JP5040030B2 - サーバサイドアバタープリレンダリングのシステム及び方法 - Google Patents

Description

本発明は、全般的にはデジタルデータ処理に関する。本発明は、特には、画像及び動画を視覚的に表示するためのデータ変換システムに関する。

カスタマイズ可能なアバターは、ゲームや娯楽などでユーザを表す象徴として表示されるもので、ユーザの間ではよく知られた、魅力的な機能となっている。ユーザは、しばしば、自分のアバターをカスタマイズしたり、一緒に過ごすことに何時間も費やしたりするため、アバターが個人を表現する手段の延長となっていることも珍しくは無い。このため、自分のアバターを出来るだけ色々な所で表示し、他の人との交流の中で共有したいと思っているユーザも多いだろう。携帯型コンピュータデバイスの激増や、電子商取引の成長に伴い、愛用するアバターとより良質な時間を過ごしたいというユーザのニーズを満たすため、様々なサービスや商品が開発され得るようになった。

しかしながら、これらのカスタマイズ可能なアバターは、しばしば、複雑なアバターシステムによりレンダリングされるため、特にレガシーアプリケーションシステムや、コンピューティング資源が限られている低電力のシンクライアントデバイスなどに代表されるような特定の環境においてはサポートが困難または不可能である。三次元マルチレイヤのアバターは、最新のパーソナルコンピュータでは容易にサポートされ得るが、携帯電話やウェブベースのアプリケーションなどのそれほどパワフルでない機器設定の場合、レンダリングの環境が十分にパワフルなでない場合がある。十分に機能的な環境においてさえも、アバターの代替データ表示は、生のレンダリングデータよりも好ましい場合もある。特定の要件を満たすために、カスタムメイドのマルチプラットフォームレンダリングコードを提供することは、解決方法の一つかもしれないが、ハードウェア設計及びオペレーティングシステムは常に変化し続けるため、開発計画が費用の嵩むものとなり兼ねない。さらに、多くのアバターシステムがそうであるように、アバターシステムが時間とともに変化したり進化したりする場合、これらの変化を実装するためのコードメンテナンスは厄介な問題となる。

したがって、過度の開発コスト及びメンテナンスが必要とされない、複数の環境において望まれる態様でアバターをレンダリングする方法を提供することによって、従来技術の欠点及び欠如を克服する必要がある。

図面の少なくとも一つに示され、および／または、それらの図との関係において説明され、請求の範囲においてより詳しく記載される、サーバサイドでのアバタープリレンダリングのためのシステム及び方法が提供される。

本発明の特徴及び効果は、下記の詳細な説明及び添付の図面を参照することで、より、当業者に明らかとなるだろう。

本発明の一実施形態に従う、プリレンダリングされたアバターを提供するサーバを含むネットワークのブロック図である。 本発明の一実施形態に従う、レンダデータの表示形式が変換される過程を示したフローチャートである。 図３aは、本発明の一実施形態に従う、プリレンダリングされたアバターを特定のクライアントに提供するサーバを含むネットワークの例を示すブロック図である。図３ｂは、本発明の一実施形態に従う、プリレンダリングされたアバターを特定のクライアントに提供するサーバを含むネットワークの例を示すブロック図である。 本発明の一実施形態に従う、メモリを有するサーバがプリレンダリングされたアバター提供するステップを説明するフローチャートである。

本出願はサーバサイドでのアバタープリレンダリングのためのシステム及び方法に関する。以下の説明には、本発明の実施に関連する特定の情報が含まれる。当業者は、本明細書に特に述べられるものとは異なる態様にて、本発明を実施可能であることを理解するだろう。さらに、本発明を不明瞭なものとすることを避けるために、本発明のいくつかの具体的な詳細については述べられない。本出願に記載されていない具体的な詳細は、当業者についての知識の範囲内である。本出願に添付の図面、及び、これら図面に関連した詳細な説明は、本発明の例示的実施形態を対象としたものにすぎない。簡潔さを維持するために、本発明の原理を利用する本発明の他の実施形態は、本明細書には特に記載されず、また、図面にも特に示されない。

図１が示すのは、本発明の一実施形態に従う、プリレンダリングされたアバターを提供するサーバを含むネットワークのブロック図である。アバターは、コンピュータユーザ自身の象徴またはその分身を含むもので、その態様は、コンピュータゲームにて用いられる三次元モデルや、二次元画像、文章構成、または動画セグメントなど様々である。ネットワーク１００には、シンクライアント１１０、ファットクライアント１１１、アバターレンダリングアプリケーション１１２、商取引アプリケーションクライアント１１４、商取引アプリケーションサーバ１１５、受注処理１１６、アバター画像サーバ１２０、アバタープリレンダリングアプリケーション１２５、及びアバターデータベース１３０が含まれる。ネットワーク１００は、アバター画像サーバ１２０に対して「クライアントサイド」と「サーバサイド」とに分けられる。シンクライアント１１０は、オンボードプロセッサを有するため、情報を処理することはできるが、その機能は制限されており、有する内部アプリケーションは少なく、処理活動は主にセントラルサーバに頼る。これに対し、ファットクライアント１１１は、よりパワフルなプロセッサを有し、有する内部アプリケーションも豊富で、処理活動は主にセントラルサーバに頼らずに行われる。

「クライアントサイド」では、シンクライアント１１０、ファットクライアント１１１、及び商取引アプリケーションサーバ１１５の三つのクライアントが、アバター画像サーバ１２０にアバターをリクエストしている。これらのアバターは、例えば、オンラインゲームキャラクタのベクトルベース二次元画像などを有する。代替実施形態において、三次元ポリゴンベースのキャラクタがアバターとして用いられるものとしても良い。ファットクライアント１１１は、オンラインゲームにおける、例えばＦｌａｓｈまたはＪａｖａ(登録商標）アプリケーションなどのゲームクライアントのインスタンスを実行しているパーソナルコンピュータなどを表す。ファットクライアント１１１は、アバターレンダリングアプリケーション１１２によって、動的画像をローカルにレンダリングする能力を有する。そのため、ファットクライアント１１１が、「アバターリクエスト」をアバター画像サーバ１２０に送信する際、プリレンダリングされた表示形式ではなく、アバターの実際の「レンダデータ」をリクエストする。「レンダデータ」をレンダリングアプリケーション１１２に通すことで、ユーザは、ファットクライアント１１１において、ユーザを表す動的画像のアバターを表示させた状態でオンラインゲームを遊ぶことができる。例えば、アバターレンダリングアプリケーション１１２は、ディスプレイ上のアバターを構成するベクトルを動的に配置したりすることで、ユーザの入力に応じて剣を振るなど、アバターを動かすことができる。この豊かな相互作用は、レンダリングアプリケーション１１２と連動したファットクライアント１１１のハードウェア処理性能により可能となる。

これに対し、シンクライアント１１０は、ファットクライアント１１１と同じような豊かなハードウェア処理性能は有しておらず、計算集約型タスクを達成するために、サーバサイドの処理アプローチに依存する。例えば、シンクライアント１１０は、バッテリ寿命を維持するために限られた処理パワーしか有さない携帯電話などであるとする。このため、携帯電話は、ベクトルグラフィックスのリアルタイムネイティブレンダリングをサポートするための、適切なハードウェアおよび／またはソフトウェア環境を有していない。このシナリオでは、シンクライアント１１０は、携帯電話ディスプレイの限られたスペース内での表示を最適化するために、低解像度のビットマップ表示形式のプリレンダリングされたアバターをリクエストするだろう。シンクライアント１１０は、低解像度のビットマップ表示形式を積極的にリクエストするものとしても良いし、もしくは、アバター画像サーバ１２０が、識別ハンドシェークに基づいて、自動的に低解像度のビットマップ表示形式を提供するものとしても良い。

例えば、「ローパワー携帯インターネットデバイス」と名づけられた定義されたカテゴリを、デフォルトで、低解像度のビットマップ表示形式と関連付けても良い。シンクライアント１１０がアバター画像サーバ１２０と交信する際、プラットフォームまたはオペレーティングシステムの、シンクライアント１１０は携帯電話であると示唆する識別子により、アバター画像サーバ１２０は、シンクライアント１１０を「ローパワー携帯インターネットデバイス」として分類する。これに対応して、リクエストされたアバターが低解像度のビットマップ表示形式にて、自動的に提供され得る。また、この自動的な関連付けは、クライアントサイドから所望の表示形式を積極的に特定することで、手動で無効とすることもできる。

低解像度のビットマップは携帯電話ディスプレイにとって十分であるのに対し、他のアプリケーションは、より高い解像度のビットマップ、または、他の代替の色空間を利用したビットマップを必要とするだろう。例えば、商用印刷アプリケーションでは、大きなドットが印刷物に表示されるのを避けるために、少なくとも解像度３００〜６００ドットパーインチ（ＤＰＩ）を必要とする傾向にある。さらに、ほとんどの電子ディスプレイにおいて、ｓＲＧＢ、即ち、スタンダードな赤（Ｒｅｄ）、緑（Ｇｒｅｅｎ）、青（Ｂｌｕｅ）のＲＧＢ色空間が用いられるが、インク印刷には、ＣＭＹＫ（シアンマゼンタイエローキー）色空間がより適しているだろう。

例えば、もし、商取引アプリケーションサーバ１１５が、クライアントが、アバターが印刷されたカスタマイズドＴシャツを発注できるウェブサーバであるとすれば、商取引アプリケーションクライアント１１４は、顧客が商取引アプリケーションサーバ１１５を通じてオーダをリクエストできるウェブブラウザである。次に、商取引アプリケーションサーバ１１５は、アバター画像サーバ１２０からオーダされたアバターのプリレンダリングされた高解像度ビットマップをリクエストする。アバター画像は印刷が想定されているため、商取引アプリケーションサーバ１１５は、さらに、ＣＭＹＫ色空間を所望のフォーマットとして指定することもできる。アバター画像サーバ１２０が適切な「ビットマップデータ」を返すと、このデータは受注処理１１６へと進められ、顧客に出荷するために、Ｔシャツ印刷装置によりアバターがＴシャツに印刷される。

「サーバサイド」には、アバター画像サーバ１２０、アバタープリレンダリングアプリケーション１２５、及びアバターデータベース１３０の三つの構成要素が描かれている。アバター画像サーバ１２０は、中間アブストラクション層として機能し、指定された表示形式のアバターデータをクライアントに提供する。そのために、このサーバ１２０は、アバターデータベース１３０にアクセスし、アバターのオリジナル「レンダデータ」を読み出し、アバタープリレンダリングアプリケーション１２５を使ってアバターレンダデータを指定された表示形式に変換する。アバタープリレンダリングアプリケーション１２５は、アバターレンダリングアプリケーション１１２と同じクライアントサイドのレンダリングコードを共有することで、コードを有効に再利用できるようにして、開発及びメンテナンス費用を最小限に抑える。例えば、もし、アバターレンダリングアプリケーション１１２が、オンラインゲームを実行するＦｌａｓｈやＪａｖａ（登録商標）ベースのクライアントコードであるとすれば、アバタープリレンダリングアプリケーション１２５は、画像をプリレンダリングするのに、同じＦｌａｓｈやＪａｖａ（登録商標）ベースのレンダリングコードを使える。このため、アバタープリレンダリングアプリケーション１２５は、アバターレンダリングアプリケーション１１２と同じ「動的画像」をレンダリングすることができ、特定のポーズのアバターを描写したり、または、例えばダンス動作アルゴリズムでレンダデータを処理することで、短いアニメ動画セグメントを生成したりする。こうして、プリレンダリングされたデータは、クライアントからの、アバターのオリジナルリクエストに応答するために「ビットマップデータ」に変換される。さらに、アバター画像サーバ１２０は、このビットマップデータをＰＮＧ（Ｐｏｒｔａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ）、ＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）、またはＭＮＧ（Ｍｕｌｔｉｐｌｅ−ｉｍａｇｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ）などの標準ファイル形式に整える。もしくは、クライアントおよび／または他のコンポーネントが、画像やムービーの生データの形式を適切に整える。

図１に示されるサーバサイドの構成は、一例を示すにすぎず、説明を容易にするものであるため、他にも様々な構成が実施され得る。例えば、複数の異なるオンラインゲーム及びアプリケーションをサポートするために、アバター画像サーバ１２０は、複数のアバターデータベース及び複数のアバタープリレンダリングアプリケーションにアクセスすることができ、アバターリクエストにより指定されたオンラインゲームまたはアプリケーションに基づいて、使用するデータベース及びアプリケーションを交渉する。さらに、アバターデータベース１３０及びアバタープリレンダリングアプリケーション１２５は、アバター画像サーバ１２０から独立したブロックとして描かれているが、これらは実際には、単一のサーバステーションに統合されても良く、または、コンピューティング作業負荷を分散させるためにいくつかのサーバステーションに分けられても良い。

図２は、本発明の一実施形態に従う、レンダデータの表示形式が変換される過程を示したフローチャートである。フローチャート２００には、レンダデータ２４０、動的画像２４１、及びビットマップデータ２４２が含まれる。フローチャート２００に描かれるデータ変換は、図１に示されるアバタープリレンダリングアプリーケーション１２５、またはアバターレンダリングアプリケーション１１２によって遂行可能なものとしても良い。

レンダデータ２４０は、図１中にて参照されるアバターのオリジナル「レンダデータ」を含んでもよい。図２に示されるように、レンダデータ２４０は、ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）によってＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）として表現される。ＸＭＬデータは、アバターのレンダリングの視覚的詳細を記述するもので、図２によれば、単純な幾何形状を含む。これは一実施例に過ぎず、他にも様々なデータフォーマットでアバターの視覚的描写を記述することができる。例えば、レンダデータ２４０が三次元アバターを記述する場合、レンダデータ２４０は、アバターの表面を構成するポリゴン座標のリストと、これに関連付けられた、表面の上にレンダリングされたテクスチャマップとを有する。特にデータフォーマットに関係無く、視覚画像を提供するには、レンダデータ２４０はレンダラによって解析されなければならない。

このため、レンダデータ２４０は、ＦｌａｓｈまたはＪａｖａ（登録商標）言語でプログラムされたベクトルベースのレンダリングエンジンを通して解析され、図１中で「動的画像」と称される動的画像２４１が得られる。動的画像２４１は、その名前に表現されるように、静止画像として表示されるのではなく、ポーズを取ったり、動いていたり、または、ディスプレイ上で変化したりする。証明、位置、及びポーズなどの特定のレンダパラメータを有するレンダデータ２４０を絶えず解釈することで、動的画像２４１は、プリセットされたパターンどおりにアニメ化されたり、ユーザのインプットに反応したりする。このため、例えば、図１中のアバターレンダリングアプリケーション１１２は、アバターをスクリーン上のプレイヤーキャラクターとして使う、リアルタイムのオンラインゲームプレイをサポートできる。

同様に、図１中のアバタープリレンダリングアプリケーション１２５は、アバターレンダリングアプリケーション１１２と同様の動的レンダリング機能を使って動的画像２４１を創れるほか、動的レンダリング機能無しに、クライアントの使用に供する、プリレンダリングされたビットマップデータ２４２を創ることもできる。これは、図１中にて、「ビットマップデータ」として言及されている。ビットマップデータ２４２は、動的画像２４１をある時点でキャプチャまたは処理することで容易に創成され得る。図２に示されるように、ビットマップデータ２４２は、ピクセルアレイを有しており、画像のビットマップ的側面を強調するために、その解像度は若干低く、動的画像２４１で使用される自由に拡大縮小可能なベクトルとは対比されるものである。既に述べたように、ビットマップデータ２４２は、プリレンダリングされたアニメ動画セグメントをサポートするために、複数の画像を有するものであっても良い。

図３ａ及び図３ｂは、本発明の一実施形態に従う、プリレンダリングされたアバターを特定のクライアントに提供するサーバを含むネットワークの例を示すブロック図である。図１では、アバタープリレンダリングシステムの一般的な例を示したので、図３ａ及び図３ｂでは、システムの理解を促進するであろう特定の具体例を示し、図１を補充する。図３ａには、シンクライアント３１０、アバター画像サーバ３２０、及びビットマップデータ３４２が示される。図３ｂには、商取引アプリケーションクライアント３１４、商取引アプリケーションサーバ３１５、受注処理３１６、シャツ印刷機３１７、マグ印刷機３１８、カスタマイズドＴシャツ３１９、アバター画像サーバ３２０、及びビットマップデータ３４２が示される。シンクライアント３１０は、図１中のシンクライアント１１０に相応する。商取引アプリケーションクライアント３１４は、図１中の商取引アプリケーションクライアント１１４に相応する。商取引アプリケーションサーバ３１５は、図１中の商取引アプリケーションサーバ１１５に相応する。受注処理３１６は、図１中の受注処理１１６に相応する。アバター画像サーバ３２０は、図１中のアバター画像サーバ１２０に相応する。ビットマップデータ３４２は、図２中のビットマップデータ２４２に相応する。

図３ａに示されるネットワーク３００は、文章チャットアプリケーションを利用しているクライアントを表すものである。シンクライアント３１０は、例えば、カスタムローパワーハードウェア及び専用オペレーティングシステムを使用する、インターネット接続可能なモバイルスマートフォンを有する。シンクライアント３１０を使用中のユーザであるスティーブは、文章チャット中に、彼がオンラインで得たアバターを、彼を表すアイコンとして使用したいかもしれない。しかし、シンクライアント３１０では、ハードウェア及びソフトウェア環境が制限されているため、リアルタイムのベクトルベースレンダラを提供するのは非現実的と思われる。その魅力的な代替案として挙げられるのが、プリレンダリングされた画像を使用することである。このため、シンクライアント３１０で実行されている文章チャットアプリケーションは、「アバターリクエスト」をアバター画像サーバ３２０に送り、アイコンとして使える、プリレンダリングされた「ビットマップデータ」を読み出すように構成されていても良い。ビットマップデータ３４２は一旦読み出されると、シンクライアント３１０のディスプレイに表示され得て、エドや他のユーザと文章チャットをしている間、スティーブは、彼のオンラインゲームのアバターによって象徴される。

図３ｂに示されるネットワーク３００は、カスタマイズド商品を印刷するための電子商取引アプリケーションを利用しているクライアントの例である。商取引アプリケーションサーバ３１５は、例えば、顧客に郵送されるカスタマイズド商品を提供することを専門としたオンラインウェブプレゼンスを表す。図３ａに示されるユーザについて話を続けると、スティーブは、商取引アプリケーションクライアント３１４である、彼のパーソナルコンピュータのウェブブラウザを使い商取引アプリケーションサーバ３１５にアクセスできる。商取引アプリケーションサーバ３１５上のウェブサービスモジュールは、アバター画像サーバ３２０と連動するので、スティーブは、彼のオンラインゲームアバターを、オーダしようとしているカスタム商品の図として使うことができる。例えば、スティーブは、彼のオンラインゲームアバターが前面に印刷された「カスタマイズドＴシャツのオーダ」を送る。すると、商取引アプリケーションサーバ３１５は、アバター画像サーバ３２０と通信し、オンラインゲームでスティーブと関連付けられているアバターのプリレンダリングされたビットマップバージョンを要求する「アバターリクエスト」を送る。これは、高解像度３００ｄｐｉ、および印刷に最も適したＣＭＹＫ色空間でレンダリングされたものである。返された「ビットマップデータ」は、受注処理３１６へと転送される。ここで、スティーブがＴシャツをリクエストしたことが確認され、ビットマップデータは、マグ印刷機３１８や他の商品に印刷するデバイスではなく、シャツ印刷機３１７へとされる。シャツ印刷機３１７において、ビットマップデータ３４２はカスタマイズドシャツ３１９に印刷され、このシャツ３１９は梱包されてスティーブ宛に発送される。

図４に示されるのは、本発明の一実施形態に従う、メモリを有するサーバがプリレンダリングされたアバターを提供するステップを説明するフローチャートである。当業者が当然に理解する特定の詳細及び特徴は、フローチャート４００からは省かれている。例えば、一つのステップには、周知のように、いくつかのサブステップが含まれ得るし、または、特別の機器または素材を使用するかもしれない。本発明の一実施形態は、フローチャート４００に示されるステップ４１０〜４５０により、十分説明される。本発明の他の実施形態は、フローチャート４００に示されるステップとは異なるステップを含むことができる。

図４に示されるフローチャート４００のステップ４１０、及び、図１に示されるネットワーク１００を参照する。フローチャート４００のステップ４１０では、シンクライアント１１０が、プリレンダリングされるべきアバターを、アバター画像サーバ１２０にリクエストする。このリクエストには、アバターの固有識別子が含まれる。ユーザであるスティーブとオンラインゲームを例にして説明を続けると、この固有識別子は、例えば、スティーブと関連付けられたオンラインゲームアカウントを固有に識別するデータベースキーを有するものとしても良い。このリクエストは、インターネットプロトコルスィートやＴＣＰ／ＩＰなどのスタンダードなプロトコルを使って、ワイヤネットワークまたはワイヤレスネットワークによって伝送される。

図４に示されるフローチャート４００のステップ４２０、及び、図１に示されるネットワーク１００を参照する。フローチャート４００のステップ４２０では、画像サーバ１２０が、ステップ４１０の固有識別子を使って、アバターデータベース１３０からアバターのレンダデータを読み出す。このため、スティーブのアバターを描写するレンダデータを読み出すには、アバターデータベース１３０において、ステップ４１０でのデータベースキーが要求される。

図４に示されるフローチャート４００のステップ４３０、及び図１に示されるネットワーク１００を参照する。フローチャート４００のステップ４３０では、アバター画像サーバ１２０が、ステップ４２０で得られたアバターレンダデータをアバタープリレンダリングアプリケーション１２５によって処理し、定義された表示形式のプリレンダリングされたアバターを作り上げる。例えば、もし、シンクライアント１１０が、ディスプレイのサイズが小さい「ローパワー携帯インターネットデバイス」として分類されたならば、表示形式は、低解像度のビットマップ画像として定義される。既に説明したように、この表示形式は、シンクライアント１１０の識別によって、自動的に選択されるものでも良いし、または、シンクライアント１１０が、直接、所望の表示形式を特定するものとしても良い。図２に描かれる変換ステップは、アバタープリレンダリングアプリケーション１２５により実行され、ビットマップデータ２４２、即ち、低解像度のビットマップ画像の表示形式のプリレンダリングされたアバターを生成するものでも良い。例えば、アバタープリレンダリングアプリケーション１２５は、Ｆｌａｓｈプレイヤのランタイム環境で実行されるＦｌａｓｈアプリケーションを有していても良い。このＦｌａｓｈアプリケーションは、オンラインゲームのアバターレンダリングアプリケーション１１２と同じＦｌａｓｈレンダリングコードを共有する。

図４に示されるフローチャート４００のステップ４４０、及び図１に示されるネットワーク１００を参照する。フローチャート４００のステップ４４０では、アバター画像サーバ１２０が、ステップ４３０で得られたプリレンダリングされたアバターをメモリに書き込む。このメモリは、アバター画像サーバ１２０にインストールされた、揮発性のダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）を有する。さらに、アバター画像サーバ１２０はステップ４３０で得られたプリレンダリングされたアバターを、より永久的な不揮発性の記憶装置に書き込み、次回にキャッシュされたデータを提供するものでもよい。例えば、もし、シンクライアント１１０が、スティーブのアバターを複数回リクエストするならば、プリレンダリングされた表示形式をローカルキャッシュデータベースに保存するだけで、処理資源を節約することができる。シンクライアント１１０または他のクライアントがスティーブのプリレンダリングされたアバターをリクエストするとき、そのプリレンダリングされたアバターは、所望の表示形式が既にローカルキャッシュデータベースにあるとすれば、ローカルキャッシュデータベースから読み込めば良い。

図４に示されるフローチャート４００のステップ４５０、及び図１に示されるネットワーク１００を参照する。フローチャート４００のステップ４５０では、アバター画像サーバは１２０が、ステップ４４０のメモリに保存されたプリレンダリングされたアバターを、シンクライアント１１０に送る。このトランザクションは、ステップ４１０と同様のプロトコル及びネットワーク資源を使って行われるものでも良い。このステップが完了すると、シンクライアント１１０のオリジナルリクエストも満たされ、処理が完了する。

本発明の各種実施形態の効果の一つに、集中型の一又は複数のサーバが、様々な所望の表示形式にプリレンダリングされたアバターを提供できることが挙げられる。また、アバターを利用しているオリジナルクライアントソフトウェアと同じレンダリングコードを効果的に再利用することで、コードメンテナンス及び開発コストを抑えることができる。また、処理機能が制限されたプラットフォーム、または、開発が困難な設計も、システムがプリレンダリング機能を備えることで、簡単にサポートされ得る。さらに、特定のフォーマットのデータを要求する、複合アプリケーションシステムやレガシーアプリケーションシステムも、コストがかかり、潜在的にリスクの高い、既存のコードベースへの修正を必要とすることなく、適応させることができる。

本発明に関する以上の説明から、本発明の範囲から逸脱することなく本発明の概念を実装するために、異なる技術が用いられ得るのは、明らかである。さらに、本発明を、特定の実施形態を参照して説明してきたが、当業者は、本発明の意図及び範囲から逸脱することなく、態様及び詳細において種々の変更を加えることが出来ることを理解するだろう。このように、説明された実施形態は、あらゆる点において例示的なものであり、限定的なものではないと考慮される。また、理解されるべきであるのは、本発明は本明細書に記載された特定の実施形態に限定されるべきものではなく、本発明の範囲から外れることなく、種々の再構成、修正、置換が可能であることが理解されるべきだろう。

１００ ネットワーク
１１０ シンクライアント
１１１ ファットクライアント
１１２ アバターレンダリングアプリケーション
１１４ 商取引アプリケーションクライアント
１１５ 商取引アプリケーションサーバ
１１６ 受注処理
１２０ アバター画像サーバ
１２５ アバタープリレンダリングアプリケーション
１３０ アバターデータベース
２００ フローチャート
２４０ レンダデータ
２４１ 動的画像
２４２ ビットマップデータ
３００ ネットワーク
３１０ シンクライアント
３１４ 商取引アプリケーションクライアント
３１５ 商取引アプリケーションサーバ
３１６ 受注処理
３１７ シャツ印刷機
３１８ マグカップ印刷機
３１９ カスタマイズドＴシャツ
３２０ アバター画像サーバ
３４２ ビットマップデータ
４００ フローチャート
４１０ ステップ
４２０ ステップ
４３０ ステップ
４４０ ステップ
４５０ ステップ

Claims (13)

1. Ｆｌａｓｈ（登録商標）アプリケーションを用いて、プリレンダリングされたアバターを提供するためのサーバであって、
   メモリと、
   クライアントから、アバターへのリクエストであって、前記アバターの固有識別子を含む該リクエストを受け取り、前記固有識別子を使ってアバターレンダデータを読み出し、前記アバターレンダデータを、Ｆｌａｓｈプレイヤランタイム環境で実行する前記Ｆｌａｓｈアプリケーションによって処理し、前記アバターのビットマップ表示形式にプリレンダリングされたＦｌａｓｈアバターデータを創成し、前記アバターデータを前記メモリに書き込み、前記リクエストに応えて、前記アバターデータを前記メモリから前記クライアントへと送るように構成されたプロセッサと、
   を有する、サーバ。
2. 請求項１記載のサーバにおいて、前記アバターレンダデータはアバターデータベースから読み出され、前記固有識別子は前記アバターデータベースのキーであるサーバ。
3. 請求項１記載のサーバにおいて、前記アバターレンダデータには、前記アバターを視覚的に記述するＸＭＬデータが含まれるサーバ。
4. 請求項１記載のサーバにおいて、前記アバターレンダデータには、複数の二次元ベクトルを記述するデータが含まれるサーバ。
5. 請求項１記載のサーバにおいて、前記アバターレンダデータには、複数の三次元ポリゴンを記述するデータが含まれるサーバ。
6. 請求項１記載のサーバにおいて、前記クライアントが前記定義された表示形式を特定するサーバ。
7. 請求項１記載のサーバにおいて、前記プリレンダリングされたＦｌａｓｈアバターデータは、さらに、次に前記プリレンダリングされたＦｌａｓｈアバターデータをリクエストされた際にキャッシュされた応答を提供するために、不揮発性記憶装置に書き込まれるものであるサーバ。
8. Ｆｌａｓｈアプリケーションを用いて、プリレンダリングされたアバターを提供するためにメモリを有するサーバによって使用される方法であって、
   クライアントからアバターへのリクエストであって、前記アバターの固有識別子を含む該リクエストを受け取るステップ、
   前記固有識別子を使ってアバターレンダデータを読み出すステップ、
   前記アバターレンダデータをＦｌａｓｈプレイヤランタイム環境で実行する前記Ｆｌａｓｈアプリケーションによって処理し、前記アバターのビットマップ表示形式にプリレンダリングされたＦｌａｓｈアバターデータを創成するステップ、
   前記アバターデータを前記メモリに書き込むステップ、および
   前記リクエストに応えて、前記アバターデータを前記メモリから前記クライアントへと送るステップ、
   を有する方法。
9. 請求項８記載の方法において、前記アバターレンダデータには、前記アバターを視覚的に記述するＸＭＬデータが含まれる方法。
10. 請求項８記載の方法において、前記アバターレンダデータには、複数の二次元ベクトルを記述するデータが含まれる方法。
11. 請求項８記載の方法において、前記アバターレンダデータには、複数の三次元ポリゴンを記述するデータが含まれる方法。
12. 請求項８記載の方法において、前記クライアントが前記定義された表示形式を特定する方法。
13. 請求項８記載の方法であって、さらに、
    前記プリレンダリングされたＦｌａｓｈアバターデータを、次に前記プリレンダリングされたＦｌａｓｈアバターデータをリクエストされた際にキャッシュされた応答を提供するために、不揮発性記憶装置に書き込むステップを有する方法。

Images