説明

マルチメディアストリームの分散化された記録方法、装置及びコンピュータプログラム製品

本発明は、一組のデータの分散化した記録方法に関するものである。本発明の方法は、要求側装置が記録処理要求を送信するステップと、通信ネットワークを通して要求側装置に接続された、要求側装置とは異なる少なくとも1つの装置に記録を分散させるステップとを含む。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば個人向けマルチメディアストリームによって送られるデータなどの一組のデータの記録の分野に関する。
【背景技術】
【0002】
従来、ビデオストリームやオーディオストリームといったマルチメディアストリームの記録は、主にローカルで行われている。これは、1つ以上のこのようなストリームを記録しようとするユーザが、記録可能な装置を所有していなければならないことを意味する。このような装置としては、例えば、ビデオテープレコーダ、DVD(ディジタル多用途ディスク)型ディスクレコーダ、またはハードディスクドライブレコーダが挙げられる。
【0003】
xDSL(ディジタル加入者線)型ネットワーク、有線ネットワーク、WiFi(無線ローカルエリアネットワーク構築のための規格を特定する無線接続性)型無線ネットワーク、又はDVB(ディジタル映像放送)規格に基づくネットワークを使用したテレビ番組放送の出現により、新しい番組記録の方法、特にネットワークにおける番組記録が可能となっている。
【0004】
ネットワーク内での番組の記録、特に映像番組や音声番組の記録が登場してきたのは、このような高速ネットワークを使ったこのような番組の放送が大幅に増えたためである。これらの番組は事業者を通して加入者に放送される。番組の受信を可能とするために、事業者は、STB、すなわちセットトップボックスとも呼ばれるディジタル端末を加入者へ提供する。この端末は、加入者が通信ネットワークを通して番組に対応するディジタルストリームを受信し、これらのストリームを圧縮解除し、例えばテレビ受像機やコンピュータ画面や音声レンダリング装置などのための装置に提供するために加入者により使用される。
【0005】
また事業者は、これらのディジタルストリームを事業者のネットワーク内で記録させることによる、新たなディジタルストリームの記録の方法も提案している。よって、放送を記録しようとする加入者は、必ずしも、自由に使える個人用記録装置を持つ必要はない。この加入者は、ネットワークを介してストリームの記録を指示することができ、事業者は事業者のネットワーク内でこの記録に必要なリソースを割り振るタスクを引き受ける。また事業者は、システマティックなもの又はほぼシステマティックなものとしてストリームの記録を行う。よって、記録するつもりのなかった番組を見ようとする加入者であっても、事業者のネットワークによってその番組を見ることができ、事業者に応じて長さの異なる期間にわたりその番組を見ることができる。つまり、事業者は、「ビデオオンデマンド」型のサービスを提供する。
【0006】
このような記録方法は、一般に、NPVR(Network Personal Video Recording)という名称のグループに分類される。
【0007】
この原理は、1つ以上の記録コマンドを中央記録処理サーバに送り、記録処理サーバが記録すべきストリームを特定し、これらのストリームをネットワーク内の専用の記憶スペースに保存するというものである。
【0008】
よって、NPVR型の記録方法は、特定のアプローチを利用して加入者にサービスを提供するものであるとともに、原則的には、事業者の投資が一度に低減できるようにするものである。というのは、加入者の自宅に特別なディジタル端末を設置する必要がなく、同時に記憶コストもプールできるからである。よって理論的には、複数の顧客が同じ送信をプログラムすると、この送信は事業者により1回だけ記録されることになる。
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかし、この従来技術の1つの欠点は、事業者が記録すべきストリームの管理が相対的に複雑になることである。よって、加入者が記録するつもりではなかった放送が持続性を持つように、事業者は、すべてのチャンネルを永続的に記録し、後で視聴又は記録される放送だけを保存するように消去を実行する。
【0010】
この従来技術の別の欠点は、相当な大きさになり、プールすることのできない帯域幅の使用に関連するものである。実際、事業者は、要求に応じて記録されたストリームを再放送する。したがって、記録されたストリームの放送は、ユニキャスト(ポイントツーポイント形式)で、すなわち加入者に対して直接的に行われる。
【0011】
さらに、加入者は完璧なレンダリング品質を要求する。これに応じて、事業者は、可能な限り顧客の近くに事業者のサーバを複製し、その記憶容量を大幅に増加させる必要がある。ビデオオンデマンドサーバの価格は非常に高いため、インフラストラクチャのコストは、いっそう増加する。
【課題を解決するための手段】
【0012】
本発明は、一組のデータを記録する独自の方法によって、従来技術の欠点を有しない解決策を提供するものである。
【0013】
本発明の方法は、要求側装置が記録処理要求を作成するステップと、通信ネットワークを通して前記要求側装置に接続された、前記要求側装置とは異なる少なくとも1つの装置へ記録処理を分散させるステップとを含む。
【0014】
よって、本発明の記録方法は、実際に記録を保存する装置であるとは限らない装置が記録処理要求を作成することを可能とする。一組のデータの物理的な記録は、記録処理要求が作成された装置とは別の複数の装置へ分散される。したがって本発明の方法は、ローカルの装置が提供する可能性のみを考慮した従来技術とは異なり、記録を行うためにネットワーク内の装置を考慮する際に使用することができる。
【0015】
本発明の一実施形態によれば、上記方法は、記録処理データを記憶するために利用可能な、前記要求側装置の記憶容量を表す情報を取得して、利用可能な容量に関する情報を送信するステップと、前記利用可能な容量に関する情報に応じて、前記ネットワークに接続された少なくとも1つの記憶装置を特定し、記録処理データの記憶処理の少なくとも一部を行うステップとを含む。
【0016】
よって、本発明による記録方法は、記録処理データを記憶するために必要な容量(すなわち、各装置が記憶のために提供できる物理的に可能な容量)を考慮して、記録処理データのための1つ以上の記憶場所を決定することを可能にする。「一組のデータの記録」という用語は、この一組のデータを後で使用する目的で保存したものを意味するものである。かかる記録は、後で見ることができるような、記憶物、すなわち物理的な保存でなければならない。したがって、本発明は、従来技術とは異なり、記憶場所を決定するためにネットワーク内の各装置(通信端末、ルータ、サーバ)における利用可能な記憶容量を考慮することを可能にする。
【0017】
よって、本発明の方法は、例えば、十分な容量のない装置などに対して、記録処理データを記憶したもののうちの全部又は一部をネットワーク内の他の装置へ転送できる可能性を提供する。この種の記憶容量の分散化によりコストがプール化される。言い換えると本発明は、記録処理を要求する装置が、要求した記録処理データを保存するために、ネットワーク内の他の装置の記憶容量を利用することを可能とする。
【0018】
本発明の一態様によれば、上記記録処理要求は、少なくとも、上記要求側装置の識別子を表す情報と、記録の開始時点を表す情報と、記録の終了の時点を表す情報と、上記一組のデータに対応する少なくとも1つのディジタルストリームの識別子を表す情報とからなるグループに属する少なくとも1つのパラメータを含む。
【0019】
よって、記録を行おうとするネットワーク内の装置は、そのような装置(例えば識別子などの形式)と、一組のデータに関する情報(例えば特定の視聴覚番組などの形式)との間のリンクを作成することを可能にする情報を提供する。次いで、記録処理要求は、これらのパラメータを提供することにより、分散した記憶容量を効率よく使用できるように記録を管理することを可能にする。
【0020】
本発明の一実施形態によれば、少なくとも1つの記憶装置を特定する上記ステップは、中央の記録処理サーバ内で実行される。
【0021】
よって本発明は、記憶装置の決定を集中化するために使用される。かかる1つの実施形態では、この集中化により、装置内の記憶容量のプール化に関連する課題を解決できる。実際、ネットワーク上の記録の従来技術によれば、記録処理はビデオオンデマンドサーバ上で行われる。かかるサーバは、この用途に利用可能な記憶容量の特性、すなわち巨大な容量を有する。したがって、従来技術は記憶サーバの集中的な特定を必要としない。しかし、本発明のこの実施形態では、この記憶容量は、必ずしもその大きさの記憶容量が利用できるとは限らない複数の記憶装置へ分散される。したがって、この実施形態では、記憶装置を決定する処理を集中化して処理をより簡単にすることができる。
【0022】
本発明の一態様によれば、前記特定するステップは、前記記録処理データを記憶するために必要な容量と、前記要求側装置において利用可能な容量に関する前記情報が表す容量との差分から得られる容量を計算するステップと、得られた容量に応じて、前記記録処理データの少なくとも一部を記憶することのできる少なくとも1つの装置を、複数の装置の中から探索するステップとを含む。
【0023】
よって本発明は、少なくとも1つの記憶装置を、その利用可能な記憶容量に応じて選択することにより、ネットワーク内で行われる記録処理データの保存を分散(delinearize)させることを可能にする。ネットワーク内の装置が有する利用可能な記憶容量は、これらの装置が要求側装置へ送ることができ、これらの情報を提供するデータベースの問い合わせによって決定できる。したがって、選択された記憶装置は、記録処理データの全部又は一部の記憶を実行する命令を受け取る。例えば、第1の装置は、1時間などの長さを有するその記録処理データの第1の期間を記憶し、第2の装置は、0.5時間などの長さを有するその記録処理データの第2の期間を保存する。よって記憶容量が大幅に合理化される。また、この記録処理の分散という側面を、ユーザからの記録処理要求の考慮と組み合わせることもできる。例えば、2人のユーザが異なる時刻に同じ番組の記録処理を要求している場合には、ユーザの装置の記憶容量においてはそのユーザが要求した部分の記録処理を優先させ、同時に他のユーザのためにその番組全体を保存することもできる。
【0024】
一実施形態によれば、上記方法は、記録処理要求を管理するサーバへ前記記録処理要求を送信するステップと、決定された少なくとも1つの処理パラメータに基づいて、前記管理するサーバが前記記録処理要求を処理するステップと、前記記録処理要求を表す少なくとも1つの情報を前記記録処理サーバへ送信するステップとを含む。
【0025】
よって本発明は、記録処理を管理するサーバにおいて、通信ネットワークを構成する異なる装置によって送信されたデータを集中化するために使用される。この集中化は、記憶装置の決定の効率を上げる処理パラメータに応じて記録処理要求を一様に処理するために行われる。
【0026】
本発明の一態様によれば、決定された少なくとも1つの処理パラメータは、上記通信ネットワーク内の複数の装置における記録処理データの冗長度を表す情報である。
【0027】
よって、冗長度以下で記録処理データが有効に記憶される閾値を定義するために使用される、フィードバック制御パラメータともいう冗長パラメータに基づいて、記録処理データを管理することができる。実際、通信ネットワーク内の記憶装置における誤動作を軽減するためには、1つの記録処理データを複数回にわたって記憶することが必要になる場合もある。その場合、これらの複数の記憶処理は、この冗長パラメータによって制御される。本発明の一実施形態では、この冗長パラメータの値を1とすることができる。この場合、複数の記憶装置内には記録処理データの1つのコピーだけが保持される。
【0028】
本発明の一態様によれば、決定された少なくとも1つの処理パラメータは、上記通信ネットワーク内の複数の装置における記録処理データの最大保存期間を表す情報である。
【0029】
また、本発明の方法は、記録処理データの保存期間を管理するために使用することもできる。実際、装置は、その装置自体の記憶容量内に少なくとも全体としては保持されない記録処理を要求するのであるから、この記録処理データをそれ以上保存できない時点を決定する必要がある。かかる制約条件は、異なる装置の記憶容量の適切な使用を保証するために必要であることが分かる。
【0030】
また本発明は、視聴覚番組を表す一組のデータにも関連するものである。
【0031】
本発明によれば、かかる一組のデータは、それぞれが利用可能な記憶リソースを有し、それぞれが上記記録処理データの一部を保持する、通信ネットワーク内で互いに接続された少なくとも2つの装置へ分散される。
【0032】
よって、この種の一組のデータは、記憶リソースの使用を最適化すると同時に、一組のデータの永続性の保証も行う。
【0033】
本発明の別の実施形態は、通信ネットワークからダウンロードすることのできる、及び/又はコンピュータ読み取り可能な媒体上に保存された、及び/又はマイクロプロセッサが実行することのできるコンピュータプログラム製品に関連する。
【0034】
本発明の別の実施形態では、かかるコンピュータプログラム製品は、前述の記録方法を実行するためのプログラムコード命令を含む。
【0035】
本発明の他の特徴及び利点について、単なる説明のための非限定的な例によって与えられる以下の好ましい実施形態の説明と、添付の図面を参照して説明する。
【図面の簡単な説明】
【0036】
【図1】本発明の記録方法を実施するためのシステムの一般的なアーキテクチャを示すブロック図である。
【図2】本発明による要求管理サーバの簡略化したアーキテクチャを示す図である。
【図3】本発明による記録処理サーバの簡略化したアーキテクチャを示す図である。
【発明を実施するための形態】
【0037】
したがって、本発明は、共有型及び分散型(delinearized)の視聴覚番組の記録を提案するものである。このような記録は、例えば、ローカルでのディジタル記録、及び事業者やインターネットサービス提供者などがユーザへ提供する通信ネットワーク上の記録と組み合わせて定義される。
【0038】
よって、この種の記録を組み合わせれば、VOD(ビデオオンデマンド)ネットワークリソースを不必要に独占すること、ならびに記録の実記憶(real storage)が全てのセットトップボックス上及び全てのVODサーバ上に分散されることを防止できる。また本発明は、異なる人(例えば近接したユニット内に位置する人など)が行った記録を取り出すための記録の共有も提案する。
【0039】
また本発明は、だれも自発的には、あるいはその時点では、その記録を要求していない視聴覚番組を記録するために、STB(セットトップボックス)の記録処理の実行を集中的に行うことも提案する。
【0040】
したがって、本発明の原理は、ネットワークにおける異なる主体の間でのリソースの共有を利用して、各ユーザの記録のための記憶容量をプールするものである。
【0041】
よって、ネットワークインフラストラクチャの提供者は、利用可能なSTBを有するユーザにより提供される記録の可能性を増加させるというスケールメリットを得ることができる。実際、すでに述べたように、ユーザの記録容量には限界があることが非常に多く、事業者は、ネットワーク記録(NVPR)によっては、ユーザに無制限な記憶容量を提供することはできない。したがって本発明は、ユーザの記憶リソースをプールして、各ユーザの総記憶容量と、このユーザが、(見落としなどのために)プログラムしていない記録を見る可能性との両方を増加させることを提案する。
【0042】
したがって、ネットワーク上の特別なエンティティ(記録処理サーバとも呼ばれる)が、要求されていない記録の保存などを行わせることができる。すなわち、記録処理サーバは、後で分散的に(delinearized)アクセスするために、いく人かのユーザのSTBと、記録処理サーバ固有の記憶リソース(専用ハードディスクドライブ)の両方にある一定数のチャンネルを絶えず記録する。したがって、本発明のこの実施形態では、記録処理サーバは、STBのハードディスクドライブに対する完全なフィードバック制御を確立することができる。よって、1つ以上のSTBを放送の記録処理のために使用することができる。
【0043】
また本発明は、ユーザが、中央ビデオオンデマンドサーバの提供するレンダリング品質より高いレンダリング品質を得ることも可能にする。実際、本発明の1つの特定の実施形態では、近接集合(proximity set)が定義される。この近接集合は、事業者又は提供者のネットワークに接続され、地理的に近接したネットワークを介して記録のためのサービスに加入しているユーザからなる。
【0044】
以下、本発明を実施するいくつかの形態を説明する。しかし、本発明がこれらの特定の実施形態に限定されないことは明らかである。特に、提示されるアーキテクチャは例示のためのものに過ぎず、本発明の一般的な概念は、当然ながら、ネットワーク上における記録処理データの分散化というものである。
【0045】
この実施形態では、ユーザが作成した記録処理要求の管理に寄与する要求管理エンティティを稼働させる技術的アーキテクチャに関連して、本発明の記録方法の実施を説明する。また、このアーキテクチャは、各ユーザの異なる記録処理データの保存の管理全般を担う記録処理サーバも稼働させるものである。
【0046】
したがって、要求管理サーバは、各端末と、要求された放送と、保存場所(端末又はネットワーク)とのリファレンスを含むデータベースを用いて、記録処理要求の管理を行う。記録処理サーバは、要求管理サーバの要求によりネットワークに映像コンテンツを保存する。
【0047】
したがって、この実施形態では、記録処理は2段階で行われる。第1段階では、各ユーザが、記録処理要求を処理する要求管理サーバへ自己の記録処理要求を行う。第2段階では、ユーザのパラメータ、ユーザのディジタル端末及び要求管理サーバが行った決定に応じて、記録処理サーバがユーザの要求した記録処理データの効率的な保存を指示することができる。
【0048】
図1を用いて、この実施形態を簡単に説明する。
【0049】
端末(住宅用ゲートウェイやSTB型端末など)100は、事業者又はアクセスプロバイダのネットワーク101に接続されている。この端末は、ネットワークから(マルチキャスト又はユニキャスト)ディジタルストリームを受け取る。また、この端末100は、要求管理サーバ103にも接続されており、要求管理サーバ103へ要求(記録処理要求など)を送り(符号1002)、次いで要求管理サーバ103から要求を受け取る(1003)。
【0050】
要求管理サーバ103は、事業者ネットワークによって記録処理サーバ104に接続されている。記録処理サーバ104へ記録処理データの保存を求める要求を送り(1004)、記録処理サーバ104からこれらの要求に対する応答を受け取る(1005)。ネットワークにより、あるユーザへ記録処理データを提供(render)する場合には、記録処理サーバ104は、端末100へ映像ストリーム(例えば、1ユーザだけを対象とする場合にはユニキャストなど)を提供する(1006)。ユーザが記録処理データを取り出す場合には、記録処理サーバ104は、それに対応するストリーム又はストリームの一部を端末100から受信する。
【0051】
この実施形態において、要求管理サーバ103は、ユーザが要求した番組の記録処理を管理するデータベース1007を備えている。このデータベースにおいて、要求管理サーバ103は、記録処理要求ごとに、記録処理のリファレンス(チャンネル番号、開始時刻、終了時刻など)をユーザのディジタル端末の一意の識別子へ関連付ける。
【0052】
実際、この実施形態では、ユーザのディジタル端末は、ハードディスクドライブなどの独自の記憶容量を備えていてもよい。当然ながら、この実施形態は実施の一例に過ぎない。この点に関して、要求管理サーバは、例えば、パーソナルコンピュータ又は個人用ストレージサーバなどの他の周辺装置を用いた、ユーザの通信ネットワーク内で利用可能な記憶リソースなどといった、ユーザのあらゆる記憶リソースの使用を想定する必要がある。
【0053】
したがって、要求管理サーバ103は、このデータベース1007からユーザの記録処理の恒久的な情報を得ることができる。
【0054】
この実施形態では、様々な主体と関連づけのやり方との関係を区別する必要がある。
【0055】
ユーザが端末に対してコマンドとして作成する記録処理要求の管理について、この実施形態では、以下の2つの場合が考えられる。
場合1: ユーザの端末100のディスクドライブ上に十分な空き容量がある。この場合、保存はローカルに行われる。記録処理の終了時に、端末100はサーバ103に対して記録処理が終了したことを通知する。記録処理が(例えば異常などの後で)適切に行われなかった場合には、端末100は異常メッセージによってサーバ103へ知らせる。
場合2: ユーザのディスクドライブが満杯であるか、又はユーザのディスク上に十分なリソースがない。要求管理サーバ103は、記録処理要求及び端末のリファレンスを記憶し、その要求を記録処理サーバ104へ送る。
【0056】
いずれの場合も、記録処理要求は、例えば以下のようなユーザのプログラミングのパラメータを含む。
・即時の記憶の場合には、開始時刻及び記録する時間
・予約設定された記録処理の場合には、記録処理の開始及び終了の日時
・論理記録の場合には、例えば、番組ガイドなどから得られた視聴覚番組の識別子
【0057】
当然ながら、本発明の他の実施形態では、記録処理時に、場合1から場合2へ移行することもありうる。つまり、そのハードディスクドライブ上に空き容量がある端末100が視聴覚番組の記録をローカルに開始した場合に、この容量全体がまだ完了していない記録処理データによって使い果たされたときには、端末100は要求管理サーバ103へネットワーク上での記録処理の継続を求めることができる。
【0058】
ユーザの端末のハードディスクドライブ上に十分な容量があるときには、読み取り時に帯域幅を不必要に使用するのを防ぐために、ユーザ端末のハードディスク上で記録処理が行われる。その際、ネットワーク上に記録するためにユーザの端末の少なくとも一部のフィードバック制御を行う一実施形態においては、このローカルな記録処理により、結果的に記録処理サーバ104が記録処理のための場所を確保する必要はなく、端末(STBなど)に対するフィードバック制御は不要である。
【0059】
言い換えると、ユーザの端末に対するフィードバック制御の管理は、ユーザ自身の記録処理要求に応じて動的に行われる。よって、ある視聴覚番組がすでに他の場所でいくつか記録されている場合には、端末上でこの番組の記録処理を指示することにより端末のフィードバック制御を確立する必要はない。
【0060】
しかし、端末に技術的な問題が発生した場合には、これを解消するために、冗長な記録s処理を実行する必要がある。よって、冗長閾値Nが決定され、これはフィードバック制御パラメータとも呼ばれ、所与の記録処理データへのアクセスを保証するのに使用される。
【0061】
記録処理データの読み取りに関しては、以下の3つの場合を考慮する必要がある。
場合1: 記録処理はユーザの端末上で行われている。したがって、読み取りは端末から直接的に行われる。この端末は、この端末が利用できないことを要求管理サーバへ通知する。読み取りが終了すると、端末は、この端末が利用可能になったことを要求管理サーバへ通知する。記録処理データ自体の読み取りの開始は、要求管理サーバによって行われ、要求管理サーバが端末へ読み取りコマンドを出す。
場合2: 記録処理データは記録処理サーバに要求される。したがって、端末は、要求管理サーバへコンテンツ読み取り要求を行う。それに応じて、要求管理サーバは、
・ストリーミングサーバのアドレス、例えば、記録処理サーバの記録処理データを放送するための「ユニキャスト」アドレスと、
・コンテンツのパラメータ(識別子、開始時刻、終了時刻など)
といった、コンテンツを読み取るのに必要な情報を端末へ送る。
場合3: ユーザは、ネットワーク内で記録処理データを探す。実際に、本発明は、記憶リソースと記録処理データそのものの両方のプール化を可能にするものであると考えることができる。したがって、ユーザは、自分では予約設定するつもりのなかった記録処理データを探索することも全く可能である。その場合、端末は、端末の探索パラメータを要求管理サーバへ送り、要求管理サーバは、記録データベース1007内で探索を行う。探索要求のパラメータは例えば、
・記録処理の開始と終了の日時、及び/又は
・要求されている放送の識別子
などとすることができる。
【0062】
場合2及び場合3では、記録処理サーバは、1つ以上の端末又は記録処理サーバ自体の記憶リソースに問い合わせてコンテンツを組み立て直すよう、要求されていない記録処理のドライバへ要求する。これらの端末はストリームを送るか、又はコンテンツをダウンロードし、そのコンテンツがユーザの端末へリダイレクトされる。この機構は、アップリンク(端末からサーバまで)の帯域幅に左右されるため、中間サーバをシステムに介在させて高品質のフルストリームを再構築することができる。
【0063】
記録処理データを消去する処理に関して、本発明は、本明細書で説明する実施形態において、ユーザのリソースを最大限までプール化しようとするものである。よって、どんな消去処理の前にも、消去される記録処理データの後のアクセスの条件についてのチェックが行われる。
【0064】
以下の2つの場合を区別する必要がある。
場合1: コンテンツはユーザの端末のディスクドライブ上にある。消去を許可する際に、要求管理サーバ103は、そのコンテンツがネットワーク内にあるかどうかを記録処理サーバ104へ問い合わせるか、又はそのコンテンツが他の端末においてまだ利用できるかどうかをチェックする。そのコンテンツがその端末において利用できず、N個の端末上でのみ利用できる場合には、要求管理サーバ103は、関与する端末のうちの1つにおけるコンテンツの取得を要求しなければならない。
場合2: コンテンツは、(例えば別の端末上や記録処理サーバ内などの)ネットワーク内に記録されている。その場合、要求管理サーバは、そのデータベース1007内のこの記録に対してそのユーザを消去するだけにとどめる。
【0065】
場合1において、Nはフィードバック制御パラメータである。これは、ネットワークにおいて記録処理データが利用できることを保証するために用いられる値である。言い換えると、複数のユーザによって記録されている視聴覚番組について、関与するすべてのユーザがその番組の消去を要求しない限り、又はやはりパラメータ化可能な一定期間が経過しない限り、いつでも利用できるようにするためにこのパラメータが用いられる。
【0066】
本明細書で説明する実施形態において、予約設定の変更が可能なのは、まだ開始していない記録処理についてだけである。端末に十分な容量がある場合と、端末に十分な容量がない場合とを区別する必要がある。
場合1: ユーザの端末のディスク上に十分な空きがある。端末100は、変更を求める要求を要求管理サーバ103へ出し、要求管理サーバ103は要求を受け入れ、そのデータベース1007内での変更を考慮する。
場合2: ユーザの端末のディスクは満杯である。要求管理サーバ103は、そのデータベース1007内での変更を考慮し、記録処理サーバへ変更を考慮するよう求める。
【0067】
本明細書で説明する実施形態において、ユーザは、事前にその記録処理が要求されていないコンテンツを探索する可能性がある。かかる探索では最初に、端末100は、そのコンテンツが利用できるかどうかを、優先して記録処理サーバ上で、次いで各端末上で確認するための探索を行うために、探索コマンドをデータサーバ103へ送る。コンテンツが端末においてのみ利用できる場合、そのコンテンツは記録処理サーバ上で取得されなければならない。
【0068】
後者の場合、コンテンツが取得された後に、要求管理サーバ103はその応答として、
・ストリーミングサーバのアドレス
・コンテンツのパラメータ(識別子、開始時刻、終了時刻など)
といった、そのコンテンツを読み取るのに必要な情報を端末100へ送る。
【0069】
端末内で利用できるコンテンツを取得するために、要求管理サーバ103は最初に、コンテンツを端末100へロードする許可を求める。かかる許可は、例えば、その端末100が利用できない場合、あるいはユーザがこのコンテンツを公開したくない場合には拒否することもできる。第2の段階において、要求管理サーバにダウンロードの許可が与えられると、要求管理サーバは、コンテンツをダウンロードする記録処理サーバへその許可を転送する。
【0070】
ネットワーク上での記録処理の間(例えば、ユーザの端末のハードディスクドライブ上に十分な容量がなくなったときなどに)、要求管理サーバ103は、そのデータベース1007における端末からの記録処理要求を考慮した後に、その視聴覚番組の記録処理を記録処理サーバ104へ求める。記録処理サーバ104は、その記憶容量内で利用可能な場所をチェックする。容量が十分にある場合には、記録処理サーバ104は、記録処理要求の承諾を要求管理サーバ103へ通知すると同時に、この記録処理の記憶識別子を与える。
【0071】
ユーザからの消去要求が要求管理サーバ103へ送られると、要求管理サーバ103は、その要求を考慮して、その記録処理データがネットワークにおいて記憶されている場合には、この消去要求を記録処理サーバ104へ送る。記録処理サーバ104は、必要なチェックを行った後に記録処理データを消去し、その旨を要求管理サーバ103へ知らせる。
【0072】
記録処理データを有する第1のユーザ側のダウンロードの承諾を受け取った場合に、その記録処理データを第1のユーザの端末から記録処理サーバ104へダウンロードする必要があるとき(例えば、消去要求や第2のユーザが行った探索の後など)には、記録処理サーバ104は、ダウンロードを実行して、その記録処理データを記録処理サーバ104の記憶容量内に保存する。コンテンツのロードが終了すると、記録処理サーバ104は、コンテンツが取得されたことを要求管理サーバ103に知らせ、コンテンツに一意の識別子を付与する。
【0073】
本発明の一実施形態では、クライアントの端末のフィードバック制御と一緒に、各端末における補完的な記録処理データの分散を作成することができる。かかる分散化は、例えば、数個の端末上に記録処理データを分散させることにより、記憶容量の利用を最適化するなどのために行われる。
【0074】
よって、例えば、記録処理サーバは、視聴覚番組の記録処理を数個の端末へ分散させることを決定することができる。例えば、この実施形態では、ある端末は番組の最初の20分間の記録処理(及び保存処理)を担当し、別の端末は次の20分間を記録し、以下同様にして、その視聴覚番組の最後まで記録する。よって、本発明のこの実施形態によって記録された視聴覚番組を記録処理サーバへ転送する間に使用される帯域幅を低減することができる。実際、各端末は、短時間に対応する限られた量のデータだけを送信すればよい。したがって、各端末は、ごくわずかな時間にわたり実行するのみであり、ユーザのインターネット接続の利用が過度に制限されることはない。
【0075】
本発明の少なくとも1つの実施形態では、記録処理データのセグメント化を行う。実際、視聴覚番組は、とりわけ複数のディジタルストリームで構成されている。これらのディジタルストリームに対して、セグメント化を実行することもできる。その場合、記録処理データは、一組のセグメントからなり、各セグメントは、あるストリーム、開始時刻及び終了時刻に対応する。したがって、あるセグメントは、記録処理データを構成するその他のセグメントとは独立して記憶することのできるその記録処理データの一部を表す。
【0076】
よって、記録処理データのプール化の割合はさらに増加する。実際、この実施形態は、ユーザによって異なるパラメータを用いて視聴覚番組を記録できることを考慮するものである。
【0077】
従来技術においては、1つの視聴覚番組Pについて、ユーザU1は、20時00分に開始して22時00分に終了する記録を「予約設定」し、別のユーザU2は19時55分に開始し22時05分に終了する記録を「予約設定」する。その場合、要求管理サーバは、以下のどちらを選ぶかという問題に直面する。
・(ユーザU2が不満を持つ危険を冒して)ユーザU2のパラメータを使用せず、ユーザU1の記録のただ1つの記憶だけを記録処理サーバに求めることにする。ここで、この記録処理データは、ユーザU1にも、ユーザU2にも、他の潜在的なユーザにも使用されうる。
・不必要にデータが重複するリスクを承知の上で、すべてのユーザのすべてのパラメータを使用する。この場合、ユーザU1とユーザU2は満足するが、その視聴覚番組は重複するタイムスロットを用いて2回記録されることになる。
【0078】
この実施形態では、例えば5分単位のセグメントを用いて記録処理データをセグメント化すれば、リソースのプール化が可能になる。よって、前述の例では、ユーザU2は、その端末のハードディスクドライブにおける空き容量に応じて、19時55分〜20時00分のタイムスロットに対応するセグメントと、22時00分〜22時05分のタイムスロットに対応するセグメントとの両方をローカルで持つことができるはずであり、残りのセグメントは、各ユーザの端末のフィードバック制御があるか又はない状態で、ネットワークにおいて記憶される。
【0079】
言い換えると、記録処理は、各ユーザ自身の予約設定要求を満たすと同時に、不要な情報の重複を防ぐために、各ユーザの端末へ分散される。端末のフィードバック制御の場合には、フィードバック制御パラメータNが使用される。したがって、このパラメータは、各セグメントのフィードバック制御を可能にする。この結果、要求管理サーバでは、各ユーザ要求の管理がより複雑になる。しかし、各ユーザの満足度はより高まり、記憶容量は最適化される。
【0080】
本発明の他の実施形態は、近接集合(proximity set)という概念を導入する。近接集合は、すでに示したように、地理的に互いに近接しているユーザの端末の記憶容量のプール化を可能にする。本実施形態は、ユーザにより一層の使い心地のよさを提供する。
【0081】
この実施形態では、近接集合は、例えば、(DSLアクセスマルチプレクサ(DSLAM)とも呼ばれる)ディジタル加入者線アクセスマルチプレクサ又は分配器などによって構成することができ、VODサーバと、インターネットアクセス及び/又はビデオオンデマンドアクセスのためにこのDSLAMに接続された事業者又は提供者のすべてのクライアントとを含むことができる。
【0082】
よって、本発明によれば、近接集合の一部を構成するユーザの集団が形成され、これらのユーザ間の物理的距離は短い。したがって、これらのユーザ間で利用できる通信速度(flow rate)及び帯域幅はより大きくなる。
【0083】
近接集合は、前述の一般的なアーキテクチャ(要求管理サーバ及び記録処理サーバ)の全部又は一部を統合することもできる。そのような場合には、例えば、ある近接集合の記録を他の近接集合において複製するなどのために、各近接集合内で管理される記録処理データを監視する、記録管理のための中央エンティティを実装することができる。
【0084】
次に図2を参照して、本発明による要求管理サーバの簡略化したアーキテクチャについて説明する。
【0085】
このアーキテクチャは、メモリ21と、コンピュータプログラム(又はアプリケーション)22を実行するマイクロプロセッサを備えた処理ユニット20とを含む。処理ユニット20は、ネットワーク入力インターフェースモジュール23を介して入力側で以下を受信する。
・ユーザの端末からの要求24a
・記録処理サーバからの記録に関するデータ24b
【0086】
この情報は、マイクロプロセッサにより、プログラム22の命令に従って、端末からの要求を承認又は否認し(26a)、記録処理サーバへコマンドを送る(26b)ために処理される。
【0087】
このデータは、ネットワーク出力インターフェースモジュール25を介してこのデータを担当する装置へ送られる。
【0088】
図3を参照して、本発明による要求管理サーバの簡略化したアーキテクチャを説明する。
【0089】
このアーキテクチャは、メモリ31と、コンピュータプログラム(又はアプリケーション)32を実行するマイクロプロセッサを備えた処理ユニット30とを含む。処理ユニット30は、ネットワーク入力インターフェースモジュール33を介して入力側で以下を受け取る。
・要求管理サーバからのコマンド34a
・フィードバック制御される端末からの記録に関するデータ34b
【0090】
この情報は、マイクロプロセッサにより、プログラム32の命令に従って、
・要求管理サーバからの要求を承認又は否認し(36a)、
・フィードバック制御される端末へコマンドを送信する(36b)
ために処理される。
【0091】
このデータは、ネットワーク出力インターフェースモジュール35を介してこのデータを担当する装置へ送られる。

【特許請求の範囲】
【請求項1】
要求側装置が記録処理要求を作成するステップと、
通信ネットワークを通して前記要求側装置に接続された、前記要求側装置とは異なる少なくとも1つの装置へ記録処理を分散させるステップと
を含む、一組のデータの記録方法。
【請求項2】
記録処理データを記憶するために利用可能な、前記要求側装置の記憶容量を表す情報を取得して、利用可能な容量に関する情報を送信するステップと、
前記利用可能な容量に関する情報に応じて、前記ネットワークに接続された少なくとも1つの記憶装置を特定し、前記記録処理データの記憶処理の少なくとも一部を行うステップと
を含む請求項1に記載の記録方法。
【請求項3】
前記少なくとも1つの記憶装置を特定する前記ステップは、中央の記録処理サーバにより実行されるものである、請求項2に記載の記録方法。
【請求項4】
前記特定するステップは、
前記記録処理データを記憶するために必要な容量と、前記要求側装置において利用可能な容量に関する前記情報が表す容量との差分から得られる容量を計算するステップと、
得られた容量に応じて、前記記録処理データの少なくとも一部を記憶することのできる少なくとも1つの装置を、複数の装置の中から探索するステップと
を含むものである、請求項2又は3に記載の記録方法。
【請求項5】
記録処理要求を管理するサーバへ記録処理要求を送信するステップと、
決定された少なくとも1つの処理パラメータに基づいて、前記管理するサーバが前記記録処理要求を処理するステップと、
前記記録処理要求を表す少なくとも1つの情報を前記記録処理サーバへ送信するステップと
をさらに含む請求項1から4のいずれか一項に記載の記録方法。
【請求項6】
決定された少なくとも1つの処理パラメータが、前記通信ネットワーク内の前記複数の装置における記録処理データの冗長度を表す情報である、請求項5に記載の記録方法。
【請求項7】
決定された少なくとも1つの処理パラメータが、前記通信ネットワーク内の前記複数の装置における記録処理データの最大保存期間を表す情報である、請求項6に記載の記録方法。
【請求項8】
通信ネットワーク内で互いに接続された少なくとも2つの装置にわたって分散される、視聴覚番組を表す一組のデータであって、各装置は、利用可能な記憶リソースを有し、記録処理の一部を実行するものである、一組のデータ。
【請求項9】
ある通信ネットワークからダウンロードすることのできる、及び/又はコンピュータが読み取り可能な媒体上に記憶された、及び/又はマイクロプロセッサが実行することのできるコンピュータプログラム製品であって、請求項1から6のいずれか一項に記載の記録方法をコンピュータに実行させるプログラムコード命令を含むコンピュータプログラム製品。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate


【公表番号】特表2010−519668(P2010−519668A)
【公表日】平成22年6月3日(2010.6.3)
【国際特許分類】
【出願番号】特願2009−550744(P2009−550744)
【出願日】平成20年2月22日(2008.2.22)
【国際出願番号】PCT/FR2008/050303
【国際公開番号】WO2008/113948
【国際公開日】平成20年9月25日(2008.9.25)
【出願人】(591034154)フランス・テレコム (290)
【Fターム(参考)】