WO2020170976A1

WO2020170976A1 - 認可システム、管理サーバおよび認可方法

Info

Publication number: WO2020170976A1
Application number: PCT/JP2020/005837
Authority: WO
Inventors: 芳彦大森; 山下　高生
Original assignee: 日本電信電話株式会社
Priority date: 2019-02-22
Filing date: 2020-02-14
Publication date: 2020-08-27
Also published as: US11721148B2; US20220172533A1; JP7172716B2; JP2020135651A

Abstract

【課題】スマートロックのゲスト招待において、オーナーによる招待の負担を軽減し、なりすましや意図しない第三者の招待を防止する。【解決手段】スマートロック４００の解錠を要求する代表ゲスト端末１０２は、解錠の要求時に参照される認証情報を生成して署名し、オーナー端末１０１に送信する。オーナー端末１０１は、代表ゲスト端末１０２の署名を検証し、認証情報に署名して、管理サーバ２００に送信する。管理サーバ２００は、代表ゲスト端末１０２やオーナー端末１０１の署名を検証して、オーナー端末１０１と代表ゲスト端末１０２とを関連付けて記憶するとともに、認証情報と代表ゲスト端末１０２とを関連付けて記憶する。管理サーバ２００が、スマートロック４００から解錠要求を受信して、記憶した認証情報を参照しての解錠要求の認証に成功すれば、スマートロック４００が解錠する。

Description

認可システム、管理サーバおよび認可方法

　本発明は、ゲストの端末に対してスマートロックの解錠を認可するための認可システム、管理サーバおよび認可方法に関する。

　ＩｏＴ（Internet of Things）デバイスの１つとして、スマートロックがある（非特許文献１参照）。スマートロックは、オーナーが、例えば自宅の玄関の扉に設置する。続いて、オーナーは、合鍵を入手するための招待ＵＲＬ（Universal Resource Locator）を家族やゲストに発行し、家族やゲストは合鍵を記憶したスマートフォンを用いてスマートロックを解錠したり、オーナーが遠隔で解錠したりできる。ゲスト用の合鍵には、利用時間の制限を設けることができる。

　ゲストとしては、友人や知人に限らず、家事や子守りなどのサービスを提供する事業者（以下、サービス事業者とも記す）が派遣する従業員も考えられる。

Qrio Lock, ［online］，［平成31年2月13日検索］，インターネット<ＵＲＬ:https://qrio.me/smartlock>

　ゲストを招待する場合には、オーナーは、ゲストごとに招待ＵＲＬを取得して、ゲストの端末に送信する。ゲストが友人ならば、取得した招待ＵＲＬをメールやＳＮＳ（Social Networking Service）などで送信すればよい。
　しかしながら、ゲストが、サービス事業者の従業員の場合には、送信先が多く、招待ＵＲＬを取得したり送信したりする手間が増え、オーナーの負担となる。また、サービス事業者の従業員は、面識のない人であることが多く、相手を確認する手間が増えて、さらにオーナーの負担が大きくなる。また、ゲストが本人であることの十分な確認が困難で、なりすましのリスクがある。
　他にも、招待ＵＲＬがゲストの端末から第三者に覗き見されたり、共有されたりして、オーナーが意図しない第三者が合鍵を取得する可能性がある。

　本発明は、前記した背景を鑑みて創案されたものであり、招待するゲストの数が増えたり、招待の頻度が増加したりした場合であっても、オーナーによる招待の負担を軽減し、なりすましや意図しない第三者の招待を防止することが可能な認可システム、管理サーバ及び認可方法を提供することを課題とする。

　前記した課題を解決するため、請求項１に記載の発明は、スマートロック、前記スマートロックの管理者が利用するオーナー端末、子ゲストが利用し前記スマートロックの解錠を要求する子ゲスト端末、代表ゲストが利用し前記スマートロックの解錠を要求する代表ゲスト端末、および管理サーバを含む認可システムであって、前記代表ゲスト端末は、前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを、前記代表ゲスト端末による解錠の許可登録の要求として前記オーナー端末に送信し、前記オーナー端末は、前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、前記管理者による前記代表ゲスト端末に対する解錠の許可登録を承認する情報を受け付けた後に、前記代表ゲスト端末の認証情報に署名し、受信した前記解錠の許可登録の要求に含まれる情報と、前記代表ゲスト端末の認証情報に対する前記オーナー端末の署名とを、前記管理サーバに送信し、前記管理サーバは、前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記オーナー端末と前記代表ゲスト端末とを関連付けて記憶するとともに、前記代表ゲスト端末の認証情報と前記代表ゲスト端末とを関連付けて記憶し、前記スマートロックから、解錠を要求する前記代表ゲスト端末が送信した解錠要求を受信すると、当該代表ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該代表ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信し、前記スマートロックは、前記管理サーバが、前記解錠要求は前記代表ゲスト端末が送信した解錠要求であると判断した場合には解錠することを特徴とする認可システムとした。

　また、請求項１１に記載の発明は、スマートロック、前記スマートロックの管理者が利用するオーナー端末、子ゲストが利用し前記スマートロックの解錠を要求する子ゲスト端末、代表ゲストが利用し前記スマートロックの解錠を要求する代表ゲスト端末、および管理サーバを含む認可システムの認可方法であって、前記代表ゲスト端末は、前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを、前記代表ゲスト端末による解錠の許可登録の要求として前記オーナー端末に送信するステップを実行し、前記オーナー端末は、前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、前記管理者による前記代表ゲスト端末に対する解錠の許可登録を承認する情報を受け付けた後に、前記代表ゲスト端末の認証情報に署名するステップと、前記代表ゲスト端末から受信した前記解錠の許可登録の要求に含まれる情報と、前記代表ゲスト端末の認証情報に対する前記オーナー端末の署名とを、前記管理サーバに送信するステップとを実行し、前記管理サーバは、前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記オーナー端末と前記代表ゲスト端末とを関連付けて記憶するとともに、前記代表ゲスト端末の認証情報と前記代表ゲスト端末とを関連付けて記憶するステップと、前記スマートロックから、解錠を要求する前記代表ゲスト端末が送信した解錠要求を受信すると、当該代表ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該代表ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信するステップとを実行し、前記スマートロックは、前記管理サーバが、前記解錠要求は前記代表ゲスト端末が送信した解錠要求であると判断した場合には解錠するステップを実行することを特徴とする認可方法とした。

　このような構成にすることで、認可システムは、オーナーが承認した代表ゲスト端末を許可登録（代表ゲストの招待、代表ゲスト端末の登録）する。このため、代表ゲストは、自身の端末を用いて、スマートロックを解錠して入室ができるようになる。
　また、既存技術の招待ＵＲＬのようなスマートロックの合鍵は存在せず、合鍵が盗まれたり、第三者に渡ったりすることがなく、意図しない端末に解錠を許可することを防止できる。

　請求項２に記載の発明は、前記子ゲスト端末が、前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを前記代表ゲスト端末に送信し、前記代表ゲスト端末は、前記子ゲスト端末から受信した情報に含まれる署名の検証に成功した後に、前記子ゲスト端末の認証情報に署名し、前記代表ゲスト端末による解錠の許可登録の要求に加えて、前記子ゲスト端末の認証情報と、当該認証情報に対する前記子ゲスト端末の署名と、当該認証情報に対する前記代表ゲスト端末の署名とを、前記子ゲスト端末による解錠の許可登録の要求として前記オーナー端末に送信し、前記オーナー端末は、前記代表ゲスト端末から受信した前記子ゲスト端末による解錠の許可登録の要求に含まれる署名の検証に成功し、前記管理者による前記子ゲスト端末に対する解錠の許可登録を承認する情報を受け付けた後に、前記子ゲスト端末の認証情報に署名し、前記代表ゲスト端末から受信した前記子ゲスト端末による解錠の許可登録の要求に含まれる情報と、前記子ゲスト端末の認証情報に対する前記オーナー端末の署名とを、前記代表ゲスト端末による解錠の許可登録の要求に含まれる情報および前記代表ゲスト端末の認証情報に対する前記オーナー端末の署名とともに、前記管理サーバに送信し、前記管理サーバは、前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記代表ゲスト端末と前記子ゲスト端末とを関連付けて記憶するとともに、前記子ゲスト端末の認証情報と前記子ゲスト端末とを関連付けて記憶し、前記スマートロックから、解錠を要求する前記子ゲスト端末が送信した解錠要求を受信すると、当該子ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該子ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信し、前記スマートロックは、前記管理サーバが、前記解錠要求は前記子ゲスト端末が送信した解錠要求であると判断した場合には解錠することを特徴とする請求項１に記載の認可システムとした。

　このような構成にすることで、認可システムは、代表ゲスト端末が要求し、オーナーが承認した子ゲスト端末を許可登録（子ゲストの招待、子ゲスト端末の登録）する。このため、オーナーは、子ゲストの招待に関して、個々の子ゲスト端末に許可することなく、代表ゲストを介して許可することができる。オーナーは、信頼できる代表ゲストを介することで、個々の子ゲストを確認して許可登録するという負担が削減される。

　請求項３に記載の発明は、前記オーナー端末が、前記解錠の許可登録の管理サーバへの要求を前記代表ゲスト端末に認可することを示す許可トークンを生成して署名を付与し、前記署名を付与した許可トークンを前記管理サーバに送信し、前記管理サーバは、前記オーナー端末から受信した許可トークンに付与された署名を検証し、当該許可トークンと前記代表ゲスト端末とを関連付けて記憶し、前記子ゲスト端末は、前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを前記代表ゲスト端末に送信し、前記代表ゲスト端末は、前記子ゲスト端末から受信した情報に含まれる署名の検証に成功した後に、前記子ゲスト端末の認証情報に署名し、前記子ゲスト端末の認証情報と、当該認証情報に対する前記子ゲスト端末の署名と、当該認証情報に対する前記代表ゲスト端末の署名とを、前記子ゲスト端末による解錠の許可登録の要求として前記管理サーバに送信し、前記管理サーバは、前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、当該代表ゲスト端末に関連付けられた許可トークンを記憶していることを確認した後に、前記代表ゲスト端末と前記解錠の許可登録の要求に含まれる子ゲスト端末とを関連付けて記憶するとともに、当該子ゲスト端末の認証情報と当該子ゲスト端末とを関連付けて記憶することを特徴とする請求項１に記載の認可システムとした。

　これにより、管理サーバに認可トークンが登録され、代表ゲスト端末は、オーナー端末を経由することなく、管理サーバに直接に子ゲスト端末の解錠の許可登録を要求することができる。このため、オーナーによる子ゲスト招待を承認するという負担を削減することができる。また、管理サーバにおいて、どの代表ゲスト端末に対して認可トークンを発行したか管理することができる。

　請求項４に記載の発明は、前記オーナー端末が、前記解錠の許可登録の管理サーバへの要求を前記代表ゲスト端末に認可することを示す許可トークンを生成して署名を付与し、前記署名を付与した許可トークンを前記代表ゲスト端末に送信し、前記代表ゲスト端末は、前記オーナー端末から受信した許可トークンに付与された署名を検証して記憶し、前記子ゲスト端末は、前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを前記代表ゲスト端末に送信し、前記代表ゲスト端末は、前記子ゲスト端末から受信した情報に含まれる署名の検証に成功した後に、前記子ゲスト端末の認証情報に署名し、前記子ゲスト端末の認証情報と、当該認証情報に対する前記子ゲスト端末の署名と、当該認証情報に対する前記代表ゲスト端末の署名と、前記署名が付与された許可トークンとを、前記子ゲスト端末による解錠の許可登録の要求として前記管理サーバに送信し、前記管理サーバは、前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、前記許可トークンで認可された代表ゲスト端末が、前記解錠の許可登録の要求した代表ゲスト端末であることを検証して成功した後に、前記代表ゲスト端末と前記解錠の許可登録の要求に含まれる子ゲスト端末とを関連付けて記憶するとともに、当該子ゲスト端末の認証情報と当該子ゲスト端末とを関連付けて記憶することを特徴とする請求項１に記載の認可システムとした。

　これにより、代表ゲスト端末は、許可トークンを管理サーバに送信することで、オーナー端末を経由することなく、管理サーバに直接に子ゲスト端末の解錠の許可登録を要求することができる。このため、オーナーによる子ゲスト招待を承認するという負担を削減することができる。

　請求項５に記載の発明は、前記許可トークンが、前記子ゲスト端末の前記解錠の許可登録の取り消しを含み、前記代表ゲスト端末は、前記子ゲスト端末の許可登録の取り消しを要求し、前記管理サーバは、当該代表ゲスト端末に対応する許可トークンを記憶していることを検証して成功した後、または、前記許可登録の取り消しの要求に当該代表ゲスト端末に対応する許可トークンが含まれていて当該許可トークンに付与された署名を検証して成功した後に、当該代表ゲストに関連付けられた当該子ゲスト端末の認証情報を削除することを特徴とする請求項３または４に記載の認可システムとした。

　これにより、代表ゲスト端末は、自身が許可登録を要求した子ゲスト端末の許可登録を取り消すすることができる。

　請求項６に記載の発明は、前記許可トークンが、前記解錠の許可登録可能な子ゲスト端末の上限数および登録可能な期間の何れかを含み、前記管理サーバは、前記許可トークンが前記上限数を含む場合には、前記代表ゲスト端末から前記解錠の許可登録の要求を前記上限数まで受け付け、前記許可トークンが前記登録可能な期間を含む場合には、当該登録可能な期間に前記代表ゲスト端末から前記解錠の許可登録の要求があれば当該要求を受け付ける、ことを特徴とする請求項３または４に記載の認可システムとした。

　これにより、管理者は、代表ゲスト端末が登録可能な子ゲスト端末の数や登録可能な期間を制限できる。

　請求項７に記載の発明は、前記許可トークンが、前記解錠を許可する日時を含み、前記管理サーバは、前記解錠の許可登録を要求する子ゲスト端末の認証情報と当該子ゲスト端末とを関連付けて記憶する際に、前記解錠を許可する日時を関連付けて記憶し、前記解錠要求は当該子ゲスト端末が送信した解錠要求であるか否かを判断するときに、前記解錠要求の送信時刻が、当該子ゲスト端末と関連付けて記憶された解錠を許可する日時に含まれているかも判断することを特徴とする請求項３または４に記載の認可システムとした。

　これにより、管理者は、代表ゲスト端末が登録した子ゲスト端末による解錠可能な日時を制限することができる。

　請求項８に記載の発明は、前記管理サーバが、前記代表ゲスト端末から前記子ゲスト端末の解錠の許可登録の要求を受信すると、前記子ゲスト端末の認証情報と前記子ゲスト端末とを関連付けて記憶する前に、前記オーナー端末に前記解錠の許可登録の承認の可否を問い合わせ、前記オーナー端末は、前記管理者による前記解錠の許可登録の承認の可否を示す情報を受け付け、承認可または承認否を前記管理サーバに送信し、前記管理サーバは、前記承認可を受信すると、前記認証情報と前記子ゲスト端末とを関連付けて記憶することを特徴とする請求項３または４に記載の認可システムとした。

　これにより、管理サーバは、代表ゲスト端末から子ゲストの招待の要求があり、オーナーの承認を得た後に、子ゲスト端末にスマートロックの解錠を許可登録する。このため、代表ゲストが認めた子ゲストであっても、オーナーが承認しない子ゲストの招待を防止することができる。

　請求項９に記載の発明は、前記管理サーバが、前記代表ゲスト端末から前記子ゲスト端末の解錠の許可登録の要求を受信すると、前記代表ゲスト端末と前記子ゲスト端末とを関連付けて記憶するとともに、前記子ゲスト端末の認証情報と前記子ゲスト端末とを関連付けて記憶した後に、前記オーナー端末に前記解錠の許可登録を通知し、前記オーナー端末は、前記管理者による前記解錠の許可登録のキャンセルの可否を示す情報を受け付け、キャンセル可またはキャンセル否を前記管理サーバに送信し、前記管理サーバは、前記キャンセル可を受信すると、前記子ゲスト端末と関連付けて記憶した前記認証情報を削除することを特徴とする請求項３または４に記載の認可システムとした。

　これにより、管理サーバは、代表ゲスト端末から子ゲストの招待の要求があり、子ゲスト端末にスマートロックの解錠を許可登録した後であっても、オーナーが許可登録のキャンセルを指示すれば、許可登録を削除する。このため、代表ゲストが認めた子ゲストであっても、オーナーが承認しない子ゲストの招待をキャンセルすることができる。

　請求項１０に記載の発明は、スマートロック、前記スマートロックの管理者が利用するオーナー端末、子ゲストが利用し前記スマートロックの解錠を要求する子ゲスト端末、代表ゲストが利用し前記スマートロックの解錠を要求する代表ゲスト端末、および管理サーバを含む認可システムの管理サーバであって、前記代表ゲスト端末が前記スマートロックの解錠を要求したときに参照される認証情報と、前記認証情報に対する前記代表ゲスト端末の署名および前記オーナー端末の署名とを、前記オーナー端末から受信し、前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記オーナー端末と前記代表ゲスト端末とを関連付けて記憶するとともに、前記代表ゲスト端末の認証情報と前記代表ゲスト端末とを関連付けて記憶し、前記スマートロックから、解錠を要求する前記代表ゲスト端末が送信した解錠要求を受信すると、当該代表ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該代表ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信することを特徴とする管理サーバとした。

　このような構成にすることで、管理サーバは、オーナーが承認した代表ゲスト端末を許可登録する。このため、代表ゲストは、自身の端末を用いて、スマートロックを解錠して入室ができるようになる。
　また、既存技術の招待ＵＲＬのようなスマートロックの合鍵は存在せず、合鍵が盗まれたり、第三者に渡ったりすることがなく、意図しない端末に解錠を許可することを防止できる。

　本発明によれば、招待するゲストの数が増えたり、招待の頻度が増加したりした場合であっても、オーナーによる招待の負担を軽減し、なりすましや意図しない第三者の招待を防止することが可能な認可システム、管理サーバ及び認可方法を提供することができる。

本実施形態に係る認可システムの全体構成を示す図である。本実施形態に係る端末の全体構成図である。本実施形態に係る管理サーバの全体構成図である。本実施形態に係る権限情報データベースのデータ構成図である。本実施形態に係るスマートロックの管理サーバへの登録処理を説明するためのシーケンス図である。本実施形態に係る子ゲスト端末の管理サーバへの登録準備処理を説明するためのシーケンス図である。本実施形態に係る代表ゲスト端末の管理サーバへの登録準備処理を説明するためのシーケンス図である。本実施形態に係る子ゲスト端末および代表ゲスト端末の管理サーバへの登録処理を説明するためのシーケンス図である。本実施形態に係る子ゲスト端末によるスマートロックの解錠処理を説明するためのシーケンス図である。本実施形態に係る子ゲストの追加登録処理を説明するためのシーケンス図である。本実施形態の変型例３に係る子ゲストの追加登録処理を説明するためのシーケンス図である。本実施形態の変型例５に係る子ゲスト端末の管理サーバへの登録処理を説明するためのシーケンス図である。本実施形態の変型例５に係る子ゲスト端末の追加登録処理を説明するためのシーケンス図である。

≪認可システムの全体構成≫
　以下に本発明を実施するための形態（実施形態）における認可システムを説明する。図１は、本実施形態に係る認可システム１０の全体構成を示す図である。認可システム１０は、ネットワーク５００で接続されるスマートロック４００、スマートロック４００のオーナー（管理者）の端末であるオーナー端末１０１、代表ゲストの端末である代表ゲスト端末１０２、子ゲストの端末である子ゲスト端末１０３、および管理サーバ２００を含んで構成される。認可システム１０は、暗号鍵を管理するために、認証局３００を利用する。

　なお、オーナー端末１０１、代表ゲスト端末１０２および子ゲスト端末１０３を総称して端末（後記する図２に示す端末１００）とも記す。また、オーナー端末１０１、代表ゲスト端末１０２、子ゲスト端末１０３、およびスマートロック４００は、相互に近距離無線で通信可能である。代表的な近距離無線通信としてBluetooth（登録商標）やＮＦＣ（Near Field Communication）、赤外線通信などがある。
　端末およびスマートロック４００と管理サーバ２００との通信は保護されており、通信データの盗聴や改竄、なりすましは発生しない。同様に、近距離無線通信は保護されており、通信データの盗聴や改竄、なりすましは発生しない。

≪認可システムの概要≫
　以下では、認可システム１０の概要を説明する。スマートロック４００は、玄関や部屋のドアに設置された鍵である。スマートロック４００のオーナーが、代表ゲストや子ゲストの部屋への入室を許可すると、代表ゲストや子ゲストの端末に係る情報が管理サーバ２００に登録される。登録されると、代表ゲストや子ゲストが、入室可能になる。なお、オーナーが代表ゲストや子ゲストを登録することを、代表ゲストや子ゲストを招待するとも言う。

　代表ゲストや子ゲストが入室するときには、自身の端末に指示してスマートロック４００を解錠するように認証を要求する。端末に係る情報が管理サーバ２００に登録されていれば、スマートロック４００が代表ゲスト端末１０２や子ゲスト端末１０３の認証に成功して解錠し、代表ゲストや子ゲストが入室できるようになる。
　オーナーが代表ゲストの入室を許可するときには、オーナーと代表ゲストとが対面し、オーナー端末１０１と代表ゲスト端末１０２とが近距離無線で通信して、代表ゲスト端末１０２に係る情報が管理サーバ２００に登録される。

　子ゲストは、代表ゲストを介して、入室を許可される。詳しくは、代表ゲストは、子ゲストと対面し、代表ゲスト端末１０２と子ゲスト端末１０３とが近距離無線で通信して、子ゲスト端末１０３に係る情報が、代表ゲスト端末１０２に記憶される。続いて、代表ゲストは、オーナーと対面し、オーナー端末１０１と代表ゲスト端末１０２とが近距離無線で通信して、オーナー端末１０１により子ゲスト端末１０３に係る情報が管理サーバ２００に登録される。
　また、許可トークンを利用することで、代表ゲストがオーナーに対面することなく、代表ゲスト端末１０２により子ゲスト端末１０３に係る情報が管理サーバ２００に登録される。

　上記に説明したように、子ゲストそれぞれがオーナーから入室許可を得るのではなく、代表ゲストが子ゲストを代表して、子ゲストの入室許可を得る。このようにすることで、オーナーは個々の子ゲストに対面しなくても入室許可を与えることができ、オーナーの負担が削減される。代表ゲストは、複数の子ゲストの入室許可をまとめて得ることもでき、オーナーおよび代表ゲストの双方の負担が削減される。また、許可トークンを利用すれば、代表ゲストは、オーナーに対面不要で子ゲスト端末１０３を登録でき、オーナーおよび代表ゲストの双方の負担が削減される。

　以下では、端末の構成や管理サーバ２００の構成、端末や管理サーバ２００、スマートロック４００間のデータ通信を説明することで、入室許可（解錠の許可登録、子ゲストや代表ゲストの招待）や解錠がいかにして行われるかを説明する。

≪端末の構成≫
　図２は、本実施形態に係る端末１００の全体構成図である。端末１００は、例えばスマートフォンやタブレット端末などの携帯型コンピュータであって、制御部１１０、記憶部１２０、タッチパネルディスプレイ１８１、および通信部１８２を含んで構成される。

　制御部１１０は、ＣＰＵ（Central Processing Unit）から構成され、管理サーバ２００や他の端末１００との通信、データに対する暗号化や復号、署名、署名検証など、さまざまな処理を実行して、端末１００を認可システム１０の端末として機能させる。タッチパネルディスプレイ１８１は、端末に備わる表示部であり、かつ、利用者であるオーナー、代表ゲスト、子ゲストの操作を受け付ける。通信部１８２は、携帯電話通信や近距離無線通信のデータ送受信を行う。

　記憶部１２０は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、フラッシュメモリなどから構成される。記憶部１２０は、制御部１１０が実行するプログラム、プログラム実行に必要な一時的なデータの他に、電子証明書１３１、認証局公開鍵１３２、ロック用秘密鍵１４１、ロック用公開鍵１４２、管理用秘密鍵１５１、管理用公開鍵１５２を記憶する。

　電子証明書１３１は、認証局３００が端末１００に対して発行した電子証明書であって、電子証明書１３１に含まれる公開鍵が端末１００の公開鍵であることを証明する。電子証明書１３１は、制御部１１０が、秘密鍵を用いて署名した署名（デジタル署名）を検証するときに参照される。電子証明書１３１は、制御部１１０が生成した署名とともに、他の端末１００や管理サーバ２００、スマートロック４００に送信される。署名と電子証明書１３１を受信した端末１００や管理サーバ２００は、電子証明書１３１に付与された認証局３００の署名を、認証局公開鍵１３２を用いて検証して、端末１００の公開鍵を取得し、この公開鍵を用いて署名を検証する。

　なお、電子証明書１３１に付与されている認証局３００の署名を検証することを、単に電子証明書１３１を検証するとも記す。また、電子証明書１３１を検証して、電子証明書１３１の公開鍵を用いて署名を検証することを、電子証明書１３１の検証を省略して、単に署名を検証するとも記す。
　認証局公開鍵１３２は、電子証明書１３１の検証に用いられる認証局３００の公開鍵である。なお、オーナー端末１０１に対しては電子証明書１３１が発行されず、オーナー端末１０１には、電子証明書１３１が存在しない。

　ロック用秘密鍵１４１とロック用公開鍵１４２とは、公開鍵暗号のペアとなる鍵であって、スマートロック４００が解錠される際の、スマートロック４００による端末１００の認証に用いられる。
　管理用秘密鍵１５１と管理用公開鍵１５２とは、公開鍵暗号のペアとなる鍵であって、ロック用公開鍵１４２への署名や管理サーバ２００へ送信するデータの署名や署名検証に用いられる。
　なお、ロック用秘密鍵１４１および管理用秘密鍵１５１は、署名生成に用いられる暗号鍵であり、高い機密性が求められる。このため、ロック用秘密鍵１４１および管理用秘密鍵１５１を耐タンパ性のあるデバイスに記憶するようにしてもよい。

　電子証明書１３１に含まれる公開鍵は、管理用公開鍵１５２である。電子証明書１３１を取得するときには、制御部１１０は、管理用秘密鍵１５１と管理用公開鍵１５２とを生成し、管理用公開鍵１５２を認証局３００に送信して電子証明書１３１を要求する。認証局３００は、端末１００または端末１００の利用者を認証したのちに、認証局３００の署名を付与した電子証明書１３１を発行して、端末１００に送信する。

≪管理サーバの構成≫
　図３は、本実施形態に係る管理サーバ２００の全体構成図である。管理サーバ２００はコンピュータであって、ＣＰＵから構成される制御部２１０、ＲＡＭやＳＳＤ（Solid State Drive）、ハードディスクドライブから構成される記憶部２２０、および通信部２８０から構成される。通信部２８０は、ネットワーク５００を介して端末１００やスマートロック４００と通信データを送受信する。

　記憶部２２０は、制御部２１０が実行するプログラム、プログラム実行に必要な一時的なデータの他に、認証局公開鍵２３２、後記する権限情報データベース２４０（図３では権限情報ＤＢ（Database）と記載、後記する図４参照）を記憶する。認証局公開鍵２３２は、認証局３００の公開鍵であって、管理サーバ２００が受信した電子証明書の検証に用いられる。

≪権限情報データベース≫
　図４は、本実施形態に係る権限情報データベース２４０のデータ構成図である。権限情報データベース２４０は、オーナー識別情報２４１（図４ではオーナーＩＤ（Identifier）と記載）や管理用公開鍵２４２、入室情報２４３、代表ゲスト情報２５０、子ゲスト情報２６０を関連付けて記憶する。権限情報データベース２４０は、電子証明書２５４，２６５やロック用公開鍵２５１，２６１、入室情報２４３のなかのスマートロック識別情報を高速に検索するためのインデックス情報を記憶するが、図４には記載していない。

　オーナー識別情報２４１は、スマートロック４００のオーナーを識別するための情報である。権限情報データベース２４０には、１つ以上のオーナー識別情報２４１が記憶される。
　管理用公開鍵２４２は、オーナー識別情報２４１に関連付けられ、オーナー識別情報２４１で識別されるオーナーのオーナー端末１０１に記憶される管理用公開鍵１５２である。１人のオーナーが複数のオーナー端末１０１を所持し、オーナー識別情報２４１に複数の管理用公開鍵２４２が関連付けられる場合も存在する。以下では、管理用公開鍵２４２は１つとして説明する。

　入室情報２４３は、管理用公開鍵２４２に関連付けられて記憶される情報であって、スマートロック４００に係る識別情報（スマートロック識別情報）やスマートロック４００を解錠する条件（解錠条件とも記す）などの情報を含む。解錠条件とは、親ゲストや子ゲストの入室が許可された期間や曜日、時間帯などの情報である。
　オーナーが複数のスマートロック４００を保有し、管理用公開鍵２４２に複数の入室情報２４３が関連付けられる場合も存在する。以下では、入室情報２４３は１つとして説明する。

　代表ゲスト情報２５０は、入室情報２４３に関連付けられて記憶される情報である。１つの入室情報２４３に対して、１つ以上の代表ゲスト情報２５０が関連付けられる。代表ゲスト情報２５０には、ロック用公開鍵２５１、電子証明書２５４、利用権限２５５、および許可トークン２５６が含まれる。

　ロック用公開鍵２５１は、代表ゲスト端末１０２に記憶されるロック用公開鍵１４２であって、代表ゲストの署名２５２、オーナーの署名２５３が付与されている。代表ゲストの署名２５２は、ロック用公開鍵２５１に対する署名であって、代表ゲスト端末１０２が記憶する管理用秘密鍵１５１を用いて生成された署名である。代表ゲストの署名２５２は、後記する電子証明書２５４に含まれる公開鍵を用いて検証される。
　オーナーの署名２５３は、ロック用公開鍵２５１および代表ゲストの署名２５２に対する署名であって、オーナー端末１０１が記憶する管理用秘密鍵１５１を用いて生成された署名である。オーナーの署名２５３は、管理用公開鍵２４２を用いて検証される。

　電子証明書２５４は、代表ゲスト端末１０２が記憶する電子証明書１３１であって、代表ゲストの署名２５２の検証に用いられる。他に、スマートロック４００の解錠時における代表ゲスト端末１０２の認証にも用いられる。
　利用権限２５５は、代表ゲストに許可されたスマートロック４００に対する権限であって、例えば、入室する部屋の識別情報や入室可能時間などを含む。

　許可トークン２５６は、オーナーが認可した代表ゲストの権限であって、オーナーの署名２５７が付与される。代表ゲストの権限としては、子ゲストの登録や登録削除がある。
　オーナーの署名２５７は、許可トークン２５６に対する署名であって、オーナー端末１０１が記憶する管理用秘密鍵１５１を用いて生成された署名である。オーナーの署名２５７は、管理用公開鍵２４２を用いて検証される。

　子ゲスト情報２６０は、代表ゲスト情報２５０に関連付けられて記憶される情報である。１つの代表ゲスト情報２５０に対して、１つ以上の子ゲスト情報２６０が関連付けられる。子ゲスト情報２６０には、ロック用公開鍵２６１、電子証明書２６５および利用権限２６６が含まれる。

　ロック用公開鍵２６１は、子ゲスト端末１０３に記憶されるロック用公開鍵１４２であって、子ゲストの署名２６２、代表ゲストの署名２６３、オーナーの署名２６４が付与されている。
　子ゲストの署名２６２は、ロック用公開鍵２６１に対する署名であって、子ゲスト端末１０３が記憶する管理用秘密鍵１５１を用いて生成された署名である。子ゲストの署名２６２は、後記する電子証明書２６５に含まれる公開鍵を用いて検証される。

　代表ゲストの署名２６３は、ロック用公開鍵２６１および子ゲストの署名２６２に対する署名であって、代表ゲスト端末１０２が記憶する管理用秘密鍵１５１を用いて生成された署名である。代表ゲストの署名２６３は、代表ゲスト情報２５０にある電子証明書２５４に含まれる公開鍵を用いて検証される。
　オーナーの署名２６４は、ロック用公開鍵２６１、子ゲストの署名２６２および代表ゲストの署名２６３に対する署名であって、オーナー端末１０１が記憶する管理用秘密鍵１５１を用いて生成された署名である。オーナーの署名２６４は、管理用公開鍵２４２を用いて検証される。

　電子証明書２６５は、子ゲスト端末１０３が記憶する電子証明書１３１であって、子ゲストの署名２６２の検証に用いられる。他に、スマートロック４００の解錠時における子ゲスト端末１０３の認証にも用いられる。
　利用権限２６６は、子ゲストに許可されたスマートロック４００に対する権限であって、例えば、入室する部屋の識別情報や入室可能時間などを含む。

　代表ゲスト情報２５０および子ゲスト情報２６０には、ロック用公開鍵２５１，２６１、電子証明書２５４，２６５が含まれており、代表ゲスト端末１０２および子ゲスト端末１０３が生成した署名を検証するときに参照される。また、ロック用公開鍵２５１，２６１、電子証明書２５４，２６５は、スマートロック４００の解錠の際、管理サーバ２００が代表ゲスト端末１０２および子ゲスト端末１０３を認証するときに、認証情報として参照される。

≪スマートロック登録処理≫
　以下では、スマートロック登録処理、子ゲスト端末の登録準備処理、代表ゲスト端末の登録準備処理、ゲスト端末の登録処理、スマートロックの解錠処理、子ゲストの追加登録処理を説明する。処理中には署名検証があるが、以下の説明では、署名検証が成功し、署名対象の真正性が確認できたとして説明する。署名検証に失敗した場合には、署名を送信した端末にエラーを通知し、処理を中止する。

　図５は、本実施形態に係るスマートロック４００の管理サーバ２００への登録処理を説明するためのシーケンス図である。スマートロック登録処理は、オーナーがスマートロック４００とオーナーとを管理サーバ２００に登録する処理である。
　ステップＳ１０１において、オーナー端末１０１は、管理用秘密鍵１５１および管理用公開鍵１５２のペアを生成する。

　ステップＳ１０２において、オーナー端末１０１は、オーナー識別情報、スマートロック識別情報、およびステップＳ１０１で生成した管理用公開鍵１５２を管理サーバ２００へ送信して、スマートロック４００の登録を申請する。ここで、オーナー端末１０１と管理サーバ２００との通信は、保護されており、通信データの改竄やなりすましなどは発生しない。

　ステップＳ１０３において、管理サーバ２００は、受信したオーナー識別情報および管理用公開鍵１５２を、それぞれ権限情報データベース２４０のオーナー識別情報２４１および管理用公開鍵２４２として登録する。スマートロック識別情報については、入室情報２４３に登録する。

　オーナー端末１０１は、ステップＳ１０２において、スマートロック４００を設置したドアや部屋の情報を送信してもよい。管理サーバ２００は、ステップＳ１０３において、これらの情報を入室情報２４３に登録する。
　スマートロック登録処理が実行されることで、管理サーバ２００には、オーナー識別情報２４１と、オーナーの管理用公開鍵２４２と、スマートロックの情報とが関連付けられて記憶される。

≪子ゲスト端末の登録準備処理≫
　図６は、本実施形態に係る子ゲスト端末１０３の管理サーバ２００への登録準備処理を説明するためのシーケンス図である。子ゲスト端末１０３は、代表ゲスト端末１０２およびオーナー端末１０１を介して、管理サーバ２００に登録される。子ゲスト端末１０３の登録準備処理（子ゲストの招待準備処理）では、子ゲスト端末１０３の情報が代表ゲスト端末１０２に送信され、さらにオーナー端末１０１に送信される前の準備が実行される。

　ステップＳ１１１において、代表ゲスト端末１０２は、認証局３００から電子証明書１３１（図２参照）を取得する。取得の手順は、図２に記載の管理用秘密鍵１５１と管理用公開鍵１５２の記載で説明した。
　ステップＳ１１２において、子ゲスト端末１０３は、認証局３００から電子証明書１３１を取得する。

　ステップＳ１１３において、子ゲスト端末１０３は、ロック用秘密鍵１４１およびロック用公開鍵１４２のペアを生成する。
　ステップＳ１１４において、子ゲスト端末１０３は、ロック用公開鍵１４２に管理用秘密鍵１５１を用いて署名する。

　以下では、子ゲストは代表ゲストと対面していて、子ゲスト端末１０３と代表ゲスト端末１０２とが近距離無線で通信可能として説明を続ける。
　ステップＳ１１５において、子ゲスト端末１０３は、子ゲストの情報、子ゲスト端末１０３の電子証明書１３１、およびステップＳ１１４で生成した署名付ロック用公開鍵を近距離無線通信で代表ゲスト端末１０２に送信して、登録を要求する。子ゲストの情報は、子ゲストの名前、子ゲスト端末１０３の識別情報などを含む。ロック用公開鍵１４２や電子証明書１３１は、スマートロック４００の解錠時の子ゲスト端末１０３を認証するための認証情報として用いられる。

　ステップＳ１１６において、代表ゲスト端末１０２は、受信した署名付ロック用公開鍵の署名を検証する。詳しくは、代表ゲスト端末１０２は、受信した子ゲスト端末１０３の電子証明書１３１の署名を、認証局公開鍵１３２を用いて検証して、子ゲスト端末１０３の管理用公開鍵１５２を取得する。続いて、代表ゲスト端末１０２は、取得した子ゲスト端末１０３の管理用公開鍵１５２を用いて、受信した署名付ロック用公開鍵の署名を検証する。これにより、代表ゲスト端末１０２は、子ゲスト端末１０３の真正なロック用公開鍵１４２を取得したことになる。

≪代表ゲスト端末の登録準備処理≫
　図７は、本実施形態に係る代表ゲスト端末１０２の管理サーバ２００への登録準備処理を説明するためのシーケンス図である。子ゲスト端末１０３と代表ゲスト端末１０２とは、オーナー端末１０１を介して、管理サーバ２００に登録される。代表ゲスト端末１０２の登録準備処理（代表ゲストの招待準備処理）では、子ゲスト端末１０３および代表ゲスト端末１０２の情報がオーナー端末１０１に送信される。

　ステップＳ１２１において、代表ゲスト端末１０２は、ロック用秘密鍵１４１およびロック用公開鍵１４２のペアを生成する。
　ステップＳ１２２において、代表ゲスト端末１０２は、ロック用公開鍵１４２に管理用秘密鍵１５１を用いて署名する。

　ステップＳ１２３において、代表ゲスト端末１０２は、子ゲスト端末１０３から受信した署名付ロック用公開鍵に管理用秘密鍵１５１を用いて署名する。子ゲスト端末１０３のロック用公開鍵１４２は、子ゲスト端末１０３に署名され、さらに代表ゲスト端末１０２に署名されて、２重に署名されている。以下では、ステップＳ１２２で生成された代表ゲスト端末１０２の署名付ロック用公開鍵と、ステップＳ１２３で生成された２重署名付ロック用公開鍵とを合わせて、署名付ロック用公開鍵群と記す。

　以下では、代表ゲストはオーナーと対面していて、代表ゲスト端末１０２とオーナー端末１０１とが近距離無線で通信可能として説明を続ける。
　ステップＳ１２４において、代表ゲスト端末１０２は、子ゲストの情報、代表ゲストの情報、子ゲスト端末１０３の電子証明書１３１、代表ゲスト端末１０２の電子証明書１３１および署名付ロック用公開鍵群を近距離無線通信でオーナー端末１０１に送信して、登録（許可登録）を要求する。代表ゲストの情報は、代表ゲストの名前、代表ゲスト端末１０２の識別情報などを含む。電子証明書１３１や、署名付ロック用公開鍵群に含まれる子ゲスト端末１０３および代表ゲスト端末１０２のロック用公開鍵１４２は、スマートロック４００の解錠時の子ゲスト端末１０３を認証するための認証情報として用いられる。

　ステップＳ１２５において、オーナー端末１０１は、受信した署名付ロック用公開鍵群の署名を検証する。詳しくは、オーナー端末１０１は、受信した子ゲスト端末１０３の電子証明書１３１および代表ゲスト端末１０２の電子証明書１３１の署名を、認証局公開鍵１３２を用いて検証して、子ゲスト端末１０３の管理用公開鍵１５２および代表ゲスト端末１０２の管理用公開鍵１５２を取得する。続いて、オーナー端末１０１は、取得した子ゲスト端末１０３の管理用公開鍵１５２および代表ゲスト端末１０２の管理用公開鍵１５２を用いて、受信した署名付ロック用公開鍵群の署名を検証する。これにより、オーナー端末１０１は、子ゲスト端末１０３および代表ゲスト端末１０２の真正なロック用公開鍵１４２を取得したことになる。

≪ゲスト端末の登録処理≫
　図８は、本実施形態に係る子ゲスト端末１０３および代表ゲスト端末１０２（ゲスト端末とも記す）の管理サーバ２００への登録処理を説明するためのシーケンス図である。子ゲスト端末１０３の登録準備処理（図６参照）および代表ゲスト端末１０２の登録準備処理（図７参照）により、オーナー端末１０１は、子ゲスト端末１０３および代表ゲスト端末１０２の真正なロック用公開鍵１４２を取得している。ゲスト端末の登録処理（ゲストの招待処理）では、オーナー端末１０１は、子ゲストの情報や親ゲストの情報とともに、このロック用公開鍵１４２を管理サーバ２００に送信して登録を要求する。
　以下では、オーナー端末１０１が、子ゲストや代表ゲストの情報を表示してゲスト端末の登録要求の確認をオーナーに求め、オーナーが確認して登録を指示したとして説明を続ける。

　ステップＳ１３１において、オーナー端末１０１は、代表ゲストに認可する認可権限を示す許可トークンを生成する。許可トークンには、認可権限を与えるオーナー端末１０１の識別情報、認可権限を取得する代表ゲスト端末１０２の識別情報、認可権限、認可権限の有効期間などを含む。認可権限としては、子ゲストの追加や子ゲストの削除がある。
　ステップＳ１３２において、オーナー端末１０１は、管理用秘密鍵１５１を用いて許可トークンに署名する。

　ステップＳ１３３において、オーナー端末１０１は、管理用秘密鍵１５１を用いて、代表ゲスト端末１０２から受信した署名付ロック用公開鍵群に署名する。子ゲスト端末１０３のロック用公開鍵１４２には、子ゲスト端末１０３の署名と、代表ゲスト端末１０２の署名と、オーナー端末１０１の署名とが付与されており、３重に署名されている。代表ゲスト端末１０２のロック用公開鍵１４２には、代表ゲスト端末１０２の署名と、オーナー端末１０１の署名とが付与されており、２重に署名されている。

　ステップＳ１３４において、オーナー端末１０１は、入室情報、子ゲストの情報、代表ゲストの情報、オーナーの署名付の署名付ロック用公開鍵群、オーナーの署名付許可トークン、子ゲスト端末１０３の電子証明書１３１および代表ゲスト端末１０２の電子証明書１３１を管理サーバ２００に送信して、登録を要求する。入室情報は、スマートロック４００の識別情報や、オーナーが許可した親ゲストや子ゲストが入室可能な期間、曜日、時間帯などの情報を含む。

　ステップＳ１３５において、管理サーバ２００は、オーナーの署名付許可トークンの署名を検証する。検証には、管理用公開鍵２４２（図４参照）を用いる。
　ステップＳ１３６において、管理サーバ２００は、オーナーの署名付の署名付ロック用公開鍵群の署名を検証する。オーナーの署名付の署名付ロック用公開鍵群には、オーナー端末１０１による署名、代表ゲスト端末１０２による署名、子ゲスト端末１０３による署名が含まれており、管理サーバ２００は、それぞれ管理用公開鍵２４２、代表ゲスト端末１０２の管理用公開鍵１５２、子ゲスト端末１０３の管理用公開鍵１５２を用いて検証する。管理サーバ２００は、受信した代表ゲスト端末１０２および子ゲスト端末１０３の電子証明書１３１の署名を、認証局公開鍵２３２を用いて検証して、代表ゲスト端末１０２および子ゲスト端末１０３の管理用公開鍵１５２を取得する。電子証明書１３１の署名を検証することで、管理サーバ２００は、真正な代表ゲスト端末１０２および子ゲスト端末１０３の管理用公開鍵１５２を取得できる。

　ステップＳ１３７において、管理サーバ２００は、取得した情報を権限情報データベース２４０（図４参照）に格納する。詳しくは、受信した入室情報に含まれるスマートロック識別情報を含む権限情報データベース２４０の入室情報２４３に関連付けて代表ゲスト情報２５０を作成し、代表ゲストに係る情報を代表ゲスト情報２５０に格納する。詳しくは、管理サーバ２００は、受信したオーナーの署名付許可トークンを、許可トークン２５６およびオーナーの署名２５７に格納する。また、管理サーバ２００は、受信したオーナーの署名付の署名付ロック用公開鍵群に含まれる代表ゲスト端末１０２のロック用公開鍵１４２および署名を、ロック用公開鍵２５１、代表ゲストの署名２５２およびオーナーの署名２５３に格納する。管理サーバ２００は、受信した代表ゲスト端末１０２の電子証明書１３１を電子証明書２５４に格納する。また、管理サーバ２００は、受信した代表ゲストの情報や入室情報に含まれる、代表ゲストの入室可能な期間などの情報を利用権限２５５に格納する。

　子ゲスト情報２６０についても同様である。詳しくは、管理サーバ２００は、代表ゲスト情報２５０に関連付けて子ゲスト情報２６０を作成する。続いて、管理サーバ２００は、子ゲスト端末１０３のロック用公開鍵と付与された３重の署名をロック用公開鍵２６１と子ゲストの署名２６２と代表ゲストの署名２６３とオーナーの署名２６４とに格納し、電子証明書と、子ゲストの情報および入室情報とを、それぞれ電子証明書２６５と、利用権限２６６とに格納する。

　代表ゲスト情報２５０および子ゲスト情報２６０に登録されたロック用公開鍵２５１，２６１や電子証明書２５４，２６５は、管理サーバ２００が、代表ゲスト端末１０２が生成した署名を検証するときや、スマートロック４００の解錠の際、代表ゲスト端末１０２および子ゲスト端末１０３を認証するときの認証情報として参照される。

　図６から図８で説明した、子ゲスト端末の登録準備処理、代表ゲスト端末の登録準備処理、ゲスト端末の登録処理をとおして、子ゲスト端末１０３および代表ゲスト端末１０２のロック用公開鍵１４２，２５１，２６１や電子証明書１３１，２５４，２６５、利用権限２５５，２６６が管理サーバ２００に登録された。これらの情報を用いて、管理サーバ２００が、子ゲスト端末１０３や代表ゲスト端末１０２を認証した後に、スマートロック４００が解錠される。

≪スマートロックの解錠処理≫
　図９は、本実施形態に係る子ゲスト端末１０３によるスマートロック４００の解錠処理を説明するためのシーケンス図である。子ゲストは、スマートロック４００が設置されたドアに近づき、子ゲスト端末１０３に解錠するように指示した後の処理を説明する。
　ステップＳ２０１において、子ゲスト端末１０３は、スマートロック４００に認証要求を送信する。

　ステップＳ２０２において、スマートロック４００は、乱数を生成し、チャレンジとして子ゲスト端末１０３に送信する。
　ステップＳ２０３において、子ゲスト端末１０３は、受信したチャレンジにロック用秘密鍵１４１を用いて署名する。
　ステップＳ２０４において、子ゲスト端末１０３は、署名付チャレンジと電子証明書１３１をスマートロック４００に送信する。

　ステップＳ２０５において、スマートロック４００は、自身のスマートロック識別情報、受信した電子証明書、受信した署名付チャレンジを管理サーバ２００に送信する。
　ステップＳ２０６において、管理サーバ２００は、署名付チャレンジの署名を検証する。詳しくは、管理サーバ２００は、権限情報データベース２４０のなかの入室情報２４３であって、スマートロック識別情報を含む入室情報２４３を検索する。続いて、管理サーバ２００は、検索結果の入室情報に関連付けられた代表ゲスト情報２５０および子ゲスト情報２６０のなかで、受信した電子証明書に一致する電子証明書２５４，２６５を検索する。次に、管理サーバ２００は、検索結果の代表ゲスト情報２５０または子ゲスト情報２６０に含まれるロック用公開鍵２５１，２６１を用いて署名付チャレンジの署名を検証する。管理サーバ２００は、入室情報２４３の検索、電子証明書２５４，２６５の検索、署名の検証の何れかに失敗したときは、認証は失敗と判断する。

　ステップＳ２０７において、管理サーバ２００は、利用権限を照合する。詳しくは、管理サーバ２００は、ステップＳ２０６で検索した代表ゲスト情報２５０または子ゲスト情報２６０に含まれる利用権限２５５，２６６と照合する。利用権限２５５，２６６には、入室が許可される期間や時間帯などの条件が含まれており、管理サーバ２００は、条件に合致しない場合は、認証は失敗と判断する。
　ステップＳ２０８において、管理サーバ２００は、認証結果をスマートロック４００に送信する。詳しくは、ステップＳ２０６，Ｓ２０７の何れかで認証失敗ならば、認証失敗を送信し、そうでなければ認証成功を送信する。

　ステップＳ２０９において、スマートロック４００は、受信した認証結果に応じて解錠する。詳しくは、スマートロック４００は、認証成功ならば解錠し、認証失敗ならば解錠しない。

≪子ゲストの追加登録処理≫
　図６～図８の処理において、代表ゲストとオーナーとが対面して、代表ゲストと子ゲストとが登録（招待）されている。代表ゲストが登録され後は、代表ゲストは、オーナーに対面することなく、子ゲストを登録することができるようになる。

　図１０は、本実施形態に係る子ゲストの追加登録処理を説明するためのシーケンス図である。以下では、追加される子ゲスト端末１０３の登録準備処理（図６参照）は終えているとして、その後の処理を説明する。
　ステップＳ３０１において、代表ゲスト端末１０２は、子ゲスト端末１０３から受信した署名付ロック用公開鍵に管理用秘密鍵１５１を用いて署名する。
　ステップＳ３０２において、代表ゲスト端末１０２は、オーナー識別情報、入室情報、子ゲストの情報、代表ゲストの署名付の署名付ロック用公開鍵、子ゲスト端末１０３の電子証明書１３１を、管理サーバ２００に送信して、登録を要求する。

　ステップＳ３０３において、管理サーバ２００は、代表ゲストに子ゲストの追加権限があることを確認する。詳しくは、管理サーバ２００は、権限情報データベース２４０（図４参照）の代表ゲスト情報２５０に含まれる許可トークン２５６を参照して確認する。
　ステップＳ３０４において、管理サーバ２００は、受信した代表ゲストの署名付の署名付ロック用公開鍵に含まれる署名を検証する。代表ゲスト端末１０２の署名の検証には、代表ゲスト端末１０２に対応する代表ゲスト情報２５０に含まれる電子証明書２５４を用いる。また、子ゲスト端末１０３の署名の検証には、受信した子ゲスト端末１０３の電子証明書を用いる。

　ステップＳ３０５において、管理サーバ２００は、入室情報、子ゲストの情報、代表ゲストの情報をオーナー端末１０１に送信する。代表ゲストの情報は、権限情報データベース２４０から取得する。
　ステップＳ３０６において、オーナー端末１０１は、受信した入室情報、子ゲストの情報、代表ゲストの情報を表示して、オーナーに子ゲストの追加登録を承認するか問い合わせて、承認結果を取得する。

　ステップＳ３０７において、オーナー端末１０１は、取得した承認結果（承認可または承認否）を管理サーバ２００に送信する。
　ステップＳ３０８において、管理サーバ２００は、受信した承認結果が承認可ならば、子ゲスト端末１０３を権限情報データベース２４０に登録する。登録する処理は、ステップＳ１３７（図８参照）と同様である。代表ゲスト端末１０２の情報は登録済みであり、登録不要である。承認否ならば、管理サーバ２００は、登録しない。

　ステップＳ３０９において、管理サーバ２００は、承認結果を代表ゲスト端末１０２に送信する。
≪認可システムの特徴≫
　上記した実施形態では、子ゲストは、代表ゲストを介して、登録（招待）される。詳しくは、代表ゲストが対面して確認した子ゲストを、オーナーが代表ゲストと対面して確認してから登録している。このため、オーナーは、子ゲストを個々に対面して、確認してから登録する必要はなくなり、登録の負担が削減される。

　代表ゲストが登録されると、代表ゲストは入室可能になるだけではなく、子ゲストの追加権限が与えられる（図４記載の許可トークン２５６、図８記載のステップＳ１３１参照）。権限が与えられたのちは、代表ゲストは、オーナーに対面することなく、子ゲストの追加を申請（許可登録の要求）すること（図１０記載のステップＳ３０２参照）ができ、オーナーは申請を承認することができる（ステップＳ３０６参照）。このため、代表ゲストおよびオーナーの負担が削減される。

　子ゲスト端末１０３の登録準備処理（図６参照）では、代表ゲストは子ゲストに対面しており、子ゲストの本人確認が容易になり、なりすましを防止している。また、代表ゲスト端末１０２の登録準備処理（図７参照）では、オーナーは代表ゲストに対面しており、代表ゲストの本人確認が容易になり、なりすましを防止している。

　認可システム１０におけるスマートロック４００の解錠には、ゲスト端末に合鍵（招待ＵＲＬ）を渡すのではなく、公開鍵暗号をベースとしたデジタル署名技術を採用して、ゲスト端末を認証している。このため、合鍵が意図しない第三者に渡ることがなく、オーナーが招待または承認したゲストだけが入室可能であり、第三者の入室を防止できる。

≪変型例１：複数の子ゲスト端末≫
　上記の実施形態では、１つの子ゲスト端末１０３を管理サーバ２００に登録（招待）している。複数の子ゲスト端末１０３をまとめて登録するようにしてもよい。詳しくは、代表ゲスト端末１０２が、複数の子ゲスト端末１０３から署名付ロック用公開鍵を受信し、ステップＳ１２３（図７参照）において、複数の署名付ロック用公開鍵をまとめてオーナー端末１０１に送信する。オーナー端末１０１は、複数の署名付ロック用公開鍵をまとめて管理サーバ２００に送信して登録する。

　このようにすることで、個々の子ゲストと対面するというオーナーの負担が削減される。
　子ゲスト端末１０３の追加登録においても同様であり、ステップＳ３０２（図１０参照）において、代表ゲスト端末１０２が、複数の署名付ロック用公開鍵をまとめて管理サーバ２００に送信するようにしてもよい。

≪変型例２：追加登録時の入室情報≫
　子ゲスト追加時の入室情報（入室可能期間など、図１０のステップＳ３０２参照）は、代表ゲストが決定している。これに替えて、オーナーが承認する際に、オーナーが決定するようにしてもよいし、代表ゲストが送信した入室情報をオーナーが修正して承認するようにしてもよい。この場合の入室情報は、ステップＳ３０７においてオーナー端末１０１から管理サーバ２００に送信され、ステップＳ３０８において権限情報データベース２４０に登録される。

≪変型例３：オーナー承認なしの子ゲスト追加登録≫
　上記した実施形態では、オーナーの承認後に子ゲストが追加登録される。オーナーの承認なしに追加登録され、その後にオーナーが追加登録をキャンセルするようにしてもよい。
　図１１は、本実施形態の変型例３に係る子ゲストの追加登録処理を説明するためのシーケンス図である。図１１は、図１０に替わる処理である。

　ステップＳ３１１～Ｓ３１４は、ステップＳ３０１～Ｓ３０４と同様の処理である。
　ステップＳ３１５において、管理サーバ２００は、子ゲスト端末１０３を権限情報データベース２４０に登録する。登録する処理は、ステップＳ１３７（図８参照）と同様である。

　ステップＳ３１６において、管理サーバ２００は、入室情報、子ゲストの情報、代表ゲストの情報をオーナー端末１０１に送信する。代表ゲストの情報は、権限情報データベース２４０から取得する。
　ステップＳ３１７において、オーナー端末１０１は、受信した入室情報、子ゲストの情報、代表ゲストの情報を表示して、オーナーに子ゲストの追加登録をキャンセルするか否かを問い合わせる。オーナーがキャンセル不要とした場合は、オーナー端末１０１は、その旨（キャンセル否）を管理サーバ２００に送信する。キャンセル不要ならば、管理サーバ２００での処理は不要であり、子ゲストの追加登録処理が終わる。以下では、オーナーがキャンセルを指示したとして説明を続ける。

　ステップＳ３１８において、オーナー端末１０１は、管理サーバ２００に子ゲストの追加登録のキャンセルを指示する（キャンセル可を送信する）。
　ステップＳ３１９において、管理サーバ２００は、ステップＳ３１５において登録した子ゲスト情報２６０を削除する。
　ステップＳ３２０において、管理サーバ２００は、キャンセルが完了したことをオーナー端末１０１に通知する。
　ステップＳ３２１において、管理サーバ２００は、子ゲスト追加登録がキャンセルされたことを代表ゲスト端末１０２に通知する。

≪変型例３の特徴≫
　変型例３では、オーナーの承認を待つことなく、代表ゲストは子ゲストを追加登録することができ、上記した実施形態より早く子ゲストを追加登録することができる。また、オーナーは、追加登録をキャンセルすることができる。

≪変型例４：子ゲストの登録削除≫
　図１０や図１１では、代表ゲストによる、オーナーとの対面なしの子ゲストの追加登録を説明した。これと同様に、代表ゲストによる、オーナーとの対面なしの登録済み子ゲストの削除も可能である。詳しくは、代表ゲスト端末１０２が管理サーバ２００に子ゲストの登録削除を申請する。次に、管理サーバ２００は、代表ゲストに子ゲスト削除の権限があるか許可トークン２５６を参照して判断し、権限があれば子ゲスト情報２６０を削除する。管理サーバ２００は、削除の前に、オーナーに確認するようにしてもよい。

≪変型例５：代表ゲスト端末経由の許可トークン≫
　上記した実施形態では、許可トークンを生成したオーナー端末１０１が、許可トークンを管理サーバ２００に送信している。これに替えて、代表ゲスト端末１０２を経由して許可トークンが管理サーバ２００に送信されるようにしてもよい。

　図１２は、本実施形態の変型例５に係る子ゲスト端末１０３の管理サーバ２００への登録処理を説明するためのシーケンス図である。図１２は、図８に替わる子ゲスト端末１０３の登録準備処理である。
　ステップＳ４０１～Ｓ４０２は、図８に記載のステップＳ１３１～Ｓ１３２と同様の処理である。
　ステップＳ４０３において、オーナー端末１０１は、署名付許可トークンを代表ゲスト端末１０２に送信する。

　ステップＳ４０４，Ｓ４０５，Ｓ４０６，Ｓ４０７は、それぞれステップＳ１３３，Ｓ１３４，Ｓ１３６，Ｓ１３７と同様の処理である。但し、ステップＳ４０５において、オーナー端末１０１は、署名付許可トークンを送信しない。また、ステップＳ４０７において、管理サーバ２００は、許可トークンを権限情報データベース２４０に登録しない。

　図１３は、本実施形態の変型例５に係る子ゲスト端末１０３の追加登録処理を説明するためのシーケンス図である。図１３は、図１０に替わる子ゲスト端末１０３の追加登録処理である。
　ステップＳ４１１～Ｓ４１２は、図１０に記載のＳ３０１～Ｓ３０２と同様の処理である。但し、ステップＳ４１２において、代表ゲスト端末１０２は、ステップＳ４０３でオーナー端末１０１から受信した署名付許可トークンを含めて管理サーバ２００に送信する。

　ステップＳ４１３は、図８に記載のステップＳ１３５と同様の処理である。許可トークンは、権限情報データベース２４０に登録される。
　ステップＳ４１４～Ｓ４２０は、図１０に記載のＳ３０３～Ｓ３０９と同様の処理である。

≪変型例６：管理サーバに送信時の認証≫
　ステップＳ１３４（図８参照）やステップＳ３０２（図１０参照）など、オーナー端末１０１や代表ゲスト端末１０２から管理サーバ２００に子ゲストの登録（招待）を要求するときには、生体認証技術を用いてオーナー端末１０１や代表ゲスト端末１０２の利用者を認証するようにしてもよい。このようにすることで、入室を許可することになる子ゲスト登録における信頼性を向上させることができる。

≪変型例７：近距離無線通信≫
　オーナーと代表ゲスト端末が対面して、オーナー端末１０１と代表ゲスト端末１０２とが通信するときには、近距離無線通信を利用していた。オーナー端末１０１と代表ゲスト端末１０２とがケーブルで直結して通信してもよい。

≪変型例８：署名検証の省略≫
　上記した実施形態のステップＳ１３６（図８参照）において、管理サーバ２００は、オーナーの署名付の署名付ロック用公開鍵群に付与されている、オーナー端末１０１による署名、代表ゲスト端末１０２による署名、子ゲスト端末１０３による署名を検証している。これに対して、代表ゲスト端末１０２による署名、子ゲスト端末１０３による署名はオーナー端末１０１が検証済みとして、オーナー端末１０１による署名のみを検証するようにしてもよい。こうすることで、管理サーバ２００は、登録要求の処理コストを下げることができる。

≪変型例９：子ゲスト端末の追加登録時のオーナー承認≫
　図１０に記載の子ゲスト端末の追加登録処理においては、オーナーの承認を得た後に子ゲスト端末を登録している。一方、図１１に記載の子ゲスト端末の追加登録処理においては、オーナーの承認を得る前に子ゲスト端末を登録し、後にオーナーが登録をキャンセルすることが可能となっている。認証トークンの子ゲスト端末の追加登録を、事前承認要の追加登録と事前承認不要の追加登録とに区別するようにしてもよい。こうすることで、オーナーが高く信頼する代表ゲストには、事前承認不要の追加登録権限を与え、そうではない代表ゲストには、事前承認要の追加登録権限を与えるようにできる。

≪変型例１０：代表ゲスト端末の登録≫
　上記した実施形態では、代表ゲスト端末１０２は子ゲスト端末１０３と一緒に、登録（招待）される。これに対して、代表ゲスト端末１０２が子ゲスト端末１０３の認証情報をオーナー端末１０１に送信せず、代表ゲスト端末１０２の認証情報と署名のみをオーナー端末１０１に送信して、代表ゲスト端末１０２単独で登録するようにしてもよい。これにより、子ゲスト端末１０３の登録なしに、代表ゲスト端末１０２が登録可能となる。

≪変型例１１：子ゲスト端末の登録制限≫
　上記した実施形態では、許可トークンを参照して、管理サーバ２００は、代表ゲスト端末１０２に子ゲスト端末１０３を追加する権限があることを確認していた。許可トークンが登録可能な期間や子ゲスト端末１０３の上限数を含むようにして、管理サーバ２００が、代表ゲスト端末１０２による登録可能な期間や子ゲスト端末１０３の数を制限するようにしてもよい。
　また、許可トークンに子ゲスト端末１０３が解錠可能な日時を含め、代表ゲスト端末１０２が登録した子ゲスト端末１０３の解錠可能な日時を制限できるようにしてもよい。解錠可能な日時は、子ゲスト情報２６０の利用権限２６６に記憶される（図４参照）。

≪変型例１２：端末間の通信≫
　上記した実施形態では、子ゲスト端末１０３は、近距離無線通信を利用して自身の認証情報を代表ゲスト端末１０２に送信していた。この他に、十分に本人確認ができるのであれば、他の安全な通信路を用いてもよい。代表ゲスト端末１０２が、自身の認証情報をオーナー端末１０１に送る場合も同様である。

≪変型例１３：権限情報データベースのデータ構造≫
　上記した実施形態における権限情報データベース２４０では、オーナー識別情報２４１および管理用公開鍵２４２、管理用公開鍵２４２および入室情報２４３、入室情報２４３および代表ゲスト情報２５０のそれぞれが関連付けられる。これに替えて、オーナー識別情報２４１と管理用公開鍵２４２と入室情報２４３とをまとめてオーナー端末１０１と見なして、代表ゲスト情報２５０と関連付けるなど、他のデータ構成にしてもよい。

≪その他の変型例≫
　以上、本発明の実施形態といくつかの変型例について説明したが、これらの実施形態や変型例は、例示に過ぎず、本発明の技術的範囲を限定するものではない。本発明はその他の様々な実施形態を取ることが可能であり、さらに、本発明の要旨を逸脱しない範囲で、省略や置換等種々の変更を行うことができる。これら実施形態やその変形は、本明細書等に記載された発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０　　認可システム
１００　端末
１０１　オーナー端末
１０２　代表ゲスト端末
１０３　子ゲスト端末
１４２，２６１　ロック用公開鍵
２００　管理サーバ
２５６　許可トークン
３００　認証局
４００　スマートロック

Claims

　スマートロック、前記スマートロックの管理者が利用するオーナー端末、子ゲストが利用し前記スマートロックの解錠を要求する子ゲスト端末、代表ゲストが利用し前記スマートロックの解錠を要求する代表ゲスト端末、および管理サーバを含む認可システムであって、
　前記代表ゲスト端末は、
　前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを、前記代表ゲスト端末による解錠の許可登録の要求として前記オーナー端末に送信し、
　前記オーナー端末は、
　前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、前記管理者による前記代表ゲスト端末に対する解錠の許可登録を承認する情報を受け付けた後に、前記代表ゲスト端末の認証情報に署名し、
　受信した前記解錠の許可登録の要求に含まれる情報と、前記代表ゲスト端末の認証情報に対する前記オーナー端末の署名とを、前記管理サーバに送信し、
　前記管理サーバは、
　前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記オーナー端末と前記代表ゲスト端末とを関連付けて記憶するとともに、前記代表ゲスト端末の認証情報と前記代表ゲスト端末とを関連付けて記憶し、
　前記スマートロックから、解錠を要求する前記代表ゲスト端末が送信した解錠要求を受信すると、当該代表ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該代表ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信し、
　前記スマートロックは、
　前記管理サーバが、前記解錠要求は前記代表ゲスト端末が送信した解錠要求であると判断した場合には解錠する
　ことを特徴とする認可システム。
　前記子ゲスト端末は、
　前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを前記代表ゲスト端末に送信し、
　前記代表ゲスト端末は、
　前記子ゲスト端末から受信した情報に含まれる署名の検証に成功した後に、前記子ゲスト端末の認証情報に署名し、
　前記代表ゲスト端末による解錠の許可登録の要求に加えて、前記子ゲスト端末の認証情報と、当該認証情報に対する前記子ゲスト端末の署名と、当該認証情報に対する前記代表ゲスト端末の署名とを、前記子ゲスト端末による解錠の許可登録の要求として前記オーナー端末に送信し、
　前記オーナー端末は、
　前記代表ゲスト端末から受信した前記子ゲスト端末による解錠の許可登録の要求に含まれる署名の検証に成功し、前記管理者による前記子ゲスト端末に対する解錠の許可登録を承認する情報を受け付けた後に、前記子ゲスト端末の認証情報に署名し、
　前記代表ゲスト端末から受信した前記子ゲスト端末による解錠の許可登録の要求に含まれる情報と、前記子ゲスト端末の認証情報に対する前記オーナー端末の署名とを、前記代表ゲスト端末による解錠の許可登録の要求に含まれる情報および前記代表ゲスト端末の認証情報に対する前記オーナー端末の署名とともに、前記管理サーバに送信し、
　前記管理サーバは、
　前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記代表ゲスト端末と前記子ゲスト端末とを関連付けて記憶するとともに、前記子ゲスト端末の認証情報と前記子ゲスト端末とを関連付けて記憶し、
　前記スマートロックから、解錠を要求する前記子ゲスト端末が送信した解錠要求を受信すると、当該子ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該子ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信し、
　前記スマートロックは、
　前記管理サーバが、前記解錠要求は前記子ゲスト端末が送信した解錠要求であると判断した場合には解錠する
　ことを特徴とする請求項１に記載の認可システム。
　前記オーナー端末は、
　前記解錠の許可登録の管理サーバへの要求を前記代表ゲスト端末に認可することを示す許可トークンを生成して署名を付与し、
　前記署名を付与した許可トークンを前記管理サーバに送信し、
　前記管理サーバは、
　前記オーナー端末から受信した許可トークンに付与された署名を検証し、当該許可トークンと前記代表ゲスト端末とを関連付けて記憶し、
　前記子ゲスト端末は、
　前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、
　前記認証情報と前記署名とを前記代表ゲスト端末に送信し、
　前記代表ゲスト端末は、
　前記子ゲスト端末から受信した情報に含まれる署名の検証に成功した後に、前記子ゲスト端末の認証情報に署名し、
　前記子ゲスト端末の認証情報と、当該認証情報に対する前記子ゲスト端末の署名と、当該認証情報に対する前記代表ゲスト端末の署名とを、前記子ゲスト端末による解錠の許可登録の要求として前記管理サーバに送信し、
　前記管理サーバは、
　前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、
　当該代表ゲスト端末に関連付けられた許可トークンを記憶していることを確認した後に、
　前記代表ゲスト端末と前記解錠の許可登録の要求に含まれる子ゲスト端末とを関連付けて記憶するとともに、当該子ゲスト端末の認証情報と当該子ゲスト端末とを関連付けて記憶する
　ことを特徴とする請求項１に記載の認可システム。
　前記オーナー端末は、
　前記解錠の許可登録の管理サーバへの要求を前記代表ゲスト端末に認可することを示す許可トークンを生成して署名を付与し、
　前記署名を付与した許可トークンを前記代表ゲスト端末に送信し、
　前記代表ゲスト端末は、
　前記オーナー端末から受信した許可トークンに付与された署名を検証して記憶し、
　前記子ゲスト端末は、
　前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、
　前記認証情報と前記署名とを前記代表ゲスト端末に送信し、
　前記代表ゲスト端末は、
　前記子ゲスト端末から受信した情報に含まれる署名の検証に成功した後に、前記子ゲスト端末の認証情報に署名し、
　前記子ゲスト端末の認証情報と、当該認証情報に対する前記子ゲスト端末の署名と、当該認証情報に対する前記代表ゲスト端末の署名と、前記署名が付与された許可トークンとを、前記子ゲスト端末による解錠の許可登録の要求として前記管理サーバに送信し、
　前記管理サーバは、
　前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、
　前記許可トークンで認可された代表ゲスト端末が、前記解錠の許可登録の要求した代表ゲスト端末であることを検証して成功した後に、
　前記代表ゲスト端末と前記解錠の許可登録の要求に含まれる子ゲスト端末とを関連付けて記憶するとともに、当該子ゲスト端末の認証情報と当該子ゲスト端末とを関連付けて記憶する
　ことを特徴とする請求項１に記載の認可システム。
　前記許可トークンは、前記子ゲスト端末の前記解錠の許可登録の取り消しを含み、
　前記代表ゲスト端末は、前記子ゲスト端末の許可登録の取り消しを要求し、
　前記管理サーバは、
　当該代表ゲスト端末に対応する許可トークンを記憶していることを検証して成功した後、または、前記許可登録の取り消しの要求に当該代表ゲスト端末に対応する許可トークンが含まれていて当該許可トークンに付与された署名を検証して成功した後に、
　当該代表ゲストに関連付けられた当該子ゲスト端末の認証情報を削除する
　ことを特徴とする請求項３または４に記載の認可システム。
　前記許可トークンは、前記解錠の許可登録可能な子ゲスト端末の上限数および登録可能な期間の何れかを含み、
　前記管理サーバは、
　前記許可トークンが前記上限数を含む場合には、前記代表ゲスト端末から前記解錠の許可登録の要求を前記上限数まで受け付け、
　前記許可トークンが前記登録可能な期間を含む場合には、当該登録可能な期間に前記代表ゲスト端末から前記解錠の許可登録の要求があれば当該要求を受け付ける、
　ことを特徴とする請求項３または４に記載の認可システム。
　前記許可トークンは、前記解錠を許可する日時を含み、
　前記管理サーバは、
　前記解錠の許可登録を要求する子ゲスト端末の認証情報と当該子ゲスト端末とを関連付けて記憶する際に、前記解錠を許可する日時を関連付けて記憶し、
　前記解錠要求は当該子ゲスト端末が送信した解錠要求であるか否かを判断するときに、前記解錠要求の送信時刻が、当該子ゲスト端末と関連付けて記憶された解錠を許可する日時に含まれているかも判断する
　ことを特徴とする請求項３または４に記載の認可システム。
　前記管理サーバは、前記代表ゲスト端末から前記子ゲスト端末の解錠の許可登録の要求を受信すると、前記子ゲスト端末の認証情報と前記子ゲスト端末とを関連付けて記憶する前に、前記オーナー端末に前記解錠の許可登録の承認の可否を問い合わせ、
　前記オーナー端末は、前記管理者による前記解錠の許可登録の承認の可否を示す情報を受け付け、承認可または承認否を前記管理サーバに送信し、
　前記管理サーバは、前記承認可を受信すると、前記認証情報と前記子ゲスト端末とを関連付けて記憶する
　ことを特徴とする請求項３または４に記載の認可システム。
　前記管理サーバは、前記代表ゲスト端末から前記子ゲスト端末の解錠の許可登録の要求を受信すると、前記代表ゲスト端末と前記子ゲスト端末とを関連付けて記憶するとともに、前記子ゲスト端末の認証情報と前記子ゲスト端末とを関連付けて記憶した後に、前記オーナー端末に前記解錠の許可登録を通知し、
　前記オーナー端末は、前記管理者による前記解錠の許可登録のキャンセルの可否を示す情報を受け付け、キャンセル可またはキャンセル否を前記管理サーバに送信し、
　前記管理サーバは、前記キャンセル可を受信すると、前記子ゲスト端末と関連付けて記憶した前記認証情報を削除する
　ことを特徴とする請求項３または４に記載の認可システム。
　スマートロック、前記スマートロックの管理者が利用するオーナー端末、子ゲストが利用し前記スマートロックの解錠を要求する子ゲスト端末、代表ゲストが利用し前記スマートロックの解錠を要求する代表ゲスト端末、および管理サーバを含む認可システムの管理サーバであって、
　前記代表ゲスト端末が前記スマートロックの解錠を要求したときに参照される認証情報と、前記認証情報に対する前記代表ゲスト端末の署名および前記オーナー端末の署名とを、前記オーナー端末から受信し、
　前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記オーナー端末と前記代表ゲスト端末とを関連付けて記憶するとともに、前記代表ゲスト端末の認証情報と前記代表ゲスト端末とを関連付けて記憶し、
　前記スマートロックから、解錠を要求する前記代表ゲスト端末が送信した解錠要求を受信すると、当該代表ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該代表ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信する
　ことを特徴とする管理サーバ。
　スマートロック、前記スマートロックの管理者が利用するオーナー端末、子ゲストが利用し前記スマートロックの解錠を要求する子ゲスト端末、代表ゲストが利用し前記スマートロックの解錠を要求する代表ゲスト端末、および管理サーバを含む認可システムの認可方法であって、
　前記代表ゲスト端末は、
　前記スマートロックの解錠を要求したときに参照される認証情報を生成して署名し、前記認証情報と前記署名とを、前記代表ゲスト端末による解錠の許可登録の要求として前記オーナー端末に送信するステップを実行し、
　前記オーナー端末は、
　前記代表ゲスト端末から受信した情報に含まれる署名の検証に成功し、前記管理者による前記代表ゲスト端末に対する解錠の許可登録を承認する情報を受け付けた後に、前記代表ゲスト端末の認証情報に署名するステップと、
　前記代表ゲスト端末から受信した前記解錠の許可登録の要求に含まれる情報と、前記代表ゲスト端末の認証情報に対する前記オーナー端末の署名とを、前記管理サーバに送信するステップとを実行し、
　前記管理サーバは、
　前記オーナー端末から受信した情報に含まれる署名の検証に成功した後に、前記オーナー端末と前記代表ゲスト端末とを関連付けて記憶するとともに、前記代表ゲスト端末の認証情報と前記代表ゲスト端末とを関連付けて記憶するステップと、
　前記スマートロックから、解錠を要求する前記代表ゲスト端末が送信した解錠要求を受信すると、当該代表ゲスト端末に関連付けられた認証情報を参照して、前記解錠要求は当該代表ゲスト端末が送信した解錠要求であるか否かを判断し、判断の結果を前記スマートロックに送信するステップとを実行し、
　前記スマートロックは、
　前記管理サーバが、前記解錠要求は前記代表ゲスト端末が送信した解錠要求であると判断した場合には解錠するステップを実行する
　ことを特徴とする認可方法。