JP3655256B2 - 動画再生制御方法及び動画サーバ - Google Patents
動画再生制御方法及び動画サーバ Download PDFInfo
- Publication number
- JP3655256B2 JP3655256B2 JP2002128742A JP2002128742A JP3655256B2 JP 3655256 B2 JP3655256 B2 JP 3655256B2 JP 2002128742 A JP2002128742 A JP 2002128742A JP 2002128742 A JP2002128742 A JP 2002128742A JP 3655256 B2 JP3655256 B2 JP 3655256B2
- Authority
- JP
- Japan
- Prior art keywords
- moving image
- video
- information
- interrupted
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、動画再生制御方法に係り、特にネットワークを介して複数の利用者から動画再生要求を受ける動画サーバ及び動画再生制御方法に関する。
【０００２】
【従来の技術】
従来よりネットワークを介して複数のユーザに動画再生サービスを行なうビデオサーバ等のシステムが提案もしくは実現されている。この場合に動画を途切れずに再生することは重要なことである。このために、ワーストケースデザインをし、最悪の場合でも動画データの転送が間に合わないことがないように、余裕をもったスケジューリングや伝送を行なう。これは安全ではあるが、システムの性能限界よりも大きく劣った動画データ配信能力に留まる。例えば、動画データの１ストリーム当たりの伝送速度の最大値が１０Ｍｂｐｓでネットワークの伝送容量が１００Ｍｂｐｓであった場合には、安全に供給できるストリーム数は（ネットワークの伝送容量／１ストリーム当たりの最大伝送速度）＝１０となる。しかし、１ストリーム当たりの最大伝送量が１０Ｍｂｐｓと多い場合であっても、１ストリーム当たりの平均伝送量は４Ｍｂｐｓと低い場合が多い。この場合、期待値としては１００Ｍｂｐｓ／４Ｍｂｐｓ＝２５ストリームで伝送できる。
【０００３】
また、ユーザが動画データの再生を要求してから最初の画面が出るまでにある程度時間がかかることがある。このような場合に対し、特開平５−２０７２４７号公報に開示された静止画像情報再生装置では、最初に限り静止画を出してユーザを待たせるようにする技術が開示されている。しかし、上記公報では動画再生途中については述べられていない。
【０００４】
また、同じタイトルに対して時間上でずれて複数の再生要求があった場合に、それらの要求を同期させることにより、より少いストリーム数でサービスが可能となる。例えば、同じ映画の再生を二人の人が１５秒のずれで要求した場合に、二本のビデオストリームをそれぞれに用いるのではなく、先に要求した人の再生を１５秒ずらして二人の要求に対して一本のストリームを用いると資源の節約になる。従来技術としては、先に再生要求した方に対して動画の再生を少し遅くして同期を取るという方法が提案されている。しかし、僅かに再生を遅くすることは技術的に困難である。すなわち、遅くする度合を小さくするとユーザに対して違和感を与えることが少い代わりに再生速度を遅くする期間が長くなる。また逆に再生速度を遅くする度合を高めると、再生速度を遅くする期間を短縮できる代わりに、ユーザに与える違和感が大きくなる。
【０００５】
さらに、動画サーバに障害が生じた場合に、ユーザの画面で配信中のコンテンツの内容とは無関係に動画の再生が中断し、ユーザに不快感を与えるという問題がある。
【０００６】
【発明が解決しようとする課題】
動画サーバーにＭＰＥＧ１やＭＰＥＧ２といった転送（情報）レートの異なる情報が保持され、動画サーバから転送する必要がでてくる。例えば、一つのタイトルであっても、動画の様子に合わせて異なる転送（情報）レートで保持されることも将来は考えられる。
【０００７】
この場合に、動画転送の連続性を保証するためには、最大転送レート時でも転送上にネックがないようにする必要がある。例えば、一部だけＭＰＥＧ２（４Ｍｂｐｓ）でエンコードされているが、その他の部分がＭＰＥＧ１（１．５Ｍｂｐｓ）で保持されているタイトルが複数あるとする。もし、１０Ｍｂｐｓの転送路でこれらを転送しようとすると、１０Ｍｂｐｓを最大転送レートである４Ｍｂｐｓで割った２本のストリームしか流すことができない。これは確実に連続性を保証するという厳しい条件からきた結果である。
【０００８】
しかし、期待値としては、もっと多くのストリームを流す能力があることは明かである。そこで、転送路上の混雑のために転送できなくなった場合に何らかの処置をするようにして、安全確実に送れるストリームよりも多くのストリームを供給することが要求される。
【０００９】
また、従来は時刻のずれた動画再生要求に対しては別々のストリームを割り当てることが一般的に行なわれている。研究室レベルでは先行する動画の再生を遅くして二つの動画を同期させストリーム数を減少させるという提案はある。しかし、現実的に容易な方法でストリーム数を減らす方法は提案されていない。
【００１０】
さらに、動画サーバの障害により動画の配信ができなくなった場合にも、動画の意味とは無関係な切れ目で動画の配信が中断するのではなく、動画の意味的な切れ目で動画の表示を中断することも望まれる。このようにすれば、視聴者に比較的不快感なく、動画の配信を一時中止することができる。
【００１１】
以上のように、動画データを効率の良いスケジューリングによって取り出し、なるべく少いストリームで多くのユーザに動画データを違和感なく提供することが望まれる。
【００１２】
本発明は、上記事情を考慮してなされたものであり、ネットワークを介して複数のユーザに動画再生サービスを行なうシステムにおいて、過負荷時、障害時、同一タイトルの複数ユーザ読みだし時に、ユーザに違和感を与えることを少くして、伝送効率を最大限に引き上げることのできる動画再生制御方法及び動画サーバを提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、複数のシーンからなる動画情報が複数記憶されている記憶装置から要求された動画情報を読みだして再生するための動画再生制御方法において、動画サーバ内に、前記動画情報における各々の隣接シーン間の切れ目に相当する位置の情報を記録しておき、前記動画サーバは、動画再生をとぎれさせると判断された場合には、前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断することを特徴とする。
【００１４】
本発明によれば、配信されるべき動画データには意味的切れ目のデータが付与されており、端末側で動画の連続再生が困難であると動画サーバが判断した場合に、次の意味の切れ目で動画の配信を中断する。これにより、ユーザにとって、動画の表示が中断されても意味的な切れ目までは見ることができる。
【００１５】
好ましくは、前記動画サーバは、前記切れ目に相当する位置の各々を対象として、当該切れ目に相当する位置よりもオーバーヘッド時間以前の時点で、前記動画再生をとぎれさせるか否かを判断し、動画再生をとぎれさせると判断された場合には、当該対象となった前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断するようにしてもよい。
【００１６】
好ましくは、前記動画サーバは、前記動画再生をとぎれさせると判断されたために、前記動画の配信を一時中断した場合には、該動画の配信に使用していた通信資源を一旦解放するようにしてもよい。
【００１７】
好ましくは、前記動画サーバは、動画情報が保持されている記憶装置からのデータ読みだしが集中し近い将来にスケジューリングができなくなることが予想された場合、ネットワークや回線のトラフィックを監視しトラフィック量が一定値を越えた場合、もしくは動画サーバ内で瞬時に回復できないと予測される障害の発生が検出された場合に、当該動画読みだし要求に対して、または複数の端末から同一の動画情報に対する読みだし要求があり且つ要求のあった時刻のずれが小さい場合に先行する動画読みだし要求に対して、次の前記切れ目に相当する位置までで動画の配信を中断し、端末においては次の意味的な切れ目の位置で再生を中断すると判断するようにしてもよい。
この構成では、動画配信の中断を判断する機能を提供する。すなわち、
（ａ）動画データが保持されている記憶装置からのデータの読みだしが集中し近い将来にスケジューリングができなくなることが予想された時、
（ｂ）ネットワークや回線のトラフィックを監視しトラフィック量が一定値を超えた時、
（ｃ）動画サーバ内で瞬時に回復できないような障害が生じた場合を検出した場合に、
（ｄ）複数の端末から同一の動画データへの読みだし要求があり、かつ両者の時刻のずれが小さい場合には先行する動画読みだし要求に対して、
動画の配信を中断する判断をする。これにより、動画の配信を中断すべき場合が明らかになる。
【００１８】
好ましくは、動画再生を一時中断した場合に端末に表示させるべき別画像を予め用意しておき、動画再生を中断させた直後から、前記予め用意してあった別画像を端末に表示させるようにしてもよい。
この構成では、動画の配信が中断した後に、それまでに配信しようとしていた動画に代わって別情報をユーザに表示する。代替情報としては、動画サーバ内の動画が格納されている記憶装置とは別の記憶装置からのデータを代わりに伝送してユーザに表示したり、端末内の記憶装置に格納されたデータを表示する。これにより、本来ユーザが要求した動画の表示サービスが中断しても、ユーザに別情報を提供することにより、ユーザを飽きさせずに待たせることができる。
【００１９】
好ましくは、前記読みだし要求に応じて動画を配信すると端末での動画再生が中断される可能性がある場合には、使用料金を割り引く、もしくは動画を一時中断した回数や時間に応じて使用料金を割り引くようにしてもよい。
この構成では、端末が直接要求した動画情報ではなく別情報が表示された場合には、その回数と時間とを端末ごとに記録しておき、その結果をサービス料金に反映させる。これにより、サービス低下に対して埋め合わせをすることで、より合理的なサービスの提供を行なうことができる。
【００２０】
好ましくは、動画を端末に配信するのに用いるネットワークに障害が生じたかもしくはネットワーク容量を超えたことにより情報が伝送できない場合には、予め取り決められた別の伝送路を用いて動画が表示されないことについての情報を該端末に提供するようにしてもよい。
この構成では、動画サーバ内の障害ではなく、動画を配信するネットワークに障害が生じたり、ネットワークが容量を超過し、ネットワークの容量が超過したという情報さえも流せなくなった場合には、電話線や電波（地上波、衛星波など）を用いて動画が端末に表示されない状態説明、理由、修復にかかる時間などの情報を端末に表示する。この場合には、単にテキスト形式で伝送されたものを表示してもよいし、符号化されて送られて来た情報が指示する端末内部に格納されたデータ（動画、静止画、音声、テキストなど）を表示しても良い。このように動画が表示されなくなったときに直ちに説明を行うことにより視聴者に安心感を与える。
【００２１】
また、本発明に係る動画サーバは、複数のシーンからなる動画情報を複数記憶するための記憶手段と、前記動画情報における各々の隣接シーン間の切れ目に相当する位置の情報を記録するための手段と、端末から動画情報の読みだし要求を受けた場合に、前記記憶手段から要求された動画情報を読みだして配信するための手段と、動画再生をとぎれさせるか否か判断するための手段と、この手段により動画再生をとぎれさせると判断された場合に、前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断させるための手段とを備えたことを特徴とする。
【００２２】
好ましくは、前記動画再生をとぎれさせると判断されたために、前記動画の配信を一時中断した場合には、該動画の配信に使用していた通信資源を一旦解放するようにしてもよい。
【００２３】
好ましくは、動画情報が保持されている記憶装置からのデータ読みだしが集中し近い将来にスケジューリングができなくなることが予想された場合、ネットワークや回線のトラフィックを監視しトラフィック量が一定値を越えた場合、もしくは動画サーバ内で瞬時に回復できないと予測される障害の発生が検出された場合に、当該動画読みだし要求に対して、または複数の端末から同一の動画情報に対する読みだし要求があり且つ要求のあった時刻のずれが小さい場合に先行する動画読みだし要求に対して、次の前記切れ目に相当する位置までで動画の配信を中断するようにしてもよい。
【００２４】
また、本発明は、意味的な切れ目の情報の付与された動画データを格納する記憶装置と、別情報を保持する記憶装置と、ネットワークや回線のトラフィックを監視し、かつ前記動画データへのアクセスをスケジューリングし、かつ複数の端末から同一の動画データを読みだしていることを認知しそのずれ時間を管理し、かつ動画情報を取り出して伝送し要求に応じて意味の切れ目で再生を中断し、かつデータの入力先や出力先を切替え制御し、かつ端末側に端末内の記憶装置に格納されている情報を表示することを指示する制御部と、動画情報を伝送できるネットワークや回線を通して複数の端末と、動画を表示する端末内の装置と、端末内の記憶装置と、別情報が挿入された回数と時間とを端末ごとに集計する装置とからなる。
【００２５】
なお、請求項１，４，５の発明の構成をすべて備えた場合、以下のような作用効果を得ることができる。
（ａ）ネットワークのトラフィックがあらかじめ決められた値を超え、動画の配信が不可能となる可能性が高いと予測された場合に、動画のサービスを意味的な切れ目で動画サーバでの送信および端末での表示を中断し、ネットワークのトラフィックが下るまで、端末にあらかじめ保持されたデータ（動画、静止画、テキスト）を用いてユーザを飽きさせずに待たせる。
（ｂ）動画データが保持されている記憶装置からのデータの読みだしが集中し近い将来にスケジューリングができなくなることが予想された時に、動画のサービスを意味的な切れ目で動画サーバでの送信および端末での表示を中断し、記憶装置への読みだしの集中が緩和されるまで、動画サーバ内のアクセス集中を起こしていない別の記憶装置に格納されたデータを代わりに配信して端末に表示したり、端末にあらかじめ保持されたデータ（動画、静止画、テキスト）を用いてユーザを待たせる。
（ｃ）動画サーバ内で瞬時に回復できないような障害（再試行では回復できず、復旧に時間を要するような障害）が生じた場合を検出した場合に、障害が生じていない部位にあるデータおよび通進路を用いて、ユーザに情報（別の動画、静止画、音声、テキスト）を提供し、ユーザを待たせない。この別情報では障害の原因や復旧にかかると思われる予測時間も表示する。
（ｄ）複数の端末から同一の動画データへの読みだし要求があり、かつ両者の時刻のずれが小さい場合には、先行する動画読みだし要求に対して、別情報を伝送することにより時刻揃えを行ない、複数の端末に対して一本のストリームで動画データを伝送する。これにより少ないストリーム数でより多くのユーザに動画データが配信可能となる。
【００２６】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２７】
図１は、本実施形態の動画再生システムの概略構成を示すブロック図である。また、図２に動画配信を中断する際の動画サーバでの処理の流れの概略を、図３に動画配信が中断される際の端末での処理の流れの概略をそれぞれ示す。
【００２８】
本実施形態の動画再生システムは、動画サーバ１０１、複数の端末１０２、ネットワーク１０３からなる。
【００２９】
動画サーバ１０１は、制御部１０５、第１の記憶装置１０４、第２の制御部１０６を備えている。第１の記憶装置１０４には、ユーザの要求に応じて配信する動画データが格納される。第２の制御部１０６には、後述する用に、ユーザの要求した動画の代りに所定時間だけ伝送する別情報を格納する。
【００３０】
端末１０２は、表示部１０７、第３の記憶装置１０８を備えている。
【００３１】
動画サーバ１０１は、複数の端末１０２とネットワーク１０３を介して接続されており、ユーザからの要求に対して、第１の記憶装置１０４から動画データを取り出し、制御部１０５を介してネットワーク１０３にデータを伝送する。動画データを要求した端末１０２は、動画サーバ１０１からネットワーク１０３経由で伝送されたデータを受信し、表示部１０７に動画を再生する。
【００３２】
本実施形態では、動画サーバ１０１の第１の記憶装置１０４に保持された動画データには、動画の意味的な切れ目に印が付けられている。切れ目と切れ目の間はシーンと呼ぶ。切れ目のデータは、動画データに直接付与されていてもよいし、補助情報として別のデータとして保持されていてもよい。後者の場合には、記憶装置１０４に保持されていても記憶装置１０６に保持されていてもよい。
【００３３】
この意味的な動画データの切れ目は、各種オーサリングツールによって人手で指示してもよいし、自動シーン切り出し技術を利用してもよい。
【００３４】
ただし、シーンの途中（すなわち印が付けられた切れ目と切れ目の間）で転送レートは変動してはならないものとし（変動する場合には、その最大値をそのシーとにおける転送レートとする）、システムは事前に転送レート情報を得られるものとする。
【００３５】
制御部１０５は、記憶装置１０４を制御しており、複数の端末からの動画要求に対して記憶装置１０４からデータを取り出す。この複数要求に対するデータの取り出しのスケジューリングも制御部１０５で行なう。制御部１０５は、例えば要求の過度の集中や障害により、全ての動画読み込み要求に答えるスケジューリングが不可能と判断した場合には、スケジューリングに失敗した動画再生を遅らせる必要がある。また、制御部１０５は、ネットワーク１０３のトラフィックを監視しており、トラフィックが多すぎて伝送が追い付かないような場合にも、動画再生を遅らせる必要がある。例えば、ネットワークの伝送容量を１ストリーム当たりの平均伝送容量で割った値のストリーム数の８０％くらいのストリームを通常供給しておき、トラフィックがネットワーク容量の９５％を超えたところでネットワークが容量オーバーするという予測を立てて、優先度の低いストリームのサービスを中断する。優先度は、ストリーム固有に当初から割り当てられている値と、その時までにサービスが中断された回数および時間の情報から決められる。
【００３６】
前者のスケジューリングに関する原因により動画再生を遅らせる必要があることが事前に判明した場合には（ステップＳ１１）、遅らせる必要がある動画データについて最も近い意味的な切れ目の位置まで再生を続け（ステップＳ１２，Ｓ２２）、次にスケジューリング可能となるまで、制御部１０５は記憶装置１０６に保持された別情報を取り出してネットワーク１０３を介して送出する。もしくは、制御部１０５は、ネットワーク１０３を介して、端末１０２の記憶装置１０８に対して代わりにデータを表示部１０７に送出するように指示する（ステップＳ１３，Ｓ２３）。
【００３７】
ここで、代わりに伝送する別情報は、コマーシャル（お知らせ）、あるいは視聴者を飽きさせないようなクイズ、ゲーム、応募情報などであるとする。なお、コマーシャルを代替情報として用いる場合には、物理的な事情により伝送が困難な場合でなくても、コマーシャルを動画提供者がプログラムに従って提供できるようになる。すなわち、視聴者の嗜好に合わせた内容のコマーシャルを予め設定された頻度で動画の意味的な切れ目の場所に自動挿入させることができる。また、現在動画の配信が中断された理由や障害時の現状説明や復旧予測時間などを表示できるようにする。また、障害発生時に何も情報が得られない場合には、単に端末内に格納されている動画データを繰り返し再生することもある。このようにすることにより、希望の動画が表示されない場合に、視聴者はその原因を知る可能性が高まる。
【００３８】
後者のトラフィックに関する原因により動画再生を送らせる必要があることが事前に判明した場合には（ステップＳ１１）、遅らせる必要がある動画データについて最も近い意味的な切れ目の位置まで再生を続け（ステップＳ１２，Ｓ２２）、ネットワークのトラフィックに空き容量ができるまで、制御部１０５はネットワーク１０３を介して端末１０２の記憶装置１０８にデータを代わりに表示部１０７に送出するように指示する（ステップＳ１３，Ｓ２３）。
【００３９】
このように、動画の伝送が中断された場合には、動画の伝送が中断された原因となった問題がなくなった段階で再び当初要求された動画の伝送を再開する（ステップＳ１４，Ｓ２４）。
【００４０】
また、複数の端末から同一の動画について伝送要求があり、しかもそれらの時間のずれが少い場合もある。そのような場合には、要求の数だけのストリームを用いて動画データを伝送するのではなく、要求の数よりも少いストリームを割り当てられれば資源の節約になる。そこで、先行する動画ストリームに対して、意味的な切れ目で要求動画の再生を中断し、複数の動画ストリームを同期させて割り当てるストリーム数を節約する。ここで、中断する時間が一度に長くなりすぎないように、適度に中断時間を分割して視聴者に違和感を与えないように再生する。例えば、二つの動画再生要求に三分の差があった場合、先行する動画ストリームの一度の意味の切れ目で三分の代替データを伝送するのではなく、例えば、一分の代替データを三回の意味的な切れ目に分けて伝送する。
【００４１】
ところで、代替情報を挿入することはサービスの質（ＱＯＳ）を下げることになる。従って、このような場合、ユーザに不利益を与えないようにサービスの対価を設定するのが好ましい。第一の方法として、ユーザに予め代替情報が入る可能性があってもよいか否かの選択をさせ、それに従って料金を設定する。この場合には、代替情報が入ってもよいとしたユーザに対しては、実際に代替情報が入っても入らなくても同一の料金とする。もう一つの方法は、より厳密な方法であり、代替情報が入った回数や時間を端末ごとに記録しておき、その量によって料金を割り引く方法である。
【００４２】
また、動画サーバ内の障害ではなく、動画を配信するネットワークに障害が生じたり、ネットワークが容量を超過し、ネットワークの容量が超過したという情報さえも流せなくなった場合には、電話線や電波（地上波、衛星波など）を用いて動画が端末に表示されない状態説明、理由、修復にかかる時間などの情報を端末に表示すると良い。この場合には、単にテキスト形式で伝送されたものを表示してもよいし、符号化されて送られて来た情報が指示する端末内部に格納されたデータ（動画、静止画、音声、テキストなど）を表示しても良い。このように動画が表示されなくなったときに直ちに説明を行うことにより視聴者に安心感を与えることができる。
【００４３】
以下では、新しいストリームが転送要求をした場合の処理およびシーンの変わり目での処理について夫々説明する。
【００４４】
転送レートは、情報を送るレートであり、リアルタイムに情報を送っているならば、転送レートと情報圧縮レートは等しい。情報圧縮レートは、アナログ動画情報をデジタル動画情報に変換するときに指定するものである。従って、エンコード時に指定した情報圧縮レートが転送レートとなる。このため、転送レートは既知情報である。
【００４５】
ここでは、簡単のために情報圧縮レートとして、基本圧縮率の整数倍の圧縮レートを用いるとする。例えば、ＭＰＥＧ１の一般的な圧縮レートである１．５Ｍｂｐｓを基本として、３Ｍｂｐｓ，４．５Ｍｂｐｓ，６Ｍｂｐｓ，．．．を用いるとする。このように転送レートは、基本転送レートの整数倍の値をとるものとする。
【００４６】
また、全転送容量が１５Ｍｂｐｓである場合には、１．５Ｍｂｐｓが１０本通せることになる。１．５Ｍｂｐｓを１スロットとすると、全転送路には１０スロットがあることになる。例えば、４．５Ｍｂｐｓの情報を転送するには、３スロットを必要とすることになる。
【００４７】
図４に、一つのタイトル中で転送レート（動画情報圧縮率）が異なる動画の一例を示す。シーン０，１，４はスロットを一つだけ用い、シーン２，３では３スロットを用い、シーン５ではスロットを２つ用いる。
【００４８】
以下、動画を受け付け、転送するアルゴリズムについて説明する。ここでの転送は、記憶装置１０４から制御部１０５への転送時にも、またネットワーク１０３を介した転送時にも用いることができる。
【００４９】
本実施形態では、転送中であったが、必要なスロット資源が取れなくなった場合には、そのストリームは空スロット待ち行列につながれる。「変数ｓ」は、現在使用しているスロット数である。次に空スロット待ち行列につなぐ予定のストリームには、マークがつけられる。マークがつけられているストリームの数は、「変数ｍａｒｋ」によって管理されている。
【００５０】
新しいストリームが転送要求をした場合には、図５に示される処理がなされる。まず、空スロット待ちのストリームが既にあるかどうかを調べる（ステップＳ３０１）。もしあれば、新たなストリームを流すことはできない。
【００５１】
空スロット待ちのストリームがなければ、現在の空スロット数があらかじめ決められたＮという定数よりも多いかどうかを調べる（ステップＳ３０２）。もし充分な空スロットがなければ、新しいストリームを転送しないことにする。
【００５２】
充分な空スロットがあれば、変数ｓに必要スロット数を加えて、変数ｓを更新する（ステップＳ３０３）。そして新しいストリームを空スロットに割り付ける（ステップＳ３０４）。
【００５３】
ここで、新しいストリームを転送開始できなかった場合には、一定の時間をおいて再度この処理を実行する。
【００５４】
次に、シーンの変わり目での処理を図６および図７のフローチャートを用いて説明する。
【００５５】
シーンの変わり目がどこにあるかは既知情報であるので、シーンの変わり目よりもスケジューリングオーバーヘッドにあたる時間以前の時点で図６および図７の処理を行なう。言い換えると、シーンの切れ目の位置でのスケジューリングに間に合うように図６および図７の判断処理を行なう。なお、ストリームの終了時の処理も同様に図６および図７のルーチンを用いる。ただし、この場合には、必要なスロット数が０に変更になったものとして扱う。
【００５６】
このアルゴリズムは、ストリームがシーンの切れ目に到達したときに、そのストリームを空スロット待ち行列に入れるか否か（すなわちそのストリームに割り当てられたスロットを解放するか否か）、また空スロット待ちストリームがあった場合にそれらにスロットを割り付けるかどうかを決める。現在転送されているストリームが空スロット待ちになるかどうかは、関数ｆによって決まり、空スロット待ちストリームが空スロット待ち行列のどの位置で待つかは関数ｇによって決まる。
【００５７】
まず、自ストリームにマーク（中断すべきストリームにはマークが付けられる）がつけられているかどうかを判断する（ステップＳ４０１）。ここで、自ストリームにマークがつけられているならば、空スロット待ち行列は空ではないことになる。ただし、反対に、自ストリームにマークがついていなかったからといって、空スロット待ち行列が空であるとは限らない。
【００５８】
もし自ストリームにマークがつけられているならば（ステップＳ４０１）、そのストリームは中断されるべきであるのでスロット資源を解放する必要がある。その処理をステップＳ４０２〜Ｓ４０９で行なう。
【００５９】
自ストリームを関数ｇの値に従って空スロット待ち行列につなぐ（ステップＳ４０２）。ここで、関数ｇ（ｔ，ｄ）は、二つの引数ｔとｇを持つ。ｔはそのストリームが空スロット待ち行列に入ってからの滞留時間（滞留時間の総和ではなく現在の滞留時間である）を表し、引数ｄは過去最近Ｔ時間以内における空スロット待ち行列に滞留している時間比である。ｄの値が高いと確率的に長い時間、空スロット待ち状態にあることを意味する。関数ｇ（ｔ，ｄ）はｔとｄの偏微分に対して正の値を取る。例えば、ｇ（ｔ，ｄ）＝ａ＊ｔ＊ｔ＋ｂ＊ｄ（ａとｂは適当な正の定数）である。
【００６０】
空スロット待ち行列内で、このｇ（ｔ，ｄ）の値の高い順にソートして並べる。この特殊形がＦＩＦＯであり、この場合にはｇ（ｔ，ｄ）＝ｔとなる。しかし、この単純形のように単にｔの値だけを用いた評価尺度ではなく、過去の実績ｄも含めた評価尺度の方がより公平なストリームへの資源割り当てとなる。ただし、空スロット待ち行列の先頭のストリームに対しては順位を変更しない。なぜならば、先頭ストリームは次に資源を割り当てられるべきストリームとして決められているからである。
【００６１】
次に、ステップＳ４０３で、占有していたスロットを解放し、現在使用されているスロット数ｓを更新する。
【００６２】
また、マークがつけられたストリームが一つ空スロット待ち行列に入ったので、変数ｍａｒｋをデクリメントする（ステップＳ４０４）。
【００６３】
この結果、変数ｍａｒｋが０になったら（ステップＳ４０５）、空スロット待ち行列の先頭のストリームにスロット資源を割り当て、スロット数ｓを更新し（ステップＳ４０６）、そのストリームを空スロット待ち行列から外して活性化させる（ステップＳ４０７）。
【００６４】
もしステップＳ４０５で変数ｍａｒｋが０にならなければ、空スロット待ち行列の先頭ストリームが動き出すのにはまだ充分な空スロットがないので、それ以上は何もしないで処理を終了する。
【００６５】
次に、ステップＳ４０５の判断で変数ｍａｒｋが０となり、空スロット待ち行列の先頭ストリームを空スロット待ち行列から取り除いた結果、空スロット待ち行列がまだ空でなければ（ステップＳ４０８）、空スロット待ち行列の先頭のストリームを活性化するために次に休止させるべきストリームを関数ｆに従って決める（ステップＳ４０９）。関数ｆ（ｔ，ｄ）は、二つの引数ｔとｄを持つ。引数ｔは、次のシーンの切れ目までの時間である。引数ｄは、前述のように、過去最近Ｔ時間以内における空スロット待ち行列に滞留している時間比である。ｄの値が高いと確率的に長い時間、空スロット待ち状態にあることを意味する。関数ｇ（ｔ，ｄ）は、ｔとｄの偏微分に対して正の値を取る。例えば、ｆ（ｔ，ｄ）＝ｃ＊ｔ＋ｅ＊ｄ（ｃとｅは適当な正の定数）である。
【００６６】
実際に転送中のストリームの中で、このｆ値の低いストリームから順に、空ストリーム待ち行列の先頭のストリームが必要とするスロット数に達するまで、ストリームにマークを付ける。そして、変数ｍａｒｋもマークを付けたストリームの数に設定する。
【００６７】
もしステップＳ４０８で空スロット待ち行列が空であれば、処理を終了する。
【００６８】
一方、自ストリームにマークがつけられていない場合には（ステップＳ４０１）、転送レートが変わるかどうかを判定する（ステップＳ４１０）。これはストリームに付与された転送（圧縮）レート情報をみればわかる。もし転送レートが変わらない場合には、何もせずに処理を終了させる。
【００６９】
必要ストリーム数が減る場合には、不要となったストリームを解放し、現使用ストリーム数ｓを更新する（ステップＳ４１１）。
【００７０】
転送レートが増加する場合には（ステップＳ４１０）、スロット資源を新たに獲得する必要がある。もし、すでに空スロット待ち行列で空スロットを待っているストリームがなく、かつ、現在未使用のスロットが充分あるならば（ステップＳ４１２）、必要なスロットを獲得し、現使用スロット数を更新する（ステップＳ４１３）。自ストリームは、新たな転送レートで転送を継続することができる。
【００７１】
もし、空スロット待ち行列が空でなかったり、資源が充分にないならば（ステップＳ４１４）、自ストリームは空スロット待ち行列につなぎ（ステップＳ４１４）、占有していたスロット資源を解放する（ステップＳ４１５）。ステップＳ４１４で空スロット待ち行列に自ストリームをつなぐときには、ステップＳ４０２で述べたアルゴリズムを用いる。ステップＳ４１５では自ストリームが占有していたスロット資源を解放し、現使用スロット数ｓを更新する。
【００７２】
その後、空スロット待ち行列が空であるかどうかを調べ（ステップＳ４１６）、空であれば処理を終了する。もし空でなければ、ステップＳ４０９で述べた手順に従ってマークのつけ直しを行なう（ステップＳ４１７）。この結果、マークがついているものがなくなれば（ステップＳ４１８）、空スロット待ちの先頭のストリームは資源を獲得できたことを意味するので、ステップＳ４０６からの処理を行なう。もしステップＳ４１８で変数ｍａｒｋが０にならなければ、空スロット待ち行列の先頭ストリームが動き出すのにはまだ充分な空スロットがないので、それ以上は何もしないで処理を終了する。本発明は、上述した実施形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【００７３】
【発明の効果】
以上に説明したように、本発明によれば、過負荷時、障害時、同一タイトルを複数端末から要求があった場合にも、効率の良い動画データの伝送サービスを行なうことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る動画再生システムの概略構成を示すブロック図
【図２】動画配信を中断する際の動画サーバでの処理の流れを示すフローチャート
【図３】動画配信が中断される際の端末での処理の流れを示すフローチャート
【図４】一つのタイトル中で転送レート（動画情報圧縮率）が異なる例を説明するための図
【図５】新しいストリームが転送要求をした場合の処理を示すフローチャート
【図６】シーンの変わり目での処理を示すフローチャート
【図７】シーンの変わり目での処理を示すフローチャート
【符号の説明】
１０１…動画サーバ
１０２…端末
１０３…ネットワーク
１０４，１０６，１０８…記憶装置
１０５…制御部
１０７…表示部
【発明の属する技術分野】
本発明は、動画再生制御方法に係り、特にネットワークを介して複数の利用者から動画再生要求を受ける動画サーバ及び動画再生制御方法に関する。
【０００２】
【従来の技術】
従来よりネットワークを介して複数のユーザに動画再生サービスを行なうビデオサーバ等のシステムが提案もしくは実現されている。この場合に動画を途切れずに再生することは重要なことである。このために、ワーストケースデザインをし、最悪の場合でも動画データの転送が間に合わないことがないように、余裕をもったスケジューリングや伝送を行なう。これは安全ではあるが、システムの性能限界よりも大きく劣った動画データ配信能力に留まる。例えば、動画データの１ストリーム当たりの伝送速度の最大値が１０Ｍｂｐｓでネットワークの伝送容量が１００Ｍｂｐｓであった場合には、安全に供給できるストリーム数は（ネットワークの伝送容量／１ストリーム当たりの最大伝送速度）＝１０となる。しかし、１ストリーム当たりの最大伝送量が１０Ｍｂｐｓと多い場合であっても、１ストリーム当たりの平均伝送量は４Ｍｂｐｓと低い場合が多い。この場合、期待値としては１００Ｍｂｐｓ／４Ｍｂｐｓ＝２５ストリームで伝送できる。
【０００３】
また、ユーザが動画データの再生を要求してから最初の画面が出るまでにある程度時間がかかることがある。このような場合に対し、特開平５−２０７２４７号公報に開示された静止画像情報再生装置では、最初に限り静止画を出してユーザを待たせるようにする技術が開示されている。しかし、上記公報では動画再生途中については述べられていない。
【０００４】
また、同じタイトルに対して時間上でずれて複数の再生要求があった場合に、それらの要求を同期させることにより、より少いストリーム数でサービスが可能となる。例えば、同じ映画の再生を二人の人が１５秒のずれで要求した場合に、二本のビデオストリームをそれぞれに用いるのではなく、先に要求した人の再生を１５秒ずらして二人の要求に対して一本のストリームを用いると資源の節約になる。従来技術としては、先に再生要求した方に対して動画の再生を少し遅くして同期を取るという方法が提案されている。しかし、僅かに再生を遅くすることは技術的に困難である。すなわち、遅くする度合を小さくするとユーザに対して違和感を与えることが少い代わりに再生速度を遅くする期間が長くなる。また逆に再生速度を遅くする度合を高めると、再生速度を遅くする期間を短縮できる代わりに、ユーザに与える違和感が大きくなる。
【０００５】
さらに、動画サーバに障害が生じた場合に、ユーザの画面で配信中のコンテンツの内容とは無関係に動画の再生が中断し、ユーザに不快感を与えるという問題がある。
【０００６】
【発明が解決しようとする課題】
動画サーバーにＭＰＥＧ１やＭＰＥＧ２といった転送（情報）レートの異なる情報が保持され、動画サーバから転送する必要がでてくる。例えば、一つのタイトルであっても、動画の様子に合わせて異なる転送（情報）レートで保持されることも将来は考えられる。
【０００７】
この場合に、動画転送の連続性を保証するためには、最大転送レート時でも転送上にネックがないようにする必要がある。例えば、一部だけＭＰＥＧ２（４Ｍｂｐｓ）でエンコードされているが、その他の部分がＭＰＥＧ１（１．５Ｍｂｐｓ）で保持されているタイトルが複数あるとする。もし、１０Ｍｂｐｓの転送路でこれらを転送しようとすると、１０Ｍｂｐｓを最大転送レートである４Ｍｂｐｓで割った２本のストリームしか流すことができない。これは確実に連続性を保証するという厳しい条件からきた結果である。
【０００８】
しかし、期待値としては、もっと多くのストリームを流す能力があることは明かである。そこで、転送路上の混雑のために転送できなくなった場合に何らかの処置をするようにして、安全確実に送れるストリームよりも多くのストリームを供給することが要求される。
【０００９】
また、従来は時刻のずれた動画再生要求に対しては別々のストリームを割り当てることが一般的に行なわれている。研究室レベルでは先行する動画の再生を遅くして二つの動画を同期させストリーム数を減少させるという提案はある。しかし、現実的に容易な方法でストリーム数を減らす方法は提案されていない。
【００１０】
さらに、動画サーバの障害により動画の配信ができなくなった場合にも、動画の意味とは無関係な切れ目で動画の配信が中断するのではなく、動画の意味的な切れ目で動画の表示を中断することも望まれる。このようにすれば、視聴者に比較的不快感なく、動画の配信を一時中止することができる。
【００１１】
以上のように、動画データを効率の良いスケジューリングによって取り出し、なるべく少いストリームで多くのユーザに動画データを違和感なく提供することが望まれる。
【００１２】
本発明は、上記事情を考慮してなされたものであり、ネットワークを介して複数のユーザに動画再生サービスを行なうシステムにおいて、過負荷時、障害時、同一タイトルの複数ユーザ読みだし時に、ユーザに違和感を与えることを少くして、伝送効率を最大限に引き上げることのできる動画再生制御方法及び動画サーバを提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、複数のシーンからなる動画情報が複数記憶されている記憶装置から要求された動画情報を読みだして再生するための動画再生制御方法において、動画サーバ内に、前記動画情報における各々の隣接シーン間の切れ目に相当する位置の情報を記録しておき、前記動画サーバは、動画再生をとぎれさせると判断された場合には、前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断することを特徴とする。
【００１４】
本発明によれば、配信されるべき動画データには意味的切れ目のデータが付与されており、端末側で動画の連続再生が困難であると動画サーバが判断した場合に、次の意味の切れ目で動画の配信を中断する。これにより、ユーザにとって、動画の表示が中断されても意味的な切れ目までは見ることができる。
【００１５】
好ましくは、前記動画サーバは、前記切れ目に相当する位置の各々を対象として、当該切れ目に相当する位置よりもオーバーヘッド時間以前の時点で、前記動画再生をとぎれさせるか否かを判断し、動画再生をとぎれさせると判断された場合には、当該対象となった前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断するようにしてもよい。
【００１６】
好ましくは、前記動画サーバは、前記動画再生をとぎれさせると判断されたために、前記動画の配信を一時中断した場合には、該動画の配信に使用していた通信資源を一旦解放するようにしてもよい。
【００１７】
好ましくは、前記動画サーバは、動画情報が保持されている記憶装置からのデータ読みだしが集中し近い将来にスケジューリングができなくなることが予想された場合、ネットワークや回線のトラフィックを監視しトラフィック量が一定値を越えた場合、もしくは動画サーバ内で瞬時に回復できないと予測される障害の発生が検出された場合に、当該動画読みだし要求に対して、または複数の端末から同一の動画情報に対する読みだし要求があり且つ要求のあった時刻のずれが小さい場合に先行する動画読みだし要求に対して、次の前記切れ目に相当する位置までで動画の配信を中断し、端末においては次の意味的な切れ目の位置で再生を中断すると判断するようにしてもよい。
この構成では、動画配信の中断を判断する機能を提供する。すなわち、
（ａ）動画データが保持されている記憶装置からのデータの読みだしが集中し近い将来にスケジューリングができなくなることが予想された時、
（ｂ）ネットワークや回線のトラフィックを監視しトラフィック量が一定値を超えた時、
（ｃ）動画サーバ内で瞬時に回復できないような障害が生じた場合を検出した場合に、
（ｄ）複数の端末から同一の動画データへの読みだし要求があり、かつ両者の時刻のずれが小さい場合には先行する動画読みだし要求に対して、
動画の配信を中断する判断をする。これにより、動画の配信を中断すべき場合が明らかになる。
【００１８】
好ましくは、動画再生を一時中断した場合に端末に表示させるべき別画像を予め用意しておき、動画再生を中断させた直後から、前記予め用意してあった別画像を端末に表示させるようにしてもよい。
この構成では、動画の配信が中断した後に、それまでに配信しようとしていた動画に代わって別情報をユーザに表示する。代替情報としては、動画サーバ内の動画が格納されている記憶装置とは別の記憶装置からのデータを代わりに伝送してユーザに表示したり、端末内の記憶装置に格納されたデータを表示する。これにより、本来ユーザが要求した動画の表示サービスが中断しても、ユーザに別情報を提供することにより、ユーザを飽きさせずに待たせることができる。
【００１９】
好ましくは、前記読みだし要求に応じて動画を配信すると端末での動画再生が中断される可能性がある場合には、使用料金を割り引く、もしくは動画を一時中断した回数や時間に応じて使用料金を割り引くようにしてもよい。
この構成では、端末が直接要求した動画情報ではなく別情報が表示された場合には、その回数と時間とを端末ごとに記録しておき、その結果をサービス料金に反映させる。これにより、サービス低下に対して埋め合わせをすることで、より合理的なサービスの提供を行なうことができる。
【００２０】
好ましくは、動画を端末に配信するのに用いるネットワークに障害が生じたかもしくはネットワーク容量を超えたことにより情報が伝送できない場合には、予め取り決められた別の伝送路を用いて動画が表示されないことについての情報を該端末に提供するようにしてもよい。
この構成では、動画サーバ内の障害ではなく、動画を配信するネットワークに障害が生じたり、ネットワークが容量を超過し、ネットワークの容量が超過したという情報さえも流せなくなった場合には、電話線や電波（地上波、衛星波など）を用いて動画が端末に表示されない状態説明、理由、修復にかかる時間などの情報を端末に表示する。この場合には、単にテキスト形式で伝送されたものを表示してもよいし、符号化されて送られて来た情報が指示する端末内部に格納されたデータ（動画、静止画、音声、テキストなど）を表示しても良い。このように動画が表示されなくなったときに直ちに説明を行うことにより視聴者に安心感を与える。
【００２１】
また、本発明に係る動画サーバは、複数のシーンからなる動画情報を複数記憶するための記憶手段と、前記動画情報における各々の隣接シーン間の切れ目に相当する位置の情報を記録するための手段と、端末から動画情報の読みだし要求を受けた場合に、前記記憶手段から要求された動画情報を読みだして配信するための手段と、動画再生をとぎれさせるか否か判断するための手段と、この手段により動画再生をとぎれさせると判断された場合に、前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断させるための手段とを備えたことを特徴とする。
【００２２】
好ましくは、前記動画再生をとぎれさせると判断されたために、前記動画の配信を一時中断した場合には、該動画の配信に使用していた通信資源を一旦解放するようにしてもよい。
【００２３】
好ましくは、動画情報が保持されている記憶装置からのデータ読みだしが集中し近い将来にスケジューリングができなくなることが予想された場合、ネットワークや回線のトラフィックを監視しトラフィック量が一定値を越えた場合、もしくは動画サーバ内で瞬時に回復できないと予測される障害の発生が検出された場合に、当該動画読みだし要求に対して、または複数の端末から同一の動画情報に対する読みだし要求があり且つ要求のあった時刻のずれが小さい場合に先行する動画読みだし要求に対して、次の前記切れ目に相当する位置までで動画の配信を中断するようにしてもよい。
【００２４】
また、本発明は、意味的な切れ目の情報の付与された動画データを格納する記憶装置と、別情報を保持する記憶装置と、ネットワークや回線のトラフィックを監視し、かつ前記動画データへのアクセスをスケジューリングし、かつ複数の端末から同一の動画データを読みだしていることを認知しそのずれ時間を管理し、かつ動画情報を取り出して伝送し要求に応じて意味の切れ目で再生を中断し、かつデータの入力先や出力先を切替え制御し、かつ端末側に端末内の記憶装置に格納されている情報を表示することを指示する制御部と、動画情報を伝送できるネットワークや回線を通して複数の端末と、動画を表示する端末内の装置と、端末内の記憶装置と、別情報が挿入された回数と時間とを端末ごとに集計する装置とからなる。
【００２５】
なお、請求項１，４，５の発明の構成をすべて備えた場合、以下のような作用効果を得ることができる。
（ａ）ネットワークのトラフィックがあらかじめ決められた値を超え、動画の配信が不可能となる可能性が高いと予測された場合に、動画のサービスを意味的な切れ目で動画サーバでの送信および端末での表示を中断し、ネットワークのトラフィックが下るまで、端末にあらかじめ保持されたデータ（動画、静止画、テキスト）を用いてユーザを飽きさせずに待たせる。
（ｂ）動画データが保持されている記憶装置からのデータの読みだしが集中し近い将来にスケジューリングができなくなることが予想された時に、動画のサービスを意味的な切れ目で動画サーバでの送信および端末での表示を中断し、記憶装置への読みだしの集中が緩和されるまで、動画サーバ内のアクセス集中を起こしていない別の記憶装置に格納されたデータを代わりに配信して端末に表示したり、端末にあらかじめ保持されたデータ（動画、静止画、テキスト）を用いてユーザを待たせる。
（ｃ）動画サーバ内で瞬時に回復できないような障害（再試行では回復できず、復旧に時間を要するような障害）が生じた場合を検出した場合に、障害が生じていない部位にあるデータおよび通進路を用いて、ユーザに情報（別の動画、静止画、音声、テキスト）を提供し、ユーザを待たせない。この別情報では障害の原因や復旧にかかると思われる予測時間も表示する。
（ｄ）複数の端末から同一の動画データへの読みだし要求があり、かつ両者の時刻のずれが小さい場合には、先行する動画読みだし要求に対して、別情報を伝送することにより時刻揃えを行ない、複数の端末に対して一本のストリームで動画データを伝送する。これにより少ないストリーム数でより多くのユーザに動画データが配信可能となる。
【００２６】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２７】
図１は、本実施形態の動画再生システムの概略構成を示すブロック図である。また、図２に動画配信を中断する際の動画サーバでの処理の流れの概略を、図３に動画配信が中断される際の端末での処理の流れの概略をそれぞれ示す。
【００２８】
本実施形態の動画再生システムは、動画サーバ１０１、複数の端末１０２、ネットワーク１０３からなる。
【００２９】
動画サーバ１０１は、制御部１０５、第１の記憶装置１０４、第２の制御部１０６を備えている。第１の記憶装置１０４には、ユーザの要求に応じて配信する動画データが格納される。第２の制御部１０６には、後述する用に、ユーザの要求した動画の代りに所定時間だけ伝送する別情報を格納する。
【００３０】
端末１０２は、表示部１０７、第３の記憶装置１０８を備えている。
【００３１】
動画サーバ１０１は、複数の端末１０２とネットワーク１０３を介して接続されており、ユーザからの要求に対して、第１の記憶装置１０４から動画データを取り出し、制御部１０５を介してネットワーク１０３にデータを伝送する。動画データを要求した端末１０２は、動画サーバ１０１からネットワーク１０３経由で伝送されたデータを受信し、表示部１０７に動画を再生する。
【００３２】
本実施形態では、動画サーバ１０１の第１の記憶装置１０４に保持された動画データには、動画の意味的な切れ目に印が付けられている。切れ目と切れ目の間はシーンと呼ぶ。切れ目のデータは、動画データに直接付与されていてもよいし、補助情報として別のデータとして保持されていてもよい。後者の場合には、記憶装置１０４に保持されていても記憶装置１０６に保持されていてもよい。
【００３３】
この意味的な動画データの切れ目は、各種オーサリングツールによって人手で指示してもよいし、自動シーン切り出し技術を利用してもよい。
【００３４】
ただし、シーンの途中（すなわち印が付けられた切れ目と切れ目の間）で転送レートは変動してはならないものとし（変動する場合には、その最大値をそのシーとにおける転送レートとする）、システムは事前に転送レート情報を得られるものとする。
【００３５】
制御部１０５は、記憶装置１０４を制御しており、複数の端末からの動画要求に対して記憶装置１０４からデータを取り出す。この複数要求に対するデータの取り出しのスケジューリングも制御部１０５で行なう。制御部１０５は、例えば要求の過度の集中や障害により、全ての動画読み込み要求に答えるスケジューリングが不可能と判断した場合には、スケジューリングに失敗した動画再生を遅らせる必要がある。また、制御部１０５は、ネットワーク１０３のトラフィックを監視しており、トラフィックが多すぎて伝送が追い付かないような場合にも、動画再生を遅らせる必要がある。例えば、ネットワークの伝送容量を１ストリーム当たりの平均伝送容量で割った値のストリーム数の８０％くらいのストリームを通常供給しておき、トラフィックがネットワーク容量の９５％を超えたところでネットワークが容量オーバーするという予測を立てて、優先度の低いストリームのサービスを中断する。優先度は、ストリーム固有に当初から割り当てられている値と、その時までにサービスが中断された回数および時間の情報から決められる。
【００３６】
前者のスケジューリングに関する原因により動画再生を遅らせる必要があることが事前に判明した場合には（ステップＳ１１）、遅らせる必要がある動画データについて最も近い意味的な切れ目の位置まで再生を続け（ステップＳ１２，Ｓ２２）、次にスケジューリング可能となるまで、制御部１０５は記憶装置１０６に保持された別情報を取り出してネットワーク１０３を介して送出する。もしくは、制御部１０５は、ネットワーク１０３を介して、端末１０２の記憶装置１０８に対して代わりにデータを表示部１０７に送出するように指示する（ステップＳ１３，Ｓ２３）。
【００３７】
ここで、代わりに伝送する別情報は、コマーシャル（お知らせ）、あるいは視聴者を飽きさせないようなクイズ、ゲーム、応募情報などであるとする。なお、コマーシャルを代替情報として用いる場合には、物理的な事情により伝送が困難な場合でなくても、コマーシャルを動画提供者がプログラムに従って提供できるようになる。すなわち、視聴者の嗜好に合わせた内容のコマーシャルを予め設定された頻度で動画の意味的な切れ目の場所に自動挿入させることができる。また、現在動画の配信が中断された理由や障害時の現状説明や復旧予測時間などを表示できるようにする。また、障害発生時に何も情報が得られない場合には、単に端末内に格納されている動画データを繰り返し再生することもある。このようにすることにより、希望の動画が表示されない場合に、視聴者はその原因を知る可能性が高まる。
【００３８】
後者のトラフィックに関する原因により動画再生を送らせる必要があることが事前に判明した場合には（ステップＳ１１）、遅らせる必要がある動画データについて最も近い意味的な切れ目の位置まで再生を続け（ステップＳ１２，Ｓ２２）、ネットワークのトラフィックに空き容量ができるまで、制御部１０５はネットワーク１０３を介して端末１０２の記憶装置１０８にデータを代わりに表示部１０７に送出するように指示する（ステップＳ１３，Ｓ２３）。
【００３９】
このように、動画の伝送が中断された場合には、動画の伝送が中断された原因となった問題がなくなった段階で再び当初要求された動画の伝送を再開する（ステップＳ１４，Ｓ２４）。
【００４０】
また、複数の端末から同一の動画について伝送要求があり、しかもそれらの時間のずれが少い場合もある。そのような場合には、要求の数だけのストリームを用いて動画データを伝送するのではなく、要求の数よりも少いストリームを割り当てられれば資源の節約になる。そこで、先行する動画ストリームに対して、意味的な切れ目で要求動画の再生を中断し、複数の動画ストリームを同期させて割り当てるストリーム数を節約する。ここで、中断する時間が一度に長くなりすぎないように、適度に中断時間を分割して視聴者に違和感を与えないように再生する。例えば、二つの動画再生要求に三分の差があった場合、先行する動画ストリームの一度の意味の切れ目で三分の代替データを伝送するのではなく、例えば、一分の代替データを三回の意味的な切れ目に分けて伝送する。
【００４１】
ところで、代替情報を挿入することはサービスの質（ＱＯＳ）を下げることになる。従って、このような場合、ユーザに不利益を与えないようにサービスの対価を設定するのが好ましい。第一の方法として、ユーザに予め代替情報が入る可能性があってもよいか否かの選択をさせ、それに従って料金を設定する。この場合には、代替情報が入ってもよいとしたユーザに対しては、実際に代替情報が入っても入らなくても同一の料金とする。もう一つの方法は、より厳密な方法であり、代替情報が入った回数や時間を端末ごとに記録しておき、その量によって料金を割り引く方法である。
【００４２】
また、動画サーバ内の障害ではなく、動画を配信するネットワークに障害が生じたり、ネットワークが容量を超過し、ネットワークの容量が超過したという情報さえも流せなくなった場合には、電話線や電波（地上波、衛星波など）を用いて動画が端末に表示されない状態説明、理由、修復にかかる時間などの情報を端末に表示すると良い。この場合には、単にテキスト形式で伝送されたものを表示してもよいし、符号化されて送られて来た情報が指示する端末内部に格納されたデータ（動画、静止画、音声、テキストなど）を表示しても良い。このように動画が表示されなくなったときに直ちに説明を行うことにより視聴者に安心感を与えることができる。
【００４３】
以下では、新しいストリームが転送要求をした場合の処理およびシーンの変わり目での処理について夫々説明する。
【００４４】
転送レートは、情報を送るレートであり、リアルタイムに情報を送っているならば、転送レートと情報圧縮レートは等しい。情報圧縮レートは、アナログ動画情報をデジタル動画情報に変換するときに指定するものである。従って、エンコード時に指定した情報圧縮レートが転送レートとなる。このため、転送レートは既知情報である。
【００４５】
ここでは、簡単のために情報圧縮レートとして、基本圧縮率の整数倍の圧縮レートを用いるとする。例えば、ＭＰＥＧ１の一般的な圧縮レートである１．５Ｍｂｐｓを基本として、３Ｍｂｐｓ，４．５Ｍｂｐｓ，６Ｍｂｐｓ，．．．を用いるとする。このように転送レートは、基本転送レートの整数倍の値をとるものとする。
【００４６】
また、全転送容量が１５Ｍｂｐｓである場合には、１．５Ｍｂｐｓが１０本通せることになる。１．５Ｍｂｐｓを１スロットとすると、全転送路には１０スロットがあることになる。例えば、４．５Ｍｂｐｓの情報を転送するには、３スロットを必要とすることになる。
【００４７】
図４に、一つのタイトル中で転送レート（動画情報圧縮率）が異なる動画の一例を示す。シーン０，１，４はスロットを一つだけ用い、シーン２，３では３スロットを用い、シーン５ではスロットを２つ用いる。
【００４８】
以下、動画を受け付け、転送するアルゴリズムについて説明する。ここでの転送は、記憶装置１０４から制御部１０５への転送時にも、またネットワーク１０３を介した転送時にも用いることができる。
【００４９】
本実施形態では、転送中であったが、必要なスロット資源が取れなくなった場合には、そのストリームは空スロット待ち行列につながれる。「変数ｓ」は、現在使用しているスロット数である。次に空スロット待ち行列につなぐ予定のストリームには、マークがつけられる。マークがつけられているストリームの数は、「変数ｍａｒｋ」によって管理されている。
【００５０】
新しいストリームが転送要求をした場合には、図５に示される処理がなされる。まず、空スロット待ちのストリームが既にあるかどうかを調べる（ステップＳ３０１）。もしあれば、新たなストリームを流すことはできない。
【００５１】
空スロット待ちのストリームがなければ、現在の空スロット数があらかじめ決められたＮという定数よりも多いかどうかを調べる（ステップＳ３０２）。もし充分な空スロットがなければ、新しいストリームを転送しないことにする。
【００５２】
充分な空スロットがあれば、変数ｓに必要スロット数を加えて、変数ｓを更新する（ステップＳ３０３）。そして新しいストリームを空スロットに割り付ける（ステップＳ３０４）。
【００５３】
ここで、新しいストリームを転送開始できなかった場合には、一定の時間をおいて再度この処理を実行する。
【００５４】
次に、シーンの変わり目での処理を図６および図７のフローチャートを用いて説明する。
【００５５】
シーンの変わり目がどこにあるかは既知情報であるので、シーンの変わり目よりもスケジューリングオーバーヘッドにあたる時間以前の時点で図６および図７の処理を行なう。言い換えると、シーンの切れ目の位置でのスケジューリングに間に合うように図６および図７の判断処理を行なう。なお、ストリームの終了時の処理も同様に図６および図７のルーチンを用いる。ただし、この場合には、必要なスロット数が０に変更になったものとして扱う。
【００５６】
このアルゴリズムは、ストリームがシーンの切れ目に到達したときに、そのストリームを空スロット待ち行列に入れるか否か（すなわちそのストリームに割り当てられたスロットを解放するか否か）、また空スロット待ちストリームがあった場合にそれらにスロットを割り付けるかどうかを決める。現在転送されているストリームが空スロット待ちになるかどうかは、関数ｆによって決まり、空スロット待ちストリームが空スロット待ち行列のどの位置で待つかは関数ｇによって決まる。
【００５７】
まず、自ストリームにマーク（中断すべきストリームにはマークが付けられる）がつけられているかどうかを判断する（ステップＳ４０１）。ここで、自ストリームにマークがつけられているならば、空スロット待ち行列は空ではないことになる。ただし、反対に、自ストリームにマークがついていなかったからといって、空スロット待ち行列が空であるとは限らない。
【００５８】
もし自ストリームにマークがつけられているならば（ステップＳ４０１）、そのストリームは中断されるべきであるのでスロット資源を解放する必要がある。その処理をステップＳ４０２〜Ｓ４０９で行なう。
【００５９】
自ストリームを関数ｇの値に従って空スロット待ち行列につなぐ（ステップＳ４０２）。ここで、関数ｇ（ｔ，ｄ）は、二つの引数ｔとｇを持つ。ｔはそのストリームが空スロット待ち行列に入ってからの滞留時間（滞留時間の総和ではなく現在の滞留時間である）を表し、引数ｄは過去最近Ｔ時間以内における空スロット待ち行列に滞留している時間比である。ｄの値が高いと確率的に長い時間、空スロット待ち状態にあることを意味する。関数ｇ（ｔ，ｄ）はｔとｄの偏微分に対して正の値を取る。例えば、ｇ（ｔ，ｄ）＝ａ＊ｔ＊ｔ＋ｂ＊ｄ（ａとｂは適当な正の定数）である。
【００６０】
空スロット待ち行列内で、このｇ（ｔ，ｄ）の値の高い順にソートして並べる。この特殊形がＦＩＦＯであり、この場合にはｇ（ｔ，ｄ）＝ｔとなる。しかし、この単純形のように単にｔの値だけを用いた評価尺度ではなく、過去の実績ｄも含めた評価尺度の方がより公平なストリームへの資源割り当てとなる。ただし、空スロット待ち行列の先頭のストリームに対しては順位を変更しない。なぜならば、先頭ストリームは次に資源を割り当てられるべきストリームとして決められているからである。
【００６１】
次に、ステップＳ４０３で、占有していたスロットを解放し、現在使用されているスロット数ｓを更新する。
【００６２】
また、マークがつけられたストリームが一つ空スロット待ち行列に入ったので、変数ｍａｒｋをデクリメントする（ステップＳ４０４）。
【００６３】
この結果、変数ｍａｒｋが０になったら（ステップＳ４０５）、空スロット待ち行列の先頭のストリームにスロット資源を割り当て、スロット数ｓを更新し（ステップＳ４０６）、そのストリームを空スロット待ち行列から外して活性化させる（ステップＳ４０７）。
【００６４】
もしステップＳ４０５で変数ｍａｒｋが０にならなければ、空スロット待ち行列の先頭ストリームが動き出すのにはまだ充分な空スロットがないので、それ以上は何もしないで処理を終了する。
【００６５】
次に、ステップＳ４０５の判断で変数ｍａｒｋが０となり、空スロット待ち行列の先頭ストリームを空スロット待ち行列から取り除いた結果、空スロット待ち行列がまだ空でなければ（ステップＳ４０８）、空スロット待ち行列の先頭のストリームを活性化するために次に休止させるべきストリームを関数ｆに従って決める（ステップＳ４０９）。関数ｆ（ｔ，ｄ）は、二つの引数ｔとｄを持つ。引数ｔは、次のシーンの切れ目までの時間である。引数ｄは、前述のように、過去最近Ｔ時間以内における空スロット待ち行列に滞留している時間比である。ｄの値が高いと確率的に長い時間、空スロット待ち状態にあることを意味する。関数ｇ（ｔ，ｄ）は、ｔとｄの偏微分に対して正の値を取る。例えば、ｆ（ｔ，ｄ）＝ｃ＊ｔ＋ｅ＊ｄ（ｃとｅは適当な正の定数）である。
【００６６】
実際に転送中のストリームの中で、このｆ値の低いストリームから順に、空ストリーム待ち行列の先頭のストリームが必要とするスロット数に達するまで、ストリームにマークを付ける。そして、変数ｍａｒｋもマークを付けたストリームの数に設定する。
【００６７】
もしステップＳ４０８で空スロット待ち行列が空であれば、処理を終了する。
【００６８】
一方、自ストリームにマークがつけられていない場合には（ステップＳ４０１）、転送レートが変わるかどうかを判定する（ステップＳ４１０）。これはストリームに付与された転送（圧縮）レート情報をみればわかる。もし転送レートが変わらない場合には、何もせずに処理を終了させる。
【００６９】
必要ストリーム数が減る場合には、不要となったストリームを解放し、現使用ストリーム数ｓを更新する（ステップＳ４１１）。
【００７０】
転送レートが増加する場合には（ステップＳ４１０）、スロット資源を新たに獲得する必要がある。もし、すでに空スロット待ち行列で空スロットを待っているストリームがなく、かつ、現在未使用のスロットが充分あるならば（ステップＳ４１２）、必要なスロットを獲得し、現使用スロット数を更新する（ステップＳ４１３）。自ストリームは、新たな転送レートで転送を継続することができる。
【００７１】
もし、空スロット待ち行列が空でなかったり、資源が充分にないならば（ステップＳ４１４）、自ストリームは空スロット待ち行列につなぎ（ステップＳ４１４）、占有していたスロット資源を解放する（ステップＳ４１５）。ステップＳ４１４で空スロット待ち行列に自ストリームをつなぐときには、ステップＳ４０２で述べたアルゴリズムを用いる。ステップＳ４１５では自ストリームが占有していたスロット資源を解放し、現使用スロット数ｓを更新する。
【００７２】
その後、空スロット待ち行列が空であるかどうかを調べ（ステップＳ４１６）、空であれば処理を終了する。もし空でなければ、ステップＳ４０９で述べた手順に従ってマークのつけ直しを行なう（ステップＳ４１７）。この結果、マークがついているものがなくなれば（ステップＳ４１８）、空スロット待ちの先頭のストリームは資源を獲得できたことを意味するので、ステップＳ４０６からの処理を行なう。もしステップＳ４１８で変数ｍａｒｋが０にならなければ、空スロット待ち行列の先頭ストリームが動き出すのにはまだ充分な空スロットがないので、それ以上は何もしないで処理を終了する。本発明は、上述した実施形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【００７３】
【発明の効果】
以上に説明したように、本発明によれば、過負荷時、障害時、同一タイトルを複数端末から要求があった場合にも、効率の良い動画データの伝送サービスを行なうことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る動画再生システムの概略構成を示すブロック図
【図２】動画配信を中断する際の動画サーバでの処理の流れを示すフローチャート
【図３】動画配信が中断される際の端末での処理の流れを示すフローチャート
【図４】一つのタイトル中で転送レート（動画情報圧縮率）が異なる例を説明するための図
【図５】新しいストリームが転送要求をした場合の処理を示すフローチャート
【図６】シーンの変わり目での処理を示すフローチャート
【図７】シーンの変わり目での処理を示すフローチャート
【符号の説明】
１０１…動画サーバ
１０２…端末
１０３…ネットワーク
１０４，１０６，１０８…記憶装置
１０５…制御部
１０７…表示部
Claims (10)
- 複数のシーンからなる動画情報が複数記憶されている記憶装置から要求された動画情報を読みだして再生するための動画再生制御方法において、
動画サーバ内に、前記動画情報における各々の隣接シーン間の切れ目に相当する位置の情報を記録しておき、
前記動画サーバは、動画再生をとぎれさせると判断された場合には、前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断することを特徴とする動画再生制御方法。 - 前記動画サーバは、前記切れ目に相当する位置の各々を対象として、当該切れ目に相当する位置よりもオーバーヘッド時間以前の時点で、前記動画再生をとぎれさせるか否かを判断し、動画再生をとぎれさせると判断された場合には、当該対象となった前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断することを特徴とする請求項１に記載の動画再生制御方法。
- 前記動画サーバは、前記動画再生をとぎれさせると判断されたために、前記動画の配信を一時中断した場合には、該動画の配信に使用していた通信資源を一旦解放することを特徴とする請求項１に記載の動画再生制御方法。
- 前記動画サーバは、動画情報が保持されている記憶装置からのデータ読みだしが集中し近い将来にスケジューリングができなくなることが予想された場合、ネットワークや回線のトラフィックを監視しトラフィック量が一定値を越えた場合、もしくは動画サーバ内で瞬時に回復できないと予測される障害の発生が検出された場合に、当該動画読みだし要求に対して、または複数の端末から同一の動画情報に対する読みだし要求があり且つ要求のあった時刻のずれが小さい場合に先行する動画読みだし要求に対して、次の前記切れ目に相当する位置までで動画の配信を中断し、端末においては次の前記切れ目に相当する位置で再生を中断すると判断することを特徴とする請求項１に記載の動画再生制御方法。
- 動画再生を一時中断した場合に端末に表示させるべき別画像を予め用意しておき、動画再生を中断させた直後から、前記予め用意してあった別画像を端末に表示させることを特徴とする請求項１に記載の動画再生制御方法。
- 前記読みだし要求に応じて動画を配信すると端末での動画再生が中断される可能性がある場合には、使用料金を割り引く、もしくは動画を一時中断した回数や時間に応じて使用料金を割り引くことを特徴とする請求項１に記載の動画再生制御方法。
- 動画を端末に配信するのに用いるネットワークに障害が生じたかもしくはネットワーク容量を超えたことにより情報が伝送できない場合には、予め取り決められた別の伝送路を用いて動画が表示されないことについての情報を該端末に提供することを特徴とする請求項１に記載の動画再生制御方法。
- 複数のシーンからなる動画情報を複数記憶するための記憶手段と、
前記動画情報における各々の隣接シーン間の切れ目に相当する位置の情報を記録するための手段と、
端末から動画情報の読みだし要求を受けた場合に、前記記憶手段から要求された動画情報を読みだして配信するための手段と、
動画再生をとぎれさせるか否か判断するための手段と、
この手段により動画再生をとぎれさせると判断された場合に、前記切れ目に相当する位置まで動画を配信し続けた後に、動画の配信を一時中断させるための手段とを備えたことを特徴とする動画サーバ。 - 前記動画再生をとぎれさせると判断されたために、前記動画の配信を一時中断した場合には、該動画の配信に使用していた通信資源を一旦解放することを特徴とする請求項８に記載の動画サーバ。
- 動画情報が保持されている記憶装置からのデータ読みだしが集中し近い将来にスケジューリングができなくなることが予想された場合、ネットワークや回線のトラフィックを監視しトラフィック量が一定値を越えた場合、もしくは動画サーバ内で瞬時に回復できないと予測される障害の発生が検出された場合に、当該動画読みだし要求に対して、または複数の端末から同一の動画情報に対する読みだし要求があり且つ要求のあった時刻のずれが小さい場合に先行する動画読みだし要求に対して、次の前記切れ目に相当する位置までで動画の配信を中断することを特徴とする請求項８に記載の動画サーバ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002128742A JP3655256B2 (ja) | 2002-04-30 | 2002-04-30 | 動画再生制御方法及び動画サーバ |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002128742A JP3655256B2 (ja) | 2002-04-30 | 2002-04-30 | 動画再生制御方法及び動画サーバ |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP23440895A Division JP3320595B2 (ja) | 1995-09-12 | 1995-09-12 | 動画再生制御方法及び動画サーバ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003037821A JP2003037821A (ja) | 2003-02-07 |
| JP3655256B2 true JP3655256B2 (ja) | 2005-06-02 |
Family
ID=19194291
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002128742A Expired - Lifetime JP3655256B2 (ja) | 2002-04-30 | 2002-04-30 | 動画再生制御方法及び動画サーバ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3655256B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8856326B2 (en) | 2007-02-01 | 2014-10-07 | Telefonaktiebolaget L M Ericsson (Publ) | Enhanced media control |
| JP2008293276A (ja) * | 2007-05-24 | 2008-12-04 | Sony Corp | デジタルシネマ再生装置、上映中断対応方法及びプログラム |
| KR101319159B1 (ko) * | 2009-08-25 | 2013-10-17 | 주식회사 홍인터내셔날 | 다트 게임 장치 및 다트 게임 장치의 게임 데이터 인증 방법 |
| JP2015515166A (ja) * | 2012-02-15 | 2015-05-21 | トムソン ライセンシングＴｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ | 的を絞った広告 |
-
2002
- 2002-04-30 JP JP2002128742A patent/JP3655256B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003037821A (ja) | 2003-02-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4508422B2 (ja) | 情報分散システムの可変ビットレ−ト情報を処理する方法および装置 | |
| US9363302B2 (en) | Media stream scheduling for hiccup-free fast-channel-change in the presence of network chokepoints | |
| EP0660605B1 (en) | Video storage and delivery apparatus and method | |
| JP5662308B2 (ja) | 信号喪失をマスキングするための方法と装置 | |
| JP2001111972A (ja) | データ送出装置 | |
| US20110093885A1 (en) | Bookmark calibration for video on demand applications incorporating dynamic advertising | |
| US7072972B2 (en) | Method and apparatus for performing user migration within a video on demand environment | |
| EP2347587B1 (en) | Multi-rate statistical multiplexing | |
| JP2009124527A (ja) | コンテンツ再生方法、ノード装置およびプログラム | |
| JP3320595B2 (ja) | 動画再生制御方法及び動画サーバ | |
| JP3655256B2 (ja) | 動画再生制御方法及び動画サーバ | |
| US5774466A (en) | Regulation method and apparatus for ATM cell delay variation | |
| CN115278281B (zh) | 直播质量保障方法、装置、计算设备和存储介质 | |
| JP3974318B2 (ja) | 受信再生装置及びその方法 | |
| US20200186849A1 (en) | Method and system for reducing drop-outs during video stream playback | |
| JP3588522B2 (ja) | リアルタイムデータ用情報中継システムおよびリアルタイムデータ伝送用情報提供システム | |
| JP2004153789A (ja) | 受信装置及び受信方法 | |
| JP2006050220A (ja) | 映像再生装置、中継サーバおよび中継サービス、映像配信システムおよび映像配信サービス | |
| JP2001136205A (ja) | マルチキャストシステム、クライアント端末、送出装置 | |
| JP5532768B2 (ja) | 動画配信システム、その帯域制限方法、管理サーバ及びプログラム | |
| JP3824606B2 (ja) | リアルタイムデータ伝送用情報提供システム | |
| JP4558463B2 (ja) | ストリーム多重化送出装置 | |
| JP2006135793A (ja) | データ配信装置及びその制御方法、プログラム | |
| JP3670919B2 (ja) | 番組情報送出装置及び番組情報送出方法 | |
| JP2005223685A (ja) | コンテンツ再生方法及び装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050222 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050302 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080311 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090311 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100311 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100311 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110311 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120311 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130311 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130311 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140311 Year of fee payment: 9 |
|
| EXPY | Cancellation because of completion of term |