JP2017134560A - データ操作方法とデータ操作方法プログラム - Google Patents

Abstract

【課題】データの削除処理に関するシステムの負荷を軽減させるデータ操作方法を提供するデータ操作方法を提供する。【解決手段】運用管理装置２０が、検索キーを含む削除候補選択要求を、データ蓄積装置１０に送信し、検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードに、削除候補であることを表す削除候補フラグを付与する削除候補選択ステップと、データ蓄積装置１０が、検索キーを含むデータ送信要求を受信し、検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードに、削除候補フラグが付与されているか否かを判定する削除候補判定ステップＳ８と、データ蓄積装置１０が、前記判定した結果、削除候補フラグが付与されている場合は、前記送信を行わないデータ送信ステップＳ９とを含む。【選択図】図２

Description

本発明は、利用者端末から入力されるデータを蓄積してサービスを提供するシステムのデータ操作方法とデータ操作方法プログラムに関する。

利用者端末から入力されるデータを蓄積してサービスを提供するシステムとしては、例えばＮＴＴ東日本（東日本日本電信電話株式会社）が提供している「災害用伝言ダイヤル」が知られている（非特許文献１）。この「災害用伝言ダイヤル」における利用者からのデータは、音声である。

「災害用伝言ダイヤル」は、電話網上の蓄積型音声サービスの一種であり、利用者が電話機から「１７１番」にダイヤルすると、電話網に設けられた伝言ダイヤルセンタから、「こちらは災害用伝言ダイヤルです。録音される方は１、再生される方は２、…」というガイダンス音声が利用者の電話機へ送出され、ガイダンス音声に従ってダイヤルすることにより、災害伝言の録音、或いは再生を行うことができる。

［平成２８年１月４日検索］、インターネット＜URL:https://www.ntt-east.co.jp/saigai/voice171/＞ ［平成２８年１月４日検索］、インターネット＜URL:https://www.nttdocomo.co.jp/info/disaster/disaster_voice/＞

従来の災害用伝言ダイヤルでは、伝言の保存期間と一つの電話番号で録音できる伝言数に制限を設けている。保存期間は一律に48時間に制限されており、保存期間が満了すると自動的に消去される。録音できる蓄積伝言数の上限が決まっており、上限を超えた場合には古いメッセージから順に上書きされる。また、システムの制限により録音できる総蓄積伝言数に上限があり（例えば800万）、総伝言数の上限を越えれば、一つの電話番号で録音できる伝言数が上限以下であっても古いメッセージから順に上書きされる。伝言の保存期間は、状況に応じてＮＴＴが設定し、設定した期間を超えると、手動或いは自動で消去される。

しかし、災害時における伝言の数は数百万と膨大な数になる。したがって、膨大な数の伝言削除処理は、システムのCPUに負担をかけるので新たな伝言の蓄積や伝言提供に影響を与える場合がある。例えば、システムのCPU負荷が大きい時に伝言削除処理を行うと削除しきれずに古い伝言が残る場合がある。また、古い伝言が残ると蓄積できる伝言数に制限があるため、新規の伝言を登録できない場合がある。

本発明は、これらの課題に鑑みてなされたものであり、データの削除処理に関するシステムの負荷を軽減させるデータ操作方法とデータ操作プログラムを提供することを目的とする。

本発明のデータ操作方法は、データ蓄積装置が行うデータ操作方法であって、前記データ蓄積装置は、複数のデータを蓄積するデータ格納部と、各々の前記データのファイル名と前記データの属性情報とを対応付けたレコードを含むテーブルとを備え、運用管理装置から検索キーを含む削除候補選択要求を受信して、前記検索キーと一致する属性情報のレコードが前記テーブルにある場合、当該レコードに、削除候補であることを表す削除候補フラグを付与する削除候補選択ステップと、利用者端末から検索キーを含むデータ送信要求を受信し、前記検索キーと一致する属性情報のレコードが前記テーブルにある場合、当該レコードに、前記削除候補フラグが付与されているか否かを判定する削除候補判定ステップと、前記削除候補フラグが付与されていない場合は、当該レコードに対応するファイル名のデータを前記データ送信要求の送信元に送信し、前記削除候補フラグが付与されている場合は、前記データの送信を行わないデータ送信ステップとを行うことを要旨とする。

また、本発明のデータ操作方法プログラムは、上記のデータ操作方法をコンピュータに実行させるようにしたものである。

本発明によれば、データの削除処理に関するシステムの負荷を軽減させるデータ操作方法を提供することができる。

本発明のデータ操作方法を適用したシステム１の構成例を示す図である。 システム１を構成するデータ蓄積装置１０の動作フローを示す図である。 運用管理装置２０に表示される処理メニューの例を示す図である。 運用管理装置２０に表示される削除候補表示の例を示す図である。 データ蓄積装置１０が具備するテーブル１５の例を示す図である。 運用管理装置２０に表示される削除候補解除表示の例を示す図である。 運用管理装置２０に表示される削除予約表示の例を示す図である。 データ蓄積装置１０の変化率監視ステップの動作フローを示す図である。 利用者端末３０とデータ蓄積装置１０の動作シーケンスを示す図である。

以下、本発明の実施形態について図面を用いて説明する。複数の図面中同一のものには
同じ参照符号を付し、説明は繰り返さない。

〔システム〕
図１に、本発明のデータ操作方法を適用したシステム１の構成例を示す。システム１は、データ蓄積装置１０と運用管理装置２０とを備える。データ蓄積装置１０と利用者端末３０とは、ネットワーク４０を介して接続される。ネットワーク４０は、例えば電話網である。

データ蓄積装置１０と運用管理装置２０とは、例えばLANケーブル等を用いて直接接続される。なお、運用管理装置２０は、ネットワーク４０を介してデータ蓄積装置１０と接続するようにしても良い。

利用者端末３０は、複数の参照符号３０ａ,３０ｂ,…で示す様に多数存在する。利用者端末３０とデータ蓄積装置１０とは、ネットワーク４０を介して接続する。なお、以降において特に必要がある場合を除き、利用者端末３０の参照符号は３０として説明する。

データ蓄積装置１０と運用管理装置２０とは、例えばROM、RAM、CPU等で構成されるコンピュータに所定のプログラムが読み込まれて、CPUがそのプログラムを実行することで実現されるものである。

データ蓄積装置１０は、データ処理部１１とデータ格納部１７とで構成される。データ格納部１７は、多数の音声伝言を蓄積する。

データ処理部１１は、更に、データ登録部１２と、データ送信部１３と、データ削除部１４と、テーブル１５と、フラグ管理部１６とで構成される。テーブル１５は、データ格納部１７に蓄積された各々の音声伝言（データ）のファイル名と、データの属性情報とを対応付けたレコードを含むテーブルである。

フラグ管理部１６は、運用管理装置２０からの要求に対してテーブル１５のレコードにフラグを付与又は削除する。データ蓄積装置１０は、当該フラグの状態に応じてデータ格納部１７に蓄積されたデータの扱いを変える。テーブル１５と、そのレコードのフラグの状態によるデータの扱いについて詳しくは後述する。

システム１の動作を簡単に説明する。システム１は、例えば上記の「災害用伝言ダイヤル」として機能し、上記の伝言ダイヤルセンタに相当する機能を担う。以降の説明において、データは音声データであり、データ格納部１７に蓄積されるデータは、利用者端末３０から入力される音声伝言（以降データ）であるとして説明する。

例えば、利用者端末３０ａの所在地が被災したと仮定する。被災した利用者ａは、利用者端末３０ａからデータ蓄積装置１０に接続してデータを蓄積する。利用者端末３０ａから入力されたデータは、ネットワーク４０とデータ登録部１２を介してデータ格納部１７に蓄積される。

その後、利用者ａの安否を心配する被災地以外の遠隔地に住む利用者ｎは、図示しない利用者端末３０ｎを使用し、利用者端末３０ａの電話番号を含むデータ送信要求をデータ蓄積装置１０に送信する。そして、利用者端末３０ｎは、データ蓄積装置１０のデータ格納部１７に蓄積された利用者ａのデータを、データ送信部１３とネットワーク４０とを介して取得する。

図２に、データ蓄積装置１０の動作フローを示す。データ蓄積装置１０のデータ操作方法には、削除候補選択マーキングスレッドＳ２と削除候補解除マーキングスレッドＳ４と削除予約マーキングスレッドＳ６とが含まれる。スレッド（thread）とは、CPU利用の単位のことである。

削除候補選択マーキングスレッドＳ２は、運用管理装置２０から入力される検索キーを含む削除候補選択要求を受信して、当該検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードに、削除候補であることを表す削除候補フラグを付与する。ここで検索キーとは、利用者端末３０を識別する電話番号や、利用者端末３０の所在地を表す所在地情報や、伝言を蓄積してからの経過時間である蓄積時間や、伝言を蓄積した日時等のことであり、データの属性の一態様を決めるものである。

なお、削除候補解除マーキングスレッドＳ４と削除予約マーキングスレッドＳ６については後述する。

本実施形態のデータ操作方法には、更に削除候補判定ステップＳ８とデータ送信ステップＳ９とが含まれる。削除候補判定ステップＳ８とデータ送信ステップＳ９は、上記の利用者端末３０ｎからのデータ送信要求に対する処理である。ここでは、削除候補判定ステップＳ８とデータ送信ステップＳ９とについて説明し、データ蓄積装置１０の他の処理ステップについての説明は後述する。

削除候補判定ステップＳ８は、データ蓄積装置１０が、利用者端末３０から検索キーを含むデータ送信要求を受信し、検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードに、削除候補フラグが含まれているか否かを判定する。ここでデータ送信要求に含まれる検索キーとは、各々の利用者端末３０を識別する電話番号を含み、データ格納部１７に蓄積されたデータの属性の一態様を決めるものである。

データ送信ステップＳ９は、削除候補判定ステップＳ８で判定した結果、当該レコードに、削除候補フラグが付与されていない場合は、当該レコードに対応するファイル名のデータをデータ送信要求の送信元に送信する。そして、削除候補フラグが付与されている場合は、当該レコードに対応するファイル名のデータをデータ送信要求の送信元に送信しない。データ送信要求の送信元とは、例えば上記の利用者端末３０ｎのことである。

以上のように動作する本実施形態のデータ操作方法によれば、削除候補フラグを付与したレコードに対応するファイル名のデータは、データ格納部１７に蓄積されたまま残っているが、利用者端末３０に送信されない。

つまり、本実施形態のデータ操作方法によれば、削除候補選択フラグをレコードに付与した時点では、データを削除する削除処理を行わずデータの削除を仮想的に行ったものとして動作する。その結果、システム１のCPU負荷が大きな場合において、データの削除処理が中断することで生じる不要な伝言の残留や、新規なデータの蓄積（録音）が出来ない等の蓄積データを操作する上での課題を生じさせない。

図３に、運用管理装置２０に表示される処理メニューを示す。図２と図３を参照して更に詳しく本実施形態のデータ操作方法について説明する。

運用管理装置２０が動作を開始すると、図３に示す処理メニューが表示される。図３に示す処理メニューの例は、削除候補選択２００、削除候補解除２０１、削除予約２０２の３つで示す。それぞれの処理メニューは、削除候補選択マーキングスレッドＳ２、削除候補解除マーキングスレッドＳ４、削除予約マーキングスレッドＳ６に対応する。

〔削除候補選択〕
運用管理者が、削除候補選択２００を選択する（ステップＳ１のYes）と、運用管理装置２０は、検索キーを含む削除候補選択要求をデータ蓄積装置１０に送信する。データ蓄積装置１０は、削除候補選択要求を受信すると、削除候補選択マーキングスレッドＳ２を起動する。削除候補選択マーキングスレッドＳ２が起動すると、データ蓄積装置１０は、運用管理装置２０に図４に示す削除候補選択表示を表示させる。そして、データ蓄積装置１０は、削除候補選択要求に含まれる検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードに、削除候補であることを表す削除候補フラグを付与する（ステップＳ２ａ）。

削除候補選択表示（図４）の１列目は行を選択したことを表すチェックボックである。２列目は削除候補表示の削除単位２０３、３列目は設定値２０４である。削除単位２０３と設定値２０４は、データの属性を表す属性情報である。なお、総蓄積伝言数の時系列２０５と総蓄積伝言数の予測時系列２０６については後述する。

削除単位２０３として、例えば、データを蓄積してからの経過時間である蓄積時間２０３ａと、削除候補の対象とするデータを登録した利用者端末３０の所在地２０３ｂと、データを登録した登録日時２０３ｃとを表示している。そして、それぞれの削除単位２０３の設定値として「24時間２０３ａ１」、「北海道２０３ｂ１」、「2014年10月1日午前10時00分から2014年10月2日午前10時00まで２０３ｃ１」を表示している。

蓄積時間２０３ａの設定値は、例えば、24時間、32時間、40時間、任意の時間、の何れかが選択できる。蓄積時間２０３ａは、この例では選択していないので、蓄積時間２０３ａに対応する設定値は無効であり、何れの設定値のラジオボタンも点灯していない。

一方、削除単位２０３として選択した所在地２０３ｂの設定値２０４は、「北海道２０３ｂ１」のチェックボックスにチェックが入っている。また、もう一つの削除単位２０３として選択した登録日時２０３ｃの設定値２０４には、「2014年10月1日午前10時00分から2014年10月2日午前10時00まで２０３ｃ１」が入力されている。このように設定値は、予め設定した固定値であっても良いし、テキスト情報で入力するようにしても良い。

運用管理装置２０で削除単位２０３と設定値２０４を指定（データの属性を指定）すると、データ蓄積装置１０はテーブル１５を検索する。この例では、登録電話番号の所在地が「北海道２０３ｂ１」であり、登録日時２０３ｃが「2014年10月1日午前10時から10月2日の午前10時まで」に登録したデータのファイル名を含むテーブル１５のレコードを検索する。つまり、データ蓄積装置１０は、検索キーを「北海道２０３ｂ１」と当該登録日時としてテーブル１５を検索する。そして、検索キーの一致するテーブル１５のレコードに削除候補フラグを付与する。なお、レコードを検索してフラグを付与する主体は、フラグ管理部１６である。

図５に、テーブル１５のレコードの例を示す。テーブル１５のレコードは、図５に示す２行目以降の１行で表せる。この例では５個のレコード１５０〜１５４が表示されている。１つのレコードは、例えば、蓄積しているデータの登録者の電話番号２０７、登録電話番号の所在地２０３ｂ、登録日時２０３ｃ、データのファイル名２０８、パスワード２０９、ストレージ格納先２１０、削除候補フラグ２１１、削除予約フラグ２１２から構成される。

レコード１５０は、電話番号２０７に「031234567」、所在地２０３ｂに「北海道２０３ｂ１」、登録日時２０３ｃに「2014年10月1日20時20分」、パスワード２０９に「1234」を記憶している。レコード１５１以降については、記憶している情報の表記を省略している。パスワード２０９は、パスワードを用いたデータ送信の際に用いる
図５に示すレコード１５０の属性情報は、上記の検索キーの条件例に一致している。したがって、データ蓄積装置１０は、当該レコード１５０に削除候補フラグ２１１を付与する（○）。

次に、データ蓄積装置１０は、削除候補フラグ２１１が付与されたレコードに対応するファイル名のデータ格納部１７に蓄積されたデータをデータ量として算出せず、削除候補フラグ２１１が付与されていないレコードに対応するファイル名のデータをデータ量として算出する（図２、ステップＳ２ｂ）。この時、後述する削除予約フラグ２１２が付与されているレコードに対応するファイル名のデータもデータ量として算出しない。データ量の算出は、テーブル１５に対してSQLのカウント文を適用することで容易に行える。

データ蓄積装置１０は、ステップＳ２ｂを実行すると、算出したデータ量を、例えば総蓄積伝言数の時系列情報２０５（以降、時系列２０５）として出力し、運用管理装置２０に表示させる。時系列２０５の横軸は時間であり、縦軸はデータ数（伝言数）である。時系列２０５の横軸の右端が、削除単位２０３と設定値２０４を指定した時刻に相当する。削除単位２０３と設定値２０４を指定した時刻、つまり、検索するデータの属性を指定した時刻とは、削除単位２０３と設定値２０４を指定した後に、例えば、運用管理装置２０のEnterキー、或いは運用管理装置２０に表示されるボタンを操作した時刻である。

また、運用管理装置２０に、総蓄積伝言数の予測値の時系列情報２０６（以降、時系列２０６）も同時に表示させても良い。時系列２０６の横軸と縦軸は、時系列２０５と同じであるが表示される時間が未来である点と、件数が予測値である点で異なる。例えば時系列２０６の原点の時刻が、例えば検索するデータの属性を指定した時刻である。

なお、総蓄積伝言数の予測値は、例えば過去の同時期の同じ検索条件でのデータ量の推移を表示する。又は、時系列２０５から何らかの予測手法を用いて計算して求めても良い。

運用管理者は、表示されている時系列２０５と２０６とから、削除単位２０３と設定値２０４をどの程度にすれば良いかを判断する。そして、それぞれの項目を決定する。

例えば、関東地方で災害が発生した時には、関東地方を優先し、他の地方は非優先と考え、他の地方のチェックボックスをチェックする。登録日時を削除候補単位として選択する場合には、登録日時のチェックボックスにチェックを入れ、登録日時を入力する。

利用者端末３０ｎから、データの送信要求があった場合、削除候補フラグ２１１を付与したレコードに対応するファイル名のデータは、利用差端末３０ｎに送信しない。つまり、削除候補フラグ２１１を付与したレコードに対応するファイル名のデータは、上記の利用者端末３０ｎからのデータ送信要求の対象にならない。

したがって、削除候補選択２００の時点では、削除候補フラグ２１１を付与したレコードに対応するファイル名のデータは、存在しないものとして扱われる。ただし、この時点では、当該データは削除されていない。

このように削除候補選択２００が動作することで、ファイル削除処理に要する多大な時間とCPU過負荷によって生じる課題を解決するのと同時に、きめ細やかなデータ管理を実現することができる。なお、一度付与した削除候補フラグ２１１は、削除することができる。次に、削除候補フラグ２１１を削除する削除候補解除マーキングスレッドについて説明する。

〔削除候補解除〕
運用管理者が、削除候補解除２０１を選択する（ステップＳ３のYes）と、運用管理装置２０は、検索キーを含む削除候補解除要求をデータ蓄積装置１０に送信する。データ蓄積装置１０は、削除候補解除要求を受信すると、削除候補解除マーキングスレッドＳ４を起動する。削除候補解除マーキングスレッドＳ４が起動すると、運用管理装置２０に、図６に示す削除候補選択表示を表示させる。

そして、データ蓄積装置１０は、削除候補解除要求に含まれる検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードの削除候補フラグ２１１を解除する（ステップＳ４ａ）。削除候補フラグ２１１を解除するとは、図５に示す削除候補フラグ２１１の○を削除することである。

図６に示す例は、図４に示した削除候補表示を、全て解除した削除候補解除表示を示している。削除候補解除の表示は、例えばチェックボクスの点灯（■）で表示されている。

次に、データ蓄積装置１０は、削除候補フラグ２１１が付与されているレコード（削除候補フラグが削除されていないレコード）を検索し、当該レコードに対応するファイル名のデータ格納部１７に蓄積されたデータのデータ量を算出（ステップＳ４ｂ）し、算出したデータ量を、データを蓄積した時刻と関連付けて時系列２０５として出力する。出力した時系列２０５は、運用管理装置２０に表示される。ステップＳ４ｂは、上記のステップＳ２ｂと同じ処理である。

運用管理者は、時系列２０５によって、データ量がどのくらい増加するかを知ることができる。この時、総蓄積伝言数の予測値の時系列２０６も表示しても良い。時系列２０６の求め方は上記の方法と同じである。

削除候補解除２０１によれば、一度削除候補フラグ２１１を付与したレコードの削除候補フラグ２１１を削除することができる。削除候補フラグ２１１が削除されたレコードに対応するファイル名のデータは、存在するものとして処理される。つまり、削除候補フラグ２１１を削除したレコードに対応するファイル名のデータは、上記の利用者端末３０ｎからのデータ送信要求の対象になる。

運用管理者は、削除候補選択２００と削除候補解除２０１とによって、システム１のデータ管理を容易に行うことができる。次に、データの削除を予約する削除予約マーキングスレッドＳ６について説明する。

〔削除予約〕
運用管理者が、削除予約２０２を選択する（ステップＳ５のYes）と、運用管理装置２０は、検索キーを含む削除予約要求をデータ蓄積装置１０に送信する。データ蓄積装置１０は、削除予約要求を受信すると、削除予約マーキングスレッドＳ６を起動する。削除予約マーキングスレッドＳ６が起動すると、データ蓄積装置１０は、運用管理装置２０に、図７に示す削除予約表示を表示させる。

そして、データ蓄積装置１０は、削除予約要求に含まれる検索キーと一致する属性情報のレコードがテーブル１５にある場合、当該レコードに削除予約フラグ２１２を付与する（○）（ステップＳ６ａ）。

図７に示す例は、図４に示した削除候補表示を、全て削除することを示している。削除予約の表示は、例えばチェックボクスの点滅（■）で表示されている。

次に、データ蓄積装置１０は、削除予約フラグ２１２が付与されていないレコードを検索し、当該レコードに対応するファイル名のデータ格納部１７に蓄積されたデータをデータ量として算出する。算出したデータ量は、データを蓄積した時刻と関連付けた時系列情報として出力する。時系列情報は、例えば上記の時系列２０５と同様に、運用管理装置２０に表示させても良い。

なお、この時、削除予約フラグが付与されたレコードを検索し、削減するデータ量を求め、CPU使用率がどのくらい増加するかを表示するようにしても良い。その表示は、例えば時系列２０５の縦軸をCPU使用率にしたものが考えられる。

データ蓄積装置１０は、所定時間が経過する度に（ステップＳ１０）、テーブル１５の削除予約フラグ２１２が付与されているレコードを検索し、当該レコードに対応するファイル名のデータを削除する（ステップＳ１１）。ステップＳ１０の所定時間の計時を、運用管理装置２０と利用者端末３０の一方からデータの操作要求が有った場合に例えばリセットすると、データの削除（ステップＳ８）は、データの操作要求の無い時間帯に行われる。

データの操作要求の無い状態とは、例えば、災害が沈静化して総蓄積伝言数が減少し、システム１のCPU負荷に余裕が生じた状態である。このように削除予約２０２で削除予約フラグ２１２を付加したレコードに対応するファイル名のデータは、バックグラウンド処理で定期的に削除される。

なお、データの削除（ステップＳ８）は、データ蓄積装置１０にデータの蓄積要求をした要求元の所在地を表す所在地情報に応じて行うようにしても良い。例えば、関東地方で災害が発生した場合には、他の地方のデータの削除を優先して行うようにしても良い。

図８に、所在地情報に応じてデータの削除を行うようにしたデータ蓄積装置１０の動作フローを示す。データ蓄積装置１０は、所定時間が経過する度に、テーブル１５のレコードごとに所在地情報がレコード間で一致するレコードに対応するファイル名のデータのデータ量を、所在地情報ごとに算出し、算出したデータ量の変化率を監視する変化率監視ステップを行う（ステップＳ１２）。データ量の変化率とは、所定時間の間隔でデータ蓄積装置１０に蓄積されたデータ量の変化の度合いである。この変化率は、上記の時系列２０５と同様の方法で求めることができる。

データ量の変化率は、例えば被災地方とその他の地方とで差が出ると考えられる。また、データ量は被災地方に多く、その他の地方に少なく割当て、データの削除をその他の地方を優先して行うようにしても良い。

つまり、データの削除は、データ量の変化率が閾値より小さいデータを、当該変化率が前記閾値より大きいデータより先に削除するようにしても良い（ステップＳ１３）。そうすることで、必要性の高い所在地の利用者端末３０に、多くのデータ量を分配することも可能である。

〔利用者端末とデータ蓄積装置〕
図９に、データ蓄積装置１０と利用者端末３０の動作シーケンスを示す。図９を参照して、利用者端末３０とデータ蓄積装置１０の動作を詳しく説明する。

利用者端末３０を操作する利用者が、データ蓄積装置１０に対してデータの蓄積要求を行うと（ステップＳ１４のYes）、利用者端末３０はデータ蓄積装置１０に蓄積要求を送信する（ステップＳ１５）。

データ蓄積装置１０は、データの蓄積要求を受信すると（ステップＳ１６のYes）、該当利用端末（例えば３０ａ）からの蓄積伝言総数と総蓄積伝言数が、蓄積数上限を超えているか否かを判定する（ステップＳ１７）。例えば、１電話番号当たり10件以下及び総蓄積伝言数800万件以下の何れか一方を満たさない場合を、蓄積不可と判定する。判定は、テーブル１５のレコードを検索して件数等を数えることで行える。

該当利用者端末（例えば３０ａ）の蓄積伝言総数と総蓄積伝言数とが蓄積数上限以下で有る場合（ステップＳ１７の可）、データ蓄積装置１０は蓄積可能応答を利用者端末３０ａに送信する（ステップＳ１８）。

蓄積可能応答を受信した利用者端末３０ａは、データの登録が可能であることを利用者ａに知らせる。データの登録が可の場合（ステップＳ１９のYes）、利用者端末３０ａは、データをデータ蓄積装置１０に蓄積する目的で送信する（ステップＳ２０）。

データを受信したデータ蓄積装置１０は、データ登録部１２を介してデータ格納部１７にデータを蓄積する（ステップＳ２１）。蓄積したデータの属性情報は、テーブル１５のレコードに記録される。蓄積したデータの属性情報とは、上記の利用者の登録電話番号、伝言蓄積時間、登録電話番号の所在地、登録日時、音声伝言のファイル名、パスワード等である。

蓄積不可と判定された場合、データ蓄積装置１０は何も出力しない（ステップＳ１７の否、ステップＳ７のNo）。この場合、データ蓄積装置１０は、利用者端末３０ａにデータの蓄積が出来ないことを通知するようにしても良い。

利用者端末３０ｎを操作する利用者ｎが、データ蓄積装置１０に対してデータの送信要求を行うと（ステップＳ２２のYes）、利用者端末３０ｎはデータ蓄積装置１０にデータの送信要求を送信する（ステップＳ２３）。送信要求は、データの送信を要求する相手の電話番号を指定して行う。例えば、所在地が北海道札幌市の利用者端末mの電話番号「001*******」を入力して行う。

送信要求を受信したデータ蓄積装置１０は、テーブル１５を参照して相手の電話番号に対応するデータを検索する。そして、検索したデータの削除候補フラグ２１１の有無を確認する。検索したデータに削除候補フラグ２１１が付与されていない場合は、当該レコードに対応するファイル名のデータ格納部１７に蓄積されたデータを、送信要求の有った利用者端末３０ｎに送信する。

削除候補フラグ２１１が付与されている場合は、データ格納部１７に蓄積されている当該データを利用者端末３０ｎに送信しない。この場合、データ蓄積装置１０は、利用者端末３０ｎにデータ送信不可情報を送信しても良い。或いは、データ蓄積装置１０は、利用者端末３０ｎにデータを送信しないまま動作を終了しても良い。

以上説明したようにテーブル１５に、削除候補フラグ２１１と削除予約フラグ２１２とを設け、削除候補フラグ２１１が付加されたデータは存在しないものとして処理する。したがって、システム１は、データの削除処理が高速に行われたものとして動作することができる。

また、削除予約フラグ２１２が付与されたデータは、運用管理装置２０又は利用者端末３０からのデータ操作要求が無い期間に削除される。つまり、例えば災害が沈静化し、総蓄積データ数が減少し、システム１のCPU負荷に余裕が出て来た時に、データ蓄積装置１０は削除予約フラグ２１２が付与されたデータを削除する。したがって、データの削除処理に要する多大な時間とCPU過負荷によって生じる利便性の低下を解決することができる。

なお、上記した実施形態ではデータ格納部１７に記録するデータを音声伝言の例を示したが、本発明はこの例に限定されない。データはテキストでも画像データであっても本実施形態のデータ操作方法を適用することが可能である。

また、本実施形態のデータ操作方法を、データ蓄積装置１０が行う例で説明を行ったが、データ操作方法の処理ステップは複数の装置（サーバ）に分散させても良い。このように本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１：システム
１０：データ蓄積装置
１１：データ処理部
１２：データ登録部
１３：データ送信部
１４：データ削除部
１５：テーブル
１６：フラグ管理部
１７：データ格納部
２０：運用管理装置
３０：利用者端末
４０：ネットワーク

Claims (6)

1. データ蓄積装置が行うデータ操作方法であって、
   前記データ蓄積装置は、複数のデータを蓄積するデータ格納部と、各々の前記データのファイル名と前記データの属性情報とを対応付けたレコードを含むテーブルとを備え、
   運用管理装置から検索キーを含む削除候補選択要求を受信して、前記検索キーと一致する属性情報のレコードが前記テーブルにある場合、当該レコードに、削除候補であることを表す削除候補フラグを付与する削除候補選択ステップと、
   利用者端末から検索キーを含むデータ送信要求を受信し、前記検索キーと一致する属性情報のレコードが前記テーブルにある場合、当該レコードに、前記削除候補フラグが付与されているか否かを判定する削除候補判定ステップと、
   前記削除候補フラグが付与されていない場合は、当該レコードに対応するファイル名のデータを前記データ送信要求の送信元に送信し、前記削除候補フラグが付与されている場合は、前記データの送信を行わないデータ送信ステップと
   を行うことを特徴とするデータ操作方法。
2. 請求項１に記載したデータ操作方法において、
   運用管理装置から検索キーを含む削除候補解除要求を受信して、前記検索キーと一致する属性情報のレコードが前記テーブルにあり、且つ、当該レコードに前記削除候補フラグが付与されている場合、当該削除候補フラグを削除する削除候補解除ステップを行うことを特徴とするデータ操作方法。
3. 請求項１又は２に記載したデータ操作方法において、
   運用管理装置から検索キーを含む削除予約要求を受信して、前記検索キーと一致する属性情報のレコードが前記テーブルにある場合、当該レコードに、削除予約フラグを付与する削除予約ステップと、
   バックグラウンド処理で、前記テーブルの前記削除予約フラグが付与されているレコードを検索し、前記レコードに対応するファイル名のデータを前記データ格納部から削除する削除ステップと
   を行うことを特徴とするデータ操作方法。
4. 請求項３に記載したデータ操作方法において、
   前記レコードの属性情報は、前記データ蓄積装置にデータの蓄積要求をした要求元の所在地を表す所在地情報を含み、
   前記所在地情報が一致するそれぞれのレコードに対応するファイル名のデータのデータ量を、所定のタイミングで所在地情報ごとに算出し、算出したデータ量の変化率を監視する変化率監視ステップを行い、
   前記削除ステップにおいて、前記変化率が閾値より小さいデータを、前記変化率が前記閾値より大きいデータより先に削除することを特徴とするデータ操作方法。
5. 請求項１乃至４の何れかに記載したデータ操作方法において、
   前記削除候補フラグ又は削除予約フラグが付与されていないレコードを検索し、前記レコードに対応するファイル名のデータのデータ量を算出し、算出したデータ量を、前記データを蓄積した時刻と関連付けた時系列情報として出力する時系列出力ステップを行うことを特徴とするデータ操作方法。
6. 請求項１乃至５の何れかに記載したデータ操作方法を、コンピュータに実行させるためのデータ操作方法プログラム。

Images