JP5097563B2 - コンテンツ受信方法及びコンテンツ受信装置 - Google Patents

Description

本発明は、視聴者の要求に応じて、インターネット等の通信ネットワークを介してコンテンツ配信サーバの配信する映像コンテンツを受信、記録、再生するネットワーク対応テレビなどの映像コンテンツ受信装置およびコンテンツダウンロード制御方法に関する。

近年、ブロードバンドインターネットサービスの普及に伴い、映像、写真、音楽、マルチメディアデータ、アプリケーションプログラムといったコンテンツをインターネットで配信するサービスが注目を集めている。特に、従来放送局の放送電波が主流だったハイビジョン映像コンテンツについても、見たい時に見たいタイトルを楽しむことが可能なビデオオンデマンド（ＶＯＤ）サービスやＩＰ(インターネットプロトコル)放送など、ネットワークを通じて映像番組を配信するサービス形態が本格化し、対応してテレビやレコーダなどの放送受信機もネットワーク機能や大容量のハードディスクを搭載し、映像コンテンツをＩＰデータパケットとして受信、記録、再生する機能を搭載することが普通になって来た。

一般的に、ＩＰネットワークを使ったＶＯＤストリーミングサービスやダウンロードサービスは、ＰＣ等の情報処理装置でのユーザインタフェースを継承し、各々のサービス事業者のサービス提供窓口となるポータルサーバのサービスサイトに、視聴者が受信機のインターネットブラウザを使ってアクセスし、該ポータルサイトで示された提供番組情報から視聴したい番組を選択指定すると、指定した映像コンテンツファイルが配信サーバによりＩＰパケットデータとして送信され、それを視聴者の受信機（クライアント）が受信して蓄積する手順で実現される。

なお、サーバの送出するコンテンツをリアルタイムでデコードして視聴するストリーミングサービスに対して、コンテンツを一旦受信機に記録してから視聴するダウンロードサービスの場合は、コンテンツデータを受信機にダウンロードするのに時間がかかり、大抵の場合、ユーザがダウンロードしたいコンテンツをまとめて幾つか指定できるようになっており、ユーザが不在中や別の番組を視聴している間でも端末装置がサーバ装置と自動的に通信を行なって、ユーザの指定したコンテンツを適宜自動取得する仕組みが設けられている。

上記のような複数コンテンツダウンロードの技術分野において、例えば特許文献１には、「端末装置のメモリ容量やダウンロード時間に制約のある条件下でもサーバ装置から端末装置へ多量のコンテンツをダウンロードできるコンテンツダウンロードシステムの提供」を目的として、ユーザがダウンロードしたいコンテンツを複数個指定すると、コンテンツを送り出すサーバが、コンテンツ属性情報や容量情報、受信機のメモリ容量等を調べ、コンテンツの送出優先順位を決定し、受信機へと自動送信する方式が示されている。

また、特許文献２には、指定された複数コンテンツのダウンロードする順序を、ユーザの選好度を反映するように受信機が自動構成してサーバに送出要請し、サーバが該要請に従ってコンテンツを送出、かつ送出終了時に実際に送出したコンテンツ情報を受信機に通知する方式が開示されている。

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

しかし、実際のサービスにおいては、ダウンロードの実行形態には様々な形式がありうる。特に、有料のサービスになると、コンテンツのダウンロードは購入単位で行なわれるようになることが多い。すなわち、従来例で想定しているユーザが指定したコンテンツを逐次ダウンロードするような形態の他に、例えば、多数のコンテンツを一括してダウンロードするサービスや、シリーズものとして定期的に配信されるコンテンツを逐次ダウンロードしたり、最新ニュースなど新しいバージョンのコンテンツが配信されたらダウンロード済みのコンテンツを更新したり、また、ユーザがダウンロードを指示した時点では未配信のコンテンツをサービス業者が配信開始後自動的にダウンロードする予約ダウンロード等、様々なダウンロード形態がありうる。

こうした様々な形態のダウンロード機能を提供するために、規格化されたダウンロード制御情報として、XML形式のタグ言語で書かれたメタ情報ファイルが利用されることが多い。メタ情報ファイルの中には、受信機がダウンロード対象のコンテンツをダウンロードする際に実行すべき処理内容を設定するに必要な情報が記載される。

具体的には、ダウンロードするコンテンツの名称、データ種別、インターネット上の所在（URL）、サイズ、配信日時、更新管理をするか否か、更新管理する場合の更新期限の日時、更に蓄積したコンテンツの再生する際に使用する情報ファイルやDRM情報ファイルの取得先など、ダウンロードサービスを提供する上で必要な全ての情報が記載されている。このメタ情報ファイルは、例えば上記のポータルサーバ上に置かれる。受信機は、HTMLコンテンツからリンクされたメタ情報ファイルを、ユーザのコンテンツ指定指示に対応して読み込むことにより、該当のコンテンツダウンロード形態を、メタ情報ファイルの記述に従って実現するよう動作することになる。

このような様々な形態のダウンロードサービスを、視聴者が多数のサービス事業者に対して任意に指定し、受信機とサーバが各々のサービスに応じてメタ情報ファイルの記載に従いダウンロードを実行するようになると、ある一つの事業者サーバの判断によるダウンロード順序決定や、単純に視聴者の好みによるダウンロード順決定は、ユーザにとって必ずしも合理的なものではなくなってしまう。特に、ある特定の情報を毎日送るような周期的配信のサービスは、常に最新情報がダウンロードされているようにしたい。

そこで、例えば、現在ダウンロード対象となっているコンテンツのダウンロード形態を、該コンテンツのメタ情報ファイルを精査することによって把握し、最新情報を得るために使われることの多い周期的配信型のコンテンツのダウンロードを優先して行う。また複数の周期的配信型が指示されていたとき、ダウンロード制御メタファイルの更新周期情報を見て、更新周期の時間が小さい、すなわち、より短い時間で更新・変更されるコンテンツを優先的にダウンロードすることにより、ユーザが早く見たい情報を効率よく優先的にダウンロードする。また、上記ダウンロード優先順序判定処理と共に、周期的配信されるコンテンツダウンロード時間を監視する機構を設け、ダウンロードの実行が不可能になる状態等を監視する。

上記手段によれば、ユーザが複数の周期配信コンテンツのダウンロードを指示した時、更新周期の時間の短いものを優先してダウンロードすることにより、最新情報が効率的にダウンロードでき、また、ユーザが周期配信のサービスを多く申し込みすぎて、周期的なコンテンツのダウンロードが間に合わなくなった場合には、警告を発することが出来る。

図１は本発明の一実施形態であるコンテンツ配信サービスシステムの機器構成を示す図である。

コンテンツ配信サービスを利用するユーザの端末である受信機３は、コンテンツ配信ネットワーク４を経由して、サービスを提供する事業者の運営するポータルサーバ１やコンテンツ配信サーバ２に接続し、コンテンツ配信を受ける。

ポータルサーバ１は、ユーザがコンテンツダウンロードサービスを利用する際の各種手続きを行なうためのユーザインタフェースとなるポータルサイトを提供するＷｅｂサーバで、ダウンロードできるコンテンツ一覧や有料コンテンツの価格を提示し、ユーザの購入時に課金処理などの手続きを行う。また、ユーザが受信機に映像コンテンツデータのダウンロードを行なう時に必要な制御情報を記述したダウンロード制御メタファイルを蓄積しており、受信機３からのリクエストに応じてダウンロード制御メタファイルを配信する機能を持つ。

コンテンツ配信サーバ２は、映像コンテンツ群をデータファイルの形で蓄積しており、受信機３からのダウンロードリクエストに応じて、所望の映像コンテンツをＩＰデータパケットの形でユーザの受信機へと転送する機能を持つファイルサーバである。

受信機３は、コンテンツ配信サービスを利用するための機能を搭載したユーザのクライアント端末であり、例えばネットワークに接続される、記録機能を有するテレビ、レコーダ、パーソナルコンピュータ等であるが、本実施例においては本発明の優先度付きダウンロード機能を搭載したネットワーク対応のデジタルテレビであるとする。

コンテンツ配信ネットワーク４は、様々な従来のネットワーク物理層（光、有線、または無線ネットワークを含む）のいずれかを使用して実現されるインターネットプロトコル通信ネットワークであり、ルータやスイッチ、ハブなど、データパケットを送信元から送信先へ正確に送り届けるための通信制御機器４１〜４４も含まれる。

図２に、受信機３のネットワーク対応テレビハードウェア構成図を示す。受信機３は、放送電波を受信するアンテナやデジタルチューナ以外に、ＩＰ（Internet Protocol）データパケットを送受信するためのＩＰ通信ポートを備え、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＤＨＣＰ（Dynamic Host Configuration Protocol）、ＤＮＳ（domain name server）、ＨＴＴＰ(HyperText Transfer Protocol)、ＲＴＰ(Real-time Transport Protocol)、ＲＴＳＰ(Real Time Streaming Protocol)、ＭＬＤ(Multicast Listener Discovery)、ＩＧＭＰ(Internet Group Management Protocol)等の各種通信プロトコルの処理が可能である。またＨＴＴＰブラウザなどのアプリケーションを搭載しており、該ＩＰ通信Ｉ／Ｆ２２でルータ等を介して宅外のコンテンツ配信ネットワーク４に接続し、ポータルサーバ１やコンテンツ配信サーバ２の配信する様々なコンテンツのストリーミングやダウンロードのサービスを利用することができる。

なお、受信機３では、ＣＰＵ２０が、ＲＯＭ２４に格納されたプログラムを実行することで、各種の処理を行う。さらにリアルタイムクロック２８を持ち、常に実時間を保持し、上記プログラムから参照することができ、設定された日時にＣＰＵ２０にプログラムを実行させるタイマー機能をも有する。なお、各プログラムは独立したハードウェアにより構成することもできる。

また、ハードディスクインタフェース（ＨＤＤ Ｉ／Ｆ）１７を介して、ハードディスクドライブ（ＨＤＤ）１６が接続されており、大容量のデータの読み書き処理を行うことができる。そして、ＩＰパケットとして受信したコンテンツのデータファイルを、放送波と同じデコード処理が可能なようにデータ変換を行った後デコーダ１４に送る仕組みを持つ。これにより放送もＩＰネットワーク配信されたコンテンツも区別なく再生視聴が出来る。

具体的なダウンロードサービスの運用手順としては、例えば、まずユーザが受信機３のＷｅｂブラウザを用いてＷｅｂサーバ１にアクセスする。受信機（又はユーザ）のＩＤの認証が実行された後に、Webサーバ１上のダウンロードサービス用のＷｅｂサイトのページを取得する。そのＷｅｂページを用いて、ユーザはダウンロードを所望するコンテンツの購入パッケージの購入処理を行なう。

購入処理は、まずＷｅｂサーバ１が該当の購入パッケージ（コンテンツ）のＩＤと受信機（又はユーザ）のＩＤを顧客管理の課金サーバに送って課金する。課金が完了すると、ダウンロード制御メタファイルをＷｅｂサーバ１から受信機３にダウンロードする。受信機３は、取得したダウンロード制御メタファイルに従って、コンテンツ配信サーバ２にアクセスし、コンテンツの取得要求を行なう。コンテンツ配信サーバ２は、受信機の要求に応じてインターネットを介してコンテンツのデータを配信し、それを受信機はＨＤＤ Ｉ／Ｆ１７を介して、ＨＤＤ１６に記録することでダウンロードが完了する。

ダウンロードしたパッケージ（コンテンツ）を再生するときには、再生制御メタファイルやＤＲＭ（Digital Rights Management）の鍵データやコンテンツメタデータを必要に応じて取得する。

図３は、ダウンロード制御メタファイルの構成例を示す。ダウンロード制御メタファイルは、メタファイル自身の内容を記述したダウンロード制御情報110と、一つまたは複数のコンテンツをダウンロードするのに用いるダウンロード実行情報120を含む。各情報は、例えばＲＳＳ（Rich Site Summary）言語で記述されているとする。

ダウンロード制御メタファイルは、ユーザに販売するコンテンツパッケージの形態に応じてサービス業者によって作成される。一つのコンテンツに対して一つのダウンロードメタファイルがある場合や、一括ダウンロードのように任意の複数コンテンツに対し一つのダウンロード制御メタファイルが対応する場合もある。また、或るコンテンツに対して複数の販売形態がある場合は複数用意することも可能である。ただし、どのような販売形態であろうと、必ずユーザが購入した全コンテンツがダウンロードできるように用意するものであり、複数の販売パッケージに跨るような矛盾した物を作ってはならない。

さらに、ダウンロード制御メタファイルは更新されることがあり、受信機３は一定周期でチェックし差分を更新する。なお、ＲＳＳの場合にはenclosure urlで各コンテンツを識別できる。

ダウンロード制御情報110は、該ファイル自身を示す情報であり、一つのダウンロード制御メタファイルに一つだけ存在する。情報内容としては、自分自身を表す名称（例えば販売パッケージの名称、ファイル名、ID等）を示すダウンロード制御メタファイルの名称111、対応するダウンロード制御メタファイルの所在（例えば、ダウンロード予約を提供するウェブサイトのインターネット上のURL。URLに限らないアドレスであってもよい、以下所在について同様）を示すダウンロード制御メタファイルの所在112、対応するダウンロード制御メタファイルの説明（例えばダウンロード予約についての説明や言語タイプ等）を示すダウンロード制御メタファイルの説明文113、ダウンロードタイプ114、更新管理情報115などの情報が入る。

ダウンロードタイプ114は、このダウンロード制御メタファイルの内容が変更されものであるのか否か、つまり、受信機３が周期的にチェックを行う必要があるファイルなのかどうかを判別するフラグであり、一度取得しても後に変更されることのある「更新」と、最初に取得した後は変更されることの無い「単発」のどちらかをとる。

更新管理情報115は、ダウンロードタイプ114が「更新」の場合に有効で、ダウンロード制御メタファイルが更新される周期や、期限、バージョンなどの情報を示す。例えば、更新周期や期限は、受信機から見れば、コンテンツの更新を監視するタイミングや期限を示す。更新や期限の単位（日単位、時単位、分単位等）は任意である。「期限なし」すなわち半永久的に受信機がチェックをし続けなくてはならないことを示す値を取ることも可能である。

また、別の実施例として、更新管理情報115の特殊な値（例えばすべて０）をダウンロードタイプ114の「単発」を示す値として扱うことにより、ダウンロードタイプ114を省略する構成も実現可能である。後で説明するダウンロード実行管理テーブル500では、そのような構成をとっている。

ダウンロード実行情報120は、一つのダウンロード制御メタファイルに複数記述可能である。ダウンロードする各々のコンテンツについて、そのコンテンツのタイトル（番組名等であってもよいし、ファイル名やＩＤであってもよい）を示す配信コンテンツのタイトル121、そのコンテンツの説明（特徴や備考等）を示す配信コンテンツの説明文122、そのコンテンツを配信する日時（日単位、分単位であっても良い）を示す配信日時123、そのコンテンツの所在を示す配信コンテンツの所在124、配信コンテンツの種別125、そのコンテンツに対応するメタファイルの所在を示す配信コンテンツ用メタファイルの所在126、配信コンテンツのサイズ127などの情報を格納する。

配信日時123は、通常、コンテンツがファイルサーバ2に格納され、公開された日時を記載する。ダウンロード制御メタファイルが配信されたとき、即ち購入時にはコンテンツがまだ公開されない予約型の販売形態の場合には、配信日時123には配信予定の未来の日時が記載されることになる。また、例えば、配信されたコンテンツの内容が定期的に更新されるような定期配信型の販売形態の場合、配信日時123には、定期的に更新された日時が記載されることになる。

配信コンテンツのファイル種別125は、例えばサーバから配信される映像、写真、音楽、プログラム、マルチメディアデータなどの種別を記載する。映像の中で更に細分化して、映画、ニュース、スポーツ等、音楽の中で更に細分化してクラシック、ロック、ジャズ等の種別を記載してもよい。

配信コンテンツ用メタファイルとは、コンテンツの再生や実行に必要な付属情報のことで、一例としてはコンテンツ検索用のジャンルやキーワード情報、コンテンツが映像情報であれば、そのサムネイルやチャプタ情報などがある。

なお、ダウンロード制御メタファイルや、ダウンロード制御情報、ダウンロード実行情報の全部又は一部をダウンロード制御データと呼ぶこともある。

図４のフローチャートは、ダウンロード制御メタファイルを、受信機３が取得する手順の例である。ポータルサーバ１が提供するＷｅｂページの一例は図８に示す。

ダウンロード制御メタファイルの取得は、Ｗｅｂブラウザで行う。受信機３はＷｅｂブラウザを起動し、ユーザの指示で、ポータルサーバのコンテンツダウンロード手続きを行なうＷｅｂページ（例えば、映画、番組、楽曲等のコンテンツのタイトルを表示する画面データや、ＨＴＭＬを含む）の取得要求を行い、取得したＷｅｂページを表示する。なお、本例の受信機３はリモコン３０で操作する。

このようなコンテンツダウンロードの手続きを行なう画面は、通常、ダウンロード可能なコンテンツのタイトルやサムネイル、あるいは複数個のコンテンツを纏めたコンテンツパッケージ名等が羅列されており、ユーザが、それらのタイトルやパッケージ名の中から、所望のものを選択指定することで、ポータルサーバ１にダウンロード対象のコンテンツを通知することになる(ステップ1000〜1001)。なお、この時、有料のコンテンツの場合は、金額やライセンス上の制限（例えば、コピー回数や視聴回数の上限など）の確認が行なわれることが多い。

また、ダウンロードするコンテンツを選択指定する実行ボタンには、ダウンロード制御メタファイル100がリンク記述されている。これにより、ステップ1002でユーザがダウンロードコンテンツを選択指示すると、受信機３のＷｅｂブラウザは、該コンテンツやパッケージダウンロードのためのダウンロード制御メタファイル100を、Ｗｅｂサーバ1から取得することになる。

図3で、ステップ1002の実行結果例として示した図８のWebページ200は、番組のタイトル「柏FＣ’06パック」と、このパッケージに含まれるコンテンツを選択するダウンロードボタン（例えば「全部」を選択すると本ページの全てのコンテンツが一括してダウンロードされ、「６月」を選択すると６月分のコンテンツがダウンロードされる）の画面表示例である。このＷｅｂページにおいて、一つ一つのダウンロードボタンに対して、それぞれダウンロードするコンテンツについて記述したダウンロード制御メタファイル100が用意され、リンクされている。

すなわち、「６月」のダウンロードボタンには、６月の試合のコンテンツ一つだけをダウンロードする情報の記述されたダウンロードメタファイルが、「全部」のダウンロードボタンには、プレシーズンから12月までの11個のコンテンツ全てをダウンロードするための情報が記述されたダウンロードメタファイルがリンクされていることになる。

受信３のWebブラウザは、ダウンロード制御メタファイル100を取得すると、そのデータをＨＤＤ１６に格納して、以後の処理を受信機３に搭載されたコンテンツダウンロード管理機能（以後ダウンローダと称する）に引き継ぐ。

図５は、本例のダウンローダプログラムの処理の流れを示すフローチャートである。ダウンローダは起動すると、後述する初期設定処理（ステップ2000）の後、イベント待ち状態となる（ステップ2001）。前記Ｗｅｂブラウザの発行したイベント（ステップ1006）によりＷｅｂブラウザが新規に取得したダウンロード制御メタフィルが存在することを通知するイベントを受け取ると、ステップ2002の処理に進み、該取得したダウンロード制御メタファイルの内容を解析する。

そして、その中に記載されたダウンロード制御情報110を図６で説明するダウンロード予約管理テーブル2100に登録し(ステップ2003)、対応するダウンロード実行情報120を図６で説明するダウンロード実行管理テーブル500に登録する(ステップ2004)。その後、ダウンロードの実行順序決定処理に進む。

図６に、ダウンローダが管理するダウンロード管理テーブルの構成例を示す。ダウンロード管理テーブルは、ダウンロード管理情報テーブル300、ダウンロード予約管理テーブル400、ダウンロード実行管理テーブル500、ダウンロード実行順序テーブル600からなる。

ダウンローダ管理情報テーブル300は、ダウンローダが、ダウンロード制御メタファイルの更新をチェックするタイミングや更新ダウンロード量を管理する情報である。チェック周期情報310は、例えばユーザが変更可能な固定のチェック周期時間である。前回チェック日時320は、周期的にチェックする際、前回チェックを行った日時情報である。

次回チェック予定日時330は、前回チェック日時320に、チェック周期情報310を加算して求めた日時であり、この値をリアルタイムクロック28のタイマーに設定し、予定時刻になった時に割り込みイベントを発生させることで、次回チェック予定日時330にダウンロード制御メタファイルの更新をチェックすることができる。周期合計量340は、周期配信されるコンテンツの日割り平均量を計算するために用い、ユーザが周期配信コンテンツを多く購入しすぎて、ダウンロードの実行が間に合わなくなった場合に警告を出すために使用する。

上記、ダウンローダが起動したときのステップ2000の初期設定処理は、前述の前回チェック日時320に、チェック周期情報310を加算して次回チェック予定日時330の値を設定、該予定時刻にタイマー割込み発生要求を設定する処理である。なお、上記で加算して算出した次回チェック予定日時が現在時刻より過去の場合は、次回チェック予定日時に現在時刻を書き込み、即座にチェックを行なうようにする。

ダウンロード予約管理テーブル400は、各々のダウンロード制御メタファイルに対応して設けられるダウンロード時刻の設定を管理するテーブルである。ダウンロード予約の名称401、ダウンロード予約の所在402、ダウンロード予約の説明文403、更新タイプ404、更新管理情報405にはそれぞれ、上記ステップ2002において、解析したダウンロード制御メタファイル100のダウンロード制御情報110に含まれる、ダウンロード制御メタファイルの名称111、ダウンロード制御メタファイルの所在112、ダウンロード制御メタファイルの説明文113、ダウンロードタイプ114、更新管理情報115が格納される。

ダウンロード実行管理テーブル500は、各々のコンテンツについて、ダウンロードの実行状況を管理するテーブルであり、ダウンロードの管理が可能なコンテンツ数（Ｍ個）用意される。配信コンテンツのタイトル501、配信コンテンツの説明文502、配信日時503、配信コンテンツの所在504、配信コンテンツの種別505、配信コンテンツ用メタファイルの所在506、配信コンテンツのサイズ507には、それぞれ、上記ステップ2003において、解析したダウンロード制御メタファイル100のダウンロード実行情報120に含まれる、配信コンテンツのタイトル121、配信コンテンツの説明文122、配信日時123、配信コンテンツの所在124、配信コンテンツの種別125、配信コンテンツ用メタファイルの所在126、配信コンテンツのサイズ127を格納する。

ダウンロード実行状態508は、「未実行」「ダウンロード中」「ダウンロード済」「中断状態」などの値を持ち、ダウンローダが、ダウンロードの実行状態を管理するために利用する。初期値は「未実行」である。

ダウンロード進捗情報509は、ダウンロードの進捗度合いを管理するために使う情報で、本例では、コンテンツのダウンロード済みデータのサイズを逐次格納する。この場合、配信コンテンツのサイズ507との比を求めることで、ダウンロードの進捗度合いをユーザにプログレスバーや％表示等で示すことができる。なお、ダウンロード進捗情報509はダウンロード実行状態508が「未実行」の場合は0、「ダウンロード済」の場合は、ダウンロード進捗情報509の値＝配信コンテンツのサイズ507に設定する。

ダウンロード更新情報510は、ダウンロード制御メタファイル100の更新チェックフラグ114と更新制御情報115を、まとめて登録するフィールドである。本例では、更新チェックフラグ114が「単発」のダウンロード制御メタファイルに存在するコンテンツの場合は、ダウンロード更新情報510フィールドの更新周期、期限、バージョン値を全て0に設定、更新チェックフラグ114が「更新」のダウンロード制御メタファイルに存在するコンテンツは、ダウンロード制御メタファイルの更新管理情報をそのまま登録する。

ダウンロード予約管理テーブル400のダウンロード実行管理テーブルポインタ（406_1から406_N）には、同じダウンロード制御メタファイルに存在するダウンロード実行情報を管理するためのダウンロード実行管理テーブル500の所在（ＨＤＤ１６内でのアドレスやＲＡＭ２３またはＲＯＭ２４のアドレス等）を格納する。Ｎは、処理可能なダウンロード実行情報120の最大値であり、システム設計により異なる。

ダウンロード実行順序テーブル600は、ダウンローダが、ダウンロードを実行する優先度を管理するテーブルであり、ダウンロード実行管理テーブル500へのポインタ610の配列となっている。ポインタの並び方は本例では実行順であり、ダウンローダの優先順位付け処理により決定される。ダウンローダはプログラムであり、ＣＰＵ２０で処理されることにより、優先順位付け等の処理を行うが、ダウンローダは独立したハードウェアにより構築することもできる。

ダウンローダがダウンロード制御メタファイルを受信して、その内容を解析し、ダウンロード予約管理テーブル400、ダウンロード実行管理テーブル500、ダウンロード実行順序テーブル600、などの各テーブルに登録を行なう。しかし、これらの処理は別々のハードウェアにより実現することもできる。すなわち、受信は受信部が行ない、解析は解析部が行ない、登録は登録部が行なうようにしてもよい。解析、登録を、登録部が一括して行なってもよい。

ダウンロードの順序決定について説明する。ダウンローダは、ダウンロード予約管理テーブル400のうち、配信日時403が未来のもの、すなわち、まだ配信されるコンテンツがサーバ上に無く、ダウンロードを予約している状態のものや、ダウンロード実行状態408が「ダウンロード済」のものなどを、実行対象外として実行順序決定の対象外とする（ステップ2005）。

もし、全てのダウンロード実行管理テーブル500が実行対象外で、ダウンロードすべきコンテンツの無い場合は処理を中止してイベント待ち状態に戻る（ステップ2006）。

実行対象のダウンロード実行管理テーブル500が在った場合は、ダウンローダは、所定の法則に従い、ダウンロード実行順序を決定し、決定した実行順序に従ってダウンロード処理を行なう。ダウンロード実行順序テーブル600のダウンロード実行管理テーブルポインタフィールド610に、対応するダウンロード実行管理テーブル500へのポインタ値を優先して実行する順に格納する（ステップ2007〜2010）。

順序決定方法は、本例の場合、まず、ダウンロードコンテンツを（１）中断更新コンテンツ、（２）中断単発コンテンツ、（３）単発コンテンツ、（４）更新コンテンツの４グループに分けて設定している。なお、
（１）の中断更新コンテンツは、更新型のコンテンツのダウンロード途中、何らかの理由でダウンロードが停止し、コンテンツのダウンロードが終わっていないもので、具体的にはダウンロード実行状態508が「中断状態」かつダウンロード更新情報510に０で無い値が設定されているものである。
（２）の中断単発コンテンツは、単発型のコンテンツのダウンロード途中、何らかの理由でダウンロードが停止し、コンテンツのダウンロードが終わっていないもので、具体的にはダウンロード実行状態508が「中断状態」かつダウンロード更新情報510が全部０であるものである。
（３）の単発コンテンツは、ダウンロードが未実行、ダウンロード制御メタファイル100のダウンロードタイプが単発であるファイルに属するコンテンツで、具体的には、ダウンロード実行状態508が「未実行」かつダウンロード更新情報510が全部０のものである。
（４）更新コンテンツは、ダウンロードが未実行、ダウンロード制御メタファイル100のダウンロードタイプが更新であるファイルに属するコンテンツで、具体的には、ダウンロード実行状態508が「未実行」かつダウンロード更新情報510に０で無い値が設定されているものである。

そして、本例では、基本的に
（ａ）（１）（２）（３）（４）の順で優先的にダウンロードする。
（ｂ）（１）同士では、更新周期の時間がより短いダウンロード制御メタファイルに属するコンテンツを優先する。
（ｃ）（２）同士では、残りのダウンロード量の小さいものを優先する。
（ｄ）（３）同士では、ダウンロードサイズが小さいものを優先する。
（ｅ）（４）同士では、更新周期の時間がより短いダウンロード制御メタファイルに属するコンテンツを優先する。という法則に従ってダウンローダがダウンロード順序を決定する。

従って、手順としては、まず、ダウンローダがステップ2005で抽出した実行対象のダウンロード実行管理テーブル500のリストから、（１）に相当するダウンロード実行状態508が「中断状態」かつダウンロード更新情報510に０で無い値が含まれているコンテンツを抽出する。

（ｂ）に従って、ダウンローダがダウンロード更新情報510の中の更新周期を調べて比較し、更新周期の小さい順に、該当ダウンロード実行管理テーブル500へのポインタ値を、ダウンロード実行順序テーブル600の先頭フィールドから順次書き込む(ステップ2007)。

次に、ダウンローダが実行対象のダウンロード実行管理テーブル500のリストから、（２）に相当するダウンロード実行状態508が「中断状態」かつダウンロード更新情報510が全部０のコンテンツを抽出する。（ｃ）に従って、各々のダウンロード残サイズを調べて比較し（配信コンテンツのサイズ507−ダウンロード進捗情報509＝ダウンロード残サイズ）、残サイズの小さい順に、該当ダウンロード実行管理テーブル500へのポインタ値を、ダウンロード実行順序テーブル600の先頭フィールドから順次書き込む(ステップ2008)。

続いて、ダウンローダが、実行対象のダウンロード実行管理テーブルのリストから、（３）に相当する、ダウンロード実行状態508が「未実行」かつダウンロード更新情報510が全部０のコンテンツを抽出し、（ｃ）に従って配信コンテンツのサイズ507を調べて比較し、サイズの小さい順に、該当ダウンロード実行管理テーブル500へのポインタ値を、ダウンロード実行順序テーブル600に（１）グループに続いて書き加える（ステップ2009）。

最後に、ダウンローダが実行対象のダウンロード実行管理テーブルのリストから、（４）に相当する、ダウンロード実行状態508が「未実行」かつダウンロード更新情報510に０では無い値が登録されているコンテンツを抽出し、（ｄ）に従ってダウンロード更新情報510の中の更新周期を調べて比較し、更新周期の小さい順に、該当ダウンロード実行管理テーブル500へのポインタ値を、ダウンロード実行順序テーブル600に（２）グループに続いて書き加える（ステップ2010）。

以上の処理で、上記法則に従った順序でダウンロードが行なわれるように、ダウンロード実行順序テーブルが完成する。

なお、上記法則は、（ａ）（ｂ）（ｃ）（ｄ）の各単位で変更可能である。つまり、（ａ）の法則は、優先順を例えば（１）（４）（２）（３）にしたり、（４）（３）（２）（１）にしたり等、ユーザが自由に設定でき、設定に応じて、ステップ2007、2008、2009、2010は順序が入れ替わる。

（ｂ）に関しては、例えば、上述の更新周期が小さい順ではなく、配信日時の古いものから順にダウンロードするよう設定することが出来る。そのように設定された場合は、ステップ2007では、ダウンロード更新情報510の中の更新周期ではなく、配信日時503を参照して比較し、期限の近いものからダウンロード実行順序テーブル600に登録する。

以下同様に、（ｃ）に関しては、例えば、配信日時の古いものから順にダウンロードすることが出来る。そのように設定された場合はステップ2008では、残サイズではなく、配信日時503を参照して比較し、日時の古いものからダウンロード実行順序テーブル600に登録する。また、逆に、配信日時の新しいものから順にダウンロードすることも出来る。そのように設定された場合は、ステップ2009では、配信コンテンツのサイズ507ではなく、配信日時503を参照して比較し、日時の新しいものからダウンロード実行順序テーブル600に登録する。

（ｄ）に関しては、更新期限の近いものから順にダウンロードすることが出来る。そのように設定された場合は、ステップ2010では、ダウンロード更新情報510の中の更新周期ではなく、更新期限を参照して比較し、期限の近いものからダウンロード実行順序テーブル600に登録する。

以上の様に、本装置ではダウンロード実行の順序を決める法則は、任意に設定可能である。

ダウンロード実行順序テーブル600が完成すると、該配列の順序に従って実際のダウンロード処理を行うダウンロード処理に進む。ダウンロード処理は後に説明する。

ダウンロード実行順序テーブル600は、ダウンローダが生成するが、独立したハードウェアであるダウンロード実行順序テーブル生成部を有してもよい。

以上が、新規にダウンロード制御メタファイルを取得してきた場合の処理の流れであるが、ステップ2001でのイベント待ち状態で、上述したように、ダウンロード更新時間設定テーブル300の次回チェック予定日時330の時間になると、リアルタイムクロックによりタイマー割込みイベントが発生する。その場合、ダウンロード制御メタファイルの更新をチェックする操作に進む。

ステップ2001でタイマー割り込みイベントを検知すると、まず、ダウンローダ管理情報テーブル300を更新する。すなわち、次回チェック予定日時330の値を前回チェック日時320にコピーし、次回チェック予定日時330に、前回チェック日時320にチェック周期時間310を加算した値を格納し、リアルタイムクロック28を次回チェック予定日時330の時刻にタイマー割込みイベントが発生するよう設定する。また、周期合計量を０に初期化する（ステップ2020）。

その後、サーバ側のダウンロードメタファイルの更新をチェックする。ダウンロード予約管理テーブル400に存在する全データについて、先頭レコードから順に、ダウンロード制御メタファイル100の更新チェックが必要か否かを調べる。

すなわち、ダウンロード予約管理テーブル400の更新タイプ404が「更新」で更新管理情報405の更新期限が、現在より未来の値、すなわち現在も更新され続けており、更新チェックが必要かを調べる（ステップ2021）。

現在も更新中でありチェックが必要なら（ステップ2022）、ダウンロード予約の所在402が示すURLにアクセスし、サーバ上のダウンロード制御メタファイル100の更新制御情報115のバージョンと現在受信機３がダウンロード済のダウンロード制御メタファイル100のバージョンとを比較する。サーバ上のダウンロード制御メタファイル100が新しいバージョンであった場合には、更新されていると判定し（ステップ2023）。サーバ上の新しいダウンロード制御メタファイル100をダウンロードする（ステップ2024）。

なお、この時、サーバ上のダウンロード制御メタファイルが更新されておらず、取得更新しなかった場合は、ステップ2028に飛び、新規にダウンロードメタファイルをから周期配信されるコンテンツの日割りの平均ダウンロード量を計算し、ユーザが周期配信コンテンツを多く購入しすぎて、ダウンロードの実行が間に合わない可能性がないかの周期合計量のチェックを行なう。

具体的にはステップ2028で、ダウンロード実行管理テーブルポインタ1〜Nの参照先のダウンロード実行管理テーブル500について、その配信コンテンツのサイズ507の値を、予め受信機に設定された最低ダウンロードレートで除算し、該コンテンツのダウンロード時間を算出する。さらに、算出したダウンロード時間を、更新管理情報405の更新周期を１日に何回かに換算した値を乗算し、結果を、周期合計量340の値に加算する。

例えば、配信コンテンツが600MByte（4800Mbit）で、最低ダウンロードレートが８Mbps、更新周期が２日の場合、4800Mbit÷８Mbps＝600秒（10分）を一日当たり1/2回ダウンロードするので、10分×1/2＝5分、これを周期合計量340に加算する。

周期合計量340が24時間を越えたら、更新ダウンロード量が多すぎて間に合わない可能性があると判定し（ステップ2029）、ユーザに警告を表示する(ステップ2030)。

警告の表示は、ダウンローダが行なうが、独立したハードウェアである出力部が、警告を表示してもよい。

ステップ2024で更新ダウンロード制御メタファイルをダウンロードした場合は、上記周期合計量の計算の前に、対応するダウンロード予約管理テーブル400およびダウンロード実行管理テーブル500の値を比較し、両テーブルの修正を行なう。

まず、ダウンロード実行管理テーブルポインタ1〜Nの参照先のダウンロード実行管理テーブル500について、ダウンロード実行情報120から削除されたものがないか調べ、もしあれば、該当するダウンロード実行管理テーブル500のレコードを消去する(ステップ2024)。次に、ダウンロード実行管理テーブルポインタ1〜Nの参照先のダウンロード実行管理テーブル500について、既存のダウンロード実行管理テーブル500にない、ダウンロード実行情報120が追加されていないかを調査し、もしあれば、該当するダウンロード実行管理テーブル500のレコードを追加作成する(ステップ2025)。

さらに、ダウンロード実行管理テーブルポインタ1〜Nの参照先のダウンロード実行管理テーブル500について、新しいダウンロード実行情報120で情報が更新されているかを調べ、もし更新されている部分があれば、該当するダウンロード実行管理テーブル500のフィールドの値を修正する(ステップ2026)。

その後、ダウンロード制御メタファイルを更新しなかった場合と同じように、周期合計量のチェックを行なう（ステップ2028〜2030）。

このステップ202１から〜2030の処理を、すべてのダウンロード予約管理テーブル400について繰り返し(ステップ2031)、更新チェックが終了する。

以上の処理により、一定周期で、サーバに対してダウンロード制御メタファイルの更新をチェックし、変更された部分を、ダウンローダのデータベースに反映させることができる。

全てのダウンロード制御メタファイルの更新チェック、周期合計量のチェックを終了すると、ステップ2005のダウンロード実行順序を決定する処理に進み、その後コンテンツダウンロードを実行することになる。

図７はダウンロード実行順序テーブル900が完成した後に行なう、ダウンロード処理の流れを示す図の例である。

まず、ステップ3000でダウンロード実行順序テーブル600の先頭のダウンロード実行管理テーブルポイタ610が示すダウンロード実行管理テーブル500を読み込む。そして、該ダウンロード実行管理テーブル120の内容に従い、コンテンツ配信サーバにアクセスしてコンテンツの取得要求を行う(ステップ3001)。

コンテンツ配信サーバ２がデータダウンロードを開始すると、ダウンロード実行状態508の値を、初期値の「未ダウンロード」や「中断状態」から「ダウンロード中」に変更する(ステップ3002)。

コンテンツ配信サーバからのデータダウンロードが終了し、ＨＤＤに記録されたデータサイズと配信コンテンツのサイズ507フィールドの値が一致することを確認（ステップ3003）したらステップ3004に進む。配信コンテンツ用メタファイルの所在506のＵＲＬから、コンテンツの再生や検索などのナビゲーション実行に必要な関連情報ファイルをダウンロードし、コンテンツと併せてＨＤＤに登録し（ステップ3005）、ダウンロードの実行状態508の値を「ダウンロード済」に変更する(ステップ3006)。

次に、ダウンロードが完了したコンテンツのダウンロード実行管理テーブル500が属するダウンロード予約管理テーブル400を参照し、これに属する全てのダウンロード実行管理テーブル500についてダウンロード実行状態508をチェックする(ステップ3007)。全てのダウンロード実行状態508が「ダウンロード済」で、更新タイプ404＝「単発」、または、更新タイプ404＝「更新」かつ更新管理情報405の中の更新期限が現在日時より過去であれば（ステップ3008）、それ以上ダウンロード制御メタファイル100を更新する必要はないと判断し、該当ダウンロード予約管理テーブル400と、それに属するダウンロード実行管理テーブル500を全て削除する(ステップ3009)。

なお、ステップ3003で、ＨＤＤに記録されたデータサイズと配信コンテンツのサイズ507フィールドの値が一致しなかった場合は、ステップ3010に進みダウンロードの実行状態508の値を「中断状態」に変更する。

最後に、ダウンロード実行順序テーブル600から、該当するポインタフィールドを削除して、前に詰める(ステップ3011)。

以上の処理を、ダウンロード実行順序テーブル600に登録されたポインタがなくなるまで、すなわちダウンロード対象コンテンツを全てダウンロード処理終了するまで繰り返す（ステップ3012）。

本実施例によれば、ユーザが複数の周期配信コンテンツのダウンロードが指示した時、更新周期の短いものを優先する手段を提供することにより、効率的なコンテンツダウンロードができる。

また、同時に周期的にダウンロードしなくてはならないコンテンツ量を常にチェックする手段を提供することにより、ユーザが周期配信のサービスを多く申し込みすぎて、周期的なコンテンツのダウンロードが間に合わなくなった場合には、警告を発することが出来る。

本発明のコンテンツ配信サービスシステムの機器構成例を示すブロック図の例である。 図1の受信機３のネットワーク対応テレビハードウェア構成図の例である。 ダウンロード制御メタファイルの構成例を示す図の例である。 ダウンロード制御メタファイルの取得手順を示す図の例である。 ダウンローダプログラムの処理の流れを示すフロー図の例である。 ダウンローダ管理情報の構成例を示すデータ図の例である。 ダウンロード実行処理の例を示すフロー図の例である。 ポータルサーバ１が提供するＷｅｂページの一例である。

符号の説明

１：ポータルサーバ、２：コンテンツ配信サーバ、３：受信機、４：ネットワーク １１：アンテナ・チューナ、１２：デスクランブラ、１３：デマルチプレクサ、１４：ビデオオーディオデコーダ、１５：メディア記録制御部、１６：ハードディスク、１７：ハードディスクインタフェース、１８：表示画面、１９：スピーカ、２０：ＣＰＵ、２１：リモコンインタフェース部、２２：ＩＰ（インターネットプロトコル）通信ポート、２３：ランダムアクセスメモリ、２４：リードオンリメモリ、２５：グラフィックオーディオエンジン、２６：映像表示制御部、２７：オーディオ出力制御部、２８：リアルタイムクロック、３０：リモコン、１００：ダウンロード制御メタファイル、１１４：ダウンロードタイプ、１１５：更新制御情報、３００：ダウンローダ管理情報、４００ダウンロード予約管理テーブル、５００：ダウンロード実行管理テーブル、ダウンロード実行順序テーブル

Claims (10)

1. コンテンツ受信装置におけるコンテンツ受信方法であって、
   ダウンローダは、１つ以上のダウンロード制御メタ情報を受信し、
   前記ダウンロード制御メタ情報は、１つ以上のコンテンツのダウンロード実行情報と、当該ダウンロード制御メタ情報の更新周期を有し、
   前記ダウンローダは、更に、
   受信した前記１つ以上のダウンロード制御メタ情報を解析し、前記１つ以上のダウンロード実行情報を１つ以上のダウンロード実行待ち行列に登録し、
   前記更新周期の小さい順に、前記ダウンロード実行管理情報を実行する順序を示すダウンロード実行順序を決定し、
   前記ダウンロード実行順序に基づき前記ダウンロード実行待ち行列に登録された前記コンテンツの受信を行う、コンテンツ受信方法。
2. 前記ダウンロード実行順序を決定する処理は、前記ダウンロード実行管理情報への指定を、前記更新周期の小さい順にダウンロード実行順序情報の先頭から指定することにより行う、請求項１記載のコンテンツ受信方法。
3. 前記ダウンロード制御メタ情報は、当該ダウンロード制御メタ情報が後に更新される更新型か更新されない単発型かを示す更新フラグを有するダウンロード更新情報を有しており、
   前記ダウンローダは、前記ダウンロード制御メタ情報が更新型か単発型かを判定し、
   前記ダウンロード制御メタ情報が更新型の場合は、前記更新型の前記ダウンロード実行情報を、前記単発型の前記ダウンロード実行情報よりも優先して実行する、請求項１記載のコンテンツ受信方法。
4. 前記１つ以上のダウンロード実行待ち行列に基づき受信するコンテンツの容量を取得し、
   前記コンテンツの容量に基づきダウンロード時間を算出し、
   前記ダウンロード時間と、更新回数とに基づき、ダウンロードに要する合計時間を算出し、
   前記合計時間が所定の値を超える場合には、ダウンロードができない旨を出力する、請求項１記載のコンテンツ受信方法。
5. コンテンツ受信装置であって、
   １つ以上のダウンロード制御メタ情報を受信する受信部を備え、
   前記ダウンロード制御メタ情報は、１つ以上のコンテンツのダウンロード実行情報と、当該ダウンロード制御メタ情報の更新周期を有し、更に、
   受信した前記１つ以上のダウンロード制御メタ情報を解析し、前記１つ以上のダウンロード実行情報を１つ以上のダウンロード実行待ち行列に登録する登録部と、
   前記更新周期の小さい順に、前記ダウンロード実行管理情報を実行する順序を示すダウンロード実行順序を決定し、
   前記ダウンロード実行順序に基づき前記ダウンロード実行待ち行列に登録された前記コンテンツの受信を行うダウンロード実行部と、を有する、コンテンツ受信装置。
6. 前記生成部は、前記ダウンロード実行管理情報への指定を、前記更新周期の小さい順にダウンロード実行順序情報の先頭から指定することにより行う、請求項５記載のコンテンツ受信装置。
7. 前記ダウンロード制御メタ情報は、当該ダウンロード制御メタ情報が後に更新される更新型か更新されない単発型かを示す更新フラグを有するダウンロード更新情報を有しており、
   前記登録部は、前記ダウンロード制御メタ情報が更新型か単発型かを判定し、
   前記ダウンロード制御メタ情報が更新型の場合は、前記更新型の前記ダウンロード実行情報を、前記単発型の前記ダウンロード実行情報よりも優先して実行する、請求項５記載のコンテンツ受信装置。
8. 前記１つ以上のダウンロード実行待ち行列に基づき受信するコンテンツの容量を取得し、前記コンテンツの容量に基づきダウンロード時間を算出し、前記ダウンロード時間と、更新回数とに基づき、ダウンロードに要する合計時間を算出する算出部と、
   前記合計時間が所定の値を超える場合に、ダウンロードができない旨を出力する出力部と、を有する、請求項５記載のコンテンツ受信装置。
9. コンテンツ受信装置におけるコンテンツ受信方法であって、
   ダウンローダは、
   １つ以上のダウンロード実行情報を含む１つ以上のダウンロード制御メタ情報を受信し、
   受信した前記１つ以上のダウンロード制御メタ情報を解析し、前記１つ以上のダウンロード実行情報を１つ以上のダウンロード実行管理情報に登録し、
   前記１つ以上のダウンロード実行管理情報を実行する順序を示す、ダウンロード実行順序情報を生成し、
   前記ダウンロード実行順序情報が指し示す前記ダウンロード実行管理情報を読み込み、
   読み込んだ前記ダウンロード実行管理情報に基づき前記コンテンツの受信を行い、
   前記１つ以上のダウンロード実行管理情報に基づき受信するコンテンツの容量を取得し、
   前記コンテンツの容量に基づきダウンロード時間を算出し、
   前記ダウンロード時間と、更新回数とに基づき、ダウンロードに要する合計時間を算出し、
   前記合計時間が所定の値を超える場合には、ダウンロードができない旨を出力する、コンテンツ受信方法。
10. コンテンツ受信装置であって、
    １つ以上のダウンロード実行情報を含む１つ以上のダウンロード制御メタ情報を受信する受信部と、
    受信した前記１つ以上のダウンロード制御メタ情報を解析し、前記１つ以上のダウンロード実行情報を１つ以上のダウンロード実行管理情報に登録する登録部と、
    前記１つ以上のダウンロード実行管理情報を実行する順序を示す、ダウンロード実行順序情報を生成する生成部と、
    前記ダウンロード実行順序情報が指し示す前記ダウンロード実行管理情報を読み込み、読み込んだ前記ダウンロード実行管理情報に基づき前記コンテンツの受信を行うダウンロード実行部と、
    前記１つ以上のダウンロード実行管理情報に基づき受信するコンテンツの容量を取得し、前記コンテンツの容量に基づきダウンロード時間を算出し、前記ダウンロード時間と、更新回数とに基づき、ダウンロードに要する合計時間を算出する算出部と、
    前記合計時間が所定の値を超える場合に、ダウンロードができない旨を出力する出力部
    と、を有する、コンテンツ受信装置。

Images