JPWO2016092911A1 - 情報処理装置、情報処理方法、プログラム、および情報処理システム - Google Patents

Abstract

【課題】開錠時における認証の安全性を向上させることが可能な、情報処理装置、情報処理方法、プログラム、および情報処理システムを提案する。【解決手段】第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、を備える、情報処理装置。【選択図】図１

Description

本開示は、情報処理装置、情報処理方法、プログラム、および情報処理システムに関する。

従来、ドアの施開錠を電気的に行うことが可能な錠前装置が開発されている。例えば、特許文献１には、携帯機器が電気錠にかざされると、電気錠は携帯機器からキーデータを読み取り、そして、読み取ったキーデータと認証用キーデータとを照合することにより開錠制御を行う技術が開示されている。

特開２００７−２３９３４７号公報

しかしながら、特許文献１に記載の技術は、認証の安全性が低い。例えば、上記の技術では、携帯機器のキーデータがそのまま電気錠に送信される。このため、送信時に、例えば別の装置によりキーデータが盗聴されることにより、キーデータが漏えいする恐れがある。

そこで、本開示では、開錠時における認証の安全性を向上させることが可能な、新規かつ改良された情報処理装置、情報処理方法、プログラム、および情報処理システムを提案する。

本開示によれば、第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、を備える、情報処理装置が提供される。

また、本開示によれば、第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信することと、前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定することと、を備える、情報処理方法が提供される。

また、本開示によれば、コンピュータを、第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部、として機能させるための、プログラムが提供される。

また、本開示によれば、第１の通信端末、および情報処理装置を有し、前記情報処理装置は、第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを前記第１の通信端末から受信する通信部と、前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、を備える、情報処理システムが提供される。

以上説明したように本開示によれば、開錠時における認証の安全性を向上させることができる。なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本開示の第１の実施形態による情報処理システムの構成例を示した説明図である。 同実施形態による錠前デバイス１０‐１の構成例を示した機能ブロック図である。 同実施形態によるｅＫｅｙの構成例を示した説明図である。 同実施形態によるユーザ端末２０の構成例を示した機能ブロック図である。 同実施形態によるサーバ３０の構成例を示した機能ブロック図である。 同実施形態による錠前デバイス１０‐１への鍵の登録時の動作を示したシーケンス図である。 同実施形態によるオーナー２ａの鍵の検証時の動作を示したシーケンス図である。 同実施形態によるサーバ３０へのアカウントの登録時の動作を示したシーケンス図である。 同実施形態によるサーバ３０へのユーザ端末２０の登録時の動作を示したシーケンス図である。 同実施形態によるサーバ３０によるアカウントの認証時の動作を示したシーケンス図である。 同実施形態によるゲスト２ｂの招待時の動作を示したシーケンス図である。 同実施形態によるｅＫｅｙの発行依頼時の動作を示したシーケンス図である。 同実施形態によるｅＫｅｙの発行時の動作を示したシーケンス図である。 同実施形態による開錠時の動作の一部を示したシーケンス図である。 同実施形態による開錠処理の動作の一部を示したシーケンス図である。 同実施形態による開錠処理の動作の一部を示したシーケンス図である。 同実施形態によるｅＫｅｙＧｒｏｕｐの失効要求時の動作を示したシーケンス図である。 同実施形態の応用例による情報処理システムの構成例を示した説明図である。 同応用例によるｅＫｅｙの構成例を示した説明図である。 同応用例による動作の一部を示したシーケンス図である。 本開示の第２の実施形態による錠前デバイス１０‐２の構成例を示した機能ブロック図である。 同実施形態によるｅＫｅｙの構成例を示した説明図である。 同実施形態による錠前デバイス１０‐２への鍵の登録時の動作の一部を示したシーケンス図である。 同実施形態による錠前デバイス１０‐２への鍵の登録時の動作の一部を示したシーケンス図である。 同実施形態によるＭＱレスポンスデータ検証処理の動作を示したフローチャートである。 同実施形態によるオーナー２ａの鍵の検証時の動作を示したシーケンス図である。 同実施形態によるアルゴリズムの移行要求時の動作を示したシーケンス図である。 同実施形態によるサーバ３０によるアカウントの認証時の動作を示したシーケンス図である。 同実施形態による開錠処理の動作の一部を示したシーケンス図である。 同実施形態による開錠処理の動作の一部を示したシーケンス図である。 本開示の第３の実施形態による錠前デバイス１０‐３の構成例を示した機能ブロック図である。 同実施形態によるｅＫｅｙの構成例を示した説明図である。 同実施形態による開錠処理の動作の一部を示したシーケンス図である。 本開示の第４の実施形態による情報処理システムの構成例を示した機能ブロック図である。 同実施形態による錠前デバイス１０‐４の構成例を示した機能ブロック図である。 同実施形態による錠前デバイス１０‐４に接近した個々のユーザ端末２０に関する処理の流れを示した説明図である。 同実施形態による動作の一部を示したフローチャートである。 同実施形態による動作の一部を示したフローチャートである。 同実施形態による開錠要求判定処理の動作を示したフローチャートである。 本開示の第５の実施形態による錠前デバイス１０‐５の構成例を示した機能ブロック図である。 同実施形態による動作を示したフローチャートである。 本開示の第６の実施形態による錠前デバイス１０‐６の構成例を示した機能ブロック図である。 同実施形態による動作を示したシーケンス図である。 本開示の第７の実施形態による錠前デバイス１０‐７の構成例を示した機能ブロック図である。 同実施形態による動作を示したシーケンス図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の構成を、必要に応じてユーザ端末２０ａおよびユーザ端末２０ｂのように区別する。ただし、実質的に同一の機能構成を有する複数の構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、ユーザ端末２０ａおよびユーザ端末２０ｂを特に区別する必要が無い場合には、単にユーザ端末２０と称する。

また、以下に示す項目順序に従って当該「発明を実施するための形態」を説明する。
１．第１の実施形態
２．第２の実施形態
３．第３の実施形態
４．第４の実施形態
５．第５の実施形態
６．第６の実施形態
７．第７の実施形態
８．変形例

本開示は、一例として「１．第１の実施形態」〜「７．第７の実施形態」において詳細に説明するように、多様な形態で実施され得る。まず、第１の実施形態について説明する。

＜＜１．第１の実施形態＞＞
＜１−１．システム構成＞
図１は、第１の実施形態による情報処理システムの構成を示した説明図である。図１に示したように、第１の実施形態による情報処理システムは、錠前デバイス１０‐１、ユーザ端末２０、通信網２２、サーバ３０、およびデータベース３２を含む。

［１−１−１．錠前デバイス１０‐１］
錠前デバイス１０‐１は、本開示における情報処理装置の一例である。錠前デバイス１０‐１は、例えば家の玄関のドアなどに取り付けられ、施錠および開錠の制御を行うための装置である。より具体的には、錠前デバイス１０‐１は、錠前のサムターンに相当する施錠部１３２の施錠および開錠の制御を行う。

また、この錠前デバイス１０‐１は、後述するユーザ端末２０から受信される開錠要求に基づいて開錠の制御を行う。

［１−１−２．ユーザ端末２０］
ユーザ端末２０は、本開示における通信端末の一例である。ユーザ端末２０は、ユーザ２が所有する端末であり、基本的には携帯型の端末である。例えば、ユーザ端末２０は、スマートフォンなどの携帯電話、タブレット端末、腕時計型デバイスなどであってもよい。

ユーザ端末２０は、錠前デバイス１０‐１に対してドアの開錠要求を行うためのアプリケーションを実装することが可能である。また、ユーザ端末２０は、例えば無線通信により、後述する通信網２２を介してサーバ３０と通信することが可能である。

［１−１−３．通信網２２］
通信網２２は、通信網２２に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、通信網２２は、電話回線網、インターネット、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などを含んでもよい。また、通信網２２は、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）などの専用回線網を含んでもよい。

［１−１−４．サーバ３０］
サーバ３０は、本開示における管理装置の一例である。サーバ３０は、例えばｗｅｂシステムで構成される鍵認証サービスを管理するための装置である。例えば、サーバ３０は、ユーザ端末２０からの要求に基づいてユーザ２のアカウントを新規登録したり、ユーザ端末２０による鍵認証サービスへのログイン時の認証などを行う。

［１−１−５．データベース３２］
データベース３２は、サーバ３０からの指示に従って、鍵認証サービスにおいて利用される様々な情報を記憶するための装置である。例えば、データベース３２は、個々の錠前デバイス１０‐１に対応づけて、開錠権を有するユーザ２およびユーザ端末２０の登録情報を記憶する。

なお、第１の実施形態による情報処理システムは、上述した構成に限定されない。例えば、データベース３２は、独立した装置として構成される代わりに、サーバ３０内に記憶されてもよい。

［１−１−６．課題の整理］
（１−１−６−１．課題１）
以上、第１の実施形態による情報処理システムの構成について説明した。ところで、ユーザ端末２０が錠前デバイス１０‐１に対して開錠を要求する際には、錠前デバイス１０‐１は、ユーザ端末２０が開錠する権限を有する正当な端末であることを認証可能であることが必要となる。

第１の方法として、ユーザのＩＤまたはパスワードを錠前デバイス１０‐１に登録しておき、そして、錠前デバイス１０‐１が、ユーザ端末２０から開錠要求時に受信されるＩＤまたはパスワードを照合することにより、ユーザ端末２０を認証する方法が考えられる。

しかしながら、この第１の方法では、ＩＤまたはパスワードの送信時に、例えば別の装置により盗聴されることにより、ＩＤまたはパスワードが漏えいするリスクがある。そして、ＩＤまたはパスワードが漏えいすると、別の装置によりドアが開錠可能になってしまう。

また、第２の方法として、錠前デバイス１０‐１およびユーザ端末２０に共通鍵を登録しておき、そして、錠前デバイス１０‐１が、ユーザ端末２０により受信される、共通鍵で暗号化された情報を復号した結果を検証することにより、ユーザ端末２０を認証する方法が考えられる。この方法では、錠前デバイス１０‐１とユーザ端末２０との間で送受信される情報が仮に盗聴されたとしても、別の装置によりドアが開錠されるリスクを軽減できる。しかしながら、この方法では、同一の共通鍵を複数の装置に登録しないと認証できないので、鍵を管理する装置が多くなる。その結果、鍵が盗まれるリスクが残る。

（１−１−６−１．課題２）
また、別の課題として以下が挙げられる。錠前デバイス１０‐１の鍵を管理する管理者のユーザ２（以下、オーナー２ａと称する場合がある）が、開錠可能な鍵情報を別のユーザ２（以下、ゲスト２ｂと称する場合がある）に発行可能であることが望ましい。

公知の技術では、第１の方法として、ゲスト２ｂが自分の鍵をサーバーに登録し、そして、サーバーに登録されたゲスト２ｂの鍵に対してオーナー２ａが開錠権限を設定する方法が提案されている。しかしながら、この方法では、例えばゲスト２ｂが必要なアプリケーションをインストールしていないなど、自分の鍵をまだサーバーに登録していない場合には、オーナー２ａは、ゲスト２ｂに対して開錠権を設定することができない。また、この方法では、ゲスト２ｂが鍵情報を受け取ることを希望していても、例えばどのアプリケーションをインストールして、どのように端末の設定をすればよいかを知ることが難しい場合がある。

また、第２の方法として、オーナー２ａがゲスト２ｂに発行する鍵ＩＤをＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に埋め込み、そして、当該ＵＲＬとアプリケーションのインストール手順とを含むｅ−ｍａｉｌをゲスト２ｂ宛てに送信する方法が考えらえる。しかしながら、この方法では、メール本文に記載された鍵ＩＤが第三者により盗聴されると、第三者がドアを開錠可能になってしまう。

そこで、上記事情を一着眼点にして、第１の実施形態による錠前デバイス１０‐１を創作するに至った。第１の実施形態による錠前デバイス１０‐１は、ユーザ端末２０の秘密の情報が漏えいすることなく、ユーザ端末２０を認証することが可能である。また、第１の実施形態によれば、ゲスト２ｂに対してオーナー２ａが錠前デバイス１０‐１の鍵情報を受け渡す際に、鍵情報の漏えいを防止することが可能である。以下、このような第１の実施形態について順次詳細に説明する。

＜１−２．構成＞
［１−２−１．錠前デバイス１０‐１］
次に、第１の実施形態による構成について詳細に説明する。図２は、第１の実施形態による錠前デバイス１０‐１の構成を示した機能ブロック図である。図２に示したように、錠前デバイス１０‐１は、制御部１００‐１、通信部１３０、施錠部１３２、および記憶部１３４を有する。

（１−２−１−１．制御部１００‐１）
制御部１００‐１は、錠前デバイス１０‐１に内蔵される、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などのハードウェアを用いて、錠前デバイス１０‐１の動作を全般的に制御する。また、図２に示したように、制御部１００‐１は、鍵情報検証部１０２、検証処理部１０４、判定部１０６、施錠制御部１０８、乱数生成部１１０、および送信制御部１１２を有する。

（１−２−１−２．鍵情報検証部１０２）
鍵情報検証部１０２は、本開示における鍵検証部の一例である。鍵情報検証部１０２は、ユーザ端末２０から受信されるｅＫｅｙの正当性を判定する。ここで、ｅＫｅｙは、本開示における鍵情報の一例である。

例えば、鍵情報検証部１０２は、受信されたｅＫｅｙに含まれる、ユーザ端末２０の公開鍵に対する署名情報に基づいてユーザ端末２０の公開鍵の正当性を検証する。より具体的には、鍵情報検証部１０２は、受信されたｅＫｅｙに含まれる、ユーザ端末２０の公開鍵に対する署名情報が検証処理部１０４により復号された結果と、ユーザ端末２０の公開鍵とに基づいて、ユーザ端末２０の公開鍵が正当であるか否かを検証する。

また、鍵情報検証部１０２は、受信されたｅＫｅｙの有効期間を参照して、有効期間内であるか否かを判定する。

‐ｅＫｅｙ
ここで、第１の実施形態によるｅＫｅｙの構成例（ｅＫｅｙ４０‐１）について、図３を参照して説明する。図３に示したように、ｅＫｅｙ４０‐１は、例えばヘッダー４００、および本体４０２を有する。また、ヘッダー４００は、ｅＫｅｙＩＤ４０００、ｄｅｖｉｃｅＩＤ４００２、錠前ＩＤ４００４、および、有効期間４００６を有する。また、本体４０２は、ＲＳＡ公開鍵４０２０、および鍵のＲＳＡ証明書４０２２を有する。

ここで、ｅＫｅｙＩＤ４０００には、ｅＫｅｙ４０‐１に対応するｅＫｅｙＩＤが記録される。なお、ｅＫｅｙＩＤは、例えばｅＫｅｙ４０‐１を発行したオーナー２ａのユーザ端末２０ａにより決定されるＩＤである。また、ｄｅｖｉｃｅＩＤ４００２には、該当のｅＫｅｙ４０‐１を有するユーザ端末２０の端末ＩＤが記録される。また、錠前ＩＤ４００４には、（該当のｅＫｅｙ４０‐１に対応づけて）開錠を許可された錠前デバイス１０‐１のＩＤが記録される。また、有効期間４００６には、該当のｅＫｅｙ４０‐１に対して設定された有効期間が記録される。例えば、有効期間４００６には、使用可能な日にち、曜日、または、時間帯などが記録される。なお、図３では、有効期間４００６として、期間の制限のないことを示す値である「ＡＬＷＡＹＳ」が記録された例を示している。また、ＲＳＡ公開鍵４０２０には、該当のｅＫｅｙ４０‐１が発行されたユーザ端末２０のＲＳＡ公開鍵が記録される。また、鍵のＲＳＡ証明書４０２２には、該当のｅＫｅｙ４０‐１が発行されたユーザ端末２０のＲＳＡ公開鍵に対する、オーナー２ａのユーザ端末２０ａによる署名情報が記録される。より具体的には、鍵のＲＳＡ証明書４０２２には、ｅＫｅｙ４０‐１が発行されたユーザ端末２０のＲＳＡ公開鍵に対する、ユーザ端末２０ａのＲＳＡ秘密鍵を用いた署名情報が記録される。

なお、オーナー２ａのユーザ端末２０ａが、自端末に対してｅＫｅｙ４０‐１を発行することも可能である。この場合、鍵のＲＳＡ証明書４０２２には、ユーザ端末２０ａのＲＳＡ公開鍵に対するユーザ端末２０ａ自身の署名情報が記録される。

（１−２−１−３．検証処理部１０４）
検証処理部１０４は、ユーザ端末２０から受信される、ユーザ端末２０の秘密鍵に基づいて生成された情報を所定のアルゴリズムにより検証する。例えば、検証処理部１０４は、ユーザ端末２０の秘密鍵に基づいて生成された情報が受信された場合に、受信された情報をユーザ端末２０の公開鍵に基づいて検証する。また、検証処理部１０４は、ユーザ端末２０から受信されたｅＫｅｙに含まれる、ユーザ端末２０ｂの公開鍵に対するオーナー２ａのユーザ端末２０ａによる署名情報を、ユーザ端末２０ａの公開鍵に基づいて復号化する。

（１−２−１−４．判定部１０６）
判定部１０６は、ユーザ端末２０の秘密鍵に基づいて生成された情報の検証の結果、およびユーザ端末２０の公開鍵の検証の結果に基づいて、後述する施錠部１３２に開錠させるか否かを判定する。例えば、判定部１０６は、ユーザ端末２０の公開鍵が正当であることが鍵情報検証部１０２により検証され、かつ、ユーザ端末２０の秘密鍵に基づいて生成された情報が正当であることが検証処理部１０４により検証された場合には、施錠部１３２に開錠させることを判定する。より具体的には、判定部１０６は、まず、ユーザ端末２０の公開鍵が正当であることが鍵情報検証部１０２により検証されたか否かを確認する。そして、ユーザ端末２０の公開鍵が正当であると検証された場合で、かつ、ユーザ端末２０により生成された情報が正当であることが検証処理部１０４により検証された場合には、判定部１０６は、施錠部１３２に開錠させることを判定する。

また、判定部１０６は、ユーザ端末２０の公開鍵が正当ではないと検証された場合、または、ユーザ端末２０の秘密鍵に基づいて生成された情報が正当ではないと検証された場合には、施錠部１３２に開錠させないことを判定する。

（１−２−１−５．施錠制御部１０８）
施錠制御部１０８は、判定部１０６による判定結果に基づいて施錠部１３２の動作の制御を行う。例えば、施錠制御部１０８は、判定部１０６により開錠させることが判定された場合には、施錠部１３２に開錠させる。

（１−２−１−６．乱数生成部１１０）
乱数生成部１１０は、例えば所定の範囲内の一様乱数などの、乱数を生成する。

（１−２−１−７．送信制御部１１２）
送信制御部１１２は、各種の情報をユーザ端末２０へ通信部１３０に送信させる。例えば、送信制御部１１２は、乱数生成部１１０により生成された乱数をユーザ端末２０へ通信部１３０に送信させる。

（１−２−１−８．通信部１３０）
通信部１３０は、例えばＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）などのＢｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ‐Ｆｉ（登録商標）、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などに沿った無線通信により、他の装置との間で情報の送受信を行う。例えば、通信部１３０は、送信制御部１１２の制御により、乱数をユーザ端末２０へ送信する。また、通信部１３０は、ｅＫｅｙ、開錠要求、およびユーザ端末２０の秘密鍵に基づいて生成された情報をユーザ端末２０から受信する。

（１−２−１−９．施錠部１３２）
施錠部１３２は、施錠制御部１０８の制御に従って、施錠または開錠を行う。

（１−２−１−１０．記憶部１３４）
記憶部１３４は、例えば、後述する登録鍵ＤＢ１３６などの各種のデータやソフトウェアを記憶することが可能である。

‐登録鍵ＤＢ１３６
登録鍵ＤＢ１３６は、後述するように、該当の錠前デバイス１０‐１を管理するオーナー２ａのユーザ端末２０ａに関する情報を記憶するデータベースである。また、変形例として、登録鍵ＤＢ１３６は、判定部１０６により開錠することが判定されたゲスト２ｂのユーザ端末２０ｂに関する情報を記憶することも可能である。

［１−２−２．ユーザ端末２０］
図４は、第１の実施形態によるユーザ端末２０の構成を示した機能ブロック図である。図４に示したように、ユーザ端末２０は、制御部２００、通信部２２０、操作表示部２２２、および記憶部２２４を有する。

（１−２−２−１．制御部２００）
制御部２００は、ユーザ端末２０に内蔵される、例えばＣＰＵ、ＲＡＭなどのハードウェアを用いて、ユーザ端末２０の動作を全般的に制御する。また、図４に示したように、制御部２００は、暗号生成部２０２、鍵情報発行部２０４、送信制御部２０６、招待メール生成部２０８、および表示制御部２１０を有する。

（１−２−２−２．暗号生成部２０２）
‐生成例１
暗号生成部２０２は、例えば錠前デバイス１０‐１から受信される乱数および所定のアルゴリズムに基づいて情報を生成する。例えば、暗号生成部２０２は、受信された乱数、および後述する記憶部２２４に記憶されているユーザ端末２０の秘密鍵に基づいて情報を生成する。ここで、所定のアルゴリズムは、例えばＲＳＡ暗号アルゴリズムである。

‐生成例２
また、ユーザ端末２０がオーナー２ａのユーザ端末２０である場合には、暗号生成部２０２は、ゲスト２ｂのユーザ端末２０ｂの公開鍵に対して電子署名を行うことも可能である。例えば、上記の場合には、暗号生成部２０２は、ゲスト２ｂの公開鍵を、ユーザ端末２０の秘密鍵に基づいて暗号化することにより電子署名を行う。

（１−２−２−３．鍵情報発行部２０４）
鍵情報発行部２０４は、ユーザ端末２０のユーザ２がｅＫｅｙの発行権限を有し、かつ、別のユーザ端末２０ｂに対するｅＫｅｙの発行要求が、後述するサーバ３０から受信された場合には、当該ユーザ端末２０ｂと対応づけてｅＫｅｙを発行する。より具体的には、鍵情報発行部２０４は、上記の場合には、暗号生成部２０２により生成される、ユーザ端末２０ｂの公開鍵に対する署名情報を含むようにｅＫｅｙを発行する。

（１−２−２−４．送信制御部２０６）
送信制御部２０６は、各種の情報を錠前デバイス１０‐１またはサーバ３０へ通信部２２０に送信させる。例えば、送信制御部２０６は、暗号生成部２０２により生成された情報を錠前デバイス１０‐１へ通信部２２０に送信させる。また、送信制御部２０６は、鍵情報発行部２０４により発行されたｅＫｅｙをサーバ３０へ通信部２２０に送信させる。また、送信制御部２０６は、後述する招待メール生成部２０８により生成された招待メールを、該当のユーザ端末２０へ通信部２２０に送信させる。

（１−２−２−５．招待メール生成部２０８）
招待メール生成部２０８は、別のユーザ端末２０ｂに対応づけられたｅＫｅｙＩＤ、およびサーバ３０へのリンク情報を含む招待メールを生成する。なお、ユーザ端末２０ｂがこの招待メールを受信すると、ユーザ端末２０ｂは、招待メールに記載のリンク情報に接続することにより、例えば、オーナー２ａなどのｅＫｅｙの発行権限者に対してｅＫｅｙの発行を要求することが可能となる。

（１−２−２−６．表示制御部２１０）
表示制御部２１０は、各種の表示画面を操作表示部２２２に表示させる。例えば、ユーザ端末２０がオーナー２ａのユーザ端末２０である場合には、表示制御部２１０は、別のユーザ２ｂのユーザ端末２０ｂに対するｅＫｅｙの発行を承認するか否かを入力するためのｅＫｅｙ発行承認画面を、後述する操作表示部２２２に表示させる。

（１−２−２−７．通信部２２０）
通信部２２０は、例えばＢｌｕｅｔｏｏｔｈ、Ｗｉ‐Ｆｉ、ＮＦＣなどに沿った無線通信により、他の装置との間で情報の送受信を行う。例えば、通信部２２０は、送信制御部２０６の制御により、暗号生成部２０２により生成された情報を錠前デバイス１０‐１へ送信する。

（１−２−２−８．操作表示部２２２）
操作表示部２２２は、例えばタッチパネル型のディスプレイから構成される。この操作表示部２２２は、表示制御部２１０の制御により、各種の表示画面を表示する。また、操作表示部２２２は、例えば表示画面に表示されている選択ボタンの選択など、ユーザによる各種の入力を受け付ける。

（１−２−２−９．記憶部２２４）
記憶部２２４は、例えば、ユーザ端末２０のＲＳＡ秘密鍵などの各種のデータや、各種のソフトウェアを記憶する。

［１−２−３．サーバ３０］
図５は、第１の実施形態によるサーバ３０の構成を示した機能ブロック図である。図５に示したように、サーバ３０は、制御部３００、通信部３２０、および記憶部３２２を有する。

（１−２−３−１．制御部３００）
制御部３００は、サーバ３０に内蔵される例えばＣＰＵ、ＲＡＭなどのハードウェアを用いて、サーバ３０の動作を全般的に制御する。また、図５に示したように、制御部３００は、鍵情報発行要求部３０２、送信制御部３０４、乱数生成部３０６、検証処理部３０８、および検証部３１０を有する。

（１−２−３−２．鍵情報発行要求部３０２）
鍵情報発行要求部３０２は、ゲスト２ｂのユーザ端末２０ｂからｅＫｅｙＩＤを受信した場合に、ｅＫｅｙＩＤに対応するｅＫｅｙの発行要求を生成する。

（１−２−３−３．送信制御部３０４）
送信制御部３０４は、各種の情報をユーザ端末２０へ通信部３２０に送信させる。例えば、送信制御部３０４は、鍵情報発行要求部３０２により生成された、ｅＫｅｙの発行要求をオーナー２ａのユーザ端末２０ａへ通信部３２０に送信させる。

（１−２−３−４．乱数生成部３０６）
乱数生成部３０６は、例えば所定の範囲内の一様乱数などの、乱数を生成する。

（１−２−３−５．検証処理部３０８）
検証処理部３０８は、ユーザ端末２０から受信される、ユーザ端末２０の秘密鍵に基づいて生成された情報を所定のアルゴリズムにより検証する。例えば、検証処理部１０４は、ユーザ端末２０から受信される、ユーザ端末２０の秘密鍵に基づいて生成された情報を、例えばデータベース３２に記録されているユーザ端末２０の公開鍵に基づいて復号化する。

（１−２−３−７．検証部３１０）
検証部３１０は、ユーザ端末２０から受信された情報が検証処理部３０８により検証された結果に基づいて、ユーザ端末２０の正当性を検証する。例えば、検証部３１０は、ユーザ端末２０から受信された情報が検証処理部３０８により正当であると検証された場合には、ユーザ端末２０が正当であると判定し、また、正当ではないと検証された場合にはユーザ端末２０は正当ではないと判定する。

（１−２−３−８．通信部３２０）
通信部３２０は、例えば通信網２２に接続されている他の装置との間で情報の送受信を行う。例えば、通信部３２０は、送信制御部３０４の制御により、ｅＫｅｙの発行要求を該当のオーナー２ａのユーザ端末２０ａへ送信する。

（１−２−３−９．記憶部３２２）
記憶部３２２は、各種のデータやソフトウェアを記憶する。なお、変形例として、記憶部３２２は、データベース３２を記憶することも可能である。

＜１−３．動作＞
以上、第１の実施形態による構成について説明した。続いて、第１の実施形態による動作について、図６〜図１７を参照し、以下の流れで説明を行う。
１．錠前デバイス１０‐１への鍵の登録時の動作
２．オーナー２ａの鍵の検証時の動作
３．サーバ３０へのアカウントの登録時の動作
４．サーバ３０へのユーザ端末２０の登録時の動作
５．サーバ３０によるアカウント認証時の動作
６．ゲスト２ｂの招待時の動作
７．ｅＫｅｙの発行依頼時の動作
８．ｅＫｅｙの発行時の動作
９．開錠時の動作
１０．開錠処理の動作
１１．ｅＫｅｙＧｒｏｕｐの失効要求時の動作

なお、図６〜図１７では、特に明記しない限り、ユーザ端末２０ａがオーナー２ａのユーザ端末２０であり、また、ユーザ端末２０ｂがゲスト２ｂのユーザ端末２０である例を示している。

［１−３−１．錠前デバイス１０‐１への鍵の登録時の動作］
図６は、第１の実施形態による、錠前デバイス１０‐１への鍵の登録時の動作を示したシーケンス図である。なお、この動作は、オーナー２ａのユーザ端末２０ａのｄｅｖｉｃｅＩＤや公開鍵などの情報を、オーナー２ａが管理する錠前デバイス１０‐１に対して初期登録する際の動作である。また、この動作は、基本的には、各錠前デバイス１０‐１に関して、当該錠前デバイス１０‐１を管理するオーナー２ａにより一回だけ実施される。

図６に示したように、まず、錠前デバイス１０‐１の送信制御部１１２は、定期的に、錠前デバイス１０‐１の識別情報である錠前ＩＤを周囲に発信する（Ｓ１００１）。

その後、ユーザ端末２０ａが錠前デバイス１０‐１に接近すると、ユーザ端末２０ａは、錠前デバイス１０‐１から発信されている錠前ＩＤを受信し、そして、受信した錠前ＩＤに基づいて目的の錠前デバイス１０‐１であるか否かを判定する。目的の錠前デバイス１０‐１である場合には、ユーザ端末２０ａは、錠前デバイス１０‐１とのセッションを確立する（Ｓ１００３）。

続いて、ユーザ端末２０ａの送信制御部２０６は、ユーザ端末２０ａのｄｅｖｉｃｅＩＤおよびユーザ端末２０ａのＲＳＡ公開鍵を錠前デバイス１０‐１へ通信部２２０に送信させる（Ｓ１００５）。

その後、錠前デバイス１０‐１の制御部１００‐１は、Ｓ１００５で受信されたｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録済みであるか否かを確認する（Ｓ１００７）。ｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録済みである場合には（Ｓ１００７：Ｙｅｓ）、錠前デバイス１０‐１は、後述するＳ１０１９の動作を行う。

一方、ｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録されていない場合には（Ｓ１００７：Ｎｏ）、乱数生成部１１０は、乱数を生成する。そして、送信制御部１１２は、生成された乱数をユーザ端末２０ａへ通信部１３０に送信させる（Ｓ１００９）。

その後、ユーザ端末２０ａの暗号生成部２０２は、Ｓ１００９で受信された乱数を、ユーザ端末２０ａのＲＳＡ秘密鍵で暗号化することにより、ＲＳＡ署名データを生成する（Ｓ１０１１）。

続いて、送信制御部２０６は、Ｓ１０１１で生成されたＲＳＡ署名データを錠前デバイス１０‐１へ通信部２２０に送信させる（Ｓ１０１３）。

その後、錠前デバイス１０‐１の検証処理部１０４は、Ｓ１０１３で受信されたＲＳＡ署名データを、Ｓ１００５で受信されたＲＳＡ公開鍵を用いて復号化する（Ｓ１０１５）。

続いて、判定部１０６は、Ｓ１０１５で復号化された情報とＳ１００９で生成された乱数とを比較する（Ｓ１０１７）。両者が一致しない場合には（Ｓ１０１７：Ｎｏ）、判定部１０６は、Ｒｅｓｕｌｔ（＝登録結果）に「ＮＧ」を設定する（Ｓ１０１９）。その後、錠前デバイス１０‐１は、後述するＳ１０２５の動作を行う。

一方、両者が一致する場合には（Ｓ１０１７：Ｙｅｓ）、判定部１０６は、Ｒｅｓｕｌｔに「ＯＫ」を設定する（Ｓ１０２１）。そして、判定部１０６は、Ｓ１００５で受信されたｄｅｖｉｃｅＩＤとＲＳＡ公開鍵とを対応づけて登録鍵ＤＢ１３６に記録する（Ｓ１０２３）。

その後、送信制御部１１２は、Ｓ１０１９またはＳ１０２１で設定されたＲｅｓｕｌｔをユーザ端末２０ａへ通信部１３０に送信させる（Ｓ１０２５）。

［１−３−２．オーナー２ａの鍵の検証時の動作］
次に、図７を参照して、第１の実施形態による、オーナー２ａの鍵の検証時の動作について説明する。なお、この動作は、錠前デバイス１０‐１が、通信対象のユーザ端末２０がオーナー２ａのユーザ端末２０ａであるか否かを検証するために行う動作である。例えば、この動作は、錠前デバイス１０‐１に登録されているデータの削除要求などオーナー２ａにのみ許可されている処理をユーザ端末２０が要求した際などに行われる。

図７に示したＳ１１０１〜Ｓ１１０５の動作は、図６に示したＳ１００１〜Ｓ１００５の動作と概略同様である。但し、Ｓ１１０３では、ユーザ端末２０ａは、Ｓ１１０１で受信された錠前ＩＤが、公開鍵を登録済みの錠前デバイス１０‐１の錠前ＩＤである場合に、錠前デバイス１０‐１とのセッションを確立する点が、Ｓ１００３とは相違する。

Ｓ１１０５の後、錠前デバイス１０‐１の制御部１００‐１は、Ｓ１１０５で受信されたｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録済みであるか否かを確認する（Ｓ１１０７）。ｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録されていない場合には（Ｓ１１０７：Ｎｏ）、錠前デバイス１０‐１は、後述するＳ１１１９の動作を行う。

一方、ｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録済みである場合には（Ｓ１１０７：Ｙｅｓ）、乱数生成部１１０は、乱数を生成する。そして、送信制御部１１２は、生成された乱数をユーザ端末２０ａへ通信部１３０に送信させる（Ｓ１１０９）。

なお、Ｓ１１１１〜Ｓ１１１５の動作は、図６に示したＳ１０１１〜Ｓ１０１５の動作と概略同様である。

Ｓ１１１５の後、判定部１０６は、Ｓ１１１５で復号化された情報とＳ１１０９で生成された乱数とを比較する（Ｓ１１１７）。両者が一致しない場合には（Ｓ１１１７：Ｎｏ）、判定部１０６は、Ｒｅｓｕｌｔ（＝検証結果）に「ＮＧ」を設定し、そして、ユーザ端末２０ａを認証しない（Ｓ１１１９）。その後、錠前デバイス１０‐１は、後述するＳ１１２３の動作を行う。

一方、両者が一致する場合には（Ｓ１１１７：Ｙｅｓ）、判定部１０６は、Ｒｅｓｕｌｔに「ＯＫ」を設定し、そして、ユーザ端末２０ａを認証する（Ｓ１１２１）。

その後、送信制御部１１２は、Ｓ１１１９またはＳ１１２１で設定されたＲｅｓｕｌｔをユーザ端末２０ａへ通信部１３０に送信させる（Ｓ１１２３）。

［１−３−３．サーバ３０へのアカウントの登録時の動作］
次に、図８を参照して、第１の実施形態による、サーバ３０へのアカウントの登録時の動作について説明する。なお、この動作は、例えば、ユーザ２が鍵認証サービスを利用するためにサーバ３０にアカウントを登録する際の動作である。ここで、ユーザ２は、オーナー２ａであってもよいし、（１−３−６節で説明する、招待メールを受信済みの）ゲスト２ｂであってもよい。

図８に示したように、まず、ユーザ端末２０は、サーバ３０へアクセスする。そして、ユーザ端末２０の操作表示部２２２は、例えばサーバ３０から受信されるアカウント登録画面を表示し、そして、当該登録画面において、ユーザ２によるユーザ名およびｅ−ｍａｉｌアドレスの入力、および（例えば個人識別に用いられる）アイコン画像の選択を受け付ける。その後、送信制御部２０６は、入力内容を含む、アカウントの登録要求をサーバ３０へ通信部２２０に送信させる（Ｓ１２０１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１２０１で受信されたｅ−ｍａｉｌアドレスと同じｅ−ｍａｉｌアドレスが登録されているか否かの確認要求をデータベース３２へ通信部３２０に送信させる（Ｓ１２０３）。

その後、データベース３２は、Ｓ１２０３で受信された要求に基づいて確認を行い、そして、確認結果をサーバ３０へ送信する（Ｓ１２０５）。

その後、同じｅ−ｍａｉｌアドレスが登録されていることが確認された場合には（Ｓ１２０７：Ｙｅｓ）、サーバ３０の送信制御部３０４は、該当のアカウントの登録不可の通知をユーザ端末２０へ通信部３２０に送信させる（Ｓ１２０９）。そして、当該「サーバ３０へのアカウントの登録時の動作」は終了する。

一方、同じｅ−ｍａｉｌアドレスが登録されていないことが確認された場合には（Ｓ１２０７：Ｎｏ）、送信制御部３０４は、Ｓ１２０１で受信されたアイコン画像の保存要求をデータベース３２へ通信部３２０に送信させる（Ｓ１２１１）。

その後、データベース３２は、Ｓ１２１１で受信されたアイコン画像の保存先のＵＲＬを決定する。そして、データベース３２は、受信されたアイコン画像と、決定したＵＲＬとを対応づけて記憶する（Ｓ１２１３）。そして、データベース３２は、Ｓ１２１３で決定したＵＲＬをサーバ３０へ送信する（Ｓ１２１５）。

その後、サーバ３０の送信制御部３０４は、Ｓ１２０１で受信されたユーザ名およびｅ−ｍａｉｌアドレス、およびＳ１２１５で受信されたアイコンＵＲＬを含む、アカウントの作成要求をデータベース３２へ通信部３２０に送信させる（Ｓ１２１７）。

その後、データベース３２は、該当のユーザ２に対応するｗｅｂＩＤを決定する。そして、データベース３２は、Ｓ１２１７で受信された作成要求に含まれるユーザ名、ｅ−ｍａｉｌアドレス、アイコンＵＲＬ、および、決定したｗｅｂＩＤを対応づけて記憶する（Ｓ１２１９）。

続いて、データベース３２は、Ｓ１２１９で決定したｗｅｂＩＤをサーバ３０へ送信する（Ｓ１２２１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１２２１で受信されたｗｅｂＩＤを含む、アカウントの登録完了の通知をユーザ端末２０へ通信部３２０に送信させる（Ｓ１２２３）。

［１−３−４．サーバ３０へのユーザ端末２０の登録時の動作］
次に、図９を参照して、第１の実施形態による、サーバ３０へのユーザ端末２０の登録時の動作について説明する。なお、この動作は、ユーザ２が鍵認証サービスを利用するためにユーザ端末２０の情報をサーバ３０に登録する際の動作である。また、この動作は、例えば、１−３−３節で述べた「サーバ３０へのアカウントの登録時の動作」の直後に行われる。なお、以下では、ゲスト２ｂのユーザ端末２０ｂの情報を登録する際の動作例について説明するが、オーナー２ａのユーザ端末２０ａの情報を登録する際に関しても概略同様である。

図９に示したように、まず、ユーザ端末２０ｂは、サーバ３０へアクセスする。そして、ユーザ端末２０ｂは、ユーザ端末２０ｂのｄｅｖｉｃｅＩＤ、（サーバ３０から発行済みの）ユーザｗｅｂＩＤ、ユーザ端末２０ｂのＲＳＡ公開鍵、およびユーザ端末２０ｂのデバイス名を含む、デバイスの登録要求をサーバ３０へ送信する（Ｓ１３０１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１３０１で受信されたｄｅｖｉｃｅＩＤと同じｄｅｖｉｃｅＩＤが登録済みであるか否かの確認要求をデータベース３２へ通信部３２０に送信させる（Ｓ１３０３）。

その後、データベース３２は、Ｓ１３０３で受信された要求に基づいて確認を行い、そして、確認結果をサーバ３０へ送信する（Ｓ１３０５）。

その後、同じｄｅｖｉｃｅＩＤが登録されていることが確認された場合には（Ｓ１３０７：Ｙｅｓ）、サーバ３０の送信制御部３０４は、該当のユーザ端末２０ｂの登録不可の通知をユーザ端末２０ｂへ通信部３２０に送信させる（Ｓ１３０９）。

一方、同じｄｅｖｉｃｅＩＤが登録されていないことが確認された場合には（Ｓ１３０７：Ｎｏ）、サーバ３０の送信制御部３０４は、同じユーザ２ｂ（すなわち、ユーザｗｅｂＩＤが同じユーザ２ｂ）によるデバイス登録の有無の確認要求をデータベース３２へ通信部３２０に送信させる（Ｓ１３１１）。

その後、データベース３２は、Ｓ１３１１で受信された要求に基づいて確認を行い、そして、確認結果をサーバ３０へ送信する（Ｓ１３１３）。

その後、同じユーザ２ｂにより別のデバイスを登録されていないことが確認された場合には（Ｓ１３１５：Ｎｏ）、サーバ３０は、後述するＳ１３２５の動作を行う。

一方、同じユーザ２ｂにより別のデバイスを登録されていることが確認された場合には（Ｓ１３１５：Ｙｅｓ）、サーバ３０の送信制御部３０４は、Ｓ１３０１で受信されたｄｅｖｉｃｅＩＤおよびデバイス名を含む、新たなデバイスの登録の承認要求を、オーナー２ａのユーザ端末２０ａへ通信部３２０に送信させる（Ｓ１３１７）。

その後、ユーザ端末２０ａの表示制御部２１０は、例えば、Ｓ１３１７で受信された承認要求に対して承認するか否かを入力するためのデバイス登録承認画面を操作表示部２２２に表示させる。そして、送信制御部２０６は、操作表示部２２２に対するオーナー２ａの入力に基づいて、Ｓ１３１７で受信されたｄｅｖｉｃｅＩＤを含む、デバイスの登録を承認するか否かの通知を生成し、そして、生成した通知をサーバ３０へ通信部２２０に送信させる（Ｓ１３１９）。

その後、サーバ３０の制御部３００は、Ｓ１３１９で受信された通知の内容を確認する（Ｓ１３２１）。受信された通知の内容がデバイスの登録を拒否することを示す場合には（Ｓ１３２１：Ｎｏ）、送信制御部３０４は、該当のユーザ端末２０ｂの登録不可の通知をユーザ端末２０ｂへ通信部３２０に送信させる（Ｓ１３２３）。

一方、受信された通知の内容がデバイスの登録を承認することを示す場合には（Ｓ１３２１：Ｙｅｓ）、送信制御部３０４は、Ｓ１３０１で受信された登録要求に基づいて、デバイス登録要求をデータベース３２へ通信部３２０に送信させる（Ｓ１３２５）。

その後、データベース３２は、Ｓ１３２５で受信されたデバイス登録要求に含まれるｄｅｖｉｃｅＩＤ、ユーザｗｅｂＩＤ、ＲＳＡ公開鍵、およびデバイス名を対応づけて記憶する（Ｓ１３２７）。

［１−３−５．サーバ３０によるアカウント認証時の動作］
次に、図１０を参照して、第１の実施形態による、サーバ３０によるアカウント認証時の動作について説明する。なお、この動作は、上述したサーバ３０へのアカウントの登録およびユーザ端末２０の登録の終了後に、例えば、ユーザ端末２０が鍵認証サービスへログインする度に行われる動作である。

図１０に示したように、まず、ユーザ端末２０の送信制御部２０６は、ユーザ端末２０のｄｅｖｉｃｅＩＤを含む、チャレンジ取得要求をサーバ３０へ通信部２２０に送信させる（Ｓ１４０１）。

その後、サーバ３０の乱数生成部３０６は、例えば一様乱数であるチャレンジを生成する（Ｓ１４０３）。そして、送信制御部３０４は、Ｓ１４０３で生成されたチャレンジをユーザ端末２０へ通信部３２０に送信させる（Ｓ１４０５）。

その後、ユーザ端末２０の暗号生成部２０２は、Ｓ１４０５で受信されたチャレンジを、ユーザ端末２０のＲＳＡ秘密鍵で暗号化することにより、ＲＳＡ署名データを生成する（Ｓ１４０７）。

続いて、送信制御部２０６は、Ｓ１４０７で生成されたＲＳＡ署名データをサーバ３０へ通信部２２０に送信させる（Ｓ１４０９）。

その後、サーバ３０の送信制御部３０４は、Ｓ１４０１で受信されたｄｅｖｉｃｅＩＤに対応するＲＳＡ公開鍵の取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ１４１１）。

その後、データベース３２は、Ｓ１４１１で受信された取得要求に含まれるｄｅｖｉｃｅＩＤに対応するＲＳＡ公開鍵を抽出し、そして、抽出したＲＳＡ公開鍵をサーバ３０へ送信する（Ｓ１４１３）。

その後、サーバ３０の検証処理部３０８は、Ｓ１４０９で受信されたＲＳＡ署名データを、Ｓ１４１３で受信されたＲＳＡ公開鍵を用いて復号化する（Ｓ１４１５）。

続いて、検証部３１０は、Ｓ１４１５で復号化された情報とＳ１４０３で生成されたチャレンジとを比較する（Ｓ１４１７）。両者が一致しない場合には（Ｓ１４１７：Ｎｏ）、検証部３１０は、Ｒｅｓｕｌｔ（＝認証結果）に「ＮＧ」を設定し、そして、ユーザ端末２０を認証しない（Ｓ１４１９）。その後、サーバ３０は、後述するＳ１４２３の動作を行う。

一方、両者が一致する場合には（Ｓ１４１７：Ｙｅｓ）、検証部３１０は、Ｒｅｓｕｌｔに「ＯＫ」を設定し、そして、ユーザ端末２０を認証する（Ｓ１４２１）。

その後、送信制御部３０４は、Ｓ１４１９またはＳ１４２１で設定されたＲｅｓｕｌｔをユーザ端末２０へ通信部３２０に送信させる（Ｓ１４２３）。

［１−３−６．ゲスト２ｂの招待時の動作］
次に、図１１を参照して、第１の実施形態による、ゲスト２ｂの招待時の動作について説明する。なお、この動作は、例えば、オーナー２ａが、錠前デバイス１０‐１の開錠権を与えることを認めたゲスト２ｂに対して開錠権を付与するために行われる動作である。

図１１に示したように、まず、ユーザ端末２０ａの鍵情報発行部２０４は、例えば操作表示部２２２に対するオーナー２ａの入力に基づいて、特定の錠前デバイス１０‐１に対応づけられるｅＫｅｙＧｒｏｕｐＩＤを生成する（Ｓ１５０１）。なお、この際、該当のｅＫｅｙＧｒｏｕｐＩＤに対応するｅＫｅｙＧｒｏｕｐの有効期限、および有効性確認フラグの値も設定される。詳細については後述するが、有効性確認フラグは、錠前デバイス１０‐１が開錠要求時においてユーザ端末２０から受信されるｅＫｅｙの有効性について錠前デバイス１０‐１がサーバ３０に問い合わせる必要があるか否かを定められたフラグである。

続いて、送信制御部２０６は、Ｓ１５０１で生成されたｅＫｅｙＧｒｏｕｐＩＤ、ｅＫｅｙＧｒｏｕｐＩＤに対応する錠前デバイスＩＤ、オーナー２ａのｗｅｂＩＤ、Ｓ１５０１で設定された有効期限、および有効性確認フラグを含む、ｅＫｅｙＧｒｏｕｐの登録要求をサーバ３０へ通信部２２０に送信させる（Ｓ１５０３）。

その後、サーバ３０の送信制御部３０４は、Ｓ１５０３で受信された登録要求に含まれるｅＫｅｙＧｒｏｕｐＩＤと同じｅＫｅｙＧｒｏｕｐＩＤが登録済みであるか否かの確認要求をデータベース３２へ通信部３２０に送信させる（Ｓ１５０５）。

その後、データベース３２は、Ｓ１５０５で受信された要求に基づいて確認を行い、そして、確認結果をサーバ３０へ送信する（Ｓ１５０７）。

その後、同じｅＫｅｙＧｒｏｕｐＩＤが登録されていることが確認された場合には（Ｓ１５０９：Ｙｅｓ）、サーバ３０の送信制御部３０４は、ｅＫｅｙＧｒｏｕｐの登録不可の通知をユーザ端末２０ａへ通信部３２０に送信させる（Ｓ１５１１）。そして、当該「ゲスト２ｂの招待時の動作」は終了する。

一方、同じｅＫｅｙＧｒｏｕｐＩＤが登録されていないことが確認された場合には（Ｓ１５０９：Ｎｏ）、サーバ３０の送信制御部３０４は、Ｓ１５０３で受信された登録要求に基づいて、ｅＫｅｙＧｒｏｕｐの登録要求をデータベース３２へ通信部３２０に送信させる（Ｓ１５１３）。

その後、データベース３２は、Ｓ１５１３で受信された登録要求に含まれる、ｅＫｅｙＧｒｏｕｐＩＤ、錠前デバイスＩＤ、オーナー２ａのｗｅｂＩＤ、有効期限、および有効性確認フラグを対応づけて記憶する（Ｓ１５１５）。

その後、サーバ３０の送信制御部３０４は、ｅＫｅｙＧｒｏｕｐの登録完了の通知をユーザ端末２０ａへ通信部３２０に送信させる（Ｓ１５１７）。

その後、ユーザ端末２０ａの送信制御部２０６は、該当のｅＫｅｙＧｒｏｕｐＩＤを含む、（ゲスト２ｂをｅＫｅｙＧｒｏｕｐに招待するための）招待メール用のＵＲＬの取得要求をサーバ３０へ通信部２２０に送信させる（Ｓ１５１９）。

その後、サーバ３０の制御部３００は、Ｓ１５１９で受信された取得要求に基づいて、招待メール用のＵＲＬを決定する。なお、このＵＲＬは、例えば、サーバ３０における所定のリンク先へのリンク情報である。

そして、送信制御部３０４は、決定したＵＲＬをユーザ端末２０ａへ通信部３２０に送信させる（Ｓ１５２１）。

その後、ユーザ端末２０ａの招待メール生成部２０８は、Ｓ１５２１で受信されたＵＲＬを含む招待メールを生成する（Ｓ１５２３）。そして、送信制御部２０６は、Ｓ１５２３で生成した招待メールをサーバ３０へ通信部２２０に送信させる（Ｓ１５２５）。

その後、ユーザ端末２０ｂ、サーバ３０、およびデータベース３２の間で、１−３−３節で述べた「サーバ３０へのアカウントの登録時の動作」と概略同様の処理を行う（Ｓ１５２７）。

その後、ユーザ端末２０ａ、ユーザ端末２０ｂ、サーバ３０、およびデータベース３２の間で、後述する「ｅＫｅｙの発行依頼時の動作」を行う（Ｓ１５２９）。

［１−３−７．ｅＫｅｙの発行依頼時の動作］
次に、図１２を参照して、Ｓ１５２９における「ｅＫｅｙの発行依頼時の動作」について詳細に説明する。なお、この動作は、例えば、オーナー２ａから招待メールを受け取ったゲスト２ｂが、サーバ３０を介してオーナー２ａにｅＫｅｙの発行を依頼する際の動作である。

図１２に示したように、まず、ユーザ端末２０ｂは、図１１に示したＳ１５２５で受信された招待メールに記載されているＵＲＬへアクセスする（Ｓ１５５１）。これにより、ユーザ端末２０ｂは、サーバ３０における所定のリンク先にアクセスできる。

続いて、ユーザ端末２０ｂの送信制御部２０６は、Ｓ１５２５で受信された招待メールに記載されているｅＫｅｙＧｒｏｕｐＩＤ、およびユーザ端末２０ｂのｄｅｖｉｃｅＩＤを含む、ｅＫｅｙの発行依頼をサーバ３０へ通信部２２０に送信させる（Ｓ１５５３）。

その後、サーバ３０の送信制御部３０４は、Ｓ１５５３で受信されたｅＫｅｙ発行依頼基づいてオーナー２ａのｗｅｂＩＤの取得要求を、データベース３２へ通信部３２０に送信させる（Ｓ１５５５）。

その後、データベース３２は、受信された取得要求に含まれるｅＫｅｙＧｒｏｕｐＩＤに対応するオーナー２ａのｗｅｂＩＤを抽出し、そして、抽出したｗｅｂＩＤをサーバ３０へ送信する（Ｓ１５５７）。

その後、サーバ３０の送信制御部３０４は、Ｓ１５５３で受信されたｅＫｅｙ発行依頼に基づいて、デバイス名およびユーザ名の取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ１５５９）。

その後、データベース３２は、Ｓ１５５９で受信された取得要求に含まれるｄｅｖｉｃｅＩＤに対応するデバイス名およびユーザ名を抽出し、そして、抽出したデバイス名およびユーザ名をサーバ３０へ送信する（Ｓ１５６１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１５５３で受信されたｅＫｅｙ発行依頼に含まれるｅＫｅｙＧｒｏｕｐＩＤ、ｄｅｖｉｃｅＩＤ、Ｓ１５６１で受信されたデバイス名およびユーザ名を含む、ｅＫｅｙの発行依頼を、Ｓ１５５７で受信されたｗｅｂＩＤに対応するユーザ端末２０ａに対してＰｕｓｈ通知する（Ｓ１５６３）。

その後、ユーザ端末２０ａの表示制御部２１０は、Ｓ１５６３で通知された発行依頼に基づいて、例えばｅＫｅｙ発行承認画面を操作表示部２２２に表示させる。そして、操作表示部２２２に対してオーナー２ａにより承認しないことが入力された場合には（Ｓ１５６５：Ｎｏ）、ユーザ端末２０ａは処理を終了する。そして、当該「ｅＫｅｙの発行依頼時の動作」は終了する。

一方、オーナー２ａにより承認することが入力された場合には（Ｓ１５６５：Ｙｅｓ）、ユーザ端末２０ａの鍵情報発行部２０４は、例えばＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）であるｅＫｅｙＩＤを生成する（Ｓ１５６７）。

その後、ユーザ端末２０ａの送信制御部２０６は、Ｓ１５６３で通知されたｄｅｖｉｃｅＩＤに対応するＲＳＡ公開鍵の取得要求をサーバ３０へ通信部２２０に送信させる（Ｓ１５６９）。

その後、サーバ３０の送信制御部３０４は、Ｓ１５６９で受信された取得要求に基づいて、ＲＳＡ公開鍵の取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ１５７１）。

その後、データベース３２は、受信された取得要求に含まれるｄｅｖｉｃｅＩＤに対応するＲＳＡ公開鍵を抽出し、そして、抽出したＲＳＡ公開鍵をサーバ３０へ送信する（Ｓ１５７３）。

その後、サーバ３０の送信制御部３０４は、Ｓ１５７３で受信されたＲＳＡ公開鍵をユーザ端末２０ａへ通信部３２０に送信させる（Ｓ１５７５）。

その後、ユーザ端末２０ａの暗号生成部２０２は、Ｓ１５７５で受信されたＲＳＡ公開鍵（つまり、ゲスト２ｂのＲＳＡ公開鍵）に対してユーザ端末２０ａのＲＳＡ秘密鍵を用いて電子署名を行うことにより、受信されたＲＳＡ公開鍵の証明書を生成する（Ｓ１５７７）。

その後、ユーザ端末２０ａ、ユーザ端末２０ｂ、サーバ３０、およびデータベース３２の間で、後述する「ｅＫｅｙの発行時の動作」を行う（Ｓ１５７９）。

［１−３−８．ｅＫｅｙの発行時の動作］
次に、図１３を参照して、Ｓ１５７９における「ｅＫｅｙの発行時の動作」について詳細に説明する。なお、この動作は、例えば、オーナー２ａのユーザ端末２０ａがゲスト２ｂのユーザ端末２０ｂのｅＫｅｙを発行し、そして、サーバ３０を介してユーザ端末２０ｂへｅＫｅｙを受け渡す際の動作である。

図１３に示したように、まず、ユーザ端末２０ａの鍵情報発行部２０４は、例えば、図１２に示したＳ１５６７で生成されたｅＫｅｙＩＤ、ユーザ端末２０ａのｄｅｖｉｃｅＩＤ、およびＳ１５７７で生成されたＲＳＡ公開鍵の証明書を含む、ｅＫｅｙを発行する（Ｓ１６０１）。そして、送信制御部２０６は、Ｓ１６０１で発行されたｅＫｅｙおよびｅＫｅｙＩＤをサーバ３０へ通信部２２０に送信させる（Ｓ１６０３）。

その後、サーバ３０の送信制御部３０４は、Ｓ１６０３で受信されたｅＫｅｙＩＤおよびｅＫｅｙをデータベース３２へ通信部３２０に送信させる（Ｓ１６０５）。

その後、データベース３２は、Ｓ１６０５で受信されたｅＫｅｙＩＤおよびｅＫｅｙを対応づけて記憶する（Ｓ１６０７）。

その後、サーバ３０の送信制御部３０４は、Ｓ１６０３で受信されたｅＫｅｙＩＤを含む、ｅＫｅｙの発行通知を、ユーザ端末２０ｂへＰｕｓｈ通知する（Ｓ１６０９）。

その後、ユーザ端末２０ｂの送信制御部２０６は、Ｓ１６０９で通知されたｅＫｅｙＩＤに対応するｅＫｅｙの取得要求を、例えば操作表示部２２２に対するゲスト２ｂの入力に基づいて、サーバ３０へ通信部２２０に送信させる（Ｓ１６１１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１６１１で受信された取得要求に基づいて、ｅＫｅｙの取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ１６１３）。

その後、データベース３２は、Ｓ１６１３で受信された取得要求に含まれるｅＫｅｙＩＤに対応するｅＫｅｙを抽出し、そして、抽出したｅＫｅｙをサーバ３０へ送信する（Ｓ１６１５）。

その後、サーバ３０の送信制御部３０４は、Ｓ１６０３で受信されたｅＫｅｙＩＤを含む、ｅＫｅｙの取得完了の通知を、（オーナー２ａの）ユーザ端末２０ａへＰｕｓｈ通知する（Ｓ１６１７）。

続いて、送信制御部３０４は、Ｓ１６１５で受信されたｅＫｅｙをユーザ端末２０ｂへ通信部３２０に送信させる（Ｓ１６１９）。

その後、ユーザ端末２０ｂの送信制御部２０６は、該当のｅＫｅｙＩＤを含む、ｅＫｅｙの有効性確認フラグの取得要求を、例えば操作表示部２２２に対するユーザの入力に基づいて、サーバ３０へ通信部２２０に送信させる（Ｓ１６２１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１６２１で受信された取得要求に基づいて、有効性確認フラグの取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ１６２３）。

その後、データベース３２は、Ｓ１６２３で受信された取得要求に含まれるｅＫｅｙＩＤに対応する有効性確認フラグを抽出し、そして、抽出した有効性確認フラグをサーバ３０へ送信する（Ｓ１６２５）。

その後、サーバ３０の送信制御部３０４は、Ｓ１６２５で受信された有効性確認フラグをユーザ端末２０ｂへ通信部３２０に送信させる（Ｓ１６２７）。

［１−３−９．開錠時の動作］
次に、図１４を参照して、第１の実施形態による、開錠時の動作について説明する。なお、この動作は、例えば、該当の錠前デバイス１０‐１に対応するｅＫｅｙを所有しているユーザ端末２０が錠前デバイス１０‐１に接近し、そして、錠前デバイス１０‐１に開錠を要求する際の動作である。以下では、ゲスト２ｂのユーザ端末２０ｂが開錠要求を行う際の動作例について説明するが、オーナー２ａのユーザ端末２０ａが開錠要求を行う際に関しても概略同様である。

図１４に示したように、まず、ユーザ端末２０ｂは、図１３に示したＳ１６２７で受信された有効性確認フラグの値が「ＯＮ」であるか否かを確認する（Ｓ１７０１）。有効性確認フラグの値が「ＯＮ」ではない場合には（Ｓ１７０１：Ｎｏ）、ユーザ端末２０ｂは、後述するＳ１７１３の動作を行う。

一方、有効性確認フラグの値が「ＯＮ」である場合には（Ｓ１７０１：Ｙｅｓ）、ユーザ端末２０ｂの送信制御部２０６は、該当のｅＫｅｙＩＤを含む、ｅＫｅｙの有効性の確認要求をサーバ３０へ通信部２２０に送信させる（Ｓ１７０３）。

その後、サーバ３０の送信制御部３０４は、Ｓ１７０３で受信された確認要求に基づいて、ｅＫｅｙの有効性の確認要求をデータベース３２に通信部２２０に送信させる（Ｓ１７０５）。

その後、データベース３２は、Ｓ１７０５で受信された確認要求に含まれるｅＫｅｙＩＤに対応するｅＫｅｙの有効性に関する情報を抽出し、そして、抽出した情報をサーバ３０へ送信する（Ｓ１７０７）。

その後、サーバ３０の送信制御部３０４は、Ｓ１７０７で受信された情報に基づいた有効性の確認結果をユーザ端末２０ｂへ通信部３２０に送信させる（Ｓ１７０９）。

その後、Ｓ１７０９で受信された確認結果がｅＫｅｙが有効ではないことを示す場合には（Ｓ１７１１：Ｎｏ）、ユーザ端末２０ｂは、処理を終了する。そして、当該「開錠時の動作」は終了する。

一方、Ｓ１７０９で受信された確認結果がｅＫｅｙが有効であることを示す場合には（Ｓ１７１１：Ｙｅｓ）、ユーザ端末２０ｂは、後述する「開錠処理」を行う（Ｓ１７１３）。

そして、Ｓ１７１３において開錠に失敗した場合には（Ｓ１７１５：Ｎｏ）、ユーザ端末２０ｂは、処理を終了する。そして、当該「開錠時の動作」は終了する。

一方、開錠に成功した場合には（Ｓ１７１５：Ｙｅｓ）、ユーザ端末２０ｂの送信制御部２０６は、ユーザ端末２０ｂのユーザｗｅｂＩＤおよびｅＫｅｙＩＤを含む、開錠実施の通知をサーバ３０へ通信部２２０に送信させる（Ｓ１７１７）。

その後、サーバ３０の送信制御部３０４は、Ｓ１７１７で受信された開錠実施の通知に基づいて、オーナー２ａのｗｅｂＩＤ、およびゲスト２ｂのユーザ名およびデバイス名の取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ１７１９）。

その後、データベース３２は、Ｓ１７１９で受信された取得要求に含まれるｅＫｅｙＩＤに対応するオーナー２ａのｗｅｂＩＤ、および当該取得要求に含まれるユーザｗｅｂＩＤに対応するユーザ名およびデバイス名を抽出し、そして、抽出した情報をサーバ３０へ送信する（Ｓ１７２１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１７１７で受信されたｅＫｅｙＩＤ、Ｓ１７２１で受信されたユーザ名、およびデバイス名を含む、開錠実施の通知を、Ｓ１７２１で受信されたｗｅｂＩＤに対応するユーザ端末２０（つまり、オーナー２ａのユーザ端末２０ａ）へ通信部２２０に送信させる（Ｓ１７２３）。

［１−３−１０．開錠処理の動作］
次に、図１５および図１６を参照して、Ｓ１７１３における「開錠処理の動作」について詳細に説明する。なお、図１５に示したＳ１８０１〜Ｓ１８０３の動作は、図７に示したＳ１１０１〜Ｓ１１０３の動作と同様である。

Ｓ１８０３の後、ユーザ端末２０の送信制御部２０６は、ユーザ端末２０のｄｅｖｉｃｅＩＤおよび（例えば図１３に示したＳ１６１９で受信された）ｅＫｅｙを錠前デバイス１０‐１へ通信部２２０に送信させる（Ｓ１８０５）。

その後、錠前デバイス１０‐１の制御部１００‐１は、Ｓ１８０５で受信されたｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録済みであるか否かを確認する（Ｓ１８０７）。ｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録されていない場合には（Ｓ１８０７：Ｎｏ）、錠前デバイス１０‐１は、後述するＳ１８３１の動作を行う。

一方、ｄｅｖｉｃｅＩＤが登録鍵ＤＢ１３６に記録されている場合には（Ｓ１８０７：Ｙｅｓ）、鍵情報検証部１０２は、Ｓ１８０５で受信されたｅＫｅｙに含まれる有効期間の値を確認し、そして、現在がｅＫｅｙの有効期間内であるか否かを判定する（Ｓ１８０９）。ｅＫｅｙの有効期間外である場合には（Ｓ１８０９：Ｎｏ）、錠前デバイス１０‐１は、後述するＳ１８３１の動作を行う。

一方、ｅＫｅｙの有効期間内である場合には（Ｓ１８０９：Ｙｅｓ）、検証処理部１０４は、該当のｅＫｅｙに含まれる、ユーザ２ｂの公開鍵のＲＳＡ証明書を、登録鍵ＤＢ１３６に記録されているオーナー２ａのユーザ端末２０ａのＲＳＡ公開鍵を用いて復号化する（Ｓ１８１１）。

そして、鍵情報検証部１０２は、Ｓ１８１１で復号化した証明書に基づいて、ユーザ２ｂのＲＳＡ公開鍵が正当であるか否かを判定する（Ｓ１８１３）。ユーザ２ｂのＲＳＡ公開鍵が正当でないと判定された場合には（Ｓ１８１３：Ｎｏ）、錠前デバイス１０‐１は、後述するＳ１８３１の動作を行う。

一方、ユーザ２ｂのＲＳＡ公開鍵が正当であると判定された場合には（Ｓ１８１３：Ｙｅｓ）、乱数生成部１１０は、乱数を生成する。そして、送信制御部１１２は、生成された乱数をユーザ端末２０へ通信部１３０に送信させる（Ｓ１８２１）。

次に、図１６を参照して、Ｓ１８２１より後の動作について説明する。なお、Ｓ１８２３〜Ｓ１８２７の動作は、図６に示したＳ１０１１〜Ｓ１０１５と同様である。

Ｓ１８２７の後、錠前デバイス１０‐１の判定部１０６は、Ｓ１８２７で復号化された情報とＳ１８２１で生成された乱数とを比較する（Ｓ１８２９）。両者が一致しない場合には（Ｓ１８２９：Ｎｏ）、判定部１０６は、開錠しないことを決定する（Ｓ１８３１）。その後、錠前デバイス１０‐１は、後述するＳ１８３５の動作を行う。

一方、両者が一致する場合には（Ｓ１８２９：Ｙｅｓ）、判定部１０６は、開錠することを決定する。そして、施錠制御部１０８は、施錠部１３２に開錠させる（Ｓ１８３３）。

その後、送信制御部１１２は、Ｓ１８３１またはＳ１８３３の実行結果をユーザ端末２０へ通信部１３０に送信させる（Ｓ１８３５）。

（１−３−１０−１．変形例）
なお、Ｓ１８３３の変形例として、ユーザ端末２０がゲスト２ｂのユーザ端末２０であり、かつ、該当のユーザ端末２０による最初の開錠時である場合には、判定部１０６は、Ｓ１８０５で受信されたｅＫｅｙに含まれるヘッダー４００とＲＳＡ公開鍵とを対応づけて登録鍵ＤＢ１３６に記録することも可能である。この変形例によれば、該当のユーザ端末２０による２回目以降の開錠要求時に、例えばＳ１８０５〜Ｓ１８１３において、ｅＫｅｙの送信およびｅＫｅｙの検証などの処理を省略することが可能となる。これにより、処理を高速化させることが可能となる。

［１−３−１１．ｅＫｅｙＧｒｏｕｐの失効要求時の動作］
次に、図１７を参照して、第１の実施形態による、ｅＫｅｙＧｒｏｕｐの失効要求時の動作について説明する。なお、この動作は、例えば錠前デバイス１０‐１の取り換え時などに、錠前デバイス１０‐１に対応づけられたｅＫｅｙＧｒｏｕｐを失効させることをオーナー２ａが希望する場合に行われる動作である。

図１７に示したように、まず、オーナー２ａは、例えばユーザ端末２０ａの操作表示部２２２に表示されるｅＫｅｙＧｒｏｕｐ失効登録画面に対して、ｅＫｅｙＧｒｏｕｐＩＤおよび失効登録の入力を行う。そして、ユーザ端末２０ａの送信制御部２０６は、入力されたｅＫｅｙＧｒｏｕｐＩＤを含む、ｅＫｅｙＧｒｏｕｐの失効要求をサーバ３０へ通信部２２０に送信させる（Ｓ１９０１）。

その後、サーバ３０の送信制御部３０４は、Ｓ１９０１で受信された失効要求に含まれるｅＫｅｙＧｒｏｕｐＩＤに対応するｅＫｅｙＧｒｏｕｐの失効をデータベース３２に記録する（Ｓ１９０３）。これにより、該当のｅＫｅｙＧｒｏｕｐＩＤに対応するｅＫｅｙＧｒｏｕｐが失効する。

その後、サーバ３０の送信制御部３０４は、ｅＫｅｙＧｒｏｕｐの失効完了の通知をユーザ端末２０ａへ通信部３２０に送信させる（Ｓ１９０５）。

＜１−４．効果＞
［１−４−１．効果１］
以上、例えば図２、図１５、および図１６等を参照して説明したように、第１の実施形態による錠前デバイス１０‐１は、ユーザ端末２０の秘密鍵に基づいて生成された情報と開錠要求とをユーザ端末２０から受信し、そして、受信されたユーザ端末２０により生成された情報とユーザ端末２０の公開鍵とに基づいて施錠部１３２に開錠させるか否かを判定する。このため、錠前デバイス１０‐１は、秘匿性の高い情報をユーザ端末２０から受信することなく、ユーザ端末２０を認証できるので、認証の安全性が高い。

さらに、ユーザ端末２０は、錠前デバイス１０‐１およびサーバ３０に秘匿性の高い情報を登録する必要がないので、開錠時以外に関しても、秘匿性の高い情報が外部に漏えいすることを防止できる。

また、錠前デバイス１０‐１は、ユーザ端末２０ｂから受信されるｅＫｅｙに含まれる、オーナー２ａのユーザ端末２０ａの署名情報をユーザ端末２０ａの公開鍵を用いて検証することにより、ユーザ端末２０ｂの公開鍵の正当性を検証する。このため、錠前デバイス１０‐１は、認証対象のユーザ端末２０ｂが、開錠権限を有するユーザ２のユーザ端末２０であるか否かを確認することができる。

［１−４−２．効果２］
また、第１の実施形態によれば、オーナー２ａのユーザ端末２０ａは、ゲスト２ｂのｍａｉｌアドレスだけを特定できていれば、ｅｋｅｙＩＤ、すなわちｅＫｅｙ発行の招待状を含むｅ‐ｍａｉｌをゲスト２ｂのユーザ端末２０ｂへ送信することができる。

また、ユーザ端末２０ａが、ｅ‐ｍａｉｌをゲスト２ｂのユーザ端末２０ｂへ送信した後にサーバ３０を介して受信される承認依頼に対して承認した場合にのみ、ｅＫｅｙは、ユーザ端末２０ｂに対して受け渡される。このため、オーナー２ａが、承認したいゲスト２ｂに対してのみｅＫｅｙを発行することが可能になる。

なお、ｅｋｅｙＩＤはあくまでもｅＫｅｙを発行してもらうためのポインタであり、ｅｋｅｙＩＤだけでは錠前デバイス１０‐１に開錠させることができない。このため、仮に、ｅｋｅｙＩＤを含むｅ‐ｍａｉｌが第三者により盗聴されたとしても、錠前デバイス１０‐１の開錠権が奪われることはない。

＜１−５．応用例＞
以上、第１の実施形態について説明した。続いて、第１の実施形態の応用例について、図１８〜図２０を参照して説明する。

［１−５−１．背景］
最初に、本応用例を創作するに至った背景について説明する。上述した第１の実施形態では、ｅＫｅｙを発行可能なユーザ２は、基本的にオーナー２ａだけである。このため、例えば、多数のゲスト２ｂに対してｅＫｅｙを発行することが求められる場面では、全てのユーザ２ｂに対してｅＫｅｙを発行するのに時間がかかる。また、オーナー２ａは、個々のゲスト２ｂからのｅＫｅｙの発行要求に対して承認作業を行う必要があるので、オーナー２ａの作業負荷が大きい。

後述するように、本応用例によれば、オーナー２ａは、他のユーザ２の中からｅＫｅｙの発行権限を有する準オーナー２ｃを登録することが可能である。

［１−５−２．システム構成］
次に、図１８を参照して、本応用例による情報処理システムの構成について説明する。図１８に示したように、本応用例による情報処理システムは、図１に示したシステムと比べて、準オーナー２ｃのユーザ端末２０ｃをさらに有する。ここで、準オーナー２ｃは、条件付きのｅＫｅｙを発行する権限を有するユーザ２である。例えば、準オーナー２ｃは、オーナー２ａよりも低い階層が設定されており、かつ、自己に設定された階層よりも低い階層のユーザ２に対するｅＫｅｙの発行権限を有する。一例として、準オーナー２ｃは、ｅＫｅｙの発行権限を有しないゲスト２ｂに対して、ｅＫｅｙを発行することが可能である。

なお、その他の構成要素に関しては、第１の実施形態と同様である。

［１−５−３．構成］
（１−５−３−１．ユーザ端末２０）
以上、本応用例による情報処理システムの構成について説明した。続いて、本応用例による構成について詳細に説明する。本応用例によるユーザ端末２０の構成は、図４に示した構成と概略同様である。以下では、上述した第１の実施形態と異なる機能を有する構成要素についてのみ説明を行う。

‐暗号生成部２０２
本応用例による暗号生成部２０２は、ユーザ端末２０が、オーナー２ａまたは準オーナー２ｃのユーザ端末２０である場合には、ｅＫｅｙの発行対象のユーザ２ｂのユーザ端末２０ｂの公開鍵に対して電子署名を行う。例えば、上記の場合には、暗号生成部２０２は、対象のユーザ２ｂの公開鍵を、ユーザ端末２０の秘密鍵を用いて暗号化することにより電子署名を行う。

‐鍵情報発行部２０４
‐‐ｅＫｅｙレベルの設定
本応用例による鍵情報発行部２０４は、ｅＫｅｙの発行対象のユーザ２の階層を示すｅＫｅｙレベルをさらに含むｅＫｅｙを発行する。

図１９は、本応用例によるｅＫｅｙの構成例（ｅＫｅｙ４０‐２）を示した説明図である。図１９に示したように、ｅＫｅｙ４０‐２は、図３に示したｅＫｅｙ４０‐１と比べて、ｅＫｅｙレベル４００８をさらに有する。ここで、ｅＫｅｙレベル４００８には、該当のユーザ２に対して設定されたｅＫｅｙレベルの値が記録される。

なお、ｅＫｅｙレベルの値は、ｅＫｅｙの発行者であるユーザ２（以下、ｅＫｅｙ発行ユーザ２と称する場合もある）により設定される。例えば、ｅＫｅｙ発行ユーザ２は、自分のｅＫｅｙレベルよりも低い値をｅＫｅｙレベルに設定する。一例として、ｅＫｅｙ発行ユーザ２は、「自分のｅＫｅｙレベル −１」〜「−１０」の範囲の整数をｅＫｅｙレベルに設定する。ここで、「−１０」は、ｅＫｅｙレベルのデフォルト値であり、ｅＫｅｙの発行権限のないユーザ２に付与される値である。また、オーナー２ａのｅＫｅｙレベルには「０」が設定される。

この設定例によれば、ｅＫｅｙレベルとして「−１」〜「−９」の値が設定されたユーザ２は、自分のｅＫｅｙレベルよりも低い値をｅＫｅｙレベルに設定してｅＫｅｙを発行することが可能である。つまり、当該ユーザ２は、条件付きでｅＫｅｙを発行可能な準オーナー２ｃの権限を有することになる。

（１−５−３−２．錠前デバイス１０‐１、サーバ３０）
本応用例による錠前デバイス１０‐１、およびサーバ３０の構成および機能は、上述した第１の実施形態と概略同様である。

［１−５−４．動作］
以上、本応用例による構成について説明した。続いて、本応用例による動作について、図２０を参照して説明する。なお、図１１に示したＳ１５０１以外の動作については、上述した第１の実施形態と概略同様であるので、説明を省略する。

図２０に示したように、本応用例では、Ｓ１５０１の代わりに、Ｓ２００１〜Ｓ２００３の動作を行う。まず、ユーザ端末２０ａの鍵情報発行部２０４は、ユーザ端末２０ａのｅＫｅｙに含まれるｅＫｅｙレベルが、例えば「−９」など、ｅＫｅｙの発行権限の閾値以上であるか否かを判定する（Ｓ２００１）。ｅＫｅｙレベルが閾値未満である場合には（Ｓ２００１：Ｎｏ）、ユーザ端末２０ａは、ｅＫｅｙの発行権限がないと判定する（Ｓ２００５）。そして、当該「ゲスト２ｂの招待時の動作」は終了する。

一方、ｅＫｅｙレベルが閾値以上である場合には（Ｓ２００１：Ｙｅｓ）、鍵情報発行部２０４は、例えば自端末のｅＫｅｙレベルと対応づけて、ｅＫｅｙＧｒｏｕｐＩＤを生成する（Ｓ２００３）。その後、ユーザ端末２０ａは、図１１に示したＳ１５０３以降の動作を行う。

［１−５−５．効果］
以上、図１８〜図２０を参照して説明したように、本応用例によるユーザ端末２０は、ｅＫｅｙの発行対象のユーザ２の階層を示すｅＫｅｙレベルをさらに含むｅＫｅｙを発行する。そして、ｅＫｅｙレベルには、ｅＫｅｙ発行ユーザ２のｅＫｅｙレベルよりも低い値が設定される。

このため、オーナー２ａ以外のユーザ２であっても、自分に設定されたｅＫｅｙレベルが閾値以上である場合には、自分のｅＫｅｙレベルよりも低い値がｅＫｅｙレベルに設定されたｅＫｅｙを発行することが可能であり、準オーナー２ｃの権限を有することになる。そして、オーナー２ａは、準オーナー２ｃを設定することにより、例えばゲスト２ｂに対するｅＫｅｙの発行などを準オーナー２ｃに委託することができ、オーナー２ａの作業負荷が軽減される。

例えば、本応用例によれば、マンションの所有者（オーナー２ａ）が、例えば不動産管理会社を準オーナー２ｃに設定し、そして、マンションの各部屋の入居者、工事業者、または仲介業者など（ゲスト２ｂ）に対するｅＫｅｙの発行を不動産管理会社に委託することが可能となる。このため、マンションの所有者の作業負荷が大きく軽減される。

［１−５−６．変形例］
なお、上述した応用例では、準オーナー２ｃを設定する方法としてｅＫｅｙレベルを用いる例について説明したが、本開示はかかる例に限定されない。変形例として、準オーナー２ｃの権限の有無の示すフラグをｅＫｅｙ、またはユーザ２の公開鍵に設定する方法を用いてもよい。

＜＜２．第２の実施形態＞＞
＜２−１．背景＞
以上、第１の実施形態について説明した。続いて、第２の実施形態について説明する。

最初に、第２の実施形態を創作するに至った背景について説明する。上述した第１の実施形態では、例えばＲＳＡ認証アルゴリズムなどの、一つだけの認証アルゴリズムを用いて認証を行う。

ところで、例えば将来的に計算機能力が飛躍的に進歩するなどの理由により、錠前デバイス１０‐１に実装されている一つだけの認証アルゴリズムでは、鍵の機密性が維持できなくなる恐れがある。そして、正当な権限を有しない第三者により鍵が解読され、開錠されてしまう恐れがある。

後述するように、第２の実施形態による錠前デバイス１０‐２は、複数の種類の認証アルゴリズムを実装することが可能である。

＜２−２．システム構成＞
第２の実施形態によるシステム構成は、図１または図１８に示した第１の実施形態と同様である。

＜２−３．構成＞
［２−３−１．錠前デバイス１０‐２］
続いて、第２の実施形態による構成について詳細に説明する。図２１は、第２の実施形態による錠前デバイス１０‐２の構成を示した機能ブロック図である。図２１に示したように、錠前デバイス１０‐２は、図２に示した錠前デバイス１０‐１と比較して、制御部１００‐１の代わりに、制御部１００‐２を有する。なお、以下では、第１の実施形態と重複する機能については説明を省略する。

（２−３−１−１．制御部１００‐２）
制御部１００‐２は、第１の実施形態による制御部１００‐１と比べて、アルゴリズム切り替え部１１４をさらに有する。

（２−３−１−２．アルゴリズム切り替え部１１４）
アルゴリズム切り替え部１１４は、第１の認証アルゴリズムから第２の認証アルゴリズムへの移行要求がオーナー２ａのユーザ端末２０ａから受信された場合には、使用する認証アルゴリズムを第１の認証アルゴリズムから第２の認証アルゴリズムに切り替える。より具体的には、アルゴリズム切り替え部１１４は、当該移行要求がユーザ端末２０ａから受信された場合には、まず、第１の認証アルゴリズムの使用を停止し、そして、第２の認証アルゴリズムを使用するように設定を変更する。

あるいは、アルゴリズム切り替え部１１４は、開錠要求時に、例えば第２の認証アルゴリズムに基づいて生成された情報がユーザ端末２０から受信された場合に、使用する認証アルゴリズムを第１の認証アルゴリズムから第２の認証アルゴリズムに切り替えることも可能である。

ここで、第１の認証アルゴリズムは、処理時間は短時間で済むが、仮に計算機能力が大きく向上した場合には鍵の機密性が維持できなくなる恐れがあるアルゴリズムである。例えば、第１の認証アルゴリズムは、ＲＳＡ、ＤＳＡ、またはＥＣＤＳＡなどである。また、第２の認証アルゴリズムは、処理時間は長時間かかるが、仮に計算機能力が大きく向上したとしても鍵の機密性が維持できる可能性が大きいアルゴリズムである。例えば、第２の認証アルゴリズムは、量子コンピュータへの耐性があると考えられているアリゴリズムである。一例として、第２の認証アルゴリズムは、ＭＱ認証方式、格子暗号ベースの認証方式、または、符号を利用した暗号ベースの認証方式などである。なお、第１の認証アルゴリズムから第２の認証アルゴリズムへ移行すべきか否かは、例えば、現在の計算機能力や技術動向などに基づいてオーナー２ａにより判断される。

なお、以下では、第１の認証アルゴリズムがＲＳＡアルゴリズムであり、また、第２の認証アルゴリズムがＭＱアルゴリズムである例を中心として説明を行う。

（２−３−１−３．鍵情報検証部１０２）
第２の実施形態による鍵情報検証部１０２は、アルゴリズム切り替え部１１４によりＲＳＡアルゴリズムの使用が停止された場合には、ユーザ端末２０から受信されるｅＫｅｙの正当性を、ＭＱアルゴリズムに基づいて判定する。

‐ｅＫｅｙ
ここで、第２の実施形態によるｅＫｅｙの構成例（ｅＫｅｙ４０‐３）について、図２２を参照して説明する。図２２に示したように、ｅＫｅｙ４０‐３は、図１９に示した（第１の実施形態の応用例による）ｅＫｅｙ４０‐２と比較して、ＭＱ公開鍵４０２４、および鍵のＨＭＡＣ証明書４０２６をさらに有する。ここで、ＭＱ公開鍵４０２４には、ｅＫｅｙ４０‐３が発行されたユーザ端末２０のＭＱ公開鍵が記録される。また、鍵のＨＭＡＣ証明書４０２６には、ユーザ端末２０のＭＱ公開鍵に対する、オーナー２ａのユーザ端末２０ａのＨＭＡＣ鍵を用いた署名情報が記録される。

（２−３−１−４．検証処理部１０４）
第２の実施形態による検証処理部１０４は、アルゴリズム切り替え部１１４によりＲＳＡアルゴリズムの使用が停止された場合には、ユーザ端末２０から受信される、ユーザ端末２０のＭＱ秘密鍵に基づいて生成された情報をＭＱアルゴリズムにより検証する。

（２−３−１−５．記憶部１３４）
第２の実施形態による記憶部１３４は、ＲＳＡアルゴリズムに基づいた認証ソフトウェア、およびＭＱアルゴリズムに基づいた認証ソフトウェアを記憶する。

なお、錠前デバイス１０‐２に含まれるその他の構成要素については、第１の実施形態と概略同様である。

［２−３−２．ユーザ端末２０］
続いて、第２の実施形態によるユーザ端末２０の構成について説明する。

（２−３−２−１．暗号生成部２０２）
第２の実施形態による暗号生成部２０２は、ＲＳＡアルゴリズムからＭＱアルゴリズムへの移行指示情報がサーバ３０から受信された場合には、受信以後、錠前デバイス１０‐１から受信される乱数およびＭＱ秘密鍵に基づいて情報を生成する。

（２−３−２−２．送信制御部２０６）
第２の実施形態による送信制御部２０６は、例えばユーザ端末２０がオーナー２ａのユーザ端末２０である場合に、操作表示部２２２に対するユーザ２の入力に基づいて、ＲＳＡアルゴリズムからＭＱアルゴリズムへの移行要求をサーバ３０へ通信部２２０に送信させる。

なお、ユーザ端末２０に含まれるその他の構成要素については、第１の実施形態と概略同様である。

［２−３−３．サーバ３０］
続いて、第２の実施形態によるサーバ３０の構成について説明する。

（２−３−３−１．検証処理部３０８）
第２の実施形態による検証処理部３０８は、ＲＳＡアルゴリズムからＭＱアルゴリズムへの移行要求がユーザ端末２０から受信された場合には、受信以後、ユーザ端末２０から受信される、ユーザ端末２０のＭＱ秘密鍵に基づいて生成された情報をＭＱアルゴリズムにより検証する。

（２−３−３−４．送信制御部３０４）
第２の実施形態による送信制御部３０４は、ＲＳＡアルゴリズムからＭＱアルゴリズムへの移行要求がユーザ端末２０ａから受信された場合には、ＲＳＡアルゴリズムからＭＱアルゴリズムへの移行指示情報を他のユーザ端末２０ｂへ通信部３２０に送信させる。

（２−３−３−５．記憶部３２２）
第２の実施形態による記憶部３２２は、ＲＳＡアルゴリズムに基づいた認証ソフトウェア、およびＭＱアルゴリズムに基づいた認証ソフトウェアを記憶する。

なお、サーバ３０に含まれるその他の構成要素については、第１の実施形態と概略同様である。

＜２−４．動作＞
以上、第２の実施形態による構成について説明した。続いて、第２の実施形態による動作について、図２３〜図３０を参照し、以下の流れで説明を行う。なお、その他の種類の動作については第１の実施形態と同様であるので、説明を省略する。
１．錠前デバイス１０‐２への鍵の登録時の動作
２．ＭＱレスポンスデータ検証処理の動作
３．オーナー２ａの鍵の検証時の動作
４．アルゴリズムの移行要求時の動作
５．サーバ３０によるアカウント認証時の動作

なお、図２３〜図３０では、特に明記しない限り、ユーザ端末２０ａがオーナー２ａのユーザ端末２０であり、また、ユーザ端末２０ｂがゲスト２ｂのユーザ端末２０である例を示している。

［２−４−１．錠前デバイス１０‐２への鍵の登録時の動作］
図２３は、第２の実施形態による、錠前デバイス１０‐２への鍵の登録時の動作の一部を示したシーケンス図である。なお、この動作は、（図６に示した）第１の実施形態による動作の代わりの動作である。また、ここでは、オーナー２ａのユーザ端末２０ａのｄｅｖｉｃｅＩＤや２種類の公開鍵（すなわちＲＳＡ公開鍵およびＭＱ公開鍵）などの情報を、オーナー２ａが管理する錠前デバイス１０‐２に対して初期登録する際の動作例について説明する。また、この動作は、基本的には、各錠前デバイス１０‐２に関して当該錠前デバイス１０‐２を管理するオーナー２ａにより一回だけ実施される。

なお、図２３に示したＳ３００１〜Ｓ３００３の動作は、図６に示したＳ１００１〜Ｓ１００３と同様である。

Ｓ３００３の後、ユーザ端末２０ａの暗号生成部２０２は、ＭＱアルゴリズムに基づいてコミットメントを生成する（Ｓ３００５）。

続いて、送信制御部２０６は、ユーザ端末２０ａのｄｅｖｉｃｅＩＤ、Ｓ３００５で生成されたコミットメント、ユーザ端末２０ａのＨＭＡＣ鍵、ユーザ端末２０ａのＭＱ公開鍵、およびユーザ端末２０ａのＲＳＡ公開鍵を錠前デバイス１０‐２へ通信部２２０に送信させる（Ｓ３００７）。

なお、図２３に示したＳ３００９〜Ｓ３０１７の動作は、図６に示したＳ１００７〜Ｓ１０１５と概略同様である。

Ｓ３０１７の後、錠前デバイス１０‐２の判定部１０６は、Ｓ３０１７で復号化された情報とＳ３０１１で生成された乱数とを比較する（Ｓ３０１９）。両者が一致しない場合には（Ｓ３０１９：Ｎｏ）、判定部１０６は、後述するＳ３０４５の動作を行う。

ここで、Ｓ３０１９において両者が一致する場合（Ｓ３０１９：Ｙｅｓ）の動作について、図２４を参照して説明する。

図２４に示したように、まず、ユーザ端末２０ａの暗号生成部２０２は、Ｓ３０１１で受信された乱数、およびユーザ端末２０ａのＭＱ秘密鍵に基づいて、例えばＮ個のＭＱレスポンスデータ［ｉ］（ｉ＝１〜Ｎ）を生成する（Ｓ３０３１）。なお、ここでは、例えばＭＱレスポンスデータのデータサイズが大きいなどの理由により、暗号生成部２０２が、Ｎ個に分割してデータを生成する例を説明する。但し、かかる例に限定されず、暗号生成部２０２は、ＭＱレスポンスデータを１個だけ生成してもよい。

続いて、送信制御部２０６は、Ｓ３０３１で生成されたＮ個のＭＱレスポンスデータ［ｉ］（ｉ＝１〜Ｎ）を錠前デバイス１０‐２へ通信部２２０に送信させる（Ｓ３０３３〜Ｓ３０３９）。

その後、錠前デバイス１０‐２は、後述する「ＭＱレスポンスデータ検証処理」を行う（Ｓ３０４１）。

その後、ＭＱレスポンスデータが正当ではないと検証された場合には（Ｓ３０４３：Ｎｏ）、判定部１０６は、Ｒｅｓｕｌｔ（＝登録結果）に「ＮＧ」を設定する（Ｓ３０４５）。その後、錠前デバイス１０‐２は、後述するＳ３０５１の動作を行う。

一方、ＭＱレスポンスデータが正当であると検証された場合には（Ｓ３０４３：Ｙｅｓ）、判定部１０６は、Ｒｅｓｕｌｔに「ＯＫ」を設定する（Ｓ３０４７）。そして、判定部１０６は、Ｓ３００７で受信されたｄｅｖｉｃｅＩＤ、ＨＭＡＣ鍵、ＭＱ公開鍵、およびＲＳＡ公開鍵を対応づけて登録鍵ＤＢ１３６に記録する（Ｓ３０４９）。

その後、送信制御部１１２は、Ｓ３０４５またはＳ３０４７で設定されたＲｅｓｕｌｔをユーザ端末２０ａへ通信部１３０に送信させる（Ｓ３０５１）。

［２−４−２．ＭＱレスポンスデータ検証処理の動作］
次に、図２５を参照して、Ｓ３０４１における「ＭＱレスポンスデータ検証処理の動作」について詳細に説明する。

図２５に示したように、まず、錠前デバイス１０‐２の検証処理部１０４は、図２３に示したＳ３００７で受信されたＭＱ公開鍵、コミットメント、および図２３に示したＳ３０１１で生成された乱数に基づいて、ＭＱアルゴリズムによりＳｔａｔｅ［０］を算出する（Ｓ３１０１）。

その後、検証処理部１０４は、ｉ＝１〜Ｎまで、算出されたＳｔａｔｅ［ｉ−１］と、Ｓ３０３５で受信されたＭＱレスポンスデータ［ｉ］とに基づいて、ＭＱアルゴリズムによりＳｔａｔｅ［ｉ］を算出することを繰り返す（Ｓ３１０３〜Ｓ３１０９）。

その後、判定部１０６は、算出されたＳｔａｔｅ［Ｎ］が正当な値であるか否かを検証する（Ｓ３１１１）。Ｓｔａｔｅ［Ｎ］が正当な値ではない場合には（Ｓ３１１１：Ｎｏ）、判定部１０６は、ユーザ端末２０ａから受信されたＭＱレスポンスデータは正当ではないと判定する（Ｓ３１１３）。

一方、Ｓｔａｔｅ［Ｎ］が正当な値である場合には（Ｓ３１１１：Ｙｅｓ）、判定部１０６は、受信されたＭＱレスポンスデータは正当であると判定する（Ｓ３１１５）。

［２−４−３．オーナー２ａの鍵の検証時の動作］
次に、第２の実施形態による、オーナー２ａの鍵の検証時の動作について説明する。なお、この動作は、（図７に示した）第１の実施形態による動作の代わりの動作である。また、この動作は、ＲＳＡアルゴリズムを用いた検証動作、およびＭＱアルゴリズムを用いた検証動作の２種類の動作を含み、例えばこの２種類の動作が連続して実行される。このうち、ＲＳＡアルゴリズムを用いた検証動作は、第１の実施形態による動作と同様であるので、説明を省略する。以下では、ＭＱアルゴリズムを用いた検証動作について、図２６を参照して説明する。

なお、図２６に示したＳ３２０１〜Ｓ３２０３の動作は、図７に示したＳ１１０１〜Ｓ１１０３と同様である。また、Ｓ３２０５の動作は、図２３に示したＳ３００５と同様である。

Ｓ３２０５の後、ユーザ端末２０ａの送信制御部２０６は、ユーザ端末２０ａのｄｅｖｉｃｅＩＤ、Ｓ３２０５で生成されたコミットメント、およびユーザ端末２０ａのＭＱ公開鍵を錠前デバイス１０‐２へ通信部２２０に送信させる（Ｓ３２０７）。

なお、Ｓ３２０９〜Ｓ３２１１の動作は、図７に示したＳ１１０７〜Ｓ１１０９と同様である。また、Ｓ３２１３〜Ｓ３２２３の動作は、図２４に示したＳ３０３１〜Ｓ３０４１と同様である。

Ｓ３２２３の後、ＭＱレスポンスデータが正当ではないと検証された場合には（Ｓ３２２５：Ｎｏ）、錠前デバイス１０‐２の判定部１０６は、Ｒｅｓｕｌｔ（＝検証結果）に「ＮＧ」を設定する（Ｓ３２２７）。その後、錠前デバイス１０‐２は、後述するＳ３２３１の動作を行う。

一方、ＭＱレスポンスデータが正当であると検証された場合には（Ｓ３２２５：Ｙｅｓ）、判定部１０６は、Ｒｅｓｕｌｔに「ＯＫ」を設定する（Ｓ３２２９）。

その後、送信制御部１１２は、Ｓ３２２７またはＳ３２２９で設定されたＲｅｓｕｌｔをユーザ端末２０ａへ通信部１３０に送信させる（Ｓ３２３１）。

［２−４−４．アルゴリズムの移行要求時の動作］
次に、図２７を参照して、第２の実施形態によるアルゴリズムの移行要求時の動作について説明する。なお、この動作は、例えば、錠前デバイス１０‐２が使用する認証アルゴリズムをＲＳＡアルゴリズムからＭＱアルゴリズムへ移行することをオーナー２ａが希望する場合に実施される動作である。

図２７に示したように、まず、ユーザ端末２０ａは、鍵認証サービスにログインする。そして、ユーザ端末２０ａの送信制御部２０６は、例えば操作表示部２２２に対するユーザの入力に基づいて、ＭＱアルゴリズムへの移行要求をサーバ３０へ通信部２２０に送信させる（Ｓ３３０１）。

その後、サーバ３０の制御部３００は、記憶部３２２（またはデータベース３２）に記録されている、使用する認証アルゴリズムの設定をＲＳＡアルゴリズムからＭＱアルゴリズムへ変更し、記録内容を更新する（Ｓ３３０３）。ここで、制御部３００は、登録済みの全てのｅＫｅｙＧｒｏｕｐに関して使用する認証アルゴリズムをＲＳＡアルゴリズムからＭＱアルゴリズムへ変更してもよい。あるいは、制御部３００は、Ｓ３３０１で受信される移行要求において指定されるｅＫｅｙＧｒｏｕｐに関してのみ、使用する認証アルゴリズムをＲＳＡアルゴリズムからＭＱアルゴリズムへ変更してもよい。

続いて、送信制御部３０４は、認証アルゴリズムの移行完了の通知をユーザ端末２０ａへ通信部３２０に送信させる（Ｓ３３０５）。

その後、ユーザ端末２０ａの制御部２００は、記憶部２２４に記録されている、使用する認証アルゴリズムの設定をＲＳＡアルゴリズムからＭＱアルゴリズムへ変更し、記憶部２２４の記録内容を更新する（Ｓ３３０７）。

また、サーバ３０の送信制御部３０４は、ＲＳＡアルゴリズムからＭＱアルゴリズムへの移行指示情報を他のユーザ端末２０ｂへ通信部３２０に送信させる（Ｓ３３０９）。

その後、ユーザ端末２０ｂの制御部２００は、Ｓ３３０７と同様に、使用する認証アルゴリズムの設定をＲＳＡアルゴリズムからＭＱアルゴリズムへ変更し、記憶部２２４の記録内容を更新する（Ｓ３３１１）。

［２−４−５．サーバ３０によるアカウント認証時の動作］
次に、第２の実施形態による、サーバ３０によるアカウント認証時の動作について説明する。なお、この動作は、（図１０に示した）第１の実施形態による動作の代わりの動作である。また、この動作は、ＲＳＡアルゴリズムを用いた認証動作、およびＭＱアルゴリズムを用いた認証動作の２種類の動作を含む。例えば、サーバ３０は、２−４−４節で述べた、アルゴリズムの移行要求がユーザ端末２０ａから受信される前はＲＳＡアルゴリズムを用いた認証動作を行い、また、アルゴリズムの移行要求が受信された後はＭＱアルゴリズムを用いた認証動作を行う。なお、ＲＳＡアルゴリズムを用いた認証動作は、第１の実施形態による認証動作と同様であるので、説明を省略する。以下では、ＭＱアルゴリズムを用いた認証動作について、図２８を参照して説明する。

図２８に示したように、まず、ユーザ端末２０の暗号生成部２０２は、ＭＱアルゴリズムに基づいてコミットメントを生成する（Ｓ３４０１）。

続いて、送信制御部２０６は、ユーザ端末２０のｄｅｖｉｃｅＩＤ、およびＳ３４０１で生成されたコミットメントを含む、チャレンジ取得要求をサーバ３０へ通信部２２０に送信させる（Ｓ３４０３）。

なお、Ｓ３４０５〜Ｓ３４０７の動作は、図１０に示したＳ１４０３〜Ｓ１４０５と同様である。

その後、ユーザ端末２０の暗号生成部２０２は、Ｓ３４０７で受信されたチャレンジ、およびユーザ端末２０のＭＱ秘密鍵に基づいて、例えばＮ個のＭＱレスポンスデータ［ｉ］（ｉ＝１〜Ｎ）を生成する（Ｓ３４０９）。

続いて、送信制御部２０６は、Ｓ３４０９で生成されたＮ個のＭＱレスポンスデータ［ｉ］（ｉ＝１〜Ｎ）をサーバ３０へ通信部２２０に送信させる（Ｓ３４０９〜Ｓ３４１７）。

その後、サーバ３０の送信制御部３０４は、ユーザ端末２０のＭＱ公開鍵の取得要求をデータベース３２へ通信部３２０に送信させる（Ｓ３４１９）。

その後、データベース３２は、Ｓ３４１９で受信された取得要求に含まれるｄｅｖｉｃｅＩＤに対応するＭＱ公開鍵を抽出し、そして、抽出したＭＱ公開鍵をサーバ３０へ送信する（Ｓ３４２１）。

その後、サーバ３０は、「ＭＱレスポンスデータ検証処理」を行う（Ｓ３４２３）。なお、この「ＭＱレスポンスデータ検証処理」は、図２５に示した動作と比べて、動作主体が錠前デバイス１０‐２の代わりにサーバ３０である点が相違するが、その他の内容については概略同様である。

Ｓ３４２３において、ＭＱレスポンスデータが正当ではないと検証された場合には（Ｓ３４２５：Ｎｏ）、サーバ３０の制御部３００は、Ｒｅｓｕｌｔ（＝認証結果）に「ＮＧ」を設定し、そして、ユーザ端末２０を認証しない（Ｓ３４２７）。その後、サーバ３０は、後述するＳ３４３１の動作を行う。

一方、ＭＱレスポンスデータが正当であると検証された場合には（Ｓ３４２５：Ｙｅｓ）、制御部３００は、Ｒｅｓｕｌｔに「ＯＫ」を設定し、そして、ユーザ端末２０を認証する（Ｓ３４２９）。

その後、送信制御部３０４は、Ｓ３４２７またはＳ３４２９で設定されたＲｅｓｕｌｔをユーザ端末２０へ通信部１３０に送信させる（Ｓ３４３１）。

［２−４−６．開錠処理の動作］
次に、第２の実施形態による「開錠処理の動作」について説明する。なお、この動作は、（図１５および図１６に示した）第１の実施形態による動作の代わりの動作である。また、この動作は、ＲＳＡアルゴリズムを用いた開錠処理、およびＭＱアルゴリズムを用いた開錠処理の２種類の動作を含む。例えば、錠前デバイス１０‐２が認証アルゴリズムとしてＲＳＡアルゴリズムを使用している場合にはＲＳＡアルゴリズムを用いた開錠処理が実行され、また、錠前デバイス１０‐２が認証アルゴリズムとしてＭＱアルゴリズムを使用している場合にはＭＱアルゴリズムを用いた開錠処理が実行される。このうち、ＲＳＡアルゴリズムを用いた開錠処理は、第１の実施形態による動作と同様であるので、説明を省略する。以下では、ＭＱアルゴリズムを用いた開錠処理について、図２９〜図３０を参照して説明する。

なお、図２９に示したＳ３５０１〜Ｓ３５０３の動作は、図１５に示したＳ１８０１〜Ｓ１８０３の動作と同様である。また、Ｓ３５０５の動作は、図２６に示したＳ３２０５と概略同様である。また、Ｓ３５０７〜Ｓ３５１１の動作は、図１５に示したＳ１８０５〜Ｓ１８０９と同様である。

Ｓ３５１１において、Ｓ３５０７で受信されたｅＫｅｙが有効期間内であることが確認された場合には（Ｓ３５１１：Ｙｅｓ）、錠前デバイス１０‐２の検証処理部１０４は、ｅＫｅｙに含まれる、ユーザ２のＭＱ公開鍵のＨＭＡＣ証明書を、登録鍵ＤＢ１３６に記録されている、オーナー２ａのユーザ端末２０ａのＨＭＡＣ鍵を用いて復号化する（Ｓ３５１３）。

そして、判定部１０６は、Ｓ３５１３で復号化された証明書に基づいて、ユーザ２のＭＱ公開鍵が正当であるか否かを判定する（Ｓ３５１５）。ユーザ２のＭＱ公開鍵が正当でないと判定された場合には（Ｓ３５１５：Ｎｏ）、錠前デバイス１０‐２は、後述するＳ３５３５の動作を行う。

ここで、Ｓ３５１５においてユーザ２のＭＱ公開鍵が正当であると判定された場合（Ｓ３５１５：Ｙｅｓ）の動作について、図３０を参照して説明する。

なお、図３０に示したＳ３５２１〜Ｓ３５３１の動作は、図２４に示したＳ３０３１〜Ｓ３０４１と概略同様である。

Ｓ３５３１の後、ＭＱレスポンスデータが正当ではないと検証された場合には（Ｓ３５３３：Ｎｏ）、錠前デバイス１０‐２の判定部１０６は、開錠しないことを決定する（Ｓ３５３５）。その後、錠前デバイス１０‐１は、後述するＳ３５３９の動作を行う。

一方、ＭＱレスポンスデータが正当であると検証された場合には（Ｓ３５３３：Ｙｅｓ）、判定部１０６は、開錠することを決定する。そして、施錠制御部１０８は、施錠部１３２に開錠させる（Ｓ３５３７）。

その後、送信制御部１１２は、Ｓ３５３５またはＳ３５３７の実行結果をユーザ端末２０へ通信部１３０に送信させる（Ｓ３５３９）。

＜２−５．効果＞
［２−５−１．効果１］
以上、図２１〜図３０を参照して説明したように、第２の実施形態による錠前デバイス１０‐２およびサーバ３０は、ＲＳＡアルゴリズムおよびＭＱアルゴリズムなどの２種類の認証アルゴリズムを実装しており、初期状態では、ＲＳＡアルゴリズムを認証アルゴリズムとして使用する。現状ではＲＳＡアルゴリズムにより鍵の機密性が十分保証できるので、安全に認証を行うことができる。また、例えばＭＱアルゴリズムと比べて、より短時間で認証処理を行うことが可能である。

［２−５−２．効果２］
また、錠前デバイス１０‐２およびサーバ３０は、認証アルゴリズムの移行要求がオーナー２ａのユーザ端末２０ａから受信された場合には、使用する認証アルゴリズムをＲＳＡアルゴリズムからＭＱアルゴリズムに切り替える。

このため、仮に将来的に計算機能力が飛躍的に進歩するなどの理由により、ＲＳＡアルゴリズムでは鍵の機密性が維持できなくなったとしても、錠前デバイス１０‐２は、ＭＱアルゴリズムを用いてユーザ端末２０を認証することにより、正当な権限を有しない第三者により開錠されることを防止することができる。つまり、第２の実施形態によれば、鍵の寿命を第１の実施形態よりも長くする効果が得られる。

＜＜３．第３の実施形態＞＞
＜３−１．背景＞
以上、第２の実施形態について説明した。続いて、第３の実施形態について説明する。最初に、第３の実施形態を創作するに至った背景について説明する。

上述したようにｅＫｅｙには有効期間が設定されるが、ｅＫｅｙを正しく運用するためには、錠前デバイス１０‐１内で管理されている日時情報が正確である必要がある。しかしながら、錠前デバイス１０‐１の制約により、錠前デバイス１０‐１の使用が経過するにつれて、この日時情報がずれてしまう恐れがある。そこで、錠前デバイス１０‐１の日時情報を時々補正する必要が生じる。

ところで、仮に（開錠権を有する）全てのユーザ端末２０が当該日時情報を補正可能に設定されているとすると、悪意のあるユーザ２により不正な日時に設定される恐れがある。例えば、悪意のあるユーザ２が有効期間の切れたｅＫｅｙの使用を継続するために、当該日時情報を不正な日時に補正する恐れがある。

後述するように、第３の実施形態による錠前デバイス１０‐３は、日時情報を変更する権限を有するユーザ２を限定することが可能である。

＜３−２．システム構成＞
第３の実施形態によるシステム構成は、図１または図１８に示した第１の実施形態と同様である。

＜３−３．構成＞
［３−３−１．錠前デバイス１０‐３］
続いて、第３の実施形態による構成について詳細に説明する。図３１は、第３の実施形態による錠前デバイス１０‐３の構成を示した機能ブロック図である。図３１に示したように、錠前デバイス１０‐３は、図２に示した錠前デバイス１０‐１と比較して、制御部１００‐１の代わりに、制御部１００‐３を有する。

（３−３−１−１．制御部１００‐３）
制御部１００‐３は、第１の実施形態による制御部１００‐１と比べて、日時情報変更部１１６をさらに有する。

（３−３−１−２．日時情報変更部１１６）
日時情報変更部１１６は、ユーザ端末２０から受信されるｅＫｅｙに含まれる時刻同期可否フラグに基づいて、ユーザ端末２０による錠前デバイス１０‐３の日時情報の変更の可否を判断する。例えば、日時情報変更部１１６は、受信されたｅＫｅｙに含まれる時刻同期可否フラグが「ＯＫ」を示す場合には、ユーザ端末２０による錠前デバイス１０‐３の日時情報の変更を許可する。また、日時情報変更部１１６は、この時刻同期可否フラグが「ＮＧ」を示す場合には、ユーザ端末２０による錠前デバイス１０‐３の日時情報の変更を許可しない。なお、時刻同期可否フラグの値は、例えばｅＫｅｙの発行時に、ｅＫｅｙの発行ユーザ２（オーナー２ａまたは準オーナー２ｃ）により設定されてもよい。または、時刻同期可否フラグの値は、オーナー２ａだけが「ＯＫ」であり、他のユーザ２ｂは「ＮＧ」であるなど、一律に定められていてもよい。

‐ｅＫｅｙ
ここで、第３の実施形態によるｅＫｅｙの構成例（ｅＫｅｙ４０‐４）について、図３２を参照して説明する。図３２に示したように、ｅＫｅｙ４０‐４は、図２２に示した（第２の実施形態による）ｅＫｅｙ４０‐３と比較して、時刻同期可否フラグ４０１０をさらに有する。ここで、時刻同期可否フラグ４０１０には、ｅＫｅｙ４０‐３が発行されたユーザ端末２０に対して設定された時刻同期可否フラグの値が記録される。

なお、錠前デバイス１０‐３に含まれるその他の構成要素については、第１の実施形態と概略同様である。また、ユーザ端末２０およびサーバ３０の構成については、第１の実施形態と概略同様である。

＜３−４．動作＞
以上、第３の実施形態による構成について説明した。続いて、第３の実施形態による動作について説明する。ここでは、第３の実施形態による「開錠処理の動作」について説明する。この動作は、（図１５および図１６に示した）第１の実施形態による動作の代わりの動作である。なお、その他の種類の動作については、図６〜図１４、および図１７に示した第１の実施形態と同様であるので、説明を省略する。

［３−４−１．開錠処理の動作］
図３３は、第３の実施形態による「開錠処理の動作」の一部を示したシーケンス図である。なお、図１５〜図１６に示したＳ１８０１〜Ｓ１８２９までの動作については第１の実施形態と同様であるので、図３３では記載を一部省略している。以下では、Ｓ１８２９より後の動作についてのみ説明を行う。

Ｓ１８２９において、図１６に示したＳ１８２７で復号化された情報と図１６に示したＳ１８２１で生成された乱数とが一致する場合には（Ｓ１８２９：Ｙｅｓ）、錠前デバイス１０‐３の判定部１０６は、開錠することを決定する。そして、施錠制御部１０８は、施錠部１３２に開錠させる（Ｓ１８３３）。

続いて、日時情報変更部１１６は、図１５に示したＳ１８０５で受信されたｅＫｅｙに含まれる時刻同期可否フラグの値が「ＯＫ」であるか否かを判定する（Ｓ４００１）。時刻同期可否フラグの値が「ＯＫ」ではない場合には（Ｓ４００１：Ｎｏ）、錠前デバイス１０‐３は、後述するＳ４００５の動作を行う。

一方、時刻同期可否フラグの値が「ＯＫ」である場合には（Ｓ４００１：Ｙｅｓ）、日時情報変更部１１６は、錠前デバイス１０‐３の日時情報を、ユーザ端末２０により管理されている日時情報と同期させる（Ｓ４００５）。これにより、錠前デバイス１０‐３の日時情報が、ユーザ端末２０の日時情報と同一になるように補正される。

その後、送信制御部１１２は、Ｓ１８３１またはＳ１８３３の実行結果をユーザ端末２０へ通信部１３０に送信させる（Ｓ４００５）。

＜３−５．効果＞
以上、図３１〜図３３を参照して説明したように、第３の実施形態による錠前デバイス１０‐３は、ユーザ端末２０から受信されるｅＫｅｙに含まれる時刻同期可否フラグに基づいて錠前デバイス１０‐３の日時情報の変更の可否を判断し、そして、時刻同期可否フラグが「ＯＫ」を示す場合にはユーザ端末２０による錠前デバイス１０‐３の日時情報の変更を許可する。

このため、錠前デバイス１０‐３の日時情報が、時刻補正の権限を与えられていないユーザ２のユーザ端末２０により変更されることを防止することができる。例えば、悪意のあるユーザ２により当該日時情報を不正な日時に変更されるリスクを減少させることができる。

＜＜４．第４の実施形態＞＞
＜４−１．背景＞
以上、第３の実施形態について説明した。続いて、第４の実施形態について説明する。最初に、第４の実施形態を創作するに至った背景について説明する。

［４−１−１．背景１］
一般的に、開錠権を有するユーザ２にとって、負荷が少なくドアを開錠可能であることが望ましい。公知の技術では、第１の方法として、ユーザ２が、携帯する端末に実装されている所定のアプリケーションを起動し、そして、当該アプリケーションにおいて開錠操作を行う技術が提案されている。しかしながら、この方法では、ドアを開錠しようとする度にアプリケーションを起動しなければならず、ユーザ２の作業負荷が大きい。

また、第２の方法として、開錠権を有するユーザ２がドアに近づいたことを検知した場合に、自動的に開錠する方法も提案されている。しかしながら、この方法では、ユーザ２が実際にはドアから少し離れた位置にいる場合であっても開錠されてしまう恐れがある。その結果、悪意のある人物により室内に侵入される恐れがある。

［４−１−２．背景２］
また、別の課題として以下が挙げられる。もし同一の錠前デバイス１０‐１に対する開錠権を有するユーザ端末２０が複数存在する場合には、複数のユーザ端末２０が錠前デバイス１０‐１に接近し、そして、ほぼ同じ時間帯に開錠を要求する場面が生じることも想定される。このような場合、仮に特定のユーザ端末２０ａが錠前デバイス１０‐１と何らかの通信をしている間は、他のユーザ端末２０ｂは錠前デバイス１０‐１と通信ができず、一定時間開錠できない事象が生じる恐れがある。特に、錠前デバイス１０‐１とユーザ端末２０との間で、開錠処理のためのセキュアな通信を行う場合には通信量が多くなるので、上記の問題が起こりやすい。

その結果、他のユーザ端末２０ｂのユーザ２は、開錠されるまで一定時間待たされることになり、ストレスを感じる恐れがある。

後述するように、第４の実施形態による錠前デバイス１０‐４は、開錠権を有するユーザ２がアプリケーションを操作することなく、かつ、セキュアに開錠することが可能である。また、開錠操作時において、ユーザ２がドアの前で待たされる時間が短縮される。

＜４−２．システム構成＞
まず、図３４を参照して、第４の実施形態によるシステム構成について説明する。図３４に示したように、第４の実施形態による情報処理システムは、図１に示した第１の実施形態と比べて、ウェアラブルデバイス５０をさらに有する。

［４−２−１．ウェアラブルデバイス５０］
ウェアラブルデバイス５０は、ユーザ２が身体に装着可能な例えば腕時計型の装置である。このウェアラブルデバイス５０は、例えば加速度センサーを有し、ウェアラブルデバイス５０の加速度を測定することが可能である。

また、ウェアラブルデバイス５０は、タッチパネルを有した表示部を備え、表示画面を表示することが可能である。

なお、その他の構成要素に関しては、第１の実施形態と概略同様である。

＜４−３．構成＞
［４−３−１．錠前デバイス１０‐４］
以上、第４の実施形態による情報処理システムの構成について説明した。続いて、第４の実施形態による構成について詳細に説明する。図３５は、第４の実施形態による錠前デバイス１０‐４の構成を示した機能ブロック図である。図３５に示したように、第４の実施形態による錠前デバイス１０‐４は、図２に示した錠前デバイス１０‐１と比較して、制御部１００‐１の代わりに、制御部１００‐４を有する。また、錠前デバイス１０‐４は、測定部１３８をさらに有する。

（４−３−１−１．制御部１００‐４）
制御部１００‐４は、第１の実施形態による制御部１００‐１と比べて、接近検知部１１８、および検出部１２０をさらに有する。

（４−３−１−２．接近検知部１１８）
接近検知部１１８は、錠前デバイス１０‐４に対するユーザ端末２０の接近を検知する。例えば、接近検知部１１８は、ユーザ端末２０から受信されるＢｌｕｅｔｏｏｔｈなどの所定の規格の電波の強度に基づいて、ユーザ端末２０の接近を検知する。より具体的には、接近検知部１１８は、受信される電波の強度が徐々に強くなることが検知された場合には、ユーザ端末２０が錠前デバイス１０‐４に接近していると判定する。また、接近検知部１１８は、受信される電波の強度が徐々に弱くなることが検知された場合には、ユーザ端末２０が錠前デバイス１０‐４から離れていると判定する。

または、接近検知部１１８は、例えばユーザ端末２０から受信されるユーザ端末２０の位置情報に基づいて、ユーザ端末２０が錠前デバイス１０‐４に接近しているか否かを検知することも可能である。例えば、所定の時間間隔で、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）などの測位衛星から受信される測位信号から特定されるユーザ端末２０の位置情報をユーザ端末２０から受信することにより、接近検知部１１８は、ユーザ端末２０が錠前デバイス１０‐４に接近しているか否かを検知してもよい。または、例えば屋内に設置された発信機により発信される当該発信機の位置情報をユーザ端末２０から受信することにより、接近検知部１１８は、ユーザ端末２０が錠前デバイス１０‐４に接近しているか否かを検知してもよい。

（４−３−１−２．検出部１２０）
検出部１２０は、後述する測定部１３８により測定される振動または周囲の音の検出結果が所定の条件を満たす場合に、ユーザ端末２０のユーザ２による開錠要求を検出する。例えば、検出部１２０は、測定部１３８による振動の測定結果に基づいて、ユーザ２によりドアがノックされたことが検知された場合に、開錠要求を検出する。または、検出部１２０は、ユーザ２が装着するウェアラブルデバイス５０から所定の情報が受信された場合に、開錠要求を検出する。

なお、ウェアラブルデバイス５０は、例えばユーザ２により上下方向に反復して振られるなど所定の動作状態が検出された場合に、上記の所定の情報を錠前デバイス１０‐４へ送信してもよい。または、ウェアラブルデバイス５０は、表示画面に対してユーザによりタップされた場合に、上記の所定の情報を錠前デバイス１０‐４へ送信してもよい。

また、変形例として、検出部１２０は、ウェアラブルデバイス５０から受信される、ウェアラブルデバイス５０により検知された振動のタイミングと、測定部１３８により測定された振動のタイミングとが一致する場合に、開錠要求を検出することも可能である。また、検出部１２０は、測定部１３８による振動の測定結果に基づいて、予め定められたノックの回数だけユーザ２によりドアがノックされたことが検知された場合に、開錠要求を検出することも可能である。これらの変形例によれば、開錠要求をより適切に検出することができるので、セキュリティを向上させることが可能となる。

（４−３−１−３．施錠制御部１０８）
‐制御例１‐
第４の実施形態による施錠制御部１０８は、例えば錠前デバイス１０‐４から所定の範囲内にユーザ端末２０が接近したことが接近検知部１１８により検知された場合に、開錠させるための処理のうち前処理を行う。ここで、前処理は、開錠させるための処理のうち多くの時間を要する処理である。例えば、前処理は、図１５〜図１６に示した開錠処理の動作のうちの開錠以外の処理である。一例として、前処理は、Ｓ１８０１〜Ｓ１８２１までの処理であってもよい。

また、施錠制御部１０８は、ユーザ端末２０ａの前処理を行っている間に、別のユーザ端末２０ｂの接近が接近検知部１１８によりさらに検知された場合には、ユーザ端末２０ａの前処理の終了後に、別のユーザ端末２０ｂに対応する前処理を行う。

‐制御例２‐
また、施錠制御部１０８は、前処理が終了し、かつ、検出部１２０により開錠要求が検出された場合には、開錠させるための処理のうち開錠制御処理を行う。例えば、ユーザ端末２０ａの前処理が終了しており、施錠制御部１０８が別のユーザ端末２０ｂに対応する前処理を行っている間に、ユーザ端末２０ａによる開錠要求が検出部１２０により検出された場合には、まず、施錠制御部１０８は、別のユーザ端末２０ｂに対応する前処理を一時中断する。そして、施錠制御部１０８は、ユーザ端末２０ａに対応する開錠制御処理を行う。

ここで、図３６を参照して、上記の機能についてより詳細に説明する。図３６は、錠前デバイス１０‐４に接近したユーザ端末２０ａ〜ユーザ端末２０ｃに関する、施錠制御部１０８による処理の流れを示した説明図である。図３６に示したように、まず、ユーザ端末２０ａが錠前デバイス１０‐４に接近したことが時刻「ｔ１」に接近検知部１１８により検知されたと仮定する。この場合、施錠制御部１０８は、時刻「ｔ１」にユーザ端末２０ａの前処理を開始する。なお、図３６に示したように、前処理は、例えば時刻「ｔ１」〜「ｔ４」までのように、一定の時間を要する処理である。

そして、施錠制御部１０８がユーザ端末２０ａの前処理を行っている間に、時刻「ｔ２」において、ユーザ端末２０ｂが錠前デバイス１０‐４に接近したことが接近検知部１１８により検知されたと仮定する。この場合、施錠制御部１０８は、ユーザ端末２０ｂから受信される例えばｄｅｖｉｃｅＩＤなどの識別情報をキューに入れ、そして、ユーザ端末２０ｂを待機させる。

さらに、ユーザ端末２０ａの前処理を継続している間に、時刻「ｔ３」においてユーザ端末２０ｃが錠前デバイス１０‐４に接近したことが接近検知部１１８により検知されたと仮定する。この場合、施錠制御部１０８は、同様に、ユーザ端末２０ｃの識別情報をキューに入れ、そして、ユーザ端末２０ｃを待機させる。

その後、時刻「ｔ４」においてユーザ端末２０ａの前処理が終了したと仮定する。この場合、施錠制御部１０８は、キューの先頭の識別番号を取り出し、そして、取り出した識別番号に対応するユーザ端末２０（すなわちユーザ端末２０ｂ）の前処理を開始する。

その後、施錠制御部１０８がユーザ端末２０ｂの前処理を行っている間に、時刻「ｔ５」において、ユーザ端末２０ａからの開錠要求が検出部１２０により検出されたと仮定する。この場合、施錠制御部１０８は、ユーザ端末２０ｂの前処理を一時中断し、そして、ユーザ端末２０ａの開錠制御処理を開始する。そして、時刻「ｔ６」においてユーザ端末２０ａの開錠制御処理が終了すると、施錠制御部１０８は、中断していたユーザ端末２０ｂの前処理を再開する。

（４−３−１−４．測定部１３８）
測定部１３８は、錠前デバイス１０‐４が有する例えば加速度センサー、地磁気センサー、またはマイクロフォンなどにより、各種の情報を測定する。例えば、測定部１３８は、錠前デバイス１０‐４の加速度や、周囲の音声などを測定する。

なお、錠前デバイス１０‐４に含まれるその他の構成要素については、第１の実施形態と概略同様である。また、ユーザ端末２０およびサーバ３０の構成については、第１の実施形態と概略同様である。

＜４−４．動作＞
以上、第４の実施形態による構成について説明した。続いて、第４の実施形態による動作について、図３７〜図３９を参照して説明する。なお、ここでは、ユーザ端末２０による開錠要求の場面での動作について説明を行う。より具体的には、錠前デバイス１０‐４にまずユーザ端末２０ａが錠前デバイス１０‐４に接近し、その後、別のユーザ端末２０ｂが錠前デバイス１０‐４に接近する場合の動作例について説明する。

なお、その他の種類の動作については、図６〜図１７に示した第１の実施形態と同様であるので、説明を省略する。

［４−４−１．全体的な動作］
図３７に示したように、まず、錠前デバイス１０‐４の施錠制御部１０８は、いずれかのユーザ端末２０の接近が接近検知部１１８により検知されるまで待機する（Ｓ５００１）。

そして、ユーザ端末２０ａの接近が接近検知部１１８により検知された場合には（Ｓ５００１：Ｙｅｓ）、施錠制御部１０８は、ユーザ端末２０ａの前処理を開始する（Ｓ５００３）。

その後、ユーザ端末２０ａの前処理の途中で、他のユーザ端末２０ｂの接近が接近検知部１１８により検知された場合には（Ｓ５００５：Ｙｅｓ）、施錠制御部１０８は、検知されたユーザ端末２０ｂの識別情報をキューに入れる（Ｓ５００７）。

そして、施錠制御部１０８は、ユーザ端末２０ａの前処理が終了するまで、Ｓ５００５〜Ｓ５００７の処理を繰り返す。

ここで、図３８を参照して、Ｓ５００７より後の動作について説明する。Ｓ５００７の後に、ユーザ端末２０ａの前処理が終了した場合には（Ｓ５００９：Ｙｅｓ）、施錠制御部１０８は、キューに入れられた識別情報のうち先頭の識別情報を取り出す（Ｓ５０２１）。

続いて、施錠制御部１０８は、Ｓ５０２１で取り出した識別情報のユーザ端末２０ｂに対応する前処理を開始する（Ｓ５０２３）。

そして、施錠制御部１０８は、後述する「開錠要求判定処理」を行う（Ｓ５０２５）。その後、ユーザ端末２０ａからの開錠要求が検出部１２０により検出されるまで、施錠制御部１０８は、Ｓ５０２５の処理を繰り返す。

Ｓ５０２５においてユーザ端末２０ａからの開錠要求が検出部１２０により検出された場合には（Ｓ５０２７：Ｙｅｓ）、施錠制御部１０８は、ユーザ端末２０ｂの前処理を一時中断する（Ｓ５０２９）。

続いて、施錠制御部１０８は、ユーザ端末２０ａの開錠制御処理を行う（Ｓ５０３１）。

その後、施錠制御部１０８は、Ｓ５０２９で一時中断したユーザ端末２０ｂの前処理を再開する（Ｓ５０３３）。

［４−４−２．開錠要求判定処理］
次に、図３９を参照して、Ｓ５０２５における「開錠要求判定処理」の動作について詳細に説明する。

図３９に示したように、まず、錠前デバイス１０‐４の検出部１２０は、測定部１３８による加速度の測定結果に基づいて、振動が検出されたか否かを判定する（Ｓ５１０１）。振動が検出されていない場合には（Ｓ５１０１：Ｎｏ）、検出部１２０は、後述するＳ５１０９の動作を行う。

一方、振動が検出された場合には（Ｓ５１０１：Ｙｅｓ）、検出部１２０は、ウェアラブルデバイス５０により検知された振動のタイミングがウェアラブルデバイス５０から受信されるまで例えば所定の時間待機する（Ｓ５１０３）。振動のタイミングが受信されない場合には（Ｓ５１０３：Ｎｏ）、検出部１２０は、後述するＳ５１０９の動作を行う。

一方、検知された振動のタイミングがウェアラブルデバイス５０から受信された場合には（Ｓ５１０３：Ｙｅｓ）、検出部１２０は、Ｓ５１０１で検出された振動のタイミングと、受信された振動のタイミングとが一致するか否かを判定する（Ｓ５１０５）。

振動のタイミングが一致する場合には（Ｓ５１０５：Ｙｅｓ）、検出部１２０は、ユーザ端末２０ａからの開錠要求を検出する（Ｓ５１０７）。一方、振動のタイミングが一致しない場合には（Ｓ５１０５：Ｎｏ）、検出部１２０は、開錠要求を検出しない（Ｓ５１０９）。

＜４−５．効果＞
［４−５−１．効果１］
以上、例えば図３５〜図３９を参照して説明したように、第４の実施形態による錠前デバイス１０‐４は、ユーザ端末２０が接近したことが検知された場合に、開錠のための処理のうち前処理を行う。そして、錠前デバイス１０‐４は、前処理が終了し、かつ、ユーザ端末２０からの開錠要求が検出された場合には、開錠のための処理のうち開錠制御処理を行う。

このため、錠前デバイス１０‐４は前処理を事前に行っておくので、開錠要求時において、開錠のための処理のうち残りの処理（つまり開錠制御処理）だけを行えばよく、短時間で処理が終了する。従って、開錠要求時において、ユーザ２がドアの前で待たされる時間が短縮される。

また、錠前デバイス１０‐４は、ユーザ端末２０ｂの前処理を行っている間に、すでに前処理が終了しているユーザ端末２０ａによる開錠要求が検出された場合には、ユーザ端末２０ｂの前処理を一時中断し、そして、ユーザ端末２０ａの開錠制御処理を行う。このため、仮に同じ時間帯に複数のユーザ端末２０が錠前デバイス１０‐４に接近した場合であっても、ユーザ端末２０ａのユーザ２が開錠操作を行ったら、素早く開錠される。このため、ユーザ２は、開錠のためにほとんど待たされることがなく、ストレスを感じることがない。

［４−５−２．効果２］
また、第４の実施形態によれば、ユーザは、例えばウェアラブルデバイス５０を振ったり、ウェアラブルデバイス５０に対してタップすることにより開錠操作を行うことができる。このため、ユーザは、ドアを開錠しようとする度に例えばユーザ端末２０においてアプリケーションを起動する必要がなく、作業負荷が軽減される。

［４−５−３．効果３］
また、ユーザ端末２０からの開錠要求が検出されない限り、錠前デバイス１０‐４は、開錠制御処理を行わないので、例えば公知のキーレスエントリーの技術と比べて、開錠の安全性が向上する。例えば、ユーザがドアから離れた場所にいる場合など、ユーザが意図せずにドアが開錠されることを防止することができる。

＜４−６．変形例＞
なお、錠前デバイス１０‐４とユーザ端末２０とがＢｌｕｅｔｏｏｔｈに沿って通信を行う場合には以下の変形例が適用可能である。例えば、施錠制御部１０８は、すでに前処理が終了しているユーザ端末２０ａによる開錠要求がまだ検出部１２０により検出されておらず、かつ、現在前処理を行っている別のユーザ端末２０ｂの前処理が終了した場合には、Ｂｌｕｅｔｏｏｔｈの接続をユーザ端末２０ｂからユーザ端末２０ａへ戻してもよい。

通常、Ｂｌｕｅｔｏｏｔｈの接続には、一定の時間が必要となる。この変形例によれば、予めＢｌｕｅｔｏｏｔｈの接続を、先に前処理が終了しているユーザ端末２０ａへ戻すことにより、錠前デバイス１０‐４は、ユーザ端末２０ａによる開錠要求が検出された場合に、ユーザ端末２０ａに対応する開錠制御処理をより短時間で行うことが可能となる。

＜＜５．第５の実施形態＞＞
＜５−１．背景＞
以上、第４の実施形態について説明した。続いて、第５の実施形態について説明する。最初に、第５の実施形態を創作するに至った背景について説明する。

一般的に、一旦ドアが開錠された後には、適切なタイミングで自動的に施錠されることが望ましい。公知の技術では、ドアが開錠されてから所定の時間が経過した際に、自動的に施錠する方法が提案されている。しかしながら、この方法では、ユーザがドアを開けたままにしている場合には、ドアが開いた状態で施錠処理が行われてしまう恐れがある。

後述するように、第５の実施形態による錠前デバイス１０‐５は、適切なタイミングで自動的に施錠することが可能である。

＜５−２．システム構成＞
第５の実施形態によるシステム構成は、図１または図１８に示した第１の実施形態と同様である。

＜５−３．構成＞
［５−３−１．錠前デバイス１０‐５］
続いて、第５の実施形態による構成について詳細に説明する。図４０は、第５の実施形態による錠前デバイス１０‐５の構成を示した機能ブロック図である。図４０に示したように、第５の実施形態による錠前デバイス１０‐５は、図２に示した錠前デバイス１０‐１と比較して、制御部１００‐１の代わりに、制御部１００‐５を有する。また、錠前デバイス１０‐５は、測定部１３８をさらに有する。

（５−３−１−１．制御部１００‐５）
制御部１００‐５は、第１の実施形態による制御部１００‐１と比べて、開閉状態判定部１２２をさらに有する。

（５−３−１−２．開閉状態判定部１２２）
開閉状態判定部１２２は、測定部１３８により測定される測定結果に基づいて、錠前デバイス１０‐５が取り付けられているドアが閉まっているか否かを判定する。例えば、開閉状態判定部１２２は、測定部１３８により測定された加速度が所定の閾値以上の値である場合には、ドアが動いていると判定する。

また、開閉状態判定部１２２は、例えば記憶部１３４に記憶されている、ドアが閉じた状態の地磁気の測定値と、測定部１３８により測定された地磁気の値とを比較することにより、ドアが閉まっているか否かを判定する。より具体的には、開閉状態判定部１２２は、ドアが閉じた状態の地磁気の測定値と、測定部１３８により測定された地磁気の値との差異が所定の範囲内である場合にはドアが閉まっていると判定する。また、開閉状態判定部１２２は、上記の差異が所定の範囲外である場合にはドアが開いていると判定する。

‐変形例
なお、変形例として、開閉状態判定部１２２は、測定部１３８による測定結果に基づいて、錠前デバイス１０‐５の取り付け状態が異常であるか否かを判定することも可能である。例えば、開閉状態判定部１２２は、測定部１３８により所定の範囲の値の加速度が測定された際には、取り付けられているドアから錠前デバイス１０‐５が落下状態であると判定してもよい。また、開閉状態判定部１２２は、測定部１３８により測定された重力の方向に基づいて錠前デバイス１０‐５の取り付け姿勢を判別することも可能である。例えば、錠前デバイス１０‐５が両面テープでドアに取り付けられる場合などには、錠前デバイス１０‐５の取り付け姿勢が変化し得る。そこで、開閉状態判定部１２２は、判別した錠前デバイス１０‐５の取り付け姿勢が所定の方向からズレている場合には、錠前デバイス１０‐５の取り付け状態が異常であると判定してもよい。

（５−３−１−３．施錠制御部１０８）
第５の実施形態による施錠制御部１０８は、施錠部１３２に開錠させた後に例えば所定の時間が経過し、かつ、開閉状態判定部１２２によりドアが閉まっていることが判定された場合には、施錠部１３２に施錠させる。

（５−３−１−４．送信制御部１１２）
第５の実施形態による送信制御部１１２は、開閉状態判定部１２２によりドアが開いていると判定された時間が所定時間経過した場合には、警告の通知をユーザ端末２０へ通信部１３０に送信させることが可能である。この送信例によれば、ドアが長時間開いたままになっていることをユーザに警告することが可能になる。

なお、測定部１３８の機能は、第４の実施形態と同様である。また、錠前デバイス１０‐５に含まれるその他の構成要素については、第１の実施形態と概略同様である。また、ユーザ端末２０およびサーバ３０の構成については、第１の実施形態と概略同様である。

＜５−４．動作＞
以上、第５の実施形態による構成について説明した。続いて、第５の実施形態による動作について、図４１を参照して説明する。なお、ここでは、ドアの開錠および施錠時における動作について説明を行う。その他の種類の動作については、図６〜図１７に示した第１の実施形態と同様であるので、説明を省略する。

図４１に示したように、まず、錠前デバイス１０‐５の施錠制御部１０８は、施錠部１３２により開錠されるまで（例えば図１６に示したＳ１８３３の動作が行われるまで）待機する（Ｓ６００１）。

そして、開錠された場合には（Ｓ６００１：Ｙｅｓ）、施錠制御部１０８は、一定時間待機する。なお、この間、開閉状態判定部１２２は、錠前デバイス１０‐５が取り付けられているドアが閉まっているか否かを定期的に判定する（Ｓ６００３）。

続いて、施錠制御部１０８は、現在ドアが閉まっていると開閉状態判定部１２２により判定されているか否かを確認する（Ｓ６００５）。ドアが閉まっていると判定されている場合には（Ｓ６００５：Ｙｅｓ）、施錠制御部１０８は、施錠部１３２に施錠させる（Ｓ６００７）。その後、錠前デバイス１０‐５は、再びＳ６００１の動作を行う。

一方、ドアが開いていると判定されている場合には（Ｓ６００５：Ｎｏ）、施錠制御部１０８は、所定の時間が経過するまで、Ｓ６００５の動作を繰り返す。

そして、所定の時間が経過した場合には（Ｓ６００９：Ｙｅｓ）、送信制御部１１２は、警告の通知をユーザ端末２０へ通信部１３０に送信させる（Ｓ６０１１）。

その後、錠前デバイス１０‐５は、再びＳ６００５の動作を行う。

＜５−５．効果＞
以上、図４０および図４１を参照して説明したように、第５の実施形態による錠前デバイス１０‐５は、開錠した後に例えば所定の時間が経過し、かつ、錠前デバイス１０‐５が取り付けられているドアが閉まっていることが判定された場合には自動的に施錠する。

このため、ドアが閉まっている時にのみ自動的に施錠することが可能になる。また、ドアが開いているのに施錠されることを防止できる。

＜５−６．変形例＞
なお、第５の実施形態の変形例として、錠前デバイス１０‐５に隣接する壁に磁石を設置してもよい。この変形例によれば、ドアが開いているときの地磁気の測定結果と、ドアが閉まっているときの地磁気の測定結果との差異がより大きくなると考えられる。従って、錠前デバイス１０‐５は、ドアの開閉状態をより精度高く判定することができる。

また、上記の説明では、ドアが長時間開いていると判定された場合には、錠前デバイス１０‐５がユーザ端末２０へ警告の通知を送信する例について説明したが、かかる例に限定されない。例えば、上記の場合には、錠前デバイス１０‐５は、ブザーを鳴らしてもよい。

＜＜６．第６の実施形態＞＞
＜６−１．背景＞
以上、第５の実施形態について説明した。続いて、第６の実施形態について説明する。最初に、第６の実施形態を創作するに至った背景について説明する。

錠前デバイス１０‐１がユーザ端末２０と無線通信を行い、ユーザ端末２０を認証して開錠処理を行う場面では、ユーザ端末２０のユーザ２は、錠前デバイス１０‐１と物理的なインタラクションを一切行わない。このため、錠前デバイス１０‐１が反応していることを何らかの手段によりユーザに通知しなければ、例えば錠前デバイス１０‐１がユーザ端末２０と通信していることや、錠前デバイス１０‐１が故障していること等、錠前デバイス１０‐１の状況をユーザ２は理解することができない。

公知の技術では、ドアの外側に錠前装置を設置し、そしてＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）またはディスプレイなどの表示手段により、錠前装置の状況をユーザに知らせる方法が提案されている。しかしながら、錠前装置がドアの外側に設置されていると、悪意のある人物により錠前装置が盗難される恐れがある。

また、別の方法として、ドアの内側に錠前装置を設置し、錠前装置の状況をユーザに知らせるための表示装置をドアの外側にさらに設置する方法も考えらえる。しかしながら、この方法では、装置の製造および設置のコストが大きくなってしまう。

後述するように、第６の実施形態による錠前デバイス１０‐６は、錠前デバイス１０‐６がドアの内側に設置された場合であっても、処理の状況をユーザに通知することが可能である。

＜６−２．システム構成＞
第６の実施形態によるシステム構成は、図１または図１８に示した第１の実施形態と同様である。

＜６−３．構成＞
［６−３−１．錠前デバイス１０‐６］
続いて、第６の実施形態による構成について詳細に説明する。図４２は、第６の実施形態による錠前デバイス１０‐６の構成を示した機能ブロック図である。図４２に示したように、第６の実施形態による錠前デバイス１０‐６は、図２に示した錠前デバイス１０‐１と比較して、制御部１００‐１の代わりに、制御部１００‐６を有する。

（６−３−１−１．制御部１００‐６）
制御部１００‐６は、第１の実施形態による制御部１００‐１と比べて、処理状況通知部１２４をさらに有する。

（６−３−１−２．処理状況通知部１２４）
処理状況通知部１２４は、所定のタイミングで、施錠制御部１０８による処理状況を示す処理状況通知を該当のユーザ端末２０へ通信部１３０に送信させる。例えば、処理状況通知部１２４は、開錠させるための処理が施錠制御部１０８により行われている間において、要通知イベントが発生する度に、発生した要通知イベントの内容を示す処理状況通知を該当のユーザ端末２０へ通信部１３０に送信させる。

ここで、開錠させるための処理は、第４の実施形態と同様である。また、要通知イベントは、例えば、「錠前デバイス１０‐６とユーザ端末２０とが接続可能状態になったこと」、「錠前デバイス１０‐６とユーザ端末２０とが実際に接続されたこと」、「ユーザ端末２０の認証処理中であること」、「ユーザ端末２０の認証処理が完了したこと」、または、「開錠が完了したこと」などであってもよい。なお、「実際に接続されたこと」とは、例えばＢＬＥではｂｏｎｄの処理が実行されたことに該当する。

なお、錠前デバイス１０‐６に含まれるその他の構成要素については、第１の実施形態と概略同様である。

［６−３−２．ユーザ端末２０］
続いて、第６の実施形態によるユーザ端末２０の構成について説明する。

（６−３−２−１．制御部２００）
第６の実施形態による制御部２００は、錠前デバイス１０‐６から受信された処理状況通知に基づいて、受信された処理状況通知を出力させる。例えば、制御部２００は、受信された処理状況通知が所定の通知である場合には、ユーザ端末２０またはウェアラブルデバイス５０を振動させる。また、制御部２００は、受信された処理状況通知が所定の通知以外である場合には、受信された処理状況通知の内容を表示画面に表示させる。ここで、所定の通知は、例えば「実際に接続されたこと」を示す通知であってもよい。かかる構成によれば、ユーザ端末２０またはウェアラブルデバイス５０の振動によりユーザに表示画面を確認させる契機を与えることができる。また、振動させるイベントは一回だけなので、ユーザが不快感を抱く恐れがほとんどない。

なお、ユーザ端末２０に含まれるその他の構成要素については、第１の実施形態と概略同様である。また、サーバ３０の構成については、第１の実施形態と概略同様である。

＜６−４．動作＞
以上、第６の実施形態による構成について説明した。続いて、第６の実施形態による動作について、図４３を参照して説明する。なお、ここでは、開錠処理時の動作について説明を行う。その他の種類の動作については、図６〜図１７に示した第１の実施形態と同様であるので、説明を省略する。また、図４３に示した動作は、所定の時間間隔で定期的に行われることを前提とする。

図４３に示したように、まず、錠前デバイス１０‐６の処理状況通知部１２４は、錠前デバイス１０‐６の処理状況を確認し、要通知イベントが発生したか否かを確認する（Ｓ７００１）。要通知イベントが発生した場合には（Ｓ７００１：Ｙｅｓ）、処理状況通知部１２４は、要通知イベントの内容を示す処理状況通知を該当のユーザ端末２０へ通信部１３０に送信させる（Ｓ７００３）。

その後、ユーザ端末２０の制御部２００は、Ｓ７００３で受信された処理状況通知が所定の通知であるか否かを判定する（Ｓ７００５）。受信された処理状況通知が所定の通知である場合には（Ｓ７００５：Ｙｅｓ）、制御部２００は、ユーザ端末２０、または（ユーザ端末２０のユーザ２が装着している）ウェアラブルデバイス５０を振動させる（Ｓ７００７）。

一方、受信された処理状況通知が所定の通知以外である場合には（Ｓ７００５：Ｎｏ）、制御部２００は、受信された処理状況通知の内容を表示画面に表示させる（Ｓ７００９）。

＜６−５．効果＞
以上、図４２および図４３を参照して説明したように、第６の実施形態による錠前デバイス１０‐６は、要通知イベントが発生する度に、発生した要通知イベントの内容を示す処理状況通知を該当のユーザ端末２０へ送信する。このため、仮に錠前デバイス１０‐６がドアの内側（つまり室内側）に設置された場合であっても、錠前デバイス１０‐６の状況をユーザに通知することができる。

その結果、錠前デバイス１０‐６をドアの外側に設置する必要がなくなるので、錠前デバイス１０‐６が盗難される恐れがほとんどない。また、例えば錠前デバイス１０‐６の状況をユーザに知らせるための表示装置も設置する必要がないので、装置の製造および設置のコストを削減することができる。

＜＜７．第７の実施形態＞＞
＜７−１．背景＞
以上、第６の実施形態について説明した。続いて、第７の実施形態について説明する。最初に、第７の実施形態を創作するに至った背景について説明する。

通常、錠前デバイス１０‐１のような錠前装置の電源としては、乾電池や二次電池などの電池が利用されることが多い。このため、電池の電力残量が不足すると、錠前装置が使用不可能になるので、電池の適切な交換タイミングをユーザに通知可能であることが望ましい。

しかしながら、乾電池の消耗は例えば環境の温度なども大きく影響するので、一般的に、乾電池の電池寿命予測は難しい。このため、予測した寿命よりも早く電池の寿命が到来してしまう恐れがある。

また、充電式乾電池に関しては、電池を充電している間は、代わりの電池がなければ錠前装置が使用できないという問題点がある。

また、錠前装置が充電式のバッテリーを内蔵する方法も考えられるが、この方法では、充電を行う作業がユーザにとって不便である。例えば、ユーザは、充電用のケーブルを錠前装置とコンセントとの間で引き回すなどの作業が必要となる。

後述するように、第７の実施形態による錠前デバイス１０‐７は、電池の適切な交換タイミングをユーザに通知することが可能である。

＜７−２．システム構成＞
第７の実施形態によるシステム構成は、図１または図１８に示した第１の実施形態と同様である。

＜７−３．構成＞
［７−３−１．錠前デバイス１０‐７］
続いて、第７の実施形態による構成について詳細に説明する。図４４は、第７の実施形態による錠前デバイス１０‐７の構成を示した機能ブロック図である。図４４に示したように、第７の実施形態による錠前デバイス１０‐７は、図２に示した錠前デバイス１０‐１と比較して、制御部１００‐１の代わりに、制御部１００‐７を有する。また、錠前デバイス１０‐７は、電池切り替え部１４０をさらに有する。

また、図４４には図示していないが、錠前デバイス１０‐７は、第１のバッテリー、および第２のバッテリーの２種類のバッテリーを有する。ここで、第１のバッテリーは、使用中のバッテリーであり、また、第２のバッテリーは、バックアップ用の予備のバッテリーである。また、第１のバッテリーおよび第２のバッテリーは、同じ種類のバッテリーであり得る。また、第１のバッテリーおよび第２のバッテリーは、例えばリチウム乾電池などの乾電池や、二次電池などの電池であってもよい。

（７−３−１−１．制御部１００‐７）
制御部１００‐７は、第１の実施形態による制御部１００‐１と比べて、電池残量取得部１２６、および電池交換警告通知部１２８をさらに有する。

（７−３−１−２．電池残量取得部１２６）
電池残量取得部１２６は、第１のバッテリーの残量を示す情報を例えば第１のバッテリーから取得する。なお、第１のバッテリーが乾電池である場合には、上記の残量を示す情報は、例えば、閾値以上の電圧が測定されているか否かを示す情報であってもよい。

（７−３−１−３．電池交換警告通知部１２８）
電池交換警告通知部１２８は、電池残量取得部１２６により取得された情報が、第１のバッテリーの残量が所定の閾値以下になったことを示す場合には、電池交換の警告通知をユーザ端末２０へ通信部１３０に送信させる。例えば、電池交換警告通知部１２８は、上記の場合で、かつ、第１のバッテリーが交換されるまでの間に、電池交換の警告通知を定期的にユーザ端末２０へ通信部１３０に送信させてもよい。

ここで、所定の閾値は、例えば、錠前デバイス１０‐７が正常に稼働するために必要な最低限の電力量であってもよい。また、所定の閾値は、「０」であってもよい。

（７−３−１−４．電池切り替え部１４０）
電池切り替え部１４０は、電池残量取得部１２６により取得された情報が、第１のバッテリーの残量が所定の閾値以下になったことを示す場合に、使用するバッテリーを第１のバッテリーから第２のバッテリーに切り替える。

なお、錠前デバイス１０‐７に含まれるその他の構成要素については、第１の実施形態と概略同様である。

［７−３−２．ユーザ端末２０］
続いて、第７の実施形態によるユーザ端末２０の構成について説明する。

（７−３−２−１．表示制御部２１０）
第７の実施形態による表示制御部２１０は、錠前デバイス１０‐７から電池交換の警告通知が受信された場合には、受信された警告通知を操作表示部２２２に表示させる。例えば、表示制御部２１０は、警告通知をポップアップ形式で、例えばユーザにより選択されるまでの間継続的に操作表示部２２２に表示させてもよい。

また、表示制御部２１０は、表示画面に表示された警告通知がユーザ２により選択された場合には、ユーザ２が電池を発注するためのメニュー画面を操作表示部２２２にさらに表示させることも可能である。

なお、ユーザ端末２０に含まれるその他の構成要素については、第１の実施形態と概略同様である。また、サーバ３０の構成については、第１の実施形態と概略同様である。

＜７−４．動作＞
以上、第７の実施形態による構成について説明した。続いて、第７の実施形態による動作について、図４５を参照して説明する。なお、この動作は、錠前デバイス１０‐７が起動している間、例えば所定の時間間隔で定期的に行われる。また、その他の種類の動作については、図６〜図１７に示した第１の実施形態と同様であるので、説明を省略する。

図４５に示したように、まず、錠前デバイス１０‐７の電池残量取得部１２６は、第１のバッテリーの残量を示す情報を例えば第１のバッテリーから取得する。そして、電池切り替え部１４０は、取得された情報が示す残量が所定の閾値以下であるか否かを確認する（Ｓ８００１）。残量が所定の閾値以下になっていない場合には（Ｓ８００１：Ｎｏ）、錠前デバイス１０‐７は、後述するＳ８００９の動作を行う。

一方、残量が所定の閾値以下である場合には（Ｓ８００１：Ｙｅｓ）、電池切り替え部１４０は、使用するバッテリーを第１のバッテリーから第２のバッテリーに切り替える（Ｓ８００３）。そして、電池交換警告通知部１２８は、電池交換の警告通知をユーザ端末２０へ通信部１３０に送信させる（Ｓ８００５）。

その後、ユーザ端末２０の表示制御部２１０は、Ｓ８００５で受信された警告通知を操作表示部２２２に表示させる。さらに、表示された警告通知がユーザにより選択された場合には、表示制御部２１０は、電池の発注メニューを操作表示部２２２に表示させる（Ｓ８００７）。

その後、錠前デバイス１０‐７は、一定時間待機する（Ｓ８００９）。その後、錠前デバイス１０‐７は、再びＳ８００１の動作を繰り返す。

＜７−５．効果＞
［７−５−１．効果１］
以上、図４４および図４５を参照して説明したように、第７の実施形態による錠前デバイス１０‐７は、第１のバッテリーの残量が所定の閾値以下になったことが検出された場合には、使用するバッテリーを第１のバッテリーから、予備の第２のバッテリーに自動的に切り替える。このため、バッテリーの残量不足の発生を防止することができ、錠前デバイス１０‐７を長時間安定して稼働させることが可能になる。

［７−５−２．効果２］
また、錠前デバイス１０‐７は、第１のバッテリーの残量が所定の閾値以下になったことが検出された場合には、警告通知をユーザ端末２０へ送信する。このため、錠前デバイス１０‐７は、適切なタイミングで、バッテリーの交換をユーザに促すことが可能である。その結果、例えば、乾電池がまだ使用可能なのにユーザが交換してしまうなど、ユーザによる非効率なバッテリーの交換を避けることができる。

また、ユーザ端末２０は、受信された警告通知と関連づけて電池の発注メニューを操作表示部２２２に表示させることが可能である。このため、ユーザ２は、該当のアプリケーションにおいて電池の発注および決済も行うことが可能であり、ユーザにとって利便性が高い。

＜＜８．変形例＞＞
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

例えば、上述した各実施形態では、錠前デバイス１０‐１〜錠前デバイス１０‐７が家の玄関などのドアに設置される例を中心として説明したが、かかる例に限定されない。錠前デバイス１０‐１〜錠前デバイス１０‐７は、例えば、空港や駅などに設置されるロッカーのドア、自動車のドアなどの各種のドアに設置され得る。また、自転車などの施錠機構に適用されてもよい。

また、上述した各実施形態の動作における各ステップは、必ずしも記載された順序に沿って処理されなくてもよい。例えば、各ステップは、適宜順序が変更されて処理されてもよい。また、各ステップは、時系列的に処理される代わりに、一部並列的に又は個別的に処理されてもよい。

また、上述した各実施形態によれば、ＣＰＵなどのプロセッサ、およびＲＡＭなどのハードウェアを、上述した錠前デバイス１０‐１の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、
前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、
を備える、情報処理装置。
（２）
前記情報処理装置は、前記生成された第１の情報を前記第１の公開鍵に基づいて検証する検証処理部をさらに備え、
前記判定部は、前記生成された第１の情報の検証結果に基づいて、前記施錠部に開錠させるか否かを判定する、前記（１）に記載の情報処理装置。
（３）
前記判定部は、前記検証処理部により前記生成された第１の情報が正当であることが検証された場合に、前記施錠部に開錠させることを判定する、前記（２）に記載の情報処理装置。
（４）
前記通信部は、前記第１の公開鍵と、第２の通信端末による前記第１の公開鍵に対する署名情報とを含む第１の鍵情報をさらに受信し、
前記情報処理装置は、前記第１の公開鍵に対する署名情報に基づいて前記第１の公開鍵の正当性を検証する鍵検証部をさらに備え、
前記判定部は、さらに、前記鍵検証部による検証結果に基づいて、前記施錠部に開錠させるか否かを判定する、前記（２）または（３）に記載の情報処理装置。
（５）
前記判定部は、前記第１の公開鍵が正当であることが検証された場合に、前記施錠部に開錠させることを判定する、前記（４）に記載の情報処理装置。
（６）
前記第１の公開鍵に対する署名情報は、前記第２の通信端末に対応づけられた第２の秘密鍵を用いて前記第１の公開鍵に対して電子署名された情報であり、
前記検証処理部は、さらに、前記第２の秘密鍵に対応する第２の公開鍵に基づいて前記第１の公開鍵に対する署名情報を検証し、
前記鍵検証部は、前記第１の公開鍵に対する署名情報の検証結果と前記第１の公開鍵とに基づいて、前記第１の公開鍵が正当であるか否かを検証する、前記（４）または（５）に記載の情報処理装置。
（７）
前記情報処理装置は、前記第２の公開鍵を記憶する記憶部をさらに備える、前記（６）に記載の情報処理装置。
（８）
前記情報処理装置は、第１のアルゴリズムおよび第２のアルゴリズムを記憶する記憶部をさらに備え、
前記第１の公開鍵および前記第１の秘密鍵は、前記第１のアルゴリズムに応じた情報である、前記（１）〜６に記載のいずれか一項に記載の情報処理装置。
（９）
第３の公開鍵および前記第３の公開鍵に対応する第３の秘密鍵は、前記第２のアルゴリズムに応じた情報であり、
前記通信部は、前記第３の秘密鍵に基づいて生成された第１の情報を前記第１の通信端末からさらに受信し、
前記判定部は、前記第３の公開鍵と、前記第３の秘密鍵に基づいて生成された第１の情報とに基づいて、前記施錠部に開錠させるか否かを判定する、前記（８）に記載の情報処理装置。
（１０）
前記通信部は、前記第１のアルゴリズムから前記第２のアルゴリズムへのアルゴリズムの移行要求を前記第１の通信端末からさらに受信し、
前記情報処理装置は、前記移行要求が受信された場合に、前記第１のアルゴリズムの使用を停止するアルゴリズム切り替え部をさらに備える、前記（８）または（９）に記載の情報処理装置。
（１１）
前記第１の鍵情報は、前記情報処理装置が管理する日時情報の変更権限の有無を示す日時変更権限情報をさらに含み、
前記情報処理装置は、前記第１の鍵情報に含まれる日時変更権限情報に基づいて、前記第１の通信端末による前記日時情報の変更の可否を判断する日時情報変更部をさらに備える、前記（４）〜（７）のいずれか一項に記載の情報処理装置。
（１２）
前記情報処理装置は、前記施錠部をさらに備える、前記（１）〜（１１）のいずれか一項に記載の情報処理装置。
（１３）
第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信することと、
前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定することと、
を備える、情報処理方法。
（１４）
コンピュータを、
第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、
前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部、
として機能させるための、プログラム。
（１５）
第１の通信端末、および情報処理装置を有し、
前記情報処理装置は、
第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを前記第１の通信端末から受信する通信部と、
前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、
を備える、情報処理システム。
（１６）
前記情報処理システムは、第２の通信端末、および管理装置をさらに有し、
前記第２の通信端末は、第２の情報、および前記管理装置へのリンク情報を前記第１の通信端末に送信し、
前記第１の通信端末は、前記第２の情報を前記管理装置へ送信することにより、第１の鍵情報を前記管理装置から受信し、
前記第１の鍵情報は、前記第２の通信端末による前記第１の公開鍵に対する署名情報を含む、前記（１５）に記載の情報処理システム。
（１７）
前記管理装置は、前記第１の通信端末から前記第２の情報を受信した場合に、前記第１の鍵情報の発行要求を前記第２の通信端末に送信し、
前記第２の通信端末は、前記第１の鍵情報の発行要求が前記管理装置から受信された場合に、前記第１の鍵情報を前記管理装置へ送信する、前記（１６）に記載の情報処理システム。
（１８）
前記第１の鍵情報は、前記第１の通信端末のユーザの階層を示す階層情報をさらに含み、
前記第１の鍵情報に含まれる階層情報は、前記第２の通信端末のユーザの階層よりも低い階層を示す、前記（１６）または（１７）に記載の情報処理システム。
（１９）
前記第２の通信端末のユーザは、前記情報処理装置の管理者である、前記（１８）に記載の情報処理システム。
（２０）
前記情報処理システムは、第３の通信端末、および管理装置をさらに有し、
第４の公開鍵は、前記第３の通信端末に対応づけられており、
前記第１の通信端末は、第３の情報、および前記管理装置へのリンク情報を前記第３の通信端末に送信し、
前記第３の通信端末は、前記第３の情報を前記管理装置へ送信することにより、第３の鍵情報を前記管理装置から受信し、
前記第３の鍵情報は、前記第１の通信端末による前記第４の公開鍵に対する署名情報を含む、前記（１５）〜（１９）のいずれか一項に記載の情報処理システム。

１０‐１〜１０‐７ 錠前デバイス
２０ ユーザ端末
２２ 通信網
３０ サーバ
３２ データベース
５０ ウェアラブルデバイス
１００‐１〜１００‐７ 制御部
１０２ 鍵情報検証部
１０４ 検証処理部
１０６ 判定部
１０８ 施錠制御部
１１０ 乱数生成部
１１２ 送信制御部
１１４ アルゴリズム切り替え部
１１６ 日時情報変更部
１１８ 接近検知部
１２０ 検出部
１２２ 開閉状態判定部
１２４ 処理状況通知部
１２６ 電池残量取得部
１２８ 電池交換警告通知部
１３０ 通信部
１３２ 施錠部
１３４ 記憶部
１３６ 登録鍵ＤＢ
１３８ 測定部
１４０ 電池切り替え部
２００ 制御部
２０２ 暗号生成部
２０４ 鍵情報発行部
２０６ 送信制御部
２０８ 招待メール生成部
２１０ 表示制御部
２２０ 通信部
２２２ 操作表示部
２２４ 記憶部
３００ 制御部
３０２ 鍵情報発行要求部
３０４ 送信制御部
３０６ 乱数生成部
３０８ 検証処理部
３１０ 検証部
３２０ 通信部
３２２ 記憶部

Claims (20)

1. 第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、
   前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、
   を備える、情報処理装置。
2. 前記情報処理装置は、前記生成された第１の情報を前記第１の公開鍵に基づいて検証する検証処理部をさらに備え、
   前記判定部は、前記生成された第１の情報の検証結果に基づいて、前記施錠部に開錠させるか否かを判定する、請求項１に記載の情報処理装置。
3. 前記判定部は、前記検証処理部により前記生成された第１の情報が正当であることが検証された場合に、前記施錠部に開錠させることを判定する、請求項２に記載の情報処理装置。
4. 前記通信部は、前記第１の公開鍵と、第２の通信端末による前記第１の公開鍵に対する署名情報とを含む第１の鍵情報をさらに受信し、
   前記情報処理装置は、前記第１の公開鍵に対する署名情報に基づいて前記第１の公開鍵の正当性を検証する鍵検証部をさらに備え、
   前記判定部は、さらに、前記鍵検証部による検証結果に基づいて、前記施錠部に開錠させるか否かを判定する、請求項２に記載の情報処理装置。
5. 前記判定部は、前記第１の公開鍵が正当であることが検証された場合に、前記施錠部に開錠させることを判定する、請求項４に記載の情報処理装置。
6. 前記第１の公開鍵に対する署名情報は、前記第２の通信端末に対応づけられた第２の秘密鍵を用いて前記第１の公開鍵に対して電子署名された情報であり、
   前記検証処理部は、さらに、前記第２の秘密鍵に対応する第２の公開鍵に基づいて前記第１の公開鍵に対する署名情報を検証し、
   前記鍵検証部は、前記第１の公開鍵に対する署名情報の検証結果と前記第１の公開鍵とに基づいて、前記第１の公開鍵が正当であるか否かを検証する、請求項４に記載の情報処理装置。
7. 前記情報処理装置は、前記第２の公開鍵を記憶する記憶部をさらに備える、請求項６に記載の情報処理装置。
8. 前記情報処理装置は、第１のアルゴリズムおよび第２のアルゴリズムを記憶する記憶部をさらに備え、
   前記第１の公開鍵および前記第１の秘密鍵は、前記第１のアルゴリズムに応じた情報である、請求項１に記載の情報処理装置。
9. 第３の公開鍵および前記第３の公開鍵に対応する第３の秘密鍵は、前記第２のアルゴリズムに応じた情報であり、
   前記通信部は、前記第３の秘密鍵に基づいて生成された第１の情報を前記第１の通信端末からさらに受信し、
   前記判定部は、前記第３の公開鍵と、前記第３の秘密鍵に基づいて生成された第１の情報とに基づいて、前記施錠部に開錠させるか否かを判定する、請求項８に記載の情報処理装置。
10. 前記通信部は、前記第１のアルゴリズムから前記第２のアルゴリズムへのアルゴリズムの移行要求を前記第１の通信端末からさらに受信し、
    前記情報処理装置は、前記移行要求が受信された場合に、前記第１のアルゴリズムの使用を停止するアルゴリズム切り替え部をさらに備える、請求項８に記載の情報処理装置。
11. 前記第１の鍵情報は、前記情報処理装置が管理する日時情報の変更権限の有無を示す日時変更権限情報をさらに含み、
    前記情報処理装置は、前記第１の鍵情報に含まれる日時変更権限情報に基づいて、前記第１の通信端末による前記日時情報の変更の可否を判断する日時情報変更部をさらに備える、請求項４に記載の情報処理装置。
12. 前記情報処理装置は、前記施錠部をさらに備える、請求項１に記載の情報処理装置。
13. 第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信することと、
    前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定することと、
    を備える、情報処理方法。
14. コンピュータを、
    第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを第１の通信端末から受信する通信部と、
    前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部、
    として機能させるための、プログラム。
15. 第１の通信端末、および情報処理装置を有し、
    前記情報処理装置は、
    第１の秘密鍵に基づいて生成された第１の情報と開錠要求とを前記第１の通信端末から受信する通信部と、
    前記第１の秘密鍵に対応する第１の公開鍵と前記生成された第１の情報とに基づいて、施錠部に開錠させるか否かを判定する判定部と、
    を備える、情報処理システム。
16. 前記情報処理システムは、第２の通信端末、および管理装置をさらに有し、
    前記第２の通信端末は、第２の情報、および前記管理装置へのリンク情報を前記第１の通信端末に送信し、
    前記第１の通信端末は、前記第２の情報を前記管理装置へ送信することにより、第１の鍵情報を前記管理装置から受信し、
    前記第１の鍵情報は、前記第２の通信端末による前記第１の公開鍵に対する署名情報を含む、請求項１５に記載の情報処理システム。
17. 前記管理装置は、前記第１の通信端末から前記第２の情報を受信した場合に、前記第１の鍵情報の発行要求を前記第２の通信端末に送信し、
    前記第２の通信端末は、前記第１の鍵情報の発行要求が前記管理装置から受信された場合に、前記第１の鍵情報を前記管理装置へ送信する、請求項１６に記載の情報処理システム。
18. 前記第１の鍵情報は、前記第１の通信端末のユーザの階層を示す階層情報をさらに含み、
    前記第１の鍵情報に含まれる階層情報は、前記第２の通信端末のユーザの階層よりも低い階層を示す、請求項１６に記載の情報処理システム。
19. 前記第２の通信端末のユーザは、前記情報処理装置の管理者である、請求項１８に記載の情報処理システム。
20. 前記情報処理システムは、第３の通信端末、および管理装置をさらに有し、
    第４の公開鍵は、前記第３の通信端末に対応づけられており、
    前記第１の通信端末は、第３の情報、および前記管理装置へのリンク情報を前記第３の通信端末に送信し、
    前記第３の通信端末は、前記第３の情報を前記管理装置へ送信することにより、第３の鍵情報を前記管理装置から受信し、
    前記第３の鍵情報は、前記第１の通信端末による前記第４の公開鍵に対する署名情報を含む、請求項１５に記載の情報処理システム。

Images