ホーム > 特許ランキング > 株式会社デンソーウェーブ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-04
(45)【発行日】2024-06-12
(54)【発明の名称】管理システム
(51)【国際特許分類】
E05B 49/00 20060101AFI20240605BHJP
G07C 9/27 20200101ALI20240605BHJP
【ＦＩ】
E05B49/00 J
G07C9/27
【請求項の数】
5
(21)【出願番号】P 2021020812
(22)【出願日】2021-02-12
(65)【公開番号】P2022123477
(43)【公開日】2022-08-24
【審査請求日】2023-07-24
(73)【特許権者】
【識別番号】501428545
【氏名又は名称】株式会社デンソーウェーブ
(74)【代理人】
【識別番号】110000110
【氏名又は名称】弁理士法人 快友国際特許事務所
(72)【発明者】
【氏名】清水 敏雄
(72)【発明者】
【氏名】荻原 和也
【審査官】野尻 悠平
(56)【参考文献】
【文献】特開２０１２－２１９５７６（ＪＰ，Ａ）
【文献】特開平０３－１５４９９１（ＪＰ，Ａ）
【文献】特開２０１４－２１４４７７（ＪＰ，Ａ）
【文献】特開２００８－２９７８０４（ＪＰ，Ａ）
【文献】特開２０１１－１８４９７７（ＪＰ，Ａ）
【文献】特開２０１９－２１９８４３（ＪＰ，Ａ）
【文献】実開昭６３－０９４２８４（ＪＰ，Ｕ）
【文献】米国特許出願公開第２０１６／００９２６６６（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１３／００９３５６３（ＵＳ，Ａ１）
【文献】特開２０１３－０８９２４２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｅ０５Ｂ １／００－８５／２８
Ｇ０７Ｃ ９／２７
(57)【特許請求の範囲】
【請求項1】
所定の領域の出入口に設けられているドアを施錠可能な電気錠と、
前記所定の領域の外側に設けられており、前記所定の領域に進入するユーザから当該ユーザを示すユーザ情報を取得するための外側取得装置と、
前記所定の領域の内側に設けられており、前記所定の領域から退出するユーザから当該ユーザを示すユーザ情報を取得するための内側取得装置と、
前記電気錠と前記外側取得装置と前記内側取得装置と通信可能な通信装置と、を備え、
前記通信装置は、
前記外側取得装置及び前記内側取得装置のうちのいずれかから受信した前記ユーザ情報を利用したアンチパスバック方式の判断を実行して、前記ユーザの進入又は退出を許可することと、前記ユーザの進入又は退出を許可しないことと、のいずれかを決定する決定部と、
前記ドアが閉じている場合において、前記判断で前記ユーザの進入又は退出が許可されるときに、解錠の指示を前記電気錠に送信する解錠送信部と、
前記ユーザが前記ドアを開いた後に前記ドアが閉じられる場合に、施錠の指示を前記電気錠に送信する施錠送信部と、
第１のユーザが前記ドアを開けた後で前記ドアが閉じられる前に、前記外側取得装置及び前記内側取得装置のうちのいずれかから第２のユーザを示す前記ユーザ情報が受信されて、前記判断で前記第２のユーザの進入又は退出が許可される場合に、所定の時間のカウントを開始するカウント部であって、前記所定の時間のカウントが終了するまでは、前記ドアが閉じられても、前記施錠の指示は、前記電気錠に送信されない、前記カウント部と、を備え、
前記外側取得装置及び前記内側取得装置のうちの特定の取得装置が前記第１のユーザから前記第１のユーザを示す前記ユーザ情報を取得し、
前記特定の取得装置が前記第２のユーザから前記第２のユーザを示す前記ユーザ情報を続けて取得し、
前記第１のユーザが前記ドアを開いた後で前記ドアが閉じられる前に、前記特定の取得装置から前記第２のユーザを示す前記ユーザ情報を受信することに起因して、前記所定の時間のカウントが開始された後に、前記所定の時間のカウントが終了することなく、前記特定の取得装置が第３のユーザから前記第３のユーザを示す前記ユーザ情報をさらに続けて取得する場合において、前記判断で前記第３のユーザの進入又は退出が許可されるときに、前記カウント部は、前記所定の時間のカウントをリセットする、
管理システム。
【請求項2】
所定の領域の出入口に設けられているドアを施錠可能な電気錠と、
前記所定の領域の外側に設けられており、前記所定の領域に進入するユーザから当該ユーザを示すユーザ情報を取得するための外側取得装置と、
前記所定の領域の内側に設けられており、前記所定の領域から退出するユーザから当該ユーザを示すユーザ情報を取得するための内側取得装置と、
前記電気錠と前記外側取得装置と前記内側取得装置と通信可能な通信装置と、を備え、
前記通信装置は、
前記外側取得装置及び前記内側取得装置のうちのいずれかから受信した前記ユーザ情報を利用したアンチパスバック方式の判断を実行して、前記ユーザの進入又は退出を許可することと、前記ユーザの進入又は退出を許可しないことと、のいずれかを決定する決定部と、
前記ドアが閉じている場合において、前記判断で前記ユーザの進入又は退出が許可されるときに、解錠の指示を前記電気錠に送信する解錠送信部と、
前記ユーザが前記ドアを開いた後に前記ドアが閉じられる場合に、施錠の指示を前記電気錠に送信する施錠送信部と、
第１のユーザが前記ドアを開けた後で前記ドアが閉じられる前に、前記外側取得装置及び前記内側取得装置のうちのいずれかから第２のユーザを示す前記ユーザ情報が受信されて、前記判断で前記第２のユーザの進入又は退出が許可される場合に、所定の時間のカウントを開始するカウント部であって、前記所定の時間のカウントが終了するまでは、前記ドアが閉じられても、前記施錠の指示は、前記電気錠に送信されない、前記カウント部と、を備え、
前記外側取得装置及び前記内側取得装置のうちの特定の取得装置が前記第１のユーザから前記第１のユーザを示す前記ユーザ情報を取得し、
前記特定の取得装置が前記第２のユーザから前記第２のユーザを示す前記ユーザ情報を続けて取得し、
前記第１のユーザが前記ドアを開いた後で前記ドアが閉じられる前に、前記特定の取得装置から前記第２のユーザを示す前記ユーザ情報を受信することに起因して、前記所定の時間のカウントが開始された後に、前記所定の時間のカウントが終了することなく、前記特定の取得装置が第３のユーザから前記第３のユーザを示す前記ユーザ情報をさらに続けて取得する場合において、前記判断で前記第３のユーザの進入又は退出が許可されるときに、前記カウント部は、所定の値を上限値として前記所定の時間を延長する、
管理システム。
【請求項3】
所定の領域の出入口に設けられているドアを施錠可能な電気錠と、
前記所定の領域の外側に設けられており、前記所定の領域に進入するユーザから当該ユーザを示すユーザ情報を取得するための外側取得装置と、
前記所定の領域の内側に設けられており、前記所定の領域から退出するユーザから当該ユーザを示すユーザ情報を取得するための内側取得装置と、
前記電気錠と前記外側取得装置と前記内側取得装置と通信可能な通信装置と、を備え、
前記通信装置は、
前記外側取得装置及び前記内側取得装置のうちのいずれかから受信した前記ユーザ情報を利用したアンチパスバック方式の判断を実行して、前記ユーザの進入又は退出を許可することと、前記ユーザの進入又は退出を許可しないことと、のいずれかを決定する決定部と、
前記ドアが閉じている場合において、前記判断で前記ユーザの進入又は退出が許可されるときに、解錠の指示を前記電気錠に送信する解錠送信部と、
前記ユーザが前記ドアを開いた後に前記ドアが閉じられる場合に、施錠の指示を前記電気錠に送信する施錠送信部と、
第１のユーザが前記ドアを開けた後で前記ドアが閉じられる前に、前記外側取得装置及び前記内側取得装置のうちのいずれかから第２のユーザを示す前記ユーザ情報が受信されて、前記判断で前記第２のユーザの進入又は退出が許可される場合に、所定の時間のカウントを開始するカウント部であって、前記所定の時間のカウントが終了するまでは、前記ドアが閉じられても、前記施錠の指示は、前記電気錠に送信されない、前記カウント部と、
前記所定の時間をカウントした回数が所定の回数を上回る場合に、警告を報知する報知部と、
を備える、管理システム。
【請求項4】
所定の領域の出入口に設けられているドアを施錠可能な電気錠と、
前記所定の領域の外側に設けられており、前記所定の領域に進入するユーザから当該ユーザを示すユーザ情報を取得するための外側取得装置と、
前記所定の領域の内側に設けられており、前記所定の領域から退出するユーザから当該ユーザを示すユーザ情報を取得するための内側取得装置と、
前記電気錠と前記外側取得装置と前記内側取得装置と通信可能な通信装置と、を備え、
前記通信装置は、
前記外側取得装置及び前記内側取得装置のうちのいずれかから受信した前記ユーザ情報を利用したアンチパスバック方式の判断を実行して、前記ユーザの進入又は退出を許可することと、前記ユーザの進入又は退出を許可しないことと、のいずれかを決定する決定部と、
前記ドアが閉じている場合において、前記判断で前記ユーザの進入又は退出が許可されるときに、解錠の指示を前記電気錠に送信する解錠送信部と、
前記ユーザが前記ドアを開いた後に前記ドアが閉じられる場合に、施錠の指示を前記電気錠に送信する施錠送信部と、
前記ユーザが前記ドアを開いた後に前記ドアが閉じられ、前記施錠の指示が前記電気錠に送信される場合に、前記判断で利用されるフラグ値を変更する第１の変更部と、
前記判断において前記ユーザの進入又は退出が許可されて、前記解錠の指示が前記電気錠に送信された後に、前記ドアが開いている状態が所定の上限時間を上回って継続する場合に、前記フラグ値を変更する第２の変更部と、
第１のユーザが前記ドアを開けた後で前記ドアが閉じられる前に、前記外側取得装置及び前記内側取得装置のうちのいずれかから第２のユーザを示す前記ユーザ情報が受信されて、前記判断で前記第２のユーザの進入又は退出が許可される場合に、所定の時間のカウントを開始するカウント部であって、前記所定の時間のカウントが終了するまでは、前記ドアが閉じられても、前記施錠の指示は、前記電気錠に送信されない、前記カウント部と、
を備える、管理システム。
【請求項5】
前記外側取得装置及び前記内側取得装置のうちの一方の取得装置が前記第１のユーザから前記第１のユーザを示す前記ユーザ情報を取得し、前記外側取得装置及び前記内側取得装置のうちの他方の取得装置が前記第２のユーザから前記第２のユーザを示す前記ユーザ情報を取得し、
前記一方の取得装置が前記第１のユーザを示す前記ユーザ情報を取得するタイミングと、前記他方の取得装置が前記第２のユーザを示す前記ユーザ情報を取得するタイミングと、の間の時間差が所定の閾値を上回る場合に、前記カウント部は、第１の時間である前記所定の時間のカウントを開始し、
前記時間差が前記所定の閾値を下回る場合に、前記カウント部は、前記第１の時間よりも長い第２の時間である前記所定の時間のカウントを開始する、請求項１から４のいずれか一項に記載の管理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書で開示する技術は、アンチパスバック方式を利用した管理システムに関する。
【背景技術】
【0002】
特許文献１には、アンチパスバック方式を利用した管理システムが開示されている。例えば、アンチパスバック方式を利用した管理において、二者がほぼ同じタイミングで認証操作を行い、一方の者が扉を開けた後、他方の者が入室又は退出する前に扉を閉めてしまった場合には、ドアが施錠され、他方の者の入室又は退出が不可能である事態が発生する。特許文献１の管理システムは、このような事態の発生時において、例外的な措置を実行する。例外的な措置では、管理システムは、他方の者による認証操作に応じた再照合を許可して、ドアを解錠する。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００６－１３８０８０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記の技術では、入室又は退出が不可能となった他方の者は、ドアを解錠するために、再び認証操作を行う必要がある。ユーザは不便に感じ得る。
【0005】
本明細書では、ユーザの利便性を向上させるための技術を提供する。
【課題を解決するための手段】
【0006】
本明細書で開示する管理システムは、所定の領域の出入口に設けられているドアを施錠可能な電気錠と、前記所定の領域の外側に設けられており、前記所定の領域に進入するユーザから当該ユーザを示すユーザ情報を取得するための外側取得装置と、前記所定の領域の内側に設けられており、前記所定の領域から退出するユーザから当該ユーザを示すユーザ情報を取得するための内側取得装置と、前記電気錠と前記外側取得装置と前記内側取得装置と通信可能な通信装置と、を備え、前記通信装置は、前記外側取得装置及び前記内側取得装置のうちのいずれかから受信した前記ユーザ情報を利用したアンチパスバック方式の判断を実行して、前記ユーザの進入又は退出を許可することと、前記ユーザの進入又は退出を許可しないことと、のいずれかを決定する決定部と、前記ドアが閉じている場合において、前記判断で前記ユーザの進入又は退出が許可されるときに、解錠の指示を前記電気錠に送信する解錠送信部と、前記ユーザが前記ドアを開いた後に前記ドアが閉じられる場合に、施錠の指示を前記電気錠に送信する施錠送信部と、第１のユーザが前記ドアを開けた後で前記ドアが閉じられる前に、前記外側取得装置及び前記内側取得装置のうちのいずれかから第２のユーザを示す前記ユーザ情報が受信されて、前記判断で前記第２のユーザの進入又は退出が許可される場合に、所定の時間のカウントを開始するカウント部であって、前記所定の時間のカウントが終了するまでは、前記ドアが閉じられても、前記施錠の指示は、前記電気錠に送信されない、前記カウント部と、を備える。
【0007】
このような構成によれば、所定の時間のカウントが終了するまでは、ドアが閉じられても、施錠の信号は電気錠に送信されない。即ち、ドアが閉じられても、第２のユーザからユーザ情報を再び取得しなくても、所定の時間に亘ってドアの解錠が維持されて、第２のユーザの進入又は退出が許可される。ユーザ情報を内側又は外側の取得装置に再び取得させることが不要となり、ユーザの利便性を向上することができる。例えば、第１のユーザの進入に続けて第２のユーザが退出する状況において、第２のユーザの退出が許可されない事態の発生を抑制することができる。また、例えば、第１のユーザの進入に続けて第２のユーザが進入する状況において、第２のユーザの進入が許可されない事態の発生を抑制することができる。
【0008】
前記外側取得装置及び前記内側取得装置のうちの一方の取得装置が前記第１のユーザから前記第１のユーザを示す前記ユーザ情報を取得し、前記外側取得装置及び前記内側取得装置のうちの他方の取得装置が前記第２のユーザから前記第２のユーザを示す前記ユーザ情報を取得し、前記一方の取得装置が前記第１のユーザを示す前記ユーザ情報を取得するタイミングと、前記他方の取得装置が前記第２のユーザを示す前記ユーザ情報を取得するタイミングと、の間の時間差が所定の閾値を上回る場合に、前記カウント部は、第１の時間である前記所定の時間のカウントを開始し、前記時間差が前記所定の閾値を下回る場合に、前記カウント部は、前記第１の時間よりも長い第２の時間である前記所定の時間のカウントを開始してもよい。
【0009】
上記の時間差が所定の閾値を下回ることは、例えば、第１のユーザの進入と第２のユーザの退出がほぼ同時に行われることを意味する。この場合には、両者が入れ違いとなり、一方のユーザによって他方のユーザの進入又は退出が妨げられる可能性がある。他方のユーザの進入又は退出が妨げられると、一方のユーザがドアを閉めてから他方のユーザがドアを開けるまでの時間が比較的長くなる。この場合、他方のユーザがドアを開ける迄に所定の時間のカウントが終了する可能性がある。上記の構成によれば、上記の時間差が所定の閾値を下回る場合には、比較的長い第２の時間でカウントが開始される。これにより、他方のユーザがドアを開ける迄に所定の時間のカウントが終了することを抑制することができる。一方で、上記の時間差が所定の閾値を上回る場合には、比較的短い第１の時間でカウントが開始される。両者の入れ違いが発生し難い状況において、ドアが施錠されない時間を短くすることができる。
【0010】
前記外側取得装置及び前記内側取得装置のうちの特定の取得装置が前記第１のユーザから前記第１のユーザを示す前記ユーザ情報を取得し、前記特定の取得装置が前記第２のユーザから前記第２のユーザを示す前記ユーザ情報を続けて取得し、前記第１のユーザが前記ドアを開いた後で前記ドアが閉じられる前に、前記特定の取得装置から前記第２のユーザを示す前記ユーザ情報を受信することに起因して、前記所定の時間のカウントが開始された後に、前記所定の時間のカウントが終了することなく、前記特定の取得装置が第３のユーザから前記第３のユーザを示す前記ユーザ情報をさらに続けて取得する場合において、前記判断で前記第３のユーザの進入又は退出が許可されるときに、前記カウント部は、前記所定の時間のカウントをリセットしてもよい。
【0011】
例えば、複数のユーザが、所定の領域に続けて進入する状況が想定される。このような状況では、ドアが開いている状態が継続する可能性がある。仮に、所定の時間のカウントの終了後でもドアが開いている場合において、第３のユーザが所定の領域に進入する前に第２のユーザがドアを閉めると、第３のユーザが所定の領域に進入する前に、ドアが施錠され得る。上記の構成によれば、第３のユーザの進入又は退出が許可されるときに、所定の時間のカウントがリセットされる。これにより、第３のユーザが所定の領域に進入する前に第２のユーザがドアを閉めても、所定の時間のカウントがリセットされて終了していない。所定の時間のカウントが終了せずにドアが施錠されないので、第３のユーザが所定の領域に進入できない事態が発生することを抑制することができる。なお、複数のユーザが、所定の領域から続けて退出する状況でも、同様に、第３のユーザが所定の領域から退出できない事態が発生することを抑制することができる。
【0012】
前記外側取得装置及び前記内側取得装置のうちの特定の取得装置が前記第１のユーザから前記第１のユーザを示す前記ユーザ情報を取得し、前記特定の取得装置が前記第２のユーザから前記第２のユーザを示す前記ユーザ情報を続けて取得し、前記第１のユーザが前記ドアを開いた後で前記ドアが閉じられる前に、前記特定の取得装置から前記第２のユーザを示す前記ユーザ情報を受信することに起因して、前記所定の時間のカウントが開始された後に、前記所定の時間のカウントが終了することなく、前記特定の取得装置が第３のユーザから前記第３のユーザを示す前記ユーザ情報をさらに続けて取得する場合において、前記判断で前記第３のユーザの進入又は退出が許可されるときに、前記カウント部は、所定の値を上限値として前記所定の時間を延長してもよい。
【0013】
この構成では、第３のユーザの進入又は退出が許可されるときに、所定の時間が延長される。これにより、第３のユーザが所定の領域に進入又は退出する前に第２のユーザがドアを閉めても、所定の時間が延長されてカウントが終了していない。所定の時間のカウントが終了せずにドアが施錠されないので、第３のユーザが所定の領域に進入又は退出できない事態が発生することを抑制することができる。また、所定の時間の延長には、上限値が設定されている。ドアが施錠されない時間が不必要に延長されることを抑制することができる。
【0014】
前記通信装置は、さらに、前記所定の時間をカウントした回数が所定の回数を上回る場合に、警告を報知する報知部を備えてもよい。
【0015】
所定の時間をカウントする回数が所定の回数を上回る場合には、ドアが正常に閉まらない状態が発生している可能性が高いことを意味する。上記の構成によれば、ドアが正常に閉まらない状態が発生している可能性が高い場合に、警告を報知することができる。
【0016】
前記通信装置は、さらに、前記ユーザが前記ドアを開いた後に前記ドアが閉じられ、前記施錠の指示が前記電気錠に送信される場合に、前記判断で利用されるフラグ値を変更する第１の変更部と、前記判断において前記ユーザの進入又は退出が許可されて、前記解錠の指示が前記電気錠に送信された後に、前記ドアが開いている状態が所定の上限時間を上回って継続する場合に、前記フラグ値を変更する第２の変更部と、を備えてもよい。
【0017】
一般に、アンチパスバック方式では、施錠の指示が電気錠に送信される場合に、フラグ値が変更される。しかし、仮に、ドアが開いている状態が長時間継続して、フラグ値が変更されないままとなると、進入が許可されたユーザが進入後に退出する場合に、フラグ値が変更されていないことに起因して、アンチパスバック方式の判断が正常に行われない可能性がある。上記の構成によれば、ドアが開いている状態が所定の上限時間を上回って継続する場合に、フラグ値を強制的に変更する。フラグ値が変更されていないことに起因して、アンチパスバック方式の判断が正常に行われないことを抑制することができる。
【0018】
また、管理システムの制御方法も新規で有用である。また、上記の通信装置それ自体、通信装置の制御方法、通信装置のためのコンピュータプログラム、及び、当該コンピュータプログラムを保存する記憶媒体も、新規で有用である。
【図面の簡単な説明】
【0019】
【図1】管理システムの構成を示す。
【図2】管理システムのブロック図を示す。
【図3】アンチパスバック方式の概要を示す。
【図4】アンチパスバック方式における問題点の概要を示す。
【図5】アンチパスバック方式における問題点の概要を示す。
【図6】各実施例の入退判断処理のフローチャートを示す。
【図7】各実施例の施錠処理のフローチャートを示す。
【図8】第１実施例のタイマ処理のフローチャートを示す。
【図9】各実施例の異常判断処理のフローチャートを示す。
【図10】入退判断処理と施錠処理によって実現される具体的なケースを示す。
【図11】入退判断処理と施錠処理によって実現される具体的なケースを示す。
【図12】第２実施例のタイマ処理のフローチャートを示す。
【図13】第３実施例のタイマ処理のフローチャートを示す。
【図14】第４実施例のタイマ処理のフローチャートを示す。
【発明を実施するための形態】
【0020】
（第１実施例）
（管理システム２の構成：図１、２）
本実施例に係る管理システム２は、所定の領域（例えば、工場、事務所）へのユーザの入退を管理するシステムである。管理システム２は、管理サーバ１０と、端末装置８０と、外側リーダ１００と、内側リーダ２００と、ドア３００と、電気錠４００と、開閉センサ５００と、を備える。管理サーバ１０は、アンチパスバック方式（以下では、アンチパスバックのことを「ＡＰＢ」と記載する）の判断を実行して、電気錠４００の解錠と施錠を制御するサーバである。なお、ＡＰＢ方式の概要については後述する。管理サーバ１０は、各装置８０、１００、２００、４００、５００と通信可能である。端末装置８０は、管理サーバ１０と通信可能な端末である。端末装置８０は、例えば、デスクトップＰＣ、ノートＰＣ、スマートフォン等である。ドア３００は、所定の領域の出入口に設けられている。ドア３００は、ノブを回して開閉する手動のドアである。なお、変形例では、ドア３００は、自動ドアであってもよい。
（管理システム２の構成：図１、２）
本実施例に係る管理システム２は、所定の領域（例えば、工場、事務所）へのユーザの入退を管理するシステムである。管理システム２は、管理サーバ１０と、端末装置８０と、外側リーダ１００と、内側リーダ２００と、ドア３００と、電気錠４００と、開閉センサ５００と、を備える。管理サーバ１０は、アンチパスバック方式（以下では、アンチパスバックのことを「ＡＰＢ」と記載する）の判断を実行して、電気錠４００の解錠と施錠を制御するサーバである。なお、ＡＰＢ方式の概要については後述する。管理サーバ１０は、各装置８０、１００、２００、４００、５００と通信可能である。端末装置８０は、管理サーバ１０と通信可能な端末である。端末装置８０は、例えば、デスクトップＰＣ、ノートＰＣ、スマートフォン等である。ドア３００は、所定の領域の出入口に設けられている。ドア３００は、ノブを回して開閉する手動のドアである。なお、変形例では、ドア３００は、自動ドアであってもよい。
【0021】
外側リーダ１００は、所定の領域の外側に設けられている。内側リーダ２００は、特定の領域の内側に設けられている。各リーダ１００、２００は、ＮＦＣ通信を利用して、非接触型のＩＣチップに記憶されている情報を読む出すリーダである。ＩＣチップは、ＩＣカード６００に含まれる（図２参照）。ＩＣチップには、ＩＣカード６００を携帯するユーザを示すユーザＩＤ（例えば「ｕ００１」）が記憶されている。なお、変形例では、ＩＣチップは、スマートフォン等の携帯端末に備えられていてもよい。
【0022】
電気錠４００は、ドア３００を施錠可能な錠である。電気錠４００は、ドア３００が施錠されている状態において、管理サーバ１０から解錠の指示を示す解錠信号を受信する場合に、ドア３００を解錠する。また、電気錠４００は、ドア３００が施錠されていない状態において、管理サーバ１０から施錠の指示を示す施錠信号を受信する場合に、ドア３００を施錠する。
【0023】
開閉センサ５００は、ドア３００の開閉を検知するセンサである。
【0024】
（管理サーバ１０の構成；図２）
管理サーバ１０は、通信インターフェース１２と、制御部３０と、を備える。なお、以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。通信Ｉ／Ｆ１２は、他の装置（例えば外側リーダ１００）との通信を実行するためのＩ／Ｆである。
管理サーバ１０は、通信インターフェース１２と、制御部３０と、を備える。なお、以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。通信Ｉ／Ｆ１２は、他の装置（例えば外側リーダ１００）との通信を実行するためのＩ／Ｆである。
【0025】
制御部３０は、ＣＰＵ３２と、揮発性メモリ、不揮発性メモリなどによって構成されるメモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に記憶されているプログラム４０に従って、様々な処理（例えば後述する図６の入退判断処理）を実行する。
【0026】
メモリ３４は、さらに、ＡＰＢテーブル４２と、タイマ回数４４と、を記憶する。ＡＰＢテーブル４２は、ＡＰＢ方式の判断（以下では「ＡＰＢ判断」と記載）に利用される各情報を記憶するテーブルである。ＡＰＢテーブル４２は、所定の領域を利用する複数のユーザのそれぞれについて、当該ユーザを示すユーザＩＤと、進入フラグと、エラーフラグと、を記憶する。進入フラグは、対応するユーザが所定の領域に進入したことを示す「ＯＮ」と、対応するユーザが所定の領域から退出したことを示す「ＯＦＦ」と、のいずれかの値を示す。エラーフラグは、対応するユーザについて所定のエラーが発生したことを示す「ＯＮ」と、対応するユーザについて所定のエラーが発生していないことを示す「ＯＦＦ」と、のいずれかの値を示す。所定のエラーの内容については、後述する。
【0027】
タイマ回数４４は、後述する図８のタイマ処理においてタイマが開始された回数を示す。タイマ回数４４の初期値は０回である。タイマ回数４４は、例えば、ドア３００の保守点検を行う作業者によってリセットされる。
【0028】
（ＡＰＢ方式の概要；図３）
図３を参照して、ＡＰＢ方式の概要について説明する。なお、以下では、各デバイスの各ＣＰＵ（例えば管理サーバ１０のＣＰＵ３２等）が実行する処理について、理解の容易さの観点から、各ＣＰＵを主体として記載せずに、各デバイス（例えば管理サーバ１０等）を主体として記載する場合がある。また、管理サーバ１０は、通信Ｉ／Ｆ１２を介して、他の装置（例えば外側リーダ１００）との通信を実行する。以下では、説明の簡略化のために、「通信Ｉ／Ｆ１２を介して」という記載を省略する場合がある。
図３を参照して、ＡＰＢ方式の概要について説明する。なお、以下では、各デバイスの各ＣＰＵ（例えば管理サーバ１０のＣＰＵ３２等）が実行する処理について、理解の容易さの観点から、各ＣＰＵを主体として記載せずに、各デバイス（例えば管理サーバ１０等）を主体として記載する場合がある。また、管理サーバ１０は、通信Ｉ／Ｆ１２を介して、他の装置（例えば外側リーダ１００）との通信を実行する。以下では、説明の簡略化のために、「通信Ｉ／Ｆ１２を介して」という記載を省略する場合がある。
【0029】
（ケースＡ１）
本ケースは、ユーザＩＤ「ｕ００１」によって示されるユーザ（以下では、ユーザ「ｕ００１」と記載）の所定の領域への進入が正常に完了するケースを示す。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＦＦ」が記憶されている。
本ケースは、ユーザＩＤ「ｕ００１」によって示されるユーザ（以下では、ユーザ「ｕ００１」と記載）の所定の領域への進入が正常に完了するケースを示す。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＦＦ」が記憶されている。
【0030】
Ｔ１０では、ユーザ「ｕ００１」は、所定の領域に進入するために、ユーザ「ｕ００１」のＩＣカード６００を外側リーダ１００に近づけるタッチ操作を行う。これにより、外側リーダ１００は、ＩＣカード６００からユーザＩＤ「ｕ００１」を読み取る。
【0031】
Ｔ１２では、外側リーダ１００は、Ｔ１０で読み取ったユーザＩＤ「ｕ００１」を管理サーバ１０に送信する。
【0032】
管理サーバ１０は、Ｔ１２において、外側リーダ１００からユーザＩＤ「ｕ００１」を受信すると、Ｔ１４において、外側リーダ１００との通信をトリガとして開始される第１のＡＰＢ判断を実行する。第１のＡＰＢ判断では、管理サーバ１０は、ＡＰＢテーブル４２から、外側リーダ１００から受信したユーザＩＤに対応付けて記憶されている進入フラグを特定する。そして、管理サーバ１０は、特定済みの進入フラグが「ＯＦＦ」を示す場合（即ちユーザが所定の領域の外側に居る事実に反しない場合）に、当該ユーザＩＤによって示されるユーザの進入を許可することを決定する。一方、管理サーバ１０は、特定済みの進入フラグが「ＯＮ」を示す場合（即ちユーザが所定の領域の外側に居る事実に反する場合）に、当該ユーザＩＤによって示されるユーザの進入を許可しないことを決定する。本ケースでは、管理サーバ１０は、ＡＰＢテーブル４２においてユーザＩＤ「ｕ００１」に対応付けて記憶されている進入フラグが「ＯＦＦ」を示すので、第１のＡＰＢ判断において、ユーザ「ｕ００１」の進入の許可を決定する。
【0033】
管理サーバ１０は、Ｔ１４の第１のＡＰＢ判断において、ユーザ「ｕ００１」の進入の許可を決定すると、Ｔ１６において、解除信号を電気錠４００に送信する。これにより、電気錠４００がドア３００を解錠し、ユーザ「ｕ００１」は、ドア３００を開けて所定の領域に進入する。
【0034】
続けて、管理サーバ１０は、開閉センサ５００からドア３００が閉じたことを示す閉信号を受信すると、Ｔ１８において、施錠信号を電気錠４００に送信する。これにより、電気錠４００がドア３００を施錠する。
【0035】
さらに、管理サーバ１０は、開閉センサ５００から閉信号を受信すると、ＡＰＢテーブル４２においてユーザＩＤ「ｕ００１」に対応付けて記憶されている進入フラグを「ＯＦＦ」から「ＯＮ」に変更する。
【0036】
（ケースＡ２）
本ケースは、ユーザ「ｕ００１」の所定の領域への進入が正常に完了しないケースを示す。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＮ」が記憶されている。例えば、ユーザ「ｕ００１」が、内側リーダ２００へのタッチ操作を行うことなく、他のユーザの後について、所定の領域から退出する（即ち、ユーザ「ｕ００１」が共連れで退出する）場合に、本ケースの初期状態が発生する。
本ケースは、ユーザ「ｕ００１」の所定の領域への進入が正常に完了しないケースを示す。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＮ」が記憶されている。例えば、ユーザ「ｕ００１」が、内側リーダ２００へのタッチ操作を行うことなく、他のユーザの後について、所定の領域から退出する（即ち、ユーザ「ｕ００１」が共連れで退出する）場合に、本ケースの初期状態が発生する。
【0037】
Ｔ３０、Ｔ３２は、Ｔ１０、Ｔ１２と同様である。Ｔ３４では、管理サーバ１０は、第１のＡＰＢ判断を実行する。本ケースでは、管理サーバ１０は、ＡＰＢテーブル４２においてユーザＩＤ「ｕ００１」に対応付けて記憶されている進入フラグが「ＯＮ」を示すので、第１のＡＰＢ判断において、共連れで退出したユーザ「ｕ００１」の進入の不許可を決定する。
【0038】
（ケースＢ１）
本ケースは、ユーザ「ｕ００１」の所定の領域からの退出が正常に完了するケースを示す。本ケースの初期状態は、ケースＡ２と同様で、進入フラグが「ＯＮ」を示す。
本ケースは、ユーザ「ｕ００１」の所定の領域からの退出が正常に完了するケースを示す。本ケースの初期状態は、ケースＡ２と同様で、進入フラグが「ＯＮ」を示す。
【0039】
Ｔ４０では、ユーザ「ｕ００１」は、所定の領域から退出するために、ユーザ「ｕ００１」のＩＣカード６００を内側リーダ２００に近づけるタッチ操作を行う。これにより、内側リーダ２００は、ＩＣカード６００からユーザＩＤ「ｕ００１」を読み取る。
【0040】
Ｔ４２では、内側リーダ２００は、Ｔ４０で読み取ったユーザＩＤ「ｕ００１」を管理サーバ１０に送信する。
【0041】
管理サーバ１０は、Ｔ４２において、内側リーダ２００からユーザＩＤ「ｕ００１」を受信すると、Ｔ４４において、内側リーダ２００との通信をトリガとして開始される第２のＡＰＢ判断を実行する。第２のＡＰＢ判断では、管理サーバ１０は、ＡＰＢテーブル４２から、内側リーダ２００から受信したユーザＩＤに対応付けて記憶されている進入フラグを特定する。そして、管理サーバ１０は、特定済みの進入フラグが「ＯＮ」を示す場合（即ちユーザが所定の領域の内側に居る事実に反しない場合）に、当該ユーザＩＤによって示されるユーザの退出を許可することを決定する。一方、管理サーバ１０は、特定済みの進入フラグが「ＯＦＦ」を示す場合（即ちユーザが所定の領域の内側に居る事実に反する場合）に、当該ユーザＩＤによって示されるユーザの退出を許可しないことを決定する。本ケースでは、管理サーバ１０は、ＡＰＢテーブル４２においてユーザＩＤ「ｕ００１」に対応付けて記憶されている進入フラグが「ＯＮ」を示すので、第２のＡＰＢ判断において、ユーザ「ｕ００１」の退出の許可を決定する。
【0042】
Ｔ４６、Ｔ４８は、Ｔ１６、Ｔ１８と同様である。Ｔ５０は、進入フラグを「ＯＮ」から「ＯＦＦ」に変更する点を除いて、Ｔ２０と同様である。
【0043】
（ケースＢ２）
本ケースは、ユーザ「ｕ００１」の所定の領域からの退出が正常に完了しないケースを示す。本ケースの初期状態は、ケースＡ１と同様で、進入フラグが「ＯＦＦ」を示す。例えば、ユーザ「ｕ００１」が、外側リーダ１００へのタッチ操作を行うことなく、他のユーザの後について、所定の領域に進入する（即ち、ユーザ「ｕ００１」が共連れで進入する）場合に、本ケースの初期状態が発生する。
本ケースは、ユーザ「ｕ００１」の所定の領域からの退出が正常に完了しないケースを示す。本ケースの初期状態は、ケースＡ１と同様で、進入フラグが「ＯＦＦ」を示す。例えば、ユーザ「ｕ００１」が、外側リーダ１００へのタッチ操作を行うことなく、他のユーザの後について、所定の領域に進入する（即ち、ユーザ「ｕ００１」が共連れで進入する）場合に、本ケースの初期状態が発生する。
【0044】
Ｔ６０、Ｔ６２は、Ｔ４０、Ｔ４２と同様である。Ｔ６４では、管理サーバ１０は、第２のＡＰＢ判断を実行する。本ケースでは、管理サーバ１０は、進入フラグが「ＯＦＦ」を示すので、第２のＡＰＢ判断において、共連れで進入したユーザ「ｕ００１」の退出の不許可を決定する。
【0045】
ケースＡ１～Ｂ２で示すように、ＡＰＢ方式では、共連れで進入又は退出した者を管理し、その者の進入又は退出を許可しないことができる。例えば、第三者が共連れで進入して、所定の領域内のユーザからＩＣカード６００を盗み、そのＩＣカード６００を使って退出することを抑制することできる。所定の領域内の情報が漏洩することを抑制することができる。
【0046】
【0047】
（ケースＣ１；図４）
本ケースでは、ユーザ「ｕ００１」に続けて、ユーザＩＤ「ｕ００２」によって示されるユーザ（以下では、ユーザ「ｕ００２」と記載）が所定の領域に進入することを想定する。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＦＦ」、及び、ユーザＩＤ「ｕ００２」に対応付けて進入フラグ「ＯＦＦ」が記憶されている。
本ケースでは、ユーザ「ｕ００１」に続けて、ユーザＩＤ「ｕ００２」によって示されるユーザ（以下では、ユーザ「ｕ００２」と記載）が所定の領域に進入することを想定する。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＦＦ」、及び、ユーザＩＤ「ｕ００２」に対応付けて進入フラグ「ＯＦＦ」が記憶されている。
【0048】
Ｔ１００～Ｔ１０６は、管理サーバ９００が利用される点を除いて、図３のＴ１０～Ｔ１６と同様である。続けて、ユーザ「ｕ００１」は、ドア３００を開ける。一方、Ｔ１１０では、ユーザ「ｕ００２」が外側リーダ１００に対するタッチ操作を行う。続くＴ１１２、Ｔ１１４は、ユーザＩＤ「ｕ００２」が利用される点を除いて、Ｔ１０２、Ｔ１０４と同様である。即ち、ユーザ「ｕ００２」の進入の許可が決定される。
【0049】
本ケースでは、進入が許可されたユーザ「ｕ００２」が所定の領域に進入する前に、ユーザ「ｕ００１」がドア３００を閉じてしまう。この場合、Ｔ１１８では、管理サーバ９００は、施錠信号を電気錠４００に送信する。そして、管理サーバ９００は、Ｔ１２０において、ＡＰＢテーブル４２から、現時点において進入が許可されたユーザを示すユーザＩＤ「ｕ００１」、「ｕ００２」を特定し、特定済みの２個のユーザＩＤに対応する２個の進入フラグを「ＯＦＦ」から「ＯＮ」に変更する。
【0050】
ユーザ「ｕ００２」は、所定の領域への進入を再び試みるために、Ｔ１３０において、再びタッチ操作を行う。続くＴ１３２は、Ｔ１１２と同様である。Ｔ１３４では、管理サーバ９００は、第１のＡＰＢ判断を実行する。現時点では、進入フラグが「ＯＮ」を示すので、管理サーバ９００は、第１のＡＰＢ判断において、ユーザ「ｕ００２」の進入の不許可を決定する。
【0051】
本ケースのように、ユーザ「ｕ００１」に続けて、ユーザ「ｕ００２」が所定の領域に進入する場合には、共連れではないにも関わらず、ユーザ「ｕ００２」が所定の領域に進入できない事態が発生する可能性がある。
【0052】
（ケースＣ２；図５）
本ケースでは、ユーザ「ｕ００１」が所定の領域に進入し、ユーザ「ｕ００２」が所定の領域から退出することを想定する。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＦＦ」、及び、ユーザＩＤ「ｕ００２」に対応付けて進入フラグ「ＯＮ」が記憶されている。
本ケースでは、ユーザ「ｕ００１」が所定の領域に進入し、ユーザ「ｕ００２」が所定の領域から退出することを想定する。本ケースの初期状態では、ＡＰＢテーブル４２において、ユーザＩＤ「ｕ００１」に対応付けて進入フラグ「ＯＦＦ」、及び、ユーザＩＤ「ｕ００２」に対応付けて進入フラグ「ＯＮ」が記憶されている。
【0053】
Ｔ１５０～Ｔ１５６は、管理サーバ９００が利用される点を除いて、図３のＴ１０～Ｔ１６と同様である。一方、Ｔ１６０～Ｔ１６４は、管理サーバ９００が利用される点と、ユーザＩＤ「ｕ００２」が利用される点を除いて、図３のＴ４０～Ｔ４４と同様である。本ケースでは、Ｔ１５０においてユーザ「ｕ００１」が外側リーダ１００にタッチ操作を行うタイミングと、Ｔ１６０においてユーザ「ｕ００２」が内側リーダ２００にタッチ操作を行うタイミングと、が略同じである。このため、ユーザ「ｕ００１」及びユーザ「ｕ００２」のいずれかがドア３００を開けると、両者が入れ違いとなり、例えばユーザ「ｕ００１」によってユーザ「ｕ００２」の退出が妨げられる可能性がある。
【0054】
本ケースでは、ユーザ「ｕ００２」の退出が妨げられている間に、ドア３００が閉じる。この場合、Ｔ１６８では、管理サーバ９００は、施錠信号を電気錠４００に送信する。そして、管理サーバ９００は、Ｔ１７０において、ユーザＩＤ「ｕ００１」に対応付けて記憶されている進入フラグを「ＯＦＦ」から「ＯＮ」に変更し、ユーザＩＤ「ｕ００２」に対応付けて記憶されている進入フラグを「ＯＮ」から「ＯＦＦ」に変更する。
【0055】
ユーザ「ｕ００２」は、所定の領域からの退出を再び試みるために、Ｔ１８０において、再びタッチ操作を行う。続くＴ１８２は、Ｔ１６２と同様である。Ｔ１８４では、管理サーバ９００は、第２のＡＰＢ判断を実行する。現時点では、進入フラグが「ＯＦＦ」を示すので、管理サーバ９００は、第２のＡＰＢ判断において、ユーザ「ｕ００２」の退出の不許可を決定する。
【0056】
本ケースのように、ユーザ「ｕ００１」とユーザ「ｕ００２」が略同時にタッチ操作を行う場合には、共連れではないにも関わらず、所定の領域から退出できない事態が発生する可能性がある。
【0057】
（入退判断処理；図６）
図６を参照して、本実施例の管理サーバ１０のＣＰＵ３２がプログラム４０に従って実行する入退判断処理について説明する。図６の処理は、管理サーバ１０の電源ＯＮをトリガとして開始される。なお、図３の処理の一部は、図６の処理によって実現される。
図６を参照して、本実施例の管理サーバ１０のＣＰＵ３２がプログラム４０に従って実行する入退判断処理について説明する。図６の処理は、管理サーバ１０の電源ＯＮをトリガとして開始される。なお、図３の処理の一部は、図６の処理によって実現される。
【0058】
Ｓ１０では、ＣＰＵ３２は、外側リーダ１００及び内側リーダ２００のいずれかのリーダからユーザＩＤを受信することを監視する。ＣＰＵ３２は、いずれかのリーダからユーザＩＤを受信する場合（Ｓ１０でＹＥＳ）に、Ｓ１２に進む。
【0059】
Ｓ１２では、ＣＰＵ３２は、いずれかのリーダから受信したユーザＩＤを利用したユーザ認証を実行する。具体的には、ＣＰＵ３２は、受信済みのユーザＩＤがＡＰＢテーブル４２に記憶されているユーザＩＤのいずれかと一致する場合に、ユーザ認証が成功したと判断する。一方、ＣＰＵ３２は、受信済みのユーザＩＤがＡＰＢテーブル４２に記憶されているユーザＩＤのいずれかとも一致しない場合に、ユーザ認証が失敗したと判断する。ＣＰＵ３２は、ユーザ認証が失敗したと判断する場合（Ｓ１２でＮＯ）に、Ｓ２０以降の処理をスキップして、図６の処理を終了する。一方、ＣＰＵ３２は、ユーザ認証が成功したと判断する場合（Ｓ１２でＹＥＳ）に、Ｓ２０に進む。
【0060】
Ｓ２０では、ＣＰＵ３２は、受信済みのユーザＩＤを利用したＡＰＢ判断を実行する。具体的には、ＣＰＵ３２は、受信済みのユーザＩＤが外側リーダ１００から受信された場合には、第１のＡＰＢ判断を実行し、受信済みのユーザＩＤが内側リーダ２００から受信された場合には、第２のＡＰＢ判断を実行する。
【0061】
続くＳ２２では、ＣＰＵ３２は、Ｓ２０のＡＰＢ判断において進入又は退出の許可が決定されたのか否かを判断する。ＣＰＵ３２は、進入又は退出の不許可が決定されたと判断する場合（Ｓ２２でＮＯ）に、Ｓ３０以降の処理をスキップして、図６の処理を終了する。一方、ＣＰＵ３２は、進入又は退出の許可が決定されたと判断する場合（Ｓ２２でＹＥＳ）に、Ｓ３０に進む。
【0062】
Ｓ３０では、ＣＰＵ３２は、開閉センサ５００からの信号を利用して、ドア３００が現在開いている状態であるのか否かを判断する。ＣＰＵ３２は、ドア３００が現在閉じている状態であると判断する場合（Ｓ３０でＮＯ）に、Ｓ３２において、解錠信号を電気錠４００に送信する。Ｓ３２が終了すると、図６の処理が終了する。
【0063】
【0064】
（施錠処理；図７）
図７を参照して、本実施例の管理サーバ１０のＣＰＵ３２がプログラム４０に従って実行する施錠処理について説明する。図７の処理は、管理サーバ１０が解錠信号を電気錠４００に送信することをトリガとして開始される。なお、図３の処理の一部は、図７の処理によって実現される。
図７を参照して、本実施例の管理サーバ１０のＣＰＵ３２がプログラム４０に従って実行する施錠処理について説明する。図７の処理は、管理サーバ１０が解錠信号を電気錠４００に送信することをトリガとして開始される。なお、図３の処理の一部は、図７の処理によって実現される。
【0065】
Ｓ５０では、ＣＰＵ３２は、開閉センサ５００からの信号を利用して、ドア３００が現在閉じている状態であるのか否かを監視する。ＣＰＵ３２は、ドア３００が現在閉じている状態であると判断する場合（Ｓ５０でＹＥＳ）に、Ｓ６０に進む。
【0066】
Ｓ６０では、ＣＰＵ３２は、図６のＳ３４のタイマ処理（詳細は図８にて後述）においてタイマが既に開始されているのか否かを判断する。ＣＰＵ３２は、タイマが既に開始されていると判断する場合（Ｓ６０でＹＥＳ）に、Ｓ６２において、タイマのタイムアップを監視する。そして、ＣＰＵ３２は、タイマがタイムアップする場合（Ｓ６２でＹＥＳ）に、Ｓ７０に進む。
【0067】
また、ＣＰＵ３２は、現時点においてタイマが開始されていないと判断する場合（Ｓ６０でＮＯ）に、Ｓ６２をスキップして、Ｓ７０に進む。
【0068】
Ｓ７０では、ＣＰＵ３２は、施錠信号を電気錠４００に送信する。続くＳ７２では、ＣＰＵ３２は、ＡＰＢテーブル４２において、１個以上の対象の進入フラグを変更する。対象の進入フラグは、図６のＳ２０のＡＰＢ判断において進入又は退出の許可が決定されたユーザを示すユーザＩＤに対応付けられて記憶されている進入フラグである。例えば、複数のユーザのそれぞれについて図６の処理が実行される場合には、Ｓ７２では、ＣＰＵ３２は、複数個の対象フラグを変更する。
【0069】
また、ＣＰＵ３２は、Ｓ５０の監視においてドア３００が現在開いている状態であると判断する場合（Ｓ５０でＮＯ）に、Ｓ５２に進む。Ｓ５２では、ドア３００が継続して開いている時間が所定の上限時間（例えば３０秒）を上回っているのか否かを判断する。ＣＰＵ３２は、ドア３００が継続して開いている時間が上限時間を下回っていると判断する場合（Ｓ５２でＮＯ）に、Ｓ５０の監視に戻る。一方、ＣＰＵ３２は、ドア３００が継続して開いている時間が上限時間を上回っていると判断する場合（Ｓ５２でＹＥＳ）に、Ｓ８０に進む。
【0070】
Ｓ８０は、Ｓ７２と同様である。即ち、ＣＰＵ３２は、ドア３００が開いているにも関わらず、対象の進入フラグを強制的に変更する。例えば、ドア３００が開いている状態が長時間継続していると、対象の進入フラグが変更されないままとなり、進入が許可されたユーザが進入した後に退出する場合に、対象の進入フラグが変更されていないことに起因して、ＡＰＢ判断が正常に行われない可能性がある。Ｓ８０の処理によって、対象の進入フラグが変更されていないことに起因して、ＡＰＢ判断が正常に行われないことを抑制することができる。
【0071】
続くＳ８２では、ＣＰＵ３２は、ＡＰＢテーブル４２において対象の進入フラグに対応付けて記憶されているエラーフラグを「ＯＦＦ」から「ＯＮ」に変更する。これにより、対象の進入フラグに対応するユーザについて、進入又は退出が許可されたものの、その後、ドア３００が開いている状態が長時間継続していた所定のエラーが発生したことを記憶することができる。Ｓ７２及びＳ８２のいずれかの処理が終了すると、図７の処理が終了する。
【0072】
（タイマ処理；図８）
図８を参照して、図６のＳ３４のタイマ処理について説明する。Ｓ１００では、ＣＰＵ３２は、タイマが既に開始されているのか否かを判断する。ＣＰＵ３２は、タイマが既に開始されていると判断する場合（Ｓ１００でＹＥＳ）に、Ｓ１０２以降の処理をスキップして、図８の処理を終了する。一方、ＣＰＵ３２は、現時点においてタイマが開始されていないと判断する場合（Ｓ１００でＮＯ）に、Ｓ１０２に進む。
図８を参照して、図６のＳ３４のタイマ処理について説明する。Ｓ１００では、ＣＰＵ３２は、タイマが既に開始されているのか否かを判断する。ＣＰＵ３２は、タイマが既に開始されていると判断する場合（Ｓ１００でＹＥＳ）に、Ｓ１０２以降の処理をスキップして、図８の処理を終了する。一方、ＣＰＵ３２は、現時点においてタイマが開始されていないと判断する場合（Ｓ１００でＮＯ）に、Ｓ１０２に進む。
【0073】
Ｓ１０２では、ＣＰＵ３２は、タイマを開始する。具体的には、ＣＰＵ３２は、所定の時間（例えば１秒）のカウントダウンを開始する。なお、変形例では、ＣＰＵ３２は、所定の時間のカウントアップを開始してもよい。
【0074】
【0075】
（異常判断処理；図９）
図９を参照して、図８のＳ１１０の異常判断処理について説明する。Ｓ１２０では、ＣＰＵ３２は、タイマ回数４４が所定の回数（例えば１０００回）を上回ったのか否かを判断する。ＣＰＵ３２は、タイマ回数４４が所定の回数を下回っていると判断する場合（Ｓ１２０でＮＯ）に、Ｓ１２２の処理をスキップして、図９の処理を終了する。一方、ＣＰＵ３２は、タイマ回数４４が所定の回数を上回っていると判断する場合（Ｓ１２０でＹＥＳ）に、Ｓ１２２に進む。
図９を参照して、図８のＳ１１０の異常判断処理について説明する。Ｓ１２０では、ＣＰＵ３２は、タイマ回数４４が所定の回数（例えば１０００回）を上回ったのか否かを判断する。ＣＰＵ３２は、タイマ回数４４が所定の回数を下回っていると判断する場合（Ｓ１２０でＮＯ）に、Ｓ１２２の処理をスキップして、図９の処理を終了する。一方、ＣＰＵ３２は、タイマ回数４４が所定の回数を上回っていると判断する場合（Ｓ１２０でＹＥＳ）に、Ｓ１２２に進む。
【0076】
Ｓ１２２では、ＣＰＵ３２は、警告を示す信号を端末装置８０に送信する。これにより、端末装置８０は、警告を報知する（例えば、端末装置８０の画面に警告を示すメッセージを表示する）。タイマ回数４４が所定の回数を上回ることは、ドアが正常に閉まらない状態が発生している可能性が高いことを意味する。上記の構成によれば、ドアが正常に閉まらない状態が発生している可能性が高い場合に、警告を報知することができる。これにより、警告を受けた作業者が、ドア３００の保守点検を行うことができる。
【0077】
【0078】
（ケースＤ１；図１０）
本ケースは、図４のケースＣ１と同様に、ユーザ「ｕ００１」に続けてユーザ「ｕ００２」が所定の領域に進入することを想定する。本ケースのＡＰＢテーブル４２の初期状態は、図４と同様である。また、本ケースの初期状態では、タイマは開始されていない。
本ケースは、図４のケースＣ１と同様に、ユーザ「ｕ００１」に続けてユーザ「ｕ００２」が所定の領域に進入することを想定する。本ケースのＡＰＢテーブル４２の初期状態は、図４と同様である。また、本ケースの初期状態では、タイマは開始されていない。
【0079】
Ｔ２００～Ｔ２０６は、管理サーバ１０が利用される点を除いて、図４のＴ１００～Ｔ１０６と同様である。続けて、ユーザ「ｕ００１」は、ドア３００を開ける。ここで、管理サーバ１０は、Ｔ２０６において解錠信号を電気錠４００に送信している。このため、管理サーバ１０は、図７の施錠処理を開始する。
【0080】
Ｔ２１０、Ｔ２１２は、管理サーバ１０が利用される点を除いて、図４のＴ１１０、Ｔ１１２と同様である。
【0081】
管理サーバ１０は、Ｔ２１２において、外側リーダ１００からユーザＩＤ「ｕ００２」を受信すると（図６のＳ１０でＹＥＳ）、ユーザＩＤ「ｕ００２」を利用したユーザ認証を実行する（Ｓ１２）。本ケースでは、当該ユーザ認証は成功する（Ｓ１２でＹＥＳ）。そして、管理サーバ１０は、Ｔ２１４において、第１のＡＰＢ判断を実行し（Ｓ２０）、ユーザＩＤ「ｕ００２」に対応する進入フラグが「ＯＦＦ」を示すので、ユーザ「ｕ００１」の進入の許可を決定する（Ｓ２２でＹＥＳ）。
【0082】
現時点では、ドア３００は開いている。このため、管理サーバ１０は、Ｔ２２０において、ドア３００が現在開いている状態であると判断する（Ｓ３０でＹＥＳ）。そして、管理サーバ１０は、タイマ処理を実行する（Ｓ３４）。具体的には、管理サーバ１０は、Ｔ２２２において、現時点においてタイマが開始されていないと判断し（図８のＳ１００でＮＯ）、タイマを開始する（Ｓ１０２）。
【0083】
続けて、管理サーバ１０は、Ｔ２２４において、タイマ回数４４をインクリメントする（Ｓ１０４）。なお、本ケースでは、タイマ回数４４は所定の回数を上回らないので、図９の異常判断処理において警告の報知は実行されない。
【0084】
本ケースでも、ケースＣ１と同様に、ユーザ「ｕ００２」が所定の領域に進入する前に、ユーザ「ｕ００１」がドア３００を閉じてしまう。Ｔ２３０では、管理サーバ１０は、施錠処理において、ドア３００が現在閉じている状態であると判断する（図７のＳ５０でＹＥＳ）。Ｔ２３２では、管理サーバ１０は、タイムアップの監視を開始する（Ｓ６２）。
【0085】
本ケースでは、ユーザ「ｕ００２」は、タイムアップ前にドア３００を開けることを試みる。タイムアップ前において施錠信号は電気錠４００に送信されてないので（Ｓ６２でＮＯ）、ユーザ「ｕ００２」は、ドア３００を開けることができる。そして、ユーザ「ｕ００２」は、所定の領域への進入後にドア３００を閉める。
【0086】
管理サーバ１０は、タイムアップと判断する（図７のＳ６２でＹＥＳ）と、Ｔ２４４において、施錠信号を電気錠４００に送信する（Ｓ７０）。これにより、電気錠４００が、ドア３００を施錠する。
【0087】
続くＴ２４６では、管理サーバ１０は、２個の対象の進入フラグ、即ち、ユーザＩＤ「ｕ００１」に対応付けて記憶されている進入フラグ「ＯＦＦ」とユーザＩＤ「ｕ００２」に対応付けて記憶されている進入フラグ「ＯＦＦ」との双方を「ＯＮ」に変更する（Ｓ７２）。
【0088】
このような構成によれば、ユーザ「ｕ００２」が所定の領域に進入できない事態が発生する図４のケースＣ１に示す問題点を解消することができる
【0089】
（ケースＤ２；図１１）
本ケースは、図５のケースＣ２と同様に、ユーザ「ｕ００１」が所定の領域に進入し、ユーザ「ｕ００２」が所定の領域から退出することを想定する。本ケースのＡＰＢテーブル４２の初期状態は、図５と同様である。また、本ケースの初期状態では、タイマは開始されていない。
本ケースは、図５のケースＣ２と同様に、ユーザ「ｕ００１」が所定の領域に進入し、ユーザ「ｕ００２」が所定の領域から退出することを想定する。本ケースのＡＰＢテーブル４２の初期状態は、図５と同様である。また、本ケースの初期状態では、タイマは開始されていない。
【0090】
Ｔ３００～Ｔ３０６は、管理サーバ１０が利用される点を除いて、図５のＴ１５０～Ｔ１５６と同様である。続けて、ユーザ「ｕ００１」は、ドア３００を開ける。ここで、管理サーバ１０は、Ｔ３０６において解錠信号を電気錠４００に送信している。このため、管理サーバ１０は、図７の施錠処理を開始する。
【0091】
一方、Ｔ３１０では、ユーザ「ｕ００２」が、内側リーダ２００にタッチ操作を行う。本ケースでも、Ｔ３００においてユーザ「ｕ００１」が外側リーダ１００にタッチ操作を行うタイミングと、Ｔ３１０においてユーザ「ｕ００２」が内側リーダ２００にタッチ操作を行うタイミングと、が略同じである。本ケースでは、両者が入れ違いとなり、ドア３００を開けたユーザ「ｕ００１」によってユーザ「ｕ００２」の退出が妨げられる。
【0092】
Ｔ３１２は、内側リーダ２００が利用される点を除いて、図５のＴ１６２と同様である。Ｔ３１４では、管理サーバ１０は、第２のＡＰＢ判断を実行し（Ｓ２０）、ユーザＩＤ「ｕ００２」に対応する進入フラグが「ＯＮ」を示すので、ユーザ「ｕ００２」の退出の許可を決定する（Ｓ２２でＹＥＳ）。Ｔ３２０～Ｔ３２４は、図１０のＴ２２０～Ｔ２２４と同様である。
【0093】
本ケースでも、図５のケースＣ２と同様に、ユーザ「ｕ００２」が所定の領域から退出する前に、ユーザ「ｕ００１」がドア３００を閉じてしまう。Ｔ３３０、Ｔ３３２は、図１０のＴ２３０、Ｔ２３２と同様である。本ケースでも、ユーザ「ｕ００２」は、タイムアップ前にドア３００を開けることを試みる。本ケースでも、タイムアップ前において、電気錠４００はドア３００を施錠していない。ユーザ「ｕ００２」は、ドア３００を開けることができる。そして、ユーザ「ｕ００２」は、所定の領域から退出後にドア３００を閉める。
【0094】
Ｔ３４０～Ｔ３４４は、図１０のＴ２４０～Ｔ２４４と同様である。続くＴ３４６では、管理サーバ１０は、ユーザＩＤ「ｕ００１」に対応付けて記憶されている対象の進入フラグ「ＯＦＦ」を「ＯＮ」に変更し、ユーザＩＤ「ｕ００２」に対応付けて記憶されている対象の進入フラグ「ＯＮ」を「ＯＦＦ」に変更する（Ｓ７２）。
【0095】
このような構成によれば、ユーザ「ｕ００２」が所定の領域から退出できない事態が発生する図５のケースＣ２に示す問題点を解消することができる
【0096】
（本実施例の効果）
例えば、図１０、図１１のケースにおいて、ユーザ「ｕ００２」の進入又は退出の前にドア３００が閉じられる場合に、ユーザ「ｕ００２」に再度のタッチ操作を要求する比較例が想定される。この比較例では、ユーザ「ｕ００２」は、再度のタッチ操作を不便に感じ得る。これに対して、本実施例の構成によれば、タイムアップまでは、ドア３００が閉じられても、施錠信号が電気錠４００に送信されない（図７のＳ６２でＮＯ）。即ち、ユーザ「ｕ００２」がタッチ操作を行わなくても、所定の時間に亘ってドア３００の解錠が維持され、ユーザ「ｕ００２」の進入又は退出が許可される。ユーザ「ｕ００２」の再度のタッチ操作が不要となり、ユーザの利便性を向上することができる。
例えば、図１０、図１１のケースにおいて、ユーザ「ｕ００２」の進入又は退出の前にドア３００が閉じられる場合に、ユーザ「ｕ００２」に再度のタッチ操作を要求する比較例が想定される。この比較例では、ユーザ「ｕ００２」は、再度のタッチ操作を不便に感じ得る。これに対して、本実施例の構成によれば、タイムアップまでは、ドア３００が閉じられても、施錠信号が電気錠４００に送信されない（図７のＳ６２でＮＯ）。即ち、ユーザ「ｕ００２」がタッチ操作を行わなくても、所定の時間に亘ってドア３００の解錠が維持され、ユーザ「ｕ００２」の進入又は退出が許可される。ユーザ「ｕ００２」の再度のタッチ操作が不要となり、ユーザの利便性を向上することができる。
【0097】
（対応関係）
管理サーバ１０、外側リーダ１００、内側リーダ２００、ドア３００、電気錠４００が、それぞれ、「通信装置」、「外側取得装置」、「内側取得装置」、「ドア」、「電気錠」の一例である。図６のＳ２０の処理を実行する制御部３０、Ｓ３２の処理を実行する制御部３０、Ｓ３４の処理を実行する制御部３０が、それぞれ、「決定部」、「解錠送信部」、「カウント部」の一例である。図７のＳ７０の処理を実行する制御部３０が、「施錠送信部」の一例である。Ｓ７２の処理を実行する制御部３０、Ｓ８０の処理を実行する制御部３０が、それぞれ、「第１の変更部」、「第２の変更部」の一例である。図９のＳ１２２の処理を実行する制御部３０が、報知部の一例である。
管理サーバ１０、外側リーダ１００、内側リーダ２００、ドア３００、電気錠４００が、それぞれ、「通信装置」、「外側取得装置」、「内側取得装置」、「ドア」、「電気錠」の一例である。図６のＳ２０の処理を実行する制御部３０、Ｓ３２の処理を実行する制御部３０、Ｓ３４の処理を実行する制御部３０が、それぞれ、「決定部」、「解錠送信部」、「カウント部」の一例である。図７のＳ７０の処理を実行する制御部３０が、「施錠送信部」の一例である。Ｓ７２の処理を実行する制御部３０、Ｓ８０の処理を実行する制御部３０が、それぞれ、「第１の変更部」、「第２の変更部」の一例である。図９のＳ１２２の処理を実行する制御部３０が、報知部の一例である。
【0098】
（第２実施例）
本実施例は、タイマ処理の内容が異なる点を除いて、第１実施例と同様である。
本実施例は、タイマ処理の内容が異なる点を除いて、第１実施例と同様である。
【0099】
（タイマ処理；図１２）
Ｓ２００は、図８のＳ１００と同様である。Ｓ２０２では、ＣＰＵ３２は、現時点にて実行されたＡＰＢ判断の一つ前に実行されたＡＰＢ判断（即ち先の判断）のタイミングと、現時点にて実行されたＡＰＢ判断（即ち現時点の判断）のタイミングとの間の時間差が所定の閾値（例えば０．１秒）を下回るのか否かを判断する。先の判断のタイミングと現時点の判断のタイミングの時間差が所定の閾値を下回ることは、例えば、図１１のケースＤ２のように、ユーザ「ｕ００１」が外側リーダ１００にタッチ操作を行うタイミングと、Ｔ３１０においてユーザ「ｕ００２」が内側リーダ２００にタッチ操作を行うタイミングと、が略同じであることを意味する。ＣＰＵ３２は、上記の時間差が所定の閾値を上回ると判断する場合（Ｓ２０２でＮＯ）に、Ｓ２０４において、所定の第１時間（例えば１秒）のカウントダウンを開始する。一方、ＣＰＵ３２は、上記の時間差が所定の閾値を下回ると判断する場合（Ｓ２０２でＹＥＳ）に、Ｓ２０６において、所定の第２時間（例えば２秒）のカウントダウンを開始する。ここで、第２時間は、第１時間よりも長い。ＣＰＵ３２は、Ｓ２０４又はＳ２０６が終了すると、Ｓ２０８に進む。
Ｓ２００は、図８のＳ１００と同様である。Ｓ２０２では、ＣＰＵ３２は、現時点にて実行されたＡＰＢ判断の一つ前に実行されたＡＰＢ判断（即ち先の判断）のタイミングと、現時点にて実行されたＡＰＢ判断（即ち現時点の判断）のタイミングとの間の時間差が所定の閾値（例えば０．１秒）を下回るのか否かを判断する。先の判断のタイミングと現時点の判断のタイミングの時間差が所定の閾値を下回ることは、例えば、図１１のケースＤ２のように、ユーザ「ｕ００１」が外側リーダ１００にタッチ操作を行うタイミングと、Ｔ３１０においてユーザ「ｕ００２」が内側リーダ２００にタッチ操作を行うタイミングと、が略同じであることを意味する。ＣＰＵ３２は、上記の時間差が所定の閾値を上回ると判断する場合（Ｓ２０２でＮＯ）に、Ｓ２０４において、所定の第１時間（例えば１秒）のカウントダウンを開始する。一方、ＣＰＵ３２は、上記の時間差が所定の閾値を下回ると判断する場合（Ｓ２０２でＹＥＳ）に、Ｓ２０６において、所定の第２時間（例えば２秒）のカウントダウンを開始する。ここで、第２時間は、第１時間よりも長い。ＣＰＵ３２は、Ｓ２０４又はＳ２０６が終了すると、Ｓ２０８に進む。
【0100】
【0101】
（本実施例の効果）
図１１のケースＤ２のような状況において、進入するユーザ「ｕ００１」のタッチ操作のタイミングと退出するユーザ「ｕ００２」のタッチ操作のタイミングの時間差が略同時になると、両者が入れ違いとなり、例えば、ユーザ「ｕ００１」によってユーザ「ｕ００２」の退出が妨げられる。ユーザ「ｕ００２」の退出が妨げられる時間が長くなると、ユーザ「ｕ００１」がドア３００を閉めてからユーザ「ｕ００２」がドア３００を開けるまでの時間が比較的長くなり、ユーザ「ｕ００２」がドア３００を開ける迄にタイムアップする可能性がある。本実施例によれば、上記の時間差が所定の閾値を下回り、両者のタッチ操作が略同時である場合には、比較的長い第２の時間でカウントダウンが開始される（図１２のＳ２０６）。これにより、上記のように、ユーザ「ｕ００２」がドア３００を開ける迄にタイムアップすることを抑制することができる。一方で、上記の時間差が所定の閾値を上回り、両者のタッチ操作が略同時でない場合には、比較的短い第１の時間でカウントダウンが開始される。両者の入れ違いが発生し難い状況において、ドア３００が施錠されない時間を短くすることができる。
図１１のケースＤ２のような状況において、進入するユーザ「ｕ００１」のタッチ操作のタイミングと退出するユーザ「ｕ００２」のタッチ操作のタイミングの時間差が略同時になると、両者が入れ違いとなり、例えば、ユーザ「ｕ００１」によってユーザ「ｕ００２」の退出が妨げられる。ユーザ「ｕ００２」の退出が妨げられる時間が長くなると、ユーザ「ｕ００１」がドア３００を閉めてからユーザ「ｕ００２」がドア３００を開けるまでの時間が比較的長くなり、ユーザ「ｕ００２」がドア３００を開ける迄にタイムアップする可能性がある。本実施例によれば、上記の時間差が所定の閾値を下回り、両者のタッチ操作が略同時である場合には、比較的長い第２の時間でカウントダウンが開始される（図１２のＳ２０６）。これにより、上記のように、ユーザ「ｕ００２」がドア３００を開ける迄にタイムアップすることを抑制することができる。一方で、上記の時間差が所定の閾値を上回り、両者のタッチ操作が略同時でない場合には、比較的短い第１の時間でカウントダウンが開始される。両者の入れ違いが発生し難い状況において、ドア３００が施錠されない時間を短くすることができる。
【0102】
（対応関係）
図１２のＳ２０４の第１時間、Ｓ２０６の第２時間が、それぞれ、「第１の時間」、「第２の時間」の一例である。
図１２のＳ２０４の第１時間、Ｓ２０６の第２時間が、それぞれ、「第１の時間」、「第２の時間」の一例である。
【0103】
（第３実施例）
本実施例は、タイマ処理の内容が異なる点を除いて、第１実施例と同様である。
本実施例は、タイマ処理の内容が異なる点を除いて、第１実施例と同様である。
【0104】
（タイマ処理；図１３）
Ｓ３００は、図８のＳ１００と同様である。ＣＰＵ３２は、現時点においてタイマが開始されていないと判断する場合（Ｓ３００でＮＯ）に、Ｓ１１２に進む。Ｓ３１２～Ｓ３２０は、図８のＳ１０２～Ｓ１１０と同様である。Ｓ３２０が終了すると、図１３の処理が終了する。一方、ＣＰＵ３２は、タイマが既に開始されていると判断する場合（Ｓ３００でＹＥＳ）に、Ｓ３０２に進む。ここで、タイマが既に開始されていることは、現時点の１つ前のタイミングにおいてドア３００が開いている状態でユーザが外側リーダ１００及び内側リーダ２００のいずれかにタッチ操作を行ったことを意味する。即ち、Ｓ３００でＹＥＳと判断されることは、ドア３００が開いている状態で２人目以降のユーザが外側リーダ１００及び内側リーダ２００のいずれかにタッチ操作を行ったことを意味する。
Ｓ３００は、図８のＳ１００と同様である。ＣＰＵ３２は、現時点においてタイマが開始されていないと判断する場合（Ｓ３００でＮＯ）に、Ｓ１１２に進む。Ｓ３１２～Ｓ３２０は、図８のＳ１０２～Ｓ１１０と同様である。Ｓ３２０が終了すると、図１３の処理が終了する。一方、ＣＰＵ３２は、タイマが既に開始されていると判断する場合（Ｓ３００でＹＥＳ）に、Ｓ３０２に進む。ここで、タイマが既に開始されていることは、現時点の１つ前のタイミングにおいてドア３００が開いている状態でユーザが外側リーダ１００及び内側リーダ２００のいずれかにタッチ操作を行ったことを意味する。即ち、Ｓ３００でＹＥＳと判断されることは、ドア３００が開いている状態で２人目以降のユーザが外側リーダ１００及び内側リーダ２００のいずれかにタッチ操作を行ったことを意味する。
【0105】
Ｓ３０２では、ＣＰＵ３２は、現時点の１つ前のタイミングにおいてタッチ操作が行われたリーダと現時点のタイミングにおいてタッチ操作が行われたリーダが同じであるのか否かを判断する。即ち、ＣＰＵ３２は、上記の２人目以降のユーザが同じリーダ（例えば外側リーダ１００）で続けてタッチ操作を行ったのか否かを判断する。ＣＰＵ３２は、上記の２人目以降のユーザが同じリーダで続けてタッチ操作を行ったと判断する場合（Ｓ３０２でＹＥＳ）に、Ｓ３０４に進む。Ｓ３０４では、ＣＰＵ３２は、既に開始されているタイマをリセットする。具体的には、ＣＰＵ３２は、既に開始されているタイマを終了して、所定の時間（例えば１秒）のカウントダウンを再び開始する。Ｓ３０４が終了すると、図１３の処理が終了する。
【0106】
また、上記の２人目以降のユーザが同じリーダで続けてタッチ操作を行っていないと判断する場合（Ｓ３０２でＮＯ）に、Ｓ３０４の処理をスキップして、図１３の処理を終了する。
【0107】
（本実施例の効果）
複数のユーザが、所定の領域に続けて進入する状況が想定される。例えば、図１０のケースＤ１において、Ｔ２１０のユーザ「ｕ００２」に続けて他のユーザ（例えばユーザＩＤ「ｕ００３」によって示されるユーザ「ｕ００３」）が、外側リーダ１００にタッチ操作を行う状況である。このような状況では、ドア３００が開いている状態が継続する可能性がある。仮に、カウントアップ後でもドア３００が開いている場合において、ユーザ「ｕ００３」が所定の領域に進入する前にユーザ「ｕ００２」がドア３００を閉めると、ユーザ「ｕ００３」が所定の領域に進入する前に、ドア３００が施錠される。本実施例の構成によれば、２人目以降のユーザであるユーザ「ｕ００３」の進入が許可されるときに、所定の時間のカウントダウンがリセットされる（図１３のＳ３０４）。これにより、ユーザ「ｕ００３」が所定の領域に進入する前にユーザ「ｕ００２」がドア３００を閉めても、タイムアップしない。タイムアップせずにドア３００が施錠されないので、ユーザ「ｕ００３」が所定の領域に進入できない事態が発生することを抑制することができる。なお、複数のユーザが、所定の領域から続けて退出する状況でも、同様に、ユーザ「ｕ００３」が所定の領域から退出できない事態が発生することを抑制することができる。図１０の外側リーダ１００、ユーザ「ｕ００１」、ユーザ「ｕ００２」、ユーザ「ｕ００３」が、それぞれ、「特定の取得装置」、「第１のユーザ」、「第２のユーザ」、「第３のユーザ」の一例である。
複数のユーザが、所定の領域に続けて進入する状況が想定される。例えば、図１０のケースＤ１において、Ｔ２１０のユーザ「ｕ００２」に続けて他のユーザ（例えばユーザＩＤ「ｕ００３」によって示されるユーザ「ｕ００３」）が、外側リーダ１００にタッチ操作を行う状況である。このような状況では、ドア３００が開いている状態が継続する可能性がある。仮に、カウントアップ後でもドア３００が開いている場合において、ユーザ「ｕ００３」が所定の領域に進入する前にユーザ「ｕ００２」がドア３００を閉めると、ユーザ「ｕ００３」が所定の領域に進入する前に、ドア３００が施錠される。本実施例の構成によれば、２人目以降のユーザであるユーザ「ｕ００３」の進入が許可されるときに、所定の時間のカウントダウンがリセットされる（図１３のＳ３０４）。これにより、ユーザ「ｕ００３」が所定の領域に進入する前にユーザ「ｕ００２」がドア３００を閉めても、タイムアップしない。タイムアップせずにドア３００が施錠されないので、ユーザ「ｕ００３」が所定の領域に進入できない事態が発生することを抑制することができる。なお、複数のユーザが、所定の領域から続けて退出する状況でも、同様に、ユーザ「ｕ００３」が所定の領域から退出できない事態が発生することを抑制することができる。図１０の外側リーダ１００、ユーザ「ｕ００１」、ユーザ「ｕ００２」、ユーザ「ｕ００３」が、それぞれ、「特定の取得装置」、「第１のユーザ」、「第２のユーザ」、「第３のユーザ」の一例である。
【0108】
（第４実施例）
本実施例は、タイマ処理の内容が異なる点を除いて、第１実施例と同様である。
本実施例は、タイマ処理の内容が異なる点を除いて、第１実施例と同様である。
【0109】
（タイマ処理；図１４）
本実施例のタイマ処理では、現時点のタイマの時間（即ち所定の時間）が延長され得る。本実施例のタイマ処理は、Ｓ３０２の判断以降の処理が異なる点を除いて、第３実施例のタイマ処理（図１３参照）と同様である。ＣＰＵ３２は、２人目以降のユーザが同じリーダで続けてタッチ操作を行ったと判断する場合（Ｓ３０２でＹＥＳ）に、４０２に進む。
本実施例のタイマ処理では、現時点のタイマの時間（即ち所定の時間）が延長され得る。本実施例のタイマ処理は、Ｓ３０２の判断以降の処理が異なる点を除いて、第３実施例のタイマ処理（図１３参照）と同様である。ＣＰＵ３２は、２人目以降のユーザが同じリーダで続けてタッチ操作を行ったと判断する場合（Ｓ３０２でＹＥＳ）に、４０２に進む。
【0110】
Ｓ４０２では、ＣＰＵ３２は、現時点のタイマの時間が所定の上限値（例えば５秒）を下回っているのか否かを判断する。ＣＰＵ３２は、現時点のタイマの時間が所定の上限値を下回っていると判断する場合（Ｓ４０２でＹＥＳ）に、Ｓ４０４に進む。
【0111】
Ｓ４０４では、ＣＰＵ３２は、現時点のタイマの時間を所定の秒数（例えば０．５秒）だけ延長する。Ｓ４０４が終了すると図１４の処理が終了する。
【0112】
また、ＣＰＵ３２は、現時点のタイマの時間が所定の上限値を上回っていると判断する場合（Ｓ４０２でＮＯ）に、Ｓ４０４の処理をスキップして、図１４の処理を終了する。
【0113】
（本実施例の効果）
本実施例でも、第３実施例と同様に、複数のユーザが、所定の領域に続けて進入する状況に対処することができる。本実施例の構成によれば、２人目以降のユーザであるユーザ「ｕ００３」（図１０参照）の進入が許可されるときに、タイマの時間が延長される（Ｓ４０４）。これにより、ユーザ「ｕ００３」が所定の領域に進入する前にユーザ「ｕ００２」がドア３００を閉めても、タイマの時間が延長されてタイムアップしない。タイムアップせずにドア３００が施錠されないので、ユーザ「ｕ００３」が所定の領域に進入できない事態が発生することを抑制することができる。また、タイマの時間の延長には、上限値が設定されている（Ｓ４０２）。ドア３００が施錠されない時間が不必要に延長されることを抑制することができる。
本実施例でも、第３実施例と同様に、複数のユーザが、所定の領域に続けて進入する状況に対処することができる。本実施例の構成によれば、２人目以降のユーザであるユーザ「ｕ００３」（図１０参照）の進入が許可されるときに、タイマの時間が延長される（Ｓ４０４）。これにより、ユーザ「ｕ００３」が所定の領域に進入する前にユーザ「ｕ００２」がドア３００を閉めても、タイマの時間が延長されてタイムアップしない。タイムアップせずにドア３００が施錠されないので、ユーザ「ｕ００３」が所定の領域に進入できない事態が発生することを抑制することができる。また、タイマの時間の延長には、上限値が設定されている（Ｓ４０２）。ドア３００が施錠されない時間が不必要に延長されることを抑制することができる。
【0114】
以上、本明細書で開示する技術の具体例を説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例を採用してもよい。
【0115】
（変形例１） 「外部取得装置」及び「内側取得装置」は、非接触型のＩＣチップに記憶されている情報を読み出すリーダに限らず、例えば、ユーザの生体情報（例えば、指紋情報、顔画像、虹彩情報等）を取得するための装置であってもよい。本変形例では、生体情報が、「ユーザ情報」の一例である。
【0116】
（変形例２）図８のＳ１１０の異常判断処理は実行されなくてもよい。本変形例では、「報知部」を省略可能である。
【0117】
（変形例３）図７のＳ５２、Ｓ８０、Ｓ８２の処理は実行されなくてもよい。本変形例では、「第２の変更部」を省略可能である。
【0118】
本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【0119】
２ ：管理システム
１０ ：管理サーバ
１２ ：通信Ｉ／Ｆ
３０ ：制御部
３２ ：ＣＰＵ
３４ ：メモリ
４０ ：プログラム
４２ ：ＡＰＢテーブル
４４ ：タイマ回数
８０ ：端末装置
１００ ：外側リーダ
２００ ：内側リーダ
３００ ：ドア
４００ ：電気錠
５００ ：開閉センサ
６００ ：ＩＣカード
１０ ：管理サーバ
１２ ：通信Ｉ／Ｆ
３０ ：制御部
３２ ：ＣＰＵ
３４ ：メモリ
４０ ：プログラム
４２ ：ＡＰＢテーブル
４４ ：タイマ回数
８０ ：端末装置
１００ ：外側リーダ
２００ ：内側リーダ
３００ ：ドア
４００ ：電気錠
５００ ：開閉センサ
６００ ：ＩＣカード
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
