(57)【特許請求の範囲】
【請求項１】
端末へアニメーションを示すデータを送出するサーバ装置において、
アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、上記端末に応じた第２のフレームデータへ変換する変換部を備えており、
上記変換部は、上記第１のフレームデータとして入力されるキーフレームの間を、上記端末の表示可能なフレームレートに収まるように補間して、第２のフレームデータに変換することを特徴とするサーバ装置。
【請求項２】
さらに、上記変換部は、上記第１のフレームデータに含まれる図形データのうち、上記端末で表現できない図形データを、当該端末で表現できる図形データに変換または削除して、別の上記第２のフレームデータに変換することを特徴とする請求項１記載のサーバ装置。
【請求項３】
さらに、上記第２のフレームデータを、ビットマップ形式のアニメーションデータにフォーマット変換するフォーマット変換部を備えていることを特徴とする請求項１記載のサーバ装置。
【請求項４】
接続されている端末の情報を受信する端末情報受信部を備え、
上記変換部は、当該端末情報を参照して、上記第１のフレームデータを第２のフレームデータに変換することを特徴とする請求項１記載のサーバ装置。
【請求項５】
アニメーションのデータを送出する時点の状況を検出する状況検知部を備え、
上記変換部は、検出した状況を参照して、上記第１のフレームデータを第２のフレームデータに変換することを特徴とする請求項１記載のサーバ装置。
【請求項６】
端末へアニメーションを示すデータを送出するサーバ装置において、
アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、上記端末に応じた第２のフレームデータへ変換する変換部を備えており、
上記変換部は、上記第１のフレームデータとして入力されるキーフレームデータと、当該キーフレームデータ間を補間して作成したフレームデータとを、上記第２のフレームデータとして出力すると共に、上記キーフレームデータおよび補間して作成したフレームデータとの合計のフレームレートが、上記端末の表示可能なフレームレートに収まるように、補間するフレームデータの数を決定することを特徴とするサーバ装置。
【請求項７】
端末へアニメーションを示すデータを送出するサーバ装置において、
アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、上記端末に応じた第２のフレームデータへ変換する変換部を備えており、
上記変換部は、上記第１のフレームデータとして入力されるキーフレームデータの間を、上記端末の表示可能なフレームレートに収まるように補間して、上記第２のフレームデータに変換すると共に、補間する際、前のキーフレームデータと次のキーフレームデータとについて、各キーフレームに含まれる各図形データを記述する表示要素のうち、上記両キーフレームデータ間で相違している表示要素を補間することを特徴とするサーバ装置。
【請求項８】
アニメーションを表示する表示部を有する端末と、該端末へ該アニメーションを示すデータを送出するサーバ装置とを備えるアニメーション通信システムであって、
上記端末は、
上記サーバ装置と通信して、上記アニメーションを示すデータを受け取るアニメーションデータ受信部と、
上記サーバ装置へ、自らの情報を示す端末情報を送信する端末情報送信部とを備えており、
上記サーバ装置は、
上記アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、上記端末情報を参照して定められる変換規則に基づいて、第１のフレームデータとして入力されるキーフレームの間を、上記端末の表示可能なフレームレートに収まるように補間して、第２のフレームデータに変換する変換部を備えていることを特徴とするアニメーション通信システム。
【請求項９】
アニメーションを表示する表示部を有する端末と、該アニメーションを示すデータを出力する複数のサーバ装置との間に中継サーバが配されたアニメーション通信システムであって、
上記端末は、
上記各サーバ装置と通信して、上記アニメーションを示すデータを受け取るアニメーションデータ受信部と、
上記各サーバ装置へ、自らの情報を示す端末情報を送信する端末情報送信部とを備えており、
上記各サーバ装置は、
上記アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、上記端末情報を参照して予め定められる変換規則に基づいて、第１のフレームデータとして入力されるキーフレームの間を、上記端末の表示可能なフレームレートに収まるように補間して、第２のフレームデータに変換する変換部を備えており、
上記中継サーバは、
上記端末からの要求を受けた場合、上記複数のサーバ装置のうちのいずれか一つを選択して、選択されたサーバ装置と上記端末との通信を中継することを特徴とするアニメーション通信システム。
【発明の詳細な説明】
技術分野
本発明は、アニメーションを端末に伝送するアニメーション通信システムに関し、特に、例えば、携帯電話など、機能／性能の低い端末でも滑らかなアニメーション表示を可能にするアニメーション通信システムに関するものである。
背景技術
近年では、例えば、携帯電話や携帯型の情報表示端末など、携帯可能な端末が広く普及しており、これらの端末の高機能化に伴い、映像やアニメーションなどをネットワーク上で伝送することで、ユーザにとって、直感的かつ効率的な情報交換を行うことが検討されている。
例えば、特開平１０−２７５２４４号公報には、キーフレームを伝送し、キーフレーム間を補間してアニメーションを表示するシステムが開示されている。また、特開平１１−２２５１６８号公報には、動画を示すビットストリームを伝送する際、伝送データに加えて、伝送方法／伝送フォーマットに関する情報を送受信し、映像や音声の再生品質を動的に変更する方式が開示されている。
しかしながら、上記端末は、携帯する必要があるため、汎用の卓上型コンピュータなどに比べて、機能／性能が低く設定されていることが多く、特に、携帯性を重視した端末では、アニメーションの再生に十分な機能／性能を持っていないことが多い。この結果、端末の処理が増えると、ただでさえ低いフレームレートがさらに低下して、アニメーションを表示できなくなるという問題を生ずる。
また、端末は、卓上型のコンピュータに比べて、機能、性能、寸法、重量、稼動時間などが制限されるため、用途に応じて、多様な端末が存在する。したがって、低機能の端末に合わせてアニメーションデータを作成し、当該アニメーションデータを配信すると、表現力が乏しくなり、高機能の端末に合わせてアニメーションデータを作成・配信すると、表示できない端末ができてしまう。
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、アニメーションデータが１種類であっても、高機能の再生装置での品質を低下させることなく、処理速度が低い端末で滑らかにアニメーション表示可能なアニメーション通信システムを実現することにある。
発明の開示
本発明に係るサーバ装置は、上記目的を達成するために、端末へアニメーションを示すデータを送出するサーバ装置において、アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、上記端末に応じた弟２のフレームデータへ変換する変換部を備えていることを特徴としている。
上記構成によれば、サーバ装置が第１のフレームデータから第２のフレームデータに変換する。したがって、第１のフレームデータが端末用でなくても、端末は、自機器用のアニメーションデータを受け取ることができる。この結果、第１のフレームデータを端末が直接受け取る場合に比べて、端末の負担を軽減でき、アニメーションデータ再生時のフレームレートを向上できる。また、第１および第２フレームデータがフレームデータなので、サーバ装置は、予め各端末用のアニメーションデータを作成し、保管しておかなくても、リアルタイムにアニメーションデータを作成できる。したがって、サーバ装置に必要な記憶容量を余り増大させずに、端末でより滑らかにアニメーション表示可能なシステムを実現できる。
また、上記構成のサーバ装置において、上記変換部は、上記第１のフレームデータに含まれる図形データのうち、上記端末で表現できない図形データを、当該端末で表現できる図形データに変換または削除して、上記第２のフレームデータに変換してもよい。
当該構成では、サーバ装置が端末で表現できない図形データを変換または削除して第２のフレームデータに変換するので、端末は、自らが表現可能な図形データのみを示すアニメーションデータを受け取ることができる。この結果、端末では、自機器で表現できない図形データを識別して削除／変換する処理が不要になる。したがって、第１のフレームデータが特定の端末用に製作されていない場合であっても、端末の負担を軽減でき、滑らかなアニメーション表示が可能になる。
これとは別に、上記構成のサーバ装置において、上記変換部は、上記第１のフレームデータとして入力されるキーフレームの間を、上記端末に応じたフレームレートで補間して、上記第２のフレームデータに変換してもよい。
当該構成では、サーバ装置が端末の性能などに応じてフレーム補間するので、端末でのフレーム補間が不要になる。この結果、端末の負担を軽減でき、滑らかなアニメーション表示が可能になる。したがって、第１のフレームデータが特定の端末用に製作されていない場合であっても、端末の負担を軽減でき、滑らかなアニメーション表示が可能になる。
また、上記各構成のサーバ装置は、さらに、上記第２のフレームデータを、ビットマップ形式のアニメーションデータにフォーマット変換するフォーマット変換部を備えていてもよい。
当該構成では、サーバ装置のフォーマット変換部が第２のフレームデータをビットマップ形式のアニメーションデータに変換する。したがって、フレームデータを再生できない端末であっても、ビットマップ形式のアニメーションを再生できれば、何ら支障なく、第１のフレームデータに応じたアニメーションを再生できる。また、第２のフレームデータは、例えば、フレームレートや図形データなどが、既に、端末に応じて変換されているので、ビットマップ形式のアニメーションデータも、端末に応じたデータとなる。したがって、第１のフレームデータが特定の端末用に製作されていない場合であっても、端末の負担を軽減でき、滑らかなアニメーション表示が可能になる。
さらに、上記各構成のサーバ装置は、接続されている端末の情報を受信する端末情報受信部を備え、上記変換部は、当該端末情報を参照して、上記第１のフレームデータを第２のフレームデータに変換する方が好ましい。
当該構成では、変換部は、端末情報に応じて第２のフレームデータに変換する。したがって、複数種類の端末が接続される場合であっても、サーバ装置は、各端末に応じたアニメーションデータを出力でき、それぞれの端末で、滑らかなアニメーション表示が可能になる。
また、上記各構成のサーバ装置は、アニメーションのデータを送出する時点の状況を検出する状況検知部を備え、上記変換部は、検出した状況を参照して、上記第１のフレームデータを第２のフレームデータに変換する方が望ましい。
当該構成によれば、状況検知部は、例えば、端末の周囲の明るさや回線の混雑状況などを検知し、変換部の変換方法を変更する。したがって、例えは、周囲が暗いときには、コントラストが高い第２のフレームデータを生成したり、回線が混雑しているときは、データ量の少ない第２のフレームデータを生成したりできる。このように、サーバ装置は、端末に応じた第２のフレームデータを、状況に応じて調整できるので、端末は、ユーザが見やすく、効果的なアニメーションを再生できる。
さらに、上記各構成のサーバ装置では、上記状況検知部は、上記端末周囲の明るさを推定し、上記変換部は、明るさが暗いと推定されるとき、明るい場合よりも、コントラストを強調した第２のフレームデータに変換してもよい。
当該構成では、例えば、時刻や季節あるいは天候などによって、端末周囲の明るさが暗いと推定される場合、第２のフレームデータを、より高コントラストに調整する。この結果、端末は、ユーザが見やすく、効果的なアニメーションを再生できる。
一方、本発明に係る端末は、上記目的を達成するために、アニメーションを表示する表示部を有する端末において、アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、端末を示す端末情報を参照して定められる変換規則に基づいて、当該端末に応じた第２のフレームデータへ変換する変換部が設けられたサーバ装置と通信して、アニメーションを示すデータを受け取るアニメーションデータ受信部と、上記サーバ装置へ、自らの情報を示す端末情報を送信する端末情報送信部とを備えていることを特徴としている。
当該構成によれば、端末は、上述の各構成のサーバ装置へ、自機器の情報を伝えることができるので、サーバ装置が複数種類の端末へアニメーションデータを送出する場合であっても、端末は、自機器に適したアニメーションデータを受け取ることができる。この結果、より滑らかなアニメーションを表示できる。
また、本発明に係る端末は、上記目的を達成するために、アニメーションを表示する表示部を有する端末において、アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、当該端末に応じた第２のフレームデータへ変換する変換部が設けられた複数のサーバ装置の一つと通信して、アニメーションを示すデータを受け取るアニメーションデータ受信部と、上記複数のサーバ装置のうち、いずれのサーバ装置からのアニメーションデータを上記表示部へ表示させるかを制御する表示制御部とを備えていることを特徴としている。
上記構成では、表示制御部が、例えば、品質や等時間性、あるいは、既に伝送したデータ量などに基づいて、複数のサーバ装置のうち、いずれのサーバ装置から受け取ったアニメーションデータを表示するかを制御する。したがって、サーバ装置が１つの場合に比べて、端末は、より良いアニメーションデータを選択でき、より滑らかなアニメーションを表示できる。
さらに、本発明に係る中継サーバは、上記目的を達成するために、アニメーションを表示する表示部を有する端末と、アニメーションを示すデータを出力する複数のサーバ装置との間に配された中継サーバであって、上記端末からの要求を受けた場合、アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、当該端末に応じた第２のフレームデータへ変換する変換部が設けられた複数のサーバ装置のうちのいずれか一つを選択して、選択されたサーバ装置と端末との通信を中継することを特徴としている。
当該構成では、中継サーバが複数のサーバの一つを選択し、端末との通信を中継する。したがって、中継サーバは、より良いアニメーションデータを選択でき、端末は、より滑らかなアニメーションを表示できる。
また、本発明に係る変換規則管理サーバは、上記目的を達成するために、アニメーションのフレームを１つ以上の図形データで表現した第１のフレームデータから、予め定められる変換規則に基づいて、端末に応じた第２のフレームデータへ変換する変換部を有するサーバ装置へ、上記第１のフレームデータから第２のフレームデータへの変換規則を送出する変換規則送信部を備えていることを特徴としている。
上記構成によれば、変換規則管理サーバが上記各構成のサーバ装置へ変換規則を配信できる。したがって、サーバ装置の数や設置場所に拘わらず、容易に変換規則を指定でき、複数のサーバ装置を同時並列に運用しやすくなる。
なお、上記サーバ装置、端末、中継サーバおよび変換規則管理サーバは、ハードウェアで実現してもよいし、記録媒体に記録されたプログラムをコンピュータに実行させて実現してもよい。
これらのプログラムが実行されると、コンピュータは、上記サーバ装置、端末、中継サーバあるいは変換規則管理サーバとして動作する。この結果、上記各装置と同様に、端末がより滑らかにアニメーション表示可能なシステムを実現できる。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかろであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
発明を実施するための最良の形態
以下、実施例および比較例により、本発明をさらに詳細に説明するが、本発明はこれらにより何ら限定されるものではない。
〔第１の実施形態〕
本発明の一実施形態について図１ないし図４に基づいて説明すると以下の通りである。すなわち、本実施形態に係るアニメーション通信システムは、キーフレームデータとして表現されるアニメーションを、例えば、携帯電話など、処理速度が低い端末や、描画機能の乏しい端末などでも余りフレームレートを低下させずに表示可能なシステムであって、例えば、利用者が携帯可能な端末２と、図示しない基地局などを介して、端末２へアニメーションを示すデータを伝送可能なサーバ装置４とを備えている。
上記サーバ装置４には、キーフレームデータＫＦを管理するアニメーションデータ管理部４１と、端末２に応じて予め定められる規則に従って、キーフレームデータＫＦをリアルタイムに変換するアニメーションデータ変換部（変換部）４２と、変換したデータを送信するアニメーションデータ送信部（送信部）４３とが設けられており、例えば、小型携帯型情報端末や携帯電話など、特定の端末２向けのデータを送出できる。
したがって、特定表示機器としての端末２は、例えば、表示デバイスの特性などの機能、あるいは、自らの処理能力に見合ったデータを受け取ることができる。この結果、例えば、卓上型のコンピュータなど、多機能かつ高速な装置用のデータを受け取り、当該データを端末２が処理可能な範囲で再生する場合に比べて、端末２の負担を大幅に削減でき、端末２の処理能力が極めて低い場合であっても比較的滑らかなアニメーション表示を実現できる。
具体的には、本実施形態に係るアニメーションデータ管理部４１は、卓上型のコンピュータと同様の形式のアニメーションデータＡを格納している。当該アニメーションデータＡは、順序付けされたキーフレームデータＫＦを含んでおり、各キーフレームデータＫＦは、例えば、線図および色情報など、図形を示す図形データＥを１つ以上含んでいる。また、アニメーションデータＡは、さらに、キーフレーム間の補間規則として、例えば、映像変化の時間、あるいは、各キーフレームデータＫＦ間における図形データＥ同士の対応関係などを補助的に含んでいてもよい。
上記アニメーションデータＡを再生する場合、キーフレームデータＫＦが順次抽出され、必要に応じてキーフレームデータＫＦ間が補間される。さらに、補間あるいは抽出された各フレームデータＦから、当該フレーム内の図形データＣが抽出された後、図形データＥの示す図形Ｉを組み合わせて１フレームが形成され、画面上に表示される。各フレームの表示は、順次繰り返され、動きのあるアニメーションが表示される。
例えば、図２に示す画面Ｖ１は、四角形、文字列および三角形を示す図形Ｉ１１・Ｉ１２・Ｉ１３から構成されており、当該フレームを示すキーフレームデータＫＦ１には、各図形Ｉ１１〜Ｉ１３を示す図形データＥ１１〜Ｅ１３が含まれている。当該キーフレームデータＫＦは、卓上型のコンピュータなど、端末２に比べて、処理能力、および、表示画面の広さや階調数などの機能が高い機器での再生を前提としており、各図形データＥも、多様な色の指定や多様な線の太さ、スプライン命令などを含んでいる。
例えば、図２に示す例では、四角形を示す図形データＥ１１は、表示位置を示す要素（”（ＰＯＳ．．．）”）と、辺を示す要素（”（ｌｉｎｅ．．．）”）と、内部を示す要素（”（ｆｉｌｌ．．．）”）とを含んでおり、表示位置は、各頂点の座標で、辺は、色（”（ｃｏｌｏｒ．．．）”）と太さ（”（ｄｅｐｔｈ．．．）”）とで、さらに、内部は、色（”（ｃｏｌｏｒ．．．）”）によって、それぞれ指定されている。
同様に、文字列を示す図形データＥ１２は、表示位置を示す要素、方向を示す要素（”（ｄｉｒｅｃｔｉｏｎ．．．）”）、フォントを示す要素（”（ｆｏｎｔ．．．）”）、サイズを示す要素（”（ｓｉｚｅ．．．）”）および色を示す要素を含んでおり、三角形を示す図形データＥ１３は、表示位置、辺および内部の表示要素で記述される。なお、図２では、各表示要素が”ＰＯＳ”などのコマンドを含む文字列として記述されているが、各表示要素を特定できれば、当然ながら、バイナリデータであってもよい。
この結果、再生側の機器がキーフレームデータＫＦを忠実に再現すると、画面Ｖ１のように、例えば、図形データＥ１１は、内部が特定の色（図２では、斜線で図示）で、特定の線の太さ（この場合は、４ドット）を持った四角形Ｉ１１として表示される。同様に、文字列Ｉ１２も特定のフォントおよびサイズで表示される。
一方、図１に示すアニメーションデータ変換部４２は、上述のアニメーションデータＡを、予め定められる規則に従って、特定の端末２向けに変換する。本実施形態に係るアニメーションデータ変換部４２は、当該端末２で表示可能な表示要素のみが含まれるように変換しており、図２に示すキーフレームデータＫＦ１を図３に示すキーフレームデータＫＦ１ａに変換する。
当該キーフレームデータＫＦ１ａでは、モノラル２階調表示しかできない端末２に合わせて、各表示要素の色が２値化（白黒）され、元の色が黒を除く何色であったとしても、”（２５５，２５５，２５５）”に変換されている。また、アニメーションデータ変換部４２は、端末２として、辺の太さ、および、内部に塗る色を表現できない端末を想定しており、上記各図形データＥの表示要素から、辺の太さ、および、内部の色を示す情報（属性）が省略されている。同様に、文字のフォントおよびサイズを変更できない端末２に合わせて、キーフレームデータＫＦ１ａの図形データＥ１２ａでは、図形データＥ１２から、例えば、”（ｓｉｚｅ．．．）”および”（ｆｏｎｔ．．．）”など、フォントおよびサイズを示す情報が省略されている。
また、アニメーションデータ変換部４２によって変換されたアニメーションデータＡａは、アニメーションデータ送信部４３によって、端末２に向けて送信される。なお、送信の手順は、例えば、インターネットで規定されているＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコルに準拠するなど、端末２まで伝送可能な一般的な手順を使用する。
一方、端末２では、アニメーション受信部２１がアニメーションデータＡａを受け取り、アニメーション表示部（表示部）２２が当該アニメーションデータＡａのキーフレームＫＦを補間しながら再生する。この結果、図３に示すように、図４に示すフレームは、端末２において、画面Ｖ１ａに示すように、端末２が表示可能な表示要素のみで特定される図形Ｉ１１ａ〜Ｉ１３ａとして表示される。なお、図２および図３では、アニメーションデータ変換部４２による変換処理の一例として、表示要素の色の２値化と、文字のフォントやサイズ、辺の太さ、および内部の色を示す情報の省略とを挙げているが、端末２の機能や処理速度に合わせて、減色、線の太さの変更およびスプライン命令の無効化などを行ってもよい。
ここで、一般に、端末２は、寸法や重量などが持ち運びできる範囲に制限されており、用途に応じた稼動時間を確保する必要がある。したがって、これらの制限を受けないサーバ装置４に比べて、通信速度や処理速度あるいは機能などが大幅に低く設定されている。
例えば、携帯電話の場合を例にすると、機能の一例として、表示画面の解像度は、９６×９２画素であり、例えば、ＸＧＡ（ｅＸｔｅｎｄｅｄ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）規格の場合で１０２８×７６８画素など、卓上型のコンピュータの解像度に比べて大幅に低く設定されている。また、当該コンピュータの階調数が、２４ビットカラーの場合で約１６００万色程度なのに対して、端末２の階調数は、モノラル２階調程度である。また、上記コンピュータでは、ＲＡＭの記憶容量が１００Ｍバイトを超え、ハードディスクの記録容量が１０Ｇバイトを超えるものが広く普及しているが、上記端末２では、一度に記憶可能なデータの容量も２ｋバイトから６ｋバイト程度に設定されている。さらに、処理速度は、卓上型のコンピュータの１／１００〜１／１０００倍よりも低く設定される。また、端末２と図示しない基地局との間の通信速度も、消費電力などを考慮して、例えば、９６００ｂｐｓや、３２ｋｂｐｓあるいは６４ｋｂｐｓなど、卓上型のコンピュータ間の通信速度、すなわち、１０Ｍｂｐｓや１００Ｍｂｐｓなどに比べて、大幅に遅く設定される。
したがって、端末２が、図２に示すキーフレームデータＫＦからなるアニメーションデータＡを受け取り、自らで表示可能な表示要素か否かを判定して、自らで表示可能な図形Ｉのみを表示しようとすると、端末２の負担が増大して、フレーム数の向上が困難になる。
ところが、本実施形態に係るアニメーション通信システム１では、サーバ装置４によって、キーフレームデータＫＦ自体の品質が最終表示端末の属性、例えば、画面サイズや表示ドット数、カラー再生能力に応じて動的に変更される。したがって、端末２は、自らが表示可能な図形ＩのみからなるキーフレームデータＫＦを受け取ることができる。この結果、端末２は、より少ない演算量でキーフレームデータＫＦを表示できる。また、端末２が表示できない表示要素は、サーバ装置４側で削除され、送信されない。この結果、通信路を伝送されるデータ量を削減でき、端末２がデータを受信する際に必要な演算量と受信したデータの記憶に必要な容量とを削減できる。
このように、端末２の負担を低減できるので、処理能力の低い端末２であっても、よりフレーム数の多い、すなわち、より滑らかなアニメーションを表示できる。特に、携帯電話など、携帯性が重視された端末では、余剰な処理能力が少なく、卓上型のコンピュータに比べて再生可能なフレーム数が少ない。したがって、フレーム数向上の影響が目に見えやすく、特に効果が大きい。
加えて、端末２では、上述した制限によって、寸法・重量・稼動時間・機能および処理速度の全てを満足させることが難しいため、用途に合わせて、様々な機能／処理速度の端末が存在する。したがって、アニメーションデータＡの作成者が、それぞれの端末２用にアニメーションデータＡを作成しようとすると、非常に手間がかかってしまう。
ところが、本実施形態に係るアニメーション通信システム１では、サーバ装置４のアニメーションデータ変換部４２がアニメーションデータ管理部４１に格納されたアニメーションデータＡから、特定の端末２用のアニメーションデータＡを生成するので、各端末２間、並びに、卓上型のコンピュータの間でアニメーションデータＡを共用できる。
さらに、本実施形態に係るアニメーション通信システム１では、アニメーションデータＡを記述する際、現在の端末２の機能よりも高く、現在の端末２では完全に表示できない表示要素を使用し、アニメーションデータ変換部４２が当該アニメーションデータＡを端末２に合わせて変換する。したがって、将来、端末２の機能が向上した場合であっても、アニメーションデータＡを変更することなく、アニメーションデータ変換部４２を新たな端末２に応じて変更するだけで対応できる。特に、端末２の機能は、卓上型のコンピュータよりも低く、例えば、階調数や画素数など、機能の一部は、卓上型コンピュータの後を追って向上することが多い。したがって、比較的、将来の端末２に搭載可能な機能を予測しやすい。この結果、将来の端末２との間でもアニメーションデータＡを共用できる。
また、当該アニメーションデータＡがフレームを図形単位で記述するキーフレーム形式のデータなので、特定の端末２用のアニメーションデータＡをリアルタイムに生成できる。したがって、例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）−１、−２または−４形式など、フレームを画素単位で表現するため、エンコードに時間がかかり、専用のハードウェアを使用せずに、特定の端末２用のデータをリアルタイムに出力しようとすると、当該端末２用のデータを予め作成しておく必要のある場合と異なり、サーバ装置４側の記憶容量を削減できる。
ここで、小型携帯型情報端末や携帯電話などの端末機器がキーフレーム補間方式のアニメーションを表示するプログラムを内蔵せず、アニメーションＧＩＦ（Ｇｒａｐｈｉｃｓ  Ｉｎｔｅｒｃｈａｎｇｅ  Ｆｏｒｍａｔ）など、ビットマップ形式の画像ファイルを表示する機能しか持っていない場合は、図４に示す変形例のサーバ装置４ａのように、アニメーションデータ変換部４２とアニメーションデータ送信部４３との間に、ファイル変換部（フォーマット変換部）４４を設け、特定の端末２用のアニメーションデータＡを、端末２が表示可能なビットマップ形式のフォーマットに変換した後で、送信してもよい。この場合、端末２のアニメーション表示部２２は、当該フォーマットに従って画面表示する。
なお、より小型の端末２など、端末２が静止画の表示プログラムと、切り換え制御のプログラムとしか内蔵しない場合には、上記ファイル変換部４４は、特定の端末２用のアニメーションデータＡを、複数の静止画ファイルと、その切り換え命令とからなる文書フォーマットに変換し、端末２のアニメーション表示部２２は、各静止画ファイルを切り換え命令に従って切り換えて、アニメーションを表示する。
これらの結果、キーフレーム補間方式のアニメーションを表示できない場合であっても、何ら支障なく、端末２は、アニメーションデータＡを表示できる。なお、当該変形例に係るサーバ装置４ａであってもアニメーションデータＡが端末２用に変換された後、ビットマップ形式に変換されるため、端末２は、自らが表示できないデータを受け取ることがない。したがって、端末２の負担を軽減でき、より滑らかにアニメーション表示できる。
ところで、上述の説明では、アニメーションデータ変換部４２の変換方法として、例えば、図形データＣの変換や削除などによって、キーフレームデータＫＦから端末２の処理できない図形データＣを取り除く場合について説明したが、これに限るものではない。アニメーションデータ変換部４２が端末２に応じたフレームデータ、すなわち、アニメーションのフレームを１つ以上の図形データで表現したデータを出力できれば、例えば、キーフレームデータＫＦ間を補間したフレームデータＦを出力してもよい。
この場合、アニメーションデータ管理部４１は、図２に示すデータに加えて、各キーフレームデータＫＦ間における図形データＥ同士の対応関係を記憶する。さらに、例えば、映像変化の時間などを記憶してもよい。
一方、アニメーションデータ変換部４２は、キーフレームデータＫＦとキーフレームデータＫＦ間を補間して作成したフレームデータＩＦとの合計が、端末２の表示可能なフレーム数に収まるように、補間フレームデータＩＦの数を決定し、前のキーフレームデータＫＦから次のキーフレームデータＫＦへ、互いに対応する図形データＥが滑らかに変化するように、例えば、図形データＥの位置や色など、両キーフレームデータＫＦ間で相違している表示要素を補間する。
例えば、前後のキーフレームデータＫＦで、ある図形データＥの座標が（０，０）と（１０，１０）とであり、１枚のフレームデータＩＦを線形に補間する場合、フレームデータＩＦにおける当該図形データＥの座標は、（５，５）となる。なお、この例では、線形に補間すなわち等分する場合を例にして説明したが、キーフレームデータＫＦから任意の数のフレームデータＩＦを作成できれば、予め定められた関数で非線形に補間するなど、他の方法で補間してもよい。
いずれの場合であっても、アニメーションデータ変換部４２が端末２に応じたフレーム数で、キーフレームデータＫＦ間を補間し、キーフレームデータＫＦと補間したフレームデータＩＦとの双方からなるフレームデータＦを出力すると共に、アニメーションデータ送信部４３がフレームデータＦを示すアニメーションデータＡを端末２へ送信すれば、端末２での補間処理が不要になる。この結果、端末２の処理速度が極めて遅く、キーフレームデータＫＦ間を補間できない場合であっても、アニメーションデータＡを再生できる。なお、フレーム補間と、端末２が表示できない図形データＥの変換／削除との双方を行えば、さらに、端末２の負担を軽減でき、特に処理速度が遅い端末２に好適である。
〔第２の実施形態〕
ところで、上記アニメーションデータ変換部４２は、各表示要素毎に特定の端末２への変換ロジックを設定してもよいが、上述したように、様々な機能や性能の端末２が存在しており、年々、性能や機能が向上しているため、多様な端末２や急速な変化に対応しやすい構成をとることが望まれる。
本実施形態に係るサーバ装置４ｂでは、図５に示すように、図１に示すアニメーションデータ変換部４２がデータ変換部５１と変換規則管理部５２とに分けられており、データ変換部５１は、変換規則管理部５２に格納された変換規則を参照しながら、各端末２に共通の変換ロジックを用いて、アニメーションデータＡを特定の端末２に合わせて変更する。
具体的には、本実施形態に係る変換規則管理部５２は、図６に示すように、変換前のパターンと、それを変換した後のパターンとの組み合わせを列挙した表形式として、変換規則を記憶しており、データ変換部５１は、図２に示すようなキーフレームデータＫＦから変換前のパターンにあてはまる（マッチする）個所を見つけ、当該個所を変換後のパターンで置き換えることによって、図３に示すように、特定の端末２用のキーフレームデータＫＦ１ａを作成する。なお、図中、変換前のパターンの欄に記載の゛”＊”は、任意の文字列にマッチすることを示しており、変換後のパターンの欄の”＊”は、変換前のまま変換しないことを示している。
例えば、図６に示す変換表の第１行目は、四角形の位置情報に関しては、何も変換しないことを示しており、第２行目は、四角形の辺の色が何色であっても、特定の色（この場合は、”２５５，２５，２５５”が示す白色）に強制的に変換することを示している。また、第３および第４行目は、変換後のパターンが空欄になっており、四角形の線の太さおよび内部の色については、変換前にどんな記述があっても削除することを示している。
上記構成では、端末２用の変換規則を記憶する変換規則管理部５２がデータ変換部５１から分けられているので、端末２の性能や機能が向上した場合でも、変換規則管理部５２の内容を変更するだけで、データ変換部５１の変換ロジックを変更する必要がない。したがって、アニメーション通信システム１全体の拡張性を保持できる。
また、本実施形態に係るサーバ装置４ｂを、端末２の種類の数だけ同時並列して運用する場合、互いに同一のデータ変換部５１を用い、変換規則管理部５２だけを差し替えて運用することができる。したがって、例えば、各表示要素毎に特定の端末２への変換ロジックを設定する場合に比べて、アニメーション通信システム１の運用時の手間を削減できる。
〔第３の実施形態〕
さらに、本実施形態に係るサーバ装置４ｃでは、図７に示すように、図５に示す変換規則管理部５２が、共通規則管理部５２ａと、端末規則管理部５２ｂとに分けられている。
上記共通規則管理部５２ａは、例えば、将来の端末２の機能および性能の向上に備えて予約された表示要素を削除／変換する規則など、どんな端末２にも共通の規則を管理している。一方、端末規則管理部５２ｂは、上記共通の規則では変換しきれない特定の端末２に固有の規則を管理する。また、データ変換部５１は、両規則管理部５２ａ・５２ｂの変換規則に基づき、アニメーションデータＡを変換する。なお、両規則管理部５２ａ・５２ｂの変換規則が相違する場合は、端末規則管理部５２ｂの変換規則が優先される。
このように、本実施形態に係るサーバ装置４ｃでは、両規則管理部５２ａ・５２ｂを分けることによって、各端末２で共通の規則と、特定の端末２に固有の規則とを独立して管理できる。したがって、新たな端末２用のサーバ装置４ｃを作成する場合には、端末規則管理部５２ｂの変換規則のみを変更すればよく、アニメーション通信システム１の運用時の手間を、さらに削減できる。
〔第４の実施形態〕
ところで、上記第１ないし第３の実施形態では、サーバ装置４（４ａ〜４ｃ）が常時同じ変換規則でアニメーションデータＡを変換する場合について説明したが、本実施形態では、図８から図１１を参照して、状況に応じて変換規則を変更する場合について説明する。なお、以下では、一例として、第２の実施形態に適用した場合について説明する。
すなわち、本実施形態に係るサーバ装置４ｄは、図８に示すように、図５に示すサーバ装置４ｂの構成に加えて、状況検知部４５が設けられており、変換規則管理部５２としての設けた状況変換規則管理部５３は、図９に示すように、各状況毎に、変換規則管理部５２と同様の変換表Ｔ１１ａ・Ｔ１１ｂ…と、図１０に示すように、いずれの変換表Ｔ１１ａ…を選択すべきかの判断基準を示す表Ｔ１２とを記憶している。
本実施形態では、状況検知部４５が時刻や天候などに基づいて、端末２の周囲の明るさを推測し、状況変換規則管理部５３は、通常（デフォルト）用の変換表Ｔ１１ａと、コントラスト強調用の変換表Ｔ１１ｂとを切り換える。
具体的には、上記通常用の変換表Ｔ１１ａには、四角形の辺の太さ、および、内部の塗り色を削除する規則が格納されており、コントラスト強調用の変換表Ｔ１１ｂには、変換前の指定に拘わらず、四角形の辺の太さを”２”に変換する規則が格納されている。これにより、アニメーションデータ変換部４２は、変換表Ｔ１１ｂを採用した場合、変換表Ｔ１１ａの場合よりも、よりコントラストが強調されたアニメーションデータＡを出力できる。
本実施形態に係る状況検知部４５は、データ変換を瞬間の状況、具体的には、時刻や季節、天候に関する情報を検知し、上記表Ｔ１２を参照しながら、いずれの変換表Ｔ１１ａ…を選択すべきかを決定する。例えば、図１０に示す表Ｔ１２に従う場合、時刻が”１７：００〜１９：００”の範囲であれば、変換する瞬間が夕方と判定して、コントラスト優先の表Ｔ１１ｂを採用し、天候が”雨”の場合もコントラスト優先の表Ｔ１１ｂを採用する。
なお、時刻や季節に関する情報は、例えば、時計機能やカレンダーの機能を有するソフトウェアモジュールを用意すれば取得できる。また、天候に関する情報は、例えば、インターネット上の天気情報サイトなど、天気情報を応答可能なサービスへ接続するなどすれば取得できる。ここで、上記サービスが、天候を取得したい場所の入力を必要とする場合、端末２が例えば、端末２が衛星と通信して位置を取得したり、端末２が現在通信可能な無線基地局に基づいて位置を取得し、状況検知部４５が端末２の位置の天候を上記サービスに問い合わせればよい。また、状況検知部４５は、端末２がサービスに問い合わせて取得した天候を受信して、端末２の天候を取得してもよい。なお、端末２の移動範囲が限られており、その範囲内では、上記サービスへ通知する場所が変化しない場合、予め設定された場所で問い合わせればよい。さらに、端末２が気圧を検出し、検出結果に基づいて、端末２または状況検知部４５が天候を推定してもよいし、例えば、端末２にカメラが設けられている場合は、カメラの撮影結果から、状況検知部４５が、端末２の周囲の明るさを取得してもよい。
なお、上記の例では、端末２の周囲の明るさを推測して、アニメーションデータＡのコントラストを調整したが、例えば、端末２とサーバ装置４ｄとの間の通信路の混雑状況に応じて、混雑時の方がアニメーションデータＡのデータ量が少なくなるように、変換規則を調整してもよい。
いずれの場合であっても、状況検知部４５が状況を検知し、状況規則管理部５３が状況に応じた変換規則を選択するので、サーバ装置４ｄは、アニメーション再生の状況に応じたアニメーションデータＡの生成が可能になり、端末２は、ユーザが見やすく、効果的なアニメーションを再生できる。
〔第５の実施形態〕
本実施形態に係るサーバ装置４ｅでは、第３の実施形態に係る変換規則管理部５２と同様、図１１に示すように、図８に示す状況変換規則管理部５３が、どんな状況にも共通の規則を管理する共通状況規則管理部５３ａと、個々の状況に個別の変換規則を管理する個別状況規則管理部５３ｂとに分けられている。なお、両規則管理部５３ａ・５３ｂの変換規則が相違する場合は、個別状況規則管理部５３ｂの変換規則が優先される。
このように、本実施形態に係るサーバ装置４ｅでは、両規則管理部５３ａ・５３ｂを分けることによって、全状況で共通の規則と、特定の状況に個別の規則とを独立して管理できるので、アニメーション通信システム１の運用時の手間を、さらに削減できる。
〔第６の実施形態〕
ところで、上記第１ないし第５の実施形態では、端末２が予め特定されている場合を例にして説明した。これに対して、本実施形態では、図１２ないし図１４を参照して、端末２を識別することで、複数種類の端末２のそれぞれに応じたアニメーションデータＡを送出可能なサーバ装置４ｆについて説明する。なお、本構成は、第１ないし第５のいずれの実施形態にも適用できるが、以下では、第２の実施形態に適用する場合を例にして説明する。
すなわち、図１２に示すように、本実施形態に係る端末２には、端末の情報を送信する端末情報送信部２３が設けられており、本実施形態に係るサーバ装置４ｆには、図５に示すサーバ装置４ｂの構成に加えて、端末２からの情報を受け取り、アニメーションデータ変換部４２へ指示する端末情報受信部４６が設けられている。また、変換規則管理部５２は、図１３に示すように、サーバ装置４ｆが対応可能な端末２毎の変換表Ｔ１ａ・Ｔ１ｂ…と、図１４に示すように、いずれの変換表Ｔ１ａ…を変換すべきかを判定するための表Ｔ２とを記憶している。
上記端末情報受信部４６は、データ変換を要求している端末２の端末情報送信部２３からの情報を受信するものであり、例えば、インターネットを介して端末２と接続されているときには、端末２がサーバ装置４ｆにアクセスする際のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）内に、端末２の種類を特定するための端末情報を記載させたり、アクセスするボート番号で識別したり、あるいは、ＨＴＴＰのリクエストヘッダを参照したりして、端末２の情報を受信する。また、例えば、電話線による接続の場合は、例えば、発信者番号表示の機能を利用するなどして端末情報を受信する。なお、これらの端末情報は、端末２の種類を特定できれば、どのような情報であってもよいが、例えば、端末２の機種や機器ＩＤ、使用者のプロファイル、接続条件などを含んでいてもよい。
一方、例えば、図１３に示す変換表Ｔ１ａは、比較的解像度が低い端末２に対応するデフォルトの変換表であり、四角形の辺の太さについて、変換前にどのようなパターンがあっても、それを無視して削除する変換規則が格納されている。また、変換表Ｔ１ｂは、比較的高解像度な端末２に対応する変換表であり、辺の太さや内部の色を、そのまま保持して変換する変換規則が記憶されている。
また、図１４の例では、上記端末情報で端末２の機種を検知できる場合の表を示しており、機種と選択すべき変換表Ｔ１ａ…との組み合わせが格納されている。例えば、端末２が”ＪＨ−ＣＨ０２”の場合、端末情報受信部４６は、表Ｔ２を参照して、変換規則管理部５２へ、変換表Ｔ１ａを選択するように指示し、データ変換部５１は、変換表Ｔ１ａの変換規則に基づいて、アニメーションデータＡを変換する。これにより、辺の太さや内部の色が省略される。一方、端末２が”ＪＨ−ＣＨ０３”の場合は、変換表Ｔ１ｂが選択され、辺や内部の色が保持されたまま、品質の高いアニメーションを再生可能なアニメーションデータＡに変換される。
このように、サーバ装置４ｆが端末情報受信部４６を備え、データ変換を要求する端末２に応じた変換規則を選択することで、サーバ装置４ｆは、端末２の性能や機能に応じた変換規則を使用でき、端末２は、ユーザが見易く、効果的なアニメーションの再生が可能になる。
〔第７の実施形態〕
ところで、上記第１ないし第６の実施形態において、アニメーションデータ変換部４２がアニメーションデータＡを変換する際の変換ロジック／変換規則は、サーバ装置４（４ａ〜４ｆ）に予め格納されていてもよいが、変換ロジック／変換規則を通信路を介して受け取ってもよい。なお、第２および第６の実施形態では、変換表のみを受信すればよい。
例えば、第２の実施形態に適用した場合を例にして説明すると、本実施形態に係るサーバ装置４ｇは、図１５に示すように、図５に示すサーバ装置４ｂの構成に加えて、変換規則を受け取る変換規則受信部４７を備えている。当該変換規則受信部４７は、例えば、インターネットなどの通信路を介して、変換規則管理サーバ５から変換規則を受け取るものであり、変換規則管理サーバ５の変換規則送信部５ａは、変換規則を格納した変換規則管理部５ｂからサーバ装置４ｇ用の変換規則を読み出し、例えば、ＨＴＴＰプロトコルに準拠したプロトコルなど、変換規則受信部４７までデータを伝送可能なプロトコルで通信する。なお、変換規則の送信元（入手先）は、変換規則を示すデータを送出できれば、変換規則管理サーバ５に限定されないが、変換規則管理サーバを設けた方が、変換規則を集約して管理できるため、より好ましい。
当該サーバ装置４ｇでは、変換規則受信部４７が設けられているので、変換規則を作成／更新した場合、サーバ装置４ｇの数および設置場所に拘わらず、作成／更新された変換規則を送信するだけで、各サーバ装置４ｇに変換規則を設定でき、アニメーション通信システム１の保守／管理が容易になる。この結果、全く同じ変換を行うサーバ装置４ｇを多数設けることが容易になり、ネットワーク上で、同時並列に運用することが可能になる。
〔第８の実施形態〕
ところで、上記第１〜第７の実施形態では、アニメーションデータ管理部４１がサーバ装置４（４ａ〜４ｇ）に設けられている場合を例にして説明したが、アニメーションデータ管理部４１は、サーバ装置４と別体に設けられてもよい。
すなわち、図１２に示すアニメーション通信システム１ｆと同様の構成を例にして説明すると、本実施形態に係るアニメーション通信システム１ｈでは、図１６に示すように、サーバ装置４ｇが、アニメーションデータ管理部４１を有するアニメーションデータ管理サーバ６と、アニメーションデータ変換部４２・アニメーションデータ送信部４３・端末情報受信部４６を有するアニメーションデータ変換サーバ７とに分割されている。なお、アニメーションデータ変換サーバ７が特許請求の範囲に記載のサーバ装置に相当する。
また、アニメーションデータ管理サーバ６には、アニメーションデータＡをアニメーションデータ変換サーバ７へ送信するアニメーションデータ送信部４８が設けられており、アニメーションデータ変換サーバ７には、アニメーションデータ送信部４８からのアニメーションデータＡを受け取るアニメーションデータ受信部４９が設けられている。なお、両部材４８・４９間は、例えば、ＨＴＴＰ、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＮＮＴＰ（Ｎｅｔｗｏｒｋ  Ｎｅｗｓ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、Ｇｏｐｈｅｒ、ＷＡＰ（Ｗｉｒｅｌｅｓｓ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）などのプロトコルに準拠するなど、両者が通信可能なプロトコルで通信される。
本実施形態に係るアニメーション通信システム１ｈでも、上記各実施形態と同様に、アニメーションデータ変換サーバ７がアニメーションデータＡを端末２に応じた形式に変換しているので、端末２は、自らの機能や性能に応じたアニメーションデータＡを受け取ることができ、ユーザが見やすく、効果的なアニメーションを再生できる。
さらに、本実施形態では、アニメーションデータ管理サーバ６とアニメーションデータ変換サーバ７とが分離されているので、アニメーションデータ管理サーバ６におけるアニメーションコンテンツと、アニメーションデータ変換サーバ７における変換規則とを、それぞれ独立して管理できる。この結果、アニメーションコンテンツの分散管理や、コンテンツの変換機能の分散管理が可能になる。
〔第９の実施形態〕
上記各実施形態では、サーバ装置４またはアニメーションデータ管理サーバ６に格納されたアニメーションデータＡを、端末２で表示する場合を例にして説明した。これに対して、本実施形態では、図１７に示すように、アニメーション生成部２４を有する端末２同士が、アニメーションデータ変換サーバ７を介して通信する場合について説明する。なお、アニメーション生成部２４は、アニメーションデータ変換サーバ７へ自律的にアニメーションデータＡを送信してもよいし、対向（通信相手）の端末２からの要求を、アニメーションデータ変換サーバ７が仲介するなどして、アニメーションデータ変換サーバ７が端末２内のアニメーション生成部２４にデータ送信要求を出してもよい。
上記アニメーション生成部２４は、アニメーションデータ管理部４１と同様、アニメーションデータＡを管理している。なお、アニメーション生成部２４が記憶するアニメーションデータＡは、アニメーションデータ管理部４１と同一の形式であってもよいし、端末２に合わせて表示要素の種類などが簡略化された物であってもよい。また、アニメーション生成部２４は、予め記憶したアニメーションデータＡを出力してもよいし、例えば、ユーザの入力に応じて、線、多角形、楕円、文字列などの図形を組み合わせて複数の静止画を作成し、それら静止画間に順序をつけることによって、アニメーションデータＡを生成してもよい。なお、各図形には、色を設定してもよい。
本実施形態に係るアニメーション通信システム１ｉでも、端末２以外に設けられたアニメーションデータ変換サーバ７で、アニメーションデータＡを再生側の端末２に応じた形式に変換しているので、送信側あるいは受信側の端末２で変換する場合に比べて、各端末２の負担が軽くなる。この結果、互いに性能／機能が異なる複数の端末２間であっても、リアルタイムに、アニメーションによるコミュニケーションが可能になる。
〔第１０の実施形態〕
ところで、上記第８の実施形態では、アニメーションデータ変換サーバ７が単数の場合を例にして説明したが、本実施形態では、図１８に示すように、アニメーションデータ変換サーバ７が複数設けられているアニメーション通信システム１ｊについて説明する。
すなわち、本実施形態に係る端末２は、複数のアニメーションデータ変換サーバ７と接続可能であり、端末２の端末情報送信部２３は、接続されている全てのアニメーションデータ変換サーバ７へ、端末２に関する情報を送信する。また、図１６に示す構成に加えて、端末２に表示制御部２５が設けられており、アニメーションデータ受信部２１が複数のアニメーションデータ変換サーバ７から伝送されるアニメーションデータＡを受信し、いずれから受信したかを示すデータと共に表示制御部２５へ提供すると、表示制御部２５は、各アニメーションデータ変換サーバ７からのアニメーションデータＡの品質や、伝送済みのデータ量、伝送の等時間性などを考慮して、複数のアニメーションデータＡの１つを選択し、アニメーション表示部２２に表示させる。なお、選択方法は、例えば、使用者の指示に従ってもよいし、例えば、混雑する時間帯は、よりデータ量の少ない変換方法のアニメーションデータ変換サーバ７を選択するなど、時間などを参照して自動的に選択してもよい。
当該構成によれば、端末２は、複数のアニメーションデータ変換サーバ７から、複数の変換方式で変換されたアニメーションデータＡ、または、同一の変換方式であっても異なる反応速度のアニメーションデータＡを受け取り、選択して表示できる。したがって、より品質の高いアニメーション、あるいは、表示速度の速いアニメーションを選択できる。
〔第１１の実施形態〕
本実施形態に係るアニメーション通信システム１ｋは、図１９に示すように、第９の実施形態と同様、端末２間がアニメーションデータ変換サーバ７を介して通信するアニメーション通信システムであって、第１０の実施形態と同様、アニメーションデータ変換サーバ７が複数設けられている。また、各端末２には、第１０の実施形態と同様に、表示制御部２５が設けられており、複数のアニメーションデータ変換サーバ７からのアニメーションデータＡのうちの１つを選択して表示させる。
本実施形態でも、複数のアニメーションデータ変換サーバ７が設けられているため、端末２間でアニメーションデータＡを送受するシステムにおいて、第１０の実施形態と同様に、より品質の高いアニメーションや、表示速度の速いアニメーションを選択でき、端末２のユーザ同士のコミュニケーションの品質を向上できる。
〔第１２の実施形態〕
ところで、第１０および第１１の実施形態では、端末２に表示制御部２５が設けられている場合を例にして説明した。これに対して、本実施形態では、図２０に示すように、表示制御部２５と同様の選択部２５ａを有する中継サーバ８が、端末２とアニメーションデータ変換サーバ７との間に設けられている場合について説明する。
第１１の実施形態に適用した場合を例にすると、図２０に示すように、本実施形態に係るアニメーション通信システム１ｍでは、端末２と各アニメーションデータ変換サーバ７との間に、中継サーバ８が設けられており、端末２の表示制御部２５が、中継サーバ８内に選択部２５ａとして移動している。当該選択部２５ａは、端未２から、アニメーションデータＡの送信を指示する要求を受けると、表示制御部２５と同様に、複数のアニメーションデータ変換サーバ７のうち、最適なアニメーションデータ変換サーバ７を選択して、当該アニメーションデータ変換サーバ７と端末２との通信を中継する。
これにより、第１０および第１１の実施形態と同様、端末２は、アニメーションデータ変換サーバ７が単一の場合に比べて、より品質の高いアニメーション、あるいは、表示速度の速いアニメーションを表示できる。
なお、上記第１ないし第１２の実施形態において、端末２・サーバ装置４・変換規則管理５・アニメーションデータ管理サーバ６・アニメーションデータ変換サーバ７・中継サーバ８などを構成する各部材は、ＣＰＵなどの演算手段が、ＲＯＭやＲＡＭなどの記録媒体に格納されたプログラムを実行することで実現される機能ブロックであってもよいし、同様の処理を行うハードウェアで実現してもよい。また、処理の一部を行うハードウェアと、当該ハードウェアの制御や残余の処理を行うプログラムを実行する上記演算手段とを組み合わせても実現することもできる。さらに、上記演算手段は、単体であってもよいし、装置内部のバスや種々の通信路を介して接続された複数の演算手段が共同してプログラムを実行してもよい。
上記プログラムは、プログラム自体や当該プログラムを作成するためのデータなどを示すプログラムデータを記録媒体に格納し、当該記録媒体を配付したり、あるいは、上記プログラムデータを、有線または無線の通信手段で送信したりして配付され、上記演算手段で実行される。
ここで、プログラムデータを配付する際の記録媒体は、取外し可能である方が好ましいが、プログラムデータを配付した後の記録媒体は、取外し可能か否かを問わない。また、上記記録媒体は、プログラムデータが記憶されていれば、書換え（書き込み）可能か否か、揮発性か否か、記録方法および形状を問わない。記録媒体の一例として、磁気テープやカセットテープなどのテープ、あるいは、フロッピーディスクやハードディスクなどの磁気ディスク、または、ＣＤ−ＲＯＭや光磁気ディスク（ＭＯ）、ミニディスク（ＭＤ）やデジタルビテオディスク（ＤＶＤ）などのディスクが挙げられる。また、記録媒体は、ＩＣカードや光カードのようなカード、あるいは、マスクＲＯＭやＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュＲＯＭなどのような半導体メモリであってもよい。
なお、上記プログラムデータは、上記各処理の全手順を上記演算手段へ指示するコードであってもよいし、所定の手順で呼び出すことで、上記各処理の一部または全部を実行可能な基本プログラム（例えば、オペレーティングシステムやライブラリなど）が既に存在していれば、当該基本プログラムの呼び出しを上記演算手段へ指示するコードやポインタなどで、上記全手順の一部または全部を置き換えてもよい。
また、上記記録媒体にプログラムデータを格納する際の形式は、例えば、実メモリに配置した状態のように、演算手段がアクセスして実行可能な格納形式であってもよいし、実メモリに配置する前で、演算手段が常時アクセス可能なローカルな記録媒体（例えば、実メモリやハードディスクなど）にインストールした後の格納形式、あるいは、ネットワークや搬送可能な記録媒体などから上記ローカルな記録媒体にインストールする前の格納形式などであってもよい。また、プログラムデータは、コンパイル後のオブジェクトコードに限るものではなく、ソースコードや、インタプリトまたはコンパイルの途中で生成される中間コードとして格納されていてもよい。いずれの場合であっても、圧縮の解凍や、復号化、インタプリト、コンパイル、リンク、あるいは、実メモリへの配置などの処理や各処理の組み合わせによって、上記演算手段が実行可能な形式に変換可能であれば、プログラムデータを記録媒体に格納する際の形式に拘わらず、同様の効果を得ることができる。
尚、発明を実施するための最良の形態の項においてなした具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求の範囲内で、いろいろと変更して実施することができるものである。
産業上の利用の可能性
本発明に係るサーバ装置は、端末へ送る前に、第１のフレームデータから端末に応じた第２のフレームデータへ変換する。したがって、第１のフレームデータが端末用でなくても、端末は、自機器用のアニメーションデータを受け取ることができる。この結果、第１のフレームデータを端末が直接受け取る場合に比べて、端末の負担を軽減でき、アニメーションデータ再生時のフレームレートを向上できる。また、第１および第２フレームデータが、フレームを１つ以上の図形データで表現したフレームデータなので、サーバ装置は、予め各端末用のアニメーションデータを作成し、保管しておかなくても、リアルタイムにアニメーションデータを作成できる。したがって、サーバ装置に必要な記憶容量を余り増大させずに、端末でより滑らかにアニメーション表示可能なシステムを実現できる。
【図面の簡単な説明】
図１は、本発明の一実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図２は、上記アニメーション通信システムで再生されるフレームデータの一例を示すものであり、変換前のデータを示す説明図である。
図３は、上記アニメーション通信システム、で再生されるフレームデータの一例を示すものであり、変換後のデータを示す説明図である。
図４は、上記アニメーション通信システムの変形例を示すブロック図である。
図５は、本発明の他の実施形態を示すものであり、サーバ装置の要部構成を示すブロック図である。
図６は、上記サーバ装置の変換規則を示す説明図である。
図７は、本発明のさらに他の実施形態を示すものであり、サーバ装置の要部構成を示すブロック図である。
図８は、本発明のまた別の実施形態を示すものであり、サーバ装置の要部構成を示すブロック図である。
図９は、上記サーバ装置の変換規則を示す説明図である。
図１０は、上記変換規則の選択基準を示す説明図である。
図１１は、本発明の他の実施形態を示すものであり、サーバ装置の要部構成を示すブロック図である。
図１２は、本発明のさらに他の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図１３は、上記サーバ装置の変換規則を示す説明図である。
図１４は、上記変換規則の選択基準を示す説明図である。
図１５は、本発明のまた別の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図１６は、本発明の他の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図１７は、本発明のさらに他の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図１８は、本発明のまた別の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図１９は、本発明の他の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
図２０は、本発明のさらに他の実施形態を示すものであり、アニメーション通信システムの要部構成を示すブロック図である。
【図１】
0004212810.tif 000002
【図２】
0004212810.tif 000003
【図３】
0004212810.tif 000004
【図４】
0004212810.tif 000005
【図５】
0004212810.tif 000006
【図６】
0004212810.tif 000007
【図７】
0004212810.tif 000008
【図８】
0004212810.tif 000009
【図９】
0004212810.tif 000010
【図１０】
0004212810.tif 000011
【図１１】
0004212810.tif 000012
【図１２】
0004212810.tif 000013
【図１３】
0004212810.tif 000014
【図１４】
0004212810.tif 000015
【図１５】
0004212810.tif 000016
【図１６】
0004212810.tif 000017
【図１７】
0004212810.tif 000018
【図１８】
0004212810.tif 000019
【図１９】
0004212810.tif 000020
【図２０】
0004212810.tif 000021