JP2015161709A - 再生装置、再生システム、アプリケーションプログラム - Google Patents

Abstract

【課題】複数の端末に記録されたコンテンツを再生装置で再生する場合に、ユーザの操作を軽減する。
【解決手段】通信部を通じて接続された各端末が記録するコンテンツのリストと、端末ごとのコンテンツの再生回数とを含むコンテンツ情報を取得し、取得した前記端末ごとのコンテンツの再生回数をもとに、各コンテンツの優先度を算出し、算出された前記優先度に応じて、前記各コンテンツの再生順序を決定する。そして、各端末に前記再生順序に対応したコンテンツを前記通信部を通じて要求し、要求に応じて取得されたコンテンツを前記再生部に再生させる。
【選択図】図３

Description

本発明は、端末と通信を行いつつ、この端末に記録されたコンテンツの再生を行う再生装置に関する。

２つの端末の間に通信を確立させておき、ある端末が記録するコンテンツを、他の端 末にストリーミングして、再生させる発明が開示されている（例えば、特許文献１参照）。このような、コンテンツのストリーミングを受ける端末（再生装置）は、コンテンツを記録することなく他の端末が記録するコンテンツを再生することができる。

特開２００８−２６８３０８号公報

２つ以上の端末に記録されたコンテンツを、ストリーミングして再生装置に再生させる場合、ソース側の端末は何ら連携していないため、ユーザが手動で端末の切り替えを行ったり、コンテンツの選曲を行う必要がある。たとえば、Ｂｌｕｅｔｏｏｔｈなどの近距離無線の規格を用いて端末同士を接続する場合、端末との間で１対１でのペアリング作業が必要となる。そのため、ユーザに煩雑な操作を求める結果となる。

本発明は、上記課題にかんがみてなされたもので、複数の端末に記録されたコンテンツを再生装置にストリーミングして再生する場合に、ユーザの操作を軽減することを目的とする。

・適用例１
上記課題を解決するために、本発明の一態様では、通信部と、再生部と、前記通信部を通じて接続された各端末が記録するコンテンツのリストと、端末ごとのコンテンツの再生回数とを含むコンテンツ情報を取得するコンテンツ情報取得部と、取得した前記端末ごとのコンテンツの再生回数をもとに、各コンテンツの優先度を算出する優先度算出部と、算出された前記優先度に応じて、前記各コンテンツの再生順序を決定する再生順序決定部と、各端末に前記再生順序に対応したコンテンツを前記通信部を通じて要求するコンテンツ要求部と、前記要求に応じて取得されたコンテンツを前記再生部に再生させる再生制御部と、を有する。

上記のように構成された発明では、まず、端末ごとのコンテンツの再生回数をもとに、各コンテンツの優先度を算出する。次に、算出した優先度に応じて、各コンテンツの再生順序を決定する。このように決定された再生順序に応じて、各端末に再生順序に対応したコンテンツを通信部を通じて要求する。
そのため、各端末が記録するコンテンツ再生順序を各ユーザの嗜好に合わせて決定し、決定された再生順序に応じて端末にコンテンツファイルをストリーミングすることができる。すなわち、ユーザが端末から再生装置にコンテンツをストリーミングして再生する場合に端末に対して煩雑な操作を行う必要がなくなる。

・適用例２
本発明の一態様では、前記コンテンツ情報には、各コンテンツの属性情報が前記リストに対応づけて記録されており、前記優先度算出部は、前記属性情報ごとの前記再生回数を集計して、前記コンテンツの優先度を算出する。
上記のように構成された発明では、ある属性情報に注目してコンテンツの再生順序を決定することができ、ユーザの嗜好を再生順序により効果的に反映させることができる。

・適用例３
本発明の一態様では、前記属性情報は、第１の属性情報と、第２の属性情報と、を含み、前記優先度算出部は、前記第１の属性情報における優先度と、前記第２の属性情報における優先度と、の積にもとづいて前記コンテンツの優先度を算出する。
上記のように構成された発明では、複数の属性情報を組み合わせることができるため、ユーザの嗜好を再生順序により効果的に反映させることができる。

・適用例４
本発明の一態様では、前記優先度算出部は、各端末における再生回数の割合が高いコンテンツの優先度を高くする。
上記のように構成された発明では、端末間の平均では、再生回数が低くとも、特定の端末において再生回数が高いコンテンツの優先度を高くすることができ、再生順序の決定をより柔軟に行うことが可能となる。

・適用例５
本発明の一態様では、前記再生順序決定部は、重複するコンテンツが存在する場合に、いずれかのコンテンツのみを再生順序に加える。
上記のように構成された発明では、重複するコンテンツの再生を抑制することができる。

・適用例６
本発明の一態様では、前記通信部は、ＬＡＮで前記端末と接続している。
上記のように構成された発明では、複数の端末と一度に接続を行うことができるため、再生装置と端末との間の接続に要する処理を簡単にすることができる。

また、本発明は再生装置として捉えるのみならず、再生装置を一部に含む再生システムや、本発明の特徴を備える、再生方法としても捉えることができる。
また、本発明の再生装置とともに使用される端末に、所定の処理を実行させるためのアプリケーションプログラムとしても適用することができる。

一例としての再生システムを示す外観図。 再生装置のハードウェア構成を示すブロック構成図。 再生装置の機能を説明する機能ブロック図。 一例としての、端末から表示装置１０へ送信されるコンテンツ情報Ｃｄを示す図。 コンテンツの再生回数と、優先度との関係を説明する図。 端末３０の構成を示すブロック構成図。 端末３０がコンテンツ情報Ｃｄを記録す方法を説明するフローチャート。 コンテンツの再生方法を示すフローチャート。 一例としてのプレイリストＰｌを示す図。 ステップＳＡ４において実行される優先度の算出方法を説明するフローチャート。 コンテンツ情報Ｃｄからコンテンツごとの優先度βが算出される手法を説明する図。 コンテンツ情報Ｃｄからコンテンツごとの優先度βが算出される手法を説明する図。 第２の実施形態において、ステップＳＡ４において実行される優先度の算出方法を説明するフローチャート。 第２の実施形態での優先度δを説明する図である。 第３の実施形態において、図８のステップＳ５において実行される処理を示すフローチャート。

以下、下記の順序に従って本発明の実施形態を説明する。
１．第１の実施形態：
（１）再生システムの構成
（２）コンテンツ情報の記録方法
（３）コンテンツ再生方法
（４）優先度の算出方法
２．第２の実施形態：
３．第３の実施形態：
４．その他の実施形態：

１．第１の実施形態：
（１）再生システムの構成
図１は、一例としての再生システムを示す外観図である。
この第１の実施形態では、再生システム１００の一部を構成する再生装置として、車載型の表示装置１０を例に説明を行う。表示装置１０は、図示ない車両の内部に搭載されており、車両に乗車したユーザにカーナビゲーションや、コンテンツの再生等のサービスを提供することができる。また、表示装置１０は、端末３０、４０、５０との間で通信を確立し、端末３０−５０からコンテンツのストリーミング（提供）を受けることができる。すなわち、この実施形態では、端末３０−５０は、コンテンツをストリーミングするソース機器として機能する。

図２は、再生装置のハードウェア構成を示すブロック構成図である。
表示装置１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、フラッシュメモリ１４、通信ＩＦ１５、タッチパネルモジュール１６、音声出力部１７、バス１８を備える。表示装置１０の各部は、バス１８を通じて互いに接続されている。

通信ＩＦ１５は、表示装置１０を端末３０−５０と接続させる。通信ＩＦ１５は、例えば、Ｗｉ−Ｆｉに対応するプロトコルにより、表示装置１０と端末３０−５０とを接続する。そのため、確立された通信網を介して、端末３０−５０から表示装置１０にコンテンツや、コンテンツの情報（コンテンツ情報）が送信される。
また、通信ＩＦ１５がＷｉ−ＦｉなどのＬＡＮを用いて端末３０−５０と接続することで、１つの通信網により複数の端末と接続することができる。

タッチパネルモジュール１６は、ユーザの操作入力を受付ける。受付けた操作はバス１８を通じてＣＰＵ１１に入力される。無論、表示装置１０がタッチパネルモジュール１６を備えることが一例に過ぎず、ユーザからの操作を受付けるものであればどのようなものであってもよい。

ＣＰＵ１１は、通信ＩＦ１５を通じて入力したコンテンツや、コンテンツ情報、タッチパネルモジュール１６を通じて入力した操作入力をもとに、表示装置１０の駆動を統合的に制御する。

ＲＯＭ１２には、ＣＰＵ１１がバス１８に接続された各ハードウェアを制御するためのＯＳ（Operating System）１２１や、ＣＰＵ１１が端末３０−５０から取得したコンテンツやコンテンツ情報をもとに、コンテンツの再生を制御するためのプログラムモジュール１２２が、記録されている。そのため、ＣＰＵ１１がＯＳ１２１や、プログラムモジュール１２２をＲＡＭ１３に展開して実行し、各ハードウェアを制御することができる。
なお、ＣＰＵ１１がＯＳ１２１を用いてハードウェア等を制御することは一例に過ぎず、ＣＰＵ１１がＯＳ１２１以外のプログラムによりハードウェア等を制御するものであってもよい。

図３は、再生装置の機能を説明する機能ブロック図である。図３では、ＣＰＵ１１がＲＯＭ１２に記録されたＯＳ１２１やプログラムモジュール１２２を実行することで実現される機能と、ハードウェアとの関係を示している。

コンテンツ情報取得部１１１は、通信ＩＦ１５を通じて接続された端末３０−５０が記録するコンテンツのコンテンツ情報Ｃｄ（リスト、各コンテンツの再生回数）を取得する。コンテンツ情報Ｃｄは、端末３０−５０がコンテンツを再生するごとに値を記録したものである。

図４は、一例としての、端末から表示装置１０へ送信されるコンテンツ情報を示す図である。図４（ａ）は、端末３０から表示装置１０に送信されるコンテンツ情報を示す。また、図４（ｂ）は、端末４０から表示装置１０に送信されるコンテンツ情報を示す。そして、図４（ｃ）は、端末５０から表示装置１０に送信されるコンテンツ情報を示す。

図４（ａ）−（ｃ）に示すコンテンツ情報Ｃｄでは、送信元の端末を識別する情報である端末ＩＤ、コンテンツを識別する情報であるコンテンツＩＤ、コンテンツの属性を示す情報である属性情報、各コンテンツの再生回数が対応づけて記録されている。ここで、端末ＩＤ（Ａ〜Ｃ）は、コンテンツ情報Ｃｄを作成した端末３０−５０を識別する情報である。また、コンテンツＩＤ（Ｔｒ＿Ａ１〜Ａ５、Ｔｒ＿Ｂ１〜Ｂ５、Ｔｒ＿Ｃ１〜Ｃ５）は、コンテンツを固有に識別する情報である。そして、属性情報は、コンテンツの特徴をクラス分けするための情報であり、『コンテンツ名称』、『アーティスト』、『ジャンル』、『ビットレート』等、コンテンツをクラス分けできるものであればどのようなものであってもよい。図４に示すコンテンツ情報Ｃｄでは、属性情報としてアーティストＩＤ（Ａｒ）と、ジャンルＩＤ（Ｇｅ）とが記録されている。アーティストＩＤは、コンテンツの作曲者や演奏者等を示す情報であり、同じアーティストであれば同一のアーティストＩＤが付与される。また、ジャンルＩＤは、コンテンツのジャンル（ポップ、ロック、クラッシック、等）を示す情報であり、同じジャンルであれば同一のジャンルＩＤが付与される。以下では、同一の属性情報に属するものをオブジェクトとも記載する。そして、再生回数は、端末３０−５０があるコンテンツを再生するごとに、カウントした値である。

優先度算出部１１２は、コンテンツ情報取得部１１１により取得されたコンテンツの再生回数をもとに、各コンテンツの優先度を算出する。優先度は、表示装置１０が、コンテンツを再生する順序を決定するために用いる値である。すなわち、優先度が高いコンテンツの再生順序は早くなる。また、この第１の実施形態では、優先度算出部１１２は、コンテンツに関連づけられた属性情報に注目し、この属性情報ごとに再生回数Ｎを集計し、優先度を決定する。そのため、ある属性情報に注目した場合に、再生回数Ｎが多いオブジェクトを備えるコンテンツは優先度は高くなり、再生回数Ｎが少ないオブジェクトを備えるコンテンツは優先度が低くなる。

図５は、コンテンツの再生回数と、優先度との関係を説明する図である。図５（ａ）では、属性情報として『アーティスト』に注目した場合に、『アーティスト』に含まれる各オブジェクトの数を横軸に示し、再生回数Ｎを縦軸に示している。なお、図５に示す、再生回数Ｎは、端末３０−５０における全ての再生回数を母集合としたものである。図５（ａ）に示すように、コンテンツにおける属性情報『アーティスト』に注目した再生回数Ｎの集計は、『Ａｒ１』、『Ａｒ４』、『Ａｒ２』、『Ａｒ３』の順で低くなっている。そのため、優先度算出部１１２は、『Ａｒ１』に関連づけられたコンテンツの優先度を最も高くする。また、『Ａｒ４』、『Ａｒ２』、『Ａｒ３』の順序で、優先度を低くする。
無論、優先度を算出するために注目する属性情報は１つに限られず、複数の属性をもとに、優先度を算出するものであってもよい。

再生順序決定部１１３は、優先度算出部１１２によって算出された優先度に応じて、各コンテンツの再生順序を決定する。図５（ｂ）は、優先度と、再生順序との関係を示す図である。図５（ｂ）では、図５（ａ）で示した優先度に応じて決定された各コンテンツの再生順序（１〜４）を示している。図５（ｂ）の例では、オブジェクト『Ａｒ１』を含むコンテンツの再生順序が他のオブジェクト（Ａｒ２、Ａｒ３、Ａｒ４）を含むコンテンツと比べて最も早くなる。また、オブジェクト『Ａｒ３』を含むコンテンツの再生順序が他のオブジェクト（Ａｒ１、Ａｒ２、Ａｒ４）を含むコンテンツと比べて最も遅くなる。この第１の実施形態では、再生順序決定部１１３は、再生順序を決定したプレイリストＰｌを作成し、フラッシュメモリ１４に記録する。すなわち、優先度が高いコンテンツの再生順序を先にし、優先度が低いコンテンツの再生順序を後にする。

コンテンツ要求部１１４は、再生順序決定部１１３により決定された再生順序（プレイリストＰｌ）に従って、各コンテンツを通信ＩＦ１５を通じて要求する。
そして、再生制御部１１５は、コンテンツ要求部１１４による要求に応じてストリーミングされたコンテンツを音声出力部（再生部）１７に再生させる。

次に、端末３０−５０の構成について説明する。
図６は、端末３０の構成を示すブロック構成図である。なお、端末４０、５０の構成は、端末３０と同様であるため、その説明は省略する。
この第１の実施形態では、端末３０は、スマートフォンや、小型ＰＣにより実現される。無論、端末３０−５０は、コンテンツをストリーミングできる装置であればどの様な装置であってもよい。

端末３０は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、フラッシュメモリ３４、通信ＩＦ３５、タッチパネルモジュール３６、音声再生部３７、バス３８を備える。端末３０の各部は、バス３８を通じて互いに接続されている。

ＣＰＵ３１は、ＲＯＭ３２に記録されたプログラムに従って、各ハードウェアの駆動を統合的に制御する。

ＲＯＭ３２には、ＣＰＵ３１が、ハードウェアの駆動を制御するためのＯＳ３２１や、音声再生部３７のコンテンツの再生に合わせて、図４に示したコンテンツ情報Ｃｄを記録するためのアプリケーションプログラム３２２が記録されている。ＣＰＵ３１は、ＯＳ３２１や、アプリケーションプログラム３２２をＲＡＭ３３に展開して実行することで、コンテンツ情報Ｃｄの記録や、表示装置１０からの要求に従った動作を行うことができる。

フラッシュメモリ３４には、コンテンツファイル（コンテンツ）が記録されている。また、フラッシュメモリには、ＣＰＵ３１が作成したコンテンツ情報Ｃｄ（図４）が記録されている。なお、この第１の実施形態では、音楽コンテンツを例に説明を行う。無論、本発明は、音楽コンテンツ以外にも適用できる。

（２）コンテンツ情報Ｃｄの記録方法
次に、端末３０−５０により行われるコンテンツ情報Ｃｄの記録方法について説明する。図７は、端末３０がコンテンツ情報Ｃｄを記録す方法を説明するフローチャートである。図７に示すフローチャートは、ユーザが端末３０を操作して、あるコンテンツを再生した場合に実行され、図４に示すコンテンツ情報Ｃｄが記録される。なお、端末４０、５０においても、図７に示す同様の手法によりコンテンツ情報Ｃｄが記録されるため、説明は省略する。

ステップＳＢ１では、ＣＰＵ３１は、コンテンツ情報Ｃｄを参照し、今から再生するコンテンツがコンテンツ情報Ｃｄに記録されているか否かを判断する。例えば、ＣＰＵ３１は、コンテンツファイルのヘッダに付与されているコンテンツＩＤや、属性情報（アーティストＩＤ、ジャンルＩＤ）から、コンテンツの種別を判断する。

今から再生するコンテンツがコンテンツ情報Ｃｄに記録されていなければ（ステップＳＢ２：ＹＥＳ）、ステップＳＢ３において、ＣＰＵ３１は、コンテンツファイルに含まれる情報（属性情報等）を取得する。この第１の実施形態では、属性情報は、『アーティスト』、『ジャンル』であるため、ＣＰＵ３１は、コンテンツファイルから『アーティスト』、『ジャンル』のそれぞれの属性情報を取得する。そして、ステップＳＢ４では、ＣＰＵ３１は、コンテンツ情報Ｃｄにコンテンツの各情報（コンテンツＩＤ、属性情報等）を記録する。

ステップＳＢ５では、ＣＰＵ３１は、コンテンツ情報Ｃｄの該当コンテンツの再生回数に１をプラスする。なお、再生回数に１をプラスするタイミングは、コンテンツの再生が終了したタイミングでもよい。

一方、今から再生するコンテンツがコンテンツ情報Ｃｄに記録されていれば（ステップＳＢ２：ＮＯ）、ＣＰＵ１１は、ステップＳＢ５に進む。すなわち、再生するコンテンツの情報は、コンテンツ情報Ｃｄに記録されているため、ＣＰＵ３１は、属性情報等の記録は行わず、コンテンツ情報Ｃｄの該当コンテンツの再生回数に１をプラスする。

以上、端末３０により実行されるコンテンツ情報Ｃｄの記録を説明した。

（３）コンテンツ再生方法
次に、再生システム１００におけるコンテンツの再生方法を説明する。図８は、コンテンツの再生方法を示すフローチャートである。例えば、図８に示すフローチャートは、ユーザが端末３０−５０を操作して、表示装置１０にコンテンツの再生を実行させる場合に行われる。

ステップＳＡ１では、ＣＰＵ１１は、接続対象となる端末との間で無線ＬＡＮを設定するためのペアリングを行う。なわち、このステップＳＡ１では、ＣＰＵ１１は、無線ＬＡＮを通じて端末３０−５０との間で行なわれる通信時のＳＳＩＤの設定や、セキュリティーの設定等が行われる。すなわち、本発明では、表示装置１０が端末３０−５０に対する親機として機能する。

ステップＳＡ２では、ＣＰＵ１１（コンテンツ情報取得部１１１）は、通信ＩＦ１５を通じて、各端末３０−５０からコンテンツ情報Ｃｄの送信を要求する。端末３０−５０では、コンテンツ情報Ｃｄの送信要求を受けると、ステップＳＢ１１において、ＣＰＵ３１は、フラッシュメモリ３４に記録されたコンテンツ情報Ｃｄを送信する。

ステップＳＡ３では、ＣＰＵ１１は、端末３０−５０から送信されたコンテンツ情報Ｃｄ（図４）を受信する。そのため、ＣＰＵ１１は、端末３０−５０ごとのコンテンツ情報Ｃｄ（図４）をフラッシュメモリ１４に記録する。

ステップＳＡ４では、ＣＰＵ１１（優先度算出部１１２）は、取得したコンテンツ情報Ｃｄに含まれる再生回数Ｎをもとにコンテンツごとの優先度を算出するための優先度算出処理を行なう。すなわち、ＣＰＵ１１は、ステップＳＡ３で取得したコンテンツ情報Ｃｄから、所定の属性情報に注目して再生回数Ｎを集計し、表示装置１０で再生させる個々のコンテンツの優先度を算出する。優先度の詳細な算出方法については、（４）優先度算出方法で説明する。

ステップＳＡ５では、ＣＰＵ１１（再生順序決定部１１３）は、ステップＳＡ４で算出されたコンテンツごとの優先度に応じてコンテンツの再生順序を示すプレイリストＰｌを作成する。図９は、一例としてのプレイリストＰｌを示す図である。プレイリストＰｌには、表示装置１０が端末３０−５０からストリーミングされるコンテンツの再生順序（１〜１５）が記録されている。また、プレイリストＰｌには、コンテンツＩＤ、端末ＩＤ、関連情報が関連づけて記録されている。

ステップＳＡ６では、ＣＰＵ１１（コンテンツ要求部１１４）は、ステップＳＡ５で作成したプレイリストＰｌに従って、コンテンツファイルのストリーミングを各端末３０−５０に要求する。一例として、ＣＰＵ１１は、通信ＩＦ１５を通じて、プレイリストＰｌの再生順序ＰＯｄの先頭から順に、コンテンツのストリーミング要求をブロードキャストする。このストリーミング要求では、プレイリストＰｌの該当再生順序ＰＯｄに対応づけられた端末ＩＤを送り先とし、該当再生順序ＰＯｄに対応づけられたコンテンツＩＤを対象とする。そのため、ステップＳＢ１２において、ストリーミング要求を受信した端末３０−５０の内、端末ＩＤに該当する端末は、コンテンツＩＤに対応するコンテンツファイルを表示装置１０に対してストリーミングする。

ステップＳＡ７では、ＣＰＵ１１（再生制御部１１５）は、ステップＳＡ６の要求により端末からストリーミングされたコンテンツファイルを再生する。ここで、コンテンツファイルの解凍等は端末３０−５０により事前に行われており、表示装置１０は、ストリーミングされたコンテンツファイルを再生するだけでよい。なお、表示装置１０と端末３０−５０との間で、コンテンツの暗号化が取り決められている場合は、コンテンツを復号する必要がある。

再生順序がプレイリストＰｌの終端まで達していなければ（ステップＳＡ８：ＮＯ）、ＣＰＵ１１は、ステップＳＡ６に戻り、ステップＳＡ６、ＳＡ７の処理を繰返す。
再生順序がプレイリストＰｌの終端まで達していれば（ステップＳＡ８：ＹＥＳ）、ＣＰＵ１１は、端末３０−５０に対してコンテンツの要求を終了する。

（４）優先度算出方法
次に、図８のステップＳＡ４で示した優先度算出処理について説明する。
図１０は、ステップＳＡ４において実行される優先度の算出方法を説明するフローチャートである。図１０に示す優先度算出方法は、『アーティスト』、『ジャンル』の２つの属性情報（第１の属性情報、第２の属性情報）に注目して優先度を算出している。また、図１１、図１２は、コンテンツ情報Ｃｄからコンテンツごとの優先度βが算出される手法を説明する図である。

以下では、注目する変数に応じて集計された値に添え字『ｉ』『ｊ』『ｋ』『ｌ』を付して説明を行う。すなわち、コンテンツ情報Ｃｄに記録される再生回数Ｎは、端末ＩＤ、コンテンツＩＤ、属性情報のそれぞれが関連づけられており、各情報に注目して、集計を行うことができる。そのため、ある値を端末ＩＤ（変数）に注目して集計した場合、この値に添え字『ｉ』を付して示す。また、ある値を、コンテンツＩＤ（変数）に注目して集計した場合、この値に添え字『ｊ』を付して示す。そして、ある値を属性情報（変数）に注目して集計した場合、添え字『ｋ』または『ｌ』を付して示す。また、注目する変数は、２つ以上を組み合わせて用いる場合もあり、この場合、値には２つ以上の添え字を付して示される。

ステップＳＡ４１では、ＣＰＵ１１は、端末３０−５０の内のいずれかを示す端末ＩＤに属するコンテンツ情報ＣｄからアーティストＩＤが共通の再生回数（個別アーティスト再生回数ＩＡｒＮ（ｉ、ｋ））を集計する。
図１１（ａ）は、ステップＳＡ４１において集計される個別アーティスト再生回数ＩＡｒＮ（ｉ、ｋ）を示す図である。図１１（ａ）では、縦方向に並ぶアーティストＩＤ（Ａｒ１〜Ａｒ４）と、横方向に並ぶ端末ＩＤ（Ａ〜Ｃ）と、を変数とし、各配列要素をアーティスト再生回数ＡｒＮとして示している。図１１（ａ）では、端末ＩＤ（ｉ＝Ａ〜Ｃ）のそれぞれのコンテンツ情報Ｃｄから、アーティストＩＤの各オブジェクト『Ａｒ１』、『Ａｒ２』、『Ａｒ３』、『Ａｒ４』の個別アーティスト再生回数ＩＡｒＮ（ｉ、ｋ）が集計されている。

ステップＳＡ４２では、ＣＰＵ１１は、ある端末ＩＤに属するコンテンツ情報ＣｄからジャンルＩＤが共通の再生回数（個別ジャンル再生回数ＩＧｅＮ（ｉ、ｌ））を集計する。
図１１（ｂ）は、ステップＳＡ４２において集計される個別ジャンル再生回数ＧｅＮ（ｉ、ｌ）を示す図である。図１１（ｂ）では、縦方向に並ぶジャンルＩＤ（Ｇｅ１〜Ｇｅ３）と、横方向に並ぶ端末ＩＤ（Ａ〜Ｃ）と、を変数とし、各配列要素を個別ジャンル再生回数ＩＧｅＮ（ｉ、ｌ）として示している。図１１（ｂ）では、端末ＩＤ（ｉ＝Ａ〜Ｃ）のそれぞれのコンテンツ情報Ｃｄから、ジャンルＩＤの各オブジェクト『Ｇｅ１』、『Ｇｅ２』、『Ｇｅ３』の個別ジャンル再生回数ＩＧｅＮ（ｉ、ｌ）が集計されている。

ステップＳＡ４３では、ＣＰＵ１１は、ある端末ＩＤに属するコンテンツ情報Ｃｄの再生回数Ｎの総数（個別再生総数ＩＴＮ（ｉ））を集計する。

ステップＳＡ４４では、ＣＰＵ１１は、下記（式１）をもとに、ステップＳＡ４１で集計した個別アーティスト再生回数ＩＡｒＮ（ｉ、ｋ）をステップＳＡ４３で取得した個別再生総数ＩＴＮ（ｉ）で割った、ある端末ＩＤにおける個別アーティスト優先度ＩＡｒＰ（ｉ、ｋ）を算出する。

図１１（ｃ）では、縦方向に並ぶアーティストＩＤ（Ａｒ１〜Ａｒ４）と、横方向に並ぶコンテンツＩＤ（Ａ〜Ｃ）と、を変数とし、各配列要素を個別アーティスト優先度ＡｒＰとして示している。すなわち、アーティストＩＤの各オブジェクト『Ａｒ１』、『Ａｒ２』、『Ａｒ３』、『Ａｒ４』の個別アーティスト優先度ＡｒＰが算出されている。

ステップＳＡ４５では、ＣＰＵ１１は、下記（式２）をもとに、ステップＳＡ４２で集計した個別ジャンル再生回数ＩＧｅＮ（ｉ、ｌ）をステップＳＡ４３で取得した個別再生総数ＩＴＮ（ｉ）で割って、ある端末ＩＤにおける個別ジャンル優先度ＩＧｅＰ（ｉ、ｌ）を算出する。

図１１（ｄ）は、ステップＳＡ４５において集計される個別ジャンル優先ＧｅＰ（ｉ、ｌ）を示す図である。図１１（ｄ）では、縦方向に並ぶジャンルＩＤ（ｌ＝Ｇｅ１〜Ｇｅ３）と、横方向に並ぶ端末ＩＤ（ｉ＝Ａ〜Ｃ）と、を変数とし、各配列要素を個別ジャンル優先度ＧｅＰとして示している。すなわち、ジャンルＩＤの各オブジェクト『Ｇｅ１』、『Ｇｅ２』、『Ｇｅ３』のジャンル優先度ＧｅＰが算出されている。

全ての端末ＩＤで個別アーティスト優先度ＩＡｒＰ、個別ジャンル優先度ＩＡｒｐを算出していなければ（ステップＳＡ４６：ＮＯ）、ステップＳＡ４７では、ＣＰＵ１１は、対象とする端末ＩＤを変化させる。そして、ＣＰＵ１１は、ステップＳＡ４１〜ＳＡ４５の処理を繰返す。
一方、全ての端末ＩＤで個別アーティスト優先度ＩＡｒＰ、個別ジャンル優先度ＩＧｅＰを算出していれば（ステップＳＡ４６：ＹＥＳ）、ＣＰＵ１１は、ステップＳＡ４８に進む。

ステップＳＡ４８では、ＣＰＵ１１は、下記（式３）をもとに、アーティストＩＤが共通する個別アーティスト優先度ＩＡｒＰの平均値（アーティスト優先度ＡｒＰ（ｋ））を算出する。

図１２（ａ）は、ステップＳＡ４８において算出されるアーティスト優先度ＡｒＰ（ｋ）を示すグラフである。図１２（ａ）では、縦方向に並ぶアーティストＩＤごとのアーティスト優先度ＡｒＰ（ｋ）が算出されている。

ステップＳＡ４９では、ＣＰＵ１１は、下記（式４）をもとに、ジャンルＩＤが共通する個別ジャンル優先度ＩＧｅＰの平均値（ジャンル優先度ＧｅＰ（ｌ））を算出する。

図１２（ｂ）は、ステップＳＡ４９において算出されるジャンル優先度ＧｅＰ（ｌ）を示すグラフである。図１２（ｂ）では、縦方向に並ぶジャンルＩＤごとのジャンル優先度ＧｅＰが算出されている。

ステップＳＡ５０では、ＣＰＵ１１は、下記（式５）をもとに、コンテンツ毎に、関係を有するアーティスト優先度ＡｒＰ（ｋ）とジャンル優先度ＧｅＰ（ｌ）とをかけ合わせて優先度βを算出する。

図１２（ｃ）は、端末ごとのコンテンツ情報Ｃｄに付与された優先度βを示す図である。図１２（ｃ）では、図中、点線で囲む優先度βが高い値となっている。そのため、図８のステップＳＡ５において、ＣＰＵ１１は、優先度βの高いコンテンツの再生順序を早くする。

以上説明したように、この第１の実施形態に示す再生装置では、以下の効果を奏する。 端末ごとのコンテンツの再生回数をもとに、各コンテンツの優先度を算出し、この優先度に応じて各コンテンツの再生順序を決定する。このように決定された再生順序に応じて、各端末に再生順序に対応したコンテンツを通信部を通じて要求する。そのため、再生装置が複数の端末からコンテンツのストリーミングを受ける場合に、コンテンツ再生順序を各ユーザの嗜好に合わせて決定し、決定された再生順序に応じて各端末にコンテンツファイルを送信させることができる。すなわち、ユーザは、端末に対して煩雑な操作を行う必要がなくなる。

また、ある属性情報に注目してコンテンツの再生順序を決定することができ、ユーザの嗜好を再生順序に、効果的に反映させることができる。
さらに、複数の属性情報を組み合わせることで、ユーザの嗜好を再生順序により効果的に反映させることができる。

２．第２の実施形態：
再生順序を決定するための優先度の算出方法として、特定の端末において、再生回数が高いコンテンツの優先度を高くするものであってもよい。

図１３は、第２の実施形態において、ステップＳＡ４において実行される優先度の算出方法を説明するフローチャートである。この第２の実施形態においても、図１３に示す優先度算出方法は、『アーティスト』『ジャンル』の２つの属性情報に注目して優先度を算出している。
なお、同一の名称、符号を付したものは、第１の実施形態と同じものを示し、その説明は繰返さない。

図１３のステップＳＡ１４１では、ＣＰＵ１１は、ある端末ＩＤに属するコンテンツ情報ＣｄからアーティストＩＤが共通の再生回数（個別アーティスト再生回数ＩＡｒＮ（ｉ、ｋ））を集計する。
次に、ステップＳＡ１４２では、ＣＰＵ１１は、ある端末ＩＤに属するコンテンツ情報ＣｄからジャンルＩＤが共通の再生回数（個別ジャンル再生回数ＩＧｅＮ（ｉ、ｌ））を集計する。
次に、ステップＳＡ１４３では、ＣＰＵ１１は、ある端末ＩＤに属するコンテンツ情報Ｃｄの再生回数Ｎの総数（個別再生総数ＩＴＮ（ｉ））を集計する。

ステップＳＡ１４４では、ＣＰＵ１１は、上記（式１）をもとに、ステップＳＡ１４１で集計した個別アーティスト再生回数ＩＡｒＮをステップＳＡ１４３で取得した個別再生総数ＩＴＮで割った値である個別アーティスト優先度ＩＡｒＰ（ｉ、ｋ）を算出する。

ステップＳＡ１４５では、ＣＰＵ１１は、上記（式２）をもとに、ステップＳＡ１４２で集計した個別ジャンル再生回数ＩＧｅＮをステップＳＡ１４３で取得した個別再生総数ＩＴＮで割った値である個別ジャンル優先度ＩＧｅＰ（ｉ、ｌ）を算出する。

ステップＳＡ１４６では、ＣＰＵ１１は、下記（式６）をもとに、コンテンツごとの再生回数Ｎ（ｉ、ｊ）を、ステップＳＡ１４３で取得した個別再生総数ＩＴＮ（ｉ）で割った値である再生比率γを算出する。

全ての端末ＩＤで個別アーティスト優先度ＡｒＰ、個別ジャンル優先度Ａｒｐ、再生比率γを算出していなければ（ステップＳＡ１４７：ＮＯ）、ステップＳＡ１４８では、ＣＰＵ１１は、対象とする端末ＩＤを変化させる。そして、ＣＰＵ１１は、ステップＳＡ１４１〜ＳＡ４６の処理を繰返す。
一方、全ての端末ＩＤで個別アーティスト優先度ＡｒＰ、個別ジャンル優先度ＧｅＰ、再生比率γを算出していれば（ステップＳＡ１４７：ＹＥＳ）、ＣＰＵ１１は、ステップＳＡ１４９に進む。

ステップＳＡ１４９では、ＣＰＵ１１は、上記（式３）をもとに、アーティストＩＤが共通する個別アーティスト優先度ＩＡｒＰの平均値（アーティスト優先度ＡｒＰ（ｋ））を算出する。
次に、ステップＳＡ１５０では、ＣＰＵ１１は、上記（式４）をもとに、ジャンルＩＤが共通する個別ジャンル優先度ＩＧｅＰの平均値（ジャンル優先度ＧｅＰ（ｌ））を算出する。

次に、ステップＳＡ１５１では、ＣＰＵ１１は、下記（式７）をもとに、コンテンツ毎の優先度δを算出する。

図１４は、第２の実施形態での優先度δを説明する図である。図１４（ａ）は、端末３０（端末ＩＤ＝Ａ）において、ある属性情報に注目した場合の再生回数Ｎの集計を示す。また、図１４は、端末４０（端末ＩＤ＝Ｂ）において、ある属性情報に注目した場合の再生回数Ｎの集計を示す。そして、図１４（ｃ）は、端末５０（端末ＩＤ＝Ｃ）において、ある属性情報に注目した場合の再生回数Ｎの集計を示す。

この第２の実施形態では、コンテンツ毎の再生比率γに、アーティスト優先度ＡｒＰ、ジャンル優先度ＧｅＰの逆数をかけたものを優先度δとしている。これを図１４を用いて説明する。
図１４（ａ）に示すように、端末３０では、アーティストＩＤ（Ａｒ１）の再生回数Ｎの集計が他のアーティストＩＤ（Ａｒ２〜Ａｒ４）と比べて多く、再生比率γが高くなっている。しかし、端末３０−５０において、再生回数Ｎの集計で比較すると、端末３０のアーティストＩＤ（Ａｒ１）の集計数は高くない。
そこで、アーティスト優先度ＡｒＰおよびジャンル優先度ＧｅＰの逆数を加えることで、図１４（ａ）に示したように、集計数が低く優先度（アーティスト優先度ＡｒＰ、ジャンル優先度ＧｅＰ）が低くなるが、再生比率γが高い属性情報を備えるコンテンツの優先度δを高くすることができる。すなわち、平均的には各端末で再生される割合が低いアーティストやジャンルであるが、特定の端末においては再生される割合が高いコンテンツの優先度を高くすることが可能となる。無論、これに限定されず、再生比率γをそのまま優先度δとして用いるものであってもよい。

以下、図８のステップＳＡ５において、ＣＰＵ１１は、算出された優先度δに応じて、コンテンツの再生順序を設定したプレイリストＰｌを作成する。

以上説明したように、この第２の実施形態に示す再生装置では、第１の実施形態が示す効果に加えて以下の効果を奏する。
ある端末において再生回数が高いコンテンツの優先度を高くすることができるため、端末間の平均では再生回数が高くないコンテンツであっても、優先度を高くすることができ、再生順序の決定をより柔軟に行うことが可能となる。

３．第３の実施形態：
プレイリストＰｌに同じコンテンツが存在する場合に、いずれかのコンテンツのみを再生するものであってもよい。

図１５は、第３の実施形態において、図８のステップＳ５において実行される処理を示すフローチャートである。図１５に示すフローチャートでは、重複するコンテンツが存在する場合に、ビットレートが高いものを再生順序に加える。ビットレートが高いものは、再生品質が高くなるため、より品質が高いコンテンツを再生対象に選択することができる。無論、コンテンツを選別する条件は、ビットレートに限定されない。

ステップＳＡ５１では、ＣＰＵ１１は、優先度に応じてプレイリストＰｌの元となる結合されたコンテンツ情報のコンテンツＩＤを並び替える。

重複するコンテンツが存在する場合（ステップＳＡ５２：ＹＥＳ）、ＣＰＵ１１は、ステップＳＡ５３に進む。ここで、コンテンツの重複を判断する方法としては、例えば、コンテンツの属性情報である、『曲名』および『アーティスト』が一致する場合である。

ステップＳ５３では、ＣＰＵ１１は、重複するコンテンツにおけるビットレートを比較する。例えば、ビットレートは、コンテンツ情報の属性情報として記録されている。

ステップＳ５４では、ＣＰＵ１１は、重複するコンテンツの内、ビットレートが低いコンテンツに係る情報（コンテンツＩＤ、属性情報）を結合したコンテンツ情報から削除する。

ステップＳ５５では、ＣＰＵ１１は、更新後のリストをプレイリストＰｌとしてフラッシュメモリ１４に記録する。

一方、重複するコンテンツが存在しない場合（ステップＳ５２：ＮＯ）、ＣＰＵ１１は、ステップＳＡ５５に進み、更新後のリストをプレイリストＰｌとしてフラッシュメモリ１４に記録する。以下、ステップＳＡ５５において記録されたプレイリストＰｌをもとに、ＣＰＵ１１は、端末３０−５０に対してコンテンツを要求する。

以上説明したように、この第３の実施形態では、第１の実施形態の効果に加えて、以下の効果を奏する。
重複するコンテンツの再生を抑制することができる。

４．その他の実施形態：
再生装置が再生情報を決定するコンテンツに、自機が記録するコンテンツを加えるものであってもよい。即ち、再生装置も端末３０−５０と同様、図７に示すフローチャートに従って、自機が記録するコンテンツのコンテンツ情報Ｃｄを記録する。そして、再生装置が図８のフローチャートに従って、端末３０−５０からコンテンツ情報Ｃｄを取得する場合に、自機が記録するコンテンツを含めて、再生順序を決定するものであってもよい。

再生装置として車載型の表示装置を例に説明を行ったのは一例に過ぎない。例えば、再生装置は、据え置き型のプレイヤーや、端末であってもよい。

コンテンツとして、音楽コンテンツを用いて説明を行ったことは一例に過ぎない。例えば、動画コンテンツであってもよい。

なお、本発明は上記実施例に限られるものでないことは言うまでもない。当業者であれば言うまでもないことであるが、
・上記実施例の中で開示した相互に置換可能な部材および構成等を適宜その組み合わせを変更して適用すること
・上記実施例の中で開示されていないが、公知技術であって上記実施例の中で開示した部材および構成等と相互に置換可能な部材および構成等を適宜置換し、またその組み合わせを変更して適用すること
・上記実施例の中で開示されていないが、公知技術等に基づいて当業者が上記実施例の中で開示した部材および構成等の代用として想定し得る部材および構成等と適宜置換し、またその組み合わせを変更して適用すること
は本発明の一実施例として開示されるものである。

１０…表示装置、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…フラッシュメモリ、１６…タッチパネルモジュール、１７…音声出力部、１８…バス、３０…端末、３１…ＣＰＵ、３２…ＲＯＭ、３３…ＲＡＭ、３４…フラッシュメモリ、３５…通信ＩＦ、３６…タッチパネルモジュール、３７…音声再生部、３８…バス、４０…端末、５０…端末、１００…再生システム、１１１…コンテンツ情報取得部、１１２…優先度算出部、１１３…再生順序決定部、１１４…コンテンツ要求部、１１５…再生制御部、１２１…ＯＳ、１２２…プログラムモジュール、３２１…ＯＳ、３２２…アプリケーションプログラム

Claims (8)

1. 通信部と、
   再生部と、
   前記通信部を通じて接続された各端末が記録するコンテンツのリストと、端末ごとのコンテンツの再生回数とを含むコンテンツ情報を取得するコンテンツ情報取得部と、
   取得した前記端末ごとのコンテンツの再生回数をもとに、各コンテンツの優先度を算出する優先度算出部と、
   算出された前記優先度に応じて、前記各コンテンツの再生順序を決定する再生順序決定部と、
   各端末に前記再生順序に対応したコンテンツを前記通信部を通じて要求するコンテンツ要求部と、
   前記要求に応じて取得されたコンテンツを前記再生部に再生させる再生制御部と、を有することを特徴とする再生装置。
2. 前記コンテンツ情報には、各コンテンツの属性情報が前記コンテンツのリストに対応づけて記録されており、
   前記優先度算出部は、前記属性情報ごとに前記再生回数を集計して、前記コンテンツの優先度を算出する、ことを特徴とする請求項１に記載の再生装置。
3. 前記属性情報は、第１の属性情報と、第２の属性情報と、を含み、
   前記優先度算出部は、前記第１の属性情報における優先度と、前記第２の属性情報における優先度と、の積にもとづいて前記コンテンツの優先度を算出する、ことを特徴とする請求項２に記載の再生装置。
4. 前記優先度算出部は、各端末における再生回数の割合が高いコンテンツの優先度を高くする、ことを特徴とする請求項１に記載の再生装置。
5. 前記再生順序決定部は、重複するコンテンツが存在する場合に、いずれかのコンテンツのみを再生順序に加える、ことを特徴とする請求項１から請求項４のいずれか一項に記載の再生装置。
6. 前記通信部は、ＬＡＮで前記端末と接続している、ことを特徴とする請求項１から請求項５のいずれか一項に記載の再生装置。
7. コンテンツを記録する端末と、前記端末と通信部を通して通信する再生装置と、を備える再生システムであって、
   前記再生装置は、
   再生部と、
   前記通信部を通じて接続された各端末が記録するコンテンツのリストと、端末ごとのコンテンツの再生回数を含むコンテンツ情報を取得するコンテンツ情報取得部と、
   取得した前記端末ごとのコンテンツの再生回数をもとに、各コンテンツの優先度を算出する優先度算出部と、
   算出された前記優先度に応じて、前記各コンテンツの再生順序を決定する再生順序決定部と、
   各端末に前記再生順序に対応したコンテンツを前記通信部を通じて要求するコンテンツ要求部と、
   前記要求に応じて取得されたコンテンツを前記再生部に再生させる再生制御部と、を有することを特徴とする再生システム。
8. 端末に対して、再生装置にコンテンツをストリーミングさせるアプリケーションプログラムであって、
   前記端末に、
   記録する前記コンテンツ毎に再生回数を記録する機能と、
   記録する前記コンテンツのリストと、前記コンテンツ毎の再生回数と、含むコンテンツ情報を前記再生装置に送信する機能と、
   前記再生装置から前記再生回数に応じて設定されたコンテンツの再生順序に応じたコンテンツの要求を受信した場合に、前記要求されたコンテンツを送信する機能と、を実現させるアプリケーションプログラム。

Images