特開2016-223212(P2016-223212A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

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

▶ ソニー株式会社の特許一覧
特開2016-223212錠前デバイス、情報処理方法、プログラム、および通信端末
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2016-223212(P2016-223212A)
(43)【公開日】2016年12月28日
(54)【発明の名称】錠前デバイス、情報処理方法、プログラム、および通信端末
(51)【国際特許分類】
   E05B 49/00 20060101AFI20161205BHJP
   H04M 11/00 20060101ALI20161205BHJP
   H04M 1/00 20060101ALI20161205BHJP
【FI】
   E05B49/00 J
   H04M11/00 301
   H04M1/00 U
【審査請求】未請求
【請求項の数】19
【出願形態】OL
【全頁数】57
(21)【出願番号】特願2015-112092(P2015-112092)
(22)【出願日】2015年6月2日
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニー株式会社
(74)【代理人】
【識別番号】100095957
【弁理士】
【氏名又は名称】亀谷 美明
(74)【代理人】
【識別番号】100096389
【弁理士】
【氏名又は名称】金本 哲男
(74)【代理人】
【識別番号】100101557
【弁理士】
【氏名又は名称】萩原 康司
(74)【代理人】
【識別番号】100128587
【弁理士】
【氏名又は名称】松本 一騎
(72)【発明者】
【氏名】作本 紘一
(72)【発明者】
【氏名】飯田 起弘
(72)【発明者】
【氏名】白井 太三
【テーマコード(参考)】
2E250
5K127
5K201
【Fターム(参考)】
2E250AA02
2E250AA03
2E250AA12
2E250BB08
2E250BB30
2E250BB46
2E250BB65
2E250CC16
2E250CC29
2E250DD06
2E250EE02
2E250EE06
2E250EE10
2E250EE15
2E250FF23
2E250FF27
2E250FF36
2E250GG06
2E250GG13
5K127AA21
5K127BA03
5K127BB22
5K127BB33
5K127DA15
5K127GA14
5K127GD16
5K127GD18
5K127GE03
5K127GE11
5K127JA42
5K201AA09
5K201BA01
5K201BD01
5K201CB01
5K201CB13
5K201DC03
5K201EB07
5K201EC06
5K201ED05
5K201ED09
(57)【要約】
【課題】通信端末から処理要求が受信される際に、錠前デバイスの機能に関して通信端末ごとに設定される権限を適応的に判定することが可能な、錠前デバイス、情報処理方法、プログラム、および通信端末を提案する。
【解決手段】錠前デバイスであって、前記錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部と、を備える、錠前デバイス。
【選択図】図1
【特許請求の範囲】
【請求項1】
錠前デバイスであって、
前記錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、
前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部と、
を備える、錠前デバイス。
【請求項2】
前記錠前デバイスは、施錠部をさらに備え、
前記設定情報は、前記施錠部の解錠または施錠に関して設定された権限を示す情報を含み、
前記処理要求は、前記施錠部の解錠要求または施錠要求を含む、請求項1に記載の錠前デバイス。
【請求項3】
前記設定情報は、前記錠前デバイスが記憶している操作ログの閲覧に関して設定された権限を示す情報をさらに含み、
前記処理要求は、前記操作ログの閲覧要求をさらに含む、請求項2に記載の錠前デバイス。
【請求項4】
前記設定情報は、前記錠前デバイスが記憶している時刻情報の変更、または、前記錠前デバイスに含まれる複数の機器の設定情報の変更に関して設定された権限を示す情報をさらに含み、
前記処理要求は、前記時刻情報の変更要求、または、前記複数の機器のうちいずれか一以上の機器の設定情報の変更要求をさらに含む、請求項2に記載の錠前デバイス。
【請求項5】
前記錠前デバイスは、前記錠前デバイスに対するアクセス権限を有しない通信端末の識別情報を格納するアクセス不可端末リストを記憶する記憶部をさらに備え、
前記鍵情報は、前記第1の通信端末の識別情報をさらに含み、
前記判定部は、前記第1の通信端末の識別情報が前記アクセス不可端末リストに格納されている場合には、前記処理要求を許可しないことを判定する、請求項2に記載の錠前デバイス。
【請求項6】
前記設定情報は、前記アクセス不可端末リストに対する他の通信端末の識別情報の追加または削除に関して設定された権限を示す情報をさらに含み、
前記処理要求は、前記アクセス不可端末リストに対する他の通信端末の識別情報の追加要求または削除要求をさらに含む、請求項5に記載の錠前デバイス。
【請求項7】
前記通信部は、さらに、第1の共通鍵と、第2の通信端末に対応付けられた第2の公開鍵とを前記第2の通信端末から受信し、
前記錠前デバイスは、前記錠前デバイスに対応付けられた第2の共通鍵を記憶する記憶部と、
前記第1の共通鍵と前記第2の共通鍵との比較結果が一致する場合に、前記第2の通信端末を前記錠前デバイスのオーナー端末として登録し、かつ、前記第2の公開鍵を前記記憶部に格納するオーナー端末登録部と、をさらに備える、請求項2に記載の錠前デバイス。
【請求項8】
前記鍵情報は、前記錠前デバイスのオーナー端末として登録された前記第2の通信端末により、前記第1の通信端末と対応付けて発行された情報である、請求項7に記載の錠前デバイス。
【請求項9】
前記鍵情報は、前記第2の通信端末による前記第1の公開鍵に対する署名情報をさらに含む、請求項8に記載の錠前デバイス。
【請求項10】
前記錠前デバイスは、前記第1の公開鍵に対する署名情報に基づいて前記第1の公開鍵の正当性を検証する鍵検証部をさらに備え、
前記判定部は、さらに、前記鍵検証部により前記第1の公開鍵が正当であることが検証された場合に、前記処理要求を許可することを判定する、請求項9に記載の錠前デバイス。
【請求項11】
前記通信部は、さらに、前記第1の公開鍵に対応する第1の秘密鍵により生成された第1の情報を前記第1の通信端末から受信し、
前記錠前デバイスは、前記第1の情報を前記第1の公開鍵に基づいて検証する検証処理部をさらに備え、
前記判定部は、さらに、前記検証処理部により前記第1の情報が正当であることが検証された場合に、前記処理要求を許可することを判定する、請求項10に記載の錠前デバイス。
【請求項12】
前記通信部は、前記錠前デバイスの複数の種類の機能に関する第3の通信端末の権限の設定情報、および前記第3の通信端末に対応付けられた第3の公開鍵を含むサブ鍵情報と、前記錠前デバイスに対する第2の処理要求とを前記第3の通信端末からさらに受信し、
前記判定部は、さらに、前記サブ鍵情報に基づいて前記第2の処理要求を許可するか否かを判定し、
前記サブ鍵情報は、前記第1の通信端末により前記第3の通信端末と対応付けて発行された情報であり、
前記複数の種類の機能に関して前記第3の通信端末に設定された権限は、前記第1の通信端末に設定された権限以下である、請求項2に記載の錠前デバイス。
【請求項13】
錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信することと、
前記鍵情報に基づいて、前記処理要求を許可するか否かを判定することと、
を備える、情報処理方法。
【請求項14】
コンピュータを、
錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、
前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部、
として機能させるための、プログラム。
【請求項15】
錠前デバイスから受信する第1の電波強度を測定する電波強度測定部と、
前記電波強度測定部により測定された前記第1の電波強度の値に基づいて、前記錠前デバイスに対する解錠要求の送信を制御する送信制御部と、
を備える、通信端末。
【請求項16】
前記通信端末は、外出フラグを記憶する記憶部と、
前記通信端末の位置情報を計測する位置情報計測部と、
前記位置情報計測部により計測された位置情報に基づいて前記外出フラグの値を変更する外出フラグ変更部と、をさらに備える、請求項15に記載の通信端末。
【請求項17】
前記送信制御部は、前記第1の電波強度の測定値および前記外出フラグの値に基づいて、前記錠前デバイスに対する前記解錠要求の送信を制御する、請求項16に記載の通信端末。
【請求項18】
前記通信端末は、前記外出フラグの値が第1の値から第2の値に変更された場合に、前記位置情報の計測を前記位置情報計測部に停止させる計測制御部をさらに備える、請求項17に記載の通信端末。
【請求項19】
前記外出フラグ変更部は、前記錠前デバイスに対して前記解錠要求が送信された際に、前記外出フラグの値を前記第2の値から前記第1の値に変更し、
前記外出フラグの値が前記第1の値であり、かつ、前記電波強度測定部により測定された前記第1の電波強度の測定値が第1の閾値以下であり、かつ、第2の電波強度の測定値が第2の閾値以下であった場合に、前記計測制御部は、前記位置情報の計測を前記位置情報計測部に再開させる、請求項18に記載の通信端末。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、錠前デバイス、情報処理方法、プログラム、および通信端末に関する。
【背景技術】
【0002】
従来、ドアの施解錠を電気的に行うことが可能な錠前デバイスが開発されている。例えば、特許文献1には、携帯機器が電気錠にかざされると、電気錠は携帯機器からキーデータを読み取り、そして、読み取ったキーデータと認証用キーデータとを照合することにより解錠制御を行う技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2007−239347号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献1に記載の技術では、携帯機器に依存せずに、電気錠の機能に関する同一の権限がキーデータに設定される。このため、特許文献1に記載の技術では、電気錠は、携帯機器から受信される要求の可否の判定を携帯機器に応じて異ならせることができない。
【0005】
そこで、本開示では、通信端末から処理要求が受信される際に、錠前デバイスの機能に関して通信端末ごとに設定される権限を適応的に判定することが可能な、新規かつ改良された錠前デバイス、情報処理方法、プログラム、および通信端末を提案する。
【課題を解決するための手段】
【0006】
本開示によれば、錠前デバイスであって、前記錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部と、を備える、錠前デバイスが提供される。
【0007】
また、本開示によれば、錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信することと、前記鍵情報に基づいて、前記処理要求を許可するか否かを判定することと、を備える、情報処理方法が提供される。
【0008】
また、本開示によれば、コンピュータを、錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部、として機能させるための、プログラムが提供される。
【0009】
また、本開示によれば、錠前デバイスから受信する第1の電波強度を測定する電波強度測定部と、前記電波強度測定部により測定された第1の電波強度の値に基づいて、前記錠前デバイスに対する解錠要求の送信を制御する送信制御部と、を備える、通信端末が提供される。
【発明の効果】
【0010】
以上説明したように本開示によれば、通信端末から処理要求が受信される際に、錠前デバイスの機能に関して通信端末ごとに設定される権限を適応的に判定することができる。なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【0011】
図1】本開示の第1の実施形態による情報処理システムの構成例を示した説明図である。
図2】同実施形態による錠前デバイス10‐1の構成例を示した機能ブロック図である。
図3】同実施形態による錠前鍵ファイル126の構成例を示した説明図である。
図4】同実施形態によるオーナー情報ファイル128の構成例を示した説明図である。
図5】同実施形態によるeKeyの構成例を示した説明図である。
図6】同実施形態によるeKeyに含まれる権限設定情報の構成例を示した説明図である。
図7】同実施形態によるユーザ端末20‐1の構成例を示した機能ブロック図である。
図8】同実施形態によるオーナー登録カードの一例を示した説明図である。
図9】同実施形態による施解錠要求画面の表示例を示した説明図である。
図10】同実施形態によるサーバ30‐1の構成例を示した機能ブロック図である。
図11】同実施形態によるオーナー情報DB324の構成例を示した説明図である。
図12】同実施形態による全体的な動作を示したシーケンス図である。
図13】同実施形態によるアカウント登録画面の表示例を示した説明図である。
図14】同実施形態による本人確認画面の表示例を示した説明図である。
図15】同実施形態によるアカウント登録画面に対する入力後に送信される電子メールの表示例を示した説明図である。
図16】同実施形態によるパスコード表示画面の表示例を示した説明図である。
図17】同実施形態による錠前デバイス10‐1へのオーナー登録時の動作を示したシーケンス図である。
図18】同実施形態によるサーバ30‐1へのオーナー登録時の動作を示したシーケンス図である。
図19】同実施形態による自端末へのeKeyの発行時の動作を示したシーケンス図である。
図20】同実施形態による別のユーザ端末20‐1へのeKeyの発行時の動作の一部を示したシーケンス図である。
図21】同実施形態による別のユーザ端末20‐1へのeKeyの発行時の動作の一部を示したシーケンス図である。
図22】同実施形態による別のユーザ端末20‐1へのeKeyの発行時の動作の一部を示したシーケンス図である。
図23】同実施形態による錠前デバイス10‐1への処理要求時の動作を示したシーケンス図である。
図24】同実施形態による「処理要求判定処理」の動作の一部を示したシーケンス図である。
図25】同実施形態による「処理要求判定処理」の動作の一部を示したシーケンス図である。
図26】同実施形態の変形例1によるオーナー登録カードの一例を示した説明図である。
図27】同実施形態の変形例1による、錠前鍵ファイル126における初期状態時の情報の格納例を示した説明図である。
図28】同実施形態の変形例1による錠前デバイス10‐1へのオーナー登録時の動作を示したシーケンス図である。
図29】同実施形態の変形例2による別のユーザ端末20‐1へのeKeyの発行時の動作の一部を示したシーケンス図である。
図30】同実施形態の応用例による情報処理システムの構成例を示した説明図である。
図31】同応用例によるeKeyに含まれる権限設定情報の構成例を示した説明図である。
図32】同応用例による別のユーザ端末20‐1へのサブeKeyの発行時の動作の一部を示したシーケンス図である。
図33】本開示の第2の実施形態によるサーバ30‐2の構成例を示した説明図である。
図34】同実施形態によるeKeyの失効要求時の動作を示したシーケンス図である。
図35】本開示の第3の実施形態による錠前デバイス10‐3の構成例を示した説明図である。
図36】同実施形態によるeKeyに含まれる権限設定情報の構成例を示した説明図である。
図37】同実施形態によるブラックリストDB132への端末IDの追加要求時の動作の一部を示したシーケンス図である。
図38】同実施形態によるブラックリストDB132への端末IDの追加要求時の動作の一部を示したシーケンス図である。
図39】本開示の第4の実施形態によるユーザ端末20‐4の構成例を示した説明図である。
図40】同実施形態による自動解錠が行われる際の錠前デバイス10‐1とユーザ端末20‐4との位置関係の例を示した説明図である。
図41】同実施形態によるユーザ端末20‐4により位置情報の計測が行われる範囲の例を示した説明図である。
図42】同実施形態による初期設定時の動作を示したフローチャートである。
図43】同実施形態による自動解錠利用時の動作の一部を示したフローチャートである。
図44】同実施形態による自動解錠利用時の動作の一部を示したフローチャートである。
【発明を実施するための形態】
【0012】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0013】
また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の構成を、必要に応じてユーザ端末20‐1aおよびユーザ端末20‐1bのように区別する。ただし、実質的に同一の機能構成を有する複数の構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、ユーザ端末20‐1aおよびユーザ端末20‐1bを特に区別する必要が無い場合には、単にユーザ端末20‐1と称する。
【0014】
また、以下に示す項目順序に従って当該「発明を実施するための形態」を説明する。
1.第1の実施形態
2.第2の実施形態
3.第3の実施形態
4.第4の実施形態
5.変形例
【0015】
<<1.第1の実施形態>>
本開示は、一例として「1.第1の実施形態」〜「4.第4の実施形態」において詳細に説明するように、多様な形態で実施され得る。まず、第1の実施形態について説明する。
【0016】
<1−1.システム構成>
図1は、第1の実施形態による情報処理システムの構成を示した説明図である。図1に示したように、第1の実施形態による情報処理システムは、錠前デバイス10‐1、ユーザ端末20‐1、通信網22、サーバ30‐1、およびデータベース32を含む。
【0017】
[1−1−1.錠前デバイス10‐1]
錠前デバイス10‐1は、例えば家の玄関のドアなどに取り付けられ、施錠および解錠の制御を行うための装置である。例えば、錠前デバイス10‐1は、ドアに設置されているサムターン(図示省略)に対する施錠および解錠の制御を行うための装置である。または、ドアにはサムターンが設置されておらず、錠前デバイス10‐1自体が、ドアに設置されたロック機構であってもよい。
【0018】
また、この錠前デバイス10‐1は、後述するユーザ端末20‐1から受信される処理要求に基づいて、例えば施錠処理や解錠処理などの各種の処理を行う。
【0019】
[1−1−2.ユーザ端末20‐1]
ユーザ端末20‐1は、本開示における通信端末の一例である。ユーザ端末20‐1は、ユーザ2が所有する端末であり、基本的には携帯型の端末である。例えば、ユーザ端末20‐1は、スマートフォンなどの携帯電話、タブレット端末、腕時計型デバイス、眼鏡型デバイス、または、例えばBluetooth(登録商標)などに沿った通信機能を有するヘッドホンなどであってもよい。
【0020】
ユーザ端末20‐1は、錠前デバイス10‐1に対して例えば解錠要求などの各種の処理要求を行うためのアプリケーションを実装することが可能である。また、ユーザ端末20‐1は、例えば無線通信により、後述する通信網22を介してサーバ30‐1と通信することが可能である。
【0021】
[1−1−3.通信網22]
通信網22は、通信網22に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、通信網22は、電話回線網、インターネット、衛星通信網などの公衆回線網や、Ethernet(登録商標)を含む各種のLAN(Local Area Network)、WAN(Wide Area Network)などを含んでもよい。また、通信網22は、IP−VPN(Internet Protocol−Virtual Private Network)などの専用回線網を含んでもよい。
【0022】
[1−1−4.サーバ30‐1]
サーバ30‐1は、例えばwebシステムで構成される鍵共有サービスを管理するための装置である。例えば、サーバ30‐1は、ユーザ端末20‐1から受信される要求に基づいて、鍵共有サービスにおけるユーザのアカウントを新規登録する。また、サーバ30‐1は、ユーザ端末20‐1による鍵共有サービスへのログイン時の認証を行う。
【0023】
[1−1−5.データベース32]
データベース32は、サーバ30‐1から受信される指示に従って、鍵共有サービスにおいて利用される様々な情報を記憶する装置である。例えば、データベース32は、個々の錠前デバイス10‐1に対応づけて、オーナー端末として登録されたユーザ端末20‐1の情報を記憶する。
【0024】
なお、第1の実施形態による情報処理システムは、上述した構成に限定されない。例えば、データベース32は、独立した装置として構成される代わりに、サーバ30‐1内に記憶されてもよい。
【0025】
以上、第1の実施形態による情報処理システムの構成について説明した。第1の実施形態による錠前デバイス10‐1は、ユーザ端末20‐1から受信される処理要求の可否を、錠前デバイス10‐1の複数の種類の機能に関してユーザ端末20‐1ごとに設定される権限に適応的に判定することが可能である。以下、このような第1の実施形態について順次詳細に説明する。
【0026】
<1−2.構成>
[1−2−1.錠前デバイス10‐1]
次に、第1の実施形態による構成について詳細に説明する。図2は、第1の実施形態による錠前デバイス10‐1の構成を示した機能ブロック図である。図2に示したように、錠前デバイス10‐1は、制御部100‐1、通信部120、施錠部122、および記憶部124を有する。
【0027】
(1−2−1−1.制御部100‐1)
制御部100‐1は、錠前デバイス10‐1に内蔵される、例えばCPU(Central Processing Unit)、RAM(Random Access Memory)などのハードウェアを用いて、錠前デバイス10‐1の動作を全般的に制御する。また、図2に示したように、制御部100‐1は、情報登録部102、鍵情報検証部104、認証情報検証部106、判定部108、処理実行部110、チャレンジ生成部112、および送信制御部114を有する。
【0028】
(1−2−1−2.情報登録部102)
情報登録部102は、ユーザ端末20‐1から受信された共通鍵と、後述する錠前鍵ファイル126に格納されている錠前デバイス10‐1の共通鍵とを利用した認証処理の結果に基づいて、該当のユーザ端末20‐1を錠前デバイス10‐1のオーナー端末として登録する。例えば、ユーザ端末20‐1から受信された共通鍵と、錠前鍵ファイル126に格納されている錠前デバイス10‐1の共通鍵とが一致する場合に、情報登録部102は、該当のユーザ端末20‐1を錠前デバイス10‐1のオーナー端末として登録する。また、受信された共通鍵と、錠前鍵ファイル126に格納されている錠前デバイス10‐1の共通鍵とが一致しない場合には、情報登録部102は、該当のユーザ端末20‐1をオーナー端末に登録しない。なお、具体的な認証方法としては、前述のように共通鍵が一致するか否かの検証を行う方法以外にも、ISO/IEC9798−2に記載されているような共通鍵認証手法を利用してもよい。
【0029】
また、情報登録部102は、オーナー端末としてユーザ端末20‐1を登録した際に、当該ユーザ端末20‐1から受信されたユーザ端末20‐1の公開鍵を、後述するオーナー情報ファイル128に格納する。例えば、情報登録部102は、オーナー端末の登録を行った際に、まず、オーナー情報ファイル128を作成し、そして、該当のユーザ端末20‐1から受信されたユーザ端末20‐1の公開鍵を、作成したオーナー情報ファイル128に格納する。
【0030】
‐錠前鍵ファイル126
錠前鍵ファイル126は、該当の錠前デバイス10‐1固有の認証鍵の情報が格納されるファイルである。ここで、図3を参照して、錠前鍵ファイル126の構成例について説明する。図3に示したように、錠前鍵ファイル126では、例えば、錠前ID1260、錠前共通鍵1262、錠前秘密鍵1264、および、錠前公開鍵1266が対応づけられている。ここで、錠前ID1260には、該当の錠前デバイス10‐1に対して予め定められているIDが格納される。また、錠前共通鍵1262、錠前秘密鍵1264、および、錠前公開鍵1266には、それぞれ該当の錠前デバイス10‐1に対応付けて予め発行された共通鍵、秘密鍵、または公開鍵が格納される。
【0031】
なお、図3では、錠前鍵ファイル126における、例えば製品出荷時などの初期状態時の情報の格納例を示している。図3に示したように、初期状態時では、錠前鍵ファイル126には、錠前デバイス10‐1の錠前IDおよび共通鍵のみが格納され得る。
【0032】
‐オーナー情報ファイル128
オーナー情報ファイル128は、該当の錠前デバイス10‐1のオーナー端末として情報登録部102により登録されたユーザ端末20‐1の情報が格納されるファイルである。ここで、図4を参照して、オーナー情報ファイル128の構成例について説明する。図4に示したように、オーナー情報ファイル128では、例えば、端末ID1280、および、端末公開鍵1282が対応づけられている。ここで、端末ID1280には、錠前デバイス10‐1のオーナー端末として情報登録部102により登録されたユーザ端末20‐1の端末IDが格納される。また、端末公開鍵1282には、オーナー端末として登録されたユーザ端末20‐1の公開鍵が格納される。
【0033】
なお、図4では、端末公開鍵1282に、該当の端末IDのユーザ端末20‐1の公開鍵が一つだけ格納される例を記載しているが、かかる例に限定されない。変形例として、端末公開鍵1282には、該当の端末IDのユーザ端末20‐1に対応付けて生成された複数の種類の公開鍵認証アルゴリズム用の公開鍵が格納されてもよい。ここで、公開鍵認証アルゴリズムは、例えばRSA、DSA、ECDSA、MQ認証方式、格子暗号ベースの認証方式、または、符号を利用した暗号ベースの認証方式などである。
【0034】
この格納例によれば、後述する鍵情報検証部104および認証情報検証部106による検証処理において、複数の種類の公開鍵認証アルゴリズムによる検証処理を行うことが可能となる。そして、登録されている全ての種類の公開鍵認証アルゴリズムによる検証をパスした場合にのみ、全体としての検証をパスさせることが可能となる。これにより、仮に一種類の公開鍵認証アルゴリズムの安全性が破られたとしても、登録されている他の公開鍵認証アルゴリズムのうち少なくともいずれかの安全性が破られない場合には、全体としての安全性が破られることを防止することができる。
【0035】
(1−2−1−3.鍵情報検証部104)
鍵情報検証部104は、本開示における鍵検証部の一例である。鍵情報検証部104は、ユーザ端末20‐1から受信されるeKeyの正当性を判定する。ここで、eKeyは、本開示における鍵情報の一例である。なお、詳細については後述するが、錠前デバイス10‐1のオーナー端末としてサーバ30‐1に登録されたユーザ端末20‐1のみが、該当の錠前デバイス10‐1に対応するeKeyを発行することが可能である。
【0036】
‐検証例1
例えば、鍵情報検証部104は、受信されたeKeyに含まれる、ユーザ端末20‐1の公開鍵に対する署名情報を検証することにより、該当のeKeyの正当性を検証する。一例として、受信されたeKeyに含まれる、ユーザ端末20‐1の公開鍵に対する署名情報が、後述する認証情報検証部106により検証された結果に基づいて、該当のeKeyに含まれるユーザ端末20‐1の公開鍵が正当であるか否かを判定する。なお、ユーザ端末20‐1の公開鍵に対する署名情報は、基本的には、eKeyを発行したユーザ端末20‐1a(つまりオーナー端末)による署名情報である。また、詳細については後述するが、錠前デバイス10‐1のオーナー端末として登録されたユーザ端末20‐1は、自端末に対してeKey40‐1を発行することも可能である。この場合、公開鍵の証明書4022には、ユーザ端末20‐1の公開鍵に対するユーザ端末20‐1自身の署名情報が記録される。
【0037】
‐検証例2
また、鍵情報検証部104は、受信されたeKeyに含まれる有効期間の情報を参照し、そして、現在が有効期間内である場合には、該当のeKeyが正当であると判定する。例えば、錠前デバイス10‐1のCPUの外部に水晶振動子が実装されている場合には、鍵情報検証部104は、この水晶振動子を用いて正確な時刻を取得することにより、現在時刻が該当のeKeyの有効期間内であるか否かを判定する。
【0038】
‐‐eKey
ここで、図5を参照して、eKeyの構成例(eKey40‐1)について説明する。図5に示したように、eKey40‐1は、例えばヘッダー400、および本体402を有する。また、ヘッダー400は、eKeyID4000、端末ID4002、錠前ID4004、有効期間4006、および権限設定情報4008‐1を有する。また、本体402は、端末公開鍵4020、および公開鍵の証明書4022を有する。
【0039】
ここで、eKeyID4000には、eKey40‐1に対応するeKeyIDが記録される。なお、eKeyIDは、例えばオーナー端末により、eKey40‐1と対応付けて決定されたIDである。また、端末ID4002には、該当のeKey40‐1の発行対象のユーザ端末20‐1の端末IDが記録される。また、錠前ID4004には、(該当のeKey40‐1に対応づけられた)利用対象の錠前デバイス10‐1のIDが記録される。また、有効期間4006には、該当のeKey40‐1に対して例えばオーナー端末のユーザにより設定された有効期間が記録される。例えば、有効期間4006には、該当のeKey40‐1の利用可能な日にち、曜日、または、時間帯などが記録される。なお、図5では、有効期間4006として、有効期間が無制限であることを意味する「ALWAYS」が登録されている例を示している。
【0040】
また、権限設定情報4008‐1には、錠前デバイス10‐1が有する複数の種類の機能の各々に関して、該当のeKey40‐1の発行対象であるユーザ端末20‐1に設定された権限の情報が記録される。例えば、権限設定情報4008‐1には、錠前デバイス10‐1が有する複数の種類の機能の各々に関するユーザ端末20‐1の権限の有無が格納される。ここで、図6を参照して、権限設定情報4008‐1の構成例について説明する。図6に示したように、権限設定情報4008‐1には、例えば、解錠および施錠、時刻情報の閲覧や変更、例えばスピーカーやLED(Light Emitting Diode)などの、錠前デバイスが有する複数の機器の各々の設定情報の閲覧や変更、後述する操作ログDB130に格納されるログ情報の閲覧または変更、または、サムターンの回転量に関する設定などに関するユーザ端末20‐1の権限の有無(ON/OFF)が格納される。
【0041】
また、(図5に示した)端末公開鍵4020には、該当のeKey40‐1の発行対象のユーザ端末20‐1の公開鍵が記録される。また、公開鍵の証明書4022には、端末公開鍵4020に格納されている公開鍵に対する、例えばeKey40‐1を発行したユーザ端末20‐1a(つまりオーナー端末)による署名情報が記録される。
【0042】
なお、図5では、端末公開鍵4020、および、公開鍵の証明書4022がそれぞれ一つずつ格納される例を示しているが、かかる例に限定されない。例えば、端末公開鍵4020、および、公開鍵の証明書4022には、複数の種類の公開鍵認証アルゴリズムにより生成されたユーザ端末20‐1の公開鍵、および、当該ユーザ端末20‐1の公開鍵に対するオーナー端末による署名情報がそれぞれ格納されてもよい。
【0043】
(1−2−1−4.認証情報検証部106)
認証情報検証部106は、本開示における検証処理部の一例である。認証情報検証部106は、ユーザ端末20‐1の秘密鍵により生成された情報(以下、レスポンスデータとも称する)が受信された場合に、受信された情報の正当性をユーザ端末20‐1の公開鍵、および所定の公開鍵認証アルゴリズムに基づいて検証する。例えば、後述するチャレンジ生成部112により生成されたチャレンジがユーザ端末20‐1に送信された後に、レスポンスデータがユーザ端末20‐1から受信された場合には、認証情報検証部106は、ユーザ端末20‐1の公開鍵、元のチャレンジ、および、所定の公開鍵認証アルゴリズムに基づいて、受信されたレスポンスデータの正当性を検証する。
【0044】
また、認証情報検証部106は、ユーザ端末20‐1から受信されたeKeyに含まれる、ユーザ端末20‐1の公開鍵に対する署名情報を復号化することが可能である。例えば、認証情報検証部106は、受信されたeKeyに含まれる、ユーザ端末20‐1bの公開鍵に対するユーザ端末20‐1a(オーナー端末)による署名情報を、オーナー情報ファイル128に格納されているユーザ端末20‐1aの公開鍵を用いて復号化する。
【0045】
(1−2−1−5.判定部108)
判定部108は、ユーザ端末20‐1から受信されたeKeyが鍵情報検証部104により検証された結果、および該当のeKeyに含まれるユーザ端末20‐1の権限設定情報の内容に基づいて、ユーザ端末20‐1から受信された処理要求を許可するか否かを判定する。例えば、ユーザ端末20‐1の公開鍵が正当であることが鍵情報検証部104により判定され、かつ、受信された処理要求に関してユーザ端末20‐1の権限が有ることが該当の権限設定情報に格納されている場合には、判定部108は、受信された処理要求を許可する。一例として、ユーザ端末20‐1の公開鍵が正当であることが判定され、かつ、受信された処理要求に関してユーザ端末20‐1の権限が有ることが該当の権限設定情報に格納されており、かつ、受信されたレスポンスデータが正当であることが認証情報検証部106により判定された場合には、判定部108は、受信された処理要求を許可する。また、上記の条件のうち少なくともいずれかを満たさない場合には、判定部108は、受信された処理要求を許可しない。
【0046】
(1−2−1−6.処理実行部110)
処理実行部110は、判定部108による判定結果に基づいて、受信された処理要求に応じた処理を実行する。例えば、受信された処理要求が、施錠部122に対する解錠要求または施錠要求であり、かつ、当該処理要求を許可することが判定部108により判定された場合には、処理実行部110は、施錠部122に解錠または施錠させる。
【0047】
(1−2−1−7.チャレンジ生成部112)
チャレンジ生成部112は、例えば所定の範囲内の一様乱数などであるチャレンジを生成する。例えば、チャレンジ生成部112は、ユーザ端末20‐1から受信されたeKeyに含まれる公開鍵が正当であることが鍵情報検証部104により判定された場合に、チャレンジを生成する。
【0048】
(1−2−1−8.送信制御部114)
送信制御部114は、各種の情報をユーザ端末20‐1へ通信部120に送信させる。例えば、送信制御部114は、チャレンジ生成部112により生成されたチャレンジをユーザ端末20‐1へ通信部120に送信させる。
【0049】
(1−2−1−9.通信部120)
通信部120は、例えばBLE(Bluetooth Low Energy)などのBluetooth、Wi‐Fi(登録商標)、NFC(Near Field Communication)などに沿った無線通信により、他の装置との間で情報の送受信を行う。例えば、通信部120は、送信制御部114の制御により、チャレンジをユーザ端末20‐1へ送信する。また、通信部120は、eKey、処理要求、または、レスポンスデータなどをユーザ端末20‐1から受信する。
【0050】
(1−2−1−10.施錠部122)
施錠部122は、処理実行部110の制御に従って、施錠処理または解錠処理を行う。
【0051】
(1−2−1−11.記憶部124)
記憶部124は、例えば、錠前鍵ファイル126、オーナー情報ファイル128、および、後述する操作ログDB130などの各種のデータや、各種のソフトウェアを記憶することが可能である。
【0052】
‐操作ログDB130
操作ログDB130は、錠前デバイス10‐1に対する個々のユーザ端末20‐1の操作ログが格納されるデータベースである。例えば、操作ログDB130では、操作日時、ユーザ端末20‐1の端末ID、および、操作内容が対応付けて格納される。なお、操作ログDB130には、錠前デバイス10‐1に対するユーザ端末20‐1を用いた操作の履歴だけでなく、例えば錠前デバイス10‐1に含まれるつまみやボタンなどに対するユーザの手動操作の履歴も格納され得る。
【0053】
[1−2−2.ユーザ端末20‐1]
図7は、第1の実施形態によるユーザ端末20‐1の構成を示した機能ブロック図である。図7に示したように、ユーザ端末20‐1は、制御部200‐1、通信部220、操作表示部222、撮像部224、および記憶部226を有する。
【0054】
(1−2−2−1.制御部200‐1)
制御部200‐1は、ユーザ端末20‐1に内蔵される、例えばCPU、RAMなどのハードウェアを用いて、ユーザ端末20‐1の動作を全般的に制御する。また、図7に示したように、制御部200‐1は、二次元コード読み取り部202、電子署名部204、鍵情報発行部206、認証処理部208、操作認識部210、および、送信制御部212を有する。
【0055】
(1−2−2−2.二次元コード読み取り部202)
二次元コード読み取り部202は、後述する撮像部224により撮影された二次元コードの画像を解析することにより、二次元コードに格納されている情報を取得する。例えば、二次元コード読み取り部202は、特定のユーザに提供される、例えば図8に示したようなオーナー登録カードに印刷されている二次元コードが、撮像部224により撮影された画像を解析し、そして、二次元コードに格納されている錠前デバイス10‐1の共通鍵、公開鍵、および秘密鍵などの情報を取得する。なお、特定のユーザは、錠前デバイス10‐1に対してオーナー情報の登録を行うことが予め許可されたユーザであり、例えば、錠前デバイス10‐1の購入者などである。また、オーナー登録カードは、例えば、錠前デバイス10‐1と一緒に梱包された状態で特定のユーザ宛てに配送されてもよい。
【0056】
(1−2−2−3.電子署名部204)
電子署名部204は、ユーザ端末20‐1aがオーナー端末としてサーバ30‐1に登録されている場合には、別のユーザ端末20‐1bの公開鍵または自端末(ユーザ端末20‐1a)の公開鍵に対して電子署名を行うことが可能である。例えば、上記の場合には、電子署名部204は、ユーザ端末20‐1bの公開鍵をユーザ端末20‐1aの秘密鍵に基づいて暗号化することにより電子署名を行う。
【0057】
(1−2−2−4.鍵情報発行部206)
鍵情報発行部206は、ユーザ端末20‐1aがオーナー端末として登録されている場合には、別のユーザ端末20‐1bまたは自端末と対応づけてeKeyを発行することが可能である。例えば、別のユーザ端末20‐1bに対するeKeyの発行要求が、後述するサーバ30‐1から受信された場合に、鍵情報発行部206は、ユーザ端末20‐1bと対応づけてeKeyを発行する。より具体的には、鍵情報発行部206は、上記の場合には、電子署名部204により生成される、ユーザ端末20‐1bの公開鍵に対する署名情報を含むようにeKeyを発行する。
【0058】
(1−2−2−5.認証処理部208)
認証処理部208は、例えば錠前デバイス10‐1から受信されるチャレンジおよび所定の公開鍵認証アルゴリズムに基づいてレスポンスデータを生成する。例えば、認証処理部208は、受信されたチャレンジ、後述する記憶部226に記憶されているユーザ端末20‐1の秘密鍵、および、所定の公開鍵認証アルゴリズムに基づいてレスポンスデータを生成する。なお、所定の公開鍵認証アルゴリズムは、基本的には、錠前デバイス10‐1に実装されている公開鍵認証アルゴリズムと同じ種類のアルゴリズムである。
【0059】
(1−2−2−6.操作認識部210)
操作認識部210は、例えば後述する操作表示部222に対するユーザによりなされた各種の操作の内容を認識する。例えば、操作認識部210は、操作表示部222に表示される処理要求画面においてユーザにより入力された錠前デバイス10‐1に対する処理要求の内容を認識する。
【0060】
図9は、処理要求画面の一例(施解錠要求画面60)を示した説明図である。この施解錠要求画面60は、錠前デバイス10‐1に対して施錠または解錠を要求するための画面である。図9に示したように、施解錠要求画面60は、例えば、施錠アイコン600aおよび解錠アイコン600bを含む。この施解錠要求画面60において、例えば、施錠アイコン600aから解錠アイコン600bへのスワイプ操作をユーザが行った場合には、操作認識部210は、ユーザにより解錠要求が入力されたことを認識する。同様に、施解錠要求画面60において、解錠アイコン600bから施錠アイコン600aへのスワイプ操作をユーザが行った場合には、操作認識部210は、ユーザにより施錠要求が入力されたことを認識する。
【0061】
(1−2−2−7.送信制御部212)
送信制御部212は、各種の情報を錠前デバイス10‐1またはサーバ30‐1へ通信部220に送信させる。例えば、送信制御部212、操作認識部210により認識された処理要求を錠前デバイス10‐1へ通信部220に送信させる。また、送信制御部212は、認証処理部208により生成されたレスポンスデータを錠前デバイス10‐1へ通信部220に送信させる。また、送信制御部212は、鍵情報発行部206により発行された別のユーザ端末20‐1bのeKeyをサーバ30‐1へ通信部220に送信させる。
【0062】
(1−2−2−8.通信部220)
通信部220は、例えばBluetooth、Wi‐Fi、NFCなどに沿った無線通信により、他の装置との間で情報の送受信を行う。例えば、通信部220は、送信制御部212の制御により、認証処理部208により生成されたレスポンスデータを錠前デバイス10‐1へ送信する。また、ユーザ端末20がオーナー端末以外の端末である場合に、通信部220は、オーナー端末により発行されたeKeyをサーバ30‐1から受信する。
【0063】
(1−2−2−9.操作表示部222)
操作表示部222は、例えばタッチパネル型のディスプレイから構成される。この操作表示部222は、制御部200‐1の制御により、各種の表示画面を表示する。また、操作表示部222は、例えば表示画面に表示されている選択ボタンの選択など、ユーザによる各種の入力を受け付ける。
【0064】
(1−2−2−10.撮像部224)
撮像部224は、外部の映像を、レンズを通して例えばCCD(Charge Coupled Device)やCMOS(Complementary Metal Oxide Semiconductor)などの撮像素子に結像させることにより、デジタル画像として記録する。
【0065】
(1−2−2−11.記憶部226)
記憶部226は、例えば、ユーザ端末20‐1の公開鍵および秘密鍵や、ユーザ端末20‐1に発行されたeKeyなどの各種のデータ、および、各種のソフトウェアを記憶する。
【0066】
[1−2−3.サーバ30‐1]
図10は、第1の実施形態によるサーバ30‐1の構成を示した機能ブロック図である。図10に示したように、サーバ30‐1は、制御部300‐1、通信部320、および記憶部322を有する。
【0067】
(1−2−3−1.制御部300‐1)
制御部300‐1は、サーバ30‐1に内蔵される例えばCPU、RAMなどのハードウェアを用いて、サーバ30‐1の動作を全般的に制御する。また、図10に示したように、制御部300‐1は、情報登録部302、鍵情報発行要求部304、送信制御部306、チャレンジ生成部308、認証情報検証部310、および、認証部312を有する。
【0068】
(1−2−3−2.情報登録部302)
情報登録部302は、錠前デバイス10‐1の公開鍵、ユーザ端末20‐1の端末ID、およびユーザ端末20‐1の公開鍵がユーザ端末20‐1から受信された場合に、受信された端末IDのユーザ端末20‐1を、受信された錠前デバイス10‐1の公開鍵に対応する錠前デバイス10‐1のオーナー端末として登録する。
【0069】
また、情報登録部302は、オーナー端末としてユーザ端末20‐1を登録した際に、ユーザ端末20‐1から受信された錠前デバイス10‐1の公開鍵に対応する錠前デバイス10‐1の錠前IDと、錠前デバイス10‐1の公開鍵と、ユーザ端末20‐1の公開鍵とを対応づけて、後述するオーナー情報DB324に格納する。なお、錠前デバイス10‐1の錠前IDと錠前デバイス10‐1の公開鍵との対応関係は、例えばシステム管理者により予めオーナー情報DB324に登録されていてもよいし、または、登録されていなくてもよい。
【0070】
‐オーナー情報DB324
オーナー情報DB324は、例えば製造済みの個々の錠前デバイス10‐1に関して、情報登録部302によりオーナー端末として登録されたユーザ端末20‐1の情報が格納されるデータベースである。このオーナー情報DB324は、例えばデータベース32に保存されている。
【0071】
ここで、図11を参照して、オーナー情報DB324の構成例について説明する。図11に示したように、オーナー情報DB324では、例えば、錠前ID3240、錠前公開鍵3242、端末ID3244、および、端末公開鍵3246が対応づけられている。ここで、錠前ID3240には、ユーザ端末20から受信された錠前デバイス10‐1の公開鍵に対応づけて例えばデータベース32に登録されている錠前IDが格納される。あるいは、ユーザ端末20から錠前デバイス10‐1の公開鍵と一緒に錠前デバイス10‐1の錠前IDが受信された場合には、錠前ID3240には、ユーザ端末20から受信された錠前デバイス10‐1の錠前IDが格納されてもよい。
【0072】
また、錠前公開鍵3242には、受信された錠前デバイス10‐1の公開鍵が格納される。また、端末ID3244には、受信されたユーザ端末20‐1の端末IDが格納される。また、端末公開鍵3246には、受信されたユーザ端末20‐1の公開鍵が格納される。
【0073】
なお、図11では、端末公開鍵3246には、該当の端末IDのユーザ端末20‐1の公開鍵が一つだけ格納される例を記載しているが、かかる例に限定されない。変形例として、端末公開鍵3246には、該当の端末IDのユーザ端末20‐1に対応付けて生成された複数の種類の公開鍵認証アルゴリズム用の公開鍵が格納されてもよい。
【0074】
(1−2−3−3.鍵情報発行要求部304)
鍵情報発行要求部304は、オーナー端末として登録されているユーザ端末20‐1からeKeyURLの生成依頼が受信された場合に、eKeyURLを生成する。なお、eKeyURLは、(オーナー端末として登録されている)ユーザ端末20‐1が発行可能なeKeyに対応するリンク情報である。ここで、eKeyURLと、eKeyURLに対応付けてユーザ端末20により発行されるeKeyとの関係は、1対Nの関係である。例えば、eKeyURLは、例えばクリスマスパーティなどの一つのイベントに対応する。そして、ユーザ端末20‐1は、当該イベントに参加する複数のユーザそれぞれに対して当該イベント用の別々のeKeyを発行することが可能である。
【0075】
また、生成済みのeKeyURLをオーナー端末以外のユーザ端末20‐1bから受信した場合に、鍵情報発行要求部304は、受信したeKeyURLに対応するeKeyの、オーナー端末に対する発行要求を生成する。
【0076】
(1−2−3−4.送信制御部306)
送信制御部306は、各種の情報をユーザ端末20‐1へ通信部320に送信させる。例えば、送信制御部306は、鍵情報発行要求部304により生成された、eKeyの発行要求をオーナー端末として登録されているユーザ端末20‐1へ通信部320に送信させる。
【0077】
(1−2−3−5.チャレンジ生成部308)
チャレンジ生成部308は、例えば所定の範囲内の一様乱数などであるチャレンジを生成する。例えば、チャレンジ生成部308は、オーナー端末の登録要求がユーザ端末20‐1から受信された場合に、チャレンジを生成する。
【0078】
(1−2−3−6.認証情報検証部310)
認証情報検証部310は、レスポンスデータがユーザ端末20‐1から受信された場合に、受信されたレスポンスデータの正当性をユーザ端末20‐1の公開鍵、および所定の公開鍵認証アルゴリズムに基づいて検証する。例えば、チャレンジ生成部308により生成されたチャレンジがユーザ端末20‐1に送信された後に、ユーザ端末20‐1からレスポンスデータが受信された場合には、認証情報検証部310は、ユーザ端末20‐1の公開鍵、元のチャレンジ、および、所定の公開鍵認証アルゴリズムに基づいて、受信されたレスポンスデータの正当性を検証する。なお、所定の公開鍵認証アルゴリズムは、基本的には、錠前デバイス10‐1に実装されている公開鍵認証アルゴリズムと同じ種類のアルゴリズムである。
【0079】
(1−2−3−7.認証部312)
認証部312は、ユーザ端末20‐1から受信されたレスポンスデータが認証情報検証部310により検証された結果に基づいて、ユーザ端末20‐1を認証する。例えば、認証部312は、受信されたレスポンスデータが認証情報検証部310により正当であると検証された場合には、ユーザ端末20‐1を認証し、また、正当ではないと検証された場合にはユーザ端末20‐1を認証しない。
【0080】
(1−2−3−8.通信部320)
通信部320は、例えば通信網22に接続されている他の装置との間で情報の送受信を行う。例えば、通信部320は、送信制御部306の制御により、eKeyの発行要求を該当のeKeyの発行権限を有するユーザ端末20‐1へ送信する。
【0081】
(1−2−3−9.記憶部322)
記憶部322は、各種のデータやソフトウェアを記憶する。なお、変形例として、記憶部322は、データベース32を記憶することも可能である。
【0082】
<1−3.動作>
以上、第1の実施形態による構成について説明した。続いて、第1の実施形態による動作について、図12図29を参照し、以下の流れで説明を行う。
1.全体の動作の流れ
2.アカウント登録時の動作
3.錠前デバイス10‐1へのオーナー登録時の動作
4.サーバ30‐1へのオーナー登録時の動作
5.自端末へのeKeyの発行時の動作
6.別のユーザ端末20‐1へのeKeyの発行時の動作
7.錠前デバイス10‐1への処理要求時の動作
【0083】
なお、図12図29では、特に明記しない限り、ユーザ端末20‐1aが錠前デバイス10‐1のオーナー端末として登録される(または、登録された)ユーザ端末20‐1であり、また、ユーザ端末20‐1bが、オーナー端末以外のユーザ端末20‐1である例を示している。
【0084】
[1−3−1.全体の動作の流れ]
図12は、第1の実施形態による全体の動作の流れを示したシーケンス図である。図12に示したように、まず、ユーザ端末20‐1aおよびユーザ端末20‐1bは、各ユーザの操作に基づいて例えばサーバ30‐1にアクセスし、そして、鍵共有サービスを利用するための専用アプリケーションをそれぞれダウンロードする。そして、ユーザ端末20‐1aおよびユーザ端末20‐1bは、専用アプリケーションをインストールする(S2〜S4)。
【0085】
その後、ユーザ端末20‐1aの制御部100‐1は、例えばS2でインストールされた専用アプリケーションに対するユーザの操作に基づいて、ユーザ端末20‐1aの公開鍵および秘密鍵を生成する。そして、制御部100‐1は、生成した公開鍵および秘密鍵を記憶部226に格納する。その後、制御部200‐1は、専用アプリケーションに対するユーザの操作に基づいて、後述する「アカウント登録処理」をサーバ30‐1に対して行う(S6)。また、ユーザ端末20‐1aもS6と同様の動作を行う(S8)。
【0086】
その後、ユーザ端末20‐1aは、錠前デバイス10‐1へオーナー端末登録を要求するための、後述する「オーナー登録処理A」を行う(S10)。
【0087】
その後、ユーザ端末20‐1aは、錠前デバイス10‐1のオーナー端末の登録をサーバ30‐1へ要求するための、後述する「オーナー登録処理B」を行う(S11)。
【0088】
その後、ユーザ端末20‐1aは、ユーザ端末20‐1a自身へeKeyを発行するための、後述する「eKey発行処理A」を行う(S12)。
【0089】
その後、ユーザ端末20‐1aは、別のユーザ端末20‐1(ユーザ端末20‐1b)へeKeyを発行するための、後述する「eKey発行処理B」を行う(S13)。
【0090】
その後、ユーザ端末20‐1aは、錠前デバイス10‐1に対して例えば解錠処理などの各種の処理を要求するための、後述する「錠前への処理要求」を行う(S14)。
【0091】
[1−3−2.アカウント登録処理]
以上、全体の動作の流れについて説明した。次に、図13図16を参照して、S6(またはS8)における「アカウント登録処理」の動作について詳細に説明する。まず、ユーザ端末20‐1aは、起動中の専用アプリケーションの制御により、図13に示したようなアカウント登録画面70を表示する。図13に示したように、アカウント登録画面70は、例えば、アカウント名入力欄700、メールアドレス入力欄702、および、メール送信ボタン704を含む。このアカウント登録画面70において、ユーザは、所望のアカウント名、および、登録用のメールアドレスをそれぞれアカウント名入力欄700、および、メールアドレス入力欄702に入力し、そして、メール送信ボタン704を選択する。これにより、ユーザ端末20‐1aの送信制御部212は、入力されたアカウント名およびメールアドレスをサーバ30‐1へ通信部220に送信させる。なお、この際、送信制御部212は、さらに、ユーザ端末20の公開鍵をサーバ30‐1へ通信部220に送信させてもよい。
【0092】
その後、ユーザ端末20‐1aは、専用アプリケーションの制御により、図14に示したような本人確認画面72を表示する。また、送信制御部212は、メールアドレス入力欄702に入力されたメールアドレス宛てに、図15に示したようなレイアウトの電子メール74を送信する。
【0093】
図14に示したように、本人確認画面72は、パスコード入力欄720、および、パスコード送信ボタン722を含む。
【0094】
また、図15に示したように、電子メール74は、例えば、リンク選択ボタン740を含む。例えばPC(Personal Computer)やスマートフォンなどの端末は、ユーザの操作に基づいて電子メール74を表示する。そして、このリンク選択ボタン740がユーザにより選択されると、当該端末は、選択されたリンク選択ボタン740のリンク先の装置(図示省略)と通信することにより、例えば図16に示したようなパスコード表示画面76を表示する。図16に示したように、パスコード表示画面76は、例えば4ケタのパスコードを表示するパスコード表示欄760を含む。
【0095】
その後、ユーザは、パスコード表示欄760に表示されたパスコードを確認し、そして、ユーザ端末20に表示されている本人確認画面72のパスコード入力欄720に、確認したパスコードを入力する。そして、ユーザは、パスコード送信ボタン722を選択する。これにより、ユーザ端末20‐1aの認証処理部208は、入力されたパスコードをユーザ端末20の秘密鍵に基づいて暗号化する。そして、通信部220は、送信制御部212の制御に従って、暗号化された情報をサーバ30‐1へ送信する。
【0096】
その後、サーバ30‐1は、受信されたパスコードの正当性を、予め受信されているユーザ端末20の公開鍵に基づいて検証する。そして、正当であることが検証された場合には、サーバ30‐1は、(アカウント登録画面70において送信された)アカウントを、ユーザ端末20の端末IDと対応付けてデータベース32に格納する。
【0097】
(1−3−2−1.効果)
上述した動作例によれば、電子メール74を見て、そして、リンク選択ボタン740を明示的に選択した(正当な)ユーザだけがアカウント登録を行うことができる。このため、悪意のあるユーザによりサーバ30‐1に対して不正にアカウント登録されることを防止することができる。例えば、悪意のあるユーザが、仮に図13に示したアカウント登録画面70において、攻撃対象の別のユーザのメールアドレスを入力し、そして、図14に示したパスコード入力欄720において確認コードを総当たりで入力したとしても、(リンク選択ボタン740が選択されていないので)アカウントが登録されることがない。
【0098】
[1−3−3.錠前デバイス10‐1へのオーナー登録時の動作]
次に、図17を参照して、(図12に示した)S10における「オーナー登録処理A」の動作について詳細に説明する。なお、この動作は、オーナー登録カードが提供されたユーザのユーザ端末20‐1を錠前デバイス10‐1のオーナー端末として錠前デバイス10‐1に登録する際の動作である。また、この動作は、個々の錠前デバイス10‐1に関して、各錠前デバイス10‐1に対応するオーナー登録カードが提供されたユーザにより原則として一回だけ実施される。
【0099】
図17に示したように、例えば錠前デバイス10‐1と一緒に梱包された状態で配送されたオーナー登録カード内に印刷された二次元バーコードを、ユーザ端末20‐1aの撮像部224は、操作表示部222に対するユーザの操作に基づいて撮影する(S1001)。そして、二次元コード読み取り部202は、撮影された画像を解析することにより、二次元コードに格納されている錠前デバイス10‐1の共通鍵、公開鍵、および秘密鍵を取得する(S1003)。
【0100】
続いて、通信部220は、送信制御部212の制御に従って、S1003で取得された錠前デバイス10‐1の共通鍵、公開鍵、および秘密鍵と、ユーザ端末20‐1aの端末IDと、ユーザ端末20‐1aの公開鍵とを含むオーナー登録要求を錠前デバイス10‐1へ送信する(S1005)。
【0101】
その後、錠前デバイス10‐1の制御部100‐1は、錠前デバイス10‐1のオーナー端末がすでに登録されているか否かを確認する(S1007)。例えば、制御部100‐1は、オーナー情報ファイル128が作成済みであるか否かを確認する。
【0102】
オーナー端末がすでに登録されている場合には(S1007:Yes)、錠前デバイス10‐1は、後述するS1011の動作を行う。
【0103】
一方、オーナー端末がまだ登録されていない場合には(S1007:No)、次に、情報登録部102は、S1005で受信された共通鍵と、錠前鍵ファイル126に格納されている錠前デバイス10‐1の共通鍵とを比較する(S1009)。比較結果が一致しない場合には(S1009:No)、情報登録部102は、Result(=登録結果)に「NG」を設定する(S1011)。その後、錠前デバイス10‐1は、後述するS1019の動作を行う。
【0104】
一方、比較結果が一致する場合には(S1009:Yes)、情報登録部102は、Resultに「OK」を設定する(S1013)。次に、情報登録部102は、S1005で受信された錠前デバイス10‐1の公開鍵および秘密鍵を錠前鍵ファイル126に追加する(S1015)。そして、情報登録部102は、オーナー情報ファイル128を作成し、そして、S1005で受信されたユーザ端末20‐1aの端末IDおよび公開鍵を、作成したオーナー情報ファイル128に格納する(S1017)。
【0105】
その後、通信部120は、送信制御部114の制御に従って、S1011またはS1013で設定されたResultをユーザ端末20‐1aへ送信する(S1019)。
【0106】
[1−3−4.サーバ30‐1へのオーナー登録時の動作]
次に、図18を参照して、(図12に示した)S11における「オーナー登録処理B」の動作について詳細に説明する。なお、この動作は、錠前デバイス10‐1によりオーナー端末として登録されたユーザ端末20‐1aが、該当の錠前デバイス10‐1のオーナー端末の登録要求をサーバ30‐1に対して行う動作である。また、この動作は、個々の錠前デバイス10‐1に関して、オーナー端末の登録がされた各ユーザ端末20‐1により原則としてそれぞれ一回ずつ実施される。
【0107】
図18に示したように、まず、ユーザ端末20‐1aは、サーバ30‐1へアクセスする。そして、ユーザ端末20‐1aの通信部220は、送信制御部212の制御に従って、登録対象の錠前デバイス10‐1の公開鍵、ユーザ端末20‐1aの端末ID、および、ユーザ端末20‐1aの公開鍵を含むオーナー登録要求をサーバ30‐1へ送信する(S1101)。
【0108】
その後、サーバ30‐1のチャレンジ生成部308は、例えば一様乱数であるチャレンジを生成する(S1103)。そして、通信部320は、送信制御部306の制御に従って、S1103で生成されたチャレンジをユーザ端末20‐1aへ送信する(S1105)。
【0109】
その後、ユーザ端末20‐1aの認証処理部208は、S1105で受信されたチャレンジ、該当の錠前デバイス10‐1の秘密鍵、および、所定の公開鍵認証アルゴリズムに基づいてレスポンスデータを生成する(S1107)。そして、通信部220は、送信制御部212の制御に従って、S1107で生成されたレスポンスデータをサーバ30‐1へ送信する(S1109)。
【0110】
その後、サーバ30‐1の認証情報検証部310は、S1109で受信されたレスポンスデータを、S1101で受信された錠前デバイス10‐1の公開鍵、S1103で生成されたチャレンジ、および所定の公開鍵認証アルゴリズムに基づいて検証する(S1111)。受信されたレスポンスデータが正当ではないと判定された場合には(S1113:No)、認証部312は、Result(=認証結果)に「NG」を設定する(S1115)。その後、サーバ30‐1は、後述するS1125の動作を行う。
【0111】
一方、受信されたレスポンスデータが正当であると判定された場合には(S1113:Yes)、認証部312は、Resultに「OK」を設定する(S1117)。そして、通信部320は、送信制御部306の制御に従って、S1101で受信された錠前デバイス10‐1の公開鍵、ユーザ端末20‐1aの端末ID、および、ユーザ端末20‐1aの公開鍵を含むオーナー登録要求をデータベース32へ送信する(S1119)。
【0112】
その後、データベース32は、S1119で受信された錠前デバイス10‐1の公開鍵に対応する錠前IDを検索する(S1121)。そして、データベース32は、S1121で特定した錠前IDと、S1119で受信されたユーザ端末20‐1aの端末IDと、ユーザ端末20‐1aの公開鍵とを対応づけて記憶する(S1123)。
【0113】
また、サーバ30‐1の通信部320は、送信制御部306の制御に従って、S1115またはS1117で設定されたResultをユーザ端末20‐1aへ送信する(S1125)。
【0114】
[1−3−5.自端末へのeKeyの発行時の動作]
次に、図19を参照して、(図12に示した)S12における「eKey発行処理A」の動作について詳細に説明する。なお、この動作は、サーバ30‐1へのオーナー端末の登録が完了したユーザ端末20‐1aが自端末にeKeyを発行する際の動作である。
【0115】
図19に示したように、まず、ユーザ端末20‐1aの鍵情報発行部206は、発行対象のeKeyに対応するeKeyIDを生成する(S1201)。
【0116】
続いて、電子署名部204は、ユーザ端末20‐1aの公開鍵に対してユーザ端末20‐1aの秘密鍵を用いて電子署名を行うことにより、ユーザ端末20‐1aの公開鍵の証明書を生成する(S1203)。
【0117】
続いて、鍵情報発行部206は、S1201で生成されたeKeyIDと、ユーザ端末20‐1aの端末IDと、S1203で生成された公開鍵の証明書とを含むeKeyを発行する(S1205)。そして、鍵情報発行部206は、発行したeKeyを記憶部226に格納する(S1207)。
【0118】
[1−3−6.別のユーザ端末20‐1へのeKeyの発行時の動作]
次に、図20図22を参照して、(図12に示した)S13における「eKey発行処理B」の動作について詳細に説明する。なお、この動作は、オーナー端末として登録されたユーザ端末20‐1aが、別のユーザ端末20‐1(ユーザ端末20‐1b)にeKeyを発行する際の動作である。具体的なユースケースとしては、「12/25 18:00からのクリスマスパーティ用のeKey」や、「8/10〜8/13の3泊4日で宿泊客を滞在させるためのeKey」などをユーザ端末20‐1aがユーザ端末20‐1bに発行する例が挙げられる。
【0119】
図20に示したように、まず、ユーザ端末20‐1aの鍵情報発行部206は、例えば操作表示部222に対するユーザの入力に基づいて、該当の錠前デバイス10‐1に対応づけられるeKeyURLの生成依頼を作成する。なお、この際、(該当のeKeyURLに対応付けて発行される)eKeyの有効期限、および、錠前デバイス10‐1の各機能に関してユーザ端末20‐1bに設定される権限の情報がユーザにより指定され、そして、鍵情報発行部206は、指定された情報を含むように、eKeyURLの生成依頼を作成する。
【0120】
そして、通信部220は、送信制御部212の制御に従って、作成されたeKeyURLの生成依頼をサーバ30‐1へ送信する(S1301)。
【0121】
その後、サーバ30‐1の鍵情報発行要求部304は、S1301で受信された生成依頼に基づいて、ユーザ端末20‐1aが発行可能なeKeyに対応するeKeyURLを生成する(S1303)。そして、通信部320は、送信制御部306の制御に従って、S1303で生成されたeKeyURLをユーザ端末20‐1aへ送信する(S1305)。
【0122】
その後、ユーザ端末20‐1aは、操作表示部222に対するユーザの操作に基づいて、例えば、S1305で受信されたeKeyURLを含む電子メールをユーザ端末20‐1b宛てに送信したり、または、該当のeKeyURLをSNS(Social Networking Service)やホームページなどで公開する(S1307)。これにより、該当のeKeyURLがユーザ端末20‐1bのユーザに伝達される。なお、eKeyURL自体は、eKeyとは異なり、錠前デバイス10‐1に対して各種の処理要求を行う権限を一切有しない。このため、eKeyURLが公開されることにより、第三者がeKeyURLを取得したとしても、第三者が錠前デバイス10‐1に対して解錠要求を行うことはできない。
【0123】
その後、ユーザ端末20‐1bのユーザがeKeyの取得を望む場合には、操作表示部222に対してeKeyの発行要求の入力を行う。そして、ユーザ端末20‐1bの通信部220は、送信制御部212の制御に従って、S1307で共有されたeKeyURLと、ユーザ端末20‐1bの端末IDとを含むeKey発行リクエストをサーバ30‐1へ送信する(S1309)。
【0124】
その後、サーバ30‐1の通信部220は、鍵情報発行要求部304の制御に従って、S1309で受信されたユーザ端末20‐1bの端末IDに対応する身元情報の取得要求をデータベース32へ送信する(S1311)。
【0125】
その後、データベース32は、S1311で受信されたユーザ端末20‐1bの端末IDに対応づけて予め格納されているユーザ端末20‐1bの身元情報を抽出し、そして、抽出した身元情報をサーバ30‐1へ送信する(S1313)。
【0126】
その後、サーバ30‐1の鍵情報発行要求部304は、S1309で受信されたeKeyURLおよびユーザ端末20‐1bの端末IDと、S1313で受信されたユーザ端末20‐1bの身元情報とを含むeKey発行リクエストを生成する。そして、通信部320は、送信制御部306の制御に従って、生成されたeKey発行リクエストをユーザ端末20‐1aへ送信する(S1315)。
【0127】
その後、ユーザ端末20‐1aのユーザは、操作表示部222に表示される、S1315で受信されたeKey発行リクエストの内容に基づいて、eKeyの発行を承認するか否かを入力する(S1317)。eKeyの発行を承認しないことが入力された場合には(S1317:No)、当該「eKey発行処理B」の動作は終了する。
【0128】
一方、eKeyの発行を承認することが入力された場合には(S1317:Yes)、鍵情報発行部206は、発行対象のeKeyに対応するeKeyIDを生成する(S1319)。
【0129】
ここで、図21を参照して、S1319より後の動作について説明する。図21に示したように、S1319の後、ユーザ端末20‐1aの制御部200‐1は、ユーザ端末20‐1bの公開鍵が記憶部226に格納されているか否かを確認する(S1321)。ユーザ端末20‐1bの公開鍵が記憶されている場合には(S1321:Yes)、ユーザ端末20‐1aは、後述するS1331の動作を行う。
【0130】
一方、ユーザ端末20‐1bの公開鍵が記憶されていない場合には(S1321:No)、通信部220は、鍵情報発行部206の制御に従って、ユーザ端末20‐1bの端末IDを含む公開鍵参照リクエストをサーバ30‐1へ送信する(S1323)。
【0131】
その後、サーバ30‐1の通信部220は、鍵情報発行要求部304の制御に従って、S1323で受信された端末IDに対応する公開鍵の取得要求をデータベース32へ送信する(S1325)。
【0132】
その後、データベース32は、S1325で受信された端末IDに対応づけて格納されているユーザ端末20‐1bの公開鍵を抽出する。そして、データベース32は、抽出した公開鍵をサーバ30‐1へ送信する(S1327)。
【0133】
その後、サーバ30‐1の通信部320は、送信制御部306の制御に従って、S1327で受信されたユーザ端末20‐1bの公開鍵をユーザ端末20‐1aへ送信する(S1329)。
【0134】
その後、ユーザ端末20‐1aの電子署名部204は、S1329で受信された(もしくは、記憶部226に格納されている)ユーザ端末20‐1bの公開鍵に対してユーザ端末20‐1aの秘密鍵を用いて電子署名を行うことにより、ユーザ端末20‐1bの公開鍵の証明書を生成する(S1331)。
【0135】
続いて、鍵情報発行部206は、S1319で生成されたeKeyIDと、ユーザ端末20‐1bの端末IDと、S1331で生成されたユーザ端末20‐1bの公開鍵の証明書とを含むeKeyを発行する(S1333)。そして、通信部220は、鍵情報発行部206の制御に従って、S1319で生成されたeKeyIDと、S1333で発行されたeKeyとをサーバ30‐1へ送信する(S1335)。
【0136】
その後、サーバ30‐1の通信部320は、送信制御部306の制御に従って、S1335で受信されたeKeyIDおよびeKeyを含む、eKeyの保存要求をデータベース32へ送信する(S1337)。
【0137】
その後、データベース32は、S1337で受信されたeKeyIDおよびeKeyを対応づけて記憶する(S1339)。
【0138】
ここで、図22を参照して、S1339より後の動作について説明する。図22に示したように、S1339の後、サーバ30‐1の送信制御部306は、S1335で受信されたeKeyIDを含む、eKeyの発行通知をユーザ端末20‐1bへPush通知する(S1341)。
【0139】
その後、ユーザ端末20‐1bの送信制御部212は、S1341で通知されたeKeyIDに対応するeKeyの取得要求を、例えば操作表示部222に対するユーザの入力に基づいてサーバ30‐1へ通信部220に送信させる(S1343)。
【0140】
その後、サーバ30‐1の通信部320は、送信制御部306の制御に従って、S1343で受信された取得要求に基づいて、eKeyの取得要求をデータベース32へ送信する(S1345)。
【0141】
その後、データベース32は、S1345で受信された取得要求に含まれるeKeyIDに対応するeKeyを抽出し、そして、抽出したeKeyをサーバ30‐1へ送信する(S1347)。
【0142】
その後、サーバ30‐1の通信部320は、送信制御部306の制御に従って、S1347で受信されたeKeyをユーザ端末20‐1bへ送信する(S1349)。
【0143】
[1−3−7.錠前デバイス10‐1への処理要求時の動作]
次に、図23図25を参照して、(図12に示した)S14における「錠前への処理要求」の動作について詳細に説明する。なお、この動作は、ある錠前デバイス10‐1に対応するeKeyを所有しているユーザ端末20‐1が錠前デバイス10‐1に接近し、そして、錠前デバイス10‐1に何らかの処理を要求する際の動作である。以下では、オーナー端末として登録されているユーザ端末20‐1aが解錠要求を行う際の動作例について説明するが、オーナー端末以外のユーザ端末20‐1bが解錠要求を行う際の動作例に関しても概略同様である。
【0144】
図23に示したように、まず、ユーザ端末20‐1aの通信部220は、送信制御部212の制御に従って、ユーザ端末20‐1aが記憶しているeKeyに対応するeKeyIDを含む、該当のeKeyの有効性の確認要求をサーバ30‐1へ送信する(S1401)。
【0145】
その後、サーバ30‐1の送信制御部306は、S1401で受信された確認要求に基づいて、eKeyの有効性の確認要求をデータベース32へ通信部320に送信させる(S1403)。
【0146】
その後、データベース32は、S1403で受信された確認要求に含まれるeKeyIDに対応するeKeyの有効性に関する情報を抽出し、そして、抽出した情報をサーバ30‐1へ送信する(S1405)。
【0147】
その後、サーバ30‐1の送信制御部306は、S1405で受信された情報に基づいた有効性の確認結果をユーザ端末20‐1aへ通信部320に送信させる(S1407)。
【0148】
その後、ユーザ端末20‐1aの制御部200‐1は、S1407で受信された確認結果に基づいてeKeyが有効であるか否かを判定する(S1409)。eKeyが有効ではないと判定された場合には(S1409:No)、当該「錠前への処理要求」の動作は終了する。
【0149】
一方、eKeyが有効であると判定された場合には(S1409:Yes)、錠前デバイス10‐1およびユーザ端末20‐1aは、後述する「処理要求判定処理」を行う(S1411)。
【0150】
ユーザ端末20‐1aに発行されているeKeyに含まれる権限設定情報において操作ログの閲覧権限が設定されており、かつ、S1411において錠前デバイス10‐1から操作ログが取得された場合には(S1413:Yes)、ユーザ端末20‐1aの送信制御部212は、該当の錠前デバイス10‐1の錠前IDと、S1411で取得された操作ログとをサーバ30‐1へ通信部220に(自動的に)送信させる(S1415)。
【0151】
その後、サーバ30‐1の通信部320は、送信制御部306の制御に従って、S1415で受信された操作ログの保存要求をデータベース32へ送信する(S1417)。
【0152】
その後、データベース32は、S1417で受信された保存要求に含まれる錠前IDと操作ログとを対応付けて記憶する(S1419)。これにより、例えば、オーナー端末は、サーバ30‐1にアクセスすることにより、他のユーザ端末20による錠前デバイス10‐1に対する操作のログを閲覧することが可能となる。
【0153】
(1−3−7−1.処理要求判定処理)
ここで、図24および図25を参照して、S1411における「処理要求判定処理」の動作について詳細に説明する。なお、以下で述べる認証処理は、錠前デバイス10‐1とユーザ端末20‐1aとの間で例えばBLEを用いて行われる。このため、ユーザ端末20‐1aがインターネットに接続されていない環境でも錠前デバイス10‐1はユーザ端末20‐1aと通信可能である。例えば、錠前デバイス10‐1が地下や山奥など、携帯電話の電波状況が悪い環境に設置されている場合であっても、錠前デバイス10‐1は、ユーザ端末20‐1aと通信可能である。
【0154】
図24に示したように、まず、錠前デバイス10‐1の通信部120は、送信制御部114の制御に従って、定期的に、錠前デバイス10‐1の錠前IDを周囲に発信する(S1501)。
【0155】
その後、ユーザ端末20‐1aが錠前デバイス10‐1に接近すると、ユーザ端末20‐1aは、S1501で発信されている錠前IDを受信し、そして、受信された錠前IDが、対象の錠前デバイス10‐1の錠前IDであるか否かを判定する。そして、対象の錠前デバイス10‐1である場合には、ユーザ端末20‐1aは、錠前デバイス10‐1とのセッションを確立する(S1503)。
【0156】
続いて、ユーザ端末20‐1aの認証処理部208は、所定の公開鍵認証アルゴリズムに基づいてコミットメントを生成する(S1505)。そして、送信制御部212は、例えば操作表示部222に対してユーザにより入力された処理要求と、記憶部226に記憶されているeKeyと、S1505で生成されたコメットメントとを錠前デバイス10‐1へ通信部220に送信させる(S1507)。
【0157】
その後、錠前デバイス10‐1の認証情報検証部106は、S1507で受信されたeKeyに含まれる公開鍵の証明書を、オーナー情報ファイル128に格納されているオーナー端末の公開鍵を用いて復号化する(S1509)。
【0158】
そして、鍵情報検証部104は、S1509で復号化された結果に基づいて、S1507で受信されたeKeyに含まれるユーザ端末20‐1aの公開鍵が正当であるか否かを判定する(S1511)。ユーザ端末20‐1aの公開鍵が正当ではないと判定された場合には(S1511:No)、錠前デバイス10‐1は、後述するS1533の動作を行う。
【0159】
一方、ユーザ端末20‐1aの公開鍵が正当であると判定された場合には(S1511:Yes)、次に、鍵情報検証部104は、受信されたeKeyに含まれる有効期間の情報を参照し、そして、現在が有効期間内であるか否かを判定する(S1513)。現在が有効期間外である場合には(S1513:No)、錠前デバイス10‐1は、後述するS1533の動作を行う。
【0160】
一方、現在が有効期間内である場合には(S1513:Yes)、次に、判定部108は、S1507で受信されたeKeyに含まれる権限設定情報を確認することにより、S1507で受信された処理要求に関する権限がユーザ端末20‐1aに設定されているか否かを確認する(S1521)。
【0161】
ここで、図25を参照して、S1521以後の動作について説明する。S1521において、受信された処理要求に関する権限がユーザ端末20‐1aに設定されていないことが確認された場合には(S1521:No)、錠前デバイス10‐1は、後述するS1533の動作を行う。
【0162】
一方、受信された処理要求に関する権限がユーザ端末20‐1aに設定されていることが確認された場合には(S1521:Yes)、チャレンジ生成部112は、例えば一様乱数であるチャレンジを生成する。そして、通信部120は、送信制御部114の制御に従って、生成されたチャレンジをユーザ端末20‐1aへ送信する(S1523)。
【0163】
その後、ユーザ端末20‐1aの認証処理部208は、S1523で受信されたチャレンジ、ユーザ端末20‐1aの秘密鍵、および所定の公開鍵認証アルゴリズムに基づいてレスポンスデータを生成する(S1525)。そして、通信部220は、送信制御部212の制御に従って、生成されたレスポンスデータを錠前デバイス10‐1へ送信する(S1527)。
【0164】
その後、錠前デバイス10‐1の認証情報検証部106は、S1507で受信されたeKeyに含まれるユーザ端末20‐1aの公開鍵と、S1507で受信されたコミットメントと、S1523で生成されたチャレンジと、所定の公開鍵認証アルゴリズムとに基づいて、S1527で受信されたレスポンスデータの正当性を検証する(S1529)。受信されたレスポンスデータが正当ではないと判定された場合には(S1531:No)、判定部108は、S1507で受信された処理要求を許可しない(S1533)。そして、錠前デバイス10‐1は、後述するS1537の動作を行う。
【0165】
一方、受信されたレスポンスデータが正当であると判定された場合には(S1531:Yes)、判定部108は、S1507で受信された処理要求を許可する。そして、処理実行部110は、処理要求に応じた処理を実行する(S1535)。
【0166】
その後、通信部120は、送信制御部114の制御に従って、S1533またはS1535の実行結果をユーザ端末20‐1aへ送信する(S1537)。
【0167】
<1−4.効果>
[1−4−1.効果1]
以上、例えば図2図12図29などを参照して説明したように、第1の実施形態による錠前デバイス10‐1は、錠前デバイス10‐1の複数の種類の機能に関するユーザ端末20‐1の権限設定情報を含むeKeyと、錠前デバイス10‐1に対する処理要求とをユーザ端末20‐1から受信し、そして、権限設定情報に基づいて、受信された処理要求を許可するか否かを判定する。このため、錠前デバイス10‐1は、ユーザ端末20‐1から受信される処理要求の可否を、錠前デバイス10‐1の複数の種類の機能に関してユーザ端末20‐1ごとに設定される権限に適応的に判定することができる。例えば、錠前デバイス10‐1は、オーナー端末以外のユーザ端末20‐1bには、ユーザ端末20‐1bの権限設定情報に基づいて、解錠および施錠のみを許可することができる。また、錠前デバイス10‐1は、オーナー端末であるユーザ端末20‐1aには、ユーザ端末20‐1aの権限設定情報に基づいて、解錠および施錠だけでなく、例えば、錠前デバイス10‐1に記憶されている時刻情報の変更や、操作ログDB130に格納されている操作ログの閲覧など、様々な種類の要求を許可することができる。
【0168】
[1−4−2.効果2]
また、錠前デバイス10‐1は、例えばユーザ端末20‐1の秘密鍵などの秘匿性の高い情報をユーザ端末20から受信することなくユーザ端末20‐1を認証できるので、認証の安全性が高い。
【0169】
さらに、オーナー端末の登録時においてユーザ端末20‐1は、錠前デバイス10‐1およびサーバ30‐1に、例えばユーザ端末20‐1の秘密鍵などの秘匿性の高い情報を登録しない。このため、錠前デバイス10‐1に対する処理要求時以外に関しても、秘匿性の高い情報が外部に漏えいすることを防止できる。
【0170】
[1−4−3.効果3]
また、錠前デバイス10‐1は、ユーザ端末20‐1bから受信されるeKeyに含まれる、オーナー端末であるユーザ端末20‐1aの署名情報をオーナー端末の公開鍵を用いて検証することにより、ユーザ端末20bの公開鍵の正当性を検証する。このため、錠前デバイス10‐1は、認証対象のユーザ端末20‐1bが、正当なeKeyを有するユーザ端末20‐1であるか否かを確認することができる。
【0171】
<1−5.変形例>
[1−5−1.変形例1]
なお、第1の実施形態は、上述した説明に限定されない。上記の説明では、オーナー登録カードに印刷された二次元コードに格納されている、錠前デバイス10‐1の共通鍵などの情報をユーザ端末20‐1が読み取ることにより、ユーザ端末20‐1が錠前デバイス10‐1およびサーバ30‐1に対してオーナー登録を行う例について説明した。
【0172】
ところで、二次元コードを読み取るためのアプリケーションがユーザ端末20‐1に実装されていない場合や、例えば高齢者など、二次元コードの読み取り方をユーザが知らない場合も想定される。
【0173】
後述するように、変形例1によれば、オーナー登録カードに印刷された二次元コードをユーザ端末20‐1が読み取らなくても、ユーザ端末20‐1は、錠前デバイス10‐1およびサーバ30‐1に対してオーナー登録を行うことが可能である。
【0174】
(1−5−1−1.構成)
図26は、変形例1によるオーナー登録カードの一例(オーナー登録カード50b)を示した説明図である。図26に示したように、オーナー登録カード50bには、二次元コード500と一緒に、二次元コード500に格納されている錠前デバイス10‐1の共通鍵のコード値502が直接印刷されている。なお、このオーナー登録カード50bの二次元コード500には、錠前デバイス10‐1の共通鍵のみが格納されており、錠前デバイス10‐1の公開鍵および秘密鍵は格納されていなくてもよい。
【0175】
また、変形例1による錠前デバイス10‐1には、例えば製品出荷時などの初期状態時において、錠前デバイス10‐1の共通鍵、公開鍵、および秘密鍵が格納されている。図27は、変形例1による、錠前鍵ファイル126における初期状態時の情報の格納例(錠前鍵ファイル126b)を示した説明図である。図27に示したように、錠前鍵ファイル126bには、図3に示した錠前鍵ファイル126aと比較して、初期状態時において、(錠前IDおよび錠前共通鍵だけでなく)錠前秘密鍵および錠前公開鍵も格納されている。
【0176】
なお、変形例1によるその他の構成については、上記の説明と同様である。
【0177】
(1−5−1−2.動作)
次に、変形例1による動作について説明する。以下では、変形例1による「オーナー登録処理A」の動作(S10)について、図28を参照して説明する。この動作は、図17に示した動作の代替となる動作である。ここでは、ユーザ端末20‐1aのユーザが、オーナー登録カードに印刷されている錠前デバイス10‐1の共通鍵のコード値をユーザ端末20‐1aに対して手入力する際の動作例について説明する。なお、その他の種類の動作については、上記の説明と同様であるので、説明を省略する。
【0178】
図28に示したように、まず、例えば錠前デバイス10‐1と一緒に梱包された状態で配送されたオーナー登録カードに印刷されている錠前デバイス10‐1の共通鍵のコード値を、ユーザ端末20‐1aのユーザは、操作表示部222に対して手入力する(S1601)。
【0179】
そして、送信制御部212は、例えば操作表示部222に対するユーザの操作に基づいて、S1601で入力された錠前デバイス10‐1の共通鍵(のコード値)と、ユーザ端末20‐1aの端末IDと、ユーザ端末20‐1aの公開鍵とを含むオーナー登録要求を錠前デバイス10‐1へ通信部220に送信させる(S1603)。
【0180】
なお、図28に示したS1605〜S1611の動作は、図17に示したS1007〜S1013と同様である。また、図28に示したS1613の動作は、図17に示したS1017と同様である。
【0181】
S1613の後、錠前デバイス10‐1の送信制御部114は、錠前鍵ファイル126に格納されている錠前デバイス10‐1の公開鍵および秘密鍵をユーザ端末20‐1aへ通信部120に送信させる(S1615)。これにより、ユーザ端末20‐1aは、錠前デバイス10‐1の公開鍵および秘密鍵を取得することができる。そして、例えば図18に示した動作と同様の流れにより、ユーザ端末20‐1aはサーバ30‐1へオーナー端末の登録を行うことができる。
【0182】
なお、図28に示したS1617の動作は、図17に示したS1019と同様である。
【0183】
(1−5−1−3.効果)
以上、図26図28を参照して説明したように、変形例1によれば、オーナー登録カードに印刷された錠前デバイス10‐1の共通鍵をユーザがユーザ端末20‐1に手入力することにより、ユーザ端末20‐1は、オーナー登録カードに印刷された二次元コードを読み取らなくても、錠前デバイス10‐1およびサーバ30‐1に対してオーナー登録を行うことができる。
【0184】
また、錠前デバイス10‐1の共通鍵のコード値が入力されたユーザ端末20‐1のみが錠前デバイス10‐1の公開鍵および秘密鍵を錠前デバイス10‐1から取得できるため、錠前デバイス10‐1の共通鍵のコード値を知らないユーザが不正にオーナー登録を行うことを防ぐことができる。
【0185】
なお、通常、錠前デバイス10‐1の共通鍵は128〜256bit程度であるので、ユーザは、錠前デバイス10‐1の共通鍵を苦労なく手入力することができる。
【0186】
[1−5−2.変形例2]
以上、変形例1について説明した。次に、変形例2について説明する。上述した第1の実施形態では、図20に示したように、オーナー端末であるユーザ端末20‐1aは、オーナー端末以外のユーザ端末20‐1bによりeKeyの発行を要求された場合に、ユーザ端末20‐1bに対してeKeyを発行する例について説明したが、本発明はかかる例に限定されない。
【0187】
後述するように、変形例2によれば、オーナー端末であるユーザ端末20‐1aが、別のユーザ端末20‐1bを自発的に指定し、そして、指定したユーザ端末20‐1bに対してeKeyを発行することが可能である。
【0188】
(1−5−2−1.動作)
図29は、変形例2による「eKey発行処理B」の動作(S13)の一部を示したシーケンス図である。この動作は、図20に示した動作の代替となる動作である。なお、その他の種類の動作については、上記の説明と同様であるので、説明を省略する。
【0189】
図29に示したS1701〜S1705の動作は、図20に示したS1301〜S1305と同様である。
【0190】
S1705の後、ユーザ端末20‐1aのユーザは、操作表示部222に対してeKeyの発行対象のユーザ端末20‐1bを指定する。そして、ユーザ端末20‐1aの鍵情報発行部206は、指定されたユーザ端末20‐1bの端末IDを、eKeyの発行対象のユーザ端末20‐1の端末IDに設定する(S1707)。
【0191】
なお、図29に示したS1709の動作は、図20に示したS1319と同様である。また、S1709より後の動作は、図21図22に示した動作と同様である。
【0192】
この変形例2によれば、図20に示したS1307〜S1317の処理を省略することができるという利点もある。
【0193】
<1−6.応用例>
以上、第1の実施形態について説明した。続いて、第1の実施形態の応用例について、図30図32を参照して説明する。
【0194】
[1−6−1.背景]
最初に、本応用例を創作するに至った背景について説明する。上述した第1の実施形態では、個々の錠前デバイス10‐1に対応するeKeyを発行可能なユーザ端末20‐1は、オーナー端末として登録されたユーザ端末20‐1aだけである。このため、例えば、オーナー端末のユーザであるオーナーユーザ2aが多数のゲストユーザ2b(オーナーユーザ2a以外のユーザ)に対してeKeyを発行することが求められる場面では、全てのゲストユーザ2bに対してeKeyを発行するのに時間がかかる。また、オーナーユーザ2aは、個々のゲストユーザ2bからのeKeyの発行要求に対して承認作業を行う必要があるので、オーナーユーザ2aの作業負荷が大きい。
【0195】
後述するように、本応用例によれば、オーナー端末は、eKeyに類似したサブeKeyの発行権限を別のユーザ端末20‐1bに与えることが可能である。なお、サブeKeyは、本開示におけるサブ鍵情報の一例である。
【0196】
[1−6−2.システム構成]
図30は、本応用例による情報処理システムの構成を示した説明図である。図30に示したように、本応用例による情報処理システムは、図1と比較して、ユーザ端末20‐1cをさらに有する。
【0197】
なお、その他の構成要素に関しては、上記の説明と同様である。
【0198】
[1−6−3.構成]
(1−6−3−1.錠前デバイス10‐1)
以上、本応用例による情報処理システムの構成について説明した。続いて、本応用例による構成について詳細に説明する。本応用例による錠前デバイス10‐1の構成は、図2に示した構成と概略同様である。以下では、上記の説明と異なる機能を有する構成要素についてのみ説明を行う。
【0199】
‐鍵情報検証部104
本応用例による鍵情報検証部104は、ユーザ端末20‐1から受信されるeKeyまたはサブeKeyの正当性を判定する。なお、具体的な判定方法については、上記の説明と概略同様である。
【0200】
‐‐eKey
ここで、図31を参照して、本応用例によるeKeyに含まれる権限設定情報の構成例(権限設定情報4008‐2)について説明する。図31に示したように、権限設定情報4008‐2には、図6に示した権限設定情報4008‐1と比較して、サブeKeyの発行に関するユーザ端末20‐1の権限の有無(ON/OFF)がさらに格納される。
【0201】
‐判定部108
本応用例による判定部108は、ユーザ端末20‐1からサブeKeyが受信された場合には、受信されたサブeKeyが鍵情報検証部104により検証された結果、および該当のサブeKeyに含まれるユーザ端末20‐1の権限設定情報に基づいて、ユーザ端末20‐1から受信された処理要求を許可するか否かを判定する。なお、具体的な判定方法については、上記の説明と概略同様である。
【0202】
(1−6−3−2.ユーザ端末20‐1)
また、本応用例によるユーザ端末20‐1の構成は、図7に示した構成と概略同様である。以下では、上記の説明と異なる機能を有する構成要素についてのみ説明を行う。
【0203】
‐鍵情報発行部206
本応用例による鍵情報発行部206は、ユーザ端末20‐1にeKeyが発行されており、かつ、当該eKeyにおいてサブeKeyの発行権限が登録されている場合には、別のユーザ端末20‐1cと対応づけてサブeKeyを発行することが可能である。例えば、鍵情報発行部206は、サブeKeyに含まれる情報の種類がeKeyと同一になるようにサブeKeyを発行する。さらに、鍵情報発行部206は、サブeKeyの発行対象のユーザ端末20‐1cに設定される権限が、ユーザ端末20‐1に発行されているeKeyにおいて設定されている権限以下となるようにサブeKeyを発行する。
【0204】
(1−6−3−3.サーバ30‐1)
本応用例によるサーバ30‐1の構成および機能は、上記の説明と概略同様である。
【0205】
[1−6−4.動作]
以上、本応用例による構成について説明した。続いて、本応用例による動作について図32を参照して説明する。なお、ここでは、オーナー端末ではないユーザ端末20‐1bが、別のユーザ端末20‐1cにサブeKeyを発行する場面の動作例について説明する。なお、1−3節で述べたその他の種類の動作については、本応用例でも同様であるので、説明を省略する。
【0206】
図32に示したように、まず、ユーザ端末20‐1bの鍵情報発行部206は、例えば操作表示部222に対してユーザによりサブeKeyの発行要求が入力された場合に、発行済みのeKeyが記憶部226に格納されているか否かを確認する(S1801)。eKeyが記憶部226に記憶されていない場合には(S1801:No)、本動作は終了する。
【0207】
一方、eKeyが記憶部226に記憶されている場合には(S1801:Yes)、鍵情報発行部206は、記憶されているeKeyに含まれる権限設定情報を確認することにより、サブeKeyの発行権限がユーザ端末20‐1bに設定されているか否かを確認する(S1803)。サブeKeyの発行権限がユーザ端末20‐1bに設定されていない場合には(S1803:No)、本動作は終了する。
【0208】
一方、サブeKeyの発行権限がユーザ端末20‐1bに設定されている場合には(S1803:Yes)、鍵情報発行部206は、該当の錠前デバイス10‐1に対応づけられるサブeKeyURLの生成依頼を作成する。なお、この際、(該当のサブeKeyURLに対応付けて発行される)サブeKeyの有効期限、および、錠前デバイス10‐1の各機能に関してユーザ端末20‐1cに設定される権限の情報がユーザ端末20‐1bのユーザにより指定され、そして、鍵情報発行部206は、指定された情報を含むように、サブeKeyURLの生成依頼を作成する。
【0209】
そして、通信部220は、送信制御部212の制御に従って、作成されたサブeKeyURLの生成依頼をサーバ30‐1へ送信する(S1805)。
【0210】
なお、図32に示したS1805より後の動作に関しては、図20図22に示した「eKey発行処理B」のS1303以降の動作と比較して、eKeyとサブeKey、およびユーザ端末20‐1の端末IDが相違するが、その他の内容および処理順に関しては同様である。従って、ここでは説明を省略する。
【0211】
[1−6−5.効果]
(1−6−5−1.効果1)
以上説明したように、本応用例によれば、オーナー端末は、eKeyに含まれる権限設定情報においてサブeKeyの発行権限をユーザ端末20‐1bに設定してeKeyをユーザ端末20‐1bに発行することにより、サブeKeyの発行権限をユーザ端末20‐1bに与えることができる。そして、eKeyが発行されたユーザ端末20‐1bは、基本的にはオーナー端末の承認を得ることなく、別のユーザ端末20‐1cに対してサブeKeyを発行することができる。
【0212】
例えば、オーナーユーザは、ゲストユーザ2cに対するサブeKeyの発行を、ユーザ端末20‐1bのユーザ(以下、準オーナーユーザとも称する)に委託することができ、オーナーユーザの作業負荷が軽減される。
【0213】
一例として、マンションの所有者(オーナーユーザ)が、例えば不動産管理会社のユーザ端末20‐1にeKeyを発行することにより、例えばマンションの各部屋の入居者、工事業者、または仲介業者など(ゲストユーザ)に対するサブeKeyの発行を不動産管理会社に委託することができる。このため、マンションの所有者の作業負荷が大きく軽減される。
【0214】
(1−6−5−2.効果2)
また、eKeyに許可された権限設定と、サブeKeyに許可された権限設定との両方を確認し、そして、サブeKeyに許可された権限設定がeKeyに許可された権限設定を超えていないことを検証することにより、不正に権限を追加されていないことを確認することも可能である。
【0215】
<<2.第2の実施形態>>
<2−1.背景>
以上、第1の実施形態について説明した。続いて、第2の実施形態について説明する。
【0216】
最初に、第2の実施形態を創作するに至った背景について説明する。上述した第1の実施形態によるユーザ端末20‐1は、eKeyが発行された場合に、基本的には、eKeyにおいて設定された有効期間内であればeKeyを自由に使用することが可能である。
【0217】
ところで、オーナー端末のユーザが、例えば「付き合っていた異性と別れたため、有効期限満了前だが強制的にeKeyを失効させたい」など、他のユーザ端末20‐1に発行済みのeKeyを有効期限満了前に失効させることを希望することも想定される。
【0218】
後述するように、第2の実施形態によれば、オーナー端末が、失効を希望するeKeyのeKeyIDをサーバ30‐2へ通知することにより、発行済みのeKeyを有効期限満了前に失効させることが可能である。
【0219】
<2−2.システム構成>
第2の実施形態によるシステム構成は、図1または図30に示した第1の実施形態と同様である。
【0220】
<2−3.構成>
続いて、第2の実施形態による構成について詳細に説明する。なお、以下では、第1の実施形態と重複する内容については説明を省略する。
【0221】
[2−3−1.サーバ30‐2]
図33は、第2の実施形態によるサーバ30‐2の構成を示した機能ブロック図である。図33に示したように、サーバ30‐2は、図10に示したサーバ30‐1と比較して、制御部300‐1の代わりに、制御部300‐2を有する。
【0222】
(2−3−1−1.制御部300‐2)
制御部300‐2は、制御部300‐1と比較して、eKey失効リスト登録部314をさらに有する。
【0223】
(2−3−1−2.eKey失効リスト登録部314)
eKey失効リスト登録部314は、失効対象のeKeyIDを含む、eKeyの失効要求がユーザ端末20‐1から受信された場合に、受信された失効要求に含まれるeKeyIDを、後述するeKey失効リストDB326に追加する。
【0224】
‐eKey失効リストDB326
eKey失効リストDB326は、強制失効の対象として登録されたeKeyのeKeyIDが格納されるデータベースである。例えば、eKey失効リストDB326では、失効要求日時、および、失効対象のeKeyIDが対応付けて格納される。なお、このeKey失効リストDB326は、例えばデータベース32に保存されている。
【0225】
[2−3−2.錠前デバイス10‐1、ユーザ端末20‐1]
なお、第2の実施形態による錠前デバイス10‐1、およびユーザ端末20‐1の構成は、第1の実施形態と概略同様である。
【0226】
<2−4.動作>
以上、第2の実施形態による構成について説明した。続いて、第2の実施形態による動作について、「2−4−1.eKeyの失効要求時の動作」〜「2−4−2.錠前デバイス10‐1への処理要求時の動作」において説明する。なお、第1の実施形態で述べた他の種類の動作については、第2の実施形態でも同様である。
【0227】
[2−4−1.eKeyの失効要求時の動作]
まず、第2の実施形態によるeKeyの失効要求時の動作について、図34を参照して説明する。なお、ここでは、オーナー端末であるユーザ端末20‐1が、発行済みのeKeyのうち特定のeKeyの強制失効をサーバ30‐2に依頼する場面の動作例について説明する。
【0228】
図34に示したように、まず、ユーザ端末20‐1の制御部200‐1は、例えば操作表示部222に対してユーザによりeKeyの失効要求が入力された場合に、発行されたeKeyが記憶部226に格納されているか否かを確認する(S2001)。eKeyが記憶部226に記憶されていない場合には(S2001:No)、本動作は終了する。
【0229】
一方、eKeyが記憶部226に記憶されている場合には(S2001:Yes)、制御部200‐1は、記憶されているeKeyに含まれる権限設定情報を確認することにより、eKey失効リストの追加権限がユーザ端末20‐1に設定されているか否かを確認する(S2003)。eKey失効リストの追加権限がユーザ端末20‐1に設定されていない場合には(S2003:No)、本動作は終了する。
【0230】
一方、eKey失効リストの追加権限がユーザ端末20‐1に設定されている場合には(S2003:Yes)、ユーザ端末20‐1のユーザは、操作表示部222に対して失効対象のeKeyのeKeyIDを指定する(S2005)。
【0231】
その後、制御部200‐1は、S2005で指定されたeKeyIDを含む、eKeyの失効要求を生成する。そして、通信部220は、送信制御部212の制御に従って、生成された、eKeyの失効要求をサーバ30‐2へ送信する(S2007)。
【0232】
その後、サーバ30‐2のeKey失効リスト登録部314は、S2007で受信された、eKeyの失効要求に基づいて、eKeyの失効登録要求をデータベース32へ通信部320に送信させる(S2009)。
【0233】
その後、データベース32は、S2009で受信された失効登録要求に含まれるeKeyIDをeKey失効リストDB326に追加する(S2011)。
【0234】
[2−4−2.錠前デバイス10‐1への処理要求時の動作]
次に、第2の実施形態による(図23に示した)「錠前への処理要求」の動作(S14)について説明する。なお、第2の実施形態による「錠前への処理要求」の動作は、図23に示したS1405以外については第1の実施形態と同様であるので、説明を省略する。
【0235】
第2の実施形態によるS1405では、データベース32は、まず、S1403で受信された確認要求に含まれるeKeyIDがeKey失効リストDB326に登録されているかを検索する。そして、検索がヒットした場合には、eKeyが失効していること(つまりeKeyが有効ではないこと)を示す確認結果をサーバ30‐2へ送信する。
【0236】
一方、検索がヒットしなかった場合には、第1の実施形態と同様に、データベース32は、当該eKeyIDに対応するeKeyの有効性に関する情報を抽出し、そして、抽出した情報をサーバ30‐2へ送信する。
【0237】
<2−5.効果>
以上、図33および図34を参照して説明したように、第2の実施形態によるサーバ30‐2は、オーナー端末であるユーザ端末20‐1から受信される、eKeyの失効要求に含まれるeKeyIDをeKey失効リストDB326に追加する。そして、例えばオーナー端末以外のユーザ端末20‐1bによる錠前デバイス10‐1に対する処理要求時などにおいて、ユーザ端末20‐1bに記憶されているeKeyの有効性の問い合わせがユーザ端末20‐1bから受信された場合には、サーバ30‐2は、まず、受信された問い合わせに含まれるeKeyIDがeKey失効リストDB326に登録されているか否かを確認する。そして、eKey失効リストDB326に登録されている場合には、サーバ30‐2は、eKeyが失効していることをユーザ端末20‐1bへ通知する。
【0238】
従って、オーナー端末は、発行済みのeKeyのうち特定のeKeyを有効期限満了前に強制的に失効させることができる。
【0239】
<<3.第3の実施形態>>
以上、第2の実施形態について説明した。上述したように、第2の実施形態では、オーナー端末が、失効対象のeKeyのeKeyIDをサーバ30‐2へ通知することにより、発行済みのeKeyを有効期限満了前に失効させる。
【0240】
続いて、第3の実施形態について説明する。後述するように、第3の実施形態によれば、オーナー端末が、失効を希望するeKeyが発行されたユーザ端末20‐1の端末IDを錠前デバイス10‐3へ登録することにより、発行済みのeKeyを有効期限満了前に失効させることが可能である。
【0241】
<3−1.システム構成>
第3の実施形態によるシステム構成は、図1または図30に示した第1の実施形態と同様である。
【0242】
<3−2.構成>
[3−2−1.錠前デバイス10‐3]
続いて、第3の実施形態による構成について詳細に説明する。図35は、第3の実施形態による錠前デバイス10‐3の構成を示した機能ブロック図である。なお、以下では、第1の実施形態と重複する内容については説明を省略する。
【0243】
(3−2−1−1.判定部108)
第3の実施形態による判定部108は、ユーザ端末20‐1から受信されたeKeyに含まれる端末IDが、後述するブラックリストDB132に登録されている場合には、ユーザ端末20‐1から受信された処理要求を許可しない。
【0244】
また、第3の実施形態による判定部108は、ユーザ端末20‐1から受信された処理要求が、ブラックリストDB132に対する端末IDの追加要求または削除要求であり、かつ、受信された処理要求に関してユーザ端末20‐1の権限が有ることがeKeyの権限設定情報に格納されている場合には、受信された処理要求(つまり、ブラックリストDB132に対する端末IDの追加要求または削除要求)を許可する。
【0245】
‐ブラックリストDB132
ブラックリストDB132は、錠前デバイス10‐3に対する全ての処理要求が拒絶されるユーザ端末20‐1の端末IDを格納するデータベースである。例えば、ブラックリストDB132では、追加日時、および、対象の端末IDが対応付けて格納される。なお、ブラックリストDB132は、本開示におけるアクセス不可端末リストの一例である。
【0246】
‐eKey
ここで、図36を参照して、第3の実施形態によるeKeyに含まれる権限設定情報の構成例(権限設定情報4008‐3)について説明する。図36に示したように、権限設定情報4008‐3には、図31に示した権限設定情報4008‐2と比較して、ブラックリストDB132の登録内容の閲覧、変更、および削除に関するユーザ端末20‐1の権限の有無(ON/OFF)がさらに格納される。
【0247】
(3−2−1−2.処理実行部110)
第3の実施形態による処理実行部110は、ユーザ端末20‐1から受信された処理要求が、ブラックリストDB132に対する端末IDの追加要求または削除要求であり、かつ、当該処理要求を許可することが判定部108により判定された場合には、ユーザ端末20‐1から受信された端末IDをブラックリストDB132に追加、またはブラックリストDB132から削除する。
【0248】
(3−2−1−3.記憶部124)
第3の実施形態による記憶部124は、さらに、ブラックリストDB132を記憶する。
【0249】
なお、錠前デバイス10‐3に含まれるその他の構成要素については、第1の実施形態と概略同様である。また、ユーザ端末20‐1およびサーバ30‐1の構成については、第1の実施形態と概略同様である。
【0250】
<3−3.動作>
以上、第3の実施形態による構成について説明した。続いて、第3の実施形態による動作について説明する。以下では、第3の実施形態による「処理要求判定処理」の動作(S1411)について、図37図38を参照して説明する。この動作は、図24図25に示した動作の代替となる動作である。以下では、ユーザ端末20‐1が、ブラックリストDB132への端末IDの追加を錠前デバイス10‐3へ要求する場面における動作例について説明する。
【0251】
なお、その他の種類の動作については、第1の実施形態と同様であるので、説明を省略する。
【0252】
[3−3−1.処理要求判定処理]
図37に示したS3001〜S3007の動作は、図24に示したS1501〜S1507と同様である。
【0253】
S3007の後、錠前デバイス10‐3の判定部108は、S3007で受信されたeKeyに含まれる端末IDがブラックリストDB132に登録されているか否かを確認する(S3009)。該当の端末IDがブラックリストDB132に登録されている場合には(S3009:Yes)、錠前デバイス10‐3は、後述するS3033の動作を行う。
【0254】
一方、該当の端末IDがブラックリストDB132に登録されていない場合には(S3009:No)、錠前デバイス10‐3は、図24に示したS1509〜S1513と同様の動作を行う(S3011〜S3015)。
【0255】
ここで、図38を参照して、S3015より後の動作について説明する。S3015において、現在が、受信されたeKeyに含まれる有効期間内であると判定された場合には(S3015:Yes)、図38に示したように、次に、判定部108は、S3007で受信されたeKeyに含まれる権限設定情報を確認することにより、ブラックリストDB132に対する端末IDの追加権限がユーザ端末20‐1に設定されているか否かを確認する(S3021)。ブラックリストDB132に対する追加権限がユーザ端末20‐1に設定されていない場合には(S3021:No)、錠前デバイス10‐3は、後述するS3033の動作を行う。
【0256】
一方、ブラックリストDB132に対する追加権限がユーザ端末20‐1に設定されている場合には(S3021:Yes)、錠前デバイス10‐3は、図25に示したS1523〜S1531と同様の動作を行う(S3023〜S3031)。
【0257】
S3031において、S3027で受信されたレスポンスデータが正当ではないと判定された場合には(S3031:No)、判定部108は、S3007で受信された処理要求、すなわちブラックリストDB132に対する端末IDの追加要求を許可しない(S3033)。そして、錠前デバイス10‐3は、後述するS3037の動作を行う。
【0258】
一方、受信されたレスポンスデータが正当であると判定された場合には(S3031:Yes)、判定部108は、S3007で受信された処理要求を許可する。そして、処理実行部110は、S3007で受信された処理要求に含まれる端末IDをブラックリストDB132に追加する(S3035)。
【0259】
なお、図38に示したS3037の動作は、図25に示したS1537と同様である。
【0260】
<3−4.効果>
[3−4−1.効果1]
以上、図35図38を参照して説明したように、第3の実施形態による錠前デバイス10‐3は、ユーザ端末20‐1から受信されたeKeyに含まれる端末IDがブラックリストDB132に登録されている場合には、ユーザ端末20‐1から受信された処理要求を許可しない。
【0261】
従って、オーナー端末は、失効を希望するeKeyが発行されたユーザ端末20‐1の端末IDをブラックリストDB132へ登録することにより、当該端末IDのユーザ端末20‐1のeKeyを有効期限満了前に強制的に失効させることができる。
【0262】
[3−4−2.効果2]
なお、上述した第2の実施形態では、eKey失効リストDB326にeKeyIDが登録された場合であっても、例えば電波状況などにより、当該eKeyIDに対応するeKeyを記憶するユーザ端末20‐1とサーバ30‐2との間で通信が遮断している際には、サーバ30‐2は、ユーザ端末20‐1によるeKeyの使用を停止することができない。つまり、eKeyの失効登録がなされたユーザ端末20‐1であっても、解錠処理などの各種の処理を錠前デバイス10‐1に実行させることが一時的に可能となり得る。
【0263】
一方、第3の実施形態では、錠前デバイス10‐3自体がブラックリストDB132を記憶する。従って、通信状況に依存することなく、ブラックリストDB132に登録された端末IDのユーザ端末20‐1は、錠前デバイス10‐3に対して処理を実行させることができない。つまり、第3の実施形態によれば、eKeyを確実に失効させることが可能となる。
【0264】
<<4.第4の実施形態>>
<4−1.背景>
以上、第3の実施形態について説明した。続いて、第4の実施形態について説明する。最初に、第4の実施形態を創作するに至った背景について説明する。
【0265】
一般的に、解錠権限を有するユーザにとって、負荷が少なくドアを解錠可能であることが望ましい。例えば、ユーザ端末がドアに接近した場合に、ドアを自動的に解錠する方法が考えられる。しかしながら、この方法では、ユーザが家の中にいる場合であってもドアが解錠されてしまう恐れがある。その結果、悪意のある人物により室内に侵入される恐れがある。
【0266】
後述するように、第4の実施形態によれば、ユーザが意図せずに自動解錠されることを防止することが可能である。また、第4の実施形態によるユーザ端末20‐4は、ドアを自動解錠させる目的での位置情報の計測範囲を制限することにより、ユーザ端末20‐4の電力の消費量を抑制することができる。
【0267】
<4−2.システム構成>
第4の実施形態によるシステム構成は、図1または図30に示した第1の実施形態と同様である。
【0268】
<4−3.構成>
続いて、第4の実施形態による構成について詳細に説明する。なお、以下では、第1の実施形態と重複する内容については説明を省略する。
【0269】
[4−3−1.ユーザ端末20‐4]
図39は、第4の実施形態によるユーザ端末20‐4の構成を示した機能ブロック図である。図39に示したように、ユーザ端末20‐4は、図7に示したユーザ端末20‐1と比較して、電波強度測定部228、および位置情報計測部230をさらに有し、かつ、撮像部224を有しない。また、ユーザ端末20‐4は、制御部200‐1の代わりに、制御部200‐4を有する。
【0270】
(4−3−1−1.制御部200‐4)
制御部200‐4は、第1の実施形態による制御部200‐1と比較して、距離算出部214、外出フラグ変更部216、および計測制御部218をさらに有する。また、制御部200‐4は、二次元コード読み取り部202を有しない。
【0271】
(4−3−1−2.距離算出部214)
距離算出部214は、記憶部226に記憶されているロック位置情報と、後述する位置情報計測部230により計測される位置情報との間の距離を算出する。ここで、ロック位置情報は、例えば、錠前デバイス10‐1の例えばBLE圏内にユーザ端末20‐4が位置しており、かつ、操作表示部222に表示される初期設定画面においてユーザにより初期設定の入力がされた場合において、位置情報計測部230により計測された位置情報である。
【0272】
例えば、記憶部226に記憶されている外出フラグの値がOFFに設定されており、かつ、位置情報計測部230により計測された位置情報が錠前デバイス10‐1のBLE圏外(かつ、例えば錠前デバイス10‐1が設置されているドアを有する施設内にWi‐Fiのルーターが設置されている場合には、Wi‐Fi圏外)である場合に、距離算出部214は、記憶されているロック位置情報と、位置情報計測部230により計測される位置情報との間の距離を算出する。ここで、外出フラグは、ユーザ端末20‐4を携帯しているユーザが現在外出中であるか否かを識別するためのフラグである。例えば、外出フラグの値がONに設定されている場合はユーザが外出中であることを示し、また、外出フラグの値がOFFに設定されている場合はユーザが外出中ではないことを示す。なお、「OFF」は、本開示における第1の値の一例であり、また、「ON」は、本開示における第2の値の一例である。但し、かかる例に限定されず、例えば、第1の値は「0」であり、また、第2の値は「1」であるなど、第1の値と第2の値とは互いに異なる任意の数または文字であってもよい。また、外出フラグの値は、後述する外出フラグ変更部216により変更され得る。なお、詳細については後述するが、外出フラグは、位置情報計測部230による計測を制御する際にも用いられる。
【0273】
(4−3−1−3.外出フラグ変更部216)
外出フラグ変更部216は、位置情報計測部230により計測された位置情報に基づいて外出フラグの値を変更する。また、外出フラグ変更部216は、さらに、電波強度測定部228により測定された電波強度の変化、および、記憶部226に記憶されている外出フラグの値に基づいて、外出フラグの値を変更する。
【0274】
例えば、記憶部226に記憶されている外出フラグの値がONに設定されており、かつ、電波強度測定部228により測定された第1の電波強度の測定値が第1の閾値以下の値から第1の閾値よりも大きい値に変化した場合には、外出フラグ変更部216は、外出フラグの値をONからOFFに切り替える。ここで、第1の電波強度は、例えば、錠前デバイス10‐1から受信されるBLEの電波強度である。
【0275】
また、記憶部226に記憶されている外出フラグの値がOFFに設定されており、かつ、電波強度測定部228により測定された第1の電波強度の測定値が第1の閾値以下であり、かつ、電波強度測定部228により測定された第2の電波強度の測定値が第2の閾値以下であった場合には、外出フラグ変更部216は、距離算出部214により算出された距離の大きさに基づいて外出フラグの値をOFFからONに切り替える。例えば、外出フラグの値がOFFに設定されており、かつ、距離算出部214により算出された距離が所定の距離よりも大きい場合には、外出フラグ変更部216は、外出フラグの値をOFFからONに切り替える。なお、第2の電波強度は、例えば、該当の施設内に設置されているWi‐Fiのルーターから受信される電波強度である。また、第2の閾値と第1の閾値とは互いに異なる値であってもよいし、同じ値であってもよい。
【0276】
‐外出フラグの変更例1
ここで、上記の機能について図40を参照して、より詳細に説明する。まず、ユーザ端末20‐4を携帯するユーザが、例えば家4に帰宅する場合など、図40に示した地点Dから家4へ向かって移動している場合における処理内容について説明する。なお、この場合、(ユーザは外出中であるので)外出フラグの値がONに設定されている。また、図40に示したように、地点Aにおいて、錠前デバイス10‐1から受信されるBLEの電波強度の測定値が第1の閾値以下の値から第1の閾値よりも大きい値に変化する。このため、(ユーザ端末20‐4の)外出フラグ変更部216は、ユーザ端末20‐4が地点Aに到達した際に、外出フラグの値をONからOFFに切り替える。なお、詳細については後述するが、この際、ユーザ端末20‐4は、錠前デバイス10‐1へ解錠要求を送信することにより、ドアが自動解錠される。
【0277】
‐外出フラグの変更例2
また、ユーザ端末20‐4を携帯するユーザが、例えば外出する場合など、家4の中から地点Eへ向かって移動している場合における処理内容について説明する。なお、上述したように、ユーザが家4の中にいる場合には、外出フラグの値はOFFに設定されている。
【0278】
ユーザが地点Aを通過すると、錠前デバイス10‐1から受信されるBLEの電波強度の測定値が第1の閾値よりも大きい値から第1の閾値以下の値に変化する。このため、ユーザ端末20‐4が地点Aよりも家4から離れた場合には、まず、距離算出部214は、記憶部226に記憶されているロック位置情報と、位置情報計測部230により計測された位置情報との間の距離を算出する。なお、ここでは、ロック位置情報は、図40に示した錠前デバイス10‐1の位置と概ね同じ位置の位置情報であるとする。
【0279】
そして、外出フラグ変更部216は、距離算出部214により算出された距離と、所定の距離(図40に示した‘a’)とを比較し、そして、算出された距離が‘a’よりも大きい場合には、外出フラグ変更部216は、外出フラグの値をOFFからONに切り替える。図40に示した例では、ユーザ端末20‐4が地点Bよりも家4から離れた場合には、距離算出部214により算出される距離が‘a’よりも大きくなる。このため、ユーザ端末20‐4が地点Bよりも家4から離れた際に、外出フラグ変更部216は、外出フラグの値をOFFからONに切り替える。
【0280】
(4−3−1−4.計測制御部218)
計測制御部218は、記憶部226に記憶されている外出フラグの値および電波強度測定部228により測定された電波強度の測定値に基づいて、位置情報計測部230による計測を制御する。例えば、外出フラグ変更部216により外出フラグの値がOFFからONに変更された場合には、計測制御部218は、位置情報の計測を位置情報計測部230に停止させる。また、外出フラグの値がOFFに設定されており、かつ、電波強度測定部228により測定された第1の電波強度の測定値が第1の閾値以下であり、かつ、第2の電波強度の測定値が第2の閾値以下であった場合には、計測制御部218は、位置情報の計測を位置情報計測部230に再開させる。この制御例によれば、特定の場合だけしか位置情報計測部230に位置情報を計測させないので、ユーザ端末20‐4の電力の消費量を抑制することができる。
【0281】
ここで、図41を参照して、上記の機能についてより詳細に説明する。図41は、図40に示した例に対応する図であり、計測制御部218が位置情報計測部230に位置情報を計測させる範囲を示した説明図である。なお、図41において円で示した範囲80の内部にユーザ端末20‐4が位置する場合には、錠前デバイス10‐1からユーザ端末20‐4が受信するBLEの電波強度の測定値が第1の閾値よりも大きいものとする。また、図41に示した範囲82の内部は、家4の内部に設置されているWi‐Fiのルーター34からユーザ端末20‐4が受信する電波強度の測定値が第2の閾値よりも大きいものとする。また、図41において円で示した範囲84は、記憶部226に記憶されているロック位置情報から所定の距離(‘a’)以内の範囲であるとする。
【0282】
図41に示した例において、一点鎖線で示した計測領域86内にユーザ端末20‐4が位置する場合にのみ、計測制御部218は、例えば所定の時間間隔で、位置情報計測部230に位置情報を計測させる。
【0283】
(4−3−1−5.送信制御部212)
第4の実施形態による送信制御部212は、記憶部226に記憶されている外出フラグの値、および、電波強度測定部228により測定された電波強度の値に基づいて、錠前デバイス10‐1に対する解錠要求の送信を制御する。例えば、送信制御部212は、外出フラグの値がONに設定されており、かつ、電波強度測定部228により測定された第1の電波強度の測定値が第1の閾値以下の値から第1の閾値よりも大きい値に変化した場合には、解錠要求を錠前デバイス10‐1へ通信部220に送信させる。
【0284】
(4−3−1−6.記憶部226)
第4の実施形態による記憶部226は、外出フラグをさらに記憶する。
【0285】
(4−3−1−7.電波強度測定部228)
電波強度測定部228は、錠前デバイス10‐1から受信される例えばBLEの電波強度を測定する。また、電波強度測定部228は、該当の施設内にWi‐Fiのルーターが設置されている場合には、当該ルーターから受信されるWi‐Fiの電波強度を測定することも可能である。
【0286】
(4−3−1−8.位置情報計測部230)
位置情報計測部230は、ユーザ端末20‐4の現在の位置情報を計測する。ここで、位置情報は、例えば、経度および緯度を含む情報である。
【0287】
例えば、位置情報計測部230は、GPS(Global Positioning System)などの測位衛星から測位信号を受信することにより、現在の位置情報を計測する。なお、位置情報計測部230は、一種類の衛星から測位信号を受信することも可能であるし、または、複数の種類の衛星による測位信号を受信し、そして、受信された信号の組み合わせに基づいて位置情報を計測することも可能である。
【0288】
[4−3−2.錠前デバイス10‐1、サーバ30‐1]
なお、錠前デバイス10‐1およびサーバ30‐1の構成については、第1の実施形態と概略同様である。
【0289】
<4−4.動作>
以上、第4の実施形態による構成について説明した。続いて、第4の実施形態による動作について、「4−4−1.初回設定時の動作」〜「4−4−2.自動解錠利用時の動作」において説明する。なお、その他の種類の動作については、(図12図29に示した)第1の実施形態と同様であるので、説明を省略する。
【0290】
[4−4−1.初回設定時の動作」
図42は、第4の実施形態による「初回設定時の動作」を示したフローチャートである。なお、ここでは、ユーザ端末20‐4のユーザが、錠前デバイス10‐1の近辺において、ロック位置情報を登録する際の動作について説明を行う。また、以下では、ユーザ端末20‐4の電波強度測定部228は、例えば所定の時間間隔で、該当の錠前デバイス10‐1から受信されるBLEの電波強度を測定するものとする。
【0291】
図42に示したように、まず、例えば操作表示部222に対してユーザにより初期設定の入力がされた場合に、制御部200‐4は、電波強度測定部228により直前に測定されたBLEの電波強度が第1の閾値よりも大きいか否かを判定する(S4001)。測定されたBLEの電波強度が第1の閾値以下である場合には(S4001:No)、制御部200‐4は、例えば「ドアの近くへ移動して設定を行ってください」のようなメッセージを操作表示部222に表示させる。そして、当該「初回設定時の動作」は終了する。
【0292】
一方、測定されたBLEの電波強度が第1の閾値よりも大きい場合には(S4001:Yes)、制御部200‐4は、セットアップ画面を操作表示部222に表示させる(S4003)。
【0293】
続いて、該当の錠前デバイス10‐1が設置されているドアを有する家の中にWi‐Fiのルーターが設置されている場合には(S4005:Yes)、ユーザは、S4003で表示されたセットアップ画面において、該当のWi‐FiのルーターのMACアドレスを入力する(S4007)。
【0294】
家の中にWi‐Fiのルーターが設置されていない場合(S4005:No)、または、S4007の後には、計測制御部218は、位置情報計測部230に現在の位置情報を計測させる(S4009)。
【0295】
その後、制御部200‐4は、S4009で計測された位置情報をロック位置情報として記憶部226に格納する(S4011)。
【0296】
なお、その後、外出フラグ変更部216は、外出フラグの値をONに設定して、外出フラグを記憶部226に格納することも可能である。また、ユーザは、セットアップ画面において「自動解錠モード」の利用開始を入力してもよい。
【0297】
[4−4−2.自動解錠利用時の動作]
次に、図43図44を参照して、第4の実施形態による「自動解錠利用時の動作」について詳細に説明する。なお、この動作は、ロック位置情報が登録され、かつ、セットアップ画面において「自動解錠モード」の利用開始が設定された後における動作例である。また、以下では、ユーザ端末20‐4の電波強度測定部228が、例えば所定の時間間隔で、該当の錠前デバイス10‐1から受信されるBLEの電波強度を測定するものとする。
【0298】
図43に示したように、まず、ユーザ端末20‐4の外出フラグ変更部216は、記憶部226に記憶されている外出フラグの値がONに設定されているか否かを判定する(S4101)。外出フラグの値がOFFに設定されている場合には(S4101:No)、ユーザ端末20‐4は、後述するS4111の動作を行う。
【0299】
一方、外出フラグの値がONに設定されている場合には(S4101:Yes)、次に、制御部200‐4は、電波強度測定部228により直前に測定されたBLEの電波強度が第1の閾値よりも大きいか否かを判定する(S4103)。測定されたBLEの電波強度が第1の閾値以下である場合には(S4103:No)、ユーザ端末20‐4は、例えば所定の時間待機し、そして、再びS4103の動作を行う。
【0300】
一方、測定されたBLEの電波強度が第1の閾値よりも大きい場合には(S4103:Yes)、通信部220は、送信制御部212の制御に従って、解錠要求を錠前デバイス10‐1へ送信する(S4105)。そして、外出フラグ変更部216は、外出フラグの値をONからOFFに変更し、そして、記憶部226に格納し直す(S4107)。これにより、ユーザ端末20‐4は、現在外出中ではないと識別することが可能となる。
【0301】
ここで、図44を参照して、S4107より後の動作について説明する。図44に示したように、まず、制御部200‐4は、電波強度測定部228により直前に測定されたBLEの電波強度が第1の閾値よりも大きいか否かを判定する(S4111)。測定されたBLEの電波強度が第1の閾値よりも大きい場合には(S4111:Yes)、ユーザ端末20‐4は、後述するS4121の動作を行う。
【0302】
一方、測定されたBLEの電波強度が第1の閾値以下である場合には(S4111:No)、次に、制御部200‐4は、電波強度測定部228により直前に測定された、該当の施設内に設置されているWi‐Fiのルーターから受信される電波強度が第2の閾値よりも大きいか否かを判定する(S4113)。測定されたWi‐Fiの電波強度が第2の閾値よりも大きい場合には(S4113:Yes)、ユーザ端末20‐4は、後述するS4121の動作を行う。
【0303】
一方、測定されたWi‐Fiの電波強度が第2の閾値以下である場合には(S4113:No)、計測制御部218は、位置情報計測部230に位置情報の計測を開始させる(S4115)。これにより、位置情報計測部230は、例えば所定の時間間隔で現在の位置情報を計測する。
【0304】
続いて、距離算出部214は、位置情報計測部230により直前に計測された位置情報と、記憶部226に記憶されているロック位置情報との間の距離を算出する(S4117)。
【0305】
続いて、外出フラグ変更部216は、S4117で算出された距離が所定の距離よりも大きいか否かを判定する(S4119)。算出された距離が所定の距離以下である場合には(S4119:No)、ユーザ端末20‐4は、一定時間待機する(S4121)。そして、ユーザ端末20‐4は、再びS4111の動作を行う。
【0306】
一方、算出された距離が所定の距離よりも大きい場合には(S4119:Yes)、外出フラグ変更部216は、外出フラグの値をOFFからONに変更し、そして、記憶部226に格納し直す(S4123)。これにより、ユーザ端末20‐4は、現在外出中であると識別することが可能となる。
【0307】
その後、ユーザ端末20‐4は、再びS4103の動作を行う。
【0308】
<4−5.効果>
[4−5−1.効果1]
以上、例えば図39図44を参照して説明したように、第4の実施形態によるユーザ端末20‐4は、記憶されている外出フラグの値がONに設定されており、かつ、測定された第1の電波強度の測定値が第1の閾値以下の値から第1の閾値よりも大きい値に変化した場合にのみ、解錠要求を錠前デバイス10‐1へ送信する。例えば、ユーザ端末20‐4を携帯するユーザが外出先から自宅に戻ってきた場合にのみ、ユーザ端末20‐4は、錠前デバイス10‐1に対して解錠要求を送信する。このため、ユーザが意図せずに自動解錠されることを防止することができる。
【0309】
また、一旦ドアが自動解錠された場合には、ユーザ端末20‐4は、外出フラグの値をONからOFFに変更し、そして、ユーザ端末20‐4がロック位置から所定の距離以内に位置する限り外出フラグの値をOFFのまま維持する。このため、ユーザ端末20‐4が、家の中に位置するにも関わらずドアが自動的に解錠されてしまうことを防止することができる。
【0310】
[4−5−2.効果2]
また、ユーザ端末20‐4は、錠前デバイス10‐1(およびWi‐Fiルーター)から受信される電波強度の測定結果、および、位置情報の計測結果に基づいて、ユーザ端末20‐4のユーザが外出中であるか否かを高い精度で判定することができ、そして、判定結果を外出フラグの値として記録することができる。
【0311】
[4−5−3.効果3]
また、第4の実施形態によれば、自動解錠を行うために、錠前デバイス10‐1は、ユーザ端末20‐4の接近を検出するためのセンサーなどを有する必要がない。
【0312】
[4−5−4.効果4]
また、第4の実施形態では、ユーザ端末20‐4にインストールされているアプリケーションを用いた、ユーザの明示的な施錠指示または解錠指示を錠前デバイス10‐1へ送信したり、または、例えば錠前デバイス10‐1に実装されるオートロックシステムを、上述した自動解錠の処理と併用することも可能である。その結果、ユーザの利便性がより高い、ドアの解錠および施錠を実現することができる。
【0313】
[4−5−5.効果5]
また、ユーザ端末20‐4は、記憶されている外出フラグの値、および、錠前デバイス10‐1またはWi‐Fiのルーターから受信される電波強度の測定値に基づいて、位置情報を計測するか否かを制御する。例えば、外出フラグの値がOFFに設定されており、かつ、BLEの電波強度の測定値が閾値以下であり、かつ、Wi‐Fiの電波強度の測定値が閾値以下である場合には、ユーザ端末20‐4は、例えば所定の時間間隔で位置情報を計測し、また、上記以外の場合には、位置情報を計測しない。
【0314】
従って、ユーザ端末20‐4は、特定の場合だけしか位置情報を計測しないので、ユーザ端末20‐4の電力の消費量を抑制することができる。例えば、外出フラグの値がONに設定されている場合(つまり、ユーザが外出している場合)や、ユーザが自宅にWi‐Fiのルーターを設置しており、かつ、ユーザが自宅内にいる場合には、位置情報の計測が不要である。また、自宅にWi‐Fiのルーターが設置されていない場合であっても、錠前デバイス10‐1のBLE圏内にユーザ端末20‐4が位置する場合には、位置情報の計測が不要である。ユーザ端末20‐4は、これらの場合に位置情報を計測しないので、電力の消費量を抑制することができる。
【0315】
<<5.変形例>>
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【0316】
例えば、上述した各実施形態では、錠前デバイス10‐1または錠前デバイス10‐3が家の玄関や部屋のドアに設置される例を中心として説明したが、かかる例に限定されない。錠前デバイス10‐1または錠前デバイス10‐3は、例えば、空港や駅などに設置されるロッカーのドア、自動車のドアなどの各種のドアに設置され得る。また、自転車などの施錠機構に適用されてもよい。
【0317】
また、上述した各実施形態の動作における各ステップは、必ずしも記載された順序に沿って処理されなくてもよい。例えば、各ステップは、適宜順序が変更されて処理されてもよい。また、各ステップは、時系列的に処理される代わりに、一部並列的に又は個別的に処理されてもよい。
【0318】
また、上述した各実施形態によれば、CPUなどのプロセッサ、およびRAMなどのハードウェアを、上述した錠前デバイス10‐1または錠前デバイス10‐3の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。
【0319】
なお、以下のような構成も本開示の技術的範囲に属する。
(1)
錠前デバイスであって、
前記錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、
前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部と、
を備える、錠前デバイス。
(2)
前記錠前デバイスは、施錠部をさらに備え、
前記設定情報は、前記施錠部の解錠または施錠に関して設定された権限を示す情報を含み、
前記処理要求は、前記施錠部の解錠要求または施錠要求を含む、前記(1)に記載の錠前デバイス。
(3)
前記設定情報は、前記錠前デバイスが記憶している操作ログの閲覧に関して設定された権限を示す情報をさらに含み、
前記処理要求は、前記操作ログの閲覧要求をさらに含む、前記(2)に記載の錠前デバイス。
(4)
前記設定情報は、前記錠前デバイスが記憶している時刻情報の変更、または、前記錠前デバイスに含まれる複数の機器の設定情報の変更に関して設定された権限を示す情報をさらに含み、
前記処理要求は、前記時刻情報の変更要求、または、前記複数の機器のうちいずれか一以上の機器の設定情報の変更要求をさらに含む、前記(2)または(3)に記載の錠前デバイス。
(5)
前記錠前デバイスは、前記錠前デバイスに対するアクセス権限を有しない通信端末の識別情報を格納するアクセス不可端末リストを記憶する記憶部をさらに備え、
前記鍵情報は、前記第1の通信端末の識別情報をさらに含み、
前記判定部は、前記第1の通信端末の識別情報が前記アクセス不可端末リストに格納されている場合には、前記処理要求を許可しないことを判定する、前記(2)〜(4)のいずれか一項に記載の錠前デバイス。
(6)
前記設定情報は、前記アクセス不可端末リストに対する他の通信端末の識別情報の追加または削除に関して設定された権限を示す情報をさらに含み、
前記処理要求は、前記アクセス不可端末リストに対する他の通信端末の識別情報の追加要求または削除要求をさらに含む、前記(5)に記載の錠前デバイス。
(7)
前記通信部は、さらに、第1の共通鍵と、第2の通信端末に対応付けられた第2の公開鍵とを前記第2の通信端末から受信し、
前記錠前デバイスは、前記錠前デバイスに対応付けられた第2の共通鍵を記憶する記憶部と、
前記第1の共通鍵と前記第2の共通鍵との比較結果が一致する場合に、前記第2の通信端末を前記錠前デバイスのオーナー端末として登録し、かつ、前記第2の公開鍵を前記記憶部に格納するオーナー端末登録部と、をさらに備える、前記(2)〜(6)のいずれか一項に記載の錠前デバイス。
(8)
前記鍵情報は、前記錠前デバイスのオーナー端末として登録された前記第2の通信端末により、前記第1の通信端末と対応付けて発行された情報である、前記(7)に記載の錠前デバイス。
(9)
前記鍵情報は、前記第2の通信端末による前記第1の公開鍵に対する署名情報をさらに含む、前記(8)に記載の錠前デバイス。
(10)
前記錠前デバイスは、前記第1の公開鍵に対する署名情報に基づいて前記第1の公開鍵の正当性を検証する鍵検証部をさらに備え、
前記判定部は、さらに、前記鍵検証部により前記第1の公開鍵が正当であることが検証された場合に、前記処理要求を許可することを判定する、前記(9)に記載の錠前デバイス。
(11)
前記通信部は、さらに、前記第1の公開鍵に対応する第1の秘密鍵により生成された第1の情報を前記第1の通信端末から受信し、
前記錠前デバイスは、前記第1の情報を前記第1の公開鍵に基づいて検証する検証処理部をさらに備え、
前記判定部は、さらに、前記検証処理部により前記第1の情報が正当であることが検証された場合に、前記処理要求を許可することを判定する、前記(10)に記載の錠前デバイス。
(12)
前記通信部は、前記錠前デバイスの複数の種類の機能に関する第3の通信端末の権限の設定情報、および前記第3の通信端末に対応付けられた第3の公開鍵を含むサブ鍵情報と、前記錠前デバイスに対する第2の処理要求とを前記第3の通信端末からさらに受信し、
前記判定部は、さらに、前記サブ鍵情報に基づいて前記第2の処理要求を許可するか否かを判定し、
前記サブ鍵情報は、前記第1の通信端末により前記第3の通信端末と対応付けて発行された情報であり、
前記複数の種類の機能に関して前記第3の通信端末に設定された権限は、前記第1の通信端末に設定された権限以下である、前記(2)〜(11)のいずれか一項に記載の錠前デバイス。
(13)
錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信することと、
前記鍵情報に基づいて、前記処理要求を許可するか否かを判定することと、
を備える、情報処理方法。
(14)
コンピュータを、
錠前デバイスの複数の種類の機能に関する第1の通信端末の権限の設定情報、および前記第1の通信端末に対応付けられた第1の公開鍵を含む鍵情報と、前記錠前デバイスに対する処理要求とを前記第1の通信端末から受信する通信部と、
前記鍵情報に基づいて、前記処理要求を許可するか否かを判定する判定部、
として機能させるための、プログラム。
(15)
錠前デバイスから受信する第1の電波強度を測定する電波強度測定部と、
前記電波強度測定部により測定された前記第1の電波強度の値に基づいて、前記錠前デバイスに対する解錠要求の送信を制御する送信制御部と、
を備える、通信端末。
(16)
前記通信端末は、外出フラグを記憶する記憶部と、
前記通信端末の位置情報を計測する位置情報計測部と、
前記位置情報計測部により計測された位置情報に基づいて前記外出フラグの値を変更する外出フラグ変更部と、をさらに備える、前記(15)に記載の通信端末。
(17)
前記送信制御部は、前記第1の電波強度の測定値および前記外出フラグの値に基づいて、前記錠前デバイスに対する前記解錠要求の送信を制御する、前記(16)に記載の通信端末。
(18)
前記通信端末は、前記外出フラグの値が第1の値から第2の値に変更された場合に、前記位置情報の計測を前記位置情報計測部に停止させる計測制御部をさらに備える、前記(17)に記載の通信端末。
(19)
前記外出フラグ変更部は、前記錠前デバイスに対して前記解錠要求が送信された際に、前記外出フラグの値を前記第2の値から前記第1の値に変更し、
前記外出フラグの値が前記第1の値であり、かつ、前記電波強度測定部により測定された前記第1の電波強度の測定値が第1の閾値以下であり、かつ、第2の電波強度の測定値が第2の閾値以下であった場合に、前記計測制御部は、前記位置情報の計測を前記位置情報計測部に再開させる、前記(18)に記載の通信端末。
【符号の説明】
【0320】
10‐1、10‐3 錠前デバイス
20‐1、20‐4 ユーザ端末
22 通信網
30‐1、30‐2 サーバ
32 データベース
34 Wi‐Fiルーター
100‐1、100‐3、200‐1、200‐4、300‐1、300‐2 制御部
102、302 情報登録部
104 鍵情報検証部
106、310 認証情報検証部
108 判定部
110 処理実行部
112、308 チャレンジ生成部
114、212、306 送信制御部
120、220、320 通信部
122 施錠部
124、226、322 記憶部
126 錠前鍵ファイル
128 オーナー情報ファイル
130 操作ログDB
132 ブラックリストDB
202 二次元コード読み取り部
204 電子署名部
206 鍵情報発行部
208 認証処理部
210 操作認識部
214 距離算出部
216 外出フラグ変更部
218 計測制御部
222 操作表示部
224 撮像部
228 電波強度測定部
230 位置情報計測部
304 鍵情報発行要求部
312 認証部
314 失効リスト登録部
324 オーナー情報DB
326 失効リストDB
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図44