(57)【特許請求の範囲】
【請求項１】
コンテンツデータを受信して蓄積する受信装置、及び受信装置と通信回線網を介して接続される情報処理装置を内包してなるシステムであって、
受信装置が、当該受信装置の記録媒体の空き容量に関する情報を取得するステップと、
受信装置が、取得した前記記録媒体の空き容量に関する情報を情報処理装置に通知するステップと、
情報処理装置が、受信装置から通知される記録媒体の空き容量に関する情報を受信するステップと、
情報処理装置が、電子番組ガイドシステムを介して番組情報を取得するステップと、
情報処理装置が、予めユーザにより登録されていた希望コンテンツが前記番組情報に含まれているか否かを判断するステップと、
情報処理装置が、前記希望コンテンツが前記番組情報に含まれていると判断した場合に、受信装置から受信した情報に基づいて受信装置の記録媒体の空き容量が不足していないかどうかを判断するステップと、
情報処理装置が、受信装置の記録媒体の空き容量が不足していると判断した場合に、当該情報処理装置側で前記希望コンテンツのデータを受信して蓄積するステップと
を実施するシステム。
【請求項２】
情報処理装置が、データの蓄積回数、蓄積したデータサイズ、蓄積している時間のうち何れか一以上の値をパラメータとしてデータ蓄積サービス料金を算出するステップをさらに実施する請求項１記載のシステム。
【請求項３】
請求項１記載のシステムを構成するために用いられ、コンテンツデータを受信して蓄積する受信装置と通信回線網を介して接続される情報処理装置であって、
受信装置から通知される記録媒体の空き容量に関する情報を受信するステップと、
電子番組ガイドシステムを介して番組情報を取得するステップと、
予めユーザにより登録されていた希望コンテンツが前記番組情報に含まれているか否かを判断するステップと、
前記希望コンテンツが前記番組情報に含まれていると判断した場合に、受信装置から受信した情報に基づいて受信装置の記録媒体の空き容量が不足していないかどうかを判断するステップと、
受信装置の記録媒体の空き容量が不足していると判断した場合に、当該情報処理装置側で前記希望コンテンツのデータを受信して蓄積するステップと
を実施する情報処理装置。
【請求項４】
請求項１記載のシステムを構成するために用いられるプログラムであって、コンテンツデータを受信して蓄積する受信装置と通信回線網を介して接続される情報処理装置に、
受信装置から通知される記録媒体の空き容量に関する情報を受信するステップと、
電子番組ガイドシステムを介して番組情報を取得するステップと、
予めユーザにより登録されていた希望コンテンツが前記番組情報に含まれているか否かを判断するステップと、
前記希望コンテンツが前記番組情報に含まれていると判断した場合に、受信装置から受信した情報に基づいて受信装置の記録媒体の空き容量が不足していないかどうかを判断するステップと、
受信装置の記録媒体の空き容量が不足していると判断した場合に、当該情報処理装置側で前記希望コンテンツのデータを受信して蓄積するステップと
を実施させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、蓄積型放送サービス等において受信したデータを記録媒体に蓄積する受信装置、サーバ装置、サービス料算出方法、及びファイルに対して削除や移動などの自動操作を行うことのできるファイル操作情報を具備したファイルシステムに関する。
【背景技術】
【０００２】
近年、携帯電話やＰＨＳ等の携帯端末は、その機能の向上やインフラ整備に伴い、次々に新しいサービスが付加されて提供されてきている。
【０００３】
例えば、携帯電話を利用した電子メールサービスでは、送受信するファイルが、当初文字データだけであったものが音楽や静止画付データが送受信できるようになり、さらには動画データ等のデータサイズの大きなファイルが送受信できるようになってきている。
【０００４】
一方、ＨＤＤ等の記録媒体を具備した受信装置を利用して、受信したデジタルＴＶ放送やデータ放送のコンテンツ等を前記記録媒体に蓄積し、蓄積録画した番組や情報等のデータを、後で随時見ることができるようにするといった蓄積型サービスが現在考えられつつある。
【０００５】
このような蓄積型サービスによれば、ユーザーは録画予約等を行うことで、リアルタイムでＴＶを見なくても、必要な映像コンテンツ等のデータを必要な時に得ることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、データやファイルを蓄積させる記録媒体に空き容量が不足していた場合には、データやファイルの蓄積ができないという問題が生じる。
【０００７】
例えば、文字データや画像データ等からなるファイルを携帯電話等の受信装置で受信するとき、その受信装置に設けられた記録媒体の空き容量が不足していたときには、ファイルの受信を失敗するという問題点がある。
【０００８】
また、ナイター中継のスポーツ番組等を録画するとき、その番組が延長されたとき等には録画するデータサイズが大きくなる。このとき、受信装置に設けられた記録媒体の空き容量が不足していたときには、録画されない部分ができるという問題が生じるおそれがある。
【０００９】
そこで本発明は、受信装置に設けられた記録媒体にデータやファイルを記録する際、その受信装置の記録媒体に空き容量が無かった場合にでも、データやファイルに設けられた操作情報を基に、データやファイルの移動や削除や圧縮などの自動操作がなされ、所望のデータやファイルが確実に蓄積でき得るシステムを提供することを所期の大きな課題としたものである。
【課題を解決するための手段】
【００１０】
前記課題を解決すべくなされた本願請求項１に係る発明の受信装置は、データを記録する際、その記録媒体に空き容量が無かった場合にでも、データを完全に受信する前にそのデータサイズを取得し、取得したデータサイズに基づき空き容量を予測して、記録媒体に既に蓄積されているデータに対して移動や削除や圧縮などの操作を行い得るようにしたものである。
【００１１】
このようにすれば、所望のデータを受信装置側の記録媒体を極めて効率的に使用して蓄積でき得るシステムが供給できるようになるからである。
【００１２】
また、本願請求項４に係る発明の受信装置は、空き容量に関する容量情報に基づき、その記録媒体に記録できるか否かをチェックし、記録できないような場合には受信したデータの全部または一部をサーバに送信するようにしたものである。このようにすれば、所望のデータの蓄積を受信装置に空き容量が無くてもサーバ側が補完してくれるため、システムとしてデータ蓄積機能の向上が図られたシステムを供給できるようになるからである。
【００１３】
さらに、本願請求項５に係る発明の受信装置は、空き容量に関する容量情報に基づき、受信装置の記録媒体に記録できるか否かをチェックし、記録できないような場合にはできない旨を含む容量不足情報をサーバに通知するようにしたものである。このようにすれば、サーバが受信装置の蓄積状況を知ることができるようになるからである。
【００１４】
さらに、本願請求項７に係る発明の受信装置は、空き容量に関する容量情報に基づき、受信装置の記録媒体に記録できるか否かをチェックし、記録できないような場合には容量不足になる予測時間をサーバに通知するようにしたものである。このようにすれば、その情報に基づきサーバが容量不足になる予測時間に蓄積開始するため、システムとしてデータ蓄積機能の充実化が図られたシステムを供給できるようになるからである。
【００１５】
さらに、本願請求項１２に係る発明のサービス料算出方法は、サーバ装置におけるデータ蓄積に対して、データ蓄積回数、蓄積したデータサイズ、蓄積している時間等を管理したものである。このようにすれば、これらを利用して、データ蓄積サービス料金としてサービス料が算出できるようになるからである。
【００１６】
一方、本願請求項１３に係る発明のファイルシステムは、ファイルの削除、圧縮、移動、保管等に関する自動的な操作についての情報である操作情報を属性として当該ファイルに具備させることで、記録媒体に容量不足などがあった場合でも、前記属性に基づいてファイルの自動管理を行い得るようにし、ファイルを効率的に蓄積できるようにしたものである。
【００１７】
ここで、「ファイルシステム」とは、直接ＯＳ等の管理下におかれるものであって、データベースシステムやメモリシステムは含まない概念である。
【００１８】
そして、放送コンテンツ等のデータを受信蓄積する受信装置に係るファイルシステムを搭載しておくことが実施の態様上好ましい。
【００１９】
具体的に「データ」とは、アナログ放送やデジタル放送等で放送される、音声データや画像データを有したＴＶ放送やラジオ放送の番組コンテンツ等の他、データ放送のコンテンツである文字情報等を示すものであり、電子メール等で送受信される文字データ、画像データ、音声データ等のデータを含む。
【００２０】
また、上述の「データ」は１ファイル中に１又は複数存在してもよいし、複数のファイルにまたがって存在してもよい。
【００２１】
このような構成によれば、記録媒体にファイルを記録する際、その記録媒体に空き容量が無かった場合にでも、ファイルに対して移動や削除や圧縮などの自動操作がなされるため、所望のファイルを確実に蓄積でき得るファイルシステムが供給できることとなる。
【発明の効果】
【００２２】
以上に詳述した本発明によれば、ＨＤＤ等の記録媒体を具備した受信装置を利用して、受信したデジタルＴＶ放送やデータ放送のコンテンツ等を受信装置に設けられた記録媒体にデータを記録する際、その受信装置の記録媒体に空き容量が無かった場合にでも、データに対して移動や削除や圧縮などの自動操作がなされたり、サーバを利用して蓄積されるため、所望のデータを効率的かつ確実に蓄積でき得るシステムが供給できることとなる。
【発明を実施するための最良の形態】
【００２３】
以下、図面を用いて本発明の実施の形態について説明する。
【００２４】
図１は、本発明の実施形態における全体システムを示した全体機器構成図である。
【００２５】
図１において、Ｐ１はユーザの用いる受信装置であり、Ｐ２は情報処理装置たる蓄積管理サーバである。
【００２６】
受信装置Ｐ１は、BS/CS衛星や地上波やケーブル等を経由して放送局（コンテンツ配信者）から放送される番組（コンテンツ）をディジタル信号として受け取る。同時に受信装置Ｐ１は、蓄積管理サーバＰ２とインターネット等の通信回線網を介して双方向通信可能に接続されている。
【００２７】
このものは図２に示すように、ＣＰＵ１０１、内部メモリ１０２、ＨＤＤ等の外部記憶装置１０３、衛星や地上波等を経由する放送（データ放送等を含む）をアンテナＡＴを介して受信する番組受信装置１０４、テレビジョン受像機ＤＰに映像や音声信号を出力するＡＶデコーダ１０５、リモコンＲＣと通信するユーザインタフェース１０６、電話回線等を介してインタネットに接続するための送受信装置１０７等を主な構成要素とする。
【００２８】
なお、この受信装置Ｐ１は、例えばテレビジョン受像機に付帯させて使用される一種のコンピュータであって、セットトップボックスと称されるものを含むし、もちろん汎用のコンピュータを利用したものでもよい。
【００２９】
一方、図３に示すように、蓄積管理サーバＰ２は、データベース機能等を具備したもので、ＣＰＵ２０１、内部メモリ２０２、ＨＤＤ等の外部記憶装置２０３、モデム等の通信インタフェース２０４、マウスやキーボードといった入出力インタフェース２０６等を主な構成要素とする。
【００３０】
このように構成されたシステムにおいて、放送局（コンテンツ配信者）から放送される番組は、通常地上波もしくは衛星やケーブル等を介してユーザーへ放送される。
【００３１】
ＣＳアンテナやＢＳアンテナや地上波アンテナ等放送を受信するための機器に接続された受信装置Ｐ１は、テレビジョン受像機に接続され、ユーザーはテレビ番組を楽しむことができる。このとき、ユーザーが何らかの理由でリアルタイムに番組を視聴することができない場合、受信装置Ｐ１に内蔵された外部記憶装置１０３（本実施形態ではHDDとした）に番組の録画を行う。録画する方法は例えばＶＴＲのようにユーザーがリモコンＲＣを使ってセットする方法やインターネットを介して外部からセットする方法など様々な方法が考えられるが、本実施形態ではユーザがユーザーＩＦ１０６を介してリモコンＲＣを用いて設定することとした。
【００３２】
録画がなされるようにセットされた番組は、所定の時間に放送され電波としてアンテナＡＴで受信され受信装置Ｐ１のＨＤＤ１０３に記録されるが、このとき受信装置Ｐ１内部の回路ユニットで様々な信号処理がなされる。例えば、有料放送の場合スクランブル放送として放送されるため、そのスクランブル信号をデコードするデスクランブラ処理がなされたり、AVデコーダでディジタル信号がアナログ信号に変換されたりする。
【００３３】
本実施形態では、受信装置Ｐ１は、その内部メモリ１０２等に記憶させたプログラムにしたがって前記ＣＰＵ１０１や周辺機器を作動させ、図４に示すように、データサイズ取得部１、記録媒体状態予測部２、データ操作部３、容量取得部４、データ送信部５、通知部６ａ、第二通知部６ｂ、記録予約情報受付部７、記録媒体８としての機能を発揮するようにしている。
【００３４】
また、蓄積管理サーバＰ２も同様に、内部メモリ２０２等に記憶させたプログラムにしたがって前記ＣＰＵ２０１や周辺機器を作動させ、図４に示すように、第二データ受信部１１、第二データ蓄積部１２、通知受信部１３ａ、第二通知受信部１３ｂ、蓄積状況取得部１４、サービス料算出部１５としての機能を発揮するようにしている。
【００３５】
具体的に、図４に示された受信装置Ｐ１の各部を具体的に詳述する。
【００３６】
データサイズ取得部１は、放送局から放送される番組（コンテンツ）のデータのサイズをインターネットなどの通信回線網を介して取得するものであり、取得したデータのサイズは、前記ＨＤＤ１０３の所定領域に格納される。ここで本実施形態における「データ」とは、動画又は音声のうちの少なくとも一方を有するデータである放送コンテンツである。なお、通信回線網に限らず、放送中の電波等からこのデータのサイズが取得されても構わない。
【００３７】
また、本実施形態でデータのサイズを取得する方法は、ＴＶ局やラジオ局等に設置されたセンタコンピュータから送信される番組表を受信装置Ｐ１であらかじめ受信し、ＴＶ番組等の録画予約や視聴予約を行うＥＰＧ（電子番組ガイド）システムを利用したが、これに限らず、番組情報を持つ外部のマシンから取得しても構わない。
【００３８】
記録媒体状態予測部２は、前記データサイズ取得部１で取得したデータサイズに基づき、当該データが取得されて記録媒体８に記録された結果、その記録媒体８の空き容量がどのような状態になるかを予測するものである。例えば、「空き容量が十分にある」とか、「空き容量が不足している」という予測結果が出力される。ここで「出力」とは、例えば蓄積管理サーバＰ２への送信、テレビジョン受像機ＤＰへの表示、印字などがあるが、ここでは、取得した前記予測結果をデータ操作部３および通知部６に出力するという意味である。
【００３９】
データ操作部３は、前記記録媒体状態予測部２の出力結果に基づき、記録媒体８の空き容量が不足しているとされた場合等には、記録媒体８に既に蓄積されているデータに対して、削除や圧縮や移動などのデータ操作を行うものである。
【００４０】
容量取得部４は、記録媒体８からその空き容量に関する情報を含む容量情報を取得するものであり、その取得した容量情報をデータ送信部５、通知部６ａ、第二通知部６ｂ及び記録予約情報受付部７に出力する。
【００４１】
データ送信部５は、前記容量情報が一定の条件を満たす場合に、受信したデータの全部または一部を、蓄積管理サーバＰ２へインターネット等の通信回線網を介して送信する機能を有するもので、前記モデムを利用して構成してある。ここで「一定の条件」とは、主に、空き容量やデータサイズに関する条件のことで、例えば、「受信装置Ｐ１の記録媒体８の空き容量が、記録しようとする番組データより大きい場合」などがある。
【００４２】
通知部６ａは、容量取得部４で得られた空き容量情報を、その空き容量情報が一定の条件を満たす場合に、不足容量サイズや端末識別子等を蓄積管理サーバＰ２へインターネットを介して通知するものであり、前記モデムを利用して構成してある。
【００４３】
第二通知部６ｂは、容量取得部４で得られた容量情報を、その空き容量情報が一定の条件を満たす場合に、容量不足になる予測時間や端末識別子等を蓄積管理サーバＰ２へインターネットを介して通知するものであり、前記モデムを利用して構成してある。
【００４４】
なお、本実施形態では、通知する情報を容量不足になる予測時間としたが、これに限らず、容量不足に関する情報であればよく、例えば、「もうすぐ容量不足になりそうだ」というような状態をあらわす情報でもよい。
【００４５】
記録予約情報受付部７は、例えば何年何月何日の何時何分からデータの録画を開始する等、ユーザーがリモコン等で行なう録画予約に関する情報を受け付け、前記容量情報と比較し、一定の条件を満たすか否かを判断するものである。また、ここで「一定の条件」とは、データ送信部５で説明した「一定の条件」と同じである。
【００４６】
記録媒体８は、図５に示すような、顧客ＩＤ番号・氏名・端末識別子・端末仕様（ハードディスク全容量、空き容量）等の属性を有した顧客ＤＢファイルと、番組ＩＤ番号・番組名・提供者・ファイルサイズ・放送日時等の属性を有した番組ＤＢファイルと、顧客ＩＤ番号・番組ＩＤ番号・放送日時・ファイルサイズ・優先度等の属性を有した端末蓄積情報ファイルと、番組ＩＤ番号・データの属性を有した端末蓄積データファイルと、全容量サイズ・蓄積個数・既蓄積容量サイズ・空き容量サイズ・不足容量サイズ・容量不足になる予測時間の属性を有した容量管理情報ファイルとを、前記HDD１０３等のその所定記憶領域に格納してなるものであり、これら顧客ＤＢファイル、番組ＤＢファイル、端末蓄積情報ファイル、端末蓄積データファイル、容量管理情報ファイルは各々関連付けられたリレーショナル形式をなすものである。
【００４７】
各属性を詳述する。
【００４８】
顧客ＩＤ番号はユニークな値として受信装置Ｐ１が付与する。氏名はユーザーの呼称であり、端末識別子はインターネットを介して外部からも識別できるもので、本実施形態では、ＩＰｖｅｒ６にも対応できるようなユニークな値を用いることとした。端末仕様はハードディスク全容量、空き容量等受信装置Ｐ１の仕様である。
【００４９】
番組ＩＤ番号はユニークな値として受信装置Ｐ１が付与する。番組名と提供者は、ファイルサイズ、放送日時は、番組に関するデータでありＥＰＧ（電子番組ガイド）システムより入手した。
【００５０】
優先度は、データの保護、データの移動、データの圧縮処理、データの削除等、データの操作に関する操作情報を基に定義付けられた番号のことであり、これにより、記録媒体８に既に蓄積されているデータの、削除や圧縮や移動などの操作が円滑に行われることとなる。
【００５１】
本実施形態では、図５に示すように優先度が１のときはデータの保護（プロテクテッド）、優先度が２のときはデータの移動（外部デバイスへの移管）、優先度が３のときはデータの圧縮（再圧縮してローカルにおく）、優先度が４のときはデータの削除としたが、これに限らず、優先度の段階をより細かく設定するなど適宜設定しても構わない。
【００５２】
全容量サイズ、既蓄積容量サイズ、空き容量サイズ、不足容量サイズは、受信装置Ｐ１における記録媒体の容量に関するサイズのことで、それぞれ、記録媒体の全容量、既蓄積データの合計容量、空き容量の合計容量、新たにデータを追加記録するときに前記記録媒体で不足する容量のことを表す。蓄積個数は既蓄積コンテンツの総数、容量不足になる予測時間は新しくデータを蓄積したとき、蓄積開始から前記記録媒体が容量不足になるまでの時間を表す。
【００５３】
次に図４に示された蓄積管理サーバＰ２の各部を具体的に詳述する。
【００５４】
第二データ受信部１１は、受信装置Ｐ１もしくは放送局のからデータを受信する機能を有するものであり、前記通信インターフェイス２０４を利用して構成されている。
【００５５】
第二データ蓄積部１２は、受信装置Ｐ１から送信されてくるデータ及び番組ＩＤや、放送局から衛星等を介して放送されてくるデータ及び番組ＩＤを格納するもので、前記HDD２０３の所定領域に形成してある。
【００５６】
通知受信部１３ａは、受信装置Ｐ１の通知部６ａから送信されてくる、不足容量サイズや端末識別子等を受信して第二データ受信部１１に不足容量サイズを識別する番組ＩＤを出力するものであり、前記通信インターフェイス２０６を利用して構成されている。
【００５７】
第二通知受信部１３ｂは、受信装置Ｐ１の通知部６ｂから送信されてくる、容量不足になる予測時間や端末識別子等を受信して第二データ受信部１１に不足容量サイズを識別する番組ＩＤ番号を出力するものであり、前記通信インターフェイス２０６を利用して構成されている。
【００５８】
蓄積状況取得部１４は、前記第二通知受信部１３ｂから出力される受信装置Ｐ１の空き容量情報を管理し、図６に示すような蓄積管理ファイルに示される蓄積管理情報として第二通知受信部１３ｂに出力するものである。蓄積ＩＤ番号は蓄積管理サーバＰ２によって付与されるユニークな値である。蓄積アドレス及び蓄積データは、それぞれ前記蓄積管理サーバＰ２のＨＤＤ２０３における格納位置及び格納されるコンテンツを表す。また、図中の項目が図５の項目と同じであれば、同じ意味をなす。
【００５９】
図６の属性を詳述する。
【００６０】
サービス料算出部１５は、前記第二データ蓄積部１２のデータ蓄積回数、蓄積したデータサイズ、蓄積している時間等を基に、データ蓄積サービス料金を算出するものである。本実施形態では、データ蓄積回数１回に対し１００円、蓄積したデータサイズ１ＭＢに対し１００円、データ蓄積時間２４時間に対し１００円で算出する方法を採用したが、これに限らずデータの送受信時間（例えば１０円/分）で算出するなど、任意の算出方法を採用してもよい。
【００６１】
次に、本実施形態のシステムの動作について、図７〜図１０に示すフロー図を用いて説明する。
【００６２】
図７〜図１０は、受信装置Ｐ１における、番組（コンテンツ）の録画予約から蓄積に至るまでの過程がフロー図で示されたものである。
【００６３】
まず、ユーザーがリモコンＲＣを用いて番組ガイドなどから蓄積予約したい番組を選択すると（ステップＳＴ１０１）、番組のデータサイズ（Ｕ）をインターネットを介してＥＰＧ（電子番組ガイド）システムより取得し（ステップＳＴ１０２）、番組ＤＢのファイルサイズに格納する。一方、容量取得部４が受信装置Ｐ１の実際の空き容量（Ｖ）を取得し（ステップＳＴ１０３）、容量管理情報ファイルの空き容量サイズに格納する。
【００６４】
そして、この番組のデータサイズ（Ｕ）と受信装置Ｐ１の実際の空き容量（Ｖ）とを比較し（ステップＳＴ１０４）、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より小さければ、予約を終了する。
【００６５】
一方、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より大きければ、受信装置Ｐ１に既に蓄積されている既蓄積コンテンツの優先度を端末蓄積情報ファイルから調べ、既蓄積コンテンツの優先度が全て１であれば（ステップＳＴ１０５）、すなわち既蓄積コンテンツ全てにプロテクトがかかっていれば、受信装置Ｐ１が接続されたテレビジョン受像機ＤＰに「既蓄積番組の優先度を設定して下さい」のメッセージを表示させる（ステップＳＴ１０６）。そして、ユーザによる優先度の再設定を受けて（ステップＳＴ１０７）、端末蓄積情報ファイルが、その優先度の低い順にソートされ（ステップＳＴ１０８）、さらに、各優先度レベルで蓄積した時間の古い順にソートされる（ステップＳＴ１０９）。以上のステップにより、既蓄積コンテンツは、その優先度が低くかつ蓄積した時間が古いもの順に並べ替えられることとなる。
【００６６】
次に、並び替えられた既蓄積コンテンツは、並び替えられた順に一つずつ優先度に応じた次のような自動操作が行なわれる。
優先度が４であれば（ステップＳＴ１１１）、当該コンテンツの削除（ステップＳＴ１１２）。優先度が３であれば（ステップＳＴ１１３）、当該コンテンツを再圧縮して端末におく（ステップＳＴ１１４）。優先度が２であれば（ステップＳＴ１１５）、当該コンテンツをサーバへ移動する（ステップＳＴ１１６）。優先度が１であれば（ステップＳＴ１１７）、当該コンテンツを保護する（ステップＳＴ１１８）。
【００６７】
そして、各処理毎に、受信装置Ｐ１の空き容量（Ｖ）を取得し（ステップＳＴ１１９）、その空き容量（Ｖ）が番組のデータサイズ（Ｕ）より大きくなっていれば（ステップＳＴ１２０）、予約を完了し、そうでなければ、次の蓄積コンテンツ（ステップＳＴ１２１）の自動操作を空き容量（Ｖ）が番組のデータサイズ（Ｕ）より大きくなるかがチェックされながら続けて行なわれる（ステップＳＴ１２２）。
【００６８】
最後の既蓄積コンテンツでも空き容量（Ｖ）が番組のデータサイズ（Ｕ）よりも大きくならなければ、端末に接続されたテレビジョン受像機ＤＰに「空き容量を増やすことができません。サーバにて蓄積予約を行ないますか」とのメッセージを表示させる（ステップＳＴ１２３）。
【００６９】
そしてユーザーの入力によるサーバでの蓄積予約に関する指示を待ち（ステップＳＴ１２４）、サーバでの蓄積予約が希望されない場合には、予約しないで終了する。一方、希望された場合は、通知部６ａがサーバに番組のリクエストを含む容量不足情報を送信し（ステップＳＴ１２５）、サーバからＯＫ待ち、（ステップＳＴ１２６）、ＯＫとの応答が得られなければ、予約は不可となり、ＯＫとの応答が得られた場合には予約が完了する。
【００７０】
なお、本実施形態では、優先度に基づくコンテンツの整理を予約操作と同時に行なったが、これに限らず、毎日決まった時刻に整理を行なったり、次の蓄積の１時間前に整理を行なうなど任意のタイミングで構わない。
【００７１】
また、通知部６ａがリクエストを含む容量不足情報の送信するタイミングを予約操作と同時に行なったが、これに限らず、サーバから了承の応答を事前に得られることが分かっている場合などでは、蓄積予定時間前に送信されれば、周期的に送信するなど任意のタイミングで構わない。
【００７２】
さらに、本実施形態では、受信装置Ｐ１と蓄積管理サーバＰ２との間の通信回線網をインターネットの場合で説明したが、これに限らず通常の電話回線や携帯電話などを用いてもよい。
【００７３】
図１１は、上述した受信装置Ｐ１に対応して番組の蓄積を行なう蓄積管理サーバＰ２の、番組（コンテンツ）蓄積過程がフロー図で示されたものである。
まず、蓄積管理サーバＰ２の通知受信部１３ａで受信装置Ｐ１の容量不足情報を受信したとき（ステップＳＴ２０１）、ユーザが蓄積管理サーバＰ２使用の契約を行なっているか否かがチェックされ（ステップＳＴ２０２）、契約がなければ蓄積拒否を通知する（ステップＳＴ２０３）。一方、契約があった場合、受信装置Ｐ１へ蓄積許可を通知し（ステップＳＴ２０４）、通知受信部１３ａで受信した容量不足情報に含まれるデータ識別子で受信するコンテンツを識別し（ステップＳＴ２０５）、第二データ受信部１１でそのコンテンツを受信する（ステップＳＴ２０６）。さらに、そのコンテンツは、第二データ蓄積部１２で蓄積され（ステップＳＴ２０７）、コンテンツの蓄積回数や蓄積時間などに応じたデータ蓄積サービス料金が算出される（ステップＳＴ２０８）。
【００７４】
以上のように本実施形態によれば、データを記録する際、その記録媒体に空き容量が無かった場合にでも、データを完全に受信する前にそのデータサイズを取得し、取得したデータサイズに基づき空き容量を予測して、記録媒体に既に蓄積されているデータに対して移動や削除や圧縮などの操作を行い得るようにしたため、所望のデータを受信装置側の記録媒体を極めて効率的に使用して蓄積でき得るシステムが供給できる。
【００７５】
また、空き容量に関する容量情報に基づき、その記録媒体に記録できるか否かをチェックし、記録できないような場合には受信したデータの全部または一部をサーバに送信し、所望のデータの蓄積を受信装置に空き容量が無くてもサーバ側が補完するようにしたため、システムとしてデータ蓄積機能の向上が図られたシステムを供給できる。
【００７６】
さらに、空き容量に関する容量情報に基づき、受信装置の記録媒体に記録できるか否かをチェックし、記録できないような場合にはできない旨を含む容量不足情報をサーバに通知するようにしたため、サーバが受信装置の蓄積状況を知る得ることができる。
【００７７】
そして、サーバ装置が、そのサーバ装置におけるコンテンツ蓄積に対して、データ蓄積回数、蓄積したデータサイズ、蓄積している時間等を管理したため、データ蓄積サービス料金としてサービス料が算出できる。
【００７８】
次に、本実施形態の他のシステムの動作について、図１２、図１３に示すフロー図を用いて説明する。
【００７９】
図１２は、受信装置Ｐ１における、番組（コンテンツ）視聴中に録画操作が行なわれたときの蓄積に至るまでの過程がフロー図で示されたものである。
【００８０】
受信装置Ｐ１が、ユーザによる録画操作を受け付けると（ステップＳＴ３０１）、録画が開始される（ステップＳＴ３０２）。このとき、受信装置Ｐ１は当該番組のデータサイズ（Ｕ）をＥＰＧ（電子番組ガイド）システムより取得し（ステップＳＴ３０３）番組ＤＢのファイルサイズに格納する。一方、受信装置Ｐ１の容量取得部４が実際の空き容量（Ｖ）を取得し（ステップＳＴ３０４）容量管理情報ファイルの空き容量サイズに格納する。
【００８１】
そして、この番組のデータサイズ（Ｕ）と受信装置Ｐ１の実際の空き容量（Ｖ）とを比較し（ステップＳＴ３０５）、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より小さければ、録画が完了されたか否かをチェックし（ステップＳＴ３０６）、録画が完了していなければその１０分後に、番組のデータサイズ（Ｕ）を新たに取得しなおす（ステップＳＴ３０３）。そして、端末の空き容量も再度取得し（ステップＳＴ３０４）、番組のデータサイズ（Ｕ）と受信装置Ｐ１の実際の空き容量（Ｖ）とを比較し（ステップＳＴ３０５）、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より小さければ、録画が完了するまでこの動作を繰り返す。
【００８２】
一方、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より大きければ、容量取得部４の容量不足情報に基づき算出された、受信装置Ｐ１の容量が不足になる容量不足予測時間を含む容量管理情報を第二通知部６ｂから蓄積管理サーバＰ２へ通知する（ステップＳＴ３０７）。
【００８３】
なお、本実施形態では、番組のデータサイズ（Ｕ）と受信装置Ｐ１の実際の空き容量（Ｖ）とを比較し、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より大きくなったときに、第二通知部６ｂからサーバへ通知することとしたが、これに限らず、番組のデータサイズ（Ｕ）が受信装置Ｐ１の実際の空き容量（Ｖ）より小さくても、受信装置Ｐ１の実際の空き容量（Ｖ）自体が少なくなった場合など、任意の条件設定によって、第二通知部６ｂからサーバへ容量不足を含む情報として容量管理情報を通知しても構わない。
【００８４】
また、ナイター中継で試合が延長されたときのように、その番組のデータサイズ（Ｕ）が分からない場合にも、その旨をサーバに通知してもよい。
【００８５】
そして、番組のデータサイズ（Ｕ）を新たに取得しなおす時間を１０分ごととしたが、これに限らず、記録媒体の状態により、時間間隔を短くするなど、任意の間隔で設定しても構わない。
【００８６】
図１３は、上述した受信装置Ｐ１に対応して番組の蓄積を行なう蓄積管理サーバＰ２の、番組（コンテンツ）蓄積過程がフロー図で示されたものである。
【００８７】
蓄積管理サーバＰ２の第二通知受信部１３ｂで受信装置Ｐ１の容量不足情報を受信し、（ステップＳＴ４０１）、第二通知受信部１３ｂで受信した容量不足情報に含まれるデータ識別子で受信するデータを識別し（ステップＳＴ４０２）、第二データ受信部１１で受信する（ステップＳＴ４０３）。
【００８８】
そして、予測時間であるかをチェックし（ステップＳＴ４０４）、予測時間になれば、第二データ蓄積部１２で蓄積が開始され（ステップＳＴ４０５）、コンテンツの蓄積回数や蓄積時間などに応じたデータ蓄積サービス料金が算出される（ステップＳＴ４０６）。
【００８９】
以上のように本実施形態によれば、受信装置が、空き容量に関する容量情報に基づき、受信装置の記録媒体に記録できるか否かをチェックし、記録できないような場合には容量不足になる予測時間をサーバに通知するようにしたものであるため、その情報に基づきサーバが容量不足になる予測時間に蓄積開始するため、突然録画が開始された場合にでも対応できるデータ蓄積機能の充実化が図られたシステムが供給できる。
【００９０】
次に、本実施形態の他のシステムの動作について、図１４に示すフロー図を用いて説明する。
【００９１】
図１４は、蓄積管理サーバＰ２における、番組（コンテンツ）の自動受信を示すフロー図である。
【００９２】
蓄積管理サーバＰ２が、受信装置Ｐ１の空き容量を容量取得部４及び通知部６ａを介して取得する（ステップＳＴ５０１）。また、ＥＰＧ（電子番組ガイド）システムを利用して番組情報を取得する（ステップＳＴ５０２）。
【００９３】
そして、予めユーザにより登録されていた希望番組（コンテンツ）が前記番組情報に含まれているか否かをチェックする（ステップＳＴ５０３）。そして、含まれていなければ、終了する。
【００９４】
希望コンテンツがある場合、受信装置Ｐ１の空き容量を確認し（ステップＳＴ５０４）、空き容量があれば、受信装置Ｐ１に希望コンテンツの蓄積を行ない（ステップＳＴ５０６）、なければ、蓄積管理サーバＰ２に希望コンテンツの蓄積を行なう（ステップＳＴ５０５）。
【００９５】
以上のように本実施形態によれば、蓄積管理サーバＰ２が受信装置Ｐ１の空き容量を管理することで、ユーザの希望するコンテンツを自動蓄積できるシステムを供給できる。
【００９６】
図１５は、蓄積管理サーバの管理により、番組が延びたときにでも、確実に録画蓄積がなされる方法を示したフロー図である。
【００９７】
番組が延びたとき、放送局からの番組時間変更通知をＥＰＧ（電子番組ガイド）システム等を介して蓄積管理サーバＰ２が受信すると（ステップＳＴ６０１）、そこで当該番組を予約したユーザーが特定される（ステップＳＴ６０２）。そして変更時間と元の録画予定時間とを比較し（ステップＳＴ６０３）、変更時間が元の録画予定時間より長ければ、特定されたユーザーの受信装置Ｐ１に蓄積可能な空き容量があるか否かを調べる（ステップＳＴ６０４）。そして、特定された前記受信装置Ｐ１の空き容量の有無に基づき（ステップＳＴ６０５）、空き容量が不足していない場合には、先で特定された受信装置Ｐ１に対して番組の開始終了時間が送信され（ステップＳＴ６０６）、各受信装置Ｐ１にて予約蓄積時間が設定し直されることとなる（ステップＳＴ６０７）。一方、蓄積容量が不足していた場合には、サーバで蓄積される。
【００９８】
以上のように本実施形態によれば、蓄積管理サーバＰ２が受信装置Ｐ１の管理を行なったため、蓄積するコンテンツの蓄積開始時間などに変更があった場合でも蓄積をすることができる、蓄積条件の変更等に強いシステムを供給できる。
【００９９】
次に、本発明の他の実施形態として、ファイルシステムに応用した例を用いて説明する。
【０１００】
本発明のファイルシステムは、例えば各ファイルの属性をファイル・アロケーション・テーブル（ＦＡＴ）を利用して管理するタイプのもので、図１６に示すようにそのディレクトリエントリに、通常定義されているファイル属性に加え、第二ファイル属性を定義しておき、この第二ファイル属性に、前記実施形態におけるデータベースシステムで用いた属性と同様、ファイルの自動的な操作を行なう削除、圧縮、移動、保護のファイル操作情報を有した属性値を付与し、ＯＳ上で稼働させるようにしている。このようにしておけば、記録媒体に容量不足などがあった場合でも、前記ファイル属性に基づいてファイルの自動管理をＯＳが行うため、ファイルが効率的に蓄積される。
【０１０１】
具体的に、本実施形態のシステムの動作について、図１７に示すフロー図を用いて説明する。
【０１０２】
新しいファイルを格納しようとしたとき（ステップＳＴ７０１）、それを格納できる空き領域があれば（ステップＳＴ７０３）、その領域に新しいファイルが格納され（ステップＳＴ７２２）、その格納状態を示す情報が新たにディレクトリエントリ（ステップＳＴ７２３）に書き込まれる。そして、この格納した新しいファイルの第二ファイル属性の設定を行なう（ステップＳＴ７２４）。
【０１０３】
一方、格納できる空き領域が無い場合（ステップＳＴ７０３）には、ＯＳが、ファイル１（ａａａ．ｊｐｇ）、ファイル２（ｂｂｂ．ｍｐｇ）等、既に格納されている既蓄積ファイルに対してその１番目の既蓄積ファイルから（ステップＳＴ７０２）順番にディレクトリエントリに示される第二ファイル属性を読み込み（ＳＴ７０６）、これを基に既蓄積ファイルの削除等の自動操作が行なわれる（ステップＳＴ７０７〜ステップＳＴ７１４）。
【０１０４】
例えば、ファイル１はその格納されているデータ保護を示す第二ファイル属性情報を有しているため（ステップＳＴ７１０）、削除等は行なわれず保護されるため（ステップＳＴ７１４）その格納態様は変わらないが、ファイル２ではデータ削除を示す第二ファイル属性情報を有しているため（ステップＳＴ７０７）、ファイルの削除が行なわれる（ステップＳＴ７１１）。
【０１０５】
ファイル２の削除は、図１８に示すように１つのクラスタに収まらず複数のクラスタにまたがって格納されているデータを削除するものであるが、そのデータの冒頭部分の位置を示すアドレス情報（先頭クラスタ番号）や、データの一部がどのクラスタに飛ばされて格納されているかを示すリンクポインタ（クラスタ番号）や、ファイルサイズ等がディレクトリエントリに記録されているため、これによりなんら問題無く当該ファイルの削除が行なわれ、データを格納する領域が確保されていく。
【０１０６】
また、既蓄積ファイルの第二ファイル属性が圧縮（ステップＳＴ７０８）や移動（ステップＳＴ７０９）を示していれば、その既蓄積ファイルがＯＳによって圧縮されたり（ステップＳＴ７１２）、図示しないネットワークで接続された他のサーバ等へ移動されたりするなど（ステップＳＴ７１３）、自動的に操作されて新しいファイルを格納できる領域が確保されるまで繰り返し行なわれる（ステップＳＴ７０４、ＳＴ７０５）。
【０１０７】
そして、最後の既蓄積ファイルになっても空き領域が確保できない場合には（ステップＳＴ７０４）、ディスプレイに「空き容量不足です。既存蓄積ファイルを削除するなどの設定を行ないますか」との空き容量不足とファイルの属性を再設定とを促す表示を行い（ステップＳＴ７１５）、既蓄積ファイルの第二ファイル属性を再設定するか否かの指示をユーザから受ける（ステップＳＴ７１６）。また、このとき一定時間内にユーザからの指示がない場合には、ステップＳＴ７１７において再設定しないものと判断することとする。
【０１０８】
そして、この指示が再設定するものでなければ（ステップＳＴ７１７）、新しいファイルの蓄積を行なわずに終了し、再設定するものであれば（ステップＳＴ７１７）、既蓄積ファイルの最初のファイルから（ステップＳＴ７１８）、ユーザによって第二ファイル属性の設定が行なわれ（ステップＳＴ７１９）、最後の既蓄積ファイルまで（ステップＳＴ７２０）繰り返し行なわれる（ステップＳＴ７２１）。そして再度、新しいファイルを格納する領域が確保されるまで、既蓄積ファイルの自動操作が順番に行なわれ（ステップＳＴ７０７〜７１４）、格納する領域が確保されれば（ステップＳＴ７０３）、その確保された領域に新しいファイルが格納され（ステップＳＴ７２２）、その格納状態を示す情報が新たにディレクトリエントリ（ステップＳＴ７２３）に書き込まれる。そして、この格納した新しいファイルの第二ファイル属性の設定を行なう（ステップＳＴ７２４）。
【０１０９】
このようにして、ディレクトリエントリにファイルの自動的な操作を行なう削除、圧縮、移動、保護のファイル操作情報を有した属性値を付与し、ＯＳ上で稼働させることで、所望のデータを効率的に蓄積できる。
【０１１０】
なお、本実施形態では、各ファイルの属性をファイル・アロケーション・テーブル（ＦＡＴ）を利用して管理するタイプのファイルシステムとしたが、これに限らず、例えば、ＮＴＦＳファイルシステムやＵＮＩＸ（登録商標）用ファイルシステム等でもよい。
【０１１１】
また、第二ファイル属性の設定をする方法は、ＤＯＳ−ＳｈｅｌｌやＢ−シェル等のＯＳのコマンド・シェルを用いる方法等、任意の方法でよい。
【０１１２】
また、本実施形態では、新しいファイルが格納されるとき、既蓄積ファイルの第二ファイル属性を読み込んだ時に既蓄積ファイルの操作を行なう構成としていたが、これに限らず定期的に既蓄積ファイルのチェックを行う等、任意の時に行なっても構わない。
【０１１３】
そして、上述したようなファイルシステムを受信装置Ｐ１に導入すれば、受信装置Ｐ１に設けられた記録媒体に番組を記録する際、その受信装置Ｐ１の記録媒体に空き容量が無かった場合にでも、ファイルに対して移動や削除や圧縮などの自動操作がなされるため、所望のデータを確実に蓄積でき得るシステムが供給できる。
【図面の簡単な説明】
【０１１４】
【図１】本発明の実施形態における全体機器構成図。
【図２】同実施形態における受信装置Ｐ１の内部機器構成図。
【図３】同実施形態における蓄積管理サーバＰ２の内部機器構成図。
【図４】同実施形態における受信装置Ｐ１及び蓄積管理サーバＰ２の動作を示すフロー図。
【図５】同実施形態における受信装置Ｐ１での格納態様。
【図６】同実施形態における蓄積管理サーバＰ２での格納態様。
【図７】同実施形態における受信装置Ｐ１でのデータが蓄積される過程を示すフロー図。
【図８】同実施形態における受信装置Ｐ１でのデータが蓄積される過程を示すフロー図。
【図９】同実施形態における受信装置Ｐ１でのデータが蓄積される過程を示すフロー図。
【図１０】同実施形態における受信装置Ｐ１でのデータが蓄積される過程を示すフロー図。
【図１１】同実施形態における蓄積管理サーバＰ２でのデータが蓄積される過程を示すフロー図。
【図１２】同実施形態における受信装置Ｐ１でのデータが蓄積される他の過程を示すフロー図。
【図１３】同実施形態における蓄積管理サーバＰ２でのデータが蓄積される他の過程を示すフロー図。
【図１４】蓄積管理サーバＰ２における、番組（コンテンツ）の自動受信を示すフロー図。
【図１５】蓄積管理サーバの管理により、番組が延びたときにでも、確実に録画蓄積がなされる方法を示したフロー図である。
【図１６】ＦＡＴファイルシステムに応用したときのディレクトリエントリを示した図。
【図１７】同システムにおけるファイルの自動操作を示すフロー図。
【図１８】同システムにおけるディレクトリエントリに関連付けられたデータの格納態様を示した図。
【符号の説明】
【０１１５】
Ｐ１…受信装置
Ｐ２…蓄積管理サーバ（サーバ装置）
１…データサイズ取得部
２…記録媒体状態予測部
３…データ操作部
４…容量取得部
５…データ送信部
６ａ…通知部
６ｂ…第二通知部
７…記録予約情報受付部
８…記録媒体
１１…第二データ受信部
１２…第二データ蓄積部
１３ａ…通知受信部
１３ｂ…第二通知受信部
１４…蓄積状況取得部
１５…サービス料算出部
【図１】
0004125345.tif 000002
【図２】
0004125345.tif 000003
【図３】
0004125345.tif 000004
【図４】
0004125345.tif 000005
【図５】
0004125345.tif 000006
【図６】
0004125345.tif 000007
【図７】
0004125345.tif 000008
【図８】
0004125345.tif 000009
【図９】
0004125345.tif 000010
【図１０】
0004125345.tif 000011
【図１１】
0004125345.tif 000012
【図１２】
0004125345.tif 000013
【図１３】
0004125345.tif 000014
【図１４】
0004125345.tif 000015
【図１５】
0004125345.tif 000016
【図１６】
0004125345.tif 000017
【図１７】
0004125345.tif 000018
【図１８】
0004125345.tif 000019