JP6592046B2 - 情報処理装置およびコンテンツデータ生成方法 - Google Patents

Description

本発明は、ゲームなどのコンテンツ画像を視聴する技術、またコンテンツ画像の視聴を実現するための技術に関する。

多人数でのコミュニケーションツールとして、様々なソーシャル・ネットワーキング・サービス（ＳＮＳ：Social Networking Service）が活用されている。またユーザが作成またはキャプチャした動画を共有するサービスも普及しており、ユーザは、ネットワーク上で様々な情報を他のユーザと共有できるようになっている。動画共有サイトは、ユーザが動画を投稿し、また閲覧する環境を提供している。

ユーザが動画を投稿する際には、ユーザが、動画タイトルやコメントなどのメタデータを入力して、動画データとともに動画共有サイトに送信する。またユーザが動画を閲覧する際には、動画共有サイトに検索キーワードを入力して、検索された動画リストから所望の動画を選択することで、動画データが配信される。

しかしながら従来の動画共有サービスにおいては、ユーザが、所望の動画にアクセスすることが容易でないという問題がある。これは、動画検索の際に、ユーザが適切な検索キーワードを入力することが難しいことが一つの理由であり、また、動画共有サイトに投稿された動画に、適切なメタデータが付加されていないことも別の理由として存在する。そのため、従来の動画共有サイトは、多くの動画を蓄積していても、ユーザの要求に沿った動画を提供できずにいるという課題を有している。

そこで本発明は、サーバから、ユーザの状況にマッチしたコンテンツ画像を提供可能な環境を生成するための技術を提供することを目的とする。

上記課題を解決するために、本発明のある態様の情報処理装置は、実行中のアプリケーションの画像データを記録する記録部と、実行中のアプリケーションから、アプリケーションの実行状態を示すメタデータを取得するメタデータ取得部と、記録部に記録されたアプリケーション画像データのうち、開始点から終了点までのアプリケーション画像データを、コンテンツデータとして抽出するコンテンツ生成部と、を備える。コンテンツ生成部は、メタデータが取得されたタイミングを示す時間情報を参照して、開始点から終了点までの期間に収集されたメタデータを、コンテンツデータに付加する。

本発明の別の態様もまた、情報処理装置である。この装置は、サーバに、実行中のアプリケーションの画像データを送信する送信処理部と、実行中のアプリケーションから、アプリケーションの実行状態を示すメタデータを取得するメタデータ取得部と、を備える。送信処理部は、アプリケーション画像データをサーバに送信している間にメタデータ取得部が取得したメタデータを、サーバに送信する。

本発明のさらに別の態様は、コンテンツデータ生成方法である。この方法は、実行中のアプリケーションから、アプリケーションの実行状態を示すメタデータを取得するステップと、実行中のアプリケーションの画像データを記録する記録部から、開始点から終了点までの画像データを、コンテンツデータとして抽出するステップと、メタデータが取得されたタイミングを示す時間情報を参照して、開始点から終了点までの期間に収集されたメタデータを、コンテンツデータに付加するステップと、を備える。

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

本発明の情報処理技術によると、サーバから、ユーザの状況にマッチしたコンテンツ画像を提供可能な環境を生成するための技術を提供することを目的とする。

本発明の実施例にかかる情報処理システムを示す図である。 （ａ）は、入力装置上面の外観構成を示す図であり、（ｂ）は、入力装置奥側側面の外観構成を示す図である。 情報処理装置の機能ブロック図である。 コンテンツ送信機能を実現する情報処理装置の内部構成を示す図である。 ゲーム画面の一例を示す図である。 （ａ）は、イベントの発生時刻がコンテンツデータを切り出す開始点となる例を示す図であり、（ｂ）は、２つのイベントコードで開始点と終了点が指定される例を示す図である。 ゲーム画面上に重畳表示される編集画面の一例を示す図である。 編集サーバの内部構成を示す図である。 コンテンツ受信機能を実現する情報処理装置の内部構成を示す図である。 ゲーム画面の一例を示す図である。 コンテンツサーバの内部構成を示す図である。 検索結果画面の一例を示す図である。 ダウンロードしたプレイ動画の一例を示す図である。 ダウンロードしたプレイ動画の一例を示す図である。

図１は、本発明の実施例にかかる情報処理システム１を示す。情報処理システム１は、ユーザＡが使用する情報処理装置１０と、別のユーザが使用する情報処理装置５ａ、５ｂと、コンテンツサーバ１２とを備え、これらはインターネットやＬＡＮ（Local Area Network）などのネットワーク３を介して接続している。コンテンツサーバ１２は、ゲーム動画などのコンテンツに関するサービスを提供し、ここでは配信サーバ１４、編集サーバ１６および検索サーバ１８を統括した概念として示されている。配信サーバ１４は、ユーザに対してゲーム動画などのアプリケーション画像を配信するサービスを提供する。たとえば配信サーバ１４は、共有動画サイトであってよく、ユーザにより投稿された動画データや、編集サーバ１６により編集された動画データを配信する。編集サーバ１６は、ユーザから提供される動画データを編集するサービスを提供する。検索サーバ１８は、ユーザからの動画検索要求に応じて配信サーバ１４から提供する動画の候補をユーザに提示するサービスを提供する。

配信サーバ１４、編集サーバ１６および検索サーバ１８は、別個のサーバとして構成され、各々がネットワーク３を介して通信してもよいが、これらのサーバは一体として形成されてもよい。また配信サーバ１４と編集サーバ１６とが一体として形成されてもよく、配信サーバ１４と検索サーバ１８とが一体として形成されてもよく、編集サーバ１６と検索サーバ１８とが一体として形成されてもよい。たとえば配信サーバ１４が、動画データを蓄積し、ユーザにより指定された動画データを配信するという単純な機能しか有しない場合には、編集サーバ１６および検索サーバ１８が、動画データに付加されるメタデータを処理するためのインテリジェントな知識サーバとして構成されてもよい。なお動画のメタデータが動画データに埋め込まれていない場合には、編集サーバ１６ないしは検索サーバ１８が、配信サーバ１４が蓄積する動画データとは別に、動画データのメタデータを蓄積して、動画データの編集処理ないしは検索処理を行ってもよい。

アクセスポイント（以下、「ＡＰ」とよぶ）８は、無線アクセスポイントおよびルータの機能を有し、情報処理装置１０は、無線または有線経由でＡＰ８に接続して、ネットワーク３上のコンテンツサーバ１２と通信可能に接続する。情報処理装置５ａ、５ｂ（以下、特に区別しない場合には「情報処理装置５」とよぶ）も同様にコンテンツサーバ１２と通信可能に接続する。なお情報処理装置１０と情報処理装置５は、同種の装置であってもよいが、別種の装置であってもよく、少なくともコンテンツサーバ１２からコンテンツを提供されて、コンテンツを再生表示できるものであればよい。

情報処理装置１０は、ユーザが操作する入力装置６と無線または有線で接続し、入力装置６はユーザの操作結果を示す操作情報を情報処理装置１０に出力する。情報処理装置１０は入力装置６から操作情報を受け付けるとシステムソフトウェアやアプリケーションソフトウェアの処理に反映し、出力装置４から処理結果を出力させる。情報処理システム１において情報処理装置１０はゲームを実行するゲーム装置であり、入力装置６はゲームコントローラなど情報処理装置１０に対してユーザの操作情報を供給する機器であってよい。ゲームをプレイするためにユーザは情報処理装置１０のＯＳ（システムソフトウェア）にログインする。ログインユーザは、情報処理装置１０において登録されているユーザアカウントによって管理される。

配信サーバ１４は、情報処理装置１０や情報処理装置５からアップロードされる画像データを共有するためのサービスを提供する。配信サーバ１４は、蓄積した画像データをユーザからの要求に応じてオンデマンド配信し、またユーザからリアルタイムで提供される画像データをライブ配信する機能を有する。情報処理システム１において配信サーバ１４の数は１つに限定されるものではなく、それ以上存在してよい。配信サーバ１４により提供される画像配信サービスは、対象とするユーザを登録会員に限定してもよく、また一般に開放してもよい。

編集サーバ１６は、ユーザから提供される画像データを編集する機能をもつ。たとえば編集サーバ１６は、アプリケーションにおいて発生したイベントを特定するイベントコードに基づいて、画像データから、イベントコードに対応する箇所をコンテンツデータとして抽出し、編集したコンテンツデータを生成する。イベントコードは、イベントコードに付随する時間情報とともに、画像データからコンテンツデータを抽出するための開始点および終了点を定めるものであり、編集サーバ１６は、イベントコードに基づいてコンテンツデータを抽出する。たとえば編集サーバ１６が、野球ゲームの動画像から、ホームランを打ったシーンを切り出して、所定時間（たとえば１０秒間）のイベント動画（コンテンツ）を生成してもよい。編集サーバ１６は、野球ゲームにおける「ホームランを打った」ことを示すイベントコードおよびその時間情報をもとに、野球ゲームのプレイを記録した動画像データの中から切り出すシーンの開始点と終了点を特定して、動画像データからホームランを打ったシーンを抽出したホームラン動画を生成する。編集サーバ１６は、ユーザからリアルタイムで提供される画像データとイベントコードを用いて、オンタイムで画像編集を行ってもよいが、画像データとイベントコードとが全て提供された後に、バッチ処理で、または必要に応じたタイミングで、画像編集を行ってもよい。編集サーバ１６は、生成したコンテンツデータを、配信サーバ１４に提供して、配信サーバ１４が配信できるようにする。

検索サーバ１８は、ユーザからコンテンツの検索要求を受け取ると、配信サーバ１４に記録されているコンテンツのメタデータを参照して、コンテンツを検索する。コンテンツの検索要求には、ユーザの状況を示す情報、たとえばユーザがプレイしているゲームのステータスデータが含まれており、検索サーバ１８は、このステータスデータを、コンテンツのメタデータと比較することで、ユーザの状況に適したゲーム動画を検索する。なお検索サーバ１８は、検索効率を高めるために、コンテンツのメタデータを、コンテンツＩＤに紐付けて自ら保持していてもよい。

補助記憶装置２はＨＤＤ（ハードディスクドライブ）やフラッシュメモリなどの大容量記憶装置であり、ＵＳＢ（Universal Serial Bus）などによって情報処理装置１０と接続する外部記憶装置であってよく、内蔵型記憶装置であってもよい。出力装置４は画像を出力するディスプレイおよび音声を出力するスピーカを有するテレビであってよく、またコンピュータディスプレイであってもよい。出力装置４は、情報処理装置１０に有線ケーブルで接続されてよく、無線接続されてもよい。

撮像装置であるカメラ７は出力装置４の近傍に設けられ、出力装置４周辺の空間を撮像する。図１ではカメラ７が出力装置４の上部に取り付けられている例を示しているが、出力装置４の側方に配置されてもよく、いずれにしても出力装置４の前方でゲームをプレイするユーザを撮像できる位置に配置される。なおカメラ７はステレオカメラであってよい。入力装置６は複数のプッシュ式の操作ボタンや、アナログ量を入力できるアナログスティック、回動式ボタンなどの複数の入力部を有して構成される。

入力装置６のボタン構成について説明する。
［上面部の構成］
図２（ａ）は、入力装置上面の外観構成を示す。ユーザは左手で左側把持部７８ｂを把持し、右手で右側把持部７８ａを把持して、入力装置６を操作する。入力装置６の筐体上面には、入力部である方向キー７１、アナログスティック７７ａ、７７ｂと、４種の操作ボタン７６が設けられている。４種のボタン７２〜７５には、それぞれを区別するために、異なる色で異なる図形が記されている。すなわち、○ボタン７２には赤色の丸、×ボタン７３には青色のバツ、□ボタン７４には紫色の四角形、△ボタン７５には緑色の三角形が記されている。筐体上面上において、方向キー７１と操作ボタン７６の間の平坦な領域には、タッチパッド７９が設けられる。タッチパッド７９は、ユーザが押すことで下方に沈み込み、またユーザが手を離すと元の位置に復帰する押下式ボタンとしても機能する。

２つのアナログスティック７７ａ、７７ｂの間に機能ボタン８０が設けられる。機能ボタン８０は、入力装置６の電源をオンし、同時に入力装置６と情報処理装置１０とを接続する通信機能をアクティブにするために使用される。入力装置６が情報処理装置１０と接続した後は、機能ボタン８０は、情報処理装置１０にメニュー画面を表示させるためにも使用される。

ＳＨＡＲＥボタン８１は、タッチパッド７９と方向キー７１の間に設けられる。ＳＨＡＲＥボタン８１は、情報処理装置１０におけるＯＳないしはシステムソフトウェアに対するユーザからの指示を入力するために利用される。またＯＰＴＩＯＮＳボタン８２は、タッチパッド７９と操作ボタン７６の間に設けられる。ＯＰＴＩＯＮＳボタン８２は、情報処理装置１０において実行されるアプリケーション（ゲーム）に対するユーザからの指示を入力するために利用される。ＳＨＡＲＥボタン８１およびＯＰＴＩＯＮＳボタン８２は、いずれもプッシュ式ボタンとして形成されてよい。

［奥側側面部の構成］
図２（ｂ）は、入力装置奥側側面の外観構成を示す。入力装置６の筐体奥側側面の上側には、タッチパッド７９が筐体上面から延設されており、筐体奥側側面の下側には、横長の発光部８５が設けられる。発光部８５は、赤（Ｒ）、緑（Ｇ）、青（Ｂ）のＬＥＤを有し、情報処理装置１０から送信される発光色情報にしたがって点灯する。

筐体奥側側面において、上側ボタン８３ａ、下側ボタン８４ａと、上側ボタン８３ｂ、下側ボタン８４ｂとが長手方向の左右対称な位置に設けられる。上側ボタン８３ａ、下側ボタン８４ａは、それぞれユーザ右手の人差し指、中指により操作され、上側ボタン８３ｂ、下側ボタン８４ｂは、それぞれユーザ左手の人差し指、中指により操作される。図示されるように発光部８５が、右側の上側ボタン８３ａ、下側ボタン８４ａの並びと、左側の上側ボタン８３ｂ、下側ボタン８４ｂの並びの間に設けられることで、各ボタンを操作する人差し指または中指によって隠れることはなく、カメラ７は、点灯した発光部８５を好適に撮像することができる。上側ボタン８３はプッシュ式ボタンとして構成され、下側ボタン８４は回動支持されたトリガー式のボタンとして構成されてよい。

図３は、情報処理装置１０の機能ブロック図を示す。情報処理装置１０は、メイン電源ボタン２０、電源ＯＮ用ＬＥＤ２１、スタンバイ用ＬＥＤ２２、システムコントローラ２４、クロック２６、デバイスコントローラ３０、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０を有して構成される。

メインシステム６０は、メインＣＰＵ（Central Processing Unit）、主記憶装置であるメモリおよびメモリコントローラ、ＧＰＵ（Graphics Processing Unit）などを備える。ＧＰＵはゲームプログラムの演算処理に主として利用される。これらの機能はシステムオンチップとして構成されて、１つのチップ上に形成されてよい。メインＣＰＵは補助記憶装置２に記録されたゲームプログラムを実行する機能をもつ。

サブシステム５０は、サブＣＰＵ、主記憶装置であるメモリおよびメモリコントローラなどを備え、ＧＰＵを備えず、ゲームプログラムを実行する機能をもたない。サブＣＰＵの回路ゲート数は、メインＣＰＵの回路ゲート数よりも少なく、サブＣＰＵの動作消費電力は、メインＣＰＵの動作消費電力よりも少ない。サブＣＰＵは、メインＣＰＵがスタンバイ状態にある間においても動作し、消費電力を低く抑えるべく、その処理機能を制限されている。

メイン電源ボタン２０は、ユーザからの操作入力が行われる入力部であって、情報処理装置１０の筐体の前面に設けられ、情報処理装置１０のメインシステム６０への電源供給をオンまたはオフするために操作される。電源ＯＮ用ＬＥＤ２１は、メイン電源ボタン２０がオンされたときに点灯し、スタンバイ用ＬＥＤ２２は、メイン電源ボタン２０がオフされたときに点灯する。

システムコントローラ２４は、ユーザによるメイン電源ボタン２０の押下を検出する。メイン電源がオフ状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オン指示」として取得し、一方で、メイン電源がオン状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オフ指示」として取得する。

クロック２６はリアルタイムクロックであって、現在の日時情報を生成し、システムコントローラ２４やサブシステム５０およびメインシステム６０に供給する。

デバイスコントローラ３０は、サウスブリッジのようにデバイス間の情報の受け渡しを実行するＬＳＩ（Large-Scale Integrated Circuit）として構成される。図示のように、デバイスコントローラ３０には、システムコントローラ２４、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０などのデバイスが接続される。デバイスコントローラ３０は、それぞれのデバイスの電気特性の違いやデータ転送速度の差を吸収し、データ転送のタイミングを制御する。

メディアドライブ３２は、ゲームなどのアプリケーションソフトウェア、およびライセンス情報を記録したＲＯＭ媒体４４を装着して駆動し、ＲＯＭ媒体４４からプログラムやデータなどを読み出すドライブ装置である。ＲＯＭ媒体４４は、光ディスクや光磁気ディスク、ブルーレイディスクなどの読出専用の記録メディアである。

ＵＳＢモジュール３４は、外部機器とＵＳＢケーブルで接続するモジュールである。ＵＳＢモジュール３４は補助記憶装置２およびカメラ７とＵＳＢケーブルで接続してもよい。フラッシュメモリ３６は、内部ストレージを構成する補助記憶装置である。無線通信モジュール３８は、Bluetooth（登録商標）プロトコルやIEEE802.11プロトコルなどの通信プロトコルで、たとえば入力装置６と無線通信する。なお無線通信モジュール３８は、ＩＴＵ（International Telecommunication Union；国際電気通信連合）によって定められたＩＭＴ−２０００（International Mobile Telecommunication 2000）規格に準拠した第３世代（3rd Generation）デジタル携帯電話方式に対応してもよく、さらには別の世代のデジタル携帯電話方式に対応してもよい。有線通信モジュール４０は、外部機器と有線通信し、たとえばＡＰ８を介してネットワーク３に接続する。

本実施例の情報処理装置１０は、コンテンツサーバ１２にコンテンツを送信する機能と、コンテンツサーバ１２からコンテンツを受信する機能とを備える。以下、これらの２つの機能について説明する。

＜コンテンツ送信機能＞
情報処理装置１０は、コンテンツサーバ１２によるオンデマンド配信のためにコンテンツサーバ１２にコンテンツを送信し、またコンテンツサーバ１２によるライブ配信のためにコンテンツサーバ１２にコンテンツを送信する機能を有する。
図４は、コンテンツ送信機能を実現する情報処理装置１０の内部構成を示す。情報処理装置１０は、処理部１００および通信部１０２を備え、処理部１００は、アプリケーション処理部１１０、画像生成部１３０、コンテンツ生成部１５０、記録部１７０および共有処理部１９０を備える。アプリケーション処理部１１０は、アプリケーションに関する処理を行い、画像生成部１３０は、出力装置４に表示するための画像生成処理を行う。コンテンツ生成部１５０は、アプリケーション画像の編集に関する処理を行い、記録部１７０は、アプリケーションの画像データを、所定時間分を上限として記録する処理を行う。共有処理部１９０は、アプリケーションの画像データをコンテンツサーバ１２に送信する処理を行う。

図４において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

本実施例の情報処理システム１において、通信部１０２は、入力装置６においてユーザが入力部を操作した情報（以下、「操作情報」ともよぶ）を受信し、また処理部１００で生成または取得した画像データをコンテンツサーバ１２に送信する。ここで画像データは、画像生成部１３０において生成された画像データ、およびコンテンツ生成部１５０において編集された画像データ（コンテンツデータ）を少なくとも含む。通信部１０２は図３に示す無線通信モジュール３８および有線通信モジュール４０の機能を併せ持つ構成として表現され、無線通信モジュール３８は入力装置６との通信を担当し、有線通信モジュール４０はコンテンツサーバ１２との通信を担当する。

アプリケーション処理部１１０は、ゲーム実行部１１２、イベントコード通知部１１４およびステータスデータ通知部１１６を備える。ゲーム実行部１１２は、ユーザによる入力装置６の操作入力を受けてゲームを進行させるプログラムを実行する機能を有する。イベントコード通知部１１４は、ゲームの実行中に所定のイベントが発生すると、そのイベントを特定する情報（以下、「イベントコード」と呼ぶ）をコンテンツ生成部１５０に出力する。なおイベントは、ゲームごとに設定されており、たとえば野球ゲームであれば、「二死満塁になった」、「１イニング中に２点差を逆転した」、「盗塁した」、「ホームランを打った」など、様々なものが設定されてよい。イベントコード通知部１１４は、設定されたイベントが発生すると、そのイベントコードをコンテンツ生成部１５０に通知する機能をもつ。ステータスデータ通知部１１６は、ゲームのステータスデータをコンテンツ生成部１５０に通知する。ステータスデータ通知部１１６は、コンテンツ生成部１５０からの要求に応じてステータスデータをコンテンツ生成部１５０に通知してもよいが、たとえばステータスに変化があった場合に、変化後のステータスデータをコンテンツ生成部１５０に通知してもよい。このときステータスデータ通知部１１６は、変化前と変化後の差分となるステータスデータを通知してもよいが、変化後の全てのステータスデータを収集して通知してもよい。

ゲーム実行部１１２は、ユーザから入力装置６に入力された操作情報をもとに、仮想空間においてゲームキャラクタを動かす演算処理を行う。このようにゲーム実行部１１２はアプリケーション（ゲームプログラム）そのものを含む概念として表現されてもよい。ゲーム画像生成部１３２はレンダリング処理などを実行するＧＰＵ（Graphics Processing Unit）であってよく、ゲーム実行部１１２による処理結果を受けて、出力装置４に表示するアプリケーション（ゲーム）の画像データを生成する。図５は、出力装置４に表示されるゲーム画面の一例を示す。なお本実施例においてゲーム実行部１１２はゲームプログラムを実行するが、他の種類のアプリケーションプログラムを実行してもよい。

情報処理装置１０において記録部１７０は、記録制御部１７２、書込／読出部１７４およびリングバッファ１７６を有し、出力装置４に表示される画像をバックグランドで録画する機能を有する。ゲーム画像生成部１３２は、ゲーム画像データを生成して出力装置４に表示するが、記録部１７０は、その画像データをバックグランドで録画している。

記録制御部１７２は、書込／読出部１７４によるデータの書込および読出処理を制御する。書込／読出部１７４はリングバッファ１７６にデータを書き込み、またはデータを読み出す。記録部１７０におけるバックグランド録画は、リングバッファ１７６において行われる。記録制御部１７２は、補助記憶装置２の記憶領域の開始アドレスおよび終了アドレスを設定してリングバッファ１７６を生成する。このリングバッファ領域は、情報処理装置１０の出荷時に予め設定されていてよい。記録制御部１７２は、ゲーム画像生成部１３２で生成された、実行中のアプリケーションの画像データをリングバッファ１７６に記録する。記録制御部１７２はリングバッファ１７６に画像データを開始アドレスから予め定められたアドレス順に記録し、終了アドレスまでの記録が終了すると、開始アドレスに戻って上書き記録し、それを繰り返す。たとえばリングバッファ１７６は、最長３０分間のゲーム画像を記録するように設定され、記録されたゲーム画像には、時間情報（タイムスタンプ）が付与される。このタイムスタンプは、情報処理装置１０によるＯＳにより付与されてよい。表示画像データをリングバッファ１７６にバックグランド録画しておくことで、ゲーム中にイベントが発生したときに、コンテンツ生成部１５０が、イベント発生時よりも過去の画像データを含むコンテンツデータを生成できるようになる。

図５は、野球ゲームの実行画面を示す。ユーザは、入力装置６を操作して野球ゲームをプレイしている。ここでゲームの進行が、ゲームプログラムに設定されているイベントを発生させると、イベントコード通知部１１４が、そのイベントコードをコンテンツ生成部１５０に通知する。たとえばイベントは、「二死満塁になった」、「１イニング中に２点差を逆転した」、「盗塁した」、「ホームランを打った」など様々であり、ゲームに、様々なイベントを仕込んでおくことで、ゲーム画像共有サービスの充実を図れるようになる。

たとえば、野球ゲームの局面が、二死満塁となったとき、イベントコード通知部１１４は、「二死満塁になった」イベントの発生を示すイベントコードを、イベント発生時の時間情報とともにコンテンツ生成部１５０に通知する。したがってメタデータ取得部１５４は、実行中のアプリケーション（ゲームプログラム）から、アプリケーションにおいて設定されているイベントの発生を示すイベントコードを、その時間情報とともに自動取得する。このイベントコードは、後述するように、コンテンツデータに付加されるメタデータを構成する。

イベントコードが通知されると、メタデータ取得部１５４は、ステータスデータ通知部１１６に、現在のステータスデータの通知を要求する。ステータスデータ通知部１１６は、要求を受けた時点のアプリケーションの実行状態を示すステータスデータを収集し、収集したステータスデータを、収集したタイミングを示す時間情報とともにメタデータ取得部１５４に通知する。したがってメタデータ取得部１５４は、実行中のアプリケーション（ゲームプログラム）から通知されたステータスデータを、メタデータとして取得する。

たとえばステータスデータは、ゲームプレイしているシーンを特定するシーンＩＤを含む。また野球ゲームにおいては、ステータスデータとして、ユーザのチーム情報、対戦相手のチーム情報、イニング情報、バッター情報、相手のピッチャー情報などがさらに含まれてもよい。ステータスデータ通知部１１６が収集するステータスデータは、後述するように、コンテンツサーバ１２にアップロードされるコンテンツに、メタデータとして付加されるものであり、コンテンツサーバ１２においてコンテンツの検索に使用されるものである。そのため、ステータスデータ通知部１１６が、多種類のステータスデータを収集できるようにゲームプログラムが構成されていることで、コンテンツサーバ１２における検索の粒度を高めることが可能となる。

上記したように、リングバッファ１７６には、過去３０分間のゲーム画像が記録されており、また、最新のゲーム画像がリアルタイムで順次上書き記録されていく。リングバッファ１７６に記録されているゲーム画像にはタイムスタンプが付加されており、編集処理部１５６は、イベント発生時の時間情報で指定される開始点から所定時間分（たとえば１分間）の画像データがリングバッファ１７６に記録されるのを待って、イベントコードおよびイベント発生時の時間情報で特定される開始点から終了点までの画像データをリングバッファ１７６から読み出し、二死満塁イベントのコンテンツデータとして抽出する。

編集処理部１５６は、このコンテンツデータに、メタデータ取得部１５４が取得したメタデータを付加する。このとき編集処理部１５６は、ステータスデータが収集されたタイミングを示す時間情報を参照して、コンテンツデータを切り出した開始点から終了点までの期間に収集されたステータスデータを、メタデータとしてコンテンツデータに付加する。このように編集処理部１５６がゲーム画像を編集することで、ユーザがゲームプレイしていた状況を詳細に示すメタデータをコンテンツデータに付加することができる。なおメタデータ取得部１５４は、アプリケーションを特定するためのアプリケーションＩＤ（タイトルＩＤ）、およびプレイヤであるユーザを特定する情報を予め取得しておき、編集処理部１５６は、これらの情報をメタデータとしてコンテンツデータに付加することが好ましい。編集処理部１５６は、少なくともアプリケーションＩＤについては、必ずメタデータとしてコンテンツデータに付加する。

図６（ａ）は、イベントの発生時刻がコンテンツデータを切り出す開始点となる例を示す。コンテンツデータの切り出しの終了点は、開始点から所定時間（１分）後に設定される。この例においてメタデータ取得部１５４は、ステータスデータＡ、Ｂ、Ｃ、Ｄを取得している。このうち、編集処理部１５６は、開始点から終了点までの期間に収集されたステータスデータＢ、Ｃを、コンテンツデータに付加する。これにより、開始点から終了点で切り出されたコンテンツデータと、その期間におけるゲームのプレイ状況を示すステータスデータとを紐付けることができる。

なお上記の例では、編集処理部１５６が、二死満塁イベントの発生時から所定時間分の画像データをコンテンツデータとして切り出すことを説明したが、たとえば、二死満塁イベントの発生から終了までの画像データをコンテンツデータとして切り出してもよい。野球ゲームにおいて、二死満塁のチャンスが終了すると、イベントコード通知部１１４は、「二死満塁が終了した」イベントの発生を示すイベントコードを、イベント発生時の時間情報とともにコンテンツ生成部１５０に通知する。これにより編集処理部１５６は、二死満塁イベントの終了を知り、「二死満塁になった」イベント発生時の時間情報で指定される開始点と、「二死満塁が終了した」イベント発生時の時間情報で指定される終了点とを用いて、画像データをリングバッファ１７６から読み出し、二死満塁イベントのコンテンツデータとして抽出する。これにより編集処理部１５６は、二死満塁の発生から終了までのコンテンツデータを取得できる。編集処理部１５６は、このコンテンツデータに、開始点から終了点までの期間においてメタデータ取得部１５４が取得したメタデータを付加する。このように編集処理部１５６がゲーム画像を編集することで、ユーザがゲームプレイしていた状況を詳細に示すメタデータをコンテンツデータに付加することができる。

図６（ｂ）は、２つのイベントコードで開始点と終了点が指定される例を示す。最初のイベントコードの時間情報でコンテンツデータの切り出しの開始点が指定され、次のイベントコードの時間情報でコンテンツデータの切り出しの終了点が指定される。この例においてメタデータ取得部１５４は、ステータスデータＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇを取得している。このうち、編集処理部１５６は、開始点から終了点までの期間に収集されたステータスデータＢ、Ｃ、Ｄ、Ｅ、Ｆを、コンテンツデータに付加する。これにより、開始点から終了点で切り出されたコンテンツデータと、その期間におけるゲームのプレイ状況を示すステータスデータとを紐付けることができる。

なお、編集処理部１５６におけるコンテンツデータの抽出処理は、イベントコード通知部１１４から通知されるイベントコードの種別を用いて実行されてよい。イベントコードの種別として、たとえば、
（１）イベント発生時を開始点とし、所定時間後を終了点とするもの、
（２）開始点を指定するイベントコードと、終了点を指定するイベントコードとが、一組となっているもの、
が定義される。イベントコードに、種別を示す情報が埋め込まれることで、編集処理部１５６は、イベントコードの種別を認識できるようになる。端的に両者の違いを説明すれば、種別（１）のイベントコードは、単独で開始点と終了点を特定できるものであり、種別（２）のイベントコードは、一組で、開始点と終了点を特定できるものである。

種別（１）のイベントコードには、開始点から終了点までの期間を指定する情報が含まれる。イベントコードで指定される期間は、たとえば１０秒、３０秒、６０秒など、様々であってよく、これらの期間は、イベントに応じてゲームメーカが適宜決めればよい。編集処理部１５６は、種別の（１）のイベントコードを受け取ると、イベント発生時（開始点）から、所定時間後（終了点）までの画像データを、コンテンツデータとしてリングバッファ１７６から読み出す。上記した例でいえば、「二死満塁になった」イベントの発生時から１分間分の画像データを抽出して、コンテンツデータを生成したことが相当する。なお、種別（１）のイベントコードの変形例として、イベントコードに、さらに、開始点を指定する時間情報が含まれていてもよい。たとえば、イベントコードに、イベント発生時のα秒前を開始点とし、所定時間後を終了点とする情報が含まれてもよい。リングバッファ１７６には過去３０分間分の画像データが記録されているため、編集処理部１５６は、イベント発生前の画像データもコンテンツデータに組み込めることを利用して、コンテンツデータの開始点と終了点とを適宜設定することが可能となる。なお、イベントコードに、イベント発生時のβ秒後を開始点とし、所定時間後を終了点とする情報が含まれてもよい。このように種別（１）のイベントコードは、単独で、開始点および終了点を定めることができる。

種別（２）のイベントコードには、開始点を指定するイベントコードであるか、または終了点を指定するイベントコードであるかを特定する情報が含まれる。図６（ｂ）に示した例でいえば、「二死満塁になった」イベントが開始点を指定するイベントコードであり、「二死満塁が終了した」イベントが終了点を指定するイベントコードである。「二死満塁になった」イベントのイベントコードと、「二死満塁が終了した」イベントのイベントコードは、一組のイベントコードとして編集処理部１５６により扱われる。たとえば各イベントコードには、一組のイベントコードの一方であることを示す情報が含まれている。前者をイベント開始コード、後者をイベント終了コードと呼ぶと、イベント開始コードには、イベントが開始されたこと、イベント終了コードには、イベントが終了したこと、を示す情報が含まれ、編集処理部１５６は、この一組のイベントコードによって、切り出す画像データの開始点と終了点を決定する。なお、イベント開始コードには、開始点が指定する時間情報が含まれ、イベント終了コードには、終了点を指定する時間情報が含まれていてもよい。これによりイベント開始コードは、イベントコードの時間情報の前後を開始点とすることもでき、またイベント終了コードは、イベントコードの時間情報の前後を終了点とすることもできる。

種別（２）のイベントコードの別の例として、「１イニング中に２点差を逆転した」イベントについて説明する。このイベントは、プレイヤが攻撃するイニングにおいて、２点差で負けているときに発生する。イベントコード通知部１１４は、イニングの開始時にプレイヤが負けていれば、「２点差で負けている」イベントのイベントコードをメタデータ取得部１５４に通知する。メタデータ取得部１５４は、「２点差で負けている」イベントの発生時以降に通知されるステータスデータを、このイベントのコンテンツデータに付加するために蓄積する。既述したように、メタデータ取得部１５４は、イベントコードを通知されると、ステータスデータ通知部１１６に現在のステータスデータを要求して、ステータスデータ通知部１１６が、現在のステータスデータをメタデータ取得部１５４に通知してもよいが、ステータスデータ通知部１１６は、ステータスが変化するたびに、ステータスデータをメタデータ取得部１５４に通知してもよい。ステータスデータ通知部１１６は、たとえば、バッター交替があったとき、また守備の変更があったときを、ステータスに変化があったとみなし、その時点のステータスデータを収集して、メタデータ取得部１５４に通知する。これにより、メタデータ取得部１５４は、２点差を逆転するまでの詳細なメタデータを取得し、蓄積できる。ゲームにおいて、プレイヤが２点差を逆転すると、イベントコード通知部１１４が、「１イニング中に２点差を逆転した」イベントのイベントコードをメタデータ取得部１５４に通知する。

この場合、「２点差で負けている」イベントのイベントコードと、「１イニング中に２点差を逆転した」イベントのイベントコードとは、一組のイベントコートとして、編集処理部１５６により取り扱われる。編集処理部１５６は、この一組のイベントコードによって、切り出す画像データの開始点と終了点を決定する。これにより、編集処理部１５６は、２点差で負けていた時点から、同じイニング内で２点差を逆転するまでの一連のゲーム画像を、コンテンツデータとしてリングバッファ１７６から切り出すことができるとともに、その間のステータスデータを、メタデータとしてコンテンツデータに付加できるようになる。

なお、１イニング中に２点差を逆転できるかどうかは、ゲームの進行次第であり、逆転できないこともある。このときイベントコード通知部１１４は、イニングの終了時に、イニングが終了したことを示すイベントコードをメタデータ取得部１５４に通知する。メタデータ取得部１５４は、イニング終了を示すイベントコードを受け取ると、２点差を逆転できなかったことが分かるので、「２点差で負けている」イベントの発生時以降に蓄積していたステータスデータを破棄してもよく、編集処理部１５６は、画像データの編集を行わない。図６（ｂ）の例でいえば、２つめのイベント終了コードを取得できなかった場合に相当し、この場合には、イベント開始コードの取得後のステータスデータを破棄してもよい。

以上のように、編集処理部１５６は、リングバッファ１７６に記録された画像データを編集して、メタデータを付加したコンテンツデータを生成する。なおメタデータには、情報処理装置１０の機器種別を特定する情報が含まれてもよい。さらにはゲームにおいて、ユーザの習熟度を示すユーザレベルが定められている場合には、アプリケーションを使用しているユーザに関する情報の１つとして、ユーザのレベル情報もメタデータに含まれてよい。このように編集処理部１５６は、直接ゲームから、ステータスデータを受け取ることで、そのゲームプレイ時の状況を示す詳細な情報を、メタデータとしてコンテンツデータに付加することが可能となる。

アップロード処理部１９２は、生成されたコンテンツデータを、コンテンツサーバ１２にアップロードする。具体的にアップロード処理部１９２は、コンテンツデータを、配信サーバ１４にアップロードして、他のユーザが、コンテンツデータをダウンロードして視聴できるようにする。これにより、ユーザのプレイ動画が共有されることになり、多くの人の目に触れることで、ゲームの人気向上が期待される。

以上は、コンテンツ生成部１５０が、自動的にコンテンツデータを生成する仕組みについて説明した。以下、コンテンツ生成部１５０が、ユーザからの指示に基づいて、コンテンツデータを生成する仕組みについて説明する。

図７は、ゲーム画面上に重畳表示される編集画面の一例を示す。ユーザが、入力装置６を操作して、画像編集指示を画像生成部１３０に提供すると、編集画像生成部１３４が、編集画面２００を生成する。ユーザが入力装置６の所定のボタン（たとえばＳＨＡＲＥボタン８１）を操作すると、編集ボタンが画面に表示されて、それを選択することで、画面編集指示が画像生成部１３０に提供されてもよい。

編集画面２００においてユーザはアップロードする動画データの長さを決定することができ、具体的には最長で３０分の画像データの開始点２０２と終了点２０４を定めて、開始点２０２と終了点２０４の間の画像データをアップロード対象として決定する。ユーザは入力装置６を操作することで、開始点２０２および終了点２０４を自由に移動させられる。画像表示領域２０６には、動画データが再生され、ユーザは、再生ボタン、早送りボタン、早戻しボタンなどのインジケータ２０８を操作して、アップロードする動画データの開始点２０２および終了点２０４を再生画像を見ながら決定する。画像表示領域２０６の左端は、リングバッファ１７６に記録されている画像データの最初（すなわち３０分前の画像）、右端は画像データの最後（すなわち最新の画像）を示し、ユーザが画像表示領域２０６の任意の位置にカーソルをあてると、時間軸上の対応する位置に存在する画像が表示されてもよい。時間情報２１０は、過去３０分のうちの再生画像の相対的な時間を示す。ユーザは開始点２０２および終了点２０４を設定し、Ｅｎｔｅｒキーを押すことで抽出する画像データが特定される。

ユーザがＥｎｔｅｒキーを操作すると、指示取得部１５２は、画像データの編集指示を取得するとともに、編集画面２００において設定された開始点２０２および終了点２０４の時間情報を取得する。ステータスデータ通知部１１６は、ゲーム中のステータスが変化するたびに、ステータスデータを収集して、収集したタイミングを示す時間情報とともにメタデータ取得部１５４に逐次通知し、メタデータ取得部１５４は、その全てを蓄積している。なお、メタデータ取得部１５４は、リングバッファ１７６から上書き削除された画像データに対応するメタデータ、すなわち３０分以上前の時間情報をもつメタデータについては、破棄してもよい。

既述したように、リングバッファ１７６に記録されている画像データには、タイムスタンプが付与されている。編集処理部１５６は、開始点２０２および終了点２０４で特定される画像データをリングバッファ１７６から抽出してコンテンツデータとして取得するとともに、この画像データの開始点から終了点までの期間に、メタデータ取得部１５４が取得したステータスデータをメタデータとしてコンテンツデータに付加する。このように編集処理部１５６が、ユーザからの開始点および終了点を指定した編集指示をもとにゲーム画像を編集することで、ユーザがゲームプレイしていた状況を詳細に示すメタデータを、コンテンツデータに付加することができる。アップロード処理部１９２は、コンテンツデータを、コンテンツサーバ１２に送信する。

以上のようにして、コンテンツサーバ１２に、多くのコンテンツデータが集まるようになる。特に、編集処理部１５６がイベントコードをもちいて自動的に画像データを編集することで、ユーザの作業が不要となるため、コンテンツサーバ１２は、多くのユーザから、多数のコンテンツデータを自動的に集めることが可能となる。なお編集処理部１５６が、自動的にコンテンツデータを生成するか否かは、ユーザが選択することができ、したがってユーザが自動編集を望まない場合には、自動編集を禁止する設定をすればよい。この場合であっても、ユーザは図７に示す編集画面２００から、コンテンツデータをコンテンツサーバ１２にアップロードできる。

なお以上は、情報処理装置１０がコンテンツデータを生成して、アップロードする仕組みであるが、コンテンツデータは、コンテンツサーバ１２側において生成されてもよい。画像データの生成処理は、編集サーバ１６によって行われる。

編集サーバ１６が画像データを編集する前提として、情報処理装置１０において、送信処理部１９４が、ゲーム画像生成部１３２により生成された画像データを、編集サーバ１６に送信する。また送信処理部１９４が、イベントコード通知部１１４により通知されたイベントコードを、イベント発生時の時間情報とともに編集サーバ１６に送信する。また送信処理部１９４が、ステータスデータ通知部１１６により通知されたステータスデータを、ステータス収集時の時間情報とともに編集サーバ１６に送信する。なおステータスデータ通知部１１６は、ゲーム中のステータスが変化するたびに、ステータスデータを送信処理部１９４に通知し、送信処理部１９４が、ステータスデータの通知をうける度に、編集サーバ１６にステータスデータを送信することが好ましい。

図８は、編集サーバ１６の内部構成を示す。編集サーバ１６は、コンテンツ生成部３００および通信部３０２を備える。コンテンツ生成部３００は、通信部３０２を介してネットワーク３に接続し、画像データ取得部３１０、メタデータ取得部３１２、編集処理部３１４および記録部３１６を備える。図８において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

画像データ取得部３１０は、情報処理装置１０から配信される画像データを取得し、記録部３１６に記録する。画像データはリアルタイム送信されるため、したがって、この画像データは、配信サーバ１４から、ライブ配信されてもよい。情報処理装置１０から画像データがライブ中継のために配信サーバ１４に送信されている場合には、画像データ取得部３１０は、配信サーバ１４から画像データを取得してもよい。

メタデータ取得部３１２は、情報処理装置１０から送信されるイベントコードおよびステータスデータを、それぞれの時間情報とともに取得する。編集処理部３１４は、イベントコードおよびイベント発生時の時間情報をもとに、記録部３１６に記録された画像データを編集する。

なおコンテンツ生成部３００におけるメタデータ取得部３１２、編集処理部３１４および記録部３１６の各機能は、情報処理装置１０におけるメタデータ取得部１５４、編集処理部１５６およびリングバッファ１７６の各機能と同じであるため、重複する説明は省略する。なお記録部３１６は、リングバッファである必要はなく、リングバッファ１７６よりも大きな記憶領域を有してよい。このように編集サーバ１６は、情報処理装置１０内で行っていた画像データの編集処理を実行する機能を有する。なお編集サーバ１６は、画像データの編集処理を行う点で、情報処理装置１０と同様の画像データ編集機能を有するものであり、したがって編集サーバ１６は、画像データの編集処理機能を備えた情報処理装置と呼ぶこともできる。

画像データの編集処理を情報処理装置１０側で行うか、または編集サーバ１６側で行うかは、情報処理システム１における処理負荷バランスにより決定されればよい。編集処理部３１４は、イベントコードにもとづいて画像データを切り出す開始点と終了点を特定して、記録部３１６に記録された画像データの開始点から終了点までを抽出して、コンテンツデータを取得する。編集処理部３１４は、開始点から終了点までの期間にメタデータ取得部３１２が取得したイベントコードおよびステータスデータを、メタデータとしてコンテンツデータに付加する。編集処理部３１４が生成したコンテンツデータは、コンテンツサーバ１２に提供されて、複数のユーザがコンテンツデータをダウンロードして視聴できるようにする。これにより、ユーザのプレイ動画が共有されることになり、多くの人の目に触れることで、ゲームの人気向上が期待される。

以上のようにして、コンテンツサーバ１２は、複数のコンテンツデータを所有する。コンテンツデータには、ゲームプログラムから提供される詳細なメタデータが付加されているため、ユーザは、ブラウザからコンテンツサーバ１２にアクセスして、メタデータを検索ワードとして入力することで、所望のコンテンツをダウンロードできる環境が実現される。

以下、ユーザの状況に応じて、効率よく所望のコンテンツをダウンロードする仕組みについて説明する。
＜コンテンツ受信機能＞
図９は、コンテンツ受信機能を実現する情報処理装置１０の内部構成を示す。情報処理装置１０は、処理部１００および通信部１０２を備え、処理部１００は、アプリケーション処理部１１０、画像生成部１３０およびダウンロード処理部１２０を備える。アプリケーション処理部１１０は、アプリケーションに関する処理を行い、画像生成部１３０は、出力装置４に表示するための画像生成処理を行う。ダウンロード処理部１２０は、コンテンツサーバ１２に蓄積されたコンテンツのダウンロード処理を行う。

図９において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。なお図９において、図４に示す符号と同じ符号を付した構成は、図４に示す構成と同一もしくは同様の機能を有している。通信部１０２は、コンテンツサーバ１２との間で、コンテンツに関する要求やデータを送受信する。

アプリケーション処理部１１０において、ゲーム実行部１１２は、ユーザによる入力装置６の操作入力を受けてゲームを進行させるプログラムを実行する機能を有する。ゲーム画像生成部１３２はレンダリング処理などを実行するＧＰＵであってよく、ゲーム実行部１１２による処理結果を受けて、出力装置４に表示するアプリケーション（ゲーム）の画像データを生成する。図１０は、出力装置４に表示されるゲーム画面の一例を示す。

イベントコード通知部１１４は、ゲームの実行中に、ゲームプログラムにおいて設定されたイベントが発生すると、そのイベントの発生を示すイベントコードをダウンロード処理部１２０に出力する。ダウンロード処理部１２０において、メタデータ取得部１４２が、通知されたイベントコードを取得する。なおイベントは、ゲームごとに設定されており、たとえば格闘ゲームであれば、「格闘が開始された」、「体力が半分になった」、「残り時間が１０秒となった」、「必殺技がでた」など、様々なものが設定されてよい。イベントコード通知部１１４は、設定されたイベントが発生すると、そのイベントコードをコンテンツ生成部１５０に通知する機能をもつ。ステータスデータ通知部１１６は、ゲームのステータスデータをコンテンツ生成部１５０に通知する。ステータスデータ通知部１１６は、コンテンツ生成部１５０からの要求に応じてステータスデータをコンテンツ生成部１５０に通知してもよいが、たとえばステータスに変化があった場合に、変化後のステータスデータをコンテンツ生成部１５０に通知してもよい。このときステータスデータ通知部１１６は、変化前と変化後の差分となるステータスデータを通知してもよいが、変化後の全てのステータスデータを収集して通知してもよい。

図１０は、格闘ゲームの実行画面を示す。ユーザは、入力装置６を操作して格闘ゲームをスタートする。ユーザは、プレイ中のどの時点でも構わないが、入力装置６を操作して、現在のプレイ状況に関連した画像データの検索指示を生成する。たとえばユーザは、機能ボタン８０を操作して、メニュー画面に表示される検索ボタンを選択することで検索指示を生成してもよく、または検索機能が割り当てられているボタンを操作して、検索指示を生成してもよい。実施例の情報処理装置１０は、カメラ７からユーザのジェスチャを認識できるため、ユーザが所定のジェスチャを行うことで、検索指示が生成されてもよい。いずれにしても、検索指示が生成されると、指示取得部１４０が、検索指示を受け付ける。

メタデータ取得部１４２は、アプリケーションの実行状態を示すイベントコードおよびステータスデータを取得している。イベントコード通知部１１４は、イベントが発生するたびにイベントコードを通知し、またステータスデータ通知部１１６は、ステータスに変化があるたびに、ステータスデータを収集して通知している。指示取得部１４０が検索指示を受け付けると、メタデータ取得部１４２は、最新のイベントコード、および最新のステータスデータを、メタデータとして要求生成部１４４に提供する。要求生成部１４４は、最新のイベントコードおよび最新のステータスデータをメタデータとして含むコンテンツの検索要求を生成し、要求生成部１４４が、検索要求をコンテンツサーバ１２に送信する。

要求生成部１４４が、イベントコードおよびステータスデータをメタデータとして検索要求に含ませることで、この検索要求には、現在のユーザのプレイ状況を表現する多種類のメタデータが埋め込まれることになる。なお既述したように、メタデータには、タイトルＩＤが必ず含まれる。たとえば格闘ゲームのステータスデータとしては、ユーザが使用するキャラクタ、対戦相手のキャラクタ、それぞれのキャラクタの残り体力、残り時間などが含まれてよい。またステータスデータには、ユーザの習熟度や経験値を表現するレベル、対戦相手のレベルも含まれてよい。

図１１は、配信サーバ１４および検索サーバ１８の機能を集約した構成を示す。以下、これらの機能をコンテンツサーバ１２が有しているものとして説明する。コンテンツサーバ１２は、配信処理部３２０および通信部３２２を備える。配信処理部３２０は、通信部３２２を介してネットワーク３に接続し、検索要求取得部３３０、検索処理部３３２、検索結果送信部３３４、送信要求取得部３３６、コンテンツ送信部３３８およびコンテンツ記録部３４０を備える。これらの機能ブロックをあえて配信サーバ１４と検索サーバ１８とに振り分けるとすると、検索要求取得部３３０、検索処理部３３２、検索結果送信部３３４が検索サーバ１８に、送信要求取得部３３６、コンテンツ送信部３３８、コンテンツ記録部３４０が配信サーバ１４に含まれてよいが、この限りではない。コンテンツ記録部３４０は、メタデータを付加されたコンテンツデータを記録する。なお、各コンテンツデータには、コンテンツ記録部３４０においてコンテンツを一意に特定するためのコンテンツＩＤが付与されているものとする。コンテンツＩＤは、コンテンツサーバ１２がコンテンツデータを受け入れたときに、当該コンテンツを識別するために付与してもよい。

図１１において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

コンテンツサーバ１２において、検索要求取得部３３０が、情報処理装置１０から送信されるコンテンツの検索要求を取得する。検索処理部３３２は、検索要求に含まれるメタデータにもとづいて、コンテンツ記録部３４０においてコンテンツを検索する。ここで、検索要求に含まれるメタデータの例を以下に示す。
タイトルＩＤ ＸＹＺ
ユーザ名 Ａ
プレイヤキャラクタ ＴＡＲＯ
対戦相手キャラクタ ＪＩＲＯ
ユーザレベル ３
プレイヤ残り体力 １００％
対戦相手残り体力 １００％

検索処理部３３２は、これらのメタデータにマッチするメタデータをもつコンテンツをコンテンツ記録部３４０から検索する。なおコンテンツサーバ１２は、コンテンツのメタデータを抽出したデータベースを検索用に予め作成しておき、検索処理部３３２は、このデータベースを参照して、検索処理を行ってもよい。まず検索処理部３３２は、タイトルＩＤを同一とするコンテンツを検索する。これにより検索対象を、同じゲームの動画に絞る。

検索処理部３３２は、ゲームごとに、検索条件として優先度の高いメタデータを把握している。検索処理部３３２は、メタデータの優先度を、メタデータごとに登録したファイルを保持していてもよい。たとえば、プレイヤキャラクタと対戦相手キャラクタとが同一であることが最高の優先度に設定されていれば、検索処理部３３２は、プレイヤキャラクタがＴＡＲＯ、対戦相手キャラクタがＪＩＲＯであるメタデータが設定されているコンテンツを検索する。

一方で、あまりに実力レベルの違うユーザのプレイ動画を見ても、視聴ユーザに参考にならないこともあるため、ユーザレベルが同じであって、且つプレイヤキャラクタが同一であることが最高の優先度に設定されていれば、検索処理部３３２は、プライヤキャラクタがＴＡＲＯ、ユーザレベルが３のメタデータが設定されているコンテンツを検索する。

このように検索条件の優先度は、各ゲームメーカによって定められてよい。この優先度は、ユーザに対して、どのような動画を見せたいかという観点から定められる。なお、検索処理部３３２は、複数のカテゴリで検索結果を生成してもよい。たとえば検索処理部３３２は、最高の優先度に設定されている検索条件での検索結果、検索要求を送信したユーザのフレンドで検索した検索結果、視聴ユーザからの評価が高い検索結果など、さまざまなカテゴリの検索結果を生成してもよい。検索結果送信部３３４は、コンテンツの検索結果を、情報処理装置１０に送信する。この検索結果には、コンテンツＩＤ、コンテンツの静止画像や、コンテンツの投稿ユーザ名、投稿日時などのコンテンツごとの情報が含まれる。

また検索条件は、ゲームのシーンごとに定められてよい。たとえばストーリーが進行するアドベンチャーゲームにおいては、プレイヤキャラクタのアクションに応じて、その後のゲーム進行が決定される。そこで、ゲームシーンがストーリーの分岐点である場合に、そこから進行する可能性のある複数のルートに関する検索結果を、検索処理部３３２が生成するようにしてもよい。キャラクタがストーリーの分岐点にいる場合に、ゲームが、イベントコードを出力するように構成されていれば、検索処理部３３２は、そのイベントコードに対応付けられている検索条件をもとに、コンテンツのメタデータを検索してもよい。

情報処理装置１０において、検索結果取得部１６０が、コンテンツの検索結果を取得する。この検索結果は、検索要求に含まれる複数種類のメタデータにもとづいて検索されたコンテンツの検索結果である。候補画像生成部１３６は、検索結果として、ダウンロードする候補となる複数のコンテンツに関する画像を生成して、出力装置４に表示する。なお、これにより、出力装置４に表示されていたゲーム画面は、ダウンロード候補のリスト画面に切り替えられることになる。

図１２は、検索結果画面の一例を示す。候補画像生成部１３６は、検索結果として、複数のコンテンツに関する画像を並べて表示する。検索画面においては、コンテンツの静止画像であるキャプチャ画像２２０が並べられ、また各キャプチャ画像２２０の横には、投稿ユーザ名や、投稿日時などが表示される。またリストの上段には、複数の検索結果タブが表示され、ユーザは、タブを選択することで、検索結果を切り替えて閲覧できるようになっている。なお、「キーワード」タブは、ユーザがあらためて検索キーワードを入力する際に選択される。

この検索結果画面において、ユーザが入力装置６を操作して、ダウンロードを希望するコンテンツを選択する。情報処理装置１０において、指示取得部１４０が、コンテンツを指定する選択指示を受け付けると、要求生成部１４４が、選択されたコンテンツのコンテンツＩＤを含めたコンテンツ送信要求を生成する。要求送信部１４６は、コンテンツ送信要求をコンテンツサーバ１２に送信する。

コンテンツサーバ１２において、送信要求取得部３３６が、コンテンツの送信要求を取得すると、コンテンツ送信部３３８が、送信要求に含まれるコンテンツＩＤで特定されるコンテンツデータをコンテンツ記録部３４０から読み出し、情報処理装置１０に送信する。

情報処理装置１０において、コンテンツ取得部１６２がコンテンツデータを取得し、コンテンツ画像生成部１３８が、取得したコンテンツの画像を生成して、出力装置４に出力する。図１３および図１４は、ダウンロードしたプレイ動画の一例を示す。なお図１３は、プレイヤキャラクタが相手キャラクタを攻撃している様子を、図１４はプレイヤキャラクタが相手キャラクタをＫＯした様子を示している。

このように情報処理装置１０は、コンテンツの検索要求に、現在のプレイ状況を詳細に示すメタデータを自動的に付加することで、コンテンツサーバ１２が、ユーザの状況に適した検索処理を実行できるようになる。またコンテンツサーバ１２においても、各コンテンツに、詳細なメタデータが付加されていることで、コンテンツサーバ１２における検索の粒度を高めることも可能となっている。

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

実施例においては、情報処理装置１０ないし編集サーバ１６が、アプリケーションの実行中に、画像データを切り出して、メタデータを付加したコンテンツデータを生成することを説明した。このようにコンテンツデータを生成して、コンテンツ記録部３４０に記録しておくことで、配信サーバ１４は、送信を要求されたコンテンツデータを即座に情報処理装置１０に配信することができる。

変形例では、コンテンツサーバ１２が、コンテンツ記録部３４０において、切り出しを行っていない画像データと、その画像データのメタデータとを紐付けて記録しておく。なお画像データとメタデータとは、別個のストレージ装置に記録されていてもよい。図８に示す編集サーバ１６の動作に関連して説明したように、情報処理装置１０において、送信処理部１９４が、ゲーム画像生成部１３２により生成された画像データを、コンテンツサーバ１２に送信する。また送信処理部１９４が、イベントコード通知部１１４により通知されたイベントコードを、イベント発生時の時間情報とともにコンテンツサーバ１２に送信する。また送信処理部１９４が、ステータスデータ通知部１１６により通知されたステータスデータを、ステータス収集時の時間情報とともにコンテンツサーバ１２に送信する。送信処理部１９４は、画像データをコンテンツサーバ１２に送信している間にメタデータ取得部１５４が取得したイベントコードおよびステータスデータを、メタデータとしてコンテンツサーバ１２に送信する。

コンテンツサーバ１２において、これらのデータ、すなわち画像データおよびメタデータは、互いに関連づけてコンテンツ記録部３４０に記録される。実施例では、編集サーバ１６が、イベントコードの取得を契機として画像データを編集してコンテンツデータを生成することを説明したが、この変形例では、この時点で編集サーバ１６はコンテンツデータを生成しない。

ここで、ユーザから検索要求取得部３３０が検索要求を受け付けると、検索処理部３３２が、コンテンツ記録部３４０に記録されたメタデータを参照して、検索要求に含まれるメタデータにマッチしたコンテンツを検索し、検索結果送信部３３４が、検索結果を情報処理装置１０に送信する。情報処理装置１０においてコンテンツが選択され、送信要求取得部３３６が、コンテンツの送信要求を受け取ると、このとき、編集サーバ１６が、検索要求に含まれていたメタデータのうちのイベントコードにもとづいて画像データを編集してコンテンツデータを生成する。すなわち、編集サーバ１６は、コンテンツの送信要求を受けた後に、画像データを編集して、コンテンツデータを生成する。コンテンツ送信部３３８は、編集されたコンテンツデータを情報処理装置１０に送信する。このように編集サーバ１６は、都度コンテンツデータを生成するようにすることで、編集処理にかかる負荷を低減できる。

なお、この変形例において、送信処理部１９４は、画像データをコンテンツサーバ１２にリアルタイムで送信するが、メタデータに関しては、リアルタイムで送信しなくてもよい。つまり送信処理部１９４は、画像データの送信中にメタデータ取得部１５４が取得したメタデータを、画像データの送信が終了した後に、コンテンツサーバ１２に送信してもよい。また画像データについても、情報処理装置１０からリアルタイムで送信されなくてもよく、情報処理装置１０において記録した画像データ、メタデータが、まとめて編集サーバ１６に送信されてもよい。

１・・・情報処理システム、１０・・・情報処理装置、１２・・・コンテンツサーバ、１４・・・配信サーバ、１６・・・編集サーバ、１８・・・検索サーバ、１００・・・処理部、１０２・・・通信部、１１０・・・アプリケーション処理部、１１２・・・ゲーム実行部、１１４・・・イベントコード通知部、１１６・・・ステータスデータ通知部、１２０・・・ダウンロード処理部、１３０・・・画像生成部、１３２・・・ゲーム画像生成部、１３４・・・編集画像生成部、１３６・・・候補画像生成部、１３８・・・コンテンツ画像生成部、１４０・・・指示取得部、１４２・・・メタデータ取得部、１４４・・・要求生成部、１４６・・・要求送信部、１５０・・・コンテンツ生成部、１５２・・・指示取得部、１５４・・・メタデータ取得部、１５６・・・編集処理部、１６０・・・検索結果取得部、１６２・・・コンテンツ取得部、１７０・・・記録部、１７２・・・記録制御部、１７４・・・書込／読出部、１７６・・・リングバッファ、１９０・・・共有処理部、１９２・・・アップロード処理部、１９４・・・送信処理部、２００・・・編集画面、３００・・・コンテンツ生成部、３０２・・・通信部、３１０・・・画像データ取得部、３１２・・・メタデータ取得部、３１４・・・編集処理部、３１６・・・記録部、３２０・・・配信処理部、３２２・・・通信部、３３０・・・検索要求取得部、３３２・・・検索処理部、３３４・・・検索結果送信部、３３６・・・送信要求取得部、３３８・・・コンテンツ送信部、３４０・・・コンテンツ記録部。

Claims (8)

1. 実行中のアプリケーションの画像データを記録する記録部と、
   アプリケーションにおいてイベントが発生すると、実行中のアプリケーションからイベントの発生を示すイベントコードを取得し、また実行中のアプリケーションからアプリケーションの実行状態を示すメタデータと、当該メタデータを収集したタイミングを示す時間情報とを取得するメタデータ取得部と、
   イベントコードの種別にもとづいてアプリケーション画像データを抽出する開始点および終了点を特定し、前記記録部に記録されたアプリケーション画像データのうち、開始点から終了点までのアプリケーション画像データを、コンテンツデータとして抽出する編集処理部と、を備え、
   前記編集処理部は、メタデータを収集したタイミングを示す時間情報を参照して、開始点から終了点までの期間に収集されたメタデータを、コンテンツデータに付加することを特徴とする情報処理装置。
2. 前記メタデータ取得部は、アプリケーションを使用しているユーザに関する情報を、メタデータとして取得し、
   前記編集処理部は、コンテンツデータに、ユーザに関する情報を付加することを特徴とする請求項１に記載の情報処理装置。
3. 前記メタデータ取得部は、イベントコードを、メタデータとして取得することを特徴とする請求項１または２に記載の情報処理装置。
4. サーバに、実行中のアプリケーションの画像データを送信する送信処理部と、
   アプリケーションにおいてイベントが発生すると、実行中のアプリケーションからイベントの発生を示すイベントコードを取得し、また実行中のアプリケーションからアプリケーションの実行状態を示すメタデータと、当該メタデータを収集したタイミングを示す時間情報とを取得するメタデータ取得部と、を備え、イベントコードは、アプリケーション画像データを抽出する開始点および終了点の特定に使用されるイベントコード種別を示す情報を含んでおり、
   前記送信処理部は、アプリケーション画像データをサーバに送信している間に前記メタデータ取得部が取得したメタデータおよび時間情報を、サーバに送信することを特徴とする情報処理装置。
5. 前記送信処理部は、イベントコードを、メタデータとして、サーバに送信することを特徴とする請求項４に記載の情報処理装置。
6. アプリケーションにおいてイベントが発生すると、実行中のアプリケーションからイベントの発生を示すイベントコードを取得するステップと、
   実行中のアプリケーションからアプリケーションの実行状態を示すメタデータと、当該メタデータを収集したタイミングを示す時間情報とを取得するステップと、
   イベントコードの種別にもとづいてアプリケーションの画像データを抽出する開始点および終了点を特定するステップと、
   実行中のアプリケーションの画像データを記録する記録部から、開始点から終了点までの画像データを、コンテンツデータとして抽出するステップと、
   メタデータを収集したタイミングを示す時間情報を参照して、開始点から終了点までの期間に収集されたメタデータを、コンテンツデータに付加するステップと、
   を備えることを特徴とするコンテンツデータ生成方法。
7. コンピュータに、
   アプリケーションにおいてイベントが発生すると、実行中のアプリケーションからイベントの発生を示すイベントコードを取得する機能と、
   実行中のアプリケーションからアプリケーションの実行状態を示すメタデータと、当該メタデータを収集したタイミングを示す時間情報とを取得する機能と、
   イベントコードの種別にもとづいてアプリケーションの画像データを抽出する開始点および終了点を特定する機能と、
   実行中のアプリケーションの画像データを記録する記録部から、開始点から終了点までの画像データを、コンテンツデータとして抽出する機能と、
   メタデータを収集したタイミングを示す時間情報を参照して、開始点から終了点までの期間に収集されたメタデータを、コンテンツデータに付加する機能と、
   を実現させるためのプログラム。
8. 請求項７に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images