JP6102939B2 - 情報処理装置、システム、情報処理方法およびプログラム - Google Patents

Description

本開示は、情報処理装置、システム、情報処理方法およびプログラムに関する。

例えばオンラインゲームやコミュニティサイトなどの仮想空間でユーザ同士が会話する場合、発言を示すテキストとともにユーザを示すアバター（avatar）が表示されることが多くある。アバターは、例えば仮想空間におけるユーザの存在に視覚的なイメージを与え、実空間での存在に近づけることによって、仮想空間におけるユーザ同士のコミュニケーションを円滑にする。

このようなアバターの表示に、ユーザの実際の状態を関連付ける技術も提案されている。例えば特許文献１には、ユーザの生体情報や表情の変化に対応した感情が表現されるように、アバターの表情や動きを変化させる技術が記載されている。また、特許文献２には、他のユーザとの親密度や他のユーザの活動状態を、それぞれのユーザを表示するオブジェクトの表示位置によって表現する技術が記載されている。

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

しかしながら、上記のような技術では、アバターの表情や動きなどはユーザの状態に応じて変化するものの、アバターそのものはユーザによって任意に設定されるものであった。それゆえ、アバターがユーザの実際の人となりから乖離するような状況も起きうる。例えば、ユーザである中年男性が彼のアバターとして少女を設定した場合、表情の変化などによってユーザの状態を表現することはできても、アバター自体は依然としてユーザの実際の人となりからは乖離している。

仮想空間でのコミュニケーションにおいては、ユーザが現実のありようから自由になれる場面もあってよい。しかしながら、最近は、ＳＮＳ（Social Networking Service）またはソーシャルメディアの普及などによって、仮想空間での存在と現実の存在とがリンクされる場合も多くなっている。このような場合には、アバターがユーザの実際の人となりを表現している方が、より自然で円滑なコミュニケーションが期待できる。

そこで、本開示では、ユーザの人となりを反映したオブジェクトによってユーザを表象することを可能にする、新規かつ改良された情報処理装置、システム、情報処理方法およびプログラムを提案する。

本開示によれば、所定の期間に蓄積されたユーザの行動履歴情報を取得する行動履歴取得部と、属性群のうちの１または複数の属性について、上記行動履歴情報に基づく上記ユーザの属性スコアを算出する属性スコア算出部と、上記属性スコアに基づいて、上記ユーザを表象するオブジェクトを生成するオブジェクト生成部とを含むサーバが提供される。

また、本開示によれば、ユーザの行動をセンシングするセンシング部と、上記センシングの結果をサーバに送信し、該センシングの結果を含む情報に基づいて生成される上記ユーザの行動履歴情報を所定の期間蓄積したものに基づいて属性群のうちの１または複数の属性について算出される属性スコアに基づいて生成される上記ユーザを表象するオブジェクトの情報を上記サーバから受信する通信部と、上記オブジェクトを表示部に表示させる表示制御部とを含むクライアントが提供される。

また、本開示によれば、クライアントおよびサーバを含み、上記クライアントは、ユーザの行動をセンシングするセンシング部と、上記センシングの結果をサーバに送信し、上記ユーザを表象するオブジェクトの情報を上記サーバから受信する通信部と、上記オブジェクトを表示部に表示させる表示制御部とを有し、上記サーバは、所定の期間に蓄積された、上記センシングの結果を含む情報に基づいて生成される上記ユーザの行動履歴情報を取得する行動履歴取得部と、属性群のうちの１または複数の属性について、上記行動履歴情報に基づく上記ユーザの属性スコアを算出する属性スコア算出部と、上記属性スコアに基づいて上記オブジェクトを生成するオブジェクト生成部とを有するシステムが提供される。

また、本開示によれば、所定の期間に蓄積されたユーザの行動履歴情報を取得することと、属性群のうちの１または複数の属性について、上記行動履歴情報に基づく上記ユーザの属性スコアを算出することと、上記属性スコアに基づいて、上記ユーザを表象するオブジェクトを生成することとを含む情報処理方法が提供される。

また、本開示によれば、所定の期間に蓄積されたユーザの行動履歴情報を取得する機能と、属性群のうちの１または複数の属性について、上記行動履歴情報に基づく上記ユーザの属性スコアを算出する機能と、上記属性スコアに基づいて、上記ユーザを表象するオブジェクトを生成する機能とをコンピュータに実現させるためのプログラムが提供される。

所定の期間に蓄積されたユーザの行動履歴情報には、その期間におけるユーザの生活が反映されているといえる。この行動履歴情報から、属性群のうちの１または複数の属性についての属性スコアを算出することによって、ユーザの人となりを表す指標を得ることができる。その指標である属性スコアに基づいてオブジェクトを生成すれば、生成されるオブジェクトにユーザの人となりが反映される。

以上説明したように本開示によれば、ユーザの人となりを反映したオブジェクトによってユーザを表象することができる。

本開示の第１の実施形態に係るシステムの概略的な機能構成を示すブロック図である。 本開示の第１の実施形態に係るシステムによって実現されるオブジェクトの表示の例を示す図である。 図２に示したような表示を実現するための処理の例を示すフローチャートである。 本開示の第１の実施形態で用いられるデータの例を示す図である。 本開示の第１の実施形態においてオブジェクト生成条件を設定した場合の第１の例を示す図である。 本開示の第１の実施形態においてオブジェクト生成条件を設定した場合の第２の例を示す図である。 本開示の第１の実施形態においてオブジェクト生成条件を設定した場合の第３の例を示す図である。 図７の例の変形例を示す図である。 本開示の第１の実施形態におけるオブジェクトの段階的設定の例を示す図である。 本開示の第１の実施形態の機能構成の第１の変形例を示すブロック図である。 本開示の第１の実施形態の機能構成の第２の変形例を示すブロック図である。 本開示の第２の実施形態における第１の表示例を示す図である。 本開示の第２の実施形態における第２の表示例を示す図である。 本開示の第３の実施形態に係るシステムの概略的な機能構成を示すブロック図である。 本開示の第３の実施形態で用いられるデータの例を示す図である。 本開示の第３の実施形態における処理の例を示すフローチャートである。 本開示の第３の実施形態における第１の表示例を示す図である。 本開示の第３の実施形態における第２の表示例を示す図である。 本開示の第３の実施形態の変形例に係るシステムの概略的な機能構成を示すブロック図である。 本開示の第３の実施形態の変形例を示すフローチャートである。 本開示の第４の実施形態における第１の表示例を示す図である。 本開示の第４の実施形態においてユーザ間の友達登録時にオブジェクトの表示を共有する場合の処理の例を示す図である。 本開示の第４の実施形態における第２の表示例を示す図である。 図２３に示したような表示を実現するための処理の例を示すフローチャートである。 情報処理装置のハードウェア構成を説明するためのブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．第１の実施形態
１−１．機能構成
１−２．処理の例
１−３．データの例
１−４．オブジェクト生成条件の例
１−５．オブジェクトの段階的設定の例
１−６．機能構成に関する変形例
２．第２の実施形態
３．第３の実施形態
３−１．機能構成
３−２．処理の例
３−３．表示例
３−４．変形例
４．第４の実施形態
５．ハードウェア構成
６．補足

（１．第１の実施形態）
まず、図１〜図１１を参照して、本開示の第１の実施形態について説明する。

（１−１．機能構成）
図１は、本開示の第１の実施形態に係るシステムの概略的な機能構成を示すブロック図である。図１を参照すると、システム１０は、クライアント１００と、サーバ１５０とを含む。クライアント１００とサーバ１５０とは、有線または無線の各種のネットワークによって互いに接続され、必要に応じて通信する。以下、クライアント１００およびサーバ１５０のそれぞれの構成について、さらに説明する。

（クライアント）
クライアント１００は、センシング部１０２、入力部１０４、表示制御部１０６、表示部１０８、および通信部１１０を含む。クライアント１００は、ユーザによって使用される各種の情報処理装置、例えば携帯電話（スマートフォン）、各種のＰＣ（Personal Computer）、メディアプレーヤ、ゲーム機などによって実現される。情報処理装置は、例えば後述するハードウェア構成によって実現される。

ここで、クライアント１００は、単一の装置によって実現されてもよいし、複数の装置によって実現されてもよい。例えば、センシング部１０２は、ユーザの行動をセンシングするため、携帯電話（スマートフォン）などのユーザによって携帯される装置によって実現されることが望ましい。その一方で、入力部１０４、表示制御部１０６、および表示部１０８は、必ずしもユーザによって携帯されなくてもよいため、センシング部１０２と同一の装置によって実現されてもよいし、センシング部１０２とは異なる装置、例えばデスクトップ型のＰＣなどの据え置き型の装置によって実現されてもよい。以下、かかるクライアント１００の各機能構成について説明する。

センシング部１０２は、クライアント１００を使用するユーザの行動をセンシングする。センシング部１０２は、例えば加速度センサ、ジャイロセンサ、地磁気センサ、光センサ、音センサなどの各種のセンサ、および／またはＧＰＳ（Global Positioning System）受信機などによって実現され、ユーザの位置や活動状態などをセンシングする。センシング部１０２は、センシングの結果を通信部１１０を介してサーバ１５０に送信する。

入力部１０４は、サーバ１５０におけるオブジェクト生成時のフィルタリング条件に関するユーザの入力を受け付ける。後述するように、サーバ１５０は、ユーザを表象するオブジェクトを生成するにあたり、取得する行動履歴の範囲や、強調して用いる属性スコアなどを選択する機能を有する場合がある。この場合、ユーザは、例えば入力部１０４を介して選択に関する情報を入力することによって、オブジェクトの生成にある程度の要望を反映させることができる。入力部１０４は、例えばタッチパネルやキーボード、マウスなどの入力装置によって実現され、受け付けた入力を通信部１１０を介してサーバ１５０に送信する。

表示制御部１０６は、サーバ１５０で生成されたオブジェクトの情報を通信部１１０を介して受信し、そのオブジェクトを表示部１０８に表示させる。オブジェクトは、例えばアバターのようにユーザを表象するオブジェクトである。ここで受信された情報を用いて表示されるオブジェクトは、センシング部１０２によって行動がセンシングされるユーザについて生成されたオブジェクトであってもよいし、他のユーザについて生成されたオブジェクトであってもよいし、その両方であってもよい。表示制御部１０６は、オブジェクトを単体で表示してもよいし、他のアプリケーションなどの画面の中で表示させてもよい。また、表示制御部１０６は、オブジェクトを対応するユーザの画像（例えばＡＲ（Augmented Reality）アプリケーションなどで提供される撮像画像、またはシースルー型の表示部１０８で透過して見えている実空間の像など）に重畳させて表示させてもよい。表示制御部１０６は、例えばＣＰＵ（Central Processing unit）がメモリに格納されたプログラムに従って動作することによって実現される。

表示部１０８は、表示制御部１０６の制御に従って、各種の情報をユーザに向けて表示する。表示制御部１０６について説明したように、表示部１０８に表示される情報には、ユーザを表象するオブジェクトが含まれる。表示部１０８は、例えば各種のディスプレイによって実現される。ディスプレイは、例えば平面型であってもよく、ヘッドマウント型であってもよい。また、ディスプレイは、例えば非透過型であってもよく、透過型であってもよい。

通信部１１０は、クライアント１００とサーバ１５０との間でやりとりされる各種の情報を送受信する。通信部１１０は、例えばネットワークに接続される各種の通信インターフェースによって実現される。

（サーバ）
サーバ１５０は、行動認識部１５２、行動履歴ＤＢ１５４、行動履歴取得部１５６、属性スコア算出部１５８、属性ＤＢ１６０、オブジェクト生成部１６２、オブジェクトＤＢ１６４、ユーザＤＢ１６６、および通信部１６８を含む。サーバ１５０は、さらに、期間選択部１７０および属性選択部１７２の一方または両方を含んでもよい。サーバ１５０は、単一の情報処理装置、または有線もしくは無線の各種のネットワークによって互いに接続された複数の情報処理装置の協働によって実現される。情報処理装置は、例えば後述するハードウェア構成によって実現される。以下、各機能構成について説明する。なお、ＤＢおよび通信部を除く各部は、例えばＣＰＵがメモリに格納されたプログラムに従って動作することによって実現される。ＤＢは、例えばストレージ装置によって実現される。

行動認識部１５２は、クライアント１００のセンシング部１０２から通信部１６８を介して受信したセンシング結果に基づいて、クライアント１００のユーザの行動を認識し、認識の結果を行動履歴ＤＢ１５４に格納する。行動認識部１５２は、さらに他のサーバなどからその他の情報を取得し、この情報にさらに基づいてユーザの行動を認識してもよい。その他の情報は、例えば店舗における購買ログや、特定の場所に設置された端末を操作した履歴などでありうる。行動認識部１５２は、さらに、ユーザの住所や勤務地などの登録情報を行動の認識に利用してもよい。なお、行動認識の技術の詳細に関しては、例えば特開２０１２−８７７１号公報など多くの文献で紹介されており、行動認識部１５２ではそれらの技術を適宜利用してユーザの行動を認識する。

行動履歴ＤＢ１５４には、行動認識部１５２による認識の結果が、ユーザの行動履歴として蓄積される。行動履歴ＤＢ１５４に蓄積される情報は、例えばユーザの位置履歴や、購入履歴、操作履歴などであってもよいし、行動認識部１５２による認識結果を反映した行動パターン履歴や行動種別履歴などであってもよい。このような情報の限定的ではない例として、例えば以下のようなものが蓄積されうる。端末装置が充電中であるか、操作中であるか。ユーザが止まっているか、座っているか、歩いているか、走っているか、ジャンプしているか。ユーザが移動中であるかと、その位置。ユーザが電車に乗っているか、自動車に乗っているか、エレベータに乗っているか。ユーザが仕事中であるか、買い物中であるか。ユーザが入力したテキストログの口調から推定されるユーザの行動。行動履歴ＤＢ１５４に蓄積された上記のような情報を参照すれば、ユーザが、過去のある時点においてどのような行動をしていたかを特定することができる。

行動履歴取得部１５６は、所定の期間に蓄積されたユーザの行動履歴情報を、行動履歴ＤＢ１５４から取得する。行動履歴取得部１５６は、所定の期間として、直近の特定の期間（例えば過去１年間など）を指定してもよいし、行動履歴情報が存在するすべての期間（つまり、ユーザが行動履歴を取得するサービスを利用し始めてから現在まで）を指定してもよい。また、付加的に期間選択部１７０が設けられる場合、期間選択部１７０による期間の選択があれば、行動履歴取得部１５６は選択された期間について行動履歴情報を取得する。選択がなければ、行動履歴取得部１５６は、期間選択部１７０が設けられない場合と同様に行動履歴情報を取得する。

属性スコア算出部１５８は、行動履歴取得部１５６が取得したユーザの行動履歴情報に基づいて、属性群のうちの１または複数の属性について属性スコアを算出する。属性は、ユーザの人となりを示す属性であり、例えば仕事や、買い物、食事などに関するものでありうる。属性は、属性群として予め属性ＤＢ１６０に登録されている。属性スコア算出部１５８は、属性群のうちのすべての属性について属性スコアを算出してもよいし、そのうちの一部について属性スコアを算出してもよい。複数の属性について属性スコアを算出する場合、属性スコア算出部１５８は、それぞれのスコアを正規化して、異なる属性間でスコアの大小を比較することを可能にしてもよい。また、属性スコア算出部１５８は、一旦算出した属性スコアをユーザに対応づけて属性ＤＢ１６０に格納し、定期的に更新してもよい。

ここで、付加的に属性選択部１７２が設けられる場合、後述するオブジェクト生成部１６２によってオブジェクトの生成において強調される属性スコアが、属性選択部１７２による選択によって決定される。この場合、例えば、属性スコア算出部１５８は、属性選択部１７２によって選択された属性に限定して、または選択された属性に重みをつけて属性スコアを算出してもよい。あるいは、属性スコア算出部１５８は、属性選択部１７２の選択に関わらず、属性群のうちの１または複数の属性について属性スコアを算出して属性ＤＢ１６０に格納しており、属性選択部１７２の選択に応じて格納された属性スコアを読み出すときに、重みづけなどの再計算を実行してもよい。なお、属性および属性スコアは、後述するオブジェクトの生成と関連しているため、それらの具体的な例についてはオブジェクトの例とともに説明する。

属性ＤＢ１６０には、属性スコア算出部１５８によって算出される属性スコアに関する情報が格納される。例えば、属性ＤＢ１６０には、属性スコアの算出の対象になる属性群を定義する情報が格納される。また、属性ＤＢ１６０には、属性スコア算出部１５８が算出した属性スコアがユーザに対応づけて格納され、属性スコア算出部１５８によって定期的に更新されてもよい。属性群に含まれるそれぞれの属性の定義情報は、例えば、行動履歴と属性スコアとの関係を定義する情報を含む。例えば、“仕事”という属性の場合、“ユーザが職場にいた時間に応じて属性スコアを加算する”といったようなルールが定義されうる。

なお、後述するように、属性スコアに基づいてオブジェクトを生成するときには、オブジェクトＤＢ１６４の情報が参照される。それゆえ、属性ＤＢ１６０に格納された属性の定義情報と、オブジェクトＤＢ１６４に格納されたオブジェクトの情報とは対応している。例えば、属性ＤＢ１６０で“仕事”という属性が定義されていれば、オブジェクトＤＢ１６４には“仕事”の属性スコアに応じて選択されるオブジェクトが定義されている。

オブジェクト生成部１６２は、属性スコア算出部１５８から提供された属性スコアに基づいて、ユーザを表象するオブジェクトを生成する。オブジェクトは、例えば、行動履歴情報が提供されたユーザ、および／または他のユーザに向けて、ユーザを表すものとして表示される画像である。例えば、オブジェクトが何らかの具体物（例えば人、動物、ロボット、など）の画像であれば、オブジェクトはユーザのアバター（化身）であるともいえる。また、オブジェクトは、図形などの抽象的な画像であってもよい。この場合も、オブジェクトはその形、サイズ、色などによってユーザを表象する。なお、オブジェクトの具体的な例については後述する。オブジェクト生成部１６２は、生成されたオブジェクトを通信部を介してクライアント１００に送信し、表示制御部１０６による表示部１０８への表示に供する。さらに、オブジェクト生成部１６２は、生成されたオブジェクトを、ユーザＤＢ１６６にユーザと関連付けて格納し、その後に再びオブジェクトの提供の要求があったときに読み出してもよい。

ここで、オブジェクト生成部１６２は、予めオブジェクトＤＢ１６４に登録された情報を参照し、属性スコアに基づいてオブジェクトを生成する。より具体的には、オブジェクト生成部１６２は、属性スコアを用いて、オブジェクトＤＢ１６４に登録された情報を検索し、ユーザを表象するのに適切なオブジェクトの情報を抽出する。例えば、属性スコア算出部１５８によって複数の属性について属性スコアが算出された場合、オブジェクト生成部１６２は、そのうち最も属性スコアが高い属性について設定されたオブジェクトの情報を抽出してもよい。あるいは、オブジェクト生成部１６２は、複数の属性についてそれぞれ設定されたオブジェクトの情報を抽出し、これらをそれぞれの属性スコアに応じて合成してオブジェクトを生成してもよい。

さらに、オブジェクト生成部１６２は、ユーザＤＢ１６６に格納されたユーザの登録情報を参照してオブジェクトを生成してもよい。この場合、オブジェクト生成部１６２は、ユーザの性別、年齢、職業などに応じて、同じ属性スコアに対して用意された複数のオブジェクトの中から適切なものを選択してもよい。例えば、同じ“仕事”の属性のオブジェクトであっても、ユーザが男性か女性か、若者かシニアか、オフィスワーカーか工場労働者か、などといったことに応じて、異なるオブジェクトが生成されうる。このようにユーザの情報を参照してオブジェクトを生成することで、オブジェクトによってユーザの人となりをより適切に表現することができる。なお、オブジェクトが抽象的な画像であったり、具体物の画像であっても性別や年齢などの属性が関係ないものであるような場合、オブジェクト生成部１６２は必ずしもユーザＤＢ１６６を参照しなくてもよい。また、例えばオブジェクトに現れる性別や年齢などについては、あえてユーザによる自由な設定を許容してもよい。

オブジェクトＤＢ１６４には、オブジェクト生成部１６２によるオブジェクトの生成に用いられるオブジェクトの情報が格納される。オブジェクトは、例えば、属性ＤＢ１６０で定義された属性に対応して設定される。例えば、属性ＤＢ１６０で“仕事”という属性が定義されている場合、オブジェクトＤＢ１６４には、“仕事”の属性に対応する少なくとも１つのオブジェクトの情報が格納される。さらに、オブジェクトは、属性スコアに応じて複数設定されてもよい。例えば、“仕事”という属性について、属性スコアが低い場合、中程度の場合、高い場合、といったように、何段階かのオブジェクトが設定され、ユーザがどの程度仕事熱心であるかを表現することが可能であってもよい。また、オブジェクトＤＢ１６４は、オブジェクトをさまざまな姿勢やサイズで表示することを可能にするデータを、オブジェクトごとに格納していてもよい。この場合、オブジェクト生成部１６２、またはクライアント１００の表示制御部１０６で、表示されるオブジェクトの姿勢やサイズが決定される。

ユーザＤＢ１６６には、ユーザに関する情報が格納される。ユーザに関する情報は、例えば、ユーザＩＤ、性別、年齢、住所、職業、勤務地などの登録情報を含みうる。上記の通り、ユーザＤＢ１６６に格納されたユーザの登録情報は、オブジェクト生成部１６２におけるオブジェクトの生成に用いられてもよい。登録情報は、オブジェクト生成部１６２だけではなく、行動認識部１５２など、サーバ１５０のさまざまな部分から参照されうる。また、ユーザＤＢ１６６には、オブジェクト生成部１６２によって生成されたオブジェクトの情報がユーザに関連付けて格納され、オブジェクトの表示要求があった場合に読み出されてもよい。

通信部１６８は、サーバ１５０とクライアント１００との間でやりとりされる各種の情報を送受信する。通信部１６８は、例えばネットワークに接続される各種の通信インターフェースによって実現される。

期間選択部１７０は、付加的に設けられる。期間選択部１７０は、クライアント１００でユーザの操作を取得した入力部１０４から通信部１６８を介して受信した情報に基づいて、オブジェクト生成部１６２でオブジェクトの生成において強調される期間を選択する。期間は、例えば“夏”、“平日”、“週末”、“昼間”、“オフタイム”、“家にいる時間”など、周期的な期間によって選択されてもよいし、例えば“１０年前まで”、“最近１年間”、“１０年後”などのように非周期的な期間によって選択されてもよい。期間選択部１７０によって期間が選択された場合、例えば、行動履歴取得部１５６が、選択された期間に限定して行動履歴情報を取得してもよい。あるいは、属性スコア算出部１５８が、選択された期間の行動履歴情報に、他の期間の行動履歴情報よりも大きな重みをつけて属性スコアを算出してもよい。

なお、未来の期間を選択する場合、例えば行動履歴取得部１５６はユーザの比較的近い過去の行動履歴情報を取得し、属性スコア算出部１５８は、その行動履歴と同様の行動を続けた場合の、選択された未来の期間におけるユーザの属性スコアの推定値を算出する。この場合、例えば、現在運動をあまりしないユーザについて、未来の期間を選択して生成したオブジェクトは、肥満型の人物のオブジェクトでありうる。期間選択部１７０は、属性スコアの元になる行動履歴情報が取得される期間の条件を設定するという点で、オブジェクトの生成条件を設定する条件設定部の１つともいえる。

属性選択部１７２も、付加的に設けられる。属性選択部１７２は、クライアント１００でユーザの操作を取得した入力部１０４から通信部１６８を介して受信した情報に基づいて、オブジェクト生成部１６２でのオブジェクトの生成において強調される属性スコアを選択する。例えば、属性選択部１７２によって、属性ＤＢ１６０に定義された属性群の中から１または複数の属性が選択された場合、属性スコア算出部１５８は、選択された属性に限定して属性スコアを算出するか（他の属性スコアは０）、選択された属性の属性スコアに他の属性スコアに比べて大きな重みをつけてもよい。あるいは、属性スコア算出部１５８によって属性スコアが既に算出されて属性ＤＢ１６０に格納されている場合、オブジェクトの生成時に読み出された属性スコアのうち、選択された属性の属性スコアに対する重みづけの再計算が実行されてもよい。

ここで、選択可能な属性スコアの数は、予め設定されていてもよい。あるいは、属性は、予め設定されたパターンに従って選択されてもよい。例えば、“日常の行動”というパターンで属性を選択した場合、“仕事”、“家での過ごし方”、“移動の仕方”などに関する１または複数の属性が選択される。また、属性選択部１７２による属性の選択と、期間選択部１７０による期間の選択とは、相互に影響を与えあってもよい。例えば、期間選択部１７０で“週末”の期間が選択された場合、属性選択部１７２が“買い物の場所”、“余暇の過ごし方”といった、“週末”の行動に関連する属性を選択してもよい。また、例えば、属性選択部１７２で“仕事”の属性が選択された場合、期間選択部１７０が“仕事”がされているであろう“平日”の期間を選択してもよい。属性選択部１７２も、オブジェクトの生成に用いられる属性スコアを選択するという点で、オブジェクトの生成条件を設定する条件設定部の１つともいえる。

本実施形態では、条件設定部である期間選択部１７０および属性選択部１７２が、ユーザの操作に従ってオブジェクトの生成条件を設定する。これによって、ユーザは、自らを表象するオブジェクトに、どのような時期の、どのような属性を反映させるかを選択することができる。この点で、ユーザは、“見せたい自分”をある程度演出できる。例えば、平日は仕事に追われているユーザも、週末にスポーツを楽しんでいれば、期間選択部１７０を介して“週末”の期間を選択することで、“スポーツ好きな自分”のオブジェクトを生成させることができる。しかしながら、ユーザは、行動履歴によって示される範囲を超えて“見せたい自分”を作り出すことはない。例えば、ユーザが平日にも週末にもスポーツをしていなければ、どのようにしても“スポーツ好きな自分”のオブジェクトは生成されない。この点で、ユーザによるオブジェクトの生成条件の設定を許容したとしても、オブジェクト生成部１６２によって生成されるオブジェクトは、多かれ少なかれユーザの人となりが反映されるといえる。もちろん、条件設定部を設けずに、よりリアルにユーザの人となりを反映したオブジェクトが生成されるようにしてもよい。

一方、本実施形態の変形例として、条件設定部である期間選択部１７０および属性選択部１７２は、オブジェクト生成部１６２によって生成されたオブジェクトが表示される状況に応じて生成条件を設定してもよい。例えば、条件設定部は、オブジェクトが表示されるコミュニティサイトの属性に応じてオブジェクトの生成条件を設定してもよい。例えば、オブジェクトがスポーツをテーマにしたコミュニティサイトで表示される場合、属性選択部１７２によって自動的に“スポーツ”に関する属性スコアが選択されてもよい。また、例えば、オブジェクトが学校の同窓会のコミュニティサイトで表示される場合、期間選択部１７０によって自動的にユーザが学校に在籍していた期間が選択されてもよい。これによって、仮想空間におけるコミュニケーションの場ごとに、その性質に合ったオブジェクトを表示することができる。

以上、本開示の第１の実施形態に係るシステムの概略的な機能構成について説明した。続いて、かかるシステムによって実現されるオブジェクトの表示や、オブジェクトを生成するための処理、用いられるデータなどの具体的な例について、さらに説明する。

（１−２．処理の例）
図２は、本開示の第１の実施形態に係るシステムによって実現されるオブジェクトの表示の例を示す図である。図２では、ユーザＡおよびユーザＢが、仮想空間で会話している状況が示されている。画面１１００には、アバター１１０１と、ダイアログ１１０３とが表示される。ここで、アバター１１０１は、ユーザＡのアバター１１０１ａと、ユーザＢのアバター１１０１ｂとを含み、ダイアログ１１０３は、ユーザＡのダイアログ１１０３ａと、ユーザＢのダイアログ１１０３ｂとを含む。

ここで、アバター１１０１は、上記のサーバ１５０のオブジェクト生成部１６２において生成されたオブジェクトである。ユーザＡのアバター１１０１ａは、“仕事”の属性スコアに基づいて生成され、スーツを着てカバンを持ったユーザの姿を表している。このことから、会話の相手であるユーザＢは、ユーザＡが主に仕事をしている人物であることを認識することができる。

一方、ユーザＢのアバター１１０１ｂは、“家事”の属性スコアに基づいて生成され、家で料理をしているユーザの姿を表している。このことから、ユーザＡは、ユーザＢが主に家事をしている人物であることを認識することができる。従って、両者の会話では、“お仕事大変そうですね”や、“家事も大変ですよね”といった話題が容易に導き出され、会話がより自然で円滑なものになることが期待される。

図３は、図２に示したような表示を実現するための処理の例を示すフローチャートである。まず、サーバ１５０において、属性スコア算出部１５８は、行動履歴取得部１５６が取得した行動履歴に基づいて、定期的に属性ＤＢ１６０に格納されたユーザの属性スコアを更新している（ステップＳ１０１）。ここで、例えば図２に示したようなアプリケーションが起動されたことなどによってオブジェクトの表示要求があった場合（ステップＳ１０３）、サーバ１５０ではオブジェクト生成のための処理が実行される。

まず、属性スコア算出部１５８は、属性ＤＢ１６０に格納された属性スコアを読み出すにあたり、属性選択部１７２による属性の選択があれば（ステップＳ１０５）、その選択に応じて使用する属性スコアを選択する（ステップＳ１０７）。なお、ここでの属性の選択は、例えばユーザの操作や、オブジェクトが表示される状況（図２に示したような会話がなされる状況）に基づくものでありうる。属性の選択がない場合、算出されているすべての属性スコアが使用される。

次に、オブジェクト生成部１６２が、属性ＤＢ１６０から読み出された属性スコアに基づいてオブジェクトを生成する（ステップＳ１０９）。そして、オブジェクト生成部１６２は、通信部１６８を介してオブジェクトの情報をクライアント１００に送信する（Ｓ１１１）。このとき、オブジェクト生成部１６２は、例えば図２に示した画面１１００を表示するためのデータの一部として、オブジェクトの情報を送信してもよい。以上のような処理によって、クライアント１００で、ユーザを表象するオブジェクトを含む画像が表示される。

（１−３．データの例）
図４は、本開示の第１の実施形態で用いられるデータの例を示す図である。図示された例では、ユーザＡ〜ユーザＦの６人について、オブジェクトの生成のために用いられるデータの例が示されている。データの項目ごとに説明すると、“性別”および“職業”は、ユーザの登録情報であり、例えばユーザＤＢ１６６に格納される。“職場”および“家”は、ユーザの位置履歴に関して設定された属性であり、それぞれの場所にいた時間の長さに応じて属性スコアが算出される。“座る”、“歩く”、“走る”、“食事”および“買い物”は、ユーザの行動状態に関して設定された属性であり、それぞれの行動をしていた時間の長さに応じて属性スコアが算出される。図示された例において、各属性スコアは正規化されており、相互に比較することが可能である。一方、“デパート”、“スーパー”および“本屋”は、属性“買い物”をさらに細分化した属性であり、それぞれの種類の店舗で買い物をした回数、または金額に応じて属性スコアが算出される。この“買い物”の例のように、属性は階層的な構成をもっていてもよい。これらの属性スコアは、ユーザの行動履歴に基づいて属性スコア算出部１５８によって算出される。

上記のようなデータに基づいて、オブジェクト生成部１６２がユーザを表象するオブジェクトを生成する。生成条件が設定されなかった場合、オブジェクト生成部１６２は、算出されているすべての属性スコアを参照して、オブジェクトを生成しうる。この場合、例えば、オブジェクト生成部１６２は、各属性の属性スコアを比較して、最も高い属性についてオブジェクトを生成する。

例えば、ユーザＡ、ユーザＢについては、“職場”の属性スコアが最も高い。そこで、オブジェクト生成部１６２は、オブジェクトＤＢ１６４に格納されたオブジェクトの情報の中から、“職場”の属性に対応するオブジェクトの情報を選択する。さらに、当該オブジェクトの情報が、性別や職業などに応じて複数用意されている場合、オブジェクト生成部１６２は、ユーザＡ、ユーザＢの性別および職業、すなわち男性の会社員に該当するオブジェクトの情報を選択する。このような処理の結果として、例えば、スーツを着用し、カバンを持った男性のアバター１１０１ｃが、オブジェクトとして生成される。ここで、例えば、ユーザＡ、ユーザＢの職業が農夫であり、それに対応したオブジェクトの情報がオブジェクトＤＢ１６４に格納されていれば、別のアバター、例えば麦わら帽子をかぶって鍬を持った男性のアバターが生成されうる。

同様に、ユーザＣ、ユーザＤについても、“職場”の属性スコアが最も高いが、ユーザＣ、ユーザＤは女性であるため、オブジェクト生成部１６２は、スーツを着用した女性のアバター１１０１ｄをオブジェクトして生成する。一方、ユーザＥ、ユーザＦについては、“家”の属性スコアが最も高い。そこで、オブジェクト生成部１６２は、オブジェクトＤＢ１６４に格納されたオブジェクトの情報の中から、“家”の属性に対応するオブジェクトの情報を選択する。また、ユーザＥ、ユーザＦは女性であるため、オブジェクト生成部１６２は、家で料理をしている女性のアバター１１０１ｅをオブジェクトとして生成する。

なお、上記の例では、オブジェクト生成部１６２が、属性スコアが最も高い属性に基づいてオブジェクトを生成したが、本開示の実施形態はこのような例には限られない。例えば、オブジェクト生成部１６２は、属性スコアが比較的高い複数の属性について、これらの属性に対応するオブジェクトの情報をオブジェクトＤＢ１６４から取得し、取得した情報を各属性スコアに応じて合成してオブジェクトを生成してもよい。

例えば、ユーザＡ〜ユーザＤは、いずれも“職場”の属性スコアが最も高い点で共通しているが、ユーザＢ、ユーザＣは“歩く”の属性スコアが比較的高く、ユーザＡ、ユーザＤは“歩く”の属性スコアが低い、という点で相違する。例えば、オブジェクト生成部１６２は、このような相違をオブジェクトに反映させるべく、ユーザＢ、ユーザＣについては、スーツを着用して歩いている男性または女性のアバターをオブジェクトとして生成し、ユーザＡ、ユーザＤについては、スーツを着用して座っている男性または女性のアバターをオブジェクトとして生成してもよい。

このように、複数の属性についての属性スコアに基づいてオブジェクトを生成することで、ユーザに最もよくあてはまる属性を抽出して、その属性に対応するオブジェクトを生成することができる。その一方で、例えば会社員のユーザの場合、滞在時間に基づいて算出される“職場”の属性スコアが高くなってしまうために、その他の、例えば“オフタイムにスポーツを楽しんでいる”という特徴が埋没してしまう可能性もある。そのような場合、付加的に設けられる期間選択部１７０や属性選択部１７２によってオブジェクトの生成条件を設定することで、例えばよりユーザの個性を反映したオブジェクトの生成が可能になる。以下、そのような生成条件が設定された場合のオブジェクトの生成の例について、さらに説明する。

（１−４．オブジェクト生成条件の例）
図５は、本開示の第１の実施形態においてオブジェクト生成条件を設定した場合の第１の例を示す図である。図示された例では、図４と同様のデータを基にオブジェクトを生成するにあたり、“運動フィルタ”ともいえる生成条件が設定されている。より具体的には、属性選択部１７２が、オブジェクトの生成において強調される属性スコアとして、ユーザの運動状況に関係する“座る”、“歩く”、“走る”の属性スコアを選択している。

この場合、オブジェクト生成部１６２は、選択された属性スコアを強調してオブジェクトを生成する。従って、図示された例では、“座る”の属性スコアが高く、消費カロリーの低い行動が多いと推定されるユーザＡについては、小太りの男性のアバター１１０１ｆが、オブジェクトとして生成される。一方、“歩く”や“走る”の属性スコアが比較的高く、消費カロリーの高い行動が多いと推定されるユーザＢについては、スマートな男性のアバター１１０１ｇが、オブジェクトとして生成される。

このような生成条件の設定によって、全体として見ればいずれも“主に仕事をしている人”であって差異がないユーザＡとユーザＢとに、“運動をよくするか否か”という点で差が生じる。例えば、ユーザＢが、よく運動をしている自信があり、そのような自分を仮想空間におけるアバターのようなオブジェクトに表現したいと望む場合、ユーザＢは、属性選択部１７２を介して上記の“運動フィルタ”を設定すればよい。

なお、このようなフィルタ型の生成条件が設定された場合であっても、フィルタによって選択されなかった属性スコアが、オブジェクトの生成にある程度反映されてもよい。例えば、図５の例であれば、アバター１１０１ｆ，１１０１ｇは必ずしもトレーニングウェアを着用していなくてもよく、例えば、選択されなかった属性スコアで一番高いものが“職場”の属性スコアであることに基づいて、スーツを着用していてもよい。

図６は、本開示の第１の実施形態においてオブジェクト生成条件を設定した場合の第２の例を示す図である。図示された例では、図４と同様のデータを基にオブジェクトを生成するにあたり、“買い物フィルタ”ともいえる生成条件が設定されている。より具体的には、属性選択部１７２が、オブジェクトの生成において強調される属性スコアとして、ユーザの買い物の仕方に関連する“デパート”、“スーパー”、“本屋”の属性スコアを選択している。

上記の図５の例と同様に、オブジェクト生成部１６２は、選択された属性スコアに基づいてオブジェクトを生成する。従って、図示された例では、“デパート”の属性スコアが高いユーザＥについては、デパートのショッピングバッグを持ち、着飾った女性のアバター１１０１ｈが、オブジェクトとして生成される。一方、“スーパー”の属性スコアが高いユーザＦについては、普段着でネギの突き出したビニール袋を持った女性のアバター１１０１ｉが、オブジェクトとして設定される。

このような生成条件の設定によって、全体として見ればいずれも“主に家にいる主婦”であって差異がないユーザＥとユーザＦとに、“どこで買い物をするか”という点で差が生じる。例えば、商品のレビューを投稿するサイトに彼女らのアバターを表示する場合、属性選択部１７２がサイトの属性に応じて自動的に“買い物フィルタ”を設定することで、レビューを投稿したユーザがどこで買い物をすることが多いのかを知った上でレビューを閲覧することができる。

図７は、本開示の第１の実施形態においてオブジェクト生成条件を設定した場合の第３の例を示す図である。図示された例では、図４と同様のデータを基にオブジェクトを生成するにあたり、“週末フィルタ”ともいえる生成条件が設定されている。より具体的には、期間選択部１７０が、オブジェクトの生成において行動履歴が強調される期間として“週末”を選択している。図には、“週末”について算出された、“家”、“移動”、“家以外の場所”の属性スコアが示されている。これらの属性スコアは、例えばユーザの位置情報がそれぞれの属性の条件を満たしていた時間の長さに応じて算出される。また、これらのスコアも正規化されており、相互に比較することが可能である。

図示された例において、オブジェクト生成部１６２は、選択された期間の行動履歴情報に基づいて算出された属性スコアに基づいてオブジェクトを生成する。この場合、例えば、“家以外の場所”にいる時間が長いユーザＣについては、旅行カバンを持った女性のアバター１１０１ｊが、オブジェクトとして生成される。一方、“家”にいる時間が長いユーザＤについては、自宅でお茶を飲んでいる女性のアバター１１０１ｋが、オブジェクトとして生成される。

このような生成条件の設定によって、図４に示した全期間についての属性データでは差異がないユーザＣとユーザＤとに、“週末の過ごし方”という点で差が生じる。仕事をしているユーザの多くは、平日は基本的に仕事をしており、過ごし方に個性が出にくい傾向がある。そこで、上記のような“週末フィルタ”を設定してオブジェクトを生成すれば、各ユーザについてバラエティに富んだオブジェクトが生成されうる。

図８は、図７の例の変形例を示す図である。本実施形態では、図７の例のように期間についての条件を設定して算出された属性スコアと、図４の例のように期間についての条件を設定せずに、または異なる条件を設定して算出された属性スコアとが、互いに比較されてもよい。図示された例の場合、オブジェクト生成部１６２は、図４および図７の例に示されたユーザＤについて、期間の条件を設定せずに算出された属性スコアの中で最も高い“仕事”の属性スコア（５５）と、期間を“週末”に限定して算出された属性スコアの中で最も高い“家”の属性スコア（８０）とを比較し、より高い属性スコアに応じてオブジェクトを生成している。結果として、ユーザＤについては、“週末”について算出された“家”の属性スコアに基づいて、アバター１１０１ｋがオブジェクトとして生成される。

このような比較によって、例えば、対象になる期間を変えて算出されたユーザの属性スコアの中で、最も特徴的なものが選択されうる。例えば、ユーザＤが、週末の過ごし方には特に特徴がないけれども、平日は人一倍仕事をしているユーザであれば、“週末フィルタ”が設定されていても、平日の“職場”の属性スコアに基づいて生成されるアバター１１０１ｄが選択されうる。一方、ユーザＤが、平日の仕事は人並みだけれども、週末は人一倍家で過ごすことが多いユーザであれば、週末の“家”の属性スコアに基づいて生成されるアバター１１０１ｋが選択されうる。

このような比較は、例えば期間選択部１７０や属性選択部１７２によって設定されている条件に従って実行されてもよい。あるいは、属性スコア算出部１５８は、さまざまな期間や属性のフィルタリングパターンでの属性スコアの算出を試行することによって、ユーザの人となりを最もよくオブジェクトに反映させることができる生成条件を探索してもよい。この生成条件は、例えばユーザごとに異なっていてもよい。

（１−５．オブジェクトの段階的設定の例）
図９は、本開示の第１の実施形態におけるオブジェクトの段階的設定の例を示す図である。図９には、本実施形態においてオブジェクトＤＢ１６４に格納されうる情報の例が示されている。上述したように、オブジェクトＤＢ１６４には、同じ属性について、属性スコアに応じて設定された複数のオブジェクトの情報が格納され、オブジェクト生成部１６２は、ユーザの属性スコアに応じてこれらの中から適切なオブジェクトの情報を選択してもよい。これによって、例えば、ユーザがその属性によって表される事項にどの程度あてはまるかを表現することができる。なお、図９に示される例は、図４〜図８の例とは相関性がない。

図示された例では、“仕事”、“買い物”、“電車旅行”の３つの属性について、属性スコアに応じて段階的にオブジェクトの情報が設定されている。例えば、“仕事”の属性の場合（例えば職場に滞在している時間に応じて属性スコアが設定される）、属性スコアが５０〜５９であれば、アバターがネクタイを着用する。属性スコアが６０〜６９になれば、アバターがさらにスーツを着用する。属性スコアが７０〜９９であれば、かなり仕事熱心な人であることを表現するために、アバターが汗をかく。さらに、属性スコアが１００になると、相当に仕事熱心な偉い人であることを表現するために、アバターに後光がさす。

同様に“買い物”の属性の場合（例えばデパートに滞在している時間に応じて属性スコアが設定される）、属性スコアが高くなるにつれて、アバターが所持しているショッピングバッグの数が増える。さらに、背景にデパートの建物が現れ、最終的には荷物を持ってくれるお付きの者がつく。また、“電車旅行”の属性の場合（例えば電車に乗って移動している時間に応じて属性スコアが設定される）、属性スコアが高くなるにつれて、鉄道マニアがよく所持しているアイテムが次々とアバターに与えられる。なお、属性スコアの各段階について設定されるオブジェクトの情報は、１つには限られない。例えば、属性スコアの各段階には、それぞれ複数のオブジェクトの情報が設定されてもよい。この場合、ユーザが該当する属性スコアの段階のオブジェクトの中でどれを選択するかは、例えばユーザの入力操作に基づいて決定されてもよい。

このように、属性スコアに応じて段階的に変化するオブジェクトが生成されることによって、ユーザがどのような属性の人であるかという定性的な情報に加えて、どの程度その属性が強い人かという定量的な情報を、オブジェクトに反映させることができる。また、上記の例のように、属性スコアに応じて生成されるオブジェクトにある程度の遊びの要素をもたせることで、ユーザの実際の行動にモチベーションを与えられる場合もある（例えば、“今週は仕事が忙しいので、どうせならアバターに後光がさすまで頑張ってみよう”など）。

また、上記の例と同様の性質をもつ変形例として、属性ＤＢ１６０には、ユーザが所定のイベントを達成したか否かを示す属性が定義され、この場合、属性スコア算出部１５８が、行動履歴情報に基づいて、ユーザが当該イベントを達成したか否かを判定し、例えば達成した場合には属性スコアに１を、そうでない場合には属性スコアに０を設定する。さらに、オブジェクト生成部１６２が、上記の属性の属性スコアに１が設定されているユーザについて、オブジェクトＤＢ１６４に格納された情報に基づいて、イベントを達成したことを示す特別なオブジェクトを生成してもよい。

イベントの例としては、“１日の移動距離がちょうど３０ｋｍになる”、“３日連続で朝一番に出勤する”、“ある店舗で１００回以上買い物をする”、“ある店舗の開店時間中に、１日１回以上店舗の前を通過する”、“特定の日時に特定の行動をする（例えば、２０１２年１２月１２日の１２時１２分に建物の１２階にいる）”、“ある店舗に、１年以上前にはよく来ていたが最近１年は来ていない”などがある。こうしたイベント、およびイベントに対応したオブジェクトは、例えば純粋にユーザの楽しみのために設定されてもよいし、後述する地図上へのオブジェクトの表示の実施形態などと組み合わせてマーケティングなどに利用されてもよい。

（１−６．機能構成に関する変形例）
図１０は、本開示の第１の実施形態の機能構成の第１の変形例を示すブロック図である。図１０を参照すると、システム２０は、クライアント１００と、行動認識サーバ２４０と、オブジェクトサーバ２５０とを含む。クライアント１００、行動認識サーバ２４０、およびオブジェクトサーバ２５０は、有線または無線の各種のネットワークによって互いに接続され、必要に応じて通信する。

ここで、クライアント１００は、上記のシステム１０におけるクライアント１００と同様の機能構成を含む。行動認識サーバ２４０は、行動認識部１５２、行動履歴ＤＢ１５４および通信部２６８（図１を参照して説明した通信部１６８と同様）を含む。オブジェクトサーバ２５０は、行動履歴取得部１５６、属性スコア算出部１５８、属性ＤＢ１６０、オブジェクト生成部１６２、オブジェクトＤＢ１６４、ユーザＤＢ１６６、および通信部１６８を含み、付加的に期間選択部１７０および属性選択部１７２の一方または両方を含む。

この例に示されるように、行動認識サーバ２４０とオブジェクトサーバ２５０とは、上記の図１の例におけるサーバ１５０の機能を分散して実現する２つのサーバである。上述のように、サーバ１５０は、単一の情報処理装置、または複数の情報処理装置の協働によって実現されるため、行動認識サーバ２４０とオブジェクトサーバ２５０とは、複数の情報処理装置の協働によって実現されたサーバ１５０の一例ということもできる。もちろん、行動認識サーバ２４０およびオブジェクトサーバ２５０も、それぞれ複数の情報処理装置の協働によって実現されてもよい。また、サーバ１５０が、図１０に示された形とは異なる形で分散して複数の情報処理装置によって実現されてもよい。

図１１は、本開示の第１の実施形態の機能構成の第２の変形例を示すブロック図である。図１１を参照すると、システム３０は、クライアント３００と、オブジェクトサーバ２５０とを含む。クライアント３００とオブジェクトサーバ２５０とは、有線または無線の各種のネットワークによって互いに接続され、必要に応じて通信する。

ここで、クライアント３００は、上記のシステム１０におけるクライアント１００の機能構成に加えて、行動認識部１５２と行動履歴ＤＢ１５４とを含む。オブジェクトサーバ２５０は、図１０を参照して説明したオブジェクトサーバ２５０と同様の機能構成を含む。

図示されているように、本変形例では、行動認識部１５２、および行動履歴ＤＢ１５４が、クライアント側に組み込まれている。例えば、クライアント３００は、センシング部１０２に含まれる加速度センサなどのセンシング結果に基づいて行動認識部１５２でユーザの行動を認識し、その結果を行動履歴ＤＢ１５４に蓄積していてもよい。この場合、オブジェクトサーバ２５０は、例えば定期的に、またはユーザを表象するオブジェクトの生成がクライアント３００から要求されたときに、クライアント３００の行動履歴ＤＢ１５４にアクセスして所定の期間の行動履歴情報を取得する。

このように、本実施形態に係るシステムの機能構成は、サーバ、クライアントを問わず、ネットワーク上の任意の要素に配置されうる。この点に関し、上記の２つの変形例以外にも、さまざまな変形例が実現可能である。例えば、上記の２つの変形例のように、オブジェクトサーバ２５０の行動履歴取得部１５６が、外部の行動履歴ＤＢ１５４から行動履歴情報を取得できるようにすれば、オブジェクトサーバ２５０を提供する事業者が、行動認識サーバ２４０またはクライアント３００で行動認識サービスを提供する別の事業者から行動履歴情報を入手することも可能である。また、複数の行動認識サービスによって取得された行動履歴情報をマージして利用してもよい。例えば、オブジェクトサーバ２５０を提供する事業者は、自らも行動認識サービスを提供し（従ってオブジェクトサーバ２５０は図１に示したサーバ１５０のような機能構成を有しうる）、さらに他の事業者の行動認識サービスによって取得された行動履歴情報を取得して属性スコアの算出およびオブジェクトの生成に利用してもよい。

（２．第２の実施形態）
次に、図１２および図１３を参照して、本開示の第２の実施形態について説明する。この第２の実施形態は、ユーザを表象するオブジェクトが、ユーザの実際の画像に重畳表示するためのオブジェクトであるという点で、上記の第１の実施形態とは異なる。なお、機能構成などそれ以外の部分については、第１の実施形態と同様であるため、重複した詳細な説明は省略する。

図１２は、本開示の第２の実施形態における第１の表示例を示す図である。本実施形態では、サーバ１５０のオブジェクト生成部１６２によって生成されるオブジェクト２１０１が、ユーザの実際の画像２１０３に重畳して表示される。図示された例では、スーツを着用した男性のユーザが、実際の画像２１０３として表示されているところに、麦わら帽子のオブジェクト２１０１が重畳して表示されている。オブジェクト２１０１は、例えば、このユーザが、今はスーツを着用して仕事をしているけれども、週末には家庭菜園の手入れに精を出していることを表すものでありうる。このように、オブジェクトは、仮想空間において表示されるアバターのようなものには限られず、実際のユーザの画像とともに表示される服装やアクセサリー、髪形、ペットなどのオブジェクトであってもよい。

ここで、ユーザの実際の画像２１０３は、例えば、ＡＲアプリケーションなどで提供される実空間の撮像画像や、シースルー型の表示部で透過して見えている実空間の像として視認される。オブジェクト生成部１６２、またはクライアント１００の表示制御部１０６は、こうしたユーザの実際の画像２１０３の位置や姿勢を認識し、それに合わせてオブジェクト２１０１を表示させる。なお、このような表示がされる場合、オブジェクト生成の対象になるユーザと、表示されたオブジェクトを観察するユーザとは、別々のユーザでありうる。

図１３は、本開示の第２の実施形態における第２の表示例を示す図である。図示された例では、図１２の例と同様に、スーツを着た男性のユーザが、実際の画像２１０３として表示されている。オブジェクト２１０５は、例えば、この実際の画像の背景を表示する環境オブジェクトであり、表示されることによってユーザの実際の画像２１０３を隠蔽する。かかるオブジェクト２１０５は、属性スコアに基づいて、ユーザが特定の条件を満たさないことが示される場合に生成されうる。例えば、画像を見る側のユーザが、“スポーツをよくする人”というような条件を設定している場合、スポーツをあまりしないことが属性スコアによって示されるユーザは、オブジェクト２１０５を重畳して表示することによって画像を見る側のユーザの視界から消える。

このような表示は、例えば、多くのユーザが集まったイベント会場などで、声をかける相手を探す場合に、どのユーザが希望している条件に合うユーザかを識別し、声をかけた後のコミュニケーションが成り立ちやすくするために有効である。この場合も、オブジェクト２１０５は、特定の条件を満たしていないという、そのユーザの人となりを反映したオブジェクトであるといえる。

（３．第３の実施形態）
次に、図１４〜図１９を参照して、本開示の第３の実施形態について説明する。この第３の実施形態は、ユーザを表象するオブジェクトが地図上に表示され、その表示に対して何らかの機能を実行することが可能であるという点で、上記の第１の実施形態とは異なる。なお、それ以外の部分については、第１の実施形態と同様であるため、重複した詳細な説明は省略する。

（３−１．機能構成）
図１４は、本開示の第３の実施形態に係るシステムの概略的な機能構成を示すブロック図である。図１４を参照すると、システム４０は、クライアント４００と、サーバ４５０とを含む。クライアント４００とサーバ４５０とは、有線または無線の各種のネットワークによって互いに接続され、必要に応じて通信する。以下、クライアント４００およびサーバ４５０のそれぞれの構成について、さらに説明する。

（クライアント）
クライアント４００は、センシング部１０２を含まない点で、図１を参照して説明したクライアント１００とは異なるが、それ以外の点ではクライアント１００と同様である。クライアント４００は、センシングの結果をサーバに送信せず、専ら他のユーザについて生成されたオブジェクトを含む画像を観察するユーザによって使用される。そのために、クライアント４００は、入力部１０４、表示制御部１０６、および表示部１０８を含む。これらの機能構成の詳細については、上記のクライアント１００と同様であるため、詳細な説明を省略する。

（サーバ）
サーバ４５０は、操作取得部４７４、およびメッセージ送信部４７６を含む点で、図１を参照して説明したサーバ１５０とは異なるが、それ以外の点ではサーバ１５０と同様である。図示されていないが、サーバ４５０は、期間選択部１７０および属性選択部１７２の一方または両方を含んでもよい。

図示された例では、クライアント４００がセンシングの結果をサーバに送信しないため、サーバ４５０の行動認識部１５２は、クライアント４００とは異なる他のクライアントからの情報に基づいて、それらのクライアントを使用するユーザの行動を認識する。従って、行動履歴ＤＢ１５４に格納される行動履歴情報は、クライアント４００のユーザとは異なるユーザの行動履歴情報であり、行動履歴取得部１５６、属性スコア算出部１５８、およびオブジェクト生成部１６２の処理を経て生成されるオブジェクトも、クライアント４００のユーザとは異なるユーザを表象するものである。

つまり、システム４０は、サーバ４５０で他のユーザについて生成されたオブジェクトがクライアント４００で表示され、その表示に対してクライアント４００のユーザが何らかの操作を実行するためのシステムである。以下、かかるシステム４０においてサーバ４５０に含まれる操作取得部４７４およびメッセージ送信部４７６の機能について、さらに説明する。なお、操作取得部４７４およびメッセージ送信部４７６は、いずれも、例えばＣＰＵがメモリに格納されたプログラムに従って動作することによって実現される。

操作取得部４７４は、クライアント４００でユーザの操作を取得した入力部１０４から通信部１６８を介して情報を受信する。ここで受信される情報は、例えば、後述する例のように、地図上に表示されたオブジェクト（オブジェクト生成部１６２によって生成されたオブジェクト）のうちの少なくとも一部を指定する操作を示す情報でありうる。この操作情報では、指定するオブジェクトの種類がさらに指定されてもよい。操作取得部４７４は、取得した情報を、メッセージ送信部４７６に提供する。また、操作取得部４７４は、地図上にオブジェクトを表示させることの要求を取得してもよい。この要求には、例えば、表示させるオブジェクトの種類や、クライアント４００の位置情報などが含まれていてもよい。これらの情報は、オブジェクト生成部１６２に提供されうる。

メッセージ送信部４７６は、操作取得部４７４から取得した情報に従って所定の機能を実行する機能部の一例である。図示された例において、メッセージ送信部４７６は、操作取得部４７４が取得した操作情報によって指定された地図上のオブジェクトに対応するユーザに対して、メッセージの送信を実行する。メッセージの送信先は、例えば行動認識部１５２に行動を認識するための情報を提供したクライアントのうちの少なくとも一部でありうる。メッセージ送信部４７６は、メッセージの送信先の情報を取得するために、ユーザＤＢ１６６を参照してもよい。

（３−２．処理の例）
図１５は、本開示の第３の実施形態で用いられるデータの例を示す図である。図示されたデータは、例えばサーバ４５０でユーザＤＢ１６６に格納されうる。このデータは、各ユーザ（ユーザＡ〜ユーザＤ）について“オブジェクト種類”、“現在位置”、“Ｅ−ｍａｉｌ”の項目を含む。“オブジェクト種類”には、オブジェクト生成部１６２によって生成され、各ユーザに対応付けられたオブジェクトの種類が記録されている。“現在位置”には、ＧＰＳなどを用いて検出された各ユーザの位置情報が、例えば緯度経度によって記録されている。“Ｅ−ｍａｉｌ”には、例えば各ユーザがサービス利用のために登録したメールアドレスが記録されている。

図示された例では、ユーザＡ、ユーザＤについて“サラリーマン”（例えば、仕事に関する属性スコアが比較的高いユーザについて生成されるオブジェクトの種類）、ユーザＢについて“ゴージャス”（例えば、高級品の買い物に関する属性スコアが比較的高いユーザについて生成されるオブジェクトの種類）、ユーザＣについて“スポーツマン”（例えば、スポーツに関する属性スコアが比較的高いユーザについて生成されるオブジェクトの種類）というオブジェクト種類が記録されている。なお、これらのオブジェクト種類は、例えば、ユーザに関するすべての属性スコアに基づいて決定されてもよいし、ユーザが期間選択部１７０や属性選択部１７２などによる何らかの条件を設定した結果として決定されてもよい。

図１６は、本開示の第３の実施形態における処理の例を示すフローチャートである。まず、サーバ４５０において、オブジェクト生成部１６２は、属性スコア算出部１５８が算出した属性スコアに基づいて、定期的にユーザＤＢ１６６に格納されたユーザのオブジェクト情報を更新している（ステップＳ２０１）。これによって、例えば図１５に示す“オブジェクト種類”の項目も更新される。ここで、クライアント４００からオブジェクトの表示要求があった場合（ステップＳ２０３）、サーバ４５０ではオブジェクトの表示のための処理が実行される。

本実施形態では、オブジェクト生成部１６２によって予めオブジェクトが生成され、オブジェクト情報がユーザＤＢ１６６に格納されている。従って、オブジェクトの表示のための処理は、表示要求において表示するオブジェクト種類の選択がある場合に（ステップＳ２０５）、オブジェクト生成部１６２が、ユーザＤＢ１６６に格納されたオブジェクト種類の情報に基づいてどのユーザのオブジェクトを表示するかを選択する（ステップＳ２０７）処理から始まる。他の実施形態では、上記の図３の例のように、属性スコア算出部１５８が属性スコアを算出する、または読み出す処理が実行されてもよいし、さらには行動履歴取得部１５６が行動履歴を取得する処理が実行されてもよい。

次に、オブジェクト生成部１６２は、表示要求に含まれるクライアント４００の位置情報に基づいて、表示するオブジェクトを抽出する（ステップＳ２０９）。このとき抽出されるオブジェクトは、ステップＳ２０７でオブジェクトの種類が選択されている場合、対象になる種類のオブジェクトに限られる。そうではない場合は、種類に関わらずオブジェクトが抽出される。

次に、オブジェクト生成部１６２は、抽出されたオブジェクトを、ユーザＤＢ１６６に格納された対応するユーザの位置情報に基づいて地図にマッピングし（ステップＳ２１１）、オブジェクトがマッピングされた地図情報をクライアント４００に送信する（ステップＳ２１３）。ここで、オブジェクトがマッピングされる地図は、表示要求に含まれるクライアント４００の位置情報に基づいて設定される。

（３−３．表示例）
図１７は、本開示の第３の実施形態における第１の表示例を示す図である。図示された例では、クライアント４００の表示部１０８で、地図３１００上に、ユーザを示すオブジェクト３１０１が表示される。ここでは、オブジェクト３１０１の色がユーザの属性スコアに応じて変化している。つまり、現在の行動を示す属性スコアとして“徒歩”のスコアが算出されたユーザのオブジェクト３１０１ａ（オブジェクト種類“徒歩”のオブジェクト）と、同じく“電車”のスコアが算出されたユーザのオブジェクト３１０１ｂ（オブジェクト種類“電車”のオブジェクト）と、同じく“自動車”のスコアが算出されたユーザのオブジェクト３１０１ｃ（オブジェクト種類“自動車”のオブジェクト）とでは、生成される色のオブジェクトが異なる。図示されているように、この例で生成されるオブジェクトは、円という抽象的な図形であるが、このような場合であっても、例えば色を属性スコアに応じて変化させることで、ユーザの人となりに関する情報（この場合は、どのような手段で移動しているか）を表示することができる。

図１８は、本開示の第３の実施形態における第２の表示例を示す図である。図示された例では、クライアント４００で、図１７の例と同様に地図３１００上にオブジェクト３１０１が表示されているときに、入力部１０４に含まれるタッチパネルなどを用いて、範囲指定図形３１０３が入力されている。また、対象とするオブジェクト種類を指定するために、オブジェクトの凡例部分に選択用のチェックボックス３１０５が表示され、入力部１０４を用いた選択が可能になっている。図示された例では、範囲指定図形３１０３で地図３１００の中央付近に位置するユーザを指定するとともに、チェックボックス３１０５で対象をオブジェクト種類“徒歩”で表示されているユーザに限定している。これによって、例えば、指定された領域内に位置する、指定した属性を有するユーザに対して、限定的にメッセージを配信するといった操作を実行することができる。

このとき、サーバ４５０では、操作取得部４７４が上記の範囲指定図形３１０３の描画およびチェックボックス３１０５の選択によって示されるユーザの操作情報を取得し、メッセージ送信部４７６がメッセージ送信などの機能を実行する。ここで、メッセージ送信部４７６は、例えば図１５に示されたデータの“現在位置”と、地図３１００上での範囲指定図形３１０３によって示される領域とを比較することによって位置の条件を満たすユーザを抽出する。さらに、メッセージ送信部４７６は、“オブジェクト種類”とチェックボックス３１０５によって指定されたオブジェクト種類とを比較することによってオブジェクト種類の条件を満たすユーザを抽出し、抽出されたユーザの“Ｅ−ｍａｉｌ”として示されるアドレスに向けてメッセージを送信する。

以上のような構成によって、例えば、特定の場所にいるユーザの中で、ある属性（オブジェクト種類によって表される）を有するユーザを抽出してメッセージを送るといったような操作を、直感的かつ容易な操作によって実行することができる。なお、属性は、２以上が設定されてもよい。例えば、図１８の例で、オブジェクトが表示されているユーザ全体が“会社員”に限定されている場合（第１の属性による限定）、その中でさらに駅周辺の領域を指定し（位置情報による限定）、さらに徒歩で移動中のユーザに限定して（第２の属性による限定）メッセージを送信することによって、例えば飲食店のランチの広告を、その需要層と推定されるユーザに限定して配信することが可能である。

（３−４．変形例）
図１９は、本開示の第３の実施形態の変形例に係るシステムの概略的な機能構成を示すブロック図である。図１９を参照すると、システム４２は、クライアント４００と、サーバ４５０とを含む。システム４２の構成は、図１４を参照して説明した本実施形態に係るシステム４０と基本的に同様であるが、サーバ４５０の機能部として、メッセージ送信部４７６に代えて投稿受付部４７８が設けられる点で異なる。

投稿受付部４７８は、操作取得部４７４から取得した情報に従って所定の機能を実行する機能部の一例である。図示された例において、投稿受付部４７８は、操作取得部４７４が取得した操作情報によってユーザからの投稿を受け付け、ユーザＤＢ１６６に格納されたオブジェクト情報を参照することによって、ユーザに投稿の資格があるか否かを判定する。ユーザに投稿の資格がある場合、投稿受付部４７８は、通信部１６８を介して、クライアント４００に投稿のための入力画面を送信する。投稿受付部４７８は、例えばＣＰＵがメモリに格納されたプログラムに従って動作することによって実現される。

図２０は、本開示の第３の実施形態の変形例を示すフローチャートである。まず、サーバ４５０において、オブジェクト生成部１６２は、属性スコア算出部１５８が算出した属性スコアに基づいて、定期的にユーザＤＢ１６６に格納されたユーザのオブジェクト情報を更新している（ステップＳ３０１）。これによって、例えば図１５に示す“オブジェクト種類”の項目も更新される。ここで、クライアント４００からレビューの投稿要求があった場合（ステップＳ３０３）、サーバ４５０ではオブジェクト種類による判定のための処理が実行される。なお、ここで、レビューは、飲食店などを利用したユーザが、その店舗について提供する評価などの情報である。

ここで、投稿受付部４７８は、レビューの投稿要求を送信したユーザは、所定のオブジェクト種類に関連付けられているか否かを判定する（ステップＳ３０５）。ここでの判定は、例えば、オブジェクト生成部１６２によって予め生成されたオブジェクトについてユーザＤＢ１６６に格納されたオブジェクト情報に基づいてされてもよい。あるいは、判定のときに、オブジェクト生成部１６２が属性スコアに基づいてオブジェクトを生成し、そのオブジェクトの種類によって判定がされてもよい。なお、上記所定のオブジェクト種類は、例えば、レビュー投稿の対象になる店舗や、レビューが表示されるコミュニティごとに予め設定されている。

ステップＳ３０５において、ユーザが所定のオブジェクト属性に関連付けられている場合、さらに、投稿受付部４７８は、ユーザＤＢ１６６を参照して、ユーザの位置情報が、レビュー投稿の対象になっている店舗の周辺であるか否かを判定する（ステップＳ３０７）。ここで、ユーザの位置情報が店舗の周辺であると判定された場合、投稿受付部４７８は、通信部１６８を介して、レビュー投稿用の画面をクライアント４００に送信する（ステップＳ３０９）。一方、ステップＳ３０５またはステップＳ３０７で否定的な判定がされた場合、投稿受付部４７８は、通信部１６８を介して、レビューの投稿を受け付けられないことを示すメッセージ（投稿ＮＧメッセージ）をクライアント４００に送信する（ステップＳ３１１）。

上記のような処理によって、例えば、店舗についてのレビューを投稿するユーザを、特定の属性を有するユーザに限定（例えば、女性限定、社会人限定、など）することができる。例えば店舗がターゲットにする客層を設定している場合や、レビューが特定の属性を有するユーザを対象にしたコミュニティで公開されるような場合には、このような限定が有効でありうる。また、ユーザの位置を店舗の周辺に限定することによって、実際に店舗を利用したユーザの、利用直後のレビューに限って受け付けることができる。例えば、サクラを排除したい場合や、レビューの鮮度を重視する場合には、このような限定が有効でありうる。

（４．第４の実施形態）
次に、図２１〜図２４を参照して、本開示の第４の実施形態について説明する。この第４の実施形態は、生成されたオブジェクトの表示および共有に関して、上記の第２の実施形態とは異なる。なお、機能構成などそれ以外の部分については、第２の実施形態と同様であるため、重複した詳細な説明は省略する。

図２１は、本開示の第４の実施形態における第１の表示例を示す図である。本実施形態では、ユーザの実際の画像に重畳表示されるオブジェクトが、複数のユーザの間で共有される。つまり、サーバ１５０の行動履歴取得部１５６は、複数のユーザについて行動履歴情報を取得し、属性スコア算出部１５８は、複数のユーザについて属性スコアを算出し、オブジェクト生成部１６２は、複数のユーザが互いに視認可能なオブジェクトを生成する。

一つの例としては、各ユーザが、例えば特開２００８−８３２９０号公報で開示されているような外部を視認可能なＨＭＤ（Head Mounted Display）を装着して行動しており、他のユーザと会ったときに、そのユーザとともにオブジェクトが重畳して表示されるような場合が考えられる。図示された例では、元気そうな男性のユーザが実際の画像４１０３として表示されているところに、不健康そうな男性のオブジェクト４１０１が重畳して表示されている。オブジェクト４１０１は、例えば、このユーザが、実は不摂生な生活をしていることを表すものでありうる。オブジェクト４１０１が表示されることで、このユーザが不摂生な生活をしていることが他のユーザにも知れてしまう。

このように、オブジェクトは、見た目には現れないユーザの状態を示すアバター（分身）として機能しうる。この場合、例えば、他のユーザからも見られるアバターの見た目をよくするために、健康的な生活を実践するなど、実際のユーザの行動を改善するモチベーションが得られる。また、ユーザを限定してアバターの表示を許可したり、アバターに関するコメントなどの評価を送信できるようにすることで、ユーザ間のコミュニケーションの活性化を図ってもよい。また、アバターをユーザ自身からも視認可能にすれば、仮想的にアバターを連れて歩くような感覚が得られ、必ずしも他のユーザとの間でアバターの表示を共有しなくても楽しめる場合がある。

なお、表示されるアバターは、ユーザと同様の性別や年齢の文字通り“分身”であってもよいし、性別が異なったり、人間ではなく動物であったりしてもよい。例えば、男性のユーザが女性のアバターを仮想的なガールフレンドとして連れて歩いてもよいし、動物のアバターをペットのようにして連れ歩いてもよい。ただし、このような場合でも、アバターの見た目にはユーザ自身の行動が反映される。例えば、男性のユーザがアバターとしてガールフレンドを連れ歩く場合、ユーザ自身が不摂生な生活を送っていると、ガールフレンドが不健康そうな見た目になる。また、アバターとしてペットを連れ歩く場合、ユーザ自身が不摂生な生活を送っていると、ペットの見た目が薄汚くなる。このように、必ずしもユーザの文字通り“分身”ではないアバターの表示の場合でも、アバターにはユーザの人となりが反映され、例えば行動の改善のモチベーションが得られたり、親しみがわきやすかったりするという効用が得られうる。

図２２は、本開示の第４の実施形態においてユーザ間の友達登録時にオブジェクトの表示を共有する場合の処理の例を示す図である。まず、ユーザＡが使用する端末Ａで、友達リクエストが送信される（ステップＳ４０１）。ユーザＢが使用する端末Ｂでは、この友達リクエストを受信し（ステップＳ４０３）、承認するか否かが、例えばユーザＢの操作に基づいて判定される（ステップＳ４０５）。ここで、承認されなければ、端末Ａに非承認応答が返送され（ステップＳ４０７）、処理は終了する。

一方、ステップＳ４０５で友達リクエストが承認された場合、端末Ｂは承認応答を送信する（ステップＳ４０９）。端末Ａでは、承認応答を受信した（ステップＳ４１１）後、ユーザＡのオブジェクト情報を端末Ｂに送信する（ステップＳ４１３）。ここで送信されるオブジェクト情報は、例えば上記の第２の実施形態と同様にしてサーバ１５０のオブジェクト生成部１６２において生成され、端末Ａに送信されたものである。端末Ａでは、サーバ１５０から受信したオブジェクトの情報が保存されており、ステップＳ４１３では保存されているオブジェクト情報が送信される。

ここで、端末Ｂは、ユーザＡのオブジェクト情報を受信し、保存する（ステップＳ４１５）。次に、端末Ｂは、ユーザＢのオブジェクト情報を端末Ａに送信する（ステップＳ４１７）。端末Ａは、ユーザＢのオブジェクト情報を受信し、保存する（ステップＳ４１９）。これによって、端末Ａおよび端末Ｂの両方で、お互いのオブジェクト情報が共有される。以後、端末Ａでは実際のユーザＢの画像にユーザＢのオブジェクトを重畳表示し（ステップＳ４２１）、端末Ｂでは実際のユーザＡの画像にユーザＡのオブジェクトを重畳表示する（ステップＳ４２３）ことが可能になる。なお、ユーザＡ、ユーザＢそれぞれの顔などの認識は、予め交換された情報に基づいて端末Ａ、端末Ｂの双方で可能であるものとする。また、上記の処理の後、各ユーザの行動履歴の変化によってオブジェクトが更新された場合には、再度オブジェクトの送信（ステップＳ４１３またはステップＳ４１７）が実行されうる。

なお、上記の図２２では、端末同士がサーバを介さずに通信するＰ２Ｐ（Peer to Peer）方式の場合の例について説明したが、サーバを介した通信によってユーザ間でオブジェクトの表示を共有してもよい。この場合、それぞれの端末装置にオブジェクトを保存する必要はなく、サーバに保存されているオブジェクトの表示対象にお互いを加えるだけでよい（例えば、ユーザＢがユーザＡの初めての友達だとすると、ユーザＡのオブジェクトの表示対象に、それまでのユーザＡ（本人）に加えてユーザＢが設定され、端末Ａおよび端末Ｂの両方でオブジェクトが表示されるようになる）。

図２３は、本開示の第４の実施形態における第２の表示例を示す図である。図示された例では、各ユーザに対応するオブジェクトが、ユーザの身代わりとして対戦する。オブジェクト５１０１ａはユーザＡのアバターであり、オブジェクト５１０１ｂはユーザＢのアバターである。ユーザＡの画面５１００ａには、リングに見立てたノート型ＰＣの上に立ったこれらのオブジェクト５１０１を、オブジェクト５１０１ａの側から見た画像が表示されており、一方のユーザＢの画面５１００ｂには同じ状況をオブジェクト５１０１ｂの側から見た画像が表示されている。上記の図２１の例との相違として、オブジェクト５１０１はユーザの画像に重畳していない。例えば、普段は図２１の例のようにユーザの肩に乗っているアバターが、対戦が開始されると降りてきて相手と戦う、といったような演出があってもよい。

上記の例の場合、サーバ１５０のオブジェクト生成部１６２において生成されるオブジェクト（アバター）には、このような対戦の機能のためのパラメータ（対戦パラメータ）が設定されていてもよい。対戦パラメータは、両方のユーザに共通の属性スコアに基づいて設定されうる。例えば、上記の図５の例の“運動フィルタ”に従って対戦パラメータが設定されてもよい。この場合、例えば消費カロリーの高い行動が多いユーザほど、知力、体力、判断力、集中力、運などといった対戦パラメータが高くなる。従って、日頃から自身を鍛錬しているユーザほど、アバターを用いた対戦でも有利でありうる。

あるいは、対戦パラメータは、ユーザがそれぞれにフィルタなどを用いて設定した属性スコアに基づいて設定されてもよい。この場合、例えば、ユーザがそれぞれ自身の得意な属性のフィルタを指定した上でアバターを生成し、対戦することができる。例えば、ユーザＡが“運動フィルタ”に従って対戦パラメータを設定するのに対して、ユーザＢが“買い物フィルタ”に従って対戦パラメータを設定してもよい。この場合、腕っ節が強いユーザのアバターが対戦に必ずしも勝つとは限らず、何らかの属性で突出した属性スコアを有するユーザが勝つ場合もある。

また、対戦パラメータは、アバターの見た目に反映されてもよいし、反映されなくてもよい。例えば、アバターの見た目を生成するために用いられる生成条件と、アバターに設定される対戦パラメータを生成するために用いられる生成条件とは、別個であってもよい。この場合、例えば、釣りが趣味のプロ野球選手のアバターが、見た目については“余暇の過ごし方”のフィルタが設定されているためにさほど強そうに見えないが、対戦パラメータについては“運動フィルタ”が設定されているためにとんでもなく強い、といったように、見た目と強さとのギャップによってゲーム性を増した対戦が実現される。

図２４は、図２３に示したような表示を実現するための処理の例を示すフローチャートである。図示された例において、端末Ａ、端末Ｂは、それぞれユーザＡ、ユーザＢによって使用される端末である。サーバは、上記の例のサーバ１５０のようにオブジェクトを生成する機能を有するサーバであってもよいし、対戦ゲームのために用意された別のサーバであってもよい。前者の場合、サーバは、例えば上記の第３の実施形態のメッセージ送信部４７６などと同様に、所定の機能を実行する機能部として、対戦ゲームを制御する構成要素を有する。後者の場合、サーバは、予めサーバ１５０から、オブジェクト生成部１６２によって生成されたオブジェクト情報を取得する。

まず、対戦の準備段階として、サーバで、各ユーザのオブジェクト情報に基づいて対戦パラメータを設定する（ステップＳ５０１）。次いで、端末Ａ、端末Ｂで、それぞれ攻撃コマンドの送信（ステップＳ５０３）と守備コマンドの送信（ステップＳ５０５）とが実行される。サーバでは、送信された攻撃、守備コマンドに基づいて、対戦３Ｄグラフィック画像を生成する（ステップＳ５０７）。

続いて、端末Ａ、端末Ｂのそれぞれから、端末のカメラの位置、３次元方向、ズーム率などを示す撮像画像が送信される（ステップＳ５０９，Ｓ５１１）。これを受信したサーバは、撮像画像を比較して、対応する特徴点のうち画面ほぼ中央の基準点を特定する（ステップＳ５１３）。次に、サーバは、基準点を中心とした平面上に、各カメラの位置関係を考慮した３Ｄグラフィック画像をそれぞれ生成し（ステップＳ５１５）、端末Ａ、端末Ｂに、それぞれ異なる３Ｄグラフィック画像を配信する（ステップＳ５１７）。

次に、端末Ａ、端末Ｂは、それぞれが配信された３Ｄグラフィック画像を表示する（ステップＳ５１９，Ｓ５２１）。それぞれの端末の視点が変化した場合、上記のステップＳ５０９〜Ｓ５２１の処理が繰り返される。その後、次のターンの動作として、攻守が交代し、端末Ａが守備コマンドを送信し（ステップＳ５２３）、端末Ｂが攻撃コマンドを送信する（ステップＳ５２５）。以下、同様の処理が繰り返される。

なお、上記の処理は一例であり、本開示の実施形態としては、この他にもさまざまな対戦ゲームが可能である。例えば、必ずしも対戦ゲームの画像は３Ｄでなくてもよいし、攻撃コマンドと守備コマンドとによって進行するゲームでなくてもよい。また、ゲームは対戦ゲームには限られず、ユーザが単独でプレイするゲームであってもよい。この場合も、自らの属性スコアに基づいて生成されたプレーヤキャラクタを操作することで、上記の対戦ゲームの場合と同様の興趣が得られる。

また、本実施形態を通じて、アバターなどのオブジェクトがユーザの実際の画像に重畳される例について説明したが、他の実施形態では、アバターが任意のアプリケーションの画面に表示されてもよい。従って、対戦ゲーム（またはそれ以外のゲーム）も、必ずしも実際の空間にアバターを重畳させるものでなくてよく、通常の２Ｄや３Ｄのゲーム画面と同様の画面で、ユーザのアバターがプレーヤキャラクタになるものでありうる。

（５．ハードウェア構成）
次に、図２５を参照して、本開示の実施形態に係る情報処理装置のハードウェア構成について説明する。図２５は、情報処理装置のハードウェア構成を説明するためのブロック図である。図示された情報処理装置９００は、例えば、上記の実施形態における各種サーバおよびクライアントを実現しうる。

情報処理装置９００は、ＣＰＵ（Central Processing unit）９０１、ＲＯＭ（Read Only Memory）９０３、およびＲＡＭ（Random Access Memory）９０５を含む。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インターフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２３、通信装置９２５を含んでもよい。さらに、情報処理装置９００は、必要に応じて、撮像装置９３３、およびセンサ９３５を含んでもよい。情報処理装置９００は、ＣＰＵ９０１に代えて、またはこれとともに、ＤＳＰ（Digital Signal Processor）などの処理回路を有してもよい。

ＣＰＵ９０１は、演算処理装置および制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９、またはリムーバブル記録媒体９２７に記録された各種プログラムに従って、情報処理装置９００内の動作全般またはその一部を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータなどを記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３、およびＲＡＭ９０５は、ＣＰＵバスなどの内部バスにより構成されるホストバス９０７により相互に接続されている。さらに、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Peripheral Component Interconnect/Interface）バスなどの外部バス９１１に接続されている。

入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置である。入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置９００の操作に対応した携帯電話などの外部接続機器９２９であってもよい。入力装置９１５は、ユーザが入力した情報に基づいて入力信号を生成してＣＰＵ９０１に出力する入力制御回路を含む。ユーザは、この入力装置９１５を操作することによって、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりする。

出力装置９１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置９１７は、例えば、ＬＣＤ（Liquid Crystal Display）、ＰＤＰ（Plasma Display Panel）、有機ＥＬ（Electro-Luminescence）ディスプレイなどの表示装置（シースルー型やヘッドマウント型であってもよい）、スピーカおよびヘッドホンなどの音声出力装置、ならびにプリンタ装置などでありうる。出力装置９１７は、情報処理装置９００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音声または音響などの音声として出力したりする。

ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ（Hard Disk Drive）などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。

ドライブ９２１は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体９２７のためのリーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２１は、装着されているリムーバブル記録媒体９２７に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２１は、装着されているリムーバブル記録媒体９２７に記録を書き込む。

接続ポート９２３は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２３は、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small Computer System Interface）ポートなどでありうる。また、接続ポート９２３は、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（High-Definition Multimedia Interface）ポートなどであってもよい。接続ポート９２３に外部接続機器９２９を接続することで、情報処理装置９００と外部接続機器９２９との間で各種のデータが交換されうる。

通信装置９２５は、例えば、通信ネットワーク９３１に接続するための通信デバイスなどで構成された通信インターフェースである。通信装置９２５は、例えば、有線または無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Wireless USB）用の通信カードなどでありうる。また、通信装置９２５は、光通信用のルータ、ＡＤＳＬ（Asymmetric Digital Subscriber Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２５は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２５に接続される通信ネットワーク９３１は、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。

撮像装置９３３は、例えば、ＣＣＤ（Charge Coupled Device）またはＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。撮像装置９３３は、静止画を撮像するものであってもよいし、また動画を撮像するものであってもよい。

センサ９３５は、例えば、加速度センサ、ジャイロセンサ、地磁気センサ、光センサ、音センサなどの各種のセンサである。センサ９３５は、例えば情報処理装置９００の筐体の姿勢など、情報処理装置９００自体の状態に関する情報や、情報処理装置９００の周辺の明るさや騒音など、情報処理装置９００の周辺環境に関する情報を取得する。また、センサ９３５は、ＧＰＳ（Global Positioning System）信号を受信して装置の緯度、経度および高度を測定するＧＰＳセンサを含んでもよい。

以上、情報処理装置９００のハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。かかる構成は、実施する時々の技術レベルに応じて適宜変更されうる。

（６．補足）
本開示の実施形態は、例えば、上記で説明したような情報処理装置（クライアントまたは各種サーバ）、システム、情報処理装置またはシステムで実行される情報処理方法、情報処理装置を機能させるためのプログラム、およびプログラムが記録された記録媒体を含みうる。

なお、上記で説明した実施形態における各種サーバおよびクライアントは、必ずしもネットワーク上でのサーバまたはクライアントとしての役割を与えられた装置によって実現されなくてもよい。本開示の実施形態は、例えば、いわゆるメッシュネットワークにおいて、それぞれの端末（情報処理装置）が各種サーバまたはクライアントとして動作することによっても実現可能である。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）所定の期間に蓄積されたユーザの行動履歴情報を取得する行動履歴取得部と、
属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出する属性スコア算出部と、
前記属性スコアに基づいて、前記ユーザを表象するオブジェクトを生成するオブジェクト生成部と
を備える情報処理装置。
（２）前記オブジェクトの生成条件を設定する条件設定部をさらに備える、前記（１）に記載の情報処理装置。
（３）前記条件設定部は、前記オブジェクトの生成において強調される前記属性スコアを選択する属性選択部を含む、前記（２）に記載の情報処理装置。
（４）前記条件設定部は、前記所定の期間のうち、前記オブジェクトの生成において強調される期間を選択する期間選択部を含む、前記（２）または（３）に記載の情報処理装置。
（５）前記条件設定部は、前記ユーザの操作に従って前記生成条件を設定する、前記（２）〜（４）のいずれか１項に記載の情報処理装置。
（６）前記条件設定部は、前記オブジェクトが表示される状況に応じて前記生成条件を設定する、前記（２）〜（５）のいずれか１項に記載の情報処理装置。
（７）前記属性スコア算出部は、前記属性群のうちの複数の属性について前記属性スコアを算出し、
前記オブジェクト生成部は、前記各属性の属性スコアの比較に基づいて前記オブジェクトの種類を選択する、前記（１）〜（６）のいずれか１項に記載の情報処理装置。
（８）前記属性群は、所定のイベントを達成したか否かを示す属性を含む、前記（１）〜（７）のいずれか１項に記載の情報処理装置。
（９）前記オブジェクト生成部は、前記ユーザの実際の画像に重畳表示するための前記オブジェクトを生成する、前記（１）〜（８）のいずれか１項に記載の情報処理装置。
（１０）前記オブジェクト生成部は、前記ユーザの実際の画像の背景を表示することによって前記ユーザを隠蔽する前記オブジェクトを生成する、前記（９）に記載の情報処理装置。
（１１）前記オブジェクト生成部は、前記属性スコアに応じて段階的に変化する前記オブジェクトを生成する、前記（１）〜（１０）のいずれか１項に記載の情報処理装置。
（１２）前記オブジェクト生成部は、前記属性スコアに応じて色が変化する前記オブジェクトを生成する、前記（１）〜（１１）のいずれか１項に記載の情報処理装置。
（１３）前記オブジェクト生成部は、地図上に表示するための前記オブジェクトを生成する、前記（１）〜（１２）のいずれか１項に記載の情報処理装置。
（１４）前記地図上に表示された前記オブジェクトの観察者による、該オブジェクトのうちの少なくとも一部を指定する操作に関する情報を取得する操作取得部と、
前記指定されたオブジェクトに対応する前記ユーザに対して所定の機能を実行する機能部と
をさらに備える、前記（１３）に記載の情報処理装置。
（１５）前記操作は、地図上の領域を指定する操作を含む、前記（１４）に記載の情報処理装置。
（１６）前記行動履歴取得部は、複数のユーザについて前記行動履歴情報を取得し、
前記属性スコア算出部は、前記複数のユーザについて前記属性スコアを算出し、
前記オブジェクト生成部は、前記複数のユーザが互いに視認可能な前記オブジェクトを生成する、前記（１）〜（１５）のいずれか１項に記載の情報処理装置。
（１７）ユーザの行動をセンシングするセンシング部と、
前記センシングの結果をサーバに送信し、該センシングの結果を含む情報に基づいて生成される前記ユーザの行動履歴情報を所定の期間蓄積したものに基づいて属性群のうちの１または複数の属性について算出される属性スコアに基づいて生成される前記ユーザを表象するオブジェクトの情報を前記サーバから受信する通信部と、
前記オブジェクトを表示部に表示させる表示制御部と
を備える情報処理装置。
（１８）クライアントおよびサーバを含み、
前記クライアントは、
ユーザの行動をセンシングするセンシング部と、
前記センシングの結果をサーバに送信し、前記ユーザを表象するオブジェクトの情報を前記サーバから受信する通信部と、
前記オブジェクトを表示部に表示させる表示制御部と
を有し、
前記サーバは、
所定の期間に蓄積された、前記センシングの結果を含む情報に基づいて生成される前記ユーザの行動履歴情報を取得する行動履歴取得部と、
属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出する属性スコア算出部と、
前記属性スコアに基づいて前記オブジェクトを生成するオブジェクト生成部と
を有するシステム。
（１９）所定の期間に蓄積されたユーザの行動履歴情報を取得することと、
属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出することと、
前記属性スコアに基づいて、前記ユーザを表象するオブジェクトを生成することと
を含む情報処理方法。
（２０）所定の期間に蓄積されたユーザの行動履歴情報を取得する機能と、
属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出する機能と、
前記属性スコアに基づいて、前記ユーザを表象するオブジェクトを生成する機能と
をコンピュータに実現させるためのプログラム。

１０，２０，３０，４０，４２ システム
１００，３００，４００ 装置
１０２ センシング部
１０４ 入力部
１０６ 表示制御部
１０８ 表示部
１１０ 通信部
２４０ 行動認識サーバ
１５０，２５０ サーバ（オブジェクトサーバ）
１５２ 行動認識部
１５６ 行動履歴取得部
１５８ 属性スコア算出部
１６２ オブジェクト生成部
１６８，２６８ 通信部
１７０ 期間選択部
１７２ 属性選択部
４７４ 操作取得部
４７６ メッセージ送信部
４７８ 投稿受付部

Claims (17)

1. 所定の期間に蓄積されたユーザの行動履歴情報を取得する行動履歴取得部と、
   属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出する属性スコア算出部と、
   前記属性スコアに基づいて、前記ユーザを表象するオブジェクトを生成するオブジェクト生成部と、
   前記所定の期間のうち前記オブジェクトの生成において強調される期間を選択する期間選択部を含み、前記オブジェクトの生成条件を設定する、条件設定部と
   を備える、情報処理装置。
2. 前記条件設定部は、前記オブジェクトの生成において強調される前記属性スコアを選択する属性選択部をさらに含む、請求項１に記載の情報処理装置。
3. 前記条件設定部は、前記ユーザの操作に従って前記生成条件を設定する、請求項１に記載の情報処理装置。
4. 前記条件設定部は、前記オブジェクトが表示される状況に応じて前記生成条件を設定する、請求項１に記載の情報処理装置。
5. 前記属性スコア算出部は、前記属性群のうちの複数の属性について前記属性スコアを算出し、
   前記オブジェクト生成部は、前記各属性の属性スコアの比較に基づいて前記オブジェクトの種類を選択する、請求項１に記載の情報処理装置。
6. 前記属性群は、所定のイベントを達成したか否かを示す属性を含む、請求項１に記載の情報処理装置。
7. 前記オブジェクト生成部は、前記ユーザの実際の画像に重畳表示するための前記オブジェクトを生成する、請求項１に記載の情報処理装置。
8. 前記オブジェクト生成部は、前記ユーザの実際の画像の背景を表示することによって前記ユーザを隠蔽する前記オブジェクトを生成する、請求項７に記載の情報処理装置。
9. 前記オブジェクト生成部は、前記属性スコアに応じて段階的に変化する前記オブジェクトを生成する、請求項１に記載の情報処理装置。
10. 前記オブジェクト生成部は、前記属性スコアに応じて色が変化する前記オブジェクトを生成する、請求項１に記載の情報処理装置。
11. 前記オブジェクト生成部は、地図上に表示するための前記オブジェクトを生成する、請求項１に記載の情報処理装置。
12. 前記地図上に表示された前記オブジェクトの観察者による、該オブジェクトのうちの少なくとも一部を指定する操作に関する情報を取得する操作取得部と、
    前記指定されたオブジェクトに対応する前記ユーザに対して所定の機能を実行する機能部と
    をさらに備える、請求項１１に記載の情報処理装置。
13. 前記操作は、地図上の領域を指定する操作を含む、請求項１２に記載の情報処理装置。
14. 前記行動履歴取得部は、複数のユーザについて前記行動履歴情報を取得し、
    前記属性スコア算出部は、前記複数のユーザについて前記属性スコアを算出し、
    前記オブジェクト生成部は、前記複数のユーザが互いに視認可能な前記オブジェクトを生成する、請求項１に記載の情報処理装置。
15. クライアントおよびサーバを含み、
    前記クライアントは、
    ユーザの行動をセンシングするセンシング部と、
    前記センシングの結果をサーバに送信し、前記ユーザを表象するオブジェクトの情報を前記サーバから受信する通信部と、
    前記オブジェクトを表示部に表示させる表示制御部と
    を有し、
    前記サーバは、
    所定の期間に蓄積された、前記センシングの結果を含む情報に基づいて生成される前記ユーザの行動履歴情報を取得する行動履歴取得部と、
    属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出する属性スコア算出部と、
    前記属性スコアに基づいて前記オブジェクトを生成するオブジェクト生成部と、
    前記所定の期間のうち前記オブジェクトの生成において強調される期間を選択する期間選択部を含み、前記オブジェクトの生成条件を設定する、条件設定部と
    を有するシステム。
16. 所定の期間に蓄積されたユーザの行動履歴情報を取得することと、
    属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出することと、
    前記属性スコアに基づいて、前記ユーザを表象するオブジェクトを生成することと、
    前記所定の期間のうち前記オブジェクトの生成において強調される期間を選択して、前記オブジェクトの生成条件を設定することと
    を含む情報処理方法。
17. 所定の期間に蓄積されたユーザの行動履歴情報を取得する機能と、
    属性群のうちの１または複数の属性について、前記行動履歴情報に基づく前記ユーザの属性スコアを算出する機能と、
    前記属性スコアに基づいて、前記ユーザを表象するオブジェクトを生成する機能と、
    前記所定の期間のうち前記オブジェクトの生成において強調される期間を選択して、前記オブジェクトの生成条件を設定する機能と、
    をコンピュータに実現させるためのプログラム。
    

Images