JP2014004134A - メッセージ管理装置、メッセージ管理方法およびプログラム - Google Patents

Abstract

【課題】メッセージの閲覧をしつつ、ゲームについても当該閲覧のユーザインターフェースを流用して、対話形式で進行させる。
【解決手段】メッセージ管理装置である管理サーバは、グループを構成する複数のメンバーのそれぞれから送信されたメッセージを、それぞれのメンバーの端末装置のメッセージ表示部にて閲覧可能に提供する。管理サーバは、予め定められたゲームの進行に関連するアイコン情報、または、入力に基づいた送信されたメッセージを受け付ける受付部と、送信されたアイコン情報に基づいてゲームを進行させるゲーム制御部と、受け付けられたメッセージについては、グループを構成するメンバーのうち、当該メッセージを送信したメンバー以外の他のメンバーに送信し、ゲームの進行に応じた結果またはメッセージについては、グループを構成するメンバー全員に送信する送信部と、を備える。
【選択図】図５

Description

本発明は、複数の利用者同士でメッセージ等を閲覧させる技術に関する。

近年、インターネットを利用したサイトによってメッセージの閲覧などのサービスを提供する技術が普及している（例えば特許文献１参照）。

特開２００８−２４２６９３号公報

ところで、このようなサービスを提供する場合に、利用者にとって面白みがあり、かつ、場の雰囲気を盛り上げるような機能を付加する要求は極めて強いが、機能の追加によってユーザインターフェースが複雑化するのは、できるだけ避けたい、という事情がある。
本発明は、上述した事情に鑑みてなされたものであり、その目的の一つは、インターフェースの変更を少なくした上で、メッセージの閲覧等のサービスに、利用者にとって面白みがあり、かつ、場の雰囲気を盛り上げるような機能を付加して提供することにある。

上記課題を解決するために本発明が採用する手段を説明する。なお、本発明の理解を容易にするために、以下では図面の参照符号を便宜的に括弧書で付記するが、本発明を図示の形態に限定する趣旨ではない。

本発明に係るメッセージ管理装置（１０）は、グループを構成する複数の利用者のそれぞれから送信されたメッセージを、それぞれの利用者の端末装置（２０）のメッセージ表示部（２１２）にて閲覧可能に提供するメッセージ管理装置（１０）であって、予め定められたゲームの進行に関連する複数のアイコン情報のうち利用者から送信されたアイコン情報、または、利用者の入力に基づいた送信されたメッセージを受け付ける受付部（１２１）と、利用者から送信されたアイコン情報に基づいてゲームを進行させるゲーム制御部（１２３）と、前記受付部（１２１）で受け付けられたメッセージを、前記複数の利用者のうち、少なくとも当該メッセージを送信した利用者以外の他の利用者に送信し、ゲームの進行に応じた結果またはメッセージを、前記複数の利用者のそれぞれに送信する送信部（１４０）と、を備える。
ここで、アイコン情報とは、ゲームの進行に関連するアイコンを識別する情報であっても良いし、アイコンそのものを示す情報であっても良い。また、ゲームの進行に関連する、とは、当該ゲームの開始や、命令、終了などのように当該ゲームの進行に関与するものであれば良い。受け付けられたメッセージは、グループを構成する複数の利用者のうち、当該メッセージを送信した利用者以外の他の利用者に送信されても良いし、グループを構成する複数の利用者の全員に送信されても良い。

本発明において、前記受付部（１２１）は、前記複数のアイコン情報のうち前記利用者によって選択されたアイコンのアイコン情報を受け付け、前記ゲームが進行したときに、前記利用者が選択可能なアイコンが増加する構成としても良い。

また、本発明において、前記ゲーム制御部（１２３）は、前記ゲームを複数のステージで管理するとともに、一のステージにおいて所定の条件が充足されたときに、当該一のステージ以外のステージへの進行を許可する構成としても良い。この構成において、前記所定の条件には、対価の支払いが含まれても良い。

本発明において、前記送信部（１４０）は、前記メッセージ表示部（２１２）の一端側に前記複数の利用者のメッセージを、前記メッセージ表示部（２１２）の他端側にゲームの進行に応じた結果またはメッセージを、それぞれ送信した時間の順で閲覧可能に提供する構成が好ましい。
この構成において、送信部（１４０）は、端末装置（２０）のメッセージ表示部（２１２）に、利用者のメッセージ、または、ゲームの進行に応じた結果もしくはメッセージを、結果的に時間の順で閲覧可能に提供するのであれば良い。

本発明は、メッセージ管理装置のみならず、当該メッセージの管理方法や、サーバ（１０）としてのコンピュータで機能させるプログラムとしても概念することができる。
また、上記プログラムは記録媒体に記憶させても良い。この記録媒体を用いれば、例えば上記コンピュータに上記プログラムをインストールすることができる。ここで、上記プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であっても良い。

実施形態に係るシステムの概要動作を示す図である。 実施形態に係るシステムの構成を示す図である。 同システムにおける管理サーバの構成を示すブロック図である。 同システムにおける端末装置の構成を示すブロック図である。 同システムにおいて構築される機能ブロック図である。 送信情報一時記憶部の構成を示すブロック図である。 利用者登録テーブルの一例を示す図である。 グループ登録テーブルの一例を示す図である。 ゲーム管理テーブルの一例を示す図である。 アイコン管理テーブルの一例を示す図である。 端末装置での閲覧処理を示すフローチャートである。 端末装置での受信処理を示すフローチャートである。 管理サーバでの受付処理を示すフローチャートである。 管理サーバでのバッファ処理を示すフローチャートである。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置におけるタイムライン表示の例を示す図である。 端末装置におけるアイコン選択画面の例を示す図である。 応用例に係るシステムで構築される機能ブロック図である。

＜実施形態の概要＞
まず、実施形態に係るメッセージ管理装置を適用したシステムの動作概要について説明する。
図１は、この動作概要を説明するための図である。この図に示されるように、システムは、メッセージ管理装置としての管理サーバと、当該管理サーバと通信可能な複数の端末装置とを含む。ここでは、複数の端末装置の利用者のうち、メンバーＡ、Ｂ、Ｃの３名で１つのグループを構成しているものとする。
システムにおいて、メンバーＡが自己の端末装置を介して、メッセージとして例えば「ＯＫ」を他のメンバーＢ、Ｃ宛に送信すると、当該メッセージは、管理サーバ１０に送信される一方、送信者であるメンバーＡの端末装置において表示される。
管理サーバでは、グループを構成するメンバーの情報が例えばテーブルとして予め登録されている。管理サーバは、メンバーＡの端末装置からメッセージを受け付けると、メッセージの送信者であるメンバーＡ以外のメンバーＢ、Ｃについて上記テーブルを参照して特定し、特定したメンバーＢ、Ｃの端末装置に メンバーＡのメッセージを転送（送信）する。これにより、メンバーＢ、Ｃの端末装置においても、メンバーＡによるメッセージが表示されることになる。
このようなメッセージには、後述するように送信日時を示す時間情報などが付帯しているので、グループの端末装置において自他メンバーによるメッセージを蓄積する一方で、送信日時の順でタイムライン（時系列）表示することによって、あたかもチャットしているかのような場がメンバー同士で共有されることになる。

本実施形態では、このようなチャットの場において特定の条件を満たしたときに、ゲームが開始する。ゲームの開始は、例えばいずれかのメンバーがゲームの開始を自発的に指示したときや、現在時刻が毎時００分になったときのように管理サーバが指示したときなどで開始する。また、ゲームの種類としては、本実施形態では、想像・空想上で与えられるステージ（試練、課題、戦闘など）を克服して所定の目的を達成するロールプレイング的なものを想定する。このため、本実施形態において、ゲームは複数のステージで構成され、例えばステージ１→ステージ２→ステージ３…というような過程を辿る。ただし、本発明においてゲームの種類はこれに限られず、ゲーム進行の単位であるターンがプレイヤーに所定の順番に到来するターン制ゲームなどであっても良い。
いずれにしてもゲームを進行させるためには、プレイヤーとしてのグループメンバーがなんらかの命令を指示しなければならない。

本実施形態では、ゲームの進行を指示するために、端末装置において複数のゲーム命令のそれぞれに対応したスタンプ状のアイコンが予め１個または複数個用意されており、メンバーが、このアイコンを選択することによってゲームの進行を指示する構成となっている。
ゲームが開始しているときに、グループメンバーＢが端末装置において例えば「突く」のゲーム命令に対応したアイコンを選択したとき、当該アイコンを一意に識別するアイコン情報が管理サーバに送信される。管理サーバは、メンバーＢの端末装置から当該アイコン情報を受け付けると、当該アイコン情報に対応するゲーム命令にしたがってゲームを進行させるとともに、その進行結果に応じた画像やメッセージを、当該グループを構成するメンバーの全員、すなわちメンバーＡ、Ｂ、Ｃの端末装置のそれぞれに送信する。

これにより、メンバー全員の端末装置には、ゲームの進行結果に対応した画像やメッセージが表示されるので、ゲームの進行結果をメンバー全員で共有することができる。
このようなゲームの進行結果に対応した画像やメッセージには、メンバーが送信したメッセージと同様に時間情報などが付帯しているので、グループの端末装置においてゲームの進行結果を蓄積する一方で、タイムライン表示することによって、チャットとゲームが同時並行的に進行する場が提供されることになる。
換言すれば、チャットをしつつ、ゲームについても当該チャットのユーザインターフェースを流用して、対話形式で進行させることができる。

次に、実施形態の詳細について図面を参照して説明する。

＜全体構成＞
図２は、実施形態に係るシステムの全体的な構成を示すブロック図である。
この図に示されるように、システム１では管理サーバ１０が、複数の端末装置２０−１、２０−２、２０−３、…に対して、移動通信網Ｎｂ、ゲートウェイ１５およびインターネットＮａを介して接続された構成となっている。
なお、以降において、端末装置２０−１、２０−２、２０−３、…については、端末装置を特定せずに一般的に説明するので、符号における「−（ハイフン）」以下を省略して単に「２０」とする。

管理サーバ１０は、利用者の情報や、グループの情報などを管理する。このため、管理サーバ１０では、各種の情報をテーブル化している。また、管理サーバ１０は、各グループでのゲームの進行を制御する。

図３は、管理サーバ１０のハードウェア的な構成を示すブロック図である。この図に示されるように、管理サーバ１０は、装置全体を制御するＣＰＵ（Central Processing Unit）１０１と、ＣＰＵ１０１の主記憶として機能するＲＡＭ（Random Access Memory）１０２と、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）１０３と、ネットワークを介して通信するためのインターフェース（Ｉ／Ｆ）１０５と、時間情報を出力するＲＴＣ（Real Time Clock）１０６と、各種のプログラムやデータを記憶するストレージユニット１０８と、を含む。ストレージユニット１０８では、ＣＰＵ１０１によって管理されるデータベース１１８が構築される。

なお、データベース１１８によって管理される各種のテーブル等の詳細については後述する。
また、管理サーバ１０は、図１においては１台で構築されているが、２台以上に分散させるとともに外部からみたときに仮想的に１台であるかのようにみえる構成としても良い。一方で、管理サーバ１０の一部の機能を他のサービスを提供しているサーバで構築しても良い。また、管理サーバ１０が中継サーバを介して端末装置２０と接続するように構成しても良い。

端末装置２０は、例えば利用者が操作する携帯電話機である。この端末装置２０は、表示パネル２１０に重ねられたタッチパネル２２０を有し、利用者が表示パネル２１０に表示された画面に対してタッチ操作等することで、必要な情報の入力や各種の指示が与えられる構成となっている。

図４は、端末装置２０のハードウェア構成を示すブロック図である。この図に示されるように、端末装置２０は、ＣＰＵ２０１と、メモリ２０２と、通信部２０４と、ＲＴＣ２０６と、表示パネル２１０と、タッチパネル２２０と、を含む。

このうち、ＣＰＵ２０１は端末装置２０の全体を制御し、メモリ２０２は、基本プログラムや、管理サーバ１０から各種のサービスの提供を受けるためのアプリケーションプログラム、各種のデータなどを記憶する。ここでいうアプリケーションプログラムは、自己の端末装置２０で作成されたメッセージを送信したり、自己および他のメンバーによるメッセージをタイムライン表示したり、当該チャットにおいてゲームが開始されたときに当該ゲームの命令を指示したりするものであり、特定のサイトからダウンロードされて、端末装置２０にインストールされている。
通信部２０４は、移動通信網Ｎｂや無線ＬＡＮ網など介して管理サーバ１０と通信する。ＲＴＣ２０６は、現在時刻の時間情報を出力する。

表示パネル２１０は、例えば液晶表示装置や有機ＥＬ（Electro Luminescence）装置などのフラットディスプレイである。タッチパネル２２０は、詳細な説明については省略するが、表示パネル２１０によって表示された画面のタッチ位置（二次元座標値）を検出し、検出したタッチ位置を示す位置情報をＣＰＵ２０１に供給する。ＣＰＵ２０１は、タッチパネル２２０からの位置情報に基づいて、タッチ位置の移動方向や、移動速度、タッチ操作の種類等を検出する。
ここで、検出可能なタッチ操作の種類には、例えばタップ、フリック、ドラッグ、ピンチ等が含まれる。このうち、タップとは、表示画面を指で軽く叩く操作である。フリックとは、画面に表示された対象物を指で軽く払う操作である。ドラッグとは、画面に表示された対象物を指で接触させた状態で移動させる操作である。ピンチとは、表示画面に二本の指を接触させた状態で広げたり狭めたりする操作である。

なお、端末装置２０は、移動通信網Ｎｂに限られず、無線ＬＡＮ（Local Area Network）に接続される構成であっても良い。無線ＬＡＮに接続される場合、端末装置２０は、無線基地局（アクセスポイント）およびインターネットＮｂを経由して、上記管理サーバ１０に接続される。
また、端末装置２０は、携帯電話機に限られず、タブレット型コンピュータやＰＤＡ（Personal Digital Assistant）などでも良い。

図５は、メッセージの閲覧等がなされる際に、管理サーバ１０および当該端末装置２０で構築される機能ブロックを示す図である。
この機能ブロックは、管理サーバ１０においては、所定のプログラムを実行することによって、また、端末装置２０においては、予めインストールされた上記アプリケーションプログラムを実行することによって、それぞれ構築される。
なお、図２におけるインターネットＮａや、ゲートウェイ１５、移動通信網Ｎｂ、また、図３におけるＩ／Ｆ１０５、図４における通信部２０４などについては、データや情報等の伝送経路に過ぎないので、図５においては図示を省略している。

図５に示されるように、管理サーバ１０側では、データベース１１８とともに、受付部１２１、ゲーム制御部１２３、管理部１２５、送信情報一時記憶部１３０および送信部１４０が構築される。受付部１２１は、端末装置２０から後述するメッセージや、アイコン情報、アクノリッジ（受領情報）などを受け付ける。ゲーム制御部１２３は、受付部１２１によって受け付けられたアイコン情報に応じて、ときとしてゲームの進行を制御し、その結果を示す画像やメッセージなどの情報を作成して出力する。
このとき、ゲーム制御部１２３は、時間情報をＲＴＣ１０６から取得して、ゲームの進行結果に応じた情報に付帯させる。
管理部１２５は、データベース１１８を管理するものであり、主に受付部１２１によって受け付けられたメッセージや、ゲーム制御部１２３から出力されたゲームの結果を示す情報などの送信先を、当該データベース１１８にアクセスして特定する。

送信情報一時記憶部１３０は、詳細についてはグループ登録テーブルＴＢ２の後に説明するが、端末装置２０に送信すべき情報を一時的に記憶するものである。
送信部１４０は、送信情報一時記憶部１３０に記憶された情報を、実際に端末装置２０に送信するものである。
なお、管理サーバ１０は、複数の端末装置２０に情報を送信し、逆に、複数の端末装置２０から情報等を受信する。図５において、送信部１４０から端末装置２０以外に向かう矢印は、当該端末装置２０以外の端末装置にも情報が送信されることを示し、端末装置２０以外から受付部１２１に向かう矢印は、他の端末装置からの情報を受け付けることを示している。

一方、端末装置２０側では、ＣＰＵ２０１がアプリケーションプログラムを実行することによって、操作検出部２３１および表示制御部２３２が構築される。また、表示パネル２１０の表示領域には、メッセージ表示部２１２が設けられる。
操作検出部２３１は、タッチパネル２２０からの位置情報に基づいて、タッチ位置や、その移動方向、移動速度、タッチ操作の種類等を検出して出力する。

表示制御部２３２は、操作検出部２３１の位置情報や、送信部１４０からの情報に基づいて表示パネル２１０の表示内容を制御する。例えば、表示制御部２３２は、送信部１４０からの送信されたメッセージ等を記憶するとともに、送信日時の順にソートしてメッセージ表示部２１２においてタイムライン表示したり、アイコン選択画面を表示する旨の指示がなされたときに、使用可能状態のアイコンを一覧表示させたりする。

さて、データベース１１８には、送信先のほか、他に必要な情報を参照するために、利用者登録テーブルＴＢ１と、グループ登録テーブルＴＢ２と、ゲーム管理テーブルＴＢ３が構築される。そこで次に、これらのテーブルについて説明する。

＜利用者登録テーブル＞
図７は、利用者登録テーブルＴＢ１の一例を示す図である。
利用者登録テーブルＴＢ１は、利用者に関する情報を記憶するテーブルであり、図に示されるように、利用者ＩＤと、利用者の名前情報と、プロフィール画像とを利用者毎に対応付けて記憶する。
これらのうち、利用者ＩＤは、数字や記号などを組み合わせた情報であり、システム１において利用者を一意に識別する。利用者の名前情報は、メッセージ閲覧時において利用者同士で識別する名前を示し、実名やニックネームが用いられる。プロフィール画像情報は、当該利用者を示す画像を示し、利用者によって登録や、選択、編集などされたものが用いられる。このプロフィール画像は、メッセージの送信者が誰であるのかを一見して判るようにするために、後述するようにメッセージの近傍に表示させるものである。
なお、プロフィール画像情報については必ず登録すべきものではなく、利用者が登録しないことを選択することも可能である。登録しないことを選択した場合には、予め用意された画像を表示するようにしても良いし、何も表示しないようにしても良い。また、プロフィール画像情報については、実体そのものではなく、実体のリンク先（参照先）であっても良い。いずれにしても、利用者ＩＤ等から、プロフィール画像情報を取得できる手段が講じられていれば良い。

＜グループ登録テーブル＞
本実施形態において、メッセージの閲覧は、利用者ＩＤで識別される利用者のうち、予め作成されたグループの構成員（メンバー）に対して提供される。１つのグループは、２人以上のメンバーで構成され、いずれのメンバーも、利用者登録テーブルＴＢ１において利用者ＩＤが登録された利用者である。このようなグループのメンバーを管理するためのものが、グループ登録テーブルＴＢ２である。

図８は、グループ登録テーブルＴＢ２の一例を示す図である。この図に示されるように、グループ登録テーブルＴＢ２は、グループを一意に識別するグループＩＤと、グループの名称と、グループを構成するメンバーとして例えばＡからＥまでの５人の利用者ＩＤとをグループ毎に対応付けて記憶する。なお、グループメンバーの＜ｎｕｌｌ＞は、未設定の空き状態であることを示している。

図８の例において、矢印で示されるグループは、グループＩＤが「ａｙ０１」であって、グループ名称が「三十路の館」であり、利用者ＩＤが「ｘｘ１３」、「ｘｘ１８」、「ｘｘ１２」、「ｘｘ１５」の４名のメンバーによって構成されていることを示している。ここで、利用者ＩＤが「ｘｘ１３」、「ｘｘ１８」、「ｘｘ１２」、「ｘｘ１５」であるメンバーに関する情報、すなわち、利用者の名前情報やプロフィール画像情報については、図７に示した利用者登録テーブルＴＢ１を参照することで取得することができる。

なお、ある利用者は、一つのグループのみならず、異なる複数のグループのメンバーとなっても良い。図８の例では、例えば利用者ＩＤが「ｘｘ１３」である利用者は、グループＩＤが「ａｙ０１」のグループのメンバーであるとともに、グループＩＤが「ａｙ０２」のグループのメンバーでもあることが示されている。
また、ここでは説明の便宜のために、本実施形態ではグループを構成するメンバー数を「５」としているが、これに限定する趣旨ではなく、４人以下でも、６人以上であっても良い点については、いうまでもない。

＜ゲーム管理テーブル＞
本実施形態では、上述したようにゲームが複数のステージで構成され、ステージ１→ステージ２→ステージ３…というような過程を辿る。このため、あるグループで進行しているゲームがいまどのステージにあるのか等について管理するものが、ゲーム管理テーブルＴＢ３である。

図９は、ゲーム管理テーブルＴＢ３の一例を示す図であり、ある１つのグループにおいて、ある１つのゲームについて示した例である。
この図に示されるように、ゲーム管理テーブルＴＢ３には、当該ゲームを構成する複数のステージのそれぞれについて、使用可能であるのか、使用不可なのかを示すステージフラグが登録されている。
図９の例では、最初のステージ１について無料で制限なくプレイすることができる。このため、ステージ１についてステージフラグは、初期状態で使用可能である。一方、次のステージ２以降については、直前のステージをクリアした上で、いずれかのメンバーによる所定の金額の支払いが条件となっている。したがって、ステージ２以降についてステージフラグの初期状態は使用不可である。ただし例えば、ステージ１をクリアした上で、図示の金額（１ドル）が支払われれば、ステージ２についてのステージフラグは、初期状態の使用不可から使用可能に変更される。このため、ゲーム管理テーブルＴＢ３を参照すると、ある１つのグループで進行しているゲームが、どのステージまで使用可能（どのステージから使用不可）であるかが判る構成となっている。

なお、図９は、１つのグループについて１つのゲームの例を示している。本実施形態においては、実際には、図８に示されるように複数のグループが登録され、また、１つのグループについて１つのゲームに限られず、異なる複数のゲームが進行する場合もあり得る。したがって、図９のようなテーブルは、実際にはグループＩＤとゲームを識別するゲーム識別情報とに対応付けられた組み合わせのそれぞれについて設けられる。

＜アイコン＞
次に、ゲームの進行に関連するアイコンについて説明する。
アイコンは、あるゲームについて１つ以上用意されるとともに、ゲームの進行に応じて増えたり、ある回数使用すると以降使用ができなくなったり、金銭の支払いを条件として使用可能になったりする。
このため、本実施形態においては次のようにして、アイコンの使用可能または使用不可が管理されている。
すなわち、本実施形態では、第１に、端末装置２０において各アイコンにつき使用可能であるか使用不可であるかを示すアイコンフラグがテーブル化される一方、当該アイコンフラグに応じてアイコンの使用可能、使用不可が決定される。第２に、当初から使用できるアイコンについてのアイコンフラグは使用可能に設定され、それ以外のアイコンについてのアイコンフラグは使用不可に設定されるとともに、アイコンについての使用条件を満たしたときに、アイコンフラグが使用可能に変更される一方で、アイコンについての使用が満了したときに、アイコンフラグを使用不可に変更される。第３に、グループメンバー同士にわたって、各アイコンについてのアイコンフラグについて同一性を担保するために、端末装置２０でのアイコンフラグについては、管理サーバによる変更通知によってのみ変更される。

図１０は、アイコンを管理するアイコン管理テーブルの一例である。
この図に示されるように、アイコン管理テーブルは、アイコンを識別するアイコン情報（アイコンＩＤ）毎に、使用可能であるのか、使用不可なのかを示すアイコンフラグが登録されている。
図１０の例では、アイコン情報が「ｙｙ０１」から「ｙｙ０４」までのアイコンについては、当初から使用できるため、アイコンフラグが初期状態から使用可能に設定されているが、それ以外については使用不可に設定されている。ここで、例えばアイコン情報が「ｙｙ０５」および「ｙｙ０６」のアイコンについて使用条件がステージ１のクリアである場合に、実際にあるグループにおいてゲームのステージ１がクリアされたとき、管理サーバ１０は、当該グループのメンバーの端末装置２０に、アイコン情報が「ｙｙ０５」および「ｙｙ０６」であるアイコンフラグを使用可能に変更する変更通知を送信する。
これにより、当該グループのメンバーの端末装置２０において、アイコン管理テーブルが変更通知にしたがって変更されるので、使用できるアイコンについての同一性が保たれる。
なお、アイコン管理テーブルについては、表示制御部２３２からアクセス可能な地点に設けられれば良いので、図５では特に図示していない。また、アイコン管理テーブルについては、端末装置２０の電源が遮断されても登録内容が保持されるように、不揮発性に記録される。

次に、送信情報一時記憶部１３０の詳細について説明する。図６は、送信情報一時記憶部１３０の構成を示すブロック図である。
この図に示されるように、送信情報一時記憶部１３０は、バッファ制御部１３１と、グループ登録テーブルＴＢ２に登録されたグループＩＤのそれぞれに対応するバッファ群１３３を有する。このため、グループ登録テーブルＴＢ２に新たに１つのグループＩＤが登録されると、登録されたグループＩＤに対応して、１つのバッファ群１３３が設けられることになる。
１つのグループに対応したバッファ群１３３には、当該グループを構成するメンバーのそれぞれに対応したバッファ１３５が設けられる。本実施形態では、グループを構成するメンバー数を「５」としているので、１つのバッファ群１３３を構成するバッファ１３５
の個数についても、メンバーＡ〜Ｅのそれぞれに対応して「５」としている。
なお、バッファ１３５から読み出された情報は、送信部１４０に供給されて、当該送信部１４０によって端末装置２０に送信されることになる。

管理部１２５から供給される情報は端末装置２０に送信すべき情報であり、当該情報には、グループＩＤおよび利用者ＩＤが付帯する。バッファ制御部１３１は、管理部１２５から供給された情報を、グループＩＤに対応するバッファ群１３３であって、利用者ＩＤに対応するバッファ１３５に記憶させる一方、例えば後述するように一定時間毎に、バッファ１３５からの読み出しや、情報の削除などを実行する。

＜システムの動作＞
次に、システム１の動作について、便宜的に先に端末装置２０側を説明し、次に管理サーバ１０側を説明する。

図１１は、端末装置２０で実行される閲覧処理の動作を示すフローチャートであり、図１２は、閲覧処理における受信処理の詳細動作を示すフローチャートである。
まず、端末装置２０において、利用者がメッセージを閲覧するために所定の操作をしたとき、例えば当該機能を示すアイコンなどをメインメニュー画面（図示省略）においてタップ操作したとき、操作検出部２３１は、当該端末装置２０が閲覧処理に移行する旨の通知を、当該端末装置２０の利用者ＩＤとともに、管理サーバ１０における受付部１２１を介して管理部１２５に通知する。

管理部１２５は、グループ登録テーブルＴＢ２にアクセスして当該端末装置２０の利用者ＩＤをメンバーとするグループを特定し、利用者登録テーブルＴＢ１にアクセスして特定したグループのメンバーに関する情報を取得して、当該端末装置２０の表示制御部２３２に転送する。表示制御部２３２は、転送された情報に基づいて、メッセンジャートップ画面を作成して、表示パネル２１０に表示させる。これにより、表示パネル２１０においては、メッセンジャートップ画面が表示される（ステップＳａ１１）。

図１５は、メッセンジャートップ画面の一例を示す図である。
この図に示されるように、メッセンジャートップ画面においては、端末装置２０の利用者をメンバーとするグループが、グループ名称、メンバーのプロフィール画像、当該グループのメンバーによる最終発言日時などとともに、例えば最新のメッセージが送信された順番で一覧表示される。

また、メッセンジャートップ画面においては、グループの一覧表示のほか、各種のソフトウェアボタンや各種案内が表示されている。
このうち、ボタン２５１は、新規グループの作成を指示するものである。
領域２５２では、端末装置２０の利用者に関係する「お知らせ」が告知される。
マーク２５３は、それが付されたグループにおいて当該端末装置２０の利用者が未読のメッセージがあることを示している。
ボタン２５４、２５５、２５６のそれぞれは、各グループに対応してそれぞれ表示される。このうち、ボタン２５４は、対応するグループのメッセージを閲覧するページへの移動を指示するものであり、ボタン２５５は、そのグループの編集を指示するものであり、ボタン２５６は、そのグループから退会を指示するものである。
ボタンＦｉｎは、このメッセージ閲覧の終了（メインメニュー画面に戻ること）を指示するものである。

なお、各グループにおいて、左端のメンバーのプロフィール画像を囲む太枠は、当該グループの管理者（作成者）であることを示す。
また、一覧すべきグループが多数あって、表示パネル２１０で１度に表示しきれない場合、例えばフリックや、スライドバーの移動などの操作によって、上下のスクロール表示が可能になる。各グループの表示順序は、最新のメッセージが送信された順に限られず、グループの作成順（新しい順、古い順）、グループメンバーの多い順、少ない順などでも良い。
端末装置２０の利用者をメンバーとするグループが存在しない場合、特に図示しないが、その旨の警告がメッセンジャートップ画面に表示される。

メッセンジャートップ画面において、操作検出部２３１は、タッチパネル２２０に対して適切な操作がなされたのか否かを判別する（ステップＳａ１２）。ここで、適切な操作とは、予め想定された範囲内での操作、例えばボタン表示部分などの操作をいう。操作がなければ、または、操作があっても想定されていない無効な領域に対する操作であれば（ステップＳａ１２の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ１１に戻る。このため、何らかの適切な操作があるまで、メッセンジャートップ画面の表示が継続することになる。
適切な操作がなされたとき（ステップＳａ１２の判別結果が「Ｙｅｓ」になったとき）、操作検出部２３１は、当該操作が終了の指示、すなわちボタンＦｉｎの表示部分への操作であったか否かを判別する（ステップＳａ１３）。

終了の指示であれば（ステップＳａ１３の判別結果が「Ｙｅｓ」であれば）、操作検出部２３１は、その旨を表示制御部２３２に通知し、当該表示制御部２３２は、閲覧処理を終了させてメインメニュー画面の表示に戻す。
終了の指示でなければ（ステップＳａ１３の判別結果が「Ｎｏ」であれば）、操作検出部２３１は、当該操作がグループ選択の指示、すなわち、いずれかのグループに対応したボタン２５４の表示部分への操作であったか否かを判別する（ステップＳａ２１）。

当該操作がグループ選択でなければ（ステップＳａ２１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ３６に移行する。ステップＳａ３６においては、当該操作に対応した処理が実行される。このような処理の例としては、グループの一覧の表示部分がフリックされたときに当該表示部分をスクロール表示させる処理や、領域２５２がタップ操作されたときに当該端末装置２０の利用者に関係する「お知らせ」を例えば別画面で詳細に表示させる処理、ボタン２５５の表示部分が操作されたときに対応するグループの編集させる処理、ボタン２５６の表示部分が操作されたときに対応するグループから退会する処理などが挙げられる。ステップＳａ３６の後、ステップＳａ１１におけるメッセンジャートップ画面の表示に戻る。

一方、当該操作がグループの選択であれば（ステップＳａ２１の判別結果が「Ｙｅｓ」であれば）、操作検出部２３１は表示制御部２３２に対しその旨を通知し、この通知を受けて表示制御部２３２は、管理サーバ１０の送信部１４０から各種情報を受信する受信処理を実行する（ステップＳａ２２）。

この受信処理の詳細にはついては図１２に示される通りである。
表示制御部２３２が受信処理によって送信部１４０から受信する情報としては、本実施形態にあっては、第１に、他のメンバーによるメッセージ、第２に、他のメンバーによるアイコン情報、第３に、ゲームの進行結果に対応した画像やメッセージ、および、第４に、指定されたアイコンフラグの変更を通知する変更通知がある。
なお、メッセージや、アイコン情報、画像には、いずれも送信日時（作成日時）を示す時間情報と、送信者を示す識別情報とが付帯する。送信者を示す識別情報は、メンバーによって送信されたものであれば利用者ＩＤであり、管理サーバ１０で作成等されたものであればシステムＩＤである。

受信処理において、表示制御部２３２は、まず他のメンバーによるメッセージを受信したか否かを判別する（ステップＳａ４１）。当該メッセージを受信していれば（ステップＳａ４１の判別結果が「Ｙｅｓ」であれば）、表示制御部２３２は、当該メッセージを付帯情報とともにメモリ２０２（図３参照）に格納する（ステップＳａ４２）。なお、他のメンバーによるメッセージを受信していなければ（ステップＳａ４１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ４３にスキップする。

続いて、表示制御部２３２は、他のメンバーによるアイコン情報を受信したか否かを判別する（ステップＳａ４３）。当該アイコン情報を受信していれば（ステップＳａ４３の判別結果が「Ｙｅｓ」であれば）、表示制御部２３２は、当該アイコン情報を付帯情報とともにメモリ２０２に格納する（ステップＳａ４４）。なお、受信していなければ（ステップＳａ４３の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ４５にスキップする。

次に、表示制御部２３２は、管理サーバ１０で作成されたメッセージや画像などを受信したか否かを判別する（ステップＳａ４５）。当該メッセージ等を受信していれば（ステップＳａ４５の判別結果が「Ｙｅｓ」であれば）、表示制御部２３２は、当該メッセージ等を付帯情報とともにメモリ２０２に格納する（ステップＳａ４６）。なお、受信していなければ（ステップＳａ４５の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ４７にスキップする。

後述するように利用者がグループを選択してメッセージを送信する旨の操作をしたときも、自己のメッセージは付帯情報とともにメモリ２０２に格納される。このため、メッセンジャートップ画面において利用者が自己の属するグループを選択したとき、当該端末装置２０のメモリ２０２には、当該グループにおける自他のメンバーのメッセージや、管理サーバ１０で作成されたメッセージ等が、付帯情報とともに逐一格納されるので、一種のメッセージ等の履歴が形成される。
なお、メモリ２０２には、現在日時よりも一定期間以上古いメッセージ等については、順次削除するようにしても良い。

そして、表示制御部２３２は、アイコンフラグを変更する変更通知を受信したか否かを判別する（ステップＳａ４７）。当該変更通知を受信していれば（ステップＳａ４７の判別結果が「Ｙｅｓ」であれば）、表示制御部２３２は、当該変更通知で指定されたアイコンフラグを変更する（ステップＳａ４８）。なお、ステップＳａ４８の処理後、または、当該変更通知を受信していないとき（ステップＳａ４７の判別結果が「Ｎｏ」であるとき）、処理手順は、図１１におけるステップＳａ２３に移行する。

さて、受信処理後、メモリ２０２には、上記ステップＳａ４２、Ｓａ４４において、選択グループにおける自他のメンバーのメッセージや、アイコン情報、管理サーバ１０で作成された画像やメッセージ等が格納された状態にあるので、表示制御部２３２は、これらのメッセージをタイムラインで表示する処理を実行する（ステップＳａ２３）。
詳細には、表示制御部２３２は、メモリ２０２に格納したメッセージ等を付帯情報とともに読み出し、例えば図２２に示されるよう、グループメンバーによるメッセージおよびアイコンについてはメッセージ表示部２１２の一端である例えば右側の領域（２）、（３）および（４）に、管理サーバ１０によるメッセージ等についてはメッセージ表示部２１２の他端である左側の領域（１）および（５）に、それぞれ送信（作成）時間の順にソートして表示させる。
このため、図２２において下側に向かうほど、送信時間が古いものであるとしたとき、領域（１）〜（５）によるタイムライン表示は、領域（１）が最新で、領域（２）、（３）、（４）、（５）の順で古いものとなる。
なお、タイムライン表示は、送信日時が新しいものほど画面の下方に向かうように配列させても良い。グループメンバーによるメッセージおよびアイコンについてはメッセージ表示部２１２の左側に配置させる一方、管理サーバ１０によるメッセージ等についてはメッセージ表示部２１２の右側に配置させても良い。また、左右ではなく、上下に振り分けも良い。

図２２において、グループメンバーによるメッセージは、画面右側に寄せられた吹き出しで表示される。詳細には、送信者を示すプロフィール画像が画面右端に表示されるとともに、吹き出しが当該プロフィール画像から発せられたように表現されている。また、メンバーのプロフィール画像の近傍には、メッセージの送信時間や、送信者の名前情報も表示される。
ここで、領域（２）および（３）においては、メンバーがアイコンを選択した場合の表示例が示されており、アイコン情報に対応したアイコン（画像）が表示されている。この場合のアイコンは、アイコン情報に対応したものであり、予めテーブルとして各端末装置２０で記憶したものや、管理サーバ１０ほか他のサーバに問い合わせて取得したものなどが用いられる。
また、領域（４）においては、メンバーがアイコンの選択ではなく、メッセージを送信した場合の例である。吹き出しにハッチングが付されているのは、この端末装置２０の利用者が送信したメッセージであることを示している。すなわち、領域（４）のメッセージは、この端末装置２０の利用者によって送信されたメッセージであることを示している。これによって、自己のメッセージは、他のメンバーによるメッセージと容易に区別することができる。
自他のメッセージを区別する態様としては、自己の吹き出しにハッチングを付すほかに、色や形状を異ならせることや、自己のプロフィール画像を非表示とするなど、種々考えられる。

一方、管理サーバ１０によるメッセージは、画面左側に寄せられた吹き出しで、画面左端から発せられたように表現されている。また、ゲームの進行結果に応じた画像が吹き出しの上側に表示されている。なお、メッセージの吹き出しの近傍には、送信時間が表示される。ここでは、ゲームの進行結果が、当該結果に応じた画像とメッセージとの双方で表示されているがいずれか一方のみの場合もある。
なお、管理サーバ１０によるメッセージ等であることは、送信者がシステムＩＤであることによって容易に判明する。

メッセージ表示画面では、メッセージ等をタイムライン表示するメッセージ表示部２１２のほかに、メッセージ入力部２１１、ボタン２７１、２７２、２７３が表示される。このうち、ボタン２７１は、メッセージ入力部２１１に入力されたメッセージの内容を確定させて送信を指示するソフトウェアボタンである。ボタン２７２は、アイコンを選択するために、選択画面を表示させることを指示するソフトウェアボタンである。ボタン２７３は、１つ前のメッセンジャートップ画面に戻ることを指示するソフトウェアボタンである。

このようなメッセージ表示画面において、操作検出部２３１は、適切な操作がなされたのか否かを判別する（ステップＳａ２４）。操作がなければ、または、操作があっても想定されていない無効な領域に対する操作であれば（ステップＳａ２４の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ２２に戻る。
このため、何らかの適切な操作がなされるまで、処理手順がステップＳａ２２→Ｓａ２３→Ｓａ２４→（Ｓａ２２）で循環するので、メッセージ表示画面が継続するとともに、管理サーバ１０から新たなメッセージ等を受信すれば、そのメッセージがタイムラインにおいて追加表示されることになる。

本実施形態ではメッセージ表示画面に対する適切な操作としては、次の５種類を想定している。すなわち、第１にボタン２７１の表示部分へのタップ等の操作、第２にボタン２７２の表示部分へのタップ等の操作、第３にボタン２７３の表示部分へのタップ等の操作、第４にアイコン購入操作、および、第５にゲームのステージ購入操作が想定されている。このほかにも、メッセージ表示画面に対する適切な操作としては、メッセージをスクロール表示させるためのフリックや、拡大表示のためのピンチなども挙げられるが、本発明とは直接関係しないので説明を省略することにする。

さて、適切な操作がなされた場合（ステップＳａ２４の判別結果が「Ｙｅｓ」になった場合）、操作検出部２３１は、まず、当該操作がメッセージの送信の指示、すなわちボタン２７１の表示部分へのタップ等の操作であったか否かを判別する（ステップＳａ２５）。
ボタン２７１への操作であったとき（ステップＳａ２５の判別結果が「Ｙｅｓ」であったとき）、操作検出部２３１は、当該操作時点においてメッセージ入力部２１１に入力されたメッセージを、当該送信の指示がなされたときにＲＴＣ２０６から取得した時間情報（送信日時）と、選択されたグループＩＤと、自己の利用者ＩＤとに関連付けて、表示制御部２３２と管理サーバ１０とに送信する（ステップＳａ２６）。表示制御部２３２は、時間情報とグループＩＤと自己の利用者ＩＤとを付帯させて、当該メッセージをメモリ２０２に格納する。
この後、処理手順がステップＳａ２２に戻る。このため、メモリ２０２に格納された当該メッセージは、ステップＳａ２２を経た次のステップＳａ２３のメッセージ表示画面において、タイムラインに直ちに追加されて表示されることになる。

メッセージ表示画面に対してなされた操作がメッセージの送信の指示でなかったとき（ステップＳａ２５の判別結果が「Ｎｏ」であったとき）、操作検出部２３１は、次に、当該操作がアイコンの選択画面を表示させる指示、すなわちボタン２７２の表示部分へのタップ等の操作であったか否かを判別する（ステップＳａ２８）。
ボタン２７２への操作であったとき（ステップＳａ２８の判別結果が「Ｙｅｓ」であったとき）、操作検出部２３１は、その旨を表示制御部２３２に通知し、その通知を受けて、表示制御部２３２は、表示パネル２１０の表示領域に、例えば図２５（ａ）に示されるように、ゲームの進行に関連したアイコン２７５を一覧表示させたアイコン選択画面を表示させる（ステップＳａ２９）。

アイコン選択画面において、操作検出部２３１は、なんらかの操作がなされたときに当該操作がいずれかのアイコン２７５を選択するタッチ等の操作であったか否かを判別する（ステップＳａ３０）。アイコン選択画面に対してなされた操作がアイコン２７５への操作であったとき（ステップＳａ３０の判別結果が「Ｙｅｓ」であったとき）、操作検出部２３１は、操作されたアイコンを識別するアイコン情報を付帯情報とともに表示制御部２３２と管理サーバ１０とに送信する（ステップＳａ３１）。表示制御部２３２は、当該アイコン情報を付帯情報とともにメモリ２０２に格納する。
この後、処理手順がステップＳａ２２に戻る。このため、メモリ２０２に格納された当該アイコン情報で識別されるアイコンは、ステップＳａ２２を経た次のステップＳａ２３のメッセージ表示画面において、タイムラインに直ちに追加されて表示されることになる。

一方、アイコン選択画面に対してなされた操作がアイコン２７５への操作でなかったとき、例えば当該アイコン選択画面を閉じる旨を指示するボタン２７６への操作であったとき（ステップＳａ３０の判別結果が「Ｎｏ」であったとき）、処理手順がステップＳａ２２に戻る。アイコン２７５への操作でない例としては、このほかにもアイコン選択画面におけるフリックやスライドバーの移動などが挙げられるが、これらの例についての動作の説明は省略することにする。

メッセージ表示画面に対してなされた操作がメッセージの送信の指示でなく、アイコンの選択画面を表示させる指示でもなかったとき（ステップＳａ２５、Ｓａ２８の判別結果がいずれも「Ｎｏ」であったとき）、操作検出部２３１は、当該操作がメッセンジャートップ画面に戻る指示、すなわちボタン２７３の表示部分への操作であったか否かを判別する（ステップＳａ３２）。
当該操作がボタン２７３の表示部分のタッチ操作であれば（ステップＳａ３２の判別結果が「Ｙｅｓ」であれば）、操作検出部２３１は、その旨を表示制御部２３２に通知し、当該通知を受けた表示制御部２３２は、再びメッセンジャートップ画面を表示させる。

一方、当該操作がボタン２７３の表示部分のタッチ操作でなければ（ステップＳａ３２の判別結果が「Ｎｏ」であれば）、操作検出部２３１は、当該操作がアイコンの購入操作であったか否かを判別する（ステップＳａ３３）。
当該操作がアイコンの購入操作であれば（ステップＳａ３３の判別結果が「Ｙｅｓ」であれば、操作検出部２３１は、購入が指示されたアイコンを示す情報を管理サーバ１０に送信する（ステップＳａ３４）。詳細には例えば、アイコンの購入操作があったときに操作検出部２３１は、その旨を表示制御部２３２に通知し、その通知を受けて表示制御部２３２は、表示パネル２１０の表示領域に対し、通知時点で購入可能なアイコンの一覧を表示させる（図示省略）。一覧においてアイコンが選択されるとともに、購入金額の支払いや認証、確認などの所定の処理を経たときに、操作検出部２３１は、購入が指示されたアイコンを示す情報を管理サーバ１０に送信する。この後、処理手順がステップＳａ２２に戻って、メッセージ表示画面が再び表示されることになる。

また、当該操作がアイコンの購入操作でなければ（ステップＳａ３３の判別結果が「Ｎｏ」であれば、当該操作は、ゲームのステージ購入操作である。このため、操作検出部２３１は、購入が指示されたステージを示す情報を管理サーバ１０に送信する（ステップＳａ３５）。
詳細には、操作検出部２３１は、アイコン購入指示と同様に、ステージ購入操作があった旨を表示制御部２３２に通知し、その通知を受けて表示制御部２３２は、表示パネル２１０の表示領域に対し、通知時点で購入可能なゲームのステージを一覧表示させる（図示省略）。一覧においてステージが選択されるとともに、購入金額の支払いや認証、確認などの所定の処理を経たときに、操作検出部２３１は、購入が指示されたゲームのステージを示す情報を管理サーバ１０に送信する。この後、処理手順がステップＳａ２２に戻って、メッセージ表示画面が再び表示されることになる。

このように閲覧処理においては、グループが選択されると、メッセージ表示画面が表示されるとともに、当該表示画面の操作に応じた処理が実行されることになる。

続いて、管理サーバ１０側の動作について説明する。管理サーバ１０では、メッセージの閲覧時において受付処理とバッファ処理とが互い独立して実行される。
このうち、受付処理とは、概略的にいえば、複数の端末装置２０から情報を受け付けたときに当該情報を、送信先に対応するバッファ１３５に格納する処理である。また、バッファ処理とは、バッファ１３５に格納された情報を、当該バッファ１３５に対応する端末装置２０に送信する処理である。

まず、受付処理について説明する前に、上述したように端末装置２０から送信される情報、すなわち管理サーバ１０からみて端末装置２０から受け付ける情報としては、メッセージ（ステップＳａ２７）と、操作されたアイコンを示すアイコン情報（ステップＳａ３１）と、購入が指示されたアイコンを示す情報（ステップＳａ３４）と、購入が指示されたステージを示す情報（ステップＳａ３５）との４種類が想定されている。

＜受付処理＞
図１３は、管理サーバ１０で実行される受付処理の動作を示すフローチャートである。
まず、管理サーバ１０の受付部１２１では、いずれかの端末装置２０から４種類のいずれかの情報を受け付けたか否かを判別する（ステップＳｂ１１）。
いずれの情報について受け付けていなければ（ステップＳｂ１１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳｂ１１に戻る。このため、いずれかの情報を受け付けるまで、処理手順がステップＳｂ１１を循環することになる。
いずれかの情報を受け付けると（ステップＳｂ１１の判別結果が「Ｙｅｓ」になると）、受付部１２１は、当該情報が端末装置２０から送信されたメッセージであるか否かを判別する（ステップＳｂ１２）。メッセージであるならば（ステップＳｂ１２の判別結果が「Ｙｅｓ」であれば）、受付部１２１は、当該メッセージを付帯情報とともに管理部１２５に転送し、管理部１２５は、当該メッセージに付帯する利用者ＩＤおよびグループＩＤから、当該メッセージの送信先を決定する。

ここでいうグループＩＤは、当該メッセージの送信者が送信前にメッセンジャートップ画面において選択したグループであり、どのグループのメンバー宛に当該メッセージを送信しようとしているのかを示している。
一方、当該メッセージを送信したメンバーの端末装置２０では、当該メッセージが、ステップＳａ２６を経たＳａ２３のメッセージ表示画面においてすでにタイムライン表示されている。このため、当該メッセージについては、グループＩＤで特定されるグループメンバーのうち、当該メッセージを送信したメンバーを除いたメンバーの端末装置２０に送信する必要がある。
このため、管理部１２５は、グループ登録テーブルＴＢ２にアクセスして、グループＩＤで規定されるグループのメンバーを特定するとともに、これらのメンバーのうち、利用者ＩＤで示される利用者（送信者）以外のメンバーの端末装置を、当該メッセージの送信先として決定する。

管理部１２５は、当該メッセージとグループＩＤと決定した送信先とを送信情報一時記憶部１３０に供給する。送信情報一時記憶部１３０は、グループＩＤに対応するバッファ群１３３であって、決定された送信先に対応するメンバー（グループメンバーのうち、メッセージの送信者を除くメンバー）のバッファ１３５に当該メッセージを格納する（ステップＳｂ１３）。
なお、バッファ１３５に格納されたメッセージを端末装置２０に送信するのは、後述するバッファ処理である。ステップＳｂ１３の後、処理手順はステップＳｂ１１に戻る。

一方、受け付けた情報が端末装置２０から送信されたメッセージでなければ（ステップＳｂ１２の判別結果が「Ｎｏ」であれば）、受付部１２１は、当該情報が端末装置２０から送信されたアイコン情報であるか否かを判別する（ステップＳｂ１４）。アイコン情報であるならば（ステップＳｂ１４の判別結果が「Ｙｅｓ」であれば）、受付部１２１は、当該アイコン情報を付帯情報とともにゲーム制御部１２３および管理部１２５に転送する。ここで、管理部１２５は、当該メッセージと同様にして当該アイコン情報の送信先を決定する。管理部１２５は、当該アイコン情報を送信情報一時記憶部１３０に供給し、送信情報一時記憶部１３０は、グループＩＤに対応するバッファ群１３３であって、決定された送信先に対応するメンバー（グループメンバーのうち、アイコン情報の送信者を除くメンバー）のバッファ１３５に当該メッセージを格納する（ステップＳｂ１５）。

また、ゲーム制御部１２３は、当該アイコン情報に付帯するグループＩＤで特定されるグループで実行されているゲームを、当該アイコン情報に応じて進行させ、その進行結果に対応する画像やメッセージを作成して、当該画像やメッセージを、グループＩＤとともに管理部１２５に供給する（ステップＳｂ１６）。
詳細には、ゲーム制御部１２３は、例えばアイコン情報とゲーム命令とを関連付けたテーブルから、受け付けられたアイコン情報に対応したゲーム命令を取得し、ゲームの内容を当該ゲーム命令に応じて進行させる。ゲームの進行結果に対応したものとしては、本実施形態としては、画像またはメッセージのいずれか一方でも良いし、両方でも良い。また、音声などを追加しても良い。
なお、ゲーム制御部１２３は、ゲーム命令に応じて直ちにゲームの内容を進行させるとは限らない。例えば、ゲーム制御部１２３は、アイコン情報を取得してからある程度の時間差（例えば１０分）をおいてゲームを進行させる場合もある。また、ゲーム制御部１２３は、ゲーム命令に応じて必ずゲームの内容を進行させるとは限らない。例えば、ゲーム制御部１２３は、アイコン情報の３回の取得に対して、１回の割合でゲームを進行させても良いし、特定のアイコン情報が組み合わせられたときのみ、ゲームを進行させても良い。
また、ゲームの進行に対応した情報としては、画像やメッセージに限られず、後述するようにアイコン情報で特定されるアイコンの使用回数が上限に達したなどのときに、そのアイコンフラグを使用不可に変更する変更通知が含まれる。

端末装置２０から送信されたメッセージやアイコン情報については、グループＩＤで特定されるグループメンバーのうち、送信者を除いたメンバーの端末装置２０に送信したが、ゲームの進行結果に対応した情報については、送信者を含めたメンバー全員に送信する必要がある。
このため、管理部１２５は、ゲームの進行結果に対応した情報の送信先を、グループＩＤで規定されるグループのメンバー全員として決定して、当該情報を送信情報一時記憶部１３０に供給する。送信情報一時記憶部１３０は、グループＩＤに対応するバッファ群１３３であって、メンバー全員のバッファ１３５に、ゲームの進行結果に対応した情報をそれぞれ格納する（ステップＳｂ１７）。この後、処理手順はステップＳｂ１１に戻る。

受け付けられた情報がアイコン情報でなければ（ステップＳｂ１５の判別結果が「Ｎｏ」であれば）、受付部１２１は、金銭の支払いを条件として使用可能になるアイコンの購入指示であるか否かを判別する（ステップＳｂ１８）。
アイコンの購入指示には、具体的には、購入しようとするアイコンの識別情報（アイコン情報）や、当該購入を指示した利用者の識別情報（利用者ＩＤ）、そのアイコンを用いるゲームがどのグループで選択されたかを示すグループＩＤとが含まれる。
アイコンの購入指示であれば（ステップＳｂ１８の判別結果が「Ｙｅｓ」であれば）、受付部１２１は、当該指示をゲーム制御部１２３に転送し、ゲーム制御部１２３は、金銭の支払い以外の他の条件を満たしているか否かを判別する（ステップＳｂ１９）。他の条件を満たしていなければ（ステップＳｂ１９の判別結果が「Ｎｏ」であれば）、本実施形態では、処理手順がステップＳｂ１１に戻るので、当該購入指示は無視される。ただし、当該購入指示が無効である旨、および、当該アイコンが使用可能とするための他の条件を明示するメッセージを、当該購入指示を送信した端末装置２０に返信しても良い。

アイコン購入について金銭の支払い以外の他の条件を満たしている場合（ステップＳｂ１９の判別結果が「Ｙｅｓ」である場合）、ゲーム制御部１２３は、その旨を管理部１２５に通知する。管理部１２５は、金銭の支払いについて所定の認証手続きを経た上で、当該指示のあったアイコンフラグを使用可能に変更する変更通知を、送信情報一時記憶部１３０に供給する（ステップＳｂ２０）。また、管理部１２５は、当該変更通知の送信先をグループＩＤで規定されるグループのメンバー全員の端末装置を、当該変更通知をメッセージの送信先として決定する。
これにより、送信情報一時記憶部１３０は、グループＩＤに対応するバッファ群１３３であって、メンバー全員のバッファ１３５に当該変更通知を格納する（ステップＳｂ１７）。

一方、受け付けられた情報がアイコンの購入指示でなければ（ステップＳｂ１８の判別結果が「Ｎｏ」であれば）、受付部１２１は、当該受け付けられた情報が金銭の支払いを条件とするステージの購入指示であるか否かを判別する（ステップＳｂ２１）。
ステージの購入指示には、具体的には、購入しようとするステージの識別情報や、当該購入を指示した利用者の利用者ＩＤ、グループＩＤが含まれる。
ステージの購入指示であれば（ステップＳｂ２１の判別結果が「Ｙｅｓ」であれば）、受付部１２１は、当該指示をゲーム制御部１２３に転送し、ゲーム制御部１２３は、金銭の支払い以外の他の条件を満たしているか否かを判別する（ステップＳｂ２２）。他の条件、例えば１つ前のステージをクリアすることを満たしていなければ（ステップＳｂ２２の判別結果が「Ｎｏ」であれば）、本実施形態では、処理手順がステップＳｂ１１に戻るので、当該購入指示は無視される。ただし、アイコンの購入指示と同様に、当該ステージの購入指示が無効である旨、および、当該ステージの購入するための他の条件を明示するメッセージを、当該購入指示を送信した端末装置２０に返信しても良い。

ステージの購入について金銭の支払い以外の他の条件を満たしている場合（ステップＳｂ２２の判別結果が「Ｙｅｓ」である場合）、ゲーム制御部１２３は、その旨を管理部１２５に通知する。管理部１２５は、金銭の支払いについて所定の認証手続きを経た上で、ゲーム管理テーブルＴＢ３にアクセスして当該指示のあったステージを使用可能に変更する（ステップＳｂ２３）。これにより、当該グループにおいては、購入指示のあったステージにゲームが進行することが許可される。また、このとき、当該グループのメンバーに、当該ステージへの進行が許可されたメッセージを通知しても良い。この後、処理手順はステップＳｂ１１に戻る。

なお、受け付けられた情報がステージの購入指示でなければ（ステップＳｂ２１の判別結果が「Ｎｏ」であれば）、管理サーバ１０では、当該情報に応じた処理が実行される（ステップＳｂ２４）。この処理の例としては、端末装置２０から受領情報を受付部１２１が受け付けたときに、当該受領情報をバッファ制御部１３１に供給する処理などが挙げられる。この後、処理手順はステップＳｂ１１に戻る。

このように受付処理では、管理サーバ１０において端末装置２０から情報を受け付ける毎に、当該情報に応じた処理が繰り返し実行される。

＜バッファ処理＞
受付処理のステップＳｂ１３、Ｓｂ１７において、端末装置２０に送信すべき情報は、当該端末装置２０に対応するバッファ１３５に格納されるのみであり、実際にバッファ１３５に格納された情報を端末装置２０に送信処理は、次に説明するバッファ処理で実行される。そこで次に、バッファ処理について説明する。

図１４は、管理サーバ１０で実行されるバッファ処理の動作を示すフローチャートである。
まず、管理サーバ１０の送信部１４０は、前回の実行から所定時間、例えば１００ミリ秒経過したか否かを判別する（ステップＳｂ３１）。所定時間経過してなければ（ステップＳｂ３１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳｂ３１に戻る。このため、一定時間経過するまで処理手順がステップＳｂ３１を循環する。
やがて一定時間経過すると（ステップＳｂ３１の判別結果が「Ｙｅｓ」になると）、送信部１４０は、未送信の情報、すなわちバッファ１３５に格納された情報があるか否かをバッファ制御部１３１に問い合わせて判別する（ステップＳｂ３２）。
後述するようにバッファ１３５に格納された情報が送信部１４０によって端末装置２０に送信されて、当該端末装置２０が当該情報を受信すると、当該受信の確認を示す受領情報が当該端末装置２０から返信される。当該受領情報の返信を受けると、バッファ１３５に格納されていた情報が削除される構成となっているので、バッファ１３５に格納され続けている情報は、端末装置２０に送信する前の情報、または、当該端末装置２０に送信したものの、なんらかの理由によって当該端末装置２０が受信していない情報である。

いずれのバッファ１３５に情報が格納されていなければ（ステップＳｂ３２の判別結果が「Ｎｏ」であれば）、以降の処理が不要なので、処理手順はステップＳｂ３１に戻る。

一方、一定時間経過したときに、送信すべき情報がバッファ１３５に格納されているとき（ステップＳｂ３２の判別結果が「Ｙｅｓ」であるとき）、送信部１４０は、バッファ制御部１３１に対して当該情報の読み出しを指示して、当該情報の供給を受け、対応する端末装置２０に当該情報を送信する（ステップＳｂ３３）。

この後、送信部１４０は、送信先の端末装置２０から受領情報が返信された否かを判別する（ステップＳｂ３４）。送信先の端末装置２０から受領情報が返信されない事態としては、当該端末装置２０の電源が投入されていないことや、通信状態によって当該端末装置２０が当該情報を受信できなかったことなどが考えられる。このため、受領情報が返信されなかった場合（ステップＳｂ３４の判別結果が「Ｎｏ」である場合）、当該情報を再度送信すべく、処理手順がステップＳｂ３１に戻る。
一方、受領情報が返信された場合（ステップＳｂ３４の判別結果が「Ｙｅｓ」である場合、当該情報をバッファ１３５に格納する必要はなくなったので、送信部１４０は、バッファ制御部１３１に対して当該情報をバッファ１３５から削除するように依頼する（ステップＳｂ３５）。これにより、当該情報はバッファ１３５から削除される。
この後、処理手順がステップＳｂ３１に戻る。
したがって、バッファ処理では、端末装置２０に情報が送信されるとともに当該端末装置２０から受領情報を受け付けるまで、当該情報がバッファ１３５に格納され続ける。このため、当該情報を端末装置２０に確実に送信することができるとともに、メッセージ等の履歴を管理サーバ１０の側で記憶する必要がないので、その分、管理サーバ１０の処理負担を軽減することができる。

＜具体的動作＞
次に、メッセージの閲覧動作について具体的な例を用いて説明する。
図８においてグループＩＤが「ａｙ０１」であるグループメンバーが、自己の端末装置２０に対しメインメニュー画面で所定の操作をしたとき、図１５に示されるようなメッセンジャートップ画面が表示される（ステップＳａ１１）。この後、当該メンバーが、グループの名称が「三十路の館」に対応するボタン２５４の表示部分をタッチ操作すると、図１６に示されるようなメッセージ表示画面が表示される（ステップＳａ２３）。

ここで、当該メンバーが自己の端末装置２０において、メッセージ入力部２１１にメッセージを入力してボタン２７１を操作すると、処理手順が、図１１においてステップＳａ２３→Ｓａ２４→Ｓａ２５→Ｓａ２６→Ｓａ２３という経路を辿る。このときのステップＳａ２６において当該メッセージが当該端末装置２０に記憶されるとともに、管理サーバ１０に送信された後に、ステップＳａ２３においてメッセージが読み出されてメッセージ表示部２１２に表示される。

管理サーバ１０では、端末装置２０からメッセージを受け付けたとき、処理手順が、図１３においてステップＳｂ１１→Ｓｂ１２→Ｓｂ１３という経路を辿る。これにより、当該メッセージは、選択されたグループのメンバーのうち、当該メッセージの送信者以外のメンバーのバッファ１３５に格納される。
バッファ１３５にメッセージが格納されると、図１４において処理手順がやがてステップＳｂ３１→Ｓｂ３２→Ｓｂ３３という経路を辿るので、当該メッセージは、送信者以外のメンバーの端末装置２０に送信される。なお、送信したメンバーの端末装置２０から受領情報を受信すると、処理手順がステップＳｂ３４→Ｓｂ３５という経路を辿るので、当該メンバーに対応したバッファ１３５に格納された当該メッセージが削除される。また、送信したメンバーの端末装置２０から受領情報を受信しないとき、処理手順が再びステップＳｂ３１→Ｓｂ３２→Ｓｂ３３という経路を辿るので、当該メッセージの再送信がリトライされることになる。

メッセージの送信者以外のメンバーの端末装置２０において、管理サーバ１０からメッセージを受信すると、ステップＳａ２２の受信処理において、処理手順がステップＳａ４１→Ｓａ４２という経路を辿るので、当該メッセージが当該端末装置２０（のメモリ２０２）に格納される。この直後のステップＳａ２３においてメッセージが読み出されてメッセージ表示部２１２に表示される。

結局、メッセージの送信者の端末装置２０でも、当該送信者以外のメンバーの端末装置２０でも、管理サーバ１０を経るか否かの相違はあるものの、メッセージ表示部２１２には同じメッセージの内容が表示されることになる。
また、このようなメッセージの送信が繰り返されると、図１６に示されるように、メッセージを時系列的に例えば領域（１）から（５）まで配置したタイムライン表示となる。

図１６に示される例では、利用者ＩＤが「ｘｘ１３」のメッセージを表示する吹き出しにハッチングが付されている。このため、当該メッセージ表示画面は、利用者ＩＤが「ｘｘ１３」である端末装置２０の表示例であることが判る。また、他のメンバーの端末装置では、メッセージを表示する吹き出しのハッチングが自己のものに変更される以外、同様なものとなる。

この状態において、例えば現在時刻が午前７時００分となったことを契機として、ゲーム制御部１２３が、当該グループで進行しているゲームのステージ１において敵であるモンスターを出現させたとする。ゲーム制御部１２３は、ゲームの進行結果として、モンスターの画像と、この出現を示すメッセージとを作成するとともに、グループＩＤと作成者がシステムであることを示すシステムＩＤとを付して、管理部１２５を介して送信情報一時記憶部１３０に供給する。送信情報一時記憶部１３０のバッファ制御部１３１は、ゲームの進行結果を示す情報を、グループＩＤに対応するグループメンバー全員のバッファ１３５に格納する。
バッファ１３５に格納された情報は、バッファ処理によってメンバーの端末装置２０に送信される一方、端末装置２０においては、管理サーバ１０から当該情報が受信処理によって受信および記憶されるとともに、読み出されてメッセージ表示部２１２に表示される。
これにより、メッセージ表示画面は、図１７に示されるようなものとなる。すなわち、タイムライン表示において最新の領域（１）には、モンスターの画像とともに、当該モンスターの出現を示すメッセージとが上述したように画面左側で表示されるとともに、それまでタイムライン表示されていたメッセージは、１つずつ繰り下がる。
なお、本実施形態において、管理サーバ１０側で作成されるモンスター等の画像については、画面左側で表示されるので、相手となるグループメンバーと対向するように、例えば視線方向が右側になるように作成される。

ここで、利用者ＩＤが「ｘｘ１３」のメンバーが、図１８に示されるように、自己の端末装置２０においてメッセージ入力部２１１に「誰か、倒して！」というテキストを入力して、ボタン２７２の表示部分を操作した場合、上述した同様な処理手順を辿るので、当該端末装置２０においては図１９に示されるように、ハッチングありの吹き出しによって当該メッセージが表示される一方、他のメンバーの端末装置２０においては、特に図示しないが、ハッチングなしの吹き出しで当該メッセージが表示される。
換言すれば、ゲームの進行結果が表示されている場合であっても、各メンバーは、メッセージのみのチャットを継続することができる。

ここで、利用者ＩＤが「ｘｘ１８」の別のメンバーが、ゲームの進行を指示するために、端末装置２０においてボタン２７３を操作して、アイコン選択画面（図２５（ａ）参照）を表示させ、例えばアイコン情報が「ｙｙ０３」であるアイコンを選択したとする。このとき、処理手順が、ステップＳａ２４→Ｓａ２５→Ｓａ２８→Ｓａ２９→Ｓａ３０→Ｓａ３１という経路を辿るので、当該アイコン情報は、当該端末装置２０に記憶されるとともに、管理サーバ１０に送信される。
端末装置２０に記憶されたアイコン情報は、この後、ステップＳａ２３において読み出されて当該端末装置２０のメッセージ表示部２１２に表示される。

管理サーバ１０では、端末装置２０から送信されたアイコン情報を受け付けたとき、処理手順が、図１３において、ステップＳｂ１１→Ｓｂ１２→Ｓｂ１４→Ｓｂ１５という経路を辿るので、当該アイコン情報は、受付部１２１から管理部１２５を介し送信情報一時記憶部１３０に供給されて、送信者以外のメンバーのバッファ１３５に格納される。バッファ１３５にアイコン情報が格納されると、バッファ処理によって送信者以外のメンバーの端末装置２０に送信される。
なお、メッセージの送信者以外のメンバーの端末装置２０において、管理サーバ１０からアイコン情報を受信すると、ステップＳａ２２における受信処理において、処理手順がステップＳａ４１→Ｓａ４３→Ｓａ４４という経路を辿るので、当該アイコン情報が当該端末装置２０に記憶される。この直後のステップＳａ２３においてアイコン情報が読み出されてメッセージ表示部２１２に表示される。
このため、アイコン情報を選択したメンバー以外のメンバー、例えば利用者ＩＤが「ｘｘ１３」であるメンバーの端末装置２０では、図２０に示されるように、送信者が選択したアイコン情報に対応するアイコンが当該送信者を示すプロフィール画像等とともに表示されることになる。
アイコン情報を選択したメンバー、すなわち利用者ＩＤが「ｘｘ１８」であるメンバーの端末装置２０でも、吹き出しにハッチングが付されない点以外、図２０と同様な画面が表示されることになる。

管理サーバ１０では、処理手順が、引き続きステップＳｂ１６→Ｓｂ１７という経路を辿る。これにより、当該アイコン情報は、ゲーム制御部１２３にも供給されて、ゲームの進行の制御に用いられる。
ただし、ゲーム制御部１２３は、常にアイコン情報に応じてゲームの進行結果を生成するとは限られない。例えば、モンスターのダメージが当該アイコン情報に対応したゲーム命令（攻撃）によってゼロとならない場合、ゲーム制御部１２３は、ゲームの進行結果に対応する情報として何も出力しない。このため、ステップＳｂ１７においてはなんらデータがバッファ１３５に格納されず、実質的にスキップとなる。
したがって、この場合、図２０に示されるように、選択されたアイコンの表示にとどまり、ゲームの進行結果に対応した表示はされない。

次に、利用者ＩＤが「ｘｘ１２」のメンバーが、さらにゲームの進行を指示するために、アイコン情報が「ｙｙ０１」であるアイコン（図２５（ａ）参照）を選択したとする。このとき、処理手順が、同様な経路を辿るので、当該アイコン情報は、当該端末装置２０に記憶されるとともに、管理サーバ１０に送信される。端末装置２０に記憶されたアイコン情報は、この後、読み出されて当該端末装置２０のメッセージ表示部２１２に表示される。
管理サーバ１０では、端末装置２０から送信されたアイコン情報が受け付けられたとき、上述したように、当該アイコン情報は、受付部１２１から管理部１２５を介して送信情報一時記憶部１３０に供給され、送信者以外のメンバーのバッファ１３５に格納されて、バッファ処理によって送信者以外のメンバーの端末装置２０に送信される。
送信者以外のメンバーの端末装置２０において、管理サーバ１０からアイコン情報を受信すると、当該アイコン情報が当該端末装置２０に記憶され、読み出されてメッセージ表示部２１２に表示される。
このため、アイコン情報を選択したメンバー以外のメンバー、例えば利用者ＩＤが「ｘｘ１３」であるメンバーの端末装置２０では、図２１に示されるように、送信者が選択したアイコン情報に対応するアイコンが当該送信者を示すプロフィール画像等とともに表示されることになる。
アイコン情報を選択したメンバー、すなわち利用者ＩＤが「ｘｘ１２」であるメンバーの端末装置２０でも、吹き出しにハッチングが付されない点以外、図２１と同様な画面が表示されることになる。

本実施形態において、管理サーバ１０側で作成されるモンスター等の画像については、画面左側で表示される関係上、視線方向が右側になるように作成される。これに対応して、アイコンについては、当該モンスター等にあたかも攻撃を与えるように、攻撃方向が左側に向くように、あるいは、当該モンスター等から逃れる方向となるように、作成されている。この点については、上記アイコン選択画面で一覧表示されるアイコンについて共通である。

管理サーバ１０では、さらに処理手順がステップＳｂ１６→Ｓｂ１７という経路を辿る。これにより、当該アイコン情報がゲーム制御部１２３にも供給されて、ゲームの進行の制御に用いられる。ここで、モンスターのダメージが当該アイコン情報に対応したゲーム命令（攻撃）によってゼロとなったとき、ゲーム制御部１２３は、ゲームの進行結果に対応する情報、例えば当該モンスターが倒れた画像とともに、その旨のメッセージを出力する。
ゲームの進行結果に対応する情報は、管理部１２５を介して送信情報一時記憶部１３０に供給されて、メンバー全員のバッファ１３５に格納される。バッファ１３５にアイコン情報が格納されると、バッファ処理によってメンバー全員の端末装置２０に送信される。
端末装置２０において、管理サーバ１０からゲームの進行結果に対応する情報を受信すると、図１２の受信処理において、処理手順がステップＳａ４１→Ｓａ４３→Ｓａ４５→Ｓａ４６という経路を辿るので、当該情報が当該端末装置２０に記憶される。この直後のステップＳａ２３において当該情報が読み出されてメッセージ表示部２１２に表示される。このため、ゲームの進行結果に対応する情報を受信した端末装置２０では、図２２に示されるように、モンスターが倒れた画像とともに、その旨のメッセージが画面左側に配置されて表示されることになる。

なお仮に、当該モンスターを倒したことによって、ステージがクリアとなる場合、ゲーム制御部１２３は、ステップＳｂ１６において、ステージがクリアとなった旨や、次のステージの進行条件（金額）などを明示するメッセージを作成して、メンバー全員の端末装置に送信されるようにしても良い。
図２３は、このようなメッセージの一例である。なお、この例では、当該モンスターを倒すことによってステージ１がクリアとなったこと、および、次のステージ２の金額は１ドルであることが示されている。このため、クリアしたステージ番号や、次ステージの金額を代入する定型フォーマットを使用することができる。

また、これ以降の表示画面については図示を省略して、図２４のタイムラインで説明する。
図において、※１でステージ１がクリアとなった旨のメッセージとともに、次ステージの進行条件などを明示したメッセージを管理サーバ１０（システム）がメンバー全員の端末装置に送信し、これにより、当該メッセージが端末装置２０に表示される。この後に、※２に示されるように、メンバーの１人が、次のステージ２に進行するために所定の金額を支払って、当該ステージ２を購入する操作をしたとき、当該メンバーの端末装置２０では、処理手順がステップＳａ２４→Ｓａ２５→Ｓａ２８→Ｓａ３２→Ｓａ３３→Ｓａ３５という経路を辿る。これにより、ステージ２の購入指示が管理サーバ１０に送信される。
管理サーバ１０では、端末装置２０から当該ステージ２の購入指示を受け付けたとき、処理手順が、図１３においてステップＳｂ１１→Ｓｂ１２→Ｓｂ１４→Ｓｂ１８→Ｓｂ２１という経路を辿り、他の条件を満たしていれば、さらにステップＳｂ２２→Ｓｂ２３という経路を辿るので、ゲーム管理テーブルＴＢ３においてステージ２のステージフラグが使用不可から使用可能に変更される。
これにより、ゲームにおいて、購入が指示されたステージ２のプレイが許可される。

また、図２４において※１でステージ１がクリアになり、※２における金銭の支払によって、※３でステージ２が許可されると、図１０に示されるように、アイコン情報が「ｙｙ０５」、「ｙｙ０６」であるアイコンについても使用が可能になるはずである。この点について説明すると、ゲーム制御部１２３は、ステージ２のステージフラグが使用可能になったときに、アイコン情報が「ｙｙ０５」、「ｙｙ０６」であるアイコンフラグを使用可能に変更させる変更通知を、管理部１２５を介して送信情報一時記憶部１３０に供給する。これにより、当該変更通知は、メンバー全員のバッファ１３５に格納されて、バッファ処理によってメンバー全員の端末装置２０に送信される。
メンバーの端末装置２０において、管理サーバ１０から当該変更通知を受信すると、図１２の受信処理において、処理手順がステップＳａ４１→Ｓａ４３→Ｓａ４５→Ｓａ４７→Ｓａ４８という経路を辿るので、アイコン管理テーブルにおいて、アイコン情報が「ｙｙ０５」、「ｙｙ０６」であるアイコンフラグが使用不可から使用可能に変更される。この変更は、メンバー全員の端末装置２０にわたって実行される。したがって、メッセージ表示画面においてボタン２７３が操作されて、アイコン選択画面への移行が指示されたとき、それまで図２５（ａ）に示されるように「？」が付されて選択できなかったアイコンが、図２５（ｂ）に示されるように選択できるように表示される。これによってメンバー全員が当該アイコンを使用することができるようになる。

アイコンについては、ステージのクリアなどのゲームの進行のほかに、図１０に示されるように購入によって使用可能になるものもある。ここで、例えばステージ３がクリアされた状態で、アイコン情報が「ｙｙ０９」であるアイコンについて、メンバーの１人が購入を指示したとき、当該メンバーの端末装置２０では、処理手順がステップＳａ２４→Ｓａ２５→Ｓａ２８→Ｓａ３２→Ｓａ３３→Ｓａ３４という経路を辿る。これにより、当該アイコンの購入指示が管理サーバ１０に送信される。
管理サーバ１０において受付部１２１が端末装置２０から当該アイコンの購入指示を受け付けたとき、処理手順は、図１３においてステップＳｂ１１→Ｓｂ１２→Ｓｂ１４→Ｓｂ１８という経路を辿り、これにより、受付部１２１は、当該アイコンの購入指示をゲーム制御部１２３に供給する。
ゲーム制御部１２３は、他の条件を満たしていると判別すれば、さらに処理手順がステップＳｂ１９→Ｓｂ２０→Ｓｂ１７という経路を辿る。これにより、ゲーム制御部１２３は、購入指示のあったアイコンフラグを使用可能に変更させる変更通知を、管理部１２５を介して送信情報一時記憶部１３０に供給する。これにより、当該変更通知は、メンバー全員のバッファ１３５に格納されて、バッファ処理によってメンバー全員の端末装置２０に送信される。
メンバーの端末装置２０において、管理サーバ１０から当該変更通知を受信した以降の動作については同様であり、これによってメンバー全員が当該アイコンを使用することができるようになる。

アイコンについては、ゲームの進行や購入によって使用可能になるものがある一方で、図１０に示されるように使用回数に制限があるもの、すなわち使用回数が上限値に達したときに以降使用不可になるものがある。ここで、例えばステージ３がクリアされた状態で、アイコン情報が「ｙｙ０８」であるアイコンを、あるメンバーが選択したとき、当該メンバーの端末装置２０では、当該アイコン情報が管理サーバ１０に送信される点については上述した通りである。
管理サーバ１０では、端末装置２０から当該アイコン情報が受け付けられると、処理手順がステップＳｂ１１→Ｓｂ１２→Ｓｂ１４→Ｓｂ１５→Ｓｂ１６という経路を辿って、ゲーム制御部１２３が当該アイコン情報に応じてゲームの進行を制御する。
このとき、ゲーム制御部１２３は、例えばゲームの進行制御と並行して当該アイコン情報に対応した予め記憶した使用可能回数をダウンカウントするとともに、当該使用可能回数がゼロとなった時点で、当該アイコンフラグを使用不可とする変更通知を、管理部１２５を介して送信情報一時記憶部１３０に供給する。これにより、当該変更通知は、メンバー全員のバッファ１３５に格納されて、バッファ処理によってメンバー全員の端末装置２０に送信される。
メンバーの端末装置２０において、管理サーバ１０から当該変更通知を受信した以降の動作については同様であり、これによって各メンバーは当該アイコンを使用できなくなることになる。

本実施形態においては、管理サーバ１０側で作成されたゲームの進行結果に応じた結果の一例であるモンスター等の画像については、視線方向が右側である一方、当該モンスター等に攻撃を与えるアイコンについては、攻撃方向が左側に向くので、あたかも両者が戦っているように表示される。
このとき、メンバーが選択したアイコンについては、攻撃を与えるものであれば、同方向を向くので、メンバーが協力し合うかのような雰囲気を持たせることできる。

＜応用・変形例＞
本発明は、上述した実施形態に限定されるものではなく、例えば次に述べるような各種の応用・変形が可能である。なお、次に述べる応用・変形の態様は、任意に選択された一または複数を適宜に組み合わせることもできる。

＜アイコン＞
実施形態において、端末装置２０において、アイコン選択画面にてアイコンが選択されたとき、当該アイコンを識別する情報がアイコン情報として管理サーバ１０に送信されたが、アイコンそのものを示す画像をアイコン情報として送信する構成としても良い。この構成によれば、アイコンを識別する情報からアイコンを示す画像を取得する手間を省略することができる。

＜アイコンの追加＞
実施形態にあっては、当初から使用できるアイコンについては、アイコンフラグが使用可能に設定される一方、それ以外については使用不可に設定されて、以降、条件を満たしたときに、アイコンフラグを使用可能に変更する構成にしたが、条件を満たしたときに、アイコン情報を、管理サーバ１０からメンバーの端末装置２０に供給することによって、使用できるアイコンを逐次増加させても良い。

＜ＳＮＳ等＞
チャットやゲームが提供されるコミュニティの場を、ＳＮＳ（Social Networking Service）会員に限定する構成としても良い。すなわち、利用者は、予め登録したアカウントやパスワードを入力するなどのログイン等を経た上で、ＳＮＳのサービスとしてチャットやゲームをする構成としても良い。

＜アイコン画像とメッセージ＞
実施形態にあっては、ゲームの進行に関連するアイコンが選択されると、メンバー全員の端末装置２０のメッセージ表示部２１２に当該アイコンが表示される一方、メッセージが表示されない構成となっていたが、当該アイコンにメッセージを対応付けておき、当該アイコンが選択されたときに、当該アイコンとともに対応付けられたメッセージを表示する構成としても良い。
また、実施形態では、アイコンが選択されたときの当該アイコン情報の送信と、メッセージ入力部２１１に入力されたメッセージの送信とは互いに独立して実行する構成としたが、例えば選択されたアイコン情報を直ちに送信せず、ボタン２７２が操作されたときに、メッセージ入力部２１１に入力されたメッセージと、当該アイコン情報とを併せて送信して、メッセージ表示部２１２には、当該アイコンと当該メッセージとを併せて表示する構成としても良い。
一方、実施形態においては、あるメンバーにより入力されたメッセージや選択されたアイコン情報は、自己の端末装置２０のメモリ２０２に格納される一方で、他のメンバーの端末装置２０には管理サーバ１０を経由して送信された上でメモリ２０２に格納される構成となっていたが、自己のメッセージ等についても、管理サーバ１０を経由してメモリ２０２に格納する構成としても良い。

＜ウェブ型＞
実施形態においては、端末装置２０にインストールされたアプリケーションプログラムの実行によってメッセージの閲覧等を実行する、いわゆるネイティブ型の構成としたが、本発明は、この構成に限られない。例えば、管理サーバ１０側で表示の制御を記述したウェブ画面を作成して端末装置２０に送信する一方、端末装置２０側のブラウザがウェブ画面を表示するとともに、ウェブ画面（タッチパネル）に対する操作に応じた処理を実行するウェブ型の構成としても良い。

図２６は、ウェブ型とした応用例に係るシステム１の構成を示す機能ブロック図であって、メッセージ等の閲覧が実行される際に、管理サーバ１０および当該端末装置２０で構築される機能ブロックを示す図である。
端末装置２０では、表示の制御が記述されたウェブ画面を、表示パネル２１０におけるメッセージ表示部２１２に表示させるためのブラウザ２３４が構築される。
一方、管理サーバ１０側では、ある１つのグループに着目した場合、当該グループのメンバーから送信されたメッセージや、当該グループでのゲームの進行に応じた結果、メッセージ等の履歴を、データベース１１８の履歴記憶部ＴＢ４で記憶しておき、送信部１４０が、当該履歴に基づいて当該グループのメッセージやゲームの進行に応じた結果等についてタイムライン表示させたウェブ画面を作成して、当該グループのメンバーの端末装置２０に送信する構成となる。
送信部１４０は、実施形態では、受付部１２１で受け付けられたメッセージをグループメンバーのうち、当該メッセージを送信したメンバー以外のメンバーに送信する構成であったが、ウェブ型では、ウェブ画面を作成する関係上、送信者を含めたグループメンバーの全員に送信する構成となる。

＜ｐｕｓｈ型、ｐｕｌｌ型＞
実施形態や応用例にあっては、メッセージの送信やアイコンの選択がなされる毎に、当該メッセージやゲームの進行結果などがメンバーの端末装置２０に表示されるｐｕｓｈ型サービスとして説明したが、反対に、端末装置２０からの要求に応じて、自己に関連するグループのメッセージやゲームの進行結果などが管理サーバ１０から引き出されて表示されるｐｕｌｌ型サービスとした構成としても良い。

１…システム、１０…管理サーバ、２０…端末装置、１０１、２０１…ＣＰＵ、１１８…データベース、１２１…受付部、１２３…ゲーム制御部、１４０…送信部、２１２…メッセージ表示部、２３１…操作検出部、２３２…表示制御部。

Claims (7)

1. グループを構成する複数の利用者のそれぞれから送信されたメッセージを、それぞれの利用者の端末装置のメッセージ表示部にて閲覧可能に提供するメッセージ管理装置であって、
   予め定められたゲームの進行に関連する複数のアイコン情報のうち利用者から送信されたアイコン情報、または、利用者の入力に基づいた送信されたメッセージを受け付ける受付部と、
   利用者から送信されたアイコン情報に基づいてゲームを進行させるゲーム制御部と、
   前記受付部で受け付けられたメッセージを、前記複数の利用者のうち、少なくとも当該メッセージを送信した利用者以外の他の利用者に送信し、
   ゲームの進行に応じた結果またはメッセージを、前記複数の利用者のそれぞれに送信する送信部と、
   を備えることを特徴とするメッセージ管理装置。
2. 前記受付部は、前記複数のアイコン情報のうち前記利用者によって選択されたアイコンのアイコン情報を受け付け、
   前記ゲームが進行したときに、前記利用者が選択可能なアイコンが増加する
   ことを特徴とする請求項１に記載のメッセージ管理装置。
3. 前記ゲーム制御部は、
   前記ゲームを複数のステージで管理するとともに、一のステージにおいて所定の条件が充足されたときに、当該一のステージ以外のステージへの進行を許可する
   ことを特徴とする請求項１または２に記載のメッセージ管理装置。
4. 前記所定の条件には、対価の支払いが含まれる、
   ことを特徴とする請求項３に記載のメッセージ管理装置。
5. 前記送信部は、
   前記メッセージ表示部の一端側に前記複数の利用者のメッセージを、
   前記メッセージ表示部の他端側にゲームの進行に応じた結果またはメッセージを、
   それぞれ送信した時間の順で閲覧可能に提供する
   ことを特徴とする請求項１乃至４に記載のメッセージ管理装置。
6. グループを構成する複数の利用者のそれぞれから送信されたメッセージを、それぞれの利用者の端末装置の画面上のメッセージ表示部にて閲覧可能に提供するメッセージ管理方法であって、
   予め定められたゲームの進行に関連する複数のアイコン情報のうち利用者から送信されたアイコン情報、または、利用者の入力に基づいた送信されたメッセージを受け付けるステップと、
   利用者から送信されたアイコン情報に基づいてゲームを進行させるステップと、
   受け付けられたメッセージを、前記複数の利用者のうち、少なくとも当該メッセージを送信した利用者以外の他の利用者に送信する一方、ゲームの進行に応じた結果またはメッセージを、前記複数の利用者のそれぞれに送信するステップと、
   を備えることを特徴とするメッセージ管理方法。
7. グループを構成する複数の利用者のそれぞれから送信されたメッセージを、それぞれの利用者の端末装置の画面上のメッセージ表示部にて閲覧可能に提供するコンピュータに対し、
   予め定められたゲームの進行に関連する複数のアイコン情報のうち利用者から送信されたアイコン情報、または、利用者の入力に基づいた送信されたメッセージを受け付ける受付部、
   利用者から送信されたアイコン情報に基づいてゲームを進行させるゲーム制御部、および、
   前記受付部で受け付けられたメッセージを、前記複数の利用者のうち、少なくとも当該メッセージを送信した利用者以外の他の利用者に送信し、
   ゲームの進行に応じた結果またはメッセージを、前記複数の利用者のそれぞれに送信する送信部、
   として機能させることを特徴とするプログラム。

Images