JP5486361B2

JP5486361B2 - 情報処理装置及びプログラム

Info

Publication number: JP5486361B2
Application number: JP2010061770A
Authority: JP
Inventors: 康博木幡; 光義山足; 崇小宮
Original assignee: Mitsubishi Electric Corp; Mitsubishi Electric Information Technology Corp
Current assignee: Mitsubishi Electric Corp; Mitsubishi Electric Information Technology Corp
Priority date: 2010-03-18
Filing date: 2010-03-18
Publication date: 2014-05-07
Anticipated expiration: 2030-03-18
Also published as: JP2011197843A

Description

本発明は、例えば、オフィスビル等における入退室管理に関し、特に、入退室管理のために利用者に設定されている通行権限を管理する技術に関する。

オフィスビルやマンション、病院などのセキュリティ向上のため、エントランス、フロア、居住室などの空間の出入り口にゲート装置を備え、ゲート装置の通行の際にゲート装置付近に設置された読取装置に利用者の認証情報（利用者が付帯するＩＣカードのカード番号、利用者の指紋等）を読み取らせて入退室管理システムに認証情報の照合を行わせ、認証情報が入退室管理システムに登録されている登録情報と一致した利用者のみ入室を許す仕組みがある。

このような入退室管理システムでは、認証情報と登録情報の照合以外に、当該利用者がゲート装置を通行できる権限があるかどうか、つまり、ゲート装置を通行して内部の空間に入場できるという通行権限が当該利用者に付与されているかどうかについても判定を行っている場合がある。
たとえば、ゲート装置Ｘを通行してエリアＹに入場することができる通行権限が利用者Ａに付与されている場合は、利用者Ａは認証情報と登録情報が一致すればゲート装置Ｘを通行してエリアＹに入場することができる。一方、このような通行権限が利用者Ｂには与えられていない場合は、利用者Ｂは認証情報と登録情報との照合の結果いかんを問わず、ゲート装置Ｘの通行が許可されない。

通行権限の設定の仕方として、組織ごとに通行権限を設定する方法がある。例えば、企業において、経理部に所属する者は一律に、例えば、ゲート装置Ｘを通行してエリアＹに入場できるといった形である。
しかしながら、組織の形態及び個人の活動形態によっては、組織ごとの通行権限では不十分であり、個人の属性に基づき、個人単位で通行権限を設定しなければならない場合がある。
例えば、サーバ室等では、組織とは関係なく、サーバの管理者に対して、通行を許可する必要があり、個人対応で特別な通行権限を与える必要がある。

このような特別な通行権限は、通常は、申請に基づき個人に割り当てられる。
一方で、特別な通行権限が与えられた個人が例えば人事異動になった結果、当該個人に特別な通行権限を与えておく必要がなくなる場合がある。
このような場合に、個人からの削除申請により、特別な通行権限を解除することも考えられるが、削除申請が行われずに、当該個人に特別な通行権限が付与されたままになる場合もある。
このように、不要な通行権限が付与されたままの状態は、セキュリティ上好ましくない。
また、手作業により、維持が不要な通行権限を抽出して削除理を行うのは、処理負担が大きい。
これに対し、通行権限の設定時に有効期限を設定し、有効期限の到来とともに個人対応の通行権限が消滅するという方式も考えられる。
しかし、この方式においても、有効期限後にも権限が必要な場合は延長申請を行うことになるが、延長申請に対する延長手続きが必要になり、管理負荷が高くなるという課題がある。

この点に関し、例えば、特許文献１では、扉通行の際に行われる認証の履歴を利用し、認証回数（利用回数）が少ない扉や、最終利用日時が所定の期間よりも前である扉については、自動的に通行権限を削除する方式が開示されている。

特開２００８−１５８７４６号公報

上記のように、特許文献１では、扉の利用回数や最終利用日時に基づき、通行権限を削除する。
しかしながら、特許文献１によれば、利用頻度は高くないが、通行が必要な扉に対する通行権限は削除されてしまうことになる。
このため、利用頻度が高くない扉に対する通行権限が削除された個人が、通行権限の再申請を行うことになり、再申請を処理するための管理負荷が発生するという課題がある。

本発明は、このような課題を解決することを主な目的としており、個人対応で設定された通行権限のうち不要になった通行権限のみを、管理負荷を発生させずに、確実に削除することを主な目的とする。

本発明に係る情報処理装置は、
ゲート装置を通行する権限を持つ通行権限者が示される通行権限者情報を保持し、前記通行権限者情報に基づき入退室管理を行う入退室管理システム
に接続されている情報処理装置であって、
通行権限者情報を削除するための削除条件を前記通行権限者の属性に対応付けて定義する削除条件情報を記憶する削除条件情報記憶部と、
前記通行権限者の属性が変化した場合に、前記通行権限者の変化後の属性を検出する属性変化検出部と、
前記属性変化検出部により検出された前記通行権限者の変化後の属性が前記削除条件情報の削除条件に合致するか否かを判断し、前記通行権限者の変化後の属性が前記削除条件に合致する場合に、前記入退室管理システムに前記通行権限者の通行権限者情報の削除を指示し、前記ゲート装置に対する前記通行権限者の通行権限を失効させる削除判定部とを有することを特徴とする。

本発明によれば、通行権限者情報を削除するための削除条件を通行権限者の属性に対応付けて事前に定義し、通行権限者の属性が変化した場合に、通行権限者の変化後の属性が削除条件に合致するか否かを判断し、通行権限者の変化後の属性が削除条件に合致する場合に、入退室管理システムに通行権限者の通行権限者情報の削除を指示し、通行権限者の通行権限を失効させるため、個人対応で設定された通行権限のうち不要になった通行権限のみを、登録時の削除条件設定以外の管理負荷を発生させずに、確実に削除することができる。

実施の形態１に係るシステム構成例を示す図。実施の形態１に係る個人割り付けテーブルの例を示す図。実施の形態１に係る権限削除条件テーブルの例を示す図。実施の形態１に係る権限削除条件テーブルの例を示す図。実施の形態１に係る登録処理の動作例を示すフローチャート図。実施の形態１に係る削除処理の動作例を示すフローチャート図。実施の形態１に係るＩＤ管理システムのハードウェア構成例を示す図。

実施の形態１．
図１は、本実施の形態に係るシステム構成例を示す。
図１において、ＩＤ管理システム１００は、オフィスビル、工場、マンション、病院、スポーツクラブ等の施設を利用する利用者の通行権限を管理する装置である。
ＩＤ管理システム１００は情報処理装置の例である。
以下では、オフィスビルを例として説明する。
そして、当該オフィスビルで就業する従業員に対して、原則として、組織単位で通行権限を設定するが、特定の従業員に対しては個人対応で特別な通行権限を設定するものとする。
以下では、特別な通行権限が認められた特定の従業員に対する処理を中心に説明を進める。

ＩＤ管理システム１００は、ＩＤ管理システムＤＢ（Ｄａｔａｂａｓｅ）１５０と接続されている。
また、ＩＤ管理システム１００は、ディスプレイ装置２００、キーボード２１０、カードリーダ２２０に接続されている。
ＩＤ管理システムＤＢ１５０は、特定の従業員に設定されている通行権限を示す個人割り付け権限テーブルを格納している。
個人割り付け権限テーブルは、例えば、図２に示す情報である。
個人割り付け権限テーブルは、特別な通行権限が認められている従業員（以下、通行権限者ともいう）について、当該従業員の個人番号（従業員番号等）と当該従業員に認められている通行権限（通行が認められる扉の扉ＩＤ）が対応付けられている。
個人割り付け権限テーブルは、通行権限者情報の例である。

なお、本実施の形態では、従業員はＩＣカード（以下、単にカードともいう）を携行しており、扉３８０（ゲート装置）を通行する際に、携行しているＩＣカードをカードリーダ３７０にかざして入退室管理システム３３０による認証を受ける。
ＩＣカードには、個人番号（従業員番号等）が記憶されており、カードリーダ３７０は、ＩＣカードから個人番号を読み出し、入退室管理システム３３０に個人番号を転送する。
入退室管理システム３３０に接続されている入退室管理システムＤＢ３４０には、図２と同様の個人割り付け権限テーブルが格納されている。
入退室管理システム３３０は、カードリーダ３７０から入力した個人番号に基づき、入退室管理システムＤＢ３４０の個人割り付け権限テーブルを検索し、扉３８０を通行しようとしている従業員が、扉３８０の通行権限があるかを検査し、通行権限がある場合は、扉制御装置３５０に指示を送り、電気錠３６０を開錠させて、当該従業員の扉３８０の通行を許可する。

人事ＤＢシステム３１０は、従業員ごとに、個人番号、氏名、役職、所属している組織、就業している事業所（本社、支社等）を記憶している。
また、人事ＤＢシステム３１０は、例えば、従業員が、所属組織からは独立したタスクフォースやプロジェクトに属しているといった情報を管理していてもよい。
また、人事ＤＢシステム３１０は、図２の個人割り付け権限テーブルに個人番号が記されている通行権限者の所属組織が変わった場合に、異動先の組織の情報をＩＤ管理システム１００に通知する。
更に、人事ＤＢシステム３１０は、図２の個人割り付け権限テーブルに個人番号が記されている通行権限者が他の事業所に移った場合や、当該従業員がタスクフォースやプロジェクトから外れた場合やタスクフォースやプロジェクトが終了した場合等にも、ＩＤ管理システム１００に異動先の事業所の情報やタスクフォースやプロジェクトを外れた旨やタスクフォースやプロジェクトが終了した旨等を通知する。

次に、ＩＤ管理システム１００の内部構成例について説明する。
ＩＤ管理システム１００において、制御部１０１は、通信部１０２、入出力部１０３、通行権限決定部１０４、権限削除条件テーブル記憶部１０５、権限削除監視部１０６、ＩＤ管理システムＤＢ１５０の各要素の動作及び要素間のデータのやり取りを制御する。

通信部１０２は、外部装置との間で情報の送受信を行う。
より具体的には、通信部１０２は、図２に示す個人割り付け権限テーブルが生成された場合に、生成された個人割り付け権限テーブルを入退室管理システム３３０に送信する。
入退室管理システム３３０は、生成された個人割り付け権限テーブルを入退室管理システムＤＢ３４０に格納する。
また、通信部１０２は、通行権限者の属性（所属組織、事業所、タスクフォースやプロジェクト等）が変更になった場合に、通行権限者の属性の変化を通知する属性変化通知情報を人事ＤＢシステム３１０から受信する。
また、通行権限者の属性（所属組織、事業所、タスクフォースやプロジェクト等）が変更になり、変更後の属性が後述する削除条件に合致するようになった場合に、変更後の属性が削除条件に合致することになった通行権限者の通行権限の削除を指示する削除指示を入退室管理システム３３０に送信する。
削除指示を受信した入退室管理システム３３０は、入退室管理システムＤＢ３４０内の該当する通行権限を個人割り付け権限テーブルから削除する。

入出力部１０３は、キーボード２１０又はカードリーダ２２０から情報を入力し、また、ディスプレイ装置２００に情報を出力する。
入出力部１０３は、例えば、個人割り付け権限テーブルの生成のために、個人番号や扉ＩＤ等をキーボード２１０から入力する。
また、入出力部１０３は、例えば、後述する権限削除条件テーブルの生成のために、個人番号や削除条件等をキーボード２１０から入力する。
また、個人割り付け権限テーブル及び権限削除条件テーブルの生成の際に、必要な情報をディスプレイ装置２００に出力する。

通行権限決定部１０４は、入出力部１０３により入力されたデータから、個人割り付け権限テーブル及び権限削除条件テーブルを生成する。
なお、通行権限決定部１０４は、生成した個人割り付け権限テーブルをＩＤ管理システムＤＢ１５０に格納し、また、通信部１０２を介して入退室管理システム３３０に送信し、入退室管理システムＤＢ３４０に格納させる。
また、通行権限決定部１０４は、生成した権限削除条件テーブルを後述の権限削除条件テーブル記憶部１０５に格納する。

権限削除条件テーブル記憶部１０５は、権限削除条件テーブルを記憶する。
権限削除条件テーブルは、個人割り付け権限テーブル内の通行権限者のレコード（通行権限）を削除するための削除条件を通行権限者の属性に対応付けて定義する情報であり、削除条件情報の例である。
権限削除条件テーブルは、例えば、図３及び図４に示す情報である。
図３及び図４に示すように、権限削除条件テーブルは、通行権限者の個人番号と削除条件を対応付けている。
削除条件は、通行権限者の属性に対応付けられている。
より具体的には、削除条件には、通行権限を維持する必要がなくなる属性の変化が示される。
図３の例では、通行権限者（個人番号：ＡＢＣ１２３４）の所属組織が社長室以外となった場合は、当該通行権限者に認められていた扉１、３、５の全ての通行権限が失効する。
なお、図３の例では、通行権限者の所属組織が特定の１つの組織（社長室）でなくなった場合に通行権限が失効するが、通行権限者の所属組織が複数の組織のいずれでもなくなった場合に通行権限が失効するようにしてもよい。
例えば、通行権限者の所属組織が、社長室、人事部、総務部のいずれでもなくなった場合に、扉１、３、５の通行権限が失効するようにしてもよい。
また、図４の例のように、通行権限ごと（扉ごと）に、異なる削除条件を設けるようにしてもよい。
図４の例では、扉１の通行権限は、通行権限者の所属組織が社長室以外となった場合に失効し、扉３は通行権限者が戦略プロジェクトから外れた場合に失効し、扉５の通行権限は通行権限者の事業所が本社以外となった場合に失効する。
また、削除条件としては、有効期日を指定して、有効期日が切れたら削除するとか、個人の属性情報として、組織以外の役職が変更になった場合等についても、同様に設定でき、複数の削除条件を指定して、どれかの削除条件が該当した時に権限を失効する設定が可能である。
なお、権限削除条件テーブル記憶部１０５は、削除条件情報記憶部の例である。

権限削除監視部１０６は、通行権限者の属性が変化した場合に、人事ＤＢシステム３１０からの通知に基づき、通行権限者の変化後の属性を検出し、通行権限者の変化後の属性が権限削除条件テーブルの削除条件に合致するか否かを判断し、通行権限者の変化後の属性が削除条件に合致する場合に、入退室管理システム３３０に個人割り付け権限テーブル内の当該通行権限者のレコード（通行権限）の削除を指示し、通行権限のあった扉に対する通行権限を失効させる。
権限削除監視部１０６は、属性変化検出部及び削除判定部の例である。

次に、本実施の形態に係るＩＤ管理システム１００における個人割り付け権限テーブル及び権限削除条件テーブルの登録処理時の動作例を図５のフローチャートに従って説明する。

まず、ＩＤ管理システム１００のオペレータが、キーボード２１０を操作して、個人番号及び通行権限（通行が許可される扉ＩＤ）を入力し、入出力部１０３がこれらのデータを受け付け、通行権限決定部１０４が、図２の個人割り付け権限テーブルを生成する（Ｓ５０１）。
また、オペレータは、カードリーダ２２０を用いて、通行権限者に配布するカードに個人番号を記憶させる。

次に、通行権限決定部１０４が、生成した個人割り付け権限テーブルをＩＤ管理システムＤＢ１５０に登録するとともに、通信部１０２を介して、入退室管理システム３３０に送信し、入退室管理システムＤＢ３４０に登録させる（Ｓ５０２）。

また、通行権限決定部１０４は、生成した個人割り付け権限テーブルに示される個人番号（通行権限者の個人番号）を、通信部１０２を介して人事ＤＢシステム３１０に通知する。
なお、この人事ＤＢシステム３１０への個人番号の通知は、例えば、オペレータがオフラインで行ってもよい。また、個人情報とＩＤは、人事ＤＢから送信され、ＩＤ管理システム１００では、権限割り付けとカード割り付けを行うようにしても良い。
人事ＤＢシステム３１０では、通知された通行権限者の個人番号を、属性が変化した際に属性の変化を通知する個人番号（属性変化通知対象番号）として記憶する。

次に、ＩＤ管理システム１００のオペレータが、キーボード２１０を操作して、個人番号及び削除条件（通行権限を失効させる属性に関する条件と、失効対象の扉ＩＤ）を入力し、入出力部１０３がこれらのデータを受け付け、通行権限決定部１０４が、図３又は図４の権限削除条件テーブルを生成する（Ｓ５０３）。

次に、通行権限決定部１０４が、生成した権限削除条件テーブルを権限削除条件テーブル記憶部１０５に登録する（Ｓ５０４）。

次に、本実施の形態に係るＩＤ管理システム１００における個人割り付け権限テーブル及び権限削除条件テーブルの削除処理時の動作例を図６のフローチャートに従って説明する。

人事ＤＢシステム３１０では、記憶している属性変化通知対象番号に対応する従業員（通行権限者）の属性の変化を検知する。
属性の変化とは、例えば、所属組織の変更（離職を含む）、就業している事業所の変更、所定のタスクフォースやプロジェクトからの離脱、所定のタスクフォースやプロジェクトの終了、新入社員の追加や退職による削除情報等である。
人事ＤＢシステム３１０は、通行権限者の属性の変化を検知した場合には、属性の変化を通知する属性変化通知を送信する。
ＩＤ管理システム１００では、通信部１０２が属性変化通知を受信し、権限削除監視部１０６に属性変化通知を転送する（Ｓ６０１でＹＥＳ）（属性変化検出処理）。
権限削除監視部１０６は、これにより、通行権限者の属性の変化を検出する。
属性変化通知には、個人番号と、変化後の属性が示される。

権限削除監視部１０６では、ＩＤ管理システムＤＢ１５０から個人割り付け権限テーブルを読み出し、属性変化通知に示されている個人番号が個人割り付け権限テーブルにあるかを判断する（Ｓ６０２）。
属性変化通知に示されている個人番号が個人割り付け権限テーブルにない場合（ＮＯの場合）は、Ｓ６０１に戻る。また、このとき、オペレータに対して所定のエラー通知を行ってもよい。
また、属性変化通知に示されている個人番号が個人割り付け権限テーブルにある場合（ＹＥＳの場合）は、権限削除監視部１０６は、権限削除条件テーブルを権限削除条件テーブル記憶部１０５から読み出す。
そして、属性変化通知に示されている個人番号と一致する個人番号が示されているレコードを権限削除条件テーブルから抽出し、属性変化通知に示されている変化後の属性が当該レコードにある削除条件に合致するかを判断する（Ｓ６０３）（削除判定処理）。
例えば、図３の権限削除条件テーブルの場合、属性変化通知に示されている通行権限者（個人番号：ＡＢＣ１２３４）の変化後の所属組織が社長室以外であるかを判断する。

属性変化通知に示されている変化後の属性が削除条件に合致しない場合（ＮＯの場合）は、Ｓ６０１に戻る。
一方、属性変化通知に示されている変化後の属性が削除条件に合致する場合（ＹＥＳの場合）は、権限削除監視部１０６は、当該通行権限者のレコードを個人割り付け権限テーブルから削除するよう指示する削除指示を生成し、削除指示を通信部１０２から入退室管理システム３３０に送信させる（Ｓ６０４）（削除判定処理）。
削除指示には、削除対象の通行権限者の個人番号と、削除対象の通行権限が含まれる。
図４のように、扉ごとに削除条件が異なり、一部の扉の通行権限を削除する場合は、削除対象となる扉ＩＤを含ませる。
削除指示により入退室管理システム３３０では、入退室管理システムＤＢ３４０内の個人割り付け権限テーブルのうち対象となる通行権限者のレコード（又は扉ＩＤ）を削除し、これにより、対象となる通行権限者の通行権限が失効する。

次に、権限削除監視部１０６は、ＩＤ管理システムＤＢ１５０内の個人割り付け権限テーブルのうち対象となる通行権限者のレコード（又は扉ＩＤ）を削除し（Ｓ６０５）、更に、権限削除条件テーブル記憶部１０５内の権限削除条件テーブルのうち対象となるレコード（又は削除条件）を削除する（Ｓ６０６）。
図４のように、扉ごとに削除条件が異なり、一部の扉の通行権限のみを削除した場合は、通行権限を削除した扉ＩＤに対応する削除条件のみを削除する。

このように、本実施の形態に係るＩＤ管理では、個人の属性に対応付けて通行権限の削除条件を設け、個人の属性が変化して削除条件に合致することになった場合に、個人に割り当てられている通行権限を削除するため、不要になった通行権限が残ってしまうという事態を回避することができ、セキュリティ強度を高めることができる。
また、個人対応の通行権限の割り当ての際に有効期限を設定する必要がないので、有効期限切れによる更新手続も不要となり、更新手続にかかる管理負荷が発生しない。

なお、以上では、オフィスビルで就業する従業員を例として説明したが、病院、マンション、スポーツクラブ等の利用者の属性に基づいて個人対応の通行権限を設定したり、削除条件を設定するようにしてもよい。

以上、本実施の形態では、
個人ＩＤとそれに割りついたカードＩＤを管理し、扉の通行を許可する権限として、通行可能な扉のグループを通行権限としてカード毎に対応付けることにより、許可されたカードを持つ人のみが扉を通過できるようにする機能を有する入退室管理システムに対して、入退室管理システムで設定された、通行権限を通信により取り込み、入退室管理システムが必要とする個人ＩＤとカードＩＤと通行権限を各個人毎に割り付けて、情報を配信するＩＤ管理システムにおいて、個人に権限を割り付ける際に、通行権限を組織や役職、他の人事情報の属性に対して設定するのでなく、個人に対して特別な通行権限を与える時には、設定時に、以下のような削除条件を指定できる、通行権限を柔軟に割り付けるための制御方式を説明した。
（１）該当ユーザの組織が変更になった時
（２）指定した複数の組織以外の組織に変更になった時

最後に、本実施の形態に示したＩＤ管理システム１００のハードウェア構成例について説明する。
図７は、本実施の形態に示すＩＤ管理システム１００のハードウェア資源の一例を示す図である。
なお、図７の構成は、あくまでもＩＤ管理システム１００のハードウェア構成の一例を示すものであり、ＩＤ管理システム１００のハードウェア構成は図７に記載の構成に限らず、他の構成であってもよい。

図７において、ＩＤ管理システム１００は、プログラムを実行するＣＰＵ９１１（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）９１３、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（ＦｌｅｘｉｂｌｅＤｉｓｋＤｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、カードリーダ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
本実施の形態で説明したＩＤ管理システムＤＢ１５０及び権限削除条件テーブル記憶部１０５は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、カードリーダ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、図１に示すように、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮのほか、インターネット、ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｗｔｏｒｋ）、ＳＡＮ（ＳｔｏｒａｇｅＡｒｅａＮｅｔｗｏｒｋ）などに接続されていても構わない。

磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。

また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。

また、ＲＯＭ９１３には、ＢＩＯＳ（ＢａｓｉｃＩｎｐｕｔＯｕｔｐｕｔＳｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
ＩＤ管理システム１００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。

上記プログラム群９２３には、本実施の形態の説明において「〜部」（「権限削除条件テーブル記憶部１０５」を除く、以外でも同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。

ファイル群９２４には、本実施の形態の説明において、「〜の判断」、「〜の決定」、「〜の比較」、「〜の生成」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、本実施の形態で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、本実施の形態の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、本実施の形態の「〜部」としてコンピュータを機能させるものである。あるいは、本実施の形態の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、本実施の形態に示すＩＤ管理システム１００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

１００ＩＤ管理システム、１０１制御部、１０２通信部、１０３入出力部、１０４通行権限決定部、１０５権限削除条件テーブル記憶部、１０６権限削除監視部、１５０ＩＤ管理システムＤＢ、２００ディスプレイ装置、２１０キーボード、２２０カードリーダ、３００ＬＡＮ、３１０人事ＤＢシステム、３３０入退室管理システム、３４０入退室管理システムＤＢ、３５０扉制御装置、３６０電気錠、３７０カードリーダ、３８０扉。

Claims

ゲート装置を通行する権限を持つ通行権限者が示される通行権限者情報を保持し、前記通行権限者情報に基づき入退室管理を行う入退室管理システム
に接続されている情報処理装置であって、
通行権限者情報を削除するための削除条件を、前記通行権限者の役職、前記通行権限者のタスクフォース及び前記通行権限者が属するプロジェクトのうちの少なくともいずれかである前記通行権限者の属性に対応付けて定義する削除条件情報を記憶する削除条件情報記憶部と、
前記通行権限者の属性が変化した場合に、前記通行権限者の変化後の属性を検出する属性変化検出部と、
前記属性変化検出部により検出された前記通行権限者の変化後の属性が前記削除条件情報の削除条件に合致するか否かを判断し、前記通行権限者の変化後の属性が前記削除条件に合致する場合に、前記入退室管理システムに前記通行権限者の通行権限者情報の削除を指示し、前記ゲート装置に対する前記通行権限者の通行権限を失効させる削除判定部とを有することを特徴とする情報処理装置。
前記情報処理装置は、
複数のゲート装置を通行する権限を持つ通行権限者が示される通行権限者情報を記憶している入退室管理システムと接続されており、
前記削除条件情報記憶部は、
削除条件をゲート装置ごとに前記通行権限者の属性に対応付けて定義する削除条件情報を記憶し、
前記削除判定部は、
前記属性変化検出部により検出された前記通行権限者の変化後の属性が前記削除条件情報の削除条件に合致するか否かをゲート装置ごとに判断し、前記通行権限者の変化後の属性がいずれかのゲート装置の削除条件に合致する場合に、該当するゲート装置に関する前記通行権限者の通行権限者情報の削除を前記入退室管理システムに指示し、該当するゲート装置に対する前記通行権限者の通行権限を失効させることを特徴とする請求項１に記載の情報処理装置。
前記削除条件情報記憶部は、
前記通行権限者の所属組織に対応付けて削除条件を定義する削除条件情報を記憶し、
前記属性変化検出部は、
前記通行権限者の所属組織が変更になった場合に、前記通行権限者の変更後の所属組織を検出し、
前記削除判定部は、
前記属性変化検出部により検出された前記通行権限者の変更後の所属組織が前記削除条件情報の削除条件に合致する場合に、前記入退室管理システムに前記通行権限者の通行権限者情報の削除を指示することを特徴とする請求項１又は２に記載の情報処理装置。
ゲート装置を通行する権限を持つ通行権限者が示される通行権限者情報を保持し、前記通行権限者情報に基づき入退室管理を行う入退室管理システム
に接続され、
通行権限者情報を削除するための削除条件を、前記通行権限者の役職、前記通行権限者のタスクフォース及び前記通行権限者が属するプロジェクトのうちの少なくともいずれかである前記通行権限者の属性に対応付けて定義する削除条件情報を記憶しているコンピュータに、
前記通行権限者の属性が変化した場合に、前記通行権限者の変化後の属性を検出する属性変化検出処理と、
前記属性変化検出処理により検出された前記通行権限者の変化後の属性が前記削除条件情報の削除条件に合致するか否かを判断し、前記通行権限者の変化後の属性が前記削除条件に合致する場合に、前記入退室管理システムに前記通行権限者の通行権限者情報の削除を指示し、前記ゲート装置に対する前記通行権限者の通行権限を失効させる削除判定処理とを実行させることを特徴とするプログラム。