特許第5755475号(P5755475)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立情報通信エンジニアリングの特許一覧

特許5755475入退管理システム、及びアンチパスバック違反解除方法
<>
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000002
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000003
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000004
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000005
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000006
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000007
  • 特許5755475-入退管理システム、及びアンチパスバック違反解除方法 図000008
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5755475
(24)【登録日】2015年6月5日
(45)【発行日】2015年7月29日
(54)【発明の名称】入退管理システム、及びアンチパスバック違反解除方法
(51)【国際特許分類】
   G07C 9/00 20060101AFI20150709BHJP
   E05B 49/00 20060101ALI20150709BHJP
【FI】
   G07C9/00 Z
   E05B49/00 J
【請求項の数】8
【全頁数】21
(21)【出願番号】特願2011-74122(P2011-74122)
(22)【出願日】2011年3月30日
(65)【公開番号】特開2012-208746(P2012-208746A)
(43)【公開日】2012年10月25日
【審査請求日】2014年3月18日
(73)【特許権者】
【識別番号】000233295
【氏名又は名称】株式会社日立情報通信エンジニアリング
(74)【代理人】
【識別番号】100080001
【弁理士】
【氏名又は名称】筒井 大和
(72)【発明者】
【氏名】山崎 佑輔
(72)【発明者】
【氏名】角田 健一
【審査官】 太田 良隆
(56)【参考文献】
【文献】 特開平05−197890(JP,A)
【文献】 特開2007−247141(JP,A)
【文献】 特開2003−044891(JP,A)
【文献】 特開2009−087084(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G07C 9/00−9/02
E05B 49/00
(57)【特許請求の範囲】
【請求項1】
IDカードを利用した入退管理システムであって、
アンチパスバック制御を含む入退管理制御を所定の管理情報を用いて行う制御装置と、当該制御装置に接続される複数のカードリーダ装置と、を有し、
アンチパスバック違反を解除する制御を行う機能として、
(1)第1のカードリーダ装置で読み取った第1のIDカードがアンチパスバック違反状態である場合、タイマのカウントを開始する、第1の手段と、
(2)前記タイマのカウントによる所定の制限時間内に、前記第1のカードリーダ装置で読み取った第2のIDカードがアンチパスバック違反状態ではない場合、当該第2のIDカードが第1のIDカードのアンチパスバック違反状態を解除する権限を有するかを判定する、第2の手段と、
(3)上記権限を有する場合、前記第1のIDカードのアンチパスバック違反状態を解除する処理を前記管理情報に対して実行する、第3の手段と、を有すること、を特徴とする入退管理システム。
【請求項2】
請求項1記載の入退管理システムにおいて、
前記カードリーダ装置は、前記制御装置との通信に基づき、ユーザによりかざされる前記IDカードのID情報を読み取って扉の通過の許可/不許可を判定する認証を行いその結果に応じて扉の電気錠の解錠を制御し、
前記制御装置は、前記カードリーダ装置との通信に基づき、アンチパスバック違反の検出及び記録を含む入退管理制御の処理を前記所定の管理情報を用いて行い、
前記制御装置は、アンチパスバック違反を解除する機能を実現する解除制御部を有し、
前記解除制御部において、
(1)第1の動作として、アンチパスバック違反状態の第1のユーザの第1のIDカードを第1のカードリーダ装置で読み取って認証し不許可となった場合、当該契機で前記タイマのカウントを開始する、第1の処理部と、
(2)第2の動作として、前記タイマのカウントによる所定の制限時間内に、アンチパスバック違反状態ではない第2のユーザの第2のIDカードを前記第1のカードリーダ装置で読み取って認証し許可となった場合、当該契機で当該第2のユーザの第2のIDカードが前記第1のユーザの第1のIDカードのアンチパスバック違反状態を解除する権限を有するかを判定する、第2の処理部と、
(3)上記権限を有する場合、前記第1のユーザの第1のIDカードにおけるアンチパスバック違反状態を解除する処理を前記管理情報に対して実行する、第3の処理部と、を有し、
上記構成により、前記第1のユーザのアンチパスバック違反状態を第2のユーザの第2のIDカードの認証の動作に伴い解除でき、解除後、第1のユーザの第1のIDカードを第1のカードリーダ装置で読み取って認証し許可となることにより、第1のユーザによる扉の通過が可能になること、を特徴とする入退管理システム。
【請求項3】
請求項1記載の入退管理システムにおいて、
前記第3の手段は、前記解除処理において、更に、第1のユーザの第1のIDカードの第1のカードリーダ装置での認証の動作を省略して当該認証で許可された後の状態になるように、前記管理情報の内容を更新し、
上記構成により、前記第1のユーザのアンチパスバック違反状態を第2のユーザの第2のIDカードの認証の動作に伴い解除でき、解除後、第1のユーザの第1のIDカードを第1のカードリーダ装置で読み取って認証する動作を省略して、第2のユーザによる扉の通過と一緒に第1のユーザによる扉の通過が可能になること、を特徴とする入退管理システム。
【請求項4】
請求項1記載の入退管理システムにおいて、
前記カードリーダ装置は、前記タイマを有し、
前記制御装置は、前記タイマのカウントの状態を把握し、前記カウントによる制限時間の経過を判断し、前記制限時間の値を設定する、タイマ管理部を有すること、を特徴とする入退管理システム。
【請求項5】
請求項1記載の入退管理システムにおいて、
前記制御装置は、入退管理の対象となる組織のデータベースから、前記IDカードを持つユーザ間の関係を示すユーザ情報を取得または参照し、前記第2の手段による前記解除の権限の判定の際に、前記ユーザ情報を参照して前記権限の有無を判定する処理を行うこと、を特徴とする入退管理システム。
【請求項6】
請求項1記載の入退管理システムにおいて、
前記制御装置は、入退管理の対象となる組織の人事データベースから、前記IDカードを持つユーザ間の関係を示すユーザ情報を取得し、取得したユーザ情報から、前記解除の権限の有無を示すフラグ情報を含む権限テーブルを作成する処理を行い、前記第2の手段による前記権限の判定の際に、前記権限テーブルを参照して前記権限の有無を判定する処理を行うこと、を特徴とする入退管理システム。
【請求項7】
請求項1記載の入退管理システムにおいて、
前記制御装置は、前記第3の手段による解除処理を実行した場合の解除履歴情報を作成して履歴データベースに格納する処理を行うこと、を特徴とする入退管理システム。
【請求項8】
IDカードを利用した入退管理システムにおけるアンチパスバック違反を解除する処理を行うアンチパスバック違反解除方法であって、
前記入退管理システムは、アンチパスバック制御を含む入退管理制御を所定の管理情報を用いて行う制御装置と、当該制御装置に接続される複数のカードリーダ装置と、を有し、
前記アンチパスバック違反を解除する処理において、
(1)第1のカードリーダ装置で読み取った第1のIDカードがアンチパスバック違反状態である場合、タイマのカウントを開始する、第1の処理手順と、
(2)前記タイマのカウントによる所定の制限時間内に、前記第1のカードリーダ装置で読み取った第2のIDカードがアンチパスバック違反状態ではない場合、当該第2のIDカードが第1のIDカードのアンチパスバック違反状態を解除する権限を有するかを判定する、第2の処理手順と、
(3)上記権限を有する場合、前記第1のIDカードのアンチパスバック違反状態を解除する処理を前記管理情報に対して実行する、第3の処理手順と、を有すること、を特徴とするアンチパスバック違反解除方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、IDカードを利用した入退管理システムの技術に関し、特に、アンチパスバック制御などに関する。
【背景技術】
【0002】
セキュリティが必要な部屋などのエリア(セキュリティエリア)への入退室管理において、固有のIDが登録されているカード(ICカード(IDカード)等)がカードリーダ(認証装置)にかざされ、そのカード所有者(ユーザ)の入退権限有無を照会して当該カードリーダに対応付けられた扉(錠)の開閉を制御することによりセキュリティを確保するシステム(入退管理システム)が知られている。
【0003】
上記カードを用いた入退管理システム(その基本的な入退管理制御機能)において、更にセキュリティを強化する機能として、アンチパスバック(アンチパスバック制御機能)がある。以下、アンチパスバック:APBと略称する。
【0004】
即ち、上記基本的な入退管理制御機能がある場合でも、伴連れ(ピギーバック)やすれ違い等により不正にセキュリティエリアへ侵入したり、あるいはカードリーダにカードをかざして入退室が許可されたのにもかかわらず入退室しなかったり、といった行為(システムの正規登録者であるユーザによる不正を意図しない行為の場合を含む)によって、入退管理上の整合性に矛盾が生じること(いわゆる通行履歴違反による通行エラー)がある。そのような行為や状態(以下「APB違反」)を検出することや、APB違反状態のユーザ(対応カード)による入退室を制限してセキュリティを確保する機能・制御などを含めて、APBないしAPB制御と称する。
【0005】
上記APB制御では、例えば正規の手順(経路など)を踏まずに解錠された扉を通過したユーザ(APB違反者)に対して、次のカードリーダを用いた入退の認証での制限(不許可)により、セキュリティが確保・強化される。例えば、正規の手順として、第1の部屋への第1の扉の入室用の第1のカードリーダに第1のユーザが第1のカードをかざして入室許可され入室する第1の動作、続いて、同第1の扉の退室用の第2のカードリーダに第1のユーザが第1のカードをかざして退室許可され退室する第2の動作、といった順序による経路が定義される。そしてAPB制御では、第1の動作の後でないと第2の動作ができず、第2の動作の後でないと第1の動作ができず、また、第1の動作や第2の動作を2回続けてはできない、といったように制限される。
【0006】
上記APB制御機能を持つ入退管理システムにおいて、APB違反が発生した場合、例えば、当該APB違反者であるユーザがカードを次のカードリーダにかざしても不許可となるため扉が解錠されず他の部屋へ移動することができない、といった状態になる。そのため、システムの正規登録者のようなユーザによる不正を意図しない場合のAPB違反である場合は、上記状態を解除(リセット等)する必要が生じる。即ち、通常時のように当該ユーザが移動できる状態になるように、システムの入退管理・制御上の情報を適切に変更する必要が生じる。
【0007】
従来技術例のシステムでは、上記APB違反の解除については、管理者(解除の権限を持つ者)などによる人的な作業に依っている。即ち、管理者へ連絡され、当該APB違反のユーザ(対応カード)に関するシステムの入退管理・制御上の情報を修正する作業などが行われる。
【0008】
上記入退管理システムに関する先行技術例として、特開2009−087084号公報(特許文献1)、特開2000−259968号公報(特許文献2)、などが挙げられる。
【0009】
特許文献1では、ユーザが自律的にAPB違反(APBエラー)の解除を行うことを可能とする技術が開示されている。即ち、APB違反の一時的な解除のためのパスワードの入力を受け付ける手段と、受け付けた入力パスワードが登録済み情報である場合に、扉の通行制御を解除する手段と、を備えることが記載されている。
【0010】
また、特許文献2では、APB制御機能を持つ入退管理システム例について記載されている。
【先行技術文献】
【特許文献】
【0011】
【特許文献1】特開2009−087084号公報
【特許文献2】特開2000−259968号公報(特許第3982938号)
【発明の概要】
【発明が解決しようとする課題】
【0012】
前述の従来技術例の入退管理システムにおけるAPB違反の解除の方式では、管理者などによる手間やコストを要するという問題がある。例えば管理者が不在の場合などには解除作業が進まないといった不便も考えられる。
【0013】
前記特許文献1によれば、管理者などによる操作を伴わずに解除を実施できることになるが、当該ユーザが予めシステムに登録してあるパスワードを入力することにより当該ユーザ(APB違反者)自身が単独で解除を実施できてしまうため、セキュリティレベルが低下する問題がある。
【0014】
以上を鑑み、本発明の主な目的は、APB制御機能を含む入退管理システムに係わり、(1)管理者などによる手間やコストを要せず、かつ、(2)セキュリティレベルを低下させず、APB違反の解除を実現できる技術を提供することである。
【課題を解決するための手段】
【0015】
上記目的を達成するため、本発明のうち代表的な形態は、IDカード(ID情報が記録された媒体)を利用したAPB制御機能を含む入退管理システム、APB違反解除方法、等であって、以下に示す構成を有することを特徴とする。
【0016】
本形態の入退管理システムは、APB制御を含む入退管理制御を所定の管理情報を用いて行う制御装置と、当該制御装置に接続される複数のカードリーダ装置と、を有し、APB違反を解除する制御を行う機能として、(1)第1のカードリーダ装置で読み取った第1のIDカードがアンチパスバック違反状態である場合、タイマのカウントを開始する、第1の手段と、(2)前記タイマのカウントによる所定の制限時間内に、前記第1のカードリーダ装置で読み取った第2のIDカードがアンチパスバック違反状態ではない場合、当該第2のIDカードが第1のIDカードのアンチパスバック違反状態を解除する権限を有するかを判定する、第2の手段と、(3)上記権限を有する場合、前記第1のIDカードのアンチパスバック違反状態を解除する処理を前記管理情報に対して実行する、第3の手段と、を有する。
【0017】
本形態の入退管理システム/ABP違反解除方法は、例えば以下の手段/処理手順を有する。
【0018】
(a)第1のユーザの第1のIDカード、及び第2のユーザの第2のIDカードを含む各ユーザのカード(ID)に関するAPB制御を含む基本的な入退管理制御を、所定の管理情報を用いて行う手段/処理手順。
【0019】
(b)APB違反状態であり解除対象である第1のユーザの第1のIDカードを第1のリーダで読み取って認証する第1の動作により、第1のユーザのAPB違反状態または入退不許可を認識する手段/処理手順。
【0020】
(c)上記第1の動作を契機として、下記解除のための第2の動作を受け付ける時間を判定するためのタイマ手段のカウントを開始し、当該カウントによる所定の制限時間の経過の状態を判断・管理する手段/処理手順。
【0021】
(d)上記タイマ手段のカウントによる制限時間内において、上記第1のユーザのAPB違反状態を対象とした解除者となるAPB違反状態ではない第2のユーザの第2のIDカードを第1のリーダで読み取って認証する第2の動作により、第2のユーザによる解除の動作として受け付ける手段/処理手順。
【0022】
(e)上記解除の動作を受け付けた第2のユーザの第2のIDカードについて、上記第1のユーザの第1のIDカードに関するAPB違反状態を解除する権限の有無を判定する手段/処理手順。例えば、組織のユーザ情報を用いて当該解除権限を判定するための情報を作成・設定する手段/処理手順。
【0023】
(f)上記第2のユーザによる解除の権限が有る場合、第1のユーザの第1のIDカードに関するAPB違反状態の解除処理を、前記所定の管理情報に対して実行することにより、第1のユーザの第1のIDカードについて、非APB違反状態または入退許可となるように変更する手段/処理手順。前記所定の管理情報は、例えば、APB制御に対応した、第1のユーザの第1のIDカードに関する複数の各リーダでの認証における入退の許可/不許可の状態を示す情報を含む。
【0024】
(g)上記解除処理を実行した場合の解除履歴情報を作成し記録する手段/処理手順。
【0025】
例えば、第1の方式として、第2のユーザによる第2の動作(解除の動作)に基づく解除処理において、管理情報を、第1のユーザが第1のリーダの認証で入退が許可される状態となるように変更する。その後、第2のユーザが第1のリーダに対応する第1の扉を通過した後、第1のユーザの第1のIDカードを第1のリーダで読み取って認証し入退が許可されることにより、第2のユーザが第1の扉を通過する。
【発明の効果】
【0026】
本発明のうち代表的な形態によれば、APB制御機能を含む入退管理システムに係わり、(1)管理者などによる手間やコストを要せず、かつ、(2)セキュリティレベルを低下させず、APB違反の解除を実現できる。
【図面の簡単な説明】
【0027】
図1】本発明の一実施の形態のシステム(入退管理システム)を用いて実現される動作の例を示す図であり、(a)は第1の方式の場合、(b)は第2の方式の場合である。
図2】本発明の一実施の形態のシステム(入退管理システム)の全体の構成を示す図である。
図3】本システムのカードリーダ装置を含む構成を示す図である。
図4】本システムの第1の方式(図1(a))での処理フローを示す図である。
図5】本システムの管理情報の例として、(a)入退シーケンステーブル、(b)解錠フラグDB、を示す図である。
図6】本システムの管理情報の例として、人事DB/ユーザ情報に基づき作成される権限テーブル、を示す図である。
図7】本システムにおける管理情報(解錠フラグDB)の値の遷移例を示す図である。
【発明を実施するための形態】
【0028】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。説明上の記号として、R:リーダ(カードリーダ装置)、等とする。「ユーザ」は、本システムの利用者(正規登録者)、カード所持者などに相当する。「カード」はIDカード等に相当する。「ID」は識別子/識別情報に相当する。
【0029】
[概要等]
図1は、本実施の形態のシステムを用いて実現される動作の例をわかりやすく示しており、(a)は第1の方式(実施の形態1)の場合、(b)は第2の方式(実施の形態2)の場合である。なお図1中の部屋Aなどの例は図2中に示す管理対象空間と対応している。
【0030】
[第1の方式]
図1(a)の第1の方式において、左側にはユーザやカードの例、右側には部屋、扉、リーダR、等の例を示している。S1等は、動作やステップを表す。第1のユーザAは第1のカードA(対応する第1のID:ID1)を所持し、第2のユーザBは第2のカードB(対応する第2のID:ID2)を所持している。いずれのユーザA,B(カードA,B)も扉A(RA,RB)に関する基本的な通過権限を持つ設定である。第1のユーザAは、APB違反者(解除対象者)の例である。第2のユーザBは、第1のユーザAに関するAPB違反の解除権限を持つ人(解除者)の例である。例えば、同じ組織において、ユーザAは部下、ユーザBは上長、という関係であり、ユーザBはユーザAのAPB違反を解除する権限を有する設定である。
【0031】
状況として、ユーザA,Bが部屋外から部屋A内へ扉Aを通過して入室する場合である。扉Aの錠に関係付けられるリーダRA,RBを有し、第1のリーダRAは入室時の認証用、第2のリーダRBは退室時の認証用である。部屋Aへの入室に際し、リーダRAでの認証で許可(OK)になる必要があり、許可の場合は扉Aの電気錠が解錠され、不許可(NG)の場合は解錠されない。
【0032】
第1の方式では、例えばリーダRAでユーザAのAPB違反を認識した場合に、一緒にいるユーザBが、カードBをリーダRAにかざす動作によって、ユーザAのAPB違反状態を解除でき、ユーザAが扉Aを通過できる状態になる。同じ組織内での所定の関係性を持つユーザB(上長)がユーザA(部下)を目視確認(相互認証に相当する)しているため、この形でセキュリティレベルを維持しながら、解除の手続きを簡単な動作で実現している。
【0033】
そして、第1の方式では、ユーザBによる解除の動作により、まずユーザBが部屋Aに入室した後、ユーザAがカードAをリーダRAにかざし認証で許可されるので部屋Aに入室する、という流れである。即ちユーザB,Aの順で別々に部屋Aに入室する形である。
【0034】
図1(a)で、S1〜S4は上記の流れを示す。S1は、ユーザAによるAPB違反行為の一例である。S2は、ユーザAのカードA(ID1)の認証によりユーザAのAPB違反状態(不許可)を認識する動作である。S3は、ユーザBのカードB(ID2)自身の通常の認証(許可)の動作であるとともに、ユーザBのカードB(ID2)によるユーザAのカードA(ID1)のAPB違反の解除の動作となる。S4は、解除後のユーザAのカードA(ID1)の認証(許可)の動作である。
【0035】
(S1) S1は、APB違反行為の一例として、最初、ユーザAがカードAをリーダRAにかざして認証で許可(OK)され扉Aが解錠されたにもかかわらず扉Aを通過せず部屋Aに入室しなかった場合である。S1の認証(許可)により、本システムの管理情報(図2の解錠フラグDB32等)では、正規の手順に従い当該ユーザA(カードA,ID1)が部屋A内に移動したとみなした状態となっているが、実際には移動していないためAPB違反状態である。
【0036】
(S2) S2は、S1の後、S1のAPB違反状態となっているカードA(ID1)を持つユーザAが、再度、リーダRAにカードAをかざした場合である。この時、当該リーダRAでカードA(ID1)が読み取られ認証されるが、S1によるAPB違反状態であるため認証結果は不許可(NG)になり、扉Aは解錠されずユーザAは部屋Aに入室できない。
【0037】
本システムはS2によりユーザAのAPB違反状態(不許可)を認識し、このS2の契機で、リーダRAのタイマ61(図3)のカウントを開始する。タイマ61のカウントの制限時間Lが予め設定されている。この制限時間Lは、下記S3の解除の動作を受け付ける時間に相当する。
【0038】
(S3) S3は、上記制限時間L内に、APB違反状態ではないユーザBがカードB(ID2)を同リーダRAにかざした場合である。本システムで、このS3の動作は、まず当該ユーザB(カードB)自身の認証(許可)の動作となるが、それだけでなく、S2のユーザAのAPB違反状態を解除する動作としても認識される。S2のユーザAの近くにいるユーザBは、S2の動作(タイマ61のカウント等)を契機として、ユーザB自身が部屋Aに入室するための認証と同時にユーザAのAPB違反状態を解除してユーザAが入室できる状態にすることを、S3の1つの動作により行うことができる。
【0039】
S3の際、本システムは、当該ユーザB(カードB)がユーザA(カードA)の違反状態を解除する権限(解除権限)を有するかどうかを判定(確認)する。その結果、解除権限有りの場合、本システムは、自動的に、当該ユーザAのカードA(ID1)のAPB違反状態を解除する処理(「解除処理」)を、本システムの管理情報(図2の解錠フラグDB32等)に対して実行する。
【0040】
本例では、ユーザB(上長)はユーザA(部下)の違反を解除する権限を有する設定であるため、上記判定の結果、解除処理が実行され、ユーザAのカードAは、APB違反状態が解除された状態(非APB違反状態、通常の状態)になる。
【0041】
(S4) S3の後、ユーザA(カードA)は、通常の状態であり、リーダRAで認証が許可される状態になっている。よって、S4で、ユーザAがカードAをリーダRAにかざすとID1が読み取られ認証結果が許可になり、扉Aが解錠され、ユーザAは扉Aを通過して部屋Aに入室できる。
【0042】
以上のように所定の条件を満たした場合に自動的に解除処理が実行されるため、従来技術例のシステムのような解除の手続きのための管理者の手間などが不要である。また、解除の際(S2,S3)にユーザ間(A,B)で相互認証していることに相当する仕組みであるため、APB違反者自身がパスワードで解除できる方式のようなセキュリティレベルの低下も防止される。
【0043】
[第2の方式]
図1(b)の第2の方式において、S1,S2は図1(a)の第1の方式と同様である。第2の方式では、S3のユーザBによる解除の動作に基づき、ユーザAのAPB違反状態の解除処理を実行するが、この解除処理の内容が第1の方式のS3とは異なる。第2の方式では、このS3の解除処理により、第1の方式のS4のユーザAの認証の動作を省略する形である。これによりユーザAは、図1(a)のS2,S4のように2回カードAをかざす動作が必要無くなり、S2の1回の操作のみでよいことになり、ユーザAの負担が軽減される。
【0044】
(S3) S3で、制限時間L内に、APB違反状態ではないユーザBがカードB(ID2)を同リーダRAにかざした場合、ユーザBの認証(許可)と共に、ユーザBに解除権限有りの場合は、自動的に、ユーザAのカードA(ID1)のAPB違反状態の解除処理が当該ユーザAに関する管理情報(図2の解錠フラグDB32等)に対して実行される。この解除処理において、本システムは、第1の方式と同様にユーザAの違反状態を解除した状態となるように、かつ、ユーザAにより再度カードAをリーダRAにかざす認証(許可)の動作を済ませ当該ユーザAが部屋A内へ移動したとみなした状態となるように、管理情報の内容を更新する。
【0045】
(S4) S3の後、ユーザA(カードA)は、通常の状態であり、更にリーダRAでの認証を済ませた状態になっている。よって、S4で、ユーザAはカードAをリーダRAにかざす動作無しで、S3によるユーザBの扉Aの通過に伴い、ユーザBと一緒に(続いて)、扉Aを通過して部屋Aに入室できる。
【0046】
[他のAPB違反例]
なお図1のS1のAPB違反の例に限らず、他のAPB違反の場合であっても同様に本システムによる解除が実現できる。他のAPB違反の例を簡単に説明すると以下である(図2の管理対象空間に対応)。
【0047】
(a)ユーザAが部屋外から部屋Aへ扉Aを通過して入室する際、リーダRAでの認証の手順を踏まずに供連れ等によって入室した場合、APB違反行為である。この場合、管理情報の状態としては、当該ユーザAが部屋外にいる状態として把握している。よって、当該部屋A内のユーザAが次に通過が許可されるリーダRとして、例えばRAは許可(OK)、RB,RCは不許可(NG)となる。そのためユーザAは部屋A内から扉A(RB)や扉B(RC)を通過して退室しようとしても認証で不許可になるため退室できない。
【0048】
この場合の例えば部屋A内のユーザBによる解除動作に基づく解除処理としては、ユーザAが部屋外から部屋A内へ移動した後の状態となるように管理情報を更新すればよい(第1の方式)。即ち次に通過が許可されるリーダRとして、例えばRAは不許可(NG)、RB,RCは許可(OK)となるように更新すればよい。
【0049】
(b)ユーザAが部屋Aから部屋外へ扉Aを通過して退室する際、リーダRBでの認証の手順を踏まずに供連れ等によって退室した場合、APB違反行為である。この場合、管理情報の状態としては、当該ユーザAが部屋A内にいる状態として把握している。よって、当該部屋外のユーザAが次に通過が許可されるリーダRとして、例えばRAは不許可(NG)、RB,RCは許可(OK)となる。そのため例えばユーザAが部屋外から扉A(RA)を通過して部屋A内へ入室しようとしても認証で不許可になるため入室できない。
【0050】
この場合の例えば部屋外のユーザBによる解除動作に基づく解除処理としては、ユーザAが部屋Aから部屋外へ移動した後の状態となるように管理情報を更新すればよい(第1の方式)。即ち次に通過が許可されるリーダRとして、例えばRAは許可(NG)、RB,RCは不許可(NG)となるように更新すればよい。
【0051】
[管理対象空間]
図2で、管理対象空間において、セキュリティエリアとなる2つの部屋A,Bが存在する場合である。例えば部屋Aは扉A,扉Bを有する。各扉には対応する電気錠8(図3)を有する。例えば扉A(電気錠8)は、入室時の認証用の第1のリーダRAと、退室時の認証用の第2のリーダRBとが関係付けられている。
【0052】
管理対象の組織に所属している各ユーザ(本システムの正規登録者)はカード9を所持する。本例ではユーザA,B,C等がおり、ユーザAはカードA(対応するID:ID1)、ユーザBはカードB(対応するID:ID2)を所持する。カードAは、対応するIDのコードをID1で示し、カードBは、対応するIDのコードをID2で示すとする。各カード9のID情報などは予め本システムに登録される(SPU2による設定)。本システムにおけるAPB制御を含む基本的な入退管理制御において、ユーザA,BのカードA,B(対応ID)は、図2中のすべてのリーダ3(RA〜RF)で、APBの条件を満たす範囲内で基本的に通過(入退)が許可される権限を持つ設定である。特に、ユーザA,BのカードA,B(対応ID)は、所定のAPB制御に対応して、所定の経路(例えば部屋外−部屋A−部屋B−部屋外)における入退の両方向の移動が許可される。
【0053】
[システム構成(1)]
図2図3において、本システムの全体は、入退管理制御装置(コントローラ)1と、SPU(システム処理装置)2と、複数のカードリーダ装置(リーダR)3と、複数のリーダ制御装置4と、組織サーバ7と、を有し、これらはネットワーク(または専用接続線)5,6で接続されている。
【0054】
SPU2は、コントローラ1に接続され、管理者などが操作・参照する入退管理用のPCやサーバ等である。SPU2は、入退シーケンステーブル21、履歴DB22などの管理情報を有する。例えば管理者の操作に基づきSPU2を用いて画面でコントローラ1(本入退管理システム)に対する設定を行うことや、画面に履歴DB22の情報を表示して確認すること等ができる。SPU2の入退シーケンステーブル21は、マスタとして管理・設定する情報である。履歴DB22は、本システムの入退管理の履歴情報を一元的に格納するデータベースである。
【0055】
リーダR(3)の例としてRA〜RFを有する。例えば扉Aに関するリーダRA,RBは、リーダ制御装置A(4)に接続されている。リーダ制御装置A(4)は、対応するリーダRA,RBの制御を行う。各リーダ制御装置4はコントローラ1に接続される。なおリーダ制御装置4は、コントローラ1に統合した構成としてもよい。
【0056】
コントローラ1は、制御部10(APB制御機能を含む入退管理制御部)を有する。制御部10は、更新部11、解除制御部12(APB違反解除制御部)を有する。更新部11は、入退シーケンステーブル31、解錠フラグDB32などの管理情報を保持し処理する。解除制御部12は、設定部50(権限情報作成部)、タイマ管理部51、権限判定部52、解除処理部53、解除履歴部54、等の処理部を有する。設定部50は、ユーザ情報33、権限テーブル34などの管理情報を保持し処理する。これら各処理部は例えばソフトウェアプログラム処理や回路処理などにより実現される。また各種のDBやテーブル情報は、コントローラ1内部、SPU2内部などに限らず、他の外部の装置に保持されていてもよい。
【0057】
本実施の形態の入退管理システムは、前提として、制御部10により実現される、APB制御機能を含む基本的な入退管理制御機能を有する。なお本実施の形態では、APB制御機能としては、公知技術、例えば特許文献2記載の方式に従ったものとしているが、これに限定されるものではない。
【0058】
制御部10によるAPB制御を含む入退管理制御では、所定の経路でのユーザ(カード9)の移動のみを各リーダ3の認証で許可するようにする。これは管理情報として、入退シーケンステーブル31、解錠フラグDB32等により規定される(図5)。
【0059】
更新部11は、制御部10の一部(既存要素)であり、ネットワーク5及び各リーダ制御装置4を介して各リーダ3と通信しながら、基本の入退管理制御の管理情報を随時更新する処理を行う部分を示す。SPU2の入退シーケンステーブル21に基づき、コントローラ1で保持し、対応する入退シーケンステーブル31の内容が適宜更新される。更新部11は、入退シーケンステーブル31に基づき解錠フラグDB32の内容を適宜作成・更新する。更新部11は、解錠フラグDB32に基づき、各リーダ3への情報配信により、各リーダ3内の登録情報45(図3)を更新する。また更新部11は、SPU2の履歴DB22に対して、随時、通常の入退管理の履歴情報を格納する。
【0060】
解除制御部12は、制御部10のAPB制御におけるAPB違反の場合の解除のための処理を行う部分(機能)であり、更新部11と連携して動作する。またリーダ3側の解除制御部60(図3)と対応関係の機能である。
【0061】
設定部50は、組織サーバ7の人事DB71から情報をコントローラ1内へダウンロード等により取得し、この情報(ユーザ情報33)を用いて、本システム(権限判定部52)で利用するための権限テーブル34を作成(設定)する処理を行う。また設定部50を用いて管理者による権限テーブル34の設定も可能である。
【0062】
タイマ管理部51は、リーダ3の持つタイマ61(図3)に関する管理処理を行う。これは、タイマ61の起動の判断と、タイマ61のカウントの状態の把握と、タイマ61のカウントの制限時間Lの設定とを含む。本実施の形態では、タイマ管理部51を用いて、管理者による設定操作に基づき、各リーダ3のタイマ61の制限時間Lの値を可変に設定できる。なおタイマ61の制限時間Lは予め固定の設定値としてもよい。また、制限時間Lは、カード9(対応ユーザ)ごとに異なる設定を可能としてもよい。
【0063】
権限判定部52は、前述の動作(S3)に基づくAPB違反状態の解除(APB制御でAPB違反により不許可の状態になっているカード9を許可の状態に変更すること等)を行うための解除権限を判定・確認する処理を行う。権限判定部52は、例えば権限テーブル34(または人事DB71/ユーザ情報33)を参照して当該判定・確認を行う。なお解除権限は、APB制御用のフラグ(解錠フラグ)を変更する権限などと言い換え可能である。
【0064】
解除処理部53は、権限判定部52により権限有りが確認された場合に、解錠フラグDB32等に対して解除処理を実行する。これにより解錠フラグDB32の内容が適宜更新される。
【0065】
解除履歴部54は、解除処理部53による解除処理が実行された場合に、対応する解除履歴情報を作成し、当該情報をネットワーク6を介してSPU2の履歴DB22に配信して記録する処理を行う。これにより解除履歴情報についても基本の履歴情報と併せて管理者がSPU2で参照可能となるため、システム管理上有用となる。
【0066】
本実施の形態の入退管理システムでは、SPU2、コントローラ1、複数のリーダ制御装置4、複数のリーダ3、といった要素が接続されて成る構成であるが、これらは適宜統合や分離した形態が可能である。例えばSPU2とコントローラ1を統合してもよいし、コントローラ1とリーダ制御装置4を統合してもよい。
【0067】
[システム構成(2)]
図3で、特にコントローラ1とカードリーダ装置3との接続構成例及び連携処理例を説明する。リーダ3の制御部40は、コントローラ1の制御部10と対応した、APB制御を含む入退管理制御に関する処理を行う。そして制御部40は、解除制御部60を有し、解除制御部60は、コントローラ1の解除制御部12と対応した、APB違反の解除に関する処理を行う。
【0068】
制御部40は、公知要素として、ID読取部41、ID認証部42、錠制御部43、登録情報45などを有する。ID読取部41は、ユーザによりかざされたカード9のID情報などを読み取る。ID認証部42は、ID読取部41により読み取られたID情報と、登録情報45とを用いて、ID認証処理を行う。例えば、ID認証部42は、読み取られたIDと同じIDが登録情報45内に登録されている場合は、認証結果として「許可」(OK)とし、無い場合は「不許可」(NG)とする。錠制御部43は、ID認証部42の認証結果が「許可」の場合は、対応する扉の電気錠8を解錠する。上記ID認証及びその結果は適宜リーダ3(制御部40)とコントローラ1(更新部11)との通信に基づきコントローラ1側でも把握・管理され、基本の履歴情報として履歴DB22へ記録される。
【0069】
登録情報45の例としては、当該リーダ3の認証で入退が許可されるID情報(例{ID1,ID2,……})が登録されており、更新部11からの解錠フラグDB32の情報の配信により随時更新される。
【0070】
解除制御部60は、タイマ61、ユーザI/F部62を含む。解除制御部60は、制御部40(ID認証部42)によるカード9のIDの認証結果が不許可でありAPB違反状態の時は、タイマ管理部51による判断に基づき、タイマ61のカウントを開始する。タイマ61は、タイマ管理部51から、カウントに関する所定の制限時間Lが設定されている。タイマ61のカウントの状態はタイマ管理部51により把握される。
【0071】
ユーザI/F部62は、タイマ61の作動に伴い、状態や解除動作に関するユーザインタフェースを提供する。例えばLEDランプ等の表示制御や、ブザーやスピーカ等の音声出力や、ディスプレイ等のメッセージ表示など、各種の形態が可能である。例えば、図1(a)のS2でAPB違反状態を認識すると、タイマ61のカウントと共にユーザI/F部62で所定のLEDを点灯/点滅させ、制限時間Lを経過した場合はLEDを消灯させる、といった制御が挙げられる。なおユーザI/F部62の具備は必須ではない。また同様に、コントローラ1側、SPU2側においても、対応してユーザインタフェース(パトランプ表示など)を提供してもよい。
【0072】
各部(40,60,10,12)が連携して処理を行うことにより、APB制御を含む入退管理制御、及び解除制御を実現する。リーダ3の制御部40とコントローラ1の制御部10とが連携し、リーダ3の制御部40と解除制御部60とが連携し、コントローラ1の制御部10と解除制御部60とが連携する。例えば基本的(通常時)には、リーダ3にカード9がかざされる動作による認証の発生ごとに、リーダ3の制御部40とコントローラ1の制御部10(更新部11)との間でネットワーク5及びリーダ制御装置4を介して通信し入退管理制御に係わる処理を行う。その際、当該カード9(ID)が所定の条件に該当する場合は、更にリーダ3の解除制御部60とコントローラ1の解除制御部12とを用いてAPB違反の解除に関する処理を行う。
【0073】
例えば図1(a)のS2の動作の時は、リーダ3の制御部40からコントローラ1の制御部10(更新部11)へ連携して通常の入退管理制御の処理が行われることにより、ユーザAのAPB違反状態(不許可)が認識される(履歴情報も記録される)。またそれに基づき、各制御部10,40から各解除制御部12,60へ連携して、タイマ管理部51によりタイマ61を起動し、カウント状態を把握する。また、S3の動作の時は、同様の連携により、コントローラ1のタイマ管理部12で各リーダ3のタイマ61のカウントによる制限時間Lの経過などを判断する。S3の時、コントローラ1側では、タイマ管理部12による制限時間Lの経過の判断、権限判定部52による解除権限の判定、解除処理部53による解除処理、及び、解除履歴部54による解除履歴格納、といった流れで処理が行われる。
【0074】
コントローラ1の制御部10は、図示しないプロセッサ、メモリ、入力装置、出力装置、通信I/F装置などの公知要素を用いて実現される。プロセッサがメモリに制御プログラムをロードして実行すること等により各処理部が実現される。また、リーダ3の制御部40は、図示しないプロセッサ、メモリ、入力装置、出力装置、通信I/F装置などを用いて実現される。また、SPU2は、図示しないプロセッサ、メモリ、入力装置、出力装置、通信I/F装置などを用いて実現される。
【0075】
なお図3では、下位のリーダ3側にタイマ61を備え、上位のコントローラ1側にタイマ管理部51を備える構成例を示しているが、これに限らず可能である。例えば、上位のコントローラ1(解除制御部12)側にのみタイマ61及びタイマ管理部51相当を備えて、基本的にコントローラ1側で時間の管理をしてもよい。また、例えば下位の各リーダ3(解除制御部60)側で独立的にタイマ61及びタイマ管理部51相当を備えて、基本的にリーダ3側で時間の管理をしてもよい。
【0076】
[APB制御]
本実施の形態におけるAPB制御について説明する。本APB制御では、主に図5の管理情報(入退シーケンステーブル31、解錠フラグDB32)を用いる。入退シーケンステーブル31及び解錠フラグDB32に応じて、コントローラ1から各リーダ3(登録情報45)への配信内容が決定される。コントローラ1(更新部11)は、随時、入退シーケンステーブル31の情報を用いて、解錠フラグDB32の内容を更新する処理を行い、また解錠フラグDB32の情報を用いて、各リーダ3の登録情報45の内容を更新するための情報を配信する処理を行う。解錠フラグDB32の内容は、各カード9がかざされる各リーダ3に関する入退管理上のフラグ情報(解錠フラグ)を含む。
【0077】
図5の管理情報などに基づき、本システムのコントローラ1では、例えば図1図2)のリーダRAにユーザAのカードAがかざされた場合、当該ユーザAが部屋Aに移動したものとみなし、部屋A内からカードAをかざすことができるリーダRB,RCのみ、次に許可するように解錠フラグDB32のフラグ情報などを更新する。また一方、部屋外から部屋A内へ移動したとみなしたため、部屋A内からカードAをかざすことのできないリーダRA,RF等(RB,RC以外)については、次に不許可になるように上記情報を更新する。
【0078】
図1図2)の例で実現されるAPB制御内容(入退の制限)としては、部屋外からは部屋Aまたは部屋Bへの扉A,C(対応RA,RF)の通過のみ許可され、部屋Aからは部屋外または部屋Bへの扉A,B(対応RB,RC)の通過のみ許可され、部屋Bからは部屋Aまたは部屋外への扉B,C(対応RD,RE)の通過のみ許可される(図5のテーブルT1の設定と対応)。
【0079】
上記APB制御により、例えばユーザAが部屋外でカードAをリーダRAにかざして認証で許可となったにもかかわらず扉Aを通過して部屋A内へ移動しなかった場合、APB違反行為となる(S1)。当該ユーザAはAPB違反状態であるため、部屋外から別のエリア(部屋Aまたは部屋B)へ移動することができない。即ちAPB制御による高いセキュリティが実現されている。
【0080】
上記APB違反(S1)により、例えばユーザAのカードA(ID1)は部屋A内へ移動することができない状態となっている。このAPB違反状態を解除する手続きを、本システムの機能(解除制御部12,60等)を用いて自動的な処理として行う。
【0081】
[入退シーケンステーブル]
図5(a)は、SPU2の入退シーケンステーブル21に基づくコントローラ1の入退シーケンステーブル31の例を示している。入退シーケンステーブル31は、APB制御を含む入退管理制御に対応した、正規の手順に対応する所定の経路に応じた入退シーケンス(解錠フラグ情報を含む)についてテーブル(T)として定義されている。また多様な経路の制御に対応可能なように複数の種類のテーブル(T1,T2等)として定義されている。例えばT1は第1の経路(APB制御内容)に対応したテーブルである。
【0082】
入退シーケンステーブル31は、各リーダ3(例:RA〜RF)にカード9(基本的な通過権限有りのカード、例えばカードA,B等)がかざされる際、前後のリーダ3での認証の許可/不許可の関係を解錠フラグ情報で規定している。言い換えると、前のリーダRの認証で許可となったカード9について、次にどのリーダ3で許可となるかについての登録情報である。
【0083】
T1において、(a)「前リーダ」と(b)「次リーダ」との各リーダR{RA〜RF等}の関係のマトリクスで、フラグ値“0”/“1”が設定される。(a)「前リーダ」は、前にカード9がかざされ認証で許可したリーダRを示す番号などである。(b)「次リーダ」は、(a)「前リーダ」の次にカード9がかざされ認証が行われるリーダRを示す番号などである。フラグ(解錠フラグ)は、(b)「次リーダ」の認証における許可/不許可を示す。“0”は次に不許可にすること(OFF)を示し、“1”は次に許可にすること(ON)を示す。
【0084】
例えば501の行では、リーダRAの許可の次に許可されるリーダ3がRB,RCであることを示している。これは図1等で部屋外からリーダRAの認証で許可され扉Aを通過して部屋Aに入室した場合は次に扉A・リーダRAを通じて部屋外へ退室するか、扉B・リーダRBを通じて部屋Bへ入室するか、に制限されることに対応している。同様に502の行では、リーダRBの許可の次に許可されるリーダ3がRA,RFであることを示している。
【0085】
[解錠フラグDB]
また図5(b)は、コントローラ1の解錠フラグDB32の例を示している。解錠フラグDB32は、各リーダ3毎、各カード9(対応ID、ユーザ)毎における、APB制御を含む入退管理制御のためのフラグ(解錠フラグ)を含む情報が規定されている。解錠フラグDB32は、各ユーザがリーダ3にカード9をかざした結果の時点ごとの状態を表している。リーダ3でのカード9の認証で許可となった場合は解錠フラグDB32の内容が更新され、不許可の場合は更新されない。
【0086】
「カードID」項目はカード9のID(対応するユーザ)を示す。例えばID1(ユーザA),ID2(ユーザB)等である。なおユーザ、カード、IDなどは所定の対応関係で管理されるため適宜読み替え可能である。「入退シーケンステーブル番号」項目は、当該「カードID」に対して関係付ける入退シーケンステーブル31(T)の番号を示す。例えばユーザA,BのカードA,Bで同じ入退シーケンステーブルT1(図5(a))が関連付けられ即ち同じAPB制御が行われる設定の場合である。「リーダ番号&フラグ」項目は、当該「カードID」(ユーザ)について、次のリーダ3に応じた許可/不許可の状態(セット)を示す。
【0087】
例えば、図2のユーザA(カードA)が部屋AからリーダRBの認証の許可を通じて部屋外へ移動した後の状態の場合、図5(a)のT1の2行目(502)に従い、「リーダ番号&フラグ」項目は、511のような値となる。即ち、次に許可されるリーダ3がRA,RFのみの状態である。例えば、図2のユーザB(カードB)が部屋外からリーダRAの認証の許可を通じて部屋A内へ移動した後の時点の状態の場合、図5(a)のT1の1行目(501)に従い、「リーダ番号&フラグ」項目は、512のような値となる。即ち、次に許可されるリーダ3がRB,RCのみの状態である。
【0088】
なお各ユーザごとの経路(対応テーブルT)の設定によらずに、二人のユーザ(例:A,B)が同じリーダ3の認証を通じて同じ扉を通過する際に、本システムの解除機能が有効である。
【0089】
[人事DB・ユーザ情報・権限テーブル]
図6は、人事DB71ないしユーザ情報33、及びそれらの情報に基づいて作成(設定)される権限テーブル34の例を示す。これらの情報は、本システムにカード9(ID)情報が登録されるユーザ同士の関係を確認し、解除権限を判定するために用いる。例えばユーザA,Bが互いに同じ組織に所属する人であるのかどうかや、組織内でユーザAに対してユーザBが上位となる関係か、等を判定するために用いる。
【0090】
図2の組織サーバ7は、人事DB71などを保持する。人事DB71は、管理対象の組織の人事情報(複数のユーザの情報)を含むデータベースである。コントローラ1のユーザ情報33は、人事DB71からダウンロード等により取得した同様の情報である。例えば、ユーザA,B,C等において、ユーザ同士の関係が階層あるいはグループなどによって規定されている。本例では、ユーザBが上長であり、その部下としてユーザA,C等を有する。
【0091】
そして本実施の形態では特に、設定部50により、人事DB71情報またはユーザ情報33を用いて権限テーブル34を予め作成(設定)する処理を行う。そして、権限判定部52による権限判定の際にこの権限テーブル34の情報を参照する構成である。
【0092】
権限テーブル34で、左側(行)は解除者(例えばユーザB)となるユーザのIDを示し、上側(列)は解除対象者(例えばユーザA)となるユーザのIDを示し、それらのユーザ同士の関係のマトリクスで、フラグ(解除権限フラグ)は解除権限の有無を示す。解除権限フラグ=“1”は権限有り、“0”は権限無しを示す。本例では、601の行に示すように、ユーザBは、ユーザA,CのAPB違反の解除の権限を有する設定である。
【0093】
また、権限テーブル34情報は、設定部50やSPU2を用いて管理者による手動で詳細設定してもよい。その場合、組織のセキュリティポリシー等に応じて、個別のユーザ毎に権限を設定可能である。例えば、ユーザA,Cが同僚(同グループ)であり、ユーザA,C同士で互いに解除権限を持たせるといった設定も可能である。
【0094】
なお上記権限テーブル34が無いとしても、各ユーザのカード9(ID)同士の解除権限有無(ユーザ同士の関係性)を判定することができる同様の情報として、人事DB71情報ないしユーザ情報33を直接参照して判定する等の形でもよい。
【0095】
[処理(第1の方式)]
図4の処理フロー(図1(a)の第1の方式に対応)を用いて、解除の手続きについて説明する。Sは処理ステップを表す。
【0096】
(S100) まず前提として、APB違反行為(例:図1(a)のS1)があったとする。これはコントローラ1の制御部10(更新部11)の通常の制御として検出及び記録されている(解錠フラグDB32の内容に反映されている)。
【0097】
(S101) 上記APB違反状態のユーザ(例:A)がカード9(例:A)をリーダ3(例:RA)にかざす(S2)。リーダ3の制御部40は、かざされたカード9のIDをID読取部41により読み取り、ID認証部42により当該読み取りIDと登録情報45の登録IDとを比較して認証し、「許可」(“1”)か「APB違反による不許可」(“0”)かを判定する。不許可の場合(Y)はS102へ進む。許可の場合(N)は終了する(最初から同様に繰返し)。
【0098】
なおS101−Nの場合、既存の入退管理制御に従う通常通りの制御(許可処理を含む)が行われる。即ち許可処理では、リーダ3(錠制御部43)は、許可なので、対応する扉の電気錠8を解錠する。またリーダ3とコントローラ1との通信に基づき、コントローラ1(更新部11)は、入退許可とした内容の履歴情報を作成して履歴DB22へ記録する。更には、入退シーケンステーブル31に従い、解錠フラグDB32の更新も行われる。
【0099】
例えばリーダRAでは、カードAのID1(ユーザA)に関して、APB違反状態であるため、上記認証結果が不許可となる。
【0100】
(S102) リーダ3及びコントローラ1は、不許可処理(既存処理)を行う。リーダ3は、不許可なので、対応する扉の電気錠8を解錠しない。またリーダ3とコントローラ1との通信に基づき、コントローラ1(更新部11)は、入退不許可とした内容の履歴情報を作成して履歴DB22へ記録する。
【0101】
(S103) コントローラ1は、上記S101,S102によるリーダ3(RA)との通信に基づき、当該カードA(ID1)がAPB違反状態により不許可となったこと(S2)を認識する。認識した結果に基づき、タイマ管理部51は、当該契機で、当該リーダ3(RA)のタイマ61を起動させる。当該リーダ3(RA)はタイマ61のカウントを開始する。
【0102】
(S104) S104では、同リーダ3(RA)において、上記タイマ61のカウント中の状態で、上記S101のAPB違反状態の不許可カード(例:カードA)とは別に、APB違反状態ではない許可カード(例:カードB)がかざされたかどうかを判定する。例えばAPB違反状態ではないユーザBがカードBを同リーダ3(RA)にかざす(S3)。リーダ3(RA)は、S101と同様に、当該カード9のIDを読み取って認証し許可/不許可を判定する。ここで許可のカード(B)である場合(Y)はS105へ進む。不許可のカード(B)である場合(N)はS108へ進む。なおS104−Yの場合、上記同様に通常通りの制御(許可処理を含む)が行われる。
【0103】
(S105) S105では、上記S104でかざされた許可カード(B)(対応ユーザ、ID)に関して、上記S101の不許可カード(A)に関するAPB違反の解除権限が有るかどうかを判定する。リーダ3とコントローラ1との通信に基づき、コントローラ1の解除制御部12の権限判定部52は、権限テーブル34を参照し、上記権限有無を確認する。権限有りの場合(Y)はS106へ進み、権限無しの場合(N)はS108へ進む。なお権限テーブル34を用いない場合は人事DB71やユーザ情報33の検索処理になる。
【0104】
例えば権限テーブル34(図6)で該当ID(ID1,ID2)に関する解除権限フラグをみると、当該ユーザB(ID2)が当該ユーザA(ID1)の解除権限を持っており、上記判定結果は権限有りとなる。
【0105】
(S106) 上記権限有りの場合、解除処理部53は、上記APB違反状態のユーザA(カードA)に関して、解除処理を実行する。即ち、解除処理部53は、解錠フラグDB32の内容(解錠フラグ)を修正することにより、当該カードA(ID1)の状態が不許可(違反状態)から許可(通常状態)になるように変更する(値の具体例は図7)。これにより例えばユーザAのカードAはリーダRAの認証で許可される状態になる。
【0106】
(S107) また、解除履歴部54は、上記S106の解除(修正)を実行したことを示す内容の解除履歴情報を作成し、ネットワーク6を介してSPU2へ配信して履歴DB22内に記録する。解除履歴情報は例えばカードB(ID2)がカードA(ID1)のAPB違反状態を解除(修正)したことを示す情報を含む。
【0107】
(S108) S108では、タイマ61のカウント値が所定の設定された制限時間Lを経過したかどうかを判定する。Lを経過した場合(Y)は終了する(解除動作は無効となる)。Lを経過していない場合(N)は、S104に戻って同様に繰り返す。
【0108】
その後は、例えばカードAを持つユーザAは、リーダRAにカードAをかざすことにより(図1(a)、S4)、認証で許可となるので、部屋外から扉Aを通過して部屋A内へ移動することができる。
【0109】
[処理(第2の方式)]
図1(b)の第2の方式の場合、図4の第1の方式の処理フローと概ね共通であるが、異なる処理として以下がある。特にS3,S4に対応してS106の解除処理の内容が異なる。第2の方式では、S106で、解除処理部53は、APB違反状態の不許可カード(例:カードA)を非APB違反状態の許可カードの状態になるように変更すると共に、更に当該リーダRAでのユーザAのカードAの認証を済ませた後の状態(部屋外から部屋A内へ移動したとみなした状態)になるように、解錠フラグDB32の内容を更新する(図7)。
【0110】
解錠フラグDB32を更新する方法として、公知技術、例えば、特許文献2の方式を用いるために、リーダRAにユーザAのカードAが認証し許可となったように装い、許可履歴情報を作成し、ネットワーク5を介して、入退シーケンステーブル31に従い、解錠フラグDB32を更新する。
【0111】
また、別の方法として、S106での処理と一緒に、入退シーケンステーブル31の501を同時に実施して解錠フラグDB32を更新するようにしてもよい。
【0112】
[具体例]
図7は解錠フラグDB32の内容(値)の具体的な更新(遷移)の例を示している。図1(a)の第1の方式の例に対応して、ユーザA(ID1)、入退シーケンステーブルT1に関して、次に許可されるリーダRの状態を示している。
【0113】
700は、最初、S1のAPB違反行為よりも前の正常な状態である。部屋外にユーザAがいる状態なので、次にリーダRA,RFのみが許可(“1”)となっている。
【0114】
701は、S1のAPB違反行為をした後の状態、及びS2の時の状態である。S1でリーダRAにカードAをかざして許可され、ユーザAは部屋A内へ移動したとみなされ、次にリーダRB,RCのみが許可となっている。S2の時、この状態であるため、ユーザAがカードAをリーダRAにかざしても不許可となる。
【0115】
702は、図1(a)の第1の方式の場合でS3の解除の後の状態である。解除処理により701の状態が702の状態へ修正されている。これによりS4でユーザAがカードAをリーダRAにかざすと許可となる。
【0116】
703は、図1(b)の第2の方式の場合でS3の解除の後の状態である。解除処理により701の状態が703の状態へ修正されている。なおこの場合、701の値と703の値とが偶々同じ場合である。
【0117】
704は、702または703の後、S4によりユーザAが部屋A内へ移動した後の状態である。次にリーダRB,RCのみが許可となっている。
【0118】
またユーザB(ID2)、テーブルT1に関して、次に許可されるリーダRの状態を同様に示している。710は、701と同様に、最初、S1よりも前の正常な状態である。部屋外にユーザAと共にユーザBがいる状態である。711は、図1(a)の第1の方式の場合でS3の後の状態である。リードRAでのユーザBの認証の許可により、次にリーダRB,RCのみが許可となっている。712は、図1(b)の第2の方式の場合でS3の後の状態であり、711と同様の状態である。
【0119】
[効果等]
以上説明したように、本実施の形態によれば、一緒にいるユーザ同士の責任(相互認証)に基づいて解除が実現できる仕組みであり、管理者などによる手間やコストを要せず、かつ、セキュリティレベルを低下させず、APB違反の解除を実現できる。例えば管理者が不在の場合でも解除に対応可能であるという効果がある。
【0120】
従来技術例のシステムにおけるAPB違反の解除の際の管理者の作業の例を挙げると以下である。管理者は解除のための連絡を受けると、SPU等で履歴DBの情報を参照し、その中から該当のAPB違反の箇所の情報を抽出する。そしてSPU等で所定のソフトウェアプログラム処理の実行により、システムの管理情報に対して解除(APB違反が解除された整合性のある状態への修正)を行っている。一方、本実施の形態では、自動的に解除処理が行われるので、上記管理者の作業を必要としない、もしくは削減できる。
【0121】
図1(a)の第1の方式と図1(b)の第2の方式については、一方のみ固定で実装した形態としてもよいし、コントローラ1の設定によりその都度適用する方式を選択可能な形態としてもよい。また解除権限を持つユーザごとに適用する方式を選択設定可能な形態としてもよい。
【0122】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【0123】
本発明は、入退管理システムに利用可能である。
【符号の説明】
【0124】
1…入退管理制御装置(コントローラ)、2…SPU(システム処理装置)、3…カードリーダ装置(リーダ)、4…リーダ制御装置、5,6…ネットワーク、7…組織サーバ、8…電気錠、9…カード(IDカード)、10…制御部、11…更新部、12…解除制御部、21…入退シーケンステーブル、22…履歴DB、31…入退シーケンステーブル、32…解錠フラグDB、33…ユーザ情報、34…権限テーブル、40…制御部、41…ID読取部、42…ID認証部、43…錠制御部、45…登録情報、50…設定部(権限情報作成部)、51…タイマ管理部、52…権限判定部、53…解除処理部、54…解除履歴部、60…解除制御部、61…タイマ、62…ユーザI/F部、71…人事DB。
図1
図2
図3
図4
図5
図6
図7