(57)【特許請求の範囲】
【請求項１】
ホスト・ステーションと、マイクロコントローラを有する携帯物品との間の通信方法であって、前記携帯物品は第１の通信プロトコールを用いるバス・システムによって前記ホスト・ステーションに接続されており、ホスト・ステーションが前記第１の通信プロトコールに従って、第２の通信プロトコールに対応する特定のリクエストを、マイクロコントローラを有する携帯物品に転送するステップを含んでおり、
前記マイクロコントローラを有する携帯物品はマイクロコントローラ・カードであり、
当該マイクロコントローラ・カードは、
前記マイクロコントローラに第一の通信プロトコールに従って通信することを可能とする一組のインストラクションを有するメモリと、
第一の通信プロトコールに従うコマンドを第二の通信プロトコールに従うコマンドに変換するとともに、逆にも変換するインターフェースと、
を備えることを特徴とする方法。
【請求項２】
前記携帯物品はカード状であって、前記ホスト・ステーションにコネクタを介して接続されており、前記コネクタは、カード状携帯物品を受け入れるためのスロットとなる端部、及びホスト・ステーションのＵＳＢスロットに挿入可能なプラグとなるもう一方の端部を有することを特徴とする請求項１に記載の方法。
【請求項３】
前記スロットは、一組のコンタクト・エレメントを有し、前記コンタクト・エレメントは、ＩＳＯ７８１６互換のカード状の携帯物品がスロットに挿入されたときに、ＩＳＯ７８１６互換のカード状の携帯物品のＣ１，Ｃ５，Ｃ４，Ｃ８のコンタクト領域と接触する、請求項２に記載の方法。
【請求項４】
前記バス・システムは、ユニバーサル・シリアル・バスＵＳＢシステムであり、前記特定のリクエストは前記システムのコントロール・トランスファー・モードを用いてマイクロコントローラを有する携帯物品と通信することを特徴とする請求項１に記載の方法。
【請求項５】
前記特定のリクエストは、マイクロコントローラを有する携帯物品のためのリーダの機能を与える特定のリクエストであることを特徴とする請求項１に記載の方法。
【請求項６】
前記マイクロコントローラは、中央処理装置を揮発性メモリと提携させるアセンブリを含み、かつ、特定のリクエストは前記アセンブリの揮発性メモリのリセット動作をトリガーするDoReset()リクエストであることを特徴とする請求項１に記載の方法。
【請求項７】
前記特定のリクエストは、前記携帯物品をリセットするときにアンサー・ストリングが復元されるようにするGetATR()リクエストである請求項１に記載の方法。
【請求項８】
前記特定のリクエストは、ホスト・ステーションにコマンド・ヘッダを携帯物品に送ることを可能にするSendADPU()リクエストであることを特徴とする請求項１に記載の方法。
【請求項９】
前記特定のリクエストは、ホスト・ステーションに携帯物品によって送られたデータを復元し、そしてステータス・ワードを復元することを可能にするGetData()リクエストであることを特徴とする請求項１に記載の方法。
【請求項１０】
前記特定のリクエストは、ホスト・ステーションに携帯物品へのデータの通信を可能にするSendData()リクエストであることを特徴とする請求項１に記載の方法。
【請求項１１】
前記特定のリクエストは、ホスト・ステーションが携帯物品における動作を低消費電力モードにトリガーするのを防ぐ役割を果たすIsReady()リクエストであることを特徴とする請求項１に記載の方法。
【請求項１２】
前記ホスト・ステーションに前記携帯物品における低消費電力モードをトリガーすることを可能にするリクエストに応答して、前記携帯物品がOS-STATUSアンサーをホスト・ステーション送ることを特徴とし、前記応答は携帯物品の現在のステータスを定義するようなやり方でコード化されている、請求項１１に記載の方法。
【請求項１３】
携帯物品の前記現在のステータスは、ミュート・ステータス又はカードが現在処理中であるというステータスである、請求項１２に記載の方法。
【請求項１４】
第一の通信プロトコールはＩＳＯ７８１６−３規格に適合し、第二の通信プロトコールはＵＳＢプロトコールに適合するものである、請求項１に記載の方法。
【請求項１５】
前記カードの前記マイクロコントローラは、ＩＳＯ７８１６規格において定義されているようなAPDUコマンドを実行するプロトコールを用いての通信に適合するオペレーティング・システムを搭載した不揮発性メモリを含んでいることを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、マイクロコントローラを有するカード状の携帯物品に関する。さらに本発明は、このようなカード状携帯物品を受け入れるスロットを有するコネクタに関する。
【０００２】
【発明の背景】
スマートカードは、ISO規格7816において定義されている標準化された携帯物品であり、これはとりわけ、秘密情報の安全な管理や身元確認に利用することができる。これらのカードは一般に、外界との通信に、上述の規格の第三部及び第四部で定義された通信プロトコールを利用している。特に、これらには、Ｔ＝０として当業者によく知られている、定義されたフォーマットのコマンドすなわちアプリケーション・プロトコール・データ・ユニット（APDU）コマンドを実現するプロトコールが含まれている。
【０００３】
ユニバーサル・シリアル・バス（USB）規格には、ユニバーサル・シリアル・バス・システムが記述されており、これは、ホスト・ステーションすなわちパーソナル・コンピュータから構成されるワークステーションと、任意の周辺デバイスたとえばプリンタ、キーボードなどとの間でのデータ交換が単純かつ高速な方法で管理されることを可能とすべく開発された。このシステムを使うと種々の利点がある。第一に、これは周辺デバイスへ電力を供給する二つの導線ＶBUS及びＧＮＤと、データ信号の差動転送（differential transmission）のための二つの導線Ｄ＋及びＤ−を必要とする。第二に、パーソナル・コンピュータにインストールされている従来からのシリアル・リンクによって提案されているものよりも一般に高い速度でのデータ転送を可能とする。この速度は最高で毎秒１２メガビット（Mb/s）、低速で１．５Mb/sである。さらに、周辺機器の「プラグ・アンド・プレー」、すわなち動作中の周辺機器を認識するホストコンピュータとも互換性がある。このような認識によって、ホストコンピュータの大容量メモリ内にある周辺機器のドライバ・プログラムは、前記周辺機器が接続されたときのみ前記コンピュータのリード／ライト・メモリにロードされる。このドライバ・プログラムは、周辺機器が取り外されたときは、前記リード／ライト・メモリから消去される。加えてユニバーサル・シリアル・バスは、単一の物理USBポートに１２６台までの周辺機器をカスケード接続することができる。最後に、USBの周辺機器は、コンピュータのコンポーネントによって管理されているハードウェアの割り込み要求（IRQ）を独占しない。
【０００４】
今日、ホスト・ステーションへのアクセス、同様に前記ステーションと関連するサーバーへのアクセスを安全に行うことの必要性がますます重要になっている。このようなステーションの制御のもとでデータの転送、特に、データを保証し署名することを可能にする暗号化アルゴリズムによってデータが認証されるようにするのが望ましいｅメール専用又はインターネットの閲覧専用の前記ステーションのアプリケーション・ソフトウェアからの転送を、安全に行うことの必要性についてもますます重要になっている。
【０００５】
上で述べた最新技術が与えられたとすれば、ISO規格7816の第３部及び第４部に規定されたプロトコールを用いて動作するスマートカードを、ホストコンピュータのUSBポートへ接続された、USB/ISOプロトコール変換を実現するスマートカード・リーダとともに利用することによって、前述の安全性のニーズを満たすことができる。このようなリーダは、まずUSBシステムを用いてホスト・コンピュータと通信し、続いてISOシステムを用いてカードと通信する。
【０００６】
残念ながら、このようなリーダは非常に高価である。これらは、カードのクロック（CLK）コンタクトエリアを通してカードのマイクロコントローラ内の中央処理装置（CPU）を動作させるクロックを生成する手段を有する必要がある。これらはまた、リセット信号を生成する手段、およびリセット（RST）エリアとして知られる特定のコンタクトエリアを通してこの信号をカードへ転送する手段を有する必要がある。
【０００７】
さらに、カードが純粋なISOカードの場合は、このようなカードと通信するためのプロシージャには前述のUSBシステムの利点、特に、数少ない導線及び高速なデータ速度等に関連する利点はない。
【０００８】
【発明の概要】
コストを削減することが、本発明の一つの目的である。
【０００９】
第一の特徴として、本発明は、ホスト・ステーションと、スマートカードなどのようなマイクロコントローラを有する携帯物品との間の通信の方法を提供し、前記携帯物品はバス・システムによって前記ホスト・ステーションと接続され、当該方法は、ホスト・ステーションがマイクロコントローラを有する携帯物品へ特定のリクエストを伝達するステップを含んでいることを特徴とする。
【００１０】
バス・システムは、ユニバーサル・シリアル・バス（USB）システムとし、前記特定のリクエストは、前記システムのコントロール・トランスファー・モードを用いてマイクロコントローラを有する携帯物品へ伝達され、特定のリクエストは、マイクロコントローラを有する携帯物品のためのリーダの機能を与える特定のリクエストであり、マイクロコントローラは中央処理装置を揮発性メモリと連携させるアセンブリを含んでおり、そして、特定のリクエストは、前記アセンブリの揮発性メモリをリセットする動作をトリガーするDoReset()リクエストであり、特定のリクエストは、携帯物品をリセットする際にアンサー列（answer string）が回復されるようにするGetATR()リクエストであり、特定のリクエストは、ホスト・ステーションがコマンド・ヘッダを携帯物品に送ることができるようにするSendAPDU()リクエストであり、特定のリクエストは、ホスト・ステーションが携帯物品によって送られたデータを回復できるようにすると共にステータス・ワードを回復できるようにするGetData()リクエストであり、特定のリクエストは、ホスト・ステーションが携帯物品にデータを転送できるようにするSendData()リクエストであり、特定のリクエストは、ホスト・ステーションが携帯物品における動作の低消費電力モードをトリガーするのを防ぐ役割を果たすIsReady()リクエストであり、携帯物品は前記ステーションが前記携帯物品における低消費電力モードをトリガーできるようにするリクエストに応答してOS-STATUSアンサーをホスト・ステーションへ送り、前記応答は携帯物品の現在のステータスを定義するような方法でエンコードされ、携帯物品の現在のステータスはミュート・ステータス又はカードが現在処理中であるというステータスであり、マイクロコントローラを有する携帯物品はマイクロコントローラ・カードであり、そして、カードのマイクロコントローラはISO7816規格において定義されているようなAPDUコマンドを実現するプロトコールによって通信するのに適合したオペレーティング・システムを搭載した不揮発性メモリを含むようにするのが有利である。
【００１１】
第二の特徴として、スマートカードのようなマイクロコントローラを有する携帯物品を提供することによってこの問題を解決する。この物品はパーソナル・コンピュータなどのホスト・ステーションとの間で、前記携帯物品とホスト・ステーションの両方に接続されたバスによって通信するように適合されており、この物品はホスト・ステーションと直接通信できるように適合されているという特徴を有している。
【００１２】
携帯物品はスマートカードから構成され、バス・システムはUSBバス・システムであり、携帯物品は、中央処理装置を、ISO7816規格において定義されているようなAPDUコマンドを管理するのに適合したオペレーティング・システムが搭載された不揮発性メモリと連携させる構成を含むようにするのが有利である。
【００１３】
この発明は、以下の非限定的な説明を精読することによってより良く理解されるだろう。この説明は図面を参照しながら読むべきある。
【００１４】
【詳細な説明】
本発明は、特に、商標として保護されているウィンドウズ２０００としてマイクロソフトから頒布されているオペレーティング・システムが搭載されたホスト・ステーションなどのホスト・ステーションの安全を確保するという場合に適用できる。このオペレーティング・システム及びこのオペレーティング・システムと共に動作する一定のソフトウェア・アプリケーションは、データ転送の安全を特に確保すること、例えばｅメールに署名すること、及びオーセンティケーション・アルゴリズムや否認防止（non-repudiation）アルゴリズムなどによってコンピュータ・ネットワークへのアクセスの安全を確保することを意図したカードを使用できるようになっている。本発明は、一般に、ISO規格7816の第３部及び第４部に適合するオペレーティング・システムを有する任意のカードについて実施することができる。
【００１５】
図１は、統合ハブ２を有するホスト・ステーション１を示しており、このハブ２には、１９９８年９月２３日に公表されたUSB規格バージョン1.1で定義された特定のポート２１、２２、２３が設けられている。USBポートは本発明に従ってマイクロコントローラを有する物品３に接続することができる。この接続は、ポート２１、２２に接続されている物品のように直接でも、ポート２３に接続されている物品のように別のハブ４を介して間接的であってもよい。
【００１６】
図２に示すように、ホスト・ステーションは、例えばパーソナル・コンピュータ１からなるワークステーションであり、マイクロコントローラを有する携帯物品は、スマートカード３である。スマートカード３はコネクタ５に接続されている。これはリーダではなく、ここにリーダがカードのリード及び／又はライトを行うための手段、及び／又はこのようなリード／ライトをイネーブルとする手段を有することになるだろう。
【００１７】
従来からと同様、コンピュータ１はモニタ１２及びキーボードと接続された中央装置１１を有している。中央装置１１はマザーボードを搭載している。マザーボードには特に、マイクロプロセッサ及び複数の揮発性メモリ片が含まれている。これはコンピュータの大容量メモリとなるハードディスクと、コンピュータ内に一体化されたハブに含まれる少なくとも一つのUSBポートに接続されている。
【００１８】
ここで図６を参照すると、ホスト・コンピュータ１には、最低一つのソフトウェア・アプリケーション１３を含み、スマートカード３を利用していることが分かる。またこれは、アプリケーションが使うインターフェースを管理するソフトウェア部PC/SC１４を有している。またこれは、二つのメインの論理部分（図６には不図示）からなる中間的なソフトウェア・ドライバー１５を有している。この第一の部分は、起動時にホスト・コンピュータのリード／ライト・メモリにロードされ、PC/SCソフトウェア部１４とのインターフェースを与え、ホスト・コンピュータに接続された本発明の一又は二以上のスマートカードのためのリーダの存在をシミュレートする。これは仮想リーダである。第二の部分はホスト・コンピュータの大容量メモリに格納されており、カードが実際にホスト・コンピュータに接続されたときにそのリード／ライト・メモリにロードされ、アドレスされ、コンフィギュアされる。この第二の部分は、PC/SC部からあるいはカードから、それぞれの行く先へ情報を伝達する役割を果たし、データ変換を実行する。これはまたホスト１６のコントローラ部を含み、これはUSBバスへのデータの配分を管理する役割を果たす。最後に、これはまた、ホストと外界との間のインターフェースとなるハードウェア部１７を含む。
【００１９】
図２に示したカード３は、例えば標準的なISOフォーマットのカード、又は前記ISO規格7816又は ETSI GSM規格11.11に記述されているような「プラグイン」フォーマットのカードである。このようなカードを図３に詳しく示してある。これは、中に挿入された電子モジュールを有するプラスチックのカード本体３１からなり、この電子モジュールには接続ワイヤを介してカード本体の表面と同一面とされたコンタクト・エリア３２に接続されたマイクロコントローラを含んでいる。
【００２０】
図４は、カード３のコンタクト領域３２を示している。一例として、ここでは８個のコンタクト領域が設けられている。これらの領域はＣ１、Ｃ２、Ｃ３、Ｃ４、Ｃ５、Ｃ６、Ｃ７、Ｃ８と符号付けされている。領域Ｃ１及びＣ５はそれぞれ、カードのマイクロコントローラのＶCCパッド及びＧＮＤパッドに接続されており、マイクロコントローラに電力を供給する。領域Ｃ４及びＣ８はそれぞれ前記マイクロコントローラのＤ＋及びＤ−に接続されている。これらのパッドはUSBバス・システムを用いたデータの転送のための差動ペア（differential pair）となる。他の領域はISO規格を用いるデータの転送のために使われ、前述のUSBバス・システムでは利用されない。
【００２１】
カード３のマイクロコントローラ３３を、図５にブロック図として描いてある。これは、中央処理装置CPUを揮発性のリード／ライト・メモリRAM及び不揮発性のROM及びEEPROMメモリと結合したアセンブリ３３１を含んでいる。ここでROMには、カードのオペレーティング・システムが搭載されている。また、ISOシステムを利用するインターフェース３３２、一方で転送システム３３４、他方でレジスタ３３５と連携するUSBエンジン３３３、そして外部ブロック・インターフェース（EBI）３３６を有している。この転送システムは、カードの少なくともＤ＋領域及びＤ−領域に接続されている。また、電力供給の目的でＶCC及びＧＮＤにも接続されている。カードのオペレーティング・システム３３７、EBI３３６、そしてUSBエンジン３３３は、図６にブロック図として示してある。
【００２２】
図３から分かるように、カードは使用時にはカード・コネクタ５に挿入される。本発明においてコネクタ５は小さく、USBコネクタ５１及びカード３用のコネクタ５２を有するだけである。
【００２３】
USB規格では、データは、高速度で１２Mb/sであり、低速度で１．５Mb/sという二つの速度で転送される。本発明では、データは低速度で転送される。したがって、USBバスのデータ線に基づいて内部クロック信号を生成することが可能である。その結果、コネクタ５はカード３へクロック信号を供給するための手段は持っていない。
【００２４】
USB規格には、四つのデータ転送モードが設けられている。バルク（bulk）転送モード及びアイソクロナス（isochronous）転送モードは、高速度通信の実現のためだけに意図されたものである。コントロール転送モード及びインターラプト転送モードは、低速度通信及び高速度通信の両方を実現することを意図したものである。
【００２５】
本発明では、カードは、コントロール転送モードで直接ホスト・コンピュータと通信するUSB周辺機器である。このためカードは、USBバス上を低速度USB信号の形態でそのカードにアドレスされるデータを解釈し、処理することができる。これはまた、コントロール転送モード特有のUSBリクエスト、そして特にホスト・コンピュータにカードのデスクリプタ（descriptor）を復元することを可能として、ホスト・コンピュータにアドレスを与えこれをコンフィギュアする、従来からのリクエストを処理することを可能とするプログラムも有している。USB規格では、コントロール転送モードが、すべてのUSB周辺機器について要求されるが、これは、それらのデスクリプタを復元するため、それらに対してアドレスを割り当てるため、そしてそれらをコンフィギュアするためである。USB規格は、前述のタイプのコントロールステップの間以外は、データ転送をハンドリングするためにコントロール転送モードを用いることを提案していない。
【００２６】
周辺機器を認識し、アドレスし、そしてコンフィギュアすることを可能とする従来からのUSBリクエストに加えて、６つのベンダー特有の（vendor-specific）リクエストが定義されている。カードは、これらのベンダー特有のリクエストを認識し、そして処理するための手段を有している。これらのベンダー特有のリクエストは、アクティブ・スマートカード・リーダと協働して、USBプロトコール及び関連するデータバスを用い、かつ当該リーダによって構成される追加のインターフェースを用いずに、ISO7816-3又はISO7816-4のカードの動作を再生（reproduce）することを可能にする。これらのリクエストは、特に、APDUコマンドが処理されることを保証し、ホスト・コンピュータとの通信インターフェースを再初期化せずにカードのマイクロコントローラを初期化又は再初期化する役割を果たす。
【００２７】
カードは、第一に、ベンダー特有のリクエストを送信することを担うホスト・コンピュータにインストールされたドライバーによって、第二に、これらのリクエストの認識及び処理を担うカードのマイクロコントローラ及びそのオペレーティング・システムに含まれているUSBエンジンによってコントロールされる。
【００２８】
最後に、カードは、あたかもスマートカード・リーダに接続されているかのように動作するが、USBプロトコールを使っているときは、これはインターフェースの変更、すなわちISOスマートカード・リーダからUSBコネクタへの変更は、ホスト・コンピュータのアプリケーション・レベルには見えない。
【００２９】
本発明のベンダー特有のリクエストは、下記の表に定義されている。
【００３０】
【表１】
0004898056.tif 000002
【００３１】
この表において、
−bmRequestという列の値は、リクエストの特性を示す。bmRequestの値が40hであれば、そのリクエストは、そのデータ・フェーズがホストからカードへ転送されるベンダー特有のリクエストである。bmRequestの値がC0hであれば、そのリスクエストは、そのデータ・フェーズがカードからホストへ転送されるベンダー特有のリクエストである。
−bRequestという列の値は、最小桁ビット（least significant bit）がビット０の場合にビット４及びビット５の各場合に１ビットだけテストして、USBエンジンにリクエストDoReset()及びIsReady()を特定することを可能とする。
−wValueという列の値は、リクエストについて固有である。
−wIndexという列の値も同様である。
−wLengthという列の値は、リクエストのデータ・フェーズにおけるバイト数を指定する。
−表の最後の列のModeは、USBデータの伝送方向に対応する。OUTは、データ・フェーズの間に、データがホスト・コンピュータからカードへ向かって進行し、INは、データがカードからホスト・コンピュータに向かって進行することを意味する。
【００３２】
最初に、二つのリクエストがカードのリセット・シーケンスに用いられる。これらのリクエストとは、DoReset()及びGetATR()である。
【００３３】
リクエストDoReset()は、ホスト・コンピュータとの通信インターフェースをリセットすせずに、マイクロコントローラ及びリード／ライト・メモリRAMをリセットさせる。これはもっぱらマイクロコントローラに含まれるUSBエンジン３３３によって処理され、カードのオペレーティング・システムの関与は必要としない。ベンダー特有のリクエストであるDoReset()の自動処理は、スマートカード自身がリセット信号を生成することを可能とし、そしてベンダー特有のリクエストGetATR()と共同でISOモードにおけるリセット信号の通常動作の維持を可能とする。
【００３４】
リクエストGetATR()は、カードのリセットに対するアンサー・ストリングを回復させる（ここでATRは「リセットへのアンサー」を表す）。このアンサーは、ISO規格7816-3において定義されている。これはカードを特定する。
【００３５】
ほとんどの周辺機器に、異常動作の際に使われるリセットが設けられていることが分かるだろう。USBプロトコールは、周辺機器を完全に初期化させるUSBウォーム・リセットを送る可能性をホスト・コンピュータに与えることによって、このような状況に備えている。それにも拘わらず、スマートカードの使用に頼っているアプリケーションは、前記カードのマイクロコントローラによって管理されるリード／ライト・メモリだけを再初期化する目的でスマートカード・リセットを用いることができる。このような状況のもとでは、ホスト・コンピュータとの通信インターフェースをリセットする必要性はなく、これは時間の無駄となる。したがって、USBウォーム・リセット信号を用いることを正当化する理由はない。さらに、このリセット信号は、完全に非同期でなければならない。これは、任意のコマンドが処理される場合、カード又は処理されるコマンドの状態に拘わらず考慮されるうることを意味する。これが、従来技術において現在利用可能な解決策においてスマートカード・リーダを用いる一つの理由である。この場合、マイクロコントローラのリセット・コンタクト・パッドに接続されたコンタクト領域によってマイクロコントローラ及びそれに関連するメモリをリセットさせるのはこのリーダである。
【００３６】
その後、APDUコマンドを処理するのに四つのリクエストが用いられる。このうちの三つはSendAPDU()と、GetData()と、SendData()である。
【００３７】
SendAPDU()リクエストは、ISOのAPDUコマンドのヘッダをカードへ送る役割を果たす。すなわち、CLAss、INStruction、パラメータP2、パラメータP3の部分である。
【００３８】
リクエストGetDATA()は、タイプ２のISOコマンドの状況でカードによって送られるデータを復元することと、ISO規格7816によって定義されているステータス・ワードを復元するという役割を果たし、これはコマンドの実行が終了したときに前に送られたコマンドの結果を外界へ通知する。
【００３９】
リクエストSendData()は、は、タイプ３のISOコマンドの状況で、コマンドのヘッダ・パラメータに加えてデータを送る役割を果たす。
【００４０】
最後に、四つ目のリクエストは、低消費電力モードをトリガーするのを防ぐのと、APDUコマンドの順序付け（sequencing）を処理するのに用いられるリクエストで、これはリクエストIsReady()である。ベンダー特有のリクエストであるIsReady()の半自動処理は、APDUのISOコマンドを実行する際に、低消費電力へ切り換わるのを防止する役割をする。カードがAPDUのISOコマンドを処理するのに必要な時間を予測することはできない。残念ながら、USBプロトコールはバスがある長さの時間使われていないときに、低消費電力モードとなり、これは、APDUのISOコマンドの処理に要する時間が長すぎるときに生じうる。このためこのリクエストは、APDUのISOコマンドを処理しているあいだ低消費電力モードとなることを防ぐ。もっとも別の場合にはこのような切り換えは可能である。より正確には、カードのオペレーティング・システムの状態又は、コマンドが実際に処理されている場合には処理されるコマンドの状態を復元することを可能とする。これは、カードがAPDUのISOコマンドを処理しているときに、例えば５ミリ秒（ms）に一回という頻度で周期的にホスト・コンピュータに含まれているドライバー１５によって送られる。これはマイクロコントローラに含まれているUSBエンジン３３３によって処理されうる。これは特にマイクロコントローラがビジー又はミュートの状態で応答できない場合に当てはまる。これはまた、特にカードが利用可能で、したがって応答可能の時には、カードのオペレーティング・システムによっても処理することができる。
【００４１】
このベンダー特有のリクエストの組は、ISOモードにおける従来からのスマートカードの動作の実行及び標準的なUSB周辺機器の動作の実行に加えて、カードに関連するスマートカード・リーダの動作を再構成することを可能にする。
【００４２】
さらに、IsReady()リクエストに対するOS_STATUS応答も定義されている。この応答は、最初の４ビットがカードの現在状態を定義し、最後の４ビットが前記状態を特定する１バイトでエンコードされている。
【００４３】
したがって、ビット７が１のときは、カードはMUTEと表されるミュート状態にあることを意味する。ビット６が１のときは、カードのオペレーティング・システムが処理を行っており、したがってシステムを他の処理に利用できないことを意味する。ビット５が１のときは、前にカードが受け取ったコマンドの処理が終了し、オペレーティング・システムはステータス・ワードＳＷ１、ＳＷ２を送る準備ができていることを意味する。このときカードはステータス・ワード・フェーズ（SWP）にあると言われる。ビット４が１のときは、カードのオペレーティング・システムが以前のコマンドに関連するデータの送信又は受信の準備ができていることを意味する。この場合カードはデータ転送フェーズ（DTP）状態にあると言われる。
【００４４】
ビット３、２、１、０は、現在の状態についてのさらなる情報を与える。これらは、例えばコマンドが非常に長いときにタイム・アウト（time-out）の発生を避けるのに有用である。すなわちコマンドがある最大指定時間を超えたことで措置をとる。この場合、その値は周期的にインクリメントされる。したがってこれはその値がFhになった後は0hに戻り、これによりＰＣに入っているドライバーにある動作の検出を可能ならしめる。
【００４５】
USBプロトコールによるISO規格7816の第３部及び第４部に定義されている通信プロトコールの純粋なカプセル化は、カードがホスト・コンピュータによってバス上で情報を転送するよう要求されたときのみUSBバス上で情報を伝送できるという事実及びいくつかの情報はAPDUコマンドを実行する状況において役に立たないという事実に関連して、時間のロスを生じるだろう。ベンダー特有のリクエストIsReady()を使用すると、カード・ドライバーに現在のカードの状態だけでなく、コマンドの現在の状態も知らせることによって、この時間の長さを短縮でき、これによりISO規格7816-3において定義されているプロシージャ・バイトのステップ（procedure byte step）を削除できる。
【００４６】
ISO規格7816-3は、カードのオペレーティング・システムがATRストリングによって定義された時間内にデータを返さない場合には、タイム・アウトの管理を行う。この時間内に処理され得ないコマンドに対して、規格は、カードがまだ処理中であることを指定するための予備の値であるバイト60hを用いるようにされている。カードがこのバイトを送ると、タイム・アウトをトリガーするためのカウンタを再初期化する効果がある。このタイム・アウトの管理は、IsReady()リクエストへの応答として返された値によって再生される。
【００４７】
図７は、本発明のスマートカードとの通信セッションがどのように行われるかを示している。この図の左側には、カードのUSBエンジンによって実行される処理を示しており、右側はカードのオペレーティング・システムによって実行される処理を示している。
【００４８】
カードのオペレーティング・システムによって実行される処理には、特に以下の処理が含まれている。
【００４９】
「カードの接続」は、ホスト・コンピュータのUSBポートへのカードの接続である。このときホスト・コンピュータには、カードが接続されたことと、新しいUSB周辺機器を構成することが知らされる。そしてコンピュータはカードに電力を供給してカードをリセットする。このリセットには、カードのRAM、EBI３３６、レジスタ３３５、そして転送システム３３４のリセット動作が含まれる。
【００５０】
「カード部品のリスト及び初期化」  リスト動作は、カードを動作状態にすること、すなわちアドレスされ、コンフィギュアされることを可能とする。以前の処理によって一旦カードがリセットされると、カードはそれをホスト・コンピュータに知らせる。カードがデスクリプタの形態でホスト・コンピュータに種々の情報の断片を送るのはこのリスト段階の期間である。すると、ホスト・コンピュータはカードにアドレスを与え、それをコンフィギュアする。これでカードは使用準備ができた状態になる。
【００５１】
「GetATR()受信」  前の「リスト及び初期化」のステップの後、カードはベンダー特有のリクエストであるGetATR()を待つ。これはこの段階で認められている唯一のベンダー特有のリクエストである。
【００５２】
「カードがATRストリングを返す」  一旦ベンダー特有のリクエストであるGetATR()が受信されると、カードはATRストリングを返す。すなわち、ホスト・コンピュータのアプリケーション・レベルにおいて、カードに存在するISO規格7816と完全に互換性のあるResetがシミュレートされる。
【００５３】
「OS_STATUS=00h」  カードのオペレーティング・システムはコンフィギュレーションを開始し、その中でそのステータスバイトを00hに設定することによってAPDUのISOコマンドの処理の準備ができる。
【００５４】
「SendAPDU()受信」  カードのオペレーティング・システムはベンダー特有のUSBリクエストの形態でAPDUコマンドのヘッダを受け取る。
【００５５】
「OS_STATUS=BUSY」  カードのオペレーティング・システムはそれ自身でAPDUコマンドのヘッダを処理する準備をする。これにより利用不可となる。外界に対して利用不可あることを知らせるために、そして実際にはホスト・コンピュータに知らせるために、前記オペレーティング・システムはそのステータス・バイトを「BUSY」に設定して更新する。この段階で、ホスト・コンピュータから来るリクエストはカードのUSBエンジンによって処理される。
【００５６】
「コマンドの処理」  カードのオペレーティング・システムがAPDUコマンドのヘッダを処理する。
【００５７】
この段階で、いくつかの状況が生じうる。
まず、このコマンドはISOのタイプ１のAPDUコマンド、すなわちすべてがそのヘッダによって表されるAPDUコマンドで、その実行によってカードはステータス・ワードを送る。そうでなければ誤ったタイプ２又はタイプ３のISOコマンドであり、タイプ２のISOコマンドはそのヘッダによって定義されるコマンドであって、その実行によってデータはステータス・ワードと共にカードから送られ、ISOのタイプ３コマンドはそのヘッダ及びデータによって定義されるコマンドであって、その実行によってカードはステータス・ワードを送る。この場合、以下のケースが実行される。
【００５８】
「OS_STATUS=SWP」  カードのオペレーティング・システムはステータス・ワードを返す準備ができ、これはまたここへ送られたリクエストを処理するのに利用され、ホスト・コンピュータに知らせるためのIsReady()リクエストを待っている。このステータス・バイトは更新される。これは値「SWP」をとる。
【００５９】
「IsReady()受信」  カードのオペレーティング・システムは続いてベンダー特有のリクエストIsReady()を受け取る。このリクエストの役割は、外界に対してカードのオペレーティング・システムの状態を知らせることであり、これには「MUTE」又は「BUSY」があり、そうでければAPDUのISOコマンドの状態は処理され、それは「SWP」又は「DTP」である。今の場合、このリクエストへの応答は「SWP」である。これはホスト・コンピュータに、ステータス・ワードを復元するためにGetData()コマンドを送らなければならないことを知らせる。
【００６０】
「Return OS_STATUS」  カードのオペレーティング・システムはそのステータス・ワードをホスト・コンピュータに返し、ベンダー特有のリクエストGetData()を待つ。
【００６１】
「GetData()受信」  ベンダー特有のリクエストが送られた後、この場合のステータス・ワードのようなカードのオペレーティング・システムによって返されたデータをコンピュータが復元できるようにする目的で、カードのオペレーティング・システムはGetData()を受信する。
【００６２】
「Return status word」  GetData()リクエストに応答して、カードのオペレーティング・システムはステータス・ワードを返す。そしてコンフィギュレーションを開始し、新たなAPDU ISOコマンドを処理する準備ができ、そしてシステムは前述のステップ「OS_STATUS=00h」に戻る。
【００６３】
タイプ２及びタイプ３のISO APDUコマンドには、ISO 2コマンドに対してはカードからホストへ、そしてISO 3コマンドに対してはホストからカードへというデータ・フェーズを有しているという特別の特徴がある。いずれの場合も、オペレーティング・システムはホスト・コンピュータに、データ・フェーズの準備ができたことを知らせなければならない。それから以下のステップが実行される。
【００６４】
「OS_STATUS=DTP」  カードのオペレーティング・システムはAPDUのISOコマンドのデータ・フェーズの準備ができる。したがってこれは再び送られてきたリクエストを処理するのに利用可能であり、この利用可能性の状態を外界に対して知らせるために、IsReady()を受け取るのを待っている。ステータス・バイトは更新される。これは「DTP」という値を取る。
【００６５】
「IsReady()受信」  カードのオペレーティング・システムは、ベンダー特有のリクエストIsReady()を受け取る。このリクエストの目的は、ホスト・コンピュータにカードのオペレーティング・システムのステータスを知らせることである。このステータスは「MUTE」又は「BUSY」のいずれかで、そうでなければ現在処理されているAPDUのISOコマンド「SWP」又は「DTP」である。今の場合、このリクエストに対する応答は「DTP」である。最初に、この応答はホスト・コンピュータにAPDUのISOコマンドへの応答を構成するデータを復元するためにGetData(P3)を送らなければならないことを知らせる。このデータはP3バイトからなる。ここでP3はAPDUのISOコマンドのパラメータの一つである。二つ目の場合として、この応答は、ホスト・コンピュータに、APDUのISOコマンドの追加データを送るためのSendData(P3)リクエストを送らなければならないことを知らせる。このデータはP3バイトからなり、ここでP3はAPDUのISOコマンドのパラメータの一つである。
【００６６】
「OS_STATUSを返す」  カードのオペレーティング・システムは、そのステータス・バイトをホスト・コンピュータに返し、GetData(P3)リクエスト又はSendData(P3)リクエストのいずれかを待つ。
【００６７】
ここで二つの状況が生じうる。
一つ目の状況は、コマンドのヘッダに関連する又はカードの現在の状況におけるエラーが検出されないという形式上の場合についてのISO２のAPDUコマンドの状況である。この場合、カードのオペレーティング・システムはGetData(P3)リクエストを待つ。
【００６８】
「GetData()受信」  カードのオペレーティング・システムは、GetData()リクエストを受信している。このリクエストの機能は、オペレーティング・システムによって返されたデータ、例えば今の場合であればタイプ２のAPDUのISOコマンドへの応答を構成するデータを復元することである。
【００６９】
「カードがデータを返す」  GetData()リクエストが受信されると、APDUのISOコマンドへの応答を構成するデータを返し、それ自身をステータス・ワードを返す準備ができているコンフィギュレーションの中に入れる。この場合、システムは前述のステップ「OS_STATUS=SWP」へ戻る。
【００７０】
二つ目の状況は、コマンドのヘッダ又はカードの現在の状況においてエラーが検出されない形式上の場合におけるタイプ３のAPDUのISOコマンドの状況である。この場合、オペレーティング・システムはSendData(P3)リクエストを待つ。
【００７１】
「SendData()受信」  カードのオペレーティング・システムはSendData()リクエストを受信している。このリクエストは、タイプ３のAPDUのISOコマンドを動作させるのに必要とされる、追加データの送信を可能とする。
【００７２】
「カードがデータを復元」  リクエストが受信されると、カードはタイプ３のAPDUのISOコマンドの追加データを復元し、そのコマンドのデータの残りを処理することを可能とするコンフィギュレーションの中にそれ自身を入れる。
【００７３】
「OS_STATUS=BUSY」  カードのオペレーティング・システムは処理中なので、送られるリクエストを処理することはできない。オペレーティング・システムはこのステータスを、ステータス・バイトを「BUSY」に設定することによって表す。この段階では、ホスト・コンピュータによって送られたリクエストを処理するのは、カードのUSBエンジンである。
【００７４】
「コマンドの処理」  オペレーティング・システムはAPDUのISOコマンドの処理を終了し、ステータス・ワードを返す準備ができているコンフィギュレーションの中に自身を入れる。そして、前述の「OS_STATUS=SWP」に戻る。
【００７５】
カードのオペレーティング・システムによって処理される最後の状況は、任意のAPDUのISOコマンドの実行中に生じる重大なエラー、例えばこの後の安全性への攻撃又はデータの改変などの状況である。このような状況下では、カードのオペレーティング・システムは、続く処理でミュートに設定される。
【００７６】
「OS_STATUS=MUTE」  カードのオペレーティング・システムはそのステータス・バイトを「MUTE」に設定して、次のDoReset()リクエストまで、あるいはカードが外されるまでは利用不可であることをホスト・コンピュータに知らせる。このステージの間は、ホスト・コンピュータによって送られるリクエストを処理するのは、USBエンジンである。
【００７７】
USBエンジンによって実行される処理には、特に以下の処理が含まれる。
オペレーティング・システム(OS)が利用不可の間、すなわちOS_STATUS=BUSY又はOS_STATUS=MUTEの間は、ホスト・コンピュータによって送られるリクエストはUSBエンジンによって処理される。さらに、リクエストDoReset()は、カードのオペレーティング・システムが自身のリセットの際に介入するのを防ぐために常にUSBエンジンによって処理される。
【００７８】
三つの状況が生じうる。最初の状況（図７には示していない）は、USBエンジンによって処理されていると述べられていないすべてのリクエストに対応する。これらのリクエストに対しては、USBエンジンはホスト・コンピュータにこれらが関係ないことを知らせるだけである。
【００７９】
二番目の状況はDoReset()リクエストの場合であり、以下のステップが実行される。
【００８０】
「DoReset()」  カードのオペレーティング・システムの状況、あるいは現在処理されているAPDUのISOコマンドの状況がどうであろとう、このリクエストは常にUSBエンジンによって処理される。これは、カードのCPU及びこれに関連するメモリをリセットさせ、そして、コンフィギュレーション及び周辺機器及びアドレスによって形成されたUSB通信インターフェースは元のままなので、セントラル・ユニット及びこれに関連するメモリだけがリセットされる。
【００８１】
「リセット・シーケンス」  カードのCPU及びそのメモリは再初期化される。カードのオペレーティング・システムはGetATR()リクエストを待つ。このリセット・シーケンスは、カードのオペレーティング・システムを、オペレーティング・システムに送られてきたリクエストを処理できる状態にする。
【００８２】
三番目の状況は、カードのオペレーティング・システムが利用不可のときに生じるIsReady()リクエストの状況である。以下のステップが実行される。
【００８３】
「IsReady()受信」  カードのオペレーティング・システムは、IsReady()リクエストを受信する。このリクエストの機能は、ホスト・コンピュータにカードのオペレーティング・システムの「MUTE」又は「BUSY」の状態を知らせること、あるいは処理されているAPDUのISOコマンドの「SWP」又は「DTP」の状態を知らせることである。カードのオペレーティング・システムは、「MUTE」又は「BUSY」であるために、利用不可である。他の状況については、カードのオペレーティング・システムによって処理される。
【００８４】
「USBエンジンがOS_STATUSを返す」  USBエンジンは、ステータス・バイトを返すことによって、ホスト・コンピュータにカードのオペレーティング・システムのステータスを知らせる。
【００８５】
この方法において、スマートカード・リーダに関連するISOカードの動作が再生される。
【００８６】
ここまでは図７について説明したが、以下の記述は図８Ａ、図８Ｂ、図９Ａ〜図９Ｄ、図１０Ａ〜図１０Ｄの説明である。
【００８７】
図８Ａに示したタイプ１のAPDUコマンドに対して、コマンド・ヘッダは、このコマンドを完全に実行するのに十分であり、そしてカードのオペレーティング・システムからの唯一の応答はステータス・ワードである。このためISOプロトコールでは、通信は最低二つのステップに分割される。第一のステップにおいて、コンピュータはコマンド・ヘッダを送る。そして第二のステップにおいて、カードは、タイム・アウト又はその他のステータス・ワードSW1、SW2（図８Ｂ）を決定するために、バイト60hを送ってカウンタをリセットする。バイト60hが送られると、続くステップでは他のバイトか、あるいは60hを送り、最後のステップでは常にステータス・ワードSW1、SW2を送る。これとは対照的に、本発明では、図８Ｂに示したステップが削除されている。これはホスト・コンピュータによって送られたIsReady()コマンドに対するカードの応答に置き換えられている。
【００８８】
タイプ２のISOのAPDUコマンドに対して、コマンド・ヘッダは実行を開始するが、カードのオペレーティング・システムの応答は、ステータス・ワードに加えてデータから成り立っている。通信は一般に四つのステップに分割される。図９Ａに示した第一のステップにおいて、コンピュータはコマンド・ヘッダを送る。第二のステップは慣例的にISOプロシージャにおいて使われる。このステップにおいて、コンピュータはプロシージャ・バイト60h、INS、又はSW1を受け取る。プロシージャ・バイトが60hのときは、システムは、INSバイト又はSW1バイトを受け取るまで上で述べた状況へ戻る。図９Ｂに示すように、INS又はSW1のプロシージャ・バイトが受信されると、プロセスは図９Ｃ、図９Ｄを参照して下で説明するように処理は継続する。それにもかかわらず、本発明では図９Ｂのステップが省略されることが分かるだろう。これはホスト・コンピュータによって送られたIsReady()コマンドへのカードの応答に置き換えられている。図９Ｃを参照すると、これは受信されたプロシージャ・バイトがINSである場合に対応するが、カードはデータを送る。最後に、コンピュータは図９Ｄに示すようにSW1になるまでプロシージャ・バイトを待つ。INSが受信されずSW1が直接受信された場合は、SW2が受信され、コマンドは終了される。本発明では、図９Ｃ及び図９Ｄに示したこれらのステップは、図９Ｄに示したようにカードがプロシージャ・バイト60hを返す状況を除いて、保存される。
【００８９】
タイプ３のAPDUコマンドに対するプロシージャは、データが送られる方向を除いてタイプ２のISOコマンドの処理に関し上で述べたプロシージャと同じであり、ここではカードからコンピュータへではなく、コンピュータからカードへという方向である。
【００９０】
以上を要約すると、マイクロコントローラを有するカード状の携帯物品について説明してきた。このカード状の携帯物品は、第一の通信プロトコールに従ってマイクロコントローラが通信できるようにするインストラクションの組が組み込まれたメモリを有しいてる。このカード状の携帯物品はさらに、第一の通信プロトコールに従ったコマンドを第二の通信プロトコールに従ったコマンドに変換し、そしてその逆に変換するためのインターフェースを有している。第一の通信プロトコールはISO7816-3規格に従うものであり、第二の通信プロトコールはUSB規格に従うものであることが好ましい。一つの利点は、カード状の携帯物品が、USB規格に従った通信を行うのに、特定のオペレーティング・システムを必要としないということである。ISO7816をベースとしたオペレーティング・システムを用いることが可能である。USBのための特定のオペレーティング・システムは相対的に高い開発コストを伴うのに対し、このようなオペレーティング・システムは、相対的に低コストで実現することができる。
【００９１】
コネクタについても説明してきた。このコネクタはカード状の携帯物品を受け入れるためのスロットとなる端部と、ホスト・ステーションのUSBスロットに挿入可能なプラグとなるもう一方の端部を有している。このスロットは、ISO7816互換のカード状の携帯物品が挿入されたときには、ISO7816互換のカード状の携帯物品のコンタクト領域C1、C5、C4、C8と接触するコンタクト・エレメントの組を備えていることが望ましい。
【図面の簡単な説明】
【図１】  本発明に係る、ホストのワークステーションとと携帯物品との間の考え得る接続の構成を示している。
【図２】  本発明に係る、ホストのパーソナル・コンピュータとスマートカードとの間の接続を示している。
【図３】  本発明に従ってホスト・コンピュータと接続するためにスマートカードを受け入れるのに適したコネクタ・エレメントの斜視図である。
【図４】  本発明に従ったスマートカードのホスト・コンピュータとの接続用のコンタクトを示した拡大正面図である。
【図５】  本発明に従ったホスト・コンピュータとの接続のためのカードのマイクロコントローラの動作に関係する種々のエレメントを示したブロック図である。
【図６】  カードとホスト・コンピュータのソフトウェア・アプリケーションとの間の通信のための、本発明に従ったシステムの論理構成を示した図である。
【図７】  本発明のスマートカードとの通信セッションがどのように行われるかを示したフローチャートである。
【図８Ａ】  カードによってISOのタイプ１のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図８Ｂ】  カードによってISOのタイプ１のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図９Ａ】  カードによってISOのタイプ２のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図９Ｂ】  カードによってISOのタイプ２のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図９Ｃ】  カードによってISOのタイプ２のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図９Ｄ】  カードによってISOのタイプ２のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図１０Ａ】  カードによってISOのタイプ３のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図１０Ｂ】  カードによってISOのタイプ３のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図１０Ｃ】  カードによってISOのタイプ３のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図１０Ｄ】  カードによってISOのタイプ３のコマンドを実行するモードにおいて行われるトランザクションを示している。
【図１】
0004898056.tif 000003
【図２】
0004898056.tif 000004
【図３】
0004898056.tif 000005
【図４】
0004898056.tif 000006
【図５】
0004898056.tif 000007
【図６】
0004898056.tif 000008
【図７】
0004898056.tif 000009
【図８Ａ】
0004898056.tif 000010
【図８Ｂ】
0004898056.tif 000011
【図９Ａ】
0004898056.tif 000012
【図９Ｂ】
0004898056.tif 000013
【図９Ｃ】
0004898056.tif 000014
【図９Ｄ】
0004898056.tif 000015
【図１０Ａ】
0004898056.tif 000016
【図１０Ｂ】
0004898056.tif 000017
【図１０Ｃ】
0004898056.tif 000018
【図１０Ｄ】
0004898056.tif 000019