画像処理装置、画像処理システム、画像処理方法、及び記憶媒体

 

画像処理装置は、第1のフレームを取得し、第1のユーザと第2のユーザとの少なくともいずれかのための追加の画像データを取得し、第1のフレーム及び第1のユーザのための追加画像データを合成することによる第1のユーザのための第1の合成フレームと第1のフレーム及び第2のユーザのための追加画像データを合成することによる第2のユーザのための第2の合成フレームとの少なくともいずれかを生成し、第1のユーザに対して、第1の合成フレームが生成された場合には第1の合成フレームを、それ以外の場合には第1のフレームを出力し、第2のユーザに対して、第2の合成フレームが生成された場合には第2の合成フレームを、それ以外の場合には第1のフレームを出力する。

 

 

本発明は、一般に、画像処理技術に関し、具体的には、複数のユーザのそれぞれのためのパーソナライズされた動画データストリームを生成するための、装置、システム及び方法に関する。
ビデオゲーム産業は、スタンドアロン型アーケードゲームの導入から、家庭用コンピュータゲーム、専門コンソール用に作られたゲームの出現まで、目覚ましい発展が見受けられる。そして、インターネットへの一般からのアクセスの広がりは、さらなる主要な発展、即ち「クラウドゲーミング」につながった。クラウド型ゲーミングシステムでは、プレイヤはインターネットを介してビデオゲームサーバに接続するスマートフォンやタブレットのような、一般的なインターネット対応電子機器を使用することが可能である。ビデオゲームサーバは、プレイヤについてセッションを開始し、複数のプレイヤについてそのようにしてもよい。ビデオゲームサーバは、プレイヤ行動(例えば移動、選択)及びゲームについての他の属性に基づいて、プレイヤについての映像データを描画し、音声を生成する。符号化された映像及び音声は、インターネットを介してプレイヤの機器に配信され、視聴可能な画像及び音声として再生される。このようにして、世界中のあらゆる場所のプレイヤは、専用のビデオゲームコンソール、計算集約型ソフトウェアまたは専用の描画処理ハードウェアを使用せずに、ビデオゲームをプレイすることができる。
従来のクラウドコンピューティングの実装においては、異なるプレイヤに対してインターネットを介して送信される異なる画像は、異なる描画命令のセットから生成される。すなわち、画像のプレイヤごとの任意のカスタマイズは、描画命令又はそれらの描画命令がアクセスするリソースを変更することによって、描画の前に行われる。したがって、基本的に同じ画像に対して、プレイヤごとにマイナーな変更のみが要求される場合であっても、従来のアプローチは、サーバに対して不釣合いな計算の負担を加えうる。また、従来のプレイヤごとのカスタマイズは、オリジナルのビデオゲームコードへのアクセスがない場合には可能でありえなかった。したがって、上述の不十分な点のうちの1つ以上に対応する改善が要求されている。
本発明の一態様によれば、描画手段によって描画されると共に映像データストリームに含まれる第1のフレームを取得すると共に、第1のユーザと第2のユーザとの少なくともいずれかのための追加画像データとを取得する取得手段と、前記第1のフレームと前記第1のユーザのための前記追加画像データとを組み合わせることによる第1の合成フレームと、前記第1のフレームと前記第2のユーザのための前記追加画像データとを組み合わせることによる第2の合成フレームと、の少なくともいずれかを生成する合成手段と、前記第1のユーザのために、前記第1の合成フレームが生成された場合は当該第1の合成フレームを、前記第1の合成フレームが生成されていない場合は前記第1のフレームを出力し、前記第2のユーザのために、前記第2の合成フレームが生成された場合は当該第2の合成フレームを、前記第2の合成フレームが生成されていない場合は前記第1のフレームを出力する出力手段と、を有する画像処理装置が提供される。
本発明の一態様によれば、画像の系列を表す初期フレームのセットを描画する描画手段と、複数のユーザのそれぞれのためのカスタマイズ情報を受信し、前記初期フレームのセットを変形して出力フレームの複数のセットを生成するカスタマイズ手段と、を有し、出力フレームの各セットは、前記ユーザのそれぞれのための前記カスタマイズ情報に基づいて、当該ユーザのためにカスタマイズされた画像の系列を表す、画像処理装置が提供される。
さらに、本発明の特徴は、添付の図面を参照して、以下の例示的な実施形態の説明により明らかになるだろう。
本発明の非限定的な実施形態に係る、サーバシステムを含むクラウド型ビデオゲームシステムアーキテクチャのブロック図。 本発明の非限定的な実施形態に係る、ゲームプレイの間のデータネットワークを介した一連のクライアント機器とのインタラクションを示した、図1Aのクラウド型ビデオゲームシステムアーキテクチャのブロック図。 本発明の非限定的な実施形態に係る、図1のアーキテクチャの様々な物理的構成要素を示したブロック図。 図2Aの変形例を示す図。 図2A及び2Bの物理的構成要素により実現され得ると共にゲームプレイの間に動作可能でありうる、図1のアーキテクチャにおけるサーバシステムの様々なモジュールを示したブロック図。 、 、 本発明の非限定的な実施形態に係る、描画命令生成部によって実行される一連のビデオゲーム処理の実行を示したフローチャート。 、 本発明の非限定的な実施形態に係る、受信した映像及び音声の各々を処理するためのクライアント機器の動作を示したフローチャート。 本発明の第1の非限定的な実施形態に係る、描画部を示すブロック図。 図5Aの描画部による、プライマリフレームと補助フレームとからの合成フレームの生成を示す図。 本発明の第2の非限定的な実施形態に係る、描画部を示すブロック図。 図6Aの描画部による、プライマリフレームと補助フレームとからの合成フレームの生成を示す図。 本発明の第3の非限定的な実施形態に係る、描画部を示すブロック図。 本発明の第4の非限定的な実施形態に係る、描画部を示すブロック図。 本発明の第5の非限定的な実施形態に係る、描画部を示すブロック図。 描画部の様々な要素がどのように描画サーバと計算サーバとの少なくともいずれかにおいて実装されうるかを概念的に示す図。 描画部のその時点で置かれた動作環境におけるブロック図。 本発明の非限定的な実施形態に係る、クライアント機器を示す図。 説明及び図面は本発明のある実施形態の説明のためだけのものであり理解を助けるためのものであることが明確に理解されるべきである。それらは、本発明の限界を定めることが意図されたものではない。
クラウド型システムのアーキテクチャ
図1Aは、本発明の非限定的な実施形態に係るクラウド型システムのアーキテクチャを概略的に示している。本アーキテクチャは、インターネット130等のデータネットワークを介してサーバシステム100等の情報処理装置に接続された、クライアント機器120n(1≦n≦Nであり、Nはビデオゲームに参加しているユーザの数を表す。)を含みうる。N(クラウド型システムアーキテクチャにおけるクライアント機器の数)は特に限定されないことが理解されるべきである。
サーバシステム100は、クライアント機器の複数のユーザが同時に参加することが可能な仮想空間を提供する。いくつかの場合、この仮想空間は、ビデオゲームを表現してもよく、他の場合には、通信を補助し、又は通信に対するユーザ体験を改善するためのツールとして用いられる仮想的なエフェクトを提供しうる。各ユーザは、その空間内で、その空間内に位置する対応するアバターを操作し、動かすことができる。ユーザが仮想空間内でアバターを操作すると、そのユーザのクライアント機器に、その空間において設定された視点に対する画面が提供される。その視点は、予め設定された固定視点のなかから選択されてもよいし、ユーザによって選択的に変更可能であってもよいし、ユーザによるアバターでの動作(回転)の操作に従って変更されるものであってもよい。
クライアント機器120n(1≦n≦N)の構成は具体的には限定されない。いくつかの実施形態では、1つ以上のクライアント機器120n(1≦n≦N)は、パーソナルコンピュータ(PC)、ホームゲーム機(コンソール)、ポータブルゲーム機、スマートテレビ、セットトップボックス(STB)などによって具現化されうる。他の実施形態では、1つ以上のクライアント機器120n(1≦n≦N)は、携帯電話、パーソナルデジタルアシスタント(PDA)又はタブレットなどの、通信又は計算機器でありうる。
図12に、本発明の非限定的な実施形態による、クライアント機器120n(1≦n≦N)の一般的構成を示す。クライアントCPU1201は、クライアント機器120n(1≦n≦N)に備えられるブロック/モジュールの動作を制御しうる。クライアントCPU1201は、クライアント記憶媒体1202に記憶されたブロックのための動作プログラムを読み出して、クライアントRAM1203に展開し、それらを実行することにより、ブロックの動作を制御しうる。クライアント記憶媒体1202は、HDD、不揮発性ROMなどでありうる。また、動作プログラムは、専用のアプリケーション、ブラウジングアプリケーションなどでありうる。クライアントRAM1203は、プログラムの展開領域であることに加えて、ブロックのいずれかの動作における中間データ出力などのようなものを一時的に記憶する記憶領域としても使用されうる。
クライアント通信部1204は、クライアント機器120nに備えられた通信インタフェースでありうる。ある実施形態では、クライアント通信部1204は、インターネット130を介して、情報処理装置(サーバシステム100)から提供されるサービスの符号化された画面データを受信しうる。また、反対方向の通信において、クライアント通信部1204は、クライアント機器120nのユーザによってなされた動作入力に関する情報を、インターネット130を介して、情報処理装置(サーバシステム100)へ送信しうる。クライアント復号部1205は、クライアント通信部1204によって受信された、符号化された画像データを復号し、画面データを生成しうる。生成された画面データは、クライアントディスプレイ1206に出力されて表示されることにより、クライアント機器120nのユーザに提示される。なお、クライアント機器はクライアントディスプレイ1206を有している必要はなく、クライアントディスプレイ1206はクライアント機器に接続される外部表示装置であってもよい。
クライアント入力部1207は、クライアント機器120nに備えられたユーザインタフェースでありうる。クライアント入力部1207は、(タッチスクリーン、キーボード、ゲームコントローラ、ジョイスティックなどのような)入力機器を含み、ユーザによる動作入力を検出しうる。検出された動作入力に対して、集約されたデータが、クライアント通信部1204を介して、サーバシステム100へ送信されてもよく、特定の動作入力が動作内容を解析した後に実行されたことを示す情報として送信されてもよい。また、クライアント入力部1207は、カメラなどを含みうる、特定のオブジェクトの動き又はユーザによってなされた体の動きを動作入力として検出する他のセンサ(例えばKinect(商標))を含んでもよい。さらに、クライアント機器120nは、音声を出力するためのスピーカを含んでもよい。
ここで図1Aに戻り、クライアント機器120n(1≦n≦N)の各々は、各々のローカルアクセスネットワーク(不図示)を介することを含む、あらゆる好適な方式でインターネット130に接続しうる。また、サーバシステム100は、ローカルアクセスネットワーク(不図示)を介してインターネット130に接続してもよいが、サーバシステム100はローカルアクセスネットワークの媒介なく、インターネット130と直接接続してもよい。クラウドゲーミングサーバシステム100と1以上のクライアント機器120n(1≦n≦N)との間の接続は、1つ以上のチャネルを含んでいてもよい。これらのチャネルは、物理的及び/または論理的リンクによって構成されていてもよく、無線周波数、光ファイバ、光空間(free-space optical)、同軸ケーブル、及びツイストペアを含む様々な物理的媒体を伝搬してもよい。チャネルは、UDPやTCP/IPのようなプロトコルに従ってもよい。また、1つ以上のチャネルが、仮想プライベートネットワーク(VPN)でサポートされていてもよい。いくつかの実施形態では、1つ以上の接続はセッションベースでなされてもよい。
サーバシステム100は、クライアント機器120n(1≦n≦N)のユーザが、ビデオゲームを個々に(即ち、シングルプレイヤ用ビデオゲーム)または集団で(即ち、マルチプレイヤ用ビデオゲーム)プレイすることが可能としうる。また、サーバシステム100は、クライアント機器120n(1≦n≦N)のユーザが、他のユーザによってプレイされているゲームを観戦する(ゲームに観戦者として参加する)ことを可能とし得る。ビデオゲームの非限定的な例は、レジャー、教育及び/またはスポーツについてプレイされるゲームを含みうる。しかし、ビデオゲームは貨幣損益の可能性をユーザに提示する必要はない。
また、サーバシステム100は、クライアント機器120n(1≦n≦N)のユーザが、ビデオゲームのテストと、サーバシステム100の管理との少なくともいずれかを行うことを可能とし得る。
サーバシステム100は、場合によっては1つ以上のゲームサーバを含む1つ以上の計算リソースを含んでもよく、場合によってはユーザ(参加者)データベース10を含む1つ以上のデータベースを含み、又はデータベースにアクセスしてもよい。ユーザデータベース10は、識別データ、財務データ、位置データ、人口動態データ、接続データなどのような、様々なユーザ及びクライアント機器120n(1≦n≦N)についていのアカウント情報を記憶しうる。ゲームサーバは、共通のハードウェアによって具現化されてもよいし、通信リンクを介して、場合によってはインターネット130を介することを含んで、接続される異なるサーバであってもよい。同様に、データベースは、サーバシステム100内に統合されてもよいし、通信リンクを介して、場合によってはインターネット130を介して、そこに接続されてもよい。
サーバシステム100は、ゲームプレイの前などのゲーム環境外でのクライアント機器120n(1≦n≦N)とのインタラクションを処理するための管理アプリケーションを実行しうる。例えば、管理アプリケーションは、クライアント機器120n(1≦n≦N)の1つのユーザを、(「プレイヤ」「観戦者」、「管理者」又は「試験者」などの)ユーザクラスに登録し、インターネットを介してユーザの接続性を追跡し、いくつかの非限定的な機能のうち、ゲームのインスタンスの開始、参加、退出、又は終了を行うためのユーザの命令に応答するように構成されうる。この目的を達成するために、管理アプリケーションは、ユーザデータベース10にアクセスする必要がありうる。
いくつかの非限定的な可能性を挙げると、管理アプリケーションは、「プレイヤ」「観戦者」、「管理者」又は「試験者」を含みうる異なるユーザクラスのユーザと別に相互作用しうる。したがって、例えば、管理アプリケーションは、プレイヤ(すなわち、「プレイヤ」ユーザクラスにおけるユーザ)がユーザデータベース10においてアカウントを設定し、プレイするビデオゲームを選択することを可能とするように、そのプレイヤとインタフェースを取りうる。この選択に従って、管理アプリケーションは、サーバ側のビデオゲームアプリケーションを起動しうる。サーバ側のビデオゲームアプリケーションは、プレイヤがビデオゲームの仮想世界の中でキャラクタ、アバター、レーシングカー、コクピットなどを制御することを可能とする、プレイヤのためのモジュールのセットを実行するコンピュータ可読命令によって定義されうる。マルチプレイヤ用ビデオゲームの場合、仮想世界は、2人以上のプレイヤによって共有されてもよく、1人のプレイヤのゲームプレイは、他のゲームプレイに影響を与えうる。別の例では、管理アプリケーションは、観戦者(すなわち、「観戦者」ユーザクラスのユーザ)がユーザデータベース10においてアカウントを設定し、ユーザが観戦することを望みうる実行中のビデオゲームのリストからビデオゲームを選択することを可能とするように、その観戦者とインタフェースを取りうる。この選択に従って、管理アプリケーションは、その観戦者が他のユーザのゲームプレイを観戦することはできるが、ゲーム内のアクティブキャラクタを制御することはできないようにする、その観戦者のためのモジュールのセットを起動しうる。(特段の表示がない限り、用語「ユーザ」が用いられる場合は、「プレイヤ」ユーザクラスと「観戦者」ユーザクラスとの両方に等しく適用することが意図されている)。さらなる例では、管理アプリケーションは、管理者(すなわち、「管理者」ユーザクラスのユーザ)が、ゲームサーバアプリケーションの様々な特徴を変更し、更新を実行し、プレイヤ/観戦者アカウントを管理することを可能とするように、その管理者とインタフェースを取りうる。
またさらなる例では、ゲームサーバアプリケーションは、試験者(すなわち、「試験者」ユーザクラスのユーザ)が、テスト対象のビデオゲームを選択することを可能とするために、その試験者とインタフェースを取りうる。この選択に従って、ゲームサーバアプリケーションは、試験者がビデオゲームをテストすることを可能とする、試験者のためのモジュールのセットを起動しうる。
図1Bは、「プレイヤ」又は「観戦者」ユーザクラスのユーザのために、ゲームプレイの間にクライアント機器120n(1≦n≦N)とサーバシステム100との間で行われるインタラクションを示している。
いくつかの非限定的な実施形態では、サーバ側のビデオゲームアプリケーションは、クライアント機器120n(1≦n≦N)などのクライアント機器で実行するコンピュータ可読命令のセットによって定義されうる、クライアント側のビデオゲームアプリケーションと協働しうる。クライアント側のビデオゲームアプリケーションの使用は、ユーザがゲームをプレイし又は観戦し、ゲームの特徴にアクセスするための、カスタム化されたインタフェースを与えうる。他の非限定的な実施形態では、クライアント機器は、クライアント機器によって直接実行可能なクライアント側のビデオゲームアプリケーションを特徴とはしない。むしろ、クライアント機器の観点からは、インタフェースとしてウェブブラウザを用いうる。ウェブブラウザは、サーバ側のビデオゲームアプリケーションとのインタラクションを最適化するために、それ自身、それ自身のソフトウェア環境内でクライアント側のビデオゲームアプリケーションのインスタンスを作成しうる
所与のクライアント機器において(独立して、又はブラウザ内で)作動しているクライアント側のビデオゲームアプリケーションは、受け取ったユーザ入力と、検出したユーザ動作とを、インターネット130を介してクラウドゲーミングサーバシステム100へ送信されうる「クライアント機器入力」に変換しうる。
図1Bの図示されている実施形態では、クライアント機器120n(1≦n≦N)は、それぞれ、クライアント機器入力140n(1≦n≦N)を生成しうる。サーバシステム100は、様々なクライアント機器120n(1≦n≦N)から受信したクライアント機器入力140n(1≦n≦N)を処理し、その様々なクライアント機器120n(1≦n≦N)のための「メディア出力」150n(1≦n≦N)を生成しうる。メディア出力150n(1≦n≦N)は、符号化された(画面に表示されるときの画像を表す)映像データ及び(スピーカを介して再生されるときの音を表す)音声を含みうる。メディア出力150n(1≦n≦N)は、パケットの形でインターネット130を介して送信されうる。クライアント機器120n(1≦n≦N)の特定の1つに向けられたパケットは、インターネット130を介してその装置にルーティングされるような方法でアドレスされうる。クライアント機器120n(1≦n≦N)の各々は、クラウドゲーミングサーバシステム100から受信したパケット内のメディア出力をバッファして処理するための回路、画像を表示するためのディスプレイ、及び音声を出力するための振動子(例えばスピーカ)を含みうる。また、動作を誘導するための電気機械システム等の追加の出力装置が提供されてもよい。
映像データのストリームは「フレーム」に分割されうることが理解されるべきである。ここで使用される用語「フレーム」は、映像データのフレーム間及びその映像データによって表される画像間の1対1の対応関係の存在を必要としない。すなわち、映像データのフレームが、個別の表示画像を表すデータを全部含むことができる一方で、映像データのフレームは、ある画像の一部のみを表すデータを含むことができ、その画像を適切に再生して表示するために2つ以上のフレームを必要とすることも可能である。同様に、映像データのフレームは、M<Nであるときに、M個のフレームを用いてN個の画像を表し得るように、1つより多くの完全な画像を表すデータを含んでもよい。
クラウドゲーミングサーバシステム100(分散型アーキテクチャ)
図2Aは、クラウドゲーミングサーバシステム100の構成要素の、1つのとり得る非限定的な物理的構成を示している。本実施形態では、クラウドゲーミングサーバシステム100の個々のサーバが、専用の機能を実行するよう構成されうる。例えば、計算サーバ200Cは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡についての役割を担いうる一方で、描画サーバ200Rは、グラフィック(映像データ)の描画についての役割を担いうる。
クライアント機器120n(1≦n≦N)のユーザは、プレイヤまたは観戦者でありうる。いくつかのケースでは1人のプレイヤと観戦者なしであってもよく、一方で別のケースでは複数のプレイヤと1人の観戦者が存在してもよく、さらに別のケースでは1人のプレイヤと複数の観戦者があってもよく、さらなる他のケースでは複数のプレイヤと複数の観戦者が存在してもよいことが理解されるべきである。
簡単のため、以下の説明では単一の描画サーバ200Rに単一の計算サーバ200Cが接続されているものとする。しかしながら、同一の計算サーバ200Cに接続された1つより多くの描画サーバ200R、または、同一の描画サーバ200Rに接続された1つより多くの計算サーバ200Cがあってもよいことが理解されるべきである。複数の描画サーバ200Rが存在する場合、これらは、あらゆる適切な地理的領域に分散されうる。
図2Aの構成要素の非限定的な物理的構成に示されるように、計算サーバ200Cは、1つ以上の中央演算装置(CPU)220C、222C及びランダムアクセスメモリ(RAM)230Cを有しうる。CPU220C、222Cは、例えば通信バスアーキテクチャを介してRAM230Cにアクセス可能である。2つのCPU220C、222Cのみが示されているが、計算サーバ200Cのいくつかの実装例では、より多数のCPUまたは単一のCPUのみが提供されてもよいことが理解されるべきである。また、計算サーバ200Cは、ビデオゲームに参加しているクライアント機器の各々から、インターネット130を介してクライアント機器入力を受信するための受信器を有する。ここで説明される例示の実施形態では、クライアント機器120n(1≦n≦N)は、ビデオゲームに参加しているものとし、従って、受信されるクライアント機器入力には、クライアント機器入力140n(1≦n≦N)が含まれうる。非限定的な実施形態において、受信器は、ネットワークインタフェース要素(NIC)210C2でありうる。
計算サーバ200Cは、さらに、描画命令204mのセットを出力する送信器を有しうる。ここで、1≦m≦Mである。計算サーバ200Cから出力される描画命令204m(1≦m≦M)のセットは、描画サーバ200Rへ送信されうる。非限定的な実施形態において、送信器は、ネットワークインタフェース要素(NIC)210C1によって具現化されうる。ある実施形態では、計算サーバ200Cは、描画サーバ200Rに、直接、接続されうる。他の実施形態では、計算サーバ200Cは、インターネット130又は他のネットワークでありうるネットワーク260を介して、描画サーバ200Rに接続されうる。仮想プライベートネットワーク(VPN)が、ネットワーク260を介して計算サーバ200Cと描画サーバ200Rとの間に確立されてもよい。
描画サーバ200Rにおいて、計算サーバ200Cにより送信された描画命令204m(1≦m≦M)のセットは、(ネットワークインタフェース要素(NIC)210R1によって実装されうる)受信器において受信されてもよく、1つ以上のCPU220R、222Rに導かれうる。CPU220R、222Rは、グラフィック処理装置(GPU)240R、250Rに接続されうる。非限定的な例として、GPU240Rは、GPUコア242Rのセット及びビデオランダムアクセスメモリ(VRAM)246Rを含んでもよい。同様に、GPU250RはGPUコア252Rのセット及びビデオランダムアクセスメモリ(VRAM)256Rを含んでもよい。CPU220R、222Rの各々は、GPU240R、250Rの各々に接続されていてもよいし、GPU240R、250Rのサブセットに接続されていてもよい。CPU220R、222RとGPU240R、250Rとの間の通信は、例えば通信バスアーキテクチャを用いて確立されうる。2つのCPU及び2つのGPUのみが示されるが、描画サーバ200Rの実装の特定の例においては、描画サーバ200Rの特定の実装例では、2つより多くのCPU及びGPUがあってもよいし、単一のCPUまたはGPUだけがあってもよい。
CPU220R、222Rは、描画命令204m(1≦m≦M)のセットを、、グラフィック出力ストリーム206n(1≦n≦N)に変換するために、GPU240R、250Rと協働しうる。。ここで、1≦n≦Nであり、Nはビデオゲームに参加しているユーザ(又はクライアント機器)の数を表す。具体的には、クライアント機器120n(1≦n≦N)のそれぞれについての、N個のグラフィック出力ストリーム206n(1≦n≦N)がありうる。このことのさらなる詳細については後述する。描画サーバ200Rは、さらに、(ネットワークインタフェース要素(NIC)210R2によって実装されうる)送信器を有してもよく、この送信器を介してグラフィック出力ストリーム206n(1≦n≦N)がそれぞれクライアント機器120n(1≦n≦N)に送信されうる。
クラウドゲーミングサーバシステム100(ハイブリッドアーキテクチャ)
図2Bは、クラウドゲーミングサーバシステム100の構成要素の、第2のとり得る非限定的な物理的構成を示している。本実施形態では、ハイブリッドサーバ200Hが、ユーザ入力に基づくビデオゲーム内の状態変化の追跡と、グラフィック(映像データ)の描画と、の両方の役割を担いうる。
図2Bの構成要素の非限定的な物理的構成に示されるように、ハイブリッドサーバ200Hは、1つ以上の中央演算装置(CPU)220H、222H及びランダムアクセスメモリ(RAM)230Hを有しうる。CPU220H、222Hは、例えば通信バスアーキテクチャを介してRAM230Hにアクセスしうる。2つのCPU220H、222Hのみが示されているが、ハイブリッドサーバ200Hのいくつかの実装例において、より多数のCPUまたは単一のCPUのみが提供されてもよいことが理解されるべきである。またハイブリッドサーバ200Hは、ビデオゲームに参加するクライアント機器の各々からインターネット130を介して受け取られるクライアント機器入力を受信するための受信器を有しうる。ここで説明される例示の実施形態では、クライアント機器120n(1≦n≦N)は、ビデオゲームに参加しているものとし、したがって、受信されるクライアント機器入力は、クライアント機器入力140n(1≦n≦N)を含んでもよい。非限定的な実施形態において、受信器は、ネットワークインタフェース要素(NIC)210Hによって実装されうる。
また、CPU220H、222Hは、描画処理装置(GPU)240H、250Hに接続されうる。非限定的な例では、GPU240Hは、GPUコア242のセット及びビデオランダムアクセスメモリ(VRAM)246Hを含んでいてもよい。同様に、GPU250Hは、GPUコア252Hのセット及びビデオランダムアクセスメモリ(VRAM)256Hを含んでいてもよい。CPU220H、222Hの各々は、GPU240H、250Hの各々またはGPU240H、250Hのサブセットに接続されうる。CPU220H、222HとGPU240H、250Hとの通信は、例えば通信バスアーキテクチャを用いて確立されうる。2つのCPUと2つのGPUのみが示されているが、ハイブリッドサーバ200Hの特定の実装例では、2つより多くのCPUがあってもよいし、単一のCPUまたはGPUのみがあってもよい。
描画命令204m(1≦m≦M)のセットを、グラフィック出力ストリーム206n(1≦n≦N)に変換するために、CPU220H、222HはGPU240H、250Hと協働しうる。具体的には、それぞれ、参加しているクライアント機器120n(1≦n≦N)のための、N個のグラフィック出力ストリーム206n(1≦n≦N)が存在しうる。グラフィック出力ストリーム206n(1≦n≦N)は、非限定的な実施形態においてNIC210Hによって少なくとも部分的に実装されうる送信器を介して、クライアント機器120n(1≦n≦N)に送信されうる。
クラウドゲーミングサーバシステム100(機能概要)
ゲームプレイの間、サーバシステム100は、一連のモジュールから成り得る、サーバ側のビデオゲームアプリケーションを実行する。図2Cを参照すると、これらのモジュールには、描画命令生成部270、描画部280、及び、映像符号化器285が含まれうる。これらのモジュールは、上述した計算サーバ200Cと描画サーバ200R(図2A)及び/またはハイブリッドサーバ200H(図2B)の物理的構成要素によって実装されうる。例えば、図2Aの非限定的な実施形態によれば、描画命令生成部270は計算サーバ200Cにより実現されてもよく、描画部280及び映像符号化器285は描画サーバ200Rにより実現されうる。図2Bの非限定的な実施形態によれば、ハイブリッドサーバ200Hは描画命令生成部270、描画部280、及び映像符号化器285を実現しうる。
本例示の実施形態は、図を簡略化するために単一の描画命令生成部270について議論する。しかしながら、クラウドゲーミングサーバシステム100の実際の実装において、描画命令生成部270と同様の多くの描画命令生成部が平行して実行されうることが留意されるべきである。したがって、クラウドゲーミングサーバシステム100は、同一のビデオゲームの複数の独立したインスタンス化または複数の異なるビデオゲームの同時のインスタンス化をサポートしうる。また、ビデオゲームは、あらゆる種類の1人プレイヤ用ビデオゲームまたはマルチプレイヤ用ゲームであってもよいことが理解されるべきである。
描画命令生成部270は、(図2Aの)計算サーバ200Cまたは(図2Bの)ハイブリッドサーバ200Hの、所定の物理的構成要素により実現されてもよい。具体的には、描画命令生成部270は、(計算サーバ200CのCPU220C、222Cやハイブリッドサーバ200HのCPU220H、222Hのような)CPUにより実行可能なコンピュータ読み取り可能な命令として符号化されうる。本命令は、(計算サーバ200Cの)RAM230C若しくは(ハイブリッドサーバ200Hの)RAM230H、又は他の記憶領域に、描画命令生成部270により使用される定数、変数及び/または他のデータとともに、明白に(tangibly)格納されうる。いくつかの実施形態において、描画命令生成部270は、(計算サーバ200CのCPU220C、222Cやハイブリッドサーバ200HのCPU220H、222Hのような)CPUにより実行されているオペレーティングシステムがサポートしうる、バーチャルマシンの環境内で実行されてもよい。
描画部280は、(図2Aの)描画サーバ200Rまたは(図2Bの)ハイブリッドサーバ200Hの、所定の物理的構成要素により実現されてもよい。ある実施形態では、描画部280は、1つ以上のGPU(図2Aの240R、250R、図2Bの240H、250H)を擁してもよいし、CPUリソースを利用してもよいし利用しなくてもよい。
映像符号化器285は、(図2Aの)描画サーバ200Rまたは(図2Bの)ハイブリッドサーバ200Hの所定の物理的構成要素により実現されうる。本技術分野に属する当業者は、映像符号化器285を実現する種々の手法があることを容易に理解するだろう。図2Aの実施形態において、映像符号化器285は、CPU220R、222R及び/またはGPU240R、250Rにより実現されうる。図2Bの実施形態では、映像符号化器285は、CPU220H、222H及び/またはGPU240H、250Hにより実現されうる。その他の実施形態では、映像符号化器285は、分離された符号化チップ(不図示)により実現されてもよい。
動作において、描画命令生成部270は、受信したクライアント機器入力140n(1≦n≦N)に基づいて描画命令204m(1≦m≦M)のセットを生成しうる。受信されるクライアント機器入力は、その行き先となる描画命令生成部270を識別するデータ(例えばアドレス)と、その送信元であるユーザ及び/またはクライアント機器を識別するデータとの少なくともいずれかを運びうる。
描画命令は、映像データの1つのフレームまたは一連の映像データのフレーム群を生成するように、専用の描画処理装置(GPU)に指示をするために用いられうる命令を示す。図2Cを参照すると、描画命令204m(1≦m≦M)のセットは、描画部280による映像データのフレームの生成をもたらしている。これらのフレームによって表される画像は、描画命令生成部270にプログラムされた、クライアント機器入力140n(1≦n≦N)に応じた機能として変化しうる。例えば、描画命令生成部270は、所定の特定の要因に応答して、ユーザに(将来のインタラクションが異なる、より挑戦的とさせる、またはより刺激的とさせる)進行体験を提供するような方法でプログラムされてもよく、一方で、他の特定の要因への応答は、回帰や終了の体験をユーザに与えるだろう。描画命令生成部270への指示はバイナリ実行可能なファイルの形式で固定されてもよいが、クライアント機器入力140n(1≦n≦N)は、対応するクライアント機器120n(1≦n≦N)を使用するプレイヤのインタラクション動作があるまで不明である。結果として、提供される特定のクライアント機器入力に応じて、様々な種類の生じ得る結果が存在してもよい。プレイヤ/観戦者と描画命令生成部270との間のクライアント機器120n(1≦n≦N)を介したこのインタラクションは、「ゲームプレイ」や「ビデオゲームをプレイしている」等として言及されうる。
描画部280は、複数の映像データストリーム205n(1≦n≦N、ここでNはビデオゲームに参加しているユーザ/クライアント機器の数を参照する。)を生成するために複数の描画命令204m(1≦m≦M)のセットを処理しうる。したがって、一般的に、ユーザごとに(または、同等には、クライアント機器ごとに)生成された、1つの映像データストリームが存在しうる。描画が実行されている際に、3次元空間(例えば物理オブジェクト)または2次元空間(例えばテキスト)において表される1つ以上のオブジェクトについてのデータは、特定のGPU240R、250R、240H、250Hのキャッシュメモリ(不図示)に展開されうる。このデータは、GPU240R、250R、240H、250Hにより、適切なVRAM246R、256R、246H、256Hに格納されうる2次元画像に変換されうる。このようにして、VRAM246R、256R、246H、256Hは、ゲーム画面についての画素(ピクセル)値の一時的な格納領域を提供しうる。
映像符号化器285は、映像データストリーム205n(1≦n≦N)の各々に含まれる映像データを、対応する圧縮された/符号化された映像データのストリームに圧縮及び符号化しうる。グラフィック出力ストリームとして言及される、圧縮された/符号化された映像データの結果であるストリームは、クライアント機器基準で生成されうる。本例示の実施形態では、映像符号化器285は、クライアント機器120n(1≦n≦N)のそれぞれについてのグラフィック出力ストリーム206n(1≦n≦N)を生成しうる。追加のモジュールが、インターネット130を介して送信可能となるように、映像データをパケット形式にするために提供されてもよい。映像データストリーム205n(1≦n≦N)内の映像データ及び所与のグラフィック出力ストリーム内の圧縮された/符号化された映像データが、フレームに分割されうる。
描画命令の生成
以下、描画命令生成部270による描画命令の生成について、図2C、3A及び3Bを参照してより詳細に説明する。具体的には、描画命令生成部270の実行は、以下に詳細が説明されるメインゲームプロセス300Aとグラフィック制御プロセス300Bとを含むいくつかのプロセスを伴う。
メインゲームプロセス
メインゲームプロセス300Aについて、図3Aを参照して説明する。メインゲームプロセス300Aは、連続するループとして、繰り返し実行されうる。メインゲームプロセス300Aの一部として、その実行中にクライアント機器入力が受信されうる、動作310Aが提供されうる。ビデオゲームが観戦の可能性がない1人プレイヤ用ビデオゲームである場合、単一のクライアント機器(例えばクライアント機器1201)からのクライアント機器入力(例えばクライアント機器入力1401)が動作310Aの一部として受信される。ビデオゲームがマルチプレイヤ用ビデオゲームまたは観戦の可能性がある1人プレイヤ用ゲームである場合、1つ以上のクライアント機器からのクライアント機器入力が、動作310Aの一部として受信されうる。
非限定的な例示の目的で、所与のクライアント機器からの入力は、その所与のクライアント機器のユーザが、制御下にあるキャラクタに対して移動、ジャンプ、キック、旋回、揺動、引く、つかむ等をさせることを所望していることを伝送しうる。代替的あるいは追加的に、その所与のクライアント機器からの入力は、1つ以上の音声、映像またはゲームプレイ設定を変更する、ゲームをロード/セーブする、またはネットワークセッションの作成やセッションへの参加を行うために、その所与のクライアント装置のユーザによりなされたメニュー選択を伝送しうる。代替的あるいは追加的に、その所与のクライアント機器からの入力は、その所与のクライアント機器のユーザが特定のカメラ視野(例えば1人称または3人称)の選択、または仮想世界内の視野の再配置を所望していることを伝送しうる。
動作320Aで、ゲームステートは、動作310Aにおいて受信したクライアント機器入力の少なくとも一部及び他のパラメータに基づいて更新されうる。ゲームステートの更新は、次の動作を伴いうる:第1に、ゲームステートの更新は、そこからクライアント機器入力が受信されうるクライアント機器に関連付けられたユーザ(プレイヤまたは観戦者)の所定の特性(property)を更新することを伴いうる。これらの特性は、ユーザデータベース10に格納されうる。ユーザデータベース10に保持されて動作320において更新されうるユーザ特性は、例として、カメラ視野の選択(例えば1人称、3人称)、プレイモード、選択された音声または映像の設定、スキルレベル、顧客グレード(例えばゲスト、プレミアム等)を含みうる。
第2に、ゲームステートの更新は、クライアント機器入力の解釈に基づいて、仮想世界内の所定のオブジェクトの属性を更新することを伴いうる。属性が更新されるオブジェクトは、いくつかのケースでは2次元または3次元モデルにより表されてもよいし、プレイキャラクタ、非プレイキャラクタ及び他のオブジェクトを含みうる。プレイヤキャラクタである場合、更新されうる属性はオブジェクトの位置、強さ、武器/防具、経過した寿命、特殊能力、速さ/方向(速度)、アニメーション、視覚的効果、エネルギ、弾薬等を含みうる。他のオブジェクト(背景、植物、建物、乗り物、スコアボード等)である場合、更新されうる属性は、そのオブジェクトの位置、速度、アニメーション、ダメージ/体力、視覚的効果、テキスト内容等を含みうる。
クライアント機器入力とは別のパラメータは、上述した(ユーザの)特性及び(仮想世界オブジェクトの)属性に影響を与えうることが理解されるべきである。例えば、様々なタイマ(経過時間、特定のイベントからの時間、一日の仮想時刻、プレイヤ総数、ユーザの地理的位置等)が、ゲームステートの様々な態様に影響を及ぼしてもよい。
動作320Aの実行に加えてゲームステートが更新されると、メインゲームプロセス300Aは動作310Aに戻ってもよく、それに応じて、前回のメインゲームプロセスを終了してから受信した新たなクライアント機器入力が収集され、処理される。
グラフィック制御プロセス
以下、グラフィック制御プロセスとして言及される第2のプロセスについて、図3Bを参照して説明する。グラフィック制御プロセス300Bは、メインゲームプロセス300Aと分離して示されているが、メインゲームプロセス300Aの延長として実行されうる。グラフィック制御プロセス300Bは繰り返し実行されてもよく、結果として、描画命令204m(1≦m≦M)のセットが生成される。観戦の可能性がない1人プレイヤ用ビデオゲームの場合、1人のユーザのみが存在し(すなわち、N=1)、したがって、生成されるべき結果の描画命令2041のセットは1つのみ(すなわち、M=1)である。他の場合では、N(ユーザの数)は1より大きい。例えば、マルチプレイヤ用ビデオゲームの場合、複数のプレイヤについて複数の(M>1)独立した描画命令のセットが生成されることが必要であり、従って、複数のサブプロセスが、それぞれが各プレイヤのために、並行して実行されうる。一方で、観戦の可能性がある1人プレイヤ用ゲームの場合(この場合も、複数ユーザであり、従ってN>1である)、描画命令204の単一のセット2041(M=1)のみが存在しうると共に、結果の映像データストリームは、描画部280により観戦者のために複製されうる。もちろん、これらは単なる実装の例であり、限定として取られるべきものではない。
映像データストリーム205n(1≦n≦N)のうちの1つを要求する所与のユーザのためのグラフィック制御プロセス300Bの動作について検討する。動作310Bにおいて、描画命令生成部270は、その所与のユーザについて描画されるオブジェクトを決定しうる。この動作は、以下の種類のオブジェクトを識別することを含みうる。第1に、この動作は、仮想世界から所与のユーザについての「ゲーム画面描画範囲」(「シーン」としても知られる)内にある、これらのオブジェクトを識別することを含みうる。ゲーム画面描画範囲は、所与のユーザのカメラの視点から「観ることが可能」な、仮想世界の部分を含みうる。これは、仮想世界内のオブジェクトに関連するカメラの位置及び方向に依存しうる。動作310Bの非限定的な実装例において、錐台が仮想世界に適用され得、その錐台内のオブジェクトが保持またはマークされる。錐台は、所与のユーザのカメラの位置に置かれた頂点を有し、そのカメラの方向性により規定される方向を有しうる。
第2に、この動作は、仮想世界内に現れないが、それにも関わらず所与のユーザについて描画される必要がありうる追加のオブジェクトを識別することを含みうる。例えば、これらの追加のオブジェクトは、非限定的な2〜3の可能性を挙げると、テキストメッセージ、グラフィック警告及びダッシュボードインジケータを含んでもよい。
動作320Bで、描画命令生成部270は、動作310Bにおいて識別されたオブジェクトを、画像(映像データ)に描画するための命令204m(1≦m≦M)のセットを生成する。描画は、視野及び適用される照明状態に従って、1つのオブジェクトまたはオブジェクト群の3次元または2次元座標の、表示可能な画像への変換を参照してもよい。これは、例えばここに参照により組み込まれる「"Computer Graphics and Geometric Modelling: Implementation & Algorithms", Max K. Agoston, Springer-Verlag London Limited, 2005」に記載されるような、任意の数の様々なアルゴリズム及び技術を用いて達成されうる。描画命令は、限定なく、Microsoft Corporation, Redmond, WAからの「Direct3D」及びKhronos Group, Beaverton, ORによって管理されている「OpenGL」などの、3Dのアプリケーションプログラミングインタフェース(API)に適合する形式を有しうる。
動作330Bで、動作320Bにおいて生成された描画命令は、描画部280に出力されうる。これは、描画部280に送信する描画命令204m(1≦m≦M)のセットへの、生成された描画命令のパケット化を伴いうる。
グラフィック出力の生成
描画部280は、描画命令204m(1≦m≦M)のセットを解釈し、それぞれがN個の参加しているクライアント機器120n(1≦n≦N)のそれぞれのための、複数の映像データストリーム205を生成しうる。描画は、(図2Aの)CPU220R、222Rまたは(図2Bの)CPU220H、222Hの制御の下、GPU240R、250R、240H、250Hにより実現されうる。1つの参加しているクライアント機器のための映像データのフレームが生成されるレートは、フレームレートとして参照されうる。
N名のユーザが存在する実施形態において、N個の映像データストリーム205n(1≦n≦N)が、描画命令204m(1≦m≦M、ここでM=N)のセットのそれぞれから生成されうる。この場合、描画機能はユーザ間で共有されない。しかしながら、より少ない数の描画命令のセットが描画部280により処理される必要があることとなるように、M個の描画命令204m(1≦m≦M、ここでMはNより小さい)のセットからN個の映像データストリーム205n(1≦n≦N)が生成されてもよい。その場合、より少ない数の描画命令204m(1≦m≦M、ここでM<N)のセットから、より多い数の映像データストリーム205n(1≦n≦N)を生成するために、描画部280は共有または複製を行ってもよい。このような共有または複製は、複数のユーザ(例えば観戦者)が同一のカメラ画角を観ることを所望した場合に普及するものであってもよい。このように、描画部280は、生成された映像データストリームを1つ以上の観戦者に複製するなどの機能を実行してもよい。
次に、映像データストリーム205n(1≦n≦N)の各々における映像データは、映像符号化器285により符号化され、グラフィック出力ストリームとして参照され、各クライアント機器に関連付けられた一連の符号化映像データが得られる。図2A〜2Cの実施形態の例において、クライアント機器120n(1≦n≦N)のそれぞれに宛てられた一連の符号化映像データは「グラフィック出力ストリーム」206n(1≦n≦N)として参照される。
映像符号化器285は、デジタル映像についての映像圧縮または展開アルゴリズムを起動する、実行する、または定義する装置(またはコンピュータ読み取り可能な命令のセット)であり得る。映像圧縮は、(画素位置、色値等で表現される)デジタル画像データのオリジナルストリームを、より少ないビットを用いるが実質的に同一の情報を伝送するデジタル画像データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられうる。データ圧縮に加え、映像データの特定のフレームの符号化に用いられる符号化処理は、暗号法の暗号化を含んでもよいし、しなくともよい。
上述の手法で生成されたグラフィック出力ストリーム206n(1≦n≦N)は、インターネット130を介して各クライアント機器に送信されうる。非限定的な例として、グラフィック出力ストリームは、各々がヘッダ及びペイロードを有する複数のパケットに、分割され、またはフォーマットされてもよい。所与のユーザについての映像データを含むパケットのヘッダは、その所与のユーザに関連付けられたクライアント機器のネットワークアドレスを含んでもよく、ペイロードは全部または一部として映像データを含んでもよい。非限定的な実施形態において、所定の映像データを符号化するために用いられる圧縮アルゴリズムのアイデンティティ及び/またはバージョンが、その映像データを伝送する1つ以上のパケットのコンテンツ内に符号化されてもよい。符号化映像データの他の送信手法は、本技術分野に属する当業者には思い当たるだろう。
本開示は個々の2D画像を表す映像データの描画に着目するものであるが、本発明は3D効果を生成するために、フレームごとに複数の2D画像を表す映像データを描画することの可能性を除外するものではない。
クライアント機器におけるゲーム画面再生
以下、非限定的な例示の目的で、クライアント機器120n(1≦n≦N)のいずれかであり得る、所与のユーザに関連付けられたクライアント機器によって実行されうるクライアント側のビデオゲームアプリケーションの動作を示す図4Aを参照する。動作において、いくつかの非限定的な可能性を挙げると、クライアント側ビデオゲームアプリケーションは、クライアント機器によって直接実行可能であってもよいし、ウェブブラウザ内で動作してもよい。
動作410Aで、(グラフィック出力ストリーム260n(1≦n≦N)のうちの)グラフィック出力ストリームは、実施形態に応じて、描画サーバ200R(図2A)から、またはハイブリッドサーバ200H(図2B)から、インターネット130を介して受信されうる。受信されたグラフィック出力ストリームは、複数のフレームに分割されうる、映像データの圧縮/符号化されたフレームを含みうる。
動作420Aで、圧縮/符号化された映像データのフレームは、符号化/圧縮処理に用いられた符号化/圧縮アルゴリズムを補間する復号化/展開アルゴリズムに従って、復号/展開される。非限定的な実施形態において、映像データの符号化/圧縮に用いられた符号化/圧縮アルゴリズムのアイデンティティまたはバージョンは、予め知らされていてもよい。他の実施形態では、映像データの符号化に用いられた符号化/圧縮アルゴリズムのアイデンティティまたはバージョンは、その映像データそのものを伴ってもよい。
動作430Aで、(復号/展開された)映像データのフレームが処理されうる。これは、バッファへの復号/展開された映像データのフレームの配置、誤り訂正の実行、複数の連続するフレームの順序付け及び/または合成、アルファブレンディング、欠損したデータ部分の補間等を含みうる。その結果は、フレームごとにユーザに提示されるべき最終画像を表す映像データとなり得る。
動作440Aで、最終画像がクライアント機器の出力機構を介して出力されうる。例えば、コンポジット映像フレームが、クライアント機器のディスプレイに表示されうる。
音声生成
以下、音声生成処理として言及される3番目の処理について、図3Cを参照して説明する。音声生成処理は、知覚可能な音声ストリームを要求する各ユーザについて、断続的に実行しうる。一実施形態において、音声生成処理はグラフィック制御プロセス300Bと無関係に実行されうる。他の実施形態において、音声生成処理及びグラフィック制御処理の実行が協調されうる。
動作310Cで、描画命令生成部270は、生成すべき音声を決定しうる。具体的には、本動作は、音量(音の強さ)及び/または仮想世界内においてユーザへの近さに応じて、地形音響特性に影響を及ぼす仮想世界内のオブジェクトに関連付けられた音声を特定することを含みうる。
動作320Cで、描画命令生成部270は音声セグメントを生成しうる。音声セグメントの継続期間は映像フレームの継続期間に及んでもよいし、いくつかの実施形態では音声セグメントは映像フレームよりも少ない頻度で生成されてもよいし、他の実施形態では音声セグメントは映像フレームよりも高い頻度で生成されてもよい。
動作330Cで、音声セグメントは例えば音声符号化器により符号化されてもよく、その結果、符号化音声セグメントが得られる。音声符号化器は、音声圧縮または展開アルゴリズムを起動し、実行し、または定義する装置(または指示のセット)でありうる。音声圧縮は、(時間の経過によって振幅及び位相が変化する音波として表現される)デジタル音声のオリジナルストリームを、より少ないビットを使用するが実質的に同一の情報を伝送するデジタル音声データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられうる。音声圧縮に加え、特定の音声セグメントの符号化に用いられる符号化処理は暗号法の暗号化を適用してもよいし、しなくてもよい。
いくつかの実施形態において、音声セグメントは計算サーバ200C(図2A)またはハイブリッドサーバ200H(図2B)のいずれかの専用ハードウェア(例えばサウンドカード)により生成されてもよいことが理解されるべきである。図2Aの分散型構成に適用可能でありうる代替的実施形態では、音声セグメントは描画命令生成部270によりスピーチパラメータ(例えばLPCパラメータ)にパラメータ化されてもよく、スピーチパラメータは描画サーバ200Rにより、配信先のクライアント機器に再配信されうる。
上述した方式で生成された符号化された音声は、インターネット130を介して送信される。非限定的な例において、符号化された音声入力は、各々がヘッダ及びペイロードを有するパケットに分解及びフォーマットされうる。ヘッダは、ユーザのために音声生成処理が実行されているときのその参加者に関連付けられたクライアント機器のアドレスを伝送してもよく、ペイロードは符号化された音声を含んでいてもよい。非限定的な実施形態において、所与の音声セグメントの符号化に用いられる圧縮アルゴリズムのアイデンティティ及び/またはバージョンは、その所与のセグメントを伝送する1つ以上のパケットのコンテンツ内に符号化されてもよい。符号化された音声を送信する他の手法は、本技術分野に属する当業者には思い当たるだろう。
以下、非限定的な例示を目的として、クライアント機器120n(1≦n≦N)のいずれかでありうる、所与のユーザに関連付けられたクライアント機器の動作を示す図4Bを参照する。
動作410Bで、符号化された音声セグメントが(実施形態に応じて)計算サーバ200C、描画サーバ200R、またはハイブリッドサーバ200Hから受信されうる。動作420Bで、符号化処理に用いられた圧縮アルゴリズムを補間する展開アルゴリズムに従って、符号化された音声が復号されうる。非限定的な実施形態において、音声セグメントの符号化に用いられた圧縮アルゴリズムのアイデンティティまたはバージョンは、音声セグメントを伝送する1つ以上のパケットのコンテンツ内で特定されてもよい。
動作430Bで、(復号された)音声セグメントが処理されうる。これは、バッファ内への復号された音声セグメントの配置、誤り訂正の実行、複数の連続する波形の合成等を含みうる。その結果は、フレームごとにユーザに提示される最終音声となり得る。
動作440Bで、最終的に生成された音声は、クライアント機器の出力機構を介して出力されうる。例えば、音声はクライアント機器のサウンドカードまたはスピーカを介して再生される。
非限定的な実施形態の具体的開示
以下、本発明の所定の非限定的な実施形態について、より詳細な説明を提供する。
本発明の非限定的な実施形態の一般的なブロック図を示す図11を参照する。描画命令生成部270は、描画部280へ、描画命令のセット2041を供給する。ここでは、N人のユーザのそれぞれのための複数の映像データストリーム205n(1≦n≦N)をもたらす1つの描画命令のセット2041(すなわち、M=1)を検討する。この状況は、N人のユーザ(プレイヤと観戦者との少なくともいずれか)が同一のカメラの視点を共有する場合に生じうる。当然ながら、それぞれが1つ以上の別個の映像データストリームを生じさせうる1つより多くの描画命令のセットが存在する(すなわちM>1の)場合にも、同様の説明が適用されうる。
描画命令のセット2041は、描画部280内の描画器1120へ供給される。本発明のある実施形態を除いて、描画器1120は、描画命令のセット2041を処理して、単一のクライアント機器に充てられたフレームを生成しうる。その一方で、本発明の非限定的な実施形態によれば、描画器1120は、描画命令のセット2041を処理して、後にN人のユーザのそれぞれのための映像データストリーム205n(1≦n≦N)を形成するためにカスタマイズ部1110によってカスタマイズされる、一次フレーム540a、540b、…、を含む映像データストリームを生成する。
カスタマイズ部1110は、描画命令生成部270から各ユーザのためのカスタマイズ情報を受け取る。ここで、ユーザの全てに対するカスタマイズ情報を受け取らなくてもよいことに留意すべきである。すなわち、一部のユーザに対して、カスタマイズされていない一次フレームが映像データストリームとして出力されてもよい。具体的には、カスタマイズ情報は、1つ以上のユーザのそれぞれのための1つ以上のカスタマイズ情報(例えば、ユーザn(ここで1≦n≦N)に対するカスタマイズ情報1150n)を含む。カスタマイズ部1110はカスタマイズ情報を解釈し、カスタムの特徴を取得し、そのカスタムの特徴を一次フレーム540a、540b、…、に組み入れ、対応するユーザのための「合成フレーム」のセットをそれぞれが含んだ、複数の映像データストリーム205n(1≦n≦N)を生成する。なお、ユーザn(1≦n≦N)のための映像データストリーム205nにおける合成フレームは、描画後に加えられた、ユーザnのためのカスタマイズ情報によって指定されたカスタム化部分(1つ以上のグラフィック要素)を含む。これらの合成フレームが、映像符号化器285によって、ユーザn(1≦n≦N)のためのカスタム化されたグラフィック出力ストリーム(映像コンテンツ)206nへと符号化される。映像符号化器285は、動画の標準に従って合成フレームを符号化しうる。
グラフィック要素を一次フレーム540a、540b、…、に付加して所与のユーザのためのカスタマイズされた画像のセットを形成することが可能な多くの方法がある。これは、ここで説明されるように、描画部280及びカスタマイズ部1110の多くの非限定的な例示の実施形態を用いて達成されうる。

<実施形態1>
図5Aの実施形態において、図11の描画部280及びカスタマイズ部1110は、それぞれ、描画部280A及びカスタマイズ部1110Aとして表されている。カスタマイズ部1110Aは、グラフィック合成器500及び挿入制御部510を含む。グラフィック合成器500は、描画器1120と映像符号化器285との間のパスに沿って配置される。グラフィック合成器500は、描画器1120によって描画される一次フレームと、例えば、挿入制御部510を介して、画像データベース(D/B)520から、ユーザのそれぞれのための1つ以上の補助フレームとを取得する。そして、グラフィック合成器500は、一次フレームと、1つ以上の補助フレームのそれぞれとを合成して、複数のユーザ(ユーザクライアント)のそれぞれのためにそれぞれが生成される1つ以上の合成フレームを形成し、その1つ以上の合成フレームを映像符号化器285へ出力する。符号化された合成フレームのそれぞれが、例えばインターネットを介して、その対応するユーザ端末へ送信される。
なお、合成フレームは全ユーザクライアントに対して生成されなくてもよく、一次フレームが符号化され、1つ以上であるがすべてではないユーザクライアントへ送信されてもよい。例えば、グラフィック合成器500は、第1のユーザのために、一次フレームとその第1のユーザのための補助フレームとを合成することにより生成された第1の合成フレームを、第2のユーザのために、一次フレームとその第2のユーザのための補助フレームとを合成することにより生成された第2の合成フレームを出力することができる一方で、第1のユーザのために一次フレームを、第2のユーザのために、一次フレームとその第2のユーザのための「補助」フレームとを合成することにより生成された合成フレームを出力してもよい。
合成フレーム5501a、5501b、…、を含む映像データストリーム2051の場合について検討する。グラフィック合成器500は、一次フレーム540a、540b、…のそれぞれと、特定の補助フレーム5301x、5301y、…とを合成することにより、合成フレーム5501a、5501b、…のそれぞれを生成する。一次フレーム540a、540b、…は、描画器1120によって描画されて供給される一方で、補助フレーム5301x、5301y、…は、データベース520に記憶され、挿入制御部510によって供給される画像から導出されうる。なお、補助フレーム5301x、5301y、…は、以下の実施形態で説明するように、他の方法によって供給されてもよい。さらに、補助フレーム5301x、5301y、…は、1つ以上の事前に位置合わせされたグラフィック要素を含んでもよい。グラフィック合成器500は、補助フレーム5301x、5301y、…を、一次フレーム540a、540b、…と混合し、合成フレーム5501a、5501b、…を得る。例えば、グラフィック合成器500は、一次フレーム上に補助フレームを重ね合わせる。混合は、アルファ合成又はビットブリッティングなど、様々な技術を用いて行われうる。
ここで、合成フレーム5502a、5502b、…を含んだ映像データストリーム2052の、類似のケースについて検討する。グラフィック合成器500は、一次フレーム540a、540b、…のそれぞれと、特定の補助フレーム5302x、5302y、…とを合成することにより、合成フレーム5502a、5502b、…、のそれぞれを生成する。一次フレーム540a、540b、…が描画器1120によって描画されるとともに供給される一方で、補助フレーム5302x、5302y、…は、挿入制御部510によって供給される。なお、補助フレーム5302x、5302y、…は、後の実施形態で説明するように、他の方法によって供給されてもよい。また、補助フレーム5302x、5302y、…は、1つ以上の事前に位置合わせされたグラフィック要素を含んでもよい。グラフィック合成器500は、補助フレーム5302x、5302y、…を、一次フレーム540a、540b、…と混合し、合成フレーム5502a、5502b、…を得る。例えば、グラフィック合成器500は、一次フレーム上に補助フレームを重ね合わせる。
このように、(ユーザ1のための)映像データストリーム2051における合成フレーム5501a、5501b、…は、所定の補助フレーム5301x、5301y、…からのグラフィック要素が組み込まれうる、一次フレーム540a、540b、…からなる。同様に、(ユーザ1と同一のシーンを共有するユーザ2のための)映像データストリーム2052における合成フレーム5502a、5502b、…は、他の所定の補助フレーム5302x、5302y、…からのグラフィック要素が組み込まれうる、その同一の一次フレーム540a、540b、…からなる。全ての合成フレームが一次フレームと補助フレームとから形成されるわけではないことが理解されるべきである。例えば、いくつかの場合、一次フレームは、補助フレームによって変形されることなくカスタマイズ部1110Aを通過するようにされてもよい。
図5Bをさらに参照して、例示の一次フレーム540a、例示の補助フレーム5301x、例示の合成フレーム5501aを示す。補助フレーム5301aは、ユーザ1のための1つ以上のカスタマイズされたグラフィック要素(例えばテキストまたはグラフィック)を含んだ画面サイズのフレームでありうる。グラフィック要素は、画面の一部分のみを占め、事前に定められたサイズ、位置及び特性品質を有しうる。特性品質は、「ルックアンドフィール」と呼ばれることがあり、フォント、レイアウト、形状及び色の少なくともいずれかを含みうる。テキストについての具体的な場合において、「ルックアンドフィール」は、一般に受け付けられている定義を有する、フォント、色、スタイルなどを指しうる。グラフィックの場合、「ルックアンドフィール」は、パターン、スタイル、色及び形状に基づく、フレームの質的な特徴的外観を指しうる。すなわち、特性品質は、合成フレームにおいてグラフィック要素がどのように提示されるかを示す。特性品質は、グラフィック要素のそれぞれについて定められてもよい。例えば、グラフィック要素のうちの1つについての特性品質は、グラフィック要素のうちの別の1つについての特性品質と異なりうる。さらに、特性品質は、グラフィック要素の一部についてのみ定められてもよい。
データベース520は、画像情報を記憶するため、画像情報データベースと呼ばれてもよい。いくつかの実施形態では、画像情報は、事前に位置合わせされたグラフィック要素を有するフレームを構成しうる。他の実施形態では、データベース520に記憶される画像情報は、事前設定された位置又はサイズを有さず、外部の指定に従ってフレーム内で位置合わせとサイズ合わせとが行われうる、個別のグラフィック要素を構成しうる。図5Aの実施形態の場合、データベース520は、補助フレーム5301x、5301y、…、5302x、5302y、…、530Nx、530Ny、…を含むフレームを、収容しうる。したがって、補助フレームは、画像情報データベース520に記憶され、それぞれが事前に位置合わせされたグラフィック要素を含む画像を表しうる。データベース520内の個別の画像には、容易にアクセスすることができるように、ユニークな識別子(ID)が与えられうる。データベース520は、その中に記憶される画像が変化することを許容するために、動的に更新されうる。
図5Aに戻り、画像データベース520から適切な画像を取得し、適切な時刻にそれらをグラフィック合成器500へ供給するために、挿入制御部510は、描画命令生成部270からの、様々なユーザのためのカスタマイズ情報1150n(1≦n≦N)を受け付ける。非限定的な本実施形態においては、ユーザ1についてのカスタマイズ情報11501は、(「トリガ」と呼ばれる)挿入タイミング信号5601とID信号5701とを含みうる。ID信号5701は、どの画像が、データベース520から取得し、補助フレーム5301x、5301y、…において使用するのに的確であるかを特定する。トリガ信号5601は、取得された画像についてのタイミング/同期の特定を行い、すなわち、トリガ信号は、挿入制御部510がこれらの補助フレーム5301x、5301y、…を対応する一次フレーム540a、540b、…への挿入のためにグラフィック合成器500へ供給する時刻、又は、グラフィック合成器500がこれらの補助フレーム5301x、5301y、…を対応する一次フレーム540a、540b、…と合成する時刻を指定する。ここで、トリガ信号は、実世界における時刻又はビデオゲームの仮想世界における時刻を指定しうる。前者の場合、挿入制御部510は、補助フレームの挿入時刻を指定するためのリアルタイムクロックを有しうる。後者の場合、挿入制御部510は、挿入制御部が適切なタイミングでグラフィック合成器500へ補助フレームを供給することができるように、ビデオゲームのフレーム番号を取得するユニット、例えば、フレームカウンタを有しうる。この場合、フレーム番号をカウントアップするために、一次フレーム540が挿入制御部510へ入力されてもよいし、挿入制御部510は、グラフィック合成器500においてカウントアップされたフレーム番号を取得してもよい。挿入制御部510は、フレーム番号以外の、ビデオゲームの仮想世界の時刻を示す情報を取得してもよい。
なお、(ID信号5701、…、570Nを用いて)画像データベース520から抽出すべき適切な画像の特定は、各ユーザのアイデンティティ、人口統計情報、社会経済状態等のような、様々なファクタに依存しうる。また、ゲームプレイ中に、補助フレームが一次フレームへ挿入されることがより望ましい(又はより望ましくない)時がありえ、これは、それぞれのトリガ信号5601、…、560Nによって制御される。このように、ユーザn(1≦n≦N)についてのトリガ信号560nは、補助フレーム5301a、5301b、…をグラフィック合成器500へ供給するのに適切な時期を示しうる。
1つの非限定的な実施形態では、計算サーバ200Cで実行する描画命令生成部270は、ID信号5701、…、570Nとトリガ信号5601、…、560Nとを、ビデオゲームにおけるある所定の時点で生成し、これらの信号を挿入制御部510供給するように事前にプログラミングされる。結果として、挿入制御部510は、所定の挿入時刻に、グラフィック合成器500へ、所定の画像を提供し、所定の画像と所定の時刻は、ビデオゲームの状況に基づいて決定されうる。
結果の合成フレーム5501a、5501b、…において、画面上で持続する印象を与えるために、同一の補助フレームが、連続した一次フレーム5401a、5401b、…へ、挿入されてもよいことが理解されるべきである。さらに別の実施形態では、2つ以上の補助フレームが単一の一次フレームへ挿入されうることが予定されている。例えば、2つの画像を単一の補助フレームへと合成することに代えて、それぞれの画像から2つの別個の補助フレームが生成されることが可能でありえ、両者が対応する合成フレームを形成するために、特定の一次フレームと混合されることが可能でありうる。
<実施形態2>
図6Aでは、図11の描画部280及びカスタマイズ部1110が、それぞれ、描画部280B及びカスタマイズ部1110Bとして表されている。カスタマイズ部1110Bは、上述のグラフィック合成器500、及び挿入制御部610並びにグラフィックカスタマイズ器600を有する。グラフィック合成器500は、ここでも、描画器1120と映像符号化器285との間のパスに沿って配置される。実施形態1で説明したように、グラフィック合成器500は、一次フレームと各ユーザのための1つ以上の補助フレームとを取得し、一次フレームと1つ以上の補助フレームのそれぞれとを合成して、それぞれが複数のユーザ(ユーザクライアント)のそれぞれのために生成される1つ以上の合成フレームを形成し、1つ以上の合成フレームを映像符号化器285へ出力する。符号化された合成フレームのそれぞれは、例えばインターネットを介して、その対応するユーザ端末へ送信される。さらに、本実施形態においても、合成フレームは、ユーザクライアントの全てに対して生成される必要はなく、一次フレームが符号化され、1つ以上であるが全てではないユーザクライアントへ送信されてもよい。
ユーザ1のための、合成フレーム6501a、6501b、…を含む映像データストリーム2051の場合について検討する。グラフィック合成器500は、一次フレーム540a、540b、…のそれぞれを、補助フレーム6301x、6301y、…のうちの特定の1つと合成することにより、合成フレーム6501a、6501b、…のそれぞれを生成する。一次フレーム540a、540b、…は、描画器1120によって描画されて供給され、その一方で、補助フレーム6301x、6301y、…は、挿入制御部610によって供給される。なお、補助フレーム6301x、6301y、…は、他の方法によって供給されてもよい。グラフィック合成器500は、補助フレーム6301x、6301y、…を、一次フレーム540a、540b、…と混合し、合成フレーム6501a、6501b、…を得る。例えば、グラフィック合成器500は、補助フレームを一次フレーム上に重ね合わせる。混合は、アルファ合成又はビットブリッティングなどの様々な技術を用いて行われうる。
本実施形態では、挿入制御部610は、図5Aの挿入制御部510と同様である。例えば、ユーザ1の場合、類似点の1つは、挿入制御部610が、ユーザ1のためのカスタマイズ情報11501の一部として供給される上述の挿入タイミング(トリガ)信号5601に基づいて、適切な時刻に、補助フレーム6301x、6301y、…を、グラフィック合成器500に供給する役割を担うことである。ここで、トリガ信号5601は、挿入制御部610が、対応する一次フレーム540a、540b、…への挿入のために、これらの補助フレーム6301x、6301y、…をグラフィック合成器500へ供給するタイミング、又は、グラフィック合成器500が、これらの補助フレーム6301x、6301y、…を、対応する一次フレーム540a、540b、…と合成するタイミングを指定しうる。本実施形態においても、トリガ信号は、実世界の時刻又はビデオゲーム仮想世界における時刻を指定することができ、前者の場合、挿入制御部610が補助フレームの挿入タイミングを特定するためのリアルタイムクロックを有してもよく、後者の場合、挿入制御部610は、挿入制御部がグラフィック合成器500へ、適切なタイミングで補助フレームを供給することができるように、ビデオゲームのフレーム番号を取得するための手段、例えばフレームカウンタを有しうる。一方、相違点の1つは、補助フレーム6301x、6301y、…が、画像データベースから直接供給されるのではなく、以下詳細に説明するグラフィックカスタマイズ器600によって、挿入制御部610が利用可能となる点である。
具体的には、グラフィックカスタマイズ器600は、グラフィック要素データベース620へアクセスする。グラフィック要素データベース620は、様々なグラフィック要素をファイルとして記憶することができ、グラフィック要素のそれぞれは、テキスト(例えば単語、メッセージ)、グラフィック(例えば写真、画像)、又はそれらの組み合わせを表し得る。個別のグラフィック要素には、グラフィックカスタマイズ器600がそれらに容易にアクセスすることができるように、ユニークな識別子(ID)が与えられうる。データベース620は、それに記憶されているグラフィック要素が変化することを許容するように、動的に更新されうる。
グラフィックカスタマイズ器600は、所与のユーザn(1≦n≦N)に関する限りにおいて、2つの主要な機能を実行する。第1の機能は、ユーザnのためのカスタマイズ情報1150nの一部を形成すると共に先述のID信号570nと同様のID信号670nに基づいて、グラフィック要素データベース620から1つ以上のグラフィック要素640を選択することである。第2の機能は、選択されたグラフィック要素640を、挿入制御部610へ供給される補助フレーム630nx、630ny、…へと変換することである。この変形は、選択されたグラフィック要素640に適用されるべき所望のサイズ、位置、又は(「ルックアンドフィール」とも呼ばれる)特性品質を含むユーザnのためのパラメータのセット680nに基づいて、行われる。特性品質は、グラフィック要素が合成フレームにおいてどのように提示されるかを示し、フォント、レイアウト、形状及び色の少なくとも1つを含みうる。また、パラメータのセット680nは、ユーザnのためのカスタマイズ情報1150nの一部を形成する。なお、パラメータのセット680nは、時間と共に変化しうる。すなわち、例えば、グラフィック要素640に適用されるべき、位置、サイズ、又は、特性品質の少なくともいずれかは、時間と共に変化する。結果として、グラフィックカスタマイズ器600は、補助フレームを生成し、それらを挿入制御部610へ供給し、挿入制御部610は、所望の挿入時間において、グラフィック合成器500へ、所望の特性品質が適用された1つ以上の所望のグラフィック要素を含んでいる、生成された補助フレームを供給する。
図6Bをさらに参照して、例示の一次フレーム540a、2つの例示のグラフィック要素640、例示の補助フレーム6301x、及び、例示の合成フレーム6501aを示す。ユーザ1のためのこの場合に、選択されたグラフィック要素640は、カスタマイズされたグラフィック要素(例えば、テキストファイル及びグラフィックファイル)を含む。選択されたグラフィック要素640は、例示の補助フレーム6301xに含まれるが、画面サイズの画像を生成するために、適切にサイズ合わせ、位置合わせ、及びフォーマットがなされる。
なお、本実施形態では、選択されたグラフィック要素640は一般的なものであることができ、サイズ、位置、又は特性品質の少なくともいずれかに基づいて(すなわち、パラメータのセット680nによって定められるように)、所与のユーザnのためにカスタマイズされてもよい。すなわち、パラメータのセット680nは、その対応するグラフィック要素がフレーム内で配置される所望のサイズ若しくは所望の位置又は所望のサイズ及び位置と、その対応するグラフィック要素がどのように合成フレームにおいて提示されるかを示す所望の特性品質との少なくともいずれかを指定しうる。パラメータのセット680nは、ID信号670nによって特定される全てのグラフィック要素に対して定義されうるが、パラメータのセット680nは、グラフィック要素の一部のみに対して定義されてもよい。グラフィックカスタマイズ器600は、グラフィック要素を、所望の位置、サイズ、特性品質の少なくともいずれかで配置することにより、補助フレームを生成しうる。パラメータのセット680nは、描画命令生成部270が知りうる様々な要素に依存してもよい。したがって、パラメータのセット680nは、トリガ信号560n及びID信号670nと共に、描画命令生成部270によって供給されうる。非限定的な例示の実施形態では、パラメータのセット680nは、描画命令のセット2041内の描画命令の解析を実行したことに基づいて、描画命令生成部270によって決定されうる。
<実施形態3>
ユーザn(1≦n≦N)の場合、パラメータのセット680nは、補助フレーム630nx、640ny、…内での選択されたグラフィック要素640の、位置、サイズ、特性品質(「ルックアンドフィール」)の少なくともいずれかを表し得ることに留意されたい。パラメータのこれらの3つの例は、一次フレーム540a、540b、…のグラフィックレイアウトに依存するため、挿入されるべきカスタマイズされたテキストとグラフィックとの少なくともいずれかについての、適切なサイズ、位置、及び「ルックアンドフィール」を推定するために、一次フレーム540a、540b、…を処理することができる。このような描画されたフレームの処理は、描画命令生成部270の中でビデオゲームのソースコードへのアクセスができない場合に、特に有用でありうる。
この目的のために、図7では、図11の描画部280及びカスタマイズ部1110は、それぞれ、描画部280C及びカスタマイズ部1110Cとして表されている。描画部280Cは、カスタマイズ部1110Cが画像処理器700を含む点を除き、図6Aの描画部280Bと実質的に同様である。換言すれば、パラメータのセット680n(1≦n≦N)は、グラフィックカスタマイズ器600に供給され続けるが、それらは、描画命令生成部270からのものではない。むしろ、パラメータ680のセットn(1≦n≦N)は、画像処理器700によって供給される。具体的には、画像処理器700は、描画器1120から一次フレーム540a、540b、…を受け取り、グラフィック要素についての候補位置と避けるべき興味領域との少なくともいずれかを特定するために、一連の機能(例えば、パターン認識、テキスト認識、コントラスト検出など)を実行する。例えば、画像処理器700は、ゲームに関する所定の情報(プレイヤの位置、現在の武器、スコア、インベントリなど)を抽出し、抽出された情報がグラフィック要素をトリガすべき場合にデータベース内で検索するために、一次フレーム540a、540b、…を解析しうる。
また、画像処理器700は、「ルックアンドフィール」と呼ばれうる、一次フレーム540a、540b、…の様々な特性を検出しうる。非限定的な例では、一次フレーム540a、540b、…の「ルックアンドフィール」、はフォントを含みうる。フォントは、例えば、www.myfonts.com/WhatTheFontなどの既存のユーティリティを用いて、自動で検出されうる。他の検出可能な特性は、その検出も自動化されうる、一次フレーム540a、540b、…におけるオブジェクトのサイズ及び色(又は表現)を含むことができる。その一方で、「ルックアンドフィール」が完全に自動化された方法で判定されることは必須ではない。例えば、ゲームの「ルックアンドフィール」に関する様々な特性は、客観的及び反復可能な基準に基づいて、人間によって一義的に決定されることが可能でありうる。
画像処理器700の出力は、パラメータのセット680n(1≦n≦N)、すなわち、その後に上述したグラフィックカスタマイズ器600によって使用される選択されたグラフィック要素640についての、位置、サイズ、「ルックアンドフィール」の少なくともいずれかを含みうる。このように、画像処理器700は、ビデオゲームの状況に基づいて(すなわち、一次フレームの解析結果に基づいて)、グラフィック要素に適用されるべきパラメータ(所望の位置、所望の挿入タイミング、特性品質の少なくともいずれか)を決定しうる。
<実施形態4>
ここで、図8に移ると、図11の描画部280及びカスタマイズ部1110は、それぞれ、描画部280D及びカスタマイズ部1110Dとして表されている。カスタマイズ部1110Dは、図5A及び6Aのグラフィック合成器500と図6Aのグラフィックカスタマイズ器600との機能を組み合わせた、グラフィックカスタマイズ及び合成器800を有する。グラフィックカスタマイズ及び合成器800は、描画器1120と映像符号化器285との間のパスに沿って配置される。本実施形態では、グラフィックカスタマイズ及び合成器800へ供給されるものは、(図5A及び図6Aにおける場合のような)補助フレームではなく、選択されたグラフィック要素640及び上述のパラメータのセット6801、…、680Nである。具体的には、グラフィックカスタマイズ及び合成器800は、ユーザnのために、パラメータのセット680nに従って、選択されたグラフィック要素640のサイズ合わせ、位置合わせ、フォーマットの少なくともいずれかを実行する。その結果は、映像符号化器285へ送出される合成フレーム850na、850nb、…を生成するために一次フレーム540a、540b、…と合成される、内部的に生成された補助フレーム(不図示)でありうる。
本実施形態では、選択されたグラフィック要素640は、上述のグラフィック要素データベース620へアクセスする挿入制御部810によって、提供される。グラフィック要素データベース620から適切なグラフィック要素を抽出して適切なタイミングでそれらをグラフィックカスタマイズ及び合成器800へ供給するために、挿入制御部810は、上述の挿入タイミング(トリガ)信号5601、…、560N及び上述のID信号6701、…、670Nに依拠する。ID信号6701、…、670Nは、どのグラフィック要素が、選択されたグラフィック要素640として、データベース620から読み出すことが的確なものであるかを特定する。それらの一部として、上述のように、トリガ信号5601、…、560Nは、選択されたグラフィック要素640が一次フレーム540a、540b、…への挿入のためにグラフィックカスタマイズ及び合成器800に提供されるべきタイミング、又は、グラフィックカスタマイズ及び合成器800が、これらのグラフィック要素640を一次フレーム540a、540b、…と合成するタイミングを指定する。ここで、トリガ信号は、実世界における時刻又はビデオゲームの仮想世界における時刻を指定しうる。前者の場合、挿入制御部810は、選択されたグラフィック要素640の挿入タイミングを特定するためのリアルタイムクロックを有しうる。後者の場合、挿入制御部810は、挿入制御部が選択されたグラフィック要素640をグラフィックカスタマイズ及び合成器800へ適切なタイミングで提供することができるように、ビデオゲームのフレーム番号を取得する手段、例えばフレームカウンタを有しうる。この場合、一次フレーム540は、フレーム番号のカウントアップのために挿入制御部810へ入力されてもよいし、挿入制御部810は、グラフィックカスタマイズ及び合成器800においてカウントアップされたフレーム番号を取得してもよい。挿入制御部810は、フレーム番号以外のビデオゲームの仮想世界の時刻を示す情報を取得してもよい。
なお、(ユーザnのためのID信号670nを用いた)適切なグラフィック要素の特定は、ユーザのアイデンティティ、人口統計情報、社会経済状態、地理的位置等のような様々なファクタに依存しうる。また、ゲームプレイ中に、選択されたグラフィック要素640が一次フレーム540a、540b、…へ挿入されることがより望ましい(又はより望ましくない)時がありえ、これは、それぞれのトリガ信号560nによって制御される。このように、ユーザnについてのトリガ信号560nは、選択されたグラフィック要素640をグラフィックカスタマイズ及び合成器800へ供給するのに適切な時期を示しうる。ID信号670n及びトリガ信号560nは、計算サーバ200Cによって実行されうる描画命令生成部270によって、制御され、供給されうる。
グラフィックカスタマイズ及び合成器800は、2つの主要な機能を実行する。第1の機能は、選択されたグラフィック要素640を、内部補助フレーム(不図示)へと変換することである。この変換は、選択されたグラフィック要素640に適用されるべき所望のサイズ、位置又は「ルックアンドフィール」(特性品質)を含みうるパラメータのセット680nに基づいて、ユーザn(1≦n≦N)のために行われる。ここで、グラフィックカスタマイズ及び合成器800は、必ずしも内部補助フレームを生成しなくてもよい。例えば、グラフィックカスタマイズ及び合成器800は、グラフィック要素に適用されるべき位置、サイズ、特性品質の少なくともいずれかを決定し、決定された位置、サイズ、特性品質の少なくともいずれかに従って、これらのグラフィック要素を一次フレーム上に直接配置してもよい。グラフィックカスタマイズ及び合成器800の第2の機能は、合成フレーム850na、850nb、…を生成するために、これらの補助フレームを一次フレーム540a、540b、…と混合することである。
なお、本実施形態では、選択されたグラフィック要素640は、ユーザnのために、それらのサイズ、位置及び「ルックアンドフィール」(すなわち、パラメータのセット680n)と無関係にカスタマイズ可能である。パラメータのセット680nは、描画命令生成部270に知られていてもよい様々なファクタに依拠しうる。したがって、ユーザn(1≦n≦N)のためのパラメータのセット680nは、トリガ信号560n及びID信号670nと共に、描画命令生成部270によって供給されうる。
<実施形態5>
ここで、図9に移ると、図11の描画部280及びカスタマイズ部1110は、それぞれ、描画部280E及びカスタマイズ部1110Eとして表されている。本実施形態では、カスタマイズ部1110Eは、図7の文脈において上で説明した、上述の画像処理器700を含む。換言すれば、(グラフィックカスタマイズ及び合成器800へ供給され続ける)パラメータのセット6801、…、680Nは、描画命令生成部270ではなく、画像処理器700によって提供される。画像処理器700は、一次フレーム540a、540b、…を受け取り、グラフィック要素の候補位置と、避けるべき興味領域との少なくともいずれかを特定するために、一連の機能(例えば、パターン認識、テキスト認識、コントラスト検出など)を実行する。また、画像処理器700は、すでに上述した方法で、一次フレーム540a、540b、…の、「ルックアンドフィール」と呼ばれうる様々な特性を検出する。画像処理器700の出力は、ユーザ単位で、選択されたグラフィック要素640についての位置、サイズ、「ルックアンドフィール」の少なくともいずれかなどの、パラメータのセット6801、…、680Nを含みうる。このように、画像処理器700は、ビデオゲームの状況に基づいて(すなわち、一次フレームの解析結果に基づいて)、グラフィック要素に適用されるべきパラメータ(所望の位置、所望の挿入タイミング、特性品質の少なくともいずれか)を決定しうる。
<他の実施形態>
上述の図面は、コンピュータ可読媒体に記憶された命令としてその機能性が符号化されるソフトウェアモジュールとして、実現されうる要素を示している。グラフィック合成器500及びグラフィックカスタマイズ及び合成器800の場合、これらの要素は、描画サーバ200Rの一部として実装されうる。挿入制御部510、610、810の場合、様々な実施形態に従って、図10に示すような、グラフィックカスタマイズ器600、画像処理器700、グラフィックカスタマイズ及び合成器800、画像データベース520、及び、グラフィック要素データベース620、上述の要素の所定のものが、計算サーバ200Cの一部として、又は描画サーバ200Rの一部として実装されうる。他の実施形態では、それらは、インターネット130などのネットワークを介して到達可能な別個のサーバにおいて実装されうる。
変形例によれば、画像処理器700は、ID信号5701、…、570N、6701、…、670Nに加えて、一次フレーム540a、540b、…へグラフィックを挿入するのにいつが適しているかを示す、トリガ信号5601、…、560N、6601、…、660Nをも、出力してもよい。例えば、画像処理器700は、アクションが低下した又は異なるシーン又はレベルへの遷移があるゲーム内の時期を検出することができる。例えば、画面は、プレイヤのキャラクタが負傷した際に、不鮮明となるか、グレースケールに移るかの少なくともいずれかでありえ、そのキャラクタが回復し、非難し、又は危険から逃れると、通常にゆっくりと戻りうる。このような遷移又は変化は、画像処理器700によって監視されるべき要素のリストの観点から定義され、それによりアクションのレベル又はシーンの遷移の自動検出を促進することが可能でありうる。
本発明の技術分野に属する当業者は、上述した実施形態が例示であり限定するものではないものとみなされるべきことを理解する必要がある。本技術分野の当業者の知識の範疇であることが想定されるような、本発明の特定の実施形態の動作のために必要でありうる付加的な要素が説明または図示されていないことも理解されるべきである。さらに、本発明の特定の実施形態は、ここに具体的に記載していない任意の要素を含まなくてもよい、その要素を欠いてもよい、及び/またはその要素なしに機能してもよい。
また本技術分野に属する当業者は、記載された実施形態の付加的な適応及び変形がなされうることを理解するだろう。したがって、本発明の範囲は、上述した特定の実施形態によって限定されるべきものでなく、むしろ添付の特許請求の範囲によって定められる。
例示的な実施形態を参照して本発明を説明してきたが、記載した例示的な実施形態に発明が限られるものでないことが理解されるべきである。以下の特許請求の範囲は、このような変形、等価な構成及び機能の全てを包含するような、最も広範な解釈が認められるべきものである。また、本発明に係る画像処理装置、及び情報処理装置の制御方法は、コンピュータにおいてその手法を実行するプログラムにより実現可能である。プログラムは、コンピュータ読み取り可能な記録媒体に格納されることにより、または電気的な通信回線を介して、提供/配信可能である。
本出願は、その全体がここに参照により援用される、2013年6月17日に出願された米国仮出願第61/835765号の利益を主張するものである。



  1. 描画手段によって描画されると共に映像データストリームに含まれる第1のフレームを取得すると共に、第1のユーザと第2のユーザとの少なくともいずれかのための追加画像データとを取得する取得手段と、
    前記第1のフレームと前記第1のユーザのための前記追加画像データとを組み合わせることによる第1の合成フレームと、前記第1のフレームと前記第2のユーザのための前記追加画像データとを組み合わせることによる第2の合成フレームと、の少なくともいずれかを生成する合成手段と、
    前記第1のユーザのために、前記第1の合成フレームが生成された場合は当該第1の合成フレームを、前記第1の合成フレームが生成されていない場合は前記第1のフレームを出力し、前記第2のユーザのために、前記第2の合成フレームが生成された場合は当該第2の合成フレームを、前記第2の合成フレームが生成されていない場合は前記第1のフレームを出力する出力手段と、
    を有する画像処理装置。

  2. 前記取得手段は、記憶手段から前記追加画像データを取得するように構成される、
    請求項1に記載の画像処理装置。

  3. 前記追加画像データは、1つ以上の事前に配置されたグラフィック要素を含む第2のフレームである、
    請求項1又は2に記載の画像処理装置。

  4. 各ユーザのためのカスタマイズ情報を受け付ける受付手段をさらに有し、
    前記取得手段は、前記受け付けたカスタマイズ情報に従って前記追加画像データを取得するように構成される、
    請求項1から3のいずれか1項に記載の画像処理装置。

  5. ユーザのための前記カスタマイズ情報は、当該ユーザのための前記追加画像データの識別子と前記追加画像データの挿入時刻に関する情報との少なくとも1つを含む、
    請求項4に記載の画像処理装置。

  6. 前記映像データストリームはビデオゲームに関し、前記追加画像データの前記識別子は前記ビデオゲームの状況に基づいて決定される、
    請求項5に記載の画像処理装置。

  7. 前記挿入時刻に関する情報は、前記追加画像データが前記第1のフレームと合成される時刻、又は前記取得手段によって前記追加画像データが取得される時刻を指定する、
    請求項5に記載の画像処理装置。

  8. 前記映像データストリームはビデオゲームに関し、前記挿入時刻は、前記ビデオゲームの状況に応じて決定される、
    請求項5から7のいずれか1項に記載の画像処理装置。

  9. 前記取得手段は、前記追加画像データとして1つ以上のグラフィック要素を取得するように構成され、前記合成手段は、前記第1のフレーム内で前記1つ以上のグラフィック要素のそれぞれを配置することによって、合成フレームを生成するように構成される、
    請求項1又は2に記載の画像処理装置。

  10. 前記合成手段は、前記1つ以上のグラフィック要素のそれぞれが前記第1のフレーム内において配置される位置とサイズとの少なくともいずれかを制御するように構成される、
    請求項9に記載の画像処理装置。

  11. 前記合成手段は、前記1つ以上のグラフィック要素の少なくとも1つが前記第1のフレーム内において配置される所望の位置とサイズとの少なくともいずれかを指定するパラメータセットを受信し、前記所望の位置とサイズとの少なくともいずれかに従って、前記1つ以上のグラフィック要素のそれぞれが前記第1のフレーム内に配置される前記位置と前記サイズとの少なくともいずれかを制御する、
    請求項10に記載の画像処理装置。

  12. 前記1つ以上のグラフィック要素のそれぞれが前記第1のフレーム内で配置される前記位置と前記サイズとの少なくともいずれかは、時間に応じて変化する、
    請求項10又は11に記載の画像処理装置。

  13. 前記パラメータセットは、前記1つ以上のグラフィック要素が前記合成フレームにおいてどのように表現されるかを示す、当該1つ以上のグラフィック要素の少なくとも1つの特性品質をさらに指定する、
    請求項11に記載の画像処理装置。

  14. 前記特性品質は、フォント、レイアウト、形状、及び色の少なくとも1つを含む、
    請求項13に記載の画像処理装置。

  15. 各ユーザのためのカスタマイズ情報を受け付ける受付手段をさらに有し、
    前記取得手段は、前記受け付けたカスタマイズ情報に従って前記1つ以上のグラフィック要素を取得するように構成される、
    請求項9から14のいずれか1項に記載の画像処理装置。

  16. 前記合成手段は、前記描画手段が前記第1のフレームを描画する際に基づく描画命令セットの一部として前記パラメータセットを受信するように構成される、
    請求項11、13又は14に記載の画像処理装置。

  17. 前記第1のフレームを解析することにより、前記パラメータセットを生成するパラメータ生成手段をさらに有する、
    請求項11、13又は14に記載の画像処理装置。

  18. 請求項1から17のいずれか1項に記載の画像処理装置と前記第1のフレームを描画する描画手段とを含む、
    画像処理システム。

  19. 画像を処理する方法であって、
    描画手段によって描画されると共に映像データストリームに含まれる第1のフレームを取得し、
    第1のユーザと第2のユーザとの少なくともいずれかのための追加画像データを取得し、
    前記第1のフレームと前記第1のユーザのための前記追加画像データとを組み合わせることによる前記第1のユーザのための第1の合成フレームと、前記第1のフレームと前記第2のユーザのための前記追加画像データとを組み合わせることによる前記第2のユーザのための第2の合成フレームと、の少なくともいずれかを生成し、
    前記第1のユーザのために、前記第1の合成フレームが生成された場合には前記第1の合成フレームを、前記第1の合成フレームが生成されていない場合には前記第1のフレームを、出力し、
    前記第2のユーザのために、前記第2の合成フレームが生成された場合には前記第2の合成フレームを、前記第2の合成フレームが生成されていない場合には前記第1のフレームを、出力する、
    方法。

  20. 計算エンティティによって実行されるときに、当該計算エンティティに方法を実行させるコンピュータ可読命令を有するコンピュータ可読媒体であって、前記方法は、
    描画手段によって描画されると共に映像データストリームに含まれる第1のフレームを取得することと、
    第1のユーザと第2のユーザとの少なくともいずれかのための追加画像データを取得することと、
    前記第1のフレームと前記第1のユーザのための前記追加画像データとを組み合わせることによる前記第1のユーザのための第1の合成フレームと、前記第1のフレームと前記第2のユーザのための前記追加画像データとを組み合わせることによる前記第2のユーザのための第2の合成フレームと、の少なくともいずれかを生成することと、
    前記第1のユーザのために、前記第1の合成フレームが生成された場合には前記第1の合成フレームを、前記第1の合成フレームが生成されていない場合には前記第1のフレームを、出力することと、
    前記第2のユーザのために、前記第2の合成フレームが生成された場合には前記第2の合成フレームを、前記第2の合成フレームが生成されていない場合には前記第1のフレームを、出力することと、
    を含むコンピュータ可読媒体。

  21. 画像の系列を表す初期フレームのセットを描画する描画手段と、
    複数のユーザのそれぞれのためのカスタマイズ情報を受信し、前記初期フレームのセットを変形して出力フレームの複数のセットを生成するカスタマイズ手段と、
    を有し、
    出力フレームの各セットは、前記ユーザのそれぞれのための前記カスタマイズ情報に基づいて、当該ユーザのためにカスタマイズされた画像の系列を表す、
    画像処理装置。

  22. 請求項21に記載の画像処理装置と、描画命令を生成する描画命令生成手段とを有する画像処理システムであって、
    前記描画手段は、前記描画命令に従って前記初期フレームのセットを描画するように構成される、
    ことを特徴とする画像処理システム。

  23. 画像を処理する方法であって、
    画像の系列を表す初期フレームのセットを描画し、
    複数のユーザのそれぞれのためのカスタマイズ情報を受信し、
    前記初期フレームのセットを変形して出力フレームの複数のセットを生成し、
    出力フレームの各セットは、前記ユーザのそれぞれのための前記カスタマイズ情報に基づいて、当該ユーザのためにカスタマイズされた画像の系列を表す、
    方法。

  24. 計算エンティティによって実行されるときに、当該計算エンティティに方法を実行させるコンピュータ可読命令を有するコンピュータ可読媒体であって、前記方法は、
    画像の系列を表す初期フレームのセットを描画することと、
    複数のユーザのそれぞれのためのカスタマイズ情報を受信することと、
    前記初期フレームのセットを変形して出力フレームの複数のセットを生成することと、
    を含み、
    出力フレームの各セットは、前記ユーザのそれぞれのための前記カスタマイズ情報に基づいて、当該ユーザのためにカスタマイズされた画像の系列を表す、
    コンピュータ可読媒体。

 

 

Patent trol of patentswamp
類似の特許
本願はデジタル署名の生成方法及び装置を提供する。該方法は、装置が有効性判定条件を満たすデジタル署名パラメータrを生成し、秘密鍵d、乱数k、r及び楕円曲線パラメータnを用いて、以下の式


に従ってデジタル署名パラメータsを生成し、ここで、kの値範囲が[1,n−1]であり、生成されたsが0であるか否かを判断し、0の場合、0でないものとなるまで、有効性判定条件を満たすrを生成し直し、d、生成し直された値範囲が[1,n−1]のk、生成し直されたr及びnを用いて、sを生成し直し、r及び0でないsのデータ型をバイトストリングに変換し、デジタル署名(r,s)を取得する。本願の実施例に係る態様によれば、簡略化された計算式を用いてデジタル署名パラメータsを取得することで、大整数演算の回数を低減でき、SM2デジタル署名生成アルゴリズムに基づくデジタル署名生成の演算効率を向上できる。
車両通信システム(100)は、車両(102)に位置付けられる基地局(104)と、移動体通信ユニット(122)を備える。基地局(104)は、移動体通信ユニット(122)に信号を送信するための第1送信器と、移動体通信ユニット(122)から認証信号を受信するための第1受信器を備える。基地局(104)は、移動体通信ユニットと少なくとも第1送信器及び第1受信器の間の通信の飛行時間に基づいて車両に対する移動体通信ユニットの位置を追跡し;被監視車両(102)機能のパフォーマンスに関するサブシステムステータス信号を受け取り、サブシステムステータス信号に基づいて、被監視車両(102)機能に関する被監視機能ステータスを決定するように構成される。基地局(104)は、また、移動体通信ユニット(122)による受信のためのステータス更新信号を出力するようにも構成され、ステータス更新信号は、被監視機能ステータスの指標である。車両通信システム(100)は、移動体通信ユニット(122)の位置に依存してステータス更新信号に基づいてユーザーに対してステータス指標を提供するように構成される。
無線ネットワークにおけるマシンタイプ通信のためのeNodeBおよび方法の実施形態が本明細書において概して記載される。いくつかの実施形態において、進化型ノードB(eNodeB)の回路によって実行される方法は、ユーザ機器(UE)がマシンタイプ通信(MTC)に用いられるよう設定されるという通知をeNodeBが受信する段階を含み得る。当該方法は、UEが無線リソース制御接続(RRC_Connected)状態にあるかどうかを決定する段階と、UEが省電力モードに入り得るかどうかを決定する段階とを含み得る。当該方法は、UEがRRC_Connected状態にあり、かつ、UEが省電力モードに入り得ると決定することに応答して、RRCディープアイドルモードに移行するようUEを設定する段階を含み得る。
特に、電子装置内の2つのデバイス間のデータの送信を容易にするシステム、方法および装置を説明する。情報が、n相極性符号化シンボルにおいて送信される。ドライバは、連続的なシンボル間の遷移期間を最小にするために、2つ以上のコネクタ上の状態遷移を整列させるように適合または構成され得る。ドライバは、いくつかの遷移を進ませるかまたは遅延させる回路を含み得る。ドライバは、コネクタが非駆動状態に遷移されているときでさえ、遷移期間の一部の間にコネクタの状態を駆動するように動作するプリエンファシス回路を含み得る。
データフィード(14)のソースによる再送信を必要としないデータフィードからブロードキャストされたデータユニットを管理することが、ネットワーク(12)の第1のノードにおいて、複数のデータユニットを含むデータフィードの少なくとも一部を受信することと、ネットワークの第2のノードにおいて、データフィードの少なくとも一部を受信することと、第1のノードにおいてデータフィードの受信の中断を判定することと、中断の前に第1のノードによって受信された最後のデータユニットと中断の後に第1のノードによって受信された最初のデータユニットとの間に広がるデータの欠落(504)の範囲を特定することと、第2のノードによって保存された結果(510)に対する要求を第1のノードから送信すること(506)であって、第2のノードによって保存された結果がデータの欠落に対応する、送信することとを含む。
安全な産業用制御システムについて開示する。産業用制御システムは、複数の産業エレメント(例えば、モジュール、ケーブル等)を含み、それら自体の一意のセキュリティ証明を製造の間に供給される。安全な産業用制御システムの鍵管理エンティティは、製造された時点から開始して、産業用制御システムにおいて実装されるまで、およびその間にわたり、産業用制御システムのセキュリティを促進するために、産業エレメントのセキュリティ証明を監視および管理する。産業用制御システムに実装された産業エレメントを認証するための、セキュリティ証明に基づく認証プロセスが、産業用制御システムのセキュリティを促進するために実行される。1つ以上の実装態様において、安全な産業用制御システムが有する全ての産業エレメントは、複数の(例えば、全ての)システムのレベルでセキュリティを設けるためにセキュリティ証明が供給される。
【選択図】図1
本発明は、動通信システムで端末が上向きリンクデータを伝送するためにスケジューリング要請をする方法に関する。具体的に互いに異なる基地局間の搬送波結合をするシステムで、端末がそれぞれの基地局別に「スケジューリング要請」制御情報を伝送するようにするスケジューリング要請手続及び方法を定義することによって、動的なスケジューリング及び上向きリンクデータの効率的な伝送が可能にする。
セルラ通信システムにおいて、補償サービスエリアに割り当てられたリソースが、省エネサービスエリアによってサービス提供されている1つ以上のUE装置にサービスを提供するための充分な利用可能なキャパシティを有すると判定する場合に、カバレッジエリア構成遷移が行われる。カバレッジエリア構成遷移は、省エネルギーサービスエリアのカバレッジの縮小と補償サービスエリアのカバレッジの拡張とを含む。補償サービスエリアを提供する補償通信局は、カバレッジエリア構成遷移のための要求を省エネルギー通信局に送信する。省エネルギー通信局は、該カバレッジエリア構成遷移を拒絶してもよいし、該カバレッジエリア構成遷移を承諾して拡張通知を補償通信局に送信してもよい。該通知は、補償サービスエリアが拡張され得ることを少なくとも示す。
移動通信ネットワークの一部を形成するインフラ機器は、通信端末からデータパケットを受信する。インフラ機器は、無線アクセスインタフェースに従って信号を送信し、受信する送信機および受信機を制御するように構成されたスケジューラを含み、スケジューラは受信機から、通信端末の入力バッファ内の遅延許容データパケットおよび非遅延許容データパケットの数の指示を受信するように構成され、入力バッファは無線アクセスインタフェースを介した通信端末による送信に対するデータパケットをバッファするためのデータパケットを受信し、無線アクセスインタフェースを介して通信端末からインフラ機器にデータパケットを送信するための無線通信の現在の状態の指示を受信する。スケジューラは、無線通信の現在の状態と、通信端末の入力バッファ内の遅延許容データパケットの量と、入力バッファ内の非遅延許容パケットの量と、を含む所定の状態に応じて、非遅延許容データパケットをインフラ機器に送信するためまたは非遅延許容データパケットおよび遅延許容データパケットをインフラ機器に送信するために、通信端末に対して無線アクセスインタフェースの通信リソースを割り当てるか、所定の状態が満たされるまで、無線アクセスインタフェースの通信リソースを割り当てないか、を判定し、通信リソースが通信端末に割り当てられる場合、スケジューラは、遅延許容データパケットと非遅延許容データパケットまたは非遅延許容データパケットを受信するように構成される。それによって、構成は、通信端末の電力を節約し、より効率的に移動通信ネットワークによって提供される無線アクセスインタフェースの通信リソースを利用することができる方法で、少なくとも遅延許容および非遅延許容データパケットに分類されるデータパケットが通信端末によって送信される。
【選択図】図14
本発明の実施形態は、マルチキャリア信号(RFS)を条件付ける送信機装置(TA1)に関する。送信機装置(TA1)は、マルチキャリア信号(RFS)のサブキャリアを、このサブキャリアの第1のグループを含む第1の周波数ブロックと、前記サブキャリアの少なくとも第2のグループを含む少なくとも第2の周波数ブロックとにグループ化する手段(FE−PU)を含む。送信機装置(TA1)はさらに、第1の周波数ブロックの外側で側波帯抑制をする第1のフィルタリング手段(LPF−1)と、少なくとも第2の周波数ブロックの外側で同時および別個の側波帯抑制をする少なくとも第2のフィルタリング手段(LPF−2、...、LPF−M)とを含む。本発明の実施形態はさらに、マルチキャリア信号(RFS)を条件付ける方法に関する。この方法は、マルチキャリア信号(RFS)のサブキャリアを、前記サブキャリアの第1のグループを含む第1の周波数ブロックと、前記サブキャリアの少なくとも第2のグループを含む少なくとも第2の周波数ブロックとにグループ化するステップを含む。この方法はさらに、第1の周波数ブロックの外側で側波帯抑制をするために第1の周波数ブロックをフィルタリングするステップと、少なくとも第2の周波数ブロックの外側で同時および別個の側波帯抑制をするために少なくとも第2の周波数ブロックをフィルタリングするステップとを含む。本発明の実施形態はさらに、コンピュータ・プログラムがコンピュータまたはプロセッサ上で実行される場合には、この方法を実施するためのプログラム・コードを有するコンピュータ・プログラムと、送信機装置を含むネットワーク・ノードとに関する。
To top