JP2003297015A

JP2003297015A - コンテンツ保存端末及びこのコンテンツ保存端末にコンテンツを配信する配信サーバ装置

Info

Publication number: JP2003297015A
Application number: JP2002097755A
Authority: JP
Inventors: Yasuki Arai; 康記新井
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2002-03-29
Filing date: 2002-03-29
Publication date: 2003-10-17

Abstract

(57)【要約】【課題】コンテンツ保存時に保存領域が不足す
ることが判明したとき、特定のメディアの記録を省くこ
とでその他のメディアの記録時間を最大化できるコンテ
ンツ保存端末及び配信サーバ装置を提供するにある。【解決手段】音声及び映像のコンテンツが所定のフ
ォーマットで多重化されたマルチメディア・データがコ
ンテンツ保存端末で受信される。マルチメディア・デー
タの先頭には、ヘッダが位置し、このヘッダには、メデ
ィアの種別及びこの種別に対応した各データのサイズ並
びに配列情報が記述されている。各データサイズからマ
ルチメディア・データの総データ・サイズが求められ、
データ保存部の空き容量と比較され、保存ができない場
合には、削除されるべきコンテンツの種別の指定が求め
られる。指定されたメディアデータは、ヘッダのデータ
配列情報を参照して消去される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、コンテンツ保存
端末及びこのコンテンツ保存端末にコンテンツを配信す
る配信サーバ装置に係り、特に、マルチメディア・コン
テンツを特定フォーマットに変換して、これを多重化し
て送信するコンテンツサービスを提供するコンテンツ・
サーバ及び放送・通信網を介して接続される利用者端末
からなるシステムに関する。

【０００２】

【従来の技術】従来、文字情報データ、静止画及び動画
等の画像データ及び音楽データ等のマルチメディア・コ
ンテンツを配信するシステムは、一般的には、図１に示
すようなネットワークを構成している。この図１に示さ
れるマルチメディアを配信するコンテンツ・サーバ２１
は、放送網或いは通信網２２を経由してパーソナルコン
ピュータ、或いは、基地局２４を介して携帯電話等の利
用者端末２３に接続され、利用者からの要求によってコ
ンテンツを配信することができる。

【０００３】図２には、このコンテンツ・サーバ２１の
回路構成が示されている。コンテンツ・サーバ２１は、
マルチメディア・コンテンツ、例えば、ビデオデータＶ
及びオーディデータＡが貯蔵されている記憶部３１及び
マルチメディア・コンテンツ、例えば、オーディオ・デ
ータ及びビデオデータを多重化して所定のフォーマット
に変換する多重フォーマット作成部３２を具備してい
る。また、コンテンツ・サーバ２１は、この多重化され
所定のフォーマットに変換された送信用コンテンツ、或
いは、外部から供給される多重化され所定のフォーマッ
トに変換された送信用コンテンツを格納する多重フォー
マット・コンテンツ記憶部３６を備えている。このコン
テンツ・サーバ２１は、更に、図１に示す外部のネット
ワークに送信用コンテンツを送信する送信部３４、外部
のネットワークからコンテンツを受信する受信部３５及
びフォーマット作成部３２、記憶部３１、３６、受信部
３５及び送信部３４を制御する制御部３３を具備してい
る。尚、図２において、実線で示す矢印は、データ線を
示し、破線で示す矢印は、制御線を示している。

【０００４】図３には、利用者端末２３の回路構成がブ
ロック図で示されている。利用者端末２３は、コンテン
ツ・データを受信する受信部４１、送信要求等の要求或
いは音声及び文字データ等を送信する送信部４２、受信
したデータファイルの内容を表示用データとするブラウ
ザ部４３及び所定のフォーマットで多重化されたコンテ
ンツ・データをビデオデータ及び音声データ等に分離す
る多重フォーマット分離部４４を具備している。また、
音声データをデコードする音声メディア・デコード部４
５、ビデオデータをデコードする映像メディア・デコー
ド部４６、ユーザ、即ち、利用者からの指示を入力する
ユーザ・インターフェース部４７、受信された多重フォ
ーマット・コンテンツを保存する多重フォーマット・コ
ンテンツ保存部４８、デコードされた音声データを出力
する音声出力部４９、デコードされたビデオデータを出
力する映像出力部５０及び図３に示す各部を制御する制
御部５１を更に具備している。

【０００５】このようなシステムにおいては、利用者端
末２３において、ユーザによってユーザ・インターフェ
ース部４７でコンテンツ送信要求が入力され、ユーザ・
インターフェース部４７、ブラウザ部４３及び送信部４
２介してコンテンツ・サーバ２１がアクセスされる。こ
のアクセスに応答して、コンテンツ・サーバ２１は、制
御部３３の制御下で受信部３５を介してデータ送信要求
を受け、このデータ送信要求に応じてマルチメディア・
コンテンツを利用者端末２３に送信している。ここで、
コンテンツ・サーバ２１から配信されるマルチメディア
・コンテンツは、コンテンツ記憶部３１から取り出さ
れ、複数メディアのコンテンツが多重フォーマット作成
部３２に取り込まれる。このマルチメディア・コンテン
ツは、多重フォーマット作成部３２において、多重化さ
れた所定のフォーマットに変換され、送信部３４から放
送網或いは通信網２２に送り出される。尚、多重フォー
マット記憶部３６は、予め多重フォーマットでメディア
・コンテンツが取り込まれ、これを保存している。従っ
て、多重フォーマット記憶部３６からのマルチメディア
・コンテンツは、多重フォーマット作成部３２のコンテ
ンツ多重機能をバイパスして送信部３４から直接に放送
網或いは通信網２２に送信することができる。

【０００６】送信部３４は、放送・通信網２２からアク
セス仕様（プロトコル）に合わせて、多重フォーマット
・コンテンツを放送・通信網上に送り出している。利用
者端末２３では、受信部４１にて多重フォーマット・コ
ンテンツが受信され、多重フォーマット・デコード部４
４により多重フォーマットから個別のメディア情報が取
り出される。また、利用者の選択的要求に応じて、受信
部４１で受信した多重フォーマット・コンテンツは、多
重フォーマット・コンテンツ保存部４８に保存すること
もできる。取り出された個別のメディアは、音声メディ
ア・デコード部４５及び映像メディア・デコード部４６
にてデコードされ、音声出力部４９及び映像出力部５０
へ送られ、再生される。

【０００７】

【発明が解決しようとする課題】図３に示す利用者端末
２３では、多重フォーマット・コンテンツを受信するに
際し、利用者の選択により多重フォーマット・コンテン
ツ保存部４８にコンテンツを保存可能である。しかしな
がら、多重フォーマット・コンテンツ保存部４８へのコ
ンテンツの保存途中で多重フォーマット・コンテンツ保
存部４８の記憶残量が枯渇した場合には、受信した全コ
ンテンツを保存できず、コンテンツの途中で保存が終了
する問題がある。特に、従来のシステムでは、利用者が
予め音声、或いは、映像等、多重配信されるメディアの
中から優先的に保存するコンテンツを選択することはで
きないため、例えば、必要に応じて音声だけを長時間、
記録したくてもできない問題がある。

【０００８】従来、マルチメディア・コンテンツを録画
する装置として放送等の番組を録画する番組録画装置が
あり、このような番組録画装置が特開２００１−１４８
１５５及び特開２００１−１６０２６４に開示されてい
る。このような番組録画装置では、必要に応じて録画し
た番組を消去する方式が採用されている。しかしなが
ら、この番組録画装置は、番組単位で録画を消去し、録
画の為の記憶領域を確保し、新たに番組を録画するもの
であり、利用者の要望に応じて、空き記憶領域に選択的
に必要なコンテンツのみを記憶することができない。即
ち、利用者端末の記憶部の空き領域が十分でない場合
に、利用者が興味を有するコンテンツのみを記憶できな
い問題がある。

【０００９】この発明は、上述したような事情に鑑みな
されたものであって、コンテンツ保存時に保存領域が不
足することが判明したとき、特定のメディアの記録を省
くことでその他のメディアの記録時間を最大化できるコ
ンテンツ保存端末及びこのコンテンツ保存端末にコンテ
ンツを配信する配信サーバ装置を提供するにある。

【００１０】

【課題を解決するための手段】この発明によれば、複数
のメディア・コンテンツが所定のフォーマットで多重化
されているマルチメディア・データの送信を要求する為
の送信部と、この送信部からの要求に応じて送信された
マルチメディア・データを受信する為の受信部と、この
マルチメディア・データを保存する為のデータ保存部
と、前記マルチメディア・データ中の消去されるべきメ
ディア・コンテンツの種別を指定する為の指定部と、前
記データ保存部の空き容量をモニタしてマルチメディア
・データを保存するに十分な空き容量がない場合に前記
指定された種別のメディア・コンテンツ・データを消去
する為の制御部と、を具備することを特徴とするコンテ
ンツ保存端末が提供される。

【００１１】また、この発明によれば、複数のメディア
・コンテンツが所定のフォーマットで多重化され、その
先頭にメディアの種別及びこの種別に対応した各データ
のサイズ並びに配列情報が記述されているヘッダを有す
るマルチメディア・データの送信を要求する為の送信部
と、この送信部からの要求に応じて送信されたマルチメ
ディア・データを受信する為の受信部と、このマルチメ
ディア・データを保存する為のデータ保存部と、前記マ
ルチメディア・データ中の消去されるべきメディア・コ
ンテンツの種別を指定する為の指定部と、前記データ保
存部の空き容量をモニタすると共に前記ヘッダの各デー
タのサイズから前記マルチメディア・データの総データ
・サイズを求め、両者の比較から前記マルチメディア・
データを保存するに十分な空き容量が前記データ保存部
にない場合に、前記ヘッダのデータ配列情報を参照して
指定された種別のメディア・コンテンツ・データを消去
する為の制御部と、を具備することを特徴とするコンテ
ンツ保存端末が提供される。

【００１２】更に、この発明によれば、データを保存可
能な容量と共に送信要求を受ける為の受信部と、この送
信要求に応じて複数のメディア・コンテンツが所定のフ
ォーマットで多重化されているマルチメディア・データ
の送信する為の送信部と、前記マルチメディア・データ
中のメディア・コンテンツの種別を予め指定する為の指
定部と、前記マルチメディア・データのサイズが前記デ
ータ保存容量より大きい際に指定された種別のメディア
・コンテンツ・データのみを前記送信部から送信させる
為の制御部と、を具備するコンテンツ保存端末にコンテ
ンツを配信する配信サーバ装置が提供される。

【００１３】

【発明の実施の形態】以下、図面を参照して、この発明
の実施の形態に係るコンテンツ保存端末及び配信サーバ
装置を説明する。

【００１４】図４は、この発明のコンテンツ保存端末及
び配信サーバ装置が適用されるネットワーク・システム
を概略的に示すブロック図である。図４に示されるよう
に、このシステムは、パーソナルコンピュータ、或い
は、携帯電話等の利用者端末６１、無線回線を利用する
利用者端末６１、例えば、携帯電話をネットワーク網に
接続する為の基地局６２及びネットワーク中の電話回線
に含まれる交換装置６３を具備している。ここで、ネッ
トワーク網は、ネットワーク、通信・放送網、外部ネッ
トワーク等で称せられるもの含み、単に網或いは外部網
と称せられる場合があることを明記する。また、このシ
ステムは、利用者からの要求によってコンテンツを配信
するサーバ装置６４、コンテンツの媒介路としてのイン
ターネット６５から構成されている。尚、コンテンツ・
サーバ装置６４は、インターネット６５に限らず、電話
回線或いはケーブル等の回線を介してコンテンツを配信
することができる。また、利用者端末６１が無線回線を
利用する利用者端末６１、例えば、携帯電話である場合
には、基地局６２が利用者端末６１との間に無線回線を
設定する。このようなシステムでは、利用者端末６１か
らコンテンツの配信要求があると、利用者の要求に従い
サーバ装置６４は、マルチメディア・コンテンツを送信
し、インターネット６５等のコンテンツの媒介路を介し
てマルチメディア・コンテンツが利用者端末６１にダウ
ンロードされる。

【００１５】図５には、図４に示したサーバ装置６４の
詳細が示されている。この図５に示すように、サーバ装
置６４は、マルチメディア・コンテンツを送信する送信
部７１、利用者端末６１から配信要求等の要求を受信す
る受信部７２、サーバ装置６４内の各部を制御する制御
部７３を具備している。また、このサーバ装置６４は、
多重化されたマルチメディア・コンテンツを格納する多
重コンテンツ記憶部７４、音声メディア・コンテンツを
格納する音声メディア記憶部７５、映像メディア（静止
画或いは動画データ）を格納する映像メディア記憶部７
６及び音声メディア記憶部７５及び映像メディア記憶部
７６からのコンテンツを多重化して所定のフォーマット
のファイルを作成する多重ファイル作成部７７から構成
されている。この多重ファイル作成部７７は、図６に示
されるように送信されるべきファイルの先頭にファイル
情報を含むヘッダを常に位置させるフォーマットに変換
するヘッダ先出し機能部７８を含む。従って、このヘッ
ダ先出し機能部７８によって変換されたコンテント・フ
ァイルが送信される際には、図６に示すように常にヘッ
ダからコンテンツファイルが送信される。尚、図５にお
いて、実線で示す矢印は、データ線を示し、破線で示す
矢印は、制御線を示している。

【００１６】図５に示したサーバ装置６４では、他のサ
ーバ装置６４からインターネット等の外部ネットワーク
から、或いは、直接に、コンテンツが受信部７２で受信
され、制御部７３を介して記憶部７４，７５，７６に格
納される。即ち、コンテンツが音声メディア・コンテン
ツであれば、この音声メディア・コンテンツが音声メデ
ィア記憶部７５に格納される。また、コンテンツが映像
メディア（静止画或いは動画データ）であれば、この映
像メディアが映像メディア記憶部７６に格納される。同
様に、コンテンツがマルチメディア・コンテンツであっ
て、多重コンテンツ記憶部７４に格納されたフォーマッ
トと同一のフォーマットを有するマルチメディア・コン
テンツであれば、このマルチメディア・コンテンツは、
多重コンテンツ記憶部７４に格納される。受信部７２で
受信されたマルチメディア・コンテンツが多重コンテン
ツ記憶部７４に格納されたフォーマットと異なるフォー
マットを有するマルチメディア・コンテンツである場合
には、このマルチメディア・コンテンツは、制御部７３
に含まれる多重ファイル分離部において、音声及び映像
メディア・コンテンツに分離される。分離された音声メ
ディア・コンテンツは、音声メディア記憶部７５に格納
され、また、分離された映像メディア・コンテンツは、
映像メディア記憶部７６に格納される。

【００１７】図５に示したサーバ装置６４では、利用者
端末６１からコンテンツの配信要求が受信部７２を介し
て制御部７３に入力されると、制御部７３は、この配信
要求に従って、配信要求があったコンテンツを記憶部７
４，７５，７６から多重ファイル作成部７７に出力す
る。ここで、多重コンテンツ記憶部７４に格納されたマ
ルチメディア・コンテンツが配信要求された場合には、
そのマルチメディア・コンテンツは、予め所定フォーマ
ットを有するように多重化されていることから、多重フ
ァイル作成部７７で多重ファイルに変換されることな
く、送信部７１に送られ、この送信部７１から利用者端
末６１に向けて送信される。マルチメディア・コンテン
ツの配信の際には、各ファイルでは、ヘッダ先出し機能
部７８によって図６に示すようなファイルに変換され、
常にヘッダが始めに送信され、これに続いてメディアデ
ータが送信される。配信要求があったコンテンツが音声
メディア・コンテンツ、或いは、映像メディア・コンテ
ンツのいずれかであれば、このコンテンツは、多重ファ
イル作成部７７で所定フォーマットに変換されて所定の
フォーマットを有するファイルとして送信部７１に送ら
れ、この所定のフォーマットのファイルが送信部７１か
ら利用者端末６１に向けて送信される。この送信に際し
ても、同様にヘッダ先出し機能部７８によって、常に始
めにヘッダが送信され、これに続いてメディアデータが
送信されるようにファイルが図６に示すようにフォーマ
ットされる。配信要求があったコンテンツが音声メディ
ア・コンテンツ及び映像メディア・コンテンツであれ
ば、この音声メディア・コンテンツ及び映像メディア・
コンテンツは、多重ファイル作成部７７で多重化され、
また、所定フォーマットに変換されて多重化ファイルと
して送信部７１に送られ、この多重化ファイルが送信部
７１から利用者端末６１に向けて送信される。ここで、
多重ファイル作成部７７は、既に説明したように映像メ
ディア記憶部７６からの映像メディアデータ及び音声メ
ディア記憶部７５からの音声メディアデータを送信時に
多重ファイルに作成するばかりでなく、多重コンテンツ
記憶部７４に作成した多重ファイルを保存し、また、多
重コンテンツ記憶部７４に保存してある多重ファイルを
そのまま、或いは、その内容を一部修正して送信部７１
に送出する機能を有している。

【００１８】図７は、図４に示した利用者端末６１の回
路構成を詳細に示すブロック図である。図６に示される
利用者端末６１は、送信要求等の要求、或いは、音声及
び文字データ等を送信する送信部８１、コンテンツ・デ
ータ等のデータを受信する受信部８２を具備している。
また、この利用者端末６１は、受信部８２を介して受信
されたマルチメディア・コンテンツ・データを各コンテ
ンツ・データに分離する多重ファイル分離部８３及び受
信部８２を介して受信されたマルチメディア・コンテン
ツ・データを保存する多重ファイル保存部９３を具備し
ている。更に、この利用者端末６１は、分離された音声
コンテンツ・データをデコードする音声デコーダ８４及
び同様に分離された映像コンテンツ・データをデコード
する映像デコーダ８５を備え、更にまた、デコードされ
た音声信号を再生するスピーカ８６、デコードされた映
像信号を再生する表示器８７、受信データファイルの内
容を表示用データとするブラウザ部８８、ユーザ、即
ち、利用者からの指示を入力する入力部８９及びこの利
用者端末６１内の各部を制御する制御部９０を具備して
いる。

【００１９】このシステムにおいては、利用者端末６１
の入力部８９からメニュー情報等の配信情報の送信要求
がユーザによって入力され、この送信要求が制御部９０
及び送信部９１介してコンテンツ・サーバ６４に送信さ
れ、コンテンツ・サーバ６４がアクセスされる。このア
クセスに応じて、コンテンツ・サーバ６４は、制御部７
３の制御下において、受信部７２を介するデータ送信要
求に応じてメニュー情報等の配信情報を利用者端末６１
に送信する。従って、利用者端末６１では、受信部８２
を介してメニュー情報等の配信情報がブラウザ部８８に
入力され、表示器８７にメニュー情報等の配信情報が整
形表示される。この表示部８７の表示を利用して利用者
は、希望するコンテンツをメニューから検索し、取得す
るマルチメディア・コンテンツを選択することができ
る。

【００２０】この表示部８７を参照して、入力部９８力
される。このこのコンテンツの送信要求及び選択情報
は、制御部９０を経由して送信部８１からネットワーク
に送り出される。このコンテンツの送信要求及び選択情
報がサーバ装置６４に届くと、サーバ装置６４の送信部
７１からメニュー情報等で利用者が選択したマルチメデ
ィア・コンテンツが制御部７３の制御下で利用者端末６
１に送信される。ここで、コンテンツ・サーバ６４から
配信されるマルチメディア・コンテンツは、コンテンツ
記憶部７５，７６から取り出された複数メディアのコン
テンツが多重ファイル作成部７７にて多重化されるとと
もに所定のフォーマットに変換され、ヘッダを先頭に多
重化されたマルチメディア・コンテンツが送信部７１を
介して放送網、或いは、通信網６５に送り出される。
尚、多重フォーマット記憶部７４には、予め多重フォー
マットでメディア・コンテンツが取り込まれて保存され
ている。従って、多重フォーマット記憶部７４からのマ
ルチメディア・コンテンツは、多重ファイル作成部７７
を介さずに送信部７１から直接に放送網或いは通信網６
５に送信される。

【００２１】コンテンツ・サーバ６４の送信部７１は、
放送・通信網６５からアクセス仕様（プロトコル）に合
わせて、多重フォーマット・コンテンツを放送・通信網
上に送り出している。利用者端末６１では、受信部８２
にて多重フォーマット・コンテンツが受信され、多重フ
ァイル分離部８３により多重フォーマット・ファイルか
ら個別のメディア情報が取り出される。即ち、多重ファ
イル分離部８３では、図６に示すような各コンテンツフ
ァイルの先頭に配置されたヘッダが分離され、このヘッ
ダが多重ファイル保存部９３に格納されるとともに後に
述べるようにマルチメディア・ファイルの保存に先立っ
て後に述べるようにヘッダ中のメディアサイズ等の特定
情報が制御部９０に与えられる。制御部９０は、多重フ
ァイル保存部９３の空き容量をモニタし、このマルチメ
ディア・ファイルを多重ファイル保存部９３へ保存する
ことが可能であると判断すると、マルチメディア・ファ
イルが多重ファイル保存部９３に格納される。このマル
チメディア・ファイルの保存の手順については、後に詳
述する。

【００２２】このように利用者の選択的要求に応じて、
受信部８２で受信した多重フォーマット・コンテンツ
は、多重ファイル保存部９３に保存するができる。多重
ファイル分離部８３から、或いは、多重ファイル保存部
９３から取り出された個別のメディアは、音声メディア
・デコード部８４及び映像メディア・デコード部８５に
てデコードされ、スピーカ６１及び表示器８７へ送ら
れ、再生される。

【００２３】多重ファイル作成部７７でフォーマット可
能な多重ファイル・フォーマットの一例として、ＩＳＯ
／ＩＥＣ,１４４９６−１,ＭＰＥＧ−４システム・ファ
イル・フォーマット（単に、ＭＰ４と称する。）があ
る。このファイル構造が図８に示されている。このＭＰ
ＥＧ−４システム・ファイル・フォーマットでは、この
フォーマットで規定されたマルチメディア用のファイル
・フォーマットであって、映像或いは音声等の複数のメ
ディアを多重化して１つのファイルとして保存すること
ができるフォーマットとして知られている。

【００２４】この図８に示されるファイル・フォーマッ
トでは、１つのＭＰ４ファイルは、第１階層のヘッダと
してファイル情報が記載されるｍｏｏｖ（Movie Atom）
及び音声データ及び映像データを含むマルチメディア・
データが格納されているｍｄａｔ（Media Data Atom)か
ら構成されている。このＭＰ４ファイルには、付加的
に、第１階層の空き領域としてのｆｒｅｅ並びにｓｋｉ
ｐ及びユーザが定義する書き込みを許すｕｄｔａ (User
Data Atom)が設けられている。

【００２５】尚、ＭＰ４ファイルでは、一般にａｔｏｍ
と称される単位を元にデータを分類し、管理さされてい
る。このａｔｏｍは、上位層から下位層に至る階層構造
を取ることができ、その内部に更に下位層のａｔｏｍを
含むものを「コンテナａｔｏｍ」と呼ぶ。ここで説明す
るａｔｏｍは、ｂｏｘと称される場合があることを注意
されたい。

【００２６】また、ヘッダとしてのｍｏｏｖ（Movie At
om）には、第２階層にあるＭＰ４ファイルの作成時刻及
びＭＰ４ファイルのコンテンツ長等のヘッダ情報が記述
されているｍｖｈｄ (Movie Header Atom)、オブジェク
ト、即ち、再生対象に関する情報が記述されているｉｏ
ｄｓ(Object descriptor Atom)及び多重化されているメ
ディア情報に関する各種パラメータが記述されているｔ
ｒａｋ (Track Atom)を含んでいる。このｔｒａｋ (Tra
ck Atom)は、多重化されているメディアが多数あれば、
そのメディアの数だけ用意される。例えば、音声と映像
とが多重化されたコンテンツにあっては、音声メディア
ｔｒａｋ及び映像メディアのｔｒａｋが用意され、その
音声用のｔｒａｋに音声メディアのパラメータが格納さ
れ、映像用のｔｒａｋに映像メディアのパラメータが格
納される。

【００２７】図４に示されるようにｔｒａｋ (Track At
om)は、第３階層にあるトラックの作成時刻及びトラッ
クＩＤ（識別子）と称されるトラックを識別するための
一連の番号が格納されているｔｋｈｄ (Track Header A
tom)、トラックに関して記述されたｔｒｅｆ (Track Re
ference Atom)、編集情報に関してのｅｄｔｓ (EditAto
m)及びメディアの情報に関して記述されたｍｄｉａ (Me
dia Atom)を含んでいる。edts (Edit Atom)は、第４階
層に編集リスト情報が記述されたelst (Edit List Ato
m)を含み、ｍｄｉａ (Media Atom)は、第４階層にこの
メディアトラックのタイムスケール等の情報が格納され
るｍｄｈｄ(Media Header)、ヘッダを参照する情報が記
述されたｈｄｌｒ(Handler Reference Atom)及びメディ
アに関する情報が格納されているｍｉｎｆ(Media infor
mation)を含んでいる。ｍｉｎｆ(Media information)
は、更に第５階層にトラックに格納されているメディア
が映像であることを示すｖｍｈｄ(Video Media Heade
r)、或いは、トラックに格納されているメディアが音声
であることを示すｓｍｈｄ (Sound Media Header Ato
m)、ヒント・メディアのヘッダ情報が記述されたｈｍｈ
ｄ(Hint Media Header Atom)、メディアがビデオ或いは
音声以外のＭＰＥＧ−４ストリームである場合に、ＭＰ
ＥＧ−４のヘッダ情報が記述された＜ｍｐｅｇ＞(MPEG-
4 Media Atoms) 、メディア情報が記述されたｍｉｎｆ
(Media Information Atom)及びサンプルに関しての情報
が記述されたｓｔｂｌ(Sample Table Atom)を含んでい
る。ｖｍｈｄ(Video Media Header Atom)及びｓｍｈｄ
(Sound Media Header Atom)は、トラックに格納されて
いるメディア、即ち、音声か映像化の種別に応じて択一
的に記載される。更にまた、ｄｉｎｆ(Data Informatio
n Atom)は、データを参照する情報が記述されたｄｒｅ
ｆ(Data Reference Atom)を含み、また、ｓｔｂｌ(Samp
le Table Atom)は、各サンプルの時間間隔が設定されて
いるｓｔｔｓ(Decoding timeto Sample Atom) 、サンプ
ルに対するデコード時間が記述されたｃｔｔｓ (Compos
ition Time to Sample Atom)、サンプルの同期情報が記
述されたｓｔｓｓ（Sync Sample Atom）、コーディック
の種別やデコードに必要となる各種情報が設定されてい
るｓｔｓｄ(Sample Description Atom) 、トラック中の
サンプルの総数（sample_count）及び各サンプルのデー
タサイズ（entry_size）が設定されているｓｔｓｚ(Sam
ple Size Atom)、チャンク内のサンプル数(sample_per_
chunk)及びサンプルのインデックス(sample_descriptio
n_index)が記述されたｓｔｓｃ（Sample to Chunk Ato
m）、チャンクに関するファイルの先頭からのオフセッ
ト位置情報(chunk_offset)が記述されるｓｔｃｏ (Chun
k Offset Atom)、同期情報が記述されたｓｔｓｈ(Shado
w Sync Sample Atom)及びｓｔｄｐ(Degradation Priori
ty Atom)を含んでいる。ｓｔｓｄ(Sample Description
Atom)は、必要に応じて複数個設定することができる。

【００２８】ここで、サンプル（即ち、ｓａｍｐｌｅ）
とは、映像や音声の実際のメディアデータをある大きさ
に区切った単位を称し、メディアデータは、このｓａｍ
ｐｌｅを基に管理されている。チャンク（即ち、ｃｈｕ
ｎｋ）は、１又は複数のｓａｍｐｌｅが連接されている
ものを称し、ファイル先頭からのｃｈｕｎｋの位置や当
該ｃｈｕｎｋにいくつのｓａｍｐｌｅが含まれているか
と言った、データ領域の内部構造に関する情報は、上述
したようにｍｏｏｖコンテナａｔｏｍの下位階層に記述
される。また、既に説明したように実際のメディアデー
タは、ｍｄａｔａｔｏｍに配置され、音声や映像といっ
たメディア毎の情報管理にｔｒａｋというａｔｏｍが割
り当てられている。このようにＭＰ４ファイルは、ｍｏ
ｏｖコンテナａｔｏｍを取得すれば、構成されるメディ
ア数、それぞれの種別、データサイズ等が判明する。

【００２９】一般にＭＰ４のａｔｏｍは、同一階層の配
置順序の規定がない。図７の第１階層においては、ｍｏ
ｏｖ、ｍｄａｔ、ｆｒｅｅ、ｓｋｉｐ、ｕｄｔａの順序
で並んでいるが、これは必ずしも規格上ファイル先頭か
らこの順番で並ばなければならないことを意味していな
い。

【００３０】この発明の実施の形態では、ファイル情報
を取得するために必ず第１階層では、ファイル情報が記
述されるｍｏｏｖがファイルの先頭に割り当てられるよ
うにファイルがフォーマットされる。即ち、サーバ装置
６４においては、多重ファイル作成部７７は、ヘッダ先
出し機能部７８を含み、このヘッダ先出し機能部７８に
よって、多重コンテンツ記憶部７４にマルチメディア・
ファイルを格納する際に各ファイルの先頭にヘッダ情報
としてのｍｏｏｖを付している。また、映像メディア記
憶部７６及び音声メディア記憶部７５からのメディアを
多重化して所定フォーマットに整える際にそのファイル
の先頭に同様にヘッダ情報としてのｍｏｏｖを付してい
る。

【００３１】この図８に示すファイルのヘッダから全て
のマルチメディア・データ・サイズ及び個々のマルチメ
ディア・データのサイズを獲得する手順について図９を
参照して説明する。

【００３２】図７に示す利用者端末６１では、マルチメ
ディア・ファイルが受信されてマルチメディア・データ
のサイズの計算が開始される。（ステップＳ１０）多重
ファイル分離部８３において受信したマルチメディア・
ファイルからファイル先頭のヘッダ情報としてのｍｏｏ
ｖがステップＳ１２に示すように多重ファイル保存部９
３に格納され、このｍｏｏｖ中のファイル情報が必要に
応じて制御部９０に与えられる。このｍｏｏｖ中の第２
階層にあるｔｒａｋは、メディアの数だけ用意されてい
ることから、ステップＳ１４に示すように制御部９０に
おいて、このトラックの数をカウントすることによって
メディア数が明らかとなる。また、ｍｏｏｖの第６階層
にあるｓｔｓｚ(sample size atom)からそのｔｒａｋが
記述するメディアのデータサイズが計算される。即ち、
ｓｔｓｚ(sample size atom)には、夫々３２ビットの符
号なし整数のサンプル・サイズ(sample-size)及びサン
プル・カウント(sample-count)があり、サンプル・サイ
ズが０でないときは、全てのサンプルのサイズ(entry-s
ize)は、同一とされている。従って、当該トラックのデ
ータサイズは、サンプル・サイズ(sample-size)×サン
プル・カウント(sample-count)で算出される。また、サ
ンプル・サイズ(sample-size)が０のときは、それぞれ
のサンプル毎にエントリー・サイズ(entry-size)が記述
される。従って、該当するトラックのデータサイズは、
エントリー・サイズ(entry-size)の総計（Σentry-siz
e）で求められる。更に、当該トラックのメディアの種
別に関しては、第４階層にｍｉｎｆ(Media Informatio
n)があり、このｍｉｎｆ(Media Information)に含まれ
る第４階層のｖｍｈｄ(Video Media Header)、ｓｍｈｄ
(Soundmedium Header)、ｈｍｈｄ(Hint Media Header)
から当該トラックが何れのメディアに属するかが判明す
る。即ち、ｖｍｈｄ(Video Media Header)から当該トラ
ックのメディアが映像（ビデオ）メディアであることが
判明し、ｓｍｈｄ(Soundmedium Header)から当該トラッ
クのメディアが音声（オーディオ）であることが判明
し、ｈｍｈｄ(Hint Media Header)から当該トラックの
メディアがヒント・メディアであることが判明する。更
にまた、ｓｔｓｄ(Sample Description Atom)から当該
メディアのコーディング・モード等が判明する。即ち、
ｓｔｓｄ(Sample Description Atom)にｍｐ４ｖ(Mpeg-4
Video)と記述されれば、ＭＰＥＧ４の規格に定められ
たコーディング・モードでビデオデータが符号化されて
いる旨が判明し、ｓｔｓｄ(Sample Description Atom)
にｍｐ４ａ(Mpeg-4 Audio)と記述されれば、ＭＰＥＧ４
の規格に定められたコーディング・モードで音声データ
が符号化されている旨が判明する。また、ｓｔｓｄ(Sam
ple Description Atom)にＡＭＲ(Adaptive Multi-Rate)
と記述されれば、可変伝送レートでのコーディング・モ
ードで音声データが符号化されている旨が判明する。
尚、ＡＭＲ(Adaptive Multi-Rate)は、samrと表記され
ることが、３ＧＰＰの３ＧＰＰＴＳ２６．２３４に定
められている。

【００３３】図７に示した利用者端末６１においては、
多重ファイル、即ち、マルチメディア・ファイルを受信
すると、制御部９０は、送信されるマルチメディア・フ
ァイルの全サイズを図９に従った手順で計算し、そのサ
イズと多重ファイル保存部９３の空き容量を比較する。
マルチメディア・ファイルを保存する多重ファイル保存
部９３に十分な空き容量があり、送られたマルチメディ
ア・ファイルを保存することができる場合には、そのま
まそのマルチメディア・ファイルは、多重ファイル保存
部９３に保存される。しかしながら、多重ファイル保存
部９３に十分な空き容量がなく、そのままマルチメディ
ア・ファイルを保存できない場合には、制御部９０から
は、容量枯渇メッセージがブラウザ部１０７に送られ
る。このメッセージに応答して、表示器８２には、図１
０（ａ）、或いは、図１０（ｂ）に示すような選択画面
が表示される。図１０（ａ）は、保存するメディア・ス
トリームを選択する画面であり、図示の例では、音声ス
トリームが選択されて保存される。また、図１０（ｂ）
は、削除するメディア・ストリームを選択する画面であ
り、図示の例では、音声ストリームが選択されて削除さ
れる。この表示に従って、利用者が選択画面の項目を選
択すると、その選択結果が制御部９０に与えられ、送信
されるマルチメディア・ファイルの中の保存すべきメデ
ィア・ストリームのサイズと多重ファイル保存部９３の
空き容量とが比較される。依然、メディア・ストリーム
のサイズが多重ファイル保存部９３の空き容量に比べて
大きい場合には、保存領域が不足している旨が表示され
て保存を終了する旨が表示され、保存が終了される。こ
こで、既に説明したように、ｍｉｎｆ(Media Informati
on)に含まれる第４階層のｖｍｈｄ(Video Media Heade
r)から当該トラックがビデオ（映像）でる旨が判明し、
当該トラックのサイズは、サンプル・サイズ(sample-si
ze)及びサンプル・カウント(sample-count)、或いは、
エントリー・サイズ(entry-size)から求められる。同様
にして、ｍｉｎｆ(Media Information)に含まれる第４
階層のｓｍｈｄ(Sound medium Header)から当該トラッ
クのメディアが音声（オーディオ）である旨が判明し、
当該トラックのサイズは、サンプル・サイズ(sample-si
ze)及びサンプル・カウント(sample-count)、或いは、
エントリー・サイズ(entry-size)から求められる。

【００３４】上述したようにマルチメディア・コンテン
ツの保存を終了する場合には、送信部９１を介して、コ
ンテンツ・サーバ装置６４に送信停止メッセージが送ら
れ。これによりサーバはファイル送出を停止する。ま
た、送信されるマルチメディア・コンテンツ中から所定
のメディアデータのみの保存を継続する場合、利用者端
末８３では、これまでに記録したメディアデータのうち
不要なメディアデータを消去しながら選択したメディア
データのみが保存される。

【００３５】ここで、図１１を参照してマルチメディア
・コンテンツ中からあるメディアを消去しながら所定の
メディアを保存する手順について説明する。図１０
（ａ）、或いは、図１０（ｂ）の画面が表示されてある
メディアの消去が開始される。（ステップＳ１０）この
画面でステップＳ３２に示すように消去すべきデータが
ビデオデータであるかが確認される。ビデオデータであ
る場合には、ステップＳ３４に示すようにｍｉｎｆにｖ
ｍｈｄが記述されているトラック（track）が特定され
る。この特定されたトラック（track）は、ビデオデー
タに関して記述されていることから、ステップＳ３６に
示すようにｍｄａｔ中のｓｔｃｏに記述されるチャンク
(chunk)の数及びオフセット・アドレスが獲得される。
ここで、図１２に示されるように各トラックのアドレス
は、ファイルの先頭からのオフセット・アドレスで記述
される。この実施の形態では、必ずヘッダが先頭に配置
されることから、moovの先頭からの相対的なアドレスで
記述される。ビデオチャンク(Vchunk)にあっては、通常
１つのサンプル（V sample）で構成され、複数サンプル
で構成されても良いことから、そのサイズは、サンプル
数及びそのサンプル・サイズによって決定される。従っ
て、ｓｔｓｚ（sample size atom）を参照することによ
って消去すべきデータのサイズが判明し、そのチャンク
の終了アドレスが判明する。従って、ステップＳ３８に
示すようにチャンクのオフセット・アドレス及びそのサ
イズからチャンクが消去される。図１２に示される例に
おいて、トラック１（track 1）がビデオである場合に
は、始めに第１チャンク(chunk)が消去される。次に、
ステップＳ４０に示すように当該トラックに含まれるチ
ャンクの全てが消去されたかが確認される。このステッ
プでは、ｓｔｃｏに記述されるチャンク(chunk)の数だ
け消去されたかで確認される。全て消去されていない場
合には、ステップＳ３６が実行される。即ち、図１２に
示す例では、第２のチャンクが消去される。全てのチャ
ンクが消去されて、例えば、図１２におけるトラック１
の第１、第２及び第３チャンクが消去されて処理が終了
される。（ステップＳ５２）従って、多重ファイル保存
部９３には、音声のチャンクのみが保存される。

【００３６】ステップＳ３２において、消去すべき対象
がビデオでない場合には、ステップＳ４２において、そ
の対象が音声データであるかが確認される。消去対象が
ビデオでも音声でも、ない場合には、その処理が終了さ
れる。消去対象が音声データである場合には、ステップ
Ｓ４４に示すようにｍｉｎｆにｓｍｈｄが記述されてい
るトラック（track）が特定される。この特定されたト
ラック（track）は、音声データに関して記述されてい
ることから、ステップＳ４６に示すようにｍｄａｔ中の
ｓｔｃｏに記述されるチャンク(chunk)の数及びオフセ
ット・アドレスが獲得される。音声チャンク(Ａ chunk)
にあっては、１又は複数のサンプル（Ａ sample）で構
成されることから、そのサイズは、サンプル数及びその
サンプル・サイズによって決定される。即ち、ｓｔｓｃ
（Sample to Chunk Atom）を参照することによって、各
チャンクを構成するサンプルの数が判明し、ｓｔｓｚ
（sample size atom）を参照することによってそのサン
プルのサイズが判明する。従って、消去すべきチャンク
のデータのサイズが判明し、そのチャンクの終了アドレ
スが判明する。ステップＳ４８に示すようにチャンクの
オフセット・アドレス及びそのサイズからチャンクが消
去される。図１２に示される例において、トラック２
（track 2）が音声である場合には、始めにそのトラッ
ク２（track 2）の第１チャンク(chunk)が消去される。
次に、ステップＳ５０に示すように当該トラックに含ま
れるチャンクの全てが消去されたかが確認される。この
ステップでは、ｓｔｃｏに記述されるチャンク(chunk)
の数だけ消去されたかで確認される。全て消去されてい
ない場合には、ステップＳ４６が実行される。即ち、図
１２に示す例では、トラック２の第２のチャンクが消去
される。全てのチャンクが消去されて、例えば、図１２
におけるトラック２の第１及び第２チャンクが消去され
て処理が終了される。（ステップＳ５２）従って、多重
ファイル保存部９３には、ビデオのチャンクのみが保存
される。

【００３７】図１１に示した手順は、消去しながら所定
のメディアを保存する場合として説明したが、既に多重
ファイル保存部９３にマルチメディ・ファイルが保存さ
れ、このマルチメディア・ファイルから所定のコンテン
ツ・データのみを消去する場合も同様であるので、その
説明は、省略する。

【００３８】図６に示す多重ファイル保存部９３におい
て、消去しながらメディアを保存する場合、或いは、保
存した後において、あるマルチメディア・データを消去
する場合には、多重ファイル保存部９３でデータの詰め
替えが必要とされ、また、このデータの詰め替えに伴っ
てヘッダとしてのｍｏｏｖの記述を変更する必要があ
る。このデータの詰め替え及びｍｏｏｖの記述を書き換
える手順を図１３から図１５を参照して説明する。

【００３９】図１３に示すようにマルチメディア・コン
テンツをそのまま受信して多重ファイル保存部９３に保
存すると、チャンク単位で連続して保存される。ここ
で、保存しながら、ある、メディアのコンテンツがチャ
ンク毎に消去される場合には、図１３（ｂ）に示すよう
に保存すべきチャンク(1)〜(15)に消去された空白の領
域が生じる。図１３（ａ）においては、保存すべきチャ
ンクは、縦縞で表し、消去されるべきチャンクは、横縞
で表し、また、図１３（ｂ）においては、消去された記
憶領域は、白抜きで示されている。このように多重ファ
イル保存部９３の保存領域中に保存すべきデータが飛び
飛びの状態で記録され、その間に未記録の領域がある場
合には、ファイルの利用効率が低下する。そこで、図１
４（ａ）に示すように保存されるデータ列は、図１４
（ｂ）に示すように連続して保存されるデータ列に書き
換えられる。即ち、図１４（ａ）に示す空白領域に隣接
するチャンク(1)〜(15)が移され、図１４（ｂ）に示す
ようにチャンク(1)〜(15)が連続して配置される。この
詰め替えに応じてｓｔｃｏ（Chunk Offset Atom）に記
述されるチャンクのオフセット・アドレスが書き換えら
れる。

【００４０】ここでは、あるマルチメディア・コンテン
ツが２つのメディアから構成され、そのうち一方を消去
する場合の詰め替えを例として説明する。

【００４１】ステップＳ６０に示されるようにチャンク
の詰め替えが開始されると、ステップＳ６２に示すよう
に書き出しポインダがどちらか残すトラックのオフセッ
トの最小値に設定される。ここで、最小値関数は、引数
の第1項、すなわち、トラック０のオフセット０と、引
数の第２項、すなわちトラック１のオフセット０のうち
どちらか小さい値を返す関数である。変数「サンプル
数」は０、変数「オフセット・インデックス(offset_in
dex）」は、０、変数「チャンク番号」は、０に初期設
定される。変数「オフセット・インデックス(offset_in
dex）は、０から始まり、残すトラックの最大チャンク
数まで変化する変数であり、この値は、現在当該トラッ
クの何番目のチャンクを処理しているかを示す。変数
「サンプル数」は、現在処理中のチャンクに含まれるサ
ンプル数を保持する。次に、ステップＳ６４において、
オフセット・インデックス（offset_index）がｓｔｃｏ
（Sample to Chunk Atom）に記述されるｅｎｔｒｙ＿ｃ
ｏｕｎｔより小さいかが比較される。ここで、ｓｔｃｏ
（Sample to Chunk Atom）のｅｎｔｒｙ＿ｃｏｕｎｔ
は、そのトラックにおけるチャンクの数に相当している
ことから、オフセット・インデックス（offset_index）
がそのトラック数になれば、そのトラック中のチャンク
の移し替え処理が完了したこととなる。（ステップＳ６
６）ステップＳ６４において、移し替え処理が終了して
いない場合には、ステップＳ６８において、変数「開始
書出しポインタ」に変数「書出しポインタ」の値を設定
する。変数「書出しポインタ」は、これまで書き出した
最終アドレスを記憶しているので、これに続けて書き出
すために変数「開始書出しポインタ」に値を設定する。
次に、ステップＳ７０において、ｓｔｃｏｏｆｆｓｅ
ｔ[offset_index]は、チャンクの開始アドレスの記され
たテーブル[offset (構造体stcoのメンバとして記述)」
のoffset_index番目の値という意味である。ステップＳ
６４におけるoffset_indexは、保存されるべきチャンク
のオフセット・インデックスであり、ステップS72に示
されるように読出しポインタがインクリメントされて読
出しポインタが移し替えるべきチャンク(コピーされる
べきチャンク)の先頭に達するまで移動される。読出し
ポインタが移し替えられるべきチャンクの先頭に達する
と、ステップS74に示すように当該チャンクのサンプル
数がｓｔｓｃ(Sample to Chunk Atom)から求められる。

【００４２】即ち、当該チャンクを構成するサンプル数
が決定されて読み出すべきサンプル数が定められる。ま
た、ステップＳ８２において、チャンクを移し代えた際
の新たなアドレスを特定する為に、新たなｓｔｃｏ(Chu
nk Offset Atom)のチャンク・オフセット(chunk_offse
t) テーブル[offset」のオフセット・インデックス〈of
fset_index)番目の値として、変数「書出しポイメタ」
の値を保存する。

【００４３】更に、ステップＳ７６において、当該チャ
ンクを構成する全てのサンプルを読み出したかが判断さ
れる。全てのサンプルを読み出した場合には、ステップ
Ｓ７８において、処理対象チャンク番号を示すｏｆｆｓ
ｅｔ＿ｉｎｄｅｘが１だけ増加されて次のチャンクを処
理する為に再びステップＳ６４に戻される。

【００４４】ステップＳ７６において、全てのサンプル
を読み出していない場合には、ステップＳ８０におい
て、当該チャンクのデータが読み出す為にそのチャンク
のサンプル・サイズがｓｔｓｚのｅｎｔｒｙ＿ｓｉｚｅ
から読み出される。ステップＳ８４において、当該サン
プルがそのサイズだけ読み出されたかが判断される。当
該サンプルが読み出されていない場合には、ステップＳ
８６において、データの読出し及びその読出しデータ
の書き込み、読出しポインタが更新され、また、書
出しポインタが更新されてサンプル内のデータの読出し
及び書き込みが継続される。ステップＳ８６において、
当該サンプルの読出しが終わると、ステップＳ７６にお
いて当該チャンク内に処理されていないサンプルがある
かが判断される。

【００４５】図１５に示す処理を経て保存すべきデータ
のチャンクが読み出され、新たなオフセット・アドレス
で書き込まれ、そのチャンク・オフセットが更新され
る。この処理により、多重ファイル保存領域において、
データの詰め替えが実行される。

【００４６】図１３及び図１４に示す実施の形態では、
チャンクに関しては、そのデータサイズに制約がない例
で説明しているが、予め、図１６（ａ）に示すようにあ
る基本単位のデータは、メディア間のデータの最少公倍
数に定められていることが好ましい。例えば、ある記録
単位としてのブロックが２ビデオサンプルに相当すると
共に５音声サンプルに相当する場合には、そのブロック
を単位として図１６（ｂ）に示すように２ビデオサンプ
ルと５音声サンプルとの組み合わせでmdatに配列されて
いることが好ましい。このようにあるメディア・コンテ
ンツ・データを記録する際に定まる第１の記録単位の平
均値と他のメディア・コンテンツ・データを記録する際
に定まる第２の記録単位の平均値との公倍数で定められ
る記録ブロックで複数のメディアがデータ保存部に記録
されるフォーマットであれば、片方のメディアデータ領
域を不要とするときもすでに配置した保存すべきメディ
アデータを移動することなく、消去すべきメディアデー
タが書かれていた場所に上書きすることでデータの入れ
替えが可能であり、その結果、データの移動に伴う処理
時間を短縮することができる。

【００４７】更に、図１７（ａ）及び（ｂ）に示すよう
に複数メディア（便宜上ここでは２メディア）のデータ
が互いに保存領域のはじめ及び終わりから書くようなフ
ォーマットが採用されてもよい。このようなフォーマッ
トでは、それぞれのメディアデータの書出し位置を管理
している変数が交差することで、記録データ保存領域が
不足することが判明する。ここでは、順方向に書くメデ
ィアトラックをフォワード・トラック（Forward Trac
k）と称し、逆方向から書くトラックをリバース・トラ
ック（Reverse Track）と称する。このようなフォーマ
ットでマルチメディア・データが保存される場合には、
いずれかのメディアデータを継続して保存するときは、
他のメディアデータは保存するメディアデータにより上
書きされることで消去される。ただし、両方のメディア
データも保存することができた場合、２つのメディアデ
ータの間には空白領域が残ることとなる。このようなフ
ォーマットにおいて、以下の説明において、リバース・
トラック（Reverse Track）に記録されるデータは、ネ
ガティブ・オフセット（Negative Offset）と称するア
ドレスで記録される。

【００４８】記録データを外部メモリ等の記憶媒体に出
力する際には、メモリ内容を転送する必要が生じる。こ
の際、リバース・トラック（Reverse Track）のデータ
はネガティブ・オフセット（Negative Offset）だけず
らして空白領域を残さずに出力される。また、通常デー
タの位置に変更する際はヘッダ内にあるオフセットテー
ブル内容を更新する必要があるが、この実施の形態で
は、ネガティブ・オフセット（Negative Offset）をヘ
ッダ領域に記載しておくことにより、ヘッダ領域のオフ
セットテーブル内容に手を加える必要がない。ヘッダ領
域にリバース・トラック（Reverse Track）として記録
されているメディアのＩＤ及びネガティブ・オフセット
（Negative Offset）が記載される。これにより、リバ
ース・トラック（Reverse Track）再生時にテーブルか
ら引き出される値からネガティブ・オフセット（Negati
ve Offset）分引いた位置がアクセスされる。尚、図１
７（ａ）に示すようにこのようなデータ保存方法にあっ
ても、基本単位のデータは、メディア間のデータの最少
公倍数に定められていることが好ましい。

【００４９】上述した実施の形態においては、利用者端
末６１において、多重ファイル保存部９３に十分な空き
容量がなく、そのままマルチメディア・ファイルを保存
できない場合には、表示器８２にその旨が表示されると
している。この表示に代えて、或いは、併用して、コン
テンツ・サーバ６４から利用者端末６１に送られるデー
タに制約を与えても良い。即ち、図１８に示されるよう
に利用者端末６１から予め制約条件を受信部７２で受
け、その制約条件を利用者毎に利用者端末管理部１００
に保存し、利用者端末６１からその多重ファイル保存部
９３の空き容量が知らされ、その空き容量が十分で無い
と判断した場合には、マルチメディア・ファイル中のあ
るメディアデータのみを利用者端末６１に送信するよう
にしても良い。一例としては、利用者端末６１からデー
タ送信要求と共に多重ファイル保存部９３の空き容量が
送られた際に、制御部７３は、送信要求の対象とされる
マルチメディア・ファイルと多重ファイル保存部９３の
空き容量とを比較し、十分な空き容量が多重ファイル保
存部９３に無いと判断する場合には、その利用者の制約
条件、例えば、空き容量が十分でない場合には、音声デ
ータのみの送信を希望するとの制約条件に従ってファイ
ルをその利用者端末６１に送信してもよい。

【００５０】また、図１９に示すように、コンテンツ・
サーバ６４には、利用者の意図する保存優先度及び保存
領域残量をサーバ装置の利用者端末保存優先順位管理部
１１０が設けられ、この管理部１１０にて、コンテンツ
・サーバ６４から利用者端末６１に送信されるマルチメ
ディア・データが管理されても良い。この図１９に示す
コンテンツ・サーバ６４では、利用者が希望するコンテ
ンツの送信要求を受けると、制御部７３から多重ファイ
ル作成部７７にそのコンテンツの送信要求が伝えられ
る。多重ファイル作成部ではまず、利用者に送付するた
めのヘッダ情報を作成する。このヘッダ情報は、利用者
端末保存優先順位管理部４１０に送られ、このヘッダ情
報の内容が利用者端末保存優先順位管理部４１０におい
て解析される。端末がすべて受信できると判断した場
合、そのまま送出することを多重ファイル作成部に許可
する。もし、解析の結果、端末側で全部を受信できない
ことが判明すると、利用者端末保存優先順位管理部４１
０に登録されている優先メディアの情報のみを残し、そ
れ以外のメディアを含めないで多重ファイルを作成する
ことを多重ファイル作成部に指示する。こうして利用者
端末６１にはあらかじめ保存が可能な状態でサーバ装置
６４から多重コンテンツファイルが提供される。

【００５１】上述した実施形態では、ＭＰ４の多重フォ
ーマットに係るマルチメディア・データを送信データと
して説明しているが、ＭＰ４以外の多重フォーマットに
係るマルチメディア・データにあっても、本願の発明を
適用することができる。例えば、保存中に保存領域の不
足が判明する多重フォーマットでは、全体の保存サイズ
は、保存完了まで判明しないが、保存途中でもメディア
の種類と各メディアデータがどこに格納されているか特
定できるフォーマットであれば、本願の発明を適用する
ことができる。多重ファイル保存部９３に次々にデータ
が記録されている途中であっても、空き容量がある所定
値以下となった際には、上述した実施形態と同様に所定
のメディアが保存され、他のメディアが消去されても良
い。

【００５２】このようなフォーマットの例としては、図
２０（ａ）及び（ｂ）に示されるような低ビットレート
テレビ電話で用いられているＨ．２２３多重フォーマッ
トをそのまま記録する場合が該当する。Ｈ．２２３多重
フォーマットでは、図２０（ａ）に示すようにＨ．２２
３のフレームは、フラグ（Ｆ）、ヘッダ（Ｈ）、ペイロ
ード（メディアデータ）、フラグ（Ｆ）で構成されてい
る。１フレームの終了は、次のフラグパタンを検出する
ことによって判定される。ヘッダ（Ｈ）の構造は、図２
０（ｂ）に示されるようにヘッダーエラーコントロール
（ＨＥＣ）、多重コード（ＭＣ）及びパケットマーカ
（ＰＭ）から構成されている。ヘッダーエラーコントロ
ール（ＨＥＣ）及び多重コード（ＭＣ）は、互いに一意
に決まる値を用いており、ヘッダーエラーコントロール
（ＨＥＣ）の値から多重コード（ＭＣ）値が導けないと
きは、当該パケットに伝送エラーの影響が生じているこ
とが検出される。また、パケットマーカ（ＰＭ）は、ペ
イロードデータを分割して送付したときに、受信側で元
の分割前の構造を再現する必要のあるデータを送るため
に使われるモード（フレームドモード）にて、分割の最
終が含まれることを示すときに”１”を設定して用いら
れる。多重コードＭＣは、別途送付される多重化テーブ
ルを用いることにより、ペイロード部分にどのメディア
の情報が何オクテット含まれているかが判明する。サー
バからの多重ファイルの受信時にこのフォーマットが用
いられるとき、利用者端末６４は、受信途中にメモリが
いっぱいなるまでコンテンツ保存に十分なメモリ領域が
あるかないかが判定できない。

【００５３】したがって、保存途中のある時点ではじめ
て判明し、図１０（ａ）及び図１０（ｂ）のような利用
者による選択を促すメッセージによって選択、もしくは
利用者があらかじめ登録する保存優先順位（あるいは消
去優先順位）に基づき、消去するメディアの情報を決定
し、多重化テーブルの内容を書き換えることができる。
その後、不要なデータ部分を削除し、空いた部分に後方
からフレームデータを移設する。これにより特定のメデ
ィアデータの情報を残すことができる。

【００５４】

【発明の効果】以上のように、この発明によれば、コン
テンツ保存時に保存領域が不足することが判明したと
き、特定のメディアの記録を省くことでその他のメディ
アの記録時間を最大化できるコンテンツ保存端末及び配
信サーバ装置を提供することができる。

【図面の簡単な説明】

【図１】一般的なマルチメディア・コンテンツを配信す
るネットワーク・システムを示す概略図である。

【図２】図１に示したコンテンツ・サーバの構成を概略
的に示すブロック図である。

【図３】図１に示した利用者端末の構成を概略的に示す
ブロック図である。

【図４】この発明のコンテンツ保存端末及び配信サーバ
装置が適用されるマルチメディア・コンテンツを配信す
るネットワーク・システムを示す概略図である。

【図５】図４に示したこの発明の一実施の形態に係るコ
ンテンツ・サーバの構成を概略的に示すブロック図であ
る。

【図６】図５に示されたコンテンツ・サーバから送信さ
れるマルチメディア・コンテンツデータの一例に係るデ
ータフォーマットを概略的に示す平面図である。

【図７】図４に示したこの発明の一実施の形態に係る利
用者端末の構成を概略的に示すブロック図である。

【図８】図５に示されたコンテンツ・サーバから送信さ
れるマルチメディア・コンテンツデータの一例に係るＭ
Ｐ４ファイルの構造を示すテーブルである。

【図９】図７に示した利用者端末において、受信したＭ
Ｐ４ファイルからそのサイズを計算するステップを示す
フローチャートである。

【図１０】（ａ）及び（ｂ）は、夫々図７に示した利用
者端末において、保存領域が不足した際に表示される表
示画面例を示す平面図である。

【図１１】図７に示した利用者端末において、受信した
ＭＰ４ファイルから所定のメディアに係るトラックのみ
を保存するステップを示すフローチャートである。

【図１２】図８に示されたＭＰ４ファイルのmdatの構造
をオフセット値で示す説明図である。

【図１３】（ａ）及び（ｂ）は、図１２に示されたＭＰ
４ファイルから所定のメディアに係るトラック・データ
の保存を説明する為の平面図である。

【図１４】（ａ）及び（ｂ）は、図１３に示された所定
のメディアに係るトラック・データを空白領域に詰め替
えの手順のステップを説明する為の平面図である。

【図１５】図８に示されたＭＰ４ファイルにおけるデー
タの入れ替えのステップを示すフローチャートである。

【図１６】（ａ）及び（ｂ）は、図７に示した利用者端
末において、データの入れ替えに好適なデータ構造を説
明的に示す概略図である。

【図１７】（ａ）及び（ｂ）は、図７に示した利用者端
末において、データの入れ替えに好適な他のデータ構造
を説明的に示す概略図である。

【図１８】図４に示したこの発明の他の実施の形態に係
るコンテンツ・サーバの構成を概略的に示すブロック図
である。

【図１９】図４に示したこの発明の更に他の実施の形態
に係るコンテンツ・サーバの構成を概略的に示すブロッ
ク図である。

【図２０】（ａ）及び（ｂ）は、図５に示されたコンテ
ンツ・サーバから送信されるマルチメディア・コンテン
ツデータの他の例に係るＨ．２２３多重フォーマットの
フレーム構造及び多重化テーブルを概略的に示す平面図
である

【符号の説明】

６１．．．利用者端末６２．．．基地局６３．．．交換機６４．．．コンテンツ・サーバ装置６５．．．インターネット７１．．．送信部７２．．．受信部７４．．．多重コンテンツ記憶部７５．．．音声メディア記憶部７６．．．映像メディア記憶部７７．．．多重ファイル作成部７８．．．ヘッダ先出し機能部８３．．．多重ファイル分離部８２．．．受信部８４．．．音声デコーダ８５．．．映像デコーダ８６．．．スピーカ８７．．．表示機８８．．．ブラウザ部８９．．．入力部９０．．．制御部９１．．．送信部９３．．．多重ファイル保存部１００．．．利用者端末制約管理部１１０．．．利用者端末保存優先順位管理部

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5C052 AA01 AB02 AB04 DD04 EE02 EE03 5C064 BA07 BB05 BC23 BD01 BD08 5D044 AB05 AB07 BC01 CC05 DE03 DE12 DE14 DE25 DE49 DE54 GK12 HL11

Claims

【特許請求の範囲】

【請求項１】複数のメディア・コンテンツが所定のフォ
ーマットで多重化されているマルチメディア・データの
送信を要求する為の送信部と、この送信部からの要求に応じて送信されたマルチメディ
ア・データを受信する為の受信部と、このマルチメディア・データを保存する為のデータ保存
部と、前記マルチメディア・データ中の消去されるべきメディ
ア・コンテンツの種別を指定する為の指定部と、前記データ保存部の空き容量をモニタしてマルチメディ
ア・データを保存するに十分な空き容量がない場合に前
記指定された種別のメディア・コンテンツ・データを消
去する為の制御部と、を具備することを特徴とするコンテンツ保存端末。
【請求項２】前記指定部は、利用者が対話的にメディア
・コンテンツの種別を選択する表示部を含むことを特徴
とする請求項１に記載のコンテンツ保存端末。
【請求項３】前記指定部は、利用者が対話的に保存すべ
きメディア・コンテンツの種別を指定して他のメディア
・コンテンツを消去と指定する表示部を含むことを特徴
とする請求項１に記載のコンテンツ保存端末。
【請求項４】前記指定部は、利用者が予め前記マルチメ
ディア・データ中の消去されるべきメディア・コンテン
ツの種別を指定し、これを保持する保持部を含むことを
特徴とする請求項１に記載のコンテンツ保存端末。
【請求項５】前記制御部は、前記指定された種別のメデ
ィア・コンテンツ・データを消去するとともに保存すべ
きメディア・コンテンツ・データを消去されるメディア
・コンテンツ・データに入れ替えて保存部に保存し、保
存されるメディア・コンテンツ・データに関する情報を
更新することを特徴とする請求項１に記載のコンテンツ
保存端末。
【請求項６】前記制御部は、あるメディア・コンテンツ
・データを記録する際の第１記録単位の平均値と他のメ
ディア・コンテンツ・データを記録する際の第２記録単
位の平均値との公倍数で定められる記録ブロックで複数
のメディアをデータ保存部に記録することを特徴とする
請求項１のコンテンツ保存端末。
【請求項７】前記制御部は、２つのメディア・コンテン
ツ・データを記録するとき、前記データ保存部に互いに
逆向きに記録することを特徴とした請求項１のコンテン
ツ保存端末。
【請求項８】複数のメディア・コンテンツが所定のフォ
ーマットで多重化され、その先頭にメディアの種別及び
この種別に対応した各データのサイズ並びに配列情報が
記述されているヘッダを有するマルチメディア・データ
の送信を要求する為の送信部と、この送信部からの要求に応じて送信されたマルチメディ
ア・データを受信する為の受信部と、このマルチメディア・データを保存する為のデータ保存
部と、前記マルチメディア・データ中の消去されるべきメディ
ア・コンテンツの種別を指定する為の指定部と、前記データ保存部の空き容量をモニタすると共に前記ヘ
ッダの各データのサイズから前記マルチメディア・デー
タの総データ・サイズを求め、両者の比較から前記マル
チメディア・データを保存するに十分な空き容量が前記
データ保存部にない場合に、前記ヘッダのデータ配列情
報を参照して指定された種別のメディア・コンテンツ・
データを消去する為の制御部と、を具備することを特徴とするコンテンツ保存端末。
【請求項９】前記指定部は、利用者が対話的にメディア
・コンテンツの種別を選択する表示部を含むことを特徴
とする請求項８のコンテンツ配信システム。
【請求項１０】前記指定部は、利用者が対話的に保存す
べきメディア・コンテンツの種別を指定して他のメディ
ア・コンテンツを消去と指定する表示部を含むことを特
徴とする請求項８のコンテンツ配信システム。
【請求項１１】前記指定部は、利用者が予め前記マルチ
メディア・データ中の消去されるべきメディア・コンテ
ンツの種別を指定し、これを保持する保持部を含むこと
を特徴とする請求項８のコンテンツ配信システム。
【請求項１２】前記制御部は、前記指定された種別のメ
ディア・コンテンツ・データを消去するとともに保存す
べきメディア・コンテンツ・データを消去されるメディ
ア・コンテンツ・データに入れ替えて保存部に保存し、
保存されるメディア・コンテンツ・データに関するヘッ
ダ情報を更新することを特徴とする請求項８に記載のコ
ンテンツ保存端末。
【請求項１３】前記制御部は、あるメディア・コンテン
ツ・データを記録する際の第１記録単位の平均値と他の
メディア・コンテンツ・データを記録する際の第２記録
単位の平均値との公倍数で定められる記録ブロックで複
数のメディアをデータ保存部に記録することを特徴とす
る請求項８のコンテンツ保存端末。
【請求項１４】前記制御部は、２つのメディア・コンテ
ンツ・データを記録するとき、前記データ保存部に互い
に逆向きに記録することを特徴とした請求項８のコンテ
ンツ保存端末。
【請求項１５】データを保存可能な容量と共に送信要求
を受ける為の受信部と、この送信要求に応じて複数のメディア・コンテンツが所
定のフォーマットで多重化されているマルチメディア・
データの送信する為の送信部と、前記マルチメディア・データ中のメディア・コンテンツ
の種別を予め指定する為の指定部と、前記マルチメディア・データのサイズが前記データ保存
容量より大きい際に指定された種別のメディア・コンテ
ンツ・データのみを前記送信部から送信させる為の制御
部と、を具備するコンテンツ保存端末にコンテンツを配信する
配信サーバ装置。