JP2011523486A - ユーザのステータスを示すためにアバタステータスを自動的に更新するための方法およびシステム - Google Patents

Abstract

セルラーまたはワイヤレスモバイルデバイスは、１つまたは複数のセンサと、１つまたは複数のセンサからのデータ、カレンダデータおよびデバイス設定を受信し、センサ、カレンダ、デバイス設定データ、および要求側ユーザの許可レベルをアバタ選択基準と比較し、その比較に基づいてアバタを選択するようにソフトウェアを用いて構成されたプロセッサとを含む。センサデータ、カレンダデータおよびデバイス設定をユーザの現在のステータスと相関させることによって、アバタ選択基準は、プロセッサが、ユーザの現在のステータスを反映するアバタを自動的に選択することを可能にする。次いで、他者は、ユーザのアバタにアクセスすることによってユーザの現在のステータスを知ることができる。

Description

本発明は、一般に、コンピュータによって生成されたアバタを介してユーザのステータスまたはアクティビティの現在の指示を与えることに関する。

コンピューティングの意味では、アバタはコンピュータユーザの仮想表現である。「アバタ」という用語は、インターネットユーザのスクリーンネームまたはハンドルに接続されたパーソナリティを指すこともある。アバタは、コンピューティングの仮想世界において現実の世界のユーザを表すためにしばしば使用される。アバタは、バーチャルリアリティアプリケーションおよびコンピュータゲームにおいて使用される３次元モデルとすることができる。アバタは、インターネットフォーラムおよび他のオンラインコミュニティ、インスタントメッセージング、ゲームおよび非ゲームアプリケーションにおいて使用される２次元アイコン（ピクチャ）とすることもできる。アバタは、アニメーション化されている場合も静的な場合もある。

アバタという用語は、少なくとも、一連のコンピュータゲームにおいてプレーヤのキャラクタの名前として使用された１９８５年にさかのぼる。最近、アバタの使用が普及し、アバタは現在インターネットフォーラムにおいてしばしば使用されている。インターネットフォーラム上のアバタは、ユーザおよびユーザの行為を表し、フォーラムへのユーザの寄与を個人化するという目的を果たし、フォーラムにおいてユーザの人格、信念、興味または社会的地位の様々な部分を表すことができる。

たいていのインターネットフォーラム上で使用される従来のアバタシステムは、アバタが配置されるユーザのフォーラムポストに近接する、小さい（たとえば、９６×９６〜１００×１００ピクセルの）方形エリアである。いくつかのフォーラムでは、ユーザは、ユーザによってデザインされたかまたは他の場所から収集されたアバタ画像をアップロードすることができる。他のフォーラムでは、ユーザは、プリセットリストからアバタを選択するか、または自動発見アルゴリズムを使用してユーザのホームページからアバタを抽出することができる。

インスタントメッセージング（ＩＭ）コンテキストでは、アバタは、バディアイコンと呼ばれることがあり、通常小さい画像である。たとえば、ＩＭアイコンは４８×４８ピクセルであるが、一般にどこでも５０×５０ピクセルから１００×１００ピクセルまでのサイズを測定する多くのアイコンをオンラインで発見することができる。多種多様なこれらの画像化されたアバタは、ウェブサイトおよびＹａｈｏｏ！グループなどの普及しているｅグループ上で発見できる。インスタントメッセージングにおけるアバタの最新の使用は、ダイナミックアバタが大半を占める。ユーザは、チャットの間ユーザを表すアバタを選択し、テキスト音声技術を使用して、アバタがチャットウィンドウにおいて使用されているテキストを話せるようにする。この種のアバタを使用するための別の形態はビデオチャット／ビデオ呼用である。Ｓｋｙｐｅなどの（いくつかの外部プラグインを介した）いくつかのサービスでは、ビデオ呼中に話すアバタを使用することができ、ユーザのカメラの画像の代わりにアニメーション化された話すアバタを使用することができる。

ユーザの現在の現実の世界のステータスまたはアクティビティのより正確な表現を与えるために、ユーザの仮想世界アバタを自動的に更新する様々な実施形態システムおよび方法を開示する。実施形態は、ユーザの現実の世界環境のいくつかのパラメータを与えるためにユーザのモバイルデバイス内に、またはモバイルデバイスに極めて近接して位置する様々なセンサから情報を受信することができる。様々なセンサは、ロケーションセンサ（たとえば、ＧＰＳ座標）、周囲雑音を感知するためのマイクロフォン、周辺光を感知するためのカメラまたは光センサ、加速度計、温度センサ、および飲酒検知器、心拍数モニタ、パルスセンサ、ＥＥＧ、ＥＣＧ、ＥＫＧ、および／または血圧センサなどのバイオ生理学的センサを含むことができるが、これらには限定されない。さらに、実施形態は、ユーザのカレンダデータならびにモバイルデバイス設定を利用して、ユーザの現実の世界のステータスまたはアクティビティのアバタを介した更新された仮想表現を生成することができる。代替実施形態は、ユーザが年をとり、より成熟するにつれて、ユーザのアバタが年をとり、より成熟するように、時間とともにユーザのアバタの年をとらせることができる。様々な実施形態は、ユーザがユーザの日々のアクティビティを行うにつれて、ユーザのアバタを自動的に更新または変更する。他の実施形態は、アバタを閲覧したいという要求が行われると、ユーザのアバタを更新または変更する。ユーザのアバタは、ウェブページなど、単一のロケーションにおいて閲覧できる。代替実施形態では、ユーザのアバタを任意の要求側当事者へダウンロードすることができる。さらに他の実施形態は、アバタを送信することによってユーザの現在の現実の世界のステータスまたはアクティビティを選択された当事者にプロアクティブに知らせることができる。

本明細書に組み込まれ、本明細書の一部をなす添付の図面は、本発明の例示的な実施形態を示し、上記の概略的な説明および下記の詳細な説明とともに、本発明の特徴を説明するのに役立つ。

様々な実施形態での使用に好適な例示的なアバタを示す図。 様々な実施形態での使用に好適なシステムのシステムブロック図。 様々な実施形態での使用に好適なモバイルデバイスのシステムブロック図。 システム上での実装に好適な一実施方法のプロセスフロー図。 モバイルハンドセット上での実装に好適な特定の実施方法のプロセスフロー図。 ユーザの現在のステータスを示す様々なセンサデータ、ユーザカレンダデータ、およびモバイルデバイス設定を記憶するのに好適な例示的なパラメータデータテーブルを示す図。 様々なパラメータに基づいて表示すべきアバタを示す例示的なアバタ選択論理テーブルを示す図。 アバタ選択論理テーブルを較正するための一実施方法のプロセスフロー図。 バッテリおよびプロセッサ時間を節約するモバイルハンドセット上での実装に好適な一実施方法のプロセスフロー図。 サーバ要求に応答するモバイルハンドセット上での実装に好適な一実施方法のプロセスフロー図。 第２のユーザ要求に応答するモバイルハンドセット上での実装に好適な一実施方法のプロセスフロー図。 アバタ選択がサーバにオフロードされる別の実施方法のプロセスフロー図。 アバタ選択が、バッテリおよびプロセッサ時間を節約するサーバにオフロードされる別の実施方法のプロセスフロー図。 アバタ選択が、サーバ要求に応答することによってバッテリおよびプロセッサ時間を節約するサーバにオフロードされる別の実施方法のプロセスフロー図。 アバタ選択が、第２のユーザ要求に応答することによってバッテリおよびプロセッサ時間を節約するサーバにオフロードされる別の実施方法のプロセスフロー図。 要求側デバイス上にアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。 要求側デバイス上に新しいアバタまたは更新されたアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。 バッテリおよびプロセッサ時間を節約する要求側デバイス上にアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。 バッテリおよびプロセッサ時間を節約する要求側デバイス上に新しいアバタまたは更新されたアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。 第２のユーザ要求に応答することによってバッテリおよび処理時間を節約する要求側デバイス上にアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。 第２のユーザ要求に応答することによってバッテリおよび処理時間を節約する要求側デバイス上に新しいアバタまたは更新されたアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。 アバタ選択が要求側ユーザのデバイスにオフロードされる要求側デバイス上に直接アバタを表示するのに好適な別の実施方法のプロセスフロー図。 システム上での実装に好適な代替実施方法のプロセスフロー図。 様々なセンサデータ、ユーザカレンダデータ、モバイルデバイス設定およびアバタを要求するユーザの許可レベルを記憶するのに好適な例示的なパラメータデータテーブルを示す図。 要求側ユーザの許可レベルを含む様々なパラメータに基づいて表示すべきアバタを示す例示的なアバタ選択論理テーブルを示す図。 要求側ユーザの許可レベルを含むアバタ選択論理テーブルを較正するための一実施方法のプロセスフロー図。 要求側ユーザの許可レベルを含むアバタ選択論理テーブルに基づいて表示のためにアバタを選択するための一実施方法のプロセスフロー図。 要求側ユーザの許可レベルを含むアバタ選択論理テーブルに基づいて表示のためにアバタを選択するための別の実施方法のプロセスフロー図。 要求側ユーザの許可レベルを含むアバタ選択論理テーブルに基づいて表示のためにアバタを選択するための別の実施方法のプロセスフロー図。 要求側ユーザの許可レベルを含むアバタ選択論理テーブルに基づいて表示のためにアバタを選択するための別の実施方法のプロセスフロー図。 センサおよび設定データ、ならびに第２のユーザの許可レベルに基づいて選択されたアバタを要求側デバイス上に直接表示するのに好適な別の実施方法のプロセスフロー図。 センサおよび設定データ、ならびに第２のユーザの許可レベルに基づいて選択された新しいアバタまたは更新されたアバタを要求側デバイス上に直接表示するのに好適な別の実施方法のプロセスフロー図。 センサおよび設定データ、ならびに第２のユーザの許可レベルに基づいて選択されたアバタを要求側デバイス上に直接表示するのに好適な別の実施方法のプロセスフロー図。 センサおよび設定データ、ならびに第２のユーザの許可レベルに基づいて選択された新しいアバタまたは更新されたアバタを要求側デバイス上に直接表示するのに好適な別の実施方法のプロセスフロー図。 センサおよび設定データ、ならびに第２のユーザの許可レベルに基づいて要求側デバイス上にアバタを直接表示するのに好適な別の実施方法のプロセスフロー図。

様々な実施形態について添付の図面を参照しながら詳細に説明する。可能な場合はいつでも、同じまたは同様の部分を指すために図面全体にわたって同じ参照番号を使用する。特定の例および実装形態になされる言及は、説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。

本明細書で使用するモバイルデバイスという用語は、セルラー電話、個人情報端末（ＰＤＡ）、パームトップコンピュータ、ラップトップコンピュータ、ワイヤレス電子メール受信機（たとえば、ＢｌａｃｋＢｅｒｒｙ（登録商標）およびＴｒｅｏ（登録商標）デバイス）、マルチメディアインターネット対応セルラー電話（たとえば、ｉＰｈｏｎｅ（登録商標））、およびプログラマブルプロセッサとメモリとを含む同様のパーソナル電子デバイスのうちのいずれか１つまたはすべてを指す。好ましい一実施形態では、モバイルデバイスは、セルラー電話ネットワーク（たとえば、セルフォン）を介して通信することができるセルラーハンドセットである。しかしながら、セルラー電話通信機能は、すべての実施形態において必要というわけではない。その上、ワイヤレスデータ通信は、セルラー電話ネットワークの代わりにワイヤレスデータネットワーク（たとえば、ＷｉＦｉネットワーク）に接続するモバイルデバイスによって達成できる。

本明細書で使用する「サーバ」という用語は、クライアントサーバアーキテクチャにおいて動作するように構成された様々な市販のコンピュータシステムのいずれかを指す。特に、「サーバ」という用語は、一般に、プロセッサと、メモリ（たとえば、ハードディスクメモリ）と、サーバプロセッサをインターネットなどのネットワークに接続するように構成されたネットワークインターフェース回路とを含むネットワークサーバ、特にインターネットアクセス可能なサーバを指す。

本明細書で使用する「テーマ」という用語は、ユーザ選好に合わせてモバイルハンドセットを個人化するためにモバイルハンドセット上に実装できるユーザ構成可能設定の集合を指す。テーマは、壁紙（すなわち、モバイルハンドセットディスプレイ上に提示される画像）、呼出し音（すなわち、様々なイベントによってトリガされるオーディオファイル）、呼出し設定（たとえば、大、中、小、サイレント、ならびにバイブレートモード）、ボタントーン（すなわち、ボタンが押されたときに再生されるトーン）、ボタン機能、表示アイコン、およびスピードダイヤル設定（すなわち、スピードダイヤル用に構成された各ボタンに関連する電話番号）のうちのいずれかおよびすべてのために使用されるファイルおよび設定によって定義される。テーマは、パスワード保護、キーパッドロック、キャリア選択などのような他のユーザ構成可能設定の設定をも含むことができる。そのようなデータから構成されるテーマは、ファイル（たとえば、画像およびオーディオファイル）ならびに構成データ（たとえば、特定のスピードダイヤルボタンに関連する電話番号）のミックスとして記憶できる。

現代のコンピューティングおよびモバイル通信の出現により、個人は様々な方法でいつでも互いに通信することができる。過去において、個人が別の個人と通信したい場合、対面会話、手紙、または電話によって通信を行うことができた。今日、これらの従来の通信の手段に加えて、個人は、電子メール、ＳＭＳ、インスタントメッセージング、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）呼、ビデオオーバーインターネットプロトコル呼、インターネットフォーラムチャット、およびモバイルデバイス（ハンドセット）呼を介した電話通信によって互いに通信することができる。通信の極めて多くの様々なチャネルを用いて、個人は、望むときはいつでも他者と連絡することができると予想している。しかしながら、一部の個人は、妨害されないことを望むことがある。たとえば、ある個人は、重要な会議を行っていることがあり、会議中に自分のモバイルデバイスが鳴ることを望まない。その個人は、自分のモバイルデバイス（またはリンガー）を単にオフにすることもあるが、自分が一時的に対応できない理由を発呼者に知らせることを望むこともある。モバイル通信は非常にユビキタス的であるので、多くのユーザは、自分の予定呼受信者にいつでも連絡することができると予想している。したがって、予定受信者が電子メール、ＳＭＳ、電話呼などに返答しないとき、開始発呼者はしばしば、予定受信者がなぜ応答しないのだろうと思わされる。

アバタは、個人のグラフィカル表現として使用するのにますます人気を得ている。アバタは、（スクリーンネームなどの）テキストあるいは２次元または３次元グラフィカル表現（たとえば、写真、漫画または機械生成画像）とすることができる。アバタは静止画像または動画（アニメーション）画像とすることができる。いくつかのアバタの例を図１に示す。図１に示すように、アバタは、職業、趣味、現在のアクティビティおよびムードなど、関連する個人に関する情報をグラフィカルに伝える画像とすることができる。歴史的に、ユーザは、オンラインゲームまたはインターネットフォーラムチャットにおいてユーザまたはユーザの人格の表現としてアバタを使用してきた。アバタは、まさにアバタの特徴によって、ユーザの興味など、ユーザに関する情報を効率的に伝えることができる。従来、ユーザは、オンラインゲーム、インターネットフォーラムチャット、ＳＭＳチャットなどに参加しているユーザの表現を表示するようにアバタを選択するであろう。このようにして、選択されたアバタファイルを使用して、コンピューティングまたは電子通信の仮想世界において現実の世界のユーザを表すことができる。本明細書で開示する様々な実施形態は、ユーザが、仮想世界においてユーザの現実の世界のステータスをよりぴったり表すアバタを生成またはポスティングすることを可能にする。

モバイルデバイス、特にセルラー電話は、実際にユビキタス的であり、不可欠なものである。したがって、モバイルデバイスは、ユーザの環境およびアクティビティを測定することができるセンサを格納するための理想的なプラットフォームとなることができる。ユーザモバイルデバイス上に取り付けられたセンサから得られる動き、音、ロケーションおよび他の感知された情報を適切に分析することによって、コンピュータシステムは、ユーザアクティビティを推測し、様々な実施形態において、ユーザの現実の世界のアクティビティを反映するようにユーザのアバタを更新するために使用できる情報を推測することができる。たとえば、ユーザのモバイルデバイスは、ユーザの現在のＧＰＳロケーションがオフィス内の会議室であるということを「学習」することができる。したがって、モバイルデバイスは、モバイルデバイスをバイブレートモードに自動的に設定し、「取り込み中（do not disturb）」を示すようにユーザのアバタを自動的に更新することができる。

様々なセンサからのデータを含めることによって、様々な実施形態は、ユーザのモバイルデバイス中に格納された様々なセンサを援用または利用し、センサ情報を使用して、ユーザのステータス、ロケーション、ムードおよび／またはアクティビティを反映するために表示できるアバタを更新または生成する。様々な実施形態は、ユーザのステータスをより正確に反映するために、様々なセンサを採用し、モバイルデバイス内で維持されるスケジュールまたはカレンダ情報にアクセスすることができる。ユーザの現在のステータス、ロケーション、ムードおよび／またはアクティビティを閲覧者に迅速に知らせるために、そのようなアバタをパブリックまたはプライベート閲覧のために利用可能にすることができる。そのようなアバタは、ＳＭＳまたは電子メールメッセージに添付するかまたはその中に含めるなど、プロアクティブに他者に送信するか、あるいは、アバタが維持されるオンラインゲームまたはウェブサイトにアクセスすることなどによって他者がアバタにアクセスするかまたはそれをダウンロードすることができるサーバにポスティングすることが可能である。ユーザのステータスに従って事前スケジュールベース（たとえば、周期更新）で、（たとえば、アバタの要求に応答して）ユーザのステータスが要求されたときはいつでも、あるいはユーザのステータスが変化したとき（たとえば、センサがユーザのロケーション、ムードおよび／またはアクティビティが変化したことを示すとき）はいつでも、アバタを変化させることができる。

図２は、本明細書で開示する様々な実施形態での使用に好適なコンピューティングおよび電気通信システムのシステムブロック図である。システムブロック図は、例示的なセルラーネットワークシステムを示し、すべての可能な構成を企図するものではない。図２に示すように、様々なアクティビティに関与する様々なユーザは、様々なモバイルデバイスを所持していることがある。たとえば、第１のユーザは、コーヒーショップ内でラップトップコンピュータ１０１を使用していることがある。第２のユーザは、ＰＤＡ１０２を携帯して空港でショッピングをしていることがある。第３のユーザは、セルフォン１０３を持って自動車を運転していることがある。第４のユーザは、会議を行い、セルフォン１０４を携帯していることがある。モバイルデバイス１０１、１０２、１０３、および１０４の各々は、ワイヤレスネットワークを介してワイヤレス通信基地局１０５と通信することができる。ワイヤレス通信基地局１０５は、セルフォンタワー、Ｂｌｕｅｔｏｏｔｈ（登録商標）受信機、ＷｉＦｉ受信機、または他のワイヤレストランシーバとすることができる。好ましい一実施形態では、デバイスは、セルラー電話およびデータネットワークを介してセルラー基地局アンテナ１０５と通信する。ワイヤレス通信基地局１０５は、インターネット１０８に接続するためにルータ１０６およびワイヤレス通信サーバ１０７に結合できる。インターネット１０８への代替経路は、より多いまたはより少ない通信機器を含むことがある。たとえば、いくつかのワイヤレスサービスプロバイダは、それらのユーザにインターネット１０８へのアクセスを与えるために追加のサーバを必要とすることがある。代替的に、ワイヤレス通信基地局は、インターネット１０８へのより直接的なリンクを可能にすることができる。

モバイルデバイスのユーザは、互いに通信し、またはインターネット１０８を通して接続された他のユーザと通信することができる。たとえば、第１のユーザは、そのユーザのラップトップ１０１からデスクトップコンピュータ１１３のユーザ、ＰＤＡ１１４のユーザ、ラップトップコンピュータ１１５のユーザに、または他のユーザのセルフォン１１６、１１７を介して他のユーザに、電子メールを送信することができる。そのような場合、ユーザは、基地局１０５にワイヤレス送信されるであろう電子メールをラップトップ１０１から送信するであろう。電子メールは、ルータ１０６を介してサーバ１０７に送信され、インターネット１０８上で、予定受信者のコンピューティングデバイスにサービスしているサーバ１１０に送信され、ルータ１１１に送信され、ワイヤード接続を介してデスクトップコンピュータ１１２に、またはワイヤレス基地局１１２を介してモバイルデバイス１１４〜１１７に送信されるであろう。同様に、受信者は、逆の方法でユーザに応答し、またはユーザへの通信を開始することができる。

モバイルデバイスユーザは、時々着信メッセージに応答することができず、ユーザがなぜ応答しないかを説明するために、ユーザの現在のステータスの何らかの指示を与えることを望むことがある。代替的に、モバイルデバイスユーザは、他者が、ユーザが通信することができるかどうかを知ることができるように、他者にユーザの現在のステータスに関して知らせることを望むことがある。さらに、一部のユーザは、ユーザのソーシャルネットワーキングライフスタイルの一部としてユーザの現在のステータスおよびアクティビティをユーザの友人および家族に知らせることを望むことがある。ユーザのステータスのそのような通知は、選択された個人がアクセスすることができるアバタ、または選択された個人に提示できるアバタを使用して、効率的に達成できる。

そのようなアバタは、たとえば、ユーザソーシャルネットワーキングウェブページ（たとえば、ｍｙｓｐａｃｅ．ｃｏｍ、ｆａｃｅｂｏｏｋ．ｃｏｍなど）またはインターネットアクセス可能なサーバ上で維持される他のウェブページ上で維持および表示できる。アバタは、ウェブページのコンテンツおよびその中に含まれるデータとともに、サーバ１０９のメモリに記憶できる。サーバ１０９は、インターネット１０８に接続され、インターネット１０８の機能および適切なアクセス権をもつデバイスによってアクセスできる。

一実施形態では、ユーザは、通信する（たとえば、発呼、電子メールの送信またはＳＭＳメッセージの送信）より前に、現在ステータスアバタを表示するためにウェブページにアクセスすることなどによって、ある人のアバタにアクセスすることができる。別の実施形態では、ユーザがある人と通信しようと試みるとき、その人が応答しない場合、またはその人が「取り込み中」オプションを選択している場合、現在ステータスアバタを含んでいるウェブページにユーザを自動的に導くことができる。別の実施形態では、アバタファイルを表示のためにユーザのデバイス１１３〜１１７に自動的に直接返送することができる。別の実施形態では、ユーザのステータスが変化したときはいつでも、あるいは定期的にスケジュールされたまたは所定の間隔で、アバタファイルを受信者の事前承認されたリストにプロアクティブに送信することができる。別の実施形態では、ユーザのステータスが変化したときはいつでも、あるいは定期的にスケジュールされたまたは所定の間隔で、アバタを含むユーザのウェブページへのリンクを受信者の事前承認されたリストに送信することができる。当業者なら諒解するように、アバタファイルがユーザのデバイス１１３〜１１７に直接送信されている場合、サーバ１０９は必要でないことがある。さらに、アバタは、様々なサーバ１０７、１１０上でホスティングでき、特定のサーバ１０９に限定される必要はない。

感知され記録された情報に基づいてアバタを自動的に更新することに加えて、一実施形態は、ユーザが、ユーザの現在のステータスにかかわらず特定のアバタを選択するために自動更新をオーバーライドすることを可能にする。したがって、ユーザは、ある時にはユーザのアバタにユーザの現在のステータスを反映させることを選択し、またある時には特定のアバタを選択することができる。別の実施形態では、ユーザはまた、特定のアバタを、だれが、いつ、どんなアクティビティ中に閲覧することができるかを制御するために、アバタのパーミッションまたは許可レベルを設定することができる。たとえば、ユーザは、ユーザの監督者が勤務時間中のみ特定のアバタを閲覧できるようにすることを選択することができる。勤務時間外には、アバタを非表示にすること、送信しないこと、またはアバタにビジーなどの一般的ステータスを反映させることができる。そのような実施形態では、ユーザは、パブリックである情報およびアバタを設定することができる。そのような実施形態は、ウェブサイト上または一般的ブロードキャストでアバタを更新する際に使用できる。

ユーザのモバイルデバイス内のセンサからの情報を使用して、アバタをどのように更新すべきかを判断することができる。モバイルデバイス１０１〜１０４の各々は、それぞれのユーザのステータスを判断するために使用される情報を与えることができる様々なセンサを含むことができる。様々なセンサの例について以下でより詳細に説明する。さらに、日、時間、およびモバイルデバイス設定は、それぞれのユーザのステータスに関するさらなる情報を与えると考えることができる。さらに、モバイルデバイス自体の動作ステータスは、ユーザのステータスに関する情報を与えることができる。

たとえば、ユーザが定期的にコーヒーショップを訪問し、店のワイヤレスＷｉＦｉネットワークを使用する場合、このステータスは、（１）特にブレークが定期的またはスケジュールされている場合、時刻および曜日（ＴＯＤ／ＤＯＷ）、（２）あるいはＴＯＤ／ＤＯＷ情報と組み合わせた、ＷｉＦｉトランシーバの活動化、（３）あるいはＴＯＤ／ＤＯＷ情報と、ＷｉＦｉトランシーバの活動化と組み合わせた、ＧＰＳ（または他のロケーションセンサ）座標、（４）あるいはＴＯＤ／ＤＯＷ情報と、ＷｉＦｉトランシーバの活動化と、ＧＰＳ座標情報と組み合わせた、デバイスのマイクロフォンによってピックアップされる背景雑音（たとえば、エスプレッソマシンの独特の音）に基づいて判断できる。加速度計（あるとしてもわずかな動きを示す）と温度（屋内ロケーションに一致する周囲温度を示す）とを含む他のセンサも、ユーザのステータスがコーヒーブレークに一致することを確認することができる。ユーザが、ユーザのコーヒーブレークをスキップしたか、病気で家にいたか、または休暇中だった場合、ＴＯＤ／ＤＯＷ情報のみに基づくアバタ表示は、ユーザの現在のステータスを不正確に示すであろう。モバイルデバイスのＧＰＳセンサをさらに参照することによって、システムは、ユーザがコーヒーショップロケーション内（またはその近く）にいるかどうかを判断することができる。背景雑音感知を使用して、システムは、エスプレッソマシン雑音を認識してコーヒーブレークステータスを確認することができる。ユーザの現在のステータスのこの判断が行われると、システム（ユーザのモバイルデバイス１０１またはデバイス１０１から情報を受信しているサーバ１０９のいずれか）は、このステータスをグラフィカルに示すアバタを選択または生成することができる。さらに、デバイスのマイクロフォンが所定の限界を超えた雑音レベルを検出した場合、ユーザの周囲環境を反映するようにアバタを改変することができる。これは、アバタを閲覧している人がユーザに連絡することを望んだ場合、非言語的通信手段（たとえば、テキストメッセージ）が最良の通信形態であることをその人に示唆することができる。

別の例として、（たとえば、モバイルデバイスのマイクロフォンを使用して）ユーザのムードを推測するために使用できる音楽および他の音について背景雑音を監視することができる。たとえば、背景雑音が一層アップテンポのビートをもつ音楽を含む場合、楽しいムードを表すアバタを選択することができる。この例が示すように、使用されるセンサの数および考慮される情報の多様性を増加させることによって、システムは、ユーザの現在のステータスをより良く推測することができる。

別の例として、飛行機に乗っているユーザステータスは、ＴＯＤ／ＤＯＷ情報をユーザのカレンダ情報と比較することによって判断できる。ユーザに飛行機フライトがスケジュールされており、相反する情報（たとえば、ユーザのモバイルデバイス１０２とのオープンなＷｉＦｉ接続）がない場合、システム（ユーザのモバイルデバイス１０１またはデバイス１０１から情報を受信しているサーバ１０９のいずれか）は、このステータスをグラフィカルに示すアバタを選択または生成することができる。航空会社が、モバイルデバイスがフライト中に通信できるようにし始めた場合、モバイルデバイス１０２はまた、ステータスの確認を可能にするために航空移動に一致するセンサ情報を報告することができる。たとえば、常に変化するモバイルデバイス１０２からのＧＰＳデータ、モバイルデバイス１０２上のセンサからの加速度計データおよび／または気圧データをすべて使用して航空移動を確認することができる。

別の例として、自動車を運転しているかまたは自動車に乗っているユーザを、ＧＰＳロケーション情報および加速度計センサ読みと組み合わせたＴＯＤ／ＤＯＷ（たとえば、ラッシュアワーに一致する時間および日）に基づいて判断することができる。モバイルデバイス１０３からの常に変化するＧＰＳデータおよび加速度計データを使用して、ユーザのステータスが運転中であることを確認することができる。

別の例として、業務会議中のセルフォン１０４のユーザのステータスを、ユーザのカレンダと比較したＴＯＤ／ＤＯＷ情報から推測することができる。ＴＯＤ／ＤＯＷおよびカレンダ情報はセルフォン１０４および／またはサーバ１０９内で維持できる。そのような予備判断は、ＧＰＳロケーション情報、加速度計および温度センサ読みなどの他のセンサ情報、ならびにセルフォン１０４の動作設定を考慮することによって確認できる。たとえば、ユーザがユーザのモバイルデバイス１０４をバイブレートまたはサイレント呼出しに切り替えた場合、これらの設定は、ユーザが会議中であることに一致し、ユーザのステータスを確認するのを助ける。同様に、ＧＰＳロケーションが会議室に一致し、加速度計の読みが著しい動きをほとんど示さず、温度が屋内ロケーションに一致する場合、この情報を使用して、ユーザが会議中であることを確認することができる。ユーザのステータスがそのように推測されると、適切なアバタファイルを選択または生成することができる。

別の例として、セルフォン１０４のユーザは、休暇の間、現在のステータスを表示する代わりに設定されたアバタ（たとえば、ハンモックの中で寝ているアバタ）を表示するように選択することができる。この例では、センサデータを中継しないか、または設定されたアバタを通信するようにセルフォン１０４を構成することができ、あるいはセンサデータおよびＴＯＤ／ＤＯＷ情報を無視し、選択されたアバタを表示するようにサーバ１０９を構成することができる。

ユーザのステータスを推測するために様々なセンサおよび情報源を使用する際に、いくつかのセンサまたはパラメータに、特に互いに、より高い優先度を与えることができる。たとえば、ＧＰＳロケーションが、カレンダ情報によって示されるロケーションとは異なるときなど、ＧＰＳロケーション情報はカレンダ情報＋ＴＯＤ／ＤＯＷをオーバーライドすることができる。そのような矛盾した情報を扱うために、論理ルールを生成することができる。さらに、現在のステータスに関するユーザ入力および設定は、すべてのセンサ、電話設定、またはカレンダパラメータデータをオーバーライドすることができる。

図３に、概観システムでの使用に好適なモバイルデバイスの一実施形態の構成要素ブロック図を示す。典型的なモバイルデバイス３０１は、マイクロプロセッサ３９１と、メモリ３９２と、アンテナ３９４と、ディスプレイ３９３と、英数字キーパッド３９６と、４方向メニューセレクタロッカースイッチ３９７と、スピーカー３８８と、マイクロフォン３８９と、ボコーダ３９９と、受信機３９５と、送信機３９８と、（併せてセルラーネットワークトランシーバ）および様々な回路と、これらの構成要素の間のバスおよび電気的相互接続とを含むことができる。さらに、モバイルデバイス３０１は、周囲雑音レベルを検出するためにマイクロフォン３８９に接続された周囲雑音センサ３５０を含むことができる。周囲雑音センサ３５０はまた、スピーカーフォン動作のためのマイクロフォンとして機能することができる。モバイルデバイス３０１はまた、写真を撮ることに加えて周辺光レベルを測定するために使用できるカメラ３５１を含むことができる。モバイルデバイスはまた、周辺温度センサ３５２と、モバイルデバイス３０１の相対加速度を検出する１つまたは複数の加速度計３５３とを含むことができる。モバイルデバイスはまた、モバイルデバイス３０１の正確なグローバル位置を判断するためにＧＰＳ衛星から信号を受信するように構成されたＧＰＳ受信機回路３５４を含むことができる。モバイルデバイスはまた、ユーザの呼気から血中アルコール濃度（ＢＡＣ）を測定するように構成された飲酒検知器センサ３５５を含むことができる。たとえば、血圧モニタ、脈拍数センサ、ＥＥＧ、ＥＣＧ、ＥＫＧなどの他の生体センサを含めることもできる。ＥＥＧセンサが含まれる実施形態では、ＥＥＧセンサが集中レベルに一致する脳波パターンを示す場合、たとえば、集中しているユーザのアバタを表示することができる。代替的に、ＥＥＧセンサがリラックスレベルに一致する脳波パターンを示す場合、ユーザがリラックスした精神状態にあることを示すようにユーザのアバタを表示することができる。

モバイルデバイス３０１のセンサ３５０〜３５６の各々はプロセッサ３９１に接続され、プロセッサ３９１は内部メモリユニット３９２に接続される。このようにして、プロセッサ３９１は、各種のセンサ３５０〜３５６からパラメータデータを収集し、データをメモリユニット３９２に記憶するか、または送信機３９８を介してデータを送信することができる。モバイルデバイス３０１は、図３ではモバイルハンドセットまたはセルフォンとして示されているが、システムブロックは、ワイヤレス通信機能をもつ任意のモバイルデバイス中に見られることに留意されたい。このようにして、ラップトップコンピュータ、ＰＤＡまたは同様のデバイスなどの他のモバイルデバイスを表すことができる。

図３に示す各種のセンサを使用して、より正確にユーザのステータスおよびアクティビティを推測することができる。たとえば、飲酒検知器センサ３５５が、ユーザのＢＡＣが０．１％を上回り、ユーザが酒気帯びである可能性を示していると判断した場合、障害を示すようにユーザのアバタを選択または生成することができる。別の例として、加速度計がジョギングに一致するリズミカルな動きを感知した場合、ユーザが運動していることを示すようにアバタを選択または生成することができる。ユーザがジョギングペースで移動しているのか医療施設にいるのかを判断するために、加速度計センサ情報に基づく、この推測されたステータスをＧＰＳ読みと比較して確認することができる。また、モバイルデバイス３０１が血圧または脈拍数センサ（図示せず）を含む場合、センサ値が運動に一致するかどうかを判断するために、そのようなセンサからの情報を調べることができる。そのようなセンサは、ランニングまたはサイクリングを、同様の加速度計およびＧＰＳ情報を生じる可能性がある自動車、バスまたは列車での移動と区別することを可能にすることができる。

図３は、モバイルデバイス３０１のプロセッサ３９１に電気的に結合された各種のセンサ３５０〜３５６を示しているが、様々な外部センサと通信するために、ＷｉＦｉトランシーバ３５６などのワイヤレストランシーバと短距離ワイヤレストランシーバ（ＳＲＷＴｘ）３５７とを組み込むことができる。当業者なら、短距離ワイヤレス通信トランシーバ３５７は、Ｂｌｕｅｔｏｏｔｈ（登録商標）プロトコルトランシーバ、ＺｉｇＢｅｅプロトコルトランシーバ、または他の技術／プロトコルのトランシーバとすることができることを諒解されよう。

図４に、様々な実施形態において採用される基本プロセスステップを示す。第１のステップとして、モバイルデバイス３０１のプロセッサ３９１は、プロセッサ３９１に接続されたセンサ（たとえば、３５０〜３５５）の一部または全部をポーリングする（ステップ４０１）。上述のように、センサは、中距離から長距離のワイヤレストランシーバ３５６を介してプロセッサ３９１にワイヤレス接続された外部センサ、および／またはモバイルデバイス３０１内に含まれる短距離ワイヤレストランシーバ３５７を含むことができる。センサはまた、各種の利用可能なポートまたはカスタムインターフェース回路によってプロセッサ３９１に結合できる。さらに、プロセッサ３９１は複数のプロセッサを含むことができ（すなわち、プロセッサ３９１はマルチプロセッサチップとすることができ）、いくつかのセンサは、プロセッサに結合されるかまたはプロセッサとインターフェースしており、他のセンサは、マルチプロセッサ内で第２のプロセッサに結合されるかまたは第２のプロセッサとインターフェースしている。センサをポーリングする際、プロセッサ３９１は、センサデータがバッファされるデータレジスタにアクセスするか、またはセンサ（またはセンサインターフェース回路）に信号を送信して、センサに読みを取るように指示し、センサデータを受信するのを待つ。センサがモバイルデバイス３０１の外部にある場合、プロセッサ３９１は、ワイヤードまたはワイヤレスデータ接続を介してデータ要求メッセージをセンサに送信し、次いで同じデータリンクを介して応答メッセージ中のセンサデータを受信するのを待つ。代替的に、プロセッサ３９１は、促すことなしにセンサ（たとえば、３５０〜３５５）の各々によって送信されたデータを単に受信する。

センサデータを受信した後、受信しながら、または受信する前に、プロセッサ３９１はまた、メモリ３９２に記憶されたカレンダデータを検索する（ステップ４０２）。上述のように、カレンダデータを使用して、モバイルデバイス３０１のユーザのアクティビティおよびロケーションを推測することができる。カレンダデータは、特定の時刻および曜日について得ることができる。このステップの一部として、プロセッサ３９１は、データレジスタに記憶された現在の時間および日を得ることもできる。

センサデータおよびカレンダデータを受信した後、受信しながら、または受信する前に、プロセッサ３９１は様々なモバイルデバイス設定を検索する（ステップ４０３）。そのようなデバイス設定は、選択されたリンガータイプ（たとえば、サイレントまたは可聴）と、テーマ設定と、通常またはローミング通信モードと、バッテリ電力レベルと、ユーザが電話で話し中かモバイルブラウザ上でインターネットにアクセスしているかなど現在のセルラー通信ステータスと、ユーザが現在ＷｉＦｉネットワークに接続されているかどうかなど現在のワイヤレス通信ステータスと、ユーザが現在Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイスを使用しているかどうかなど現在のローカルエリアワイヤレスネットワークステータスとを含むことができる。これらのモバイルデバイス設定および動作状態の各々は、ユーザのステータスに関する情報を与えることができる。たとえば、ユーザが、カジュアルなテーマ（たとえば、風変わりな壁紙、音楽リンガーなど）を表示するようにモバイルデバイス３０１を設定した場合、これは、ユーザが業務または仕事のアクティビティに従事していないことを示すことができる。

様々な実施形態の各々では、本明細書で説明する方法ステップの順序は、図に示す順序とは異なることがある。たとえば、センサデータを収集するステップは、モバイルデバイス設定およびカレンダデータを収集するステップの後に実行できる。このようにして、デバイス設定によって与えられるかまたはユーザのカレンダで示される情報を使用して、ユーザのアクティビティに関する初期推測を行い、選択されたセンサデータによって初期推測を確認するかまたはさらに改良することができる。たとえば、デバイス設定が、セルラー通話が進行中であることを示す場合、ユーザのステータス（セルフォンで通話中）はすでに確立されており、判断すべきものはロケーションだけなので、ＧＰＳセンサのみをポーリングするようにモバイルデバイスプロセッサ３９１を構成することができる。別の例として、カレンダデータが、ユーザが会議中であることを示す場合、プロセッサ３９１は、そのステータスを確認するのに必要なセンサのみをポーリングするようにソフトウェアを用いて構成できる。

モバイルデバイスセンサから収集された情報と記憶されたデータおよび設定とを使用して、プロセッサは、ユーザの現在のステータスを推測し、アバタのグループのうちのどのアバタを表示すべきかを判断する（ステップ４０４）。様々な実施形態において、この判断を行うために様々なプロセッサを使用することができる。一実施形態では、モバイルデバイス３０１のプロセッサ３９１は、そのメモリ３９２に記憶された基準に基づいて、表示のためにアバタを選択するようにソフトウェア命令を用いて構成される。そのような実施形態では、モバイルデバイス３０１によって表示のために選択されたアバタを別のコンピューティングデバイス１１３〜１１７にアップロードすることができる。たとえば、一実施形態では、選択されたアバタを電子メールまたはＳＭＳメッセージへの添付として別のモバイルコンピューティングデバイスに送信することができる。別の実施形態では、モバイルデバイスは、受信コンピュータが、与えられたＵＲＬまたは他のアドレスにアクセスすることによってアバタを得ることができるように、ＵＲＬまたは他のネットワークアドレスを別のコンピューティングデバイスに送信することができる。別の実施形態では、モバイルコンピューティングデバイス３０１は、受信コンピューティングデバイスがそれ自体のメモリからアバタを得ることができるように、選択されたアバタファイルのメモリ記憶ロケーションを示すメモリポインタを別のコンピューティングデバイスに送信することができる。アバタファイルがサーバ１０９のメモリ（たとえば、ハードディスクメモリ）に記憶されている場合、この実施形態を採用することができ、それによって、サーバが、選択されたアバタをユーザのウェブページにロードすることが可能になる。他のコンピューティングデバイス１１３〜１１７とともに、この実施形態を採用することもできる。

他の実施形態では、モバイルコンピューティングデバイス３０１は、アバタ判断（ステップ４０４）が受信コンピューティングデバイスのプロセッサによって実行できるように、センサ、カレンダ、および設定データを、サーバ１０９または他のコンピューティングデバイス１１３〜１１７など別のコンピューティングデバイスに送信することができる。そのような実施形態では、コンピューティングデバイスのプロセッサがアバタ判断を行う前に、センサ、カレンダ、および設定データを受信し、メモリに記憶する。

表示すべき適切なアバタを判断した後、コンピューティングデバイス１１３〜１１７上での表示のためにアバタファイルを利用可能にする（ステップ４０５）。一実施形態では、コンピューティングデバイス１１３〜１１７は、（たとえば、モバイルデバイス３０１によって通信されたアドレスまたはメモリポインタを使用して）メモリに事前記憶されたアバタファイル、あるいはモバイルデバイス１０１〜１０４またはサーバ１０９のいずれかからダウンロードされたアバタファイルにアクセスすることによって、選択されたアバタを表示する。別の実施形態では、サーバ１０９によってホスティングされるインターネットウェブページの一部としてアバタにアクセスし、アバタを表示することができる。別の実施形態では、アバタがユーザの年齢を反映するように、アバタファイルを毎年更新するか、または何らかの他の時間期間で更新することができる。ユーザが成熟し、年をとるにつれて、より年老いて、より成熟したアバタを表示するように様々なアバタファイルを更新することができる。たとえば、アバタファイルは、ユーザの実際の外観にふさわしいように、白髪になったユーザあるいは体重が減ったまたは増えたユーザを示すことができる。このようにして、適切なアバタファイルがアクセスまたは検索されるとき、アバタはユーザの年齢を正確に反映することになる。

様々な実施形態の特定のプロセスフローステップについて、次に図５〜図２６を参照しながらより詳細に説明する。

図５は、表示すべきアバタがモバイルデバイス３０１によって判断され、ユーザの現在のステータスを反映するように常に更新される第１の実施方法のプロセスフロー図である。本実施形態では、モバイルデバイス３０１のプロセッサ３９１は、モバイルデバイス３０１に関連するセンサ（たとえば、３５０〜３５６）の各々を周期的にポーリングする（ステップ４０１）。このステップでは、プロセッサ３９１は、各種のセンサの各々をポーリングし、関連するセンサデータを受信し、モバイルデバイスメモリ３９２内の適切なデータレコードに記憶するループを実行する。プロセッサ３９１はまた、メモリ３９２に記憶されたカレンダデータを調べる（ステップ４０２）。カレンダデータは、現在の時間において、ユーザの予想される所在地と、ユーザが従事していることが予想される特定のアクティビティとを示すことができる。プロセッサ３９１はまた、現在のテーマを含むモバイルデバイスの様々な設定を調べる（ステップ４０３）。上記のように、プロセッサ３９１がデータを得る順序は、必ずしも重要ではなく、実装形態の間で異なることがある。プロセッサ３９１は、センサ、カレンダ、および設定データのすべてをパラメータ値テーブルに記憶する（ステップ４０９）。パラメータ値テーブルについては、以下で図６ａを参照しながらより詳細に論じる。

プロセッサ３９１は、パラメータデータテーブルに記憶されたデータを評価して（ステップ４１０）、どのアバタを表示すべきかを判断する（ステップ４１１）。様々な方法実施形態を使用して、記憶されたパラメータデータを評価し、表示のために特定のアバタを選択することができる。好ましい一実施形態では、データテーブルに記憶されたパラメータを、図６ｂに示す値など選択テーブルに記憶された値と比較する。以下でその図を参照しながらより詳細に説明するように、ユーザは、そのような選択テーブルに、関連する選択基準を入力することによって、特定のアバタを選択するようにユーザのモバイルデバイスをプログラムすることができる。このようにして、ユーザは、選好および設定に合わせてモバイルデバイスを容易に構成することができる。本実施形態では、プロセッサ３９１は、パラメータデータテーブルに記憶されたパラメータによって最大の数の選択基準が満たされるアバタを選択することによって、表示すべきアバタを判断する（ステップ４１１）。

別の実施形態では、ソフトウェアにプログラムされた論理ツリーでパラメータデータを評価することができる。この例示的な実施形態では、プロセッサ３９１は、実行される特定のステップ（たとえば、一連の「Ｘの場合、Ｙ」論理テスト）がいくつかのパラメータ値に依存する、ソフトウェアルーチンを実行する。プログラムされた論理ツリールーチンの使用により、より高速に動作できるようなるが、本実施形態では、ユーザが構成することがより困難になり、ユーザ選択オプションがより少なくなることがある。

適切なアバタを選択した後、プロセッサ３９１は、選択されたアバタをワイヤレスまたはセルラーネットワークとインターネット１０８とを介してサーバ１０９に送信するように送信機３９８に指示する（ステップ４１５）。このステップでは、プロセッサ３９１は、選択されたアバタファイル、選択されたアバタファイルを含んでいるメモリへのポインタまたはアドレス、あるいはサーバ１０９がそのメモリ内の対応するアバタファイルの位置を特定するために使用することができる選択されたアバタの識別子を送信することができる。

選択されたアバタがサーバ１０９に送信されると、プロセッサ３９１は、表示されたアバタを頻繁に更新するために、パラメータ値を得るステップを周期的に反復することができる。ユーザが適切なアバタを生成し、個々のアバタを様々なパラメータ値に適切にリンクするようにモバイルデバイスを構成した場合、本実施形態は、サーバ１０９がユーザの現在のステータスを反映するアバタを表示することを可能にすることができる。一実施形態では、プロセッサ３９１は、プロセッサ３９１に対する要求を低減するために、パラメータ値を得るステップを反復する前に所定の時間量の間、随意に休止する（ステップ４５０）。

サーバ１０９は、表示すべき特定のアバタを示す送信されたデータを受信する（ステップ４２０）。サーバ１０９のサーバプロセッサ（別個に図示せず）は、パブリック表示のために、選択されたアバタファイルをサーバ１０９上でホスティングされるユーザ用のウェブページ中に含める（ステップ４３０）。第２のユーザがユーザのウェブページにアクセスする（ステップ４４０）とき、サーバ１０９はアクセス要求を受信する（ステップ４３１）。応答して、サーバ１０９は、選択されたアバタファイルをもつウェブページをＨＴＭＬファイルとして第２のユーザのコンピューティングデバイス１１３〜１１７に送信する（ステップ４３２）。受信コンピューティングデバイス１１３〜１１７は、次いで、選択されたアバタを第２のユーザに表示する（ステップ４４１）。モバイルデバイスプロセッサ３９１はアバタ選択を頻繁に更新しているので、本実施形態は、第２のユーザが第１のユーザウェブページにアクセスする（ステップ４４０）ときはいつでも、第１のユーザの現在のステータスを反映するアバタが表示される（ステップ４４１）ことを保証する。センサおよび設定データのポーリングおよび分析は自律的に実行されるので、他者に提示されるユーザのアバタは、ユーザによる入力なしにユーザの現在のステータスに一致して維持される。

様々な実施形態で、図６ａにその例を示す様々なデータ構造を使用することができる。図示のように、センサ（たとえば、３５０〜３５６）からのデータ、ユーザのカレンダ、およびモバイルデバイス設定データは、パラメータ値テーブル６００に記憶できる。そのようなデータは、絶対値（すなわち、未加工センサ情報）の形態、または処理済み情報（すなわち、解釈されたセンサ情報）の形態で記憶できる。この区別は、情報がパラメータ値テーブル６００に記憶される前に行われる情報の処理の量に基づいて変わる。たとえば、図６ａは、未加工地理的定点座標値が、解釈され、ロケーションのユーザ作成テーブルと比較された、パラメータ値テーブル６００に記憶された処理済みＧＰＳセンサ情報を示し、この情報により、モバイルデバイス３０１は、デバイスが現在「トラック」に位置し、約４ｍｐｈの速度で移動していることを認識することができる。同様に、周囲雑音センサ３５０からの未加工データが処理され、３０ｄＢ未満という認識された特性がパラメータ値テーブル６００に記憶される。同様に、周辺光センサ３５１のデータが処理され、「明るい」という認識された特性がパラメータ値テーブル６００に記憶される。同様に、加速度計３５３のデータが処理され、様々な加速値（ｇ）および加速（周期的）という認識された特性として記憶される。未加工センサデータはまた、パラメータ値テーブル６００に直接記憶できる。たとえば、８７度Ｆの温度センサデータがテーブルに記憶される。同様に、現在、ユーザのカレンダに何も記憶されていないということが、データなし、またはカレンダデータベース中にデータが存在しないことを示すシンボルのいずれかとしてパラメータ値テーブル６００に記憶される。同様に、モバイルデバイス３０１上で採用された特定の壁紙および呼出し音設定（「大」）がパラメータ値テーブル６００に記憶される。

図６ａに示すパラメータ値テーブル６００に記憶された処理済みデータ値は、説明のためのものにすぎない。当業者なら諒解するように、センサおよび設定データは、プロセッサ３９１によって解釈できるデジタルデータとして記憶される可能性が高い。たとえば、特定の範囲または値に一致するものとして認識される処理済みデータは、シンボルまたはバイナリ値として記憶できる。

パラメータ値テーブル６００に記憶されたセンサおよび設定データを用いて、この情報を、その例示的な例を図６ｂに示すアバタ選択論理テーブル６０１に記憶された基準と容易に比較することができる。

アバタ選択論理テーブル６０１は、表示すべき適切なアバタを判断するコンピューティングデバイスのメモリに記憶できる。したがって、モバイルデバイス３０１が、図５を参照しながら上述したように、表示すべきアバタを判断した場合、アバタ選択論理テーブル６０１はコンピューティングデバイス３０１のメモリに記憶されることになる。対照的に、アバタ選択がサーバ１０９によって行われた場合、アバタ選択論理テーブル６０１は、サーバプロセッサに結合されたハードディスクメモリに記憶できる。同様に、別のコンピューティングデバイス１１３〜１１７がアバタ選択を行った場合、アバタ選択論理テーブル６０１はそのデバイス上で記憶されるであろう。さらに、アバタ選択論理テーブル６０１は２つ以上のコンピューティングデバイス上で記憶できる。たとえば、アバタ選択論理テーブル６０１は、モバイルデバイス３０１上、ならびにユーザのアバタおよびウェブページをホスティングするサーバ１０９上で記憶できる。さらに、アバタ選択論理テーブル６０１の様々なバージョンは様々なコンピューティングデバイス上で記憶でき、ユーザは、選択を行うために使用されている特定のコンピュータに基づいてアバタ選択基準を変えることができる。したがって、アバタ選択論理テーブル６０１は、どの実施形態が実装されるかに応じて、これらのデバイスの各々に関連するメモリに記憶できる。さらに、アバタ選択論理テーブル６０１は、受信コンピューティングデバイスがアバタ選択を行うことを可能にするために、あるデバイスから別のデバイスに送信できる。

アバタ選択を実行するためにアバタ選択論理テーブル６０１を使用することは、より多くのユーザフレキシビリティとプロセスに対する制御とを与える。様々な実施形態は、ユーザのパーソナルな選好およびアクティビティを反映するアバタを提示するためのフレキシブルで正確な手段をユーザに与えることを意図する。したがって、ユーザが選んだアバタを選択し、表示するために使用されるプロセスに対する細かい制御をユーザに与えることに利益がある。アバタ選択論理テーブル６０１の使用はまた、多くのセンサおよび設定基準が採用されるときのユーザのセットアッププロセスを単純化する。ユーザが、アバタ選択基準を変更するか、あるいは所与の時間に提示されたアバタを手作業で制御することを可能にするために、モバイルデバイス上にネイティブアプリケーションを与えることができる。

表示のために選択されたアバタファイルが様々なパラメータに基づいて選択されるように、ユーザはアバタ選択論理テーブル６０１をカスタマイズすることができる。このカスタマイゼーションはユーザセットアッププロセス中に達成できる。また、ユーザ自身のアバタビヘイビアをカスタマイズするために、ユーザがパーソナル選択を行うユーザセットアッププロセス中に、アバタ選択基準を選択し、アバタ選択論理テーブル６０１をポピュレートすることができる。そのようなセットアッププロセスは、コンピューティングデバイス上で実行する対話型メニューアプリケーションを用いて達成できる。そのような対話型メニューアプリケーションは、アバタを作成し、修正し、記憶するためのユーザツール、ならびにアバタ選択論理テーブル６０１をプログラムするためのメニューを含むことができる。アバタを作成するためのプロセスの一部として、そのようなメニューアプリケーションは、アバタ選択論理テーブル６０１に保存できる各アバタの名前または記述子を割り当てることをユーザに要求する。アバタが作成されると、またはすべてのアバタが作成された後、メニューアプリケーションは次いで、各アバタを選択するための基準として使用すべき値または範囲を入力するようにユーザを促し、ユーザの応答をアバタ選択論理テーブル６０１の適切なフィールドに記憶する。

たとえば、図６ｂは、ユーザが、「仕事」と題され、データレコード６１０として記憶されたアバタを定義したアバタ選択論理テーブル６０１を示す。たいていのユーザの場合、「仕事」アバタは、ユーザの職業に従事するユーザのグラフィック表現を示す。この例では、仕事アバタのための選択基準は、オフィスのロケーションおよびＧＰＳセンサによって記録された低い速度と、低い周囲雑音と、「明るい」周辺光条件と、（たとえば、着席または歩行に一致する）０または低い加速度計読みと、（会社ロゴなどの）職業上の壁紙設定とを含む。仕事アバタ選択基準は、その特定のアバタのユーザのステータスを解決するのに役立つ可能性がないとユーザが予想する、いくつかのパラメータの値を含まないことがある。たとえば、ユーザは、周囲温度、カレンダおよび呼出し音値が、仕事アバタを選択するための追加の協議値を与えないと決定している。第２の例として、アバタ選択論理テーブル６０１は、データレコード６１１として記憶された「会議」アバタを含む。仕事アバタに類似したこのアバタの場合、ユーザは、５０ｄＢよりも大きい周囲雑音基準を設定し、呼出し音＝「サイレント」基準を追加した。

代替的に、モバイルデバイスは、ユーザが、センサおよび設定データを記録しながらアクティビティを実行し、次いで、記録された値に関連付けるべきアバタを識別することによって、アバタ選択論理テーブルをポピュレートできるようにするソフトウェアアプリケーションを用いてプログラムできる。たとえば、特定のトラック上で頻繁にジョギングするユーザは、そのトラックにおいてジョギング較正プロセスをアクティブにすることによってアバタ選択論理テーブルを較正することができる。較正プロセスでは、モバイルデバイス３０１は、アクティビティ中にセンサ値およびデバイス設定を記録し、値を平均化し、平均または範囲をアバタ選択論理テーブル６０１内に記憶することができる。このようにして、モバイルデバイスは、トラックのＧＰＳ座標と、ジョギング中のユーザの速度範囲と、周囲雑音と、光および温度条件と、ジョギング中の加速度計読みとを記録することができる。特に、いくつかのセンサ値は、較正プロセス中に認識され、記録される特定のアクティビティ中の特性パターンを示すことができる。たとえば、加速度計は、値の周期的加速と足運びに一致する周期性とに基づいて、ユーザがジョギングしているときを認識することが可能である。モバイルデバイス３０１はまた、アクティビティ中にユーザによって選択されるデバイス設定を記録することができる。

図６ｃに、アバタ選択論理テーブルを完成するのに好適な例示的な実施形態較正方法を示す。プロセスを開始するために、ユーザは、較正すべき特定のアバタを選択する（ステップ６１０）。このアバタは、すでにユーザによって作成され、名前を与えられていることがある。代替的に、ユーザは、これから作成すべきアバタのための名前を入力することができる。ユーザは、次いで、モバイルハンドセット上の特定のキーを押すことなどによって、アクティビティを開始し、較正を開始する（ステップ６１２）。アクティビティ中に、モバイルデバイス３０１は、このセンサデータおよびデバイス設定を記録する（ステップ６１４）。いくつかのセンサでは、これは、時間ベースパターンを認識することができるように、各記録の時間とともに、ある時間期間にわたってセンサ読みを記録することを含むことができる。ある時間期間の後、モバイルデバイス上の特定のキーを押すことなどによって、ユーザは較正を終了する（ステップ６１６）。代替的に、ステップ６１６が自動的に行われるように、プリセットされた時間量の間、較正を続けることができる。

較正データ収集が完了すると、モバイルデバイス３０１のプロセッサ３９１は、よく知られている統計的プロセスを使用して、記録されたセンサデータを分析することができる。たとえば、平均センサ値とセンサ値の標準偏差とを判断するために、センサデータを統計的に分析することができる。この計算を使用して、特定のアクティビティを特徴づける範囲（すなわち、＋／−）値をもつ平均を与えることができる。代替的に、最大値および最小値を判断するためにセンサデータを分析し、それによって、アクティビティ中の測定の実際の範囲を判断することができる。この分析は、アクティビティ（たとえば、ジョギングトラックの周囲）の境界を判断するために、特にＧＰＳ座標値に適している。加速度計読みが、ジョギングまたは歩行中の場合のように周期的に変動するか、他のアクティビティの場合のようにランダムに変動するかなど、値の特性を判断するためにセンサデータを時間的に分析することもできる。エスプレッソマシンの音など特定の雑音パターンを検出し、記録するために、記録された周囲雑音を処理することなど、データのより高度な分析を同様に採用することができる。分析後、分析されたセンサデータおよびモバイルデバイス設定の結論をアバタ選択論理テーブル６０１中のアバタ名を含むデータレコードに記憶する（ステップ６２０）。アバタ選択論理テーブル６０１はモバイルデバイス３０１のメモリ３９２に記憶できる。ユーザは、ユーザのアバタのすべてに対して基準が保存されるまで、較正のためにアバタを選択し、モバイルデバイス３０１に較正ルーチンを実行させながら関連するアクティビティに従事し、分析されたセンサデータをアバタ選択論理テーブル６０１に記憶するプロセスを反復することができる。随意に、アバタ選択論理テーブル６０１が完成したとき、ユーザのアバタがホスティングされるサーバ１０９など別のコンピューティングデバイスにテーブルを送信する（ステップ６２２）。

ユーザは、特定のアバタのための較正または基準を更新するため、または新たに作成されたアバタのための選択基準を追加するために、図６ｃに示すプロセスをいつでも反復することができる。

ユーザは、ユーザの様々なアクティビティのＧＰＳ座標を知らないことがあり、周囲雑音およびアクティビティの加速度計特性を正確に推定できる可能性がないので、この自己較正方法により、アバタ選択基準をセットアップするプロセスが単純になる。さらに、ユーザは様々なアクティビティがユーザのモバイルデバイスにどのように影響を及ぼすかを認識することができず、したがって、この実施方法は、ユーザが認識しないものでも、記録可能な限り多くのセンサおよび設定値に基づいてアバタが選択されることを可能にする。たとえば、コーヒーショップは、エスプレッソマシンの音など、ユーザが注目しない、いくつかの特性背景雑音を有することがある。

図６ｂに示すアバタ選択アバタ選択論理テーブル６０１は、単に説明のためのものである。モバイルデバイス３０１中に含まれるセンサおよび設定に応じて、より多いまたはより少ない選択基準をテーブルに含めることができる。ユーザが、表示すべきアバタがより少数のパラメータを使用して判断できると決定した場合、同じく、より少数のパラメータをアバタ選択テーブルに含めることができる。アバタ選択テーブル中の各アバタに関連する特定のパラメータは例示にすぎず、個々のユーザの選好に従って改変されることになる。

パラメータ値テーブル６００に記憶された値に基づいて特定のアバタを選択するために、（モバイルデバイス３０１、サーバ１０９、または別のコンピューティングデバイス中にある）プロセッサは、各値を、アバタ選択論理テーブル６０１中の対応する基準と比較することができる。どのアバタの選択基準が、パラメータ値テーブル６００中の値のいずれかによって最もぴったり満たされるかを判断するために、様々なアルゴリズムを採用することができる。いくつかの実装形態では、満たされた基準の数の単純な合計は、割り当てるべき適切なアバタを判断するのに十分である。一実施形態では、アバタを選択するときにいくつかの測定されたセンサ値がより大きい重みを与えられるように、選択された基準に重み係数を適用することができる。別の実施形態では、１つまたは２つの基準を使用して、現在のステータスの予備判断を行い、続いて、確認する基準とのパラメータ値の比較を行う。たとえば、ＧＰＳおよびカレンダデータを特定のアクティビティの主要なインジケータとして使用し、雑音、光および加速度計データを使用して、ＧＰＳロケーションまたはカレンダエントリによって示されるアクティビティを確認することができる。たとえば、パラメータ値テーブル６００に記憶されたＧＰＳ値は、データレコード６１８のランニングアバタのための基準に最もぴったり一致する。次いで、加速度計データをアバタ選択論理テーブル６０１中の対応する基準と比較することによって、ランニングアバタを適切な選択として確認することができる。この例では、加速度計データは、アクティビティを、トラックに沿った運転またはトラックの近くでの歩行と区別する。パラメータ値テーブル６００に記憶された値とアバタ選択論理テーブル６０１中の基準とのそのような比較を行うことによって、プロセッサは、「ランニング」アバタを表示すべきであると決定することができる。別の実施形態では、モバイルデバイス３０１は、それが現在のアクティビティ（ランニングなど）を正しく診断したかどうかをユーザに尋ねるか、またはユーザに現在のアクティビティに名前をつけるように依頼するようにソフトウェア命令を用いて構成できる。この方法は、モバイルデバイス３０１が、パラメータが所望の基準を満たすときを「学習」することを可能にすることができる。代替的に、アバタファイルおよびアバタ選択論理テーブルがリモートサーバ上でホスティングされる実施形態では、他の前のユーザのアバタ選択論理テーブルを使用して、新しいユーザのための新しいアバタ選択論理テーブルをポピュレートすることができる。たとえば、いくつかの前のユーザが、特定のＧＰＳロケーション（トラック）と、加速度計読みと、雑音、光などのセンサ読みとを含むセンサデータのセットに「ジョギング」アバタを割り当てた場合、サーバ上で実行している人工知能ルーチンは、較正ルーチン中にセンサデータの同じまたは類似したセットが生成されたとき、新しいユーザに「ジョギング」アバタを推薦することができる。人工知能ルーチンは、割り当てられたアバタと対応するセンサデータとのパターンまたは共通性を識別するために、ホスティングされたアバタ選択論理テーブルの各々を分析することができる。これらのパターンを識別することによって、サーバは、較正プロセス中に収集されたセンサデータに基づいてアバタを推薦することができる。

多くのアクティビティに対して、ＧＰＳセンサロケーションおよび速度データは、表示すべきアバタの優れた指示を与える。しかしながら、多くの状況において、複数のアバタが同じＧＰＳロケーションに関連することがある。たとえば、アバタ選択論理テーブル６０１中のデータレコード６１０および６１１は、両方ともユーザのオフィスのＧＰＳロケーション基準を含む。周囲雑音レベルが５０ｄＢを超える場合、それは会議を示すであろうと考えること、または呼出し音設定が「サイレント」に設定されている場合、それは同じく会議を示すであろうと考えることによって、この曖昧さを解決し、「仕事」アバタではなく「会議」アバタを表示すべきであることを示すことができる。代替実施形態は、記録されたセンサおよび設定データを学習し、特定のアクティビティに関連付けるために、（ディスプレイ上に提示されるプロンプトなどによって）ユーザにアクティビティの性質を尋ねることができる。ユーザにアクティビティの性質を定義するように依頼する代わりに、モバイルデバイス３０１は、ユーザに、現在のアクティビティに今後関連付けるべき特定のアバタを識別するように依頼することができる。このようにして、表示されたアバタは、ユーザのステータスをより正確に表すことができる。

図７は、パラメータ値テーブル６００に記憶されたパラメータのいずれかが変化したかどうかを判断する決定ステップ４０５を含むことによって、モバイルデバイスの処理能力を節約する代替実施形態のプロセスフロー図である。センサ値およびデバイス設定がパラメータ値テーブル６００にすでに記憶されたものと同じである場合、言い換えれば、パラメータ値が変化していない場合、アバタの変更は必要とされない。したがって、表示のためにアバタを選択するステップおよび選択をサーバに送信するステップ（ステップ４１０〜４１５）を実行する必要はない。したがって、ステップ４０５においてパラメータの変化がない場合、プロセッサは、センサをポーリングし、設定を調べるプロセス（ステップ４０１〜４０９）に戻ることができる。随意に、センサを監視することに専用の処理時間の量を低減するために、少しの所定の遅延（ステップ４５０）の後にステップ４０１〜４０９を反復することができる。プロセッサがパラメータ値テーブル６００中の値が変化したと決定した場合、本方法は、図５を参照しながら上述した方法と同様の方法で、表示のために特定のアバタを選択し、アバタをサーバに送信すること（ステップ４１０〜４４１）を続けることができる。

図８は、ユーザのウェブページをホスティングするサーバ１０９によって促されたときのみ、センサをポーリングし、デバイス設定を調べ、表示のためにアバタを選択する（ステップ４０１〜４１５）ことによって、モバイルデバイス３０１の処理能力を節約する一実施形態のプロセスフロー図である。本実施形態では、サーバ１０９は、モバイルデバイス３０１に現在のアバタを送信するように要求する要求をモバイルデバイス３０１に周期的に送信する（ステップ４５５）。更新をモバイルデバイス３０１に要求するプロセスは、図ではモバイルデバイス３０１の「ピング」と呼ばれる。サーバ１０９は、ユーザのウェブサイト上でユーザの現在のステータスを反映するアバタを維持するために、周期的にまたは所定の時間にアバタの要求をモバイルデバイス３０１に送信する。サーバ１０９からアバタの要求または「ピング」を受信することに応答して、モバイルデバイス３０１のプロセッサ３９１は、すべて図５を参照しながら上述した方法と同様の方法で、センサをポーリングし（ステップ４０１）、カレンダデータを調べ（ステップ４０２）、デバイス設定を調べ（ステップ４０３）、プライマ値テーブルにデータを記憶し（ステップ４０９）、パラメータ値をアバタ選択と比較することによって、表示のためのアバタを選択し（ステップ４１０、４１２）、選択されたアバタをサーバ１０９に送信する（ステップ４１５）プロセスを行う。

サーバ１０９からの「ピング」（ステップ４５５）の周期性に応じて、ユーザはアバタ更新間のアクティビティを完了および変更することができる。したがって、表示されたアバタは、ユーザの現在のステータスを常に正確に表すわけではない。追加の処理オーバーヘッドがかかるが、モバイルデバイスに送信されるアバタ更新要求（ステップ４５５）の頻度を増加させることによって、表示されたアバタの現在性を向上させることができる。同様に、モバイルデバイスに送信されるアバタ更新要求（ステップ４５５）間の期間を増加させることによって、モバイルデバイス３０１は処理オーバーヘッドを低減することができる。したがって、モバイルデバイスに送信されるアバタ更新要求（ステップ４５５）の周期を変化させることによって、現在性とモバイルデバイスプロセッサオーバーヘッドとの間のトレードオフを管理することができる。

図９は、サーバ１０９がユーザのアバタの要求を受信したときのみ、センサをポーリングし、デバイス設定を調べ、表示のためにアバタを選択する（ステップ４０１〜４１５）ことによって、モバイルデバイス３０１の処理能力を節約する別の実施形態のプロセスフロー図である。ある人がユーザのアバタを閲覧することを望むとき、その人は、アバタを含んでいるユーザのウェブページにアクセスしたいという要求をサーバ１０９に送信する（ステップ４４０）。サーバ１０９がユーザのアバタの要求を受信する（ステップ４３１）と、サーバ１０９はアバタ更新要求をモバイルデバイスに送信する（ステップ４５５）。サーバ１０９からアバタの要求または「ピング」を受信することに応答して、モバイルデバイス３０１のプロセッサ３９１は、すべて図５を参照しながら上述した方法と同様の方法で、センサをポーリングし（ステップ４０１）、カレンダデータを調べ（ステップ４０２）、デバイス設定を調べ（ステップ４０３）、プライマ値テーブルにデータを記憶し（ステップ４０９）、パラメータ値をアバタ選択と比較することによって、表示のためのアバタを選択し（ステップ４１０、４１２）、選択されたアバタをサーバ１０９に送信する（ステップ４１５）プロセスを行う。モバイルデバイスから選択されたアバタファイルを受信した（ステップ４２０）後、サーバ１０９は、アバタをユーザのウェブページに挿入し（ステップ４３０）、アバタを含むウェブページを要求側に送信し（ステップ４３２）、要求側のブラウザによってアバタを含むウェブページを表示する（ステップ４４１）。このようにして、第２のユーザがユーザのアバタを閲覧することを望むとき、モバイルデバイス３０１は、センサをポーリングし、カレンダおよびデバイス設定データを検索しなければならないだけである。これは、現在ステータスアバタを与えることに専用のモバイルデバイス１０９の処理リソースを最小限に抑える。図９に示す実施形態は、要求側がアバタを閲覧することができる前に、わずかな遅延を生じることがあるが、得られたアバタはユーザの現在のステータスを正確に反映することになる。

図１０は、アバタの選択が、ユーザのウェブページをホスティングするサーバ１０９によって行われる一実施形態のプロセスフロー図である。本実施形態では、センサをポーリングし、カレンダデータを調べ、デバイス設定を任意のパラメータ値テーブルに記録するプロセス（ステップ４０１〜４０９）は、図５を参照しながら上述したプロセスと実質的に同じである。モバイルデバイス３０１内でパラメータ値をアバタ選択基準と比較するのではなく、モバイルデバイスはパラメータ値テーブルをサーバ１０９に送信する（ステップ４１６）。上述のように、パラメータ値テーブル６００に保存され、ステップ４１６においてサーバ１０９に送信されるデータは、実装形態に応じて処理済みデータまたは未加工センサデータとすることができる。パラメータ値テーブル６００をサーバ１０９に送信した（ステップ４１６）後、モバイルデバイス３０１のプロセッサ３９１は、ユーザの現在のステータスを反映するセンサおよび設定データがサーバ１０９に周期的に送信されるように、センサをポーリングするなどのプロセス（ステップ４０１〜４０９）を反復する。随意に、モバイルデバイスプロセッサ３９１は、ポーリングステップおよび記録ステップ（４０１〜４０４）を反復する前に休止する（ステップ４５０）。

サーバ１０９は、パラメータ値テーブル６００を受信し（ステップ４１７）、テーブルをハードディスクメモリに記憶する。代替実施形態では、モバイルデバイス３０１は、センサパラメータ値をサーバ１０９に連続的に送信し、サーバ１０９は、ステップ４１７においてデータを受信すると、次いでパラメータ値テーブル６００をポピュレートする。パラメータ値テーブル６００が受信された後、値をアバタ選択論理テーブル６０１中のアバタ選択基準と比較する（ステップ４１８）。パラメータ値をアバタ選択基準と比較するプロセスは、ステップ４１１および図５を参照しながら上述した方法と実質的に同様の方法でサーバ１０９において達成できる。ステップ４１８における比較に基づいて、サーバ１０９は、表示のために適切なアバタを選択し（ステップ４１９）、サーバ１０９によってホスティングされるユーザのウェブページにアバタを挿入することなどによって、表示のためにアバタを準備する。ユーザのパラメータ値テーブル６００を最新に保つことによって、アバタにアクセスする（ステップ４４０）人に応答して、サーバ１０９が、要求側のコンピューティングデバイス上での表示（ステップ４４１）のためにアバタを送信した（ステップ４３２）とき、ユーザの現在のステータスを反映するアバタが表示されることになる。この実施形態は、モバイルデバイスが、適切なアバタを選択し、アバタをサーバに送信する必要をなくし、それによってプロセッサオーバーヘッドを低減し、電力を節約する。たいていのモバイルデバイス３０１は、それらの処理能力およびバッテリポテンシャルにおいて制限されるので、アバタ選択をサーバ１０９にオフロードすることにより、プロセッサは、１回のバッテリ充電でモバイルデバイス３０１をより長く動作させることができる。

図１１は、アバタ選択がサーバ１０９によって実行され、モバイルデバイス３０１は、センサ、カレンダおよび設定データが変化した場合のみ、そのようなデータを送信する代替実施形態を示す。この実施形態の処理は、任意のパラメータ値がパラメータ値テーブルの最後の送信（ステップ４１６）以来、変化したかどうかを判断するためのテスト（ステップ４０５）を追加した、図１０を参照しながら上述した処理と実質的に同じである。パラメータ値が変化していない場合、モバイルデバイス３０１のプロセッサ３９１は、随意の休止（ステップ４５０）後、センサをポーリングするなどのプロセス（ステップ４０１〜４０９）を反復する。パラメータ値が変化した場合のみ、モバイルデバイスは、更新されたパラメータ値テーブルをサーバ１０９に送信する（ステップ４１６）。本実施形態は、サーバ１０９上で記憶された値に対する更新が必要とされるときのみパラメータ値テーブルを送信する、という追加の利点を有する。したがって、本実施形態はモバイルデバイスバッテリ使用をさらに節約する。

図１２は、アバタ選択が、モバイルデバイス３０１に更新を周期的に要求するサーバ１０９によって行われる代替実施形態を示す。図８を参照しながら上述した方法と同様の方法で、サーバ１０９は、パラメータ値テーブル６００の更新を周期的に要求する（ステップ４５５）。応答して、モバイルデバイス３０１は、図１０のステップ４０１〜４１６を参照しながら上述したように、センサのポーリングなどを行い、パラメータ値テーブル６００をサーバ１０９に送信する。本実施形態のステップの残りは、図１０を参照しながら上述したステップと実質的に同じである。本実施形態は、センサのポーリングなどを、サーバ１０９によって制御される周期に限定することによって、モバイルデバイス３０１のバッテリ消費をさらに低減する。図８を参照しながら上記で説明したように、アバタの現在性とバッテリ消費との間のトレードオフは、モバイルデバイス３０１に対して行われる要求の周期を変化させることによって制御できる。代替実施形態はまた、「スリープ」し、いくつかのパラメータ（たとえば、雑音、光、加速、ロケーションの変化など）が検出されたときのみアウェイクされるセンサを採用することができる。

図１３は、アバタ選択が、他者からのアバタを閲覧したいという要求に応答してサーバ１０９によって行われる別の代替実施形態を示す。図９を参照しながら上述した方法と同様の方法で、ある人がユーザのアバタにアクセスしたい（ステップ４４０）という要求を送信したとき、サーバ１０９は要求を受信し（ステップ４３１）、それに応答して、アバタ更新要求をモバイルデバイスに送信する（ステップ４５５）。応答して、モバイルデバイス３０１は、図１０および図１２のステップ４０１〜４１６を参照しながら上述したように、センサのポーリングなどを行い、パラメータ値テーブル６００をサーバ１０９に送信する。本実施形態のステップの残りは、図１０の番号付きステップを参照しながら上述したステップと実質的に同じである。本実施形態は、センサのポーリングおよびデータの送信を、ある人がユーザのアバタにアクセスした場合に限定することによって、バッテリ電力を一層節約する。

ユーザのアバタのためのホストまたはアクセスポイントとして働くサーバ１０９に関する上記の実施形態について説明した。これらの実施形態は、アバタにアクセスしやすくするためにアバタがサーバ上で維持される現在のインターネットアーキテクチャを利用する。しかしながら、代替実施形態は、サーバ１０９にアクセスする必要なしに、第２のユーザのコンピューティングデバイス（たとえば、１１３〜１１７）上でのユーザのアバタの表示を可能にすることができる。これらの実施形態では、アバタファイルは、第１のユーザのモバイルデバイス３０１または第２のユーザのデバイス３１３〜３１７上あるいはその両方で記憶される。（特にアバタファイルが３次元であるかまたはアニメーション化されている場合）アバタファイルの記憶および表示はかなりのメモリストレージスペースおよびプロセッサ時間を必要とすることがあるので、ユーザ間でアバタファイルを要求し、受信するための事前許可が望まれることがある。ユーザのアバタを表示するためのそのような方法の例示的な実施形態を図１４ａに示す。

図１４ａを参照すると、モバイルデバイス３０１内での処理は、アバタを選択する（ステップ４１１）ポイントまで、図５を参照しながら上述した処理と実質的に同様である。モバイルデバイス３０１は、ユーザの現在のステータスに関するデータを収集するために、センサを連続的にポーリングし（ステップ４０１）、カレンダおよび設定データを調べる（ステップ４０２、４０３）。収集されたデータをパラメータ値テーブル６００に記憶し（ステップ４０９）、アバタ選択アバタ選択論理テーブル６０１と比較する（ステップ４１０）。比較に基づいて、表示すべきアバタファイルを選択する（ステップ４１１）。このようにして、選択されたアバタがユーザの現在のステータスを反映するようにアバタ選択を連続的に更新する。バッテリ電力を節約し、プロセッサオーバーヘッドを低減するために、ポーリングサイクル間に随意の休止または遅延（ステップ４５０）を行うことができる。

上記のプロセスステップにより、モバイルデバイス３０１は、メモリに記憶された現在のアバタ選択を有するようになる。第２のユーザは、電子メール、ＳＭＳメッセージおよび／または電話呼によってアバタの要求を送信する（ステップ４６０）。アバタの要求を受信する（ステップ４６１）ことに応答して、モバイルデバイス３０１のプロセッサ３９１は、メモリからアバタファイルを呼び戻し、ファイルを要求側に送信する（ステップ４６２）。アバタファイルを受信した（ステップ４６３）後、要求側コンピューティングデバイスは、次いでアバタを表示する（ステップ４４１）。

一実施形態では、プロセッサ３９１は、要求側デバイスがユーザのアバタを受信することを許可されるかどうかを判断するために、コンタクト要求のソース（たとえば、リターンアドレスまたは電話番号）を、事前承認された第２のユーザデバイス（たとえば、１１３〜１１７）のリストと比較することができる。事前承認されたユーザのこのリストは、友人および家族の電話番号および電子メールアドレスのリストと同様とすることができる。

一実施形態では、ユーザのアバタを受信することを事前承認されたすべてのコンピューティングデバイスなど、コンタクトを開始するデバイス上で複数のユーザのアバタファイルを事前記憶することができる。全アバタファイルが要求側に送信される上記の実施形態とは異なり、要求側がそれ自体のメモリからアバタファイルを呼び戻すために、アバタ名のみが送信される必要がある。事前承認されたコンピューティングデバイス上にアバタファイルを事前記憶することによって、アバタ名のみが送信されるので、アバタ要求と要求側に対するその提示との間の遅延は最小限に抑えられる。しかしながら、そのような実施形態は、複数のデバイスに関するかなりの記憶要件、ならびにユーザのアバタファイルのすべてを各事前承認されたコンピューティングデバイスにダウンロードするために必要な時間を必要とする。

代替実施形態では、事前承認されたコンピューティングデバイス上でアバタファイルを事前記憶すること、ならびにアバタファイルを事前承認されたコンピューティングデバイスに直接送信することができる。モバイルデバイス３０１と要求側デバイスの両方によって必要とされる電力消費量を最小限に抑えるために、選択されたアバタファイルの識別子のみを第２のユーザのデバイスに送信する。代替実施形態は、アバタファイルの送信が必要かどうかを判断するために、要求側デバイスのローカルメモリを調べる。アバタファイルがすでに要求側デバイスのローカルメモリ中に存在する場合、アバタファイルは直接表示される。アバタファイルがローカルメモリ中に存在しない場合、アバタファイルの要求が行われ、その後、表示のために送信される。図１４ｂは、ステップ５０４においてアバタファイル識別子（ＩＤ）を要求側デバイスに送信することを除いて、図１４ａを参照しながら上述した実施形態と実質的に同じである代替実施形態を示す。要求側デバイスは、アバタＩＤを受信し（ステップ５０６）、そのＩＤを使用して、関連するアバタファイルがすでにそのメモリに記憶されているかどうかを判断する（テスト５０７）。そのＩＤに対応するアバタファイルがすでにローカルメモリ中に存在する場合（すなわち、テスト５０７＝はい）、すぐにアバタを表示する（ステップ４４１）。しかしながら、ＩＤに対応するアバタファイルがまだメモリ中にない場合（すなわち、テスト５０７＝いいえ）、要求側デバイスはファイルが送信されることを要求する（ステップ５０８）。モバイルデバイス３０１は要求を受信し（ステップ５０５）、対応するアバタファイルを送信する（ステップ４６２）。その後、要求側デバイスは、アバタファイルを受信し（ステップ４６３）、アバタファイルを表示する（ステップ４４１）。図示しない随意のステップとして、受信したアバタファイルを将来の使用のためにローカルメモリに記憶することができる。このようにして、代替実施形態は、新しいまたは更新されたアバタファイルの表示を可能にする。さらに、要求側デバイスがまだローカルメモリ中にアバタファイルを有しないときのみ、大きいアバタファイルの送信を必要とすることによって、モバイルデバイス３０１と要求側デバイスの両方によって電力消費量が節約される。送信されるデータの量を制限することによって、代替実施形態は伝送帯域幅をも節約する。

図１５ａは、パラメータが変化したかどうかを判断するためのテスト（ステップ４０５）を含む、図１４ａに示す上記の実施形態の代替を示す。図７のステップ４０５を参照しながら上記でより十分に説明したように、最後のアバタ選択（ステップ４１１）以来、パラメータが変化していない場合、プロセッサ３９１は、センサ、カレンダおよび設定データの収集（ステップ４０１〜４０９）を続けることができる。パラメータが変化した場合、本方法は、図１４の同様の番号付きステップを参照しながら上述したように続くことができる。

図１４ｂに示す実施形態が図１４ａの方法を変更した様式と同様に、図１５ｂに示す実施形態は、図１５ａに示す方法を変更する。図１５ｂに示す代替実施形態は、処理能力、バッテリ寿命および伝送帯域幅を節約し、更新されたまたは新しいアバタファイルの使用をさらに可能にする。図１４ｂに示す実施形態と同様に、図１５ｂに示す実施形態は、選択されたアバタファイルの識別子のみを第２のユーザのデバイスに送信するステップ５０４〜５０８をさらに含むことによって、図１５ａに示す方法を変更する。アバタファイルの送信が必要かどうかを判断するために、要求側デバイスのローカルメモリを調べる。アバタファイルがすでに要求側デバイスのローカルメモリ中に存在する場合、アバタファイルは直接表示される。アバタファイルがローカルメモリ中に存在しない場合、アバタファイルの要求が行われ、その後、表示のために送信される。

図１６は、第２のユーザによって行われるアバタ要求に応答することによって、モバイルデバイス３０１のプロセッサおよびバッテリ時間をさらに節約する代替実施形態を示す。第２のユーザはアバタ要求をモバイルデバイス３０１に送信する（ステップ４６０）。モバイルデバイス３０１はアバタ要求を受信し（ステップ４６１）、それに応答して、プロセッサ３９１は、図５を参照しながら上述したようにセンサ、カレンダおよび設定データを収集し、記憶する（ステップ４０１〜４０９）。プロセッサ３９１は、次いで、パラメータ値テーブル６００に収集されたデータをアバタ選択論理テーブル６０１と比較して（ステップ４１０）、表示（ステップ４１１）のためにアバタを選択する。プロセッサ３９１は、次いで、選択されたアバタファイルを要求側コンピューティングデバイスに送信し（ステップ４１５）、要求側コンピューティングデバイスは、アバタファイルを受信し（ステップ４６２）、選択されたアバタを表示する（ステップ４４１）。

一実施形態では、プロセッサ３９１は、要求側デバイスがユーザのアバタを受信することを許可されるかどうかを判断するために、コンタクト要求のソース（たとえば、リターンアドレスまたは電話番号）を、事前承認された第２のユーザデバイス（たとえば、１１３〜１１７）のリストと比較することができる。事前承認されたユーザのこのリストは、友人および家族の電話番号および電子メールアドレスのリストと同様とすることができる。

一実施形態では、アバタの要求を開始するコンピューティングデバイス上で複数のユーザのアバタファイルを事前記憶することができる。たとえば、ユーザのアバタファイルは、ユーザのアバタを受信するために事前承認されたすべてのコンピューティングデバイス上で記憶できる。全アバタファイルが要求側に送信される上記の実施形態とは異なり、要求側がそれ自体のメモリからアバタファイルを呼び戻すために、アバタ名のみが送信される必要がある。事前承認されたコンピューティングデバイス上にアバタファイルを事前記憶することによって、アバタ名のみが送信されるので、アバタ要求と要求側に対するその提示との間の遅延は最小限に抑えられる。しかしながら、そのような実施形態は、複数のデバイスに関するかなりの記憶要件、ならびにユーザのアバタファイルのすべてを各事前承認されたコンピューティングデバイスにダウンロードするために必要な時間を必要とする。

代替的に、図１４ｂおよび図１５ｂに示す実施形態と同様に、図１６ｂに示す実施形態は、選択されたアバタファイルの識別子のみを第２のユーザのデバイスに送信するステップ５０４〜５０８を追加することによって、図１６ａに示す方法を変更する。アバタファイルの送信が必要かどうかを判断するために、要求側デバイスのローカルメモリを調べる。アバタファイルがすでに要求側デバイスのローカルメモリ中に存在する場合、アバタファイルは直接表示される。アバタファイルがローカルメモリ中に存在しない場合、アバタファイルの要求が行われ、その後、表示のために送信される。

図１７に示す実施形態では、ユーザのアバタを要求することを許可されたコンピューティングデバイス上でアバタファイルおよびアバタ選択論理テーブル６０１を事前記憶する。本実施形態では、事前承認されたコンピューティングデバイスは、ユーザに電話するか、電子メールを送信するか、またはＳＭＳメッセージを送信することなどによってアバタを要求する（ステップ４６０）。アバタの要求を受信する（ステップ４６１）ことに応答して、モバイルデバイス３０１のプロセッサ３９１は、図５を参照しながら上記でより十分に説明したように、センサをポーリングし、カレンダデータを調べ、デバイス設定を調べ（ステップ４０１〜４０３）、そのデータをパラメータ値テーブル６００に記憶する（ステップ４０９）。プロセッサ３９１は、次いでパラメータ値テーブル６００を要求側コンピューティングデバイスに送信する（ステップ４１６）。要求側コンピューティングデバイスは、パラメータ値テーブルを受信し（ステップ４６２）、その値をコンピューティングデバイス上で記憶されたアバタ選択論理テーブル６０１と比較して（ステップ４６４）、表示のために適切なアバタを選択する（ステップ４６６）。適切なアバタが選択されると、コンピューティングデバイスは、次いで、そのメモリからアバタを呼び出し、アバタを表示する（ステップ４４１）。アバタ要求側コンピューティングデバイスがパラメータ値をアバタ選択基準と比較する（ステップ４６４および４６６）プロセスは、モバイルデバイス３０１またはサーバ１０９によって実行される上述の同様のステップと実質的に同じである。

別の実施形態では、ユーザはまた、各アバタを、だれが、いつ、どんなアクティビティ中に閲覧することができるかを制御するために許可選択基準を設定することができる。ユーザは、同じセンサ設定に対応するが、要求側（すなわち、要求を行う第２のユーザ）の識別情報に応じて異なる複数のアバタを与えることができる。いくつかのアバタは、ユーザの正確なアクティビティに関してより少ない詳細を与えるか、またはユーザが実際に従事するアクティビティから著しく異なることが可能である。さらに、ユーザは、表示されたアバタがユーザの実際のアクティビティに対応しないようにするために、センサ情報をオーバーライドするように許可制御を設定することができる。

たとえば、ユーザは、ユーザの上司が勤務時間中のみ、ユーザのアクティビティを詳述するアバタを閲覧することができるようにするために許可レベルを設定することができる。またある時には、アバタを拒否または非表示にすることができ、またはアバタを提示する場合、アバタは、ユーザが従事するアクティビティを示すことなしに、ユーザが忙しいことを示す単純なアバタとすることができる。別の例では、ユーザは、センサデータが、ユーザがジムにいることを示すとき、ユーザの上司が、仕事中のユーザを示すアバタを閲覧するように、（パーミッション制御とも呼ばれる）許可レベルを設定することができる。

図１８に、要求側の許可レベルに部分的に基づいてアバタを選択する実施形態において採用される例示的なプロセスステップを示す。図４を参照しながら上述したように、モバイルデバイスプロセッサ３９１は、ユーザの現在のアクティビティに関する様々なデータを検索する（ステップ４０１〜４０３）。ユーザの現在のアクティビティに関して関係するデータを収集した後、要求側の許可レベルを判断する（ステップ５０１）。要求側の許可レベルを判断する様々な方法について、以下でより詳細に説明する。要求側の許可レベルを判断した後、それを別のパラメータとして使用して、表示のために適切なアバタを選択することができる。アバタがモバイルデバイス３０１から要求側のデバイスに直接送信される実施形態では、モバイルデバイスのプロセッサ３９１が要求側の許可レベルを調べることができる。アバタが中央サーバロケーションにおいてウェブページに記憶され、挿入される場合には、サーバのプロセッサまたはモバイルデバイスのプロセッサが、要求側の許可レベルを調べるステップを実行することができる。

要求側の許可レベルを調べるために様々な方法のいずれかを実装することができる。たとえば、要求側がアバタを受信することを許可されることおよび／または特定の許可レベルを有することを確認するユーザ名およびパスワードなど、何らかの形態の認証証明を与えるように要求側に依頼することができる。代替的に、いくつかの特定のコンピューティングデバイスに、選択されたアバタを閲覧することを許可することができる。プロセッサは、コンピューティングデバイスがアバタを受信することを許可されるかどうかを判断するために、アバタ要求メッセージ中で受信されたスタティックインターネットプロトコル（ＩＰ）アドレスを、アバタを受信することを許可されたスタティックＩＰアドレスのリストと比較することなどによって、アバタの要求をサブミットするコンピューティングデバイスのスタティックＩＰアドレスを調べることができる。要求側の許可レベルを調べるステップを実行するために、要求側、または許可されたユーザ／デバイスとしてアバタを受信したいという要求を送信するコンピューティングデバイスを認証する方法、あるいは要求側またはデバイスを様々な許可レベルにカテゴリー分類する方法を、様々な方法において使用することができる。要求側が特定のアバタを受信することを許可されるかどうか（または要求側の許可のレベル）の判断が行われた後、どのアバタを表示すべきか、または要求側に送信すべきかを判断するための別の基準として、この基準をパラメータテーブルに入力することができる。

様々なモバイルデバイスセンサ、様々なモバイルデバイス設定およびカレンダデータから収集された情報を使用して、プロセッサはユーザの現在のステータスを推測することができる。この推測を要求側の許可レベルと組み合わせて、プロセッサは、ユーザの選好に従って表示のためにアバタを選択する（ステップ４０４）。図５〜図１７に示す様々な実施形態に関して上述したように、様々なプロセッサを使用して、この判断を行うことができる。たとえば、どのアバタを表示すべきかの判断を、モバイルデバイス３０１、サーバ１０９、または要求側のコンピューティングデバイスのプロセッサによって行うことができる。さらに、適切なアバタを選択した後、上述の方法のいずれかで適切なアバタを表示することができる。たとえば、アバタを、サーバによってホスティングされるウェブページの一部として表示するか、要求側のコンピューティングデバイス上で直接表示するか、または電子メール、ＳＭＳまたは他のメッセージ中で送信される画像ファイルとして添付することができる。

上述の実施形態と同様に、モバイルデバイスセンサ（たとえば、３５０〜３５６）からのデータ、ユーザのカレンダ、およびモバイルデバイス設定は、パラメータ値テーブル６０２に記憶できる。そのようなデータは、絶対値（すなわち、未加工センサ情報）の形態、または処理済み情報（すなわち、解釈されたセンサ情報）の形態で記憶できる。この区別は、情報がパラメータ値テーブル６０２に記憶される前に行われる情報の処理の量に基づいて変わる。さらに、パラメータテーブル６０２は、要求側が許可されるかどうかを記録するため、または３つ以上のレベルがある場合、要求側の許可レベルを記録するための追加の列を含むことができる。たとえば、図１９ａに、ステップ５０１において実行される許可レベル検査の結果を記憶する「許可レベル」と題された列を追加した、図６を参照しながら上述したパラメータ値テーブルと同様のパラメータ値テーブル６０２を示す。図示の例では、許可レベル検査は要求側が許可されると判断した。

パラメータ値テーブル６０２に記憶されたセンサ、カレンダ、設定データ、および要求側の許可レベルを用いて、この情報を、アバタ選択論理テーブル６０３に記憶された基準と比較することができる。図６ｂを参照しながら上述した選択論理テーブル６０１と同様であるアバタ選択論理テーブル６０３の例示的な例を図１９ｂに示す。図１９ｂのアバタ選択論理テーブル６０３は、要求側の許可レベルに関係する選択基準を記録する追加のパラメータ列を含む。

図６ｂを参照しながら上述したように、図１９ｂに示すアバタ選択論理テーブル６０３は、表示すべき適切なアバタを判断するコンピューティングデバイスのメモリに記憶できる。図６ｂを参照しながら前述したように、アバタ選択を実行するためにアバタ選択論理テーブル６０３を使用することは、フレキシビリティと選択プロセスに対する制御とをユーザに与える。表示のために選択されたアバタが、要求側の許可レベルを含む様々なパラメータに基づいて選択されるように、ユーザはアバタ選択論理テーブル６０３をカスタマイズすることができる。アバタ選択論理テーブル６０３は、要求側の許可レベルに基づいて表示のために様々なアバタを割り当てる追加のオプションをユーザに与える。アバタ選択論理テーブル６０３のこのカスタマイゼーションはユーザセットアッププロセス中に達成できる。アバタ選択論理テーブル６０３を構成するために、アバタ選択論理テーブル６０１をポピュレートするための上述のセットアップ方法のいずれかを実装することができる。

許可レベルは、単に要求側が許可されるかどうかを示す２値レベルとすることができる。そのような２値システムでは、要求側が許可されるかどうかに応じて、センサ、カレンダおよび設定データの同じ選択基準に対して２つの異なるアバタを表示することができる。たとえば、要求側が許可されない場合、より一般的なアバタを表示することができ、要求側が許可される場合、センサ、カレンダおよび設定データの同じ選択基準に対して詳細またはより正確なアバタを表示することができる。第１のユーザは、要求側が許可されない場合、アバタが表示されないかまたは送信されないことを意味する、「アバタなし」の値を割り当てることを単に選択することができる。代替的に、第１のユーザは複数の許可レベルを設定することができ、各許可レベルは、センサ、カレンダおよび設定値の同じ選択基準に対して異なるアバタの表示を生じる。

図１９ｂに示す例では、同じセンサ、カレンダおよび設定データに対して、ユーザは、それぞれ、データレコード６５０および６５１において「仕事」および「会議」と題された２つの異なるアバタを定義している。アバタ選択プロセスは、アバタ選択テーブル論理６０１に関して上述した方法と同様の方法で達成される。この例では、データレコード６５０とデータレコード６５１の両方の選択基準は、オフィスのロケーションおよびＧＰＳセンサによって記録された低い速度と、低い周囲雑音と、「明るい」周辺光条件と、（たとえば、着席または歩行に一致する）０または低い加速度計読みと、会議がスケジュールされていることを示すカレンダデータと、（会社ロゴなどの）職業上の壁紙設定とを含む。「仕事」および「会議」アバタ選択基準は、その特定のアバタのユーザのステータスを解決するのに役立つ可能性がないとユーザが予想する、いくつかのパラメータの値を含まないことがある。たとえば、ユーザは、周囲温度および呼出し音値が、仕事アバタまたは会議アバタのいずれかを選択するための追加の値を与えないと決定している。パラメータ値テーブル６０２に記憶されたセンサおよび設定データが、データレコード６５０および６５１の基準に一致する場合、要求側の許可レベル（この場合、ユーザが許可されるかどうか）に応じて、異なるアバタが選択され、表示される。要求側が許可されない場合（すなわち、許可レベル＝「いいえ」）、これは、要求側が単に、ユーザに知られていない一般社会のメンバーであることを意味することがある。そのような一般社会のメンバーに対して、ユーザは、ユーザが仕事中であることを示し、ユーザが現在従事している正確なアクティビティを開示しないことを望むことがある。したがって、カレンダパラメータは、ユーザが現在「重役会議」中であることを示すが、無許可の要求側に表示されるアバタは、ユーザの職業に従事するユーザのより一般的な「仕事」アバタである。

対照的に、要求側が許可される（すなわち、テーブル６０２に記憶された許可レベルが「はい」である）場合、これは、要求側が、ユーザが正確なアバタを開示することを望む（たとえば）同僚、上司、または家族メンバーであることを意味することがある。そのような要求側に対して、ユーザは、正確により多くの情報が既知の要求側に伝達されるように、ユーザが従事しているアクティビティを示すことを望むことがある。したがって、要求側が許可される場合、会議またはプレゼンテーションに従事するユーザを示す「会議」アバタを表示することができる。

データレコード６５２および６５３の場合、選択基準は、ホームのロケーションおよびＧＰＳセンサによって記録された低い速度と、「暗い」周辺光条件と、（たとえば、着席または睡眠に一致する）０の加速度計読みとを含む。データレコード６５２とデータレコード６５３の両方は、その特定のアバタのユーザのステータスを解決するのに役立つ可能性がないとユーザが予想する、いくつかのパラメータの値を含まないことがある。たとえば、ユーザは、周囲温度、カレンダデータ、壁紙および呼出し音値が、表示すべきいずれかのアバタを選択するための追加の協議値を与えないと決定している。むしろ、ユーザは、ユーザが自宅にいる場合、ユーザは睡眠中の可能性があると思うことがある。しかしながら、ユーザは、ユーザが睡眠中であることを同僚またはより具体的にはユーザの上司に示すことを望まない場合がある。したがって、友人および家族メンバーなど、許可された要求側のみが「睡眠」アバタを受信することになる。ユーザの上司など、無許可の要求側は、データレコード６５３中の選択基準に従って「ビジー」アバタを受信することになる。

ユーザは、要求側の許可レベルに応じて、同じセンサ、カレンダおよび設定データに対して３つ以上の異なるアバタが表示できるように、複数の許可レベルを用いてアバタ選択論理テーブル６０３をプログラムすることができる。たとえば、データレコード６５４〜６５６において、選択基準は、ゴルフコースのロケーションおよびＧＰＳセンサによって記録された低い速度と、「明るい」周辺光条件と、（たとえば、歩行またはゴルフカートに乗ることに一致する）０〜低い加速度計読みと、７５度よりも大きい周囲温度と、週日を示すカレンダ設定とを含む。そのような状況では、ユーザは、ユーザが週日の勤務時間中にゴルフをしていることをユーザの配偶者または上司に知らせることを望まないことがある。したがって、許可レベルが、要求側がユーザのバディリストに載っていることを示す要求側には、「ゴルフ」アバタが送信されることになる（データレコード６５５参照）。しかしながら、ユーザの配偶者は、「ビジー」アバタを表示のために選択させる「家族」の許可レベルを有することがある。さらに、ユーザの上司は、「仕事」アバタを表示のために選択させるであろう許可レベルを有することがある。

ユーザは、図６ｃを参照しながら上述した方法と同様の方法でアバタ選択論理テーブル６０３をポピュレートすることができる。図１９ｃに、要求側の許可レベルを含むアバタ選択論理テーブルを完成するのに好適な例示的な実施形態較正方法を示す。プロセスを開始するために、ユーザは、較正すべき特定のアバタを選択する（ステップ６１０）。このアバタは、すでにユーザによって作成され、名前を与えられていることがある。代替的に、ユーザは、これから作成すべきアバタのための名前を入力することができる。ユーザは、次いで、モバイルハンドセット上の特定のキーを押すことなどによって、アクティビティを開始し、較正を開始する（ステップ６１２）。アクティビティ中に、モバイルデバイス３０１はセンサデータおよびデバイス設定を記録する（ステップ６１４）。いくつかのセンサでは、これは、時間ベースパターンを認識することができるように、各記録の時間とともに、ある時間期間にわたってセンサ読みを記録することを含むことができる。代替的に、ユーザは、アバタのためのパラメータ読みの較正を改良するために、複数のセンサ読みを取り、そのセンサ読みを平均化することができる。たとえば、アバタは、改良された心拍数センサ読みに応じて、運動セッション中のユーザ側の増加または減少する労力を示すように表示できる。ある時間期間の後、モバイルデバイス上の特定のキーを押すことなどによって、ユーザは較正を終了する（ステップ６１６）。代替的に、ステップ６１６が自動的に行われるように、プリセットされた時間量の間、較正を続けることができる。センサデータおよびデバイス設定を記録した（ステップ６１４）後、データレコードに許可レベルを追加するオプションをユーザに与える（ステップ６１５）。ユーザは、記録されたセンサおよび設定データに対する代替アバタを選択するように促される。ユーザは、さらに、センサおよび設定が、記録された基準に一致するときはいつでも、選択された許可レベルを所有する要求側が、選択された代替アバタを受信することになるように、選択された代替アバタに対応する許可レベルを選択するように促される。較正データ収集が完了すると、モバイルデバイス３０１のプロセッサ３９１は、図６ｃを参照しながら上記でより十分に説明したように、よく知られている統計的プロセスを使用して、記録されたセンサデータを分析することができる。

分析後、分析されたセンサデータおよびモバイルデバイス設定の結論を、アバタ選択論理テーブル６０３中の許可レベルとアバタ名とを含むデータレコードに記憶する（ステップ６２０）。アバタ選択論理テーブル６０３はモバイルデバイス３０１のメモリ３９２に記憶できる。ユーザは、ユーザのアバタのすべてに対して基準が保存されるまで、較正のためにアバタを選択し、モバイルデバイス３０１に較正ルーチンを実行させながら関連するアクティビティに従事し、分析されたセンサデータをアバタ選択論理テーブル６０３に記憶するプロセスを反復することができる。これは、様々な許可レベルに対する複数のアバタ設定を含むことができる。随意に、アバタ選択論理テーブル６０３が完成したとき、ユーザのアバタがホスティングされるサーバ１０９など別のコンピューティングデバイスにテーブルを送信する（ステップ６２２）。さらに、アバタ選択論理テーブル６０１に関して上述した学習方法を実装することができる。

ユーザは、特定のアバタのための較正または基準を更新するため、または新たに作成されたアバタのための選択基準を追加するために、図１９ｃに示すプロセスをいつでも反復することができる。

図２０は、表示すべきアバタが、センサおよび設定データならびに要求側の許可レベルに基づいて判断される実施方法のプロセスフロー図である。本実施形態では、モバイルデバイス３０１のプロセッサ３９１は、図５〜図１２を参照しながら上述した方法と実質的に同様の方法でステップ４０１〜４３１を実行する。

ウェブページアクセス要求を受信すると、サーバ１０９のプロセッサは、前述したいくつかの方法のいずれかを実施して、ウェブページへのアクセスを要求する人またはデバイス（「第２のユーザ」）の許可レベルを調べる（ステップ５０１）。許可レベルを調べるステップを完了するために、第２のユーザのデバイスから第２のユーザに関するデータをサーバ１０９のプロセッサに返送する（ステップ５０３）。

第２のユーザの許可レベルを判断した後、この情報は、サーバ１０９のメモリ中に保持されるパラメータテーブルに記憶される。どのアバタを表示すべきかを判断するために、パラメータテーブルのデータレコードを、サーバ１０９のメモリに記憶されたアバタ選択論理テーブル６０３中の基準と比較する（ステップ４１１）。上記でより十分に説明したように、様々な方法実施形態を使用して、記憶されたパラメータデータを評価し、表示のために特定のアバタを選択することができる。たとえば、サーバ１０９のプロセッサは、パラメータデータテーブルに記憶されたパラメータによって最大の数の選択基準が満たされるアバタを選択することができる。適切なアバタを選択した後、サーバ１０９のプロセッサは、ステップ４３０〜４４１について図５〜図１２を参照しながら上記でより十分に説明したように、選択されたアバタをウェブページに挿入し、要求側に送信する。センサおよび設定データのポーリングおよび分析は自律的に実行されるので、ユーザが要求側の許可レベルに基づいて、選択すべきアバタを改変することを選択しない限り、他者に提示されるユーザのアバタは、ユーザによる入力なしにユーザの現在のステータスに一致して維持される。

図２１は、バッテリおよびプロセッサ時間を節約し、第２のユーザの許可レベルに関係するデータを含むアバタ選択論理テーブルに基づいて、表示すべきアバタを判断する、モバイルハンドセット上での実装形態に好適な実施方法のプロセスフロー図である。図２１に示す実施形態は、図５〜図１２を参照しながら上述したステップ４０１〜４４０を含む。プロセッサは、ステップ５０１〜５０３および４１１について図２０を参照しながら上述した方法と同様の方法で表示すべきアバタを選択する。適切なアバタを選択した後、サーバ１０９のプロセッサは、ステップ４３０〜４４１について図５〜図１２を参照しながら上記でより十分に説明したように、選択されたアバタをウェブページに挿入し、要求側に送信する。

図２２は、ユーザのウェブページをホスティングするサーバ１０９によって促された（ステップ４５５）ときのみ、センサをポーリングし、デバイス設定を調べる（ステップ４０１〜４０９）ことによって、モバイルデバイス３０１の処理能力を節約する一実施形態のプロセスフロー図である。本実施形態は、図５〜図１２を参照しながら上述したステップ４０１〜４５５を含む。プロセッサは、図２０および図２１を参照しながら上述したように、要求側の許可レベルを受信し、調べ（ステップ５０１〜５０３）、適切なアバタを選択する（ステップ４１１）。適切なアバタを選択した後、サーバ１０９のプロセッサは、ステップ４３０〜４４１について図５〜図１２を参照しながら上記でより十分に説明したように、選択されたアバタをウェブページに挿入し、要求側に送信する。

図２３は、サーバ１０９がユーザのアバタの要求を受信したときのみ、センサをポーリングし、デバイス設定を調べ、表示のためにアバタを選択することによって、モバイルデバイス３０１の処理能力を節約する別の実施形態のプロセスフロー図である。図２３に示す実施形態は、図２０および図２１を参照しながら上述した、要求側の許可レベルを調べること（ステップ５０１、５０３）を追加した、図９に示す実施形態とほとんど同じ方法で動作する。ステップ５０１および５０３おいて判断した許可レベルを、図５〜図９を参照しながら上述したように、パラメータテーブル６０２に記憶する（ステップ４０９）ためにモバイルデバイス３０１に送信する。したがって、アバタは第２のユーザの許可レベルに基づいて選択できる。適切なアバタを選択した後、ステップ４１５〜４４１について図９を参照しながら上記でより十分に説明したように、アバタを要求側に送信する。

図２４ａは、センサおよび設定データ、ならびに第２のユーザの許可レベルに基づいて選択されたアバタを要求側デバイス上に直接表示するのに好適な別の実施方法のプロセスフロー図である。図２４ａに示す実施形態は、図２０および図２１を参照しながら上述したように、第２のユーザの許可レベルを調べ（ステップ５０１および５０３）、許可レベルデータをパラメータテーブル６０２に記憶する（ステップ５０２）ことを追加した、図１４ａを参照しながら上述した方法と同じ方法で動作する。許可レベルデータをパラメータテーブル６０２に記憶した後、ステップ４１１、４３２、４６３、４４２について図１４ａ、図２０および図２１を参照しながら上述したように、完成したパラメータテーブル６０２をアバタ選択論理テーブル６０３と比較して、適切なアバタを選択し、表示する。

代替的に、図１４ｂ、図１５ｂおよび図１６ａに示す実施形態と同様に、図２４ｂに示す実施形態は、選択されたアバタファイルの識別子のみを第２のユーザのデバイスに送信するステップ５０４〜５０８を追加することによって、図２４ａに示す実施方法を変更する。アバタファイルの送信が必要かどうかを判断するために、要求側デバイスのローカルメモリを調べる。アバタファイルがすでに要求側デバイスのローカルメモリ中に存在する場合、アバタファイルは直接表示される。アバタファイルがローカルメモリ中に存在しない場合、アバタファイルの要求が行われ、その後、表示のために送信される。図２４ｂに示す代替実施形態は、処理能力、バッテリ寿命および伝送帯域幅を節約し、更新されたまたは新しいアバタファイルの使用をさらに可能にする。

図１６ａに示す実施形態と同様に、図２５ａに示す実施形態は、第２のユーザによって行われるアバタ要求に応答することによって、モバイルデバイス３０１のプロセッサおよびバッテリ時間をさらに節約する代替実施形態を示す。図２５ａに示す実施形態は、図２０および図２１を参照しながら上述したように、第２のユーザの許可レベルを調べ、送信する（ステップ５０１および５０３）ことを追加した、図１６ａを参照しながら上述した実施形態と同じ方法で動作する。許可レベルデータを様々なセンサおよび設定データとともにパラメータテーブル６０２に記憶する（ステップ４０９）。記憶した後、完成したパラメータテーブル６０２をアバタ選択論理テーブル６０３と比較し（ステップ４１０）、表示すべき適切なアバタを選択する（ステップ４１１）。選択した後、プロセッサ３９１は、次いで、図１４から図１６を参照しながら上述したように、選択されたアバタファイルを要求側コンピューティングデバイスに送信し（ステップ４１５）、要求側コンピューティングデバイスは、アバタファイルを受信し（ステップ４６２）、選択されたアバタを表示する（ステップ４４１）。

この場合も、図１４ｂ、図１５ｂおよび図１６ａに示す実施形態と同様に、図２５ｂに示す実施形態は、選択されたアバタファイルの識別子のみを第２のユーザのデバイスに送信するステップ５０４〜５０８を追加することによって、図２５ａに示す実施方法を変更する。アバタファイルの送信が必要かどうかを判断するために、要求側デバイスのローカルメモリを調べる。アバタファイルがすでに要求側デバイスのローカルメモリ中に存在する場合、アバタファイルは直接表示される。アバタファイルがローカルメモリ中に存在しない場合、アバタファイルの要求が行われ、その後、表示のために送信される。図２５ｂに示す代替実施形態は、処理能力、バッテリ寿命および伝送帯域幅を節約し、更新されたまたは新しいアバタファイルの使用をさらに可能にする。

図１７に示す実施形態と同様に、図２６に示す実施形態は、ユーザのアバタを要求することを許可されたコンピューティングデバイス上でアバタファイルおよびアバタ選択アバタ選択論理テーブル６０３を事前記憶する。要求側コンピューティングデバイスの各々は、ユーザのアバタを要求することを前に許可されているが、いくつかのコンピューティングデバイスは、様々なセンサおよび設定データに応答して、いくつかのアバタのみを閲覧することを許可されることがある。図２６に示す実施形態は、図２０および図２１を参照しながら上述したように、第２のユーザの許可レベルを調べ、送信する（ステップ５０１および５０３）ことを追加した、図１７を参照しながら上述した方法と同じ方法で動作する。許可レベルデータを様々なセンサおよび設定データとともにパラメータテーブル６０２に記憶する（ステップ４０９）。記憶した後、完成したパラメータテーブル６０２を第２のユーザの要求側コンピューティングデバイスに送信し（ステップ４１６）、ステップ４６２、４６４、４６６、４４１について図１７を参照しながら上述したように、アバタ選択論理テーブル６０３と比較して、適切なアバタを選択し、表示する。

一実施形態では、反復パラメータパターンが認識されたとき、表示のためにアバタを選択するようにユーザを促すための人工知能ルーチンをモバイルデバイス上に実装することができる。たとえば、モバイルデバイスがＧＰＳセンサ３５４を連続的にポーリングし、人工知能アプリケーションが、デバイスが週日中に午前９時と午後５時との間に同じＧＰＳロケーション座標にあることに注目した場合、プロセッサは、ロケーションの名前を特定するようにユーザを促し、「仕事」という名前を提案することができる。代替的に、プロセッサ３９１が、脈拍センサ（図示せず）によって検出されたユーザの脈拍が１分当たり１００回を上回って上昇したことに注目した場合、プロセッサ３９１は、ユーザの現在のアクティビティを「運動」と特定するようにユーザを促すことができる。同時に、プロセッサ３９１が、モバイルデバイス３０１が１時間当たり３マイルよりも大きい速度で移動していることをＧＰＳセンサから認識した場合、プロセッサ３９１は、ユーザの現在のアクティビティを「ランニング」と特定するようにユーザを促すことができる。

アバタファイルが、それらを表示するコンピューティングデバイス上で直接記憶される場合など、メモリに記憶されたアバタファイルの数が制限される実施形態では、より少数の、より一般的なアバタが望まれることがある。そのような場合、ユーザの現在のステータスを正確に反映するために、より少数のパラメータが必要とされることがある。逆に、アバタファイルが、サーバ１０９など、より大きい記憶および処理能力をもつコンピューティングデバイス上で記憶される場合、アバタファイルの数を増加させ、ならびにアバタをユーザの現在のステータスと一致させる際の精度のレベルを高めることができる。

さらなる実施形態では、パラメータデータは、ユーザのアクティビティの変化に一致してアバタを変化させることができる。アバタ選択テーブル６０１、６０３を改良することによって、パラメータデータの変化に応答して、異なるアバタを表示することができる。たとえば、ＧＰＳセンサ３５４が１時間当たり約６マイルの速度を測定し、加速度計３５３がランニングに一致する加速の周期性を示すことによって推測されるようにユーザがランニング中である場合、表示のために選択されるアバタはランナーのアニメーション画像とすることができる。ＧＰＳセンサ３５４の記録が増加するにつれて、表示のために選択されたアバタは、より高速に動くランニング画像、および／またはより激しく走り、汗をかき、呼吸するアバタを表示することによって労力の増加を示すランニング画像を示すことができる。アニメーション化されたアバタを含む、そのような追加のアバタを含むことは、単に、アバタ選択論理テーブル６０１、６０３中に、新しいアバタファイルを表示するための要件として増加した速度をリンクする別の行を含めることを必要とする。

本明細書で開示する様々な方法を実装することによって、第１のユーザは、第１のユーザの現在のアクティビティの正確な表現を第２のユーザに与えることができる。たとえば、インターネットフォーラム設定において、表示されるアバタは、ユーザがステータスを変化させるにつれて動的に変化させることができるであろう。従来の使用では、ユーザは、インターネットフォーラムの他のメンバーに表示されるユーザのアバタをプロアクティブに変化させることができる。しかしながら、アバタは、ユーザが表示のために選択されたファイルをプロアクティブに変更した場合のみ変化することになる。本明細書で開示する実施形態では、インターネットフォーラムの他のメンバーは、ユーザがアクティビティまたはステータスを変化させるにつれて、ユーザのアバタが自動的に変化することに気づくことができる。このようにして、ユーザは、もはやユーザのステータスを反映するために表示すべきアバタをアクティブに改変する必要はない。当業者なら、同様の適用例が、インスタントメッセージング、テキストメッセージング、または標準的な電話の状況にも実装できることを諒解されよう。

様々な実施形態は、モバイルデバイスのいくつかの新しい適用例を与える。そのような適用例は、同僚との通信を改善することと、子供のアクティビティを監視することと、ゲームへの参加を広げることと、医療モニタリングとを含む。

上述のように、アバタは、「百聞は一見にしかず（a picture is worth a thousand words）」であるので、ユーザに関する情報を迅速に通信することができる。ユーザは、同僚が、電子メールを送信するかまたは電話をかけるより前にユーザのステータスを迅速に判断することができるように、アバタを選択し、アバタ選択基準をプログラムすることができる。たとえば、同僚は、ユーザのアバタにアクセスできる場合、電子メールを送信するかまたは電話をかけるより前にアバタを素早く見ることにより、ランニングのために外出中、会議中、または休暇中など、ユーザが、迅速な応答を妨げる何らかのアクティビティに関与しているかどうかを知ることになる。ある個人がユーザのアバタに対するアクセス権を与えられている場合、その個人が、電子メールを送信するかまたは電話をかけるより前に、またはその一部としてユーザのステータスを調べることができるように、アバタへのアクセスリンク（たとえば、アバタをホスティングしているＩＰアドレスへのハイパーリンク）をアドレス帳に組み込むことができる。このようにして、アバタのユーザは、選択された同僚にユーザのステータスをプロアクティブに知らせることができる。たとえば、ユーザが会議（あるいは旅行または休暇）中であることを示すアバタをポスティングすることによって、ユーザに連絡することを望む人々は、呼は返答されず、電子メールはすぐに読まれないことを知ることになる。

様々な実施形態の一適用例では、親は、子供が親から見えない所にいるとき、子供を追跡することが可能である。たとえば、親は、実施形態のうちの１つまたは複数に従って構成されたモバイルデバイスを身に着けている子供を、子供のロケーションと現在アクティビティとを含む、自分の子供のアバタを表示するウェブサイトにアクセスして追跡することができる。たとえば、子供の親は、「かくれんぼ」のゲームに関与している子供を、各子供のロケーションおよび移動／ステータスを示すアバタを含む遊び場の地図を閲覧して監視することができる。

ゲーム設定では、表示されるアバタは、ユーザの現実の世界の移動およびアクティビティの移動およびアクティビティによりぴったりリンクできる。たとえば、様々な実施形態は、観客が仮想世界表現でペイントボールの試合を見ている間、ユーザがペイントボールのゲームに関与することを可能にすることができる。各参加者は、動き、位置およびロケーションセンサのスイートを含むモバイルデバイス３０１を装備し、各センサは、ほぼリアルタイムでセンサデータを中央サーバ１０９に報告することができる。さらに、ある個人がペイントボールガンに直面している方向、またはペイントボールガンの狙いを定めている方向など、参加者の姿勢および移動に関するデータを与えるために、位置センサをユーザの四肢に装着し、ワイヤレスデータリンク（たとえば、ブルートゥース）によってモバイルデバイスに結合することができる。試合の仮想世界表現中に各ペイントボール参加者を表すアバタを生成することができ、各ユーザのアバタは、リアルタイムでサンプリングされるモバイルデバイス３０１のセンサデータに基づいて、ロケーションおよびアクティビティ（すなわち、走る、座る、隠れる）を変化させる。仮想世界アバタ表現は、したがって、モバイルデバイス３０１を担持する現実の世界のユーザの移動およびアクティビティを正確に模することができる。

明らかに、ゲームに適用する同じ設定を、国防性質の訓練演習に移すことができるであろう。

医療モニタリング適用例では、モバイルデバイス３０１上の医療センサ、またはワイヤレスデータリンク（たとえば、ブルートゥース）によってプロセッサに接続された医療センサは、患者の現在のステータスを反映するアバタを選択するために、医療センサのデータを（たとえば、モバイルデバイス３０１を通して）そのような情報を使用するシステムに報告することができる。医療設定では、プロセッサは、モバイルである必要はなく、代わりに救急室または病院情報システムなどの設備に関連することができる。血圧、脈拍、ＥＫＧ、およびＥＥＧセンサなど患者に関連するセンサデータは、各患者に結合された様々な医療センサから受信できる。センサの各々に関連するアバタ選択基準を使用して、患者の医療ニーズまたは状態を反映するアバタを選択することができる。たとえば、医療センサが、苦しんでいる患者のためのアバタ基準を満たすデータを与える場合、プロセッサは、赤い背景の患者の写真からなるアバタを選択し、看護ステーションに対してそのアバタを表示することができる。そのようなアバタの使用は、重要な情報を、スクリーン上に提示されたテキスト（たとえば、患者の名前および医療データ）よりも効率的に通信することができる。別の例として、患者の医師がアクセス可能なサーバにデータを中継することができる短距離通信データリンクなどによって、デバイスまたは患者の心臓の状態に関する情報をモバイルデバイスに送信するようにペースメーカを構成することができる。そのサーバは、患者のステータスを医師に効率的に通信するために、患者のペースメーカデータを使用して、適切なアバタを選択することができる。

上記の実施形態を実装するために使用されるハードウェアは、命令のセットを実行するように構成された処理要素およびメモリ要素とすることができ、命令のセットは上記の方法に対応する方法ステップを実行するためのものである。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行できる。

本明細書で開示した実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを当業者なら諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。

本明細書で開示する実施形態に関して説明する方法またはアルゴリズムのステップは、直接ハードウェアで実施するか、プロセッサによって実行されるソフトウェアモジュールで実施するか、またはその２つの組合せで実施することができる。ソフトウェアモジュールは、両方ともＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当技術分野で知られている任意の他の有形形態の記憶媒体のいずれかとすることができるプロセッサ可読記憶媒体および／またはプロセッサ可読メモリ中に常駐することができる。その上、プロセッサ可読メモリは、２つ以上のメモリチップと、プロセッサチップの内部の別々のメモリチップ中のメモリと、フラッシュメモリやＲＡＭメモリなどの様々なタイプのメモリの組合せとを備えることができる。本願明細書におけるモバイルハンドセットのメモリへの言及は、特定の構成、タイプまたはパッケージングに限定されない、モバイルハンドセット内のいずれか１つまたはすべてのメモリモジュールを包含するものとする。例示的な記憶媒体は、モバイルハンドセットまたはテーマサーバのいずれかの中のプロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサに一体化することができる。プロセッサおよび記憶媒体はＡＳＩＣ中に常駐することができる。

様々な実施形態の上記の説明は、当業者が本発明を実施または使用できるようにするために提供されるものである。これらの実施形態への様々な修正は当業者には容易に明らかであり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用できる。したがって、本発明は、本明細書で示した実施形態に限定されるものでなく、代わりに、特許請求の範囲は、本明細書で開示した原理および新規の特徴に合致する最も広い範囲を与えられるべきである。

Claims (62)

1. モバイルデバイスユーザのステータスを示すためにアバタを自動的に更新するための方法であって、
   前記ユーザのモバイルデバイスに接続されたセンサをポーリングすることと、
   センサデータをアバタ選択基準と比較することと、
   前記センサデータと前記アバタ選択基準との前記比較に基づいて表示のためにアバタを選択することと
   を備える方法。
2. カレンダデータをアバタ選択基準と比較することと、
   カレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
   をさらに備える、請求項１に記載の方法。
3. モバイルデバイス設定をアバタ選択基準と比較することと、
   モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
   をさらに備える、請求項１に記載の方法。
4. 第２のユーザの許可レベルをアバタ選択基準と比較することと、
   前記第２のユーザの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
   をさらに備える、請求項１に記載の方法。
5. センサをポーリングする前記ステップと、センサデータをアバタ選択基準と比較する前記ステップと、表示のためにアバタを選択する前記ステップとが、サーバから受信したアバタの要求に応答して実行される、請求項１に記載の方法。
6. センサをポーリングする前記ステップと、センサデータをアバタ選択基準と比較する前記ステップと、表示のためにアバタを選択する前記ステップとが、別のコンピューティングデバイスから受信したアバタの要求に応答して実行され、前記選択されたアバタを表示のために前記他のコンピューティングデバイスに送信することをさらに備える、請求項１に記載の方法。
7. アバタの要求が前記サーバによって受信されたときのみ、前記サーバが前記モバイルデバイスから前記アバタを要求する、請求項５に記載の方法。
8. 前記選択されたアバタの識別子をサーバに送信することと、
   前記識別子を使用して前記サーバのメモリからアバタファイルを呼び戻すことと
   をさらに備える、請求項１に記載の方法。
9. 前記センサデータをサーバに送信することをさらに備え、前記センサデータをアバタ選択基準と比較する前記ステップと、前記比較に基づいて表示のためにアバタを選択する前記ステップとが前記サーバ上で実行される、請求項１に記載の方法。
10. 前記サーバによってホスティングされるウェブページに前記選択されたアバタを挿入することをさら備える、請求項９に記載の方法。
11. カレンダデータを前記サーバに送信することと、
    前記サーバにおいてカレンダデータをアバタ選択基準と比較することと、
    前記サーバにおいて実行されたカレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備える、請求項９に記載の方法。
12. モバイルデバイス設定を前記サーバに送信することと、
    前記サーバにおいてモバイルデバイス設定をアバタ選択基準と比較することと、
    前記サーバにおいて実行されたモバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備える、請求項９に記載の方法。
13. 前記センサデータを別のコンピューティングデバイスに送信することをさらに備え、前記センサデータをアバタ選択基準と比較する前記ステップと、前記比較に基づいて表示のためにアバタを選択する前記ステップとが前記他のコンピューティングデバイス上で実行される、請求項１に記載の方法。
14. カレンダデータを前記他のコンピューティングデバイスに送信することと、
    前記他のコンピューティングデバイスにおいてカレンダデータをアバタ選択基準と比較することと、
    前記他のコンピューティングデバイスにおいて実行されたカレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備える、請求項１３に記載の方法。
15. モバイルデバイス設定を前記他のコンピューティングデバイスに送信することと、
    前記他のコンピューティングデバイスにおいてモバイルデバイス設定をアバタ選択基準と比較することと、
    前記他のコンピューティングデバイスにおいて実行されたモバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備える、請求項１３に記載の方法。
16. 前記他のコンピューティングデバイスの許可レベルを得ることと、
    前記他のコンピューティングデバイスにおいて前記他のコンピューティングデバイスの前記許可レベルをアバタ選択基準と比較することと、
    前記他のコンピューティングデバイスにおいて実行された前記他のコンピューティングデバイスの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備える、請求項１３に記載の方法。
17. 前記ユーザのモバイルデバイスに接続されたセンサをポーリングする前記ステップが、全地球測位センサと、加速度計と、温度センサと、生体センサと、光センサと、雑音センサとからなるグループから選択された少なくとも１つのセンサからデータを得ることを備える、請求項１に記載の方法。
18. プロセッサと、
    前記プロセッサに結合されたトランシーバと、
    前記プロセッサに結合されたメモリと、
    全地球測位センサと、加速度計と、温度センサと、生体センサと、光センサと、雑音センサとからなるグループから選択されたパラメータを測定するように構成された少なくとも１つのセンサと
    を備えるモバイルデバイスであって、
    前記プロセッサが、
    前記少なくとも１つのセンサからセンサデータを受信することと、
    前記センサデータをアバタ選択基準と比較することと、
    前記センサデータと前記アバタ選択基準との前記比較に基づいて表示のためにアバタを選択することと
    を備えるステップを実行するようにソフトウェア命令を用いて構成された、モバイルデバイス。
19. プロセッサが、
    カレンダをアバタ選択基準と比較することと、
    カレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備えるステップを実行するようにソフトウェア命令を用いて構成された、請求項１８に記載のモバイルデバイス。
20. プロセッサが、
    モバイルデバイス設定をアバタ選択基準と比較することと、
    モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備えるステップを実行するようにソフトウェア命令を用いて構成された、請求項１８に記載のモバイルデバイス。
21. プロセッサが、
    第２のユーザの許可レベルをアバタ選択基準と比較することと、
    前記第２のユーザの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    をさらに備えるステップを実行するようにソフトウェア命令を用いて構成された、請求項１８に記載のモバイルデバイス。
22. 前記プロセッサが、センサデータを受信する前記ステップと、センサデータをアバタ選択基準と比較する前記ステップと、表示のためのアバタを選択する前記ステップとを、サーバから受信したアバタの要求に応答して実行するようにソフトウェア命令を用いて構成された、請求項１８に記載のモバイルデバイス。
23. プロセッサが、センサデータを受信する前記ステップと、センサデータをアバタ選択基準と比較する前記ステップと、表示のためのアバタを選択する前記ステップとを、別のコンピューティングデバイスから受信したアバタの要求に応答して実行するようにソフトウェア命令を用いて構成された、請求項１８に記載のモバイルデバイス。
24. プロセッサが、前記選択されたアバタの識別子を前記トランシーバを介して前記サーバに送信することをさらに備えるステップを実行するようにソフトウェア命令を用いて構成された、請求項２２に記載のモバイルデバイス。
25. プロセッサが、前記選択されたアバタを前記トランシーバを介して前記サーバに送信することをさらに備えるステップを実行するようにソフトウェア命令を用いて構成された、請求項２２に記載のモバイルデバイス。
26. プロセッサが、前記選択されたアバタを前記トランシーバを介して前記他のコンピューティングデバイスに送信することをさらに備えるステップを実行するようにソフトウェア命令を用いて構成された、請求項２３に記載のモバイルデバイス。
27. 外部センサからセンサデータを受信し、前記センサデータを前記プロセッサに与えるように構成された短距離ワイヤレストランシーバをさらに備える、請求項１８に記載のモバイルデバイス。
28. ユーザのステータスを示すパラメータを感知するための手段と、
    前記感知されたパラメータをアバタ選択基準と比較するための手段と、
    前記比較に基づいて表示のためにアバタを選択するための手段と
    を備えるモバイルデバイス。
29. モバイルデバイス設定をアバタ選択基準と比較するための手段と、
    モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項２８に記載のモバイルデバイス。
30. モバイルデバイス設定をアバタ選択基準と比較するための手段と、
    モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項２８に記載のモバイルデバイス。
31. 第２のユーザの許可レベルをアバタ選択基準と比較するための手段と、
    前記第２のユーザの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項２８に記載のモバイルデバイス。
32. 前記選択されたアバタをサーバに送信するための手段をさらに備える、請求項２８に記載のモバイルデバイス。
33. 前記モバイルデバイスの外部のセンサからセンサデータを受信するための手段をさらに備える、請求項２８に記載のモバイルデバイス。
34. プロセッサに結合された少なくとも１つのセンサからセンサデータを受信することと、
    前記センサデータをアバタ選択基準と比較することと、
    前記センサデータと前記アバタ選択基準との前記比較に基づいて表示のためにアバタを選択することと
    を備えるステップを前記プロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を記憶した有形記憶媒体。
35. 前記有形記憶媒体が、
    カレンダをアバタ選択基準と比較することと、
    カレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップをプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
36. 前記有形記憶媒体が、
    モバイルデバイス設定をアバタ選択基準と比較することと、
    モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップをプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
37. 前記有形記憶媒体が、
    第２のユーザの許可レベルをアバタ選択基準と比較することと、
    前記第２のユーザの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップをプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
38. 前記有形記憶媒体が、センサデータを受信する前記ステップと、センサデータをアバタ選択基準と比較する前記ステップと、表示のためにアバタを選択する前記ステップとを、サーバから受信したアバタの要求に応答してプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
39. 前記有形記憶媒体が、センサデータを受信する前記ステップと、センサデータをアバタ選択基準と比較する前記ステップと、表示のためにアバタを選択する前記ステップとを、別のコンピューティングデバイスから受信したアバタの要求に応答してプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
40. 前記有形記憶媒体が、前記選択されたアバタの識別子をサーバに送信することを備えるさらなるステップをプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
41. 前記有形記憶媒体が、前記選択されたアバタをサーバに送信することを備えるさらなるステップをプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を有する、請求項３４に記載の有形記憶媒体。
42. ユーザのソーシャルウェブページをホスティングし、ネットワークを介してデータを受信および送信するように構成されたサーバであって、
    前記ユーザのソーシャルウェブページを記憶したサーバメモリと、
    前記サーバメモリに結合されたサーバプロセッサとを備え、前記サーバプロセッサが、
    前記ユーザのモバイルデバイスからセンサデータを受信することと、
    前記受信したセンサデータをアバタ選択基準と比較することと、
    前記センサデータとアバタ選択基準との前記比較に基づいて表示のためにアバタを選択することと、
    前記選択されたアバタを前記サーバメモリに記憶された前記ユーザのソーシャルウェブページに含めることと
    を備えるステップを実行するようにソフトウェア命令を用いて構成された、サーバ。
43. 前記サーバプロセッサが、
    前記ユーザのモバイルデバイスからカレンダデータを受信することと、
    前記カレンダデータをアバタ選択基準と比較することと、
    前記カレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるステップを実行するようにソフトウェア命令を用いてさらに構成された、請求項４２に記載のサーバ。
44. 前記サーバプロセッサが、
    前記ユーザのモバイルデバイスからモバイルデバイス設定を受信することと、
    前記モバイルデバイス設定をアバタ選択基準と比較することと、
    前記モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるステップを実行するようにソフトウェア命令を用いてさらに構成された、請求項４２に記載のサーバ。
45. 前記サーバプロセッサが、
    第２のユーザのコンピューティングデバイスから許可レベルデータを受信することと、
    前記第２のユーザのコンピューティングデバイスの前記許可レベルデータをアバタ選択基準と比較することと、
    前記第２のユーザのコンピューティングデバイスの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるステップを実行するようにソフトウェア命令を用いてさらに構成された、請求項４２に記載のサーバ。
46. 前記サーバプロセッサが、
    前記ユーザのモバイルデバイスからパラメータ値テーブルを受信することと、
    前記パラメータ値テーブル中の値をアバタ選択基準と比較することと、
    前記パラメータ値テーブルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるステップを実行するようにソフトウェア命令を用いてさらに構成された、請求項４２に記載のサーバ。
47. 前記サーバプロセッサが、
    前記ユーザのモバイルデバイスにセンサデータを送信するように要求すること
    を備えるステップを実行するようにソフトウェア命令を用いてさらに構成された、請求項４２に記載のサーバ。
48. 前記サーバプロセッサが、前記ユーザのアバタの要求を受信したことに応答して、前記ユーザのモバイルデバイスにセンサデータを送信するように要求することを備えるステップを実行するようにソフトウェア命令を用いてさらに構成された、請求項４２に記載のサーバ。
49. ユーザのモバイルデバイスからセンサデータを受信するための手段と、
    前記受信したセンサデータをアバタ選択基準と比較するための手段と、
    前記センサデータとアバタ選択基準との前記比較に基づいて表示のためにアバタを選択するための手段と、
    前記選択されたアバタを前記サーバメモリに記憶された前記ユーザのソーシャルウェブページに含めるための手段と
    を備えるサーバ。
50. 前記ユーザのモバイルデバイスからカレンダデータを受信するための手段と、
    前記カレンダデータをアバタ選択基準と比較するための手段と、
    前記カレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項４９に記載のサーバ。
51. 前記ユーザのモバイルデバイスからモバイルデバイス設定を受信するための手段と、
    前記モバイルデバイス設定をアバタ選択基準と比較するための手段と、
    前記モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項４９に記載のサーバ。
52. 要求側ユーザのコンピューティングデバイスから許可レベルデータを受信するための手段と、
    前記要求側ユーザのコンピューティングデバイスの前記許可レベルデータをアバタ選択基準と比較するための手段と、
    前記要求側ユーザのコンピューティングデバイスの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項４９に記載のサーバ。
53. 前記ユーザのモバイルデバイスからパラメータ値テーブルを受信するための手段と、
    前記パラメータ値テーブル中の値をアバタ選択基準と比較するための手段と、
    前記パラメータ値テーブルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択するための手段と
    をさらに備える、請求項４９に記載のサーバ。
54. 前記ユーザのモバイルデバイスにセンサデータを送信するように要求するための手段をさらに備える、請求項４９に記載のサーバ。
55. 前記ユーザのアバタの要求を受信したことに応答して、前記ユーザのモバイルデバイスに、センサデータを送信するように要求するための手段をさらに備える、請求項４９に記載のサーバ。
56. 前記ユーザのモバイルデバイスからセンサデータを受信することと、
    前記受信したセンサデータをアバタ選択基準と比較することと、
    前記センサデータとアバタ選択基準との前記比較に基づいて表示のためにアバタを選択することと、
    前記選択されたアバタを前記サーバメモリに記憶された前記ユーザのソーシャルウェブページに含めることと
    を備えるステップを前記サーバに実行させるように構成されたサーバ実行可能ソフトウェア命令を記憶した有形記憶媒体。
57. 前記記憶されたサーバ実行可能ソフトウェア命令が、
    前記ユーザのモバイルデバイスからカレンダデータを受信することと、
    前記カレンダデータをアバタ選択基準と比較することと、
    前記カレンダデータとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップを前記サーバに実行させるように構成された、請求項５６に記載の有形記憶媒体。
58. 前記記憶されたサーバ実行可能ソフトウェア命令が、
    前記ユーザのモバイルデバイスからモバイルデバイス設定を受信することと、
    前記モバイルデバイス設定をアバタ選択基準と比較することと、
    前記モバイルデバイス設定とアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップを前記サーバに実行させるように構成された、請求項５６に記載の有形記憶媒体。
59. 前記記憶されたサーバ実行可能ソフトウェア命令が、
    要求側ユーザのコンピューティングデバイスから許可レベルデータを受信することと、
    前記要求側ユーザのコンピューティングデバイスの前記許可レベルデータをアバタ選択基準と比較することと、
    前記要求側ユーザのコンピューティングデバイスの前記許可レベルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップを前記サーバに実行させるように構成された、請求項５６に記載の有形記憶媒体。
60. 前記記憶されたサーバ実行可能ソフトウェア命令が、
    前記ユーザのモバイルデバイスからパラメータ値テーブルを受信することと、
    前記パラメータ値テーブル中の値をアバタ選択基準と比較することと、
    前記パラメータ値テーブルとアバタ選択基準との前記比較にさらに基づいて表示のために前記アバタを選択することと
    を備えるさらなるステップを前記サーバに実行させるように構成された、請求項５６に記載の有形記憶媒体。
61. 前記記憶されたサーバ実行可能ソフトウェア命令が、前記ユーザのモバイルデバイスにセンサデータを送信するように要求することを備えるさらなるステップを前記サーバに実行させるように構成された、請求項５６に記載の有形記憶媒体。
62. 前記記憶されたサーバ実行可能ソフトウェア命令が、ユーザのアバタの要求を受信したことに応答して、前記ユーザのモバイルデバイスに、センサデータを送信するように要求することを備えるさらなるステップを前記サーバに実行させるように構成された、請求項５６に記載の有形記憶媒体。

Images