(57)【特許請求の範囲】
【請求項１】
コンテンツを記憶するコンテンツキャッシュ部と、
クラウド上のコンテンツサーバに登録されているコンテンツの再生頻度を算出するための再生頻度情報を保持するコンテンツデータベースと、
前記コンテンツキャッシュ部を管理するコンテンツキャッシュ管理部と、
を備え、
前記コンテンツキャッシュ管理部は、
再生対象となるコンテンツの前記再生頻度情報に基づいて、前記コンテンツサーバ上のコンテンツをダウンロードしながらリアルタイムに再生するオンザフライ再生動作と、前記コンテンツサーバからダウンロードしたコンテンツデータを前記コンテンツキャッシュ部に書き込みながら同時に再生を行うダウンロード再生動作と、を切り替えることを特徴とする、コンテンツ再生装置。
【請求項２】
コンテンツを記憶するコンテンツキャッシュ部と、
クラウド上のコンテンツサーバに登録されているコンテンツの再生確率を予想するための再生確率予想情報を保持するコンテンツデータベースと、
前記コンテンツキャッシュ部を管理するコンテンツキャッシュ管理部と、
を備え、
前記コンテンツキャッシュ管理部は、
再生対象となるコンテンツの前記再生確率予想情報に基づいて、前記コンテンツサーバ上のコンテンツをダウンロードしながらリアルタイムに再生するオンザフライ再生動作と、前記コンテンツサーバからダウンロードしたコンテンツデータを前記コンテンツキャッシュ部に書き込みながら同時に再生を行うダウンロード再生動作と、を切り替えることを特徴とする、コンテンツ再生装置。
【請求項３】
前記コンテンツキャッシュ部においては、各コンテンツの先頭部分とそれ以外の残余部分とに分けて、データが記録されることを特徴とする、請求項１又は２に記載のコンテンツ再生装置。
【請求項４】
前記コンテンツキャッシュ部において、容量が満杯になってしまった場合に、前記各コンテンツの残余部分が先に削除されることを特徴とする、請求項３に記載のコンテンツ再生装置。
【請求項５】
前記コンテンツキャッシュ部において、
前記各コンテンツの先頭部分を保存する先頭部分キャッシュの容量と、前記各コンテンツの残余部分を保存する残余部分キャッシュの容量とが分けて管理され、
容量が満杯になってしまった場合に、前記先頭部分キャッシュと前記残余部分キャッシュとで独立して不要データの削除処理が実施されることを特徴とする、請求項３に記載のコンテンツ再生装置。
【請求項６】
前記コンテンツキャッシュ部は、
ユーザが直近で再生する可能性が高いコンテンツを保存する第１コンテンツキャッシュと、
ユーザが後日また再生する可能性が高いコンテンツを保存する第２コンテンツキャッシュと、
を有することを特徴とする、請求項１〜５のいずれかに記載コンテンツ再生装置。
【請求項７】
前記第１コンテンツキャッシュには、再生中のコンテンツに関連するコンテンツのみが保存されることを特徴とする、請求項６に記載のコンテンツ再生装置。
【請求項８】
前記第１コンテンツキャッシュは、揮発性メモリにより構成されることを特徴とする、請求項７に記載のコンテンツ再生装置。
【請求項９】
前記第１コンテンツキャッシュにおけるデータ管理単位は、１つのコンテンツをさらに細かく分けたチャンク単位であることを特徴とする、請求項７に記載のコンテンツ再生装置。
【請求項１０】
前記第２コンテンツキャッシュには、後日再生する可能性が高いコンテンツのみが保存され、
前記第２コンテンツキャッシュにおけるキャッシュ管理のアルゴリズムは、前記第１コンテンツキャッシュとは別のアルゴリズムが採用されることを特徴とする、請求項６〜９のいずれかに記載のコンテンツ再生装置。
【請求項１１】
前記第２コンテンツキャッシュは、データの保存先として、不揮発性メモリにより構成されることを特徴とする、請求項１０に記載のコンテンツ再生装置。
【請求項１２】
前記第２コンテンツキャッシュにおけるデータ管理単位は、コンテンツ単位であることを特徴とする、請求項１０又は１１に記載のコンテンツ再生装置。
【請求項１３】
前記第１コンテンツキャッシュと前記第２コンテンツキャッシュの容量は、個別に設定できることを特徴とする、請求項６〜１２のいずれかに記載のコンテンツ再生装置。
【請求項１４】
前記コンテンツデータベースは、複数のコンテンツサーバのコンテンツリスト情報を統合した統合コンテンツリスト情報を保持することを特徴とする、請求項１〜１３のいずれかに記載のコンテンツ再生装置。
【請求項１５】
コンピュータを、請求項１〜１４のいずれかに記載のコンテンツ再生装置として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを再生するコンテンツ再生装置及びコンピュータプログラムに関する。本明細書において再生の対象となるコンテンツの種類は、音楽に限定されず、電子書籍コンテンツ、動画像コンテンツ、静止画像コンテンツ等の種々の形態のコンテンツが対象となり得る。
【背景技術】
【０００２】
近年では、３ＧやＬＴＥ等のモバイル向け通信システムを利用することよって、いつでもどこでもインターネットとの通信を行うことが可能なスマートフォンと呼ばれるモバイル機器が普及しており、そのようなモバイル機器向けにクラウド上のコンテンツ・サーバから音楽データを逐次ダウンロードしながら再生するストリーミング再生機能を提供するクラウド型の音楽配信サービスが提供されている。またさらに近年では、定額制の音楽配信サービスも普及しつつある。定額制の音楽配信サービスでは、毎月一定額のサービス利用料を支払うことにより、視聴時間の制限なく、新譜や旧譜も含めて好きな楽曲をいくらでも視聴することができる。
【０００３】
このようなクラウド型の音楽配信サービスでは、これまでのように自分の聞きたい楽曲をモバイル機器内の内蔵メモリに保存しておく必要がないため、再生可能な曲数に制限が無く、内蔵メモリが楽曲データの保存のために消費されることがないため、限りある内蔵メモリにより多くの他のアプリケーションプログラムをインストールすることができるようになるというメリットがある。このように、内蔵メモリの容量に制限があり、またパソコンのように後からメモリ容量を追加することが困難なモバイル機器において、クラウド型の音楽配信サービスはとても相性がよい。
【０００４】
しかしながら、このクラウド型の音楽配信サービスには重大な欠点もある。それは楽曲の再生時に音楽データを逐次クラウド上のサーバからダウンロードする必要があるため、３ＧやＬＴＥの基地局がモバイル機器の近傍に無く、モバイル機器に圏外表示されるような場所においては、音楽を再生することができなくなってしまうことである。最近では自社では移動体向けの回線網を持たずに、他の回線網を持つ移動体通信事業者(Mobile Network Operator、以降ＭＮＯ)から回線網を借りて、自社ブランドで通信サービスを行うＭＶＮＯ（Mobile Virtual Network Operator）とも呼ばれる事業者が、毎月利用可能なモバイル通信のデータ量に上限がある代わりに、通信サービス利用料がＭＮＯよりも低廉なサービス利用料でモバイル通信を利用することが可能な通信サービスの提供を始めている。毎月の通信料を節約することが可能なこのような通信サービスは、格安ＳＩＭと呼ばれている。
【０００５】
このような格安ＳＩＭは、毎月利用可能なモバイル通信データ量の上限があるために、クラウド型の音楽配信サービスとは相性があまりよくない。なぜならば、例えば月の途中でその一ヶ月間に利用可能なモバイル通信データ量の上限に達してしまうと、その時点から月末までの間は音楽を聞くことができなくなってしまうからである。そこでこのような不便さに対応するために、モバイル機器がインターネットとの通信ができないオフラインの状態にあっても、何らかの方法により音楽を再生することができるようなオフライン再生機能に対するニーズが高まっている。
【０００６】
そのための具体的な対応策としては、ユーザが選択した特定の楽曲の音楽データのみを携帯機器の内蔵メモリにダウンロードして保存しておくことにより、モバイル機器がオフラインの状態であっても、内蔵メモリに保存しておいた楽曲を再生可能とする技術が考えられ、既に知られている（例えば、特許文献１参照。）。
あるいは別の対応策としては、再生した音楽データを携帯機器の内蔵メモリにコピーしておく、いわゆるキャッシングの機構を設けることにより、インターネットとの通信が行えない状況においてもキャッシュメモリ内に保存されている楽曲については、オフラインで再生することを可能とするコンテンツキャッシュ技術もごく一般的に利用されている。このコンテンツキャッシュ方式で問題になるのは、キャッシュメモリとして利用可能なメモリ容量には限りがあるため、再生した音楽データをどんどんキャッシュメモリに追記していくと、いつかはキャッシュメモリが満杯になってしまい、それ以上音楽データを書き込むことができなくなってしまうことである。このような事態が発生した場合に、どの楽曲をキャッシュメモリに残して、どの楽曲をキャッシュメモリから捨てるべきかを判断するキャッシュ管理アルゴリズムとして、最も過去に利用されたデータを捨てていくLeast Recently Used（以降、LRUと表記）方式や、利用頻度が最も低いデータを捨てるLeast Frequently Used（以降、LFU）方式等が考えられ、キャッシュメモリの管理方式として広く利用されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１３−７７０７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、従来の楽曲データをダウンロードする機能を備えたクラウド型音楽再生アプリにおいては、ユーザが手動操作で指定した楽曲の音楽データをモバイル機器側の内蔵メモリにダウンロードして、保存しているのにすぎなかった。例えば、ユーザがお気に入りのアーティストが新譜のアルバムを発売したとする。ユーザが「今後はこのアルバムをよく聞くので、スマートフォンに基地局からの電波が届かない場所に行ったときでも、この新譜は再生できるようにしておきたい」、あるいは「格安ＳＩＭのデータ通信量を節約したいので、今後よく聞きそうなこの新譜の音楽データをダウンロードしておこう」と考えた場合には、ユーザはそのアルバムに含まれる楽曲をダウンロードするための操作を手動で行う必要がある。
【０００９】
さらなる問題として、ユーザがこのような楽曲データのダウンロードばかりを行い続けることはできないという事情も発生する。なぜならばモバイル機器の内蔵メモリの容量には上限があるため、いつかはメモリ容量の上限に達してしまい、それ以上楽曲をダウンロードすることができなくなってしまうからである。もしそのようなメモリ満杯の状態になってしまった場合には、ユーザは今後あまり聞きそうもない楽曲を選び、それらの楽曲データを削除するための操作を手動で行う必要がある。
【００１０】
すなわち従来の楽曲データをダウンロードする機能を備えたクラウド型音楽再生アプリでは、モバイル端末にダウンロードした楽曲データの管理をユーザが手動で行う必要があった。音楽を聞くという直接の目的とは関係のない事柄にユーザが関心を払う必要があり、場合によってはユーザが手動で操作して新しい楽曲をダウンロードしたり、あるいは古い楽曲データを削除する必要があるために、アプリの使い勝手が悪いという問題があった。
【００１１】
そこで本発明は、このような問題に鑑みてなされたものであり、その目的とするところは、クラウド型音楽再生アプリにおいて、ダウンロードした楽曲データの管理を自動化することにより、ユーザが音楽を再生したい楽曲を選択する以外の余計な仕事から解放して、クラウド型音楽再生アプリの使い勝手を高めることの可能な、新規かつ改良されたコンテンツ再生装置及びコンピュータプログラムを提供することにある。
【００１２】
また楽曲データのキャッシング機能を備えたクラウド型音楽再生アプリにおいては、キャッシュデータの管理は確かに自動化されており、ユーザが手動で楽曲データをダウンロードしたり、あるいは古い楽曲を削除する必要は無い。しかし従来から利用されているLRU方式やLFU方式等のキャッシュ管理アルゴリズムには致命的な欠点がある。それは各楽曲データの利用履歴情報（LRU 方式ではアクセス日時、LFU方式ではアクセス頻度）を維持管理する対象が、キャッシュメモリ内に存在している楽曲データのみに限定されることである。そのためにユーザがある時にたまたま気が向いて、キャッシュメモリ上には楽曲データのコピーが存在していない古い楽曲を久しぶりに再生したような場合に、おそらくはユーザがその同じ楽曲を近日中に繰り返し再生する可能性が低いにもかかわらず、そのような古い楽曲データをキャッシュしてしまう。これはLRU方式においては、ユーザが再生した楽曲はその時点では最も直近に利用したデータであることから、常に再優先でキャッシュメモリに残すべきデータであると判断されるからである。つまりLRU方式はデータへのアクセス頻度を全く考慮していないという欠点がある。
【００１３】
一方、LFU方式はデータのアクセス頻度を考慮しているという点では、一見、本発明と類似している。しかしLFU方式においては、キャッシュ対象のデータに関する利用履歴情報を維持管理する対象がキャッシュメモリ上に存在しているデータのみに限定されているため、直近でアクセスしたデータについては過去のアクセス履歴情報が無くアクセス頻度を知ることができないため、そのような直近でアクセスしたデータは常にキャッシュメモリに書き込むというLRU方式と同じ動作を行うしかなかった。
【００１４】
またこの事情はLRUやLFU方式以外の、他のキャッシュ管理方式においても共通である。すなわち従来のキャッシュ管理方式においては、キャッシュメモリ上に存在していないデータに関する過去のアクセス履歴情報を持たないために、直近でアクセスしたデータは、たとえそのデータに対するアクセス頻度が過去において低かったとしても、常にキャッシュメモリに書き込んでいた。結果として、従来のキャッシング機能を備えたクラウド型音楽再生アプリにおいては、再生頻度の低い楽曲を再生した場合に、新譜や準新譜の楽曲データをキャッシュから追い出してしまうために、キャッシュのヒット率が低下し、ひいてはモバイル通信データ量を無駄に消費してしまうことにつながっていた。
【００１５】
一方、本発明では、キャッシュメモリ上に存在する楽曲に加えて、キャッシュメモリ上に存在していない楽曲についても、再生履歴情報を維持管理している所に特徴がある。従って再生履歴情報を参照可能な楽曲については、各楽曲データの再生頻度や再生確率を考慮することにより、クラウド上のコンテンツサーバからダウンロードした楽曲データを、単にそのまま再生するだけのストリーミング再生動作と、後のリピート再生に備えて不揮発のキャッシュメモリに書き込んで残しておくダウンロード再生動作とを適切に切り替えることを可能としている。これにより、従来のキャッシュ機構を備えたクラウド型音楽再生アプリと比較して、本発明はキャッシュのヒット率が高く、貴重なモバイル通信データ量を節約することが可能となっている。本発明の目的は、近年利用が広がっている格安SIMに代表されるような従量課金方式の通信サービスに好適な、新規かつ改良されたコンテンツ再生装置及びコンピュータプログラムを提供することにある。
【課題を解決するための手段】
【００１６】
上記課題を解決するために、本発明の第１の観点によれば、コンテンツを記憶するコンテンツキャッシュ部と、クラウド上のコンテンツサーバに登録されているコンテンツの再生頻度を算出するための再生頻度情報を保持するコンテンツデータベースと、前記コンテンツキャッシュ部を管理するコンテンツキャッシュ管理部と、を備え、前記コンテンツキャッシュ管理部は、再生対象となるコンテンツの前記再生頻度情報に基づいて、前記コンテンツサーバ上のコンテンツをダウンロードしながらリアルタイムに再生するオンザフライ再生動作と、前記コンテンツサーバからダウンロードしたコンテンツデータを前記コンテンツキャッシュ部に書き込みながら同時に再生を行うダウンロード再生動作と、を切り替えることを特徴とする、コンテンツ再生装置が提供される。
【００１７】
かかる構成によれば、コンテンツの再生頻度に応じて自動的にオンザフライ再生とダウンロード再生を切り替えることにより、あるときたまたま再生頻度の低いコンテンツを再生したことにより、より再生頻度の高いコンテンツをコンテンツキャッシュから削除してしまうという事態を防止できる。その結果、コンテンツキャッシュのヒット率が向上し、通信データ量をより節約できるようになる。このようにして、クラウド型音楽再生アプリの使い勝手を高めたコンテンツ再生装置とすることができる。
【００１８】
また、たまたま久しぶりに再生したが、またしばらくの間は聞きそうもない楽曲のデータをキャッシュに保存することを防止することができるので、書き換え回数に制限のあるメモリ（例えば、ＮＡＮＤ−Ｆｌａｓｈメモリ）に対する書き込み回数を抑制することができる（なお、モバイル端末は内蔵のＮＡＮＤ−Ｆｌａｓｈメモリの寿命を迎えると、故障状態となり使用不可となってしまう。）。その結果として、モバイル端末の利用可能年数を延ばすことができる。
【００１９】
上記課題を解決するために、本発明の第２の観点によれば、コンテンツを記憶するコンテンツキャッシュ部と、クラウド上のコンテンツサーバに登録されているコンテンツの再生確率を予想するための再生確率予想情報を保持するコンテンツデータベースと、前記コンテンツキャッシュ部を管理するコンテンツキャッシュ管理部と、を備え、前記コンテンツキャッシュ管理部は、再生対象となるコンテンツの前記再生確率予想情報に基づいて、前記コンテンツサーバ上のコンテンツをダウンロードしながらリアルタイムに再生するオンザフライ再生動作と、前記コンテンツサーバからダウンロードしたコンテンツデータを前記コンテンツキャッシュ部に書き込みながら同時に再生を行うダウンロード再生動作と、を切り替えることを特徴とする、コンテンツ再生装置が提供される。
【００２０】
かかる構成によれば、再生確率の高いコンテンツ（例えば、コンテンツサーバへの登録日時が新しいコンテンツ（音楽で言えば新曲））がコンテンツキャッシュに保存されるため、コンテンツキャッシュのヒット率が向上し、モバイル通信帯域を節約することが可能となる。一方で、久しぶりにたまたま再生した旧譜はキャッシュしないので、旧譜を再生することによりコンテンツキャッシュのヒット率が低下することがない。このようにして、クラウド型音楽再生アプリの使い勝手を高めたコンテンツ再生装置とすることができる。
【００２１】
本発明は、さまざまな応用が可能である。
例えば、前記コンテンツキャッシュ部においては、各コンテンツの先頭部分（例えば、３秒程度）とそれ以外の残余部分（又は全体）とに分けて、データが記録されるようにしてもよい。かかる構成によれば、コンテンツの先頭部分のデータを優先して残すなどといった柔軟な制御ができ、コンテンツ再生開始時の再生遅延時間が短縮される。コンテンツの先頭部分がコンテンツキャッシュに存在していれば、ユーザがある曲の再生を指示した場合に、すぐに楽曲の再生を開始することが可能となるため、機器の使い勝手が向上する。
【００２２】
また、前記コンテンツキャッシュ部において、容量が満杯になってしまった場合に、前記各コンテンツの残余部分が先に削除されるようにしてもよい。かかる構成によれば、コンテンツの先頭のデータがコンテンツキャッシュに残っている可能性が高まるため、楽曲再生指示を行った場合のレスポンスを高められる可能性が高くなり、機器の使い勝手が向上する。
【００２３】
また、前記コンテンツキャッシュ部において、前記各コンテンツの先頭部分を保存する先頭部分キャッシュの容量と、前記各コンテンツの残余部分を保存する残余部分キャッシュの容量とが分けて管理され、容量が満杯になってしまった場合に、前記先頭部分キャッシュと前記残余部分キャッシュとで独立して不要データの削除処理が実施されるようにしてもよい。かかる構成によれば、コンテンツの先頭のデータがコンテンツキャッシュに残っている可能性が高まるため、楽曲再生指示を行った場合のレスポンスを高められる可能性が高くなり、機器の使い勝手が向上する。
【００２４】
また、前記コンテンツキャッシュ部は、ユーザが直近で再生する可能性が高いコンテンツを保存する第１コンテンツキャッシュと、ユーザが後日また再生する可能性が高いコンテンツを保存する第２コンテンツキャッシュと、を有するようにしてもよい。第１、第２コンテンツキャッシュそれぞれについて、各コンテンツキャッシュ部の利用状況に応じた最適なデータ管理方法を採用することが可能となるため、キャッシュデータの有効活用が可能となる。また、第１、第２キャッシュそれぞれについて、各キャッシュの利用状況に応じた最適なデータ記録デバイスを利用することが可能となるため、デバイス寿命の消耗を防ぎ、結果として機器の高寿命化を図ることができる。
【００２５】
また、前記第１コンテンツキャッシュには、再生中のコンテンツに関連するコンテンツのみ（例えば、再生中のアルバムのコンテンツのみ）が保存されるようにしてもよい。かかる構成によれば、ユーザが再生しているコンテンツ（例えば、再生している曲）を変更する操作を行った場合に、迅速に応答する操作性を提供することができる。
【００２６】
また、前記第１コンテンツキャッシュは、データの保存先として、メインメモリ等の揮発性メモリにより構成されるようにしてもよい。かかる構成によれば、最もデータの入れ代わりが激しい第１コンテンツキャッシュの保存先としてメインメモリを利用することにより、第２コンテンツキャッシュに利用されるデバイス（例えば、ＮＡＮＤ−Ｆｌａｓｈメモリで構成）の寿命の消耗を防ぎ、機器の高寿命化を図ることができる。
【００２７】
また、前記第１コンテンツキャッシュにおけるデータ管理単位は、１つのコンテンツ（例えば、１曲）をさらに細かく分けたチャンク単位であってもよい。かかる構成によれば、第１コンテンツキャッシュの容量の限界までコンテンツデータを先読みすることが可能となるので、キャッシュ容量を目一杯有効活用することができる。よって、それだけ先読みできるコンテンツの長さが増えるので、コンテンツサーバからのダウンロード速度が一時的に低下したような場合であっても、より再生途切れの発生が少ない機器を提供することができる。
【００２８】
また、前記第２コンテンツキャッシュには、後日再生する可能性が高いコンテンツのみが保存され、前記第２コンテンツキャッシュにおけるキャッシュ管理のアルゴリズムは、前記第１コンテンツキャッシュとは別のアルゴリズムが採用されるようにしてもよい。かかる構成によれば、第２コンテンツキャッシュの利用状況に応じて、最適なキャッシュ管理アルゴリズムを採用することが可能となるため、第２コンテンツキャッシュのヒット率がより向上し、結果的に限りあるインターネット通信データ量を節約することが可能となる。
【００２９】
また、前記第２コンテンツキャッシュは、データの保存先として、ＮＡＮＤ−Ｆｌａｓｈメモリ等で構成された不揮発性メモリにより構成されるようにしてもよい。かかる構成によれば、機器の電源を切ったり、あるいは再起動させた場合であっても、第１コンテンツキャッシュと比較してより大容量を割り当てることが可能な第２コンテンツキャッシュ内のデータを失うことがないため、せっかくキャッシュしたデータをより有効活用することができる。よって、限りあるインターネット通信データ量を無駄にしてしまうことがない。
【００３０】
また、前記第２コンテンツキャッシュにおけるデータ管理単位は、コンテンツ単位（例えば、曲単位）であってもよい。かかる構成によれば、第２コンテンツキャッシュの管理データの増大を防ぐことができるため、同じ容量のメモリにより多くの楽曲をキャッシュすることが可能となる。また、第２コンテンツキャッシュのデータの書き換え頻度を大幅に低減することが可能となる。ＮＡＮＤ−Ｆｌａｓｈメモリにはデバイス固有の書き込み上限回数というものがあるが、書き換え頻度を節約することにより、機器の大幅な高寿命化を期待することができる。
【００３１】
また、前記第１コンテンツキャッシュと前記第２コンテンツキャッシュの容量は、個別に設定できるようにしてもよい。かかる構成によれば、ユーザの利用状況・利用環境に応じた最適なキャッシュ容量を選択することが可能なため、例えば毎月の通信量が無制限の通信契約を結んでいる場合には、第２コンテンツキャッシュの容量はごく少な目に設定して、主に第１コンテンツキャッシュのみを利用することにより、一時的に通信速度が低下した場合の音楽再生途切れを防止することと、機器の不揮発性メモリ容量をむやみに消費してしまうことを防ぐことができる。あるいは逆に毎月の通信量に上限がある通信契約を結んでいる場合は、第１コンテンツキャッシュと第２コンテンツキャッシュを共に多めに設定することにより、音楽再生途切れの防止効果と、通信データ量節約の効果を両方享受することが可能となる。
【００３２】
また、前記コンテンツデータベースは、複数のコンテンツサーバのコンテンツリスト情報を統合した統合コンテンツリスト情報を保持するようにしてもよい。かかる構成によれば、コンテンツの保存先が複数のサーバに分かれている場合であっても、一元化されたコンテンツリストから再生するコンテンツを選択することができるので、使い勝手が良くなる。また、再生したい曲が登録されているコンテンツサーバをいちいち選択する操作から、ユーザを解放することができる。
【００３３】
上記本発明の応用例は、任意に組み合わせることが可能である。また、本発明によれば、コンピュータを、上記のいずれかに記載のコンテンツ再生装置として機能させるためのコンピュータプログラムが提供される。
【発明の効果】
【００３４】
本発明によれば、クラウド型音楽再生アプリにおいて、ダウンロードした楽曲データの管理を自動化することにより、ユーザが音楽を再生したい楽曲を選択する以外の余計な仕事から解放して、クラウド型音楽再生アプリの使い勝手を高めることの可能なコンテンツ再生装置及びコンピュータプログラムが提供される。本発明のその他の効果については、以下の発明を実施するための形態の項でも説明する。
【図面の簡単な説明】
【００３５】
【図１】コンテンツ再生システムの全体構成を概略的に示す図である。
【図２】コンテンツサーバの内容を示す図である。
【図３】第１コンテンツキャッシュＬ１内のデータの配置を示す図である。
【図４】不揮発データの配置を示す図である。
【図５】コンテンツデータベースの内容を示す図である。
【図６】オンザフライ再生時の動作を示す図である。
【図７】ダウンロード再生時の動作を示す図である。
【図８】キャッシュ再生時の動作を示す図である。
【図９】本発明の一実施形態の動作を示すシーケンス図である。
【図１０】インタフェース・コマンドの例を一覧にした図である。
【図１１】メイン・コントローラ１１０のメインスレッドを示すフローチャートである。
【図１２】メイン・コントローラ１１０のＵＩ処理スレッドを示すフローチャートである。
【図１３】メイン・コントローラ１１０の再生処理スレッドを示すフローチャートである。
【図１４】コンテンツキャッシュ管理部１９０のメインスレッドを示すフローチャートである。
【図１５】コンテンツキャッシュ管理部１９０の先読みスレッドを示すフローチャートである。
【図１６】次ダウンロードチャンク決定処理を示すフローチャートである。
【図１７】空きチャンクバッファ検索処理を示すフローチャートである。
【図１８】キャッシュ再生スレッドを示すフローチャートである。
【図１９】ダウンロード／オンザフライ再生スレッドを示すフローチャートである。
【図２０】Ｌ２−Ｈキャッシュ書き込み処理を示すフローチャートである。
【図２１】Ｌ２−Ｅキャッシュ書き込み処理を示すフローチャートである。
【図２２】コンテンツ再生頻度値の算出処理を示すフローチャートである。
【図２３】コンテンツ再生頻度値更新処理スレッドを示すフローチャートである。
【図２４】コンテンツデータベース１７０の更新処理スレッドを示すフローチャートである。
【図２５】ディレクトリ検索処理を示すフローチャートである。
【図２６】artistテーブルの不要レコード削除処理を示すフローチャートである。
【図２７】albumテーブルの不要レコード削除処理を示すフローチャートである。
【図２８】songテーブルの不要レコード削除処理を示すフローチャートである。
【図２９】コンテンツ再生確率予想値の算出処理を示すフローチャートである。
【図３０】コンテンツ再生確率予想値更新処理スレッドを示すフローチャートである。
【発明を実施するための形態】
【００３６】
以下に添付図面を参照しながら、本発明の好適な実施形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００３７】
（第１の実施形態）
まず、本実施形態に係るコンテンツ再生装置１００が適用されるコンテンツ再生システムの全体構成について説明する。図１は、コンテンツ再生システムの全体構成を概略的に示す図である。コンテンツ再生システムは、図１に示したように、コンテンツサーバ１０とコンテンツ再生装置１００が、インターネットなどのネットワークを介して通信可能となっている。以下、このコンテンツ再生システムの各構成要素について順に説明する。
【００３８】
（コンテンツサーバ１０）
コンテンツサーバ１０は、クラウド上に存在するストレージ（クラウドストレージ）を利用することにより、後述するコンテンツ再生装置１００において再生対象となるコンテンツデータを記憶・保持しているサーバである。
【００３９】
コンテンツサーバ１０において記憶・保持されるコンテンツデータの内容について、図２を参照しながら説明する。図２は、コンテンツサーバ１０の内容の一部を示す図である。コンテンツサーバ１０に記憶・保持されるコンテンツデータは、図２に示したように、アーティストと、アルバム名と、トラック番号と、タイトルと、コンテンツの置き場所であるＵＲＬ（Uniform Resource Locator）を含んで構成される。なお、図２では、３つのコンテンツデータを（ａ）〜（ｃ）で表している。これらは１つのコンテンツサーバ１０に置かれてもよく、本実施形態のように異なるコンテンツサーバに置かれてもよい。
【００４０】
コンテンツデータにおけるアーティスト、アルバム名、トラック番号、タイトル及びコンテンツのＵＲＬの関係は一般的なものと同様である。すなわち、一人のアーティストに対して、アルバム名は一つでもよく二つ以上あってもよい。例えば、図２の例では、アーティスト「The  Beatles」に対して、２つのアルバム「Please please me」と「A hard day's night」が対応している。また、アルバム名とトラック番号は、一般には１：複数の関係である。また、各トラックに対してタイトルがあり、各タイトルに対して、１つのコンテンツのＵＲＬが対応している。
【００４１】
以上、コンテンツサーバ１０について説明した。次に、再び図１を参照しながら、本実施形態に特徴的な構成要素であるコンテンツ再生装置１００について説明する。
【００４２】
（コンテンツ再生装置１００）
コンテンツ再生装置１００は、使用者が携帯して移動できる機器であるモバイル機器を想定したものである。コンテンツ再生装置１００は、図１に示したように、メイン・コントローラ１１０と、ネットワーク通信部１２０と、操作検知部１３０と、画面表示部１４０、音楽再生部１５０と、コンテンツキャッシュ部１６０と、コンテンツデータベース１７０と、コンテンツデータベース更新部１８０と、コンテンツキャッシュ管理部１９０と、を主に備えて構成される。以下、コンテンツ再生装置１００の各構成要素について、順に説明する。
【００４３】
メイン・コントローラ１１０は、コンテンツ再生装置１００の全体の制御を行うものであり、図１に示したように、コンテンツ再生装置１００の各構成要素と連携動作する。なお、図１中の矢印は便宜上付したものであり、矢印が描かれていても連携動作しないものもあり、矢印が描かれていなくても連携動作するものもある。なお、以下の説明においては、メイン・コントローラ１１０の制御により行われる動作・作用については、制御主体を特に明示しない。
【００４４】
メイン・コントローラ１１０における本実施形態に特徴的な制御としては、メイン・コントローラ１１０は、後述するコンテンツキャッシュ管理部１９０と連係動作して、再生動作の切り替えを行う。具体的には、メイン・コントローラ１１０は、コンテンツキャッシュ管理部１９０と連係動作して、オンザフライ再生動作とダウンロード再生動作とを切り替える。この点については、さらに後述する。
【００４５】
ネットワーク通信部１２０は、コンテンツ再生装置１００をインターネットを介して通信を行う機能部である。操作検知部１３０は、コンテンツ再生装置１００のユーザによる操作を検知するものである。ユーザによる操作とは、例えば指による操作、声による操作、コンテンツ再生装置１００を動かすことによる操作など、各種操作を含む。画面表示部１４０は、コンテンツ再生装置１００における各種情報を表示する画面である。音楽再生部１５０は、音声を出力する機能部である。
【００４６】
ここで説明したネットワーク通信部１２０、操作検知部１３０、画面表示部１４０及び音楽再生部１５０は、汎用的なモバイル機器や音楽プレーヤーにおける一般的な構成要素であり、当業者であれば容易に理解できるため、これ以上の詳細な説明を割愛する。なお、コンテンツ再生装置１００に、これ以外の一般的な構成要素を含んでもよいことは言うまでもない。
【００４７】
（コンテンツキャッシュ記憶部１６０）
コンテンツキャッシュ部１６０は、コンテンツデータのコピーを保存する記憶手段である。本実施形態では、コンテンツキャッシュ部１６０は、第１コンテンツキャッシュＬ１と第２コンテンツキャッシュＬ２から構成されている。
【００４８】
コンテンツキャッシュ部１６０は、ユーザが直近で再生する可能性が高いコンテンツを保存する第１コンテンツキャッシュＬ１と、ユーザが後日また再生する可能性が高いコンテンツを保存する第２コンテンツキャッシュＬ２とを有する。このような構成とすることにより、各コンテンツキャッシュＬ１、Ｌ２それぞれについて、各コンテンツキャッシュＬ１、Ｌ２の利用状況に応じた最適なデータ管理方法を採用することが可能となるため、キャッシュデータの有効活用が可能となる。
【００４９】
また、各コンテンツキャッシュＬ１、Ｌ２それぞれについて、各コンテンツキャッシュの利用状況に応じた最適なデータ記録デバイスを利用することが可能となるため、デバイス寿命の消耗を防ぎ、結果として機器の高寿命化を図ることができる。本実施形態では、第１コンテンツキャッシュＬ１として、ＲＡＭ（メインメモリ）を使用し、第２コンテンツキャッシュＬ２として、ＮＡＮＤ−Ｆｌａｓｈメモリを使用する場合について説明する。
【００５０】
（第１コンテンツキャッシュＬ１）
以下、第１コンテンツキャッシュＬ１について説明する。まず、第１コンテンツキャッシュＬ１の構成について説明し、さらに第１コンテンツキャッシュＬ１の特徴について説明する。
【００５１】
上述したように、第１コンテンツキャッシュＬ１は、ＲＡＭ（メインメモリ）上に配置される。図３に示すように、メインメモリの一部の領域が第１コンテンツキャッシュデータ領域１６１として割り当てられている。第１コンテンツキャッシュデータ領域には、図３に示したように、Ｌ１キャッシュ管理テーブル１６２と、Ｌ１キャッシュチャンクバッファ１６３が配置されている。
【００５２】
Ｌ１キャッシュ管理テーブル１６２は、図３に示したように、チャンクのインデックスである「chunk_id」フィールドと、曲のインデックスである「song_id」フィールドと、ある曲を構成する複数のチャンクの中で何番目のチャンクであるかを示す「chunk_no」フィールドと、チャンクデータを送出済みであることを示す「used」フィールドと、チャンクの開始時刻である「chunk_start_time」フィールドとチャンクの終了時刻である「chunk_end_time」フィールドにより構成される。song_idフィールドの１つのsongに対して、chunk_noフィールドの複数のチャンクが対応する。また、chunk_idフィールドの値は、Ｌ１キャッシュ・チャンクバッファ１６３と関連付けられている。
【００５３】
図３に示した一例では、第１コンテンツキャッシュＬ１内には、合計５個のチャンクデータが存在している。そして、「chunk_id」＝１〜５のチャンクは、「song_id」＝１の曲の先頭５個分のチャンクデータに対応している。例えば、「chunk_id」＝１のチャンクは、「song_id」＝１の曲の０分０秒００〜０分７秒３９までの音楽データに対応しており、「chunk_id」＝２のチャンクは、「song_id」＝１の曲の０分７秒３９〜０分１２秒７８までの音楽データに対応しており、以下同様である。また、「chunk_id」＝１〜３のチャンクは送出済みであり、もし他に空きチャンクバッファが見つからない場合には、解放可能であることを示している。
【００５４】
Ｌ１キャッシュチャンクバッファ１６３は、図３に示したように、chunk_idフィールドの値に対応したチャンクが保存される領域である。各チャンクバッファのサイズは、６４ＫＢ固定である。
【００５５】
第１コンテンツキャッシュＬ１には、再生中のアルバムのコンテンツのみが保存される。これによりユーザが再生曲を変更する操作を行った場合に、迅速に応答する操作性を提供することができる。
【００５６】
また、第１コンテンツキャッシュＬ１は、上述したように、データの保存先として、メインメモリ等の揮発性メモリにより構成される。最もデータの入れ代わりが激しい第１コンテンツキャッシュＬ１の保存先として書換回数に制限の無いメインメモリを利用することにより、機器の高寿命化を図ることができる。
【００５７】
また、第１コンテンツキャッシュＬ１におけるデータ管理単位は、１曲をさらに細かく分けたチャンク単位である。かかる構成によれば、第１コンテンツキャッシュＬ１の容量の限界までコンテンツデータを先読みすることが可能となるので、キャッシュ容量を目一杯有効活用することができる。それだけ先読みできるコンテンツの長さが増えるので、コンテンツサーバ１０からのダウンロード速度が一時的に低下したような場合であっても、より再生途切れの発生が少ない機器を提供することができる。
【００５８】
（第２コンテンツキャッシュＬ２）
以下、第２コンテンツキャッシュＬ２について説明する。まず、第２コンテンツキャッシュＬ２の構成について説明し、さらに第２コンテンツキャッシュＬ２の特徴について説明する。
【００５９】
コンテンツ再生アプリが読み書きする不揮発データは、本実施形態の一例では、不揮発なメモリーデバイスであるＮＡＮＤ−Ｆｌａｓｈメモリー内に保存されている。図４に示したように、ＮＡＮＤ−Ｆｌａｓｈメモリー内には管理データ領域１６４と、Ｌ２キャッシュコンテンツ保存用領域１６５が配置されている。
【００６０】
管理データ領域１６４には、図４に示したように、コンテンツＤＢファイル１６６と、Ｌ２キャッシュ管理ファイル１６７が配置されている。コンテンツＤＢファイル１６６内には、図４に示したように、serverテーブルと、artistテーブルと、albumテーブルと、songテーブルが書き込まれている。Ｌ２キャッシュ管理ファイル１６７には、図４に示したように、Ｌ２−Ｈキャッシュ管理テーブルと、Ｌ２−Ｅキャッシュ管理テーブルが書き込まれている。なお、Ｌ２−Ｈは、第２コンテンツキャッシュＬ２の先頭部分（Ｈｅａｄ）の意味であり、Ｌ２−Ｅは、第２コンテンツキャッシュＬ２の全体（Ｅｎｔｉｒｅ）の意味である。
【００６１】
Ｌ２−Ｈキャッシュ管理テーブルは、idフィールドと、song_idフィールドと、fileフィールドと、scoreフィールドとから構成される。Ｌ２−Ｈキャッシュ管理テーブルのfileフィールドは、後述するコンテンツヘッド・キャッシュ・ファイルと関連付けられている。Ｌ２−Ｅキャッシュ管理テーブルは、idフィールドと、song_idフィールドと、fileフィールドと、scoreフィールドとから構成される。Ｌ２−Ｅキャッシュ管理テーブルのfileフィールドは、後述するコンテンツ・キャッシュ・ファイルと関連付けられている。
【００６２】
Ｌ２キャッシュコンテンツ保存用領域１６５は、図４に示したように、Ｌ２コンテンツ先頭部分保存エリアＬ２−Ｈと、Ｌ２コンテンツ全体保存用エリアＬ２−Ｅとから構成される。Ｌ２コンテンツ先頭部分保存エリアＬ２−Ｈは、第２コンテンツキャッシュＬ２に保存されたコンテンツ（Ｌ２コンテンツ）の先頭部分を保存するエリアであり、例えば最大５１２ＭＢである。Ｌ２コンテンツ全体保存用エリアＬ２−Ｅは、第２コンテンツキャッシュＬ２に保存されたコンテンツ（Ｌ２コンテンツ）の全体を保存するエリアであり、例えば最大４ＧＢである。
【００６３】
Ｌ２コンテンツ先頭部分保存エリアＬ２−Ｈには、図４に示したように、コンテンツヘッド・キャッシュ・ファイル00001.head、00002.head、00003.head、00004.head、・・・が保存される。各ファイルサイズは、６４ＫＢ固定とすることができ、この場合には５１２ＭＢ÷６４ＫＢ＝最大８１９２曲分保存できる。
【００６４】
Ｌ２コンテンツ全体保存用エリアＬ２−Ｅには、図４に示したように、コンテンツ・キャッシュ・ファイル00001.cache、00002.cache、00003.cache、00004.cache、・・・が保存される。各ファイルサイズは、コンテンツの長さに依存する可変長の大きさである。例えば、コンテンツの平均ファイルサイズが４ＭＢであるとすると、４ＧＢ÷４ＭＢ＝最大１０２４曲程度までコンテンツを保存できる。
【００６５】
第２コンテンツキャッシュＬ２には、後日再生する可能性が高いコンテンツのみが保存され、第２コンテンツキャッシュＬ２におけるキャッシュ管理のアルゴリズムは、第１コンテンツキャッシュＬ１とは別のアルゴリズムが採用される。第２コンテンツキャッシュＬ２の利用状況に応じて、最適なキャッシュ管理アルゴリズムを採用することが可能となるため、第２コンテンツキャッシュＬ２のヒット率がより向上し、結果的に限りあるインターネット通信データ量を節約することが可能となる。
【００６６】
また、第２コンテンツキャッシュＬ２は、上述したように、データの保存先として、ＮＡＮＤ−Ｆｌａｓｈメモリ等で構成された不揮発性メモリにより構成される。コンテンツ再生装置１００の電源を切ったり、あるいは再起動させた場合であっても、第１コンテンツキャッシュＬ１と比較してより大容量を割り当てることが可能な第２コンテンツキャッシュＬ２内のデータを失うことがないため、せっかくキャッシュしたデータをより有効活用することができる。このようにして、限りあるインターネット通信データ量を無駄にしてしまうことがない。
【００６７】
また、第２コンテンツキャッシュＬ２におけるデータ管理単位は、曲単位としている。このように第１コンテンツキャッシュＬ１よりも大粒度の管理を行うことにより、第２コンテンツキャッシュＬ２の管理データの増大を防ぐことができるため、同じ容量のメモリにより多くの楽曲をキャッシュすることが可能となる。また、第２コンテンツキャッシュＬ２のデータの書き換え頻度を大幅に低減することも可能となる。ＮＡＮＤ−Ｆｌａｓｈメモリにはデバイス固有の書き込み上限回数というものがあるが、書き換え頻度を節約することにより、機器の大幅な高寿命化を期待することができる。
【００６８】
以上、コンテンツキャッシュ部１６０を構成する第１コンテンツキャッシュＬ１と第２コンテンツキャッシュＬ２について説明した。以下、第１コンテンツキャッシュＬ１、第２コンテンツキャッシュＬ２の応用例について説明する。
【００６９】
コンテンツキャッシュ部１６０においては、各コンテンツの先頭部分（例えば、３秒程度）とそれ以外の残余部分（又は全体）とに分けて、データを記録することができる。コンテンツの先頭部分のデータを優先して残すなどといった柔軟な制御ができ、コンテンツ再生開始時の再生遅延時間が短縮される。コンテンツの先頭部分がコンテンツキャッシュ部１６０に存在していれば、ユーザがある曲の再生を指示した場合に、すぐに楽曲の再生を開始することが可能となるため、機器の使い勝手が向上する。
【００７０】
また、コンテンツの先頭部分（例えば、３秒程度）と全体（又は先頭部分を除く残りの部分）を分けて、コンテンツキャッシュ部１６０にデータを記録するようにしたときは、さらにコンテンツキャッシュ部１６０に保存可能なコンテンツ全体の曲数よりも、コンテンツの先頭のみを保存可能な曲数を大きくすることができる。
【００７１】
例えば、ある曲の先頭部分のみがキャッシュされていて、全体がキャッシュされていない状況下において、その曲の再生が指示された場合には、コンテンツサーバ１０にその曲データの全体ダウンロード要求を発行しながら、同時にコンテンツキャッシュ部１６０内のコンテンツの先頭データの再生を開始する。その後、ネットワークの通信遅延時間（往復分）＋コンテンツサーバ１０の応答時間を加えた時間が経過すると、コンテンツサーバ１０からコンテンツデータが届き始める。このサーバ応答時間よりも、コンテンツキャッシュ部１６０に保存するコンテンツの先頭部分の長さを長く設定することによって、コンテンツを途切れずに再生することが可能となる。なお本実施例では、コンテンツの先頭部分のデータサイズを、第２コンテンツキャッシュＬ２のチャンクサイズと同一に設定することにより、コンテンツキャッシュ管理部が担うコンテンツ制御処理が複雑化することを防止している。
【００７２】
ここで、従来技術との対比で説明する。従来、キャッシュのデータを減らすためには、ファイルデータを部分的に削除することが行われていた。ここでいうファイルデータを部分的に削除するとは、各コンテンツの質を低下する方向でデータを改変することを意味している。例えば、以下のような削除が行われていた。
・静止画：画素を間引く（解像度を下げる）。
・動画：フレームを間引く（フレームレート（映像の滑らかさ）を下げる）。
・画像＋文字：画像を削除して、文字情報だけ残す。
・音声：ステレオ音声をモノラル音声に変換する。ビットレートを下げる（同時に音質は劣化する）。
この点、本実施形態によれば、各コンテンツの質は維持したまま、コンテンツを時間方向に向かって一部のデータを削除しているため、部分的に削除することの意味合いが全く異なっており、得られる効果は全く別物である。
【００７３】
また、コンテンツキャッシュ部１６０において、容量が満杯になってしまった場合に、各コンテンツの残余部分（コンテンツの先頭のデータ以外の部分）が先に削除されるようにしてもよい。コンテンツの先頭のデータがコンテンツキャッシュ部１６０に残っている可能性が高まるため、楽曲再生指示を行った場合のレスポンスを高められる可能性が高くなり、機器の使い勝手が向上する。
【００７４】
また、コンテンツキャッシュ部１６０において、各コンテンツの先頭部分を保存する先頭部分キャッシュの容量と、各コンテンツの残余部分を保存する残余部分キャッシュの容量とが分けて管理され、容量が満杯になってしまった場合に、先頭部分キャッシュと残余部分キャッシュとで独立して不要データの削除処理が実施されるようにしてもよい。コンテンツの先頭のデータがコンテンツキャッシュ部１６０に残っている可能性が高まるため、楽曲再生指示を行った場合のレスポンスを高められる可能性が高くなり、機器の使い勝手が向上する。
【００７５】
また、第１コンテンツキャッシュＬ１と第２コンテンツキャッシュＬ２の容量は、個別に設定できるようにしてもよい。ユーザの利用状況・利用環境に応じた最適なキャッシュ容量を選択することを可能なため、以下のような使い方が可能となる。
・例えば、毎月の通信量が無制限の通信契約を結んでいる場合には、第２コンテンツキャッシュＬ２の容量はごく少な目に設定して、主に第１コンテンツキャッシュＬ１のみを利用することにより、一時的に通信速度が低下した場合の音楽再生途切れを防止することと、機器の不揮発性メモリ容量をむやみに消費してしまうことを防ぐことができる。
・あるいは逆に毎月の通信量に上限がある通信契約を結んでいる場合は、第１コンテンツキャッシュＬ１／第２コンテンツキャッシュＬ２をともに多めに設定することにより、音楽再生途切れの防止効果と、通信データ量節約の効果を両方享受することが可能となる。
【００７６】
（コンテンツデータベース１７０）
再び図１を参照しながら、コンテンツ再生装置１００の構成要素を説明する。
コンテンツデータベース１７０は、コンテンツサーバ１０に登録されているコンテンツに関する再生履歴情報とコンテンツ鮮度情報を保持する機能部である。コンテンツデータベース更新部１８０は、コンテンツデータベース１７０の内容を更新する機能部である。
【００７７】
コンテンツデータベース１７０で保持される情報について、図５を参照しながら説明する。図５は、コンテンツデータベース１７０の内容の一部を示す図である。コンテンツデータベース１７０で保持される情報は、図５（ａ）に示したserverテーブルと、図５（ｂ）に示したartistテーブルと、図５（ｃ）に示したalbumテーブルと、図５（ｄ）に示したsongテーブルと、から主に構成される。
【００７８】
serverテーブルは、コンテンツサーバ１０のトップＵＲＬを示すものであり、図５（ａ）に示した一例では、３つのコンテンツサーバ１０のトップＵＲＬを示す。artistテーブルは、図５（ｂ）に示したように、識別子である「id」フィールドとアーティスト名である「name」フィールドと、アーティスト名の読みを示す「yomi」フィールドとからなる。albumテーブルは、図５（ｃ）に示したように、識別子である「id」フィールドと、「artist_id」フィールドと、アルバムのタイトル名である「title」フィールドとからなる。ここで、「artist_id」フィールドは、artistテーブルの「id」フィールドに対応するものである。
【００７９】
songテーブルは、図５（ｄ）に示したように、識別子である「id」フィールドと、アルバムの識別子である「album_id」フィールドと、アルバム内のトラック番号を表す「trackno」フィールドと、曲のタイトルを表す「title」フィールドと、serverテーブルに対応する「server_id」フィールドと、曲のコンテンツサーバ上の場所を表す「path」フィールドと、曲データの長さをバイト単位で表す「filesize」フィールドと、この曲がコンテンツサーバに書き込まれた日時を記録する「write_date」フィールドと、この曲を最後に再生開始した日時を記録する「play_date1」フィールドと、この曲を最後のその前に再生開始した日時を記録する「play_date2」フィールドとからなる。
【００８０】
再生頻度値は、例えば以下のプログラムにより計算することができる。scoreの値が再生頻度を示し、値が大きいほど再生頻度が高いことを意味する。
if play_date2 != ""
then
diff = max(play_date1 - play_date2, now_date - play_date1)
score = max(365 - diff, 0) / 365 * 100
else
score = -1
【００８１】
ここで(play_date1 - play_date2)や(now_date - play_date1)の値は、日数単位で計算される。例えば、あるコンテンツを２０１５年１２月１日の１０：００に初めて再生して、ちょうどその１２時間後の２２：００に同じコンテンツを再生した場合には、(play_date1 - play_date2)の計算値は０．５となる。上記のプログラムにより計算されるscoreの値は、例えば同じコンテンツを立て続けに２回再生した場合にはほぼ１００の値となる。一方、play_date1とplay_date2の日数差が大きくなるにつれてscoreの値は低下していき、日数差が３６５日に達するとscoreの値は０となる。またplay_date1とplay_date2の日数差が小さかったとしても、now_dateとplay_date1の日数差が大きくなるとscoreの値はやはり低下する。これはあるコンテンツを過去において繰り返し何回も再生したことがあるとしても、最後にそのコンテンツを再生してから多くの日数が経過している場合には、そのコンテンツの再生頻度は低くなったと考えられるからである。scoreの値が大きいほどコンテンツの再生頻度が高いと判断されるが、scoreの絶対値そのものには特に意味はない。
【００８２】
以上、コンテンツデータベース１７０について説明した。コンテンツデータベース１７０では、上記の他にもさまざまな情報を保持することができる。例えば、コンテンツデータベース１７０は、複数のコンテンツサーバ（例えば、コンテンツサーバ１０と同様の構成を有する複数のコンテンツサーバ）のコンテンツリスト情報を統合した統合コンテンツリスト情報を保持するようにしてもよい。かかる構成によれば、コンテンツの保存先が複数のサーバに分かれている場合であっても、一元化されたコンテンツリストから再生するコンテンツを選択することができるので、使い勝手が良くなる。また、再生したい曲が登録されているコンテンツサーバをいちいち選択する操作から、ユーザを解放することができる。
【００８３】
（コンテンツキャッシュ管理部１９０）
コンテンツキャッシュ管理部１９０は、コンテンツキャッシュ部１６０を管理する機能部である。コンテンツキャッシュ管理部１９０は、メイン・コントローラ１１０と連携動作することにより、オンザフライ再生動作と、ダウンロード再生動作を実現する。すなわち、コンテンツキャッシュ管理部１９０は、再生対象となるコンテンツの再生頻度情報に従って、オンザフライ再生動作とダウンロード再生動作とを切り替える。
【００８４】
コンテンツの再生動作について、図６〜図８を参照しながら説明する。図６〜図８において、図中の破線は、コンテンツデータの流れを示す。オンザフライ再生動作とは、図６に示したように、コンテンツサーバ１０上のコンテンツデータを第１コンテンツキャッシュＬ１にダウンロードしながら、リアルタイムに再生する動作である。
【００８５】
また、ダウンロード再生動作とは、図７に示したように、コンテンツサーバ１０から第１コンテンツキャッシュＬ１にダウンロードしたコンテンツデータを、第２コンテンツキャッシュＬ２にコピーしながら、同時に再生を行う動作である。なお、ダウンロード再生動作を行うことによって、第２コンテンツキャッシュＬ２にコンテンツデータが書き込まれる。この第２コンテンツキャッシュＬ２に書き込まれたコンテンツデータは、キャッシュ再生動作により再生することができる。
【００８６】
キャッシュ再生動作とは、図８に示したように、第２コンテンツキャッシュＬ２に書き込まれているコンテンツデータを利用することで、ネットワーク通信が行えないような場合であっても、コンテンツの再生を可能とする動作である。
【００８７】
次に、本実施形態におけるコンテンツキャッシュ管理部１９０の動作について、従来技術との対比で説明する。
【００８８】
従来技術においては、再生対象のコンテンツがコンテンツキャッシュに存在するかどうかに応じて、ダウンロードデータの再生（＝コンテンツキャッシュへの書き込み）か、キャッシュデータの再生（＝コンテンツキャッシュの読み出し）のいずれかの動作を行っていた。ここで、ダウンロードデータの再生は、さらに細かく分類すると、ダウンロード再生方式とストリーミング再生方式のいずれかの方式で行われていた。
【００８９】
ダウンロード再生方式とは、まずダウンロードしたコンテンツデータをコンテンツキャッシュに書き込んでいき、１曲分のダウンロードが完了したら、ダウンロード済みコンテンツの再生を開始する再生方式である。また、ストリーミング再生方式とは、コンテンツデータをダウンロードしながら、同時にダウンロードしたコンテンツの再生を行う再生方式である。いずれの再生方式を採用している場合であっても、再生対象のコンテンツデータは必ずコンテンツキャッシュに書き込む必要があった。
【００９０】
ここでコンテンツキャッシュ内に再生頻度が高いコンテンツが書き込まれている状況下において、再生頻度が低く、コンテンツキャッシュにもキャッシュデータが存在していないコンテンツを再生した場合を考えてみる。もしコンテンツキャッシュにダウンロードしたコンテンツデータが収まる分の空き容量があるのであれば、ダウンロードしたデータをコンテンツキャッシュに書き込むだけであり、何も問題はない。
【００９１】
一方、コンテンツキャッシュの空き容量が不足していた場合には、LRU方式ではコンテンツキャッシュ内に存在するすべてのコンテンツの中で最も過去に再生したコンテンツをまず削除した上で、ダウンロードしたコンテンツをコンテンツキャッシュに書き込むことになる。しかしながらその結果として、ある時にたまたま再生したが長い目で見れば再生頻度の低いコンテンツが再生頻度の高いコンテンツをコンテンツキャッシュから追い出してしまうことが発生していた。このために、コンテンツキャッシュのヒット率が低下してしまい、ひいては通信データ量を無駄に消費してしまうことにつながっていた。このような動作を引き起こしてしまう一番の要因は、コンテンツの再生履歴情報（再生日時／再生回数／再生頻度等）が維持管理される対象が、コンテンツキャッシュ内に存在するコンテンツのみだったからである。
【００９２】
一方、本実施形態のコンテンツキャッシュ管理部１９０においては、再生対象のコンテンツがコンテンツキャッシュ部１６０に存在するかどうかに加えて、再生対象のコンテンツの再生頻度値とコンテンツキャッシュ部１６０内の各コンテンツの再生頻度値を比較することにより、オンザフライ再生（第２コンテンツキャッシュＬ２は使用しない）（図６）か、ダウンロード再生（図７）のいずれかの動作を行う。
【００９３】
すなわち、本実施形態において、再生対象のコンテンツがコンテンツキャッシュ部１６０内に存在していない場合に、再生対象コンテンツの再生頻度値が相対的に低い場合には、オンザフライ再生（図６）を行い、逆に再生頻度値が高い場合には、従来と同様に、ダウンロード再生（図７）を行う。
【００９４】
上述したように、オンザフライ再生では、コンテンツをダウンロードしながら再生を行うが、ダウンロードしたコンテンツを不揮発の第２コンテンツキャッシュＬ２には書き込まない動作を行う。このオンザフライ再生の導入により、あるときたまたま再生頻度の低いコンテンツを再生したことにより、より再生頻度の高いコンテンツを第２コンテンツキャッシュＬ２から削除してしまうという事態を防止できる。その結果、第２コンテンツキャッシュＬ２のヒット率が向上し、通信データ量をより節約できるようになる。
【００９５】
なお、本実施形態において、コンテンツの再生履歴情報（再生日時／再生回数／再生頻度等）が維持管理される対象は、コンテンツサーバ１０に存在するすべてのコンテンツとすることができる。そして、もし複数のコンテンツサーバ（クラウドストレージ）が存在するのであれば、各コンテンツサーバが保持しているコンテンツを統合した全コンテンツに対して再生履歴情報を維持管理することができる。
【００９６】
ただし、コンテンツの再生履歴情報（再生日時／再生回数／再生頻度等）が維持管理される対象としては、必ずしもすべてのコンテンツである必要はなく、以下のように考えることもできる。
・コンテンツキャッシュ部１６０に保持しているコンテンツ：Ａ
・コンテンツサーバ１０に登録されている全コンテンツ：Ｂ
・再生頻度情報を保持するコンテンツ：Ｘ
としたときに、「Ａ＜Ｘ≦Ｂ」の関係が成立するような条件で再生頻度条件を保持するようにしてもよい。
【００９７】
（第１の実施形態の動作）
次に、本実施形態の動作について、図９〜図２８を参照しながら説明する。図９は、本実施形態の動作を示すシーケンス図である。図１０は、図９のシーケンスにおいて構成要素間でやり取りされるインタフェース・コマンドの例を一覧にしたものである。図１１〜図２８は、図９のうち主要なスレッドの詳細を示すフローチャートである。以下、図９及び図１０を参照しつつ、図１１〜図２８のフローチャートを説明する。
【００９８】
＜メインスレッド：図１１＞
メイン・コントローラ１１０のメインスレッドについて、図１１を参照しながら説明する。まず、メイン・コントローラ１１０の再生処理スレッドの実行を開始する（ステップＳ１０２）。この処理については、図１３を参照しながら後述する。続いて、メイン・コントローラ１１０のＵＩ処理スレッドの実行を開始する（ステップＳ１０４）。この処理については、図１２を参照しながら後述する。さらに、コンテンツキャッシュ管理部１９０のメインスレッドの実行を開始する（ステップＳ１０６）。この処理については、図１４を参照しながら後述する。
【００９９】
なお、ここでスレッドについて補足しておく。従来から良く利用されているサブルーチンの場合には、例えばメインルーチンからサブルーチンを呼び出した場合には、サブルーチンを実行している最中はメインルーチンの方は実行停止状態となり、しかる後にサブルーチンの実行が終了するとメインルーチンの動作が再開されるというような動きとなる。すなわちサブルーチンの場合には、呼び出し側の処理（この例ではメインルーチン）と呼び出された側の処理（この例ではサブルーチン）が同時に実行されることはない。一方スレッドの場合には、例えばメインスレッドから別のスレッドの実行開始を指示すると、呼び出し側の処理（この例ではメインスレッド）と呼び出された側の処理（この例では別スレッド）が同時並行的に実行されるという違いがある。
【０１００】
続いて、コンテンツ再生頻度値（又は再生確率予想値）を更新するかを判断する（ステップＳ１０８）（なお、後述する第２の実施形態では、コンテンツ再生頻度値を、再生確率予想値と読み替える。以下同様である。）。この判断の具体的な実行タイミングとしては、例えば１日に１回程度、自動的に実行することができる。これはコンテンツ再生頻度値（又は再生確率予想値）（以下、scoreと表記）を算出する際に「現在日時」を参照しているため、時間の経過と共にscore値が変化するからである。しかし、あまり頻繁にこの更新処理を行っても、モバイル機器のバッテリーを無用に消耗させてしまうだけなので、バッテリー消費とscore値をできるだけ正しい値に維持することのバランスを考慮して、更新頻度を設定する必要がある。
【０１０１】
ステップＳ１０８の判断の結果、コンテンツ再生頻度値（又は再生確率予想値）を更新する場合は、コンテンツ再生頻度値（又は再生確率予想値）の更新処理スレッドの実行を開始する（ステップＳ１１０）。そして、ステップＳ１０８に戻る。
【０１０２】
一方、ステップＳ１０８の判断の結果、コンテンツ再生頻度値（又は再生確率予想値）を更新しない場合は、コンテンツデータベース１７０を更新するかを判断する（ステップＳ１１２）。この判断の具体的な実行タイミングとしては、例えば１か月に１回程度自動的に実行させたり、あるいはユーザが手動で「コンテンツデータベース１７０の更新」を指示した時に実行してもよい。コンテンツデータベース１７０を更新するためには、インターネット経由でコンテンツサーバ１０上のコンテンツファイルにアクセスする必要があるため、むやみにコンテンツデータベース１７０の更新を行うと、貴重なモバイル通信データ量を無駄に消費してしまう。よってこの更新処理を自動実行することは、モバイル通信データ量の上限のある通信サービスを利用しているユーザにとっては好ましい動作ではない可能性が高い。よって、コンテンツデータベース１７０の更新処理を自動的に行うかどうかの設定手段を設けて、ユーザが選択可能とするのが良い。
【０１０３】
ステップＳ１１２の判断の結果、コンテンツデータベース１７０を更新する場合は、コンテンツデータベース１７０の更新処理スレッドの実行を開始する（ステップＳ１１４）。そして、ステップＳ１０８に戻る。一方、ステップＳ１１２の判断の結果、コンテンツデータベース１７０を更新しない場合は、そのままステップＳ１０８に戻る。
【０１０４】
＜ＵＩ処理スレッド（図１２）＞
上述した図１１のステップＳ１０４で起動しているメイン・コントローラ１１０のＵＩ処理スレッドについて、図１２を参照しながら説明する。
【０１０５】
まず、コンテンツデータベース１７０のartistテーブルを参照して、アーティストリストを得る（ステップＳ２０２）。この際のＳＱＬ文は図１０（ａ）に示したとおりである。そして、アーティストリストを画面表示部１４０に表示する（ステップＳ２０４）。そして、アーティストが選択されるかを待つ（ステップＳ２０６）。あるアーティストが選択された場合には、albumテーブルでartist_idがユーザの選択したアーティストと一致するアルバムを検索して、アルバムリストを得る（ステップＳ２０８）。この際のＳＱＬ文は図１０（ｂ）に示したとおりである。そして、アルバムリストを画面表示部１４０に表示する（ステップＳ２１０）。
【０１０６】
ここで、“前の画面に戻る”が選択された場合には（ステップＳ２１２）、ステップＳ２０２に戻る。“前の画面に戻る”が選択されない場合で、あるアルバムが選択されない場合（ステップＳ２１４）は、ステップＳ２１２に戻り、あるアルバムが選択された場合には、songテーブルでalbum_idがユーザの選択したアルバムと一致する曲を検索して、曲リストを得る（ステップＳ２１６）。この際のＳＱＬ文は図１０（ｃ）に示したとおりである。そして、曲リストを画面表示部１４０に表示する（ステップＳ２１８）。
【０１０７】
“前の画面に戻る”が選択された場合には（ステップＳ２２０）、ステップＳ２０８に戻る。“前の画面に戻る”が選択されない場合で、ある曲の再生が指示されない場合（ステップＳ２２２）は、ステップＳ２２０に戻り、ある曲の再生が指示された場合は、選択アルバムと選択曲に基づいて、プレイリスト通知を作成する（ステップＳ２２４）。さらに、再生処理スレッドにプレイリスト通知を発行する（ステップＳ２２６）。この際のプレイリスト通知内容は図１０（ｄ）に示したとおりである。そして、再生処理スレッドに再生開始要求を発行する（ステップＳ２２８）。この際の再生開始要求内容は図１０（ｅ）に示したとおりである。
【０１０８】
＜再生処理スレッド（図１３）＞
上述した図１１のステップＳ１０２で起動しているメイン・コントローラ１１０の再生処理スレッドについて、図１３を参照しながら説明する。
【０１０９】
まず、他モジュール／スレッドからのリクエストメッセージを受信する（ステップＳ３０２）。リクエストメッセージを受信したかを判断し（ステップＳ３０４）、受信しない場合は、ステップＳ３０２に戻る。受信した場合は、メッセージ内容を判断する（ステップＳ３０６）。メッセージ内容は、「プレイリスト要求」、「再生開始要求」、「再生停止要求」、「コンテンツ再生終了通知」のいずれかであり、メッセージ内容に応じて、以下の処理を行う。
【０１１０】
メッセージが「プレイリスト通知」である場合、コンテンツキャッシュ管理部１９０のメインスレッドにプレイリスト通知を発行する（ステップＳ３０８）。この際のプレイリスト通知内容は図１０（ｆ）に示したとおりである。メッセージが「再生開始要求」である場合、サウンドサービスが提供するサウンド再生ＡＰＩをコールして、再生対象コンテンツのＵＲＬを渡すことによって、コンテンツの再生を開始する（ステップＳ３１０）。サウンドサービスはコンテンツキャッシュ管理部に対して、http プロトコルで “GET” リクエストを発行することで、再生対象のコンテンツデータを取得する。この際のコンテンツ要求内容は図１０（ｇ）に示したとおりである。メッセージが「再生停止要求」である場合、サウンド再生ＡＰＩをコールして、コンテンツの再生を停止する（ステップＳ３１２）。
【０１１１】
メッセージが「コンテンツ再生終了通知」である場合、プレイリストの全コンテンツの再生が終了したかを判断する（ステップＳ３１４）。プレイリストの全コンテンツの再生が終了した場合、ステップＳ３０２に戻る。プレイリストの全コンテンツの再生が終了していない場合、再生対象コンテンツを次のコンテンツに変更したプレイリストを作る（ステップＳ３１６）。さらに、コンテンツキャッシュ管理部１９０のメインスレッドにプレイリストを通知し（ステップＳ３１８）、サウンド再生ＡＰＩをコールして、次に再生するコンテンツのＵＲＬを渡すことによって、次コンテンツの再生を開始する（ステップＳ３２０）。
【０１１２】
以上、メイン・コントローラ１１０の動作について説明した。以下、コンテンツキャッシュ管理部１９０の動作について説明する。
【０１１３】
＜メインスレッド：図１４＞
まず、コンテンツキャッシュ管理部１９０の先読みスレッドの実行を開始する（ステップＳ４０２）。この処理については、図１５を参照しながら後述する。次に、他モジュール／スレッドからのリクエストメッセージを受信する（ステップＳ４０４）。リクエストメッセージを受信しない間は、ステップＳ４０４に戻る。リクエストメッセージを受信した場合は、メッセージの内容を判断する（ステップＳ４０８）。
【０１１４】
メッセージの内容が「プレイリスト通知」である場合は、プレイリスト通知のsong_list[ ]から第２コンテンツキャッシュＬ２に存在する曲を取り除き、コンテンツ先読み要求を作成する（ステップＳ４１０）。そして、先読みスレッドに対して、コンテンツ先読み要求を発行する（ステップＳ４１２）。この際のコンテンツ先読み要求内容は図１０（ｈ）に示したとおりである。
【０１１５】
一方、メッセージの内容が「コンテンツ要求」である場合は、まずsongテーブル中のidがreq_song_idと一致するレコードに対して、以下の操作を行う（ステップＳ４１４）。
play_date2 ← play_date1
play_date1 ← 現在日時
なお、ここで参照しているreq_song_idは、図１０（ｇ）のURLに含まれる <req_song_id> の文字列を数値に変換した値のことを意味している。
【０１１６】
続いて、要求されたコンテンツの全体が第２コンテンツキャッシュＬ２に存在するかを判断する（ステップＳ４１６）。そして、要求されたコンテンツの全体が第２コンテンツキャッシュＬ２に存在する場合には、キャッシュ再生スレッドの実行を開始する（ステップＳ４１８）。この動作については、図１８を参照しながら後述する。そして、ステップＳ４０４に戻る。一方、要求されたコンテンツの全体が第２コンテンツキャッシュＬ２に存在しない場合には、ダウンロード／オンザフライ再生スレッドの実行を開始する（ステップＳ４２０）。この動作については、図１９を参照しながら後述する。そして、ステップＳ４０４に戻る。
【０１１７】
＜先読みスレッド：図１５＞
上述した図１１のステップＳ４０２で起動している先読みスレッドについて、図１５を参照しながら説明する。まず、他モジュール／スレッドからのリクエストメッセージを受信する（ステップＳ５０２）。そして、リクエストメッセージを受信したかを判断する（ステップＳ５０４）。
【０１１８】
ステップＳ５０４でリクエストメッセージを受信した場合は、メッセージ内容を判断する（ステップＳ５０６）。メッセージ内容が「ダウンロード完了通知」である場合は、ダウンロードしたデータをchunk_id = cur_chunk_idのチャンクバッファに書き込む（ステップＳ５０８）。この動作は、図６、図７の図中（１）の動作に対応するものである。そして、後述するステップＳ５２６に進む。
【０１１９】
一方、メッセージ内容が「コンテンツ先読み要求」である場合は、まず、以下の処理を行い、次にダウンロードする曲のsong_list[ ] 中のインデックス値をnext_song_indexにセットする（ステップＳ５１０）。
next_song_index ← play_index
next_chunk_no ← 1
そして、コンテンツのチャンクデータをダウンロード中かを判断する（ステップＳ５１２）。ダウンロード中でない場合は、後述するステップＳ５２６に進む。ダウンロード中である場合は、先読み対象のコンテンツに変更があったかどうか確認するために、まず次ダウンロードチャンク決定処理を行う（ステップＳ５１４）。この処理については、図１６を参照しながら後述する。
【０１２０】
次に、next_song_id = cur_song_idかを判断し（ステップＳ５１６）、next_song_id = cur_song_idである場合は、さらにnext_chunk_id = cur_chunk_idかを判断し（ステップＳ５１８）、next_chunk_id = cur_chunk_idである場合は、先読み対象のコンテンツに変更がなかったものと判断してステップＳ５０２に戻る。ステップＳ５１６でnext_song_id = cur_song_idでない場合、又は、ステップＳ５１８でnext_chunk_id = cur_chunk_idでない場合は先読み対象のコンテンツに変更があったものと判断し、チャンクデータのダウンロードを中断する（ステップＳ５２０）。そして、ダウンロード中の中途半端なコンテンツデータが書き込まれている可能性があるchunk_id = cur_chunk_idのチャンクバッファをクリアする（ステップＳ５２２）。そして、後述するステップＳ５２６に進む。
【０１２１】
以上、ステップＳ５０４でリクエストメッセージを受信した場合について説明した。一方、ステップＳ５０４で、リクエストメッセージを受信しない場合は、チャンクデータのダウンロード中かを判断する（ステップＳ５２４）。チャンクデータのダウンロード中の場合は、ステップＳ５０２に戻る。チャンクデータのダウンロード中でない場合は、以下のステップＳ５２６に進む。
【０１２２】
ステップＳ５２６では、次ダウンロードチャンク決定処理を行う（ステップＳ５２６）。この処理については、図１６を参照しながら後述する。そして、ダウンロードするべきチャンクがあるかを判断する（ステップＳ５２８）。ダウンロードするべきチャンクがない場合は、ステップＳ５０２に戻る。ダウンロードするべきチャンクがある場合は、空きチャンクバッファ検索処理を行う（ステップＳ５３０）。この処理については、図１７を参照しながら後述する。
【０１２３】
続いて、空きチャンクバッファが見つかったかどうかを判断する（ステップＳ５３２）。空きチャンクバッファが見つからなかった場合は、ステップＳ５０２に戻る。空きチャンクバッファが見つかった場合は、チャンクデータのダウンロードを開始する（ステップＳ５３４）。この際のダウンロード要求内容は図１０（ｊ）に示したとおりである。そして、次の処理を行い（ステップＳ５３６）、現在ダウンロード中のコンテンツのsong_idとchunk_noをcur_song_id/cur_chunk_noに保存しておく。
cur_song_id ← next_song_id
cur_chunk_no ← next_chunk_no
【０１２４】
＜次ダウンロードチャンク決定処理：図１６＞
上記ステップＳ５１４、ステップＳ５２６から呼び出している次ダウンロードチャンク決定処理のサブルーチンについて、図１６を参照しながら説明する。
【０１２５】
まず、next_song_id ← song_list[next_song_index] とすることにより、次にダウンロードする曲のsong_idをnext_song_idにセットする（ステップＳ６０２）。そして、Ｌ１キャッシュ管理テーブル１６２を検索して、song_id = next_song_id, chunk_no = next_chunk_noの条件を満たすチャンクが存在するかどうかを検索する（ステップＳ６０４）。なお、ここで参照しているnext_song_indexとは、ステップＳ５１０で値を設定したnext_song_index の事を指している。またsong_list[ ] は図１０（ｈ）のパラメータsong_list[ ] の事を指している。
【０１２６】
続いて、条件に合ったチャンクが存在するかどうかを判断する（ステップＳ６０６）。チャンクが存在しなかった場合には、次にダウンロードするべきチャンクはnext_song_idとnext_chunk_noに対応するチャンクであると判断して、このサブルーチンから元のステップ（ステップＳ５１４又はステップＳ５２６）に戻る。もしチャンクが存在した場合には、同じコンテンツの次のチャンクに進めるために、chunk_no ← chunk_no + 1とする（ステップＳ６０８）。
【０１２７】
そして、コンテンツの終端に達したかどうかを判断する（ステップＳ６１０）。コンテンツの終端に達していない場合には、ステップＳ６０４に戻る。コンテンツの終端に達した場合には、プレイリスト中の次に再生するコンテンツに進めるために、以下の処理を行う（ステップＳ６１２）。
next_song_index ← next_song_index + 1
next_chunk_no ← 1
【０１２８】
そして、song_list[ ]に次の曲があるかを判断する（ステップＳ６１４）。次の曲がある場合は、ステップＳ６０２に戻る。もし次の曲がない場合は、これ以上ダウンロードするべきチャンクが無いと判断して、次ダウンロードチャンク決定処理の実行結果としてnext_song_id = 0を返す（ステップＳ６１６）。
【０１２９】
＜空きチャンクバッファ検索処理：図１７＞
上記ステップＳ５３０から呼び出している空きチャンクバッファ検索処理のサブルーチンについて、図１７を参照しながら説明する。
【０１３０】
まず、Ｌ１キャッシュ管理テーブル１６２の中から、未使用のチャンクバッファを探す（ステップＳ７０２）。そして、未使用のチャンクバッファがあるかどうかを判断する（ステップＳ７０４）。未使用のチャンクバッファがある場合は、発見した未使用のチャンクバッファのchunk_idを返す（ステップＳ７０６）。そして、サブルーチンを終了し元のステップ（ステップＳ５３０）に戻る。
【０１３１】
一方、ステップＳ７０４で未使用のチャンクバッファが無い場合は、Ｌ１キャッシュ管理テーブル１６２の中から、先読みコンテンツリストに含まれていないコンテンツに属すチャンクを抽出して、該当するチャンクバッファのchunk_idをchunk_id_list[ ]の配列に格納する（ステップＳ７０８）。そして、chunk_id_list[ ]は空かどうかを判断する（ステップＳ７１０）。そして、chunk_id_list[ ]が空でない場合は、後述するステップＳ７２８に進む。
【０１３２】
ステップＳ７１０でchunk_id_list[ ]が空の場合は、Ｌ１キャッシュ管理テーブル１６２の中から、再生済みのコンテンツに属すチャンクを抽出して、該当するチャンクバッファのchunk_idをchunk_id_list[ ]の配列に格納する（ステップＳ７１２）。そして、chunk_id_list[ ]は空かどうかを判断する（ステップＳ７１４）。そして、chunk_id_list[ ]が空でない場合は、後述するステップＳ７３０に進む。なお、ここで言う再生済みのコンテンツとは、図１０（ｈ）の例では次に再生する曲が２曲目（play_index=2）であるため、song_list[ ] 中の１曲目の曲（song_id=1）のみが再生済みのコンテンツに該当する。
【０１３３】
一方、ステップＳ７１４でchunk_id_list[ ]が空の場合は、Ｌ１キャッシュ管理テーブル１６２の中から、未再生のコンテンツに属し、次ダウンロードチャンクよりも再生順が後のチャンクを抽出して、該当するチャンクバッファのchunk_idをchunk_id_list[ ]の配列に格納する（ステップＳ７１６）。そして、chunk_id_list[ ]は空かどうかを判断する（ステップＳ７１８）。chunk_id_list[ ]が空でない場合は、後述するステップＳ７３０に進む。なお、ここで言う未再生のコンテンツとは、図１０（ｈ）の例では次に再生する曲が２曲目（play_index=2）であるため、song_list[ ] 中の３曲目以降の全ての曲が未再生のコンテンツに該当する。また次にダウンロードするチャンクがどれであるかは、次にダウンロードする曲のsong_idを保持しているnext_song_idと、次にダウンロードするチャンク番号を保持しているnext_chunk_noを参照することにより知ることができる。
【０１３４】
ステップＳ７１８でchunk_id_list[ ]が空の場合は、次ダウンロードチャンクが再生中のコンテンツかどうかを判断する。この判断は、具体的にはnext_song_idとreq_song_idの値が等しいかどうかによって判定することができる。なおreq_song_idはステップＳ４１４で取得した値に対応している（ステップＳ７２０）。次ダウンロードチャンクが再生中のコンテンツである場合は、Ｌ１キャッシュ管理テーブル１６２の中から、再生中のコンテンツに属し、usedフィールドが“1”のチャンクを抽出して、該当するチャンクバッファのchunk_idをchunk_id_list[ ]の配列に格納する（ステップＳ７２２）。そして、chunk_id_list[ ]は空かどうかを判断する（ステップＳ７２４）。chunk_id_list[ ]が空でない場合は、後述するステップＳ７３０に進む。
【０１３５】
上記ステップＳ７２０で次ダウンロードチャンクが再生中のコンテンツでない場合又は上記ステップＳ７２４でchunk_id_list[ ]が空の場合は、空きチャンクの検索結果として“0”（空きチャンクバッファ無し）を返す（ステップＳ７２６）。そして、サブルーチンを終了し元のステップ（ステップＳ５３０）に戻る。
【０１３６】
以上、ステップＳ７０８／Ｓ７１２／Ｓ７１６／Ｓ７２２のいずれの検索時にも、利用可能なチャンクバッファで見つからなかった場合について説明した。一方、ステップＳ７０８／Ｓ７１２／Ｓ７１６／Ｓ７２２のいずれかの検索時に、利用可能なチャンクバッファで見つかった場合には、以下の動作を行う。
【０１３７】
まず、ステップＳ７０８の検索時に利用可能なチャンクバッファで見つかった場合には、chunk_id_list[ ]の中で、write_dateが最も古いチャンクを探し、そのsong_idをtarget_song_idにセットする（ステップＳ７２８）。これによりＬ１キャッシュ内にキャッシュデータが存在するコンテンツの中で、最も過去に再生したコンテンツのsong_id がtarget_song_idにセットされる。そして、後述するステップＳ７３４に進む。
【０１３８】
また、ステップＳ７１２／Ｓ７１６／Ｓ７２２の検索時に利用可能なチャンクバッファで見つかった場合には、Ｌ１キャッシュ管理テーブルを参照して chunk_id_list[ ] に収められている各chunk_idの値をsong_idに変換して重複データを削除した結果をsong_id_list[] に格納する（ステップＳ７３０）。そして、song_id_list[] の中からダウンロード中のコンテンツからダウンロード順が最も離れているsong_idをtarget_song_idにセットする（ステップＳ７３２）。そして、ステップＳ７３４に進む。
【０１３９】
ステップＳ７３４では、chunk_id_list[ ]の中からsong_idがtarget_song_idに一致するチャンクを抽出し、その中でchunk_noが最も大きなチャンクのchunk_idをfree_chunk_idにセットする（ステップＳ７３４）。これにより、Ｌ１キャッシュ内において最も過去に再生したコンテンツを構成するチャンクデータの中で、コンテンツ中の最後端のチャンクの chunk_idがfree_chunk_idにセットされることになる。
【０１４０】
次に、Ｌ１キャッシュ管理テーブルの中で、free_chunk_idに対応するレコードをクリアして（ステップＳ７３６）、さらにＬ１キャッシュチャンクバッファの中でfree_chunk_idに対応するチャンクバッファをクリアすることで、見つけたチャンクバッファを空きチャンクとして利用できるようにする（ステップＳ７３８）。次に、空きチャンクの検索結果としてfree_chunk_idを返す（ステップＳ７４０）。そして、サブルーチンを終了し、元のステップ（ステップＳ５３０）に戻る。
【０１４１】
このように空きチャンクバッファの検索処理を順次行うことにより、結果的に以下の優先順位で空きチャンクバッファの検索が行われることになる。
優先度１：未使用のチャンクバッファ
優先度２：先読みコンテンツリストに含まれていないコンテンツに対応するチャンクバッファ
優先度３：先読みコンテンツリストに含まれている再生済みのコンテンツに対応するチャンクバッファ
優先度４：先読みコンテンツリストに含まれている未再生のコンテンツに対応するチャンクバッファの中で、次ダウンロードチャンクよりも再生順が後のチャンクバッファ
優先度５：再生中のコンテンツに対応するチャンクバッファの中で、コンテンツ要求に対する応答としてチャンクデータを送出済みのチャンクバッファ（但し優先度５に対する検索は、次ダウンロードチャンクが現在再生中のコンテンツの場合のみ行う）
【０１４２】
ここで優先度５の判定は、曲の長さが非常に長く、１曲分のコンテンツデータ全体がＬ１キャッシュに収まりきらないような場合に、先読みしたコンテンツデータがＬ１キャッシュチャンクバッファを埋めつくしてしまい、それ以上コンテンツの先読みが行えなくなり、結果としてＬ１キャッシュのサイズを越えるコンテンツが再生不能となってしまうことを防止するために用意されたものである。
【０１４３】
＜キャッシュ再生スレッド：図１８＞
上記ステップＳ４１８で説明したキャッシュ再生スレッドについて、図１８を参照しながら説明する。要求されたコンテンツを第２コンテンツキャッシュＬ２から読み出して、コンテンツ要求に対する応答として送出する（ステップＳ８１２）。この動作は、図８の図中（４）の動作に対応する。
【０１４４】
＜ダウンロード／オンザフライ再生スレッド：図１９＞
上記ステップＳ４２０で説明したダウンロード／オンザフライ再生スレッドについて、図１９を参照しながら説明する。まず、play_chunk_no ← 1とする（ステップＳ９０２）。そして、play_chunk_no = 1かどうかを判断する（ステップＳ９０４）。play_chunk_no = 1でない場合は、後述するステップＳ９１０に進む。play_chunk_no = 1である場合は、req_song_idに対応するデータがＬ２−Ｈキャッシュ（図４参照）に存在するかどうかを判断する（ステップＳ９０６）。req_song_idに対応するデータがＬ２−Ｈキャッシュに存在しない場合は、後述するステップＳ９１０に進む。req_song_idに対応するデータがＬ２−Ｈキャッシュに存在する場合は、Ｌ２−Ｈキャッシュからコンテンツ先頭部分のデータを読み出して、コンテンツ要求に対する応答として送出する（ステップＳ９０８）。そして、後述するステップＳ９２２に進む。
【０１４５】
上述したステップＳ９１０では、Ｌ１キャッシュ管理テーブル１６２を検索して、song_id = req_song_id、chunk_no = play_chunk_noのチャンクを探し、見つけたchunk_idをplay_chunk_idにセットする（ステップＳ９１０）。そして、チャンクが見つかったかどうかを判断する（ステップＳ９１２）。もしチャンクが見つからなかった場合には、ステップＳ９１０に戻る。チャンクが見つかった場合は、play_chunk_no = 1かどうかを判断する（ステップＳ９１４）。
【０１４６】
play_chunk_no = 1でない場合は、ステップＳ９１８に進む。play_chunk_no = 1の場合は、Ｌ２−Ｈキャッシュへの書き込み処理を行う（ステップＳ９１６）。この動作については、図２０を参照しながら後述する。そして、ステップＳ９１８に進む。ステップＳ９１８では、play_chunk_idに対応するチャンクデータを、コンテンツ要求に対する応答として送出する（ステップＳ９１８）。この動作は、図６、図７の図中（２）の動作に対応する。そして、Ｌ１キャッシュ管理テーブル１６２の中でplay_chunk_idに対応するレコードのusedフィールドを1にセットする（ステップＳ９２０）。
【０１４７】
上述したＳ９２２では、応答データの送出時にエラーが発生したかを判断する（ステップＳ９２２）。エラーが発生した場合は、サブルーチンを終了して元のステップに戻る。エラーが発生していない場合は、chunk_no ← chunk_no + 1とする（ステップＳ９２４）。そして、１曲分の全チャンクの送出が完了したかを判断する（ステップＳ９２６）。１曲分の全チャンクの送出が完了していない場合は、ステップＳ９０４に戻る。１曲分の全チャンクの送出が完了した場合は、Ｌ２−Ｅキャッシュ書き込み処理を行う（ステップＳ９２８）。この動作については、図２１を参照しながら後述する。そして、サブルーチンを終了して元のステップに戻る。
【０１４８】
なお、ダウンロード再生動作とオンザフライ再生動作の切り替えは、Ｌ２−Ｈキャッシュ書き込み処理又はＬ２−Ｅキャッシュ書き込み処理において、コンテンツサーバからダウンロードしたコンテンツデータを第１コンテンツキャッシュＬ１から第２コンテンツキャッシュＬ２にコピーするかどうかによって、ダウンロード再生とオンザフライ再生のいずれかが選択される。
【０１４９】
＜Ｌ２−Ｈキャッシュ書き込み処理：図２０＞
図１９のステップＳ９１６から呼び出しているＬ２−Ｈキャッシュ書き込み処理のサブルーチンについて、図２０を参照しながら説明する。まず、再生中コンテンツの先頭チャンクがＬ２−Ｈキャッシュの空き容量に収まるかを判断する（ステップＳ１００２）。空き容量に収まる場合には、ステップＳ１０１６に進む。空き容量に収まらない場合は、以下の処理を行う。
【０１５０】
まず、再生中のコンテンツの再生頻度値（又は再生確率予想値）（score）を算出する（ステップＳ１００４）。この動作については、図２２を参照しながら後述する。そして、Ｌ２−Ｈキャッシュに存在する全コンテンツの中で、再生中のコンテンツよりもscoreが低い全てのコンテンツを抽出して、抽出したコンテンツのsong_id/score/filesizeの組をdelete_candidate[ ]の配列に格納する（ステップＳ１００６）。次に、delete_candidate[ ]の内容をscoreの低い順にソートする（ステップＳ１００８）。そして、delete_candidate[ ]の先頭から何曲分を削除すれば、再生中のコンテンツの先頭部分をＬ２−Ｈキャッシュに保存可能なのかを求め、削除が必要なコンテンツのsong_idをdelete_song_id[ ]に格納する（ステップＳ１０１０）。
【０１５１】
次に、delete_candidate[ ]の全曲を削除してもＬ２−Ｈキャッシュに収まらないかを判断する（ステップＳ１０１２）。Ｌ２−Ｈキャッシュに収まらない場合は、サブルーチンを終了して、元のステップ（ステップＳ９１６）に戻る。Ｌ２−Ｈキャッシュに収まる場合は、delete_song_id[ ]で指定されるコンテンツをＬ２−Ｈキャッシュから削除する（ステップＳ１０１４）。そして、ステップＳ１０１６に進む。
【０１５２】
上述したステップＳ１０１６では、第１コンテンツキャッシュＬ１から再生中のコンテンツの先頭チャンクのみを読み出して、Ｌ２−Ｈキャッシュに書き込む（ステップＳ１０１６）。この動作は、図７の図中（３）の動作に対応する。最終的にＬ２−Ｈキャッシュ書き込み処理においてステップＳ１０１６を実行した場合には、ダウンロード再生動作を行ったことになる。あるいは逆にステップＳ１０１６を実行しなかった場合には、オンザフライ再生動作を行ったことになる。
【０１５３】
＜Ｌ２−Ｅキャッシュ書き込み処理：図２１＞
図１９のステップＳ９２８から呼び出しているＬ２−Ｅキャッシュ書き込み処理のサブルーチンについて、図２１を参照しながら説明する。まず、再生中のコンテンツの全体がＬ２−Ｅキャッシュの空き容量に収まるかを判断する（ステップＳ１１０２）。空き容量に収まる場合には、ステップＳ１１１６に進む。空き容量に収まらない場合は、以下の処理を行う。
【０１５４】
まず、再生中のコンテンツの再生頻度値（又は再生確率予想値）（score）を算出する（ステップＳ１１０４）。この動作については、図２２を参照しながら後述する。そして、Ｌ２−Ｅキャッシュに存在する全コンテンツの中で、再生中のコンテンツよりもscoreが低い全てのコンテンツを抽出して、抽出したコンテンツのsong_id/score/filesizeの組をdelete_candidate[ ]の配列に格納する（ステップＳ１１０６）。次に、delete_candidate[ ]の内容をscoreの低い順にソートする（ステップＳ１１０８）。そして、delete_candidate[ ]の先頭から何曲分を削除すれば、再生中のコンテンツをＬ２−Ｅキャッシュに保存可能なのかを求め、削除が必要なコンテンツのsong_idをdelete_song_id[ ]に格納する（ステップＳ１１０８）。
【０１５５】
次に、delete_candidate[ ]の全曲を削除してもＬ２−Ｅキャッシュに収まらないかを判断する（ステップＳ１１１２）。Ｌ２−Ｅキャッシュに収まらない場合は、サブルーチンを終了して、元のステップ（ステップＳ９２８）に戻る。Ｌ２−Ｅキャッシュに収まる場合は、delete_song_id[ ]で指定されるコンテンツをＬ２−Ｅキャッシュから削除する（ステップＳ１１１４）。そして、ステップＳ１１１６に進む。
【０１５６】
上述したステップＳ１１１６では、第１コンテンツキャッシュＬ１から再生中のコンテンツに対応する全てのチャンクデータを読み出し、それらを結合したデータをＬ２−Ｅキャッシュに書き込む（ステップＳ１１１６）。この動作は、図７の図中（３）の動作に対応する。最終的にＬ２−Ｅキャッシュ書き込み処理においてステップＳ１１１６を実行した場合には、ダウンロード再生動作を行ったことになる。あるいは逆にステップＳ１１１６を実行しなかった場合には、オンザフライ再生動作を行ったことになる。
【０１５７】
＜コンテンツ再生頻度値の算出処理：図２２＞
上述したコンテンツ再生頻度値の算出処理のサブルーチンについて、図２２を参照しながら説明する。まず、now_date に現在日時をセットする（ステップＳ１２０２）。
now_date ← 現在日時
そして、play_date2に日付情報が存在するかを判断する（ステップＳ１２０４）。play_date2に日付情報が存在しない場合には、score ← -1とする（ステップＳ１２０６）。そして、後述するステップＳ１２１２に進む。
【０１５８】
一方、play_date2に日付情報が存在する場合は、次の処理を行う（ステップＳ１２０８、Ｓ１２１０）。
diff ← max(play_date1- play_date2, now_date - play_date1)
score ← max(365 - diff, 0) / 365 * 100
そして、ステップＳ１２１２に進む。
【０１５９】
ステップＳ１２１２では、scoreの値を返す（ステップＳ１２１２）。そして、サブルーチンを終了し、元のステップに戻る。
【０１６０】
＜コンテンツ再生頻度値更新処理スレッド：図２３＞
上述した図１１のステップＳ１１０で起動しているコンテンツ再生頻度値更新処理スレッドについて、図２３を参照しながら説明する。まず、id ← 1とする（ステップＳ１３０２）。そして、Ｌ２−Ｈキャッシュ管理テーブルからidに対応するレコードを取り出して、そのsong_idを得る（ステップＳ１３０４）。
【０１６１】
次に、song_idが空かを判断する（ステップＳ１３０６）。song_idが空の場合は、後述するステップＳ１３１６に進む。song_idが空でない場合は、コンテンツデータベース１７０のsongテーブルからidがsong_idと一致するレコードを見つけて、そのコンテンツの再生履歴情報を得る（ステップＳ１３０８）。そして、play_date2に日付情報が存在するかを判断する（ステップＳ１３１０）。play_date2に日付情報が存在しない場合は、ただちに後述するステップＳ１３１６に進む。
【０１６２】
play_date2に日付情報が存在する場合は、コンテンツの再生頻度値（score）を算出する（ステップＳ１３１２）。そして、このレコードのscoreフィールドを更新する（ステップＳ１３１４）。そして、ステップＳ１３１６に進む。
【０１６３】
ステップＳ１３１６では、id ← id + 1とする（ステップＳ１３１６）。そして、全レコードの処理が完了したかを判断する（ステップＳ１３１８）。全レコードの処理が完了していない場合は、ステップＳ１３０４に戻る。全レコードの処理が完了した場合は、Ｌ２−Ｅキャッシュ管理テーブルについても、上記と同様の処理を行う。
【０１６４】
以上、コンテンツキャッシュ管理部１９０の動作について説明した。以下、コンテンツデータベース更新部１８０の動作について説明する。
【０１６５】
＜コンテンツデータベース１７０の更新処理スレッド：図２４＞
コンテンツデータベース１７０の更新処理スレッドについて、図２４を参照しながら説明する。まず、メインメモリ上にartist_exist[ ]、album_exist[ ]、song_exist[ ]の配列を確保する（ステップＳ１４０２）。そして、artist_exist[ ]、album_exist[ ]、song_exist[ ]を0にクリアする（ステップＳ１４０４）。
【０１６６】
以下順に、ディレクトリ検索処理（検索対象＝ルートディレクトリ）（ステップＳ１４０６）、不要レコード削除処理：artistテーブル（ステップＳ１４０８）、不要レコード削除処理：albumテーブル（ステップＳ１４１０）、不要レコード削除処理：songテーブル（ステップＳ１４１２）を行う。これら処理については、図２６〜図２８を参照しながら後述する。最後に、artist_exist[ ]、album_exist[ ]、song_exist[ ]を解放する（ステップＳ１４１４）。
【０１６７】
＜ディレクトリ検索処理：図２５＞
ディレクトリ検索処理について、図２５を参照しながら説明する。
まず、検索対象のディレクトリに存在するファイル／ディレクトリの検索を開始する（ステップＳ１５０２）。そして、次のファイル名又はディレクトリ名を得る（ステップＳ１５０４）。そして、見つけたのはファイルだったかどうかを判断する（ステップＳ１５０６）。見つけたのがファイルではなくディレクトリであった場合には、そのディレクトリに対してディレクトリ検索処理を再帰呼出しにより実行する（ステップＳ１５０８）。見つけたのがファイルである場合は、以下の処理に進む。
【０１６８】
まず、コンテンツファイルの内容を読み出して、artist/album/title/tracknoを得る（ステップＳ１５１０）。次にコンテンツファイルから取得したartistが新規アーティストかどうかを判断する（ステップＳ１５１２）。もし新規アーティストである場合は、artistテーブルに新規レコードを追加して、追加したレコードのidをartist_idにセットする（ステップＳ１５１４）。新規アーティストでない場合は、artistテーブルを検索して、アーティスト名が一致するレコードを探し、そのartist_idを得る（ステップＳ１５１６）。その後、artist_exist[artist_id] ← 1とする（ステップＳ１５１８）。
【０１６９】
次に、コンテンツファイルから取得したalbumが新規アルバムかどうかを判断する（ステップＳ１５２０）。もし新規アルバムである場合は、albumテーブルに新規レコードを追加して、追加したレコードのidをalbum_idにセットする（ステップＳ１５２２）。新規アルバムでない場合は、albumテーブルを検索して、artist_idとアルバム名が一致するレコードを探し、そのalbum_idを得る（ステップＳ１５２４）。その後、album_exist[album_id] ← 1とする（ステップＳ１５２６）。
【０１７０】
次に、コンテンツファイルから取得したtitleが新規の曲かどうかを判断する（ステップＳ１５２８）。もし新規の曲である場合は、songテーブルに新規レコードを追加して、追加したレコードのidをsong_idにセットする（ステップＳ１５３０）。新規の曲でない場合は、aongテーブルを検索して、artist_id/album_idとタイトルが一致するレコードを探し、そのsong_idを得る（ステップＳ１５３２）。その後、song_exist[song_id] ← 1とする（ステップＳ１５３４）。
【０１７１】
最後に、ディレクトリの検索が終了したかを判断する（ステップＳ１５３６）。ディレクトリの検索が終了していない場合は、ステップＳ１５０４に戻る。ディレクトリの検索が終了した場合は、サブルーチンを終了して、元のステップに戻る。
【０１７２】
＜不要レコード削除処理：artistテーブル：図２６＞
図２４のステップＳ１４０８から呼び出しているartistテーブルの不要レコード削除処理のサブルーチンについて、図２６を参照しながら説明する。
まず、id ← 1とする（ステップＳ１６０２）。そして、artist_exist[id] = 0かどうかを判断する（ステップＳ１６０４）。artist_exist[id] = 0でない場合は、ただちにステップＳ１６０８に進む。artist_exist[id] = 0の場合は、artistテーブルのidに対応するレコードをクリアし（ステップＳ１６０６）、ステップＳ１６０８に進む。
【０１７３】
ステップＳ１６０８では、id ← id + 1とする（ステップＳ１６０８）。最後に、全レコードの処理が完了したかを判断する（ステップＳ１６１０）。全レコードの処理が完了していない場合は、ステップＳ１６０４に戻る。全レコードの処理が完了した場合は、サブルーチンを終了して、元のステップ（ステップＳ１４０８）に戻る。
【０１７４】
＜不要レコード削除処理：albumテーブル：図２７＞
図２４のステップＳ１４１０から呼び出しているalbumテーブルの不要レコード削除処理のサブルーチンについて、図２７を参照しながら説明する。
まず、id ← 1とする（ステップＳ１７０２）。そして、album_exist[id] = 0かどうかを判断する（ステップＳ１７０４）。album_exist[id] = 0でない場合は、ただちにステップＳ１７０８に進む。album_exist[id] = 0の場合は、albumテーブルのidに対応するレコードをクリアし（ステップＳ１７０６）、ステップＳ１７０８に進む。
【０１７５】
ステップＳ１７０８では、id ← id + 1とする（ステップＳ１７０８）。最後に、全レコードの処理が完了したかを判断する（ステップＳ１７１０）。全レコードの処理が完了していない場合は、ステップＳ１７０４に戻る。全レコードの処理が完了した場合は、サブルーチンを終了して、元のステップ（ステップＳ１４１０）に戻る。
【０１７６】
＜不要レコード削除処理：songテーブル：図２８＞
図２４のステップＳ１４１２から呼び出しているsongテーブルの不要レコード削除処理のサブルーチンについて、図２８を参照しながら説明する。
まず、id ← 1とする（ステップＳ１８０２）。そして、song_exist[id] = 0かどうかを判断する（ステップＳ１８０４）。song_exist[id] = 0でない場合は、ただちにステップＳ１８０８に進む。song_exist[id] = 0の場合は、songテーブルのidに対応するレコードをクリアし（ステップＳ１８０６）、ステップＳ１８０８に進む。
【０１７７】
ステップＳ１８０８では、id ← id + 1とする（ステップＳ１８０８）。最後に、全レコードの処理が完了したかを判断する（ステップＳ１８１０）。全レコードの処理が完了していない場合は、ステップＳ１８０４に戻る。全レコードの処理が完了した場合は、サブルーチンを終了して、元のステップ（ステップＳ１４１２）に戻る。
【０１７８】
（第１の実施形態の効果）
以上説明したように、本実施形態によれば、コンテンツの再生頻度に応じて自動的にオンザフライ再生とダウンロード再生を切り替えることにより、あるときたまたま再生頻度の低いコンテンツを再生したことにより、より再生頻度の高いコンテンツをコンテンツキャッシュ部１６０から削除してしまうという事態を防止できる。その結果、コンテンツキャッシュ部１６０のヒット率が向上し、通信データ量をより節約できるようになる。このようにして、クラウド型音楽再生アプリの使い勝手を高めたコンテンツ再生装置１００とすることができる。
【０１７９】
また、たまたま久しぶりに再生したが、しばらくの間は聞きそうもない楽曲のデータをコンテンツキャッシュ部１６０に保存することを防止することができるので、書き換え回数に制限のあるメモリ（例えば、ＮＡＮＤ−Ｆｌａｓｈメモリ）に対する書き込み回数を抑制することができる（なお、モバイル端末は内蔵ＮＡＮＤ−Ｆｌａｓｈメモリの寿命を迎えると、故障状態となり使用不可となってしまう。）。その結果として、モバイル端末の利用可能年数を延ばすことができる。
【０１８０】
以上説明したコンテンツ再生装置１００は、コンピュータにプログラムを適用することにより、コンピュータをコンテンツ再生装置１００として機能させることができる。このコンピュータプログラムは、任意の記録媒体に記録された形で市場を流通させることができるほか、ネットワークを介したダウンロードやその他の形で市場を流通させることができる。
【０１８１】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。本実施形態では、上記第１の実施形態と異なる点を中心に説明するものとし、上記第１の実施形態と実質的に同様の内容については、同一の参照符号を付することにより、重複説明を省略する。
【０１８２】
上記第１の実施形態では、コンテンツの再生頻度に基づいて、ダウンロード再生を行うか、あるいは、オンザフライ再生を行うかを判断していた。本実施形態では、この判断のために、コンテンツが再び再生される確率の予想値（再生確率予想値）を利用することを特徴とする。以下では、再生確率予想値の一例として、各コンテンツの再生頻度に加えて、コンテンツがコンテンツサーバ１０に登録された日時（コンテンツ鮮度情報）に基づいて判断する場合について説明する。
【０１８３】
本実施形態の再生確率予想情報は、上記第１の実施形態の再生頻度情報をさらに発展させた内容である。図５（ｄ）に示したsongテーブルの構造の中に「write_date」、「play_date1」、「play_date2」というフィールドが存在している。「write_date」はそのコンテンツがコンテンツサーバに登録された日時（コンテンツ鮮度情報）を保持している。したがって、すべてのコンテンツの「write_date」フィールドには有効値が書き込まれている。一方、コンテンツがコンテンツサーバ１０に登録された時点では、「play_date1」と「play_date2」フィールドの内容は空である。あるコンテンツを再生すると、「play_date1」の内容が「play_date2」にコピーされ、再生時点の日時が「play_date1」に書き込まれる。したがって、コンテンツサーバ１０に登録されたコンテンツを初めて再生したときには、「play_date1」にのみ有効値が書き込まれていて、「play_date2」は空となる。
【０１８４】
上記第１の実施形態１では再生頻度情報は、
・一度も再生したことがないコンテンツ：score＝−１
・初めて再生したコンテンツ：score＝−１
・２回以上再生したコンテンツ：score＝１００〜０
と計算されることになる。よって、上記第１の実施形態では、再生頻度情報を算出することが可能な、２回以上再生したことのあるコンテンツに関しては、より再生頻度が高いコンテンツを優先してコンテンツキャッシュ部１６０に保存する動作を実現することができる。
【０１８５】
しかし、ある新しいコンテンツ（音楽の場合で言えば新譜）がコンテンツサーバ１０に新規登録され、その後そのコンテンツを初めて再生した場合には、score値が最低の−１と算出されることになる。よって、そのコンテンツのscore値は、コンテンツサーバ１０に登録されている中で、再生頻度を求めることが可能などんな古いコンテンツよりもscore値が上回ることがないので、結果的に新しいコンテンツを初めて再生したときには、決してコンテンツキャッシュ部１６０に保存されることがなく、そのコンテンツを２回目に再生したときになってやっとコンテンツキャッシュ部１６０に保存されることとなる。このため、限りある通信帯域を無駄に消費してしまうおそれがある。
【０１８６】
この点、本実施形態の再生確率予想値は、以下のプログラムにより計算される。scoreの値が再生確率を示し、値が大きいほど再生確率が高いことを意味する。
if play_date2 != ""
then 
diff = max(play_date1 - play_date2, now_date - play_date1)
score = max(365 - diff, 0) / 365 * 100
else 
score = -1
diff = now_date - write_date
bonus = max(30 - diff, 0) / 30 * 100
score = score + bonus
【０１８７】
このbonusの値はscoreの値に加算されるボーナス分のスコアであり、新しいコンテンツがコンテンツサーバ１０に登録された日時「write_date」と、現在日時「now_date」の日数差に応じて計算される＋１００〜０の値である。あるコンテンツがコンテンツサーバ１０に登録されてから３０日以内にそのコンテンツを再生した場合には、「write_date」と「now_date」の日数差に応じたボーナス値が算出される。ボーナスの値はコンテンツの新規登録された時点では１００であり、そこから日数が経過するにつれてボーナス値が低下していき、３０日が経過した時点でボーナス値は０となる。
【０１８８】
このように本実施形態では、ボーナス値が発生する期間を３０日と設定しているが、このことは、新コンテンツに関しては、コンテンツサーバへの登録後１ヶ月以内であれば、まだ一度しか再生履歴がなくとも再生確率値scoreがプラスの値となるため、コンテンツキャッシュ部１６０に保存される可能性が高くなる。しかし、新しいコンテンツの登録後、１ヶ月が経過しても再生履歴が１度しかなかったような場合には、ボーナス値の加算はなくなる。これによりユーザが一度だけ再生して、その後繰り返し再生されることのなかったコンテンツ（これはおそらくユーザの好みに合わず、リピート再生する意欲をなくしたコンテンツであると考えられる）を、いつまでもコンテンツキャッシュ部１６０に残しておくことを防止することができる。結果的に、コンテンツキャッシュ部１６０の限りある容量を有効に活用することが可能となる。
【０１８９】
次に、従来技術との差異について説明する。従来技術では、コンテンツキャッシュが満杯になってしまった場合に、コンテンツキャッシュにコンテンツを書き込んだ日時に基づいて、削除するべきコンテンツを決定していた。
【０１９０】
一方、本実施形態においては、コンテンツキャッシュ部１６０の満杯時に削除するべきコンテンツを選択する際に、各コンテンツの再生頻度に加えて、コンテンツがコンテンツサーバ１０に登録された日時（コンテンツ鮮度情報）を判断条件として利用することに特徴がある。例えばある新曲がリリースされ、そのコンテンツデータがコンテンツサーバ１０に追加されたとする。このとき、コンテンツデータベース１６０のsongテーブル（図５（ｄ））には、その新曲を示すレコード（テーブルにおける１行分のデータ）が追加され、そのレコードの「write_date」にはそのコンテンツの登録日時が書き込まれる。また「play_date1」と「play_date2」は空欄のままとなる。
【０１９１】
次にこの新曲の再生を指示すると、そのときの日時が「play_date1」に書き込まれる。本実施形態では、各コンテンツの再生頻度として「play_date1」と「play_date2」の差分及び「now_date」と「play_date1」の差分を比較して、大きな方の差分値から計算した値を利用している。しかし、新曲を初めて再生した場合には「play_data2」には有効な値が書き込まれていないため、その曲の再生頻度を求めることができない。第１の実施形態では、再生頻度を計算することができないコンテンツについては、「再生頻度＝最低」として取り扱っている。これはあるとき初めて再生したコンテンツが、後日その曲を何度も繰り返し再生する可能性が高いかどうかの判断が付かないからである。
【０１９２】
このように再生頻度が求められないコンテンツを「再生頻度＝低」として取り扱うことで、あるときたまたま気が向いて再生した旧譜（またすぐにその曲を再生する可能性は低い）をコンテンツキャッシュ部１６０に書き込んでしまうことによる悪影響を回避することができる反面、ある新曲を初めて再生した時にその曲をコンテンツキャッシュ部１６０に書き込むことができなくなってしまう。一般的に新曲は旧譜よりも繰り返し再生する可能性が高いと考えられるので、コンテンツキャッシュ部１６０のヒット率を高めるためには、ある新曲を初めて再生したときにその曲データをコンテンツキャッシュ部１６０に書き込む動作を行うことが望ましい。
【０１９３】
第２の実施形態においては、再生対象曲の「play_date2」が空欄の場合には、「write_date」と「now_date」の値から新譜度合い値を求め、再生頻度値と新譜度合い値を元に再生確率予想値を算出し、新規再生曲とコンテンツキャッシュ部１６０内の楽曲の再生確率予想値を比較する機能を搭載することによって、初めて再生した新曲をコンテンツキャッシュ部１６０に書き込むような動作を実現している。
【０１９４】
（第２の実施形態の動作）
次に、本実施形態の動作について、主に図２９、図３０を参照しながら説明する。
本実施形態の動作は、上記第１の実施形態の動作（図９〜図２８）と以下の点で異なり、その他の点では同様とすることができる。すなわち、本実施形態では、上記第１の実施形態のコンテンツ再生頻度値の算出処理（図２２）に代えて、図２９に示すコンテンツ再生確率予想値の算出処理を行う。また、上記第１の実施形態のコンテンツ再生頻度値更新処理スレッド（図２３）に代えて、図３０に示すコンテンツ再生確率予想値更新処理スレッドを実行する。以下、順に説明する。
【０１９５】
＜コンテンツ再生確率予想値の算出処理：図２９＞
コンテンツ再生確率予想値の算出処理について、図２９を参照しながら説明する。まず、now_date に現在日時をセットする（ステップＳ１９０２）。そして、play_date2に日付情報が存在するかを判断する（ステップＳ１９０４）。play_date2に日付情報が存在しない場合には、score に -1をセットする（ステップＳ１９０６）。そして、後述するステップＳ１９１６に進む。
【０１９６】
一方、play_date2に日付情報が存在する場合は、次の処理を行う（ステップＳ１９０８、Ｓ１９１０）。
diff ← max(play_date1- play_date2, now_date - play_date1)
score ← max(365 - diff, 0) / 365 * 100
そして、ステップＳ１９１６に進む。
【０１９７】
ステップＳ１９１６以降では、次の処理を行う（ステップＳ１９１６、Ｓ１９１８、Ｓ１９２０）。
diff ← now_date - write_date
bonus ← max(30 - diff, 0) / 30 * 100
score ← score + bonus
そしてステップＳ１９２２に進む。ステップＳ１９２２では、scoreの値を返す（ステップＳ１９２２）。
【０１９８】
＜コンテンツ再生確率予想値更新処理スレッド：図３０＞
上述した図１１のステップＳ１１４で起動しているコンテンツ再生確率予想値更新処理スレッドについて、図３０を参照しながら説明する。
まず、id ← 1とする（ステップＳ２００２）。そして、Ｌ２−Ｈキャッシュ管理テーブルからidに対応するレコードを取り出して、そのsong_idを得る（ステップＳ２００４）。
【０１９９】
次に、song_idは空かを判断する（ステップＳ２００６）。song_idが空の場合は、後述するステップＳ２０１６に進む。song_idが空でない場合は、コンテンツデータベース１７０のsongテーブルからsong_idに対応するレコードを取り出し、コンテンツの履歴情報を取り出す（ステップＳ２００８）。
【０２００】
ステップＳ２０１２では、コンテンツの再生確率予想値（score）を算出する（ステップＳ２０１２）。そして、idに対応するレコードのscoreフィールドを更新する（ステップＳ２０１４）。そして、ステップＳ２０１６に進む。
【０２０１】
ステップＳ２０１６では、id ← id + 1とする（ステップＳ２０１６）。そして、全レコードの処理が完了したかを判断する（ステップＳ２０１８）。全レコードの処理が完了していない場合は、ステップＳ２００４に戻る。全レコードの処理が完了した場合は、Ｌ２−Ｅキャッシュ管理テーブルについて、上記と同様の処理を行う。
【０２０２】
以下、さらに具体的な一例について説明する。
本実施形態ではコンテンツ鮮度情報として、コンテンツがコンテンツサーバ１０に書き込まれた日時（write_date）を用いている。ここで例えば以下のような経緯で、あるコンテンツがコンテンツサーバ１０に登録された場合を考えてみる。
【０２０３】
・２０１５年１２月２５日に、あるコンテンツが新譜としてリリースされたとする。このときのコンテンツのリリース日（１）：２０１５／１２／２５である。
・２０１６年１月１５日に、本コンテンツ再生装置のユーザがそのコンテンツをオンライン購入し、ダウンロードしたコンテンツデータをユーザＰＣ内のＨＤＤに保存した。このときのファイル更新日時：２０１６／１／１５、ファイル作成日時：２０１６／１／１５である。
・２０１６年２月１日に、ユーザＰＣのＨＤＤに保存されていたコンテンツファイルをコンテンツサーバ１０にコピーした。このときのファイル更新日時（２）：２０１６／１／１５、ファイル作成日時（３）：２０１６／２／１である。
【０２０４】
上記例では、このコンテンツがコンテンツサーバ１０に書き込まれた日時は、上記のファイル作成日時（３）の２０１６／２／１となる。
【０２０５】
コンテンツサーバ１０が、本コンテンツ再生装置のユーザがプライベートで構築したものである場合には、コンテンツサーバ１０に登録されているコンテンツはユーザの意思に基づいて管理されていることになる。あるときユーザが、２０年前にリリースされた古い楽曲データを何らかの方法で入手し、そのコンテンツファイルをコンテンツサーバ１０に登録したものとする。この場合、おそらくはユーザはそのコンテンツを聞きたいと考えたからこそ、そのコンテンツファイルを自らが管理するコンテンツサーバ１０に登録したのだと考えられる。つまりそのコンテンツはこのユーザにとっては新譜に相当するような目新しい楽曲だということであり、おそらくは近日中にそのコンテンツを再生する確率が高いものと予想される。
【０２０６】
本実施形態では、このようにコンテンツファイルがコンテンツサーバ１０に登録された日時をコンテンツ鮮度情報として利用することにより、楽曲のリリース日が最近だからその楽曲の再生確率が高いと単純に判断する従来の機器よりも、よりユーザの気持ちに添ったコンテンツ再生確率を算出することを可能としている。
【０２０７】
なお、コンテンツ鮮度情報として利用する情報は、上記のファイル作成日時（３）に限定されるものではなく、ユーザがコンテンツファイルを入手した日時を示すファイル更新日時（２）や、コンテンツのリリース日（１）を用いることも可能である。
【０２０８】
（第２の実施形態の効果）
以上説明したように、本実施形態によれば、コンテンツサーバ１０への登録日時が新しいコンテンツ（音楽で言えば新曲）がコンテンツキャッシュ部１６０に保存される可能性が高まるため、コンテンツキャッシュ部１６０のヒット率が向上し、モバイル通信帯域を節約することが可能となる。一方で、久しぶりにたまたま再生した旧譜はキャッシュしないので、旧譜を再生することによりコンテンツキャッシュ部１６０のヒット率が低下することがない。
【０２０９】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【０２１０】
例えば、上記第１の実施形態では、再生頻度値を求めるための具体例やプログラムについて説明したが、本発明はこれに限定されない。コンテンツの再生頻度を表す情報であれば、任意の情報から再生頻度値を求めるように構成することができる。
【０２１１】
また、上記第２の実施形態では、再生確率予想値の一例として、コンテンツがコンテンツサーバ１０に登録された日時（コンテンツ鮮度情報）とコンテンツの再生履歴情報に基づいて算出する場合について説明したが、本発明はこれに限定されない。再生確率を予想できる情報であれば、任意の情報から再生確率予想値を求めるように構成することができる。
【０２１２】
また、上記実施形態では、コンテンツ再生装置１００として、半導体メモリを有するモバイル機器を前提として説明したが、本発明はこれに限定されない。例えば、半導体メモリ型のコンテンツ再生装置から半導体メモリを取り外したもの（いわゆるクラウド型のコンテンツ再生装置）や、車載向けの音楽再生装置や、据置型のネットワークオーディオプレーヤーや、音楽再生機能を持ったテレビや、電子書籍リーダーにも本発明は適用可能である。
【産業上の利用可能性】
【０２１３】
本発明は、コンテンツを再生するコンテンツ再生装置及びコンピュータプログラムに利用可能である。
【符号の説明】
【０２１４】
１０    コンテンツサーバ
１００  コンテンツ再生装置
１１０  メイン・コントローラ
１２０  ネットワーク通信部
１３０  操作検知部
１４０  画面表示部
１５０  音楽再生部
１６０  コンテンツキャッシュ部
Ｌ１    第１コンテンツキャッシュ
Ｌ２    第２コンテンツキャッシュ
１７０  コンテンツデータベース
１８０  コンテンツデータベース更新部
１９０  コンテンツキャッシュ管理部
【図１】
0006589087.tif 000002
【図２】
0006589087.tif 000003
【図３】
0006589087.tif 000004
【図４】
0006589087.tif 000005
【図５】
0006589087.tif 000006
【図６】
0006589087.tif 000007
【図７】
0006589087.tif 000008
【図８】
0006589087.tif 000009
【図９】
0006589087.tif 000010
【図１０】
0006589087.tif 000011
【図１１】
0006589087.tif 000012
【図１２】
0006589087.tif 000013
【図１３】
0006589087.tif 000014
【図１４】
0006589087.tif 000015
【図１５】
0006589087.tif 000016
【図１６】
0006589087.tif 000017
【図１７】
0006589087.tif 000018
【図１８】
0006589087.tif 000019
【図１９】
0006589087.tif 000020
【図２０】
0006589087.tif 000021
【図２１】
0006589087.tif 000022
【図２２】
0006589087.tif 000023
【図２３】
0006589087.tif 000024
【図２４】
0006589087.tif 000025
【図２５】
0006589087.tif 000026
【図２６】
0006589087.tif 000027
【図２７】
0006589087.tif 000028
【図２８】
0006589087.tif 000029
【図２９】
0006589087.tif 000030
【図３０】
0006589087.tif 000031