(57)【要約】  本発明は、一組のデータの分散化した記録方法に関するものである。本発明の方法は、要求側装置が記録処理要求を送信するステップと、通信ネットワークを通して要求側装置に接続された、要求側装置とは異なる少なくとも１つの装置に記録を分散させるステップとを含む。
2010519668.tif 000002
【特許請求の範囲】
【請求項１】
要求側装置が記録処理要求を作成するステップと、
通信ネットワークを通して前記要求側装置に接続された、前記要求側装置とは異なる少なくとも１つの装置へ記録処理を分散させるステップと
を含む、一組のデータの記録方法。
【請求項２】
記録処理データを記憶するために利用可能な、前記要求側装置の記憶容量を表す情報を取得して、利用可能な容量に関する情報を送信するステップと、
前記利用可能な容量に関する情報に応じて、前記ネットワークに接続された少なくとも１つの記憶装置を特定し、前記記録処理データの記憶処理の少なくとも一部を行うステップと
を含む請求項１に記載の記録方法。
【請求項３】
前記少なくとも１つの記憶装置を特定する前記ステップは、中央の記録処理サーバにより実行されるものである、請求項２に記載の記録方法。
【請求項４】
前記特定するステップは、
前記記録処理データを記憶するために必要な容量と、前記要求側装置において利用可能な容量に関する前記情報が表す容量との差分から得られる容量を計算するステップと、
得られた容量に応じて、前記記録処理データの少なくとも一部を記憶することのできる少なくとも１つの装置を、複数の装置の中から探索するステップと
を含むものである、請求項２又は３に記載の記録方法。
【請求項５】
記録処理要求を管理するサーバへ記録処理要求を送信するステップと、
決定された少なくとも１つの処理パラメータに基づいて、前記管理するサーバが前記記録処理要求を処理するステップと、
前記記録処理要求を表す少なくとも１つの情報を前記記録処理サーバへ送信するステップと
をさらに含む請求項１から４のいずれか一項に記載の記録方法。
【請求項６】
決定された少なくとも１つの処理パラメータが、前記通信ネットワーク内の前記複数の装置における記録処理データの冗長度を表す情報である、請求項５に記載の記録方法。
【請求項７】
決定された少なくとも１つの処理パラメータが、前記通信ネットワーク内の前記複数の装置における記録処理データの最大保存期間を表す情報である、請求項６に記載の記録方法。
【請求項８】
通信ネットワーク内で互いに接続された少なくとも２つの装置にわたって分散される、視聴覚番組を表す一組のデータであって、各装置は、利用可能な記憶リソースを有し、記録処理の一部を実行するものである、一組のデータ。
【請求項９】
ある通信ネットワークからダウンロードすることのできる、及び／又はコンピュータが読み取り可能な媒体上に記憶された、及び／又はマイクロプロセッサが実行することのできるコンピュータプログラム製品であって、請求項１から６のいずれか一項に記載の記録方法をコンピュータに実行させるプログラムコード命令を含むコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば個人向けマルチメディアストリームによって送られるデータなどの一組のデータの記録の分野に関する。
【背景技術】
【０００２】
従来、ビデオストリームやオーディオストリームといったマルチメディアストリームの記録は、主にローカルで行われている。これは、１つ以上のこのようなストリームを記録しようとするユーザが、記録可能な装置を所有していなければならないことを意味する。このような装置としては、例えば、ビデオテープレコーダ、ＤＶＤ（ディジタル多用途ディスク）型ディスクレコーダ、またはハードディスクドライブレコーダが挙げられる。
【０００３】
ｘＤＳＬ（ディジタル加入者線）型ネットワーク、有線ネットワーク、ＷｉＦｉ（無線ローカルエリアネットワーク構築のための規格を特定する無線接続性）型無線ネットワーク、又はＤＶＢ（ディジタル映像放送）規格に基づくネットワークを使用したテレビ番組放送の出現により、新しい番組記録の方法、特にネットワークにおける番組記録が可能となっている。
【０００４】
ネットワーク内での番組の記録、特に映像番組や音声番組の記録が登場してきたのは、このような高速ネットワークを使ったこのような番組の放送が大幅に増えたためである。これらの番組は事業者を通して加入者に放送される。番組の受信を可能とするために、事業者は、ＳＴＢ、すなわちセットトップボックスとも呼ばれるディジタル端末を加入者へ提供する。この端末は、加入者が通信ネットワークを通して番組に対応するディジタルストリームを受信し、これらのストリームを圧縮解除し、例えばテレビ受像機やコンピュータ画面や音声レンダリング装置などのための装置に提供するために加入者により使用される。
【０００５】
また事業者は、これらのディジタルストリームを事業者のネットワーク内で記録させることによる、新たなディジタルストリームの記録の方法も提案している。よって、放送を記録しようとする加入者は、必ずしも、自由に使える個人用記録装置を持つ必要はない。この加入者は、ネットワークを介してストリームの記録を指示することができ、事業者は事業者のネットワーク内でこの記録に必要なリソースを割り振るタスクを引き受ける。また事業者は、システマティックなもの又はほぼシステマティックなものとしてストリームの記録を行う。よって、記録するつもりのなかった番組を見ようとする加入者であっても、事業者のネットワークによってその番組を見ることができ、事業者に応じて長さの異なる期間にわたりその番組を見ることができる。つまり、事業者は、「ビデオオンデマンド」型のサービスを提供する。
【０００６】
このような記録方法は、一般に、ＮＰＶＲ（Network Personal Video Recording）という名称のグループに分類される。
【０００７】
この原理は、１つ以上の記録コマンドを中央記録処理サーバに送り、記録処理サーバが記録すべきストリームを特定し、これらのストリームをネットワーク内の専用の記憶スペースに保存するというものである。
【０００８】
よって、ＮＰＶＲ型の記録方法は、特定のアプローチを利用して加入者にサービスを提供するものであるとともに、原則的には、事業者の投資が一度に低減できるようにするものである。というのは、加入者の自宅に特別なディジタル端末を設置する必要がなく、同時に記憶コストもプールできるからである。よって理論的には、複数の顧客が同じ送信をプログラムすると、この送信は事業者により１回だけ記録されることになる。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、この従来技術の１つの欠点は、事業者が記録すべきストリームの管理が相対的に複雑になることである。よって、加入者が記録するつもりではなかった放送が持続性を持つように、事業者は、すべてのチャンネルを永続的に記録し、後で視聴又は記録される放送だけを保存するように消去を実行する。
【００１０】
この従来技術の別の欠点は、相当な大きさになり、プールすることのできない帯域幅の使用に関連するものである。実際、事業者は、要求に応じて記録されたストリームを再放送する。したがって、記録されたストリームの放送は、ユニキャスト（ポイントツーポイント形式）で、すなわち加入者に対して直接的に行われる。
【００１１】
さらに、加入者は完璧なレンダリング品質を要求する。これに応じて、事業者は、可能な限り顧客の近くに事業者のサーバを複製し、その記憶容量を大幅に増加させる必要がある。ビデオオンデマンドサーバの価格は非常に高いため、インフラストラクチャのコストは、いっそう増加する。
【課題を解決するための手段】
【００１２】
本発明は、一組のデータを記録する独自の方法によって、従来技術の欠点を有しない解決策を提供するものである。
【００１３】
本発明の方法は、要求側装置が記録処理要求を作成するステップと、通信ネットワークを通して前記要求側装置に接続された、前記要求側装置とは異なる少なくとも１つの装置へ記録処理を分散させるステップとを含む。
【００１４】
よって、本発明の記録方法は、実際に記録を保存する装置であるとは限らない装置が記録処理要求を作成することを可能とする。一組のデータの物理的な記録は、記録処理要求が作成された装置とは別の複数の装置へ分散される。したがって本発明の方法は、ローカルの装置が提供する可能性のみを考慮した従来技術とは異なり、記録を行うためにネットワーク内の装置を考慮する際に使用することができる。
【００１５】
本発明の一実施形態によれば、上記方法は、記録処理データを記憶するために利用可能な、前記要求側装置の記憶容量を表す情報を取得して、利用可能な容量に関する情報を送信するステップと、前記利用可能な容量に関する情報に応じて、前記ネットワークに接続された少なくとも１つの記憶装置を特定し、記録処理データの記憶処理の少なくとも一部を行うステップとを含む。
【００１６】
よって、本発明による記録方法は、記録処理データを記憶するために必要な容量（すなわち、各装置が記憶のために提供できる物理的に可能な容量）を考慮して、記録処理データのための１つ以上の記憶場所を決定することを可能にする。「一組のデータの記録」という用語は、この一組のデータを後で使用する目的で保存したものを意味するものである。かかる記録は、後で見ることができるような、記憶物、すなわち物理的な保存でなければならない。したがって、本発明は、従来技術とは異なり、記憶場所を決定するためにネットワーク内の各装置（通信端末、ルータ、サーバ）における利用可能な記憶容量を考慮することを可能にする。
【００１７】
よって、本発明の方法は、例えば、十分な容量のない装置などに対して、記録処理データを記憶したもののうちの全部又は一部をネットワーク内の他の装置へ転送できる可能性を提供する。この種の記憶容量の分散化によりコストがプール化される。言い換えると本発明は、記録処理を要求する装置が、要求した記録処理データを保存するために、ネットワーク内の他の装置の記憶容量を利用することを可能とする。
【００１８】
本発明の一態様によれば、上記記録処理要求は、少なくとも、上記要求側装置の識別子を表す情報と、記録の開始時点を表す情報と、記録の終了の時点を表す情報と、上記一組のデータに対応する少なくとも１つのディジタルストリームの識別子を表す情報とからなるグループに属する少なくとも１つのパラメータを含む。
【００１９】
よって、記録を行おうとするネットワーク内の装置は、そのような装置（例えば識別子などの形式）と、一組のデータに関する情報（例えば特定の視聴覚番組などの形式）との間のリンクを作成することを可能にする情報を提供する。次いで、記録処理要求は、これらのパラメータを提供することにより、分散した記憶容量を効率よく使用できるように記録を管理することを可能にする。
【００２０】
本発明の一実施形態によれば、少なくとも１つの記憶装置を特定する上記ステップは、中央の記録処理サーバ内で実行される。
【００２１】
よって本発明は、記憶装置の決定を集中化するために使用される。かかる１つの実施形態では、この集中化により、装置内の記憶容量のプール化に関連する課題を解決できる。実際、ネットワーク上の記録の従来技術によれば、記録処理はビデオオンデマンドサーバ上で行われる。かかるサーバは、この用途に利用可能な記憶容量の特性、すなわち巨大な容量を有する。したがって、従来技術は記憶サーバの集中的な特定を必要としない。しかし、本発明のこの実施形態では、この記憶容量は、必ずしもその大きさの記憶容量が利用できるとは限らない複数の記憶装置へ分散される。したがって、この実施形態では、記憶装置を決定する処理を集中化して処理をより簡単にすることができる。
【００２２】
本発明の一態様によれば、前記特定するステップは、前記記録処理データを記憶するために必要な容量と、前記要求側装置において利用可能な容量に関する前記情報が表す容量との差分から得られる容量を計算するステップと、得られた容量に応じて、前記記録処理データの少なくとも一部を記憶することのできる少なくとも１つの装置を、複数の装置の中から探索するステップとを含む。
【００２３】
よって本発明は、少なくとも１つの記憶装置を、その利用可能な記憶容量に応じて選択することにより、ネットワーク内で行われる記録処理データの保存を分散（delinearize）させることを可能にする。ネットワーク内の装置が有する利用可能な記憶容量は、これらの装置が要求側装置へ送ることができ、これらの情報を提供するデータベースの問い合わせによって決定できる。したがって、選択された記憶装置は、記録処理データの全部又は一部の記憶を実行する命令を受け取る。例えば、第１の装置は、１時間などの長さを有するその記録処理データの第１の期間を記憶し、第２の装置は、０．５時間などの長さを有するその記録処理データの第２の期間を保存する。よって記憶容量が大幅に合理化される。また、この記録処理の分散という側面を、ユーザからの記録処理要求の考慮と組み合わせることもできる。例えば、２人のユーザが異なる時刻に同じ番組の記録処理を要求している場合には、ユーザの装置の記憶容量においてはそのユーザが要求した部分の記録処理を優先させ、同時に他のユーザのためにその番組全体を保存することもできる。
【００２４】
一実施形態によれば、上記方法は、記録処理要求を管理するサーバへ前記記録処理要求を送信するステップと、決定された少なくとも１つの処理パラメータに基づいて、前記管理するサーバが前記記録処理要求を処理するステップと、前記記録処理要求を表す少なくとも１つの情報を前記記録処理サーバへ送信するステップとを含む。
【００２５】
よって本発明は、記録処理を管理するサーバにおいて、通信ネットワークを構成する異なる装置によって送信されたデータを集中化するために使用される。この集中化は、記憶装置の決定の効率を上げる処理パラメータに応じて記録処理要求を一様に処理するために行われる。
【００２６】
本発明の一態様によれば、決定された少なくとも１つの処理パラメータは、上記通信ネットワーク内の複数の装置における記録処理データの冗長度を表す情報である。
【００２７】
よって、冗長度以下で記録処理データが有効に記憶される閾値を定義するために使用される、フィードバック制御パラメータともいう冗長パラメータに基づいて、記録処理データを管理することができる。実際、通信ネットワーク内の記憶装置における誤動作を軽減するためには、１つの記録処理データを複数回にわたって記憶することが必要になる場合もある。その場合、これらの複数の記憶処理は、この冗長パラメータによって制御される。本発明の一実施形態では、この冗長パラメータの値を１とすることができる。この場合、複数の記憶装置内には記録処理データの１つのコピーだけが保持される。
【００２８】
本発明の一態様によれば、決定された少なくとも１つの処理パラメータは、上記通信ネットワーク内の複数の装置における記録処理データの最大保存期間を表す情報である。
【００２９】
また、本発明の方法は、記録処理データの保存期間を管理するために使用することもできる。実際、装置は、その装置自体の記憶容量内に少なくとも全体としては保持されない記録処理を要求するのであるから、この記録処理データをそれ以上保存できない時点を決定する必要がある。かかる制約条件は、異なる装置の記憶容量の適切な使用を保証するために必要であることが分かる。
【００３０】
また本発明は、視聴覚番組を表す一組のデータにも関連するものである。
【００３１】
本発明によれば、かかる一組のデータは、それぞれが利用可能な記憶リソースを有し、それぞれが上記記録処理データの一部を保持する、通信ネットワーク内で互いに接続された少なくとも２つの装置へ分散される。
【００３２】
よって、この種の一組のデータは、記憶リソースの使用を最適化すると同時に、一組のデータの永続性の保証も行う。
【００３３】
本発明の別の実施形態は、通信ネットワークからダウンロードすることのできる、及び／又はコンピュータ読み取り可能な媒体上に保存された、及び／又はマイクロプロセッサが実行することのできるコンピュータプログラム製品に関連する。
【００３４】
本発明の別の実施形態では、かかるコンピュータプログラム製品は、前述の記録方法を実行するためのプログラムコード命令を含む。
【００３５】
本発明の他の特徴及び利点について、単なる説明のための非限定的な例によって与えられる以下の好ましい実施形態の説明と、添付の図面を参照して説明する。
【図面の簡単な説明】
【００３６】
【図１】本発明の記録方法を実施するためのシステムの一般的なアーキテクチャを示すブロック図である。
【図２】本発明による要求管理サーバの簡略化したアーキテクチャを示す図である。
【図３】本発明による記録処理サーバの簡略化したアーキテクチャを示す図である。
【発明を実施するための形態】
【００３７】
したがって、本発明は、共有型及び分散型（delinearized）の視聴覚番組の記録を提案するものである。このような記録は、例えば、ローカルでのディジタル記録、及び事業者やインターネットサービス提供者などがユーザへ提供する通信ネットワーク上の記録と組み合わせて定義される。
【００３８】
よって、この種の記録を組み合わせれば、ＶＯＤ（ビデオオンデマンド）ネットワークリソースを不必要に独占すること、ならびに記録の実記憶（real storage）が全てのセットトップボックス上及び全てのＶＯＤサーバ上に分散されることを防止できる。また本発明は、異なる人（例えば近接したユニット内に位置する人など）が行った記録を取り出すための記録の共有も提案する。
【００３９】
また本発明は、だれも自発的には、あるいはその時点では、その記録を要求していない視聴覚番組を記録するために、ＳＴＢ（セットトップボックス）の記録処理の実行を集中的に行うことも提案する。
【００４０】
したがって、本発明の原理は、ネットワークにおける異なる主体の間でのリソースの共有を利用して、各ユーザの記録のための記憶容量をプールするものである。
【００４１】
よって、ネットワークインフラストラクチャの提供者は、利用可能なＳＴＢを有するユーザにより提供される記録の可能性を増加させるというスケールメリットを得ることができる。実際、すでに述べたように、ユーザの記録容量には限界があることが非常に多く、事業者は、ネットワーク記録（ＮＶＰＲ）によっては、ユーザに無制限な記憶容量を提供することはできない。したがって本発明は、ユーザの記憶リソースをプールして、各ユーザの総記憶容量と、このユーザが、（見落としなどのために）プログラムしていない記録を見る可能性との両方を増加させることを提案する。
【００４２】
したがって、ネットワーク上の特別なエンティティ（記録処理サーバとも呼ばれる）が、要求されていない記録の保存などを行わせることができる。すなわち、記録処理サーバは、後で分散的に（delinearized）アクセスするために、いく人かのユーザのＳＴＢと、記録処理サーバ固有の記憶リソース（専用ハードディスクドライブ）の両方にある一定数のチャンネルを絶えず記録する。したがって、本発明のこの実施形態では、記録処理サーバは、ＳＴＢのハードディスクドライブに対する完全なフィードバック制御を確立することができる。よって、１つ以上のＳＴＢを放送の記録処理のために使用することができる。
【００４３】
また本発明は、ユーザが、中央ビデオオンデマンドサーバの提供するレンダリング品質より高いレンダリング品質を得ることも可能にする。実際、本発明の１つの特定の実施形態では、近接集合（proximity set）が定義される。この近接集合は、事業者又は提供者のネットワークに接続され、地理的に近接したネットワークを介して記録のためのサービスに加入しているユーザからなる。
【００４４】
以下、本発明を実施するいくつかの形態を説明する。しかし、本発明がこれらの特定の実施形態に限定されないことは明らかである。特に、提示されるアーキテクチャは例示のためのものに過ぎず、本発明の一般的な概念は、当然ながら、ネットワーク上における記録処理データの分散化というものである。
【００４５】
この実施形態では、ユーザが作成した記録処理要求の管理に寄与する要求管理エンティティを稼働させる技術的アーキテクチャに関連して、本発明の記録方法の実施を説明する。また、このアーキテクチャは、各ユーザの異なる記録処理データの保存の管理全般を担う記録処理サーバも稼働させるものである。
【００４６】
したがって、要求管理サーバは、各端末と、要求された放送と、保存場所（端末又はネットワーク）とのリファレンスを含むデータベースを用いて、記録処理要求の管理を行う。記録処理サーバは、要求管理サーバの要求によりネットワークに映像コンテンツを保存する。
【００４７】
したがって、この実施形態では、記録処理は２段階で行われる。第１段階では、各ユーザが、記録処理要求を処理する要求管理サーバへ自己の記録処理要求を行う。第２段階では、ユーザのパラメータ、ユーザのディジタル端末及び要求管理サーバが行った決定に応じて、記録処理サーバがユーザの要求した記録処理データの効率的な保存を指示することができる。
【００４８】
図１を用いて、この実施形態を簡単に説明する。
【００４９】
端末（住宅用ゲートウェイやＳＴＢ型端末など）１００は、事業者又はアクセスプロバイダのネットワーク１０１に接続されている。この端末は、ネットワークから（マルチキャスト又はユニキャスト）ディジタルストリームを受け取る。また、この端末１００は、要求管理サーバ１０３にも接続されており、要求管理サーバ１０３へ要求（記録処理要求など）を送り（符号１００２）、次いで要求管理サーバ１０３から要求を受け取る（１００３）。
【００５０】
要求管理サーバ１０３は、事業者ネットワークによって記録処理サーバ１０４に接続されている。記録処理サーバ１０４へ記録処理データの保存を求める要求を送り（１００４）、記録処理サーバ１０４からこれらの要求に対する応答を受け取る（１００５）。ネットワークにより、あるユーザへ記録処理データを提供（render）する場合には、記録処理サーバ１０４は、端末１００へ映像ストリーム（例えば、１ユーザだけを対象とする場合にはユニキャストなど）を提供する（１００６）。ユーザが記録処理データを取り出す場合には、記録処理サーバ１０４は、それに対応するストリーム又はストリームの一部を端末１００から受信する。
【００５１】
この実施形態において、要求管理サーバ１０３は、ユーザが要求した番組の記録処理を管理するデータベース１００７を備えている。このデータベースにおいて、要求管理サーバ１０３は、記録処理要求ごとに、記録処理のリファレンス（チャンネル番号、開始時刻、終了時刻など）をユーザのディジタル端末の一意の識別子へ関連付ける。
【００５２】
実際、この実施形態では、ユーザのディジタル端末は、ハードディスクドライブなどの独自の記憶容量を備えていてもよい。当然ながら、この実施形態は実施の一例に過ぎない。この点に関して、要求管理サーバは、例えば、パーソナルコンピュータ又は個人用ストレージサーバなどの他の周辺装置を用いた、ユーザの通信ネットワーク内で利用可能な記憶リソースなどといった、ユーザのあらゆる記憶リソースの使用を想定する必要がある。
【００５３】
したがって、要求管理サーバ１０３は、このデータベース１００７からユーザの記録処理の恒久的な情報を得ることができる。
【００５４】
この実施形態では、様々な主体と関連づけのやり方との関係を区別する必要がある。
【００５５】
ユーザが端末に対してコマンドとして作成する記録処理要求の管理について、この実施形態では、以下の２つの場合が考えられる。
場合１：  ユーザの端末１００のディスクドライブ上に十分な空き容量がある。この場合、保存はローカルに行われる。記録処理の終了時に、端末１００はサーバ１０３に対して記録処理が終了したことを通知する。記録処理が（例えば異常などの後で）適切に行われなかった場合には、端末１００は異常メッセージによってサーバ１０３へ知らせる。
場合２：  ユーザのディスクドライブが満杯であるか、又はユーザのディスク上に十分なリソースがない。要求管理サーバ１０３は、記録処理要求及び端末のリファレンスを記憶し、その要求を記録処理サーバ１０４へ送る。
【００５６】
いずれの場合も、記録処理要求は、例えば以下のようなユーザのプログラミングのパラメータを含む。
・即時の記憶の場合には、開始時刻及び記録する時間
・予約設定された記録処理の場合には、記録処理の開始及び終了の日時
・論理記録の場合には、例えば、番組ガイドなどから得られた視聴覚番組の識別子
【００５７】
当然ながら、本発明の他の実施形態では、記録処理時に、場合１から場合２へ移行することもありうる。つまり、そのハードディスクドライブ上に空き容量がある端末１００が視聴覚番組の記録をローカルに開始した場合に、この容量全体がまだ完了していない記録処理データによって使い果たされたときには、端末１００は要求管理サーバ１０３へネットワーク上での記録処理の継続を求めることができる。
【００５８】
ユーザの端末のハードディスクドライブ上に十分な容量があるときには、読み取り時に帯域幅を不必要に使用するのを防ぐために、ユーザ端末のハードディスク上で記録処理が行われる。その際、ネットワーク上に記録するためにユーザの端末の少なくとも一部のフィードバック制御を行う一実施形態においては、このローカルな記録処理により、結果的に記録処理サーバ１０４が記録処理のための場所を確保する必要はなく、端末（ＳＴＢなど）に対するフィードバック制御は不要である。
【００５９】
言い換えると、ユーザの端末に対するフィードバック制御の管理は、ユーザ自身の記録処理要求に応じて動的に行われる。よって、ある視聴覚番組がすでに他の場所でいくつか記録されている場合には、端末上でこの番組の記録処理を指示することにより端末のフィードバック制御を確立する必要はない。
【００６０】
しかし、端末に技術的な問題が発生した場合には、これを解消するために、冗長な記録s処理を実行する必要がある。よって、冗長閾値Ｎが決定され、これはフィードバック制御パラメータとも呼ばれ、所与の記録処理データへのアクセスを保証するのに使用される。
【００６１】
記録処理データの読み取りに関しては、以下の３つの場合を考慮する必要がある。
場合１：  記録処理はユーザの端末上で行われている。したがって、読み取りは端末から直接的に行われる。この端末は、この端末が利用できないことを要求管理サーバへ通知する。読み取りが終了すると、端末は、この端末が利用可能になったことを要求管理サーバへ通知する。記録処理データ自体の読み取りの開始は、要求管理サーバによって行われ、要求管理サーバが端末へ読み取りコマンドを出す。
場合２：  記録処理データは記録処理サーバに要求される。したがって、端末は、要求管理サーバへコンテンツ読み取り要求を行う。それに応じて、要求管理サーバは、
・ストリーミングサーバのアドレス、例えば、記録処理サーバの記録処理データを放送するための「ユニキャスト」アドレスと、
・コンテンツのパラメータ（識別子、開始時刻、終了時刻など）
といった、コンテンツを読み取るのに必要な情報を端末へ送る。
場合３：  ユーザは、ネットワーク内で記録処理データを探す。実際に、本発明は、記憶リソースと記録処理データそのものの両方のプール化を可能にするものであると考えることができる。したがって、ユーザは、自分では予約設定するつもりのなかった記録処理データを探索することも全く可能である。その場合、端末は、端末の探索パラメータを要求管理サーバへ送り、要求管理サーバは、記録データベース１００７内で探索を行う。探索要求のパラメータは例えば、
・記録処理の開始と終了の日時、及び／又は
・要求されている放送の識別子
などとすることができる。
【００６２】
場合２及び場合３では、記録処理サーバは、１つ以上の端末又は記録処理サーバ自体の記憶リソースに問い合わせてコンテンツを組み立て直すよう、要求されていない記録処理のドライバへ要求する。これらの端末はストリームを送るか、又はコンテンツをダウンロードし、そのコンテンツがユーザの端末へリダイレクトされる。この機構は、アップリンク（端末からサーバまで）の帯域幅に左右されるため、中間サーバをシステムに介在させて高品質のフルストリームを再構築することができる。
【００６３】
記録処理データを消去する処理に関して、本発明は、本明細書で説明する実施形態において、ユーザのリソースを最大限までプール化しようとするものである。よって、どんな消去処理の前にも、消去される記録処理データの後のアクセスの条件についてのチェックが行われる。
【００６４】
以下の２つの場合を区別する必要がある。
場合１：  コンテンツはユーザの端末のディスクドライブ上にある。消去を許可する際に、要求管理サーバ１０３は、そのコンテンツがネットワーク内にあるかどうかを記録処理サーバ１０４へ問い合わせるか、又はそのコンテンツが他の端末においてまだ利用できるかどうかをチェックする。そのコンテンツがその端末において利用できず、Ｎ個の端末上でのみ利用できる場合には、要求管理サーバ１０３は、関与する端末のうちの１つにおけるコンテンツの取得を要求しなければならない。
場合２：  コンテンツは、（例えば別の端末上や記録処理サーバ内などの）ネットワーク内に記録されている。その場合、要求管理サーバは、そのデータベース１００７内のこの記録に対してそのユーザを消去するだけにとどめる。
【００６５】
場合１において、Ｎはフィードバック制御パラメータである。これは、ネットワークにおいて記録処理データが利用できることを保証するために用いられる値である。言い換えると、複数のユーザによって記録されている視聴覚番組について、関与するすべてのユーザがその番組の消去を要求しない限り、又はやはりパラメータ化可能な一定期間が経過しない限り、いつでも利用できるようにするためにこのパラメータが用いられる。
【００６６】
本明細書で説明する実施形態において、予約設定の変更が可能なのは、まだ開始していない記録処理についてだけである。端末に十分な容量がある場合と、端末に十分な容量がない場合とを区別する必要がある。
場合１：  ユーザの端末のディスク上に十分な空きがある。端末１００は、変更を求める要求を要求管理サーバ１０３へ出し、要求管理サーバ１０３は要求を受け入れ、そのデータベース１００７内での変更を考慮する。
場合２：  ユーザの端末のディスクは満杯である。要求管理サーバ１０３は、そのデータベース１００７内での変更を考慮し、記録処理サーバへ変更を考慮するよう求める。
【００６７】
本明細書で説明する実施形態において、ユーザは、事前にその記録処理が要求されていないコンテンツを探索する可能性がある。かかる探索では最初に、端末１００は、そのコンテンツが利用できるかどうかを、優先して記録処理サーバ上で、次いで各端末上で確認するための探索を行うために、探索コマンドをデータサーバ１０３へ送る。コンテンツが端末においてのみ利用できる場合、そのコンテンツは記録処理サーバ上で取得されなければならない。
【００６８】
後者の場合、コンテンツが取得された後に、要求管理サーバ１０３はその応答として、
・ストリーミングサーバのアドレス
・コンテンツのパラメータ（識別子、開始時刻、終了時刻など）
といった、そのコンテンツを読み取るのに必要な情報を端末１００へ送る。
【００６９】
端末内で利用できるコンテンツを取得するために、要求管理サーバ１０３は最初に、コンテンツを端末１００へロードする許可を求める。かかる許可は、例えば、その端末１００が利用できない場合、あるいはユーザがこのコンテンツを公開したくない場合には拒否することもできる。第２の段階において、要求管理サーバにダウンロードの許可が与えられると、要求管理サーバは、コンテンツをダウンロードする記録処理サーバへその許可を転送する。
【００７０】
ネットワーク上での記録処理の間（例えば、ユーザの端末のハードディスクドライブ上に十分な容量がなくなったときなどに）、要求管理サーバ１０３は、そのデータベース１００７における端末からの記録処理要求を考慮した後に、その視聴覚番組の記録処理を記録処理サーバ１０４へ求める。記録処理サーバ１０４は、その記憶容量内で利用可能な場所をチェックする。容量が十分にある場合には、記録処理サーバ１０４は、記録処理要求の承諾を要求管理サーバ１０３へ通知すると同時に、この記録処理の記憶識別子を与える。
【００７１】
ユーザからの消去要求が要求管理サーバ１０３へ送られると、要求管理サーバ１０３は、その要求を考慮して、その記録処理データがネットワークにおいて記憶されている場合には、この消去要求を記録処理サーバ１０４へ送る。記録処理サーバ１０４は、必要なチェックを行った後に記録処理データを消去し、その旨を要求管理サーバ１０３へ知らせる。
【００７２】
記録処理データを有する第１のユーザ側のダウンロードの承諾を受け取った場合に、その記録処理データを第１のユーザの端末から記録処理サーバ１０４へダウンロードする必要があるとき（例えば、消去要求や第２のユーザが行った探索の後など）には、記録処理サーバ１０４は、ダウンロードを実行して、その記録処理データを記録処理サーバ１０４の記憶容量内に保存する。コンテンツのロードが終了すると、記録処理サーバ１０４は、コンテンツが取得されたことを要求管理サーバ１０３に知らせ、コンテンツに一意の識別子を付与する。
【００７３】
本発明の一実施形態では、クライアントの端末のフィードバック制御と一緒に、各端末における補完的な記録処理データの分散を作成することができる。かかる分散化は、例えば、数個の端末上に記録処理データを分散させることにより、記憶容量の利用を最適化するなどのために行われる。
【００７４】
よって、例えば、記録処理サーバは、視聴覚番組の記録処理を数個の端末へ分散させることを決定することができる。例えば、この実施形態では、ある端末は番組の最初の２０分間の記録処理（及び保存処理）を担当し、別の端末は次の２０分間を記録し、以下同様にして、その視聴覚番組の最後まで記録する。よって、本発明のこの実施形態によって記録された視聴覚番組を記録処理サーバへ転送する間に使用される帯域幅を低減することができる。実際、各端末は、短時間に対応する限られた量のデータだけを送信すればよい。したがって、各端末は、ごくわずかな時間にわたり実行するのみであり、ユーザのインターネット接続の利用が過度に制限されることはない。
【００７５】
本発明の少なくとも１つの実施形態では、記録処理データのセグメント化を行う。実際、視聴覚番組は、とりわけ複数のディジタルストリームで構成されている。これらのディジタルストリームに対して、セグメント化を実行することもできる。その場合、記録処理データは、一組のセグメントからなり、各セグメントは、あるストリーム、開始時刻及び終了時刻に対応する。したがって、あるセグメントは、記録処理データを構成するその他のセグメントとは独立して記憶することのできるその記録処理データの一部を表す。
【００７６】
よって、記録処理データのプール化の割合はさらに増加する。実際、この実施形態は、ユーザによって異なるパラメータを用いて視聴覚番組を記録できることを考慮するものである。
【００７７】
従来技術においては、１つの視聴覚番組Ｐについて、ユーザＵ１は、２０時００分に開始して２２時００分に終了する記録を「予約設定」し、別のユーザＵ２は１９時５５分に開始し２２時０５分に終了する記録を「予約設定」する。その場合、要求管理サーバは、以下のどちらを選ぶかという問題に直面する。
・（ユーザＵ２が不満を持つ危険を冒して）ユーザＵ２のパラメータを使用せず、ユーザＵ１の記録のただ１つの記憶だけを記録処理サーバに求めることにする。ここで、この記録処理データは、ユーザＵ１にも、ユーザＵ２にも、他の潜在的なユーザにも使用されうる。
・不必要にデータが重複するリスクを承知の上で、すべてのユーザのすべてのパラメータを使用する。この場合、ユーザＵ１とユーザＵ２は満足するが、その視聴覚番組は重複するタイムスロットを用いて２回記録されることになる。
【００７８】
この実施形態では、例えば５分単位のセグメントを用いて記録処理データをセグメント化すれば、リソースのプール化が可能になる。よって、前述の例では、ユーザＵ２は、その端末のハードディスクドライブにおける空き容量に応じて、１９時５５分〜２０時００分のタイムスロットに対応するセグメントと、２２時００分〜２２時０５分のタイムスロットに対応するセグメントとの両方をローカルで持つことができるはずであり、残りのセグメントは、各ユーザの端末のフィードバック制御があるか又はない状態で、ネットワークにおいて記憶される。
【００７９】
言い換えると、記録処理は、各ユーザ自身の予約設定要求を満たすと同時に、不要な情報の重複を防ぐために、各ユーザの端末へ分散される。端末のフィードバック制御の場合には、フィードバック制御パラメータＮが使用される。したがって、このパラメータは、各セグメントのフィードバック制御を可能にする。この結果、要求管理サーバでは、各ユーザ要求の管理がより複雑になる。しかし、各ユーザの満足度はより高まり、記憶容量は最適化される。
【００８０】
本発明の他の実施形態は、近接集合（proximity set）という概念を導入する。近接集合は、すでに示したように、地理的に互いに近接しているユーザの端末の記憶容量のプール化を可能にする。本実施形態は、ユーザにより一層の使い心地のよさを提供する。
【００８１】
この実施形態では、近接集合は、例えば、（ＤＳＬアクセスマルチプレクサ（ＤＳＬＡＭ）とも呼ばれる）ディジタル加入者線アクセスマルチプレクサ又は分配器などによって構成することができ、ＶＯＤサーバと、インターネットアクセス及び／又はビデオオンデマンドアクセスのためにこのＤＳＬＡＭに接続された事業者又は提供者のすべてのクライアントとを含むことができる。
【００８２】
よって、本発明によれば、近接集合の一部を構成するユーザの集団が形成され、これらのユーザ間の物理的距離は短い。したがって、これらのユーザ間で利用できる通信速度（flow rate）及び帯域幅はより大きくなる。
【００８３】
近接集合は、前述の一般的なアーキテクチャ（要求管理サーバ及び記録処理サーバ）の全部又は一部を統合することもできる。そのような場合には、例えば、ある近接集合の記録を他の近接集合において複製するなどのために、各近接集合内で管理される記録処理データを監視する、記録管理のための中央エンティティを実装することができる。
【００８４】
次に図２を参照して、本発明による要求管理サーバの簡略化したアーキテクチャについて説明する。
【００８５】
このアーキテクチャは、メモリ２１と、コンピュータプログラム（又はアプリケーション）２２を実行するマイクロプロセッサを備えた処理ユニット２０とを含む。処理ユニット２０は、ネットワーク入力インターフェースモジュール２３を介して入力側で以下を受信する。
・ユーザの端末からの要求２４ａ
・記録処理サーバからの記録に関するデータ２４ｂ
【００８６】
この情報は、マイクロプロセッサにより、プログラム２２の命令に従って、端末からの要求を承認又は否認し（２６ａ）、記録処理サーバへコマンドを送る（２６ｂ）ために処理される。
【００８７】
このデータは、ネットワーク出力インターフェースモジュール２５を介してこのデータを担当する装置へ送られる。
【００８８】
図３を参照して、本発明による要求管理サーバの簡略化したアーキテクチャを説明する。
【００８９】
このアーキテクチャは、メモリ３１と、コンピュータプログラム（又はアプリケーション）３２を実行するマイクロプロセッサを備えた処理ユニット３０とを含む。処理ユニット３０は、ネットワーク入力インターフェースモジュール３３を介して入力側で以下を受け取る。
・要求管理サーバからのコマンド３４ａ
・フィードバック制御される端末からの記録に関するデータ３４ｂ
【００９０】
この情報は、マイクロプロセッサにより、プログラム３２の命令に従って、
・要求管理サーバからの要求を承認又は否認し（３６ａ）、
・フィードバック制御される端末へコマンドを送信する（３６ｂ）
ために処理される。
【００９１】
このデータは、ネットワーク出力インターフェースモジュール３５を介してこのデータを担当する装置へ送られる。
【図１】
2010519668.tif 000003
【図２】
2010519668.tif 000004
【図３】
2010519668.tif 000005
【手続補正書】
【提出日】平成21年10月22日(2009.10.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
要求側装置が記録処理要求を作成するステップと、
通信ネットワークを通して前記要求側装置に接続された、前記要求側装置とは異なる少なくとも１つの装置へ記録処理を分散させるステップと
を含む、一組のデータの記録方法。
【請求項２】
記録処理データを記憶するために利用可能な、前記要求側装置の記憶容量を表す情報を取得して、利用可能な容量に関する情報を送信するステップと、
前記利用可能な容量に関する情報に応じて、前記ネットワークに接続された少なくとも１つの記憶装置を特定し、前記記録処理データの記憶処理の少なくとも一部を行うステップと
を含む請求項１に記載の記録方法。
【請求項３】
前記少なくとも１つの記憶装置を特定する前記ステップは、中央の記録処理サーバにより実行されるものである、請求項２に記載の記録方法。
【請求項４】
前記特定するステップは、
前記記録処理データを記憶するために必要な容量と、前記要求側装置において利用可能な容量に関する前記情報が表す容量との差分から得られる容量を計算するステップと、
得られた容量に応じて、前記記録処理データの少なくとも一部を記憶することのできる少なくとも１つの装置を、複数の装置の中から探索するステップと
を含むものである、請求項２又は３に記載の記録方法。
【請求項５】
記録処理要求を管理するサーバへ記録処理要求を送信するステップと、
決定された少なくとも１つの処理パラメータに基づいて、前記管理するサーバが前記記録処理要求を処理するステップと、
前記記録処理要求を表す少なくとも１つの情報を前記記録処理サーバへ送信するステップと
をさらに含む請求項１から４のいずれか一項に記載の記録方法。
【請求項６】
決定された少なくとも１つの処理パラメータが、前記通信ネットワーク内の前記複数の装置における記録処理データの冗長度を表す情報である、請求項５に記載の記録方法。
【請求項７】
決定された少なくとも１つの処理パラメータが、前記通信ネットワーク内の前記複数の装置における記録処理データの最大保存期間を表す情報である、請求項６に記載の記録方法。
【請求項８】
通信ネットワーク内で互いに接続された少なくとも２つの装置にわたって分散される、視聴覚番組を表す一組のデータであって、各装置は、利用可能な記憶リソースを有し、記録処理の一部を実行するものである、一組のデータ。
【請求項９】
ある通信ネットワークからダウンロードすることのできる、及び／又はコンピュータが読み取り可能な媒体上に記憶された、及び／又はマイクロプロセッサが実行することのできるコンピュータプログラム製品であって、請求項１から６のいずれか一項に記載の記録方法をコンピュータに実行させるプログラムコード命令を含むコンピュータプログラム製品。
【請求項１０】
少なくとも１つのディジタルストリームを受信するために通信ネットワークに接続する手段と、前記ディジタルストリームの少なくとも一部を記憶する手段とを備えた少なくとも１つのディジタルストリームを受信する装置であって、
前記ディジタルストリームの少なくとも一部の記録処理を、前記ネットワークへ接続された少なくとも１つの他の利用可能な装置において行うための記録処理要求を作成する手段を備える装置。
【請求項１１】
前記通信ネットワークを通して別の装置が送信したディジタルストリームの少なくとも一部を受信すると、前記記憶する手段において利用可能な記憶容量を表す情報を決定する手段と、
前記情報を前記別の装置へ送信する手段と
を備える請求項１０に記載の装置。
【国際調査報告】
2010519668.tif 000006
2010519668.tif 000007
2010519668.tif 000008
2010519668.tif 000009
2010519668.tif 000010
2010519668.tif 000011