アクセスの制御は、アクセスを選択的に許可するコントローラを有する、アクセスに対するバリアを設けることと、資格認証／証明を生成する少なくとも１つの管理エンティティを有し、期限が過ぎた証明に対する資格証明と値だけが所与の場合には有効な証明が確定不可能であると設定され、コントローラは資格認証／証明を受信し、コントローラはアクセスが現在認可されているか否かを判定し、もし、アクセスが現在認可されているならば、コントローラはアクセスを許可する。資格認証／証明は１つの部品内にあり、または、資格認証／証明は別個の部品内にあってよい。資格認証を生成する第１の管理エンティティと、証明を生成する他の管理エンティティがあってもよい。第１の管理エンティティは証明をも生成し、または、第１の管理エンティティは証明を生成しなくてもよい。資格認証は、一方向性関数を、複数の証明のうちの第１の証明に適用した結果である最終値を含むディジタル証明書に対応することがある。

【発明の詳細な説明】
【技術分野】
【０００１】
本出願は物理的アクセス制御の分野に関し、特に、処理装置作動式のロックおよび関連データを用いる物理的アクセス制御の分野に関する。
【０００２】
関連出願へのクロス・レファレンス
本出願は、２００３年７月１８日出願、米国仮特許出願６０／４８８，６４５号に基づく優先権を主張する。この仮特許出願は、引用によって本明細書に挿入されている。また、本出願は、２００３年９月２４出願、米国仮特許出願６０／５０５，６４０号に基づく優先権を主張する。この仮特許出願は、引用によって本明細書に挿入されていて、２００４年６月２４日出願、米国特許出願１０／８７６，２７５号（係属中）の一部継続出願である。米国特許出願１０／８７６，２７５号は、２００３年６月２４日出願、米国仮特許出願６０／４８２，１７９に基づく優先権を主張し、２００１年６月２５日出願、米国特許出願０９／９１５，１８０号（係属中）の一部継続出願である。米国特許出願０９／９１５，１８０号は、２０００年１月１４日出願、米国特許出願０９／４８３，１２５号（現在米国特許６，２９２，８９３号）の継続出願である。米国特許出願０９／４８３，１２５号は、１９９９年６月１９日出願、米国特許出願０９／３５６，７４５号（放棄）の継続出願である。米国特許出願０９／３５６，７４５号は、１９９７年３月２４日出願、米国特許出願０８／８２３，３５４号（現在米国特許５，９６０，０８３号）の継続出願である。米国特許出願０８／８２３，３５４号は、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許５，６６６，４１６号）の継続出願で、米国特許出願０８／５５９，５３３号は、１９９５年１０月２４日出願、米国仮特許出願６０／００６，０３８号に基づく優先権を主張し、２００３年４月８日出願、米国特許出願１０／４０９，６３８号（係属中）の一部継続出願である。米国特許出願１０／４０９，６３８号は、
２００２年４月８日出願、米国仮特許出願６０／３７０，８６７号
２００２年４月１６日出願、米国仮特許出願６０／３７２，９５１号
２００２年４月１７日出願、米国仮特許出願６０／３７３，２１８号
２００２年４月２３日出願、米国仮特許出願６０／３７４，８６１号
２００２年１０月２３日出願、米国仮特許出願６０／４２０，７９５号
２００２年１０月２５日出願、米国仮特許出願６０／４２１，１９７号、
２００２年１０月２８日出願、米国仮特許出願６０／４２１，７５６号
２００２年１０月３０日出願、米国仮特許出願６０／４２２，４１６号
２００２年１１月１９日出願、米国仮特許出願６０／４２７，５０４号
２００３年１月２９日出願、米国仮特許出願６０／４４３，４０７号および
２００３年２月１０日出願、米国仮特許出願６０／４４６，１４９号
に基づく優先権を主張している。米国特許出願１０／４０９，６３８号の優先権主張の基礎をなす上記出願の全ての教示内容は、引用によって本明細書に挿入されたものとする。そして、米国仮特許出願１０／４０９，６３８号は２００２年３月２０日出願、米国特許出願１０／１０３，５４１号（係属中）の一部継続出願である。米国特許出願１０／１０３，５４１号の教示内容は引用によって本明細書に挿入されたものとする。米国特許出願１０／１０３，５４１号は、それ自身、２００１年７月２５日出願、米国特許出願０９／９１５，１８０号（係属中）の一部継続出願であり、かつ、２０００年１月１４日出願、米国特許出願０９／４８３，１２５号（現在米国特許６，２９２，８９３号）の継続出願である。米国特許出願０９／４８３，１２５号は、１９９９年７月１９日出願、米国特許出願０９／３５６，７４５号（放棄）の継続出願である。米国特許出願０９／３５６，７４５号号は１９９７年３月２４日出願、米国特許出願０８／８２３，３５４号（現在米国特許５，９６０，０８３号）の継続出願である。米国特許出願０８／８２３，３５４号は、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許５，６６６，４１６）の継続出願である。米国特許出願０８／５５９，５３３号は、１９９５年１０月２４日出願、米国仮特許出願６０／００６，０３８号に基づいている。米国特許出願１０／１０３，５４１号は、また、１９９７年１２月１８日出願、米国特許出願０８／９９２，８９７号（現在米国特許６，４８７，６５８号）の一部継続出願である。米国特許出願０８／９９２，８９７号は、１９９６年１２月１８日出願、米国仮特許出願６０／０３３，４１５号に基づき、かつ、１９９６年９月１９日出願、米国特許出願０８／７１５，７１２号（放棄）の一部継続出願である。米国特許出願０８／７１５，７１２は、１９９５年１０月２日出願、米国仮特許出願６０／００４，７９６号に基づいている。米国特許出願０８／９９２，８９７号は、また、１９９６年１０月１１日出願、米国特許出願０８／７２９，６１９号（現在米国特許６，０９７，８１１号）の一部継続出願である。米国特許出願０８／７２９，６１９号は、１９９５年１１月２日出願、米国仮特許出願６０／００６，１４３号に基づいている。米国特許出願０８／９９２，８９７号は、また、１９９７年２月２４日出願、米国特許出願０８／８０４，８６８号（放棄）の一部継続出願である。米国特許出願０８／８０４，８６８号は、１９９６年１１月１日出願、米国特許出願０８／７４１，６０１号（放棄）の継続出願である。米国特許出願０８／７４１，６０１号は、１９９５年１１月２日出願、米国仮特許出願６０／００６，１４３号に基づいている。米国特許出願０８／９９２，８９７号は、また、１９９７年６月１１日出願、米国特許出願０８／８７２，９００号（放棄）の一部継続出願である。米国特許出願０８／８７２，９００号は、１９９６年１１月５日出願、米国特許出願０８／７４６，００７号（現在米国特許５，７９３，８６８号）の継続出願である。米国特許出願０８／７４６，００７号は、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号に基づいている。米国特許出願０８／９９２，８９７号は、また、１９９７年２月３日出願、米国仮特許出願６０／０３５，１１９号に基づいていて、かつ、１９９７年８月５日出願、米国特許出願０８／９０６，４６４号（放棄）の一部継続出願である。米国特許出願０８／９０６，４６４号は、１９９６年１２月９日出願、米国特許出願０８／７６３，５３６号（現在米国特許５，７１７，７５８号）の一部継続出願である。米国特許出願０８／７６３，５３６号は、１９９６年９月１０日出願、米国仮特許出願６０／０２４，７８６号に基づき、１９９６年４月２３日出願、米国特許出願０８／６３６，８５４号（現在米国特許５，６０４，８０４号）の一部継続出願であって、かつ、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号にも基づいている。米国特許出願０８／９９２，８９７号は、また、１９９６年１１月２６日出願、米国特許出願０８／７５６，７２０号（放棄）の一部継続出願である。米国特許出願０８／７５６，７２０号は、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号に基づき、１９９６年９月１９日出願、米国特許出願０８／７１５，７１２号（放棄）の一部継続出願であり、かつ、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許５，６６６，４１６号）の一部継続出願である。米国特許出願０８／９９２，８９７号は、また、１９９６年１１月１９日出願、米国特許出願０８／７５２，２２３号（現在米国特許Ｎｏ５，７１７，７５７号）の一部継続出願である。この米国特許出願０８／７５２，２２３号は、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号に基づき、１９９７年２月２４日出願、米国特許出願０８／８０４，８６９号（放棄）の一部継続出願でもある。米国特許出願０８／８０４，８６９号は、１９９６年１１月１日出願、米国特許出願０８／７４１，６０１号（放棄）の継続出願である。米国特許出願０８／７４１，６０１号は、１９９５年１１月２日出願、米国仮特許出願６０／００６，１４３号に基づいている。米国特許出願０８／９９２，８９７号、また、１９９７年３月２４日出願、米国特許出願０８／８２３，３５４号（現在米国特許５，９６０，０８３号）の一部継続出願である。米国特許出願０８／８２３，３５４号は、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許５，６６６，４１６号）の継続出願である。米国特許出願０８／５５９，５３３号は１９９５年１０月２４日出願、米国仮特許出願６０／００６，０３８号に基づいている。米国特許出願１０／１０３，５４１号は、また、２００１年３月２０日出願の米国仮特許出願６０／２７７，２４４号、２００１年６月２５日出願の米国仮特許出願６０／３００，６２１号および２００１年１２月２７日出願の米国仮特許出願６０／３４４，２４５号に基づいている。上記の全ては引用によって本明細書に挿入されたものとする。米国特許出願１０／４０９，６３８号は、また、２００１年６月２５日出願、米国特許出願０９／９１５，１８０号（係属中）の一部継続出願であり、米国特許出願０９／９１５，１８０号の教示内容は、引用によって本明細書に挿入されたものとする。米国特許出願０９／９１５，１８０号それ自身は２０００年１月１４日出願、米国特許出願０９／４８３，１２５号（現在米国特許６，２９２，８９３号）の継続出願である。米国特許出願０９／４８３，１２５号は、１９９９年７月１９日出願、米国特許出願０９／３５６，７４５号（放棄）の継続出願である。米国特許出願０９／３５６，７４５号は、１９９７年３月２４日出願、米国特許出願０８／８２３，３５４号（現在米国特許５，９６０，０８３号）の継続出願である。米国特許出願０８／８２３，３５４号は、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許５，６６６，４１６号）の継続出願である。米国特許出願０８／５５９，５３３号は、１９９５年１０月２４日出願、米国仮特許出願６０／００６，０３８号に基づいている。全ての上記引用の教示内容は引用によって本明細書に挿入されたものとする。米国特許出願１０／４０９，６３８号は、また、２００３年３月２１日出願、米国特許出願１０／３９５，０１７号（係属中）の一部継続出願で、米国特許出願１０／３９５，０１７号の教示内容は、引用によって本明細書に挿入されたものとし、米国特許出願１０／３９５，０１７号自身は、２００２年９月１６日出願、米国特許出願１０／２４４，６９５号（放棄）の継続出願である。米国特許出願１０／２４４，６９５号は、１９９７年１２月１８日出願、米国特許出願０８／９９２，８９７号（現在米国特許６，４８７，６５８号）の継続出願である。米国特許出願０８／９９２，８９７号は、１９９６年１２月１８日出願、米国仮特許出願６０／０３３，４１５号に基づいていて、１９９６年９月１９日出願、米国特許出願０８／７１５，７１２号（放棄）の一部継続出願である。米国特許出願０８／７１５，７１２号は、１９９５年１０月２日出願、米国仮特許出願６０／００４，７９６号に基づいていて、かつ、１９９６年１０月１０日出願、米国特許出願０８／７２９，６１９号（現在米国特許６，０９７，８１１号）の一部継続出願である。米国特許出願０８／７２９，６１９号は、１９９５年１１月２日出願、米国仮特許出願６０／００６，１４３号に基づき、かつ、１９９７年２月２４日出願、米国特許出願０８／８０４，８６８号（放棄）の一部継続出願である。米国特許出願０８／８０４，８６８号は、１９９６年１１月１日出願、米国特許出願０８／７４１，６０１号（放棄）の継続出願である。米国特許出願０８／７４１，６０１号は、１９９５年１１月２日出願、米国仮特許出願６０／００６，１４３号に基づき、かつ、１９９７年６月１１日出願、米国特許出願０８／８７２，９００号（放棄）の一部継続出願である。米国特許出願０８／８７２，９００号は、１９９６年１１月５日出願、米国特許出願０８／７４６，００７号（現在米国特許５，７９３，８６８号）の継続出願である。米国特許出願０８／７４６，００７号は、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号に基づき、かつ、１９９７年２月３日出願、米国仮特許出願６０／０３５，１１９号に基づき、かつ、１９９７年８月５日出願、米国特許出願０８／９０６，４６４号（放棄）の一部継続出願である。米国特許出願０８／９０６，４６４号は、１９９６年１２月９日出願、米国特許出願０８／７６３，５３６号（現在米国特許５，７１７，７５８号）の継続出願である。米国特許出願０８／７６３，５３６号は、１９９６年９月１０日出願、米国仮特許出願６０／０２４，７８６号に基づき、かつ、１９９７年４月２３日出願、米国特許出願０８／６３６，８５４号（現在米国特許５，６０４，８０４号）と１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号の継続出願で、かつ、１９９６年１１月２６日出願、米国特許出願０８／７５６，７２０号（放棄）の一部継続出願である。米国特許出願０８／７５６，７２０号は、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号に基づき、かつ、１９９６年９月１９日出願、米国特許出願０８／７１５，７１２号（放棄）の一部継続出願であり、かつ、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許Ｎｏ５，６６６，４１６）号）の一部継続出願である。また、米国特許出願０８／７５６，７２０号は、１９９６年１１月１９日出願、米国特許出願０８／７５２，２２３号（現在米国特許５，７１７，７５７号）の一部継続出願である。米国特許出願０８／７５２，２２３号は、１９９６年８月２９日出願、米国仮特許出願６０／０２５，１２８号に基づき、かつ、１９９７年２月２４日出願、米国特許出願０８／８０４，８６９号（放棄）の一部継続出願である。米国特許出願０８／８０４，８６９号は、１９９６年１１月１日出願、米国特許出願０８／７４１，６０１号（放棄）の継続出願である。米国特許出願０８／７４１，６０１号は、１９９５年１１月２日出願、米国仮特許出願６０／００６，１４３号に基づき、かつ、１９９７年３月２４日出願、米国特許出願０８／８２３，３５４号（現在米国特許５，９６０，０８３号）の一部継続出願である。米国特許出願０８／８２３，３５４号は、１９９５年１１月１６日出願、米国特許出願０８／５５９，５３３号（現在米国特許５，６６６，４１６号）の継続出願である。米国特許出願０８／５５９，５３３号は、１９９５年１０月２４日出願、米国仮特許出願６０／００６，０３８号に基づいている。上記の全ての引用の教示内容は、引用によって本明細書に挿入されたものとする。
【背景技術】
【０００３】
認可された個人のみが、保護された区域または装置にアクセスしてもよいことを確実なものとすることは、空港、軍事施設、オフィッスビルディング等へのアクセスの場合なごのように多くの場合に重要である。機密事項を扱う区域の保護のために従来のドアや壁が使用されることあるが、従来の錠や鍵を備えたドアは多くのユーザをもつ環境においては管理することが厄介である。たとえば、従業員が一旦解雇されると、その元従業員に、雇用時に付与されていた物理鍵を回収することが困難である場合がある。さらに、そのような鍵の複製が作られて引き渡されないという危険があり得る。
【０００４】
スマートドアはアクセス制御を行う。幾つかの例においては、スマートドアは、ユーザが自分のＰＩＮまたはパスワードを入力するキーパッドを備えていることがある。キーパッドは、複数の正当なＰＩＮ／パスワードのリストを格納してもよい。付属のメモリおよび／または簡単なプロセッサを備えていることがある。したがって、ドアは、現在入力されたＰＩＮが現在正当なリストに属しているかどうかをチェックしてもよい。もし属しているならば、ドアは開かれる。そうでなければ、ドアはロックされたままである。勿論、（単に）従来の鍵や簡単なキーパッドに頼らずに、さらに近代的なスマートドアが、カード（スマート・カードや磁気ストリップカードのような）または非接触装置（たとえば、ＰＤＡやセルフォン等）で作動させる。そのようなカードまたは装置は、従来形の鍵または電子的キーパッドに加えて、またはそれらの代わりに使用してもよい。ユーザによって携帯されるように設計された、そのような磁気ストリップカード、スマート・カード、または非接触装置は、ドアに送信される情報を格納する機能を有していることができる。さらに進歩したカードは、演算および通信の機能ももつことがある。ドア上の対応装置はカードから情報を読みとり、そして、おそらく、カードと対話型のプロトコルで接続し、コンピュータ等と通信をしてもよいであろう。
【０００５】
ドアの態様はその接続性のレベルである。完全に接続されたドアは、あるデータベース（または他のコンピュータシステム）に常時接続されているドアである。たとえば、データベースは、現在正当なカード、ユーザ、ＰＩＮ等に関する情報を含むことある。幾つかの例では、敵対者がドアへ流れる情報を変更することを防止するために、そのような接続は（たとえば、ドアからデータベースへスチールのパイプ内に配線を敷設することによって）確実なものとされる。一方、全く接続されていないドアは、そのすぐ近傍の外側とは通信をしない。これらの２つの極端の中間に断続的な接続性をもつドア（たとえば、航空機やトラックのドアのように、地上の部署の範囲内にあるときにのみ、外部と通信してもよい、無線接続される「移動」ドア）がある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来のアクセス制御機構は多くの欠点がある。完全に接続されたドアは非常に高価である。セキュリティ保護されたパイプを遠方のスマートドアへ配管するコストは、スマートドアそれ自体のコストを遙かに超えることがある。配線を暗号法的に保護することは、多分、もっと安価であろうが、それでもそれ自身のコスト（たとえば、暗号キーを保護し管理するコスト）をもっている。そのうえ、スチールのパイプや保安要員がない暗号法は配線が切断されることを防止することができない。配線が切断された場合には、もはや接続されていないドアは２つの極端な選択肢、すなわち、いずれも望ましくない、常時、閉じたままかまたは常時開いたままかのどれかを選択することを余儀なくされる。とにかく、ドアを完全に接続することは、多くの場合、実行可能な選択ではない（たとえば、大西洋の真ただ中において、海面より下の貨物コンテナのドアは、全く実用上の目的から完全に非接続にされる）。
【０００７】
非接続のスマートドアは、接続されたドアよりも安価である場合がある。しかし、スマートドアに対する従来の取り組みは、それ自体の問題を持っている。たとえば、非接続のスマートドアがＰＩＮを認できるとする。解雇された従業員は、もはや、そのドアを通ることを認可されていないかもしれない。しかし、もし、その従業員が未だ自身のＰＩＮを覚えているならば、彼は、そのような初歩的はスマートドアを難なく開くことができるであろう。したがって、解雇された従業員のＰＩＮを「プログラム解除する」（ｄｅｐｒｏｇｒａｍ）ことが必要だろうが、それは非接続のドアには困難である。実際、そのような方法は厄介で、かつ、費用がかかる。すわち、空港の設備には何百というドアがある場合があり、一人の従業員が退職し、または、解雇されるごとに特別のチームの作業員を派遣してそのようなドアをすべてプログラム解除することは余りにも非実際的であろう。
【０００８】
完全に接続されたドアに関するセキュリティのレベルをその付加的なコストを招くことなく設けることが望ましい。実証したように、非接続のスマートドアおよびカードは、それだけでは、アクセス制御システムのセキュリティ、利便性、低コストを保証するものではない。
【課題を解決するための手段】
【０００９】
本発明によると、アクセスの制御は、選択的にアクセスを許可するコントローラを有する、アクセスに対するバリアを設けることと、少なくとも１つの管理エンティティが資格認証（ｃｒｅｄｅｎｔｉａｌｓ）／証明（ｐｒｏｏｆｓ）を生成し、期限が過ぎた証明に対する資格証明と値だけが所与の場合には有効な証明が確定不可能であるとし、コントローラは資格認証／証明を受信し、コントローラはアクセスが現在認可されているか否かを判定し、もし、アクセスが現在認可されているならば、コントローラはアクセスを許可する。資格認証／証明は１つの部品内または別個の部品内にあってよい。資格認証を生成する第１の管理エンティティと、証明を生成する他の管理エンティティがあってよい。第１の管理エンティティは証明をも生成し、または第１の管理エンティティは証明を生成しないでよい。資格認証は、一方向性関数を複数の証明のうちの第１の証明に適用した結果である最終値を含むディジタル証明書に対応してよい。証明の各々は、一方向関数を複数の証明のうちの将来の証明に適用した結果であってよい。ディジタル証明書は、電子装置に対する識別子を含んでよい。資格認証は、一方向性関数を複数の証明のうちの第１の証明に適用した結果である最終値を含んでよい。複数の証明の各々は、一方向性関数を、該証明の将来の証明に適用した結果であってよい。資格証明はアクセスを要求しているユーザに対する識別子を含んでよい。資格認証／証明がディジタル署名を含んでよい。アクセスに対するバリアが複数の壁およびドアを含んでよい。アクセスを制御することが、コントローラに接続されたドアロックを設けることを含んでよく、該コントローラがアクセスを許可することは、該コントローラが、ドアを開くことができるようにするためにドアロックを作動させることを含んでいる。アクセスを制御することは、コントローラに接続された読み取り器を設けることを含んでもよく、その場合には、コントローラは該読み取り器から資格認証／証明を受け取る。資格認証／証明はユーザによって提示されるスマート・カード上に設けてもよい。アクセスを制御することは、コントローラへの外部接続を設けることをも含んでよい。外部接続が断続的であってよい。コントローラが外部接続を用いて資格認証／複数の証明の少なくとも一部を受け取り、または、コントローラが前記外部接続を用いて資格認証／証明の全てを受け取ってもよい。アクセスを制御することは、コントローラに接続された読み取り器を設けることを含んでもよく、その場合には、コントローラは読み取り器から資格認証／証明の残りの部分を受け取る。資格認証／証明は、ユーザによって提示されるスマート・カード上に設けてもよい。資格認証／証明は、ユーザによって書き込まれたパスワードを含んでよい。資格認証／証明は、ユーザの生体認証情報を含んでよい。資格認証／証明は、手書きの署名を含んでよい。資格認証／証明は、ユーザによって保持されるカード上に設けられた秘密値を含んでよい。資格認証／証明は所定の時に満了してもよい。
【００１０】
さらに本発明によると、複数のユーザの、少なくとも１つの非接続のドアへのアクセスを制御するエンティティは、一連の日付の期間ｄごとに複数のユーザをグループにマッピングすることと、認可機関に、該グループの構成員が期間ｄの間にドアにアクセスしてもよいことを示すディジタル署名ＳＩＧＵＤｄを生成させることと、該グループの少なくとも1人の構成員に、ドアを通過するために、そのドアに提示するためのＳＩＧＵＤｄを期間ｄの間受け取らせることと、該グループの前記少なくとも1人の構成員に、ＳＩＧＵＤｄをドアＤに提示させることと、（ｉ）ＳＩＧＵＤｄは、該グループの構成員が期間ｄに該ドアにアクセスしてもよいことを示す、認可機関のディジタル署名であり、（ｉｉ）現在の時間が期間ｄ内にあることを検証した後、ドアを開かせることを含む。グループの前記少なくとも1人の構成員はユーザカードを所持し、ドアは電磁気的ロックに接続されたカード・読み取り器を備え、そして、グループの前記少なくとも1人の構成員は、ＳＩＧＵＤｄをユーザカードに格納することによってＳＩＧＵＤｄを受け取り、カード・読み取り器によってユーザカードを読むことによってドアにＳＩＧＵＤｄを提示してもよい。認可機関は、グループの前記少なくとも1人の構成員がアクセスしてもよいデータベースへＳＩＧＵＤｄを書き込むことによってグループの前記少なくとも1人の構成員に期間ｄの間にＳＩＧＵＤｄを受け取らせるようにしてもよい。ＳＩＧＵＤｄは公開キー署名であってよく、ドアは、認可機関の公開キーを記憶してもよい。ドアは、グループの前記少なくとも1人の構成員に関する同一性情報を検証してもよい。グループの前記少なくとも1人の構成員に関する同一性情報は、ＰＩＮとドアのチャレンジに対する返答のうちの少なくとも１つを含んでよい。
【００１１】
さらに、本発明によると、物理的アクセスを制御することは、リアルタイム資格認証をユーザのグループに割り当てることと、固定されている第１の部分と定期的に変更される第２の部分を含み、第２の部分が、リアルタイム資格認証が現在通用するという証明を与える、そのリアルタイム資格認証を再検討することと、第１の部分に演算を行ってその結果を第２の部分と比較することによってそのリアルタイム資格認証の正当性と検証することと、リアルタイム資格認証が正当であると検証された場合にのみ物理的アクセスをグループの構成員に許可することを含む。第１の部分は、認可機関によってディジタル署名をされてもよい。認可機関は第２の部分を生成してもよい。第２の部分は認可機関以外のエンティティによって生成されてもよい。リアルタイム資格認証はスマート・カード上に設けてもよい。グループの構成員は、リアルタイム資格認証の第２の部分を第１の指定位置で得てもよい。グループの構成員は第１の指定位置と異なり、かつ、第１の指定位置から離れた第２の指定位置へのアクセスを許可されてもよい。リアルタイム資格認証の第１の部分の少なくとも一部は、リアルタイム資格認証の第２の部分の一部分に複数回適用される一方向性ハッシュを表してもよい。上記複数回は、リアルタイム資格認証の第１の部分が発行されてから経過した時間に対応してもよい。物理的アクセスを制御することは、ドアを通るアクセスを制御することも含んでよい。
【００１２】
さらに、本発明によると、アクセスを判定することは、特定の資格認証／証明が、アクセスが許可されたことを示しているかどうかを判定することと、資格認証／証明から分離されている、資格認証／証明に関連する付加データがあるかどうかを判定することと、もし特定の資格認証／証明が、アクセスが許可されたことを示し、かつ、もし、その特定の資格認証／証明に関連する付加データがあるならば、その付加データによって与えられる情報に従って、アクセスを拒絶するべきかどうか決定することとを含んでいる。資格認証／証明は１つの部品に、または別個の部品に存在してもよい。資格認証を生成する第１の管理エンティティと、証明を生成する他の管理エンティティが存在してもよい。第１の管理エンティティは証明を生成してもよいし、または、証明を生成しなくてもよい。資格認証は一方向性関数を複数の証明のうちの第１の証明に適用した結果である最終値を含むディジタル証明書に対応してもよい。複数の証明の各々は、該証明のうちの将来の証明に一方向性関数を適用した結果であってよい。ディジタル証明書は電子装置に対する識別子を含んでよい。資格認証は、一方向性関数を、複数の証明のうちの第１の証明に適用した結果である最終値を含んでよい。複数の証明の各々は、該証明のうちの将来の証明に一方向性関数を適用した結果であってよい。資格認証は、アクセスを要求するユーザに対する識別子を含んでよい。資格認証／証明はディジタル署名を含んでよい。アクセスは、複数の壁とドアで囲まれた区域へのアクセスであってよい。アクセスを判定することは、アクセスが拒絶されているか否かに応じて、作動させられるドアロックを設けることを含んでよい。アクセスを判定することは、資格認証／証明を受け取る読み取り器を設けることをも含んでよい。資格認証／証明は、ユーザによって提示されるスマート・カード上に設けてもよい。資格認証／証明はユーザによって記入されるパスワードを含んでよい。資格認証／証明はユーザの生体認証情報を含んでよい。資格認証／証明は、手書きの署名を含んでよい。資格認証／証明は、ユーザによって保持されるカード上に設けられた秘密値を含んでよい。資格認証／証明は、所定の時に満了してもよい。付加データはディジタル署名されてもよい。付加データは、資格認証／証明に接続されたメッセージであってよい。前記メッセージは、特定の資格認証／証明を識別し、かつ該特定の資格認証／証明が無効にされているどうかについての表示を含んでよい。前記表示は空の文字列であってよい。付加データは日付を含んでよい。付加データは前記特定の資格認証／証明についての情報を含み、かつ1つまたは2つ以上の他の資格認証／証明についての情報を含むメッセージであってよい。アクセスを判定することは、付加データを格納することをも含んでよい。付加データは、どれだけの期間その付加データは保存されなければならないかを示す満了時間を含んでよい。満了時間は前記特定の資格認証／証明の期限切れに対応してもよい。アクセスを判定することは、所定の時間の間、付加データを格納することを含んでもよい。複数の資格認証／複数の証明は、所定の時間の後に全て満了してもよい。前記付加データは、スマート・カードを用いて設けてもよい。スマート・カードは、ある区域へのアクセスを得ようとするユーザによって提示されてもよい。その区域へのアクセスは複数の壁と少なくとも１つのドアによって制限されてもよい。前記付加データは、アクセスを得ようとするユーザと異なるユーザに対するものであってよい。アクセスを判定することは、通信リンクを設けることと、その通信リンクを用いて前記付加データを送信することを含んでもよい。通信リンクはスマート・カードによって付加情報を供給されてもよい。スマート・カードは、作動し続けるために、通信リンクとの周期的な通信を要求してもよい。スマート・カードは、他のスマート・カードによって付加データを供給されてもよい。付加データは、複数のスマート・カードの部分集合へ選択的に提供されてもよい。アクセスを判定することは、優先レベルを付加データに付加することを含んでもよい。付加データは、該付加データに与えられた優先レベルに従って、スマート・カードの部分集合へ選択的に与えられてもよい。付加データは、スマート・カードの部分集合へランダムに与えられてもよい。
【００１３】
さらに、本発明によると、資格認証についてのデータを発行することと配布することは、あるエンティティに、その資格認証が無効にされていることを示す認証されたデータを発行させることと、その認証されたデータを第１のユーザの第１のカードに格納させことと、その認証されたデータを第１のドアへ転送するために第１のカードを利用することと、第１のドアに、認証されたデータについての情報を格納させることと、第１のドアに、該資格認証へのアクセスを拒絶するために、認証されたデータに関する情報に依存させることとを含んでいる。認証されたデータは、ディジタル署名によって認証されてもよく、第１のドアはそのディジタル署名を検証してもよい。ディジタル署名は公開キー・ディジタル署名であってよい。ディジタル署名に対する公開キーは資格認証に関連させてもよい。ディジタル署名は秘密キーディジタル署名であってよい。資格認証と第１のカードはともに第１のユーザに所属してもよい。資格認証は第１のカードと異なる第２のカードに格納してもよく、第１のドアは、認証されたデータについての情報のような情報をメモリから取り出すことによって、認証されたデータについての情報に依存してもよい。資格認証は、第１のユーザと異なる第２のユーザに所属してもよい。認証されたデータは、まず、第１のカードと異なる少なくとも１つの他のカードに格納してもよく、認証されたデータは、その少なくとも１つの他のカードから第１のカードに転送してもよい。認証されたデータは、まず、第１のドアと異なる少なくとも１つの他のドアへ転送されることによって、前記少なくとも１つの他のカードから第１のカードに転送してもよい。エンティティは、まず、認証されたデータをレスポンダー上に格納させ、次に、第１のカードに該認証されたデータをレスポンダーから取得させることによって、認証されたデータを第１のカードに格納させてもよい。レスポンダーは保護されていなくてよい。第１のドアは、認証されたデータが、まず、第１のカードと異なる少なくとも１つの他のカードに転送されることによって、認証されたデータについての情報を第１のカードから受け取ってもよい。前記少なくとも１つの他のカードは、まず、認証されたデータが第１のドアと異なる少なくとも１つの他のドアへ転送されることによって、認証されたデータについての情報を第１のカードから受け取ってもよい。第１のドアは、完全に非接続にされ、または、断続的に接続されていてよい。
【００１４】
さらに、本発明によると、第１のドアは、第１のユーザの資格認証についての認証されたデータを受け取り、方法は、第１のユーザと異なる第２のユーザに属する第１のカードから認証されたデータを受け取ることと、その認証されたデータについての情報を格納することと、資格認証を受け取ることと、その資格認証へのアクセスを拒絶するために、該認証されたデータについての格納された情報にたよることを含む。該認証されたデータはディジタル署名によって認証され、第１のドアはディジタル署名を検証してもよい。ディジタル署名は公開キー・ディジタル署名であってよい。ディジタル署名に対する公開キーは資格認証に関連していてよい。ディジタル署名は秘密キー・ディジタル署名であってよい。認証されたデータは、まず、少なくとも１つの他のカードに格納され、次にその少なくとも１つの他のカードから第１のカードへ転送されることによって、第１のカードに格納してもよい。認証されたデータは、まず、第１のドアと異なる少なくとも１つの他のドアへ転送されることによって該少なくとも１つの他のカードから第１のカードへ転送してもよい。認証されたデータは、まず、レスポンダー上に格納され、次に該レスポンダーから第１のカードによって取得されることによって、第１のカードに格納してもよい。レスポンダーは、保護されていなくてもよい。第１のドアは、認証されたデータが、まず、第１のカードと異なる少なくとも１つの他のカードへ転送されることによって、該認証されたデータについての情報を第１のカードから受け取ってもよい。該少なくとも１つの他のカードは、認証されたデータが、まず、第１のドアと異なる少なくとも１つの他のドアへ転送されることによって、認証されたデータについての情報を第１のカードから受け取ってもよい。第１のドアは、完全に非接続であってもよいし、または、断続的に接続されてもよい。
【００１５】
さらに、本発明によると、アクセスの迅速な取り消しを支援することは、資格認証についての認証されたデータを受け取ることと、その認証されたデータについての情報を第１のカード上に格納することと、第１のドアに該認証されたデータについての情報を受け取らせることとを含んでいる。その認証されたデータはディジタル署名によって認証してもよい。そのディジタル署名は公開キー・ディジタル署名であってよい。そのディジタル署名に対する公開キーは資格認証に関連していてもよい。ディジタル署名は秘密キー・ディジタル署名であってよい。資格認証とカードはともに第１のユーザに所属してもよい。第１のカードは、もし、第１のカードが予め指定された時間内に予め指定されたタイプの信号を受信しないならば、アクセスのために使用不可能になってもよい。資格認証は、第１のユーザと異なる他のユーザに所属してもよい。該認証されたデータは、まず、第１のカードと異なる少なくとも１つの他のカードに格納され、次に、その少なくとも１つの他のカードから第１のカードに転送されることによって、第１のカードによって受信されてもよい。該認証されたデータは、まず、第１のドアと異なる少なくとも1つの他のドアへ転送されることによって該少なくとも１つの他のカードから第１のカードへ転送してもよい。第１のカードは認証されたデータをレスポンダーから取得してもよい。レスポンダーは保護されていなくてもよい。第１のカードは、まず、第１のカードと異なる少なくとも１つの他のカードへ該認証されたデータを転送することによって、第１のドアにその認証されたデータについての情報を受け取らせることができる。第１のカードは、まず、第１のドアと異なる少なくとも１つの他のドアへ該認証されたデータを転送することによって、前記少なくとも１つの他のカードに、該認証されたデータについての情報を受け取らせてもよい。第１のドアは、完全に非接続であるか、または断続的に接続されてもよい。第１のカードは、最終的には格納された認証されたデータについての情報をメモリから取り除いてもよい。資格認証は期限日付を持ってもよく、第１のカードは、資格認証が満了した後に、認証されたデータについての格納された情報をメモリから取り除いてもよい。資格認証の期限日付は、該資格認証内に指定されている情報から推測してもよい。
【００１６】
さらに、本発明によると、ある区域へアクセスすることに関連するイベントの記録をとることは、イベント記録をとるためにその区域へのアクセスに関連するイベントを記録することと、認証された記録をとるために少なくともそのイベント記録を認証することを含んでいる。イベントの記録をとることは、イベントの時間を記録することを含んでよい。イベントを記録することは、イベントのタイプを記録することを含んでよい。イベントは、該区域へアクセスしようとする試みであってよい。イベントを記録することは、該区域へアクセスしようとする試みに関連して使用される資格認証／証明を記録することを含んでよい。イベントを記録することは、該試みの結果を記録することを含んでよい。イベントを記録することは、アクセスが拒絶されるべきであることを示す、資格認証／証明以外のデータの存在を記録することを含んでよい。イベントを記録することは、該区域に関する付加データを記録することを含んでよい。該記録を認証することは、該記録にディジタル署名をすることを含んでよい。少なくともイベント記録を認証することは、単一の認証された記録を提供するために、該イベント記録を認証することと、他のイベント記録を認証することを含んでよい。該単一の認証された記録はカード上に格納されてもよい。該認証された記録はカード上に格納されてもよい。カードは、それに格納された他の認証された記録を持ってもよい。該他の認証された記録は、該カードが該区域にアクセスするために使用されることと関連して該カードによって提供されてもよい。アクセスは、もし、該他の認証された記録が検証されないならば、拒絶してもよい。該区域にアクセスすることに関連してコントローラを設けてもよく、該コントローラは、該他の認証された記録をさらに認証する。該他の認証された記録はディジタル証明書を用いて認証されてもよい。イベントの記録をとることは、ユーザが該区域にアクセスしようとするためにカードを提示することを含んでもよい。イベントの記録をとることは、ユーザが該区域にアクセスしようとするのと関連して、カードが、該認証された記録を認証することをさらに含んでもよい。該区域にアクセスすることに関連してコントローラを設けてもよく、コントローラとカードは一緒になって、該認証された記録をさらに認証する。イベントの記録をとることは、該認証された記録の内容を示す相関生成データを生成することを含んでよい。該相関生成データは、該認証された記録に接続されてもよい。相関生成データは認証された記録に結合されてもよく、その結果として生じた結合は認証されてもよい。その結果として生じた結合をディジタル署名してもよい。相関生成データは、一連の数であってもよく、その数のうちの特定の１つはイベントに割り当てられてもよい。イベントの記録をとることは、該特定の数とイベントとの結合を認証することを含んでもよい。前記結合を認証することは、該接続にディジタル署名することを含んでよい。前記結合を認証することは、該結合を一方向ハッシュ処理し、次に、その結果にディジタル署名することを含んでよい。イベントに対する相関生成データは他のイベントを識別する情報を含んでよい。該他のイベントは以前のイベントであってよい。該他のイベントは将来のイベントであってよい。イベントの記録をとることは、該イベントに対して第１および第２の乱数値を関連づけることと、該第１および第２の乱数値の少なくとも１つを該他のイベントに関連づけることと、該第１および第２の乱数値の少なくとも１つを前記他のイベントに結合することを含んでもよい。相関生成データを生成することは、相関情報を生成するための多項式を使用することを含んでよい。相関生成データを生成することは、該相関情報を生成するためにハッシュ・チェーンを用いることを含んでよい。相関生成データは、複数の他のイベントについての情報を含んでよい。相関生成データは誤り訂正コードを含んでよい。イベントの記録をとることは、認証された記録を配布することも含んでもよい。認証された記録を配布することは、該区域へアクセスしようとするユーザによって提示されたカード上にその認証された記録を設けることを含んでよい。該区域は複数の壁とドアによって定められてもよい。
【００１７】
さらに、本発明によると、少なくとも１つの管理エンティティが、該少なくとも１つの管理エンティティが生成する資格認証と、電子装置のための複数の対応する証明とによって、該電子装置へのアクセスを制御し、期限が過ぎた証明に対する資格認証と値のみが所与の場合には有効な証明を確定することが不可能であり、該電子装置は、もしアクセスが特定の時間において許可されているならば、該資格認証を受け取り、該電子装置は、前記特定の時間に対応する証明を受け取り、そして電子装置は、資格認証を用いて該証明を確認する。前記少なくとも１つの管理エンティティは、資格認証を生成した後に証明を生成してもよい。単一の管理エンティティが資格認証を生成し、かつ、証明を生成してもよい。資格認証を生成する第１の管理エンティティと、証明を生成する他の管理エンティティがあってもよい。第１の管理エンティティが証明をも生成してもよいし、生成しなくでもよい。資格認証は、一方向性関数を、複数の証明のうちの第１の証明に適用した結果である最終値を含むディジタル証明書であってよい。複数の証明の各々は、一方向性関数を、複数の証明のうちの将来の証明に適用した結果であってよい。ディジタル証明書は、電子装置に対する識別子を含んでよい。資格認証は、一方向性関数を、複数の証明のうちの第１の証明に適用した結果である最終値を含んでよい。複数の証明の各々は、一方向性関数を、該証明のうちの将来の証明に適用した結果であってよい。資格認証は、電子装置に対する識別子を含んでよい。電子装置は、アクセスが認可された場合にのみ起動するコンピュータであってよい。電子装置はディスク・ドライブであってよい。少なくとも１つの管理エンティティが電子装置へのアクセスを制御することは、該少なくとも１つの管理エンティティとは別個の少なくとも１つの証明配布エンティティを用いて証明を提供することを含んでよい。単一の証明配布エンティティがあってもよいし、複数の証明配布エンティティがあってもよい。少なくとも１つの管理エンティティが電子装置へのアクセスを制御することは、該電子装置への接続を用いて証明を提供することを含んでよい。前記接続はインターネットでもよい。複数の証明のうちの少なくとも幾つかは局所的に前記電子装置上に格納されてもよい。少なくとも１つの管理エンティティが電子装置へのアクセスを制御することは、その時点に対応する証明が局所的に入手不可能である場合には、該電子装置が外部接続を介して証明を要求することを含んでよい。複数の証明の各々は、特定の期間に関連づけてもよい。複数の証明のうちの特定の証明に関連する特定の期間が経過したのち、電子装置は新しい証明を受け取ってもよい。上記の期間は1日であってよい。
【００１８】
さらに、本発明によると、電子装置は、該電子装置に対する資格認証と複数の対応する証明の少なくとも１つを受け取ることによって該電子装置に対するアクセスを制御し、期限が過ぎた証明に対する資格認証と値のみが所与の場合には有効な証明を確定することが不可能であり、該資格認証を用いて前記複数の証明のうちの少なくとも１つをテストする。資格認証は、複数の証明のうちの第１の証明に一方向性関数を適用した結果である最終値を含むディジタル証明書であってよい。複数の証明の各々は、該証明のうちの将来の証明に一方向性関数を適用した結果であってよい。ディジタル証明書は、電子装置に対する識別子を含んでよい。資格認証は、複数の証明のうちの第１の証明に一方向性関数を適用した結果である最終値を含んでよい。複数の証明の各々は、該証明のうちの将来の証明に一方向性関数を適用した結果であってよい。資格認証は、電子装置に対する識別子を含んでよい。電子装置は、コンピュータであってよい。電子装置が自装置へのアクセスを制御することは、アクセスが認可された場合にのみ、コンピュータが起動することを含んでもよい。電子装置は、ディスク・ドライブであってよい。電子装置が、自己へのアクセスを制御することは、該電子装置への接続を用いて証明を取得することを含んでもよい。前記接続はインターネットであってよい。複数の証明のうちの少なくとも幾つかは、局所的に電子装置上に格納してもよい。電子装置が自装置へのアクセスを制御することは、もし、その時点に対応する証明が局所的に入手できないならば、該電子装置が外部接続を介して証明を要求することを含んでもよい。複数の証明の各々は、特定の期間に関連していてもよい。複数の証明のうちの特定の１つに関連する特定の期間が経過した後、電子装置は、新しい証明を受け取ってもよい。前記期間は1日であってよい。
【００１９】
さらに、本発明によれば、電子装置へのアクセスを制御することは、資格認証を該電子蔵置へ出力することと、もし、アクセスが特定の時間に許可されるならば、証明を、該特定の時間に対応する電子装置へ出力することとを含み、該証明は、期限が過ぎた証明に対する資格認証と値のみが与えられるならば、確定不可能である。資格認証は、一方向性関数を、複数の証明のうちの第１の証明に適用した結果である最終値を含むディジタル証明書であってよい。複数の証明の各々は、該証明の将来の証明に一方向性関数を適用した結果であってよい。ディジタル証明書は、電子装置に対する識別子を含んでよい。資格認証は、一方向性関数を、複数の証明のうちの第１の証明に適用した結果である最終値を含んでよい。複数の証明の各々は、該証明の将来の証明に一方向性関数を適用した結果であってよい。資格認証は、電子装置に対する識別子を含んでよい。電子装置は、コンピュータであってよい。電子装置へのアクセスを制御することは、アクセスが認可された場合にのみ、該コンピュータが起動することを含んでよい。電子装置は、ディスク・ドライブであってよい。電子装置へのアクセスを制御することは、前記少なくとも１つの管理エンティティとは別個の少なくとも１つの証明配布エンティティを用いて証明を提供することを含んでよい。単一の証明配布エンティティがあってもよい。複数の証明配布エンティティがあってもよい。電子装置へのアクセスを制御することは、該電子装置への接続を用いて証明を提供することを含んでよい。前記接続はインターネットでもよい。複数の証明のうちの少なくとも幾つかは局所的に電子装置上に格納してもよい。電子装置へのアクセスを制御することは、その時点に対応する証明が局所的に入手不可能である場合には該電子装置が外部接続を介して証明を要求することを含んでよい。複数の証明の各々は、特定の期間に関連づけられてよい。複数の証明のうちの特定の証明に関連する特定の期間が経過したのち、電子装置は新しい証明を受け取ってもよい。前記の期間は1日であってよい。
【発明を実施するための最良の形態】
【００２０】
図１Ａを参照すると、図２０は、複数の電子装置２４−２６が接続されている全体の接続２２を表している。図２０は3個の電子装置２４−２６を示しているが、ここに記載されたシステムは任意の数の電子装置で動作してもよい。接続２２は直接的な電子データ接続、電話回線を経由する接続、ＬＡＮ，ＷＡＮ、インターネット、仮想・プライベート・ネットワーク、その他のデータ通信を行うための任意の機構によって実施してもよい。電子装置２４−２６は、１個または複数のラップトップコンピュータ、（オフィッス内の、または従業員の自宅または他の場所における）デスクトップコンピュータ、ＰＤＡ、携帯電話、ディスク・ドライブ、大容量の記憶装置、または、その他の、アクセスを制限することが有益であると考えられる任意の電子装置であってよい。本実施形態では、電子装置２４−２６は、ユーザ／従業員がその組織から退職したとき、および/
またはコンピュータの１つが紛失しまたは盗難にあったときに、該コンピュータへのアクセスを制限することを希望する組織の従業員によって使用されているデスクトップコンピュータまたはラップトップコンピュータを示している。勿論、電子装置２４−２６の１つまたは２つ以上へのアクセスを制限するその他の理由が存在することがあり、ここに記載されたシステムは任意の適切な実施に関連して用いてもよい。
【００２１】
管理エンティティ２８が電子装置２４−２６へのユーザによるアクセスを許可するポリシーを設定する。たとえば、管理エンティティ２８は、特定のユーザＵ１が電子装置２４−２６のいずれかにもはやアクセスしてはならず、他方、他のユーザＵ２は電子装置２４にはアクセスしてもよいが他の電子装置２５，２６にはアクセスしてはならないということを決定する。管理エンティティ２８は、ユーザのアクセスを設定する任意のポリシーを用いてもよい。
【００２２】
管理エンティティ２８は、接続２２を経由して電子装置２４−２６へ送信される複数の証明を生成する。その証明は、以下に詳細に述べる他の手段によって電子装置２４−２６に与えられてもよい。電子装置２４−２６は配布された証明を受け取り、内部に（本明細書の他の個所でより詳しく説明する）格納されている資格認証（credential)）を用いて該電子装置へのアクセスが許可されるべきであるか否かを決定する。任意に、証明配付エンティティ３２は接続２２と管理エンティティ２８に接続されてもよい。証明配付エンティティ３２は証明を電子装置２４−２６へ与える。一実施形態においては、証明は、一人のユーザ、電子装置２４−２６のうちの１つに対してのみ有効であり、そして、任意に、ある定まった日付、またはある期間の間にのみ有効であろう。
【００２３】
これら証明は、電子装置２４−２６の各々が、管理エンティティ２８（または、権限のあるエンティティ）によって署名され、Ｎ回適用される一方向性関数を有し、初期値を表す特定の値を含んでいるディジタル証明書を資格認証として受け取る、引用によってここに含まれる米国特許５,６６６,４１６に開示されているような機構を用いて提供される。これら電子装置は、新たな期間ごとに、一方向性関数を適用することによって得られるＮ個の値の組のなかの値の１つの値からなる証明が与えられる。そのような場合には、電子装置２４−２６は、そのディジタル証明書中に与えられている特定の値を得るために一方向性関数を多数回、適用することによってその証明が正当であることを確認してもよい。この機構および他の考えられる機構は本明細書の他の所でより詳細記述する。
【００２４】
本明細書で説明さるような適切な資格認証と証明を提供するために、または、１）職務権限によって（管理的セキュリティ違反がなく）生成することができたであろう証明であって、２）他のどのような証明を生成するためにも使用することができない、固有の証明を生成する他の何らかの機構を用いるために、マサセチューセッツ州ケンブリッジのＣｏｒｅＳｔｒｅｅｔ社によって提供される1つまたは複数の製品を用いることも可能である。したがって、これら証明は、正当な証明をＰ１とすると、認可されていないユーザが異なる目的のために（たとえば、異なる期間、異なる装置、等のために）見かけ上、正当な他の証明Ｐ２を生成しないであろうようなものである。したがって、発行された証明は、セキュアではない方法で格納され、配布されてもよく、このことは、システムに関連するコストをかなり低減する。もちろん、何らかの未発行の（たとえば、将来の）証明のための適切なセキュリティを維持するとともに、資格認証および/または証明を生成する１つまたは複数のエンティティに対する適切なセキュリティを維持することは有利である。
【００２５】
さらに、正当な証明Ｐ１−ＰＮを所有する、認可されていないユーザは、新たな証明ＰＮ＋１を生成することはないであろう。このことは、多くの場合において有利である。たとえば、解雇された従業員は、彼がまだ会社に雇用されていたとき、たとえ彼が会社のラップトップ用に用いていた元の正当な証明のすべてを未だ所持していても、解雇後に彼のそのラップトップに認可なくアクセスできるための新たな証明を彼自身で生成することはできないであろう。
【００２６】
ここに記載されている実施形態においては、電子装置２４−２６は、証明が、コンピュータへの認可されていないログインおよび/またはアクセスを防止するために用いられる、本明細書に記述されている処理を行うファームウエアおよび／またはオペレーティング・システム・ソフトウエアを有するコンピュータである。このコンピュータは、起動時および/または証明が、該コンピュータへの認可されていないログインおよび/またはアクセスを防止するために用いられる十分な時間が経過したとき、動作するために適切な証明を必要とするであろう。本実施形態では、ここに記載した機能は、（ＢＩＯＳまたはＰＸＥ環境のみならず）標準のウインドウズ・ログイン・システムと一体化される。管理エンティティ２８はマイクロソフト社のネットワークの通常のユーザ管理ツールと一体化され、管理者が各ユーザに対するログインポリシーを設定するのを可能にするようにしてもよい。多くの場合、管理エンティティ２８は全ての必要な情報を既存の管理情報から導き出すことができ、その結果この新しい機能を管理者にとってほとんどトランスペアレントにし、かつ訓練と採択のコストを低減する。管理エンティティ２８は企業のネットワーク内で作動してもいし、または、ＡＳＰモデルとして、ラップトップのメーカ、ＢＩＯＳのメーカ、または信頼のある他のパートナーによってホストされてもよい。証明配布エンティティ３２は、一部は企業ネットワーク内で作動し、一部はグローバルなサイトで作動してもよい。証明は機密事項を扱う情報でないので、証明配布システムのグローバルにアクセス可能な格納所はｗｅｂサービスとして作動し、それによって、証明を、ユーザの企業のネットワークの外部のユーザが利用することに可能にする。
【００２７】
ここでの実施形態において、各コンピュータは毎日新たな証明を要求するであろう。しかし、時間のインクリメントを、たとえば、コンピュータが1週間ごとに新しい証明を要求し、または、1時間ごとに新たな証明を要求するように、変更してもよいことを当業者はわかるであろう。
【００２８】
さらに、ＩＤＥ規格のハードドライブのほとんど使用されない特徴、すなわち、ドライブが回転してコンテンツへのアクセスを可能にする前にドライブに与えられなければならないパスワードを該ドライブに設定することを可能にするという特徴を利用することも可能である。もし、ここ記載されているシステムを用いるために、ドライブ用のファームウエアを変更するならば、たとえば、そのドライブを異なるコンピュータ内に置いたとしても、コンピュータのハードドライブへのアクセスすることは不可能であるように、ハードドライブへのアクセスを制限することが可能である。この特徴は、他のタイプのハードドライブでも実施してもよい。
【００２９】
他の実施においては、システムは、データファイル、物理的格納ボリューム、論理ボリューム等へのアクセスに関連して使用される。ファイルへのアクセスを制限するような幾つかの例においては、対応するオペレーティング・システムに適切な変更を加えることが有用である。
【００３０】
図１Ｂを参照すると、図２０’は複数の管理エンティティ２８ａ−２８ｃを有する他の実施形態を示している。図２０’は３個の管理エンティティ２８ａ−２８ｃを示しているが、ここに記述されているシステムは、任意の数の管理エンティティで動作してもよい。図２０’によって示されている実施形態においては、管理エンティティ２８ａ−２８ｃの１つ（たとえば、管理エンティティ２８ａ）が資格認証を発生し、管理エンティティ２８ａ−２８ｃのその他のもの（たとえば、管理エンティティ２８ａ、２８ｂ）が証明を発生し、または全ての管理エンティティ２８ａ−２８ｃが証明を発生することが可能である。任意に、証明配布エンティティ３２を使用してもよい。
【００３１】
図１Ｃを参照すると、図２０’’は複数の証明配布エンティティ３２ａ−３２ｃを有する他の実施形態を図示している。図２０’’は３つの証明配布エンティティ３２ａ−３２ｃを図示しているが、ここに記述されているシステムは、任意の数の証明配布エンティティで動作してもよい。図２０’’によって示されている実施形態はマサチューセッツ州ケンブリッジのＡｋａｍａｉＴｅｃｈｎｏｌｏｇｉｅｓ Ｉｎｃｏｒｐｏｒａｔｅｄによって提供されている技術を用いて実施してもよい。
【００３２】
図１Ｄを参照すると、図２０’’’は複数の管理エンティティ２８ａ’−２８ｃ’と複数の証明配布エンティティ３２ａ’−３２ｃ’を有する他の実施形態を示している。図２０’’’は３つの管理エンティティ２８ａ’−２８ｃ’と３つの証明配布エンティティ３２ａ’−３２ｃ’を示しているが、ここに記述されているシステムは、任意の数の管理エンティティと証明配布エンティティで動作してもよい。図２０’’’によって示されている実施形態は図１Ｂによって説明した実施形態の特徴を図１Ｃによって説明した実施形態の特徴と組み合わせている。
【００３３】
図２を参照すると、図は電子装置２４を、妥当性確認ユニット４２，資格認証データ４４、および証明データ４６を含んでいるとしてさらに詳細に図示している。妥当性確認ユニット４２は、ハードウエア、ソフトウエア、ファームウエアまたは、それらの任意の組み合わせを用いて実施してもよい。ブート・アップのような特定の状態のときに、妥当性確認ユニット４２は、妥当性確認ユニット４２に資格認証データ４４と証明データ４６とを検査させ、その結果に基づいて、正当な証明が存在することを示す合格信号を発生させ、そうでなければ、不合格信号を発生させるスタート信号を受信する。妥当性確認ユニット４２の出力は、コンピュータ・ブートアップ・ファームウエアのような後続する処理／装置によって、動作を続けることができるか、どうかを判定するために用いられる。
【００３４】
ここに記載されている実施形態においては、電子装置２４は、妥当性確認ユニット４２によって制御される外部インターフェース４８を含んでいる。妥当性確認ユニット４２の場合と同様に、外部インターフェース４８はハードウエア、ソフトウエア、ファームウエア、またはそれらの任意の組み合わせを用いて実施してもよい。外部インターフェース４８は例えば接続２２に接続され、証明データ４６中に格納される新しい証明をフェッチするために使用される。したがって、もし、妥当性確認ユニット４２が、証明データ４６に格納されている証明が十分でない（たとえば、期限切れになっている）と判定すると、妥当性確認ユニット４２は、外部インターフェース４８に接続２２を介して新たな証明を要求させる信号を外部インターフェース４８に出力する。もちろん、もし、電子装置２４が紛失したかおよび/または盗まれているならば、または、もし、ユーザが解雇された従業員であるならば、または、もし、電子装置２４へのアクセスを許可しない何か他の理由があるならば、外部インターフェース４８は正当な証明を得ることができないであろう。いくつかの実施形態においては、外部インターフェース４８は、ユーザに適切な電子的接続をする（たとえば、ラップトップをネットワークに接続する）ことを促す。
【００３５】
この実施形態においては、時間データ５２は、正当な証明が妥当性確認ユニット４２に所与の最後の時間を示す情報を妥当性確認ユニット４２にもたらす。この情報は、過度に頻繁に証明を要求することを防ぎ、かつ同時に新たな証明を要求するまでに、過度に長時間待つことを防止すために使用してもよい。妥当性確認ユニット４２、外部インターフェース４８、資格認証データ４４、証明データ４６、および時間データ５２の相互作用と使用については本明細書の他の所でさらに詳細に記述する。
【００３６】
図３を参照すると、フローチャート７０は、妥当性確認ユニット４２が資格認証データ４４と証明データ４６を、合格信号または不合格信号を生成するために、調べるかどうかを判定するために、妥当性確認ユニット４２へスタート信号を送信するべきかどうかを判定することに関連して行われるステップを示している。処理は、ブート・アップ動作が行われているかどうかを判定する最初のステップ７２で始まる。ここに記載されている実施形態では、証明は常にブート・アップ動作に関連してチェックされる。したがって、テスト・ステップ７２において、ブート・アップが行われていると判定されると、制御はステップ７２から、スタート信号が妥当性確認ユニット４２に送信されるステップ７４に移る。処理が、再び繰り返されるまで所定の時間待機するステップ７６がステップ７４に続く。ここに記載されている実施形態では、所定の時間は1日であるが、他の時間を用いてもよい。ステップ７６に次いで、制御は上記したテスト・ステップ７２に戻る。
【００３７】
もし、ブート・アップ動作が行われていないとテスト・ステップ７２において判定されると、制御はテスト・ステップ７２から、妥当性確認ユニット４２が最後に実行してから所定の時間が経過したかが判定されるテスト・ステップ７８に移る。これは、時間データ要素５２と、場合によっては現在のシステム時間を用いて判定される。ここに記載されている実施形態においては、テスト・ステップ７８で用いられる所定の時間は1日である。もし、妥当性確認ユニット４２が最後に実行してからの時間が所定の時間よりも大きいとテスト・ステップ７８で判定されると、制御はテスト・ステップ７８から、スタート信号が妥当性確認ユニット４２へ送信されるステップ７４に移る。もし時間が所定の時間よりも大きくないならば、ステップ７４またはスト・ステップ７８に上記したステップ７６が続く。
【００３８】
図４を参照すると、フローチャート９０は、十分な証明が受信されたかどうかが、妥当性確認ユニット４２に関連して判定することに関連して行われるステップを示している。本明細書の他の所で述べたように、妥当性確認ユニット４２は合格信号または不合格信号を（コンピュータ・ブート・アップ・ファームウエアまたはディスク・ドライブ・ファームウエアのような）次の処理／装置に送信する。処理は、妥当性確認ユニット４２が必要な証明を判定する最初のステップ９２で開始する。必要な証明は、合格信号を送信してもよいのに十分であると妥当性確認ユニット４２によって判定される証明である。妥当性確認ユニット４２は、資格認証データ４４、証明データ４６、時間データ５２、そして場合によって内部／システムクロックさえも調べることによって必要な証明を判定する。適切な証明が局所的に（すなわち、証明データ４６内で）入手可能であるか、そして、局所的に提供された証明が必要な要件（本明細書の他の所で論じられる）を満たすどうかを判定するテスト・ステップ９４がステップ９２に続く。もし、そうならば、制御はステップ９４から、妥当性確認ユニット４２が合格信号を出力するステップ９６に移る。ステップ９６に続いて処理は完了する。
【００３９】
いくつかの実施形態においては、将来の証明を得、証明データ４６中に格納することが可能であり、望ましい。例えば、管理エンティティ２８および/または証明配布エンティティ３２との接続がないことを期待するユーザは将来の証明を得て格納することであろう。これらの実施形態においては、電子装置は、管理エンティティ２８および/または証明配布エンティティ３２と接続されたとき、予め決められたポリシーにしたがって設けられる将来の証明に、自動的に票を投ずることがある。あるいは（または、それに加えて）ユーザおよび/または電子装置は、支配しているポリシーに従って設けても、設けなくてもよい将来の証明を具体的に要求することが可能である。
【００４０】
もし、適切な証明が局所的に（すなわち、証明データ４６内に）入手することができないとステップ９４において判定されると、制御はテスト・ステップ９４からテスト・ステップ９８に移り、テスト・ステップ９８において、妥当性確認ユニット４２は、前記したように、たとえば、外部インターフェース４８に、証明をフェッチするように試みさせる信号を出力することによって、適切な証明が外部から入手可能かどうか判定する。もし、テスト・ステップ９８において、外部から提供された証明が必要な要件（本明細書の他の所で論ずる）を満たすと判定されると、制御はテスト・ステップ９８から、妥当性確認ユニット４２が合格信号を出力する、前記したステップ９６に移る。ここに記述された実施形態においては、外部から提供された証明は証明データ４６に格納される。
【００４１】
もし、テスト・ステップ９８において、適切な接続がないという理由、あるいはある他の理由によって、適切な証明を外部から入手できないと判定されると、制御はテスト・ステップ９８から、ユーザが適切な証明を入力するように促されるステップ１０２に移る。ここに記載されている実施形態において、もし、ユーザが適切な電気的接続がない場所にいるならば、ユーザは、特定の電話番号に電話してステップ１０２において所与の促しに関連して電子装置に手動で入力される番号の形式の適切な証明を受け取る。もちろん、ユーザは、証明を、手書き、またはタイプ、または新聞での（たとえば、機密欄に）発表のような他の手段によって受け取ってもよい。
【００４２】
ユーザが必要な要件（本明細書の他の所に記載されているような）を満たした証明を入力したかどうかを判定するテスト１０４がステップ１０２に続く。もし、そうならば、制御は、テスト・ステップ１０４から、妥当性確認ユニット４２が合格信号を出力する上記のステップ９６に移る。もし、そうでなければ、制御はテスト・ステップ１０４から、妥当性確認ユニット４２が不合格信号を出力するステップ１０６に移る。ステップ１０６の次に、処理は完了する。
【００４３】
図５を参照すると、フローチャート１２０は、妥当性確認ユニット４２によって使用される資格認証の生成に関連して行われるステップを示している。フローチャート１２０の各ステップは、資格認証（および一連の証明）を生成し、その資格認証を電子装置２４に出力する管理エンティティ２８によって実行される。他の適切なエンティティ（たとえば、管理エンティティ２８によって認可されたエンティティ）が資格認証を生成してもよい。ランダム値が資格認証と証明の生成に関連して使用され、そしてここに記載されている実施形態においては、一般に予測不可能である。インデックス変数Ｉを１に設定するステップ１２４がステップ１２２に続く。ここに記載されている実施形態においては、提供された資格認証は1年を通じて使用され、新しい証明は、３６５個の個別の証明が資格認証の生成に関連して生成されるように毎日必要である。インデックス変数Ｉは、生成された証明の数を追跡するために使用される。初期証明値Ｙ（０）が、ステップ１２２で定められたランダムな値ＲＶに等しく設定されるステップ１２６がステップ１２４に続く。
【００４４】
インデックス変数Ｉが最終値ＩＥＮＤよりも大きいかどうかを判定するテスト・ステップ１２８がテスト・ステップ１２６に続く。上記したように、ここに記載されている実施形態においては、この実施形態においては、ＩＥＮＤは３６５個であるように、資格認証の生成に関連して３６５個の証明が生成される。しかし、他の実施形態では、ＩＥＮＤを任意の値に設定することが可能である。
【００４５】
もし、テスト・ステップ１２８においてＩの値がＩＥＮＤよりも大きくないと判定されると、制御はステップ１２８から、Ｙ（Ｉ）がＹ（Ｉ−１）に適用された一方向性関数の値に等しく設定されるステップ１３２に移る。ステップ１３２において用いられる一方向性関数は、一方向性関数を適用した結果が与えられているとすると、一方向性関数に入力された値を求めることが殆ど不可能であるような関数である。したがって、ステップ１３２で用いられる一方向性関数の場合、Ｙ（Ｉ）を与えても、入力の値（この場合にはＹ（Ｉ−１））を突き止めることは、たとえ不可能でないとしても、非常に困難である。ここに用いられているように、一方向性関数という用語は、従来の一方向ハッシュ関数とディジタル署名を、限定することなく含むこの性質を適切に備えている任意の関数または動作を含む。ステップ１３２で用いられている一方向性関数のこの性質は、本明細書の他の場所で論ずるように、発行された証明をセキュリティではない方法で格納し配布してもよいという点で有用である。資格認証群と証明群は異なった時間に生成してもよく、または証明はその資格認証を生成したエンティティまたは他のエンティティによって後日再生成してもよい。なお、他の実施形態では、Ｙ（Ｉ）をＹ（Ｉ−１）または、そのために、どのような他のＹ‘の関数でもないようにしてもよい。
【００４６】
処理は、ランダムな値ＲＶが生成される最初のステップ１２２で始まる。インデックス変数Ｉが増分されるステップ１３４がステップ１３２に続く。ステップ１３４に続いて、制御は上記のテスト・ステップ１２８に戻る。もし、テスト・ステップ１２８においてＩがＩＥＮＤより大きいと判定されると、制御はテスト・ステップ１２８から、最終値ＦＶがＹ（Ｉ−１）に等しく設定されるステップ１３６に移る。なお、ＩはＩＥＮＤを超過して増分されたので、Ｉから１が差し引かれる。管理エンティティ２８（または、証明と資格認証を生成する他のエンティティ）は、その最終値、現在の日付、および該証明に関連して用いられている他の情報にディジタル署名をするステップ１３８がステップ１３６に続く。ここに記載されている実施形態においては、他の情報は、特定の電子装置（たとえば、ラップトップ）、特定のユーザ、または、その資格認証と証明を、特定の電子装置および/または、ユーザおよび/または他の何らかの性質と関連付ける他の情報を識別するために用いてもよい。任意に、日付および1/または、他の情報と組み合わせてもよい。たとえば、単に「装置＃１２３４５６が１／１／２００４の日に有効である」というＯＣＳＰ形の署名されたメッセージを用いること、または、特定の装置がオンまたはオフ状態にあることに対応するｍｉｎｉＣＲＬにビットを持つことが可能である。これらの場合において、装置上の資格認証が該装置を認証する（すなわち、該装置が本当に装置＃１２３４５６である等と判定する）。ＯＣＳＰとｍｉｎｉＣＲＬは本技術分野で公知である。ステップ１３８に続いて、処理は完了する。
【００４７】
図６を参照すると、フローチャート１５０は証明の妥当性を判定することに関連して妥当性確認ユニット４２によって実行されるステップを示している。処理は、妥当性確認ユニット４２が（たとえば、証明データ４４から証明を読み出すことによって）証明を受け取る最初のステップ１５２で始まる。妥当性確認ユニット４２が（たとえば、資格認証データ４６を読み出すことによって）資格認証を受け取るステップステップ１５４がステップ１５２に続く。
【００４８】
該資格認証を備えている他の情報がＯＫであるかどうかを判定するテスト・ステップ１５６がステップ１５４に続く。本明細書の他の所で述べたように、前記の他の情報は、たとえば、電子装置の識別子、ユーザの識別子、またはその他の性質を特定する情報を含んでいる。もし、資格認証に関連する他の情報が、該他の情報によって記述されている特定の特性に合致しない（たとえば、その資格認証が、異なる電子装置または異なるユーザのためのものである）ならば、制御はテスト・ステップ１５６から、不合格信号が出力されるステップ１５８へ移る。ステップ１５８に続いて、処理は完了する。
【００４９】
もし、テスト・ステップ１５６において、資格認証に関連する他の情報がＯＫであると判定されると、制御はテスト・ステップ１５６から、変数Ｎが現在の日付から資格認証に関する日付を引いたもの（すなわち、資格認証が発行されてからの日数）に等しく設定されるステップ１６２に移る。ステップ１５２で提供された証明の値が、Ｎ回適用された一方向性関数の値をもつステップ１６４がステップ１６２に続く。ステップ１６４で用いられる一方向性関数は、前記のステップ１３２で用いられた一方向性関数に相当する。
【００５０】
ステップ１６４で得られた結果が、ステップ１５４で受け取った資格認証の一部である最終値ＦＶに等しいかを判定するステップ１６６がステップ１６４に続く。もし、そうであるならば、制御はテスト・ステップ１６６から、合格信号が妥当性確認ユニット４２によって出力されるステップ１６８に移る。そうではなく、もし、テスト・ステップ１６６において、ステップ１６４で得られた結果がステップ１５４において資格認証が与えられる最終値ＦＶに等しくないと判定されると、制御はテスト・ステップ１６６から、不合格信号が妥当性確認ユニット４２によって出力されるステップ１７２に移る。ステップ１７２の次に、処理は終了する。
【００５１】
ディジタル署名はインターネット認証の効果的な形式をもたらす。従来のパスワードやＰＩＮとは異なり、ディジタル署名は普遍的に検証可能で無効にすることができない認証をもたらす。ディジタル署名は署名キーＳＫによって作成し、照合検証キーＰＫによって検証される。ユーザＵは彼自身のＳＫを秘密にする（その結果、ＵだけがＵのために署名をしてもよい）。幸いなことに、キーＰＫは照合キーＳＫを「さらけ出す」ことをしない、すなわち、ＰＫをしっていることは敵にＳＫを計算するときの実際的な利益を全く与えない。したがって、ユーザＵは彼自身のＰＫを（誰でもＵの署名を検証できるように）できるだけ公開してもよい。この理由で、ＰＫを公開キーと呼ぶことが望ましい。なお、用語「ユーザ」はユーザ、エンティティ、装置、または、ユーザ、エンティティおよび/または装置からなる集合体を意味する。
【００５２】
公開キーは非対称暗号のためにも使用してもよい。公開暗号キーＰＫは照合復号キーＳＫと共に生成してもよい。この場合も同様に、ＰＫを知っていることはＳＫをさらけ出さない。任意のメッセージを、ＰＫを用いて容易に暗号化してもよいが、そのように演算された暗号文はキーＳＫを知っていることによって容易に復号できるだけである。したがって、ユーザＵは、（誰でもＵのためのメッセージを暗号化してもよいように）彼自身のＰＫをできるだけ公開できる、（Ｕだけが、Ｕのための暗号化されたメッセージを読むことができるように）ＳＫを秘密にしておくことができる。
【００５３】
周知のＲＳＡシステムはディジタル署名と非対称暗号の両者の例をもたらす。
【００５４】
証明書と呼ばれる英数字の文字列は、所与のキーＰＫが所与のユーザＵの公開キーであることを規定している。認証機関（ＣＡ）としばしば呼ばれるエンティティは証明書を生成してユーザに発行する。証明書は特定の時間、公的ＣＡの場合には通常は1年、の後に期限切れになる。基本的に、ディジタル証明書Ｃは、幾つかの量、すなわち該証明書に固有の通し番号ＳＮ、ユーザの公開キーＰＫ、ユーザ名Ｕ、発行日付Ｄ₁、期限Ｄ₂、および付加情報（情報なしを含む）ＡＩである量をセキュリティ上安全に組み合わせて成るＣＡのディジタル署名から成る。記号で表すと、Ｃ＝ＳＩＧ_CA(ＳＮ,ＰＫ,Ｕ,Ｄ₁,Ｄ₂,ＡＩ)。
【００５５】
公開暗号キーは、認証／識別の手段も備えていてもよい。たとえば、所与の公開暗号キーＰＫが所与のユーザＵに属していることを知っていて（たとえば、この当事者がＵおよびＰＫのための対応するディジタル証明書を検証したことがあるので）、Ｕを識別したい当事者は、ＰＫを用いてランダムな問題Ｃを暗号化し、Ｕに正しい復号で応答することを要求してもよい。ＳＫ（そして、したがって、Ｕ）の所有者だけがこれをしてもよいので、もし、その問題に対する応答が正しければ、Ｕは正しく識別される。
【００５６】
スマートドア（および/またはスマート仮想ドア、本明細書の他の所の記述を参照）を用いてある区域への物理的なアクセスを制御するシステムを設けることが可能である。スマートドアは、立ち入ろうとする人が現在、そうすることが認可されていることを検証する。スマートドアに、所与のユーザの資格認証のみならず資格認証／ユーザがまだ正当であるという別個の証明を、非接続のドアさえもセキュリティ上安全に用いることができるように備えることが有利である。一実施形態においては、そのような証明は次のように生成される。資格認証は、ユーザが入ってもよい１つまたは複数のドアを特定すると仮定する。次に、各資格認証および各期間（たとえば、毎日）について、正当なエンティティＥ（たとえば、任意の時点において誰がどのドアに対して認可されているかを決定するエンティティそのものか、または、そのエンティティのために動作する第２のエンティティ）が、所与の資格認証が所与の期間において正当であるという認証された指示（ＰＲＯＯＦ）を演算する。（もし、資格認証が、ユーザが入ることを認可されているドアを特定しないならば、ＰＲＯＯＦは所定の期間において資格認証が有効である１つまたは複数のドアを特定する。）
ＥのＰＲＯＯＦは、所与の資格認証が所与の期間の間に正当であることを、認証された方法、たとえば、ＳＩＧ_E(ＩＤ,Ｄａｙ,Ｖａｌｉｄ,ＡＩ)で示すＥのディジタル署名から成っている。ここで、ＩＤは資格認証を識別する情報（たとえば、資格認証の通し番号）、Ｄａｙは所与の期間を示す表示（意図された一般性を失うことなく、所定の日）、Ｖａｌｉｄは該資格認証が有効であると見なされるということを示す表示（この表示は、もし、資格認証が有効であると見なされない限りＥが同様なデータ列に署名しないならば、省略してもよい）、ＡＩは有用であると見なされる任意の付加的情報（情報がないことをも含む）を示す。いくつかの場合においては、Ｅの署名は公開キー署名でもよい。（しかし、それは秘密キー署名、すなわち、署名者と検証者の両者に知られている単一の秘密キーによって生成され、検証されるものであってもよい。）もし、資格認証がディジタル証明書から成るならば、１つの下位の実施形態は、短い期間の証明書、すなわち、所望の期間に対する資格認証を再発行するディジタル証明書（たとえば、同じ公開キー、同じユーザＵ、および若干の他の基本的な情報を以前と同様に特定しているが、所望の（意図されている一般性を失うことなく）日を識別するために開始日付と期限日付を特定しているディジタル証明書）からなっていてもよい。たとえば、そのような下位の実施形態において、意図されている一般性を失うことなく、短かい期間の証明書が1日連続するならば、ＰＲＯＯＦは形式ＳＩＧ_E(ＰＫ,Ｕ,Ｄ₁,Ｄ₂,ＡＩ)をとってもよい。ここで、開始日付Ｄ₁は、所与の日Ｄの開始を示し、終わり日付Ｄ₂は、日Ｄの対応する最後を示し、すなわちＤ₁＝Ｄ₂＝Ｄであり、 または、該日を識別するため単一の日付情報フィールドＳＩＧ_E(ＰＫ,Ｕ,Ｄａｙ,ＡＩ)を単に用いる。もし、Ｅが元の認証機関と一致するならば、短かい期間の証明書ＰＲＯＯＦは形式ＳＩＧ_E(ＰＫ,Ｕ,Ｄ₁,Ｄ₂,ＡＩ)またはＳＩＧ_CA(ＰＫ,Ｕ,Ｄａｙ,ＡＩ)をとってもよい。
【００５７】
ユーザは、認証されると、彼自身の当日のＰＲＯＯＦ（すなわち、彼自身の資格認証のその日のＰＲＯＯＦ）を作ってはならないし、彼の昨日のＰＲＯＯＦを今日の彼自身のＰＲＯＯＦに変更したり、今日のための他のユーザのＰＲＯＯＦを今日のための彼自身のＰＲＯＯＦに変更したりすることもできない。ＰＲＯＯＦは偽造したり、変更したりすることが本質的にできないので、これらのＰＲＯＯＦは保護される必要はない。したがって、エンティティＥはＰＲＯＯＦをごく僅かなコストで利用可能にしてもよい。たとえば、Ｅは、所与の日のすべてのＰＲＯＯＦをインターネット上に掲載し（たとえば、ＰＲＯＯＦをアカマイ・サーバまたは同等のサーバによって利用可能にし）または、ユーザによって容易に届けられることができる応答者／サーバへＰＲＯＯＦを送ることができる。たとえば、正しくアクセスされるドアの多くが置かれている空港（または、オフィス・ビルディング）の入り口に位置するサーバへＰＲＯＯＦを送ることができる。このようにして、働くために来ている従業員は（たとえば、サーバに接続されているカード・読み取り器に彼自身のカードを挿入することによって）彼自身のＰＲＯＯＦを容易に入手することができ、そして、たとえば、そのＰＲＯＯＦを、彼自身の資格認証と共に彼自身のカード上に格納する。このようにして、ユーザが、彼の資格認証がアクセスを認可しているドアへ自分のカードを提出すると、ドアは接続されることを全く必要とせずに、その資格認証を検証してもよいばかりでなく、現在認可されているＰＲＯＯＦを受け取って検証する。ドアはＰＲＯＯＦを（たとえば、Ｅの設置以来、Ｅが格納してもよいＥの公開キーによるＥのディジタル署名を）検証し、かつ、そのＰＲＯＯＦによって特定されている期間が正しいことを（たとえば、それ自身のローカル時計によって）検証する。もし、すべてが良好ならば、ドアはアクセスを許可し、そうでなければ、ドアはアクセスを拒否する。基本的に、ドアは、非接続にすることができ、しかも、そのＰＲＯＯＦの検証は比較的に容易であり（ドアは最も入手可能な当事者、すなわちアクセスを要求するユーザによってＰＲＯＯＦを受け取るので）、かつ、比較的にセキュアである（たとえ、ドアが、決定的に最も疑わしいと思われる当事者、すなわちアクセスを要求するユーザからＰＲＯＯＦを受け取る場合でも）。実際、アクセスを要求するユーザは通常、ドアの物理的近傍にあり、したがって、遠方のサイトに接続することなく非常に容易にＰＲＯＯＦを提供することができ、したがって、ドアの接続の無関係に動作してもよい。同時に、アクセスを要求するユーザは、そのきわめて重要なときに最も信じられない情報源であることがある。それでもなお、ユーザは彼の現在の正当性のあるＰＲＯＯＦを作ったり、多少なりとも変更したりしないので、正しく検証されたＰＲＯＯＦがＥによって作られなければならないということはドアにとっては確かなことであり、そして、もし、ユーザが所与の期間認可されていないことをＥが知っていたならば、ＥはＰＲＯＯＦを作らないであろう。ユーザが認可されることを止めるならば、Ｅは、該ユーザに対する認可のＰＲＯＯＦを発行することを停止し、したがって、アクセスを許可するためにドアが検証することを必要とするＰＲＯＯＦをそのユーザが欠いているので、ユーザは、もはや、非接続のドアにさえ入ることができない。したがって、ユーザが要求するアクセスを、正しい現在の認可を証明するために利用することによって、ここに記載されたシステムは、他のシステムに関連した不便、すなわち、非接続ドアをプログラミングするする作業員を派遣する必要が不要になる。
【００５８】
この方法は、「職務」によって（または「特権」によって）非接続のドアへのアクセスを管理することを可能にする。すなわち、資格認証が、その資格認証のユーザが入ることを認可されている１つまたは複数のドアを特定し、次に、（たとえば、毎日）資格認証の現在の有効性のＰＲＯＯＦを発行しないで（すなわち、所与の資格認証のユーザが所与の期間においてある１つまたは複数のドアに入ることを、該資格認証が認可することを明記するＰＲＯＯＦを発行しないで）、非接続のドアは（たとえば、設置時に）所与の職務をもつユーザだけにアクセスを許可するようにプログラムされていてもよい。たとえば、飛行機のコックピット・ドアは、パイロットと検査官のみに対してアクセスを許可するようにプログラムされる。資格認証は、従業員に対して先ず第１に彼らが本人であること（それは変化しない）を保証するために発行することができ、一方、所与の資格認証に対してＥが−たとえば、毎日−発行する各ＰＲＯＯＦは、その日におけるそれの対応するユーザの職務を（たとえば、ＡＩフィールドにおいて）特定することもできる。たとえば、ＰＲＯＯＦ＝ＳＩＧ_E(ＩＤ，ＤＡＹ，ＰＩＬＯＴ,ＡＩ)は、ＩＤによって識別される資格認証に対応するユーザがパイロットであることをＤａｙという日に証明する。このようにして、従業員は、ある職務から次の職務に、彼らの資格認証を再発行しなくても、またそのユーザはその日にどのドアにアクセスするかをユーザの資格認証内に、または、それに対応する毎日にＰＲＯＯＦに特定する必要がなく「移動」してもよい。なお、そのようなドアの数は非常に多い。したがって、ユーザがアクセスすることを認可される全てのドアをユーザの資格認証内で特定することは厄介である。さらに、もし、（たとえば、新しい飛行機が購入されたために）新たなドアが追加されるならば、追加のドアを特定するために、そのパイロットの資格認証が再発行されなければならず、このことも厄介である。
【００５９】
所与の資格認証に対して適切な期間は、資格認証それ自身内に特定され、または、資格認証とＰＲＯＯＦとの両方によって特定されてもよい。たとえば、資格認証は所定の開始日とそれが正当であると毎日証明される必要があることを指定し、一方、資格認証内に特定されている開始日後の２４４日をＰＲＯＯＦが参照することを示すために、ＰＲＯＯＦは期間２４４を特定してもよい。
【００６０】
本明細書に記載されているシステムは、もっと高価な接続ドアのシステムに比較して有利でもある。たとえば、全てのドアがセキュリティ上安全に中央のデータベースに接続され、かつ突然の停電が（たとえば、サボタージュによって）起こったと仮定しよう。そのとき、接続されたドアは、２つの極端な選択肢、すなわち、常時開（セキュリティ上安全に対しては良であるが、セキュリティに対しては不良、特に、テロリストが停電を起こしたならば）と、常時閉（セキュリティ上安全に対しては不良であるが、セキュリティに対しては良）の何れかを選択することを余儀なくされるであろう。それとは反対に、突然の停電の場合には、本明細書に記載されているシステムははるかにフレキシブルに応答し、幾つかの（もはや）接続されていないドアは常に閉じたままであるが、他のドアは常に開き、しかも、他のドアは、本明細書に記載されている非接続型ドアのアクセス制御のとおりに動作し続けることができる。すなわち、バッテリに頼るドアは、正しい資格認証と正しいＰＲＯＯＦがある場合にのみ開くことができる。事実、停電が起こる前に、全ての従業員が定期的に彼らの予定されたＰＲＯＯＦを受け取ってもよい。
【００６１】
エンティティＥは、勿論、異なる資格認証に対する異なる時間間隔を特定するＰＲＯＯＦを生成する。たとえば、空港設備において、警察官や救急要員は、次の２週間を該期間と指定するＰＲＯＯＦを毎日持ち、一方、全ての正規の従業員は該日のみを指定する毎日のＰＲＯＯＦを持つ。そのようなシステムは、長期の、かつ予期しない停電の場合に、よりよい制御を行うことができる。万一、そのような停電が起こると、ＰＲＯＯＦを毎日いつものとおりに配布することが中断させられ、普通の従業員は彼らの毎日のＰＲＯＯＦを受けることができないが、警察官や救急処理員は、彼らが前の日に受け取った２週間証明を彼らのカード中に未だ携帯しており、したがって、彼らが入ることを許可されている全てのドア（たとえば、全てのドア）を動作させ続けることができる。
【００６２】
本明細書に記載されている方法は、最小証明書と呼ばれることがある、証明書の縮小された形式からなる資格認証を用いることを含んでいる。最小証明書はユーザ名および/または証明書の識別子ＩＤを省略してもよい（または、むしろ、ユーザ名および/または証明書の識別子ＩＤを、各証明書に固有である証明書の公開キーに置き換える）。たとえば、最小証明書の資格認証は、この資格認証の正しい提示がＰＫに対応する秘密キーＳＫを知っていることを証明すること（たとえば、チャレンジ・応答方法によって）を含んでいるという理解のもとで、形式ＳＩＧ_E(ＰＫ,Ｄ₁,Ｄ₂,ＡＩ)をとる。ドアはＰＫに関する資格認証の正しい提示がなされるならば（なるべくならば、現在検証されるならば）アクセスを許可すべきか（否か）を予め知っている。あるいは、最小の資格認証Ｃは、対応するＳＫを知っているユーザが所与のドアに入るように資格を与えられているか否かを（たとえば、ＡＩ中に）指定してもよい。公開キーがＰＫである最小証明書に関するＰＲＯＯＦは、もしどのような同様の署名も有効であることを暗に示しているということが理解されるならば、形式ＳＩＧ_E(ＩＤ,Ｄａｙ,Ｖａｌｉｄ,ＡＩ)、ＳＩＧ_E(ＰＫ,Ｄａｙ,Ｖａｌｉｄ,ＡＩ)またはＳＩＧ_E(ＩＤ,Ｄａｙ,ＡＩ)をもつことができる。あるいは、最小証明書の通用ＰＲＯＯＦが短い期間の最小証明書の再発行の形式、たとえば、ＳＩＧ_E(ＰＫ,Ｄ₁,Ｄ₂,ＡＩ)をとることができる。ここで、開始日付Ｄ₁は所与の日Ｄの始まりを表し、Ｄ₂は日Ｄの対応する最後をあらわし、または、Ｄ₁=Ｄ₂=Ｄである。または、ＳＩＧ_E(ＰＫ,Ｄａｙ,ＡＩ)。または、Ｅを元の認証機関に一致させるとすると、ＳＩＧ_CA(ＰＫ, Ｄ₁,Ｄ₂,ＡＩ)またはＳＩＧ_CA(ＰＫ, Ｄａｙ,ＡＩ)。一般に、証明書を対象として本明細書に述べられているどの方法も、最小証明書にも当てはまると理解すべきである。
【００６３】
スマートドアは、対応する証明が付随することがあるユーザの資格認証の正当性と通用性を検証する。ある区域へのアクセスを得るためにユーザによって使用される資格認証／証明は、本明細書の他の所で論じられているように、電子装置へのアクセスを制御することに関連して使用される資格認証／証明と同様であってよい。次の記述は資格認証／証明の例で、そのあるものは、他のものと組み合わされることがある。
【００６４】
１．ドアに付属する、または、ユーザのカードによってドアへ通信されるキーパッドで入力されるＰＩＮまたはパスワード。
【００６５】
２．ドアに付属する特別な読みとり器によってユーザによって提供される生体認証情報。
【００６６】
３．ドアに付属する特別な署名パッドを介してユーザによって提供される従来（手書きの）署名。
【００６７】
４．公開キーＰＫのためのディジタル証明書（たとえば、そのような資格認証はユーザのカードに格納され、正当なユーザ／カードは、たとえば、チャレンジ応答プロトコルを介して、ドアに対してそれ自身を認証／識別するために、対応する秘密キーＳＫを使用してもよい。）たとえば、もし、ＰＫが署名公開キーであるならば、ドアは、所与のメッセージに署名してもらうことを要求し、正当なユーザ（対応する秘密署名キーＳＫを知っているただ一人の人）は、正しい要求された署名を提供してもよい。もし、ＰＫが公開暗号キーであるならば、ドアは、所与のチャレンジ暗号文が復号されることを要求する。復号は、対応する秘密復号キーＳＫを知っている正当なユーザによって行うことができる。
【００６８】
５．ユーザのカードに格納され、ドアに通知されている毎日の「正当性確認値」（これは、該証明書がこの特定の日付の日に正当であることを保証する）を含んでいる機能強化されたディジタル証明書。
【００６９】
６．ユーザの証明書が現時点で正当であることを確認し、サーバまたは応答者によってドアに通知される中央認可機関(central authority)のディジタル署名。
【００７０】
７．ユーザのカードに格納されてドアに通知されるディジタル証明書と、サーバまたは応答者によってドアに通知される毎日の「正当性確認値」。
【００７１】
８．ユーザのカードに格納されている秘密であって、それを知っていることが、知識ドアとの対話型（おそらくゼロ知識）プロトコルによってドアに対して証明される秘密。
【００７２】
９．ユーザのカード中に格納され、該ユーザがある特定の日に入ることを許可されていることを示す、認可機関(authority)の秘密キー署名。
【００７３】
このように、いくつかの場合において、複数の資格認証／証明は単一の部分に設けられ、他の場合には複数の資格認証／証明は別個の部分、すなわち、資格認証と分離して証明が設けられる。たとえば、資格認証／証明が、証明書がこの特定の日付において正当であることを示す毎日の正当性確認値を含み、かつ、ユーザに関連していてドアに通知されている、機能強化されたディジタル証明書から成る場合には、その資格認証（機能強化されたディジタル証明書）は、証明（毎日の正当性確認値）から分離して（異なる手段によっておよび/または異なる時点において）設けられる。同様に、資格認証と証明は全て同一の認可機関によって生成され、または異なる認可機関によって生成される。
【００７４】
図７を参照すると、図は物理的アクセスが制限される区域２０２を含むシステム２００を示している。区域２０２は複数の壁２０４−２０７によって囲まれている。壁２０７は、区域２０２への出口をもたらすドア２１２を備えている。他の実施形態においては、２以上のドアを用いてもよい。壁２０４−２０７およびドア２１２は、区域２０２へのアクセスに対する障害をもたらす。ドア２１２は、電子ロック２１４が適切な信号を受信しなければ、そして、電子ロック２１４が適切な信号を受信するまで、ドア２１２が開くことを妨げる電子ロック２１４を用いてロックしてもよい。電子ロックは、市販品の電子ロックを、これに限定することなく含む、本明細書に記載されている機能を提供する任意の適切な部材を用いて実施してもよい。
【００７５】
電子ロック２１４は、ドア２１２が開かれるように電子ロック２１４に適切な信号を出力するコントローラ２１６に接続してもよい。幾つかの実施形態においては、電子ロック２１４とコントローラ２１６とは単一のユニットで設けられる。コントローラ２１６は、ユーザの資格認証を受けとるとともに、任意に、ユーザが現在区域２０２に入ることを許可されていることを示す、対応する証明を受信する入力ユニット２１８に接続してもよい。入力ユニット２１８は、ユーザがもはや区域２０２に入ることが許されないことを示すホット取り消し警報(ＨＲＡ)をも受信する。ＨＲＡは、以下にさらに詳細に記述する。入力ユニット２１８は、キーパッド、カード・読み取り器、生体認証ユニット等のような、任意の適切な入力装置でよい。
【００７６】
任意に、コントローラ２１６は、データをコントローラ２１６へ、およびコントローラ２１６から送信するために用いられる外部接続２２２を備えている。外部接続２２２はセキュアであるが、いくつかの実施形態においては、外部接続２２２はセキュア安全でなくてもよい。さらに、本明細書に記載されている機能は、外部接続を持たないスタンドアロン型ユニットを用いて供与されるので、外部接続２２２は必要とされない。外部接続２２２が設けられている例では、外部接続２２２は、少なくとも、資格認証、証明、ＨＲＡを送信するために使用され、および/または、区域２０２へのアクセスの記録をとることに関連して使用されてもよい。アクセスの記録をとることは、本明細書の他の個所でさらに詳細に記述す」る。なお、外部接続２２２は、たとえば、あるときには外部接続２２２がコントローラ２１６のための接続をもたらすが、他のときにはコントローラ２１６のための外部接続はないというように、不連続的である。いくつかの場合では、外部接続２２２は資格認証／証明の一部分（たとえば、ＰＫＩディジタル証明書）を送信するために使用してもよいが、ユーザは、資格認証／証明の他の部分（たとえば、ディジタル証明書に関連して使用される毎日の正当性確認値）を入力ユニット２１８に提示する。
【００７７】
いくつかの実施形態においては、ユーザはカード２２４を入力ユニットへ提示する。本明細書の他の個所で述べたように、データ（たとえば、資格認証／証明）を入力ユニット２１８に出力するカード２２４は、スマート・カード、ＰＤＡ等であってよい。カード２２４はいくらかの、または全てのデータをトランスポンダー２２６から得る。他の場合では、カード２２４はデータを他のカード（不図示）から、入力ユニット２１８（または区域２０２へのアクセスに関する他の機構）から、または何らかの他の適切なソースから得る。
【００７８】
第１の例においては、資格認証および証明は、物理的保護を有するＰＩＮ／パスワードを用いて維持してもよい。この例においては、毎朝、サーバが認可された各ユーザＵのための新しい秘密パスワードＳＵを生成し、その新しいＳＵを、Ｕがアクセスすることを許可されている特定のドアへ通信する。この通信は、セキュアでない回線を使用して送られるために暗号化され、または、何か他のセキュアな手段によってドアへ送信してもよい。朝、Ｕが働くことを知らせると、中央サーバは、Ｕのカードが現在の秘密パスワードＳＵを受け取るようにする。秘密パスワードＳＵはカードのセキュアなメモリに格納され、このセキュア・メモリはカードは（たとえば、ユーザがカードに関連する秘密ＰＩＮを入力することによって、または、サーバまたはドア上の信頼されているハードウエアに接続することによって）正しく認証されているときにだけ読み出すことができる。ユーザがドアにアクセスしようとするときにはいつでもカードはセキュリティ上安全にドアへＳＵを通信する。ドアは、つぎに、カードから入力した値ＳＵが朝にサーバから入力した値と一致するかどうかチェックし、もし一致するならばアクセスを許可する。
【００７９】
したがって、ＳＵは１日に対するユーザの資格認証である。このシステムは、各資格認証が限定された連続期間をもつこと、すなわち、もし、従業員が解雇され、または彼のカードが盗まれると、彼の資格認証は翌日には役に立たないと言う利点がある。しかし、本システムは若干の接続性を必要とする。すなわち、少なくとも短期間の接続性（できるだけ、毎朝）がドアを更新するために必要である。この送信は（たとえば、物理的に、または、暗号によって）セキュアでなければならない。
【００８０】
他の例においては、ユーザの資格認証は秘密キー署名を含んでいる。この例は署名、すなわち、公開キー署名（たとえば、ＲＳＡ署名）または秘密キー署名（メッセージ認証コード、すなわちＭＡＣ）を利用する。たとえば、アクセス制御サーバは署名を作成するために秘密キーＳＫを用い、ドアはそのような署名を検証する手段を（たとえば、対応する公開キーによって、または、同じＳＫについての知識を共有することによって）備えている。ユーザがＤ日の朝に働くことを報告すると、サーバは、ＵのカードにＵの識別情報（たとえば、固有のカード番号、またはＵの秘密パスワード、または、Ｕの指紋のような生体認証情報）と日付Ｄとを認証する署名Ｓｉｇを受け取らせる。Ｕがドアにアクセスしようとすると、カードは署名Ｓｉｇをドアに伝え、ドアは、おそらく、Ｕによって与えられた識別情報と、ドアのローカル時計によって供給される日付に関連してその正当性を検証する。もし、全てが正しいならば、ドアはアクセスを許可する。
【００８１】
この技術では、署名Ｓｉｇはユーザの資格認証と証明とを併せたものであると考えることができる。この方法はそれ自身の利点、すなわち、カードは秘密を格納する必要がなく、ドアは中央サーバへのセキュアな接続や正当な資格認証の長いリストを維持する必要がない、という利点がある。
【００８２】
他の例においては、ユーザの資格認証は、図５のフローチャートに関連して生成される資格認証と同様な、ハッシュ・チェーン方式の正当性証明を有するディジタル証明書を含んでいる。この例は、公開キー署名と一方向性ハッシュ関数Ｈを利用する（特別のタイプのディジタル署名を実施する）。中央認可機関はキー対、すなわち、公開キーＰＫ（ドアに知られている）と一般に知られていない秘密キーＳＫを備えている。ユーザＵのついて、認可機関はランダムな秘密値Ｘ０を生成し、値Ｘ１＝Ｈ（Ｘ０）,Ｘ２＝Ｈ（Ｘ１）,..., Ｘ３６５＝Ｈ（Ｘ３６４）を計算する。Ｈは一方向性ハッシュ関数であるので、Ｘの各値はＸの次の値から計算することができない。認可機関は、ＳＫを用いて署名され、1年間有効な、値Ｘ３６５を含むディジタル証明書Ｃｅｒｔをユーザに発行する。次に、Ｕが日ｉに働くことを報告すると、認可機関はユーザのカードに、その日の正当性確認値Ｘｊ（ただし、ｊ＝３６５−ｉ）を受け取らせる。Ｕがドアにアクセスしようとすると、カードは正当性確認値Ｘｊと、Ｘ３６５を含んでいる証明書Ｃｅｒｔをドアに伝達する。ドアは認可機関の公開キーＰＫをもつＣｅｒｔの正当性を検証し、Ｘｊにｉ回適用されたＨがＸ３６５を生成することをチェックする。なお、「1年」と３６５は、任意の他の期間に置き換えることができる。
【００８３】
このように、ユーザの証明書Ｃｅｒｔと正当性確認値Ｘｊはユーザの資格認証／証明を構成する。このシステムは多くの利点を持っている。すなわち、ドアもカードも秘密を格納する必要がない、ドアはセキュアな接続を必要としない、証明書は1年に1回発行することができ、その後は、中央認可機関にかかる毎日の計算負荷は最小である（その認可機関はＸｊを取り出す必要があるだけであるので）、毎日の正当性確認値は、毎日の正当性確認値は秘密である必要はないので、
セキュアでない（安価な）分散されたレスポンダーによって提供してもよい。
【００８４】
ユーザＵに対する資格認証／証明は、その連続期間が限られている場合が多く、これは多くの状況において有用である。たとえば、もし、Ｕが空港の従業員であり、そして解雇されたならば、彼の資格認証／証明は当日の終わりに期限切れになり、彼は、もはや空港のドアにアクセスすることができない。さらに正確なアクセス制御のためには、連続期間がもっと短い資格認証を有することが望ましいだろう。たとえば、もしＵに対する資格認証／証明が日付のみならず、時と分を含んでいるならば、Ｕを解雇の1分以内に空港から閉め出すことができる。しかし、資格認証／証明は、連続期間が短いほど、より頻繁に更新する必要があり、このことによってシステムへの費用が増す。もし、空港の全ての従業員が、彼または彼女のカード上に毎分新たな資格認証／証明をアップロードしければならないならば、それは不都合なことであるはずある。したがって、短期間の資格認証を持ちたいという希望と低コストのシステムを持ちたいという希望の間に本来的な緊張関係があり、このことはしばしば希望よりも長くなる資格認証につながることがある。たとえば、Ｕは空港から直ちに閉め出される必要があるかもしれないが、彼の資格認証は真夜中まで期限切れしないであろう。したがって、まだ期限切れしていない資格認証を直ちに取り消すことが望ましい。
【００８５】
なお、もし、資格認証／証明が、アクセスが要求されるたびにドアによって検索されるセキュアなデータベース内に格納されるならば、たとえば、無効にされる資格認証／証明をデータベースから取り除くことによって資格認証／証明を無効にすることは比較的に直接的である。しかし、ドアが、毎回、セキュアなデータベースを検索することは費用がかかる。第１に、これは、ユーザがすぐにドアにアクセスすることを望むために彼は検索が正しく完了されることを待たなければならないので、処理にかなりの遅延をもたらすからである。第２に、この通信は、できるだけセキュアなチャネルを通って行われのが好ましいこのことはドア当たり４０００ドル（またはさらに多額）を容易に費やし、または、場合によっては（たとえば、空港または貨物コンテナのドアにとって）全く使用不可能であることがあるからである。第３に、単一のセキュアなデータベースは限定された検索負荷を処理してもよいだけで、セキュアデータベースを複製することは、それ自体高価で時間がかかるからである（たとえば、データベースをセキュな状態に保持する費用が倍にしなければならず、これらの複製を同期状態に保持するための努力が追加されなければならない）。したがって、完全に接続型の方法とは異なり、（上記の例における方法のような）非接続型または断続接続型の方法は、接続型の方法より少ない通信しか必要とせず、多くの場合、資格認証／証明を、セキュリティによって保護されていないレスポンダー上、またはカード自身上に格納する。そのような場合、資格認証／証明をデータベースから単に取り除くだけでは十分でない。再び、上記例に言及するために、パスワードＳＵ、または認可機関の署名、または妥当性確認値Ｘｊが何とかユーザのカードまたはドアから取り除かれなければならないであろう。さらに、セキュリティによって保護されていないレスポンダーに格納されている資格認証が、それを保存することができ、それをユーザのカードから除去した後にそれを使用しようとするた悪意のアタッカーを含む誰かに入手可能であるので、そのような取り除きをしても、資格認証の取り消しは必ずしも保証されない。このように、限定された連続期間の資格認証をもつ費用効率の高い解決策があるとしても、これらの解決策は、それだけでは、期限切れしていない資格認証／証明を十分に必ずしも取り消すことができない。
【００８６】
資格認証／証明の取り消しは、（期限切れしていない可能性があるが）無効にされた資格認証／証明を有するユーザに対してドアがアクセスを許可することを防止する、ドアに送信される（好ましくは認証された）データであるホット取り消し警報（ＨＲＡ）を用いて実行してもよい。たとえば、ＨＲＡは、所与の資格認証／証明が無効にされていることを示すディジタル署名されたメッセージからなっていてよい。しかし、署名は必ずしもＨＲＡ中に含まれなくてもよいことに注意されたい。たとえば、セキュリティ上安全に接続されたドアの場合、保護された接続に沿ってＨＲＡを送るだけで十分である。しかし、上記したように、セキュリティ上安全に接続されたドアは、ある場合には高価であり、他の場合には不可能（または、ほとんど不可能）である。
【００８７】
もし、ＨＲＡが与えられるエンティティが、該ＨＲＡが本物であることが比較的に確信するようにＨＲＡが認証されるならば、それは有益である。ＩＤを、無効にされた資格認証／証明Ｃに対する識別子とすると（特に、ＩＤはＣそれ自身に一致する）、ＳＩＧ（ＩＤ,"ＲＥＶＯＫＥＤ",ＡＩ）はＨＲＡである。ここで、"ＲＥＶＯＫＥＤ"は、Ｃが無効にされたことを信号で伝える任意の方法を表し（"ＲＥＶＯＫＥＤ"は、もし、資格認証／証明が取り消されているという事実が、無効の場合を除いてはそのような署名されたメッセージを送らないというシステムの慣例のような他の手段によって推論できたならば、おそらく空の文字列である）、ＡＩは付加的情報（資格認証／証明が無効にされたとき、および/またはＨＲＡが生成されたときのような、おそらく日付の情報または無情報）を表す。ディジタル署名ＳＩＧは、特に、公開キー・ディジタル署名、秘密キー・ディジタル署名、またはメッセージ認証コードである。また、正しく情報を暗号化することによって、認証されたＨＲＡを発行することも可能である。たとえば、認証されたＨＲＡは、形式ENC（ＩＤ,"ＲＥＶＯＫＥＤ",ＡＩ）を取ることができる。
【００８８】
認証されたＨＲＡの他の注目すべき例が、引用によって、本明細書に含まれたものとする米国特許５，６６６，４１６号に記載されている。発行機関（ｉｓｓｕｉｎｇ ａｕｔｈｏｒｉｔｙ)は資格認証／証明中に、Ｃに固有の（ディジタル署名方式の）公開キーＰＫを挿入し、その結果、そのＰＫに関連するディジタル署名はＣが無効にされていることを表す。そのような方式の特別な実施形態において、ＰＫは、Ｈは（好ましくは、ハッシュ法の）一方向性関数であり、Ｙ０は秘密値であるとして、Ｙ１＝Ｈ（Ｙ０）として計算される値Ｙ１から成る。資格認証／証明Ｃが無効にされると、Ｙ０だけから成るＨＲＡが発行される。そのようなＨＲＡは、Ｙ０をハッシュ演算し、その結果が資格認証／証明Ｃに属する値Ｙ１に一致することをチェックすることによって検証してもよい。
【００８９】
なお、署名はＨＲＡにとって必要ではない。たとえば、セキュリティ上安全に接続されているドアの場合、（ＩＤ,"ＲＥＶＯＫＥＤ",ＡＩ）を、保護された接続に沿って送るだけでＨＲＡとして十分であろう。しかし、認証されたＨＲＡの利点は、ＨＲＡ自身が秘密である必要がないということである。認証されたＨＲＡは、適切な認可機関によって一旦認証されると、もう１つの（おそらく、地理学的に分散された）レスポンダー上に格納される。さらに、これらのレスポンダーは、秘密情報を格納していないので、（発行機関とは異なり）保護されていないことがある。より大きな信頼性は、多数の保護されていないレスポンダーを複製することによって低コストで得られる。米国特許５，６６６，４１６号の認証されたＨＲＡの、さらに幾つかの利点は、（１）ＨＲＡが比較的短い（２０バイトと短かい）、（２）比較的容易に計算される（単に予め格納されているＹ０の検索）（３）比較的容易に検証される（一方向性ハッシュ関数を1回だけ適用）である。
【００９０】
認証されたＨＲＡは、以下にさらに説明するように、効率的に広く配布するのに特に有利である。ＨＲＡがドアへの途中に多数の点を通過するとき、正しくないＨＲＡがシステムに挿入される多数の可能性がある。事実、直接ではなく、または、セキュアな接続を経由して発行者からドアによって受信されたＨＲＡは、特定の資格認証の取り消しの単なる噂程度のものである。しかし、もしそのＨＲＡが認証されると、この噂はその真正性を検証してもよいドアによって容易に裏付けしてもよい。
【００９１】
一般に、ＨＲＡは単一の資格認証／証明に固有であり、または多数の資格認証／証明に関する無効情報をもたらす。たとえば、もし、ＩＤ１、・・・ＩＤｋが無効にされた資格認証の識別子であるならば、ＨＲＡは単一のディジタル署名ＳＩＧ（ＩＤ1,...,ＩＤｋ;"ＲＥＶＯＫＥＤ";ＡＩ）から成る。ドアにアクセスする権利をもつ複数の資格認証／証明を識別する情報を格納しているドアの場合を考えよう。もし、そのようなドアが１つまたは２以上の資格認証／証明が無効にされたことを示すＨＲＡを受信すると、そのドアはそのＨＲＡを格納する必要はない。そのドアは識別された１つまたは複数の資格認証／１つまたは複数の証明をその記憶装置から消去すれば（または、ともかくもそれらに”ＲＥＶＯＫＥＤ”というマークを付ければ）十分である。したがって、もし、無効にされた資格認証／証明をもつユーザがアクセスしようとするならば、ドアは、提示された資格認証／証明が現在ドアに格納されていない、または、もし格納されているとしても”ＲＥＶＯＫＥＤ”とマークされているのでアクセスを許可しないであろう。
【００９２】
さて、すべての許可された資格認証／証明を識別する情報を格納しておらず、むしろ、資格認証／証明が、提示されたとき、許可されているかどうかを検証するドアの場合を考えよう。ユーザが、資格認証／証明をそのようなドアへ提示したとき、ドアはＨＲＡを無視しながら、その資格認証／証明が有効であるかどうかをまず検証する。（たとえば、もし、資格認証／証明がディジタル署名を含んでいるならば、ドアはその署名を検証する。さらに、もし、資格認証／証明が期限切れ時を含んでいるならば、ドアは、たとえば、内部クロックを用いて、その資格認証／証明が期限切れでないこともまた検証する。）しかし、全てのチェックを合格しても、もし、資格認証／証明がＨＲＡによって無効にされていると示されているならば、ドアは、やはりアクセスを拒否する。したがって、そのようなドアが、関連するＨＲＡに関する情報を持っているならば、それは有益である。このことを達成する１つの方法は、ドアが、ドアに提示される全てのＨＲＡを保存することである。他方、いくつかの場合には、これは非実用的である。多くの資格認証／証明がそのドアを通過するために使用してもよいシステムを考えよう。たとえば、米国運輸省は、いろいろなときに、所与のドアへのアクセスを許可してもよい様々な個人（パイロット、空港職員、航空会社従業員、整備士、手荷物扱い人、トラック運転手、警官、等を含む）のための１０，０００，０００−資格認証システムを想定している。控えめに見積もって１０％の年間取り消し率（無効率）で、ドアは1年の最後までに１，０００，０００個のＨＲＡを格納しなければならないことになり、これは非常に費用のかかる（もし、そうでなければ、実行不可能な）仕事であるだろう。さらに、もし、ＨＲＡの量を予め正確に決定することができないならば、システムの設計者は、安全サイドをとるためにＨＲＡのメモリサイズを過大に見積もり、さらに大きなメモリ容量さえも（もっと高いコストをかけてさえも）ドア中に組みこまなければならないであろう。
【００９３】
この問題は除去可能なＨＲＡによって対処してもよい。ＨＲＡを有するこの手段は、ＨＲＡをメモリからセキュリティ上安全に除去してもよいか時間を特定する時間成分を示す。たとえば、連続期間が短い資格認証／証明を有するシステムでは、これは、（１）資格認証／証明に、期限の後には、資格認証／証明は、アクセスのために有効であるとしてドアによって承認されてならない期限を含ませ、（２）資格認証／証明を無効にするＨＲＡに期限を含ませ、（３）ドアに、期限の経過後は資格認証／証明を無効にするＨＲＡをそのメモリから除去させる、ことによって達成してもよい。たとえば、ある資格認証／証明に対する期限はその資格認証／証明が満了するときである（そしてその期限は該資格認証／証明内に明示的に含まれ認証してもよいであろうし、または、それはシステムにわたる仕様によって暗示される。）期限後に、そのようなＨＲＡを除去することはセキュリティを損なわない。事実、もし、ドアがある特定の資格認証／証明を無効にするＨＲＡを格納していないならば、それはドアが期限後にそのＨＲＡをメモリから消去したからであって、いずれにしても、その時点でその期限切れの資格認証／証明はドアによってアクセスを拒否されるであろう。
【００９４】
なお、期限がＨＲＡ内で暗示的に、または間接的に示すことができる場合には、上記のステップ（２）は任意である。たとえば、ＨＲＡは形式ＳＩＧ（C,"ＲＥＶＯＫＥＤ",ＡＩ）を持ってもよく、資格認証／証明はそれ自身の期限日付を含んでよい。さらに、除去可能のＨＲＡは、無効にされた資格認証の期限を全く示していないＨＲＡを用いて実施することもできるので、上記ステップ（１）は任意であってよい。たとえば、もし、特定のシステムにおける全ての資格認証が最大でも1日間有効であるならば、全てのＨＲＡは1日間格納された後消去される。（より一般的には、もし、資格認証／証明の最大の寿命が何とかして推論されるならば、対応するＨＲＡは、その時間の間、格納された後に消去される。）他の例について、特定の期限をもつ資格認証／証明を提示されたとき、ドアはその資格認証を無効にするＨＲＡを探す。もし、それが存在し、かつ、その期限が既に経過しているならば、ドアはそのＨＲＡをセキュリティ上安全に除去する。そうでなければ、ドアは格納されているＨＲＡに関連する期限を格納して、その期限後、そのＨＲＡを除去する。
【００９５】
ドアは、ＨＲＡをその満了後に様々な方法で除去する。場合によっては、ＨＲＡの除去は、期限に基づいてＨＲＡのデータ構造（優先キューのような）を維持することによって効果的に行うことができる。あるいは、ドアは、メモリ中の全てのＨＲＡを周期的に点検して、もはや必要でないものを除去する。別の選択肢として、もし、ドアがＨＲＡに遭遇したときにそのＨＲＡがもはや関係ないということをわかったならば、ドアはＨＲＡを消去する。たとえば、ＨＲＡは、資格認証が検証のために提示されるごとにチェックされるリストに格納してもよい。そのようなリスト内で期限切れのＨＲＡに出会ごとにその期限切れＨＲＡは除去される。さらにもう１つの選択肢として、ドアは、メモリが解放される必要があるとき（多分、他のＨＲＡのために）、必要に応じてのみＨＲＡを除去する。
【００９６】
除去可能なＨＲＡは、ドアにおいて必要とされるメモリをかなり減少させる。上記の、１０，０００，０００人のユーザと１０％の年間無効率の例を用いた場合に、もしＨＲＡが満了して除去されるならば、1日に平均僅かに２，７４０（１，０００，０００の代わりに）個のＨＲＡが格納される必要があるだけである。この小さくされたメモリ要件は除去可能なＨＲＡの大きな潜在的な利点である。
【００９７】
もはや受理できない資格認証／証明をドアに知らせるために、ＨＲＡをできるだけ早くドアに入手可能にすることが有益である。これは非接続型ドアにとって問題でありが、完全な接続型ドアにとっても問題である。勿論、完全な接続型ドアには、ＨＲＡが発行されたときにドアの接続を通ってＨＲＡが送られる。しかし、この送信もやはり所定の敵に阻止され、または妨害されることがある。（たとえば、たとえ、ドアへの接続が暗号法的な手段によってセキュリティ上安全にされていても、敵は配線を切断し、または伝送されている信号を変更し／フィルタリングすることがある。もし、ドアへの接続がスチール・パイプ内に配線を走らせることによってセキュリティ上安全にするならば、そのような妨害と阻止はもっと難しくなるだろうが、やはり不可能ではない。）ＨＲＡの悪意のある妨害と阻止は、断続的（たとえば、無線の）接続性をもつドアに対しては、さらにより実行し易くなるであろう。
【００９８】
ドアがＨＲＡを受け取ることを敵が邪魔することをさらに難しくするために、ＨＲＡは無効にされたカードそれ自体によって保持されることがある。たとえば、カードがデータベース、または接続されているドア（または、該ＨＲＡを知っているドア）と通信をするときに、ドアはカードにＨＲＡを送り、カードはそのＨＲＡを格納する。特に、このことは、そのカードを改ざんしてＨＲＡを除去することを望んでいるユーザから保護するように、ユーザに何ら知らせずに行なうことができる。この方法は、もし、カードが、改ざんし難いハードウエア部品、またはユーザによって容易には読み出され／除去されないデータ（たとえば、暗号化されたデータ）を保持しているならば、より効果的である。カードがその後任意の（たとえ、完全な非接続型でも）ドアへのアクセスを得ようとして使用されるとき、カードはそのＨＲＡをドアに伝達、ドアは正しい検証をするとき、アクセスを拒否し（そして、ある場合にはそのＨＲＡを格納する）。
【００９９】
ＨＲＡは無線チャネルを通って（たとえば、ページャーまたはセルラー・ネットワークを介して、または衛星を介して）カード自身へ送られる。これは、たとえカードが限定された通信機能、たとえば、各ユーザが通過しそうな位置に無線送信機を配置することによって行うことができる。たとえば、ビルディングにおいては、そのような送信機は、複数のカードの１つのユーザがビルディングに入るごとに、全てのカードが送信を受信する機会を与えるように、ビルディングの各エントランスに置いてもよい。あるいは、送信機は駐車場等の入り口に置いてもよい。
【０１００】
悪意のあるユーザが（たとえば、送信された信号が通らない材料でカードを包むことによって）送信を阻止することを防止するために、カードは、正しく機能するように、それが周期的送信を受信することを実際に必要とするであろう。たとえば、カードは、そのクロックをシステムのそれに同期させるために５分ごとに信号を期待し、または、ＧＰＳ信号のような（好ましくはディジタル署名された）他の周期信号を受信することを期待し、または、適切な周波数で適切なノイズでさえも期待してもよい。もし、そのような信号が適切な時間間隔で受信されないならば、カードは「ロック」し、どのドアとの通信を単に拒絶し、このことは、カード自身をアクセスに適合させなくする。なお、そのようなシステムは、ＨＲＡは特別注文で、絶えずメッセージを変更しているので、全てのＨＲＡを単に全てのカードにブロードカストするよりも経済的で便利であろう。したがって、ＨＲＡを全てのカードにブロードカストすることは、特別の目的の人工衛星を打ち上げるか、既存のものをカスタマイズすることを必要とするであろう。上記の方法はその代わりに、広域の送信のための既に使用可能な信号を利用し、かつ特別注文のメッセージのための非常にローカルな送信機を設置する。
【０１０１】
あるいは、もしセキュリティポリシーが、セキュリティバッジのように、目で見えるようにカードを身につけることをユーザに要求するならば、または、それを（送信範囲内の）適切な場所で守衛に提示することをユーザに要求するならば、ユーザは、カードへの送信を阻止することが防止されるようにしてもよい。特定のカード／資格認証／証明のためのＨＲＡを配布する付加的な技術は、ＨＲＡをドアへ運ぶために他のカードを使用することを含んでいる。この変形例においては、Ｃａｒｄ１が（たとえば、それ自身の毎日の資格認証／証明を検知したとき、または無線で、または接続されたドアと通信をするとき、または、何かの種類の接続をするときに）ＨＲＡ、すなわち、異なるカードＣａｒｄ２に関連する資格認証／証明を無効にするＨＲＡ２を受け取る。Ｃａｒｄ１は、次に、ＨＲＡ２を格納しＨＲＡ２をドアへ伝達し、ドアは次にＨＲＡ２を格納する。Ｃａｒｄ１は、実際にＨＲＡ２を多くのドア、たとえば、全てのドア、または、特定の期間（たとえば、まる一日）Ｃａｒｄ２にアクセスし、またはＣａｒｄ２と通信する全ての接続されていないドアへ出力する。この時点において、Ｃａｒｄ１が到着したどのドアも（たとえ、非接続であっても）無効にされた資格認証／証明を含んでいるＣａｒｄ２の保持者へのアクセスを拒否してもよい。ＨＲＡ２はディジタル署名され、または自動認証し、そして、Ｃａｒｄ１が到着したどのドアも、偽のＨＲＡの悪意のある配布を防止するようにＨＲＡ２の真正性をチェックするのが好ましい。
【０１０２】
この方法は、Ｃａｒｄ１が到着したドアに、もう１つのカード、すなわち、次にそれにアクセスする、または、そのドアと通信するＣａｒｄ３へ学習されたＨＲＡ２を伝達させることによって機能を向上させてもよい。これは、Ｃａｒｄ１が到着していない、またはＣａｒｄ３より遅く到着するドアにＣａｒｄ３が到着するので有用である。このプロセスは、これらの追加的にカードが到着したドアに、他のカード等へ通信させることによって連続する。さらに、幾つかのドアは、たとえ中央のデータベースに十分に接続されていなくても、相互への接続を持っていてもよい。したがって、そのようなドアは利用可能なＨＲＡを同様に交換してもよい。もし、カード同士が相互との通信機能を持っているならば−たとえば、非常に近接しているとき−、それらは、それらが格納しているＨＲＡに関する情報を交換することもできる。
【０１０３】
なお、認証されたＨＲＡは本明細書に論じられているＨＲＡ配布技術の場合に特に有利である。実際、多数の媒介物（カードとドア）を通してＨＲＡを送ることは、ＨＲＡが変更され、または偽造ＨＲＡが敵対者によって差し込まれることがある多数の障害点をもたらすことになる。ある意味では、認証されないＨＲＡは、それがドアに到着するときまで単なる噂にとどまるだけである。一方、認証されたＨＲＡは、それがどのようにしてドアに到達しようとも正当であることが保証される。
【０１０４】
資源が重要な関心事でない場合においては、全てのＨＲＡを格納し、このようにして配布してもよいであろう。幾つかの最適化を採用することも可能である。たとえば、カードはドアのようなＨＲＡメモリを管理し、内部カードメモリを解放し、他のドアとの不必要な通信を防止するために期限切れのＨＲＡを除去してもよい。そのようなシステム内において、メモリと通信とを最小化することは、期限切れになっていない無効にされた資格認証の数がたとえ足りなくても、構成要素（たとえば、幾つかのカードまたはドア）によっては、期限切れになっていない全てのＨＲＡを処理するための十分なメモリまたはバンド幅を持っていないものがあるので、有用である。
【０１０５】
メモリと通信とを最小化するもう１つの可能性は、どのカードを経由してどのＨＲＡが配布されるべきかを選択することを含んでいる。たとえば、ＨＲＡが、特定の資格認証／証明についての知識をできるだけ迅速に広げることについての相対的重要性を示す優先情報を伴っていてもよい。たとえば、あるＨＲＡには「緊急」というマークを付け、他のＨＲＡには「ルーチン」というマークを付けてもよい。（優先度の等級付けは必要に応じて細かくまたは粗くしてよい。）限られたバンド幅またはメモリを持つ装置は、高優先度のＨＲＡについての情報を記録し交換し、そして、資源が許す場合にのみその注意を低優先度のＨＲＡに向けるようにしてもよい。もう１つの例として、あるカードが所与のドアにアクセスすることを防ぐＨＲＡは、該ドアに迅速に到達する可能性がより高いカード（たとえば、該ドアまたはその近傍のドアへアクセスできるようにする資格認証をもつカード）によって配布してもよい。実際に、カードとドアは、どのＨＲＡを格納および/または追加的な配布のために受理するべきかを設定するという目的との通信に従事してもよい。あるいは、複数のＨＲＡまたはそれらを格納する複数のカードは無作為を含む方法で選択してもよく、または、ドアはＨＲＡをある数のカード（たとえば、該ドアが「遭遇した」最初のｋ個のカード）へ与えてもよい。
【０１０６】
そのような配布技術の使用は、非接続型のドアに対してさえ、ユーザが、他のユーザが最新のカードと共に適切なＨＲＡを該ドアに与える前に、該ドアに到達しなければならないので、無効にされた資格認証／証明を持つユーザがアクセスを得ることができる可能性を低減させることがある。複数のカードと複数のドアの間の情報の交換は、多くのカードに取り消しを迅速に知らされることを確実にするのを助ける。この方法は、接続型ドアの接続を絶ち、ドアがＨＲＡを受け取るのを妨げようとする「妨害」攻撃に対する対抗手段としても用いてよい。たとえ、妨害攻撃が成功し、ドアが中央サーバまたはレスポンダーからＨＲＡを知らされなくても、個々のユーザのカードは、何らかの方法でＨＲＡをドアに知らせる可能性がある。なお、カードとドアとの間でＨＲＡを交換する実際の方法を変更してもよい。いくつかの短いＨＲＡの場合、全ての既知のＨＲＡを交換して比較することが最も効率的であろう。もし、多くのＨＲＡが１つのリストに集められるならば、そのリストは、そのリストがいつサーバによって発行されたかを示す時間を含んでいてよい。その場合には、カードとドアは、先ず、ＨＲＡのそれらのリストの発行時を比較し、古いリストを持つものが、そのリストを新しいリストに置き換えることがある。その他の場合には、相違点を発見して一致させるより高度なアルゴリズムを用いてもよい。
【０１０７】
効率的なＨＲＡ配布は、（１）認証されたＨＲＡを発行すること、（２）その認証されたＨＲＡを1つまたは２つ以上のカードに送ること、（３）そのカードにその認証されたＨＲＡを他のカードおよび/またはドアへ送らせること、（４）ドアに、受け取ったＨＲＡを格納させる、および/または、他のカードに送信させること、によって行うことができる。
【０１０８】
以下の幾つかのサンプルＨＲＡの使用を詳細に示すことは有用であろう。
手順１(「認可機関」から直接ドアへ）
１． エンティティＥはユーザＵのための資格認証／証明を無効にし、その資格認証／証明が無効にされているという情報を含むＨＲＡＡを発行する。
【０１０９】
２． Ａは、有線または無線通信によってドアＤへ送信される。
【０１１０】
３． ＤはＡの真正性を検証し、もし、検証が成功したならば、Ａに関する情報を格納する。
【０１１１】
４． Ｕが、資格認証／証明を提示することによってＤにアクセスしようとすると、ドアＤは、Ａについての格納されている情報が、該資格認証／証明が無効にされていることを示していることに気づき、アクセスを否認する。
手順２（「認可機関」からユーザのカードへ、ドアへ）
１． エンティティＥはユーザＵのための資格認証／証明を無効にし、その資格認証／証明が無効にされているという情報を含むＨＲＡＡを発行する。
【０１１２】
２． もう1人のユーザＵ’は働くことを報告し、彼の現在の資格認証／証明を得るために，Ｅに彼のカードを提示する。
【０１１３】
３． Ｕ’のための現在の資格認証／証明と共に、ＨＲＡＡがＵ’のカードに送信され、カードはＡを格納する。（カードは、該カードの機能に応じて、Ａの真正性を検証してもしなくてもよい。）
４． Ｕ’がドアＤにアクセスしようとする、彼のカードはＡと共に、彼の資格認証／証明をＤに送信する。
【０１１４】
５． ＤはＡの真正性を検証し、もし、検証が成功すると、Ａを格納する。
【０１１５】
６． Ｕが彼の資格認証／証明を提示することによってＤにアクセスしようとすると、ドアＤは、ＡがＵの資格認証／証明を無効にしていることに気づき、アクセスを否認する。
手順３（「認可機関」からもう１つのドアへ、ユーザのカードへ、ドアへ）
１． エンティティＥはユーザＵのための資格認証／証明を無効にし、Ｕの資格認証／証明が無効にされているという情報を含むＨＲＡＡを発行する。
【０１１６】
２． Ａは、有線または無線通信によってドアＤ’へ送信される。
【０１１７】
３． Ｄ’はＡの真正性を検証し、もし、検証が成功すると、Ａを格納する。
【０１１８】
４． 自分自身の資格認証／証明をもつもう1人のユーザＵ’がＤ’へのアクセルを得るために彼のカードをＤ’に提示する。Ｄ’はＵ’の資格認証／証明を検証することに加えて、もし適切であるならばアクセスを許可し、ＡをＵ’のカードに送信する。カードはＡを格納する（カードは、そのカードの機能に応じてＡの真正性を検証してもよいし、しなくてもよい。）
５． Ｕ’がドアＤへアクセスしようとすると、彼のカードは彼自身の資格認証／証明をＡと共にＤへ送信する。
【０１１９】
６． Ｄ’はＡの真正性を検証し、もし検証が成功すればＡを格納する。
【０１２０】
７． Ｕが彼の資格認証／証明を提示してＤへアクセスしようとすると、ドアＤは、ＡがＵの資格認証／証明を無効にしていることを気づき、アクセスを否認する。
手順４（「認可機関」からユーザのカードへ、ドアへ）
１． エンティティＥはユーザＵのための資格認証Ｃを無効にし、Ｃが無効にされているという情報を含むＨＲＡＡを発行する。
【０１２１】
２． 自分のカードを携行しているユーザＵは、ビルディングの入り口近くに設置されている送信点を通過し、これによって彼のカードはＡを受信する。カードはＡを格納する。（カードは、カードの機能に応じてＡの真正性を検証してもよいし、しなくてもよい。）
３． ＵがＤにアクセスしようとすると、彼のカードはＣと共にＡをＤに送信する。
【０１２２】
４． ＤはＡの真正性を検証し、もし検証が成功すればＡを格納してＵへのアクセスを否認する。
【０１２３】
５． もし、ＵがＣを提示することによって再度Ｄへアクセスしようとするならば、ドアＤは、以前に格納した、Ｃを無効にするＡに気づき、アクセスを否認する。
【０１２４】
誰がある特定のドアにいつアクセスしようとしたか、どの資格認証／証明が提示されたか、アクセスが否認されたか、許可されたかを事後にはっきりさせることは有益であることがある。ドアの機構が故障したか、スイッチやセンサが機能しなくなったか等を知ることも有用である。このために、発生するイベントのイベント・ログを保持することが望ましいであろう。そのようなログは、それが検査され、それに基づいて行動してもよいように、ある中央の場所で容易に入手可能であるならば、特に有用である。たとえば、ハードウエアの障害が起こった場合に修理チームを迅速に派遣する必要がある。しかし、そのようなログに２つの主要な問題がある。
【０１２５】
第１に、もし、ドアが接続されているならば、接続を経由してログを送ることによってそれを収集することは容易である。しかし、非接続のドアにとってイベント・ログを収集することはより困難であろう。勿論、ログを収集する１つの方法は、ログを中央の指定区域へ物理的に戻すために全ての非接続に人を送ることであるが、この方法は費用がかかる。
【０１２６】
第２に、イベント・ログが信頼されるためには、ログの生成、収集、および格納を含む全システムのインテグリティが保証されなければならない。そうでなければ、たとえば、敵対者は偽のログ・エントリを発生して正当なエントリを削除するかもしれない。通信チャネルおよびデータ格納設備を物理的にセキュリティ上安全にするような従来の方法は非常に高価である（そしてそれだけでは十分ではないかもしれない）。
【０１２７】
従来のログは、「あるユーザがあるドアへ行った」ということを、正当であるとみなさなければならない、そのようなログ・エントリの存在のみによって保証する。しかし、これは、高セキュリティの用途には適当でないであろう。ユーザＵがロックされているドアＤの背後にある財産を損傷したことを非難されることを考えよう。従来のログ・エントリは、ＵがＤに入ったという弱い証拠を提供するだけである。すなわち、誰も悪意でログ・エントリを改竄したのではないと信じなければならないであろう。したがって、ログは敵によって「製造」されないから、遙かに強力な証拠を提供するログを備えることが望ましい。特に、疑う余地なく正当な（ｉｎｄｉｓｐｕｔａｂｌｅ）ログは、ドアが（できればＵのカードと協働して）ログ内に記録を生成したことを証明するであろう。
【０１２８】
本明細書に記載されているシステムはこのことに次のようにして対処する。ドアがアクセス要求の一部として提示された資格認証／証明を受け取るごとに、ドアは、イベント、たとえば、
要求の時間、
要求の型（もし、２つ以上の要求が可能ならば−たとえば、要求が、出るまたは入るための要求、または、エンジンをオンまたはオフにするための要求等であるならば）、
提示された資格認証／証明または身元（もし、あるならば）、
資格認証／証明が成功裏に検証されたかどうか、
資格認証／証明が対応するＨＲＡを持っていたかどうか、
アクセスが許可されたか、または、否認されたか、
に関する情報を含むログ・エントリ（たとえば、データ列）を生成することがある。
【０１２９】
ログ・エントリは、動作データ、または、何らかの異常のイベント、たとえば、電流または電圧の変動、センサの故障、スイッチ位置、等に関する情報を含んでいてよい。疑う余地なく正当なログを作る1つの方法は、秘密キー（ＳＫ）によって、ドアに、イベント情報にディジタル署名させることを含む。その結果として生成された疑う余地なく正当なログは、ＡＩは任意の付加的情報を表すとして、ＳＩＧ（ｅｖｅｎｔ，ＡＩ）によって表すことができる。ＡＩは任意の付加情報を表す。ドアＤによって用いられる署名方法は、公開キーまたは秘密キーであってよい。
【０１３０】
もし、有効な署名に関連する公開キーＰＫ、または、その署名を作成するときに使用される秘密きーＳＫ、またはその署名を生成したドアを重要視することが有用ならば、疑う余地なく正当なログを、ＳＩＧ_PK（Ｅｖｅｎｔ，ＡＩ）, ＳＩＧ_SK（ＥＶＥＮＴ，ＡＩ）, ＳＩＧ_D（ＥＶＥＮＴ，ＡＩ）によって記号で表すことができるであろう。そのようなログは、敵が、ドアの署名を、関連する秘密キーを知ることなく偽造することができないので、疑う余地なく正当であろう。一方、ログの真正性は、正しく知らされた検証者（たとえば、ドアのＰＫ、またはドアのＳＫを知っている人）によって、ログを格納しているデータベースのインテグリティ、またはログを送信するシステムのインテグリティを信頼する必要なしにチェックしてもよいであろう。一般に、ログは、各エントリをディジタル署名することによるばかりでなく、多数のエントリのためのディジタル認証ステップを用いることによって、疑う余地なく正当なものにしてもよい。たとえば、ドアは、記号ＳＩＧ(Ｅ1,...,Ｅ２，ＡＩ)で表されるディジタル署名を用いて多数のイベントＥ１，Ｅ２．．．を認証してもよいであろう。例のどおり、本出願のどこにおいても、ディジタル署名は、認証されるべきデータの一方向性ハッシュ演算にディジタル署名をする処理を意味する。特に、ストリーム認証は、ディジタル署名の特別な場合と見なしてもよい。たとえば、認証された各エントリが次の（または前回の）エントリを認証するために使用してもよい。これを行う１つの方法は、認証されたエントリが、次の、または他のエントリを認証するために使用される公開キー（特に、ワンタイムディジタル署名の公開キー）を含むようにすることから成る。
【０１３１】
ログと、疑う余地なく正当なログは、カードによって作ってもよい（特に、カードは、イベントＥについての情報にディジタル署名をする（記号で表すと、ＳＩＧ(Ｅ，ＡＩ)）ことによって、疑う余地なく正当なログを作成してもよい）。本明細書に記載されているログ技術の全ては、カードによって作られたログに関連すると解釈してもよい。
【０１３２】
さらに、他のログと、疑う余地なく正当なログとは、ドアとカードの両方を関係させることによって得てもよい。たとえば、ドア・アクセスの要求中、カードは、ドアへのカード自身の（おそらく疑う余地なく正当な）ログ・エントリをドアに出力する。ドアはそのログ・エントリを検査して、ドアがそのログ・エントリが「受理可能」であることを知った場合にのみアクセスを許可する。たとえば、ドアは、カードの、ログ・エントリを認証するディジタル署名を検証し、または、ドアは、カードのログ・エントリに含まれている時間情報が、ドアへアクセス可能なクロックに照らして正しいことを検証する。
【０１３３】
疑う余地なく正当なログの他のタイプは、ドアとカードとの両者をログ・エントリの生成および/または認証に寄与させるようにすることによって得られるであろう。たとえば、カードはログ・エントリを認証し、ドアは次にもログ・エントリ情報の少なくとも一部をも認証し、その逆の動作も行なわれる。特定の実施形態においては、カードＣは、そのログ・エントリの署名ｘ=ＳＩＧ_C(Ｅ，ＡＩ)をドアに与え、ドアはログ・エントリの署名に記号ＳＩＧ_D（ｘ，ＡＩ‘）でカウンターサインし、その逆の動作も行われる。あるいは、ドアとカードはイベント情報のジョイントディジタル署名を計算してもよい（たとえば、ドアとカードに分割された秘密署名キーによって、または、ドアの署名をカードの署名と組み合わせて単一の「多重」署名にすることによって計算される。）幾つかの多重署名方式、特に、Ｍｉｃａｌｌ, ＯｈｔａおよびＲｅｙｚｉｎの方式を用いてもよい。
【０１３４】
ログへ付加情報を含めることが可能である。その場合には、カードによって報告された情報とドアによって報告された情報が一致するかどうかをチェックしてもよい。たとえば、カードとドアの両方とも、それらに利用可能なクロックを用いて、時間情報をログ・エントリ中に含めてもよい。さらに、カード（とおそらくドアも）位置情報（ＧＰＳから得られるような）をログ・エントリ中に含めてもよい。あるいは、もし、（たとえば、ＧＰＳの受信機能が使用不可能のために）現在の位置が入手できないならば、最近の既知の位置（と、おそらく、どの位前にそれが確定されたか）に関する情報を含めてもよい。このようにして、特に、（飛行機のドアのような）可動のドアの場合には、イベントが起こったときにドアとカードがどこに位置していたかを確定することが可能である。
【０１３５】
勿論、上記の疑う余地なく正当なログ・エントリでさえも、完全に、データベースから悪意で削除されたり、または、データベースに到達することを妨げられたりすることがあり得る。そのような削除から保護するために、削除検出可能・ログ・システム（Ｄｅｌｅｔｉｏｎ-Ｄｅｔｅｃｔａｂｌｅ Ｌｏｇ Ｓｙｓｔｅｍｓ）を設けることが有益である。このようなシステムは、（１）認証方式（たとえば、ディジタル署名方式）、（２）相関生成方式、および（３）相関検出方式を用いることによって、次のように構築してもよい。１つのログ・イベントＥ（イベントの、おそらく過去のイベントおよび/または将来のイベントのシーケンスの一部）が所与のものとすると、相関生成方式を、相関情報ＣＩを生成するために用いてもよく、相関情報ＣＩは次に、削除検出可能・ログ・エントリを生成するために認証方式によってＥにセキュリティ上安全に接続される。たとえ、複数のベントそれら自身が相関しておらず、かつ１つのイベントの存在が他のイベントの存在から推定されなくても、ＣＩは、紛失したログ・エントリについて、相関検出方式を用いて検出してもよい情報である正しく相関している情報は存在しないことを保証するように生成されるのを相関生成方式は確実なものとする。幾つかの場合では、システムは、たとえ、幾つかのログ・エントリが紛失しても、他のログ・エントリは真正である、および/またはそれぞれ疑う余地なく正当であると保証してもよいということを確実なものとする。
【０１３６】
第１の例においては、ログ・エントリの相関情報ＣＩはログ・エントリの通し番号付けを含む。対応する相関検出方式は、番号付けの順番にギャップがあることに気付くから成ることができる。しかし、削除検出可能・ログ・システムを得るために、ＣＩとログ・エントリとの間の正しい結合が求められるが、それは、たとえ、セキュアなディジタル署名がシステムの認証要素のために用いられても、容易には行うことはできない。たとえば、ｉ番目のログ・エントリが(i,ＳＩＧ（ｅｖｅｎｔ，ＡＩ）)から成るようにすることはその理由は、敵は、あるログ・エントリを削除したのち、ギャップを隠すために、それに続くエントリの番号付けを変更してもよいのでセキュアではない。特に、ログ・エントリ番号１００を削除した後、敵対者は、ログ・エントリの番号１０１、１０２等を１だけ減らすことがある。敵は、たとえ、イベント情報のインテグリティがディジタル署名によって保護されても、番号付けそのものは保護されることがないので、そのようにして彼の削除を隠蔽してもよい。さらに、数にもディジタル署名をすることはうまくいかない。たとえば、ｉ番目のログ・エントリが(ＳＩＧ(i),ＳＩＧ（ｅｖｅｎｔ，ＡＩ）からなると仮定する。すると、敵は、削除を完全に隠蔽するように、（１）ＳＩＧ(100)に気づいてこれを記憶し、（２）エントリ番号１００を削除し、（３）ＳＩＧ(101)を記憶しながら、元のエントリ１０１におけるＳＩＧ(１０１)の代わりにＳＩＧ(１００)を置換し、等々をしてもよい。
【０１３７】
上記の２つの方法はいずれも、ＣＩとログ・エントリとの間の所望のセキュアな結合を作らない。実際、（１）番号付け情報と（２）番号付けされるイベントとをセキュリティ上安全に結合るとは、ｊがｉと異なるとき、たとえ、（ａ）番号ｉとＥｉのセキュな結合と、（ｂ）番号ｊとＥｊのセキュアな結合とが与えられていても、敵がある番号ｊと、ｉ番目のイベントＥｉに関するイベント情報との結合を作らないということである。たとえば、ｉ番目のログ・エントリはＳＩＧ(i,Ｅｉ,ＡＩ)からなる。このように、後のログ・エントリが所与とすると、ｉ番目のログ・エントリの削除は検出される。その理由は、後のログ・エントリには、それがログ・エントリにセキュリティ上安全に結合されているため、敵対者によって除去されたり、変更されたり、他のログ・エントリの番号付け情報に切り替えられたりすることができない、ｉより大きい番号を付随させることができるからである。たとえば、敵対者がログ・エントリ番号１００、ＳＩＧ(１００,E１００,ＡＩ)を削除すると仮定しよう。敵対者が彼の削除を隠蔽するために、全ての後続のログ・エントリを削除する（それは、データベースへの連続的なアクセスを必要とするであろう）ことができない限り、敵対者は同一の番号１００を持つもう１つのログ・エントリを発生する必要があるであろう。しかし、これは、（ａ）敵対者はドアの秘密署名キーを持っていないので、新しい１００番目のログ・エントリＳＩＧ(１００,Ｅ',ＡＩ')を生成することができない、（ｂ）敵対者は既存のログ・エントリを、そのディジタル署名を無効にしないで、変更することができない（たとえば、たとえ、敵対者が削除されたエントリＳＩＧ(１００,Ｅ１００,ＡＩ１００)を記憶していてもＳＩＧ(１０１,Ｅ１０１,ＡＩ１０１)をＳＩＧ(１００,Ｅ１０１,ＡＩ１０１)に変更することはできない）、（ｃ）敵対者は、番号１００を示すログ・エントリの一部の署名を抽出して、それをもう１つのログ・エントリに対するディジタル署名に結び付けることはできない、ので、困難であるであろう。
【０１３８】
そのようなセキュアな結合は、エントリ番号と番号付けされたイベントとに併せてディジタル署名以外の手段を用いて行うこともできる。たとえば、それは、エントリ番号と番号付けされたイベントとを一方向性ハッシュ処理し、次にそのハッシュに、記号的には、ＳＩＧ(Ｈ(i,Ｅｉ,ＡＩ))で署名をすることによって行うことができる。他の例に関しては、それは、番号のハッシュをイベントのディジタル署名に含めることによって、または、その逆の処理を、たとえば、記号ＳＩＧ(i,Ｈ(Ｅｉ),ＡＩ))、によっても行うことができる。それは、イベント情報のディジタル署名と共に、番号付け情報に、たとえば、記号的にＳＩＧ(ｉ,ＳＩＧ(Ｅｉ),ＡＩ))、と署名することによっても行うことができる。さらに他の選択肢として、（１）固有の文字列ｘと共に番号付け情報と、（２）固有の文字列ｘと共にイベント情報に、別個に、記号的には、（ＳＩＧ(ｉ,ｘ), ＳＩＧ(ｘ,Ｅｉ,)ＡＩ)）と署名してもよい。（そのような文字列ｘはナンス（ｎｏｎｃｅ）であり得る。）
削除検出可能ログは通し番号付け情報以外のログ・エントリ相関情報とセキュリティ上安全に結合することによって得られる。たとえば、ログ・エントリｉに、先のログ・エントリ、たとえば、エントリｉ−１からのある識別情報を含めることができる。そのような情報はエントリｉ−１（またはログ・エントリｉ−１の一部分）の耐衝突性ハッシュであってもよく、すなわち記号的にはログ・エントリｉはＳＩＧ(Ｈ(ｌｏｇ ｅｎｔｒｙ i−1),Ｅｉ,ＡＩ)と表すことができる。したがって、もし、敵対者がログ・エントリｉ−１を削除しようとするならば、そのような削除は、（Ｈの耐衝突性のために）前回に受け取られたログ・エントリのハッシュＨ（ｌｏｇ ｅｎｔｒｙ ｉ−２）はＨ（ｌｏｇ ｅｎｔｒｙ ｉ−１）と一致しないため、ログ・エントリｉが受け取られたとき検知されるであろう。一方、Ｈ（ｌｏｇ ｅｎｔｒｙ ｉ−１）は、それがログ・エントリｉにセキュリティ上安全に結合されているので、ディジタル署名の正当性を破壊することなく敵対者によって変更することができないであろう。ここでログ・エントリｉとは、Ｅｉのような、ｉの情報の部分集合である。
【０１３９】
エントリｉと結合している情報を持つのはログ・エントリｉ−１である必要はないことに注意されたい。それは先の、または将来のもう１つのエントリでもよいし、または、事実上、多数の他のエントリでもよい。さらに、どのログ・エントリがどのログ・エントリに結合するべきかは、無作為を用いて選択される。
【０１４０】
他の相関情報を使用してもよい。たとえば、各ログ・エントリｉは、それとセキュア２つの値（たとえば、乱数値またはナンス）ｘ_iおよびｘ_i+1をセキュリティ上安全に、すなわち記号的には、たとえば、ＳＩＧ(x_i,x_i+1,Ｅｉ,ＡＩ)で結合してもよい。したがって、２つの連続したログ・エントリは１つのｘ値を常に共有し、すなわち、たとえば、エントリｉとエントリｉ＋１はｘ_i+1を共有するであろう。しかし、もし、ログ・エントリが削除されると、このことは、もはや成り立たない。（その理由は、敵対者は、署名のための秘密キーを知っているのでなければ、署名されたログ・エントリを検出しないで変更することはできないからである。）たとえば、もし、エントリ番号１００が削除されるならば、データベースはＳＩＧ(ｘ₉₉,ｘ₁₀₀,Ｅ99,ＡＩ)とＳＩＧ(x₁₀₁,x₁₀₂,
Ｅ101,ＡＩ)を含み、それらは共通のｘ値を共有していないことがわかる。そのような相関情報は他の形をとることができる。事実、ログ・エントリは多くの他のログ・エントリと相関させることができる。このことは、特に、相関情報を生成するための多項式を使用することによって行うことができる（たとえば、２つ以上のログ・エントリがそれぞれ、異なる入力値に対して同じ多項式の値を求めた結果を含んでよい）。そのような相関情報はハッシュ・チェーンを使用してもよい。たとえば、値ｙ₁から出発してｙ₂＝Ｈ（ｙ₁）、ｙ₃＝Ｈ（ｙ₂）・・・等、とし、次に、ｙ_iをＥｉにセキュリティ上安全に結合する。たとえば、ｉ番目のログ・エントリは記号的にＳＩＧ(y_i,Ｅｉ,ＡＩ)と表すことができる。したがって、連続するログ・エントリｉおよびｉ＋１は、ｙ_i+1＝Ｈ（ｙ_i）であるように、相関値ｙ_i、ｙ_i+1を持つ。しかし、もし敵対者がログ・エントリを削除するならば、この関係はもはや成り立たず、したがって、削除を検出してもよい。たとえば、もし、エントリ１００が削除されると、データベースはＳＩＧ(ｙ₉₉,Ｅ99,ＡＩ)およびＳＩＧ(y₁₀₁,E１０１,AI)を含むであろう（これらは、前と同様に、ディジタル署名を変形することなく敵対者によって変更することはできない）。その場合には、Ｈ（ｙ₁₀₁）がｙ₉₉に一致しないので削除を検出してもよい。おそらく、非連続エントリにおいて両方向に用いられるであろう多重ハッシュ・チェーンを使用すれば、そのような相関情報が得られるであろう。
【０１４１】
他の実施形態において、各ログ・エントリは前回のイベント、または、後続のイベントでさえも、その幾つかまたは全ての表示を含み、したがって、ログを削除検出可能にするのみならず、削除の場合には再構成可能にしてもよい。再構成可能なログ・システムは、（１）認証方式（ディジタル署名方式）、（２）再構築情報生成方式、および（３）再構築方式を用いることによって次のように構築してもよい。１つのログ・イベントＥ（一連のイベント、おそらく一連の過去および/または将来のイベントの一部）が所与とすると、再構築情報生成方式は再構築情報ＲＩを生成するために用いられ、ＲＩは次に、認証方式によって他のログ・エントリにセキュリティ上安全に結合される。再構築情報生成方式は、たとえ、イベントｉに対応するログ・エントリが失われても、他のログ・エントリが、他のログ・エントリ内にあるＲＩからＥの再構築を可能にするようにＥについての十分な情報を含むことを確実にする。たとえば、ｉ＋１番目のエントリは、再構築情報生成方式によって生成された、先のｉ個のイベントの全てまたは幾つかに関する情報を含んでよい。したがって、敵がとにかくデータベースからｊ番目のログ・エントリを消去することに成功したとしても、ｊ番目のイベントＥｊについての情報が1つまたは2つ以上の後続するエントリに出現し、たとえｊ番目のログ・エントリがなくてもその再構築方式を用いて情報Ｅｊを再構築することが可能になるであろう。したがって、敵がデータベースに一時的にアクセスしても十分ではないであろう。すなわち。敵は、j番目のイベントについての情報が明らかにされるのを妨げるために、「四六時中」データベースを監視し、多数のログ・エントリを削除しなければならないであろう。どのイベントをログ・エントリに含めるかの選択は、敵が、何時、所与のイベントについての情報が連続したログ中に出現するであろうかを予測することをより困難にするように、再構築情報生成方式によってランダムにおこなうことができる。再構築可能なログのためのシステムは削除検出可能で疑う余地のなく正当であることが望ましい。
【０１４２】
なお、他のログ・エントリへ含められるイベントｊについての再構築情報は直接的である必要はないことである。それは、エントリｊの一部、または、その（特に、再構築情報生成方式によって、一方向性／耐衝突性ハッシュ関数を用いて計算された）ハッシュ値ｈ_j、または、そのディジタル署名、または任意の他の表示からなっていてよい。特に、もし一方向性耐衝突性ハッシュ関数Ｈが用いられるならば、ｈ_jを含んでいるログ・エントリｉから、すなわち、もしｉ番目のエントリが署名されているならば、対応する疑う余地なく正当なログは記号的には形式ＳＩＧ（ｈ_j，Ｅｉ，ＡＩ）をとることができるログ・エントリｉからj番目のイベントについての情報を疑う余地なく正当に回復することが可能である。たとえば、特定のユーザが特定の時間に特定のドアに入ったのではないかと疑うならば、値ｈ_jが、そのようなイベントに応答して発生させられたであろうログ・エントリＥｊのハッシュＨ（Ｅｊ）に一致するかどうかをテストすることができる。これは、Ｈの耐衝突特性のために、疑う余地なく正当である。すなわち、Ｈ（Ｅ‘ｊ）＝Ｈ（Ｅｊ）が成り立つような、Ｅｊと異なるＥ’ｊを思いつくことは本質的に不可能である。
【０１４３】
ログ・エントリＥｊは、所与のイベントに対するログ・エントリが何であるべきかを推測し（そして、したがって検証する）ことをより容易にするような方法（たとえば、粗い時間精度を用いてログ・エントリのための標準化されたフォーマット等を用いることによって）で生成してもよい。一方向性ハッシュ処理は、その小さなサイズのために特に有用である。すなわち、多くの先のログ・エントリを、または全ての先のログ・エントリさえも、後続のエントリに含めるためにハッシュ処理することが可能である。たとえば、エントリｉ＋１はｈ₁=Ｈ(Ｅ₁), ｈ₂=Ｈ(Ｅ₂), ..., ｈ_i=Ｈ(Ｅ_i)を含んでよい。あるいは、ハッシュ（の幾つか）をネストすることができ、それによって必要なスペース量を減らすことができる。たとえば、もしそれらの全てをネストするならば、２番目のログ・エントリはｈ₁=Ｈ(Ｅ₁)を含み、３番目のログ・エントリはｈ₂=Ｈ(Ｅ₂,ｈ₁)を含み、・・・であろう。したがって、もし、ログ・エントリ１からｉ−１およびログ・エントリｉ＋１を再構成し、または気づくことができるならば、疑う余地なく正当にログ・エントリｉを再構成することができる。このシステムは、敵が特定のイベントの再構成可能性を弱めるためにどの情報を破壊しなければならないかを知ることができないように、ログ・エントリ内の情報（のあるもの）を（たとえば、データベースだけに知られているキーで）暗号化することによって改良してもよい。実際、一旦、ログが暗号によって保護されると、そのような暗号化されたログ（疑う余地なく正当に暗号化されたログが望ましい）は、秘密性を失うことなく他の（第２の）データベースへ移すことができる。これは、敵にとって削除をさらにより難しくする。すなわち、今は、敵はログを改竄するために２つ以上のデータベースへのアクセスを得なければならない。
【０１４４】
再構成可能なログは誤り訂正コードを使用して得てもよい。特に、これは、各ログ・エントリの多重成分（「共有成分」）を生成し、ログ・エントリが、十分に多くの共有成分を受け取ったときに、誤り訂正コード用のデコード・アルゴリズムを行使してもよい再構成方式によって再構成されるように、それら（共有成分）を個別に（たぶん、他のログ・エントリと共に）送ることによって行うことができる。これらの共有成分はランダムに、または疑似ランダムに配分することができ、これは、十分な共有成分が最終的に到達したとき、ログ・エントリの再構成を妨害するために、敵対者がそれらの十分に多数を除去することが困難にする。
【０１４５】
（カードによって作成されようとも、ドアによって作成されようとも、またはその両者によって協働して作成されようとも）イベント・ログは、それらの収集を容易にするためにカードに保持されてよい。カードが、接続されたドアに到達し、または中央サーバと通信をし、または、そうでなければ、中央データベースと通信することができるとき、カードはそのなかに格納されているログを送ることができる。このことは、ＨＲＡが中央点からカードに送られることができることを除いてＨＲＡの配布と同様に行うことができ、これに対してログはカードから中央点に送られてもよい。したがって、ＨＲＡを配布する全ての方法はイベント・ログの収集にも当てはまる。具体的には、ＨＲＡを配布する方法は、（１）送信機を受信機の代わりに使い、そして受信機を送信機の代わりに使い、（２）ＨＲＡをログ・エントリに置き換えることによってイベント・ログを収集する方法に変換することができる。
【０１４６】
特に、カードＣ１は、他のカードＣ２によるアクセス、またはドアＤの誤動作のようなＣ１に無関係のイベントのためのイベント・ログを収集してもよい。さらに、１つのドアＤ１のためのイベント・ログは、（おそらく、カードＣ１によって他のドアＤ２に運ばれて）そのドアＤ２上に（おそらく一時的に）格納してもよい。次に、他のカードＣ２がＤ２と通信したとき、他のカードＣ２は、これらのログ・エントリの幾つかを受け取り、そして、後にそれらを他のドアまたは中央の場所に伝達してもよい。この広域の配布は、イベント・ログがより早く中央点に到着することを確実にする。（さらに、幾つかのドアは、完全に中央のデータベースに接続されていなくても、相互に接続を持つことが可能である。したがって、そのようなドアは、入手可能なイベント・ログを同様に交換してもよい。もし、複数のカードが相互間の通信機能を備えているならば（たとえば近傍にあるとき）、それらのカードは、彼らが格納しているイベント・ログについての情報を交換してもよい。）そのような収集処理においては、疑う余地なく正当なログは、それらが改竄することができないので、それらがセキュリティ上安全なチャネルを通って運ばれる必要がないので、有利である。したがって、それら複数のカードまたは複数のカードと複数のドアとの間の接続のセキュリティに頼らない。削除検出可能のログは、もし、幾つかのログ・エントリが（おそらく、幾つかのカードが接続されたドアにまだ到達していないため）収集されないならば、この事実を検出してもよいことを確実にすることによって、追加の利点を有する。再構成可能なログは、幾つかのログ・エントリが、（この場合も、おそらく、幾つかのカードが接続されたドアにまだ到達していないために）中央のデータベースに到着しないと、ログ・エントリの再構成をさらに考慮に入れてもよい。
【０１４７】
幾つかの場合、全てのイベント・ログは格納されて、このように配布することができるであろう。その他、幾つかの最適化法を採用することは有益である。１つの最適化の方法は、イベント・ログに、特定のイベントについて中央の認可機関に情報を与えることの相対的重要性を示す優先情報を付属させることである。あるログ・エントリは、たとえば、もしドアが開いた位置または閉じた位置に固定されているならば、もし認可されないアクセスが試みられるならば、または、もし、異常なアクセス・パターンが検出されるならば、他のログ・エントリよりも緊急に重要であることがある。そのような重要な情報が影響を与えることができる位置へのその情報の送信を速めるために、アクセスログ内の情報には、その重要性を示すタグを付けてもよい（または、その重要性は情報そのものから推論してもよい）。たとえば、あるログ・エントリには「緊急」という標識を付け、他のログ・エントリには「ルーチン」という標識を付け、または、それらの重要度を示す数字またはコード語によって標識を付けてもよい。（優先度は適宜細かく、または粗くしてもよい。）より重要性の高い情報の配布に、多大の努力または高い優先度を当ててもよい。たとえば、より高い優先度の情報を、それがその目的地により早くまたはより確実に着く可能性を増すために、より多くのカードおよび/
またはドアに与えてもよい。また、カードまたはドアは、高い優先度の情報を受け取ったとき、低優先度の情報をそのメモリから除去することによってそこに空き領域を作ってもよい。同様に、ドアは、通過する全てのカードに高優先度の情報を与えることを決定し、一方、低優先度の情報は、ほんの僅かなカードに与えられ、または、ドアが接続される時まで待ってもよい。
【０１４８】
上記の技術の代わりに、またはそれに加えて、カードは、特定のログ・エントリを無作為を含む方法で格納することを選択し、または、ドアはある数のカード（たとえば、ドアが「出会う」最初のｋ個のカード）へログ・エントリを提供してもよい。そのような配布技術の使用は、イベント・ログ中の重要なエントリに作用する中央の位置にそれが到達することができなくなる可能性を著しく減らす。特に、それは、損傷したドアがその損傷を伝達しないようにする「妨害」攻撃に対する効果的な対抗策として使用してもよい。複数のカードと複数のドアの間でログを交換する実際の方法は変えてもよい。少数のエントリの場合には、全ての既知のエントリを交換して比較することが最も効率的である。他の場合には、相違を見つけて調整するためにさらに高度なアルゴリズムが適切である。
【０１４９】
エントリ・ログを収集する幾つかのサンプル方法を詳細に提示することは有益かも知れない。以下において、「認可機関」Ａは、イベント・ログが収集される、ある中央点またはデータベースを含んでいる。
手順１（ドアから直接、認可機関へ）
１． 接続されたドアＤはイベントに応答して疑う余地なく正当なログ・エントリＥを発生する。
【０１５０】
２． Ｅは有線または無線通信によって認可機関Ａへ送信される。
【０１５１】
３． ＡはＥの認証を検証し、検証が成功すれば、Ｅを格納する。
手順２（ドアからユーザのカードへ、認可機関へ）
１． ドアＤはイベントに応答して疑う余地なく正当なログ・エントリＥを発生する。
【０１５２】
２． Ｄへのアクセスのために提示されるユーザＵのカードはＥを受け取り、格納する（アクセスに関連する通信に加えて）。カードはＥの認証を検証してもよいし、しなくてもよい。
【０１５３】
３． Ｕが退職して勤務日の最後に彼のカードをＡに提示するとき、ＥはカードによってＡに送信される。
【０１５４】
４． ＡはＥの認証を検証し、検証が成功すればＥを格納する。
手順３（ドアからユーザのカードへ、他の（接続されている）ドアへ、認可機関へ）
１． ドアＤはイベントに応答して疑う余地なく正当なログ・エントリＥを発生する。
【０１５５】
２． Ｄへのアクセスのために提示されるユーザＵのカードはＥを受け取り、格納する（アクセスに関連する通信に加えて）。カードはＥの認証を検証してもよいし、しなくてもよい。
【０１５６】
３， 後に、Ｕは他の（接続されている）ドアＤ’へのアクセスのために彼のカードＣを提示する。Ｄ’は資格認証を検証し、適切であるならば、アクセスを許可することに加えて、ＣからＥを受け取る。Ｄ’はＥの認証を検証してもよいし、しなくてもよい。
【０１５７】
４． ＥはＤ’によって有線通信または無線通信によって認可機関Ａへ送信される。
【０１５８】
５． ＡはＥの認証を検証し、検証が成功すればＥを格納する。
【０１５９】
保護される区域は、複数の壁と、人が入るために通るドアや、コンテナ、食料棚、車両等のドアのような複数の物理的ドアによって区画されてもよい。保護される区域は、複数の仮想ドアと複数の壁によって区画されてもよい。たとえば、区域は、もし、認可が与えられなければ、侵入を感知し、おそらく警報をならし、または他の信号を送ることができる検出器によって保護してもよい。そのような警報システムは仮想ドアの一例である。すなわち、空港においては、多くの場合、出口通路を通って搭乗区域に入ると、たとえ、物理的ドアまたは壁が侵犯されなくてもそのような警報が始動する。仮想ドアのもう１つの例が料金所である。すなわち、多くの料金所は物理的なバーやドアを備えていなくても、所与の車は料金所を通過することを認可され、または、認可されない。そのような認可は、たとえば、車の電子料金請求券の有効性に依存してもよい。さらに、もう１つの例は交通規制区域の仮想ドアである。たとえば、所与の都市のダウンタウン、または核施設、軍隊の兵舎や他の機密を要する区域へ通ずる道路へ入るためには、車両は、料金支払い、セキュリティ、渋滞制御のような目的のために正しい認可を受けなければならない。
【０１６０】
さらに、保護は区域に対してばかりでなく、飛行機のエンジンや軍事設備のような装置に対しても必要であろう。たとえば、認可された個人だけが、危険物を運ぶ飛行機またはトラックのエンジンを始動してもよいことを確実なものにすることは必要であろう。
【０１６１】
アクセス制御のために資格認証／証明を使用する多くの方法がある。なお、本明細書の開示では、下記の用語「日」は、一連の期間の中の一般的な期間を意味し、「朝」は、期間の初めを意味すると理解すべきである。
【０１６２】
この出願の全体を通して、「ドア」は全てのタイプ（たとえば、少なくとも物理的または仮想的の何れか）の入り口(ｐｏｒｔａｌ)、アクセス制御システム／装置、監視システム／装置を含んでいると解釈されるべきである。特に、それらは、エンジンおよび制御設備を始動するために用いられるキー機構を含んでいる。（したがって、本発明は、特に、現在許可されているユーザだけが飛行機を発進させ、アースムーバを作動させ、または貴重および/または危険な他の種々の物体、装置または機械にアクセスし、制御してもよいことを保証するために使用することができる）。この仕様と一致して、「入る」は、（物理的にかまたは仮想的に）所望のアクセスを許可することを指す。
【０１６３】
同様に、具体的に、しかし意図された一般性を失うことなく、カードはユーザの何らかのアクセス装置を意味すると理解されてもよい。カードの概念は、携帯電話、ＰＤＡ、その他の有線および/または高性能の装置を含むように十分に概括的であり、カードは、ＰＩＮ、パスワード、生体認証のような他のセキュリティ手段を含みまたはこれらと共に動作するが、これらのいくつかはカード自体の中というよりもカード保持者の頭脳または身体に「内在」している。
【０１６４】
さらに、「ユーザ」（たびたび、「彼」または「彼女」と呼ばれている）という表現は、ユーザおよび人々ばかりでなく、限定なしにユーザカードを含む、装置、エンティティ、（およびユーザ、装置、およびエンティティの集合）を含むものと広義に理解してもよい。
【０１６５】
本明細書に記載されているシステムは、ハードウエアと、1つまたは２つ以上のプロセッサによってアクセスされるコンピュータ読み出し可能な媒体に格納されているソフトウエアを、限定なしに含むソフトウエアの任意の適切な組み合わせを用いて実施してもよい。さらに、暗号化、認証等に使用される技術は、適宜、組み合わせ交換して使用してもよい。これに関連して、つぎの米国特許および出願のそれぞれを参照としてここに含める。
米国仮特許出願６０／００４，７９６号 １９９５年１０月２日出願；
米国仮特許出願６０／００６，０３８号 １９９５年１０月２４日出願；
米国仮特許出願６０／００６，１４３号 １９９５年１１月２日出願；
米国仮特許出願６０／０２４，７８６号 １９９６年９月１０日出願；
米国仮特許出願６０／０２５，１２８号 １９９６年８月２９日出願；
米国仮特許出願６０／０３３，４１５号 １９９６年１２月１８日出願；
米国仮特許出願６０／０３５，１１９号 １９９７年２月３日出願；
米国仮特許出願６０／２７７，２４４号 ２００１年３月２０日出願；
米国仮特許出願６０／３００，６２１号 ２００１年６月２５日出願；
米国仮特許出願６０／３４４，２４５号 ２００１年１２月２７日出願；
米国仮特許出願６０／３７０，８６７号 ２００２年４月８日出願；
米国仮特許出願６０／３７２，９５１号 ２００２年４月１６日出願；
米国仮特許出願６０／３７３，２１８号 ２００２年４月１７日出願；
米国仮特許出願６０／３７４，８６１号 ２００２年４月２３日出願；
米国仮特許出願６０／４２０，７９５号 ２００２年１０月２３日出願；
米国仮特許出願６０／４２１，１９７号 ２００２年１０月２５日出願；
米国仮特許出願６０／４２１，７５６号 ２００２年１０月２８日出願；
米国仮特許出願６０／４２２，４１６号 ２００２年１０月３０日出願；
米国仮特許出願６０／４２７，５０４号 ２００２年１１月１９日出願；
米国仮特許出願６０／４４３，４０７号 ２００３年１月２９日出願；
米国仮特許出願６０／４４６，１４９号 ２００３年２月１０日出願；
米国仮特許出願６０／４８２，１７９号 ２００３年６月２４日出願；
米国仮特許出願６０／４８８，６４５号 ２００３年７月１８日出願；
米国仮特許出願６０／５０５，６４０号 ２００３年９月２４日出願；
米国特許出願０８／７１５，７１２号 １９９６年９月１９日出願；
米国特許出願０８／７４１，６０１号 １９９６年１１月１日出願；
米国特許出願０８／７５６，７２０号 １９９６年１１月２６日出願；
米国特許出願０８／８０４，８６８号 １９９７年２月２４日出願；
米国特許出願０８／８０４，８６９号 １９９７年２月２４日出願；
米国特許出願０８／８７２，９００号 １９９７年６月１１日出願；
米国特許出願０８／９０６，４６４号 １９９７年８月５日出願；
米国特許出願０９／９１５，１８０号 ２００１年７月２５日出願；
米国特許出願１０／１０３，５４１号 ２００２年３月２０日出願；
米国特許出願１０／２４４，６９５号 ２００２年９月１６日出願；
米国特許出願１０／４０９，６３８号 ２００３年４月８日出願；
米国特許出願１０／８７６，２７５号 ２００４年６月２４日出願；
米国特許５，６０４，８０４号；
米国特許５，６６６，４１６号；
米国特許５，７１７，７５７号；
米国特許５，７１７，７５８号；
米国特許５，７９３，８６８号；
米国特許５，９６０，０８３号；
米国特許６，０９７，８１１号；
米国特許６，４８７，６５８号．
【０１６６】
本発明が種々の実施形態に関連して開示したが、その変形例は当業者にとって容易に明らかであろう。したがって、本発明の要旨と範囲は添付の特許請求の範囲に記載されている。
【図面の簡単な説明】
【０１６７】
【図１Ａ】接続、複数の電子装置、管理エンティティ、および証明配布エンティティを含む、本明細書に記載されているシステムの実施形態を説明する図である。
【図１Ｂ】接続、複数の電子装置、管理エンティティ、および証明配布エンティティを含む、本明細書に記載されているシステムの他の実施形態を説明する図である。
【図１Ｃ】接続、複数の電子装置、管理エンティティ、および証明配布エンティティを含む、本明細書に記載されているシステムの他の実施形態を説明する図である。
【図１Ｄ】接続、複数の電子装置、管理エンティティ、および証明配布エンティティを含む、本明細書に記載されているシステムの他の実施形態を説明する図である。
【図２】本明細書に記載されているシステムによる電子装置をさらに詳細に示す図である。
【図３】本明細書に記載されているシステムによる、検証を行うべきか否かを判定する電子装置に関連して実行されるステップを示すフローチャートである。
【図４】本明細書に記載されているシステムによる、検証を行う処理に関連して実行されるステップを示すフローチャートである。
【図５】本明細書に記載されているシステムによる、資格認証を生成する処理に関連して実行されるステップを示すフローチャートである。
【図６】本明細書に記載されているシステムによる、資格認証に違反する証明をチェックする処理に関連して実行されるステップを示すフローチャートである。
【図７】本明細書に記載されているシステムによって物理的アクセスが制限されるべき区域を含むシステムを説明する図である。

【特許請求の範囲】
【請求項１】
アクセスを選択的に許可するコントローラを有する、アクセスに対するバリアを設けることと、
複数の資格認証／複数の証明を生成する少なくとも１つの管理エンティティを有し、
期限が過ぎた証明に対する資格証明と値だけが所与の場合には有効な証明を確定不可能であり、
前記コントローラは前記資格認証／証明を受信し、
前記コントローラはアクセスが現在認可されているか否かを判定し、
もし、アクセスが現在認可されているならば、前記コントローラはアクセスを許可する、
アクセスを制御する方法。
【請求項２】
前記資格認証／証明は１つの部品内にある、請求項１に記載の方法。
【請求項３】
前記資格認証／証明は別個の部品内にある、請求項１に記載の方法。
【請求項４】
前記複数の資格認証を生成する第１の管理エンティティと、前記複数の証明を生成する他の管理エンティティがある、請求項３に記載の方法。
【請求項５】
前記第１の管理エンティティは証明をも生成する、請求項４に記載の方法。
【請求項６】
前記第１の管理エンティティは証明を生成しない、請求項４に記載の方法。
【請求項７】
前記複数の資格認証は、一方向性関数を、前記複数の証明のうちの第１の証明に適用した結果である最終値を含むディジタル証明書に対応する、請求項１に記載の方法。
【請求項８】
前記複数の証明の各々は、一方向関数を、前記複数の証明のうちの将来の証明に適用した結果である、請求項7に記載の方法。
【請求項９】
前記ディジタル証明書は、前記電子装置に対する識別子を含んでいる、請求項7に記載の方法。
【請求項１０】
前記資格認証は、一方向性関数を、前記複数の証明のうちの第１の証明に適用した結果である最終値を含んでいる、請求項１に記載の方法。
【請求項１１】
前記複数の証明の各々は、一方向性関数を、前記証明のうちの将来の証明に適用した結果である、請求項１０に記載の方法。
【請求項１２】
前記資格証明がアクセスを要求しているユーザに対する識別子を含んでいる、請求項１に記載の方法。
【請求項１３】
前記資格認証／証明がディジタル署名を含んでいる、請求項１に記載の方法。
【請求項１４】
アクセスに対するバリアが複数の壁とドアを含んでいる、請求項１に記載の方法。
【請求項１５】
前記コントローラに接続されたドアロックを設けることをさらに含み、該コントローラがアクセスを許可することは、該コントローラが、ドアを開くことができるようにするために、前記ドアロックを作動させることを含んでいる、請求項１４に記載の方法。
【請求項１６】
前記コントローラに接続された読み取り器を設けることをさらに含み、前記コントローラは該読み取り器から資格認証／証明を受け取る、請求項１に記載の方法。
【請求項１７】
前記資格認証／証明はユーザによって提示されるスマート・カード上に設けられている、請求項16に記載の方法。
【請求項１８】
前記コントローラへの外部接続を設けることをさらに含む、請求項１に記載の方法。
【請求項１９】
前記外部接続が断続的である、請求項１８に記載の方法。
【請求項２０】
前記コントローラが前記外部接続を用いて複数の資格認証／証明の少なくとも一部を入力する、請求項１８に記載の方法。
【請求項２１】
前記コントローラが前記外部接続を用いて前記資格認証／証明の全てを入力する、請求項２０に記載の方法。
【請求項２２】
前記コントローラに接続された読み取り器を備えることをさらに有し、該コントローラは前記読み取り器から前記資格認証／証明の残りの部分を受け取る、請求項２０に記載の方法。
【請求項２３】
前記資格認証／証明がユーザによって提示されるスマート・カード上に設けられている、請求項２２に記載の方法。
【請求項２４】
前記資格認証／証明がユーザによって書き込まれたパスワードを含んでいる、請求項１に記載の方法。
【請求項２５】
前記資格認証／証明がユーザの生体認証情報を含んでいる、請求項１に記載の方法。
【請求項２６】
前記資格認証／証明が手書きの署名を含んでいる、請求項１に記載の方法。
【請求項２７】
前記資格認証／証明がユーザによって保持されたカード上に設けられた秘密値を含んでいる、請求項１に記載の方法。
【請求項２８】
前記資格認証／証明は所定の時に期限が切れる、請求項１に記載の方法。

【図１Ａ】

【図１Ｂ】

【図１Ｃ】

【図１Ｄ】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【公表番号】特表２００７−５００８８５（Ｐ２００７−５００８８５Ａ）
【公表日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願番号】特願２００６−５２１１３３（Ｐ２００６−５２１１３３）
【出願日】平成１６年７月１６日（２００４．７．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２２８１０
【国際公開番号】ＷＯ２００５／０１０６８５
【国際公開日】平成１７年２月３日（２００５．２．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ウィンドウズ
【出願人】（５０４３７４８６１）コアストリート、　リミテッド (4)
【氏名又は名称原語表記】ＣＯＲＥＳＴＲＥＥＴ，　ＬＴＤ．
【Ｆターム（参考）】