JP3917124B2 - 画像蓄積配信システムの帯域制御方式 - Google Patents
画像蓄積配信システムの帯域制御方式 Download PDFInfo
- Publication number
- JP3917124B2 JP3917124B2 JP2003361006A JP2003361006A JP3917124B2 JP 3917124 B2 JP3917124 B2 JP 3917124B2 JP 2003361006 A JP2003361006 A JP 2003361006A JP 2003361006 A JP2003361006 A JP 2003361006A JP 3917124 B2 JP3917124 B2 JP 3917124B2
- Authority
- JP
- Japan
- Prior art keywords
- value
- bandwidth
- image
- image data
- importance
- 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
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Television Signal Processing For Recording (AREA)
- Closed-Circuit Television Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
本発明は、カメラで撮影された画像データを蓄積し、また、ユーザであるクライアント端末へ蓄積した画像データを配信する画像蓄積配信システムに関し、特に、ネットワークの負荷の増大やシステムハードウェアの処理負荷の増大等に起因した輻輳によって実効帯域が狭まった時に対処する帯域制御方式に関する。
ネットワーク通信の普及により、カメラで撮影された画像（動画像、静止画像、静止画像が時系列に連続した間欠的な準動画像等）を、遠隔地のユーザがパーソナルコンピュータやモバイルツール等のクライアント装置で画面表示することができるシステムが実施されている。
このようなシステムは、種々な用途に利用されており、例えば、画像により侵入者や管理対象物の異常を監視する監視システムとして利用されている。
このようなシステムは、種々な用途に利用されており、例えば、画像により侵入者や管理対象物の異常を監視する監視システムとして利用されている。
クライアント装置への画像データの配信は、カメラで撮影した画像データをサーバに蓄積し、当該サーバからクライアント装置へ配信する形態が一般的であるが、複数のカメラに対する蓄積処理や複数のクライアント装置に対する配信処理が輻輳してしまう場合があり、蓄積や配信の処理に係る処理を効率的に行う必要がある。
蓄積処理や配信処理に係る負荷の１つとしては、ネットワーク通信路の伝送帯域の減少があり、従来では、マルチメディア通信を行う通信路の伝送帯域の変動に応じて、メディア情報の種類に応じた符号化方式を切り換えて、メディア情報の種類に応じた態様で通信する方法が提案されている。
特開平１１―３１３０４８号公報
蓄積処理や配信処理に係る負荷の１つとしては、ネットワーク通信路の伝送帯域の減少があり、従来では、マルチメディア通信を行う通信路の伝送帯域の変動に応じて、メディア情報の種類に応じた符号化方式を切り換えて、メディア情報の種類に応じた態様で通信する方法が提案されている。
従来、一般的には、あらかじめシステムハードウェアの性能とネットワーク帯域を測定しておき、画像データの蓄積や配信に用いる帯域の合計値を十分にまかなえる余裕をもった能力にシステムを設定することが行われている。
しかしながら、ネットワークの通信負荷やシステムハードウエア処理の負荷の増大といった輻輳は外的要因であり、あらかじめ予測することは困難である。
しかしながら、ネットワークの通信負荷やシステムハードウエア処理の負荷の増大といった輻輳は外的要因であり、あらかじめ予測することは困難である。
このような外的要因が発生しても蓄積と配信が十分に行える帯域値をリミッター値として設する方法も考えられるが、リミッター値を設けると、外的要因が発生していない時には、無駄に性能を落としていることになる。また、リミッター値は予測に基づくものであるので、実際の生ずる外的要因によっては、蓄積や配信の使用帯域の合計値がリミッター値未満の場合においても、蓄積または配信に影響する場合もありえる。
更に、外的要因によって蓄積や配信に影響が出る場合、重要なところ影響がでるか、比較的重要でないところ影響がでるか制御できないため、画像データの重要性に応じた制御を行うことができない。
更に、外的要因によって蓄積や配信に影響が出る場合、重要なところ影響がでるか、比較的重要でないところ影響がでるか制御できないため、画像データの重要性に応じた制御を行うことができない。
本発明は、上記従来の事情に鑑みなされたもので、画像データの蓄積や配信処理に際して、対象となるカメラやクライアント装置の重要性に応じた帯域制御を行うことにより、重要性に応じた動的な制御を実現することを目的とする。
なお、本発明の更なる目的は、以下に説明するところにより明らかである。
なお、本発明の更なる目的は、以下に説明するところにより明らかである。
本発明に係る帯域制御方式は、カメラで撮影された画像データを取得して蓄積し、当該蓄積された画像データをクライアント装置へ配信する画像蓄積配信システムにおいて、カメラ側とクライアント装置側との少なくとも一方について重要性を示す値を設定し、カメラ又はクライアント装置とのネットワークを介した画像データ通信処理に係る実効帯域の低下を検知し、実効帯域低下を検知した場合に、重要性の低いカメラ又はクライアント装置に対する処理の帯域制限を行って帯域使用量を減らすことにより、重要性の高いカメラ又はクライアント装置に対する処理の帯域を確保することを特徴とする。
より具体的には、本発明では、蓄積を行う画像データのカメラや画像データの配信をするクライアント装置に重要性を示す値を設け、外的要因によって通信帯域の低下等の輻輳を検知する手段を設け、重要性の低い画像データに対する帯域使用量を減らすことによって、重要性の高い画像データの帯域を確保する。
より具体的には、本発明では、蓄積を行う画像データのカメラや画像データの配信をするクライアント装置に重要性を示す値を設け、外的要因によって通信帯域の低下等の輻輳を検知する手段を設け、重要性の低い画像データに対する帯域使用量を減らすことによって、重要性の高い画像データの帯域を確保する。
本発明によると、カメラで撮影された画像データの蓄積やクライアント装置への画像データの配信を行う画像蓄積配信システムにおいて、輻輳によって帯域が狭まった場合には、重要性の低い画像データから帯域使用量を減らし、重要な画像データほど輻輳の影響を受け難くして、必要な画像を確実に利用することができる環境を実現することができる。
本発明を図に示す実施形態を例にとって具体的に説明する。
図１は、本実施形態に係る蓄積配信帯域制御方式が適用される画像蓄積配信システムの全体構成を示す。
画像蓄積配信システムは、画像データ（音声データを含むものであってもよい）を蓄積するための記録装置（以降、ディスク装置と称する）３を備えた画像蓄積配信サーバ１と、ネットワーク４を介して画像蓄積配信サーバ１に接続される複数のＷＥＢカメラ５(５−１〜５−ｎ）及び複数のクライアント端末６（６−１〜６−ｍ）とを有して構成されている。
ここで、ｎ及びｍは自然数であり、ｎとｍとはシステム実施時に設定されるＷＥＢカメラ５とクライアント端末６との個数である。
図１は、本実施形態に係る蓄積配信帯域制御方式が適用される画像蓄積配信システムの全体構成を示す。
画像蓄積配信システムは、画像データ（音声データを含むものであってもよい）を蓄積するための記録装置（以降、ディスク装置と称する）３を備えた画像蓄積配信サーバ１と、ネットワーク４を介して画像蓄積配信サーバ１に接続される複数のＷＥＢカメラ５(５−１〜５−ｎ）及び複数のクライアント端末６（６−１〜６−ｍ）とを有して構成されている。
ここで、ｎ及びｍは自然数であり、ｎとｍとはシステム実施時に設定されるＷＥＢカメラ５とクライアント端末６との個数である。
例えば、５−１はチャネル１（ＣＨ１）用のＷＥＢカメラ、５−２はチャネル２（ＣＨ２）用のＷｅｂカメラ、・・・、５−ｎはチャネルｎ（ＣＨｎ）用のＷｅｂカメラであり、Ｗｅｂカメラ５−１〜５−ｎは、それぞれを特定できるチャネル番号を有し、撮影された画像の各フレームを、例えばＪＰＥＧ等の画像圧縮方式で圧縮し、圧縮された画像データをＩＰパケット形式でネットワーク４を介して画像蓄積配信サーバ１に送信する。
本例の画像蓄積配信サーバ１は、Ｗｅｂカメラ５−１〜５−ｎからネットワーク４を介して受信した各パケットから圧縮された画像データ（以下、単に画像データと言う）を抽出し、ディスク装置３にあらかじめチャネル別に確保されたチャネル用記録領域７（７−１〜７−ｎ）に書き込んで記録する。
本例の画像蓄積配信サーバ１は、Ｗｅｂカメラ５−１〜５−ｎからネットワーク４を介して受信した各パケットから圧縮された画像データ（以下、単に画像データと言う）を抽出し、ディスク装置３にあらかじめチャネル別に確保されたチャネル用記録領域７（７−１〜７−ｎ）に書き込んで記録する。
以下に説明する実施形態では、Ｗｅｂカメラ５はＪＰＥＧ画像データを出力するカメラとし、画像蓄積配信サーバ１がいずれかのＷｅｂカメラ５に対して要求を送信すると、当該Ｗｅｂカメラ５が１枚のＪＰＥＧ画像データを画像蓄積配信サーバ１へ送信するといったように、１つの要求がある毎に１フレームのＪＰＥＧ画像データがＷｅｂカメラ５から画像蓄積配信サーバ１へ送信されて蓄積されるようにしている。また、実施形態では、クライアント端末６への画像データ配信についても同様であり、いずれかのクライアント端末６から１つの要求がある毎に画像蓄積配信サーバ１に蓄積されている１フレームのＪＰＥＧ画像データが画像蓄積配信サーバ１から当該クライアント端末６へ送信されるようにしている。
すなわち、本実施形態では、要求がある毎に画像データを１フレームずつネットワーク４を介して通信する方法を採用しているが、要求がある毎に画像データを複数フレーム分（あるいは１ファイル分）通信するようにしてもよい。また、本実施形態では、Ｗｅｂカメラ５から出力される画像データは間欠的に時系列に連続した準動画像であるが、本発明では、例えば、Ｗｅｂカメラ５をＭＰＥＧ画像データを出力するカメラとして、要求がある毎にＭＰＥＧ形式の動画像データを所定の長さ分通信するようにしてもよい。
すなわち、本実施形態では、要求がある毎に画像データを１フレームずつネットワーク４を介して通信する方法を採用しているが、要求がある毎に画像データを複数フレーム分（あるいは１ファイル分）通信するようにしてもよい。また、本実施形態では、Ｗｅｂカメラ５から出力される画像データは間欠的に時系列に連続した準動画像であるが、本発明では、例えば、Ｗｅｂカメラ５をＭＰＥＧ画像データを出力するカメラとして、要求がある毎にＭＰＥＧ形式の動画像データを所定の長さ分通信するようにしてもよい。
Ｗｅｂカメラ５から画像蓄積配信サーバ１が取得する１フレーム分の画像データのサイズは、画像画素数、圧縮指定値によって異なる。
図３は、本実施形態で使用するＷｅｂカメラ５の画像画素数と圧縮指定値とに対する１フレームの画像データサイズの関係を示す。
画像蓄積配信サーバ１がＷｅｂカメラ５からネットワーク４を介して画像データを取得するために使用する帯域は、１フレーム毎の画像データサイズと、フレームレートの積で求まる。後述するように、画像データサイズを規定する画像画素数や圧縮指定値、更には、フレームレートは、画像蓄積配信サーバ１が画像要求とともにＷｅｂカメラ５に通知し、これによって、画像蓄積配信サーバ１による管理下で、Ｗｅｂカメラ５から画像データを取得するに際しての帯域制御が実行される。
図３は、本実施形態で使用するＷｅｂカメラ５の画像画素数と圧縮指定値とに対する１フレームの画像データサイズの関係を示す。
画像蓄積配信サーバ１がＷｅｂカメラ５からネットワーク４を介して画像データを取得するために使用する帯域は、１フレーム毎の画像データサイズと、フレームレートの積で求まる。後述するように、画像データサイズを規定する画像画素数や圧縮指定値、更には、フレームレートは、画像蓄積配信サーバ１が画像要求とともにＷｅｂカメラ５に通知し、これによって、画像蓄積配信サーバ１による管理下で、Ｗｅｂカメラ５から画像データを取得するに際しての帯域制御が実行される。
クライアント端末６は、画像蓄積配信サーバ１に対して、配信要求とともにチャネル番号とフレーム番号を通知指定し、指定に対応する画像データの配信を要求する。このクライアント端末６からの要求に応じて、画像蓄積配信サーバ１は、ディスク装置３に蓄積された対応するチャネル番号とフレーム番号の画像データをＩＰパケット形式で要求元のクライアント端末６にネットワーク４を介して送信する。
画像蓄積配信サーバ１がクライアント端末６に画像データを送信するために使用する帯域は、１フレーム毎の画像サイズと、フレームレートの積で求まる。後述するように、本実施形態におけるクライアント端末６に対する配信処理では、画像蓄積配信サーバ１がクライアント端末６に待機要求時間値を通知することによりフレームレートだけを制御して比較的単純な方法で帯域制御を実行するが、本発明では、上記のＷｅｂカメラ５側に対すると同様に送信する画像データサイズも制御するようにしてもよい。
画像蓄積配信サーバ１がクライアント端末６に画像データを送信するために使用する帯域は、１フレーム毎の画像サイズと、フレームレートの積で求まる。後述するように、本実施形態におけるクライアント端末６に対する配信処理では、画像蓄積配信サーバ１がクライアント端末６に待機要求時間値を通知することによりフレームレートだけを制御して比較的単純な方法で帯域制御を実行するが、本発明では、上記のＷｅｂカメラ５側に対すると同様に送信する画像データサイズも制御するようにしてもよい。
図１に示すように、画像蓄積配信サーバ１は帯域制御を実現するために必要な機能として、帯域制御用情報テーブル８と負荷監視スレッド９とを有している。上記のような帯域制御は、画像蓄積配信サーバ１内のメモリ上に存在する帯域制御用情報テーブル８を用いて、蓄積配信サーバ１上にて実行するプログラムモジュールである負荷監視スレッド９が行なう。
負荷監視スレッド９は、後に詳述するように、時系列な画像データの蓄積と配信の実効帯域及びディスク３の状態を監視し、これらの処理に輻輳（ここでの輻輳とは、ネットワーク通信処理に係る輻輳とシステムハードウエアの負荷増大による輻輳との両方の概念を含む）の発生を検知した際には、帯域制御用情報テーブル８に従って輻輳を解消させるための帯域制御を行ない、輻輳の解消を検知した際には、帯域制御を行なった逆順で帯域制御を解除する処理を行う。
負荷監視スレッド９は、後に詳述するように、時系列な画像データの蓄積と配信の実効帯域及びディスク３の状態を監視し、これらの処理に輻輳（ここでの輻輳とは、ネットワーク通信処理に係る輻輳とシステムハードウエアの負荷増大による輻輳との両方の概念を含む）の発生を検知した際には、帯域制御用情報テーブル８に従って輻輳を解消させるための帯域制御を行ない、輻輳の解消を検知した際には、帯域制御を行なった逆順で帯域制御を解除する処理を行う。
ここで、本実施形態では、画像蓄積配信サーバ１において、Ｗｅｂカメラ５からの画像データの受信及びクライアント端末６への画像データの配信の間隔が１秒以下の場合においてのみ帯域制御を行なう。
これは、画像データの受信や配信が１秒間に１回（１フレーム）程度であれば、ネットワーク通信上やシステムハードウエア処理上の輻輳は問題とならず、帯域制御を行うまでもないという知見に基づいているが、例えば、通信処理負担やシステムハードウエア処理負担が大きい設定である場合には１秒より長い時間間隔において帯域制御を行うようにしてもよく、要は、当該時間間隔は画像蓄積配信システムの実施上の必要に応じて任意に設定されればよい。
これは、画像データの受信や配信が１秒間に１回（１フレーム）程度であれば、ネットワーク通信上やシステムハードウエア処理上の輻輳は問題とならず、帯域制御を行うまでもないという知見に基づいているが、例えば、通信処理負担やシステムハードウエア処理負担が大きい設定である場合には１秒より長い時間間隔において帯域制御を行うようにしてもよく、要は、当該時間間隔は画像蓄積配信システムの実施上の必要に応じて任意に設定されればよい。
図２は、本実施形態に係る画像蓄積配信サーバ１のハードウエア構成を示す。
画像蓄積配信サーバ１は、プロセッサ１０と、プロセッサ１０が実行する各種のプログラムを格納したプログラム格納メモリ１１と、Ｗｅｂカメラ５からの画像データの受信及びクライアント端末６への画像データの配信の帯域制御に必要な情報がテーブル化されている帯域制御用情報テーブル８と、送受信する画像フレームのバッファ領域及び書込／読出し画像データのキャッシュ領域として利用されるデータ格納メモリ１２を有している。
また、画像蓄積配信サーバ１は、ネットワーク４に接続するためのネットワークインターフェイス１４と、ＴＣＰ/ＩＰスタック１５と、ディスク装置３の接続インターフェイスとなるファイバーチャネルドライバ１６及びファイバーチャネルインターフェイス１７を有している。
画像蓄積配信サーバ１は、プロセッサ１０と、プロセッサ１０が実行する各種のプログラムを格納したプログラム格納メモリ１１と、Ｗｅｂカメラ５からの画像データの受信及びクライアント端末６への画像データの配信の帯域制御に必要な情報がテーブル化されている帯域制御用情報テーブル８と、送受信する画像フレームのバッファ領域及び書込／読出し画像データのキャッシュ領域として利用されるデータ格納メモリ１２を有している。
また、画像蓄積配信サーバ１は、ネットワーク４に接続するためのネットワークインターフェイス１４と、ＴＣＰ/ＩＰスタック１５と、ディスク装置３の接続インターフェイスとなるファイバーチャネルドライバ１６及びファイバーチャネルインターフェイス１７を有している。
帯域制御用情報テーブル８には、図８を参照して後述する帯域制御に必要な主要データに加えて、図３〜図７に示す帯域制御に必要な参照データを記憶している。
図３は上記のようにＷｅｂカメラ５の画像データサイズ特性を示すデータであり、画像蓄積配信サーバ１は、当該画像データサイズ特性を参照することにより、画像画素数と圧縮指定値からＷｅｂカメラ５が出力する画像データのバイトサイズを求めることができ、そして、画像画素数及び／又は圧縮指定値を画像要求とともに通知することにより、Ｗｅｂカメラ５から受信処理する画像データのバイトサイズを制御することができる。
図３は上記のようにＷｅｂカメラ５の画像データサイズ特性を示すデータであり、画像蓄積配信サーバ１は、当該画像データサイズ特性を参照することにより、画像画素数と圧縮指定値からＷｅｂカメラ５が出力する画像データのバイトサイズを求めることができ、そして、画像画素数及び／又は圧縮指定値を画像要求とともに通知することにより、Ｗｅｂカメラ５から受信処理する画像データのバイトサイズを制御することができる。
図４〜図６は、 Ｗｅｂカメラ５の画像品質値を規定するテーブルであり、このＷｅｂカメラの画像品質値は、蓄積配信サーバ１がＷｅｂカメラ５から画像データを取得するために使用する帯域を規定する値である。
図示の例では、Ｗｅｂカメラ映像品質値が大きくなるほど、Ｗｅｂカメラ５から画像データを取得するために使用する帯域が小さくなるように設定されている。
また、本実施形態では、図４〜図６に示す３種類の画像品質値テーブルが用意されており、後述するように、Ｗｅｂカメラ毎にいずれかの画像品質値テーブルに従った帯域制御方法が選択可能となっている。
図示の例では、Ｗｅｂカメラ映像品質値が大きくなるほど、Ｗｅｂカメラ５から画像データを取得するために使用する帯域が小さくなるように設定されている。
また、本実施形態では、図４〜図６に示す３種類の画像品質値テーブルが用意されており、後述するように、Ｗｅｂカメラ毎にいずれかの画像品質値テーブルに従った帯域制御方法が選択可能となっている。
図４は、画像画素数、圧縮指定値、フレームレートに関わらず、使用帯域の大きい順に画像品質値を割り付けたテーブルであり、蓄積配信サーバ１からＷｅｂカメラ５が出力する画像データの画像画素数、圧縮指定値、フレームレートの全ての変更を行う時に使用する。すなわち、帯域制御を行う場合に、蓄積配信サーバ１は画像要求とともに画像画素数、圧縮指定値、フレームレートを指定通知し、Ｗｅｂカメラ５が指定に従って画像データを送信するように制御する。
図５は、画像画素数を固定し、圧縮指定値とフレームレートとを変数として、使用帯域の大きい順に映像品質値を割り付けたテーブルであり、蓄積配信サーバ１からＷｅｂカメラ５が出力する画像データの圧縮指定値とフレームレートとの変更を行う時に使用する。すなわち、帯域制御を行う場合に、蓄積配信サーバ１は画像要求とともに圧縮指定値とフレームレートとを指定通知し、Ｗｅｂカメラ５が指定に従って画像データを送信するように制御する。
図６は、画像画素数と圧縮指定値を固定し、フレームレートを変数として、使用帯域の大きい順に映像品質値を割り付けたテーブルであり、蓄積配信サーバ１からＷｅｂカメラ５が出力する画像データのフレームレート変更しか行なわない時に使用する。すなわち、帯域制御を行う場合に、蓄積配信サーバ１は画像要求とともにフレームレートを指定通知し、Ｗｅｂカメラ５が指定に従って画像データを送信するように制御する。
図５は、画像画素数を固定し、圧縮指定値とフレームレートとを変数として、使用帯域の大きい順に映像品質値を割り付けたテーブルであり、蓄積配信サーバ１からＷｅｂカメラ５が出力する画像データの圧縮指定値とフレームレートとの変更を行う時に使用する。すなわち、帯域制御を行う場合に、蓄積配信サーバ１は画像要求とともに圧縮指定値とフレームレートとを指定通知し、Ｗｅｂカメラ５が指定に従って画像データを送信するように制御する。
図６は、画像画素数と圧縮指定値を固定し、フレームレートを変数として、使用帯域の大きい順に映像品質値を割り付けたテーブルであり、蓄積配信サーバ１からＷｅｂカメラ５が出力する画像データのフレームレート変更しか行なわない時に使用する。すなわち、帯域制御を行う場合に、蓄積配信サーバ１は画像要求とともにフレームレートを指定通知し、Ｗｅｂカメラ５が指定に従って画像データを送信するように制御する。
図７は、クライアント端末へ配信する画像品質値を示すテーブルであり、このクライアント画像品質値は、蓄積配信サーバ１からクライアント端末６へ画像データを配信するために使用する帯域を規定する値である。
図示の例では、クライアント画像品質値が大きくなるほど、クライアント端末６へ画像データを配信するために使用する帯域は小さくなる要に設定されている。
クライアント画像品質値には、最小要求間隔（ｍｓ）２１と制限帯域（ＫＢ／ｓ）２２とがを割り付けられている。
図示の例では、クライアント画像品質値が大きくなるほど、クライアント端末６へ画像データを配信するために使用する帯域は小さくなる要に設定されている。
クライアント画像品質値には、最小要求間隔（ｍｓ）２１と制限帯域（ＫＢ／ｓ）２２とがを割り付けられている。
最小要求間隔２１は、画像蓄積配信サーバ１がクライアント端末６から画像要求を受け付ける最小の時間間隔を示しており、最小要求間隔２１の値よりも短い時間間隔で、クライアント端末６から画像蓄積配信サーバ１に画像要求があった場合には、画像蓄積配信サーバ１はクライアント端末６に対して、画像データを配信せず、最小要求間隔２１に収まってない旨を示すエラーメッセージと、どのくらいの時間の後なら要求を受け付けるかを示す値である待機要求時間値を送信する。
制限帯域２２は、画像蓄積配信サーバ１からクライアント端末６へ画像データを配信するために使用する帯域の上限を示しており、単位時間あたりの使用帯域が制限帯域２２を越えた時は、画像蓄積配信サーバ１はクライアント端末６に対して、画像データを配信せず、制限帯域２２を超えた旨を示すエラーメッセージと、上記同様の待機要求時間値を、送信する。
制限帯域２２は、画像蓄積配信サーバ１からクライアント端末６へ画像データを配信するために使用する帯域の上限を示しており、単位時間あたりの使用帯域が制限帯域２２を越えた時は、画像蓄積配信サーバ１はクライアント端末６に対して、画像データを配信せず、制限帯域２２を超えた旨を示すエラーメッセージと、上記同様の待機要求時間値を、送信する。
クライアント端末６は、画像蓄積配信サーバ１からエラーメッセージと待機要求時間値を受信した時には、待機要求時間値の時間を待機した後に、あらためて画像蓄積配信サーバ１に対して画像要求を行なう機能を有している。
したがって、このように画像蓄積配信サーバ１がクライアント端末６からの画像要求間隔を伸ばして要求頻度を低下させることにより、クライアント端末６に対する配信処理負荷を低減させる帯域制御が実行される。
なお、本実施形態では、配信処理に係る帯域制御はクライアント端末６毎に設定される品質値に基づいてクライアント端末６毎に必要に応じた帯域制御がなされるが、例えば、異なる最小要求間隔や制限帯域を設定した複数の画像品質値テーブルを用意しておき、クライアント端末（すなわち、ユーザ）に付与した権限に応じてこれら画像品質値テーブルを使い分けるようにしてもよい。
したがって、このように画像蓄積配信サーバ１がクライアント端末６からの画像要求間隔を伸ばして要求頻度を低下させることにより、クライアント端末６に対する配信処理負荷を低減させる帯域制御が実行される。
なお、本実施形態では、配信処理に係る帯域制御はクライアント端末６毎に設定される品質値に基づいてクライアント端末６毎に必要に応じた帯域制御がなされるが、例えば、異なる最小要求間隔や制限帯域を設定した複数の画像品質値テーブルを用意しておき、クライアント端末（すなわち、ユーザ）に付与した権限に応じてこれら画像品質値テーブルを使い分けるようにしてもよい。
図８は、帯域制御用情報テーブル８の主要な内容を示しており、この帯域制御用テーブル８には、Ｗｅｂカメラ側帯域制御用テーブル３０と、クライアント側帯域制御用テーブル４０と、負荷低減処理実施先テーブル５０と、最新負荷低減処理数変更時刻を記憶する領域６０と、負荷低減処理実行数を記憶する領域６１とを有している。
Ｗｅｂカメラ側帯域制御用テーブル３０は、Ｗｅｂカメラ５毎に設けられた、重要度指定値３１、重要度３２、負荷低減貢献値３３、画像品質指定値３４、画像品質値テーブル識別子３５、取得フレーム数測定中値３６、取得フレーム数測定開始時刻３７、前測定時取得フレーム数３８を含んでいる。
Ｗｅｂカメラ側帯域制御用テーブル３０は、Ｗｅｂカメラ５毎に設けられた、重要度指定値３１、重要度３２、負荷低減貢献値３３、画像品質指定値３４、画像品質値テーブル識別子３５、取得フレーム数測定中値３６、取得フレーム数測定開始時刻３７、前測定時取得フレーム数３８を含んでいる。
重要度指定値３１の示す値は自然数であり、本例では「０」を最も重要度が高いとする。重要度指定値３１の示す値は、何段階まで負荷低減貢献値３３を上げられるか、すなわち、映像品質指定値３４から何段階まで図４〜図６に示した画像の品質値を増やせるかを示す値である。すなわち、重要度指定値３１は、使用帯域を何段階まで低減できるかを示す値である。この重要度指定値３１の値は、各Ｗｅｂカメラ５−１〜５−ｎ毎に、あらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。
負荷低減貢献値３３は、現在、画像品質指定値３４から画像品質値を何段階増しているかを示す値であり、つまり、現在、何段階の帯域制限が行なわれているかを示す値である。０≦負荷低減貢献値３３≦重要度指定値３１ の関係である。この負荷低減貢献値３３の値は、画像蓄積配信サーバ１が下記に説明する処理により情況に応じて値を変更する。
負荷低減貢献値３３は、現在、画像品質指定値３４から画像品質値を何段階増しているかを示す値であり、つまり、現在、何段階の帯域制限が行なわれているかを示す値である。０≦負荷低減貢献値３３≦重要度指定値３１ の関係である。この負荷低減貢献値３３の値は、画像蓄積配信サーバ１が下記に説明する処理により情況に応じて値を変更する。
映像品質指定値３４は、Ｗｅｂカメラ５の画像品質値の初期値を示す値であり、この値は、各Ｗｅｂカメラ５−１〜５−ｎ毎にあらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。
重要度３２は、現在の重要度を示す値であり、重要度指定値３１を初期値として、帯域制限が行なわれた回数値を重要度指定値３１から引いた値である。すなわち、重要度３２＝重要度指定値３１−負荷低減貢献値３３の関係であり、０≦重要度３２≦重要度指定値３１の関係である。重要度３２は、上記のような輻輳を検出して帯域制限を行なう際に、どの画像データに帯域制限を行なうかを選択する際に基準として使用する。すなわち、重要性に応じてＷｅｂカメラからの画像データを選択的に帯域制御する。この重要度３２の値は、画像蓄積配信サーバ１が下記に説明する処理により情況に応じて値を変更する。
重要度３２は、現在の重要度を示す値であり、重要度指定値３１を初期値として、帯域制限が行なわれた回数値を重要度指定値３１から引いた値である。すなわち、重要度３２＝重要度指定値３１−負荷低減貢献値３３の関係であり、０≦重要度３２≦重要度指定値３１の関係である。重要度３２は、上記のような輻輳を検出して帯域制限を行なう際に、どの画像データに帯域制限を行なうかを選択する際に基準として使用する。すなわち、重要性に応じてＷｅｂカメラからの画像データを選択的に帯域制御する。この重要度３２の値は、画像蓄積配信サーバ１が下記に説明する処理により情況に応じて値を変更する。
映像品質指定値テーブル識別子３５は、図４〜図６に示すように複数存在する画像品質値テーブルのうちのどの品質値テーブルを使用するかを示す値である。この映像品質指定値テーブル識別子３５の値は、Ｗｅｂカメラ５−１〜５−ｎ毎に、あらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。これにより、図４〜図６に示すテーブルに基づくいずれの方法で帯域を指定するかが設定される。
取得フレーム数測定中値３６は、Ｗｅｂカメラ５からのフレームレートの実効値の測定に用いる値であり、本例では、１０秒間の取得フレーム数からフレームレートを算出する。
取得フレーム数測定開始時刻３７は、取得フレーム数の測定を開始した時刻を示す値であり、取得フレーム数測定開始時刻３７以後に取得したフレーム数が取得フレーム数測定中値３６である。
前測定時取得フレーム数３８は、取得フレーム数測定開始時刻３７の直前１０秒間の取得フレーム数を示す値であり、前回の測定におけるフレームレートを示す値である。
取得フレーム数測定中値３６は、Ｗｅｂカメラ５からのフレームレートの実効値の測定に用いる値であり、本例では、１０秒間の取得フレーム数からフレームレートを算出する。
取得フレーム数測定開始時刻３７は、取得フレーム数の測定を開始した時刻を示す値であり、取得フレーム数測定開始時刻３７以後に取得したフレーム数が取得フレーム数測定中値３６である。
前測定時取得フレーム数３８は、取得フレーム数測定開始時刻３７の直前１０秒間の取得フレーム数を示す値であり、前回の測定におけるフレームレートを示す値である。
すなわち、Ｗｅｂカメラ５から画像データを取得した時刻が、取得フレーム数測定開始時刻３７から１０秒未満であれば、取得フレーム数測定中値３６に取得フレーム数を加算する。一方、Ｗｅｂカメラ５から画像データを取得した時刻が、取得フレーム数測定開始時刻３７から１０秒を超えていた場合には、取得フレーム数測定中値３６を、前測定時取得フレーム数３８にコピーし、取得フレーム数測定開始時刻３７を更新し、取得フレーム数測定中値３６を一旦「０」にクリアした後に取得フレーム数を加算する。
クライアント側帯域制御用テーブル４０は、クライアント端末６毎に設けられた、重要度指定値４１、重要度４２、負荷低減貢献値４３、画像品質指定値４４、使用帯域測定中値４５、使用帯域前回測定値４６、最終アクセス時刻４７を含んでいる。
重要度指定値４１の示す値は、重要度指定値３１と同様であり、自然数であり「０」が最も重要度が高いとする。重要度指定値４１の示す値は、何段階まで負荷低減貢献値４３を上げられるか、画像品質指定値４４から何段階まで画像品質値を増やせるかを示す値でもある。この重要度指定値４１の値は、クライアント端末の権限毎に、あらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。
重要度指定値４１の示す値は、重要度指定値３１と同様であり、自然数であり「０」が最も重要度が高いとする。重要度指定値４１の示す値は、何段階まで負荷低減貢献値４３を上げられるか、画像品質指定値４４から何段階まで画像品質値を増やせるかを示す値でもある。この重要度指定値４１の値は、クライアント端末の権限毎に、あらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。
負荷低減貢献値４３は、負荷低減貢献値３３と同様であり、現在、画像品質指定値４４から画像品質値を何段階増しているかを示す値である。０≦負荷低減貢献値４３≦重要度指定値４１の関係である。この負荷低減貢献値４３の値は、画像蓄積配信サーバ１が下記の処理により情況に応じて値を変更する。
画像品質指定値４４は、図７に示すクライアント配信画像品質値の初期値を示す。この画像品質指定値４４の値は、各クライアント端末の権限毎に、あらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。すなわち、この画像品質の指定により、図７に示すテーブルに基づいて、クライアント端末毎の最小要求間隔と制限帯域が指定される。
重要度４２は、現在の重要度を示す値であり、重要度指定値４１を初期値として、帯域制限が行なわれた回数値を重要度指定値４１から引いた値である。重要度４２＝重要度指定値４１−負荷低減貢献値４３の関係であり、０≦重要度４２≦重要度指定値４１の関係である。重要度４２は、上記のような輻輳を検出して帯域制限を行なう際に、どの画像データに帯域制限を行なうかを選択する際に基準として使用する。この重要度４２の値は、画像蓄積配信サーバ１が下記の処理により情況に応じて値を変更する。
画像品質指定値４４は、図７に示すクライアント配信画像品質値の初期値を示す。この画像品質指定値４４の値は、各クライアント端末の権限毎に、あらかじめ画像蓄積配信サーバ１を運用する管理者が設定しておく値である。すなわち、この画像品質の指定により、図７に示すテーブルに基づいて、クライアント端末毎の最小要求間隔と制限帯域が指定される。
重要度４２は、現在の重要度を示す値であり、重要度指定値４１を初期値として、帯域制限が行なわれた回数値を重要度指定値４１から引いた値である。重要度４２＝重要度指定値４１−負荷低減貢献値４３の関係であり、０≦重要度４２≦重要度指定値４１の関係である。重要度４２は、上記のような輻輳を検出して帯域制限を行なう際に、どの画像データに帯域制限を行なうかを選択する際に基準として使用する。この重要度４２の値は、画像蓄積配信サーバ１が下記の処理により情況に応じて値を変更する。
使用帯域測定中値４５は、クライアント端末６への配信にどれだけの帯域を用いたかの実測値の測定に用い、この値は画像蓄積配信サーバ１が測定する。本例では、画像データを現在の秒に何バイトのデータを配信したかを示す値を保持すし、クライアント端末６に配信を行なう毎に値を更新する。
使用帯域前回測定値４６は、クライアント端末６への配信における前回測定時の使用帯域測定中値４５の最終値を保持する。この値は、画像蓄積配信サーバ１が下記の処理により更新する。本例では、画像データを直前の１秒間に何バイト分を配信したかを示す値を保持し、１秒間の刻み毎にこの値を更新する。
最終アクセス時刻４７は、クライアント端末６への配信を行った最終時刻を保持する。本例では、使用帯域測定中値４５を１秒単位で累算し、秒が変わるたびに一旦「０」にリセットする。また、新たに画像データ配信を行う度に、最終アクセス時刻４７の値を更新する。
すなわち、新たに画像データの配信を行った際の時刻が最終アクセス時刻４７が示す時刻の次の秒であった場合には、使用帯域測定中値４５の値を使用帯域前回測定値４６にコピーし、使用帯域測定中値４５の値を「０」にリセットする。また、新たに画像データの配信を行った際の時刻が、最終アクセス時刻４７が示す時刻と２秒以上の差があった場合には、使用帯域測定中値４５と使用帯域前回測定値４６の値を０とする。
使用帯域前回測定値４６は、クライアント端末６への配信における前回測定時の使用帯域測定中値４５の最終値を保持する。この値は、画像蓄積配信サーバ１が下記の処理により更新する。本例では、画像データを直前の１秒間に何バイト分を配信したかを示す値を保持し、１秒間の刻み毎にこの値を更新する。
最終アクセス時刻４７は、クライアント端末６への配信を行った最終時刻を保持する。本例では、使用帯域測定中値４５を１秒単位で累算し、秒が変わるたびに一旦「０」にリセットする。また、新たに画像データ配信を行う度に、最終アクセス時刻４７の値を更新する。
すなわち、新たに画像データの配信を行った際の時刻が最終アクセス時刻４７が示す時刻の次の秒であった場合には、使用帯域測定中値４５の値を使用帯域前回測定値４６にコピーし、使用帯域測定中値４５の値を「０」にリセットする。また、新たに画像データの配信を行った際の時刻が、最終アクセス時刻４７が示す時刻と２秒以上の差があった場合には、使用帯域測定中値４５と使用帯域前回測定値４６の値を０とする。
負荷低減処理実施先テーブル５０は、通信帯域制御処理をＷｅｂカメラ５−１〜５−ｎまたはクライアント端末６−１〜６−ｎのどれにどういう順番で行なったかを記録する履歴に関するテーブル情報である。負荷低減処理実施先テーブル５０は、負荷低減処理実行番号５１と、負荷低減処理実施先識別子５２と、負荷低減処理実施時刻５３を含んでおり、通信帯域制御処理の履歴をそれぞれ記録する。
帯域制限を行う際には、重要性の低いところから重要性の高いところの順に行い、帯制限の解除を行う際には、重要性の高いところから低いところの順に行うべきである。そのため、本実施例では、帯域制限の解除の順番は、帯域制限を行った順の逆で行っている。すなわち、負荷低減処理実施先テーブル５０は、帯域制限を行った順を記録し、一方で、帯域制限の解除を行う順を明らかにする役割をもっている。
負荷低減処理実行番号５１は、負荷低減処理を行なった順番を示す値である。
負荷低減処理実施先識別子５２は、負荷低減処理を行なった先（対象）であるＷｅｂカメラ５−１〜５−ｎまたはクライアント６−１〜６−ｎを特定する識別値である。
負荷低減処理実施時刻５３は、負荷低減処理実行番号５１が示す各負荷低減処理が行なわれた時刻を示す値である。
負荷低減処理実行数６１は負荷低減処理の実行数を示す値であり、最新負荷低減処理数変更時刻６０は負荷低減処理実行数６１の増減が行なわれた最新の時刻を保持する。
帯域制限を行う際には、重要性の低いところから重要性の高いところの順に行い、帯制限の解除を行う際には、重要性の高いところから低いところの順に行うべきである。そのため、本実施例では、帯域制限の解除の順番は、帯域制限を行った順の逆で行っている。すなわち、負荷低減処理実施先テーブル５０は、帯域制限を行った順を記録し、一方で、帯域制限の解除を行う順を明らかにする役割をもっている。
負荷低減処理実行番号５１は、負荷低減処理を行なった順番を示す値である。
負荷低減処理実施先識別子５２は、負荷低減処理を行なった先（対象）であるＷｅｂカメラ５−１〜５−ｎまたはクライアント６−１〜６−ｎを特定する識別値である。
負荷低減処理実施時刻５３は、負荷低減処理実行番号５１が示す各負荷低減処理が行なわれた時刻を示す値である。
負荷低減処理実行数６１は負荷低減処理の実行数を示す値であり、最新負荷低減処理数変更時刻６０は負荷低減処理実行数６１の増減が行なわれた最新の時刻を保持する。
図９は、本実施形態の画像蓄積配信サーバ１において、上記したように受信した画像データを蓄積するための書き込みと、蓄積した画像データを配信するための読出し、および帯域制御に関係する機能部の構成を示す。
本例では、データ格納メモリ１２（図２参照）に、チャネル数ｎに対応した複数の受信フレームバッファ７０（７０−１〜７０−ｎ）とディスク書込みキャッシュ７２（７２−１〜７２−ｎ）が形成される。すなわち、チャネル番号１〜ｎ別に、受信フレームバッファとディスク書込みキャッシュが形成される。
また、データ格納メモリ１２に、クライアント端末数ｍと対応した複数の送信フレームバッファ７７（７７−１〜７７−ｍ）とディスク読出しキャッシュ７６（７６−１〜７６−ｍ）とが形成される。すなわち、クライアント端末別に、送信フレームバッファとディスク読出しキャッシュとが形成される。
本例では、データ格納メモリ１２（図２参照）に、チャネル数ｎに対応した複数の受信フレームバッファ７０（７０−１〜７０−ｎ）とディスク書込みキャッシュ７２（７２−１〜７２−ｎ）が形成される。すなわち、チャネル番号１〜ｎ別に、受信フレームバッファとディスク書込みキャッシュが形成される。
また、データ格納メモリ１２に、クライアント端末数ｍと対応した複数の送信フレームバッファ７７（７７−１〜７７−ｍ）とディスク読出しキャッシュ７６（７６−１〜７６−ｍ）とが形成される。すなわち、クライアント端末別に、送信フレームバッファとディスク読出しキャッシュとが形成される。
受信スレッド７１（７１−１〜７１−ｎ）の実体は、プログラム格納メモリ１１に用意された受信画像フレーム処理用のプログラムである。本例では、受信スレッド７１はチャネル毎に存在する。各受信スレッド７１は、チャネル番号に対応したＷｅｂカメラ５に対して画像データの要求を行い、要求に応じてＷｅｂカメラが送信する画像データを受信し、チャネル番号に対応するディスク書込みキャッシュ７２に受信した画像データを格納する。
各受信スレッド７１から対応するＷｅｂカメラ５への画像要求は、図４〜図６に示す画像品質値テーブルから後述する方法で求めたフレームレート等のパラメータを伴ってなされる。 各受信スレッド７１が使用する画像品質値テーブルは、帯域制御用情報テーブル８のチャネル番号に対応するＷｅｂカメラ番号の画像品質値テーブル識別子３５（図８参照）から判別する。
各受信スレッド７１から対応するＷｅｂカメラ５への画像要求は、図４〜図６に示す画像品質値テーブルから後述する方法で求めたフレームレート等のパラメータを伴ってなされる。 各受信スレッド７１が使用する画像品質値テーブルは、帯域制御用情報テーブル８のチャネル番号に対応するＷｅｂカメラ番号の画像品質値テーブル識別子３５（図８参照）から判別する。
画像品質値は、帯域制御用情報テーブル８のチャネル番号に対応するＷｅｂカメラ番号の画像品質指定値３４に、負荷低減貢献値３３を加えた値を使用する。画像品質値＝画像品質指定値３４＋負荷低減貢献値３３の関係にある。なお、求めた画像品質値が、画像品質値テーブル（図４〜図６）内にない（画像品質値テーブル内で定義する画像品質値より大きい）場合には、本例では、画像品質値テーブル内の最大の画像品質値を用いる。
すなわち、画像品質値テーブル識別子３５が示すテーブルの該当する画像の品質値を用いて、対応するＷｅｂカメラに対する画像要求のパラメータを得る。
具体的には、図４の画像品質値テーブルを用いる場合には、当該画像品質値テーブルに設定された画像画素数、圧縮指定値、フレームレートをパラメータとしてＷｅｂカメラ５に対して画像要求を行なう。図５の画像品質値テーブルを用いる場合には、当該画像品質値テーブルに設定された圧縮指定値とフレームレートとをパラメータとしてＷｅｂカメラ５に対して画像要求を行なう。図６の画像品質値テーブルを用いる場合には、当該画像品質値テーブルに設定されたフレームレートをパラメータとしてＷｅｂカメラ５に対して画像要求を行なう。
すなわち、画像品質値テーブル識別子３５が示すテーブルの該当する画像の品質値を用いて、対応するＷｅｂカメラに対する画像要求のパラメータを得る。
具体的には、図４の画像品質値テーブルを用いる場合には、当該画像品質値テーブルに設定された画像画素数、圧縮指定値、フレームレートをパラメータとしてＷｅｂカメラ５に対して画像要求を行なう。図５の画像品質値テーブルを用いる場合には、当該画像品質値テーブルに設定された圧縮指定値とフレームレートとをパラメータとしてＷｅｂカメラ５に対して画像要求を行なう。図６の画像品質値テーブルを用いる場合には、当該画像品質値テーブルに設定されたフレームレートをパラメータとしてＷｅｂカメラ５に対して画像要求を行なう。
Ｗｅｂカメラ５は、各受信スレッド７１からの画像要求に応答して、画像データをＩＰパケット形式でネットワーク４を介して送信する。Ｗｅｂカメラ５から送信された画像フレームパケットは、ネットワークインターフェイス１４で受信され、ＴＣＰ／ＩＰスタック１５で画像フレームが抽出され、チャネル番号と対応した受信フレームバッファ７０（７０−１〜７０−ｎ）に入力される。受信フレームバッファ７０に入力された画像フレームは、チャネル番号と対応した受信スレッド７１（７１−１〜７１−ｎ）によって、チャネル番号と対応したディスク書込みキャッシュ７２（７２−１〜７２−ｎ）に転送される。
本実施形態では、図１０に詳示するように、チャンネル番号に対応する各ディスク書込みキャッシュ７２―ｉは複数のキャッシュ領域７２０―１〜７２０―４で構成されている。なお、図１０には、あるチャンネル番号を示すために“ｉ”を枝符号として付して示してある。
各受信スレッド７１−ｉは、１つのキャッシュ領域内に、当該キャッシュ領域のサイズに収まるだけの複数の画像データを受信順に詰め込む。そして、各受信スレッド７１−ｉは、１つのキャッシュ領域に画像データを詰め込み終えると、その後の受信画像データを別のキャッシュ領域に詰め込んでいく。また、各受信スレッド７１−ｉは、画像データで満たしたキャッシュ領域の識別子を書込み待ちブロックキュー７３に登録する。
ディスク書込みスレッド７４（７４−１〜７４−Ｌ：但し、ＬはＬ＜ｎの自然数）の実体は、プログラム格納メモリ１１に用意されたデータブロック処理用のプログラムであり、それぞれ書込み待ちブロックキュー７３からキャッシュ領域の識別子を読出し、該当キャッシュ内の画像データをディスク装置３に書き込む。これによって、各Ｗｅｂカメラ５から受信した画像データが当該チャネル毎にディスク装置３に蓄積される。
各受信スレッド７１−ｉは、１つのキャッシュ領域内に、当該キャッシュ領域のサイズに収まるだけの複数の画像データを受信順に詰め込む。そして、各受信スレッド７１−ｉは、１つのキャッシュ領域に画像データを詰め込み終えると、その後の受信画像データを別のキャッシュ領域に詰め込んでいく。また、各受信スレッド７１−ｉは、画像データで満たしたキャッシュ領域の識別子を書込み待ちブロックキュー７３に登録する。
ディスク書込みスレッド７４（７４−１〜７４−Ｌ：但し、ＬはＬ＜ｎの自然数）の実体は、プログラム格納メモリ１１に用意されたデータブロック処理用のプログラムであり、それぞれ書込み待ちブロックキュー７３からキャッシュ領域の識別子を読出し、該当キャッシュ内の画像データをディスク装置３に書き込む。これによって、各Ｗｅｂカメラ５から受信した画像データが当該チャネル毎にディスク装置３に蓄積される。
図９に示す配信スレッド７５（７５−１〜７５−ｍ）の実体も、プログラム格納メモリ１１に用意された送信データ処理用のプログラムである。
クライアント端末６（６−１〜６−ｍ）からの画像フレーム配信要求を受信すると、配信スレッド７５は、図１１に示すような処理を行って画像配信条件を満たすか否かを確認する。
この画像配信条件は、本実施形態では、クライアント端末６の画像要求間隔が許可された範囲になっているか、そして、通信帯域が当該クライアント端末６に割り当てられた範囲内に収まっているかを確認することにより判断される。
後述するように、この判断の結果、画像配信条件を満たさなければ、要求元のクライアント端末６にエラーメッセージと待機要求時間を送信する。一方、画像配信条件を満たしていれば、配信スレッド７５はディスク読み出しキャッシュ７６またはディスク装置３から、後述するような処理手順で、要求された画像データを読出し、送信フレームバッファ７７へ転送する。
クライアント端末６（６−１〜６−ｍ）からの画像フレーム配信要求を受信すると、配信スレッド７５は、図１１に示すような処理を行って画像配信条件を満たすか否かを確認する。
この画像配信条件は、本実施形態では、クライアント端末６の画像要求間隔が許可された範囲になっているか、そして、通信帯域が当該クライアント端末６に割り当てられた範囲内に収まっているかを確認することにより判断される。
後述するように、この判断の結果、画像配信条件を満たさなければ、要求元のクライアント端末６にエラーメッセージと待機要求時間を送信する。一方、画像配信条件を満たしていれば、配信スレッド７５はディスク読み出しキャッシュ７６またはディスク装置３から、後述するような処理手順で、要求された画像データを読出し、送信フレームバッファ７７へ転送する。
ここで、上記において、ディスク読込キャッシュ７６に要求された画像データが存在するときには、当該キャッシュ７６から画像データを読出して、送信フレームバッファ７７への転送する。一方、ディスク読込キャッシュ７６に要求された画像データが存在しないときには、ディスク装置３から画像データを読出してディスク読込キャッシュ７６へ転送するとともに送信フレームバッファ７７へ転送する。
このようにして送信フレームバッファ７７に入力された画像データは、ＴＣＰ／ＩＰスタック１５でＩＰパケットに変換され、ネットワークインターフェイス１４からネットワーク４を介して要求元のクライアント端末６へ送信される。
なお、このようにしてクライアント端末からの画像要求に応答して画像データを配信した時には、帯域制御用情報テーブル８（図８参照）の当該クライアント端末に対応する最終アクセス時刻４７を更新し、配信した画像データのバイトサイズを使用帯域測定中値４５に加算する。
このようにして送信フレームバッファ７７に入力された画像データは、ＴＣＰ／ＩＰスタック１５でＩＰパケットに変換され、ネットワークインターフェイス１４からネットワーク４を介して要求元のクライアント端末６へ送信される。
なお、このようにしてクライアント端末からの画像要求に応答して画像データを配信した時には、帯域制御用情報テーブル８（図８参照）の当該クライアント端末に対応する最終アクセス時刻４７を更新し、配信した画像データのバイトサイズを使用帯域測定中値４５に加算する。
図１１は、上記クライアント端末６に関する画像配信条件の判断処理の手順を示す。画像配信条件の判断は、図７及び図８に示すように各クライアント端末６毎に設定された最小要求間隔及び制限帯域に照らして、各クライアント端末６からの画像要求の間隔が許可されている条件をみたしているか、及び、通信帯域がクライアントに割り当てられた制限帯域の範囲内に収まっているかを画像蓄積配信サーバ１が判定することにより行われる。 まず、クライアント端末からの画像要求を受信すると、（現在時刻−最終アクセス時刻４７）で求まる差分時間が、クライアント画像品質値テーブル（図７）と品質値（画像品質指定値４４−負荷低減貢献値４３）から求まる最小要求間隔２１を超えているかを判定する（ステップＳ１）。
この判定の結果、超えてない場合には、当該クライアント端末からの画像要求は配信条件を満たしてないので（ステップＳ２）、（最終アクセス時刻４７＋最小要求間隔２１−現在時刻）の演算により待機要求時間値を求めて、当該要求元のクライアント端末へエラーメッセージととも当該待機要求時間値をネットワーク４を介して送信して通知し（ステップＳ３）、処理を終了する。
一方、越えている場合には、更に最終アクセス時刻４７を１秒未満の単位で切り上げた時刻として、当該切り上げた最終アクセス時刻と現在時刻（本例では、現在時刻は秒未満の単位も有効とする。）とを比較する（ステップＳ４）。この判定の結果、現在時刻が切り上げた最終アクセス時刻以上である場合には、当該画像要求は配信条件を満たすものと判断し（ステップＳ５）、処理を終了する。これは、上述した通り（段落００３０）、使用帯域測定中値４５は１秒単位で累算し、秒が変わるたびに一旦「０」にリセットされるため、ステップＳ４で秒が変わったと判断される場合（Ｓ５に進む場合）には、使用帯域測定中値４５が「０」となっているため、クライアント画像品質値テーブルと品質値（負荷低減貢献値４３＋画像品質指定値４４）とから求まる制限帯域２２を越えているという状況は起こり得ないためである。
一方、越えている場合には、更に最終アクセス時刻４７を１秒未満の単位で切り上げた時刻として、当該切り上げた最終アクセス時刻と現在時刻（本例では、現在時刻は秒未満の単位も有効とする。）とを比較する（ステップＳ４）。この判定の結果、現在時刻が切り上げた最終アクセス時刻以上である場合には、当該画像要求は配信条件を満たすものと判断し（ステップＳ５）、処理を終了する。これは、上述した通り（段落００３０）、使用帯域測定中値４５は１秒単位で累算し、秒が変わるたびに一旦「０」にリセットされるため、ステップＳ４で秒が変わったと判断される場合（Ｓ５に進む場合）には、使用帯域測定中値４５が「０」となっているため、クライアント画像品質値テーブルと品質値（負荷低減貢献値４３＋画像品質指定値４４）とから求まる制限帯域２２を越えているという状況は起こり得ないためである。
一方、最終アクセス切り上げ時刻が現在時刻より大きい場合には、使用帯域測定中値４５が、クライアント画像品質値テーブルと品質値（負荷低減貢献値４３＋画像品質指定値４４）とから求まる制限帯域２２に収まっているかを判定する（ステップＳ６）。
この判定の結果、収まっている場合には、当該画像要求は配信条件を満たすものと判断し（ステップＳ５）、処理を終了する。すなわち、画像配信サーバ１は当該画像要求に応答して、該当する画像データフレームをディスク装置３から読み出して、要求元のクライアント端末６へネットワーク４を介して配信する処理を実行する。
一方、収まってない場合には、当該クライアント端末からの画像要求は配信条件を満たしてないので（ステップＳ７）、（上記の秒未満単位を切り上げた最終アクセス時刻−現在時刻）の演算により待機要求時間値を求めて、当該要求元のクライアント端末へエラーメッセージととも当該待機要求時間値をネットワーク４を介して送信して通知し（ステップＳ８）、処理を終了する。
この判定の結果、収まっている場合には、当該画像要求は配信条件を満たすものと判断し（ステップＳ５）、処理を終了する。すなわち、画像配信サーバ１は当該画像要求に応答して、該当する画像データフレームをディスク装置３から読み出して、要求元のクライアント端末６へネットワーク４を介して配信する処理を実行する。
一方、収まってない場合には、当該クライアント端末からの画像要求は配信条件を満たしてないので（ステップＳ７）、（上記の秒未満単位を切り上げた最終アクセス時刻−現在時刻）の演算により待機要求時間値を求めて、当該要求元のクライアント端末へエラーメッセージととも当該待機要求時間値をネットワーク４を介して送信して通知し（ステップＳ８）、処理を終了する。
ここで、本実施形態では、画像データの通信に係る画像蓄積配信サーバ１の内部処理負担に応じても上記のような帯域制御を行って、輻輳に対処している。
図１０は、画像蓄積配信サーバ１の内部処理の一例として、第ｉ番目のチャンネル（第ｉチャンネル）用の受信用スレッド７１−ｉによるディスク書込みキャッシュ７２−ｉの動作を示す。
本例では、第ｉチャンネル用のディスク書込みキャッシュ７２−ｉとして、４個のキャッシュ領域７２０−１〜７２０−４が用意されている。キャッシュ領域の状態には、空き状態（ＳＴ０）、詰め込み中状態（ＳＴ１）、ディスク装置３への書込み待ち状態（ＳＴ２）、ディスク装置３への書込み完了状態（ＳＴ３）があり、各キャッシュ領域の現在の状態は、キャッシュ領域状態テーブル７８−ｉに記録される。
図１０は、画像蓄積配信サーバ１の内部処理の一例として、第ｉ番目のチャンネル（第ｉチャンネル）用の受信用スレッド７１−ｉによるディスク書込みキャッシュ７２−ｉの動作を示す。
本例では、第ｉチャンネル用のディスク書込みキャッシュ７２−ｉとして、４個のキャッシュ領域７２０−１〜７２０−４が用意されている。キャッシュ領域の状態には、空き状態（ＳＴ０）、詰め込み中状態（ＳＴ１）、ディスク装置３への書込み待ち状態（ＳＴ２）、ディスク装置３への書込み完了状態（ＳＴ３）があり、各キャッシュ領域の現在の状態は、キャッシュ領域状態テーブル７８−ｉに記録される。
受信用スレッド７１−ｉは、キャッシュ領域状態テーブル７８−ｉを参照して、ディスク書込みキャッシュ７２−ｉから空き状態（ＳＴ０）にあるキャッシュ領域を選択し、このキャッシュ領域の状態コードを詰め込み中状態（ＳＴ１）、すなわち、当該キャッシュ領域に画像データを書込みできる状態にした後、受信画像データの書込みを行う。また、空き状態（ＳＴ０）のキャッシュ領域が全くない場合には、書込み完了状態（ＳＴ３）にあるキャッシュ領域の中から、書込みを行った時刻が最も古いキャッシュ領域を選択し、その状態コードを詰め込み中状態（ＳＴ１）に変更した後、当該キャッシュ領域に受信画像データを詰め込む。
受信用スレッド７１−ｉは、空き状態（ＳＴ０）及び書込み完了状態（ＳＴ３）がのキャッシュ領域が無く、全てのキャッシュ領域が書込み待ち状態（ＳＴ２）である時には、全キャッシュディスク書込み待ちフラグ７９−ｉを「１」とし、書き込み完了状態（ＳＴ３）のキャッシュ領域が生じるまで、Ｗｅｂカメラ５からの画像データの取得を中断する。
受信用スレッド７１−ｉは、空き状態（ＳＴ０）及び書込み完了状態（ＳＴ３）がのキャッシュ領域が無く、全てのキャッシュ領域が書込み待ち状態（ＳＴ２）である時には、全キャッシュディスク書込み待ちフラグ７９−ｉを「１」とし、書き込み完了状態（ＳＴ３）のキャッシュ領域が生じるまで、Ｗｅｂカメラ５からの画像データの取得を中断する。
受信用スレッド７１−ｉは、１つのキャッシュ領域で画像データの詰め込みが完了すると、キャッシュ領域状態テーブル７８−ｉ上で当該キャッシュ領域の状態コードをＳＴ１からＳＴ２に変更し、該キャシュ領域の識別子を書込み待ちブロックキュー７３に登録する。
ディスク書込みスレッド７４−ｉは、書込み待ちブロックキュー７３に登録された先頭のキャッシュ領域の識別子を取り出し、ディスク書込みキャッシュ７２−ｉから、書込み待ち状態（ＳＴ２）にあるキャッシュ領域を読み出し、このキャッシュ領域内の全ての画像データをディスク装置３に書き込む。そして、キャッシュ領域状態テーブル７８−ｉ上で、ディスク装置３への書込みが完了したキャッシュ領域の状態コードをＳＴ２からＳＴ３に変更して、１つのキャシュ領域の書込み処理を終了する。
ディスク書込みスレッド７４−ｉによるキャッシュ領域の書込み所要時間は、受信用スレッド７１−ｉによるキャッシュ詰め込み時間に比較して短いため、チャンネル数ｎよりも少ない個数Ｌのディスク書込みスレッド７４（７４−１〜７４−Ｌ）で、ディスク書込みキャッシュ７２の全チャンネルのキャッシュ領域をディスク装置３に書込むことができる。本実施形態では、ディスク書込みキャッシュ７２−ｉに４個のキャッシュ領域７２０−１〜７２０−４を用意したが、キャッシュ領域は、各チャンネルに少なくとも２個あればよく、その最大数は任意である。
ディスク書込みスレッド７４−ｉは、書込み待ちブロックキュー７３に登録された先頭のキャッシュ領域の識別子を取り出し、ディスク書込みキャッシュ７２−ｉから、書込み待ち状態（ＳＴ２）にあるキャッシュ領域を読み出し、このキャッシュ領域内の全ての画像データをディスク装置３に書き込む。そして、キャッシュ領域状態テーブル７８−ｉ上で、ディスク装置３への書込みが完了したキャッシュ領域の状態コードをＳＴ２からＳＴ３に変更して、１つのキャシュ領域の書込み処理を終了する。
ディスク書込みスレッド７４−ｉによるキャッシュ領域の書込み所要時間は、受信用スレッド７１−ｉによるキャッシュ詰め込み時間に比較して短いため、チャンネル数ｎよりも少ない個数Ｌのディスク書込みスレッド７４（７４−１〜７４−Ｌ）で、ディスク書込みキャッシュ７２の全チャンネルのキャッシュ領域をディスク装置３に書込むことができる。本実施形態では、ディスク書込みキャッシュ７２−ｉに４個のキャッシュ領域７２０−１〜７２０−４を用意したが、キャッシュ領域は、各チャンネルに少なくとも２個あればよく、その最大数は任意である。
負荷監視スレッド９の実体も、プログラム格納メモリ１１に用意されたデータ処理用のプログラムであり、図１２に示すような負荷監視処理を行って負荷情況を判断し、負荷低減貢献値を増減する処理（すなわち、帯域を制限又は当該制限を解除する処理）を行う。なお、この処理は、所定の時間間隔で循環的に繰り返し実行され、当該処理中に変動した負荷を判定して、帯域制限を増減する。
図１２に示す処理では、まず、全ての受信用スレッド７１に付属する「全キャッシュディスク書込み待ちフラグ」７９−ｉを「０」として初期化し（ステップＳ１０）、（現在時刻−最新負荷低減処理数変更時刻６０）が１０秒以上となるかを演算することにより、先の負荷低減処理の処理数の増減が行なわれてから１０秒間経過するまで待機する（ステップＳ１１）。なお、この待機時間は、負荷低減処理を変更処理の効果を見定める意味を有しており、本例では、１０秒間も経過すれば「全キャッシュディスク書込み待ちフラグ」の変化も十分に反映されるであろうとしているが、この待機時間は実際のシステムの設定状況に応じて任意に設定すればよい。
図１２に示す処理では、まず、全ての受信用スレッド７１に付属する「全キャッシュディスク書込み待ちフラグ」７９−ｉを「０」として初期化し（ステップＳ１０）、（現在時刻−最新負荷低減処理数変更時刻６０）が１０秒以上となるかを演算することにより、先の負荷低減処理の処理数の増減が行なわれてから１０秒間経過するまで待機する（ステップＳ１１）。なお、この待機時間は、負荷低減処理を変更処理の効果を見定める意味を有しており、本例では、１０秒間も経過すれば「全キャッシュディスク書込み待ちフラグ」の変化も十分に反映されるであろうとしているが、この待機時間は実際のシステムの設定状況に応じて任意に設定すればよい。
そして、１０秒間を経過したときには、当該処理中においても並行して実施されている上記のディスク書き込み処理（図１０参照）により「全キャッシュディスク書込み待ちフラグ」７９−ｉの中に「１」となっているものが存在するか判定する（ステップＳ１２）。
この判定の結果、存在する場合には、なんらかの理由でディスク装置３へのアクセスが間に合ってないことを意味するので、後述する方法により、負荷低減処理を１つ増加させて負荷の低減を図り（ステップＳ１３）、その後、再び負荷監視を行うためにステップＳ１０の処理に移行する。
なお、本実施形態では、負荷低減または当該低減の解除は、負荷低減貢献値を１つずつ増加または減少されることにより行うが、負荷低減貢献値を１度に２つ以上増減させるようにしてもよく、この増減の態様は任意に設定されればよい。
この判定の結果、存在する場合には、なんらかの理由でディスク装置３へのアクセスが間に合ってないことを意味するので、後述する方法により、負荷低減処理を１つ増加させて負荷の低減を図り（ステップＳ１３）、その後、再び負荷監視を行うためにステップＳ１０の処理に移行する。
なお、本実施形態では、負荷低減または当該低減の解除は、負荷低減貢献値を１つずつ増加または減少されることにより行うが、負荷低減貢献値を１度に２つ以上増減させるようにしてもよく、この増減の態様は任意に設定されればよい。
一方、上記判定の結果、存在しない場合には、「総取得済みフレーム数」に対する「予定総取得フレーム数」の比が９８％未満であるかを判定する（ステップＳ１４）。
ここに、「総取得済みフレーム数」は、全Ｗｅｂカメラ分の前測定時取得フレーム数３８の合計を示す。「予定総取得フレーム数」は、全Ｗｅｂカメラの中にて前測定時取得フレーム数３８が１以上のＷｅｂカメラを対象として、品質値（画像品質指定値３４＋負荷低減貢献値３３）とＷｅｂカメラ画像品質値テーブル（図４〜図６）から求まる「帯域」の合計を示す。
なお、この９８％は画像フレームの所得処理の進行度合いを見定める基準値の一例であり、当該基準値は、実際のシステムの設定状況に応じて任意に設定すればよい。
ここに、「総取得済みフレーム数」は、全Ｗｅｂカメラ分の前測定時取得フレーム数３８の合計を示す。「予定総取得フレーム数」は、全Ｗｅｂカメラの中にて前測定時取得フレーム数３８が１以上のＷｅｂカメラを対象として、品質値（画像品質指定値３４＋負荷低減貢献値３３）とＷｅｂカメラ画像品質値テーブル（図４〜図６）から求まる「帯域」の合計を示す。
なお、この９８％は画像フレームの所得処理の進行度合いを見定める基準値の一例であり、当該基準値は、実際のシステムの設定状況に応じて任意に設定すればよい。
この判定の結果、９８％未満である場合には、なんらかの理由でネットワーク通信に負荷がかかっていることを意味するので、後述する方法により、負荷低減処理を１つ増加させて負荷の低減を図り（ステップＳ１３）、その後、再び負荷監視を行うためにステップＳ１０の処理に移行する。
一方、９８％以上である場合には、負荷低減処理実行数６１が１つ以上存在するかを判定し（ステップＳ１５）、この結果、負荷低減処理実行数６１が「０」で負荷低減処理が行なわれてない場合には、引き続き負荷監視を行うためにステップＳ１０の処理に移行する。
一方、９８％以上である場合には、負荷低減処理実行数６１が１つ以上存在するかを判定し（ステップＳ１５）、この結果、負荷低減処理実行数６１が「０」で負荷低減処理が行なわれてない場合には、引き続き負荷監視を行うためにステップＳ１０の処理に移行する。
一方、上記の判定の結果、負荷低減処理数が１つ以上存在する場合には、（現在時刻−最新負荷低減処理数変更時刻６０）が６０秒未満であるかを判定して、負荷低減処理の処理数の増減が行なわれてから６０秒経過しているか判断する（ステップＳ１６）。
この判定の結果、最新負荷低減処理数変更時刻が６０秒未満である場合には、引き続き負荷監視を行うためにステップＳ１０の処理に移行する一方、６０秒を経過している場合には、当該６０秒の間にディスク装置３へのアクセスやネットワーク４に発生していた負荷が軽減した可能性があるので、後述する方法により、負荷低減処理を１つ削減させて負荷の低減を解除して（ステップＳ１７）、その後、再び負荷監視を行うためにステップＳ１０の処理に移行する。
すなわち、実際の負荷が低減された状態となったときには、負荷を低減させる帯域制限を解除して、元の帯域に徐々に復帰させる処理を行う。なお、本例の６０秒間は負荷の変化を見定めるための時間の一例であり、実際のシステムの設定状況に応じて任意に設定すればよい。
この判定の結果、最新負荷低減処理数変更時刻が６０秒未満である場合には、引き続き負荷監視を行うためにステップＳ１０の処理に移行する一方、６０秒を経過している場合には、当該６０秒の間にディスク装置３へのアクセスやネットワーク４に発生していた負荷が軽減した可能性があるので、後述する方法により、負荷低減処理を１つ削減させて負荷の低減を解除して（ステップＳ１７）、その後、再び負荷監視を行うためにステップＳ１０の処理に移行する。
すなわち、実際の負荷が低減された状態となったときには、負荷を低減させる帯域制限を解除して、元の帯域に徐々に復帰させる処理を行う。なお、本例の６０秒間は負荷の変化を見定めるための時間の一例であり、実際のシステムの設定状況に応じて任意に設定すればよい。
上記図１２の処理により、負荷監視スレッド９が負荷低減処理実行数６１の値を１増やすと判定した場合の処理を説明する。
図１３に示す負荷低減処理対象選定処理にて、Ｗｅｂカメラ５−１〜５〜ｎおよびクライアント端末６−１〜６−ｍの中から、負荷低減処理を行う対象先を選定する。なお、負荷低減処理対象選定処理にて、負荷低減処理を行う対象先が存在しない場合には、負荷低減処理の追加は行わない。
なお、負荷低減処理対象の選定は、図１３に示すように各対象の重要度に応じてなされ、重要度の大きい対象（本実施形態では、対象の重要性が高いものほど重要度は小さく設定しているので、重要性の低い対象）を優先的に負荷低減処理の対象として選定する。また、これとは逆に、帯域制限を解除する対象は、重要度の小さい対象（すなわち、重要性の高い対象）を優先的に選定する。
図１３に示す負荷低減処理対象選定処理にて、Ｗｅｂカメラ５−１〜５〜ｎおよびクライアント端末６−１〜６−ｍの中から、負荷低減処理を行う対象先を選定する。なお、負荷低減処理対象選定処理にて、負荷低減処理を行う対象先が存在しない場合には、負荷低減処理の追加は行わない。
なお、負荷低減処理対象の選定は、図１３に示すように各対象の重要度に応じてなされ、重要度の大きい対象（本実施形態では、対象の重要性が高いものほど重要度は小さく設定しているので、重要性の低い対象）を優先的に負荷低減処理の対象として選定する。また、これとは逆に、帯域制限を解除する対象は、重要度の小さい対象（すなわち、重要性の高い対象）を優先的に選定する。
負荷低減処理を行う対象先が存在する場合は、次の処理を行う。
負荷低減処理を行う対象先の負荷低減貢献値（Ｗｅｂカメラ側であれば負荷低減貢献値３３、クライアント端末側であれば負荷低減貢献値４３）を１つ加算して、重要度（Ｗｅｂカメラ側であれば重要度３２、クライアント端末側であれば重要度４２）を１つ減算する。
負荷低減処理実施先テーブル５０（図８参照）の負荷処理実行番号５１の最下欄（Ｋ）に負荷処理実行数６１を、負荷低減処理実施先識別子５２―Ｋに対象先を示す識別子を、負荷処理低減処理実施時刻５３−Ｋに現在時刻を記して、負荷処理実行数６１を１つ加算する。
この負荷低減貢献値は使用帯域に関わる値であり、負荷低減貢献値が１大きくなると使用帯域が狭まる関係にあるので、選定された対象（Ｗｅｂカメラまたはクライアント端末）に対する画像データの蓄積または配信の処理に使用する帯域が制限される。
すなわち、負荷低減処理の対象先がＷｅｂカメラであった場合には、以後、画像品質指定値３４で指定された図４〜図６のいずれかの品質値テーブルと品質値（上記１加算された負荷低減貢献値３３＋画像品質指定値３４）とから定まる品質により蓄積配信サーバ１は当該対象先であるＷｅｂカメラに対する画像要求を行う。また、負荷低減処理の対象先がクライアント端末であった場合には、以後、図７の品質値テーブルと品質値（上記１が加算された負荷低減貢献値４３＋画像品質指定値４４）とから定まる品質（最小要求間隔２１、制限帯域２２）により蓄積配信サーバ1は当該対象先であるクライアント端末に対する画像配信を行う。
負荷低減処理を行う対象先の負荷低減貢献値（Ｗｅｂカメラ側であれば負荷低減貢献値３３、クライアント端末側であれば負荷低減貢献値４３）を１つ加算して、重要度（Ｗｅｂカメラ側であれば重要度３２、クライアント端末側であれば重要度４２）を１つ減算する。
負荷低減処理実施先テーブル５０（図８参照）の負荷処理実行番号５１の最下欄（Ｋ）に負荷処理実行数６１を、負荷低減処理実施先識別子５２―Ｋに対象先を示す識別子を、負荷処理低減処理実施時刻５３−Ｋに現在時刻を記して、負荷処理実行数６１を１つ加算する。
この負荷低減貢献値は使用帯域に関わる値であり、負荷低減貢献値が１大きくなると使用帯域が狭まる関係にあるので、選定された対象（Ｗｅｂカメラまたはクライアント端末）に対する画像データの蓄積または配信の処理に使用する帯域が制限される。
すなわち、負荷低減処理の対象先がＷｅｂカメラであった場合には、以後、画像品質指定値３４で指定された図４〜図６のいずれかの品質値テーブルと品質値（上記１加算された負荷低減貢献値３３＋画像品質指定値３４）とから定まる品質により蓄積配信サーバ１は当該対象先であるＷｅｂカメラに対する画像要求を行う。また、負荷低減処理の対象先がクライアント端末であった場合には、以後、図７の品質値テーブルと品質値（上記１が加算された負荷低減貢献値４３＋画像品質指定値４４）とから定まる品質（最小要求間隔２１、制限帯域２２）により蓄積配信サーバ1は当該対象先であるクライアント端末に対する画像配信を行う。
一方、上記図１２の処理により、負荷監視スレッド９が負荷低減処理数６１の値を１つ減らすと判定した場合の処理を説明する。
負荷低減処理実施先テーブル５０内の負荷低減処理実行番号５１が最大である欄の負荷低減処理実施先識別子５２が示すＷｅｂカメラまたはクライアント端末を対象とする。
対象先の負荷低減貢献値（Ｗｅｂカメラ側であれば負荷低減貢献値３３、クライアント端末側であれば負荷低減貢献値４３）を１つ減算して、重要度（Ｗｅｂカメラ側であれば重要度３２、クライアント側であれば重要度４２）を１つ加算する。
負荷低減処理実施先テーブル５０内の、対応する負荷低減処理実行番号５１の値と負荷低減処理実施先識別子５２の識別子情報とを消去し、負荷処理実行数６１を１つ減算する。
この負荷低減貢献値は使用帯域に関わる値であり、負荷低減貢献値が１小さくなると使用帯域が広まる関係にあるので、選定された対象（Ｗｅｂカメラまたはクライアント端末）に対する画像データの蓄積または配信の処理に使用する帯域の制限が１段階解除される。
すなわち、負荷低減処理の解除の対象先がＷｅｂカメラであった場合には、以後、画像品質指定値３４で指定された図４〜図６のいずれかの品質値テーブルと品質値（上記１減算された負荷低減貢献値３３＋画像品質指定値３４）とから定まる品質により蓄積配信サーバ１は当該対象先であるＷｅｂカメラに対する画像要求を行う。また、負荷低減処理の解除の対象先がクライアント端末であった場合には、以後、図7の品質値テーブルと品質値（上記１減算された負荷低減貢献値４３＋画像品質指定値４４）とから定まる品質（最小要求間隔２１、制限帯域２２）により蓄積配信サーバ１は当該対象先であるクライアント端末に対する画像配信を行う。
負荷低減処理実施先テーブル５０内の負荷低減処理実行番号５１が最大である欄の負荷低減処理実施先識別子５２が示すＷｅｂカメラまたはクライアント端末を対象とする。
対象先の負荷低減貢献値（Ｗｅｂカメラ側であれば負荷低減貢献値３３、クライアント端末側であれば負荷低減貢献値４３）を１つ減算して、重要度（Ｗｅｂカメラ側であれば重要度３２、クライアント側であれば重要度４２）を１つ加算する。
負荷低減処理実施先テーブル５０内の、対応する負荷低減処理実行番号５１の値と負荷低減処理実施先識別子５２の識別子情報とを消去し、負荷処理実行数６１を１つ減算する。
この負荷低減貢献値は使用帯域に関わる値であり、負荷低減貢献値が１小さくなると使用帯域が広まる関係にあるので、選定された対象（Ｗｅｂカメラまたはクライアント端末）に対する画像データの蓄積または配信の処理に使用する帯域の制限が１段階解除される。
すなわち、負荷低減処理の解除の対象先がＷｅｂカメラであった場合には、以後、画像品質指定値３４で指定された図４〜図６のいずれかの品質値テーブルと品質値（上記１減算された負荷低減貢献値３３＋画像品質指定値３４）とから定まる品質により蓄積配信サーバ１は当該対象先であるＷｅｂカメラに対する画像要求を行う。また、負荷低減処理の解除の対象先がクライアント端末であった場合には、以後、図7の品質値テーブルと品質値（上記１減算された負荷低減貢献値４３＋画像品質指定値４４）とから定まる品質（最小要求間隔２１、制限帯域２２）により蓄積配信サーバ１は当該対象先であるクライアント端末に対する画像配信を行う。
図１３に示す負荷低減処理対象選定処理を説明する。
まず、Ｗｅｂカメラ側帯域制御用テーブル３０の全項目（１〜ｎ）、および、クライアント側帯域制御用テーブル４０内の全項目（１〜ｍ）において、選定比較値を求める（ステップＳ２０）。この選定比較値は、重要度（Ｗｅｂカメラ側では重要度３２の値、クライアント側では重要度４２）の値を各テーブルから抽出して使用する。
そして、これらＷｅｂカメラ側およびクライアント端末側について、重要度（選定比較値）の値が１以上のものが１つでもあるか判定し（ステップＳ２１）、１以上のものが１つもない場合には、全てのＷｅｂカメラおよびクライアント端末の重要性が極めて高いか、もしくは、既に負荷低減処理が行える対象全てに対して負荷低減処理を行ってしまった後で、負荷低減処理を行なえる対象が存在しないことを意味するので、負荷低減対象なしとして判定処理を終了する（ステップＳ２２）。
まず、Ｗｅｂカメラ側帯域制御用テーブル３０の全項目（１〜ｎ）、および、クライアント側帯域制御用テーブル４０内の全項目（１〜ｍ）において、選定比較値を求める（ステップＳ２０）。この選定比較値は、重要度（Ｗｅｂカメラ側では重要度３２の値、クライアント側では重要度４２）の値を各テーブルから抽出して使用する。
そして、これらＷｅｂカメラ側およびクライアント端末側について、重要度（選定比較値）の値が１以上のものが１つでもあるか判定し（ステップＳ２１）、１以上のものが１つもない場合には、全てのＷｅｂカメラおよびクライアント端末の重要性が極めて高いか、もしくは、既に負荷低減処理が行える対象全てに対して負荷低減処理を行ってしまった後で、負荷低減処理を行なえる対象が存在しないことを意味するので、負荷低減対象なしとして判定処理を終了する（ステップＳ２２）。
一方、重要度の値が１以上のものが１つ以上存在する場合には、これらの内から重要度値が最大のものが１つのみか２つ以上存在するかを判定し（ステップＳ２３）、１つのみ場合には当該重要度値が最大のものを負荷低減の対象とし手選定して処理を終了する（ステップＳ２４）。これに対して、重要度値が最大のものが２つ以上存在する場合には、これら重要度値が最大のもの中にクライアント端末が含まれているかを判定し（ステップＳ２５）、クライアント端末が含まれている場合には、これら重要度値が最大のクライアント端末は１つのみか２つ以上存在するかを判定し（ステップＳ２６）、１つの場合には、当該クライアント端末を負荷低減の対象として選定して処理を終了する（ステップＳ２７）。
一方、重要度値が最大のクライアント端末が２つ以上存在する場合には、これらクライアント端末の中において、使用帯域前回測定値４６が最大となるものが１つのみか２つ以上存在するかを判定し（ステップＳ２８）、１つのみ場合には、当該クライアント端末を負荷低減の対象として選定して処理を終了する（ステップＳ２９）。すなわち、クライアント端末の内の重要度が最大のものが複数ある場合は、これらの中から前回の配信処理において使用帯域が大きかった方のクライアント端末を対象に選定する。
これに対して、使用帯域前回測定値４６が最大となるクライアント端末が複数ある場合には、更に、これらの中において、最終アクセス時刻４７が最新のものを負荷低減の対象として選定して処理を終了する（ステップＳ３０）。
これに対して、使用帯域前回測定値４６が最大となるクライアント端末が複数ある場合には、更に、これらの中において、最終アクセス時刻４７が最新のものを負荷低減の対象として選定して処理を終了する（ステップＳ３０）。
上記の判定処理において（ステップＳ２５）、重要度値が最大となるものが複数ある場合で、これらの中にクライアント端末が含まれていない場合（すなわち、Ｗｅｂカメラのみの場合）には、これらの中で、品質値（画像品質指定値３４＋負荷低減貢献値３３）と図４〜図６に示した画像品質値テーブルから求まる「帯域」が最大となる対象は１つであるか判定し（ステップＳ３１）、１つの場合には「帯域」が最大のＷｅｂカメラを負荷低減の対象として選定して処理を終了する（ステップＳ３２）。
一方、「帯域」が最大のＷｅｂカメラが２つ以上存在する場合には、これらの中のＷｅｂカメラ番号が最大のものを選定して（ステップＳ３３）、当該Ｗｅｂカメラを負荷低減の対象として選定して処理を終了する（ステップＳ３２）。
一方、「帯域」が最大のＷｅｂカメラが２つ以上存在する場合には、これらの中のＷｅｂカメラ番号が最大のものを選定して（ステップＳ３３）、当該Ｗｅｂカメラを負荷低減の対象として選定して処理を終了する（ステップＳ３２）。
したがって、帯域制限の対象は、重要性の最も低いもの（重要度の最も大きいもの）を選択するという基準、そして、Ｗｅｂカメラよりクライアント端末を優先して選択するという基準に基づいて選定される。
そして更に、同条件の複数のクライアント端末の間では、前回の使用帯域が大きい方のものを選定するという基準、そして更に、最新にアクセスされたものを選定するという基準に基づいて選定される。また、同条件の複数のＷｅｂカメラの間では、使用帯域が大きい方のものを選定するという基準、そして更に、Ｗｅｂカメラ番号が大きい方のものを選定するという基準に基づいて選定される。
もちろん、こちらの基準は一例であり、実際のシステムの設定状況に応じて任意に設定すればよいことは言うまでもない。例えば、クライアント端末よりＷｅｂカメラを優先して負荷低減処理の対象先として選択するという基準を用いてもよい。
なお、本実施例では、帯域制限を行った順序を負荷低減処理実施先テーブル５０に保持しており、帯域制限を解除する対象は、上記テーブルを用いて制限をかけた逆順で解除を行う。なお、「逆順」とは、必ずしも厳密に逆順としなくともよいが、重要性の高いものを優先して帯域制限の解除の対象先として選択されるようにし、画像の受信や配信の必要性が高いものについて、より十分な帯域を確保することが望ましい。
そして更に、同条件の複数のクライアント端末の間では、前回の使用帯域が大きい方のものを選定するという基準、そして更に、最新にアクセスされたものを選定するという基準に基づいて選定される。また、同条件の複数のＷｅｂカメラの間では、使用帯域が大きい方のものを選定するという基準、そして更に、Ｗｅｂカメラ番号が大きい方のものを選定するという基準に基づいて選定される。
もちろん、こちらの基準は一例であり、実際のシステムの設定状況に応じて任意に設定すればよいことは言うまでもない。例えば、クライアント端末よりＷｅｂカメラを優先して負荷低減処理の対象先として選択するという基準を用いてもよい。
なお、本実施例では、帯域制限を行った順序を負荷低減処理実施先テーブル５０に保持しており、帯域制限を解除する対象は、上記テーブルを用いて制限をかけた逆順で解除を行う。なお、「逆順」とは、必ずしも厳密に逆順としなくともよいが、重要性の高いものを優先して帯域制限の解除の対象先として選択されるようにし、画像の受信や配信の必要性が高いものについて、より十分な帯域を確保することが望ましい。
なお、上記の実施形態では、画像の受信および配信の間隔が１秒以下の場合においてのみ帯域制御を行う例で示したが、図４〜図７の画像品質値テーブルにおいて、受信および配信の間隔が１秒以下のものを定義して１秒以下の場合にも対応して帯域制御を行うようにしてもよい。
また、上記の例では、重要度（Ｗｅｂカメラ側では重要度３２、クライアント側では重要度４２）と、負荷低減貢献値（Ｗｅｂカメラ側では負荷低減貢献値３３、クライアント側では負荷低減貢献値４３）の２つの値をテーブルに用意しているが、帯域制御用テーブルに変数を用意せず、必要な時に重要度指定値（Ｗｅｂカメラ側では重要度指定値３１、クライアント側では重要度指定値４１）から負荷低減貢献値を引くことで求めてもよい。
また、上記の例では、重要度（Ｗｅｂカメラ側では重要度３２、クライアント側では重要度４２）と、負荷低減貢献値（Ｗｅｂカメラ側では負荷低減貢献値３３、クライアント側では負荷低減貢献値４３）の２つの値をテーブルに用意しているが、帯域制御用テーブルに変数を用意せず、必要な時に重要度指定値（Ｗｅｂカメラ側では重要度指定値３１、クライアント側では重要度指定値４１）から負荷低減貢献値を引くことで求めてもよい。
また、上記の例では、クライアント画像品質値テーブルは１つのみ用意しているが（図７参照）、ユーザ（クライアント端末側）に権限を設けて重要性についての優先度を付与する場合には、ユーザの権限毎に画像品質値テーブルを用意して、クライアント側帯域制御用テーブル４０にこれら画像品質値テーブルの内の使用するテーブルを特定する識別情報を追加し、Ｗｅｂカメラ側と同様に画像品質値テーブルを対象毎に選択設定できるようにしてもよい。そして、これにより、クライアント端末に配信する画像データのフレームサイズやフレームレートを設定してもよい。また、Ｗｅｂカメラから受信する画像データの処理において、上記実施形態で説明したクライアント端末に配信する画像データと同様に、画像データのサイズ等の画像フレームの品質に変更を加えずに、画像データフレームを通信する間隔を変更することで帯域制御を行うようにしてもよい。
また、画像蓄積配信サーバの運用について、クライアント端末への配信に使用する帯域を全般的に落としても、Ｗｅｂカメラからの画像データの蓄積を優先したいといった場合には、クライアント側の重要度指定値４１の値をＷｅｂカメラ側の重要度指定値３１より全般的に大きくすればよい。
また、上記の実施形態では、主にＷｅｂカメラ５からネットワーク４を経由して画像データを取得してディスク記録装置３へ書き込む処理過程での輻輳を検知し、これに応じた帯域制御を行う処理を説明したが、このような輻輳検知に応じた帯域制御をクライアント端末６への画像データ配信処理過程において行うようにしてもよく、Ｗｅｂカメラ５側とクライアント６側との少なくともいずれかい一方にて輻輳検知を行うようにすればよい。
また、上記の実施形態では、主にＷｅｂカメラ５からネットワーク４を経由して画像データを取得してディスク記録装置３へ書き込む処理過程での輻輳を検知し、これに応じた帯域制御を行う処理を説明したが、このような輻輳検知に応じた帯域制御をクライアント端末６への画像データ配信処理過程において行うようにしてもよく、Ｗｅｂカメラ５側とクライアント６側との少なくともいずれかい一方にて輻輳検知を行うようにすればよい。
また、上記の実施形態では、Ｗｅｂカメラ５からの通信データ量はフレーム単位で扱い、クライアント端末６への通信データ量はバイト単位で扱っているが、これらの単位は統一しても更には他の単位としてもよい。
また、上記の実施形態は、カメラからネットワークを介して受信する画像データの蓄積機能と、ネットワークを介してクライアント端末へ画像データを配信する機能とを備える画像蓄積配信サーバを例にとって説明したが、蓄積機能と配信機能とのいずれか一方を備えたものであってもよく、例えば、カメラはネットワーク接続されておらず、画像蓄積配信サーバが他の方法により蓄積した画像データをクライアント端末にネットワーク配信するようにしてもよい。
また、上記の実施形態は、カメラからネットワークを介して受信する画像データの蓄積機能と、ネットワークを介してクライアント端末へ画像データを配信する機能とを備える画像蓄積配信サーバを例にとって説明したが、蓄積機能と配信機能とのいずれか一方を備えたものであってもよく、例えば、カメラはネットワーク接続されておらず、画像蓄積配信サーバが他の方法により蓄積した画像データをクライアント端末にネットワーク配信するようにしてもよい。
１：画像蓄積配信サーバ、 ３：ディスク装置、
４：ネットワーク、 ５、５−１〜５―ｎ：カメラ、
６、６−１〜６−ｍ：クライアント端末、 ８：帯域制御用情報テーブル、
９：負荷監視スレッド、 ３０：Ｗｅｂカメラ側帯域制御用テーブル、
３１：重要度指定値、 ３２：重要度、
３３：負荷低減貢献度値、 ３４：画像品質指定値、
３５：画像品質値テーブル識別子、 ４０：クライアント側帯域制御用テーブル、
４１：重要度指定値、 ４２：重要度、
４３：負荷低減貢献度値、 ４４：画像品質指定値、
５０：負荷低減処理実施先テーブル、 ５２：負荷低減処理実施先識別子、
６０：最新負荷低減処理数変更時刻、 ６１：負荷低減処理実施数、
４：ネットワーク、 ５、５−１〜５―ｎ：カメラ、
６、６−１〜６−ｍ：クライアント端末、 ８：帯域制御用情報テーブル、
９：負荷監視スレッド、 ３０：Ｗｅｂカメラ側帯域制御用テーブル、
３１：重要度指定値、 ３２：重要度、
３３：負荷低減貢献度値、 ３４：画像品質指定値、
３５：画像品質値テーブル識別子、 ４０：クライアント側帯域制御用テーブル、
４１：重要度指定値、 ４２：重要度、
４３：負荷低減貢献度値、 ４４：画像品質指定値、
５０：負荷低減処理実施先テーブル、 ５２：負荷低減処理実施先識別子、
６０：最新負荷低減処理数変更時刻、 ６１：負荷低減処理実施数、
Claims (2)
- カメラで撮影された画像データを取得して蓄積し、当該蓄積された画像データをクライアント装置へ配信する画像蓄積配信システムの帯域制御方式において、
前記画像蓄積配信システムに備えられた設定手段が、カメラ側とクライアント装置側との少なくとも一方について重要性を示す値を設定し、
前記画像蓄積配信システムに備えられた検知手段が、カメラ又はクライアント装置とのネットワークを介した画像データ通信処理に係る実効帯域の低下を検知し、
前記画像蓄積配信システムに備えられた制御手段が、前記検知手段により実効帯域低下を検知した場合に、重要性の低いカメラ又はクライアント装置とのネットワークを介した画像データ通信処理の帯域制限を行なって帯域使用量を減らすことにより、重要性の高いカメラ又はクライアント装置とのネットワークを介した画像データ通信処理の帯域を確保し、
前記画像蓄積配信システムに備えられた管理手段が、既に行なった帯域制限の実施先と実施量の履歴を管理し、
更に、前記制御手段は、前記検知手段により実効帯域低下を検知して画像データの通信処理に係る帯域使用量を減らす際に、前記管理手段により管理される既に行なった帯域制限の実施先と実施量の履歴を参照して、重要性の低いカメラ又はクライアント装置から段階的に均一的に帯域制限を行なって帯域使用量を減らしていき、帯域制限の対象となったカメラ又はクライアント装置については、当該カメラ又はクライアント装置に対して設定されている重要性を一段階高くすることにより、帯域制限の実施先と実施量の偏りをなくす、ことを特徴とする画像蓄積配信システムの帯域制御方式。 - 請求項１に記載の画像蓄積配信システムの帯域制御方式において、
前記制御手段は、カメラ又はクライアント装置を対象として帯域制限処理を実行している状態において、所定の時間、当該対象について実効帯域の低下を検出しなかった場合には、前記管理手段により管理される既に行なった帯域制限の実施先と実施量の履歴に基づいて帯域制限を行なった逆順にて、実効帯域を確認しながら段階的に帯域制限を解除することを特徴とする画像蓄積配信システムの帯域制御方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003361006A JP3917124B2 (ja) | 2003-10-21 | 2003-10-21 | 画像蓄積配信システムの帯域制御方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003361006A JP3917124B2 (ja) | 2003-10-21 | 2003-10-21 | 画像蓄積配信システムの帯域制御方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005130041A JP2005130041A (ja) | 2005-05-19 |
| JP3917124B2 true JP3917124B2 (ja) | 2007-05-23 |
Family
ID=34641143
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003361006A Expired - Fee Related JP3917124B2 (ja) | 2003-10-21 | 2003-10-21 | 画像蓄積配信システムの帯域制御方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3917124B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2898757A1 (fr) * | 2006-03-14 | 2007-09-21 | Canon Kk | Procede et dispositif d'adaptation d'une frequence temporelle d'une sequence d'images video |
| US7912975B2 (en) * | 2008-03-03 | 2011-03-22 | Alcatel Lucent | System and method for application layer resource traffic control |
| JP2011170640A (ja) * | 2010-02-18 | 2011-09-01 | Nec Corp | キャッシュサーバ制御装置、コンテンツ配信システム、コンテンツ配信方法、及びプログラム |
| US9002973B2 (en) * | 2011-10-21 | 2015-04-07 | Fisher Controls International Llc | Delayed publishing in process control systems |
| JP6219101B2 (ja) * | 2013-08-29 | 2017-10-25 | 株式会社日立製作所 | 映像監視システム、映像監視方法、映像監視システム構築方法 |
| JP6049602B2 (ja) * | 2013-12-19 | 2016-12-21 | 三菱電機株式会社 | 映像処理装置 |
| JP6551926B2 (ja) * | 2015-06-05 | 2019-07-31 | 株式会社Ｂｌｕｅ Ｐｌａｎｅｔ−ｗｏｒｋｓ | メッセージ配信システム、メッセージ配信方法、およびプログラム |
| JP6862977B2 (ja) * | 2017-03-22 | 2021-04-21 | 富士通株式会社 | 通信制御プログラム、通信制御方法、および通信制御装置 |
| WO2019082864A1 (ja) | 2017-10-23 | 2019-05-02 | 日本電気株式会社 | 映像配信システム、映像配信方法、及び、映像配信プログラムを格納する記録媒体 |
| WO2022259541A1 (ja) * | 2021-06-11 | 2022-12-15 | 日本電気株式会社 | 監視システム、映像品質設定方法、群衆行動解析サーバ及び群衆行動解析プログラムが格納されるコンピュータ読み取り可能な非一時的記録媒体 |
-
2003
- 2003-10-21 JP JP2003361006A patent/JP3917124B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005130041A (ja) | 2005-05-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111628847B (zh) | 数据传输方法及装置 | |
| US10298969B2 (en) | Architecture and method for high performance on demand video transcoding | |
| US8219702B2 (en) | Video delivery apparatus and method | |
| US7954130B2 (en) | Network camera system and network camera control program | |
| JP3917124B2 (ja) | 画像蓄積配信システムの帯域制御方式 | |
| US10887363B1 (en) | Streaming decision in the cloud | |
| JP4270623B2 (ja) | 時系列データ蓄積配信システム | |
| JP2013214295A (ja) | 医用画像処理システム | |
| US10681400B2 (en) | Method and device for transmitting video | |
| US20150062344A1 (en) | Monitoring Camera Device and Monitoring Camera System | |
| CN115150473A (zh) | 一种资源调度方法、装置及存储介质 | |
| KR101668540B1 (ko) | 배신 네트워크와 서버 및 배신 방법 | |
| CN113068074B (zh) | 缓存方法和装置、计算机可读的存储介质及电子装置 | |
| CN112153419A (zh) | 一种网络资源配置调整方法、装置、服务器及存储介质 | |
| US11438545B2 (en) | Video image-based media stream bandwidth reduction | |
| JP2012150532A (ja) | キャッシュ装置、データ管理方法、プログラム、及びキャッシュシステム | |
| JP7220880B1 (ja) | データアクセスのためのシステム、方法、及びコンピュータ可読媒体 | |
| US10193770B2 (en) | Supplying data files to requesting stations | |
| JP5717589B2 (ja) | コンテンツ配信制御サーバ、方法及びプログラム | |
| US20180123965A1 (en) | Method for packet transmission apparatus to transmit packet in real time, packet transmission apparatus, and computer program | |
| JP4961994B2 (ja) | 帯域利用制御システム、帯域利用制御方法、装置及びそのプログラム | |
| JP4371859B2 (ja) | 動画情報伝送方法および装置 | |
| CN114936089A (zh) | 资源调度方法、系统、设备及存储介质 | |
| CN107734278A (zh) | 一种视频回放方法及相关装置 | |
| JP6204287B2 (ja) | 分散処理方法、処理サーバ、および、プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060620 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060809 |
|
| 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: 20070206 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070207 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3917124 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100216 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110216 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120216 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120216 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130216 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130216 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140216 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |