JP2016116591A - 情報処理システム、サーバ、プログラム、及び情報処理方法 - Google Patents

Abstract

【課題】ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えること。【解決手段】サーバ１のイベント取得部１１は、ゲーム内で負として処理された需要喚起イベントを発生させた端末２−１等から当該需要喚起イベントのログデータを取得する。イベント取得部１１は、ゲーム内で正として処理された供給可能性イベントを発生させた端末２−２から当該供給可能性イベントのログデータを取得する。需要度合演算部１３は、取得された夫々のログデータに基づいて１以上の需要喚起イベントの中から供給可能性イベントと関連するものを選択し、その選択結果に基づいて潜在需要の度合を演算する。プレイ動画記録推薦報知部１４は、当該度合が所定条件を満たす供給可能性イベントを発生させた端末２−２に対して、当該供給可能性イベントのプレイ動画の記録を促す報知を行う。【選択図】図１

Description

本発明は、情報処理システム、サーバ、プログラム、及び情報処理方法に関する。

近年、スマートフォン等の端末上でのゲーム体験をプレイヤー同士で共有するために、プレイ中のゲーム画面を録画した動画像データが、数多くネット上にアップロードされるようになっている（特許文献１，２参照）。そのための環境も整いつつあり、このような動画像データを記録するための開発ツールも多数提供されるようになっている

ここで、プレイ中のゲーム画面を録画した動画像データは、一般的に「プレイ動画」と呼ばれている場合が多い。
このような動画像データの他、プレイヤーそのものも含めて撮影されたゲームの実行内容を示す動画像データも存在する。このような動画像データは、一般的に「ゲーム実況動画」と呼ばれている。
ただし、以下においては、「ゲーム実況動画」も含めて、即ち、これらの動画像データを総称して「プレイ動画」と呼ぶことにする。
即ち、本明細書では、「プレイ動画」とは、所定のゲームの実行内容を示す画像という広義な概念である。

今後、プレイ動画を作成可能なツールキットが組み込まれたゲームが数多く登場すると予想される。この場合のプレイ動画は、プレイ時間の間ずっと撮影されたものではなく、面白いプレイ、美しいプレイ、ボスを鮮やかに倒すプレイ等の、ピンポイントのものが多くなると予想される。
このようなピンポイントのプレイ動画が数多くアップロードされることによって、プレイ動画の共有と視聴のサイクルが確立し、その結果として、上記のようなプレイ動画作成機能を有するゲームが普及するものと思われる。

米国特許出願公開第２０１４／００９４３０２号明細書 米国特許出願公開第２０１４／０２２８１１２号明細書

しかしながら、特許文献１及び２を含め従来の技術では、他のプレイヤーから必要とされるプレイ動画をピンポイントで作成することは容易ではなく、視聴されることの少ないプレイ動画が大量に蓄積され、プレイ動画の共有と視聴のサイクルの確立が阻害されることになると予想される。
このため、カジュアルなプレイヤー（ユーザー）が、質の高いプレイ動画、即ち他プレイヤーから必要とされるプレイ動画を容易に作成することを支援する新たな仕組み要求されている。

本発明は、このような状況に鑑みてなされたものであり、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることを目的とする。

上記目的を達成するため、本発明の一態様の情報処理システムは、
ゲームを実行し得る複数の端末と、サーバとを含む情報処理システムであって、
前記サーバは、
前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、前記ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算手段と、
当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、当該第２イベントに関する動画像の記録を促す報知を行う報知手段と、
を備え、
前記複数の端末の少なくとも一部は、
前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出手段と、
前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供手段と、
前記サーバからの前記報知の内容を提示する提示手段と、
を備える。

これにより、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができる。

本発明の一態様のサーバは、
ゲームを実行し得る複数の端末と通信をするサーバにおいて、
前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算手段と、
前記度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する画像データの記録を促す報知を行う報知手段と、
を備える。

これにより、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができる。

さらに、前記ログデータは、前記ゲームの実行時に得られる属性情報を１種類以上含み、
前記度合演算手段は、
前記第２イベントの前記ログデータと、１以上の前記第１イベントの前記ログデータの夫々との相関量を算出し、
前記相関量が所定基準を満たす前記ログデータを有する前記第１イベントを、前記第２イベントと関連するものとして選択するようにすることができる。

これにより、適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。

さらに、前記ログデータは、前記ゲームの進行状況を示すログデータと、前記ゲームのプレイヤーの状態を示すログデータとを含むようにすることができる。

これにより、ゲーム実行中のプレイヤーに対して、当該ゲームの進行状況や当該プレイヤーの状態と相関のある別のプレイヤーからの閲覧需要があることを報知できるので、当該プレイ動画データをアップロードすべき動機付けを適切に与えることができる。

また、前記ログデータは、多次元ベクトル空間上のベクトルで表され、
前記度合演算手段は、前記第２イベントの前記ログデータを表すベクトルと、１以上の前記第１イベントの前記ログデータを表すベクトルの夫々との前記多次元ベクトル空間上の距離を、前記相関量として算出するようにすることができる。

これにより、さらに一段と適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。

また、前記度合演算手段は、
前記第２イベントと関連する前記第１イベントの選択数が多いほど、当該第２イベントに関する画像の潜在需要の前記度合を高めるようにすることができる。

これにより、さらに一段と適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。

また、前記サーバは、過去に実行された前記ゲームの所定イベントに関する画像データ又は当該画像データの所在データを管理する管理手段をさらに備え、
前記度合演算手段は、
前記管理手段により管理されている前記画像データ又は前記所在データにより特定される画像データのうち、前記第２イベントに関連する画像データへのアクセス数を求め、
当該アクセス数が多いほど、当該第２イベントに関する画像の潜在需要の前記度合を低下させるようにすることができる。

これにより、さらに一段と適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。

本発明の一態様の第１のプログラムは、上述の本発明の一態様のサーバに対応する情報処理方法である。

本発明の一態様の第２プログラムは、上述の本発明の一態様の情報処理システムにおける端末を制御するコンピュータに実行させるプログラムである。
即ち、
ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得機能と、
取得された前記ログデータの夫々に基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算し、当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する画像データの記録を促す報知を行う報知機能と、
を備えるサーバとの間で通信する端末を制御するコンピュータに、
前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出ステップと、
前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供ステップと、
前記サーバからの前記報知の内容を提示する提示ステップと、
を含む制御処理を実行させる。

これにより、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができる。

本発明の一態様の上記第２プログラムに対応する情報処理方法も、本発明の一態様の情報処理方法として提供される。

本発明によれば、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができると共に、ゲームを実行中のプレイヤーに対して、他のプレイヤーが必要とするプレイ動画を作成及びアップロートすることを促し、プレイ動画の需要を迅速に満たすサイクルを実現することができる。

本発明の一実施形態に係る情報システムの機能的構成を示す機能ブロック図である。 図１の情報システムにおける、需要喚起イベントの検出と、図１の端末２−２における供給可能性イベントの検出に基づくプレイ動画の推薦とを説明するための図である。 多次元の特徴空間内で定義されたベクトル間の相関量を計量する手法について説明するための図である。 図１の情報処理システムが実行される録画推奨処理を示すフローチャートである。

以下、本発明の実施形態について、図面を用いて説明する。

なお、以下において、単に「画像」と呼ぶ場合には、「動画像」と「静止画像」との両方を含むものとする。
また、「動画像」には、次の第１処理乃至第３処理の夫々により表示される画像を含むものとする。
第１処理とは、平面画像（２Ｄ画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対して、複数枚からなる一連の静止画像を時間経過とともに連続的に切り替えて表示させる処理をいう。具体的には例えば、２次元アニメーション、いわゆるパラパラ漫画的な処理が第１処理に該当する。
第２処理とは、立体画像（３Ｄモデルの画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対応するモーションを設定しておき、時間経過とともに当該モーションを変化させて表示させる処理をいう。具体的には例えば、３次元アニメーションが第２処理に該当する。
第３処理とは、オブジェクト（例えばゲームキャラクタ）の夫々の動作に対応した映像（即ち動画）を準備しておき、時間経過とともに当該映像を流していく処理をいう。

図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
図１に示す情報処理システムは、サーバ１と、端末２−１，２−２の各々が、図示せぬインターネット等の所定のネットワークを介して相互に接続されることで構成されている。なお、図１には２台の端末２−１，２−２しか図示されていないが、これは本発明の説明を容易にするためである。実際には、情報処理システムにおけるサーバ１には、多数の端末が接続され得る。

本実施形態におけるサーバ１及び端末２−１，２−２の夫々は、コンピュータ及びその周辺装置に適用される。本実施形態における各部は、コンピュータ及びその周辺装置が備えるハードウェア並びに当該ハードウェアを制御するソフトウェアによって構成される。

上記ハードウェアには、制御部としてのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の他、記憶部、通信部、表示部及び入力部が含まれる。記憶部としては、例えば、メモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＯＭ：Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ等）、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、光ディスク（ＣＤ：Ｃｏｍｐａｃｔ Ｄｉｓｋ、ＤＶＤ：Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ等）ドライブ等が挙げられる。通信部としては、例えば、各種有線及び無線インターフェース装置が挙げられる。表示部としては、例えば、液晶ディスプレイ等の各種ディスプレイが挙げられる。入力部としては、例えば、キーボードやポインティング・デバイス（マウス、トラッキングボール等）が挙げられる。

なお、本実施形態の端末２−１，２−２は、スマートフォンとして構成され、入力部と表示部を兼ね備えたタッチパネルも有している。
タッチパネルの入力部は、例えば表示部の表示領域に積層される静電容量式又は抵抗膜式の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。ここで、タッチ操作とは、表示媒体たるタッチパネル（正確にはそのうちの入力部）に対する物体（ユーザの指やタッチペン等）の接触又は近接の操作をいう。なお、以下、タッチ操作がなされた位置を「タッチ位置」と呼び、タッチ位置の座標を「タッチ座標」と呼ぶ。

また、上記ソフトウェアには、上記ハードウェアを制御するコンピュータ・プログラムやデータが含まれる。コンピュータ・プログラムやデータは、記憶部により記憶され、制御部により適宜実行、参照される。また、コンピュータ・プログラムやデータは、通信回線を介して配布されることも可能であり、ＣＤ−ＲＯＭ等のコンピュータ可読媒体に記録して配布されることも可能である。

サーバ１及び端末２−１，２−２の夫々は、このようなハードウェアとソフトウェアの協働による各種動作をすべく、図１に示すような機能的構成を有している。

サーバ１は、イベント取得部１１と、需要ログ記憶部１２と、需要度合演算部１３と、プレイ動画記録推薦報知部１４と、プレイ動画記憶部１５と、プレイ動画管理部１６とを備えている。

イベント取得部１１は、複数の端末（図１の例では端末２−１，２−２）のうち、所定のゲーム内で負として処理された第１イベントを発生させた端末（図１の例では端末２−１）から当該第１イベントのログデータを取得する。
また、イベント取得部１１は、複数の端末のうち、当該ゲーム内で正として処理された第２イベントを発生させた端末（図１の例では端末２−２）から当該第２イベントのログデータを取得する。

ここで、ゲームは、複数のイベントを含むものとする。また、複数のイベントのうち少なくとも一部は、プレイヤーの操作等に応じて正又は負として選択的に処理されるものとする。
なお、ここでいう「正」と「負」は、対になる概念という意である。つまり、プレイヤーの操作に応じて、対になる２つの処理が選択的に行われれば足り、それらの処理内容等は特に限定されない。

例えば、負として処理される第１イベントには、ゲーム内で失敗的な状況として処理されるイベントが含まれる。
具体的には例えば、ゲームオーバー、レアアイテムの獲得の失敗、ＮＰＣ（Ｎｏｎ−Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）を仲間にすることに失敗、及びストーリー分岐点を見つけられない等が、第１イベントに含まれる。
このような第１イベントとは、それを経験したプレイヤーが、第１イベントに関連するプレイ動画（例えば成功的な状況として処理されるまでの過程を示す他人のプレイ動画等）の視聴を所望する可能性が高いイベントであると把握できる。そこで以下、このような第１イベントを「需要喚起イベント」と呼ぶ。

これに対して例えば、正として処理される第２イベントには、ゲーム内で成功的な状況として処理されるイベントが含まれる。
具体的には例えば、ステージクリア、レアアイテムの獲得、ＮＰＣを仲間にする、ストーリー分岐点を見つける等が、第２イベントに含まれる。
このような第２イベントは、当該第２イベントに関連するプレイ動画（例えば成功的な状況として処理されるまでの過程を示すプレイ動画）を公開することにより、他のプレイヤーの需要を満たす可能性が高いイベントである。そこで以下、このような第２イベントを「供給可能性イベント」と呼ぶ。

また、ここでいうログデータとは、ゲーム内において時々刻々と変化する状況等の履歴を示すデータである。即ち、ここでいうログデータとは、取得タイミングによらず同一内容となる静的データではなく、取得タイミングに応じて内容が変化する動的なデータ（リアルタイムデータ）である。
例えば本実施形態では、ログデータは、ゲーム内の属性情報を要素として、任意の個数の任意の種類の要素の集合体からなるデータである。そして本実施形態では、ログデータには、ゲームの進行状況を示すログデータと、ゲームのプレイヤーの状態を示すログデータとが含まれている。
つまり、需要喚起イベントのログデータとは、プレイヤーが当該需要喚起イベントを体験した時点における、ゲームの進行状況及びプレイヤーの状況を示す履歴のデータである。
これに対して、供給可能性イベントのログデータとは、プレイヤーが当該供給可能性イベントを体験した時点における、ゲームの進行状況及びプレイヤーの状況を示す履歴のデータである。

なお、以下、説明の簡略上、需要喚起イベントは端末２−１において発生され、供給可能性イベントは端末２−２において発生されるものとする。
つまり、図１の例では、イベント取得部１１のうち、需要喚起イベント取得部２１は、端末２−１で発生した需要喚起イベントのログデータを取得する一方、供給可能性イベント取得部２２は、端末２−２で発生した供給可能性イベントのログデータを取得するものとする。
ただし、需要喚起イベントも供給可能性イベントも、ゲームを実行中の任意の端末（端末２−１，２−２含む）で発生し得る点については言うまでもない。

ここで、このようなサーバ１に対して、需要喚起イベントのログデータを送信する端末（図１の例では端末２−１）においては、図１に示すように、ゲーム実行部３１と、ログデータ生成部３２と、ログデータ保持部３３と、需要喚起イベント検出部３４と、ログデータ送信制御部３５とが機能する。

ゲーム実行部３１は、所定のゲームを実行する。
ログデータ生成部３２は、当該所定のゲームの実行中においてログデータを逐次生成する。ログデータ保持部３３は、このようにして逐次生成されるログデータを保持する。
即ち、ゲームの進行状況やプレイヤーの状態は刻々と変化していくが、このようなゲームの進行状況やプレイヤーの状態を示すログデータが逐次（リアルタイム）取得されて保持されていく。
需要喚起イベント検出部３４は、需要喚起イベントが発生したことを検出する。
ログデータ送信制御部３５は、ゲームの実行中において所定のタイミングで生成されたログデータを、サーバ１に送信する制御を実行する。本実施形態では、需要喚起イベント検出部３４によって需要喚起イベントが検出されたときが所定のタイミングに該当する。つまり、本実施形態では、ログデータは、リアルタイムに逐次生成されていくが、サーバ１に常に送信されるわけではなく、需要喚起イベントが検出されたときのみ、需要喚起イベントのログデータとして送信される。

需要ログ記憶部１２は、このような端末２−１を含む各種端末から送信されてきた、需要喚起イベントのログデータを記憶する。

ここで、ゲーム内の所定イベントは、あるプレイヤーにとっては需要喚起イベントになる場合もあるし、別のプレイヤーにとっては需要喚起イベントとはならない場合（供給可能性イベントになる場合）もある。つまり、需要喚起イベントとなったプレイヤーの数は、ゲーム内の各種イベント毎に異なる。例えばクリアが難しいイベントでは、需要喚起イベントとなったプレイヤーの数が多くなると予想される。
従って、需要喚起イベントのログデータは、ゲーム内の各種各様なイベント毎に需要ログ記憶部１２に記憶され得る。また、同一イベントの観点でみると、各種各様な状況で当該イベントを体験した複数のプレイヤーの夫々についての複数の需要喚起イベントのログデータが、需要ログ記憶部１２に記憶され得る。

需要度合演算部１３は、供給可能性イベント取得部２２により取得された供給可能性イベントのログデータ、及び需要ログ記憶部１２に記憶された複数の需要喚起イベントのログデータに基づいて、当該供給可能性イベントと関連する需要喚起イベントを１以上選択する。
そして、需要度合演算部１３は、その選択結果に基づいて、当該供給可能性イベントのプレイ動画の潜在需要の度合（以下、「プレイ動画需要度合」と呼ぶ）を演算する。

なお、供給可能性イベントと関連する需要喚起イベントの選択手法は、特に限定されないが、本実施形態では次のような手法が適用されている。
即ち、需要度合演算部１３は、供給可能性イベントのログデータと、１以上の需要喚起イベントのログデータの夫々との相関量を算出する。
そして、需要度合演算部１３は、相関量が所定基準を満たすログデータを有する需要喚起イベントを、供給可能性イベントと関連するものとして選択する。

また、需要度合演算部１３によるプレイ動画需要度合の演算手法は、特に限定されないが、本実施形態では次のような手法が適用されている。

即ち、上述したように、あるプレイヤーにとっては供給可能性イベントとなったイベントであっても、別プレイヤーにとっては、需要喚起イベントになる場合もある。このような別プレイヤーにとっては、供給可能性イベントのプレイ動画（成功の状況に至るまでの過程を示すプレイ動画）の視聴を所望する可能性が高い。
従って、本実施形態では、需要度合演算部１３は、対象の供給可能性イベントと関連する需要喚起イベントの選択数が多いほど、プレイ動画需要度合を高める。

一方で、対象の供給可能性イベントのプレイ動画が別ユーザから既にアップロードされていれば、需要喚起イベントとなったユーザにとっては、既にアップロードされたプレイ動画を視聴すれば足りる場合もある。このような場合、新たな供給可能性イベントのプレイ動画の需要は減少すると把握することもできる。
本実施形態では、後述するプレイ動画記憶部１５には、過去に実行されたゲームについてのプレイ動画が多数アップロードされて記憶されている。そして、後述するプレイ動画管理部１６によって、プレイ動画記憶部１５に記憶された各プレイ動画のアクセスが管理されている。
需要度合演算部１３は、プレイ動画記憶部１５に既にアップロード済みのプレイ動画のうち、対象の供給イベントに関連するプレイ動画へのアクセス数を求め、当該アクセス数が多いほど、プレイ動画需要度合を低くする。

なお、プレイ動画需要度合の具体例として、本実施形態では需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）が採用されている。需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）の詳細については、後述する。

プレイ動画記録推薦報知部１４は、プレイ動画需要度合が所定の条件を満たす供給可能性イベントを発生させた端末（図１の例では端末２−２）に対して、当該供給可能性イベントのプレイ動画の記録を促す報知を行う。
なお、所定の条件は、特に限定されず、例えば所定の閾値を設け、プレイ動画需要度合が当該閾値を超えたという条件を採用してもよい。
報知の仕方は、特に限定されない。本実施形態の報知の具体例については、図２を参照して後述する。

このようなサーバ１に対して、供給可能性イベントのログデータを送信して、当該供給可能性イベントのプレイ動画の記録を促す報知がなされ得る端末（図１の例では端末２−２）においては、図１に示すように、ゲーム実行部４１と、ログデータ生成部４２と、ログデータ保持部４３と、供給可能性イベント検出部４４と、ログデータ送信制御部４５と、報知内容提示部４６とが機能する。

ゲーム実行部４１は、所定のゲームを実行する。
ログデータ生成部４２は、当該所定のゲームの実行中においてログデータを逐次生成する。ログデータ保持部４３は、このようにして逐次生成されるログデータを保持する。即ち、ゲームの進行状況やプレイヤーの状態を示すログデータが逐次（リアルタイム）に取得されて保持されていく点は端末２−１と同様である。
供給可能性イベント検出部４４は、供給可能性イベントが発生したことを検出する。
ログデータ送信制御部４５は、ゲームの実行中において所定のタイミングで生成されたログデータを、サーバ１に送信する制御を実行する。本実施形態では、供給可能性イベント検出部４４によって供給可能性イベントが検出されたときが所定のタイミングに該当する。つまり、本実施形態では、ログデータは、リアルタイムに逐次生成されていくが、サーバ１に常に送信されるわけではなく、供給可能性イベントが検出されたときのログデータ（供給可能性イベントの状況等を示すログデータ）のみが送信される。

報知内容提示部４６は、供給可能性イベントのプレイ動画の記録を促す報知がなされた場合、当該報知の内容をプレイヤーに提示する。
なお、提示の手法は特に限定されないが、本実施形態では、画像（例えば後述の画面１０３）を表示する手法が採用されている。
当該報知を受けたプレイヤーは、供給可能性イベントのプレイ動画の記録を所望する場合、所定の指示操作（後述の図２の例では画面１０３内の「はい」のボタンを押下する操作）をする。
プレイ動画生成部４７は、当該指示操作を受け付けると、供給可能性イベントのプレイ動画を生成し、サーバ１にアップロードする。

サーバ１のプレイ動画管理部１６は、端末２−２からアップロードされた供給可能性イベントのプレイ動画を、先に供給可能性イベント取得部２２により取得されたログデータと関連付けて、プレイ動画記憶部１５に記憶させる。
即ち、プレイ動画記憶部１５は、所定のゲームについての各種各様なプレイ動画（主に供給可能性イベントのプレイ動画）を記憶する。

さらに以下、図２以降の図面を参照して、本実施形態の情報処理システムについて詳細に説明する。
図２は、図１の端末２−１における需要喚起イベントの検出と、図１の端末２−２における供給可能性イベントの検出に基づくプレイ動画の推薦とを説明するための図である。

ステップＳａにおいて、需要喚起イベントの検出と集計が行われる。
具体的には例えば、画面１０１は、端末２−１のプレイヤーが実行するゲームにおいて、あるステージでゲームオーバーになってしまった状況を示している。このような失敗的な状況（即ち、負として処理される第１イベント）が当該ステージの需要喚起イベントとして検出され、当該需要喚起イベントのログデータがサーバ１の需要ログ記憶部１２に蓄積される。
このような需要喚起イベントのログデータは、端末２−１に限らず任意の端末において、需要喚起イベントが発生する毎に取得され、需要ログ記憶部１２に蓄積され、適宜イベント毎に集計が行われる。

ステップＳｂにおいて、供給可能性イベントの検出が行われる。
具体的には例えば、画面１０２は、端末２−２のプレイヤーが上記ステージをクリアした状況を示している。このような成功的な状況（即ち、正として処理される第２イベント）が当該ステージの供給可能性イベントとして検出される。
そして、当該供給可能性イベントについて、ステップＳａの集計結果に基づいてプレイ動画需要度合が算出される。
当該プレイ動画需要度合が高ければ（所定の条件を満たせば）、当該供給可能性イベントのプレイ動画（ステージをクリアするまでの過程を示すプレイ動画）の閲覧を所望する潜在的需要があるとみなされ、当該プレイ動画を作成してアップロードすることを推奨する画面１０３が端末２−２に提示される。

なお、このような供給可能性イベントのプレイ動画がサーバ１にアップロードされた場合、ステップＳｃにおいて、需要の高い動画像（プレイ動画）として、図示せぬリコメンデーションエンジンを通じて、需要喚起イベントが発生した端末２−１等に配信される。

このように、プレイ動画の推薦（画面１０３の提示）をするか否かは、プレイ動画需要度合に基づいて行われる。そこで、以下、プレイ動画需要度合についてより具体的に説明する。
上述したように、所定の供給可能性イベントについてのプレイ動画需要度合は、当該供給可能性イベントと関連する需要喚起イベントの数の多少に基づいて変化する。そして、当該供給可能性イベントと需要喚起イベントとが関連するか否かは、当該供給可能性イベントと需要喚起イベントとの各ログデータの相関量に基づいて行われる。

ここで、相関量の演算手法は、特に限定されないが、本実施形態では次のような手法が採用されている。
即ち、本実施形態のログデータは、ゲームの実行時に得られる属性情報を複数種類含んでおり、複数種類の属性情報の夫々を各要素として構成されるベクトル、即ち、多次元ベクトル空間上のベクトルで表されている。
そこで、需要度合演算部１３は、供給可能性イベントのログデータを表すベクトルと、需要ログ記憶部１２に記憶されている各需要喚起イベントのログデータを表すベクトルの夫々との多次元ベクトル空間上の距離を、相関量として算出する。

図３を参照して、このような相関量の演算手法のさらなる詳細について説明する。
図３は、多次元の特徴空間内で定義されたベクトル間の相関量を計量する手法について説明するための図である。
ここでは図解のため３次元で表現しているが、実際の特徴空間はｎ次元（ｎは、１以上の任意の整数値）のベクトル空間であり、各特長軸は、ゲームの実行時に得られる所定種類の属性情報、例えばゲーム内の個別のアイテムやスキル等に対応している。従って、あるプレイヤーのゲーム内の状態（ログデータ）は、この多次元ベクトル空間上の１つのベクトルとして表すことができる。
図３では、３人のプレイヤーの各状況（ログデータ）がベクトルＡ乃至Ｃの夫々で表されている。
このようなプレイヤーの状況を示すベクトル間の距離、即ちベクトル同士の内積が、相関量として用いられている。
図３の例では、ベクトルＡについては、ベクトルＣよりもベクトルＢの方が近距離である。従って、ベクトルＡに対応するプレイヤーの状況（ログデータ）は、ベクトルＣに対応するプレイヤーの状況（ログデータ）よりも、ベクトルＢに対応するプレイヤーの状況（ログデータ）と関連している（類似している）ことになる。

ここで、１つのログデータは、プレイヤーの状態を示すログデータＰと、ゲームの進行状態を示すログデータＱとの組み合わせ＜Ｐ，Ｑ＞として記述できる。

先ず、プレイヤーの状態を示すログデータＰは、プレイヤーのレベルや各種パラメータ、所有アイテム、所有スキル等のプレイヤーのゲーム内の属性情報を、次の式（１）で示すようなｎ次元のベクトルとして表現したものである。

・・・（１）
ここで、p_iは、プレイヤーのゲーム内の属性情報のうち、ｉ番目の属性に対応する０〜１の実数を示す。これらの値は、無限大ノルム正規化が行われていることが好ましい。例えば、最大レベルが１００のゲームでは、レベルの値を最大値で正規化することにより、レベル１を０．０１とし、レベル１００を１として表現することができる。また、多く所有することに価値があるタイプのアイテムについて、その所有数を表現するときは、所有可能な最大値で正規化することができる。これらの属性の数は、ゲーム内容に応じて、数百〜数千になる場合がある。例えば、ゲーム内に５００種類のアイテムがあり、スキルが５００種類ある時、ｎの値は１０００以上となる。

次に、ゲームの進行状態を示すログデータＱは、ゲームの進行状態、あるいは、ゲームの仮想空間上の場所を示すデータの集合として表現することができる。例えば、横にスクロールするアクションゲームにおいて、プレイヤーの到達した位置を表す有限個のセルＩＤのシーケンスをログデータＱに含めることができる。さらに、ＲＰＧ（Ｒｏｌｌ−Ｐｌａｙｉｎｇ Ｇａｍｅ）では、有限個のシーン番号を用いてゲームの進行状態を表現しているので、このシーン番号のシーケンスもログデータＱに含めることができる。一般に、ゲームソフトウェアはゲームの進行状態を管理するためのフラグやＩＤを内蔵しているので、ゲームの進行状態を示すログデータＱはそれらのデータを用いて容易に定義でき、次の式（２）で示すようなｍ次元のベクトルとして表現される。

・・・（２）
ここで、q_iは、プレイヤーのゲームの進行状態のうちｉ番目の状態を、プレイ動画が含んでいる場合は１の値となり、含んでいない場合は０の値となる。

なお、以下、重要喚起イベントと供給可能性イベントとのログデータを明確に区別すべく、需要喚起イベントのログデータを＜Ｐ⁻，Ｑ⁻＞と記述し、供給可能性イベントのログデータを＜Ｐ^＋，Ｑ^＋＞と記述する。

さらに本実施形態では、所定の供給可能性イベントについてのプレイ動画需要度合は、当該供給可能性イベントと関連する需要喚起イベントの数の多少のみならず、当該供給可能性イベントと関連するプレイ動画が既にアップロードされているか否かに基づいても変化する。
このため、プレイ動画記憶部１５に既にアップロードされている所定イベントのプレイ動画（以下、「既存プレイ動画」と呼ぶ）についても、当該所定ベントのログデータが対応付けられているものとする。このような既存プレイ動画に対応付けられたログデータを、上述の重要喚起イベントと供給可能性イベントとのログデータを明確に区別すべく、＜Ｐ，Ｑ＞と記述するものとする。

このようにして定義された３種類のログデータを用いたプレイ動画需要度合の具体的な演算例について、ステップＳＡ乃至ＳＥの５段階にわけて説明する。
なお、以下の例では、プレイ動画需要度合は、スコアとして算出される。そこで以下、このようなスコアを「需要スコア」と呼ぶ。

ステップＳＡは、需要喚起イベントを検出するステップである。
図１の例では端末２−１のみであるが、実際には、サーバ１により管理される図示せぬ全端末のゲームのプレイ状況がモニタリングされ、需要喚起イベントが検出される。
需要喚起イベントが検出される毎に、需要喚起イベントのログデータ＜Ｐ−，Ｑ−＞が需要ログ記憶部１２に蓄積される。

ステップＳＢは、供給可能性イベントを検出するステップである。
図１の例では端末２−２のみであるが、実際には、サーバ１により管理される図示せぬ全端末のゲームのプレイ状況がモニタリングされ、供給可能性イベントが検出される。
供給可能性イベントが検出されると、供給可能性イベントのログデータ＜Ｐ＋，Ｑ＋＞が需要度合演算部１３に取得される。
そこで、需要度合演算部１３は、次のステップＳＣ乃至ＳＦの処理を実行する。

ステップＳＣは、ステップＳＢで検出された供給可能性イベントと関連する既存プレイ動画を選択して、データ集合Ｖとするステップである。
需要スコアは、当該供給可能性イベントと関連する既存プレイ動画が存在する場合には、当該既存プレイ動画のアクセス数が多いほど（重複するほど）低下させると好適である。

そこで、本実施形態では、供給可能性イベントとの相関量が所定条件を満たす（一定以上に類似している）ログデータを有する既存プレイ動画が、当該供給可能性イベントと関連する既存プレイ動画として抽出される。
具体的には、需要度合演算部１３は、当該供給可能性イベントのログデータ＜Ｐ^＋，Ｑ^＋＞と、各既存プレイ動画のログデータ＜Ｐ，Ｑ＞との相関量を、次の式（３）で示すような２つの内積によって算出する。

・・・（３）
ここで、ｓｃｏｒｅＰ（Ｐ^＋，Ｐ）は、当該供給可能性イベントを発生させたプレイヤーの状態を示すログデータＰ^＋と、各既存プレイ動画をアップロードしたプレイヤーの状態を示すログデータＰとの相関量の重み値を示す。この重み値が高いほど、プレイヤーの状態が類似していることになる。
また、ｓｃｏｒｅＱ（Ｑ^＋，Ｑ）は、当該供給可能性イベントにおけるゲームの進行状態を示すログデータＱ^＋と、各既存プレイ動画が示すゲームの進行状態を示すログデータＱとの相関量の重み値を示す。この重み値が高いほど、ゲームの進行状態が類似していることになる。

需要度合演算部１３は、これら２つの重み値を組み合わせた次の式（４）により、当該供給可能性イベントに対する各既存プレイ動画の相関量を計量する。

・・・（４）
即ち、需要度合演算部１３は、ｓｃｏｒｅＱ（Ｑ^＋，Ｑ）が所定の閾値ｔを上回る各既存プレイ動画について、上記２つの重み値の積として、相関量ｒｅｌ（＜Ｐ^＋，Ｑ^＋＞，＜Ｐ，Ｑ＞）を算出する。

そして、需要度合演算部１３は、当該相関量ｒｅｌ（＜Ｐ^＋，Ｑ^＋＞，＜Ｐ，Ｑ＞）が所定の閾値を超える既存プレイ動画を選択して、選択された既存プレイ動画の集合をデータ集合Ｖと定義する。

ステップＳＤは、ステップＳＢで検出された供給可能性イベントと関連する需要喚起イベントを選択して、データ集合Ｅとするステップである。
需要スコアは、当該供給可能性イベントと関連する需要喚起イベントの数が多いほど上昇すると考えられる。

そこで、本実施形態では、供給可能性イベントとの相関量が所定条件を満たす（一定以上に類似している）ログデータを有する需要喚起イベントが、当該供給可能性イベントと関連する需要喚起イベントとして抽出される。
具体的には、需要度合演算部１３は、当該供給可能性イベントのログデータ＜Ｐ^＋，Ｑ^＋＞と、各需要喚起イベントのログデータ＜Ｐ−，Ｑ−＞との相関量を、上述の式（３）と同様の式に従って算出する。
そして、需要度合演算部１３は、次の式（５）により、当該供給可能性イベントに対する各需要喚起イベントの相関量を計量する。

・・・（５）
即ち、需要度合演算部１３は、ｓｃｏｒｅＱ（Ｑ^＋，Ｑ⁻）が所定の閾値ｔを上回る各需要喚起イベントについて、相関量ｒｅｌ（＜Ｐ^＋，Ｑ^＋＞，＜Ｐ⁻，Ｑ⁻＞）を算出する。

そして、需要度合演算部１３は、当該相関量ｒｅｌ（＜Ｐ^＋，Ｑ^＋＞，＜Ｐ⁻，Ｑ⁻＞）が所定の閾値を超える需要喚起イベントを選択して、選択された需要喚起ベントの集合をデータ集合Ｅと定義する。

ステップＳＥは、データ集合Ｖとデータ集合Ｅから需要スコアを算出するステップである。
上述のように、データ集合Ｅに含まれるデータ数、即ち供給可能性イベントと関連する需要喚起イベントの数が多いほど、需要スコアを上昇させると好適である。一方、データ集合Ｖに含まれるデータ、即ち供給可能性イベントと関連のある既存プレイ動画のアクセス数が多いほど、需要スコアを低下させると好適である。
そこで、本実施形態の需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）は、次の式（６）のように算出される。なお、式（６）のｒｅｌ（Ｅｊ）は、データ集合Ｅのｊ番目の要素の需要喚起イベントＥ_ｊについて計算したものである。

・・・（６）
ここで、ｐａｇｅｖｉｅｗ（Ｖ_ｉ）とｆｅｅｄｂａｃｋ（Ｖ_ｉ）は、データ集合Ｖのｉ番目の要素のプレイ動画のページビュー数と当該プレイ動画へのソーシャルフィードバックの回数を示す。即ち、既存プレイ動画のアクセス数として、本実施形態では、閲覧数（ページビュー数）と、評価数（ソーシャルフィードバックの回数）とが採用されている。

プレイ動画記録推薦報知部１４は、上述の式（６）に従って算出された需要スコアが所定の条件を満たす場合（例えば所定の閾値を超える場合）、供給可能性イベントを発生させた端末２−２のプレイヤーに対して、当該供給可能性イベントのプレイ動画を記録してアップロードをするすることを勧める報知をする。即ち図２の例では画面１０３が端末２−２に表示される。

次に、図４を参照して、供給可能性イベントを発生させた端末２−２と、サーバ１との間で実行される処理の関係について説明する。このような処理は、供給可能性イベントのプレイ動画の録画の推奨が行われるため、以下、「録画推奨処理」と呼ぶ。
図４は、本実施形態に関わる録画推奨処理の流れを説明するフローチャートである。

ステップＳ１において、端末２−２のゲーム実行部４１は、ゲームを実行する。

ステップＳ２において、ログデータ生成部４２は、ゲームの進行に合わせてログデータを逐次生成し、ログデータ保持部４３に保持させる。

ステップＳ３において、供給可能性イベント検出部４４は、供給可能性イベントが発生したか否かを判定する。

供給可能性イベントが未だ発生していない場合、ステップＳ３においてＮＯであると判定されて、処理はステップＳ９に進む。

ステップＳ９において、ゲーム実行部４１は、ゲーム実行が終了したか否かを判定する。
ゲーム実行が終了した場合、ステップＳ９においてＹＥＳと判定され、録画推奨処理は終了する。
これに対して、ゲームが続行されている場合、ステップＳ９においてＮＯであると判定され、処理はステップＳ２に戻される。
即ち、ゲームが続行されている場合には、供給可能性イベントが発生するまでの間、ステップＳ２、ステップＳ３Ｎｏ、及びステップＳ９Ｎｏのループ処理が繰り返されて、ログデータが逐次生成され続ける。ただし、ログデータはサーバ１に送信されない。

この間、ステップＳ１１において、サーバ１の供給可能性イベント取得部２２は、供給可能性ログデータを受信したか否かを判定する。
供給可能性ログデータが未受信の場合、ステップＳ１１においてＮＯであると判定されて、処理はステップＳ１７に進む。

ステップＳ１７において、サーバ１は、処理の終了が指示されたか否かを判定する。
処理の終了の指示は、特に限定されず、例えばサーバ１の電源遮断等を採用することができる。
処理の終了の指示がなされた場合、ステップＳ１７においてＹＥＳと判定され、録画推奨処理は終了する。
これに対して、処理の終了の指示がなされていない場合、ステップＳ１７においてＮＯであると判定され、処理はステップＳ１１に戻される。
即ち、処理の終了の指示がなされていなければ、供給可能性イベントが受信されるまでの間、ステップＳ１１Ｎｏ、及びステップＳ１７Ｎｏのループ処理が繰り返されて、サーバ１は待機状態になる。

端末２−２において実行されているゲーム中に供給可能性イベントが発生すると、ステップＳ３においてＹＥＳであると判定されて、処理はステップＳ４へ進む。
ステップＳ４において、端末２−２のログデータ送信制御部４５は、ログデータ保持部４３に保持されているログデータを、当該供給可能性イベントのログデータとしてサーバ１に送信する。

この場合、サーバ１側では、ステップＳ１１においてＹＥＳであると判定されて、処理はステップＳ１２に進む。
ステップＳ１２において、サーバ１の需要度合演算部１３は、プレイ動画需要度合を演算する。
本実施形態では、上述のステップＳＣ乃至ＳＥの処理が実行されて、式（６）に示す需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）が、プレイ動画需要度合として演算される。

ステップＳ１３において、プレイ動画記録推薦報知部１４は、プレイ動画需要度合が所定要件を満たすか否かを判定する。
ここで、所定要件は、特に限定されないが、本実施形態ではプレイ動画需要度合として需要スコアが採用されていることから、需要スコアが所定の閾値を超えていることという要件が採用されているものとする。
従って、需要スコアが所定の閾値を超えない場合、ステップＳ１３においてＮＯであると判定されて、処理はステップＳ１７に進む。即ち、処理の終了が指示されていない場合、次の供給可能性ログデータが受信されるまでの間、サーバ１は待機状態になる。
これに対して、需要スコアが所定の閾値を超える場合、ステップＳ１３においてＹＥＳであると判定されて、処理はステップＳ１４に進む。

ステップＳ１４において、サーバ１のプレイ動画記録推薦報知部１４は、供給可能性イベントを発生させた端末２−２に対して、供給可能性イベントのプレイ動画の記録を促す報知を行う。
即ち、ステップＳ６において、端末２−２の報知内容提示部４６は、当該報知の内容をプレイヤーに提示する。
なお、報知の提示手法は、特に限定されないが、本実施形態では、図２の画面１０３を端末２−２に表示させる手法が採用されている。

ステップＳ７において、端末２−２のプレイ動画生成部４７は、録画の指示があったか否かを判定する。
本実施形態では、録画の指示は、図２の画面１０３の「はい」のボタンの押下操作により行われる。
従って、図２の画面１０３の「はい」のボタンの押下操作がなされていない場合、ステップＳ７においてＮＯであると判定されて、処理はステップＳ９に進む。即ち、この場合、プレイ動画の録画は推奨されたものの、プレイヤーに受け入れられず、供給可能性イベントのプレイ動画は録画されない。この場合、さらにゲームが進んでログデータが逐次生成され、新たな供給可能性イベントが発生すると、上述のステップＳ４以降の処理が実行されることになる。

これに対して、図２の画面１０３の「はい」のボタンの押下操作がなされると、ステップＳ７においＹＥＳであると判定されて、処理はステップＳ８に進む。
ステップＳ８において、プレイ動画生成部４７は、供給可能性イベントのプレイ動画を録画して、サーバ１にアップロードする。

この間、ステップＳ１６において、サーバ１のプレイ動画管理部１６は、プレイ動画がアップロードされたか否かを判定する。
判定手法は、特に限定されないが、例えば本実施形態では、所定時間経過内にアップされない場合、アップロードされなかったと判定する手法が採用されている。
アップロードされなかったと判定された場合、即ちステップＳ１５においてＮＯであると判定されて、処理はステップＳ１７に進む。即ち、サーバ１は待機状態になる。

これに対して、アップロードされた場合にはステップＳ１５においてＹＥＳであると判定されて、処理はステップＳ１６に進む。
ステップＳ１６において、プレイ動画管理部１６は、アップロードされた、供給可能性イベントのプレイ動画をプレイ動画記憶部１５に記録する。
なお、プレイ動画記憶部１５に記録された当該プレイ動画は、今後発生し得る他の供給可能性イベントにとって、既存プレイ動画となる。このため、プレイ動画管理部１６は、ステップＳ１１（ＹＥＳ）の処理で受信された供給可能性イベントのログデータを、ログデータとして、プレイ動画に対応付けて管理する。
このようなステップＳ１６の処理が終了すると、処理はステップＳ１７に進む。即ち、サーバ１は待機状態になる。

以上説明した本実施形態の情報処理システムは、多様なイベントの正負の種類（敵を倒す／倒せない、ステージをクリアする／クリアできない、難易度の高い必殺技で敵を倒す／必殺技が出せない、など）に応じて、プレイ動画の需要の集計と、プレイ動画の作成を推薦することが可能であるため、様々なジャンルのゲームに適用することができる。

本実施形態の情報処理システムは、潜在的に需要が高いシーンや状況を自動的に検出し、当該シーンで成功的なプレイをしたプレイヤーへ、プレイ動画を作成することを強く動機づけることが出来るため、動画の作成者には、動画が多数のユーザに見られる機会を提供するとともに、ゲームのプレイヤーには、ゲームの新たなプレイの仕方を伝達できる。

詳細には、本実施形態の情報処理システムは、他プレイヤーからの需要が高いと推定されるシーンや状況において、プレイ動画を撮影することを、プレイヤーに推薦する、プレイ動画撮影タイミング推薦方式を適用している。
従って、本実施形態の情報処理システムは、例えば、初心者がある特定のステージで行き詰っている状況や、特定のボスが倒せない状況（負として処理される第１イベント、即ち需要喚起イベント）を、プレイ動画の需要として集計していく。
次に、あるプレイヤーが、当該の状況を解決するプレイをしたときに（正として処理される第２イベント、即ち供給可能性イベント）、そのプレイ内容が、プレイ動画として需要の高いものであることを示し、プレイ動画として保存してアップロード（共有）することを推薦する。
これにより、自動的に、プレイ動画の需要と供給のマッチングを行うとともに、潜在的に需要が高いシーンや状況において、プレイ動画を作成することを強く動機づけることが出来る。
つまり、プレイヤーがゲーム内で実行したイベントの種類に応じて、プレイ動画が公開されたときの需要をリアルタイムに計算し、需要の高いシーンのみをピンポイントで撮影することを推薦することができる。

より具体的に言えば、端末２−１，２−２等ゲームを実行する端末は、ゲーム専用端末の場合もあるが、スマートフォン等、ゲーム専用ではない端末である場合も多い。このようなゲーム専用ではない端末でゲームをするユーザ（プレイヤー）の多くは、いわゆるカジュアルユーザである。
このようなカジュアルユーザにとって、他ユーザにとって望まれるプレイ動画、即ち他ユーザからの需要があるプレイ動画がどのようなものであるかは、自明ではない。
このため、従来、カジュアルユーザにとって、他ユーザの需要を満たす動画像をピンポイントで作成することは容易ではなかった。また、カジュアルユーザにとって、他ユーザから評価されないかもしれないという不安が、プレイ動画を作成して公開することを阻害する、高い心理的ハードルとなっていた。

ここで、ＹｏｕＴｕｂｅ（登録商標）等の動画サイト上では、人気のある動画像ほどランキングの上位に位置する傾向が強く、カジュアルユーザによる動画投稿が、他のカジュアルユーザに閲覧される可能性は低い。また、既存の人気動画や公式動画は、高度に編集されており、カジュアルユーザが気軽に作成できるものではない。したがって、既存技術は、動画像をアップロードすべき適切なタイミング、および、適切な内容を、カジュアルユーザに提示するメカニズムを持たないため、一般利用者にプレイ動画作成を継続的に動機づけることは難しい。

従って、このようなカジュアルユーザに対して、プレイ動画の作成の契機づけを与えないことには、プレイ動画作成のツールキットが組み込まれたゲームも普及しない。
特に、ゲームのプレイ時間をずっと撮影したものではなく、面白いプレイ、美しいプレイ、ボスを鮮やかに倒すプレイ等の、ピンポイントのプレイ動画の作成の契機づけを与えることが、プレイ動画作成のツールキットが組み込まれたゲームの普及に貢献すると思われる。
即ち、多様なプレイヤーからの多様なプレイ動画の需要と、カジュアルユーザが作成するプレイ動画の内容との、マッチング・メカニズムの実現が重要である。このようなマッチング・メカニズムが、本実施形態の情報処理システムにより実現されたことになる。
即ち、本実施形態の情報処理ステムを適用することで、プレイヤーに「今のプレイ」の需要が高いことを伝え、動画のアップロードを動機づけることが可能になる。これにより、プレイ動画への潜在的な需要を迅速に充足させる、プレイ動画の共有と視聴のサイクルを確立することが容易に実現可能になる。その結果、プレイ動画作成機能を有するゲームの普及に貢献すると思われる。

さらに、本実施形態の情報処理システムは、次のような利点も有している。

例えば、潜在的なプレイ動画作成者を発掘できるという利点がある。即ち、プレイ動画を撮影するつもりはなかったプレイヤーにも、実際には、自分のプレイ内容を見ることで、他の人が助かることを伝えることにより、新たな動画作成者として発掘することが出来る。プレイ動画により、ゲームへのコミットメントを強化することになるため、プレイヤーはゲームを継続する可能性が高くなる。

また例えば、互換性の点でも利点がある。即ち、プレイ動画作成の推薦機能は、任意のゲーム動画を録画すＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）とともに実装することができる。即ち、特定のプレイ動画録画方法に依存することなく情報処理システムの構築が可能になる。

また例えば、独自性の点でも利点がある。即ち、ゲーム内容と連動したプレイ動画作成の推薦は、独自性が高い。

また例えば、汎用性の点でも利点がある。本実施形態の情報処理システムは、途中中断することが可能な、任意のゲームタイトルに適用することができる。また、上述のプレイ動画録画の推薦は、特定のゲームのジャンルに依存しておらず、アクション、ＲＰＧ、シューティング、シミュレーションなど、幅広いゲームのジャンルに適用することが可能である。

以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

上述の実施形態では、イベントのログデータを多次元ベクトル空間上のベクトルとして示したが、特にこれに限定されず、即ちログデータを必ずしもそのように表す必要はなく、例えば、ヒストグラムや、ツリー構造上のノード、ネットワークグラフ中のノードなど、多様な手法が選択可能である。
ヒストグラムとして表現した場合、２つのヒストグラム間の類似性は、ヒストグラム・インターセクションと呼ばれる距離尺度や、Ｅａｒｔｈ Ｍｏｖｅｒ’ｓ Ｄｉｓｔａｎｃｅと呼ばれる距離尺度を用いて計量することが可能である。ツリー構造やネットワークグラフ構造中の２つのノードは、ノード間の距離を、ホップ数として計量することができる。本発明では、２つの分布データの間に、有意な距離尺度を与えることができる、任意のデータ構造を用いることが可能である。

また、例えばプレイ動画の記憶場所は、上述の実施形態ではサーバ１のプレイ動画記憶部１５とされたが、特にこれに限定されず、サーバ１とは別の場所（例えばＹｏｕＴｕｂｅ（登録商標）における動画ストレージ）としてもよい。
即ち、プレイ動画は、必ずしもサーバ１にアップロードする必要はなく、別の場所にアップロードしてその所在データ（例えばＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ））でサーバ１は管理してもよい。
つまり、端末２−２からプレイ動画をアップロードする際、サーバ１にアップロードするのではなく、ＹｏｕＴｕｂｅ（登録商標）等にアップロードしてＵＲＬを取得し、当該ＵＲＬのみをサーバ１に送信するようにしてもよい。

換言すると、本発明が適用される情報処理システムは、上述の図１の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施形態を取ることができる。
即ち、本発明が適用される情報処理システムは、
ゲームを実行し得る複数の端末と、サーバとを含む情報処理システムである。
前記サーバ（例えば図１のサーバ１）は、
前記複数の端末のうち、前記ゲーム内で負として処理された第１イベント（例えば上述の需要喚起イベント）を発生させた端末（例えば図１の端末２−１）から当該第１イベントのログデータを取得し、前記ゲーム内で正として処理された第２イベント（例えば上述の供給可能性イベント）を発生させた端末（例えば図１の端末２−２）から当該第２イベントのログデータを取得するイベント取得手段（例えば図１のイベント取得部１１）と、
取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合（例えば上述の式（６）で示す需要スコア）を演算する度合演算手段（例えば図１の需要度合演算部１３）と、
当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、当該第２イベントに関する動画像の記録を促す報知を行う報知手段（例えば図１のプレイ動画記録推薦報知部１４）と、
を備える。
前記複数の端末の少なくとも一部（例えば図１の端末２−１，２−２）は、
前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出手段（例えば図１の需要喚起イベント検出部３４，供給可能性イベント検出部４４）と、
前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供手段（例えば図１のログデータ送信制御部３５，ログデータ送信制御部４５）と、
前記サーバからの前記報知の内容を提示する提示手段（例えば報知内容提示部４６）と、
を備える。

これにより、ゲーム実行中のプレイヤーに対して、プレイ内容を録画したプレイ動画に閲覧需要があることを報知し、当該プレイ動画データをアップロードすべき動機付けを与えることができる。

上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、図１の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図１の例に限定されない。また、機能ブロックの存在場所も、図１に特に限定されず、任意でよい。例えば、サーバ１の機能ブロックを端末２−２等に移譲させてもよいし、逆に端末２−２の機能ブロックをサーバ１等に移譲させてもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

１・・・サーバ、２−１，２−２・・・端末、１１・・・イベント取得部、１２・・・需要ログ記憶部、１３・・・需要度合演算部、１４・・・プレイ動画記録推薦報知部、１５・・・プレイ動画記憶部、１６・・・プレイ動画管理部、２１・・・需要喚起イベント取得部、２２・・・供給可能性イベント取得部、３１・・・ゲーム実行部、３２・・・ログデータ生成部、３３・・・ログデータ保持部、３４・・・需要喚起イベント検出部、３５・・・ログデータ送信制御部、４１・・・ゲーム実行部、４２・・・ログデータ生成部、４３・・・ログデータ保持部、４４・・・供給可能性イベント検出部、４５・・・ログデータ送信制御部、４６・・・報知内容提示部、４７・・・プレイ動画生成部

Claims (10)

1. ゲームを実行し得る複数の端末と、サーバとを含む情報処理システムにおいて、
   前記サーバは、
   前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、前記ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
   取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算手段と、
   当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、当該第２イベントに関する動画像の記録を促す報知を行う報知手段と、
   を備え、
   前記複数の端末の少なくとも一部は、
   前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出手段と、
   前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供手段と、
   前記サーバからの前記報知の内容を提示する提示手段と、
   を備える、
   情報処理システム。
2. ゲームを実行し得る複数の端末と通信をするサーバにおいて、
   前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
   取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する動画像の潜在需要の度合を演算する度合演算手段と、
   前記度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知手段と、
   を備えるサーバ。
3. 前記ログデータは、前記ゲームの実行時に得られる属性情報を１種類以上含み、
   前記度合演算手段は、
   前記第２イベントの前記ログデータと、１以上の前記第１イベントの前記ログデータの夫々との相関量を算出し、
   前記相関量が所定基準を満たす前記ログデータを有する前記第１イベントを、前記第２イベントと関連するものとして選択する、
   請求項２に記載のサーバ。
4. 前記ログデータは、前記ゲームの進行状況を示すログデータと、前記ゲームのプレイヤーの状態を示すログデータとを含む
   請求項３に記載のサーバ。
5. 前記ログデータは、多次元ベクトル空間上のベクトルで表され、
   前記度合演算手段は、前記第２イベントの前記ログデータを表すベクトルと、１以上の前記第１イベントの前記ログデータを表すベクトルの夫々との前記多次元ベクトル空間上の距離を、前記相関量として算出する
   請求項３又は４に記載のサーバ。
6. 前記度合演算手段は、
   前記第２イベントと関連する前記第１イベントの選択数が多いほど、当該第２イベントに関する動画像の潜在需要の前記度合を高める、
   請求項２乃至５のうち何れか１項に記載のサーバ。
7. 過去に実行された前記ゲームの所定イベントに関する動画像又は当該動画像の所在データを管理する管理手段をさらに備え、
   前記度合演算手段は、
   前記管理手段により管理されている前記動画像又は前記所在データにより特定される動画像のうち、前記第２イベントに関連する動画像へのアクセス数を求め、
   当該アクセス数が多いほど、当該第２イベントに関する動画像の潜在需要の前記度合を低下させる、
   請求項２乃至６のうち何れか１項に記載のサーバ。
8. ゲームを実行し得る複数の端末との通信を含む制御を実行するコンピュータに、
   前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得ステップと、
   取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算ステップと、
   前記度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知ステップと、
   を含む制御処理を実行させるプログラム。
9. ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得機能と、
   取得された前記ログデータの夫々に基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算し、当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知機能と、
   を備えるサーバとの間で通信する端末を制御するコンピュータに、
   前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出ステップと、
   前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供ステップと、
   前記サーバからの前記報知の内容を提示する提示ステップと、
   を含む制御処理を実行させるプログラム。
10. ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得機能と、
    取得された前記ログデータの夫々に基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算し、当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知機能と、
    を備えるサーバとの間で通信する情報処理装置が実行する情報処理方法であって、
    前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出ステップと、
    前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供ステップと、
    前記サーバからの前記報知の内容を提示する提示ステップと、
    を含む情報処理方法。

Images