(57)【要約】【課題】  通話録音システムにおいて各通話録音サーバに保存された音声データを無駄なく大容量ストレージに保存すること。【解決手段】  通話録音サーバになる音声データをストレージに転送のために、それぞれの転送グループ毎にストレージの領域を割り当てるにあたり、実際に保存した容量の比率でストレージ内にボリューム割当を行うことによりフレキシブルに割当を行うようにしている。【選択図】  図１
2010147731.tif 000002
【特許請求の範囲】
【請求項１】
複数の拠点にあるＩＰ電話の通話を録音する通話録音サーバと、該サーバ内に録音された音声データを保存するストレージに転送する転送サーバからなる転送グループを複数備えた通話録音システムにおいて、
前記複数の転送グループ毎に前記ストレージの保存容量の割当をダイナミックに割り当てる通話録音制御サーバを設けたことを特徴とする通話録音システムにおける音声データ保存システム。
【請求項２】
前記転送グループが追加されたとき、前記ストレージへの保存容量の割り当てをダイナミックに行うことを特徴とする請求項１記載の通話録音システムにおける音声データ保存システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、通話録音システムにおける録音した音声データの保存システムに関する。
【背景技術】
【０００２】
従来は、音声データをストレージに保存する場合、大容量ストレージの保存領域をあらかじめ固定的に割り当てていた。
【０００３】
【特許文献１】特開平１１−１３６３６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、各拠点に設置された通話録音サーバに保存される音声データは拠点によって通話の頻度も異なるため、転送する音声データの容量も異なる場合に、それぞれ、転送グループ毎に大容量ストレージの保存領域をあらかじめ固定的に割り当てると、拠点におけるＩＰ電話での通話の頻度及び通話時間により、音声データの容量も異なってくるため、頻度と通話時間が長い拠点と、そうでない拠点において、保存効率が悪い。換言すれば、同じサイズで固定的に割り当てを行った場合、長期的な観点で見た場合、得策とはいえない。また、転送グループ毎に過去の通話実績をもとに固定的に容量を割り当てた場合も、拠点の統廃合、拠点の新設など何らかの要因で通話の頻度が変化した場合を考慮すると得策とはいえない。
【０００５】
つまり、蓄積データをあらかじめ固定的に割り当てて使用する従来システムでは、サーバにより容量が異なってしまうと、無駄が生じてしまう問題があった。
【０００６】
本願発明は、過去の録音した実績値から次に確保する容量を自動的に割り当て、効率的にデータの保存システム、方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的は、複数の拠点に設置された通話録音サーバとその中に保存された音声データを転送する転送サーバとを１グループとし、複数グループから通話録音システムが構成されている場合に、大容量ストレージのボリュームをあらかじめ固定的に設定するのではなく、転送グループ毎に割り当て容量を変化させる方式とし、ストレージ保存領域の無駄を少なくすることことを特徴とする。
【発明の効果】
【０００８】
本発明は、録音された音声データの容量の変化に対応して大容量ストレージへの保存領域を変化させているため、大容量ストレージの保存領域の無駄を最小限に抑える効果がある。１つの転送グループに想定外の音声データが保存されていった場合、その転送グループに割り当てた容量を使い果たした場合他の転送グループを含めたシステム全体で考えると、ディスクの空き容量はまだあるにもかかわらず、新規にディスク追加を実施する必要が発生してしまうのを防ぐことができる。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照して本発明の実施形態を説明する。
【実施例１】
【００１０】
以下、本発明の実施形態を図１から図９により説明する。まず、本発明に係る通話録音システムについて説明する。
【００１１】
図１はその一例で概要構成を示したものである。図のように通話録音システムは拠点側の通話録音サーバ通話録音サーバ１０１〜１０６と、センタ側の転送サーバ１０７〜１０９、ストレージ１１０、通話録音制御サーバ１１１〜１１３、データベースサーバ１１４、アプリケーションサーバ１１５、汎用サーバ１１６とから構成される。通話録音サーバ１０１〜１０６は拠点に設置されたＩＰ電話の通話を録音するためのサーバである。転送サーバ１０７〜１０９は通話録音サーバ１０１〜１０６で録音された音声データをストレージ１１０に転送するサーバである。通話録音制御サーバは、通話録音サーバを制御するサーバで、拠点にある各通話録音サーバが録音する電話機の電話番号や電話機台数などが登録されている。
【００１２】
本例では、通話録音システムの転送を行うグループとして３つのグループＡ、Ｂ、Ｃで構成されている。転送グループＡは通話録音サーバ１０１、１０２の音声データを転送サーバ１０７から、転送グループＢは通話録音サーバ１０３、１０４の音声データを転送サーバ１０８から、転送グループＣは通話録音サーバ１０５、１０６の音声データを転送サーバ１０９からそれぞれストレージ１１０へ転送することを想定している。
【００１３】
図２はストレージ１１０にボリューム割り当てを行うイメージを示す図である。汎用サーバ１１６は転送サーバ１０７、１０８、１０９にすでにストレージ１１０の割り当てがされているかを確認する(１)。ストレージ１１０にボリューム割当がされていない場合は、通話録音制御サーバ１１１、１１２、１１３に対して通話録音対象電話機台数を問い合わせ(２)、転送グループＡ、Ｂ、Ｃに対応したストレージ１１０に割り当てる容量をその比で計算し、初期割当を実施する(３)。ストレージ１１０にボリュームが既に割り当てられている場合は、転送グループが追加の場合は当分した容量を追加する。転送サーバ１０７、１０８、１０９にストレージ１１０の使用済み容量を確認し、閾値に達しているかどうかを判定する(１)。閾値超えしていない場合は特に何も行わない。閾値超えをしている場合は、割り当て可能な最終ボリュームかどうかを判定し、次に割り当てるボリュームが最終ボリュームでない場合は、転送サーバ１０７〜１０９の容量の比でストレージ１１０にボリュームの割当を実施する(３)。最終ボリュームの場合は、割り当てボリュームがなくなったことがわかるようにイベントログに通知後、転送サーバ１０７、１０８、１０９の容量の比でストレージ１１０にボリュームの割当を実施する(３)。
【００１４】
このイベントログを監視することにより、ディスクの追加検討を実施する。以上のフローを整理すると図３のようになる。本フローを日次で実行することを想定している。
【００１５】
図3のフロー図において、ステップ３０１で転送サーバにストレージのボリューム割当があるかどうかを確認し、ステップ３０２でボリュームがない場合は、新規にボリューム割りあり宛を行うため、ステップ３０３で示すように、各通話録音制御サーバに転送グループ毎の電話機台数を問い合わせ、その電話機台数の比でボリュームの初期割当容量を決定する。ステップ３０４で転送サーバ経由によりストレージのボリューム割当を実施する。ステップ３０２の判定追加で転送ボリュームがある場合は、ステップ３０５で追加の転送グループがあるかどうかの確認を行い、ステップ３０６で追加転送ボリュームがある場合は、ステップ３０７で追加転送ボリューム分の割当容量を確保し、ステップ３０６で追加ボリュームが無の場合と同様の遷移を行う。ステップ３０８で各転送サーバに割当容量を問い合わせ、閾値に達しているかどうか確認する。ステップ３０９の判定で閾値超えしていないならば特に何もしない。ステップ３０９で閾値超えしているものがあるならば、ステップ３１０で割当可能なボリュームの数を確認する。ステップ３１１で割当可能なボリューム数が１、つまり今回割り当てを行ったことにより、それ以降ボリューム割り当てができないならば、ステップ３１４で割当可能なボリュームがなくなる旨をイベントログに通知し、ＨＤＤ追加を喚起する。その後は割当可能なボリューム数が１でない場合と同様の処理を行う。ステップ３１２で各転送サーバにストレージの使用容量を問い合わせ、使用容量の多い順に比で割当容量を決定、その際にステップ３０６で追加のボリュームがあった場合はその分も考慮に入れて割当容量を決定する。ステップ３１３で転送サーバ経由によりストレージのボリューム割当を実施する。
【００１６】
図４〜６は図3で示したフロー図の動作を示したブロック図である。
【００１７】
図４は新規ボリューム割当時のブロック図を示す。まず、汎用サーバ内メイン処理部にて転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内のボリューム割当制御部にボリューム割当状況を確認する（１、２）。ボリューム割当がない場合、通話録音制御サーバＡ、通話録音サーバＢ、・・・に対して通話録音サーバ内電話機谷数算出処理部に電話番号台数を問い合わせ（３、４）、ストレージ割当容量計算部よりボリューム割当容量を決定し（５、６）、転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内ボリューム割当実施部にボリューム割当を実施させる（７、８、９）
図５は追加するグループがあり、各転送サーバの容量が閾値超えしていない場合のブロック図を示す。図４と同様にまず、汎用サーバ内メイン処理部にて転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内のボリューム割当制御部にボリューム割当状況を確認する（１、２）。追加する転送サーバがある場合、ストレージ割当容量計算部に追加分の割当領域をインプットする（３、４）。転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内ボリューム使用量管理部に対して各転送サーバの割当容量が閾値に達しているかどうかを確認する（５、６）。閾値に達していない場合は特になにもしない。
【００１８】
図６は各転送サーバの容量が閾値超えした場合のブロック図を示す。図５と同様にまず、汎用サーバ内メイン処理部にて転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内のボリューム割当制御部にボリューム割当状況を確認する（１、２）。転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内ボリューム使用量管理部に問い合わせを実施し（３、４）閾値に達している転送サーバがある場合、１、２で問い合わせた結果として割当可能なボリューム数が１の場合はイベントログに表示させる。ストレージ割当容量計算部にて、各転送サーバの使用容量の多い順の比で割当容量を決定し、転送サーバＡ、転送サーバＢ、・・・に対して転送サーバ内のボリューム割当実施部からストレージ割当を行う（５、６、７、８、９）。
【００１９】
図７〜９はストレージの転送グループがＡ〜Ｊの１０個あり、全体を１００とした場合の例を示す。
【００２０】
図７は容量変化を考慮しない例を示す。転送グループＡ〜Ｊすべて１０ずつの固定的に割当を行うことになる。
【００２１】
図８はフレキシブルに容量割当を行う例である。初期割当時については、通話録音制御サーバに登録されている電話機台数の比で割当を行う。図の例では、その比として、１２、１８、８、６、１０、８、８、８、１２、１０とした場合の例を記載する。ここでは閾値を８０％とし、転送グループＥが閾値に達した時点の使用容量及び使用容量/割当容量のパーセンテージが９(７５％)、１０(５６％)、６(７５％)、４(６７％)、８(８０％)、６(７５％)、６(７５％)、６(７５％)、８(６７％)、７(７０％)となっていた場合、２回目のボリューム割当については９+１４+６+４+８+６+６+６+８+７=７４が全体容量となり、それぞれ、９/７４=１２．１６％、１４/７４=１８．９２％、同様に８．１１％、５．４１％、１０．８１％、８．１１％、８．１１％、８．１１％、１０．８１％、９．４６％となるため、1ボリュームの全体１００とすると、それぞれ、転送グループＡから１２．１６、１８．９２、８．１１、５．４１、１０．８１、８．１１、８．１１、８．１１、１０．８１、９．４６となる。
【００２２】
次に、転送グループＡには元々の容量１２と追加容量１２．１６の計２４．１６となるが、同様に転送グループＢから３６，９２、１６．１１、１１．４１、２０．８１、１６．１１、１６．１１、１６．１１、２２．８１、１９．４６となる。
【００２３】
また、今度は転送グループＢが閾値８０％に達したと仮定して、その時点の各グループの使用容量が以下と仮定すると、転送グループＡから１７．０１(７０．４０％)、２９．５４(８０．００％)、１２．１５(７５．４３％)、６．０９(５３．３５％)、１４．５７(７０．００％)、１０．９４(６７．８９％)、９．７２(６０．３４％)、８．５１(５２．８０％)、１８．０２(７９．００％)、９．７３(５０．００％)となっていた場合、３回目のボリューム割当については、１７．０１+２９．５４+１２．１５+６．０９+１４．５７+１０．９４+９．７２+８．５１+１８．０２ +９．７３=１３６．２６、同様比例計算すると、追加容量は１２．４８、２１．６８、８．９２、４．４７、１０．６９、８．０３、７．１３、６．２４、１３．２３、７．１４となる。
【００２４】
次に転送グループＡには先の容量２４．１６と追加容量１２．４８の計３６．６５となるが、同様に転送グループＢから５８．５９、２５．０３、１５．８７、３１．５０、２４．１３、２３．２４、２２．３５、３６．０４、２６．６０となる。
【００２５】
また、今度も転送グループＢが閾値８０％に達したと仮定して、その時点の各グループの使用容量が以下と仮定すると、１８．３２(５０％)、４６．８８(８０％)、１５．００(６０％)、８．００(５０％)、２２．０５(７０％)、１６．８９(７０％)、１５．１１(６５％)、１３．４１(６０％)、２８．４７(７９％)、１５．９６(６０％)となった場合、４回目のボリューム割当については、１８．３２+４６．８８+１５．００+８．００+２２．０５+１６．８９+１５．１１ +１３．４１+２８．４７+１５．９６= ２００．０９、同様に比例計算すると、追加容量は９．１６、２３．４３、７．５０、４．００、１１．０２、８．４４、７．５５、６．７０、１４．２３、７．９８となる。
【００２６】
図７の容量変化を考慮しない例と図８のフレキシブルに容量割当を行う例を比較すると、転送グループＢの総容量は図７では４０となるが、図８では８２．０２となり、倍程度の容量を確保できたことになる。
【００２７】
最後に図９は転送グループが追加する事象が発生した場合の例である。３回目のボリューム割当までは図８と同様とし、その後、転送グループ追加となった場合を考慮する。新規の転送グループＫを11番目として追加とし、１００／１１=９．０９を新規グループに割り当て、それ以外の容量を比例計算して、８．３２、２１．３０、６．８２、３．６３、１０．０２、７．６８、６．８６、６．０９、１２．９３、７．２５、９．０９とし、フレキシブルに容量割当を行うものとなっている。
【図面の簡単な説明】
【００２８】
【図１】本発明に係る通話録音システの一例での概要構成を示す図
【図２】ストレージにボリューム割り当てを行うイメージ図
【図３】ボリューム割当フロー図
【図４】新規ボリューム割当時のブロック図
【図５】追加グループ有閾値超え無時のブロック図
【図６】追加グループ無閾値超え有割当可ボリューム有のブロック図
【図７】容量変化を考慮しない場合のボリューム割当例
【図８】フレキシブルに容量割当を行う場合のボリューム割当例
【図９】転送グループが追加になった場合のボリューム割当例
【符号の説明】
【００２９】
１０１〜１０６・・・通話録音サーバ、１０７〜１０９・・・転送サーバ、１１０・・・ストレージ、１１１〜１１３・・・通話録音制御サーバ、１１６・・・汎用サーバ
【図１】
2010147731.tif 000003
【図２】
2010147731.tif 000004
【図３】
2010147731.tif 000005
【図４】
2010147731.tif 000006
【図５】
2010147731.tif 000007
【図６】
2010147731.tif 000008
【図７】
2010147731.tif 000009
【図８】
2010147731.tif 000010
【図９】
2010147731.tif 000011