(57)【要約】【課題】新たな認証方法を用いることなく、端末等の外部機器と認証装置との間で必要とされる相互認証を容易に行う。【解決手段】認証装置１００は、外部機器の認証を行う認証手段１００１と、前記認証手段１００１が用いる認証方法に対応する認証コードを保持する認証コード保持手段１００３と、該装置が有するメモリ領域を管理するＩＣカード手段１００６と、前記ＩＣカード手段１００６と相互認証を行うための相互認証手段１００５と、を備え、前記外部機器からコマンドを受信したときは、前記相互認証手段１００５は、前記認証コードを用いて前記ＩＣカード手段１００６と相互認証を行う。【選択図】図２
2007122379.tif 000002
【特許請求の範囲】
【請求項１】
外部機器の認証を行う認証手段と、
前記認証手段が用いる認証方法に対応する認証コードを保持する認証コード保持手段と、
該装置が有するメモリ領域を管理するＩＣカード手段と、
前記ＩＣカード手段と相互認証を行うための相互認証手段と、
を備え、
前記外部機器からコマンドを受信したとき、
前記相互認証手段は、前記認証コードを用いて前記ＩＣカード手段と相互認証を行う認証装置。
【請求項２】
前記外部機器から受信したコマンドに指定された認証方法に応じて、前記相互認証に用いる認証コードを決定する認証コード管理手段を備える請求項１記載の認証装置。
【請求項３】
前記認証コード管理手段が、前記相互認証に用いる認証コードの生成を行う請求項２記載の認証装置。
【請求項４】
前記外部機器からの開始通知を受信し、前記相互認証手段に通知後に、他の外部機器からの開始通知を排他制御する開始通知受信手段を備える請求項１記載の認証装置。
【請求項５】
前記開始通知受信手段は、外部機器からの開始通知を検証し、先に受信していた開始通知に指定された認証方法よりも優先順位が高い認証方法が指定されている場合、前記相互認証手段に通知し、
前記相互認証手段は、通知された開始通知に指定された認証方法に対応する認証コードを用いて前記ＩＣカード手段と相互認証を行う請求項４記載の認証装置。
【請求項６】
前記開始通知受信手段は、外部機器からの開始通知を検証し、先に受信していた開始通知に指定された認証方法よりもセキュリティが高い認証方法が指定されている場合、前記相互認証手段に通知し、
前記相互認証手段は、通知された開始通知に指定された認証方法に対応する認証コードを用いて前記ＩＣカード手段と相互認証を行う請求項４記載の認証装置。
【請求項７】
前記開始通知受信手段は、前記開始通知に指定された通信路を前記相互認証手段に通知し、
前記相互認証手段は、前記通信路毎に前記ＩＣカード手段と相互認証を行う請求項４記載の認証装置。
【請求項８】
前記相互認証手段は、前記認証コードを用いて新たな認証コードを生成し、生成した認証コードを用いて前記ＩＣカード手段と相互認証を行う請求項１記載の認証装置。
【請求項９】
前記ＩＣカード手段は、複数の論理領域に分割されたメモリ領域を管理し、
前記認証コード保持手段は、前記分割されたメモリ領域のそれぞれに対応する認証コードを保持する請求項１記載の認証装置。
【請求項１０】
前記外部機器から受信したデータを解釈し、前記ＩＣカード手段が解釈可能なデータ形式に変換して前記ＩＣカード手段に送信し、前記ＩＣカード手段での実行結果を受信し、前記外部機器が解釈可能なデータ形式に変換して前記外部機器に送信する制御を行う制御手段を備える請求項１記載の認証装置。
【請求項１１】
外部機器の認証機能を有する認証装置が、前記外部機器からアプリケーションをダウンロードして発行する方法であって、
前記外部機器と認証を行うステップと、
前記認証装置が保持する認証コードのうち、前記外部機器との認証方法に応じた認証コードを用いて、前記認証装置が有するメモリ領域を管理するＩＣカード手段との相互認証を行うステップと、
前記相互認証が成功した場合に、前記外部機器から受信したアプリケーションを発行するステップと、
を有するアプリケーション発行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部機器との間で相互認証を行う機能を有する認証装置及びこの認証装置におけるアプリケーション発行方法に関する。
【背景技術】
【０００２】
ＩＣカードは、磁気カードとは異なり、大容量の記憶領域と数値計算能力を持っているため、複数のアプリケーションを搭載可能なマルチアプリケーションカードや、発行後にアプリケーションを追加可能なダウンローダブルなカードが登場している。また、メモリカードのようなさらに大容量な記録領域をもつ媒体に、ＩＣチップを搭載したものや、カード上にＩＣチップ以外の制御コントローラを搭載した構成をもつカードも近年登場している。
【０００３】
このようなカードは、複雑な多数の認証方法を搭載することが可能であり、サービスごとに詳細な仕様は異なるが、公知技術である共通鍵認証方式や公開鍵による認証方法、ＰＩＮ（Personal Identification Number）認証に対応可能である。
【０００４】
認証は、カードにアプリケーションを搭載する際や、カードから機密情報を取得する際など、カードのセキュリティに関連した処理を実施する場合必要とされ、広域的なカードの運用、仕様を規定している標準化団体GlobalPlatformでは、カードの仕様として、セキュリティに関わる処理を実行する際に最低限のセキュリティとして、端末とカードによる相互的な認証を必須としている（例えば、非特許文献１参照）。
【０００５】
端末とカードが認証を行うには、端末、ＩＣカードの両方が予め定められた仕様に則って、情報を共有しておく必要がある。上記の仕様の１つとして、公知の技術である共通鍵認証方式の鍵を共有化しておき、お互いを認証している。
【０００６】
認証後、アプリケーションは、カードなどの認証装置の論理領域に格納される。図１に認証装置（１００）内の基本的な論理領域を示す。論理領域は認証装置（１００）内の記憶領域に構築されており、通常、ＲＯＭやＥＥＰＲＯＭなどの不揮発性メモリ上にある。論理領域の構成を決定する権限は、通常カードの発行者に与えられている。
【０００７】
認証装置の１例であるカードに関わる登場人物として、カード製造者、カード発行者、サービス提供者、発行されたカードを保有するカード保有者（ユーザ）がいる。
【０００８】
カード製造者は、安全な環境でカードの製造を行い、カード発行者との間で秘密情報を共有し、カード発行者がカード内に論理領域を構成し初期設定データを安全にカードに書き込む仕組みを構築する事業者である。
【０００９】
カード発行者は、論理領域の構成を行い、カードの識別情報やカード保有者情報などの基本的なデータやアプリケーションの発行処理、管理を行う事業者であり、カードとサービスを結び付ける準備をし、カードの発行責任を担うものである。
【００１０】
サービス提供者は、カード発行後のサービスを提供する事業者であり、カードへのアプリケーションの発行処理、管理を行うものである。カード発行者とサービス提供者は、従来の磁気カードや単一のアプリケーションのＩＣカードでは、同一者である場合が多かったが、マルチアプリケーションカードや、後からダウンロードすることが可能なカードである場合、カード発行者とは別に、複数のサービス提供者が存在する場合が多い。
【００１１】
サービス提供者は、アプリケーションの発行や削除、管理を行うためにカード発行者が保持する領域とは別に、サービス提供者領域（セキュリティドメイン）という特定の機能やデータを有するアプリケーションを作成する。
【００１２】
サービス提供者領域は、搭載するアプリケーションを管理する機能や領域内で共通して利用できる機能をアプリケーションに提供することが可能であり、カード発行者、サービス提供者どちらが提供しても構わない。
【００１３】
カード発行者がサービス提供者領域を発行する場合は、自らが設定した鍵を利用して前述した相互認証を行い、発行を行うことが可能であるが、サービス提供者が発行する場合は、カード発行者と事前に契約を結び、鍵を共有しておく必要がある。
【００１４】
図１のカード発行者領域（０００１）は、カード発行者が保持しているカード内で利用可能な論理領域を示している。領域は、カード発行者が作成、もしくは、カード製造時に作成する領域である。サービス提供者ＡとＢにはそれぞれサービス提供者Ａ領域（０００２）、サービス提供者Ｂ領域（０００３）を割り振る。
【００１５】
サービス提供者Ａ領域（０００２）上には、サービス提供者Ａが管理しているアプリケーションＡ（０００４）がある。サービス提供者Ｂ領域（０００３）には、同様にサービス提供者Ｂが管理するアプリケーションＢ（０００５）がある。アプリケーションＺ（０００６）はカード発行者が管理しており、通常カード全体の管理を行うアプリケーションであるカードマネージャが存在する。
【００１６】
サービス提供者がサービス提供者領域にアプリケーションを発行する際に必要な鍵は、領域を発行した後に領域に設定するため、他の事業者と共有しない限り、サービス提供者領域とその領域にアプリケーションを発行できるサービス提供者とは1対1の関係になる。
【非特許文献１】GlobalPlatform Card Specification 2.1.1 pp.106、表9-2 Minimum Security Requirements for GlobalPlatform Commands
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明が解決しようとする課題は２つあり、１つは、アプリケーション発行時の課題であり、もう１つは、アプリケーションを実行する環境の課題である。
【００１８】
以下、１つ目の課題について詳細を記載する。上記のカードのアプリケーション発行方式において、サービス提供者がカードにアプリケーションを発行する際、鍵を必要とする。しかし、カードが複数の認証方式に対応し、別の認証方法においてカード発行者とサービス提供者間ですでに契約が行われていても、アプリケーション発行のために新たに契約を結び、鍵を共有する必要がある。
【００１９】
カードに搭載するアプリケーションが求めるセキュリティレベルは、千差万別であるのに対して、カードにアプリケーションを発行する方法が一律に決まっているため、他の認証方法で確立したセキュリティを、アプリケーション発行時に求められるセキュリティと同等と判断することができず、アプリケーション発行を行うための認証方式を再度サービス提供者に求めることになり、サービス提供者が提供するホスト側にも仕組みを設置することを強いることになる。
【００２０】
ここでいう仕組みとは鍵情報や認証アルゴリズム等のソフトウェア上の対応、暗号処理を行うコプロセッサ等のハードウェア構成を含んでいる。そのため、ポイントカードアプリケーションや試用アプリケーションといったアプリケーション発行時に高度なセキュリティを必要としない場合でも、契約の必要や端末側の対応が求められるなど、事前準備のコストに対して、守るべきアプリケーションの価値が低い。
【００２１】
１つ目の課題として、セキュリティを求めないアプリケーションでも、発行の仕組みが一律で簡単に発行することができないことが挙げられる。
【００２２】
また、アプリケーションの価値に応じて、発行での認証方法を複数用意した場合、現在のアプリケーションを実行する環境であるサービス提供者領域では、1事業者に１サービス提供者領域を割り当てているため、認証方法が異なるアプリケーションが領域内に混在してしまう。
【００２３】
その場合、認証方法のセキュリティレベルによってアプリケーションが使える管理機能や共通機能を制限する必要があったり、一番低いセキュリティレベルに合わせた運用になってしまうことがある。
【００２４】
ここで言う管理機能とは、具体的にはアプリケーションを発行、削除する時の条件を設定し、アプリケーションのライフサイクルを変更できる機能であり、共通機能とは例えば、特定の著作権保護で用いるパディング処理を各々が用意しないで共通に使えるパディング用のライブラリを用意したり、内部に独自のキーワードを埋め込んで、簡単に独自の署名を生成することができるように機能を追加することを指す。またＰＩＮ照合やデータ設定用のコマンドなど、アプリケーション共通に用いられる機能も含まれる。
【００２５】
発行するアプリケーション毎に個別にサービス提供者領域を分けて、アプリケーションを配置した場合、複数の事業者が個々にサービス提供者領域を複数持つことになってしまい、リソースの少ないカードにとって、管理機能や共通機能をもつ領域だけで、リソースが制限されてしまう。
【００２６】
以下、2つ目の課題を詳細に記載する。従来のアプリケーション管理方法では、同一領域内にセキュリティレベルの異なるアプリケーションが混在できない。
【００２７】
また、サービス提供者領域が複数に増えた場合、鍵管理の煩雑さが増す事になる。特に共通鍵で互いの認証を行う場合に、カードごとに共通鍵を変えると、最悪の場合（カード発行枚数）と（提供するサービス数）の積になり、莫大な鍵の管理と鍵取得時に契約の手間が発生する。
【００２８】
このような課題に対して、従来の技術として、特開２００２−５６３６０号公報に記載されているものが知られている。これは、カード発行者とサービス提供者との間に第三者を配置し、鍵管理における契約を第三者がカード発行者に成り代わって行い、サービス提供者は、直接カード発行者と通信しなくても、アプリケーションの発行ができるというものである。
【００２９】
しかし、この方法は、代理人経由にすることで個別の対応が不要になるが、アプリケーション発行時の根本的な鍵管理の煩雑さを解決しておらず、カード発行者は代理人に全契約を任せる不安がある。
【００３０】
本発明は、上記従来の事情に鑑みてなされたものであって、新たな認証方法を用いることなく、端末等の外部機器と認証装置との間で必要とされる相互認証を容易に行うことができる認証装置及びアプリケーション発行方法を提供することを目的としている。
【００３１】
また、本発明は、従来の認証装置の仕様を変更せずに、従来のアプリケーション発行方法と共存できる仕組みを構築することを目的としている。
【課題を解決するための手段】
【００３２】
本発明の認証装置は、外部機器の認証を行う認証手段と、前記認証手段が用いる認証方法に対応する認証コードを保持する認証コード保持手段と、該装置が有するメモリ領域を管理するＩＣカード手段と、前記ＩＣカード手段と相互認証を行うための相互認証手段と、を備え、前記外部機器からコマンドを受信したとき、前記相互認証手段が、前記認証コードを用いて前記ＩＣカード手段と相互認証を行うものである。
【００３３】
上記構成によれば、外部機器からコマンドを受信したときに、相互認証手段が、認証手段が用いた認証方法に対応する認証コードを用いてＩＣカード手段と相互認証を行うことにより、外部機器と認証装置との間で必要とされる相互認証を認証装置内で行い、外部機器に対しては相互認証済みのように振舞うことができるため、新たな認証方法を用いることなく容易に外部機器との相互認証を行うことができる。例えば、認証装置がＩＣカードであり、外部機器から、コマンドとしてアプリケーションを受信した場合、サービス提供者がカード発行者と新たに契約を結ばなくても、すでに契約済みの認証方法を使って、外部機器とＩＣカードとの間で必要とされる相互認証を行うことができるため、容易にアプリケーションを発行することができる。また、従来の認証装置の仕様を変更せずに、従来のアプリケーション発行方法と共存できる仕組みを構築することができる。
【００３４】
また、本発明の認証装置は、前記外部機器から受信したコマンドに指定された認証方法に応じて、前記相互認証に用いる認証コードを決定する認証コード管理手段を備える。
【００３５】
上記構成によれば、認証方法ごとに認証コードを変更することができる。また、例えば前記外部機器と複数の認証方法を共有している時に、コマンドとして外部機器からアプリケーションを受信した場合、アプリケーションに定められた認証方法に対応する認証コードを用いて相互認証を行うことにより、アプリケーションの価値に応じて発行時の認証方法を多様化させることができる。
【００３６】
また、本発明の認証装置は、前記認証コード管理手段が、前記相互認証に用いる認証コードの生成を行うものである。
【００３７】
上記構成によれば、外部で作成した認証コードを内部に埋め込む方法とは異なり、外部に認証コードが漏れることがないので、安全である。
【００３８】
また、本発明の認証装置は、前記外部機器からの開始通知を受信し、前記相互認証手段に通知後に、他の外部機器からの開始通知を排他制御する開始通知受信手段を備える。
【００３９】
上記構成によれば、他の機器からの情報を受けることなく、ＩＣ手段が管理するメモリ領域と確実に相互認証することができる。
【００４０】
また、本発明の認証装置は、前記開始通知受信手段が、外部機器からの開始通知を検証し、先に受信していた開始通知に指定された認証方法よりも優先順位が高い認証方法が指定されている場合、前記相互認証手段に通知し、前記相互認証手段が、通知された開始通知に指定された認証方法に対応する認証コードを用いて前記ＩＣカード手段と相互認証を行うものである。
【００４１】
上記構成によれば、優先順位に応じて、より好ましい認証コードを用いて相互認証することができる。
【００４２】
また、本発明の認証装置は、前記開始通知受信手段が、外部機器からの開始通知を検証し、先に受信していた開始通知に指定された認証方法よりもセキュリティが高い認証方法が指定されている場合、前記相互認証手段に通知し、前記相互認証手段が、通知された開始通知に指定された認証方法に対応する認証コードを用いて前記ＩＣカード手段と相互認証を行うものである。
【００４３】
上記構成によれば、セキュリティがより高い認証方法に対応する認証コードを用いて相互認証することができる。
【００４４】
また、本発明の認証装置は、前記開始通知受信手段が、前記開始通知に指定された通信路を前記相互認証手段に通知し、前記相互認証手段が、前記通信路毎に前記ＩＣカード手段と相互認証を行うものである。
【００４５】
上記構成によれば、マルチチャネルに対応できる。
【００４６】
また、本発明の認証装置は、前記相互認証手段が、前記認証コードを用いて新たな認証コードを生成し、生成した認証コードを用いて前記ＩＣカード手段と相互認証を行うものである。
【００４７】
上記構成によれば、外部機器がＩＣカード手段と相互認証を行う際に必要な認証コードを持たずに、内部で相互認証を行うことができるため、鍵管理の手間を省く事ができる。
【００４８】
また、本発明の認証装置は、前記ＩＣカード手段が、複数の論理領域に分割されたメモリ領域を管理し、前記認証コード保持手段が、前記分割されたメモリ領域のそれぞれに対応する認証コードを保持するものである。
【００４９】
上記構成によれば、認証方法毎にアクセス可能なメモリ領域を限定することができる為、認証装置全体のセキュリティを維持することができる。
【００５０】
また、本発明の認証装置は、前記外部機器から受信したデータを解釈し、前記ＩＣカード手段が解釈可能なデータ形式に変換して前記ＩＣカード手段に送信し、前記ＩＣカード手段での実行結果を受信し、前記外部機器が解釈可能なデータ形式に変換して前記外部機器に送信する制御を行う制御手段を備える。
【００５１】
上記構成によれば、外部機器とＩＣカード手段が直接データのやり取りを行うことができる。
【発明の効果】
【００５２】
本発明によれば、外部機器からコマンドを受信したときに、相互認証手段が、認証手段が用いた認証方法に対応する認証コードを用いてＩＣカード手段と相互認証を行うことにより、外部機器と認証装置との間で必要とされる相互認証を認証装置内で行い、外部機器に対しては相互認証済みのように振舞うことができるため、新たな認証方法を用いることなく容易に外部機器との相互認証を行うことができる。
【発明を実施するための最良の形態】
【００５３】
図２は本発明の実施の形態を説明するための認証装置の構成を示す図であり、図３は本発明の実施の形態を説明するための外部機器の構成を示す図である。以下、外部機器（２００）と認証装置（１００）との間でアプリケーションの発行を行う例を説明する。
【００５４】
はじめに、本発明の実施の形態における認証装置の内部構成について説明する。認証装置（１００）は、ＩＣカード機能を持つ携帯可能な端末であり、図２に示すように、主に、認証手段（１００１）、制御手段（１００２）、認証コード保持管理手段（１００３）、開始通知受信手段（１００４）、相互認証手段（１００５）、ＩＣカード手段（１００６）で構成される。
【００５５】
認証手段（１００１）は、外部機器（２００）との認証を行う手段であり、認証方法は公知の技術である共通鍵認証方式や公開鍵認証方式、ＰＩＮ認証、ＤＴＣＰ（Digital Transmission Content Protection）で使われるＡＫＥ (Authentication and Key Exchange)などを含む。
【００５６】
外部機器（２００）との認証に成功した場合は、認証手段（１００１）は、開始通知受信手段（１００４）に認証方法の種別を含む結果を送信する。また、失敗した場合も同様に、認証方法の種別を含む結果を開始通知受信手段（１００４）に送信する。認証方法は、後述する外部機器側が同じ認証方法に対応していることが前提となる。
【００５７】
制御手段（１００２）は、外部機器との通信を行うためのインタフェースを持ち、外部機器からの指示を解釈し、認証手段（１００１）、開始通知受信手段（１００４）、ＩＣカード手段（１００６）にデータの送信を行うための手段である。外部インタフェースとしては、シリアルバス転送、パラレルバス転送、ＵＳＢ、赤外線、無線等の通信規格やそれを実現するための機器を含み、ここでは、後述する外部機器（２００）の通信手段（２００４）との間でデータの送受信を行う。
【００５８】
認証コード保持管理手段（１００３）は、ＩＣカード手段（１００６）と相互認証を行うための認証コードを保持する手段であり、相互認証手段（１００５）から受信したデータの解釈結果によって、相互認証手段（１００５）に送信する認証コードを決定する。また、認証コード保持管理手段（１００３）とＩＣカード手段（１００６）に認証コードを設定する方法については、後述する。
【００５９】
開始通知受信手段（１００４）は、制御手段（１００２）からデータを受信し、相互認証手段（１００５）に開始を通知する。開始通知受信手段（１００４）は、通知後に他からの開始通知を排他制御する。
【００６０】
排他制御は、完全に他からの開始通知を受け付けないという場合以外にも、開始通知を行う前に行われた認証方法が、すでに開始を受け付けている認証方法よりも高度なセキュリティを保証するものであったり、予め優先付けがされている認証方法であれば、変更可能である。
【００６１】
また、通信チャネルを利用して、用意しているチャネル数の範囲内であれば、通信チャネルを割り振って、相互認証手段（１００５）に通知を行い、相互認証手段（１００５）が指定されたチャネルでＩＣカード手段（１００６）と相互認証を行うことも可能である。
【００６２】
この際、割り振り可能なチャネル数を超えた場合は、他からの通知を受け付けなくなる。高度なセキュリティというのは、例えば、同じ認証アルゴリズムでも鍵長が長い場合や一般的な暗号強度から推し量る事ができる場合に、より高度であるという認識を行う。
【００６３】
相互認証手段（１００５）は、認証コード保持管理手段（１００３）から認証コードを受信し、開始通知受信手段（１００４）から開始通知を受信した場合、ＩＣカード手段（１００６）と相互認証を開始する。相互認証手段（１００５）は、相互認証の結果を、制御手段（１００２）に送信する。
【００６４】
ＩＣカード手段（１００６）は、従来のＩＣ機能を総合して称した手段であり、詳細に記載すると、図４の構成になる。演算手段（３００１）は、数値演算、コマンド実行、レスポンス生成を行う手段であり、通信手段（３００４）から情報を受信し、暗号処理手段（３００２）、記憶手段（３００３）とデータの送受信を行う。ＣＰＵ等がそれに当たる。
【００６５】
暗号処理手段は、演算手段（３００１）から暗号処理だけを抜き出して、高速に処理を行うための手段であり、Co-Processor等がそれに当たる。記憶手段（３００３）は、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＦｅＲＡＭ、ＦＬＡＳＨ等の一時的メモリを含む記憶装置で構成され、各種のデータを格納する。
【００６６】
通信手段（３００４）は、外部インタフェースであり、外部機器（２００）と通信を行う手段であり、接触、非接触等の通信規格に対応したものである。また、前述したように複数の通信チャネルを形成することが可能である。
【００６７】
次に、本発明の実施の形態における外部機器（２００）の内部構成について説明する。外部機器（２００）は、カード（１００）と認証を行い、アプリケーションを発行するための機器であり、図３に示すように、主に、演算手段（２００１）、認証手段（２００２）、記憶手段（２００３）、通信手段（２００４）で構成される。
【００６８】
演算手段（２００１）は、数値演算、コマンド生成、レスポンス解釈を行う手段であり、通信手段（２００４）から情報を受信し、認証手段（２００２）、記憶手段（２００３）とデータの送受信を行う。ＣＰＵ等がそれに当たる。
【００６９】
認証手段（２００２）は、認証装置（１００）との認証を行う手段であり、認証方法は前述の公知の技術を含む。この認証方法は、予め認証装置（１００）と同じ認証方法に対応していることが前提となる。
【００７０】
記憶手段（２００３）は、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＦｅＲＡＭ、ＦＬＡＳＨ、ＨＤＤ等の一時的メモリを含む記憶装置で構成され、各種のデータを格納する。
【００７１】
通信手段（２００４）は、外部インタフェースであり、シリアルバス転送、パラレルバス転送、ＵＳＢ、赤外線、無線等の通信規格やそれを実現するための機器を含み、ここでは、認証装置（１００）の制御手段（１００２）との間でデータの送受信を行う。認証装置（１００）とは複数の通信チャネルを形成することが可能である。
【００７２】
次に、上記構成の認証装置（１００）及び外部機器（２００）の間で行われる認証方法を説明する。認証の流れを図５に示す。
【００７３】
認証装置（１００）と外部機器（２００）は予め共有した認証アルゴリズム、認証用データおよび認証手段を使って、認証を行う。この際行う認証は、公知の技術であり、詳細については言及しないが、具体的な例として、公開鍵認証方式での相互認証を示す。
【００７４】
外部機器（２００）は、認証装置（１００）に乱数を生成するように命令を送信する。認証装置（１００）は、受信した命令を解釈し、乱数を外部機器（２００）に送信する。外部機器（２００）は、受信した乱数を認証装置（１００）のＩＣカード手段（１００６）の記憶手段（３００３）が保持する公開鍵と対称となる秘密鍵を使って、暗号化し、認証装置（１００）に暗号文を送信する。
【００７５】
認証装置（１００）は、受信した暗号文を保持する秘密鍵と対称となる公開鍵で復号を行い、認証装置（１００）が送信した乱数と同じものが復号できた場合、外部機器（２００）を認証する。
【００７６】
外部機器（２００）は、認証装置（１００）に平文（暗号化されていないデータ、クリアテキスト（clear text））を送信し、認証装置（１００）が保持する秘密鍵で受信した平文を暗号化し、外部機器（２００）に送信する。外部機器（２００）は受信した暗号文を、認証装置（１００）が公開している公開鍵を使って復号化し、外部機器（２００）が最初に送信した平文と同じになった場合、認証装置（１００）を認証する。この２つの処理がともに成功した場合、相互認証が成立したことになる（Ｓ００１）。なお共通鍵暗号の場合は、共有した鍵で暗復号を行う事になる。
【００７７】
ここで成立した相互認証は公開鍵認証方式における相互認証である。一方、認証装置（１００）にアプリケーションを発行する場合に求められる認証方式は共通鍵認証方式である。したがって、（Ｓ００１）で公開鍵認証方式の認証方式に成功しただけではアプリケーションの発行に結びつけることができない。そのため本実施形態では、これ以降で共通鍵認証方式における相互認証の処理を継続する。
【００７８】
（Ｓ００１）で相互認証成立後、認証装置（１００）の認証手段（１００１）は、公開鍵認証方式での相互認証が成立したことを、開始通知受信手段（１００４）に通知する（Ｓ００２）。開始通知受信手段（１００４）では、図６に示すように、各認証方法ごとに、ＩＣカード手段（１００６）と認証を行うための認証コードを登録しており、公開鍵認証方式での相互認証に成功した場合、第1行目が選択されることになる。
【００７９】
各列の説明を行うと、1列目は、認証手段（１００１）から相互認証手段（１００５）経由で認証コード保持管理手段（１００３）に通知された認証方法の種別によって選択される主キーとなる項目であり、２列目は、認証を行う対象となるサービス提供者領域を指定するための識別番号であり、３列目は、認証時に使用する認証コード情報となっている。
【００８０】
尚、前記の列に、有効期間等の時間の概念や、条件を入れ子にして複雑なアクセス条件を作成することは、本発明から容易に類推できる範囲である。認証コードには、ＰＩＮのようにそのまま比較の対象となるデータの他に、鍵のように対象を共有することで互いに比較の対象となるデータを生成できるデータを含む。
【００８１】
外部機器（２００）は、認証装置（１００）の制御手段（１００２）にＩＣカード手段（１００６）で処理可能なデータを送信する（Ｓ００３）。ＩＣカード手段で処理可能なデータのフォーマットとしては、ヘッダ部、データ部から成り立つ数値列であり、例としては、ＩＳＯ７８１６−４で規定されているＡＰＤＵ（Application Data Unit Protocol）やＩＣカードシステム利用促進協議会（ＪＩＣＳＡＰ）が日本鉄道サイバネティクス協議会との合意に基き開発したＪＩＣＳＡＰ２．０高速コマンド仕様で規定されている高速処理コマンド、ＳＩＭ（Subscriber Identify module）Cardコマンド等がそれに当たる。
【００８２】
制御手段に送信するコマンドとしては、具体的にはＳＤ Memory Card（Secure Digital Memory Card）コマンドやＭＭＣ Card（Multi Media Card）コマンドを用いて、上記で例示したＩＣカード手段で処理可能なコマンドを包含した形で送信する。制御手段（１００２）は受信したデータを解釈し、ＩＣカード手段（１００６）にデータを送信する（Ｓ００４）。
【００８３】
ＩＣカード手段（１００６）の通信手段（３００４）は、データを受信し、演算手段（３００１）に送信する。演算手段（３００１）は、受信したデータを解釈し、暗号処理手段（３００２）、記憶手段（３００３）を適宜利用し、データを実行する。演算手段（３００１）は実行後の結果を通信手段（３００４）を介して、制御手段（１００２）に送信する（Ｓ００５）。制御手段（１００２）は、受信した実行結果を外部機器（２００）が送信してきた形式に変換して、外部機器（２００）に送信する（Ｓ００６）。
【００８４】
相互認証を行わずにＩＣカード手段（１００６）にデータ処理をさせることはカードのセキュリティによっては可能であるが、アプリケーションの発行処理を行わせる際には、事前に相互認証が必要となる場合が多い。
【００８５】
アプリケーションの発行処理とは、アプリケーションというカード内で実行可能な一連の処理を、カードが予め規定しているフォーマットに則って、分割あるいはパックしてカードに送信し、カード内での検証を経て、カード内で動作可能な処理にすることをいう。
【００８６】
相互認証が成功していない状態でＩＣカード手段（１００６）にデータを送信した場合、データをカードにロードすることは許可されず、エラーを示す実行結果が戻ってくる。
【００８７】
また、前記のＳ００３〜Ｓ００６を利用して、外部機器（２００）とＩＣカード手段（１００６）の間でカード仕様に則って、相互認証を行う事が可能であるが、サービス提供者が外部機器（２００）を提供する場合、ＩＣカード手段（１００６）の論理領域内にサービス提供者領域を事前に構築し、鍵を共有しておく必要がある。
【００８８】
本発明では、サービス提供者が事前にカード発行者との鍵の共有をせずに、すでに契約済みの他の認証方法を利用して、外部機器（２００）とカード（１００）間の相互認証を実施する方法を示す。
【００８９】
外部機器（２００）は、制御手段（１００２）に、開始通知受信手段（１００４）が受信するためのデータを送信する（Ｓ００７）。制御手段（１００２）は、受信したデータを解釈し、開始通知受信手段（１００４）にデータを送信する（Ｓ００８）。
【００９０】
開始通知受信手段（１００４）は、受信したデータが開始通知であることを確認し、相互認証手段（１００５）に通知する（Ｓ００９）。開始通知には、開始を要求する命令以外に認証方法の種別を含んでいる。開始通知受信手段（１００４）は、再度開始通知が来ても実行しないように排他制御を開始する。
【００９１】
相互認証手段（１００５）は、開始通知受信手段（１００４）の開始通知を受信し、認証コード保持管理手段（１００３）にデータを要求する（Ｓ０１０）。認証コード保持管理手段（１００３）は、相互認証手段（１００５）からの開始通知に含まれている認証方法の種別に基づいて、認証コード保持管理手段（１００３）が保持する図６に示す認証コード管理テーブルを検索して、該当する認証方法を選択し、相互認証手段（１００５）がコマンド作成に必要とするデータを相互認証手段（１００５）に送信する（Ｓ０１１）。
【００９２】
コマンド作成に必要なデータとは、具体的には認証用の鍵データやＰＩＮデータであり、図６にて示すデータである。それ以外のデータとして、鍵の識別番号や鍵のバージョン情報を含んでも良い。
【００９３】
相互認証手段（１００５）は、認証コード保持管理手段（１００３）から受信したデータを使用して、ＩＣカード手段（１００６）で実行可能なコマンドを生成する。相互認証手段（１００５）は、作成したコマンドをＩＣカード手段（１００６）に送信する（Ｓ０１２）。
【００９４】
ＩＣカード手段（１００６）は、受信したコマンドを演算手段（３００１）で実行する。コマンドを実行した結果、ＩＣカード手段（１００６）では、（Ｓ００３〜Ｓ００６）を利用して相互認証を行った場合と同じ状態をカード内部にもつことになる。
【００９５】
ＩＣカード手段（１００６）の通信手段（３００４）は、実行した結果を相互認証手段（１００５）に送信する（Ｓ０１３）。相互認証手段（１００５）は、受信した実行結果を解釈し、開始通知受信手段（１００４）に処理が終了したことを通知する（Ｓ０１４）。
【００９６】
開始通知受信手段（１００４）は、受信した通知から排他制御を停止する。また、相互認証手段（１００５）は、制御手段（１００２）に実行結果を通知する（Ｓ０１５）。制御手段（１００２）は、受信した実行結果を外部機器（２００）が送信してきた形式に変換して、外部機器（２００）に送信する（Ｓ０１６）。
【００９７】
このように、（Ｓ００１）の相互認証（公開鍵認証方式）は、外部機器（２００）と認証装置（１００）が行っている認証であり、（Ｓ０１２）の相互認証（共通鍵認証方式）は、（Ｓ００１）の相互認証の有効性を加味してＩＣカード手段（１００６）に対して、カードアプリケーションの発行に求められている認証を擬似的に成功させるための認証装置（１００）内の相互認証である。
【００９８】
すなわち、ＩＣカード手段（１００６）が適切な認証を行ったものにするため、再度ＩＣカード手段（１００６）と相互認証手段（１００５）がアプリケーション発行に準ずる認証方法で「互いの機器」を認証する。したがって、（Ｓ０１６）以降にアプリケーションの発行処理が可能になる。
【００９９】
その後、（Ｓ００３〜Ｓ００６）を使ってＩＣカード手段（１００６）にデータを送信した場合、カード内部の状態が相互認証済みになっているため、新たに相互認証を行わなくてもアプリケーションの発行処理を実行することが可能になる。
【０１００】
外部機器（２００）から見た場合、前提条件として、すでに他の認証方法で認証装置（１００）に認証される必要はあるが、認証装置（１００）が認証済みになっているかどうかを知る必要はない。
【０１０１】
例えば、外部機器（２００）は認証装置（１００）の著作権保護機能が持つ相互認証手段（具体的にはＡＫＥ）で相互認証に成功する。外部機器（２００）は、自身が認証に成功したという状態を知れば、アプリケーション発行処理で送信するデータを、認証装置（１００）内のＩＣカード手段（１００６）との相互認証無しで送信しても、ＩＣカード手段（１００６）と相互認証手段（１００５）間で自動的に相互認証がなされ、アプリケーションの発行が可能であることを事前に知っている。
【０１０２】
失敗した場合は、何かしらの理由で、認証装置（１００）側の相互認証結果が消去されたということが分かる。失敗した具体的な理由は、制御手段（１００２）からのレスポンスデータに記載されているので、外部機器（２００）はそこから類推することができる。
【０１０３】
また認証機器（１００）が、本発明の仕組みに対応しているか不明な場合には、外部装置（２００）が認証装置（１００）の状態を取得することが可能である。
【０１０４】
上記の著作権保護機能での認証の場合、外部機器（２００）は、認証装置（１００）の状態が認証済みになっている事を認証装置用のコマンドを使う事で確認することができる。
【０１０５】
具体的には、認証装置がＳＤ Memory Cardの場合、カード状態を読み出すＳＤ Memory Cardコマンドを制御手段（１００２）に送信することで実現可能である。ＩＣカード手段（１００６）が状態を持つ場合でも、状態を読み出すＡＰＤＵコマンドを送信することで対応可能である。
【０１０６】
図７にＳ００１〜Ｓ０１６までの流れの概念図を示し、シーケンス図５との対応を示す。
【０１０７】
認証（Ｓ００１）に対応するのが、図中のＰＫＩ認証（Ｆ００１）であり、外部機器（２００）と認証手段（１００１）間での認証の例としてＰＫＩ認証を例に挙げている。認証情報通知（Ｓ００２）に対応するのが、図中の（Ｆ００２）であり、認証手段（１００１）が、開始通知受信手段（１００４）に通知する。
【０１０８】
認証情報通知は、相互認証手段（１００５）を経由して、認証コード保持管理手段に渡される（Ｆ００６、Ｆ００７）。認証コード保持管理手段は、受信した認証情報通知により、認証コード保持管理手段が保有する認証コード管理テーブルにどの認証方法が成功したのかを指し示す。
【０１０９】
コマンド送信／レスポンス受信（Ｆ００３）に対応するのが、外部機器（２００）と制御手段（１００２）で送受信を行う（Ｓ００３、Ｓ００６、Ｓ００７、Ｓ０１６）である。制御手段（１００２）とＩＣカード手段（１００６）間ではＩＣカード手段が解釈できるように変換したコマンドを送信し、レスポンスを受信する（Ｆ００４）。
【０１１０】
（Ｆ００４）に対応するのが、（Ｓ００４、Ｓ００５）である。制御手段（１００２）と開始通知受信手段（１００４）間では制御手段（１００２）が受信した開始通知を開始通知受信手段（１００４）に送信する（Ｆ００５）。開始通知には、認証方法の種別が含まれている。
【０１１１】
（Ｆ００５）に対応するのが、（Ｓ００８）である。開始通知受信手段（１００４）と相互認証手段（１００５）間では、開始通知の送信、終了通知の受信を行う（Ｆ００６）。
【０１１２】
（Ｆ００６）に対応するのが、（Ｓ００９、Ｓ０１４）である。相互認証手段（１００５）と認証コード保持管理手段（１００３）間では、認証方法の種別から認証コードの要求とデータの送信を行う（Ｆ００７）。
【０１１３】
（Ｆ００７）に対応するのが、（Ｓ０１０、Ｓ０１１）である。相互認証手段（１００５）とＩＣカード手段（１００６）間では、相互認証を行うためのコマンドを送信し、レスポンスを受信する（Ｆ００８）。
【０１１４】
（Ｆ００８）に対応するのが、（Ｓ０１２、Ｓ０１３）である。例として、ＩＣカード手段（１００６）の論理領域には、前述のＰＫＩ認証に成功した際に使用する認証用鍵情報に対応する鍵を持つサービス提供者領域（５００１）があり、（Ｆ００８）では、認証コード保持管理手段（１００３）が持つ鍵情報を相互認証手段（１００５）が使用して、サービス提供者領域（５００１）が持つ鍵に対して相互認証を行っている（Ｆ００９）。
【０１１５】
相互認証が成功した後は、外部機器（２００）は（Ｆ００３、Ｆ００４）の経路を使って、コマンドを送信し、ＩＣカード手段（１００６）の論理領域上にあるサービス提供者領域（５００１）に対してアプリケーション（５００４）を発行する。
【０１１６】
本方法でアプリケーションの発行を行った場合、認証方法とそれに対応する鍵を認証コード保持管理手段（１００３）が管理することにより、アプリケーションを発行する領域を決めることができる。
【０１１７】
具体的には、図６で示すように、公開鍵認証方式に対応した外部機器（２００）であれば、公開鍵認証方式による相互認証成功後にＩＣカード手段にアプリケーション発行処理を行うと、認証装置（１００）内部で、認証コード保持管理手段が保持する認証コード管理テーブルの1行目2列目のサービス提供者領域に対して、1行目3列目の鍵情報を用いて相互認証を行い、外部機器は実際にＩＣカード手段（１００６）と相互認証せずに、前記領域に対してアプリケーションを発行することができる。
【０１１８】
アプリケーション発行処理の前に外部機器（２００）が認証装置（１００）と、どの認証方式で認証を成功したかによって、認証装置（１００）内での状態が変化する。他の認証方式としては、ＤＴＣＰ方式、共通鍵認証方式、ＰＩＮ認証を挙げているが、公知の技術として使われている認証方式は類推の範囲である。
【０１１９】
認証装置（１００）が持つ状態によって、アプリケーションの発行領域を変えることで、混在した認証方法でアプリケーションが領域内に発行されることがなく、領域内の管理機能、共通機能を一定の基準に合わせて運用を行うことができる。
【０１２０】
そのため、ＰＩＮ認証だけでアプリケーションを発行することが可能で、かつＰＩＮ認証だけで発行したアプリケーションを一括で管理できる利点があり、従来、鍵を事前に契約して保持していなくては発行できなかったアプリケーションを、既存の認証方法に対応させ、一定レベルのセキュリティを保持した状態で、アプリケーション発行での認証方法を多様化させることができる。
【０１２１】
ここでいう一定レベルのセキュリティというのは、各アプリケーションがその価値に応じた領域に発行されることで、行き過ぎたセキュリティ機能や不相応な管理をせずに済む状態を指している。
【０１２２】
具体的な事例として、サービス提供者領域ごとに管理機能、共通機能の割り当てを行うことにより、目的別のサービス提供者領域を構築する例を図８を用いて説明する。
【０１２３】
サービス提供者領域（４００１）は、共通機能として、提供機能１（４００３）と提供機能２（４００２）を持っている。提供機能１（４００３）は、サービス提供者領域（４００１）上に提供されたアプリケーション（４００４）にどの機能を提供するかを規定している。
【０１２４】
また、その領域に対してアプリケーションの発行、削除といったライフサイクルを管理する機能（４００６）が規定できる。図８の表では、サービス提供者領域をどの認証方式に対応させるかによって、提供機能１（４００３）や提供機能２（４００２）、ライフサイクル管理（４００６）を変えることができることを示している。
【０１２５】
本例では、著作権用領域がポイントカード用領域や試験発行用領域よりも認証に成功するのが困難であり、ポイントカード用領域が試験発行用領域よりも認証に成功するのが困難であると想定し、行う事が可能な処理を段階的に制限している。
【０１２６】
例えば、提供機能１（４００３）の具体例として、著作権保護で使われているＤＴＣＰを使った認証を外部機器（２００）、認証装置（１００）間で行うことが出来た場合、カード内の論理領域に著作権用領域として作成されたサービス提供者領域にアプリケーション（４００４）を発行することができる。そして、著作権用領域で暗号機能が実行可能である場合、アプリケーション（４００４）は認証装置（１００）が搭載している暗号機能を使うことができる。
【０１２７】
それに対して、試験的にアプリケーションを発行するためにＰＩＮ認証の成功でアプリケーションの発行ができる試験発行用領域を準備し、その領域は暗号機能を実行不可とした場合、ＰＩＮ認証に成功しても、前記領域に搭載されたアプリケーションは、暗号機能を使用することができない。
【０１２８】
機能の異なるサービス提供者領域に対して、認証方法に紐付いた領域の選択を行うことによって、異なる動作環境をアプリケーションに提供することができる。認証方法によって自動的に発行する領域が決められるので、領域内に異なる認証方法で発行されたアプリケーションが混在することがない。
【０１２９】
提供機能２（４００２）は、認証装置（１００）に記憶手段（４００５）が搭載されており、前記手段に対して、発行したアプリケーションからの書き込み、読み出しを許可しているかを規定している。
【０１３０】
前述の場合と同様で、ＤＴＣＰでの認証に成功して発行したアプリケーションは、アプリケーションからの書き込み、読み出しが可能である。それに対して試験発行用領域に発行したアプリケーションは、記憶手段（４００５）へのアクセスが禁止になる。
【０１３１】
ライフサイクル管理（４００６）でも、著作権用領域と試験発行用領域では条件が異なり、アプリケーション（４００４）の削除を行う場合、発行と同じ認証方法に成功後、実施することができる。
【０１３２】
通常のカード仕様に準拠した認証方法をカードにおける最高のセキュリティレベルとすることで、それ以外の認証方法にランクを付けることが可能になる。ここで規定するランクとは、具体的なセキュリティレベルを計算式で算出し比較することではなく、アプリケーションを発行する領域に割り当てる権限や機能面から考慮し、カード発行者やユーザが任意に設定する値である。
【０１３３】
前述の図６で示した例を挙げると、公開鍵認証やＤＴＣＰ方式では使われる暗号方式が公開鍵暗号方式であることから、同ランクと見ることができ、共通鍵認証方式では使われる暗号方式が秘密鍵暗号方式であることから、前述の２つの認証方式よりかはランクが低いと考えることができる。
【０１３４】
またＰＩＮ認証では、鍵を用いた暗号方式が採用されていなく、パスワード（パスフレーズ）の比較のみため、よりランクが低いと決定することができる。よって、４つの認証方法を比較した場合、以下のような等式が成り立つ。
【０１３５】
公開鍵認証＝ＤＴＣＰ方式＞共通鍵認証＞ＰＩＮ認証
【０１３６】
本等式は1例であり、公開鍵認証時に使われる鍵長とＤＴＣＰ認証時に使われる鍵長が異なる場合は、等号ではないと判断できる。また、認証方式によって与える権限が変化する場合、ランクを設定する者の意向が入るため、一律に設定することは出来ない。
【０１３７】
認証方式のランクを用いる場面は、開始通知受信手段（１００４）が排他制御を行っている時に有効である。本例では、ランク情報を開始通知受信手段が保持し、図９にランクを用いた排他制御の振る舞いを示す。
【０１３８】
外部機器（２００）は前提条件として、認証装置（１００）と認証方式Ａ、認証方式Ｂという２つの認証に成功している（Ｓ００１−１）。外部機器（２００）は、制御手段（１００２）に対して、認証方式Ａを使うことを開始通知受信手段に通知する（Ｓ００７−１）。
【０１３９】
通知に使用するフォーマットを図１６に例示する。本フォーマットは１つの表現形態であり、これに限定されるものではない。
【０１４０】
受信した制御手段（１００２）は、コマンドを解釈し、開始通知受信手段（１００４）に送信する（Ｓ００８−１）。開始通知受信手段（１００４）は、相互認証手段（１００５）に認証方式Ａを用いた相互認証を行うように指示を出す（Ｓ００９−１）。
【０１４１】
開始通知受信手段（１００４）は、排他制御を開始する。通常の処理であれば、このまま認証方式Ａに対応した鍵で相互認証が実行される。本例では図９で示すように、相互認証実行中に、再度、外部機器（２００）より開始通知受信手段に認証方式Ｂを用いて相互認証を行うようにコマンドを送信する（Ｓ００７−２）。
【０１４２】
制御手段（１００２）は、受信したコマンドを解釈し、開始通知受信手段（１００４）に対して認証方式Ｂを使うように通知する（Ｓ００８−２）。開始通知受信手段では、予め設定されたランク情報により優先度を検討する。
【０１４３】
本例では、認証方式Ａと認証方式Ｂを比較した場合、予め認証方式Ｂの方を優先するように設定されている。そのため、開始通知受信手段（１００４）は、優先度を比較し、後から受信した認証方式Ｂを優先することを決定し、相互認証手段（１００５）に認証方式Ｂで相互認証を行うように通知をする（Ｓ００９−２）。
【０１４４】
途中まで処理がされていた情報は相互認証手段（１００５）によってクリアされる。相互認証手段（１００５）は、認証方式Ｂに対応した鍵を認証コード保持管理手段（１００３）に要求し（Ｓ０１０）、認証コード保持管理手段（１００３）は相互認証手段（１００５）に送信する（Ｓ０１１）。相互認証手段（１００５）は、コマンド生成を行い、ＩＣカード手段（１００６）と相互認証を行う。
【０１４５】
認証装置（１００）が、認証方式Ａの認証を処理している間に、外部機器（２００）が、認証方式Ａより優先度が高い認証方式Ｂの認証を要求する例として次のような場合がある。
【０１４６】
例えば、映画コンテンツの購入・配信を行う外部機器において、カードにコンテンツを配信する場面を想定する。一般的にはＰＩＮの認証をデフォルトの認証とした場合、ユーザはカード挿入時にＰＩＮ認証を行っている。認証装置は、既に成功しているＰＩＮ認証を検出して、認証装置（１００）内でＰＩＮ認証済みに対応する鍵を使って、認証装置（１００）内相互認証を行う。
【０１４７】
その内、ユーザはコンテンツを購入し、公開鍵認証を用いた決済を行ったとする。この場合は、ユーザはＰＩＮ認証と公開鍵認証の２つの認証方法を外部機器と行ったことになる。セキュリティの観点から、ユーザが外部機器（２００）を操作し（ここは外部機器（２００）が自動に行ってもよい）、公開鍵認証済みに対応する鍵に切り替える処理を行う場合がある。
【０１４８】
これは、配信可能な映画コンテンツがリストになっていて、ＰＩＮ認証で搭載できるコンテンツと公開鍵認証で搭載できるコンテンツが並んでいる場面に想定できる処理である。その結果、ユーザはＰＩＮ認証で搭載できるコンテンツだけではなく、公開鍵認証で搭載できるコンテンツをカードに格納することができる。なお、このように優先度の高い認証方式に切り替える処理ができないと、ＰＩＮ認証を実行している時に、公開鍵認証に変更する場合、一度カードを抜いてＰＩＮ認証の結果を破棄し、カードをリセットする必要がある。
【０１４９】
また、前述の例では、外部機器（２００）は２つの認証方式に成功しているが、１つのチャネル（通信経路）を使って、ＩＣカード手段（１００６）と通信を行っているため、開始通知受信手段（１００４）が認証方式Ａ、Ｂの優先度を比較する必要があった。
【０１５０】
しかし、２つの認証方式ごとに、チャネルを１つずつ開くことで、優先度に関係なく、チャネルごとにアプリケーションの発行処理を行う事もできる。図１０を用いて説明を行う。
【０１５１】
外部機器（２００）は前提条件として、認証装置（１００）と認証方式Ａ、認証方式Ｂの２つの認証に成功している（Ｓ００１−１）。外部機器（２００）は、制御手段（１００２）に対して、認証方式Ａをチャネル番号１で使うことを開始通知受信手段に通知する（Ｓ００７−３）。
【０１５２】
通知に使用するフォーマットを図１６に例示する。本フォーマットは１つの表現形態であり、これに限定されるものではない。
【０１５３】
受信した制御手段（１００２）は、コマンドを解釈し、開始通知受信手段に送信する（Ｓ００８−３）。開始通知受信手段（１００４）は、相互認証手段（１００５）に認証方式Ａ、チャネル番号１を用いた相互認証を行うように指示を出す（Ｓ００９−３）。
【０１５４】
開始通知受信手段（１００４）は、排他制御を開始する。外部機器（２００）は、さらに制御手段（１００２）に対して、認証方式Ｂをチャネル番号２で使うことを開始通知受信手段に通知する（Ｓ００７−４）。
【０１５５】
相互認証手段（１００５）では、受信した通知内容により、鍵情報を認証コード保持管理手段（１００３）より取得し、コマンドを生成する。相互認証手段（１００５）とＩＣカード手段（１００６）間で相互認証が成功した場合、相互認証手段（１００５）は開始通知受信手段（１００４）にチャネル番号１での認証結果を通知する（Ｓ０１４）。
【０１５６】
相互認証手段（１００５）はチャネル番号２での認証結果を通知する（Ｓ０１５）。開始通知受信手段（１００４）は利用されているすべてのチャネルでの結果を取得したことを確認し、排他制御を終了する。
【０１５７】
以上のチャネルを使ったＩＣカード手段（１００６）と通信する事で、異なる認証方法で複数のアプリケーション発行を実現することができる。本例では、２つの認証方法に対して、２つのチャネルを開いたが、１つの認証方法を対して複数のチャネルを開く事も可能である。この場合は、相互認証手段でコマンドを生成する際に認証方法を重複して利用することを認めるようにするだけで実現可能である。
【０１５８】
なお、図１０に示す通信チャネル１と通信チャネル２は、例えば、外部機器（２００）の通信手段（２００４）（図３）、およびＩＣカード手段（１００６）の通信手段（３００４）（図４）が複数（この場合は２系統）あることに対応する。
【０１５９】
この場合、外部機器（２００）の通信手段（２００４）が複数あれば、同時に複数のカードと通信でき、ＩＣカード手段（１００６）の通信手段（３００４）が複数あれば、ＩＣカードがマルチチャネル対応となる。なお、通信手段が複数の場合は、通信手段に関連するブロックも複数系統になる。
【０１６０】
認証方式のランクの値を含め、サービス提供者領域に設定した提供機能１（４００２）と提供機能２（４００３）、ライフサイクル管理（４００６）で指定する権限の内容は、カード発行者が一律決めてしまう場合やユーザの趣向に任せる場合など運用の範囲でカバーすべき点である。
【０１６１】
セキュリティを設定した領域と認証方法を紐付けることで、アプリケーションの発行、実行環境、削除のライフサイクルを管理することができる。例えば、ＰＩＮ認証成功時に認証される領域では、ＰＩＮ認証によって、アプリケーションの発行、削除を行う事が可能になるが、実行環境としては、カードの高度の機能が使えないようにする。
【０１６２】
高度な機能というのは、署名生成などを含む暗号処理やパスワード変更、カード状態などの情報の追加、変更を指す。また、ＤＴＣＰでの認証が成功した場合は、高度な機能の他に、サービス提供者領域が共通して公開する著作権用の暗号処理を利用可能にするなど、実行環境に付加価値となる機能を追加できる。
【０１６３】
次に、図１１にサービス提供者領域の発行方法について示す。外部機器（２００）は、認証装置（１００）の制御手段（１００２）にＩＣカード手段で実行可能なデータを送信する（Ｓ１０１）。制御手段（１００２）は、受信したデータを解釈し、ＩＣカード手段（１００６）に送信する（Ｓ１０２）。
【０１６４】
ＩＣカード手段（１００６）は、受信したデータを解釈、実行し、サービス提供者領域を作成する。ＩＣカード手段（１００６）は実行した結果を制御手段（１００２）に送信する（Ｓ１０３）。サービス提供者領域のデータサイズによって、通信を行う回数は1回以上になる場合がある。制御手段（１００２）は、外部機器（２００）に受信した実行結果を送信する（Ｓ１０４）。
【０１６５】
外部機器（２００）は、次にサービス提供者領域に対して、パーソナライズ（カスタマイズ処理）を行うための処理をＩＣカード手段（１００６）に送信する（Ｓ１０５〜Ｓ１０８）。ここでいうパーソナライズとは、作成した領域に対して、個別の鍵情報や識別情報を付与する事により、他のサービス提供者領域とは異なる機能や権限を与えることであり、本例では領域固有の認証鍵設定がそれに当たる。その他の例としては、ＰＩＮ情報がそれに当たる。
【０１６６】
その際に、外部機器（２００）は、サービス提供者領域が認証に使う鍵を生成するために、制御手段（１００２）にコマンドを送信する（Ｓ１０９）。コマンドには、生成の命令の他にサービス提供者領域識別番号を付与する。
【０１６７】
制御手段（１００２）は鍵生成用のコマンドを解釈し、ＩＣカード手段（１００６）にカード状態確認を要求する（Ｓ１１０）。ＩＣカード手段（１００６）は、カードの状態を確認し、結果を制御手段（１００２）に送信する（Ｓ１１１）。
【０１６８】
制御手段（１００２）は、受信したカード状態を判定し、カードが相互認証可能な事業者によって、認証済みの状態もしくは生成した鍵を搭載するための領域がパーソナライズ状態になっていることを確認する。
【０１６９】
この判定を行う事で、外部機器（２００）の所有者が予めカードと相互認証可能な鍵を保有する事情者、つまりカード発行者もしくはカード発行者から権限を委譲された代行者であることを認識することができる。
【０１７０】
制御手段は鍵設定が可能であると判断した場合、認証コード保持管理手段（１００３）にサービス提供者領域識別番号を送信する（Ｓ１１２）。認証コード保持管理手段（１００３）は、受信したコマンドを解釈し、鍵の生成を行う。
【０１７１】
認証コード保持管理手段（１００３）は、生成した鍵とサービス提供者識別番号を内部で管理する認証コード管理テーブルに追記し、認証ＩＤを割り当てる。本例では、鍵を生成しているが、ＰＩＮ情報の場合は、認証コード管理テーブルに、ＰＩＮ情報を生成し登録する必要がある。認証コード管理テーブルを、図６に示す。
【０１７２】
認証コード保持管理手段（１００３）は、ＩＣカード手段（１００６）に生成した鍵を付与したコマンドを送信する（Ｓ１１３）。ＩＣカード手段（１００６）は、受信したコマンドを解釈し、鍵をサービス提供者領域に格納する。
【０１７３】
ＩＣカード手段（１００６）は、実行した結果を認証コード保持管理手段（１００３）に送信する（Ｓ１１４）。認証コード保持管理手段（１００３）は、制御手段（１００２）に実行結果と、結果が成功の場合だけ認証ＩＤを送信する（Ｓ１１５）。
【０１７４】
制御手段（１００２）は、外部機器（２００）に実行結果と認証ＩＤを送信する（Ｓ１１６）。外部機器は、パーソナライズの終了をＩＣカード手段（１００６）に通知するための処理を行う（Ｓ１１７〜Ｓ１２０）。
【０１７５】
開始通知受信手段（１００４）で優先度を判別する設定を行う場合は、前述の処理で取得した認証ＩＤもしくは認証方法の種別を識別できる情報を用いて、制御手段用コマンドに開始通知受信手段用のコマンドを包含させる。
【０１７６】
開始通知受信手段（１００４）では、認証ＩＤと優先度を対応してテーブルで管理している。送信するコマンドには認証ＩＤと優先度を表すランク値を付与する。すでに登録されている認証ＩＤを受信した場合、開始通知受信手段（１００４）は認証ＩＤに対応したランク値を上書きする。ランク値は数値にて表現し、数値が小さいもの程、優先度が高いものとする。ランク値は重複を許可しており、重複している場合は優先度が同じであることを示している。
【０１７７】
認証ＩＤを用いて、優先度を設定する場合も、認証コード登録と同様に外部機器（２００）とＩＣカード手段（１００６）が相互認証に成功した状態であることがセキュリティ上必要な条件である。
【０１７８】
以上の方法で、サービス提供者領域と認証コード保持管理手段（１００３）の両方で鍵を共有することができ、かつ共有した鍵を一切外に出さずに設定することが可能である。ＰＩＮ情報も同様の方法で外にださずに共有して設定することができる。
【０１７９】
このようにすることで、特定の認証方法以外にサービス提供者領域にアプリケーションの発行を行う事ができないので、必ず同一の認証方法を利用したアプリケーションだけが格納されたサービス提供者領域にすることができる。混在しないサービス提供者領域を作ることで、サービス提供者領域をアプリケーション共通の機能や特別な管理機能をもつプラットフォームとして利用することができる。
【０１８０】
認証コード保持管理手段（１００３）が管理する認証コードを削除する場合は、サービス提供者領域を削除する際に、合わせて行う。制御手段（１００２）がサービス提供者領域の削除を確認し、その後、認証コード保持管理手段（１００３）に削除希望を通知する。
【０１８１】
その際、削除対象の認証コードを指定するためにサービス提供者領域識別番号が必要になる。サービス提供者領域識別番号は外部機器（２００）が設定したデータであり、外部機器（２００）が認証コード削除用コマンドにサービス提供者識別番号を付与し、制御手段用コマンドに包含して、制御手段（１００２）に送信する。
【０１８２】
制御手段（１００２）は受信したコマンドを解釈し、認証コード保持管理手段（１００３）に認証コードの削除要求とサービス提供者領域識別番号を送信する。認証コード保持管理手段（１００３）は、受信したサービス提供者領域識別情報を使って、認証コード保持管理手段（１００３）が保持する認証コード管理テーブルから削除する。
【０１８３】
サービス提供者領域を削除するには、ＩＣカード手段（１００６）に対して相互認証をする必要があるため、前記領域をカードに発行した事業者であるカード発行者、もしくはカード発行者から権限を委譲された代行者が行う事ができる。
【０１８４】
なお、サービス提供者領域は、アプリケーションを管理するものであり、サービス提供者領域におかれるアプリケーションのライフサイクル、拡張機能は、基本的にサービス提供者領域（管理アプリケーション）が管理する。
【０１８５】
次に、本発明を使って２つの具体的なサービス事例を示す。まず、店舗でのポイントカード発行における事例を図１２を用いて説明する。
【０１８６】
サービス提供者が発行するアプリケーションは、すべてが一律同じセキュリティを求めるものばかりではない。例えば、クレジット機能付きのポイントカードアプリケーション（５００６）とクレジット機能無しのポイントカードアプリケーション（５００７）の２つを用意し、ユーザの希望に合わせて発行する形態を変えることができる。
【０１８７】
このような場合、従来の発行方法を使うと、クレジット機能無しのポイントカードアプリケーション（５００７）を発行する際、強固なセキュリティを踏襲し、カード発行者との事前の契約が必要となる。
【０１８８】
しかし、ポイントカードの運用上、免許証などの本人確認書類をチェックしない場合や不特定多数に配布する形態など、カードにアプリケーションを発行する際、高度なセキュリティを必要としない場合もある。
【０１８９】
近年、個人情報保護法のために個人情報を保護することが必須になり、上記のようなポイントカードの配布に個人情報を預かるリスクを犯したくない発行者が多く存在している。今後このようなアプリケーションの価値と漏洩を防止するコストとの対比により、アプリケーションの価値を低く見積もり、不特定多数に配布する場面は広がっていくと思われる。
【０１９０】
また、ポイントカード用にサービス提供者領域を構築した場合、その領域は、ポイントカードが最低限動作できる環境になってしまい、サービス提供者領域としては、効率が悪い運用しかできない。
【０１９１】
一方、本発明を利用した場合、ポイントカードが発行時に求めるセキュリティをＰＩＮ認証レベルとサービス提供者が想定することで、クレジット機能無しのポイントカードアプリケーション（５００７）は、ＰＩＮ認証を成功しただけで、ＰＩＮ認証用領域（５００３）に発行することが可能になる。
【０１９２】
ＰＩＮ認証は、ユーザがカード内に格納した情報との照合のため、店頭の端末でユーザからの入力値をカードに送信するだけで認証可能であり、複雑な暗号アルゴリズムを実装する必要がない。
【０１９３】
クレジット機能付きのポイントカードアプリケーション（５００６）は、発行時に求めるセキュリティが高度なレベルであるため、従来のアプリケーション発行の仕組みを使う事で、1枚のカードに共存し、かつ実行環境の住み分けをすることができる。
【０１９４】
通常、発行を行う際のデータの受け渡し経路は、図１４に示すように、認証装置（１００）の制御手段（１００２）を使う場合と、ＩＣカード手段（１００６）の通信手段（３００４）を使う場合のどちらでも構わない。そのため、接触・非接触を問わず、発行することができる。
【０１９５】
その際、通信を行う外部機器（２００）は、制御手段（１００２）を経由して、認証手段（１００１）と認証を実施する外部機器（２００＿ａ）と、制御手段（１００２）を経由してＩＣカード手段（１００６）の演算手段（３００１）と通信を行う外部機器（２００＿ｂ）と、ＩＣカード手段（１００６）の通信手段（３００４）と通信を行う外部機器（２００＿ｃ）の３種類を考えることができる。この３種類は、すべてが必須ではなく、発行の仕組みによって、取捨選択すれば良い。
【０１９６】
ＩＣカードを使った非接触での発行では、外部機器（２００＿ｃ）が必要になる。制御手段（１００２）経由でＩＣカード手段に発行する場合は、外部機器（２００＿ｂ）が必要になる。
【０１９７】
その際、鍵情報を共有せずに発行するのであれば、既存の認証方法に対応している外部機器（２００＿ａ）を用いて、認証手段（１００１）と認証を行い、その検証結果を用いて、認証コード保持管理手段（１００３）から認証コードを取得し、相互認証手段（１００５）を用いて、ＩＣカード手段（１００６）と認証を行うことになる。機器構成として、３種類の外部機器は、１つの機器内で構成されても、個別の機器で構成されたシステム上の構成でも構わない。
【０１９８】
また、このサービスの補足的な効果として、ＰＩＮ認証だけでＰＩＮ認証用領域（５００３）内のライフサイクルを管理することができるので、ユーザ本人で不要になった場合、自らアプリケーションを削除することができ、限られたカードのリソースを有効に活用することができる。
【０１９９】
次に、店頭にあるコンテンツ販売機における事例を図１３を用いて説明する。ＩＣチップが搭載されたメモリカードのような大規模な記憶容量を持つセキュアなカードを使って、コンテンツを購入する場合、従来のコンテンツ販売機を用いた場合、著作権保護の仕組みとして公知の技術であるＣＰＲＭ（Content Protection For Recordable Media）を用いて、コンテンツ販売機とセキュアカードが相互認証を行う。
【０２００】
その後、セキュアカードのメモリ上に暗号化されて映画コンテンツが置かれる。通常は、再生機器にセキュアカードを挿入すれば、再生機器とセキュアカードが相互認証を行い、再生機器に暗号化データが転送され、再生機器で復号化され再生されるという流れになるが、この流れでは、メモリに記憶するコンテンツを暗号化する時に使われているメディアユニーク鍵がメモリ内で保有するメディアＩＤとＭＫＢ（Media Key Block）によって生成されるため、メモリ内に格納された暗号化コンテンツに対して個別に鍵を設定することができない。そのため、コンテンツ販売機に対価を払って購入するか、無料でコンテンツを開放するかのどちらかしか方法がない。
【０２０１】
本発明を利用した場合、映画コンテンツを複数のブロックに分割し、メモリ上に格納する方法を使うと、視聴可能で、かつ購入時に再ダウンロードの必要がないコンテンツ配布方法を実現することができる。
【０２０２】
ＣＰＲＭによる相互認証が成功した際、認証コード保持管理手段（１００３）は、著作権用領域と認証を行う鍵を、相互認証手段（１００５）に送信する。相互認証手段（１００５）は、ＩＣカード手段（１００６）内部の著作権用領域（６００２）と相互認証を行う。
【０２０３】
その際にコンテンツ販売機は、著作権用領域（６００２）に対して、視聴用解除キーを含むアプリケーション（６００４）を発行する。ユーザは、コンテンツ販売機にセキュアカードを挿入しただけで、記憶領域（４００５）に映像コンテンツ（６００５）、著作権用領域（６００２）に視聴用解除キーを含むアプリケーション（６００４）が格納されることになる。
【０２０４】
再生機器で再生する際には、視聴用解除キーを含むアプリケーション（６００４）でまず暗号化を解かないと見ることができない仕組みになっている。また、他のデータは、コンテンツ会社領域が正規の認証方法を使って格納する映像アプリ解除キーを含むアプリケーション（６００３）がないと見ることができない。
【０２０５】
さらに記憶領域にはすでに大規模なデータを搭載済みであるため、ユーザは購入時に大規模なデータを取得する手間がなく、映像アプリ解除キーを含むアプリケーション（６００３）だけを取得することで映像を見ることが可能となる。
【０２０６】
コンテンツ会社は、ユーザに予め契約を結ばなくても、カード手段（１００６）にアプリケーションを簡便に発行することができ、購入を希望するユーザにだけ、コンテンツ会社によるサービス提供者領域を作成するので、ユーザの獲得の機会を失わずに、宣伝投資を最小限に抑えることができる。
【０２０７】
ユーザは、記憶領域（４００５）上にある映像コンテンツ（６００５）を自由に削除することが可能であるので、不要の際に手間がかからない。
【０２０８】
尚、上記の実施の形態において、表の項目や設定値は一例であり、これにとらわれるものではなく、認証の内容、ＩＣカードや外部機器のハードウェア・ソフトウェアに係わる設計上の制約、ＩＣカードや外部機器のユーザの意向などにより任意に設定可能である。
【０２０９】
本発明の具体的な構成は、認証手段（１００１）をＣＰＲＭ機能、制御手段（１００２）・開始通知受信手段（１００４）・相互認証手段（１００５）をＳＤコントローラ、ＩＣカード手段（１００６）をＩＣチップ、記憶手段（４００５）をフラッシュメモリとして構成する。
【０２１０】
認証装置（１００）のハードウェアの構成としては、それが1チップで構成されていても、2チップで構成されていても同じであり、本発明の範囲に含まれる。
【０２１１】
認証コード保持管理手段も、上記と同様にＳＤコントローラが実装しても構わないが、ＴＲＭ（Tamper Resistant Module）領域上に、認証コードを管理する必要性があるため、ＩＣチップ上のアプリケーションとして実装しても構わない。ＴＲＭ領域とは、物理的、理論的にチップの内部解析や改竄が出来ない仕組みで構成された領域であり、ＩＣチップ上に存在する。
【０２１２】
図１５に示すように、ＩＣカード手段（１００６）の論理領域上に、サービス提供者領域として、管理用領域（７００１）を用意する。管理用領域上にはアプリケーション（７００６）を搭載し、そのアプリケーションが、各サービス提供者領域（５００１、５００２、５００３）が保持する鍵（７００２、７００３、７００４）に対応した鍵を保持する。
【０２１３】
図１５では、共通鍵暗号方式を使用した例のため、対応する鍵が同一になっている。この際、同じチャネルを利用すると、アプリケーション（７００６）にアクセスして、認証コード情報を取得する処理が、外部機器（２００）とＩＣカード手段（１００６）が通信しているチャネルと混在してしまうので、別チャネルで行うことが前提となる。
【０２１４】
また、認証コード保持管理手段（１００３）が管理する鍵は、フラッシュメモリをＴＲＭ上の鍵で暗号化した領域に置いても良い。ＴＲＭはコストが高く、できる限り領域を小さくしたいという要望があるため、フラッシュ上でのソフトウェア耐タンパーが言える場合は、フラッシュでも構わない。
【０２１５】
外部機器（２００）は、制御手段（１００２）を介して認証手段（１００１）と認証を行う。認証手段（１００１）は、相互認証手段（１００５）に通知する。相互認証手段（１００５）は、ＩＣカード手段（１００６）の管理用領域（７００１）にコマンドを送信する。
【０２１６】
コマンドは、予め相互認証手段と仕様の共有が行われており、ＩＳＯ７８１６に記載されているＡＰＤＵ（Application Protocol Data Unit）がそれに当たる。ＩＣカード手段（１００６）は受信したコマンドを解析し、正当であると判断できた場合、相互認証手段（１００５）に戻り値を送信する。
【０２１７】
相互認証手段は、前記戻り値を検証し、正当である事を確認した場合、管理用領域（７００１）と外部機器（２００）は相互認証に成功したことになる。
【０２１８】
カード上のＴＲＭ領域を利用するため、外部機器に新たなＴＲＭ領域を持つコストを抑えることができる。カードに限らず、携帯電話にＩＣチップを搭載した場合でも、ＩＣチップに搭載することで鍵の漏洩の心配をすることなく、外部機器と鍵共有をしたのと同じ効果が期待できる。
【産業上の利用可能性】
【０２１９】
本発明の認証装置は、外部機器からコマンドを受信したときに、相互認証手段が、認証手段が用いた認証方法に対応する認証コードを用いてＩＣカード手段と相互認証を行うことにより、外部機器と認証装置との間で必要とされる相互認証を認証装置内で行い、外部機器に対しては相互認証済みのように振舞うことができるため、新たな認証方法を用いることなく容易に外部機器との相互認証を行うことができる効果を有し、外部機器との間で相互認証を行う機能を有する認証装置及びこの認証装置におけるアプリケーション発行方法等に有用である。
【図面の簡単な説明】
【０２２０】
【図１】従来技術で用いられているＩＣカードの論理領域を示す図
【図２】本発明の実施の形態を説明するための認証装置の構成を示す図
【図３】本発明の実施の形態を説明するための外部機器の構成を示す図
【図４】本発明の実施の形態を説明するためのＩＣカード手段の内部構成を示す図
【図５】外部機器と認証装置が内部的に相互認証を行う手順を示すシーケンス図
【図６】認証コード保持管理手段が保持する認証コード管理テーブルの例を示す図
【図７】外部機器と認証装置が内部的に相互認証を行う手順の概念図
【図８】サービス提供者領域の機能とアプリケーション管理の例を示す図
【図９】外部機器と認証装置が内部的に相互認証を行う手順を示すシーケンス図
【図１０】外部機器と認証装置が内部的に相互認証を行う手順を示すシーケンス図
【図１１】サービス提供者領域の発行と鍵設定手順を示すシーケンス図
【図１２】本発明をポイントカードアプリケーション発行に適用した図
【図１３】本発明をコンテンツ配信方式に適用した図
【図１４】発行データの受け渡し経路を示した図
【図１５】アプリケーションが各サービス提供者領域に対応した鍵を保持する図
【図１６】制御手段に送信するコマンドフォーマットおよびコマンド例を示した図
【符号の説明】
【０２２１】
０００１  カード発行者領域
０００２  サービス提供者Ａ領域
０００３  サービス提供者Ｂ領域
０００４  サービス提供者Ａが保持するアプリケーション
０００５  サービス提供者Ｂが保持するアプリケーション
０００６  カード発行者が保持するアプリケーション
１００    認証装置
１００１  認証手段
１００２  制御手段
１００３  認証コード保持管理手段
１００４  開始通知受信手段
１００５  相互認証手段
１００６  ＩＣカード手段
２００    外部機器
２００１  演算手段
２００２  認証手段
２００３  記憶手段
２００４  通信手段
３００１  演算手段
３００２  暗号処理手段
３００３  記憶手段
３００４  通信手段
４００１  サービス提供者領域
４００２  提供機能２
４００３  提供機能１
４００４  アプリケーション
４００５  記憶手段
４００６  ライフサイクル管理
５００１  ＰＫＩ認証用領域
５００２  著作権用領域
５００３  ＰＩＮ認証用領域
５００４  アプリケーション
５００５  販売店領域
５００６  クレジットカードアプリケーション
５００７  ポイントカードアプリケーション
６００１  コンテンツ会社領域
６００２  映像アプリ解除キーを含むアプリケーション
６００３  視聴用解除キーを含むアプリケーション
６００４  映像コンテンツ
【図１】
2007122379.tif 000003
【図２】
2007122379.tif 000004
【図３】
2007122379.tif 000005
【図４】
2007122379.tif 000006
【図５】
2007122379.tif 000007
【図６】
2007122379.tif 000008
【図７】
2007122379.tif 000009
【図８】
2007122379.tif 000010
【図９】
2007122379.tif 000011
【図１０】
2007122379.tif 000012
【図１１】
2007122379.tif 000013
【図１２】
2007122379.tif 000014
【図１３】
2007122379.tif 000015
【図１４】
2007122379.tif 000016
【図１５】
2007122379.tif 000017
【図１６】
2007122379.tif 000018