図面 (/)

技術 データ操作方法とデータ操作方法プログラム

出願人 日本電信電話株式会社
発明者 大西正嗣
出願日 2016年1月27日 (5年1ヶ月経過) 出願番号 2016-012989
公開日 2017年8月3日 (3年6ヶ月経過) 公開番号 2017-134560
状態 特許登録済
技術分野 検索装置 計算機におけるファイル管理
主要キーワード 蓄積データ数 削除予約 災害用 データ送信不可 データ操作要求 CPU利用 蓄積数 音声伝言
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年8月3日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

データの削除処理に関するシステム負荷を軽減させるデータ操作方法を提供するデータ操作方法を提供する。

解決手段

運用管理装置20が、検索キーを含む削除候補選択要求を、データ蓄積装置10に送信し、検索キーと一致する属性情報レコードがテーブル15にある場合、当該レコードに、削除候補であることを表す削除候補フラグを付与する削除候補選択ステップと、データ蓄積装置10が、検索キーを含むデータ送信要求を受信し、検索キーと一致する属性情報のレコードがテーブル15にある場合、当該レコードに、削除候補フラグが付与されているか否かを判定する削除候補判定ステップS8と、データ蓄積装置10が、前記判定した結果、削除候補フラグが付与されている場合は、前記送信を行わないデータ送信ステップS9とを含む。

概要

背景

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

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

概要

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

目的

利用者端末から入力されるデータを蓄積してサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

請求項1に記載したデータ操作方法において、運用管理装置から検索キーを含む削除候補解除要求を受信して、前記検索キーと一致する属性情報のレコードが前記テーブルにあり、且つ、当該レコードに前記削除候補フラグが付与されている場合、当該削除候補フラグを削除する削除候補解除ステップを行うことを特徴とするデータ操作方法。

請求項3

請求項1又は2に記載したデータ操作方法において、運用管理装置から検索キーを含む削除予約要求を受信して、前記検索キーと一致する属性情報のレコードが前記テーブルにある場合、当該レコードに、削除予約フラグを付与する削除予約ステップと、バックグラウンド処理で、前記テーブルの前記削除予約フラグが付与されているレコードを検索し、前記レコードに対応するファイル名のデータを前記データ格納部から削除する削除ステップとを行うことを特徴とするデータ操作方法。

請求項4

請求項3に記載したデータ操作方法において、前記レコードの属性情報は、前記データ蓄積装置にデータの蓄積要求をした要求元所在地を表す所在地情報を含み、前記所在地情報が一致するそれぞれのレコードに対応するファイル名のデータのデータ量を、所定のタイミングで所在地情報ごとに算出し、算出したデータ量の変化率監視する変化率監視ステップを行い、前記削除ステップにおいて、前記変化率が閾値より小さいデータを、前記変化率が前記閾値より大きいデータより先に削除することを特徴とするデータ操作方法。

請求項5

請求項1乃至4の何れかに記載したデータ操作方法において、前記削除候補フラグ又は削除予約フラグが付与されていないレコードを検索し、前記レコードに対応するファイル名のデータのデータ量を算出し、算出したデータ量を、前記データを蓄積した時刻と関連付けた時系列情報として出力する時系列出力ステップを行うことを特徴とするデータ操作方法。

請求項6

請求項1乃至5の何れかに記載したデータ操作方法を、コンピュータに実行させるためのデータ操作方法プログラム

技術分野

0001

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

背景技術

0002

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

0003

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

先行技術

0004

[平成28年1月4日検索]、インターネット<URL:https://www.ntt-east.co.jp/saigai/voice171/>
[平成28年1月4日検索]、インターネット<URL:https://www.nttdocomo.co.jp/info/disaster/disaster_voice/>

発明が解決しようとする課題

0005

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

0006

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

0007

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

課題を解決するための手段

0008

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

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

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

実施例

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

データ処理部11は、更に、データ登録部12と、データ送信部13と、データ削除部14と、テーブル15と、フラグ管理部16とで構成される。テーブル15は、データ格納部17に蓄積された各々の音声伝言(データ)のファイル名と、データの属性情報とを対応付けたレコードを含むテーブルである。

0019

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

0020

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

0021

例えば、利用者端末30aの所在地被災したと仮定する。被災した利用者aは、利用者端末30aからデータ蓄積装置10に接続してデータを蓄積する。利用者端末30aから入力されたデータは、ネットワーク40とデータ登録部12を介してデータ格納部17に蓄積される。

0022

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

0023

図2に、データ蓄積装置10の動作フローを示す。データ蓄積装置10のデータ操作方法には、削除候補選択マーキングスレッドS2と削除候補解除マーキングスレッドS4と削除予約マーキングスレッドS6とが含まれる。スレッド(thread)とは、CPU利用の単位のことである。

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

運用管理装置20が動作を開始すると、図3に示す処理メニューが表示される。図3に示す処理メニューの例は、削除候補選択200、削除候補解除201、削除予約202の3つで示す。それぞれの処理メニューは、削除候補選択マーキングスレッドS2、削除候補解除マーキングスレッドS4、削除予約マーキングスレッドS6に対応する。

0033

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

0034

削除候補選択表示(図4)の1列目は行を選択したことを表すチェックボックである。2列目は削除候補表示の削除単位203、3列目は設定値204である。削除単位203と設定値204は、データの属性を表す属性情報である。なお、総蓄積伝言数の時系列205と総蓄積伝言数の予測時系列206については後述する。

0035

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

0036

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

0037

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

0038

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

0039

図5に、テーブル15のレコードの例を示す。テーブル15のレコードは、図5に示す2行目以降の1行で表せる。この例では5個のレコード150〜154が表示されている。1つのレコードは、例えば、蓄積しているデータの登録者の電話番号207、登録電話番号の所在地203b、登録日時203c、データのファイル名208、パスワード209、ストレージ格納先210、削除候補フラグ211、削除予約フラグ212から構成される。

0040

レコード150は、電話番号207に「031234567」、所在地203bに「北海道203b1」、登録日時203cに「2014年10月1日20時20分」、パスワード209に「1234」を記憶している。レコード151以降については、記憶している情報の表記を省略している。パスワード209は、パスワードを用いたデータ送信の際に用いる
図5に示すレコード150の属性情報は、上記の検索キーの条件例に一致している。したがって、データ蓄積装置10は、当該レコード150に削除候補フラグ211を付与する(○)。

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

〔削除候補解除〕
運用管理者が、削除候補解除201を選択する(ステップS3のYes)と、運用管理装置20は、検索キーを含む削除候補解除要求をデータ蓄積装置10に送信する。データ蓄積装置10は、削除候補解除要求を受信すると、削除候補解除マーキングスレッドS4を起動する。削除候補解除マーキングスレッドS4が起動すると、運用管理装置20に、図6に示す削除候補選択表示を表示させる。

0051

そして、データ蓄積装置10は、削除候補解除要求に含まれる検索キーと一致する属性情報のレコードがテーブル15にある場合、当該レコードの削除候補フラグ211を解除する(ステップS4a)。削除候補フラグ211を解除するとは、図5に示す削除候補フラグ211の○を削除することである。

0052

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

0053

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

0054

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

0055

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

0056

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

0057

〔削除予約〕
運用管理者が、削除予約202を選択する(ステップS5のYes)と、運用管理装置20は、検索キーを含む削除予約要求をデータ蓄積装置10に送信する。データ蓄積装置10は、削除予約要求を受信すると、削除予約マーキングスレッドS6を起動する。削除予約マーキングスレッドS6が起動すると、データ蓄積装置10は、運用管理装置20に、図7に示す削除予約表示を表示させる。

0058

そして、データ蓄積装置10は、削除予約要求に含まれる検索キーと一致する属性情報のレコードがテーブル15にある場合、当該レコードに削除予約フラグ212を付与する(○)(ステップS6a)。

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

利用者端末30を操作する利用者が、データ蓄積装置10に対してデータの蓄積要求を行うと(ステップS14のYes)、利用者端末30はデータ蓄積装置10に蓄積要求を送信する(ステップS15)。

0070

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

0071

該当利用者端末(例えば30a)の蓄積伝言総数と総蓄積伝言数とが蓄積数上限以下で有る場合(ステップS17の可)、データ蓄積装置10は蓄積可能応答を利用者端末30aに送信する(ステップS18)。

0072

蓄積可能応答を受信した利用者端末30aは、データの登録が可能であることを利用者aに知らせる。データの登録が可の場合(ステップS19のYes)、利用者端末30aは、データをデータ蓄積装置10に蓄積する目的で送信する(ステップS20)。

0073

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

0074

蓄積不可と判定された場合、データ蓄積装置10は何も出力しない(ステップS17の否、ステップS7のNo)。この場合、データ蓄積装置10は、利用者端末30aにデータの蓄積が出来ないことを通知するようにしても良い。

0075

利用者端末30nを操作する利用者nが、データ蓄積装置10に対してデータの送信要求を行うと(ステップS22のYes)、利用者端末30nはデータ蓄積装置10にデータの送信要求を送信する(ステップS23)。送信要求は、データの送信を要求する相手の電話番号を指定して行う。例えば、所在地が北海道市の利用者端末mの電話番号「001*******」を入力して行う。

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

1:システム
10:データ蓄積装置
11:データ処理部
12:データ登録部
13:データ送信部
14:データ削除部
15:テーブル
16:フラグ管理部
17:データ格納部
20:運用管理装置
30:利用者端末
40:ネットワーク

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 楽天株式会社の「 学習システム、学習方法、及びプログラム」が 公開されました。( 2021/01/07)

    【課題・解決手段】半教師あり学習において学習器の精度を高める。学習システム(S)の学習手段(103)は、複数の属性の各々の属性値を示す教師データに基づいて、複数の文書の各々に含まれる記号情報を分類する... 詳細

  • 三菱電機株式会社の「 推論装置、推論方法、及び推論プログラム」が 公開されました。( 2021/01/07)

    【課題・解決手段】推論装置(10)は、人間の状態に関する情報及び人間の行動に関する情報を含み、知識ベース(11a)から提供される知識情報と、ルールデータベース(12a)から提供される推論ルールとを用い... 詳細

  • 今福洋介の「 情報処理装置」が 公開されました。( 2021/01/07)

    【課題・解決手段】物を貸し出すことを希望する1以上の個人と、当該物の借り入れを希望する1以上の個人とのマッチングを効率よく行うことができる、CtoCレンタルプラットフォームを提供することを課題とする。... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ