JP3845018B2 - サーバとチップカード端末との間のインターネット型ネットワーク上での高速データストリーム特にマルチメディアデータストリームの送信方法 - Google Patents

Description

【０００１】
本発明は、サーバとチップカード端末との間のインターネット型ネットワーク上での高速データストリームに関する。
【０００２】
より詳細には、本発明は、セキュア化マルチメディアデータストリームの送信方法に関する。
【０００３】
本発明の枠組においては、「高データレート」という用語は、データレートが毎秒１００ｋビット程度またはそれ以上であるデータストリームに関する。たとえば、「ＭＰ３」符号化データの音声ファイルは、このファイルがデジタル回線を通じてリアルタイムで送信される場合には、１分間すなわちおよそ１００ｋビット／秒の録音について１ＭＢの記憶空間を必要とする。また、リアルタイムで表示するためにおよそ２Ｍビット／秒程度の送信速度を必要とするビデオデータストリームを挙げることもできる。ましてや、画像、ビデオおよび／または音声を同時に伝搬することができるいわゆるマルチメディアデータストリームもこれに該当する。
【０００４】
同じく本発明の枠組においては、「チップカード端末」という用語は一般的な意味において理解されなければならない。この端末はとくに、ＷＩＮＤＯＷＳまたはＵＮＩＸ（両者とも登録商標である）など種々のオペレーティングシステム上で動作するパソコンで構成することができる。端末はまた、ワークステーションまたはノート型パソコンで構成することもできる。
【０００５】
同様に、本発明の枠組においては、「インターネット網」という用語は、本来の意味でのインターネット網の他、「イントラネット」と呼ばれる種類の企業私有網または同様な網、「エクストラネット」と呼ばれる種類の外部に伸展する網、およびより一般的には、インターネット型プロトコルによりデータのやりとりが行われるあらゆる網も含む。
【０００６】
趣旨を明らかにするために、以下の記述においては、別に記載がある場合は別として、たとえばセキュア化マルチメディアデータストリームの送信など、本発明の範囲から逸脱することなく、本発明の好ましい応用の場合を想定することにする。
【０００７】
「セキュア化」とは、機密性を確保するか、少なくとも自由にデータにアクセスできないようにするために、当該データの全部または一部が暗号化されることを意味する。後者の目的の場合、有料アクセスデータを指すこともある。いずれにせよ、所望するデータ（たとえばマルチメディアファイル）を取得するためのトランザクションが可能な識別データ（パスワード、識別子すなわち「ログイン」、クレジットカード番号等）を入力することが通常必要である。これらのデータはいわゆる「影響を受け易く」、インターネット網上では「平文」で送信することができない。したがってこれらのデータはセキュア化、すなわち暗号化またはたとえば「ＳＳＬ」（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒの略）型のセキュア化プロトコルの使用を行わなければならない。
【０００８】
インターネット網のめざましい発展にともない、この網を介して種々のサーバおよび／またはクライアントシステムから／またはへ、あらゆる種類のデジタルファイルを送信することが可能であることという第１の必要性が生じた。これらの２つのシステムを接続する伝送路またはこの伝送路の一部分の通過帯域が小さい時でも（たとえば、Ｖ９０規格を実施する時、およそ５６ｋビット／秒を限度とする交換型電話回線が該当する）、この伝送路を介して大きなファイルを送信することはたしかに可能であるが、大部分の場合、ダウンロードが終了した後に非リアルタイムでしかこのファイルを使用することができない。高速通信路（ケーブルまたは衛星による接続のサービス統合デジタル網「ＲＮＩＳ」すなわち英語の用語による「ＩＳＤＮ」）が利用可能であることにより、インターネット網に接続された端末による音声ファイルさらにはマルチメディアファイルのリアルタイム送信を考えることが可能である。通常の電話回線ですら、「ＡＤＳＬ」という略号で知られている最近の送信技術を利用する時には、１Ｍビット／秒程度の速度でデジタルデータを送信することが可能である。
【０００９】
ところで、歴史的に見ると、インターネット網に接続されたリモートサーバと端末との間の伝送路が「ボトルネック」となっていた。したがって鎖の両端の情報システム、すなわちサーバおよび端末、マルチメディアファイルの送信および／または処理、および配信に必要なデータレートを受け入れることができることは明らかである。最近、インターネット網上に高速路が設置されたことにより、この種の「エンドツーエンド」処理が可能である。
【００１０】
顕著になっている別の需要は端末と組み合わせるチップカードの使用である。
【００１１】
実際、チップカードを基本とするアプリケーションシステムにおいては、チップカードには、種々の機能、特にセキュリティ機能が割り当てられる。セキュリティに関するデータ（パスワード、アクセス権など）は、ユーザが保存できるチップカード内に格納することが有利である。またデータは、暗号化が可能な形態で固定メモリ内に記録されることから、容易に変更することができず、外部から直接読むこともできない。
【００１２】
有料トランザクションの枠組においては同様の機能が使われる。上で喚起したように、パスワードおよび／または識別子、ならびに種々のセンシブルデータ（クレジットカードの番号など）、およびユーザの権利（現在有効な購読、アクセス可能なサービスなど）を画定するデータを送信することも必要である。
【００１３】
しかしながら、知られている技術においては、受信および／または送信されたデータストリームがチップカードを通過しないため、チップカードの内部に「セキュリティ機能」を直接実現することはできないことに留意されたい。したがって、セキュリティに関するチェックが行われるようにするためには、端末とチップカードとの間に対話が確立されなければならない。この動作モードはセキュリティレベルを低下させ、さらには、ある悪条件下では、端末内に「トロイの木馬」を呼び込んでしまうことがある。
【００１４】
したがって、セキュリティチェックは、原位置すなわちチップカードそのものの中で行われることが必要であり、そのため、データストリームは、端末に送信される前にチップカードにバイパスされることが必要となろう。
【００１５】
チップカードは、自身に割り当てられた「セキュリティ」機能に加え、端末内で行われるいくつかの動作を直接管理することができるとともに、たとえば、端末により受信および／または送信されるデータのあらかじめ決められた特性を変更することができることも有利である。
【００１６】
知られている技術においては、以下に示すように、これらの動作モードは、現在利用可能な技術およびチップカードを基本とするアプリケーションのために選定された規格には適合しない。
【００１７】
まず、図１Ａおよび図１Ｂを参照して、チップカードを基本とするアプリケーションシステムの一般的なアーキテクチャを簡単に振り返ることにする。
【００１８】
チップカードを基本とするアプリケーションシステムは、主要な要素として、通常
− チップカード
− 前出の端末を構成するホストシステム
− 好ましいアプリケーション内のインターネット網などの通信ネットワーク
− インターネット網に接続されたアプリケーションサーバ
を含む。
【００１９】
図１Ａは、この種のアーキテクチャの例の略図である。たとえばパソコンである端末１は、チップカード２のリーダ３を含む。このリーダ３は、物理的に端末１内に組み込むことも組み込まないようにすることも可能である。チップカード２は、入出力接続部が、電気エネルギの供給および端末１の通信を可能にするように、その支持部の表面と同じ高さになる集積回路２０を含む。端末は、インターネット網ＲＩへのアクセス回路１１を備える。この回路は、交換電話回線、あるいは本発明の場合には、好ましくは、より高速な通信路すなわちケーブルまたは衛星による接続のサービス統合デジタル網（「ＲＮＩＳ」）に接続するためのモデムで構成することができる。回路１１により、直接、あるいはインターネットサービス接続業者（英語の用語による「インターネットサービスプロバイダ」または「ＩＳＰ」）を経由して、インターネット網ＲＩに接続することが可能である。また、「プロキシ」、あるいは「ファイヤウォール」と呼ばれる隔離システム（「防火壁」、さらには「見張番」とも呼ばれる）などの中間システムに頼ることも可能である。
【００２０】
当然のことながら、端末１は、ＣＰＵ、ＲＡＭおよびＲＯＭ、磁気ディスク大容量メモリ、ディスクおよび／またはＣＤ−ＲＯＭドライブなど、図を簡略化する目的から図示しなかったが、その動作に必要な全ての回路および装置を備える。
【００２１】
通常、端末１は、表示スクリーン５ａおよび（本発明の枠組においてはマルチメディアファイルの配信が可能な）音声再生システム５ｂ、キーボード６ａおよびマウス６ｂなど、内蔵または非内蔵の通常の周辺装置にも接続される。
【００２２】
端末１は、網ＲＩに接続されたサーバまたは全ての情報処理システムと通信状態に入ることができるが、図１Ａには、そのうちの１つのシステムのみを図示してある。アクセス回路１１は、「ＷＥＢ」ナビゲータ、あるいは英語の用語では「ブラウザ」と呼ばれる特殊ソフトウェア１０により、端末１とサーバ４とを通信状態にする。通常、「クライアント−サーバ」モードにより網ＲＩの全体に分散した種々のデータアプリケーションまたはファイル、特にマルチメディアファイルには、ナビゲータによりアクセスすることができる。
【００２３】
通常、ネットワーク上の通信は、複数の重畳ソフトウェア層を備える規格を満たすプロトコルに従って行われる。インターネット型網ＲＩの場合、以下に詳述するが、通信は、同じく複数のソフトウェア層を備えるこの種の通信に特有なプロトコルに従って行われる。通信プロトコルは、より個別的に求められるアプリケーション、すなわち「ＷＥＢ」ページの問い合せ、フィアルの転送、電子メール（Ｅ−ｍｅｌ、あるいは英語の用語による「ｅ−ｍａｉｌ」）、フォーラム、または「ニュース」など、に応じて選択される。
【００２４】
図１Ｂに、端末と、チップカードリーダと、チップカードとを備えるシステムの論理アーキテクチャの略図を示す。このアーキテクチャは規格ＩＳＯにより記述されおり、同規格そのものも複数の部分集合、すなわち、
− カードの寸法およびマーキングに関するＩＳＯ７８１６−１および７８１６−２
− 端末とチップカードとの間のデータ転送に関するＩＳＯ７８１６−３
− 命令セットおよびコマンドのフォーマットに関するＩＳＯ７８１６−４
図１Ｂの端末１側には、符号１０１の規格ＩＳＯ７８１６−３に準拠する層、および符号１０２の「ＡＰＤＵ」命令マネージャ（規格ＩＳＯ７８１６−４）のみを示した。チップカード２側においては、規格ＩＳＯ７８１６−３に準拠する層には符号２０１を付し、「ＡＰＤＵ」命令マネージャ（規格ＩＳＯ７８１６−４）には符号２１０を付した。アプリケーションには符号Ａ_１、．．．、Ａ_ｊ、．．．、Ａ_ｎを付したが、ここでｎはチップカード２上に存在するアプリケーションの最大数である。
【００２５】
チップカード２（図１Ａ）内に存在する「ｃａｒｄｌｅｔ」アプリケーションは、命令セットにより端末１と対話する。通常、このセットは書き込み命令と読み出し命令とを有する。命令のフォーマットは、「ＡＰＤＵ」（「Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔの意）という英語の略語で知られている。この書式は前出の規格ＩＳＯ７８１６−４により規定されている。コマンドの「ＡＰＤＵ」は「ＡＰＤＵ．ｃｏｍｍａｎｄ」と記され、応答の「ＡＰＤＵ」は「ＡＰＤＵ．ｒｅｓｐｏｎｓｅ」と記される。「ＡＰＤＵ」は、前出の規格ＩＳＯ７８１６−３により規定されたプロトコル（たとえばキャラクタモード：Ｔ＝０、またはブロックモード：Ｔ−１）により、カードリーダとチップカードとの間でやりとりされる。
【００２６】
図１Ｂに示すように、チップカード２が異なる複数のアプリケーションを含む時、マルチアプリケーティブカードと呼ぶ。しかしながら、端末１は一度に１つのアプリケーションとしか対話しない。アプリケーションＡ_ｊは、たとえば、「ＪＡＶＡ」言語（登録商標）による「アプレット」と呼ばれるソフトウェアの形態を成し、以下、これを「カードレット」と呼ぶ。個別の「カードレット」Ａ_ｊの選択は選択型「ＡＰＤＵ」（「ＳＥＬＥＣＴ」）により得られる。いったんこの選択が行われると、これに続く複数の「ＡＰＤＵ」がこの「カードレット」に向けて送られる。新規の「ＡＰＤＵ ＳＥＬＥＣＴ」は、現在実行中のアプリケーションを破棄し、別のアプリケーションを選択する作用を有する。「ＡＰＤＵ」２１０のマネージャソフトウェアサブセットにより、チップカード２内で個別のアプリケーションＡ_ｊを選択すること、このようにして選択されたアプリケーションを記憶すること、およびこのアプリケーションへの「ＡＰＤＵ」の送信および／またはそこからの受信が可能である。
【００２７】
上で記述してきたことを要約すると、アプリケーションＡ_ｊの選択およびアプリケーションとの対話は「ＡＰＤＵ」命令のやりとりにより行われる。アプリケーションＡ_ｊは従来のアプリケーションであり、以後、「ＧＣＡ」（「Ｇｅｎｅｒｉｃ Ｃａｒｄ Ａｐｐｌｉｃａｔｉｏｎ」すなわち一般カードアプリケーションの意）と呼ぶことにする。
【００２８】
以上の点を思い起した上で、スマートカード２は、市販の標準ブラウザのコードを変更しない限り、そうしたブラウザとは直接対話できない点に留意されたい。
【００２９】
さらに、また特に、そもそも上述の標準および規格に合致している現在のスマートカードは、同じくインターネットＲＩと直接通信できないハードウェアおよびソフトウェアの構成を有する。とりわけ、それらは、この型のネットワークで使用されるプロトコルのいずれかに従って、データパケットを受取り、伝達することができない。したがって、一般には、英語で「プラグイン」で呼ばれるものの形で、端末内１に設置される追加ソフトウェアを備えることが必要である。図２Ａでは参照番号１２が付されているこのソフトウェアは、ブラウザ１０とカード２との、より厳密にはこのカード２の電子回路２０との間のインターフェイスを実施する。
【００３０】
諸技術の過去の急速な発展およびその予想される将来の進化を考慮に入れたとしても、チップカードのＲＡＭまたはＲＯＭ回路への情報記録容量は、この容量をこのチップカードの「ホスト」端末が提供する容量、および当然のことながら、「ミニコンピュータ」またはいわゆる「メインフレーム」型の大型システムといった、より大型のシステムが提供する容量と比較すると、依然として限界があり将来においても限界があることは明らかである。また、大きなデータのファイル、特にマルチメディア型ファイルをチップカード内に保存することは不可能である。したがって、チップカードをインターネット網と通信させること、およびそこにデータを通過させることが可能であること（上で示してきたように、知られている技術では不可能である）を認めながら、「一斉」に、すなわちたとえ一時的であってもメモリに記憶することなく、全ての処理を行うことが必要であろう。知られている技術または短期的に実現可能な技術の現状においては、チップカード内に存在する論理回路、特にマイクロプロセッサの計算能力ではこのような動作モードを実現することができない。
【００３１】
最後に、前出の規格は、シリアル型リーダを介してチップカードと端末との間の通信を編成する。その上、現在の技術により可能なデータレートは１〜１０ｋビット／秒程度と非常に低く、そのことは、ここでもまた、本発明のアプリケーションの一環として想定するデータレート（最低でも１００ｋビット／秒）に適合しない。
【００３２】
本発明は、顕著になってき需要、すなわち、特に、最大のセキュリティを享受しつつ高データレートストリームに対応することができるようにするという需要を満たしつつ、上でそのいくつかについて喚起してきた、知られている技術の方法および装置の欠点を解消することを目的とする。
【００３３】
本発明の第１の特徴によれば、チップカードは、自身に結合されている端末のための「ＷＥＢ」型サーバ／クライアントの役割を果たす。
【００３４】
これを行うために、端末内のチップカードおよびその垂下部に専用通信ソフトウエア層を設ける。「専用」という用語は本発明の方法に対し専用であると理解されたい。事実、これらの専用通信層は、想定するアプリケーションの如何に関わらず、両方向性のものである。これら層は、チップカードと端末との間、ならびにチップカードとネットワークとの間の双方向のデータのやりとりのプロセスにおいてのみ動作する。
【００３５】
専用通信ソフトウェア層は、特にプロトコルの変換が可能な「インテリジェントエージェント」と呼ばれるソフトウェアコンポーネントを特に含む。以後、インテリジェントエージェントを単に「エージェント」と呼ぶことにする。それぞれ端末およびチップカードに結合された専用通信層内に設置されるエージェントが存在する。本発明の方法によれば、設置されたエージェント間でセッションが確立される。
【００３６】
これらの構成により、リーダを介したチップカードと端末との間の端末のための前出のＩＳＯ規格をみたしつつ、チップカードでデータストリームの全部または一部をインターネット網からまたはインターネット網側にバイパスすることが可能になる。
【００３７】
本発明の別の特徴によれば、チップカード内に、以後の文書では「フィルタ」と呼ぶことにする特別アプリケーションをインプリメントする。これには、「プロキシ」の役割と同様の役割を果たすソフトウェアエンティティが関わる。これを行うために、エージェントを利用する前出の構成を用いる。この「プロキシ」により、セキュリティに関するデータの処理を、チップカードの内部で直接実施することが可能になる。
【００３８】
本発明の別の特徴によれば、非対称通信プロトコルをインプリメントする。この特徴によれば、送信中または受信中のデータストリームは２つのコンポーネント、すなわち直接チップカードを通過し、少ないデータ量を示す低データレート第１ストリーム −以後「クリティカルデータストリーム」と呼ぶ−と、端末を通過し、多いデータ量を示す高データレート第２ストリーム −以後「オパークデータストリーム」と呼ぶ−とに分割される。
【００３９】
本発明の好ましい適用においては、クリティカルデータストリームは、チップカードの前出の「プロキシ」において機密的に処理されるよう、このプロキシに送ることができるセキュリティデータで構成される。オパークデータは本来の意味でのマルチメディアデータで構成される。これらのデータは端末内にあるエージェントにより処理される。しかしながら、オパークデータの受信および処理の許可は、チップカード内のセキュリティデータにより開始される認証手順の結果に依存する。前出のフィルタが存在するため、端末によるデータの受信はチップカードの直接制御下にある。
【００４０】
端末を通過するオパークデータは、チップカードの制御および管理の下、実際の使用の前、すなわちチップカードが受信したクリティカルデータの画定後、端末内で個別の処理を受けることもできる。
【００４１】
これを行うために、チップカードと端末との間、またはこれらの装置の一方のみの内部に配置された追加特別エージェントを設け、これを「プロトコルの」追加特別エージェントと呼ぶ。
【００４２】
したがって本発明は、少なくとも１つのリモートサーバと、チップカードリーダを具備する端末との間における、インターネット型ネットワークを経由するデータストリームの送信方法であって、前記端末が少なくとも１つの「ＴＣＰ／ＩＰクライアント」型アプリケーションを含み、前記端末と前記サーバの双方が前記インターネット型ネットワークに接続され、
ａ／前記チップカード内に、専用通信プロトコル層を形成する第１ソフトウェアをインプリメントすることから成る第１段階と、
ｂ／前記端末内に、専用通信プロトコル層を形成し、少なくとも１つの前記「ＴＣＰ／ＩＰクライアント」型アプリケーションとのインタフェースを形成する第２ソフトウェアをインプリメントすることから成る第２段階と
を備えること、
− さらに前記第１および第２ソフトウェアがそれぞれ、少なくとも１つのクライアント型の第１独立ソフトウェアエンティティと、サーバ型の第２独立ソフトウェアエンティティとを備え、前記端末と前記チップカード（との間で双方向データ交換セッションを確立し、前記チップカードが「ＷＥＢ」型クライアント／サーバの機能を提供するようにし、かつ前記インターネット型網を経由して、前記端末と、前記リモートサーバとの間で双方向データ交換セッションを確立するよう、端末およびチップカードの情報処理手段により前記エンティティが、協働し、前記独立ソフトウェアエンティティが、あらかじめ決められたプロトコルのデータユニットで通信すること、
− 前記第２専用ソフトウェア部内に含まれるクライアントおよびサーバ型の前記第１および第２独立ソフトウェアエンティティにおよび／またはからプロトコルデータユニットを受信および／または送信する「フィルタ」と呼ばれる所与の機能特性の適用ソフトウェアを前記チップカード内に実施する段階を備え、前記適用部分の実施が前記サーバ型独立ソフトウェアエンティティの制御下にあること、
− 前記専用第１ソフトウェアの前記独立ソフトウェアエンティティとのセッションを開始し、前記端末と前記リモートサーバとの間で送信される前記データストリームのあらかじめ決められた特性を変更するために、前記フィルタが、前記専用第２ソフトウェアの前記独立ソフトウェアエンティティと協働すること
を特徴とする方法を主な対象とする。
【００４３】
次に、添付の地面を参照してより詳細に本発明を記述する。
【００４４】
以下の記述においては、別に記載がある場合、すなわち、ＷＥＢサーバも接続されるインターネットサーバに接続された端末と協働するチップカード上にインプリメントされたプロキシによりセキュア化されたマルチメディアデータストリームの場合は別として、本発明の範囲から逸脱することなく、本発明の好ましい応用の場合を想定することにする。
【００４５】
本発明によるチップカード内に位置するアプリケーションの起動手順を記述し、図２を参照してその実施のためのアーキテクチャについて詳細に説明する前に、まず、ネットワーク上の通信プロトコルの主な特徴を振り返ってみることが有益であろう。
【００４６】
通信ネットワークのアーキテクチャは種々の層により記述される。たとえば「ＩＳＯ」が規定する「ＯＳＩ」規格（「Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ」）は、下位層（物理的な送信媒体に関する「物理層」）から、特に「トランスポート層」をはじめとする中間層を経て、上位層（たとえば「アプリケーション層」）まで７つの層を含む。ある所与の層は、適当なインタフェースを介して、１つ上位の層にサービスを提供し、１つ下位の層に対し他のサービスを要求する。層はプリミティブを使用して通信する。層は同レベルの層と通信することもできる。アーキテクチャによっては複数の層が欠けていることもある。
【００４７】
インターネット型環境においては層数は５つ、すなわちより正確には、上位から下位に向かって、アプリケーション層（「ｈｔｔｐ」、「ｆｔｐ」、「ｅ−ｍａｉｌ」など）、トランスポート層（「ＴＣＰ」）、ネットワークアドレシング層（「ＩＰ」）、データリンク層（「ＰＰＰ」、「Ｓｌｉｐ」など）、および物理層である。
【００４８】
端末１およびスマートカード２ａ内にそれぞれ設置された、参照番号１３および２３ａの特有の通信プロトコルソフトウェア層を例外として他のハードウェアまたはソフトウェアエレメントは、従来の技術に共通するため、ここで再び詳細に説明する必要はない。
【００４９】
端末１は、たとえばモデムで構成されたネットワークＲＩへのアクセス回路１１を有する。これら回路は、「物理」層と「データリンク」層に対応する、下層ソフトウェア、Ｃ_１およびＣ_２を包括する。
【００５０】
また、「ネットワークアドレシング」層（インターネットの場合には「ＩＰ」）と「トランスポート」層（「ＴＣＰ」）に対応する、上層、Ｃ_３およびＣ_４が示されている。アプリケーション上層（「ｈｔｔｐ」、「ｆｔｐ」、「ｅメール」等）は示されていない。
【００５１】
下層、Ｃ_１およびＣ_２と上層、Ｃ_３およびＣ_４との間のインターフェースは、一般に「下層ドライバ」と呼ばれるソフトウェア層によって構成される。上層、Ｃ_３およびＣ_４は、このインターフェイス上に支持され、それらに対応する特有の機能のライブラリまたはネットワークライブラリ１４を介して利用される。インターネットの場合には、「ＴＣＰ／ＩＰ」は、「ソケット」と呼ばれるライブラリを用い利用される。
【００５２】
こうした構造から、ブラウザ１０は、ファイル転送用または電子郵便の送信用の「ＷＥＢ」ページ（「ＨＴＴＰ」プロトコル）の閲覧のために、サーバ４に向かって要求を出すことが可能であり、それはまったく従来の方法で行われる。
【００５３】
端末１はまた、一体型または非一体型のカード読取装置３を有する。スマートカード２ａと通信するために、カード読取装置３０はまた、層Ｃ_１およびＣ_２と類似の役割を果たす、２つの低層、ＣＣ_１（物理層）とＣＣ_２（データリンク層）を包括する。層ＣＣ_１およびＣＣ_２とのソフトウェアインターフェイスは、たとえば、仕様「ＰＣ／ＳＣ」（「第６部、サービスプロバイダ」）によって説明される。層自体、ＣＣ_１およびＣＣ_２は、特に、上述したように、規格ＩＳＯ ７８１６−１から７８１６−４によって説明される。
【００５４】
補足的ソフトウェア層１６は、応用層（ここには図示されていない）と下層、ＣＣ_１およびＣＣ_２との間でインターフェイスを形成する。この層１６に割り当てられる主要機能は、マルチプレキシング／デマルチプレキシング機能である。
【００５５】
スマートカード２ａとの通信は、「ＵＮＩＸ」型オペレーティングシステム、すなわちＯＵＶＲＩＲ（「ＯＰＥＮ」）、ＬＩＲＥ（「ＲＥＡＤ」）、ＥＣＲＩＲＥ（「ＷＲＩＴＥ」）、ＦＥＲＭＥＲ（「ＣＬＯＳＥ」）等におけるファイルの操作のために使用されるものと類似のパラダイムに従って行われる。
【００５６】
スマートカード２ａ側には、類似の構造、すなわち参照番号ＣＣａ_１（物理層）およびＣＣａ_２（データリンク層）が付された２つの低層の存在、さらには層１６とまったく同じインターフェイス層２６ａが見られる。
【００５７】
本発明の第１の特徴によれば、両側に、すなわち端末１およびスマートカード２ａにおいて、特有の２つのプロトコル層、つまり、それぞれ１３および２３ａが備えられる。
【００５８】
端末１においては、特有の層１３は、マルチプレキシング層１６を介して、「ドライバ低層」１５、ネットワーク層Ｃ_３およびＣ_４のライブラリ１４、さらに、カード読取装置３のプロトコル層、すなわち下層ＣＣ_１およびＣＣ_２とインターフェイスしている。特有の層１３は、スマートカード２ａから、またスマートカード２ａに向かって、ネットワークパケットの転送を可能にする、さらに、この層は、スマートカード２ａを利用する用途に、インターネットブラウザ１０や電子郵便等のような既存のアプリケーションを適合させる。
【００５９】
スマートカード２ａ側には、層１３と対をなして、参照番号２３ａが付された特有の層の補足的インスタンスで構成されたまったく同様の構造が見られる。
【００６０】
より厳密には、特有の層１３および２３ａは、以下の３つの主要なソフトウェアエレメントに細分割される。
【００６１】
−従来の層ＣＣ_１、ＣＣ_２、ＣＣａ_１およびＣＣａ_２を介する、層１３と２３ａの間の情報ブロックの転送モジュール１３０または２３０ａ、
−たとえば、プロトコルの変換機能を実行する「インテリジェントエージェント」１３２または２３２ａと呼ばれる１つまたは複数のソフトウェア、
−個別のインテリジェントエージェントと同一視することができるモジュールである、特有の構成の管理モジュール、１３１および２３１ａ。
【００６２】
以下、簡略化するために、先述したように、インテリジェントエージェントを「エージェント」と呼ぶ。
【００６３】
したがって、端末１とスマートカード２ａ内に、２つのエンティティ間の通信プロトコルスタックが見られる。
【００６４】
レベル２の層（データリンク層）ＣＣ_２およびＣＣａ_２は、スマートカード２ａと端末１との間の交換を行う。それらの層は、伝送エラーの検出と、場合によっては補正を行う。種々のプロトコルが使用可能であり、以下は限定的ではなく、あくまで例示的なものである。
【００６５】
−勧告ＥＴＳＩ ＧＳＭ１１．１１、
−キャラクタモードＴ＝０における、規格ＩＳＯ ７８１６−３によって規定されたプロトコル、
−ブロックモードＴ＝１における、規格ＩＳＯ ７８１６−３によって規定されたプロトコル、または
−フレームモード「ＨＤＬＣ」（「Ｈｉｇｈ−Ｌｅｖｅｌ Ｄａｔａ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ｐｒｏｃｅｄｕｒｅ」の略）において、規格ＩＳＯ ３３０９によって規定されるプロトコル。
【００６６】
本発明の枠組みにおいては、好ましくは、ブロックモードにおけるプロトコルＩＳＯ ７８１６−３が使用される。
【００６７】
それ自体良く知られている方法で、各プロトコル層に対して、同レベルの層間、さらに層から層へのデータの交換を可能にする一定数のプリミティブが関連付けられる。例として、レベル２の層に関連付けられるプリミティブは、カードによる「データ要求（「Ｄａｔａ．ｒｅｑｕｅｓｔ」）および「データの確認」（「Ｄａｔａ．ｃｏｎｆｉｒｍ」）等の型である。
【００６８】
より特有の方法では、層１３および２３ａは、スマートカード２ａとホスト、すなわち端末１との間の対話を担当する。それらの層は、たとえば、「ＨＴＭＬ」フォーマットにおけるハイパーテキストの形で実行されるメニュを介して、端末１のユーザ（図示せず）とスマートカード２ａとの間の情報交換を可能にする。それらはまた、データパケットの送信および／または受信のために適合した構成の設置を可能にする。
【００６９】
上述したように、層は３つの別々のエンティティを有する。
【００７０】
第一の層１３０または２３０ａは、主に、ソフトウェアマルチプレクサで構成される。それは、プロトコルのデータユニットの形で、スマートカード２ａとホスト端末１との間の情報交換を可能にする。第一の層は、データパケットの交換器と類似の役割を果たす。それらのユニットは、レベル２の層（データリンク層）を介して送信または受信される。この通信用の個別プロトコルは、少なくとも一対のエージェントの連絡を確立させることができる。各対の第１のエージェント１３２は、端末１側の層１３内に位置し、第２のエージェント２３２ａは、スマートカード２ａ側の層２３ａ内に位置する。２つの「エージェント」間のリンクは、「Ｓ−エージェント」と呼ぶことができるセッションに関連付けられる。セッションは、これら２つのエージェント間の双方向データ交換である。層１３および２３ａのいずれか一方が、複数のエージェントを有する場合には、同一層のエージェントはまた、互いの間で、および／または、個別のエージェントを構成するモジュール１３１および２３１ａとのセッションを確立することができる。
【００７１】
より厳密には、エージェントは、端末１によって実施される構成に応じて、レベル３および４の層の機能の全体または一部を実行することができる独立ソフトウェアエンティティである。
【００７２】
エージェントは、個別の特性または属性に関連付けられる。分かりやすくするために、限定的でなく例示的なものとして、以下の６つの特性がエージェントに関連付けられる。
【００７３】
−「ホスト」：端末内で探索されるエージェント
−「カード」：スマートカード内で探索されるエージェント
−「ローカル」：ネットワークと通信しないエージェント
−「ネットワーク」：ネットワークと通信するエージェント（端末側）
−「クライアント」：セッションを初期化するエージェント
−「サーバ」：セッションの要求を受取るエージェント
個別のエージェントは、リファレンス、たとえば１６ビットの整数によって識別される（すなわち、０から６５５３５の間）。上位ビット（ｂ１５＝１）は、リファレンスがローカルであるか（スマートカードまたは端末へのローカル通信）、または、遠隔であるか（ｂ１５＝０）を示す。
【００７４】
エージェントには２つの大きなカテゴリが存在する。固定リファレンスによって識別される「サーバ」型のエージェントと、構成管理モジュールによって付与される一時的と形容されることもある可変リファレンスによって識別される「クライアント」型のエージェント、１３１または２３１ａである。
【００７５】
エージェントは、宛先リファレンスとソースリファレンスとを構成する「プロトコルデータユニット」または「ｐｄｕ」（英語「ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉ」の略）と呼ばれるエンティティを用いて互いに通信する。さらに、この「ｐｄｕ」を、一般に使用されている英語「Ｓｍａｒｔ Ｃａｒｄ」を参考にして、「ＳｍａｒｔＴＰ ｐｄｕ」と呼ぶこともできる。「ｐｄｕ」は、特に、以上に規定したリファレンスを使用する。
【００７６】
「ＳｍａｒｔＴＰ ｐｄｕ」または、以下、より簡単に「ｐｄｕ」は、「ｐｄｕ」の性質を明示する以下のようなフラグおよびオプションのデータを構成する、ソースリファレンス、宛先リファレンス、ビット集合を有する。
【００７７】
−「ＯＰＥＮ」（開始）フラグは、セッション開始を示すために位置決めされる。
【００７８】
−「ＣＬＯＳＥ」（閉鎖）フラグは、セッションの閉鎖を示す。
【００７９】
−「ＢＬＯＣＫ」（鎖錠）フラグは、エージェントが、その通信相手の応答を待っている状態であり、あらゆる活動を一時停止することを示す。
【００８０】
データをもたない「ｐｄｕ」はトークンと呼ばれる。
【００８１】
「ＳｍａｒｔＴＰ」エンティティは、宛先エージェントの存在をコントロールし、そのエージェントに向かってパケットの通信を実行する。
【００８２】
セッションエージェント「Ｓ−Ａｇｅｎｔ」は、３つの注目すべき状態を有する。すなわち、
−接続解除されている状態。いかなるセッションも他のエージェントには開始されていない。
【００８３】
−接続されている状態。セッションが他のエージェントに開始されている。「Ｓ−Ａｇｅｎｔ」セッションは、一対のリファレンスによって識別される。
【００８４】
−ブロックされている状態。エージェントが接続され、その通信相手の応答を待つ状態。
【００８５】
「Ｓ−エージェント」セッションの確立メカニズムは、以下の通りである。
【００８６】
−クライアントエージェントの新しいインスタンスが創設され（スマートカードまたは端末側）、このエージェントは、擬似単一一時リファレンスによって識別される。
【００８７】
−クライアントエージェントは、位置決めされた「ＯＰＥＮ」フラグとともにサーバエージェント（そもそも、そのリファレンスはすでに知られている）宛てに「ｐｄｕ」を送信し、クライアントエージェントは、「ブロック」フラグの値に従って接続またはブロックされる状態に移行する。さらに
−サーバエージェントは、「ＯＰＥＮ」フラグとともに「ｐｄｕ」を受け取り、接続された状態に移行する。
【００８８】
いったんセッションが開始されると、２人のエージェントが「ｐｄｕ」を介してデータを交換する。
【００８９】
セッションの閉鎖メカニズムは以下の通りである。
【００９０】
−エージェントは、場合によってはデータを有する、位置決めされたフラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を送信する。
【００９１】
−他のエージェントは、（場合によってはデータを有する）位置決めされたフラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を受取り、「Ｓ−Ａｇｅｎｔ」セッションは、接続解除された状態に移行する。
【００９２】
図３は、上述したような「Ｓ−Ａｇｅｎｔ」セッションの状態のフローチャートを概略的に表わしている。
【００９３】
層１３０および２３０ａは、ホスト端末１およびスマートカード２ａ側で、存在するエージェントリストを含む表（図示せず）を管理する。
【００９４】
実際に、エージェントは、（たとえば、ハイパーテキストの）データの交換を可能にするが、しかも、ネットワークトランザクションを開始することができる。
【００９５】
構成管理モジュール、それぞれ１３１および２３１ａは、個別のエージェントと同一視することができる。たとえば、ホスト端末１側のモジュール１３１は、特に、この端末の構成（作動モード）に関連する情報、たとえば他のエージェントリスト等を管理する。スマートカード２ａ側のモジュール２３１ａは、類似機能を有する。これら２つのエージェントは、セッションを確立するために互いに通信を確立することができる。
【００９６】
本発明の第１の特徴によれば、チップカード２ａは「ＷＥＢ」クライアント／サーバとして働く。
【００９７】
実際には、チップカード２ａは、有利には、外部端末へのポインティングではなく端末１自身へのループバックを画定する「ＵＲＬ」（「Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ」の意味）の使用により「アドレス」される。たとえばこの「ＵＲＬ」の構造は以下のようになっている。
【００９８】
ｈｔｔｐ：／／１２７．０．０．１：８０８０ （１）
ここで１２７．０．０．１はループバックの「ＩＰ」アドレスであり、８０８０はポート番号である。
【００９９】
図４は、図２に示す種類の本発明によるシステムのソフトウェアアーキテクチャの略図であるがより詳細に示した図である。チップカード２ａは複数のエージェントを備えるが、そのうちの２つのみ、すなわち「ＷＥＢ」型エージェント２３２ａ１、および非詳細画定型エージェント２３２ａ２を示した。ソフトウェアスタックは、規格ＩＳＯ ７８１６−３（図２：ＣＣａ１およびＣＣａ２）に対応する下位プロトコル層、符号２００ａと、「ＡＰＤＵ」コマンドドライバ２０１ａ１と、パケットマルチプレクサ２３０ａとを備え、このマルチプレクサは、エージェント、特に「ＷＥＢ」エージェント２３２ａ１にインタフェースされる。
【０１００】
端末１側には、２つのスタックが存在するが、一方はインターネットＲＩと通信し、他方はスマートカード２ａと通信する。第１のスタックは、ネットワーク（規格ＯＳＩ １および２）へのアクセス機構１１（図２：Ｃ_１およびＣ_２）と、参照番号１００が付されたプロトコル「ＴＣＰ／ＩＰ」（図３：Ｃ_３およびＣ_４）層とを有する。それらの層は「ＷＥＢ」ブラウザ１０とインターフェイスされる。他方のスタックは、規格ＩＳＯ ７８１６−３に合致した参照番号１０１が付された下層プロトコル（図３：Ｃ_１およびＣ_２）と、命令管理「ＡＰＤＵ」１０２と、パケットマルチプレクサ１３０とを有し、このマルチプレクサはエージェントとインターフェイスされるが、そうちの１つだけ、１３２がここに図示されている。このエージェントは「ネットワーク型」と想定され、さらに、一方では「ＴＣＰ／ＩＰ」層１０１を介して、ブラウザ１０と、他方では、それら「ＴＣＰ／ＩＰ」層１０１とネットワークＲＩへのアクセス機構１１とを介してインターネットＲＩと通信することができる。
【０１０１】
命令管理「ＡＰＤＵ」２０１ａはまた、単にアプリケーションと呼ばれるアプリケーションレベルの１つまたは複数の層とインターフェイスされる。それらアプリケーションＡ_１…、Ａ_ｉ…、Ａ_ｎ…、は、すでに示したように、「カードレット」と呼ぶ従来型のアプリケーションである。
【０１０２】
要約すると、スマートカード２ａによって与えられる「ＷＥＢ」サーバ／クライアント機能は、すでに説明したように、スマートカード内の「ＷＥＢ」エージェント２３２ａ_１と、端末１内のネットワークエージェント１３２との関連付けによって、また、エージェント間のセッションによって実行することができる。
【０１０３】
したがって、スマートカード２ａは「ＷＥＢ」クライアント／サーバ機能を明確に表している。さらに、本発明の方法の一特徴によると、上記の「ＣＧＡ」型の従来のどんなアプリケーションＡ_１からＡ_ｎも、この「ＷＥＢ」クライアント／サーバを通して、端末１内に存在する「ＷＥＢ」ブラウザ１０によって、もしくは、エージェント間のセッションの実施によって、インターネットＲＩの何らかのポイントで探索された遠隔ブラウザ４によって、起動することができる。本発明の方法によれば、アプリケーションＡ_１からＡ_ｎは、書き直す必要なく、そのまま利用することができる。
【０１０４】
上で記述したエージェント機構を実施する本発明の別の態様によれば、チップカード２ａ上に「ＴＣＰ／ＩＰプロキシ」と呼ばれる機能を直接インプリメントする。この機能は、以下「フィルタ」と呼ぶことにする特別なソフトウェアアプリケーションで実施される。
【０１０５】
「プロキシ」機能はインターネットアプリケーションの分野においてはよく知られているが、知られている技術によるシステムのチップカード内にはインプリメントすることができない。
【０１０６】
本発明によるアーキテクチャを記述する前に、図５を参照して、知られている技術による従来の「プロキシ」の特徴を今一度簡潔に述べる。
【０１０７】
「ＴＣＰ／ＩＰ」技術においては、「ＴＣＰ／ＩＰ」サーバＳｖと「ＴＣＰ／ＩＰ」クライアントＣｌとを実現するソフトウェアエンティティＰｙを「プロキシ」と呼ぶ。ソフトウェアエンティティＰｙは、ローカルクライアントと別のリモートＴＣＰ／ＩＰサーバとの間に接続を実現する。
【０１０８】
通常、プロキシＰｙはフィルタおよび／またはセキュリティの機能を実現する。たとえば「ｈｔｔｐ」プロキシは通常、企業内において、あるナビゲータ、たとえば端末１のナビゲータ１０から「ＷＥＢ」サーバ４への接続を確保する（これは「ファイアウォール」すなわち「防火壁」という名称で知られている）。また、「ＳＳＬ」と呼ばれるプロキシのことを指すこともある。これは、端末に対しローカルであって、インターネット網ＲＩを通してセキュアードトンネルを確立するのに必要なセキュリティ操作（認証−機密−完全性）を実施する「プロキシ」であると定義することができる。
【０１０９】
次に、図６を参照して、本発明の追加的態様により「プロキシ」機能をチップカード内に直接内蔵するソフトウェアアーキテクチャを記述する。
【０１１０】
前の図と共通な要素には同じ符号が付与されており、これらは必要な場合にのみ再度記述する。記述を簡単にするために、端末１側のエージェントをただ１つの符号１３２でまとめ、チップカード２ａ側をただ１つの符号２３２ａでまとめた。以下の記述では、「端末」については文字「Ｔ」で、「スマートカード（チップカード）」については「Ｓ」でこれら符号が区別される。文字は指数として数字に組み合わされる。チップカード２ａ上に実現される「プロキシ」２７は、以下の記述においては「スマートプロキシ」と呼ぶことにする。
【０１１１】
「スマートプロキシ」２７は、以下に記述するように、端末１側の２つ：Ｔ_１およびＴ_２、チップカード２ａ側の２つ：Ｓ_１およびＳ_２の４つのエージェントと、フィルタ機能２８との組み合せにより実現される。すなわち、
− 「端末／クライアント／ネットワーク」エージェントＴ_１は、（たとえばポート８０８０上で）ＴＣＰ／ＩＰサーバを実現する。
【０１１２】
− 「カード／サーバ／ローカル」エージェントＳ_１はセッションによりエージェントＴ_１に組み合わされ、通常、後者は「ＷＥＢ」サーバの機能を実現する。
【０１１３】
− エージェントＴ_１からの情報に応じて決定されるフィルタ機能２８は、エージェントＳ_１およびＳ_２に対し「ｐｄｕ」の送受信を行うことができる。
【０１１４】
− 「ネットワーク」エージェントＴ_２とのセッションをオープンするフィルタ機能２８およびＳ_２により、「カード／サーバ／ローカル」エージェントＳ_２のインスタンスが動的に生成され、Ｓ_２が接続されたいと所望するインターネットリモートサーバ４のアドレスがネットワークサーバに示される。
【０１１５】
− 「端末／クライアント／ネットワーク」エージェントＴ_２は、インターネットサーバ４に接続されている「ＴＣＰ／ＩＰ」クライアントの機能を実現する。
【０１１６】
以下に、「スマートプロキシ」２７の生成機構を記述する。
【０１１７】
以後「ｃＴＣＰ」と呼ぶことにし、通常、「ＷＥＢ」ナビゲータ１０である「ＴＣＰ」クライアントは、「ネットワーク」エージェントＴ_１との接続を開く。次にセッションＴ_１−Ｓ_１が生成される。たとえば下記ＵＲＬは
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｘｘｘ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （２）
エージェントＴ_１およびＳ_１間でセッションの開始を生じさせる。
【０１１８】
エージェントＳ_１（ＷＥＢサーバ）に結合されたアプリケーションは、Ｔ_１およびＳ_１でやりとりされるデータから、どのフィルタ機能２８を使用すべきかを決定する。したがって「ｄｅｓ１」はある個別のフィルタの名称であり、「ｘｘｘ．ｃｏｍ」は、あるインターネットサーバ、たとえばサーバ４の任意の名称であり、「８０」はポート番号であり、「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」は、例においては「ＨＴＭＬ」言語によるページで構成される、このサーバ上の１つのファイルの任意の名称である。例においては、「ｄｅｓ１」フィルタは、「ＤＥＳ」（「Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎａｒｄ」）型アルゴリズムによる解読および／または暗号化作業を行うことができるフィルタである。
【０１１９】
言い換えれば、「カード」ＵＲＬ（２）は、外部に向けた別のＵＲＬをカプセル化し、このＵＲＬは、関係式（１）により定義されるようなループバックＵＲＬにより構成される。
【０１２０】
「ｄｅｓ１」フィルタ２８はクライアントＳ_２のインスタンスを作成し、エージェントＳ_２とＴ_２との間でセッションが開始する。最初の「ｐｄｕ」（「ＯＰＥＮｐｄｕ」）に挿入されるデータはインターネットサーバの名称（「ｘｘｘ．ｃｏｍ」）および結合されたポート番号（８０）を指定する。
【０１２１】
エージェントＴ_２は、リモートサーバ「ｓＴＣＰ」（「ｚｚｚ．ｃｏｍ」）に対し、「ＴＣＰ」型の接続を開始する。この接続が確立するとＳ_２に向けてトークンが送信される。
【０１２２】
これらのやりとりが終了すると、「スマートプロキシ」２７が生成されていて、チップカード２ａ内に常駐するフィルタ機能２８は、「ネットワーク」エージェントが受信した（インターネット網ＲＩからの）データを処理することができる。フィルタ２８は、「ネットワーク」エージェントＴ_１およびＴ_２により送信されたデータを論理的にチェックする。フィルタは、クライアント「ｃＴＣＰ」とサーバ「ｓＴＣＰ」との間でかわされるデータをチェックする「ＴＣＰプロキシ」として振舞う。
【０１２３】
趣旨を明らかにするために、種々のエージェントの任意の符号を図６に示した。すなわち、Ｔ_２およびＳ_１の「サーバ」型エージェントについての固定エージェントは「２」から「５」であり、Ｔ_１およびＳ_２の「クライアント」型エージェントについての可変または一時的エージェントは「１５３６０」および「２５５９」である。
【０１２４】
次に、フィルタ２８の個別例をより詳細に記述する。
【０１２５】
例１：リダイレクトフィルタ
リダイレクトフィルタは、たとえば以下のＵＲＬなどのカードＵＲＬに
（ｈｔｔｐ／／１２７．０．０．１：８０８０／ｅＭａｉｌ） （３）
識別データ、すなわち無料メールサーバ「ｅｍａｉｌ」に関連付けられたたとえば「ｌｏｇｉｎ」およびパスワードを、よく知られている「ＰＯＳＴ ｈｔｔｐ」という方法を使用することにより投稿するのに使用することができる外部サーバ（たとえばｗｗｗ．ｅｍａｉｌ．ｃｏｍ）への「ｈｔｔｐ」要求を関連付ける。フィルタは、チャレンジを基本とするより確実な方法（これらの方法はたとえば規格「ｈｔｔｐ１．１」において記述されている）。
【０１２６】
フィルタの実施は通常、以下の段階を含む。
【０１２７】
１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１２７．０．０．１：８０８０）との接続を開始し、カード２ａの「ＷＥＢ」サーバとのセッションＴ_１−Ｓ_１が開始する
２．（勧告「ｈｔｔｐ１．１ｒｆｃ２０６８」による）「ｈｔｔｐ」要求が、ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に送信され、このエージェントが、「／ｅＭａｉｌ」ファイルの名称から、この特別な場合におけるリダイレクトフィルタ２８への呼び出しを検出し、その瞬間から、「ネットワーク」エージェントＴ_１が受信した全データがこの特別フィルタ２８により処理される
３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成される
４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「ＷＥＢ」サーバ４のアドレスおよびポート（例においては「ｗｗｗ．ｅｍａｉｌ．ｃｏｍ」）を含む
５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始後、トークンがエージェントＳ_２に送信される
６．エージェントＳ_２が「ｈｔｔｐ」要求をリモート「ＷＥＢ」サーバ４に送信する
７．通常、このサーバ４が、操作の成功を通知し、ナビゲータに新規接続「ＵＲＬ」と、使用すべきソフトウェア部「クッキー」とをナビゲータ１０に供給する「ｈｔｔｐ」リダイレクトヘッダを送信する
８．これらのデータに関してフィルタ機能２８が何も処理を行わない
９．セッションＳ_１−Ｔ_１によりデータが「ＷＥＢ」ナビゲータ１０に送信される
ナビゲータ１０は、リダイレクトヘッダを受信すると、適当な「クッキー」によりメールサーバ４に接続する。通常、ナビゲータは「ＨＴＭＬ」言語で書かれたホームページを折り返し受信する。
【０１２８】
例２：「ｈｔｔｐ−ｄｅｓ」フィルタ
次に、前出の「ＤＥＳ」型アルゴリズムにより符号化される「ＨＴＭＬ」ページの場合を想定する。たとえば「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」という名称のこのページは、「ＷＥＢ」サーバ４、すなわち「ｚｚｚ．ｃｏｍ：８０」に格納される。（任意の名称「？ｄｅｓ１」のカード内にあるフィルタ機能２８は、解読アルゴリズムすなわち逆の機能（あるいは「ＤＥＳ^−１」）を実施するが、これには、索引１に関連付けられた鍵を使用する。
【０１２９】
ナビゲータ１０から実行される以下のＵＲＬ
ｈｔｔｐ：／／ｚｚｚ．ｃｏｍ／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （４）
は、「ｚｚｚ．ｃｏｍ」サーバからの「ｃｏｎｔｅｎｔ．ｈｔｍｌ」ファイルのロードを発生させる。「ＨＴＭＬ」ページが符号化されると、「ＨＴＭＬ」言語の取り決めに従い文書の始まりおよび終りを示すタグ「ｈｔｍｌ＞および＜／ｈｔｍｌ」は平文には現れず、ナビゲータ１０は、意味のない記号か、「ＨＴＭＬ」ページが受信されなかったことを示すエラーを表示する。
【０１３０】
以下のＵＲＬ
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｚｚｚ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （５）
は、鍵のインデックスが１である「ＤＥＳ」型のフィルタ２８を通して以下のページをロードするようカードに指示する。
【０１３１】
ｈｔｔｐ：／／ｚｚｚ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （６）
「ｃｏｎｔｅｎｔ．ｈｔｍｌ」ページのロードは以下の様に行われる。
【０１３２】
１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１２７．０．０．１：８０８０）との接続を開始し、チップカード２ａの「ＷＥＢ」サーバとのセッションＴ_１−Ｓ_１が開始する
２．（「ｈｔｔｐ１．１ｒｆｃ２０６８」）「ｈｔｔｐ」要求が、ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に送信され、この「ＷＥＢ」エージェントＳ_１が、「／？ｄｅｓ１＝ｚｚｚ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」ファイルの名称から、（索引鍵１）「ＤＥＳ」型フィルタ２８への呼び出しを検出し、その瞬間から、「ネットワーク」エージェントＴ_１が受信した全データが、索引鍵１に関連付けられた「ＤＥＳ」型フィルタ２８により処理される
３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成される
４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「ＷＥＢ」サーバ４のアドレスおよびポート（「ｚｚｚ．ｃｏｍ）を含む
５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始後、トークンがエージェントＳ_２に送信される
６．エージェントＳ_２が「ｈｔｔｐ」要求をリモート「ＷＥＢ」サーバ４に送信する
７．リモートサーバ４が、ファイルの性質を示す「ｈｔｔｐ」ヘッダを送信し、本来の意味でのファイルを送信する：これらのデータはセッションＴ_２−Ｓ_２によりフィルタ機能２８に中継される
８．「ｈｔｔｐ」ヘッダに関してフィルタ機能２８が何も処理を行わず、「ＨＴＭＬ」ページを解読する
９．解読されたデータが、セッションＳ_１−Ｔ_１により「ＷＥＢ」ナビゲータ１０に送信される
この操作の結果として、ナビゲータ１０は復号された「ＨＴＭＬ」ページを受信する。リダイレクト操作はスクリプト（通常は、登録商標である「Ｊａｖａ Ｓｃｒｉｐｔ」言語による）により自動化することができる。たとえば（仮に「ｃｏｎｔｅｎｔ．ｈｔｍｌ」）と呼ぶことにする）「ＨＴＭＬ」ページ内に含まれるスクリプトは、以下のＵＲＬ
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｚｚｚ．ｃｏｍ／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （８）を
ｈｔｔｐ：／／ｚｚｚ．ｃｏｍ／ｙｙｙ／ｘｃｏｎｔｅｎｔ．ｈｔｍｌ （７）に
リダイレクトする。
【０１３３】
ここでｘｃｏｎｔｅｎｔ．ｈｔｍｌおよびｃｏｎｔｅｎｔ．ｈｔｍｌは２つの「ＨＴＭＬ」の任意の名称である。
【０１３４】
例３：「ＳＳＬ」フィルタ
「Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ」すなわち「ＳＳＬ」と呼ばれるプロトコルは、「ＷＥＢ」型アプリケーション用として広く使われている。このプロトコルにより、クライアント（通常はナビゲータ１０）とサーバとの間に「セキュアトンネル」を開通させることが可能である。「ＳＳＬ」により、サーバを認証するとともに、やりとりされるデータの機密性および完全性を確保することができる。これを行うために、サーバに固有の公開鍵から共有機密が作成される。共有機密からセッション鍵が推定され、この鍵により、「トリプルＤＥＳ」型のアルゴリズムを使用して情報の解読が行われる。おのずとわかるように、認証「証明」を使用する技術も使用することができる。
【０１３５】
「ＳＳＬ」フィルタをチップカード２ａ内に直接作製する利点は、サーバの公開鍵の証明書の確認（これが公開鍵システムの重要部分を成す）が、先験的に安全性が低いと判断される、端末内に常駐するソフトウェアではなく、チップカードにより行われることである。従来は、いったん「ＳＳＬ」セッションが開かれると、ユーザすなわち「インターノート」（図示せず）は、キーボード（図１Ａ、６ａ）を使用して、端末１上で平叙文で入力される「ｌｏｇｉｎ」とパスワードとの組み合せである個人識別データを入力する。チップカード２ａから実施される「ＳＳＬ」セッションの別の長所は、「ｌｏｇｉｎ」およびパスワードがユーザによってではなく、チップカード２ａによって提供されることである。
【０１３６】
「ＳＳＬ」接続は以下のようにして行われる。
【０１３７】
次に、「ＳＳＬ」セッションにより取得を所望する「ＨＴＭＬ」ページを想定する。たとえば「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」という名称のこのページは、（任意の名称「ｗｗｗ．ｂａｎｋ．ｃｏｍ」）のリモート「ＷＥＢ」サーバ４に格納される。（任意に「？ｓｓ１」と呼ばれる）カード内にある特別フィルタ機能２８は、ＳＳＬプロトコルを実施し、ｌｏｇｉｎ、および索引１に関連付けられたパスワードを使用する。
【０１３８】
以下のＵＲＬ
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｓｓｌ１＝ｗｗｗ．ｂａｎｋ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （９）
は、「ＳＳＬ」プロトコルを使用して「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」のページをロードするようチップカード２ａに指示する。
【０１３９】
「ｃｏｎｔｅｎｔ．ｈｔｍｌ」ページのロードは以下の様に行われる。
【０１４０】
１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１２７．０．０．１：８０８０）との接続を開始し、チップカード２ａのＷＥＢサーバとのセッションＴ_１−Ｓ_１が開始する
２．（「ｈｔｔｐ１．１ｒｆｃ２０６８」に適合した）「ｈｔｔｐ」要求が、ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に送信され、「ＷＥＢ」エージェントＳ_１が、「／？ｓｓ１＝ｗｗｗ．ｂａｎｋ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」ファイルの名称から、（索引鍵１を有する）「ＳＳＬ」型フィルタ２８への呼び出しを検出し、その瞬間から、「ネットワーク」エージェントＴ_１が受信した全データが、索引鍵１に関連付けられた「ＳＳＬ」型フィルタ２８により処理される
３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成される
４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「ＳＳＬ ＷＥＢ」サーバ（「ｗｗｗ．ｂａｎｋ．ｃｏｍ：４４３」）のアドレスおよびポート（この例においてはＮｏ４４３）を含む
５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始後、トークンがエージェントＳ_２に送信される
６．フィルタ２８がセッションＴ_２−Ｓ_２を使用して、リモートサーバ４との間で「ＳＳＬ」プロトコルに準拠したネゴシエーションを開始する
７．「ＳＳＬ」セッションが開始すると、フィルタ２８により「ｌｏｇｉｎ」およびパスワードがリモートサーバ４に送信され、セッションＴ_２−Ｓ_２が閉じられる
８．フィルタ２８により新しいセッションＳ_２−Ｔ_２が開始される
９．フィルタ２８が、前回の「ＳＳＬ」セッションの再開をネゴシエートする １０．エージェントＳ_２がファイル取得暗号化「ｈｔｔｐ」要求をリモートサーバ４に送信する
１１．リモートサーバ４が、ファイルの性質を示す「ｈｔｔｐ」ヘッダを送信し、本来の意味でのファイルを送信する：これらのデータはセッションＳ_２−Ｔ_２によりフィルタ機能２８に中継される
１２．フィルタ機能２８が受信データを復号しその完全性を確認する
１３．解読されたデータが、セッションＳ_１−Ｔ_１により「ＷＥＢ」ナビゲータ１０に送信される
この操作の結果として、ナビゲータ１０は復号された「ＨＴＭＬ」ページを受信する。リダイレクト操作はスクリプト（通常は、登録商標である「Ｊａｖａ Ｓｃｒｉｐｔ」言語による）により自動化することができる。たとえば「ＨＴＭＬ」ページ内に含まれるスクリプトは、以下のＵＲＬ
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｓｓｌ１＝ｗｗｗ．ｂａｎｋ．ｃｏｍ／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （１０）を
ｈｔｔｐ：／／ｗｗｗ．ｂａｎｋ．ｃｏｍ／−ｙｙｙ／ｘｃｏｎｔｅｎｔ．ｈｔｍｌ （１１）に
リダイレクトする。
【０１４１】
次に、非対称通信プロトコルにより特にマルチメディアデータストリームを処理することができる本発明の追加的態様を記述する。
【０１４２】
端末１がたとえばインターネット網ＲＩからマルチメディアデータを取得すると、これらのデータは一切の機密的特性を失い、一般的に安全性が低いシステムにより記憶される。
【０１４３】
本発明の特徴のうちの１つにより実現される「スマートプロキシ」は、個別サービスの享受者の識別および認証のための鍵装置を構成する。アルゴリズムおよび鍵はチップカード２ａの内部に保存され実行される。個別フィルタ２８がリモートサーバ４との間で「ＴＣＰ」接続をいったん開始すると、２つの場合を想定することができる。すなわち
Ａ／データの完全性および機密性を確保するために固定鍵および秘密鍵が使用される。すなわちこの場合、「スマートプロキシ」のフィルタにより、データストリームが解読され確認される
Ｂ／フィルタ２８とリモートサーバ４との間で接続の開始が成功すると、「セッション鍵」とも呼ばれる一時鍵が計算される。すなわちたとえば前出の「ＳＳＬ」プロトコルまたは「ＩＰＳＥＣ」プロトコルのようなインターネット網のために使用される多くのセキュリティプロトコルにおいては、第２のケースが発生する。
【０１４４】
一時セッション鍵が使用される時には、いずれにしろこれらの鍵は一回しか使われずかつ鍵の唯一の目的は安全性の低い端末へデータの平文転送を可能にすることであるため、チップカード２ａによるアルゴリズムの計算には特別な意味はない。
【０１４５】
セキュリティの観点から見た場合、サーバ４との接続が非対称であることもある。識別手順および認証手順は秘密であるが、次にやりとりされるデータは何ら機密性を有していない。そのような経緯から、データストリームという概念が生まれることになり、以後、「スマートプロキシ」により機密的に処理すべきデータを表す「クリティカルストリーム」を「クリティカル」と呼ぶことにする。（時には同一の接続中に変化することがある）一時セッション鍵はクリティカルストリームから推定することができ、端末１は、特別な安全措置を講ずることなくこの鍵を使用することができる。
【０１４６】
したがってこれ以降は、「スマートプロキシ」により処理すべきデータストリームを指すクリティカルストリームと、安全ではない端末上で処理することができる「オパーク」データストリームとを区別することにする。
【０１４７】
この状況においては、フラグフィールドの特別な値により識別される「ｐｄｕ」（コマンドの「ｐｄｕ」）により、コマンドをエージェントに送信することができる。これらのコマンドは本来の意味でのアドレスされたエージェントにより処理され、別のエージェントまたはネットワークＲＩには送信されない。
【０１４８】
同じくこの状況においては、本発明に固有のエージェントの機構が実現されるが、データのやりとりはセッション外で行うことができる。
【０１４９】
実際、２つのエージェントは、セッションを経由して接続しなくとも、ある量のデータを交換することができる。個別コマンド「ｐｄｕ」は、任意にＡ_１と呼ぶ第１エージェントに、（ソースリファレンス、デスティネーションリファレンスおよびフラグのフィールドを除いて）送信すべきデータ量Ｑ_１を示し、別の「ｐｄｕ」は、エージェントＡ_１から送信されエージェントが受信することができるデータ量Ｑ_２を、任意にＡ_２と呼ぶ第２エージェントに示す。「ＣＬＯＳＥ」フラグを含む「ｐｄｕ」はセッション外では送信されない。
【０１５０】
クリティカルおよびオパークストリームのルートはそれぞれ以下の通りである。
【０１５１】
クリティカルストリームは、「スマートプロキシ」に結合されたフィルタ２８により処理されしたがって必ずチップカード２ａを経由しなければならない機密情報を含む。オパークストリームは、たとえばセッション外データ交換機構を使用することにより、端末１上にあるエージェントによってのみ処理することができる。
【０１５２】
オパークストリームは、クリティカルストリームによりセキュア化することができる。
【０１５３】
実際、データのグローバルストリームは通常、オパークストリームとクリティカルストリームとに分解することができ、それによりたとえば、振幅がより小さいクリティカルストリームにより、（たとえば本来の意味でのマルチメディアデータを示す）高データレートストリームを解読することができる。
【０１５４】
本発明に固有の構成により非対称データ通信および処理プロトコルを編成することにより、そのような高データレートマルチメディアデータを処理することが可能になる。
【０１５５】
例４：非対称リダイレクトフィルタ
非対称リダイレクトフィルタは、
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｆ１＝／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｕｎＦｉｃｈｉｅｒ （１２）
型の「カード」ＵＲＬに、
ｈｔｔｐ：／／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｕｎＦｉｃｈｉｅｒ （１３）
のような外部サーバ４への「ｈｔｔｐ」要求を関連つける。
【０１５６】
識別および認証の段階（たとえば「チャレンジ」を基本とする機構）を含むサーバ４への接続は、「スマートプロキシ」２７に組み合わされたフィルタ２８−以後任意に「？ｆ１」と呼ぶことにする−により制御される。フィルタ２８は非対称である。なぜなら、いったん認証が行われると、サーバ４との間で交換されるデータは暗号化されず、もはやフィルタ２８を経由しない。
【０１５７】
（図６のシステムの本発明によるアーキテクチャを簡略的に示す）図７の線図により概略的に示す非対称リダイレクトフィルタ２８の実施段階は以下の通りである。
【０１５８】
１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１２７．０．０．１：８０８０）との接続を開始し、チップカード２ａのＷＥＢサーバとのセッションＴ_１−Ｓ_１が開始する
２．「ｈｔｔｐ」要求が、ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に送信され、「ＷＥＢ」エージェントＳ_１が、「／？ｆ１＝／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｕｎＦｉｃｈｉｅｒ」ファイルの名称から、個別リダイレクトフィルタ２８（「？ｆ１」）への呼び出しを検出し、その瞬間から、「ネットワーク」エージェントＴ_１が受信した全データがこのフィルタ２８により処理される
３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成される
４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「ＷＥＢ」サーバ４のアドレスおよびポート（「ｗｗｗ．ｈｏｓｔ．ｃｏｍ」）を含む
５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始後、トークンがエージェントＳ_２に送信される
６．フィルタ２８（「？ｆ１」）とリモートサーバ４との間で認証手続が行われ、セッションＳ_２−Ｔ_２によりデータのやりとりが行われる
７．この手続が成功すると、フィルタ２８はコマンドの「ｐｄｕ」をエージェントＴ_１に送り、エージェントＴ_１はフィルタに対し、エージェントＴ_２によりセッション外で送信された全データを受信することを許可し、「ネットワーク」エージェントＴ_２にコマンドの「ｐｄｕ」を送る。このエージェントはフィルタに対し、ネットワークから受信した全データをエージェントＴ_１に送るよう指示する。すなわち、リモートサーバ４からのデータはエージェントＴ_２およびＴ_１によりナビゲータ１０に中継されるため、チップカード２ａを通過することはしなくなる
８．（サーバ４のコマンドにより）「ＴＣＰ」切断が発生すると、エージェントのうちの一方Ｔ_１またはＴ_２が、「ＣＬＯＳＥ」状態のフラグを有する「ｐｄｕ」を、エージェントのうちの一方Ｓ_１またはＳ_２に送信し、フィルタ２８は、セッションＴ_１−Ｓ_１およびＴ_２−Ｓ_２の放棄を管理する。
【０１５９】
例５：非対称「ＳＳＬ」フィルタ
この例は、図６のシステムの本発明によるアーキテクチャの主要部分を簡略に示した図８の線図により概略的に図示されている。
【０１６０】
上の例３において記述したように、「ＳＳＬ」フィルタは、「カード」ＵＲＬ（たとえば式（１１）のそれ）を使用して能動化することができる。このようなプロトコルにおいては、解読アルゴリズムおよび単一方向ハッシュ機能（または英語で「ハッシュ」）を備える一対のエンティティ、ならびにある数の関連パラメータ（「ハッシュ」機能の鍵および現在値）を選択するために、クリティカルデータストリームが使用される。いったんネゴシエーション段階が終了すれば、チップカード２ａ内でのこれらのアルゴリズムの実行は特別な意味を有するものではない。なぜならデータは平文でインターネット網ＲＩから端末１に送られるからである。
【０１６１】
したがって有利には、「ＳＳＬ」機能が割り当てられた（サーバ型の）追加エージェントＴ_３を使用することができる。このエージェントＴ_３は、端末１内に配置される。いったん「ＳＳＬ」セッションのパラメータのネゴシエーションが行われると、「ＳＳＬ」フィルタ２８は、追加クライアントエージェントＳ_３（チップカード２ａ側）と「ＳＳＬ」サーバエージェントＴ_３（端末側）との間でセッションを開始する。セッションの開始時、エージェントＴ_３は「ＤＥＳ」鍵の値および「ハッシュ」機能の現在のパラメータで初期化される。「ＳＳＬ」フィルタ２８はコマンドの「ｐｄｕ」をエージェントＴ_２に送るが、このエージェントによりフィルタは、セッション外にＴ_３により送信されたデータをネットワークＲＩに再送信し、ネットワークから受信したデータをＴ_３にリダイレクトすることができる。「ＳＳＬ」フィルタ２８は、エージェントＴ_３が、Ｔ_１およびＴ_２によって送信されたデータをセッション外で受信できるようにコマンドの「ｐｄｕ」をエージェントＴ_３に送る。「ＳＳＬ」フィルタはエージェントＴ_１にコマンドの「ｐｄｕ」を送るが、このエージェントによりフィルタは、セッション外にＴ_３により送信されたデータをネットワークＲＩに再送信し、このネットワークＲＩから受信したデータをＴ_３にリダイレクトすることができる。すると、端末１内のＴ_１−Ｔ_２−Ｔ_３間にセッション外「トンネル」が確立される。エージェントＴ_１またはＴ_２が、自身に関連するセッションを閉じると、フィルタ２８は、残っている別の２つのセッションの閉動作を行う。
【０１６２】
非対称フィルタ、一般的な場合
より一般的には、図７および図８の線図のいずれか１つを再度参照すると、非対称フィルタ２８使用手順の諸段階は以下の通りである。
【０１６３】
２つのセッションＴ_１−Ｓ_１およびＴ_２−Ｓ_２により「カード」ＵＲＬから「スマートプロキシ」２７（図６）が作製される。作製すべき個別２８がこのＵＲＬから決定される。最初にフィルタ２８が、「ＴＣＰ」クライアント（ナビゲータ１０）とリモートサーバ４との間のデータストリームを制御する。認証およびネゴシエーション段階の終了時に一組のセキュリティパラメータが得られる。このパラメータはクリティカルデータストリームから成る。
【０１６４】
するとフィルタ２８は、セッションの開始時にフィルタ２８により定義される一組のパラメータでネゴシエーションが行われるプロトコルを実施するセキュリティエージェント（たとえばＴ_３）とのセッションを開始する。フィルタ２８は、セッションＴ_１−Ｔ_２−Ｔ_３外のデータ転送「トンネル」を生成する。連Ｔ_１−Ｔ_２−Ｔ_３により、あらかじめ決められた量のデータが帯域外で送信される。別の言い方をすれば、オパークデータストリームはＴ_１−Ｔ_２−Ｔ_３のユニットで処理されるため、チップカード２ａを経由しない。オパークデータは、周期的に固定されるオパークデータ長、緊急データポインタによる「ＴＣＰ」パケット内のマークなど種々の方法により識別することができる。これらの方法は周知のものである。クリティカルデータはオパークデータとは反対に、端末１のエージェントＴ_１またはＴ_２によりフィルタ２８に送信される。その結果、フィルタは、コマンドの「ｐｄｕ」により、エージェントＴ_３の機能パラメータを変更する。端末１のエージェントＴ_１またはＴ_２が、自身に関連するセッションを閉じると、フィルタ２８は、残っている別の２つのセッションの閉動作を行う。
【０１６５】
同様に、一般的には、オパークデータストリームは、セキュリティに関するあらゆる態様以外に、たとえばエージェントＴ_３と同様の追加エージェントにより実行される種々の変更を受けることができる。「セキュリティ」という用語は、特に「証明書」などを使用することにより、機密性、許可、封印、または署名などより広範な許容範囲で理解しなければならない。
【０１６６】
この場合、結果として、フィルタ２８は上と同様に、個別の「ｐｄｕ」の使用により、エージェントＴ_３のパラメータを変更することができる。
【０１６７】
趣旨を明らかにするために、非限定的例として、フォーマットの変換を行うことができる。音声データの場合、たとえば「ｍｐ３」フォーマットにより符号化されて送信されるオパークデータは、「ｗａｖ」フォーマット、あるいは端末１が受け入れる別のあらゆるフォーマットに変換することができる。ビデオデータについても同様であり、「ＭＰＥＧ」データで受信されるオパークデータは、「ａｖｉ」フォーマット、あるいは端末１が受け入れる別のあらゆるフォーマットに変換することができる。
【０１６８】
いずれの場合も、クリティカルデータを構成する小サイズ低データレートデータストリームのみがチップカード２ａを経由する。次に、Ｔ_１およびＴ_２、場合によってはＴ_３を経由する、端末内のオパークストリームのデータの通過ならびにその処理を制御する適切なフィルタを選択するにはこれらのデータのみが必要である。
【０１６９】
言い換えれば、チップカードを「ＷＥＢ」クライアント／サーバに変換し、この中に「プロキシ」を直接作製することができる本発明に固有な構成により、チップカードは情報ストリームの処理を委任することができるが、情報量は、チップカードが接続されている端末により固定される。きわめて高いデータレートを有するグローバルストリームは、非対称通信プロトコルが実行されるおかげで、最高の程度のセキュア化を保ちながら、チップカード端末により処理することができることがわかる。この高度なセキュア化は、主たる暗号化および／または認証作業がチップカードの排他的制御下にあり、クリティカルデータがチップカードを経由することによるものである。
【０１７０】
前出の内容を読むことにより、本発明は設定した目的を達成したことが容易に確認できよう。
【０１７１】
しかしながら、本発明は、特に図２から図４ならびに図６から図８を参照して明示的に記述した実施例に限定されるものではないことは明らかであろう。
【０１７２】
また、記述した過程は反転可能であること、すなわちサーバと端末との間の送信は双方向に行うことができることも明らかであろう。実際、端末は、常にチップカードの制御下で、高データレートファイルをリモートサーバに送信することもできる。この場合、クリティカルデータは、万一、リモートサーバとのネゴシエーション段階があった場合にはその後に、チップカードに供給される。
【０１７３】
最後に、高データレートセキュア化マルチメディアデータストリームの送信の場合における方法を詳細に記述したが、上に示したような本発明による方法は、この個別の適用例に何ら限定されるものではない。
【０１７４】
本発明は、少なくとも１つのリモートサーバと、チップカードリーダを具備する端末との間における、インターネット型ネットワークを経由するデータストリームの送信方法であって、前記端末が情報処理手段と情報記憶手段とを備え、情報記憶手段が少なくとも１つの「ＴＣＰ／ＩＰクライアント」型アプリケーションを含み、チップカードが情報処理手段と情報記憶手段とを備え、前記端末と前記サーバの双方が前記インターネット型ネットワークに接続され、
ａ／前記チップカード（２ａ）の情報記憶手段内に、専用通信プロトコル層を形成する第１ソフトウェア（２３ａ）をインプリメントすることから成る第１段階と、
ｂ／前記端末（１）の情報記憶手段内に、専用通信プロトコル層を形成し、少なくとも１つの前記「ＴＣＰ／ＩＰ」型アプリケーション（１０）とのインタフェースを形成する第２ソフトウェア（１３）をインプリメントすることから成る第２段階と
を備えること、
− さらに前記第１および第２ソフトウェア部（１３、２３ａ）がそれぞれ、クライアント型の第１独立ソフトウェアエンティティ（Ｔ_２、Ｓ_１）と、サーバ型の第２独立ソフトウェアエンティティ（Ｔ_１、Ｓ_２）とを備え、前記端末（１）と前記チップカード（２ａ）との間で双方向データ交換セッションを確立し、前記チップカード（２ａ）が「ＷＥＢ」型クライアント／サーバの機能を提供するようにし、かつ前記インターネット型網（ＲＩ）を経由して、前記端末（１）と、前記リモートサーバ（４）との間で双方向データ交換セッションを確立するよう、端末およびチップカードの情報処理手段により前記エンティティ（Ｔ_１、Ｓ_１、Ｔ_２、Ｓ_２）が、協働し、前記独立ソフトウェアエンティティが、あらかじめ決められたプロトコルのデータユニットで通信すること、
− 前記第２専用ソフトウェア部（２３ａ）内に含まれるクライアントおよびサーバ型の前記第１および第２独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）におよび／またはからプロトコルデータユニットを受信および／または送信する「フィルタ」（２８）と呼ばれる所与の機能特性の適用ソフトウェア部を前記チップカード（２ａ）の情報記憶手段内に実施する段階を備え、前記適用部分の実施が前記サーバ（Ｓ_１）型独立ソフトウェアエンティティの制御下にあること、
− 前記専用第１ソフトウェア部（１３）の前記独立フトウェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを開始し、前記端末（１）と前記リモートサーバ（４）との間で送信される前記データストリームのあらかじめ決められた特性を変更するために、チップカードの前記情報処理手段により、前記フィルタ（２８）が、前記専用第２ソフトウェア部（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）と協働すること
を特徴とする方法にも関する。
【図面の簡単な説明】
【図１Ａ】 知られている技術によるチップカードを基にするアプリケーションシステムの例のそれぞれハードウェアアーキテクチャおよびソフトウェアアーキテクチャを示す略図である。
【図１Ｂ】 知られている技術によるチップカードを基にするアプリケーションシステムの例のそれぞれハードウェアアーキテクチャおよびソフトウェアアーキテクチャを示す略図である。
【図２】 本発明による、「ＷＥＢ」サーバとして動作するチップカードを基にするアプリケーションシステムの例を示す略図である。
【図３】 本発明の一態様によるインテリジェントエージェントと呼ばれるソフトウェアエンタイティ間のセッションのステイタスダイアグラムである。
【図４】 チップカードがインテリジェントエージェントを備える本発明によるシステムのソフトウェアアーキテクチャの略図である。
【図５】 知られている技術による「プロキシ」の略図である。
【図６】 「プロキシ」と呼ばれるフィルタがチップカード上に作製される、図４のシステムに適合する本発明によるシステムのソフトウェアアーキテクチャの略図である。
【図７】 図６のアーキテクチャの種類の本発明によるアーキテクチャ内の（リダイレクトと呼ばれる）非対称フィルタの第１実施例を示す概略線図である。
【図８】 図６のアーキテクチャの種類の本発明によるアーキテクチャ内の（ＳＳＬと呼ばれる）非対称フィルタの第２実施例を示す概略線図である。

Claims (17)

1. 少なくとも１つのリモートサーバと、チップカードリーダを具備する端末との間における、インターネット型ネットワークを経由するデータストリームの送信方法であって、前記端末が少なくとも１つの「ＴＣＰ／ＩＰクライアント」型アプリケーションを含み、前記端末と前記サーバの双方が前記インターネット型ネットワークに接続され、
   ａ／前記端末（１）内に、特別通信プロトコル層を形成し少なくともＴＣＰ／ＩＰ型の前記アプリケーション（１０）とのインターフェースを形成する第１ソフトウェア（１３）を導入することから成る第１段階と、
   ｂ／前記チップカード（２ａ）内に、専用通信プロトコル層を形成する第２ソフトウェア（２３ａ）を導入することから成る第２段階と
   を備えること、
   さらに前記第１および第２ソフトウェア部（１３、２３ａ）がそれぞれ、クライアント型の少なくとも１つの第１独立ソフトウェアエンティティ（Ｔ_２、Ｓ_１）とサーバ型の第２独立ソフトウェアエンティティ（Ｔ_１、Ｓ_２）とを備え、前記端末（１）と前記チップカード（２ａ）との間で双方向データ交換セッションを確立し、前記チップカード（２ａ）が「ＷＥＢ」型クライアント及び／又は「ＷＥＢ」型サーバの機能を提供するようにし、かつ前記インターネット型網（ＲＩ）を経由して、前記端末（１）と、前記リモートサーバ（４）の１つとの間で双方向データ交換セッションを確立するよう、前記独立エンティティ（Ｔ_１、Ｓ_１、Ｔ_２、Ｓ_２）が協働し、前記独立ソフトウェアエンティティが、前記独立エンティティ（Ｔ _１ 、Ｓ _１ 、Ｔ _２ 、Ｓ _２ ）の特性に関連する少なくとも１つの識別子と、前記独立エンティティ（Ｔ _１ 、Ｓ _１ 、Ｔ _２ 、Ｓ _２ ）の状態を規定するフラグと呼ばれる少なくとも１つのエンティティとを有するあらかじめ決められたプロトコルのデータユニットで通信し、前記識別子と前記フラグは前記独立エンティティ（Ｔ _１ 、Ｓ _１ 、Ｔ _２ 、Ｓ _２ ）の間のデータ交換セッションの方向を決定すること、
   前記第２専用ソフトウェア部（２３ａ）内に含まれるクライアントおよびサーバ型の前記第１および第２独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）におよび／またはからプロトコルデータユニットを受信および／または送信する「フィルタ」（２８）と呼ばれる所与の機能特性の適用ソフトウェア部を前記チップカード（２ａ）内に実施する段階を備え、前記適用ソフトウェア部分の実施が前記サーバ型独立ソフトウェアエンティティ（Ｓ _１ ）の制御下にあること、
   前記専用第１ソフトウェア部（１３）の前記独立フトウェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを開始し、前記端末（１）と前記リモートサーバ（４）との間で送信される前記データストリームのあらかじめ決められた特性を変更するために、前記フィルタ（２８）が、前記専用第２ソフトウェア部（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）と協働すること、
   を特徴とする方法。
2. 前記独立ソフトウェアエンティティが、インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）で構成されることを特徴とする請求項１に記載の方法。
3. 前記のインテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）の各々は、
   −「ホスト」：前記端末（１）内で探索されるインテリジェントエージェント、
   −「カード」：前記チップカード（２ａ）内で探索されるインテリジェントエージェント、
   −「ローカル」：前記のネットワーク（ＲＩ）と通信しないインテリジェントエージェント、
   −「ネットワーク」：前記ネットワーク（ＲＩ）と通信するインテリジェントエージェント、
   −「クライアント」：前記セッションの１つを初期化するインテリジェントエージェント、
   −「サーバ」：前記セッションの１つのための要求を受取るインテリジェントエージェント、
   の６つの特性の少なくともいずれか１つに関連付けられ、前記識別子により識別されることを特徴とする請求項２に記載の方法。
4. 前記エージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）が、整数を含む識別子により識別されること、前記サーバ型インテリジェントエージェント（Ｔ_２、Ｓ_１）が前記「サーバ」特性に関連つけられ固定基準数又はシンボルにより識別されること、および前記クライアント型インテリジェントエージェント（Ｔ_１、Ｓ_２）が前記「クライアント」特性に関連つけられ、前記セッションのうちの１つを次のセッションに変更する可変基準数又はシンボルにより識別され、これらのセッションの際に前記クライアント型インテリジェントエージェントのインスタンスが生成されることを特徴とする請求項３に記載の方法。
5. 前記プロトコルデータユニットが、各独立エンティティ（Ｔ _１ 、Ｓ _１ 、Ｔ _２ 、Ｓ _２ ）の特性に関連する前記少なくとも１つの識別子に加えて、前記プロトコルデータユニットの性質を規定することにより及び前記エンティティへ状態を関連付けることにより前記独立エンティティ（Ｔ _１ 、Ｓ _１ 、Ｔ _２ 、Ｓ _２ ）の状態を規定する前記フラグの少なくとも１つと、前記データ交換セッション中に前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）間でやりとりされる任意データとを含むことを特徴とする請求項４に記載の方法。
6. 前記フラグが、
   前記セッションのうちの１つの開始を示す「ＯＰＥＮ」（開）と
   前記セッションのうちの１つの終了を示す「ＣＬＯＳＥ」（閉）と、
   前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）のうちの１つが、対応するインテリジェントエージェントからの応答の待機状態にあり非活動状態に留まっていることを示す「ＢＬＯＣＫ」（ブロック）
   の３つの状態のうちの少なくとも１つを取ることができること、
   および前記セッションが、
   前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）のうちの１つと前記インテリジェントエージェントの別の１つとの間に１つもセッションが開かれない時の「非接続」状態と、
   前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）の別の１つとの間で、前記識別子のうちの一対により識別されるセッションが開始される時の「接続」状態と、
   前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）のうちの１つが接続され、エージェントが接続されている前記インテリジェントエージェントのうちの１つからの応答を待っている時の「ブロック」状態
   の３つの状態をとることを特徴とする請求項５に記載の方法。
7. 前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）のうちの２つの間における前記セッションのうちの１つの確立段階が、
   ａ／前記クライアント型インテリジェントエージェント（Ｔ_１、Ｓ_２）のうちの１つであって、前記可変基準数又はシンボルのうちの１つの一時基準により識別されるインテリジェントエージェントの新規インスタンスを作製する段階と、
   ｂ／前記「ＯＰＥＮ」状態に位置決めされたフラグを有する、所定の固定基準数又はシンボルにより識別される前記サーバ型エージェント（Ｔ_２、Ｓ_１）のうちの１つに向けて前記プロトコルデータユニットのうちの１つを送信する段階と、
   ｃ／前記フラグ「ＢＬＯＣＫ」の値に応じて前記クライアント型インテリジェントエージェント（Ｔ_１、Ｓ_２）を接続またはブロック状態に移行させる段階と、
   ｄ／前記サーバ型エージェント（Ｔ_２、Ｓ_１）が、前記「ＯＰＥＮ」状態に位置決めされたフラグを有する前記プロトコルデータユニットを受信し、前記接続状態に移行する段階と、
   を含むこと
   および、前記セッションの開始後、前記２つの接続インテリジェントエージェントが、前記プロトコルデータユニットを経由してデータをやり取りすること
   を特徴とする請求項６に記載の方法。
8. 前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）のうちの２つの間の前記セッションのうちの１つを閉じる段階が、
   ａ／前記「ＣＬＯＳＥ」状態に位置決めされたフラグを有し、任意にはデータを含む前記プロトコルデータユニットのうちの１つを前記クライアント型インテリジェントエージェント（Ｔ_１、Ｓ_２）のうちの１つが送信する段階と、
   ｂ／前記接続サーバ型インテリジェントエージェント（Ｔ_２、Ｓ_１）が前記プロトコルデータユニットを受信し、前記セッションを非接続状態に移行させる段階と
   含むことを特徴とする請求項７に記載の方法。
9. 前記サーバ内にある前記「ＴＣＰ／ＩＰ」型アプリケーションが「ＷＥＢ」型ナビゲータ（１０）を含むことを特徴とする請求項８に記載の方法。
10. 前記第１専用ソフトウェア部が、「ＴＣＰ／ＩＰ」型サーバの機能を実現する、Ｔ _１ とよばれる、前記特性「ネットワーク」、「クライアント」、「端末」に関連付けられた第１インテリジェントエージェント（Ｔ_１）を備えること、前記第２専用ソフトウェア部が、Ｓ _１ とよばれる、前記特性「カード」、「サーバ」、および「ローカル」に関連付けられた第１インテリジェントエージェント（Ｓ_１）を備え、このエージェントＳ_１がセッションにより前記第１インテリジェントエージェントＴ_１に関連付けられること、前記フィルタ（２８）の前記所与の機能特性が前記第１インテリジェントエージェントＴ_１からの情報により決定されること、前記第１専用ソフトウェア部が、前記インターネット型ネットワーク（ＲＩ）を経由して前記リモートサーバ（４）に接続されるために、「ＴＣＰ／ＩＰ」型クライアントの機能を実現する、Ｔ _２ と呼ばれる、前記特性「端末」、「サーバ」、「ネットワーク」に関連付けられた第２インテリジェントエージェント（Ｔ_２）を備えること、および、前記第２専用ソフトウェア部（２３ａ）が、Ｓ _２ と呼ばれる、前記特性「カード」、「クライアント」、および「ローカル」に関連付けられた第２インテリジェントエージェント（Ｓ_２）を備え、前記インテリジェントエージェントＳ_２のインスタンスが、前記フィルタ（２８）により前記セッションのそれぞれにおいて動的に生成され、前記エージェントＳ_２が前記第２インテリジェントエージェントＴ_２とのセッションを開始し、前記リモートサーバ（４）に接続できるアドレスをこのインテリジェントエージェントに示し、その結果、「ＴＣＰプロキシ」と呼ばれる機能（２７）を形成するよう前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）および前記フィルタ（２８）が協働し、前記リモートサーバ（４）および前記クライアント（１０）の間のデータのやりとりを制御することを特徴とする請求項９に記載の方法。
11. 前記「ＴＣＰプロキシ」機能（２７）の生成が、
    ａ／前記クライアント（１０）と前記インテリジェントエージェントＴ_１との間に接続を開始し、「ＵＲＬ」型の所与の「ＩＰ」アドレスを前記「ＷＥＢ」型ナビゲータ（１０）が送信することにより前記チップカード（２ａ）へのループバック、ならびに前記インテリジェントエージェントＴ_１と前記インテリジェントエージェントＳ_１との間におけるセッションの生成が生じ、前記「ＵＲＬ」型の「ＩＰ」アドレスが、前記リモートサーバ（４）内に含まれるエンティティにつながるパスを識別する別の「ＵＲＬ」型の「ＩＰ」アドレスをカプセル化する段階と、
    ｂ／前記インテリジェントエージェントＴ_１およびＳ_１間で前記セッション中にやりとりされるプロトコルデータユニットからフィルタ（２８）の所与の機能を決定し、前記フィルタ（２８）を生成する段階と、
    ｃ／前記フィルタ（２８）が前記インテリジェントエージェントＳ_２のインスタンスを生成し、前記インテリジェントエージェントＳ_２およびＴ_２間でセッションを開始し、前記カプセル化「ＩＰ」アドレスを運搬するデータを第１プロトコルデータユニットが送信し、前記データは前記遠隔サーバ（４）の名前と関連するポート番号を画定する段階と、
    ｄ／前記インテリジェントエージェントＴ_２が前記インターネット型ネットワーク（ＲＩ）を経由して、前記リモートサーバ（４）との「ＴＣＰ」型接続を開始する段階と、
    ｅ／前記リモートサーバ（４）と前記「ＷＥＢ」型ナビゲータ（１０）との間でやりとりされるデータについて所与の処理を行うように、前記インテリジェントエージェントＴ_１およびＴ_２によって発信されたデータを続いて制御する段階と
    を含むことを特徴とする請求項１０に記載の方法。
12. 前記プロトコルデータユニットが「コマンド」プロトコルデータユニットと呼ばれ、特別な値のフラグにより識別されること、前記コマンドプロトコルデータユニットが、他のインテリジェントエージェントにも前記インターネット型ネットワーク（ＲＩ）にも送信されることなく、前記宛先インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）により直接処理されること、および、前記セッション外でインテリジェントエージェント間でデータのやりとりができるように、前記コマンドプロトコルデータユニットが、第１インテリジェントエージェントに、送信すべきデータ量を示し、第１インテリジェントエージェントから受信することができるデータ量を第２エージェントに示すことを特徴とする請求項１１に記載の方法。
13. 前記データストリームが、所与の第１処理をうけるために前記チップカード（２ａ）により得られるべきクリティカルデータと、前記端末（１）に直接送信すべきオパークデータとを備える複合ストリームであり、前記オパークデータが、前記フィルタ（２８）に作用する前記クリティカルデータの管理の下、前記端末（１）内で所与の第２処理をうけることを特徴とする請求項１２に記載の方法。
14. 前記オパークデータの前記第２処理が、前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）間のセッション外のデータのやりとり時に実施されることを特徴とする請求項１３に記載の方法。
15. 前記「ＷＥＢ」型ナビゲータ（１０）と前記リモートサーバ（４）との間の前記データストリームの送信が非対称通信プロトコルに従って行われること、ならびに、少なくとも
    ａ／前記「ＷＥＢ」型ナビゲータ（１０）と前記インテリジェントエージェントＴ_１との間に接続を開始し、「ＵＲＬ」型の所与の「ＩＰ」アドレスを前記「ＷＥＢ」型ナビゲータ（１０）が送信することにより前記チップカード（２ａ）へのループバック、ならびに前記インテリジェントエージェントＴ_１と前記インテリジェントエージェントＳ_１との間におけるセッションの生成が生じ、前記「ＵＲＬ」型の「ＩＰ」アドレスが、前記リモートサーバ（４）内に含まれるエンティティにつながるパスを識別する別の「ＵＲＬ」型の「ＩＰ」アドレスをカプセル化する段階と、
    ｂ／前記インテリジェントエージェントＴ_１およびＳ_１間で前記セッション中にやりとりされるプロトコルデータユニットからフィルタ（２８）の所与の機能を決定し、前記フィルタ（２８）を生成する段階と、
    ｃ／前記フィルタ（２８）が前記インテリジェントエージェントＳ_２のインスタンスを生成し、前記インテリジェントエージェントＳ_２およびＴ_２間でセッションを開始し、前記カプセル化「ＩＰ」アドレスを運搬するデータであって、前記リモートサーバ（４）の名称および関連するポート番号を示すデータを第１プロトコルデータユニットが送信し、「ｈｔｔｐ」型要求をリモートサーバに送信する段階と、
    ｄ／前記インテリジェントエージェントＳ_２およびＴ_２間で開始される前記セッションを介して前記リモートサーバ（４）と前記フィルタ（２８）との間で個別クリティカルデータをやりとりする段階と、
    ｅ／前記フィルタ（２８）による前記別クリティカルデータの処理のあらかじめ決められた結果に基いて、コマンドのプロトコルデータユニットを前記インテリジェントエージェントＴ_２に送信し、前記エージェントＴ_１によりセッション外に送信されたデータをインテリジェントエージェントが受信することを許可し、前記リモートサーバ（４）と前記「ＷＥＢ」型ナビゲータ（１０）との間で次にやりとりされるデータが前記オパークデータを構成し、前記チップカード（２ａ）を通過することなく前記インテリジェントエージェントＴ_１およびＴ_２により直接中継される段階と、
    ｆ／「ＴＣＰ」接続切命令が検出された時、前記インテリジェントエージェントＴ_１およびＳ_１と前記インテリジェントエージェントＴ_２およびＳ_２との間の前記セッションの閉動作を前記フィルタ（２８）が監視するように、前記インテリジェントエージェントＳ_１またはＳ_２のうちの一方に向けて、前記「ＣＬＯＳＥ」状態のフラグを有する関連プロトコルデータユニットを前記インテリジェントエージェントＴ_１またはＴ_２ の１つが送信する段階
    とを
    を連続して含むことを特徴とする請求項１４に記載の方法。
16. 前記段階／ｄが、前記フィルタ（２８）と前記リモートサーバ（４）との間で行われる認証手順を含むこと、ならびに前記段階／ｅの前記あらかじめ決められた結果が、前記認証手順の良好な進行の確認であることを特徴とする請求項１５に記載の方法。
17. 前記フィルタ（２８）が前記セキュア化プロトコル「ＳＳＬ」の実施のためのフィルタであること、前記第１専用ソフトウェア部（１３）に含まれるＴ_３と呼ばれる「ＳＳＬ」型機能に組み合わされたサーバ型追加第１インテリジェントエージェント（Ｔ_３）が使用されることと、前記第２専用ソフトウェア部（２３ａ）に、Ｓ_３と呼ばれるクライアント型の追加第２インテリジェントエージェント（Ｓ_３）が含まれること、および、前記リモートサーバ（４）に対しネゴシエーションを開始し、暗号化アルゴリズムおよび単方向ハッシング機能とから成る一対のセキュリティデータ、ならびにこれらのセキュリティデータに関連付けられたパラメータを選択し、
    １／暗号化鍵の値と前記ハッシング機能の現在値とで初期化されるセッションを前記エージェントＳ_３およびＴ_３間で開始する段階と、
    ２／前記フィルタ（２８）が、前記インテリジェントエージェントＴ_２に対し、前記インテリジェントエージェントＴ_３によりセッション外で送信されたデータを前記インターネット型ネットワーク（ＲＩ）を経由してリモートサーバ（４）に送ることとインターネット型ネットワーク（ＲＩ）から受信したデータを前記インテリジェントエージェントＴ_３にリダイレクトすることとを可能にする前記コマンドプロトコルデータユニットのうちの１つを前記インテリジェントエージェントＴ_２に送る段階と、
    ３／前記フィルタが、前記インテリジェントエージェントＴ_３に対し、前記インテリジェントエージェントＴ_１およびＴ_２によりセッション外で送信されたデータを受信すること可能にする前記コマンドプロトコルデータユニットを前記インテリジェントエージェントＴ_３に送る段階と、
    ４／前記インテリジェントエージェントＴ_１、Ｔ_３およびＴ_２を通して前記端末（１）内に送信トンネルを確立する段階と、
    ５／インテリジェントエージェントに関連付けられたセッションが前記インテリジェントエージェントＴ_１またはＴ_２のうちの１つにより終了される時、前記フィルタ（２８）が、開状態のままにある他のセッションを終了させる段階と
    を続いて実施するように前記段階ａ／からｄ／を含むことを特徴とする請求項１６に記載の方法。

Images