JP4523449B2 - 鍵サービス方法、システムおよびそのプログラム - Google Patents

Description

公開鍵暗号を用いた認証情報（解錠ライセンス）により、利用者が携帯する装置、例えばＩＣチップ搭載携帯電話を用いてドアの解錠または施錠を行い、解錠または施錠を契機として情報配信を行う鍵サービス方法、システムおよびそのプログラムに関する。

従来の共通鍵暗号を用いた鍵サービスシステムのフローを図１に示す（非特許文献１）。図１において、１は利用者が携帯する装置、例えば携帯電話であり、２はゲート（ドアがわ装置）であり、３はサーバであり、４は鍵管理者である。第１の段階は初期設定の段階である。Ｓ１０で携帯電話１からサーバ３に対して利用者登録を行う。この時、携帯電話１は利用者ＩＤを送付する。Ｓ１１でサーバ３は鍵管理者４に対して設定画面の表示し、Ｓ１２で鍵管理者４はサーバ３に対して利用者毎にゲート２の解錠許可（サクセス権）の設定を行う。第２の段階は予約・解錠ライセンスのダウンロードの段階である。Ｓ１３で携帯電話１はサーバ３に対して予約を行う。この時、携帯電話１は利用者ＩＤを送付する。Ｓ１４でサーバ３は利用者を検証し、解錠許可をチェックする。許可の場合は、Ｓ１５で解錠ライセンスを発行する。解錠ライセンスにはゲートＩＤ、利用者ＩＤが含まれている。Ｓ１６でサーバ３から解錠ライセンスをゲート２にダウンロードし、Ｓ１７で携帯電話１が解錠ライセンスをダウンロードする。第３の段階は入室時の段階である。携帯電話１はゲート２に対して認証データを送信する。認証データには解錠ライセンスと利用者ＩＤが含まれている。Ｓ１９でゲート２は解錠ライセンスと利用者ＩＤを検証し、許可すべき時はＳ２０でドアを解錠する。Ｓ２１でゲート２は解錠情報（解錠ライセンス情報）をサーバ３に送信し、Ｓ２２でサーバ３はｉ−ｍｏｄｅ（登録商標）メールで情報を配信する。

この方式においては、利用者ＩＤ（これはＩＣチップに固有である）およびゲートＩＤの組が、解錠のための認証情報（解錠ライセンス）となる。セキュリティを担保するため、この認証情報（解錠ライセンス）は共通鍵により暗号化され、各装置間で受け渡される。このため、認証情報（解錠ライセンス）を扱う各装置、すなわち、サーバ、ゲートおよび携帯（ＩＣチップ）は、共通の秘密鍵（共通鍵）を知っている必要があり、またこれら装置に対しては耐タンパ性が要求される（これらの装置では、認証情報（解錠ライセンス）を秘密の情報として保護しなければならない）。

この従来方式は共通鍵を用いるため、以下の問題点がある。
（１）共通鍵が知られてしまうとシステム全体が破られたことになり、セキュリティ上の弱点となる。
（２）共通の秘密鍵、および認証情報（解錠ライセンス）といった秘密の情報を、原則として各ドアが持たなければならず、秘密情報を保護しなければならない装置の数が多くなる。
（３）解錠鍵（解錠ライセンス）（解錠のための認証情報）を発行するたび、認証情報（解錠ライセンス）を、原則として各ドアに適宜配送しなければならず、従って各ドアは常時オンラインである必要がある。

各ドアで直接処理を行うのではなく、複数のドア群と接続されそれらをコントロールするドアサーバを用いることにより、上記問題点のうち（２）、（３）は軽減することができる。しかしながら、この場合においても、ドアサーバは秘密情報を保護しなければならずかつ解錠鍵の配送を受けるため常時オンラインでなければならない。また、各ドアは任意の時点で解錠処理を行うためドアサーバとは常時接続されていなければならない。従って、ドアサーバを用いた場合でも、上記問題点は本質的には解消されない。

図１のフローにおいて、ＩＣカードを用いた場合には、ＩＣカードリーダライタ装置を接続したＰＣ等の装置を用いることが必要であり、システム上要求される装置数が増える。また、ＩＣカードを用いた場合には、鍵発行というプロセスを経ずに運用するシステムも多い。この場合、解錠に用いる認証情報は利用者ＩＤ（ＩＣチップに固有）のみであり、ＩＣカードに対する鍵ダウンロードの処理は省略できる。一方、各ドアに対しては、鍵ダウンロードという形式ではなく解錠許可の設定を行うことになるが、このため各ドアの設定はより煩雑となり、かつまた認証情報と利用者ＩＤとが同一になるためセキュリティ的にもより脆弱となる。

図１のフローにおいて情報配信の契機は解錠の成功であるが、その方式は（ｉモード）メールである。この場合、解錠からメール着信までにはタイムラグが存在し、かつまたネットワークの状態によっては情報配信が失敗する可能性があり、問題となる。鍵サービスとは異なるサービスで、非接触通信で直接ＩＣチップ搭載携帯電話に情報配信を行うシステムも存在する。しかしながらこの場合、従来システムでは配信できる情報量に制限があり、大抵の場合はＵＲＬなど実際に配信したい情報へのポインタを配信するのみである。

株式会社ＫＥＳＡＫＡシステム、株式会社コネクトテクノロジーズ、伊藤忠テクノサイエンス株式会社、株式会社ＮＴＴドコモ九州、"「おサイフケータイＴＭ」をカギとして利用のマンション完成！ 「ｋｅｓａｋａサービス」提供開始。"、[online]、［平成１７年１月２８日検索］、インターネット＜http://www.kesaka.net/tm05.htm＞＜http://www.kesaka.net/pf0404.htm＞＜http://www.kesaka.net/pf04041.htm＞＜http://www.kesaka.net/pf04042.htm＞＜http://www.kesaka.net/pf04043.htm＞＜http://www.kesaka.net/pfsample1.htm＞

本発明は、公開鍵暗号を用いることにより、鍵サービスにおける従来の方式の問題点を解決するものである。すなわち、公開鍵暗号を用いた方式により、下記を実現する。
・公開鍵暗号を用いることにより、共通の秘密鍵の漏洩にかかわるシステムのセキュリティ上の弱点を解消する。
・さらに、公開鍵暗号を用いた解錠鍵の方式を工夫することで、各ドア等の施錠・解錠装置が秘密情報を持つ必要を無くし、秘密情報を保護しなければならない装置の数を低減する。
・認証情報の各ドア等の施錠・解錠装置への事前の配送を不要とするような解錠鍵の方式を実現し、これにより各ドア等の施錠・解錠装置が常時オンラインである必要性を解消する。

更に、ＩＣチップ搭載携帯電話を用いることにより、解錠鍵の書き換えおよび閲覧・行使を、特別な装置なしに行えるようにする。すなわち、例えば、ｉモード等によりネットワークアクセスが可能な携帯電話を用いることにより、ＩＣカード内の認証情報の書き換えおよび閲覧を携帯電話のみで行うことができる。これはＩＣカードを用いた場合を比べてシステム上要求される装置の種類が少なく済み利便性が高く、かつまた従来方式よりもセキュリティ的にも優れている。

また、解錠の成功等を契機とし、ドア等の施錠・解錠装置の例えばＩＣカードリーダライタ装置から直接ＩＣチップ搭載携帯電話に非接触通信で情報配信を行うことにより、従来方式と比べてよりタイムラグが小さくかつ確実に、情報そのものの配信を行うことができる。

第１の発明は、錠の施錠・解錠を行う施錠・解錠装置が、利用者が携帯する装置から鍵管理者の秘密鍵による署名を含む電子的な鍵である解錠ライセンスを受信するステップと、前記施錠・解錠装置が、前記鍵管理者の公開鍵を用いた前記解錠ライセンスの署名の検証および前記解錠ライセンスの検証を行うステップと、前記施錠・解錠装置が前記利用者が携帯する装置に対してチャレンジを送信し、前記利用者が携帯する装置が前記チャレンジに対して前記利用者の秘密鍵により署名演算を行い前記施錠・解錠装置にレスポンスを送信し、前記施錠・解錠装置が前記利用者の公開鍵を用いてレスポンスを検証するステップと、前記施錠・解錠装置が、前記解錠ライセンスの署名の検証および前記解錠ライセンスの検証および前記レスポンスの検証に成功した場合に、錠の解錠または施錠を行うステップと、前記解錠または施錠を契機として、前記施錠・解錠装置が前記利用者が携帯する装置にハイパーリンクを含む情報およびアプリケーションの起動指示を非接触通信により配信し、前記利用者が携帯する装置がアプリケーションを起動し配信された前記ハイパーリンクを含む情報を画面に表示させるステップと、を有する鍵サービス方法である。第２の発明は、第１の発明において、サーバが、利用者が携帯する装置から前記利用者の秘密鍵による署名を含む情報を受信するステップと、前記サーバが、前記利用者の公開鍵を用いた前記利用者の検証および解錠許可の検証に成功した場合に、前記解錠ライセンスを前記利用者が携帯する装置に送信するステップと、を有する鍵サービス方法である。第３の発明は、第１または２の発明において、前記利用者によるＰＩＮ入力が成功した後、前記施錠・解錠装置が、前記利用者が携帯する装置から前記解錠ライセンスを受信する鍵サービス方法である。第４の発明は、第３の発明において、前記ＰＩＮ入力が必須の動作と、それを必須としない動作を切り替えるステップを有する鍵サービス方法である。第５の発明は、第１〜第４の発明において、前記利用者が携帯する装置はＴｙｐｅＢ ＩＣチップ搭載携帯電話である鍵サービス方法である。第６の発明は、第１〜第５の発明において、前記施錠・解錠装置と前記利用者が携帯する装置との間の通信を非接触通信で行う鍵サービス方法である。第７の発明は、第１〜第６の発明の鍵サービス方法を行う前記サーバ、前記施錠・解錠装置、および前記利用者が携帯する装置を有する鍵サービスシステムである。第８の発明は、第１〜第７の発明の鍵サービス方法のステップをコンピュータに実行させるためのプログラムである。

本発明により、公開鍵暗号を用いることで、鍵サービスにおける従来の方式の問題点を解決することができる。すなわち、下記が実現される。
・公開鍵暗号を用いることにより、共通の秘密鍵の漏洩にかかわるシステムのセキュリティ上の弱点を解消する。
・さらに、公開鍵暗号を用いた解錠鍵の方式を工夫することで、各ドア等の施錠・解錠装置が秘密情報を持つ必要を無くし、秘密情報を保護しなければならない装置の数を低減する。
・認証情報の各ドア等の施錠・解錠装置への事前の配送を不要とするような解錠鍵の方式を実現し、これにより各ドア等の施錠・解錠装置が常時オンラインである必要性を解消する。

更に、例えば、ｉモード等によりネットワークアクセスが可能な携帯電話を用いることにより、ＩＣカード内の認証情報の書き換えおよび閲覧を特別な装置なしに携帯電話のみで行うことができる。

また、解錠の成功等を契機とし、ドア等の施錠・解錠装置の例えばＩＣカードリーダライタ装置から直接ＩＣチップ搭載携帯電話に非接触通信で情報配信を行うことにより、従来方式と比べてよりタイムラグが小さくかつ確実に、情報そのものの配信を行うことができる。

以下、本発明の実施形態について説明する。
本発明の鍵サービスシステムの実施形態のフローを図２に示す。図２において、３１は利用者が携帯する装置、例えばＴｙｐｅＢ ＩＣチップ搭載携帯電話であり（以下、「ＩＣチップ搭載携帯電話３１」という。）、３２はドアの解錠、施錠を行うゲート（ドアがわ装置）であり、３３はサーバであり、３４は鍵管理者である。図２の携帯３１は本実施形態では「ＩＣチップ搭載携帯電話３１」として説明するが、これに限定されるわけではなく、利用者が携帯する装置であれば、携帯型のテレビ、ラジオ、音楽再生装置、鞄、ハンドバッグ、サイフ、免許証、証明書、カード等の利用者が携帯するものであってもよく、また、衣服に取り付けたり、電子鍵として専用のものであってもよい。本実施形態においてはゲート３２をドアがわ装置すなわちドアの錠の施錠、解錠を行う装置として説明するが、これに限定されるわけではなく、ゲート３２は金庫、鞄、ハンドバック、机、キャビネット、ロッカー、自動車、建物、その他の錠を用いる物において、錠の施錠・解錠を行う施錠・解錠装置である。

第１段階は初期設定の段階である。Ｓ４０でサーバ３３は鍵管理者ＩＤとゲートＩＤをゲート（ドアがわ装置）３２に設定する。Ｓ４１でＩＣチップ搭載携帯電話３１が利用者登録を行う。利用者登録には利用者の公開鍵が含まれている。Ｓ４２でサーバ３３は鍵管理者３４に対して設定画面を表示し、Ｓ４３で鍵管理者３４はサーバ３３に利用者毎のゲート（部屋）の解錠許可（アクセス権）を設定する。

第２段階は予約・解錠ラインセンスのダウンロードの段階である。Ｓ４４でＩＣチップ搭載携帯電話３１はサーバ３３に対して予約を送信する。予約には利用者の秘密鍵による署名が含まれている。なお、予約の代わりに、変更や削除の情報を送信することもできる。Ｓ４５でサーバ３３は利用者を検証し、解錠許可をチェックする。許可の場合はＳ４６で電子的な鍵である解錠ライセンスを生成する。解錠ライセンスは有効期限、ゲートＩＤ、利用者公開鍵付きである（サーバ３３はＳ４１で利用者公開鍵を取得している）。Ｓ４７でサーバ３３は解錠ライセンスをＩＣチップ搭載携帯電話３１に送信する。解錠ライセンスには鍵管理者の秘密鍵による署名が含まれている。

第３の段階は利用者の入出時である。Ｓ４８でＩＣチップ搭載携帯電話３１は解錠ライセンスを送信する。解錠ライセンスは鍵管理者秘密鍵による署名を含む。Ｓ４９で、ゲート（ドアがわ装置）３２は、解錠ライセンスの署名検証と解錠ライセンスの検証を行う。すなわち、ゲート（ドアがわ装置）３２は、取得した解錠ライセンスに施されている鍵管理者秘密鍵による署名を鍵管理者公開鍵によって検証する。次に、ゲート（ドアがわ装置）３２は、解錠ライセンスをパーズし、必要な情報を取り出す。取り出された情報のうち、対象のゲートＩＤおよび有効期限をチェックし、自己のゲートＩＤおよび現在時刻が条件に合致するかを確認する。解錠ライセンスの署名検証と解錠ライセンスの検証が成功すれば、ゲート（ドアがわ装置）３２はＳ５０でチャレンジを携帯電話３１に送信する。携帯電話３１は利用者の秘密鍵を用いて署名演算し、Ｓ５２でレスポンスをゲート（ドアがわ装置）３２に送信する。Ｓ５３でゲート（ドアがわ装置）３２は利用者公開鍵を用いてレスポンスを検証し、成功すればＳ５４で解錠する。Ｓ５５でゲート（ドアがわ装置）３２は非接触、連携起動によりＩＣチップ搭載携帯電話３１に情報を配信する。

本実施形態における解錠鍵（解錠ライセンス）は、対象のゲートＩＤ、有効期限、利用者の公開鍵およびその他付帯データを一組とし、その一組に対して鍵管理者秘密鍵による署名を行ったものである。解錠鍵（解錠ライセンス）は、利用者からの依頼（部屋の利用予約等）に基づき、鍵管理者が生成する。解錠鍵生成に先立ち、利用者の公開鍵は鍵管理者に知らされているものとする（図２のフローにおいては、利用者登録時（Ｓ４１）にサーバに登録される）。生成された解錠鍵（解錠ライセンス）は、利用者に送られる（Ｓ４７）。利用者は、入室時に解錠鍵（解錠ライセンス）をドアがわ装置に送り（Ｓ４８）、認証等必要な処理を行ってすべて成功すれば解錠がなされる（Ｓ５４）。入室時の認証プロセスは以下の手順となる。
１．解錠鍵（解錠ライセンス）の署名検証：ゲート（ドアがわ装置）３２は、取得した解錠鍵（解錠ライセンス）に施されている、鍵管理者秘密鍵による署名を検証する。署名検証には鍵管理者公開鍵が必要であるが、これは予め鍵管理者によってドアがわ装置３２に設定されているものとする。
２．解錠鍵（解錠ライセンス）の検証：ゲート（ドアがわ装置）３２は、解錠鍵（解錠ライセンス）をパーズし、必要な情報を取り出す。取り出された情報のうち、対象のゲートＩＤおよび有効期限をチェックし、自己のゲートＩＤおよび現在時刻が条件に合致するかを確認する。
３．利用者の認証：ゲート（ドアがわ装置）３２は、利用者に対してチャレンジを送る。利用者のＩＣチップ（ＩＣチップ搭載携帯電話３１内）は、チャレンジに対して利用者秘密鍵により署名演算を行い、結果をドアがわ装置３２に返す。ドアがわ装置３２は、解錠鍵（解錠ライセンス）から取得した利用者公開鍵を用いてレスポンスを検証する。
なお、上記１、２は図２のＳ４９で行われ、上記３は図２のＳ５０〜Ｓ５３で行われる。

上記の方式において、秘密に保持しなければならない情報は、通常の公開鍵暗号と同じく、鍵管理者秘密鍵および利用者秘密鍵のみである。従って、秘密情報を保持する機器はサーバおよび利用者が持つＩＣチップのみであり、従来方式のようにドアがわ機器に秘密情報を保持する必要はない。

本実施形態において、解錠時には鍵管理者の鍵ペアによる解錠鍵（解錠ライセンス）の検証が行われるため（図２のＳ４９参照）、第三者が解錠鍵（解錠ライセンス）を改竄したとしても改竄された解錠鍵は無効となる。また、万一鍵管理者の秘密鍵が漏洩したとしても、それにより影響を被るのは当該鍵管理者に係わるドアのみであり、従来方式のように共通の秘密鍵が漏洩した時点でシステムに対する任意の攻撃が可能となる訳ではなく、よりセキュリティが高い。また、解錠時には利用者の鍵ペアによる利用者認証が行われるため（図２のＳ５０〜Ｓ５３参照）、解錠鍵（解錠ライセンス）が第三者に渡ったとしても第三者による解錠鍵の使用は阻止される。従来方式では共通の秘密鍵を知っている（システムに参加している）第三者がＩＤを偽装できれば不正に入手した解錠鍵の使用が可能となるため、本方式はよりセキュリティが高い。さらに、万一利用者の秘密鍵が漏洩したとしても、それにより影響を蒙るのは当該利用者のみであり、従来方式のように共通の秘密鍵が漏洩した時点でシステムに対する任意の攻撃が可能となる訳ではない。

本実施形態において、解錠時の認証プロセスにおいてゲート（ドアがわ装置）３２で必要となる情報は、事前に設定された鍵管理者の公開鍵および解錠前に利用者から送られる解錠鍵（解錠ライセンス）に含まれる情報のみである。すなわち、従来方式のように、発行された解錠鍵と利用者が持つ解錠鍵（解錠ライセンス）とをドアがわ装置で照合する必要はなく、したがって解錠鍵（解錠ライセンス）を発行する度にドアがわ装置を設定したり、あるいは解錠処理を行う度にサーバ等に認証情報を確認したりする必要がない。つまり、ドアがわ装置は常時オンラインである必要はない。

本実施形態においてはＩＣチップ搭載携帯電話を用いるため、ＩＣカード内の認証情報の書き換えおよび閲覧を、特別な装置を用いることなく携帯電話のみで行うことができる。

本実施形態においては、解錠を契機として、ドアがわ装置のＩＣカードリーダライタ装置から直接ＩＣチップ搭載携帯電話に非接触通信で情報配信が行われる。従来方式は解錠通知を一旦サーバに送り、サーバから情報配信を行うため、ドアがわ装置は常時オンラインでなければならず、かつ情報配信にはタイムラグが存在した。一般に、配信されるべき情報の更新頻度は一日毎あるいは数時間毎などさほど頻繁ではないため、本方式ではドアがわ装置は常時オンラインである必要はない。また、情報配信は直接行われるため、従来方式と比べてよりタイムラグが小さくかつ確実に、情報そのものの配信を行うことができる。更に、本方式においてはＩＣチップ搭載携帯電話を用いるため、配信された情報はその場で携帯電話のディスプレイを用いて閲覧することが可能である。

図３−１に、本実施形態のシステム構成概要図を示す。３０１はＴｙｐｅＢ ＩＣチップ搭載携帯電話（以下、「ＩＣチップ搭載形態電話３０１」というが、利用者が携帯する装置であればどのようなものでもよい。）であり、図２の携帯３１に対応する。３０２はドアの解錠、施錠を行うドアがわ端末であり、図２のゲート（ドアがわ装置）３２に対応する。３０３は解錠ライセンス管理／情報配信サーバであり、図２のサーバ３３に対応する。

解錠ライセンス管理／情報配信サーバ３０３は、解錠ライセンス（解錠鍵）の発行および管理を行う解錠ライセンス管理サーバ３１０、配信情報の設定・管理およびドアがわ端末３０２への配送を行う配信情報配信サーバ３２０、利用者の登録・管理を行いかつ利用者に対するＷｅｂ Ｕ／Ｉを提供する利用者管理・Ｗｅｂ Ｕ／Ｉ３３０からなる。これら三つの部分は本実施形態では単純のため一個のサーバ装置内に置かれるものとして扱うが、それぞれ別個のサーバ装置に置かれたとしても機能的に全く問題はない。

ＩＣチップ搭載携帯電話３０１とドアがわ端末３０２はＩＳＯ／ＩＥＣ１４４４３（非接触型ＩＣカードやＲＦＩＤの通信規格の一つ）で非接触通信を行い、ＩＣチップ搭載携帯電話３０１と解錠ライセンス管理／情報配信サーバ３０３はｉ−ｍｏｄｅ網を介してｓｍｔｐ、ｈｔｔｐｓのプロトコルで通信を行い、ドアがわ端末３０２と解錠ライセンス管理／情報配信サーバ３０３はネットワーク接続により通信を行う。なお、本実施形態においてはＩＣチップ搭載携帯電話３０１とドアがわ端末３０２間の非接触通信としてＩＳＯ／ＩＥＣ１４４４３を用いているが、これに限定するものではなく、非接触通信は、電気的に非接触で、近距離の通信であればどのようなものでもよい。また、本実施形態においてはＩＣチップ搭載携帯電話３０１と解錠ライセンス管理／情報配信サーバ３０３間の通信網としてｉ−ｍｏｄｅ網を用いているが、それ以外の通信網であってもよい。

図３−２に解錠ライセンス管理／情報配信サーバ３０３の詳細を示す。解錠ライセンス管理／情報配信サーバ３０３は、解錠ライセンス管理サーバ３１０と配信情報配信サーバ３２０と利用者管理・Ｗｅｂ Ｕ／Ｉ３３０を有する。

利用者管理・Ｗｅｂ Ｕ／Ｉ３３０は、利用者の登録・管理を行いかつ利用者に対するＷｅｂ Ｕ／Ｉを提供する。利用者管理・Ｗｅｂ Ｕ／Ｉ３３０は、利用者登録機能３３１、利用者認証機能３３２、利用者管理機能３３３、Ｗｅｂ Ｕ／Ｉ３３４を有する。利用者登録機能３３１はシステムを利用できるようにするため、住所・氏名・メールアドレス・役職・クレジット情報など、必要な情報をもって利用者を登録する。利用者認証機能３３２は利用者がサーバにアクセスする際に必要となる認証のための機能を提供する。利用者管理機能３３３は、登録された利用者の情報の管理を行う。Ｗｅｂ Ｕ／Ｉは、利用者および管理者に対して、Ｗｅｂまたはそれに準じるユーザインタフェースを提供する。

解錠ライセンス管理サーバ３１０は、解錠ライセンス（解錠鍵）の発行および管理を行う。解錠ライセンスサーバ３１０は、部屋情報登録・管理機能３１１、部屋・予約情報検索機能３１２、予約処理機能３１３、ネガリスト設定・配布機能３１５、ｉアプリ・カードＡＰダウンロード機能３１６を有する。部屋情報登録・管理機能３１１は、提供する各部屋（ドア）に関する情報を登録・管理する。部屋・予約情報検索機能３１２は、提供する各部屋およびそれらに対する予約情報を検索する。予約処理機能３１３は、予約・変更・削除を行う。解錠ライセンスの発行は、主として利用者からのリクエストに基づく。発行に先立つ利用者からのリクエストは、（部屋の）予約として処理される（たとえば会議室の予約・管理システムに適用した場合や、ウィークリーマンション・ホテル等の予約・部屋提供システムに適用した場合などを想定すれば理解し易い）。そういった予約を受け付けたり、変更・削除をおこなったりする機能である。解錠ライセンス生成・ダウンロード機能３１４は、予約に基づき、解錠ライセンスを生成・発行し、それを利用者がダウンロードできるようにする。ネガリスト設定・配布機能３１５は、ネガリストを設定し、配布する。利用者が携帯電話を紛失したなどの場合、拾われた携帯電話による不正使用の防止策として、申請に基づき、当該利用者の権限を停止する必要がある。このとき、既に発行・ダウンロードされた解錠ライセンスを無効化するため、ネガリストを生成して配布する必要がある。ｉアプリ・カードＡＰダウンロード機能３１６は、電子キーｉアプリ３６１および電子キーカードＡＰ３５１をダウンロード配布する機能である。

配信情報配信サーバ３２０は、配信情報の設定・管理およびドアがわ端末３０２への配送を行う。配信情報配信サーバ３２０は、配信情報設定・登録機能３２１、配信情報配布機能３２２、メール情報配信機能３２３、ｉアプリ・カードＡＰダウンロード機能３２４を有する。配信情報設定・登録機能３２１は、情報配信のための配信情報の設定および登録を行う。なお、配信情報は、配信されるべき情報の本体と、それに対する配信条件との組からなる。配信情報配布機能３２２は、設定・登録された配信情報を各ドアがわ端末に配布する。メール情報配信機能３２３は、情報配信をメール経由で行う場合に、ドアがわ端末３０２から解錠通知を受け取り、それに基づき配信されるべき情報および配信先を検索・決定し、メールで情報配信を行う。なお本実施形態では情報配信はドアがわ端末３０２から直接、非接触経由で行うことが基本であるが、既存システムとの整合性その他の理由でメール経由で情報配信を行いたい場合に用いられる機能である。ｉアプリ・カードＡＰダウンロード機能３２４は、情報配信ｉアプリ３６７および情報配信カードＡＰ３５４をダウンロード配布する機能である。

図３−１のＩＣチップ搭載携帯電話３０１は、ｍｉｎｉＳＤ形状のＩＣチップを搭載可能であり、かつそれへのｉアプリからのアクセス手段、および非接触経由でのＩＣチップへのアクセスに必要となるアンテナ・給電等の機能を備えた携帯電話である。３５０がＩＣチップであり（ＩＣチップはｍｉｎｉＳＤ形状のものが望ましいが、他の形状のＩＣチップでもよい）、３６０がｉアプリである。

図３−３にＩＣチップ搭載携帯電話３０１の詳細を示す。ＩＣチップ搭載携帯電話はｉアプリ３６０とＩＣチップ３５０を有する。ｉアプリ３６０は電子キーｉアプリ３６１と情報配信ｉアプリ３６７を有する。ＩＣチップ３５０は電子キーカードＡＰ３５１と情報配信ＡＰ３５４を有する。

電子キーｉアプリ３６１は、ＩＣチップ内の解錠ライセンスの更新・表示を行うｉアプリである。解錠ライセンスダウンロード・管理機能３６２は、解錠ライセンス管理サーバ３１０にアクセスし、解錠ライセンスをダウンロードし電子キーカードＡＰ３５１内に保存する。また、保存された解錠ライセンスの管理を行う。解錠ライセンス表示機能３６３は、電子キーカードＡＰ３５１内に保存された解錠ライセンスの情報を携帯電話のディスプレイに表示する機能である。動作モード変更機能３６４は、解錠時に利用者によるＰＩＮ入力を必要とするか否かの、動作モードを変更する機能である（動作モードに関しては後述）。ＰＩＮ（暗証番号）入力・設定機能３６５は、利用者によるＰＩＮ入力を必要とするモードの際に、ＰＩＮを入力し、また設定する機能である。電子キーカードＡＰパーソナライズ機能３６６は、ダウンロードされた電子キーカードＡＰ３５１を使用可能な状態にし、利用者個々の情報を保存してパーソナライズする機能である。

情報配信ｉアプリ３６７は、配信された情報の管理・表示を行うｉアプリである。情報配信ｉアプリ３６７は配信情報管理・表示機能３６８を有する。配信情報管理・表示機能３６８は、配信された情報の管理および携帯電話のディスプレイへの表示を行う。

電子キーカードＡＰ３５１は、ＩＣチップ３５０内で、解錠ライセンスその他必要となる情報を保持し、かつ認証に必要な署名演算等を行う。電子キーカードＡＰ３５１は解錠ライセンス等保持機能３５２と認証機能３５３を有する。解錠ライセンス等保持機能３５２は、ダウンロードされた解錠ライセンス、その他必要となる情報を保持する機能である。認証機能３５３は、ドアがわ端末３０２との間で認証を行うため、署名演算等を行う機能である。なお、同様の認証機能をサーバとの認証に対して利用することも可能である。

情報配信カードＡＰ３５４は、ＩＣチップ３５０内で、配信される情報を取得・保持する機能である。情報配信カードＡＰ３５４は、配信情報取得・保持機能３５５を有する。配信情報取得・保持機能３５５は、配信される情報を取得・保持する機能である。

図３−１のドアがわ端末３０２は、制御端末３７０およびドアゲート３８０からなり、部屋のドアに対応する。

ドアゲート３８０は、電気錠３８１と電気錠コントローラ３８２、非接触ＩＣカードリーダライタ３８３を組み込んだドアである。電気錠コントローラ３８２は制御端末３７０からの指示に応じて電気錠３８１の解錠・施錠等のコントロールを行う。非接触ＩＣカードリーダライタ３８３は、制御端末３７０による制御に従い、非接触でＩＣチップ搭載携帯電話３０１のＩＣチップ３５０と通信を行う。なお、後述するＰＩＮ入力のため、ドアゲート３８０に１０キー入力装置を組み込む場合がある（１０キー入力装置は、制御端末３７０から制御を行う）。また、用途に応じて、表示機能や音源出力機能も組み込むこともあり得る。

制御端末３７０は、解錠ライセンス管理／情報配信サーバ３０３から配信された、あるいは予め設定された情報に基づき、ドアゲート３８０に組み込まれた各種装置を制御する。制御端末３７０はゲート端末ＡＰ３７１と情報配信ＡＰ３７６を有する。

図３−４にドアがわ端末３０２の制御端末３７０の詳細を示す。制御端末３７０は、ゲート端末ＡＰ３７１と情報配信ＡＰ３７６を有する。

ゲート端末ＡＰ３７１はドアゲート３８０を制御するアプリである。ゲート端末ＡＰ３７１は、解錠ライセンス取得・検証機能３７２、解錠機能３７３、ネガリスト取得設定機能３７４、動作モード設定・ＰＩＮ入力取得・検証機能３７５を有する。解錠ライセンス取得・検証機能３７２は、ドアゲート３８０のＩＣカードリーダライタ装置３８３を用いて、利用者がかざすＩＣチップ搭載携帯電話３０１内の電子キーカードＡＰ３５１から解錠ライセンスの取得を行い、取得した解錠ライセンスの署名検証・解錠ライセンス内の情報の検証および利用者の認証を行う。解錠機能３７３は、認証プロセスが正常に終了した場合に、ドアゲート３８０の電気錠コントローラ３８２を用いて電気錠３８１の解錠を行う機能である。なお、本実施形態では単純のため一貫して解錠に関してのみ述べるが、実際の動作としては解錠のみならず、施錠も同様に可能である。ネガリスト取得・設定機能３７４は、解錠ライセンス管理／情報配信サーバ３０３から配布されるネガリストを取得・保存し、解錠ライセンス内の情報の検証時に、合致するものがあった場合は認証プロセスを不成功とする機能である。動作モード設定・ＰＩＮ入力取得・検証機能３７５は、解錠時に利用者によるＰＩＮ入力を必要とするか否かの、動作モードを変更する機能である（動作モードに関しては後述）。ＰＩＮ入力を必要とする動作モードの場合、ＰＩＮ入力の取得は、ドアゲート３８０に組み込まれた１０キーから行う場合と、予め利用者がＩＣチップ搭載携帯電話３０１に入力しておいたものを、ドアゲートに組み込まれたＩＣカードリーダライタ装置３８３を用いて取得する場合がある。取得したＰＩＮは、ＩＣカードリーダライタ装置３８３を経由し、ＩＣチップ搭載携帯電話３０１内の電子キーカードＡＰ３５１により、検証を行う。

情報配信ＡＰ３７６は、情報配信を行うアプリである。情報配信ＡＰ３７６は情報配信・情報配信依頼機能３７７と配信情報取得・保存機能３７８を有する。情報配信・情報配信依頼機能３７７は、解錠を契機とし、予め設定された情報に基づき、配信されるべき情報を検索・決定し、ドアゲート３８０のＩＣカードリーダライタ装置３８３を用いて非接触通信により情報配信を行い、ＩＣチップ搭載携帯電話３０１内の情報配信カードＡＰ３５４に対して配信する情報を書き込む機能である。なお、情報配信をメール経由で行う場合は、解錠通知を解錠ライセンス管理／情報配信サーバ３０３に送る。配信情報取得・保存機能３７８は、配信されるべき情報を配信情報配信サーバ３２０から取得し、保存する機能である。

以下、実施例について説明する。
（実施例１）
実施例１は解錠ライセンスフォーマットの実施例である。
（実施例１．１）
図４に解錠ライセンスフォーマット例１を示す。

これは、解錠ライセンス管理／情報配信サーバ３０３（以下、単に「サーバ３０３」という。）にて生成し、ＩＣチップ３５０内に格納する解錠ライセンスのフォーマット例である。サーバ３０３では、新規予約や既存予約の変更・削除など、利用者に係わる予約に何らかの変更がある度、当該利用者の解錠ライセンスを生成し直す。その際、当該利用者に係わる予約のうち、有効期限が切れていないものをすべてリストアップし、それらのライセンス情報（図中では、ライセンス１情報、ライセンス２情報、等々）を並べ、利用者ＩＤ、利用者公開鍵等の利用者の情報を付け、その全体にサーバ署名を行い当該利用者向けの更新された解錠ライセンスとする。

ここで、利用者クラスは利用者の属するグルーピングのことであり、解錠許可あるいは情報配信の条件設定の際に利用される。また、時間帯は解錠を許可する時間を開始−終了時間の組で指定するのではなく、一日をいくつかのゾーンに切った時間帯の指定で行う際に用いる。なお、図中のＢｙｔｅの行は、ある実装を仮定した際に各フィールドで用いられるバイト数の見積もりであり、参考情報である。

また、ライセンス付帯情報は、解錠処理そのものには用いられないが、ＩＣチップ３５０内の解錠ライセンスの情報を。Ｉアプリが人間に可読な状態で表示する際に用いられるものであり、解錠ライセンスとセットで生成・更新される。

本実施例においては、利用者ひとりに対して解錠ライセンスは常にひとつであり、利用者に係わる予約に変更があった場合は解錠ライセンス全体が更新される。このため、予約に変更があった時の更新量が大きくなる反面、ｉアプリ・カードＡＰにおいて、解錠ライセンスの管理を特別に行う必要はない。

（実施例１．２）
図５に解錠ライセンスフォーマット例２を示す。
これは、サーバ３０３にて生成し、ＩＣチップ３５０内に格納する解錠ライセンスのフォーマット例である。実施例１．１と異なり、解錠ライセンスは個々の予約に対応する、個々の解錠ライセンス（図中では解錠ライセンス１、解錠ライセンス２等）のリストからなる。また、ライセンス付帯情報に関しても同様である。個々の解錠ライセンスのフォーマットは実施例１．１から容易に類推できるものであるので、説明は省略する。

本実施例においては、個々の予約に対応して独立な解錠ライセンスが存在するため、利用者に係わる予約に変更があった場合でも対応する解錠ライセンスのみを更新・削除すれば良い。このため、予約に変更があった時の更新量が小さく済む反面、ｉアプリ・カードＡＰにおいて、解錠ライセンスの管理を行う必要がある。

（実施例２）
実施例２は予約画面等の実施例である。
（実施例２．１）
実施例２．１はウィークリーマンションサービスへ適用した例である。
図６に本実施例をウィークリーマンションサービスに適用した場合の、利用者から見た画面遷移を示す。図６に示されているのは、ログイン・利用者認証から、部屋予約・申込を経て電子キー（解錠ライセンス）ダウンロードに至る一連の流れの部分である。

本実施例の携帯利用電子キーサービスは様々な分野に利用可能であるが、多くの場合、解錠ライセンスの生成・発行・解錠の部分のみではサービスとしての意味をなさず、部屋を貸す、予約するといった行為があってはじめて意味が出てくる。その一例として、ウィークリーマンションのサービスに適用した場合を記述したのが本実施例である。

これら画面はサーバ３０３にて生成され、利用者はＩＣチップ搭載携帯電話３０１のｉモードブラウザを用いてこれにアクセスする。電子キー（解錠ライセンス）ダウンロードは、ブラウザでリンクをクリックすることにより、ＩＣチップへのアクセス手段を持つ電子キーｉアプリが起動し、それによりなされる。

以下、図６を用いて説明する。利用者はＩＣチップ搭載携帯電話３０１のｉアプリまたはブックマークからサーバ３０３に接続する。画面１０１は、個人用トップページ画面である。「ログイン」を押下すると、ログイン確認画面１０２が表示される。ここで、「ＯＫ」を押下すると、サーバ３０３はＩＣチップ搭載携帯電話３０１の認証処理を行い（図２のＳ４４、Ｓ４５に対応する）、認証が正常に行われると、予約メニュー画面１０３が表示される。「部屋検索・申込」を押下すると、部屋検索画面１０４が表示され、予約期間を指定した後、「検索」を押下すると、部屋検索結果表示画面１０５が表示される。部屋を選択すると、部屋情報画面１０６が表示され、「ＯＫ」を押下すると、部屋申込画面１０７が表示され、「申込む」を押下すると、部屋申し込み完了画面１０８が表示され、解錠ライセンスが生成される（図２のＳ４６に対応する）。「電子キーダウンロードへ」を押下すると、予約確認・変更メニュー画面１０９が表示され、「電子キーダウンロード」を押下すると、ｉアプリ起動確認画面００８が表示される。「Ｙｅｓ」を押下すると、ｉアプリ起動中画面００９、ＩＣカードデータ書き込み中画面０１０が表示され、電子キー（解錠ライセンス）が保存されると、ＩＣカードデータ書き込み終了画面１１０が表示される（図２のＳ４７に対応する）。

（実施例２．２）
実施例２．２は会議室予約サービスへ適用した例である。図７に会議室予約サービスに適用した場合の、利用者から見た画面遷移を示す。図７に示されているのは、部屋予約・申込の部分（上の図）と、行った予約に対して参加者を登録・削除する部分（下の図）である。部屋予約・申込の部分（上の図）は実施例２．１と基本的には同じであるが、予約単位が実施例２．１の場合は日付であったのに対し、ここでは時間帯になっている。

図７の上の図は、会議室の予約を行う場合の携帯電話のブラウザの表示画面を示したものである。６０１は予約メニュー画面であり、「予約する」を押下すると、予約日付指定画面６０２が表示され、日付を指定して「ＯＫ」を押下すると、予約状況表示画面６０３が表示され、時間を選択すると、予約確認画面６０４が表示され、「ＯＫ」を押下すると予約完了画面６０５が表示される。ここで、「電子キーダウンロードへ」を押下すると、図６の画面１０９〜１１０と同様に電子キー（解錠ライセンス）を携帯電話にダウンロードできる。

図７の下の図は、会議室の予約確認、変更を行う場合の携帯電話のブラウザの表示画面を示したものである。６０１は予約メニュー画面であり、「予約確認・変更」を押下すると、予約確認画面６０７が表示され、会議室を選択すると、参加者登録予定変更・削除メニュー画面６０６が表示され、「参加者登録・削除」を押下すると、参加者登録・削除メニュー画面６１２が表示される。ここで、「追加」を押下すると、参加者が追加され、参加者登録完了画面６１３が表示される。参加者登録・削除メニュー画面６１２で、「削除」を押下すると、参加者が削除され、参加者削除完了画面６１４表示される。参加者として追加・削除された人の携帯電話に対して、その旨メール通知（電子キーダウンロード用ＵＲＬを含む）が行われる。追加された参加者は、通知されたメールの「電子キーダウンロード」（電子キーダウンロード用ＵＲＬへのリンク）を押下することにより、電子キー（解錠ライセンス）を自分の携帯電話にダウンロードすることができる。

図７の下の図に示す、行った予約に対して参加者を登録・削除する部分は実施例２．１にはない部分であり、予約した会議室（すなわち会議）に参加する人を予約者が指定し、参加者に対して合鍵を提供できるようにするものである。ここで、会議室予約サービスという性格上、利用者は基本的には予めすべて登録されており、かつその素性（役職、部署等）は利用者間で既知と想定して良いため、参加者登録にあたって予約者により特別に参加者の認証を行う必要はない。また、合鍵は実際には、登録された参加者が当該予約を行ったのと同様であるとみなすことで、新たに当該参加者に対して解錠ライセンスを発行することにより実現される。すなわち、合鍵という特別な仕組みを用意する必要はない。

（実施例３）
実施例３はＰＩＮ（暗証番号）認証に関するものである。
セキュリティ上の観点からは、解錠ライセンスの行使に先立ち、行使する人物がＩＣチップを保持する人物と同一であることの認証を行った方が望ましい場合がある。この目的で、解錠ライセンスを行使する前に、ＰＩＮ認証を行い、それによりＩＣチップ３５０を保持する人物と行使する人物とが同一である（すなわち本人しか知らないＰＩＮを知っている）ことを確認するプロセスを付加することができる。

また、ＰＩＮ入力を必須とするか不要とするかは、利用者により電子キーｉアプリ３６１からモード切り替えにより切り替えることも可能である。サービスの形態によっては、利用者にモード切り替えを許さず、サービス提供者が予めいづれかのモードに固定してサービスを提供することも可能である。

（実施例３．１）
図８にＰＩＮ（暗証番号）認証方式の実現例１を示す。図８（Ａ）にＰＩＮ必要モードの解錠時のフローを示し、図８（Ｂ）にＰＩＮ不要モードの解錠時のフローを示し、図８（Ｃ）にＰＩＮ必要モードに設定するフローを示し、図８（Ｄ）にＰＩＮ不要モードに設定するフローを示し、図８（Ｅ）にＰＩＮ必要モードでＰＩＮを入力するフローを示す。

図８（Ｆ）に、ＩＣチップ搭載携帯電話３０１（図３−１参照）のＩＣチップ３５０の電子キーカードＡＰ３５１内の関連ファイルの模式図を示す。電子キーカードＡＰ３５１はそれ自体がファイルであり、図８（Ａ）〜（Ｅ）の最初のステップの「Ｓｅｌｅｃｔ Ｆｉｌｅ」は電子キーカードＡＰ３５１を選択するステップである。電子キーカードＡＰ３５１の内部に「電子キー」、「ＰＩＮ（ＩＥＦ）」、「ＰＩＮ（ＥＦ）」の３つのファイルがある。「ＰＩＮ（ＩＥＦ）」は、ＰＩＮを保持しておくファイルである。このファイルへのＰＩＮの保存は、利用者によりＰＩＮの初期設定がなされた時点で行なわれ、その後は（利用者によりＰＩＮが変更されない限り）変更されない。また、セキュリティ上の要件から、外部からのこのファイルの読み出しはできないようになっている。このファイルは、ＰＩＮ認証のために用いられるものである。すなわち、ＩＣカードに対してＰＩＮが入力されたとき、入力されたＰＩＮが、ＰＩＮ（ＩＥＦ）に保持されているＰＩＮと合致するかをカード内で検証し、ＯＫ／ＮＧを返すために用いられる。「電子キー」は、電子キー（解錠ライセンス）を格納するファイルである。このファイルには、ＰＩＮ（ＩＥＦ）によるＰＩＮの照合が成功しない限り、読み出しはできないとする属性が付けられている（ＰＩＮ（ＩＥＦ）が電子キーに重なるように図示したのは、そのような関連があるとの意味である）。ＰＩＮ認証を行なうためには、上記のようにＩＣカードに対して利用者がＰＩＮを入力する必要があるが、このとき、利用者が入力したＰＩＮをそのまま、ＰＩＮ（ＩＥＦ）による認証に用いるのではなく、一旦「ＰＩＮ（ＥＦ）」に格納する。ＰＩＮ（ＥＦ）は外部からの読み出しが可能であり、認証においては、ドアがわ端末３０２がＰＩＮ（ＥＦ）に保持されたＰＩＮを読み出し、それをもって、ＩＣカードに対してＰＩＮ認証を要求する。
図８（Ａ）はＰＩＮ必要モードの解錠時のフローであり、ＩＣチップ搭載携帯電話３０１（図３−１参照）のＩＣチップ３５０の電子キーカードＡＰ３５１内では、電子キー（解錠ライセンス）を保持するファイルに対し、ＰＩＮ（ＩＥＦ）によるＰＩＮの照合が成功しない限り、読み出しはできないとする属性が付けられている。ＰＩＮ入力を必要とするモードに設定する際には、図８（Ｃ）に示すように、解錠ライセンスを保持するファイルの属性を、ＰＩＮ照合がなければ読み出し不可と設定しておけば良い（Ｍａｎａｇｅ Ａｔｔｒｉｂｕｔｅ（電子キー））。念のためこの時用いたＰＩＮ（ＥＦ）は消去する（Ｕｐｄａｔｅ Ｒｅｃｏｒｄ）。

図８（Ｅ）に示すように、利用者（ユーザ）は、解錠ライセンスの行使前に電子キーｉアプリ３６１からＰＩＮ入力を行い（Ｖｅｒｉｆｙ（ＰＩＮ））、入力されたＰＩＮはＩＣチップ３５０の電子キーカードＡＰ３５１内のＰＩＮ（ＥＦ）ファイル（図８（Ｆ）参照）に保持される。

利用者がＩＣチップ搭載携帯電話３０１をドアがわ端末３０２にかざした時、ドアがわ端末３０２では、図８（Ａ）に示すように、まずＰＩＮ（ＥＦ）ファイルを読み取り（Ｒｅａｄ Ｒｅｃｏｒｄ）、読み取られたＰＩＮを用いて、ＩＣチップ３５０に対し認証を行う（Ｖｅｒｉｆｙ（ＰＩＮ））。ＰＩＮ認証が成功すれば、解錠ライセンスが読み取り可能になるため、以降の解錠のための認証プロセス（解錠処理）に進むことができる。ただしこのとき、ＰＩＮの再利用を防ぐため、ＰＩＮ（ＥＦ）の内容はＰＩＮ認証の成否に関わらず、消去しておかなければならない（Ｕｐｄａｔｅ Ｒｅｃｏｒｄ）。なお、上記において、ＰＩＮ（ＥＦ）を用いる理由は、一般に、認証・ファイル属性指定用のＰＩＮ（ＩＥＦ）は、セキュリティ上読み取り不可でなければならないためである。

この方式において、ＰＩＮ入力を不要とするモードに設定する際には、図８（Ｄ）に示すように、利用者は電子キーｉアプリ３６１からＰＩＮ入力を行い（Ｖｅｒｉｆｙ（ＰＩＮ））、解錠ライセンスを保持するファイルに対する属性を、ＰＩＮ照合がなくても読み出し可能と設定しておけば良い（Ｍａｎａｇｅ Ａｔｔｒｉｂｕｔｅ（電子キー））。これにより、ドアがわ端末３０２はＰＩＮ認証に関する処理をすることなく、解錠のための認証プロセスを行うことができる（図８（Ｂ）参照）。また、ドアがわ端末３０２は現在のモードを知らずとも、ＰＩＮ入力が必須か不要かのモードを自動判別することも可能である。すなわち、まず解錠のための認証プロセスの冒頭で行う解錠ライセンスの読み出しを行うことにより、それが成功した場合はＰＩＮが不要なモードであり、失敗した場合は読み出しに制限がかかっているためＰＩＮ入力が必要なモードであると判断できる。

上記においては、ＰＩＮ入力はＩＣチップ搭載携帯電話３０１の電子キーｉアプリ３６１から行われるものとしていたが、ドアがわ端末３０２に組み込んだ１０キーを用いてＰＩＮ入力を行うことも可能である。この場合のフローはｉアプリから行う場合とほぼ同様であり、ＰＩＮを電子キーカードＡＰから読み出す代わりに、１０キーから取得すれば良い。

このとき、ドアがわ端末３０２はＰＩＮ入力がｉアプリからなされるか１０キーからなされるかを、予め知らずとも自動的に判別することができる。すなわち、１０キー入力およびＩＣカードリーダライタをセンスしておき、１０キー入力があった後一定の時間内にＩＣカードリーダライタにＩＣチップ搭載携帯電話がかざされたことを感知した場合は、１０キーからのＰＩＮ入力であり、そうではなく先にＩＣカードリーダライタでＩＣチップ搭載携帯電話を感知した場合は、ｉアプリからのＰＩＮ入力がなされていると判定すれば良い。

（実施例３．２）
図９にＰＩＮ認証方式の実現例２を示す。図９（Ａ）にＰＩＮ必要モードの解錠時のフローを示し、図９（Ｂ）にＰＩＮ必要モードに設定するフローを示し、図９（Ｃ）にＰＩＮ不要モードに設定するフローを示し、図９（Ｄ）にＰＩＮ必要モードでＰＩＮを入力するフローを示す。

図９（Ｅ）に、電子キーカードＡＰ３５１内の関連ファイルの模式図を示す。図９（Ｅ）は図８（Ｆ）とほぼ同様である。異なる点は、図８（Ｆ）ではＰＩＮ（ＥＦ）が利用者から入力されたＰＩＮのみを保持するのに対して、図９（Ｅ）では「ＰＩＮ＋ＭｏｄｅＢｉｔ（ＥＦ）」となっており、利用者から入力されたＰＩＮに加えて、現在のモードを表すビット（すなわちＰＩＮ必要モードを示すフラグ）もあわせて保持される点である。このモードビットは、ＰＩＮ必要モードではＰＩＮの再利用を防ぐため「ＰＩＮ＋ＭｏｄｅＢｉｔ（ＥＦ）」に保持されているＰＩＮを毎回消去する必要があるのに対し、ＰＩＮ不要モードでは消去しないため、現在のモードがいづれであるかをドアがわ端末３０２が知るために用いられる。

実施例３．１同様、電子キーカードＡＰ３５１内では、電子キー（解錠ライセンス）を保持するファイルに対し、ＰＩＮ（ＩＥＦ）によるＰＩＮの照合が成功しない限り、読み出しはできないとする属性が付けられている（図９（Ｂ）にＰＩＮ必要モードに設定するフローが示されている）。図９（Ｄ）に示すように、解錠ライセンスの行使前に利用者が電子キーｉアプリ３６１からＰＩＮ入力を行い、入力されたＰＩＮが電子キーカードＡＰ３５１内のＰＩＮ（ＥＦ）ファイルに保持されるのも実施例３．１と同様であるが、このとき、ＰＩＮ（ＥＦ）には現在のモードを表すビット（すなわちＰＩＮ必要モードを示すフラグ）もあわせて保持される（図９（Ｅ）参照）。

利用者がＩＣチップ搭載携帯電話３０１をドアがわ端末３０２にかざした時、図９（Ａ）に示すように、実施例３．１同様、ドアがわ端末３０２ではまずＰＩＮ（ＥＦ）ファイルを読み取り（Ｒｅａｄ Ｒｅｃｏｒｄ）、読み取られたＰＩＮを用いて、ＩＣチップに対し認証を行う（Ｖｅｒｉｆｙ（ＰＩＮ））。ＰＩＮ認証が成功すれば、解錠ライセンスが読み取り可能になるため、以降の解錠のための認証プロセス（解錠処理）に進むことができる。このとき、ＰＩＮの再利用を防ぐため、ＰＩＮ（ＥＦ）の内容はＰＩＮ認証の成否に関わらず、消去しておかなければならないが、この処理は実施例３．１とはことなり、現在のモードがＰＩＮ必要モードである時のみである（現在のモードはＰＩＮ（ＥＦ）に保持されているビットから知ることが出来る）。

この方式において、ＰＩＮ入力を不要とするモードに設定する際には、図８（Ｃ）に示すように、利用者にＰＩＮを入力させ、それが正しいものであることを確認した後、正しいＰＩＮと、ＰＩＮ不要モードを表すフラグとをＰＩＮ（ＥＦ）に保持しておく。これにより、ドアがわ端末３０２は常に正しいＰＩＮを取得することができ、従って実効上は利用者が改めてＰＩＮ入力を行うことなく、解錠のための認証プロセスを行うことができる。このとき、ドアがわ端末３０２は予め現在のモードを知る必要がなく処理を行うことができるが、ＰＩＮ（ＥＦ）のＰＩＮを消去するか否かを判断するためには、ＰＩＮを読み取ると同時に現在のモードも読み取り、動作を変える必要がある。

上記においては、ＰＩＮ入力はＩＣチップ搭載携帯電話３０１の電子キーｉアプリ３６１から行われるものとしていたが、ドアがわ端末３０２に組み込んだ１０キーを用いてＰＩＮ入力を行うことも、実施例３．１同様、可能である。

（実施例４）
図１０に配信情報の形式を、会議室予約の場合の例で示す。図において、一行がひとつの配信情報の単位を表し、ひとつの配信情報単位は、複数の配信条件とひとつの配信情報から構成される。

配信条件は、利用者（クラス）、ゲート（クラス）、時間、解錠回数、配信回数からなり、これらに対する条件がアンド条件で判定される。ここで表中の「^＊」はドントケア条件（すなわち任意の場合にマッチする）を示す。利用者（クラス）の欄には、特定の利用者（図中では「▲さん」）あるいは利用者クラス（グループ化された利用者。図中では「一般職」）を記述することができる。ゲート（クラス）に関しても同様である。時間の欄では、ここでは時間帯を複数書くことができる（オア条件。なお、ウィークリーマンションの場合などは時間帯ではなく、開始−終了日時の組を複数書くことになる）。解錠回数、配信回数は、当該ドアまたは当該情報に対する解錠または情報配信の回数をカウントしておき、それが特定の値または範囲になった時情報を配信することを示す。このような条件指定を評価し、合致する行（複数合致することがあるが、その場合すべて）の配信情報内容を、対象の情報配信内容とする。

ドアがわ端末３０２には予めこの表形式が配布されており、解錠が行われる度に条件判定を行い、配信されるべき情報内容を決定する（メール経由での情報配信を行う場合は、解錠通知をもとにサーバにて条件判定を行う）。

配信情報内容には、利用者名や部屋名、予約時間帯などを含めることができる。配信情報内容の記載にあたっては、その部分を特定の文字列で示しておき、配信を行う際に実際の値に置換を行う。置換されるべき実際の値は、利用者名等予約に関わる情報であれば解錠ライセンスから取得することができる。また、部屋名などであれば、ドアがわ端末の固有情報として、個々のドアがわ端末において処理することが可能である。

（実施例５）
図１１に情報配信の画面例を示す。
図１１はウィークリーマンションの場合を例とし、配信された情報をｉアプリ画面で表示する際の例である。情報配信ｉアプリ３６７（図３−１参照）では、情報配信カードＡＰ３５４（図３−１参照）に書き込まれた情報を読み出し最新の配信情報を表示するが、このとき過去数回の配信情報も保持されており、必要に応じて読み出し・表示することができる。なお、ｉアプリを用いるため、テキスト情報のみならず、ハイパーリンクも配信情報に含めることが可能である。

図１１においては、初回の解錠時と二回目以降とでは、実施例４に記載された配信条件の設定を用いて、異なる情報が配信される場合を想定している。また、図１１の「二回目以降」の部分では、一度に配信される情報量を加減できるようにすることを想定している。これは、情報配信の時間が配信される情報量に比例し、またＩＣチップの記憶容量には限りがあるため、実用時において最適なトレードオフをみつけられるようにとの配慮からである。図１１の例においては、フル〜短縮の情報量の想定は、およそ３８４〜１２８バイトである。情報配信量のコントロール方法としては、実施例４において複数行の情報配信単位を選択することができることを利用して、それぞれの行にプライオリティを付けておく方法（すなわち、必ず配信する、短縮では省略する、フルでのみ配信する、等）、あるいは、ひとつの情報配信単位での配信情報欄を更に細分しておく方法（すなわち必ず配信する部分、短縮では省略される部分、フルでのみ配信する部分、等）、などが考えられる。

以上説明した実施形態および実施例の各装置はその機能または動作を実現する手段を有しており、その手段はハードウェアで構成しても、その一部または全部を記憶装置に記憶されたプログラムとそのプログラムを処理するＣＰＵで構成してもよい。

以上、本発明者によってなされた発明を、前記実施形態、実施例に基づき具体的に説明したが、本発明は、前記実施形態、実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

従来の共通鍵暗号を用いた鍵サービスのフロー 本発明の実施形態の鍵サービスのフロー 本発明の実施形態のシステム構成概要図 解錠ライセンス管理／情報配信サーバ３０３の詳細図 ＩＣチップ搭載携帯電話３０１の詳細図 ドアがわ端末３０２の制御端末３７０の詳細図 解錠ライセンスフォーマット例１（実施例１．１） 解錠ライセンスフォーマット例２（実施例１．２） ウィークリーマンションサービスへ適用した時の予約画面遷移（実施例２．１） 会議室予約サービスへ適用した時の予約画面遷移（実施例２．２） ＰＩＮ入力方式の実現例１（実施例３．１） ＰＩＮ入力方式の実現例２（実施例３．２） 配信情報の形式例（実施例４） 情報配信画面例（実施例５）

符号の説明

１…利用者が携帯する装置（携帯電話）、２…ゲート（ドアがわ装置）、３…サーバ、４…鍵管理者、３１…利用者が携帯する装置（ＩＣチップ搭載携帯電話）、３２…ゲート（ドアがわ装置）、３３…サーバ、３４…鍵管理者、３０１…ＩＣチップ搭載携帯電話、３０２…ドアがわ端末、３０３…解錠ライセンス管理／情報配信サーバ、３１０…解錠ライセンス管理サーバ、３２０…配信情報配信サーバ、３３０…利用者管理・Ｗｅｂ Ｕ／Ｉ、３５０…ＩＣチップ、３５１…電子キーカードＡＰ、３５４…情報配信ＡＰ、３６０…ｉアプリ、３６１…電子キーｉアプリ、３６７…情報配信ｉアプリ、３７０…制御端末、３７１…ゲート端末ＡＰ、３７６…情報配信ＡＰ、３８０…ドアゲート、３８１…電気錠、３８２…電気錠コントローラ、３８３…非接触ＩＣカードリーダライタ

Claims (8)

1. 錠の施錠・解錠を行う施錠・解錠装置が、利用者が携帯する装置から鍵管理者の秘密鍵による署名を含む電子的な鍵である解錠ライセンスを受信するステップと、
   前記施錠・解錠装置が、前記鍵管理者の公開鍵を用いた前記解錠ライセンスの署名の検証および前記解錠ライセンスの検証を行うステップと、
   前記施錠・解錠装置が前記利用者が携帯する装置に対してチャレンジを送信し、前記利用者が携帯する装置が前記チャレンジに対して前記利用者の秘密鍵により署名演算を行い前記施錠・解錠装置にレスポンスを送信し、前記施錠・解錠装置が前記利用者の公開鍵を用いてレスポンスを検証するステップと、
   前記施錠・解錠装置が、前記解錠ライセンスの署名の検証および前記解錠ライセンスの検証および前記レスポンスの検証に成功した場合に、錠の解錠または施錠を行うステップと、
   前記解錠または施錠を契機として、前記施錠・解錠装置が前記利用者が携帯する装置にハイパーリンクを含む情報およびアプリケーションの起動指示を非接触通信により配信し、前記利用者が携帯する装置がアプリケーションを起動し配信された前記ハイパーリンクを含む情報を画面に表示させるステップと、
   を有する鍵サービス方法。
2. 請求項１に記載の鍵サービス方法であって、
   サーバが、利用者が携帯する装置から前記利用者の秘密鍵による署名を含む情報を受信するステップと、
   前記サーバが、前記利用者の公開鍵を用いた前記利用者の検証および解錠許可の検証に成功した場合に、前記解錠ライセンスを前記利用者が携帯する装置に送信するステップと、
   を有する鍵サービス方法。
3. 請求項１または２に記載の鍵サービス方法であって、
   前記利用者によるＰＩＮ入力が成功した後、前記施錠・解錠装置が、前記利用者が携帯する装置から前記解錠ライセンスを受信する鍵サービス方法。
4. 請求項３に記載の鍵サービス方法であって、
   前記ＰＩＮ入力が必須の動作と、それを必須としない動作を切り替えるステップを有する鍵サービス方法。
5. 請求項１ないし４のうちいずれか１項に記載の鍵サービス方法であって、
   前記利用者が携帯する装置はＴｙｐｅＢ ＩＣチップ搭載携帯電話である鍵サービス方法。
6. 請求項１ないし５のうちいずれか１項に記載の鍵サービスで方法あって、
   前記施錠・解錠装置と前記利用者が携帯する装置との間の通信を非接触通信で行う鍵サービス方法。
7. 請求項１ないし６のうちいずれか１項に記載の鍵サービス方法を行う前記サーバ、前記施錠・解錠装置、および前記利用者が携帯する装置を有する鍵サービスシステム。
8. 請求項１ないし７のうちいずれか１項に記載の鍵サービス方法のステップをコンピュータに実行させるためのプログラム。

Images