JP3813142B2 - ストリーミングコンテンツ管理システム、ストリーミングコンテンツ再生コンピュータ、及びストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Description

本発明はストリーミングコンテンツ管理システム、ストリーミングコンテンツ再生コンピュータ、及びストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体に関し、特にネットワークを介して配信される情報を取り扱うストリーミングコンテンツ管理システム、ストリーミングコンテンツ再生コンピュータ、及びストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体に関する。

近年、インターネットの急激な普及によって、サーバコンピュータ内に複数のサーバが起動され、無数のＨＴＭＬ(Hyper Text Markup Language)テキスト、ＪＰＥＧ(Joint Photographic Experts Group)ファイル、ＧＩＦ(Graphics Interchange Format) ファイル、音声ファイルなどのコンテンツが多数のユーザに提供されている。ここで、ＪＰＥＧなどの画像ファイルや音声ファイルは、テキストに比べてファイルサイズが大きく、ファイルの伝送にも時間がかかる。そのため、回線の伝送量が劇的に増え、回線への負荷が過大となっている。

このような回線の混雑を避けるため、一度アクセスしたコンテンツをローカルの媒体（ハードディスク装置など）にキャッシュしておくことが行われている。これにより、すでにキャッシュされているコンテンツに対して再度アクセスした際には、ローカルの媒体から読み出すことができ、通信回線の伝送量を低減することができる。

なお、同様のデータ転送量削減に関する技術は、他にも考えられている（たとえば、特許文献１、特許文献２、特許文献３参照）。
特開平６−３３２８５８ 特開昭６３−２９１１４２ 特開昭５９−９４１５５

しかし、コンテンツをキャッシュする方式では、最初のアクセスでは常にサーバから転送しなければならないという問題がある。また、キャッシュデータの保存には期限が設けられているのが普通であり、その期限以後のアクセスでは、やはり伝送路の伝送容量の影響を受けることとなる。

ところで、インターネットのコンテンツには、毎日のように更新されるものもあるが、一定期間更新する必要のないものもある。例えば、ある会合の参加者名簿のようなコンテンツは、その会合の開催と参加者が決定してから会合が終了するまで、内容の更新の必要はあまりない。しかも、特定の会員のみが参加する会合であれば、その会合に関するコンテンツは会員のみが閲覧できれば十分である。

そこで、特定の内容のコンテンツをＣＤ−ＲＯＭ(Compact Disk Read Only Memory)に記録し、必要としている者に配布しておくことが考えられる。ただし、この場合には、コンテンツを媒体に記録する際に、コンテンツ間のリンク関係を書き直さなければならない。すなわち、ＨＴＭＬファイルがサーバに存在するときには、リンク先の指定や、インライン表示すべき画像ファイルの指定などは、指定先のファイルのサーバ上でのＵＲＬ(Uniform Resource Locator)が割り当てられている。そのため、リンク先のファイルやインライン表示する画像ファイルなどを含めてＣＤ−ＲＯＭに格納する場合、指定するファイルの場所は、ローカルの媒体となる。リンク先に対してローカルの媒体としてアクセスするには、ＵＲＬの指定をローカルの名前に書き直す必要がある。この作業を全てのＨＴＭＬファイルに対して行うのは、非常に大変な作業である。

また、ストリーミングコンテンツを配信するには、同期制御により、進行状況に応じた画像を画面表示する場合がある。たとえば、音声をストリーミングで配信し、音声の進行に合わせた画像をクライアントで表示する場合である。従来は、ストリーミングサーバに同期ファイルを保存しておき、ストリーミング再生プレイヤーがストリーミングコンテンツを再生する際には、対応する同期ファイルをストリーミングサーバから取得する。同期ファイルには、ストリーミングコンテンツの再生を開始した時刻を基準として、どの時間帯にどの画像を開くのかが指定されている。このようにして、ストリーミングコンテンツの再生内容に適合した画像を同期させつつＷＷＷブラウザに表示させることができる。

ところが、従来の同期制御技術では、ストリーミングコンテンツをいつ再生開始しても、その再生内容が同一であることを前提としていたため、例えば、インターネットを介して、一定時間帯内であれば最初から再生可能なストリーミングコンテンツには適用できなかった。

本発明はこのような点に鑑みてなされたものであり、任意の時刻に再生可能なストリーミングコンテンツと他のコンテンツとの同期制御ができるストリーミングコンテンツ管理システム、ストリーミングコンテンツ再生コンピュータ、及びストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。

本発明では上記課題を解決するために、ストリーミングサーバからネットワークを介してローカルコンピュータに、分割して配信されるストリーミングコンテンツを管理するストリーミングコンテンツ管理システムにおいて、前記ストリーミングサーバは、前記ストリーミングコンテンツを分割して分割コンテンツを得て、得た前記分割コンテンツに同期させる関連情報を同期ファイルから抽出して、抽出した前記関連情報を前記分割コンテンツに結合してクリップを得て、得た前記クリップを前記ローカルコンピュータに送信する手段を具備し、前記ローカルコンピュータは、前記ストリーミングコンテンツの配信を前記ストリーミングサーバに要求し、要求に応じて送付された前記クリップを再生する手段と、送付された前記クリップに含まれる関連情報が指し示す関連指示情報が自己の記憶装置にあれば、該記憶装置から前記関連指示情報を取得し、該関連指示情報が他のサーバにあれば、該他のサーバから該関連指示情報を取得する要求中継手段とを具備する、ことを特徴とするストリーミングコンテンツ管理システムが提供される。

以上説明したように本発明では、配信情報の複製情報をローカルコンピュータ内に格納しておき、サーバコンピュータ内の配信情報の取得要求をローカルプロキシィサーバが受け取り、適当な情報を決定するようにしたため、サーバコンピュータとの間で伝送される情報量を削減できる。

また、ストリーミングサーバが同期ファイルを管理し、ストリーミングコンテンツのクリップ内に関連情報を含ませたため、ローカルコンピュータから何時ストリーミングコンテンツが要求されようとも、再生内容と関連情報との対応関係がずれることはない。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、実施の形態における基本的なコンテンツ取得方法を示す図である。下記の実施の形態は、互いにネットワークで接続されたローカルコンピュータ１とサーバコンピュータ２とで構成される。

サーバコンピュータ２は、ネットワークを介して配信すべき配信情報２ｂｂ、及び配信情報２ｂｂの属性情報が登録されたサーバ側制御ファイル２ｂａを格納する配信情報格納手段２ｂと、配信情報格納手段２ｂに格納された情報を要求に応じて配信するサーバ２ａと、を有している。

ローカルコンピュータ１は、配信情報格納手段２ｂ内の配信情報２ｂｂの複製情報１ｂｂ、及び複製情報１ｂｂが配信情報格納手段２ｂ内に存在したときの位置情報と複製情報１ｂｂの属性情報とが登録されたローカル側制御ファイル１ｂａを格納する複製情報格納手段１ｂと、配信情報格納手段２ｂに格納された配信情報２ｂｂの取得要求を受け取ると、サーバ側制御ファイル２ｂａとローカル側制御ファイル１ｂａとを取得し、要求された配信情報２ｂｂの属性情報と、配信情報２ｂｂに対応する複製情報１ｂｂの属性情報とを比較し、比較結果に基づいて取得すべき情報を決定する要求中継手段１ｃと、を有している。

このような情報管理システムにおいて、情報閲覧手段１ａから要求中継手段１ｃに配信情報２ｂｂの取得要求が出されると、その要求を要求中継手段１ｃが受け取り、内容を解析する。そして、要求相手のサーバ２ａが管理しているサーバ側制御ファイル２ｂａと、複製情報格納手段１ｂ内のローカル側制御ファイル１ｂａとを取得する。ここで、要求された情報が複製情報格納手段１ｂ内に格納されているかを確認し、格納されている場合には、さらに、複製情報格納手段１ｂ内の複製情報１ｂｂの版数が最新のものかどうかを判断する。複製情報格納手段１ｂ内に該当する情報が存在し、しかも、最新の版数である場合には、複製情報格納手段１ｂから情報を取り出す。そうでなければサーバコンピュータ２から配信情報２ｂｂを取り出す。

これにより、サーバコンピュータ２から取得する情報が少なくてすむとともに、情報閲覧手段１ａ側における操作は、サーバコンピュータ２へアクセスする場合と同様であり、操作手順の変更もない。

図１に示すコンテンツ取得方法をインターネットのような広域のネットワークに適用することで、より大きな効果が得られる。インターネットでは、サーバ２ａは、ＷＷＷサーバであったり、ストリーミングサーバであったりする。情報閲覧手段１ａは、ＷＷＷブラウザが該当する。

以下に、ＨＴＴＰコンテンツを閲覧したり、ストリーミングコンテンツを再生する場合を例にとって、本発明の実施の形態を説明する。ここで、ストリーミングとは、音声や映像などのマルチメディアデータをダウンロードしながら再生するために、時間的に連続して転送されるコンテンツである。なお、ストリーミングのデータは、単位情報に分割されて転送されるが、その単位情報をクリップと呼ぶ。

以下の説明では、基本的なデータ転送方法について先に説明し、その後、ストリーミングコンテンツの同期制御方法を説明する。
図２は、本発明の実施の形態におけるデータ転送機能の構成図である。図のように、ローカルコンピュータ１０とサーバコンピュータ２０とは、インターネット３０を介して接続されている。

ローカルコンピュータ１０には、ＷＷＷブラウザ１１、ストリーミング再生プレイヤー１２、ローカルプロキシィサーバ１３、及び補助記憶装置１４が設けられている。
ＷＷＷブラウザ１１は、ローカルプロキシィサーバ１３を介してサーバコンピュータ２０への要求を出力する。そのために、一般的なＷＷＷブラウザに設けられている、外部のプロキシィサーバの設定機能を用いる。すなわち、ＷＷＷブラウザ１１において、プロキシィサーバの設定を「localhost(IPアドレス＝127.0.0.1)」とする。これにより、ＷＷＷブラウザ１１が動作しているローカルコンピュータ１０内のプロキシィサーバ（ここでは、ローカルプロキシィサーバ１３）が指定され、ＷＷＷブラウザ１１からの要求をローカルプロキシィサーバ１３で中継することができる。

ストリーミング再生プレイヤー１２は、ＷＷＷブラウザ１１からの要求に応じてストリーミングサーバ２２へ要求を出し、返されたストリーミングコンテンツを再生する。
ローカルプロキシィサーバ１３は、ＷＷＷブラウザ１１がサーバコンピュータ２０に対して出力する要求を中継する。そして、サーバコンピュータ２０と補助記憶装置１４との双方から、要求されたコンテンツの制御ファイル１４ａ，２４ａを取得する。取得した制御ファイル１４ａ，２４ａに基づいて、補助記憶装置１４内のストリーミングコンテンツ１４ｃが最新のものであるか否かを判断し、最新のコンテンツであればそのストリーミングコンテンツを補助記憶装置１４から読み出し、そうでなければサーバコンピュータ２０に格納されているストリーミングコンテンツ２４ｂをインターネット３０経由で取得する。

補助記憶装置１４は、CD-ROMのような可搬型の記録媒体と、その媒体のデータの読み取り装置である。記録媒体には、制御ファイル１４ａ、ＨＴＴＰコンテンツ１４ｂ及びストリーミングコンテンツ１４ｃとが格納されている。制御ファイル１４ａは、ＨＴＴＰコンテンツ１４ｂとストリーミングコンテンツ１４ｃとの版数や、元のコンテンツの格納先などの情報を有するファイルである。ＨＴＴＰコンテンツ１４ｂとストリーミングコンテンツ１４ｃとは、サーバコンピュータ２０に格納されているＨＴＴＰコンテンツ２３ｂ、ストリーミングコンテンツ２４ｂを、過去にそのまま複写したものである。

サーバコンピュータ２０には、ＷＷＷサーバ２１とストリーミングサーバ２２とが設けられており、それぞれデータベース２３，２４を有している。データベース２３には、制御ファイル２３ａとＨＴＴＰコンテンツ２３ｂとが格納されており、データベース２４には、制御ファイル２４ａとストリーミングコンテンツ２４ｂが格納されている。

ＷＷＷサーバ２１は、ローカルコンピュータ１０からの要求に応じて、データベース２３内の制御ファイル２３ａやＨＴＴＰコンテンツ２３ｂを返す。ストリーミングサーバ２２は、ローカルコンピュータ１０からの要求に応じてデータベース２４内の制御ファイル２４ａを返すとともに、ローカルコンピュータ１０のストリーミング再生プレイヤー１２からの要求に応じてストリーミングコンテンツ２４ｂを返す。

図３は、本システムのネットワークモデルを示す図である。ローカルコンピュータ１０とサーバコンピュータ２０とが、物理層１５，２５によってインターネット３０に接続されている。物理層１５，２５の上位にインターネット層｛ＩＰ(Internet Protocol) 層｝１６，２６が構築されている。その上位には、トランスポート層１７，１８，２７，２８が構築されている。トランスポート層１７，２７はＴＣＰ(Transmission Control Protocol) 層であり、トランスポート層１８，２８はＵＤＰ(User Datagram-Protocol)層である。

ローカルコンピュータ１０側のＷＷＷブラウザ１１とローカルプロキシィサーバ１３とは、ＴＣＰのトランスポート層１７の上位のアプリケーション層である。ストリーミング再生プレイヤー１２は、ＵＤＰのトランスポート層１８の上位のアプリケーション層である。一方、サーバコンピュータ２０側のＷＷＷサーバ２１はＴＣＰのトランスポート層２７の上位のアプリケーション層であり、ストリーミングサーバ２２はＵＤＰのトランスポート層２８の上位のアプリケーション層である。

ここで、ＷＷＷブラウザ１１とストリーミング再生プレイヤー１２とは、それぞれ対応するサーバとの間でデータの送受信を行う。その基本的な手順を以下に示す。
図４は、クライアントとサーバとの間のデータの流れを示す図である。まず、ＷＷＷブラウザ１１からＷＷＷサーバ２１に対してＴＣＰによりＨＴＴＰ要求（ＧＥＴ，ＰＵＴ等）が発行される。

一般例として「URL=http://fujisan.gmsnet.ro.jp/hylintk/kanda.html」を利用者がＷＷＷブラウザ１１に指定して起動をかけた場合を想定すると、ＷＷＷサーバ２１に対する要求は、「GET http://fujisan.gmsnet.ro.jp/hylintk/kanda.html」となる。

すると、ＷＷＷサーバ２１は、ＨＴＴＰコンテンツ２３ｂの中から要求されたＨＴＭＬファイルを取り出し、そのファイルにヘッダ情報を付加して応答データ４１とする。ＷＷＷサーバ２１は、この応答データ４１をＷＷＷブラウザ１１へ返す。応答データ４１には、以下のような内容が記述される。

図５は、応答データの内容を示す図である。応答データ４１の先頭にヘッダ情報が付加されており、このヘッダ情報に続いてコンテンツの中身がＨＴＭＬで記述されている。ヘッダ情報には、「content-type」によりＭＩＭＥ(Multipurpose Internet Mail Extension)情報が示されている。

ＷＷＷブラウザ１１内には、ＭＩＭＥテーブル１１ａが用意してある。ＭＩＭＥテーブル１１ａには、自分自身で処理できるＭＩＭＥ（ＨＴＭＬ、ＪＰＥＧ、ＧＩＦなど）と、ヘルパーアプリケーション若しくはプラグインアプリケーションで処理できるＭＩＭＥが登録されている。そして、応答データ４１を受け取ったＷＷＷブラウザ１１は、ＭＩＭＥテーブル１１ａにより、自分自身で処置できるか若しくは他のアプリケーションで処理するものであるかの判別を行う。自分自身で処理できるコンテンツであればＷＷＷブラウザ１１自身が処理するが、他のアプリケーションで処理するコンテンツの場合には、対応するプログラムを起動する。起動の際には、プログラムに対してコンテンツの中身をパラメータとして渡す。

ここで、ＷＷＷブラウザ１１からストリーミングコンテンツを要求する場合がある。その場合、利用者からは、「URL=http://fujisan.gmsnet.ro.jp/hylintk/01audio/hylintk1a.ram 」という指定がなされる。このＵＲＬで指定された「hylintk1a.ram 」は、「pnm://fujisan.gmsnet.or.jp/hylintk/01audio/hylintkla.ra 」という中身のメタファイルである。ここでメタファイルとは、ＷＷＷブラウザ１１がストリーミング再生プレイヤー１２を起動するための中間ファイルをいう。その中身には、再生すべきストリーミングコンテンツのＵＲＬが記述されている。このような指定がなされると、ＷＷＷブラウザ１１からＷＷＷサーバ２１に対して、「GET http://fujisan.gmsnet.ro.jp/hylintk/01audio/hylintk1a.ram 」という要求が送られる。この要求に対してＷＷＷサーバ２１は、以下のような応答を返す。

図６は、ストリーミングコンテンツの要求に対する応答データの例を示す図である。この応答データ４１ｂでは、「context-type」として、「audio/x-pn-realaudio」と示されている。

ＷＷＷブラウザ１１は、ＭＩＭＥとして「audio/x-pn-realaudio」を渡されたため、ＭＩＭＥテーブル１１ａを参照し、対応するアプリケーションを探す。そして、該当するアプリケーションを起動する。このとき、ＷＷＷサーバ２１から渡されたコンテンツの中身をパラメータとしてアプリケーションに渡す。この例では、ストリーミング再生プレイヤー１２が起動され、パラメータとして「pnm://fujisan.gmsnet.or.jp/hylintk/01audio/hylintkla.ra 」が渡される。

起動されたストリーミング再生プレイヤー１２は、受け取ったパラメータをＵＲＬとして、ストリーミングサーバ２２にＧＥＴ要求を発行する。ストリーミングサーバ２２は、要求されたコンテンツ４２をクリップ４２ａ〜４２ｃという圧縮されたデータ単位でストリーミング再生プレイヤー１２に送出する。ストリーミング再生プレイヤー１２は、送られたクリップを伸張して、音・映像を再生する。

以上が、サーバコンピュータ２０上のＨＴＴＰコンテンツやストリーミングコンテンツへのアクセス手順である。
ここで、ＨＴＴＰコンテンツ２３ｂやストリーミングコンテンツ２４ｂが、ある程度の長い期間更新する必要のない情報であれば、それらのコンテンツをローカルコンピュータ１０内の補助記憶装置１４に格納させることができる。それには、ＨＴＴＰコンテンツ２３ｂとストリーミングコンテンツ２４ｂとをそのままＣＤ−ＲＯＭに複写する。このとき、ローカルコンピュータ１０用の制御ファイル１４ａもＣＤ−ＲＯＭに格納しておく。そして、作成したＣＤ−ＲＯＭをローカルコンピュータ１０の利用者に配布する。利用者は、配布されたＣＤ−ＲＯＭをローカルコンピュータ１０のＣＤ−ＲＯＭドライブに挿入する。これにより、ローカルコンピュータ１０内に図２に示したような補助記憶装置１４が構成される。

また、サーバコンピュータ２０において、ＨＴＴＰコンテンツ２３ｂ用の制御ファイル２３ａと、ストリーミングコンテンツ２４ｂ用の制御ファイル２４ａとを作成し、それぞれデータベース２３，２４に格納する。

図７は、ローカルコンピュータの制御ファイルの例を示す図である。この例では、制御ファイル１４ａは、統括ファイル１４ａａを中心とした複数のファイルで構成されている。ここで制御ファイル名といった場合には、統括ファイル１４ａａのファイル名を指すものとする。

統括ファイル１４ａａには、そのファイルのバージョンが示されている。その次に、各サーバに対応して「ホスト名」、「ドキュメントベースディレクトリ名」、「サーバ側制御ファイル名」、及び複数の「管理ファイル名一覧ファイル」の組が登録されている。

「ホスト名」には、対応するＩＰアドレスも付加されている。「ドキュメントベースディレクトリ名」は、サーバコンピュータ内でファイルを指定する際の基本となるディレクトリを示している。「サーバ側制御ファイル名」は、サーバコンピュータ側に設けられた制御ファイルの名前を示している。なお、この制御ファイル名は、サーバコンピュータ側の統括ファイルのファイル名が用いられる。

管理ファイル名一覧ファイル１４ａｂは、コンテンツ毎に設けられている。そして、対応するコンテンツ（ＨＴＴＰコンテンツ１４ｂ、ストリーミングコンテンツ１４ｃ）のバージョン、パス（ドキュメントベースディレクトリから該当するファイルが存在するディレクトリまでの経路）、及びファイル名が示されている。ここで、ＨＴＭＬファイルの中でインライン表示する画像などがある場合には、その画像ファイルのパスとファイル名も含まれている。

図８は、サーバコンピュータ側の制御ファイルを示す図である。サーバコンピュータ２０側の制御ファイル２３ａも統括ファイル２３ａａと管理ファイル名一覧ファイル２３ａｂとの集合である。

統括ファイル２３ａａには、そのファイルのバージョンが示されている。その次に、「ホスト名」、複数の「ドキュメントベースディレクトリ名」、及び複数の「管理ファイル名一覧ファイル」の組が登録されている。管理ファイル名一覧ファイル２３ａｂの内容は、ローカルコンピュータ１０側の管理ファイル名一覧ファイル１４ａｂ（図７に示す）と同様である。

ここで、ＷＷＷブラウザ１１から要求が出力された場合の処理手順を説明する。なお、ＷＷＷブラウザからの要求は、「（コマンド） （プロトコル）：／／（ホスト名）／（ベースパス名）／［（パス名／）］ファイル名」という内容である。コンテンツを取得する際のコマンドは「ＧＥＴ」である。また、ＷＷＷサーバ２１へアクセスする際は、プロトコルは「ｈｔｔｐ」と指定され、ストリーミングサーバへアクセスする際は、プロトコルは「ｐｎｍ」と指定される。

図９は、ローカルプロキシィサーバの処理手順を示すフローチャートの前半である。なお、以下の処理は全てローカルプロキシィサーバ１３が行う。
［Ｓ１］以前の処理において保持されていた情報を初期化する。

［Ｓ２］ＷＷＷブラウザ１１から通信要求があるか否かを判断する。要求があればステップＳ３に進み、要求がなければこの処理を繰り返す。
［Ｓ３］記録媒体が読み取り可能状態（ready ）になっているか否かを判断する。読み取り可能であればステップＳ４に進み、読み取り可能でなければステップＳ２２に進む。

［Ｓ４］記録媒体から制御ファイル１４ａを取得する。図７の例では、統括ファイル１４ａａと、管理ファイル名一覧ファイル１４ａｂとを取得する。
［Ｓ５］正常に取得できたか否かを判断する。正常に取得できたらステップＳ６に進み、ファイルが発見できないか若しくは読み取りエラーが発生した場合にはステップＳ２２に進む。

［Ｓ６］取得した制御ファイル１４ａから、ホスト名とドキュメントベースディレクトリ名との組を全て取得する。
［Ｓ７］ローカル側ファイルリストを作成する。具体的には、全ての管理ファイル名一覧ファイル１４ａｂからパス名とファイル名との組を抽出し、それらをリストアップする。

［Ｓ８］ＷＷＷブラウザ１１からの要求に含まれるホスト名が、制御ファイル１４ａに登録されているか否かを判断する。登録されていればステップＳ９に進み、登録されていなければステップＳ２２に進む。

［Ｓ９］ＷＷＷブラウザ１１からの要求に含まれるベースパス名が、ステップＳ８で検出されたホスト名に対応して登録されているドキュメントベースディレクトリ名と一致するか否かを判断する。ベースパス名が一致すればステップＳ１０に進み、一致しなければステップＳ２２に進む。

［Ｓ１０］ローカル側ファイルリストに基づいて、ステップＳ８，Ｓ９で検出されたホスト名とドキュメントベースディレクトリ名との組の下に登録されている全ての管理ファイル名一覧ファイル内のパス名とファイル名とを抽出し、ＷＷＷブラウザ１１からの要求に含まれるパス名とファイル名との組に対応するものが有るか否かを判断する。対応するファイルがあればステップＳ１１に進み、対応するファイルがなければステップＳ２２に進む。

［Ｓ１１］ステップＳ８，Ｓ９で検出されたホスト名とベースパス名との組に対応するサーバ側制御ファイル名を制御ファイル１４ａから抽出し、該当するサーバから制御ファイルを取得する。

図１０は、ローカルプロキシィサーバの処理手順を示すフローチャートの後半である。
［Ｓ１２］サーバ側の制御ファイルが正常に取得できたか否かを判断する。正常に取得できた場合にはステップＳ１３に進み、回線の未接続等によりファイルを取得できなかった場合にはステップＳ１６に進む。

［Ｓ１３］サーバ側の制御ファイルに基づいて、サーバ側ファイルリストを作成する。サーバ側ファイルリストの内容は、そのサーバの管理するコンテンツのパス名とファイル名との組の集合である。

［Ｓ１４］サーバ側ファイルリストに基づいて、ＷＷＷブラウザ１１からの要求に含まれるパス名とファイル名との組に対応するものが有るか否かを判断する。対応するファイルがあればステップＳ１５に進み、対応するファイルがなければステップＳ２２に進む。

［Ｓ１５］ステップＳ１０で検出されたファイルの版数と、ステップＳ１４で検出されたファイルの版数とを比較し、サーバ側ファイルの方が新しいか否かを判断する。サーバ側のファイルの方が新しければステップＳ２２に進み、そうでなければステップＳ１６に進む。

［Ｓ１６］補助記憶装置１４より、該当するファイルを取得する。
［Ｓ１７］正常に取得できたか否かを判断する。正常に取得できた場合にはステップＳ１８に進み、正常に取得できなかった場合にはステップＳ２２に進む。

［Ｓ１８］取得したファイルがメタファイルであるか否かを判断する。メタファイルであればステップＳ１９に進み、メタファイルでなければステップＳ２３に進む。
［Ｓ１９］メタファイル内のホスト名が、制御ファイル１４ａに登録されているか否かを判断する。登録されていればステップＳ２０に進み、登録されていなければステップＳ２３に進む。

［Ｓ２０］メタファイル内のベースパス名が、ステップＳ１９で検出されたホスト名に対応して登録されているベースパス名と一致するか否かを判断する。ベースパス名が一致すればステップＳ２１に進み、一致しなければステップＳ２３に進む。

［Ｓ２１］メタファイルの内容を変換する。具体的には、プロトコルを「file」に変更し、ホスト名とベースパス名とを、補助記憶装置１４を示す名称に変更する。例えば、「pnm://fujisan.gmsnet.or.jp/hylintk/01audio/hylintkla.ra 」というメタファイルの場合、「file:d:/hylintk/01audio/hylintkla.ra」という内容に変更する。この例では、補助記憶装置はローカルコンピュータ１０においてドライブ名「ｄ」として認識されている。この処理が終了後、ステップＳ２３に進む。

なお、ステップＳ２１における変換処理は、アプリケーション層のローカルプロキシィサーバによって要求を中継したために必要となった処理である。従って、アプリケーション層よりも下のレイヤで要求の中継を行えば、ステップＳ２１に示したような変換処理の必要はない。

［Ｓ２２］サーバからコンテンツを取得する。
［Ｓ２３］取得したデータにヘッダ情報を付加してＷＷＷブラウザ１１に返す。
このようにして、補助記憶装置１４に格納されたＨＴＴＰコンテンツ１４ｂやストリーミングコンテンツ１４ｃからコンテンツを取得することができる。なお、ストリーミングコンテンツの場合には、ステップＳ２１でファイル内容を変更したため、以後のストリーミング再生プレイヤー１２からの要求は、全て補助記憶装置１４内のストリーミングコンテンツ１４ｃに対して行われる。これにより、伝送経路の伝送容量の影響を受けずにすみ、高速に読み出すことができる。

しかも、補助記憶装置１４に格納するコンテンツの内容を変更する必要がないため、ローカルコンピュータ１０の利用者に配布するＣＤ−ＲＯＭを容易に作成することができる。さらに、ＷＷＷブラウザ１１を使用している利用者は、目的のコンテンツをサーバから取得する際の手順に従って要求を出力するだけでよいため、利用者の操作性については一切変更がない。

なお、一度取得したコンテンツは、ローカルプロキシィサーバ１３により、キャッシュデータとしてハードディスク装置などのローカルの書き込み可能な記録媒体に記録させることができる。この場合、拡張制御ファイルを生成し、その拡張制御ファイルによりキャッシュしたコンテンツを管理するとともに、統括ファイル１４ａａ内に、拡張制御ファイルまでのパス（ドライブ名も含む）と拡張制御ファイルのファイル名とを登録する。拡張制御ファイルも、統括ファイルと管理ファイル名一覧ファイルとで構成される。このとき生成される統括ファイルと管理ファイル名一覧ファイルとの内容は、サーバ側の制御ファイルを構成するものと同様の内容である。

このように、コンテンツのキャッシングも同時に行うことにより、ネットワーク経由で取得しなければならないデータを、更に削減することができる。
なお、ローカルコンピュータ１０にキャッシングの機能を設けた場合、サーバコンピュータ２０側の最新の情報を一括してダウンロードすることも可能である。それには、ローカル側の制御ファイルとサーバ側の制御ファイルとを取得した際に、対応関係にある全てのコンテンツの版数を比較する。そして、サーバ側のコンテンツの方が新しいと判断された全てのコンテンツを取得し、ローカル側の記録媒体に格納する。これにより、以後、回線未接続の状態でローカルコンピュータ１０を使用する場合にも、ローカルコンピュータ１０で最新のコンテンツを扱うことができる。

さらに、コンテンツのアクセス順番（優先順位）を指定することもできる。このアクセス順番は、ローカル側の制御ファイル内に指定しておく。そして、ローカルプロキシィサーバ１３がＷＷＷブラウザから要求を受け取った際には、指定された順番でコンテンツの存在に有無を確認する。そして、先に検出されたコンテンツをアクセスの対象とする（この場合、版数の比較は行わない）。例えば、「拡張ローカル（書き込み可能な記録媒体にキャッシングされたコンテンツ）→基準ローカル（予めＣＤ−ＲＯＭに格納されているコンテンツ）→サーバ（ネットワーク経由で取得するコンテンツ）」のようなアクセス順番を指定しておけば、サーバコンピュータ２０側の最新の情報を一括してダウンロードすることで、以後のサーバコンピュータ２０へのアクセスが、制御ファイルの取得も含めて不要となる。

また、常に最大値とみなされるスーパーの版数を指定できるようにしてもよい。スーパーの版数は、版数比較が不要であり、その版数が設定されたコンテンツを最優先にアクセスすべきことを意味している。例えば、版数の値が「００」であれば、ローカルプロキシィサーバ１３では、そのコンテンツの版数を最大値とみなすものとする。このようにスーパーの版数を定義することで、複雑な版数管理（サーバ側のコンテンツが定期的に変更される場合、複数の版数のコンテンツが存在し、管理が複雑になる）を行わずに、制御の単純化が可能である。例えば、差分ファイルにスーパーの版数を設定しておけば、常に最新コンテンツとして認識され、コンテンツの管理が容易である。また、コンテンツの優劣を指定するのにも利用できる。例えば、ローカル側のコンテンツをスーパーの版数にしておき、内容はサマリーだけにする。そして、サーバ側には従来通りの版数管理でコンテンツを管理する。

ところで、サーバコンピュータ２０やローカルコンピュータ１０は、プラットホームとなるＯＳ(Operating System)が同一であるとは限らない。プラットフォームが異なると、ディレクトリ名やファイル名の命名規則が異なる。そこで、各プラットフォームで使用可能な命名規則をタイプ別に分類し、各グループにファイルタイプ識別子を設定する。そして、制御ファイル内において、ホスト名に対応してファイルタイプ識別子を登録しておくことで、各ホストで対処可能なディレクトリ名やファイル名を指定できる。

また、異なるサーバ内で同一のベースディレクトリ名を持つことがよくある。この場合、そのまま双方のコンテンツをローカルコンピュータ１０の補助記憶装置に格納しようとすると、格納すべき場所が重複してしまう。そこで、一方のコンテンツは別な場所に格納する。このとき、もともと格納すべきであった場所の位置情報（パス）と実際に格納した場所の位置情報（パス）との対応関係を示す変換情報をローカルコンピュータ１０側の制御ファイルに格納しておく。ローカルプロキシィサーバ１３は、変換情報に基づいて、補助記憶装置内の別の場所に格納されているコンテンツに対して正しくアクセスできる。

例えば、「http://ashitaka.gmsnet.or.jp/r-pro/index.html 」と「http://fujisan.gmsnet.or.jp/r-pro/index.html」とを補助記憶装置に格納する場合、それぞれのコンテンツを、「\r-pro\index.html 」、「\r-pro1\index.html」として格納する。そして、ローカルコンピュータ１０の統括ファイルには、
HOST="ashitaka.gmsnet.or.jp"
BASE(01)="r-pro"
という記載と、
HOST="fujisan.gmsnet.or.jp"
BASE(01)="r-pro"
RENAME="r-pro1"
という記載を含める。ここで、「ＨＯＳＴ」はホスト名を示し、「ＢＡＳＥ」はドキュメントベースディレクトリを示し、「ＲＥＮＡＭＥ」は変換先の位置情報を示している。これより、ローカルプロキシィサーバ１３は、ＷＷＷブラウザから「http://ashitaka.gmsnet.or.jp/r-pro/index.html 」が要求された際には、「\r-pro\index.html 」にアクセスし、「http://fujisan.gmsnet.or.jp/r-pro/index.html」が要求された際には、「\r-pro1\index.html」にアクセスできる。

さらに、ローカルコンピュータ１０に格納すべき情報の作成後に、サーバ側でコンテンツのファイルの位置を移動したり、名前を変更したりして、構造が変化する場合がある。この場合、サーバ側の統括ファイルに、ファイル構造の変更情報を設定しておく。すなわち、変更前のディレクトリ及びファイル名に対して、変更後のディレクトリ及びファイル名とを対応付けておく。これにより、サーバ側の制御ファイルを取得したローカルプロキシィサーバ１３は、構造変更前のファイル情報に基づいて、ローカル側のコンテンツとの間の対応関係が認識でき、構造変更後のファイル情報に基づいて、該当するサーバ側のコンテンツへのアクセスが可能となる。

また、サーバ側の統括ファイルにおいて、特定のファイルに対し、キャッシュデータとして保持することを禁止する旨の設定をすることもできる。このように、キャッシュデータとしての保持を禁止されたファイルをローカルプロキシィサーバ１３が取得すると、そのファイルの内容をＷＷＷブラウザに渡すが、ハードディスク装置には格納しない。これにより、ローカルコンピュータ１０において違法なコピーができないようにすることができる。

また、上記の例では、サーバ側に格納されていたコンテンツの複製をローカルコンピュータ１０の補助記憶装置内に持ってきておく場合について説明したが、必ずしもサーバ側に格納されていたコンテンツの完全な複製である必要はない。例えば、サーバ側には解像度の低い画像データを格納しておき、その画像データに対応する鮮明な画像データをＣＤ−ＲＯＭ等に格納して、ローカルコンピュータ１０のＣＤ−ＲＯＭドライブに挿入しておいてもよい。この場合、ローカルプロキシィサーバ１３は、版数を比較する代わりに画像データの解像度の情報を比較し、解像度の高い方を取得するようにすればよい。これにより、該当するデータがローカルコンピュータ１０に格納されている場合は、高品質のデータを取得し、ネットワーク経由でしか取得できない場合は、低品質のデータを取得する。これにより、ネットワーク経由で画像を参照する際に伝送されるデータ量を低く抑えることができる。

また、補助記憶装置内に対応するコンテンツが存在する限り、必ず補助記憶装置１４から取得するようにすれば、ネットワークを介して取得するデータを更に削減することができる。

次に、ストリーミングコンテンツの同期技術について説明する。本実施の形態は、ストリーミングコンテンツと他のコンテンツ（例えば、静止画像）との同期制御を確実に行うものである。

ここで、従来から行われている同期制御について説明する。同期制御は、ストリーミングコンテンツを再生する際に、その進行状況に応じた画像を画面表示する場合などに用いられる。このとき、ストリーミングコンテンツは、ストリーミングサーバから送信され、画像はＷＷＷサーバから送信される。そのため、これらのデータ間で同期を取る必要がある。

そこで従来は、ストリーミングサーバに同期ファイルを保存しておき、ストリーミング再生プレイヤーがストリーミングコンテンツを再生する際には、対応する同期ファイルをストリーミングサーバから取得する。同期ファイルには、ストリーミングコンテンツの再生を開始した時刻を基準として、どの時間帯にどの画像を開くのかが指定されている。

図１１は、同期ファイルの例を示す図である。図に示したように、ＪＰＥＧの画像ファイルの表示開始時刻と表示終了時刻とが複数設定されている。
このような同期ファイルを取得したストリーミング再生プレイヤーは、同時に取得したストリーミングコンテンツの再生を開始した時刻を基準として、時間監視を行う。そして、ストリーミングコンテンツのクリップの要求・取り出し・再生を行うとともに、同期ファイルに示された開始時刻になると、関連ＵＲＬに基づき、ＷＷＷブラウザにそのコンテンツの表示依頼を行う。ＷＷＷブラウザは、受け取ったＵＲＬに基づいて該当する画像ファイルの要求をＷＷＷサーバへ出力し、対応するコンテンツを受け取る。受け取ったコンテンツは、クライアントコンピュータの表示装置の画面に表示する。

このようにして、ストリーミングコンテンツの再生内容に適合した画像を同期させつつＷＷＷブラウザに表示させることができる。ところが、従来の技術では、ストリーミングコンテンツをいつ再生開始しても、その再生内容が同一であることを前提としていたため、例えば、インターネットを介してライブ放送を行う場合などには適用できなかった。

ここで、ライブ放送とは、「絶対時間帯（例えば平成１０年１月２８日 午後８時から８時３０分まで）の間だけストリーミングコンテンツが配信され、その時間帯内の時刻においてのみ再生することができる」というような、ストリーミングコンテンツの配信形態をいう。なお、ライブ放送には、２通りの実現方法がある。１つめは、予め録音しておいたコンテンツをその時間帯にのみ流す方法である。２つめは、本当の生放送で、現実に収録している音声をその時間帯のみ流す方法である。

１つめの方法でライブ放送を流した場合、ストリーミング再生プレイヤーが同期時間軸の原点を０として処理するために、プレイヤーが立ち上げられた時刻によって、同期して表示される画像にずれが生じる。

図１２は、同期時間軸のずれを説明する図である。図に示すように、正しく同期された時間軸によりストリーミングコンテンツが再生されれば、コンテンツ提供者が意図した時刻に、適当な画像が表示される。例えば、音楽を再生する場合には、この曲調にあわせたイメージ画像が表示される。

ところが、ストリーミングコンテンツを再生する時刻が遅れると、画像を表示する時刻も遅れてしまう。例えば、音楽のライブ放送開始から５分後にストリーミングコンテンツの再生を開始した場合には、音楽は途中から再生されるが、画像などは再生開始時点を基準に表示される。そのため、同期して表示させるべき画像などは、すべて音楽より５分遅れで表示される。

その解決方法として、ストリーミング再生プレイヤーから要求があった際に、ライブ演奏開始からの経過時間Ｔ１を、ストリーミングサーバからローカルコンピュータへ返す方法がある。このような経過時間Ｔ１を受け取ったストリーミング再生プレイヤーでは、自己の時刻からＴ１だけ遡った時刻を基準として、関連ＵＲＬをＷＷＷブラウザに渡す。これにより、ストリーミング再生プレイヤーの再生開始時刻のずれを解消できる。

また、同期制御をストリーミングサーバで行うことによっても、同期ずれを解消可能である。その場合、何らかの方法で、ストリーミングコンテンツのクリップと関連情報とを対応づけてストリーミング再生プレイヤーに渡す必要がある。その一例として、クリップ内に関連ＵＲＬ情報を埋め込む方法がある。このような例を、第１の実施の形態として、以下に説明する。

図１３は、本発明の第１の実施の形態におけるストリーミングコンテンツの同期機能の構成図である。この実施の形態では、第１の実施の形態で説明した技術を用いて、伝送すべきデータ量の削減も図っている。

ローカルコンピュータ５０は、ＷＷＷブラウザ５１、ストリーミング再生プレイヤー５２、ローカルプロキシィサーバ５３、及び補助記憶装置５４を有している。このうち、ＷＷＷブラウザ５１、ローカルプロキシィサーバ５３、及び補助記憶装置５４については、図２で説明した同名の要素と同じ機能を有している。なお、補助記憶装置５４には、静止画像５４ａが予め格納されている。ＨＴＴＰサーバ６０は、ネットワークを介して静止画像６１を提供している。ストリーミングサーバ７０は、ストリーミングコンテンツ７１と、そのコンテンツに対応する同期ファイル７２を有している。同期ファイル７２はストリーミングコンテンツ７１と同じディレクトリに格納され、同期ファイル７２のファイル名は、ストリーミングコンテンツ７１と拡張子が異なるのみである。そのため、ストリーミングコンテンツ７１に対応する同期ファイル７２は、簡単に見つけだすことができる。

このようなシステムにおいて、ローカルコンピュータ５０のＷＷＷブラウザ５１がストリーミングコンテンツ７１を指定したメタファイルを取得すると、ストリーミング再生プレイヤー５２を起動し、メタファイルの内容を渡す。ストリーミング再生プレイヤー５２は、ストリーミングコンテンツ７１を取得するための要求をストリーミングサーバ７０へ出力する。

ストリーミングサーバ７０は、決められた時刻になったら、ストリーミングコンテンツ７１を分割して圧縮データ８１を作成し、その圧縮データ８１と同期させるべき関連ＵＲＬ８２を同期ファイル７２から抽出する。基本的に圧縮データ８１のみをクリップとして、取得要求を出した全てのローカルコンピュータに向けて順次配信する。このとき、ストリーミングサーバ７０は、ストリーミングコンテンツ７１に対応する同期ファイル７２を参照しつつ、コンテンツ送出開始からの時間の管理をしている。そして、同期ファイル７２内の情報で開始時刻として指定された時刻になったら、圧縮データ８１に関連ＵＲＬ８２を結合してクリップ８０を生成し、同期させるコンテンツのＵＲＬを含むクリップ８０をローカルコンピュータ５０へ送出する。

ストリーミングサーバ７０が送出したクリップ８０は、ストリーミング再生プレイヤー５２で受け取られる。ストリーミング再生プレイヤー５２は、クリップ８０内の圧縮データ８１を伸張し再生するとともに、関連ＵＲＬ８２が含まれていた場合には、その関連ＵＲＬ８２をＷＷＷブラウザ５１へ渡す。ＷＷＷブラウザ５１は、関連ＵＲＬ８２の要求をローカルプロキシィサーバ５３へ渡す。ローカルプロキシィサーバ５３は、指定されたＵＲＬの最新の静止画像が補助記憶装置５４に格納されていれば、補助記憶装置５４から静止画像５４ａを取得する。そうでなければＨＴＴＰサーバ６０から静止画像６１を取得する。ローカルプロキシィサーバ５３が取得した静止画像５１ａは、ＷＷＷブラウザ５１に渡され、画面表示される。

このように、ストリーミングサーバ７０が同期ファイル７２を管理し、ストリーミングコンテンツ７１のクリップ内に関連ＵＲＬを含ませることで、ローカルコンピュータ５０から何時ストリーミングコンテンツが要求されようとも、再生内容と関連情報との対応関係がずれることはない。

ところで、予め収録されたコンテンツではなく、生のライブ放送を配信する場合には、スケジュール通りに事が進まないことが多い。従って、予め同期ファイルを作成しておくことはできない。

そこで、生のライブ放送の場合には、ライブの進行状況に応じた静止画像の関連ＵＲＬを随時生成し、圧縮データと結合する。これにより、生のライブ放送であっても正しく同期制御を行うことができる。

このような、生のライブの同期制御技術を用いれば、複数のライブエンコーダコンテンツを集中管理して、全てのコンテンツを同期させながら再生することもできる。
すなわち、従来のようにストリーミングサーバが同期制御機能を有していないと、世界中の各所で演奏される楽器の音をストリーミングサーバで集中管理して生のオーケストラ放送を行う場合、ストリーミングサーバに全てのパケットが集中するため、パケットのぶつかり合いにより、いずれかのパケットには必ず遅延が発生する。オーケストラ演奏の場合、少しでも時間のずれがあると、非常に聞きづらいものとなる。

そこで、第２の実施の形態として、ストリーミングサーバに、コンテンツのバッファリング機能を設けることで、遅延時間の修正を可能とするシステムを説明する。
図１４は、本発明の第２の実施の形態の構成図である。ストリーミングサーバ９０は、複数のライブエンコーダ１１１〜１１３から生演奏の情報を取得し、同期を取りつつ複数のストリーミング再生プレイヤー１２０に配信する。

ライブエンコーダ１１１は、ピアノ１０１の音を収録してストリーミングサーバ９０へ送っている。ライブエンコーダ１１２は、ギター１０２の音を収録してストリーミングサーバ９０へ送っている。ライブエンコーダ１１３は、ドラムス１０３の音を収録してストリーミングサーバ９０へ送っている。

ストリーミングサーバ９０内には予めベース音を録音したファイル９２が格納されている。また、各ライブエンコーダ１１１〜１１３の音は、対応するファイル９３〜９５に一時的に格納される。また、各音源の演奏時間帯を定めたソース制御情報９６が予め設けられている。

ソース制御情報９６のフォーマットは、「ソースＵＲＬ，開始時刻、終了時刻、｛，同期ＵＲＬ｝」である。なお、同期ＵＲＬは、第２の実施の形態で示したように、画像などと同期させる場合に用いる。

図１５は、ソース制御情報の例を示す図である。この例は、全体で３分の演奏を制御するためのソース制御情報９６である。なお、「；」以降の記述は単なるコメントである。
ここで、ストリーミングサーバ９０からは、指揮者が演奏開始を指示したタイミングを原点として時間軸を管理する。そして、各ライブエンコーダ１１１〜１１３から送られるデータを、ファイル９３〜９５でバッファリングし、ソース制御情報に従った開始・終了時刻を調整する。これにより、統合・配信を完全に同期させて実行することができる。

図１６は、図１５のソース制御情報による演奏結果を示す図である。このように、ソース制御情報９６で指定された時刻に演奏が開始され、制定された時刻に終了する。
なお、情報を要求したストリーミング再生プレイヤーの数が多いと、サーバ内で個々のストリーミングデータを管理するオーバヘッドの問題が生じる。その場合、ソース制御情報をストリーミング再生プレイヤーに渡せばよい。ソース制御情報を受け取ったストリーミング再生プレイヤーは、音の合成処理部（ストリーミングサーバの音の合成配信処理部から配信機能を除いたもの）と、各ストリーミングデータをバッファリングするためのファイルを有している必要がある。なお、ストリーミング再生プレイヤーが要求を出力した時点で、すでにライブ演奏が開始されていた場合には、演奏開始からの経過時間をストリーミングサーバからストリーミング再生プレイヤーへ送信する。これにより、再生開始時のずれによる遅延はなくなる。

なお、上記の例は、生演奏のライブ放送の例を示したが、録音済みのストリーミングコンテンツを制御対象とすることも可能である。
また、音のデータがＭＩＤＩ(Musical Instrument Digital Interface)ファイルであれば、音の合成は簡単である。従って、上記実施の形態は、ＭＩＤＩファイルを用いたライブ放送に特に有効な手段である。

また、上記の各コンピュータが有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述させておくことができる。このプログラムをコンピュータで実行することにより、上記処理がコンピュータで実現される。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリ等がある。市場を流通させる場合には、ＣＤ−ＲＯＭやフロッピー（登録商標）ディスク等の可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置等にプログラムを格納しておき、メインメモリにロードして実行する。

実施の形態における基本的なコンテンツ取得方法を示す図である。 本発明の実施の形態におけるデータ転送機能の構成図である。 本システムのネットワークモデルを示す図である。 クライアントとサーバとの間のデータの流れを示す図である。 応答データの内容を示す図である。 ストリーミングコンテンツの要求に対する応答データの例を示す図である。 ローカルコンピュータの制御ファイルの例を示す図である。 サーバコンピュータ側の制御ファイルを示す図である。 ローカルプロキシィサーバの処理手順を示すフローチャートの前半である。 ローカルプロキシィサーバの処理手順を示すフローチャートの後半である。 同期ファイルの例を示す図である。 同期時間軸のずれを説明する図である。 本発明の第１の実施の形態におけるストリーミングコンテンツの同期機能の構成図である。 本発明の第２の実施の形態の構成図である。 ソース制御情報の例を示す図である。 図１５のソース制御情報による演奏結果を示す図である。

符号の説明

１ ローカルコンピュータ
１ａ 情報閲覧手段
１ｂ 複製情報格納手段
１ｂａ ローカル側制御ファイル
１ｂｂ 複製情報
１ｃ 要求中継手段
２ サーバコンピュータ
２ａ サーバ
２ｂ 配信情報格納手段
２ｂａ サーバ側制御ファイル
２ｂｂ 配信情報

Claims (9)

1. ストリーミングサーバからネットワークを介してローカルコンピュータに、分割して配信されるストリーミングコンテンツを管理するストリーミングコンテンツ管理システムにおいて、
   前記ストリーミングサーバは、
   前記ストリーミングコンテンツを分割して分割コンテンツを得て、得た前記分割コンテンツに同期させる関連情報を同期ファイルから抽出して、抽出した前記関連情報を前記分割コンテンツに結合してクリップを得て、得た前記クリップを前記ローカルコンピュータに送信する手段を具備し、
   前記ローカルコンピュータは、
   前記ストリーミングコンテンツの配信を前記ストリーミングサーバに要求し、要求に応じて送付された前記クリップを再生する手段と、
   送付された前記クリップに含まれる関連情報が指し示す関連指示情報が自己の記憶装置にあれば、該記憶装置から前記関連指示情報を取得し、該関連指示情報が他のサーバにあれば、該他のサーバから該関連指示情報を取得する要求中継手段とを具備する、
   ことを特徴とするストリーミングコンテンツ管理システム。
2. 前記関連情報は関連ＵＲＬであり、前記関連指示情報は静止画像であり、前記他のサーバはＨＴＴＰサーバであり、前記要求中継手段はローカルプロキシィサーバであることを特徴とする請求項１記載のストリーミングコンテンツ管理システム。
3. 前記他のサーバは、
   前記関連指示情報、及び該関連指示情報の属性情報が登録されたサーバ側制御ファイルを格納する関連指示情報格納手段を具備し、
   前記ローカルコンピュータは、
   前記関連指示情報格納手段内の前記関連指示情報の複製情報、及び前記複製情報の属性情報が登録されたローカル側制御ファイルを格納する複製情報格納手段を更に具備し、
   前記要求中継手段は、前記サーバ側制御ファイルと前記ローカル側制御ファイルとを取得し、前記関連指示情報の属性情報と前記関連指示情報に対応する前記複製情報の属性情報とを比較し、比較結果に基づいて取得すべき関連指示情報を決定する手段を具備する、
   ことを特徴とする請求項１または２記載のストリーミングコンテンツ管理システム。
4. ストリーミングコンテンツの配信をストリーミングサーバに要求し、要求に応じて、該ストリーミングコンテンツを分割して得られた分割コンテンツと該分割コンテンツに同期させる関連情報とを結合させたクリップが該ストリーミングサーバから送付されると、該クリップを再生する手段と、
   送付された前記クリップに含まれる関連情報が指し示す関連指示情報が自己の記憶装置にあれば、該記憶装置から前記関連指示情報を取得し、該関連指示情報が他のサーバにあれば、該他のサーバから該関連指示情報を取得する要求中継手段と、
   を具備することを特徴とするストリーミングコンテンツ再生コンピュータ。
5. 前記関連情報は関連ＵＲＬであり、前記関連指示情報は静止画像であり、前記他のサーバはＨＴＴＰサーバであり、前記要求中継手段はローカルプロキシィサーバであることを特徴とする請求項４記載のストリーミングコンテンツ再生コンピュータ。
6. 前記他のサーバ内の前記関連指示情報の複製情報、及び前記複製情報の属性情報が登録されたローカル側制御ファイルを格納する複製情報格納手段を更に具備し、
   前記要求中継手段は、前記他のサーバ内の前記関連指示情報及び該関連指示情報の属性情報が登録されたサーバ側制御ファイルと前記ローカル側制御ファイルとを取得し、前記関連指示情報の属性情報と前記関連指示情報に対応する前記複製情報の属性情報とを比較し、比較結果に基づいて取得すべき関連指示情報を決定する手段を具備する、
   ことを特徴とする請求項４または５記載のストリーミングコンテンツ再生コンピュータ。
7. ストリーミングコンテンツ再生コンピュータを、
   ストリーミングコンテンツの配信をストリーミングサーバに要求し、要求に応じて、該ストリーミングコンテンツを分割して得られた分割コンテンツと該分割コンテンツに同期させる関連情報とを結合させたクリップが該ストリーミングサーバから送付されると、該クリップを再生する手段、
   送付された前記クリップに含まれる関連情報が指し示す関連指示情報が自己の記憶装置にあれば、該記憶装置から前記関連指示情報を取得し、該関連指示情報が他のサーバにあれば、該他のサーバから該関連指示情報を取得する要求中継手段、
   として機能させるためのストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体。
8. 前記関連情報は関連ＵＲＬであり、前記関連指示情報は静止画像であり、前記他のサーバはＨＴＴＰサーバであり、前記要求中継手段はローカルプロキシィサーバであることを特徴とする請求項７記載のストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体。
9. 前記他のサーバ内の前記関連指示情報の複製情報、及び前記複製情報の属性情報が登録されたローカル側制御ファイルを格納する複製情報格納手段を更に具備し、
   前記要求中継手段は、前記他のサーバ内の前記関連指示情報及び該関連指示情報の属性情報が登録されたサーバ側制御ファイルと前記ローカル側制御ファイルとを取得し、前記関連指示情報の属性情報と前記関連指示情報に対応する前記複製情報の属性情報とを比較し、比較結果に基づいて取得すべき関連指示情報を決定する手段を具備する、
   ことを特徴とする請求項７または８記載のストリーミングコンテンツ再生プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images