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

Description

不確定な情報を伝達するための情報伝達方法及び情報伝達システムに関する。

従来のビデオゲームは、PC(Personal
Computer)、PDA(Personal Digital Assistant)、携帯電話、家庭に設置される家庭用ゲーム機、ゲームセンタ等のアミューズメント施設に設置される業務用ゲーム機等の情報端末単体でプログラムが実行され、利用者（プレイヤ）は１人で遊ぶことが主流であった。近年、複数の情報端末を接続して１つのビデオゲームに複数人が同時参加する遊び方が提案されている。

小規模な接続形態として、情報端末同士をケーブルにより接続し、互いに操作するキャラクタを対戦させる対戦プレイを行うものがあり、大規模な接続形態として、ネットワークを介してサービスを提供するサーバに情報端末を接続し、同様にサーバに接続された情報端末のプレイヤと同じゲームを遊ぶ場合等がある。また、複数の情報端末を接続する場合、プレイヤがゲームコントローラ等の入力手段により文字情報を入力することで、プレイヤ同士が表示画面を介して会話を行うチャット機能を有しているものがある。

こうして接続された情報端末間では、さまざまな情報のやり取りが行われる。やり取りされる情報には、対戦相手の強さや状態を表す情報、チャット機能を利用しプレイヤが入力した情報、ゲームの進行状況を各情報端末間で同期させる情報等さまざまな情報が含まれるが、その情報伝達形態は、送信側と受信側でその内容が変化しない、確定的な情報伝達が行われる。

一方現実的には、情報が伝播する過程で不確定な要素を含んでいき、情報は真実と離れていくことが多い。従って、自分が入手した情報の真偽が定かではないこともあるし、数人を経るうちに情報の内容が最初と変わってしまうことがよくある。ところが、真偽が定かでない情報の中には真実が含まれることもあるので、自分に興味のある情報を入手するとその真偽を確認したいという好奇心が刺激される。

従って、情報端末間で情報を伝播させる過程で情報（の内容）が不確定さを増すように変化する伝達方法があれば、その伝達方法を利用して情報を伝播させることによって、最初は正確な情報がいずれ不確定さを含む情報に変化していく。そして、プレイヤは真偽が定かでない情報を受信することによって、好奇心が刺激され、ゲームに対するプレイヤの興味を長い間引き付けることができ、ゲームをより魅力的なものとすることができる。

なお、従来技術において、情報端末間で情報を伝播させる過程で情報（の内容）が不確定さを増すように変化する伝達方法に関する有効な先行技術文献情報を発見することはできなかった。

しかしながら、従来情報端末間で行われる情報伝達は、上述したように確定的な情報伝達しか行われてこなかった。また、従来の情報伝達方法においては、情報端末同士を接続するのにプレイヤ同士の同意が前提となる場合があり、情報の伝達範囲は限られてしまう。

また、チャット機能により不特定多数のプレイヤと会話する場合、親しい人間同士でないと会話が弾まず、会話の巧みな主導者がいないと会話が続かない。会話が盛り上がらないと、伝達される情報も少ない。また、得られた情報は同時に参加可能なプレイヤのみで共有され、持ち込まれる情報は参加プレイヤが知っていることに限定されてしまう。

さらに、携帯型の情報端末（携帯電話等）でチャットに参加する場合、入力手段がPCのキーボード等と比較すると貧弱なため、会話（文字入力）が遅れがちでプレイヤがチャットをためらうなど、十分に情報伝達がなされるとは言い難い。

そこで本発明は上記課題に鑑みてなされたものであり、情報を情報端末を介して自動的に伝播させ、伝播の過程でより不確かさを増す情報伝達方法を提供することを目的とするものである。

上記目的は、本発明の第一の態様によれば、通信路を介して相互に情報交換可能に構成された複数の情報端末間で行われる娯楽的情報伝達方法を実行するためのアプリケーションプログラムであって、前記情報端末にそれぞれインストールされることによって、複数の文章生成用定型文が保存されると共に、前記複数の文章生成用定型文から選択される文章生成用定型文に、前記情報端末に入力される、又は前記情報端末で発生するイベントに関連して選択される、言葉を挿入することによって文章を生成するステップと、前記生成された文章を前記通信路を介して他の前記情報端末に送信する送信ステップと、前記他の情報端末において前記アプリケーションプログラムの実行により送信された前記文章を前記通信路を介して受信するステップと、前記受信した文章を変化させるか否かを判定する判定ステップと、前記判定ステップにおいて、前記受信した文章を変化させない場合、前記受信した文章を別の前記情報端末に転送する第一の転送ステップと、前記判定ステップにおいて、前記受信した文章を変化させる場合、前記受信した文章に含まれる第一の文章生成用定型文に対応付けられる第二の文章生成用定型文を前記複数の文章生成用定型文から選択し、前記第一の文章生成用定型文を前記第二の文章生成用定型文と入れ替えるか、又は、前記受信した文章に含まれる前記挿入された言葉を、別の言葉もしくは記号と入れ替えることによって新しい文章を生成し、前記生成された新しい文章を前記通信路を介して前記別の情報端末に転送する第二の転送ステップとを有することを特徴とするアプリケーションプログラムを提供することにより達成される。

また上記目的は、本発明の第二の態様によれば、第一の態様において、他の情報端末から受信したデータに含まれる転送回数情報および／または受信した文章の変化の度合いに基づき、受信した文章の正確度を算出するステップをさらに有し、前記保存された複数の文章生成用定型文のそれぞれには予め正確度基準値が定義されており、前記判定ステップにおいて、前記算出された正確度の値を前記受信した文章に対し予め設定される前記正確度基準値と比較する処理を行うことを特徴とするアプリケーションプログラムを提供することにより達成される。

また上記目的は、本発明の第三の態様によれば、第一または第二の態様において、前記イベントが、前記情報端末で実行されるゲームの進行によって発生することを特徴とするアプリケーションプログラムを提供することにより達成される。

また上記目的は、本発明の第四の態様によれば、第一乃至第三のいずれかの態様において、
前記情報端末は携帯端末であり、各情報端末は無線通信路を介して接続可能に構成されており、一の情報端末が他の情報端末と通信可能な距離範囲に入ったとき、前記送信ステップ又は前記第一の転送ステップ若しくは前記第二の転送ステップを実行可能にするように構成されたアプリケーションプログラムを提供することにより達成される。

また上記目的は、本発明の第五の態様によれば、第一乃至第四の態様のいずれかのアプリケーションプログラムがそれぞれ実行される複数の情報端末に通信路を介して接続されたサーバであって、前記複数の情報端末間で行われる娯楽的情報伝達の過程で変化しない確定的文章が格納される記憶部と、前記複数の情報端末の一の情報端末からの情報取得要求に応じて、前記記憶部に格納される前記確定的文章を送信する制御部とを有することを特徴とするサーバを提供することにより達成される。

また上記目的は、本発明の第六の態様によれば、第五の態様において、前記制御部は、前記一の情報端末からの前記情報取得要求と共に、該一の情報端末が送信する前記文章を受信して、前記記憶部に格納し、前記一の情報端末とは異なる別の情報端末からの前記情報取得要求に応じて、前記確定的文章と共に、前記一の情報端末から受信した前記文章を該別の情報端末に送信することを特徴とするサーバを提供することにより達成される。

また上記目的は、本発明の第七の態様によれば、第一乃至第四の態様のいずれかに記載のアプリケーションプログラムがそれぞれ実行される複数の情報端末に通信路を介して接続されたサーバであって、複数の文章生成用定型文が格納される記憶部と、前記複数の文章生成用定型文から選択される文章生成用定型文に、前記サーバに入力される、又は前記サーバで発生するイベントに関連して選択される、言葉を挿入することによって文章を生成する機能と、前記生成された文章を前記通信路を介して前記情報端末に送信する送信機能と、前記情報端末において前記アプリケーションプログラムの実行により送信された前記文章を前記通信路を介して受信する機能と、前記受信した文章を別の前記情報端末に転送する転送機能とを実現する制御部とを有することを特徴とするサーバを提供することにより達成される。

また上記目的は、本発明の第八の態様によれば、第一乃至第四のいずれかに記載のアプリケーションプログラムがそれぞれ実行される複数の情報端末と、前記情報端末に通信路を介して接続され、前記複数の情報端末間で行われる娯楽的情報伝達の過程で変化しない確定的文章が格納される記憶部と、前記複数の情報端末に含まれる一の情報端末からの情報取得要求に応じて、前記記憶部に格納される前記確定的文章を送信する制御部とを有するサーバとを備える情報システムを提供することにより達成される。

また上記目的は、本発明の第九の態様によれば、第八の態様において、前記サーバの前記制御部は、前記一の情報端末からの前記情報取得要求と共に、該一の情報端末が送信する前記文章を受信して、前記記憶部に格納し、前記一の情報端末とは異なる別の情報端末からの前記情報取得要求に応じて、前記確定的文章と共に、前記一の情報端末から受信した前記文章を該別の情報端末に送信することを特徴とする情報システムを提供することにより達成される。

また上記目的は、本発明の第十の態様によれば、第一乃至第四のいずれかに記載のアプリケーションプログラムがそれぞれ実行される複数の情報端末と、前記情報端末に通信路を介して接続されるサーバを備えた情報システムであって、前記サーバは、複数の文章生成用定型文が格納される記憶部と、前記複数の文章生成用定型文から選択される文章生成用定型文に、前記サーバに入力される、又は前記サーバで発生するイベントに関連して選択される、言葉を挿入することによって文章を生成する機能と、前記生成された文章を前記通信路を介して前記情報端末に送信する送信機能と、前記情報端末において前記アプリケーションプログラムの実行により送信された前記文章を前記通信路を介して受信する機能と、前記受信した文章を別の前記情報端末に転送する転送機能とを実現する制御部とを有することを特徴とする情報システムを提供することにより達成される。

本情報伝達方法を使用することで、例えばゲームに関する不確定情報が情報発生源から次々にゲーム端末に伝播してゆく。この不確定情報は、伝播の過程でその内容が変更される。こうして、利用者（プレイヤ）が不確定情報を入手すると、その真偽を確認したいという欲求が生まれ、ゲームをより面白くし、プレイヤの興味を長くそのゲームに引き付ける効果を持つ。また、他のプレイヤに関する情報を入手すると新たなゲームへの欲求を刺激する効果もある。更に、ゲームの進行に合わせたイベントを不確定情報として伝播させ、イベントを発生させることも可能となる。

本情報伝達方法を使用すれば、プレイヤがゲーム端末を携帯するだけで近くのゲーム端末等から不確定情報が蓄積される。その蓄積処理はゲームプログラムのバックグラウンドで行われ、プレイヤに負担をかけることがない。プレイヤのコミュニケーション能力に依存することもない。チャット等のリアルタイムコミュニケーションに要求される高い入力能力も不要で、汎用のゲーム端末で実現させることが可能である。

また、本情報伝達方法においては、情報の伝達範囲を限定することによりスパム、チェーンメールのような迷惑行為の発生を防止できる。本発明の情報伝達方法を使用すれば、現実世界における噂が伝播する様子を、ゲーム端末で実行されるビデオゲームの世界で再現することが可能になる。

本発明の方法が適用される情報伝達システムの第一の実施形態の構成を示す図である。 ゲーム端末の構成を示すブロック図である。 不確定情報に使用される定型文が格納される文章DBのデータ構成例である。 ユーザ情報のデータ構成例である。 Ａは、不確定情報DB２１に格納されるデータエントリのデータ構成例であり、Ｂは、IDのデータ構成の一例である。 送信限度回数、受信限度回数、そして送信残数によって情報の拡散が有限となることを説明する図である。 ゲーム内に発生させるイベントの内容が格納されたイベントDBのデータ構成例である。 チェックポイントDBのデータ構成例である。 通信履歴DBのデータ構成例である。 データエントリをどのように変更するかが格納される変更ルールDBのデータ構成例である。 ワード候補DBのデータ構成例である。 第一の実施形態におけるゲーム端末の動作を説明するフローチャートである。 Ａは、ユーザ情報の作成、更新に伴い不確定情報がデータエントリとして生成される場合を説明するフローチャートであり、Ｂは、ゲームの進行に伴い、プレイヤが到達したチェックポイントに応じて不確定情報がデータエントリとして生成される場合を説明するフローチャートであり、Ｃは、プレイヤがデータエントリの各項目に対する値を直接入力して不確定情報のデータエントリが生成される場合を説明するフローチャートである。 図１３ＡのステップＳ１０１における画面例である。 図１４の画面６３にて、「ユーザ情報更新」なる項目を選択した場合に表示される画面例である。 図１３ＣのステップＳ１における画面例である。 送受信処理を細分したステップを示している。 Ａは、シリアル番号を利用して禁ループバック処理を送信時に行う場合を説明するフローチャートであり、Ｂは、イベントフラグを利用して禁ループバック処理を送信時に行う場合を説明するフローチャートである。 図１８Ａの処理を具体化した例を説明するための図である。 図１８Ｂの処理を具体化した例を説明するための図である。 Ａは、IDを利用して禁ループバック処理を受信時に行う場合を説明するフローチャートであり、Ｂはシリアル番号を利用して禁ループバック処理を受信時に行う場合を説明するフローチャートであり、Ｃは、イベントフラグを利用して禁ループバック処理を受信時に行う場合を説明するフローチャートである。 図２１Ｂの処理を具体化した例を説明するための図である。 図２２Ｃの処理を具体化した例を説明するための図である。 Ａは、変更ルールDB２３に格納されたルールに基づき、データエントリの変更が行われる場合を説明するフローチャートであり、Ｂは、定型文を別の定型文に変更して、データエントリの変更が行われる場合を説明するフローチャートであり、Ｃは、定型文で使用されるワードを置換して、データエントリの変更が行われる場合を説明するフローチャートであり、Ｄは、定型文で使用されるワードを一部伏字にして、データエントリの変更が行われる場合を説明するフローチャートである。 図２４Ａ，図２４Ｂのように定型文が別の定型文に変更される場合の画面例である。 ワードが置換される場合の画面例である。 ワードが一部伏字にされる場合の画面例である。 第二の実施形態における情報伝達システムの構成図である。 情報中継端末の構成を示すブロック図である。 Ａは、第二の実施形態におけるユーザ情報のデータ構成例、Ｂは、参加端末DBのデータ構成例である。 サーバの構成を示すブロック図である。 第二の実施形態における不確定情報DBのデータ構成例である。 シリアル番号とゲームタイトルの対応関係が格納されるソフト管理テーブルのデータ構成例である。 ユーザ認証DBのデータ構成例である。 中継端末認証DB６３のデータ構成例である。 第二の実施形態におけるサーバと情報中継端末の動作を説明するタイムチャートである。 サーバに格納された情報をゲーム端末にダウンロードする様子を説明するための情報中継端末の画面例である。 認証・課金処理の一例を説明する画面例である。

以下、本発明の実施の形態について図面に従って説明する。しかしながら、本発明の技術的範囲はかかる実施の形態に限定されるものではなく、特許請求の範囲に記載された発明とその均等物にまで及ぶものである。

図１は、本発明の方法が適用される情報伝達システムの第一の実施形態の構成を示す図である。第一の実施形態では、ゲームに関する噂がゲーム端末１に不確定情報として格納される。プレイヤは、無線通信機能を備えたゲーム端末１同士で互いに通信を行い、対戦プレイを行ったり、各ゲーム端末１に格納された不確定情報を交換しゲームを楽しむ。各ゲーム端末１に格納された不確定情報が複数のゲーム端末１にて交換されることが繰り返され、不確定情報が伝播する。本実施形態の不確定情報は、予め情報端末に格納される定型文を基に生成される文章として伝播する。その定型文に言葉（ワード）を挿入することにより、さまざまな不確定情報となる。挿入される言葉は、過去に対戦したプレイヤのうち、ライバルと思うプレイヤの名前や、プレイヤが入手したアイテム等であり、ゲーム端末１に入力されるかあるいはゲーム端末１に予め格納されているものから選択される。

ゲーム端末１は、本発明の方法を実施するためのプログラムを実行して端末を制御し、ゲームを進行させる。ゲーム端末１は、例えば、携帯型ゲーム機、携帯電話、PDA(Personal Digital Assistance)等の情報端末で実現される。第一の実施形態において、不確定情報は、各ゲーム端末１に備えられた不確定情報データベース（以下、不確定情報DBと略す）２１に格納される。

図１には、不確定情報DBのデータ構成例が示されている。不確定情報DB２１の各行が上述したデータエントリである。このデータエントリをゲーム端末１が送受信することによってゲーム端末１間に不確定情報が伝播する。図１に示されるデータエントリには、「識別子(ID)」、「文章コード」、「正確度」、「ワード」が含まれる。「識別子」は、データエントリを特定するための管理番号である。「文章コード」は、後述する文章データベースにて定型文と対応付けられており、ある虫食い状態の定型文を特定する。

「ワード」には、定型文の虫食いの数に応じて少なくとも１つの語句が格納される。「正確度」は、文章コードにより特定される定型文に、ワードを当てはめて作成される文章の正確度であり、データエントリを伝達する過程において、この数値が変化する。正確度が、所定の閾値を下回ると、データエントリは変更され、情報の不確定さが増す。データエントリの変更とは、文章コードが変更される、又は、使用されるワードが他のワードに置換される、伏字に置換されるなどの処理が施されることである。

正確度は、例えば、１００が最高値で０が最低値である。正確度が高ければ高いほど、不確定情報が発生したときの内容に近く、正確度が所定の閾値未満では、その内容が変更されている恐れがあることを意味する。また、正確度を減らす主体は、送信側の情報端末、受信側の情報端末のどちらでもよい。

例えば、“〜は〜をライバルと思っているらしい”という２箇所に虫食いのある定型文の文章コードと、その定型文に対応するワードとして、“タロウ”、“ハナコ”が図１のゲーム端末１Ａの不確定情報DBに格納されているとする。定型文にワードを組み合わせてできる文章（これが不確定情報である）は、“タロウはハナコをライバルと思っているらしい”となる。こうして、定型文に対応する文章コードと、その定型文に使用されるワードとの組合せにより文章がデータエントリ毎に完成され、この文章が不確定情報２として伝播する。

そして、このデータエントリがゲーム端末１Ｂを介してゲーム端末１Ｃに伝播される過程で、正確度が減らされ、正確度が所定の閾値未満となったとき、例えば、“ハナコをライバルと思う人間がいるらしい”という新たな不確定情報３へと変更される。これは、ゲーム端末１Ｃの不確定情報DBのデータエントリにおいて、別の定型文“〜をライバルと思う人間がいるらしい”に対応する文章コードに変更されると共に、１箇所の虫食いに対応するワードが“ハナコ”に変更されたことを意味する。こうして、定型文に対応する文章コードと、その定型文に使用されるワードとの組合せにより文章がデータエントリ毎に完成され、データエントリを伝播させると、この文章が不確定情報として伝播しプレイヤに提供されることになる。

ゲーム端末１Ｃは、受信したデータエントリの識別子と同じデータエントリが不確定情報DB２１に既に格納されていないか確認し、新しいデータエントリのみを格納するようにしてもよい。すると、複数の経路からのデータエントリ（上記例で言えば、ゲーム端末１Ｃにおいて、ゲーム端末１Ｂを介さずに直接ゲーム端末１Ａから１Ｃに伝播するデータエントリ）が重複して格納されることがなく、記憶容量の使用量を節約できる。また、一度受信したデータエントリあるいは、自端末が発生源のデータエントリが他のゲーム端末１を介して再び自ゲーム端末１に戻り重複して格納されることも防止できる。

このように、ゲーム端末１への伝播の過程で不確定情報の内容がよりあやふやになるよう、言い換えると不確定さを増すようにデータエントリが変更される。多くのゲーム端末１に伝播するほど正確度は下がり、その内容が不明確で真偽のほどが定かではなくなる。こうして、不確定情報の発生から時間が経過すればするほど、また情報が経由したゲーム端末１の台数が増えるほど、真偽が不確かになる状況を作り出すことができる。

データエントリは上述したようにより不確定さを増すよう変更されるので、プレイヤは単独のデータエントリを入手するだけでは情報の真偽を断定することができない。そして、プレイヤは、真偽のほどを確かめようと実際にゲームを操作したり、別の情報を収集するために別のゲーム端末１から情報を取得しようと現実世界を移動したり、他のプレイヤと顔を合わせて会話しようと相手を探したりする。こうして長い期間、プレイヤの興味をゲームに引きつけることができる。

図２は、ゲーム端末１の構成を示すブロック図である。ゲーム端末１は、入力部１１、表示部１２、送受信部１３、制御部１４、記憶部２０、を有し、制御部１４は、ゲーム進行管理部１５、ユーザ情報管理部１６、不確定情報管理部１７を含む。本実施形態においては、ゲーム進行管理部１５、ユーザ情報管理部１６、不確定情報管理部１７は、制御部１４に備えられた図示省略されたCPUにより実行されるプログラムで実現されるが、ハードウェア回路により実現することもできる。

ゲーム進行管理部１５は、ゲーム画面を表示部１２に表示し、入力部１１を介してプレイヤより入力される命令を受け、その命令に応じた処理を行う。例えば、ゲーム進行管理部１５は、
不確定情報DBに格納されたデータエントリを表示部１２に表示し、また、ゲームに設けられたさまざまなチェックポイントのうち達成済みチェックポイントを示す情報を記憶部２０のチェックポイントデータベース（チェックポイントDB）２２に格納する。

更に、ゲーム進行管理部１５は、ゲーム内で発生させるイベントが格納されたイベントデータベース（イベントDB）２８を参照し、受信した不確定情報のデータエントリにイベントフラグが設定されていれば、対応するイベントをゲーム内に発生させる。

入力部１１は、例えば、図１の十字キーやボタンが該当し、表示部１２は、例えば、図１の画面が該当する。入力部１１、表示部１２はプレイヤとのインタフェースとして機能する。

ユーザ情報管理部１６は、記憶部２０に格納されるプレイヤのユーザ情報２４を管理する。ユーザ情報２４は、プレイヤ（あるいはそのプレイヤが操作するキャラクタ）を特定するプレイヤの名前を含み、ゲーム端末１間で交換されるデータである。また、ユーザ情報管理部１６は、送受信部１３を介して他のゲーム端末１より入力されるユーザ情報のうちプレイヤの名前を通信履歴データベース（通信履歴DB）２７に蓄積する。通信履歴DB２７に格納されたプレイヤの名前は、例えば、ライバルと思うプレイヤを設定する際に表示部１２に表示されて使用される。

不確定情報管理部１７は、チェックポイントDB２２やユーザ情報２４を参照して、不確定情報をデータエントリとして生成し、生成したデータエントリを不確定情報データベース（不確定情報DB）２１に格納し、また、有効期限切れ等で不要になったデータエントリを削除して、不確定情報DB２１を管理する。通信相手のゲーム端末１よりデータエントリを受信すると、不確定情報管理部１７は、定型文と文章コードが対応付けられ格納される文章データベース（文章DB）２５、定型文と共に使用される語句、文章、単語等が格納されるワード候補データベース（ワード候補DB）２６、及びデータエントリの変更をどのように行うかを決めるルールが格納される変更ルールデータベース（変更ルールDB）２３を参照してデータエントリの変更処理を行い、変更後のデータエントリを不確定情報DB２１に格納する。更に、不確定情報管理部１７は、通信相手のゲーム端末１へ送信するデータエントリを選択し送受信部１３に与える。

送受信部１３は、ゲーム端末１に内蔵されるか若しくは外付けされた通信アンテナ１０（図１参照）を介して他のゲーム端末１と無線通信可能な無線通信機能を有し、ユーザ情報２４及び不確定情報DB２１に格納されたデータエントリを通信相手のゲーム端末１（以下、通信相手端末と称す）に対し送受信する。通信アンテナ１０は、ゲーム端末１に備えられた図示しない拡張機器コネクタを介して接続される拡張機器として提供されてもよい。

送受信部１３は、無線通信可能な通信相手端末がある場合、制御部１４を介して得られるユーザ情報２４と不確定情報DB２１に格納されたデータエントリを通信相手端末に送信する。そして、送受信部１３は、通信相手端末から受信したユーザ情報をユーザ情報管理部１６に与え、通信相手端末から受信したデータエントリを不確定情報管理部１７に与える。

記憶部２０には、図示しない端末制御プログラム、不確定情報DB２１、チェックポイントDB２２、変更ルールDB２３、ユーザ情報２４、文章DB２５、ワード候補DB２６、通信履歴DB２７、イベントDB２８、その他ゲーム端末１で行われる処理に必要なデータが格納される。記憶部２０は、例えば、バッテリーバックアップされたRAM、フラッシュロム、ハードディスク等の記憶手段である。

続いて、記憶部２０に格納されるデータ毎のデータ構成を、文章DB２５、ユーザ情報２４、不確定情報DB２１、イベントDB２８、チェックポイントDB２２、通信履歴DB２７、変更ルールDB２３、ワード候補DB２６の順に説明する。

[文章データベース]
図３は、不確定情報に使用される定型文が格納される文章DB２５のデータ構成例である。文章DB２５には、虫食い状態の「定型文」と、その定型文を特定する「文章コード」と、虫食い状態の定型文を埋めるのに必要な「ワードの項目」とが格納されている。

図３において、例えば、文章コード００１に対応する定型文“〜は〜をライバルと思っているらしい”は、文中に２箇所の空き（虫食い）があり、そこに格納されるワードの項目は「主語」、「ライバル」であることがわかる。これは、虫食いを埋めるのに使用されるワードが、後述するワード候補DBにてワードの項目「主語」、「ライバル」に格納されたワードから選択可能であることを意味する。文章DB２５には、一般的な不確定情報が生成されるときに選択される初期定型文、伝播の過程でデータエントリが変更するときに選択される変更用定型文、ゲーム内に設定されたチェックポイントにプレイヤが到達するときに生成される不確定情報に使用されるチェックポイント対応用定型文、ゲーム内で発生させるイベント用のイベントフラグ対応用定型文等が格納される。チェックポイント、イベントについても後述する。

[ユーザ情報]
図４は、ユーザ情報２４のデータ構成例である。ユーザ情報２４は、ゲーム端末１のプレイヤ自身のユーザ情報（本人データ）が格納される。ユーザ情報は、ゲーム開始時にゲーム進行管理部１５がユーザ情報入力画面を表示して、プレイヤに入力を促し、入力された内容で初期設定される他、ゲーム実行中に入力部１１を介して呼び出された更新画面をゲーム進行管理部１５が表示して、プレイヤに入力を促し、入力された内容で更新される。

ユーザ情報には、「シリアル番号」、「名前」、「性別」、「本拠地」、「ライバル」、「仲間」、「レアアイテム」というデータ項目が含まれる。「シリアル番号」は、ゲームプログラムが格納されたROMカートリッジ、CD、DVD等の記憶媒体を特定する番号である。

ゲームプログラムが記憶媒体により提供されるのではなく、例えば、サーバから直接ゲーム端末１にダウンロードされるのであれば、「シリアル番号」はゲーム端末１の機器固有番号でもよい。あるいは、プログラム毎に異なる識別番号を持つようにゲームプログラムがコーディングされていれば、「シリアル番号」にはその識別番号を使用することもできる。このシリアル番号をデータエントリのIDの一部に使用することで、不確定情報が一意に特定され、同じ不確定情報を重複して不確定情報DBに蓄積することを回避することができる。

「名前」は、ゲームを遊ぶプレイヤを特定する名前である。「名前」には、自分の本名を使用しても、ゲームを遊ぶためだけのニックネームを使用してもよい。「性別」は、男性か女性か選択する。プレイヤは、どちらかを選択したくない場合、秘密にすることもできる。その場合、「性別」には「秘密」が格納される。

「本拠地」は、プレイヤが普段生活する地域を設定する。本拠地を設定すると、地域限定の不確定情報を入手することができる。プレイヤは、本拠地を設定したくない場合、秘密にすることができる。その場合、「本拠地」には、「指定なし」が格納される。

「ライバル」と「仲間」はそれぞれ、他のプレイヤの「名前」が格納される。ゲーム開始時は、相手のプレイヤに関する情報がない場合が普通であり、「ライバル」、「仲間」には、それぞれ「設定なし」が格納される。「レアアイテム」には、プレイヤがゲーム内で入手したアイテムのうち、出現頻度が少ないあるいは入手が困難なアイテムとして分類されるもの（レアアイテム）の名前が格納される。

「ライバル」、「仲間」、「レアアイテム」に有効な値が格納されると、それに関する不確定情報が生成される。例えば、対戦プレイにおいて、「ライバル」に指定されたプレイヤに勝利するとボーナスポイントが得られる、相手のアイテムが入手できるといった特殊効果がある。「仲間」に指定されたプレイヤとは、ゲーム内の任務や対戦プレイにおいて、協力した行動を取ることができるといった特殊効果がある。従って、この項目を設定すると１人でゲームをプレイするのとは異なる展開をプレイヤは体験できるので、よりゲームの面白さを加速し、またゲームに対する興味を持続させることができる。またこれらの項目に関する不確定情報がゲーム端末１間で伝播すると、そのプレイヤとの対戦を求めてユーザが移動し、より不確定情報が拡散しやすくなる。

また、レアアイテムを欲しいと思うプレイヤは、それを持つプレイヤとの対戦プレイに勝利して入手するか、そのプレイヤがレアアイテムを入手したゲーム内での場所に行くか、そのプレイヤ本人に話を聞こうする。従って、レアアイテムに関する不確定情報をゲーム端末１間に伝播させることは、ゲーム内外でのこのような行動を喚起し、やはりゲーム対する興味を持続させることになる。

[不確定情報データベース]
図５Ａは、不確定情報DB２１に格納されるデータエントリのデータ構成例である。図５Ａのデータエントリには、図１で説明した「ID」、「文章コード」、「正確度」、「ワード」に加えて、「送信限度回数」、「送信残数」、「受信限度回数」、「種類」、「イベントフラグ」、「有効期限」、「地域」が含まれる。このうち「ID」、「文章コード」、「正確度」、「ワード」以外は、ゲームをより楽しくするためや管理を容易にするための付加的なデータ項目である。

図５Ｂは、データエントリを特定するための管理番号である「ID」のデータ構成の一例である。図５Ｂには、一例として、ユーザ情報２４に含まれるシリアル番号（図４参照）と、日付と、不確定情報管理部１７によりデータエントリの生成時に付けられる連続番号がハイフン記号で結ばれている。これは、不確定情報管理部１７が、ユーザ情報２４から得られるシリアル番号と、ゲーム端末１に備えられた時計（図２にて図示省略）から得られる日付に、その日に生成した何番目の不確定情報かを示す連続番号を付与してIDを作成することで得られる。

不確定情報管理部１７は、他のゲーム端末１からデータエントリを受信すると、同一IDのデータエントリがない場合に、受信したデータエントリを不確定情報DB２１に格納する。すると、同じデータエントリが重複して格納されることはない。つまり、一度受信したデータエントリあるいは、自端末が発生源であるデータエントリが他のゲーム端末を介してループバックする現象を防止できる。これにより、データエントリが何度も同じゲーム端末間で堂々巡りし、受信する度に不明確になっていくデータエントリを受信することでプレイヤが混乱する事態を防止することができる。

図５Ａに戻り、「文章コード」は、図３の文章DB２５に格納された「定型文」を特定する文章コードである。「ワード」は、「文章コード」によって特定される定型文の虫食いを埋めるための語句、単語等である。

この「文章コード」により特定される定型文と「ワード」を組み合わせることにより不確定情報がプレイヤに提供される。例えば、「文章コード」が“００１”で、「ワード」として“タロウ、ハナコ”が格納されたデータエントリであれば、図３にて文章コード００１に対応する定型文を参照し、“タロウはハナコをライバルと思っているらしい”という文章が作成され、これが不確定情報としてプレイヤに提供される。

「正確度」は、不確定情報の正確さを示す数値である。この数値は、初期値として１００が設定され、不確定情報がゲーム端末１間で伝播するに従って減少する。そして正確度が所定の閾値未満になったときデータエントリが変更される。

この正確度によって、不確定情報の発生源に、時間的あるいは距離的に近いゲーム端末１には、より不確定情報が発生したときと同じ内容が伝播し、時間的あるいは距離的に遠いゲーム端末１には内容の不明確さが増した内容が伝播するという効果がある。正確度を減らす主体は、送信側、受信側のゲーム端末１のどちらであってもよい。

「送信限度回数」は、他のゲーム端末１にデータエントリを送信可能な回数を示す。「送信残数」は、「送信限度回数」を初期値として設定され、他のゲーム端末１にデータエントリを送信する度に１ずつ減らされる。「送信残数」が０になった情報は、それ以上送信されない。

「受信限度回数」は、受信可能な回数を示す数値である。ゲーム端末１は、受信したデータエントリを不確定情報DBに格納するとき、数値を１減らす。そして、受信回数が０になった情報は、それ以上送信されない。「受信限度回数」、「送信限度回数」は特に指定されない限り、所定の値、例えば、それぞれ３回と決められている。入力により指定された場合は、その値が使用される。上記「送信限度回数」、「送信残数」、「受信限度回数」は、データエントリが無限に拡散されることを防止するための転送回数情報として機能する。次図にてその状況を説明する。

図６は、送信限度回数、受信限度回数、そして送信残数によって情報の拡散が有限となることを説明する図である。送信限度回数３回、受信限度回数３回に設定されたデータエントリがあるとする。送信限度回数により、プレイヤＡのゲーム端末１からは３台のゲーム端末１にこのデータエントリを送信可能であり、それぞれプレイヤＢ、Ｃ、Ｄのゲーム端末１に送信する。１回送信する度に、プレイヤＡのゲーム端末１に格納された送信残数が１減らされ、プレイヤＤのゲーム端末１にデータエントリを送信すると送信残数が０になるので、プレイヤＡのゲーム端末１からそれ以上他のゲーム端末１にこのデータエントリが送信されることはない。

プレイヤＡから送信されたデータエントリがプレイヤＢのゲーム端末１に格納される際、受信限度回数が１減らされた値に更新される。プレイヤＡからのデータエントリを受信したプレイヤＢのゲーム端末１も又、他の３台のゲーム端末１にこのデータエントリを送信可能である。こうして、プレイヤＢのゲ−ム端末からプレイヤＥ、Ｆ、Ｇのゲーム端末１へデータエントリが伝播する。

同様に、プレイヤＢから送信されたデータエントリがプレイヤＥのゲーム端末１に格納される際、受信限度回数が１減少した値に更新される。プレイヤＥのゲーム端末１からはプレイヤＨ、Ｉ、Ｊのゲーム端末１にデータエントリが送信され、受信限度回数が１減少した値に更新される。プレイヤＨ、Ｉ、Ｊのゲーム端末１にデータエントリが格納されると、受信限度回数は０となる。従って、ここでこのデータエントリの伝播は停止し、これ以上この情報が広まることはなくなる。プレイヤＣ、プレイヤＤに伝播した情報に関しても同じことが言える。

送信限度回数３回、受信限度回数３回の情報は２７台の情報端末に伝播する。一般化すると、ｘのｙ乗（ｘ：送信限度回数、ｙ：受信限度回数）台の情報端末に伝播することになる。これにより、情報を広める台数を予め制限することができる。つまり、スパムメールやチェーンメールに相当する迷惑行為を防止することができる。

図５Ａに戻り、不確定情報DB２１のデータエントリに含まれるデータ項目の説明を続ける。「種類」は、データエントリの種類を示す情報である。例えば、０は、ライバルに関するデータエントリを意味し、１は、仲間に関するデータエントリを意味し、２は、ゲームの進行状況に関するデータエントリを意味し、３は、伝播によっても変化しないデータエントリを意味する。

ライバルに関するデータエントリは、あるプレイヤが別のプレイヤをライバルとしてゲーム端末において設定する際に生成されるものである。仲間に関するデータエントリは、あるプレイヤが別のプレイヤを仲間としてゲーム端末において設定する際に生成されるものである。

ゲームの進行状況に関するデータエントリは、プレイヤがゲームに設定されたチェックポイントに到達することで生成されるものである。伝播によっても変化しないデータエントリは、画定情報と呼ばれ、例えば、ゲームベンダが発表する公式な情報やプログラムに連動してゲーム内でイベントを発生させることを予告する情報がある。

従って、上記例においては、「種類」が３以外であれば、データエントリが伝播の過程で変化し、「種類」が３の場合、データエントリは変化しない。第一の実施形態においては、偽の情報がプレイヤにより確定情報として作成されることを防止するため、ゲーム端末１で生成される情報はすべて「種類」が３以外の不確定情報である。「種類」が３であるデータエントリが生成される場合については第二の実施形態で説明する。なお、種類は４つに限られるものではなく、本情報伝達方法の実行者が自由に設定することが可能である。

こうして、「種類」を使用すれば、ゲーム大会予告や宣伝情報等の公式情報をもプレイヤに伝播することが可能となる。そして、公式情報は内容が変更されないことが保証される。例えば、広告主を募集し、広告をゲーム端末１に伝播させることでゲームベンダがその広告料を新たな収益源とすることもできる。

「イベントフラグ」は、ゲームプログラムと連動してゲーム内にイベントを発生させるのに使用されるフラグ情報であり、値が１であればイベントの設定有り、０であればイベントの設定無しを意味する。予めプログラムには、イベントフラグに対応して発生させるイベントがコーディングされており、受信した情報にイベントフラグが設定されていれば、対応するイベントがゲーム内で発生する。

[イベントデータベース]
図７は、受信したデータエントリに応じて、ゲーム内に発生させるイベントの内容が格納されたイベントDB２８のデータ構成例である。図７に示されるように、受信したデータエントリに含まれる文章コードと、その文章コードに対応するイベントの内容と、そのイベントが発動されているかを示すフラグ情報である「オン・オフフラグ」が対応付けられて格納されている。
図７の文章コードを、図３の文章ＤＢにおいて検索すれば、プレイヤにイベントの内容を提供するための不確定情報を特定することができる。

例えば、図５Ａにおいて最後のデータエントリは、イベントフラグが１であり、何らかのイベントを含んだデータエントリであることがわかる。今、その文章コードの値は１００１である。ゲーム進行管理部１５は、受信したデータエントリに含まれる文章コードの値で、図３の文章DB２５と図７のイベントDB２８を検索し、表示部１２を介してプレイヤに、「今月中に対戦で５連勝するとレアアイテムがもらえるらしい」という不確定情報を提供する。

表示部１２に表示し、プレイヤがデータエントリを確認した後、ゲーム進行管理部１５は、「情報取得月内に他のプレイヤに５連勝すれば、ゴールドメダルというレアアイテムを与える」というイベントを発生させ、図７の「オン・オフフラグ」をONに変更する。

図５Ａに戻り、「有効期限」は、データエントリが有効な期間や日付を示す情報である。有効期限の設定されたデータエントリは、発生してから一定期間を過ぎると無効となる。無効なデータエントリはそれ以上送信されないので、データエントリの余計な拡散を防止する効果もある。また、より多くのプレイヤにゲームに参加してもらうためのプロモーションとして期間限定のイベントを行う場合等に有効期限を設定したデータエントリを確定情報として伝播させ、ゲームに対するプレイヤの興味を引きつけてもよい。

「地域」は、データエントリの拡散範囲を示す情報である。例えば、都道府県単位となる。地域は、ユーザ情報に含まれる「本拠地」（図４参照）と合わせて活用される。例えば、「地域」として東京都が選択されているとすると、「本拠地」が東京都に一致するプレイヤにだけ情報が伝播されるようにすることが可能である。こうして、特定の地域内で拡散するデータエントリと全国規模に広がるデータエントリとを作成することができる。

[チェックポイントデータベース]
図８は、チェックポイントDB２２のデータ構成例である。チェックポイントDBには、チェックポイントを特定する「チェックポイントコード」、「オン・オフフラグ」、「文章コード」、「ワード」、「条件」が互いに関連付けられ格納される。プレイヤがゲーム内で「条件」に記載された条件を満たせば、プレイヤがそのチェックポイントを達成したかどうかを示すフラグ情報である「オン・オフフラグ」が、「ON」に切り替わる。

すると、到達したチェックポイントに関する不確定情報が生成されるが、その際「文章コード」、「ワード」が参照される。なお、「ワード」に含まれる項目のうち、「主語」以外には、項目ごとに対応する値がイコール記号で結ばれて格納され、その値が使用される。「主語」は、ゲーム端末１でプレイするプレイヤの名前（図４のユーザ情報の「名前」）が使用される。

例えば、図８にてチェックポイントコードが００１の場合、プレイヤ（“タロウ”とする）が狼を倒すことにより、オン・オフフラグが「ON」になり、文章コードが５０１であり（図３参照）、ワードが、「主語、狼」であることから、“タロウは変装して狼を騙したらしい”という不確定情報のデータエントリが生成されることになる。こうして、プレイヤが「条件」を満たす度に、チェックポイントDB２２が更新され、不確定情報が生成される。

[通信履歴データベース]
図９は、通信履歴DB２７のデータ構成例である。通信履歴DB２７には、ゲーム端末１と過去に通信したことのある他のゲーム端末１から送信されたユーザ情報から抽出された、プレイヤの名前（図４の「名前」）と通信が行われた日時が格納される。通信日時が記録されており、記憶容量に余裕がない場合、古いものから削除される。

[変更ルールデータベース]
図１０は、データエントリをどのように変更するかが格納される変更ルールDBのデータ構成例である。図１０の変更ルールDB２３には、受信したデータエントリに含まれる文章コード（「受信した文章コード」）毎に、「正確度」の区分と、正確度がその区分に含まれるときの文章コード（「変化後の文章コード」）と、「変化後の文章コード」に対応する定型文で使用される「ワードの項目」が格納される。図１０の「正確度」は、定型文毎に予め設定される正確度基準値であり、受信したデータエントリの正確度が属する区分に応じてデータエントリを変化させるかが決定される。

図１０では、例えば、「受信した文章コード」が００３の場合、正確度が６０以上８０未満になると、文章コードが１０２に変更され、受信したデータエントリにて使用されていたワードの項目の内、「場所」と「アイテム」を引き継いだ新たなデータエントリに変更される。具体的には、「主語」（＝プレイヤの名前）が「タロウ」、「場所」が「鬼ヶ島」、「アイテム」が「巻物」であるとすると、変更前は、文章コードが００３あることから、“タロウは鬼ヶ島で巻物を手に入れたらしい”という不確定情報が、変更後は、文章コードが１０２であることから、“鬼ヶ島で巻物を手に入れた人間がいるらしい”と変更され、誰が手に入れたのかが不明になる。

更に正確度が６０未満になると、文章コードが１０３となり、受信したデータエントリにて使用されていたワードの項目の内「アイテム」が引き継がれ、“巻物を手に入れた人間がいるらしい”と変更され、誰が、何処で手に入れたかが不明になる。こうして、不確定情報がより不確定さを増すようにデータエントリが変更されていく。

[ワード候補データベース]
図１１は、データエントリを図１０とは別の方法で変更する際に使用される、ワード候補DB２６のデータ構成例である。図１１には、「ワードの項目」毎に、データエントリにてその項目のワードを置換可能な候補（「置換後のワード」）が複数対応している。「番号」は、「ワードの項目」を特定したとき、「置換後のワード」を特定するための識別番号である。

図１１の「ワードの項目」のうち、「主語とライバル」に対応する項目以外は、予めワード候補DBに格納される。「主語とライバル」は、図９に示される通信履歴DB２７に格納される通信相手の名前である。即ち、他のゲーム端末１との通信が行われると、通信履歴DB２７と共に、ワード候補DB２６の「主語とライバル」欄に、通信相手の名前が格納される。

図１１のワード候補DB２６は、文章コードはそのままで、ワードをいくつか置換してデータエントリを変更する際に参照される。例えば、文章コードが００１であり、その文章コードの定型文に対応するワードとして、主語が「タロウ」、ライバルが「ハナコ」であるデータエントリが不確定情報DB２１に格納されているとする。正確度が所定の閾値未満となったとき、不確定情報管理部１７は、受信したデータエントリの文章コードを、図３の文章DB２５で検索し、使用されているワードの項目を取得する。

ここでは、文章コード００１の定型文にて「主語」、「ライバル」が使用されることがわかる。次に、不確定情報管理部１７は、この項目から変更する項目を選択する。変更する項目は、１つでも複数でもよい。例えば、「主語」のみを変更する場合、図５のワード候補DBの「ワードの項目」を「主語」で検索し、不確定情報管理部１７は、対応する複数の「置換後のワード」から１つワードを選択し置換する。

上記の例で、図１１のワード候補DBの「主語とライバル」の４エントリから、「ダイスケ」（番号００３）が選択されると、置換後のデータエントリは、文章コードはそのままで、ワードが「タロウ、ハナコ」から「タロウ、ダイスケ」となり、“タロウはダイスケをライバルと思っているらしい”という不確定情報に変更される。

以上に説明したゲーム端末の構成に基づいて、次に第一の実施形態におけるゲーム端末の動作を説明する。

図１２は、第一の実施形態におけるゲーム端末の動作を説明するフローチャートである。本実施形態においては、制御部１４を、ゲーム進行管理部１５、ユーザ情報管理部１６、不確定情報管理部１７として機能させるプログラムをゲーム端末にインストールすると、ゲーム端末１に、チェックポイントDB２２、変更ルールDB２３、文章DB２５、ワード候補DB２６、イベントDBがコピーされる。インストール時にコピーされるワード候補DB２６は、そのプログラムに記録された初期データであり、ゲームの進行に伴って新たなデータ（不確定情報の交換を行ったプレイヤの名前や、ゲーム内で立ち寄った場所等）が追加される。

まず、不確定情報管理部１７は、不確定情報DB２１に不確定情報として伝播させるデータエントリを蓄積する（Ｓ１）。データエントリの蓄積は、そのゲーム端末において生成された不確定情報が格納される場合と、他のゲーム端末から受信したデータエントリを格納する場合と２種類ある。ステップＳ１の処理は、不確定情報の生成時やデータエントリの受信時に割り込み処理され、データエントリの蓄積が完了すると元の処理が再開される。また、不確定情報が生成される過程は複数種類存在し、その詳細は図１３を用いて後述する。

次に、不確定情報管理部１７は、送受信部１３を介してゲーム端末と通信可能な他のゲーム端末が存在するかを判定する（Ｓ２）。もし、通信可能なゲーム端末がなければ（Ｓ２Ｎｏ）、ステップＳ１に戻り、通信可能なゲーム端末が通信圏内に移動するのを待機する。

自端末と通信可能なゲーム端末（通信相手端末）があれば（Ｓ２Ｙｅｓ）、不確定情報管理部１７は、自端末のユーザ情報２４と不確定情報DB２１のデータエントリを送受信部１３に出力し、送受信部１３は、それらを通信相手端末に送信する（Ｓ３）。すべてのデータエントリを出力するのではなく、個数やデータサイズで制限してもよい。

また、送受信部１３は、通信相手端末のユーザ情報を受信してユーザ情報管理部１６に出力し、ユーザ情報管理部１６は、ユーザ情報に含まれる通信相手端末のプレイヤの「名前」（図４参照）を通信履歴DB２７とワード候補DB２６の「主語とライバル」欄に格納する。また送受信部１３は、通信相手端末からデータエントリを受信して不確定情報管理部１７に出力する（同じくＳ３）。

ある特定のゲーム端末の通信可能圏内に複数のゲーム端末があっても、送受信処理はその内の１台に対して行われる。１対１の送受信処理が終了した後、通信可能圏内にある別のゲーム端末ゲーム端末とその特定のゲーム端末との送受信処理が開始される。従って、１対１の送受信処理が終了したとき、ゲーム端末が移動して、通信可能圏内に他のゲーム端末が存在しなくなれば、送受信処理は終了する。

不確定情報管理部１７は、受信したデータエントリの正確度を所定数減らした値に更新する（Ｓ４）。１回に減らす正確度（所定数）は、予め決められた値（例えば、毎回２０ずつ正確度を減らす）であるが、データエントリ毎に異なる値、ゲーム端末毎に異なる値とすることもできる。例えば、データエントリ毎に異なる値を減らす場合、図５Ａに示された不確定情報DBのデータ構成が、更に、図示しない「所定数」のデータ項目を含み、受信したデータエントリ毎に、ゲーム端末１が「所定数」に格納された値を「正確度」から減らすことで実現できる。また、ゲーム端末１の記憶部２０に予め所定数を記憶しておき、ゲーム端末１が、受信したデータエントリの「正確度」から記憶部２０に格納された所定数を減らすことで、ゲーム端末毎に所定数を変えることができる。

そして、不確定情報管理部１７は、ステップＳ４で更新された正確度を所定の閾値と比較し、正確度が所定の閾値を下回った場合（Ｓ５Ｙｅｓ）、受信したデータエントリに対する変更処理を行う（Ｓ６）。ステップＳ６が済むと、ステップＳ１に進み、不確定情報管理部１７が、変更処理が行われたデータエントリを不確定情報DBに格納する。ステップＳ５において、正確度が所定の閾値以上であれば（Ｓ５Ｎｏ）、ステップＳ１に進み、不確定情報管理部１７が、受信したデータエントリをそのまま不確定情報DBに格納する。

ステップＳ６における受信したデータエントリに対する変更処理は複数種類存在し、その詳細は図２４を用いて後述する。またステップＳ６において、所定の閾値をどのように設定するかにするかは、データエントリの変更処理に応じて変わるのでこれも図２４にて説明する。

続いて、不確定情報がデータエントリとして生成され、不確定情報DB２１に蓄積される際のゲーム端末１での動作例を説明する。これは、図１２のステップＳ１に含まれる。

図１３Ａは、ユーザ情報の作成、更新に伴い不確定情報がデータエントリとして生成される場合を説明するフローチャートである。ゲーム進行管理部１５は、表示部１２を介してユーザ情報作成・更新画面を表示する（Ｓ１０１）。この画面では、ユーザ情報のデータ項目（図４参照）に対する値を入力することができる。そして、入力された値は図４に示されるユーザ情報２４として記憶部２０に格納される（Ｓ１０２）。

不確定情報管理部１７は、ユーザ情報２４の更新を定期的に監視し、ユーザ情報２４のデータ項目のうち、「ライバル」、「仲間」、「レアアイテム」が設定されたかを判定する（Ｓ１０３）。ユーザ情報２４の更新がこれら３つの項目に対するものでない場合（Ｓ１０３Ｎｏ）、図１２のステップＳ２に進む。

ユーザ情報２４の更新がこれら３つの項目に対するものである場合、不確定情報管理部１７は、データエントリを生成し不確定情報DB２１に格納する（Ｓ１０４）。不確定情報管理部１７は、ステップＳ１０３で設定されたデータ項目をキーとして図３の文章DB２５の「ワードの項目」を検索し、一致するエントリの「文章コード」を１つ選択する。不確定情報管理部１７は、「ライバル」が設定されれば「ライバル」で検索し、「仲間」が設定されれば「仲間」で検索し、「レアアイテム」が設定されれば、「アイテム」で検索し、これらの項目と一致するか、主語との組になっているものを選択する。

主語との組が含まれる理由は、ユーザ情報を確認すればプレイヤの名前が得られるので、「主語」は自由に使用することができるためである。つまり、図３のワードの項目が、「ライバル」、「仲間」、「アイテム」、「主語、ライバル」、「主語、仲間」、「主語、アイテム」となっているものの中から選択が行われる。こうして、「文章コード」が決まる。

「ワード」は、ステップＳ１で入力された値が使用される。「正確度」は、初期値として１００が設定される。「送信限度回数」、「受信限度回数」は特に指定がないので、所定の初期値（例えば、３回ずつ）が設定される。「送信残数」は、初期値として、「送信限度回数」と同じ値が設定される。「種類」は、ここでは不確定情報を示す０が設定される。

「イベントフラグ」は、選択された文章コードが図７のイベントDBに含まれる場合は１が、そうでない場合は０が設定される。「有効期限」、「地域」は、ここでは「設定なし」と設定される。「ID」は、ユーザ情報のシリアル番号、日付、その日に生成した不確定情報に基づいて作成される。こうして、１つのデータエントリが生成され、不確定情報DB２１に格納される。

図１４は、図１３ＡのステップＳ１０１における画面例である。つまり、ユーザ情報２４が作成・更新される際にゲーム進行管理部１５が制御する表示内容が描かれる。図１４において、ゲーム端末１に電源を入れると、まず、タイトルとメニューが表示される（画面６１）。ここでは、「Ａの冒険」というRPG(Roll Playing Game)とする。最初から開始する場合メニュー１（新たに開始）を選択し、途中から再開する場合メニュー２（記録から開始）を選択する。

メニュー１が選択されると、ユーザ情報を新規に作成するための画面が表示される（画面６２）。ここでは、プレイヤが操作するキャラクタに対する名前と、プレイヤが操作するキャラクタに対する性別と、プレイヤが住んでいる都道府県（本拠地）、ライバル情報、仲間情報、取得済みのレアアイテムを入力する。「名前」の入力だけが必須である。

そして、入力が完了すると、ゲームが開始される（画面６３）。画面６１でメニュー２を選択した場合は、そのプログラムに対して既に登録された名前が表示され、プレイヤがその中から名前を選択すると、選択された名前でプレイを中断した箇所からゲームが再開される（画面６５）。画面６３には、ゲーム実行中に入力部１１を操作することにより呼び出されるゲーム内メニュー１４１が表示され、「ユーザ情報表示」なる項目を選択することにより、現在のユーザ情報２４が表示されることになる（画面６４）。

ゲームをプレイする時間が増えると、他のゲーム端末１と不確定情報を交換する機会が増えることで、他のプレイヤの情報が入手でき、ライバルや仲間の設定がしやすくなる。また、自らのゲームも進行し、レアアイテムを入手する機会が増え、レアアイテムの設定がしやすくなる。そのような場合、画面６３に示されるゲーム内メニュー１４１を呼び出し、ユーザ情報２４を更新することができる。そして、この更新に基づいて図１３Ａで述べたように不確定情報が生成される。

図１５は、図１４の画面６３にて、「ユーザ情報更新」なる項目を選択した場合に表示される画面例である。まず、更新したい項目を選択するメニューが表示される（画面６６）。例えば、ライバルを設定する場合、メニューで３が選択され、ライバル入力画面に切り替わる（画面６７）。「直接入力」を選択すると、画面６９が表示され、ライバルプレイヤの名前を直接入力できる。

「通信履歴から選択」を選択すると、画面６８が表示され、通信履歴DB２７に格納された通信相手の名前が一覧表示され、この中からライバルが選択される。画面６８または画面６９にてライバルの選択が完了すると、ライバルの設定が完了したことが表示される（画面７０）。

図１３に戻り、説明を続ける。図１３Ｂは、ゲームの進行に伴い、プレイヤが到達したチェックポイントに応じて不確定情報がデータエントリとして生成される場合を説明するフローチャートである。

ゲームの進行に伴い、プレイヤがチェックポイントDBに格納された条件を満たすと、プレイヤはチェックポイントに到達したことになり（Ｓ１１１）、ゲーム進行管理部１５は、チェックポイントDB２２（図８参照）にて該当するチェックポイントのオン・オフフラグを「ON」にする（Ｓ１１２）。

不確定情報管理部１７は、チェックポイントDB２２の更新を定期的に監視し、オン・オフフラグが「ON」に切り替わったものがあるかを判定する（Ｓ１１３）。チェックポイントDB２２の更新が、オン・オフフラグの更新でない場合（Ｓ１１３Ｎｏ）、例えば、新たなチェックポイントの追加や、文章コード等の変更である場合等には、図１２のステップＳ２に進む。

チェックポイントDBの更新により、オン・オフフラグが「ON」に切り替わったものがある場合、不確定情報管理部１７はデータエントリを生成し不確定情報DBに格納する（Ｓ１１４）。不確定情報管理部１７は、ステップＳ３で「ON」に切り替わったチェックポイントコードの「文章コード」と「ワード」を、データエントリの「文章コード」「ワード」に設定する。「ワード」に「主語」が含まれる場合、ユーザ情報から得られるプレイヤの「名前」（図４参照）を格納する。その他の項目については、図１３Ａの場合と同じであり説明は省略する。こうして、１つのデータエントリが生成され、不確定情報DB２１に格納される。

図１３Ｃは、プレイヤがデータエントリの各項目に対する値を直接入力して不確定情報のデータエントリが生成される場合を説明するフローチャートである。ゲーム進行管理部１５は、表示部１２を介して不確定情報入力画面を表示する（Ｓ１２１）。この画面では、データエントリのデータ項目に対する値を入力することができる。そして、入力された値は不確定情報管理部１７に与えられ、不確定情報管理部１７は、データエントリとして不確定情報DB２１に格納する（Ｓ１２２）。

図１６は、図１３ＣのステップＳ１における画面例である。つまり、不確定情報がユーザにより入力される際にゲーム進行管理部１５が制御する表示内容が描かれる。図１６では、まず不確定情報入力画面が表示される（画面７１）。これは、図１４の画面６３において、「不確定情報入力」なる項目を選択すると表示される画面である。

画面７１には、プレイヤに定型文の選択を入力させる画面が表示され、プルダウンメニュー１６１で表示された文章コードを変更すると、文章DB２５でその文章コードに対応する定型文が枠１６２に表示される。

画面７１で定型文が決定すると、「文章コード」が確定し、ゲーム進行管理部１５は、次にその定型文で使用される「ワード」を入力させる画面を表示する（画面７２）。ワードの入力が済むと、「送信限度回数」、「受信限度回数」を入力させる画面を表示する（画面７３）。最後に、「有効期限」、「地域」を入力させる画面を表示する（画面７４）。各画面で入力された値は、データエントリの対応する項目に格納され、「ID」はバックグラウンドで自動的に生成されるので、こうして１つのデータエントリが生成され、不確定情報管理部１７はデータエントリを不確定情報DB２１に格納する。

以上に述べたデータエントリの蓄積処理によって、さまざまな種類の不確定情報が生成されることになる。ユーザ情報に設定したライバル、仲間、レアアイテム等により生成された不確定情報を受信したプレイヤは、他のプレイヤを探そうとする。仲間プレイヤを発見できれば、それまで攻略できない相手に協力して挑むことができたり、ライバルプレイヤを発見できれば、レアアイテムを見つけることができるかもしれないからである。

チェックポイントに基づいて作成された不確定情報を受信したプレイヤは、例えば、自分が未知の領域に他のプレイヤが到達したかもしれないという噂を入手することで、自分もそこで行きたい、そして何が起こるのか実際に確認したいという気持ちに駆られ、よりゲームを深く遊ぼうとし、ゲームに対する興味を長く保つことができる。また、これらの情報が攻略のヒントとなり、ゲーム初心者の助けとなることもある。

次に、データエントリの送受信処理（図１２Ｓ３）について詳述する。

図１７は、送受信処理を細分したステップを示している。まず、ゲーム端末は、通信相手のゲーム端末からユーザ情報を取得し、そこに含まれるシリアル番号を抽出する（Ｓ３０１）。続いて、どちらのゲーム端末が先にデータエントリを送信するかを端末順位として決定する（Ｓ３０２）。

ステップＳ３０２における端末順位は、データエントリに設定された優先度を基に決定される。ここでは、データエントリの「種類」に割り当てられた数字の大きいものがより優先度が高いデータエントリであるとする。そして、各ゲーム端末が不確定情報DBに格納されたすべてのデータエントリの優先度の合計値を算出し、その合計値を交換する。

合計値が大きい方が端末順位の高いゲーム端末である。ステップＳ３０２において、順位の高いゲーム端末が送信処理（Ｓ３０３）、受信処理（Ｓ３０４）の順で処理を行い、順位の低いゲーム端末は、受信処理（Ｓ３０４）、送信処理（Ｓ３０３）の順で処理を行って、送受信処理が終了する。図１７に示されているフローは前者を示したものである。

ステップＳ３０２における端末順位の決定法としては、優先度の合計値ではなく、優先度の合計値を不確定情報DBに格納されたデータエントリ数で割った平均値を使用することもできる。または、最高位の優先度のデータエントリをより多く有するゲーム端末（例えば、「種類」が３であるデータエントリ数がより多い方）を端末順位の高い端末と決定してもよい。

次に、送信処理（図１７Ｓ３０３）、受信処理（図１７Ｓ３０４）について詳述する。不確定情報を含むデータエントリをゲーム端末間で伝播させるにあたり、一度受信したデータエントリを再受信しない処理や自端末が発生源のデータエントリが他のゲーム端末を介して再び受信しない処理（以上をまとめて禁ループバック処理と呼ぶことにする）を施す。これは、既読の不確定情報や自端末が発生源であるデータエントリを再度プレイヤに提示する必要はないこと、また、そのような再受信を許可すると、データエントリの内容が短時間の内に改変され、前に受信した情報との整合性が取れず、プレイヤを混乱させる恐れがあることを防止するための処理である。

まず、送信処理を説明する。

図１８Ａは、シリアル番号を利用して禁ループバック処理を送信時に行うものである。図１８Ａの処理を行う場合、更に「転送履歴」というデータ項目が追加されたデータエントリが使用される。どの送信処理が適用されるかは予め決定されるので、その決定に合わせて適切なデータエントリを使用すればよい。

図１８Ａの処理を行う場合、データエントリを受信したゲーム端末は、自端末のユーザ情報２４を参照して得られる（そのとき挿入された記憶媒体等により決定される）シリアル番号と日時を受信したデータエントリの「転送履歴」に記録する。こうして、データエントリの「転送履歴」を見れば、そのデータエントリの伝播の経緯を把握することができる。

まず、不確定情報管理部１７が、これから送信しようとするデータエントリを不確定情報DBから読み出し、そのデータエントリの「転送履歴」を参照する。そして、その「転送履歴」に、ステップＳ３０１で取得した相手ゲーム端末に関するシリアル番号が含まれているかを調べる（Ｓ３３１）。そして、「転送履歴」にステップＳ３０１で取得したシリアル番号が含まれている場合（Ｓ３３１Ｙｅｓ）には、送信を行わず（Ｓ３３４）、「転送履歴」にステップＳ３０１で取得したシリアル番号が含まれていない場合（Ｓ３３１Ｎｏ）には、そのデータエントリを送信する（Ｓ３３３）。こうして、一度そのデータエントリを取得したプレイヤが同じ情報を目にすることを防止でき、混乱を防ぐことができる。

しかしながら、重複するデータエントリであっても、所定時間を経過していれば再びプレイヤに提示することにしてもよい。過去に受信したことのあるデータエントリを、十分な時間が経過してから再度受信したとしても、プレイヤはそのデータエントリによって混乱することはなく、逆にプレイヤに懐かしさを抱かせたり、忘れていた情報を思い出させる効果をもたらすためである。例えば、そのデータエントリがきっかけとなって注目されたゲーム内の町、人、イベント等の当時の状況をプレイヤは思い出したり、現状に対する好奇心が生じ、プレイヤは再度ゲーム内を探索するかもしれない。

そこで、Ｓ３３１Ｙｅｓの場合、以前に同じデータエントリを受信していることになるが、その前回の受信から所定時間が経過しているかを判定するステップ（Ｓ３３２）を設け、所定時間を経過している場合（Ｓ３３２Ｙｅｓ）、そのデータエントリを送信するようにしてもよい（Ｓ３３３）。ステップＳ３３２において、所定時間が経過していなければ（Ｓ３３２Ｎｏ）、まだ、プレイヤを混乱させる可能性が残されており、そのデータエントリの送信は行わない（Ｓ３３４）。ステップＳ３３２の所定時間は、例えば、６ヶ月等と設定することができる。

送信するデータエントリが複数ある場合には、不確定情報管理部１７は、図１８Ａの処理を繰り返し行う。送信するデータエントリの個数や、選択は、データエントリに含まれるデータ項目を利用して自由に設定することができる。従って、例えば、データエントリの「ID」に含まれる日付情報を利用して、最新のデータエントリを１０個送信するといった送信ポリシーをシステム設計者（システム運営者）が制御できる。

図１９は、図１８Ａの処理を具体化した例を説明するための図である。端末Ａは、データエントリを受信すると、そのデータエントリの「転送履歴」に現在端末Ａに挿入されているソフトＡのシリアル番号と日時を記録する。

転送履歴１９１は、端末Ａがそのデータエントリを受信した際の「転送履歴」を表したものである。転送履歴１９１によって示されるデータエントリは、先頭に記述されたシリアル番号からソフトＸが発生源であることがわかる。そして、次のシリアル番号がソフトＡであることから、発生源から直接ソフトＡが挿入された端末Ａに伝播されたデータエントリであることがわかる。

このとき、端末Ａが端末Ｂと通信可能状態になり、データエントリの送信を行う場合、端末Ａは端末Ｂのユーザ情報を取得して、端末Ｂに挿入されたソフトのシリアル番号を抽出する（図１７ステップＳ３０１）。そして、そのデータエントリの転送履歴に通信相手ゲーム端末である端末Ｂに挿入されたソフトＢのシリアル番号が、転送履歴１９１に記載されていないことから、端末Ａは端末Ｂにこのデータエントリを送信する（図１８ＡステップＳ３３１Ｎｏ→Ｓ３３３）。

このデータエントリを受信した端末Ｂは、端末Ｂに挿入されているソフトＢのシリアル番号と日付を「転送履歴」に記録する。転送履歴１９２は、端末Ｂがそのデータエントリを受信した際の「転送履歴」を表したものである。

このとき、端末Ｂが端末Ｃと通信可能状態になり、データエントリの送信を行う場合、そのデータエントリの転送履歴に通信相手ゲーム端末である端末Ｃに挿入されたソフトＣのシリアル番号が、転送履歴１９２に記載されていないことから、端末Ｂは端末Ｃにこのデータエントリを送信する。

転送履歴１９３は、上記と同様にして、端末Ｃがそのデータエントリを受信した際の「転送履歴」を表したものである。このとき、端末Ｃと端末Ａが通信可能状態になっても、そのデータエントリの転送履歴に通信相手ゲーム端末である端末Ａに挿入されたソフトＡのシリアル番号が、転送履歴１９２に記載されているため、端末Ｃは端末Ａにデータエントリを送信しない（図１８ＡステップＳ３３１Ｙｅｓ→Ｓ３３４）。

こうして、転送履歴に記載が残されたシリアル番号のソフトが挿入されたゲーム端末に対しては、データエントリを送信しないようにすることができる。なお、図１９において、端末Ｃから端末Ａに送信する際、所定時間が経過済みかを判定し、経過していれば（図１８ＡステップＳ３３２Ｙｅｓ）、そのデータエントリを送信するよう処理しても構わない。

図１８Ｂに戻り、続いてイベントフラグを利用して禁ループバック処理を送信時に行うものを説明する。図１８Ｂの処理は、イベントフラグが設定されたデータエントリに適用が可能である。

まず、ゲーム端末は、通信相手ゲーム端末のイベントDBを取得する（Ｓ３３５）。そして、不確定情報管理部１７が、これから送信しようとするデータエントリを不確定情報DBから読み出し、そのデータエントリの「イベントフラグ」を参照する。そして、その「イベントフラグ」がONであることを示す場合（例えば、値１が格納されている場合）、そのデータエントリの文章コードを使用して、ステップＳ３３５で取得した通信相手ゲーム端末のイベントDBの「オン・オフフラグ」の状態を確認する（Ｓ３３６）。通信相手ゲーム端末のオン・オフフラグがオフであれば（Ｓ３３６Ｎｏ）、これから送信するデータエントリに関するイベントが通信相手ゲーム端末にて未発生であることを意味するので、そのデータエントリは送信される（Ｓ３３３）。しかし、通信相手ゲーム端末のオン・オフフラグがオンであれば（Ｓ３３６Ｙｅｓ）、既に、通信相手ゲーム端末は、そのデータエントリを受信済みで対応するイベントが発生済みであることを意味し、そのデータエントリは送信されない（Ｓ３３４）。送信するデータエントリが複数ある場合には、不確定情報管理部１７は、図１８Ｂの処理を繰り返し行う。

図２０は、図１８Ｂの処理を具体化した例を説明するための図である。イベントDB２０１はある時点での端末ＡのイベントDBの状態を抜き出したものである。端末Ａでは、文章コードが１００１に対応するデータエントリを受信し、それに関連するイベントが発生していることが、イベントDB２０１からわかる。

このとき、端末Ａが端末Ｂと通信可能状態になり、文章コードが１００１であるデータエントリの送信を行う場合、端末Ａは端末ＢのイベントDB２０２を取得する（図１８ＢステップＳ３３５）。そして、端末ＢのイベントDB２０２で文章コードが１００１に対応するエントリの「オン・オフフラグ」がオフであることを確認すると、端末Ａは端末Ｂにこのデータエントリを送信する（図１８ＢステップＳ３３６Ｎｏ→Ｓ３３３）。

同様に、端末Ｂが端末Ｃと通信可能状態になり、このデータエントリの送信を行う場合にも、端末Ｂは端末ＣのイベントDB２０３を取得し、イベントDB２０３で文章コードが１００１に対応するエントリの「オン・オフフラグ」がオフであることを確認すると、端末Ｂは端末Ｃにこのデータエントリを送信する。

そして、端末Ｃと端末Ａが通信可能状態になると、端末Ｃは端末ＡのイベントDB２０１を取得し、イベントDB２０１で文章コードが１００１に対応するエントリの「オン・オフフラグ」がすでにオンであるため、端末Ｃは端末Ａにデータエントリを送信しない（図１８ＢステップＳ３３６Ｎｏ→Ｓ３３４）。

こうして、イベントDBの「オン・オフフラグ」に応じてデータエントリの送信を行うことで、既にデータエントリを受信してイベントが発生している場合には、データエントリが送信されず、同じデータエントリの重複受信を避けることができる。

次に、受信処理を説明する。

図２１Ａは、各データエントリを識別するID（図５Ａ参照）を利用して禁ループバック処理を受信時に行うものである。不確定情報管理部１７は、データエントリを受信すると、受信したデータエントリの「ID」と同じIDを持つデータエントリが不確定情報DBに格納済みでないかを確認する（Ｓ３４１）。そして、まだ格納されていなければ（Ｓ３４１Ｎｏ）、受信したデータエントリを不確定情報DBに格納し（Ｓ３４３）、既に格納されていれば（Ｓ３４１Ｙｅｓ）、受信したデータエントリを破棄する（Ｓ３４４）。こうして、一度そのデータエントリを取得したプレイヤが同じ情報を目にすることを防止でき、混乱を防ぐことができる。

しかし、重複するデータエントリであっても、所定時間を経過していれば再びプレイヤに提示することにしてもよい。この理由は、図１８ＡステップＳ３３２の送信処理のときと同じく、プレイヤに懐かしさを抱かせたり、忘れていた情報を思い出させる効果をもたらすためである。

そこで、Ｓ３４１Ｙｅｓの場合、以前に同じデータエントリを受信していることになるが、その前回の受信から所定時間が経過しているかを判定するステップ（Ｓ３４２）を設け、所定時間を経過している場合（Ｓ３４２Ｙｅｓ）、そのデータエントリを格納するようにしてもよい（Ｓ３４３）。ステップＳ３４２において、所定時間が経過していなければ（Ｓ３４２Ｎｏ）、まだ、プレイヤを混乱させる可能性が残されており、そのデータエントリを破棄する（Ｓ３４４）。ステップＳ３４２の所定時間は、例えば、６ヶ月等と設定することができる。

受信するデータエントリが複数ある場合には、不確定情報管理部１７は、図２１Ａの処理を繰り返し行う。

図２１Ｂは、シリアル番号を利用して禁ループバック処理を受信時に行うものである。図２１Ｂの処理を行う場合も図１８Ａの説明で紹介した「転送履歴」というデータ項目が追加されたデータエントリが使用される。

まず、不確定情報管理部１７が、受信したデータエントリの「転送履歴」を参照する。そして、その「転送履歴」に、受信端末のユーザ情報に含まれるシリアル番号が含まれているかを調べる（Ｓ３４５）。そして、「転送履歴」に自端末のシリアル番号が含まれている場合（Ｓ３４５Ｙｅｓ）には、受信したデータエントリを破棄し（Ｓ３３４）、「転送履歴」に自端末のシリアル番号が含まれていない場合（Ｓ３４５Ｎｏ）には、自端末のシリアル番号と日時を受信したデータエントリの「転送履歴」に記録すると共に、そのデータエントリを格納する（Ｓ３４３）。こうして、一度そのデータエントリを取得したプレイヤが同じ情報を目にすることを防止でき、混乱を防ぐことができる。

しかしながら、重複するデータエントリであっても、所定時間を経過していれば再びプレイヤに提示することにしてもよい。そこで、Ｓ３４５Ｙｅｓの場合、以前に同じデータエントリを受信していることになるが、その前回の受信から所定時間が経過しているかを判定するステップ（Ｓ３４２）を設け、所定時間を経過している場合（Ｓ３４２Ｙｅｓ）、そのデータエントリを格納するようにしてもよい（Ｓ３４３）。ステップＳ３４２において、所定時間が経過していなければ（Ｓ３４２Ｎｏ）、まだ、プレイヤを混乱させる可能性が残されており、そのデータエントリを破棄する（Ｓ３４４）。ステップＳ３４２の所定時間は、例えば、６ヶ月等と設定することができる。

受信するデータエントリが複数ある場合には、不確定情報管理部１７は、図２１Ｂの処理を繰り返し行う。

図２２は、図２１Ｂの処理を具体化した例を説明するための図である。転送履歴２２１は、端末Ａがあるデータエントリを端末Ｂに送信する際の転送履歴を表したものである。端末Ａは、転送履歴の先頭に記述されたシリアル番号からソフトＸが発生源であるデータエントリを、発生源から直接受信し、自端末に挿入されたソフトＡのシリアル番号と受信日付を記録したことがわかる。

端末Ｂは受信したデータエントリの「転送履歴」に端末Ｂに挿入されたソフトＢのシリアル番号が含まれていないことから、端末Ｂに挿入されているソフトＢのシリアル番号と日付を「転送履歴」に記録して、受信したデータエントリを端末Ｂの不確定情報DBに格納する（図２１ＢステップＳ３４５Ｎｏ→Ｓ３４３）。

転送履歴２２２は、端末Ｂがそのデータエントリを端末Ｃに送信する際の転送履歴を表したものである。端末Ｃは受信したデータエントリの「転送履歴」に端末Ｃに挿入されたソフトＣのシリアル番号が含まれていないことから、端末Ｃに挿入されているソフトＣのシリアル番号と日付を「転送履歴」に記録して、受信したデータエントリを端末Ｃの不確定情報DBに格納する。

転送履歴２２３は、端末Ｃがそのデータエントリを端末Ａに送信する際の転送履歴を表したものである。端末Ａは受信したデータエントリの「転送履歴」に端末Ａに挿入されたソフトＡのシリアル番号が含まれていることから、そのデータエントリを破棄する（図２１ＢステップＳ３４５Ｙｅｓ→Ｓ３４４）。

こうして、転送履歴に記載が残されたシリアル番号のソフトが挿入されたゲーム端末に対しては、データエントリを受信しないようにすることができる。なお、図２２において、端末Ｃから端末Ａに送信する際、所定時間が経過済みかを判定し、経過していれば（図２１ＢステップＳ３４２Ｙｅｓ）、そのデータエントリを格納するよう処理しても構わない。

図２１Ｃに戻り、続いてイベントフラグを利用して禁ループバック処理を受信時に行うものを説明する。図２１Ｃの処理は、イベントフラグが設定されたデータエントリに適用が可能である。

まず、不確定情報管理部１７は、受信したデータエントリに含まれる文章コードを取得し、自端末のイベントDBでその文章コードに対応するエントリの「オン・オフフラグ」を参照する（Ｓ３４６）。オン・オフフラグがオフであれば（Ｓ３４６Ｎｏ）、受信したデータエントリに関するイベントは受信端末において未発生であることを意味するので、そのデータエントリは不確定情報DBに格納されると共に、イベントDBにて対応するエントリの「オン・オフフラグ」がオンにされ、イベントが発動する（Ｓ３４７）。しかし、オン・オフフラグがオンであれば（Ｓ３４６Ｙｅｓ）、既に、そのデータエントリを受信済みで対応するイベントが発生済みであることを意味し、そのデータエントリは破棄される（Ｓ３４４）。

図２３は、図２１Ｃの処理を具体化した例を説明するための図である。イベントDB２３１はある時点での端末ＡのイベントDBの状態を抜き出したものである。端末Ａでは、文章コードが１００１に対応するデータエントリを受信し、それに関連するイベントが発生していることが、イベントDB２３１からわかる。

このとき、端末Ａが端末Ｂと通信可能状態になり、文章コードが１００１であるデータエントリを端末Ｂで受信する場合、端末Ｂは自端末のイベントDB２３２を取得し、端末ＢのイベントDB２３２で文章コードが１００１に対応するエントリの「オン・オフフラグ」がオフであることを確認すると、このデータエントリを格納して、文章コードが１００１に対応するエントリをオンに更新する（図２１ＣステップＳ３４６Ｎｏ→Ｓ３４７）。「オン・オフフラグ」がオンになったことにより、端末Ｂにて文章コードが１００１に対応するイベントが発生する。

同様に、端末Ｂが端末Ｃと通信可能状態になり、このデータエントリを端末Ｃで受信する場合にも、端末Ｃは自端末のイベントDB２３３を取得し、イベントDB２３３で文章コードが１００１に対応するエントリの「オン・オフフラグ」がオフであることを確認すると、端末Ｃはこのデータエントリを格納する。

そして、端末Ｃと端末Ａが通信可能状態になり、端末Ａでこのデータエントリを受信する場合、端末ＡはイベントDB２３１で文章コードが１００１に対応するエントリの「オン・オフフラグ」がすでにオンであるため、端末Ａはデータエントリを破棄する（図２１ＣステップＳ３４６Ｎｏ→Ｓ３４４）。

こうして、イベントDBの「オン・オフフラグ」に応じてデータエントリの受信を行うことで、既にデータエントリを受信してイベントが発生している場合には、データエントリが送信されず、同じデータエントリの重複受信を避けることができる。

また、以上の説明では、データエントリが重複して格納されるのを防止するため、不確定情報DBへの格納前に処理を行っているが、一旦すべてのデータエントリを不確定情報DBに格納するものの、転送履歴、イベントフラグ等の設定に応じてプレイヤへの表示を制限することもできる。その場合、図２１に示される受信時の処理において、ステップＳ３４３の「格納する」を「表示する」、ステップＳ３４４の「破棄する」を「表示しない」と読み替えた処理を表示前に行えばよい。他にも、所定の日時を過ぎていれば表示しないといった設定も可能である。

続いて、受信したデータエントリに対する変更処理について説明する。これは、図１２のステップＳ６に含まれる。

図２４Ａは、変更ルールDB２３に格納されたルールに基づき、データエントリの変更が行われる場合を説明するフローチャートである。不確定情報管理部１７は、受信したデータエントリの正確度を減らした結果所定の閾値未満になったとき、変更ルールDB２３に基づき、変更後の定型文の「文章コード」と「ワード」を決定する（Ｓ６０１）。

例えば、図１０に示す変更ルールDB２３において、受信したデータエントリの文章コードが００１であり、正確度が６０未満になった場合、文章コードは１００に変更されると共にワードの項目として「ライバル」が引き継がれた不確定情報に変更される。

そして、不確定情報管理部１７は、受信したデータエントリの「文章コード」と「ワード」を、ステップＳ１で決定された「文章コード」と「ワード」に更新して（Ｓ６０２）、ステップＳ１に進み、不確定情報DB２１にそのデータエントリを格納する。上記例でいうと、図１０の変更ルールDBに基づき、変更前、“タロウはジロウをライバルと思っているらしい”という不確定情報に対応するデータエントリ（つまり、文章コードが００１、ワードが「タロウ、ジロウ」である）が、変更後は、“ジロウをライバルと思っている人間がいるらしい”という不確定情報に対応するデータエントリ（つまり、文章コードが１００、ワードが「ジロウ」である）となる。

図２４Ｂは、定型文を別の定型文に変更して、データエントリの変更が行われる場合を説明するフローチャートである。不確定情報管理部１７は、受信したデータエントリの正確度を減らした結果所定の閾値未満になったとき、受信したデータエントリの文章コードに対応する定型文で使用されるワードの項目を特定する（Ｓ６１１）。例えば、受信したデータエントリの文章コードが００４であれば、図３の文章DB２５を参照し、ワードの項目として「敵、アイテム」が使用されていることがわかる。

次に、不確定情報管理部１７は、ステップＳ１で特定されたワードの項目と同じワードの項目を持つ定型文を文章DBから選択する（Ｓ６１２）。すると、その定型文に対応する「文章コード」が決定される。例えば、上記と同じ「敵、アイテム」をワードの項目として持つ定型文として、図３の文章DB２５を参照すれば、文章コードが００６の定型文が挙げられる。

そして、受信したデータエントリの「文章コード」を、ステップＳ２で選択された定型文の「文章コード」に更新して（Ｓ６１３）、ステップＳ１に進み、不確定情報管理部１７は、不確定情報DB２１にそのデータエントリを格納する。上記例でいえば、変更前、“大鬼を倒すと巻物が手に入るらしい”という不確定情報に対応するデータエントリ（つまり、文章コードが００４、ワードが「大鬼、巻物」である）が、変更後は、“大鬼は巻物を使うと倒せるらしい”という不確定情報に対応するデータエントリ（つまり、文章コードが００６に変更）となる。

図２５は、図２４Ａ，図２４Ｂのように定型文が別の定型文に変更される場合の画面例である。不確定情報の収集は、例えば、ゲーム起動時に行われる（画面７１）。この場合、ゲーム端末１への電源投入時に付近に通信可能なゲーム端末１があるか判定が行われる（図１２Ｓ２）。そして、データエントリを受信すると、ゲーム進行管理部１５は、その旨を表示する（画面７３）。ここでは、不確定情報のデータエントリを噂と表現し、プレイヤに通知している。

不確定情報の収集は、ゲームプレイ中に行うこともできる（画面７２）。例えば、図１４の画面６３のゲーム内メニュー１４１にて、「不確定情報取得」なる項目が選択された場合に画面７２が表示される。画面７２にて、「はい」が選択されると、画面７３へ進む。

図２５において、この先２手に分かれて表示されるが、左側の列が、データエントリの変更前、右側の列が、ゲーム端末間をデータエントリが伝播する過程でデータエントリが変更された後の様子である。不確定情報のデータエントリを受信すると、受信日、通信相手の名前、タイトルがリスト状に表示される（画面７４、画面７６）。そして、そのリストから確認したい不確定情報を選択すれば、その内容が表示される（画面７５、画面７７）。図２５により、変更前と、変更後では、データエントリの文章コード、ワードの変更に応じて、表示される文章が違うことがわかる。

図２４に戻り、説明を続ける。図２４Ａ、図２４Ｂは、定型文毎変更するものだが、図２４Ｃは、定型文で使用されるワードを置換して、データエントリの変更が行われる場合を説明するフローチャートである。

図２４Ｃでは、不確定情報管理部１７が、受信したデータエントリの正確度を減らした結果所定の閾値未満になったとき、受信したデータエントリの文章コードに対応する定型文を特定し、その定型文で使用されるワードの項目を選択する（Ｓ６２１）。例えば、受信したデータエントリの文章コードが５０１であれば、図３の文章DB２５を参照し、ワードの項目として「主語、場所、敵、アイテム」が使用されていることがわかり、ここでは、「場所」を選択する。

ワードの項目の選択は、例えば、不確定情報管理部１７が、乱数を発生させ、その乱数をワードの項目数で割った余りを算出し、そのあまりに応じて対応する項目を選択すればよい。上述した例では、項目数が４であるので、乱数を４で割った余りが０であれば、「主語」を選択し、１であれば、「場所」を選択し、２であれば、「敵」を選択し、３であれば「アイテム」を選択する。なお、ステップＳ６２１において、不確定情報管理部１７が、一度に置換するワードを複数個選択してもよい。

次に、不確定情報管理部１７は、図１１のワード候補DB２６から、ステップＳ６２１で選択されたワード項目に対応する「置換後のワード」を選択する（Ｓ６２２）。例えば、図１１の「場所」に挙げられた４つのワード候補（鬼ヶ島、竜宮城、寒村、港町）の中から「竜宮城」を選択する。ステップＳ６２２での選択も、一例としてステップＳ６２１で説明した乱数による選択を行えばよい。そして、不確定情報管理部１７は、受信したデータエントリのワードのうち、ステップＳ６２１で選択されたワードの項目だけ、ステップＳ６２２で選択された「置換後のワード」に置き換えてワードを更新し（Ｓ６２３）、ステップＳ１に進み、不確定情報DB２１にそのデータエントリを格納する。

具体的には、変更前、“タロウは鬼ヶ島で大鬼を倒して巻物を手に入れたらしい”という不確定情報に対応するデータエントリ（つまり、文章コードが５０１、ワードが「タロウ、鬼ヶ島、大鬼、巻物」である）が、変更後は、“タロウは竜宮城で大鬼を倒して巻物を手に入れたらしい”という不確定情報に対応するデータエントリ（つまり、ワードが「タロウ、竜宮城、大鬼、巻物」に変更）となる。

図２６は、ワードが置換される場合の画面例である。最初画面７８に示される不確定情報が、ゲーム端末間での伝播の過程で、画面７９→画面８０→画面８１のように変化していく。図２６においては、「信憑性」という数字が表示されているが、これは、データエントリの「正確度」（図５Ａ参照）とは別に、ここでは一例として（受信限度回数＋１）＊２５により簡単に算出される数値である。この信憑性のような数字をプレイヤに参考値として表示してもよい。

ここで、画面７９→画面８０においては、データエントリの内容は変更されないものの、信憑性は減じられる。画面８１では、ワードの項目「アイテム」も置換され、より不確定さが増している。

図２４に戻り説明を続ける。図２４Ｄは、定型文で使用されるワードを一部伏字にして、データエントリの変更が行われる場合を説明するフローチャートである。不確定情報管理部１７は、受信したデータエントリの正確度を減らした結果所定の閾値未満になったとき、受信したデータエントリの文章コードに対応する定型文を特定し、その定型文で使用されるワードの項目を選択する（Ｓ６３１）。例えば、受信したデータエントリの文章コードが５０１であれば、図３の文章DB２５を参照し、ワードの項目として「主語、場所、敵、アイテム」が使用されていることがわかり、ここでは、「場所」を選択する。ステップＳ６３１での選択も、ステップＳ６２１で説明した乱数による選択を行えばよい。なお、ステップＳ６３１において、不確定情報管理部１７が、伏字にするワードを複数個選択してもよい。

次に、不確定情報管理部１７は、その選択されたワードの項目に対応するワードの一部を伏字に変換する（Ｓ６３２）。例えば、「場所」として「鬼ヶ島」という値が格納されている場合、その３文字のうち２文字を伏字（ここでは、米印として表示する）に変換する。伏字にする文字数や位置は任意でよい。そして、不確定情報管理部１７は、受信したデータエントリのワードのうち、ステップＳ６３１で選択されたワードの項目だけ、ステップＳ６３２で一部伏字に変換されたワードに置き換えてワードを更新し（Ｓ６３３）、ステップＳ１に進み、不確定情報DBにそのデータエントリを格納する。

具体的には、変更前、“タロウは鬼ヶ島で大鬼を倒して巻物を手に入れたらしい”という不確定情報に対応するデータエントリ（つまり、文章コードが５０１、ワードが「タロウ、鬼ヶ島、大鬼、巻物」である）が、変更後は、“タロウは※※島で大鬼を倒して巻物を手に入れたらしい”という不確定情報に対応するデータエントリ（つまり、ワードが「タロウ、※※島、大鬼、巻物」に変更）となる。

図２７は、ワードが一部伏字にされる場合の画面例である。最初画面８２に示される不確定情報が、ゲーム端末間での伝播の過程で、画面８２→画面８３→画面８４のように変化していく。図２７においては、信憑性という数字が表示されているが、これは、図２６に示されるものと同じである。画面８２では、画面８５より伏字の置換が進み、より不確定さを増している。

以上に説明したデータエントリの変更処理によって、受信したデータエントリの正確度が所定の閾値を下回ると、別の定型文に対応する文章コードを選択したり、受信したデータエントリに使用されるワードを一部置換したり、一部を伏字にすることによって、データエントリが不確定さをますように変更されていく。こうして、不確定情報の発生源に時間的、空間的に近いゲーム端末には、ある程度正確な情報が伝達され、時間的、距離的に遠いゲーム端末には、不明確さを増した情報が届けられる。こうして、さまざまな不確定情報が真偽が定かでない状態で混在することになり、プレイヤの不確定情報に対する好奇心を刺激し、よりゲームに対する興味を引き、かつ持続させることができる。

なお、第一の実施形態において、正確度は、例えば、初期値を１００とし、受信の度に所定数（例えば、２０）ずつ減らされる値として定義されるが、図２６において説明した信憑性同様、転送回数情報（「受信限度回数」等）を基に算出される値としてもよい。また、受信したデータエントリの変化の度合いに応じて算出される値でもよい。例えば、データエントリの変化の過程で一部が伏字になる場合であれば、（伏字の数／文章に含まれる文字数）＊１００等として算出することができる。

以上第一の実施形態によれば、情報端末間でデータエントリ（不確定情報）が伝播される過程で、正確度が減っていき、正確度が所定の閾値未満の場合、データエントリが変更されるので、情報がより不確定なものとなり、それを取得した利用者がその情報の真偽に非常に関心を持つことになる。そして、情報の真偽を確認すべく、情報端末で実行されるプログラムに対する興味を惹きつけることができる。また、データエントリの正確度は、送信側の情報端末で減らされても、受信側の情報端末で減らされてもよい。

プレイヤは不確定情報を入手することによって、例えば、そのプレイヤ自身がゲーム内で行ったことのない場所に関するヒント（場所の存在や場所への行き方等）を入手する。こうして、プレイヤが１人では攻略しきれない場所まで到達することができ、ゲームをより深く楽しむことができる。また、自分もゲーム内でその場所へ行ってみようという好奇心をプレイヤに抱かせることができ、ゲームをより長い時間遊んでもらえる効果がある。また、他のプレイヤの進捗状況を不確定情報として入手する場合、他のプレイヤに遅れを取りたくないプレイヤに対しゲームを遊ぶ動機付けを与える。また、ゲーム内でのライバルや仲間を設定でき、こうしたプレイヤを現実世界で探すという行動を動機付けることで、ゲームをより長く面白く楽しんでもらうことにつながる。また、こうした現実世界でのプレイヤの行動に伴い、ゲーム端末が移動し、より不確定情報が伝播しやすくなる。

また、図５に示される不確定情報DBに格納されるデータエントリに使用するデータ項目に応じて、内容を変化させたくない情報（例えば、メーカーが公式に発表する公式情報等）を、内容を変化させる情報と合わせて伝達させたり、同じデータエントリが情報端末間でループすることを防止したり、データエントリが拡散される範囲や回数、有効期限を設定してデータエントリが無限に拡散されることを防止したり、ある期間だけ有効なデータエントリを作成してプロモーションやキャンペーン情報として使用することができる。

次に、第二の実施形態の情報端末の動作について説明する。

図２８は、第二の実施形態における情報伝達システムの構成図である。第二の実施形態では、インターネット７を介して、サーバ６と複数の情報中継端末８を接続し、サーバ６に格納された不確定情報を、情報中継端末８を介してゲーム端末１に伝播させる。プレイヤは、情報中継端末８に表示されるメニューを操作して、サーバ６に不確定情報の取得要求を送信する。そして、情報中継端末８は、サーバ６から送信される不確定情報を、取得要求を送信したプレイヤのゲーム端末１に転送するものである。

第二の実施形態においては、サーバを利用することで、各ゲーム端末の不確定情報を集中することができる。また、サーバは唯一データエントリが変化しない確定情報をゲーム端末に配信することが可能な存在であり、プロモーション情報や、キャンペーン等の実行を可能にし、よりゲームを面白くすることができる。また、ゲーム端末の構成および動作は第一の実施形態と同じであるので説明は省略する。

図２９は、情報中継端末８の構成を示すブロック図である。情報中継端末８は、入力部３１、表示部３２、送受信部３３、制御部３４、記憶部４０を有し、制御部３４は、表示管理部３５、参加端末管理部３６を含む。本実施形態においては、表示管理部３５、参加端末管理部３６は、制御部３４に備えられた図示省略されたCPUにより実行されるプログラムモジュールであるが、ハードウェア回路により実現することもできる。

表示管理部３５は、情報中継端末８を操作するための画面を表示部３２に表示し、入力部３１を介してプレイヤより入力される命令を受け、その命令に応じた画面を出力する。入力部３１は、例えば、情報中継端末８に備えられた図示しないキーボード、タッチパネル、ボタン等が該当し、表示部３２は、例えば、図示しない液晶画面が該当する。入力部３１、表示部３２はプレイヤとのインタフェースとして機能する。

参加端末管理部３６は、情報中継端末８と通信可能なゲーム端末に関する情報が格納される参加端末データベース（参加端末DB）４１を管理する。参加端末管理部３６は、参加端末DB４１に格納されたゲーム端末１のうち、情報中継端末８の通信圏外に移動したゲーム端末１に関する情報を削除し、参加端末DB４１を最新の状態に更新する。参加端末DB４１には、プレイヤのユーザ情報の他、情報中継端末８がサーバ６から送信された不確定情報を転送する際に必要なゲーム端末１のアドレス（IP(Internet
Protocol)アドレス、MAC(Media Access Control)アドレス等）が格納される。

送受信部３３は、インターネット７に接続されたサーバ６、情報中継端末８に集まるゲーム端末１と通信する通信機能を有している。これは、情報中継端末８に内蔵されるか若しくは外付けされた通信アンテナを介して、無線通信機能により実現されてもよいし、ゲーム端末１とは無線通信を行い、サーバ６とはケーブルで接続された有線通信が行われてもよい。

送受信部３３は、無線通信可能なゲーム端末１がある場合、そのユーザ情報を取得してアドレスと共に参加端末管理部３６に出力し、また、プレイヤが入力部３１を介して入力する不確定情報の取得要求をサーバ６に送信する。

記憶部４０には、制御プログラム、参加端末DB４１、中継端末識別情報４２、その他情報中継端末８で行われる処理に必要なデータが格納される。記憶部４０は、例えば、バッテリーバックアップされたRAM、フラッシュロム、ハードディスク等の記憶手段である。中継端末識別情報は、例えば、情報中継端末８がサーバ６へゲーム端末のユーザ情報等を送信する際に必要な情報中継端末８のアドレス（IP(Internet
Protocol)アドレス、MAC(Media Access Control)アドレス等）が格納される。

図３０Ａは、第二の実施形態におけるユーザ情報のデータ構成例である。第二の実施形態においては、サーバが複数のゲームに関する不確定情報を提供するため、ゲーム端末が取得する不確定情報が、現在そのゲーム端末で実行中のゲームと無関係である可能性がある。そこで、図４に示すユーザ情報に含まれるデータ項目に加えて、ゲーム端末で実行中のゲームプログラムを特定する「ゲームタイトル」が設けられる。

図４と重複する項目についての説明は省略する。「ゲームタイトル」により、各不確定情報がどのゲームに関するものかを特定することができ、ゲーム端末は、受信した不確定情報が自端末で実行中のゲームと無関係なものである場合、受信した不確定情報を破棄することができる。

図３０Ｂは、第二の実施形態における参加端末DB４１のデータ構成例である。図３０の参加端末DB４１には、図３０Ａのユーザ情報に含まれるデータ項目に加えて、「IPアドレス」が含まれる。「IPアドレス」は、情報中継端末８がゲーム端末１からユーザ情報を取得した際のパケットから取得される送信元IPアドレスを記憶したものである。「IPアドレス」は、サーバ６から送信される不確定情報をゲーム端末１に転送する際に参照される。

図３１は、サーバ６の構成を示すブロック図である。サーバ６は、入力部５１、表示部５２、送受信部５３、制御部５４、記憶部６０、を有し、制御部５４は、表示管理部５５、認証管理部５６、不確定情報管理部５７を含む。本実施形態においては、表示管理部５５、認証情報管理部５６、不確定情報管理部５７は、制御部５４に備えられた図示省略されたCPUにより実行されるプログラムモジュールであるが、ハードウェア回路により実現することもできる。

表示管理部５５は、サーバ６を操作するための画面を表示部５２に表示し、入力部５１を介してサーバ管理者より入力される命令を受け、その命令に応じた画面を出力する。入力部５１は、例えば、図示しないキーボードが該当し、表示部５２は、例えば、図示しない液晶画面が該当する。入力部５１、表示部５２はサーバ管理者とのインタフェースとして機能する。

認証情報管理部５６は、不確定情報の取得要求を送信した情報中継端末８の認証に使用する中継端末認証データベース（中継端末認証DB）６３及び取得要求を行ったプレイヤを認証するユーザ認証データベース（ユーザ認証DB）５２を管理する。中継端末認証DB６３には、予め入力部５１を介して、正規の情報中継端末８を特定するアドレス（IPアドレス、MACアドレス等）が蓄積される。

また、ユーザ認証DB６２には、予め、サーバ６の不確定情報DBに格納されたデータエントリのダウンロードを許可するユーザのユーザ情報に含まれるシリアル番号（図４参照）が蓄積される。不確定情報の取得要求に対し、これらのDBに格納された情報が照合され、不確定情報DB６１に格納されたデータエントリの送信が許可されるか判断される。

不確定情報管理部５７は、情報中継端末８を介して受信する、ゲーム端末１に格納されたデータエントリに加え、入力部５１を介して入力される確定情報（図５の「種類」の説明を参照）と不確定情報を不確定情報DB６１に格納する。ここでの不確定情報は、ゲーム端末間で伝播する過程で内容が変化するデータエントリ同様の形式で不確定情報DBに格納される。また、有効期限切れ等で不要になったデータエントリを削除して、不確定情報DB６１を管理する。情報中継端末８より情報の取得要求を受信すると、不確定情報管理部５７は、要求の種類に応じて、不確定情報あるいは確定情報、またはその両方を送受信部５３に出力する。

送受信部５３は、インターネット７に接続された情報中継端末８と通信する通信機能を有している。これは、サーバ６に内蔵されるか若しくは外付けされた通信アンテナを介して、無線通信機能により実現されてもよいし、ケーブルで接続された有線通信が行われてもよい。

記憶部６０には、図示しない制御プログラム、ユーザ認証DB６２、中継端末認証DB６３、不確定情報DB６１、その他サーバ６で行われる処理に必要なデータが格納される。記憶部６０は、例えば、バッテリーバックアップされたRAM、フラッシュロム、ハードディスク等の記憶手段である。

図３２は、第二の実施形態における不確定情報DB６１のデータ構成例である。サーバには複数のゲームプログラムに関する不確定情報が格納されるため、図３２の不確定情報DBには、第一の実施形態における不確定情報DB（図５）に含まれるデータ項目に加えて、各不確定情報がどのゲームプログラムに関するものかを特定する「ゲームタイトル」が設けられる。図５と重複するデータ項目に関する説明は省略する。

サーバが複数種類のゲームプログラムに関する不確定情報を格納する場合、図３０Ａ、図３２で説明するように、「ゲームタイトル」のデータ項目をユーザ情報、不確定情報DBで加える方法の他に、「ゲームタイトル」を追加せずに、不確定情報がどのゲームプログラムに関するものかを特定する方法もある。それには、シリアル番号を使用する。

図３３は、シリアル番号とゲームタイトルの対応関係が格納されるソフト管理テーブルのデータ構成例である。ソフト管理テーブルは、サーバの記憶部６０に格納される。予め、第二の実施形態においては、ゲームタイトル毎に割り振られるシリアル番号が図３３に示される区分に従うよう（例えば、ゲームメーカ等により製品出荷時に）設定されており、従って、シリアル番号により、ゲーム端末で実行されるゲームプログラムを特定することができる。各データエントリの「ID」には、シリアル番号が埋められており（図３２参照）、ユーザ情報、不確定情報DBにおいて、「ゲームタイトル」を設けることなく、使用中のゲームプログラムを特定することができる。

図３４は、ユーザ認証DB６２のデータ構成例である。図３４では、サーバ６に格納された不確定情報DBのデータエントリのダウンロードが許可されたユーザの「シリアル番号」（図４のユーザ情報参照）が格納される。

図３５は、中継端末認証DB６３のデータ構成例である。図３５では、正規の情報中継端末８のIPアドレスが格納されるが、情報中継端末８を一意に特定できる別の識別情報が用いられてもよい。

図３６は、第二の実施形態におけるサーバ６と情報中継端末８の動作を説明するタイムチャートである。第二の実施形態においても、ゲーム端末間での情報の伝播は行われるが、それは、第一の実施形態に示したのと同じ動作であるため、ここでは情報中継端末とサーバの動作を中心に説明する。

まず、サーバ６では不確定情報DBにデータエントリが蓄積される（Ｓ４１）。サーバ６の不確定情報DB６１へのデータエントリの蓄積は、第一の実施形態におけるゲーム端末１へのデータエントリの蓄積と同様、サーバ６において生成された不確定情報が格納される場合と、情報中継端末８を介してゲーム端末から受信したデータエントリを格納する場合と２種類ある。前者については、図１３Ｃで説明した処理がサーバ６の不確定情報管理部５７により行われる。後者については、データエントリの受信時に割り込み的にステップＳ４１が行われ、その後再び元の処理に制御が戻される。

一方、情報中継端末８では通信圏内のゲーム端末１に関する情報が参加端末DB４１に登録される（Ｓ３１）。送受信部３３（情報中継端末）は、情報中継端末８とゲーム端末が互いに通信可能圏内に入ると送受信を行い、ゲーム端末１からはユーザ情報（図３０Ａ参照）を含むIPパケットが情報中継端末８に送信される。送受信部３３（情報中継端末）は、受信したIPパケットからユーザ情報と発信元アドレスを抽出して、参加端末管理部３６に出力し、参加端末管理部３６は参加端末DB４１にそれらを格納する。こうして、情報中継端末８と通信可能なゲーム端末に関する情報が参加端末DB４１に蓄積される。

情報中継端末８では、表示部３２を介してプレイヤが利用可能なサービスに対するメニューを表示管理部３５が表示しており、このメニュー画面をプレイヤが入力部３１を介して操作することによって、情報中継端末８は、自分のプレイするゲームに関する不確定情報、確定情報の取得要求をサーバに送信する。そこで、表示管理部３５は、入力部３１よりサーバ６に格納された情報の取得要求が入力されたかを判定する（Ｓ３２）。サーバ６に格納された情報の取得要求が入力された場合、情報中継端末８は、入力された取得要求、参加端末DB４１に格納された要求元のゲーム端末１のユーザ情報と、そのゲーム端末１の不確定情報DBに格納されたデータエントリと、情報中継端末８の識別情報４２をサーバ６に送信する（Ｓ３３）。

サーバ６では、サーバ６に格納された情報の取得要求を受信すると（Ｓ４２Ｙｅｓ）、その後受信するデータエントリを割り込み処理として不確定情報DBに格納すると共に、受信した識別情報に基づく情報中継端末認証を行う（Ｓ４３）。ここでは、認証管理部５６が、受信したパケットに含まれる発信元IPアドレスと一致するIPアドレスが、中継端末認証DB６３に格納されているか否かを判定すればよい。一致する番号が格納されていない場合（Ｓ４３Ｎｏ）、正規の情報中継端末８を介して送信された情報取得要求ではないため、エラー処理が行われる（Ｓ５１）。ステップＳ５１のエラー処理では、例えば、不正な情報取得を要求してきた情報中継端末８のIPアドレス等がログとして記録される。

ステップＳ４３で情報中継端末認証に成功すると（Ｓ４３Ｙｅｓ）、次に、ユーザ情報に基づくユーザ認証を行う（Ｓ４４）。認証情報管理部５６は、受信したユーザ情報からシリアル番号を抽出し、ユーザ認証DB６２に格納されたシリアル番号に一致するものがあるかを検索する。一致するものがない場合は（Ｓ４４Ｎｏ）、登録外のユーザによる取得要求であり、エラー処理が行われる（Ｓ５２）。ステップＳ５２のエラー処理では、例えば、サーバ６が情報中継端末８に未登録エラーを通知し、情報中継端末８が、ユーザが未登録であることを表示部３２に表示し、更に、ユーザに登録を促す画面を表示する。

ユーザ認証に成功すると（Ｓ４４Ｙｅｓ）、サーバ６は取得要求に応じて情報を情報中継端末８に送信し（Ｓ４５）、ステップＳ４２に戻り、情報中継端末８からの他の取得要求に備えて待機する。そして、情報中継端末８は、サーバ６より送信される情報を対応するゲーム端末１に送信し（Ｓ３４）、ステップＳ３２に戻り、プレイヤからサーバ６に格納された情報の新たな取得要求が入力されるのを待つ。

また、図３６のフローチャートでは図示省略されているが、第二の実施形態においては、サーバが複数種類のゲームプログラムに関する不確定情報を提供する関係上、ゲーム端末が受信する不確定情報が必ずしもそのゲーム端末で実行されるゲームに関するものでない場合もありうる。そこで、ステップＳ３４で送信される情報を受信するゲーム端末において、受信する不確定情報の「ゲームタイトル」と、自端末のユーザ情報に含まれる「ゲームタイトル」を参照し、一致しない場合には、その不確定情報を破棄する処理を行ってもよい。

また、図３３で説明したように、「ゲームタイトル」を用いずに、シリアル番号によって不確定情報がどのゲームプログラムに関するものかを特定する場合には、まずサーバが、ステップＳ３３で送信されるユーザ情報に含まれる「シリアル番号」から図３３に示すソフト管理テーブルによりゲームタイトルを特定する。そして、ステップＳ４５で不確定情報を送信する際に、サーバが、送信予定の不確定情報の「ID」から抽出されるシリアル番号が、ゲーム端末で実行中の（特定された）ゲームタイトルにソフト管理テーブルにて対応付けられる番号帯に含まれるものだけを情報中継端末に送信するようにしてもよい。「シリアル番号」に基づき、サーバが送信する不確定情報を制限することで、ゲーム端末が自端末で実行されるゲームプログラムと無関係な不確定情報を受信することが防止される。

図３７は、サーバ６に格納された情報をゲーム端末１にダウンロードする様子を説明するための情報中継端末８の画面例である。情報中継端末８の表示部３２には、まずサービス提供対象のゲームタイトルが表示される（画面３７１）。画面３７１には、情報中継端末８の名前と４つのゲームタイトルが表示される。ここでは第二の実施形態を利用するゲームとして、メニュー１（Ａの冒険）が選択されるとする。すると、次に、「Ａの冒険」に対して提供中のサービス一覧が表示される（画面３７２）。

次に、サーバ６に格納された情報をダウンロードするため、メニュー５（うわさＧＥＴ！）が選択される。すると、参加端末DB４１が読み出され、参加端末DB４１に格納された「名前」（図３０参照）が表示される（画面３７３）。この中から自分のプレイヤ名を選択する。

参加者の中には自分と同じプレイヤ名を持った人間がいることがある。その時のために、画面３７３には詳細ボタンが用意されており、このボタンを押すとユーザ情報の詳細を見ることができる。ユーザ情報にはシリアル番号が含まれるので（図４参照）、情報供給端末２に表示されるシリアル番号と、自分のシリアル番号を比較することで本人確認ができる。自分のシリアル番号は、情報端末１にて確認可能である（図１４参照）。

そして、プレイヤが選択されると、ダウンロードする情報を選択する画面が表示される（画面３７４）。ここでは、メニュー１（公式情報）が選択され、図３６のステップＳ３３の処理が実行される。画面３７３で選択されたプレイヤが「タロウ」であるとすると、情報中継端末８は、公式情報の取得要求、参加端末DB４１に格納された「タロウ」のユーザ情報と、「タロウ」のゲーム端末１の不確定情報DBに格納されたデータエントリと、情報中継端末８の識別情報４２をサーバ６に送信する。

サーバは、情報中継端末の認証を行い、「タロウ」のユーザ情報に含まれるシリアル番号がユーザ認証DBに登録されたユーザであるかによりユーザ認証を行い、いずれも認証に成功すれば、サーバ６の不確定情報DBに格納されたデータエントリのうち「種類」が１（図５Ａ参照）のデータエントリを情報中継端末８に送信する。

情報中継端末８は、参加端末DB４１から「タロウ」に該当するエントリの「アドレス」を参照して「タロウ」のゲーム端末のIPアドレスを取得し、サーバから受信したデータエントリを含み、そのIPアドレスをあて先アドレスとするパケットを作成し、ゲーム端末に送信する。

そして、ダウンロードが完了すると、完了画面が表示される（画面３７５）。画面３７４で、メニュー２を選択すれば、サーバ６の不確定情報DBに格納された情報のうち、「種類」が０（不確定）であるデータエントリが送信され、メニュー３を選択すれば、「種類」に関係なくデータエントリが送信される。

また、画面３７３で選択されるプレイヤ名と実際に情報供給端末に対し一連の操作を行う人物が同一であるかを確認するために、画面３７３と画面３７４の処理の間に認証処理を行ってもよい。合わせて有料サービスを提供する場合課金処理を行うこともできる。

図３８は、認証・課金処理の一例を説明する画面例である。図３７の画面３７３の後、情報供給端末２には、認証用の番号（認証コード）が表示される（画面３８１）。これは、認証管理部によりランダムに作成される番号である。そして、画面３７３で選択されたプレイヤのゲーム端末には、認証コードを入力する画面が表示される（画面３８２）。

そして、プレイヤは画面３８１に表示された認証コードをゲーム端末に入力する。入力された番号は、情報中継端末８に送信され、情報中継端末８は、画面３８１で表示した認証コードと同じ番号が入力されていることを確認し、認証が完了する（画面３８３）。ゲーム端末から受信した番号と、表示した認証コードが一致しなければ認証は失敗し、情報のダウンロードは行われない。

また、画面３８１の前段で現金の投入等の課金処理が行われた後でないと、画面３８１が表示されないように設定すれば、課金処理と認証処理を一度に行うことができる。この認証方法によれば、画面３８３で自分が操作するキャラクタ以外を誤って選択しても、情報中継端末８１に表示される認証コードがわからないと認証に成功しないので、本人以外のプレイヤが認証される可能性は低い。

こうして、第二の実施形態によれば、サーバに、データエントリが伝播の過程で変化しない確定情報を格納し、確定情報をゲーム端末（情報端末）に伝播させることができる。こうして、ゲームメーカが公式情報として発表する情報をゲーム端末にリアルタイムにしかも、適切なタイミングに伝播させることができる。また、情報中継端末を設置することによる集客効果も期待できる。

そして、サーバでゲーム端末からの不確定情報を格納しておくことで、普段、近くにゲームをするプレイヤがいないプレイヤが、情報中継端末を介してサーバから不確定情報をダウンロードし、全国からの不確定情報を入手することができる。また、サーバ６によってのみ確定情報を発生させることができるので、偽の確定情報が発生することもない。確定情報として、期間限定のイベントをゲーム内、あるいは現実世界で開催する告知をすることもでき、よりゲームの遊戯性を高めることができる。

なお、第二の実施形態において、ゲーム端末１をサーバ３に直接接続できるようにして、情報中継端末２を省略することも可能である。

Claims (10)

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

Images