(57)【要約】  サーバ３０ｂの入力情報受信部３２はクライアント端末１０からユーザ操作に係る入力情報を受信し、入力情報記憶部４２に時刻とともに記録する。情報処理部３６は入力情報に基づき即時、情報処理を行い、生成された１次出力データをエンコード部３８がエンコードしてデータ送信部４０がクライアント端末１０に送信する。通信状況監視部５０が監視する通信状況に応じて、調整部５２は処理内容、エンコードパラメータを随時調整し調整履歴を調整履歴記憶部５４に時刻とともに記録する。リソースに余裕のある期間に、２次データ作成指示部３４からの指示により、記録しておいた入力情報、調整履歴を用いて再度、情報処理、エンコードを高品質で行い、作成された２次データを出力データ記憶部４６に格納する。
2014199412.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供サーバであって、
前記ユーザ操作に係る情報を入力情報として取得する入力情報受信部と、
前記入力情報の履歴を記憶する入力情報記憶部と、
前記入力情報受信部が取得した入力情報に基づき即時、情報処理を行うことにより、前記ユーザ操作に応じて送信すべき１次出力データを生成するとともに、前記入力情報記憶部から読み出した入力情報の履歴に基づき２度目の情報処理を行うことにより出力データを２次出力データとして生成し直す情報処理部と、
前記２次出力データを記憶する出力データ記憶部と、
前記情報処理部が生成した前記１次出力データ、または前記出力データ記憶部から読み出した前記２次出力データを、要求に応じてクライアント端末に送信するデータ送信部と、
を備えることを特徴とする出力データ提供サーバ。
【請求項２】
前記情報処理部は、出力データに含まれる画像の解像度およびビットレートの少なくとも一方を、前記１次出力データと前記２次出力データとで独立に設定して生成することを特徴とする請求項１に記載の出力データ提供サーバ。
【請求項３】
前記情報処理部は、前記１次出力データを生成中、前記クライアント端末との通信状況に応じて、当該１次出力データに含まれる画像の解像度およびビットレートの少なくとも一方を適応的に調整する一方、当該調整の有無に関わらず、所定の解像度およびビットレートで前記２次出力データを生成することを特徴とする請求項１または２に記載の出力データ提供サーバ。
【請求項４】
前記情報処理部は、前記１次出力データを生成中、前記クライアント端末との通信状況に応じて情報処理の内容を変化させるとともに当該変化の履歴を記録し、前記２度目の情報処理において、当該変化の履歴に基づき、同様に情報処理の内容を変化させることを特徴とする請求項１から３のいずれかに記載の出力データ提供サーバ。
【請求項５】
前記情報処理部は、前記１次出力データを生成中、情報処理の内容を変化させたら、前記２次出力データに含まれる画像に、変化の内容を表示することを特徴とする請求項４に記載の出力データ提供サーバ。
【請求項６】
前記情報処理部は、前記ユーザ操作に応じてゲームを進捗させる情報処理を行い、当該ユーザのクライアント端末に即時表示するためのゲームの画像データを前記１次出力データとして生成し、当該ゲーム終了後、前記２次出力データを生成して前記出力データ記憶部に格納することを特徴とする請求項１から５のいずれかに記載の出力データ提供サーバ。
【請求項７】
前記出力データ記憶部はさらに前記１次出力データを格納し、
前記データ送信部は、前記２次出力データが生成されるまでは、前記クライアント端末の要求に応じて前記１次出力データを前記出力データ記憶部から読み出して送信することを特徴とする請求項１から６のいずれかに記載の出力データ提供サーバ。
【請求項８】
クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供サーバであって、
前記ユーザ操作に係る情報を入力情報として取得する入力情報受信部と、
前記入力情報に基づき情報処理を行うことにより出力データを生成する情報処理部と、
前記出力データをクライアント端末に送信するデータ送信部と、を備え、
前記情報処理部は、前記クライアント端末との通信状況に応じて情報処理の内容および出力データの品質の少なくともいずれかを適応的に調整することを特徴とする出力データ提供サーバ。
【請求項９】
前記情報処理部は、前記ユーザ操作に応じてゲームを進捗させる情報処理を行い、前記通信状況が所定の基準より悪化したとき、当該ゲームのルールを緩和するように情報処理の内容を調整することを特徴とする請求項８に記載の出力データ提供サーバ。
【請求項１０】
前記情報処理部は、ユーザの操作タイミングが所定の判定時間内に検知されたか否かの判定処理を含むゲームを進捗させる情報処理を行い、前記通信状況が所定の基準より悪化したとき、悪化前より早いタイミングでの操作を促す表示を、出力データに含まれるゲームの画像に加えることを特徴とする請求項８に記載の出力データ提供サーバ。
【請求項１１】
前記情報処理部は生成した前記出力データを、適応的に調整した品質でエンコードして前記データ送信部に供給するとともに、当該出力データを前記調整の有無に関わらず所定の品質でエンコードし、後のクライアント端末への送信に備えて記憶装置に格納することを特徴とする請求項８に記載の出力データ提供サーバ。
【請求項１２】
前記情報処理部は、前記通信状況が所定の基準より悪化したとき、出力データに含まれる画像の解像度またはビットレートを、部分的に低下させることを特徴とする請求項８から１１のいずれかに記載の出力データ提供サーバ。
【請求項１３】
サーバが、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供方法であって、
前記ユーザ操作に係る情報を入力情報として取得するステップと、
前記入力情報の履歴をメモリに記憶するステップと、
前記入力情報に基づき即時、情報処理を行うことにより、前記ユーザ操作に応じて送信すべき１次出力データを生成し、クライアント端末に送信するステップと、
前記メモリから読み出した入力情報の履歴に基づき２度目の情報処理を行うことにより出力データを２次出力データとして生成し直し記憶装置に格納するステップと、
要求に応じて前記記憶装置から読み出した前記２次出力データをクライアント端末に送信するステップと、
を含むことを特徴とする出力データ提供方法。
【請求項１４】
サーバが、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供方法であって、
前記ユーザ操作に係る情報を入力情報として取得するステップと、
前記入力情報に基づき情報処理を行うことにより出力データを生成するステップと、
前記出力データをクライアント端末に送信するステップと、を含み、
前記出力データを生成するステップは、前記クライアント端末との通信状況に応じて情報処理の内容および出力データの品質の少なくともいずれかを適応的に調整することを特徴とする出力データ提供方法。
【請求項１５】
コンピュータに、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する機能を実現させるコンピュータプログラムであって、
前記ユーザ操作に係る情報を入力情報として取得する機能と、
前記入力情報の履歴をメモリに記憶する機能と、
前記入力情報に基づき即時、情報処理を行うことにより、前記ユーザ操作に応じて送信すべき１次出力データを生成し、クライアント端末に送信する機能と、
前記メモリから読み出した入力情報の履歴に基づき２度目の情報処理を行うことにより出力データを２次出力データとして生成し直し記憶装置に格納する機能と、
要求に応じて前記記憶装置からみ出した前記２次出力データをクライアント端末に送信する機能と、
を前記コンピュータに実現させることを特徴とするコンピュータプログラム。
【請求項１６】
コンピュータに、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する機能を実現させるコンピュータプログラムであって、
前記ユーザ操作に係る情報を入力情報として取得する機能と、
前記入力情報に基づき情報処理を行うことにより出力データを生成する機能と、
前記出力データをクライアント端末に送信する機能と、
を前記コンピュータに実現させ、
前記出力データを生成する機能は、前記クライアント端末との通信状況に応じて情報処理の内容および出力データの品質の少なくともいずれかを適応的に調整することを特徴とするコンピュータプログラム。
【請求項１７】
コンピュータに、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する機能を実現させるコンピュータプログラムを記録した記録媒体であって、
前記ユーザ操作に係る情報を入力情報として取得する機能と、
前記入力情報の履歴をメモリに記憶する機能と、
前記入力情報に基づき即時、情報処理を行うことにより、前記ユーザ操作に応じて送信すべき１次出力データを生成し、クライアント端末に送信する機能と、
前記メモリから読み出した入力情報の履歴に基づき２度目の情報処理を行うことにより出力データを２次出力データとして生成し直し記憶装置に格納する機能と、
要求に応じて前記記憶装置からみ出した前記２次出力データをクライアント端末に送信する機能と、
を前記コンピュータに実現させるコンピュータプログラムを記録したことを特徴とするコンピュータにて読み取り可能な記録媒体。
【請求項１８】
コンピュータに、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する機能を実現させるコンピュータプログラムを記録した記録媒体であって、
前記ユーザ操作に係る情報を入力情報として取得する機能と、
前記入力情報に基づき情報処理を行うことにより出力データを生成する機能と、
前記出力データをクライアント端末に送信する機能と、
を前記コンピュータに実現させ、
前記出力データを生成する機能は、前記クライアント端末との通信状況に応じて情報処理の内容および出力データの品質の少なくともいずれかを適応的に調整するコンピュータプログラムを記録したことを特徴とするコンピュータにて読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用して情報処理のサービスを提供する技術に関する。
【背景技術】
【０００２】
近年の情報処理技術の発展、ネットワークの充実化などにより、パーソナルコンピュータ、携帯端末などユーザが操作する装置の性能や使用環境によらず、様々な情報処理をサーバとの連携により実現させることが可能となっている。例えばユーザが操作する端末と、それに応じた情報処理を実施する情報処理装置とを分離することにより、簡素な構成の携帯端末などでも高度な情報を出力できるような技術が提案されている（例えば特許文献１参照）。クラウドコンピューティングのように、サーバが提供する様々なサービスをネットワークを介して利用することにより、高度な情報処理や膨大なデータ管理を、ユーザが置かれた環境によらず実現できるようにする技術的傾向は益々強くなっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−２０１５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のような技術にあっては、一つ情報処理装置内での処理と比較し、端末側で表示する画像など出力データの品質と、操作から出力までの応答性とを両立させることがさらに困難になる。すなわち端末／サーバ間の通信帯域という可変のパラメータが加わることにより、通信状況の変化によらず応答性を維持するためには、必然的に画質を十分低下させ、常時データサイズを抑えなければならなくなる。ゲームなど応答性が特に重要となる情報処理では、適正なタイミングで操作したにも関わらず操作ミスと判定されるなどの問題を回避するために応答性の維持が特に重要となり、出力データの品質を犠牲にしなければならないというジレンマが生じる。【０００５】
本発明はこのような課題に鑑みてなされたものであり、その目的は、サーバがネットワークを介して情報処理のサービスを提供する環境において、応答性と出力データの品質とを両立できる技術を提供することにある。
【課題を解決するための手段】
【０００６】
本発明のある態様は出力データ提供サーバに関する。この出力データ提供サーバは、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供サーバであって、ユーザ操作に係る情報を入力情報として取得する入力情報受信部と、入力情報の履歴を記憶する入力情報記憶部と、入力情報受信部が取得した入力情報に基づき即時、情報処理を行うことにより、ユーザ操作に応じて送信すべき１次出力データを生成するとともに、入力情報記憶部から読み出した入力情報の履歴に基づき２度目の情報処理を行うことにより出力データを２次出力データとして生成し直す情報処理部と、２次出力データを記憶する出力データ記憶部と、情報処理部が生成した１次出力データ、または出力データ記憶部から読み出した２次出力データを、要求に応じてクライアント端末に送信するデータ送信部と、を備えることを特徴とする。【０００７】
本発明の別の態様も出力データ提供サーバに関する。この出力データ提供サーバは、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供サーバであって、ユーザ操作に係る情報を入力情報として取得する入力情報受信部と、入力情報に基づき情報処理を行うことにより出力データを生成する情報処理部と、出力データをクライアント端末に送信するデータ送信部と、を備え、情報処理部は、クライアント端末との通信状況に応じて情報処理の内容および出力データの品質の少なくともいずれかを適応的に調整することを特徴とする。【０００８】
本発明のさらに別の態様は出力データ提供方法に関する。この出力データ提供方法は、サーバが、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供方法であって、ユーザ操作に係る情報を入力情報として取得するステップと、入力情報の履歴をメモリに記憶するステップと、入力情報に基づき即時、情報処理を行うことにより、ユーザ操作に応じて送信すべき１次出力データを生成し、クライアント端末に送信するステップと、メモリから読み出した入力情報の履歴に基づき２度目の情報処理を行うことにより出力データを２次出力データとして生成し直し記憶装置に格納するステップと、要求に応じて記憶装置から読み出した２次出力データをクライアント端末に送信するステップと、を含むことを特徴とする。【０００９】
本発明のさらに別の態様も出力データ提供方法に関する。この出力データ提供方法は、サーバが、クライアント端末とネットワークを介して接続し、当該クライアント端末におけるユーザ操作に係る情報を受信して情報処理を行い、その結果得られる出力データを、それを要求するクライアント端末に送信する出力データ提供方法であって、ユーザ操作に係る情報を入力情報として取得するステップと、入力情報に基づき情報処理を行うことにより出力データを生成するステップと、出力データをクライアント端末に送信するステップと、を含み、出力データを生成するステップは、クライアント端末との通信状況に応じて情報処理の内容および出力データの品質の少なくともいずれかを適応的に調整することを特徴とする。【００１０】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によると、ネットワークを介した情報処理のサービス提供を、状況に応じた最適な状態で行うことができる。
【図面の簡単な説明】
【００１２】
【図１】本実施の形態における情報処理システムの構成を示す図である。
【図２】本実施の形態におけるクライアント端末とサーバの構成をより詳細に示す図である。
【図３】本実施の形態においてゲーム実行期間にクライアント端末とサーバがゲームを進捗させる処理手順を示すフローチャートである。
【図４】本実施の形態において入力情報記憶部に格納される入力情報ファイルのデータ構造例を示す図である。
【図５】本実施の形態においてサーバが２次データを生成する処理手順を示すフローチャートである。
【図６】本実施の形態においてゲームプレイを再生する際のクライアント端末とサーバの処理手順を示すフローチャートである。
【図７】本実施の形態における、ゲーム実行期間に通信状況に応じて情報処理やエンコード処理を調整する機能をさらに設けたサーバの構成を詳細に示す図である。
【図８】本実施の形態においてサーバが、通信状況に応じた調整を行いながら情報処理を実施する処理手順を示すフローチャートである。
【図９】本実施の形態において調整部が行う処理内容の調整を定性的に説明するための図である。
【図１０】本実施の形態において２次データの生成時に調整内容を再現するときのサーバの処理手順を示すフローチャートである。
【図１１】本実施の形態において調整内容を表示した２次データの画像の例を示す図である。
【図１２】本実施の形態においてゲームを実行中、操作タイミングを早めるようにユーザに促す表示を追加したゲーム画像の例を示す図である。
【図１３】本実施の形態においてエンコードパラメータを調整する態様を説明するための図である。
【発明を実施するための形態】
【００１３】
図１は本実施の形態における情報処理システムの構成を示す。情報処理システム１においてクライアント端末１０ａ、１０ｂ、１０ｃは、それぞれネットワーク３を介してサーバ３０に接続可能に構成され、サーバ３０とデータの送受信を行う。サーバ３０はクライアント端末１０ａ、１０ｂ、１０ｃからの要求に応じて情報処理を実施し、その結果生成した出力データをクライアント端末１０ａ、１０ｂ、１０ｃに送信する。クライアント端末１０ａ、１０ｂ、１０ｃおよびサーバ３０は、ネットワーク３へ有線または無線で接続する。クライアント端末１０ａ、１０ｂ、１０ｃとサーバ３０との接続手法や情報処理の依頼、出力データの送受信に係る手続きには一般的な技術を適用することができる。
【００１４】
クライアント端末１０ａ、１０ｂ、１０ｃはそれぞれのユーザが操作する装置であり、ユーザが行った操作を入力情報としてサーバ３０へ送信し、それに応じた情報処理を要求するとともに、サーバ３０が情報処理を行った結果、生成した出力データを画像や音声として出力する。クライアント端末１０ａ、１０ｂ、１０ｃはタブレット、携帯電話、携帯端末、パーソナルコンピュータなど、一般的な装置や端末のいずれでもよい。なおネットワーク３に接続するクライアント端末１０ａ、１０ｂ、１０ｃ、サーバ３０の数は特に限定されない。以後、クライアント端末１０ａ、１０ｂ、１０ｃを総称してクライアント端末１０と呼ぶ。
【００１５】
クライアント端末１０がサーバ３０に要求する情報処理は特に限定されないが、以後の説明では主に、ゲームを実現する態様について述べる。つまりサーバ３０は、クライアント端末１０においてユーザが指定したゲームを起動し、クライアント端末１０におけるユーザの操作に従い当該ゲームを進捗させる。そしてそれに応じて生成したゲームの画像や音声などの出力データをクライアント端末１０に逐次送信する。クライアント端末１０では、サーバ３０から送信された出力データを順次、デコードするなどして出力可能な形態に変換し、画像や音声として出力する。
【００１６】
これにより、ユーザの操作に応じたゲーム画面、音声がクライアント端末１０から出力される。この構成は、サーバ３０が、ユーザの操作に応じて内容を変化させる動画像のデータをコンテンツデータとして送信するサービスを提供しているともいえる。ただしサーバ３０で実施する情報処理はゲームのほか、文書作成、画像描画、電子掲示板などのコミュニケーションツールなど、一般的な情報処理のいずれでもよい。また以後の説明では出力データを、時間軸に対し順次生成された画像フレーム列からなる動画のデータとするが、さらに音声データを含んでいてもよい。
【００１７】
サーバ３０はさらに、複数のクライアント端末１０に同じ画像データを送信することにより、複数のユーザが当該画像データを共有できるようにする。例えば実施する情報処理を、複数のユーザが参加可能なネットワークゲームとした場合、サーバ３０は複数のクライアント端末１０からそれぞれのユーザの操作に係る情報を逐次受信し、ゲームの進捗に反映させる。そして生成したゲームの画像データを全てのクライアント端末１０に送信することにより対戦型のゲームを実現できる。
【００１８】
このように本実施の形態では、その数によらずクライアント端末１０におけるユーザの操作内容を表す入力情報をサーバ３０が逐次受信し、リアルタイムで画像データを生成してクライアント端末１０に送信することにより、操作に応じた画像をクライアント端末１０に表示させることを基本とする。さらにサーバ３０は、ゲームに参加しているユーザのみならず、単にゲームを観戦したいユーザや後からゲームの様子を鑑賞したいユーザのクライアント端末１０へも、生成した画像データを送信する。このようにすることで、自分や他人のゲームプレイを時間や場所を問わず複数のユーザで共有することができる。
【００１９】
このような態様において、ユーザによる操作の頻度が高かったり、操作タイミングが得点に関わるようなゲームであるほど、ネットワーク３における通信状況に依存した応答性の変化がユーザに与えるストレスは大きくなる。また通信状況が悪化することにより画像が停止したりコマ落ちが生じたり、といった不都合が生じることがあり得る。この問題は、画像や圧縮後のデータを高品質化するほど顕在化する。
【００２０】
そこで本実施の形態では、ゲームの実行中は画像表示の応答性を最優先することによりプレイヤであるユーザの操作に係るストレスを軽減する。つまり画質をある程度抑えて通信状況の変動に対し頑健性を与える。一方、ゲーム終了後にその動画を公開する段階では操作がなく応答性が求められないことを利用し、画質を優先させる。これを実現するため、サーバ３０はゲーム終了後、当該ゲームを再度、実際のゲームプレイと同様に実行して画像データを生成し直す。これにより公開時の画像データに高い品質を保証する。以後の説明では、ユーザの操作に応じてリアルタイムで生成する画像データを「１次データ」、ゲーム終了後に生成し直す画像データを「２次データ」と呼ぶ。
【００２１】
図２はクライアント端末１０とサーバ３０の構成をより詳細に示している。なお後に述べるサーバ３０の変形例と区別するため、同図ではサーバ３０ａとしている。クライアント端末１０は、ユーザ操作を受け付ける入力部１２、受け付けた操作内容を入力情報としてサーバ３０へ送信する入力情報送信部１４、サーバ３０から送信された画像データを受信するデータ受信部１６、画像データをデコードするデコード部１８、画像を表示する表示部２０を含む。
【００２２】
サーバ３０ａは、クライアント端末１０からユーザによる入力情報を受信する入力情報受信部３２、クライアント端末１０から要求されたゲームなどの情報処理を実施する情報処理部３６、情報処理の結果として生成された画像のデータをエンコードするエンコード部３８、エンコード後の画像データをクライアント端末１０に送信するデータ送信部４０を含む。
【００２３】
サーバ３０ａはさらに、クライアント端末１０からの入力情報を入力時刻と対応づけて記憶する入力情報記憶部４２、ユーザがゲームをセーブして中断した場合に当該セーブに係る情報を記憶するセーブデータ記憶部４４、情報処理部３６およびエンコード部３８に２次データの作成を指示する２次データ作成指示部３４、および、１次データ、２次データの画像データを記憶する出力データ記憶部４６を含む。
【００２４】
図２および後述する図７において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ（Central Processing Unit）、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、記録媒体や記憶装置に格納されメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００２５】
クライアント端末１０の入力部１２は、ユーザが、サーバ３０に要求するゲームを指定したり、当該ゲームに対する操作を行ったりコマンドを入力したりするための入力手段であり、ゲームパッド、ボタン、タッチパネル、キーボード、マウス、ジョイスティックなど一般的な入力装置の少なくともいずれかによって実現する。入力情報送信部１４は、サーバ３０と一般的な手法により通信を確立し、入力部１２に対するユーザの操作内容を表す入力情報の信号を生成してサーバ３０に送信する。
【００２６】
サーバ３０の入力情報受信部３２は、クライアント端末１０から送信された入力情報を受信する。情報処理部３６は、入力情報受信部３２が受信した入力情報に従いゲームなどの情報処理を実施する。上述したように入力情報は１つまたは複数のクライアント端末１０から逐次送信され、情報処理部３６はそれに応じて情報処理をリアルタイムで進捗させる。クライアント端末１０の入力情報送信部１４からサーバ３０の入力情報受信部３２、情報処理部３６、と入力情報を即時伝送することにより、あたかもクライアント端末１０内部で情報処理を行っているかの如く情報処理を実施する。
【００２７】
具体的なプロトコルや入力信号のフォーマット、その解釈手法などには一般的なエミュレーションの技術を適用できるためここでは説明を省略する。入力情報受信部３２は情報処理部３６に供給した入力情報と同様の情報を、それぞれの入力時刻と対応づけた入力情報ファイルとして入力情報記憶部４２に格納しておく。入力情報ファイルはゲームプレイごとに作成し、各ゲームプレイの識別情報と対応づけておく。ここでゲームプレイの識別情報とは、２次データを作成したりクライアント端末１０への送信対象を特定するためにゲームプレイごとに一意に与える情報であり、サーバ３０ａ内で共有される。入力時刻とは、２次データを作成する際、ゲーム開始からの各操作のタイミングをトレースするためのものであるため、ゲーム開始からの経過時間、標準時を表す時刻、直前の操作からの時間間隔などのいずれでもよい。
【００２８】
情報処理部３６は、ゲーム開始から終了までのゲーム実行期間において、１次データとしてゲームの画像データを逐次作成しエンコード部３８に供給する。この画像データは、所定のフレームレートを有する一般的な動画像データでもよいし、静止画と動画が混在するような、不規則な時間間隔のデータでもよい。またゲームの終了は、ゲームの設定によって終了したいわゆるゲームオーバーの時点でもよいし、ユーザがゲームの途中でそれまでのデータをセーブして中断する操作を行った時点でもよい。
【００２９】
後者の場合、情報処理部３６は、セーブデータ、具体的にはゲームの到達点（セーブポイント）やその時点でのスコアなどを、ゲームプレイの識別情報と対応づけてセーブデータ記憶部４４に格納する。ユーザが、以前のセーブポイントからゲームを再開する要求を行ったら、情報処理部３６は、セーブデータ記憶部４４から該当するゲームプレイの識別情報に対応づけられたセーブデータを読み出し、そこからゲームの処理を開始する。このためクライアント端末１０における再開対象のゲームの指定情報に基づき、サーバ３０でゲームプレイの識別情報を特定するしくみを設けておく。
【００３０】
最も単純にはゲームプレイの識別情報自体を、プレイヤであるユーザやクライアント端末の識別情報、ゲームの名前、最終セーブ時刻など、ゲームプレイに固有かつ人が理解可能な情報で構成し、ユーザが直接選択できるようにすることが考えられる。ただしその他、様々な形式をとり得ることは当業者には理解されるところである。なおセーブポイントはそれまでのゲームプレイの終点であるとともに、そこから再開したゲームプレイの始点でもあるため、２次データ作成に備え、後者のゲームプレイの識別情報とも対応づけておく。
【００３１】
情報処理部３６はさらに、以前実施したゲームプレイを再現し、２次データとしてゲームの画像データを再度作成してエンコード部３８に供給する。このため２次データ作成指示部３４は、情報処理部３６およびエンコード部３８における処理能力、すなわちＣＰＵ時間やメモリ容量などのリソースに十分な余裕があるか否かを所定の基準により判断し、あると判断した場合に情報処理部３６およびエンコード部３８に２次データの作成開始を指示する。
【００３２】
２次データの作成処理は、基本的には２次データ作成対象のゲームプレイが終了した後に実施するが、リソースに余裕があれば、場合によっては実施中のゲームプレイについて並行して２次データを作成してもよい。また情報処理部３６やエンコード部３８の処理能力によっては、その他のゲームが並行して行われていてもよい。
【００３３】
２次データ作成指示部３４は２次データを未作成のゲームプレイの識別情報を内部メモリに保持しておく。そしてリソースに余裕があると判断したとき、ＦＩＦＯ(Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ)など所定の規則で２次データ作成対象のゲームプレイを選択して情報処理部３６へその識別情報を通知する。情報処理部３６は通知されたゲームプレイの識別情報に基づき、入力情報記憶部４２から対応する入力情報ファイルを読み出す。また該当するゲームプレイがセーブポイントからの再開である場合は、セーブデータ記憶部４４から対応するセーブデータを読み出す。
【００３４】
そしてセーブデータを読み出した場合は当該セーブポイントから、それ外の場合は最初から、ゲームの処理を開始する。開始後は、入力情報が記録された時刻に対応するタイミングで当該入力情報に応じた処理を行うことでゲームを再現する。ただし２次データ作成時は、当該データを即時、クライアント端末１０に送信する必要がないため、時間軸を所定の倍率に引き延ばすなどして時間をかけて処理を行ってもよい。また同じ理由で、１次データより高い画質で２次データを作成してもよい。例えば画像の空間解像度、時間解像度の少なくとも一方を１次データより高くしてもよい。
【００３５】
ただし設定によっては、必ずしも２次データの品質を１次データより高くしなくてもよい。例えば後述するように、１次データの作成時はゲームの応答性を優先し、通信状況によってその品質を調整するような場合、基本設定で品質を同じにしても、２次データ作成時はそのような調整を行わないことにより、実質的に品質の安定性、信頼性を向上させることができる。また、クライアント端末１０のディスプレイの想定サイズに応じて、２次データを複数の解像度で生成してもよい。
【００３６】
エンコード部３８は、情報処理部３６から供給された１次データまたは２次データをエンコードする。エンコード部３８においても、１次データでは応答性を優先させ、２次データではデータの品質を優先させる。例えば２次データ作成時には、１次データ作成時よりビットレートを大きくする。さらに、処理時間を長くかけることで品質とともに圧縮率を上げることもできる。情報処理部３６からの出力データを順次エンコードしていく場合、エンコードにかける時間に対応させて情報処理の時間軸を引き延ばすことで、出力データの供給タイミングを調整してもよい。
【００３７】
エンコード部３８は、エンコードした１次データを順次、データ送信部４０に供給するとともに、ゲームプレイの識別情報に対応づけて出力データ記憶部４６に格納する。さらに２次データをエンコードした際は、それをゲームプレイの識別情報に対応づけて出力データ記憶部４６に格納する。同じゲームプレイの２次データが作成されたことにより１次データが必要なくなった場合は、出力データ記憶部４６から当該１次データを削除してもよい。
【００３８】
なお情報処理部３６が生成した１次データを、直接、出力データ記憶部４６に格納してもよい。この場合、当該エンコード前の１次データを、エンコード部３８がビットレートを上げたり処理時間をかけたりしてエンコードし直し、２次データとして出力データ記憶部４６に格納してもよい。この処理も、エンコード部３８のリソースに余裕のある期間に行えばよい。このようにしても、ゲーム実行期間において応答性を優先させて送信された１次データより高品質、高圧縮率のデータを作成できる。さらに上述したように情報処理部３６がゲームを再現し、画像データを生成し直すことにより、より品質を向上させたものを３次データとして保存してもよい。
【００３９】
データ送信部４０はゲーム実行期間中、エンコード部３８から供給された１次データを順次、クライアント端末１０に転送する。具体的な転送処理には一般的な技術を適用できる。データ送信部４０はさらに、ゲーム終了後などにクライアント端末１０からの要求に応じて、出力データ記憶部４６から読み出した、要求されたゲームプレイの画像データを随時送信する。このとき、当該ゲームプレイの２次データが出力データ記憶部４６に格納済みであればそれを送信し、未格納であれば１次データを送信する。
【００４０】
クライアント端末１０のデータ受信部１６は、サーバ３０ａから送信された画像データを受信する。デコード部１８は、受信した画像データを復号、伸張し、画像として図示しないフレームメモリに展開する。送信された画像データが１次データか２次データかによってビットレート等、デコード時のパラメータが異なっていることが考えられるため、データに含まれるデコードパラメータの設定情報に従い、適宜デコード条件を切り替える。
【００４１】
表示部２０は、フレームメモリに展開された画像を表示する。したがって出力部２６は画像を表示する液晶ディスプレイ、有機ＥＬディスプレイ、プラズマディスプレイなどの一般的なディスプレイおよびそれらの装置を制御するコントローラを含む。さらに音声信号を音響として出力するスピーカ、イヤフォン、ヘッドフォンなどの音声出力機器を含めてもよい。
【００４２】
次にこの構成によって実現されるシステムの動作を説明する。図３はゲーム実行期間においてクライアント端末１０とサーバ３０ａがゲームを進捗させる処理手順を示すフローチャートである。同図では１つのクライアント端末１０とサーバ３０ａによる処理の手順を示しているが、上述の通り複数のクライアント端末１０が同時にサーバ３０ａと接続してよく、この場合、複数のクライアント端末１０が同様に処理を進める。またデータの生成、送信、出力などの各処理を１つのステップとして示しているが、処理内容によっては時間幅を有する場合があり、この場合は適宜並行して処理が進捗するものとする。後に説明する図５、６、８のフローチャートも同様である。
【００４３】
まずクライアント端末１０の入力部１２に対しユーザがゲーム名を指定するなどして処理の開始を要求する操作を行うと（Ｓ３０）、入力情報送信部１４は当該処理開始要求のための信号を作成しサーバ３０ａに送信する。この信号には、クライアント端末１０やユーザの識別情報、ゲーム名など必要な情報を含める。セーブポイントからの再開を要求する場合は、セーブ時刻など再開対象のゲームプレイを識別する情報を含める。
【００４４】
サーバ３０ａの入力情報受信部３２は、当該処理開始要求信号を受信すると、情報処理部３６に、それに対応するゲームの処理開始を指示するとともに、入力情報記憶部４２に格納する入力情報ファイルを初期化する（Ｓ３１）。具体的には、そのゲームプレイの識別情報に対応づけて、入力情報を記録するための新規ファイルを準備する。入力情報をゲーム開始からの経過時間に対応づけて記録する場合、入力情報受信部３２は図示しないタイマを起動させる。
【００４５】
情報処理部３６は、指定されたゲームのプログラムを起動するなどして処理を開始する。そして作成された初期画像のデータをエンコード部３８がエンコードし、データ送信部４０がクライアント端末１０へ送信する（Ｓ３２）。クライアント端末１０のデータ受信部１６が初期画像のデータを受信すると、デコード部１８がそれをデコードし、表示部２０が出力することにより、初期画像がクライアント端末１０に表示される（Ｓ３４）。なお初期画像のデータが動画など時間的な幅を有するデータである場合、Ｓ３２における送信処理はストリーム転送でよく、クライアント端末１０は受信したデータを順次デコードし表示する。
【００４６】
そのようにして表示された初期画像を見ながら、ユーザが入力部１２に対しコマンド入力などの指示入力を行ったら、入力情報送信部１４はその都度、当該入力情報をサーバ３０ａに送信する（Ｓ３６）。サーバ３０ａが当該情報を受信すると、入力情報受信部３２が情報処理部３６にその情報を通知することにより、情報処理部３６は通知された入力情報に対応するゲームの処理を実施する（Ｓ３８）。入力情報受信部３２はさらに、入力情報記憶部４２に準備した入力情報ファイルに、時刻とともにその入力情報を記録する（Ｓ４０）。例えば自らのタイマで計測したゲーム開始からの経過時間と入力情報を対応づけて記録する。
【００４７】
サーバ３０ａのエンコード部３８は、情報処理部３６におけるゲーム処理の結果として生成された画像のデータをエンコードする（Ｓ４２）。データ送信部４０は、このようにして生成されたエンコード後の画像データを１次データとしてクライアント端末１０に送信する（Ｓ４４）。クライアント端末１０のデータ受信部１６が画像データを受信すると、デコード部１８がそれをデコードし（Ｓ４８）、表示部２０が表示することにより、ユーザ操作に応じたゲーム画面がクライアント端末１０に表示される（Ｓ５０）。Ｓ３６からＳ５０の処理を繰り返すことにより、ユーザ操作に応じて画面が適宜更新されゲームが進捗する態様を実現できる。
【００４８】
図４は入力情報記憶部４２に格納される入力情報ファイルのデータ構造例を示している。入力情報ファイル７０は、時間フィールド７２および入力値フィールド７４を含み、クライアント端末１０においてゲーム開始後になされた操作の内容を表す入力情報を、時刻に対応づけて記録する。時間フィールド７２に記録する入力時刻は、同図の場合、ゲーム開始からの経過時間となっているが、操作の時系列が明らかであればその形式は限定されない。
【００４９】
また入力値フィールド７４は同図の場合、ユーザの操作内容を識別番号で記録している。例えば、クライアント端末１０の入力部１２におけるボタンやＧＵＩなどの各操作手段に識別番号を付与しておき、押下された操作手段を入力値フィールド７４に記録する。ただし押下が継続した時間や操作方向などさらに詳細な操作を記録すべき場合もあるため、入力値フィールド７４における入力情報の記録形式は図示するものに限らない。入力情報受信部３２は、ゲーム実行期間において、クライアント端末１０から入力情報が送信される都度、入力情報ファイル７０の行を追加していくことにより入力情報を記録していく。
【００５０】
図５はサーバ３０ａが２次データを生成する処理手順を示すフローチャートである。サーバ３０ａの２次データ作成指示部３４は、情報処理部３６およびエンコード部３８におけるリソースを監視し、２次データを作成するのに十分な空きがあるかどうかを判定する（Ｓ５２）。この処理は実際には、２次データ作成指示部３４が定期的に確認してもよいし、空きが基準値以上発生した時点で情報処理部３６やエンコード部３８から通知を受けるようにしてもよい。
【００５１】
空きがない状態であればそのまま待機する（Ｓ５２のＮ）。空きが発生したら（Ｓ５２のＹ）、２次データ作成指示部３４は、２次データが未作成のゲームプレイの識別情報を内部メモリなどから選択し、情報処理部３６およびエンコード部３８に通知することにより２次データの作成を指示する。情報処理部３６は、当該ゲームプレイの始点を表すセーブデータがセーブデータ記憶部４４に格納されている場合はそれを読み出す（Ｓ５４のＹ、Ｓ５６）。さらにセーブデータの有無にかかわらず、当該ゲームプレイの識別情報に対応づけられた入力情報ファイルを入力情報記憶部４２から読み出す（Ｓ５８）。
【００５２】
そしてセーブデータを読み出した場合（Ｓ５４のＹ）は当該セーブポイントから、セーブデータがなかった場合（Ｓ５４のＮ）は最初から、ゲーム処理を再現する（Ｓ６０）。この際、入力情報ファイルに記録された入力情報に従い、同じタイミングで同じ操作がなされたものとしてゲームを進捗させる。その結果として画像のデータが作成される都度、エンコード部３８は当該データをエンコードしていく（Ｓ６２）。
【００５３】
Ｓ６０およびＳ６２で作成、エンコードする２次データは、ゲーム実行期間に作成された１次データとは異なる解像度やビットレートでよい。例えばＳ６０において、ＳＤ（Stanndard Definition）、ＨＤ（High Definition）、フルＨＤなど、データ送信先のクライアント端末で想定されるディスプレイの解像度に合わせた複数のサイズで画像を生成してもよい。またＳ６２において複数の方式でエンコードしてもよい。エンコード部３８はエンコードした２次データを出力データ記憶部４６格納する（Ｓ６４）。このとき必要に応じて、同じゲームプレイを表す１次データを出力データ記憶部４６から削除する。
【００５４】
図６はゲームプレイを再生する際のクライアント端末１０とサーバ３０ａの処理手順を示すフローチャートである。まず鑑賞者などのユーザがクライアント端末１０の入力部１２に対し、再生対象のゲームプレイを指定するなどして再生を要求する操作を行うと（Ｓ７０）、入力情報送信部１４は当該再生要求のための信号を作成しサーバ３０ａに送信する。ユーザがゲームプレイを指定するために、公開中のゲームプレイの選択画面を表すウェブページのデータなどをサーバ３０ａから送信しておいてもよい。選択画面には、各ゲーム画面のサムネイルなどとともに、ゲーム名、プレイヤ名、プレイ日時などを表示することにより、ユーザが選択しやすくなる。
【００５５】
再生要求信号には、自装置のディスプレイの解像度や要求するエンコード方式などをさらに含めてもよい。再生要求を受信したサーバ３０ａの入力情報受信部３２は、選択されたゲームプレイの識別情報を特定し、データ送信部４０に通知する。データ送信部４０は、当該ゲームプレイの２次データが出力データ記憶部４６に格納されているか否かを確認する（Ｓ７２）。２次データが格納されている場合は（Ｓ７２のＹ）、当該２次データを読み出し、要求元のクライアント端末１０に送信する（Ｓ７４）。この際、複数の解像度やエンコード方式でデータが格納されている場合は、クライアント端末１０からの要求に対応したデータを選択して送信する。
【００５６】
２次データが格納されていない場合は（Ｓ７２のＮ）、１次データを読み出し要求元のクライアント端末１０に送信する（Ｓ７６）。クライアント端末１０のデータ受信部１６がデータを受信すると、デコード部１８がそれをデコードし（Ｓ７８）、表示部２０が表示することにより、選択したゲームプレイが動画などの形態でクライアント端末１０に表示される（Ｓ８０）。図３、５、および６に示した処理手順によって、ゲーム実行期間は応答性を優先させ、ゲームプレイ再生時には画質を優先させることができる。
【００５７】
このように本実施の形態では、同じゲームプレイの画像でありながら、状況に応じて品質を独立に設定できる。この利点をさらに積極的に活用し、ゲーム実行時は通信状況に応じて画像データの品質を適応的に調整するようにしてもよい。これにより応答性を担保した状態で、通信状況が良好であれば高い品質で画像を表示することができる。この場合でも上述のとおり２次データを作成すれば、それ以後の再生においては実行期間の通信状況は影響しない。
【００５８】
図７はゲーム実行期間において通信状況に応じて情報処理やエンコード処理を調整する機能をさらに設けたサーバ３０の構成を詳細に示している。同図のサーバ３０ｂは、通信状況に応じて画像データの品質を調整するのみならず、ゲームの内容自体を調整する。このようにすることで、通信状況の悪化によりユーザ操作がサーバ３０側で遅れて検知されユーザに不利に働くといった状況の発生を抑制することができる。なお同図において、図２に示したサーバ３０ａと同じ機能を有するブロックには同じ符号を付して、適宜説明を省略する。またクライアント端末１０の構成は図２に示したものと同様でよいため、ここでは図示を省略している。
【００５９】
サーバ３０ｂは、入力情報受信部３２、２次データ作成指示部３４、情報処理部３６、エンコード部３８、データ送信部４０、入力情報記憶部４２、セーブデータ記憶部４４、出力データ記憶部４６を含む。これらの機能ブロックは基本的に、図２のサーバ３０ａに含まれる各機能ブロックと同様に機能する。ただし情報処理部３６は、通信状況に応じて情報処理部３６やエンコード部３８における処理を調整する調整部５２を含む。サーバ３０ｂはさらに、クライアント端末１０との通信状況を監視する通信状況監視部５０、実施された調整内容を時間に対応づけて記録する調整履歴記憶部５４を含む。
【００６０】
通信状況監視部５０は、ゲーム実行期間においてクライアント端末１０との通信状況を監視する。通信状況を示すパラメータは様々、考えられるが、例えば、通信帯域の空き状況、パケットロス率、遅延時間、遅延時間のばらつき、といったパラメータの少なくともいずれかを監視する。パケットロス率は、入力情報送信などのためにクライアント端末１０から送出されたパケットのうち、サーバ３０ｂへ到達しなかったパケットの割合を表す。例えばクライアント端末１０において送出順にパケットに番号をつけておき、サーバ３０ｂにおいて当該番号の抜けを検知して失われたパケット数をカウントすることによりパケットロス率を算出する。
【００６１】
遅延時間は、クライアント端末１０におけるユーザ操作の入力時刻、あるいは当該入力情報を送信するためのパケットの送出時刻と、当該入力情報をサーバ３０ｂが受信した時刻との差である。例えば、ユーザ操作の入力時刻やパケットの送出時刻のタイムスタンプを入力情報とともにサーバ３０に送信し、サーバ３０において各入力情報を受信した時刻と比較することによって遅延時間が得られる。遅延時間のばらつきは、当該遅延時間の履歴をサーバ３０で保持しておき、その変化の標準偏差を所定の時間間隔で算出するなどして求められる。
【００６２】
通信状況監視部５０は、上記パラメータのうち監視対象として設定されたパラメータの値を所定の時間間隔で求め、その結果を情報処理部３６の調整部５２に通知する。調整部５２は、通知された値に基づき調整の必要性を判断し、情報処理部３６における処理の内容をあらかじめ定めた規則に則り調整する。あるいはエンコード部３８における処理に用いるエンコードパラメータの調整後の値を決定してエンコード部３８に通知する。情報処理部３６は調整部５２による調整のもとゲーム処理を進捗させる。エンコード部３８は、調整部５２からの通知に従いエンコードパラメータを変化させてエンコードを実施する。
【００６３】
ここで処理内容の調整とは、例えばゲームのルールを緩和させるなど、ゲームの内容自体を調整することである。例えばゲームパッドの押下が適正なタイミングでなされたときに得点が与えられるゲームにおいて、適正なタイミングとする判定基準の時間を延長する。これにより本来の適正なタイミングで押下したにも関わらずクライアント端末１０からサーバ３０ｂまでの通信遅延によりサーバ３０ではタイミングを逸したと判定されユーザが不利益を被るのを防止する。
【００６４】
本実施の形態はクライアント端末１０における入力をネットワークを介してサーバ３０ｂで受け付けて解釈するという構成を有するため、ユーザ操作のタイミングが結果に影響するようなゲームでは特に、通信状況によってゲームの状況が変化しかねない。上記のようにユーザ操作のタイミングがサーバ３０ｂで遅れて検知される以外に、画像表示までに時間がかかり結果として次の操作が遅れてしまうことも考えられる。そこで上述とおり、適正なタイミングと判定する基準時間を通信状況に応じて調整することは特に有効である。ただし調整部５２が行う処理内容の調整はこれに限らず、例えば戦闘ゲームで敵の数を減らしたり、キャラクタ移動時に目的地へ到達しやすくしたり、といったように、単に難易度を下げる調整でもよい。さらなる具体例については後述する。
【００６５】
またエンコードパラメータとは、代表的にはビットレートや符号化方式などであるが、エンコード処理において調整可能なパラメータであり、処理時間の短縮に効果があるものであればよい。処理内容の調整、エンコードパラメータの調整のいずれの場合でも、具体的な調整対象は情報処理部３６が実施する処理の内容、つまりゲームの内容や状況ごとに異なっていてよく、ゲームの作成者などがあらかじめ決定してよい。また調整の是非に加え、どの調整を行うか、その調整の度合いなどを通信状況に応じて適応的に変化させてよい。
【００６６】
調整部５２は決定した調整内容を、ゲームプレイの識別情報ごとに、調整時刻と対応づけて調整履歴記憶部５４に格納する。ここで記録する調整時刻は、入力情報記憶部４２に格納される入力情報ファイルと同様、ゲーム開始からの経過時間でもよいし、標準時などの時刻でもよい。調整部５２は、情報処理部３６がゲームを再現して２次データを作成する際、調整履歴記憶部５４から対応する調整履歴をゲームプレイの識別情報に基づいて読み出し、ゲーム実行期間と同じ調整を行う。これにより、調整がなされたことも含めてゲームの様子を再現し、２次データを作成する。
【００６７】
実施した調整のうち再現する必要のないものについては２次データ作成時の調整対象から除外する。例えばエンコードのビットレートを下げることにより、画質を犠牲にして送信速度を優先させた場合、高画質を基本とする２次データにおいてはあえてビットレートを下げなくてもよい。このように２次データ作成時に再現する必要のない調整については、調整履歴記憶部５４に記録しなくてよい。
【００６８】
次に図７の構成を有するサーバ３０ｂの動作を説明する。図８はサーバ３０ｂが、通信状況に応じた調整を行いながら情報処理を実施する処理手順を示すフローチャートである。このフローチャートを図３のフローチャートにおけるＳ３８の処理に組み入れることにより、調整機能を実現しつつゲームを進捗させることができる。まず通信状況監視部５０から通信状況を示すパラメータが逐次入力されると、調整部５２はそれをあらかじめ設定された基準と比較し、調整が必要か否かを判定する（Ｓ８２）。調整内容ごとに基準を設定しておき、それに応じてなすべき調整内容を選択するようにしてもよい。
【００６９】
なお調整要否の判定は、通信状況監視部５０が行ってもよい。また通信状況が悪化しても、それによって生じるパケットロスや通信時間のばらつきを既存の技術により隠蔽でき、ゲームに与える影響が小さいと判定できる範囲にあっては、調整を行わなくてもよい。例えばパケットロスに対しては、ストリーミングを冗長化することにより失われたパケットを復元できる。また通信時間のばらつきに対しては、クライアント端末１０にバッファを設けることによりばらつき時間を吸収できる。これらの機構を別途設け、調整の前段階として活用してもよい。
【００７０】
Ｓ８２の判定の結果、調整の必要がなければ（Ｓ８２のＮ）、調整せずにゲームを継続処理する（Ｓ９０）。調整が必要であり（Ｓ８２のＹ）、なすべき調整内容がビットレートの低減などエンコード処理に係る場合は（Ｓ８４のＹ）、エンコードパラメータの調整後の値など具体的な調整内容とともにエンコード部３８へ調整要求を行う（Ｓ８６）。調整対象がエンコード処理に係るものでない場合は（Ｓ８４のＮ）、情報処理部３６における処理の内容自体を調整する（Ｓ８８）。この処理は実際には、緩和対象のルールに対する設定値を切り替えたり、調整用に準備した別のプログラムへ処理を分岐したりする処理でよい。
【００７１】
そしてそのように調整された状態で、情報処理部３６はゲームを継続処理する（Ｓ９０）。なお図８のフローチャートはエンコードパラメータの調整および処理内容の調整のいずれか一方を実施する例であるが、設定によっては両方を実施してもよい。上述のように通信状況を示すパラメータに対し複数の基準を設け、悪化が進むに従い調整対象を増やしていくようにしてもよい。なおＳ８８において、情報処理部３６が生成するゲーム画像の解像度を小さくしてもよい。
【００７２】
図９は調整部５２が行う処理内容の調整を定性的に説明するための図である。同図は、クライアント端末１０におけるボタン等の押下に対し、適正なタイミングと考えられる判定基準の時間（以下、「判定時間」と呼ぶ）が逐次設定され、当該判定時間内に押下が検知されれば得点が与えられるようなゲームを想定している。このようなゲームとして、ゴルフクラブの振り上げ量と打球のタイミングによってボールの飛距離が決まるゴルフゲーム、楽曲に合わせてゲームパッドを押下することにより打楽器の演奏技術を競うゲーム、ゲームパッドの押下により仮想世界の敵に打撃を与える格闘ゲームなどが考えられる。
【００７３】
同図は、同じ時間範囲の、ゲームの流れ（上段、中段）および通信状況（下段）を表している。横軸は経過時間を示しており、左から右に進むほど前の時刻を表す。まず上段は、調整をしない標準状態のゲームの流れ６０であり、白抜きの矩形で表す時間範囲に判定時間６２ａ、６２ｂが設定されるとする。一方、ゲーム実行時、通信状況を表すパラメータＰが最下段のグラフ６６に示すように変化したとする。ここで値Ｐｃは、それを超えると調整を必要とする判定基準である。時刻ＴＡ、ＴＢにおいて、パラメータＰは判定基準ＰｃをそれぞれＡ、Ｂだけ超過している。
【００７４】
このとき調整部５２は、まず時刻ＴＡにおいて、超過分Ａに対応する調整量Ａ’だけ判定時間を延長する。結果としてその直後のタイミングで到来した判定時間６２ａは、中段のゲームの流れ６３に示すように、元の判定時間６２ａと同時刻に始まり、調整量Ａ’だけ延長された判定時間６４ａに調整される。同様に時刻ＴＢにおいて、判定時間を超過分Ｂに対応する調整量Ｂ’だけ延長する。結果として、その直後のタイミングで到来した判定時間６２ｂは、それと同時刻に始まり、調整量Ｂ’だけ延長された判定時間６４ｂに調整される。なお各判定時間の始点についても、超過分Ａ、Ｂに対応する調整量だけ遅延させてもよい。
【００７５】
これにより、標準状態ではミスと判定される太線矢印のタイミングで押下が検知されても、得点が与えられるようになる。結果として、クライアント端末１０では適正なタイミングで押下したにも関わらず、通信状況の悪化によりサーバ３０での検知が遅れたためミスと判定されてしまった、といった不具合の発生を抑えることができる。判定基準ＰｃからのパラメータＰの超過分Ａ、Ｂに対し、調整量Ａ’、Ｂ’を決定するための規則は、パラメータＰとして選択する変数やゲームの内容等に応じてあらかじめ設定しておく。
【００７６】
例えば通信状況を示すパラメータＰを遅延時間とした場合、調整量Ａ’、Ｂ’はそれぞれ、判定基準Ｐｃからの超過時間Ａ、Ｂと等しくしてもよいし、さらに定数を加算したり乗算したりしてもよい。あるいは判定基準Ｐｃを超過したら一律に同じ調整量で調整するようにしてもよい。同図は判定時間の長さを調整するのみであったが、通信状況の悪化がユーザの不利に働かないようにする、という思想の元では、ゲームの内容によって調整内容も様々考えられる。
【００７７】
例えばレースゲームにおいて、コーナーでのハンドル操作のタイミングが遅れても、調整後の判定時間内であればコースアウトとしないように車の動きを調整するなど、判定時間の調整とそれに付随する処理の変更を同時に行ってもよい。なお同図は、通信状況が悪化するほど大きくなるパラメータＰを用いた例であったが、逆の特性を有するパラメータＰを用いる場合は当然、判定基準Ｐｃを下回ったときに調整する。
【００７８】
図１０は２次データの生成時に調整内容を再現するときのサーバ３０ｂの処理手順を示すフローチャートである。このフローチャートを図５のフローチャートにおけるＳ６０の処理に組み入れることにより、調整処理を考慮した２次データを生成することができる。まず図５で説明したように２次データの作成指示がなされると、情報処理部３６の調整部５２は、作成対象のゲームプレイの実行中、再現が必要な調整がなされたか否かを確認する（Ｓ９４）。ゲーム実行時、再現が必要な調整の履歴のみを調整履歴記憶部５４に格納しておくことにより、調整がなされたか否かは調整履歴の有無によって判定できる。
【００７９】
上述のように２次データにおいて再現が必要な調整とは、典型的にはゲームのルールを緩和するなど処理の内容自体の調整であるが、設定によってはエンコードパラメータの調整を再現することも考えられる。再現が必要な調整がなされていなければ（Ｓ９４のＮ）、調整部５２による調整は行わず、情報処理部３６がゲームの処理を実施する（Ｓ９６）。調整がなされていたら（Ｓ９４のＹ）、調整部５２は、調整履歴記憶部５４から調整履歴を読み出し、情報処理部３６によるゲーム処理中、実際の調整と同じタイミングで同じ調整を行う（Ｓ９８）。例えば図９に示した調整がなされていた場合、２次データ作成処理におけるゲーム開始後、時刻ＴＡ、ＴＢに対応する時刻で、判定時間を調整量Ａ’、Ｂ’だけ延長する調整を行う。
【００８０】
調整を行う以外、情報処理部３６およびエンコード部３８の動作は、図５で説明したのと同様でよい。これにより、ルール緩和などの調整も含め１次データを正確にトレースしつつ、高品質な２次データを作成できる。なお調整履歴記憶部５４に格納する調整履歴は、図９の例では調整量Ａ’、Ｂ’といった具体的な調整量を調整時刻ＴＡ、ＴＢなどと対応づけたものでもよいし、通信状況を示すパラメータＰの時間変化でもよい。後者の場合、ゲームの再現処理時に調整部５２が再び調整量を導出して調整処理を再現する。
【００８１】
このように通信状況に応じてゲームのルールを緩和させた場合、その再生画面を見たユーザは、本来ミスと判定されるべきタイミングの操作が適正と判定されることなどに違和感を覚えることが考えられる。そこで調整部５２は２次データ生成時に、調整を再現するのに加えて、調整内容を表す文字情報などを画像内に表示してもよい。図１１は調整内容を表示した２次データの画像の例を示している。
【００８２】
画像９０はゴルフゲームの一場面を表し、２次データを用いた再生時にクライアント端末１０の表示部２０に表示される。この例ではゲーム実行時、ユーザの操作によりスイングしたゴルフクラブがボールに当たるタイミングとして適正と判定される判定時間を２０ミリ秒延長する調整がなされている。この場合、２次データ生成時には、調整後の判定時間で打球タイミングの判定をしたときに、調整内容を示すウィンドウ９２が所定時間、表示されるように画像を生成する。同図の例では「ネットワークタイミング調整２０ミリ秒」なる文字情報が、ゲーム画面上に重ねて表示されている。
【００８３】
これにより、プレイヤ以外のユーザもゲーム実行時の状況を知ることができ、打球タイミングとその判定結果との対応に疑問を感じずにすむ。なお調整内容の表示は、１次データに対しても行ってよい。つまりゲームプレイ中のユーザや、それをリアルタイムで鑑賞しているユーザに対しても、ルールが緩和中である旨、どの程度の緩和がなされているか、といった情報を開示してもよい。また調整内容は、文字情報のみならず、図形で表したり、その色や動きで表したりしてもよい。
【００８４】
ここで述べたルールを緩和させる態様は、プレイヤであるユーザにはクライアント端末１０において通常通り操作を行わせ、通信状況に応じてサーバ３０ｂ側で判定時間を調整するものであった。一方、判定時間は変化させず、通信状況に応じてユーザの操作自体を調整するように促すことも考えられる。具体的には、入力情報がサーバ３０ｂに到達するまでの時間を見越して操作タイミングを早めるようにユーザに促す表示を行う。
【００８５】
図１２はゲームを実行中、操作タイミングを早めるようにユーザに促す表示を追加したゲーム画像の例を示している。画像７５は図１１と同様のゴルフゲームの一場面を表し、ゲーム実行中にクライアント端末１０の表示部２０に表示される。
【００８６】
このゴルフゲームでは、ゴルフクラブのバックスイング、ダウンスイングの一連の動きに対し、スイングの方向切り替えおよび打球のタイミングを、ゲームパッドの押下操作によって決定する。そして押下タイミングの目安として、現時点のクラブの振り幅を表すゲージ７６を表示している。ゲージ７６の左端の「１００」と示された位置がフルスイング時の振り幅、ゲージ右端近傍の矢印で示された位置がジャストミート時の振り幅を表し、ゴルフクラブの動きに合わせてゲージ中の指標の端辺が、バックスイング期間は左方向へ、ダウンスイング期間は右方向へ移動する。
【００８７】
フルスイングによって飛距離を長くしたい場合、標準状態では、フルスイングの振り幅でゲームパッドを押下し、ジャストミートの振り幅で再び押下するのが望ましい。一方、通信状況が悪化した場合はサーバ３０ｂでの検知までの時間を考慮して、押下のタイミングをそれぞれ早める必要がある。そこで調整部５２は、スイングの方向切り替え操作を行う好適なタイミングを示すマーク７８ａ、打球操作を行う好適なタイミングを示すマーク７８ｂをゲージ７６に付加する。
【００８８】
つまりマーク７８ａのタイミングでユーザがスイングの方向を切り替えるように操作すると、サーバ３０ではフルスイングのタイミングで当該操作が検知される。またマーク７８ｂのタイミングで打球操作を行うと、サーバ３０ではジャストミートのタイミングで当該操作が検知される。これにより判定時間を変化させずに、通信状況の悪化をユーザによる操作タイミングの調整によって吸収することができる。このようにしてもゲームの難易度自体はあまり変化しないため、結果として、通信状況の悪化によるユーザの不利益の発生を抑えることができる。なおこの態様では判定時間の調整を行っていないため、２次データの画像はマーク７８ａ、７８ｂを表示しない通常のものとしてよい。
【００８９】
図１３は図８のフローチャートにおけるＳ８６の処理によって、エンコードパラメータを調整する態様を説明するための図である。最も単純な例として、調整が必要な状況が生じた際は、画像全体のビットレートを一律に低下させることが考えられる。一方、１つのゲーム画像であっても、領域によって情報の質や注目度が異なる場合、当該領域ごとに画質を制御することも考えられる。図１３の例ではこのように、領域によってビットレートを変化させる態様を示している。
【００９０】
画像８０はカーレースゲームの一場面を表し、仮想世界のコース上を走る車８２をユーザが操作する。調整の必要がない場合は画像全体を同じビットレートでエンコードするのに対し、調整時は、注目度が高いと考えられる車８２の前方、すなわち画面の中央付近の所定範囲の領域８４のビットレートはそのままとし、その他の領域のビットレートを低下させる。調整部５２は領域８４の位置や大きさに係る情報、その他の領域の調整後のビットレートをエンコード部３８に通知することによりエンコードを実施させる。
【００９１】
これによりゲーム実行時に、通信状況の悪化に応じてクライアント端末１０に送信すべき画像のデータサイズを小さくしながらも、ユーザの操作に影響を与える可能性が高い領域については画質を維持することができる。通信状況の悪化の度合いに応じて、領域８４のサイズを変化させたり、その他の領域のビットレートをさらに調整したりしてもよい。また場合によっては領域８４についても、所定の範囲内でビットレートを低下させてもよい。また構図の変化に応じて、ビットレートを保つ領域８４を移動させてもよい。
【００９２】
図１３はレースゲームの例であったがその他のゲームであっても同様に、ビットレートを可能な限り維持したい領域をゲームの内容に応じてあらかじめ決定し、調整部５２が調整時に参照できるようにしておく。ビットレートを維持すべき領域として、注目度が高い領域、重要な情報が含まれている領域、画質の低下によってユーザの操作に支障を来す領域などが考えられる。
【００９３】
具体的には、ロールプレイングゲームなどユーザがキャラクタや視点を動かすゲームの場合は当該キャラクタを含む所定範囲の領域、ＦＰＳ（Fist Person Shooting）またはＴＰＳ(Third Person Shooting）における照準近傍の所定範囲の領域などが考えられる。そのほか、現在のステージやスコア、テキストチャットなどの文字情報を表示する領域、ゲーム中に表示するポップアップウィンドウの領域、ユーザ操作により仮想の視点が移動した際、新たに視野に入った領域、などが考えられる。
【００９４】
以上述べた本実施の形態によれば、クライアント端末におけるユーザ操作に応じてサーバ側でゲーム画像を生成しそのデータをクライアント端末に送信するシステムにおいて、ユーザ操作の内容をサーバ側で記録しておく。そして記録したユーザ操作の内容に基づき適当なタイミングでゲームを再度実行してゲーム画像を生成し直し保存しておくことにより、複数のユーザで当該画像を共有したり再確認したりする際に用いる。これにより、初回実行時と再実行時とで、同じゲームの様子でありながら、画像の品質などを独立に制御することができ、状況に応じた最適な条件でサービスを提供できる。
【００９５】
具体的には、初回実行時は応答性を優先して解像度やエンコード時のビットレートを低く抑え、再実行時には時間的な制約がないことから、初回実行時より高い解像度やビットレートとする。これにより、初回実行時にプレイヤが望む応答性と、ゲーム再生時に鑑賞者が望む画像の質とを両立させることができる。また再実行時には、エンコードの処理時間より圧縮率を優先させることにより、画像データのサイズ自体を小さくすることができ、再生時の通信帯域やサーバにおける記憶領域の節約にも寄与する。
【００９６】
また初回実行時は、通信状況に応じてゲームのルールや生成する画像の解像度などの処理内容、ビットレートなどのエンコードパラメータを調整する。これにより、通信状況の悪化によって応答性が悪くなり得点が伸びないといったプレイヤの不利益を軽減することができる。また通信状況の悪化に備え、解像度やビットレートを最初から小さくする必要がなくなるため、通信状況が良好な状態にあっては、ゲーム実行時であっても高画質の表示が可能となる。初回実行時に解像度やビットレートを調整しても、再実行によって画像を作成し直すことにより、再生時の画質には影響しない。結果として、通信状況によらず、プレイヤのニーズ、鑑賞者のニーズの双方に対応できるシステムを実現できる。
【００９７】
以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００９８】
例えば図７で示したサーバ３０ｂは、通信状況に応じた調整機能と、２次データの作成機能の双方を備えていたが、前者のみを備えたサーバとしてもよい。このようなサーバであっても、ゲーム実行時に、通信状況の悪化による応答性の低下を防止しながら、可能な限り高画質の画像が表示できる。
【符号の説明】
【００９９】
１  情報処理システム、  １０  クライアント端末、  １２  入力部、  １４  入力情報送信部、  １６  データ受信部、  １８  デコード部、  ２０  表示部、  ３０  サーバ、  ３２  入力情報受信部、  ３４  ２次データ作成指示部、  ３６  情報処理部、  ３８  エンコード部、  ４０  データ送信部、  ４２  入力情報記憶部、  ４４  セーブデータ記憶部、  ４６  出力データ記憶部、  ５０  通信状況監視部、  ５２  調整部、  ５４  調整履歴記憶部。
【産業上の利用可能性】
【０１００】
以上のように本発明は情報処理システム、プロキシサーバ、クラウドコンピューティングなどの情報処理サービスに利用可能である。
【図１】
2014199412.tif 000003
【図２】
2014199412.tif 000004
【図３】
2014199412.tif 000005
【図４】
2014199412.tif 000006
【図５】
2014199412.tif 000007
【図６】
2014199412.tif 000008
【図７】
2014199412.tif 000009
【図８】
2014199412.tif 000010
【図９】
2014199412.tif 000011
【図１０】
2014199412.tif 000012
【図１１】
2014199412.tif 000013
【図１２】
2014199412.tif 000014
【図１３】
2014199412.tif 000015
【国際調査報告】
2014199412.tif 000016
2014199412.tif 000017
2014199412.tif 000018