JP3383524B2 - ビデオサーバシステム - Google Patents
ビデオサーバシステムInfo
- Publication number
- JP3383524B2 JP3383524B2 JP26087596A JP26087596A JP3383524B2 JP 3383524 B2 JP3383524 B2 JP 3383524B2 JP 26087596 A JP26087596 A JP 26087596A JP 26087596 A JP26087596 A JP 26087596A JP 3383524 B2 JP3383524 B2 JP 3383524B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- client
- access right
- stream
- video 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 - Fee Related
Links
Landscapes
- Television Signal Processing For Recording (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】本発明は、ビデオオンデマン
ドシステムで用いられるビデオサーバシステムに関す
る。
ドシステムで用いられるビデオサーバシステムに関す
る。
【０００２】
【従来の技術】ビデオオンデマンドシステムでは、同時
に多くの利用者が番組を視聴する場合がある。通常、ビ
デオサーバには同時に送信できるストリームの数に上限
があり、多くの利用者が同時に番組を視聴する場合に
は、番組のストリームを提供するビデオサーバに過剰な
リクエストが集中しビジー状態となる。このため、利用
者は番組の視聴の要求を行ってもその要求は拒絶され、
利用者が番組を視聴するためには、要求が受理されるま
で視聴の要求をビデオサーバに繰り返し行う必要があっ
た。
に多くの利用者が番組を視聴する場合がある。通常、ビ
デオサーバには同時に送信できるストリームの数に上限
があり、多くの利用者が同時に番組を視聴する場合に
は、番組のストリームを提供するビデオサーバに過剰な
リクエストが集中しビジー状態となる。このため、利用
者は番組の視聴の要求を行ってもその要求は拒絶され、
利用者が番組を視聴するためには、要求が受理されるま
で視聴の要求をビデオサーバに繰り返し行う必要があっ
た。
【０００３】従来、多くの利用者が特定の番組に視聴を
要求することを利用して次のような方法が考えられてい
た。その方法は、番組に対する視聴の要求があった時
に、ストリームの送信が許容される最大遅延時間内に可
能であることが分かっていれば、ストリームの送信をそ
の間だけ保持し、その間に同一番組の視聴を要求した利
用者に対し同一のストリームを共用させる方法である
（特開平８―７０４４６）。
要求することを利用して次のような方法が考えられてい
た。その方法は、番組に対する視聴の要求があった時
に、ストリームの送信が許容される最大遅延時間内に可
能であることが分かっていれば、ストリームの送信をそ
の間だけ保持し、その間に同一番組の視聴を要求した利
用者に対し同一のストリームを共用させる方法である
（特開平８―７０４４６）。
【０００４】この方法によれば、ビデオサーバの負荷が
軽減されるため、同時に番組を提供できる利用者の数は
増加する。
軽減されるため、同時に番組を提供できる利用者の数は
増加する。
【０００５】
【発明が解決しようとする課題】しかし、この方法では
ビデオサーバ側でストリームの送信完了時刻が分かるこ
とを前提としており、送信完了時刻を特定することがで
きない仮想ＶＴＲ機能を有するビデオオンデマンドシス
テムには適用できなかった。また、利用者がストリーム
を共用している場合、利用者は仮想ＶＴＲ機能を使用で
きなかった。さらに、ビデオサーバで最大遅延時間内に
ストリームの送信が可能でない場合には、利用者は番組
を視聴するために、視聴の要求を繰り返し行う必要があ
った。
ビデオサーバ側でストリームの送信完了時刻が分かるこ
とを前提としており、送信完了時刻を特定することがで
きない仮想ＶＴＲ機能を有するビデオオンデマンドシス
テムには適用できなかった。また、利用者がストリーム
を共用している場合、利用者は仮想ＶＴＲ機能を使用で
きなかった。さらに、ビデオサーバで最大遅延時間内に
ストリームの送信が可能でない場合には、利用者は番組
を視聴するために、視聴の要求を繰り返し行う必要があ
った。
【０００６】本発明は上記問題を解決することを課題と
して、仮想ＶＴＲ機能を有するビデオオンデマンドシス
テムにおいて、ビデオサーバがビジー状態である場合で
も、利用者が番組を視聴するために、視聴の要求を繰り
返し行う必要のないビデオサーバシステムを提供する。
して、仮想ＶＴＲ機能を有するビデオオンデマンドシス
テムにおいて、ビデオサーバがビジー状態である場合で
も、利用者が番組を視聴するために、視聴の要求を繰り
返し行う必要のないビデオサーバシステムを提供する。
【０００７】
【課題を解決するための手段】本発明の第一のビデオサ
ーバシステムは、ストリームの送信に関わるリソースの
確保（以下、アクセス権と称す）を行う機能とストリー
ムの送信に関わるリソースの空きを通知する機能とを有
したストリームサーバ、クライアントによるアクセス権
の要求を識別する要求識別子を保持するキュー管理手
段、クライアントとの通信をつかさどる第一インターフ
ェース手段及び前記ストリームサーバからのリソースの
空きの通知と前記キュー管理手段で管理されている前記
要求識別子に基づきクライアントのアクセス権の要求を
処理する機能と前記キュー管理手段から得られる前記要
求識別子に対応する前記クライアントにアクセス権の要
求が可能であることを前記第一インターフェース手段を
通じて通知する機能を持つリクエスト処理手段を備えた
ものである。
ーバシステムは、ストリームの送信に関わるリソースの
確保（以下、アクセス権と称す）を行う機能とストリー
ムの送信に関わるリソースの空きを通知する機能とを有
したストリームサーバ、クライアントによるアクセス権
の要求を識別する要求識別子を保持するキュー管理手
段、クライアントとの通信をつかさどる第一インターフ
ェース手段及び前記ストリームサーバからのリソースの
空きの通知と前記キュー管理手段で管理されている前記
要求識別子に基づきクライアントのアクセス権の要求を
処理する機能と前記キュー管理手段から得られる前記要
求識別子に対応する前記クライアントにアクセス権の要
求が可能であることを前記第一インターフェース手段を
通じて通知する機能を持つリクエスト処理手段を備えた
ものである。
【０００８】このビデオサーバシステムでは、リクエス
ト処理手段がストリームサーバからリソースの空きがあ
ることの通知を受けると、キュー管理手段から得られる
情報に基づき、リクエスト処理手段はストリームサーバ
にアクセス権を要求する。それと同時に、キュー管理手
段から得られる要求識別子に対応するクライアントにア
クセス権の要求が可能であることを第一インターフェー
ス手段を介して通知する。このため、ビデオサーバの利
用者は、アクセス権の要求を行うタイミングがわかり、
アクセス権の要求を繰り返し行う必要はない。
ト処理手段がストリームサーバからリソースの空きがあ
ることの通知を受けると、キュー管理手段から得られる
情報に基づき、リクエスト処理手段はストリームサーバ
にアクセス権を要求する。それと同時に、キュー管理手
段から得られる要求識別子に対応するクライアントにア
クセス権の要求が可能であることを第一インターフェー
ス手段を介して通知する。このため、ビデオサーバの利
用者は、アクセス権の要求を行うタイミングがわかり、
アクセス権の要求を繰り返し行う必要はない。
【０００９】本発明の第二のビデオサーバシステムは、
ストリームの送信に関わるリソースの確保（以下、アク
セス権と称す）を行う機能とストリームの送信に関わる
リソースの空きを通知する機能とを有したストリームサ
ーバ、クライアントによるアクセス権の要求を識別する
要求識別子を保持するキュー管理手段、クライアントと
の通信をつかさどる第一インターフェース手段、前記第
一インターフェース手段とは異なる少なくとも一つ以上
のインタフェース手段、アクセス権の要求が可能である
ことを通知するインターフェース手段を表す識別情報を
利用者毎に対応づけて管理する通知手段管理手段及び前
記ストリームサーバからのリソースの空きの通知と前記
キュー管理手段で管理されている前記要求識別子に基づ
きクライアントのアクセス権の要求を処理する機能と前
記キュー管理手段で管理されている前記要求識別子に対
応する前記クライアントにアクセス権の要求が可能であ
ることを前記通知手段管理手段で管理されている前記識
別情報に対応するインタフェース手段を通じて通知する
機能を持つリクエスト処理手段を備えたものである。
ストリームの送信に関わるリソースの確保（以下、アク
セス権と称す）を行う機能とストリームの送信に関わる
リソースの空きを通知する機能とを有したストリームサ
ーバ、クライアントによるアクセス権の要求を識別する
要求識別子を保持するキュー管理手段、クライアントと
の通信をつかさどる第一インターフェース手段、前記第
一インターフェース手段とは異なる少なくとも一つ以上
のインタフェース手段、アクセス権の要求が可能である
ことを通知するインターフェース手段を表す識別情報を
利用者毎に対応づけて管理する通知手段管理手段及び前
記ストリームサーバからのリソースの空きの通知と前記
キュー管理手段で管理されている前記要求識別子に基づ
きクライアントのアクセス権の要求を処理する機能と前
記キュー管理手段で管理されている前記要求識別子に対
応する前記クライアントにアクセス権の要求が可能であ
ることを前記通知手段管理手段で管理されている前記識
別情報に対応するインタフェース手段を通じて通知する
機能を持つリクエスト処理手段を備えたものである。
【００１０】このビデオサーバシステムでは、利用者に
アクセス権の要求が可能であることの通知をするインタ
ーフェース手段が利用者に対応づけられて通知手段管理
手段に登録される。そして、リクエスト処理手段がスト
リームサーバからリソースの空きがあることの通知を受
けると、キュー管理手段から得られる情報に基づき、リ
クエスト処理手段はストリームサーバにアクセス権を要
求する。それと同時に、キュー管理手段から得られる要
求識別子に対応するクライアントにアクセス権の要求が
可能であることの通知を通知手段管理手段に登録されて
いるインターフェース手段を介して行う。このため、ビ
デオサーバの利用者は、アクセス権の要求を行うタイミ
ングがわかり、アクセス権の要求を繰り返し行う必要は
ない。さらに、利用者はアクセス権の要求が可能である
ことの通知を利用者にとって都合のよいインターフェー
ス手段で受けとることができる。
アクセス権の要求が可能であることの通知をするインタ
ーフェース手段が利用者に対応づけられて通知手段管理
手段に登録される。そして、リクエスト処理手段がスト
リームサーバからリソースの空きがあることの通知を受
けると、キュー管理手段から得られる情報に基づき、リ
クエスト処理手段はストリームサーバにアクセス権を要
求する。それと同時に、キュー管理手段から得られる要
求識別子に対応するクライアントにアクセス権の要求が
可能であることの通知を通知手段管理手段に登録されて
いるインターフェース手段を介して行う。このため、ビ
デオサーバの利用者は、アクセス権の要求を行うタイミ
ングがわかり、アクセス権の要求を繰り返し行う必要は
ない。さらに、利用者はアクセス権の要求が可能である
ことの通知を利用者にとって都合のよいインターフェー
ス手段で受けとることができる。
【００１１】本発明の別のビデオサーバシステムは、本
発明の第二のビデオサーバシステムに、クライアントと
ビデオサーバとの接続状態を管理する接続状態管理手段
及びクライアントの接続状態が切断状態である時に使用
するアクセス権の要求が可能であることを通知するイン
ターフェース手段を示す識別情報を利用者や時間に関連
づけて管理するデフォルト通知手段管理手段を加えたも
のであって、前記リクエスト処理手段に前記接続状態管
理手段で管理されているクライアントの接続状態と前記
デフォルト通知手段管理手段で管理されている情報に基
づきクライアントの接続状態が切断状態である時にクラ
イアントにアクセス権の要求が可能であることを通知す
るインターフェース手段を示す識別情報を前記通知手段
管理手段に記憶する機能を付加したものである。
発明の第二のビデオサーバシステムに、クライアントと
ビデオサーバとの接続状態を管理する接続状態管理手段
及びクライアントの接続状態が切断状態である時に使用
するアクセス権の要求が可能であることを通知するイン
ターフェース手段を示す識別情報を利用者や時間に関連
づけて管理するデフォルト通知手段管理手段を加えたも
のであって、前記リクエスト処理手段に前記接続状態管
理手段で管理されているクライアントの接続状態と前記
デフォルト通知手段管理手段で管理されている情報に基
づきクライアントの接続状態が切断状態である時にクラ
イアントにアクセス権の要求が可能であることを通知す
るインターフェース手段を示す識別情報を前記通知手段
管理手段に記憶する機能を付加したものである。
【００１２】このビデオサーバシステムでは、クライア
ントとビデオサーバが接続されていない場合に利用者に
アクセス権の要求が可能であることを通知するインター
フェース手段とその通知を受けることのできる時間が、
利用者に対応づけられて、デフォルト通知手段管理手段
に登録されている。このため、クライアントとビデオサ
ーバとの接続が切れている場合でも、利用者はアクセス
権の要求が可能であることの通知を、利用者にとって都
合のよい時間に都合の良いインタフェース手段で受けと
ることができる。
ントとビデオサーバが接続されていない場合に利用者に
アクセス権の要求が可能であることを通知するインター
フェース手段とその通知を受けることのできる時間が、
利用者に対応づけられて、デフォルト通知手段管理手段
に登録されている。このため、クライアントとビデオサ
ーバとの接続が切れている場合でも、利用者はアクセス
権の要求が可能であることの通知を、利用者にとって都
合のよい時間に都合の良いインタフェース手段で受けと
ることができる。
【００１３】また、本発明のビデオサーバシステムは、
前記リクエスト処理手段が、アクセス権の要求が可能で
あることをクライアントに通知した後の一定期間内にク
ライアントからのアクセス権の要求がない場合にストリ
ームサーバにアクセス権の取り消しを要求する機能を前
記リクエスト処理手段に付加したものである。
前記リクエスト処理手段が、アクセス権の要求が可能で
あることをクライアントに通知した後の一定期間内にク
ライアントからのアクセス権の要求がない場合にストリ
ームサーバにアクセス権の取り消しを要求する機能を前
記リクエスト処理手段に付加したものである。
【００１４】このビデオサーバシステムでは、リクエス
ト処理手段が、アクセス権の要求が可能であることをク
ライアントに通知した後、一定期間内にクライアントか
らアクセス権の要求がない場合にはストリームサーバに
アクセス権の取り消しを要求する。このため、ストリー
ムサーバにおけるストリームを送信するためのリソース
を無駄にすることがなくなる。
ト処理手段が、アクセス権の要求が可能であることをク
ライアントに通知した後、一定期間内にクライアントか
らアクセス権の要求がない場合にはストリームサーバに
アクセス権の取り消しを要求する。このため、ストリー
ムサーバにおけるストリームを送信するためのリソース
を無駄にすることがなくなる。
【００１５】
【発明の実施の形態】以下、本発明の実施の形態につい
て図１乃至図１０を参照にしながら説明する。但し、図
中においては、インターフェースをＩ／Ｆと略す。 《構成と機能》図１にビデオサーバシステムのブロック
図を示し、図２にビデオサーバシステムを用いたビデオ
オンデマンドシステムのシステム構成を示す。
て図１乃至図１０を参照にしながら説明する。但し、図
中においては、インターフェースをＩ／Ｆと略す。 《構成と機能》図１にビデオサーバシステムのブロック
図を示し、図２にビデオサーバシステムを用いたビデオ
オンデマンドシステムのシステム構成を示す。
【００１６】まず、図１を参考にしながら図２について
記す。セットトップボックス１１は、利用者が番組を視
聴するため、あるいは、ビデオサーバ１０においてスト
リームの送信に関わるリソースの確保（アクセス権）が
可能であることの通知を受けるために用いられる装置で
ある。このセットトップボックス１１で利用者の要求を
処理する処理部が、ビデオサーバシステムにおける第一
インターフェース部８との通信をつかさどるクライアン
トに相当する。電話端末１２は利用者がアクセス権の要
求が可能であることの通知を受けるための装置である。
この電話端末１２で利用者への通知を行う処理部が、ビ
デオサーバシステムにおける第二インターフェース部９
との通信をつかさどるクライアントに相当する。ビデオ
サーバ１０は第一ネットワーク１３によりセットトップ
ボックス１１に接続され、また、第二ネットワーク１４
により電話端末１２に接続されている。第一通信路Ｃ１
は、ビデオサーバ１０のストリームサーバ２と第一ネッ
トワーク１３とをつなぐ通信路であり、ストリームやビ
デオサーバ１０で提供する仮想ＶＴＲ機能を制御するた
めのコマンドなどの通信のために使用される。第二通信
路Ｃ２は、ビデオサーバ１０の第一インターフェース部
８と第一ネットワーク１３とをつなぐ通信路であり、ア
クセス権の要求とアクセス権の要求が可能であることの
通知を行うために使用される。第三通信路Ｃ３は、ビデ
オサーバ１０の第二インターフェース部９と第二ネット
ワーク１４とをつなぐ通信路であり、アクセス権の要求
が可能であることの通知を行うために使用される。な
お、本実施の形態では、セットトップボックス及び電話
端末を例にしているが、他の装置、例えばパソコン等に
対しても同様に実施できる。
記す。セットトップボックス１１は、利用者が番組を視
聴するため、あるいは、ビデオサーバ１０においてスト
リームの送信に関わるリソースの確保（アクセス権）が
可能であることの通知を受けるために用いられる装置で
ある。このセットトップボックス１１で利用者の要求を
処理する処理部が、ビデオサーバシステムにおける第一
インターフェース部８との通信をつかさどるクライアン
トに相当する。電話端末１２は利用者がアクセス権の要
求が可能であることの通知を受けるための装置である。
この電話端末１２で利用者への通知を行う処理部が、ビ
デオサーバシステムにおける第二インターフェース部９
との通信をつかさどるクライアントに相当する。ビデオ
サーバ１０は第一ネットワーク１３によりセットトップ
ボックス１１に接続され、また、第二ネットワーク１４
により電話端末１２に接続されている。第一通信路Ｃ１
は、ビデオサーバ１０のストリームサーバ２と第一ネッ
トワーク１３とをつなぐ通信路であり、ストリームやビ
デオサーバ１０で提供する仮想ＶＴＲ機能を制御するた
めのコマンドなどの通信のために使用される。第二通信
路Ｃ２は、ビデオサーバ１０の第一インターフェース部
８と第一ネットワーク１３とをつなぐ通信路であり、ア
クセス権の要求とアクセス権の要求が可能であることの
通知を行うために使用される。第三通信路Ｃ３は、ビデ
オサーバ１０の第二インターフェース部９と第二ネット
ワーク１４とをつなぐ通信路であり、アクセス権の要求
が可能であることの通知を行うために使用される。な
お、本実施の形態では、セットトップボックス及び電話
端末を例にしているが、他の装置、例えばパソコン等に
対しても同様に実施できる。
【００１７】次に図１について記す。第一インターフェ
ース部８は、セットトップボックス１１とリクエスト処
理部１との間の通信をつかさどる。また、第二インター
フェース部９は、電話端末１２とリクエスト処理部１と
の間の通信をつかさどる。通知手段管理部４は、クライ
アントにアクセス権の要求ができることを通知するイン
ターフェース手段を示す識別情報（以下、通知手段識別
子と称す）とクライアントによるアクセス権を識別する
要求識別子との関連づけを図３に示す通知手段管理テー
ブル３１で保持している。デフォルト通知手段管理部３
は、図４に示すデフォルト通知手段管理テーブル３２に
利用者を識別する利用者識別子に通知手段識別子と通知
可能な時間帯を関連づけて保持している。ただし、デフ
ォルト通知手段管理部３で管理を行う通知手段識別子
は、クライアントとビデオサーバ１０が接続されていな
い時にクライアントにアクセス権の要求が可能であるこ
とを通知するインタフェース手段に対応するものであ
る。接続状態管理部５は、クライアントとビデオサーバ
１０との接続状態と要求識別子の関連づけを図５に示す
接続状態管理テーブル３３で保持している。ストリーム
サーバ２は、リクエスト処理部１からのアクセス権の要
求とアクセス権の取り消し要求に基づきストリームの送
信に関わるリソースの管理をアクセス権を提供している
クライアントの数（以下、アクセス数と称す）によって
行う。つまり、ストリームサーバ２がアクセス権の要求
を受信すると、アクセス数がストリームサーバ２に固有
のしきい値（ストリームを提供できるクライアントの最
大数）Ｔｈに達しているか達していないか判断し、アク
セス数がしきい値Ｔｈに達していなければ、アクセス数
を１だけ増やしてアクセス権の要求を受理する。また、
アクセス数がしきい値Ｔｈに達していればアクセス権の
要求を拒否する。さらに、アクセス権の取り消しの要求
を受信すると、アクセス数を１だけ減らす。また、アク
セス数が前記しきい値ＴｈからＴｈ−１に減少すると、
ストリームの送信に関わるリソースに空きがあることを
リクエスト処理部１に通知する。キュー管理部６は、リ
クエスト処理部１からの要求により要求識別子の保持を
行う。そして、保持している要求識別子の取り出しがリ
クエスト処理部１から要求されれば、その要求識別子を
リクエスト処理部１に通知する。そしてリクエスト処理
部１に通知した要求識別子を保持の対象から削除する。
また、保持している要求識別子の数に基づいて、キュー
の有無に関する問い合わせに応答する機能もある。タイ
マ７はタイマ識別子に値を付加し、アクセス権の要求が
可能であることをクライアントに通知してから経過した
時間を管理する。ここで、タイマ識別子はアクセス権の
要求が可能であることをクライアントに通知した後に起
動したタイマ７を識別するために使用される。時計２０
は時刻を管理する。リクエスト処理部１は、ストリーム
サーバ２とデフォルト通知手段管理部３と通知手段管理
部４と接続状態管理部５とキュー管理部６とタイマ７と
第一インターフェース部８と第二インターフェース部９
と時計２０と連携をとって、第一インターフェース部８
から受信するアクセス権の要求を処理する機能を持つ。
また、リクエスト処理部１は、要求識別子とタイマ識別
子と利用者を識別するための利用者識別子とクライアン
トを識別するためのクライアント識別子との関連づけを
図６に示す要求管理テーブル３４に保持している。
ース部８は、セットトップボックス１１とリクエスト処
理部１との間の通信をつかさどる。また、第二インター
フェース部９は、電話端末１２とリクエスト処理部１と
の間の通信をつかさどる。通知手段管理部４は、クライ
アントにアクセス権の要求ができることを通知するイン
ターフェース手段を示す識別情報（以下、通知手段識別
子と称す）とクライアントによるアクセス権を識別する
要求識別子との関連づけを図３に示す通知手段管理テー
ブル３１で保持している。デフォルト通知手段管理部３
は、図４に示すデフォルト通知手段管理テーブル３２に
利用者を識別する利用者識別子に通知手段識別子と通知
可能な時間帯を関連づけて保持している。ただし、デフ
ォルト通知手段管理部３で管理を行う通知手段識別子
は、クライアントとビデオサーバ１０が接続されていな
い時にクライアントにアクセス権の要求が可能であるこ
とを通知するインタフェース手段に対応するものであ
る。接続状態管理部５は、クライアントとビデオサーバ
１０との接続状態と要求識別子の関連づけを図５に示す
接続状態管理テーブル３３で保持している。ストリーム
サーバ２は、リクエスト処理部１からのアクセス権の要
求とアクセス権の取り消し要求に基づきストリームの送
信に関わるリソースの管理をアクセス権を提供している
クライアントの数（以下、アクセス数と称す）によって
行う。つまり、ストリームサーバ２がアクセス権の要求
を受信すると、アクセス数がストリームサーバ２に固有
のしきい値（ストリームを提供できるクライアントの最
大数）Ｔｈに達しているか達していないか判断し、アク
セス数がしきい値Ｔｈに達していなければ、アクセス数
を１だけ増やしてアクセス権の要求を受理する。また、
アクセス数がしきい値Ｔｈに達していればアクセス権の
要求を拒否する。さらに、アクセス権の取り消しの要求
を受信すると、アクセス数を１だけ減らす。また、アク
セス数が前記しきい値ＴｈからＴｈ−１に減少すると、
ストリームの送信に関わるリソースに空きがあることを
リクエスト処理部１に通知する。キュー管理部６は、リ
クエスト処理部１からの要求により要求識別子の保持を
行う。そして、保持している要求識別子の取り出しがリ
クエスト処理部１から要求されれば、その要求識別子を
リクエスト処理部１に通知する。そしてリクエスト処理
部１に通知した要求識別子を保持の対象から削除する。
また、保持している要求識別子の数に基づいて、キュー
の有無に関する問い合わせに応答する機能もある。タイ
マ７はタイマ識別子に値を付加し、アクセス権の要求が
可能であることをクライアントに通知してから経過した
時間を管理する。ここで、タイマ識別子はアクセス権の
要求が可能であることをクライアントに通知した後に起
動したタイマ７を識別するために使用される。時計２０
は時刻を管理する。リクエスト処理部１は、ストリーム
サーバ２とデフォルト通知手段管理部３と通知手段管理
部４と接続状態管理部５とキュー管理部６とタイマ７と
第一インターフェース部８と第二インターフェース部９
と時計２０と連携をとって、第一インターフェース部８
から受信するアクセス権の要求を処理する機能を持つ。
また、リクエスト処理部１は、要求識別子とタイマ識別
子と利用者を識別するための利用者識別子とクライアン
トを識別するためのクライアント識別子との関連づけを
図６に示す要求管理テーブル３４に保持している。
【００１８】《動作》次に、以上のように構成されたビ
デオサーバシステムを用いたビデオオンデマンドシステ
ムの動作について記す。
デオサーバシステムを用いたビデオオンデマンドシステ
ムの動作について記す。
【００１９】図７に示すように、クライアントからのア
クセス権の要求を処理するために、リクエスト処理部１
は、 （ａ） 第一インターフェース部８からのクライアント
のアクセス権の要求 （ｂ） タイマ７からのタイムアウトの通知 （ｃ） ストリームサーバ２からストリームの送信に関
わるリソースの空きがあることの通知 のいずれかの受信を契機として動作を始める（ステップ
１）。リクエスト処理部１は、前記（ａ）から（ｃ）の
いずれかを受信すると、受信の内容を識別し、それに応
じた処理に切り替える（ステップ２）。次に、リクエス
ト処理部１は、受信の内容に応じた処理１乃至処理３の
いずれかの処理を行う。つまり、リクエスト処理部１
は、第一インターフェース部８から利用者識別子とクラ
イアント識別子とともにアクセス権の要求をうけた場合
には、処理１を行う（ステップ３）。ストリームサーバ
２から、ストリームのアクセス権に関わるリソースの空
きがあることの通知を受信した場合には、処理２を行う
（ステップ４）。タイマ７からのタイムアウトの通知を
タイマ識別子とともに受信した場合には、処理３を行う
（ステップ５）。
クセス権の要求を処理するために、リクエスト処理部１
は、 （ａ） 第一インターフェース部８からのクライアント
のアクセス権の要求 （ｂ） タイマ７からのタイムアウトの通知 （ｃ） ストリームサーバ２からストリームの送信に関
わるリソースの空きがあることの通知 のいずれかの受信を契機として動作を始める（ステップ
１）。リクエスト処理部１は、前記（ａ）から（ｃ）の
いずれかを受信すると、受信の内容を識別し、それに応
じた処理に切り替える（ステップ２）。次に、リクエス
ト処理部１は、受信の内容に応じた処理１乃至処理３の
いずれかの処理を行う。つまり、リクエスト処理部１
は、第一インターフェース部８から利用者識別子とクラ
イアント識別子とともにアクセス権の要求をうけた場合
には、処理１を行う（ステップ３）。ストリームサーバ
２から、ストリームのアクセス権に関わるリソースの空
きがあることの通知を受信した場合には、処理２を行う
（ステップ４）。タイマ７からのタイムアウトの通知を
タイマ識別子とともに受信した場合には、処理３を行う
（ステップ５）。
【００２０】以下、リクエスト処理部１における、処理
１（ステップ３）、処理２（ステップ４）及び処理３
（ステップ５）の各処理手順について順に説明する。
１（ステップ３）、処理２（ステップ４）及び処理３
（ステップ５）の各処理手順について順に説明する。
【００２１】〔処理１〕
処理１は、
（Ｉ） クライアントが新規にアクセス権の要求を行っ
た場合の処理 （II） 過去に要求を行いビデオサーバ１０からビデオ
サーバ１０がビジー状態である旨の通知をされた後、ビ
デオサーバ１０からアクセス権の要求が可能になったこ
との通知をうけ再度アクセス権の要求を行った場合の処
理 (III) 既にアクセス権の要求が受理されたのちに再度
アクセス権の要求を行った場合の処理 の何れかに相当し、図８をもとに説明する。 ステップ１０１：リクエスト処理部１は、クライアント
が新規にアクセス権の要求を行ったかどうかを判断す
る。具体的には、クライアントから通知された利用者識
別子ＳＩＤとクライアント識別子ＣＩＤが要求管理テー
ブル３４に既に登録されているかどうかを判断する。登
録されていれば既にアクセス権の要求を行ったクライア
ントからの要求であると判断し、ステップ１０９を実行
する。登録されていなければ、新しいクライアントから
の要求であると判断し、ステップ１０２を実行する。 ステップ１０２：リクエスト処理部１は、アクセス権の
要求を行ったクライアントに対応する要求識別子ＲＩＤ
を要求管理テーブル３４の中で重複がないように割り当
て、利用者識別子ＳＩＤ及びクライアント識別子ＣＩＤ
に対応づけて登録し、タイマ識別子ＴＩＤを０に設定す
る。次にステップ１０３を実行する。 ステップ１０３：アクセス権の要求が可能であることの
通知を待っているクライアントがあるかないかを判断す
るために、リクエスト処理部１はキュー管理部６にキュ
ーの有無を問い合わせる。キューがない場合には、ステ
ップ１０４を実行し、ある場合にはステップ１０７を実
行する。 ステップ１０４：リクエスト処理部１は、ストリームサ
ーバ２にアクセス権の要求を行い、ストリームサーバ２
からの応答を受信する。次にステップ１０５を実行す
る。 ステップ１０５：ストリームサーバ２からの応答が要求
の受理である場合には、ステップ１０６を実行する。ま
た、要求の拒否である場合にはステップ１０７を実行す
る。 ステップ１０６：リクエスト処理部１は第一インターフ
ェース部８に、利用者識別子ＳＩＤとクライアント識別
子ＣＩＤとともにアクセス権の要求が受理された旨をク
ライアントに通知することを依頼する。そして、処理１
での処理を終了する。 ステップ１０７：ストリームサーバ２にストリームの送
信に関わるリソースの空きがないため、リクエスト処理
部１は要求識別子ＲＩＤの保持をキュー管理部６に依頼
する。次にステップ１０８を実行する。 ステップ１０８：要求識別子ＲＩＤに対応する利用者識
別子ＳＩＤおよびクライアント識別子ＣＩＤを要求管理
テーブル３４から検索する。そして、リクエスト処理部
１は、第一インターフェース部８に、利用者識別子ＳＩ
Ｄとクライアント識別子ＣＩＤとともにビデオサーバ１
０がビジー状態である旨をクライアントに通知すること
を依頼して、処理１での処理を終了する。 ステップ１０９：リクエスト処理部１は、 （Ａ） クライアントがアクセス権の要求が可能である
と通知を受けた後にタイムアウト前に再度アクセス権の
要求を行った場合 （Ｂ） 既にアクセス権の要求が受理されたのちに再度
アクセス権の要求を行った場合 のいずれかを判断する。具体的には、ビデオサーバ１０
からアクセス権の要求が可能であるとの通知をうけたク
ライアントの場合には、ステップ２０８（図９）で要求
管理テーブル３４のタイマ識別子ＴＩＤが０より大きい
値に設定されている。そこで、タイマ識別子ＴＩＤの値
が０であるか０より大きい値であるかの判断を行う。そ
してタイマ識別子ＴＩＤの値が０より大きければ、ステ
ップ１１０を実行し、タイマ識別子ＴＩＤの値が０であ
ればステップ１１２を実行する。 ステップ１１０：リクエスト処理部１は、タイマ７に対
してタイマ識別子ＴＩＤに対応するタイマの中止を要求
する。次にステップ１１１を実行する。 ステップ１１１：リクエスト処理部１は、要求管理テー
ブル３４での該当する要求識別子に対応するタイマ識別
子ＴＩＤを０に戻す。次にステップ１０６を実行する。 ステップ１１２：既にアクセス権の要求が受理されてい
るクライアントからの要求である。そのため、リクエス
ト処理部１は、第一インターフェース部８に、利用者識
別子ＳＩＤとクライアント識別子ＣＩＤとともにアクセ
ス権の要求が既に受理されている旨をクライアントに通
知することを依頼する。そして、処理１での処理を終了
する。
た場合の処理 （II） 過去に要求を行いビデオサーバ１０からビデオ
サーバ１０がビジー状態である旨の通知をされた後、ビ
デオサーバ１０からアクセス権の要求が可能になったこ
との通知をうけ再度アクセス権の要求を行った場合の処
理 (III) 既にアクセス権の要求が受理されたのちに再度
アクセス権の要求を行った場合の処理 の何れかに相当し、図８をもとに説明する。 ステップ１０１：リクエスト処理部１は、クライアント
が新規にアクセス権の要求を行ったかどうかを判断す
る。具体的には、クライアントから通知された利用者識
別子ＳＩＤとクライアント識別子ＣＩＤが要求管理テー
ブル３４に既に登録されているかどうかを判断する。登
録されていれば既にアクセス権の要求を行ったクライア
ントからの要求であると判断し、ステップ１０９を実行
する。登録されていなければ、新しいクライアントから
の要求であると判断し、ステップ１０２を実行する。 ステップ１０２：リクエスト処理部１は、アクセス権の
要求を行ったクライアントに対応する要求識別子ＲＩＤ
を要求管理テーブル３４の中で重複がないように割り当
て、利用者識別子ＳＩＤ及びクライアント識別子ＣＩＤ
に対応づけて登録し、タイマ識別子ＴＩＤを０に設定す
る。次にステップ１０３を実行する。 ステップ１０３：アクセス権の要求が可能であることの
通知を待っているクライアントがあるかないかを判断す
るために、リクエスト処理部１はキュー管理部６にキュ
ーの有無を問い合わせる。キューがない場合には、ステ
ップ１０４を実行し、ある場合にはステップ１０７を実
行する。 ステップ１０４：リクエスト処理部１は、ストリームサ
ーバ２にアクセス権の要求を行い、ストリームサーバ２
からの応答を受信する。次にステップ１０５を実行す
る。 ステップ１０５：ストリームサーバ２からの応答が要求
の受理である場合には、ステップ１０６を実行する。ま
た、要求の拒否である場合にはステップ１０７を実行す
る。 ステップ１０６：リクエスト処理部１は第一インターフ
ェース部８に、利用者識別子ＳＩＤとクライアント識別
子ＣＩＤとともにアクセス権の要求が受理された旨をク
ライアントに通知することを依頼する。そして、処理１
での処理を終了する。 ステップ１０７：ストリームサーバ２にストリームの送
信に関わるリソースの空きがないため、リクエスト処理
部１は要求識別子ＲＩＤの保持をキュー管理部６に依頼
する。次にステップ１０８を実行する。 ステップ１０８：要求識別子ＲＩＤに対応する利用者識
別子ＳＩＤおよびクライアント識別子ＣＩＤを要求管理
テーブル３４から検索する。そして、リクエスト処理部
１は、第一インターフェース部８に、利用者識別子ＳＩ
Ｄとクライアント識別子ＣＩＤとともにビデオサーバ１
０がビジー状態である旨をクライアントに通知すること
を依頼して、処理１での処理を終了する。 ステップ１０９：リクエスト処理部１は、 （Ａ） クライアントがアクセス権の要求が可能である
と通知を受けた後にタイムアウト前に再度アクセス権の
要求を行った場合 （Ｂ） 既にアクセス権の要求が受理されたのちに再度
アクセス権の要求を行った場合 のいずれかを判断する。具体的には、ビデオサーバ１０
からアクセス権の要求が可能であるとの通知をうけたク
ライアントの場合には、ステップ２０８（図９）で要求
管理テーブル３４のタイマ識別子ＴＩＤが０より大きい
値に設定されている。そこで、タイマ識別子ＴＩＤの値
が０であるか０より大きい値であるかの判断を行う。そ
してタイマ識別子ＴＩＤの値が０より大きければ、ステ
ップ１１０を実行し、タイマ識別子ＴＩＤの値が０であ
ればステップ１１２を実行する。 ステップ１１０：リクエスト処理部１は、タイマ７に対
してタイマ識別子ＴＩＤに対応するタイマの中止を要求
する。次にステップ１１１を実行する。 ステップ１１１：リクエスト処理部１は、要求管理テー
ブル３４での該当する要求識別子に対応するタイマ識別
子ＴＩＤを０に戻す。次にステップ１０６を実行する。 ステップ１１２：既にアクセス権の要求が受理されてい
るクライアントからの要求である。そのため、リクエス
ト処理部１は、第一インターフェース部８に、利用者識
別子ＳＩＤとクライアント識別子ＣＩＤとともにアクセ
ス権の要求が既に受理されている旨をクライアントに通
知することを依頼する。そして、処理１での処理を終了
する。
【００２２】〔処理２〕
次に処理２の処理について説明する。処理２は、ストリ
ームサーバ２がストリームの送信に関わるリソースの空
きがある場合に、クライアントに対して、アクセス権の
要求が可能であることを通知する場合の処理に相当し、
図９をもとに説明される。 ステップ２０１：リクエスト処理部１はキュー管理部６
にキューの有無を問い合わせる。ある場合にはステップ
２０２を実行し、ない場合には処理２での処理を終了す
る。 ステップ２０２：リクエスト処理部１は、キュー管理部
６から要求識別子ＲＩＤを取り出し、キュー管理部６は
取り出された要求識別子を削除する。次に、ステップ２
０３を実行する。 ステップ２０３：リクエスト処理部１は、接続状態管理
テーブル３３から要求識別子ＲＩＤに対応する接続状態
ＣＳＴを得る。次に、ステップ２０４を実行する。 ステップ２０４：接続状態ＣＳＴが接続状態を示す場合
には、ステップ２０５を実行する。また、切断状態を示
す場合には、ステップ２１２を実行する。 ステップ２０５：リクエスト処理部１は、通知手段管理
テーブル３１から、通知手段識別子ＣＭＩを得る。次
に、ステップ２０６を実行する。 ステップ２０６：通知手段識別子ＣＭＩが、「通知手段
なし」の場合には、処理２での処理を終了する。通知手
段識別子ＣＭＩが、「ＳＴＢ」あるいは「電話」の場合
には、ステップ２０７を実行する。ここで、「ＳＴＢ」
はセットトップボックス１１を意味し、「電話」は電話
端末１２を意味する。 ステップ２０７：リクエスト処理部１は、ストリームサ
ーバ２に対してアクセス権の要求を行う。次に、ステッ
プ２０８を実行する。 ステップ２０８：リクエスト処理部１は、０より大きい
値であるタイマ識別子ＴＩＤを要求管理テーブル３４で
重複しないように要求識別子ＲＩＤに割当てて、要求管
理テーブル３４に登録する。次に、ステップ２０９を実
行する。 ステップ２０９：リクエスト処理部１は、タイマ７にタ
イマ識別子ＴＩＤに対応したタイマの起動を要求する。
次に、ステップ２１０を実行する。 ステップ２１０：リクエスト処理部１は、要求管理テー
ブル３４から要求識別子ＲＩＤに対応した利用者識別子
ＳＩＤとクライアント識別子ＣＩＤを検索する。次にス
テップ２１１を実行する。 ステップ２１１：リクエスト処理部１は、通知手段識別
子ＣＭＩが「ＳＴＢ」ならば第一インターフェース部８
に対して、「電話」ならば第二インターフェース部９に
対して、利用者識別子ＳＩＤとクライアント識別子ＣＩ
Ｄとともに、クライアントにアクセス権の要求が可能で
あることの通知を依頼する。そして、処理２での処理を
終了する。 ステップ２１２：リクエスト処理部１は、時計２０から
時間を獲得し、要求管理テーブル３４から要求識別子Ｒ
ＩＤに対応するクライアント識別子ＣＩＤを検索する。
そして、それをもとに、デフォルト通知手段管理テーブ
ル３２に登録されている通知可能な時間の範囲内である
か範囲外であるかを判断する。通知可能な時間の範囲内
であればステップ２１３を実行し、通知可能な時間の後
であればステップ２１４を実行し、通知可能な時間の前
であればステップ２１５を実行する。 ステップ２１３：リクエスト処理部１は、通知手段管理
テーブル３１の通知手段識別子に、デフォルト通知手段
管理テーブル３２で管理されている通知手段識別子を登
録する。次に、ステップ２０５を実行する。 ステップ２１４：リクエスト処理部１は、通知手段管理
テーブル３１の通知手段識別子に「通知手段なし」を登
録する。次にステップ２０５を実行する。 ステップ２１５：リクエスト処理部１は、取り出した要
求識別子を再度キュー管理部６に保持を依頼し、処理２
での処理を終了する。なお、本実施の形態では、第一イ
ンターフェース手段とは異なるインターフェース手段が
一つの場合を例に説明したが、二つ以上の場合も通知手
段識別子を増やすことにより同様に処理することができ
る。
ームサーバ２がストリームの送信に関わるリソースの空
きがある場合に、クライアントに対して、アクセス権の
要求が可能であることを通知する場合の処理に相当し、
図９をもとに説明される。 ステップ２０１：リクエスト処理部１はキュー管理部６
にキューの有無を問い合わせる。ある場合にはステップ
２０２を実行し、ない場合には処理２での処理を終了す
る。 ステップ２０２：リクエスト処理部１は、キュー管理部
６から要求識別子ＲＩＤを取り出し、キュー管理部６は
取り出された要求識別子を削除する。次に、ステップ２
０３を実行する。 ステップ２０３：リクエスト処理部１は、接続状態管理
テーブル３３から要求識別子ＲＩＤに対応する接続状態
ＣＳＴを得る。次に、ステップ２０４を実行する。 ステップ２０４：接続状態ＣＳＴが接続状態を示す場合
には、ステップ２０５を実行する。また、切断状態を示
す場合には、ステップ２１２を実行する。 ステップ２０５：リクエスト処理部１は、通知手段管理
テーブル３１から、通知手段識別子ＣＭＩを得る。次
に、ステップ２０６を実行する。 ステップ２０６：通知手段識別子ＣＭＩが、「通知手段
なし」の場合には、処理２での処理を終了する。通知手
段識別子ＣＭＩが、「ＳＴＢ」あるいは「電話」の場合
には、ステップ２０７を実行する。ここで、「ＳＴＢ」
はセットトップボックス１１を意味し、「電話」は電話
端末１２を意味する。 ステップ２０７：リクエスト処理部１は、ストリームサ
ーバ２に対してアクセス権の要求を行う。次に、ステッ
プ２０８を実行する。 ステップ２０８：リクエスト処理部１は、０より大きい
値であるタイマ識別子ＴＩＤを要求管理テーブル３４で
重複しないように要求識別子ＲＩＤに割当てて、要求管
理テーブル３４に登録する。次に、ステップ２０９を実
行する。 ステップ２０９：リクエスト処理部１は、タイマ７にタ
イマ識別子ＴＩＤに対応したタイマの起動を要求する。
次に、ステップ２１０を実行する。 ステップ２１０：リクエスト処理部１は、要求管理テー
ブル３４から要求識別子ＲＩＤに対応した利用者識別子
ＳＩＤとクライアント識別子ＣＩＤを検索する。次にス
テップ２１１を実行する。 ステップ２１１：リクエスト処理部１は、通知手段識別
子ＣＭＩが「ＳＴＢ」ならば第一インターフェース部８
に対して、「電話」ならば第二インターフェース部９に
対して、利用者識別子ＳＩＤとクライアント識別子ＣＩ
Ｄとともに、クライアントにアクセス権の要求が可能で
あることの通知を依頼する。そして、処理２での処理を
終了する。 ステップ２１２：リクエスト処理部１は、時計２０から
時間を獲得し、要求管理テーブル３４から要求識別子Ｒ
ＩＤに対応するクライアント識別子ＣＩＤを検索する。
そして、それをもとに、デフォルト通知手段管理テーブ
ル３２に登録されている通知可能な時間の範囲内である
か範囲外であるかを判断する。通知可能な時間の範囲内
であればステップ２１３を実行し、通知可能な時間の後
であればステップ２１４を実行し、通知可能な時間の前
であればステップ２１５を実行する。 ステップ２１３：リクエスト処理部１は、通知手段管理
テーブル３１の通知手段識別子に、デフォルト通知手段
管理テーブル３２で管理されている通知手段識別子を登
録する。次に、ステップ２０５を実行する。 ステップ２１４：リクエスト処理部１は、通知手段管理
テーブル３１の通知手段識別子に「通知手段なし」を登
録する。次にステップ２０５を実行する。 ステップ２１５：リクエスト処理部１は、取り出した要
求識別子を再度キュー管理部６に保持を依頼し、処理２
での処理を終了する。なお、本実施の形態では、第一イ
ンターフェース手段とは異なるインターフェース手段が
一つの場合を例に説明したが、二つ以上の場合も通知手
段識別子を増やすことにより同様に処理することができ
る。
【００２３】そして、利用者が、ストリームの提供を受
けることができたとき、通知手段管理テーブル３１、デ
フォルト通知手段管理テーブル３２、接続状態管理テー
ブル３３及び要求管理テーブル３４から、利用者に対応
した情報を削除する。
けることができたとき、通知手段管理テーブル３１、デ
フォルト通知手段管理テーブル３２、接続状態管理テー
ブル３３及び要求管理テーブル３４から、利用者に対応
した情報を削除する。
【００２４】〔処理３〕次に処理３について説明する。
処理３は、アクセス権の要求が可能である通知を行った
後、一定時間内にクライアントから再度アクセス権の要
求がない場合の処理に相当し、図１０をもとに説明す
る。 ステップ３０１：リクエスト処理部１は、タイマ識別子
ＴＩＤに対応するタイマ７からタイムアウトの通知を受
信すると、ストリームサーバ２に対してアクセス権の取
り消しを要求する。次に、ステップ３０２を実行する。 ステップ３０２：リクエスト処理部１は、要求管理テー
ブル３４からタイマ識別子ＴＩＤに対応する要求識別
子、利用者識別子、クライアント識別子及びタイマ識別
子の関連づけを削除し、処理３の処理を終了する。
処理３は、アクセス権の要求が可能である通知を行った
後、一定時間内にクライアントから再度アクセス権の要
求がない場合の処理に相当し、図１０をもとに説明す
る。 ステップ３０１：リクエスト処理部１は、タイマ識別子
ＴＩＤに対応するタイマ７からタイムアウトの通知を受
信すると、ストリームサーバ２に対してアクセス権の取
り消しを要求する。次に、ステップ３０２を実行する。 ステップ３０２：リクエスト処理部１は、要求管理テー
ブル３４からタイマ識別子ＴＩＤに対応する要求識別
子、利用者識別子、クライアント識別子及びタイマ識別
子の関連づけを削除し、処理３の処理を終了する。
【００２５】《作用と効果》最後に図１乃至図１０に構
成及び処理手順を示したビデオサーバシステムを用いた
ビデオオンデマンドシステムの作用と効果について記
す。
成及び処理手順を示したビデオサーバシステムを用いた
ビデオオンデマンドシステムの作用と効果について記
す。
【００２６】ストリームサーバ２がビジー状態である場
合、アクセス権の要求を行ったクライアントの利用者識
別子とクライアント識別子と要求識別子を要求管理テー
ブル３４に保持し、さらに要求識別子をキュー管理部６
で保持する。通知手段管理部４で、クライアントにアク
セス権の要求が可能であることを通知するインターフェ
ース手段に対応した通知手段識別子（「ＳＴＢ」あるい
は「電話」）を通知手段管理テーブル３１に保持する。
そして、リクエスト処理部１は、ストリームサーバ２か
らストリームの送信に関わるリソースの空きがあるとの
通知を受けると、キュー管理部６から得られる情報に基
づき、ストリームサーバ２にアクセス権を要求する。そ
れと同時に、通知手段識別子に基づいて、アクセス権の
要求を通知するインターフェース手段を選択し、クライ
アントにアクセス権の要求が可能であることを通知す
る。こうすることにより、利用者は、利用者の都合の良
い通知手段により通知を受けとることができる。
合、アクセス権の要求を行ったクライアントの利用者識
別子とクライアント識別子と要求識別子を要求管理テー
ブル３４に保持し、さらに要求識別子をキュー管理部６
で保持する。通知手段管理部４で、クライアントにアク
セス権の要求が可能であることを通知するインターフェ
ース手段に対応した通知手段識別子（「ＳＴＢ」あるい
は「電話」）を通知手段管理テーブル３１に保持する。
そして、リクエスト処理部１は、ストリームサーバ２か
らストリームの送信に関わるリソースの空きがあるとの
通知を受けると、キュー管理部６から得られる情報に基
づき、ストリームサーバ２にアクセス権を要求する。そ
れと同時に、通知手段識別子に基づいて、アクセス権の
要求を通知するインターフェース手段を選択し、クライ
アントにアクセス権の要求が可能であることを通知す
る。こうすることにより、利用者は、利用者の都合の良
い通知手段により通知を受けとることができる。
【００２７】また、デフォルト通知手段管理部３で、各
利用者に対応して、アクセス権の要求が可能であること
の通知を受け付ける通知可能時間と、クライアントにア
クセス権の要求が可能であることの通知をするインター
フェース手段をデフォルト通知手段管理テーブル３２で
保持する。また、接続状態管理部５でクライアントとビ
デオサーバ１０との接続状態を接続状態管理テーブル３
３に保持する。リクエスト処理部１が接続状態管理テー
ブル３３からクライアントとビデオサーバ１０との接続
状態を得る。そして、クライアントとビデオサーバ１０
との接続が切れている場合には、通知手段管理テーブル
３１に登録されているインターフェース手段を、デフォ
ルト通知手段管理テーブル３２に登録されている通知可
能時間と現在時刻と通知手段識別子を基に書き換えを行
う。そして、リクエスト処理部１は、書き換えられたイ
ンターフェース手段でクライアントにアクセス権の要求
が可能であることを通知する。こうすることによって、
クライアントとビデオサーバ１０との接続が切れている
場合でも、利用者は、利用者にとって都合のよい時間に
都合のよいインターフェース手段でアクセス権の要求が
可能であることの通知を受けとることができる。
利用者に対応して、アクセス権の要求が可能であること
の通知を受け付ける通知可能時間と、クライアントにア
クセス権の要求が可能であることの通知をするインター
フェース手段をデフォルト通知手段管理テーブル３２で
保持する。また、接続状態管理部５でクライアントとビ
デオサーバ１０との接続状態を接続状態管理テーブル３
３に保持する。リクエスト処理部１が接続状態管理テー
ブル３３からクライアントとビデオサーバ１０との接続
状態を得る。そして、クライアントとビデオサーバ１０
との接続が切れている場合には、通知手段管理テーブル
３１に登録されているインターフェース手段を、デフォ
ルト通知手段管理テーブル３２に登録されている通知可
能時間と現在時刻と通知手段識別子を基に書き換えを行
う。そして、リクエスト処理部１は、書き換えられたイ
ンターフェース手段でクライアントにアクセス権の要求
が可能であることを通知する。こうすることによって、
クライアントとビデオサーバ１０との接続が切れている
場合でも、利用者は、利用者にとって都合のよい時間に
都合のよいインターフェース手段でアクセス権の要求が
可能であることの通知を受けとることができる。
【００２８】さらに、リクエスト処理部１は、クライア
ントにアクセス権の要求が可能であることの通知を行う
と同時に、タイマ７にタイマの起動を要求する。そし
て、クライアントからの再度のアクセス権の要求がタイ
マ７からのタイムアウトの通知の前にない場合には、リ
クエスト処理部１はストリームサーバ２にアクセス権の
取り消しを要求する。こうすることにより、無駄にスト
リームサーバ２のストリームの送信に関わるリソースを
消費するのを防ぐことができる。
ントにアクセス権の要求が可能であることの通知を行う
と同時に、タイマ７にタイマの起動を要求する。そし
て、クライアントからの再度のアクセス権の要求がタイ
マ７からのタイムアウトの通知の前にない場合には、リ
クエスト処理部１はストリームサーバ２にアクセス権の
取り消しを要求する。こうすることにより、無駄にスト
リームサーバ２のストリームの送信に関わるリソースを
消費するのを防ぐことができる。
【００２９】なお、本実施の形態ではインターフェース
手段として第一インターフェース部８と第二インターフ
ェース部９がある場合であるが、インターフェース手段
として第一インターフェース部８だけの場合でも、上記
の手順からクライアントにアクセス権の要求を通知する
インターフェース手段を管理する手順を削除することで
同様に実施することができる。ただし、この場合には、
利用者は常に同一のインターフェース手段からしかアク
セス権の要求が可能であることの通知を受けることはで
きない。しかし、ビデオサーバ１０がビジー状態である
場合にも、利用者はアクセス権の要求を行うタイミング
がわかり、アクセス権の要求を繰り返し行う必要はなく
なる。
手段として第一インターフェース部８と第二インターフ
ェース部９がある場合であるが、インターフェース手段
として第一インターフェース部８だけの場合でも、上記
の手順からクライアントにアクセス権の要求を通知する
インターフェース手段を管理する手順を削除することで
同様に実施することができる。ただし、この場合には、
利用者は常に同一のインターフェース手段からしかアク
セス権の要求が可能であることの通知を受けることはで
きない。しかし、ビデオサーバ１０がビジー状態である
場合にも、利用者はアクセス権の要求を行うタイミング
がわかり、アクセス権の要求を繰り返し行う必要はなく
なる。
【００３０】なお、本実施の形態では、接続状態管理部
５とデフォルト通知手段管理部３がビデオサーバ１０に
ある場合であるが、接続状態管理部５とデフォルト通知
手段管理部３がビデオサーバ１０にない場合でも、上記
の手順から接続状態が切れている場合に行う手順を削除
することで実現できる。ただし、この場合には、クライ
アントとビデオサーバ１０の接続状態が切れている場合
には、利用者は都合の良い時間やインターフェース手段
でアクセス権の要求が可能であることの通知を受け取る
ことはできない。しかし、ビデオサーバ１０がビジー状
態である場合にも、利用者はアクセス権の要求を行うタ
イミングがわかり、アクセス権の要求を繰り返し行う必
要はなくなる。また、利用者は都合のよいインターフェ
ース手段でアクセス権の要求が可能であることの通知を
受け取ることができる。
５とデフォルト通知手段管理部３がビデオサーバ１０に
ある場合であるが、接続状態管理部５とデフォルト通知
手段管理部３がビデオサーバ１０にない場合でも、上記
の手順から接続状態が切れている場合に行う手順を削除
することで実現できる。ただし、この場合には、クライ
アントとビデオサーバ１０の接続状態が切れている場合
には、利用者は都合の良い時間やインターフェース手段
でアクセス権の要求が可能であることの通知を受け取る
ことはできない。しかし、ビデオサーバ１０がビジー状
態である場合にも、利用者はアクセス権の要求を行うタ
イミングがわかり、アクセス権の要求を繰り返し行う必
要はなくなる。また、利用者は都合のよいインターフェ
ース手段でアクセス権の要求が可能であることの通知を
受け取ることができる。
【００３１】
【発明の効果】以上のように本発明によれば、リクエス
ト処理手段が、ストリームサーバからストリームの送信
に関わるリソースの空きがあることの通知をうけると、
キュー管理手段から得られる情報に基づき、ストリーム
サーバにアクセス権の要求を行う。それと同時に、キュ
ー管理手段から得られる要求識別子に対応するクライア
ントにアクセス権の要求が可能であることをインターフ
ェース手段を通じて通知する。このため、ビデオサーバ
の利用者は、アクセス権の要求を行うためのタイミング
がわかり、アクセス権の要求を繰り返し行う必要のない
ビデオサーバシステムを実現できる。
ト処理手段が、ストリームサーバからストリームの送信
に関わるリソースの空きがあることの通知をうけると、
キュー管理手段から得られる情報に基づき、ストリーム
サーバにアクセス権の要求を行う。それと同時に、キュ
ー管理手段から得られる要求識別子に対応するクライア
ントにアクセス権の要求が可能であることをインターフ
ェース手段を通じて通知する。このため、ビデオサーバ
の利用者は、アクセス権の要求を行うためのタイミング
がわかり、アクセス権の要求を繰り返し行う必要のない
ビデオサーバシステムを実現できる。
【００３２】また、本発明によれば、通知手段管理手段
をビデオサーバに付加することで、利用者が望むインタ
ーフェース手段でアクセス権の要求が可能であることの
通知を受けとることが可能なビデオサーバシステムを実
現できる。
をビデオサーバに付加することで、利用者が望むインタ
ーフェース手段でアクセス権の要求が可能であることの
通知を受けとることが可能なビデオサーバシステムを実
現できる。
【００３３】さらに、本発明によれば、接続状態管理手
段及びデフォルト通知手段管理手段をビデオサーバシス
テムに付加することで、クライアントとビデオサーバと
の接続状態が切断状態である場合でも、利用者は都合の
よい時間やインタフェース手段で、アクセス権の要求が
可能であることの通知を受けとることが可能なビデオサ
ーバシステムを実現できる。
段及びデフォルト通知手段管理手段をビデオサーバシス
テムに付加することで、クライアントとビデオサーバと
の接続状態が切断状態である場合でも、利用者は都合の
よい時間やインタフェース手段で、アクセス権の要求が
可能であることの通知を受けとることが可能なビデオサ
ーバシステムを実現できる。
【００３４】さらに、本発明によれば、リクエスト処理
手段に、クライアントにアクセス権の要求が可能である
ことの通知をした後、一定期間内にクライアントからの
アクセス権の要求がない場合に、ストリームサーバにア
クセス権の取り消しを要求する機能を付加する。こうす
ることで、ストリームの送信のためのリソースを効率的
に使用するビデオサーバシステムを実現できる。
手段に、クライアントにアクセス権の要求が可能である
ことの通知をした後、一定期間内にクライアントからの
アクセス権の要求がない場合に、ストリームサーバにア
クセス権の取り消しを要求する機能を付加する。こうす
ることで、ストリームの送信のためのリソースを効率的
に使用するビデオサーバシステムを実現できる。
【図１】 本発明の実施の形態におけるビデオサーバシ
ステムのブロック図。
ステムのブロック図。
【図２】 本発明の実施の形態におけるビデオサーバシ
ステムを用いたビデオオンデマンドシステムのシステム
構成図。
ステムを用いたビデオオンデマンドシステムのシステム
構成図。
【図３】 本発明の実施の形態における通知手段管理部
が保持する通知手段管理テーブル。
が保持する通知手段管理テーブル。
【図４】 本発明の実施の形態におけるデフォルト通知
手段管理部が保持するデフォルト手段管理テーブル。
手段管理部が保持するデフォルト手段管理テーブル。
【図５】 本発明の実施の形態における接続状態管理部
が保持する接続状態管理テーブル。
が保持する接続状態管理テーブル。
【図６】 本発明の実施の形態におけるリクエスト処理
部が保持する要求管理テーブル。
部が保持する要求管理テーブル。
【図７】 本発明の実施の形態におけるリクエスト処理
部が行う処理の全体を示すフローチャート。
部が行う処理の全体を示すフローチャート。
【図８】 本発明の実施の形態におけるリクエスト処理
部が第一インターフェース手段からアクセス権の要求を
通知された時の処理を示すフローチャート。
部が第一インターフェース手段からアクセス権の要求を
通知された時の処理を示すフローチャート。
【図９】 本発明の実施の形態におけるリクエスト処理
部がストリームサーバからストリームの送信に関わるリ
ソースの空きがあることを通知された時の処理を示すフ
ローチャート。
部がストリームサーバからストリームの送信に関わるリ
ソースの空きがあることを通知された時の処理を示すフ
ローチャート。
【図１０】 本発明の実施の形態におけるリクエスト処
理部がタイマからタイムアウトを通知された時の処理を
示すフローチャート。
理部がタイマからタイムアウトを通知された時の処理を
示すフローチャート。
１ リクエスト処理部
２ ストリームサーバ
３ デフォルト通知手段管理部
４ 通知手段管理部
５ 接続状態管理部
６ キュー管理部
７ タイマ
８ 第一インターフェース部（第一Ｉ／Ｆ部）
９ 第二インターフェース部（第一Ｉ／Ｆ部）
１０ ビデオサーバ
１１ セットトップボックス
１２ 電話端末
１３ 第一ネットワーク
１４ 第二ネットワーク
２０ 時計
３１ 通知手段管理テーブル
３２ デフォルト通知手段管理テーブル
３３ 接続状態管理テーブル
３４ 要求管理テーブル
Ｃ１ 第一通信路
Ｃ２ 第二通信路
Ｃ３ 第三通信路
─────────────────────────────────────────────────────
フロントページの続き
(51)Int.Cl.7 識別記号 ＦＩ
Ｈ０４Ｎ 7/173 Ｈ０４Ｎ 5/93 Ｅ
(72)発明者 大津 隆史
大阪府門真市大字門真1006番地 松下電
器産業株式会社内
(72)発明者 井出 剛氏
大阪府門真市大字門真1006番地 松下電
器産業株式会社内
(56)参考文献 特開 平８−18947（ＪＰ，Ａ)
特開 平８−205120（ＪＰ，Ａ)
(58)調査した分野(Int.Cl.7，ＤＢ名)
H04N 7/24 - 7/68
H04N 5/91 - 5/95
Claims (4)
- 【請求項１】 クライアントからの要求にもとづきスト
リームを送信するビデオサーバシステムであって、 ストリームの送信に関わるリソースの確保（以下、アク
セス権と称す）を行う機能とストリームの送信に関わる
リソースの空きを通知する機能とを有したストリームサ
ーバ、 クライアントによるアクセス権の要求を識別する要求識
別子を保持するキュー管理手段、 クライアントとの通信をつかさどる第一インターフェー
ス手段及び前記ストリームサーバからのリソースの空き
の通知と前記キュー管理手段で管理されている前記要求
識別子に基づきクライアントのアクセス権の要求を処理
する機能と前記キュー管理手段から得られる前記要求識
別子に対応する前記クライアントにアクセス権の要求が
可能であることを前記第一インターフェース手段を通じ
て通知する機能を持つリクエスト処理手段を備えたこと
を特徴とするビデオサーバシステム。 - 【請求項２】 クライアントからの要求にもとづきスト
リームを送信するビデオサーバシステムであって、 ストリームの送信に関わるリソースの確保（以下、アク
セス権と称す）を行う機能とストリームの送信に関わる
リソースの空きを通知する機能とを有したストリームサ
ーバ、 クライアントによるアクセス権の要求を識別する要求識
別子を保持するキュー管理手段、 クライアントとの通信をつかさどる第一インターフェー
ス手段、 前記第一インターフェース手段とは異なる少なくとも一
つ以上のインタフェース手段、 アクセス権の要求が可能であることを通知するインター
フェース手段を表す識別情報を利用者毎に対応づけて管
理する通知手段管理手段及び前記ストリームサーバから
のリソースの空きの通知と前記キュー管理手段で管理さ
れている前記要求識別子に基づきクライアントのアクセ
ス権の要求を処理する機能と前記キュー管理手段で管理
されている前記要求識別子に対応する前記クライアント
にアクセス権の要求が可能であることを前記通知手段管
理手段で管理されている前記識別情報に対応するインタ
フェース手段を通じて通知する機能とを持つリクエスト
処理手段を備えたことを特徴とするビデオサーバシステ
ム。 - 【請求項３】 クライアントとビデオサーバとの接続状
態を管理する接続状態管理手段及びクライアントの接続
状態が切断状態である時に使用するアクセス権の要求が
可能であることを通知するインターフェース手段を示す
識別情報を利用者や時間に関連づけて管理するデフォル
ト通知手段管理手段を備え、 前記リクエスト処理手段が前記接続状態管理手段で管理
されているクライアントの接続状態と前記デフォルト通
知手段管理手段で管理されている情報に基づきクライア
ントの接続状態が切断状態である時にクライアントにア
クセス権の要求が可能であることを通知するインターフ
ェース手段を示す識別情報を前記通知手段管理手段に登
録する機能を備えたことを特徴とする請求項２に記載の
ビデオサーバシステム。 - 【請求項４】 前記リクエスト処理手段は、アクセス権
の要求が可能であることをクライアントに通知した後の
一定期間内にクライアントからのアクセス権の要求がな
い場合にストリームサーバにアクセス権の取り消しを要
求する機能を有したことを特徴とする請求項１乃至請求
項３に記載のビデオサーバシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26087596A JP3383524B2 (ja) | 1996-10-01 | 1996-10-01 | ビデオサーバシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26087596A JP3383524B2 (ja) | 1996-10-01 | 1996-10-01 | ビデオサーバシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10108156A JPH10108156A (ja) | 1998-04-24 |
| JP3383524B2 true JP3383524B2 (ja) | 2003-03-04 |
Family
ID=17353973
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP26087596A Expired - Fee Related JP3383524B2 (ja) | 1996-10-01 | 1996-10-01 | ビデオサーバシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3383524B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3673085B2 (ja) * | 1998-07-08 | 2005-07-20 | シャープ株式会社 | 通信ネットワークにおける簡易セキュリティ設定方法およびそのための装置、ならびに通信ネットワークにおける簡易セキュリティ設定プログラムを記録したコンピュータで読取可能な記録媒体 |
| KR100668207B1 (ko) * | 1999-12-13 | 2007-01-11 | 주식회사 케이티 | 실시간 자원 관측에 기반한 사용자 수용 제어 방법 |
| US11343380B2 (en) | 2004-03-16 | 2022-05-24 | Icontrol Networks, Inc. | Premises system automation |
| US12063220B2 (en) | 2004-03-16 | 2024-08-13 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US12063221B2 (en) | 2006-06-12 | 2024-08-13 | Icontrol Networks, Inc. | Activation of gateway device |
| US11706279B2 (en) | 2007-01-24 | 2023-07-18 | Icontrol Networks, Inc. | Methods and systems for data communication |
| US20220078253A1 (en) * | 2007-06-12 | 2022-03-10 | Icontrol Networks, Inc. | Controlling data routing among networks |
| US11758026B2 (en) | 2008-08-11 | 2023-09-12 | Icontrol Networks, Inc. | Virtual device systems and methods |
| US8638211B2 (en) | 2009-04-30 | 2014-01-28 | Icontrol Networks, Inc. | Configurable controller and interface for home SMA, phone and multimedia |
| US11750414B2 (en) | 2010-12-16 | 2023-09-05 | Icontrol Networks, Inc. | Bidirectional security sensor communication for a premises security system |
| US9147337B2 (en) | 2010-12-17 | 2015-09-29 | Icontrol Networks, Inc. | Method and system for logging security event data |
-
1996
- 1996-10-01 JP JP26087596A patent/JP3383524B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10108156A (ja) | 1998-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6023722A (en) | High-availability WWW computer server system with pull-based load balancing using a messaging and queuing unit in front of back-end servers | |
| US5227778A (en) | Service name to network address translation in communications network | |
| JP4005363B2 (ja) | 階層的構造に基づくインターネット・ブロードキャスティング・データを提供するシステム及び方法 | |
| JP2003018326A (ja) | 通信サービス取引方法および通信システム | |
| US20030099197A1 (en) | Congestion control system and method for web service | |
| JP3383524B2 (ja) | ビデオサーバシステム | |
| US8577348B2 (en) | System architecture, and method for scheduled downloading services | |
| JP2000057072A (ja) | データ転送方式 | |
| JP2000032037A (ja) | 電子メール送受信方法及びそのシステム並びにプログラムを記録した機械読み取り可能な記録媒体 | |
| KR102321889B1 (ko) | 미디어 다운링크 전송 제어 방법 및 관련 장치 | |
| JPH01233949A (ja) | 準予約通信サービス処理方式 | |
| KR100937681B1 (ko) | 사용자간 통신을 위한 통신 모듈 및 방법, 그러한 통신 모듈을 포함하는 서버, 그러한 서버를 포함하는 방송 세트, 그러한 사용자간 통신 방법을 수행하는 컴퓨터 프로그램 제품을 저장한 저장 매체 | |
| JP3487425B2 (ja) | 輻輳制御方法及び方式 | |
| CN113347158A (zh) | 一种流媒体数据收发方法、装置及电子设备 | |
| JP2003288298A (ja) | プッシュサービス情報中継装置およびプッシュサービス情報中継方法 | |
| JPH11331812A (ja) | 動画データ配信用代理サーバおよび動画データ配信方法 | |
| JP2000244552A (ja) | ファイル転送装置 | |
| JP4046562B2 (ja) | 負荷分散方法 | |
| US7904506B2 (en) | Context information management system | |
| JP2002344504A (ja) | コンピュータネットワーク資源割当方法及び資源管理型コンピュータネットワークシステム及びリソース管理サーバ及びエッジスイッチ及びコンピュータネットワーク資源割当プログラム及びコンピュータネットワーク資源割当プログラムを格納した記憶媒体 | |
| KR20030052646A (ko) | 멀티캐스팅을 이용한 인스턴트 메신저 서비스의 다자간접속방법 | |
| JP2000040041A (ja) | インターネットプロトコルバーション変換用入出力同期方法及びシステム及びネットワークパケット受信処理用アプリケーション及びネットワークパケット受信処理用サーバ及びインターネットプロトコルバーション変換用入出力同期プログラムを格納した記憶媒体 | |
| JPH10177510A (ja) | クライアント・サーバ・システム | |
| JP4066622B2 (ja) | 輻輳制御システムと方法およびロケーションサーバならびにプログラムと記録媒体 | |
| JP2924452B2 (ja) | 情報転送方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071220 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081220 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |