(57)【特許請求の範囲】
【請求項１】
所定の第１プロトコルによる通信を可能にする、スマートカード読取装置を介して、スマートカードに接続された端末から前記スマートカードの中にソフトウェアをロードする方法であって、前記ロードは第１ロードプログラムおよび第２ロードプログラムの利用と協働によって行われ、前記第２ロードプログラムが前記スマートカードの中に記憶されている方法であって、少なくとも下記の段階、すなわち、
ａ／前記スマートカード（２ａ）の中に、第１ソフトウェア（２３ａ）を導入して、特定の通信プロトコル層を形成することから成る予備的第１段階と、
ｂ／前記端末（１）の中に、第２ソフトウェア（１３）を導入して、特定の通信プロトコル層を形成することから成る予備的第２段階と
を含み、
前記第１および第２ソフトウェア（１３、２３ａ）はさらに、少なくとも１対として組み合わせた自律的第１ソフトウェアエンティティ（１３２、２３２ａ）を含み、前記エンティティ（１３２、２３２ａ）の各々は、前記スマートカード（２ａ）が「ＷＥＢ」クライアント／サーバの機能性を提供するように、少なくとも前記端末（１）と前記スマートカード（２ａ）の間の双方向データ交換セッションを確立できるように互いに協働し、前記スマートカードは、前記「ＷＥＢ」クライアント／サーバの機能性を通してアクセス可能で、ソフトウェアをロードするために前記第２ロードプログラム（ＩＬ）により必要とされるデータを記述する、ロードパラメータ表示データを含み、
前記スマートカードが「ＣＧＩ」と呼ばれるゲートウェイインターフェースの機能性を提供するように、前記の特定の第１ソフトウェア（２３ａ）と協働するように、一連の指令を解釈してこれを一連の命令に翻訳することができる、少なくとも１つの第２ソフトウェアエンティティ（ＡＴＳ１〜ＡＴＳｎ）を、前記スマートカード（２ａ）の中に導入することから成る予備的第３段階を含み、前記スマートカードは、前記第２ロードプログラム（ＩＬ）に関連する前記指令列の少なくとも１つを含み、
本方法は少なくとも下記の段階、
１／少なくとも前記端末（１）と前記スマートカード（２ａ）の間の第１データ交換セッションを開く段階であって、このセッション中に、スマートカードの前記自律的第１ソフトウェアエンティティ（２３２ａ）が前記第２ロードプログラム（ＩＬ）によって必要とされる前記ロードパラメータ表示データを検索するために、端末の前記自律的第１ソフトウェアエンティティ（１３２）が前記第１ロードプログラム（ＯＬ）により出された要求を送信する、段階と、
２／前記スマートカード（２ａ）と少なくとも前記端末（１）との間の第２データ交換セッションを開く段階であって、このセッション中に、スマートカードの前記自律的第１ソフトウェアエンティティ（２３２ａ）が、端末の前記自律的第１ソフトウェアエンティティ（１３２）へ、前記ロードパラメータ表示データを送信し、端末の前記自律的第１ソフトウェアエンティティ（１３２）は前記データを、前記第１ロードプログラム（ＯＬ）へ送信し、前記ロードパラメータ表示データは前記第２ロードプログラム（ＩＬ）に関連する前記指令列を指す参照を含む、段階と、
３／少なくとも前記端末（１）と前記スマートカード（２ａ）の間の第３データ交換セッションを開く段階であって、このセッション中に、端末の前記自律的第１ソフトウェアエンティティ（１３２）が前記第１ロードプログラム（ＯＬ）により送られたロードファイル（７）を送信し、前記ロードファイル（７）は前記ロードパラメータ表示データを考慮し且つロードすべき前記ソフトウェア（Ｄａ）に関連するデータ（７０、７１、７２）を含む、段階とを有し、前記少なくとも１つの第２ソフトウェアエンティティ（ＡＴＳ１〜ＡＴＳｎ）は、前記ＣＧＩ機能の実行により、前記第２ロードプログラム（ＩＬ）に関連する前記一連の指令を解釈してこれを命令列へ翻訳し、前記命令列が前記スマートカードへの前記ソフトウェア（Ｄａ）の前記ロードの実行のために、前記第２ロードプログラム（ＩＬ）を活性化することを特徴とする方法。
【請求項２】
前記スマートカード読取装置（３）と前記スマートカード（２ａ）は、標準ＩＳＯ７８１６によって定義された所定の前記第１プロトコルによる前記データ伝送のための第１および第２プロトコルスタックを含み、各々は、前記スマートカード（２ａ）と前記端末（１）との間の前記データ交換を可能にするように、少なくともいわゆる低層のソフトウェア通信プロトコル層（１０１、２００ａ）を含み、これらの層は、それぞれ前記の特定通信プロトコル層を形成する前記の第１（２３ａ）および第２（１３）の特定ソフトウェアとインターフェースを形成し、これらのソフトウェア（１３、２３ａ）は各々、第１および第２プロトコルスタックの前記低層（１０１、２００ａ）とインターフェースを形成するデータ転送モジュール（１３０、２３０ａ）と管理モジュール（１３１、２３１ａ）とから構成される２つの追加エンティティを含み、および各対の前記第１エンティティは、前記セッションを確立するインテリジェントエージェント（１３２、２３２ａ１）と呼ばれるソフトウェアモジュールから構成されることを特徴とする請求項１に記載の方法。
【請求項３】
前記第２ロードプログラム（ＩＬ）に関連する解釈すべき前記一連の指令が、スクリプトによって構成されること、および前記第２ソフトウェアエンティティが、前記第２ロードプログラム（ＩＬ）によって理解できる命令を提供する、スクリプト翻訳インテリジェントエージェント（ＡＴＳ１〜ＡＴＳｎ）と呼ばれるソフトウェアモジュールによって構成されることを特徴とする請求項２に記載の方法。
【請求項４】
前記第１段階が、前記パラメータ表示データを含む「ＨＴＭＬ」言語による決定されたページのアドレス指定によってインターネット形式のプロトコルにより「ＨＴＴＰ」形式の要求を発信することを含み、前記アドレスは前記スマートカード（２ａ）におけるループバック「ＵＲＬ」形式のアドレスであることを特徴とする請求項３に記載の方法。
【請求項５】
前記第２段階が、「ＨＴＭＬ」言語による書式（８、８’）のスマートカード（２ａ）による送信を含むこと、および前記書式（８、８’）が前記スマートカード（２ａ）に少なくとも１つのループバック「ＵＲＬ」形式のアドレスと、前記第２ロードプログラム（ＩＬ）に関連する前記スクリプトを含む所定のディレクトリを導くパスとを含み、こうして前記第１ロードプログラム（ＯＬ）は前記パラメータ表示データを検索することを特徴とする請求項４に記載の方法。
【請求項６】
前記第３データ交換セッションが、ロードすべき前記ソフトウェア（Ｄａ）を表す前記データを含む、「ＨＴＴＰ」形式の要求を、前記第２ロードプログラム（ＩＬ）に関連する前記スクリプトを含む前記ディレクトリを指定する前記アドレス「ＵＲＬ」に送信し、前記スクリプトの解釈が前記ソフトウェア（Ｄａ）をロードする前記第２ロードプログラム（ＩＬ）の実施を可能とする、ことを特徴とする請求項５に記載の方法。
【請求項７】
前記ソフトウェア（Ｄａ）がオブジェクト指向プログラミング言語で書かれたアプレットであることを特徴とする請求項６に記載の方法。
【請求項８】
前記ロードファイル（７）が前記書式（８、８’）の中に組み込まれ、前記アプレットを識別するヘッダ（７０）、データ（７１）、および前記データの暗号化によって得られる少なくとも１つの電子署名（７２）を含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記第３段階の後に実施される少なくとも１つの追加第１段階を含むこと、およびこの追加第１段階が、前記第１ロードプログラム（ＯＬ）によって受信される所定のコードを伝送するために、前記スマートカード（２ａ）と少なくとも前記端末（１）との間の追加第１データ交換セッションを開くことから成ることを特徴とする請求項８に記載の方法。
【請求項１０】
前記所定のコードが、前記最初の３段階が正しく進行した場合には肯定応答で構成され、逆の場合にはエラーコードで構成されること特徴とする請求項９に記載の方法。
【請求項１１】
前記第３段階の後に実施される少なくとも２つの追加段階を含み、この追加段階は、追加データの提出を要求する追加書式の伝送のために、前記スマートカード（２ａ）と少なくとも前記端末（１）との間の双方向データ交換セッションを開くことを含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記追加データが追加電子署名を含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記端末がインターネット形式のネットワーク（ＲＩ）を通じて、およびインターネット形式のプロトコルを使用することによって少なくとも１つの遠隔サーバ（４）に接続され、前記のインテリジェントエージェント（１３２）の１つは、前記インターネットネットワーク（ＲＩ）との通信を可能にし、および前記第１ロードプログラム（ＯＬ）は前記遠隔サーバ（４、４ａ）の１つにストックされていることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記端末（１）が「ＷＥＢ」形式のブラウザ（１０）を含み、前記第１ロードプログラム（ＯＬ）は前記「ＷＥＢ」ブラウザ（１０）のソフトウェア構成部分（ＯＬ’）から成ることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ソフトウェア構成部分（ＯＬ’）が、オブジェクト指向プログラミング言語で書かれて前記スマートカード（２ａ）の中にストックされたアプレット（ＯＬ）の動的ロードの初期段階によって得られ、前記ロードは前記スマートカード（２ａ）の「ＵＲＬ」形式アドレス指定により、「ＨＴＴＰ」形式の要求の発信によって得られることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ソフトウェア構成部分（ＯＬ’）が、オブジェクト指向プログラミング言語で書かれて前記遠隔サーバ（４）の１つの中にストックされたアプレット（ＯＬ）の動的ロードの初期段階（ＯＬ）によって得られ、前記ロードは前記遠隔サーバ（４）の「ＵＲＬ」形式アドレス指定により、「ＨＴＴＰ」形式の要求の発信によって得られることを特徴とする請求項１４に記載の方法。
【発明の詳細な説明】
【０００１】
本発明は、ソフトウェアをスマートカード内にロードする方法に関する。
【０００２】
本発明は、より詳細には、フランス語で「ａｐｐｌｉｑｕｅｔｔｅ」と呼ばれ、「アプレット」という英語の用語でより広く知られているソフトウェアをロードすることに適用される。これは、「ＪＡＶＡ」（登録商標）言語で記述されたアプリケーションのことである。一般に小さいサイズであるこれらのアプリケーションは、それらがそこに埋め込まれるシステムのアーキテクチャとは独立している。したがって、これらのアプリケーションは、どのような情報処理システム上であっても、そのシステムが「ＪＡＶＡ仮想マシン」（「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ」）と呼ばれる概念を実装している限り、動作することができる。ＪＡＶＡ言語で記述されたアプリケーションは、一般に、「バイトコード」と呼ばれる中間言語に変換される。前記ＪＡＶＡ仮想マシンは、この「バイトコード」が前記仮想マシンのホストである目標システム上で直接に実行されるようにするインタープリタを成す。
【０００３】
一般に、この型のアプリケーションがそこで動作するシステムアーキテクチャは、クライアント−サーバ型と呼ばれる型のものである。この場合、サーバシステム上に記憶されたアプリケーションに関しては「サーブレット」とも呼び、またクライアントシステム上に記憶されたアプリケーションに関しては「アプレット」とも呼ぶ。下記では、一般的な意味で「アプレット」という用語を使用する。
【０００４】
上記に想起した「アプレット」の形態をとるソフトウェアは、コードの量が大きすぎない限り、他のどのアプリケーションとも同様に、スマートカード上に存在する不揮発性メモリ内に記憶することができる。
【０００５】
また、本発明による方法は、より詳細には、スマートカードの読取装置を備えた利用者端末または利用者ステーションに関する。
【０００６】
本発明の枠組みでは、「端末」という用語は、一般的な意味で理解されたい。前記端末は、具体的には、ＷＩＮＤＯＷＳまたはＵＮＩＸ（両方とも、登録商標）などの様々なオペレーティングシステムの下で動作するパーソナルコンピュータによって構成することができる。また、端末は、ワークステーション、可搬コンピュータ、またはいわゆる専用カード端末によっても構成することができる。
【０００７】
現行の技術では、スマートカード上に「アプレット」をロードすること（遠隔ロードとも呼ばれる）は、２つの特定プログラムを利用して行われる。これらのプログラムは、一般的に、第１のものは「Ｏｆｆ−Ｌｏａｄｅｒ」、また第２のものは「Ｉｎ−Ｌｏａｄｅｒ」という英語の用語で知られている。プログラム「Ｏｆｆ−Ｌｏａｄｅｒ」は、端末上で実行され、プログラム「Ｉｎ−Ｌｏａｄｅｒ」は、スマートカード内で実行される。ロードプログラムである「Ｏｆｆ−Ｌｏａｄｅｒ」と「Ｉｎ−Ｌｏａｄｅｒ」は、スマートカードとそのホスト端末間の通信に関する統一プロトコルとしてサポートされるＩＳＯ７８１６−３型の規格化されたリンクを介して互いに通信を行う。このプロトコルは、「アプレット」のロードを実現するため、一般にプロプラエタリ型の一連の交換（下記に説明するいわゆる「ＡＰＤＵ」型コマンド）を実施する。
【０００８】
本明細書に添付する図１Ａは、知られている技術によりスマートカード内に「アプレット」をロードするために実装されるアーキテクチャを概略で示している。
【０００９】
端末１は、ＯＬと呼ぶ第１特定ロードプログラム（「Ｏｆｆ−Ｌｏａｄｅｒ」）を記憶する。この端末は、スマートカード読取装置３を介して、スマートカードと通信を行う。この伝送は、前記コマンドを利用する規格化された通信プロトコルに従って実行され、このプロトコルは、下記に説明する。
【００１０】
スマートカード２の方は、ＩＬと呼ぶ第２特定ロードプログラム（「Ｉｎ−Ｌｏａｄｅｒ」）を記憶する。
【００１１】
この方法の第１の不都合は、プログラムＩＬおよびＯＬが、互いに通信できるには、対になっていなければならないことである。このことから、これらのプログラムが別々のオリジンのものである場合、先験的には、それらは互換性がないことになる。この特徴は、使用する１組のコマンドに関連している。
【００１２】
第２の不都合は、通信が、前記ＩＳＯ７８１６プロトコルに従って実行されることによる。というのは、このプロトコルは、プログラムＯＬおよびＩＬが物理的に近接していることを要件とする。このことから、プログラムＯＬは、一般に、例えば別の端末上または遠隔サーバ上ではなく、端末１上で直接に実行されなければならないことになる。
【００１３】
さて、インターネットの目覚しい発展とともに、ますます多くの端末が、このネットワークに接続され、具体的には、これは「ＷＥＢ」型の遠隔サーバとリンクできるようにするために行われる。したがって、このネットワークに接続された「ＷＥＢ」サーバ上に、例えば、「アプレット」ロードプログラムの「Ｏｆｆ−Ｌｏａｄｅｒ」部分を記憶できることに関心が持たれるであろう。さらに、１つまたは複数のスマートカード上にロードする「アプレット」をこのサーバ上、あるいは１つまたは複数のこの型のサーバ上に記憶することもできよう。
【００１４】
現行の技術では、この動作モードは、二重の不可能に直面する。その第１のことは、すでに言及した。端末とスマートカードの間の通信でサポートされる規格が、先験的に、「Ｏｆｆ−Ｌｏａｄｅｒ」プログラムＯＬと「Ｉｎ−Ｌｏａｄｅｒ」プログラムＩＬの配置が互いに物理的に近接しているのを要件とすることである。
【００１５】
他方、インターネットを介する、例えば端末と遠隔サーバという２つのシステム間の伝送は、インターネット型プロトコルを利用する。現行の技術では、下記に同様に説明するとおり、スマートカードとインターネットの間で直接の通信を実現することができない。
【００１６】
本発明の枠組みでは、「インターネット」という用語は、本来のインターネットだけでなく、いわゆる「イントラネット」型の企業専用ネットワークまたは類似のネットワーク、およびそれらを外部に向けて延長したいわゆる「エクストラネット」型のネットワーク、ならびにデータ交換がそこでインターネット型プロトコルに従って実行される一般的にどのようなネットワークも包括する。下記では、そうしたネットワークを一般的に「インターネット」と呼ぶ。
【００１７】
まず第１に、図１Ｂおよび１Ｃを参照して、インターネットに接続された、スマートカードに基づいてアプリケーションシステムの全体的アーキテクチャを簡単に思い起そう。
【００１８】
スマートカードに基づくアプリケーションシステムは、一般に、以下の主要エレメントを有する。
【００１９】
−スマートカード
−上記端末を構成するホストシステム
−通信ネットワーク、すなわち好ましいアプリケーションにおけるインターネット
−インターネットに接続されるアプリケーションサーバ。
【００２０】
図１Ｂは、この型のアーキテクチャの一例を概略で示している。端末１、例えば個別コンピュータは、スマートカード２の読取装置３を有する。この読取装置３は、端末１内に物理的に一体化することも一体化しないことも可能である。スマートカード２は、入出力接続が、端末１との通信および電気力供給を許可するためにそのサポートの表面と同じ高さにある集積回路２０を有する。この端末は、インターネットＲＩへのアクセス回路１１を有する。これら回路は、交換電話回線または、より高容量の通信手段、すなわち、サービス統合型デジタルネットワーク（「ＲＮＩＳ」）、衛星によるケーブルまたは回線等に接続されるために、モデムで構成される。回路１１は、直接またはインターネットサービス提供者（英語では「インターネットサービスプロバイダ」または「ＩＳＰ」）を介して、インターネッＲＩに接続されることができる。同じく、「プロキシ」または「ファイアウォール」と呼ばれる（（フランス語では）「ｐａｒｅ−ｆｅｕ」または「ｇａｒｄｅ  ｂａｒｒｉｅｒｅ」とも呼ばれる）システムのような中間システムに頼ることもできる。
【００２１】
端末１は、当然のことながら、図面を簡略化するためにここには図示されていないが、中央処理装置、ＲＡＭおよびＲＯＭ、磁気ディスク大容量メモリ、ディスケットおよび／またはＣＤＲＯＭ等といった、その円滑な作動に必要なあらゆる回路および機構を備える。
【００２２】
通常、端末１はまた、ディスプレイスクリーン５、キーボード６ａ、マウス６ｂ等のような、一体型または非一体型の従来の周辺装置に接続される。
【００２３】
端末１は、ネットワークＲＩに接続されたサーバまたはすべての情報処理システムと通信することができ、図１Ａにはその１つ４だけが図示されている。アクセス回路１１は、「ＷＥＢ」ブラウザまたは英語で「ブラウザ」と呼ばれる特定のソフトウェア１０によって、端末１をサーバ４と連絡させる。ＷＥＢは一般に「クライアント／サーバ」モードによって、ネットワークＲＩ全体に割り当てられたさまざまなアプリケーションまたはデータファイルにアクセスできるようにする。
【００２４】
慣習的に、ネットワーク上の通信は、重なり合ったいくつものソフトウェア層を含む標準に応答するプロトコルに従って実施される。インターネット形式のネットワークＲＩの場合には、通信は、後で詳しく説明するが同様にいくつものソフトウェア層を包含するこの形式の通信に特定のプロトコルによって実施される。通信プロトコルは、アプリケーション、さらに特定すれば「ＷＥＢ」ページの問合せ、ファイルの転送、電子郵便（ｅ−ｍｅｌ、英語で「ｅメール」）、フォーラム、または「ニュース」等に応じて選択される。
【００２５】
端末、スマートカードの読取装置、スマートカードを有するシステムの論理アーキテクチャは、図１Ｃに概略的に表わされている。また、それ自体が以下のような複数のサブアセンブリを有する、規格ＩＳＯ  ７８１６に記載されている。
【００２６】
−カードの寸法およびマーキングに関してはＩＳＯ  ７８１６−１および７８１６−２。
【００２７】
−端末のスマートカード間のデータの転送に関してはＩＳＯ  ７８１６−３。
【００２８】
−一式の命令の構造とコマンドのフォーマットに関してはＩＳＯ  ７８１６−４。
【００２９】
図１Ｃでは、端末側１に、参照番号１０１として規格ＩＳＯ  ７８１６−３に合致した層と参照番号１０２の命令管理「ＡＰＤＵ」（規格ＩＳＯ  ７８１６−４）のみが表されている。スマートカード２側では、規格７８１６−３に適合した層に参照番号２００が付され、命令管理「ＡＤＰＵ」（規格ＩＳＯ７８１６―４）に参照番号２０１が付されている。アプリケーションには、参照番号Ａ１、…、Ａｊ…、Ａｎが付されるが、この場合、ｎは、スマートカード２上に存在する最大数のアプリケーションである。
【００３０】
アプリケーションＡｊは、スマートカード２内に存在し、一式の命令を用いて端末１と対話する。この一式の命令は、通常、書込み命令と読取り命令を有する。命令のフォーマットは、英語略語「ＡＰＤＵ」（「アプリケーションプロトコルデータユニット」）で知られている。これは上記の規格ＩＳＯ  ７８１６−４によって規定される。コマンド用「ＡＰＤＵ」は、「ＡＰＤＵ．ｃｏｍｍａｎｄ」と記され、応答用「ＡＰＤＵ」は「ＡＰＤＵ．ｒｅｓｐｏｎｓｅ」と記される。「ＡＰＤＵ」は、上記の規格ＩＳＯ  ７８１６−３によって特定されたプロトコルを用いて、カードの読取装置とスマートカードとの間で交換される（たとえば、キャラクタモードではＴ＝０となる。またはブロックモードではＴ＝１となる）。
【００３１】
図１Ｃに示すように、スマートカード２がいくつもの個別のアプリケーションを含む場合には、マルチアプリケーションカードが論じられる。しかし、端末１は一度に１つのアプリケーションとしか対話しない。例えばアプリケーションＡｉは、最初に記録されるかまたは端末１から再びロードされることが可能な「アプレット」の形式で示される。これを実施するために、図１Ａに示すように、端末１の中に記録されているプログラム「オフローダ」ＯＬ、およびスマートカード２のアプリケーションＡｉの１つを形成するプログラム「インローダ」ＩＬを頼りにする。
【００３２】
個別のアプリケーションＡｊの選別は、選別型の「ＡＰＤＵ」（「ＳＥＬＥＣＴ」）を用いて得られる。いったんこの選択がなされると、それに続く「ＡＰＤＵ」が、そのアプリケーションに向って辿られる。新しい「ＡＰＤＵ  ＳＥＬＥＣＴ」は、結果的に、進行中のアプリケーションを放棄して、そこから他のアプリケーションを選択する。「ＡＰＤＵ」２０１の管理者ソフトウェアのサブアセンブリによって、スマートカード２内で個別のアプリケーションＡｊを選択し、そのように選択されたアプリケーションを記憶し、そのアプリケーションに向かって「ＡＰＤＵ」を伝達し、またそのアプリケーションから「ＡＰＤＵ」を受取ることが可能になる。
【００３３】
以上をまとめると、アプリケーションＡｊの選別と、そのアプリケーションとの対話は、命令「ＡＰＤＵ」の交換によって行われる。アプリケーションＡｊは、以下「ＧＣＡ」（「包括的カードアプリケーション」）と呼ばれる従来のアプリケーションであると仮定される。
【００３４】
この操作モードは、プログラムＯＬおよびＩＬが、交換された「ＡＰＤＵ」命令が互換性を有することができ、これらの２つのアプリケーションによって理解できるためには、対にしなければならないことを説明する。
【００３５】
以上の点を思い起した上で、スマートカード２は、市販の標準ブラウザのコードを変更しない限り、そうしたブラウザとは直接対話できない点に留意されたい。
【００３６】
さらに、また特に、そもそも上述の標準および規格に合致している現在のスマートカードは、同じくインターネットと直接通信できないハードウェアおよびソフトウェアの構成を有する。とりわけ、それらは、この型のネットワークで使用されるプロトコルのいずれかに従って、データパケットを受取り、伝達することができない。したがって、一般には、英語で「プラグイン」で呼ばれるものの形で、端末内１に設置される追加ソフトウェアを備えることが必要である。図２Ｂでは参照番号１２が付されているこのソフトウェアは、ブラウザ１０とカード２との、より厳密にはこのカード２の電子回路２０との間のインターフェイスを実施する。
【００３７】
本発明は、必要であると判断されるものに適合させながらも、上述したいくつかの欠点を含む従来の技術による方法および装置の欠点を解消することにある。
【００３８】
本発明の第１の特徴によれば、２つのロードプログラムＯＬ、ＩＬはもはや相互依存関係にない。言い換えれば、これらは互換性を有するためにもはや対になっていない。
【００３９】
本発明の第２の特徴によれば、ロードプログラムの部分ＯＬはもはや端末の中に義務的にストックされておらず、すなわち、第２部分ＩＬと物理的に近い関係にある。全く反対に、プログラムＯＬは、インターネット形式のネットワークを介して端末に接続された遠く離れたサーバにストックすることができる。
【００４０】
これを実施するために、本発明のもう１つの特徴によれば、スマートカードはこれに関連する端末のための「ＷＥＢ」形式のサーバ／クライアントとして挙動する。
【００４１】
この目的を達するため、スマートカード内に特有の通信ソフトウェア層と、端末内にその対になるものが備えられる。「特有の」という用語は、本発明の方法に特有と解釈されなければならない。というのも、特有と呼ばれるこれらの通信層は、当該のアプリケーションがどのようなものであれ一般化されるからである。それらは、一方ではスマートカードと端末との間の、他方ではスマートカードとネットワークとの間の双方向データ交換プロセスにしか関わらない。
【００４２】
特有の通信ソフトウェア層は、とりわけプロトコルの会話を可能にする、「インテリジェントエージェント」と呼ばれるソフトウェアの構成要素を有する。インテリジェントエージェントは、以下、より単純に「エージェント」と呼ぶ。それぞれ端末とスマートカードに関連した特有の通信層内に並べられたエージェントが存在する。本発明の方法によれば、こうしたエージェント間にセッションが確立される。
【００４３】
別の特徴によれば、本発明の方法は、従来の型、すなわち、いかなる点においても変更の必要なく、スマートカード内で探索された、上記の「ＧＣＡ」型のアプリケーションの起動を可能にする。
【００４４】
そのために、ブラウザの要求を受取り、それらを「ＧＣＡ」型のアプリケーションによって理解可能な命令「ＡＰＤＵ」に翻訳するスクリプト変換と呼ばれる個別のインテリジェントエージェントが備えられる。そのことから、スマートカード内に、そもそも従来の「ＷＥＢ」サーバ内では「ＣＧＩ」の名称で知られている類似機能が設けられる。この機能は「ＨＴＴＰ」型のインターネットプロトコルによって、スマートカード内でのアプリケーションの実施を可能にする。
【００４５】
スマートカードへの「アプレット」のロードは、この「ＣＧＩ」インターフェースによって実施することができる。ロードプログラムの部分ＩＬは、スマートカードによって提供される「ＷＥＢ」サーバ機能性に取り付けられた「ｃｇｉスクリプト」と呼ばれることになるコマンドスクリプトであると考えられる。プログラムＯＬとＩＬの間の交換は、英語によれば「ＨＴＭＬ」言語または「ｆｏｒｍｓ」と呼ばれる模範的な書式によって進行可能である。
【００４６】
スマートカード読取装置を通じて端末とスマートカードの間で通信するための前述のＩＳＯ標準を保持しながら、本発明による方法は、「ＴＣＰ／ＩＰ」インターネット通信プロトコルに助力を求めて、ロードプログラムの部分であるＯＬとＩＬの間の交換を可能にし、部分ＯＬおよびロードすべき「アプレット」をローカルまたは遠隔サーバにストックすることができる。
【００４７】
したがって本発明の主な目的は、所定の第１プロトコルによって通信を可能にするスマートカード読取装置を介してスマートカードに接続された端末から前記スマートカード内のソフトウェアの一部分をロードする方法であって、前記のロードは第１および第２ロードプログラムの実施と協働によって行われ、前記第２ロードプログラムは前記スマートカードの中にストックされ、本方法は少なくとも下記の段階すなわち、
ａ／前記スマートカードの中に第１ソフトウェアを導入して、特定の通信プロトコル層を形成することから成る予備的第１段階、
ｂ／前記端末の中に第２ソフトウェアを導入して、特定の通信プロトコル層を形成することから成る予備的第２段階
を含み、
前記の第１および第２ソフトウェアはさらに、少なくとも一対の組み合わせた第１ソフトウェアエンティティを含み、前記エンティティの各々は、少なくとも前記端末と前記スマートカードとの間で双方向データ交換セッションの確立を可能にするように互いに協働し、こうして前記スマートカードは「ＷＥＢ」クライアント／サーバの機能性を提供し、
本方法は、スマートカードが「ＣＧＩ」と呼ばれるゲートウェイインターフェース機能を提供するために前記の特定の第２ソフトウェアと協働するように、一連の命令を解釈するのに適し、一連の命令を翻訳するのに適した少なくとも１つの第２ソフトウェアエンティティを、前記スマートカードに導入することから成る予備的第３段階を含み、前記スマートカードは前記第２ロードプログラムに関連する少なくとも１つの前記一連の命令を含み、
本方法は少なくとも下記のステップすなわち、
１／前記第１ロードプログラムが前記第２ロードプログラムによって供給されたロードパラメータ表示データを回収するための要求伝送のために、少なくとも前記端末と前記スマートカードの間における第１データ交換セッションを開始すること、
２／前記ロードパラメータ表示データを前記第１ロードプログラムに伝送するために、前記スマートカードと少なくとも前記端末との間における第２データ交換セッションを開始することであって、前記パラメータ表示データは、前記第２ロードプログラムに属する前記命令の参照を含み、および
３／前記ロードパラメータ表示データを考慮してロードファイルを提出するために、少なくとも前記端末と前記スマートカードの間における第３データ交換セッションを開始することであって、前記ファイルは、ロードすべき前記ソフトウェアを表すデータを含み、すなわち前記第２ロードプログラムに伝送された一連の命令を発生させるように前記の機能性「ＣＧＩ」を実施することによって、前記第２ロードプログラムに関連する前記一連の命令を解釈して、前記第２プログラムを実行して、前記ソフトウェアの前記アンロードを得ること
を含むことを特徴とする。
【００４８】
添付の図面を参照して、以下に、本発明を説明する。
【００４９】
下記において、到達範囲を何ら限定することなく、反対の言及がない限り、以後本発明の好ましい適用の範囲、すなわちインターネットを介して１つまたは複数の遠隔サーバと接続された端末の枠内の見地に立つものとする。
【００５０】
本発明によるスマートカードの中に局限されたアプリケーション活動化方法を説明すること、ならびにこれを実施するためのアーキテクチャを詳述することの前に、図２を参照して、ネットワークに基づく通信プロトコルの主要特性を簡単に改めて述べることが先ず有用になる。
【００５１】
通信ネットワークのアーキテクチャをさまざまな層によって説明する。例として、「ＩＳＯ」によって定義される「ＯＳＩ」（「Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ」）標準は７つの層を含み、これらの層はいわゆる低い層（例えば物理的伝送のサポートに関するいわゆる「物理」層）から、中間層、特にいわゆる「トランスポート」層を通って、いわゆる高い層（例えばいわゆる「応用」層）に至る。所与の層はそのサービスを直接上位にある層に提供し、適切なインターフェースを介して、直接下位にある層から他のサービスを要求する。これらの層は基本的要素によって通信する。同様にこれらは同じレベルの層と通信することができる。あるアーキテクチャでは、複数の層が存在しないことも可能である。
【００５２】
インターネット形式の環境では、層の数は５層であり、さらに正確に言えば、上位の層から下位の層に向かって、いわゆる応用層（「ｈｔｔｐ」、「ｆｔｐ」、「ｅ−ｍａｉｌ」等）、いわゆるトランスポート層（「ＴＣＰ」）、ネットワークアドレス層（「ＩＰ」）、データリンク層（「ＰＰＰ」、「Ｓｌｉｐ」等）、およびいわゆる物理層である。
【００５３】
再び図２を参照すると、端末１とスマートカード２ａにそれぞれ導入されて照番号１３と２３ａを付けた特定の通信プロトコルのソフトウェア層を除いて、その他の要素、ハードウェア、またはソフトウェアは知られている技術には共通であり、したがって再度詳細に説明する必要はない。
【００５４】
端末１は、たとえばモデムで構成されたネットワークＲＩへのアクセス回路１１を有する。これら回路は、「物理」層と「データリンク」層に対応する、ソフトウェア下層、Ｃ１およびＣ２を包括する。
【００５５】
また、「ネットワークアドレシング」層（インターネットの場合には「ＩＰ」）と「トランスポート」層（「ＴＣＰ」）に対応する、上層、Ｃ３およびＣ４が示されている。アプリケーション上層（「ｈｔｔｐ」、「ｆｔｐ」、「ｅメール」等）は示されていない。
【００５６】
下層、Ｃ１およびＣ２と上層、Ｃ３およびＣ４との間のインターフェースは、一般に「ドライバ下層」と呼ばれるソフトウェア層によって構成される。上層、Ｃ３およびＣ４は、このインターフェイス上に支持され、それらに対応する特有の機能のライブラリまたはネットワークライブラリ１４を介して利用される。インターネットの場合には、「ＴＣＰ／ＩＰ」は、「ソケット」と呼ばれるライブラリを用い利用される。
【００５７】
こうした構造から、ブラウザ１０は、ファイル転送用または電子郵便の送信用の「ＷＥＢ」ページ（「ＨＴＴＰ」プロトコル）の閲覧のために、サーバ４に向かって要求を出すことが可能であり、それはまったく従来の方法で行われる。
【００５８】
端末１はまた、一体型または非一体型のカード読取装置３を有する。スマートカード２ａと通信するために、カード読取装置３０はまた、層Ｃ１およびＣ２と類似の役割を果たす、２つの低層、ＣＣ１（物理層）とＣＣ２（データリンク層）を包括する。層ＣＣ１およびＣＣ２とのソフトウェアインターフェイスは、たとえば、仕様「ＰＣ／ＳＣ」（「第６部、サービスプロバイダ」）によって説明される。層自体、ＣＣ１およびＣＣ２は、特に、上述したように、規格ＩＳＯ  ７８１６−１から７８１６−４によって説明される。
【００５９】
補足的ソフトウェア層１６は、応用層（ここには図示されていない）と下層、ＣＣ１およびＣＣ２との間でインターフェイスを形成する。この層１６に割り当てられる主要機能は、マルチプレキシング／デマルチプレキシング機能である。
【００６０】
スマートカード２ａとの通信は、「ＵＮＩＸ」型オペレーティングシステム、すなわちＯＵＶＲＩＲ（「ＯＰＥＮ」）、ＬＩＲＥ（「ＲＥＡＤ」）、ＥＣＲＩＲＥ（「ＷＲＩＴＥ」）、ＦＥＲＭＥＲ（「ＣＬＯＳＥ」）等におけるファイルの操作のために使用されるものと類似のパラダイムに従って行われる。
【００６１】
スマートカード２ａ側には、類似の構造、すなわち参照番号ＣＣａ１（物理層）およびＣＣａ２（データリンク層）が付された２つの低層の存在、さらには層１６とまったく同じインターフェイス層２６ａが見られる。
【００６２】
本発明の第１の特徴によれば、両側に、すなわち端末１およびスマートカード２ａにおいて、特有の２つのプロトコル層、つまり、それぞれ１３および２３ａが備えられる。
【００６３】
端末１においては、特有の層１３は、マルチプレキシング層１６を介して、「ドライバ低層」１５、ネットワーク層Ｃ３およびＣ４のライブラリ１４、さらに、カード読取装置３のプロトコル層、すなわち下層ＣＣ１およびＣＣ２とインターフェイスしている。特有の層１３は、スマートカード２ａから、またスマートカード２ａに向かって、ネットワークパケットの転送を可能にする、さらに、この層は、スマートカード２ａを利用する用途に、インターネットブラウザ１０や電子郵便等のような既存のアプリケーションを適合させる。
【００６４】
スマートカード２ａ側には、層１３と対をなして、参照番号２３ａが付された特有の層の補足的インスタンスで構成されたまったく同様の構造が見られる。
【００６５】
より厳密には、特有の層１３および２３ａは、以下の３つの主要なソフトウェアエレメントに細分割される。
【００６６】
−従来の層ＣＣ１、ＣＣ２、ＣＣａ１およびＣＣａ２を介する、層１３と２３ａの間の情報ブロックの転送モジュール１３０または２３０ａ、
−たとえば、プロトコルの変換機能を実行する「インテリジェントエージェント」１３２または２３２ａと呼ばれる１つまたは複数のソフトウェア、
−個別のインテリジェントエージェントと同一視することができるモジュールである、特有の構成の管理モジュール、１３１および２３１ａ。
【００６７】
以下、簡略化するために、先述したように、インテリジェントエージェントを「エージェント」と呼ぶ。
【００６８】
したがって、端末１とスマートカード２ａ内に、２つのエンティティ間の通信プロトコルスタックが見られる。
【００６９】
レベル２の層（データリンク層）ＣＣ２およびＣＣａ２は、スマートカード２ａと端末１との間の交換を行う。それらの層は、伝送エラーの検出と、場合によっては補正を行う。種々のプロトコルが使用可能であり、以下は限定的ではなく、あくまで例示的なものである。
【００７０】
−勧告ＥＴＳＩ  ＧＳＭ１１．１１、
−キャラクタモードＴ＝０における、規格ＩＳＯ  ７８１６−３によって規定されたプロトコル、
−ブロックモードＴ＝１における、規格ＩＳＯ  ７８１６−３によって規定されたプロトコル、または
−フレームモード「ＨＤＬＣ」（「Ｈｉｇｈ−Ｌｅｖｅｌ  Ｄａｔａ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  ｐｒｏｃｅｄｕｒｅ」の略）において、規格ＩＳＯ  ３３０９によって規定されるプロトコル。
【００７１】
本発明の枠組みにおいては、好ましくは、ブロックモードにおけるプロトコルＩＳＯ  ７８１６−３が使用される。
【００７２】
それ自体良く知られている方法で、各プロトコル層に対して、同レベルの層間、さらに層から層へのデータの交換を可能にする一定数のプリミティブが関連付けられる。例として、レベル２の層に関連付けられるプリミティブは、カードによる「データ要求（「Ｄａｔａ．ｒｅｑｕｅｓｔ」）および「データの確認」（「Ｄａｔａ．ｃｏｎｆｉｒｍ」）等の型である。
【００７３】
より特有の方法では、層１３および２３ａは、スマートカード２ａとホスト、すなわち端末１との間の対話を担当する。それらの層は、たとえば、「ＨＴＭＬ」フォーマットにおけるハイパーテキストの形で実行されるメニュを介して、端末１のユーザ（図示せず）とスマートカード２ａとの間の情報交換を可能にする。それらはまた、データパケットの送信および／または受信のために適合した構成の設置を可能にする。
【００７４】
上述したように、層は３つの別々のエンティティを有する。
【００７５】
第一の層１３０または２３０ａは、主に、ソフトウェアマルチプレクサで構成される。それは、プロトコルのデータユニットの形で、スマートカード２ａとホスト端末１との間の情報交換を可能にする。第一の層は、データパケットの交換器と類似の役割を果たす。それらのユニットは、レベル２の層（データリンク層）を介して送信または受信される。この通信用の個別プロトコルは、少なくとも一対のエージェントの連絡を確立させることができる。各対の第１のエージェント１３２は、端末１側の層１３内に位置し、第２のエージェント２３２ａは、スマートカード２ａ側の層２３ａ内に位置する。２つの「エージェント」間のリンクは、「Ｓ−エージェント」と呼ぶことができるセッションに関連付けられる。セッションは、これら２つのエージェント間の双方向データ交換である。層１３および２３ａのいずれか一方が、複数のエージェントを有する場合には、同一層のエージェントはまた、互いの間で、および／または、個別のエージェントを構成するモジュール１３１および２３１ａとのセッションを確立することができる。
【００７６】
より厳密には、エージェントは、端末１によって実施される構成に応じて、レベル３および４の層の機能の全体または一部を実行することができる独立ソフトウェアエンティティである。
【００７７】
エージェントは、個別の特性または属性に関連付けられる。分かりやすくするために、限定的でなく例示的なものとして、以下の６つの特性がエージェントに関連付けられる。
【００７８】
−「ホスト」：端末内で探索されるエージェント
−「カード」：スマートカード内で探索されるエージェント
−「ローカル」：ネットワークと通信しないエージェント
−「ネットワーク」：ネットワークと通信するエージェント（端末側）
−「クライアント」：セッションを初期化するエージェント
−「サーバ」：セッションの要求を受取るエージェント
個別のエージェントは、リファレンス、たとえば１６ビットの整数によって識別される（すなわち、０から６５５３５の間）。上位ビット（ｂ１５＝１）は、リファレンスがローカルであるか（スマートカードまたは端末へのローカル通信）、または、遠隔であるか（ｂ１５＝０）を示す。
【００７９】
エージェントには２つの大きなカテゴリが存在する。固定リファレンスによって識別される「サーバ」型のエージェントと、構成管理モジュールによって付与される一時的と形容されることもある可変リファレンスによって識別される「クライアント」型のエージェント、１３１または２３１ａである。
【００８０】
エージェントは、宛先リファレンスとソースリファレンスとを構成する「プロトコルデータユニット」または「ｐｄｕ」（英語「ｐｒｏｔｏｃｏｌ  ｄａｔａ  ｕｎｉ」の略）と呼ばれるエンティティを用いて互いに通信する。さらに、この「ｐｄｕ」を、一般に使用されている英語「Ｓｍａｒｔ  Ｃａｒｄ」を参考にして、「ＳｍａｒｔＴＰ  ｐｄｕ」と呼ぶこともできる。「ｐｄｕ」は、特に、以上に規定したリファレンスを使用する。
【００８１】
「ＳｍａｒｔＴＰ  ｐｄｕ」または、以下、より簡単に「ｐｄｕ」は、「ｐｄｕ」の性質を明示する以下のようなフラグおよびオプションのデータを構成する、ソースリファレンス、宛先リファレンス、ビット集合を有する。
【００８２】
−「ＯＰＥＮ」（開始）フラグは、セッション開始を示すために位置決めされる。
【００８３】
−「ＣＬＯＳＥ」（閉鎖）フラグは、セッションの閉鎖を示す。
【００８４】
−「ＢＬＯＣＫ」（鎖錠）フラグは、エージェントが、その通信相手の応答を待っている状態であり、あらゆる活動を一時停止することを示す。
【００８５】
データをもたない「ｐｄｕ」はトークンと呼ばれる。
【００８６】
「ＳｍａｒｔＴＰ」エンティティは、宛先エージェントの存在をコントロールし、そのエージェントに向かってパケットの通信を実行する。
【００８７】
セッションエージェント「Ｓ−Ａｇｅｎｔ」は、３つの注目すべき状態を有する。すなわち、
−接続解除されている状態。いかなるセッションも他のエージェントには開始されていない。
【００８８】
−接続されている状態。セッションが他のエージェントに開始されている。「Ｓ−Ａｇｅｎｔ」セッションは、一対のリファレンスによって識別される。
【００８９】
−ブロックされている状態。エージェントが接続され、その通信相手の応答を待つ状態。
【００９０】
「Ｓ−エージェント」セッションの確立メカニズムは、以下の通りである。
【００９１】
−クライアントエージェントの新しいインスタンスが創設され（スマートカードまたは端末側）、このエージェントは、擬似単一一時リファレンスによって識別される。
【００９２】
−クライアントエージェントは、位置決めされた「ＯＰＥＮ」フラグとともにサーバエージェント（そもそも、そのリファレンスはすでに知られている）宛てに「ｐｄｕ」を送信し、クライアントエージェントは、「ブロック」フラグの値に従って接続またはブロックされる状態に移行する。さらに
−サーバエージェントは、「ＯＰＥＮ」フラグとともに「ｐｄｕ」を受け取り、接続された状態に移行する。
【００９３】
いったんセッションが開始されると、２人のエージェントが「ｐｄｕ」を介してデータを交換する。
【００９４】
セッションの閉鎖メカニズムは以下の通りである。
【００９５】
−エージェントは、場合によってはデータを有する、位置決めされたフラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を送信する。
【００９６】
−他のエージェントは、（場合によってはデータを有する）位置決めされたフラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を受取り、「Ｓ−Ａｇｅｎｔ」セッションは、接続解除された状態に移行する。
【００９７】
図３は、上述したような「Ｓ−Ａｇｅｎｔ」セッションの状態のフローチャートを概略的に表わしている。
【００９８】
層１３０および２３０ａは、ホスト端末１およびスマートカード２ａ側で、存在するエージェントディレクトリを含む表（ここには図示されていない）を管理する。
【００９９】
実際に、エージェントは、（たとえば、ハイパーテキストの）データの交換を可能にするが、しかも、スマートカード２ａと遠隔サーバ４との間の通信を許可する、ネットワークトランザクションを開始することができる（図３）。
【０１００】
構成管理モジュール、それぞれ１３１および２３１ａは、個別のエージェントと同一視することができる。たとえば、ホスト端末１側のモジュール１３１は、特に、この端末の構成（作動モード）に関連する情報、たとえば他のエージェントディレクトリ等を管理する。スマートカード２ａ側のモジュール２３１ａは、類似機能を有する。これら２つのエージェントは、セッションを確立するために互いに通信を確立することができる。
【０１０１】
実際に、スマートカード２ａは、有利には、外部サーバへのポインティングではなく、端末１それ自体へのループバックを規定する「ＵＲＬ」アドレス（「Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ」の略）の使用によって「アドレシング」される。例として、この「ＵＲＬ」の構造は通常以下の通りである：
ｈｔｔｐ：／／１２７．０．０．１：８０８０                  （１）
ここで、１２７．０．０．１は、ループバックの「ＩＰ」アドレスであり、８０８０は、ポート番号である。
【０１０２】
図４は、図２に示された型の本発明によるシステムの論理アークテクチャを簡略に、しかもより詳細に表している。スマートカード２ａは、複数のエージェントを有するが、そのうちの２つだけがここに図示されている。厳密には規定されていない型のエージェント２３２ａ１と「ＷＥＢ」型と呼ばれるエージェント２３２ａ２である。論理スタックは、規格ＩＳＯ  ７８１６−３に合致した参照番号２００ａを付された、プロトコル下層（図２：ＣＣａ１およびＣＣａ２）と、コマンド管理「ＡＰＤＵ」２０１ａ１と、パケットのマルチプレクサ２３０ａとを有し、このマルチプレクサは、エージェント、特に「ＷＥＢ」エージェント２３１ａ２にインターフェイスされる。
【０１０３】
端末側には、２つのスタックが存在するが、一方はインターネットＲＩと通信し、他方はスマートカード２ａと通信する。第１のスタックは、ネットワーク（規格ＯＳＩ  １および２）へのアクセス機構１１（図２：Ｃ１およびＣ２）と、参照番号１００が付されたプロトコル「ＴＣＰ／ＩＰ」（図２：Ｃ３およびＣ４）層とを有する。それらの層は「ＷＥＢ」ブラウザ１０とインターフェイスされる。他方のスタックは、規格ＩＳＯ  ７８１６−３に合致した参照番号１０１が付されたプロトコル下層（図２：Ｃ１およびＣ２）と、命令管理「ＡＰＤＵ」１０２と、パケットマルチプレクサ１３０とを有し、このマルチプレクサはエージェントとインターフェイスされるが、そうちの１つだけ、１３２がここに図示されている。このエージェントは「ネットワーク型」と想定され、さらに、一方では「ＴＣＰ／ＩＰ」層１０１を介して、ブラウザ１０と、他方では、それら「ＴＣＰ／ＩＰ」層１０１とネットワークＲＩへのアクセス機構１１とを介してインターネットＲＩと通信することができる。
【０１０４】
命令管理「ＡＰＤＵ」２０１ａはまた、単にアプリケーションと呼ばれるアプリケーションレベルの１つまたは複数の層とインターフェイスされる。それらアプリケーションＡ１…、Ａｉ…、Ａｎ…、は、すでに示したように、従来型のアプリケーションである。
【０１０５】
要約すると、スマートカード２ａによって与えられる「ＷＥＢ」サーバ／クライアント機能は、すでに説明したように、スマートカード内の「ＷＥＢ」エージェント２３２ａ１と、端末１内のネットワークエージェント１３２との関連付けによって、また、エージェント間のセッションによって実行することができる。
【０１０６】
したがって、スマートカード２ａは「ＷＥＢ」クライアント／サーバ機能を明確に表している。さらに、本発明の方法の一特徴によると、上記の「ＧＣＡ」型の従来のどんなアプリケーションＡ１からＡｎも、この「ＷＥＢ」クライアント／サーバを通して、端末１内に存在する「ＷＥＢ」ブラウザ１０によって、もしくは、エージェント間のセッションの実施によって、インターネットＲＩの何らかのポイントで探索された遠隔ブラウザ４によって、起動することができる。本発明の方法によれば、アプリケーションＡ１からＡｎは、書き直す必要なく、そのまま利用することができる。
【０１０７】
本発明の枠内では、アプリケーションＡ１〜Ａｎの全てまたは部分は、スマートカード２の不揮発性メモリの中に最初にロードされたか、またはそうではなく２つのロードプログラムＯＬおよびＩＬを介してロードされた「アプレット」によって構成することができる。ロードプログラムＯＬ、ＩＬの性質とその可能なストック場所は後で明確に述べる。
【０１０８】
本発明の別の一態様によれば、スマートカードによって提供されたサーバ機能「ＷＥＢ」は、従来の「ＷＥＢ」サーバの中に導入されたいわゆる「ＣＧＩ」（「Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ」または「ゲートウェイインターフェース」）の機能に似た機構を含む。
【０１０９】
スマートカード内であっても、この型の機能を実行できる本発明に合致したアーキテクチャの一例を示す前に、「ＣＧＩ」作動モードの主要な特徴を思い起すことが有益である。
【０１１０】
「ＣＧＩ」は、オペレーティングシステム「ＵＮＩＸ」（登録商標）、「ＤＯＳ」、または「ＷＩＮＤＯＷＳ」（商標）のために書き込まれたアプリケーションの「ＷＥＢ」サーバからの実施仕様である。例として、「ＵＮＩＸ」オペレーティングシステムについては、仕様は「ＣＧＩ  １．１」であり、「ＷＩＮＤＯＷＳ９５」オペレーティングシステムについては、仕様は「ＣＧＩ  １．３」である。
【０１１１】
常に例示的なものとして、「ホスト」がホストシステム（一般に遠隔）を参照する、
「ｈｔｔｐ：／／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｘｘｘ．ｃｇｉ」                                                            （２）
の型の「ＵＲＬ」アドレスについての要求「ＨＴＴＰ」は、「ｘｘｘ」と名付けられ、このホストシステムのディレクトリ内に存在する「ＣＧＩ」型のコマンドスクリプトの実行として、「ＷＥＢ」サーバによって解釈される。ディレクトリの名前は、先験的に何でもよいにもかかわらず、それは、従来、「ＣＧＩ」型のスクリプトを保存するディレクトリに与えられる名前である。スクリプトは、ホストシステムのオペレーティングシステムの命令セットであり、その最終的結果は、上記の要求を送信する「ＷＥＢ」ブラウザに伝送される。このスクリプトを書き込むために、種々の言語、たとえば「ＰＥＲＬ」言語（登録商標）を使用することができる。
【０１１２】
実際には、要求は、通常、「ＨＴＬＭ」ページ内に含まれる書式の形で情報処理スクリーンに表示される。「ＨＴＬＭ」言語は、書式を「ＵＲＬ」アドレスに翻訳することができる。書式は、強制的または非強制的に１つまたは複数のフィールドを有し、それらは、通常の入力手段、すなわち、テキスト用にはキーボード、チェックボックスにはマウス、または「ラジオ」と呼ばれるボタン等を用いてユーザによって書き込まれる。書式の内容（さらに、場合によっては「隠し」情報と呼ばれる情報および命令）は、「ＷＥＢ」サーバ宛てに送信される。ページの「ＨＴＬＭ」コードは、書式のハードウェア構造（枠、デザイン、色、他のあらゆる属性）、ならびにインプットされるデータフィールドの構造（名称、長さ、データの型等）を説明する。
【０１１３】
伝送は、２つの型の主要なフォーマットに従って行うことができる。最初のフォーマットは、「ＰＯＳＴ」と呼ばれる方法を使用し、第２のフォーマットは「ＧＥＴ」と呼ばれる方法を使用する。フォーマット型情報は、書式ページのコード内に存在する。
【０１１４】
しかしながら、このメカニズムは、スマートカードが、本発明の特徴のいずれか１つに従って「ＷＥＢ」クライアント／サーバ機能を提供するとしても、直接スマートカードに移し替えられるわけではない。
【０１１５】
ここで、図５を参照して、スマートカードにおける「ＷＥＢ」サーバを介して、従来型の何らかのアプリケーションを起動することができるアーキテクチャの一例を説明しよう。
【０１１６】
本発明の様態の１つに従うインテリジェントエージェントの中には、以下、「スクリプト変換エージェント」、または略して「ＡＴＳ」と呼ばれる個別のインテリジェントエージェントが備えられる。こうして、スクリプトは、これら「インテリジェント」エージェントの１つによって解釈される。この翻訳は、以下のように種々の方法で実行することができる。
【０１１７】
ａ／この場合、二重の容量を備える、「ＷＥＢ」エージェント２３２ａ１によって、
ｂ／スマートカード２ａ内に存在するスクリプトの集合を翻訳することができる単一のスクリプトエージェントによって、
ｃ／以下「ＡＴＳＤ」と呼ばれる専用スクリプトエージェント（スクリプトごとに１つのエージェント）によって、または
ｄ／その場合、二重の容量を備えた、命令管理「ＡＰＤＵ」２０１ａの「ＡＰＤＵ」エージェント２０１０ａによって。
【０１１８】
「ＡＰＤＵ」エージェント２０１０ａは、命令管理「ＡＰＤＵ」層２０１ａの構成要素である。この層は、システムによって送信および／または受信されるあらゆる「ＡＰＤＵ」命令を集中させ、Ａ１からＡｎの中からアプリケーションを選別し、しかもインテリジェントエージェント型のインターフェイスを提供することができる層である。したがって、本発明の特徴の１つによれば、それらエージェントが構内６内で探索されようと、スマートカード２ａ内で探索されようと、あらゆるインテリジェントエージェントと通信することができる。
【０１１９】
上記のｃ／の場合には、セッションは、「ＷＥＢ」エージェント２３２ａ１と「ＡＴＳＤ」エージェントの１つとの間で開始される。
【０１２０】
図５は、変換エージェントが「ＡＴＳＤ」型であるようなアーキテクチャの一例を表している。それらは、参照番号ＡＴＳ１からＡＴＳｎが付されているが、アプリケーションＡ１からＡｎに関連付けられる。選別されたアプリケーションは、アプリケーションＡｉであると想定されるので、セッションは「ＷＥＢ」エージェント２３２ａ１とエージェントＡＴＳｉとの間に確立される。
【０１２１】
スクリプト変換エージェントは、命令セット「ＡＰＤＵ」を発生する。セッションは、変換エージェント、たとえばエージェントＡＴＳｉと「ＡＰＤＵ」エージェント２１０１ａの間で開始される。こうして、命令は、「ＡＰＤＵ」命令２１０１ａに向かって送信される。命令管理「ＡＰＤＵ」２１０ａは、「ＧＣＡ」アプリケーションＡｉを選別し、そのアプリケーションが理解することができる命令「ＡＰＤＵ」、翻訳された命令、すなわち従来の命令をそのアプリケーションに伝達する。したがって、このアプリケーションは、それを変更するまたは再び書き込みする必要なく、正確に起動される。
【０１２２】
アプリケーションＡｉの応答は、命令管理「ＡＰＤＵ」２１０ａ、「ＡＰＤＵ」エージェント２０１０ａに、さらに再びエージェントＡＴＳｉ（一般的にはスクリプト変換エージェントに）に伝送される。
【０１２３】
種々の経路が、関数型ブロックをつなぐ実線によって、またはこれらブロックの内部の点線によって図５に記号で表されている。
【０１２４】
本発明による方法は、先ほど想起した２つの特性を使用する。すなわち「ｃｇｉ」機能を含む「ＷＥＢ」サーバ／クライアントとしてのスマートカードの働きである。スマートカードへの「アプレット」のロードは、スマートカードによって提供された「ＣＧＩ」インターフェースを経て実際に行われる。
【０１２５】
さらに正確には、本発明による特徴によれば、スマートカード２ａの中に位置決めされたロードプログラムの部分ＩＬは、１つのスクリプトから構成されている。例えば、図５においてＡｉで参照されるアプリケーションに属するスクリプトが重要になる。このスクリプトは、本発明の方法の特徴によれば「ＨＴＴＰ」要求によって活動化され、部分ＯＬと部分ＩＬの間における交換は「ＴＣＰ／ＩＰ」通信プロトコルによって実行される。その結果、プログラムＩＬ、ＯＬは先験的に互換性を持つようになる。その上に、知られている技術（図１を参照）におけるように物理的な近さを尊重する必要はもうない。今後は、部分ＯＬを端末の中、または好ましくは遠隔サーバの中に位置決めすることができ（サーバと端末との間に連絡は「ＴＣＰ／ＩＰ」プロトコルに従って実行される）、またさらには、後で示すようにスマートカード自体の中にストックすることができる。前述の「ＨＴＴＰ」要求は部分ＯＬによって開始される。
【０１２６】
「ＷＥＢ」エージェント２３２ａ１にアドレス指定されたデータが、「パケットマルチプレクサ」２３０ａによって構成された特定のアプリケーションに向けられる「ＡＰＤＵ」命令形式の下で、それ自体従来の方法で運ばれることに注目することは望ましい。「ＡＰＤＵ」命令マネージャ２０１ａは、このアプリケーションを、スマートカード２ａの中に存在する「ＧＣＡ」形式の他のアプリケーションＡ１〜Ａｎに全く似た方法で選択する。換言すれば、パケットマルチプレクサ２３０ａは、「ＡＰＤＵ」命令マネージャ２０１ａによって普通の「ＧＣＡ」アプリケーションとして見られる。
【０１２７】
「ＨＴＴＰ」要求は「ＷＥＢ」エージェント２３２ａ１によって解析され、「ＷＥＢ」エージェント２３２ａ１は、一方では、今後慣習的に（「ｃｇｉビン」との類推によって）「ｃｇｉスマート」と呼ぶことになる特定ページの参照を、前記の例の場合には特定のアプリケーションＩＬの参照を検出する。したがって、完全な経路はこの場合「ｃｇｉスマート／ｉｌ」である。
【０１２８】
本発明の方法の一特徴によれば、上記のエンティティ「ｉｌ」は、同様に特定のアプリケーション（この場合はＩＬ）に関連する特定のスクリプトを指す。
【０１２９】
１つのセッションがインタープリタエージエント、例えばエージェトＡＴＳｉと「ＡＰＤＵ」エージェント２０１０ａとの間に開かれている。スクリプトＡＴＳｉのインタプリターエージェントは一連の命令「ＡＰＤＵ」を発生させる。これらの命令はエージェント「ＡＰＤＵ」２０１０ａに向けて送信される。命令「ＡＰＤＵ」のマネージャ２０１ａはアプリケーション「ＧＣＡ」Ａｉ（例えばアプリケーションＩＬ）を選択して、これに命令「ＡＰＤＵ」を、すなわちこのアプリケーションが理解できる状態にある解釈された、したがって従来型である命令を伝送する。したがって、このアプリケーションは正確に活動化される。
【０１３０】
アプリケーションＩＬ（Ａｉ）の応答は、逆方向に「ＡＰＤＵ」命令のマネージャ２０１ａ、「ＡＰＤＵ」エージェント２０１０ａ、それから再びエージェントＡＴＳｉに、（およびさらに一般的にはスクリプト翻訳エージェントに）伝送される。
【０１３１】
「ＨＴＬＭ」言語の書式によって構成された応答は、端末１に、また場合によっては、最終的にアプリケーションＯＬに到達するためにインターネットＲＩを通じて遠隔サーバ４（図４）に再伝送されるために、対になったインテリジェントエージェントの間のセッションを使用することによって逆経路を再び取る。
【０１３２】
図６は、本発明の方法による「アプレット」のロードを可能にする論理アーキテクチャを示す。この概略図において、端末１、スマートカード読取装置３、およびスマートカード２ａから成るハードウェアブロックが、前述の標準プロトコルＩＳＯ７８１６および命令「ＡＰＤＵ」の交換を利用して、それ自体典型的な方法で通信することが再見される。部分ＯＬは、スマートカード２ａの「ＨＴＴＰ」サーバ機能（ＳＣで示す）および「ＣＧＩ」を使用して、「ＴＣＰ／ＩＰ」インターネットプロトコルによる交換によって、前述の方法で部分ＩＬ（ＩＬｓと呼ぶスクリプトの形態の）と関係付けられる。
【０１３３】
ブロックＳＣおよびＩＬｓは便宜上スマートカード２ａの外側に示されているが、これらのブロックは図５を参照して説明されたスマートカードの様々な内部モジュールによって構成されていることを、よく理解すべきである。
【０１３４】
その代りに、プログラムＯＬを端末１の中にストックする義務はない。
【０１３５】
ここで、「ＧＥＴ」と呼ばれる方法を用いてスマートカード２ａの中に「アプレット」をロードする第１例を詳細に説明する。
【０１３６】
符号７で示された「アプレット」のロードファイルは、図７によって図示される構造、すなわちヘッダ７０、「ＪＡＶＡ」言語で「バイトコード」によって構成された本体７１、および電子署名７２を示すものと想定する。ヘッダは、一般に「アプリケーション識別子」または簡単に「ＡＩＤ」と呼ばれる特定のアプリケーションの識別名を表す。電子署名７２は、コード７１から得られる公開鍵または秘密鍵による暗号である。ファイル７全体も、敏感な前記のアプリケーションが重要になるときには、秘密保持を理由に暗号化される。任意選択として、示されてはいないが、１つまたは複数の追加の電子署名を予定することができる。
【０１３７】
本方法の主な段階を図８に概略的に示す。
【０１３８】
第１段階において、ロードプログラム部分ＯＬは、「ＧＥＴ」形式のコマンドによって、スマートカード２ａからロード書式を、すなわち任意に「ｄａｗｎｌｏａｄ．ｈｔｍｌ」と呼ばれることになる「ＨＴＭＬ」言語による書式を取り込む。
【０１３９】
この取込みは、
ｈｔｔｐ：／／１２７．０．０．１：８０８０／ｄｏｗｎｌｏａｄ．ｈｔｍｌ      （３）
の形式が一般的であるＵＲＬを有する該当ページを参照して実施され、
この形式において、ｈｔｔｐ：／／１２７．０．０．１：８０８０は、関係（１）によって定義されているように、厳密な意味でループバックのアドレスＵＲＬであり、「ｄｏｗｎｌｏａｄ．ｈｔｍｌ」は得るべき「ＨＴＭＬ」ページである。この要求は、本発明の第１態様によって、図２〜４に関連して説明したようにインテリジェントエージェント間のセッションを使用する。そのとき、スマートカード２ａは「ＷＥＢ」サーバの役割を果たす。
【０１４０】
スマートカード２ａは、第２段階では、本発明の方法によって、常に対になったインテリジェントエージェント間のセッションを開くことによって書式「ｄｏｗｎｌｏａｄ．ｈｔｍｌ」を送信する。得られた書式を、ブラウザ１０を介してスクリーン５の上に表示することができる。
【０１４１】
アイデアを決めるために、このような書式８の一例を図９に示す。様々な図形やテキストのゾーン８０（タイトル等）の他に、書式は、ロードファイル７のヘッダ７０、「バイトコード」７１、および署名７２の表示ゾーンを含む。表示ゾーン７１は「ＨＴＭＬ」言語による「ＴＥＸＴＡＲＥＡ」という形式のもので、長いテキストから広げられる表示のための「エレベータ」と呼ばれる機能を示す。該当する情報は、図９において明らかなように純粋に任意である。最後に、それ自体典型的な方式で、送信ボタン「ｓｅｎｄ」８１およびゼロ「リセット」ボタン８２が予定される。これらのボタンは端末のユーザ（図示せず）が自由に使えるようになっている。送信ボタン８１によって、書式を検証してこれをスマートカード２ａに再伝送する（図８においてロードファイルをサブミットする）ことができ、ゼロリセットボタン８２によって、表示された情報を消去して書式を再度初期化することができる。
【０１４２】
このような書式をプログラムするために必要な「ＨＴＭＬ」コードはそれ自体よく知られており、当業者には理解できるものである。したがって再度これを詳述する必要はない。しかしながら、これは「ＨＴＭＬ」言語によって一般的に
＜ｆｏｒｍ  ａｃｔｉｏｎ＝“ｈｔｔｐ：／／１２７．０．０１：８０８０／ｃｇｉ−ｓｍａｒｔ／ｌｏａｄｅｒ”＞                            （４）
という形で表される、特に１行を含むことを指摘することができ、ここでｈｔｔｐ：／／１２７．０．０１：８０８０は関係（１）のループバックのＵＲＬであり、ｃｇｉ−ｓｍａｒｔは、「ｉｌ」と呼ばれるロードスクリプト「ｌｏａｄｅｒ」、すなわちロードプログラムの部分ＩＬに関連するスクリプトを含む前述の「ＣＧＩ」ディレクトリである。
【０１４３】
スクリーン５における書式８の可視表示が望まれない場合には（例えば、人間のオペレータが居ない場合には）、情報を隠して、次の「ＨＴＭＬ」パラメータ、「ＴＹＰＥ＝ｈｉｄｄｅｎ」を前述のコード行（４）の中に組み込むことができる。
【０１４４】
第３段階では、部分ＯＬは、常に対になったインテリジェントエージェント間のセッションを開くことによって「ＧＥＴ」形式の「ＨＴＴＰ」要求をスマートカード２ａに送信する。スマートカード２ａによって提供された「ＣＧＩ」機能に助力を求めて、図５に関して述べたように、アプリケーションＩＬが実行され、スマートカード２ａによって形成された「ＷＥＢ」サーバは「ＨＴＴＰ」要求のパラメータをこの最後のアプリケーションに渡す。
【０１４５】
前述の要求は、一般的に
Ｓｍａｒｔ／ｌｏａｄｅｒ？ＡＩＤ＝ｘｘｘ＆ＢｙｔｅＣｏｄｅ＝ｙｙｙ＆Ｓｉｇｎａｔｕｒｅ＝ｚｚｚ                                          （５）
の形の一般的な１行のコードを含む。
【０１４６】
ただし、「ｘｘｘ」はヘッダ７０（図９の例では「２００１」）、「ｙｙｙ」は「バイトコード」７１（図９の例では「０１２３４５６７８９ＡＢＣＤＥＦ」）、および「ｚｚｚ」は電子署名７１（図９の例では「０１２３４５６７８９ＡＢＣＤＥＦ」）である。したがってロードファイルのこれら３つの部分は、連鎖形式で「ＨＴＭＬ」書式８の３つのフィールドにうまく挿入される。
【０１４７】
この時、ヘッダ７０によって識別される特定の「アプレット」のロードが行われる。
【０１４８】
最後に第４段階では、リターンコードが部分ＩＬから部分ＯＬへ、常に対になったエージェント間のセッションを開くことによって伝送される。一般に簡単な肯定応答が問題であり、または操作が正しく行われない場合には、エラーコードが問題になる。この最後の場合には第１段階から第４段階までを繰り返す必要がある。
【０１４９】
代替の解決策として、前述の「ＰＯＳＴ」方法を使用することが可能である。アイデアを決めるために、図１０はこのような書式８’の一例を示す。テキストおよび図形の様々なゾーン８０、すなわちヘッダ表示ゾーン７０および電子署名表示ゾーン７２、ならびに送信ボタン「ｓｅｎｄ」８１とゼロリセットボタン「Ｒｅｓｅｔ」８２が見られる。これらの要素は図９の同じ参照符号の要素と全く同様な役割を果し、これを再度説明する必要はない。代りに、表示ゾーン７１’はもはや明確に「バイトコード」を示さず、ロードすべき「アプレット」のコードが記録されるディレクトリまたはサブディレクトリを示す。この際、このゾーンは、端末１内に存在するハードディスクにすることができる「Ｃ」と呼ばれるストック装置に記録された任意に「ＡＰＰＬＥＴ．ＢＩＮ」と呼ばれるファイルを指す。ナビゲーションの追加ボタン「ｂｒｏｗｓｅ」８３によって、このディスクの様々な（サブ）ディレクトリを走査して、特定のファイル（「ＡＰＰＬＥＴ．ＢＩＮ」）を選択することができる。
【０１５０】
「ＰＯＳＴ」方法は「ＧＥＴ」方法と同様にそれ自体よく知られており、これを再度詳細に説明する必要はない。本発明の正確な範囲内で、ファイル「ＡＰＰＬＥＴ．ＢＩＮ」に対応する「ａｐｐｌｅｔ」は、装置「Ｃ」から、「ＧＥＴ」方法のために説明したものと同様な方式でロードされる。
【０１５１】
ここで、スマートカード２ａの中に「ａｐｐｌｅｔ」をロードする第２例を説明する。
【０１５２】
やはり、ロードの際に多くの書式をつなぎ合わせることが可能である。簡単な状況（図８に関して説明した第１例における肯定応答またはエラーコード）の代りに、この場合、部分ＩＬの戻りは新しい書式を含む。こうして、部分ＯＬとＩＬの間の動的交換順序を実施することができる。
【０１５３】
例えば、ロードファイルを解析した後に、部分ＩＬは追加の許可（すなわち電子署名）、例えば政府機関の許可を求めることができる。こうして部分ＩＬはＯＬに、一般的に下記の構造「ＨＴＭＬ」を有することができる書式を返送する。
【０１５４】
【表１】
0003834239.tif 000002
ただし、「＜ＴＩＴＬＥ＞」と／＜ＴＩＴＬＥ＞を付けた「ＨＴＬＭ」標識の間の「Ａｕｔｈｏｒｉｓａｔｉｏｎ  ｆｏｒｍ」は書式の（任意の）のタイトル、「＠ｃａｒｔｅ」は関係（１）のループバックのアドレスＵＲＬの文字による翻訳、８０８０はポートの番号を表し、コード列、
＜ＩＮＰＵＴ  ＴＹＰＥ＝“ｔｅｘｔ”  ＮＡＭＥ＝“ＧｏｕｖＳｉｇｎａｔｕｒｅ”  ＭＡＸＬＥＮＧＴＨ＝“８”＞Ｓｉｇｎａｔｕｒｅ          （７）
は、任意に「Ｓｉｇｎａｔｕｒｅ」と呼ばれる変数をテキストモードによって、最大長８オクテットで入力することを要求し、＜／ＦＯＲＭ＞は書式コードの最後を示す「ＨＴＭＬ」標識である。
【０１５５】
したがって完全なプロセスは、最終肯定応答段階の前に２つの追加段階を含み、または図１１に示すように６つの段階を含む。
【０１５６】
さらに一般には、往復の回数は、スマートカードとロードプログラムの部分ＯＬとの間で交換される書式のいずれかにおけるパラメータに依存することができる。
【０１５７】
この時点までは、部分ＯＬの位置決定ははっきりと明確にはなっていない。本方法が先験的にＯＬおよびＩＬを互換性にすることに加えて、本方法はまた、スマートカード２ａの中に存在するアプリケーションの１つを形成するようにこのスマートカードの中に部分ＩＬがストックされることを理解して、この位置決定について確かに非常に大きな柔軟性を可能にする。本発明による方法は特に、２つの部分ＯＬ、ＩＬがもはや通信プロトコルＩＳＯ７８１６に依存しないので、これらの部分間の物理的な近さを要求することはなく、これら２つのソフトウェア間の交換は「ＴＣＰ／ＩＰ」インターネット通信プロトコルを使用する、という追加の利点を提供する。
【０１５８】
さらに部分ＯＬも、厳密に言えばスマートカード２ａにロードすべき「アプレット」のデータも同様に、ローカルまたは遠隔サイトにストックすることができる。しかしながらあらゆる場合に、２つの部分間の交換は今想起したように「ＴＣＰ／ＩＰ」通信プロトコルを使用し、「アプレット」のロードは先に想起したように、スマートカード２ａによって提供される「ＷＥＢ」サーバ／クライアント機能および「ＣＧＩ」によって展開する。
【０１５９】
ここで図１２Ａ〜１２Ｇを参照して、本発明の枠内で使用することのできる主要アーキテクチャを説明する。
【０１６０】
図１２Ａは、部分ＯＬを端末１のローカルにストックするシステムアーキテクチャを示す。この端末はインターネットＲＩを通じて遠隔サーバ４に接続されている。Ｄａで示されたスマートカード２ａの中にロードすべき「アプレット」のデータは、このサーバ４にストックされる。「ＨＴＴＰ」要求は、「ＴＣＰ／ＩＰ」インターネット通信プロトコルを使用して、端末１（および図示されていないがスマートカード読取装置）を通じて、このデータをスマートカード２ａに転送することを可能にする。
【０１６１】
図１２Ｂに示すシステムアークテクチャでは、ロードプログラムの部分ＯＬおよびデータＤａは端末１のローカルにストックされる。端末１をインターネットＲＩに接続することは任意である。最小限に見積もって、この接続は、本発明の方法の各段階によって「アプレット」をロードするためには必要とされない。この接続を点線で示した。したがって端末を独立にすることができる。
【０１６２】
図１２Ｃに示すシステムアークテクチャでは、ロードプログラムの部分ＯＬおよびデータＤａは遠隔サーバ４にストックされる。サーバ４とスマートカード２ａとの間における、インターネットＲＩ、端末１、およびスマートカード読取装置（図示せず）を通じての通信は、「ＨＴＴＰ」要求によって実行され、「ＴＣＰ／ＩＰ」プロトコルを用いる。
【０１６３】
図１２Ｄに示すシステムアーキテクチャは、図１２Ｃに示すものに類似している。唯一の相異は、ロードプログラムの部分ＯＬが第１遠隔サーバ４ａにストックされて、データＤａが第２遠隔サーバ４ｂにストックされることである。
【０１６４】
図１２Ｅに示すアーキテクチャでは、ロードプログラムの部分、ここではＯＬ’は、それ自体ブラウザ１０の一構成部分から成っている。このブラウザの中に統合された「アプレット」を問題にすることが有利である。この場合に使用すべき入力形式は「ｆｉｌｅ」（ファイル）である。
【０１６５】
また有利には、スマートカード２ａにロードすべき「アプレット」のデータＤａを、外部データ記録サポート９、例えば図１２Ｅで示すようなディスケットにストックすることができる。もちろん、他のサポート、すなわちＣＤＲＯＭ、磁気テープ等も使用可能である。
【０１６６】
前述の「ＰＯＳＴ」方法を使用する場合には、ストック装置の文字、例えばディスケット９については「Ａ」、場合によっては経路（ディレクトリ、サブディレクトリ）、およびロードすべきファイルの名を明確に示すことで十分である。アイデアを決定するために、完全な経路は一般的に下記のようにすることができる。
【０１６７】
Ａ：＼ＡＰＰＬＥＴ．ＢＩＮ                          （８）
スマートカード２ａによって提供される「ＷＥＢ」サーバ／クライアント機能から当然、本発明の方法によれば、ブラウザ１０は図２〜４に関して示したように、それ自体従来の技術とは反対に、スマートカード２ａと直接通信できる状態にある。この通信は、対になったエージェント間でセッションを開くことによって実施される。
【０１６８】
図１２Ｆに示すシステムアーキテクチャは図１２Ｅに示すアーキテクチャの変形である。この変形によれば、ロードプログラム部分ＯＬはそれ自体、「ＪＡＶＡ」言語による「アプレット」の形でスマートカード２ａの中にストックされる。「ＨＴＴＰ」要求によって、この「アプレット」を端末１のＯＬ”に動的にロードすることができる。このロードは予備段階でブラウザ１０によって提出された要求によって行われる。いったん部分ＯＬがロードされると、その後の段階は前の場合と共通である。またデータＤａも外部サポート、例えばディスケット８にストックすることができる。
【０１６９】
図１２Ｇに示すシステムアーキテクチャは図１２Ｆに示すアーキテクチャの変形である。唯一の違いは、ロードプログラム部分ＯＬが「ＪＡＶＡ」言語による「アプレット」の形で遠隔サーバ４にストックされることである。先の場合のように、「ＨＴＴＰ」要求によって、この「アプレット」を端末１のＯＬ”に動的にロードすることができる。このロードは予備段階でブラウザ１０によって提出された要求によって行われる。他の段階は前の場合と共通である。
【０１７０】
本発明の範囲から逸脱することなく、他の変形アーキテクチャを使用することもできることは明らかである。様々な源泉から、例えば、ローカルネットワークまたは他のすべての情報通信技術手段によって端末１に接続された他の情報処理システムから、端末１にデータＤａをロードすることは特に可能である。
【０１７１】
先の説明では、本発明がその決められた目的をうまく達成することが容易に確認にされる。
【０１７２】
スマートカードの中の「アプレット」をこのスマートカードの中に格納された「ＷＥＢ」サーバの「ＣＧＩ」インターフェースによってロードすることは、特に次の利点がある。すなわち、
「ＨＴＭＬ」言語による書式の使用はロードを標準化し、ロードプログラム部分ＯＬおよびＩＬを先験的に互換性にする。実際、先にロードが示されたように、返送された１つまたは複数の書式のフィールドにロードが予期するロードパラメータ表示を書き込むのは、スマートカードの中にある部分ＩＬである。
【０１７３】
また、ロードプログラム部分ＯＬおよびＩＬの間におけるこの通信機構は、ロードの際の動的交換順序を簡単に管理できるようにする。
【０１７４】
ロードプログラム部分ＯＬおよびＩＬの間における交換のためのインターネットプロトコル「ＨＴＴＰ」および「ＴＣＰ／ＩＰ」の使用は、これらの部分を物理的に分離することを可能にする。端末にはパケット区域仕分け「ＩＰ」のみが必要である。したがってロードは、通信プロトコルＩＳＯ７８１６を保存している限り、一般的なスマートカード読取装置の中で行うことができる。端末は、インターネットに接続された標準型で簡単なマイクロコンピュータにすることができる。
【０１７５】
本発明の方法の同様に有利な態様によれば、スマートカードの中にストックされたアプリケーションは標準型のままであり、したがって書き換える必要はない。スマートカードと端末はこれら自体、本発明の方法に適応できるためには極くわずかの変更しか要らない。すなわちこのわずかな変更は、これら２つのユニットの中に固有と呼ばれた通信プロトコルのソフトウェア層、すなわちインテリジェントエージェントを含むソフトウェア層を導入することに要約される。
【０１７６】
代替案として、ロードプログラム部分ＯＬを、カードを通ってカードまたは遠隔サーバ「ＨＴＴＰ」から端末へ動的にロードすることができる。
【０１７７】
ロードプログラムＯＬとして、簡単なインターネットブラウザを使用することができる。
【０１７８】
しかし、本発明は特に図２〜１２Ｇに関連してはっきり説明した実施例のみに限定されるものではないことを明らかにすべきである。
【０１７９】
また一方では、「ＨＴＭＬ」言語の代りに、「インターネット」形式の通信プロトコルに適した類似の他の言語、特に「ＸＭＬ」言語を使用することができる。
【０１８０】
本発明は、スマートカード読取装置を介して、前記スマートカードに接続された端末から前記スマートカードの中にソフトウェアをロードして、所定の第１プロトコルによる通信を可能にする方法であって、端末とスマートカードは情報処理手段と情報ストック手段とを含み、前記ロードは第１および第２ロードプログラムの利用と協働によって行われ、前記第２ロードプログラムが前記スマートカードの情報ストック手段の中にストックされている方法に関し、本方法は少なくとも下記の段階、すなわち、
ａ／前記スマートカード（２ａ）の情報ストック手段の中に、第１ソフトウェア（２３ａ）を導入して、特定の通信プロトコル層を形成することから成る予備的第１段階と、
ｂ／前記端末（１）の情報ストック手段の中に、第２ソフトウェア（１３）を導入して、特定の通信プロトコル層を形成することから成る予備的第２段階と
を含み、
前記第１および第２ソフトウェア（１３、２３ａ）はさらに、少なくとも１対として組み合わせた第１ソフトウェアエンティティ（１３２、２３２ａ）を含み、前記エンティティ（１３２、２３２ａ）の各々は、前記スマートカード（２ａ）がクライアント／サーバ「ＷＥＢ」の機能性を提供するように、少なくとも前記端末（１）と前記スマートカード（２ａ）の間の双方向データ交換セッションを確立できるように、端末とスマートカードとの情報処理手段のおかげで互いに協働し、
本方法は、前記スマートカードが「ＣＧＩ」と呼ばれるゲートウェイインターフェースの機能性を提供するように、前記の特定の第２ソフトウェア（２３ａ）と協働するように、一連の指令を解釈してこれを一連の命令に翻訳するのに適した、少なくとも第２ソフトウェアエンティティ（ＡＴＳ１〜ＡＴＳｎ）を、前記スマートカード（２ａ）の情報ストック手段の中に導入することから成る予備的第３段階を含み、前記スマートカードは、前記第２ロードプログラム（ＩＬ）に関連する指令列の少なくとも１つを含み、
本方法は少なくとも下記の段階、すなわち、
１／前記第１ロードプログラム（ＯＬ）が前記第２ロードプログラム（ＩＬ）によって供給されたロードパラメータ表示データを検索するための、要求の伝送のために、端末とスマートカードの前記情報処理手段のおかげで、少なくとも前記端末（１）と前記スマートカード（２ａ）の間の第１データ交換セッションを開くこと、
２／前記ロードパラメータ表示データを前記第１ロードプログラム（ＯＬ）へ伝送するために、端末とスマートカードとの前記情報処理手段のおかげで、前記スマートカード（２ａ）と少なくとも前記端末（１）との間の第２データ交換セッションを開くことであり、前記パラメータ表示データは前記第２ロードプログラム（ＩＬ）に関連する前記指令の参照を含み、
３／前記ロードパラメータ表示データを考慮したロードファイル（７）の提出のために、端末とスマートカードとの前記情報処理手段のおかげで、少なくとも前記端末（１）と前記スマートカード（２ａ）の間の第３データ交換セッションを開くことであり、前記ファイルは、ロードすべき前記ソフトウェア（Ｄａ）に関連するデータ（７０、７１、７２）を含み、すなわち、前記第２ロードプログラム（ＩＬ）に伝送される一連の命令を発生させ、このプログラム（ＩＬ）を実行し、そして前記ソフトウェア（Ｄａ）の前記アンロードを得るように、前記第２ロードプログラム（ＩＬ）に関連する前記一連の指令を解釈すること、
を含むことを特徴とする。
【図面の簡単な説明】
【図１Ａ】  知られている技術により、スマートカード内に「アプレット」をロードするのを可能にするアーキテクチャの実現例を概略で示す図である。
【図１Ｂ】  従来の技術によるインターネットに接続されたスマートカードに基づくアプリケーションシステムの一例のハードウェアアーキテクチャを表わす図である。
【図１Ｃ】  従来の技術によるインターネットに接続されたスマートカードに基づくアプリケーションシステムの一例のソフトウェアアーキテクチャを表わす図である。
【図２】  スマートカードに基づくアプリケーションシステムの一例を概略的に表わす図であり、そのスマートカードは、本発明の一様態に従って、「ＷＥＢ」クライアント／サーバとして作動する。
【図３】  本発明の一様態による、インテリジェントエージェントと呼ばれるソフトウェアエンティティ間のセッションの状態のフローチャートである。
【図４】  スマートカードがインテリジェントエージェントを有する、本発明によるシステムのソフトウェアアーキテクチャを簡略に表わす図である。
【図５】  スマートカードが、スクリプト変換インテリジェントエージェントを有する、システムのソフトウェアアーキテクチャを簡略に表わす図である。
【図６】  スマートカードの中に「アプレット」をロードできるようにする本発明によるアーキテクチャの一実施形態の概略図である。
【図７】  本発明によって実施可能な「アプレット」のロードファイルの構造を示す図である。
【図８】  第１実施形態による「アプレット」をスマートカードの中にロードする方法における主な段階を概略的に示す図である。
【図９】  「ＧＥＴ」と呼ばれる方法を実施するための、「アプレット」をスマートカードにロードする本発明による方法によって使用可能な言語「ＨＴＭＬ」による書式の例を示す図である。
【図１０】  「ＰＯＳＴ」と呼ばれる方法を実施するための、「アプレット」をスマートカードにロードする本発明による方法によって使用可能な言語「ＨＴＭＬ」による書式の例を示す図である。
【図１１】  第２実施形態による「アプレット」をスマートカードの中にロードする方法における主な段階を概略的に示す図である。
【図１２Ａ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１２Ｂ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１２Ｃ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１２Ｄ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１２Ｅ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１２Ｆ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１２Ｇ】  「アプレット」のスマートカードへのロードを可能にする本発明によるシステムアーキテクチャの、さまざまな変形実施形態を示す図である。
【図１Ａ】
0003834239.tif 000003
【図１Ｂ】
0003834239.tif 000004
【図１Ｃ】
0003834239.tif 000005
【図２】
0003834239.tif 000006
【図３】
0003834239.tif 000007
【図４】
0003834239.tif 000008
【図５】
0003834239.tif 000009
【図６】
0003834239.tif 000010
【図７】
0003834239.tif 000011
【図８】
0003834239.tif 000012
【図９】
0003834239.tif 000013
【図１０】
0003834239.tif 000014
【図１１】
0003834239.tif 000015
【図１２Ａ】
0003834239.tif 000016
【図１２Ｂ】
0003834239.tif 000017
【図１２Ｃ】
0003834239.tif 000018
【図１２Ｄ】
0003834239.tif 000019
【図１２Ｅ】
0003834239.tif 000020
【図１２Ｆ】
0003834239.tif 000021
【図１２Ｇ】
0003834239.tif 000022