JP2008512736A - 永続的、移入可能及び抽出可能なアバター - Google Patents

Abstract

アバターデータは管理アプリケーションに格納されている。管理アプリケーションはアプリケーションに移入要求を送信する。管理アプリケーションは、アプリケーションにより使用されるアバターデータフィールド、適切なスケーリング及びアバター変換を特定する。管理アプリケーションは、データを適切にスケーリングし、必要であればアバターを変換し、（スケーリングされて、変換された）アバターデータをアプリケーションに送信する。アバターがアプリケーションから取り出されるとき、アプリケーションは管理アプリケーションにアバターデータを送り戻し、管理アプリケーションはアバターに加えられた変化をオリジナルのアバターデータに統合させる。
【選択図】 図1

Description

本発明はアバター(Avaters)に関し、より詳しくは複数のアプリケーションを備えたコンピュータで使用可能なアバターに関する。

ウェブスターの第三新国際辞典（Third New International Dictionary）(大辞典)によると、「アバター」（avatar）は「この世における神の降下と化身、. . . 人間への化身または具体化、. . . 通常は人における概念、哲学または伝統の著しく完全な顕現または具体化、. . . 場合によっては名前の変更にすぎないこともある継続的な基本的存在の様々な姿または変形・・・」と定義される(ウェブスターの第三新国際辞典150(2002))。この言葉がコンピュータ技術で使用されるとき、その意図する意味は、これらの定義の間のどこかに当てはまるが、おそらくアプリケーションにおける人の表示というのが最適な表現であろう。

コンピュータ技術におけるアバターの語(以下、単に「アバター」という)の使用について言えば、アバターの語は各種分野で使用されているが、コンピュータゲームにおける使用が最も顕著である。Asheron's Call (Turbine Entertainment Software Corporationの登録商標)などのゲームでは、多くの異なるプレーヤーが、オンライン上で協力して(または協力せずに)プレーすることができる。各プレーヤーは、キャラクターのタイプやプレーヤーの好みの図形的表示(graphical representation)を選び、その図形的表示に情報やアイテム持たせて自分の表示を作る。プレーヤーの代わりに行動するこの図形的表示がアバターの一例である。

しかし、今日使用されているアバターは、個々の環境に限定されている。プレーヤーは、Asheron's Callから自分のアバターを取り出して、そのアバターを異なるゲーム(おそらくTurbine Entertainmentの後継ゲームは例外となる)に挿入することができない。したがって、そのプレーヤーが異なるゲームをすることを希望するのであれば、異なるゲームのために異なるアバターを作る必要がある。この必要とされる複製は、一つのアバター作成に要した過程（effort）が、異なる環境におけるアバターの作成に役に立たないことを意味する。さらに悪いことには、一つのゲームから他のゲームまでアバターの情報（詳細）を何ら持ち越す方法がなく、このことは、そのキャラクターの作成や開発に費やした時間をもう一度繰り返さなければならないことを意味する。

本発明の実施例は、コンピュータ技術におけるこれらの問題や他の問題を解消することを課題としたものである。

図１は、本発明の実施例に係る、複数のアプリケーションにおいてアバターを具体化（作成／instantiate）するために他のアプリケーションと情報交換をする管理アプリケーションを示している。図１において、管理アプリケーション105は、アバター及びアプリケーション110と115のような多様なアプリケーションへのアバターの挿入(または、移入／immersion)の管理をつかさどる。

図１は二つのアプリケーションだけを示しているが、当業者であればアバターを挿入することのできるアプリケーションがいくつあってもよいことを理解するであろう。

アバターを格納するために、管理アプリケーション105はデータ格納部120を含んでいる。図１において、データ格納部120が三つのアバターデータ125、130及び135を格納する状態が示されているが、当業者であればデータ格納部120がいくつものアバターデータを格納することができることを理解するであろう。

アバターがアプリケーションに移入されるとき、アプリケーションはそのアバターのデータを保持している必要はない。アプリケーションは管理アプリケーション105からデータを受信する。管理アプリケーション105は、アプリケーションと通信してアプリケーションがどのようなデータを必要とするのかを決定する。そして、管理アプリケーション105はそのデータをアプリケーションに送信し、アプリケーションがアバタ-を処理するのを可能にする。例えば、図１は、管理アプリケーション105が通信回線140と145をそれぞれ使用してアプリケーション110と115と通信する様子を示している。

通信回線140と145は、ローカル・エリア・ネットワーク(LAN)、ワイドエリアネットワーク(WAN)、またはインターネットなどのネットワークを含む所望の通信網でもよい。ハードウェアは、MegabitやGigabit Ethernetなどの有線ネットワーク、またはIEEE802.11無線ネットワーク規格やブルートゥースネットワークなどの無線ネットワークを含むことができる。ネットワークはインフラを使用することも可能であるし、アドホックネットワークとして機能することもできる。通信回線上にデータを送るために、伝送制御プロトコル/インターネット・プロトコル(TCP/IP)やユーザ・データグラム・プロトコル(UDP)のような所望のプロトコルを使用することができる。

図１は、アバターデータ125の二つの複製(複製150と155として図示される)を、アプリケーション１と２(符号110と115)に送信する管理アプリケーション105を示しているが、当業者であれば、一般的には、一つのアバターは一つのアプリケーションだけに移入されることを理解するであろう。二つ以上のアプリケーションに同時に同じアバターをそれぞれ移入させると、一方のアプリケーションにおけるアバターは、他のアプリケーションでそのアバターが得た経験とは異なる経験を得るという結果になる場合がある。しかし、管理アプリケーション105に二つの異なるアプリケーションから来たアバターデータを統合して、起こりえる経験の矛盾を解消する能力があれば、管理アプリケーション105は同じアバターを同時に複数のアプリケーションに移入することができる。さらに、以下に示すように、アバターを同時に複数のアプリケーションに移入するのに好都合な状況がある。

理想的には、管理アプリケーション105はすべてのアバターに関連するすべてのデータを格納する責任を負う。しかし、実際には、いくつかのアプリケーションがそれらの中の特定のアプリケーションに特有で他のアプリケーションから必要とされないアバターデータを使うことも起こり得る。管理アプリケーション105にこのような特有なデータを格納する責任を負わせることもできるが、代替案として、アプリケーションの側にそのようなアプリケーションに特有のアバターデータを格納させる責任を負わせてもよい。図１に示すように、アプリケーション110はデータ格納部160を有しており、当該アプリケーション110に特有のアバターデータ165を格納している状態が示されている。アバターデータ150がアプリケーション110に送信されると、アプリケーション110は、アバターが当該アプリケーションと関係を持ち始める前に、当該アプリケーションに特有なアバターデータ165をアプリケーション側のアバターデータ150に統合する。

アプリケーションによるアバターの処理が終了した後、そのアプリケーションは、通信回線（140）と（145）を使用して管理アプリケーション105にアバターデータを戻すことができる。アプリケーションは、そのアプリケーションによって作成されたデータで、管理アプリケーション105により提供されたデータに含まれていなかったデータであっても(もし、そのデータがアバター移入のときに他のアプリケーションでも使用されるのであれば)、管理アプリケーション105にすべてのデータを戻すことができる。また、アプリケーションは、そのデータ格納部に当該アプリケーションに特有なデータを格納することもできる。

図示するように複数のアプリケーションへのアバターの移入を可能とするために、アバター移入の標準規格に関する協定（an agreement on the standard）が必要とされる。本発明の実施例の一つにおいて、認証機関（a certifying organization）により標準規格が設けられる。この認証機関は、管理アプリケーション105によりアバターがどのように格納されるか、管理アプリケーション105によりどのようなタイプのデータが格納できるのか、管理アプリケーション105とアプリケーションの間を通過するメッセージがどのように構成され通信されるのかなどを定義することができる。そして、移入可能なアバターをサポートするために、各アプリケーションは標準規格に従う必要がある。つまり、アプリケーションは認証機関によって認証されなければならない。

認証機関が行うことのできるもう一つの機能は、各アプリケーションに適したスケールを決定することである。図２と４を参照して以下に説明するように、管理アプリケーション105により行われる一つの機能は、アバターデータをアプリケーションに送信する前にスケーリングすることである。異なるアプリケーションの間では、他のアプリケーションと比べて、経験を積んでアバターを開発するのに要する過程が簡単である場合も困難である場合もある。これらの内部レベルの困難の度合いの相違を明らかにするために、標準規格化機関（the standard-setting organization）は、各アプリケーションを調査することが可能であり、また、移入可能なアバターを使用するためにアプリケーションへ資格を与えるプロセスの一部として、管理アプリケーション105で使用されるスケールに対してそのアプリケーションが適合するスケールを決めることができる。当業者であれば、アプリケーションによっては複数のスケールが適切であることを理解するであろう。例えば、あるアプリケーションは、一つのアバター属性に関してより難しいかもしれないが、他のアバター属性に関してはより簡単かもしれない。

認証機関がどのような作業をするかの例として、マルチプレーヤーゲーム環境におけるアバターを考えてみる。一方のゲームアプリケーションは、アバターがアーチェリーの「コース」を取るのであれば、弓矢を使用する環境に設定される。もう一つのゲームアプリケーションは、代わりにライフル銃などのより近代的な武器を使用する。弓矢の使い方の習得は、ライフル銃の使い方の習得より難しい技能であるが、それらのツール自体は本質的に交換可能である。したがって、管理アプリケーション105にそれぞれの技能とツールの情報を個別に格納させるよりはむしろ、アバターが技能習得を通じて進歩するにつれて、管理アプリケーション105はそれまで費やされた過程を反映したスケーリングされたデータを格納することができる。そして、もし以上の異なるゲームアプリケーションを使用する二つのアバターが、それぞれの技能を習得するために同じ程度の過程を経るのであれば、弓矢の使い方を習得するアバターは、ライフル銃の使い方を習得するアバターより、より高度にスケーリングされる。また、弓矢の使い方を習得するアバターが、ライフル銃のゲームアプリケーションに切り替わるなら、それらの技能の困難レベルの違いを反映して経験レベルはより下のレベルにスケーリングされる。

これをより明確に説明するために、技能には初心者、中級者、上級者のような異なる熟練レベルがあると仮定する。さらに、弓矢については各熟練レベルについて６単位の過程を必要とし、ライフル銃については各熟練レベルについて４単位の過程を必要とするとする。もし、プレーヤーがライフル銃の初心者レベルを達成するのに４単位中３単位を習得し終えたのなら、それは弓矢の初心者レベルを達成するために６単位中大体４単位を習得したことと同様のことである。したがって、ライフル銃について１単位のみ未修得で残されていても、弓矢については２単位が未修得で残されていることになる。別の角度からいうと、もしプレーヤーが弓矢で初心者の熟練レベル達成に向けて６単位中３単位を習得し、次に、他のライフル銃を使うゲームアプリケーションに切り替えたのであれば、ライフル銃の使い方の習得については２単位だけが残されていることになる。

ユーザは（通常）アバターをその環境からいつでも取り出すことができるので、アバターデータは当該技能の習得に費やされた過程に関するデータを保持する。したがって、アバターを弓矢のゲーム環境の中級者レベルに達した後で取り出すのであれば、それは１２単位の過程を経たことを意味する。このアバターがライフル銃のゲーム環境に移入されると、この１２単位の過程は、アバターがより狙いが正確になるかあるいは再装弾が早くなることを意味する上級者レベルであることを表す。

弓矢またはライフル銃の使用のような習得した技能は、スケーリングすることが可能な一つのタイプのデータであるが、当業者であれば、アバターデータのどのようなデータでもスケーリングできることを理解するであろう。例えば、アバターの物理的、精神的、感情的、教育的な属性や他の属性を格納してスケーリングすることができる。より具体的な例として、いくつかのアバターは、知性、カリスマ、強さ、知恵などの属性を含むかもしれない。これらの属性は、無形であり、一度設定すると変更するのがある程度難しい。

アプリケーションにより使用されるフィールドに比較的互換性がありさえすれば、複数のアプリケーションは同じアバターデータを使用できるが、スケーリングがアバターを個々のアプリケーションに適合させるために必要とされるすべてではない。例えば、アプリケーション内のアバターの図形的表示は特定のアプリケーションに応じて変わるかもしれない。一つのゲームアプリケーションは、人間の人種的グループから選ばれたアバターを使用するかもしれないし、他のゲームアプリケーションは、人種の下位範疇に属さない宇宙人から選んだアバター表現を使用するかもしれない。例えば、Star Trek（登録商標）環境では、人間のKlingon（登録商標）、Romulan（登録商標）及び他の宇宙人のアバターが使用されるかもしれない(Star Trek、 Klingon及びRomulanはParamount Pictures Corporationの登録商標である)。したがって、アバターをアプリケーションへ移入する際に、データを当該アプリケーションに適切な形式への変換が必要となる場合がある。この変換は、(もし適切なマッピングが容易に決定できるのであれば)自動的にでき、あるいはユーザが所望の変換を選択することによって手動でもできる。この変換は、管理アプリケーション105またはアバターが移入されているアプリケーションのいずれかにより行うこともできる。管理アプリケーション105が変換を実行するのであれば、それぞれのアプリケーション側では変換を実行する個々の負担を不要とすることができる。しかし、個々のアプリケーションが変換を実行するのであれば、これらのアプリケーションは、変換が最も有利に行われる方法をカスタマイズすることができる。

認証の一部として、アプリケーションが全ての可能性のあるデータフィールドを使用することは要求されない。例えば、アプリケーションは、アバターが経験を積んでオブジェクトと情報交換することは許可するが、実際にオブジェクトを担持することは許可しないようにしてもよい。このタイプのアプリケーションは、管理アプリケーション105を必要とすることなく認証され、当該アプリケーションへのアバター移入の一部として担持されたオブジェクトを提供する。

図２は、本発明の実施例に係る図１の管理アプリケーションの詳細を示す。図２において、管理アプリケーション105がいくつかの構成要素を含む状態が示されている。リクエスタ205は、アプリケーションが使用するデータフィールド及びそれらのデータフィールドのスケーリングを要求するために用いられ、それらのデータフィールドには、移入されるアバターデータが格納される。通常、管理アプリケーション105は、アバター移入の要求の一部として、アプリケーションからこの情報を要求するが、当業者であればこの情報が第三者機関、例えば、認証機関からの要求であってもよいことを理解するであろう。セレクタ210は、アプリケーションで使用されるフィールドに対応するデータを(図１に示す)データ格納部から選ぶ。スケーラ215は、上述したような理由により、データをアプリケーションに適したレベルにスケーリングするのをつかさどる。トランスフォーマ220は、上述のとおり、データをアプリケーションに適した形式に変換するのをつかさどる。インターフェース225は、アプリケーションと通信するのに使用される（つまり、リクエスタ205からの情報を送信するとともに、スケーラ215とトランスフォーマ220のそれぞれによりアバターがスケーリングされかつ変換された後でそのアバターを送信する）。

レシーバ230は、アバターがアプリケーションと情報交換を終えた後で、当該アバターについてデータをアプリケーションから受信する。(再度、インターフェース225はこのやり取りに使用される。)アバターが移入されたときに幾つかのデータが変化している可能性があるため、インテグレータ235は、データ格納部に戻されたデータを統合するのをつかさどる。アプリケーションがすべてのアバターデータを必要としない(または、使用さえできない)かもしれないので、管理アプリケーション105は、アバターが移入されている間、アバターデータを削除してはならないことに留意する必要がある。したがって、インテグレータ235は、受信したアバターデータをまだデータ格納部に残されているオリジナルのデータに統合して戻す。

図３は、本発明の実施例に係る図１のアプリケーションの一つの詳細を示す。アプリケーション110はレシーバ305を含むものとして示されているが、このレシーバはアバターを当該アプリケーションに移入するための要求を受信するために使用される。トランスミッタ310は、アプリケーション110により使用されるアバターのデータフィールドを特定した上で応答する。(トランスミッタ310は、アプリケーション110からアバターが取り出された後、アバターデータを管理アプリケーションに送り返すことにも使用することができる。) アプリケーション110は、当該アプリケーションが使用するデータフィールドを格納するためにアバターテンプレート315を使用することができる。アバターインスタンティエータ(Avatar Instantiator)320は、管理アプリケーションから受信したアバターデータを取得し、そのデータを新しいアバターのデータフィールドを満たすために使用し、そしてアバターをアプリケーションで具体化（作成）することをつかさどる。最後に、アプリケーション110は、上述の変換を実行するトランスフォーマ325を含むことができる。

図４は、本発明の実施例に係る図１のシステムにおいて、アプリケーションにアバターを挿入（移入）するための管理アプリケーションにおける手順を示す。図４のステップ405で、管理アプリケーションは、アプリケーションにアバターを移入する要求を送信する。ステップ410で、管理アプリケーションは、当該アプリケーションで使用されるデータフィールドとそれらのスケーリングを受信する。図２を参照して上述したとおり、管理アプリケーションは、通常、アプリケーションからデータフィールドのデータをそれらのスケーリングとともに受信するが、認証機関のような第三者機関からこの情報を受信することもできる。ステップ415では、管理アプリケーションはアプリケーションによって要求されたデータをスケーリングする。ステップ420では、管理アプリケーションはアバターをアプリケーションに受け入れられるフォームに変換する。上述のとおり、管理アプリケーションは変換を実行する必要がない場合もあり、そのような場合は、矢印425で示すとおりステップ420は省略できる。ステップ430では、スケーリングされ、変換されたデータがアプリケーションに送信される。ステップ435では、管理アプリケーションはアプリケーションからアップデートされたアバターデータを受信する。ステップ440では、管理アプリケーションはアップデートされたデータを再スケーリングし、そして、ステップ445では、管理アプリケーションはスケーリングされアップデートされたデータをオリジナルのデータに組み込む。

図５Ａ−５Ｃは、本発明の実施例に係る図１のシステムにおいて、管理アプリケーションから受信されたアバターを具体化するアプリケーションにおける手順を示す。図５Ａのステップ505では、アプリケーションは、管理アプリケーションからアバター移入の要求を受信する。ステップ510では、アプリケーションはアバターに使用するデータフィールドを特定する。ステップ515では、アプリケーションは管理アプリケーションにデータフィールドのためのデータを要求する。矢印520で示すとおり、管理アプリケーションがアプリケーションにより使用されるデータフィールドを決定し、また独立した情報源（例えば、認証機関など）からデータフィールドのスケーリングを決定することができるのであれば、ステップ510と515は省略できる。ステップ525では、アプリケーションは管理アプリケーションからアバターデータを受信する。ステップ530では、アプリケーションはデータフィールドにそのアバターデータを格納する。

ステップ535（図５Ｂ）では、管理アプリケーションからのデータで満たされていないデータフィールドがあるかどうかをチェックする。もし満たされていないデータフィールドがあれば、ステップ540で、これらのデータフィールドが特定され、そして、ステップ545で、アプリケーションがアバター用のアプリケーション特有データ格納部からのデータを使用して、これらのデータフィールドを満たす(アバターが以前アプリケーションに移入されたことがあり、かかるデータが作られていると仮定する。そうでない場合、アバターはこれらのデータフィールドを初期設定値で満たす)。ステップ550では、アプリケーションはアバターを変換する。上述のとおり、もし管理アプリケーションが変換を実行するならば、矢印555で示すとおりステップ550は省略できる。ステップ560では、アプリケーションはアバターを具体化し、そして、ステップ565では、アバターが経験を積んだときにアプリケーションがデータフィールドでデータをアップデートする。

ステップ570(図５Ｃ)では、アプリケーションはアップデートされたデータを管理アプリケーションに送り返す。ステップ575では、アプリケーションは、管理アプリケーションが管理しないアバターデータがあるかどうか調べる。もし該当するデータがあれば、ステップ580で、アプリケーションはこれらのデータフィールドを特定し、ステップ585で、アプリケーションはアプリケーション特有データ格納部でこれらのデータフィールドのデータを格納する。

上記の説明は、ゲームアプリケーションにおけるアバターの使用に焦点を合わせているが、当業者であれば、他の環境でもアバターの使用ができることを理解するであろう。 例えば、アプリケーションはショッピング・モールの「店」でもよい。アバターの特性は(銀行名や銀行支店コード、口座番号、認定ユーザなどの)金銭上の情報源と(家や職場の住所や連絡窓口などの)購入が行われる場所の情報を含むことができる。アバターは購入を行う特定の店に移入させることが可能で、その結果、実社会での購入行為に影響がもたらされる。

例えば、ピザ店に関するアプリケーションにアバターを移入することができる。ユーザは、アバターを通じて注文オプションを見て、注文を実行することができる。ピザ店は注文品を届けるべき住所の情報をアバターから得る。ユーザはアバター経由で注文品の支払いを承認し、ピザ店は注文品をユーザに配達するよう地元のフランチャイズに指令する。

アバターの可能性のある他の使用として医療サービスがある。アバターは、例えば、最近の病気、外科的な病歴、薬のアレルギー、現在の処方箋などの人の病歴に関する情報を持つことができる。救急隊員は、そのようなアバターを介して、ユーザの現状と最近の病歴を習得し、より優れた診断を行い問題に対処することができる。また、アバターは、医学関係者（医学関係の装置）からユーザに対する情報を受信することができる。例えば、ユーザが血圧計とつながっているとき、アバターはユーザの現在の血圧のデータを測定のときに格納することができる。(アバターは、理論的に装用型デバイスから情報を受け取ることが可能で、非常設備からデータを受け取ることだけに限られない。例えば、もしユーザが心拍数モニターを身につけているなら、アバターはユーザの心拍数に関するデータを受け取ることが可能である。)
アバターをどのように医療サービスで使用できるかに関するより詳細な例について、以下に説明する。例えば、ある人が自分の心拍数を記録する心拍数モニターを身につける。心拍数モニターが適切なソフトウェアコンポーネントを具備していれば、心拍数モニターはアバターを移入することができるアプリケーションとなり得る。管理アプリケーションとアバターの接続は、アバターが心拍数モニターに移入している間であっても維持することができる。この接続は、アバターから管理アプリケーションまでデータを送り戻すのに使用できる(この送信は連続的に行うことができ、また希望すればデータをバースト送信することもできる)。

(例えば、人の心臓が痙攣を始めるなど) 問題が生じた場合、管理アプリケーションはその人の代わりとなって行動を取ることができる。管理アプリケーションはいくつかの方法で問題を調べることができる。例えば、心拍数モニターは問題を示す特定の信号を送信することができるし、あるいは管理アプリケーションは痙攣を示す現在の心臓のパターンを認識することができる。いずれにせよ、管理アプリケーションは人の代わりとなって行動をとることができる。例えば、管理アプリケーションは、(心拍数モニターに移入されたのと同じか、または他のアバターのいずれかの)アバターを現地の緊急対応のアプリケーションに移入して、その人の場所や現在の身体的な状態を緊急プロバイダーに伝えることができる(なお、この場合、同じアバターが複数のアプリケーションに同時に移入されることになる)。管理アプリケーションは、その人の状態について緊急対応人員に知らせ続けながら、二つのアバターの間の情報伝達ルートとして機能することができる。当業者であれば、管理アプリケーションが人を代理して問題に対応する他の方法を認識するであろう。

さらに、アバターの他の使用としては証券取引がある。アバターは、(例えば、危険回避、個人的に関心のある株及び個人的に嫌いな株、投資制約などの)ユーザの好みに関するデータを格納することができ、ユーザのポートフォリオを改良する方法を見つけるために、仲買業務アプリケーションと情報交換ができる。例えば、アバターは、様々なストック売買価格の制限について情報を得ることができる。そしてアバターを、株価をモニターするアプリケーションに移入することができる。株価が売値、買値の限界に達したとき、アバターはユーザの代わりとなって、買い注文または売り注文を出すことができる。もし、アバターがユーザの仲買業務アプリケーションに移入されていないのであれば、最初に仲買業務アプリケーションにアバターを移入した上で注文を始めることができる(なお、アバターが仲買業務アプリケーションに移入される間であっても、株価を追跡し続けるためにアバターはオリジナルのアプリケーションに残しておいてもよい)。ユーザは取引を承認するかあるいは拒絶できる。

上記の説明から分るとおり、アバターは現実に人が他人と行うことのできる取引と並列な態様で、アプリケーションと情報交換することができる。上に特定のアプリケーションについて検討したが、アバターの使用は開示されたアプリケーションにだけに限られない。当業者であれば、上で説明したのと同様の方法で移入可能なアバターを使用するために、どのように他のアプリケーションが変更され得るかを理解するであろう。

以下に、本発明の一定の態様を実施する適切なマシンの簡単な一般的な説明をする。通常、マシンは、例えばプロセッサ、メモリ（例えば、ランダムアクセスメモリー(RAM)やリードオンリーメモリ(ROM)や他の状態保存媒体）、記憶装置、映像インターフェース及び出力／入力インターフェースポートなどが取付けられるシステムバスを含む。マシンは少なくとも一部分において、キーボード、マウスなどの従来の入力デバイスからの入力及び別のマシンから受けた指示、バーチャルリアリティ(VR)環境、生体フィードバックまたは他の入力信号との情報交換によって制御することが可能である。

本件明細書で使用されているマシン（machine）という語は、単一のマシンまたは、一緒に作動するマシンやデバイスと結合するコミュニケーションシステムを広く包含することを意図する。典型的なマシンは、自動車、列車、タクシーなどの個人的または公共の交通機関といった移動手段と同様に、パーソナルコンピュータ、ワークステーション、サーバ、ポータブルコンピュータ、携帯端末、電話、タブレットなどのコンピュータデバイスを含む。

また、マシンは、プログラマブルまたは非プログラマブル論理デバイスやアレイのような内蔵コントローラやASIC（Application Specific Integrated Circuits）や内蔵コンピュータやスマートカードなどを含んでもよい。また、マシンは、ネットワーク・インターフェース、モデムまたは他のコミュニケーションのカップリングを経由して、一つまたは複数のリモートマシンへの一つまたは複数の接続を利用してもよい。さらに、マシンは、イントラネット、インターネット、ローカル・エリア・ネットワーク、広域ネットワークなどのような物理的、及び/または、論理的なネットワークを通して相互接続され得る。当業者であれば、ネットワークコミュニケーションが、無線周波数(RF)、衛星、電子レンジ、電気電子技術学会(IEEE)、802.11、ブルートゥース、光学の、赤外線のケーブル、レーザなどを含む様々な有線及び/または無線の短距離または長距離キャリアとプロトコルを利用できることを理解するであろう。

本発明は、機能、手順、データ構造、アプリケーションプログラムなどを含む関連データを参照するか、あるいはそれらとの関連で説明することができる。これらの関連データは、マシンによりアクセスされたとき、当該マシンにタスクを実行させるか、あるいは抽象データ型か低レベルのハードウェアコンテキストを定義することになる。関連データは、例えば、RAM、ROMなどの揮発性及び/または非揮発性メモリ、またはハードドライブ、フロッピーディスク、光記憶装置、テープ、フラッシュメモリ、メモリースティック、デジタルビデオディスク、生物学的記憶装置などを含む他の記憶装置とそれらの関連記憶媒体に格納することができる。関連データは物理的及び/または論理的なネットワークを含む伝送環境で、パケット、シリアルデータ、並列データ、伝播された信号などの形で送信され、圧縮または暗号化された形式で使用できる。また、関連データは、分散環境で使用され、マシンのアクセスのために、局所的及び/または遠隔的に格納され得る。

図示された実施例に基づいて本発明の原理を記載しかつ説明したが、図示された実施例が係る原理から逸脱することなくその構成と詳細において変更することができりことを理解されたい。そして、以上の説明は特定の実施例に焦点を合わせたが、他の構成も考えることができる。特に、「一つの実施例において」という表現、または同様の表現がここで使用されるが、これらの語句は一般に参考実施例となり得ることを意味し、本発明を特定の実施例の構成に制限することは意図していない。ここに使用されるように、これらの語句は、他の実施例と結合可能な同一または異なる実施例を表してもよい。

結論として、ここに説明された実施例へ多種多様に置き換えることができることを鑑みると、この詳細な説明及び添付図面は例示のみを意図しており、発明の範囲を制限するものとして捕らえるべきではない。したがって、本発明により主張されることはすべて、クレームとその同等物の範囲及び精神を逸脱しないようなすべての変更を含むものである。

図１は、本発明の実施例に係る複数のアプリケーションにおいてアバターを具体化するために複数のアプリケーションと情報交換をする管理アプリケーションを示す。 図２は、本発明の実施例に係る図１の管理アプリケーションの詳細を示す。 図３は、本発明の実施例に係る図１のアプリケーションのうちの一方の詳細を示す。 図４は、本発明の実施例に係る図１のシステムのアプリケーションにアバターを挿入するための管理アプリケーションにおける手順を示す。 図５Ａ−５Ｃは、本発明の実施例に係る図１のシステムの管理アプリケーションから受信されたアバターを具体化するためのアプリケーションの使用手順を示す。

Claims (32)

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. 前記記憶媒体はさらなる記憶された命令を有しており、前記記憶媒体が機械により実行されたときに、
    前記管理アプリケーションが前記データを格納しない第一のデータフィールドを特定し、
    前記第一のデータフィールドのアバターのデータを前記アプリケーションのデータ格納場所に格納するようになっており、
    前記アップデートされたデータの送信が、前記第一のデータフィールドの前記データ以外の前記アップデートされたデータを前記管理アプリケーションに送信することを含む請求項３１に記載の物品。

Images