JP2004173295A - データ放送スケジュールシステム、それに関する装置、方法、記録媒体またはプログラム - Google Patents

Abstract

【課題】 受信端末における任意の前記ディレクトリを登録、削除をコントロールし得るデータ放送スケジュールシステムを提供すること。
【解決手段】 データ放送スケジュールシステムにおいて、送出装置は、データ管理をするディレクトリが空であることを示す空データを送信し、さらに、前記送出装置からデータを受信する受信端末は、前記送出装置から前記空データを受信したとき、前記空データに対応するディレクトリを自動的に削除するデータ削除処理部を有することを特徴とするものである。これにより、送出装置からのデータの蓄積および削除の指示同一の電送形態で伝送することにより、受信装置で特殊処理を行なうことなく、また、処理負荷を与えることなく、所望のデータを削除することができ、受信装置の記録媒体の容量オーバーフローを回避することができる。
【選択図】 図１

Description

本発明は、受信装置にコンテンツを自動蓄積、更新させることを目的とする蓄積データ放送において、受信装置の蓄積領域内の蓄積状態を送出装置から管理するためのコンテンツの送出スケジュール作成およびコンテンツの付随情報付与に関するものである。

受信装置にコンテンツを自動蓄積、更新させることを目的とする蓄積データ放送はすでに知られている。そのような技術としては、例えば特許文献１に記載されたものがある。

デジタル放送においては、従来の映像、音声主体の視聴目的の番組だけでなく、データ放送など多様なサービスが行われている。また、記憶媒体の低価格化、高密度化が進み、受信装置に蓄積装置を接続し、データ放送を一旦蓄積してから利用するサービスも実用化されつつある。蓄積するコンテンツを選択するのは視聴者であり、視聴者は受信装置の蓄積領域の残り容量を確認しながら蓄積できるコンテンツを選択していた。
特開２００１−０５３６９７公報

しかしながら、従来の蓄積データ放送における送出装置は、コンテンツの更新があったことを示す送出スケジュールを作成、送出していた。受信装置は自身が保持していないバージョンのコンテンツが送出されているときのみ受信するよう予約して蓄積、という動作を繰り返すため、受信装置のコンテンツ保持状態によって受信・予約するタイミングと予約対象時刻がばらばらであった。よって、緊急にコンテンツを差し替えたい、ということがあっても、次の予約時間までのスリープ状態に入っている受信装置にはそれを通知することができなかった。また、受信装置によっていつまでスリープ状態なのかがばらばらなので、緊急に差し替えたいコンテンツをいつ送出すべきかを決定することが出来なかった。

また、近年における蓄積データ放送においては、受信装置の蓄積領域を借り、送出側の意図に従ってコンテンツを蓄積させるビジネスも考えられている。このビジネスにおいては、コンテンツを提供するコンテンツ提供者、コンテンツを送出し、受信装置の蓄積領域に蓄積することを保証するプラットフォーム事業者が存在し、プラットフォーム事業者はコンテンツを確実に受信装置の蓄積領域に蓄積させることによりコンテンツ提供者から対価を得ることになる。このビジネスを成立させるためには、プラットフォーム事業者がコンテンツ事業者から蓄積を依頼されたすべてのコンテンツを確実に受信装置の蓄積領域に蓄積させることが必要になる。

本発明は上記従来の不具合ないしは要請に鑑みてなされたもので、その第１の目的は、受信装置内の蓄積領域内にデータを蓄積するに当たり、プラットフォーム事業者がコンテンツ事業者から蓄積を依頼されたコンテンツを確実に受信装置の蓄積領域に蓄積させることができるデータ放送スケジュールシステム、それに関する装置、方法、記録媒体またはプログラムを提供することである。

本発明の第２の目的は、データ送受信動作において、送出装置側において受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成し、受信端末における任意の前記ディレクトリを登録、削除をコントロールし得るデータ放送スケジュールシステム、それに関する装置、方法、記録媒体またはプログラムを提供することである。

本発明は、上記目的を達成するため、伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを送信する送出装置は、データ管理をするディレクトリが空であることを示す空データを送信し、さらに、前記送出装置からデータを受信する受信端末は、前記送出装置から前記空データを受信したとき、前記空データに対応するディレクトリを自動的に削除するデータ削除処理部を有することを特徴とするものである。これにより、送出装置からのデータの蓄積および削除の指示同一の電送形態で伝送することにより、受信装置で特殊処理を行なうことなく、また、処理負荷を与えることなく、所望のデータを削除することができ、受信装置の記録媒体の容量オーバーフローを回避することができる。

本発明はまた、送出装置と受信端末の間におけるデータ送受信動作において、送出装置側において受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成し、受信端末における任意の前記ディレクトリを登録、削除をコントロールし得るデータ放送スケジュールシステム、それに関する装置、方法、記録媒体またはプログラムが提供される。

以上のように、本発明においては、伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを送信する送出装置は、データ管理をするディレクトリが空であることを示す空データを流すノンスクランブルの削除用シリーズを送信し、さらに、前記送出装置からデータを受信する受信端末は、前記送出装置から前記空データを受信したとき、前記空データに対応するディレクトリを自動的に削除するようにしたため、スクランブルされた契約サービスの契約を解除した受信装置に対しても確実にコンテンツの削除を指示することが可能となる。

また、コンテンツに対し送出装置で提示期限を延長しながら付与することにより、サービスの送出終了前に契約を中止した受信装置において、契約終了したサービスのコンテンツ提示を制限することができる。

また、送出装置と受信端末の間におけるデータ送受信動作において、送出装置側において受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成し、受信端末における任意の前記ディレクトリを登録、削除をコントロールし得るようにしているから、受信装置の記録媒体をオーバーフローさせることなく、送出装置側からのコントロールに基づいてデータの送出を行なうことができ、受信装置に常に新しいデータを送信し、蓄積することができる。

上記目的および本発明の利点は添付の図面を参照して行なわれる以下の説明においてより明らかになるであろう。

以下、本発明の参考例および実施の形態について、図を用いて説明する。なお、本発明はこれら参考例或いは実施の形態に何等限定されるものではなく、その要旨を逸脱しない範囲において種々なる態様で実施し得る。

（参考例１）
まず本発明の送出装置および受信装置の基本動作を説明する。

図１は、本発明の参考例１によるコンテンツの送出装置および受信装置の構成例を示すブロック図である。

図１に示された送出装置は、コンテンツの登録要求があった場合、登録されているコンテンツ情報と照合し、コンテンツID、サイズなどが設定通りであるか確認するコンテンツ登録部１０１、コンテンツ情報を蓄積するコンテンツ情報蓄積部１０２、放送スケジュールの雛型を作成する基本スケジュール作成部１０３、基本スケジュールに緊急変更用スケジュールを設定する緊急変更用スケジュール設定部１０４、基本スケジュールを蓄積する基本スケジュール蓄積部１０５、基本スケジュールから放送スケジュールを作成する放送スケジュール作成部１０６、放送スケジュールを蓄積し、コンテンツに対して送出を指示する放送スケジュール蓄積部１０７、放送スケジュール蓄積部１０７が蓄積する放送スケジュールに従ってコンテンツを送出するコンテンツ蓄積部１０８、コンテンツと放送スケジュールを送出する送出部１０９より構成される。

また、図１に示された受信装置は、放送スケジュールとコンテンツを受信する受信部１１０、放送スケジュールを蓄積する放送スケジュール蓄積部１１１、受信部を起動させるために予約する予約部１１２、受信したコンテンツを蓄積するコンテンツ蓄積部１１３、コンテンツを表示するコンテンツ表示部１１４より構成される。

次に本参考例に係る送出装置の動作について説明する。図８は本参考例の送出装置の動作を説明するフローチャートである。

図８において、処理ステップ（以下単にステップという）８０１で、コンテンツ情報蓄積部１０２に蓄積されているコンテンツ情報は、コンテンツ登録に先立って事前に設定され、基本スケジュール作成部１０３へ渡される。 以下、コンテンツ情報を図２のコンテンツ情報の例を用いて説明する。コンテンツ情報は、コンテンツIDと、そのコンテンツ属性とから構成される。コンテンツ属性は、例えば、課金、更新頻度、最大サイズ、フィルタリング情報（地域）などより構成される。例えば、課金単位はGOLD、SILVER、BRONZEであり、更新頻度は、週１回、日１回の２種類などである。またフィルタリング情報として、地域情報をもつ場合もある。地域区分は、全国や地域別（東北、関東、東海、近畿など）に分けられる。コンテンツID１は、課金なし、更新頻度は日に１回、コンテンツの最大サイズは５００MB、地域は全国というコンテンツ属性をもつ。他のコンテンツについても同様にコンテンツ属性が設定されている。コンテンツID７００は更新頻度において強制起動と定義されているが、これについては後述する。

コンテンツ情報を事前に設定するのは、上述の発明が解決しようとする課題で述べたように、コンテンツ事業者からコンテンツの蓄積を依頼されたプラットフォーム事業者が確実にコンテンツを受信装置の蓄積領域に蓄積することを保証するためである。プラットフォーム事業者は、受信装置の蓄積容量以上のコンテンツ蓄積を依頼された場合、コンテンツの蓄積を保証することができない。そのため、各コンテンツ事業者のコンテンツごとにあらかじめ最大サイズを設定する必要がある。すべてのコンテンツを受信装置の蓄積領域に蓄積させるための必要条件として、各コンテンツ事業者は設定した最大サイズを守らなければならない。最大サイズ以外の属性については、後述するように基本スケジュール作成部１０３が基本スケジュールを作成するために必要とする情報である。

コンテンツ情報を受け取った基本スケジュール作成部１０３は、基本スケジュール作成に先立ってシリーズ設定表を作成しておく。シリーズ設定表の作成を図１３のシリーズ設定表の例を用いて説明する（シリーズは、受信単位を識別するためのものであり、受信装置はシリーズを受信判断に用いる）。基本スケジュール作成部１０３は、シリーズに対し属性（更新頻度、課金単位、フィルタリング情報、など）を設定する。シリーズには、あらかじめ属性を設定されたシリーズ（図１３においてはシリーズID１００、シリーズID１〜シリーズID５、…）と、シリーズ設定表においては属性を設定しない予備分のシリーズ（シリーズID１９、…）に分けられる。例えば、図１３におけるシリーズID２では、課金Gold、更新頻度日１回、北海道向けのコンテンツを送出することを示している。

あらかじめ設定されたシリーズには、起動強制用シリーズID１００も含まれる。起動強制用シリーズID１００はシリーズにおける伝送バージョンであるepisode・＿numberが放送スケジュールにおいて毎回上がるため、受信装置はepisode ＿numberによってシリーズでの受信単位においてコンテンツの更新があったと毎回判断し、必ず起動することになる。また、強制起動用シリーズは、他のシリーズと独立の周期で送出するよう設定されるので、強制的に受信機を起動させるタイミングを設定することが可能となる（これについては後で説明する）。予備分のシリーズは、基本スケジュール作成において事前設定されたシリーズの受信単位があらかじめ決められたコンテンツの最大サイズの合計（図１３における最大サイズ）、もしくはある決まった伝送時間以上になる場合、事前設定されたシリーズで伝送することが不可能なコンテンツを伝送するために割り当てるためのものである。また、あらかじめ属性を設定したシリーズの中に対応する属性がないコンテンツを送出するために割り当てられる。ここでは、シリーズごとに最大サイズを決めているが、全シリーズに共通の最大サイズ（もしくは最長伝送時間）、もしくは起動強制用シリーズと起動強制用シリーズ以外でそれぞれに最大サイズ（もしくは最長伝送時間）を設定できるようにしても良い。

以上のように基本スケジュール作成部１０３であらかじめ設定されているシリーズ設定表（図１３）とコンテンツ情報蓄積部１０２から受け取ったコンテンツ情報（図２）を使って、シリーズとコンテンツの対応表を作成する。作成手順について、図２、図４、図１３を用いて説明する。基本スケジュール作成部１０３は、コンテンツ属性とシリーズ属性よりシリーズとコンテンツの対応関係を定め、基本スケジュールを作成する。具体的には、図２のコンテンツ情報におけるコンテンツ属性（課金、更新頻度、地域）が図１３におけるシリーズ属性（課金、更新頻度、地域）と一致し、シリーズの最大サイズにコンテンツ群の合計サイズが収まる場合、シリーズとコンテンツを対応づけるとする。例えば、図２のコンテンツ情報においてコンテンツID１とコンテンツID７の属性は、課金無し、更新頻度日に１回、地域全国である。また図１３においてシリーズID１の属性は、課金無し、更新頻度日に１回、地域全国であるため、コンテンツID１、コンテンツID７の属性と一致する。また、コンテンツID１とコンテンツID７の合計サイズ1500MBは、シリーズID１の最大サイズ2000MB以下であるので、コンテンツID１とコンテンツID７をシリーズID１へ対応づけることができる。結果として、図４のシリーズとコンテンツの対応表において、シリーズID１のコンテンツ群としてコンテンツID１とコンテンツ７が記述される。他のコンテンツも同様に属性の関係よりシリーズを対応づける（属性が強制起動に設定されているコンテンツについても同様）。

ここで、コンテンツID２（図２の２０１）は、属性よりシリーズID２に対応づけられる（図４の４０１）が、コンテンツID６（図２の２０２）は、属性が一致するにもかかわらずシリーズID２ではなくシリーズID１９に対応させられている（図４の４０２）。これは、シリーズID２の最大サイズが図１３から分かるように4000MBであるため、コンテンツID６（サイズ1000MB）をシリーズID２へ追加した場合、コンテンツ群のサイズが5000MBとなり、最大サイズを超えてしまうからである。この場合、シリーズID２と同じ属性をもつシリーズを予備分のシリーズから割り当てる。ここでは、シリーズID１９をシリーズID２と同じ属性をもつように設定する。そして、この新規に割り当てたシリーズID１９に、コンテンツID６を対応させる（図４の４０２）。結果として、図１３のシリーズ設定表から、図３のようなシリーズ表と図４のようなシリーズとコンテンツの対応表のシリーズIDとコンテンツ群の対応部分が作成される。

次に基本スケジュール作成部１０３は、図４のシリーズとコンテンツの対応表におけるシリーズ毎の最大サイズと伝送時間を計算する。シリーズの最大サイズとは、シリーズに対応付けられたコンテンツの最大サイズの合計である。例えば、図４のシリーズとコンテンツの対応表において、シリーズ１にはコンテンツID１とコンテンツID７が対応付けられている。それぞれのコンテンツの最大サイズは、図２のコンテンツ情報から500MB と1000MBであることが分かるので、これらの合計である1500MBを図４のシリーズID１の最大サイズの欄に記述する。以降、すべてのシリーズIDについてこの処理を繰り返すことによって、図４のようなシリーズとコンテンツの対応表が完成する。

次に、図３のシリーズ表と、図４のシリーズとコンテンツの対応表から図５の基本スケジュールを作成する動作の流れを説明する。図４のコンテンツ毎の伝送時間よりある長さの基本スケジュールを作成する（図５の例では２４時間としている）。基本スケジュールとは放送スケジュールを作成するための雛型であり、この基本スケジュールを繰り返し送出することになる。これは、蓄積データ放送においては、いつ受信装置が購入されるか分からないためであり、どんなタイミングで受信を開始した受信装置でもある程度受信すれば、すべてのコンテンツが蓄積装置内に揃うようにするためである。そのために、更新がないコンテンツも繰り返し送出する必要があり、基本スケジュールはその繰り返しのための雛型である。

まず最初に、シリーズ表において強制起動用となっているシリーズID１００を基本スケジュール上に配置する。強制起動用シリーズの配置ポリシーは基本スケジュール作成部が保持する図３４の強制起動用シリーズの配置ポリシー表によって示されるものであり、どのような間隔、頻度で強制起動用シリーズを配置するのかを示す。例えば、図３４においては2.8 時間ごととしているが、この他にも日に何回送るのか、などの設定方法が考えられる。このポリシーはシステムを運用する上で的確な値を設定することとする。例えば、強制起動用シリーズの頻度によって後述の緊急コンテンツ更新がどれくらい早急に行えるかが変わるので、コンテンツの緊急更新をどれくらい早く行なえるようにしておくか、ということからポリシーを設定しておくべきである。また逆に強制起動用シリーズを頻繁に入れすぎると、通常のコンテンツの送出頻度が下がってしまうので、その点とのトレードオフでポリシーを決定する必要がある。図５の例では、図３４の強制起動用シリーズの配置ポリシー表に従い、約2.8・時間の間隔で強制起動用シリーズを配置している。またここでは、強制起動用シリーズの配置ポリシー表の値を、ある程度の目安として基本スケジュールに放送時間の空きがないように配置したが、必ず強制起動用シリーズの配置ポリシーを守るようにすることも考えられる（その場合には、基本スケジュールに放送時間の空きが発生することもあり得る）。

強制起動用シリーズ以外のシリーズについては、図３のシリーズ表の記述順で図５の基本スケジュールに設定してゆくが、同じ属性のシリーズは続けて送出されるようスケジュール上隣接して配置する。例えば、図３のシリーズ表において、シリーズID２とシリーズID１９は同じ属性であるため隣接して配置する（図５の５０１）。また、全てのシリーズの伝送時間の合計が、24時間に満たない場合、スケジュールの先頭部分のシリーズから再度リダンダント分として配置し、24時間の基本スケジュールにする。図5・の例においては、基本スケジュールの先頭部分であるシリーズID１００、シリーズID１、シリーズID２、シリーズID１９をリダンダント分として加える。それ以降のシリーズ（シリーズID３、シリーズID４、シリーズID５、…）は、基本スケジュールの24時間枠に入らないため、リダンダント分として加えることができない。基本スケジュール（図５）における伝送時間は、図４のシリーズとコンテンツの対応表においてシリーズごとに記述されている伝送時間の値を設定する。

以上の処理によって基本スケジュール作成が完了し（ステップ８０２）、基本スケジュールは基本スケジュール蓄積部１０５へ登録（ステップ８０３）され、放送スケジュール作成部１０６へ渡される。

以下、放送スケジュールの作成を図５と図６を例にして説明する。放送スケジュール作成部１０６は、決まった時刻（例えば、毎日N 時）に起動して、基本スケジュールより全てのシリーズを時間軸上に編成し、放送スケジュールを作成する（ステップ８０４）。図６は図５の基本スケジュールより作成された放送スケジュールの例である。放送スケジュールは、基本スケジュールと同様の属性に加え、放送時間とepisode ＿numberより構成される。放送時間は、シリーズの伝送時間と基本スケジュールのスケジュール順によって計算できる。例えば、放送スケジュールが0 時から始まる場合、最初のシリーズID１００は伝送時間が0.40時間（24分）であるので、放送スケジュールの放送時間は0:00〜0:24と設定する。次のシリーズID１はシリーズID１の放送終了時刻0:24から始まり、伝送時間は同じく0.40時間（24分）であるので、放送時間は0:24〜0:48と設定する。以降のシリーズについてもすべて同様の計算によって放送時間を計算する。

また、シリーズ毎にepisode ＿numberを付与する。episode ＿numberは、バージョンの役割をもち、同じシリーズのイベントにおいて変更の可能性がない場合は、episode ＿numberは同じものを付与する。伝送するコンテンツに変更の可能性がある場合は、episode ＿numberを更新する。放送スケジュールはコンテンツ送出よりもある程度前に受信装置に送出する必要があるが、コンテンツの登録は送出開始間際まで受け付けることを可能とするため、あらかじめ設定した更新頻度によってepisode ＿numberを付与した送出スケジュールを作成し、コンテンツの登録に先立って受信装置に対し送信する。図１４の2001年3 月12日の放送スケジュールの例では、シリーズ１００の強制起動用シリーズの最終episode ＿numberは１２であるので、図６の2001年3 月12日の放送スケジュールでは１３から付与する。強制起動用シリーズは放送のたびにepisode ＿numberを上げる。これにより、受信装置は強制起動用シリーズのコンテンツに更新がある可能性を検出し、強制起動用シリーズの放送時間は必ず起動するようになる（受信装置の動作については、後述する）。シリーズID１は更新頻度が日に１回であるので、episode ＿numberは図１４の2001年3 月12日の放送スケジュールにおける４に１加え、図６の2001年3 月12日の放送スケジュールにおいては５とする。その他の更新頻度が日に１回のシリーズについても同様の処理を行う。

リダンダント分については同じ日において送出時間が早いシリーズと同じepisode ＿numberを付与する。例えば、図６の2001年3 月12日の放送スケジュールにおいてリダンダント分の22:21 〜22:45 のシリーズＩＤ１のepisode ＿numberは５であるが、これは0:24〜0:48のシリーズＩＤ１のepisode ＿numberと同じ値を付与している。週１回更新のシリーズについては、前回episode ＿numberを更新してから１週間経過したときのみepisode ＿numberを上げる。図示していないが例えばシリーズID３のepisode ＿numberを前回更新したのが2001年3 月10日で、シリーズID４のepisode ＿numberを前回更新したのが2001年3 月6 日だった場合、シリーズID３は前回更新から3 日しか経過していないのでepisode ＿numberを上げないが、シリーズID４は前回更新からちょうど１週間経過しているのでepisode ＿numberを上げることになる。結果、図５と比較して図６では、シリーズID３のepisode ＿numberは上がっていないが、シリーズID４のepisode ＿numberは３から４へ上がっている。

このようにして放送スケジュールを作成する（ステップ８０４）。完成した放送スケジュールは、放送スケジュール蓄積部１０７へ登録される（ステップ８０５）。

コンテンツ蓄積部１０８は、放送スケジュールより該当シリーズ（シリーズID１）に対応したコンテンツ（コンテンツID１とコンテンツID７）を基本スケジュール蓄積部１０５より見つけ出す。そして、その該当コンテンツ（コンテンツID１とコンテンツID７）を放送スケジュールに従って送出部１０９に渡す（ステップ８０６）。0:00〜0:24は、シリーズID１に対応するコンテンツID１とコンテンツID７を送出する。その際、課金の属性を参照し、Gold、Silver、Bronzeのいずれかに設定されているシリーズはスクランブルをかけて送出する。課金無しのシリーズはノンスクランブルで送出する。以降、放送スケジュール上のシリーズそれぞれについて同様の処理を行い、送出部１０９は、放送スケジュールとコンテンツを送出する（ステップ８０７）。コンテンツの登録は、コンテンツ登録部１０１を介して行われるが、送出部１０９はコンテンツの送出時に登録されているコンテンツを送出する。

なおリダンダント分の作り方は、上記説明においては、強制起動用シリーズを除いた基本スケジュールの先頭分の繰り返しとした（シリーズID１００、シリーズID１、シリーズID２、シリーズID１９の基本スケジュール通りの順番）が、リダンダント分のスケジュールは、シリーズをランダム（シリーズID１９、シリーズID５、シリーズID３などのランダムな順番）に並べても良いし、リング状（1 日目はシリーズID１、シリーズID２、シリーズID１９、2 日目はシリーズID３、シリーズID４、シリーズID５、3 日目がシリーズID１、シリーズID２、シリーズID１９）にイベントを並べても良い。このようにリダンダント分のスケジュールを作成することによって、受信装置において、受信禁止時間が設定された場合でも、コンテンツを受信することが可能になる。

受信禁止時間は、受信装置が動作するための音が気になる視聴者が例えば深夜などに設定することが考えられる。受信禁止時間が設定された場合、受信装置は毎日その時間に対しては予約もできないし、起動もしない。例えば、毎日図６のような放送スケジュールが作成されるときに、2:30〜2:40に受信禁止時間を設定した受信装置があった場合、その受信装置は2:27〜2:42のシリーズID４は受信できないことになってしまう。先頭分繰り返してリダンダント分をスケジュールする方式では、シリーズID４は毎日１回しか送出されないので、この受信装置はシリーズID４を受信する機会が全くないことになってしまう。リダンダント分としてシリーズをランダムに並べたり、リング状に並べたりすることにより、受信禁止時間を設定した受信装置においても、ある程度の期間内ですべてのシリーズを受信する機会を得ることになる。また、各コンテンツの送出頻度を同じにすることができる。

以上のように、コンテンツ情報から放送スケジュールの雛型である基本スケジュールを作成し、それを繰り返す放送スケジュールを作成することにより、登録するたびに変更する可能性のあるコンテンツの実サイズや、登録のタイミングに依存することなく、コンテンツ送出に先立って放送スケジュールを作成することが可能となる。

また、基本スケジュール作成時には、コンテンツの更新頻度が同じものを同じスケジュールにまとめており、これによって受信単位ごとに効率的にepisode ＿numberを上げることが可能となる。例えば、更新頻度が日に１回と週に１回と設定されているコンテンツを同じシリーズに割り当ててしまうと、そのシリーズは結果として毎日episode ＿numberが上がることになるが、シリーズに含まれる週１回しか更新されないコンテンツも受信装置は毎日受信することになり、無駄である。また、課金単位が同じコンテンツを同じシリーズに割り当てているが、これによりシリーズの放送時間ごとにスクランブルをかけることが可能となり、現状のBSデジタルなどで採用されている伝送路単位でスクランブルをかける方式を利用することも可能となる。また、地域などのフィルタリング情報ごとにシリーズを割り当てることにより、受信装置がすべてのシリーズを受信する必要がなく、放送スケジュールを参照して地域が一致するシリーズだけを受信すれば良い。属性ごとにシリーズを割り当てることにより、受信装置では必要なシリーズだけを受信することが可能になり、省電力になる。

また基本スケジュール作成時に、設定されたコンテンツの最大サイズの合計や伝送時間以上にならないようシリーズを分割しているが、これは受信装置がシリーズの受信・蓄積に失敗した場合、取り直しに必要な時間が長くなることを回避するためである。また、同じ属性のシリーズを隣接するよう放送スケジュール作成時に配置しているが、これはスリープ、起動処理の回数をなるべく減らすためである。

次に本参考例に係る受信装置の基本動作を説明する。図１２は本参考例に係る受信装置の動作を説明するフローチャートである。図１２において、受信部１１０は、放送スケジュール（図６）を受信し（ステップ１２０１）、放送スケジュール蓄積部１１１へ登録する（ステップ１２０２）。

予約部１１２は、図７のような蓄積済み最終episode ＿number表と放送スケジュール蓄積部１１１の放送スケジュール（図６）を比べて放送時間の最も早いepisode ＿numberが変更されているシリーズを予約すべきもの（７０１）と判断する（ステップ１２０３）。この処理について、以下詳しく説明する。

現在時刻がシリーズID５を受信終了した直後（2:03）であるとすると、次のシリーズであるシリーズID3 のepisode ＿numberが４であり、図７の蓄積済み最終episode ＿number表のシリーズID３のepisode ＿numberに比較して更新されているので、シリーズID３を受信するために必要な伝送路（図示しないが放送スケジュールに記述されていることとする）、シリーズID、episode ＿numberの情報の１組を予約情報として登録する（ステップ１２０４）。

そして、予約部１１２は予約時間に沿って、該当シリーズのコンテンツを受信するよう受信部１１０を起動させる（ステップ１２０５）。受信部１１０は、該当シリーズのコンテンツを受信し（ステップ１２０６）、空コンテンツでなければ（ステップ１２０７）、コンテンツ蓄積部１１３へ登録する（ステップ１２０９）。空コンテンツについては参考例３において説明する。登録が完了したら、予約部１１２へ通知し、予約情報を蓄積積みepisode ＿numberとして登録する。図７の例では、予約情報として登録されたシリーズID3 のコンテンツがコンテンツ蓄積部１１３へ登録された通知を受け取ったら、蓄積済み最終episode ＿number表の該当シリーズの蓄積済み最終episode ＿numberを変更する（ステップ１２１０）。結果として、シリーズID３の蓄積済み最終episode ＿numberが３から４に更新されている。

その後受信部１１０は、再び放送スケジュールを受信し、ステップ１２０１以降の動作を受信装置は繰り返し行う。

以上のようにepisode ＿numberが更新されたシリーズだけを予約し、受信・蓄積することを繰り返すことにより、更新可能性のあるシリーズだけを受信することが可能となる。ここまでは事前に更新頻度を設定し、設定通りにコンテンツを更新する場合について説明したが、次に緊急にコンテンツを変更することを可能にする送出装置の動作を図９を用いて説明する。

緊急とは、例えば更新頻度が週１回でコンテンツの受け入れが月曜日のみというようにあらかじめ設定されているコンテンツを急きょ前の金曜日に登録する場合などである。

緊急変更用スケジュール設定部１０４は、基本スケジュール作成部１０３が作成したしリーズ設定表に対しあらかじめ緊急変更用シリーズを設定し、基本スケジュール作成部１０３へ渡す（ステップ９０１）。緊急変更用シリーズを設定したシリーズ設定表とは、例えば図１５のようなもので、ここでは強制起動用シリーズの直後に緊急変更用シリーズが設定されている。

コンテンツ情報から基本スケジュール作成までの流れは、緊急変更用シリーズにコンテンツを割り当てないこととを除いては、基本動作で説明した流れと同じである。つまり、シリーズとコンテンツの対応表は図１６のように、緊急変更用シリーズであるシリーズID２００のコンテンツ群の欄は空欄になる。また、放送スケジュール作成において、緊急変更用シリーズはepisode ＿numberを更新しないことを除いて、参考例１で示した流れと同じである。episode ＿numberを更新しないのは、緊急更新がなくても受信装置が毎回緊急変更用シリーズを予約して受信してしまうことを回避するためである。緊急更新があったときのみepisode ＿numberを更新する。

コンテンツ登録部１０１はコンテンツの登録要求があった場合（ステップ９０２）、当該コンテンツを、コンテンツ情報蓄積部１０２に蓄積されているコンテンツ情報と照合し、コンテンツID、サイズなどが設定通りであるかどうかを確認し（ステップ９０３）、コンテンツ蓄積部１０８へ登録する。もし緊急でない場合は、コンテンツ送出においては、緊急変更用シリーズにはコンテンツが割り当てられていないので、緊急変更用シリーズの時間は何も送出されない。もし、緊急であることを検知した場合には、基本スケジュール作成部１０３に緊急にコンテンツを変更することを通知する（ステップ９０４）。

基本スケジュール作成部１０３は、コンテンツを緊急変更用シリーズに対応させシリーズとコンテンツの対応表を再作成する（ステップ９０５）。例えば、コンテンツID７のコンテンツの緊急更新だった場合には、結果として図１７のようなシリーズとコンテンツの対応表が作成され、基本スケジュール蓄積部１０５へ登録される（ステップ９０６）。図１７のシリーズとコンテンツの対応表においては、図１６と比較して緊急更新用シリーズのシリーズ２００に対し、コンテンツID７が割り当てられていることが分かる。

基本スケジュール蓄積部１０５は、作成したシリーズとコンテンツの対応表（図１７）を放送スケジュール作成部１０６へ渡す。放送スケジュール作成部１０６は、コンテンツ登録部１０１からの緊急にコンテンツを変更する通知を受けて、直ちにすでに作成済みの放送スケジュールうち、現在送出中のものとこれから送出中のものについて緊急更新用シリーズのepisode ＿numberを上げる処理を行う（ステップ９０７）。再作成した放送スケジュールは放送スケジュール蓄積部１０７へ登録する（ステップ９０８）。

コンテンツ蓄積部１０８（ステップ９０９）、送出部１０９（ステップ９１０）は上記、基本動作と同じである。シリーズとコンテンツの対応表（図１７）において、緊急更新すべきコンテンツ（コンテンツID７）が緊急更新シリーズに割り当てられているので、緊急更新シリーズの放送時間にはコンテンツID７が送出されることになる。

この場合における受信装置の動作は基本動作と同じである。起動強制用シリーズのepisode ＿numberは必ず変更されているので、起動強制用シリーズのコンテンツを受信する際に、必ず受信機は起動し、予約処理を行う。そのため、起動強制用シリーズの直後のepisode ＿numberが上がった緊急変更用シリーズのコンテンツも受信・蓄積することができる。また、緊急変更がない場合には、緊急変更用シリーズのepisode ＿numberは変更されていないため、受信装置が緊急変更用シリーズを受信することはない。緊急にコンテンツを変更することがある場合にのみepisode ＿numberを変更してシリーズを受信させ、コンテンツの緊急更新を行うことが可能である。

また本参考例では、緊急更新用シリーズを必ず強制起動用シリーズの直後に配置するかのように記述したが、強制起動用シリーズ間に１つ以上配置するように配置しても良い。

以上のように、あらかじめ基本スケジュールにおいて緊急更新用シリーズを強制起動用シリーズ間に配置することにより、少なくとも強制起動用シリーズの頻度でコンテンツの緊急更新に対応することが可能となる。また、コンテンツの緊急更新が発生した場合の放送スケジュールにおける変更が、緊急更新用シリーズのepisode ＿numberだけで済む。

（参考例２）
図３５は本参考例における送出装置と受信装置の構成を示すブロック図である。緊急変更用スケジュール設定部１０４がなく、緊急変更コンテンツ設定部３５０１を追加している以外は、参考例１におけるブロック図と同じである。

本参考例では、緊急にコンテンツを変更することを可能にする、緊急変更用シリーズを使わない場合の送出装置側の動作を図１０を用いて説明する。

コンテンツの緊急変更がない場合の動作は、参考例１と同じである。以下、緊急変更がある場合について説明する。

コンテンツ登録部１０１は登録要求（ステップ１００１）されたコンテンツを、コンテンツ情報蓄積部１０２に蓄積されているコンテンツ情報と照合し、コンテンツID、サイズなどが設定通りであるかどうかを確認し、コンテンツをコンテンツ蓄積部１０８へ登録する（ステップ１００２）。そのとき緊急であることを検知したならば、放送スケジュール作成部１０６に緊急にコンテンツを変更することを通知する（ステップ８０３）。緊急の定義は参考例１と同じであり、あらかじめ設定した更新頻度よりも早く更新する場合などである。

放送スケジュール作成部１０６は、緊急変更コンテンツ設定部３５０１に放送スケジュール蓄積部１０７から取得した放送スケジュールを渡し、緊急変更コンテンツ設定部３５０１は現在時刻に対し直近の強制起動用シリーズの直後以降において緊急変更するコンテンツを送出するシリーズのepisode ＿numberを上げる（ステップ１００４）。再作成された放送スケジュールは放送スケジュール蓄積部１０７に渡される（ステップ１００５）。

コンテンツ蓄積部１０８（ステップ１００６）、送出部１０９（ステップ１００７）は、基本動作と同じであり、ステップ１００５においてepisode ＿numberを上げたシリーズにおいて、緊急更新したコンテンツが送出される（ステップ１００６、ステップ１００７）。

この場合における受信装置の動作も基本動作と同じである。起動強制用シリーズのepisode ＿numberは必ず変更されているので、起動強制用シリーズのコンテンツを受信する際に、必ず受信機は起動し、予約処理を行う。そのため、起動強制用シリーズの以降のepisode ＿numberが上がったシリーズのコンテンツも受信・蓄積することができる。結果として、緊急更新のコンテンツを送出するシリーズのコンテンツも受信・蓄積することができる。

以上のように、強制起動用シリーズをある頻度で放送スケジュールに配置することにより、必ず受信装置が起動する時間を特定することが可能となり、同じ頻度での緊急更新を送出装置として保証することが可能となる。

（参考例３）
本参考例においては、契約コンテンツの削除を受信装置に指示する際に、削除用シリーズを使う場合の動作について説明する。まず、契約コンテンツの削除指示における問題点について説明する。

契約が必要なサービスを実施する場合、受信装置がどのような組み合せでサービスを選択して契約しても、受信装置の蓄積領域があふれないようにする必要がある。例えば、ある受信装置の蓄積領域が500 ＭＢの場合、100 ＭＢを必要とするサービスＡ、350 ＭＢを必要とするサービスＢ、200 ＭＢを必要とするサービスＣを選択して契約してしまうと、すべてのサービスのコンテンツを蓄積し切れず、いずれ蓄積領域があふれてしまう。このような状態を回避するための最も簡単な方法として、すべてのサービスを選択してもあふれないよう、あらかじめサービスに必要な容量を制限してしまうことが考えられる。例えば、図１８のように各受信機の蓄積領域のサイズが700MB であるときには、送出装置で選択対象となるサービスの合計を700MB におさまるようにあらかじめ設定する。これにより、受信装置がどのような組合せで選択しても必ず選択したサービスのコンテンツをすべて蓄積することができる。

このような場合に、サービスの追加・削除があった場合の課題を述べる。ここで、選択対象のサービスはスクランブルされており、受信装置が契約処理をした場合にデスクランブルするための鍵を受信装置に渡し、契約を解約した場合には鍵の無効化処理が行われることとする。図１８のような状態のときに、受信装置１がサービスC を解約したとする。その結果、受信装置１ではサービスC のデスクランブルができなくなり、サービスC のコンテンツの更新が行われなくなる。このように受信装置で解約処理が行われた後に、例えばサービスC が図１９のようにコンテンツ１とコンテンツ２から構成されているとき（状態１）に、コンテンツ２を提供する事業者が提供を中止したとする。それにより、図１９の状態２のようにサービスC のコンテンツ２は設定から削除され、送出装置での管理上受信装置での蓄積装置は75MBが余ることになる。送出装置は、設定から削除されたコンテンツ２を削除するための空コンテンツをサービスC で送出する。空コンテンツとは、削除させたいコンテンツのIDだけが記述してあるコンテンツであり、受信装置は空コンテンツを受け取るとそのIDを持つコンテンツを削除する。しかしこの場合、受信装置１はすでにサービスC の契約を解除しているため、コンテンツ２を記述した空コンテンツを受け取ることができず、コンテンツ２を削除しない。その後、その余った領域に対し、コンテンツ５を提供する事業者が現れ、コンテンツ５をサービスD に追加する（状態３）。

その後、受信装置１においてサービスD・に対する契約処理が行われると、受信装置１はサービスD の鍵を受け取り、サービスD の蓄積を開始する。しかし、受信装置１では蓄積領域が250MB しか余っておらず、325MB を必要とするサービスD・のコンテンツをすべて蓄積することができない。

以上の課題を解決するための送出装置側の動作を説明する。

図２０は本参考例における送出装置と受信装置の構成を示すブロック図である。緊急変更用スケジュール設定部１０４が削除用シリーズ設定部２００１となっている以外は、参考例１におけるブロック図と同じである。

本参考例における送出装置の動作を図１１のフロー図で説明する。ある契約サービスでコンテンツを送出しているコンテンツ事業者からコンテンツの送出を止めたい、との申し出があった場合には、コンテンツ情報から当該コンテンツの設定削除を行う（ステップ１１０２）。コンテンツ情報蓄積部１０２は、コンテンツの設定削除があった場合には、削除されたことを示すフラグを立てる。例えば図２２のコンテンツ情報では、コンテンツID７７が削除されたことを示すフラグが立っている。削除用シリーズ設定部２００１は、基本スケジュール作成部１０３が保持するシリーズ設定表に対し削除用シリーズを設定し、基本スケジュール作成部１０３に渡す（ステップ１１０２）。削除用シリーズを設定したシリーズ設定表とは、例えば図２１のようなもので、ここでは強制起動用シリーズの直後に配置されているが、配置はどこでも良いし、強制起動用シリーズは配置されていなくても良い。また、削除用シリーズはすべての受信装置が受信する必要があるため、スクランブルはかけない（課金は「無」に設定する）。

コンテンツ情報蓄積部１０２からコンテンツ情報（図２２）を受け取った基本スケジュール作成部１０３がシリーズ表、基本スケジュール、シリーズとコンテンツの対応表を作成するまでの処理は、コンテンツ情報において削除のフラグが立っているコンテンツを削除用シリーズに割り当てることを除いて、参考例１における基本動作と同じである（ステップ１１０３）。結果として図２３のようなシリーズとコンテンツの対応表が作成される。図２３において、削除されたコンテンツは通常のコンテンツと区別できるようになっており、送出部１０９がコンテンツを送出する際には、コンテンツID７７のコンテンツについては受信装置にコンテンツ削除を指示するための空コンテンツを送出する。空コンテンツとは、削除させたいコンテンツのIDだけが記述してあるコンテンツであり、受信装置は空コンテンツを受け取るとそのIDを持つコンテンツを削除する。ここまで、基本スケジュールから放送スケジュールを作成し、コンテンツと空コンテンツを送出する処理については、参考例１と同様である（ステップ１１０４〜１１０６）。また、このように設定削除されたコンテンツであることをシリーズとコンテンツの対応表において識別できるようにするのではなく、コンテンツ登録部１０１に空コンテンツを登録させ、コンテンツ蓄積部１０８に蓄積、それを送出部１０９が送出するようにしても良い。

削除用シリーズを使う場合の受信装置側の動作は、空コンテンツを扱う以外は参考例１の基本動作における受信装置の動作と同じである。図１２のフローにおける１２０７において空コンテンツであると判定されるので、空コンテンツに記述されたIDのコンテンツをコンテンツ蓄積図１１３から削除する。

以上のように、空コンテンツを流すノンスクランブルの削除用シリーズを配置することにより、スクランブルされた契約サービスの契約を解除した受信装置に対しても確実にコンテンツの削除を指示することが可能となる。

（参考例４）
上記参考例３においては、送出装置から明示的にコンテンツの削除を指示する空コンテンツを送出する場合について説明したが、本参考例４では送出装置においてコンテンツごとに受信機での提示期限を付与することにより、契約切れとなった受信機でのコンテンツ提示を制限する方法について説明する。

図２４は、本参考例における送出装置と受信装置の構成を示す図である。２４０１はコンテンツに提示期限を付与する提示期限付与部、２４０２はコンテンツに付与された提示期限に従い、コンテンツを表示してよいかどうかを確認するコンテンツ提示期限確認部である。これら以外は参考例１における構成要素と同じである。

視聴者（受信装置）が契約をしてコンテンツを蓄積するようなサービス（以下、契約サービス）を実施している場合、視聴者（受信装置）が契約を解除しても解除前に蓄積したコンテンツを視聴できてしまう、という課題がある。この課題に対し、契約サービスを実施している事業者があらかじめ設定した契約サービスの終了日まで、送出装置がコンテンツの提示期限を延長しながら送出することにより、契約を解除した受信装置においては事業者が設定した契約サービスの終了日にコンテンツの提示を制限することが可能になる。以下、この方式について説明する。

図２５は、本参考例においてコンテンツ情報蓄積部が蓄積するコンテンツ情報の例である。参考例１でのコンテンツ情報と比較して、各コンテンツごとに開始日と終了日が付与されている。例えば、コンテンツIDが１のコンテンツについては当該コンテンツを提供している事業者が送出の開始日を2001年10月１日、終了日を2002年9 月30日に設定していることを意味している。他のコンテンツについても、それぞれのコンテンツを提供している事業者が送出の開始日と終了日を設定している。このようなコンテンツ情報から放送スケジュールを作成するところまでは、参考例１と同じである。

以降の処理について、基本スケジュール蓄積部に図４のようなシリーズとコンテンツの対応表、放送スケジュール蓄積部に図６のような放送スケジュールがそれぞれ蓄積されている場合を例に説明する。図２４におけるコンテンツ蓄積部１０８は放送スケジュール（図６）に従い、0 時24分からシリーズID２の送出を開始する。シリーズID２において送出するコンテンツはシリーズとコンテンツの対応表（図４）からコンテンツID２のコンテンツであると分かる。コンテンツ蓄積部１０８はコンテンツの送出に先立って、提示期限付与部２４０１に対し、コンテンツの提示期限付与を依頼する。この際、コンテンツも受け渡す。コンテンツID２のコンテンツに対する提示期限付与が提示期限付与部２４０１に対し依頼された場合、提示期限付与部２４０１はコンテンツ情報（図６）のコンテンツID２のコンテンツの送出開始日をまず参照する。この場合、2001年７月１日という日付が得られる。

提示期限付与部２４０１は、図２６のようなコンテンツ提示期限延長間隔表と図２９のような提示期限切替タイミング表を保持しており、図２６の例においてはコンテンツ提示期間延長間隔は１ヶ月、図２９の例においては提示期限切替タイミングは５日前となっている。コンテンツ提示期間延長間隔は、コンテンツの送出開始日からどのような間隔で、コンテンツに付与する提示期限を延長するのかを示すものである。提示期限切替タイミングは、提示期限が切れるどのくらい前から提示期限の切替を行うかを示すものである。提示期限の付与と切替について、図２７を用いコンテンツID２のコンテンツを例にして説明する。前述したように、コンテンツID２のコンテンツの送出開始日として2001年７月１日を得ている。提示期限を計算するため、送出開始日にコンテンツ提示期限延長間隔を加える。これにより2001年８月１日と提示期限切替タイミング（図２９）で示された日付から、提示期限を切り替えるタイミングを求める。この場合には、2001年８月１日から（５日＋１日）を引くことにより、提示期限切替タイミングは2001年7 月27日であることが分かる。これよりコンテンツに対し提示期限2001年８月１日を付与する期間2001年７月１日から2001年７月27日（図２７におけるＡで示される期間）が得られる。

以降同様にして（ただし、送出開始日直後以外は提示期限切替タイミング分が期間の最初の日に追加される）、コンテンツに対し提示期限2001年9 月１日を付与する期間2001年7 月27日から2001年8 月27日（図２７におけるＢで示される期間）、コンテンツに対し提示期限2001年10月１日を付与する期間2001年8 月27日から2001年9 月27日（図２７におけるＣで示される期間）のように、送出終了日までコンテンツに対して付与する提示期限と付与する期間の対応を求めることが可能となる。この結果、図２８のようなコンテンツに対し付与する提示期限と付与する期間の対応表が作成される。コンテンツに対し付与する提示期限と付与する期間の対応表の作成フローを図３３に示す。

このような場合に、現在日が2001年7 月15日であるときには、2001年7 月15日が付与する期間として含まれるエントリを図２８から検索することにより、コンテンツID２のコンテンツに付与する提示期限が2001年8 月1 日であることが分かる。よって、提示期限付与部２４０１はコンテンツID２のコンテンツに提示期限として2001年8 月1 日を付与してコンテンツ蓄積部１０８に返す。

提示期限が付与されたコンテンツ蓄積部１０８は、送出部１０９にコンテンツを渡し、送出部１０９はコンテンツを送出する。送出部１０９から送出されるコンテンツは図３０のようなイメージである。ヘッダのコンテンツIDや実サイズなどといっしょに提示期限が含まれ、伝送される。コンテンツ蓄積部１０２から提示期限付与部２４０１に対し、提示期限付与が依頼されてから提示期限付与部２４０１がコンテンツをコンテンツ蓄積部１０８に返すまでの提示期限付与の処理フローを図３２に示す。

以上の説明では、コンテンツ提示期限延長間隔（図２６）や提示期限切替タイミング（図２９）は、提示期限付与部２４０１内で一つだけ保持しているように説明したが、コンテンツごとに設定できるようにしても構わない。また、提示期限付与部２４０１に対し、コンテンツの提示期限付与が依頼される度にコンテンツに対し付与する提示期限と付与する期間の対応表を作成する必要はなく、最初の依頼のときやコンテンツ情報にコンテンツが登録されたときに作成し、以降はコンテンツ提示期限延長間隔表や提示期限切替タイミングが変更になった場合に再作成するようにしても良い。

受信機の蓄積動作は、コンテンツごとに提示期限を管理する以外は参考例１で説明した通りである。提示期限を付与されたコンテンツを受信した受信装置のコンテンツ蓄積部１１３では、コンテンツを図３１のようなコンテンツ管理表で管理している。図３１の例では、コンテンツID２のコンテンツのコンテンツ蓄積部１１３におけるサイズは3570ＭＢ、実体の蓄積先は0x763Aで示される場所、提示期限は2001年8 月1 日である。

このような場合に、受信装置のコンテンツ表示部１１４に対しコンテンツID２のコンテンツの表示要求があったときには、コンテンツ表示部１１４はコンテンツ管理部１１３にその旨通知する。コンテンツ管理部１１３はコンテンツ管理情報からコンテンツID２のコンテンツの実体の蓄積先を検索し、コンテンツの実体を取り出し、コンテンツID２のコンテンツ管理情報を添えてコンテンツ表示部１１４に渡す。コンテンツ表示部１１４は受け取ったコンテンツ管理情報をコンテンツ提示期限確認部２４０２に渡し、コンテンツ提示期限確認部２４０２はコンテンツ管理情報に記述された提示期限と現在日を比較し、提示期限が現在日と同じもしくは現在日よりも未来なら確認結果としてＯＫを返し、もし過去の場合には確認結果としてＮＧを返す。コンテンツ表示部１１４は、確認結果としてＯＫを受け取ったときのみコンテンツを表示する。

また、受信装置ではコンテンツを蓄積しようとしたときに蓄積装置が蓄積する余裕がない（以下、蓄積装置があふれた）場合に、コンテンツに付与された提示期限を検索し、提示期限が切れているコンテンツを削除するようにしても良い。また、前回蓄積装置があふれた日時を保持しておき、蓄積装置のあふれた日時が前回蓄積装置があふれた日時から一定期間以上経過していない場合には、提示期限が切れていないコンテンツの削除処理を行わないようにしても良い。蓄積装置のあふれを一定期間以内に繰り返す場合は、サイズ減少したコンテンツの蓄積もしくは空コンテンツの受信に失敗によるコンテンツ削除に失敗している可能性が高く、基本スケジュールによりコンテンツを繰り返し送出している運用においては、ある期間が経てば受信装置がサイズ減少したコンテンツの蓄積もしくは空コンテンツの受信によって、蓄積装置があふれない状態に戻る可能性が高いため、受信装置に対して負荷が高い削除処理を繰り返させることがないようにするためである。

なお、上記説明ではコンテンツの送出日に応じてコンテンツの提示期限が付与されるよう説明したが、コンテンツ登録部１０１にコンテンツが登録された日時にある期間（例えば１ヶ月）を加えてコンテンツの提示期限として設定するようにしても良い。例えば、2001年9 月5 日に登録されたコンテンツには提示期限として2001年10月5 日を付与して送出する。

以上のように、コンテンツに対し送出装置で提示期限を延長しながら付与することにより、サービスの送出終了前に契約を中止した受信機において、契約終了したサービスのコンテンツ提示を制限することができる。例えば、図２７において、2001年8 月20日に契約を止めた受信機には止めた時点で2001年9 月1 日を提示期限とするコンテンツが蓄積されているが、契約を止めてしまったので2001年10月1 日を提示期限とするコンテンツを蓄積することができない。よって2001年9 月2 日以降はコンテンツが表示されなくなる。契約を継続している受信機では、時間を追うに従って提示期限を2001年9 月1 日とするコンテンツ、2001年10月1 日とするコンテンツ、のように継続して蓄積することが可能であり、提示期限が切れる前に次の提示期限が付与されたコンテンツを蓄積するので、契約を継続する限りコンテンツは提示される。

（実施の形態１）
本実施の形態１では、受信装置に処理負荷を与えることなく受信装置の記録媒体中にある所望のデータを削除する方法、及び受信装置においてデータ毎に付与された提示期間を基にデータの表示可否の制御を行なう方法について説明する。

図３６は、本実施の形態１における送出装置と受信装置の構成を示す図である。この実施の形態１に係る送出装置３６００は、データの登録要件または削除要件を受け付けるデータ受付部３６０１と、データ提供者が指定したデータ提示期間或いは送出装置が自動的に判断したデータ提示期間を付与するデータ提示期間付与部３６０２と、受け付けたデータを蓄積するデータ蓄積部３６０３と、データ提供者からの登録要件や削除要件を受けてどのデータをいつ送出するかのスケジューリングを行ない、且つデータの更新情報やデータに対する課金情報、コピー制御情報等の付加情報の生成を行なう送出スケジュール生成部３６０４と、生成された送出スケジュールを蓄積する送出スケジュール蓄積部３６０５と、送信するデータの運用情報を示すダウンロードデータ制御データを生成するダウンロードデータ制御データ生成部３６０６と、送出スケジュールにしたがってデータ蓄積部３６０５に蓄積されたデータ、送信するデータの運用情報を示すダウンロードデータ制御データを送出し、且つ送出スケジュール蓄積部に蓄積された送出スケジュール自体を送出する送出部３６０７とより構成される。

図９３の受信装置３６１０は、送出されたデータとダウンロードデータ制御データと送出スケジュールとを受信する受信部３６１１、受信した送出スケジュールを蓄積する送出スケジュール蓄積部３６１２、送出スケジュールに付加されたデータの更新を表す情報から更新されたデータの受信時間を判断し、受信部を起動させる受信予約部３６１３、受信したダウンロードデータ制御データから当該データの蓄積或いは削除の判断を行なう蓄積／削除判断部３６１４、受信したデータを蓄積するデータ蓄積部３６１５、視聴者からのデータ表示要求を受け付け所望のデータの表示を行なうデータ表示部３６１６、蓄積／削除判断部３６１４にて削除と判断されたデータをデータ蓄積部３６１５から削除するデータ削除処理部３６１７、データを表示する際、データの提示期間と現在時刻からデータを表示して良いか否かを判断するデータ提示期間判断部３６１８から構成される。

かかる構成を有するデータ送出装置および受信装置について、以下動作を説明する。図３７は本実施の形態１に係るデータ送出装置および受信装置の間におけるデータ送受信の処理動作を説明するフローチャートである。上記データ送出装置および受信装置の動作が開始されると、処理ステップ（以下、単にステップという）３７０１においてデータ送出装置のデータ受入部３６０１により登録要求或いは削除要求の受け付けが行なわれる。この登録要求或いは削除要求が受け入れられると、それが登録要求なのか削除要求なのかのチェックが行なわれる（ステップ３７０２）。このチェック処理において登録要求である場合は、データ提供者が指定したデータ提示期間或いは送出装置３６１０が自動的に判断したデータ提示期間を付与し（ステップ３７０３）、データ蓄積部３６０３へデータを登録する（ステップ３７０４）。

ダウンロードデータ制御データ生成部３６０６は、ステップ３７０２において削除要求であると判断された場合、受信装置３６１０の記録媒体からデータを削除するためのダウンロードデータ制御データを生成し、データ蓄積部３６０３にデータが登録された場合、受信装置３６１０の記録媒体へデータを登録するためのダウンロードデータ制御データを生成する（ステップ３７０５）。送出スケジュール生成部３６０４は、データの登録要件或いはデータの削除要件を反映した送出スケジュールを生成し（ステップ３７０６）、送出スケジュール蓄積部３６０５へ蓄積する（ステップ３７０７）。送出部３６０７は、送出スケジュール送出スケジュール蓄積部３６０５へ登録された送出スケジュールにしたがって、データ蓄積部３６０３へ登録されたデータと、送信するデータの運用情報を示すダウンロードデータ制御データ、および送出スケジュール自身を放送または通信ネットワークを介して受信装置３６１０へ送出する（ステップ３７０８）。

ステップ３７０５で生成するダウンロードデータ制御データについて説明する。図３８は上記ダウンロードデータ制御データの構造を示すデータ構造図である。ダウンロードデータ制御データは、受信装置３６１０の記録媒体に対するデータの蓄積指示或いは削除指示を意味している。内容は、対象となるデータのパス名、提示期間、実際に蓄積すべき個々のダウンロードデータの個数、及び個々のダウンロードデータの番号とパス名の繰り返し部分などから構成される。受信装置３６１０の記録媒体へデータを蓄積させる場合、ダウンロードデータ制御データのダウンロードデータ数の項目に１以上の値を設定し、実際に蓄積すべきダウンロードデータとともに受信装置３６１０に対して送出する。受信装置３６１０の記録媒体からデータを削除させる場合、ダウンロードデータ制御データのダウンロードデータ数の項目に０を設定し、受信装置３６１０に対して送出する。

次に受信装置において記録媒体に対するデータの登録、削除動作について説明する。図３９は上記受信装置におけるデータの登録、削除の処理動作を説明するフローチャートである。上記データ送出装置および受信装置の動作が開始されると、受信部３６１１は送出スケジュールを受信し（ステップ３９０１）、送出スケジュール蓄積部３６１２へ登録する（ステップ３９０２）。次に、送出スケジュールにおいてデータの更新があるか否かをチェックし（ステップ３９０３）、データの更新が示されている場合はその更新されたデータが送出される開始・終了時間を予約時間として保持する（ステップ３９０４）。受信予約部３６１３は上記予約時間にしたがって、更新されたデータを取得するために受信部３６１１を起動させ（ステップ３９０５）、受信部３６１１はダウンロードデータ制御データを受信する（ステップ３９０６）。蓄積／削除判断部３６１４は、受信したダウンロードデータ制御データから、そのデータが蓄積指示か削除指示かを判断する（ステップ３９０７）。

蓄積／削除判断部３６１４は、図３８で説明したダウンロードデータ制御データのダウンロードデータ数が０の場合は削除指示であると判断する一方、ダウンロードデータ制御データのダウンロードデータ数が１以上である場合は蓄積指示であると判断する。受信したダウンロードデータ制御データが蓄積指示であると判断された場合、実際に蓄積すべきダウンロードデータを受信し、データ蓄積部３６１５へ蓄積する（ステップ３９０８）。また、受信したダウンロードデータ制御データが削除指示であると判断された場合は、データ削除処理部３６１７が対象データをデータ蓄積部３６１５から削除する（ステップ３９０９）。

次に受信装置における記録媒体に対するデータの削除動作について説明する。図４０は上記受信装置におけるデータの削除の処理による記録媒体中のデータが減少する状況を模式的に示す図である。図４０において、符号４００１は受信装置３６１０の記録媒体に対する削除が行なわれる前の記録媒体のデータ格納状態を示す。また、符号４００２は受信装置３６１０の記録媒体に対する削除が行なわれた後の記録媒体のデータ格納状態を示す。受信装置３６１０は、ダウンロードデータ数が０であるダウンロードデータ制御データ（以下、空データという）を受信した場合、当該空データで示されたパス名（図４０の場合は／Ａ／Ｂ／Ｄ）以下の全てのディレクトリおよびファイルを削除する。受信装置３６１０は、上記削除処理によって当該空データで示されたパス名の上位ディレクトリ（図４０の場合は／Ａ／Ｂ）が空になった場合、その上位ディレクトリも削除する。削除後の受信装置の記録媒体は４００２の状態となる。受信装置３６１０は空データを受信した際、削除対象となるパスが記録媒体に存在しなかった場合は、既に削除済みであると判断する。受信装置３６１０は、空データを受信した際、削除対象となっているデータを視聴者が参照中の場合、参照終了後の任意のタイミングで当該データを削除する。

上記の処理により、送出装置３６００からのデータの蓄積および削除の指示同一の電送形態（フォーマット）で伝送することにより、受信装置３６１０で特殊処理を行なうことなく、また、処理負荷を与えることなく、所望のデータを削除することができ、受信装置３６１０の記録媒体の容量オーバーフローを回避することができる。

図４１は受信装置３６１０においてデータ毎に付与された提示期間を基にデータの表示可否の制御を行なう方法を説明するフローチャートである。データ表示部３６１６は、視聴者からデータの表示要求を受け（ステップ４１０１）、当該データが記録媒体に存在するか否かをデータ管理部３６１５へ確認する（ステップ４１０２）。この確認により、データが存在しなかった場合、当該データは記録媒体に存在しない旨を表示し当該データは表示しない（ステップ４１０７）。他方、この確認により、データが存在した場合、当該データが表示可能か否かをデータ提示期間判断部３６１８へ問い合わせる（ステップ４１０３）。これに対して、データ提示期間判断部３６１８は、現在日時と当該データのデータ提示期間とを比較し（ステップ４１０４）、現在日時が提示期間内であった場合、当該データをデータ表示部３６１６の画面上に表示する（ステップ４１０５）。他方、現在日時が提示期間外であった場合、当該データは既に提示期間外である旨をデータ表示部３６１６の画面上に表示し当該データは表示しない（ステップ４１０６）。

この一連の処理動作を、一具体例について説明する。図４２は受信装置３６１０においてデータ毎に付与された提示期間を基に行なわれるデータの表示可否の制御の一具体例を示す図である。受信装置３６１０の記録媒体４２０１が図４２に示す通りであるとする。この記録状況は、
パス名：／Ａ／Ｂ／Ｄ，
提示期間：２００１年１０月１０日〜２００１年１０月３１日、
である。

この状況の下で、現在日時が２００１年１０月１５日で、パス名が／Ａ／Ｂ／Ｄ／Ｇ／ｘｘｘであるデータ表示要求を受けた場合、現在日時が提示期間内であるため当該データを表示する。他方、現在日時が２００１年１１月１日で、パス名が／Ａ／Ｂ／Ｄ／Ｇ／ｘｘｘであるデータ表示要求を受けた場合、現在日時が提示期間外であるため当該データを表示しない。

上記の処理により、データ提供者が自らデータの提示期間を設定し、データ提供者の意図に合ったデータの表示可否を制御することが可能となる。

以上のように、本発明では、空コンテンツを流すノンスクランブルの削除用シリーズを配置することにより、スクランブルされた契約サービスの契約を解除した受信装置に対しても確実にコンテンツの削除を指示することが可能となる。

また、コンテンツに対し送出装置で提示期限を延長しながら付与することにより、サービスの送出終了前に契約を中止した受信装置において、契約終了したサービスのコンテンツ提示を制限することができる。

本発明の参考例１によるコンテンツの送出装置及び受信装置の構成例を示すブロック図 前記参考例１におけるコンテンツ情報の例を示す図 前記参考例１におけるシリーズ表の例を示す図 前記参考例１におけるシリーズとコンテンツの対応表の例を示す図 前記参考例１における基本スケジュール（24時間単位）の例を示す図 前記参考例１における放送スケジュ―ルの例を示す図 前記参考例１における蓄積済み最終episode・＿number表と予約情報の例を示す図 前記参考例１におけるコンテンツの基本的な送出処理を説明するフローチャート 前記参考例１における緊急変更用シリーズを用いたコンテンツの緊急変更を可能とする送出処理を説明するフローチャート 前記参考例１における緊急変更用シリーズを用いずにコンテンツの緊急変更を可能とする送出処理を説明するフローチャート 前記参考例１におけるコンテンツの削除を可能とする送出処理を説明するフローチャート 前記参考例１におけるコンテンツの受信処理を説明するフローチャート 前記参考例１におけるシリーズ設定表の例を示す図 前記参考例１における2001年3・月12日の放送スケジュールの例を示す図 前記参考例１における緊急変更用シリーズを設定したシリーズ設定表の例を示す図 前記参考例１における緊急変更用シリーズにコンテンツを割り当てない場合のシリーズとコンテンツの対応表の例を示す図 前記参考例１における緊急変更用シリーズにコンテンツを割り当てる場合のシリーズとコンテンツの対応表の例を示す図 本発明の参考例３において、送出装置が管理するサービス毎の蓄積領域サイズと受信装置毎に契約している領域サイズの関係を示す例の図 前記参考例３における送出装置が管理するサービス毎の蓄積領域サイズの状態が変化する例を示す図 前記参考例３における送出装置と受信装置の構成を示すブロック図 前記参考例３において削除用シリーズを設定したシリーズ設定表の例を示す図 前記参考例３において設定削除するコンテンツがあるコンテンツ情報の例を示す図 前記参考例３において設定削除されたコンテンツが削除用シリーズに割り当てられたシリーズとコンテンツの対応表の例を示す図 本発明の参考例４における送出装置と受信装置の構成を示すブロック図 前記参考例４におけるコンテンツ情報蓄積部が蓄積するコンテンツ情報の例を示す図 前記参考例４におけるコンテンツ提示期限延長間隔表の例を示す図 前記参考例４におけるコンテンツ提示期限延長間隔と提示期限切替タイミングの例を示す図 前記参考例４におけるContent・＿id2・のコンテンツに付与する提示期限と付与する期間の対応表の例を示す図 前記参考例４における提示期限切替タイミング表の例を示す図 前記参考例４における送出部から送出されるコンテンツのイメージの例を示す図 前記参考例４における受信機のコンテンツ蓄積部が管理するコンテンツ管理表の例を示す図 前記参考例４における提示期限付与の処理フロー 前記参考例４における提示期限付与部におけるコンテンツに付与する提示期限と付与する期間の対応表の作成フロー 前記参考例４における強制起動用シリーズの配置ポリシー表の例を示す図 本発明の参考例２におけるコンテンツの送出装置と受信装置の構成を示すブロック図 本発明の実施の形態１におけるコンテンツの送出装置と受信装置の構成を示すブロック図 前記実施の形態１に係るデータ送出装置および受信装置の間におけるデータ送受信の処理動作を説明するフローチャート 前記実施の形態１におけるダウンロードデータ制御データの構造を示すデータ構造図 前記実施の形態１において受信装置におけるデータの登録、削除の処理動作を説明するフローチャート 前記実施の形態１において受信装置におけるデータの削除の処理による記録媒体中のデータが減少する状況を模式的に示す図 前記実施の形態１における受信装置においてデータ毎に付与された提示期間を基にデータの表示可否の制御を行なう方法を説明するフローチャート 前記実施の形態１における受信装置３６１０においてデータ毎に付与された提示期間を基に行なわれるデータの表示可否の制御の一具体例を示す図

符号の説明

１０１ コンテンツ登録部
１０２ コンテンツ情報蓄積部
１０３ 基本スケジュール作成部
１０４ 緊急変更用スケジュール設定部
１０５ 基本スケジュール蓄積部
１０６ 放送スケジュール作成部
１０７ 放送スケジュール蓄積部
１０８ コンテンツ蓄積部
１０９ 送出部
１１０ 受信部
１１１ 放送スケジュール蓄積部
１１２ 予約部
１１３ コンテンツ蓄積部
１１４ コンテンツ表示部
２００１ 削除用シリーズ設定部
２４０１ 提示期限付与部
２４０２ コンテンツ提示期限確認部
３５０１ 緊急変更コンテンツ設定部

Claims (21)

1. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを送信する送出装置は、データ管理をするディレクトリが空であることを示す空データを送信し、さらに、前記送出装置からデータを受信する受信端末は、前記送出装置から前記空データを受信したとき、前記空データに対応するディレクトリを自動的に削除するデータ削除処理部を有することを特徴とするデータ放送スケジュールシステム。
2. 前記受信端末のデータ削除処理部は、前記ディレクトリが管理する前記データが全てなくなったとき、前記ディレクトリを削除することを特徴とする請求項１記載のデータ放送スケジュールシステム。
3. 前記送出装置は、前記空データに削除すべきディレクトリ名を入れることを特徴とする請求項１記載のデータ放送スケジュールシステム。
4. 前記受信端末は、削除すべきディレクトリ名を入れた空データを受信したとき、前記ディレクトリ名に関するデータを削除する前に、前記ディレクトリ名に関するデータを参照しているユーザがいるか否かをチェックすることを特徴とする請求項１記載のデータ放送スケジュールシステム。
5. 前記送出装置は、前記受信端末におけるデータ提示期間を示すデータ提示期間データを、前記送信するデータに付与し、前記受信端末に送信することを特徴とする請求項１記載のデータ放送スケジュールシステム。
6. 前記受信端末は、前記データ提示期間データを受信し、現在の時間について示す現在時刻データと前記データ提示期間データとを使って、データを提示してもよいか否かを判断する提示期間判断部を有することを特徴とする請求項５記載のデータ放送スケジュールシステム。
7. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを受信する受信端末は、データを管理するディレクトリが空であることを示す空データを受信したとき、前記空データに対応するディレクトリを自動的に削除するデータ削除処理部を有することを特徴とするデータ放送スケジュールシステム。
8. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを送信する送出装置は、当該送出装置からのデータを受信する受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成するダウンロードデータ制御データ生成部を有し、
   さらに、前記ダウンロードデータ制御データは、前記受信端末で受信するデータの数を示すモジュール数データと、前記受信端末におけるデータを管理するディレクトリのパス名を示すディレクトリパス名データとを有し、
   さらに、前記受信端末における任意の前記ディレクトリを削除するときに、前記ディレクトリに対応する前記ダウンロードデータ制御データの前記モジュール数データを０にして前記受信端末に送信し、前記ディレクトリに対応するデータを送信しない送出部とを有し、
   さらに、前記受信端末は、前記送出装置から前記モジュール数データが０であるダウンロードデータ制御データを受信したとき、前記モジュール数データに対応するデータが受信されるか否かを一定時間監視し、受信されなければ、前記モジュール数データに対応する前記ディレクトリについての前記データを削除するデータ削除処理部を有することを特徴とするデータ放送スケジュールシステム。
9. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを送信する送出装置は、当該送出装置のデータを受信する受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成するダウンロードデータ制御データ生成部を有し、
   さらに、前記ダウンロードデータ制御データは、前記受信端末で受信するデータの数を示すモジュール数データと、前記受信端末におけるデータを管理するディレクトリのパス名を示すディレクトリパス名データとを有し、
   さらに、前記受信端末における任意の前記ディレクトリを削除するときに、前記ディレクトリに対応する前記ダウンロードデータ制御データの前記モジュール数データを０にして前記受信端末に送信し、前記ディレクトリに対応するデータを送信しない送出部とを有することを特徴とするデータ放送スケジュールシステム。
10. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを受信する受信端末は、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応するデータが受信されるか否かを一定時間監視し、受信されなければ、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについてのデータを削除するデータ削除処理部を有することを特徴とするデータ放送スケジュールシステム。
11. 伝送路を利用してデータを送受信するデータ放送スケジュール方法であって、データを送信する送出装置において、当該送出装置のデータを受信する受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成するステップと、前記受信端末における任意のディレクトリを削除するときに、前記ディレクトリに対応する前記ダウンロードデータ制御データの前記モジュール数データを０にして前記受信端末に送信するステップと、前記ディレクトリに対応するデータを送信しないステップとを有することを特徴とするデータ放送スケジュール方法。
12. 伝送路を利用してデータを送受信するデータ放送スケジュール方法であって、データを受信する受信端末において、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である、前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応するデータが受信されるか否かを一定時間監視するステップと、受信されなければ、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについての前記データを削除するステップとを有することを特徴とするデータ放送スケジュール方法。
13. 伝送路を利用してデータを送受信するデータ放送スケジュールプログラムを記録した記録媒体であって、データを受信する受信端末において、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である、前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応するデータが受信されるか否かを一定時間監視するステップと、受信されなければ、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについての前記データを削除するステップとを有することを特徴とするデータ放送スケジュールプログラムを記録した記録媒体。
14. 伝送路を利用してデータを送受信するデータ放送スケジュールプログラムであって、データを受信する受信端末において、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である、前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応するデータが受信されるか否かを一定時間監視するステップと、受信されなければ、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについての前記データを削除するステップとを、コンピュータに実行させるためのデータ放送スケジュールプログラム。
15. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを送信する送出装置は、当該送出装置からのデータを受信する受信端末におけるダウンロードデータについての運用情報を保持するダウンロードデータ制御データを生成するダウンロードデータ制御データ生成部を有し、
    さらに、前記ダウンロードデータ制御データは、前記受信端末で受信するデータの数を示すモジュール数データと、前記受信端末におけるデータを管理するディレクトリのパス名を示すディレクトリパス名データとを有し、
    さらに、前記受信端末における任意の前記ディレクトリを削除するときに、前記ディレクトリに対応する前記ダウンロードデータ制御データの前記モジュール数データを０にして前記受信端末に送信し、前記ディレクトリに対応するデータを送信しない送出部とを有し、
    さらに、前記受信端末は、前記送出装置から前記モジュール数データが０であるダウンロードデータ制御データを受信したとき、前記モジュール数データに対応する前記ディレクトリについての前記データを削除するデータ削除処理部を有することを特徴とするデータ放送スケジュールシステム。
16. 伝送路を利用してデータを送受信するデータ放送スケジュールシステムであって、データを受信する受信端末は、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについてのデータを削除するデータ削除処理部を有することを特徴とするデータ放送スケジュールシステム。
17. 伝送路を利用してデータを送受信するデータ放送スケジュール方法であって、データを受信する受信端末において、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である、前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについての前記データを削除するステップを有することを特徴とするデータ放送スケジュール方法。
18. 伝送路を利用してデータを送受信するデータ放送スケジュールプログラムを記録した記録媒体であって、データを受信する受信端末において、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である、前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについての前記データを削除するステップを有することを特徴とするデータ放送スケジュールプログラムを記録した記録媒体。
19. 伝送路を利用してデータを送受信するデータ放送スケジュールプログラムであって、データを受信する受信端末において、前記受信端末にデータを送信する送出装置から、前記受信端末で受信するデータの数を示すモジュール数データが０である、前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについての前記データを削除するステップを、コンピュータに実行させるためのデータ放送スケジュールプログラム。
20. 送出スケジュール作成機能を有する送出装置から送信されるデータとダウンロードデータ制御データと送出スケジュールとを受信する受信部と、受信した送出スケジュールを蓄積する送出スケジュール蓄積部と、送出スケジュールに付加されたデータの更新を表す情報から更新されたデータの受信時間を判断し、受信部を起動させる受信予約部と、受信したデータを蓄積するデータ蓄積部と、受信したダウンロードデータ制御データから当該データの蓄積或いは削除の判断を行なう蓄積／削除判断部と、受信したデータを受け付け所望のデータの表示を行なうデータ表示部と、蓄積／削除判断部にて削除と判断されたデータをデータ蓄積部から削除するデータ削除処理部、データを表示する際、データの提示期間と現在時刻からデータを表示して良いか否かを判断するデータ提示期間判断部とを備え、
    前記予約部は、送出スケジュール蓄積部に蓄積された送出スケジュールに基づいて受信部における受信予約を行ない、表示部は前記データ蓄積部からコンテンツを呼び出して表示するとともに、
    さらに、受信端末で受信するデータの数を示すモジュール数データが０である前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについてのデータを削除するデータ削除処理部を有することを特徴とするデータ受信装置。
21. 送出スケジュール作成機能を有する送出装置から送信されるデータとダウンロードデータ制御データと送出スケジュールとを受信する受信部と、受信した送出スケジュールを蓄積する送出スケジュール蓄積部と、送出スケジュールに付加されたデータの更新を表す情報から更新されたデータの受信時間を判断し、受信部を起動させる受信予約部と、受信したデータを蓄積するデータ蓄積部と、受信したダウンロードデータ制御データから当該データの蓄積或いは削除の判断を行なう蓄積／削除判断部と、受信したデータを受け付け所望のデータの表示を行なうデータ表示部と、蓄積／削除判断部にて削除と判断されたデータをデータ蓄積部から削除するデータ削除処理部、データを表示する際、データの提示期間と現在時刻からデータを表示して良いか否かを判断するデータ提示期間判断部とを備え、
    前記予約部は、送出スケジュール蓄積部に蓄積された送出スケジュールに基づいて受信部における受信予約を行ない、表示部は前記データ蓄積部からコンテンツを呼び出して表示するとともに、
    さらに、受信端末で受信するデータの数を示すモジュール数データが０である前記送出装置からのデータを受信する前記受信端末におけるダウンロードデータについての運用情報を示すダウンロードデータ制御データを受信したとき、前記モジュール数データに対応するデータが受信されるか否かを一定時間監視する監視部と、受信されなければ、前記モジュール数データに対応する、前記受信端末におけるデータを管理するディレクトリについてのデータを削除するデータ削除処理部を有することを特徴とするデータ受信装置。

Images