JP2003236251A - キャラクタ管理システム - Google Patents

Abstract

(57)【要約】 【課題】 可用性および公平性を高め、使い勝手をよく
する。 【解決手段】 通信端末に対応付けられたゲーム参加者
に替わってゲーム世界で動作する所定のゲームキャラク
タを管理するキャラクタ管理システムにおいて、前記通
信端末は、前記ゲームキャラクタのゲーム世界における
性質を規定するキャラクタ属性情報を収容する属性情報
蓄積手段を備え、当該ゲーム世界で当該ゲームキャラク
タを動作させることにより所定のゲームを実行する際に
は、所定のゲーム装置に当該通信端末を接続して当該属
性情報蓄積手段に収容されているキャラクタ属性情報を
参照する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はキャラクタ管理シス
テムに関し、例えば、ゲームセンタに設置されているア
ーケードゲームに携帯電話機を接続してゲームを行う場
合などに適用して好適なものである。

【０００２】

【従来の技術】ゲームに参加するゲームキャラクタの性
質を規定するキャラクタデータの管理方法は、当該キャ
ラクタデータの保管方法に応じて異なる。

【０００３】保管方法には、各キャラクタデータを各ユ
ーザ（ゲーム参加者）が携帯する磁気カードなどに分散
して保管する分散保管方法と、各ユーザに対応する多数
のキャラクタデータを単一の管理センタで集中的に保管
する集中保管方法がある。

【０００４】分散保管方法は、システム運用側にとって
運用やシステム構築のための負担が少ない点で有利であ
り、集中保管方法は、キャラクタデータの改ざんを防止
することが容易である点で有利である。

【０００５】

【発明が解決しようとする課題】ところが上述した分散
保管方法では、磁気カードなどは基本的にキャラクタデ
ータを蓄積し、保管する機能しか備えていないため、ユ
ーザが自分の磁気カード内に保管されているキャラクタ
データの内容を確認したい場合でも、ゲームセンタに設
置されているアーケードゲーム機など、当該キャラクタ
データを処理して表示する機能を備えた専用の情報処理
装置に接続することが必要であり、可用性や使い勝手の
点で問題がある。

【０００６】磁気カードなどはまた、磁気カードの構造
に関する知識やノウハウがあれば、比較的容易に、キャ
ラクタデータの内容を書き換えることもできるため、悪
意のユーザが磁気カード内に保管されているキャラクタ
データの改ざんを行うことも比較的容易で、ゲームの公
平性を保証することが難しいという欠点がある。

【０００７】一方、上述した集中保管方法では、ユーザ
が単にキャラクタデータの内容を確認したいと考えた場
合にも、前記管理センタにアクセスすることが必要にな
る。

【０００８】このアクセスのために携帯電話機などを使
用するものとすると、キャラクタデータの内容を確認す
るだけで通信料金がかかり、電波が届かない場所に携帯
電話機が位置する場合には確認することができないとい
う不利、不便があり、使い勝手や可用性の点でも問題が
ある。

【０００９】また、このアクセスのためにアーケードゲ
ーム機などを使用するものとすると、キャラクタデータ
の内容を確認するだけで、ゲームセンタに出向いてゲー
ム料金を支払う必要がある点でも、不利、不便がある。

【００１０】

【課題を解決するための手段】かかる課題を解決するた
めに、本発明では、通信端末に対応付けられたゲーム参
加者に替わってゲーム世界で動作する所定のゲームキャ
ラクタを管理するキャラクタ管理システムにおいて、前
記通信端末は、前記ゲームキャラクタのゲーム世界にお
ける性質を規定するキャラクタ属性情報を収容する属性
情報蓄積手段を備え、当該ゲーム世界で当該ゲームキャ
ラクタを動作させることにより所定のゲームを実行する
際には、所定のゲーム装置に当該通信端末を接続して当
該属性情報蓄積手段に収容されているキャラクタ属性情
報を参照することを特徴とする。

【００１１】

【発明の実施の形態】（Ａ）実施形態 以下、本発明にかかるキャラクタ管理システムを、ゲー
ムセンタを利用するゲームシステムに適用した場合を例
に、実施形態について説明する。

【００１２】本実施形態では、ゲームはゲームセンタで
のみ行い、携帯端末だけを単独で使用してゲームを行う
ことはできないものとする。

【００１３】（Ａ−１）実施形態の構成 本実施形態のゲームシステム１０の全体構成例を図１に
示す。

【００１４】図１において、当該ゲームシステム１０
は、管理センタ１１と、携帯端末１２Ａ〜１２Ｃと、ゲ
ームセンタ１３Ａ、１３Ｂと、ネットワーク（インター
ネット）１４とを備えている。

【００１５】このうち管理センタ１１とゲームセンタ１
３Ａ、１３Ｂとのあいだには、ネットワーク１４が介在
している。本実施形態では当該ネットワーク１４はイン
ターネットであるものとする。必要に応じて、携帯端末
（例えば、１２Ａ）は、ゲームセンタ（例えば１３Ａ）
を介することなく、インターネット１４を用いて管理セ
ンタ１１と通信（電子メールのやり取りや、Ｗｅｂペー
ジの閲覧など）することが可能である。

【００１６】なお、管理センタ１１とゲームセンタ（例
えば、１３Ａ）のあいだでは双方向通信が行われるが、
この双方向通信は、各携帯端末（例えば１２Ａ）を携帯
してゲームに参加するユーザ（例えばＵＡ）の認証、キ
ャラクタデータの検証、ポイント更新のための通信であ
る。

【００１７】当該双方向通信のセキュリティ性を高める
ためには、インターネット１４を専用線に置換してもよ
いし、インターネット上にＶＰＮを設定してもよい。

【００１８】図示の例では、ゲームシステム１０に含ま
れている携帯端末の数は３台で、ゲームセンタの数は２
つであるが、この数は必ずしもこの値に限定する必要は
ないことは当然である。通常は、３台よりもはるかに多
くの携帯端末と、２つよりもはるかに多くのゲームセン
タがゲームシステム１０内に含まれることになる。

【００１９】本実施形態が対象とするゲームは、ネット
ワークゲームであってもよく、通常のゲームであっても
よい。

【００２０】ネットワークゲームは、各ゲームセンタ内
に設置された複数のアーケードゲーム機をインターネッ
ト１４などのネットワークで結ぶことで統一的な１つの
ゲーム世界を生成し、ユーザは、当該ゲーム世界のなか
で行われるゲームにネットワーク経由で参加する。これ
に対し通常のゲームでは、そのゲーム世界の生成は各ア
ーケードゲーム機が独立して行い、ネットワークを使用
する必要はない。もちろん、通常のゲームでも、ゲーム
の内容とは直接関係のない認証などのためにネットワー
ク（インターネット１４など）を介した通信を行うこと
はあってよい。

【００２１】本実施形態では会員制を前提とするため、
ゲームの種類が、ネットワークゲームであろうと、通常
のゲームであろうと、ゲームの開始に際しては、認証が
行われ、肯定的な認証結果が出たユーザだけがゲームへ
の参加を認められる。

【００２２】ゲームへの参加を認められたユーザには、
ポイントを加算するようにしてもよい。例えば、ゲーム
に関する特別なイベント（ゲームの全国大会など）を行
う場合などには、このようなポイント加算によって、多
くのユーザの参加を促進することができる。

【００２３】ポイントは、その値が大きいほどユーザに
とって有益となる指標で、例えば、ゲームに負ければポ
イント値が減少し、勝てば増加し、ゲームに参加するた
めには一定値以上のポイント値が必要であるという性質
のものであってよい。その有益性は、ゲーム遂行上のキ
ャラクタの能力値の向上などに反映させてもよく、物理
的にメダルなどと引き替えることができるものであって
もよい。また、必要に応じて、現金と引き替えることが
できるものとしてもよい。ポイントはイベントの開催中
だけ有効なものであってもよいが、ここでは、イベント
開催中も含め、イベントの前およびイベントの後でも継
続的に有効であるものとする。

【００２４】前記携帯端末１２Ａ〜１２Ｃはネットワー
クゲームの参加者となり得るユーザＵＡ、ＵＢ、ＵＣが
携帯する通信端末であるが、例えばメーラやＷｅｂブラ
ウザを搭載した携帯電話機であってよい。携帯端末１２
Ａ〜１２Ｃが携帯電話機である場合、アーケードゲーム
機を介さずに管理センタ１１と携帯端末１２Ａ〜１２Ｃ
が通信する際には、厳密には、前記インターネット１４
に加えて各携帯電話事業者が運営する各携帯電話ネット
ワークが介在することとなる。

【００２５】携帯端末１２Ａ〜１２Ｃの主要部の構成例
を図４に示す。携帯端末１２Ａ〜１２Ｃの構成は実質的
に同じであるので、図４には携帯端末１２Ａ〜１２Ｃす
べての内部構成を示しているものとみることができる
が、以下の説明では、図４には主としてユーザＵＡが携
帯する携帯端末１２Ａの構成を示したものとして説明を
進める。

【００２６】（Ａ−１−１）携帯端末の構成例 図４において、当該携帯端末１２Ａは、通信部３０と、
制御部３１と、端末ＩＤ部３２と、表示処理部３３と、
記憶部３４と、操作部３５と、ディスプレイ部３６とを
備えている。

【００２７】このうち通信部３０は、直接的には前記携
帯電話ネットワーク内の基地局と無線通信する部分で、
電話として必要な音声通話のほか、電子メールの送受信
やＷｅｂページの閲覧のための送受信なども行う。必要
に応じて、例えば、Bluetoothなどの近距離無線通信機
能や、ＩｒＤＡ方式の赤外線ポートなどの赤外線通信機
能、ケーブルなどを利用した有線通信機能も、ここに搭
載することができる。当該近距離無線通信機能、赤外線
通信機能、または、有線通信機能は、認証やキャラクタ
データ（例えば、ＣＨ１）の参照などに際し、当該携帯
端末１２Ａがゲームセンタに設置されているゲーム機
（アーケードゲーム機）と通信するために使用するもの
である。

【００２８】このような通信を行うために必要ならば、
例えばＪａｖａ（登録商標）などのモバイル言語を利用
してもよい。

【００２９】制御部３１は、ハードウエア的には当該携
帯端末３１のＣＰＵ（中央処理装置）であり、ソフトウ
エア的には、当該携帯端末３１のＯＳ（オペレーティン
グシステム）である。

【００３０】端末ＩＤ部３２は、当該携帯端末１２Ａを
他の携帯端末（例えば、１２Ｂなど）から一意に識別す
るための識別情報である端末ＩＤを格納した部分であ
る。通常、通信部３０から送信する際には当該端末ＩＤ
の送信を伴う。ここでは、当該携帯端末１２Ａの端末Ｉ
ＤはＴＥ１とし、携帯端末１２Ｂの端末ＩＤはＴＥ２と
し、携帯端末１２Ｃの端末ＩＤはＴＥ３とする。

【００３１】操作部３５は、ユーザＵＡが指などで操作
して指示を制御部３１に伝える部分で、例えば、ユーザ
ＵＡが押すための多数のボタンなどを有している。

【００３２】ディスプレイ部３６はユーザＵＡが目視す
るための画面を表示する部分である。当該ディスプレイ
部３６には、携帯電話機１２Ａが待ち受け状態にあると
きには待ち受け画面が画面表示され、電子メールの読み
書きや送受信を行う際にはメーラや読み書きしている電
子メールの内容などに応じた画面が表示され、Ｗｅｂペ
ージを閲覧する際には、Ｗｅｂブラウザや閲覧対象であ
るＷｅｂページの内容などに応じた画面が表示される。

【００３３】一般的に携帯電話機は、パーソナルコンピ
ュータなどに比べると、ディスプレイ部３６の画面表示
に関する制約は多いが、現在の携帯電話機は、グラフィ
ックスを多用したグラフィカルユーザインタフェース
（ＧＵＩ）を装備しているのが普通である。

【００３４】記憶部３４は携帯端末１２Ａの記憶装置で
あり、揮発性または不揮発性の記憶手段である。

【００３５】ユーザＵＡに替わって、あるいはユーザＵ
Ａの意を受けてゲームの世界で動作するキャラクタに関
するデータの集合体（レコード）であるキャラクタデー
タＣＨ１は、当該記憶部３４に格納され、保存されてい
るものとする。

【００３６】当該キャラクタデータＣＨ１は、本来は、
キャラクタがゲームに参加する際に参照されるものであ
る（場合によって、ゲームの進行に応じて、キャラクタ
データの内容が書き換えられることもある）が、本実施
形態では、ゲームに参加するとき以外でも、ユーザＵＡ
が携帯電話機１２Ａだけを用いて自由にキャラクタデー
タＣＨ１の内容をディスプレイ部３６に画面表示して目
視確認することができるものとする。

【００３７】ただしこの際に許されるのは、キャラクタ
データＣＨ１の読出しだけであり、キャラクタデータＣ
Ｈ１に対する書込み（書き換え）は禁止する。これを禁
止しなければ、ユーザＵＡが自由にキャラクタデータＣ
Ｈ１の内容を改ざんすることが可能となって、ゲームの
公平な進行をはかることが困難となるからである。この
禁止により各ユーザ（例えば、ＵＡ）はゲームセンタで
行うゲームの進行や結果を介してしか、キャラクタデー
タＣＨ１の内容を変更することができなくなり、キャラ
クタデータＣＨ１で示されるキャラクタを育成する育成
ゲーム的な要素が加わる。

【００３８】なお、ゲーム（例えば、競馬ゲーム）に参
加する際に当該キャラクタデータＣＨ１をアーケードゲ
ーム機側から参照するため、当該キャラクタデータＣＨ
１は、当該参照を行う側であるゲームセンタに設置され
たゲーム機（例えば、図５に示す４４Ａ）のインタフェ
ースと正常な通信が可能な形式で格納しておく必要があ
る。

【００３９】すなわち、記憶部３４にキャラクタデータ
ＣＨ１を格納するときにはゲーム機が前記Bluetoothな
どに対応した通信機能を搭載することで、前記通信部３
０を介して当該記憶部３４内のキャラクタデータＣＨ１
を参照できる必要がある。

【００４０】当該キャラクタデータＣＨ１で示すキャラ
クタが例えば競馬ゲームに出走する馬である場合には、
当該キャラクタデータＣＨ１の内容は、一例として、図
１１に示すようなものであってよい。

【００４１】図１１において、当該キャラクタデータＣ
Ｈ１は、その馬に関する具体的な名称を示す馬名、体重
を示す重さ、馬体の色や模様を示す色、性別や年齢を示
す性別・歳、競馬レースに関する持久力を示すスタミ
ナ、競馬レースに関する瞬発力を示す瞬発力、競馬レー
スに関する平均的なスピードを示すスピード、性質全般
をつらぬく根本的な強さを示す根性、競馬レースに関す
る幸運の度合を示す運、これまで出走した競馬レースに
関する戦績を示す成績、競馬レースに関する競走力の特
質を示す脚質などの各データ項目の集合体である。

【００４２】このうち馬名、色、性別などはキャラクタ
データＣＨ１を最初に作成する際などに、ユーザＵＡが
自由に設定、選択できるようにしてもよい。

【００４３】また、スタミナ、瞬発力、スピード、根
性、脚質なども、例えば、乱数の組合せなどによって、
最初にキャラクタデータＣＨ１を作成する際に、ある程
度、ユーザＵＡの好みを反映できるようにしてもよい
が、何度も競馬レースを重ねるうちに、競馬レースの進
行状況や結果などに応じて変化するようにしてもよい。
競馬レースで勝ちたい多くのユーザは、これらの値は可
能な範囲でできるだけ優れた最高値であることを希望す
るものと考えられるが、例えば、瞬発力の値が高い場合
はスタミナの値を低くしたり、スピードの値が高い場合
は根性の値を低くすること等によって、ユーザの希望を
ある程度反映しつつも馬に個性を持たせてゲーム展開を
面白くするように配慮することも望ましい。

【００４４】さらに、歳、成績などは、ゲーム世界のな
かでの時間経過や、経験した競馬レースの回数などに応
じて変動していくものである。

【００４５】また、運などは、競馬レース中に発生した
偶発的な要因に応じて変動させるようにしてもよい。

【００４６】前記制御部３１に接続されている表示処理
部３３は、記憶部３４内の当該キャラクタデータＣＨ１
をユーザＵＡがディスプレイ部３６の表示画面上で確認
する場合などに機能する部分である。

【００４７】キャラクタデータＣＨ１の内容を単に確認
するだけならば、当該表示処理部３３は、単純に、その
時点のキャラクタデータＣＨ１の内容（一例としては、
図１１に図示したとおりのものであってよい）をディス
プレイ部３６に画面表示するだけでもよい。キャラクタ
データＣＨ１のデータ項目の数が多い場合などには、キ
ャラクタデータＣＨ１のなかから一部のデータ項目だけ
を選択して画面表示できるようにしてもよい。

【００４８】また、当該キャラクタデータＣＨ１に対応
した画像（キャラクタ画像）をディスプレイ部３６に画
面表示したい場合には、表示処理部３３は、当該キャラ
クタデータＣＨ１の内容から当該キャラクタ画像を生成
してディスプレイ部３６に画面表示させる機能を持つ必
要がある。

【００４９】当該キャラクタ画像が画面上で動作しない
静止した画像である場合には、前記重さ、色、歳などに
対応したキャラクタ画像がディスプレイ部３６に画面表
示される。このとき当該キャラクタ画像は、壁紙として
背景に表示されるものであってもよく、アプリケーショ
ン（例えば、前記メーラやブラウザ）の表示画面の一部
に表示されるものであってもよい。

【００５０】アプリケーションの表示画面の一部に表示
する場合、ユーザＵＡは、電子メールの読み書きや、Ｗ
ｅｂページの閲覧など、競馬レースとは無関係なアプリ
ケーションの機能を利用している状態で当該キャラクタ
画像を目視することになるが、キャラクタデータＣＨ１
で示される馬に対する愛着が強ければ、そのキャラクタ
画像を、電子メールの読み書きやＷｅｂページの閲覧な
どをともに行う親密なコンパニオンキャラクタとして認
識することができる。

【００５１】このようにコンパニオンキャラクタとする
場合には、キャラクタ画像とアプリケーションの内容は
無関係であるが、これらに関連性を持たせてもよい。こ
れは、キャラクタ画像に当該アプリケーションの仕事を
実行するエージェントキャラクタとしての機能を持たせ
る場合である。

【００５２】エージェントキャラクタもユーザＵＡに親
密な感情を抱かせる点ではコンパニオンキャラクタと同
じであるが、アプリケーションの処理の進行に伴ってデ
ィスプレイ部３６の表示画面上で動作する点がコンパニ
オンキャラクタと相違する。

【００５３】一例として、当該アプリケーションがメー
ラであり、処理の種類がメール送信である場合には、キ
ャラクタ画像である馬が画面上でメールをくわえて運ん
でいく様子などを示す画像を表示してもよいが、このと
き、当該キャラクタ画像はエージェントキャラクタであ
るといえる。

【００５４】キャラクタデータはユーザが任意に作成
し、保存し、削除することが可能である。ただし保存
や、いったん保存したキャラクタデータを削除する場合
には、ユーザデータベース２５内のチェックデータの内
容と携帯端末（例えば、１２Ａ）内のキャラクタデータ
の内容のあいだで整合が取れていなければならないた
め、作成、保存、削除は、ゲーム機に携帯端末を接続し
ているときにのみ行えるようにすることが望ましい。

【００５５】なお、作成、保存、削除は、１つのキャラ
クタデータ（例えば、ＣＨ１）の全部を最小単位として
行うものである。

【００５６】一方、当該キャラクタ画像が画面上で動作
する画像である場合にも、基本的には、静止した画像の
場合と同じであるが、静止した画像の場合には、キャラ
クタ画像は、前記重さ、色、歳などに対応したものであ
ったのに対し、動作する画像の場合には、重さ、色、歳
などに加えて、スタミナ、スピード、瞬発力、根性など
も反映させやすく、画面上の表現力が向上するため、キ
ャラクタ画像に対するユーザＵＡの親密感も高まること
が期待できる。

【００５７】特に、エージェントキャラクタの場合に
は、高い表現力によって、例えば、上述したメールをく
わえた馬が疾走する様子を示す脚や馬体の微妙な動きを
表現できることが好ましい。

【００５８】一方、前記管理センタ１１の主要部の構成
例は図３に示す通りである。管理センタ１１の機能は、
例えば、インターネット上のサイトとして実現してもよ
い。本実施形態において当該管理センタ１１は、キャラ
クタデータ（例えば、ＣＨ１）の正当性を検証する機能
も装備している。

【００５９】（Ａ−１−２）管理センタの構成例 図３において、当該管理センタ１１は、通信部２０と、
制御部２１と、メール作成部２２と、認証部２３と、ポ
イント管理部２４と、ユーザデータベース２５と、キャ
ラクタ管理部２６とを備えている。

【００６０】このうち通信部２０は、上述したゲームセ
ンタ１３Ａ、１３Ｂとの双方向通信や、前記電子メール
の送信などに使用する部分である。

【００６１】また、制御部２１は当該管理センタ１１の
ＣＰＵである。

【００６２】さらに、メール作成部２２は、前記電子メ
ールを作成する部分である。当該電子メールは、前記イ
ベントの発生を各ユーザに伝えることでイベントへの多
数のユーザの参加を促すことができる。

【００６３】当該電子メールの作成にあたっては、ユー
ザデータベース２５に格納されているデータが利用され
る。当該電子メールの本文メッセージの内容（その主要
部）は、メール作成担当者が手作業で作成してもかまわ
ないが、宛先の電子メールアドレスの記入や、誰に対し
て電子メールを送信するか等の判断はユーザデータベー
ス２５の内容を利用して当該メール作成部２２が自動的
に行うようにしたほうが、効率的である。

【００６４】当該ユーザデータベース２５の内容は、一
例として、図２に示すようなものであってよい。

【００６５】図２において、当該ユーザデータベース２
５は、データ項目として、ゲームシステム１０内で各ユ
ーザを一意に識別するためのユーザＩＤと、各携帯端末
（例えば１２Ａ〜１２Ｃなど）に対応する電子メールの
宛先を示すメールアドレスと、各携帯端末に関する端末
ＩＤと、各ユーザ（例えば、ＵＡ〜ＵＣなど）の氏名
と、各ユーザの居住地域と、各ユーザのポイントと、前
記キャラクタデータ（例えばＣＨ１）の正当性を検証す
るために必要なチェック（チェックデータ）とを備えて
いる。

【００６６】図２上の各タプル（組）が一人のユーザに
対応している。例えば、最上部のタプルは前記携帯端末
１２Ａを携帯するユーザＵＡが対応する。すなわち、ユ
ーザＵＡのユーザＩＤは１で、その携帯端末１２Ａのメ
ールアドレスはＡＤ１で、端末ＩＤはＴＥ１で、ユーザ
ＵＡの氏名はＮＡＭＥ１で、居住地域はＤＩＳＴ１で、
ポイントの値はＰＴ１で、チェックの値はＣＫ１ある。

【００６７】このようなユーザデータベース２５の各デ
ータ項目の値（登録内容）はその多くがユーザに対する
登録処理に応じて決定されたものである。各値は、各ユ
ーザがゲームに関するホームページの閲覧中にアンケー
トに記入した内容などをもとに生成するようにしてもよ
いが、図２のデータ項目のうちメールアドレスおよび氏
名以外の項目は各ユーザがゲームを行う際に自動的に取
得することも可能である。

【００６８】ユーザＩＤは管理センタ１１内で自動的に
生成することができ、端末ＩＤは各携帯端末（１２Ａな
ど）が自動的に送信するものであり、居住地域は携帯端
末の位置登録情報（携帯電話ネットワークでは、いわゆ
る一斉呼び出しを行うために、各携帯電話機の位置を示
す位置登録情報を常時監視し蓄積している）や、各ユー
ザがネットワークゲームを行ったゲームセンタの所在地
などをもとに推測することができ、ポイントは、ゲーム
時に自動的に送信されるものだからである。

【００６９】また、チェックデータも、前記キャラクタ
データ（例えばＣＨ１）の内容に応じて、ゲーム機など
が自動的に生成することができる。チェックデータとし
ては、キャラクタデータ（例えば、ＣＨ１）の全内容を
そのまま活用することもできるが、携帯端末（例えば１
２Ａ）がゲーム機に接続されていないときにキャラクタ
データ（例えばＣＨ１）が改ざんされたか否かを確認す
ることのできる最低限度のデータを当該チェックデータ
として用いることが可能である。この確認には、符号理
論などを応用して様々な方式を用いることができる。

【００７０】一例として、パリティチェックを応用する
場合、２進コードで表現されたキャラクタデータ（例え
ば、ＣＨ１）を所定長(例えば、１バイト）のブロック
に区切り、各ブロックについて各ブロックにおける
“１”の数が偶数であるか奇数であるかに応じて“１”
または“０”を対応付け、チェックデータ（例えば、Ｃ
Ｋ１）として各ビットが“１”または“０”のビット列
をユーザデータベース２５に格納しておく。

【００７１】これにより、前回のゲームを終了するとき
に収集した当該ビット列のビットパターンと、今回、ゲ
ームを開始するときに収集した当該ビット列のビットパ
ターンを照合して両者が１ビットでも相違していれば、
キャラクタデータの改ざんがあったものと判定すること
ができる。

【００７２】この場合、ゲームセンタ（例えば、１３
Ａ）側のゲーム機などが、各ブロック中の“１”の数を
カウントしてカウント結果に応じたビット列を管理セン
タ１１へ送信する機能を持つ必要があるが、キャラクタ
データ（例えば、ＣＨ１）を示す全てのビット列を送信
する場合に比べ、通信量を削減し、チェックデータを格
納するためにユーザデータベース２５側で消費される物
理的な記憶資源の量（ハードディスクの容量など）を削
減することができる利点がある。

【００７３】なお、図２の例では、１ユーザには１つの
キャラクタデータだけが対応付けられているが、１ユー
ザに複数のキャラクタデータを対応付けることができる
ようにしてもよいことは当然である。その場合、各ユー
ザは、自身に対応付けられた複数のキャラクタデータの
なかから選択した任意のキャラクタデータに対応するゲ
ームキャラクタ（馬）をゲームに参加させることができ
る。

【００７４】前記メール作成部２２が作成する電子メー
ルの本文メッセージの内容は、例えば、競馬ゲームの全
国大会（関東大会などでも可）などのイベントを開催す
る日時を伝える文章と、このイベントに参加したユーザ
には漏れなく所定値のポイントを付与する旨の文章とを
記述しておく。このポイントの付与によって、各ユーザ
の参加を促し、十分に多くのユーザが前記競馬ゲームに
参加できるようにする。

【００７５】各ユーザ宛の電子メールの本文メッセージ
の内容は基本的に同じであってよいが、氏名などを記述
する場合には、氏名だけをユーザごとに相違させるよう
にするとよい。

【００７６】またメール作成部２２が、誰に対して電子
メールを送信するかを自動的に判断する際には、各タプ
ルの居住地の値を参照するとよい。例えば、前記イベン
トが全国大会である場合には国内すべての居住地のユー
ザが宛先となるが、関東大会などでは、関東地方に居住
するユーザだけが宛先となる。そして、メール作成部２
２が自動的に宛先の電子メールアドレスを電子メールの
Ｔｏフィールドに記入するに際しては、各タプルのメー
ルアドレスの値を参照するとよい。

【００７７】前記認証部２３は、前記イベントに参加し
ようとするユーザや会員制のゲームを開始使用とするユ
ーザにつき、ユーザデータベース２５に格納されたデー
タをもとに認証を行う部分で、例えば、前記端末ＩＤを
もとに認証を行う。端末ＩＤを用いる以上、当該認証
は、厳密にはユーザの正当性を検証するユーザ認証では
なく、端末の正当性を検証する端末認証であるが、必要
ならば、ユーザ認証を実行するようにしてもよい。認証
時に、ユーザから、例えば、パスワードを入力させるよ
うにすれば、当該パスワードを正確に入力できるユーザ
とできないユーザを識別することができ、ユーザ認証を
実現可能である。

【００７８】なお、認証を行う場所は、必ずしも管理セ
ンタ１１に限らず、各ゲームセンタ（例えば、１３Ａ）
の内部で行うようにしてもよい。この場合、認証の結果
が肯定的であるか否定的であるかだけを管理センタ１１
に伝えるようにしてよい。

【００７９】前記ポイント管理部２４は、ユーザデータ
ベース２５内に格納された各ユーザのポイントの値（例
えば、ユーザＩＤ１のユーザＵＡのポイント値は、ＰＴ
１）を管理する部分である。

【００８０】ポイント値をこのように管理センタ１１側
で管理し、ユーザ側の例えば携帯端末などで管理させな
い構成とすることにより、不正にポイント値を操作する
ことが困難となるため、公正さを担保することができ
る。

【００８１】同様に、キャラクタ管理部２６は、ユーザ
データベース２５内に格納された各ユーザのキャラクタ
データを検証するためのチェックデータ値（例えば、ユ
ーザＩＤ１のユーザＵＡのキャラクタデータＣＨ１に対
しては、ＣＫ１）を管理する部分で、上述したチェック
データ（例えば、ＣＫ１）とビット列との照合を実行す
る。

【００８２】チェックデータの値をこのように管理セン
タ１１側で管理し、ユーザ側の例えば携帯端末などで管
理させない構成とすることにより、キャラクタデータの
改ざんが発覚しないようにすることが困難となるため、
ゲームの公平な進行を保証することができる。

【００８３】一方、前記ゲームセンタ１３Ａ、１３Ｂは
例えば図５に示すような構成を備えている。

【００８４】ゲームセンタ１３Ａ、１３Ｂの実体は、多
種多様なアーケードゲーム（例えば、ゲーム機４４Ａ〜
４４Ｎ）の集合体である。アーケードゲーム機は、ハー
ドウエア的にもソフトウエア的にもゲームに特化した仕
様を備えた情報処理装置であるため、ゲーム以外の用途
にも利用されるパーソナルコンピュータなどを用いる場
合に比べ、はるかに快適なゲーム環境をユーザに提供す
ることができる。

【００８５】ゲームセンタ１３Ａ、１３Ｂの構成は実質
的に同じであるので、図５にはゲームセンタ１３Ａ、１
３Ｂすべての内部構成を示しているものとみることがで
きるが、以下の説明では、図５には主としてゲームセン
タ１３Ａの構成を示したものとして説明を進める。

【００８６】（Ａ−１−３）ゲームセンタの構成例 図５において、当該ゲームセンタ１３Ａは、通信制御装
置４０と、複数のアーケードゲーム機４４Ａ〜４４Ｎを
備えている。

【００８７】このうち通信制御装置４０は、通信部４
１、４３と、制御部４２とを有する。

【００８８】通信部４３は自ゲームセンタ１３Ａ内に収
容しているゲーム機４４Ａ〜４４Ｎと通信するための部
分で、通信部４１は、前記管理センタ１１または他のゲ
ームセンタ（例えば、１３Ｂ）の通信制御装置と通信す
るための部分である。他のゲームセンタとの通信が必要
になるのは、ネットワークゲームを行う場合である。

【００８９】複数のゲーム機４４Ａ〜４４Ｎによって構
成された当該ゲームセンタ１３Ａ内のネットワークは１
つのＬＡＮ（ローカルエリアネットワーク）とみること
ができるので、当該通信制御装置４０は、ルータを主体
とする装置として構成することが可能である。

【００９０】図５では、ゲームセンタ１３Ａ内の全ゲー
ム機４４Ａ〜４４Ｎが共通の伝送路で通信部４３に接続
されているが、当該ＬＡＮの構成は必ずしも物理的に図
示したような構成である必要はない。すなわち、当該Ｌ
ＡＮの内部でも、ブリッジやルータを含んでいてよく、
複数のブロードキャストドメインやコリジョンドメイン
を包含するものであってよい。

【００９１】ネットワークゲームは、同種のゲームのた
めのゲーム機がネットワークを介して接続されるもので
あるから、同種のゲームを行うゲーム機であるかぎり、
同一のゲームセンタ１３Ａの内部にあるか外部にあるか
を意識することなく、複数のゲーム機によって現実世界
（例えば、現実世界における競馬）を模した統一的な１
つのゲーム世界が形成され、当該ゲーム世界の内部にお
いて、各キャラクタにより、ゲームが行われる。全国大
会であれば、全国各地に分散した多数のゲームセンタを
介して、全国のユーザが当該ゲームに参加することにな
る。

【００９２】例えば、競馬ゲームの場合、もしもゲーム
機４４Ａと４４Ｂが同じ競馬ゲームのためのゲーム機で
あり、他のゲームセンタ１３Ｂの内部にも同じ競馬ゲー
ムのためのゲーム機があれば、これら３つのゲーム機で
ゲームを行うユーザ（例えばＵＡ〜ＵＣ）は、各自のキ
ャラクタである馬を同じ競馬ゲームに出走させて、競走
させることができる。

【００９３】一般的にネットワークゲームを行うと、か
なり多量のデータの通信が必要になったり、かなり長時
間の通信が必要になることもあり、通信料金が問題とな
り得るが、ゲームセンタの場合には、多数のゲーム機を
備え、同時に多数のユーザを収容するため、一般の個人
ユーザ宅と異なりインターネットへのアクセス回線とし
て専用線などを利用することも比較的容易である。

【００９４】ゲームセンタ（例えば、１３Ａ、１３Ｂ）
を介して行うネットワークゲームの通信料金は、最終的
にはゲームの料金の形でユーザＵＡ〜ＵＣの負担になる
ものと考えられるが、アクセス回線に関するこのような
利点を考慮すると、個々のユーザＵＡ〜ＵＣには、自宅
でネットワークゲームを行う場合に比べ、通信料金に関
する割安感を与えることができる可能性が高い。

【００９５】ユーザＵＡなどが行うゲームがネットワー
クゲームではなく、通常のゲームである場合には、ネッ
トワークを介した通信は、認証やキャラクタデータの検
証などのためだけに必要とされ、基本的に、ゲームその
ものの進行のためには必要ではない。

【００９６】通常のゲームが競馬ゲームである場合に
は、キャラクタゲームＣＨ１に対応するゲームキャラク
タは、当該ゲーム機が自動的に生成するゲームキャラク
タと競走するのが基本である。もちろん、当該ゲーム機
が同時に複数のユーザの参加を認める仕様である場合に
は、同一のゲーム機を使用する複数のユーザのゲームキ
ャラクタ間で、競走を行わせることも可能である。

【００９７】以下、上記のような構成を有する本実施形
態の動作について説明する。本実施形態の動作は図９お
よび図１０のフローチャートと、図７および図８の動作
シーケンスに示す。このうち、図９のフローチャートは
ゲーム機（例えば４４Ａ）における動作を示し、図１０
のフローチャートは図９とほぼ同じタイミングにおける
携帯端末（例えば、１２Ａ）の動作を示す。

【００９８】そして、図７および図８の動作シーケンス
は、携帯端末（例えば、１２Ａ）、管理センタ１１、ゲ
ームセンタ（例えば、１３Ａ）の３者間における連携動
作を示すもので、図７はゲーム終了後にキャラクタデー
タを携帯端末に蓄積する場合を示し、図８は携帯端末に
蓄積されているキャラクタデータを用いてゲームを行
い、ゲーム終了後にキャラクタデータを蓄積（すでに蓄
積してあるキャラクタデータの更新を含む）する場合を
示す。したがって図７と図８は、一部が重複しているも
のとみることができる。

【００９９】図９のフローチャートはＰ５０〜Ｐ５８の
各ステップから構成され、図１０のフローチャートはＰ
６０〜Ｐ６４の各ステップから構成されている。

【０１００】また、図７の動作シーケンスは、Ｐ１０〜
Ｐ１７の各ステップから構成され、図３の動作シーケン
スは、Ｐ２０〜Ｐ２６の各ステップから構成され、図８
の動作シーケンスは、Ｐ３０〜Ｐ４１の各ステップから
構成されている。

【０１０１】（Ａ−２）実施形態の動作 予め、図２に示す各データ項目の値が、登録によって得
られているものとすると、管理センタ１１では、必要に
応じ電子メールなどを送信して会員である各ユーザ（例
えば、ＵＡ〜ＵＣ）にイベントへの参加を促すことがで
きる。携帯端末を携帯した各ユーザはこのような電子メ
ールの受信に応じて、あるいは、電子メールの受信と無
関係に、任意のゲームセンタ（例えば、１３Ａ）に立ち
寄って、ゲームを開始することができる。

【０１０２】ここでは、一例として、携帯端末１２Ａを
携帯するユーザＵＡがゲームセンタ１３Ａに立ち寄っ
て、図５に示すゲーム機４４Ａを用いてゲームを開始し
たものとする。

【０１０３】図８〜図１０において、ユーザＵＡがゲー
ム機４４Ａを操作して携帯端末１２Ａに蓄積している前
記キャラクタデータＣＨ１を使用するか否かを指示する
（Ｐ５１）。

【０１０４】ここで使用しない旨の指示を出したものと
すると、図９のステップＰ５１はＮｏ側に分岐して、新
規キャラクタを作成することになるが（Ｐ５２）、使用
する旨の指示を出したものとすると、ステップＰ５１は
Ｙｅｓ側に分岐し、ゲーム機４４Ａが前記Bluetoothな
どを使用して携帯端末１２Ａに対しゲームキャラクタＣ
Ｈ１の送信を要求する（Ｐ５３）。これに応えて、携帯
端末１２Ａは、Bluetoothなどを使用してキャラクタデ
ータＣＨ１を返すことになる（Ｐ５４）。

【０１０５】いずれの場合でも、ステップＰ５２または
Ｐ５４が終了した段階で、ゲーム開始に必要なキャラク
タデータがゲーム機４４Ａ内に生成される。

【０１０６】この時点で、図１０上ではステップＰ６０
〜Ｐ６３の処理が終了しており、図８上では、ステップ
Ｐ３０〜Ｐ３２の処理が終了している。

【０１０７】前記ステップＰ５１で蓄積しているキャラ
クタデータＣＨ１の使用を指示した場合には、キャラク
タデータＣＨ１が改ざんされていないかどうかを確認す
るため、ゲーム機４４Ａが管理センタ１１に対し、図８
上でキャラクタデータＣＨ１の検証を要求する（Ｐ３
３）。この際、当該ゲーム機４４Ａは、上述したチェッ
クデータＣＫ１と照合するためのビット列を管理センタ
１１へ送信することになるため、キャラクタデータＣＨ
１の内容から当該ビット列を生成する処理は、ゲーム機
４４Ａが実行することになる。

【０１０８】なお、ゲーム機４４Ａにこのようなビット
列の生成などを行う機能を装備することが好ましくない
場合には、各ゲーム機４４Ａ〜４４Ｎに関する当該機能
を集中的に分担する専用の処理装置をゲームセンタ１３
Ａ内に設置するようにしてもよい。これにより、ゲーム
機（例えば、４４Ａ）は、基本的にゲームに必要な機能
だけを装備すればよくなる。

【０１０９】このビット列を受信した管理センタ１１
は、前記チェックデータＣＫ１と当該ビット列を照合し
て、キャラクタデータＣＨ１が改ざんされていないかど
うかを検証し、検証結果をゲームセンタ１２Ａ（その中
のゲーム機４４Ａ）に返す（Ｐ３４）。このステップＰ
３３およびＰ３４において、キャラクタデータＣＨ１の
検証だけでなく、上述した携帯端末１２Ａに関する端末
ＩＤ等を用いた認証も行うものであってよい。通常、ユ
ーザ（あるいは携帯端末）を特定できなければ、照合す
べきチェックデータ（例えば、ＣＫ１）も特定できない
ため、キャラクタデータの検証は端末ＩＤ等を用いた認
証のあとで実行されることになる。もちろん、チェック
データ自体に他のチェックデータと識別可能な一意性を
持たせるようにしておけば、キャラクタデータの検証だ
けを単独で実行することも可能である。

【０１１０】なお、前記ステップＰ５１で、ユーザＵＡ
が、蓄積してあるキャラクタデータＣＨ１を使用しない
旨の指示を出した場合には、キャラクタデータの検証は
不要であるが、端末ＩＤ等を用いた認証は行うことがで
きる。

【０１１１】端末ＩＤ等を用いた認証、またはキャラク
タデータＣＨ１の検証結果が否定的である場合には、そ
のままゲームを開始することはできない。端末ＩＤ等を
用いた認証の結果が否定的である場合には、当該ユーザ
ＵＡが会員登録を行っていないケースであるから、新た
な会員登録を進める処理を行うようにしてもよいが、キ
ャラクタデータＣＨ１の検証結果が否定的である場合
は、キャラクタデータＣＨ１に関して不正な改ざんが行
われたケースであるから、ゲーム機４４Ａなどが警報出
力などを行うようにしてもよい。

【０１１２】端末ＩＤ等を用いた認証（、および必要な
キャラクタデータＣＨ１の検証）の結果が否定的なもの
でなければ、当該キャラクタデータＣＨ１（あるいは新
規に作成したキャラクタデータ）を用いてゲームが実行
される。

【０１１３】ゲームの内容は、上述したネットワークゲ
ームであっても、通常のゲームであってもよい。いずれ
にしてもここでは競馬ゲームを想定しているため、現実
の競馬を模したゲーム世界のなかで、競馬ゲームが実行
される（図７のＰ２１，図８のＰ３６、図９のＰ５５、
図１０のＰ６４）。この競馬ゲームのなかでは、第１レ
ース、第２レース、…など複数の競馬レースが行われる
ものであってよい。

【０１１４】そして当該競馬ゲームが終了すると（Ｐ２
２，Ｐ３７）、ユーザＵＡがゲーム機４４Ａを介して、
当該競馬ゲームの進行状況や結果に応じて更新されたキ
ャラクタデータＣＨ１の内容を携帯端末１２Ａに保存す
るか否かを指示する（Ｐ５６）。

【０１１５】保存を指示した場合には、更新されたキャ
ラクタデータＣＨ１の内容が前記Bluetoothなどを用い
て携帯端末１２Ａに送信され（Ｐ２４，Ｐ３９，Ｐ５
７）、記憶部３４内に記憶されている更新前のキャラク
タデータＣＨ１に置き換えられる。このとき、ゲーム機
４４Ａでは、更新後のキャラクタデータＣＨ１に関する
前記ビット列が生成されて管理センタ１１に送信される
（Ｐ４０）。このビット列は、新たなチェックデータＣ
Ｋ１としてユーザデータベース２５内に格納されること
になる。

【０１１６】ステップＰ４０のビット列の送信をもっ
て、ゲームシステム１０中の１ゲーム、１ユーザに関す
るすべての処理が正常に終了したことになる（Ｐ４
１）。

【０１１７】なお、ゲームを行っていないときでも、ユ
ーザＵＡが携帯端末１２Ａを操作することによって、外
部との通信を行うことなく、いつでもキャラクタデータ
ＣＨ１の内容を確認すること等が可能な点は、すでに説
明したとおりである。

【０１１８】（Ａ−３）実施形態の効果 本実施形態によれば、ユーザ（例えば、ＵＡ）は、携帯
端末だけ単独で（通信を行うことなく）利用することで
いつでもキャラクタデータの内容を確認することができ
るため、ユーザが負担する費用（通信料金など）や、可
用性や使い勝手の点で従来よりも優れており、利便性が
高い。

【０１１９】しかも、本実施形態では、キャラクタデー
タの改ざんを検証することもできるため、公平なゲーム
の進行を保証することが可能である。

【０１２０】(Ｂ）他の実施形態 上記実施形態では各携帯端末の端末ＩＤを使用して認証
を行ったが、当該端末ＩＤは、電話番号やバーコードな
どに置換可能である。

【０１２１】また、上記実施形態では、前記携帯端末
（例えば、１２Ａ）を携帯電話機であるものとしたが、
携帯端末は必ずしも携帯電話機である必要はない。例え
ば、ＰＤＡ、ＰＨＳ端末、メール端末なども、当該携帯
端末として利用することが可能である。

【０１２２】なお、携帯端末は、このような移動性のあ
る通信端末だけでなく、移動性の乏しい通信端末に置換
することも可能である。例えば、据え置き型のパーソナ
ルコンピュータなどに置換することも可能である。もち
ろんその場合には、パーソナルコンピュータとゲーム機
（例えば、４４Ａ）のあいだは、例えばインターネット
などのネットワークを介して接続する必要がある。

【０１２３】また、前記キャラクタデータ（例えば、Ｃ
Ｈ１）は、必要に応じて、前記記憶部３４に格納せず、
独立したメモリカードなどに格納するようにしてもよ
い。

【０１２４】ただし、ユーザ（例えばＵＡ）がゲームセ
ンタ（例えば、１３Ａ）などに出向くことなく携帯端末
（例えば１２Ａ）だけを用いてキャラクタデータ（例え
ばＣＨ１）の内容を確認することができるようにするた
めには、メモリカードを使用する場合、携帯端末（例え
ば１２Ａ）が当該メモリカードを装着してその内容を読
み書き（少なくとも、読出し）することのできるインタ
フェースを備えていることが必要である。

【０１２５】また、キャラクタデータをメモリカードな
どに格納した場合には、ゲーム機は、当該メモリカード
を装着して、メモリカード内のキャラクタデータ（例え
ばＣＨ１）を参照するためのスロットなどのインタフェ
ースを搭載する必要がある。

【０１２６】なお、上記実施形態におけるユーザデータ
ベース２５中のデータ項目のうち、自動的に取得できな
いデータ項目であるメールアドレスおよび氏名は省略可
能である。あるいは、データ項目として氏名およびメー
ルアドレスは設けておき、その値に空値を許す構成とし
てもよい。ただしメールアドレスを省略した場合、当
然、前記イベントへの参加を促す電子メールを送信する
ことはできなくなる。

【０１２７】また、上記実施形態では、管理センタ１１
を使用したが、管理センタ１１は省略することも可能で
ある。

【０１２８】管理センタ１１を使用しない場合の動作
は、一例として、図６の動作シーケンスに示すようにな
る。図６の動作シーケンスは、基本的に、すでに説明し
た図８の動作シーケンスから管理センタ１１に関連する
ステップを取り除いたものになっている。

【０１２９】図６の動作シーケンスではキャラクタデー
タ（馬データ）の検証を行っていないが、必要に応じて
当該検証を行うようにすることも可能である。ただしそ
の場合には前記チェックコード（例えばＣＫ１）は、ゲ
ームセンタ内に蓄積しておく必要があるため、ユーザ
（ＵＡ）がゲームをすることのできるゲームセンタは、
予め登録した特定のゲームセンタに限定されることにな
る。

【０１３０】さらに、上記実施形態では主としてハード
ウエア的に本発明を実現したが、本発明はソフトウエア
的に実現することも可能である。

【０１３１】

【発明の効果】以上に説明したように、本発明によれ
ば、可用性および公平性が高く、使い勝手のよいキャラ
クタ管理システムを提供することができる。

【図面の簡単な説明】

【図１】実施形態に係るゲームシステムの全体構成例を
示す概略図である。

【図２】実施形態で使用するデータベースの構成例であ
る。

【図３】実施形態で使用する管理センタの主要部の構成
例を示す概略図である。

【図４】実施形態で使用する携帯端末の主要部の構成例
を示す概略図である。

【図５】実施形態で使用するゲームセンタの主要部の構
成例を示す概略図である。

【図６】実施形態の動作説明図である。

【図７】実施形態の動作説明図である。

【図８】実施形態の動作説明図である。

【図９】実施形態の動作説明図である。

【図１０】実施形態の動作説明図である。

【図１１】実施形態で使用するキャラクタデータの構成
例を示す概略図である。

【符号の説明】

１０…ゲームシステム、１１…管理センタ、１２Ａ〜１
２Ｃ…携帯端末、１３Ａ、１３Ｂ…ゲームセンタ、１４
…ネットワーク、２２…メール作成部、２３…認証部、
２４…ポイント管理部、２５…ユーザデータベース、２
６…キャラクタ管理部、３２…端末ＩＤ部、３３…表示
処理部、３４…記憶部、３６…ディスプレイ部、４４Ａ
〜４４Ｎ…ゲーム機、ＵＡ〜ＵＣ…ユーザ、ＣＨ１〜Ｃ
Ｈ３…キャラクタデータ。

Claims (7)

【特許請求の範囲】
1. 【請求項１】 通信端末に対応付けられたゲーム参加者
   に替わってゲーム世界で動作する所定のゲームキャラク
   タを管理するキャラクタ管理システムにおいて、 前記通信端末は、 前記ゲームキャラクタのゲーム世界における性質を規定
   するキャラクタ属性情報を収容する属性情報蓄積手段を
   備え、 当該ゲーム世界で当該ゲームキャラクタを動作させるこ
   とにより所定のゲームを実行する際には、所定のゲーム
   装置に当該通信端末を接続して当該属性情報蓄積手段に
   収容されているキャラクタ属性情報を参照することを特
   徴とするキャラクタ管理システム。
2. 【請求項２】 請求項１のキャラクタ管理システムにお
   いて、 前記通信端末は、前記ゲーム装置に接続することなく独
   立して前記ゲームを実行することはできないものの、 前記キャラクタ属性情報の内容を前記ゲーム参加者に対
   して提示する属性情報提示手段を備えることを特徴とす
   るキャラクタ管理システム。
3. 【請求項３】 請求項２のキャラクタ管理システムにお
   いて、 前記属性情報提示手段は、 前記キャラクタ属性情報に対応したゲームキャラクタを
   示す画像を、キャラクタ画像として前記通信端末の画面
   上に表示するキャラクタ画像表示処理部を有することを
   特徴とするキャラクタ管理システム。
4. 【請求項４】 請求項２のキャラクタ管理システムにお
   いて、 前記キャラクタ画像表示処理部は、 静的な背景画像として、前記キャラクタ画像を表示する
   壁紙表示処理部を有することを特徴とするキャラクタ管
   理システム。
5. 【請求項５】 請求項３のキャラクタ管理システムにお
   いて、 前記キャラクタ画像表示処理部は、 前記通信端末で使用するアプリケーションの表示画面の
   一部に、コンパニオンキャラクタとして、前記キャラク
   タ画像を静的または動的に表示するコンパニオン表示処
   理部を有することを特徴とするキャラクタ管理システ
   ム。
6. 【請求項６】 請求項５のキャラクタ管理システムにお
   いて、 前記キャラクタ画像表示処理部は、 前記アプリケーションのための仕事を実行するエージェ
   ントキャラクタとして、前記キャラクタ画像を処理する
   エージェント対応部を有することを特徴とするキャラク
   タ管理システム。
7. 【請求項７】 請求項１のキャラクタ管理システムにお
   いて、 前記ゲーム装置に接続された管理装置を設け、 当該管理装置は、 前記ゲーム装置に前記通信端末を接続して前記キャラク
   タ属性情報を参照する際、当該キャラクタ属性情報の正
   当性を検証する検証手段を備えたことを特徴とするキャ
   ラクタ管理システム。