JP4806639B2 - セキュアデバイス及びｉｃカード発行システム - Google Patents

Description

本発明は、ＩＣ（Integrated Circuit）カードに代表されるセキュアデバイス、及びセキュアデバイスとセキュアデバイスに通信接続される携帯端末に代表される外部機器とからなるＩＣカード発行システムに関し、特に、通信接続された外部機器からの指示を受けてカード発行処理を行うセキュアデバイス、及びＩＣカード発行システムに関する。

現在、セキュアデバイスとしてＩＣカードが注目されている。ＩＣカードには、単にデータを格納するものや実際にＯＳ（Operating System）を登載するものなどがある。ＩＣカードの採用事例としては、クレジットカードやＥＴＣ（Electronic Toll Collection System）カードに代表される接触型ＩＣカード、及び交通系カードや電子マネーカードに代表される非接触型ＩＣカードなど様々なものが挙げられ、今後も新たな採用分野の開発、及び採用分野の規模拡大が進むと期待される。

一方、ユーザの利便性の向上、ＩＣカードによるサービスを提供したい事業者の参入障壁を下げることを目的に、カード発行後にアプリケーションをダウンロードすることが可能なマルチアプリケーション対応カードの開発が行われている。

また、ＩＣカードのようなセキュアデバイスを携帯端末等のモバイル機器に登載し、アプリケーションのダウンロードやアプリケーションの利用を、モバイル機器を介して実施する技術が実用化されつつある。

ここで、ＩＣカードのハードウェア構成について、図１を用いて説明する。図１は、ＩＣカードのハードウェアに関する機能ブロック図である。

ＩＣカード１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、揮発性メモリ（例：ＲＡＭ：Random Access Memory）１３、揮発性メモリ（例：ＥＥＰＲＯＭ：Electrically Erasable Programmable Read Only Memory）１４、及びＩ／Ｏ ＩＦ１５を備えている。

ＣＰＵ１１は、演算を行う。ＲＯＭ１２は、書き換えができない読み出し専用のメモリである。ＲＯＭ１２に格納される内容は、ＩＣカード製造時に決定され、その後変更することはできない。ＲＡＭ１３は、読み書きが可能なメモリである。ＥＥＰＲＯＭ１４は、電源が切断されても内容が保持されるようになっている。Ｉ／Ｏ ＩＦ１５は、ＩＣカード１０と外部とのデータ交換を担当する。ＣＰＵ１１で実行されるプログラムは、通常「アプリケーション」と呼ばれる。アプリケーションの実行のためのコードは、ＲＯＭ１２やＥＥＰＲＯＭ１４に格納される。また、ＩＣカード１０が暗号操作される場合には、ＩＣカード１０は、図１に示す以外に、暗号用コプロセッサをさらに備える。

ＩＣカード１０に登載されるアプリケーションと外部（リーダ）との間では、例えば、ＩＳＯ／ＩＥＣ７８１６−４で規定されているフォーマットであるＡＰＤＵ（Application Protocol Data Unit）を使ってデータを交換する。ＡＰＤＵは、リーダがＩＣカードに与えるコマンドメッセージと、ＩＣカードからリーダに返すレスポンスメッセージとの２つの構成からなる。

ＡＰＤＵコマンドのフォーマットについて、図２を用いて説明する。図２は、ＡＰＤＵコマンドのフォーマットの一例を示す図である。

図２のＡＰＤＵコマンド２０は、ヘッダ２１と本体２２とからなる。ヘッダ２１は、クラス（ＣＬＡ）、命令（ＩＮＳ）、及びパラメータ（Ｐ１，Ｐ２）で構成されている。本体２２は、コマンドのデータフィールド長（Ｌｃ：Length of Command Data）、データ部及びレスポンスのデータフィールド長（Ｌｅ：Length of Expected Data）で構成されている。ＡＰＤＵコマンド２０の容量は、ＣＬＡ，ＩＮＳ，Ｐ１，Ｐ２，Ｌｃ，Ｌｅ：各１バイト、及びデータ部：２５５バイトの合計２６１バイトが最大である。

次に、ＡＰＤＵを作成する方式について、図３を用いて説明する。図３は、データを分割してＡＰＤＵを作成する方式を示す概念図である。

上記のように、１つのＡＰＤＵコマンド２０の容量は、２６１バイトと小さいため、アプリケーションをダウンロードするときの数Ｋバイトにおよぶデータを送信するためには、送信データを複数のＡＰＤＵブロックに分ける必要がある。それぞれのＡＰＤＵブロックのパラメータ（Ｐ１，Ｐ２）でブロック番号やあとに続くブロックがあるかどうかを示すことにより、ＩＣカード側で、送られてきたコマンドの順番の整合性や最終処理の必要性をチェックすることができる。

また、Ｌｃを３バイトで表記し、１バイト目で３バイト表記であることを示し、２バイト目及び３バイト目でデータ長を示す拡張が提案されているが、ＩＣカードのメモリ容量の観点から実装例はきわめて少ない。

一般的に、ＩＣカードのようなメモリ容量の小さなデバイスにおいては、受信したコマンドを格納する入力バッファは、大きなサイズを取ることができない。マルチアプリケーション対応カードを用いて説明すると、ある領域を永続的に入力バッファとし、アプリケーション間で共通利用することで、確保するメモリ容量を制限している。マルチアプリケーション対応カードでは、アプリケーションが選択されたときに「現在選択されているアプリケーションを示すカレントＡＰ情報」を更新し、次につづくコマンドを受信したときにカレントＡＰ情報を参照することにより、選択中のアプリケーションに確実にコマンドを渡すことができる。

アプリケーションのダウンロードは、カードマネージャを介して行う。カードマネージャは、マルチアプリケーション対応カードにおいてカードの管理やカード内のアプリケーションを管理するアプリケーションである。「カードの管理」とは、カード発行者がカードを管理するために必要なＩＤや鍵をカード内に格納するカード発行や、発行後のカードを一時停止状態や廃棄状態に遷移させることである。また、「アプリケーションの管理」とは、アプリケーションのダウンロードや削除をおこなうことである。

また、最近では、ＩＣチップから大容量メモリをＩＣカード拡張メモリ保護領域として利用可能なデバイス（以下、セキュアメモリカード）が提案され、ＩＣカードアプリケーションデータの大容量化というニーズに対応可能となっている。セキュアメモリカードは、モバイル機器の大きさに適合できるため、スロットつきのモバイル機器に直接挿入し、モバイル機器を利用したＥＣ（Electronic Commerce）サービス利用への展開が期待されている。

モバイル機器を利用する場合には、電波圏外に位置することによって通信中断が起こり、その結果としてカードの振る舞いに影響を与える可能性が高くなる。そこで、通信中断が発生したときに、最初からダウンロードをやり直したり、途中から再送したりといった繰り返し処理が提案されている。

このようなＩＣカードアプリケーションプログラムロード技術として、例えば、特許文献１に開示されているものがある。図４は、特許文献１に記載されているＩＣカードアプリケーションプログラムロード装置のブロック図である。

図４において、ホストコンピュータ３０は、アプリケーションプログラムを記憶し、アプリケーションプログラムに所定の暗号化処理（ＲＳＡ：Rivest-Shamir-Adleman）を施して分割したコンポーネントとし、端末装置４０を介してＩＣカード５０に提供する。ＩＣカード５０は、ホストコンピュータ３０との通信が中断し、アプリケーションプログラム等のデータのやりとりが中断した場合には、正常に受信された部分以外のデータの再送要求をホストコンピュータ３０に送信する。そして、すべてのコンポーネントを受信した場合には、これらを統合し、復合化処理し、誤り検出処理する。一方、再送要求を所定の回数だけ送信しても正常に受信されない場合には、再送要求の送信を打ち切り、それまで正常に受信し記憶されたデータを消去する。
特開２００３−１０８３８４号公報

しかしながら、特許文献１記載のＩＣカードアプリケーションプログラムロード技術にあっては、以下のような問題がある。

第１に、ホストコンピュータとＩＣカードとの間で、アプリケーションプログラムのダウンロードに必要なデータの送受信を繰り返し行う必要があるため、両者間の通信が何らかの理由で中断した場合のダウンロードへの影響を免れることができず、ＩＣカードの振る舞いに影響を与える可能性が高くなるという問題がある。特に、今後、セキュアデバイスのメモリ容量増加に伴って高機能アプリケーションが期待され、アプリケーション自体が巨大化する傾向にあり、その結果、ＡＰＤＵブロック数はますます多くなると考えられる。このようなＡＰＤＵブロック数の増加はダウンロード時間の増加を意味し、ダウンロードが完了するまでに通信中断が発生する可能性が高くなることを意味する。また、通信中断が発生したときに、最初からダウンロードをやり直したり、途中から再送したりといった繰り返し処理を行っても、再送中の失敗による再再送など繰り返し処理によるシステムやカード処理の複雑性、及びダウンロード時間の増加によるユーザストレスが懸念され、できるだけ通信中断の影響を受けない方式が求められる。

第２に、ＩＣカードは、受動的なデバイスであり、ホストコンピュータから与えられたアプリケーションプログラムを取り込んで、このプログラムに指示された通りにしか動作することができないという問題がある。すなわち、使用に供するＩＣカードのアプリケーションそのものは、元々、ＩＣカードに接続される外部機器（この場合、ホストコンピュータ）に格納されたものであるため、カード発行やアプリケーションダウンロードにおいて、ユーザが選択することができるアプリケーションの範囲は制限されており、利便性に欠ける。

第３に、ホストコンピュータは、アプリケーションプログラムに所定の暗号化処理を施してＩＣカードに送信するため、ＩＣカードでは、復号化や検証の処理が必要になるという問題がある。上記のように、ＩＣカードの処理能力は高くなく、従来のセキュリティを確保しつつ、すべて平文で処理、又は復号化や検証の回数を減らすことが可能な方式が望ましい。

第４に、アプリケーションプログラムのダウンロードやカード発行時にホストコンピュータとＩＣカードとがセッション鍵を共有し、そのセッション鍵でＩＣカードに送信するＡＰＤＵブロックの暗号化やＭＡＣ（Message Authenticate Code）検証を行うためには、元データとなるＡＰＤＵブロックを知る必要があるという問題がある。実際には、ＡＰＤＵブロック作成者とアプリケーションプログラムのダウンロードやカード発行を実行する事業者とが分離している場合もあるため、ＡＰＤＵブロックに個人情報などの秘匿性の高い情報を含む場合にはアプリケーションプログラムのダウンロードやカード発行を実行する事業者がＡＰＤＵブロックの内容を知ることができない方式が期待されている。

本発明は、かかる点に鑑みてなされたものであり、外部機器との通信中断による影響を低減し、ユーザが所望するアプリケーションプログラムを、高速かつ安全に取り入れることができるセキュアデバイスを提供することを目的とする。

本発明のセキュアデバイスは、内部メモリに格納されたコマンド群から、取得するカードの機能に対応するカード発行コマンドを抽出するカード発行部と、前記カード発行部により抽出された前記カード発行コマンドを実行するカード管理部と、を有する構成を採る。

本発明のＩＣカード発行システムは、セキュアデバイスとこのセキュアデバイスとの間で通信を行う外部機器とからなるＩＣカード発行システムであって、前記外部機器は、カード発行を要求する要求コマンドを生成するコマンド生成部と、生成された前記要求コマンドを前記セキュアデバイスに送信するコマンド送信部と、を有し、前記セキュアデバイスは、内部メモリに格納されたコマンド群から、取得するカードの機能に対応するカード発行コマンドを抽出するカード発行部と、前記要求コマンドを入力した場合、前記カード発行部により抽出された前記カード発行コマンドを実行するカード管理部と、を有する構成を採る。

本発明によれば、外部機器とセキュアデバイスとの間の通信回数を削減し、かつ従来のセキュリティを確保したうえで、セキュアデバイス内のセキュリティ処理負荷を軽減することによって、外部機器とセキュアデバイスとの間におけるデータ処理（例えば、アプリケーションプログラムのダウンロードやカード発行）の高速化を実現することができる。また、ユーザが所望するアプリケーションプログラムをセキュアデバイスに取り入れることができる。さらに、アプリケーションプログラムのダウンロードやカード発行に関与する複数の事業者間において契約によって実現されてきた情報保護を、技術的に実現することができる。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。なお、本発明はこれらの実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。

また、「セキュアデバイス」とは、広義では、アプリケーションを有するチップが組み込まれた認証機能や決済機能、ＶＰＮ（Virtual Private Network）等の機能を有するデバイス全般を意味する。以下の実施の形態では、セキュアデバイスの例としてマルチアプリケーション対応カードを採用して説明する。

また、「カード発行」とは、アプリケーションを有するカード自体の発行と、発行済みのカードへのアプリケーションのダウンロードとの両方を意味する。以下の実施の形態では、カード発行の例としてこの両者を採用して説明する。

（実施の形態１）
図５は、本発明の実施の形態１に係るセキュアデバイス１００の構成を示すブロック図である。

図５において、セキュアデバイス１００は、カード管理部１０２、カード発行部１０４、及びコマンド格納部１０６を備えて構成される。

カード管理部１０２は、後述する外部機器１５０との間で通信を行い、アプリケーションプログラムや制御信号などの各種のコマンドを送受信する。また、カード管理部１０２は、例えば、カードを発行するために必要なＩＤや鍵を保持したり、必要に応じて、発行後のカードを一時停止状態や廃棄状態に遷移させることにより、セキュアデバイス１００の動作を管理する。また、カード管理部１０２は、後述する外部機器１５０からのダイレクトアクセスの要求を受け入れるかどうかを判断する。

また、カード管理部１０２は、アプリケーションプログラムのダウンロードを管理する機能（カードマネージャ）を有する。具体的には、カード発行部１０４により書き込まれた各カード発行コマンドを実行する。そして、カード管理部１０２は、カード発行が成功したかどうかを示す結果であるレスポンスを外部機器１５０に送信する。

カード発行部１０４は、コマンド格納部１０６が格納するコマンド群から、取得するカードの機能に対応する一連のカード発行コマンドを選択して抽出する。また、カード発行部１０４は、抽出した一連カードの発行コマンドを、カード発行コマンド単位で、カード管理部１０２のＡＰＤＵバッファ（図示せず）にコピーする。

コマンド格納部１０６は、カード発行を実行するためのコマンド群を格納する内部メモリである。コマンド格納部１０６に格納されるコマンド群は、例えば、購入時にセキュアデバイス１００内に格納（プレインストール）されているものでもよいし、購入後に外部機器１５０から書き込まれて挿入（インストール）されたものでもよい。すなわち、セキュアデバイス１００の用途や容量に応じて、コマンド格納部１０６に格納されるコマンド群を自由に変更、追加又は削除することができる。また、コマンド格納部１０６は、外部機器１５０からのダイレクトアクセスにより書き込まれる一連のカード発行コマンドであるＡＰＤＵ発行コマンドをまとめたデータを格納するセキュア領域を有する。

コマンド格納部１０６は、複数のカードの機能に対応する複数のカード発行コマンド群を格納することができる。それぞれのカードの機能に対応する一連のカード発行コマンドは、それぞれ後述する連立コマンドとしてファイルに収められて格納される。また、この連立コマンドが収められたファイルは、ファイル名やファイルＩＤにより識別可能である。

次に、図５の外部機器の構成について、図６を用いて説明する。図６は、図５の外部機器１５０の構成を示すブロック図である。

図６において、外部機器１５０は、コマンド生成部１５２、コマンド送信部１５４、レスポンス受信部１５６、及びセルフ発行管理部１５８を備えて構成される。

コマンド生成部１５２は、カード管理部１０２との間でやりとりする各種のコマンドを生成する。特に、コマンド生成部１５２は、セルフ発行管理部１５８の指示を受けて、セキュアデバイス１００へのカード発行要求であるセルフ発行開始コマンドを生成する。コマンド生成部１５２で生成されたセルフ発行開始コマンドは、コマンド送信部１５４を介してカード管理部１０２へ出力される。

コマンド送信部１５４は、コマンド生成部１５２で生成されたセルフ発行開始コマンドその他の各種コマンドを、カード管理部１０２へ出力する。

レスポンス受信部１５６は、カード管理部１０２からの、カード発行が成功したかどうかを示すレスポンスを受信する。レスポンス受信部１５６で受信されたレスポンスは、セルフ発行管理部１５８へ出力される。

セルフ発行管理部１５８は、外部機器１５０内におけるセルフ発行開始コマンドの生成及び送信を制御する。具体的には、セルフ発行管理部１５８は、コマンド生成部１５２に対して、セルフ発行開始コマンドの発行を要求する。また、セルフ発行管理部１５８は、レスポンス受信部１５６からのカード発行が成功したかどうかを示すレスポンスを受けて、レスポンスの内容を解析し、外部機器１５０の次の動作を決定する。

例えば、セルフ発行管理部１５８は、カード発行が成功したというレスポンスを受けた場合は、外部機器１５０の処理を終了する旨の指示を出す。また、カード発行が成功したことを再度セキュアデバイス１００に通知した後でなければカード発行によりダウンロードしたアプリケーションプログラムを使用できない場合は、セルフ発行管理部１５８は、コマンド生成部１５２に対して、「カード使用許可確認用コマンド」の発行を要求する。

一方、セルフ発行管理部１５８は、カード発行が失敗したというレスポンスを受けた場合は、コマンド生成部１５２に対して、セルフ発行開始コマンドを再生成及び再送信する旨の指示を出し、又はカード発行を中止する旨の指示を出す。

以下、上述のように構成されたセキュアデバイス１００の動作について、図７を用いて詳細に説明する。

図７は、本発明の実施の形態１に係る外部機器１５０、カード管理部１０２及びカード発行部１０４の処理を示すシーケンス図である。図７の例は、外部機器１５０から書き込まれたＡＰＤＵ発行コマンドを処理してアプリケーションプログラムをダウンロードする場合を示している。

ステップＳ１０００では、外部機器１５０とカード管理部１０２との間で使用するアプリケーションを選択する。具体的には、まず、外部機器１５０が、カードマネージャ（＝カード発行に使用するアプリケーション）を選択するためのコマンドをカード管理部１０２へ送信する。次いで、カード管理部１０２が、外部機器１５０からのコマンドを受信して、カードマネージャの選択に成功すると、現在選択されているＡＰを示す「カレントＡＰ情報」をカード管理部１０２に更新し、次に続くコマンドを受信したときに、更新された「カレントＡＰ情報」を参照する。このようにして、カード管理部１０２に、次に続くコマンドを渡すことができる。

ステップＳ１１００では、外部機器１５０とカード管理部１０２との間で、お互いの認証処理を行う。具体的には、セキュアデバイス１００が外部機器１５０を認証する外部認証と、外部機器１５０がセキュアデバイス１００を認証する内部認証とのうち、必要とするセキュリティレベルに応じて、両方又は一方のみ実施する。

なお、ステップＳ１１００の認証ステップは、秘匿性の高いデータを書き込む際には、必ず行うことが好ましいが、それ以外のデータを書き込む際には、省略してもよい。

ステップＳ１２００では、外部機器１５０が、コマンド格納部１０６のセキュア領域に対して、アプリケーションプログラムのダウンロードを実行するＡＰＤＵ発行コマンドをまとめたデータ（以下「連立コマンド」という）１６０を書き込むダイレクトアクセス処理を行う。上記のように、ダイレクトアクセスにより書き込まれた連立コマンド１６０は、ファイル名やファイルＩＤで識別可能にファイルに収められてコマンド格納部１０６に格納される。

このとき、外部機器１５０は、ステップＳ１０００で選択したアプリケーションにより許可されない限り、コマンド格納部１０６に格納されたコマンドを見ること、及びダイレクトアクセスをすることができない。ダイレクトアクセスでは、一度に数メガバイトの書き込みが可能なブロック転送のプロトコルを用いるため、アプリケーションプログラムのダウンロードを実行する連立コマンド１６０は、通常、１回だけのダイレクトアクセスで書き込みが完了する。

ここで、連立コマンド１６０について、図８を用いて説明する。図８は、連立コマンド１６０の構成の一例を示す図である。

図８において、連立コマンド１６０は、連立コマンド１６０がいくつのＡＰＤＵ発行コマンドから構成されるかを示すＡＰＤＵ数１６１とコマンド実体部１６２とからなる。図８の例では、ＡＰＤＵ数１６１は、ｍである。

コマンド実体部１６２は、ＡＰＤＵ発行コマンド１６５−１，１６５−２，１６５−３，…，１６５−ｍからなるデータと、これらのＡＰＤＵ発行コマンドがそれぞれ何バイトで構成されているかを示すコマンド長１７０−１，１７０−２，１７０−３，…，１７０−ｍとからなる。

ステップＳ１３００では、外部機器１５０が、セキュアデバイス１００に対するカード発行要求であるセルフ発行開始コマンド１８０を、カード管理部１０２に送信する。このセルフ発行開始コマンド１８０は、セルフ発行管理部１５８からの発行要求を受けたコマンド生成部１５２で生成され、コマンド送信部１５４を介して送信される。

本明細書において、「セルフ発行」とは、カード管理部１０２とカード発行部１０４との間で、コマンド格納部１０６に格納された連立コマンド１６０を構成する各ＡＰＤＵ発行コマンドを処理してカード発行を行うことを意味する。セルフ発行中のカード管理部１０２及びカード発行部１０４の動作については、後のステップＳ１５００−１〜ステップＳ１５００−ｍで詳細に説明する。

ここで、セルフ発行開始コマンド１８０について、図９を用いて説明する。図９は、セルフ発行開始コマンド１８０の形式の一例を示す図である。

図９において、セルフ発行開始コマンド１８０は、セルフ発行開始コマンドであることを特定するためのヘッダ部１８１、ファイル特定情報１８２、オフセット１８３、及び長さ１８４からなる。

ファイル特定情報１８２は、連立コマンド１６０が収められたファイルを特定するための情報（例えば、ファイル名やファイルＩＤ等）である。オフセット１８３は、特定したファイルからの読み出し位置を示す情報であり、長さ１８４は、読み出すデータ長を示す情報である。

なお、連立コマンド１６０が収められたファイルが一意に決まっているなどの理由でデフォルト処理が可能な場合は、ファイル特定情報１８２のファイル名やファイルＩＤ等を含む必要はない。

カード管理部１０２は、セルフ発行コマンド１８０を受信した後にレスポンスを送信しない限り、次のコマンドを受信することができない。ステップＳ１４００では、カード管理部１０２が、Ｓ１３００で送信したセルフ発行開始コマンド１８０を受信し、セルフ発行開始コマンド１８０に対するレスポンスとして、セルフ発行トリガをカード発行部１０４に対して出力する。セルフ発行トリガは、連立コマンド１６０のアドレス、オフセット１８３、及び長さ１８４を含む。このセルフ発行トリガは、カード発行部１０４にとって、セルフ発行を開始するためのトリガとなる。すなわち、セルフ発行トリガの送受信により、カード管理部１０２とカード発行部１０４との間で、連立コマンド１６０を構成する各ＡＰＤＵ発行コマンドの処理が開始される。

ステップＳ１５００−１〜ステップＳ１５００−ｍでは、カード管理部１０２とカード発行部１０４との間で、連立コマンド１６０を構成する各ＡＰＤＵ発行コマンドの処理（セルフ発行）を行う。

まず、カード発行部１０４は、カード管理部１０２からセルフ発行トリガを入力すると、図８に示す連立コマンド１６０のうち、コマンド長１７０−１で指定された最初のＡＰＤＵ発行コマンド１６５−１（例：Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）を抽出し、カード管理部１０２内のＡＰＤＵバッファ（図示せず）にコピーする。このとき、カード発行部１０４は、カード発行部１０４内で管理する「既出コマンド数」を１だけインクリメントする。「既出コマンド数」は、連立コマンド１６０を構成するＡＰＤＵ発行コマンドが正常に処理された数を示しており、カード管理部１０２からのセルフ発行トリガを受信したときにゼロになっている必要がある。なお、既出コマンド数は、ＥＥＰＲＯＭなどの不揮発性記憶領域（図示せず）に保持されている。

カード管理部１０２は、ＡＰＤＵバッファにコピーされたＡＰＤＵ発行コマンド１６５−１（Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）を実行し、正常終了した場合は、そのレスポンスとして、正常終了を意味するステータスワード（例：９０００ｈ）をカード発行部１０４に出力する（Ｓ１５００−１）。

次に、カード発行部１０４は、カード管理部１０２からのステータスワードが正常終了を意味することを確認すると、連立コマンド１６０から次のＡＰＤＵ発行コマンド１６５−２（例：Ｌｏａｄ１）を抽出し、カード管理部１０２内のＡＰＤＵバッファにコピーする。そして、カード管理部１０２は、ＡＰＤＵバッファにコピーされたＡＰＤＵ発行コマンド１６５−２（Ｌｏａｄ１）を実行し、正常終了した場合は、そのレスポンスとして、正常終了を意味するステータスワードをカード発行部１０４に出力する（Ｓ１５００−２）。

なお、カード発行部１０４が、ＡＰＤＵバッファにＡＰＤＵ発行コマンドをコピーする際には、カード管理部１０２が以前に実行したＡＰＤＵ発行コマンドは削除することが好ましい。

以後、同様にして、カード管理部１０２は、カード発行部１０４によりＡＰＤＵバッファにコピーされた連立コマンド１６０を構成する各ＡＰＤＵ発行コマンド１６５−３〜１６５−ｍを実行していく。すなわち、カード発行部１０４で管理する「既出コマンド数」がＡＰＤＵ数１６１と一致するまで、ＡＰＤＵ発行コマンドの実行を繰り返す（Ｓ１５００−３〜Ｓ１５００−ｍ）。

なお、ＡＰＤＵ発行コマンドの処理の途中で、メモリが枯渇するなどの異常が発生した場合は、カード発行部１０４は、異常終了を意味するステータスワード（例：６Ａ８４ｈ）をカード管理部１０２に出力し、その時点でＡＰＤＵ発行コマンドの処理を中止する。

ステップＳ１６００では、カード管理部１０２が、すべてのＡＰＤＵ発行コマンドの実行が正常に終了したか、つまり、カード発行が成功したかどうかを示すレスポンスを、外部機器１５０のレスポンス受信部１５６に送信する。具体的には、カード管理部１０２は、カード発行が成功の場合には正常終了を意味するステータスワード（例：９０００ｈ）を、カード発行が失敗の場合には異常終了を意味するステータスワード（例：６Ａ８４ｈ）を外部機器１５０のレスポンス受信部１５６に送信する。

なお、外部機器１５０のセルフ発行管理部１５８では、レスポンス受信部１５６で受信したカード管理部１０２からのカード発行が成功したかどうかを示すレスポンスの内容を解析して、外部機器１５０の次の動作を決定する。

例えば、レスポンスの内容がカード発行成功であれば、セルフ発行管理部１５８は、外部機器１５０の処理を終了する旨の指示を出して、外部機器１５０は、処理を終了する。また、カード発行成功のレスポンスを確認したことを再度セキュアデバイス１００に通知した後でなければダウンロードしたアプリケーションプログラムを使用できないような場合は、セルフ発行管理部１５８は、コマンド生成部１５２に対して、「カード使用許可確認用コマンド」の発行を要求する。この場合、コマンド生成部１５２で生成された「カード使用許可確認用コマンド」が、コマンド送信部１５４を介してセキュアデバイス１００に通知された後に、外部機器１５０は、処理を終了する。

一方、レスポンスの内容がカード発行失敗であれば、セルフ発行管理部１５８は、例えば、セルフ発行開始コマンド１８０を再生成及び再送信する旨の指示をコマンド生成部１５２に出力して、図７のステップＳ１３００からの処理を再開する。また、セルフ発行管理部１５８は、カード発行処理を所定の回数だけ試行してもカード発行失敗のレスポンスを受信した場合には、カード発行を中止する旨の指示をコマンド生成部１５２に出力し、外部機器１５０は、処理を終了するようにしてもよい。このとき、カード発行処理を試行する回数は、任意である。

以上のように、カード発行のために外部機器１５０とセキュアデバイス１００との間で行われる通信は、ダイレクトアクセスによる連立コマンド１６０の書き込み、及びカード発行要求であるセルフ発行開始コマンド１８０の送受信のみである。すなわち、セルフ発行開始コマンド１８０の受信後におけるカード発行処理は、上記のステップＳ１５００−１〜ステップＳ１５００−ｍのように、カード管理部１０２とカード発行部１０４との間でＡＰＤＵ発行コマンドの処理を繰り返すことにより、セキュアデバイス１００の内部処理で完結する。

ここで、セルフ発行開始コマンド１８０を受信してからカード発行のためのＡＰＤＵ発行コマンドの読み出しを開始するまでのセキュアデバイス１００内の動作を、図１０のフローチャートを用いて説明する。

まず、ステップＳ２０００では、カード管理部１０２が、受信したコマンドのヘッダ部１８１を解析してセルフ発行開始コマンド１８０を受信したことを確認する。

そして、ステップＳ２１００では、カード管理部１０２が、カード管理部１０２内に保持するファイル管理テーブル１９０（後述）を参照して、ファイル特定情報１８２に対応するアドレスを特定する。すなわち、コマンド格納部１０６内のセキュア領域に格納されたファイルを特定する。

図１１は、ファイル管理テーブルの一例を示す図である。ファイル管理テーブル１９０には、例えば、ファイル名、ファイルパス、ファイル特定情報、ファイルサイズ、ダイレクトアクセスが可能かどうかを示す可能フラグ、及びアドレスが記述されており、それぞれの内容は、ファイルを作成したときに追加される。

次に、ステップＳ２２００では、カード管理部１０２が、セルフ発行トリガを、カード発行部１０４に対して出力する。セルフ発行トリガには、連立コマンド１６０のアドレス、オフセット１８３、及び長さ１８４が含まれる。

次に、ステップＳ２３００では、カード発行部１０４が、セルフ発行トリガに含まれる連立コマンド１６０のアドレス及びオフセット１８３から、最初のＡＰＤＵ発行コマンドの物理的な読み出し位置を特定する。

そして、ステップＳ２４００では、カード管理部１０２とカード発行部１０４との間で、連立コマンド１６０を構成する各ＡＰＤＵ発行コマンドの読み出しと実行、つまり、セルフ発行が開始される。ここで、読み出し可能な連立コマンド１６０の長さは、セルフ発行開始コマンド１８０に含まれる読み出し長さ１８４よりも小さくなくてはならない。

このようにして、セキュアデバイス１００内では、カード管理部１０２が外部機器１５０からのセルフ発行コマンドを受信した後のＡＰＤＵ発行コマンドの読み出しが開始される。

なお、本実施の形態では、外部機器１５０からのダイレクトアクセスにより書き込まれた連立コマンド１６０を構成するＡＰＤＵ発行コマンドを実行することによりカード発行を行う場合について説明したが、本発明はこれに限定されない。例えば、取得するカードの機能に対応するＡＰＤＵ発行コマンドがコマンド格納部１０６に予め格納されている場合には、外部機器１５０とセキュアデバイス１００との通信を行うことなく、セキュアデバイス１００内部でカード発行を完了することも可能である。

このように、本実施の形態によれば、セキュアデバイス内部でアプリケーションのダウンロードやカード発行処理を完結するため、外部機器とセキュアデバイスとの間の通信回数を削減して通信中断による影響を低減し、カード発行の安全性を向上することができる。

すなわち、従来は、アプリケーションダウンロード時にアプリケーションの大きさに比例して数回〜数十回発生していたカード発行における外部機器とセキュアデバイスとの間の通信回数を、本実施の形態ではダイレクトアクセスとセルフ発行開始コマンドとの２回へと減らすことができる。これにより、従来は外部機器とカード管理部との間で行われていたカード発行コマンドのやりとりを、本実施の形態ではセキュアデバイス内部で行うことができ、モバイル網利用による通信中断のリスクを大幅に減らすことができる。

また、従来技術のアプリケーションのダウンロードでは、認証時に外部機器とセキュアデバイスとの間でセッション鍵を共有し、その後、外部機器でＡＰＤＵ発行コマンドに対して暗号化やＭＡＣ付与を行い、セキュアデバイスで外部機器からのＡＰＤＵ発行コマンドに対して復号化やＭＡＣ検証を行っている。

これに対し、本実施の形態では、外部認証や内部認証によってお互いを認証した後、ダイレクトアクセスによってカード管理部のみがアクセス可能な領域に連立コマンドを格納し、この連立コマンドを利用してセキュアデバイス内部で外部にデータを出すことなく、すべて耐タンパー性を有するセキュアデバイス内部でダウンロード処理が完結する。したがって、本実施の形態では、カード発行時の盗聴や改ざんを考慮する必要がないために、暗号化やＭＡＣの付与は必要ない。この結果、カード管理部は平文を処理するだけでよく、ダウンロード処理が高速になる。

また、送信可能なＡＰＤＵ発行コマンドの全体長が固定であるために、平文の場合は、暗号化やＭＡＣの付与を行ったときに比べて１回のＡＰＤＵ発行コマンドで送信可能なデータが大きい。したがって、平文処理が適用可能な場合は、トータルのコマンド発行数も少なくなり、この点においてもダウンロード処理の高速化に有効である。

また、本実施の形態によれば、コマンド格納部に格納されるコマンド群、及びコマンド格納部のセキュア領域に書き込む連立コマンドを、自由に変更、追加又は削除することができるため、ユーザが所望するアプリケーションを有するセキュアデバイスを実現することができる。

また、本実施の形態によれば、カード発行を指示する事業者とカード発行を担当する事業者とが異なる場合において、カード発行を指示する事業者が、どのようなコマンドを用いてカードを発行したかを知ることなく、カード発行が終了するので、カード発行におけるセキュリティ保護を実現することができる。

（実施の形態２）
図１２は、本発明の実施の形態２に係るセキュアデバイスの構成を示すブロック図である。実施の形態１に係るセキュアデバイスと同じ構成要素については同一の符号を付し、その説明を省略する。

図１２において、セキュアデバイス２００は、図５のセキュアデバイス１００に対して、特権モード管理部２０２をさらに備える構成を採る。

特権モード管理部２０２は、カード管理部１０２及びカード発行部１０４と連携しており、セキュアデバイス２００に対して「特権モード」と呼ばれるモードを設定する。

特権モードとは、セキュアデバイス２００内部でのカード発行処理、つまり、カード管理部１０２とカード発行部１０４との間における連立コマンド１６０を構成するＡＰＤＵ発行コマンドの処理（セルフ発行）を最優先するモードである。特権モードが設定されている間は、セキュアデバイス２００の接触インターフェースや非接触インターフェースを介して、外部機器１５０とのデータのやりとり（例えば、セルフ発行開始コマンドやレスポンスの送受信）を行うことができない。特権モード管理部２０２が特権モードを設定するタイミングについては、後述する動作説明において詳細に説明する。

以下、上述のように構成されたセキュアデバイス２００の動作について、図１３を用いて詳細に説明する。

図１３は、本発明の実施の形態２に係る外部機器１５０、カード管理部１０２、カード発行部１０４、及び特権モード管理部２０２の処理を示すシーケンス図である。

図１３のステップＳ３０００〜ステップＳ３４００までの各処理、及びステップＳ３７００の処理は、図７のステップＳ１０００〜ステップＳ１４００までの各処理、及びステップＳ１６００の処理とそれぞれ同一であるため、その説明を省略する。

ステップＳ３５００では、カード管理部１０２からのセルフ発行トリガをカード発行部１０４が受信した後に、特権モード管理部２０２が、セキュアデバイス２００に対して特権モードを設定する。具体的には、まず、カード管理部１０２からのセルフ発行トリガを入力したカード発行部１０４が、特権モード管理部２０２に特権モードの設定を指示し、又は、カード管理部１０２が、カード発行部１０４にセルフ発行トリガを出力すると同時に特権モード管理部２０２に特権モードの設定を指示する。そして、特権モード管理部２０２は、カード管理部１０２又はカード発行部１０４からの指示を受けて、セキュアデバイス２００に対して特権モードを設定する。

なお、特権モードの設定は、必ずしもカード発行部１０４がセルフ発行トリガを受信した後に行わなくてもよい。例えば、カード管理部１０２が外部機器１５０からのセルフ発行開始コマンドを受信した後、又はカード発行部１０４がセルフ発行トリガを受信した後、所定の期間が経過した後に特権モードを設定するようにしてもよい。

ステップＳ３６００−１〜ステップＳ３６００−ｍでは、図７のステップＳ１５００−１〜ステップＳ１５００−ｍと同様に、カード管理部１０２とカード発行部１０４との間で、セルフ発行を行う。このとき、セキュアデバイス２００には特権モードが設定されているので、セキュアデバイス２００の接触インターフェースや非接触インターフェースを介しても、セキュアデバイス２００と外部機器１５０との間でデータのやりとりを行うことができない。

なお、一旦特権モードが設定され、セキュアデバイス２００が特権モードに遷移した後は、例えば、セキュアデバイス２００への電源供給停止、他のアプリケーションの選択、又は現在選択されているカード管理部１０２の再選択によって、設定された特権モードが解除される。

このように、本実施の形態によれば、セキュアデバイスに特権モードを設定し、特権モード設定期間中は、セキュアデバイスと外部機器との間でデータをやりとりすることができないので、セキュアデバイス内部でのカード発行処理を妨害されることなく、安全かつ確実に行うことができる。

（実施の形態３）
図１４は、本発明の実施の形態３に係るセキュアデバイスの構成を示すブロック図である。実施の形態２に係るセキュアデバイスと同じ構成要素については同一の符号を付し、その説明を省略する。

図１４において、セキュアデバイス３００は、図１２のセキュアデバイス２００に対して、カード発行部１０２及び特権モード管理部２０２に代えて、カード発行部３０２及び特権モード管理部３０４を備える構成を採る。

カード発行部３０２は、カードのセルフ発行中における各ＡＰＤＵ発行コマンド処理後のカード管理部１０２からのステータスワードが成功を意味するかどうかを判断するためのレスポンス判定テーブル３０６を備えている。

カード発行部３０２は、カード発行部１０２が有する機能に加えて次の機能を有する。すなわち、カード発行部３０２は、レスポンス判定テーブル３０６を参照して、セルフ発行中における各ＡＰＤＵ発行コマンドがカード管理部１０２で正常に実行されたかどうか、つまり、セルフ発行が正常に行われているかどうかを判断する。その判断の結果、セルフ発行が正常に完了したと判断した場合、又はセルフ発行中に正常に実行されていないＡＰＤＵ発行コマンドがあると判断した場合には、カード発行部３０２は、その判断結果を特権モード管理部３０４に出力する。

特権モード管理部３０４は、特権モード管理部２０２が有する機能に加えて、セキュアデバイス３００に特権モードの設定をした後、セルフ発行が正常に完了したという判断結果、又はセルフ発行が正常に実行されていないという判断結果のいずれかをカード発行部３０２から入力すると、設定された特権モードを解除する機能を有する。

以下、上述のように構成されたセキュアデバイス３００の動作について、図１５を用いて詳細に説明する。

図１５は、本発明の実施の形態３に係る外部機器１５０、カード管理部１０２、カード発行部３０２、及び特権モード管理部３０４の処理を示すシーケンス図である。

図１５のステップＳ４０００〜ステップＳ４５００までの各処理は、図１３のステップＳ３０００〜ステップＳ３５００までの各処理とそれぞれ同一であるため、その説明を省略する。

ステップＳ４６００−１〜ステップＳ４６００−ｍでは、カード管理部１０２とカード発行部３０２との間で、セルフ発行を行う。このとき、セキュアデバイス３００には特権モードが設定されているので、セキュアデバイス３００の接触インターフェースや非接触インターフェースを介しても、セキュアデバイス３００と外部機器１５０との間でデータのやりとりを行うことができない。

まず、カード発行部３０２は、カード管理部１０２からセルフ発行トリガを入力すると、図８に示す連立コマンド１６０のうち、コマンド長１７０−１で指定された最初のＡＰＤＵ発行コマンド１６５−１（例：Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）を抽出し、カード管理部１０２内のＡＰＤＵバッファにコピーする。

カード管理部１０２は、ＡＰＤＵバッファにコピーされたＡＰＤＵ発行コマンド１６５−１（Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）を実行し、正常終了した場合は、そのレスポンスとして正常終了を意味するステータスワードを、正常終了しない場合は、そのレスポンスとして異常終了を意味するステータスワードを、カード発行部３０２に通知する（Ｓ４６００−１）。

ここで、カード管理部１０２からカード発行部３０２へのレスポンスの通知方法について、図１６（Ａ）、（Ｂ）を用いて説明する。図１６（Ａ）は、カード管理部１０２からカード発行部３０２へレスポンスを通知する一例を示す図である。図１６（Ｂ）は、カード管理部１０２からカード発行部３０２へレスポンスを通知する他の一例を示す図である。

図１６（Ａ）の例では、カード管理部１０２が保持するレスポンスバッファに格納されるレスポンスデータを、カード発行部３０２が保持するレスポンスバッファにコピーすることにより、レスポンスを通知している。また、図１６（Ｂ）の例では、カード管理部１０２が保持するレスポンスバッファに格納されるレスポンスデータをカード発行部３０２が参照することにより、レスポンスを通知している。

カード発行部３０２では、レスポンス判定テーブル３０６を参照して、カード管理部１０２からのレスポンスであるステータスワードとレスポンス判定テーブル３０６とを対比することにより、ＡＰＤＵ発行コマンド１６５−１（Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）が正常に処理されたかどうかを判断する。

その判断の結果、ＡＰＤＵ発行コマンド１６５−１が正常に処理されたと判断した場合には、次のＡＰＤＵ発行コマンド１６５−２（Ｌｏａｄ１）の処理に進む。また、ＡＰＤＵ発行コマンド１６５−１が正常に処理されていないと判断した場合には、カード発行部３０２は、その判断結果を特権モード管理部３０４に送信して、特権モードの解除を要求する。

特権モード管理部３０４は、カード発行部３０２からＡＰＤＵ発行コマンド１６５−１が正常に処理されていないという判断結果、及び特権モード解除要求を受信すると、セキュアデバイス３００に設定された特権モードを解除する。特権モード解除後は、外部機器１５０との通信が可能になり、カード管理部１０２は、外部機器１５０のレスポンス受信部１５６に、カード発行失敗を意味するステータスワード（例：６Ａ８４ｈ）を送信する。

ここで、レスポンス判定テーブル３０６について、図１７を用いて説明する。図１７は、レスポンス判定テーブル３０６の一例を示す図である。

図１７の例では、レスポンス判定テーブル３０６は、通知されたレスポンスのステータスワードが「９０００ｈ」であれば、ＡＰＤＵ発行コマンドが正常に処理されたこと（成功）を意味し、通知されたレスポンスのステータスワードが「９０００ｈ以外」であれば、ＡＰＤＵ発行コマンドが正常に処理されていないこと（失敗）を意味することを示している。

以後、同様にして、カード管理部１０２とカード発行部３０２との間で、連立コマンド１６０を構成する各ＡＰＤＵ発行コマンド１６５−２〜１６５−ｍを順に処理することによりセルフ発行を行う。

そして、セルフ発行中に、正常に処理されていないＡＰＤＵ発行コマンドが発生すると、特権モードが解除される。この場合、カード管理部１０２から外部機器１５０のレスポンス受信部１５６に、カード発行失敗を意味するステータスワードが送信される（Ｓ４８００）。

一方、すべてのＡＰＤＵ発行コマンド１６５−１〜１６５−ｍが正常に処理されてセルフ発行が成功した場合も、特権モードが解除される。この場合は、カード管理部１０２から外部機器１５０のレスポンス受信部１５６に、カード発行成功を意味するステータスワードが送信される（Ｓ４８００）。

次に、本実施の形態のセルフ発行開始後におけるカード発行部３０２の動作について、図１８を用いて説明する。

図１８は、本発明の実施の形態３に係るカード発行部３０２のセルフ発行中における動作を示すフローチャートである。なお、セキュアデバイス３００には、特権モードが設定されているものとして説明する。

まず、ステップＳ５０００では、カード発行部３０２は、レスポンス解析可能な状態であり、カード管理部１０２からのＡＰＤＵ発行コマンドの処理結果を示すレスポンスを待機している。

そして、ステップＳ５１００では、カード発行部３０２は、カード管理部１０２からのＡＰＤＵ発行コマンドの処理結果を示すレスポンスの通知を受ける。

そして、ステップＳ５２００では、カード発行部３０２は、レスポンス判定テーブル３０６を参照して、ステップＳ５１００で通知されたレスポンスがＡＰＤＵ発行コマンド処理の成功を意味するかどうかを判断する。その判断の結果、レスポンスが成功を意味する場合は（Ｓ５２００：ＹＥＳ）、ステップＳ５３００へ進み、レスポンスが成功を意味しない場合は（Ｓ５２００：ＮＯ）、ステップＳ５４００へ進む。

そして、ステップＳ５３００では、カード発行部３０２は、すべてのＡＰＤＵ発行コマンドの処理が完了したかどうかを判断する。その判断の結果、すべてのＡＰＤＵ発行コマンドの処理が完了したと判断した場合は（Ｓ５３００：ＹＥＳ）、ステップＳ５４００へ進み、すべてのＡＰＤＵ発行コマンドの処理が完了していないと判断した場合は（Ｓ５３００：ＮＯ）、ステップＳ５０００に戻り、次のＡＰＤＵ発行コマンドの処理結果を示すレスポンスを待機する。

そして、ステップＳ５４００では、カード発行部３０２は、正常に処理されていないＡＰＤＵ発行コマンドがあること、又はすべてのＡＰＤＵ発行コマンドの処理が完了したことを特権モード管理部３０４に送信するとともに、設定された特権モードの解除要求を行う。

このように、本実施の形態によれば、すべてのＡＰＤＵ発行コマンドが処理されてセルフ発行が成功したタイミング、又はＡＰＤＵ発行コマンドが正常に処理されずセルフ発行が失敗したタイミングで特権モードを解除するので、外部機器へのセルフ発行処理結果の通知を速やかに行うことができる。

（実施の形態４）
図１９は、本発明の実施の形態４に係るセキュアデバイスの構成を示すブロック図である。実施の形態１に係るセキュアデバイスと同じ構成要素については同一の符号を付し、その説明を省略する。

図１９において、セキュアデバイス４００は、図５のセキュアデバイス１００に対して、カード発行部１０４に代えて、カード発行部４０２を備える構成を採る。

カード発行部４０２は、セルフ発行中に、カード発行の失敗を検出した場合に、カード発行の失敗を意味する旨の情報と、「セルフ発行がどこまで成功していたのか」を示す情報とを含むレスポンスを演算するレスポンス演算部４０４を備えている。

カード発行部４０２は、カード発行部１０４が有する機能に加えて次の機能を有する。すなわち、カード発行部４０２は、セルフ発行における各ＡＰＤＵ発行コマンドの処理の進捗状況を監視して、ＡＰＤＵ発行コマンドが正常に実行されず、セルフ発行が失敗したときに、異常終了によりカード発行が失敗したことを意味するステータスワードとともに、「セルフ発行がどこまで成功していたのか」を示す情報を、カード管理部１０２に送信する。

「セルフ発行がどこまで成功していたのか」を示す情報は、例えば、正常に処理されたＡＰＤＵ発行コマンドの数、処理に失敗したＡＰＤＵ発行コマンドのヘッダ部、及び、残りのＡＰＤＵ発行コマンドの数などの様々な情報を含む。すなわち、「セルフ発行がどこまで成功していたのか」を示す情報は、正常に実行されたカード発行コマンドを特定する情報を得ることができる情報である。

本実施の形態では、「セルフ発行がどこまで成功していたのか」を示す情報の一例として、正常に処理されたＡＰＤＵ発行コマンドの数を用いることとし、この情報から正常に実行されたカード発行コマンドを特定する情報を得る場合について説明する。

すなわち、本実施の形態のレスポンス演算部４０４は、セルフ発行が失敗した場合、それまでに正常に処理されたＡＰＤＵ発行コマンドの数を用いて、「セルフ発行がどこまで成功していたのか」を示す情報を含むレスポンスを演算する。

レスポンス演算部４０４によるレスポンスの演算について、図２０を用いて説明する。図２０は、レスポンス演算部４０４の入出力を示す図である。

図２０において、レスポンス演算部４０４は、カード管理部１０２からＡＰＤＵ発行コマンドが正常に実行されたというレスポンスをうけると、カード発行部４０２で管理する「既出コマンド数」を１だけインクリメントして、次のＡＰＤＵ発行コマンドの処理に移行する。また、セルフ発行開始時における「既出コマンド数」は、ゼロであるため、ＡＰＤＵ発行コマンドが正常に実行されず、セルフ発行が失敗したときの「既出コマンド数」が、その時点までに正常に処理されたＡＰＤＵ発行コマンド数を示す値となる。したがって、外部機器１５０へのレスポンスに、セルフ発行が失敗した旨とともに、セルフ発行が失敗した時点までに正常に処理されたＡＰＤＵ発行コマンドの数、つまり、「セルフ発行がどこまで成功していたのか」を示す情報を含むことができる。

次に、図１９の外部機器４５０の構成について、図２１を用いて説明する。図２１は、図１９の外部機器４５０の構成を示すブロック図である。

図２１において、外部機器４５０は、図６の外部機器１５０に対して、セルフ発行管理部１５８に代えて、セルフ発行管理部４５２を備えている。

セルフ発行管理部４５２は、セルフ発行中に処理される各ＡＰＤＵ発行コマンドと各ＡＰＤＵ発行コマンドに対する処理内容とを対応付けて格納する進捗管理テーブル４５４を備えている。

セルフ発行管理部４５２は、セルフ発行管理部１５８が有する機能に加えて、セルフ発行が失敗したというレスポンスを受信した場合において、正常に実行されなかったＡＰＤＵ発行コマンドを特定して、当該ＡＰＤＵ発行コマンドの処理から開始する旨の指示を出す機能を有する。

以下、本実施の形態のセルフ発行開始後におけるカード発行部４０２の動作について、図２２のフローチャートを用いて説明する。

まず、ステップＳ６０００では、カード発行部４０２は、レスポンス解析可能な状態であり、カード管理部１０２からのＡＰＤＵ発行コマンド処理結果を示すレスポンスを待機している。

そして、ステップＳ６１００では、カード発行部４０２は、カード管理部１０２からのＡＰＤＵ発行コマンド処理結果を示すレスポンスの通知を受ける。

そして、ステップＳ６２００では、カード発行部４０２は、ステップＳ６１００で通知されたレスポンスがＡＰＤＵ発行コマンド処理の成功を意味するかどうかを判断する。その判断の結果、レスポンスが成功を意味する場合は（Ｓ６２００：ＹＥＳ）、ステップＳ６３００へ進み、レスポンスが成功を意味しない場合は（Ｓ６２００：ＮＯ）、ステップＳ６５００へ進む。

そして、ステップＳ６３００では、カード発行部４０２は、すべてのＡＰＤＵ発行コマンドの処理が完了したかどうかを判断する。その判断の結果、すべてのＡＰＤＵ発行コマンドの処理が完了したと判断した場合は（Ｓ６３００：ＹＥＳ）、ステップＳ６４００へ進み、すべてのＡＰＤＵ発行コマンドの処理が完了していないと判断した場合は（Ｓ６３００：ＮＯ）、ステップＳ６０００に戻り、次のＡＰＤＵ発行コマンドの処理結果を示すレスポンスを待機する。

そして、ステップＳ６４００では、カード発行部４０２は、すべてのＡＰＤＵ発行コマンドの処理が完了してセルフ発行が成功したことを示すレスポンスを生成する。

一方、ステップＳ６５００では、正常処理されていないＡＰＤＵ発行コマンドがありセルフ発行が失敗したことを示すレスポンスを生成する。このレスポンスには、セルフ発行失敗時点での既出コマンド数、つまり、セルフ発行失敗時点までに正常に処理されたＡＰＤＵ発行コマンドの数が含まれる。

ここで、ステップＳ６５００で生成するレスポンスについて、図２３を用いて説明する。図２３は、セルフ発行が失敗したことを示すレスポンスのフォーマットの一例を示す図である。

図２３において、レスポンス４１０は、セルフ発行処理の進捗状況を示す既出コマンド数４１１と、セルフ発行処理が失敗したことを示すステータスワード４１２とからなる。

なお、レスポンスのフォーマットとしては、図２３に示す以外にも、例えば、２バイトからなるステータスワードのいずれかのビットを利用したもの（例：６３ＣＸｈ（Ｘが既出コマンド数））を用いてもよい。

そして、ステップＳ６６００では、カード発行部４０２は、ステップＳ６４００又はステップＳ６５００で生成したレスポンスをカード管理部１０２へ出力する。このレスポンスは、カード管理部１０２から外部機器４５０のレスポンス受信部１５６へ送信される。

次に、セキュアデバイス４００からのセルフ発行が成功したかどうかを示すレスポンスを受信した後の外部機器４５０の動作について、図２４のフローチャートを用いて説明する。

まず、ステップＳ７０００では、レスポンス受信部１５６が、カード管理部１０２からのセルフ発行が成功したかどうかを示すレスポンスを受信する。受信したレスポンスは、セルフ発行管理部４５２に出力される。

そして、ステップＳ７１００では、セルフ発行管理部４５２が、ステップＳ７０００で受信したレスポンスがセルフ発行の成功を意味するかどうかを判断する。この判断は、具体的には、セルフ発行管理部４５２が、レスポンスに含まれるステータスワードを参照することにより行われる。

判断の結果、セルフ発行管理部４５２が、レスポンスはセルフ発行の成功を意味すると判断した場合は（Ｓ７１００：ＹＥＳ）、外部機器４５０の処理を終了する。このとき、セルフ発行の成功を意味するレスポンスを受信したことを再度セキュアデバイス４００に通知した後でなければダウンロードしたアプリケーションプログラムを使用できない場合は、外部機器４５０は、「カード使用許可確認用コマンド」を生成し、セキュアデバイス４００に送信して処理を終了する。一方、レスポンスがセルフ発行の成功を意味しないと判断した場合は（Ｓ７１００：ＮＯ）、ステップＳ７２００へ進む。

そして、ステップＳ７２００では、セルフ発行管理部４５２が、セルフ発行開始コマンドを再送信するかどうかを判断する。その判断の結果、セルフ発行開始コマンドを再送信しないと判断した場合は（Ｓ７２００：ＮＯ）、ステップＳ７３００へ進み、セルフ発行開始コマンドを再送信すると判断した場合は（Ｓ７２００：ＹＥＳ）、ステップＳ７４００へ進む。

なお、セキュアデバイス４００が何らかの理由（例えば、セキュアデバイス４００内のメモリが壊れている）によりリカバリ不可能な状態である場合は、ステップＳ７２００では、セルフ発行管理部４５２は、何もしない。

そして、ステップＳ７３００では、セルフ発行管理部４５２は、進捗管理テーブル４５４を参照して、セルフ発行中に書き込んだデータ（正常処理されたＡＰＤＵ発行コマンド）をクリアするための「クリアコマンド」を生成し、セキュアデバイス４００に送信して処理を終了する。

ここで、進捗管理テーブル４５４について、図２５を用いて説明する。図２５は、進捗管理テーブル４５４の一例を示す図である。

進捗管理テーブル４５４には、セキュアデバイス４００からのレスポンスに含まれる「既出コマンド数」と、その「既出コマンド数」に対応する外部機器４５０の処理内容とが、「既出コマンド数」毎に記載されている。

図２５において、セキュアデバイス４００内のセルフ発行では、ｎ番目のＡＰＤＵ発行コマンドが正常処理されなかったことを意味している。ここで、ｎは、１≦ｎ≦ｍ（ｍ：ＡＰＤＵ発行コマンドの数）を満たす整数である。この場合、ステップＳ７３００では、正常処理されたｎ番目までのＡＰＤＵ発行コマンド（発行中に書き込んだすべてのデータ）をクリアするためのクリアコマンドを送信する。

また、ステップＳ７４００では、進捗管理テーブル４５４を参照して、正常処理されなかったＡＰＤＵ発行コマンドを特定し、当該ＡＰＤＵ発行コマンドの処理から開始する旨のセルフ発行開始コマンドを再送信して処理を終了する。

図２５の例においては、ｎ番目のＡＰＤＵ発行コマンドが正常処理されていないため、ｎ番目のＡＰＤＵ発行コマンドから処理を開始する旨のセルフ発行開始コマンドを再送信する。

なお、セキュアデバイス４００が、上記セルフ発行コマンドを受信しても、その実装上の理由などにより、正常処理されなかったＡＰＤＵ発行コマンドから処理を開始することができないときは、カード発行を最初から開始するためのセルフ発行開始コマンドが再送される。

このように、本実施の形態によれば、セルフ発行が失敗した場合でも、セルフ発行がどこまで成功していたのかを示すセルフ発行の進捗状況を外部機器に通知するため、外部機器は、正常処理されなかったＡＰＤＵ発行コマンドから処理を開始するセルフ発行開始コマンドを再送信することができ、重複する無駄なセルフ発行処理を省略することができる。

（実施の形態５）
上記各実施の形態（実施の形態１〜４）では、セルフ発行開始コマンドを受信したカード発行部が連立コマンドを格納するファイルを特定し、ファイルに含まれるＡＰＤＵ発行コマンドを抽出して、一旦、カード管理部１０２内のＡＰＤＵバッファにコピーすることによって、カード管理部は、ＡＰＤＵ発行コマンドが外部機器から接触インターフェースや非接触インターフェースを介して送信されたものか、セルフ発行によるものかを区別することなくＡＰＤＵ発行コマンドを実行する方法について説明した。

本実施の形態では、接触インターフェースや非接触インターフェースを利用する際のＡＰＤＵバッファと、セルフ発行時のＡＰＤＵバッファとを共有しない形態について説明する。

図２６は、本発明の実施の形態５に係るセキュアデバイスの構成を示すブロック図である。実施の形態１に係るセキュアデバイスと同じ構成要素については同一の符号を付し、その説明を省略する。

図２６において、セキュアデバイス５００は、図５のセキュアデバイスの構成に対して、カード管理部１０２、カード発行部１０４及びコマンド格納部１０６に代えて、カード管理部５０２、カード発行部５０４及びコマンド格納部５０６を備える構成を採る。

カード管理部５０２は、外部機器１５０から接触インターフェースや非接触インターフェースを利用して書き込まれたカード発行を実行するＡＰＤＵ発行コマンドを格納するＡＰＤＵバッファ５０８を備えている。

カード発行部５０４は、コマンド格納部５０６に格納された連立コマンドのうち、後述する連立コマンド用ＡＰＤＵバッファ５１２により指定された領域をカード管理部５０２が直接参照するための直接参照部５１０を備えている。

コマンド格納部５０６は、格納された連立コマンドの領域の一部を、連立コマンド用のＡＰＤＵバッファとして指定する連立コマンド用ＡＰＤＵバッファ５１２を備えている。

まず、本実施の形態における連立コマンド５２０について、図２７を用いて説明する。図２７は、本発明の実施の形態５に係る連立コマンド５２０の構成の一例を示す図である。なお、図２７は、最初のＡＰＤＵ発行コマンド（Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）を処理する場合の連立コマンドの構成の一例である。

図２７において、連立コマンド５２０は、連立コマンド５２０がいくつのＡＰＤＵ発行コマンドから構成されるかを示すＡＰＤＵ数５２１とコマンド実体部５２２とからなる。図２７の例では、ＡＰＤＵ数５２１は、２である。

コマンド実体部５２２は、ＡＰＤＵ発行コマンド（１−ａ）５２５−１，（２−ａ）５２５−２からなるデータと、これらのＡＰＤＵ発行コマンドがそれぞれ何バイトで構成されているかを示すコマンド長５３０−１，５３０−２とからなる。それぞれの役割については、後述する。

以下、上述のように構成されたセキュアデバイス５００の動作について説明する。

まず、外部機器１５０は、カード管理部５０２のＡＰＤＵバッファ５０８に、カード発行を実行するＡＰＤＵ発行コマンドを書き込む。

次いで、カード管理部５０２は、外部機器１５０からのセルフ発行開始コマンドを受信すると、カード発行部５０４に対してセルフ発行トリガを出力する。このセルフ発行トリガは、カード発行部５０４にとって、セルフ発行を開始するためのトリガとなる。

カード発行部５０４は、カード管理部５０２からのセルフ発行トリガを入力すると、例えば、図２７のコマンド長５３０−１で指定された長さだけ連立コマンド５２０から最初のＡＰＤＵ発行コマンド（例：Ｉｎｓｔａｌｌ Ｆｏｒ Ｌｏａｄ）５２５−１を抽出し、コマンド格納部５０６内に、このＡＰＤＵ発行コマンドの長さ分の領域をＡＰＤＵバッファとして指定する。

このとき、セキュアデバイス５００内には、外部機器１５０からのＡＰＤＵ発行コマンドを格納するＡＰＤＵバッファ５０８と、連立コマンド用ＡＰＤＵバッファ５１２が共存する状態となる。すなわち、外部機器１５０からのＡＰＤＵ発行コマンドを格納するＡＰＤＵバッファは、カード管理部５０２に属し、連立コマンド用ＡＰＤＵバッファ５１２は、カード格納部５０６に属する。

図２７の例では、最初のＡＰＤＵ発行コマンド（１−ａ）５２５−１を処理する場合には、ＡＰＤＵ発行コマンド（１−ａ）５２５−１が占める領域（指定された領域）自体が連立コマンド用ＡＰＤＵバッファ５１２となる。

外部機器１５０からのＡＰＤＵ発行コマンドを格納するＡＰＤＵバッファ５０８が固定領域として永続するのに対して、連立コマンド用ＡＰＤＵバッファ５１２は、あるＡＰＤＵ発行コマンドを処理する瞬間のみ、そのＡＰＤＵ発行コマンドが入っている領域（指定された領域）を占めるものであり、次のＡＰＤＵ発行コマンドを処理する毎に時々刻々と領域のアドレスや大きさが変化する。すなわち、最初のＡＰＤＵ発行コマンド（１−ａ）５２５−１が処理されたら、次のＡＰＤＵ発行コマンド（２−ａ）５２５−２が占める領域自体が連立コマンド用ＡＰＤＵバッファ５１２となる。

ここで実施の形態１における連立コマンド１６０を示す図８と本実施の形態における連立コマンド５２０を示す図２７とを比較する。

図８において、ＬＯＡＤコマンドは発行コマンド２から発行コマンドｍに分割されている。例えば、ダウンロード対象のデータが２０００キロバイトであった場合、一回で送信可能な、つまり、ＡＰＤＵバッファ５０８に格納可能なデータ長の最大が２５５バイトとすると（ただし平文の場合。暗号化やＭＡＣ付与の場合はより短くなる。）、２５５×７＜２０００＜２５５×８となり、８コマンドに分割して送る必要があるため、ｍ＝９となる。

これに対し、図２７においては、Ｌｏａｄコマンドを連立コマンド用ＡＰＤＵバッファ５１２で指定することで、１回の処理で完結することができる。すなわち、連立コマンド用ＡＰＤＵバッファ５１２は、常に、連立コマンドのうち、まさに処理しようとしているＡＰＤＵ発行コマンド（指定された領域）のみであり、この連立コマンド用ＡＰＤＵバッファ５１２に指定された領域を直接参照部５１０が参照して処理した後、次に処理すべきＡＰＤＵ発行コマンド（指定された領域）のみが連立コマンド用ＡＰＤＵバッファ５１２となる。

カード管理部５０２のダウンロードを管理する機能（カードマネージャ）は、カード管理部５０２のＡＰＤＵバッファ５０８からデータを取得する場合と同様に、直接参照部５１０を介することで連立コマンド用ＡＰＤＵバッファ５１２からデータを取得する。いずれの場合も、カードマネージャの挙動としては、ＡＰＤＵバッファにアクセスする点で等価な処理となる。

次に、実施の形態１の場合のように、複数回に分けてＬｏａｄコマンドを受信する場合と、本実施の形態の場合のように、一回でＬｏａｄコマンドを受信する場合とのカードマネージャの動作を比較して説明する。

複数回にわけてＬｏａｄコマンドを処理する場合、ＡＰＤＵ発行コマンドの数、ＡＰＤＵ発行コマンドの受信処理、ＡＰＤＵバッファからのデータ取得処理、そのコマンドが正しい順番で送られてきているか又は最後のコマンドであるかのコマンドチェック、データの処理、次のＡＰＤＵ発行コマンドを処理するための中間状態の保持、及びレスポンス送信処理が必要となる。

一方、Ｌｏａｄコマンドを１回で処理する場合、上記一連の処理が不要になるという利点がある。

直接参照部５１０を利用するタイミングとしては、セルフ発行開始コマンドを受信した後にカード管理部５０２から直接参照部５１０に要求するタイミングやカード発行部５０４がセルフ発行トリガを受信した後に直接参照部５１０に要求するタイミングが考えられる。

なお、実施の形態２又は実施の形態３のように、セキュアデバイスに特権モードを設定可能として、特権モード設定期間中にのみ、直接参照部５１０を利用するようにしてもよい。

このように、本実施の形態によれば、直接参照部を介することにより、ＡＰＤＵ発行コマンドを分割して処理する場合と比較して、ＡＰＤＵ発行コマンド毎に行う必要のある定型処理を大幅に減らし、また次のＡＰＤＵ発行コマンドの処理のための冗長な処理を省略することができる。したがって、外部機器からＡＰＤＵ発行コマンドを複数回にわけてダウンロードする従来の手法に比して、大幅な高速化が可能となる。

読み／書き機能を有する携帯電話等の可搬性の高いモバイル端末を用いてセキュアデバイスにアプリケーションをダウンロードする場合、一般的に電源となる電池容量が有限であることからも、カード発行の高速化の意義は大きい。

さらには、セキュアデバイスが携帯電話に抜き差しできるリムーバブルメディアの場合、ユーザが突然電源を切るケースやダウンロード処理途中にセキュアデバイスを抜くことによるセキュアデバイスへの電源供給停止が起こりうる。これらのケースにおいても、高速処理できることはユーザの誤った操作の影響をうける可能性が小さくなることを意味するため意義は大きい。

（実施の形態６）
図２８は、本発明の実施の形態６に係るセキュアデバイスの構成を示すブロック図である。実施の形態１に係るセキュアデバイスと同じ構成要素については同一の符号を付し、その説明を省略する。

セルフ発行の途中にカードへの電源供給がなくなると、セキュアデバイスはカード発行を中止し、レスポンスを外部機器に送信することができない。よって、外部機器は、セキュアデバイスにおけるカード発行の進捗状況を知ることができない。本実施の形態では、このような場合であっても、電源断が起き、カード発行が中止したＡＰＤＵ発行コマンド又はこれに近いＡＰＤＵ発行コマンドを特定し、特定したＡＰＤＵ発行コマンドから、カード発行を再開することができる。

図２８において、セキュアデバイス６００は、図５のセキュアデバイスの構成に対して、カード管理部１０２及びカード発行部１０４に代えて、カード管理部６０２及びカード発行部６０４を備える構成を採る。

カード管理部６０２は、セルフ発行中に処理されたＡＰＤＵ発行コマンド数を示す既出コマンド数を監視することにより、電源が切断されるなどの理由によるセルフ発行の中断の履歴を保持する中断履歴送信部６０６を備えている。

カード管理部６０２は、カード管理部１０２が有する機能に加えて、電源が切断されるなどの理由によるセルフ発行の中断の履歴を保持して、後述するカード発行部６０４のリカバリ部６０８に出力する機能を有する。上記のように、セルフ発行の中断の履歴は、既出コマンド数を監視することにより保持されるので、セルフ発行の中断履歴から、中断により外部機器１５０に処理結果を送信することができなかった最初のＡＰＤＵ発行コマンドを特定することが可能である。

カード発行部６０４は、中断履歴送信部６０６から入力したセルフ発行の中断の履歴から、セルフ発行における再開対象のＡＰＤＵ発行コマンドを特定するリカバリ部６０８を備えている。

カード発行部６０４は、カード発行部１０４が有する機能に加えて、電源が切断されるなどの理由によりセルフ発行が中断した後、セルフ発行を再開した場合に、セルフ発行を再開すべきＡＰＤＵ発行コマンドを特定し、そのＡＰＤＵ発行コマンドから処理を再開する機能を有する。

以下、上述のように構成されたセキュアデバイス６００の動作について、図２９のフローチャートを用いて説明する。

図２９は、本発明の実施の形態６に係るセキュアデバイスの動作を示すフローチャートである。なお、図２９の例では、セルフ発行時に、セキュアデバイス６００の電源が切断されてセルフ発行が中断され、その後、セキュアデバイス６００の電源が再投入されたものとして説明する。

まず、ステップＳ８０００では、セルフ発行中にセキュアデバイス６００の電源が切断される。電源の切断が検知されたとき、カード管理部６０２は、セルフ発行の中断の履歴を保持している。セルフ発行の中断の履歴には、ＡＰＤＵ発行コマンドの処理結果を示すレスポンスのうち、中断により外部機器１５０に処理結果を送信することができなかった最初のＡＰＤＵ発行コマンドを特定可能な情報が含まれている。なお、電源の切断の検知は、例えば、セッションタイムアウトを利用することにより行われる。

そして、ステップＳ８１００では、切断されていたセキュアデバイス６００の電源が再投入される。

そして、ステップＳ８２００では、カード管理部６０２が、外部機器１５０からのセルフ発行開始コマンドを受信する。

そして、ステップＳ８３００では、カード管理部６０２が、カード管理部６０２で管理する既出コマンド数がゼロであるかどうかを判断する。その判断の結果、既出コマンド数がゼロであると判断した場合は（Ｓ８３００：ＹＥＳ）、ステップＳ８４００へ進み、既出コマンドがゼロでないと判断した場合は（Ｓ８３００：ＮＯ）、ステップＳ８５００へ進む。上記のように、既出コマンド数は、正常に処理されたＡＰＤＵ発行コマンドの数を示している。よって、電源再投入時に既出コマンド数がゼロでないことは、ステップＳ８０００の電源の切断時において、セキュアデバイス６００のセルフ発行が中断されたことを意味する。

そして、ステップＳ８４００では、最初のＡＰＤＵ発行コマンドから処理をすることにより、実施の形態１と同様のセルフ発行を開始する。

一方、ステップＳ８５００では、カード管理部６０２が、カード発行部６０４のリカバリ部６０８に、中断履歴送信部６０６が保持するセルフ発行の中断の履歴を送信する。

そして、ステップＳ８６００では、カード発行部６０４のリカバリ部６０８が、セルフ発行を再開するための最初の処理対象のＡＰＤＵ発行コマンドの読み出し位置を特定する。

ここで、リカバリ部６０８による最初の処理対象のＡＰＤＵ発行コマンドの特定処理について、図３０及び図３１を用いて説明する。

図３０は、本発明の実施の形態６に係る連立コマンド６１０の構成の一例を示す図である。

図３０の連立コマンド６１０は、図８の連立コマンド１６０の構成において、リカバリ情報６２０をさらに備える。その他の構成については、図８の連立コマンド１６０と同一であるため、その説明を省略する。

図３１は、図３０の連立コマンドに含まれるリカバリ情報６２０の構成の一例を示す図である。

図３１において、リカバリ情報６２０は、リカバリ情報６２０の長さを示すリカバリ情報長６３０、コマンド番号６４０−１，６４０−２，…，６４０−ｍ、及び、オフセット６５０−１，６５０−２，…，６５０−ｍから構成される。コマンド番号とオフセットとは、それぞれ対になって、複数設定されている。

コマンド番号６４０−１〜６４０−ｍは、セルフ発行再開時にどのＡＰＤＵ発行コマンドから処理を開始するかを示す情報である。オフセット６５０−１〜６５０−ｍは、コマンド番号６４０−１〜６４０−ｍで特定されるＡＰＤＵ発行コマンドが連立コマンド６１０のどの位置から始まっているのかを示す情報である。

リカバリ部６０８は、カード管理部６０２からのセルフ発行の中断の履歴を参照すれば、セルフ発行を再開するために最初に処理すべきＡＰＤＵ発行コマンドのコマンド番号を特定することができる。そして、リカバリ部６０８は、上記リカバリ情報６２０を用いて、連立コマンド６１０のうち、最初に処理すべきＡＰＤＵ発行コマンドの物理的な読み出し位置を特定する。

ここでは、リカバリ情報６２０を参照することでＡＰＤＵ発行コマンドの読み出し位置を決定するようにしたが、図８のようなリカバリ情報６２０を有しない連立コマンド１６０を先頭から解析することにより、読み出し位置を特定することも可能である。例えば、図８において、既出コマンド数が２であれば、まず、コマンド長１７０−１が存在するアドレスを特定して、指定された長さをアドレスに加え、次いで、コマンド長１７０−２が存在するアドレスを特定して、その後に続くＡＰＤＵ発行コマンド１６５−２の読み出し位置を決定することができる。

そして、ステップＳ８７００では、ステップＳ８６００で特定したＡＰＤＵ発行コマンドから処理を開始して、セルフ発行を開始する。

以上説明した、図２９に示すリカバリ処理は、それまでに確保した領域や格納したデータはそのままで、電源の切断が起きたＡＰＤＵ発行コマンドからやり直しができる場合（コマンド単位でリカバリ処理が可能な場合）である。

リカバリ処理には、この他にも、セキュアデバイスの実装に依存した以下のパターンが考えられる。

第１に、電源の切断が発生した後に、電源が再投入されたときや外部機器からのセルフ発行要求を受け取ったときに、電源の切断が生じるまでにセキュアデバイス内で処理したデータ（確保した領域や格納したデータ）をすべてクリアする場合が考えられる。

この場合のリカバリ処理は、カード発行を最初からやり直すことになる。このような実装を施したセキュアデバイスは、カード管理部が管理する既出コマンド数は、ＲＡＭなどの一次記憶領域に格納しておけばよい。また、外部機器も、電源の切断発生後に、ユーザからのカード発行が要求されたときにセルフ発行コマンドを送信すればよい。

第２に、あるＡＰＤＵ発行コマンドの処理以前にセキュアデバイス内で処理したデータ（確保した領域や格納したデータ）はそのままで、あるＡＰＤＵ発行コマンド以降からやり直しができる場合（機能単位でリカバリ処理可能な場合）が考えられる。

この場合のリカバリ処理は、機能単位毎に正常処理されたＡＰＤＵ発行コマンドをそのまま保持して、その後のＡＰＤＵ発行コマンドから処理を再開する。したがって、セルフ発行中断時に正常処理されたＡＰＤＵ発行コマンドを再度処理する必要が生じる場合もあるが、カード発行という処理の観点からは好ましい。

機能単位でリカバリ処理を行う場合の具体例を以下に示す。

例えば、図３１において、コマンド番号１（６４０−１）に「１」、コマンド番号（６４０−２）に「２」がそれぞれ設定されているとする。

図３０において、発行コマンド３（Ｌｏａｄ２）１６５−３は、３番目のＡＰＤＵ発行コマンドであり、この発行コマンドを実行しているときに電源断が発生した場合、カード管理部１０２が管理する既出コマンド数は「３」のままＥＥＰＲＯＭなどの不揮発性記憶領域に保持されている。

この場合、図２９のステップＳ８６００では、既出コマンド数「３」を入力したリカバリ部８０６が、既出コマンド数「３」と、コマンド番号１（６４０−１）に設定されている「１」、コマンド番号（６４０−２）に設定されている「２」とを比較して、これらが、１＜２＜３の関係になることから「３」より小さく、「３」に最も近い「２」の発行コマンドの実行から再開することを決定する。

そして、カード発行部６０４は、コマンド番号「２」に該当する発行コマンド２（Ｌｏａｄ１）１６５−２を抽出してＡＰＤＵバッファにコピーし、カード発行が開始される。

なお、本実施の形態では、セルフ発行開始コマンドを受信したタイミングで既出コマンドがゼロかどうかを判断し、セルフ発行を再開するようにしたが、これに限定されない。例えば、セルフ発行の中断が終了したとき（例：電源再投入時）に、既出コマンドがゼロかどうかを判断し、セルフ発行を再開するようにしてもよい。

このように、本実施の形態では、セキュアデバイスの電源が切断されるなどの理由によりセルフ発行が中断した場合においても、セキュアデバイス内で中断の履歴を保持するので、セルフ発行再開時に、最適なＡＰＤＵ発行コマンドの読み出し位置を特定することができる。

すなわち、カード管理部に中断履歴送信部を、カード発行部にリカバリ部をそれぞれ備えることで、セルフ発行途中にカードへの電源供給がなくなった場合の事後処理において再試行が可能となる。また、外部機器は、セキュアデバイスへの電源供給が再開されたときのセルフ発行の進捗状況を意識することなく再試行を実行することができるため、カード発行の負荷を減少することができる。

以上、上記各実施の形態で説明したように、本発明のセキュアデバイス及び外部機器は、外部機器からセキュアデバイスへ１度の指示を出すことにより、後はセキュアデバイス内で自立的に処理を実行することができるので、カードとの間の通信状態が不良な状態でのカード発行や、ユーザが持っている携帯端末機器を利用して個人が自由にカード発行することに適している。

本願は、２００５年１月１１日出願の特願２００５−００３５９６に基づく優先権を主張する。当該出願明細書に記載された内容はすべて、本願明細書に援用される。

本発明のセキュアデバイスは、外部機器との通信中断による影響を低減し、ユーザが所望するアプリケーションプログラムを、高速かつ安全に取り入れることができる効果を有し、通信接続された外部機器からの指示を受けてカード発行処理を行うセキュアデバイスとして有用である。

ＩＣカードのハードウェアに関する機能ブロック図 ＡＰＤＵコマンドのフォーマットの一例を示す図 データを分割してＡＰＤＵを作成する方式を示す概念図 従来のＩＣカードアプリケーションプログラムロード装置の構成を示すブロック図 本発明の実施の形態１に係るセキュアデバイスの構成を示すブロック図 図５の外部機器の構成を示すブロック図 本発明の実施の形態１に係る外部機器、カード管理部及びカード発行部の処理を示すシーケンス図 連立コマンドの構成の一例を示す図 セルフ発行開始コマンドの形式の一例を示す図 セルフ発行開始コマンドを受信してからカード発行のためのＡＰＤＵ発行コマンドの読み出しを開始するまでのセキュアデバイス内部の動作を示すフローチャート ファイル管理テーブルの一例を示す図 本発明の実施の形態２に係るセキュアデバイスの構成を示すブロック図 本発明の実施の形態２に係る外部機器、カード管理部、カード発行部、及び特権モード管理部の処理を示すシーケンス図 本発明の実施の形態３に係るセキュアデバイスの構成を示すブロック図 本発明の実施の形態３に係る外部機器、カード管理部、カード発行部、及び特権モード管理部の処理を示すシーケンス図 （Ａ）カード管理部からカード発行部へレスポンスを通知する一例を示す図、（Ｂ）カード管理部からカード発行部へレスポンスを通知する他の一例を示す図 レスポンス判定テーブルの一例を示す図 本発明の実施の形態３に係るカード発行部のセルフ発行中における動作を示すフローチャート 本発明の実施の形態４に係るセキュアデバイスの構成を示すブロック図 レスポンス演算部の入出力を示す図 図１９の外部機器の構成を示すブロック図 本発明の実施の形態４に係るカード発行部のセルフ発行中における動作を示すフローチャート セルフ発行が失敗したことを示すレスポンスのフォーマットの一例を示す図 本発明の実施の形態４に係るセキュアデバイスからのレスポンスを受信した後の外部機器の動作を示すフローチャート 進捗管理テーブルの一例を示す図 本発明の実施の形態５に係るセキュアデバイスの構成を示すブロック図 本発明の実施の形態５に係る連立コマンドの構成の一例を示す図 本発明の実施の形態６に係るセキュアデバイスの構成を示すブロック図 本発明の実施の形態６に係るセキュアデバイスの動作を示すフローチャート 本発明の実施の形態６に係る連立コマンドの構成の一例を示す図 図３０の連立コマンドに含まれるリカバリ情報の構成の一例を示す図

Claims (11)

1. 内部メモリに格納されたコマンド群を直接参照する直接参照部を有し、前記コマンド群から、取得するカードの機能に対応するカード発行コマンドを抽出するカード発行部と、
   前記直接参照部を介して前記カード発行コマンドを実行するカード管理部と、
   を有するセキュアデバイス。
2. 前記コマンド群は、外部機器から前記内部メモリに対するダイレクトアクセスにより書き込まれる、
   請求項１記載のセキュアデバイス。
3. 前記カード管理部は、外部機器からの要求に基づいて前記カード発行コマンドの実行を開始し、前記カード発行が成功したかどうかを示すレスポンスを前記外部機器に送信する、
   請求項１記載のセキュアデバイス。
4. 前記カード管理部と外部機器との間で通信を行うことができないモードである特権モードを設定する特権モード管理部をさらに有し、
   前記特権モード管理部は、前記カード発行コマンドの実行が開始されるタイミングで前記特権モードを設定する、
   請求項１記載のセキュアデバイス。
5. 前記カード発行部は、前記カード管理部においてすべてのカード発行コマンドが正常に実行されたかどうかを判断し、すべてのカード発行コマンドが正常に実行されたと判断した場合、又は正常に実行されていないカード発行コマンドがあると判断した場合は、特権モード解除要求を前記特権モード管理部に出力し、
   前記特権モード管理部は、前記カード発行部から特権モード解除要求を入力すると特権モードを解除する、
   請求項４記載のセキュアデバイス。
6. 前記カード発行部は、前記カード管理部において各カード発行コマンドが正常に実行されたかどうかを監視し、正常に実行されていないカード発行コマンドが発生した場合に正常に実行されたカード発行コマンドを特定する情報を前記カード管理部に出力し、
   前記カード管理部は、正常に実行されていないカード発行コマンドが発生したこと、及び前記正常に実行されたカード発行コマンドを特定する情報を含むレスポンスを前記外部機器に送信する、
   請求項３記載のセキュアデバイス。
7. 前記カード管理部は、前記カード発行コマンドの実行における中断履歴を保持し、前記外部機器へのレスポンスを送信していない最初のカード発行コマンドを前記カード発行部へ通知し、
   前記カード発行部は、前記中断履歴と、前記外部機器へのレスポンスを送信していない最初のカード発行コマンドとから、最初に実行すべきカード発行コマンドを特定してカード発行コマンドの実行を再開する、
   請求項３記載のセキュアデバイス。
8. 前記カード管理部は、前記内部メモリに格納された複数のカードの機能にそれぞれ対応する複数のコマンド群を収めるファイルを特定するファイル管理テーブルを有し、外部機器から指定されたファイルに収められたコマンド群であるカード発行コマンドを実行する、
   請求項１記載のセキュアデバイス。
9. セキュアデバイスとこのセキュアデバイスとの間で通信を行う外部機器とからなるＩＣカード発行システムであって、
   前記外部機器は、カード発行を要求する要求コマンドを生成するコマンド生成部と、生成された前記要求コマンドを前記セキュアデバイスに送信するコマンド送信部と、を有し、
   前記セキュアデバイスは、内部メモリに格納されたコマンド群を直接参照する直接参照部を有し、前記コマンド群から、取得するカードの機能に対応するカード発行コマンドを抽出するカード発行部と、
   前記要求コマンドを入力した場合、前記直接参照部を介して前記カード発行コマンドを実行するカード管理部と、を有する、
   ＩＣカード発行システム。
10. 前記セキュアデバイスの前記カード管理部は、前記カード発行が成功したかどうかを示すレスポンスを前記外部機器に送信し、
    前記外部機器は、前記レスポンスを受信するレスポンス受信部と、前記レスポンスを解析して前記レスポンスがカード発行の成功を示す場合にはカード発行を終了し、前記レスポンスがカード発行の成功を示さない場合には前記要求コマンドを再送信する指示を前記コマンド生成部に出力するセルフ発行管理部と、を有する、
    請求項９記載のＩＣカード発行システム。
11. 前記セキュアデバイスの前記カード発行部は、前記カード管理部において各カード発行コマンドが正常に実行されたかどうかを監視し、正常に実行されていないカード発行コマンドが発生した場合に正常に実行されたカード発行コマンドを特定する情報を前記カード管理部に出力し、前記セキュアデバイスの前記カード管理部は、正常に実行されていないカード発行コマンドが発生したこと、及び前記正常に実行されたカード発行コマンドを特定する情報を含むレスポンスを前記外部機器に送信し、
    前記外部機器の前記セルフ発行管理部は、前記レスポンスを解析して、正常に実行されていないカード発行コマンドから実行してカード発行を開始する要求コマンドを送信する指示を前記コマンド生成部に出力する、
    請求項１０記載のＩＣカード発行システム。

Images