JP3921865B2 - データ処理システムおよびそのプログラム記録媒体 - Google Patents
データ処理システムおよびそのプログラム記録媒体 Download PDFInfo
- Publication number
- JP3921865B2 JP3921865B2 JP06427199A JP6427199A JP3921865B2 JP 3921865 B2 JP3921865 B2 JP 3921865B2 JP 06427199 A JP06427199 A JP 06427199A JP 6427199 A JP6427199 A JP 6427199A JP 3921865 B2 JP3921865 B2 JP 3921865B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- update
- approval
- terminal
- destination
- 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
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、データに対するセキュリティ維持を図るために、データの更新を制御するデータ処理システムおよびそのプログラム記録媒体に関する。
【０００２】
【従来の技術】
従来、会社組織内に構築されているデータ処理システムにおいては、組織内で共有する各種のデータベースに対するセキュリティ機能として、組織内の規則や役職等に応じて担当者毎にデータベースへのアクセスを制限し、担当者は許可された権限の範囲内においてデータベースに対してデータの追加、削除、変更等を行うようにしている。
ところで、データベースの内容を変更する更新アクセスが制限されている担当者は、どのデータベースをどのように変更するかをその担当者が属する部署の上司と相談し、上司の承認を得なければならなかった。この場合、担当者はデータベースの更新内容を用紙上に手書によって記入したり、データ入力によって印刷し、それを上司に提出して承認を得るようにしていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、更新内容を用紙上に手書きによって記入したり、あるいはコンピュータから更新内容をデータ入力して承認要請書を印刷することは、作業効率が悪く、しかも、その担当者は上司から承認を受けたとしても、そのデータベースへの更新アクセスが制限されている環境下では、そのデータベースに対して更新権が付与されている別の担当者にその更新を依頼しなければならず、データベースのセキュリティ機能が実際の業務内容に合わなくなるという欠点があった。第１の発明の課題は、管理者の承認を受けたことを条件としてデータ更新を許可する監視条件付きのデータ更新を実現することができると共に、承認要請の自動化を実現できるようにすることである。
第２の発明の課題は、管理者の承認を条件とするデータに対してその承認を受けずにデータを更新したとしても、その後の承認可否に応じてデータ更新の有効／無効を制御できると共に、承認要請の自動化を実現できるようにすることである。
【０００４】
【課題を解決するための手段】
請求項１に記載のコンピュータシステムは、少なくとも複数台の端末装置がネットワーク上に接続されて成るコンピュータシステムにおいて、データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段と、前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段と、所定管理者の承認を必要とするデータに対して更新指示が行われた場合に、前記決定手段によりデータ更新可が決定されていることを条件に、その更新指示内容を一時記憶手段に書き込んで記憶保持しておくと共に、データの更新指定の承認要請を通知する第１の更新制御手段と、前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記一時記憶手段内の更新指示内容に基づいてデータを更新する第２の更新制御手段とを具備したことを特徴とする。
【０００５】
請求項２に記載のコンピュータシステムは、少なくとも複数台の端末装置がネットワーク上に接続されて成るコンピュータシステムにおいて、データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段と、前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段と、前記決定手段によりデータ更新可が決定されていることを条件に、データ更新の指示内容にしたがって該当するデータを暫定的に更新すると共に、前記更新指示が所定管理者の承認を必要とするデータに対して行われた場合に、データの更新指定の承認要請を通知する第１の更新制御手段と、前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記更新されたデータを確定し、承認不可であれば、前記更新されたデータを更新前の元のデータに戻す第２の更新制御手段とを具備したことを特徴とする。
【０００６】
【発明の実施の形態】
（第１実施形態）
以下、図１〜図８を参照してこの発明の第１実施形態を説明する。
図１は会社組織内において構築されているデータ処理システムを概念的に説明するためのシステム構成図である。このデータ処理システムはローカルエリアネットワークシステムあるいは広域システムで、複数台の端末装置ＴＭＬがネットワーク上に構内専用回線あるいは公衆電話回線を介して接続されていると共に、権限情報管理用サーバＡＭＳ、ＤＢ管理用サーバＤＢＳが接続されている。なお、複数台の端末装置ＴＭＬを説明の便宜上、変更データ管理用端末ＴＡ、データ確認＆承認処理用端末ＴＢに分けて以下説明する。すなわち、この実施形態はデータベースへのアクセス権限として管理者の承認を受けたことを条件としてデータベースの更新を許可する監視条件付きのアクセス権限を設定可能とするもので、変更データ管理用端末ＴＡは監視条件付きのアクセス権限が付与されている担当者側の端末装置であり、承認処理用端末ＴＢは管理者側の端末装置で、両者を観念的に区別して以下説明する。
【０００７】
変更データ管理用端末ＴＡにおいて管理者の承認を必要とするデータベースに対して更新指示が行われた場合に、その更新指示内容（更新レコード）を自己の一時ファイルＴＰＦに書き込んで記憶保持すると共に、その管理者側の承認処理用端末ＴＢに対してデータベース更新の承認要請を通知する。この承認要請を受けた承認処理用端末ＴＢ側においては、承認可否を決定し、その決定内容を要求元の変更データ管理用端末ＴＡに対して返送すると、変更データ管理用端末ＴＡは、その決定内容が承認可であることを条件に、一時ファイルＴＰＦの内容を読み出し、ＤＢ管理用サーバＤＢＳに対してデータベースの更新要求を行う。ＤＢ管理用サーバＤＢＳは各種のデータベースＤＢを管理運用するもので、変更データ管理用端末ＴＡから送信されて来た更新レコードに基づいて該当するデータベースの内容を更新する。この場合、更新種としては追加、変更、削除等であり、またデータベースＤＢはシステム全体で共通されるデータやプログラムである。権限情報管理用サーバＡＭＳはファイル別に担当者毎のアクセス権限を定義する権限情報ＡＨＹを管理するもので、変更データ管理用端末ＴＡから更新対象ファイル名やユーザ名が入力指定された際に、そのファイル名、ユーザ名に対応するアクセス権限をその端末へ返送する。
【０００８】
図２は権限情報ＡＨＹのデータ構造を示した図である。すなわち、権限情報ＡＨＹは図２（Ａ）に示すように、ファイル名別に各ユーザ（担当者）のアクセス権限を定義する構成で、図２（Ｂ）はその定義例を具体的に示している。ここで、ファイル名「購入物品台帳」に対してユーザ名「Ｏｐｅｒａｔｏｒ１」は、その権限種として「監視条件付き書き込み可」が定義されており、また監視ユーザ（上司等の管理）として「Ｍａｎａｇｅｒ１」、「Ｍａｎａｇｅｒ２」が定義されている。これはユーザ「Ｏｐｅｒａｔｏｒ１」がファイル「購入物品台帳」を更新する場合に、そのユーザの上司に当る２人の監視ユーザ「Ｍａｎａｇｅｒ１．２」の承認を得なけれぱそのファイルを更新することができないことを意味する。換言すれば、監視者の承認を得れば、そのファイルを自由に更新することができる条件付きアクセス権限の定義情報であることを意味している。また、図示の例のようにユーザ名「Ｏｐｅｒａｔｏｒ２」の権限種として「書き込み不可」が定義されている場合には、監視者の承認を得ても更新不可であることを意味し、この場合には監視ユーザの記述は省略される。一方、ファイル名「仕入れ台帳」についてユーザ名「Ｍａｎａｇｅｒ１」の権限種として「書き込み可、監視可」が定義されている。これはそのユーザの権限として該当ファイルを自由に更新できる他、「監視条件付き書き込み可」の権限が付与された他のユーザからの承認要請に対してその承認可否を決定する決定権を持つことを意味している。なお、監視ユーザとして定義される管理者としては、「係長」、「課長」、「室長」のように３人以上であってもよく、その人数は任意である。また、権限情報ＡＨＹには監視者情報ＯＢＶ（ユーザ使用端末情報）が添付されており、この監視者情報ＯＢＶは監視ユーザ名毎に承認要請の通知先ホスト名（ターミナルNo）を定義するもので、承認要請の通知時に権限情報ＡＨＹ内の監視ユーザ名に基づいて監視者情報ＯＢＶがアクセスされ、該当する通知先を取得する際に使用される。なお、権限情報ＡＨＹ、監視者情報ＯＢＶの内容はシステム管理者等が任意に設定可能なものである。
【０００９】
図３は端末装置ＴＭＬの全体構成を示したブロック図である。
ＣＰＵ１は各種プログラムにしたがってこの端末装置ＴＭＬの全体動作を制御する中央演算処理装置である。記憶装置２はオペレーティングシステムや各種アプリケーションプログラム、文字フォントデータ等が予め格納されている記憶媒体３やその駆動系を有している。この記憶媒体３は固定的に設けたもの、もしくは着脱自在に装着可能なものであり、フロッピーディスク、ハードディスク、光ディスク、ＲＡＭカード等の磁気的・光学的記憶媒体、半導体メモリによって構成されている。また、記憶媒体３内のプログラムやデータは、必要に応じてＣＰＵ１の制御により、ＲＡＭ４にロードされる。更に、ＣＰＵ１は通信回線等を介して他の機器側から送信されて来たプログラム、データを受信して記憶媒体３に格納したり、他の機器側に設けられている記憶媒体に格納されているプログラム、データを通信回線等を介して使用することもできる。また、ＣＰＵ１にはその入出力周辺デバイスである入力装置５、表示装置６、通信装置７がバスラインを介して接続されており、入出力プログラムにしたがってＣＰＵ１はそれらの動作を制御する。入力装置５は文字列データ等を入力したり、各種コマンドを入力するキーボード、マウス等のポインティングデバイスを有している。なお、表示装置６は液晶表示装置やＣＲＴ表示装置あるいはプラズマ表示装置等であり、また通信装置７は通信インターフェイスであり、通信回線を通してデータの送受信を制御する。
なお、権限情報管理用サーバＡＭＳ、ＤＢ管理用サーバＤＢＳもＣＰＵを中核として上述と同様の記憶装置を有する構成であるが、その構成は通常と同様であるため、図示省略するものとする。
【００１０】
次に、このデータ処理システムの動作を図４〜図７に示すフローチャートにしたがって説明する。ここで、これらのフローチャートに記述されている各機能を実現するためのプログラムは、読み取り可能なプログラムコードの形態で記憶媒体に格納されており、ＣＰＵはこのプログラムコードにしたがった動作を逐次実行する。このことは、後述する他の実施形態についても同様である。
いま、権限情報管理用サーバＡＭＳ側において、権限情報ＡＨＹにはファイル別に各ユーザ毎のアクセス権限（この場合にはデータ更新に関するアクセス権限）がシステム管理者等によって予め任意に設定されているものとする。
図４は変更データ管理用端末ＴＡにおいてデータベースの更新指示によって実行開始されるフローチャートである。先ず、更新対象ファイル名および自己のユーザ名が入力指定されると（ステップＡ１）、指定された対象ファイル名およびユーザ名を権限情報管理用サーバＡＭＳに対して送信し、権限種の取得要請を行い（ステップＡ２）、応答待ちとなる（ステップＡ３）。ここで、権限情報管理用サーバＡＭＳは図５のフローチャートにしたがった動作を行う。すなわち、図５は変更データ管理用端末ＴＡからの権限情報取得要請に応じて実行開始されるもので、要求情報の種類および対象ファイル名、ユーザ名を受信すると（ステップＢ１）、要求された情報は権限種かを判別するが（ステップＢ２）、いま、権限種の種得要請が要求されたので、受信した対象ファイル名、ユーザ名に基づいて権限情報ＡＨＹを検索し、該当する権限種を取得する（ステップＢ３）。そして、取得した権限種を要求元の変更データ管理用端末ＴＡへ送信する（ステップＢ６）。
【００１１】
ここで、変更データ管理用端末ＴＡ側において、権限情報管理用サーバＡＭＳからの権限種を受信すると、その種類を判別し（ステップＡ４）、「監視条件付き書込可」でなければ、ステップＡ５に進み、権限種は「書込不可」かを調べ、「書込不可」であれば、データベースへの更新指示を無効とするためにこのフローから抜け、ノンファンクションとなるが、「書込み可」であれば、ステップＡ６に進み、更新データの入力を受け付け可能とすると共に、入力された更新データを自己の一時ファイルＴＰＦへプールしたのち（ステップＡ７）、ＤＢ管理用サーバＤＢＳに対して更新要求を行い、一時ファイルＴＰＦ内の更新データをＤＢ管理用サーバＤＢＳへ送信する（ステップＡ１８）。
【００１２】
一方、権限種が「監視条件付き書込可」であれば、ステップＡ８に進み、更新データの入力を受け付け可能とすると共に、入力された更新データを自己の一時ファイルＴＰＦへプールして記憶保持しておく（ステップＡ９）。そして、ステップＡ１で指定された対象ファイル名およびユーザ名を権限情報管理用サーバＡＭＳへ送信し、承認を受ける監視者の使用端末を特定するためのターミナルNoの取得要請を行い（ステップＡ１０）、応答待ちとなる（ステップＡ１１）。ここで、権限情報管理用サーバＡＭＳは図５のフローチャートにしたがった動作を再開するが、この場合、要求情報の種類は権限種ではなく、監視者情報であるからそのことがステップＢ４で検出される。この場合、受信した対象ファイル名、ユーザ名に基づいて権限情報ＡＨＹをアクセスし、それに該当する各監視ユーザ名を読み出すと共に、この監視ユーザ名に基づいて監視者情報ＯＢＶをアクセスし、該当する通信先ホスト名（ターミナルNo）を取得する（ステップＢ５）。そして、取得した監視者情報を要求元の変更データ管理用端末ＴＡへ送信する（ステップＢ６）。
【００１３】
ここで、変更データ管理用端末ＴＡ側において監視者情報を受け取ると、それに応じて承認処理用端末ＴＢを選択して回線接続し（ステップＡ１２）、その承認処理用端末ＴＢに対して一時ファイルＴＰＦ内の更新データを送信すると共に、データ更新の承認要請を通知する（ステップＡ１３）。いま、監視者が２人以上であれば、その監視者を１人ずつ指定しながら全ての監視者に対して承認要請を通知し終るまで上述の動作を繰り返す（ステップＡ１２〜Ａ１４）。ここで、承認処理用端末ＴＢ側においてはデータ更新の承認要請を受けると、図６のフローチャートにしたがった動作を実行する。
【００１４】
すなわち、承認処理用端末ＴＢは承認要請を受信すると、その要請が有った旨のメッセージを画面上のメッセージ領域に表示する（ステップＣ１）。いま、そのユーザが表示メッセージを確認し、その詳細画面の表示を指示すると、承認要請のあった更新データが詳細表示される（ステップＣ２）。図８（Ａ）はこの場合における更新データの詳細画面を示し、どのファイルをどのように更新するかの一覧が表示される。この例では対象ファイル名は「購入物品台帳」であり、その更新内容の確認を促すために、更新レコードの内容が一覧表示されるが、現在日付や誰れからの要請かも付加される。この詳細画面と共に、画面上には図８（Ｂ）に示すような承認決定ウインドウも表示され、「ＹＥＳ」、「ＮＯ」ボタンのいずれかを操作することによって承認可否を選択指定すると（ステップＣ３）、その決定内容は要請元の変更データ管理用端末ＴＡに対して送信される（ステップＣ４）。
【００１５】
このようにして承認処理用端末ＴＢから承認可否の決定内容を受けた変更データ管理用端末ＴＡ側においては、その決定内容を受信する毎に（ステップＡ１５）、承認ＯＫか否かを判別すると共に（ステップＡ１６）、全ての監視者から承認ＯＫを受け取るまで待機する（ステップＡ１５〜Ａ１７）。ここで、１人でも承認不可の決定が下された場合には、データ更新の指示を無効とするためにこのフローから抜けるが、全ての管理者から承認可の決定を受けた場合には、それを条件に監視条件が解除される。この場合、変更データ管理用端末ＴＡは一時ファイルＴＰＦ内の更新データを読み出してＤＢ管理用サーバＤＢＳへ送信し、更新要求を行う（ステップＡ１８）。すると、ＤＢ管理用サーバＤＢＳはデータ更新要求に応じて図７のフローチャートを実行開始し、更新データを受信し（ステップＤ１）、この更新データに基づいて該当するデータベースＤＢを１レコードずつ更新する処理が行われる（ステップＤ２）。
【００１６】
以上のようにこの第１実施形態においては、データ更新のアクセス権限として「監視条件付き書込可」を設定するようにしたから、監視者の承認を受けた場合に限って許可されるデータ更新を実現することが可能となる。この場合、監視者の承認を受ける前に、更新データを入力することができ、入力された更新データは一時ファイルＴＰＦに記憶保持される。また、データ更新の承認要請をその監視者側の端末へ通知するようにしたから、承認要請の自動化を実現することが可能となる。また、アクセス権限としての「監視条件付き書込可」はファイル別にユーザ毎に設定することができるので、同じユーザであってもファイルの種類に応じて監視を条件とするか否かの設定が可能となる。また監視者側の端末ではどのファイルがどのように更新するのかの詳細画面が表示されるので、承認可否の決定をその場で行うことができる。
【００１７】
（第２実施形態）
以下、図９、図１０を参照してこの発明の第２実施形態を説明する。なお、上述した第１実施形態においては、監視者の承認を受けた際にデータベースＤＢを更新するようにしたが、この第２実施形態は承認を受ける前にデータベースＤＢを更新しておき、その後の承認可否に応じてデータ更新の有効／無効を決定するようにしたものであり、この第２実施形態において変更データ管理用端末ＴＡには、一時ファイルＴＰＦは存在しない。
図９はデータ更新が指示された際の変更データ管理用端末ＴＡの動作を示したフローチャートであり、図４と基本的に同様であるため、以下、その相違点を中心に説明するものとする。先ず、変更データ管理用端末ＴＡ側において更新対象ファイル名およびユーザ名に対応する権限種の取得要請を行い、それに応答して送信されて来た権限種を判別し（ステップＥ１〜Ｅ５）、「書込可」であれば、更新データを入力し、それを基にＤＢ管理用サーバＤＢＳに対してデータ更新を要求する（ステップＥ６、Ｅ７）。
【００１８】
一方、「監視条件付き書込可」の場合であれば、通常の「書込可」の場合と同様に更新データを入力し、それを基にＤＢ管理用サーバＤＢＳに対してデータ更新を要求するが、この場合のＤＢ管理用サーバＤＢＳに対して暫定的な更新要求を行う（ステップＥ８、Ｅ９）。
ここで、ＤＢ管理用サーバＤＢＳ側においては図１０に示したフローチャートにしたがった処理を実行する。すなわちデータベースＤＢに対する更新要求が、通常の「書込可」の場合ではなく「監視条件付き書込可」に伴う暫定的な更新要求である場合には（ステップＦ１）、その更新データを受信すると（ステップＦ２）、データベースＤＢ内に暫定更新管理情報ＴＥＭを作成すると共に、更新データに基づいて該当するデータベースＤＢを更新する（ステップＦ３）。ここで、暫定更新管理情報ＴＥＭは更新データを１レコード毎に記憶保持すると共に、更新データ毎に暫定フラグを記憶するもので、データベースＤＢへの更新が暫定的なものであることを示すために暫定フラグをＯＮさせておく。なお、暫定的な更新であっても、通常の「書込可」の場合と同様にデータベースＤＢの内容は更新データに基づいて書き替えられる。
【００１９】
次に、変更データ管理用端末ＴＡ側においては、監視者情報の取得要請を行い、全ての監視者側端末へデータ更新内容を送信すると共に、承認要請を通知する（ステップＥ１０〜Ｅ１４）。そして、全ての監視者から承認可否の決定通知が有るまで待機する（ステップＥ１５〜Ｅ１７）。ここで、全ての監視者から承認可の決定を受けた場合には、ＤＢ管理用サーバＤＢＳに対してデータの暫定更新内容の確定を要求する（ステップＥ１８）。すると、ＤＢ管理用サーバＤＢＳ側においては、暫定更新管理情報ＴＥＭを参照し、暫定フラグが立っている更新データが存在するかを調べ（ステップＦ４）、有れば、その暫定フラグおよび更新データを消去して暫定状態を解除する（ステップＦ５）。このような解除処理は暫定更新管理情報ＴＥＭ内の更新データに対して１レコード毎に繰り返される。一方、いずれかの監視者から承認不可の決定を受けた場合には、ＤＢ管理用サーバＤＢＳに対して暫定更新の棄却要求を行う（ステップＥ１８）。すると、ＤＢ管理用サーバＤＢＳ側においては、暫定更新管理情報ＴＥＭを参照し、暫定フラグが立っている更新データに基づいてデータベースＤＢを更新前の元の状態に戻す逆更新処理を行う（ステップＦ６）。これによって暫定更新された内容は棄却されて元の状態に戻される。
【００２０】
以上のようにこの第２実施形態においては、データ更新の指示内容にしたがって該当するデータを暫定的に更新すると共に、その更新指示内容が監視者の承認を必要とするデータに対して行われた場合に、その監視者側の端末装置に対してデータ更新の承認要請を通知し、この通知を受けた端末側において承認可否が決定された場合に、その決定内容が承認可であれば、暫定更新されたデータを確定し、承認不可であれば更新データを更新前の元の状態に戻すようにしたから、承認を受けずにデータを更新したとしてもその後の承認可否に応じてデータ更新の有効／無効を制御できると共に、承認要請の自動化を実現することが可能となる。その他、この第２実施形態においても上述した第１実施形態と同様の効果を有する。
【００２１】
なお、上述した各実施形態においては監視者側で承認可否を決定する場合、「ＹＥＳ」、「ＮＯ」ボタンを押下するようにしたが、署名という意味でパスワードを入力するようにすれば、承認決定の安全性を確保することができる。また、承認要請を通知してから承認決定が下されるまでの承認期限を設定しておき、一定期間以上承認決定されなかった場合に、承認要請通知を再送するようにしてもよい。更に、複数の監視者に対して承認を受ける場合において、承認要請通知を全監視者に対して行うが、その際、監視者を１人ずつ指定しながら要請通知を発行する代わりに全ての監視者に対して同報的に要請通知を行うようにしてもよい。更に、複数の監視者のうちいずれかの監視者からの承認決定が得られなかった場合に、その決定保留者だけに要請通知を再送するほか、決定済みである他の監視者の承認決定の内容を併わせて通知するようにすれば、決定保留者は他の監視者の承認可否を参考することができる。また、上述した各実施形態においては、オペレータによるデータ更新指示が行われる毎に、承認要請をリアルタイムで通知するようにしたが、バッチファイルの内容にしたがってデータを定期的に一括更新するバッチ処理毎に、承認要請を行うようにしてもよい。
【００２２】
【発明の効果】
第１の発明によれば、管理者の承認を受けたことを条件としてデータ更新を許可する監視条件付きのデータ更新を実現することができると共に、承認要請の自動化を実現することができる。
第２の発明によれば、管理者の承認を条件とするデータに対してその承認を受けずにデータを更新したとしても、その後の承認可否に応じてデータ更新の有効／無効を制御できると共に、承認要請の自動化を実現することができる。
【図面の簡単な説明】
【図１】データ処理システムを示したシステム構成図。
【図２】（Ａ）は権限情報管理用サーバＡＭＳ側に設定されている権限情報ＡＨＹのデータ構造を説明するための図で、（Ｂ）はその具体的な設定内容を示した図。
【図３】端末装置ＴＭＬの全体構成を示したブロック図、
【図４】変更データ管理用端末ＴＡにおいてデータベースの更新指示にしたがって実行開始されるフローチャート。
【図５】権限情報管理用サーバＡＭＳにおいて権限情報取得要請に応じて実行開始されるフローチャート。
【図６】承認処理用端末ＴＢにおいてデータ更新の承認要請に応じて実行開始されるフローチャート。
【図７】データベースＤＢ側においてデータ更新要求に応じて実行開始されるフローチャート。
【図８】（Ａ）、（Ｂ）は承認処理用端末ＴＢ側における承認画面を例示したもので、（Ａ）は詳細画面、（Ｂ）は承認決定ウインドウを示した図。
【図９】第２実施形態を説明するための図で、変更データ管理用端末ＴＡにおいてデータベースの更新指示にしたがって実行開始されるフローチャート。
【図１０】第２実施形態を説明するための図で、（Ａ）はＤＢ管理用サーバＤＢＳにおいてデータ更新要求や確定／棄却要求に応じて実行開始されるフローチャート、（Ｂ）はＤＢ管理用サーバＤＢＳ側の暫定更新管理情報ＴＥＭを示した図。
【符号の説明】
１ ＣＰＵ
２ 記憶装置
３ 記憶媒体
４ ＲＡＭ
５ 入力装置
６ 表示装置
７ 通信装置
ＴＡ 変更データ管理用端末
ＴＢ 承認処理用端末
ＡＭＳ 権限情報管理用サーバ
ＤＢＳ ＤＢ管理用サーバ
ＴＰＦ 一時ファイル
ＡＨＹ 権限情報
ＤＢ データベース
ＴＥＭ 暫定更新管理情報
ＯＢＶ 監視者情報
【発明の属する技術分野】
この発明は、データに対するセキュリティ維持を図るために、データの更新を制御するデータ処理システムおよびそのプログラム記録媒体に関する。
【０００２】
【従来の技術】
従来、会社組織内に構築されているデータ処理システムにおいては、組織内で共有する各種のデータベースに対するセキュリティ機能として、組織内の規則や役職等に応じて担当者毎にデータベースへのアクセスを制限し、担当者は許可された権限の範囲内においてデータベースに対してデータの追加、削除、変更等を行うようにしている。
ところで、データベースの内容を変更する更新アクセスが制限されている担当者は、どのデータベースをどのように変更するかをその担当者が属する部署の上司と相談し、上司の承認を得なければならなかった。この場合、担当者はデータベースの更新内容を用紙上に手書によって記入したり、データ入力によって印刷し、それを上司に提出して承認を得るようにしていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、更新内容を用紙上に手書きによって記入したり、あるいはコンピュータから更新内容をデータ入力して承認要請書を印刷することは、作業効率が悪く、しかも、その担当者は上司から承認を受けたとしても、そのデータベースへの更新アクセスが制限されている環境下では、そのデータベースに対して更新権が付与されている別の担当者にその更新を依頼しなければならず、データベースのセキュリティ機能が実際の業務内容に合わなくなるという欠点があった。第１の発明の課題は、管理者の承認を受けたことを条件としてデータ更新を許可する監視条件付きのデータ更新を実現することができると共に、承認要請の自動化を実現できるようにすることである。
第２の発明の課題は、管理者の承認を条件とするデータに対してその承認を受けずにデータを更新したとしても、その後の承認可否に応じてデータ更新の有効／無効を制御できると共に、承認要請の自動化を実現できるようにすることである。
【０００４】
【課題を解決するための手段】
請求項１に記載のコンピュータシステムは、少なくとも複数台の端末装置がネットワーク上に接続されて成るコンピュータシステムにおいて、データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段と、前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段と、所定管理者の承認を必要とするデータに対して更新指示が行われた場合に、前記決定手段によりデータ更新可が決定されていることを条件に、その更新指示内容を一時記憶手段に書き込んで記憶保持しておくと共に、データの更新指定の承認要請を通知する第１の更新制御手段と、前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記一時記憶手段内の更新指示内容に基づいてデータを更新する第２の更新制御手段とを具備したことを特徴とする。
【０００５】
請求項２に記載のコンピュータシステムは、少なくとも複数台の端末装置がネットワーク上に接続されて成るコンピュータシステムにおいて、データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段と、前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段と、前記決定手段によりデータ更新可が決定されていることを条件に、データ更新の指示内容にしたがって該当するデータを暫定的に更新すると共に、前記更新指示が所定管理者の承認を必要とするデータに対して行われた場合に、データの更新指定の承認要請を通知する第１の更新制御手段と、前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記更新されたデータを確定し、承認不可であれば、前記更新されたデータを更新前の元のデータに戻す第２の更新制御手段とを具備したことを特徴とする。
【０００６】
【発明の実施の形態】
（第１実施形態）
以下、図１〜図８を参照してこの発明の第１実施形態を説明する。
図１は会社組織内において構築されているデータ処理システムを概念的に説明するためのシステム構成図である。このデータ処理システムはローカルエリアネットワークシステムあるいは広域システムで、複数台の端末装置ＴＭＬがネットワーク上に構内専用回線あるいは公衆電話回線を介して接続されていると共に、権限情報管理用サーバＡＭＳ、ＤＢ管理用サーバＤＢＳが接続されている。なお、複数台の端末装置ＴＭＬを説明の便宜上、変更データ管理用端末ＴＡ、データ確認＆承認処理用端末ＴＢに分けて以下説明する。すなわち、この実施形態はデータベースへのアクセス権限として管理者の承認を受けたことを条件としてデータベースの更新を許可する監視条件付きのアクセス権限を設定可能とするもので、変更データ管理用端末ＴＡは監視条件付きのアクセス権限が付与されている担当者側の端末装置であり、承認処理用端末ＴＢは管理者側の端末装置で、両者を観念的に区別して以下説明する。
【０００７】
変更データ管理用端末ＴＡにおいて管理者の承認を必要とするデータベースに対して更新指示が行われた場合に、その更新指示内容（更新レコード）を自己の一時ファイルＴＰＦに書き込んで記憶保持すると共に、その管理者側の承認処理用端末ＴＢに対してデータベース更新の承認要請を通知する。この承認要請を受けた承認処理用端末ＴＢ側においては、承認可否を決定し、その決定内容を要求元の変更データ管理用端末ＴＡに対して返送すると、変更データ管理用端末ＴＡは、その決定内容が承認可であることを条件に、一時ファイルＴＰＦの内容を読み出し、ＤＢ管理用サーバＤＢＳに対してデータベースの更新要求を行う。ＤＢ管理用サーバＤＢＳは各種のデータベースＤＢを管理運用するもので、変更データ管理用端末ＴＡから送信されて来た更新レコードに基づいて該当するデータベースの内容を更新する。この場合、更新種としては追加、変更、削除等であり、またデータベースＤＢはシステム全体で共通されるデータやプログラムである。権限情報管理用サーバＡＭＳはファイル別に担当者毎のアクセス権限を定義する権限情報ＡＨＹを管理するもので、変更データ管理用端末ＴＡから更新対象ファイル名やユーザ名が入力指定された際に、そのファイル名、ユーザ名に対応するアクセス権限をその端末へ返送する。
【０００８】
図２は権限情報ＡＨＹのデータ構造を示した図である。すなわち、権限情報ＡＨＹは図２（Ａ）に示すように、ファイル名別に各ユーザ（担当者）のアクセス権限を定義する構成で、図２（Ｂ）はその定義例を具体的に示している。ここで、ファイル名「購入物品台帳」に対してユーザ名「Ｏｐｅｒａｔｏｒ１」は、その権限種として「監視条件付き書き込み可」が定義されており、また監視ユーザ（上司等の管理）として「Ｍａｎａｇｅｒ１」、「Ｍａｎａｇｅｒ２」が定義されている。これはユーザ「Ｏｐｅｒａｔｏｒ１」がファイル「購入物品台帳」を更新する場合に、そのユーザの上司に当る２人の監視ユーザ「Ｍａｎａｇｅｒ１．２」の承認を得なけれぱそのファイルを更新することができないことを意味する。換言すれば、監視者の承認を得れば、そのファイルを自由に更新することができる条件付きアクセス権限の定義情報であることを意味している。また、図示の例のようにユーザ名「Ｏｐｅｒａｔｏｒ２」の権限種として「書き込み不可」が定義されている場合には、監視者の承認を得ても更新不可であることを意味し、この場合には監視ユーザの記述は省略される。一方、ファイル名「仕入れ台帳」についてユーザ名「Ｍａｎａｇｅｒ１」の権限種として「書き込み可、監視可」が定義されている。これはそのユーザの権限として該当ファイルを自由に更新できる他、「監視条件付き書き込み可」の権限が付与された他のユーザからの承認要請に対してその承認可否を決定する決定権を持つことを意味している。なお、監視ユーザとして定義される管理者としては、「係長」、「課長」、「室長」のように３人以上であってもよく、その人数は任意である。また、権限情報ＡＨＹには監視者情報ＯＢＶ（ユーザ使用端末情報）が添付されており、この監視者情報ＯＢＶは監視ユーザ名毎に承認要請の通知先ホスト名（ターミナルNo）を定義するもので、承認要請の通知時に権限情報ＡＨＹ内の監視ユーザ名に基づいて監視者情報ＯＢＶがアクセスされ、該当する通知先を取得する際に使用される。なお、権限情報ＡＨＹ、監視者情報ＯＢＶの内容はシステム管理者等が任意に設定可能なものである。
【０００９】
図３は端末装置ＴＭＬの全体構成を示したブロック図である。
ＣＰＵ１は各種プログラムにしたがってこの端末装置ＴＭＬの全体動作を制御する中央演算処理装置である。記憶装置２はオペレーティングシステムや各種アプリケーションプログラム、文字フォントデータ等が予め格納されている記憶媒体３やその駆動系を有している。この記憶媒体３は固定的に設けたもの、もしくは着脱自在に装着可能なものであり、フロッピーディスク、ハードディスク、光ディスク、ＲＡＭカード等の磁気的・光学的記憶媒体、半導体メモリによって構成されている。また、記憶媒体３内のプログラムやデータは、必要に応じてＣＰＵ１の制御により、ＲＡＭ４にロードされる。更に、ＣＰＵ１は通信回線等を介して他の機器側から送信されて来たプログラム、データを受信して記憶媒体３に格納したり、他の機器側に設けられている記憶媒体に格納されているプログラム、データを通信回線等を介して使用することもできる。また、ＣＰＵ１にはその入出力周辺デバイスである入力装置５、表示装置６、通信装置７がバスラインを介して接続されており、入出力プログラムにしたがってＣＰＵ１はそれらの動作を制御する。入力装置５は文字列データ等を入力したり、各種コマンドを入力するキーボード、マウス等のポインティングデバイスを有している。なお、表示装置６は液晶表示装置やＣＲＴ表示装置あるいはプラズマ表示装置等であり、また通信装置７は通信インターフェイスであり、通信回線を通してデータの送受信を制御する。
なお、権限情報管理用サーバＡＭＳ、ＤＢ管理用サーバＤＢＳもＣＰＵを中核として上述と同様の記憶装置を有する構成であるが、その構成は通常と同様であるため、図示省略するものとする。
【００１０】
次に、このデータ処理システムの動作を図４〜図７に示すフローチャートにしたがって説明する。ここで、これらのフローチャートに記述されている各機能を実現するためのプログラムは、読み取り可能なプログラムコードの形態で記憶媒体に格納されており、ＣＰＵはこのプログラムコードにしたがった動作を逐次実行する。このことは、後述する他の実施形態についても同様である。
いま、権限情報管理用サーバＡＭＳ側において、権限情報ＡＨＹにはファイル別に各ユーザ毎のアクセス権限（この場合にはデータ更新に関するアクセス権限）がシステム管理者等によって予め任意に設定されているものとする。
図４は変更データ管理用端末ＴＡにおいてデータベースの更新指示によって実行開始されるフローチャートである。先ず、更新対象ファイル名および自己のユーザ名が入力指定されると（ステップＡ１）、指定された対象ファイル名およびユーザ名を権限情報管理用サーバＡＭＳに対して送信し、権限種の取得要請を行い（ステップＡ２）、応答待ちとなる（ステップＡ３）。ここで、権限情報管理用サーバＡＭＳは図５のフローチャートにしたがった動作を行う。すなわち、図５は変更データ管理用端末ＴＡからの権限情報取得要請に応じて実行開始されるもので、要求情報の種類および対象ファイル名、ユーザ名を受信すると（ステップＢ１）、要求された情報は権限種かを判別するが（ステップＢ２）、いま、権限種の種得要請が要求されたので、受信した対象ファイル名、ユーザ名に基づいて権限情報ＡＨＹを検索し、該当する権限種を取得する（ステップＢ３）。そして、取得した権限種を要求元の変更データ管理用端末ＴＡへ送信する（ステップＢ６）。
【００１１】
ここで、変更データ管理用端末ＴＡ側において、権限情報管理用サーバＡＭＳからの権限種を受信すると、その種類を判別し（ステップＡ４）、「監視条件付き書込可」でなければ、ステップＡ５に進み、権限種は「書込不可」かを調べ、「書込不可」であれば、データベースへの更新指示を無効とするためにこのフローから抜け、ノンファンクションとなるが、「書込み可」であれば、ステップＡ６に進み、更新データの入力を受け付け可能とすると共に、入力された更新データを自己の一時ファイルＴＰＦへプールしたのち（ステップＡ７）、ＤＢ管理用サーバＤＢＳに対して更新要求を行い、一時ファイルＴＰＦ内の更新データをＤＢ管理用サーバＤＢＳへ送信する（ステップＡ１８）。
【００１２】
一方、権限種が「監視条件付き書込可」であれば、ステップＡ８に進み、更新データの入力を受け付け可能とすると共に、入力された更新データを自己の一時ファイルＴＰＦへプールして記憶保持しておく（ステップＡ９）。そして、ステップＡ１で指定された対象ファイル名およびユーザ名を権限情報管理用サーバＡＭＳへ送信し、承認を受ける監視者の使用端末を特定するためのターミナルNoの取得要請を行い（ステップＡ１０）、応答待ちとなる（ステップＡ１１）。ここで、権限情報管理用サーバＡＭＳは図５のフローチャートにしたがった動作を再開するが、この場合、要求情報の種類は権限種ではなく、監視者情報であるからそのことがステップＢ４で検出される。この場合、受信した対象ファイル名、ユーザ名に基づいて権限情報ＡＨＹをアクセスし、それに該当する各監視ユーザ名を読み出すと共に、この監視ユーザ名に基づいて監視者情報ＯＢＶをアクセスし、該当する通信先ホスト名（ターミナルNo）を取得する（ステップＢ５）。そして、取得した監視者情報を要求元の変更データ管理用端末ＴＡへ送信する（ステップＢ６）。
【００１３】
ここで、変更データ管理用端末ＴＡ側において監視者情報を受け取ると、それに応じて承認処理用端末ＴＢを選択して回線接続し（ステップＡ１２）、その承認処理用端末ＴＢに対して一時ファイルＴＰＦ内の更新データを送信すると共に、データ更新の承認要請を通知する（ステップＡ１３）。いま、監視者が２人以上であれば、その監視者を１人ずつ指定しながら全ての監視者に対して承認要請を通知し終るまで上述の動作を繰り返す（ステップＡ１２〜Ａ１４）。ここで、承認処理用端末ＴＢ側においてはデータ更新の承認要請を受けると、図６のフローチャートにしたがった動作を実行する。
【００１４】
すなわち、承認処理用端末ＴＢは承認要請を受信すると、その要請が有った旨のメッセージを画面上のメッセージ領域に表示する（ステップＣ１）。いま、そのユーザが表示メッセージを確認し、その詳細画面の表示を指示すると、承認要請のあった更新データが詳細表示される（ステップＣ２）。図８（Ａ）はこの場合における更新データの詳細画面を示し、どのファイルをどのように更新するかの一覧が表示される。この例では対象ファイル名は「購入物品台帳」であり、その更新内容の確認を促すために、更新レコードの内容が一覧表示されるが、現在日付や誰れからの要請かも付加される。この詳細画面と共に、画面上には図８（Ｂ）に示すような承認決定ウインドウも表示され、「ＹＥＳ」、「ＮＯ」ボタンのいずれかを操作することによって承認可否を選択指定すると（ステップＣ３）、その決定内容は要請元の変更データ管理用端末ＴＡに対して送信される（ステップＣ４）。
【００１５】
このようにして承認処理用端末ＴＢから承認可否の決定内容を受けた変更データ管理用端末ＴＡ側においては、その決定内容を受信する毎に（ステップＡ１５）、承認ＯＫか否かを判別すると共に（ステップＡ１６）、全ての監視者から承認ＯＫを受け取るまで待機する（ステップＡ１５〜Ａ１７）。ここで、１人でも承認不可の決定が下された場合には、データ更新の指示を無効とするためにこのフローから抜けるが、全ての管理者から承認可の決定を受けた場合には、それを条件に監視条件が解除される。この場合、変更データ管理用端末ＴＡは一時ファイルＴＰＦ内の更新データを読み出してＤＢ管理用サーバＤＢＳへ送信し、更新要求を行う（ステップＡ１８）。すると、ＤＢ管理用サーバＤＢＳはデータ更新要求に応じて図７のフローチャートを実行開始し、更新データを受信し（ステップＤ１）、この更新データに基づいて該当するデータベースＤＢを１レコードずつ更新する処理が行われる（ステップＤ２）。
【００１６】
以上のようにこの第１実施形態においては、データ更新のアクセス権限として「監視条件付き書込可」を設定するようにしたから、監視者の承認を受けた場合に限って許可されるデータ更新を実現することが可能となる。この場合、監視者の承認を受ける前に、更新データを入力することができ、入力された更新データは一時ファイルＴＰＦに記憶保持される。また、データ更新の承認要請をその監視者側の端末へ通知するようにしたから、承認要請の自動化を実現することが可能となる。また、アクセス権限としての「監視条件付き書込可」はファイル別にユーザ毎に設定することができるので、同じユーザであってもファイルの種類に応じて監視を条件とするか否かの設定が可能となる。また監視者側の端末ではどのファイルがどのように更新するのかの詳細画面が表示されるので、承認可否の決定をその場で行うことができる。
【００１７】
（第２実施形態）
以下、図９、図１０を参照してこの発明の第２実施形態を説明する。なお、上述した第１実施形態においては、監視者の承認を受けた際にデータベースＤＢを更新するようにしたが、この第２実施形態は承認を受ける前にデータベースＤＢを更新しておき、その後の承認可否に応じてデータ更新の有効／無効を決定するようにしたものであり、この第２実施形態において変更データ管理用端末ＴＡには、一時ファイルＴＰＦは存在しない。
図９はデータ更新が指示された際の変更データ管理用端末ＴＡの動作を示したフローチャートであり、図４と基本的に同様であるため、以下、その相違点を中心に説明するものとする。先ず、変更データ管理用端末ＴＡ側において更新対象ファイル名およびユーザ名に対応する権限種の取得要請を行い、それに応答して送信されて来た権限種を判別し（ステップＥ１〜Ｅ５）、「書込可」であれば、更新データを入力し、それを基にＤＢ管理用サーバＤＢＳに対してデータ更新を要求する（ステップＥ６、Ｅ７）。
【００１８】
一方、「監視条件付き書込可」の場合であれば、通常の「書込可」の場合と同様に更新データを入力し、それを基にＤＢ管理用サーバＤＢＳに対してデータ更新を要求するが、この場合のＤＢ管理用サーバＤＢＳに対して暫定的な更新要求を行う（ステップＥ８、Ｅ９）。
ここで、ＤＢ管理用サーバＤＢＳ側においては図１０に示したフローチャートにしたがった処理を実行する。すなわちデータベースＤＢに対する更新要求が、通常の「書込可」の場合ではなく「監視条件付き書込可」に伴う暫定的な更新要求である場合には（ステップＦ１）、その更新データを受信すると（ステップＦ２）、データベースＤＢ内に暫定更新管理情報ＴＥＭを作成すると共に、更新データに基づいて該当するデータベースＤＢを更新する（ステップＦ３）。ここで、暫定更新管理情報ＴＥＭは更新データを１レコード毎に記憶保持すると共に、更新データ毎に暫定フラグを記憶するもので、データベースＤＢへの更新が暫定的なものであることを示すために暫定フラグをＯＮさせておく。なお、暫定的な更新であっても、通常の「書込可」の場合と同様にデータベースＤＢの内容は更新データに基づいて書き替えられる。
【００１９】
次に、変更データ管理用端末ＴＡ側においては、監視者情報の取得要請を行い、全ての監視者側端末へデータ更新内容を送信すると共に、承認要請を通知する（ステップＥ１０〜Ｅ１４）。そして、全ての監視者から承認可否の決定通知が有るまで待機する（ステップＥ１５〜Ｅ１７）。ここで、全ての監視者から承認可の決定を受けた場合には、ＤＢ管理用サーバＤＢＳに対してデータの暫定更新内容の確定を要求する（ステップＥ１８）。すると、ＤＢ管理用サーバＤＢＳ側においては、暫定更新管理情報ＴＥＭを参照し、暫定フラグが立っている更新データが存在するかを調べ（ステップＦ４）、有れば、その暫定フラグおよび更新データを消去して暫定状態を解除する（ステップＦ５）。このような解除処理は暫定更新管理情報ＴＥＭ内の更新データに対して１レコード毎に繰り返される。一方、いずれかの監視者から承認不可の決定を受けた場合には、ＤＢ管理用サーバＤＢＳに対して暫定更新の棄却要求を行う（ステップＥ１８）。すると、ＤＢ管理用サーバＤＢＳ側においては、暫定更新管理情報ＴＥＭを参照し、暫定フラグが立っている更新データに基づいてデータベースＤＢを更新前の元の状態に戻す逆更新処理を行う（ステップＦ６）。これによって暫定更新された内容は棄却されて元の状態に戻される。
【００２０】
以上のようにこの第２実施形態においては、データ更新の指示内容にしたがって該当するデータを暫定的に更新すると共に、その更新指示内容が監視者の承認を必要とするデータに対して行われた場合に、その監視者側の端末装置に対してデータ更新の承認要請を通知し、この通知を受けた端末側において承認可否が決定された場合に、その決定内容が承認可であれば、暫定更新されたデータを確定し、承認不可であれば更新データを更新前の元の状態に戻すようにしたから、承認を受けずにデータを更新したとしてもその後の承認可否に応じてデータ更新の有効／無効を制御できると共に、承認要請の自動化を実現することが可能となる。その他、この第２実施形態においても上述した第１実施形態と同様の効果を有する。
【００２１】
なお、上述した各実施形態においては監視者側で承認可否を決定する場合、「ＹＥＳ」、「ＮＯ」ボタンを押下するようにしたが、署名という意味でパスワードを入力するようにすれば、承認決定の安全性を確保することができる。また、承認要請を通知してから承認決定が下されるまでの承認期限を設定しておき、一定期間以上承認決定されなかった場合に、承認要請通知を再送するようにしてもよい。更に、複数の監視者に対して承認を受ける場合において、承認要請通知を全監視者に対して行うが、その際、監視者を１人ずつ指定しながら要請通知を発行する代わりに全ての監視者に対して同報的に要請通知を行うようにしてもよい。更に、複数の監視者のうちいずれかの監視者からの承認決定が得られなかった場合に、その決定保留者だけに要請通知を再送するほか、決定済みである他の監視者の承認決定の内容を併わせて通知するようにすれば、決定保留者は他の監視者の承認可否を参考することができる。また、上述した各実施形態においては、オペレータによるデータ更新指示が行われる毎に、承認要請をリアルタイムで通知するようにしたが、バッチファイルの内容にしたがってデータを定期的に一括更新するバッチ処理毎に、承認要請を行うようにしてもよい。
【００２２】
【発明の効果】
第１の発明によれば、管理者の承認を受けたことを条件としてデータ更新を許可する監視条件付きのデータ更新を実現することができると共に、承認要請の自動化を実現することができる。
第２の発明によれば、管理者の承認を条件とするデータに対してその承認を受けずにデータを更新したとしても、その後の承認可否に応じてデータ更新の有効／無効を制御できると共に、承認要請の自動化を実現することができる。
【図面の簡単な説明】
【図１】データ処理システムを示したシステム構成図。
【図２】（Ａ）は権限情報管理用サーバＡＭＳ側に設定されている権限情報ＡＨＹのデータ構造を説明するための図で、（Ｂ）はその具体的な設定内容を示した図。
【図３】端末装置ＴＭＬの全体構成を示したブロック図、
【図４】変更データ管理用端末ＴＡにおいてデータベースの更新指示にしたがって実行開始されるフローチャート。
【図５】権限情報管理用サーバＡＭＳにおいて権限情報取得要請に応じて実行開始されるフローチャート。
【図６】承認処理用端末ＴＢにおいてデータ更新の承認要請に応じて実行開始されるフローチャート。
【図７】データベースＤＢ側においてデータ更新要求に応じて実行開始されるフローチャート。
【図８】（Ａ）、（Ｂ）は承認処理用端末ＴＢ側における承認画面を例示したもので、（Ａ）は詳細画面、（Ｂ）は承認決定ウインドウを示した図。
【図９】第２実施形態を説明するための図で、変更データ管理用端末ＴＡにおいてデータベースの更新指示にしたがって実行開始されるフローチャート。
【図１０】第２実施形態を説明するための図で、（Ａ）はＤＢ管理用サーバＤＢＳにおいてデータ更新要求や確定／棄却要求に応じて実行開始されるフローチャート、（Ｂ）はＤＢ管理用サーバＤＢＳ側の暫定更新管理情報ＴＥＭを示した図。
【符号の説明】
１ ＣＰＵ
２ 記憶装置
３ 記憶媒体
４ ＲＡＭ
５ 入力装置
６ 表示装置
７ 通信装置
ＴＡ 変更データ管理用端末
ＴＢ 承認処理用端末
ＡＭＳ 権限情報管理用サーバ
ＤＢＳ ＤＢ管理用サーバ
ＴＰＦ 一時ファイル
ＡＨＹ 権限情報
ＤＢ データベース
ＴＥＭ 暫定更新管理情報
ＯＢＶ 監視者情報
Claims (4)
- 少なくとも複数台の端末装置がネットワーク上に接続されて成るコンピュータシステムにおいて、
データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段と、
前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段と、
所定管理者の承認を必要とするデータに対して更新指示が行われた場合に、前記決定手段によりデータ更新可が決定されていることを条件に、その更新指示内容を一時記憶手段に書き込んで記憶保持しておくと共に、データの更新指定の承認要請を通知する第１の更新制御手段と、
前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記一時記憶手段内の更新指示内容に基づいてデータを更新する第２の更新制御手段と、
を具備したことを特徴とするデータ処理システム。 - 少なくとも複数台の端末装置がネットワーク上に接続されて成るコンピュータシステムにおいて、
データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段と、
前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段と、
前記決定手段によりデータ更新可が決定されていることを条件に、データ更新の指示内容にしたがって該当するデータを暫定的に更新すると共に、前記更新指示が所定管理者の承認を必要とするデータに対して行われた場合に、データの更新指定の承認要請を通知する第１の更新制御手段と、
前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記更新されたデータを確定し、承認不可であれば、前記更新されたデータを更新前の元のデータに戻す第２の更新制御手段と、
を具備したことを特徴とするデータ処理システム。 - コンピュータを、
データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段、
前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否とその承認先の端末を決定する決定手段、
所定管理者の承認を必要とするデータに対して更新指示が行われた場合に、前記決定手段によりデータ更新可が決定されていることを条件に、その更新指示内容を一時記憶手段に書き込んで記憶保持しておくと共に、データの更新指定の承認要請を通知する第１の更新制御手段、
前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記一時記憶手段内の更新指示内容に基づいてデータを更新する第２の更新制御手段、
として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。 - コンピュータを、
データ種別および担当者別にデータ更新を制限する権限定義情報及び承認先の端末情報を記憶する記憶手段、
前記記憶手段内の権限定義情報及び端末情報を参照することによりデータ更新の可否と その承認先の端末を決定する決定手段、
前記決定手段によりデータ更新可が決定されていることを条件に、データ更新の指示内容にしたがって該当するデータを暫定的に更新すると共に、前記更新指示が所定管理者の承認を必要とするデータに対して行われた場合に、データの更新指定の承認要請を通知する第１の更新制御手段、
前記承認要請に応じて前記決定手段で決定された承認先の端末において承認可の入力が行われたことを条件に、前記更新されたデータを確定し、承認不可であれば、前記更新されたデータを更新前の元のデータに戻す第２の更新制御手段、
として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06427199A JP3921865B2 (ja) | 1999-03-11 | 1999-03-11 | データ処理システムおよびそのプログラム記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06427199A JP3921865B2 (ja) | 1999-03-11 | 1999-03-11 | データ処理システムおよびそのプログラム記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000259477A JP2000259477A (ja) | 2000-09-22 |
| JP3921865B2 true JP3921865B2 (ja) | 2007-05-30 |
Family
ID=13253392
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP06427199A Expired - Fee Related JP3921865B2 (ja) | 1999-03-11 | 1999-03-11 | データ処理システムおよびそのプログラム記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3921865B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101661540A (zh) * | 2008-08-29 | 2010-03-03 | 富士施乐株式会社 | 信息管理方法和信息管理系统 |
Families Citing this family (50)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7197534B2 (en) | 1998-09-01 | 2007-03-27 | Big Fix, Inc. | Method and apparatus for inspecting the properties of a computer |
| US8914507B2 (en) | 1998-09-01 | 2014-12-16 | International Business Machines Corporation | Advice provided for offering highly targeted advice without compromising individual privacy |
| US7607572B2 (en) | 1999-03-19 | 2009-10-27 | Bigfix, Inc. | Formalizing, diffusing, and enforcing policy advisories and monitoring policy compliance in the management of networks |
| US9231827B2 (en) | 2001-11-09 | 2016-01-05 | International Business Machines Corporation | Formalizing, diffusing and enforcing policy advisories and monitoring policy compliance in the management of networks |
| JP4280110B2 (ja) * | 2003-05-16 | 2009-06-17 | 日本電信電話株式会社 | 属性承認装置 |
| JP2007011897A (ja) * | 2005-07-01 | 2007-01-18 | Keysoft:Kk | データ管理システム |
| JP4665755B2 (ja) * | 2005-12-23 | 2011-04-06 | 三菱電機株式会社 | 列車運行管理システム |
| KR102559017B1 (ko) | 2007-09-24 | 2023-07-25 | 애플 인크. | 전자 장치 내의 내장형 인증 시스템들 |
| JP4873424B2 (ja) * | 2007-11-21 | 2012-02-08 | キヤノンＩｔソリューションズ株式会社 | 情報処理システム、情報処理装置、その制御方法及びプログラム |
| US8600120B2 (en) | 2008-01-03 | 2013-12-03 | Apple Inc. | Personal computing device control using face detection and recognition |
| JP5292650B2 (ja) * | 2008-08-27 | 2013-09-18 | 株式会社日本総合研究所 | データ管理システムおよびデータ削除方法 |
| US11165963B2 (en) | 2011-06-05 | 2021-11-02 | Apple Inc. | Device, method, and graphical user interface for accessing an application in a locked device |
| US8769624B2 (en) * | 2011-09-29 | 2014-07-01 | Apple Inc. | Access control utilizing indirect authentication |
| US9002322B2 (en) | 2011-09-29 | 2015-04-07 | Apple Inc. | Authentication with secondary approver |
| JP5970919B2 (ja) * | 2012-03-30 | 2016-08-17 | 富士通株式会社 | 臨床試験の情報の登録制御プログラム、臨床試験の情報の登録制御方法及び臨床試験の情報の登録制御サーバ |
| WO2014143776A2 (en) | 2013-03-15 | 2014-09-18 | Bodhi Technology Ventures Llc | Providing remote interactions with host device using a wireless device |
| US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| EP3076776B1 (en) * | 2013-11-29 | 2019-10-23 | FUJI Corporation | Data update method for circuit substrate work system and circuit substrate work system |
| US9324067B2 (en) | 2014-05-29 | 2016-04-26 | Apple Inc. | User interface for payments |
| US9967401B2 (en) | 2014-05-30 | 2018-05-08 | Apple Inc. | User interface for phone call routing among devices |
| EP4365725B1 (en) | 2014-05-30 | 2025-06-18 | Apple Inc. | Continuity |
| US10339293B2 (en) | 2014-08-15 | 2019-07-02 | Apple Inc. | Authenticated device used to unlock another device |
| JP6621682B2 (ja) * | 2016-02-18 | 2019-12-18 | 能美防災株式会社 | 防災支援システム |
| DK179186B1 (en) | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
| CN114693289A (zh) | 2016-06-11 | 2022-07-01 | 苹果公司 | 用于交易的用户界面 |
| US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
| DK201670622A1 (en) | 2016-06-12 | 2018-02-12 | Apple Inc | User interfaces for transactions |
| US20180068313A1 (en) | 2016-09-06 | 2018-03-08 | Apple Inc. | User interfaces for stored-value accounts |
| DK179471B1 (en) | 2016-09-23 | 2018-11-26 | Apple Inc. | IMAGE DATA FOR ENHANCED USER INTERACTIONS |
| US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
| US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
| US20220279063A1 (en) | 2017-05-16 | 2022-09-01 | Apple Inc. | Methods and interfaces for home media control |
| CN111343060B (zh) | 2017-05-16 | 2022-02-11 | 苹果公司 | 用于家庭媒体控制的方法和界面 |
| KR102185854B1 (ko) | 2017-09-09 | 2020-12-02 | 애플 인크. | 생체측정 인증의 구현 |
| CN112507307B (zh) | 2017-09-09 | 2025-04-08 | 苹果公司 | 生物识别认证的实现 |
| US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
| US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
| US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
| US10996917B2 (en) | 2019-05-31 | 2021-05-04 | Apple Inc. | User interfaces for audio media control |
| KR20240049648A (ko) | 2019-05-31 | 2024-04-16 | 애플 인크. | 오디오 미디어 제어를 위한 사용자 인터페이스 |
| US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
| US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
| EP4264460B1 (en) | 2021-01-25 | 2025-12-24 | Apple Inc. | Implementation of biometric authentication |
| US12210603B2 (en) | 2021-03-04 | 2025-01-28 | Apple Inc. | User interface for enrolling a biometric feature |
| US12216754B2 (en) | 2021-05-10 | 2025-02-04 | Apple Inc. | User interfaces for authenticating to perform secure operations |
| US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
| WO2022260876A1 (en) | 2021-06-06 | 2022-12-15 | Apple Inc. | User interfaces for audio routing |
| US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
| JP7180017B1 (ja) * | 2022-01-28 | 2022-11-29 | 株式会社オービック | 更新制御装置、更新制御方法、及び、更新制御プログラム |
-
1999
- 1999-03-11 JP JP06427199A patent/JP3921865B2/ja not_active Expired - Fee Related
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101661540A (zh) * | 2008-08-29 | 2010-03-03 | 富士施乐株式会社 | 信息管理方法和信息管理系统 |
| JP2010055520A (ja) * | 2008-08-29 | 2010-03-11 | Fuji Xerox Co Ltd | 情報管理プログラム及び情報管理システム |
| US8281365B2 (en) | 2008-08-29 | 2012-10-02 | Fuji Xerox Co., Ltd. | Information management method, information management system, computer-readable medium and computer data signal |
| CN101661540B (zh) * | 2008-08-29 | 2014-08-27 | 富士施乐株式会社 | 信息管理方法和信息管理系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000259477A (ja) | 2000-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3921865B2 (ja) | データ処理システムおよびそのプログラム記録媒体 | |
| US20230396661A1 (en) | Systems and methods for sharing content externally from a group-based communication platform | |
| US20080256458A1 (en) | Data Access Control System for Shared Directories and Other Resources | |
| US20110231364A1 (en) | Id management method, id management system, and computer-readable recording medium | |
| JP2008186478A (ja) | コンピュータが実行可能なワークフロー制御システム | |
| KR101932600B1 (ko) | 공유 문서 편집 방법 | |
| JP4587164B2 (ja) | 印刷システム、印刷制御方法、並びにプログラム | |
| US20070079357A1 (en) | System and/or method for role-based authorization | |
| CN113761552A (zh) | 一种访问控制方法、装置、系统、服务器和存储介质 | |
| US20180349269A1 (en) | Event triggered data retention | |
| JP2007156678A (ja) | ワークフローシステムおよび滞留電子文書処理方法 | |
| JP4531529B2 (ja) | 情報処理装置管理システム及び情報処理装置管理方法およびプログラムおよび記録媒体 | |
| JP4850159B2 (ja) | 外部装置管理システム | |
| JP4266897B2 (ja) | ライセンス管理システム、ライセンス管理方法、ライセンス管理サーバ、及びライセンス管理ソフトウェア | |
| JP5637501B2 (ja) | 文書管理システム、及び文書管理方法 | |
| CN116756711A (zh) | 数据处理方法、装置、设备以及介质 | |
| JP3904408B2 (ja) | 情報管理システム、情報管理方法および情報管理プログラム | |
| JP4769241B2 (ja) | アクセス権限制御システム | |
| JP2003256064A (ja) | ライセンス管理方法，ライセンス管理サーバ，ライセンス取得クライアント、ライセンス管理プログラム及び記録媒体 | |
| JP2007299295A (ja) | 顧客情報登録システム、アプリケーションサーバ及び端末装置 | |
| JP4262655B2 (ja) | ワークフローシステム及びワークフローシステムの管理方法 | |
| CN108960612B (zh) | 业务处理方法与业务处理微服务 | |
| JP2020154868A (ja) | 情報処理システムおよびプログラム | |
| JP5446676B2 (ja) | 情報管理サーバ、情報管理システム、ならびに、プログラム | |
| JP2009157445A (ja) | データベース開発管理システム及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060203 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060217 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060228 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060414 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060427 |
|
| 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: 20070130 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070212 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3921865 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: 20110302 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120302 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130302 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130302 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140302 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |