JP4882441B2 - 配信サーバ装置、クライアント装置、及びそれらに用いるプログラム - Google Patents

Description

本発明は、通信ネットワークを介してコンテンツを配信し、該配信されるコンテンツを再生することのできる配信サーバ装置、クライアント装置、及びそれらに用いるプログラムに関する。特に、配信先のクライアント装置に対して、ストリームメディアデータを疑似ストリーム化して配信する技術に関する。

最近では、インターネットなどの通信ネットワークの発達に伴って、携帯電話や通信機能つきのPDA（Personal Data(又はDigital) Assistants）等の携帯通信端末をプラットホームとして利用し、いつでもどこででも、通信ネットワークを介して取得した音楽や着信メロディなどのコンテンツを楽しむことができるようになっている。特に、近年では、パソコン端末向けの情報配信サービスとして普及している所謂RSS（RDF（Resource Description Framework） Site Summary）フィードと呼ばれる、各サイトからのRSS形式による更新情報の配信を、携帯通信端末でも参照することができるようになっている。こうした携帯通信端末向けのRSSフィードによる情報配信サービスに関連するものとして、例えばページアドレスURL（Uniform Resource Locator）が「http: //www.ecreal.co.jp/pc/service/rss/index.html」で示される、インターネット上のホームページ（つまりWebサイト）上に記載されている技術などが従来知られている。

上記ホームページに記載されている従来技術によれば、所謂「RSSリーダ」（あるいは「フィードリーダ」）などと呼ばれている専用のアプリケーションソフトウェアプログラムを用いて、ユーザが予め登録済みのWebサイトからのパソコン端末向けのRSS形式による更新情報を、携帯電話でも参照することができる。すなわち、前記登録済みの各サイトを巡回し、各サイトにおける１乃至複数の記事のダイジェスト等を該記事へのリンクとともに画面表示することにより、ユーザに対してサイト上で公開されている記事を知らせてくれる。そして、ユーザは該表示されたリンクをクリックすることで、リンク先であるHTMLファイル（更新された記事に関するWebページ）等を参照することができる。ただし、携帯電話のディスプレイサイズやデータ通信速度などを考慮して、画面として１度に表示できるのは最大10,000文字程度のテキストのみである。また、RSSに画像などが添付されている場合には、画像のサイズを縮小するなどして携帯電話でも表示することができるようにしている。

上述したように、従来の技術においては、画像のサイズを縮小するなどのようにして適宜にデータ変換することで、パソコン端末向けのRSSフィードによる更新情報を、携帯通信端末向けとして携帯通信端末でも参照することのできるようにしている。しかし、RSSに添付されている画像、音声、動画などが、携帯通信端末では再生できないあるいは再生が困難な類のもの（例えば、MP3エンコードされている音声データ、WMV等の携帯通信端末では未対応であるフォーマットの動画データなど）、あるいはデータサイズが転送上限を超えているもの（例えば、２MB（メガバイト）を超えるデータ）である場合、携帯通信端末ではこれらのメディアデータを受信できない、あるいは受信できたとしても利用することができない。すなわち、従来技術ではプラットフォームとして携帯通信端末を利用するユーザに対して、RSSフィードによる情報配信サービスを十分に提供することができずに都合が悪い、という問題点があった。

本発明は上述の点に鑑みてなされたもので、パソコン端末向けのRSSフィードによる情報配信サービスを、携帯通信端末（クライアント装置）に対しても不都合なく提供することのできる配信サーバ装置、クライアント装置、及びそれらに用いるプログラムを提供することを目的とする。

本発明の請求項１に係る配信サーバ装置は、通信ネットワークを介してクライアント装置とコンテンツサーバとに相互接続され、前記装置間におけるデータ配信を仲介する配信サーバ装置であって、前記コンテンツサーバからストリーム配信される、動画再生のためのメディアデータを受信するデータ受信手段と、前記受信したメディアデータに含まれる音声データと動画データをそれぞれ、所定形式の音声データとフレーム単位の所定形式の複数の静止画像データとに変換し記憶する変換手段と、所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データを生成する生成手段と、前記データ転送周期に一致する再生時間長毎に、前記変換した音声データを分割する分割手段と、前記データ転送周期に一致する再生時間長の画像フレームデータであって、前記データ転送周期に一致する再生時間毎に前記変換した複数の静止画像データが時間的に略平均化して伝送されるよう、前記静止画像データを時間的に略平均化してパッケージ化した画像アーカイブを複数生成するアーカイブ生成手段と、前記データ転送周期毎に、前記クライアント装置からのリクエストに応じて、前記生成した再生指示書データ、前記分割した音声データ、前記生成した複数の画像アーカイブの順序で、前記クライアント装置に対して前記各データを送信する送信手段とを具える。

この発明によると、配信サーバ装置は、情報配信サービスを提供するコンテンツサーバと、該サービスを受けるクライアント装置との間のデータ転送を仲介する機能を具え、コンテンツサーバからストリーム配信されたメディアデータのデータ変換を行った上で、該変換後のデータである音声データと静止画像データとを、所定のデータ転送周期毎にクライアント装置に対して送信する。すなわち、配信サーバ装置はコンテンツサーバからストリーム配信されたメディアデータに含まれる音声データと動画データのそれぞれを、クライアント装置で再生可能なデータ形式の音声データと複数のフレーム単位の静止画像データとに変換する。そして、データ転送周期に一致する再生時間長に対応する分の音声データと、データ転送周期に一致する再生時間長の画像フレームデータであって、静止画像データを時間的に略平均化してパッケージ化した画像アーカイブとに、前記変換後の音声データと静止画像データとを小分けにして転送する。こうすると、クライアント装置では、データ転送周期に一致する再生時間毎に音声データと複数の静止画像データとをダウンロードしながら再生する、所謂疑似ストリームでの動画再生ができるようになる。したがって、プラットフォームとして携帯通信端末のようなクライアント装置を利用するユーザに対しても、情報配信サービスを不都合なく十分に提供することができる。

本発明の請求項３に係るクライアント装置は、通信ネットワークを介して配信サーバ装置に相互接続されるクライアント装置であって、所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データ、前記データ転送周期に一致する再生時間長に対応する音声データ、前記データ転送周期に一致する再生時間長の画像フレームデータからなる１乃至複数の画像アーカイブの順に、繰り返しデータ転送を行うよう前記配信サーバ装置に対して要求する手段と、前記転送要求に応じて、前記各データを前記配信サーバ装置から受信する受信手段と、前記受信した再生指示書データに従い、前記転送要求を繰り返し行うデータ転送周期を設定する設定手段と、前記設定したデータ転送周期毎に、前記受信した音声データを再生する再生手段と、前記設定したデータ転送周期毎に、前記受信した１乃至複数の画像アーカイブを逐次展開し、該展開した画像アーカイブに含まれるフレーム画像を各フレーム画像に対応する時間位置に配置して順次表示する表示手段であって、前記データ転送周期に受信できなかった画像アーカイブに含まれるフレーム画像による表示を、直前の時間位置に配置した前記受信した画像アーカイブに含まれるフレーム画像の表示を維持することにより代替して表示するものとを具える。これによると、クライアント装置は、データ転送周期毎に音声データと複数の静止画像データとをダウンロードしながら再生する、所謂疑似ストリームでの動画再生ができるようになる。

本発明は装置の発明として構成し実施することができるのみならず、方法の発明として構成し実施することができる。また、本発明は、コンピュータまたはＤＳＰ等のプロセッサのプログラムの形態で実施することができるし、そのようなプログラムを記憶した記憶媒体の形態で実施することもできる。

この発明によれば、配信サーバ装置はコンテンツサーバからストリーム配信されたメディアデータを、クライアント装置で再生可能なデータ形式に変換するとともに、前記変換後の音声データと静止画像データとを小分けにして転送することから、どのようなクライアント装置であっても、コンテンツサーバからストリーム配信されるメディアデータを再生して楽しむことができるようになる、という効果を奏する。

以下、この発明の実施の形態を添付図面に従って詳細に説明する。

図１は、本発明に係るクライアント装置及び配信サーバ装置を適用したコンテンツ配信システムの一実施例の全体構成を示すシステムブロック図である。この実施例に示すコンテンツ配信システムは、RSSフィードによる情報配信サービスを提供する元であるコンテンツサーバＣＳと、RSSフィードによる情報配信サービス及び関連したコンテンツの提供を受けるエンドユーザであって、RSSの記事の表示及び記事に添付されている音声、画像、動画などの再生を行うユーザ端末ＭＴ（本発明に係るクライアント装置）と、前記コンテンツサーバＣＳと前記ユーザ端末ＭＴとの間でデータ送受信を仲介する所謂プロクシ（proxy）として機能する配信サーバＨＳ（本発明に係る配信サーバ装置）とが、インターネットなどの既存の通信ネットワークを介して双方向通信可能に適宜に接続されるシステムである。前記ユーザ端末ＭＴは例えば携帯電話であり、前記配信サーバＨＳ及びコンテンツサーバＣＳは一般的なコンピュータ装置である。前記ユーザ端末ＭＴと各種サーバ装置間は、携帯電話の通信回線網及び所定のゲートウェイサーバ（図示せず）を介したインターネットにより相互接続される。一方、各サーバ間の相互接続は有線・無線のどちらであってもよく、また公衆電話回線網やインターネット等に限らず、LAN（Local Area Network）等を含んでいてもよい。なお、RSSフィードによる情報配信サービスの提供が可能なコンテンツ配信システムとしては上記以外のハードウェアを有する場合もあるが、ここでは必要最小限の資源を用いた場合について説明する。

まず、図１に示したクライアント装置（ユーザ端末ＭＴ）、サーバ装置（コンテンツサーバＣＳ、配信サーバＨＳ）いずれかのハード構成の一実施例について、図２を用いて簡単に説明する。図２は、上記各装置いずれか１つの全体構成の一実施例を示すハード構成ブロック図である。ただし、上記各装置は同じようなハード構成を用いるものとして説明することができることから、ここでは代表として配信サーバＨＳについてのブロック図を１つだけ用いて説明する。

本実施例に示す配信サーバＨＳは、マイクロプロセッサユニット（ＣＰＵ）１、リードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３からなるマイクロコンピュータ（制御手段）によって制御されるようになっている。ＣＰＵ１は、この装置全体の動作を制御するものである。このＣＰＵ１に対して、データ及びアドレスバス１Ｄを介してＲＯＭ２、ＲＡＭ３、入力デバイス４、出力デバイス５、通信インタフェース６、外部記憶装置７がそれぞれ接続されている。ＲＯＭ２は、ＣＰＵ１により実行される各種プログラムや各種データを格納するものである。ＲＡＭ３は、ＣＰＵ１が所定のプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリ等として使用される。ＲＡＭ３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。

入力デバイス４は、各種のスイッチやボタン、文字データ入力用のキーボードや数値データ入力用のテンキー、若しくはディスプレイ上に表示されたポインタを操作するためのマウスなどの入力機器である。出力デバイス５は、静止画像データや動画データなどに基づき各種画面を表示する例えば液晶表示パネル（ＬＣＤ）やＣＲＴなどの表示機器（ディスプレイ）、音声データなどに基づき音声や楽音などの音を発する再生機器等である。通信インタフェース６は、通信ネットワークに接続され、該通信ネットワークを介して接続された機器間（ユーザ端末ＭＴ、コンテンツサーバＣＳ等）で各種情報や各種データを送受信するための通信インタフェースである。上記通信インタフェース６は、有線のものに限らず無線のものであってもよい。また、双方を具えていてもよい。

外部記憶装置７は、ＣＰＵ１が実行する各種制御プログラム（例えば、周知のネットワーク用ソフトウエアや各種アプリケーションソフトウエアなど）を記憶する。前記ＲＯＭ２に制御プログラムが記憶されていない場合、この外部記憶装置７（例えばハードディスク）に制御プログラムを記憶させておき、それを前記ＲＡＭ３に読み込むことにより、ＲＯＭ２に制御プログラムを記憶している場合と同様の動作をＣＰＵ１にさせることができる。このようにすると、制御プログラムの追加やバージョンアップ等が容易に行える。なお、外部記憶装置７はハードディスク（HD）に限られず、フロッピィーディスク（FD）、コンパクトディスク（CD）、光磁気ディスク（MO）、DVD（Digital Versatile Diskの略）等の着脱自在な様々な形態の外部記憶媒体を利用する記憶装置であってもよい。若しくは、フラッシュメモリ等の半導体メモリなどであってもよい。なお、配信サーバＨＳは入力デバイス４や出力デバイス５などを１つの装置本体に内蔵したものに限らず、それぞれが別々に構成され、所定のインタフェースを用いて前記各装置を接続するように構成されたものにも同様に適用できることはいうまでもない。

図１の説明に戻って、コンテンツサーバＣＳは、図示しない一般のコンピュータ装置（例えばパソコン端末）向けに、所謂ポッドキャスト（pod cast）などとして知られているRSSフィードによる自動更新型の情報配信サービスを提供するサーバコンピュータである。具体的には、コンテンツサーバＣＳは、MP3やWMA、WMV、MOV等の各種フォーマットからなる音声や画像あるいは動画などのストリームメディアデータ（単に、メディアデータと呼ぶ）をコンテンツとして多数記憶しており、サーバ管理者（あるいはコンテンツホルダー）により任意のタイミングで前記メディアデータの更新・追加・削除が常日頃から行われている。前記メディアデータの公開情報は任意のディレクトリ単位でRDF（Resource Description Framework）あるいはXML（eXtensible Markup Language）を用いてダイジェスト等が記述され、RSSフィードとしてユーザ端末ＭＴに対して提供されるようになっている。

上記コンテンツサーバＣＳがRSSフィードによる情報配信サービスの対象としている一般のコンピュータ装置（パソコン端末）では、「RSSリーダ」と呼ばれるアプリケーションソフトウェアプログラムにより、RSSに記述されているURLに対応するコンテンツサーバＣＳに対してアクセスすると、該アクセスしたコンテンツサーバＣＳからコンテンツを取得する。すなわち、RSSに記述されている記事だけでなく、該記事に添付されている画像、音声、動画などのメディアデータをストリーム配信によりコンテンツサーバＣＳから受け、コンピュータ装置側でコンテンツの表示や再生などをデータを受信しながら行うことができるようになっている。他方、上記コンテンツサーバＣＳが本来ならばRSSフィードによる情報配信サービスの対象としていないユーザ端末ＭＴ（例えば携帯電話）では、端末内に組み込まれている現状のハードウェアやソフトウェアを用いて、RSSに記述されている記事や記事に添付されている各種メディアデータを、データを受信しながら表示・再生することができない。特に、MP3やWMA、WMV、MOVなどのフォーマットからなる各種メディアデータについては、それらのフォーマットに応じた再生エンジンを有していないこと、また、コンテンツサーバＣＳから一般のコンピュータ装置へストリーム配信されるメディアデータはデータサイズが大きく、携帯電話の転送上限を超えるので携帯電話に対して配信することができないことから、携帯電話では上記メディアデータを表示・再生することが基本的にできない。

ユーザ端末ＭＴは例えば携帯電話やPDA等の携帯通信端末であって、配信サーバＨＳとのデータのやり取りを行うための専用のアプリケーションソフトウェアプログラム（以下、単にアプリと呼ぶ）を具える。該アプリは、ユーザが任意に登録した複数のRSSに関し、それらのページアドレスつまりURLを保持することができる。また、アプリはユーザの指示（詳しくはURLの指定）に応じて、あるいは定期的に配信サーバＨＳに対してRSS（RDF/XML）の転送を要求する。例えば、図１に示す例において、コンテンツサーバＣＳ（ページアドレス「http://contserv」）のルートディレクトリにあるRSS「podcast1.rdf」のフィードを受ける場合には、配信サーバＨＳのページアドレス「http://distserv」を指し示すURLにおいて「http://distserv/?url=http://contserv/podcast1.rdf&…」と記述したリクエストを、配信サーバＨＳに対して送信する。コンテンツサーバＣＳからのRSSフィードには、記事のタイトルや記事の概要やリンクの記述の他、添付メディア（圧縮音声ファイルや圧縮動画データ等）の指定情報（URL）も記述されている。本願発明に係るプログラム（RSSリーダ）では、RSSフィードに記述されている情報に従い出力デバイス５に記事の表示を行うとともに、添付されているメディアデータの転送要求を配信サーバＨＳに対して行うようにしている（後述する）。そして、ユーザ端末ＭＴは前記メディアデータの転送要求に応じて配信サーバＨＳから受信した、音声データを再生したり静止画像データを表示したりすることが出力デバイス５によりできる。

配信サーバＨＳは、ユーザ端末ＭＴとコンテンツサーバＣＳとの間の仲介サーバ（所謂プロクシ）として機能する。URLアクセス部Ｕは、ユーザ端末ＭＴから要求されるURLのリクエスト（図中request）を他のサーバ（ここではコンテンツサーバＣＳ）に対して行う。データ変換部Ｄは、前記コンテンツサーバＣＳからのレスポンスが、予め規定された変換対象の音声、画像、動画などのメディアデータ（図中Media）であればメディア変換を行い、該変換後のデータをメディアキャッシュＭＣに蓄積するとともに送信制御部Ｈに送り、ユーザ端末ＭＴに逐次にデータ転送させる。キャッシュ検査部Ｃは、ユーザ端末ＭＴから要求されたURLに対応する変換後のデータがメディアキャッシュＭＣに既に蓄積されていた場合に、改めて前記コンテンツサーバＣＳからメディアデータのストリーム配信を受けることなく、メディアキャッシュＭＣ内の変換後のデータを読み出してユーザ端末ＭＴに転送する。ここで、ユーザ端末ＭＴから要求されたURLがRSSフィードに対応する場合には、上記メディア変換及び変換後のデータの蓄積を行うことなく、コンテンツサーバＣＳからのレスポンスをそのままユーザ端末ＭＴに転送する一方で、要求されたURLが音声データや動画データ（音声トラックのある動画データ）などのメディアデータであった場合には、上記メディア変換及び変換データの蓄積を行う。

配信サーバＨＳにおいて、メディアデータの変換方法はデータの種類によって異なる。すなわち、メディアデータが圧縮音声データ（MP3等）である場合には、ADPCM（Adaptive Differential Pulse Code Modulation）データに展開する。メディアデータが静止画像データ(JPEG,PNG等）である場合には、規定のフォーマット（例えばJPEG）のデータに変換する。メディアデータが動画データ（WMV,MOV等）である場合には、規定描画フレーム単位の複数の静止画像データ（例えばJPEG）とADPCMデータに変換する。メディアキャッシュＭＣには、上記の態様で変換されたデータがパッケージとして（例えばURLに対応するディレクトリ、パス名で）、数日から数週間の所定期間だけ保持される。図１に示す例においては、圧縮音声データ変換後のADPCMデータについては、「contserv/media」ディレクトリ内にパッケージ名「audio.mp3」を付して保持している。静止画像データ変換後のデータについては、「contserv/media」ディレクトリ内にパッケージ名「image.jpg」を付して保持している。動画データ変換後の複数枚の静止画像データとADPCMデータについては、「contserv/media」ディレクトリ内にパッケージ名「video.wmv」を付してそれぞれを別々に保持している。勿論、変換後のデータ（ADPCM、JPEG）個々のサイズが、ユーザ端末ＭＴで再生可能なデータ形式に変換されることは言うまでもない。

ここで、配信サーバＨＳのデータの変換手順について、図３を用いて説明する。図３は、データの変換手順を説明するためのデータ変換部Ｄにおける機能ブロック図である。図３（ａ）は音声データについて、図３（ｂ）は動画データについて変換手順を説明するものである。

図３（ａ）に示すように、音声データはプロバイダ（分配器）ＰＶに入力される。プロバイダＰＶは変換元のデータである音声データのデータフォーマットに対応するだけの複数のデコーダＤＣを具えてなり、該プロバイダＰＶは入力されてきた音声データのデータフォーマットを判定し、対応するデコーダＤＣに対して前記音声データを出力する。デコーダＤＣは、入力された音声データのデコードを行い、デコード後のオーディオサンプルデータをバッファＢＦに記憶させる（バッファリングする）。バッファＢＦは、少なくとも規定秒数分（例えば８秒分）のオーディオサンプルデータを蓄積する。リサンプラーＲＳは、規定秒数毎にバッファＢＦ内のオーディオサンプリングデータを、規定サンプリングレート（例えば44khz）でリサンプリングすることによりADPCMデータとして出力する。このようにして、圧縮音声データはADPCMデータに変換される。

一方、図３（ｂ）に示すように、動画データについても上記した音声データの場合とほぼ同様の変換手順に従って、動画データを複数枚の静止画像データ（JPEG）とADPCMデータとに変換する。すなわち、プロバイダＰＶに入力された動画データは、データフォーマットの判定に従って対応するデコーダＤＣによりデコードされて、該デコードデータがバッファＢＦに記憶される。ただし、動画データの場合、バッファＢＦは少なくとも規定秒数分（例えば８秒分）のフレーム画像データを蓄積する。そして、リサンプラーＲＳは、規定秒数毎にバッファＢＦ内のフレーム画像データを、規定フレームレート（例えば30fps）でリサンプリングしてフレーム画像毎にJPEGデータとして出力する。また、図示を省略したが、動画データに含まれる音声データについては、フレーム画像データと分離された後に上記手順でADPCMデータに変換される。このようにして、動画データは複数枚のJPEGデータとADPCMデータとに変換される。

図１の説明に戻って、ユーザ端末ＭＴに転送するメディアデータが変換対象のデータである場合、配信サーバＨＳは該メディアデータをユーザ端末ＭＴに転送する際に、適宜データの品質や転送レート等のデータ転送態様を調整する。すなわち、ユーザ端末ＭＴでは、配信サーバＨＳから実際に受信できたデータファイルの状況に応じて、要求する転送品質に関する情報（品質要求）を配信サーバＨＳに対して任意のタイミングで通知しており、該通知される品質要求に応じて配信サーバＨＳではデータ転送態様の調整を行っている。例えば、メディアデータが変換対象の音声データであればサンプリングレートの変更、静止画像データであれば画像サイズの変更 及び／又はエンコード品質の変更（ただし、フォーマットがJPEG等の場合）、動画データであればフレームレートの変更 及び／又は画像サイズの変更処理が施される。また、配信サーバＨＳはユーザ端末ＭＴに対して変換対象の音声データを転送する際には、変換後のADPCMデータを小分けにして着信メロディファイル（MLDファイル）とし、動画データを転送する際には変換後のJPEGデータを所定のフレームグループ単位でアーカイブ化して転送する。こうしたユーザ端末ＭＴへのデータ送信制御の詳細な説明については、後述する。これによると、配信サーバＨＳからユーザ端末ＭＴへのデータの転送は、ストリーミング方式ではなくダウンロード方式によるものとなる（疑似ストリーム配信と呼ぶ）。なお、ユーザ端末ＭＴは、データ転送開始前にダミーデータやPingを配信サーバＭＳに送ることで両装置間の通信状態を実測し、これに応じた品質要求を配信サーバＭＳに対して通知するようにしてもよい。

次に、配信サーバＨＳにおけるユーザ端末ＭＴへのデータ転送制御について、図４を用いて説明する。図４は、データ転送制御について説明するための送信制御部Ｈの機能ブロック図である。送信制御部Ｈによるデータ転送制御は、規定のタイムスロット間隔毎（例えば８秒）に周期的に行われる。つまり、タイムスロット間隔をデータ転送周期とする。以下にデータの転送手順１〜８を示す。

転送手順１．メディアキャッシュＭＣから１タイムスロット分のADPCMデータおよび時系列順に複数枚のJPEGデータを取得し、それぞれを対応するバッファＢＦに蓄積する。すなわち、バッファＢＦに蓄積されるデータは、１タイムスロット毎に更新される。
転送手順２．リサンプラーＲＳは、前記バッファＢＦに蓄積されたADPCMデータおよびJPEGデータ（一旦変換されたデータ）を、ユーザ端末ＭＴと配信サーバＨＳとの間における現在の通信状態に適合するようにして再変換する。すなわち、ADPCMデータおよびJPEGデータのリサンプリング品質は、ユーザ端末ＭＴから通知されるタイムスロット毎の品質値の変更要求（図中においてreqで示す）に応じて任意のタイミングで変更される。ADPCMデータであればサンプルレート（及び／又はビットレート）、JPEGデータであれば画像サイズ（及び／又はフレームレート）が適宜に変更されてリサンプリングされる。一例として、サンプルレートは11、22、44khzのいずれかに、画像サイズは240×180pixel、176×144 pixel、128×96 pixelのいずれかに変更される。なお、通常においては、ビットレートが例えば16kbps固定とされ、フレームレートが例えば24fps固定とされる。

転送手順３．ADPCMデータはリサンプラーＲＳによるリサンプリング後、転送可能状態となる。
転送手順４．JPEGデータはリサンプラーＲＳによるリサンプリング後、アーカイバＡＶにより所定のフレーム画像ごとのグループ単位でアーカイブ化される。説明を理解し易くするために、例えばタイムスロット間隔を８秒、フレームレートを８fpsとした場合を示すと、
アーカイブ１：1, 9, 17, 25, 33, 41, 49, 57
アーカイブ２：5, 13, 21, 29, 37, 45, 53, 61
アーカイブ３：3, 11, 19, 27, 35, 43, 51, 59
アーカイブ４：7, 15, 23, 31, 39, 47, 55, 63
アーカイブ５：2, 10, 18, 26, 34, 42, 50, 58
アーカイブ６：6, 14, 22, 30, 38, 46, 54, 62
アーカイブ７：4, 12, 20, 28, 36, 44, 52, 60
アーカイブ８：8, 16, 24, 32, 40, 48, 56, 64
のように、１タイムスロットの間に表示すべきフレーム画像が時間的になるべく平均して伝送されるように、所定枚数のフレーム画像（JPEGデータ）を収めた画像アーカイブを作成する。各画像アーカイブ内の1〜64までの数字は、各フレーム画像毎に付与される固有の番号（フレーム番号）であり、フレーム番号１のフレーム画像がこのタイムスロット期間の最初に表示されるフレーム画像であり、フレームレートに従ってフレーム番号順に順次表示がなされるものである。

転送手順５．転送用に用意した各データの状態に応じて、再生指示書を生成する。再生指示書に記述される内容については、後述する。
転送手順６．データの転送順序は、１タイムスロット毎に、再生指示書、ADPCMデータ、アーカイブ１,アーカイブ２,…,アーカイブＮの順である。ADPCMデータの転送に関して説明すると、配信サーバＨＳにはユーザ端末ＭＴの機種に対応可能な複数種類の着信メロディファイルのテンプレート（実質中身が空のもの）が予め記憶されており、ユーザ端末ＭＴの機種に対応したフォーマットのテンプレートにADPCMデータを埋め込んで、着信メロディファイルとしてパケット送信される。一方、画像アーカイブに関しては、アーカイブ単位にパケット送信される。
転送手順７．１タイムスロット内に転送できなかった画像アーカイブは、その時点で転送が中断される。上記したアーカイブ化の例においては、１タイムスロットの間にアーカイブ８まで伝送できればコマとびのない滑らかな動画再生（フレームレート８fps相当）となり、アーカイブ４まで伝送できれば1コマとびの動画再生（フレームレート４fps相当）となり、アーカイブ２までなら4コマとびの動画再生（フレームレート２fps相当）となり、アーカイブ１のみなら8コマとびの動画再生（フレームレート１fps相当）となる。
転送手順８．再生すべきデータの終端に達した場合には、ヌル（null）データの再生指示書（null指示書と呼ぶ）を送信する。

なお、１タイムスロット期間に対応する複数のフレーム画像を、どのようにグループ化してアーカイブとするかは予め規定されており、配信サーバＨＳは各アーカイブに含まれるフレーム画像を規定したテーブル等を所定の記憶手段に記憶している。また、上記した実施例では、説明を理解し易くするために、簡易に８フレームを８アーカイブに納めた例を示した。データ転送時における配信サーバＨＳにおける画像アーカイブの作り方は、「１アーカイブに納められるフレーム画像が時間的に略平均化されており、画像アーカイブを受信するごとにフレームレートが擬似的にあがる」ことを満たしていれば特に限定されない。例えば、２４fpsの動画を８秒分ずつアーカイブ化する場合の第１の態様としては、１アーカイブあたりのフレーム画像数を８とし、全２４アーカイブを作成してよい。すなわち、
アーカイブ１: 1, 25, 49, 73, 97, 121, 145, 169
アーカイブ２: 13, 37, 61, 85, 109, 133, 157, 181
アーカイブ３: 7, 31, 55, 79, 103, 127, 151, 175
アーカイブ４: 19, 43, 67, 91, 115, 139, 163, 187
アーカイブ５: 4, 28, 52, 76, 100, 124, 148, 172
アーカイブ６: 16, 40, 64, 88, 112, 136, 160, 184
アーカイブ７: 10, 34, 58, 82, 106, 130, 154, 178
アーカイブ８: 22, 46, 70, 94, 118, 142, 166, 190
アーカイブ９: 2, 26, 50, 74, 98, 122, 146, 170
アーカイブ１０: 14, 38, 62, 86, 110, 134, 158, 182
アーカイブ１１: 8, 32, 56, 80, 104, 128, 152, 176
アーカイブ１２: 20, 44, 68, 92, 116, 140, 164, 188
アーカイブ１３: 5, 29, 53, 77, 101, 125, 149, 173
アーカイブ１４: 17, 41, 65, 89, 113, 137, 161, 185
アーカイブ１５: 11, 35, 59, 83, 107, 131, 155, 179
アーカイブ１６: 23, 47, 71, 95, 119, 143, 167, 191
アーカイブ１７: 3, 27, 51, 75, 99, 123, 147, 171
アーカイブ１８: 15, 39, 63, 87, 111, 135, 159, 183
アーカイブ１９: 9, 33, 57, 81, 105, 129, 153, 177
アーカイブ２０: 21, 45, 69, 93, 117, 141, 165, 189
アーカイブ２１: 6, 30, 54, 78, 102, 126, 150, 174
アーカイブ２２: 18, 42, 66, 90, 114, 138, 162, 186
アーカイブ２３: 12, 36, 60, 84, 108, 132, 156, 180
アーカイブ２４: 24, 48, 72, 96, 120, 144, 168, 192
この場合における動画再生は、画像アーカイブを受信するごとに 1*, 2*, 3, 4*, 5, 6, 7, 8*, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24* fps（ただし、* 以外は概数）のようにして、フレームレートが疑似的にあがる。

２４fpsの動画を８秒分ずつアーカイブ化する場合の第２の態様としては、１アーカイブあたりのフレーム画像数を２４とし、全８アーカイブを作成してよい。すなわち、 アーカイブ１: 1, 9, 17, 25, 33, 41, 49, 57, 65, 73, 81, 89, 97, 105,113,
121, 129, 137, 145, 153, 161, 169, 177, 185 アーカイブ２: 5, 13, 21, 29, 37, 45, 53, 61, 69, 77, 85, 93, 101, 109, 117,
125, 133, 141, 149, 157, 165, 173, 181, 189
アーカイブ３: 3, 11, 19, 27, 35, 43, 51, 59, 67, 75, 83, 91, 99, 107,115,
123, 131, 139, 147, 155, 163, 171, 179, 187
アーカイブ４: 7, 15, 23, 31, 39, 47, 55, 63, 71, 79, 87, 95, 103,111, 119,
127, 135, 143, 151, 159, 167, 175, 183, 191
アーカイブ５: 2, 10, 18, 26, 34, 42, 50, 58, 66, 74, 82, 90, 98, 106,114,
122, 130, 138, 146, 154, 162, 170, 178, 186
アーカイブ６: 6, 14, 22, 30, 38, 46, 54, 62, 70, 78, 86, 94, 102,110, 118,
126, 134, 142, 150, 158, 166, 174, 182, 190
アーカイブ７: 4, 12, 20, 28, 36, 44, 52, 60, 68, 76, 84, 92, 100,108, 116,
124, 132, 140, 148, 156, 164, 172, 180, 188
アーカイブ８: 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96, 104,112, 120,
128, 136, 144, 152, 160, 168, 176, 184, 192
この場合における動画再生は、アーカイブを受信するごとに 3*, 6*, 9, 12*, 15, 18, 21, 24* fps（ただし、*以外は概数）のようにして、疑似的にフレームレートがあがる。
以上のように、配信サーバＨＳにおける画像アーカイブの作り方としては、種々の態様が考えられる。

なお、タイムスロット間隔は８秒に限らない。例えば、ユーザ端末ＭＴと配信サーバＨＳ間の実効通信速度を192kbps、転送１回あたりにダウンロード可能なデータサイズの上限を100kB と仮定した場合には、100kBのデータサイズのデータを９つダウンロードするには概ね4.7秒かかる。さらに、パケット通信を行う際のロスやデータ量が増えた場合のマージンなどを見越すと、上記した実施例に示したようにタイムスロット間隔を８秒程度に設定するのが適当である。すなわち、タイムスロット間隔は実装環境に応じて任意に設定される。

配信サーバＨＳからのデータ（変換後のデータ）転送の開始にあわせて、ユーザ端末ＭＴは該転送されてきたデータを順次再生し、再生済みのデータはメモリから消去する（疑似ストリーム再生）。そこで、ユーザ端末ＭＴにおける転送データの再生手順について、図５を用いて説明する。図５は、転送データの再生手順を示す機能ブロック図である。以下にデータの再生手順ａ〜ｇを示す。

再生手順ａ．配信サーバＨＳからは１タイムスロット毎に順次、再生指示書、ADPCMデータ（着信メロディファイル）、アーカイブ１，…，アーカイブＮの順にパケットデータが伝送され、これらを受信バッファＲＢに蓄積する。
再生手順ｂ．制御手段（ＣＰＵ）は、受信バッファＲＢに蓄積されたデータを先着優先で読出す。

再生手順c．１タイムスロットの間は、下記に示す（1）〜（5）の順番に従って、レジスタＲＧ、音声バッファＯＢ、画像バッファＧＢ、ビデオバッファＶＢの各内容がそれぞれ更新される。
（１）再生指示書の内容をレジスタＲＧに保持する。また、再生指示書の受信に応じて、時間計測するタイマＴＭのカウントを初期化（０クリア）する。再生指示書には、次に示すような情報が例えばテキスト形式により記述されている。タイムスロット間隔（通常固定：例えば8000msec）。画像データのフレームレート fps（通常固定：24fps、ただし静止画のみの場合には0fps）。１タイムスロット内において伝送（受信）すべき画像アーカイブ数 N（デフォルト値：８，通信状態に応じて変更してもよい）。ADPCMデータのサンプリング周期 fs（ただし、省略可：着信メロディファイル中にも記載可能なため）。ADPCMデータのビットレート bps（ただし、省略可：着信メロディファイル中にも記載可能なため）。
（２）音声バッファＯＢ・画像バッファＧＢからのデータ読出しを制御するための読み出し周期と、受信バッファＲＢからのデータ取り込みを制御するための割込み周期を、レジスタＲＧの内容に応じてそれぞれ設定する。
（３）受信したADPCMデータを音声バッファＯＢに取り込む。
（４）受信した画像アーカイブを、データ展開部ＵＰにより逐次展開しながら画像バッファＧＢに格納する。画像バッファＧＢは、フレームレート（fps）×タイムスロットの数に対応するだけの記憶領域に区分されており、展開されたJPEGデータはフレーム位置に対応した領域に、離散的に格納されていく。このとき、カウンタＣＮは、展開した（受信した）画像アーカイブの個数をカウントする。
（５）前記設定した読み出し周期に従って、音声バッファＯＢからADPCMデータを、画像バッファＧＢからJPEGデータを読み出し、ADPCMデータをD/A変換器ＤＡに、JPEGデータを表示デバイス（例えばLCD）ＤＰのビデオバッファＶＢ（描画RAM）にそれぞれ転送する。ここで、画像バッファＧＢ内に格納されているJPEGデータは、ユーザ端末ＭＴと配信サーバＨＳ間の通信状態の良し悪しにより、ユーザ端末ＭＴのデータ受信時において、完全にデータが受信できずに一部が脱落した歯抜け状態で格納されている場合がある。その場合には、格納されていないJPEGデータの読み出しをスキップして、直前の有効なJPEGデータをビデオバッファＶＢに維持しておくよう制御される。

再生手順ｄ．１タイムスロットの終端に達したとき、音声バッファＯＢと画像バッファＧＢとカウンタＣＮの内容をそれぞれ０クリアする。
再生手順ｅ．初回のタイムスロットの再生を開始する際には、十分なデータが音声バッファＯＢ、画像バッファＧＢに蓄積されるまで、各バッファからのデータ読み出しは遅延される。
再生手順ｆ．各タイムスロットが終端に達した時点で、品質変更部ＱＨは展開できた画像アーカイブ数（カウンタＣＮによりカウントされる）と、再生指示書に記述されている伝送（受信）すべき画像アーカイブ数（Ｎ）とを比較し、比較結果に応じた品質変更要求を配信サーバＨＳに対して通知する。例えば、（展開できた画像アーカイブ数／伝送（受信）すべき画像アーカイブ数）が0.8を下回ったような場合には、１段階品質を落とすように要求する。
再生手順ｇ．転送データの再生終了は、再生指示書が「null指示書」であるか否かにより識別する。

次に、ユーザ端末ＭＴと配信サーバＨＳ間の通信状態に応じた、データ転送時における品質変更の手順について、図６を用いて説明する。図６は、品質変更の手順について説明するための概要図である。

図６に示すように、配信サーバＨＳは内部情報としてセッション管理テーブルを持つ。セッション管理テーブルは、配信サーバＨＳと相互接続されたクライアントへデータ転送を行っている各セッションの情報を保持する（すなわち、転送開始時にはセッション管理テーブルへレコードが追加され、転送終了時には該当するレコードがセッション管理テーブルから削除される）。セッション管理テーブルは、ユーザ端末ＭＴのアドレス（cliant address）、ユーザ端末ＭＴからリクエストされたURL（request URL）、ステータス（STATUS:ユーザ端末の機種情報、対応する着信メロディファイルフォーマット、タイムスロットの設定、転送する音声及び画像の各データの転送品質など）を組にしたものを、１レコードとして記憶する。配信サーバＨＳは、ユーザ端末ＭＴからURLリクエストを受け取った際に、先ず最初にセッション管理テーブルを参照して、URLリクエストを発したユーザ端末ＭＴのアドレスに一致するレコードの有無を検索する。同じユーザ端末ＭＴのアドレスに一致するレコードが無い場合には、「ユーザ端末ＭＴのアドレス、リクエストされたURL、デフォルトの品質」でなるレコードを、セッション管理テーブルに追加する。

他方、同じユーザ端末ＭＴのアドレスに一致するレコードがある場合には、リクエストURLが一致しているか否かをさらに検査する。リクエストURLが一致していない場合は、直前までのセッションレコードを消去するとともに転送処理を終了させ、新規にセッションを開始する。リクエストURLが一致していた場合は、転送品質の変更リクエストであるとみなして、転送品質の変更に関する処理を実行する。この場合、ユーザ端末ＭＴから配信サーバＨＳに対し要求する転送品質は、リクエストされたURLの末尾にURLパラメータとして付加されている（なお、URLパラメータが無い場合や未知のパラメータ値である場合、配信サーバＨＳはパラメータを無視して転送品質の変更に関する処理を行わなくてよい）。配信サーバＨＳではユーザ端末ＭＴからのURLリクエストを受信すると、URLパラメータを抽出してセッション管理テーブルのステータスを更新するとともに、転送処理における転送品質の変更を行う。なお、セッション管理テーブルは図６に示したようなテーブル形式ではなく、１セッション１ファイルとして配信サーバＨＳの所定のテンポラリ記憶領域に情報を保持しておいてもよい。

図７は、ユーザ端末ＭＴから変更を要求することが可能な転送品質の一例を示す。図７から理解できるように、品質値としては、音声品質及び画像品質ともにH（高品質）、M（中品質）、L（低品質）、0（無音又は静止画）のいずれかがある。例えば、音声品質の具体的な品質値としては、44khz/16 kbps（高品質）、22khz/16 kbps（中品質）、11khz/16 kbps（低品質）であり、画像品質の具体的な品質値としては、240×180pixel/24fps（高品質）、176×144pixel/24fps（中品質）、128×96pixel/24fps（低品質）などである。ユーザ端末ＭＴからは、図７に示した品質値のいずれかがリクエストURLとともに通知される（品質要求）。音声及び画像の品質の変更は、例えば次に示すような第１〜第３のパターンのいずれかのようにするとよい。デフォルト（初期）値は、ADPCM（音声）データの転送品質及びJPEG（静止画像）データの転送品質を共に“H”（高品質）とする。第１のパターンとしては、初期：音声H 画像H、１：音声H 画像M、２：音声M 画像M、３：音声M 画像L、４：音声L 画像L、５：音声L 画像0の中からいずれかを選択する。この第１のパターンは、ADPCMデータとJPEGデータをほぼ同じ品質で伝送しようとするものである。第２のパターンとしては、初期：音声H 画像H、１：音声H 画像M、２：音声H 画像L、３：音声H 画像0、４：音声M 画像0、５：音声L 画像0の中からいずれかを選択する。この第２のパターンは、優先的にADPCMデータを高品質に伝送しようとするものである。第３のパターンとしては、初期：音声H 画像H、１：音声M 画像H、２：音声L 画像H、３：音声0 画像H、４：音声0 画像M、５：音声0 画像Lの中からいずれかを選択する。この第３のパターンは、優先的にJPEGデータを高品質に伝送しようとするものである。データ転送時には、これらの品質に対応したデータが用意される（上述したように、メディアキャッシュＭＣに蓄積されたデータがリサンプリングされることによる）。

図１に示したコンテンツ配信システムでは、TCP/IP、HTTP（HTTPS）等の公知の通信手順に従って、ユーザアクセス開始からコンテンツの取得までが行われている。そこで、RSSに添付されている添付メディアについて、ユーザアクセス開始からコンテンツ取得までの一連の通信手順について、図８を用いて説明する。図８は、ユーザ端末ＭＴと配信サーバＨＳとコンテンツサーバＣＳ間における通信手順の概要を示すシーケンス図である。ただし、ここではRSSフィード後における添付メディアの転送要求（URL転送リクエスト）以降の処理について、コンテンツサーバＣＳから、一般のパソコン端末に対してストリーム配信されるメディアデータであるWMVフォーマットの動画データ（a.wmv）を、携帯電話（ユーザ端末ＭＴ）に対して配信する場合を例に説明する。また、ここではタイムスロット間隔を８秒、フレームレートを２４fpsとして、上述した第２の態様に示した１アーカイブあたりのフレーム画像数を２４、全８個の画像アーカイブを作成して、JPEGデータを転送する場合を示している。なお、図８では、ユーザ端末ＭＴから送信されるリクエストに含まれるパラメータのみを記載している。

最初に、ユーザ端末ＭＴから配信サーバＨＳに対して「URL転送リクエスト」を送信する。例えば、ユーザ端末ＭＴは、転送を要求するユーザ所望の動画データのソースURL（contserv/a.wmv）及びユーザ端末ＭＴの機種情報（xxx）等を、配信サーバＨＳに対して通知する（url=http://contserv/a.wmv&typ=xxx）。配信サーバＨＳは通知を受けると、ユーザ端末ＭＴに適した音声ファイル（着信メロディファイル）を生成する。ただし、メディアキャッシュＭＣに既に該当の動画データの変換後のデータが記憶済みである場合には、指示書作成の処理までジャンプする。メディアキャッシュＭＣに既に該当の動画データの変換後のデータが記憶済みでない場合、配信サーバＨＳはコンテンツサーバＣＳに対して通知された動画データのリクエストを送る（forward）。すると、コンテンツサーバＣＳから該当する動画データのストリーム配信が開始されるので（accept及びstream start）、配信サーバＨＳは動画データをストリーム受信するとともに並行して該受信した動画データのデータ変換を行い、該変換後のデータをメディアキャッシュＭＣにバッファリングする（buffering,convert,catching）。また、配信サーバＨＣは、ユーザ端末ＭＴに対して初期データ（properties）を送る。初期データ（properties）には、著作権情報（権利者名、タイトル等）、再生時間情報（オリジナルコンテンツの再生時間；省略可）、その他表示情報（コンテンツの紹介文や任意のハイパーリンク等）などが記述されており、ユーザ端末ＭＴは該初期データに基づいて初期設定を行う。ここでの初期設定では、主に画面表示に関しての設定を行う。これに対し、データ再生に関しての設定（再生設定）は、図８に示すように各タイムスロット毎に配信サーバＨＳから受信する再生指示書に基いて行う。

ユーザ端末ＭＴは第１回目のタイムスロット（time=1）時において、再生指示書(manifest）、ADPCMデータ(a.wmv.1.mld）、画像アーカイブ(a.wmv.1.1.zip〜a.wmv.1.8.zip）の順に転送要求を行う。ここで、転送要求に含まれるパラメータについて簡単に説明すると、「time」は何回目のタイムスロットであるかを表す（1〜M：ただしMは（ソース全体の再生時間／タイムスロット間隔）以上の最小の整数）。「dat」は、転送するデータの種別を表す（MANIF：再生指示書、MLD：ADPCMデータ（着信メロディファイル）、IMG：画像アーカイブ）。「seq」は、転送する画像アーカイブの当該タイムスロット内でのシーケンス番号を表す（1〜N：この例ではN=８）。「qt」は、転送品質を表す（例えば、qt=HMと記述されている場合には、音声品質を高品質、画像品質を中品質とする）。このように、実際のファイル名ではなく、タイムスロットの回数とデータ種別を指定する値を送ることで、該当データの転送要求を実現している。

配信サーバＨＳは、ユーザ端末ＭＴから受信した再生指示書の転送要求(url=…&time=1&dat=MANIF&qt=HH)に応じて、ユーザ端末ＭＴに対して再生指示書を生成して送信する。ユーザ端末ＭＴは、該受信した再生指示書に基きデータ再生に関しての設定（再生設定）を行う。次に、ユーザ端末ＭＴからADPCMデータの転送要求が行われると(url=…&time=1&dat=MLD&qt=HH)、配信サーバＨＳはメディアキャッシュＭＣに記憶済みのADPCMデータから演奏時間がタイムスロット間隔の時間長さ分だけを切り出し、該切り出したADPCMデータを着信メロディファイルに埋め込み、これをユーザ端末ＭＴに送信する。該切り出したADPCMデータの受信終了に応じて、ユーザ端末ＭＴは画像データの転送要求を行う。配信サーバＨＳは該当の画像データをメディアキャッシュＭＣから読み出してアーカイブ化し、該生成した画像アーカイブをユーザ端末ＭＴに送信する。ここに示す１回目のタイムスロットでは、当該時間内に生成された８つの画像アーカイブ全てが順次に送られている例を示している(a.wmv.1.1.zip〜a.wmv.1.8.zip）。全てのデータ（ファイル）を受信するか、あるいは再生指示書の転送要求を行った時間から所定のオフセット時間（例えば、タイムスロット間隔に相当する時間）が経過したら、ユーザ端末ＭＴは該受信したデータに基づき再生を開始する。これにより、８秒分の音声と１９２（８アーカイブ×２４フレーム）コマの静止画像からなるコンテンツが再生される。

次に、画像アーカイブの受信完了前に、転送時刻がタイムスロット間隔を経過した場合について説明する。ここに示す図８では、第２回目のタイムスロット（time=2）に、５番目の画像アーカイブ（a.wmv.2.5.zip）までしか取得できなかった（６番目の画像アーカイブの転送要求（url=…&time=2&dat=IMG&seq=6&qt=HH）をしたが、６番目の画像アーカイブ（a.wmv.2.6.zip）の受信完了前にタイムスロット間隔を経過した）場合を示している。この場合には、新たに切り出した８秒分のADPCMデータ（図示せず）に基く音声と、１２０（５アーカイブ×２４フレーム）コマの静止画像からなるコンテンツが再生される。これは１回目のタイムスロット時のコンテンツ再生と比較すると、再生音声は同じように正しく再生されるが、再生画像は７２コマ分だけコマ落ちした画像が再生されることになる。こうしたデータの受信途中でタイムスロット間隔が経過してしまった場合には、次のタイムスロット（第３回目）のデータ転送を開始する際に、ユーザ端末ＭＴから配信サーバＨＳに対し転送品質を変更するよう要求する。例えば、画像品質を１段階低下させる（url=…&time=3&dat=MANIF&qt=HM）。

第３回目のタイムスロット（time=3）においては、配信サーバＨＳは上記転送品質（qt=HM）に応じた品質のADPCMデータ及び画像データを、上記第１回目又は第２回目のタイムスロット時と同様の手順に従ってユーザ端末ＭＴに転送し、ユーザ端末ＭＴでは該データに基づきコンテンツを再生する。そして、転送すべきデータが終端に達した場合（第２５回目のタイムスロット：time=25）、配信サーバＨＳは再生指示書に記述する情報の全て（あるいは一部）をNULL値とした再生指示書（null指示書）を、ユーザ端末ＭＴに送信する。ユーザ端末ＭＴは、NULL値が入った再生指示書（null指示書）を受信すると、再生データの終端であると判定してコンテンツの再生を終了する。上記した処理を、コンテンツサーバＣＳからのメディアデータのストリーム受信と並行して、繰り返し実行する。

ここで、ユーザ端末ＭＴにおける品質変更の決まり（ルール）の一例を、以下に示す。例えば１〜２割程度の多少の画像アーカイブが送りきれなかった場合には、特に品質変更しなくてよい。実際に送信できた画像アーカイブ数が本来送るべき画像アーカイブ数の８割を切った場合、フレーム画像のサイズを落とす。最小サイズまで画像サイズを落としても送信しきれない場合は、フレームレートを下げる（例えば、24fpsから8fps等に下げる）。それでも駄目な場合は、最後に受信したフレーム画像を静止画として維持、あるいは「画像は表示できません」旨の表示を行い画像転送を中止する。音声データファイルの受信にすら失敗した場合は、再生を一時停止して受信できなかった音声データファイルの品質を落として再要求する（その場合、画像アーカイブの転送は要求しない（qt=*0））。最低品質の音声データファイルすら受信できない場合は、「受信できません」旨を表示して処理を終了する。要するに、「せめて音声だけでも送る」ようにする。上記したような品質変更のルールは例えばプログラム化されて記憶されており、これに従って品質変更についての制御が行われる。

なお、配信サーバＨＳは再生指示書中に、各画像アーカイブが対応するフレーム位置を指定する上記テーブルを含ませて送信してもよいし、画像アーカイブ内の各フレーム画像にフレーム位置に相当するファイル名を付与してアーカイブ化してもよい。後者の場合、例えば上記した第１の態様の場合、タイムスロット＝２の３アーカイブ目では、画像アーカイブ「xxx.2.3.zip」に含まれる８つのファイル名はそれぞれ、「xxx.2.7.jpg」、「xxx.2.31.jpg」、「xxx.2.55.jpg」、「xxx.2.79.jpg」、「xxx.2.103.jpg」、「xxx.2.127.jpg」、「xxx.2.151.jpg」、「xxx.2.175.jpg」となる。
なお、アーカイブ化の手法は特に制限されない。また、画像アーカイブは当然ながらデータ圧縮してもよい。その場合のアルゴリズムは、可逆な圧縮アルゴリズムであれば問わない（例えばZIP等）。また、各フレーム画像を非圧縮のビットマップデータとして、任意の可逆な圧縮アルゴリズムでアーカイブ化するようにしてもよい。

上述したような通信手順に従うと、配信サーバＨＳがデータ転送を仲介して、ユーザ端末ＭＴとコンテンツサーバＣＳ間のコンテンツ配信は行われる。そこで、上記通信手順にのっとりコンテンツを配信する具体的な処理について、図９〜図１２を用いて説明する。ただし、実際には配信サーバＨＳとユーザ端末ＭＴは、通信手順にのっとり所定の情報を送受信しながら並行して各々の処理を実行するのであるが、ここでは説明を理解しやすくするために、配信サーバＨＳとユーザ端末ＭＴにおいて独立に実行される処理にそれぞれ図を分けて説明する。

図９は、配信サーバＨＳで実行する「コンテンツ配信処理」の一実施例を示すフローチャートである。配信サーバＨＳは常時稼動状態にあり、配信サーバＨＳの制御手段（ＣＰＵ）はハードディスク等に予め記憶された制御プログラムに従い、不図示のサーバプロセスにより当該配信サーバＨＳを所謂WWWサーバとして動作させている。上記サーバプロセスは、配信サーバＨＳが備えるネットワークカード等の通信インタフェース（図２参照）により他のサーバあるいはユーザ端末ＭＴとの通信を行っており、ユーザ端末ＭＴからのリクエスト（HTTPリクエスト）を受信すると、以下に説明する「コンテンツ配信処理」（図９参照）あるいは「データ転送処理」（図１０参照）を実行するための１乃至複数のプログラム及び／又は各種データをハードディスク等から読み出して所定の処理を実行する。なお、以下に説明する「コンテンツ配信処理」において利用される各種データ（ユーザ端末ＭＴより受信するリクエスト、セッションデータ、キャッシュ等）は、配信サーバＨＳが備えるＲＡＭあるいはハードディスク等にバッファＢＦあるいは記憶領域が設けられ、適宜記憶・保持・更新されるものである。

ステップＳ１は、ユーザ端末ＭＴのアドレス（クライアントアドレス）、ユーザ端末ＭＴから送信されたリクエストURL内に含まれるその他パラメータを抽出する。その他パラメータは、上述した「ソースURL（url）」、「機種情報（typ）」、「タイムスロット（time）」、「データ種別（dat）」、「画像アーカイブのシーケンス番号（seq）」、「転送品質（qt）」などである。ステップＳ２は、図６に示したセッション管理テーブルを参照して、セッション有りか否かを判定する。当該ユーザ端末ＭＴのクライアントアドレスが、セッション管理テーブルに登録済みである場合を「セッション有り」と判定する。「セッション有り」と判定した場合には（ステップＳ２のｙｅｓ）、前記抽出した「ソースURL」と、セッション管理テーブルに保持されている「リクエストURL」とが同一であるか否かを判定する（ステップＳ６）。URLが同一でないと判定した場合には（ステップＳ６のｎｏ）、セッション管理テーブルに保持されている前記クライアントアドレスの現セッションデータを破棄し（ステップＳ７）、ステップＳ３へ飛ぶ。一方、URLが同一であると判定した場合には（ステップＳ６のｙｅｓ）、抽出した各パラメータに応じて、機種情報、タイムスロット、品質設定、送信データ、画像アーカイブ番号を設定し（ステップＳ８）、「データ転送処理」を実行する（ステップＳ９）。データ転送処理については、後述する（図１０参照）。

他方、上記ステップＳ２において、「セッションなし」と判定された場合、つまり当該ユーザ端末ＭＴのクライアントアドレスが、セッション管理テーブルに登録されていない場合（ステップＳ２のｎｏ）、あるいは現セッションデータが破棄された場合（上記ステップＳ７）には、セッション管理テーブルに当該ユーザ端末ＭＴに関するセッションデータを新たに生成する（ステップＳ３）。ステップＳ４は、ソースURLはキャッシュ対象のメディアデータを指し示すURLであるか否かを判定する。URLがキャッシュ対象でない場合、つまりメディアデータ以外のデータを指し示すURLである場合には（ステップＳ４のｎｏ）、対象URLへのリクエスト及びレスポンスの転送処理を実行する（ステップＳ５）。URLがキャッシュ対象である場合、つまりメディアデータを指し示すURLである場合には（ステップＳ４のｙｅｓ）、既に変換後のデータがメディアキャッシュＭＣにあるか否かを判定する（ステップＳ１０）。既に変換後のデータがメディアキャッシュＭＣにある場合には（ステップＳ１０のｙｅｓ）、メディアキャッシュＭＣからデータの読み出しを開始する（ステップＳ１１）。読み出されたデータは、逐次バッファＢＦに蓄積される。変換後のデータがメディアキャッシュＭＣにない場合には（ステップＳ１０のｎｏ）、コンテンツサーバＣＳに対する対象URLのリクエスト、コンテンツサーバＣＳから配信されたレスポンス（つまりメディアデータ）の変換開始及びメディアキャッシュＭＣへの変換後のデータのキャッシュの開始、メディアキャッシュＭＣからキャッシュした変換後のデータの読み出し開始といった、一連の処理を実行する（ステップＳ１２）。ステップＳ１１又はステップＳ１２の処理実行後、ステップＳ８に処理を移し、リクエストされたデータの転送を行う。

ここで、上記「コンテンツ配信処理」において実行される「データ転送処理」（図９のステップＳ９参照）の動作について、図１０を用いて説明する。 図１０は、「データ転送処理」の一実施例を示すフローチャートである。

ステップＳ２１は、ユーザ端末ＭＴに転送中の変換後のデータが終端に達したか否かを判定する。データが終端に達していると判定した場合、つまり転送終了の場合には（ステップＳ２１のｙｅｓ）、内容がnullである再生指示書（null指示書）を生成してユーザ端末ＭＴに送信する（ステップＳ２２）。そして、セッション管理テーブルから、当該ユーザ端末ＭＴに関するセッションレコードを削除する（ステップＳ２３）。一方、データが終端に達していないと判定した場合には（ステップＳ２１のｎｏ）、ユーザ端末ＭＴから送信されたリクエストURLによる要求内容を判定し、該判定した要求内容に応じた処理を実行する（ステップＳ２４）。要求内容が「機種情報（typ=xxx）」である場合には、機種情報に応じた着信メロディファイルのフォーマットを特定し（ステップＳ２５）、初期データ（プロパティ）をユーザ端末ＭＴに送信する（ステップＳ２６）。要求内容が「再生指示書（dat=MANIF）」である場合には、セッション管理テーブルに基いて再生指示書を生成して、ユーザ端末ＭＴに送信する（ステップＳ２８）。

要求内容が「ADPCMデータ（dat=MLD）」である場合には、タイムスロット間隔の時間長さ分だけの音声データの切り出しを行い（ステップＳ２９）、前記特定された着信メロディファイルに埋め込んで、該着信メロディファイルをユーザ端末ＭＴに送信する（ステップＳ３０）。すなわち、音声データは、着信メロディファイル中に埋め込まれた形で伝送される。着信メロディファイルのフォーマットはユーザ端末ＭＴの機種ごとに異なるため、データ伝送前にユーザ端末ＭＴの機種情報を取得する。要求内容が「JPEGデータ（dat=IMG）」である場合には、タイムスロットのフレーム画像のうち、指定された画像アーカイブ番号に対応するフレーム画像を読み出し（ステップＳ３１）、該読み出したフレーム画像を必要に応じてリサンプリングした上で、複数のフレーム画像をアーカイブ化して送信する（ステップＳ３２）。

図１１は、ユーザ端末ＭＴ側で実行するアプリである「RSSリーダ」のメイン処理の一実施例を示すフローチャートである。図１２は、「RSSリーダ」のサブ処理の一実施例を示すフローチャートである。図１２（ａ）は音声データの再生に係るサブ処理を示し、図１２（ｂ）は画像データの再生に係るサブ処理を示す。これらのサブ処理は、メイン処理の実行中に適宜に割込みして動作する割込み処理である。ユーザ端末ＭＴは前述のとおり携帯通信端末であり、ユーザ端末ＭＴの制御手段（ＣＰＵ）はＲＯＭやフラッシュメモリに予め記憶されたプログラムに従い、端末本来の機能である通話機能の他、パケット通信によりネットワーク上のコンテンツへのアクセス等の機能を実行し、ネットワークカード等の通信インタフェースにより無線あるいは有線で他のサーバや基地局あるいは他のユーザ端末ＭＴとの通信を行う。

ユーザ端末ＭＴは、以下に説明する「メイン処理」（図１１参照）および「サブ処理」（図１２参照）を実行するためのアプリを構成する１乃至複数の制御プログラム及び／又は各種データを、上記フラッシュメモリ等に保持しており、ユーザ端末ＭＴの制御手段（ＣＰＵ）は、不図示の各種ボタンスイッチや音声入力等の操作手段を用いたユーザによるユーザ端末ＭＴの操作に基き発生したアプリの実行指示に応じて、上記制御プログラムを読み出して以下説明する「メイン処理」の実行を開始する。

図１１に示すように、メイン処理は、まず登録されているRSS一覧をLCD等の表示装置にて画面表示する（ステップＳ４１）。すなわち、アプリ（RSSリーダ）は該アプリに対応する保存データとしてRSSの一覧（具体的にはRSSを指し示すURL）を保持しており、初期表示としてそのRSS一覧をユーザに対して提示する。ステップＳ４２では、入力デバイス（操作手段）を用いたユーザによるユーザ端末ＭＴの操作に応じて発生した操作イベントが何であるかを判定する。操作イベントがユーザによる直接のURL入力に応じて発生する「URL入力」である場合には、該入力されたURLを前記RSS一覧に登録して（ステップＳ４３）、表示中のRSS一覧の表示画面を更新する（ステップＳ４４）。操作イベントがRSS一覧の中から任意のURLを選択することに応じて発生する「URL選択」である場合には、ステップＳ４６以降の処理を実行する。操作イベントが上記以外の操作に応じて発生する「その他」である場合には、それらの操作に応じた「その他の処理」を実行する（ステップＳ４５）。上記ステップＳ４４又はステップＳ４５の処理終了後には、ステップＳ４１の処理に戻る。ただし、ステップＳ４５において、終了指示の処理を行った場合には当該アプリを終了する。

操作イベントが「URL選択」である場合には、配信サーバＨＳに対して選択したURLに基くURL転送リクエストを要求する（ステップＳ４６）。そして、表示画面を再生・表示画面に切り替え（ステップＳ４７）、配信サーバＨＳから初期データを受信し、これに基き初期画面の表示等の初期設定を行う（ステップＳ４８）。ステップＳ４９は、配信サーバＨＳに対してURLと再生指示書の配信要求を含むリクエストを送信する。ステップＳ５０は、配信サーバＨＳから受信した再生指示書が「null指示書」であるか否かを判定する。再生指示書が「null指示書」である場合には（ステップＳ５０のｙｅｓ）、データ再生を終了するとともに、表示画面を再生画面から初期画面等に復帰させ（ステップＳ５１）、ステップＳ４１の処理に戻る。

一方、再生指示書が「null指示書」でない場合には（ステップＳ５０のｎｏ）、以下に示すステップＳ５２〜ステップＳ６２の各処理を実行する。ステップＳ５２は、配信サーバＨＳから受信した再生指示書に基いて再生設定を行う。この再生設定は、タイムスロット、音声・画像の再生レートの設定などである。ステップＳ５３は、タイマＴＭを初期化する（dT=0）。タイマＴＭは、メイン処理とは独立して時間をカウントアップするタイマである。データ再生を管理するタイミングとしては、第１にタイムスロット間隔毎、第２に音声再生間隔毎、第３に表示画像更新間隔毎である。ただし、後者２つについては、再生開始後、図示しない音源ボード（チップ）あるいはビデオボード（チップ）に、データ再生の管理を任せるようにしてもよい。ステップＳ５４は、配信サーバＨＳに対し音声データの配信を要求する。ステップＳ５５は、タイムスロット以内に配信サーバＨＳからのデータ受信が完了しているか否かを判定する。タイムスロット以内にデータ受信が完了していないと判定した場合には（ステップＳ５５のｎｏ）、全体の再生を一時停止する（ステップＳ５６）。一方、タイムスロット以内にデータ受信が完了していると判定した場合には（ステップＳ５５のｙｅｓ）、受信データを展開する（ステップＳ５７）。すなわち、再生準備データとして、音声バッファに一時記憶する。そして、受信したデータ自体については展開後に破棄する。

ステップＳ５８は、タイマＴＭによりカウントされている現在の転送時刻dTがタイムスロット間隔Ｔよりも大きいか否かを判定する。現在の転送時刻dTがタイムスロット間隔Ｔよりも大きくないと判定した場合には（ステップＳ５８のｎｏ）、配信サーバＨＳに対して最初の画像データを要求し（ステップＳ５９）、配信サーバＨＳから受信した画像データ（画像アーカイブ）を展開する（ステップＳ６０）。すなわち、再生準備データとして、画像バッファに一時記憶する。そして、受信したデータ自体は展開後に破棄する。上記ステップＳ５９及びステップＳ６０の処理は、画像アーカイブ数に相当するＮ回又はタイムスロット間隔Ｔ秒の間だけ繰り返し行われ、残りの画像アーカイブを順次要求・取得する（要求シーケンス値：seqの更新）。前記Ｔ秒間は、上記ステップＳ５３において初期化されたタイマＴＭにより計測される。ステップＳ６１は、配信サーバＨＳから受信したデータの再生を開始する。ただし、当該処理は、初回の再生又は再生が一時停止されていたような場合にのみ、後述するタイマ割込み処理である「サブ処理」のスレッドを生成することで実行が開始されるものである。すなわち、後述するサブ処理は、再生終了指示がメイン処理から発生されるまで（オブジェクトが破棄されるまで）勝手に動き続けており、それによりデータの再生が続けられるようになっている。ステップＳ６２は、リクエストパラメータを更新する。ここで更新するパラメータは、タイムスロット：time(１加算する)、要求データ種別：dat、品質値：qtである。ただし、品質値については、１タイムスロット毎に変更するか否かを判定し、該判定に応じてパラメータを更新する。

図１２（ａ）に示す音声データの再生に係るサブ処理では、ｔ番目のタイムスロット時に受信した音声データを逐次に再生する（ステップＳ７１）。すなわち、音声バッファには連続的に配信サーバＨＳから受信した音声データが書き込まれ、（通信状態の悪化などによる音声データの受信に失敗しない限り）連続した音声サンプリングデータが記録される。この音声バッファには、少なくとも２回分のタイムスロット間隔（ここでは１６秒）に対応する再生時間の音声データを格納することのできるサイズの格納領域が確保されており、再帰的に音声バッファの読出しアドレスが更新されることで、音声データを連続的に再生することができるようになっている。すなわち、タイムスロット間隔は受信した１つの音声ファイルの演奏時間に相当し、この時間が経過した時点で次に受信された音声データを再生する。このとき、メイン処理では、タイムスロット毎に、書込み開始アドレスとして0又は音声バッファの真ん中のアドレス位置を交互に指定する。こうすると、音声バッファからの読み出しに応じた音声データの再生と、再生中の音声データに後続する次の音声データの音声バッファへの書き込みとを同時並行的に行うことができ、従って音声データを連続的に再生することができるようになる。

図１２（ｂ）に示す画像データの再生に係るサブ処理では、LCDなどの表示装置の描画表示レートに合わせて、表示バッファの内容をｔ番目のタイムスロット時に受信した複数毎の画像データで逐次に更新する（ステップＳ８１）。すなわち、画像バッファは（１画像アーカイブ内のフレーム画像数×２×タイムスロット間隔Ｔ）分の格納領域が確保されており、画像アーカイブ内の各フレーム画像が、対応する格納領域に配置される。そして、表示装置の描画更新レートにあわせて、画像バッファの対応する位置（小数点が出る場合もあり、その場合は整数化または補間）のフレーム画像が表示されるようになっている。すなわち、タイムスロット間隔は受信した１つの画像アーカイブに含まれる複数のフレーム画像全てを順次に表示する時間に相当し、この時間が経過した時点で次に受信された画像アーカイブに含まれる複数のフレーム画像を順番に表示し始める。このとき、メイン処理では、タイムスロット毎に、書込み開始アドレスとして0又は画像バッファの真ん中のアドレス位置を交互に指定する。こうすると、画像バッファからの読み出しに応じた画像アーカイブに含まれるフレーム画像の表示と、表示中の画像アーカイブに後続する次の画像アーカイブの画像バッファへの書き込みとを同時並行的に行うことができ、従って画像アーカイブに含まれるフレーム画像を連続的に表示することができるようになる。

以上のように、RSS（例えばポッドキャストなど）をフィードするコンテンツサーバＣＳと、該RSSフィードを受けるユーザ端末ＭＴ（携帯通信端末）との間に、データ転送を仲介する配信サーバＨＳを設けておき、該配信サーバＨＳは前記コンテンツサーバＣＳからストリーム配信により提供される動画データを、ユーザ端末ＭＴで再生可能なフォーマットの音声データ（ADPCM）と静止画像データ（JPEG）とに変換するとともに、これらを小分けにしてユーザ端末ＭＴに対して転送する。ユーザ端末ＭＴは、前記小分けにされた複数の音声データと複数の静止画像データとをダウンロードしながら再生することで、疑似ストリームでの動画再生を行うことができる。これにより、携帯通信端末上でも動画再生を含む、RSSフィードによる十分な情報配信サービスを受けることができるようになる。

なお、データ変換について、ストリームメディアデータを、ADPCMデータと複数のJPEGデータとに変換する例を示したが、これに限らない。例えば、ストリームメディアデータを、小分けにしたMPEG4や上記した以外の他のフォーマットのデータに変換してもよい。ただし、メディアキャッシュＭＣに蓄積する変換後の各データの品質は、配信サーバＨＳ側でデータ転送等の対応可能な最高のもの（例えば、音声44khz,16kbps／画像240x180pixel,24fps）とする。 なお、データ転送について、転送する際の音声品質、画像品質は例示したものに限らない。例えば、フレーム画像数は30fpsでも良い。また、転送制御される品質に対応して１つのデータに対し、複数種類の品質のデータをデータ変換処理にて用意しておくようにしもよい。さらに、メディアキャッシュＭＣに変換後のデータを蓄積する際には、複数品質のデータを同時並行的に生成してもよいし、一旦デフォルト品質でメディアキャッシュＭＣに保存したデータを、複数種類の品質のデータに再変換して記憶しておくようにしてもよい。
なお、フレーム画像をアーカイブ化してデータ転送することに限らず、音声データ（ADPCM）をアーカイブ化してデータ転送するようにしてもよい。

なお、クライアントアプリ（RSSリーダ）の動作時には、１タイムスロット以内に、当該タイムスロット時に受信すべき全データファイルの受信を完了することもある（正常に再生されている場合には必ず完了している）。そうした場合、次のタイムスロットの開始タイミングが来るまで、次のタイムスロット時に受信すべきデータの転送要求を発信するのを待つようにしてもよいし、又はタイムスロットの開始タイミングに拘わらずに受信完了に応じて、次のタイムスロット時に受信すべきデータの転送要求を行うようにしてもよい。後者の場合は、受信したデータがどのタイムスロット時に受信すべきデータであったか、および各受信データを音声バッファ、画像バッファに展開し始めるタイミングを別途管理・制御する必要がある。前者の場合は、１タイムスロット毎に一連の処理を繰り返すことになるため、受信したデータは逐次（所定の書込み位置に）展開すればよい。なお、品質指定のパラメータが「qt=0*」あるいは「qt=*0」である場合には、対応する音声データあるいは画像データの転送要求自体をスキップするようにしてよい。

なお、データ転送／データ再生時に品質の変更を行う場合、再生すべき音声サンプリング値が不連続になる恐れがある。そこで、ユーザ端末ＭＴ側では、音声バッファ内のデータを再生する際に、ファイル接続区間に相当するデータの近傍でクロスフェードしたり補間する等して、データ間で滑らかにサンプル値が遷移するように制御するようにしてもよい。同様に、小片ファイルの受信が時間内に到着しなかった場合、現在の再生を一時停止するとともにフォースダンプし、次の小片ファイルが到着次第、再生ポインタを上記フォースダンプしたアドレスまで戻し、そこから再生を再開するようにしてもよい（あわせてボリュームを滑らかに上げるとよい）。 なお、データ転送／データ再生時における品質の変更は、低品質にすることに限らず高品質にするようにしてもよい。例えばタイムスロット間隔が経過するよりも速く受信が完了した場合には、次のタイムスロットを開始する際に、ユーザ端末ＭＴから配信サーバＨＳに対し転送品質を高品質に変更するよう要求するようにしてもよい。こうすると、通信状態の悪化に応じて低品質に変更されたとしても、通信状態の復帰にあわせて再度高品質なデータを転送するように、データの品質を戻すことができ有利である。

なお、上述した実施例では「音声トラックのある動画データ」を例に説明したが、音声のみの場合は画像伝送のリクエストを、動画のみの場合は音声伝送のリクエストをそれぞれ行わなくてよい。また、静止画だけのデータである場合には、最初のタイムスロットにおいてパラメータ「qt=*0」 のリクエストを行えばよい。 なお、受信すべき（リクエストすべき）データがどのような組み合わせであるかは、ユーザ端末ＭＴ側でURLの拡張子（wmv, mp3, swf等）で判断してもよいし、配信サーバＨＳがデータの変換・キャッシュを行う際にメディアデータの組み合わせを判定し、初期データ（profile） あるいは 再生指示書（manifest） 中にデータの組み合わせがどのようなものであり、どのようなリクエストを送るべきかを識別するための情報を記述するようにしてもよい。

なお、配信サーバＨＳは、他のサーバ（コンテンツサーバＣＳ）に蓄積されているコンテンツを仲介するものであるとして説明したが、配信サーバＨＳ自体がコンテンツを記憶したコンテンツサーバＣＳであってもよい。この場合は、最初からメディアキャッシュＭＣに変換後のデータに相当するデータを予め蓄積しておいてもよいし、配信前にデータの変換・キャッシュを行うようにしてもよい。 なお、ユーザ端末ＭＴの機種を示す パラメータ「typ」 は最初にのみ送るものとして説明したが、リクエストを行う度に「typ」を指定し、配信サーバＨＳはリクエストがあるごとに、対応するテンプレートファイル（着信メロディファイル）を選択して音声データを埋め込むようにしてもよい。 なお、配信サーバＨＳはユーザ端末ＭＴの機種に対応する着信メロディファイルのテンプレートファイルへ音声データを埋め込むものとして説明したが、配信サーバＨＳがユーザ端末ＭＴに音声データをレスポンスとして返す際に、メディアタイプとしてユーザ端末ＭＴの機種に対応する着信メロディフォーマットを指定するようにしてもよいし、定型の着信メロディファイルに音声データを付加した後、機種に対応した着信メロディファイルに変換するようにしてもよい。

なお、上述した各処理は、各々の装置における図示しない制御手段が所定のプログラム（ソフトウエア）を実行することにより実施される。勿論、コンピュータソフトウエアの形態に限らず、DSP（ディジタル・シグナル・プロセッサ）によって処理されるマイクロプログラムの形態でも実施可能であり、また、この種のプログラムの形態に限らず、一部あるいは全てをディスクリート回路又は集積回路若しくは大規模集積回路あるいはゲートアレイ等を含んで構成された専用ハードウエア装置の形態で実施してもよい。

本発明に係るクライアント装置及び配信サーバ装置を適用したコンテンツ配信システムの一実施例の全体構成を示すシステムブロック図である。 コンテンツ配信システムを構成するユーザ端末またはサーバ装置のいずれかの全体構成の一実施例を示すハード構成ブロック図である。 データの変換手順を説明するためのデータ変換部における機能ブロック図であり、図３（ａ）は音声データについて、図３（ｂ）は動画データについてそれぞれ示す。 データ転送制御について説明するための送信制御部の機能ブロック図である。 転送データの再生手順を示す機能ブロック図である。 品質変更の概要について説明するための概要図である。 ユーザ端末から変更を要求することが可能な転送品質の一例を示す。 図１に示したコンテンツ配信システムを構成するユーザ端末と配信サーバとコンテンツサーバ間における通信手順を示すシーケンス図である。 コンテンツ配信処理の一実施例を示すフローチャートである。 データ転送処理の一実施例を示すフローチャートである。 RSSリーダのメイン処理の一実施例を示すフローチャートである。 RSSリーダのサブ処理の一実施例を示すフローチャートであり、図１２（ａ）は音声データの再生処理、図１２（ｂ）は画像データの再生処理を示す。

符号の説明

ＭＴ…ユーザ端末（クライアント装置）ＨＳ…配信サーバ、ＣＳ…コンテンツサーバ、Ｃ…キャッシュ検査部、Ｕ…URLアクセス部、Ｈ…送信制御部、Ｄ…データ変換部、ＭＣ…メディアキャッシュ、ＰＶ…プロバイダ、ＤＣ…デコーダ、ＢＦ…バッファ、ＲＳ…リサンプラー、ＡＶ…アーカイバ、ＳＬ…セレクタ、ＲＢ…受信バッファ、ＲＧ…レジスタ、ＴＭ…タイマ、ＯＢ…音声バッファ、ＧＢ…画像バッファ、ＤＡ…Ｄ／Ａ変換部、ＳＰ…アンプ・スピーカ、ＶＢ…ビデオバッファ、ＤＰ…ＬＣＤ（ディスプレイ）、ＣＮ…カウンタ、ＱＨ…品質変更部、１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…入力デバイス、５…出力デバイス、６…通信インタフェース、７…外部記憶装置

Claims (8)

1. 通信ネットワークを介してクライアント装置とコンテンツサーバとに相互接続され、前記装置間におけるデータ配信を仲介する配信サーバ装置であって、
   前記コンテンツサーバからストリーム配信される、動画再生のためのメディアデータを受信するデータ受信手段と、
   前記受信したメディアデータに含まれる音声データと動画データをそれぞれ、所定形式の音声データとフレーム単位の所定形式の複数の静止画像データとに変換し記憶する変換手段と、
   所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データを生成する生成手段と、
   前記データ転送周期に一致する再生時間長毎に、前記変換した音声データを分割する分割手段と、
   前記データ転送周期に一致する再生時間長の画像フレームデータであって、前記データ転送周期に一致する再生時間毎に、前記変換した複数の静止画像データが時間的に略平均化して伝送されるよう、前記静止画像データを時間的に略平均化してパッケージ化した画像アーカイブを複数生成するアーカイブ生成手段と、
   前記データ転送周期毎に、前記クライアント装置からのリクエストに応じて、前記生成した再生指示書データ、前記分割した音声データ、前記生成した複数の画像アーカイブの順序で、前記クライアント装置に対して前記各データを送信する送信手段と
   を具える配信サーバ装置。
2. 前記クライアント装置からリクエストされたメディアデータに対応する音声データと静止画像データとが、既に所定の記憶手段に記憶されているか否かを判定する判定手段をさらに具え、
   前記変換手段は、前記判定に従い、前記メディアデータに対応する音声データと静止画像データとが、前記記憶手段に記憶されていない場合には、通信ネットワークを介して接続されたコンテンツサーバからストリーム配信される、動画再生のためのメディアデータを受信し、該受信したメディアデータを、所定形式の音声データと所定形式の複数の静止画像データとに変換し前記記憶手段に記憶することを特徴とする請求項１に記載の配信サーバ装置。
3. 通信ネットワークを介して配信サーバ装置に相互接続されるクライアント装置であって、
   所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データ、前記データ転送周期に一致する再生時間長に対応する音声データ、前記データ転送周期に一致する再生時間長の画像フレームデータからなる１乃至複数の画像アーカイブの順に、繰り返しデータ転送を行うよう前記配信サーバ装置に対して転送要求する手段と、
   前記転送要求に応じて、前記各データを前記配信サーバ装置から受信する受信手段と、 前記受信した再生指示書データに従い、前記転送要求を繰り返し行うデータ転送周期を設定する設定手段と、
   前記設定したデータ転送周期毎に、前記受信した音声データを再生する再生手段と、
   前記設定したデータ転送周期毎に、前記受信した１乃至複数の画像アーカイブを逐次展開し、該展開した画像アーカイブに含まれるフレーム画像を各フレーム画像に対応する時間位置に配置して順次表示する表示手段であって、前記データ転送周期に受信できなかった画像アーカイブに含まれるフレーム画像による表示を、直前の時間位置に配置した前記受信した画像アーカイブに含まれるフレーム画像の表示を維持することにより代替して表示するものと
   を具えるクライアント装置。
4. 適宜のコンテンツサーバからフィードされるＲＳＳに対応付けられたＵＲＬを複数記憶する記憶手段と、前記配信サーバ装置に対して前記ＵＲＬに基くＲＳＳフィードを要求するリクエスト手段とをさらに具え、
   前記要求に応じた前記配信サーバ装置からのレスポンスが前記再生指示書データ、音声データ、画像アーカイブであることを特徴とする請求項３に記載のクライアント装置。
5. コンピュータに、
   所定の通信インタフェースを介して接続されたコンテンツサーバからストリーム配信される、動画再生のためのメディアデータを受信する手順と、
   前記受信したメディアデータに含まれる音声データと動画データをそれぞれ、所定形式の音声データとフレーム単位の所定形式の複数の静止画像データとに変換して所定の記憶手段に記憶する手順と、
   所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データを生成する手順と、
   前記データ転送周期に一致する再生時間長毎に、前記変換した音声データを分割する手順と、
   前記データ転送周期に一致する再生時間長の画像フレームデータであって、前記データ転送周期に一致する再生時間毎に、前記変換した複数の静止画像データが時間的に略平均化して伝送されるよう、前記記憶手段に記憶した静止画像データを時間的に略平均化してパッケージ化した画像アーカイブを複数生成する手順と、
   前記データ転送周期毎に、前記クライアント装置からのリクエストに応じて、前記生成した再生指示書データ、前記分割した音声データ、前記生成した複数の画像アーカイブの順序で、前記クライアント装置に対して前記各データを所定の通信インタフェースを介して送信する手順と
   を実行させるためのプログラム。
6. コンピュータに、
   所定の通信インタフェースを介して接続されたクライアント装置からリクエストされたメディアデータに対応する音声データと静止画像データとが、既に所定の記憶手段に記憶されているか否かを判定する手順と、
   前記判定に従い、前記メディアデータに対応する音声データと静止画像データとが、前記記憶手段に記憶されていない場合には、通信ネットワークを介して接続されたコンテンツサーバからストリーム配信される、動画再生のためのメディアデータを受信し、該受信したメディアデータに含まれる音声データと動画データをそれぞれ、所定形式の音声データとフレーム単位の所定形式の複数の静止画像データとに変換し前記記憶手段に記憶する手順と、
   所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データを生成する手順と、
   前記データ転送周期に一致する再生時間長毎に、前記変換した音声データを分割する手順と、
   前記データ転送周期に一致する再生時間長の画像フレームデータであって、前記データ転送周期に一致する再生時間毎に、前記変換した複数の静止画像データが時間的に略平均化して伝送されるよう、前記記憶手段に記憶した静止画像データを時間的に略平均化してパッケージ化した画像アーカイブを複数生成する手順と、
   前記データ転送周期毎に、前記クライアント装置からのリクエストに応じて、前記生成した再生指示書データ、前記分割した音声データ、前記生成した複数の画像アーカイブの順序で、前記クライアント装置に対して前記各データを所定の通信インタフェースを介して送信する手順と
   を実行させるためのプログラム。
7. コンピュータに、
   所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データ、前記データ転送周期に一致する再生時間長に対応する音声データ、前記データ転送周期に一致する再生時間長の画像フレームデータからなる１乃至複数の画像アーカイブの順に、繰り返しデータ転送を行うよう所定の通信インタフェースを介して接続された配信サーバ装置に対して転送要求する手順と、
   前記転送要求に応じて、前記各データを前記配信サーバ装置から前記通信インタフェースを介して受信する手順と、
   前記受信した再生指示書データに従い、前記転送要求を繰り返し行うデータ転送周期を設定する手順と、
   前記設定したデータ転送周期毎に、前記受信した音声データを再生する手順と、
   前記設定したデータ転送周期毎に、前記受信した１乃至複数の画像アーカイブを逐次展開し、該展開した画像アーカイブに含まれるフレーム画像を各フレーム画像に対応する時間位置に配置して順次に所定の表示手段に表示する際に、前記データ転送周期に受信できなかった画像アーカイブに含まれるフレーム画像による表示を、直前の時間位置に配置した前記受信した画像アーカイブに含まれるフレーム画像の表示を維持することにより代替して表示する手順と
   を実行させるためのプログラム。
8. コンピュータに、
   所定の通信インタフェースを介して接続された適宜のコンテンツサーバからフィードされるＲＳＳに対応付けられたＵＲＬを所定の記憶手段に複数記憶する手順と、
   前記通信インタフェースを介して接続された配信サーバ装置に対して前記ＵＲＬに基くＲＳＳフィードを要求する手順と、
   前記要求に応じて、所定のデータ転送周期と、音声データの再生ビットレート及び／又は画像データの再生フレームレートとを少なくとも規定した再生指示書データ、前記データ転送周期に一致する再生時間長に対応する音声データ、前記データ転送周期に一致する再生時間長の画像フレームデータからなる１乃至複数の画像アーカイブの順に、繰り返しデータ転送を行うよう前記通信インタフェースを介して接続された配信サーバ装置に対して転送要求する手順と、
   前記転送要求に応じて、前記各データを前記配信サーバ装置から前記通信インタフェースを介して受信する手順と、
   前記受信した再生指示書データに従い、前記転送要求を繰り返し行うデータ転送周期を設定する手順と、
   前記設定したデータ転送周期毎に、前記受信した音声データを再生する手順と、
   前記設定したデータ転送周期毎に、前記受信した１乃至複数の画像アーカイブを逐次展開し、該展開した画像アーカイブに含まれるフレーム画像を各フレーム画像に対応する時間位置に配置して所定の表示手段に順次表示する際に、前記データ転送周期に受信できなかった画像アーカイブに含まれるフレーム画像による表示を、直前の時間位置に配置した前記受信した画像アーカイブに含まれるフレーム画像の表示を維持することにより代替して表示する手順と
   を実行させるためのプログラム。

Images