特許 6021590 情報処理装置、情報処理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6021590

(24)【登録日】2016年10月14日

(45)【発行日】2016年11月9日

(54)【発明の名称】情報処理装置、情報処理方法及びプログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20161027BHJP

【ＦＩ】

   G06F12/00 537A

【請求項の数】7

【全頁数】9

(21)【出願番号】特願2012-240583(P2012-240583)

(22)【出願日】2012年10月31日

(65)【公開番号】特開2014-89667(P2014-89667A)

(43)【公開日】2014年5月15日

【審査請求日】2015年9月24日

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(74)【代理人】

【識別番号】110001737

【氏名又は名称】特許業務法人スズエ国際特許事務所

(72)【発明者】

【氏名】西山 薫

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 特開平１１−０８５５７９（ＪＰ，Ａ）

【文献】 特開２００７−２７９９２２（ＪＰ，Ａ）

【文献】 特開２００７−０１１９５９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

レコードデータを管理する管理手段と、
外部機器を利用するユーザが管理者ユーザであるか否かを判別する判別手段と、
前記外部機器より前記管理手段が管理する前記レコードデータの削除要求、参照要求及び編集要求を受信する受信手段と、を具備し、
前記管理手段は、
前記受信手段が受信した削除要求が前記管理者ユーザ以外のユーザからの削除要求である場合、前記削除要求の対象のレコードデータに削除フラグをセットして、当該レコードデータはファイルから削除せず、
前記削除フラグがセットされた前記レコードデータに対し前記管理者ユーザ以外のユーザから前記参照要求を受信すると参照不可とし、前記管理者ユーザから前記参照要求を受信すると参照可能とし、
前記管理者ユーザからの前記編集要求では前記削除要求の対象のレコードデータの前記削除フラグがリセット可能であるように制御する
情報処理装置。

【請求項2】

前記管理手段は、前記受信手段が受信した削除要求が前記管理者ユーザからの削除要求である場合、前記削除要求の対象の前記レコードデータを削除する請求項１記載の情報処理装置。

【請求項3】

前記管理手段は、
前記受信手段が受信した特定のファイルの前記参照要求が前記管理者ユーザからの参照要求である場合、前記管理者ユーザに対しては前記特定のファイルの全レコードデータが表示されるように制御し、
前記受信手段が受信した前記特定のファイルの前記参照要求が前記管理者ユーザ以外のユーザからの参照要求である場合、前記管理者ユーザ以外のユーザに対しては前記削除フラグがセットされたレコードデータ以外の前記特定のファイルのレコードデータが表示されるように制御する請求項１記載の情報処理装置。

【請求項4】

前記管理手段は、前記受信手段が受信した前記編集要求が前記管理者ユーザ以外のユーザからの前記編集要求である場合、前記削除フラグのリセットを不可とする請求項１記載の情報処理装置。

【請求項5】

前記管理手段は、前記削除フラグがセットされたレコードデータを、前記削除フラグがセットされてから所定時間経過後に削除する請求項１乃至請求項４のいずれか１項記載の情報処理装置。

【請求項6】

レコードデータを管理する情報処理装置の情報処理方法であって、
外部機器を利用するユーザが管理者ユーザであるか否かを判別し、
前記外部機器より前記情報処理装置が管理する前記レコードデータの削除要求、参照要求及び編集要求を受信し、
前記受信した削除要求が前記管理者ユーザ以外のユーザからの削除要求である場合、前記削除要求の対象のレコードデータに削除フラグをセットして、当該レコードデータはファイルから削除せず、
前記削除フラグがセットされた前記レコードデータに対し前記管理者ユーザ以外のユーザから前記参照要求を受信すると参照不可とし、前記管理者ユーザから前記参照要求を受信すると参照可能とし、
前記管理者ユーザからの前記編集要求に対しては前記削除要求の対象のレコードデータの前記削除フラグがリセット可能であるように制御する情報処理方法。

【請求項7】

コンピュータにより実行されるプログラムであって、前記プログラムは、
外部機器を利用するユーザが管理者ユーザであるか否かを判別し、
前記外部機器より情報処理装置が管理するレコードデータの削除要求、参照要求及び編集要求を受信し、
前記受信した削除要求が前記管理者ユーザ以外のユーザからの削除要求である場合、前記削除要求の対象のレコードデータに削除フラグをセットして、当該レコードデータはファイルから削除せず、
前記削除フラグがセットされた前記レコードデータに対し前記管理者ユーザ以外のユーザから前記参照要求を受信すると参照不可とし、前記管理者ユーザから前記参照要求を受信すると参照可能とし、
前記管理者ユーザからの前記編集要求に対しては前記削除要求の対象のレコードデータの削除フラグがリセット可能であるように制御する。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態はデータを管理する情報処理装置、情報処理方法及びプログラムに関する。

【背景技術】

【0002】

従来、データを管理するサーバと、多数のクライアントとからなる情報処理システムがある。データはサーバ側で保存され、クライアントには保存されない。ユーザはクライアントからデータ操作に関する要求（例えば、データ削除、編集等）をサーバに送信する。サーバはユーザからの要求に応じてデータ操作を実施する。

【0003】

このようなデータベースシステムの一例として検索システムがある。検索サーバは、検索結果の一覧表示に削除対象選択部を付加して検索者として削除対象を選択可能としている。選択された検索結果は非表示とされる。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開2006-155229号公報

【発明の概要】

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

【0005】

従来の情報処理装置は、どのユーザからのデータ操作要求、例えば削除要求に対しても同様な処理をしており、ユーザの種類毎にデータ操作の内容を変えることはしていない。しかし、多数のユーザの中にはデータベースの管理者的なユーザもいるし、データを入力するだけのオペレータ的なユーザ、あるいは閲覧するだけのユーザもいる。管理者的なユーザは他の種類のユーザに比べて権限が広いので、他のユーザとは異なる内容の特別なデータ操作が許可されていることがあり、ユーザの種類毎にデータ操作の内容を変える要求がある。

【0006】

本発明の目的は、ユーザの種類毎に異なるデータ操作を行うことができる情報処理装置、情報処理方法及びプログラムを提供することである。

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

【0007】

実施形態によれば、情報処理装置は、管理手段と、判別手段と、受信手段とを具備する。管理手段はレコードデータを管理する。判別手段は外部機器を利用するユーザが管理者ユーザであるか否かを判別する。受信手段は外部機器より管理手段が管理する前記レコードデータの削除要求、参照要求及び編集要求を受信する。管理手段は、受信手段が受信した削除要求が管理者ユーザ以外のユーザからの削除要求である場合、削除要求の対象のレコードデータに削除フラグをセットして、当該レコードデータはファイルから削除せず、前記削除フラグがセットされた前記レコードデータに対し前記管理者ユーザ以外のユーザから前記参照要求を受信すると参照不可とし、前記管理者ユーザからの参照要求を受信すると参照可能とし、管理者ユーザからの編集要求に対しては前記削除要求の対象のレコードデータの削除フラグがリセット可能であるように制御する。

【図面の簡単な説明】

【0008】

【図1】データベースシステムの実施形態の構成の一例を示すブロック図である。

【図2】実施形態の処理フローの一例の前半を示すフローチャートである。

【図3】実施形態の処理フローの一例の後半を示すフローチャートである。

【図4】実施形態のレコードの一例を示す図である。

【図5】実施形態の管理者の使用するクライアントの画面表示の一例を示す図である。

【図6】実施形態の管理者以外のユーザの使用するクライアントの画面表示の一例を示す図である。

【発明を実施するための形態】

【0009】

以下、第１の実施形態について図面を参照して説明する。

【0010】

図１は、データベースシステムの全体構成を示すブロック図である。データベースを含むサーバ１４に複数のクライアント１０_１、１０_２、…がネットワーク１２を介して接続されている。ネットワーク１２はＬＡＮでもよいし、インターネットでもよい。

【0011】

クライアント１０の一例は、パーソナルコンピュータがあるが、これに限らず、タブレット型端末等の一般的な情報処理端末が利用可能である。クライアント１０は、キーボード２２、ＬＣＤ等の表示部２４、ＣＰＵ等の制御部２６、有線ＬＡＮのための通信インターフェース２８、ネットワーク１２に接続されるＬＡＮ端子３０を含む。キーボード２２、表示部２４、制御部２６、通信Ｉ／Ｆ２８はバスラインに接続される。制御部２６はクライアントの動作を制御するクライアントプログラム（図示しない内蔵メモリに格納されている）を実行することにより、サーバ１４へデータ操作要求を送信し、サーバ１４からデータ操作結果を受信し、表示部２４に表示する機能を有する。

【0012】

クライアント１０を操作するユーザには、データベースの管理者もいるし、データを入力するだけのオペレータ、あるいは閲覧するだけのユーザもいる。クライアントプログラムは、クライアント１０の使用開始時にユーザにユーザＩＤの入力を促す。クライアント１０、あるいはサーバ１４は、入力されたユーザＩＤに基づいてユーザの種類を識別できる。なお、サーバ１４はユーザＩＤをクライアントＩＤとして管理することもある。この場合のクライアントＩＤはクライアントのハードウェア的なＩＤではなく、クライアントを使用しているユーザのＩＤである。

【0013】

サーバ１４は、クライアント１０からの要求を処理するユーザインタフェース（ＵＩ）処理部４２、定期的な処理を行なう定期処理部４４、データベース４８、データベース（ＤＢ）管理部４６、制御部５０、通信Ｉ／Ｆ５２、ＬＡＮ端子５４を含む。ＵＩ処理部４２は、クライアント１０からのデータ操作要求を受信し、ＤＢ管理部４６を介してデータベース４８を制御することにより要求を処理し、クライアント１０へデータの操作結果を返す。定期処理部４４は定期的に実データを削除する。この詳細は後述する。ＵＩ処理部４２、定期処理部４４、ＤＢ管理部４６、制御部５０、通信Ｉ／Ｆ５２はバスラインに接続される。データベース４８は多数のファイルを格納し、各ファイルは多数のレコードからなり、各レコードは種々のフィールドからなる。ＤＢ管理部４６はＵＩ処理部４２、定期処理部４４からのコマンドに基づきデータベース４８を管理する。すなわち、サーバ１４はデータを管理する。

【0014】

図２、図３はサーバ１４のＵＩ処理部４２、定期処理部４４によるデータベースの管理処理を示すフローチャートである。このフローチャートはユーザが外部機器としてのクライアント１０からサーバ１４へユーザＩＤとともにデータ操作要求を送信すると開始する。図示していないが、図２、図３のフローチャートは、ユーザがクライアント１０の処理を終了するまで続く。クライアント１０の使用開始時にユーザはユーザＩＤを入力する。データ操作は、例えば参照、編集、削除、追加を含むが、これらに限らず、検索、登録等を含んでも良い。参照は、ファイルの表示、利用等である。編集は、レコード内のフィールド単位のデータの変更である。削除、追加は、レコード単位のデータの削除、追加である。本実施形態は、サーバ１４がデータ操作要求を受けた場合、その要求を送信したユーザが所定ユーザ（例えば、管理者）であるか否かを判別し、判別結果に応じて処理の詳細を異ならせる。操作要求は操作対象（ファイル、レコード、フィールド等）を識別する情報も含む。

【0015】

ユーザから受信したデータ操作要求が参照要求であるか否かをブロックＢ１２で判定する。参照要求はファイルを対象とすることが多いが、ファイル全体でなく、その中の幾つかのレコード単位での参照もある。参照要求を受信した場合は、参照要求を送信したユーザは管理者であるか否かをブロックＢ１４で判定する。

【0016】

参照要求が管理者からの参照要求である場合は、当該要求で指定されたファイルの全レコードをブロックＢ１６でクライアント１０に送り、表示部２４で表示させる。

【0017】

参照要求が管理者以外のユーザからの参照要求である場合は、当該要求で指定されたファイルの全レコードのうち、特定のレコードのみをブロックＢ１８でクライアント１０に送り、表示部２４で表示させ、残りは非表示とさせる。このように特定のレコードは管理者に対しては表示されるが、それ以外のユーザに対しては非表示となるように制御される。特定のレコードの詳細は後述する。

【0018】

次に、表示部２４で表示されているファイルの削除、編集、追加について説明する。ブロックＢ１２で参照要求の受信を検出しない場合、及びブロックＢ１６、Ｂ１８の表示の後、ユーザから受信したデータ操作要求が削除要求（レコードの指定を含む）であるか否かをブロックＢ２０で判定する。削除要求を受信した場合は、削除要求を送信したユーザは管理者であるか否かをブロックＢ２２で判定する。

【0019】

削除要求が管理者からの削除要求である場合は、当該要求で指定されたレコードをファイルから削除するコマンドをブロックＢ２４でＤＢ管理部４６に与える。なお、削除は、完全に削除することに限らず、一時的にゴミ箱に入れて、一定期間後、あるいはユーザからの指示に応じてゴミ箱を空にすることにより完全に削除することも含む。

【0020】

削除要求が管理者以外のユーザからの削除要求である場合は、当該要求において指定されたレコードに所定のデータを付加するコマンドをブロックＢ２６でＤＢ管理部４６に与える。ＤＢ管理部４６は所定のデータを付加するが、当該レコードをファイルから削除することはしない。所定のデータの一例は、削除日付と削除フラグを含む。削除日付は、所定のフィールドのデータに付加される。所定のフィールドは、例えばコメントフィールドがある。コメントフィールドには自由にコメントを書くことができ、Del＋削除日付がコメントの先頭に付加される。削除フラグは例えば右端の専用のフィールドにセットされる。削除フラグは異なるユーザからの参照要求に対して異なる処理を行なうために用いられる。例えば、削除フラグがセットされたレコードは、管理者からの参照要求では参照可能とし、管理者以外のユーザからの参照要求では参照不可とする。図４は、管理者以外のユーザから削除要求が出され、所定のデータが付加されたレコードの一例を示す。レコードは、コメント、削除フラグ以外に、レコード名、クライアントＩＤ、アクセス日時のフィールド等を含む。クライアントＩＤは、実際には、クライアントを使用するユーザの種類を識別するユーザＩＤである。

【0021】

すなわち、参照要求が管理者以外のユーザからの参照要求である場合は、当該要求で指定されたファイルのレコードのうち、ブロックＢ２６で所定のデータが付加され、削除フラグがセットされているレコード以外のレコード（削除フラグがリセットされているレコード）のみがクライアント１０で表示される。すなわち、削除フラグがセットされているレコードは表示されない。これにより、管理者以外のクライアントのユーザは、レコードが削除されていると認識できる。

【0022】

ブロックＢ２０で削除要求の受信を検出しない場合、及びブロックＢ２４、Ｂ２６の削除処理の後、ユーザから受信したデータ操作要求が編集要求（フィールドの指定を含む）であるか否かをブロックＢ２８で判定する。編集要求を受信した場合は、編集要求を送信したユーザは管理者であるか否かをブロックＢ３０で判定する。

【0023】

編集要求が管理者からの編集要求である場合は、表示されているファイルの編集をブロックＢ３２で行なう。ブロックＢ１６で説明したように、管理者用の表示画面は、管理者以外のユーザにより削除要求が出され、所定のデータが付加され、削除フラグがセットされたレコードを含むので、管理者は管理者以外のユーザが間違って削除要求を出したレコードの所定データを削除（削除フラグもリセット）し、削除要求をキャンセルすることができる。

【0024】

編集要求が管理者以外のユーザからの編集要求である場合は、表示されているファイルの編集をブロックＢ３４で行なう。ブロックＢ１８で説明したように、管理者以外のユーザ用の表示画面は、削除要求が出され、削除フラグがセットされたレコードは表示されない。このように、管理者とそれ以外のユーザとでは、編集できる内容が異なる。

【0025】

ブロックＢ２８で編集要求の受信を検出しない場合、及びブロックＢ３２、Ｂ３４の編集処理の後、ユーザから受信したデータ操作要求が追加要求（レコードの追加）であるか否かをブロックＢ３６で判定する。追加要求を受信した場合は、追加要求を送信したユーザは管理者であるか否かをブロックＢ３８で判定する。

【0026】

追加要求が管理者からの追加要求である場合は、ブロックＢ４０で管理者用の追加処理１を行い、追加要求が管理者以外のユーザからの追加要求である場合は、ブロックＢ４２で管理者以外のユーザ用の追加処理２を行う。このように、追加処理も管理者とそれ以外のユーザとでは異なる。

【0027】

ブロックＢ３６で追加要求の受信を検出しない場合、及びブロックＢ４０、Ｂ４２の追加処理の後、ブロックＢ４４でタイマのカウント値に基づき一定時間（例えば、１日）が経過したか否かを判定する。一定時間が経過していなければ、ブロックＢ１２に戻り、参照要求の有無からの処理を繰り返す。一定時間が経過していれば、管理者以外のユーザにより削除要求が出され、所定のデータが付加され、削除フラグがセットされたレコードのアクセス日時をブロックＢ４６で調べる。管理者以外のユーザにより削除要求が出されてから、一定時間経過したレコードを実際に削除する。これは、管理者以外のユーザにより誤って削除要求が出された場合等に、削除要求を取り消す時間を確保するためである。

【0028】

この後、ブロックＢ４８でタイマをリセットし、ブロックＢ１２に戻り、参照要求の有無からの処理を繰り返す。

【0029】

図５、図６は、図４に示すように、管理者以外のユーザから削除要求が出され、所定のデータが付加されたレコード(001_0001)を含むファイルに参照要求が出された場合の、管理者のクライアントと、管理者以外のユーザのクライアントの表示画面の例を示す。

【0030】

すなわち、管理者が参照要求を出した場合は、ブロックＢ１６に示すように、当該要求で指定されたファイルの全レコードを表示する。このため、図５に示すように、図４に示すレコード(001_0001)も表示する。管理者はコメントフィールド内の削除の文字と、削除フラグがセットされていることから、レコード(001_0001)は管理者以外のユーザから削除要求が出されたことを認識する。管理者以外のユーザから削除要求取消を依頼された場合、あるいは削除が不適切であると判断した場合、管理者は編集要求を出して、コメントフィールドを書き直して削除の文字を抹消し、削除フラグをリセットする。

【0031】

管理者以外のユーザが参照要求を出した場合は、ブロックＢ１８に示すように、所定のデータが付加されたレコードは表示されない。このため、図６に示すように、図４に示すレコード(001_0001)は表示されない。管理者以外のユーザはレコード(001_0001)が削除されたことを認識する。

【0032】

以上説明したように、第１の実施形態によれば、異なる種類のユーザからの削除要求に対して異なる削除処理を行なうことができる。また、異なる種類のユーザからの参照要求に対して異なる参照処理を行なうことができる。そのため、管理者以外のユーザからの削除要求に対しては、所定のデータを付加するだけで実際にはレコードを削除せずにしておく。所定データが付加されたレコードは、管理者以外のユーザからの参照要求に対しては参照不可（表示しない）とし、管理者からの参照要求に対しては表示する。所定のデータが付加されたレコードは、管理者は編集可能であるが、管理者以外のユーザに対しては表示されないので、編集不可である。所定のデータが付加されたレコードは、一定時間経過後に実際に削除される。このように、管理者以外のユーザからの削除要求は管理者によって取り消すことができ、データを誤って削除することを防止できる。

【0033】

ユーザの種類を管理者とそれ以外の２種類としたが、３種類以上のユーザを識別して、ユーザの種類に応じた処理を行なっても良い。例えば、ある種類のユーザからの削除要求に対しては、管理者画面と同様に削除フラグがセットされたレコードも表示してもよい。ただし、この種類のユーザは削除フラグがセットされたレコードは編集不可とする。

【0034】

ユーザの種類に応じて処理を異ならせる対象として参照、削除、編集、追加を説明したが、これ以外の処理、例えば検索等もユーザの種類に応じて処理を異ならせてもよい。

【0035】

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

【符号の説明】

【0036】

１０…クライアント、１２…ネットワーク、１４…サーバ、２４…表示部、４２…ＵＩ処理部、４４…定期処理部、４６…ＤＢ管理部、４８…データベース。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】