JP6212864B2 - 鍵管理システム、方法及びプログラム - Google Patents

Description

本技術は、物理的な鍵の管理技術に関する。

例えば刑事施設等の施設においては、利用制限のある鍵を使用する際に、被承認者（利用者とも呼ぶ）からの承認依頼行為に対して、上司等の承認権限者（承認者又は許可者とも呼ぶ）の承認を得て、鍵を利用する。

但し、刑事施設等の施設では、交替勤務制のため、日々、承認権限者群に含まれる承認権限者と、被承認者群に含まれる被承認者との組み合わせが変化するという特徴がある。

一方、一般的な施設においては、火災発生などの緊急時において、鍵を全て取り出し可能状態又はロック解除状態とし、避難行動を最優先する。

しかしながら、刑事施設などの施設では、報知器の誤動作又は故意の鳴動（受刑者が脱獄を試みるため等）に対して、一般的な施設と同様に鍵を自由に取り出せる状態にするのは好ましくない。その一方で、緊急時にも、通常の承認フローで鍵を使用可能にするならば、承認権限者が一時不在だった場合などに緊急時対応が速やかに行えないことになる。そうすると、本当の火災だった場合等には避難行動が遅れ、大惨事にいたる危険性がある。

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

従って、本技術の目的は、一側面によれば、緊急時において速やかに鍵の使用について承認を行うことができるようにするための技術を提供することである。

本技術の一側面に係る鍵管理方法は、（Ａ）警報を受信すると、当該警報に係るエリアの鍵を特定し、（Ｂ）承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部における上記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する処理を含む。

一側面によれば、緊急時において速やかに鍵の使用について承認を行うことができる。

図１は、実施の形態に係る鍵管理システムの概要を示す図である。 図２は、鍵管理装置の機能ブロック図である。 図３は、鍵管理サーバの機能ブロック図である。 図４は、出勤予定データの一例を示す図である。 図５は、エリアデータ格納部に格納されるデータの一例を示す図である。 図６は、実施の形態におけるメインの処理フローである。 図７は、第１の実施の形態に係る承認データ生成処理の処理フローを示す図である。 図８は、所定期間の設定例を示す図である。 図９は、承認データの一例を示す図である。 図１０は、タグＩＤと名前との対応関係を示す図である。 図１１は、タグＩＤの受信サイクルの一例を示す図である。 図１２は、出退勤データの一例を示す図である。 図１３は、第２の実施の形態に係る承認データ生成処理の処理フローを示す図である。 図１４は、第２の実施の形態に係る仮の承認データの一例を示す図である。 図１５は、第２の実施の形態に係る他の仮の承認データの一例を示す図である。 図１６は、除外処理の処理フローを示す図である。 図１７は、除外者リスト生成処理の処理フローを示す図である。 図１８は、鍵不正利用者リストの一例を示す図である。 図１９は、熟練度管理テーブルの一例を示す図である。 図２０は、鍵貸出ログデータの一例を示す図である。 図２１は、第３の実施の形態に係る承認データ生成処理の処理フローを示す図である。 図２２は、コンピュータの機能ブロック図である。

［実施の形態１］
本技術の実施の形態に係る鍵管理システムの構成例を図１に示す。図１に示すように、ＬＡＮ（Local Area Network）などのネットワーク１に、防災システム２００と、鍵管理サーバ１００と、鍵管理装置３００と、勤怠管理サーバ４００と、１又は複数の承認権限者端末５００と、１又は複数の被承認者端末６００とが接続されている。

防災システム２００には、施設の各エリアに設置され且つ火災などを検知する火災報知器のような警報装置が接続されている。そして、防災システム２００は、警報装置からの警報を受け付け、鍵管理サーバ１００に、エリアのコードを含む警報を通知する。

勤怠管理サーバ４００は、例えば１又は複数の入館検査装置に接続されており、ユーザの出退勤のログデータを、データベース（ＤＢ）４１０に蓄積する。なお、ＤＢ４１０は、出勤予定データも格納している場合もある。

被承認者は、被承認者端末６００を操作して、特定のエリアのための鍵使用の許可申請を鍵管理サーバ１００に送信する。鍵管理サーバ１００は、被承認者端末６００から許可申請を受信すると、当該被承認者に対して承認を行うことができる承認権限者宛に許可申請があったことを表す通知を行う。承認権限者は、承認権限者端末５００を操作して、鍵管理サーバ１００からの通知に応じて、被承認者からの許可申請を判断して、問題なければ許可通知を鍵管理サーバ１００に送信する。鍵管理サーバ１００は、許可通知を受信すると、許可申請に係る鍵の使用許可通知を、鍵管理装置３００に送信する。鍵管理装置３００は、使用許可通知を受信すると、許可された被承認者が認証処理を行えば、特定のエリアのための鍵を取り出せるようにする。

鍵管理装置３００は、例えば図２に示すような装置である。鍵管理装置３００は、鍵保管部３１０と、受信機３２０と、センサ３３０と、コントローラ３４０と、データ格納部３５０とを有する。パッシブ型のＩＣ（Integrated Circuit）カードの場合にはＩＣカードを手に持ってかざした上で生体認証を行うと手がふさがってしまうなどの問題があるので、本実施の形態では、電池を保持するアクティブ型のＩＣカード７００（アクティブタグとも呼ぶ）を採用する。センサ３３０は、通常時には、例えばユーザの手のひらから生体情報を読み取る。受信機３２０は、ＩＣカード７００から電波でユーザの識別子（すなわちタグＩＤ）を受信してコントローラ３４０に出力する。コントローラ３４０は、通常時には、受信機３２０からの識別子から特定される照合データと、センサ３３０が読み取った生体情報とが一致すれば、鍵保持部３１０に対して、使用許可通知で許可されたエリアの鍵のロック解除を指示する。鍵保持部３１０は、複数の鍵を保持しており、コントローラ３４０からの指示に応じて、保持している鍵のうち許可されたエリアの鍵を取り出し可能にロック解除する。

図３に鍵管理サーバ１００の構成例を示す。鍵管理サーバ１００は、データ格納部１１０と、警報受信部１２０と、鍵特定部１３０と、エリアデータ格納部１４０と、承認データ生成部１５０と、承認データ格納部１６０と、鍵データ格納部１７０と、制御部１８０と、データ取得部１９０とを有する。

警報受信部１２０は、防災システム２００から、エリアコードを含む警報を受信する。データ取得部１９０は、警報受信部１２０が警報を受信すると、ネットワーク１に接続されている他の装置から所定のデータを取得し、データ格納部１１０に格納する。

本実施の形態では、データ格納部１１０は、例えば図４に示すようなデータを格納する。すなわち、出勤予定データとして、各日の勤務時間帯毎に、勤務者（より具体的には勤務者の識別子）が登録されている。勤務者としては、承認権限者と、被承認者とが区別されて登録されている。本実施の形態では、このように、承認権限者と被承認者との組み合わせが動的に変化する。

エリアデータ格納部１４０は、例えば図５に示すようなデータを格納する。図５の例では、エリアのコードに対応付けて、鍵の識別子（ＩＤ）が登録されている。

鍵特定部１３０は、警報に含まれるエリアコードに対応する鍵ＩＤを、エリアデータ格納部１４０に格納されているデータから特定し、鍵データ格納部１７０に格納する。

承認データ生成部１５０は、警報受信部１２０から通知に応じて、データ格納部１１０に格納されているデータから、承認権限者と被承認者との組み合わせデータを抽出して、承認データ格納部１６０に格納する。

制御部１８０は、承認データ格納部１６０及び鍵データ格納部１７０に格納されているデータを用いて、鍵管理装置３００に対する制御を実施する。例えば、制御部１８０は、鍵管理装置３００に対して、承認データ格納部１６０及び鍵データ格納部１７０に格納されているデータを含む緊急対応通知を送信して、緊急時対応の制御処理を実行させる。この場合、鍵管理装置３００のコントローラ３４０は、受信機３２０によって受信されたユーザの識別子（タグＩＤ）と、承認データとから、緊急対応通知に含まれる鍵ＩＤの鍵のロック解除を行っても良いか否かを判断する。コントローラ３４０は、ロック解除しても良い場合には、鍵保管部３１０に対してロック解除を指示する。

但し、制御部１８０は、鍵管理装置３００から、受信機３２０によって受信されたユーザの識別子を受信し、鍵データ格納部１７０に格納されている鍵ＩＤの鍵の使用許可通知を行うべきか否かを、承認データ格納部１６０に格納されているデータを用いて判断するようにしても良い。

次に、図６乃至図１１を用いて、本実施の形態に係る処理内容を説明する。

まず、警報受信部１２０は、防災システム２００からエリアコードを含む警報通知を受信する（図６：ステップＳ１）。そうすると、警報受信部１２０は、エリアコードを鍵特定部１３０に通知して、鍵特定部１３０は、エリアデータ格納部１４０に格納されているデータに基づき、火災などが発生したと推定されるエリアのための鍵ＩＤを特定する（ステップＳ３）。なお、警報受信部１２０は、データ取得部１９０にも警報通知の受信を通知する場合があり、その場合には、データ取得部１９０は、以下の処理で用いるデータをネットワーク１を介して接続されている他のサーバ等から取得する。また、警報受信部１２０は、承認データ生成部１５０に対しても、警報通知の受信を通知する。

そうすると、承認データ生成部１５０は、本実施の形態に係る承認データ生成処理を実行する（ステップＳ５）。承認データ生成処理については、図７乃至図１１を用いて説明する。

承認データ生成部１５０は、警報通知受信から所定時間内の出勤予定データを、データ格納部１１０から抽出する（図７：ステップＳ２１）。交代勤務の体制に応じて所定時間を可変にしても良い。例えば、２交代制であれば所定期間の長さを中レベル、３交代制以上であれば所定期間の長さを短レベル、それ以外であれば所定期間の長さを長レベルとして、例えば図８のような設定に基づき所定時間を決定するようにしても良い。図８の例では、短レベルであれば１週間分、中レベルであれば１０日分、長レベルであれば半月分が指定されている。

例えば、４月３日０：０２に警報通知を受信した場合、図４の例では、３交代であるから短レベルであり、現在の時間帯（４月３日０：００−８：００）に加えて直前の時間帯（４月２日１６：００−２４：００）から１週間分の出勤予定データを抽出する。なお、現在の時間帯を含めて１週間分の出勤予定データを抽出するようにしても良い。現在の時間帯については、警報通知受信時刻が、時間帯境界付近（例えば前後３０分内）であれば、前の時間帯又は後の時間帯についても現在の時間帯として取り扱うようにしても良い。

次に、承認データ生成部１５０は、抽出された出勤予定データから、現在の被承認者を抽出する（ステップＳ２３）。現在の時間帯における被承認者を抽出するので、上で述べた例では、「渡辺」「松本」が抽出される。警報通知時刻が時間帯境界付近であるから、「佐々木」「後藤」についても抽出するようにしても良い。

さらに、承認データ生成部１５０は、抽出された出勤予定データから、抽出された被承認者に対応する承認権限者を抽出し、それらの組み合わせデータを、承認データ格納部１６０に格納する（ステップＳ２５）。そして処理は呼出元の処理に戻る。

上で述べた例では、図４の範囲であれば、被承認者「渡辺」に対しては承認権限者「和田」及び「鈴木」が抽出され、被承認者「松本」に対しては承認権限者「今井」及び「井上」が抽出される。従って、図９に示すような承認データが格納される。なお、図１０に示すようなタグＩＤとユーザ名との対応付けデータを用いて、承認データをタグＩＤについてのデータに変換しておく。

このような処理の場合、現在の時間帯以外の時間帯についての承認権限者も抽出されるので、承認権限者の数が増加する。従って、一部の承認権限者が警報通知時に不在であっても、承認される可能性が高くなる。但し、本実施の形態では、現在の時間帯以外の時間帯についての承認権限者が勤務時間中であるか否かについては確認していない。

その後の処理は、鍵管理サーバ１００の制御部１８０が主体的に処理を行う場合と、鍵管理装置３００のコントローラ３４０が主体的に処理を行う場合とに分かれる。ここでは後者であるものとする。後者の場合には、制御部１８０は、承認データ格納部１６０に格納された承認データ及び鍵ＩＤ格納部１７０に格納されている鍵ＩＤを含む緊急対応通知を鍵管理装置３００に送信する。なお、前者の場合においても、制御部１８０は、緊急対応通知を鍵管理装置３００に送信して、鍵管理装置３００に対して緊急対応を行わせる。

鍵管理装置３００のコントローラ３４０は、承認データ及び鍵ＩＤを含む緊急対応通知を受信し、データ格納部３５０に格納する。

なお、警報通知があれば、防災システム２００等に含まれる火災報知器などが鳴動するので、本実施の形態では、承認権限者及び被承認者は、緊急対応の必要性について認識することができ、鍵管理装置３００の設置場所に急行するものとする。

鍵管理装置３００の受信機３２０は、承認権限者及び被承認者がアクティブタグ型のＩＣカード７００を保持しているので、所定の範囲内にあるＩＣカード７００からタグＩＤを受信する。受信機３２０は、図１１に示すように受信サイクルＴ毎に、受信したタグＩＤをコントローラ３４０に出力する。コントローラ３４０は、同じ受信サイクルにおいて承認権限者及び被承認者のタグＩＤを受信した場合には、承認権限者によって目視により被承認者に対する認証が行われたものとして、鍵保管部３１０に対して、緊急対応通知に含まれる鍵ＩＤの鍵のロック解除を指示する。図１１の例では、時刻０からＴまでの第１の受信サイクルにおいては、白三角で表される被承認者２名のタグＩＤを受信し、且つ黒三角で表される承認権限者１名のタグＩＤを受信したケースを示している。このような場合、被承認者２名は承認されたものとして、鍵のロック解除が鍵保管部３１０に指示される。

また、本実施の形態では、承認権限者が、鍵管理装置３００から離れてしまった場合においても、近辺にいると考えられる期間（図１１の例では、時刻Ｔから２Ｔ後の時刻３Ｔまで）に、他の被承認者のタグＩＤを受信した場合においても、当該他の被承認者に対しても承認されたものとして、鍵のロック解除が鍵保管部３１０に指示される。鍵毎に担当の被承認者が決まっている場合には、タグＩＤを受信した被承認者が担当する鍵のみがロック解除されるものとする。

但し、承認権限者が鍵管理装置３００の近辺にいるとみなされる期間を経過した後（例えば時刻３Ｔより後）であれば、被承認者のタグＩＤを受信した場合においても、鍵のロック解除は指示されない。すなわち、承認権限者のタグＩＤを読み取った受信サイクル及び所定期間（図１１の例では２Ｔ）分が有効期間となっている。

被承認者は、承認権限者が鍵管理装置３００近辺まで来なければ鍵を取り出せないので、その場に待機することになり、被承認者のタグＩＤは承認権限者が到達するまでは各受信サイクルにおいて受信される。また、承認権限者が鍵管理装置３００の近辺に居続ければ、各受信サイクルにて承認権限者のタグＩＤが受信されるので、有効期間は更新される。

図１１の例では、先に被承認者が鍵管理装置３００に到達しているが、先に承認権限者が到達する場合もある。すなわち、時刻０から時刻Ｔまでに承認権限者のみが到達した場合である。この場合でも有効期間は同じであり、時刻２Ｔから３Ｔまでに鍵管理装置３００に到達した被承認者に対しては鍵のロック解除がなされるが、時刻３Ｔを経過した後に到達した被承認者に対しては鍵のロック解除はされない。

図６の説明に戻って、鍵管理装置３００のコントローラ３４０は、受信機３２０から受け取ったタグＩＤがあれば、承認権限者のタグＩＤを受信したか又は過去に受信した承認権限者のタグＩＤの有効期限内であるか判断する（ステップＳ７）。コントローラ３４０は、受信機３２０からタグＩＤを受け取らない場合には待機する。また、承認権限者のタグＩＤを受信していない場合又は過去に受信した承認権限者のタグＩＤの有効期限内でなければ、処理はステップＳ１１に移行する。一方、承認権限者のタグＩＤを受信した場合又は過去に受信した承認権限者のタグＩＤの有効期限内であれば、コントローラ３４０は、承認データにおいて当該承認権限者に対応付けられている被承認者のタグＩＤが受信されていれば、当該被承認者に対する鍵のロック解除を、鍵保管部３１０に対して指示する（ステップＳ９）。有効期限を管理するため、コントローラ３４０は、承認データ及び鍵ＩＤに加えて、承認権限者のタグＩＤに対応付けて有効期限をデータ格納部３５０に保持しておく。

ステップＳ９の後又はステップＳ７で条件を満たさないと判断された場合には、コントローラ３４０は、緊急対応状態が終了したか判断する（ステップＳ１１）。例えば、緊急対応通知を受信してから所定時間内であるか否か、又は、別途承認権限者などから緊急対応状態の解除が指示されたか否かを判断する。緊急対応状態であれば、処理はステップＳ７に戻る。

一方、緊急対応状態が終了していれば、コントローラ３４０は、緊急対応通知に含まれ且つデータ格納部３５０に格納された承認データ及び鍵ＩＤを破棄する（ステップＳ１３）。そして処理を終了する。

このように、生体認証は省略されているが、承認権限者による目視による承認を行うので問題が無く、速やかに鍵のロック解除を行って、災害等に対する対処を速やかに行うことができるようになる。なお、承認権限者を拡張する処理をも行っているので、たまたま鍵管理装置３００の付近に不在の承認権限者がいても、他の承認権限者によって対応できるようにもなり、この点でも速やかな対処が可能となる。

なお、鍵管理サーバ１００の制御部１８０が、主体となって処理を行う場合には、鍵管理装置３００のコントローラ３４０から、タグＩＤのデータを例えば受信サイクル毎に受信して、上で述べた処理を実行する。そして、条件を満たしている場合には、制御部１８０は、鍵のロック解除の指示を、コントローラ３４０に送信して、コントローラ３４０に鍵保管部３１０へのロック解除指示を行わせる。通信が発生するだけで処理内容については変わらない。

［実施の形態２］
第１の実施の形態では出勤予定データのみを用いて承認データを生成する例を示したが、承認データ生成処理については、以下のような処理を採用しても良い。

具体的には、本実施の形態では、勤怠管理サーバ４００のＤＢ４１０に蓄積される出退勤データを活用する例を示す。従って、データ取得部１９０は、警報通知を受信すると、所定期間分の出退勤データを、勤怠管理サーバ４００から取得して、データ格納部１１０に格納するものとする。

出退勤データは、例えば図１２に示すようなデータである。図１２の例では、出勤時刻又は退勤時刻（あわせて打刻時間）に対応付けて、出勤又は退勤したユーザのＩＤが登録されるようになっている。

以下、本実施の形態に係る承認データ生成処理について、図１３乃至図１９を用いて説明する。

承認データ生成部１５０は、警報通知受信から所定時間内の出勤予定データを、データ格納部１１０から抽出する（図１３：ステップＳ３１）。本ステップはステップＳ２１と同様である。

また、承認データ生成部１５０は、データ格納部１１０に格納されている出退勤データから、現在出勤中のユーザを抽出する（ステップＳ３３）。例えば、前日の出退勤データのうち、出勤したユーザの集合を生成した後、退勤が確認できたユーザを除外することで、現在出勤中のユーザを抽出する。

例えば、４月３日０：０２に警報通知がなされる例では、「和田」「渡辺」「松本」「今井」に加えて、直前の勤務時間帯に勤務している「佐々木」「後藤」「井上」「藤田」についても出勤中ユーザとして特定される。

そして、承認データ生成部１５０は、現在出勤中の被承認者に対応する出勤中の承認権限者を、ステップＳ３１で抽出された出勤予定データから抽出し、被承認者と承認権限者との組み合わせを、仮の承認データとして生成する（ステップＳ３５）。

具体的には、例えば出勤予定データから被承認者と承認権限者との組み合わせを抽出した上で、被承認者と承認権限者の両方が出勤中ユーザとなっていない組み合わせを破棄することで、仮の承認データを生成する。その他にも、現在出勤中の被承認者を特定した上で、対応する承認権限者が現在出勤中であるか否かを判断することで、組み合わせを抽出するような処理を行うようにしても良い。

この例では、図１４に示すような仮の承認データが生成されることになる。図９と比較すると、被承認者が増加しているが、被承認者「渡辺」の承認権限者が現在出勤中の「和田」のみに限定されている。

なお、変形例として、被承認者のみ現在出勤中であることを要件として、承認権限者については現在出勤中であるか否かを要件としないようにしても良い。この方が処理が簡単になる。この場合、図１５に示すような仮の承認データが生成される。承認権限者の数が増加していることが分かる。

そして、承認データ生成部１５０は、除外処理を実行するか否かを判断する（ステップＳ３７）。例えば、除外処理実行のためのフラグがセットされているか否かで判断する。除外処理を実行しない場合には、処理はステップＳ４０に移行する。

一方、除外処理を実行する場合には、承認データ生成部１５０は、除外処理を実行する（ステップＳ３９）。除外処理については、図１６乃至図１９を用いて説明する。

まず、承認データ生成部１５０は、除外者リスト生成処理を実行する（図１６：ステップＳ４１）。除外者リスト生成処理については、図１７を用いて説明する。

承認データ生成部１５０は、現時刻から所定期間内の鍵不正利用者を特定する（ステップＳ５１）。例えば、データ格納部１１０に、図１８に示すようなリストを保持しておく。図１８の例では、違反日と違反者とが登録されており、例えば現在時刻から１週間以内であれば、採用する。このようなリストについては、手入力で管理しても良いし、承認せずという鍵貸出ログから抽出するようにしても良い。

また、承認データ生成部１５０は、鍵利用についての熟練度が閾値未満の利用者を特定する（ステップＳ５３）。

例えば、鍵貸出ログ及び出退勤データ等から、例えば図１９に示すような熟練度管理テーブルを別途生成しておく。図１９の例では、タグＩＤと、ユーザと、鍵使用回数と、勤務時間と、熟練度とが登録されるようになっている。本実施の形態では、所定期間（例えば１月）における鍵使用回数と、所定期間（例えば１月）における勤務時間との比を、熟練度として規定している。従って、鍵貸出ログから鍵使用回数を計数し、出退勤データから勤務時間を計算する。そして、閾値についても予め設定しておく。例えば閾値＝０．１であれば、図１９の例においては該当するユーザは存在しない。

以上のように特定されたユーザが、除外リストに登録されることになる。

図１６の処理の説明に戻って、承認データ生成部１５０は、仮の承認データにおける未処理の被承認者を一人特定する（ステップＳ４３）。そして、承認データ生成部１５０は、特定された被承認者が、除外リストに登録されているか判断する（ステップＳ４５）。登録されていない場合には、処理はステップＳ４９に移行する。

一方、特定された被承認者が、除外リストに登録されていれば、承認データ生成部１５０は、仮の承認データから、特定された被承認者についてのデータを削除する（ステップＳ４７）。そしてステップＳ４９に処理は移行する。

その後、承認データ生成部１５０は、仮の承認データにおいて未処理の被承認者が存在するか判断する（ステップＳ４９）。未処理の被承認者が存在する場合には、処理はステップＳ４３に戻る。一方、未処理の被承認者が存在しない場合には、呼出元の処理に戻る。

以上のような処理を実行することで、鍵の不正利用者が存在していれば、緊急時に応じて不正を行う可能性があるので除外することができ、また鍵利用の熟練度が低い者については通常どおりの承認フローを行うことで、問題ある鍵の使用を防止できるようになる。

図１３の処理の説明に戻って、承認データ生成部１５０は、仮の承認データを承認データとして、承認データ格納部１６０に格納する（ステップＳ４０）。そして、処理は呼出元の処理に戻る。

以上のような処理を行うことで、勤務実態に応じた承認データが生成できる。また、緊急時対応が不適切な被承認者については緊急時対応しないようにして、通常どおりの承認フローを行うことで、不適切な対応の発生を防止できるようになる。

［実施の形態３］
上で述べた実施の形態で用いられる出勤予定データが警報通知受信時に取得不可能なケースがある。一方、鍵管理サーバ１００は、図２０に示すような鍵貸出ログを生成して、例えばデータ格納部１１０に格納する。図２０の例では、申請及び承認結果と利用結果とが、申請及び承認が行われる毎に登録されるようになっている。申請及び承認結果には、申請を行った被承認者の識別子と、利用する鍵のＩＤと、申請時刻と、承認権限者の識別子と、承認時刻（承認されない場合には否認を表すデータが含まれる場合もある）とが含まれる。また、利用結果については、取り出し許可された鍵のＩＤと、許可時刻と、利用者（＝被承認者＝認証されるユーザ）の識別子と、認証時刻と、取り出された鍵のＩＤとが含まれる。

従って、本実施の形態では、出勤予定データが使用できない場合に対応するために、図２１に示すような承認データ生成処理を実行する。

承認データ生成部１５０は、所定期間内の鍵貸出ログを、例えばデータ格納部１１０から抽出する（ステップＳ６１）。

そして、承認データ生成部１５０は、抽出した鍵貸出ログから、承認された場合についての被承認者と承認権限者との組み合わせを抽出し、承認データ格納部１６０に格納する（ステップＳ６３）。

第１及び第２の実施の形態では、現在出勤中又は出勤中であると思われる被承認者をベースに承認権限者を抽出していたが、出勤予定データが取得できなければそのような判断は難しいので、被承認者と承認権限者との組み合わせを全て抽出する。

但し、出退勤データが取得できた場合には、第２の実施の形態のように、現在出勤中のユーザについての組み合わせに限定しても良い。

以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、図２の機能ブロック構成は、プログラムモジュール構成とは一致しない場合もある。さらに、処理フローについても、処理結果が変わらない限り、処理順番を入れ替えたり、複数のステップを並列実行するようにしても良い。

さらに図１に示したシステム構成例についても一例であり、１台の装置が有するとされた機能を複数台の装置で分担することもある。さらに、複数台の装置にて実現されるとされた装置についても１台の装置によって実現される場合もある。

なお、上で述べた防災システム２００、鍵管理サーバ１００、勤怠管理サーバ４００、承認権限者端末５００及び被承認者端末６００等は、例えばコンピュータ装置であって、図２２に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態に係る鍵管理システムは、（Ａ）承認権限者群のうち１又は複数の承認権限者と鍵の被承認者群のうち１又は複数の被承認者との過去の組み合わせを表すデータ又は過去及び現在の組み合わせを表すデータを格納するデータ格納部と、（Ｂ）警報を受信すると、当該警報に係るエリアの鍵を特定する特定部と、（Ｃ）データ格納部から、第１の所定期間内における、第１又は複数の承認権限者と１又は複数の被承認者との組み合わせを抽出する抽出部と、（Ｄ）抽出された組み合わせに含まれる承認権限者の識別情報と、当該組み合わせに含まれる被承認者の識別情報とが第２の所定期間内において入力されると、特定された鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する制御部とを有する。

このようにすれば、緊急時においても速やかに鍵の使用について承認を行うことができる。すなわち、承認権限者を増加させることで承認される確率を向上させ、承認権限者の目視を原理的に要求して機械的な認証処理を簡略化することで、緊急対応を速やかに行わせることができるようになる。さらに、交代勤務で、承認権限者と被承認者との組み合わせが動的に変化する場合にも対処できるようになる。

また、上で述べたデータ格納部が、１又は複数の承認権限者と１又は複数の被承認者との組み合わせを含む出勤予定データを格納する格納部である場合もある。この場合、上で述べた抽出部が、データ格納部から、現在の出勤予定データに含まれる被承認者を特定し、データ格納部から、特定された被承認者と第１の所定期間内に組み合わされた承認権限者を抽出するようにしても良い。出勤予定データを用いることで、出勤予定に従って適切な被承認者を抽出でき、さらに現在だけでなかく過去の承認権限者をも候補として抽出できるようになる。

また、上で述べたデータ格納部が、１又は複数の承認権限者と１又は複数の被承認者との組み合わせを含む出勤予定データを格納しており、さらにユーザの出退勤のデータを格納している場合もある。この場合、上で述べた抽出部が、ユーザの出退勤のデータから、現在出勤中のユーザを抽出し、第１のデータ格納部から、抽出された現在出勤中のユーザのうち被承認者を特定し、第１の所定期間内に当該被承認者と組み合わされている承認権限者を抽出するようにしても良い。このようにすれば、出勤予定だけでなく実体の勤務状態に応じて、被承認者と承認権限者との組み合わせを抽出できるようになる。また、承認権限者についても出勤中の承認権限者に限定しても良い。

さらに、上で述べたデータ格納部が、承認権限者が被承認者に対して鍵の取り出しを許可したことを表すログを格納する格納部である場合もある。この場合、上で述べた抽出部が、データ格納部から、第１の所定期間内におけるログに含まれる承認権限者と被承認者との組み合わせを抽出するようにしても良い。

また、上で述べた抽出部が、抽出されたデータに含まれる被承認者のうち、除外リストに含まれる被承認者を除外するようにしても良い。不適切な被承認者については緊急対応でも通常どおりの承認フローを適用するためである。

なお、上で述べた除外リストが、第３の所定期間内に鍵を不正利用した被承認者と、所定のルールに従って算出される、鍵使用の熟練度が閾値未満の被承認者とのうち少なくともいずれかを含むようにしても良い。

さらに、本システムが、アクティブタグから識別情報を受信する受信部をさらに有するようにしても良い。この場合、上で述べた制御部が、受信部による承認権限者の識別情報の受信タイミングに応じて設定される有効期限内に、当該承認権限者に組み合わせられている被承認者の識別情報が受信部により受信された場合に、特定された鍵の取り出しが当該被承認者により可能になるように、上記鍵保管部を制御するようにしても良い。アクティブタグを用いることによって、より速やかに緊急時対応ができるようになる。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
刑事施設における鍵管理システムであって、
承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部と、
タグから識別情報を受信する受信部と、
警報を受信すると、当該警報に係るエリアの鍵を特定する特定部と、
前記受信部が前記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された前記鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する制御部と、
を有する鍵管理システム。

（付記２）
前記データ格納部が、前記承認権限者の識別情報と前記被承認者の識別情報との複数の組み合わせを含む出勤予定データを格納するデータ格納部である
付記１記載の鍵管理システム。

（付記３）
前記データ格納部が、承認権限者が被承認者に対して鍵の取り出しを許可したことを表すログを格納するデータ格納部である
付記１記載の鍵管理システム。

（付記４）
前記データに含まれる被承認者のうち、鍵を不正利用した被承認者と、所定のルールに従って算出される、鍵使用の熟練度が閾値未満の被承認者とのうち少なくともいずれかの被承認者の識別番号を受信しても、特定された前記鍵の取り出しは不可のままであるように、鍵を保管する鍵保管部を制御する
付記１乃至３のいずれか１つ記載する鍵管理システム。

（付記５）
前記制御部が、
前記受信部による承認権限者の識別情報の受信タイミングに応じて設定される有効期限内に、当該承認権限者に組み合わせられている被承認者の識別情報が前記受信部により受信された場合に、特定された前記鍵の取り出しが当該被承認者により可能になるように、前記鍵保管部を制御する
付記１乃至４のいずれか１つ記載の鍵管理システム。

（付記６）
警報を受信すると、当該警報に係るエリアの鍵を特定し、
承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部における前記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された前記鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する
処理を含み、コンピュータにより実行される鍵管理方法。

（付記７）
警報を受信すると、当該警報に係るエリアの鍵を特定し、
承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部における前記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された前記鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する
処理を、コンピュータに実行させるための鍵管理プログラム。

１００ 鍵管理サーバ
２００ 防災システム
３００ 鍵管理装置
４００ 勤怠管理サーバ
５００ 承認権限者端末
６００ 被承認者端末
１１０ データ格納部
１２０ 警報受信部
１３０ 鍵特定部
１４０ エリアデータ格納部
１５０ 承認データ生成部
１６０ 承認データ格納部
１７０ 鍵データ格納部
１８０ 制御部
３１０ 鍵保管部
３２０ 受信機
３３０ センサ
３４０ コントローラ

Claims (7)

1. 承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部と、
   承認権限者又は被承認権限者の識別情報を格納するＩＣから、当該ＩＣが所定の範囲内に入った場合に、前記承認権限者又は被承認権限者の識別情報を受信する受信部と、
   警報を受信すると、当該警報に係るエリアの鍵を特定する特定部と、
   前記受信部が前記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された前記鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する制御部と、
   を有する鍵管理システム。
2. 前記データ格納部が、前記承認権限者の識別情報と前記被承認者の識別情報との複数の組み合わせを含む出勤予定データを格納するデータ格納部である
   請求項１記載の鍵管理システム。
3. 前記データ格納部が、承認権限者が被承認者に対して鍵の取り出しを許可したことを表すログを格納するデータ格納部である
   請求項１記載の鍵管理システム。
4. 前記制御部が、
   前記データに含まれる被承認者のうち、鍵を不正利用した被承認者と、所定のルールに従って算出される、鍵使用の熟練度が閾値未満の被承認者とのうち少なくともいずれかの被承認者の識別番号を受信しても、特定された前記鍵の取り出しは不可のままであるように、前記鍵保管部を制御する
   請求項１乃至３のいずれか１つ記載の鍵管理システム。
5. 前記制御部が、
   前記受信部による承認権限者の識別情報の受信タイミングに応じて設定される有効期限内に、当該承認権限者に組み合わせられている被承認者の識別情報が前記受信部により受信された場合に、特定された前記鍵の取り出しが当該被承認者により可能になるように、前記鍵保管部を制御する
   請求項１乃至４のいずれか１つ記載の鍵管理システム。
6. 警報を受信すると、当該警報に係るエリアの鍵を特定し、
   承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部における前記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された前記鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する
   処理を含み、コンピュータにより実行される鍵管理方法。
7. 警報を受信すると、当該警報に係るエリアの鍵を特定し、
   承認権限者の識別情報と被承認者の識別情報の組み合わせを表すデータを格納するデータ格納部における前記組み合わせに含まれる承認権限者及び被承認者の識別情報を受信すると、特定された前記鍵の取り出しが可能になるように、鍵を保管する鍵保管部を制御する
   処理を、コンピュータに実行させるための鍵管理プログラム。

Images