JP2015016104A - コンテンツ提供方法、コンテンツ提供サーバ、およびコンテンツ提供システム - Google Patents

Abstract

【課題】良質なコンテンツを効率よく抽出して提供する。【解決手段】第１、第２ストリーミングサーバ６０ａ、６０ｂは、対応するクライアント端末のためにゲームを実行して出力データをストリーミング転送するとともに（Ｓ１０、Ｓ１２）、設定された評価項目の値が得られる都度、それを評価項目情報としてコンテンツ提供サーバ６２に送信する（Ｓ１４、Ｓ１６）。コンテンツ提供サーバ６２は、それに基づき各ゲームプレイを評価し（Ｓ１８）、評価基準を満たしたゲームプレイをスーパープレイとして検出する（Ｓ２０）。そしてスーパープレイを実行している第１ストリーミングサーバ６０ａに実況画像データの送信を要求し、送信された実況画像を観戦対象として公開する（Ｓ２２〜Ｓ３２）。【選択図】図１２

Description

本開示は、ネットワークを利用して情報処理のサービスを提供する技術に関する。

近年の情報処理技術の発展、ネットワークの充実化などにより、パーソナルコンピュータ、携帯端末などユーザが操作する装置の性能や使用環境によらず、様々な情報処理をサーバとの連携により実現させることが可能となっている。例えばユーザが操作する端末と、それに応じた情報処理を実施する情報処理装置とを分離することにより、簡素な構成の携帯端末などでも高度な情報を出力できるような技術が提案されている（例えば特許文献１参照）。

また複数の端末が接続するサーバの利点を活かし、あるユーザが自装置で行った情報処理の内容や生成されたデータを他のユーザに公開するしくみを提供する技術も提案されている（例えば特許文献２）。クラウドコンピューティングのように、サーバが提供する様々なサービスをネットワークを介して利用することにより、高度な情報処理や膨大なデータ管理を、ユーザが置かれた環境によらず実現できるようにする技術的傾向は益々強くなっている。

特開２０１２−６５８３１号公報 特開２０１２−３８０４２号公報

上記のように、サーバを利用してユーザ個々の情報や電子データを公開できる技術が一般的になるにつれ、公開されるコンテンツは膨大化する。結果として、そのような膨大なコンテンツから、ユーザにとって価値があると思えるコンテンツに的確にアクセスすることが困難になってきている。

本開示はこのような課題に鑑みてなされたものであり、その目的は、ユーザが望む情報へのアクセスが容易であり、多様な楽しみをユーザに与えることのできる技術を提供することにある。

本開示のある態様はコンテンツ提供方法に関する。このコンテンツ提供方法は、コンテンツ提供サーバがネットワークを介してクライアント端末にコンテンツを提供する方法であって、クライアント端末におけるユーザ操作に応じて進捗するコンピュータゲームの進捗状況を示すプレイデータを取得するステップと、プレイデータに基づき所定の評価項目ごとにゲームプレイを評価するステップと、評価結果に従い抽出したゲームプレイの動画のデータを取得するステップと、動画のデータをネットワークを介してクライアント端末に配信するステップと、を含む。

本開示の別の態様はコンテンツ提供サーバに関する。このコンテンツ提供サーバは、クライアント端末におけるユーザ操作に応じて進捗するコンピュータゲームの進捗状況を示すプレイデータを取得するプレイデータ受信部と、プレイデータに基づき所定の評価項目ごとにゲームプレイを評価するプレイ評価部と、プレイ評価部における評価結果に従い抽出したゲームプレイの動画のデータを取得しクライアント端末に配信するデータ配信部と、を備える。

本開示のさらに別の態様はコンテンツ提供システムに関する。このコンテンツ提供システムは、コンピュータゲームのゲームプレイの動画の閲覧要求をサーバへ送信する入力情報送信部と、動画の閲覧要求に応じてサーバから送信された動画のデータを出力する出力部と、を備えたクライアント端末と、複数のクライアント端末のそれぞれにおけるユーザ操作に応じて進捗するコンピュータゲームの進捗状況を示すプレイデータを取得するプレイデータ受信部と、プレイデータに基づき所定の評価項目ごとにゲームプレイを評価するプレイ評価部と、プレイ評価部における評価結果に従い抽出したゲームプレイの動画のデータを取得し前記動画の閲覧要求の送信元のクライアント端末に送信するデータ配信部と、を備えたサーバと、を含む。

なお、以上の構成要素の任意の組合せ、本開示の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本開示の態様として有効である。

本開示によると、ネットワークを介したコンテンツ提供を効率よく行うとともに、さらなる楽しみを提供できる。

本実施の形態における情報処理システムの構成を示す図である。 本実施の形態においてクライアント端末／ゲーム環境提供サーバ間でなされる情報伝達のパターンを模式的に示す図である。 本実施の形態におけるクライアント端末の内部回路構成を示す図である。 本実施の形態におけるクライアント端末の機能的な構成を示す図である。 本実施の形態におけるゲーム環境提供サーバの構成を示す図である。 本実施の形態におけるストリーミングサーバの機能的な構成を示す図である。 本実施の形態におけるコンテンツ提供サーバの機能的な構成を示す図である。 本実施の形態におけるストリーミングサーバにおいて１つのゲームプレイに対し生成されるプレイデータの構造例を示す図である。 本実施の形態においてコンテンツ提供サーバがスーパープレイを選定する際の評価基準の例を示す図である。 本実施の形態におけるコンテンツ提供サーバのフィルタリング条件記憶部が保持する、フィルタリング条件のデータ構造例を示す図である。 本実施の形態におけるコンテンツ提供サーバのユーザ情報記憶部が保持する、ユーザ情報のデータ構造例を示す図である。 本実施の形態においてスーパープレイを選出し、その実況画像を観戦主体のクライアント端末に出力する処理手順を示すフローチャートである。 本実施の形態においてスーパープレイを選出し、その実況画像を観戦主体のクライアント端末に出力する処理手順を示すフローチャートである。 本実施の形態においてゲームプレイがスーパープレイとして認定された旨をプレイヤたるユーザに通知するため、ゲーム主体のクライアント端末に表示される画面例を示す図である。 本実施の形態における観戦主体のクライアント端末において表示される公開用画像の画面例を示す図である。 本実施の形態においてスーパープレイを選出し、その動画を動画主体のクライアント端末に出力する処理手順を示すフローチャートである。 本実施の形態における動画閲覧主体のクライアント端末において表示される公開用画像の画面例を示す図である。 本実施の形態において動画閲覧主体のクライアント端末に表示される動画閲覧画面例を示す図である。 本実施の形態において閲覧主体であるクライアント端末のユーザが、閲覧中の動画のゲームプレイに挑戦するときの処理手順を示すフローチャートである。 本実施の形態において挑戦プレイの観戦主体のクライアント端末に表示される挑戦プレイ観戦画面例を示す図である。 本実施の形態において挑戦プレイの観戦主体のクライアント端末に表示される挑戦プレイ観戦画面例を示す図である。

本実施の形態は、クライアント端末におけるユーザの操作を、サーバがネットワークを介して受信し、当該ユーザが要求する処理を実施してその処理結果をクライアント端末に返信する、という流れを基本とする。ここでサーバが実施する処理の内容は、コンピュータゲーム、動画作成、番組作成、音声データ作成、チャットなどのコミュニケーションツールなど、結果として電子データが出力される情報処理のいずれでもよい。また出力される電子データは画像のみ、音声のみ、画像と音声の組み合わせ、のいずれでもよい。以後、コンピュータゲームを想定し、出力データをゲーム画像のデータとして説明する。ただし単に「画像の表示」とした場合も、必要に応じて音声の出力が同時に行われていてよい。

図１は本実施の形態における情報処理システムの構成を示す。情報処理システム１においてクライアント端末１０ａ、１０ｂ、１０ｃは、それぞれネットワーク３を介してゲーム環境提供サーバ３０に接続可能に構成され、ゲーム環境提供サーバ３０とデータの送受信を行う。ゲーム環境提供サーバ３０はクライアント端末１０ａ、１０ｂ、１０ｃからの要求に応じて指定されたゲームを実行し、その結果生成した出力データをクライアント端末１０ａ、１０ｂ、１０ｃに送信する。クライアント端末１０ａ、１０ｂ、１０ｃおよびゲーム環境提供サーバ３０は、ネットワーク３へ有線または無線で接続する。クライアント端末１０ａ、１０ｂ、１０ｃとゲーム環境提供サーバ３０との接続手法やゲーム処理の要求、出力データの送受信に係る手続きには一般的な技術を適用することができる。

クライアント端末１０ａ、１０ｂ、１０ｃはそれぞれのユーザが操作する装置であり、ユーザが行った操作を入力情報としてゲーム環境提供サーバ３０へ送信し、それに応じた処理を要求するとともに、ゲーム環境提供サーバ３０が処理を行った結果、生成した出力データを受信して、画像や音声として出力する。クライアント端末１０ａ、１０ｂ、１０ｃはタブレット、携帯電話、携帯端末、パーソナルコンピュータなど、一般的な装置や端末のいずれでもよい。なおネットワーク３に接続するクライアント端末１０ａ、１０ｂ、１０ｃ、ゲーム環境提供サーバ３０の数は特に限定されない。以後、クライアント端末１０ａ、１０ｂ、１０ｃを総称してクライアント端末１０と呼ぶこともある。

ゲーム環境提供サーバ３０は、クライアント端末１０においてユーザが指定したゲームを起動し、クライアント端末１０におけるユーザの操作に従い当該ゲームを進捗させる。そしてそれに応じて生成したゲームの画像や音声などの出力データをクライアント端末１０に逐次送信する。

ゲーム環境提供サーバ３０はさらに、複数のクライアント端末１０に同じ出力データを送信することにより、複数のユーザが当該出力データを共有できるようにする。例えば実施する処理を、複数のユーザが参加可能なネットワークゲームとした場合、ゲーム環境提供サーバ３０は、複数のクライアント端末１０からそれぞれのユーザの操作に係る情報を逐次受信し、ゲームの進捗に反映させる。そして生成したゲームの出力データを全てのクライアント端末１０に送信することにより対戦型のゲームを実現できる。

さらにゲーム環境提供サーバ３０は、ゲームに参加しているユーザのみならず、単にゲームを観戦したいユーザや後からゲームの様子を鑑賞したいユーザのクライアント端末１０へも、生成した出力データを送信する。このようにすることで、自分や他人のゲームプレイを時間や場所を問わず複数のユーザで共有することができる。

図２は本実施の形態においてクライアント端末１０／ゲーム環境提供サーバ３０間でなされる情報伝達のパターンを模式的に示している。ここではクライアント端末１０ａを操作するユーザが、自分が行いたいゲームを指定することによって、ゲーム環境提供サーバ３０で当該ゲームのアプリケーションが起動されているものとする。この状況において、まず第１のパターンは、ゲーム実行要求元のクライアント端末１０ａ（以後、「ゲーム主体」とも呼ぶ）でなされた、入力装置５へのユーザ操作の情報をゲーム環境提供サーバ３０が受信し、それに応じて生成された出力データ７がクライアント端末１０ａへ返信される流れである（Ｓ２）。

出力データ７は図示するように、表示時のフレームレートなど必要な更新頻度で時間経過とともに生成される複数の画像フレーム列の動画データからなる。ゲーム環境提供サーバ３０は画像フレームを、生成した順にクライアント端末１０ａへストリーム転送する。これによりゲーム主体のクライアント端末１０ａでは、自分の操作に応じて変化するゲーム画像が常時表示されることになる。なおプレイヤの人数によらず、１回のゲームの開始から終了までを、一単位の「ゲームプレイ」と呼ぶ。ただし場合によっては、開始から終了までを所定の区切りで分割した単位を「ゲームプレイ」と呼ぶこともある。

次に第２のパターンは、ゲーム環境提供サーバ３０が、生成した出力データ７を、並行して別のクライアント端末１０ｂ（以後、「観戦主体」とも呼ぶ）へ送信する流れである（Ｓ４）。このようにすると、クライアント端末１０ａのユーザが行っているゲームの様子を、クライアント端末１０ｂのユーザが同時に見る、すなわち「観戦」することができる。

第３のパターンは、ゲーム環境提供サーバ３０が、生成した出力データ７をゲームプレイごとに内部の記憶装置９に格納しておき（Ｓ６）、あるクライアント端末１０ｃからの要求に従い随時、送信する流れである（Ｓ８）。送信するタイミングは、ゲーム実行期間中であってもよいし、ゲームが終了した後であってもよい。このときのクライアント端末１０ｃのユーザによる行為を、既述の「観戦」と区別して「動画の閲覧」と呼び、クライアント端末１０ｃを「動画閲覧主体」とも呼ぶ。また時間的に後のタイミングで閲覧される動画に対し、ゲーム主体や観戦主体のクライアント端末１０ａ、１０ｂへ送信されるリアルタイムの出力データの画像は、「実況画像」とも呼ぶ。

なお図２では、ゲーム主体であるクライアント端末１０ａ、観戦主体であるクライアント端末１０ｂ、動画閲覧主体であるクライアント端末１０ｃをそれぞれ１つずつ示しているが、各立場のクライアント端末１０が、同時に複数発生する場合もあり得る。また後述するように、動画を閲覧しているユーザが、途中からゲームの主体になる場合など、クライアント端末１０の立場はユーザの要求に応じて変化する。

図２に示したシステムを実現すると、ゲーム自体の楽しみに加え、他のユーザとの関わりによる別の楽しみが生まれる。この効果は、参加するユーザが増加するほど顕著になるが、一方で、ゲームプレイの数が膨大になると、観戦対象や閲覧対象の選択が困難になるという問題も生じる。すなわち、ごく一部の、他人の目に触れる価値のあるゲームプレイが、その他の多くのゲームプレイに埋もれてしまい、自分が見たいと思えるゲームプレイを見つけ出すことが困難になっていく。また、ゲームプレイを公開するユーザやそれを閲覧するユーザがそれぞれ自由にアクセスできる環境や、それに付随するサービスを提供することは、望ましい形態である一方、ゲーム環境提供サーバ３０における処理やリソースの負荷を増大させることにもつながる。結果として、応答速度の安定性などの面でユーザに不利益となりかねない、というジレンマが生じる。

そこで本実施の形態では、多くのゲームプレイと、観戦や閲覧を楽しみたいユーザとを好適にマッチングする技術を提供する。具体的には、ゲーム環境提供サーバ３０において要求されたゲームを実行中、ゲームの状況を表す各種評価項目を記録していき、ゲーム中または終了時に、当該記録に基づきゲームプレイを評価する。そして評価の高いゲームプレイを抽出して観戦や動画閲覧の候補とし、その情報を公開する。評価項目を多角的に準備することにより、ユーザの希望に合致するゲームプレイを容易に抽出できる。

このようにすると、ゲームのプレイヤにとっても、そのような評価を経て公開される栄誉を得られる可能性が生まれ、ゲームに対するモチベーションを向上させることができる。また、多数の玉石混淆の動画に閲覧者が分散してしまうのと比べ、公開対象を絞り込むことにより人が集まりやすくなり、公開の場が活性化する。これを利用してさらなるサービスを提供したり、ゲームの販売やシステムへの参加を促進することもできる。またゲーム環境提供サーバ３０自身がゲームプレイやその閲覧状況を管理することにより、リソースへの負荷の増大を抑えることができる。

図３は本実施の形態におけるクライアント端末１０の内部回路構成を示している。クライアント端末１０は、ＣＰＵ（Central Processing Unit）１２、ＧＰＵ（Graphics Processing Unit)１４、メインメモリ１６を含む。ＣＰＵ１２は、オペレーティングシステムやアプリケーションなどのプログラムに基づいて、クライアント端末１０内部の構成要素における処理や信号伝送を制御する。ＧＰＵ１４は画像処理を行う。メインメモリ１６はＲＡＭ（Random Access Memory）により構成され、処理に必要なプログラムやデータを記憶する。

これらの各部は、バス２０を介して相互に接続されている。バス２０にはさらに入出力インターフェース１８が接続されている。入出力インターフェース１８には、ＵＳＢやＩＥＥＥ１３９４などの周辺機器インターフェースや、有線又は無線ＬＡＮのネットワークインタフェースからなる通信部２２、ハードディスクドライブや不揮発性メモリなどの記憶部２４、画像や音声のデータを出力する出力部２６、ユーザなど外部からの入力を受け付ける入力部２８、磁気ディスク、光ディスクまたは半導体メモリなどのリムーバブル記録媒体を駆動する記録媒体駆動部２９が接続される。

ＣＰＵ１２は、記憶部２４に記憶されているオペレーティングシステムを実行することにより、クライアント端末１０の全体を制御する。ＣＰＵ１２はまた、記憶部２４やリムーバブル記録媒体から読み出されてメインメモリ１６にロードされた、あるいは通信部２２を介してダウンロードされた各種プログラムを実行する。ＧＰＵ１４は、ジオメトリエンジンの機能とレンダリングプロセッサの機能とを有し、ＣＰＵ１２からの描画命令に従って描画処理を行い、表示画像を図示しないフレームバッファに格納する。そしてフレームバッファに格納された表示画像をビデオ信号に変換して出力部２６に出力する。

入力部２８は、キーボード、タッチパッド、ボタン、ジョイスティック、マイクロフォン、カメラなど一般的な入力装置と、当該入力装置から入力信号を取得する機構とを含む。出力部２６は、画像を表示するディスプレイ、音声を出力するスピーカーなどの一般的な出力装置と、当該出力装置へ出力信号を送出する機構とを含む。

クライアント端末１０と、入力部２８に含まれる入力装置、および、出力部２６に含まれるディスプレイは、それぞれ個別の筐体を有し、有線ケーブルで接続されてよい。またはBluetooth（ブルートゥース）（登録商標）プロトコルやIEEE802.11プロトコルなどを用いて無線接続を確立してもよい。あるいは、それらが内部で接続された一体的な筐体を備えた装置としてもよい。例えばディスプレイを筐体表面に配し、その前面に設けたタッチパッドを入力装置とすることにより、携帯ゲーム機、タブレット端末、高機能携帯電話などを実現してもよい。

図４はクライアント端末１０の機能的な構成を示している。クライアント端末１０は、ユーザ操作を受け付ける入力部５２、受け付けた操作内容を入力情報としてゲーム環境提供サーバ３０へ送信する入力情報送信部５４、ゲーム環境提供サーバ３０から送信された出力データを受信する出力データ受信部５６、送信された出力データを出力可能な形式に変換する出力データ処理部５８、出力データを出力する出力部５９を含む。

図４および後述する図５乃至７において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、既述したようにＣＰＵ（Central Processing Unit）、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、記録媒体や記憶装置に格納されメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

入力部５２は、図３の入力部２８によって実現され、ユーザがクライアント端末１０に対し操作入力を行うための入力手段である。クライアント端末１０がゲーム主体であるとき、入力部５２は、ゲーム環境提供サーバ３０に処理を要求するゲームの指定、当該ゲームに対する操作などを受け付ける。クライアント端末１０が観戦主体であるとき、入力部５２は、観戦対象候補を表した公開用画像の表示要求や、観戦対象のゲームプレイの選択入力などを受け付ける。

クライアント端末１０が動画閲覧主体であるとき、入力部５２は、閲覧対象候補を表した公開用画像の表示要求、閲覧対象の動画の検索や選択入力を受け付ける。さらに閲覧中の動画のゲームプレイへの挑戦要求も受け付ける。入力情報送信部５４は、ＣＰＵ１２および通信部２２などによって実現され、ゲーム環境提供サーバ３０と一般的な手法により通信を確立する。そして入力部５２に対するユーザの操作内容を表す入力情報の信号を生成し、ゲーム環境提供サーバ３０に送信する。

出力データ受信部５６は通信部２２などによって実現され、ゲーム環境提供サーバ３０から送信された出力データを受信する。クライアント端末１０がゲーム主体である場合、受信する出力データは、ゲームの初期画面や、ゲームに対するユーザ操作に応じて変化する実況画像のデータであり、ゲーム期間中、ゲーム環境提供サーバ３０からストリーム転送される。クライアント端末１０が観戦主体である場合、受信する出力データは、観戦対象候補を表した公開用画像のデータ、観戦対象として選択されたゲームプレイの実況画像のデータなどである。後者はゲーム期間中、ゲーム環境提供サーバ３０からストリーム転送される。

クライアント端末１０が動画閲覧主体である場合、受信する出力データは、閲覧対象候補の動画を表した公開用画像のデータ、閲覧対象として選択された動画のデータなどである。出力データ処理部５８はＣＰＵ１２、ＧＰＵ１４などによって実現され、受信した出力データを適宜、復号、伸張し、出力可能な画像や音声のデータとする。あるいはマークアップ言語で記載された情報を解釈して表示画面を構築する。出力部５９は図３の出力部２６によって実現され、出力データ処理部５８が復元した画像を表示したり音声として出力したりする。

図５はゲーム環境提供サーバ３０の構成を示している。なおゲーム環境提供サーバ３０を構成する各サーバの内部回路構成は、図３で示したクライアント端末１０の内部回路構成と同様のものでよい。ゲーム環境提供サーバ３０は、第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６０ｂ、・・・、第ｎストリーミングサーバ６０ｃ、およびコンテンツ提供サーバ６２を含む。

第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６０ｂ、・・・、第ｎストリーミングサーバ６０ｃは、それぞれゲームアプリケーションを起動し、対応するゲーム主体のクライアント端末１０におけるユーザ操作に応じて生成した実況画像のデータを、ゲーム主体や観戦主体のクライアント端末１０へストリーム転送する。またゲーム実行期間において、第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６０ｂ、・・・、第ｎストリーミングサーバ６０ｃは、所定の評価項目の具体値が得られる都度、それを評価項目情報として記録する。

さらに、ゲームの途中や終了時にユーザが行ったセーブ操作に応じてセーブデータを記録したり、メモリやレジスタ内のデータ状況を定期的に表したスナップショットを記録したりする。これらの情報は、動画を閲覧しているユーザが、そのゲームプレイへの挑戦を要求したとき、ゲームの途中からでも挑戦を可能にするためのものである。以後、このような情報を「復帰情報」と呼ぶ。また、第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６０ｂ、・・・、第ｎストリーミングサーバ６０ｃを総称してストリーミングサーバ６０と呼ぶこともある。

コンテンツ提供サーバ６２は、ゲーム主体であるクライアント端末１０から要求されたゲームの処理を、ストリーミングサーバ６０のいずれかに割り当てる。コンテンツ提供サーバ６２はさらに、ストリーミングサーバ６０で実行中あるいは終了したゲームプレイの内容を、記録された評価項目情報に基づいて評価し、観戦対象や閲覧対象の候補とすべきゲームプレイを抽出する。抽出した観戦対象候補のゲームプレイや閲覧対象候補の動画は、それぞれの公開用画像によって公開する。

例えば、出現する敵を倒しながら仮想世界を進んでいくロールプレイングゲームにおいて、あるシーンで出現する敵を倒すまでの時間として最短記録を更新したゲームプレイを抽出する。当該ゲームプレイが進捗中であれば観戦対象候補とし、ゲーム終了後であれば動画として閲覧対象候補とする。抽出のための評価項目を複数、設定し、それを検索キーとして検索できるようにすることで、ユーザは、それぞれの公開用画像にリストアップされた候補の中から、自分が見たい対象を容易に見つけ出すことができる。

動画名や再生回数など表面的な情報でなく、実際のゲームの状況に基づき、統一された評価基準によって候補が決定されるため、候補の選出や検索結果の信頼性が高い。また実際に観戦や閲覧をする前に、評価されたポイントが細かく把握できるため、効率のよいアクセスが可能である。例えば、自分が苦労した場面を上手に攻略しているゲームプレイなどにピンポイントでアクセスすることができる。さらにストリーミングサーバ６０で処理する多くのゲームプレイを自動的に評価することで、プレイヤ本人に優れていたり面白かったりする自覚がなくても、当該ゲームプレイを公開の場まで引き上げることができる。

以後、ゲームが進捗中か否かに関わらず、このような評価によって抽出したゲームプレイを、「スーパープレイ」と呼ぶ。ただしスーパープレイは、優れたプレイに限定されるものではなく、珍しいプレイや面白いプレイなどでもよく、ゲーム作成者などがゲームの内容に応じて、ユーザの興味を誘う評価項目をゲームの発売後に設定または再設定してよい。

なお図１および図５では、ストリーミングサーバ６０およびコンテンツ提供サーバ６２を包括してゲーム環境提供サーバ３０としているが、ストリーミングサーバ６０およびコンテンツ提供サーバ６２は必ずしも１つの場所になくてよい。例えばストリーミングサーバ６０を世界中の様々な場所に数多く設置し、ゲーム主体のクライアント端末１０から距離が最も近いストリーミングサーバ６０を選択してゲームを実行させることにより、より応答性に優れたゲーム環境を実現できる。コンテンツ提供サーバ６２についても、互いに情報を共有できるようにすれば、その一部あるいは全ての機能をもつサーバを各地に設置してよい。

図６はストリーミングサーバ６０の機能的な構成を示している。ストリーミングサーバ６０は、コンテンツ提供サーバ６２から実施すべき処理に関する制御情報を受信する制御情報受信部７０、クライアント端末１０からユーザ操作の情報を受信する入力情報受信部７２、要求されたゲームを実行する情報処理部７４、評価項目情報や復帰情報をメタデータとして作成するメタデータ生成部７８、ゲームの実行結果として出力データを生成する出力データ生成部７６、出力データをクライアント端末１０に送信する出力データ送信部８２、メタデータや出力データを格納するプレイデータ記憶部８０、スーパープレイに認定されたことなどの通知を出力データに含める通知情報生成部８４を含む。

制御情報受信部７０は、図３の通信部２２、ＣＰＵ１２などで実現し、コンテンツ提供サーバ６２から、実行すべきゲームに係る情報を取得する、さらに当該ゲームのゲーム主体であるクライアント端末１０ａの識別情報を、ユーザの操作に係る入力情報の送信元かつ出力データの送信先として取得する。また、進捗中、または終了したゲームプレイがスーパープレイとして認定された場合に、その旨の通知も取得する。

入力情報受信部７２は、図３の通信部２２、ＣＰＵ１２などで実現し、ゲーム主体のクライアント端末１０から送信された、ユーザの操作に係る入力情報を受信する。情報処理部７４は、ＣＰＵ１２やメインメモリ１６などで実現し、指定されたゲームのアプリケーションを起動して実行する。この際、ゲーム主体である１つまたは複数のクライアント端末１０から逐次送信されたユーザの操作情報に応じて、リアルタイムでゲームを進捗させる。

クライアント端末１０／ストリーミングサーバ６０間の通信に用いる具体的なプロトコルや入力信号のフォーマット、その解釈手法などには一般的なエミュレーションの技術を適用できるためここでは説明を省略する。メタデータ生成部７８は、ＣＰＵ１２やメインメモリ１６などで実現し、情報処理部７４におけるゲームの進捗において、あらかじめ設定された評価項目の値が得られる都度、それを評価項目情報として記録する。記録すべき評価項目は、ゲームごとに設定されたものを内部のメモリなどに格納しておき、ゲームの開始時などに参照する。

メタデータ生成部７８はさらに、情報処理部７４におけるゲームの進捗において、上述の復帰情報を記録する。復帰情報は基本的に、当該ゲームプレイの動画のデータとともにプレイデータ記憶部８０に格納されたり、コンテンツ提供サーバ６２に送信されたりする。そして当該動画を閲覧しているユーザが、そのスーパープレイに挑戦する際、ユーザが希望するタイミングからゲームを開始したり、スーパープレイと条件を揃えたりする際に利用される。このようにすることで、スーパープレイとして認定されたゲームプレイがどれだけ優れているかを実感したり、自分のプレイの方が優れていることを示したりすることができる。

なおスーパープレイへ挑戦しているゲームプレイ（以後、「挑戦プレイ」と呼ぶ）も、通常のゲームプレイと同様に、ストリーミングサーバ６０が処理する。このとき、コンテンツ提供サーバ６２から、処理要求とともに復帰情報を取得することにより、挑戦者が望むタイミングからゲームを開始する。また挑戦プレイも観戦や評価の対象とする。例えば元のスーパープレイと比較することにより勝敗を決定し、勝利した場合はスーパープレイを入れ替えるようにしてもよい。

メタデータ生成部７８が作成した、評価項目情報と復帰情報は、ゲームプレイのメタデータとしてプレイデータ記憶部８０に格納する。このとき、ゲームプレイの識別情報と対応づけておく。プレイデータ記憶部８０は、図３の記憶部２４などで実現する。

出力データ生成部７６は、ＣＰＵ１２やＧＰＵ１４などで実現し、情報処理部７４の処理結果として表示すべきゲーム画像を描画したりそれにＢＧＭなどの音声を付加したりして出力データを生成する。上述のとおり表示すべき画像フレームを所定の頻度で生成することにより、動画データが生成される。

出力データ生成部７６は、生成した出力データを出力データ送信部８２に供給するとともに、所定の単位で圧縮符号化してプレイデータ記憶部８０に格納する。このときゲームプレイの識別情報と対応づけておくことにより、メタデータ生成部７８が生成した評価項目情報、復帰情報、動画データが互いに対応づけられたことになる。なお動画データを格納する代わりに、入力情報受信部７２が受信したユーザ操作の情報を格納し、動画データを別のタイミングで作成し直してもよい。

例えば当該ゲームプレイがスーパープレイとして認定され、閲覧対象候補となることが決定した時点で、ユーザ操作の情報に基づきゲームを再現するなどして動画データを作成してもよい。この場合、情報処理部７４と出力データ生成部７６がゲームを再現して動画データを作成し、プレイデータ記憶部８０に格納してもよいし、ユーザ操作の情報自体をコンテンツ提供サーバ６２に送信してしまい、コンテンツ提供サーバ６２内で動画データを作成してもよい。

出力データ送信部８２は、図３のＣＰＵ１２および通信部２２などによって構成され、生成されたリアルタイムの出力データ、すなわち実況画像のデータを、ゲーム主体のクライアント端末１０へ送信する。また、当該ゲームプレイがスーパープレイに認定されたことをコンテンツ提供サーバ６２から通知された場合は、同じ実況画像のデータを、コンテンツ提供サーバ６２へも送信する。出力データ送信部８２はさらに、ゲームの実行中や終了時に、評価項目情報をプレイデータ記憶部８０から読みだし、コンテンツ提供サーバ６２へ送信する。送信は、評価項目の値が取得される都度でもよいし、定期的でもよい。

ゲームプレイがスーパープレイに認定された場合はさらに、プレイデータ記憶部８０に格納された、当該ゲームプレイの動画データを、コンテンツ提供サーバ６２へ送信する。このときの送信単位は、必ずしもゲームプレイ全体でなくてもよい。例えばゲームが複数段階に分かれているとき、第１段階においてスーパープレイに認定されたら、第１段階の動画のデータのみを送信すればよい。この場合、ゲームが進捗中であっても、動画データの送信が可能である。分割規則はゲームの内容に応じて決定してよく、例えばある敵との戦いの場面のみを１つの動画とするなど、より細かく分割してもよいし、分割しなくてもよい。

通知情報生成部８４は、実行中または実行終了時のゲームプレイがスーパープレイに認定されたとき、その情報を、制御情報受信部７０を介してコンテンツ提供サーバ６２から取得する。そして当該ゲームプレイのプレイヤであるユーザにその旨を通知するため、実況画像に通知のための文字情報などを合成する。この通知とともに、ユーザにゲームプレイ公開の是非を確認し、許可された場合にのみゲームプレイを公開することにより、個人の事情やプライバシーへ配慮する。

図７はコンテンツ提供サーバ６２の機能的な構成を示している。コンテンツ提供サーバ６２は、クライアント端末１０からユーザ操作の情報を受信する入力情報受信部１０６、ストリーミングサーバ６０へ実施すべき処理に関する制御情報を送信するストリーミングサーバ制御部９８、ストリーミングサーバ６０から、評価項目情報、実況画像のデータ、動画データ、復帰情報を含むゲームプレイのデータを受信するプレイデータ受信部９０、ゲームプレイのデータを格納するプレイデータ記憶部９４を含む。

コンテンツ提供サーバ６２はさらに、送信された評価項目情報に基づきゲームプレイを評価するプレイ評価部９６、評価基準を格納する評価基準記憶部１０２、観戦対象候補や閲覧対象候補の公開用画像のデータを生成する公開用画像生成部１００、観戦可能なゲームプレイや閲覧可能な動画をユーザによって制限するフィルタリング条件を格納するフィルタリング条件記憶部１０４、フィルタリングに用いるユーザの情報を格納するユーザ情報記憶部１０５、および、観戦主体や動画閲覧主体のクライアント端末１０において出力されるデータを送信する出力データ送信部１０８を含む。

入力情報受信部１０６は、図３の通信部２２、ＣＰＵ１２などで実現し、クライアント端末１０から送信された入力情報を受信する。具体的には、ゲーム主体のクライアント端末１０からはゲームの実行を要求する情報を受信する。観戦主体のクライアント端末１０からは公開用画像データの送信要求や、選択されたゲームプレイの観戦要求の情報を受信する。動画閲覧主体のクライアント端末１０からは公開用画像データの送信要求や、選択した動画の閲覧要求の情報を受信する。さらに、閲覧中の動画のゲームプレイに対する挑戦要求がなされた場合はその情報も受信する。

ストリーミングサーバ制御部９８は、通信部２２、ＣＰＵ１２などで実現し、クライアント端末１０からの要求や内部でのゲームプレイ評価の結果に従って、ストリーミングサーバ６０に必要な情報を通知のうえ、各種処理を要求する。具体的には、入力情報受信部１０６が受信した、ゲーム主体のクライアント端末１０からの入力情報に基づき、要求されたゲームの実行をストリーミングサーバ６０のいずれかに割り当てる。そして当該ストリーミングサーバ６０に、ゲームの識別情報やクライアント端末１０の識別情報を通知するとともにゲームの実行を要求する。

また、ゲームプレイがスーパープレイに認定された場合に、当該ゲームプレイを行っている、または行っていたストリーミングサーバ６０に、実況画像や動画のデータ送信を要求する。クライアント端末１０のいずれかから、挑戦プレイの要求がなされた旨の情報を取得した場合は、いずれかのストリーミングサーバ６０に当該ゲームの実行を要求するとともに、その実況画像のデータ送信も要求する。

プレイデータ受信部９０は通信部２２、ＣＰＵ１２などで実現し、ストリーミングサーバ制御部９８からの要求に従いストリーミングサーバ６０から送信された、ゲームプレイの各種データを受信する。具体的には、進捗中または終了時のゲームプレイの評価項目情報、スーパープレイの実況画像データや動画データ、復帰情報、挑戦プレイの実況画像などを受信する。受信したプレイデータはプレイデータ記憶部９４に格納する。プレイデータ記憶部９４は、図３の記憶部２４などで実現する。

プレイ評価部９６はＣＰＵ１２などで実現し、プレイデータ記憶部９４に格納された、進捗中または終了時のゲームプレイの評価項目情報を読み出し、所定の評価基準に則りゲームプレイを評価する。評価基準はあらかじめゲーム作成者などが設定したものを評価基準記憶部１０２に格納しておく。評価基準記憶部１０２は図３の記憶部２４などで実現する。

プレイ評価部９６は、評価の結果、スーパープレイと認定すべきゲームプレイが検出されたら、ストリーミングサーバ制御部９８にその旨を通知する。これによりストリーミングサーバ制御部９８を介して、当該ゲームプレイを実行している、または実行していたストリーミングサーバ６０に、実況画像や動画のデータ送信を要求する。プレイ評価部９６はさらに、スーパープレイとなったゲームプレイの識別情報を公開用画像生成部１００に通知する。

公開用画像生成部１００は、ＣＰＵ１２、ＧＰＵ１４などで実現し、観戦対象候補から観戦対象を選択するための画像、および、閲覧対象候補から閲覧対象を選択するための画像を、公開用画像として生成する。公開用画像は例えば、観戦対象候補の実況画像や閲覧対象候補の動画をサムネイル表示することによって構成する。ただし候補として表示する対象は必ずしも複数でなくてよく、１つの場合はそれを観戦／閲覧するか否かの選択となる。あるいは公開用画像上で１つの実況画像や１つの動画を公開してしまってもよい。

いずれにしろ、実況画像や動画をユーザによらず公開してしまうと、ゲーム未購入のユーザまでもがゲームの全貌を知ってしまったり挑戦できたりしてしまい、ゲームアプリケーションの販売に支障をきたすことが考えられる。またゲーム購入者であっても、ロールプレイングゲームのようにストーリー性のあるゲームを途中まで進んだユーザにとっては、その先を知りたくない場合もある。

そこで公開用画像生成部１００は、ユーザによって公開画像に含めるゲームプレイを制限する。そのためのフィルタリング条件およびユーザの情報は、フィルタリング条件記憶部１０４およびユーザ情報記憶部１０５にあらかじめ格納しておく。フィルタリング条件記憶部１０４およびユーザ情報記憶部１０５は、図３の記憶部２４などで実現する。

公開用画像生成部１００は、観戦候補を表す公開用画像や、閲覧候補を表す公開画像のみならず、選択された実況画像や動画を表示するための公開用画像を生成してもよい。例えば実況画像や動画に枠を施したり、文字情報を付加したりしてもよい。いずれの場合も、マークアップ言語で記載された画面構成にしたがい、候補の画像のサムネイル、実況画像、動画などを、画面内の適切な位置に配置してホームページなどを作成するようにしてもよい。

出力データ送信部１０８は、ＣＰＵ１２、通信部２２などで実現し、クライアント端末１０に出力データを送信する。具体的には、観戦対象候補や閲覧対象候補の画像を含む公開用画像、観戦対象として選択された実況画像、閲覧対象として選択された動画、のデータのいずれかを、クライアント端末１０からの入力情報に応じて送信する。公開画像のデータは公開用画像生成部１００から取得する。実況画像や動画を加工をせずに表示する場合は、選択されたデータをプレイデータ記憶部９４から読み出す。そのため出力データ送信部１０８は、入力情報受信部１０６から、ユーザ操作に基づく要求対象に係る情報、例えば観戦対象として選択されたゲームプレイの識別情報などを取得しておく。

図８はストリーミングサーバ６０において１つのゲームプレイに対し生成されるデータ、すなわちプレイデータの構造例を示している。プレイデータ２５０は、ゲームプレイ識別情報２５２ａ、ユーザ識別情報２５２ｂ、クライアント端末識別情報２５２ｃ、評価項目情報２５２ｄ、復帰情報２５２ｅ、および動画データ２５２ｆからなる。なお同図ではこれらの構成要素が連続して１つのプレイデータを構成しているが、連続した記憶領域に格納されていることを示す主旨ではない。構成要素がゲームプレイ識別情報などを介して互いに対応づけられていれば、その格納領域は不連続でもよく、また個別に送受信の対象としてもよい。

ゲームプレイ識別情報２５２ａは、ゲームを開始する都度、当該ゲームに一意的に付与する。ユーザ識別情報２５２ｂ、クライアント端末識別情報２５２ｃは、あらかじめ設定されたログイン名やＩＰアドレスなどでよく、クライアント端末１０がコンテンツ提供サーバ６２に接続した際、サービスにログインした際、通信を行った際、などに取得する。

評価項目情報２５２ｄは、あらかじめゲームごとに設定された評価項目に対し、ゲームの進捗によって決定した値を記録した情報である。同図右上に例示するように、評価項目は、ゲームを「第１ステージ」など複数段階に分割する方が望ましい場合はその単位で、「全般」の「攻略時間」や「得点」、「敵Ａ」を「倒すまでの時間」や「ダメージ量」、・・・などゲームの内容に沿って設定する。このような評価項目に対し、値が定まった時点で、「攻略時間」＝「５６分３５秒」といった数値を記録する。

評価項目はゲームの状況を表し、評価の対象と成り得るものであれば、その具体的な内容は特に限定されない。また記録する値は必ずしも数値でなくてよく、例えば「勝ち／負け」やアイテムの種類など、通常、文字で表されるものでもよい。評価の際は、各評価項目の値を単独で参照してもよいし組み合わせてもよい。

復帰情報２５２ｅは、ゲームを同じポイントから同じ条件で再び開始するのに必要なデータを、進捗中のゲームの各ポイントで記録した情報である。同図右下に示す例では、各ステージのセーブデータと、３０秒おきのスナップショットを記録している。ただしこれらに限る主旨ではなく、得点や到達点の推移のみを記録すればよい場合などもあるため、ゲームの内容によって適宜設定する。この情報を利用することにより、挑戦プレイをゲームの途中から、スーパープレイと同じ条件で開始できるようになる。

動画データ２５２ｆはゲーム画面を表す動画のデータであり、ゲームの進捗中あるいは終了後に生成され、適宜圧縮符号化されてプレイデータ記憶部８０に格納される。上述のとおり動画データは１つのゲームプレイごとに作成してもよいし、複数の分割単位ごとに作成してもよい。同図の場合、「第１ステージ」などステージ単位で評価項目情報が得られるため、動画データもその単位としてよい。あるいは「第１ステージ」において「敵Ａ」と格闘した期間のみの動画データなどでもよい。したがって動画データ２５２ｆは、複数の動画データを含み得る。１つのゲームプレイから複数の動画を作成する場合は、動画データごとに識別情報を与えて管理する。

図９は、コンテンツ提供サーバ６２がスーパープレイを選定する際の評価基準の例を示している。なお同図は評価基準全般を包括的に示しており、コンテンツ提供サーバ６２の評価基準記憶部１０２には、ゲームごと、評価項目ごとに、スーパープレイの選定基準となる具体的な数値や要件が記載されている。評価基準例２０４において、ゲーム種別が「ロールプレイングゲーム」の場合、評価単位、すなわち「キャラクタのレベル」、「保持する武器」、「滞在している町」、「倒した敵の種別」、などが同じゲームプレイ同士を比較し、評価項目、すなわち「攻略時間」、「敵を倒した回数・倒すまでの時間・ダメージ量」、「得点・経験値」、などが最も高いゲームプレイをそれぞれスーパープレイとする。

つまり評価単位と評価項目の組み合わせに対し、それぞれのスーパープレイが選定される。例えばある町に滞在している状況のゲームプレイのうち、最も高い得点が得られているゲームプレイをスーパープレイとする。あるいはある種別の敵を倒したゲームプレイのうち、ダメージを受ける量が最も少なかったゲームプレイをスーパープレイとする。スーパープレイはこのように、他のゲームプレイとの比較によって選定してもよいし、所定のしきい値より優れているゲームプレイを選定してもよい。

その他のゲーム種別も同様であるが、オンラインゲームの場合は同じゲームプレイに多数の参加者が存在する可能性があるため、参加者同士を比較するようにしてもよい。例えば図示するように、「参加者のうち最初に敵を倒した」など、最も優れた参加者を抽出し、当該参加者のゲームプレイをスーパープレイと認定する。なお図９に示した評価基準は一例であり、ゲームの内容などによって、別の評価単位や評価項目を設定してもよいし、評価単位と評価項目の組み合わせも自由に設定してよい。また評価項目や選定基準となる具体的な数値や要件は、ゲームのアプリケーションの発売前にゲーム作成者等が初期値を設定するほか、発売後にユーザによる実際のゲームプレイに基づき設定したり更新したりする。評価基準をコンテンツ提供サーバ６２が保持することにより、評価基準を容易に更新でき、ゲームプレイの状況を即時反映させた評価が行える。

図１０は、コンテンツ提供サーバ６２のフィルタリング条件記憶部１０４が保持する、フィルタリング条件のデータ構造例を示している。フィルタリング条件テーブル２０８は、フィルタリング項目欄２１０ａおよび条件値欄２１０ｂからなり、フィルタリング対象となる項目と、観戦や閲覧を許可する条件値とを対応づけている。条件値はフィルタリング項目によって、ゲームごとに共通としてもよいし、所定の分割単位ごとに設定してもよい。例えば図８で示したプレイデータが得られるゲームプレイの場合、「第１ステージ」の観戦や動画閲覧に対しては、当該ゲーム、および「第１ステージ」に対し設定されたフィルタリングの条件値が参照される。

図示したフィルタリング条件テーブル２０８の例では、ゲームプレイの観戦や動画閲覧を、ゲームアプリケーションの購入者のみに制限したり（２行目）、同じゲームやステージをすでにクリア済みのユーザのみに制限したり（３行目）している。また、ゲームプレイのプレイヤと事前に「フレンド登録」しているユーザのみに制限している（８行目）。なお図１０で示したフィルタリング条件は一例であり、実際にはいくつかの項目を無効にしたりさらに別の項目を追加したりしてよい。条件値を設定する単位は動画の生成単位と同じでよく、ステージごとのほか、敵ごとに設定してもよい。

図１１は、コンテンツ提供サーバ６２のユーザ情報記憶部１０５が保持する、ユーザ情報のデータ構造例を示している。ユーザ情報テーブル２１２は、項目欄２１４ａおよび実値欄２１４ｂからなる。項目欄２１４ａに記載される項目は、基本的に図１０のフィルタリング条件テーブル２１０におけるフィルタリング項目欄２１０ａと同じであり、それらの項目についてユーザ個々の実値を対応づける。

ユーザ情報テーブル２１２をユーザごと、ゲームごとに準備しておき、該当ユーザがゲームアプリケーションを購入したりゲームをプレイする都度、必要に応じて実値欄２１４ｂを更新する。そして観戦対象候補や閲覧対象候補の公開用画像を生成する際に、フィルタリング条件と公開用画像要求元のクライアント端末１０のユーザ情報とをつき合わせることにより、公開用画像に含めてよいゲームプレイのみを抽出して掲載する。

あるいは公開用画像はユーザ共通とし、観戦対象や閲覧対象が選択された時点でフィルタリングを行ってもよい。このとき、選択されたゲームプレイに設定されたフィルタリング条件を満たしていないユーザに対しては、観戦や閲覧が許可されない旨を通知する。さらに、許可されない理由や、どのような条件を満たせば見られるのかを通知するようにしてもよい。

次に、これまで述べた構成によって実現されるシステムの動作について説明する。図１２、図１３は、スーパープレイを選出し、その実況画像を観戦主体のクライアント端末１０に出力する処理手順を示すフローチャートである。まず図１２を参照し、第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６０ｂなどでは、それぞれに割り当てられたゲームを実行し、そのゲーム主体であるクライアント端末（図示せず）に実況画像のデータをストリーミング転送している（Ｓ１０、Ｓ１２）。

なおクライアント端末からの要求に従いゲームアプリケーションを起動した時点で、当該ゲームプレイに対し識別情報が与えられ、実況画像データ、動画データ、評価項目情報、復帰情報に付加されることにより、それらのデータは以後、システム内で当該識別情報によって管理されるものとする。また既存の通信プロトコルを利用することにより、各種データの送受信処理において、送信側／受信側の識別情報は互いに把握されているものとする。なお図８および９では、ゲーム主体のクライアント端末と第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６２ｂ間のデータ送受信処理は省略している。

第１ストリーミングサーバ６０ａ、第２ストリーミングサーバ６０ｂは、ゲームの実行と並行して、あらかじめ設定された評価項目について値が得られる都度、それを評価項目情報として作成し、コンテンツ提供サーバ６２に送信する（Ｓ１４、Ｓ１６）。コンテンツ提供サーバ６２は、送信された評価項目情報に基づき、随時ゲームプレイを評価する（Ｓ１８）。そして所定の評価基準を満たしたゲームプレイをスーパープレイとして検出し（Ｓ２０）、当該評価項目情報の送信元のストリーミングサーバ（図では第１ストリーミングサーバ６０ａ）に、その旨を通知するとともに実況画像データの送信を要求する（Ｓ２２）。

要求を受けた第１ストリーミングサーバ６０ａは、当該ゲームプレイを行っているユーザに対し、スーパープレイに認定されたことを通知するとともに、実況画像を公開することの是非を問いあわせる（Ｓ２４）。実際には、通知内容を表したメッセージボックスや問いあわせのためのダイアログボックスの画像を実況画像に含めたり、それらの表示命令を出力データに埋め込んだりする。ユーザから公開を許可された場合、第１ストリーミングサーバ６０ａは、コンテンツ提供サーバ６２への実況画像データ送信を開始する（Ｓ２６）。

図示は省略するが、ユーザが公開を拒否した場合はＳ２６の処理は行わない。いずれにしろ、第１ストリーミングサーバ６０ａは、ゲーム主体のクライアント端末への実況画像データの送信については継続して行っている。コンテンツ提供サーバ６２へ送信された実況画像のデータは、観戦対象候補として公開用画像に掲載される。この段階で、閲覧対象候補の動画データとしてプレイデータ記憶部９４に格納してもよい。

一方、ゲーム主体でないクライアント端末１０ｂは、ゲームプレイ観戦を要求する操作がユーザよりなされたとき、コンテンツ提供サーバ６２に対し、観戦対象候補の公開用画像のデータ送信を要求する（Ｓ２８）。なおこの処理は実際には、ゲーム環境提供サーバ３０が提供する、ゲーム関連のホームページにおける観戦用ページへのアクセス要求に応じて開始してもよい。

コンテンツ提供サーバ６２は、第１ストリーミングサーバ６０ａからデータ送信された実況画像を動画サムネイルなどで表した公開用画像を作成し、クライアント端末１０ｂにデータを送信する（Ｓ３０）。ここで公開用画像は、１つのゲームプレイの実況画像のみで構成してもよいし、他のスーパープレイの実況画像が含まれていてもよい。また、ゲーム進捗中のスーパープレイがなければサムネイル画像に代わり、その旨を記載してもよい。

また公開画像は動画サムネイルに限らず、静止画サムネイルや文字情報のみなどでもよい。公開用画像の生成においては、要求元のクライアント端末１０ｂのユーザ識別情報に基づきユーザ情報記憶部１０５から読み出したユーザの情報と、フィルタリング条件記憶部１０４から読み出したフィルタリング条件とをつき合わせ、表示対象をユーザごとに選別する。クライアント端末１０ｂでは、データ送信された公開用画像を表示したうえ、ユーザがゲームプレイを選択したりして観戦開始操作を行ったとき、コンテンツ提供サーバ６２に、該当ゲームプレイの観戦開始を要求する（Ｓ３２）。

続いて図１３を参照し、コンテンツ提供サーバ６２は、要求されたゲームプレイの実況画像データの、クライアント端末１０ｂへの送信を開始する（Ｓ３４）。これによりクライアント端末１０ｂでは、実況画像の表示が開始される（Ｓ３６）。なお観戦対象を１つに絞る場合は、Ｓ３２、Ｓ３４の処理を省略してもよい。この場合、例えばユーザがホームページ上の観戦用のページにアクセスした時点で、観戦が可能となる。あるいは複数のゲームプレイを同時に観戦できるようにしてもよい。

一方、コンテンツ提供サーバ６２においては、各ストリーミングサーバ６０から集まる評価項目情報を用いてそれぞれのゲームプレイの評価が続行されている。このとき、同じ評価項目で、前にスーパープレイと認定したゲームプレイより優れたゲームプレイが検出されたら（Ｓ３８）、スーパープレイの入れ替え処理を開始する。具体的には、コンテンツ提供サーバ６２は、新たに検出されたスーパープレイを実行しているストリーミングサーバ（図では第２ストリーミングサーバ６０ｂ）に、実況画像データの送信を要求する（Ｓ４０）。

要求を受けた第２ストリーミングサーバ６０ｂは、当該ゲームプレイを行っているユーザに対し、スーパープレイに認定されたことを通知するとともに、実況画像を公開することの是非を問いあわせる（Ｓ４２）。この処理は、図１２のＳ２４と同様である。ユーザから公開を許可された場合、第２ストリーミングサーバ６０ｂは、コンテンツ提供サーバ６２への実況画像データ送信を開始する（Ｓ４４）。図１２と同様、ユーザが公開を拒否した場合はＳ４４の処理は行わない。この場合、元のスーパープレイをそのままスーパープレイとしておいてもよい。

コンテンツ提供サーバ６２は、新たに認定したスーパープレイの公開が可能になった時点で、スーパープレイを入れ替える旨の通知を、元のスーパープレイを実行している第１ストリーミングサーバ６０ａと、それを観戦している観戦主体のクライアント端末１０ｂに送信する（Ｓ４６）。クライアント端末１０ｂへの通知は、その旨を記載したメッセージボックス画像をデータ送信中の実況画像に含めるなどして実現する。通知を受信した第１ストリーミングサーバ６０ａは、当該ゲームをプレイしているユーザに対し、スーパープレイの認定解除、および公開の対象から外れることをメッセージボックスなどで通知する（Ｓ４８）。

一方、クライアント端末１０ｂでは、コンテンツ提供サーバ６２から送信されたメッセージボックスを表示するなどして、スーパープレイが入れ替わった旨をユーザに通知する（Ｓ５０）。このときコンテンツ提供サーバ６２は、公開用画像に掲載中の観戦対象候補も入れ替える。そしてクライアント端末１０ｂへ送信する観戦対象の実況画像を、新たに認定されたスーパープレイのものに切り替える（Ｓ５２）。ただしクライアント端末１０ｂのユーザが、前のスーパープレイの観戦続行を希望する場合などは、当該ゲームプレイが終了したりユーザが観戦終了操作を行うまで切り替えを行わなくてもよい。

公開画像における掲載対象や、観戦主体のクライアント端末１０ｂへの送信対象を全て切り替えたら、コンテンツ提供サーバ６２は、前のスーパープレイを実行している第１ストリーミングサーバ６０ａにその旨を通知する。これに応じて第１ストリーミングサーバ６０ａは、コンテンツ提供サーバ６２への実況画像データの送信を停止する（Ｓ５４）。一方、クライアント端末１０ｂでは、新たなスーパープレイの実況画像の表示が開始される（Ｓ５６）。

図１２、図１３で示した処理手順を、実行中のゲームプレイについて継続して実施することにより、スーパープレイとして公開される実況画像が常に最新の情報に基づくものとなる。これによりプレイヤは、ゲーム自体の攻略や勝利とは異なる新たな目標、すなわちスーパープレイに認定され他人に観戦される、という目標をもってゲームに挑むことができるため、楽しみの幅が格段に広がる。また、優れたゲームプレイや面白いゲームプレイを観戦したい、と望むユーザは、膨大なゲームプレイの中から効率よく所望のゲームプレイを探し出すことができる。

図１４は、図１２のＳ２４、図１３のＳ５０において、ゲームプレイがスーパープレイとして認定された旨をプレイヤたるユーザに通知するため、ゲーム主体のクライアント端末１０に表示される画面例を示している。観戦対象として選定されるスーパープレイは進捗中のゲームであるため、通知はゲーム画面に重畳したり、ゲーム画面の表示領域と別の領域に表示したりする。図１４の場合は前者であり、まず画面２００ａにおいて、スーパープレイに認定されたことを通知するメッセージボックス２０２ａをゲーム画面上に表示している。続いて画面２００ｂにおいて、ゲームプレイ公開の是非を問うダイアログボックス２０２ｂを表示している。ユーザは公開を許可するか否かによって、文字列「Ｙｅｓ」または「Ｎｏ」の上にカーソルを移動させるなどして確定操作を行う。

このように、スーパープレイに認定されたことを通知することで、プレイヤは自分のプレイが評価に値するものであることを認識できる。通常は、プレイヤがこのような認識を持つ機会が少ないため、自分のプレイを公開したり自慢したりする、といった発想にも至りにくい。結果として、素晴らしいゲームプレイであっても他人の目に触れる可能性が少なくなる。本実施の形態では、スーパープレイを高精度に検出することにより、その存在が埋もれてしまうのを防ぐともに、プレイヤにも認識させることで、向上心や名誉心を与えることができる。

図１５は、図１２のＳ３０においてコンテンツ提供サーバ６２から送信され観戦主体のクライアント端末１０ｂにおいて表示される公開用画像の画面例を示している。この例では、ゲーム関連のホームページ上に観戦対象候補を表すことにより公開用画像としている。公開用画像２１４は、ホームページの題名２１６ａ、ゲームに関するニュースページ／関連グッズの販売ページ／動画閲覧用ページ、へのリンクを選択するためのＧＵＩ（Graphical User Interface）領域２１６ｂ、およびスーパープレイの実況画像表示領域２１６ｃを含む。

この例では、公開するスーパープレイを１つに絞ることで、公開用画像２１４に直接、観戦対象の実況画像が表示されているが、上述のとおり複数のスーパープレイのサムネイル画像をまず公開用画像として表示し、その中からユーザが選択することによって画像２１４のような実況画像を表示してもよい。なおフィルタリングにより、公開用画像２１４に表示する実況画像やサムネイルは、ユーザによって異なる場合がある。

図１６は、スーパープレイを選出し、その動画を動画主体のクライアント端末１０に出力する処理手順を示すフローチャートである。なおこの処理は、図１２、１３で示したゲームプレイ観戦のための処理と独立して実施してもよいし、両立させてもよい。後者の場合、図１６で示したいくつかの処理を省略できる。まず第１ストリーミングサーバ６０ａなど各ストリーミングサーバは、ゲームプレイが終了した時点など所定のタイミングで、当該ゲームプレイの評価項目情報をコンテンツ提供サーバ６２へ送信する（Ｓ６０）。ゲーム終了時点以外の所定のタイミングとは、上述の、動画として生成する分割単位の終点に到達した時点などであり、ロールプレイングゲームであればストーリーの章立てに相当する各ステージをクリアしたときなどである。

コンテンツ提供サーバ６２は、送信された評価項目情報に基づきゲームプレイを評価する（Ｓ６２）。そして所定の評価基準を満たしたゲームプレイをスーパープレイとして検出し（Ｓ６４）、当該評価項目情報の送信元のストリーミングサーバ（図では第１ストリーミングサーバ６０ａ）に、その旨を通知するとともに動画データの送信を要求する（Ｓ６６）。なお上述の通りＳ６６の処理に代え、ゲームプレイ中のユーザ操作のログ情報を取得してゲームプレイを再現することにより、コンテンツ提供サーバ６２内で動画データを作成してもよい。

また図１２、１３で示したように、ゲーム実行中にゲームプレイの評価を行っている場合は、Ｓ６０からＳ６４の処理は省略できる。さらにゲームプレイ中に観戦対象または観戦対象候補として実況画像データを取得済みの場合は、上述の通り、コンテンツ提供サーバ６２において実況画像データを動画データとして保存しておいてもよい。この場合、Ｓ６６の処理、および後述するＳ６８、Ｓ７０の処理も省略できる。

Ｓ６６において要求を受けた第１ストリーミングサーバ６０ａは、当該ゲームプレイを行っているユーザに対し、スーパープレイに認定されたことを通知するとともに、動画を公開することの是非を問いあわせる（Ｓ６８）。このときの表示画面は図１５に示したものと同様である。ユーザから公開を許可された場合、第１ストリーミングサーバ６０ａは、当該ゲームプレイの動画データをコンテンツ提供サーバ６２へ送信する（Ｓ７０）。送信された動画データは、プレイデータ記憶部９４に格納される。このとき、そのプレイデータがスーパープレイに選定された理由や、Ｓ６０で送信された評価項目情報を動画データと対応づける。

これにより、公開用画像における動画の特徴表示、評価項目の検索キーへの利用、挑戦プレイとの比較表示、などを効率化できる。なお図示は省略するが、ユーザが公開を拒否した場合はＳ７０の処理は行わない。これらの処理は、図１２のＳ２４およびＳ２６と同様であるが、対象が動画データであるため、第１ストリーミングサーバ６０ａからコンテンツ提供サーバ６２へのデータ送信は継続的なものではない点が異なる。

一方、ゲーム主体でないクライアント端末１０ｃは、動画閲覧を要求する操作がユーザよりなされたとき、コンテンツ提供サーバ６２に対し、閲覧対象候補の公開用画像のデータ送信を要求する（Ｓ７２）。この処理も観戦時と同様、ゲーム関連のホームページにおける動画閲覧用ページへのアクセス要求に応じて開始してもよい。例えばユーザが、図１５に示したホームページのＧＵＩ領域２１６ｂのうち、動画閲覧用ページへのリンクを表すＧＵＩを操作したときに開始する。

コンテンツ提供サーバ６２は、第１ストリーミングサーバ６０ａなどからデータ送信された動画をサムネイルなどで表した公開用画像を作成し、クライアント端末１０ｃにデータ送信する（Ｓ７４）。この公開用画像も観戦対象候補の公開用画像と同様、１つのゲームプレイの動画のサムネイルのみで構成してもよいし、他のスーパープレイの動画のサムネイルが含まれていてもよい。また動画サムネイルに限らず、静止画サムネイルや文字情報のみなどでもよい。また要求元のクライアント端末１０ｃのユーザ識別情報に基づきユーザ情報記憶部１０５から読み出したユーザの情報と、フィルタリング条件記憶部１０４から読み出したフィルタリング条件とをつき合わせ、表示対象をユーザごとに選別する。

クライアント端末１０ｃでは、データ送信された公開用画像を表示したうえ、ユーザが動画を選択したりして閲覧開始操作を行ったとき、コンテンツ提供サーバ６２に、選択された動画の閲覧開始を要求する（Ｓ７６）。コンテンツ提供サーバ６２は、要求された動画のデータをクライアント端末１０ｃへ送信する（Ｓ７８）。これにより、クライアント端末１０ｃでは選択された動画が表示される（Ｓ８０）。

図１７は、図１６のＳ７４においてコンテンツ提供サーバ６２から送信され動画閲覧主体のクライアント端末１０ｃにおいて表示される公開用画像の画面例を示している。この例では、ゲーム関連のホームページ内の動画閲覧用ページに閲覧対象候補を表すことにより公開用画像としている。公開用画像２１８は、動画ごとに、サムネイル画像２２０ａ、動画の特徴を表す文字情報２２０ｂ、当該動画を閲覧対象として選択するためのＧＵＩ２２０ｃ、をセットで表示する。動画の特徴は、当該動画がスーパープレイに認定された理由を表し、図９で示した評価基準の場合、評価単位と評価項目との組み合わせに対応する。

また閲覧対象候補が一度に表示できない場合は、スクロールバー２２０ｄを表示するなどしてユーザが画面をスクロールできるようにする。ユーザは表示されたサムネイル画像２２０ａや文字情報２２０ｂを参照し、閲覧したい動画を選択したら、対応するＧＵＩ２２０ｃを操作することにより動画再生を要求する。観戦の場合と同様、同じ評価項目で新たなスーパープレイが生まれたら、公開用画像に掲載する動画も入れ替える。このようにすることで、動画を見たいユーザに対して常に最新の情報を提供できる。

また公開用画像に掲載される動画は、上述の通り評価基準として設定されている評価単位と評価項目との組み合わせごとなど、多角的な評価に基づき選出されたものであり、実際に動画を見る前にその特徴が明確になっている。そこで図１７の公開用画像２１８に、ユーザが動画を検索できる機能を追加してもよい。このときの検索条件として、ステージ番号、敵の名前、最短攻略時間、最小ダメージ量、など評価項目に対応するものを選択可能とすることで、ユーザは、自分の状況や希望に合致した動画を効率よく見つけ出すことができる。

図１８は、図１６のＳ８０において、動画閲覧主体のクライアント端末１０ｃに表示される動画閲覧画面例を示している。この画面は、例えば図１７で示した公開用画像における、ある動画に対応するＧＵＩ２２０ｃに対するユーザの操作に応じて表示される。動画閲覧画面２２２には、閲覧対象の動画２２４ａ、動画の特徴を表す文字情報２２４ｂ、再生回数２２４ｃ、当該動画のゲームプレイが挑戦された回数とそのうちの防衛成功回数２２４ｄを表示する。再生回数２２４ｃに加え、挑戦回数と防衛成功回数２２４ｄを表示することにより、当該動画の注目度やゲームプレイがどの程度優れているかを一見して把握できる。

動画閲覧画面２２２にはさらに、この動画のゲームプレイへの挑戦を要求するためのＧＵＩ２２４ｅを表示する。同図の例では「このゲームプレイに挑戦する」なる文字列を含むボタン状のＧＵＩが表示されている。さらにその時点で挑戦プレイを順番待ちしているユーザの数も表示する。同図の例では「（現在４人待ち）」と表示されている。

例えば１つの動画のゲームプレイに対する挑戦プレイの並列実行数に適切な上限を与えることにより、挑戦プレイへの順番待ちの状態が発生しやすいようにすると、順番待ちの人数によっても動画の注目度を表すことができる。動画の注目度が上がるほど、さらに話題を呼んで閲覧者、挑戦者、挑戦プレイの観戦者の数が増加することが見込まれる。これにより、１つの動画のゲームプレイを巡って多くのユーザが楽しみを共有することができる。また同時に処理する挑戦プレイの数を制限すれば、それを実行するストリーミングサーバ６０の処理コストの増大を防止できる。

順番待ちが多人数になれば、挑戦プレイを望むユーザも時期を改めることが考えられるため、処理コストの時間的な分散にもつながる。ただし一人のユーザによって挑戦プレイ環境が独占されることがないように、１回の挑戦プレイに制限時間を設けたり、１日あたりの挑戦回数を制限したりしてもよい。

図１９は、閲覧主体であるクライアント端末１０ｃのユーザが、閲覧中の動画のゲームプレイに挑戦するときの処理手順を示すフローチャートである。まず図１６に示した処理手順により、クライアント端末１０ｃには閲覧対象として選択された動画が出力されている（Ｓ９０）。この状況においてユーザが、当該ゲームプレイへ挑戦する旨の入力を行ったら、クライアント端末１０ｃは、その旨の要求をコンテンツ提供サーバ６２へ送信する（Ｓ９２）。例えば図１８の動画閲覧画面におけるＧＵＩ２２４ｅに対するユーザの操作を検出することで挑戦プレイの要求を受け付ける。

するとコンテンツ提供サーバ６２は、ストリーミングサーバのいずれか（図では第１ストリーミングサーバ６０ａ）に、当該ゲームの実行および結果のストリーム転送を要求する（Ｓ９４）。なお挑戦プレイの並列実行数が上限を超える場合は、クライアント端末１０ｃを待ち行列に加える。具体的にはコンテンツ提供サーバ６２内のメモリに、動画ごとにキューを準備し、クライアント端末１０ｃの識別情報を格納する。並列実行数が減少したらＦＩＦＯ（First In First Out）の方式で読み出しゲームの実行を開始する。

一方、Ｓ９４で第１ストリーミングサーバ６０ａにストリーム転送を要求する際は、要求信号に、ゲームの識別情報、動画に対応する分割単位の識別情報、動画データに付加されている復帰情報を含める。ただしゲームの最初から挑戦する場合や、前の分割単位における成績などの影響を受けない分割単位の最初から挑戦する場合などは、復帰情報を含めなくてもよい。

分割単位ごとに生成した動画の最初から挑戦する場合や、動画を再生中、ユーザが挑戦プレイを要求したタイミングに対応する場面から挑戦する場合は、復帰情報に基づきゲームの処理を開始する。動画の途中から挑戦する場合は、挑戦プレイ要求操作がなされた時点で表示されていた画像フレームの番号や再生開始からの経過時間などを取得する。そして元のゲームプレイ中、そのタイミングの直前または直後で記録された復帰情報に基づきそこからゲームを開始する。このためコンテンツ提供サーバ６２は、挑戦プレイが要求された動画データに付加された復帰情報から、挑戦プレイ要求操作に対応する復帰情報を抽出し、Ｓ９４で送信するストリーミング要求信号に含める。

第１ストリーミングサーバ６０ａは、指定されたゲームのアプリケーションを起動し、指定されたタイミングから処理を開始する。そして出力データを順次生成、出力することにより、コンテンツ提供サーバ６２へのストリーム転送を開始する（Ｓ９６）。ゲームの途中から開始する場合に復帰情報を利用することにより、スーパープレイと認定されたゲームプレイと同じ条件での挑戦が可能となる。

ただし必ずしも全て同じ条件でゲームを開始しなくてもよい。例えば難易度を可変とし、スーパープレイよりさらに高い難易度、または低い難易度をユーザが設定できるようにすることにより、スーパープレイと比較して自分がどの程度の腕前であるのかユーザ自身が客観的に確認できるようにしてもよい。あるいはゲームを開始する場面のみを統一し、それ以外の条件は、挑戦者たるユーザが過去に同じゲームを実行した際の条件に合わせるようにしてもよい。この場合、コンテンツ提供サーバ６２は、全てのユーザのゲームプレイの復帰情報を保存しておき、挑戦プレイを要求したクライアント端末１０ｃの識別情報、あるいはそのユーザの識別情報などから、今回の挑戦者が過去に行ったゲームプレイの復帰情報を抽出する。

そして第１ストリーミングサーバ６０ａへゲームの実行を要求する際、そのように抽出した挑戦者自身の復帰情報を含める。これにより、スーパープレイとして公開されている動画と同じ場面から、自分のそれまでのゲーム状況を反映してゲームを開始することができる。スーパープレイの復帰情報の一部と、挑戦者の復帰情報の一部を組み合わせて一つの復帰情報とし、それに基づきゲームを開始してもよい。例えば得点やゲームの状況についてはスーパープレイのものを反映させ、ゲームに登場するキャラクタモデルや服装は挑戦者が作成したものを用いるようにしてもよい。これにより、愛着のあるキャラクタでの挑戦が可能となる。

これらのバリエーションは、ゲーム作成者が準備したもののなかから、挑戦者たるユーザが選択できるようにしてもよいし、ゲームごとに固定としてもよい。前者の場合、ゲームを最初にプレイしたときにユーザが設定したものをコンテンツ提供サーバ６２またはクライアント端末１０ｃで記録しておき必要に応じて読み出してもよいし、挑戦プレイの要求に応じてダイアログボックスなどでユーザに問いあわせてもよい。

一方、挑戦者のクライアント端末１０ｃと異なるクライアント端末１０ｂは、挑戦プレイの観戦を要求する操作がユーザよりなされたとき、コンテンツ提供サーバ６２に対しその旨を要求する（Ｓ９８）。なおＳ９８の処理は、図１２で示した観戦要求と同様、まず観戦対象候補を表した公開用画像のデータを要求し、そこからユーザが選択した挑戦プレイの観戦を要求するようにしてもよい。

コンテンツ提供サーバ６２は、第１ストリーミングサーバ６０ａから送信された出力データを用いて挑戦プレイの実況画像のデータを生成し、挑戦者のクライアント端末１０ｃおよび観戦主体のクライアント端末１０ｂにストリーム転送する（Ｓ１００）。これにより、クライアント端末１０ｃおよびクライアント端末１０ｂでは、挑戦プレイの実況画像が出力される（Ｓ１０２、Ｓ１０４）。

挑戦者のクライアント端末１０ｃでは、ゲームに対するユーザ操作がなされる都度、その入力情報を第１ストリーミングサーバ６０ａに送信する（Ｓ１０６）。第１ストリーミングサーバ６０ａはそれに応じてゲームを進捗させながら出力データをコンテンツ提供サーバ６２に送信し続け、コンテンツ提供サーバ６２が実況画像を更新していく（Ｓ１００）。これにより、クライアント端末１０ｃおよびクライアント端末１０ｂの実況画像も更新されていく（Ｓ１０２、Ｓ１０４）。

図２０は、図１９のＳ１０４において挑戦プレイの観戦主体のクライアント端末１０ｂに表示される挑戦プレイ観戦画面例を示している。この画面は、挑戦プレイを要求したユーザが、順番待ちの間に、他のユーザの挑戦プレイを観戦している状況を想定している。ただし自分の挑戦プレイの要求と関わりなく他人の挑戦プレイを観戦できるようにしてもよい。なお挑戦主体のクライアント端末１０ｃにおいて表示される、自分の挑戦プレイの実況画像表示画面も、同図に示したものと同様の構成としてよい。

挑戦プレイ観戦画面２２６には、挑戦プレイの実況画像２２８ａ、挑戦されているゲームプレイの特徴と挑戦者を示す文字情報２２８ｂ、元のスーパープレイと現在の挑戦プレイとのリアルタイムの比較情報２２８ｃを表示する。この例では、「第１ステージ」の攻略時間が最短のスーパープレイに挑戦しているため、挑戦プレイの「第１ステージ」開始からの時間を計測し、スーパープレイの攻略時間最短記録に達するまでの残り時間を表示している。

もし攻略時間最短記録に達する前に「第１ステージ」を攻略できたら、挑戦プレイがスーパープレイに勝利したことになる。この場合、当該挑戦プレイを新たなスーパープレイとし、動画を公開用画像に掲載する。このときのおよその処理手順は図１６で示したものと同様であるが、コンテンツ提供サーバ６２は挑戦プレイの出力データを取得済みであり、評価基準も限定的であるため、データ送受信や評価に係る処理を簡略化できる。なお記録を抜かれた元のスーパープレイは、それまでの防衛率や挑戦プレイ希望者数などに応じてスーパープレイから除外するか否かを決定してよい。

スーパープレイに勝利した挑戦者には、次回の通常のゲームプレイにおいて貴重なアイテムが付与されたり、ボーナスポイントが付与されたりするようにしてもよい。与えるアイテムやポイントは、挑戦したスーパープレイの難易度やそれまでの防衛率などによって変化させてもよい。また比較情報２２８ｃは図示するものに限らない。スーパープレイとなった要因である評価項目以外の項目についても比較表などの形式で表示してもよい。あるいはスーパープレイの動画自体を挑戦プレイの実況画像２２８ａと並べて表示してもよい。速さを競うレーシングゲームなどの場合は特に、画像そのものを比較することにより一見して優劣を把握できる。この場合も各画像には、比較のための文字情報や数値を表示するようにしてもよい。

挑戦プレイ観戦画面２２６にはさらに、この観戦画面を見ているユーザが挑戦プレイの順番待ちである場合に、自分の番が到来するまでの順番待ち人数の現在値を示す文字情報２２８ｄを表示する。これにより、自分の挑戦プレイの順番が近づいてくることに対する高揚感とともに他人の挑戦プレイを観戦できる。上述したように、単にスーパープレイの動画を閲覧するばかりでなく、それに挑戦する機会を与え、さらにその挑戦プレイを観戦できるようにすることで、ゲームの内容とは異種の面白さ、楽しさを与えることができる。また１つのスーパープレイを巡って多人数が同時に集まることにより、動画公開の場を活性化させることができる。

なお図１８乃至２０は、動画の閲覧中に挑戦プレイを要求する態様について示しているが、ゲームプレイを観戦中や観戦終了後に、挑戦プレイを要求できるようにしてもよい。この場合、図１５で示した観戦用の公開用画像２１４に、図１８で示したような挑戦を要求するためのＧＵＩを表示する。この場合でも動画の場合と同様の処理で、図２０と同様の挑戦プレイの実況画面を表示することができる。なお図２０で示したような挑戦プレイ観戦画面を見ているユーザの番が到来した場合、同じ画面（ブラウザ）上の実況画像２２８ａの表示領域を当該ユーザの挑戦プレイの実況画像に切り替える。ゲームプレイを観戦中や動画の閲覧中にすぐさま挑戦プレイを行える状況においても同様に、同じブラウザ上で当該挑戦プレイの実況画像へ表示を切り替える。これにより、観戦中や動画の途中から挑戦プレイを開始する場合は、観戦中、閲覧中のプレイ画像がシームレスに自分の挑戦プレイの画像に移行する。

図２１は挑戦プレイ観戦画面の別の例を示している。この例は前提として、１つのスーパープレイに対し複数の挑戦者が同時に挑戦することを許容している。つまり複数のストリーミングサーバ６０で複数の挑戦者の挑戦プレイを実行し、その出力データをコンテンツ提供サーバ６２が集約することにより、複数の実況画像を含む挑戦プレイ観戦画面を構築する。個々の挑戦者が操作する挑戦主体のクライアント端末１０で表示する画面は、同図の画面と同様の構成としてもよいし、自分の挑戦プレイの実況画像のみ、あるいは自分の挑戦プレイの実況画像と挑戦対象のスーパープレイの動画のみ、などとしてもよい。

この例の挑戦プレイ観戦画面２３０は、中央にスーパープレイの動画２３２ａを表示し、それを囲むように８つの挑戦プレイの実況画像２３２ｂを表示している。さらに、挑戦されているゲームプレイの特徴と挑戦者数示す文字情報２３２ｃを表示している。この場合、挑戦プレイは全て同じ場面、例えばスーパープレイの動画の最初の場面から一斉に開始するようにする。当然、スーパープレイの動画も挑戦プレイの開始とともに再生を開始する。これにより、スーパープレイを含む全てのゲームプレイの戦況を比較することができる。

このようにすることで、スーパープレイへの挑戦のみならず、他の挑戦者との競争も発生することになり、観戦や挑戦をよりスリリングなものとできる。なお画像の配置や数は特に限定されない。また、挑戦者のアバターや、現在の得点、戦況などを画像や文字で各実況画像に重畳するなどして表示してもよい。これにより、観戦者が特定の挑戦者を応援できるほか、ゲーム画像ではわかりにくい比較が容易に行える。さらに挑戦プレイの途中で、所定の基準により脱落者を選ぶことで、挑戦プレイの数を減らしていくようにしてもよい。

例えばスーパープレイの得点と所定量以上の差がついた挑戦プレイは、ゲームの途中であっても強制的に終了する。そして対応する実況画像を表示対象から除外する。実況画像の数が減るほど、残った実況画像の面積を大きくしていくと、サバイバルゲームのような迫力が生まれ観戦をより面白くすることができる。挑戦プレイを１つまで減らすことにより、最終的にはスーパープレイの動画との一対一の勝負にしてもよいし、所定数まで減らしたときに残った挑戦プレイは最後までプレイできるようにしてもよい。

以上述べた本実施の形態によれば、クライアント端末におけるユーザ操作に応じてサーバ側でゲーム画像を生成しそのデータをクライアント端末に送信するシステムにおいて、サーバが、ゲームの状況によって各ゲームプレイを評価し、優れたゲームプレイをスーパープレイとして選定する。選定されたスーパープレイの情報をホームページなどで公開し、他のユーザが観戦したり閲覧したりできるようにする。これにより、日々、膨大な数のゲームプレイが行われても、公開される価値のあるゲームプレイを公平な評価基準で精度よく抽出できる。結果として観戦や動画閲覧を希望するユーザは、検索などに係る手間や時間を最小限に抑えながら、良質のコンテンツを容易に楽しむことができる。

評価に用いる項目は、ゲームの内容に沿って多面的に設定する。これにより、実際に観戦／閲覧する前に中身についての特徴を把握することができる。また評価項目を細かく設定し、それぞれに対しスーパープレイを選定することにより、ユーザの様々なニーズに合致したゲームプレイや動画を効率よく見つけ出すことができる。さらに、ゲームプレイの情報がサーバに集約される環境を利用しているため評価対象が広範囲に渡り、自分のゲームプレイを他人に見せるといった発想に至らないプレイヤのゲームプレイであっても、公開の場を提供することができ、観戦者／閲覧者との好適なマッチングができる。

また優れたゲームプレイを漏れなく抽出し、プレイヤにその事実を通知するため、ゲームの楽しみとは異なる目標やモチベーションを与えることができる。また動画閲覧中に、当該動画のスーパープレイへの挑戦の機会を与え、それも他のユーザによって観戦できるようにする。これにより、単にスーパープレイに選定されるのを待つばかりでなく、衆目の中でスーパープレイに勝利する、という特別な機会に自ら挑戦することができる。

この場合、挑戦は、オンラインで接続中のプレイヤのみでなされるのでなく、スーパープレイの動画、という固定的なコンテンツを軸にして構築されるため、ゲームプレイの質が維持できるとともに、挑戦したいユーザ、それを観戦したいユーザが流動化しにくく、人が集まりやすい。結果として、常に活気にあふれた場をネットワーク上に構築することができる。このとき挑戦プレイの並列実行数を制限することにより、サーバの処理コストの増大を防止できるとともに、順番待ちの人数によっても盛り上がりを表現できる。

以上、本開示を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解されるところである。

例えば、本実施の形態では、まず閲覧対象候補を表した公開用画像を表示し、それに対するユーザの選択入力に応じて閲覧対象の動画を再生したが、動画再生のきっかけはこれに限らない。例えば同じ場面で連続して失敗するなど苦境に陥っているプレイヤに対し、成功のためのヒントとなる動画の閲覧を促す。この場合、同じ場面での失敗数が所定数に到達したら、コンテンツ提供サーバ６２は、当該場面に対応するスーパープレイを抽出し、その動画の閲覧を勧奨するメッセージボックスや、再生のためのＧＵＩを表示するようにストリーミングサーバ６０に要求する。

スーパープレイは場面ごと、敵ごと、などで選定されており、評価単位によって武器などの条件も判明するため、レベルや条件も合致した適切な動画を容易に抽出できる。また、そのようにしてスーパープレイの動画を閲覧したユーザが自分のゲームを再開する際は、その動画における状況を反映させた状態から開始するようにしたり、獲得アイテムを増やしたり、成功の助けになるキャラクタを登場させたりして、ゲームの内容や条件が有利になるようにしてもよい。このようにすることで、ユーザは困難な状況を打開しやすくなり、ゲームに対するモチベーションを維持することができる。

また本実施の形態では、スーパープレイの選定を、プレイヤの意思と関わりなく自動で行うことにより、スーパープレイを確実に抽出するようにしたが、プレイヤの意思を反映させるようにしてもよい。例えば、ゲームプレイ中に、スーパープレイの認定に挑戦するための場面を設け、ユーザが挑戦した場合にそのプレイを評価対象としてもよい。あるいはスーパープレイ認定のための評価を受けるか否かの選択を、ゲーム開始時などにユーザに入力させるようにしてもよい。このようにすると、あくまで個人的にゲームを楽しみたいユーザにも配慮することができる。

１ 情報処理システム、 １０ クライアント端末、 １２ ＣＰＵ、 １４ ＧＰＵ、 １６ メインメモリ、 ２２ 通信部、 ２４ 記憶部、 ２６ 出力部、 ２８ 入力部、 ３０ ゲーム環境提供サーバ、 ５２ 入力部、 ５４ 入力情報送信部、 ５６ 出力データ受信部、 ５８ 出力データ処理部、 ５９ 出力部、 ６０ ストリーミングサーバ、 ６２ コンテンツ提供サーバ、 ７０ 制御情報受信部、 ７２ 入力情報受信部、 ７４ 情報処理部、 ７６ 出力データ生成部、 ７８ メタデータ生成部、 ８０ プレイデータ記憶部、 ８２ 出力データ送信部、 ８４ 通知情報生成部、 ９０ プレイデータ受信部、 ９４ プレイデータ記憶部、 ９６ プレイ評価部、 ９８ ストリーミングサーバ制御部、 １００ 公開用画像生成部、 １０２ 評価基準記憶部、 １０４ フィルタリング条件記憶部、 １０５ ユーザ情報記憶部、 １０６ 入力情報受信部、 １０８ 出力データ送信部。

Claims (14)

1. コンテンツ提供サーバがネットワークを介してクライアント端末にコンテンツを提供する方法であって、
   クライアント端末におけるユーザ操作に応じて進捗するコンピュータゲームの進捗状況を示すプレイデータを取得するステップと、
   前記プレイデータに基づき所定の評価項目ごとにゲームプレイを評価するステップと、
   評価結果に従い抽出したゲームプレイの動画のデータを取得するステップと、
   前記動画のデータをネットワークを介してクライアント端末に配信するステップと、
   を含むコンテンツ提供方法。
2. 前記コンテンツ提供サーバが、
   前記動画を配信したクライアント端末のいずれかから、当該動画に対応するゲームの実行要求を受け付けるステップと、
   前記対応するゲームを実行し、実行要求元のクライアント端末におけるユーザ操作に応じてゲームを進捗させてリアルタイムのゲーム画像のデータを生成するステップと、
   前記リアルタイムのゲーム画像のデータを前記実行要求元のクライアント端末に即時送信するステップと、
   をさらに含む請求項１に記載のコンテンツ提供方法。
3. 前記コンテンツ提供サーバが、
   前記実行要求によってなされたゲームプレイを、前記動画に対応するゲームプレイと、前記評価項目のいすれかによって比較して優劣を決定するステップをさらに含み、
   前記ゲームプレイの動画のデータを取得するステップは、決定した優劣の結果によって、抽出するゲームプレイを変化させる請求項２に記載のコンテンツ提供方法。
4. 前記即時送信するステップは、実行要求元のクライアント端末以外のクライアント端末へも前記リアルタイムのゲーム画像のデータを逐次送信する請求項２または３に記載のコンテンツ提供方法。
5. 前記ゲームの実行要求を受け付けるステップにおいて、ゲームの並列実行数に設定した上限以上の実行要求を受け付けたときは、ゲームの実行を要求するクライアント端末の待ち行列を形成し、
   前記即時送信するステップは、待ち行列に属するクライアント端末に対し、前記リアルタイムのゲーム画像のデータを逐次送信するとともに、前記待ち行列における当該クライアント端末の位置に係る情報の表示を要求する請求項２から４のいずれかに記載のコンテンツ提供方法。
6. 前記配信するステップは、前記動画のデータとともに、対応するゲームの実行要求によって過去に実行された他のゲームプレイと当該動画に対応するゲームプレイとの比較結果の累積情報を表示させるための情報を配信する請求項３から５のいずれかに記載のコンテンツ提供方法。
7. 前記配信するステップは、前記動画のデータとともに、対応するゲームの実行要求によって過去に実行された他のゲームプレイの総数を表示させるための情報を配信する請求項３から６のいずれかに記載のコンテンツ提供方法。
8. 前記リアルタイムのゲーム画像のデータを生成するステップは、ゲームを並列に実行することにより、複数のクライアント端末にそれぞれ対応する複数のゲームプレイを表す複数のリアルタイムのゲーム画像のデータを生成し、
   前記即時送信するステップは、前記複数のリアルタイムのゲーム画像のデータを即時送信するとともに、前記複数のリアルタイムのゲーム画像を一覧表示させるためのデータを送信する請求項２から７のいずれかに記載のコンテンツ提供方法。
9. 前記コンテンツ提供サーバが、
   前記リアルタイムのゲーム画像のデータを生成するステップにおけるゲーム進捗中に、前記複数のゲームプレイと前記動画に対応するゲームプレイとを前記評価項目のいずれかによって継続的に比較するステップをさらに含み、
   前記即時送信するステップは、前記継続的に比較するステップにおける比較結果に基づき、所定の規則により、データ送信するリアルタイムのゲーム画像の数を減らしていく請求項８に記載のコンテンツ提供方法。
10. 前記評価するステップは、進捗中のゲームプレイを評価し、
    前記配信するステップは、評価結果に従い抽出した進捗中のゲームプレイのリアルタイムのゲーム画像のデータを配信する請求項１に記載のコンテンツ提供方法。
11. 前記コンテンツ提供サーバが、
    前記評価するステップにおける、複数の評価項目に対する評価結果に従いそれぞれ抽出した複数のゲームプレイの動画に対応する情報を一覧表示した公開用画像を生成するステップと、
    前記公開用画像のデータをクライアント端末に配信するステップと、
    前記公開用画像を表示したクライアント端末から、前記評価項目をキーとする検索を行うユーザ操作に係る情報を受け付けるステップと、をさらに含み、
    前記配信するステップは、前記ユーザ操作に係る情報に基づき、前記キーとなる評価項目に対し抽出したゲームプレイの動画のデータを検索元のクライアント端末に送信する請求項１に記載のコンテンツ提供方法。
12. 前記配信するステップは、当該ゲームに設定されたフィルタリング条件と、配信先のクライアント端末を操作するユーザごとの当該ゲームに関連する個人情報と、を記憶装置から読み出し照合することにより、配信対象の動画のデータをクライアント端末ごとに決定する請求項１に記載のコンテンツ提供方法。
13. クライアント端末におけるユーザ操作に応じて進捗するコンピュータゲームの進捗状況を示すプレイデータを取得するプレイデータ受信部と、
    前記プレイデータに基づき所定の評価項目ごとにゲームプレイを評価するプレイ評価部と、
    前記プレイ評価部における評価結果に従い抽出したゲームプレイの動画のデータを取得しクライアント端末に配信するデータ配信部と、
    を備えたコンテンツ提供サーバ。
14. コンピュータゲームのゲームプレイの動画の閲覧要求をサーバへ送信する入力情報送信部と、
    前記動画の閲覧要求に応じてサーバから送信された動画のデータを出力する出力部と、
    を備えたクライアント端末と、
    複数のクライアント端末のそれぞれにおけるユーザ操作に応じて進捗するコンピュータゲームの進捗状況を示すプレイデータを取得するプレイデータ受信部と、
    前記プレイデータに基づき所定の評価項目ごとにゲームプレイを評価するプレイ評価部と、
    前記プレイ評価部における評価結果に従い抽出したゲームプレイの動画のデータを取得し前記動画の閲覧要求の送信元のクライアント端末に送信するデータ配信部と、
    を備えたサーバと、
    を含むコンテンツ提供システム。

Images