JP2017224132A - キャラクタ評価装置、キャラクタ評価方法、及びキャラクタ評価プログラム - Google Patents

Abstract

【課題】現在のキャラクタをより適切なキャラクタに変更することを容易とするキャラクタ評価装置、キャラクタ評価方法、及びキャラクタ評価プログラムを提供する。【解決手段】サーバ装置２０は、複数の要素によって構成されるキャラクタのキャラクタデータを記憶する記憶部と、ユーザ端末１０から、アバターに対するアイテムの変更提案を受け付ける提案受付部と、アバターを所有する所有ユーザ以外の他のユーザからの変更提案に対する評価結果を取得する評価処理部と、を有する。【選択図】図３

Description

本発明は、キャラクタ評価装置、キャラクタ評価方法、及びキャラクタ評価プログラムに関する。

従来、ネットワークを介して複数のユーザがコミュニケーションを行うことができるブログやＳＮＳ（Social Networking Service）やオンライゲーム等のサービスにおいて、複数の要素からなるキャラクタ、例えばアバターをユーザに作成させ、当該アバターを表示させるサービスが提供されている（例えば特許文献１参照）。

上記サービスにおいて、ユーザは、自信に似せるように作成したアバターを、自信の画像の代りに表示させることにより、自信の雰囲気や特徴を他のユーザに伝えることができる。一方で、全てのユーザが自信の特徴や雰囲気を適切に把握できるとは限らず、適切なアバターが作成できていない場合があった。
これに対して、特許文献１には、人物（ユーザ）と、当該人物を表わす画像（アバター）との類似度を、例えば当該人物と顔見知りである他人に評価させ、評価に基づいて類似度を算出する類似度判定装置が記載されている。これにより、他のユーザは、ユーザとアバターとの類似度を容易に把握することができた。

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

しかしながら、特許文献１に記載の装置によって取得された類似度に基づいて、ユーザは、アバターの類似度が低いことがわかったとしても、類似度を向上させ、より適切なアバターへと変更する具体的な方法を知ることはできない。例えば、アバターに対して、他ユーザから「似ていない」との評価が通知されても、ユーザはどこを変更すれば自分に似たアバターとなるかを判断できない。このように、適切なキャラクタを設定できていないユーザが、現在よりもより適切なキャラクタへと変更することは容易ではなかった。

本発明は、現在のキャラクタをより適切なキャラクタに変更することを容易とするキャラクタ評価装置、キャラクタ評価方法、及びキャラクタ評価プログラムを提供することを目的とする。

本発明のキャラクタ評価装置は、複数の要素によって構成されるキャラクタのキャラクタデータを記憶する記憶部と、ユーザ端末から、前記キャラクタに対する前記要素の変更提案を受け付ける提案受付部と、前記キャラクタを所有する所有ユーザ以外の他のユーザからの前記変更提案に対する評価結果を取得する評価処理部と、を有することを特徴とする。

本発明のキャラクタ評価装置は、キャラクタに対する変更提案を受け付け、当該キャラクタの所有ユーザ以外の他のユーザの変更提案に対する評価結果を取得する。これにより、現在のキャラクタが適切なキャラクタであるか否か（例えば、目的に応じてより適切に設定されたキャラクタであるか否か）や、より適切なキャラクタへの変更方法を示す評価結果を、提供することができる。例えば、所有ユーザは、自らの判断で適切なアバターを作成することが困難な場合であっても、評価結果に基づいてキャラクタを設定することにより、より適切なキャラクタへの変更を容易に行うことができる。

本発明の第一実施形態に係るアバター設定システムの概略構成を示す図。 第一実施形態のサーバ装置の構成を示すブロック図。 第一実施形態におけるアバター設定処理の概略を示す図。 第一実施形態におけるアバター設定処理の一例を示すフローチャート。 第一実施形態のアバター設定処理における評価画像を模式的に示す図。 第二実施形態におけるアバター設定処理の一例を示すフローチャート。 第三実施形態におけるアバター設定処理の一例を示すフローチャート。 第二実施形態のアバター設定処理における評価画像を模式的に示す図。 第四実施形態におけるアバター設定処理の一例を示すフローチャート。 第五実施形態のアバター設定処理における評価画像を模式的に示す図。

［第一実施形態］
以下、本発明の一適用例に係るアバター設定システムの第一実施形態について、図面に基づいて説明する。
図１は、第一実施形態のアバター設定システムの概略構成を示す図である。
図１に示すように、本実施形態のアバター設定システム１は、複数のユーザ端末１０と、本発明のキャラクタ評価装置に相当するサーバ装置２０と、を備え、これらのユーザ端末１０及びサーバ装置２０とがネットワーク（例えばインターネット等のＷＡＮ（Wide Area Network））を介して通信可能に接続されている。アバター設定システム１では、複数のユーザが参加するＳＮＳやブログサービス等において、ネットワークを介して、各ユーザのユーザ端末１０から送信された投稿データやメッセージ等のコンテンツが、ユーザのユーザ端末１０から閲覧可能なコンテンツデータとしてサーバ装置２０に登録される。これにより、複数のユーザ間での相互コミュニケーションが可能となる。

このアバター設定システム１は、上記ＳＮＳやブログサービス等において、特定のユーザを表現するために表示されるアバターを、当該特定のユーザ以外の他のユーザの評価に基づいて設定するアバター設定処理を実施する。すなわち、アバター設定システム１では、サーバ装置２０は、上記特定のユーザを表すアバターの変更提案を、他のユーザが操作するユーザ端末１０から受け付ける。そして、サーバ装置２０は、上記特定のユーザと面識のある他のユーザに、上記変更提案の内容について評価させ、評価結果に基づいてアバターの変更等の処理を実施する。
以下、上記のアバター設定処理を提供するための具体的な構成及び方法を説明する。

［ユーザ端末の構成］
ユーザ端末１０は、コンピュータであり、図１に示すように、表示部１１、入力操作部１２、端末通信部１３、端末記憶部１４、及び端末制御部１５を備えている。
表示部１１は、例えば液晶ディスプレイ等により構成され、端末制御部１５の制御の下、所定の画像（例えば各種ウェブページやアバター等）を表示させる。
入力操作部１２は、ユーザ操作による操作信号を端末制御部１５に出力する。この入力操作部１２としては、例えば、表示部１１と一体に設けられたタッチパネル、並びに、キーボード及びマウス等の入力装置を例示できる。

端末通信部１３は、ネットワーク上の他の機器と通信する。これにより、ユーザ端末１０は、サーバ装置２０に対してネットワークを介して通信可能になり、例えば、サーバ装置２０が提供する各種サービスの利用や、サーバ装置２０が記憶している各種データの取得や閲覧が可能となる。
端末記憶部１４は、例えばメモリ、ハードディスク等のデータ記録装置により構成されている。端末記憶部１４には、ユーザ端末１０を制御するための各種プログラム等が記憶される。

端末制御部１５は、ＣＰＵ（Central Processing Unit）等の演算回路、ＲＡＭ（Random Access Memory）等の記憶回路により構成され、ユーザ端末１０の各部を制御する。端末制御部１５は、端末記憶部１４等に記憶されているプログラムの中から所定のアプリケーション等のプログラム（ソフトウェア）をＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働で、各種処理を実行する。そして、端末制御部１５は、上記各種処理を実行することで、図１に示すように、アバター設定部１５１、変更提案部１５２、及び評価実施部１５３等として機能する。

アバター設定部１５１は、後述するサーバ装置２０のアイテムデータベース２２２を参照して、アバターを設定する。すなわち、アバター設定部１５１は、入力操作部１２によるユーザの入力操作に基づいて、アイテムデータベース２２２に登録されたアイテムからアバターを構成するアイテムを選択する。また、アバター設定部１５１は、アバターの変更提案に基づくアバターの変更を許可するか否かについての指示をサーバ装置２０に行う。

変更提案部１５２は、入力操作部１２によるユーザの入力操作に基づいて、他のユーザに対してアバターの変更を提案する変更提案（変更提案情報）を生成する。この変更提案部１５２による変更提案に係る処理については、後述する。
評価実施部１５３は、他のユーザのアバターに対する変更提案について評価を要求された場合、入力操作部１２によるユーザの入力操作に基づき、当該変更提案についての評価を行う。また、評価実施部１５３は、変更提案がユーザ端末１０の所有者（操作者）のアバターに対して変更提案がなされた場合、入力操作部１２によるユーザの入力操作に基づき、当該変更提案について他のユーザに評価してもらうか否かの判定を行う。

［サーバ装置の構成］
図２は、本実施形態のサーバ装置２０を示すブロック図である。
本実施形態のサーバ装置２０は、コンピュータであり、通信部２１と、記憶部２２（記憶手段）と、制御部２３と、等を含んで構成されている。
通信部２１は、例えばＬＡＮ等を介してネットワークに接続されており、ネットワーク上の他の機器と通信する。

記憶部２２は、例えばメモリ、ハードディスク等により構成されたデータ記録装置である。この記憶部２２は、サーバ装置２０における各種処理を実施するために必要な各種プログラム及びデータを記憶している。この記憶部２２は、各種データとして、例えば、ユーザデータベース２２１、アイテムデータベース２２２、及び、課金データベース２２３を記憶している。

ユーザデータベース２２１は、各ユーザのユーザＩＤと、当該各ユーザに関する情報（ユーザ情報）と、のそれぞれが関連付けられて構成される。ユーザ情報は、例えば、ユーザのプロフィールデータや、ユーザによる投稿やメッセージ等を含むコンテンツデータや、ユーザ間の関連付けの有無を示す関係性情報や、ユーザを表わすアバターを構成している各アイテムの情報（アイテム情報）を含むキャラクタデータや、ユーザに対して付与された特典（例えばポイント等）に関する情報（特典情報）等を含む。

なお、関係性情報とは、ＳＮＳ等において所謂「フォロー登録」「お気に入り登録」「友達登録」等と称され、例えば、対象ユーザの投稿データを抽出して閲覧させたり、対象ユーザが投稿データを更新した際に通知を送信させたりする旨を示すデータである。また、本実施形態では、関係性情報として、さらに、対象のユーザの顔を知っているか否かを示すフラグデータ等が含まれていてもよい。例えば、相互にフラグデータが登録されている、つまり相互に関連付けがなされたユーザ同士は、顔見知りであると判定可能となる。

アイテムデータベース２２２は、アバターを作成するアイテムに関する情報により構成される。ここで、アバターを作成するアイテムとして、例えば、目、鼻、口、顔の輪郭、髪型、及び眉等の、アバターの顔を構成する複数の部位（区分）に分類され、各区分について一つ又は複数のアイテム（要素）が登録されている。また、顔以外にも、衣服や装身具等の服飾品や、アバターの動作や、アバターとともに表示される背景画像等も、アイテムとして登録されている。
課金データベース２２３は、アイテムデータベース２２２に登録された有料アイテムを購入した際等の課金対象となる処理を行ったユーザのユーザＩＤと、課金額とが関連付けられて記憶されている。

制御部２３は、ＣＰＵ等の演算回路、ＲＡＭ等の記憶回路により構成され、記憶部２２等に記憶されているプログラム（ソフトウェア）をＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働で、各種処理を実行する。そして、制御部２３は、上記各種処理を実行することで、図２に示すように、提案受付部２３１、評価処理部２３２、アバター管理部２３３、アイテム販売部２３４、及び特典管理部２３５等として機能する。

提案受付部２３１は、ユーザ端末１０の変更提案部１５２によって生成され、当該ユーザ端末１０から送信された変更提案を受け付ける。
評価処理部２３２は、変更提案が成されたアバターを所有するユーザ（所有ユーザ）、すなわち提案対象のユーザに、変更提案を他のユーザに評価させるか否かの判定を実施させる。また、評価処理部２３２は、変更提案に対する評価が実際される場合、他のユーザに対して評価依頼を行い、評価結果を取得する。

アバター管理部２３３は、本発明のキャラクタ設定部に相当し、各ユーザのアバターの管理を行う。例えば、アバター管理部２３３は、ユーザからのアバターの設定指示に基づいて、ユーザＩＤに関連付けてアバターを構成するアイテムをユーザデータベース２２１に登録することによりアバターを設定する。また、アバター管理部２３３は、アバターの変更提案の内容に基づいて、ユーザデータベース２２１に記憶されたアバターの設定情報を更新する。

アイテム販売部２３４は、要素販売部に相当し、アバターを構成するアイテムのうち課金対象である有料アイテムをユーザに販売する販売処理を実施する。このアイテム販売部２３４は、アイテムデータベース２２２を参照して販売対象の有料アイテムの課金額を取得し、購入者であるユーザのユーザＩＤ該課金額を関連付けて課金データベース２２３に記憶する。

特典管理部２３５は、所定の条件を満たしたユーザに対して特典を付与する。例えば、特典管理部２３５は、有料アイテムを購入したユーザに対して、課金額に応じた特典を付与する。また、特典管理部２３５は、アバターの変更提案のうち、他のユーザによって支持された変更提案を行ったユーザに対して特典を付与する。

［アバター設定処理］
次に、上述のようなアバター設定システム１におけるアバター設定処理について、図面に基づいて説明する。
図３は、アバター設定システム１におけるアバター設定処理の流れを模式的に示す図である。図４は、サーバ装置２０におけるアバター設定処理の一例を示すフローチャートである。図５は、変更提案を評価するための評価画像の一例を模式的に示す図である。
本実施形態では、図３に示すように、ユーザ端末１０は、変更提案の対象となるアバターによって表現されたユーザ（対象者）が操作するユーザ端末１０Ａと、当該アバターの変更提案を行うユーザ（提案者）が操作するユーザ端末１０Ｂと、アバターの変更提案を評価するユーザ（評価者）が操作するユーザ端末１０Ｃと、を含む。なお、図３ではユーザ端末１０Ｃは、一つのみ図示しているが、複数の評価者のそれぞれのユーザ端末１０Ｃを含みアバター設定システム１が構成される。
また、本実施形態では、提案者及び評価者は、ユーザデータベース２２１の関係性情報が、対象者と「相互フォロー」の関係にある、つまり対象者と相互に関連付けがなされたユーザである。なお、ユーザデータベース２２１に知り合いか否かのフラグデータが登録されている場合は、相互にフラグデータが登録された顔見知りの関係にあるユーザを、提案者及び評価者としてもよい。

図４に示すように、サーバ装置２０の提案受付部２３１は、ユーザ端末１０Ｂからアバターの変更提案を受け付ける（ステップＳ１）。
すなわち、ユーザ端末１０Ｂの変更提案部１５２は、提案者による操作に基づいて、変更提案の対象となるユーザ（対象者）と、当該対象者のアバターにおいて変更を提案する要素と、を選択することにより変更提案を生成する。そして、ユーザ端末１０Ｂは、図３の矢印１に示すように、生成した変更提案（データ）をサーバ装置２０に送信する。提案受付部２３１は、当該変更提案を受信することにより、ユーザ端末１０Ｂからの変更提案を受け付ける。

この際、ユーザ端末１０Ｂは、提案者に対して、サーバ装置２０のユーザデータベース２２１を適宜参照させ、相互フォローの関係にあるユーザ（若しくは顔見知りフラグ有）に対して変更提案を実施させる。例えば、ユーザ端末１０Ｂにおいて、ユーザ（対象者）のプロフィールデータやコンテンツデータを表示させる際に、対象者のアバターと、当該アバターの近傍に配置された「変更提案」を行う旨のアイコン等と、を含む画像を表示させる。そして、提案者によって「変更提案」が選択されると、ユーザ端末１０Ｂは、サーバ装置２０からアイテムデータベース２２２を取得して、若しくは予め取得しておいたアイテムデータベース２２２を参照して、変更するアイテムを表示させる。提案者によっていずれかのアイテムが選択されることにより、ユーザ端末１０Ｂは、変更先のアイテムを特定する。

次に、サーバ装置２０の評価処理部２３２は、変更提案を受け付けた旨を示す通知（変更提案通知）を対象者に送信する（ステップＳ２）。この変更提案通知には、変更提案に対する評価処理を実施するか否かの判定を促す情報も含まれる。
このステップＳ２では、サーバ装置２０は、図３の矢印２に示すように、変更提案通知を、変更提案が提起された対象者のユーザ端末１０Ａに送信する。ユーザ端末１０Ａは、受信した変更提案通知を表示部１１に表示させる。これにより、対象者は変更提案の内容を把握できる。また、ユーザ端末１０Ａは、変更提案の評価を実施するか否かの判定を対象者に行わせ、図３の矢印３に示すように、変更提案の評価の実施可否を指示する実施可否通知をサーバ装置２０に送信する。例えば、ユーザ端末１０Ａは、変更提案の評価処理を実施するか否かを問う選択画面を表示させ、対象者が当該選択画面において、評価処理を実施する旨の選択をすると、評価処理の実施を許可する旨の実施可否通知を、評価処理を実施しない旨の選択をすると、評価処理の実施を許可しない旨の実施可否通知をサーバ装置２０に送信する。

次に、評価処理部２３２は、変更提案の評価処理を実施するか否かについて判定する（ステップＳ３）。
評価処理部２３２は、ユーザ端末１０Ａから評価の実施を許可する旨の実施可否通知を受信している場合、ステップＳ３でＹＥＳと判定し、実施を許可しない旨の実施可否通知を受信している場合、ＮＯと判定する。ステップＳ３でＮＯと判定されると、本フローによる処理が終了される。
なお、本実施形態では、変更提案が行われた場合に、対象者に評価の実施可否を判定させているが、これに限らない。例えば、評価処理部２３２は、予め設定された判定条件に基づいて、実施の可否を判定してもよい。例えば、所定のユーザからの提案である場合や、アバター変更から所定期間が経過していない場合等の所定の禁止条件を予め設定してもよい。また、変更提案があった場合は、必ず評価処理が実施されてもよい。

ステップＳ３でＹＥＳと判定されると、次に、評価処理部２３２は、複数の評価者による変更提案への評価結果を取得する評価処理を実施する（ステップＳ４）。
まず、評価処理部２３２は、評価処理として、図３の矢印４に示すように、評価者のユーザ端末１０Ｃに対して評価実施要求を行う。例えば、評価処理部２３２は、相互フォローの関係にあるユーザや、顔見知りフラグがあるユーザ等の所定のユーザを評価者とする。そして、評価処理部２３２は、評価者のユーザ端末１０Ｃに評価実施要求（データ）を出力する。この評価実施要求には、例えば、対象者のユーザＩＤ、対象者の現在のアバター（データ）、変更提案により提案されたアバター（データ）が含まれる。これにより、ユーザ端末１０Ｃは図５に示すような変更提案を評価させる旨の評価画像３０を表示部１１に表示させる。

図５に示すように、評価画像３０は、所定の領域Ａｒ１に表示された現在のアバター３１と、領域Ａｒ２に表示された変更提案に基づく変更後のアバター３２と、を同時に含む。また、評価画像３０には、評価者に対して、対象者を表すアバターとして適切なアバターを、アバター３１及びアバター３２のいずれかから選択させるためのテキスト情報３３が含まれる。
評価実施部１５３は、この評価画像３０に対して、評価者の入力操作部１２の操作により、アバター３１及びアバター３２のいずれかを選択する旨の操作が行われる（例えば、領域Ａｒ１，Ａｒ２に対するタップ操作やクリック操作等が検出される）と、評価結果（又は、例えば「変更前のアバターを選択」や「変更後のアバターを選択」といった選択結果を示すデータ）を含む評価内容通知（データ）をサーバ装置２０に送信する。

つまり、ステップＳ３の評価処理では、評価実施要求を受けたユーザ端末１０Ｃの評価実施部１５３は、図３の矢印５に示すように、評価者の操作に基づいて、変更提案に対する評価を行い、評価結果をサーバ装置２０に通知する。
そして、評価処理部２３２は、例えば、評価実施要求に対する回答率が所定値以上となった場合や、所定の期間が経過した場合等のように、予め設定された評価終了条件が満たされた場合に、評価処理を終了させる。なお、評価処理部２３２は、例えば、所定の期間が経過しても回答率が上記所定値以上とならなかった場合、今回の変更提案を不成立としてもよい。

図４に戻り、評価処理部２３２は、ユーザ端末１０Ａ，１０Ｂ，１０Ｃのそれぞれに全体評価結果を通知する（ステップＳ５）。つまり、評価処理部２３２は、複数のユーザ端末１０Ｃから取得された評価結果（個別評価結果）を用いて、変更提案に対する全体評価結果を取得し、図３の矢印６に示すように、当該全体評価結果（データ）をユーザ端末１０Ａ，１０Ｂ，１０Ｃのそれぞれに送信する。
評価処理部２３２は、例えば、全ての個別評価結果のそれぞれが、変更前のアバターを選択した旨を示す評価結果か、変更後のアバターを選択した旨を示す評価結果かに基づいて、変更前と変更後とのいずれのアバターがより多くの評価者に選択されたかを示す全体評価結果を出力する。また、全体評価結果は、例えば、より多くの評価者に選択されたアバターや、変更前と変更後とのそれぞれのアバターを選択した評価者の数や割合を示す情報（データ）である。また、全体評価結果は、例えば、変更前と変更後とのそれぞれのアバターを選択した評価者の数や割合を示すグラフ等の画像情報（データ）である。

ここで、全体評価結果が変更提案を支持する内容である場合、評価処理部２３２は、対象者のユーザ端末１０Ａに対して、全体評価結果の通知とともに、変更提案を受け入れてアバターの変更を行うか否かを判定させる判定情報を含む変更判定通知を送信する。なお、対象者には、全体評価結果と判定情報とを含む一つの通知を送信してもよい。
ユーザ端末１０Ａのアバター設定部１５１は、変更判定通知の受信に応じて、図３の矢印７に示すように、対象者の操作に基づいてアバター変更の可否を指示する変更可否通知をサーバ装置２０に送信する。例えば、ユーザ端末１０Ａは、変更提案に基づいてアバターを変更するか否かを問う選択画面を表示させ、対象者が当該選択画面において、変更する旨の選択をすると、変更を許可する旨の変更可否通知を、変更しない旨の選択をすると、変更を許可しない旨の変更可否通知をサーバ装置２０に送信する。

次に、アバター管理部２３３は、変更提案の内容に基づいてアバターを変更する必要があるか否かを判定する（ステップＳ６）。例えば、全体評価結果が、変更前よりも変更提案に基づく変更後のアバターを支持する内容であり、かつ、変更提案に基づくアバターの変更が許可されている場合に、アバター管理部２３３は当該ステップＳ６でＹＥＳと判定する。一方、全体評価結果が変更提案を指示しない（つまり変更後よりも変更前のアバターを支持する）内容である場合や、アバター変更が許可されていない場合に、アバター管理部２３３は、ステップＳ６でＮＯと判定する。

ステップＳ６でＹＥＳと判定されると、アバター管理部２３３は、ユーザデータベース２２１及びアイテムデータベース２２２を参照して、変更対象のアイテムが、対象者が所有していない有料アイテムであるか否かを判定する（ステップＳ７）。
ステップＳ７でＹＥＳと判定されると、アイテム販売部２３４は、アイテムの販売処理を実施する（ステップＳ８）。すなわち、アイテム販売部２３４は、アイテムデータベース２２２を参照し、変更対象アイテムの課金額を取得する。そして、アイテム販売部２３４は、ユーザデータベース２２１における対象者の所有アイテムに、当該変更対象アイテム（アイテムを識別するためのアイテムＩＤ）を追加する。また、アイテム販売部２３４は、当該変更対象アイテムの購入者に対する課金処理を行う。

課金処理として、アイテム販売部２３４は、購入者のユーザＩＤ、購入したアイテム名、及び課金額を関連付けて、課金データベース２２３に記憶する。本実施形態では、アイテム販売部２３４は、変更提案に伴うアイテム購入時では、通常のアイテム購入時に対して減額して課金処理を実施してもよい。これにより、変更対象のアイテムが有料の場合でも、対象者が変更提案を受け入れ易くできる。
なお、実際の決済処理としては、公知の方法を用いることができ、例えば、所定タイミングで、課金データベース２２３に基づいた請求データをユーザ端末に送信したり、ユーザにより指定された決済用サーバ装置（例えばクレジットカード会社等や、携帯電話等の電気通信を提供する電気通信事業者が運営する装置）に送信したりする。

ステップＳ７でＮＯと判定された場合、又はステップＳ８の処理が実施された場合、次に、アバター管理部２３３は、変更提案の内容に基づいて、対象者のアバターを変更する（ステップＳ９）。すなわち、アバター管理部２３３は、ユーザデータベース２２１における対象者のアバター情報のうち、変更後のアバターに対応する情報に更新する。なお、変更対象のアイテムがユーザデータベース２２１の対象者の所有アイテムに含まれない場合、アバター管理部２３３は、当該変更対象のアイテムをユーザデータベース２２１の対象者の所有アイテムに追加する。

次に、特典管理部２３５は、特典の付与対象であるユーザに特典を付与する特典付与処理を実施する（ステップＳ１０）。
特典管理部２３５は、例えば、評価処理によって支持された変更提案を行った提案者や当該変更提案を支持した評価者に対して特典を付与する。特典としては、例えば、アイテム等と交換可能なポイントの付与が例示できる。この場合、特典管理部２３５は、付与対象のユーザのユーザＩＤに関連付けられたポイントに特典ポイントを加算し、ユーザデータベース２２１を更新する。また、特典管理部２３５は、変更提案に基づいて、対象者に対する新たな有料アイテムの販売処理が実施された場合に、当該対象者とともに、提案者に対しても特典を付与する。

［第一実施形態の作用効果］
本実施形態では、サーバ装置２０では、提案受付部２３１は、アバターに対する変更提案を受け付け、評価処理部２３２は、変更が提案されたアバターの所有者（対象者）以外の他のユーザ（評価者）に対して、変更提案についての評価を行わせた結果（評価結果）を取得する。これにより、現在のアバターが適切なアバター（例えば自らの特徴や雰囲気を表すアバター）であるか否かや、より適切なアバターへの変更方法を示す評価結果を、対象者に提供することができる。したがって、対象者は、自らの判断で適切なアバターを作成することが困難な場合であっても、評価結果に基づいてアバターを設定することにより、より適切なキャラクタへの変更を容易に行うことができる。

また、本実施形態では、サーバ装置２０は、対象者をフォローするユーザ（つまり、少なくとも対象者の外見を知っているユーザ）を提案者及び評価者とし、提案者からの変更提案に対して、複数の評価者からの評価結果を取得し、複数の評価結果から全体評価結果を算出する。これにより、対象者は、顔見知りの他のユーザからの変更提案と、当該変更提案に対する評価結果とを取得することができる。したがって、対象者は、自らの特徴を把握できていなくとも、より適切なアバターへの変更を容易に行うことができる。

また、サーバ装置２０は、現在のアバター３１と、変更提案に基づく変更後のアバター３２と、を含む評価画像３０をユーザ端末１０に表示させる。したがって、評価者は、当該評価画像３０を参照することにより、各アバター３１，３２を容易に視認できる。また、評価者は、各アバター３１，３２の比較作業を容易に行うことができる。

また、アバター管理部２３３は、変更提案による変更後のアバターの方が現在のアバターよりも評価が高い場合で、かつ、対象者によるアバター変更の指示があった場合に、変更提案に基づいてアバターを変更する。この際、対象者が所有していない有料アイテムへの変更を提案する変更提案であった場合、アイテム販売部２３４は、対象者に対して課金処理を実施する。これにより、対象者が自らの判断で購入する可能性が低かった有料アイテムを、対象者に購入させる機会を増大させることができる。この際、課金額を減額することにより、対象者が変更提案を受け入れやすくすることができ、より有料アイテムの購入機会を増大させることができる。また、アイテム購入による対象者への負担が軽減されることにより、提案者も変更提案を実施し易くなる。

また、アイテム販売部２３４は、変更提案に伴うアイテム購入時の課金額を、通常のアイテム購入時の課金額よりも低い額に設定する。これにより、変更対象のアイテムが有料の場合でも、対象者が変更提案を受け入れ易くでき、対象者が有料アイテムを購入する可能性を増大させることができる。

また、特典管理部２３５は、変更提案による変更後のアバターの方が現在のアバターよりも評価が高い場合に、当該変更提案を提起した提案者や、当該変更提案を支持した評価者に特典を付与する。このように、複数の評価者によって高い評価を受けた変更提案を行った提案者に特典を付与することにより、変更提案の提起を促すことができる。また、多数の評価者に高い評価を受けた変更提案を支持した評価者に特典を付与することにより、評価依頼に対する回答率を向上させることができる。

また、特典管理部２３５は、変更提案に基づいて、対象者が新たに有料アイテムを購入した場合に、購入者である対象者に特典を付与する。これにより、有料アイテムを購入する必要がある場合でも、対象者が変更提案を受け入れやすくすることができる。
さらに、特典管理部２３５は、上述のように対象者が有料アイテムを購入した場合に、提案者に対しても特典を付与する。これにより、提案者に、有料アイテムを含む変更提案の実施を促すことができる。

［第二実施形態］
次に、第二実施形態について説明する。
上述の第一実施形態では、相互フォローの関係にあるユーザ間で変更提案や評価を実施していた。また、第一実施形態では、変更提案や変更提案に基づくアバター変更が対象者に許可された場合に実施されていた。これに対して、第二実施形態では、例えば、著名人等の顔が一般に広く認知されている特定のユーザに対して、他のユーザが変更提案を実施可能であり、同様の変更提案が所定数以上成された場合に評価が実施される点において主に相違している。以下の説明では、第一実施形態と同様の構成や処理については、説明を省略又は簡略化し、主に第一実施形態との相違点について説明する。

図６は、サーバ装置２０におけるアバター設定処理の一例を示すフローチャートである。
図６に示すように、サーバ装置２０の提案受付部２３１は、他のユーザから変更提案を受け付ける（ステップＳ１）。
本実施形態では、提案受付部２３１は、所謂「フォロワ数」が所定数以上や、全ユーザ数に対する所定割合以上の所定のユーザについて、任意のユーザから変更提案を受け付ける。例えば、ユーザデータベース２２１では、各ユーザのＩＤに対して、フォロワ数（ＩＤに対応するユーザに関連付けがなされた他のユーザの数）が対応付けられている。提案受付部２３１は、フォロワ数が所定数以上のユーザについては、対象者と相互フォローの関係にあるユーザ以外に、対象者と相互フォローの関係にないユーザからも変更提案を受け付ける。このような多数のユーザにフォローされているユーザは、例えば、広く顔が知られている著名人であり、提案受付部２３１は、任意のユーザからの変更提案を受け付ける。なお、ユーザデータベース２２１は、著名人であることを示すフラグデータを登録可能に構成されてもよい。

提案受付部２３１は、同一の変更提案を所定数以上受け付けたか否かを判定する（ステップＳ１１）。すなわち、提案受付部２３１は、同一のアイテムへの変更を提案する変更提案を複数受け付けた場合、当該同一の変更提案の数が所定数以上か否かを判定する。ここで、所定数とは、対象者が予め設定することができ、例えば、ＳＮＳ等において対象者のフォロワ数や、ブログサービス等における定期購読者数に対する所定割合に相当するユーザ数である。
提案受付部２３１は、所定数以上の同一の変更提案が提起されるまで（ステップＳ１１：ＮＯ）、ステップＳ１に戻り、変更提案を受け付ける。

なお、提案受付部２３１は、変更提案を受け付けていることを報知する文字や画像をＳＮＳ等のトップページに表示させるための報知情報を、他のユーザのユーザ端末１０に送信してもよい。また、サーバ装置２０は、報知情報を他のユーザのユーザ端末１０にメール配信してもよい。
また、提案受付部２３１は、予め設定された特定の禁止アイテムへの変更を提案する変更提案を提起された場合は、当該変更提案を受け付けず、かつ、提案者に当該変更提案を受け付けることができない旨の通知を行ってもよい。

所定数以上の同一の変更提案が提起されると（ステップＳ１１：ＹＥＳ）、変更提案を受け付けた旨を示す変更提案通知を対象者に送信し（ステップＳ２）、変更提案が予め設定された禁止条件に合致しない限り（ステップＳ３：ＹＥＳ）、変更提案に対する評価処理を実施する（ステップＳ４）。なお、禁止条件は、前回の評価処理から所定期間が経過していない場合や、アバター変更の禁止期間（変更禁止期間）に設定されている場合等である。
一方、サーバ装置２０は、禁止条件に合致する場合（ステップＳ３：ＮＯ）、評価処理を実施せずに、本フローに示す処理を終了させる。なお、評価処理が実施されない理由が、前回の評価処理から所定期間が経過していない場合では、所定期間の経過後に、また、変更禁止期間である場合では、変更禁止期間の終了後に、評価処理を実施するようにしてもよい。

ステップＳ４において、評価処理部２３２は、対象者が著名人であるため、任意のユーザに対して評価を実施させる。例えば、評価処理部２３２は、対象者をフォローしているユーザを評価者としてユーザ端末１０Ｃに評価実施要求を出力する。また、評価処理部２３２は、対象者をフォローしていない他のユーザのユーザ端末１０に、変更提案についての評価を依頼する旨の依頼情報を送信してもよい。この依頼情報は、例えば、評価を依頼する旨の文字や画像を表示させるための画面情報（データ）や、評価用のウェブページへのリンク等である。
なお、評価処理部２３２は、任意のユーザを評価者とするとしたが、ユーザデータベース２２１に予め登録された所定のユーザを評価者としてもよいし、当該所定のユーザを評価者から除外してもよい。

次に、評価処理部２３２は、ステップＳ４で取得した全体評価結果を通知する（ステップＳ５）。本実施形態では、評価処理部２３２は、対象者をフォローしているユーザや評価を行ったユーザのユーザ端末１０に全体評価結果を通知する。また、評価処理部２３２は、対象者をフォローしていない他のユーザにも全体評価結果を通知する。例えば、評価処理部２３２は、対象者をフォローしていない他のユーザのユーザ端末１０に、上述の全体評価結果を表示させる情報を送信したり、当該全体評価結果を表示させるためのウェブページへのリンクに関する情報を送信する。

次に、アバター管理部２３３は、全体評価結果に基づいて、他のユーザから変更提案が支持されている、つまり評価されているか否かを判定する（ステップＳ１２）。
本実施形態では、ステップＳ１２でＹＥＳと判定され、全体評価結果が変更提案を支持する内容である、つまり変更提案に基づく変更後のアバターが、変更前のアバターよりも評価が高い場合、アバター管理部２３３は、変更提案に基づくアバター変更を行う。一方、ステップＳ１２でＮＯと判定される場合、アバター管理部２３３は、変更提案に基づくアバター変更を行わない。

ステップＳ１２でＹＥＳと判定されると、アバター管理部２３３は、変更対象のアイテムが有料アイテムであるか否かを判定する（ステップＳ７）。
ステップＳ７でＹＥＳと判定されると、アイテム販売部２３４は、アイテムの販売処理を実施する（ステップＳ８）。
このステップＳ８において、アイテム販売部２３４は、アイテムデータベース２２２を参照し、変更対象アイテムの課金額を取得する。そして、アイテム販売部２３４は、ユーザデータベース２２１の対象者の所有アイテムに、当該変更対象アイテムを追加する。
また、アイテム販売部２３４は、当該変更対象アイテムの購入者として提案者に対する課金処理を行う。つまり、提案者は、変更対象アイテムが有料アイテムである場合、対象者へのプレゼントとして有料アイテムを購入する。一方、対象者のアバターは、提案者からプレゼントされたアイテムを含むアバターに変更される。

次に、特典管理部２３５は、特典の付与対象であるユーザに特典を付与する特典付与処理を実施する（ステップＳ１０）。特典管理部２３５は、例えば、第一実施形態と同様に、評価処理によって支持された変更提案を行った提案者や、当該変更提案を支持した評価者に対して特典を付与する。また、特典管理部２３５は、変更提案に応じて、有料アイテムを購入した提案者に対して、購入金額に応じた特典を付与する。

また、特典管理部２３５は、提案者に対して特典アイテムを付与してもよい。このような特典アイテムは、通常アイテムとして入手したり購入したりすることができない又は容易ではないアイテムである。例えば、対象者が著名人である場合、当該対象者及び提案者のアバターが並んで表示された画像や、当該対象者に関連するアイテム等である。

［第二実施形態の作用効果］
評価処理部２３２は、所定数以上のユーザに関連付けられた対象者（例えば著名人）については、任意のユーザからも評価結果を取得する。これにより、著名人等のように広く顔が知られている対象者は、自らがフォローしていない他のユーザや、自らをフォローしていない他のユーザからも、広く変更提案についての評価を取得することができる。
また、アバター管理部２３３は、変更提案による変更後のアバターの方が現在のアバターよりも評価が高い場合に、変更提案に基づいてアバターを変更する。この際、対象者が所有していない有料アイテムへの変更を提案する変更提案であった場合、アイテム販売部２３４は、提案者に対して課金処理を実施する。つまり、提案者は、有料アイテムを対象者へのプレゼントとして購入する。そして、対象者のアバターは、提案者からプレゼントされたアイテムを含むアバターへ変更される。したがって、提案者は、プレゼントしたアイテムが対象者のアバターに適用されることによる満足感を得ることができ、変更提案の増大によるシステムの活性化を図ることができる。

［第三実施形態］
次に、第三実施形態について説明する。
上述の第一実施形態では、サーバ装置２０は、提案者からの変更提案を受け付けると、当該変更提案の内容に沿って評価処理を実施していた。これに対して、第三実施形態では、サーバ装置２０は、提案者に対して、変更提案とは異なる他の提案（追加変更提案）を促す点で相違している。以下の説明では、第一実施形態と同様の構成や処理については、説明を省略又は簡略化し、主に第一実施形態との相違点について説明する。

図７は、提案者のユーザ端末１０Ｂとサーバ装置２０とによる変更提案処理を示す図である。図８は、変更提案を評価するための評価画像の一例を模式的に示す図である。
図７に示すように、ユーザ端末１０Ｂの変更提案部１５２は、ユーザ操作に基づいて、変更提案をサーバ装置２０に出力する（ステップＳ２１）。

サーバ装置２０の提案受付部２３１は、変更提案を受信し（ステップＳ３１）、その後、変更が提案された部位に関連する他の部位についても変更提案を促す追加提案要求（データ）をユーザ端末１０Ｂに出力する（ステップＳ３２）。
ステップＳ３２では、例えば、提案受付部２３１は、変更提案が、アバターを構成する複数の部位のうちの顔の輪郭についての提案である場合、顔の輪郭に関連する部位として、顔を構成する複数の部位のいずれかの部位についての追加提案要求を送信する。より具体的には、提案受付部２３１は、例えば髪型についても変更提案を促す旨の画面として、「髪型はどうですか」といった文字情報等を表示させる追加提案要求を送信する。
ここで、アイテムデータベース２２２には、部位間の関連度（例えば、５段階評価で数値が大きいほど関連性が高くなるように設定された数値）が登録されていてもよい。この際、互いに位置が近い部位は、互いに関連度が高い部位として登録されてもよい。また、アバター本体、アバターの装飾品、及び、動作等の各属性にアイテムを区分した際に、同じ属性を有するアイテムについての追加提案要求を送信してもよい。

なお、提案受付部２３１は、変更提案に関連する追加提案要求を送信するとしたが、これに限らず、変更提案とは関連性が低い部位や属性についての追加提案要求を送信してもよく（例えば顔についての変更提案を受けた際に服装についての追加提案を要求する等）、これにより変更提案に基づくアバター変更の選択肢を多くすることができる。また、提案受付部２３１は、追加提案を要求するアイテムが属する部位や属性を制限せずに、単に、別の変更提案を要求するだけでもよい。

変更提案部１５２は、追加提案要求を受信し（ステップＳ２２）、当該追加提案要求に基づいて追加提案を生成し、サーバ装置２０に出力する（ステップＳ２３）。変更提案部１５２は、追加提案要求が例えば髪型に対する提案を促す内容である場合、変更提案を生成するのと同様に、提案者による操作に基づいて、髪型に対する変更を提案する追加提案を生成し、サーバ装置２０に出力する。なお、追加提案がない場合、変更提案部１５２は、追加提案を実施しない旨の情報を追加提案として出力する。

提案受付部２３１は、追加提案を受信し（ステップＳ３３）、追加提案の内容を含む変更提案を受け付ける（ステップＳ３４）。すなわち、提案受付部２３１は、ステップＳ３１で受信した最初の変更提案と、ステップＳ３３で受信した追加提案とに基づいて、最終的な変更提案を受け付ける。
そして、サーバ装置２０は、図４のステップＳ２以降の処理を実施する。

追加提案がなされている場合、サーバ装置２０の評価処理部２３２は、評価処理の際に（図４のステップＳ４）、図８に示すように、変更提案及び変更提案に基づくアバターを含む評価画像３０Ａをユーザ端末１０に表示させる。この評価画像３０Ａは、現在のアバター３１の他、変更提案に基づく変更後のアバターとして、最初の変更提案（第一提案）に基づく第一変更アバター３２Ａと、追加提案（第二提案）に基づく第二変更アバター３２Ｂと、上記第一提案及び第二提案に基づく第三変更アバター３２Ｃと、を含む。なお、図８に示す例では、現在のアバター３１に対して、第一変更アバター３２Ａは顔の輪郭が、第二変更アバター３２Ｂは髪型が、第三変更アバター３２Ｃは第一提案（顔の輪郭）及び第二提案（髪型）の両方の変更点が、それぞれ変更されている。
評価実施部１５３は、この評価画像３０Ａに対して、評価者の入力操作部１２の操作により、アバター３１，３２Ａ，３２Ｂ，３２Ｃのいずれかを選択する旨の操作が行われると、評価結果を含む評価内容通知をサーバ装置２０に送信する。

［第三実施形態の作用効果］
提案受付部２３１は、変更提案を受信すると、当該変更提案に関連する部位や属性についての追加提案を促す追加提案要求をユーザ端末１０Ｂに出力する。追加提案要求を受信したユーザ端末１０Ｂの提案受付部２３１は、ユーザの指示に基づいて上記関連する部位や属性についての追加提案を、サーバ装置２０に出力する。そして、サーバ装置２０は、変更提案と追加提案との内容に基づいて評価処理を行う。このような構成では、一度の変更提案において、複数の要素についての変更提案を受け付けることができ、かつ、当該変更提案に対する評価を得ることができる。したがって、より適切なアバターへの変更を、より短期間で行うことができる。

また、提案受付部２３１は、最初に受けた変更提案に関連する部位や属性についての追加提案を要求するため、関連性が高い複数の要素について同時に変更提案を促すことができる。これにより、対象者をより適切に表わすアバターへの変更を、より効果的に行うことができる。

［第四実施形態］
次に、第四実施形態について説明する。
上述の第三実施形態では、サーバ装置２０は、変更が提案された部位や属性（区分）とは異なる部位や属性に対する追加の変更提案を行うことを提案者に要求していた。これに対して、第四実施形態では、サーバ装置２０が、変更が提案された部位や属性について、提案されたアイテムとは異なるアイテムへの変更案（追加提案）を具体的に提示する点で、第三実施形態とは相違している。以下の説明では、第三実施形態と同様の構成や処理については、説明を省略又は簡略化し、主に第三実施形態との相違点について説明する。

図９は、提案者のユーザ端末１０Ｂとサーバ装置２０とによる変更提案処理を示す図である。
図９に示すように、ユーザ端末１０Ｂの変更提案部１５２は、変更提案をサーバ装置２０に出力する（ステップＳ２１）。
サーバ装置２０の提案受付部２３１は、変更提案を受信し（ステップＳ３１）、その後、追加提案を生成して、ユーザ端末１０Ｂに出力する（ステップＳ３５）。
提案受付部２３１は、例えば、変更提案によって提案されているアイテムに類似するアイテムへの変更を提案する追加提案を生成する。より具体的には、例えば、アイテムデータベース２２２には、同一の部位や、属性（装飾品や動作等）に属する複数のアイテム間の類似度が予め登録されている。そして、提案受付部２３１は、変更提案が、アバターを構成する複数の部位のうちの例えば目についての変更を提案している場合、アイテムデータベース２２２を参照して、変更提案において提案された目との類似する他の目への変更を選択し、追加提案を生成する。提案受付部２３１は、類似するアイテムを選択する際に、類似度が所定値以上のアイテムからランダムに１又は複数のアイテムを選択してもよいし、類似度が最も高いアイテムを選択してもよい。

なお、提案受付部２３１は、変更提案がなされたアイテムの類似アイテムについての追加提案を行うことに限らず、変更提案がなされたアイテムと類似しないアイテムについての追加提案を行ってもよい。例えば、提案受付部２３１は、目についての変更提案において、提案された目がつり目である場合、これと類似しない目、例えばたれ目への変更を提案する。これにより、提案者及び対象者のいずれも選択しなかったアイテムを含むアバターを評価対象とすることができ、評価範囲を拡大することができる。

ユーザ端末１０Ｂの変更提案部１５２は、追加提案を受信し（ステップＳ２４）、追加提案の内容を変更提案に追加するか否かを判定する（ステップＳ２５）。
この追加提案には、追加提案を実施するか否かの判定を促す情報も含まれる。ステップＳ２５では、変更提案部１５２は、追加提案を実施するか否かを選択させる選択画面を表示部１１に表示させる。そして、変更提案部１５２は、提案者による操作に基づいて、追加提案を実施するか否かを示す判定結果（データ）を取得する。なお、判定結果として、例えば、サーバ装置２０による追加提案のみについての変更提案を実施する旨の指示を、サーバ装置２０に出力してもよい。
変更提案部１５２は、判定結果をサーバ装置２０に出力する（ステップＳ２６）。

サーバ装置２０の提案受付部２３１は、判定結果を受信し（ステップＳ３６）、変更提案及び判定結果の内容に基づいて、変更提案を受け付ける（ステップＳ３７）。
このステップＳ３７では、提案受付部２３１は、例えば、追加提案を実施する旨の判定結果を受信した場合、追加提案の内容を含む変更提案を受け付け、追加提案を実施しない旨の判定結果を受信した場合、最初に提案された変更提案のみを受け付ける。

そして、サーバ装置２０は、図４のステップＳ２以降の処理を実施する。なお、評価処理の際は、現在のアバター３１の他、変更提案に基づく変更後のアバターとして、最初に提案された変更提案に対応するアバターと、追加提案に対応するアバターと、のそれぞれが表示される。

［第四実施形態の作用効果］
提案受付部２３１は、変更提案を受信すると、当該変更提案において変更が提案された部位や属性についての他のアイテムへの変更を提案する追加提案をユーザ端末１０Ｂに出力する。サーバ装置２０は、追加提案の内容を含む評価処理の実施がユーザ端末１０Ｂによって許可された場合は、最初の変更提案と追加提案とに基づいて評価処理を行う。このような構成では、変更提案を受けた部位や属性について、提案者が選択したアイテムとは異なるアイテムを評価対象とすることができる。したがって、評価者による評価範囲を拡大させることができる。

また、提案受付部２３１は、提案者が選択したアイテムに類似したアイテムを追加提案として出力する。このような構成では、提案受付部２３１は、提案者が行った変更提案に基づいて、より適切な追加提案を行うことができる場合がある。したがって、より適切な変更提案が行われる機会を増大させることができる。

［第五実施形態］
次に、第五実施形態について説明する。
上述の第一実施形態では、相互フォローの関係にあるユーザに対して評価を実施させる際に、変更前と変更後との両方のアバターを表示させ、いずれのアバターが対象者を表わすアバターとして適切かを、評価者に選択させていた。これに対して、第五実施形態では、現在のアバターを表示させず、変更後のアバターのみを表示させ、表示されたアバターがどのユーザを表わすかを、評価者がフォローするユーザから選択させる点で相違する。以下の説明では、第一実施形態と同様の構成や処理については、説明を省略又は簡略化し、主に第一実施形態との相違点について説明する。

図１０は、変更提案を評価するための評価画像の一例を模式的に示す図である。
図４に示すように、サーバ装置２０の評価処理部２３２は、ユーザ端末１０Ｂからの変更提案に基づいて、評価処理を実施する（ステップＳ４）。
本実施形態では、評価処理部２３２は、評価実施要求（図４のステップＳ４参照）を送信し、図１０に示す評価画像３０Ｂをユーザ端末１０Ｃに表示させる。この評価画像３０Ｂは、変更後のアバター３２と、当該アバター３２がどのユーザを表わすアバターかを選択させるためのタグ３４と、を含む。
例えば、評価処理部２３２は、ユーザデータベース２２１を参照して、対象者以外のユーザ（ユーザＩＤ）を取得し、対象者（Ａさん）と、対象者以外のユーザ（Ｂさん、Ｃさん、及びＤさん）とを含む複数のユーザを選択させるためのタグ３４を含む評価画像３０Ｂを生成する。
なお、評価処理部２３２は、対象者に類似するユーザを対象者以外のユーザとして選択してもよい。例えば、評価処理部２３２は、性別、年齢（年代）、国籍、及び職業等の複数の属性に基づいて対象者との類似度を算出し、類似度が高いユーザを選択してもよい。

評価実施要求を受けたユーザ端末１０Ｃの評価実施部１５３は、ユーザの入力操作に基づいて、ユーザの選択結果を検出し、当該選択結果（選択されたユーザＩＤを含むデータ）をサーバ装置２０に出力する。そして、サーバ装置２０は、図４に示す処理のステップＳ５以降の処理を実施する。

［第五実施形態の作用効果］
評価処理部２３２は、変更提案に基づく変更後のアバター３２と、当該アバター３２がどのユーザを表わすアバターかを選択させるためのタグ３４と、を含む評価画像３０Ｂをユーザ端末１０Ｃに表示させる。評価者は、変更後のアバター３２のみを参照しながら、アバター３２に対応するユーザを選択することとなる。このため、変更前のアバターに関わらず、変更後のアバター３２が対象者の特徴を表わしているか否かの評価を、評価者に行わせることができる。
また、タグ３４に対象者（Ａさん）以外の複数のユーザ（Ｂさん、Ｃさん、及びＤさん）として、対象者と類似するユーザを選択可能に表示させる。これにより、変更後のアバター３２に対する評価精度を向上させることができる。

［変形例］
なお、本発明は、上述した実施形態に限定されるものではなく、本発明の目的を達成できる範囲で、以下に示される変形をも含むものである。

上記各実施形態では、変更提案を対象者以外の他のユーザが行う場合について例示したが、本発明はこれに限定されない。例えば、アバターによって表現されるユーザ自信が変更提案を行ってもよい。つまり、対象者と提案者とが同一でもよく、この場合でも、他のユーザによって変更提案を評価させることができるため、より適切なアバターへの変更を行うことができる。なお、他のユーザからの変更提案を受け付けることにより、対象者自信が変更提案を行う場合よりも、変更提案の精度の向上を図ることができる。

上記各実施形態では、提案者が一つの要素の変更を提案する変更提案を実施する場合について例示したが、同時に複数の要素を変更する変更提案を実施してもよい。また、互いに異なる複数の変更提案を同時期に受け付けた場合、これら複数の変更提案を個別に評価させてもよいし、同時に評価させてもよい。

上記第一から第四実施形態において、評価画像は、現在のアバターと、変更提案に基づく変更後のアバターとを含み構成されていたが、本発明はこれに限定されない。例えば、評価画像は、少なくとも変更提案に基づく変更後のアバターを含み、現在のアバターを含まなくてもよい。このような場合でも、ユーザ端末１０Ｃは、変更後のアバターを評価者に視認させることができ、変更提案に対する適切な評価結果を取得することができる。なお、ユーザ端末１０Ｃが、変更後のアバターが対象者のアバターとして適しているか否かを示す評価情報をサーバ装置２０に送信する。ここで、変更提案に基づくアバターが複数存在する場合、ユーザ端末１０Ｃは、評価者によって選択されたアバター（アバターＩＤ等）を示す情報、及び、いずれのアバターも適切じゃない旨を示す情報を少なくとも含む評価情報を送信すればよい。

上記各実施形態では、変更提案として具体的なアイテム（要素）を変更する提案を行う場合について例示しているが、これに限定されず、具体的なアイテムを選択する代わりに、アイテムの特徴を提案してもよい。例えば、現在の目よりももっとたれ目のパーツに変更した方がよい等である。これにより、具体的なパーツを選択させる場合よりも簡単に変更提案を行わせることができる。

上記各実施形態では、サーバ装置２０は、変更提案としてアバターの頭部を構成するアイテムの変更を受け付ける場合について例示したが、これに限定されない。例えば、サーバ装置２０は、変更提案として、アバターの他の部位や装飾品や背景等の変更の提案を受け付けてもよい。また、アバターが動作を要素として含む場合、サーバ装置２０は、対象者の特徴を表わす動作を要素に追加する提案を変更提案として受け付けてもよい。

上記第一実施形態では、有料アイテムの購入者を対象者とし、第二実施形態では、有料アイテムの購入者を提案者としたが、本発明はこれに限らず、購入者は、提案者及び対象者のいずれでもよく、また、提案者及び対象者以外の他のユーザであってもよい。また、変更提案を生成する際に、ユーザによって購入者を選択可能としてもよい。
なお、提案者を購入者とすることにより、変更対象のアイテムが有料アイテムであっても、対象者が変更提案を受け入れてアバターの変更を実施し易くできる。また、提案者以外を購入者とすることにより、提案者が変更提案を実施し易くできる。

上記各実施形態では、ＳＮＳ等において、ユーザの画像の代りに表示されるアバターを設定する場合について例示したが、これに限定されない。例えば、オンラインゲーム等においてユーザが設定可能なキャラクタの設定を、変更提案に基づいて、他のユーザに評価させ、評価結果に基づいて変更させる場合にも、本発明を適用することができる。例えば、キャラクタの能力や装備等の要素をユーザが設定可能である場合、サーバ装置２０は、現在の設定に対して変更提案を受け、他のユーザからの評価を受けるように構成してもよい。これにより、対象者は、評価結果に基づいて、キャラクタの設定をより適切な設定に変更することができる。

上記各実施形態では、本発明に係るキャラクタ評価方法及びキャラクタ評価プログラムが適用されるキャラクタ評価装置として、一つのサーバ装置２０を例示したが、これに限定されず、上述のキャラク評価装置の機能の少なくとも一つを有し、互いに通信可能に構成された複数の装置（ユーザ端末１０やサーバ装置２０）によって、キャラクタ評価装置が構成されてもよい。

その他、本発明の実施の際の具体的な構造及び手順は、本発明の目的を達成できる範囲で他の構造などに適宜変更できる。

１…アバター設定システム、１０，１０Ａ，１０Ｂ，１０Ｃ…ユーザ端末、２０…サーバ装置、２１…通信部、２２…記憶部、２３…制御部、３０，３０Ａ，３０Ｂ…評価画像、３１，３２…アバター、３２Ａ…第一変更アバター、３２Ｂ…第二変更アバター、３２Ｃ…第三変更アバター、１５１…アバター設定部、１５２…変更提案部、１５３…評価実施部、２２１…ユーザデータベース、２２２…アイテムデータベース、２２３…課金データベース、２３１…提案受付部、２３２…評価処理部、２３３…アバター管理部、２３４…アイテム販売部、２３５…特典管理部。

Claims (15)

1. 複数の要素によって構成されるキャラクタのキャラクタデータを記憶する記憶部と、
   ユーザ端末から、前記キャラクタに対する前記要素の変更提案を受け付ける提案受付部と、
   前記キャラクタを所有する所有ユーザ以外の他のユーザからの前記変更提案に対する評価結果を取得する評価処理部と、を有する
   ことを特徴とするキャラクタ評価装置。
2. 請求項１に記載のキャラクタ評価装置において、
   前記評価処理部は、変更が提案された前記要素を含む変更後の前記キャラクタを含み、前記変更提案を評価させる旨の評価画像を前記他のユーザのユーザ端末に出力する
   ことを特徴とするキャラクタ評価装置。
3. 請求項２に記載のキャラクタ評価装置において、
   前記評価処理部は、前記記憶部に記憶されている現在のキャラクタと、前記変更後のキャラクタと、のうちから前記キャラクタを選択させる旨の前記評価画像を前記他のユーザのユーザ端末に出力する
   ことを特徴とするキャラクタ評価装置。
4. 請求項２に記載のキャラクタ評価装置において、
   前記評価処理部は、前記変更後の前記キャラクタが、前記所有ユーザを含む複数のユーザの中からいずれのユーザが所有するキャラクタであるかを選択させる旨の前記評価画像を前記他のユーザのユーザ端末に出力する
   ことを特徴とするキャラクタ評価装置。
5. 請求項１から請求項４のいずれか１項に記載のキャラクタ評価装置において、
   前記キャラクタを構成する前記要素は、それぞれ１以上の要素を含む複数の区分のいずれかに分類され、
   前記評価処理部は、前記変更提案を受け付けた場合に、当該変更提案において変更が提案された前記要素が属する区分とは異なる他の区分についての新たな変更提案を要求する追加提案要求を、前記他のユーザのユーザ端末に出力する
   ことを特徴とするキャラクタ評価装置。
6. 請求項１から請求項５のいずれか１項に記載のキャラクタ評価装置において、
   前記キャラクタを構成する前記要素は、それぞれ１以上の要素を含む複数の区分のいずれかに分類され、
   前記評価処理部は、前記変更提案を受け付けた場合に、当該変更提案において変更が提案された前記要素が属する区分に含まれる他の要素への変更を提案する追加変更提案を、前記他のユーザのユーザ端末に出力する
   ことを特徴とするキャラクタ評価装置。
7. 請求項１から請求項６のいずれか１項に記載のキャラクタ評価装置において、
   ユーザに特典を付与する特典管理部を備え、
   前記特典管理部は、前記評価処理部によって取得された前記変更提案に対する評価が、変更前の前記キャラクタよりも前記変更提案による変更後の前記キャラクタの方が高い場合に、当該変更提案を提起したユーザに特典を付与する
   ことを特徴とするキャラクタ評価装置。
8. 請求項１から請求項７のいずれか１項に記載のキャラクタ評価装置において、
   ユーザに特典を付与する特典管理部を備え、
   前記特典管理部は、前記変更提案に対する全ての評価に基づく評価結果と同じ評価を行ったユーザに対して特典を付与する
   ことを特徴とするキャラクタ評価装置。
9. 請求項１から請求項８のいずれか１項に記載のキャラクタ評価装置において、
   前記要素を選択して前記キャラクタを設定するキャラクタ設定部と、
   課金対象の要素を販売する要素販売部と、を備え、
   前記キャラクタ設定部は、前記評価処理部によって取得された前記変更提案に対する評価が、変更前の前記キャラクタよりも前記変更提案による変更後の前記キャラクタの方が高い場合に、前記変更提案に基づいて前記キャラクタを設定し、
   前記要素販売部は、前記変更提案に基づいて課金対象の要素を含む前記キャラクタに設定される場合に、前記変更提案を行ったユーザに対して課金処理を実施する
   ことを特徴とするキャラクタ評価装置。
10. 請求項１から請求項８のいずれか１項に記載のキャラクタ評価装置において、
    前記要素を選択して前記キャラクタを設定するキャラクタ設定部と、
    課金対象の要素を販売する要素販売部と、を備え、
    前記キャラクタ設定部は、前記評価処理部によって取得された前記変更提案に対する評価が、変更前の前記キャラクタよりも前記変更提案による変更後の前記キャラクタの方が高く、かつ、前記所有ユーザからの変更の指示があった場合に、前記変更提案に基づいて前記キャラクタを設定し、
    前記要素販売部は、前記所有ユーザが所有していない課金対象の要素への変更を提案する前記変更提案に基づいて前記キャラクタが設定される場合に、前記キャラクタを所有するユーザに対して課金額を減額して課金処理を実施する
    ことを特徴とするキャラクタ評価装置。
11. 請求項１から請求項１０のいずれか１項に記載のキャラクタ評価装置において、
    前記提案受付部は、前記他のユーザのユーザ端末から前記変更提案を受け付ける
    ことを特徴とするキャラクタ評価装置。
12. 請求項１から請求項１１のいずれか１項に記載のキャラクタ評価装置において、
    前記キャラクタは、前記ユーザを表現したアバターであり、
    前記評価処理部は、前記所有ユーザと相互に関連付けがなされた他のユーザからの評価結果を取得する
    ことを特徴とするキャラクタ評価装置。
13. 請求項１２に記載のキャラクタ評価装置において、
    前記評価処理部は、前記所有ユーザが所定数以上のユーザに関連付けがなされている場合、前記所有ユーザと相互に関連付けがなされていないユーザからも評価結果を取得する
    ことを特徴とするキャラクタ評価装置。
14. コンピュータが複数の要素によって構成されるキャラクタの評価を行う方法であって、
    前記キャラクタに対する前記要素の変更提案を受け付けるステップと、
    前記変更提案に対する他のユーザからの評価結果を取得するステップと、を有する
    ことを特徴とするキャラクタ評価方法。
15. 請求項１４に記載のキャラクタ評価方法をコンピュータに実行させることを特徴とするキャラクタ評価プログラム。

Images