特許 7595154 動画像受信装置、制御方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-27

(45)【発行日】2024-12-05

(54)【発明の名称】動画像受信装置、制御方法及びプログラム

(51)【国際特許分類】

   H04N 21/45 20110101AFI20241128BHJP

   H04N 21/472 20110101ALI20241128BHJP

   A63F 13/86 20140101ALI20241128BHJP

   A63F 13/77 20140101ALI20241128BHJP

【ＦＩ】

H04N21/45

H04N21/472

A63F13/86

A63F13/77

【請求項の数】 7

(21)【出願番号】P 2023517463

(86)(22)【出願日】2022-04-19

(86)【国際出願番号】 JP2022018209

(87)【国際公開番号】W WO2022230727

(87)【国際公開日】2022-11-03

【審査請求日】2023-11-07

(31)【優先権主張番号】P 2021077839

(32)【優先日】2021-04-30

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】310021766

【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】谷川 正和

【審査官】鈴木 順三

(56)【参考文献】

【文献】特開２０００－１０７４５３（ＪＰ，Ａ）

【文献】特開２０１９－１６４７９２（ＪＰ，Ａ）

【文献】特開２０１６－０４８８９８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００ － ２１／８５８

Ａ６３Ｆ １３／００ － １３／９８

(57)【特許請求の範囲】

【請求項1】

動画像を構成するフレーム画像を表す画像データを動画像送信装置から順次受信する動画像受信装置であって、
ユーザの入力操作に応じた操作データを前記動画像送信装置に送信する操作データ送信部と、
前記動画像送信装置における前記操作データの受信から当該操作データに基づく前記フレーム画像の生成の開始までの時間を示す間隔データを前記動画像送信装置から受信する間隔データ受信部と、
前記間隔データに基づいて、次の前記操作データが送信されるタイミングを制御する送信タイミング制御部と、
を含むことを特徴とする動画像受信装置。

【請求項2】

前記操作データに基づく前記フレーム画像の生成の開始に応じて前記動画像送信装置から送信される、当該操作データに対応付けられるパケットを受信するパケット受信部、をさらに含み、
前記送信タイミング制御部は、前記パケットを受信したタイミングから次の前記操作データが送信されるまでの時間を制御する、
ことを特徴とする請求項１に記載の動画像受信装置。

【請求項3】

前記送信タイミング制御部は、前記パケットを受信したタイミングから次の前記操作データが送信されるまでの時間が第１の目標を達成するよう前記操作データが送信されるタイミングを制御する第１制御と、前記間隔データが示す時間が第２の目標を達成するよう前記操作データが送信されるタイミングを制御する第２制御と、を実行し、
前記送信タイミング制御部は、前記第１制御において前記第１の目標が達成されたことに応じて、前記第２制御を開始する、
ことを特徴とする請求項２に記載の動画像受信装置。

【請求項4】

前記送信タイミング制御部は、前記間隔データに基づいて、これから送信される前記操作データの送信周期を制御する、
ことを特徴とする請求項１に記載の動画像受信装置。

【請求項5】

前記動画像は、ゲームのプレイ状況に応じて生成される動画像であって、
前記入力操作は、前記ゲームのプレイにおける入力操作である、
ことを特徴とする請求項１に記載の動画像受信装置。

【請求項6】

動画像を構成するフレーム画像を表す画像データを動画像送信装置から順次受信する動画像受信装置が、ユーザの入力操作に応じた操作データを前記動画像送信装置に送信するステップと、
前記動画像送信装置における前記操作データの受信から当該操作データに基づく前記フレーム画像の生成の開始までの時間を示す間隔データを前記動画像送信装置から受信するステップと、
前記間隔データに基づいて、次の前記操作データが送信されるタイミングを制御するステップと、
を含むことを特徴とする制御方法。

【請求項7】

動画像を構成するフレーム画像を動画像送信装置から順次受信するコンピュータに、
ユーザの入力操作に応じた操作データを前記動画像送信装置に送信する手順、
前記動画像送信装置における前記操作データの受信から当該操作データに基づく前記フレーム画像の生成の開始までの時間を示す間隔データを前記動画像送信装置から受信する手順、
前記間隔データに基づいて、次の前記操作データが送信されるタイミングを制御する手順、
を実行させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、動画像受信装置、制御方法及びプログラムに関する。

【背景技術】

【0002】

近年注目されているクラウドゲーミングサービスの技術では、端末に対するユーザの入力操作に応じた操作データが端末からクラウドサーバに無線で送信される。そして、クラウドサーバにおいて、当該操作データに基づいて、ゲームのプレイ状況を表すフレーム画像が生成される。そして、当該フレーム画像をエンコードした画像データがクラウドサーバから端末に無線で送信され、端末において当該画像データをデコードしたフレーム画像が表示される。この一連の処理が繰り返し実行されることで、ゲームのプレイ状況を表す動画像が端末に表示される。

【0003】

また、クラウドゲーミングサービスのなかには、端末からクラウドサーバへの操作データの送信とクラウドサーバにおけるフレーム画像の生成が非同期で行われ、また、操作データの送信周期とフレーム画像の生成周期とが異なるものがある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

操作におけるユーザの違和感を低減するために、クラウドサーバにおける操作データの受信からフレーム画像の生成開始までの時間はなるべく一定であることが望ましい。

【0005】

しかし、通信環境によっては端末から送信された操作データがクラウドサーバに到達するまでの時間が変動することがある。このことは、第４世代移動通信システム（４Ｇ）や第５世代移動通信システム（５Ｇ）のような帯域変動が大きい移動通信システムを利用した無線通信においては特に顕著となる。

【0006】

そのため、クラウドサーバにおける操作データの受信からフレーム画像の生成開始までの時間が許容範囲に収まらず、ユーザに違和感が生じることがあった。

【0007】

なおこのことはクラウドゲーミングサービスが提供される状況のみならず、端末に相当する動画像受信装置から送信される操作データをクラウドサーバに相当する動画像送信装置が受信して、当該動画像送信装置がフレーム画像を生成して当該動画像受信装置に送信する状況において一般的にあてはまる。

【0008】

本発明は上記実情に鑑みてなされたものであって、その目的の一つは、動画像受信装置での操作に応じて動画像送信装置で生成される動画像が動画像受信装置で表示される状況におけるユーザの違和感を低減できる動画像受信装置、制御方法及びプログラムを提供することにある。

【課題を解決するための手段】

【0009】

上記課題を解決するために、本発明に係る動画像受信装置は、動画像を構成するフレーム画像を表す画像データを動画像送信装置から順次受信する動画像受信装置であって、ユーザの入力操作に応じた操作データを前記動画像送信装置に送信する操作データ送信部と、前記動画像送信装置における前記操作データの受信から当該操作データに基づく前記フレーム画像の生成の開始までの時間を示す間隔データを前記動画像送信装置から受信する間隔データ受信部と、前記間隔データに基づいて、次の前記操作データが送信されるタイミングを制御する送信タイミング制御部と、を含む。

【0010】

本発明の一態様では、前記操作データに基づく前記フレーム画像の生成の開始に応じて前記動画像送信装置から送信される、当該操作データに対応付けられるパケットを受信するパケット受信部、をさらに含み、前記送信タイミング制御部は、前記パケットを受信したタイミングから次の前記操作データが送信されるまでの時間を制御する。

【0011】

この態様では、前記送信タイミング制御部は、前記パケットを受信したタイミングから次の前記操作データが送信されるまでの時間が第１の目標を達成するよう前記操作データが送信されるタイミングを制御する第１制御と、前記間隔データが示す時間が第２の目標を達成するよう前記操作データが送信されるタイミングを制御する第２制御と、を実行し、前記送信タイミング制御部は、前記第１制御において前記第１の目標が達成されたことに応じて、前記第２制御を開始してもよい。

【0012】

また、本発明の一態様では、前記送信タイミング制御部は、前記間隔データに基づいて、これから送信される前記操作データの送信周期を制御する。

【0013】

また、本発明の一態様では、前記動画像は、ゲームのプレイ状況に応じて生成される動画像であって、前記入力操作は、前記ゲームのプレイにおける入力操作である。

【0014】

また、本発明に係る制御方法は、動画像を構成するフレーム画像を表す画像データを動画像送信装置から順次受信する動画像受信装置が、ユーザの入力操作に応じた操作データを前記動画像送信装置に送信するステップと、前記動画像送信装置における前記操作データの受信から当該操作データに基づく前記フレーム画像の生成の開始までの時間を示す間隔データを前記動画像送信装置から受信するステップと、前記間隔データに基づいて、次の前記操作データが送信されるタイミングを制御するステップと、を含む。

【0015】

また、本発明に係るプログラムは、動画像を構成するフレーム画像を動画像送信装置から順次受信するコンピュータに、ユーザの入力操作に応じた操作データを前記動画像送信装置に送信する手順、前記動画像送信装置における前記操作データの受信から当該操作データに基づく前記フレーム画像の生成の開始までの時間を示す間隔データを前記動画像送信装置から受信する手順、前記間隔データに基づいて、次の前記操作データが送信されるタイミングを制御する手順、を実行させる。

【図面の簡単な説明】

【0016】

【図1】本発明の一実施形態に係るクラウドゲーミングシステムの全体構成の一例を示す図である。

【図2】本発明の一実施形態に係るクラウドサーバで発生する処理のタイミングの一例を模式的に示す図である。

【図3】本発明の一実施形態に係るクラウドゲーミングシステムで発生する通信の一例を模式的に示す図である

【図4】本発明の一実施形態に係るクラウドゲーミングシステムで行われるビットレート制御の一例を説明する説明図である。

【図5】本発明の一実施形態に係るクラウドゲーミングシステムで行われるパッドシンク制御の一例を説明する説明図である。

【図6】本発明の一実施形態に係るクラウドゲーミングシステムで実装される機能の一例を示す機能ブロック図である。

【図7】本発明の一実施形態に係るクラウドサーバにおいて行われる処理の流れの一例を示すフロー図である。

【図8】本発明の一実施形態に係るクラウドサーバにおいて行われる処理の流れの一例を示すフロー図である。

【図9】本発明の一実施形態に係るクラウドサーバにおいて行われる処理の流れの一例を示すフロー図である。

【図10】本発明の一実施形態に係るクラウドサーバにおいて行われる処理の流れの一例を示すフロー図である。

【発明を実施するための形態】

【0017】

以下、本発明の一実施形態について、図面を参照しながら説明する。

【0018】

図１は、本発明の一実施形態に係るクラウドゲーミングシステム１の全体構成の一例を示す図である。図１に示すように、本実施形態に係るクラウドゲーミングシステム１には、いずれもコンピュータを中心に構成された、クラウドサーバ１０と端末１２とが含まれている。

【0019】

クラウドサーバ１０と端末１２とは、第４世代移動通信システム（４Ｇ）や第５世代移動通信システム（５Ｇ）などの移動通信システムやインターネットなどを含むコンピュータネットワーク１４に接続されている。例えば、クラウドサーバ１０は、インターネットに接続されており、端末１２は、４Ｇや５Ｇなどの移動通信システムに接続されている。そして、クラウドサーバ１０と端末１２とはコンピュータネットワーク１４を介して互いに通信可能となっている。

【0020】

本実施形態に係るクラウドサーバ１０は、例えば、クラウドゲーミングサービスに係るゲームのプログラムを実行するサーバコンピュータである。

【0021】

図１に示すように、クラウドサーバ１０には、例えば、プロセッサ１０ａ、記憶部１０ｂ、通信部１０ｃ、エンコーダ・デコーダ部１０ｄが含まれている。

【0022】

プロセッサ１０ａは、例えばＣＰＵ等のプログラム制御デバイスであって、記憶部１０ｂに記憶されたプログラムに従って各種の情報処理を実行する。本実施形態に係るプロセッサ１０ａには、当該ＣＰＵから供給されるグラフィックスコマンドやデータに基づいてフレームバッファに画像を描画するＧＰＵ（Graphics Processing Unit）も含まれている。

【0023】

記憶部１０ｂは、例えばＲＯＭやＲＡＭ等の記憶素子やソリッドステートドライブ（ＳＳＤ）などである。記憶部１０ｂには、プロセッサ１０ａによって実行されるプログラムなどが記憶される。また、本実施形態に係る記憶部１０ｂには、プロセッサ１０ａに含まれるＧＰＵにより画像が描画されるフレームバッファの領域が確保されている。

【0024】

通信部１０ｃは、例えばコンピュータネットワーク１４を介して、端末１２などといったコンピュータとの間でデータを授受するための通信インタフェースである。

【0025】

エンコーダ・デコーダ部１０ｄは、例えばエンコーダとデコーダとを含む。当該エンコーダは、入力される画像をエンコードすることにより当該画像を表す画像データを生成する。また当該デコーダは、入力される画像データをデコードして、当該画像データが表す画像を出力する。

【0026】

本実施形態に係る端末１２は、例えばクラウドゲーミングサービスを利用するユーザが利用する、スマートフォンやタブレット端末などのコンピュータである。なお、端末１２が、通信ドングルを含んだテレビのような、通信ドングルを介してクラウドサーバ１０と通信可能な電子機器であっても構わない。

【0027】

図１に示すように、端末１２には、例えば、プロセッサ１２ａ、記憶部１２ｂ、通信部１２ｃ、表示部１２ｄ、操作部１２ｅ、センサ部１２ｆ、音声出力部１２ｇ、エンコーダ・デコーダ部１２ｈが含まれている。

【0028】

プロセッサ１２ａは、例えばＣＰＵ等のプログラム制御デバイスであって、記憶部１２ｂに記憶されたプログラムに従って各種の情報処理を実行する。

【0029】

記憶部１２ｂは、例えばＲＯＭやＲＡＭ等の記憶素子やソリッドステートドライブ（ＳＳＤ）などである。記憶部１２ｂには、プロセッサ１２ａによって実行されるプログラムなどが記憶される。

【0030】

通信部１２ｃは、例えばコンピュータネットワーク１４を介して、クラウドサーバ１０などといったコンピュータとの間でデータを授受するための通信インタフェースである。

【0031】

表示部１２ｄは、例えば液晶ディスプレイや有機ＥＬディスプレイなどの表示デバイスである。

【0032】

操作部１２ｅは、例えばプロセッサ１２ａに対する操作入力を行うための操作部材である。

【0033】

センサ部１２ｆは、例えば加速度や角速度を検出可能なモーションセンサなどといったセンサである。

【0034】

音声出力部１２ｇは、例えば音声データが表す音声等を出力するスピーカなどといった音声出力デバイスである。

【0035】

エンコーダ・デコーダ部１２ｈは、例えばエンコーダとデコーダとを含む。当該エンコーダは、入力される画像をエンコードすることにより当該画像を表す画像データを生成する。また当該デコーダは、入力される画像データをデコードして、当該画像データが表す画像を出力する。

【0036】

なお、端末１２が、タッチパネルを備えていてもよい。この場合、当該タッチパネルは、上述の表示部１２ｄと操作部１２ｅの両方の役割を担うこととなる。

【0037】

本実施形態では、クラウドゲーミングサービスにおけるゲームのプレイにおける入力操作をユーザが操作部１２ｅに対して行うと、端末１２は、当該入力操作に応じた操作データを生成して、当該操作データをクラウドサーバ１０に送信する。以下、当該操作データをパッドデータＰと呼ぶこととする。

【0038】

そして、クラウドサーバ１０は、受信したパッドデータＰに応じたゲーム処理を実行する。そして、クラウドサーバ１０は、当該ゲーム処理の結果に基づいて、当該ゲームのプレイ状況を表すフレーム画像であるプレイ画像を生成して、当該プレイ画像をクラウドサーバ１０のフレームバッファに描画する。本実施形態では、ゲーム処理及びプレイ画像の生成が繰り返し実行される。

【0039】

そして、クラウドサーバ１０は、フレームバッファに描画されたプレイ画像を取得して、当該プレイ画像をエンコードすることで、当該プレイ画像を表す画像データを生成する。そして、クラウドサーバ１０は、生成される画像データを端末１２に送信する。そして端末１２は、クラウドサーバ１０から受信した画像データをデコードして、当該デコードによって生成されるプレイ画像を表示部１２ｄに表示させる。

【0040】

以上のようにして本実施形態に係るクラウドサーバ１０は、ゲームのプレイ状況に応じて生成される動画像を、当該ゲームをプレイしているユーザが利用している端末１２にストリーミング配信する。

【0041】

図２は、本実施形態に係るクラウドサーバ１０で発生する処理のタイミングの一例を模式的に示す図である。

【0042】

本実施形態では例えば、初期状態において、端末１２が、所定の周期（例えば、４ミリ秒周期）で、当該タイミングに操作部１２ｅが受け付けた入力操作を示すパッドデータＰをクラウドサーバ１０に送信する。本実施形態に係るパッドデータＰには、パッドデータＰの送信順序を表す順序番号が関連付けられている。

【0043】

図２には、このようにして送信されるパッドデータＰ（０）～Ｐ（１０）のクラウドサーバ１０における受信タイミングが示されている。なお、図２では、受信したパッドデータＰに関連付けられている順序番号が、Ｐ（０）～Ｐ（１０）における括弧内の番号として示されている。なお、コンピュータネットワーク１４の通信品質によっては、クラウドサーバ１０が必ずしも４ミリ秒間隔でパッドデータＰを受信するとは限らない。

【0044】

クラウドサーバ１０では、所定の周期（例えば、１６ミリ秒周期）で、プレイ画像の生成が行われる。このとき、クラウドサーバ１０は、プレイ画像の生成開始のタイミングにおいて直近に受信したパッドデータＰ（最新のパッドデータＰ）が示す入力操作に基づいて、プレイ画像を生成して、生成されるプレイ画像をフレームバッファに描画する。

【0045】

図２に示されている期間Ｇが、プレイ画像の生成期間を表している。図２の例では、期間Ｇ（ｍ，ｎ）に、順序番号がｎであるパッドデータＰ（ｎ）に基づいて、順序番号がｍであるプレイ画像が生成されることとする。すなわち、図２では、パッドデータＰ（０）に基づくプレイ画像の生成期間がＧ（１，０）と示されている期間に相当する。また、パッドデータＰ（４）に基づくプレイ画像の生成期間がＧ（２，４）と示されている期間に相当する。また、パッドデータＰ（８）に基づくプレイ画像の生成期間がＧ（３，８）と示されている期間に相当する。

【0046】

なお、本実施形態では、端末１２におけるパッドデータＰの送信周期と、クラウドサーバ１０におけるプレイ画像の生成周期とは異なっている。例えば、初期状態では、プレイ画像の生成周期はパッドデータＰの送信周期の４倍となっている。そのため、クラウドサーバ１０が受信したすべてのパッドデータＰがプレイ画像の生成に用いられるわけではない。図２の例では、Ｐ（１）～Ｐ（３）、Ｐ（５）～Ｐ（７）、Ｐ（９）、Ｐ（１０）と示されているパッドデータＰについては、プレイ画像の生成には用いられない。

【0047】

また、本実施形態では、クラウドサーバ１０は、パッドデータＰに基づくプレイ画像の生成が開始されたタイミングに、プレイ画像の生成が開始されたことを示すパケットを端末１２に送信する。以下、当該パケットを、ビデオシンクパケット（Video Sync Packet：ＶＳＰ）と呼ぶこととする。本実施形態では、パッドデータＰに基づくプレイ画像の生成が開始されたタイミングに送信されるＶＳＰには、当該プレイ画像の順序番号（上述のｍ）、及び、当該パッドデータＰの順序番号（上述のｎ）が含まれている。このように、本実施形態に係るＶＳＰは、プレイ画像と１対１で対応付けられる。

【0048】

図２には、順序番号が１であるプレイ画像の生成が開始されるタイミングに、ＶＳＰ（１，０）が送信されることが示されている。また、順序番号が２であるプレイ画像の生成が開始されるタイミングに、ＶＳＰ（２，４）が送信されることが示されている。また、順序番号が３であるプレイ画像の生成が開始されるタイミングに、ＶＳＰ（３，８）が送信されることが示されている。

【0049】

また、本実施形態では例えば、フレームバッファへのプレイ画像の描画が終了すると、当該プレイ画像のエンコード、及び、当該エンコードによって生成される画像データの送信が実行される。なお、本実施形態に係るクラウドサーバ１０のフレームバッファはマルチバッファで構成されており、描画が終了したプレイ画像のエンコードと並行して、次のプレイ画像の描画を行えるようになっている。

【0050】

図２に示されている期間Ｓが、プレイ画像のエンコード及び画像データの送信が行われる期間に相当する。図２の例では、期間Ｓ（ｍ，ｎ）に、順序番号がｎであるパッドデータＰに基づいて生成された、順序番号がｍであるプレイ画像のエンコード及び当該エンコードによって生成される画像データの送信が行われることとする。すなわち、図２では、順序番号が１であるプレイ画像のエンコード、及び、当該エンコードによって生成される画像データの送信が行われる期間が、Ｓ（１，０）と示されている期間に相当する。また、順序番号が２であるプレイ画像のエンコード、及び、当該エンコードによって生成される画像データの送信が行われる期間が、Ｓ（２，４）と示されている期間に相当する。

【0051】

本実施形態では、パッドデータＰに基づいて生成されるプレイ画像をエンコードすることによって生成される画像データには、当該パッドデータＰの順序番号（上述のｎ）、及び、当該プレイ画像の順序番号（上述のｍ）が関連付けられている。

【0052】

また、本実施形態では、クラウドサーバ１０において、パッドデータＰの受信タイミングから当該パッドデータＰに基づくプレイ画像の生成開始タイミングまでの時間が測定される。そして、クラウドサーバ１０において、測定された当該時間を示す間隔データが生成される。そして、本実施形態では、当該プレイ画像に基づいて生成される画像データには、このようにして生成された間隔データが関連付けられる。

【0053】

図３は、順序番号が４であるパッドデータＰ（４）の送信から当該パッドデータＰ（４）に基づいて生成される画像データの受信までの間にクラウドサーバ１０と端末１２との間で発生する通信の一例を模式的に示す図である。図３の例では、図２においてＳ（２，４）と示されている期間に送信される画像データがＤ（２，４）と示されている。

【0054】

本実施形態に係る端末１２は、パッドデータＰを送信したタイミングから当該パッドデータＰに対応付けられるＶＳＰを受信したタイミングまでの時間であるパケット受信時間を特定する。以下、当該パケット受信時間を、図３に示すように、ＰａｄＶｓｐＲＴＴとも表現することとする。本実施形態に係る端末１２は、例えば、クラウドサーバ１０から受信するＶＳＰに含まれるパッドデータＰの順序番号に基づいて、ＰａｄＶｓｐＲＴＴを特定する。

【0055】

また、図３に示すように、端末１２におけるパッドデータＰの送信から当該パッドデータＰに基づいて生成される画像データの最初のセグメントの受信までの時間を、ＰａｄＦｉｒｓｔＦｒａｇＲＴＴと呼ぶこととする。

【0056】

また、端末１２におけるパッドデータＰの送信から当該パッドデータＰに基づいて生成される画像データの最後のセグメントの受信までの時間を、ＰａｄＦｒａｍｅＲＴＴと呼ぶこととする。

【0057】

また、端末１２における画像データの最初のセグメントの受信から当該画像データの最後のセグメントの受信までの時間を、ＴｒａｎｓｆｅｒＴｉｍｅと呼ぶこととする。以下、ＴｒａｎｓｆｅｒＴｉｍｅを、ＴＴと表現することとする。

【0058】

本実施形態に係る端末１２は、クラウドサーバ１０から受信する画像データに基づいてＴＴの値を特定する。ここで例えば、端末１２は、画像データに関連付けられているパッドデータＰの順序番号に基づいて、ＰａｄＦｒａｍｅＲＴＴの値、及び、ＰａｄＦｒａｍｅＲＴＴの値を特定してもよい。そして、端末１２は、ＰａｄＦｒａｍｅＲＴＴの値からＰａｄＦｉｒｓｔＦｒａｇＲＴＴの値を引くことでＴＴの値を特定してもよい。

【0059】

なお、本実施形態において、１つのプレイ画像を複数のスライスに分割した上で、スライス毎にエンコードや画像データの送信が行われるスライス転送方式が採用される場合には、１フレームあたりのスライス数を考慮したＴＴの特定が行われるようにしてもよい。例えば、１つのスライスに係る画像データの送信が終了してから次のスライスに係る画像データの送信が開始されるまでに所定の無通信時間が発生することを踏まえたＴＴの特定が行われるようにしてもよい。この場合、例えば、ＰａｄＦｒａｍｅＲＴＴの値からＰａｄＦｉｒｓｔＦｒａｇＲＴＴの値を引いた値からさらに、（１フレーム当たりのスライス数－１）に上述の無通信時間を乗じた値を引いた値が、ＴＴの値として特定されてもよい。

【0060】

また、図３に示すように、クラウドサーバ１０におけるパッドデータＰの受信タイミングから当該パッドデータＰに基づくプレイ画像の生成開始タイミングまでの時間を、ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅと呼ぶこととする。

【0061】

本実施形態に係る端末１２は、画像データに関連付けられている間隔データに基づいて、ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅを特定する。

【0062】

また、図２に示すように、端末１２におけるＶＳＰを受信したタイミングから次のパッドデータＰを送信したタイミングまでの時間を、ＤｉｆｆＰａｄＶｓｐと呼ぶこととする。

【0063】

以下、本実施形態に係るクラウドゲーミングシステム１で行われるビットレート制御について説明する。

【0064】

クラウドゲーミングシステム１によって提供されるクラウドゲーミングサービスでは、端末１２に表示される動画像はできるだけ高画質であることが望ましい。従って当該動画像を構成するプレイ画像に基づいて生成される画像データのデータサイズはできるだけ大きいことが望ましい。

【0065】

しかし本実施形態のような即時性が求められる無線通信では、操作におけるユーザの違和感を低減するために、画像データのデータサイズを小さくしてでもそれぞれのプレイ画像が滞りなく低遅延で端末１２に表示されるようにすることが重要となる。

【0066】

また、４Ｇや５Ｇなどの移動通信システムは、無線通信路（電波の強度）の品質にばらつきがある、混雑によって通信リソースの割り当てが行われないことがある、移動による基地局間のハンドオーバが発生する、などの事情がある。そのため、４Ｇや５Ｇなどの移動通信システムでは、帯域変動が大きく遅延が発生しがちである。

【0067】

また、Ｗｉ－Ｆｉ（登録商標）による通信環境ではアップリンク（本実施形態における端末１２からクラウドサーバ１０への通信）とダウンリンク（本実施形態におけるクラウドサーバ１０から端末１２への通信）とで通信品質がそれほど変わらない。一方、４Ｇや５Ｇなどの通信環境ではアップリンクとダウンリンクのうち一方の通信品質が良く他方の通信品質が悪いということが起こりがちである。

【0068】

そのため、４Ｇや５Ｇのような移動通信システムを利用した動画像の送信が行われる状況においてはフレーム画像が低遅延で端末１２に表示されるよう特に留意する必要がある。

【0069】

そこで、本実施形態では、図４に示されているビットレート制御を行うことで、遅延を考慮した適切なデータサイズの画像データがクラウドサーバ１０において生成されるようにした。

【0070】

図４は、本実施形態に係るクラウドゲーミングシステム１で行われるビットレート制御の一例を説明する説明図である。

【0071】

図４に示すように、本実施形態に係るビットレート制御では、帯域変動追従制御とパケ詰まり低減制御という２種類の制御が行われる。

【0072】

帯域変動追従制御では、まず、通信環境が多少悪くなっても画像データの欠落が発生しないよう、ジッタに対する余裕を持たせて、送信される動画像のフレームレート（ＦＰＳ）の逆数の半分に各フレームのＴＴの値が近づくようビットレートが制御される。例えば、送信される動画像のフレームレートが６０ｆｐｓである場合には、ＴＴが約８ミリ秒に近づくよう動画像の通信におけるビットレートが制御される。

【0073】

例えば、１／（ＦＰＳ×２）を目標値とし、ＴＴを現在値とし、ビットレートの値Ｒを操作量とするＰＩＤ制御によって、ビットレートの値Ｒが決定される。

【0074】

このことは、図４に、Ｒ＝ＰＩＤ（ＴＴ－（１／（ＦＰＳ×２）））と示されている。例えば、ＴＴ－（１／（ＦＰＳ×２））の値が大きいほど、Ｒの値は小さくなるよう制御される。また、ＴＴの値が１／（ＦＰＳ×２）の値よりも大きい場合は、Ｒの値は小さくなるよう制御され、ＴＴの値が１／（ＦＰＳ×２）の値よりも小さい場合は、Ｒの値は大きくなるよう制御される。

【0075】

また、帯域変動追従制御では、帯域変動に素早く追従するために、パケット受信時間（ＰａｄＶｓｐＲＴＴ）が急激に上昇したら、即座にビットレートのさらなる低減が実行される。

【0076】

例えば、ＰａｄＶｓｐＲＴＴの時系列データを所定のローパスフィルタに通すことで、細かいノイズの除去が行われる。以下、このようにして細かいノイズが除去されたＰａｄＶｓｐＲＴＴをＦｉｌＰａｄＶｓｐＲＴＴと表現することとする。このことは、図４に、ＦｉｌＰａｄＶｓｐＲＴＴ＝ＬＰＦ（ＰａｄＶｓｐＲＴＴ）と示されている。

【0077】

そして、後述するＥｓｔＢｔｍＬａｔｅｎｃｙの値を目標値とし、ＦｉｌＰａｄＶｓｐＲＴＴの値を現在値とし、ビットレート低減量の値Ｄを操作量とするＰＤ制御によって、ビットレート低減量の値Ｄが決定される。ここでは帯域変動に素早く追従するために、ＰＩＤ制御ではなく、ＰＤ制御が行われる。

【0078】

このことは、図４に、Ｄ＝ＰＤ（ＦｉｌＰａｄＶｓｐＲＴＴ－ＥｓｔＢｔｍＬａｔｅｎｃｙ）と示されている。例えば、ＦｉｌＰａｄＶｓｐＲＴＴ－ＥｓｔＢｔｍＬａｔｅｎｃｙの値が大きいほど、Ｄの値は大きくなるよう制御される。また、ＦｉｌＰａｄＶｓｐＲＴＴの値がＥｓｔＢｔｍＬａｔｅｎｃｙの値よりも大きい場合は、Ｄの値は大きくなるよう制御される。また、ＦｉｌＰａｄＶｓｐＲＴＴの値がＥｓｔＢｔｍＬａｔｅｎｃｙの値よりも小さい場合は、Ｄの値は小さくなるよう制御される。

【0079】

本実施形態では、ＥｓｔＢｔｍＬａｔｅｎｃｙの値は、初期状態では所定値が設定される。そして、ＰａｄＶｓｐＲＴＴの特定が行われる度に、最新のＰａｄＶｓｐＲＴＴ（ＰａｄＶｓｐＲＴＴ［ｎ］）と、直前のＰａｄＶｓｐＲＴＴ（ＰａｄＶｓｐＲＴＴ［ｎ－１］）との差の絶対値Ｖが特定される。そして、所与の値Ｎ、及び、所定の閾値Ｔｈ１に対して、絶対値ＶがＴｈ１未満である状態がＮ回連続して発生した際に、ＥｓｔＢｔｍＬａｔｅｎｃｙの値が更新される。例えば、ＥｓｔＢｔｍＬａｔｅｎｃｙの値が、絶対値ＶがＴｈ１未満である状態が連続して発生したＮ回におけるＰａｄＶｓｐＲＴＴの値の平均値に更新される。このことが図４では、ＥｓｔＢｔｍＬａｔｅｎｃｙ＝Ａｖｅｒａｇｅ（ＰａｄＶｓｐＲＴＴ[ｎ]～ＰａｄＶｓｐＲＴＴ［ｎ－Ｎ＋１］）と示されている。

【0080】

本実施形態ではこのようにして、帯域がある程度安定している状態におけるＰａｄＶｓｐＲＴＴの値がＥｓｔＢｔｍＬａｔｅｎｃｙの値として設定される。そのため、ＰａｄＶｓｐＲＴＴの現在値と安定した状態におけるＰａｄＶｓｐＲＴＴの値とが乖離すればするほど、決定されるＤの値は大きくなる。

【0081】

そして、本実施形態では、上述のようにして決定されるビットレートの値Ｒからビットレート低減量の値Ｄを引いた値Ｂが最終的なビットレートの値として特定される。ただし、決定された値Ｄが負である場合は、値Ｒの調整は行われず、値Ｒがそのまま値Ｂとして特定される。このことは、図４に、Ｂ＝Ｒ－Ｄ（ただし、Ｄ＜０の場合はＤ＝０）と示されている。

【0082】

帯域変動追従制御は、所定のタイミングで実行されるようにしてもよい。例えば、帯域変動追従制御は、所定の周期（例えば、１６ミリ秒周期）で実行されてもよい。また、帯域変動追従制御は、所定のイベントの発生（例えば、画像データの最後のセグメントの受信）に応じて実行されてもよい。

【0083】

また、本実施形態では、端末１２において、例えば、パッドデータＰの送信周期でＶＳＰの受信の監視が行われる。そして、直近の所定時間ｔ１におけるＶＳＰの受信数Ｍが所定の閾値Ｔｈ２よりも小さい場合は、帯域変動追従制御が中断される。例えば、直近１００ミリ秒における受信数Ｍが５未満である、あるいは、直近の８０ミリ秒にＶＳＰが受信されていない、などの条件を満たした場合に、帯域変動追従制御が中断される。

【0084】

そして、上述のビットレートの値Ｂに所定の割合ｒ（ｒは１未満）を乗じる処理である、パケ詰まり低減制御が実行される。なお、パケ詰まり低減制御で実行される処理は、値Ｂを小さくする処理であれば値Ｂに割合ｒを乗じる処理である必要はなく、例えば、値Ｂから所定値を引く処理が実行されてもよい。

【0085】

なお、本実施形態に係るパケ詰まり低減制御では、値Ｂが所定の下限ｂ１に達したら、値Ｂはそれよりも小さくならないよう制御される。

【0086】

パケ詰まり低減制御は、所定のタイミングで実行されるようにしてもよい。例えば、パケ詰まり低減制御は、所定の周期（例えば、パッドデータＰの送信周期）で実行されてもよい。また、パケ詰まり低減制御は、所定のイベントの発生（例えば、パッドデータＰの送信）に応じて実行されてもよい。

【0087】

本実施形態では、直近の所定時間ｔ１におけるＶＳＰの受信数Ｍが所定の閾値Ｔｈ２以上となった場合は、パケ詰まり低減制御が終了され、帯域変動追従制御が再開される。

【0088】

４Ｇや５Ｇなどの移動通信システムでは、再送やバッファリング制御が手厚く行われるため、基地局等の中継装置のバッファにデータが蓄積されやすい。例えば、４Ｇや５Ｇなどの通信環境でダウンリンクの通信が停止すると、基地局等の中継装置においてクラウドサーバ１０から送信されるデータがため込まれやすい。このようにしてため込まれたデータは、ダウンリンクの通信が正常に戻ると一気に送信される。

【0089】

ため込まれたデータが排出されることによる遅延の増大や、端末１２が一度に多くのデータを受信することによる端末１２の受信バッファのオーバーフローの発生は、端末１２における受信データの欠落の発生要因となる。本実施形態では、上述のようにしてパケ詰まり低減制御が実行されるようにすることで、通信環境の悪化によって通信不能状態となった際のコンピュータネットワーク１４におけるデータの滞留量（パケ詰まり）が低減され、受信データの欠落の発生の抑制が可能となる。

【0090】

本実施形態に係るクラウドサーバ１０は、送信される動画像のビットレートの値が、帯域変動追従制御によって決定される値Ｂや、パケ詰まり低減制御によって更新される値Ｂになるよう、プレイ画像のエンコードにおける圧縮率を変更する。このようにして本実施形態では、生成される画像データのデータサイズが制御される。

【0091】

以上のようにして、本実施形態によれば、遅延を考慮した適切なデータサイズの画像データがクラウドサーバ１０において生成されることとなる。

【0092】

また、本実施形態では、上述のように、パケット受信時間（ＰａｄＶｓｐＲＴＴ）に基づいて、クラウドサーバ１０によってこれから送信される画像データのデータサイズが制御される。このようにすることによって、急激なスループットの低下に対して即座に動画像のビットレートを低減させることができる。

【0093】

以下、本実施形態に係るクラウドゲーミングシステム１で行われるパッドシンク（Pad Sync）制御について説明する。

【0094】

クラウドゲーミングシステム１によって提供されるクラウドゲーミングサービスでは、操作におけるユーザの違和感を低減するために、クラウドサーバ１０における操作データの受信からプレイ画像の生成開始までの時間はなるべく一定であることが望ましい。

【0095】

しかし通信環境によっては端末１２から送信された操作データがクラウドサーバ１０に到達するまでの時間が変動することがある。このことは、４Ｇや５Ｇのような帯域変動が大きい移動通信システムを利用した無線通信においては特に顕著となる。

【0096】

そのため、クラウドサーバ１０における操作データの受信からプレイ画像の生成開始までの時間が許容範囲に収まらず、ユーザに違和感が生じることがあった。

【0097】

そこで、本実施形態では、図５に示されているパッドシンク制御を行うことで、端末１２での操作に応じてクラウドサーバ１０で生成される動画像が端末１２で表示される状況におけるユーザの違和感を低減できるようにした。

【0098】

図５は、本実施形態に係るクラウドゲーミングシステム１で行われるパッドシンク制御の一例を説明する説明図である。

【0099】

図５に示すように、本実施形態に係るパッドシンク制御では、第１制御と第２制御という２種類の制御が行われる。

【0100】

第１制御では、ＤｉｆｆＰａｄＶｓｐ（図２参照）を示す値が、所定値Ｔ１（例えば、パッドデータＰの送信周期の１．５倍である値Ｔ１）に近づくよう、パッドデータＰの送信タイミングが制御される。

【0101】

ここで例えば、値Ｔ１を目標値とし、ＤｉｆｆＰａｄＶｓｐの値を現在値とし、パッドデータＰの送信周期Ｔを操作量とするＰＤ制御によって、パッドデータＰの送信周期Ｔが決定される。このことは、図５に、Ｔ＝ＰＤ（ＤｉｆｆＰａｄＶｓｐ－Ｔ１）と示されている。例えば、（ＤｉｆｆＰａｄＶｓｐ－Ｔ１）の値が大きいほど、Ｔの値は小さくなるよう制御される。また、ＤｉｆｆＰａｄＶｓｐの値がＴ１の値よりも大きい場合は、Ｔの値は小さくなるよう制御され、ＤｉｆｆＰａｄＶｓｐの値がＴ１の値よりも小さい場合は、Ｔの値は大きくなるよう制御される。

【0102】

そして、決定される送信周期Ｔで、パッドデータＰが送信されるようにしてもよい。例えば、直近のパッドデータＰの送信タイミングから、決定される送信周期Ｔに相当する時間が経過したタイミングに、パッドデータＰが送信されるようにしてもよい。

【0103】

そして、例えば、ＤｉｆｆＰａｄＶｓｐの値が安定したと判定された際に、パッドシンク制御は、第１制御から第２制御に移行される。例えば、ＤｉｆｆＰａｄＶｓｐの値の変動を示す値（例えばＤｉｆｆＰａｄＶｓｐの－Ｔ１の絶対値）が所定の閾値Ｔｈ３未満である状態が所定時間ｔ２以上経過した、などといった所定の条件を満たした際に、パッドシンク制御は、第１制御から第２制御に移行される。

【0104】

第２制御では、クラウドサーバ１０におけるパッドデータＰの受信タイミングから当該パッドデータＰに基づくプレイ画像の生成開始タイミングまでの時間(ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅ)を示す値が、所定値Ｔ２（例えば、１ミリ秒）に近づくよう、第１制御では固定値だった値Ｔ１を可変にさせる。この場合における値Ｔ１を、Ｔ１＿ａｄｊと表現することとする。

【0105】

ここで例えば、値Ｔ２を目標値とし、ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅの値を現在値とし、値Ｔ１＿ａｄｊを操作量とするＰＤ制御によって、値Ｔ１＿ａｄｊが決定される。このことは、図５に、Ｔ１＿ａｄｊ＝ＰＤ（ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅ－Ｔ２）と示されている。そして例えば、値Ｔ１＿ａｄｊを目標値とし、ＤｉｆｆＰａｄＶｓｐの値を現在値とし、パッドデータＰの送信周期Ｔを操作量とするＰＤ制御によって、パッドデータＰの送信周期Ｔが決定される。このことは、図５に、Ｔ＝ＰＤ（ＤｉｆｆＰａｄＶｓｐ－Ｔ１＿ａｄｊ）と、示されている。まとめると、Ｔ＝ＰＤ（ＤｉｆｆＰａｄＶｓｐ－ＰＤ（ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅ－Ｔ２））となる。

【0106】

そして、以上のようにして決定される送信周期Ｔで、パッドデータＰが送信されるようにしてもよい。例えば、直近のパッドデータＰの送信タイミングから、決定される送信周期Ｔに相当する時間が経過したタイミングに、パッドデータＰが送信されるようにしてもよい。

【0107】

そして、例えば、ＤｉｆｆＰａｄＶｓｐの値が不安定になったと判定された際に、パッドシンク制御は、第２制御から第１制御に移行される。例えば、ＤｉｆｆＰａｄＶｓｐの値の変動を示す値（例えばＤｉｆｆＰａｄＶｓｐ－Ｔ１の絶対値）が所定の閾値Ｔｈ３以上である状態が発生した、などといった所定の条件を満たした際に、パッドシンク制御は、第２制御から第１制御に移行される。

【0108】

パッドシンク制御は、所定のタイミングで実行されるようにしてもよい。例えば、パッドシンク制御は、所定の周期（例えば、１６ミリ秒周期）で実行されてもよい。また、帯域変動追従制御は、所定のイベントの発生（例えば、画像データの最後のセグメントの受信）に応じて実行されてもよい。

【0109】

以上で説明したように、本実施形態では、パッドシンク制御によって、パッドデータＰの送信タイミングとプレイ画像の生成タイミングとを同期させることで低遅延化が達成できる。このようにして本実施形態によれば、端末１２での操作に応じてクラウドサーバ１０で生成される動画像が端末１２で表示される状況におけるユーザの違和感が低減される。

【0110】

また、本実施形態では、上述の第１制御と第２制御が実行されることで、ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅを安定化させることができる。

【0111】

以下、以上で説明した点を中心に、本実施形態に係るクラウドゲーミングシステム１の機能及び本実施形態に係るクラウドゲーミングシステム１で実行される処理についてさらに説明する。

【0112】

図６は、本実施形態に係るクラウドゲーミングシステム１で実装される機能の一例を示す機能ブロック図である。なお、本実施形態に係るクラウドゲーミングシステム１で、図６に示す機能のすべてが実装される必要はなく、また、図６に示す機能以外の機能が実装されていても構わない。

【0113】

図６に示すように、本実施形態に係るクラウドサーバ１０は、機能的には例えば、サーバ側制御データ記憶部２０、操作データ受信部２２、フレーム画像生成部２４、ＶＳＰ送信部２６、エンコード処理実行部２８、画像データ送信部３０、サーバ側トラフィック制御部３２、を含んでいる。本実施形態にクラウドサーバ１０は、動画像を構成するフレーム画像を表す画像データを順次送信する動画像送信装置としての役割を担う。

【0114】

サーバ側制御データ記憶部２０は、記憶部１０ｂを主として実装される。操作データ受信部２２、ＶＳＰ送信部２６、画像データ送信部３０は、通信部１０ｃを主として実装される。フレーム画像生成部２４、サーバ側トラフィック制御部３２は、プロセッサ１０ａを主として実装される。エンコード処理実行部２８は、プロセッサ１０ａ及びエンコーダ・デコーダ部１０ｄを主として実装される。

【0115】

以上の機能は、コンピュータであるクラウドサーバ１０にインストールされた、以上の機能に対応する指令を含むプログラムをプロセッサ１０ａで実行することにより実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してクラウドサーバ１０に供給されてもよい。

【0116】

また図６に示すように、本実施形態に係る端末１２は、機能的には例えば、端末側制御データ記憶部４０、操作データ生成部４２、操作データ送信部４４、ＶＳＰ受信部４６、画像データ受信部４８、デコード処理実行部５０、フレーム画像表示制御部５２、端末側トラフィック制御部５４、送信タイミング制御部５６、を含んでいる。本実施形態に端末１２は、動画像を構成するフレーム画像を表す画像データを順次受信する動画像受信装置としての役割を担う。

【0117】

端末側制御データ記憶部４０は、記憶部１２ｂを主として実装される。操作データ生成部４２は、プロセッサ１０ａ及び操作部１２ｅを主として実装される。操作データ送信部４４、ＶＳＰ受信部４６、画像データ受信部４８は、通信部１２ｃを主として実装される。デコード処理実行部５０は、プロセッサ１０ａ及びエンコーダ・デコーダ部１２ｈを主として実装される。フレーム画像表示制御部５２は、プロセッサ１２ａ及び表示部１２ｄを主として実装される。端末側トラフィック制御部５４、送信タイミング制御部５６は、プロセッサ１０ａを主として実装される。

【0118】

以上の機能は、コンピュータである端末１２にインストールされた、以上の機能に対応する指令を含むプログラムをプロセッサ１２ａで実行することにより実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介して端末１２に供給されてもよい。

【0119】

サーバ側制御データ記憶部２０は、本実施形態では例えば、上述のビットレートの値Ｂを示す制御データを記憶する。

【0120】

操作データ受信部２２は、本実施形態では例えば、ユーザの入力操作に応じた操作データ（例えば上述のパッドデータＰ）を受信する。操作データ受信部２２は、例えば、ゲームのプレイにおける入力操作に応じた操作データを受信する。

【0121】

フレーム画像生成部２４は、本実施形態では例えば、操作データ受信部２２が受信する操作データに基づいて、フレーム画像を生成する。フレーム画像生成部２４は、例えば、パッドデータＰに基づいて、ユーザによってプレイされているゲームのプレイ状況を表すプレイ画像を生成する。

【0122】

ＶＳＰ送信部２６は、本実施形態では例えば、操作データに基づくフレーム画像の生成の開始に応じて、当該操作データに対応付けられるパケットであるＶＳＰを端末１２に送信する。ＶＳＰ送信部２６は、例えば、フレーム画像の生成が開始されるタイミングに、ＶＳＰを送信する。

【0123】

エンコード処理実行部２８は、本実施形態では例えば、フレーム画像生成部２４が生成するフレーム画像をエンコードすることで、当該フレーム画像を表す画像データを生成する。エンコード処理実行部２８は、送信される動画像のビットレートを示す値がサーバ側制御データ記憶部２０に記憶されている制御データが示す値Ｂとなるような圧縮率を決定してもよい。そしてエンコード処理実行部２８は、決定される圧縮率でフレーム画像をエンコードすることで、画像データを生成してもよい。

【0124】

また、エンコード処理実行部２８は、上述の間隔データを生成してもよい。そして、エンコード処理実行部２８は、生成される画像データに、生成される間隔データを関連付けてもよい。

【0125】

画像データ送信部３０は、本実施形態では例えば、エンコード処理実行部２８が生成する画像データを端末１２に送信する。画像データ送信部３０は、上述の間隔データが関連付けられた画像データを端末１２に送信してもよい。

【0126】

サーバ側トラフィック制御部３２は、本実施形態では例えば、画像データ送信部３０によってこれから送信される画像データのデータサイズを制御する。

【0127】

上述のように、サーバ側トラフィック制御部３２は、端末１２が画像データの受信に要した時間を示す上述のＴＴの値に基づいて、画像データ送信部３０によってこれから送信される画像データのデータサイズを制御してもよい。

【0128】

また、上述のように、サーバ側トラフィック制御部３２は、上述のパケット受信時間（ＰａｄＶｓｐＲＴＴ）に基づいて、画像データ送信部３０によってこれから送信される画像データのデータサイズを制御してもよい。

【0129】

端末側制御データ記憶部４０は、本実施形態では例えば、上述のビットレートの値Ｂを示す制御データを記憶する。

【0130】

操作データ生成部４２は、本実施形態では例えば、ユーザの入力操作に応じた上述の操作データを生成する。操作データ生成部４２は、端末側制御データ記憶部４０に記憶されている制御データが関連付けられた操作データを生成してもよい。

【0131】

操作データ送信部４４は、本実施形態では例えば、操作データ生成部４２によって生成される操作データをクラウドサーバ１０に送信する。

【0132】

操作データ送信部４４は、制御データが関連付けられた操作データを送信してもよい。この場合、サーバ側トラフィック制御部３２は、操作データ受信部２２が受信する操作データに関連付けられている制御データを取得してもよい。そして、サーバ側トラフィック制御部３２は、サーバ側制御データ記憶部２０に記憶されている制御データを取得した制御データに更新してもよい。

【0133】

なお、操作データ送信部４４は、制御データを操作データに関連付けて送信する必要はなく、操作データとは独立に制御データをクラウドサーバ１０に送信してもよい。そして、操作データ受信部２２が、このようにして送信される制御データを受信してもよい。この場合、サーバ側トラフィック制御部３２は、サーバ側制御データ記憶部２０に記憶されている制御データを、操作データ受信部２２が受信した制御データに更新してもよい。

【0134】

ＶＳＰ受信部４６は、本実施形態では例えば、操作データに基づくフレーム画像の生成の開始に応じてクラウドサーバ１０から送信される、当該操作データに対応付けられるパケットであるＶＳＰをクラウドサーバ１０から受信する。

【0135】

画像データ受信部４８は、本実施形態では例えば、クラウドサーバ１０から送信される画像データを受信する。上述のように、画像データ受信部４８は、間隔データが関連付けられた画像データを受信してもよい。

【0136】

デコード処理実行部５０は、本実施形態では例えば、画像データ受信部４８が受信する画像データをデコードすることで、当該画像データが表すフレーム画像（例えばプレイ画像）を生成する。

【0137】

フレーム画像表示制御部５２は、本実施形態では例えば、デコード処理実行部５０によって生成されるフレーム画像（例えばプレイ画像）を表示部１２ｄに表示させる。

【0138】

端末側トラフィック制御部５４は、本実施形態では例えば、クラウドサーバ１０によってこれから送信される画像データのデータサイズを制御する。

【0139】

上述のように、端末側トラフィック制御部５４は、クラウドサーバ１０から送信される画像データの受信に要した時間を示す上述のＴＴの値に基づいて、画像データ送信部３０によってこれから送信される画像データのデータサイズを制御してもよい。

【0140】

また、上述のように、端末側トラフィック制御部５４は、端末１２が操作データを送信したタイミングから当該操作データに対応付けられるＶＳＰを受信したタイミングまでの時間である上述のパケット受信時間（ＰａｄＶｓｐＲＴＴ）を特定してもよい。そして、端末側トラフィック制御部５４は、パケット受信時間に基づいて、画像データ送信部３０によってこれから送信される画像データのデータサイズを制御してもよい。

【0141】

端末側トラフィック制御部５４は、上述の帯域変動追従制御を実行してもよい。そして、端末側トラフィック制御部５４は、端末側制御データ記憶部４０に記憶されている制御データを、帯域変動追従制御を実行することで決定される値Ｂを示す制御データに更新してもよい。

【0142】

また、上述の帯域変動追従制御で説明したように、端末側トラフィック制御部５４は、最新のＶＳＰの受信におけるパケット受信時間と、最新より前の少なくとも１回のＶＳＰの受信におけるパケット受信時間と、に基づいて、これから送信される画像データのデータサイズを制御してもよい。具体的には例えば、図４にＤ＝ＰＤ（ＦｉｌＰａｄＶｓｐＲＴＴ－ＥｓｔＢｔｍＬａｔｅｎｃｙ）と示されているような制御が実行されてもよい。

【0143】

また、端末側トラフィック制御部５４は、上述のパケ詰まり低減制御を実行してもよい。そして、端末側トラフィック制御部５４は、端末側制御データ記憶部４０に記憶されている制御データを、パケ詰まり低減制御を実行することで更新される値Ｂを示す制御データに更新してもよい。

【0144】

また、上述のパケ詰まり低減制御で説明したように、端末側トラフィック制御部５４は、所定の条件に基づいてＶＳＰの受信の失敗が継続していると判定される場合に、画像データ送信部３０によってこれから送信される画像データのデータサイズが小さくなるよう制御してもよい。例えば、上述のように、直近の所定時間ｔ１におけるＶＳＰの受信数Ｍが所定の閾値Ｔｈ２よりも小さい場合に、上述のパケ詰まり低減制御が実行されるようにしてもよい。

【0145】

また、端末側トラフィック制御部５４は、ビットレート制御のモードを示すビットレート制御モードフラグを保持してもよい。そして、例えば、ビットレート制御モードフラグの値が０である場合に帯域変動追従制御が実行され、ビットレート制御モードフラグの値が１である場合にパケ詰まり低減制御が実行されるようにしてもよい。

【0146】

送信タイミング制御部５６は、本実施形態では例えば、操作データの送信タイミングを制御する。

【0147】

送信タイミング制御部５６は、ＶＳＰを受信したタイミングから次の操作データが送信されるまでの時間を制御してもよい。例えば、送信タイミング制御部５６は、ＶＳＰを受信したタイミングから次の操作データが送信されるまでの時間が第１の目標を達成するよう操作データが送信されるタイミングを制御する第１制御を実行してもよい。例えば上述の例における、ＤｉｆｆＰａｄＶｓｐの値の変動を示す値が所定の閾値Ｔｈ３未満である状態が所定時間ｔ２以上経過した、などといった所定の条件を満たすことが、第１の目標に相当する。

【0148】

また、送信タイミング制御部５６は、間隔データに基づいて、次の操作データが送信されるタイミングを制御してもよい。例えば、送信タイミング制御部５６は、画像データ受信部４８が受信する画像データに関連付けられている間隔データに基づいて、次の操作データが送信されるタイミングを制御してもよい。

【0149】

ここで例えば、送信タイミング制御部５６は、間隔データが示す時間が第２の目標を達成するよう操作データが送信されるタイミングを制御する第２制御を実行してもよい。例えば上述の例における、ＰＲｅｃｖＧＳｔａｒｔＴｉｍｅの値が所定値Ｔ２（例えば、１ミリ秒）となることが、第２の目標に相当する。

【0150】

また、上述のように、送信タイミング制御部５６は、第１制御において上述の第１の目標が達成されたことに応じて、第２制御を開始してもよい。

【0151】

また、上述のように、送信タイミング制御部５６は、間隔データに基づいて、これから送信される操作データの送信周期Ｔを制御してもよい。

【0152】

また、画像データ送信部３０が、間隔データが関連付けられた画像データを送信する必要はない。画像データ送信部３０は、画像データとは独立に間隔データをクラウドサーバ１０に送信してもよい。そして、画像データ受信部４８が、このようにして送信される間隔データを受信してもよい。そして、送信タイミング制御部５６が、このようにしてクラウドサーバ１０から受信する間隔データに基づいて、次の操作データが送信されるタイミングを制御してもよい。

【0153】

また、送信タイミング制御部５６は、パッドシンク制御のモードを示すパッドシンク制御モードフラグを保持してもよい。そして、例えば、パッドシンク制御モードフラグの値が０である場合に第１制御が実行され、パッドシンク制御モードフラグの値が１である場合に第２制御が実行されるようにしてもよい。

【0154】

送信タイミング制御部５６は、例えば、上述のようにして決定される送信周期Ｔで送信命令を操作データ送信部４４に出力してもよい。そして、操作データ送信部４４は、送信命令の受付に応じて操作データをクラウドサーバ１０に送信してもよい。

【0155】

以下、本実施形態に係る端末１２で行われる、帯域変動追従制御における処理の流れの一例を、図７に例示するフロー図を参照しながら説明する。

【0156】

まず、端末側トラフィック制御部５４が、帯域変動追従制御に係る所定の実行タイミングが到来するまで待機する（Ｓ１０１）。

【0157】

所定の実行タイミングが到来すると、端末側トラフィック制御部５４が、画像データ受信部４８が受信した最新の画像データについてのＴＴの値を特定する（Ｓ１０２）。

【0158】

そして、端末側トラフィック制御部５４が、Ｓ１０２に示す処理で特定されたＴＴに基づいて、上述の値Ｒを特定する（Ｓ１０３）。

【0159】

そして、端末側トラフィック制御部５４が、最新のＰａｄＶｓｐＲＴＴの値を特定する
（Ｓ１０４）。

【0160】

そして、端末側トラフィック制御部５４が、最新のＰａｄＶｓｐＲＴＴの値と直前のＰａｄＶｓｐＲＴＴとの差の絶対値Ｖを特定する（Ｓ１０５）。

【0161】

そして、端末側トラフィック制御部５４が、絶対値ＶがＴｈ１未満である状態がＮ回連続して発生したか否かを確認する（Ｓ１０６）。

【0162】

絶対値ＶがＴｈ１未満である状態がＮ回連続して発生したことが確認された場合は（Ｓ１０６：Ｙ）、端末側トラフィック制御部５４が、ＥｓｔＢｔｍＬａｔｅｎｃｙの値を更新する（Ｓ１０７）。

【0163】

絶対値ＶがＴｈ１未満である状態がＮ回連続して発生していないことが確認された場合
（Ｓ１０６：Ｎ）、又は、Ｓ１０７に示す処理が実行された場合は、端末側トラフィック制御部５４が、ＦｉｌＰａｄＶｓｐＲＴＴの値を特定する（Ｓ１０８）。

【0164】

そして、端末側トラフィック制御部５４が、Ｓ１０８に示す処理で特定されたＦｉｌＰａｄＶｓｐＲＴＴの値と、ＥｓｔＢｔｍＬａｔｅｎｃｙの最新の値と、に基づいて、上述の値Ｄを特定する（Ｓ１０９）。

【0165】

そして、端末側トラフィック制御部５４が、Ｓ１０３に示す処理で特定された値Ｒと、Ｓ１０９に示す処理で特定された値Ｄと、に基づいて、値Ｂを特定する（Ｓ１１０）。

【0166】

そして、端末側トラフィック制御部５４が、設定されている値Ｂが、Ｓ１０９に示す処理で特定された値Ｂとなるよう、端末側制御データ記憶部４０に記憶されている制御データを更新して（Ｓ１１１）、Ｓ１０１に示す処理に戻る。

【0167】

以下、本実施形態に係る端末１２で行われる、パケ詰まり低減制御における処理の流れの一例を、図８に例示するフロー図を参照しながら説明する。

【0168】

まず、端末側トラフィック制御部５４が、パケ詰まり低減制御に係る所定の実行タイミングが到来するまで待機する（Ｓ２０１）。

【0169】

所定の実行タイミングが到来すると、端末側トラフィック制御部５４が、端末側制御データ記憶部４０に記憶されている制御データが示すビットレートの値Ｂを特定する（Ｓ２０２）。

【0170】

そして、端末側トラフィック制御部５４は、Ｓ２０２に示す処理で特定された値Ｂが下限ｂ１より小さいか否かを確認する（Ｓ２０３）。

【0171】

値Ｂが下限ｂ１よりも小さいことが確認された場合は（Ｓ２０３：Ｙ）、Ｓ２０１に示す処理に戻る。

【0172】

値Ｂが下限ｂ１よりも小さくないことが確認された場合は（Ｓ２０３：Ｎ）、端末側トラフィック制御部５４は、Ｓ２０２に示す処理で特定された値Ｂに所定の割合ｒ（ｒは１未満）を乗じた値を、新たな値Ｂとして特定する（Ｓ２０４）。

【0173】

そして、端末側トラフィック制御部５４は、設定されている値Ｂが、Ｓ２０４に示す処理で特定された値Ｂとなるよう、端末側制御データ記憶部４０に記憶されている制御データを更新して（Ｓ２０５）、Ｓ２０１に示す処理に戻る。

【0174】

以下、本実施形態に係る端末１２で行われる、ビットレート制御モードの切替処理の流れの一例を、図９に例示するフロー図を参照しながら説明する。

【0175】

まず、端末側トラフィック制御部５４が、ビットレート制御モードの切替処理に係る所定の実行タイミングが到来するまで待機する（Ｓ３０１）。

【0176】

ここで例えば、所定の周期（例えば、操作データの送信周期Ｔ）で、実行タイミングが到来するようにしてもよい。また、所定のイベントの発生（例えば、操作データの送信）に応じて実行タイミングが到来するようにしてもよい。

【0177】

所定の実行タイミングが到来すると、端末側トラフィック制御部５４が、直近の所定時間ｔ１におけるＶＳＰの受信数Ｍを特定する（Ｓ３０２）。

【0178】

そして、端末側トラフィック制御部５４が、現在のビットレート制御モードフラグの値を確認する（Ｓ３０３）。

【0179】

確認されたビットレート制御モードフラグの値が０である場合は、端末側トラフィック制御部５４が、Ｓ３０２に示す処理で特定された受信数Ｍが所定の閾値Ｔｈ２よりも小さいか否かを確認する（Ｓ３０４）。

【0180】

受信数Ｍが所定の閾値Ｔｈ２以上である場合は（Ｓ３０４：Ｎ）、Ｓ３０１に示す処理に戻る。

【0181】

受信数Ｍが所定の閾値Ｔｈ２よりも小さい場合は（Ｓ３０４：Ｙ）、端末側トラフィック制御部５４が、保持されているビットレート制御モードフラグの値を１に変更して（Ｓ３０５）、Ｓ３０１に示す処理に戻る。

【0182】

Ｓ３０３に示す処理で確認された現在のビットレート制御モードフラグの値が１である場合は、端末側トラフィック制御部５４が、Ｓ３０２に示す処理で特定された受信数Ｍが所定の閾値Ｔｈ２以上であるか否かを確認する（Ｓ３０６）。

【0183】

受信数Ｍが所定の閾値Ｔｈ２より小さい場合は（Ｓ３０６：Ｎ）、Ｓ３０１に示す処理に戻る。

【0184】

受信数Ｍが所定の閾値Ｔｈ２以上である場合は（Ｓ３０６：Ｙ）、端末側トラフィック制御部５４が、保持されているビットレート制御モードフラグの値を０に変更して（Ｓ３０７）、Ｓ３０１に示す処理に戻る。

【0185】

以下、本実施形態に係る端末１２で行われる、パッドシンク制御における処理の流れの一例を、図１０に例示するフロー図を参照しながら説明する。

【0186】

まず、送信タイミング制御部５６が、パッドシンク制御に係る所定の実行タイミングが到来するまで待機する（Ｓ４０１）。

【0187】

所定の実行タイミングが到来すると、送信タイミング制御部５６が、最新のＤｉｆｆＰａｄＶｓｐの値を特定する（Ｓ４０２）。

【0188】

そして、送信タイミング制御部５６が、現在のパッドシンク制御モードフラグの値を確認する（Ｓ４０３）。

【0189】

確認されたパッドシンク制御モードフラグの値が０である場合は、送信タイミング制御部５６が、Ｓ４０２に示す処理で特定されたＤｉｆｆＰａｄＶｓｐの値がＴ１になるように、新たな送信周期Ｔを決定する（Ｓ４０４）。

【0190】

そして、送信タイミング制御部５６が、最新のＤｉｆｆＰａｄＶｓｐの値と値Ｔ１との差の絶対値Ｖを特定する（Ｓ４０５）。

【0191】

そして、送信タイミング制御部５６が、絶対値Ｖが所定の閾値Ｔｈ３未満である状態が継続している時間を特定する（Ｓ４０６）。

【0192】

そして、送信タイミング制御部５６が、Ｓ４０６に示す処理で特定される時間が所定時間に達したか否かを確認する（Ｓ４０７）。

【0193】

所定時間に達したことが確認されなかった場合は（Ｓ４０７：Ｎ）、Ｓ４０１に示す処理に戻る。

【0194】

所定時間に達したことが確認された場合は（Ｓ４０７：Ｙ）、送信タイミング制御部５６は、保持されているパッドシンク制御モードフラグの値を１に変更して（Ｓ４０８）、Ｓ４０１に示す処理に戻る。

【0195】

Ｓ４０３に示す処理で確認された現在のパッドシンク制御モードフラグの値が１である場合は、送信タイミング制御部５６は、最新の画像データに関連付けられている間隔データの値を特定する（Ｓ４０９）。

【0196】

そして、送信タイミング制御部５６が、Ｓ４０９に示す処理で特定された間隔データの値に基づいて、新たな送信周期Ｔを決定する（Ｓ４１０）。

【0197】

そして、送信タイミング制御部５６が、最新のＤｉｆｆＰａｄＶｓｐの値と値Ｔ１との差の絶対値Ｖを特定する（Ｓ４１１）。

【0198】

そして、送信タイミング制御部５６が、特定される絶対値Ｖが所定の閾値Ｔｈ３以上であるか否かを確認する（Ｓ４１２）。

【0199】

絶対値Ｖが所定の閾値Ｔｈ３以上でない場合は（Ｓ４１２：Ｎ）、Ｓ４０１に示す処理に戻る。

【0200】

絶対値Ｖが所定の閾値Ｔｈ３以上である場合は（Ｓ４１２：Ｙ）、送信タイミング制御部５６は、保持されているパッドシンク制御モードフラグの値を０に変更して（Ｓ４１３）、Ｓ４０１に示す処理に戻る。

【0201】

なお、本発明は上述の実施形態に限定されるものではない。

【0202】

例えば、間隔データが、画像データに関連付けられるのではなく、ＶＳＰに関連付けられてもよい。

【0203】

また、フレーム画像生成部２４が、ビットレートに応じたデータサイズのフレーム画像を生成するようにしてもよい。

【0204】

また、本発明の適用範囲は、クラウドゲーミングシステム１には限定されない。

【0205】

また、本発明の適用範囲は、４Ｇや５Ｇなどの移動通信システムを含むコンピュータネットワーク１４には限定されない。本発明は、４Ｇや５Ｇなどの移動通信システムを介した無線通信ではなく、Ｗｉ－Ｆｉ（登録商標）による無線通信が行われるコンピュータネットワーク１４にも適用可能である。

【0206】

また、上記の具体的な文字列や数値及び図面中の具体的な文字列や数値は例示であり、これらの文字列や数値には限定されない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】