JP2012018569A - プログラム、情報記憶媒体及びユーザ端末 - Google Patents

Abstract

【課題】フォローユーザの投稿の一覧の際に、単なるテキスト情報の表示という単調な表示以外の興趣性のある表示を実現すること。
【解決手段】ユーザ端末２０００では、フォローユーザそれぞれに対応付けたアバター２０を表示したフィールド画面Ｗ１が表示される。アバター２０には、投稿があることを示す吹き出し２２が付加表示されており、この吹き出し２２をタッチすることで、対応するフォローユーザの投稿の内容が表示される。また、アバター２０をタッチすることで、該アバター２０の編集を行うことができる。
【選択図】図８

Description

本発明は、サーバに投稿データを送信するユーザ端末等に関する。

ＳＮＳ（ソーシャル・ネットワーキング・サービス）や電子掲示板等では、物理的にユーザが同じ場所に集う必要がなく、好きな時に好きなところでユーザが自由に投稿することで、日記をつけたり、会話や議論ができるため、人気が高い（例えば特許文献１参照）。

特に、ＳＮＳの一種であるｍｉｘｉ（登録商標）では、お気に入りの友人をマイミクシーとして登録し、自分の日記を公開できる。また、ＴＷＩＴＴＥＲ（登録商標）と呼ばれるブログの一種のシステムでは、お気に入りのユーザをフォローユーザとして登録し、そのフォローユーザの投稿を時系列に表示させることができる。こういったお気に入りのユーザの投稿を把握する機能は利便性が高く、好んで利用されている。

特開２００７−９４５５１号公報

しかしながら、お気に入りのユーザが投稿した情報は、あくまでテキスト情報であり、そのテキスト情報が表示されるに過ぎなかった。本発明は、上述した課題を解決するためになされたものであり、その目的とするところは、単なるテキスト情報の表示という単調な表示以外の興趣性のある表示制御を実現することである。

以上の課題を解決するための第１の形態は、
ユーザ端末から投稿された投稿データを、ユーザ毎に投稿日時と対応付けて管理するとともに、ユーザ毎に登録されたフォローユーザを管理して、フォローユーザを登録したユーザのユーザ端末に、当該フォローユーザの投稿データを送信するサーバ（例えば、図１のサーバシステム１０００）と通信する通信装置を備えたユーザ端末（例えば、図１のユーザ端末２０００）となるコンピュータを、
複数のキャラクタ（例えば、図８のアバター２０）を記憶部に記憶させるキャラクタ記憶制御手段（例えば、図２４の登録アバターデータ７２０）、
各フォローユーザに対応するキャラクタを、前記記憶部に記憶されたキャラクタの中から選択設定するキャラクタ対応設定手段（例えば、図２４のフォローユーザ管理データ６４０）、
前記キャラクタ対応設定手段により対応設定されたキャラクタを所与の仮想空間に表示制御するキャラクタ表示制御手段（例えば、図２４のアバター表示制御部５１１；図３６のステップＢ９）、
として機能させるとともに、
前記キャラクタ表示制御手段が、前記サーバからフォローユーザの投稿データを受信した場合に、当該フォローユーザに対応付けられたキャラクタを識別表示する（例えば、図８の吹き出し２２の表示）識別表示手段（例えば、図３９のステップＤ７）を有するように前記コンピュータを機能させる、
ためのプログラムである。

また、他の形態として、
ユーザ端末から投稿された投稿データを、ユーザ毎に投稿日時と対応付けて管理するとともに、ユーザ毎に登録されたフォローユーザを管理して、フォローユーザを登録したユーザのユーザ端末に、当該フォローユーザの投稿データを送信するサーバと通信する通信装置を備えたユーザ端末（例えば、図１のユーザ端末２０００）であって、
複数のキャラクタを記憶部に記憶させるキャラクタ記憶制御手段と、
各フォローユーザに対応するキャラクタを、前記記憶部に記憶されたキャラクタの中から選択設定するキャラクタ対応設定手段と、
前記キャラクタ対応設定手段により対応設定されたキャラクタを所与の仮想空間に表示制御するキャラクタ表示制御手段と、
を備え、
前記キャラクタ表示制御手段は、前記サーバからフォローユーザの投稿データを受信した場合に、当該フォローユーザに対応付けられたキャラクタを識別表示する識別表示手段を有する、
ユーザ端末を構成することとしてもよい。

この第１の形態等によれば、各フォローユーザそれぞれにキャラクタを対応付けることができ、対応付けたキャラクタを表示制御することができる。そして、そのキャラクタは、対応づけられたフォローユーザの投稿データを受信した場合に識別表示される。従って、フォローユーザの投稿データを単にテキスト表示するといった従来の手法とは異なる興趣性に優れた表示制御を実現できる。

また、第２の形態として、第１の形態のプログラムにおいて、前記キャラクタ記憶制御手段が、ユーザの操作入力に従ってキャラクタの各部位を設計することでキャラクタを生成して前記記憶部に記憶させる第１のキャラクタ生成手段（例えば、図２４のアバター編集部５１２；図３６のステップＢ１７、図４１のステップＦ９〜１３、図４２のステップＦ３７〜Ｆ４１）を有する、ように前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第２の形態によれば、フォローユーザに対応付けるキャラクタを、ユーザが設計することができる。従って、例えば、ユーザがフォローユーザの容姿を知っている場合には、その容姿に似せたキャラクタを設計して、当該フォローユーザに対応付けることが可能となり、興趣性を一層向上させることができる。

さらに、第３の形態として、第２の形態のプログラムにおいて、前記第１のキャラクタ生成手段により生成されたキャラクタの設計データを、自ユーザの投稿データに含めて前記サーバに投稿する設計データ投稿手段（例えば、図２４の投稿実行部５１３；図３６のステップＢ２１図３７のステップＢ５３）として前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第３の形態によれば、キャラクタの設計データを投稿データに含めて投稿することができる。従って、自ユーザが設計したキャラクタを他人が利用することが可能となるため、例えば、有名人のキャラクタを設計して他ユーザに公開したり、自ユーザが自身のキャラクタを設計し、その設計データを、自身のことをフォローユーザとして登録している他ユーザに提供するといったことが可能となる。

また、第４の形態として、第１〜第３の何れかの形態において、前記サーバから受信したフォローユーザの投稿データに、キャラクタの設計データが含まれていることを検出する設計データ検出手段（例えば、図２４の投稿分析部５１４；図３８のステップＣ５〜Ｃ７）として前記コンピュータを機能させ、
前記キャラクタ記憶制御手段が、前記設計データ検出手段により検出された設計データに従ってキャラクタを生成して前記記憶部に記憶させる第２のキャラクタ生成手段（例えば、図２４の投稿分析部５１４；図３８のステップＣ９）を有するように前記コンピュータを機能させる、
ためのプログラムを構成することとしてもよい。

この第４の形態によれば、フォローユーザの投稿データにキャラクタの設計データが含まれている場合には、その設計データに従ったキャラクタを生成する。従って、フォローユーザが設計し、投稿したキャラクタと同じキャラクタを使用することが可能となる。

また、第５の形態として、第１〜第４の何れかの形態において、前記識別表示手段が、当該フォローユーザに対応付けられたキャラクタに、所与の付随表示体（例えば、図８の吹き出し２２）を付随させて表示制御することで前記識別表示を行う、ように前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第５の形態によれば、フォローユーザの投稿データを受信した場合に、当該フォローユーザに対応付けたキャラクタが識別表示されるが、その識別表示が所与の付随表示体の付随表示で行われる。付随表示体としては、例えば漫画の吹き出しのような表示体であったり、目に付く色や大きさのアイテム等が考えられる。何れの場合であっても、興趣性のある表示とすることができる。

また、第６の形態として、第１〜第５の何れかの形態において、前記キャラクタ表示制御手段により表示制御されたキャラクタの中から文書送信先のキャラクタを選択する送信先キャラクタ選択手段（例えば、図２４の投稿実行部５１３；図３６のステップＢ１１〜Ｂ１９）、
前記送信先キャラクタ選択手段により選択されたキャラクタに対応付けられたフォローユーザに向けて文書データを送信する文書送信手段（例えば、図２４の投稿実行部５１３；図３６のステップＢ２１）、
として前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第６の形態によれば、表示制御されているキャラクタを選択すると、そのキャラクタに対応付けられたフォローユーザに向けて文書データを送信することが可能となる。キャラクタには、対応付けられたフォローユーザの投稿データを受信したか否かの視覚的な報知としての役割があるが、その他の役割を持たせることができる。その役割は、投稿データを受信するという所謂プル型／受動型ではなく、文書データを送信するというプッシュ型／能動型の役割である。

また、第７の形態として、第１〜第６の何れかの形態において、前記キャラクタ表示制御手段が、前記サーバから受信した投稿データの内容、投稿日時及び投稿頻度のうちの少なくとも１つに基づいて、前記キャラクタの前記仮想空間中の配置位置を変更する配置位置変更手段（例えば、図２４のアバター表示制御部５１１；図３７のステップＢ６５）を有するように前記コンピュータを機能させる、ためのプログラムを構成することとしてもよい。

具体的には、例えば、第８の形態として、前記配置位置変更手段が、前記サーバから受信した投稿日時及び投稿頻度のうちの少なくとも１つに基づいて、前記仮想空間中のキャラクタを整列させる整列手段（例えば、図２４のアバター表示制御部５１１；図４４のステップＨ１〜Ｈ１１）を有するように前記コンピュータを機能させる、ためのプログラムを構成することとしてもよい。

この第８の形態によれば、受信した投稿日時及び投稿頻度に基づいてキャラクタが整列されるため、ユーザは、投稿日時及び投稿頻度を一目で、簡単に確認できる。

また、他の例としては、例えば、第９の形態として、前記配置位置変更手段が、前記サーバから受信した投稿データに所与のキーワードが含まれるか否かに基づいて、前記仮想空間中のキャラクタをグループ別に配置させるグループ配置手段（例えば、図２４のアバター表示制御部５１１；図４４のステップＨ１３〜Ｈ１７）を有するように前記コンピュータを機能させる、ためのプログラムを構成することとしてもよい。

この第９の形態によれば、投稿データに含まれるキーワードに応じて、キャラクタをグループ別に配置することができるため、各フォローユーザの投稿の傾向を、キャラクタを用いて一目で、簡単に把握することができる。

また、第１０の形態として、第１〜第９の何れかの形態において、前記サーバは、各ユーザについて、当該ユーザがフォローユーザとして登録されている数、当該ユーザが投稿した投稿データの内容、及び投稿数の何れかに基づいて、アイテム発生条件を満たしたか否かを判断する手段と、前記アイテム発生条件を満たしたユーザのユーザ端末に表示アイテムのデータを送信する手段とを備えており、
前記サーバから前記表示アイテムを受信する表示アイテム受信手段（例えば、図２４の無線通信部４２０）、
ユーザの操作入力に従って、前記記憶部に記憶されたキャラクタを、前記表示アイテム受信手段により受信された表示アイテムが付加した表示態様に更新するアイテム付加手段（例えば、図２４のアバター表示制御部５１１；図３９のステップＤ５）、
として前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第１０の形態によれば、当該ユーザがフォローユーザとして登録されている数、当該ユーザが投稿した投稿データの内容、及び投稿数の何れかがアイテム発生条件を満たした場合に、当該ユーザのユーザ端末に、キャラクタに付加表示可能な表示アイテムのデータが送信される。すなわち、ユーザにとってみれば、自身がフォローユーザとして登録されている数や自身の投稿データの内容、投稿数に応じて、キャラクタに付加表示可能なアイテムを取得でき、一層の興趣性のあるキャラクタ表示が可能となる。また、システム提供者側としては、投稿やフォローを活発化させ、システムの利用を促進させるという効果も期待できる。

また、第１１の形態として、第１〜第１０の何れかの形態において、前記サーバから受信したフォローユーザの投稿データに、画像データ又は当該画像データの所在を示す特定情報が含まれていることを検出する画像データ検出手段（例えば、図２４の投稿分析部５１４）として前記コンピュータを機能させ、
前記キャラクタ表示制御手段が、前記画像データ検出手段により検出されたフォローユーザに対応するキャラクタを、画像データが検出された旨を示す表示態様に変更する画像検出時態様変更手段（例えば、図２４のアバター表示制御部５１１）を有するように前記コンピュータを機能させる、
ためのプログラムを構成することとしてもよい。

この第１１の形態によれば、画像データ又は画像データの所在を示す特定情報を含めて投稿が可能となる。そして、受信したフォローユーザの投稿データに画像データ又はその所在を示す特定情報が含まれている場合には、当該フォローユーザに対応するキャラクタが所定の表示態様に変更される。このため、画像データ又はその所在を示す特定情報が含まれている投稿であれば、キャラクタを見れば一目で認識することが可能となる。

また、第１２の形態として、第１〜第１１の何れかの形態において、前記サーバから受信したフォローユーザの投稿データの内容を分析する投稿内容分析手段（例えば、図２４の投稿分析部５１４；図３６のステップＢ３）として前記コンピュータを機能させ、
前記キャラクタ表示制御手段が、前記投稿内容分析手段の分析結果に基づいて対応するキャラクタを動作制御する第１の動作制御手段（例えば、図２４のアバター表示制御部５１１）を有するように前記コンピュータを機能させる、
ためのプログラムを構成することとしてもよい。

この第１２の形態によれば、フォローユーザの投稿データの内容が分析され、その分析結果に基づいて、当該フォローユーザに対応付けられたキャラクタが動作制御される。従って、投稿データの内容に応じてキャラクタを多様に表示することができ、興趣性が一層向上する。

例えば、第１３の形態として、第１２の形態において、前記投稿内容分析手段が、前記サーバから受信したフォローユーザの投稿データに含まれる用語に基づいて、当該フォローユーザの当該用語の使用頻度及び／又は使用数を分析する用語分析手段（例えば、図２４の投稿分析部５１４；３８のステップＣ１１〜１３）を有し、
前記第１の動作制御手段が、前記用語分析手段の分析結果に基づいて、前記フォローユーザのキャラクタに予め定められた動作を行わせる（例えば、図２４のアバター表示制御部５１１）、
ように前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第１３の形態によれば、フォローユーザの投稿データに含まれる用語の使用頻度や使用数に応じてキャラクタの動作が変化することとなる。

また、第１４の形態として、第１２又は第１３の形態において、前記投稿内容分析手段が、移動及び／又は動作に係る指示コマンドが前記投稿データに含まれているか否かを判断する手段（例えば、図２４の投稿分析部５１４；図３８のステップＣ１５〜Ｃ１９）を有し、
前記第１の動作制御手段が、前記投稿内容分析手段によって前記指示コマンドが含まれていると判断された場合に、当該指示コマンドに従って、対応するキャラクタを前記仮想空間中で移動及び／又は動作させる（例えば、図２４のアバター表示制御部５１１；図３９のステップＤ１３）、
ように前記コンピュータを機能させるためのプログラムを構成することとしてもよい。

この第１４の形態によれば、移動や動作を指示する指示コマンドが投稿データに含まれている場合には、対応するキャラクタがその指示コマンドに従って移動／動作することとなる。そのため、フォローユーザの投稿データを受信するだけで、対応するキャラクタが移動／動作するという興趣溢れる表示制御を実現できる。

また、第１５の形態として、第１〜第１４の何れかの形態において、前記サーバから受信したフォローユーザの投稿データに、他人の投稿に関連する投稿であることを示す関連投稿データが含まれていることを検出する関連投稿検出手段（例えば、図２４の投稿分析部５１４）、
各フォローユーザそれぞれ間の親密度を、前記関連投稿検出手段の検出結果に基づいて設定する親密度設定手段、
として前記コンピュータを機能させるとともに、
前記キャラクタ表示制御手段が、フォローユーザ同士の前記親密度が所定条件を満たしたフォローユーザそれぞれに対応するキャラクタに、予め定められた動作を行わせる第２の動作制御手段を有するように前記コンピュータを機能させる、
ためのプログラムを構成することとしてもよい。

この第１５の形態によれば、投稿データに他人の登録に関連する投稿であることを示す関連投稿データが含まれているか否かに応じて、各フォローユーザ間の親密度が設定される。そして、親密度が所定条件を満たしたフォローユーザに対応するキャラクタは、所定の動作を行うように制御される。従って、例えば、親密度が最も高い２人のキャラクタ同士を隣接するように移動制御させて手をつなぐように動作制御するといった興趣性のある表示制御を、投稿データを受信するだけで実現できる。

また、第１６の形態として、第１〜第１５の何れかの形態のプログラムを記憶したコンピュータ読取可能な情報記憶媒体（例えば、図２４の記憶部６００）を構成することとしてもよいことは勿論である。

「情報記憶媒体」とは、例えば磁気ディスクや光学ディスク、ＩＣメモリなどを含む。第１６の形態によれば、第１〜第１５の何れかの形態のプログラムをコンピュータに読み取らせて実行させることによって、コンピュータに第１〜第１５の形態と同様の効果を発揮させることができる。

メッセージ投稿システムの構成図。 ユーザ端末の外観例。 新規投稿の説明図。 指定投稿の説明図。 引用投稿の説明図。 投稿フォーマットの説明図。 他ユーザのフォローの説明図。 フィールド画面の一例。 フィールド画面の生成原理の説明図。 投稿詳細画面の一例。 アバターをタッチしたときのフィールド画面の一例。 アバターエディット画面の一例。 投稿画面の一例。 アバターボタンをタッチしたときのフィールド画面の一例。 メイン画面の一例。 更新ボタンをタッチしたときのフィールド画面の一例。 フォローユーザ一覧画面の一例。 整列ボタンをタッチしたときのフィールド画面の一例。 フィールドにおけるアバターの整列の説明図。 アバターにアイテムを付加したときのフィールド画面の一例。 アバターがモーションを行っているフィールド画面の一例。 サーバシステムの機能構成図。 アカウント登録データのデータ構成例。 ユーザ端末の機能構成図。 フォローユーザ管理データのデータ構成例。 アイテムテーブルのデータ構成例。 指示コマンドテーブルのデータ構成例。 アバター配置データのデータ構成例。 登録アバターデータのデータ構成例。 アバターパーツテーブルのデータ構成例。 投稿フォーマットの説明図。 自ユーザ投稿分析結果データのデータ構成例。 投稿分析結果データのデータ構成例。 アイテム発生条件テーブルのデータ構成例。 サーバシステムにおける投稿管理処理のフローチャート。 ユーザ端末におけるメッセージ投稿処理のフローチャート。 図３６のフローチャートの続き。 投稿分析処理のフローチャート。 フィールド表示処理のフローチャート。 アバター修正処理のフローチャート。 アバター処理のフローチャート。 図４１のフローチャートの続き。 フィールド更新処理のフローチャート。 アバター整列処理のフローチャート。 定期更新処理のフローチャート。 画像有りのときのフィールド画面の一例。

以下、図面を参照して、本発明の実施形態を説明する。なお、以下では、本発明の実施例として、ユーザ端末からメッセージを投稿するメッセージ投稿システムを説明する。

［システム構成］
図１は、本実施形態におけるメッセージ投稿システム１の概略構成図である。図１によれば、メッセージ投稿システム１は、サーバシステム１０００と、ユーザ端末２０００とが、通信回線Ｎを介してデータ送受信可能に接続されて構成されている。通信回線Ｎは、データ送受信が可能な通信路であり、インターネットやローカルネットワーク（ＬＡＮ）、専用回線網、その他の回線網、及び、通信を仲介する中継装置等で構成される。

サーバシステム１０００は、メッセージ投稿システム１の運営会社側に設置・管理され、公知のサーバコンピュータシステムを用いて構成される。サーバシステム１０００は、主に、（１）メッセージ投稿サービスに関するアカウントを管理する管理サーバとして機能するとともに、（２）メッセージ投稿サービスを提供するためのウェブサイトをインターネット上に公開・管理するウェブサイトサーバとして機能する。

ユーザ端末２０００は、ユーザに所有され、例えば、携帯電話機（スマートフォンを含む）、パソコン、ＵＭＰＣ（Ultra-Mobile Personal Computer）、ＰＤＡ（Personal Digital Assistant）等の電子機器で実現される。また、ユーザ端末２０００は、ウェブブラウザ機能を有し、通信回線Ｎに接続することで、サーバシステム１０００によって管理されているウェブサイトの閲覧が可能である。

図２は、ユーザ端末２０００の一例である携帯電話機の外観図である。図２に示すように、この携帯電話機は、手のひらに載る程度の大きさの筐体に、通話用のスピーカ２００２及びマイクロフォン２００４と、ダイヤル番号等の入力に使用する操作キー２００６と、液晶ディスプレイ２００８とを備えて構成される。液晶ディスプレイ２００８の表面には、その表示面全体に亘って、指などによるタッチ位置を検出するタッチパネル２０１０が装着されている。

また、ユーザ端末２０００の筐体内には、制御装置２０１２と、着脱自在なメモリカード２０２０に対してデータの読み出し／書き込みが可能なメモリカード読取装置２０１４とを内蔵している。

制御装置２０１２は、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ(Application Specific Integrated Circuit)、ＶＲＡＭやＲＡＭ、ＲＯＭ等の各種ＩＣメモリを搭載する。また、制御装置２０１２には、通信回線Ｎに接続して無線通信を実現する無線通信装置や、液晶ディスプレイ２００８のドライバ回路、タッチパネル２０１０のドライバ回路、操作キー２００６からの信号を受信する回路、スピーカ２００２へ音声信号を出力するためのアンプ回路、メモリカード読取装置２０１４への信号入出力回路といった所謂Ｉ／Ｆ回路（インターフェース回路）を搭載する。制御装置２０１２に搭載されている各装置は、それぞれバス回路を介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

［概要１］
メッセージ投稿システム１では、「メッセージ投稿サービス」が提供される。このメッセージ投稿サービスは、いわゆるブログサービスに類似したサービスであり、ウェブサイトにメッセージを投稿して公開したり、公開されている他ユーザの投稿メッセージを閲覧したりといったことができる。ユーザは、ユーザ端末２０００を介して、サーバシステム１０００が管理する所定のウェブサイトにアクセスすることで、サーバシステム１０００によって提供されるメッセージ投稿サービスを利用することができる。

具体的には、ユーザは、先ず、ユーザ端末２０００を介してサーバシステム１０００に登録しアカウントを取得する必要がある。すると、サーバシステム１０００によって、自分専用の「ホームページ（マイページ）」が割り当てられる。ユーザは、このマイページにおいてメッセージを投稿したり、他のユーザが投稿したメッセージを閲覧したりすることができる。マイページには、自分が投稿したメッセージや、「フォロー」している他のユーザが投稿したメッセージが、時系列に一覧表示される。なお、本実施形態のメッセージ投稿サービスにおいて投稿できるメッセージは、テキストのみである。

また、メッセージの投稿には、「新規投稿」、「指定投稿」及び「引用投稿」の３種類がある。

図３は、「新規投稿」の概要を示す図である。新規投稿では、ユーザがメッセージを投稿すると、マイページ２にその投稿４が表示される。図３は、ユーザＡがメッセージを新規投稿した場合であり、ユーザＡのマイページ２Ａに、その投稿４ａが表示される。他のユーザＢは、ユーザＡの投稿４ａを閲覧することができる。なお、マイページ２において、投稿４は、文頭に投稿したユーザ名が表示され、これに続けてメッセージが表示される。

図４は、「指定投稿」の概要を示す図である。指定投稿は、宛先を指定した投稿である。ユーザが宛先のユーザを指定して投稿すると、自分のマイページ２にその投稿４が表示されるとともに、宛先のユーザのマイページ２にも、同じ投稿４が表示される。図４は、ユーザＡがユーザＣを宛先として指定投稿した場合である。この場合、ユーザＡのマイページ２Ａにその投稿４ａが表示されるとともに、宛先であるユーザＣのマイページ２Ｃにも、同じ投稿４ａが表示される。また、指定投稿では、メッセージの先頭に宛先のユーザ名が付加される。このとき、宛先のユーザ名には、指定投稿であることを示す所定の識別子６ａ（図４では、記号「＠」）が付加される。

図５は、「引用投稿」の概要を示す図である。引用投稿は、他のユーザ、或いは、自分の投稿を引用した投稿（他ユーザの投稿に関連した投稿）である。過去の投稿を引用して投稿すると、自分のマイページ２にその投稿４が表示されるとともに、投稿の引用元のユーザのマイページ２にも、同じ投稿４が表示される。図５は、ユーザＢが、ユーザＡの投稿を引用して投稿した場合である。すなわち、図５（ａ）では、ユーザＡのマイページ２Ａに、ユーザＡの投稿４ａが表示されている。次いで、図５（ｂ）に示すように、ユーザＢが、ユーザＡの投稿４ａを引用して投稿する。すると、ユーザＢのマイページ２Ｂには、ユーザＢの投稿４ｃが表示されるとともに、引用元のユーザＡのマイページ２Ａにも、同じ投稿４ｃが表示される。引用投稿では、引用した投稿の先頭に、引用投稿であることを示す所定の識別子６ｂ（図５（ｂ）では、テキスト「ＲＴ」）が付加される。また、引用した投稿に、自分のメッセージを追加して投稿することができる。

図６は、上記３種類の投稿メッセージのフォーマットを示す図である。図６（ａ）は、「新規投稿」のフォーマットを示し、図６（ｂ）は、「指定投稿」のフォーマットを示し、図６（ｃ）は、「引用投稿」のフォーマットを示している。なお、投稿メッセージは、テキストデータである。

図６（ａ）に示すように、「新規投稿」では、自ユーザによって入力されたメッセージ８のみで構成される。

また、図６（ｂ）に示すように、「指定投稿」では、先頭に、指定投稿であることを示す所定の識別子６ａ「図６（ｂ）では、記号「＠」」に続けて、宛先のユーザ名が入る。そして、１文字の空白をおいて、自ユーザによって入力されたメッセージ８が続く。

また、図６（ｃ）に示すように、「引用投稿」では、自ユーザによって入力されたメッセージ８、引用投稿であることを示す所定の識別子６ｂ（図６（ｃ）では、テキスト「ＲＴ」）、そして、引用元のメッセージ９の順となる。この識別子６ｂの前後には、それぞれ、１文字の空白が入る。

また、本実施形態のメッセージ投稿サービスでは、他のユーザを登録する「フォロー」の機能を有する。他のユーザをフォローすると、そのフォローしたユーザの投稿が、自分のマイページに表示される。図７は、フォローの一例を示す図である。図７では、ユーザＢがユーザＡをフォローしている。この場合、ユーザＡが投稿すると、その投稿４ａがユーザＡのマイページ２Ａに表示されるとともに、ユーザＡをフォローしているユーザＢのマイページ２Ｂにも、同じ投稿４ａが表示される。

［概要２］
続いて、ユーザ端末２０００における操作の流れを、液晶ディスプレイ２００８の表示画面を参照して説明する。なお、ユーザ端末２０００における操作は、表示画面におけるタッチ操作によってなされる。

ユーザは、先ず、ユーザ端末２０００から所定のウェブサイトにアクセスし、表示されるログイン画面において、ユーザＩＤやパスワード等を入力してログインする。すると、図８に示すようなフィールド画面Ｗ１が表示される。

図８は、フィールド画面Ｗ１の一例を示す図である。図８に示すように、フィールド画面Ｗ１には、自分のフォローユーザそれぞれに対応付けて設定したキャラクタであるアバター２０が表示される。

このアバター２０は、基本パーツ（部位）である胴体及び頭で構成される初期アバターに、目や鼻、口、髪型といった各種のパーツ（部位）を付加することで作成される。各パーツは複数種類用意されており、これらを自由に選択して組み合わせることで、外観が異なる様々なアバター２０を作成することができるようになっている。

アバター２０には、対応するフォローユーザの投稿を示す吹き出し２２が付加表示される。この吹き出し２２は、過去の所定期間（例えば、１日間）の間に、該吹き出し２２が付加されたアバター２０に対応するフォローユーザによる投稿が有る場合に表示される。なお、吹き出し２２は、対応するフォローユーザの未読の投稿データが有る場合に、表示することにしても良い。

更に、各アバター２０に対応するフォローユーザのうち、最新の投稿を行ったフォローユーザに対応するアバター２０が拡大表示されているとともに、その吹き出し２２が拡大表示され、該フォローユーザの最新の投稿の一部（例えば、文頭３０文字）がテキスト表示される。それ以外の吹き出し２２については、投稿が省略表示（図８では、テキスト「・・・」）される。

フィールド画面Ｗ１には、図９に示すように、キャラクタであるアバター２０が配置された仮想二次元空間であるフィールド９０のうち、所定の大きさ（図９では、フィールド全体の約１／３）の表示範囲９２に該当する部分が表示される。フィールド画面Ｗ１に表示されていないフィールド部分を見るには、フィールド画面Ｗ１の左右端に表示されたスクロールカーソル２４をタッチすることで、左右方向にスクロール表示させることができる。

また、フィールド画面Ｗ１において、吹き出し２２をタッチすると、タッチした吹き出し２２のアバター２０に対応するフォローユーザの最新の投稿を表示した投稿詳細画面Ｗ２に表示が切り替わる。

図１０は、投稿詳細画面Ｗ２の一例を示す図である。図１０に示すように、投稿詳細画面Ｗ２には、該当する１つの投稿について、投稿したユーザ名に続けて、その投稿の全文４３が表示される。

また、フィールド画面Ｗ１において、アバター２０をタッチすると、図１１に示すように、タッチしたアバター２０についてのアバターメニュー２６がポップアップ表示される。アバターメニュー２６には、アバターエディット画面Ｗ３を表示して該アバター２０を修正する「アバター修正」と、対応するフォローユーザに対して指定投稿を行う「指定投稿」と、該アバター２０のモーションを停止させる「モーション停止」とが表示されている。このアバターメニュー２６において、「アバター修正」をタッチすると、該アバター２０の修正を行うためのアバターエディット画面Ｗ３に表示が切り替わる。

図１２は、アバターエディット画面Ｗ３の一例を示す図である。図１２に示すように、アバターエディット画面Ｗ３には、エディット対象のアバター２０が表示される。また、基本パーツ、及び、アバター２０に付加できるパーツの種別の一覧であるパーツ種別一覧５１が表示されているとともに、このパーツ種別一覧５１で選択されているパーツの候補の一覧であるパーツ候補一覧５２が表示されている。 図１２では、パーツ種別として「メガネ」が選択されており、様々な形状の「メガネ」の候補が一覧表示されている。また、パーツを調整するツールとして、パーツの色を変更するカラーパレット５３と、パーツの位置を上／下／左／右に移動させる十字キー５４と、パーツを右／左に回転させる回転ツール５５とが表示されている。更に、エディット対象のアバターに関する情報として、該アバター２０が設定されているフォローユーザのユーザ名５６と、該アバター２０を作成したユーザ名５７とが表示されている。

このアバターエディット画面において、ユーザは、各パーツを変更したり、各パーツの位置や向き、色を調整したりといった、アバター２０の修正を行うことができる。そして、アバター２０の修正が終了し、登録ボタン５９をタッチすると、修正前のアバター２０が、修正後のアバター２０に更新登録されるとともに、該アバター２０の作成者が自分に更新される。

また、アバターメニュー２６において、「指定投稿」をタッチすると、該アバター２０に対応するフォローユーザへの指定投稿を行うための投稿画面Ｗ４が表示される、

図１３は、投稿画面Ｗ４の一例を示す図である。図１３に示すように、投稿画面Ｗ４には、メッセージを入力するための入力エリア４７が表示される。指定投稿であるので、入力エリア４７には、既に、識別子６ａ「＠」を付加した宛先のユーザ名が入力されている。ここでは、フィールド画面Ｗ１においてタッチしたアバター２０に対応するフォローユーザ名が、宛先のユーザ名として入力されている。ユーザは、このユーザ名に続けて、メッセージをテキスト入力する。そして、メッセージの入力を終了し、投稿ボタン４８をタッチすると、入力したメッセージ（文書データ）が投稿され、指定した宛先のユーザへと送信される。

また、フィールド画面Ｗ１（図８参照）の上部及び下部には、各種機能の実行が割り当てられた複数の機能ボタンが表示されている。具体的には、機能ボタンとして、アバターボタン３１と、投稿ボタン３２と、メインボタン３３と、更新ボタン３４と、フォローボタン３５と、アイテムボタン３６と、整列ボタン３７とが表示されている。

アバターボタン３１をタッチすると、図１４に示すように、アバターに関する操作メニューである「アバターメニュー２８」がポップアップ表示される。このアバターメニュー２８には、アバターの新規作成や、登録されているアバターの２０修正を行う「アバターの編集」と、フィールドにおけるアバター２０の配置位置を変更する「アバターの位置変更」と、アバター２０を配置するフォローユーザを変更する「配置アバターの変更」とが表示されている。

アバターメニュー２８において、「アバターの編集」をタッチすると、続いて、アバターの編集方法として、アバターを新たに作成する「新規作成」と、登録されているアバターを修正する「修正」とが提示されるので、何れかを選択する。そして、「新規作成」を選択した場合には、予め用意された初期アバターをエディット対象としたアバターエディット画面Ｗ３（図１２参照）に表示が切り替わる。一方、「修正」を選択した場合には、続いて、登録されているアバターが一覧表示されるので、これらのうちから、修正したい登録アバターを選択する。すると、選択したアバターをエディット対象としたアバターエディット画面Ｗ３（図１２参照）に表示が切り替わる。

また、アバターメニュー２８において、「アバターの位置変更」を選択すると、フィールド画面Ｗ１におけるアバター２０の位置変更操作が有効となるので、移動させたいアバター２０をタッチしスライドさせることで、所望の位置まで移動させる。

また、アバターメニュー２８において、「配置アバターの変更」を選択すると、自分のフォローユーザが一覧表示される。各フォローユーザには、対応するアバター２０がフィールドに配置されている／配置されていないを示す所定のマークが付加されるので、これを参考にしながら、フィールドにアバター２０を配置したいフォローユーザの再選択を行う。なお、フィールドに配置できるアバター２０の数には上限（例えば、３０体）があり、この上限数を超えないように選択する。

また、フィールド画面Ｗ１において、投稿ボタン３２をタッチすると、「新規投稿」を行うための投稿画面Ｗ４（図１３参照）が表示されて、新規投稿を行うことができる。

また、フィールド画面Ｗ１において、メインボタン３３をタッチすると、自分のメイン画面Ｗ５に表示が切り替わる。

図１５は、メイン画面Ｗ５の一例を示す図である。図１５に示すように、メイン画面Ｗ５には、自分のユーザ名６１やユーザ画像６２、フォローユーザの数６３、被フォローユーザの数６４、これまでの投稿数６５が表示されるとともに、また、自分の投稿及びフォローユーザそれぞれの投稿を、投稿日時の最新順に並べた投稿一覧６６が表示される。この投稿一覧６６のうちから、何れかの投稿をタッチすると、タッチした投稿についての投稿詳細画面Ｗ２（図１０参照）に表示が切り替わる。また、メイン画面Ｗ５には投稿ボタン６７が表示されており、この投稿ボタン６７をタッチすると、投稿画面Ｗ４（図１３参照）が表示されて、新規投稿を行うことができる。

また、フィールド画面Ｗ１において、更新ボタン３４をタッチすると、図１６に示すように、各フォローユーザの最新の投稿に基づいて、フィールド画面Ｗ１の表示が更新される。

また、フィールド画面Ｗ１において、フォローボタン３５をタッチすると、自分のフォローユーザを一覧表示したフォローユーザ一覧画面Ｗ６に表示が切り替わる。

図１７は、フォローユーザ一覧画面Ｗ６の一例を示す図である。図１７に示すように、フォローユーザ一覧画面Ｗ６には、自分のユーザ名７１やユーザ画像７２とともに、自分のフォローユーザを並べたフォローユーザ一覧７３が表示される。フォローユーザ一覧７３における各フォローユーザには、該フォローユーザのユーザ名７４やユーザ画像７５、該フォローユーザに設定したアバター画像７６が表示される。フォローユーザ一覧７３において、何れかのフォローユーザをタッチすると、タッチしたフォローユーザの投稿一覧画面が表示される。

また、フィールド画面Ｗ１において、整列ボタン３７をタッチすると、図１８に示すように、アバター２０が所定の整列規則に従って整列する。

ところで、フィールド画面Ｗ１には、図９に示したように、フィールド９０の一部分のみが表示される。つまり、整列ボタン３７をタッチすると、図１９に示すように、フィールド９０において、配置されている全てのアバター２０が、所定の整列規則に従って整列される。そして、フィールド９０のうち、表示範囲９２に相当する部分の様子が、図１８に示すように、フィールド画面Ｗ１として表示される。

整列規則としては、フォローユーザの最新投稿日時、投稿数（或いは、単位期間当たりの投稿数である投稿頻度としても良い）、及び、投稿の内容があり、ユーザが選択できる。すなわち、整列規則として「最新投稿日時」を選択すると、フィールド９０において、配置されているアバター２０が、対応するフォローユーザの最新投稿日時が早い／遅い順に、整列される。また、整列規則として「投稿数」を選択すると、フィールド９０において、配置されているアバター２０が、対応するフォローユーザの投稿数が多い／少ない順に、整列される。また、整列規則として「投稿の内容」を選択すると、フィールド９０において配置されているアバター２０が、対応するフォローユーザの投稿に含まれる所定のグループ分け用のキーワードが同じアバター２０同士、或いは、同じカテゴリに属するキーワードが含まれるアバター２０同士をグループとしてグループ分けされ、グループ毎に整列される。

また、フィールド画面Ｗ１において、アイテムボタン３６をタッチすると、アバター２０に付加することができるアイテムが一覧表示される。この一覧表示されるアイテムのうちから、所望のアイテムを選択し、次いで、フォローユーザを選択することで、図２０に示すように、該選択したフォローユーザに対応するアバター２０に、該選択したアイテムを付加して表示させることができる。

図２０は、アバター２０にアイテム８０を付加したフィールド画面Ｗ１の一例である。アイテムは、自分の投稿が所定のアイテム発生条件を満たしたときに、該満たしたアイテム条件に定められたアイテムが取得される。アイテム発生条件としては、具体的には、自分の投稿に含まれる所定のキーワードや、自分のフォローユーザの数、被フォローユーザの数などである。

また、図２１に示すように、フィールド画面Ｗ１において、アバター２０が「モーション」を行うことがある。図２１は、アバター２０がモーションを行っているフィールド画面Ｗ１の一例である。アバター２０のモーションは、対応するフォローユーザの投稿の内容によって行われる。具体的には、フォローユーザの投稿に所定の「指示コマンド」が含まれていた場合、該指示コマンドに対応するモーションを行う。アバター２０のモーションは、該アバター２０をタッチしたときに表示されるアバターメニュー２６（図１１参照）の「モーション停止」をタッチすることで、停止させることができる。なお、本実施形態において、このモーションは、その場で行う動作であり位置の変化（移動）は伴わないが、移動を伴うことにしても良い。

［構成］
（Ａ）サーバシステム１０００
図２２は、サーバシステム１０００の機能構成図である。図２２によれば、サーバシステム１０００は、機能的には、操作入力部１１０と、サーバ処理部２００と、通信部１２０と、画像表示部１３０と、サーバ記憶部３００とを備えて構成される。

操作入力部１１０は、サーバシステム１０００の管理者による操作入力を受け付け、操作に応じた操作信号をサーバ処理部２００に出力する。この機能は、キーボードやタッチパッド、トラックボールなどによって実現される。

サーバ処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１１０やサーバ記憶部３００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１１０からの操作入力信号に基づいて各種の演算処理を実行して、サーバシステム１０００の動作を統合的に制御する。また、本実施形態では、サーバ処理部２００は、投稿管理部２１０を含む。

投稿管理部２１０は、ユーザ端末２０００における「メッセージ投稿サービス」の実施を管理する。具体的には、ユーザ端末２０００からの要求に応じて、新規にアカウントを登録する。登録されているアカウントに関するデータは、アカウント登録データ３３０として記憶される。

図２３は、アカウント登録データ３３０のデータ構成の一例を示す図である。アカウント登録データ３３０は、アカウント登録したユーザ毎に生成され、対応するユーザのユーザＩＤ３３１と、ユーザ名３３２と、プロフィールデータ３３３と、フォローユーザリスト３３４と、被フォローユーザリスト３３５と、投稿数３３６と、投稿データ３３７と、受信投稿データ３３８とを格納している。

投稿データ３３７は、該ユーザの過去の投稿についてのデータであり、投稿ＩＤ３３７ａと、投稿日時３３７ｂと、メッセージテキスト３３７ｃとを含んでいる。また、受信投稿データ３３８は、該ユーザを宛先とした指定投稿についてのデータであり、投稿ＩＤ３３８ａと、投稿日時３３８ｂと、投稿ユーザＩＤ３３８ｃと、メッセージテキスト３３８ｄとを含んでいる。

また、投稿管理部２１０は、ユーザ端末２０００からアカウント認証を要求されると、アカウント登録データ３３０を参照して、受信したアカウント情報を登録されているアカウント情報と照合して認証する。そして、認証したユーザ端末２０００からユーザデータを要求されると、該要求とともに受信されたアカウント情報に基づき、アカウント登録データ３３０を参照してユーザを特定する。

次いで、特定したユーザ（自ユーザ）のアカウント登録データ３３０を参照して、ユーザ名やフォローユーザリスト、被フォローユーザリスト、投稿数、最新の所定数の投稿データ、最新の所定数の受信投稿データ等を含むユーザデータを、自ユーザデータとして生成する。また、自ユーザのアカウント登録データ３３０を参照して、フォローユーザを特定する。次いで、特定したフォローユーザそれそれぞれについても同様に、該当するアカウント登録データ３３０を参照して、ユーザ名やフォローユーザリスト、被フォローユーザリスト、投稿数、最新の所定数の投稿データ、最新の所定数の受信投稿データ等を含むユーザデータを、フォローユーザデータとして生成する。そして、生成した自ユーザデータ、及び、各フォローユーザデータを、該ユーザ端末２０００に送信する。

また、ユーザ端末２０００から送信された投稿データを受信すると、該投稿データとともに受信されたアカウント情報に基づき、送信元のユーザを特定する。そして、特定したユーザの投稿データに追加する。また、該投稿が「指定投稿」ならば、宛先のユーザ名を特定し、該特定した宛先のユーザの受信投稿データに追加する。

通信部１２０は、通信回線Ｎと接続して外部装置（主に、ユーザ端末２０００）と通信を実現する。この機能は、例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。

画像表示部１３０は、サーバ処理部２００からの画像信号に基づいて、投稿管理のための各種画像を表示する。この機能は、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現される。

サーバ記憶部３００は、サーバシステム１０００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００の作業領域として用いられ、サーバ処理部２００が各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。本実施形態では、サーバ記憶部３００は、プログラムとして、サーバシステムプログラム３１０と、投稿管理プログラム３２０とが記憶されるとともに、データとして、アカウント登録データ３３０が記憶される。

サーバシステムプログラム３１０は、サーバ処理部２００が実行することで、サーバシステム１０００に必要な基本的な入出力機能を実現するためのシステムプログラムである。投稿管理プログラム３２０は、サーバ処理部２００が実行することで、投稿管理部２１０としての機能を実現させるためのプログラムである。

（Ｂ）ユーザ端末２０００
図２４は、ユーザ端末２０００の機能構成図である。図２４によれば、ユーザ端末２０００は、機能的には、操作入力部４１０と、処理部５００と、画像表示部４３０と、音声出力部４４０と、無線通信部４２０と、記憶部６００とを備えて構成される。

操作入力部４１０は、ユーザによる操作入力を受け付け、操作に応じた操作信号を処理部５００に出力する。この機能は、ボタンスイッチやジョイスティック、タッチパッド、トラックボールなどによって実現される。図２では、操作キー２００６がこれに該当する。また、操作入力部４１０は、表示画面に対する接触位置を検出する接触位置検出部４１１を含む。図２では、タッチパネル２０１０がこれに該当する。

処理部５００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、ユーザ端末２０００の各機能部の間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部４１０からの操作信号等に基づいて各種の演算処理を実行して、ユーザ端末２０００の動作を制御する。図２では、制御装置２０１２がこれに該当する。また、処理部５００は、メッセージ投稿部５１０と、画像生成部５３０と、音声生成部５４０とを含む。

メッセージ投稿部５１０は、アバター表示制御部５１１と、アバター編集部５１２と、投稿実行部５１３と、投稿分析部５１４と、アイテム発生部５１５とを有し、サーバシステム１０００によって提供されるメッセージ投稿サービスを、該ユーザ端末２０００にて実現する処理を行う。

アバター表示制御部５１１は、フォローユーザのアバターを表示したフィールド画面Ｗ１（図８参照）を、画像表示部４３０に表示させる。具体的には、フォローユーザ管理データ６４０を参照して、フィールドにアバター２０を配置するフォローユーザを特定する。そして、特定したフォローユーザそれぞれについて、設定されているアバター２０をフィールドに配置したフィールド画面Ｗ１を表示させる。このとき、配置するアバター２０にアイテムが設定されている場合には、該設定されているアイテム８０を付加表示させる。また、未実行の指示コマンドが有る場合には、アバター２０に、該指示コマンドに対応するモーションを実行させる。

フォローユーザ管理データ６４０は、自ユーザのフォローユーザのアバター２０を表示制御するための管理データである。図２５は、フォローユーザ管理データ６４０のデータ構成の一例を示す図である。図２５によれば、フォローユーザ管理データ６４０は、フォローユーザ毎に生成され、該当するフォローユーザのユーザＩＤ６４１と、ユーザ名６４２と、設定アバターＩＤ６４３と、アバターの配置フラグ６４４と、アバターへの設定アイテムＩＤ６４５と、未実行指示コマンド６４６と、投稿分析結果データ６５０とを格納している。

アバターの配置フラグ６４４は、設定したアバター２０をフィールドに配置するか否かを示すフラグである。未実行指示コマンド６４６は、設定したアバター２０に所定のモーションを実行させるための指示コマンドであって、未だ実行されていない指示コマンドのストックである。この未実行指示コマンド６４６は、投稿分析部５１４による該フォローユーザの投稿に対する分析の結果、追加される。投稿分析結果データ６５０は、投稿分析部５１４による、該フォローユーザの投稿に対する投稿分析の結果のデータであり、詳細は後述する（図３３参照）。

また、アバター２０へのアイテム８０の付加表示は、アバター画像に、アイテム画像を重畳表示することで実現する。アイテム画像は、アイテムテーブル７５０として記憶されている。

図２６は、アイテムテーブル７５０のデータ構成の一例を示す図である。図２６に示すように、アイテムテーブル７５０は、予め用意されているアイテムそれぞれについて、アイテムＩＤ７５１と、アイテム名７５２と、アイテム画像７５３とを対応付けて格納している。

また、指示コマンドとモーションとの対応付けは、指示コマンドテーブル７７０として記憶されている。図２７は、指示コマンドテーブル７７０のデータ構成の一例を示す図である。図２７に示すように、指示コマンドテーブル７７０は、指示コマンド７７１と、モーションＩＤ７７２とを対応付けて格納している。

フィールドに配置されているアバター２０についてのデータは、アバター配置データ６６０として記憶される。図２８は、アバター配置データ６６０のデータ構成の一例を示す図である。図２８によれば、アバター配置データ６６０は、現在、フィールド９０に配置されているアバター２０それぞれについて、アバターＩＤ６６１と、設定フォローユーザＩＤ６６２と、フィールド９０における配置位置６６３とを対応付けて格納している。

また、アバター表示制御部５１１は、投稿分析部５１４による投稿分析結果に基づいて、アバター２０をグループ分けし、グループ毎に整列させて表示させる。具体的には、アバター配置データ６６０を参照して、現在、フィールドにアバターを配置しているフォローユーザを特定する。そして、特定したフォローユーザを、該フォローユーザの投稿に含まれる、所定のグループ分け用のキーワードをもとに、グループ分けし、グループ毎に、各フォローユーザのアバター２０を、該グループに定められた所定位置に再配置する。

詳細には、グループ分け用のキーワードは複数のカテゴリに分類されている。各フォローユーザについて、このカテゴリ毎に、該カテゴリに含まれる各キーワードの抽出回数の合計を算出し、抽出回数が最多のカテゴリを、該フォローユーザの所属カテゴリとする。そして、この所属カテゴリ毎に、フォローユーザをグループ分けする。

ここで、フォローユーザの投稿に含まれるグループ分け用のキーワードは、投稿分析部５１４によって抽出され、投稿分析結果データ６５０として記憶されている（図３３参照）。

アバター編集部５１２は、アバター２０の新規作成、及び、アバター２０の修正を行う。具体的には、アバター２０の新規作成では、初期アバターをエディット対象としたアバターエディット画面Ｗ３（図１２参照）を表示させ、ユーザ操作に従って初期アバターに対する修正を行うことで新たなアバターを作成し、作成したアバターを、新たなアバターとして追加登録する。また、アバター２０の修正は、登録されているアバターをエディット対象としたアバターエディット画面Ｗ３を表示させ、ユーザ操作に従って登録アバターに対する修正を行い、修正後のアバターを更新登録する。

ここで、初期アバターについてのデータは、初期アバターデータ７１０として記憶され、登録アバターそれぞれについてのデータは、登録アバターデータ７２０として登録されている。初期アバターデータ７１０と登録アバターデータ７２０とは同様のデータ構成であり、初期アバター２０は、基本パーツ以外のパーツの設定が無いデータとなっている。

図２９は、登録アバターデータ７２０のデータ構成の一例を示す図である。図２９によれば、登録アバターデータ７２０は、登録アバター毎に生成され、該当するアバター２０のアバターＩＤ７２１と、設計ユーザ名７２２と、設計データ７２３とを格納している。設計ユーザ名７２２は、該アバターを最後に修正・作成したユーザ名である。

設計データ７２３は、該アバターを構成する各パーツの詳細についてのデータであり、該アバターを構成するパーツ７２３ａそれぞれについて、適用されているパーツＩＤ７２３ｂと、調整データ７２３ｃを対応付けて格納している。調整データ７２３ｃは、パーツの基本値に対する調整度合を示すデータであり、大きさと、位置と、回転角度とが含まれている。大きさは、基本の大きさに対する拡大／縮小の比率である。位置は、基本パーツに対する基本の配置位置からのＸ，Ｙ軸方向へのずれである。回転角度は、基本の配置向きに対する回転角度である。

ここで、用意されているアバター２０のパーツについてのデータは、アバターパーツテーブル７３０として記憶されている。図３０は、アバターパーツテーブル７３０のデータ構成の一例を示す図である。図３０によれば、アバターパーツテーブル７３０は、パーツ種別７３１毎に生成され、パーツＩＤ７３２と、パーツ画像７３３とを対応付けて格納している。

投稿実行部５１３は、ユーザ操作に従ってメッセージの投稿を行う。具体的には、メッセージを入力するための投稿画面Ｗ４（図１３参照）を表示させ、ユーザ操作に従ってメッセージをテキスト入力する。このとき、「指定投稿」ならば、所定の識別子を付加した宛先のユーザ名を、「引用投稿」ならば、引用する投稿を、予め、投稿画面Ｗ４の入力エリア４７に入力しておく。

また、アバター２０を投稿するならば、該投稿するアバター２０の設計データ７２３に基づく「アバターデータ」を、投稿メッセージに含める。ここで、「アバターデータ」は、該当するアバターの設計データ７２３のパラメータ（適用パーツＩＤや調整データ）を、定められたパーツ順に並べたデータである。また、指示コマンドを投稿するならば、該指示コマンドを、投稿メッセージに含める。そして、投稿実行が指示されると、入力されたメッセージを、投稿データとしてサーバシステム１０００に送信する。

図３１は、投稿メッセージのフォーマットを示す図である。図３１（ａ）は、アバターの投稿の際のフォーマットを示し、図３１（ｂ）は、指示コマンドの投稿の際のフォーマットを示している。アバターデータ１２及び指示コマンド１４は、ともに、自ユーザによる入力メッセージ８の一部に含められる。図３１（ａ）に示すように、アバターデータ１２」には、アバターデータで有ることを示す所定の識別子６ｃ（図３１（ａ）では、２つの記号「％」）が、その前後に付加される。また、図３１（ｂ）に示すように、指示コマンド１４は、指示コマンドであることを示す所定の識別子６ｄ（図３１（ｂ）では、２つの記号「＆」）が、その前後に付加される。

投稿分析部５１４は、自ユーザ、及び、フォローユーザの投稿に対する分析を行う。具体的には、自ユーザの投稿に対する分析は、投稿実行部５１３によってなされた投稿に対して行う。すなわち、該投稿データに、所定のアイテム発生用のキーワードが含まれるか否かを判断し、含まれているキーワードを抽出する。このアイテム発生用のキーワードは、アバター２０に設定するアイテムの発生条件となるキーワードであり、アイテム発生用キーワードリスト６９２として記憶されている。

自ユーザの投稿に対する分析結果は、自ユーザ投稿分析結果データ６７０として記憶される。図３２は、自ユーザ投稿分析結果データ６７０のデータ構成の一例を示す図である。図３２に示すように、自ユーザ投稿分析結果データ６７０は、自ユーザの投稿毎に生成され、該当する投稿ＩＤ６７１と、投稿日時６７２と、投稿種別６７３と、抽出キーワード６７４とを格納している。

また、フォローユーザの投稿に対する分析は、サーバシステム１０００から取得したフォローユーザの投稿データに対して行う。すなわち、投稿データそれぞれに対して、所定のグループ分け用のキーワードが含まれているか、アバターの設計データが含まれているか、所定の指示コマンドが含まれているかを判断し、含まれているそれらのキーワードや、アバターの設計データ、指示コマンドを抽出する。

そして、アバターの設計データを抽出すると、該設計データに基づくアバターを追加登録する。また、指示コマンドを抽出すると、該指示コマンドを、該フォローユーザの未実行指示コマンドに追加する。

ここで、グループ分け用のキーワードは、フォローユーザをその投稿内容に応じてグループ分けする際に用いるキーワードであり、カテゴリ分けされてグループ分け用キーワードリスト６９４として記憶されている。また、指示コマンドは、アバターに対してモーションを実行させるためのコマンドであり、指示コマンドテーブル７７０にて定められている。

フォローユーザの投稿に対する分析結果は、該当するフォローユーザのフォローユーザ管理データ６４０における投稿分析結果データ６５０として記憶される。

図３３は、投稿分析結果データ６５０のデータ構成の一例を示す図である。図３３に示すように、投稿分析結果データ６５０は、分析済みの投稿それぞれの投稿履歴データ６５１と、抽出キーワードデータ６５２とを含んでいる。投稿履歴データ６５１は、該当する投稿の投稿ＩＤ６５１ａと、投稿日時６５１ｂと、投稿種別６５１ｃと、抽出されたキーワード６５１ｄと、抽出された指示コマンド６５１ｅと、抽出されたアバター設計データのアバターＩＤ６５１ｆとを格納している。抽出キーワードデータ６５２は、予め定められたカテゴリ６５２ａと、該カテゴリに属するキーワード６５２ｂと、抽出回数６５２ｃとを対応付けて格納している。

アイテム発生部５１５は、所定のアイテム発生条件を満たしたときに、該条件に応じたアイテムを発生させ、自ユーザの保有アイテムに追加する。保有アイテムは、フォローユーザのアバターに設定することができる。保有アイテムは、保有アイテムデータ６８０として記憶される。

アイテム発生条件には、（１）自分の投稿数（或いは、単位期間当たりの投稿数である投稿頻度としても良い）、（２）自分の被フォローユーザ数、（３）投稿データに含まれるキーワード、の３種類があり、アイテム発生条件テーブル７６０にて定められている。

図３４は、アイテム発生条件テーブル７６０のデータ構成の一例を示す図である。図３４に示すように、アイテム発生条件テーブル７６０は、アイテム発生条件の種類それぞれについての条件テーブル７６１，７６２，７６３を有する。条件テーブル７６１は、アイテム発生条件として自ユーザの被フォローユーザ数７６１ａと、発生させるアイテム７６１ｂとを対応付けて格納している。条件テーブル７６２は、アイテム発生条件として自ユーザの投稿数７６２ａと、発生させるアイテム７６２ｂとを対応付けて格納している。条件テーブル７６３は、アイテム発生条件として自ユーザの投稿に含まれるキーワード７６３ａと、発生させるアイテム７６３ｂとを対応付けて格納している。

なおここで、各アイテム発生条件に対応するアイテムの発生は１回のみであり、最初に各アイテム発生条件を満たしたときに、対応するアイテムが発生する。

すなわち、アイテム発生部５１５は、サーバシステム１０００から自ユーザデータを取得したときに、条件テーブル７６１，７６２それぞれに従って、該自ユーザデータに含まれる投稿数或いは被フォローユーザ数が新たに満たすアイテム発生条件に対応するアイテムを発生させる。また、投稿実行部５１３による投稿がなされたときに、条件テーブル７６３に従って、投稿分析部５１４によって抽出された、自ユーザの投稿データに含まれるアイテム発生用のキーワードが新たに満たすアイテム発生条件に対応するアイテムを発生させる。

図２４に戻り、画像生成部５３０は、アバター表示制御部５１１による処理結果に基づいて１フレーム時間（例えば１／６０秒）間隔で１枚の表示画像を生成し、生成した表示画像の画像信号を画像表示部４３０に出力する。この機能は、例えば、ＧＰＵ（Graphics Processing Unit）、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデック、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。

画像表示部４３０は、画像生成部５３０から入力される画像信号に基づいて各種画像を表示する。この機能は、例えば、フラットパネルディスプレイやブラウン管（ＣＲＴ）といった画像表示装置によって実現できる。図２では、液晶ディスプレイ２００８がこれに該当する。

音声生成部５４０は、アバター表示制御部５１１による処理結果に基づいて、各種効果音やＢＧＭ、操作音等の音信号を生成し、音声出力部４４０に出力する。この機能は、例えばデジタルシグナルプロセッサ（ＤＳＰ）、音声合成ＩＣなどのプロセッサや、音声ファイル再生可能なオーディオコーデックによって実現される。

音声出力部４４０は、音声生成部５４０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する。図２では、スピーカ２００２がこれに該当する。

無線通信部４２０は、通信回線Ｎと接続して外部装置（主に、サーバシステム１０００）との通信を実現する。この機能は、例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図２では、制御装置２０１２に搭載された無線通信装置がこれに該当する。

記憶部６００は、処理部５００にユーザ端末２０００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、各種アプリケーションプログラム、各種データ等を記憶する。また、処理部５００の作業領域として用いられ、処理部５００が各種プログラムに従って実行した演算結果や、操作入力部４１０から入力される入力データ等を一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２では、制御装置２０１２に搭載されたＩＣメモリや、メモリカード２０２０がこれに該当する。

また、本実施形態では、記憶部６００は、プログラムとして、システムプログラム６１０と、メッセージ投稿プログラム６２０とが記憶されるとともに、データとして、アカウント情報６３０と、フォローユーザ管理データ６４０と、アバター配置データ６６０と、自ユーザ投稿分析結果データ６７０と、保有アイテムデータ６８０と、アイテム発生用キーワードリスト６９２と、グループ分け用キーワードリスト６９４と、初期アバターデータ７１０及び登録アバターデータ７２０を含むアバターＤＢと、アバターパーツテーブル７３０と、フィールド画像データ７４０と、アイテムテーブル７５０と、アイテム発生条件テーブル７６０と、指示コマンドテーブル７７０と、モーションデータ７８０とが記憶される。

システムプログラム６１０は、処理部５００が実行することで、ユーザ端末２０００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。メッセージ投稿プログラム６２０は、処理部５００が実行することで、メッセージ投稿部５１０としての機能を実現させるためのプログラムである。

［処理の流れ］
（Ａ）サーバシステム１０００
図３５は、サーバシステム１０００において、投稿管理部２１０が実行する投稿管理処理の流れを説明するフローチャートである。図３５によれば、投稿管理部２１０は、ユーザ端末２０００からユーザデータが要求されたならば（ステップＡ１：ＹＥＳ）、該要求とともに受信されたアカウント情報をもとに、アカウント登録データ３３０を参照して、ユーザ（自ユーザ）を特定する（ステップＡ３）。更に、特定した自ユーザのアカウント登録データ３３０を参照して、フォローユーザを特定する（ステップＡ５）。

次いで、特定した自ユーザのアカウント登録データ３３０を参照して自ユーザデータを生成する。また、特定したユーザのフォローユーザそれぞれについて、該当するアカウント登録データ３３０を参照してフォローユーザデータを生成する。そして、生成した自ユーザデータ、及び、各フォローユーザデータを、該ユーザ端末２０００に送信する（ステップＡ７）。

また、ユーザ端末２０００から投稿データを受信したならば（ステップＡ９：ＹＥＳ）、該投稿データとともに受信されたアカウント情報をもとに、アカウント登録データ３３０を参照して、送信元のユーザを特定する（ステップＡ１１）。そして、受信した投稿データを、特定したユーザの投稿データに追加する（ステップＡ１３）。また、該投稿が指定投稿ならば（ステップＡ１５：ＹＥＳ）、宛先のユーザを特定し、受信した投稿データを、該特定したユーザの受信投稿データに追加する（ステップＡ１７）。その後、ステップＡ１に戻る。投稿管理処理は、このように行われる。

（Ｂ）ユーザ端末２０００
図３６，図３７は、ユーザ端末２０００において、メッセージ投稿部５１０が実行するメッセージ投稿処理の流れを説明するフローチャートである。図３６に示すように、メッセージ投稿部５１０は、先ず、サーバシステム１０００から、自ユーザ、及び、フォローユーザそれぞれのユーザデータを取得する（ステップＢ１）。次いで、投稿分析部５１４が、取得したフォローユーザデータを対象とした投稿分析処理を行う（ステップＢ３）。

図３８は、投稿分析処理の流れを説明するフローチャートである。図３８によれば、投稿分析部５１４は、フォローユーザそれぞれを対象としたループＡの処理を行う。

ループＡでは、先ず、サーバシステム１０００から取得した、対象フォローユーザのフォローユーザデータに含まれる投稿データのうちから、未分析の投稿データを抽出する（ステップＣ１）。そして、抽出した未分析の投稿データそれぞれを対象としたループＢの処理を行う。

ループＢでは、対象投稿データの投稿種別を特定する（ステップＣ３）。また、対象投稿データに、アバターの設計データが含まれるか否かを判断し、含まれるならば（ステップＣ５：ＹＥＳ）、該含まれているアバターの設計データを抽出し（ステップＣ７）、該設計データに基づくアバターを生成して追加登録する（ステップＣ９）。

また、対象投稿データに、所定のグループ分け用のキーワードが含まれるか否かを判断し、含まれるならば（ステップＣ１１：ＹＥＳ）、含まれているキーワードを抽出する（ステップＣ１３）。

また、対象投稿データに、所定の指示コマンドが含まれるか否かを判断し、含まれるならば（ステップＣ１５：ＹＥＳ）、含まれている指示コマンドを抽出し（ステップＣ１７）、該抽出した指示コマンドを、対象フォローユーザの未実行指示コマンドに追加する（ステップＣ１９）。

その後、対象投稿データを分析済みとして、対象フォローユーザの投稿履歴を追加する（ステップＣ２１）。ループＢの処理は、このように行われる。

未分析の投稿データの全てを対象としたループＢの処理を終了すると、対象フォローユーザについてのループＡの処理を終了する。そして、全てのフォローユーザを対象としたループＡの処理を終了すると、投稿分析処理を終了する。

投稿分析処理が終了すると、次いで、アイテム発生部５１５が、最新の自ユーザデータをもとに、新たに満たすアイテム発生条件の有無を判断し、新たに満たすアイテム発生条件が有るならば、該アイテム発生条件に対応するアイテムを、自ユーザが取得したとして、所有アイテムに追加する（ステップＢ５）。

続いて、アバター表示制御部５１１が、フィールド表示処理を行って、フィールド画面Ｗ１を表示させる（ステップＢ９）。

図３９は、フィールド表示処理の流れを説明するフローチャートである。図３９によれば、アバター表示制御部５１１は、先ず、フィールドにアバター２０を配置するフォローユーザ（配置フォローユーザ）を特定する（ステップＤ１）。次いで、特定した各配置フォローユーザそれぞれに対応するアバター２０をフィールドに配置したフィールド画面Ｗ１を表示させる（ステップＤ３）。

そして、配置フォローユーザそれぞれについて、アバターに付加するアイテムが設定されているか否かを判断し、設定されているならば、該アバター２０に、設定されているアイテムを付加表示させる（ステップＤ５）。また、各アバター２０に、吹き出し２２を付加表示させる（ステップＤ７）。次いで、全ての配置フォローユーザのうち、投稿日時が最新である一人のフォローユーザを特定し（ステップＤ９）、特定したフォローユーザのアバター２０を拡大表示させるとともに、該アバター２０の吹き出し２２を拡大表示して、この吹き出し２２に、該フォローユーザの最新の投稿をテキスト表示させる（ステップＤ１１）。

更に、配置フォローユーザそれぞれについて、未実行指示コマンドが有るか否かを判断し、有る場合には、その未実行指示コマンドに対応するモーションを、該フォローユーザのアバターに行わせる（ステップＤ１３）。以上の処理を行うと、フィールド表示処理を終了する。

フィールド表示処理が終了すると、定期更新処理（図４５参照）を開始する（ステップＢ９）。

続いて、フィールド画面Ｗ１において、アバター２０がタッチされたならば（ステップＢ１１：ＹＥＳ）、該アバター２０についての「アバターメニュー２６」を表示させる（ステップＢ１３）。そして、このアバターメニュー２６において、「アバター修正」がタッチされたならば（ステップＢ１５：ＹＥＳ）、アバター編集部５１２が、該選択されたアバター２０をエディット対象としたアバター修正処理を行う（ステップＢ１７）。

図４０は、アバター修正処理の流れを説明するフローチャートである。図４０によれば、アバター編集部５１２は、先ず、選択されたアバター２０をエディット対象としたアバターエディット画面Ｗ３を表示させる（ステップＥ１）。次いで、ユーザ操作に従って、エディット対象のアバターの修正を行う（ステップＥ３）。

そして、「登録（ＯＫ）」がタッチされたならば（ステップＥ５：ＹＥＳ）、修正後のアバターを、更新登録する（ステップＥ７）。また、「キャンセル」が選択されたならば（ステップＥ９：ＹＥＳ）、エディット対象のアバターに対する修正をキャンセルする（ステップＥ１１）。その後、フィールド画面Ｗ１を再表示する（ステップＥ１３）。以上の処理を行うと、アバター修正処理を終了する。

また、アバターメニュー２６において、「指定投稿」がタッチされたならば（ステップＢ１９：ＹＥＳ）、投稿実行部５１３が、該選択されたアバター２０に対応するフォローユーザを宛先とした指定投稿を行う（ステップＢ２１）。

指定投稿を行うと、続いて、投稿分析部５１４が、投稿データに対する分析を行う。すなわち、投稿データの投稿種別を特定するとともに、該投稿データに含まれている所定のアイテム発生用のキーワードを抽出する（ステップＢ２３）。

その後、アイテム発生部５１５が、投稿データから抽出されたキーワードをもとに、新たに満たすアイテム発生条件の有無を判断し、新たに満たすアイテム発生条件が有るならば、該アイテム発生条件に対応するアイテムを、自ユーザが取得したとして、所有アイテムに追加する（ステップＢ２５）。

また、アバターメニュー２６において、「モーション停止」がタッチされたならば（ステップＢ２７：ＹＥＳ）、アバター表示制御部５１１は、該アバター２０に適用しているモーションを終了させる（ステップＢ２９）。

また、フィールド画面Ｗ１において、吹き出し２２がタッチされたならば（ステップＢ３１：ＹＥＳ）、アバター表示制御部５１１は、該選択された吹き出し２２のアバター２０に対応するフォローユーザを特定し、該フォローユーザの最新の投稿を表示した投稿詳細画面Ｗ２を表示させる（ステップＢ３３）

また、図３７に示すように、フィールド画面Ｗ１において、「アバターボタン３１」がタッチされたならば（ステップＢ３５：ＹＥＳ）、アバター編集部５１２が、アバター処理を行う（ステップＢ３７）。

図４１，４２は、アバター処理の流れを説明するフローチャートである。図４１によれば、アバター編集部５１２は、先ず、全てのアバターについてのアバターメニュー２８を表示させる（ステップＦ１）。

そして、このアバターメニュー２８において「アバターの編集」が選択され、更に編集方法として「登録アバターの修正」が選択されたならば（ステップＦ３：ＹＥＳ）、ユーザ操作に従って、登録アバターのうちから、エディット対象とする登録アバターを選択する（ステップＦ５）。次いで、選択した登録アバターをエディット対象としたアバターエディット画面Ｗ３を表示させる（ステップＦ７）。続いて、ユーザ操作に従って、エディット対象のアバターの修正を行う（ステップＦ９）。

その後、「登録」が選択されたならば（ステップＦ１１：ＹＥＳ）、修正後のアバターを、更新登録する（ステップＦ１３）。続いて、該アバターが、フォローユーザに設定されているか否かを判定し、設定されていないならば（ステップＦ１５：ＮＯ）、ユーザ操作に従って、該アバターを、何れかのフォローユーザに設定するか否かを決定する。

該アバターをフォローユーザに設定するならば（ステップＦ１７：ＹＥＳ）、ユーザ操作に従って、自ユーザのフォローユーザのうちから、アバターを設定するフォローユーザを選択する（ステップＦ１９）。次いで、選択したフォローユーザに、既にアバターが設定されているか否かを判断し、設定されていないならば（ステップＦ２１：ＮＯ）、該アバターを、該選択したフォローユーザに新規設定する（ステップＦ２５）。一方、選択したフォローユーザには、既にアバターが設定されているならば（ステップＦ２１：ＹＥＳ）、該設定されているアバターに替えて、該アバターを更新設定する（ステップＦ２３）。その後、フィールド画面Ｗ１を再表示する（ステップＦ６９）。

また、アバターメニュー２８において「アバターの編集」が選択され、更に編集方法として「新規作成」がタッチされたならば（ステップＦ３３：ＹＥＳ）、初期アバターをエディット対象としたアバターエディット画面Ｗ３を表示させる（ステップＦ３５）。次いで、ユーザ操作に従って、アバターの作成を行う（ステップＦ３７）。

そして、「登録」が選択されたならば（ステップＦ３９：ＹＥＳ）、作成したアバターを、追加登録する（ステップＦ４１）。続いて、ユーザ操作に従って、作成したアバターをフォローユーザに設定するか否かを決定し、設定するならば（ステップＦ４３：ＹＥＳ）、ユーザ操作に従って、自ユーザのフォローユーザのうちから、アバターを設定するフォローユーザを選択する（ステップＦ４５）。

選択したフォローユーザに、既にアバターが設定されているか否かを判断し、設定されていないならば（ステップＦ４７：ＮＯ）、該フォローユーザに、作成したアバターを、新規設定する（ステップＦ５１）。一方、アバターが既に設定されているならば（ステップＦ４７：ＹＥＳ）、該既に設定されているアバターに替えて、作成したアバターを、該フォローユーザに更新設定する（ステップＦ４９）。その後、フィールド画面Ｗ１を再表示する（ステップＦ６９）。

また、アバターメニュー２８において、フィールドにおける「アバターの位置変更」がタッチされたならば（ステップＦ５７：ＹＥＳ）、ユーザ操作に従って、フィールドにおける各アバターの配置位置を変更する（ステップＦ５９）。その後、フィールド画面Ｗ１を再表示する（ステップＦ６９）。

また、アバターメニュー２８において、「配置アバターの変更」がタッチされたならば（ステップＦ６１：ＹＥＳ）、ユーザ操作に従って、フィールドにアバターを配置するフォローユーザの追加・削除等の変更を行う（ステップＦ６３）。その後、フィールド画面Ｗ１を再表示する（ステップＦ６９）。

また、アバターメニュー２８において、「フォローユーザへのアバターの設定変更」が選択されたならば（ステップＦ６５：ＹＥＳ）、ユーザ操作に従って、アバターの設定変更を行うフォローユーザを選択し、該選択したフォローユーザへのアバターの設定変更を行う（ステップＦ６７）。その後、フィールド画面Ｗ１を再表示する（ステップＦ６９）。以上の処理を行うと、アバター処理を終了する。

また、フィールド画面Ｗ１において、「更新ボタン３４」がタッチされたならば（ステップＢ３９：ＹＥＳ）、アバター表示制御部５１１は、フィールド更新処理を行う（ステップＢ４１）。

図４３は、フィールド更新処理の流れを説明するフローチャートである。図４３に示すように、サーバシステム１０００から、自ユーザ、及び、各フォローユーザのユーザデータを再取得する（ステップＧ１）。次いで、取得したフォローユーザデータをもとに、フィールド画面Ｗ１における各アバター２０の吹き出し２２の表示を更新する（ステップＧ３）。すなわち、フォローユーザのうちから、最新の投稿を行ったフォローユーザを特定し、該特定したフォローユーザのアバター２０及び吹き出し２２を拡大表示させ、この吹き出し２２に、フォローユーザの最新の投稿の内容をテキスト表示させる。

その後、再取得したフォローユーザデータを対象とした投稿分析処理（図３８参照）を行う（ステップＧ５）。以上の処理を行うと、フィールド更新処理を終了する。

また、フフィールド画面Ｗ１において、「メインボタン３３」がタッチされたならば（ステップＢ４３：ＹＥＳ）、自ユーザのメイン画面Ｗ５を表示させる（ステップＢ４５）。

また、フィールド画面Ｗ１において、「フォローボタン３５」がタッチされたならば（ステップＢ４７：ＹＥＳ）、自ユーザのフォローユーザを一覧表示させた「フォローリスト画面」を表示させる（ステップＢ４９）。

図３７に戻り、フィールド画面Ｗ１において、「投稿ボタン３２」がタッチされたならば（ステップＢ５１：ＹＥＳ）、投稿実行部５１３が、新規投稿を行う（ステップＢ５３）。新規投稿を行うと、続いて、投稿分析部５１４が、投稿データに対する分析を行う。すなわち、投稿データの投稿種別を特定するとともに、該投稿データに含まれている所定のアイテム発生用のキーワードを抽出する（ステップＢ５５）。

その後、アイテム発生部５１５が、投稿データから抽出されたキーワードをもとに、新たに満たすアイテム発生条件の有無を判断し、新たに満たすアイテム発生条件が有るならば、該アイテム発生条件に対応するアイテムを、自ユーザが取得したとして、所有アイテムに追加する（ステップＢ５７）。

また、フィールド画面Ｗ１において、「アイテムボタン３６」がタッチされたならば（ステップＢ５９：ＹＥＳ）、ユーザ操作に従って、各フォローユーザのアタバーに付加表示させるアイテムの設定変更を行う（ステップＢ６１）。

また、フィールド画面Ｗ１において、「整列ボタン３７」が選択されたならば（ステップＢ６３：ＹＥＳ）、アバター表示制御部５１１は、アバター整列処理を行う（ステップＢ６５）。

図４４は、アバター整列処理の流れを説明するフローチャートである。図４４によれば、アバター表示制御部５１１は、先ず、ユーザ操作に従って、整列規則を決定する。そして、整列規則として「投稿日時」に従って整列させるならば（ステップＨ１：ＹＥＳ）、フィールド９０に配置されている各アバター２０を、対応するフォローユーザの最新の投稿日時に従ってソートし（ステップＨ３）、ソート順に、各アバター２０を再配置する（ステップＨ５）。

また、「投稿数」に従って整列させるならば（ステップＨ７：ＹＥＳ）、フィールド９０に配置されている各アバター２０を、対応するフォローユーザの投稿数に従ってソートし（ステップＨ９）、ソート順に、各アバター２０を再配置する（ステップＨ１１）。

また、「投稿内容」に従って整列させるならば（ステップＨ１３：ＹＥＳ）、フィールドに配置されている各アバター２０について、対応するフォローユーザの投稿分析結果データ６５０をもとに、属する抽出キーワードの合計が最多であるカテゴリ（投稿最多カテゴリ）を特定し、特定した投稿最多カテゴリによってグループ分けする（ステップＨ１５）。そして、グループ毎に、各アバター２０を、該グループに定められた所定位置に再配置する（ステップＨ１７）。以上の処理を行うと、アバター整列処理を終了する。

その後、図３７において、メッセージ投稿部５１０は、終了指示が入力される等によって本処理を終了するか否かを判断し、終了しないならば（ステップＢ６７：ＮＯ）、ステップＢ１１に戻り、同様の処理を繰り返す。終了するならば（ステップＢ６７：ＹＥＳ）、メッセージ投稿処理を終了する。

図４５は、定期更新処理の流れを説明するフローチャートである。図４５に示すように、先ず、タイマーを開始する（ステップＪ１）。そして、タイマーによる計時時間が所定時間に達したならば（ステップＪ３：ＹＥＳ）、フィールド更新処理（図４３参照）を行う（ステップＪ５）。フィールド更新処理が終了すると、タイマーをリセットした後（ステップＪ７）、ステップＪ１に戻る。定期更新処理は、このように行われる。

［作用・効果］
このように、本実施形態によれば、ユーザ端末２０００では、フォローユーザそれぞれに対応付けたアバター２０を表示したフィールド画面Ｗ１が表示される。アバター２０には、投稿があることを示す吹き出し２２が付加表示されており、この吹き出し２２をタッチすることで、対応するフォローユーザの投稿の内容が表示される。これにより、フォローユーザの投稿を単にテキスト表示するのみでなく、より興趣性に優れた他ユーザの投稿の表示が実現される。

また、アバター２０はユーザが自由に設計できるので、例えばフォローユーザの容姿に似せたアバター２０を設計し対応付けることが可能となり、フォローユーザに対する親しみが増し、更なる興趣性の向上が得られる。更に、アバターの設計データを投稿することができるので、自分が設計したアバターを他のユーザと共有したり、アバター２０にアイテム８０を付加表示させたり、投稿内容に応じたモーションをアバター２０に行わせるといった、キャラクタを使用することならではの興趣性が得られる。

［変形例］
なお、本発明の適用可能な実施形態は、上述の実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能なのは勿論である。

（Ａ）吹き出し２２
例えば、上述の実施形態では、フォローユーザの投稿が有ることを示すための対応するアバター２０の識別表示として、付随表示体である吹き出し２２を付加表示させることにしたが、これ以外の表示体を表示することにしても良い、更に、アバター２０の表示色を変化させるといったようにアバター２０そのものの表示態様を変化させたり、所定のモーションを行うこととしてもよい。

（Ｂ）画像投稿
また、画像投稿が可能であり、フォローユーザの投稿に画像が含まれる場合、該フォローユーザに対応するアバター２０を、画像が含まれることを示す所定の表示態様に変化させることにしても良い。

図４６は、この場合のフィールド画面Ｗ１の一例である。図４６では、アバター２０に、対応するフォローユーザの投稿に画像が含まれていることを示す所定の画像アイコン８２（図４６では、カメラのアイコン）が付加表示されている。更に、この画像アイコン８２をタッチすると、対応する画像が表示されることにしても良い。なお、投稿データがテキストデータである場合、画像投稿は、画像の所在を示すＵＲＬアドレス（画像の特定情報）を含めることで実現される。つまり、投稿データに含まれている画像投稿用のＵＲＬアドレスを検出することで、該投稿データに含まれている画像を検出することができる。

また、画像が含まれることを示す表示態様は、これ以外でも良く、例えば、アバター２０の表示色やモーションを変化させることにしても良い。

（Ｃ）アバター２０間の親密度
また、フォローユーザ間に該フォローユーザの投稿に基づく「親密度」を設定し、この親密度に応じて、対応するアバター２０の表示形態を変更することにしても良い。具体的には、例えば、ある二人のフォローユーザ間の「親密度」を、一方のフォローユーザが他方のフォローユーザの投稿を引用元とした引用投稿を行った回数とする。そして、該フォローユーザそれぞれに対応するアバター２０の配置位置を、例えば、親密度が高くなるほど近づくといったように、親密度に応じて変更する。更に、所定以上の親密度となったときには、例えば、二体のアバター２０が互いに向き合ったり、二体がペアとなってくるくる回るといったように、親密度が高いことを示唆するような所定の動作を行わせることにしても良い。

（Ｄ）自ユーザのアバター
また、上述の実施形態では、フィールド画面Ｗ１には、フォローユーザのアバター２０が表示されることとしたが、自ユーザのアバターを配置することにしても良い。

（Ｅ）アイテム
また、上述の実施形態では、ユーザ端末２０００において、サーバシステム１０００から取得した自ユーザデータをもとに、所定のアイテム発生条件を満たすアイテムを発生させることとしたが、これを、サーバシステム１０００が発生させることにしても良い。具体的には、サーバシステム１０００が、アカウント登録データ３３０を参照して、ユーザ毎に、アイテム発生条件を満たしたか否かを判断し、満たしたアイテム発生条件に対応するアイテムのデータをユーザ端末２０００に送信することで、該アイテムをユーザに付与する。

１ メッセージ投稿システム
１０００ サーバシステム
１１０ 操作入力部、１２０ 通信部、１３０ 画像表示部
２００ サーバ処理部、２１０ 投稿管理部、２２０ 画像生成部
３００ サーバ記憶部
３１０ サーバシステムプログラム、３２０ 投稿管理プログラム
３３０ アカウント登録データ
２０００ ユーザ端末
４１０ 操作入力部、４１２ 接触位置検出部
４２０ 画像表示部、４３０ 音声出力部、４４０ 無線通信部
５００ 処理部
５１０ メッセージ投稿部
５１１ アバター表示制御部、５１２ アバター編集部
５１３ 投稿実行部、５１４ 投稿分析部、５１５ アイテム発生部
５３０ 画像生成部、５４０ 音声生成部
６００ 記憶部
６１０ システムプログラム、６２０ メッセージ投稿プログラム
６３０ アカウント情報、６４０ フォローユーザ管理データ
６６０ 配置アバターデータ、６７０ 自ユーザ投稿分析結果データ
６８０ 保有アイテムデータ
７１０ 初期アバターデータ、７２０ 登録アバターデータ
７３０ アバターパーツテーブル、７４０ フィールド画像データ
７５０ アイテムテーブル、７６０ アイテム発生条件テーブル
７７０ 指示コマンドテーブル、７８０ モーションデータ
Ｗ１〜Ｗ６ 表示画面
２０ アバター、２２ 吹き出し

Claims (17)

1. ユーザ端末から投稿された投稿データを、ユーザ毎に投稿日時と対応付けて管理するとともに、ユーザ毎に登録されたフォローユーザを管理して、フォローユーザを登録したユーザのユーザ端末に、当該フォローユーザの投稿データを送信するサーバと通信する通信装置を備えたユーザ端末となるコンピュータを、
   複数のキャラクタを記憶部に記憶させるキャラクタ記憶制御手段、
   各フォローユーザに対応するキャラクタを、前記記憶部に記憶されたキャラクタの中から選択設定するキャラクタ対応設定手段、
   前記キャラクタ対応設定手段により対応設定されたキャラクタを所与の仮想空間に表示制御するキャラクタ表示制御手段、
   として機能させるとともに、
   前記キャラクタ表示制御手段が、前記サーバからフォローユーザの投稿データを受信した場合に、当該フォローユーザに対応付けられたキャラクタを識別表示する識別表示手段を有するように前記コンピュータを機能させる、
   ためのプログラム。
2. 前記キャラクタ記憶制御手段が、ユーザの操作入力に従ってキャラクタの各部位を設計することでキャラクタを生成して前記記憶部に記憶させる第１のキャラクタ生成手段を有する、
   ように前記コンピュータを機能させるための請求項１に記載のプログラム。
3. 前記第１のキャラクタ生成手段により生成されたキャラクタの設計データを、自ユーザの投稿データに含めて前記サーバに投稿する設計データ投稿手段として前記コンピュータを機能させるための請求項２に記載のプログラム。
4. 前記サーバから受信したフォローユーザの投稿データに、キャラクタの設計データが含まれていることを検出する設計データ検出手段として前記コンピュータを機能させ、
   前記キャラクタ記憶制御手段が、前記設計データ検出手段により検出された設計データに従ってキャラクタを生成して前記記憶部に記憶させる第２のキャラクタ生成手段を有するように前記コンピュータを機能させる、
   ための請求項１〜３の何れか一項に記載のプログラム。
5. 前記識別表示手段が、当該フォローユーザに対応付けられたキャラクタに、所与の付随表示体を付随させて表示制御することで前記識別表示を行う、ように前記コンピュータを機能させるための請求項１〜４の何れか一項に記載のプログラム。
6. 前記キャラクタ表示制御手段により表示制御されたキャラクタの中から文書送信先のキャラクタを選択する送信先キャラクタ選択手段、
   前記送信先キャラクタ選択手段により選択されたキャラクタに対応付けられたフォローユーザに向けて文書データを送信する文書送信手段、
   として前記コンピュータを機能させるための請求項１〜５の何れか一項に記載のプログラム。
7. 前記キャラクタ表示制御手段が、前記サーバから受信した投稿データの内容、投稿日時及び投稿頻度のうちの少なくとも１つに基づいて、前記キャラクタの前記仮想空間中の配置位置を変更する配置位置変更手段を有するように前記コンピュータを機能させる、
   ための請求項１〜６の何れか一項に記載のプログラム。
8. 前記配置位置変更手段が、前記サーバから受信した投稿日時及び投稿頻度のうちの少なくとも１つに基づいて、前記仮想空間中のキャラクタを整列させる整列手段を有するように前記コンピュータを機能させる、
   ための請求項７に記載のプログラム。
9. 前記配置位置変更手段が、前記サーバから受信した投稿データに所与のキーワードが含まれるか否かに基づいて、前記仮想空間中のキャラクタをグループ別に配置させるグループ配置手段を有するように前記コンピュータを機能させる、
   ための請求項７又は８に記載のプログラム。
10. 前記サーバは、各ユーザについて、当該ユーザがフォローユーザとして登録されている数、当該ユーザが投稿した投稿データの内容、及び投稿数の何れかに基づいて、アイテム発生条件を満たしたか否かを判断する手段と、前記アイテム発生条件を満たしたユーザのユーザ端末に表示アイテムのデータを送信する手段とを備えており、
    前記サーバから前記表示アイテムを受信する表示アイテム受信手段、
    ユーザの操作入力に従って、前記記憶部に記憶されたキャラクタを、前記表示アイテム受信手段により受信された表示アイテムが付加した表示態様に更新するアイテム付加手段、
    として前記コンピュータを機能させるための請求項１〜９の何れか一項に記載のプログラム。
11. 前記サーバから受信したフォローユーザの投稿データに、画像データ又は当該画像データの所在を示す特定情報が含まれていることを検出する画像データ検出手段として前記コンピュータを機能させ、
    前記キャラクタ表示制御手段が、前記画像データ検出手段により検出されたフォローユーザに対応するキャラクタを、画像データが検出された旨を示す表示態様に変更する画像検出時態様変更手段を有するように前記コンピュータを機能させる、
    ための請求項１〜１０の何れか一項に記載のプログラム。
12. 前記サーバから受信したフォローユーザの投稿データの内容を分析する投稿内容分析手段として前記コンピュータを機能させ、
    前記キャラクタ表示制御手段が、前記投稿内容分析手段の分析結果に基づいて対応するキャラクタを動作制御する第１の動作制御手段を有するように前記コンピュータを機能させる、
    ための請求項１〜１１の何れか一項に記載のプログラム。
13. 前記投稿内容分析手段が、前記サーバから受信したフォローユーザの投稿データに含まれる用語に基づいて、当該フォローユーザの当該用語の使用頻度及び／又は使用数を分析する用語分析手段を有し、
    前記第１の動作制御手段が、前記用語分析手段の分析結果に基づいて、前記フォローユーザのキャラクタに予め定められた動作を行わせる、
    ように前記コンピュータを機能させるための請求項１２に記載のプログラム。
14. 前記投稿内容分析手段が、移動及び／又は動作に係る指示コマンドが前記投稿データに含まれているか否かを判断する手段を有し、
    前記第１の動作制御手段が、前記投稿内容分析手段によって前記指示コマンドが含まれていると判断された場合に、当該指示コマンドに従って、対応するキャラクタを前記仮想空間中で移動及び／又は動作させる、
    ように前記コンピュータを機能させるための請求項１２又は１３に記載のプログラム。
15. 前記サーバから受信したフォローユーザの投稿データに、他人の投稿に関連する投稿であることを示す関連投稿データが含まれていることを検出する関連投稿検出手段、
    各フォローユーザそれぞれ間の親密度を、前記関連投稿検出手段の検出結果に基づいて設定する親密度設定手段、
    として前記コンピュータを機能させるとともに、
    前記キャラクタ表示制御手段が、フォローユーザ同士の前記親密度が所定条件を満たしたフォローユーザそれぞれに対応するキャラクタに、予め定められた動作を行わせる第２の動作制御手段を有するように前記コンピュータを機能させる、
    ための請求項１〜１４の何れか一項に記載のプログラム。
16. 請求項１〜１５の何れか一項に記載のプログラムを記憶したコンピュータ読取可能な情報記憶媒体。
17. ユーザ端末から投稿された投稿データを、ユーザ毎に投稿日時と対応付けて管理するとともに、ユーザ毎に登録されたフォローユーザを管理して、フォローユーザを登録したユーザのユーザ端末に、当該フォローユーザの投稿データを送信するサーバと通信する通信装置を備えたユーザ端末であって、
    複数のキャラクタを記憶部に記憶させるキャラクタ記憶制御手段と、
    各フォローユーザに対応するキャラクタを、前記記憶部に記憶されたキャラクタの中から選択設定するキャラクタ対応設定手段と、
    前記キャラクタ対応設定手段により対応設定されたキャラクタを所与の仮想空間に表示制御するキャラクタ表示制御手段と、
    を備え、
    前記キャラクタ表示制御手段は、前記サーバからフォローユーザの投稿データを受信した場合に、当該フォローユーザに対応付けられたキャラクタを識別表示する識別表示手段を有する、
    ユーザ端末。

Images