プログラムおよびコンピュータシステム
【課題】ネットワークゲームの仮想社会におけるアバターの活動をとおして、不特定性の個人に対してメッセージの受け渡しを実現するプログラムを提供することを目的とする。
【解決手段】第１のアバターがメッセージを書き込むための魚を購入し、この魚にメッセージおよびこのメッセージを読んでもらいたいアバターの属性を書き込む。そして、この魚を川や海へ放流する。これにより、魚は自由に回遊する。第２のアバターが、川や海へ行き、釣り糸を水中を下して、魚を釣り上げる。そうすると、この魚に書き込まれているメッセージが表示される。これにより、魚と魚釣りという動作を介してメッセージを不特定の個人に手渡すことができる。
【解決手段】第１のアバターがメッセージを書き込むための魚を購入し、この魚にメッセージおよびこのメッセージを読んでもらいたいアバターの属性を書き込む。そして、この魚を川や海へ放流する。これにより、魚は自由に回遊する。第２のアバターが、川や海へ行き、釣り糸を水中を下して、魚を釣り上げる。そうすると、この魚に書き込まれているメッセージが表示される。これにより、魚と魚釣りという動作を介してメッセージを不特定の個人に手渡すことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のアバターが登場する仮想社会内で、アバター間でメッセージを交換するためのプログラムおよびこのプログラムを実行するコンピュータシステムに関する。
【背景技術】
【０００２】
近年、例えばＭＭＯＲＰＧ（ＭＭＯＲＰＧ：Massively Multiplayer Online Role-Playing Game）等のインターネットを介して多人数が参加するネットワークゲームが普及している（たとえば非特許文献１）。
【０００３】
この種のネットワークゲームでは、複数のプレイヤーが、それぞれ端末装置を操作して仮想社会に自己のキャラクタであるアバターを登場させ、互いに会話をしたり、一緒にゲームをしたりすることができる。
【０００４】
【非特許文献１】“ハンゲームガイド”、［online］、NHN Japan 株式会社、［平成１９年２月９日検索］、インターネット＜URL：http://www.hangame.co.jp/guide/index.asp?Content=avatar＞
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来、パーソナルコンピュータ，ネットワークを用いたコミュニケーション手段としては、メール，チャット等が知られている。これらは、特定の相手に向けたものであり、不特定の限られた人に向けたコミュニケーション手段は存在しなかった。また、従来より、公衆に向けてメッセージを発信する機能として掲示板が知られているが、この掲示板は、不特定多数の公衆に向けてメッセージを発信するものであり、掲示板にアクセスする人全てがメッセージを閲覧することができるものであり、やはり不特定の限られた人に向けてメッセージを発信できるものではなかった。
【０００６】
また、上記ネットワークゲームにおいて、メッセージの受け渡しを直接的な目的としないアバターの活動の中でメッセージの受け渡しを実現するという、ゲーム的な要素を取り入れたコミュニケーション手段は存在しなかった。
この発明は、ネットワークゲームの仮想社会におけるアバターの活動をとおして、不特
定の限られた人に対してメッセージの受け渡しを実現するプログラムを提供することを目的とし、また、このプログラムを実行するコンピュータシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願発明の第１の側面によって提供されるゲームプログラムは、複数の端末装置がネットワークで接続されたコンピュータシステムに、以下の手順を実行させることを特徴とする。
複数の端末装置によってそれぞれ操作される複数の仮想のキャラクタ（アバター）と、仮想オブジェクトと、を含む仮想社会を生成する仮想社会生成手順
仮想社会を各端末装置の表示部に表示させる表示手順
特定の端末装置から、仮想オブジェクトに対応づけたメッセージの入力操作を受け付けたときに、このメッセージを仮想オブジェクトに対応づけて登録するメッセージ登録手順
メッセージが登録された仮想オブジェクトを、複数のアバターのうちの１つである不特定アバターの取得動作に応じて、該不特定アバターに取得および占有させる取得手順
この不特定アバターによって仮想オブジェクトが占有されているとき、この不特定アバターを操作する端末装置にメッセージを出力可能にするメッセージ出力許可手順
不特定アバターを操作する端末装置からの操作により、取得動作に応じて不特定アバターに占有されている仮想アイテムの占有を解除して他の不特定アバターが取得可能な状態にもどす占有解除手順
【０００８】
上記発明において、メッセージが登録された仮想オブジェクトを仮想社会内で移動させる移動手順を、コンピュータシステムに更に実行させてもよい。
【０００９】
上記発明において、仮想社会生成手順は、属性が付与されたアバターを生成する手順を含み、メッセージ登録手順は、メッセージとともに属性を登録する手順を含み、取得手順は、仮想オブジェクトに対応付けて登録されている属性と一致する属性が付与された不特定アバターのみに仮想オブジェクトの取得を可能にする手順を含んでいてもよい。
【００１０】
上記発明において、仮想アイテムの購入操作が行われた端末装置を特定の端末装置としてもよい。
【００１１】
本願発明の第２の側面によって提供されるコンピュータシステムは、上記のプログラムを記憶する記憶部と、前記プログラムを実行するコンピュータと、を備えたことを特徴とする。
【発明の効果】
【００１２】
この発明によれば、メッセージが登録された仮想オブジェクトが取得されたとき、その仮想オブジェクトを取得したアバターに対してメッセージを出力可能にすることにより、不特定の限定された人に対してメッセージを発信することが可能になる。また、仮想建造物や仮想オブジェクトに登録したメッセージが仮想建造物や仮想オブジェクトから出力される態様で出力されることにより、そのときその場に居合わせた不特定の限定された少数アバターに対してメッセージを伝えることができる。これにより、従来のメール，チャット，掲示板にはない、偶然性を用いた不特定の限定された人に対するメッセージの伝達が可能になる。
【００１３】
この発明は、たとえば釣りや蝶々取り等の仮想社会内での（直接的なコミュニケーションではない）活動を通して、メッセージの受け渡しができるため、ネットワークゲームの趣向性を損なわずに他のプレイヤーとのコミュニケーションをとることが可能になる。
【図面の簡単な説明】
【００１４】
【図１】この発明が適用されるコンピュータシステムで実行されるネットワークゲームのステージとなる仮想社会の一例を示す図
【図２】前記仮想社会の画面表示例を示す図
【図３】アバターの例を示す図
【図４】ゲームにおいてメッセージ魚へのメッセージの書き込み・捕の手順を示すフローチャート
【図５】前記ネットワークゲームを実行するコンピュータシステムの構成を示す図
【図６】ポータルサーバに設けられるサーバデータベースを示す図
【図７】ポータルサーバに設けられるサーバデータベースを示す図
【図８】ログイン時およびデータの定期更新時のコンピュータシステムの動作を示すフローチャート
【図９】アバターの動作制御処理を示すフローチャート
【図１０】メッセージ登録時の動作を示すフローチャート
【図１１】魚捕獲（釣り）動作時の端末装置の動作を示すフローチャート
【図１２】魚捕獲（釣り）動作時のポータルサーバの動作を示すフローチャート
【図１３】釣り上げ成功時のコンピュータシステムの動作を示すフローチャート
【図１４】ゲームにおいてメッセージ蝶々へのメッセージの書き込み・捕獲の手順を示すフローチャート
【図１５】ゲームにおいてメッセージボトルへのメッセージの書き込み・捕獲の手順を示すフローチャート
【図１６】メッセージボトルの位置情報更新手順を示すフローチャート
【図１７】ゲームにおいてロバの耳井戸へのメッセージの入力・出力の手順を示すフローチャート
【図１８】ロバの耳井戸へのメッセージ入力・出力を実行するためのコンピュータシステムの処理手順を示すフローチャート
【発明を実施するための形態】
【００１５】
<<ゲームの概要説明>>
まず、この発明が適用されたコンピュータシステムで展開されるオンラインゲームについて説明する。
このゲームは、ポータルサーバと、端末装置であるパーソナルコンピュータとをインターネット等のネットワークを介して接続したコンピュータシステムで実行される多人数同時参加型のネットワークゲームであり、ポータルサーバや端末装置の情報処理機能（特に画像処理機能）を用いて仮想的に創り出された仮想社会に、各端末装置の利用者であるプレイヤーが、その端末装置を介して操作する仮想のキャラクタであるアバターを登場させ、このアバターを仮想社会に住まわせたり、種々の活動をさせるゲームである。なお、この実施形態の説明では、プレイヤーの操作を、適宜アバターの活動として表現する場合がある。
【００１６】
仮想社会は、複数のステージからなり、アバターは、１つのステージ内で移動可能であるとともに、各ステージ間を移動することもできる。各ステージは、懐かしい街、近代的な街、海岸、野原等それぞれ独自に特徴づけされている。
【００１７】
本コンピュータシステムにおいて、ポータルサーバはポータルサイトを運営するとともに、このポータルサイトにログインした端末装置上で上記ゲームのゲーム画像を表示する。これによって、ポータル機能と連携したゲーム画像を表示することができ、興趣性の高いポータルサイトを提供することができる。例えば、ゲームの仮想社会の店舗やアイテムにリンクが設定されており、プレイヤーがマウスクリック等により店舗やアイテムを選択すると、ポータルサーバは、そのプレイヤーの端末装置をリンク先に接続する。また、プレイヤーが、ポータルサイトで検索を行うと、端末装置には、検索内容に対応する仮想社会の領域が検索結果として表示される。例えば、「ゲーム」で検索を行った場合に、ゲームに関連するサイトの一覧が表示されるとともに、仮想社会におけるゲームセンタ等が表示される。
【００１８】
このネットワークゲームにおいて、アバターは、プレイヤーによる端末装置の操作に対応して、仮想社会内を移動する。また、アバターは、服や眼鏡等種々のアイテムを着用する。このアイテムも仮想社会内でアバターが着用する仮想のアイテムである。プレイヤーは、自己のアバターに種々のアイテムを着用させることにより、アバターを自分の気に入った外観で仮想社会で活動させることができる。プレイヤーは、これらのアイテムを、仮想社会内に設置されている店舗で購入したり、他のアバターから貰う・交換する等により、自己のアバターのために入手することができる。アイテムの購入には、この仮想社会内で通用する仮想通貨が使用される。
【００１９】
また、このオンラインゲームにおいては、以下の種々の方法を用いてアバターがメッセージを発信することができる。
（１）メッセージ魚：メッセージを書き込んだ魚を川や海に放し、これを釣り上げた他のアバターがメッセージを読むことができるもの
（２）メッセージ蝶々：メッセージを書き込んだ蝶々を放し、これを捕獲した他のアバターがメッセージを読むことができるもの
（３）メッセージボトル：メッセージを書き込んだメモを入れたボトルを川や海に流し（または街角に置き）、漂着したボトルまたは街角に置かれたボトルを拾い上げた他のアバターがメッセージを読むことができるもの
（４）ロバの耳井戸：井戸に複数のメッセージが入力され、所定のタイミングにランダムに選択されたメッセージが井戸から吹き出し表示され、その場に居るアバターが見ることができるようにしたもの
これらのメッセージ発信手段は、それぞれ特定の相手（アバター）に向けたものではなく、いつ誰が読むか判らない偶然性を持ったメッセージ発信手段である。また、オンラインゲーム中のアバターの日常動作（たとえば釣りや虫取り等）を介してメッセージの受け渡しを可能にしたものである。
【００２０】
<<ゲームの詳細説明>>
以下、図面を参照してゲームについて詳細に説明する。
前記ポータルサーバと複数の端末装置とで創り出される仮想社会は、複数のステージで構成される。各ステージは、たとえば家や店舗のある街、川が流れている野原、海岸等それぞれ異なる態様にされている。
【００２１】
図１は、このうち街のレイアウトを俯瞰的に示す図である。この街には、電車の駅１００や各種の商品を販売している店舗１０１や公園１０２等がレイアウトされている。この実施形態では、１つのステージは、２００セル×２００セルの４００００セルで構成されている。
【００２２】
プレイヤーがこのネットワークゲームにログインすると、そのプレイヤーのアバターが電車の駅１００に立っているところからゲームがスタートする。プレイヤーは、自己のアバターをこの街の中で移動させて店舗１０１や公園１０２等を訪れさせることができる。また、自己のアバターを電車１０３に乗せて他のステージに移動させることもできる。
【００２３】
図２は、図１に示したステージ「街」のモニタ表示例を示す図である。各端末装置のモニタ２６には、図１に示した街の一部の風景がほぼ水平の視線で表示されるため、このような画面となる。この図は、図１の店舗１０１Ａ（たばこや）付近の風景を示している。ここには、自己のアバター１１０および複数の他人アバター１１１が表示されている。プレイヤーは、画面上をマウスクリックすることで、自己のアバター１１０をそのマウスクリックの方向に移動（歩行）させることができる。また、プレイヤーが店舗１０１Ａをマウスクリックすることにより、自己のアバター１１０をこの店舗１０１Ａに入店させることができる。さらに、プレイヤーが電車１０３をクリックすることにより、自己のアバター１１０を電車１０３に乗せて、他のステージに移動させることができる。
【００２４】
図３は、プレイヤーが操作する仮想キャラクタであるアバターの一例を示す図である。同図のアバターは男性のアバターを示している。アバターは、図２の自己のアバター１１０に示したような基本形状（素体）をしており、この素体１２０の上に、プレイヤーの操作により、各種のアイテムが付加されて同図のような外観のアバターが構成される。この図では、素体１２０に、カツラ（髪形）１２１、眼鏡１２２、Ｔシャツ１２３、ジャケット１２４、パンツ１２５、靴１２６のアイテムを着用させて、図示のような外観に仕上げられている。なお、これら各種アイテムは、上述したメッセージ魚、メッセージ蝶々、メッセージボトルと同様に、仮想社会内の店舗から購入されるものである。
【００２５】
このオンラインゲームでは、上述したように、直接的にメッセージを発信するための活動でないアバターの活動を介して、他のアバターに対してメッセージを発信することができる。以下の実施形態では、魚アイテム（メッセージ魚）を用いたメッセージの発信について説明する。
【００２６】
図４は、メッセージ魚を用いてメッセージを受け渡す場合のプレイヤーの操作手順を示すフローチャートである。同図（Ａ）は、第１のアバターが魚にメッセージを書き込んで放流する手順を示したフローチャートである。まず、第１のアバターが店舗でメッセージを書き込むための魚を購入する （Ｓ２０１）。そして、この魚にメッセージおよびこのメッセージを読んでもらいたいアバターの属性を書き込む（Ｓ２０２）。そして、この魚を持って川や海へ移動し（Ｓ２０３）、この魚を放流する（Ｓ２０４）。これにより、魚は（サーバコンピュータの制御により）川や海等の水域を自由に回遊する。
【００２７】
同図（Ｂ）は、第２のアバターが釣りをすることにより、魚を釣り上げてそこに書き込まれているメッセージを読む手順を示すフローチャートである。第２のアバターが、釣り竿を購入する等して、釣り竿を持って（Ｓ２１０）、川や海へ行く（Ｓ２１１）。そして、釣り糸を水中に下ろす（Ｓ２１２）。そうすると、近くに居る魚が食いつくので、引きを確認したときに（Ｓ２１３）、釣り糸を引き上げる（Ｓ２１４）。これにより、魚がつり上がる。そして、この魚に書き込まれているメッセージが表示される（Ｓ２１５）。なお、魚を釣り上げることができた場合に、即メッセージが表示されるのではなく、アバターが一端魚を持ち物として所持し、プレイヤーの表示操作があったときにメッセージが表示されてもよい。
【００２８】
以下、上記のようなゲームの進行を実現するためのコンピュータシステムの動作について説明する。
【００２９】
<<システム構成の説明>>
図５は、上記ネットワークゲームを実行するコンピュータシステムの構成を説明する図である。このコンピュータシステムは、ポータルサーバ１、複数の端末装置２がインターネット３を介して接続されて構成されている。ポータルサーバ１は、一般的なサーバコンピュータまたはワークステーションで構成すればよく、端末装置２は、一般的なパーソナルコンピュータで構成すればよいため、そのハードウェア構成の詳細説明は省略する。
【００３０】
ポータルサーバ１は、仮想社会や複数のアバターのデータを蓄積記憶したサーバデータベース１１（図６、図７参照）、このネットワークゲームの全体進行を制御管理するゲーム進行管理部１２、店舗においてアバターに対するアイテムの販売およびアフィリエイトの発行を制御管理するアイテム販売管理部１３、および、端末装置２等との通信を制御する通信制御部１４を備えている。ゲーム進行管理部１２は、ゲーム進行管理プログラムによるゲーム進行管理処理が、ポータルサーバ１のＣＰＵ等のハードウェア資源によって実現された機能部である。アイテム販売管理部１３は、アイテム販売管理プログラムによるアイテム販売管理処理が、ポータルサーバ１のＣＰＵ等のハードウェア資源によって実現された機能部である。また、通信制御部１４は、通信制御プログラムによる通信制御処理が、ポータルサーバ１のＣＰＵ、通信関連周辺機器等のハードウェア資源によって実現された機能部である。
【００３１】
端末装置２は、自機においてネットワークゲームを進行させるためのデータを記憶するローカルデータベース２１、モニタ２６にゲーム画面を表示させる表示制御部２２、端末装置２の利用者であるプレイヤーの操作を受け付ける操作管理部２３、ポータルサーバ１等との通信を制御する通信制御部２４、および、自機においてゲームの進行を制御するゲーム進行管理部２５を備えている。表示制御部２２にはモニタ２６が接続される。表示制御部２２は、表示制御プログラムによる表示制御処理が、端末装置２のＣＰＵ等のハードウェア資源によって実現された機能部である。操作管理部２３は、操作管理プログラムによる操作管理処理が、端末装置２のＣＰＵやマウス・キーボード等の周辺機器等のハードウェア資源によって実現された機能部である。また、通信制御部２４は、通信制御プログラムによる通信制御処理が、周辺機器２のＣＰＵ、通信関連周辺機器等のハードウェア資源によって実現された機能部である。ゲーム進行管理部２５は、ゲーム進行を制御するプログラムによるゲーム進行制御処理が、端末装置２のＣＰＵ等のハードウェア資源によって実現された機能部である。
【００３２】
端末装置２において、このネットワークゲームは、インターネットブラウザで表示されるものとしてもよく、独立したアプリケーションプログラムで実行されるものとしてもよい。インターネットブラウザで表示されるものとした場合、ゲームプログラム（表示制御プログラム、操作管理プログラム、通信制御プログラム等）は、インターネットブラウザのプラグインとして提供される。これらのプログラムは、ＣＤ−ＲＯＭ等のメディアを用いて端末装置２に予めインストールされていてもよいが、インターネットブラウザのプラグインとして提供される場合等は、端末装置２が最初にポータルサーバ１にログインしたときにポータルサーバ１から自動的にダウンロードされるようにしてもよい。また、ローカルデータベース２１は、上記プログラムと同時に構築されるようにすればよい。ローカルデータベース２１や各プログラムは、端末装置２がポータルサーバ１にログインする都度、最新のものがポータルサーバ１からダウンロードされて更新される。
【００３３】
操作管理部２３は、プレイヤーの操作を監視し、検出した操作内容で、自装置における自己のアバターのデータを更新するとともに、この操作内容を表す操作情報を通信制御部２４を介してポータルサーバ１に送信する。ポータルサーバ１（ゲーム進行管理部１２）は、各端末装置２から送られてきた操作情報に基づいて各プレイヤーのアバターを活動させるようにゲームの進行を管理する。このゲームの進行の管理は、仮想社会の状態を全て記憶するサーバデータベース１１の内容を、そのときの仮想社会の状態に合うように更新することによって行われる。ポータルサーバ１のゲーム進行管理部１２は、データベース１１の更新情報を定期的に各端末装置２に送信する。各端末装置２（各ゲーム進行管理部２５）は、ポータルサーバ１から送られてきた更新情報に基づいてローカルデータベース２１を更新するとともに、これに合わせて画面表示を更新することによってゲームを進行させる。
【００３４】
ポータルサーバ１のアイテム販売管理部１３は、いずれかのプレイヤー（端末装置２）で操作されるアバターが仮想社会に設けられている店舗を訪問したときに機能する。アイテム販売管理部１３は、店舗を訪問したアバターを操作する端末装置２に対してその店舗の販売アイテム情報を送信したり、アバター（プレイヤー）がアイテムを購入したときには、そのアイテムをそのプレイヤーの所有アイテムテーブルに登録し、所有仮想通貨からそのアイテムの価格分を減算する。
【００３５】
図６、図７は、サーバデータベース１１の構成を示す図である。サーバデータベース１１は、仮想社会の構成を記憶する仮想社会データ記憶部３０、複数のアバターについてのデータを記憶するアバターデータ記憶部４０、この仮想社会で販売・所有・着用される複数のアイテムについてのデータを記憶するアイテムデータ記憶部５０、および、アバターが発信したメッセージを記憶するメッセージデータ記憶部６０を有している。
【００３６】
仮想社会記憶部３０は、複数のステージの各々の構成を記憶するステージデータ記憶部３１、各ステージに立っている家や駅や公園等の建物のデータを記憶する建物データ記憶部３２、店舗で販売されるアイテムを管理する販売アイテムデータ記憶部３３を有している。アバターデータ記憶部４０は、ポータルサーバ１に登録されている各アバター毎の情報を記憶するプレイヤーデータ記憶部４１、アバターの素体画像を記憶するアバター素体画像データ記憶部４２を有している。
【００３７】
ステージデータ記憶部３１は、各ステージごとに設定されたステージデータをステージ分記憶している。各ステージデータは、そのステージの名称（たとえば「懐かしい街」等）を示すステージ名称データ、そのステージにおける建物などの配置が書き込まれたマップデータおよびこのマップデータ上に配置される建物を指定する建物指定データ等を含んでいる。
【００３８】
建物データ記憶部３１は、各建物ごとに設定された建物データを各建物の分だけ記憶している。各建物データは、建物の名称（例えば、「○○デパート」等）を示す建物名称データ、その建物の外観の画像である建物画像データ、建物の種類データ（店舗、民家、入室可能か否か等）、入室可能な建物の場合には内部レイアウトデータ、さらに、アイテムを販売する店舗の場合には、販売アイテムを指定するアイテム指定データを含む。なお、建物データは、構造物だけに限らず道端の露店のようなものについても設定されている。
【００３９】
販売アイテムデータ記憶部３３は、この仮想社会のいずれかの店舗で販売されるアイテムごとに設けられる販売アイテムデータを記憶している。各販売アイテムデータは、そのアイテムをアイテムデータ記憶部５０に記憶されているアイテムから指定するアイテム指定データおよびそのアイテムの価格を示す価格データを含んでいる。
【００４０】
アイテムデータ記憶部５０は、各アイテムごとに設定されたアイテムデータを記憶している。各アイテムデータは、そのアイテムを識別するためのアイテムＩＤ、アイテムの名称（「赤い傘」等）を示すアイテム名称データ、アイテムの外観等を表すアイテム画像データ、そのアイテムがアバターのどこに着用されるか等を指示するアイテム種類データ等を含んでいる。
【００４１】
なお、このゲームでアバターが着用するアイテムは、衣類に限定されず、たとえば、釣り竿や虫取り網等の道具類も含まれる。このような道具類も店舗で販売される。
また、上述したメッセージ魚、メッセージ蝶々、メッセージボトルも店舗で販売されるアイテムの種類である。これら３種類の各アイテムは、それぞれ大きさ等が異なる更に複数種類のアイテムからなる。たとえば、メッセージ魚の場合、それぞれ大きさが異なる「ヒトコトイワシ」や「フタコトアジ」等のアイテムが存在する。これら「ヒトコトイワシ」、「フタコトアジ」はアイテム名称である。
【００４２】
これらメッセージ魚、メッセージ蝶々、メッセージボトルは、店舗で販売されるときは通常のアイテムと同様であるが、アバターが、このアイテムを購入してメッセージを書き込んで手放す（放流する、放す、流す、置く等）ことにより、それぞれ上述の特徴をもったコミュニケーションアイテムとなり、サーバデータベースのメッセージデータ記憶部６０（後述）に登録される。
【００４３】
また、プレイヤーデータ記憶部４１は、ポータルサーバ１に登録されているアバター（プレイヤー）毎に設定されたプレイヤーデータを記憶している。各プレイヤーデータは、そのプレイヤーのアバターの名称を示すアバター名称データ、そのプレイヤーが選択したアバターの素体の画像を指定する素体選択データ、このアバターの属性を示す属性データ、このアバターがどのステージの何処の座標に存在するかを示す位置データ、このアバターの動作（姿勢）を示す動作データ、このアバターが所有または着用しているアイテムが登録されるアイテムテーブル、および、仮想社会内で使用される仮想通貨の所持金額を表す所持金額データを含んでいる。
【００４４】
アバター素体画像データ記憶部４２は、プレイヤーデータの素体選択データによって選択される複数のアバター素体画像を記憶している。アバター素体画像は、たとえば、図２に示したアバター１１０等のような画像である。
【００４５】
アバターの属性データは、このアバターまたはプレイヤーの属性を示すデータであり、図７（Ａ）に示すように、年齢層、性別、趣味、地域等のカテゴリーのデータからなっている。この属性データは、プレイヤーにより、このネットワークゲームに参加登録するときに入力される情報であり、プレイヤー自身の属性が入力される場合、プレイヤーが操作する仮想のアバターに付与したい属性が入力される場合がある。
【００４６】
図７（Ａ）において、年齢層は、１０代、２０代、３０代、４０代、５０代以上の５つの選択肢から１つが選択される。性別は、男／女からどちらかが選択される。趣味は、ゲーム、音楽、スポーツ、映画、ドライブ・ツーリング、読書から１または複数が選択される。地域は、４７都道府県から１つが選択される。
なお、プレイヤーの属性を表すデータは、これらに限定されない。また、年齢層，趣味，地域の選択肢の設定態様も上記に限定されない。
【００４７】
図７（Ｂ）は、メッセージデータ記憶部６０のうち、魚データの記憶エリアを示した図である。魚データは、水中に放流されたメッセージ魚について登録されたデータであり、この魚を識別するための魚ＩＤ、サイズデータ、アイテムＩＤ、捕獲条件データ、位置情報、捕獲中フラグ、メッセージ本文等の内容で構成される。
【００４８】
サイズデータは、この魚の大きさを表すデータである。このサイズデータによって、魚の外観上の大きさが決定されるとともに、書き込み（対応付けて登録）可能なメッセージの文字数が決定される。例えば、「ヒトコトイワシ」はサイズが５ｃｍで、２０文字までメッセージを登録することができ、「フタコトアジ」はサイズが１０ｃｍで、４０文字までメッセージを登録することができる。アイテムＩＤは、アイテムデータ記憶部５０に記憶されているアイテムデータを指定するＩＤである。このアイテムＩＤでアイテムデータを指定することにより、その指定されたアイテムデータに含まれるアイテム画像データを読み出してこのメッセージ魚の外観を作成することができる。捕獲条件データは、この魚を釣り上げることができるアバターの条件（属性）を指定するデータである。この捕獲条件データは、この魚にメッセージを書き込むプレイヤーが、このメッセージを読んでもらいたいアバター（プレイヤー）を絞り込むために、その属性を設定する。この捕獲条件データは、図７（Ａ）に示した複数のカテゴリーの全部または一部について設定される。捕獲条件データが設定されていないメッセージ魚は、全てのアバターによって釣り上げられることができる。
【００４９】
なお、プレイヤーデータにアバターの属性が設定されていない場合には、捕獲条件が設定されていないメッセージ魚、すなわち上記の全てのアバターによって釣り上げられるメッセージ魚のみ釣り上げることができる。
【００５０】
位置情報は、この魚がどこを泳いでいるかを示すデータであり、ステージを示す情報とそのステージ内での座標からなる。魚の回遊は、プレイヤーが制御するのではなく、ポータルサーバ１のゲーム進行管理部１２が、独自のアルゴリズムで回遊経路を決定する。ゲーム進行管理部１２は、上記アルゴリズムで各魚の回遊経路を決定して、定期的に各魚の位置情報を更新する。
【００５１】
なお、ゲーム進行管理部１２が、魚の位置情報を更新せず、常に放流された位置をその魚の位置情報としてもよい。また、位置情報が魚データに含まれなくてもよい。この場合には、魚の釣り上げが魚の位置とは無関係に決定され、例えば、捕獲条件データとアバターの属性データと、魚サイズと釣竿の性能との一致だけで、魚の釣り上げの成否が決定される。
【００５２】
捕獲中フラグは、いずれかの端末装置２において、この魚が釣り糸に掛かっていることを示すフラグである。このフラグがセットされていると、他の端末装置２ではこの魚を捕獲することができない。端末装置２におけるゲーム進行において、アバターが釣り糸を垂らした付近に魚がいると、その魚が釣り糸に掛かり、このことがポータルサーバ１に通知される。ポータルサーバ１は、この通知に対応して捕獲中フラグをセットする。しかし、魚が釣り糸に掛かっても、引き上げるのが遅れたり、上記捕獲条件が満たされなかった場合には、この魚は逃げてしまう。端末装置２から魚が逃げたことが通知されると、ポータルサーバ１は、この捕獲中フラグをリセットする。一方、端末装置２から、魚が逃れることなく釣り上げられたことが通知されると、メッセージ本文をその端末装置２に送信するとともに、この魚データをメッセージデータ記憶部６０から消去する。
【００５３】
メッセージ本文は、テキストデータからなる。文字数は、魚のサイズに応じて異なり、２００文字〜４００文字程度である。なお、この実施形態では、メッセージ魚に設定（対応付けて登録）するメッセージをテキストとしているが、メッセージはテキストに限定されない。たとえば、音声、静止画、動画など端末装置から出力可能なものであれば、どのようなものでもよい。
【００５４】
ポータルサーバ１は、サーバデータベース１１として、図６，図７（Ｂ）に示すデータ群を常時記憶している。端末装置２のローカルデータベース２１は、サーバデータベースとほぼ同様の構成・内容を有している。サーバデータベース１１とローカルデータベース２１とで異なる点は、ローカルデータベース２１が、他のプレイヤーが操作するアバター（他人アバター）のプレイヤーデータ（４１）を持たない点程度である。ローカルデータベース２１のうち、仮想社会データ（３０）、アイテムデータ（５０）の固定部分は、プログラムと一緒にインストールされる。そして、ゲームに進行に応じて更新される部分は、プレイヤーの操作によって端末装置２が、ポータルサーバ１にログインする都度、更新データとしてダウンロードされる。
【００５５】
なお、上記ゲームにおいて、自己のアバターがステージを移動すると、移動先のステージに位置する他人アバターのプレイヤーデータ等がダウンロードされる。なお、このときに移動前のステージに位置していた他人アバターのプレイヤーデータは破棄される。
【００５６】
また、自己のアバター，他人アバターは常に移動し、着用するアイテムや所持するアイテムが変更されることもあり、アバターの属性データも変更されこともある。このため、ポータルサーバ１は、各端末装置２からアバターの位置の変更や属性データの変更等のプレイヤーデータの変更を示す情報を受信したときに、サーバデータベース１１のプレイヤーデータを更新し、この更新したデータを更新情報として定期的に各端末装置２に送信する。
【００５７】
アバター（プレイヤー）が、メッセージ魚アイテムを購入して川や海に放流したとき、魚データが作成され、この魚データが各端末装置２からポータルサーバ１にアップロードされる。ポータルサーバ１は、この魚データをメッセージデータ記憶部６０に登録し（メッセージを仮想オブジェクトに対応づけて登録し）、定期的なデータ更新時にこの魚データを各端末装置２にダウンロードする。
【００５８】
この魚データの各端末装置２へのダウンロードは、トラフィックを軽減するため、魚ＩＤ、捕獲条件データ、サイズ、外観画像指定データ、位置情報のみをログイン時や定期的なデータ更新時等に行い、ある端末装置２から釣り上げられた旨の通知があったとき、その端末装置２のみにメッセージ本文をダウンロードする。
【００５９】
もっとも、以下のような方式を採用してもよい。
（１）ログイン時等に、全ての端末装置２に全ての魚データ（メッセージ本文を含む）をダウンロードする。
（２）魚データの位置情報に基づき、その魚がどのステージにいるかを判断し、同じステージにいるアバターの端末装置２のみに、データをダウンロードする。
【００６０】
魚データのメッセージ本文を、その端末装置に送信したのち、その魚データをメッセージデータ記憶部６０から消去し、各端末装置２に対してその魚が釣り上げられた旨を通知する。
各端末装置２は、魚が釣り上げられた旨の通知を受信すると、既にダウンロードされているその魚の魚データを消去する。
【００６１】
≪動作の説明≫
図８〜図１３のフローチャートを参照して、図４に示したコンピュータシステムの動作について説明する。
図８（Ａ）は、ログイン時の動作を示すフローチャートである。プレイヤーが端末装置２を用いて、ＩＤ，パスワードを入力する等のログイン操作を行うと（Ｓ１）、端末装置２は、このログイン操作情報をポータルサーバ１に送信する（Ｓ２）。
【００６２】
ポータルサーバ１は、端末装置２からログイン操作情報を受信すると（Ｓ３）、（このログイン操作情報が正しいことを前提として）そのプレイヤーをログイン登録し、そのアバターを仮想社会に登場させるべく処理を行う（Ｓ４）。そして、このプレイヤーの操作する端末装置２に対して最新のデータを送信する（Ｓ５）。
【００６３】
端末装置２は、ポータルサーバ１から送られてきたデータを受信し、このデータで自装置のローカルデータベース２１を更新する（Ｓ６）。そして、このローカルデータベース２１に書き込まれているデータに基づいて仮想社会をモニタ２６に表示するとともに、この仮想社会にそのとき登場しているアバター（自己のアバターを含む）を表示して、この端末装置２においてゲームをスタートさせる（Ｓ７）。
【００６４】
ゲームの進行は、複数の端末装置２から送信されてくる操作情報に基づいてポータルサーバ１のゲーム進行管理部１２が管理しており、ログインした端末装置２では、ポータルサーバ１から送られてくる更新データに基づき、ゲーム進行管理部２５がゲームの進行を管理する。
【００６５】
図８（Ｂ）は、端末装置２におけるゲーム進行処理を示すフローチャートである。この処理は定期的に実行される。ポータルサーバ１のゲーム進行管理部１２は、まず、サーバデータベース１１のメッセージデータ記憶部６０に登録されている魚データの位置を更新する（Ｓ９）。この魚データの位置は、端末装置２からの操作に依存しないため、ポータルサーバ１側で決定する。次に、サーバデータベース１１の更新内容に基づき、ローカルデータベースを更新するための更新データを各端末装置２に対して定期的に送信する（Ｓ１０）。この更新データには、上記魚データの位置情報や各アバターの位置や動作等を更新するためのデータが含まれる。端末装置２は、ポータルサーバ１から送られてきた更新データを受信して（Ｓ１１）、ローカルデータベース２１を更新するとともに（Ｓ１２）、この更新データに基づいて、モニタ２６の画面表示を更新する（Ｓ１３）ことにより、ゲームを進行させる。
【００６６】
図９は、プレイヤーによるアバターの動作制御操作に対応したコンピュータシステムの動作を示すフローチャートである。
同図（Ａ）は、端末装置２の動作を示すフローチャートである。プレイヤーは、自己のアバターに何らかの動作をさせる場合、端末装置２のマウスやキーボードを操作してアバターがその動作を行うように指示する。たとえば、アバターを移動させる場合には、モニタ２６の画面上において、移動させたい方向の適当な位置、または、入店させたい店舗や乗車させたい乗り物等をマウスでクリックする。また、釣り糸を海に垂らしたい場合には、釣り竿アイテムを右クリックしてプルダウンメニューから「下ろす」を選択する。プレイヤーにより動作の指示を受け付けたとき（Ｓ２０）、この指示がアバターを他のステージに移動させる指示でない場合には（Ｓ２１でＮＯ）、端末装置２は、アバターの外観をその動作をしている状態に変化させるとともに（Ｓ２２）、この動作情報をポータルサーバ１に送信する（Ｓ２３）。たとえば、移動させたい方向の適当な位置や入店させたい店舗等がクリックされた場合、自己のアバターは同一ステージ内で移動するよう制御され、図１における電車１０３等の乗り物がクリックされた場合、自己のアバターは他のステージに移動するよう制御される。また、釣り糸を垂らす旨のメニューが選択された場合、アバターが装着しているアイテムである釣り竿を下にさげるよう形状を変化させる。また、釣り糸を引き上げる旨のメニューが選択された場合、アバターが装着しているアイテムである釣り竿を引き上げるよう形状を変化させる。
【００６７】
ただし、ステップＳ２０の動作制御操作が、アバターを他のステージに移動させる旨の操作であった場合には（Ｓ２１でＹＥＳ）、端末装置２は、このステージ移動操作情報をポータルサーバ１に送信する（Ｓ２５）。その後、ポータルサーバ１から移動先の新たなステージのデータを受信して（Ｓ２６）、このデータでローカルデータベース２１を更新し（Ｓ２７）、このステージの画像とアバターを表示してこのステージにおいてゲームを再開する（Ｓ２８）。
【００６８】
同図（Ｂ）は、端末装置２から、動作情報を受信したときのポータルサーバ１の動作を示すフローチャートである。ポータルサーバ１は、端末装置２が、同図（Ａ）のステップＳ２３で送信した動作情報を受信する（Ｓ３１）。そして、この端末装置２に対応するプレイヤーデータ（位置データ、動作データ）をこの動作情報に基づいて更新する（Ｓ３２）。この更新されたプレイヤーデータは、他の端末装置２に対しては、図８（Ｂ）に示した定期的なデータ更新時に送信される。
【００６９】
同図（Ｃ）は、端末装置２から、ステージを移動する旨の操作情報を受信したときのポータルサーバ１の動作を示すフローチャートである。ポータルサーバ１は、端末装置２が、同図（Ａ）のステップＳ２５で送信したステージ移動情報を受信して（Ｓ３４）、この端末装置２に対応するアバターデータの位置データや動作データをこのステージ移動情報に基づいて更新する（Ｓ３５）。位置データは、新しいステージへ登場したときのデフォルトの位置に設定される。そして、この新たなステージの情報を端末装置２に対して送信する（Ｓ３６）。このアバターの更新された位置データは、図８ （Ｂ）に示した定期的なデータ更新時に、他の各端末装置２に送信される。
【００７０】
このように、端末装置２では、動作情報をポータルサーバ１に送信するとともに、（ポータルサーバからの更新データの受信を待たずに）自己のアバターの姿勢や位置を更新している。これにより、操作に対応した自己のアバターの姿勢や位置の更新が遅れないようにしている。なお、自己のアバターについても、ポータルサーバ１からの更新データの受信を待って移動させるようにしてもよい。
【００７１】
図１０は、端末装置２が行うメッセージ登録動作を示すフローチャートである。プレイヤーが店舗で魚を購入することによって、この処理がスタートする。プレイヤーが魚を購入すると（Ｓ４０）、端末装置２は、この魚のメッセージ登録ウィンドウを表示する（Ｓ４１）。このメッセージ登録ウィンドウには、捕獲条件入力部およびメッセージ本文入力部が設けられている。
【００７２】
端末装置２は、まず捕獲条件の入力を受け付ける（Ｓ４２）。捕獲条件は、上述したように図７ （Ａ）に示すアバターの属性の全部または一部を指定するデータである。モニタ２６に表示される入力ウィンドウには、例えば、図７（Ａ）で示す情報が一覧表示され、この一覧の１カテゴリーから１選択肢を選択する操作をプレイヤーが行うことで捕獲条件が入力される。
【００７３】
次に、端末装置２は、メッセージの入力を受け付ける（Ｓ４３）。上述したように、入力を受け付けるメッセージの文字数は魚のサイズによって異なる。そして、アバターによってメッセージ魚の放流の動作が行われたとき（Ｓ４４）、上記操作で生成されたメッセージ魚のデータ（メッセージデータ）を、ポータルサーバ１に送信して（Ｓ４５）、動作を終了する。
【００７４】
ここで、端末装置２からポータルサーバ１に送信されるメッセージデータは、アイテムＩＤ、サイズ、捕獲条件、メッセージ本文、放流位置等である。なお、これらのデータのうち、アイテムＩＤ、サイズは、アイテムデータから取得されて送信される。サイズについては、アイテムデータに含まれるアイテム種類データ（メッセージ魚では魚の種類を示す）から取得される。
【００７５】
なお、プレイヤーの魚の購入後、即メッセージ登録ウィンドウが表示されなくてもよく、魚が一端アバターの持ち物として所持され、プレイヤーの表示操作を受け付けた場合に、メッセージ登録ウィンドウが表示されてもよい。
【００７６】
ポータルサーバ１は、端末装置２から送信されてきたメッセージデータを受信する（Ｓ４７）。そして、このメッセージデータを、サーバデータベースのメッセージデータ記憶部６０に魚データとして登録する（Ｓ４８）。すなわち、ポータルサーバ１は、受信したメッセージデータに魚ＩＤを付して魚データを生成し、メッセージデータ記憶部６０に登録する。この登録された魚データのＩＤ，位置データ，アイテムＩＤ，サイズデータ、捕獲条件及び位置情報は、図８（Ｂ）に示した定期的なデータ更新時に、他の各端末装置２に送信される。
【００７７】
図１１は、端末装置における魚捕獲処理動作すなわち釣り動作を示すフローチャートである。
プレイヤーが自己のアバターが所持している釣り糸を川や海に垂らしたとき（Ｓ４９）、この動作がスタートする。まず、釣り糸を垂らした位置（ウキの位置）の情報を割り出す（Ｓ５０）。そして、この位置情報に基づき付近に魚がいるか否かを検索する（Ｓ５１）。この検索は、ポータルサーバ１からローカルデータベース２１にダウンロードされている魚データの位置情報に基づいて判断する。付近に魚がいない場合には（Ｓ５２でＮＯ）、糸が引き上げられるまで（Ｓ５３）、Ｓ５０以下の動作を繰り返し実行する。アバターが釣り糸を移動させることがあるため、毎回位置情報は割り出される（Ｓ５０）。
【００７８】
一方、付近に魚がいる場合には、その魚と釣り糸（うき）との距離に応じた確率に基づいて、今回この魚が掛かる（食いつく）か否かを演算する（Ｓ５４）。魚が掛からなかった場合には（Ｓ５５でＮＯ）、Ｓ５０にもどって、Ｓ５０以下の動作を再度実行する。したがって、付近に魚がいる場合には、その魚が遠くへ移動してしまわないかぎり、掛かるまで毎回Ｓ５４の確率演算が実行される。
【００７９】
ここで、上記魚と釣り糸（うき）との距離に基づく食いつきの確率は、魚とうきが同一セルにある場合には１００％であり、１セルずれるごとに３０％ずつ小さくなる。たとえば、うきが魚の隣のセルにある場合には確率７０％となる。
【００８０】
一方、魚が掛かったと判定された場合には（Ｓ５５でＹＥＳ）、捕獲中情報をポータルサーバ１に送信する（Ｓ５６）。ポータルサーバ１では、他のアバターがこの魚を既に捕獲中か否かを判定し、他のアバターが捕獲中なければ捕獲許可情報を返信し、他のアバターが既に捕獲中の場合には捕獲不許可情報を返信してくる（図１２（Ａ）参照）。端末装置は、この捕獲許可／不許可情報を受信する（Ｓ５７）。次に、この魚データのサイズおよび捕獲条件を読み出し、釣り竿の性能がこの魚のサイズに適合しているか、および、このアバターの属性が魚の捕獲条件に適合しているかを判定する（Ｓ５８）。釣竿の性能と魚のサイズの適合を判断する理由は、釣竿の機能が複数ランク設定されており、釣竿のランク毎に釣り上げ可能な魚のサイズの限界値が設定されているからであり、このため、釣竿のランクによっては大きすぎで釣り上げることができない魚があるからである。なお、釣竿（アイテム）のＩＤ、このランク、及び上記魚サイズの限界値は、互いに対応付けてサーバデータベース１１及びローカルデータベース２１に記憶されている。こののち、画面のウキを動かしてプレイヤーに魚が掛かっている旨（引き）を表示する（Ｓ５９）。
【００８１】
メッセージ魚アイテム、釣り竿アイテムはともに店舗で販売されるアイテムであり、それぞれ価格の異なる複数種類がある。メッセージ魚は、価格の高いアイテムほど外観が大きく、書き込みのできるメッセージの文字数も多い。また、釣り竿アイテムは、価格の高いアイテムほど太く大きい魚を釣り上げることができる性能を有している。ステップＳ５８では、釣り竿の太さが釣り上げようとしているメッセージ魚の大きさに適合しているか、すなわち、このメッセージ魚以上の大きさの魚を釣り上げ可能な太さであるかを判断し、適合しているときにＹＥＳの判断をする。
【００８２】
なお、上記捕獲条件の適合／不適合の判定において、完全に適合していなくても、近似している場合には、ある程度の確率で適合と認めるようにしてもよい。すなわち、捕獲条件と属性が一致しないカテゴリーの選択肢リスト（図７（Ａ）参照）において、捕獲条件と属性とが近い位置関係にあるとき、所定の確率で適合と判定するようにしてもよい。図７（Ａ）に示す選択肢は、たとえば、年齢順（１０代、２０代、・・・）や地域順（北海道、青森、岩手、・・・）のように、近似するものから順にリスト化されている。したがって、捕獲条件と属性とが一致しない場合でも、図７（Ａ）の選択肢リストにおける距離が近い場合には略一致と判断して、ある程度の確率で適合と判断する処理を適合判断の変形例とすることが可能である。
【００８３】
この場合において、捕獲条件と属性との距離に応じて捕獲確率を決定してもよい。たとえば、捕獲条件が２０代であった場合に、属性が２０代（距離０）であれば捕獲確率１００パーセント、属性が１０代、３０代（距離１）であれば捕獲確率５０パーセント、属性が４０代（距離２）であれば捕獲確率２０パーセントとするなどである。
【００８４】
なお、魚がかかるかどうかの判定方法は、上記に限定されない。すなわち、上記実施形態では、位置情報、捕獲条件、魚サイズに基づいて捕獲の成否を判定しているが、これらの条件の一部を用いてもよく、また、例えば魚データが魚種類を示すデータを含み、アバターが海で釣りをしている場合には、メッセージデータ記憶部６０で記憶される海魚の魚でデータから抽選によって１の魚が選択されて掛かるようになっていてもよい。
後ろに下げました）
この引きに応じてプレイヤー（アバター）が、一定時間以内に釣り糸を引き上げたか否かを判断する（Ｓ６０、Ｓ６１）。一定時間以内に引き上げられなかった場合には（Ｓ６０でＮＯ、Ｓ６１でＹＥＳ）、魚が逃げた旨の処理を行って（Ｓ６２）、動作をＳ５０に戻す。
【００８５】
また、引きが発生してから一定時間以内に釣り糸が引き上げられた場合には（Ｓ６０でＹＥＳ）、Ｓ５７で受信した情報が捕獲許可情報であったか、および、Ｓ５８で判定した釣り竿とサイズ、アバター属性と捕獲条件が適合しているかを判断し（Ｓ６３）、この条件を満たした場合には（Ｓ６３でＹＥＳ）、釣り上げ処理（Ｓ６４）を実行する。一方、Ｓ５７で受信した情報が捕獲不許可情報であった場合またはＳ５８の条件が適合していなかった場合には（Ｓ６３でＮＯ）、釣り糸を引き上げたが糸が切れて魚が逃げてしまった旨の処理を行って（Ｓ６５）、動作を終了する。
【００８６】
ここで、ステップＳ６２の魚が逃げた旨の処理は、ウキの引き画像を停止するとともに、ポータルサーバ１に対して捕獲失敗情報を送信する処理である。また、ステップ６５の糸が切れた旨の処理は、引き上げ途中で釣り糸の画像を消去してしまうとともに、ポータルサーバ１に対して捕獲失敗情報を送信する処理である。なお、切れてしまった釣り竿の糸は、次の使用時に自動的に復活する。
このように、この処理は、ステップＳ４９で釣り糸を水中に垂らしたときスタートし、ステップＳ５３またはステップＳ６０で釣り糸を引き上げたことによって終了する。
【００８７】
図１２（Ａ）は、端末装置２から捕獲中情報を受信したポータルサーバ１の動作を示すフローチャートである。端末装置から捕獲中情報を受信すると（Ｓ９０：図１１のＳ５６に対応）、この捕獲中情報に含まれている魚ＩＤに基づいてサーバデータベース１１を検索し、この魚データの捕獲中フラグがセットされているか否かを判断する（Ｓ９１）。他の端末装置において捕獲中でない場合にはこの捕獲中フラグがリセットされているため（Ｓ９１でＮＯ）、捕獲中フラグをセットしたのち（Ｓ９２）、今回捕獲中情報を送信してきた端末装置に対して捕獲許可情報を送信する（Ｓ９３）。一方、既に他の端末装置において捕獲中であった場合には捕獲中フラグがセットされているため（Ｓ９１でＹＥＳ）、今回捕獲中情報を送信してきた端末装置に対して捕獲不許可情報を送信する（Ｓ９４）。
【００８８】
同図（Ｂ）は、端末装置２から捕獲失敗情報を受信したポータルサーバ１の動作を示すフローチャートである。端末装置から捕獲失敗情報を受信すると（Ｓ９５：図１１のＳ６２，Ｓ６５に対応）、この捕獲中情報に含まれている魚ＩＤに基づいてサーバデータベース１１を検索し、この魚データの捕獲中フラグをリセットする（Ｓ９６）。これにより、この魚が、再度捕獲可能になる。
【００８９】
図１３は、図１１のＳ６４の釣り上げ処理を示すフローチャートである。まず、ポータルサーバ１に対して捕獲成功情報を送信する（Ｓ７０）。そして、これに対応してポータルサーバ１から、釣り上げた魚に書き込まれているメッセージ本文を受信する（Ｓ７１）。次に、アバターの釣り上げ動作にしたがって、魚画像をモニタ２６に表示し（Ｓ７２）、この魚を所有アイテムとしてアイテムテーブルに登録する（Ｓ７３）。次に、プレイヤー（アバター）によるメッセージ表示装置に対応して （Ｓ７４）、メッセージ本文を表示する（Ｓ７５）。プレイヤー（アバター）による表示消去操作があるまで（Ｓ７６）、表示を継続し、消去操作があったとき（Ｓ７６でＹＥＳ）、表示を消去して （Ｓ７７）、動作を終了する。
【００９０】
ポータルサーバ１は、端末装置２から送信されてきた捕獲成功情報を受信して（Ｓ８０）、この捕獲成功情報に含まれる魚ＩＤで識別される魚データのメッセージ本文を読み出し（Ｓ８１）、このメッセージ本文を端末装置２に対して送信する（Ｓ８２）。こののち、この魚データを消去して（Ｓ８３）、動作を終了する。この魚データの消去は、図８で示すＳ１０によって、ポータルサーバ１から各端末装置２に通知され、この通知を受けた端末装置２はローカルデータベース２１のメッセージデータ記憶部から対応する魚データを消去する。
【００９１】
以上の処理により、釣り上げられた魚は、ポータルサーバが管理するメッセージから、アバターの所有するアイテムとなる。アバターは、この魚アイテムをクリックすることにより、その後何度でもメッセージを表示させることができる。また、このアイテムは他のアイテムと同様、売買，交換，捨てること等が可能である。
【００９２】
≪他の実施形態≫
以上は、メッセージ魚について説明したが、次にメッセージ蝶々，メッセージボトルについて説明する。メッセージ蝶々，メッセージボトルは、それぞれメッセージ魚の変形例である。メッセージ蝶々，メッセージボトルは、それぞれ以下の点でメッセージ魚と異なっている。
【００９３】
メッセージ魚は、川または海の水中を泳いでおり釣り上げるまで魚影としてしか見ることができないが、メッセージ蝶々は、全てのステージの空中を飛ぶことが可能であり、常に見ることができる。メッセージ魚は、選択条件として捕獲されるアバターの属性を設定可能であるが、メッセージ蝶々は、選択条件を設定できない。メッセージ魚は、魚が近くにいれば、アバターのスキルに関係なく釣り糸に掛かるが、メッセージ蝶々は、道具アイテムである虫取り網を上手く操作しないと蝶々を捕まえることができない。しかしながら、虫取り網を上手く操作することさえできれば、アバターはメッセージ蝶々を捕まえることができ、捕獲されるアバターの属性を選ばない。
なお、この実施形態では、蝶々を用いているが、空中を飛ぶ昆虫としては蝶々に限定されるものではなく、他の昆虫たとえはトンボなどを用いることができる。
【００９４】
また、メッセージボトルは、街角に置かれていたり、海辺に打ち上げられていたりするものをアバターが拾い上げることができるため、取得（捕獲）にスキルは必要ないが、メッセージ魚と同様に、メッセージを読むことができるアバターの条件を設定することができる。この条件は、捕獲条件ではなく、捕獲した後にボトルの蓋を開けてメッセージを取り出すことができるための条件である。
【００９５】
図１４を参照して、メッセージ蝶々を用いてメッセージを受け渡す場合のプレイヤーの操作手順について説明する。
【００９６】
同図（Ａ）は、第１のアバターが蝶々にメッセージを書き込んで空中に放す手順を示したフローチャートである。まず、第１のアバターが店舗でメッセージを書き込むための蝶々を購入する（Ｓ２２０）。そして、この蝶々にメッセージを書き込む（Ｓ２２１）。そして、この蝶々を任意の場所で空中に放す（Ｓ２２２）。これにより、この蝶々は（ポータルサーバ１の制御により）自由に全てのステージを飛び回ることができる。
【００９７】
同図（Ｂ）は、第２のアバターが虫取り網で虫取りをすることにより、蝶々を捕獲してそこに書き込まれているメッセージを読む手順を示すフローチャートである。第２のアバターが、虫取り網を持って（または虫取り網を購入して：Ｓ２２５）、町中や野原で蝶々を見つけ出す（Ｓ２２６）。そして、この蝶々を網の中に収めるように虫取り網を操作して蝶々を捕獲する（Ｓ２２７）。蝶々の捕獲は、アバター（プレイヤー）が虫取り網を振って蝶々を網の中に捕らえたとき、すなわち、アバターによって振られた虫取り網の軌跡上に蝶々が居た場合に成功する。蝶々を捕らえようとすれば、アバター（プレイヤー）は良いタイミングに良い位置に虫取り網を振らなければならないため、この蝶々の捕獲の成否にはアバター（プレイヤー）のスキルが反映される。なお、蝶々が捕獲されると、この蝶々に書き込まれているメッセージが表示される（Ｓ２２８）。
【００９８】
なお、メッセージ蝶々は、空中を飛んでおり、常にアバター（プレイヤー）から見えているため、端末装置２は、ポータルサーバ１から通知された位置情報に基づいて蝶々を表示する処理を行う。
【００９９】
同図（Ｃ）は、第２のアバター（プレイヤー）が蝶々の捕獲動作を行ったとき、すなわち、アバターが蝶々のいる場所に虫取り網を振ったときに実行される動作を示すフローチャートである。アバターが蝶々の捕獲動作を行うと、すなわちプレイヤーによる捕獲操作を受け付けると（Ｓ１４０）、端末装置２は、ポータルサーバ１に対して捕獲動作情報を送信して捕獲を許可するか否か、すなわち、既に（ポータルサーバ１から画像の更新情報を受信する前に）他のアバター（プレイヤー）が先に蝶々を捕獲しているか否かを問い合わせる（Ｓ１４１）。
【０１００】
ポータルサーバ１は、この捕獲動作情報を受信して図１２（Ａ）のＳ９１〜Ｓ９４の処理を実行する。すなわち、先にこの蝶々を捕獲しているか否かをこの蝶々のデータの捕獲中フラグがセットされているか否かに基づいて判断し（Ｓ９１）、他の端末装置で捕獲中でない場合にはこの捕獲中フラグをセットしたのち（Ｓ９２）、端末装置に対して捕獲許可情報を送信する（Ｓ９３）。一方、既に他の端末装置が捕獲中であった場合には、端末装置に対して捕獲不許可情報を送信する（Ｓ９４）。
【０１０１】
端末装置２は、ポータルサーバ１から情報を受信し（Ｓ１４２）、この受信した情報が捕獲許可情報であった場合には（Ｓ１４３でＹＥＳ）、捕獲成功処理を実行する（Ｓ１４４）。この捕獲成功処理は、図１３のメッセージ魚の釣り上げ処理とほぼ同様であり、Ｓ７２の魚画像を表示する動作に代えて、虫取り網の中に蝶々が捕獲されている画像を表示する。一方、ポータルサーバ１から受信した情報が捕獲不許可情報であった場合には（Ｓ１４３でＮＯ）、端末装置２は、アバターが蝶々の捕獲を失敗した画像（蝶々が網から逃げた画像）を表示して（Ｓ１４５）動作を終了する。
【０１０２】
メッセージ蝶々には捕獲条件が設定されないため、メッセージ魚の捕獲条件とアバターの属性とが合致する否かの判定（図１１のＳ５８、Ｓ６３）は行われない。また、端末装置２は、捕獲許可情報を受信した場合、例外なく捕獲成功処理に進み（Ｓ１４３参照）、一端捕獲した蝶々を取り逃がすことがないため、ポータルサーバ１が図１２（Ｂ）の処理を実行することはない。
【０１０３】
図１５は、メッセージボトルを用いてメッセージを受け渡す場合のプレイヤーの操作手順を示すフローチャートである。同図（Ａ）は、第１のアバターがメッセージを書き込だメモを封入したボトルを放流するまたは街角におく手順を示したフローチャートである。まず、第１のアバターが店舗でメッセージを書き込むボトルとメモを購入する（Ｓ２３０）。そして、メモにメッセージおよびこのメッセージを読んでもらいたいアバターの属性を書き込んでボトルに封入する（Ｓ２３１）。そして、このボトルを流す場合には、ボトルを持って川や海へ移動し（Ｓ２３２）、ボトルを川または海に流す（Ｓ２３３）。これにより、ボトルは（サーバコンピュータの制御により）漂流し、どこかの岸に漂着する。なお、ボトルの漂流制御を行わず、所定の漂流ポイントから１のポイントが抽選されて、このポイントにボトルを配置する等してもよい。また、ボトルを流さない場合には、街角等の任意の場所に置くことができる（Ｓ２３４）。この場合、ボトルは移動せず誰かが拾い上げるまで同じ位置にあり、ボトルを置いたアバターが、誰が拾い上げるか見届けることができる。
【０１０４】
同図（Ｂ）は、第２のアバターを操作する端末装置において、第２のアバター（プレイヤー）がボトルを拾い上げる操作が行われたときに実行される動作を示すフローチャートである。第２のアバターが海岸または街角でボトルを拾う操作がされると（Ｓ１５０）、端末装置２は、ポータルサーバ１に対して拾い上げ動作情報を送信してこの拾い上げを許可するか否か、すなわち、既に（ポータルサーバ１から画像の更新情報を受信する前に）他のアバター（プレイヤー）が先にボトルを拾い上げているか否かを問い合わせる（Ｓ１５１）。
【０１０５】
ポータルサーバ１は、この捕獲動作情報を受信して図１２（Ａ）のＳ９１〜Ｓ９４の処理を実行する。すなわち、先にこのボトルを拾い上げているか否かをこのボトルのデータの取得中フラグがセットされているか否かに基づいて判断し（Ｓ９１）、他の端末装置で取得中でない場合にはこの取得中フラグをセットしたのち（Ｓ９２）、端末装置に対して取得許可情報を送信する（Ｓ９３）。一方、既に他の端末装置が取得中であった場合には、端末装置に対して取得不許可情報を送信する（Ｓ９４）。
【０１０６】
端末装置２は、ポータルサーバ１から情報を受信し（Ｓ１５２）、この受信した情報が取得許可情報であった場合には（Ｓ１５３でＹＥＳ）、ステップＳ１５５以下の動作を実行する（後述）。一方、ポータルサーバ１から受信した情報が取得不許可情報であった場合には（Ｓ１５３でＮＯ）、端末装置２は、アバターがボトルの拾い上げに失敗した画像（ボトルが手から滑り落ちた画像）を表示して（Ｓ１５４）動作を終了する。
【０１０７】
ステップＳ１５５以下の動作は以下のとおりである。端末装置２は、アバターがボトルの拾い上げに成功した画像を表示する（Ｓ１５５）。こののち、アバターによって、ボトルの蓋開け操作が行われるか（Ｓ１５６）、または、このボトルが再び海岸や街角に置かれるまで（Ｓ１５７）、待機する。
【０１０８】
ボトルの蓋開け操作が行われた場合（Ｓ１５６でＹＥＳ）には、拾い上げたアバターの属性がこのボトルのメッセージに設定されている開蓋条件に合致するか否かによって決定される。この属性と開蓋条件との一致／不一致をステップＳ１５８で判定し、この条件が合致した場合には（Ｓ１５９でＹＥＳ）、蓋開け成功処理を実行する（Ｓ１６０）。この蓋開け成功処理は、図１３のメッセージ魚の釣り上げ処理とほぼ同様であり、Ｓ７２の魚画像を表示する動作に代えて、ボトルの蓋が開き、中のメモに書き込まれているメッセージを表示する画像が表示される。
また、アバター（プレイヤー）がこのボトルを再び海岸や街角に置く動作をした場合には（Ｓ１５７でＹＥＳ）、蓋開け失敗処理を実行して（Ｓ１６１）動作を終了する。
【０１０９】
ステップＳ１６１の蓋開け失敗処理は、ボトルの画像をアバターの足元の仮想社会に表示とともに、ポータルサーバ１に対して蓋開け失敗情報を送信する処理である。この蓋開け失敗情報を受信したポータルサーバ１は、メッセージ魚の場合と同様に図１２（Ｂ）の処理を実行する。
【０１１０】
このように、メッセージボトルは、どのアバターでも道具なしで拾い上げることができる。また、拾い上げたのち、開蓋条件に合致する場合のみ蓋を開いてメッセージを読むことができる。
【０１１１】
また、メッセージボトルの場合、漂流しているか岸に漂着しているかで処理が異なるため、常に回遊しているメッセージ魚の場合の処理である図８のＳ９に代えて図１６の処理を実行する。図１６において、まずボトルが漂流中であるかを判断する（Ｓ１００）。漂流中であるか否かは、データベースに登録されるボトルデータに設けられた漂着フラグによって判断する。漂着フラグは、ボトルが岸に漂着したとき、または、街角等に置かれたときセットされるフラグである。
【０１１２】
漂流中の場合、すなわち漂着フラグがリセットしているときは、このボトルの漂流位置を表す位置データを更新する（Ｓ１０１）。この位置データは、次のデータ更新時に各端末装置に配信される。そして、今回の移動によって岸に漂着したかを判断する（Ｓ１０２）。岸に漂着したか否かは、データベースのマップデータと今回更新された位置データを対比して判断する。漂着した場合には（Ｓ１０２でＹＥＳ）、漂着フラグをセットして（Ｓ１０３）動作を終了する。この漂着フラグのセットは、次回のデータ更新時に各端末装置に配信される。一方、未だ岸に漂着していない場合には（Ｓ１０２でＮＯ）、そのまま動作を終了する。
【０１１３】
なお、上述した実施形態及び変形例では、メッセージが対応付けて登録されるアイテムは、魚、蝶々及びボトルであるが、アイテムの種類はこれに限定されず、仮想社会に存在するアイテムであればよい。
【０１１４】
≪ロバの耳井戸≫
次に、図１７，図１８を参照してロバの耳井戸について説明する。上に述べたアバターの活動を介したコミュニケーション手段である「メッセージ魚」、「メッセージ蝶々」、「メッセージボトル」は、それぞれメッセージが書き込まれたオブジェクト（魚，蝶々，ボトル）を１人のアバターに捕獲してもらい、そのアバター（プレイヤーまたは端末装置）のみにメッセージを表示するものであったが、ロバの耳井戸は、適当なタイミングに間欠泉のように井戸からメッセージが吹き出し、そのとき井戸の周辺にいるアバターが読むことができるものである。
【０１１５】
図１７（Ａ）は、ネットワークゲームにおけるロバの耳井戸のメッセージの入力と出力の手順を示すフローチャートである。アバターが井戸端へ行き（Ｓ２４０）、メッセージを入力する（Ｓ２４１）。井戸へのメッセージの入力は井戸に向けて内緒話（王様の耳はロバの耳）を吹き込む動作を転用したもの（メタファ）であるが、このゲームでは、メッセージの入力は、井戸をクリックすることにより表示されるメッセージ入力ウィンドウに、メッセージをテキストで打ち込むことによって行われる。メッセージの入力は、多くのアバターによって複数回行われ、間欠的にランダムに選択されたメッセージが井戸から出力される（Ｓ２４２）。メッセージの出力は、井戸から声が聞こえてくるような態様で表示される吹き出しウィンドウ内に表示されることで行われる。なお、井戸に入力されるメッセージとして、端末装置２にマイクを設け、テキストデータに代えて実際に音声データが吹き込まれるようにしてもよい。
【０１１６】
なお、この井戸へのメッセージの入力は、上述したメッセージ魚，メッセージ蝶々，メッセージボトルと異なり無料であるため、同じアバターが何度も繰り返しメッセージを入力してしまうおそれがある。そこで、入力されたメッセージに録音時刻とアバターのＩＤを付加しておき、同じアバターが何度もメッセージを入力できない（たとえば１日１回程度）ようにしてもよい。
【０１１７】
図１７（Ｂ）は、サーバデータベース１１に登録される井戸メッセージデータの構成を示す図である。井戸メッセージデータは、この移動メッセージデータを識別するための情報であるメッセージＩＤ、この井戸メッセージデータが入力された井戸を識別するための情報である井戸ＩＤ、この井戸メッセージの録音時刻、表示可能フラグ、および、メッセージ本文を有している。表示可能フラグは、このメッセージが表示可能に選択された旨を示すフラグである（詳細は後述する）。
【０１１８】
このネットワークゲームの仮想社会には、メッセージを入力することができる井戸が複数存在しており、ゲーム進行管理部１２は、メッセージの録音時刻および井戸ＩＤに基づいて、間欠的にどのメッセージを出力するかを決定する。
【０１１９】
図１８（Ａ）は、井戸メッセージ入力時のコンピュータシステムの動作を示すフローチャートである。端末装置２において、アバターによって井戸がクリックされるとこの動作が実行される。アバターが移動クリックすると（Ｓ１１０）、メッセージの入力ウィンドウを表示する（Ｓ１１１）。この入力ウィンドウは、井戸からの吹き出しウィンドウの形状で表示される。アバター（プレイヤー）によってメッセージが入力されると（Ｓ１１２）、吹き出しウィンドウを井戸に吸い込まれるように消去し（Ｓ１１３）、井戸のＩＤ、録音時刻等の情報を添えてポータルサーバに送信する（Ｓ１１４）。
ポータルサーバ１は、端末装置２から送信されてきたメッセージを受信して（Ｓ１１５）、井戸メッセージデータとしてデータベースに登録する（Ｓ１１６）。
【０１２０】
同図（Ｂ）は、井戸メッセージ出力時のコンピュータシステムの動作を示すフローチャートである。ポータルサーバ１のゲーム進行管理部１２は、定期的に井戸メッセージデータを選出する（Ｓ１２０）。この選出は、ランダムに行うが古いメッセージを優先的に出力するように録音時刻を参照して選出してもよい。メッセージが選出されると、保存時間の計時を開始するとともに、この井戸メッセージデータを表示可能に設定する、すなわち表示可能フラグをセットする（Ｓ１２１）。表示可能に設定されたメッセージは、次の定期的なデータ更新時に、このメッセージを出力する井戸と同じステージにいるアバターの端末装置に対して送信される。なお、井戸と同じステージにいるアバターではなく、井戸周辺の所定のエリア（井戸を表示画面に表示可能なエリア）に居るアバターを選出してもよい。そして、この選出されたメッセージについて、選出から一定の保存時間が経過するまで待機し（Ｓ１２２）、保存時間が経過すると（Ｓ１２２でＹＥＳ）、この井戸メッセージデータ(表示可能 フラグがセットされている井戸メッセージデータ)を消去する（Ｓ
１２３）。保存時間は、概ね２時 間程度である。なお、上記一定期間内にこのステージ
移動してきたアバターがあった場合には、そのアバターの端末装置に対してもこの井戸メッセージは送信される。
【０１２１】
同図（Ｃ）は、井戸メッセージを受信した端末装置２の動作を示すフローチャートである。端末装置２では、井戸メッセージを受信すると保存時間の計時を開始し、保存時間が経過するまで、一定時間ごとに間欠的に井戸メッセージを表示する。ステップＳ１３０、Ｓ１３１の待機ルーチンで、表示時刻が到来するか（Ｓ１３０）、保存時間が経過するか（Ｓ１３１）を判断する。
【０１２２】
表示時刻が到来した場合には（Ｓ１３０でＹＥＳ）、受信した井戸メッセージを井戸から吹き出しているような吹き出しウィンドウで表示する（メッセージデータが音声データの場合には再生する）（Ｓ１３２）。この表示は、井戸の上のオブジェクトとして表示するものであるため、同じステージであっても井戸の見えない位置にアバターがいる場合には、実際にモニタ２６には表示されない。一定の表示時間（たとえば５分）が経過すると（Ｓ１３３）、このウィンドウ表示を消去して（Ｓ１３４）、上記待機ルーチンにもどる。
一方、保存時間が経過した場合には（Ｓ１３１でＹＥＳ）、受信した井戸メッセージを消去して （Ｓ１３５）、動作を終了する。
【０１２３】
なお、井戸は仮想社会に複数配置されているが、選出されたメッセージが、いずれか１つの井戸 （一般的には録音された井戸）から吹き出し表示されるようにしてもよく、複数の井戸で同時に表示されてもよい。また、Ｓ１２０における井戸メッセージデータの選出は、全ての井戸の井戸メッセージデータの中から１または複数を選出してもよく、各井戸から入力されたメッセージの中からそれぞれ１または複数選出するようにしてもよい。また、定期的な選出の中に空選出（０個の選出）の回があってもよい。また、入力された井戸と異なる井戸から出力するべくメッセージを選出してもよい。なお、井戸は仮想社会にひとつだけ配置されていてもよい。
【０１２４】
なお、本実施形態（ロバの耳井戸）では、井戸メッセージが、所定の表示時刻が到来する毎に表示されるようになっているが、井戸メッセージの表示タイミングは、これに限定されない。例えば、アバターが井戸に対して特定の動作をしたとき、すなわち、端末装置２が、プレイヤーから特定の操作を受け付けたとき、井戸メッセージが表示されるようにしてもよい。たとえば、アバターが井戸を覗き込んだとき（プレイヤーが井戸をダブルクリックしたとき）、その操作のあった端末装置２だけで、井戸メッセージが表示されるようにしてもよい。この場合、図１８（Ｃ）のＳ１３０は、アバターの覗き込み動作（プレイヤーによる特定操作）を判断する判定動作とすればよい。
【０１２５】
なお、本実施形態（ロバの耳井戸）は、井戸からメッセージが表示される構成であるが、メッセージが表示される仮想建造物は井戸でなくてもよく、例えばトイレ等であってもよい。また、仮想建造物でなくても湖や池等、または、電話機等の仮想オブジェクトであってもよい。
【０１２６】
実施形態（ロバの耳井戸、メッセージ魚）において、コンピュータシステムを構成するサーバは、ポータル機能を実行するものであり、ゲーム内容はこのポータル機能と関連づけられたものであるが、この構成に限定されない。本実施形態にかかるゲームは、ロールプレイングゲームや、アクションゲーム等の他の種類のゲームであってもよく、仮想社会内においてアイテムを表示可能に所有させたアバターを活動させることができるゲームであればよい。
【０１２７】
なお、コンピュータシステムのシステム構成はこれに限定されず、ポータルサーバを複数の装置で構成してもよい、また商品販売サーバとしての機能も備え、現実の商品をポータルサーバで販売することができてもよい。
【０１２８】
なお、「アバター」とは、一般的にゲームキャラクタを含まないが、本発明においてはプレイヤーの操作によって動作するゲームキャラクタを含む。
【符号の説明】
【０１２９】
１…ポータルサーバ
２…端末装置
１１…サーバデータベース
１２…ゲーム進行管理部
２１…ローカルデータベース
２５…ゲーム進行管理部
３０…仮想社会記憶部
６０…メッセージ記憶部
【技術分野】
【０００１】
この発明は、複数のアバターが登場する仮想社会内で、アバター間でメッセージを交換するためのプログラムおよびこのプログラムを実行するコンピュータシステムに関する。
【背景技術】
【０００２】
近年、例えばＭＭＯＲＰＧ（ＭＭＯＲＰＧ：Massively Multiplayer Online Role-Playing Game）等のインターネットを介して多人数が参加するネットワークゲームが普及している（たとえば非特許文献１）。
【０００３】
この種のネットワークゲームでは、複数のプレイヤーが、それぞれ端末装置を操作して仮想社会に自己のキャラクタであるアバターを登場させ、互いに会話をしたり、一緒にゲームをしたりすることができる。
【０００４】
【非特許文献１】“ハンゲームガイド”、［online］、NHN Japan 株式会社、［平成１９年２月９日検索］、インターネット＜URL：http://www.hangame.co.jp/guide/index.asp?Content=avatar＞
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来、パーソナルコンピュータ，ネットワークを用いたコミュニケーション手段としては、メール，チャット等が知られている。これらは、特定の相手に向けたものであり、不特定の限られた人に向けたコミュニケーション手段は存在しなかった。また、従来より、公衆に向けてメッセージを発信する機能として掲示板が知られているが、この掲示板は、不特定多数の公衆に向けてメッセージを発信するものであり、掲示板にアクセスする人全てがメッセージを閲覧することができるものであり、やはり不特定の限られた人に向けてメッセージを発信できるものではなかった。
【０００６】
また、上記ネットワークゲームにおいて、メッセージの受け渡しを直接的な目的としないアバターの活動の中でメッセージの受け渡しを実現するという、ゲーム的な要素を取り入れたコミュニケーション手段は存在しなかった。
この発明は、ネットワークゲームの仮想社会におけるアバターの活動をとおして、不特
定の限られた人に対してメッセージの受け渡しを実現するプログラムを提供することを目的とし、また、このプログラムを実行するコンピュータシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願発明の第１の側面によって提供されるゲームプログラムは、複数の端末装置がネットワークで接続されたコンピュータシステムに、以下の手順を実行させることを特徴とする。
複数の端末装置によってそれぞれ操作される複数の仮想のキャラクタ（アバター）と、仮想オブジェクトと、を含む仮想社会を生成する仮想社会生成手順
仮想社会を各端末装置の表示部に表示させる表示手順
特定の端末装置から、仮想オブジェクトに対応づけたメッセージの入力操作を受け付けたときに、このメッセージを仮想オブジェクトに対応づけて登録するメッセージ登録手順
メッセージが登録された仮想オブジェクトを、複数のアバターのうちの１つである不特定アバターの取得動作に応じて、該不特定アバターに取得および占有させる取得手順
この不特定アバターによって仮想オブジェクトが占有されているとき、この不特定アバターを操作する端末装置にメッセージを出力可能にするメッセージ出力許可手順
不特定アバターを操作する端末装置からの操作により、取得動作に応じて不特定アバターに占有されている仮想アイテムの占有を解除して他の不特定アバターが取得可能な状態にもどす占有解除手順
【０００８】
上記発明において、メッセージが登録された仮想オブジェクトを仮想社会内で移動させる移動手順を、コンピュータシステムに更に実行させてもよい。
【０００９】
上記発明において、仮想社会生成手順は、属性が付与されたアバターを生成する手順を含み、メッセージ登録手順は、メッセージとともに属性を登録する手順を含み、取得手順は、仮想オブジェクトに対応付けて登録されている属性と一致する属性が付与された不特定アバターのみに仮想オブジェクトの取得を可能にする手順を含んでいてもよい。
【００１０】
上記発明において、仮想アイテムの購入操作が行われた端末装置を特定の端末装置としてもよい。
【００１１】
本願発明の第２の側面によって提供されるコンピュータシステムは、上記のプログラムを記憶する記憶部と、前記プログラムを実行するコンピュータと、を備えたことを特徴とする。
【発明の効果】
【００１２】
この発明によれば、メッセージが登録された仮想オブジェクトが取得されたとき、その仮想オブジェクトを取得したアバターに対してメッセージを出力可能にすることにより、不特定の限定された人に対してメッセージを発信することが可能になる。また、仮想建造物や仮想オブジェクトに登録したメッセージが仮想建造物や仮想オブジェクトから出力される態様で出力されることにより、そのときその場に居合わせた不特定の限定された少数アバターに対してメッセージを伝えることができる。これにより、従来のメール，チャット，掲示板にはない、偶然性を用いた不特定の限定された人に対するメッセージの伝達が可能になる。
【００１３】
この発明は、たとえば釣りや蝶々取り等の仮想社会内での（直接的なコミュニケーションではない）活動を通して、メッセージの受け渡しができるため、ネットワークゲームの趣向性を損なわずに他のプレイヤーとのコミュニケーションをとることが可能になる。
【図面の簡単な説明】
【００１４】
【図１】この発明が適用されるコンピュータシステムで実行されるネットワークゲームのステージとなる仮想社会の一例を示す図
【図２】前記仮想社会の画面表示例を示す図
【図３】アバターの例を示す図
【図４】ゲームにおいてメッセージ魚へのメッセージの書き込み・捕の手順を示すフローチャート
【図５】前記ネットワークゲームを実行するコンピュータシステムの構成を示す図
【図６】ポータルサーバに設けられるサーバデータベースを示す図
【図７】ポータルサーバに設けられるサーバデータベースを示す図
【図８】ログイン時およびデータの定期更新時のコンピュータシステムの動作を示すフローチャート
【図９】アバターの動作制御処理を示すフローチャート
【図１０】メッセージ登録時の動作を示すフローチャート
【図１１】魚捕獲（釣り）動作時の端末装置の動作を示すフローチャート
【図１２】魚捕獲（釣り）動作時のポータルサーバの動作を示すフローチャート
【図１３】釣り上げ成功時のコンピュータシステムの動作を示すフローチャート
【図１４】ゲームにおいてメッセージ蝶々へのメッセージの書き込み・捕獲の手順を示すフローチャート
【図１５】ゲームにおいてメッセージボトルへのメッセージの書き込み・捕獲の手順を示すフローチャート
【図１６】メッセージボトルの位置情報更新手順を示すフローチャート
【図１７】ゲームにおいてロバの耳井戸へのメッセージの入力・出力の手順を示すフローチャート
【図１８】ロバの耳井戸へのメッセージ入力・出力を実行するためのコンピュータシステムの処理手順を示すフローチャート
【発明を実施するための形態】
【００１５】
<<ゲームの概要説明>>
まず、この発明が適用されたコンピュータシステムで展開されるオンラインゲームについて説明する。
このゲームは、ポータルサーバと、端末装置であるパーソナルコンピュータとをインターネット等のネットワークを介して接続したコンピュータシステムで実行される多人数同時参加型のネットワークゲームであり、ポータルサーバや端末装置の情報処理機能（特に画像処理機能）を用いて仮想的に創り出された仮想社会に、各端末装置の利用者であるプレイヤーが、その端末装置を介して操作する仮想のキャラクタであるアバターを登場させ、このアバターを仮想社会に住まわせたり、種々の活動をさせるゲームである。なお、この実施形態の説明では、プレイヤーの操作を、適宜アバターの活動として表現する場合がある。
【００１６】
仮想社会は、複数のステージからなり、アバターは、１つのステージ内で移動可能であるとともに、各ステージ間を移動することもできる。各ステージは、懐かしい街、近代的な街、海岸、野原等それぞれ独自に特徴づけされている。
【００１７】
本コンピュータシステムにおいて、ポータルサーバはポータルサイトを運営するとともに、このポータルサイトにログインした端末装置上で上記ゲームのゲーム画像を表示する。これによって、ポータル機能と連携したゲーム画像を表示することができ、興趣性の高いポータルサイトを提供することができる。例えば、ゲームの仮想社会の店舗やアイテムにリンクが設定されており、プレイヤーがマウスクリック等により店舗やアイテムを選択すると、ポータルサーバは、そのプレイヤーの端末装置をリンク先に接続する。また、プレイヤーが、ポータルサイトで検索を行うと、端末装置には、検索内容に対応する仮想社会の領域が検索結果として表示される。例えば、「ゲーム」で検索を行った場合に、ゲームに関連するサイトの一覧が表示されるとともに、仮想社会におけるゲームセンタ等が表示される。
【００１８】
このネットワークゲームにおいて、アバターは、プレイヤーによる端末装置の操作に対応して、仮想社会内を移動する。また、アバターは、服や眼鏡等種々のアイテムを着用する。このアイテムも仮想社会内でアバターが着用する仮想のアイテムである。プレイヤーは、自己のアバターに種々のアイテムを着用させることにより、アバターを自分の気に入った外観で仮想社会で活動させることができる。プレイヤーは、これらのアイテムを、仮想社会内に設置されている店舗で購入したり、他のアバターから貰う・交換する等により、自己のアバターのために入手することができる。アイテムの購入には、この仮想社会内で通用する仮想通貨が使用される。
【００１９】
また、このオンラインゲームにおいては、以下の種々の方法を用いてアバターがメッセージを発信することができる。
（１）メッセージ魚：メッセージを書き込んだ魚を川や海に放し、これを釣り上げた他のアバターがメッセージを読むことができるもの
（２）メッセージ蝶々：メッセージを書き込んだ蝶々を放し、これを捕獲した他のアバターがメッセージを読むことができるもの
（３）メッセージボトル：メッセージを書き込んだメモを入れたボトルを川や海に流し（または街角に置き）、漂着したボトルまたは街角に置かれたボトルを拾い上げた他のアバターがメッセージを読むことができるもの
（４）ロバの耳井戸：井戸に複数のメッセージが入力され、所定のタイミングにランダムに選択されたメッセージが井戸から吹き出し表示され、その場に居るアバターが見ることができるようにしたもの
これらのメッセージ発信手段は、それぞれ特定の相手（アバター）に向けたものではなく、いつ誰が読むか判らない偶然性を持ったメッセージ発信手段である。また、オンラインゲーム中のアバターの日常動作（たとえば釣りや虫取り等）を介してメッセージの受け渡しを可能にしたものである。
【００２０】
<<ゲームの詳細説明>>
以下、図面を参照してゲームについて詳細に説明する。
前記ポータルサーバと複数の端末装置とで創り出される仮想社会は、複数のステージで構成される。各ステージは、たとえば家や店舗のある街、川が流れている野原、海岸等それぞれ異なる態様にされている。
【００２１】
図１は、このうち街のレイアウトを俯瞰的に示す図である。この街には、電車の駅１００や各種の商品を販売している店舗１０１や公園１０２等がレイアウトされている。この実施形態では、１つのステージは、２００セル×２００セルの４００００セルで構成されている。
【００２２】
プレイヤーがこのネットワークゲームにログインすると、そのプレイヤーのアバターが電車の駅１００に立っているところからゲームがスタートする。プレイヤーは、自己のアバターをこの街の中で移動させて店舗１０１や公園１０２等を訪れさせることができる。また、自己のアバターを電車１０３に乗せて他のステージに移動させることもできる。
【００２３】
図２は、図１に示したステージ「街」のモニタ表示例を示す図である。各端末装置のモニタ２６には、図１に示した街の一部の風景がほぼ水平の視線で表示されるため、このような画面となる。この図は、図１の店舗１０１Ａ（たばこや）付近の風景を示している。ここには、自己のアバター１１０および複数の他人アバター１１１が表示されている。プレイヤーは、画面上をマウスクリックすることで、自己のアバター１１０をそのマウスクリックの方向に移動（歩行）させることができる。また、プレイヤーが店舗１０１Ａをマウスクリックすることにより、自己のアバター１１０をこの店舗１０１Ａに入店させることができる。さらに、プレイヤーが電車１０３をクリックすることにより、自己のアバター１１０を電車１０３に乗せて、他のステージに移動させることができる。
【００２４】
図３は、プレイヤーが操作する仮想キャラクタであるアバターの一例を示す図である。同図のアバターは男性のアバターを示している。アバターは、図２の自己のアバター１１０に示したような基本形状（素体）をしており、この素体１２０の上に、プレイヤーの操作により、各種のアイテムが付加されて同図のような外観のアバターが構成される。この図では、素体１２０に、カツラ（髪形）１２１、眼鏡１２２、Ｔシャツ１２３、ジャケット１２４、パンツ１２５、靴１２６のアイテムを着用させて、図示のような外観に仕上げられている。なお、これら各種アイテムは、上述したメッセージ魚、メッセージ蝶々、メッセージボトルと同様に、仮想社会内の店舗から購入されるものである。
【００２５】
このオンラインゲームでは、上述したように、直接的にメッセージを発信するための活動でないアバターの活動を介して、他のアバターに対してメッセージを発信することができる。以下の実施形態では、魚アイテム（メッセージ魚）を用いたメッセージの発信について説明する。
【００２６】
図４は、メッセージ魚を用いてメッセージを受け渡す場合のプレイヤーの操作手順を示すフローチャートである。同図（Ａ）は、第１のアバターが魚にメッセージを書き込んで放流する手順を示したフローチャートである。まず、第１のアバターが店舗でメッセージを書き込むための魚を購入する （Ｓ２０１）。そして、この魚にメッセージおよびこのメッセージを読んでもらいたいアバターの属性を書き込む（Ｓ２０２）。そして、この魚を持って川や海へ移動し（Ｓ２０３）、この魚を放流する（Ｓ２０４）。これにより、魚は（サーバコンピュータの制御により）川や海等の水域を自由に回遊する。
【００２７】
同図（Ｂ）は、第２のアバターが釣りをすることにより、魚を釣り上げてそこに書き込まれているメッセージを読む手順を示すフローチャートである。第２のアバターが、釣り竿を購入する等して、釣り竿を持って（Ｓ２１０）、川や海へ行く（Ｓ２１１）。そして、釣り糸を水中に下ろす（Ｓ２１２）。そうすると、近くに居る魚が食いつくので、引きを確認したときに（Ｓ２１３）、釣り糸を引き上げる（Ｓ２１４）。これにより、魚がつり上がる。そして、この魚に書き込まれているメッセージが表示される（Ｓ２１５）。なお、魚を釣り上げることができた場合に、即メッセージが表示されるのではなく、アバターが一端魚を持ち物として所持し、プレイヤーの表示操作があったときにメッセージが表示されてもよい。
【００２８】
以下、上記のようなゲームの進行を実現するためのコンピュータシステムの動作について説明する。
【００２９】
<<システム構成の説明>>
図５は、上記ネットワークゲームを実行するコンピュータシステムの構成を説明する図である。このコンピュータシステムは、ポータルサーバ１、複数の端末装置２がインターネット３を介して接続されて構成されている。ポータルサーバ１は、一般的なサーバコンピュータまたはワークステーションで構成すればよく、端末装置２は、一般的なパーソナルコンピュータで構成すればよいため、そのハードウェア構成の詳細説明は省略する。
【００３０】
ポータルサーバ１は、仮想社会や複数のアバターのデータを蓄積記憶したサーバデータベース１１（図６、図７参照）、このネットワークゲームの全体進行を制御管理するゲーム進行管理部１２、店舗においてアバターに対するアイテムの販売およびアフィリエイトの発行を制御管理するアイテム販売管理部１３、および、端末装置２等との通信を制御する通信制御部１４を備えている。ゲーム進行管理部１２は、ゲーム進行管理プログラムによるゲーム進行管理処理が、ポータルサーバ１のＣＰＵ等のハードウェア資源によって実現された機能部である。アイテム販売管理部１３は、アイテム販売管理プログラムによるアイテム販売管理処理が、ポータルサーバ１のＣＰＵ等のハードウェア資源によって実現された機能部である。また、通信制御部１４は、通信制御プログラムによる通信制御処理が、ポータルサーバ１のＣＰＵ、通信関連周辺機器等のハードウェア資源によって実現された機能部である。
【００３１】
端末装置２は、自機においてネットワークゲームを進行させるためのデータを記憶するローカルデータベース２１、モニタ２６にゲーム画面を表示させる表示制御部２２、端末装置２の利用者であるプレイヤーの操作を受け付ける操作管理部２３、ポータルサーバ１等との通信を制御する通信制御部２４、および、自機においてゲームの進行を制御するゲーム進行管理部２５を備えている。表示制御部２２にはモニタ２６が接続される。表示制御部２２は、表示制御プログラムによる表示制御処理が、端末装置２のＣＰＵ等のハードウェア資源によって実現された機能部である。操作管理部２３は、操作管理プログラムによる操作管理処理が、端末装置２のＣＰＵやマウス・キーボード等の周辺機器等のハードウェア資源によって実現された機能部である。また、通信制御部２４は、通信制御プログラムによる通信制御処理が、周辺機器２のＣＰＵ、通信関連周辺機器等のハードウェア資源によって実現された機能部である。ゲーム進行管理部２５は、ゲーム進行を制御するプログラムによるゲーム進行制御処理が、端末装置２のＣＰＵ等のハードウェア資源によって実現された機能部である。
【００３２】
端末装置２において、このネットワークゲームは、インターネットブラウザで表示されるものとしてもよく、独立したアプリケーションプログラムで実行されるものとしてもよい。インターネットブラウザで表示されるものとした場合、ゲームプログラム（表示制御プログラム、操作管理プログラム、通信制御プログラム等）は、インターネットブラウザのプラグインとして提供される。これらのプログラムは、ＣＤ−ＲＯＭ等のメディアを用いて端末装置２に予めインストールされていてもよいが、インターネットブラウザのプラグインとして提供される場合等は、端末装置２が最初にポータルサーバ１にログインしたときにポータルサーバ１から自動的にダウンロードされるようにしてもよい。また、ローカルデータベース２１は、上記プログラムと同時に構築されるようにすればよい。ローカルデータベース２１や各プログラムは、端末装置２がポータルサーバ１にログインする都度、最新のものがポータルサーバ１からダウンロードされて更新される。
【００３３】
操作管理部２３は、プレイヤーの操作を監視し、検出した操作内容で、自装置における自己のアバターのデータを更新するとともに、この操作内容を表す操作情報を通信制御部２４を介してポータルサーバ１に送信する。ポータルサーバ１（ゲーム進行管理部１２）は、各端末装置２から送られてきた操作情報に基づいて各プレイヤーのアバターを活動させるようにゲームの進行を管理する。このゲームの進行の管理は、仮想社会の状態を全て記憶するサーバデータベース１１の内容を、そのときの仮想社会の状態に合うように更新することによって行われる。ポータルサーバ１のゲーム進行管理部１２は、データベース１１の更新情報を定期的に各端末装置２に送信する。各端末装置２（各ゲーム進行管理部２５）は、ポータルサーバ１から送られてきた更新情報に基づいてローカルデータベース２１を更新するとともに、これに合わせて画面表示を更新することによってゲームを進行させる。
【００３４】
ポータルサーバ１のアイテム販売管理部１３は、いずれかのプレイヤー（端末装置２）で操作されるアバターが仮想社会に設けられている店舗を訪問したときに機能する。アイテム販売管理部１３は、店舗を訪問したアバターを操作する端末装置２に対してその店舗の販売アイテム情報を送信したり、アバター（プレイヤー）がアイテムを購入したときには、そのアイテムをそのプレイヤーの所有アイテムテーブルに登録し、所有仮想通貨からそのアイテムの価格分を減算する。
【００３５】
図６、図７は、サーバデータベース１１の構成を示す図である。サーバデータベース１１は、仮想社会の構成を記憶する仮想社会データ記憶部３０、複数のアバターについてのデータを記憶するアバターデータ記憶部４０、この仮想社会で販売・所有・着用される複数のアイテムについてのデータを記憶するアイテムデータ記憶部５０、および、アバターが発信したメッセージを記憶するメッセージデータ記憶部６０を有している。
【００３６】
仮想社会記憶部３０は、複数のステージの各々の構成を記憶するステージデータ記憶部３１、各ステージに立っている家や駅や公園等の建物のデータを記憶する建物データ記憶部３２、店舗で販売されるアイテムを管理する販売アイテムデータ記憶部３３を有している。アバターデータ記憶部４０は、ポータルサーバ１に登録されている各アバター毎の情報を記憶するプレイヤーデータ記憶部４１、アバターの素体画像を記憶するアバター素体画像データ記憶部４２を有している。
【００３７】
ステージデータ記憶部３１は、各ステージごとに設定されたステージデータをステージ分記憶している。各ステージデータは、そのステージの名称（たとえば「懐かしい街」等）を示すステージ名称データ、そのステージにおける建物などの配置が書き込まれたマップデータおよびこのマップデータ上に配置される建物を指定する建物指定データ等を含んでいる。
【００３８】
建物データ記憶部３１は、各建物ごとに設定された建物データを各建物の分だけ記憶している。各建物データは、建物の名称（例えば、「○○デパート」等）を示す建物名称データ、その建物の外観の画像である建物画像データ、建物の種類データ（店舗、民家、入室可能か否か等）、入室可能な建物の場合には内部レイアウトデータ、さらに、アイテムを販売する店舗の場合には、販売アイテムを指定するアイテム指定データを含む。なお、建物データは、構造物だけに限らず道端の露店のようなものについても設定されている。
【００３９】
販売アイテムデータ記憶部３３は、この仮想社会のいずれかの店舗で販売されるアイテムごとに設けられる販売アイテムデータを記憶している。各販売アイテムデータは、そのアイテムをアイテムデータ記憶部５０に記憶されているアイテムから指定するアイテム指定データおよびそのアイテムの価格を示す価格データを含んでいる。
【００４０】
アイテムデータ記憶部５０は、各アイテムごとに設定されたアイテムデータを記憶している。各アイテムデータは、そのアイテムを識別するためのアイテムＩＤ、アイテムの名称（「赤い傘」等）を示すアイテム名称データ、アイテムの外観等を表すアイテム画像データ、そのアイテムがアバターのどこに着用されるか等を指示するアイテム種類データ等を含んでいる。
【００４１】
なお、このゲームでアバターが着用するアイテムは、衣類に限定されず、たとえば、釣り竿や虫取り網等の道具類も含まれる。このような道具類も店舗で販売される。
また、上述したメッセージ魚、メッセージ蝶々、メッセージボトルも店舗で販売されるアイテムの種類である。これら３種類の各アイテムは、それぞれ大きさ等が異なる更に複数種類のアイテムからなる。たとえば、メッセージ魚の場合、それぞれ大きさが異なる「ヒトコトイワシ」や「フタコトアジ」等のアイテムが存在する。これら「ヒトコトイワシ」、「フタコトアジ」はアイテム名称である。
【００４２】
これらメッセージ魚、メッセージ蝶々、メッセージボトルは、店舗で販売されるときは通常のアイテムと同様であるが、アバターが、このアイテムを購入してメッセージを書き込んで手放す（放流する、放す、流す、置く等）ことにより、それぞれ上述の特徴をもったコミュニケーションアイテムとなり、サーバデータベースのメッセージデータ記憶部６０（後述）に登録される。
【００４３】
また、プレイヤーデータ記憶部４１は、ポータルサーバ１に登録されているアバター（プレイヤー）毎に設定されたプレイヤーデータを記憶している。各プレイヤーデータは、そのプレイヤーのアバターの名称を示すアバター名称データ、そのプレイヤーが選択したアバターの素体の画像を指定する素体選択データ、このアバターの属性を示す属性データ、このアバターがどのステージの何処の座標に存在するかを示す位置データ、このアバターの動作（姿勢）を示す動作データ、このアバターが所有または着用しているアイテムが登録されるアイテムテーブル、および、仮想社会内で使用される仮想通貨の所持金額を表す所持金額データを含んでいる。
【００４４】
アバター素体画像データ記憶部４２は、プレイヤーデータの素体選択データによって選択される複数のアバター素体画像を記憶している。アバター素体画像は、たとえば、図２に示したアバター１１０等のような画像である。
【００４５】
アバターの属性データは、このアバターまたはプレイヤーの属性を示すデータであり、図７（Ａ）に示すように、年齢層、性別、趣味、地域等のカテゴリーのデータからなっている。この属性データは、プレイヤーにより、このネットワークゲームに参加登録するときに入力される情報であり、プレイヤー自身の属性が入力される場合、プレイヤーが操作する仮想のアバターに付与したい属性が入力される場合がある。
【００４６】
図７（Ａ）において、年齢層は、１０代、２０代、３０代、４０代、５０代以上の５つの選択肢から１つが選択される。性別は、男／女からどちらかが選択される。趣味は、ゲーム、音楽、スポーツ、映画、ドライブ・ツーリング、読書から１または複数が選択される。地域は、４７都道府県から１つが選択される。
なお、プレイヤーの属性を表すデータは、これらに限定されない。また、年齢層，趣味，地域の選択肢の設定態様も上記に限定されない。
【００４７】
図７（Ｂ）は、メッセージデータ記憶部６０のうち、魚データの記憶エリアを示した図である。魚データは、水中に放流されたメッセージ魚について登録されたデータであり、この魚を識別するための魚ＩＤ、サイズデータ、アイテムＩＤ、捕獲条件データ、位置情報、捕獲中フラグ、メッセージ本文等の内容で構成される。
【００４８】
サイズデータは、この魚の大きさを表すデータである。このサイズデータによって、魚の外観上の大きさが決定されるとともに、書き込み（対応付けて登録）可能なメッセージの文字数が決定される。例えば、「ヒトコトイワシ」はサイズが５ｃｍで、２０文字までメッセージを登録することができ、「フタコトアジ」はサイズが１０ｃｍで、４０文字までメッセージを登録することができる。アイテムＩＤは、アイテムデータ記憶部５０に記憶されているアイテムデータを指定するＩＤである。このアイテムＩＤでアイテムデータを指定することにより、その指定されたアイテムデータに含まれるアイテム画像データを読み出してこのメッセージ魚の外観を作成することができる。捕獲条件データは、この魚を釣り上げることができるアバターの条件（属性）を指定するデータである。この捕獲条件データは、この魚にメッセージを書き込むプレイヤーが、このメッセージを読んでもらいたいアバター（プレイヤー）を絞り込むために、その属性を設定する。この捕獲条件データは、図７（Ａ）に示した複数のカテゴリーの全部または一部について設定される。捕獲条件データが設定されていないメッセージ魚は、全てのアバターによって釣り上げられることができる。
【００４９】
なお、プレイヤーデータにアバターの属性が設定されていない場合には、捕獲条件が設定されていないメッセージ魚、すなわち上記の全てのアバターによって釣り上げられるメッセージ魚のみ釣り上げることができる。
【００５０】
位置情報は、この魚がどこを泳いでいるかを示すデータであり、ステージを示す情報とそのステージ内での座標からなる。魚の回遊は、プレイヤーが制御するのではなく、ポータルサーバ１のゲーム進行管理部１２が、独自のアルゴリズムで回遊経路を決定する。ゲーム進行管理部１２は、上記アルゴリズムで各魚の回遊経路を決定して、定期的に各魚の位置情報を更新する。
【００５１】
なお、ゲーム進行管理部１２が、魚の位置情報を更新せず、常に放流された位置をその魚の位置情報としてもよい。また、位置情報が魚データに含まれなくてもよい。この場合には、魚の釣り上げが魚の位置とは無関係に決定され、例えば、捕獲条件データとアバターの属性データと、魚サイズと釣竿の性能との一致だけで、魚の釣り上げの成否が決定される。
【００５２】
捕獲中フラグは、いずれかの端末装置２において、この魚が釣り糸に掛かっていることを示すフラグである。このフラグがセットされていると、他の端末装置２ではこの魚を捕獲することができない。端末装置２におけるゲーム進行において、アバターが釣り糸を垂らした付近に魚がいると、その魚が釣り糸に掛かり、このことがポータルサーバ１に通知される。ポータルサーバ１は、この通知に対応して捕獲中フラグをセットする。しかし、魚が釣り糸に掛かっても、引き上げるのが遅れたり、上記捕獲条件が満たされなかった場合には、この魚は逃げてしまう。端末装置２から魚が逃げたことが通知されると、ポータルサーバ１は、この捕獲中フラグをリセットする。一方、端末装置２から、魚が逃れることなく釣り上げられたことが通知されると、メッセージ本文をその端末装置２に送信するとともに、この魚データをメッセージデータ記憶部６０から消去する。
【００５３】
メッセージ本文は、テキストデータからなる。文字数は、魚のサイズに応じて異なり、２００文字〜４００文字程度である。なお、この実施形態では、メッセージ魚に設定（対応付けて登録）するメッセージをテキストとしているが、メッセージはテキストに限定されない。たとえば、音声、静止画、動画など端末装置から出力可能なものであれば、どのようなものでもよい。
【００５４】
ポータルサーバ１は、サーバデータベース１１として、図６，図７（Ｂ）に示すデータ群を常時記憶している。端末装置２のローカルデータベース２１は、サーバデータベースとほぼ同様の構成・内容を有している。サーバデータベース１１とローカルデータベース２１とで異なる点は、ローカルデータベース２１が、他のプレイヤーが操作するアバター（他人アバター）のプレイヤーデータ（４１）を持たない点程度である。ローカルデータベース２１のうち、仮想社会データ（３０）、アイテムデータ（５０）の固定部分は、プログラムと一緒にインストールされる。そして、ゲームに進行に応じて更新される部分は、プレイヤーの操作によって端末装置２が、ポータルサーバ１にログインする都度、更新データとしてダウンロードされる。
【００５５】
なお、上記ゲームにおいて、自己のアバターがステージを移動すると、移動先のステージに位置する他人アバターのプレイヤーデータ等がダウンロードされる。なお、このときに移動前のステージに位置していた他人アバターのプレイヤーデータは破棄される。
【００５６】
また、自己のアバター，他人アバターは常に移動し、着用するアイテムや所持するアイテムが変更されることもあり、アバターの属性データも変更されこともある。このため、ポータルサーバ１は、各端末装置２からアバターの位置の変更や属性データの変更等のプレイヤーデータの変更を示す情報を受信したときに、サーバデータベース１１のプレイヤーデータを更新し、この更新したデータを更新情報として定期的に各端末装置２に送信する。
【００５７】
アバター（プレイヤー）が、メッセージ魚アイテムを購入して川や海に放流したとき、魚データが作成され、この魚データが各端末装置２からポータルサーバ１にアップロードされる。ポータルサーバ１は、この魚データをメッセージデータ記憶部６０に登録し（メッセージを仮想オブジェクトに対応づけて登録し）、定期的なデータ更新時にこの魚データを各端末装置２にダウンロードする。
【００５８】
この魚データの各端末装置２へのダウンロードは、トラフィックを軽減するため、魚ＩＤ、捕獲条件データ、サイズ、外観画像指定データ、位置情報のみをログイン時や定期的なデータ更新時等に行い、ある端末装置２から釣り上げられた旨の通知があったとき、その端末装置２のみにメッセージ本文をダウンロードする。
【００５９】
もっとも、以下のような方式を採用してもよい。
（１）ログイン時等に、全ての端末装置２に全ての魚データ（メッセージ本文を含む）をダウンロードする。
（２）魚データの位置情報に基づき、その魚がどのステージにいるかを判断し、同じステージにいるアバターの端末装置２のみに、データをダウンロードする。
【００６０】
魚データのメッセージ本文を、その端末装置に送信したのち、その魚データをメッセージデータ記憶部６０から消去し、各端末装置２に対してその魚が釣り上げられた旨を通知する。
各端末装置２は、魚が釣り上げられた旨の通知を受信すると、既にダウンロードされているその魚の魚データを消去する。
【００６１】
≪動作の説明≫
図８〜図１３のフローチャートを参照して、図４に示したコンピュータシステムの動作について説明する。
図８（Ａ）は、ログイン時の動作を示すフローチャートである。プレイヤーが端末装置２を用いて、ＩＤ，パスワードを入力する等のログイン操作を行うと（Ｓ１）、端末装置２は、このログイン操作情報をポータルサーバ１に送信する（Ｓ２）。
【００６２】
ポータルサーバ１は、端末装置２からログイン操作情報を受信すると（Ｓ３）、（このログイン操作情報が正しいことを前提として）そのプレイヤーをログイン登録し、そのアバターを仮想社会に登場させるべく処理を行う（Ｓ４）。そして、このプレイヤーの操作する端末装置２に対して最新のデータを送信する（Ｓ５）。
【００６３】
端末装置２は、ポータルサーバ１から送られてきたデータを受信し、このデータで自装置のローカルデータベース２１を更新する（Ｓ６）。そして、このローカルデータベース２１に書き込まれているデータに基づいて仮想社会をモニタ２６に表示するとともに、この仮想社会にそのとき登場しているアバター（自己のアバターを含む）を表示して、この端末装置２においてゲームをスタートさせる（Ｓ７）。
【００６４】
ゲームの進行は、複数の端末装置２から送信されてくる操作情報に基づいてポータルサーバ１のゲーム進行管理部１２が管理しており、ログインした端末装置２では、ポータルサーバ１から送られてくる更新データに基づき、ゲーム進行管理部２５がゲームの進行を管理する。
【００６５】
図８（Ｂ）は、端末装置２におけるゲーム進行処理を示すフローチャートである。この処理は定期的に実行される。ポータルサーバ１のゲーム進行管理部１２は、まず、サーバデータベース１１のメッセージデータ記憶部６０に登録されている魚データの位置を更新する（Ｓ９）。この魚データの位置は、端末装置２からの操作に依存しないため、ポータルサーバ１側で決定する。次に、サーバデータベース１１の更新内容に基づき、ローカルデータベースを更新するための更新データを各端末装置２に対して定期的に送信する（Ｓ１０）。この更新データには、上記魚データの位置情報や各アバターの位置や動作等を更新するためのデータが含まれる。端末装置２は、ポータルサーバ１から送られてきた更新データを受信して（Ｓ１１）、ローカルデータベース２１を更新するとともに（Ｓ１２）、この更新データに基づいて、モニタ２６の画面表示を更新する（Ｓ１３）ことにより、ゲームを進行させる。
【００６６】
図９は、プレイヤーによるアバターの動作制御操作に対応したコンピュータシステムの動作を示すフローチャートである。
同図（Ａ）は、端末装置２の動作を示すフローチャートである。プレイヤーは、自己のアバターに何らかの動作をさせる場合、端末装置２のマウスやキーボードを操作してアバターがその動作を行うように指示する。たとえば、アバターを移動させる場合には、モニタ２６の画面上において、移動させたい方向の適当な位置、または、入店させたい店舗や乗車させたい乗り物等をマウスでクリックする。また、釣り糸を海に垂らしたい場合には、釣り竿アイテムを右クリックしてプルダウンメニューから「下ろす」を選択する。プレイヤーにより動作の指示を受け付けたとき（Ｓ２０）、この指示がアバターを他のステージに移動させる指示でない場合には（Ｓ２１でＮＯ）、端末装置２は、アバターの外観をその動作をしている状態に変化させるとともに（Ｓ２２）、この動作情報をポータルサーバ１に送信する（Ｓ２３）。たとえば、移動させたい方向の適当な位置や入店させたい店舗等がクリックされた場合、自己のアバターは同一ステージ内で移動するよう制御され、図１における電車１０３等の乗り物がクリックされた場合、自己のアバターは他のステージに移動するよう制御される。また、釣り糸を垂らす旨のメニューが選択された場合、アバターが装着しているアイテムである釣り竿を下にさげるよう形状を変化させる。また、釣り糸を引き上げる旨のメニューが選択された場合、アバターが装着しているアイテムである釣り竿を引き上げるよう形状を変化させる。
【００６７】
ただし、ステップＳ２０の動作制御操作が、アバターを他のステージに移動させる旨の操作であった場合には（Ｓ２１でＹＥＳ）、端末装置２は、このステージ移動操作情報をポータルサーバ１に送信する（Ｓ２５）。その後、ポータルサーバ１から移動先の新たなステージのデータを受信して（Ｓ２６）、このデータでローカルデータベース２１を更新し（Ｓ２７）、このステージの画像とアバターを表示してこのステージにおいてゲームを再開する（Ｓ２８）。
【００６８】
同図（Ｂ）は、端末装置２から、動作情報を受信したときのポータルサーバ１の動作を示すフローチャートである。ポータルサーバ１は、端末装置２が、同図（Ａ）のステップＳ２３で送信した動作情報を受信する（Ｓ３１）。そして、この端末装置２に対応するプレイヤーデータ（位置データ、動作データ）をこの動作情報に基づいて更新する（Ｓ３２）。この更新されたプレイヤーデータは、他の端末装置２に対しては、図８（Ｂ）に示した定期的なデータ更新時に送信される。
【００６９】
同図（Ｃ）は、端末装置２から、ステージを移動する旨の操作情報を受信したときのポータルサーバ１の動作を示すフローチャートである。ポータルサーバ１は、端末装置２が、同図（Ａ）のステップＳ２５で送信したステージ移動情報を受信して（Ｓ３４）、この端末装置２に対応するアバターデータの位置データや動作データをこのステージ移動情報に基づいて更新する（Ｓ３５）。位置データは、新しいステージへ登場したときのデフォルトの位置に設定される。そして、この新たなステージの情報を端末装置２に対して送信する（Ｓ３６）。このアバターの更新された位置データは、図８ （Ｂ）に示した定期的なデータ更新時に、他の各端末装置２に送信される。
【００７０】
このように、端末装置２では、動作情報をポータルサーバ１に送信するとともに、（ポータルサーバからの更新データの受信を待たずに）自己のアバターの姿勢や位置を更新している。これにより、操作に対応した自己のアバターの姿勢や位置の更新が遅れないようにしている。なお、自己のアバターについても、ポータルサーバ１からの更新データの受信を待って移動させるようにしてもよい。
【００７１】
図１０は、端末装置２が行うメッセージ登録動作を示すフローチャートである。プレイヤーが店舗で魚を購入することによって、この処理がスタートする。プレイヤーが魚を購入すると（Ｓ４０）、端末装置２は、この魚のメッセージ登録ウィンドウを表示する（Ｓ４１）。このメッセージ登録ウィンドウには、捕獲条件入力部およびメッセージ本文入力部が設けられている。
【００７２】
端末装置２は、まず捕獲条件の入力を受け付ける（Ｓ４２）。捕獲条件は、上述したように図７ （Ａ）に示すアバターの属性の全部または一部を指定するデータである。モニタ２６に表示される入力ウィンドウには、例えば、図７（Ａ）で示す情報が一覧表示され、この一覧の１カテゴリーから１選択肢を選択する操作をプレイヤーが行うことで捕獲条件が入力される。
【００７３】
次に、端末装置２は、メッセージの入力を受け付ける（Ｓ４３）。上述したように、入力を受け付けるメッセージの文字数は魚のサイズによって異なる。そして、アバターによってメッセージ魚の放流の動作が行われたとき（Ｓ４４）、上記操作で生成されたメッセージ魚のデータ（メッセージデータ）を、ポータルサーバ１に送信して（Ｓ４５）、動作を終了する。
【００７４】
ここで、端末装置２からポータルサーバ１に送信されるメッセージデータは、アイテムＩＤ、サイズ、捕獲条件、メッセージ本文、放流位置等である。なお、これらのデータのうち、アイテムＩＤ、サイズは、アイテムデータから取得されて送信される。サイズについては、アイテムデータに含まれるアイテム種類データ（メッセージ魚では魚の種類を示す）から取得される。
【００７５】
なお、プレイヤーの魚の購入後、即メッセージ登録ウィンドウが表示されなくてもよく、魚が一端アバターの持ち物として所持され、プレイヤーの表示操作を受け付けた場合に、メッセージ登録ウィンドウが表示されてもよい。
【００７６】
ポータルサーバ１は、端末装置２から送信されてきたメッセージデータを受信する（Ｓ４７）。そして、このメッセージデータを、サーバデータベースのメッセージデータ記憶部６０に魚データとして登録する（Ｓ４８）。すなわち、ポータルサーバ１は、受信したメッセージデータに魚ＩＤを付して魚データを生成し、メッセージデータ記憶部６０に登録する。この登録された魚データのＩＤ，位置データ，アイテムＩＤ，サイズデータ、捕獲条件及び位置情報は、図８（Ｂ）に示した定期的なデータ更新時に、他の各端末装置２に送信される。
【００７７】
図１１は、端末装置における魚捕獲処理動作すなわち釣り動作を示すフローチャートである。
プレイヤーが自己のアバターが所持している釣り糸を川や海に垂らしたとき（Ｓ４９）、この動作がスタートする。まず、釣り糸を垂らした位置（ウキの位置）の情報を割り出す（Ｓ５０）。そして、この位置情報に基づき付近に魚がいるか否かを検索する（Ｓ５１）。この検索は、ポータルサーバ１からローカルデータベース２１にダウンロードされている魚データの位置情報に基づいて判断する。付近に魚がいない場合には（Ｓ５２でＮＯ）、糸が引き上げられるまで（Ｓ５３）、Ｓ５０以下の動作を繰り返し実行する。アバターが釣り糸を移動させることがあるため、毎回位置情報は割り出される（Ｓ５０）。
【００７８】
一方、付近に魚がいる場合には、その魚と釣り糸（うき）との距離に応じた確率に基づいて、今回この魚が掛かる（食いつく）か否かを演算する（Ｓ５４）。魚が掛からなかった場合には（Ｓ５５でＮＯ）、Ｓ５０にもどって、Ｓ５０以下の動作を再度実行する。したがって、付近に魚がいる場合には、その魚が遠くへ移動してしまわないかぎり、掛かるまで毎回Ｓ５４の確率演算が実行される。
【００７９】
ここで、上記魚と釣り糸（うき）との距離に基づく食いつきの確率は、魚とうきが同一セルにある場合には１００％であり、１セルずれるごとに３０％ずつ小さくなる。たとえば、うきが魚の隣のセルにある場合には確率７０％となる。
【００８０】
一方、魚が掛かったと判定された場合には（Ｓ５５でＹＥＳ）、捕獲中情報をポータルサーバ１に送信する（Ｓ５６）。ポータルサーバ１では、他のアバターがこの魚を既に捕獲中か否かを判定し、他のアバターが捕獲中なければ捕獲許可情報を返信し、他のアバターが既に捕獲中の場合には捕獲不許可情報を返信してくる（図１２（Ａ）参照）。端末装置は、この捕獲許可／不許可情報を受信する（Ｓ５７）。次に、この魚データのサイズおよび捕獲条件を読み出し、釣り竿の性能がこの魚のサイズに適合しているか、および、このアバターの属性が魚の捕獲条件に適合しているかを判定する（Ｓ５８）。釣竿の性能と魚のサイズの適合を判断する理由は、釣竿の機能が複数ランク設定されており、釣竿のランク毎に釣り上げ可能な魚のサイズの限界値が設定されているからであり、このため、釣竿のランクによっては大きすぎで釣り上げることができない魚があるからである。なお、釣竿（アイテム）のＩＤ、このランク、及び上記魚サイズの限界値は、互いに対応付けてサーバデータベース１１及びローカルデータベース２１に記憶されている。こののち、画面のウキを動かしてプレイヤーに魚が掛かっている旨（引き）を表示する（Ｓ５９）。
【００８１】
メッセージ魚アイテム、釣り竿アイテムはともに店舗で販売されるアイテムであり、それぞれ価格の異なる複数種類がある。メッセージ魚は、価格の高いアイテムほど外観が大きく、書き込みのできるメッセージの文字数も多い。また、釣り竿アイテムは、価格の高いアイテムほど太く大きい魚を釣り上げることができる性能を有している。ステップＳ５８では、釣り竿の太さが釣り上げようとしているメッセージ魚の大きさに適合しているか、すなわち、このメッセージ魚以上の大きさの魚を釣り上げ可能な太さであるかを判断し、適合しているときにＹＥＳの判断をする。
【００８２】
なお、上記捕獲条件の適合／不適合の判定において、完全に適合していなくても、近似している場合には、ある程度の確率で適合と認めるようにしてもよい。すなわち、捕獲条件と属性が一致しないカテゴリーの選択肢リスト（図７（Ａ）参照）において、捕獲条件と属性とが近い位置関係にあるとき、所定の確率で適合と判定するようにしてもよい。図７（Ａ）に示す選択肢は、たとえば、年齢順（１０代、２０代、・・・）や地域順（北海道、青森、岩手、・・・）のように、近似するものから順にリスト化されている。したがって、捕獲条件と属性とが一致しない場合でも、図７（Ａ）の選択肢リストにおける距離が近い場合には略一致と判断して、ある程度の確率で適合と判断する処理を適合判断の変形例とすることが可能である。
【００８３】
この場合において、捕獲条件と属性との距離に応じて捕獲確率を決定してもよい。たとえば、捕獲条件が２０代であった場合に、属性が２０代（距離０）であれば捕獲確率１００パーセント、属性が１０代、３０代（距離１）であれば捕獲確率５０パーセント、属性が４０代（距離２）であれば捕獲確率２０パーセントとするなどである。
【００８４】
なお、魚がかかるかどうかの判定方法は、上記に限定されない。すなわち、上記実施形態では、位置情報、捕獲条件、魚サイズに基づいて捕獲の成否を判定しているが、これらの条件の一部を用いてもよく、また、例えば魚データが魚種類を示すデータを含み、アバターが海で釣りをしている場合には、メッセージデータ記憶部６０で記憶される海魚の魚でデータから抽選によって１の魚が選択されて掛かるようになっていてもよい。
後ろに下げました）
この引きに応じてプレイヤー（アバター）が、一定時間以内に釣り糸を引き上げたか否かを判断する（Ｓ６０、Ｓ６１）。一定時間以内に引き上げられなかった場合には（Ｓ６０でＮＯ、Ｓ６１でＹＥＳ）、魚が逃げた旨の処理を行って（Ｓ６２）、動作をＳ５０に戻す。
【００８５】
また、引きが発生してから一定時間以内に釣り糸が引き上げられた場合には（Ｓ６０でＹＥＳ）、Ｓ５７で受信した情報が捕獲許可情報であったか、および、Ｓ５８で判定した釣り竿とサイズ、アバター属性と捕獲条件が適合しているかを判断し（Ｓ６３）、この条件を満たした場合には（Ｓ６３でＹＥＳ）、釣り上げ処理（Ｓ６４）を実行する。一方、Ｓ５７で受信した情報が捕獲不許可情報であった場合またはＳ５８の条件が適合していなかった場合には（Ｓ６３でＮＯ）、釣り糸を引き上げたが糸が切れて魚が逃げてしまった旨の処理を行って（Ｓ６５）、動作を終了する。
【００８６】
ここで、ステップＳ６２の魚が逃げた旨の処理は、ウキの引き画像を停止するとともに、ポータルサーバ１に対して捕獲失敗情報を送信する処理である。また、ステップ６５の糸が切れた旨の処理は、引き上げ途中で釣り糸の画像を消去してしまうとともに、ポータルサーバ１に対して捕獲失敗情報を送信する処理である。なお、切れてしまった釣り竿の糸は、次の使用時に自動的に復活する。
このように、この処理は、ステップＳ４９で釣り糸を水中に垂らしたときスタートし、ステップＳ５３またはステップＳ６０で釣り糸を引き上げたことによって終了する。
【００８７】
図１２（Ａ）は、端末装置２から捕獲中情報を受信したポータルサーバ１の動作を示すフローチャートである。端末装置から捕獲中情報を受信すると（Ｓ９０：図１１のＳ５６に対応）、この捕獲中情報に含まれている魚ＩＤに基づいてサーバデータベース１１を検索し、この魚データの捕獲中フラグがセットされているか否かを判断する（Ｓ９１）。他の端末装置において捕獲中でない場合にはこの捕獲中フラグがリセットされているため（Ｓ９１でＮＯ）、捕獲中フラグをセットしたのち（Ｓ９２）、今回捕獲中情報を送信してきた端末装置に対して捕獲許可情報を送信する（Ｓ９３）。一方、既に他の端末装置において捕獲中であった場合には捕獲中フラグがセットされているため（Ｓ９１でＹＥＳ）、今回捕獲中情報を送信してきた端末装置に対して捕獲不許可情報を送信する（Ｓ９４）。
【００８８】
同図（Ｂ）は、端末装置２から捕獲失敗情報を受信したポータルサーバ１の動作を示すフローチャートである。端末装置から捕獲失敗情報を受信すると（Ｓ９５：図１１のＳ６２，Ｓ６５に対応）、この捕獲中情報に含まれている魚ＩＤに基づいてサーバデータベース１１を検索し、この魚データの捕獲中フラグをリセットする（Ｓ９６）。これにより、この魚が、再度捕獲可能になる。
【００８９】
図１３は、図１１のＳ６４の釣り上げ処理を示すフローチャートである。まず、ポータルサーバ１に対して捕獲成功情報を送信する（Ｓ７０）。そして、これに対応してポータルサーバ１から、釣り上げた魚に書き込まれているメッセージ本文を受信する（Ｓ７１）。次に、アバターの釣り上げ動作にしたがって、魚画像をモニタ２６に表示し（Ｓ７２）、この魚を所有アイテムとしてアイテムテーブルに登録する（Ｓ７３）。次に、プレイヤー（アバター）によるメッセージ表示装置に対応して （Ｓ７４）、メッセージ本文を表示する（Ｓ７５）。プレイヤー（アバター）による表示消去操作があるまで（Ｓ７６）、表示を継続し、消去操作があったとき（Ｓ７６でＹＥＳ）、表示を消去して （Ｓ７７）、動作を終了する。
【００９０】
ポータルサーバ１は、端末装置２から送信されてきた捕獲成功情報を受信して（Ｓ８０）、この捕獲成功情報に含まれる魚ＩＤで識別される魚データのメッセージ本文を読み出し（Ｓ８１）、このメッセージ本文を端末装置２に対して送信する（Ｓ８２）。こののち、この魚データを消去して（Ｓ８３）、動作を終了する。この魚データの消去は、図８で示すＳ１０によって、ポータルサーバ１から各端末装置２に通知され、この通知を受けた端末装置２はローカルデータベース２１のメッセージデータ記憶部から対応する魚データを消去する。
【００９１】
以上の処理により、釣り上げられた魚は、ポータルサーバが管理するメッセージから、アバターの所有するアイテムとなる。アバターは、この魚アイテムをクリックすることにより、その後何度でもメッセージを表示させることができる。また、このアイテムは他のアイテムと同様、売買，交換，捨てること等が可能である。
【００９２】
≪他の実施形態≫
以上は、メッセージ魚について説明したが、次にメッセージ蝶々，メッセージボトルについて説明する。メッセージ蝶々，メッセージボトルは、それぞれメッセージ魚の変形例である。メッセージ蝶々，メッセージボトルは、それぞれ以下の点でメッセージ魚と異なっている。
【００９３】
メッセージ魚は、川または海の水中を泳いでおり釣り上げるまで魚影としてしか見ることができないが、メッセージ蝶々は、全てのステージの空中を飛ぶことが可能であり、常に見ることができる。メッセージ魚は、選択条件として捕獲されるアバターの属性を設定可能であるが、メッセージ蝶々は、選択条件を設定できない。メッセージ魚は、魚が近くにいれば、アバターのスキルに関係なく釣り糸に掛かるが、メッセージ蝶々は、道具アイテムである虫取り網を上手く操作しないと蝶々を捕まえることができない。しかしながら、虫取り網を上手く操作することさえできれば、アバターはメッセージ蝶々を捕まえることができ、捕獲されるアバターの属性を選ばない。
なお、この実施形態では、蝶々を用いているが、空中を飛ぶ昆虫としては蝶々に限定されるものではなく、他の昆虫たとえはトンボなどを用いることができる。
【００９４】
また、メッセージボトルは、街角に置かれていたり、海辺に打ち上げられていたりするものをアバターが拾い上げることができるため、取得（捕獲）にスキルは必要ないが、メッセージ魚と同様に、メッセージを読むことができるアバターの条件を設定することができる。この条件は、捕獲条件ではなく、捕獲した後にボトルの蓋を開けてメッセージを取り出すことができるための条件である。
【００９５】
図１４を参照して、メッセージ蝶々を用いてメッセージを受け渡す場合のプレイヤーの操作手順について説明する。
【００９６】
同図（Ａ）は、第１のアバターが蝶々にメッセージを書き込んで空中に放す手順を示したフローチャートである。まず、第１のアバターが店舗でメッセージを書き込むための蝶々を購入する（Ｓ２２０）。そして、この蝶々にメッセージを書き込む（Ｓ２２１）。そして、この蝶々を任意の場所で空中に放す（Ｓ２２２）。これにより、この蝶々は（ポータルサーバ１の制御により）自由に全てのステージを飛び回ることができる。
【００９７】
同図（Ｂ）は、第２のアバターが虫取り網で虫取りをすることにより、蝶々を捕獲してそこに書き込まれているメッセージを読む手順を示すフローチャートである。第２のアバターが、虫取り網を持って（または虫取り網を購入して：Ｓ２２５）、町中や野原で蝶々を見つけ出す（Ｓ２２６）。そして、この蝶々を網の中に収めるように虫取り網を操作して蝶々を捕獲する（Ｓ２２７）。蝶々の捕獲は、アバター（プレイヤー）が虫取り網を振って蝶々を網の中に捕らえたとき、すなわち、アバターによって振られた虫取り網の軌跡上に蝶々が居た場合に成功する。蝶々を捕らえようとすれば、アバター（プレイヤー）は良いタイミングに良い位置に虫取り網を振らなければならないため、この蝶々の捕獲の成否にはアバター（プレイヤー）のスキルが反映される。なお、蝶々が捕獲されると、この蝶々に書き込まれているメッセージが表示される（Ｓ２２８）。
【００９８】
なお、メッセージ蝶々は、空中を飛んでおり、常にアバター（プレイヤー）から見えているため、端末装置２は、ポータルサーバ１から通知された位置情報に基づいて蝶々を表示する処理を行う。
【００９９】
同図（Ｃ）は、第２のアバター（プレイヤー）が蝶々の捕獲動作を行ったとき、すなわち、アバターが蝶々のいる場所に虫取り網を振ったときに実行される動作を示すフローチャートである。アバターが蝶々の捕獲動作を行うと、すなわちプレイヤーによる捕獲操作を受け付けると（Ｓ１４０）、端末装置２は、ポータルサーバ１に対して捕獲動作情報を送信して捕獲を許可するか否か、すなわち、既に（ポータルサーバ１から画像の更新情報を受信する前に）他のアバター（プレイヤー）が先に蝶々を捕獲しているか否かを問い合わせる（Ｓ１４１）。
【０１００】
ポータルサーバ１は、この捕獲動作情報を受信して図１２（Ａ）のＳ９１〜Ｓ９４の処理を実行する。すなわち、先にこの蝶々を捕獲しているか否かをこの蝶々のデータの捕獲中フラグがセットされているか否かに基づいて判断し（Ｓ９１）、他の端末装置で捕獲中でない場合にはこの捕獲中フラグをセットしたのち（Ｓ９２）、端末装置に対して捕獲許可情報を送信する（Ｓ９３）。一方、既に他の端末装置が捕獲中であった場合には、端末装置に対して捕獲不許可情報を送信する（Ｓ９４）。
【０１０１】
端末装置２は、ポータルサーバ１から情報を受信し（Ｓ１４２）、この受信した情報が捕獲許可情報であった場合には（Ｓ１４３でＹＥＳ）、捕獲成功処理を実行する（Ｓ１４４）。この捕獲成功処理は、図１３のメッセージ魚の釣り上げ処理とほぼ同様であり、Ｓ７２の魚画像を表示する動作に代えて、虫取り網の中に蝶々が捕獲されている画像を表示する。一方、ポータルサーバ１から受信した情報が捕獲不許可情報であった場合には（Ｓ１４３でＮＯ）、端末装置２は、アバターが蝶々の捕獲を失敗した画像（蝶々が網から逃げた画像）を表示して（Ｓ１４５）動作を終了する。
【０１０２】
メッセージ蝶々には捕獲条件が設定されないため、メッセージ魚の捕獲条件とアバターの属性とが合致する否かの判定（図１１のＳ５８、Ｓ６３）は行われない。また、端末装置２は、捕獲許可情報を受信した場合、例外なく捕獲成功処理に進み（Ｓ１４３参照）、一端捕獲した蝶々を取り逃がすことがないため、ポータルサーバ１が図１２（Ｂ）の処理を実行することはない。
【０１０３】
図１５は、メッセージボトルを用いてメッセージを受け渡す場合のプレイヤーの操作手順を示すフローチャートである。同図（Ａ）は、第１のアバターがメッセージを書き込だメモを封入したボトルを放流するまたは街角におく手順を示したフローチャートである。まず、第１のアバターが店舗でメッセージを書き込むボトルとメモを購入する（Ｓ２３０）。そして、メモにメッセージおよびこのメッセージを読んでもらいたいアバターの属性を書き込んでボトルに封入する（Ｓ２３１）。そして、このボトルを流す場合には、ボトルを持って川や海へ移動し（Ｓ２３２）、ボトルを川または海に流す（Ｓ２３３）。これにより、ボトルは（サーバコンピュータの制御により）漂流し、どこかの岸に漂着する。なお、ボトルの漂流制御を行わず、所定の漂流ポイントから１のポイントが抽選されて、このポイントにボトルを配置する等してもよい。また、ボトルを流さない場合には、街角等の任意の場所に置くことができる（Ｓ２３４）。この場合、ボトルは移動せず誰かが拾い上げるまで同じ位置にあり、ボトルを置いたアバターが、誰が拾い上げるか見届けることができる。
【０１０４】
同図（Ｂ）は、第２のアバターを操作する端末装置において、第２のアバター（プレイヤー）がボトルを拾い上げる操作が行われたときに実行される動作を示すフローチャートである。第２のアバターが海岸または街角でボトルを拾う操作がされると（Ｓ１５０）、端末装置２は、ポータルサーバ１に対して拾い上げ動作情報を送信してこの拾い上げを許可するか否か、すなわち、既に（ポータルサーバ１から画像の更新情報を受信する前に）他のアバター（プレイヤー）が先にボトルを拾い上げているか否かを問い合わせる（Ｓ１５１）。
【０１０５】
ポータルサーバ１は、この捕獲動作情報を受信して図１２（Ａ）のＳ９１〜Ｓ９４の処理を実行する。すなわち、先にこのボトルを拾い上げているか否かをこのボトルのデータの取得中フラグがセットされているか否かに基づいて判断し（Ｓ９１）、他の端末装置で取得中でない場合にはこの取得中フラグをセットしたのち（Ｓ９２）、端末装置に対して取得許可情報を送信する（Ｓ９３）。一方、既に他の端末装置が取得中であった場合には、端末装置に対して取得不許可情報を送信する（Ｓ９４）。
【０１０６】
端末装置２は、ポータルサーバ１から情報を受信し（Ｓ１５２）、この受信した情報が取得許可情報であった場合には（Ｓ１５３でＹＥＳ）、ステップＳ１５５以下の動作を実行する（後述）。一方、ポータルサーバ１から受信した情報が取得不許可情報であった場合には（Ｓ１５３でＮＯ）、端末装置２は、アバターがボトルの拾い上げに失敗した画像（ボトルが手から滑り落ちた画像）を表示して（Ｓ１５４）動作を終了する。
【０１０７】
ステップＳ１５５以下の動作は以下のとおりである。端末装置２は、アバターがボトルの拾い上げに成功した画像を表示する（Ｓ１５５）。こののち、アバターによって、ボトルの蓋開け操作が行われるか（Ｓ１５６）、または、このボトルが再び海岸や街角に置かれるまで（Ｓ１５７）、待機する。
【０１０８】
ボトルの蓋開け操作が行われた場合（Ｓ１５６でＹＥＳ）には、拾い上げたアバターの属性がこのボトルのメッセージに設定されている開蓋条件に合致するか否かによって決定される。この属性と開蓋条件との一致／不一致をステップＳ１５８で判定し、この条件が合致した場合には（Ｓ１５９でＹＥＳ）、蓋開け成功処理を実行する（Ｓ１６０）。この蓋開け成功処理は、図１３のメッセージ魚の釣り上げ処理とほぼ同様であり、Ｓ７２の魚画像を表示する動作に代えて、ボトルの蓋が開き、中のメモに書き込まれているメッセージを表示する画像が表示される。
また、アバター（プレイヤー）がこのボトルを再び海岸や街角に置く動作をした場合には（Ｓ１５７でＹＥＳ）、蓋開け失敗処理を実行して（Ｓ１６１）動作を終了する。
【０１０９】
ステップＳ１６１の蓋開け失敗処理は、ボトルの画像をアバターの足元の仮想社会に表示とともに、ポータルサーバ１に対して蓋開け失敗情報を送信する処理である。この蓋開け失敗情報を受信したポータルサーバ１は、メッセージ魚の場合と同様に図１２（Ｂ）の処理を実行する。
【０１１０】
このように、メッセージボトルは、どのアバターでも道具なしで拾い上げることができる。また、拾い上げたのち、開蓋条件に合致する場合のみ蓋を開いてメッセージを読むことができる。
【０１１１】
また、メッセージボトルの場合、漂流しているか岸に漂着しているかで処理が異なるため、常に回遊しているメッセージ魚の場合の処理である図８のＳ９に代えて図１６の処理を実行する。図１６において、まずボトルが漂流中であるかを判断する（Ｓ１００）。漂流中であるか否かは、データベースに登録されるボトルデータに設けられた漂着フラグによって判断する。漂着フラグは、ボトルが岸に漂着したとき、または、街角等に置かれたときセットされるフラグである。
【０１１２】
漂流中の場合、すなわち漂着フラグがリセットしているときは、このボトルの漂流位置を表す位置データを更新する（Ｓ１０１）。この位置データは、次のデータ更新時に各端末装置に配信される。そして、今回の移動によって岸に漂着したかを判断する（Ｓ１０２）。岸に漂着したか否かは、データベースのマップデータと今回更新された位置データを対比して判断する。漂着した場合には（Ｓ１０２でＹＥＳ）、漂着フラグをセットして（Ｓ１０３）動作を終了する。この漂着フラグのセットは、次回のデータ更新時に各端末装置に配信される。一方、未だ岸に漂着していない場合には（Ｓ１０２でＮＯ）、そのまま動作を終了する。
【０１１３】
なお、上述した実施形態及び変形例では、メッセージが対応付けて登録されるアイテムは、魚、蝶々及びボトルであるが、アイテムの種類はこれに限定されず、仮想社会に存在するアイテムであればよい。
【０１１４】
≪ロバの耳井戸≫
次に、図１７，図１８を参照してロバの耳井戸について説明する。上に述べたアバターの活動を介したコミュニケーション手段である「メッセージ魚」、「メッセージ蝶々」、「メッセージボトル」は、それぞれメッセージが書き込まれたオブジェクト（魚，蝶々，ボトル）を１人のアバターに捕獲してもらい、そのアバター（プレイヤーまたは端末装置）のみにメッセージを表示するものであったが、ロバの耳井戸は、適当なタイミングに間欠泉のように井戸からメッセージが吹き出し、そのとき井戸の周辺にいるアバターが読むことができるものである。
【０１１５】
図１７（Ａ）は、ネットワークゲームにおけるロバの耳井戸のメッセージの入力と出力の手順を示すフローチャートである。アバターが井戸端へ行き（Ｓ２４０）、メッセージを入力する（Ｓ２４１）。井戸へのメッセージの入力は井戸に向けて内緒話（王様の耳はロバの耳）を吹き込む動作を転用したもの（メタファ）であるが、このゲームでは、メッセージの入力は、井戸をクリックすることにより表示されるメッセージ入力ウィンドウに、メッセージをテキストで打ち込むことによって行われる。メッセージの入力は、多くのアバターによって複数回行われ、間欠的にランダムに選択されたメッセージが井戸から出力される（Ｓ２４２）。メッセージの出力は、井戸から声が聞こえてくるような態様で表示される吹き出しウィンドウ内に表示されることで行われる。なお、井戸に入力されるメッセージとして、端末装置２にマイクを設け、テキストデータに代えて実際に音声データが吹き込まれるようにしてもよい。
【０１１６】
なお、この井戸へのメッセージの入力は、上述したメッセージ魚，メッセージ蝶々，メッセージボトルと異なり無料であるため、同じアバターが何度も繰り返しメッセージを入力してしまうおそれがある。そこで、入力されたメッセージに録音時刻とアバターのＩＤを付加しておき、同じアバターが何度もメッセージを入力できない（たとえば１日１回程度）ようにしてもよい。
【０１１７】
図１７（Ｂ）は、サーバデータベース１１に登録される井戸メッセージデータの構成を示す図である。井戸メッセージデータは、この移動メッセージデータを識別するための情報であるメッセージＩＤ、この井戸メッセージデータが入力された井戸を識別するための情報である井戸ＩＤ、この井戸メッセージの録音時刻、表示可能フラグ、および、メッセージ本文を有している。表示可能フラグは、このメッセージが表示可能に選択された旨を示すフラグである（詳細は後述する）。
【０１１８】
このネットワークゲームの仮想社会には、メッセージを入力することができる井戸が複数存在しており、ゲーム進行管理部１２は、メッセージの録音時刻および井戸ＩＤに基づいて、間欠的にどのメッセージを出力するかを決定する。
【０１１９】
図１８（Ａ）は、井戸メッセージ入力時のコンピュータシステムの動作を示すフローチャートである。端末装置２において、アバターによって井戸がクリックされるとこの動作が実行される。アバターが移動クリックすると（Ｓ１１０）、メッセージの入力ウィンドウを表示する（Ｓ１１１）。この入力ウィンドウは、井戸からの吹き出しウィンドウの形状で表示される。アバター（プレイヤー）によってメッセージが入力されると（Ｓ１１２）、吹き出しウィンドウを井戸に吸い込まれるように消去し（Ｓ１１３）、井戸のＩＤ、録音時刻等の情報を添えてポータルサーバに送信する（Ｓ１１４）。
ポータルサーバ１は、端末装置２から送信されてきたメッセージを受信して（Ｓ１１５）、井戸メッセージデータとしてデータベースに登録する（Ｓ１１６）。
【０１２０】
同図（Ｂ）は、井戸メッセージ出力時のコンピュータシステムの動作を示すフローチャートである。ポータルサーバ１のゲーム進行管理部１２は、定期的に井戸メッセージデータを選出する（Ｓ１２０）。この選出は、ランダムに行うが古いメッセージを優先的に出力するように録音時刻を参照して選出してもよい。メッセージが選出されると、保存時間の計時を開始するとともに、この井戸メッセージデータを表示可能に設定する、すなわち表示可能フラグをセットする（Ｓ１２１）。表示可能に設定されたメッセージは、次の定期的なデータ更新時に、このメッセージを出力する井戸と同じステージにいるアバターの端末装置に対して送信される。なお、井戸と同じステージにいるアバターではなく、井戸周辺の所定のエリア（井戸を表示画面に表示可能なエリア）に居るアバターを選出してもよい。そして、この選出されたメッセージについて、選出から一定の保存時間が経過するまで待機し（Ｓ１２２）、保存時間が経過すると（Ｓ１２２でＹＥＳ）、この井戸メッセージデータ(表示可能 フラグがセットされている井戸メッセージデータ)を消去する（Ｓ
１２３）。保存時間は、概ね２時 間程度である。なお、上記一定期間内にこのステージ
移動してきたアバターがあった場合には、そのアバターの端末装置に対してもこの井戸メッセージは送信される。
【０１２１】
同図（Ｃ）は、井戸メッセージを受信した端末装置２の動作を示すフローチャートである。端末装置２では、井戸メッセージを受信すると保存時間の計時を開始し、保存時間が経過するまで、一定時間ごとに間欠的に井戸メッセージを表示する。ステップＳ１３０、Ｓ１３１の待機ルーチンで、表示時刻が到来するか（Ｓ１３０）、保存時間が経過するか（Ｓ１３１）を判断する。
【０１２２】
表示時刻が到来した場合には（Ｓ１３０でＹＥＳ）、受信した井戸メッセージを井戸から吹き出しているような吹き出しウィンドウで表示する（メッセージデータが音声データの場合には再生する）（Ｓ１３２）。この表示は、井戸の上のオブジェクトとして表示するものであるため、同じステージであっても井戸の見えない位置にアバターがいる場合には、実際にモニタ２６には表示されない。一定の表示時間（たとえば５分）が経過すると（Ｓ１３３）、このウィンドウ表示を消去して（Ｓ１３４）、上記待機ルーチンにもどる。
一方、保存時間が経過した場合には（Ｓ１３１でＹＥＳ）、受信した井戸メッセージを消去して （Ｓ１３５）、動作を終了する。
【０１２３】
なお、井戸は仮想社会に複数配置されているが、選出されたメッセージが、いずれか１つの井戸 （一般的には録音された井戸）から吹き出し表示されるようにしてもよく、複数の井戸で同時に表示されてもよい。また、Ｓ１２０における井戸メッセージデータの選出は、全ての井戸の井戸メッセージデータの中から１または複数を選出してもよく、各井戸から入力されたメッセージの中からそれぞれ１または複数選出するようにしてもよい。また、定期的な選出の中に空選出（０個の選出）の回があってもよい。また、入力された井戸と異なる井戸から出力するべくメッセージを選出してもよい。なお、井戸は仮想社会にひとつだけ配置されていてもよい。
【０１２４】
なお、本実施形態（ロバの耳井戸）では、井戸メッセージが、所定の表示時刻が到来する毎に表示されるようになっているが、井戸メッセージの表示タイミングは、これに限定されない。例えば、アバターが井戸に対して特定の動作をしたとき、すなわち、端末装置２が、プレイヤーから特定の操作を受け付けたとき、井戸メッセージが表示されるようにしてもよい。たとえば、アバターが井戸を覗き込んだとき（プレイヤーが井戸をダブルクリックしたとき）、その操作のあった端末装置２だけで、井戸メッセージが表示されるようにしてもよい。この場合、図１８（Ｃ）のＳ１３０は、アバターの覗き込み動作（プレイヤーによる特定操作）を判断する判定動作とすればよい。
【０１２５】
なお、本実施形態（ロバの耳井戸）は、井戸からメッセージが表示される構成であるが、メッセージが表示される仮想建造物は井戸でなくてもよく、例えばトイレ等であってもよい。また、仮想建造物でなくても湖や池等、または、電話機等の仮想オブジェクトであってもよい。
【０１２６】
実施形態（ロバの耳井戸、メッセージ魚）において、コンピュータシステムを構成するサーバは、ポータル機能を実行するものであり、ゲーム内容はこのポータル機能と関連づけられたものであるが、この構成に限定されない。本実施形態にかかるゲームは、ロールプレイングゲームや、アクションゲーム等の他の種類のゲームであってもよく、仮想社会内においてアイテムを表示可能に所有させたアバターを活動させることができるゲームであればよい。
【０１２７】
なお、コンピュータシステムのシステム構成はこれに限定されず、ポータルサーバを複数の装置で構成してもよい、また商品販売サーバとしての機能も備え、現実の商品をポータルサーバで販売することができてもよい。
【０１２８】
なお、「アバター」とは、一般的にゲームキャラクタを含まないが、本発明においてはプレイヤーの操作によって動作するゲームキャラクタを含む。
【符号の説明】
【０１２９】
１…ポータルサーバ
２…端末装置
１１…サーバデータベース
１２…ゲーム進行管理部
２１…ローカルデータベース
２５…ゲーム進行管理部
３０…仮想社会記憶部
６０…メッセージ記憶部
【特許請求の範囲】
【請求項１】
複数の端末装置がネットワークで接続されたコンピュータシステムに、
前記複数の端末装置によってそれぞれ操作される複数の仮想のキャラクタ（以下、アバターと呼ぶ）と、仮想オブジェクトと、を含む仮想社会を生成する仮想社会生成手順と、
前記仮想社会を、各端末装置の表示部に表示させる表示手順と、
特定の端末装置から、前記仮想オブジェクトに対応づけたメッセージの入力操作を受け付けたときに、このメッセージを前記仮想オブジェクトに対応づけて登録するメッセージ登録手順と、
前記メッセージが登録された仮想オブジェクトを、前記複数のアバターのうちの１つである不特定アバターの取得動作に応じて、該不特定アバターに取得および占有させる取得手順と、
この不特定アバターによって前記仮想オブジェクトが占有されているとき、この不特定アバターを操作する端末装置に前記メッセージを出力可能にするメッセージ出力許可手順と、
前記不特定アバターを操作する端末装置からの操作により、前記取得動作に応じて前記不特定アバターに占有されている前記仮想アイテムの占有を解除して他の不特定アバターが取得可能な状態にもどす占有解除手順と、
を実行させるプログラム。
【請求項２】
メッセージが登録された仮想オブジェクトを前記仮想社会内で移動させる移動手順を、
前記コンピュータシステムに更に実行させる請求項１に記載のプログラム。
【請求項３】
前記仮想社会構築手順は、属性が付与されたアバターを生成する手順を含み、
前記メッセージ登録手順は、メッセージとともに属性を登録する手順を含み、
前記取得手順は、前記仮想オブジェクトに対応付けて登録されている属性と一致する属性が付与された不特定アバターのみに当該仮想オブジェクトの取得を可能にする手順を含む
請求項１または請求項２に記載のプログラム。
【請求項４】
前記特定の端末装置は、前記仮想アイテムの購入操作が行われた端末装置である請求項１乃至請求項３のいずれかに記載のプログラム。
【請求項５】
請求項１乃至請求項４のいずれかに記載のプログラムを記憶する記憶部と、前記プログラムを実行するコンピュータと、を備えたコンピュータシステム。
【請求項１】
複数の端末装置がネットワークで接続されたコンピュータシステムに、
前記複数の端末装置によってそれぞれ操作される複数の仮想のキャラクタ（以下、アバターと呼ぶ）と、仮想オブジェクトと、を含む仮想社会を生成する仮想社会生成手順と、
前記仮想社会を、各端末装置の表示部に表示させる表示手順と、
特定の端末装置から、前記仮想オブジェクトに対応づけたメッセージの入力操作を受け付けたときに、このメッセージを前記仮想オブジェクトに対応づけて登録するメッセージ登録手順と、
前記メッセージが登録された仮想オブジェクトを、前記複数のアバターのうちの１つである不特定アバターの取得動作に応じて、該不特定アバターに取得および占有させる取得手順と、
この不特定アバターによって前記仮想オブジェクトが占有されているとき、この不特定アバターを操作する端末装置に前記メッセージを出力可能にするメッセージ出力許可手順と、
前記不特定アバターを操作する端末装置からの操作により、前記取得動作に応じて前記不特定アバターに占有されている前記仮想アイテムの占有を解除して他の不特定アバターが取得可能な状態にもどす占有解除手順と、
を実行させるプログラム。
【請求項２】
メッセージが登録された仮想オブジェクトを前記仮想社会内で移動させる移動手順を、
前記コンピュータシステムに更に実行させる請求項１に記載のプログラム。
【請求項３】
前記仮想社会構築手順は、属性が付与されたアバターを生成する手順を含み、
前記メッセージ登録手順は、メッセージとともに属性を登録する手順を含み、
前記取得手順は、前記仮想オブジェクトに対応付けて登録されている属性と一致する属性が付与された不特定アバターのみに当該仮想オブジェクトの取得を可能にする手順を含む
請求項１または請求項２に記載のプログラム。
【請求項４】
前記特定の端末装置は、前記仮想アイテムの購入操作が行われた端末装置である請求項１乃至請求項３のいずれかに記載のプログラム。
【請求項５】
請求項１乃至請求項４のいずれかに記載のプログラムを記憶する記憶部と、前記プログラムを実行するコンピュータと、を備えたコンピュータシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１３−８１７９５（Ｐ２０１３−８１７９５Ａ）
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１２−２７５４８５（Ｐ２０１２−２７５４８５）
【出願日】平成２４年１２月１８日（２０１２．１２．１８）
【分割の表示】特願２００７−９０２５９（Ｐ２００７−９０２５９）の分割
【原出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（０００１２９１４９）株式会社カプコン (192)
【Ｆターム（参考）】
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２４年１２月１８日（２０１２．１２．１８）
【分割の表示】特願２００７−９０２５９（Ｐ２００７−９０２５９）の分割
【原出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（０００１２９１４９）株式会社カプコン (192)
【Ｆターム（参考）】
[ Back to top ]