JP2003522361A

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

Info

Publication number: JP2003522361A
Application number: JP2001557760A
Authority: JP
Inventors: ユリアン，パスカル
Original assignee: ブル・セー・ペー・８
Priority date: 2000-02-10
Filing date: 2001-02-09
Publication date: 2003-07-22
Anticipated expiration: 2021-02-09
Also published as: FR2805062A1; EP1208684A2; JP3845018B2; EP1208684B1; TW509847B; WO2001060040A2; KR100859782B1; CN1172505C; CN1363171A; FR2805062B1; ATE345003T1; DE60124367T2; CA2366568C; AU3564801A; HK1048906A1; CA2366568A1; KR20020005670A; US20020138549A1; WO2001060040A3; DE60124367D1

Abstract

(57)【要約】本発明は、リモートサーバ４とチップカード端末１との間のインターネット型網ＲＩ上での高データレートデータストリーム送信方法に関する。端末およびカードはそれぞれ専用送信プロトコル層１３、２３ａを備える。これらの層は２つのインテリジェントエージェントＴ_２、Ｔ_１、Ｓ_２、Ｓ_１を備え、一方がサーバ、他方がクライアントである。インテリジェントエージェントＴ_２、Ｔ_１、Ｓ_２、Ｓ_１により、双方向データ交換セッションを確立することができる。その際、カードは「ＷＥＢ」クライアント／サーバの機能を有する。フィルタ２８は、カード内に直接インプリメントされる「プロキシ」２７機能を形成するために、インテリジェントエージェントＴ_２、Ｔ_１、Ｓ_２、Ｓ_１と協働する。データストリームは、カードを通過するクリティカルデータと、フィルタ２８の管理の下、端末１を直接通過するオパークデータとを含む。特にマルチメディアデータストリームに適用される。

Description

【発明の詳細な説明】

【０００１】本発明は、サーバとチップカード端末との間のインターネット型ネットワーク
上での高速データストリームに関する。

【０００２】より詳細には、本発明は、セキュア化マルチメディアデータストリームの送信
方法に関する。

【０００３】本発明の枠組においては、「高データレート」という用語は、データレートが
毎秒１００ｋビット程度またはそれ以上であるデータストリームに関する。たと
えば、「ＭＰ３」符号化データの音声ファイルは、このファイルがデジタル回線
を通じてリアルタイムで送信される場合には、１分間すなわちおよそ１００ｋビ
ット／秒の録音について１ＭＢの記憶空間を必要とする。また、リアルタイムで
表示するためにおよそ２Ｍビット／秒程度の送信速度を必要とするビデオデータ
ストリームを挙げることもできる。ましてや、画像、ビデオおよび／または音声
を同時に伝搬することができるいわゆるマルチメディアデータストリームもこれ
に該当する。

【０００４】同じく本発明の枠組においては、「チップカード端末」という用語は一般的な
意味において理解されなければならない。この端末はとくに、ＷＩＮＤＯＷＳま
たはＵＮＩＸ（両者とも登録商標である）など種々のオペレーティングシステム
上で動作するパソコンで構成することができる。端末はまた、ワークステーショ
ンまたはノート型パソコンで構成することもできる。

【０００５】同様に、本発明の枠組においては、「インターネット網」という用語は、本来
の意味でのインターネット網の他、「イントラネット」と呼ばれる種類の企業私
有網または同様な網、「エクストラネット」と呼ばれる種類の外部に伸展する網
、およびより一般的には、インターネット型プロトコルによりデータのやりとり
が行われるあらゆる網も含む。

【０００６】趣旨を明らかにするために、以下の記述においては、別に記載がある場合は別
として、たとえばセキュア化マルチメディアデータストリームの送信など、本発
明の範囲から逸脱することなく、本発明の好ましい応用の場合を想定することに
する。

【０００７】「セキュア化」とは、機密性を確保するか、少なくとも自由にデータにアクセ
スできないようにするために、当該データの全部または一部が暗号化されること
を意味する。後者の目的の場合、有料アクセスデータを指すこともある。いずれ
にせよ、所望するデータ（たとえばマルチメディアファイル）を取得するための
トランザクションが可能な識別データ（パスワード、識別子すなわち「ログイン
」、クレジットカード番号等）を入力することが通常必要である。これらのデー
タはいわゆる「影響を受け易く」、インターネット網上では「平文」で送信する
ことができない。したがってこれらのデータはセキュア化、すなわち暗号化また
はたとえば「ＳＳＬ」（ＳｅｃｕｒｅＳｏｃｋｅｔＬａｙｅｒの略）型のセ
キュア化プロトコルの使用を行わなければならない。

【０００８】インターネット網のめざましい発展にともない、この網を介して種々のサーバ
および／またはクライアントシステムから／またはへ、あらゆる種類のデジタル
ファイルを送信することが可能であることという第１の必要性が生じた。これら
の２つのシステムを接続する伝送路またはこの伝送路の一部分の通過帯域が小さ
い時でも（たとえば、Ｖ９０規格を実施する時、およそ５６ｋビット／秒を限度
とする交換型電話回線が該当する）、この伝送路を介して大きなファイルを送信
することはたしかに可能であるが、大部分の場合、ダウンロードが終了した後に
非リアルタイムでしかこのファイルを使用することができない。高速通信路（ケ
ーブルまたは衛星による接続のサービス統合デジタル網「ＲＮＩＳ」すなわち英
語の用語による「ＩＳＤＮ」）が利用可能であることにより、インターネット網
に接続された端末による音声ファイルさらにはマルチメディアファイルのリアル
タイム送信を考えることが可能である。通常の電話回線ですら、「ＡＤＳＬ」と
いう略号で知られている最近の送信技術を利用する時には、１Ｍビット／秒程度
の速度でデジタルデータを送信することが可能である。

【０００９】ところで、歴史的に見ると、インターネット網に接続されたリモートサーバと
端末との間の伝送路が「ボトルネック」となっていた。したがって鎖の両端の情
報システム、すなわちサーバおよび端末、マルチメディアファイルの送信および
／または処理、および配信に必要なデータレートを受け入れることができること
は明らかである。最近、インターネット網上に高速路が設置されたことにより、
この種の「エンドツーエンド」処理が可能である。

【００１０】顕著になっている別の需要は端末と組み合わせるチップカードの使用である。

【００１１】実際、チップカードを基本とするアプリケーションシステムにおいては、チッ
プカードには、種々の機能、特にセキュリティ機能が割り当てられる。セキュリ
ティに関するデータ（パスワード、アクセス権など）は、ユーザが保存できるチ
ップカード内に格納することが有利である。またデータは、暗号化が可能な形態
で固定メモリ内に記録されることから、容易に変更することができず、外部から
直接読むこともできない。

【００１２】有料トランザクションの枠組においては同様の機能が使われる。上で喚起した
ように、パスワードおよび／または識別子、ならびに種々のセンシブルデータ（
クレジットカードの番号など）、およびユーザの権利（現在有効な購読、アクセ
ス可能なサービスなど）を画定するデータを送信することも必要である。

【００１３】しかしながら、知られている技術においては、受信および／または送信された
データストリームがチップカードを通過しないため、チップカードの内部に「セ
キュリティ機能」を直接実現することはできないことに留意されたい。したがっ
て、セキュリティに関するチェックが行われるようにするためには、端末とチッ
プカードとの間に対話が確立されなければならない。この動作モードはセキュリ
ティレベルを低下させ、さらには、ある悪条件下では、端末内に「トロイの木馬
」を呼び込んでしまうことがある。

【００１４】したがって、セキュリティチェックは、原位置すなわちチップカードそのもの
の中で行われることが必要であり、そのため、データストリームは、端末に送信
される前にチップカードにバイパスされることが必要となろう。

【００１５】チップカードは、自身に割り当てられた「セキュリティ」機能に加え、端末内
で行われるいくつかの動作を直接管理することができるとともに、たとえば、端
末により受信および／または送信されるデータのあらかじめ決められた特性を変
更することができることも有利である。

【００１６】知られている技術においては、以下に示すように、これらの動作モードは、現
在利用可能な技術およびチップカードを基本とするアプリケーションのために選
定された規格には適合しない。

【００１７】まず、図１Ａおよび図１Ｂを参照して、チップカードを基本とするアプリケー
ションシステムの一般的なアーキテクチャを簡単に振り返ることにする。

【００１８】チップカードを基本とするアプリケーションシステムは、主要な要素として、
通常 − チップカード − 前出の端末を構成するホストシステム − 好ましいアプリケーション内のインターネット網などの通信ネットワーク − インターネット網に接続されたアプリケーションサーバを含む。

【００１９】図１Ａは、この種のアーキテクチャの例の略図である。たとえばパソコンであ
る端末１は、チップカード２のリーダ３を含む。このリーダ３は、物理的に端末
１内に組み込むことも組み込まないようにすることも可能である。チップカード
２は、入出力接続部が、電気エネルギの供給および端末１の通信を可能にするよ
うに、その支持部の表面と同じ高さになる集積回路２０を含む。端末は、インタ
ーネット網ＲＩへのアクセス回路１１を備える。この回路は、交換電話回線、あ
るいは本発明の場合には、好ましくは、より高速な通信路すなわちケーブルまた
は衛星による接続のサービス統合デジタル網（「ＲＮＩＳ」）に接続するための
モデムで構成することができる。回路１１により、直接、あるいはインターネッ
トサービス接続業者（英語の用語による「インターネットサービスプロバイダ」
または「ＩＳＰ」）を経由して、インターネット網ＲＩに接続することが可能で
ある。また、「プロキシ」、あるいは「ファイヤウォール」と呼ばれる隔離シス
テム（「防火壁」、さらには「見張番」とも呼ばれる）などの中間システムに頼
ることも可能である。

【００２０】当然のことながら、端末１は、ＣＰＵ、ＲＡＭおよびＲＯＭ、磁気ディスク大
容量メモリ、ディスクおよび／またはＣＤ−ＲＯＭドライブなど、図を簡略化す
る目的から図示しなかったが、その動作に必要な全ての回路および装置を備える
。

【００２１】通常、端末１は、表示スクリーン５ａおよび（本発明の枠組においてはマルチ
メディアファイルの配信が可能な）音声再生システム５ｂ、キーボード６ａおよ
びマウス６ｂなど、内蔵または非内蔵の通常の周辺装置にも接続される。

【００２２】端末１は、網ＲＩに接続されたサーバまたは全ての情報処理システムと通信状
態に入ることができるが、図１Ａには、そのうちの１つのシステムのみを図示し
てある。アクセス回路１１は、「ＷＥＢ」ナビゲータ、あるいは英語の用語では
「ブラウザ」と呼ばれる特殊ソフトウェア１０により、端末１とサーバ４とを通
信状態にする。通常、「クライアント−サーバ」モードにより網ＲＩの全体に分
散した種々のデータアプリケーションまたはファイル、特にマルチメディアファ
イルには、ナビゲータによりアクセスすることができる。

【００２３】通常、ネットワーク上の通信は、複数の重畳ソフトウェア層を備える規格を満
たすプロトコルに従って行われる。インターネット型網ＲＩの場合、以下に詳述
するが、通信は、同じく複数のソフトウェア層を備えるこの種の通信に特有なプ
ロトコルに従って行われる。通信プロトコルは、より個別的に求められるアプリ
ケーション、すなわち「ＷＥＢ」ページの問い合せ、フィアルの転送、電子メー
ル（Ｅ−ｍｅｌ、あるいは英語の用語による「ｅ−ｍａｉｌ」）、フォーラム、
または「ニュース」など、に応じて選択される。

【００２４】図１Ｂに、端末と、チップカードリーダと、チップカードとを備えるシステム
の論理アーキテクチャの略図を示す。このアーキテクチャは規格ＩＳＯにより記
述されおり、同規格そのものも複数の部分集合、すなわち、 − カードの寸法およびマーキングに関するＩＳＯ７８１６−１および７８１
６−２ − 端末とチップカードとの間のデータ転送に関するＩＳＯ７８１６−３ − 命令セットおよびコマンドのフォーマットに関するＩＳＯ７８１６−４図１Ｂの端末１側には、符号１０１の規格ＩＳＯ７８１６−３に準拠する層、
および符号１０２の「ＡＰＤＵ」命令マネージャ（規格ＩＳＯ７８１６−４）の
みを示した。チップカード２側においては、規格ＩＳＯ７８１６−３に準拠する
層には符号２０１を付し、「ＡＰＤＵ」命令マネージャ（規格ＩＳＯ７８１６−
４）には符号２１０を付した。アプリケーションには符号Ａ_１、．．．、Ａ_ｊ、
．．．、Ａ_ｎを付したが、ここでｎはチップカード２上に存在するアプリケーシ
ョンの最大数である。

【００２５】チップカード２（図１Ａ）内に存在する「ｃａｒｄｌｅｔ」アプリケーション
は、命令セットにより端末１と対話する。通常、このセットは書き込み命令と読
み出し命令とを有する。命令のフォーマットは、「ＡＰＤＵ」（「Ａｐｐｌｉｃ
ａｔｉｏｎＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔの意）という英語の略語で
知られている。この書式は前出の規格ＩＳＯ７８１６−４により規定されている
。コマンドの「ＡＰＤＵ」は「ＡＰＤＵ．ｃｏｍｍａｎｄ」と記され、応答の「
ＡＰＤＵ」は「ＡＰＤＵ．ｒｅｓｐｏｎｓｅ」と記される。「ＡＰＤＵ」は、前
出の規格ＩＳＯ７８１６−３により規定されたプロトコル（たとえばキャラクタ
モード：Ｔ＝０、またはブロックモード：Ｔ−１）により、カードリーダとチッ
プカードとの間でやりとりされる。

【００２６】図１Ｂに示すように、チップカード２が異なる複数のアプリケーションを含む
時、マルチアプリケーティブカードと呼ぶ。しかしながら、端末１は一度に１つ
のアプリケーションとしか対話しない。アプリケーションＡ_ｊは、たとえば、「
ＪＡＶＡ」言語（登録商標）による「アプレット」と呼ばれるソフトウェアの形
態を成し、以下、これを「カードレット」と呼ぶ。個別の「カードレット」Ａ_ｊの選択は選択型「ＡＰＤＵ」（「ＳＥＬＥＣＴ」）により得られる。いったんこ
の選択が行われると、これに続く複数の「ＡＰＤＵ」がこの「カードレット」に
向けて送られる。新規の「ＡＰＤＵＳＥＬＥＣＴ」は、現在実行中のアプリケ
ーションを破棄し、別のアプリケーションを選択する作用を有する。「ＡＰＤＵ
」２１０のマネージャソフトウェアサブセットにより、チップカード２内で個別
のアプリケーションＡ_ｊを選択すること、このようにして選択されたアプリケー
ションを記憶すること、およびこのアプリケーションへの「ＡＰＤＵ」の送信お
よび／またはそこからの受信が可能である。

【００２７】上で記述してきたことを要約すると、アプリケーションＡ_ｊの選択およびアプ
リケーションとの対話は「ＡＰＤＵ」命令のやりとりにより行われる。アプリケ
ーションＡ_ｊは従来のアプリケーションであり、以後、「ＧＣＡ」（「Ｇｅｎｅ
ｒｉｃＣａｒｄＡｐｐｌｉｃａｔｉｏｎ」すなわち一般カードアプリケーシ
ョンの意）と呼ぶことにする。

【００２８】以上の点を思い起した上で、スマートカード２は、市販の標準ブラウザのコー
ドを変更しない限り、そうしたブラウザとは直接対話できない点に留意されたい
。

【００２９】さらに、また特に、そもそも上述の標準および規格に合致している現在のスマ
ートカードは、同じくインターネットＲＩと直接通信できないハードウェアおよ
びソフトウェアの構成を有する。とりわけ、それらは、この型のネットワークで
使用されるプロトコルのいずれかに従って、データパケットを受取り、伝達する
ことができない。したがって、一般には、英語で「プラグイン」で呼ばれるもの
の形で、端末内１に設置される追加ソフトウェアを備えることが必要である。図
２Ａでは参照番号１２が付されているこのソフトウェアは、ブラウザ１０とカー
ド２との、より厳密にはこのカード２の電子回路２０との間のインターフェイス
を実施する。

【００３０】諸技術の過去の急速な発展およびその予想される将来の進化を考慮に入れたと
しても、チップカードのＲＡＭまたはＲＯＭ回路への情報記録容量は、この容量
をこのチップカードの「ホスト」端末が提供する容量、および当然のことながら
、「ミニコンピュータ」またはいわゆる「メインフレーム」型の大型システムと
いった、より大型のシステムが提供する容量と比較すると、依然として限界があ
り将来においても限界があることは明らかである。また、大きなデータのファイ
ル、特にマルチメディア型ファイルをチップカード内に保存することは不可能で
ある。したがって、チップカードをインターネット網と通信させること、および
そこにデータを通過させることが可能であること（上で示してきたように、知ら
れている技術では不可能である）を認めながら、「一斉」に、すなわちたとえ一
時的であってもメモリに記憶することなく、全ての処理を行うことが必要であろ
う。知られている技術または短期的に実現可能な技術の現状においては、チップ
カード内に存在する論理回路、特にマイクロプロセッサの計算能力ではこのよう
な動作モードを実現することができない。

【００３１】最後に、前出の規格は、シリアル型リーダを介してチップカードと端末との間
の通信を編成する。その上、現在の技術により可能なデータレートは１〜１０ｋ
ビット／秒程度と非常に低く、そのことは、ここでもまた、本発明のアプリケー
ションの一環として想定するデータレート（最低でも１００ｋビット／秒）に適
合しない。

【００３２】本発明は、顕著になってき需要、すなわち、特に、最大のセキュリティを享受
しつつ高データレートストリームに対応することができるようにするという需要
を満たしつつ、上でそのいくつかについて喚起してきた、知られている技術の方
法および装置の欠点を解消することを目的とする。

【００３３】本発明の第１の特徴によれば、チップカードは、自身に結合されている端末の
ための「ＷＥＢ」型サーバ／クライアントの役割を果たす。

【００３４】これを行うために、端末内のチップカードおよびその垂下部に専用通信ソフト
ウエア層を設ける。「専用」という用語は本発明の方法に対し専用であると理解
されたい。事実、これらの専用通信層は、想定するアプリケーションの如何に関
わらず、両方向性のものである。これら層は、チップカードと端末との間、なら
びにチップカードとネットワークとの間の双方向のデータのやりとりのプロセス
においてのみ動作する。

【００３５】専用通信ソフトウェア層は、特にプロトコルの変換が可能な「インテリジェン
トエージェント」と呼ばれるソフトウェアコンポーネントを特に含む。以後、イ
ンテリジェントエージェントを単に「エージェント」と呼ぶことにする。それぞ
れ端末およびチップカードに結合された専用通信層内に設置されるエージェント
が存在する。本発明の方法によれば、設置されたエージェント間でセッションが
確立される。

【００３６】これらの構成により、リーダを介したチップカードと端末との間の端末のため
の前出のＩＳＯ規格をみたしつつ、チップカードでデータストリームの全部また
は一部をインターネット網からまたはインターネット網側にバイパスすることが
可能になる。

【００３７】本発明の別の特徴によれば、チップカード内に、以後の文書では「フィルタ」
と呼ぶことにする特別アプリケーションをインプリメントする。これには、「プ
ロキシ」の役割と同様の役割を果たすソフトウェアエンティティが関わる。これ
を行うために、エージェントを利用する前出の構成を用いる。この「プロキシ」
により、セキュリティに関するデータの処理を、チップカードの内部で直接実施
することが可能になる。

【００３８】本発明の別の特徴によれば、非対称通信プロトコルをインプリメントする。こ
の特徴によれば、送信中または受信中のデータストリームは２つのコンポーネン
ト、すなわち直接チップカードを通過し、少ないデータ量を示す低データレート
第１ストリーム −以後「クリティカルデータストリーム」と呼ぶ−と、端末を
通過し、多いデータ量を示す高データレート第２ストリーム −以後「オパーク
データストリーム」と呼ぶ−とに分割される。

【００３９】本発明の好ましい適用においては、クリティカルデータストリームは、チップ
カードの前出の「プロキシ」において機密的に処理されるよう、このプロキシに
送ることができるセキュリティデータで構成される。オパークデータは本来の意
味でのマルチメディアデータで構成される。これらのデータは端末内にあるエー
ジェントにより処理される。しかしながら、オパークデータの受信および処理の
許可は、チップカード内のセキュリティデータにより開始される認証手順の結果
に依存する。前出のフィルタが存在するため、端末によるデータの受信はチップ
カードの直接制御下にある。

【００４０】端末を通過するオパークデータは、チップカードの制御および管理の下、実際
の使用の前、すなわちチップカードが受信したクリティカルデータの画定後、端
末内で個別の処理を受けることもできる。

【００４１】これを行うために、チップカードと端末との間、またはこれらの装置の一方の
みの内部に配置された追加特別エージェントを設け、これを「プロトコルの」追
加特別エージェントと呼ぶ。

【００４２】したがって本発明は、少なくとも１つのリモートサーバと、チップカードリー
ダを具備する端末との間における、インターネット型ネットワークを経由するデ
ータストリームの送信方法であって、前記端末が少なくとも１つの「ＴＣＰ／Ｉ
Ｐクライアント」型アプリケーションを含み、前記端末と前記サーバの双方が前
記インターネット型ネットワークに接続され、ａ／前記チップカード内に、専用通信プロトコル層を形成する第１ソフトウェ
アをインプリメントすることから成る第１段階と、ｂ／前記端末内に、専用通信プロトコル層を形成し、少なくとも１つの前記「
ＴＣＰ／ＩＰクライアント」型アプリケーションとのインタフェースを形成する
第２ソフトウェアをインプリメントすることから成る第２段階とを備えること、 − さらに前記第１および第２ソフトウェアがそれぞれ、少なくとも１つのク
ライアント型の第１独立ソフトウェアエンティティと、サーバ型の第２独立ソフ
トウェアエンティティとを備え、前記端末と前記チップカード（との間で双方向
データ交換セッションを確立し、前記チップカードが「ＷＥＢ」型クライアント
／サーバの機能を提供するようにし、かつ前記インターネット型網を経由して、
前記端末と、前記リモートサーバとの間で双方向データ交換セッションを確立す
るよう、端末およびチップカードの情報処理手段により前記エンティティが、協
働し、前記独立ソフトウェアエンティティが、あらかじめ決められたプロトコル
のデータユニットで通信すること、 − 前記第２専用ソフトウェア部内に含まれるクライアントおよびサーバ型の
前記第１および第２独立ソフトウェアエンティティにおよび／またはからプロト
コルデータユニットを受信および／または送信する「フィルタ」と呼ばれる所与
の機能特性の適用ソフトウェアを前記チップカード内に実施する段階を備え、前
記適用部分の実施が前記サーバ型独立ソフトウェアエンティティの制御下にある
こと、 − 前記専用第１ソフトウェアの前記独立ソフトウェアエンティティとのセッ
ションを開始し、前記端末と前記リモートサーバとの間で送信される前記データ
ストリームのあらかじめ決められた特性を変更するために、前記フィルタが、前
記専用第２ソフトウェアの前記独立ソフトウェアエンティティと協働することを特徴とする方法を主な対象とする。

【００４３】次に、添付の地面を参照してより詳細に本発明を記述する。

【００４４】以下の記述においては、別に記載がある場合、すなわち、ＷＥＢサーバも接続
されるインターネットサーバに接続された端末と協働するチップカード上にイン
プリメントされたプロキシによりセキュア化されたマルチメディアデータストリ
ームの場合は別として、本発明の範囲から逸脱することなく、本発明の好ましい
応用の場合を想定することにする。

【００４５】本発明によるチップカード内に位置するアプリケーションの起動手順を記述し
、図２を参照してその実施のためのアーキテクチャについて詳細に説明する前に
、まず、ネットワーク上の通信プロトコルの主な特徴を振り返ってみることが有
益であろう。

【００４６】通信ネットワークのアーキテクチャは種々の層により記述される。たとえば「
ＩＳＯ」が規定する「ＯＳＩ」規格（「ＯｐｅｎＳｙｓｔｅｍＩｎｔｅｒｃ
ｏｎｎｅｃｔｉｏｎ」）は、下位層（物理的な送信媒体に関する「物理層」）か
ら、特に「トランスポート層」をはじめとする中間層を経て、上位層（たとえば
「アプリケーション層」）まで７つの層を含む。ある所与の層は、適当なインタ
フェースを介して、１つ上位の層にサービスを提供し、１つ下位の層に対し他の
サービスを要求する。層はプリミティブを使用して通信する。層は同レベルの層
と通信することもできる。アーキテクチャによっては複数の層が欠けていること
もある。

【００４７】インターネット型環境においては層数は５つ、すなわちより正確には、上位か
ら下位に向かって、アプリケーション層（「ｈｔｔｐ」、「ｆｔｐ」、「ｅ−ｍ
ａｉｌ」など）、トランスポート層（「ＴＣＰ」）、ネットワークアドレシング
層（「ＩＰ」）、データリンク層（「ＰＰＰ」、「Ｓｌｉｐ」など）、および物
理層である。

【００４８】端末１およびスマートカード２ａ内にそれぞれ設置された、参照番号１３およ
び２３ａの特有の通信プロトコルソフトウェア層を例外として他のハードウェア
またはソフトウェアエレメントは、従来の技術に共通するため、ここで再び詳細
に説明する必要はない。

【００４９】端末１は、たとえばモデムで構成されたネットワークＲＩへのアクセス回路１
１を有する。これら回路は、「物理」層と「データリンク」層に対応する、下層
ソフトウェア、Ｃ_１およびＣ_２を包括する。

【００５０】また、「ネットワークアドレシング」層（インターネットの場合には「ＩＰ」
）と「トランスポート」層（「ＴＣＰ」）に対応する、上層、Ｃ_３およびＣ_４が
示されている。アプリケーション上層（「ｈｔｔｐ」、「ｆｔｐ」、「ｅメール
」等）は示されていない。

【００５１】下層、Ｃ_１およびＣ_２と上層、Ｃ_３およびＣ_４との間のインターフェースは、
一般に「下層ドライバ」と呼ばれるソフトウェア層によって構成される。上層、
Ｃ_３およびＣ_４は、このインターフェイス上に支持され、それらに対応する特有
の機能のライブラリまたはネットワークライブラリ１４を介して利用される。イ
ンターネットの場合には、「ＴＣＰ／ＩＰ」は、「ソケット」と呼ばれるライブ
ラリを用い利用される。

【００５２】こうした構造から、ブラウザ１０は、ファイル転送用または電子郵便の送信用
の「ＷＥＢ」ページ（「ＨＴＴＰ」プロトコル）の閲覧のために、サーバ４に向
かって要求を出すことが可能であり、それはまったく従来の方法で行われる。

【００５３】端末１はまた、一体型または非一体型のカード読取装置３を有する。スマート
カード２ａと通信するために、カード読取装置３０はまた、層Ｃ_１およびＣ_２と
類似の役割を果たす、２つの低層、ＣＣ_１（物理層）とＣＣ_２（データリンク層
）を包括する。層ＣＣ_１およびＣＣ_２とのソフトウェアインターフェイスは、た
とえば、仕様「ＰＣ／ＳＣ」（「第６部、サービスプロバイダ」）によって説明
される。層自体、ＣＣ_１およびＣＣ_２は、特に、上述したように、規格ＩＳＯ
７８１６−１から７８１６−４によって説明される。

【００５４】補足的ソフトウェア層１６は、応用層（ここには図示されていない）と下層、
ＣＣ_１およびＣＣ_２との間でインターフェイスを形成する。この層１６に割り当
てられる主要機能は、マルチプレキシング／デマルチプレキシング機能である。

【００５５】スマートカード２ａとの通信は、「ＵＮＩＸ」型オペレーティングシステム、
すなわちＯＵＶＲＩＲ（「ＯＰＥＮ」）、ＬＩＲＥ（「ＲＥＡＤ」）、ＥＣＲＩ
ＲＥ（「ＷＲＩＴＥ」）、ＦＥＲＭＥＲ（「ＣＬＯＳＥ」）等におけるファイル
の操作のために使用されるものと類似のパラダイムに従って行われる。

【００５６】スマートカード２ａ側には、類似の構造、すなわち参照番号ＣＣａ_１（物理層
）およびＣＣａ_２（データリンク層）が付された２つの低層の存在、さらには層
１６とまったく同じインターフェイス層２６ａが見られる。

【００５７】本発明の第１の特徴によれば、両側に、すなわち端末１およびスマートカード
２ａにおいて、特有の２つのプロトコル層、つまり、それぞれ１３および２３ａ
が備えられる。

【００５８】端末１においては、特有の層１３は、マルチプレキシング層１６を介して、「
ドライバ低層」１５、ネットワーク層Ｃ_３およびＣ_４のライブラリ１４、さらに
、カード読取装置３のプロトコル層、すなわち下層ＣＣ_１およびＣＣ_２とインタ
ーフェイスしている。特有の層１３は、スマートカード２ａから、またスマート
カード２ａに向かって、ネットワークパケットの転送を可能にする、さらに、こ
の層は、スマートカード２ａを利用する用途に、インターネットブラウザ１０や
電子郵便等のような既存のアプリケーションを適合させる。

【００５９】スマートカード２ａ側には、層１３と対をなして、参照番号２３ａが付された
特有の層の補足的インスタンスで構成されたまったく同様の構造が見られる。

【００６０】より厳密には、特有の層１３および２３ａは、以下の３つの主要なソフトウェ
アエレメントに細分割される。

【００６１】 −従来の層ＣＣ_１、ＣＣ_２、ＣＣａ_１およびＣＣａ_２を介する、層１３と２３
ａの間の情報ブロックの転送モジュール１３０または２３０ａ、 −たとえば、プロトコルの変換機能を実行する「インテリジェントエージェン
ト」１３２または２３２ａと呼ばれる１つまたは複数のソフトウェア、 −個別のインテリジェントエージェントと同一視することができるモジュール
である、特有の構成の管理モジュール、１３１および２３１ａ。

【００６２】以下、簡略化するために、先述したように、インテリジェントエージェントを
「エージェント」と呼ぶ。

【００６３】したがって、端末１とスマートカード２ａ内に、２つのエンティティ間の通信
プロトコルスタックが見られる。

【００６４】レベル２の層（データリンク層）ＣＣ_２およびＣＣａ_２は、スマートカード２
ａと端末１との間の交換を行う。それらの層は、伝送エラーの検出と、場合によ
っては補正を行う。種々のプロトコルが使用可能であり、以下は限定的ではなく
、あくまで例示的なものである。

【００６５】 −勧告ＥＴＳＩＧＳＭ１１．１１、 −キャラクタモードＴ＝０における、規格ＩＳＯ７８１６−３によって規定
されたプロトコル、 −ブロックモードＴ＝１における、規格ＩＳＯ７８１６−３によって規定さ
れたプロトコル、または −フレームモード「ＨＤＬＣ」（「Ｈｉｇｈ−ＬｅｖｅｌＤａｔａＬｉｎ
ｋＣｏｎｔｒｏｌｐｒｏｃｅｄｕｒｅ」の略）において、規格ＩＳＯ３３
０９によって規定されるプロトコル。

【００６６】本発明の枠組みにおいては、好ましくは、ブロックモードにおけるプロトコル
ＩＳＯ７８１６−３が使用される。

【００６７】それ自体良く知られている方法で、各プロトコル層に対して、同レベルの層間
、さらに層から層へのデータの交換を可能にする一定数のプリミティブが関連付
けられる。例として、レベル２の層に関連付けられるプリミティブは、カードに
よる「データ要求（「Ｄａｔａ．ｒｅｑｕｅｓｔ」）および「データの確認」（
「Ｄａｔａ．ｃｏｎｆｉｒｍ」）等の型である。

【００６８】より特有の方法では、層１３および２３ａは、スマートカード２ａとホスト、
すなわち端末１との間の対話を担当する。それらの層は、たとえば、「ＨＴＭＬ
」フォーマットにおけるハイパーテキストの形で実行されるメニュを介して、端
末１のユーザ（図示せず）とスマートカード２ａとの間の情報交換を可能にする
。それらはまた、データパケットの送信および／または受信のために適合した構
成の設置を可能にする。

【００６９】上述したように、層は３つの別々のエンティティを有する。

【００７０】第一の層１３０または２３０ａは、主に、ソフトウェアマルチプレクサで構成
される。それは、プロトコルのデータユニットの形で、スマートカード２ａとホ
スト端末１との間の情報交換を可能にする。第一の層は、データパケットの交換
器と類似の役割を果たす。それらのユニットは、レベル２の層（データリンク層
）を介して送信または受信される。この通信用の個別プロトコルは、少なくとも
一対のエージェントの連絡を確立させることができる。各対の第１のエージェン
ト１３２は、端末１側の層１３内に位置し、第２のエージェント２３２ａは、ス
マートカード２ａ側の層２３ａ内に位置する。２つの「エージェント」間のリン
クは、「Ｓ−エージェント」と呼ぶことができるセッションに関連付けられる。
セッションは、これら２つのエージェント間の双方向データ交換である。層１３
および２３ａのいずれか一方が、複数のエージェントを有する場合には、同一層
のエージェントはまた、互いの間で、および／または、個別のエージェントを構
成するモジュール１３１および２３１ａとのセッションを確立することができる
。

【００７１】より厳密には、エージェントは、端末１によって実施される構成に応じて、レ
ベル３および４の層の機能の全体または一部を実行することができる独立ソフト
ウェアエンティティである。

【００７２】エージェントは、個別の特性または属性に関連付けられる。分かりやすくする
ために、限定的でなく例示的なものとして、以下の６つの特性がエージェントに
関連付けられる。

【００７３】 −「ホスト」：端末内で探索されるエージェント −「カード」：スマートカード内で探索されるエージェント −「ローカル」：ネットワークと通信しないエージェント −「ネットワーク」：ネットワークと通信するエージェント（端末側） −「クライアント」：セッションを初期化するエージェント −「サーバ」：セッションの要求を受取るエージェント個別のエージェントは、リファレンス、たとえば１６ビットの整数によって識
別される（すなわち、０から６５５３５の間）。上位ビット（ｂ１５＝１）は、
リファレンスがローカルであるか（スマートカードまたは端末へのローカル通信
）、または、遠隔であるか（ｂ１５＝０）を示す。

【００７４】エージェントには２つの大きなカテゴリが存在する。固定リファレンスによっ
て識別される「サーバ」型のエージェントと、構成管理モジュールによって付与
される一時的と形容されることもある可変リファレンスによって識別される「ク
ライアント」型のエージェント、１３１または２３１ａである。

【００７５】エージェントは、宛先リファレンスとソースリファレンスとを構成する「プロ
トコルデータユニット」または「ｐｄｕ」（英語「ｐｒｏｔｏｃｏｌｄａｔａ
ｕｎｉ」の略）と呼ばれるエンティティを用いて互いに通信する。さらに、こ
の「ｐｄｕ」を、一般に使用されている英語「ＳｍａｒｔＣａｒｄ」を参考に
して、「ＳｍａｒｔＴＰｐｄｕ」と呼ぶこともできる。「ｐｄｕ」は、特に、
以上に規定したリファレンスを使用する。

【００７６】「ＳｍａｒｔＴＰｐｄｕ」または、以下、より簡単に「ｐｄｕ」は、「ｐｄ
ｕ」の性質を明示する以下のようなフラグおよびオプションのデータを構成する
、ソースリファレンス、宛先リファレンス、ビット集合を有する。

【００７７】 −「ＯＰＥＮ」（開始）フラグは、セッション開始を示すために位置決めされ
る。

【００７８】 −「ＣＬＯＳＥ」（閉鎖）フラグは、セッションの閉鎖を示す。

【００７９】 −「ＢＬＯＣＫ」（鎖錠）フラグは、エージェントが、その通信相手の応答を
待っている状態であり、あらゆる活動を一時停止することを示す。

【００８０】データをもたない「ｐｄｕ」はトークンと呼ばれる。

【００８１】「ＳｍａｒｔＴＰ」エンティティは、宛先エージェントの存在をコントロール
し、そのエージェントに向かってパケットの通信を実行する。

【００８２】セッションエージェント「Ｓ−Ａｇｅｎｔ」は、３つの注目すべき状態を有す
る。すなわち、 −接続解除されている状態。いかなるセッションも他のエージェントには開始
されていない。

【００８３】 −接続されている状態。セッションが他のエージェントに開始されている。「
Ｓ−Ａｇｅｎｔ」セッションは、一対のリファレンスによって識別される。

【００８４】 −ブロックされている状態。エージェントが接続され、その通信相手の応答を
待つ状態。

【００８５】「Ｓ−エージェント」セッションの確立メカニズムは、以下の通りである。

【００８６】 −クライアントエージェントの新しいインスタンスが創設され（スマートカー
ドまたは端末側）、このエージェントは、擬似単一一時リファレンスによって識
別される。

【００８７】 −クライアントエージェントは、位置決めされた「ＯＰＥＮ」フラグとともに
サーバエージェント（そもそも、そのリファレンスはすでに知られている）宛て
に「ｐｄｕ」を送信し、クライアントエージェントは、「ブロック」フラグの値
に従って接続またはブロックされる状態に移行する。さらに −サーバエージェントは、「ＯＰＥＮ」フラグとともに「ｐｄｕ」を受け取り
、接続された状態に移行する。

【００８８】いったんセッションが開始されると、２人のエージェントが「ｐｄｕ」を介し
てデータを交換する。

【００８９】セッションの閉鎖メカニズムは以下の通りである。

【００９０】 −エージェントは、場合によってはデータを有する、位置決めされたフラグ「
ＣＬＯＳＥ」とともに「ｐｄｕ」を送信する。

【００９１】 −他のエージェントは、（場合によってはデータを有する）位置決めされたフ
ラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を受取り、「Ｓ−Ａｇｅｎｔ」セッショ
ンは、接続解除された状態に移行する。

【００９２】図３は、上述したような「Ｓ−Ａｇｅｎｔ」セッションの状態のフローチャー
トを概略的に表わしている。

【００９３】層１３０および２３０ａは、ホスト端末１およびスマートカード２ａ側で、存
在するエージェントリストを含む表（図示せず）を管理する。

【００９４】実際に、エージェントは、（たとえば、ハイパーテキストの）データの交換を
可能にするが、しかも、ネットワークトランザクションを開始することができる
。

【００９５】構成管理モジュール、それぞれ１３１および２３１ａは、個別のエージェント
と同一視することができる。たとえば、ホスト端末１側のモジュール１３１は、
特に、この端末の構成（作動モード）に関連する情報、たとえば他のエージェン
トリスト等を管理する。スマートカード２ａ側のモジュール２３１ａは、類似機
能を有する。これら２つのエージェントは、セッションを確立するために互いに
通信を確立することができる。

【００９６】本発明の第１の特徴によれば、チップカード２ａは「ＷＥＢ」クライアント／
サーバとして働く。

【００９７】実際には、チップカード２ａは、有利には、外部端末へのポインティングでは
なく端末１自身へのループバックを画定する「ＵＲＬ」（「Ｕｎｉｖｅｒｓａｌ
ＲｅｓｏｕｒｃｅＬｏｃａｔｅｒ」の意味）の使用により「アドレス」され
る。たとえばこの「ＵＲＬ」の構造は以下のようになっている。

【００９８】ｈｔｔｐ：／／１２７．０．０．１：８０８０（１）ここで１２７．０．０．１はループバックの「ＩＰ」アドレスであり、８０８
０はポート番号である。

【００９９】図４は、図２に示す種類の本発明によるシステムのソフトウェアアーキテクチ
ャの略図であるがより詳細に示した図である。チップカード２ａは複数のエージ
ェントを備えるが、そのうちの２つのみ、すなわち「ＷＥＢ」型エージェント２
３２ａ１、および非詳細画定型エージェント２３２ａ２を示した。ソフトウェア
スタックは、規格ＩＳＯ７８１６−３（図２：ＣＣａ１およびＣＣａ２）に対
応する下位プロトコル層、符号２００ａと、「ＡＰＤＵ」コマンドドライバ２０
１ａ１と、パケットマルチプレクサ２３０ａとを備え、このマルチプレクサは、
エージェント、特に「ＷＥＢ」エージェント２３２ａ１にインタフェースされる
。

【０１００】端末１側には、２つのスタックが存在するが、一方はインターネットＲＩと通
信し、他方はスマートカード２ａと通信する。第１のスタックは、ネットワーク
（規格ＯＳＩ１および２）へのアクセス機構１１（図２：Ｃ_１およびＣ_２）と
、参照番号１００が付されたプロトコル「ＴＣＰ／ＩＰ」（図３：Ｃ_３およびＣ _４）層とを有する。それらの層は「ＷＥＢ」ブラウザ１０とインターフェイスさ
れる。他方のスタックは、規格ＩＳＯ７８１６−３に合致した参照番号１０１
が付された下層プロトコル（図３：Ｃ_１およびＣ_２）と、命令管理「ＡＰＤＵ」
１０２と、パケットマルチプレクサ１３０とを有し、このマルチプレクサはエー
ジェントとインターフェイスされるが、そうちの１つだけ、１３２がここに図示
されている。このエージェントは「ネットワーク型」と想定され、さらに、一方
では「ＴＣＰ／ＩＰ」層１０１を介して、ブラウザ１０と、他方では、それら「
ＴＣＰ／ＩＰ」層１０１とネットワークＲＩへのアクセス機構１１とを介してイ
ンターネットＲＩと通信することができる。

【０１０１】命令管理「ＡＰＤＵ」２０１ａはまた、単にアプリケーションと呼ばれるアプ
リケーションレベルの１つまたは複数の層とインターフェイスされる。それらア
プリケーションＡ_１…、Ａ_ｉ…、Ａ_ｎ…、は、すでに示したように、「カードレ
ット」と呼ぶ従来型のアプリケーションである。

【０１０２】要約すると、スマートカード２ａによって与えられる「ＷＥＢ」サーバ／クラ
イアント機能は、すでに説明したように、スマートカード内の「ＷＥＢ」エージ
ェント２３２ａ_１と、端末１内のネットワークエージェント１３２との関連付け
によって、また、エージェント間のセッションによって実行することができる。

【０１０３】したがって、スマートカード２ａは「ＷＥＢ」クライアント／サーバ機能を明
確に表している。さらに、本発明の方法の一特徴によると、上記の「ＣＧＡ」型
の従来のどんなアプリケーションＡ_１からＡ_ｎも、この「ＷＥＢ」クライアント
／サーバを通して、端末１内に存在する「ＷＥＢ」ブラウザ１０によって、もし
くは、エージェント間のセッションの実施によって、インターネットＲＩの何ら
かのポイントで探索された遠隔ブラウザ４によって、起動することができる。本
発明の方法によれば、アプリケーションＡ_１からＡ_ｎは、書き直す必要なく、そ
のまま利用することができる。

【０１０４】上で記述したエージェント機構を実施する本発明の別の態様によれば、チップ
カード２ａ上に「ＴＣＰ／ＩＰプロキシ」と呼ばれる機能を直接インプリメント
する。この機能は、以下「フィルタ」と呼ぶことにする特別なソフトウェアアプ
リケーションで実施される。

【０１０５】「プロキシ」機能はインターネットアプリケーションの分野においてはよく知
られているが、知られている技術によるシステムのチップカード内にはインプリ
メントすることができない。

【０１０６】本発明によるアーキテクチャを記述する前に、図５を参照して、知られている
技術による従来の「プロキシ」の特徴を今一度簡潔に述べる。

【０１０７】「ＴＣＰ／ＩＰ」技術においては、「ＴＣＰ／ＩＰ」サーバＳｖと「ＴＣＰ／
ＩＰ」クライアントＣｌとを実現するソフトウェアエンティティＰｙを「プロキ
シ」と呼ぶ。ソフトウェアエンティティＰｙは、ローカルクライアントと別のリ
モートＴＣＰ／ＩＰサーバとの間に接続を実現する。

【０１０８】通常、プロキシＰｙはフィルタおよび／またはセキュリティの機能を実現する
。たとえば「ｈｔｔｐ」プロキシは通常、企業内において、あるナビゲータ、た
とえば端末１のナビゲータ１０から「ＷＥＢ」サーバ４への接続を確保する（こ
れは「ファイアウォール」すなわち「防火壁」という名称で知られている）。ま
た、「ＳＳＬ」と呼ばれるプロキシのことを指すこともある。これは、端末に対
しローカルであって、インターネット網ＲＩを通してセキュアードトンネルを確
立するのに必要なセキュリティ操作（認証−機密−完全性）を実施する「プロキ
シ」であると定義することができる。

【０１０９】次に、図６を参照して、本発明の追加的態様により「プロキシ」機能をチップ
カード内に直接内蔵するソフトウェアアーキテクチャを記述する。

【０１１０】前の図と共通な要素には同じ符号が付与されており、これらは必要な場合にの
み再度記述する。記述を簡単にするために、端末１側のエージェントをただ１つ
の符号１３２でまとめ、チップカード２ａ側をただ１つの符号２３２ａでまとめ
た。以下の記述では、「端末」については文字「Ｔ」で、「スマートカード（チ
ップカード）」については「Ｓ」でこれら符号が区別される。文字は指数として
数字に組み合わされる。チップカード２ａ上に実現される「プロキシ」２７は、
以下の記述においては「スマートプロキシ」と呼ぶことにする。

【０１１１】「スマートプロキシ」２７は、以下に記述するように、端末１側の２つ：Ｔ_１およびＴ_２、チップカード２ａ側の２つ：Ｓ_１およびＳ_２の４つのエージェント
と、フィルタ機能２８との組み合せにより実現される。すなわち、 − 「端末／クライアント／ネットワーク」エージェントＴ_１は、（たとえば
ポート８０８０上で）ＴＣＰ／ＩＰサーバを実現する。

【０１１２】 − 「カード／サーバ／ローカル」エージェントＳ_１はセッションによりエー
ジェントＴ_１に組み合わされ、通常、後者は「ＷＥＢ」サーバの機能を実現する
。

【０１１３】 − エージェントＴ_１からの情報に応じて決定されるフィルタ機能２８は、エ
ージェントＳ_１およびＳ_２に対し「ｐｄｕ」の送受信を行うことができる。

【０１１４】 − 「ネットワーク」エージェントＴ_２とのセッションをオープンするフィル
タ機能２８およびＳ_２により、「カード／サーバ／ローカル」エージェントＳ_２のインスタンスが動的に生成され、Ｓ_２が接続されたいと所望するインターネッ
トリモートサーバ４のアドレスがネットワークサーバに示される。

【０１１５】 − 「端末／クライアント／ネットワーク」エージェントＴ_２は、インターネ
ットサーバ４に接続されている「ＴＣＰ／ＩＰ」クライアントの機能を実現する
。

【０１１６】以下に、「スマートプロキシ」２７の生成機構を記述する。

【０１１７】以後「ｃＴＣＰ」と呼ぶことにし、通常、「ＷＥＢ」ナビゲータ１０である「
ＴＣＰ」クライアントは、「ネットワーク」エージェントＴ_１との接続を開く。
次にセッションＴ_１−Ｓ_１が生成される。たとえば下記ＵＲＬはｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｘｘｘ．ｃｏｍ
：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（２）エージェントＴ_１およびＳ_１間でセッションの開始を生じさせる。

【０１１８】エージェントＳ_１（ＷＥＢサーバ）に結合されたアプリケーションは、Ｔ_１お
よびＳ_１でやりとりされるデータから、どのフィルタ機能２８を使用すべきかを
決定する。したがって「ｄｅｓ１」はある個別のフィルタの名称であり、「ｘｘ
ｘ．ｃｏｍ」は、あるインターネットサーバ、たとえばサーバ４の任意の名称で
あり、「８０」はポート番号であり、「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」は
、例においては「ＨＴＭＬ」言語によるページで構成される、このサーバ上の１
つのファイルの任意の名称である。例においては、「ｄｅｓ１」フィルタは、「
ＤＥＳ」（「ＤａｔａＥｎｃｒｙｐｔｉｏｎＳｔａｎａｒｄ」）型アルゴリ
ズムによる解読および／または暗号化作業を行うことができるフィルタである。

【０１１９】言い換えれば、「カード」ＵＲＬ（２）は、外部に向けた別のＵＲＬをカプセ
ル化し、このＵＲＬは、関係式（１）により定義されるようなループバックＵＲ
Ｌにより構成される。

【０１２０】「ｄｅｓ１」フィルタ２８はクライアントＳ_２のインスタンスを作成し、エー
ジェントＳ_２とＴ_２との間でセッションが開始する。最初の「ｐｄｕ」（「ＯＰ
ＥＮｐｄｕ」）に挿入されるデータはインターネットサーバの名称（「ｘｘｘ．
ｃｏｍ」）および結合されたポート番号（８０）を指定する。

【０１２１】エージェントＴ_２は、リモートサーバ「ｓＴＣＰ」（「ｚｚｚ．ｃｏｍ」）に
対し、「ＴＣＰ」型の接続を開始する。この接続が確立するとＳ_２に向けてトー
クンが送信される。

【０１２２】これらのやりとりが終了すると、「スマートプロキシ」２７が生成されていて
、チップカード２ａ内に常駐するフィルタ機能２８は、「ネットワーク」エージ
ェントが受信した（インターネット網ＲＩからの）データを処理することができ
る。フィルタ２８は、「ネットワーク」エージェントＴ_１およびＴ_２により送信
されたデータを論理的にチェックする。フィルタは、クライアント「ｃＴＣＰ」
とサーバ「ｓＴＣＰ」との間でかわされるデータをチェックする「ＴＣＰプロキ
シ」として振舞う。

【０１２３】趣旨を明らかにするために、種々のエージェントの任意の符号を図６に示した
。すなわち、Ｔ_２およびＳ_１の「サーバ」型エージェントについての固定エージ
ェントは「２」から「５」であり、Ｔ_１およびＳ_２の「クライアント」型エージ
ェントについての可変または一時的エージェントは「１５３６０」および「２５
５９」である。

【０１２４】次に、フィルタ２８の個別例をより詳細に記述する。

【０１２５】例１：リダイレクトフィルタリダイレクトフィルタは、たとえば以下のＵＲＬなどのカードＵＲＬに（ｈｔｔｐ／／１２７．０．０．１：８０８０／ｅＭａｉｌ）（３）識別データ、すなわち無料メールサーバ「ｅｍａｉｌ」に関連付けられたたと
えば「ｌｏｇｉｎ」およびパスワードを、よく知られている「ＰＯＳＴｈｔｔ
ｐ」という方法を使用することにより投稿するのに使用することができる外部サ
ーバ（たとえばｗｗｗ．ｅｍａｉｌ．ｃｏｍ）への「ｈｔｔｐ」要求を関連付け
る。フィルタは、チャレンジを基本とするより確実な方法（これらの方法はたと
えば規格「ｈｔｔｐ１．１」において記述されている）。

【０１２６】フィルタの実施は通常、以下の段階を含む。

【０１２７】１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１
２７．０．０．１：８０８０）との接続を開始し、カード２ａの「ＷＥＢ」サー
バとのセッションＴ_１−Ｓ_１が開始する２．（勧告「ｈｔｔｐ１．１ｒｆｃ２０６８」による）「ｈｔｔｐ」要求が、
ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に送信され、このエージェント
が、「／ｅＭａｉｌ」ファイルの名称から、この特別な場合におけるリダイレク
トフィルタ２８への呼び出しを検出し、その瞬間から、「ネットワーク」エージ
ェントＴ_１が受信した全データがこの特別フィルタ２８により処理される３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成
される４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信
された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「
ＷＥＢ」サーバ４のアドレスおよびポート（例においては「ｗｗｗ．ｅｍａｉｌ
．ｃｏｍ」）を含む５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始
後、トークンがエージェントＳ_２に送信される６．エージェントＳ_２が「ｈｔｔｐ」要求をリモート「ＷＥＢ」サーバ４に送
信する７．通常、このサーバ４が、操作の成功を通知し、ナビゲータに新規接続「Ｕ
ＲＬ」と、使用すべきソフトウェア部「クッキー」とをナビゲータ１０に供給す
る「ｈｔｔｐ」リダイレクトヘッダを送信する８．これらのデータに関してフィルタ機能２８が何も処理を行わない９．セッションＳ_１−Ｔ_１によりデータが「ＷＥＢ」ナビゲータ１０に送信さ
れるナビゲータ１０は、リダイレクトヘッダを受信すると、適当な「クッキー」に
よりメールサーバ４に接続する。通常、ナビゲータは「ＨＴＭＬ」言語で書かれ
たホームページを折り返し受信する。

【０１２８】例２：「ｈｔｔｐ−ｄｅｓ」フィルタ次に、前出の「ＤＥＳ」型アルゴリズムにより符号化される「ＨＴＭＬ」ペー
ジの場合を想定する。たとえば「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」という名
称のこのページは、「ＷＥＢ」サーバ４、すなわち「ｚｚｚ．ｃｏｍ：８０」に
格納される。（任意の名称「？ｄｅｓ１」のカード内にあるフィルタ機能２８は
、解読アルゴリズムすなわち逆の機能（あるいは「ＤＥＳ^−１」）を実施するが
、これには、索引１に関連付けられた鍵を使用する。

【０１２９】ナビゲータ１０から実行される以下のＵＲＬｈｔｔｐ：／／ｚｚｚ．ｃｏｍ／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（４）
は、「ｚｚｚ．ｃｏｍ」サーバからの「ｃｏｎｔｅｎｔ．ｈｔｍｌ」ファイルの
ロードを発生させる。「ＨＴＭＬ」ページが符号化されると、「ＨＴＭＬ」言語
の取り決めに従い文書の始まりおよび終りを示すタグ「ｈｔｍｌ＞および＜／ｈ
ｔｍｌ」は平文には現れず、ナビゲータ１０は、意味のない記号か、「ＨＴＭＬ
」ページが受信されなかったことを示すエラーを表示する。

【０１３０】以下のＵＲＬｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｚｚｚ．ｃｏｍ
：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（５）は、鍵のインデックスが１である「ＤＥＳ」型のフィルタ２８を通して以下のペ
ージをロードするようカードに指示する。

【０１３１】ｈｔｔｐ：／／ｚｚｚ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（６）「ｃｏｎｔｅｎｔ．ｈｔｍｌ」ページのロードは以下の様に行われる。

【０１３２】１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１
２７．０．０．１：８０８０）との接続を開始し、チップカード２ａの「ＷＥＢ
」サーバとのセッションＴ_１−Ｓ_１が開始する２．（「ｈｔｔｐ１．１ｒｆｃ２０６８」）「ｈｔｔｐ」要求が、ナビゲータ
１０から「ＷＥＢ」エージェントＳ_１に送信され、この「ＷＥＢ」エージェント
Ｓ_１が、「／？ｄｅｓ１＝ｚｚｚ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈ
ｔｍｌ」ファイルの名称から、（索引鍵１）「ＤＥＳ」型フィルタ２８への呼び
出しを検出し、その瞬間から、「ネットワーク」エージェントＴ_１が受信した全
データが、索引鍵１に関連付けられた「ＤＥＳ」型フィルタ２８により処理され
る３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成
される４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信
された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「
ＷＥＢ」サーバ４のアドレスおよびポート（「ｚｚｚ．ｃｏｍ）を含む５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始
後、トークンがエージェントＳ_２に送信される６．エージェントＳ_２が「ｈｔｔｐ」要求をリモート「ＷＥＢ」サーバ４に送
信する７．リモートサーバ４が、ファイルの性質を示す「ｈｔｔｐ」ヘッダを送信し
、本来の意味でのファイルを送信する：これらのデータはセッションＴ_２−Ｓ_２によりフィルタ機能２８に中継される８．「ｈｔｔｐ」ヘッダに関してフィルタ機能２８が何も処理を行わず、「Ｈ
ＴＭＬ」ページを解読する９．解読されたデータが、セッションＳ_１−Ｔ_１により「ＷＥＢ」ナビゲータ
１０に送信されるこの操作の結果として、ナビゲータ１０は復号された「ＨＴＭＬ」ページを受
信する。リダイレクト操作はスクリプト（通常は、登録商標である「Ｊａｖａ
Ｓｃｒｉｐｔ」言語による）により自動化することができる。たとえば（仮に「
ｃｏｎｔｅｎｔ．ｈｔｍｌ」）と呼ぶことにする）「ＨＴＭＬ」ページ内に含ま
れるスクリプトは、以下のＵＲＬｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｚｚｚ．ｃｏｍ
／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（８）をｈｔｔｐ：／／ｚｚｚ．ｃｏｍ／ｙｙｙ／ｘｃｏｎｔｅｎｔ．ｈｔｍｌ
（７）にリダイレクトする。

【０１３３】ここでｘｃｏｎｔｅｎｔ．ｈｔｍｌおよびｃｏｎｔｅｎｔ．ｈｔｍｌは２つの
「ＨＴＭＬ」の任意の名称である。

【０１３４】例３：「ＳＳＬ」フィルタ「ＳｅｃｕｒｅＳｏｃｋｅｔＬａｙｅｒ」すなわち「ＳＳＬ」と呼ばれる
プロトコルは、「ＷＥＢ」型アプリケーション用として広く使われている。この
プロトコルにより、クライアント（通常はナビゲータ１０）とサーバとの間に「
セキュアトンネル」を開通させることが可能である。「ＳＳＬ」により、サーバ
を認証するとともに、やりとりされるデータの機密性および完全性を確保するこ
とができる。これを行うために、サーバに固有の公開鍵から共有機密が作成され
る。共有機密からセッション鍵が推定され、この鍵により、「トリプルＤＥＳ」
型のアルゴリズムを使用して情報の解読が行われる。おのずとわかるように、認
証「証明」を使用する技術も使用することができる。

【０１３５】「ＳＳＬ」フィルタをチップカード２ａ内に直接作製する利点は、サーバの公
開鍵の証明書の確認（これが公開鍵システムの重要部分を成す）が、先験的に安
全性が低いと判断される、端末内に常駐するソフトウェアではなく、チップカー
ドにより行われることである。従来は、いったん「ＳＳＬ」セッションが開かれ
ると、ユーザすなわち「インターノート」（図示せず）は、キーボード（図１Ａ
、６ａ）を使用して、端末１上で平叙文で入力される「ｌｏｇｉｎ」とパスワー
ドとの組み合せである個人識別データを入力する。チップカード２ａから実施さ
れる「ＳＳＬ」セッションの別の長所は、「ｌｏｇｉｎ」およびパスワードがユ
ーザによってではなく、チップカード２ａによって提供されることである。

【０１３６】「ＳＳＬ」接続は以下のようにして行われる。

【０１３７】次に、「ＳＳＬ」セッションにより取得を所望する「ＨＴＭＬ」ページを想定
する。たとえば「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」という名称のこのページ
は、（任意の名称「ｗｗｗ．ｂａｎｋ．ｃｏｍ」）のリモート「ＷＥＢ」サーバ
４に格納される。（任意に「？ｓｓ１」と呼ばれる）カード内にある特別フィル
タ機能２８は、ＳＳＬプロトコルを実施し、ｌｏｇｉｎ、および索引１に関連付
けられたパスワードを使用する。

【０１３８】以下のＵＲＬｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｓｓｌ１＝ｗｗｗ．ｂａｎ
ｋ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（９）は、「ＳＳＬ」プロトコルを使用して「ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」の
ページをロードするようチップカード２ａに指示する。

【０１３９】「ｃｏｎｔｅｎｔ．ｈｔｍｌ」ページのロードは以下の様に行われる。

【０１４０】１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１
２７．０．０．１：８０８０）との接続を開始し、チップカード２ａのＷＥＢサ
ーバとのセッションＴ_１−Ｓ_１が開始する２．（「ｈｔｔｐ１．１ｒｆｃ２０６８」に適合した）「ｈｔｔｐ」要求が、
ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に送信され、「ＷＥＢ」エージ
ェントＳ_１が、「／？ｓｓ１＝ｗｗｗ．ｂａｎｋ．ｃｏｍ：８０／ｙｙｙ／ｃｏ
ｎｔｅｎｔ．ｈｔｍｌ」ファイルの名称から、（索引鍵１を有する）「ＳＳＬ」
型フィルタ２８への呼び出しを検出し、その瞬間から、「ネットワーク」エージ
ェントＴ_１が受信した全データが、索引鍵１に関連付けられた「ＳＳＬ」型フィ
ルタ２８により処理される３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成
される４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信
された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「
ＳＳＬＷＥＢ」サーバ（「ｗｗｗ．ｂａｎｋ．ｃｏｍ：４４３」）のアドレス
およびポート（この例においてはＮｏ４４３）を含む５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始
後、トークンがエージェントＳ_２に送信される６．フィルタ２８がセッションＴ_２−Ｓ_２を使用して、リモートサーバ４との
間で「ＳＳＬ」プロトコルに準拠したネゴシエーションを開始する７．「ＳＳＬ」セッションが開始すると、フィルタ２８により「ｌｏｇｉｎ」
およびパスワードがリモートサーバ４に送信され、セッションＴ_２−Ｓ_２が閉じ
られる８．フィルタ２８により新しいセッションＳ_２−Ｔ_２が開始される９．フィルタ２８が、前回の「ＳＳＬ」セッションの再開をネゴシエートする１０．エージェントＳ_２がファイル取得暗号化「ｈｔｔｐ」要求をリモートサ
ーバ４に送信する１１．リモートサーバ４が、ファイルの性質を示す「ｈｔｔｐ」ヘッダを送信
し、本来の意味でのファイルを送信する：これらのデータはセッションＳ_２−Ｔ _２によりフィルタ機能２８に中継される１２．フィルタ機能２８が受信データを復号しその完全性を確認する１３．解読されたデータが、セッションＳ_１−Ｔ_１により「ＷＥＢ」ナビゲー
タ１０に送信されるこの操作の結果として、ナビゲータ１０は復号された「ＨＴＭＬ」ページを受
信する。リダイレクト操作はスクリプト（通常は、登録商標である「Ｊａｖａ
Ｓｃｒｉｐｔ」言語による）により自動化することができる。たとえば「ＨＴＭ
Ｌ」ページ内に含まれるスクリプトは、以下のＵＲＬｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｓｓｌ１＝ｗｗｗ．ｂａｎ
ｋ．ｃｏｍ／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ（１０）をｈｔｔｐ：／／ｗｗｗ．ｂａｎｋ．ｃｏｍ／−ｙｙｙ／ｘｃｏｎｔｅｎｔ．ｈ
ｔｍｌ（１１）にリダイレクトする。

【０１４１】次に、非対称通信プロトコルにより特にマルチメディアデータストリームを処
理することができる本発明の追加的態様を記述する。

【０１４２】端末１がたとえばインターネット網ＲＩからマルチメディアデータを取得する
と、これらのデータは一切の機密的特性を失い、一般的に安全性が低いシステム
により記憶される。

【０１４３】本発明の特徴のうちの１つにより実現される「スマートプロキシ」は、個別サ
ービスの享受者の識別および認証のための鍵装置を構成する。アルゴリズムおよ
び鍵はチップカード２ａの内部に保存され実行される。個別フィルタ２８がリモ
ートサーバ４との間で「ＴＣＰ」接続をいったん開始すると、２つの場合を想定
することができる。すなわちＡ／データの完全性および機密性を確保するために固定鍵および秘密鍵が使用
される。すなわちこの場合、「スマートプロキシ」のフィルタにより、データス
トリームが解読され確認されるＢ／フィルタ２８とリモートサーバ４との間で接続の開始が成功すると、「セ
ッション鍵」とも呼ばれる一時鍵が計算される。すなわちたとえば前出の「ＳＳ
Ｌ」プロトコルまたは「ＩＰＳＥＣ」プロトコルのようなインターネット網のた
めに使用される多くのセキュリティプロトコルにおいては、第２のケースが発生
する。

【０１４４】一時セッション鍵が使用される時には、いずれにしろこれらの鍵は一回しか使
われずかつ鍵の唯一の目的は安全性の低い端末へデータの平文転送を可能にする
ことであるため、チップカード２ａによるアルゴリズムの計算には特別な意味は
ない。

【０１４５】セキュリティの観点から見た場合、サーバ４との接続が非対称であることもあ
る。識別手順および認証手順は秘密であるが、次にやりとりされるデータは何ら
機密性を有していない。そのような経緯から、データストリームという概念が生
まれることになり、以後、「スマートプロキシ」により機密的に処理すべきデー
タを表す「クリティカルストリーム」を「クリティカル」と呼ぶことにする。（
時には同一の接続中に変化することがある）一時セッション鍵はクリティカルス
トリームから推定することができ、端末１は、特別な安全措置を講ずることなく
この鍵を使用することができる。

【０１４６】したがってこれ以降は、「スマートプロキシ」により処理すべきデータストリ
ームを指すクリティカルストリームと、安全ではない端末上で処理することがで
きる「オパーク」データストリームとを区別することにする。

【０１４７】この状況においては、フラグフィールドの特別な値により識別される「ｐｄｕ
」（コマンドの「ｐｄｕ」）により、コマンドをエージェントに送信することが
できる。これらのコマンドは本来の意味でのアドレスされたエージェントにより
処理され、別のエージェントまたはネットワークＲＩには送信されない。

【０１４８】同じくこの状況においては、本発明に固有のエージェントの機構が実現される
が、データのやりとりはセッション外で行うことができる。

【０１４９】実際、２つのエージェントは、セッションを経由して接続しなくとも、ある量
のデータを交換することができる。個別コマンド「ｐｄｕ」は、任意にＡ_１と呼
ぶ第１エージェントに、（ソースリファレンス、デスティネーションリファレン
スおよびフラグのフィールドを除いて）送信すべきデータ量Ｑ_１を示し、別の「
ｐｄｕ」は、エージェントＡ_１から送信されエージェントが受信することができ
るデータ量Ｑ_２を、任意にＡ_２と呼ぶ第２エージェントに示す。「ＣＬＯＳＥ」
フラグを含む「ｐｄｕ」はセッション外では送信されない。

【０１５０】クリティカルおよびオパークストリームのルートはそれぞれ以下の通りである
。

【０１５１】クリティカルストリームは、「スマートプロキシ」に結合されたフィルタ２８
により処理されしたがって必ずチップカード２ａを経由しなければならない機密
情報を含む。オパークストリームは、たとえばセッション外データ交換機構を使
用することにより、端末１上にあるエージェントによってのみ処理することがで
きる。

【０１５２】オパークストリームは、クリティカルストリームによりセキュア化することが
できる。

【０１５３】実際、データのグローバルストリームは通常、オパークストリームとクリティ
カルストリームとに分解することができ、それによりたとえば、振幅がより小さ
いクリティカルストリームにより、（たとえば本来の意味でのマルチメディアデ
ータを示す）高データレートストリームを解読することができる。

【０１５４】本発明に固有の構成により非対称データ通信および処理プロトコルを編成する
ことにより、そのような高データレートマルチメディアデータを処理することが
可能になる。

【０１５５】例４：非対称リダイレクトフィルタ非対称リダイレクトフィルタは、ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｆ１＝／ｗｗｗ．ｈｏｓｔ
．ｃｏｍ／ｕｎＦｉｃｈｉｅｒ（１２）
型の「カード」ＵＲＬに、ｈｔｔｐ：／／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｕｎＦｉｃｈｉｅｒ（１３）
のような外部サーバ４への「ｈｔｔｐ」要求を関連つける。

【０１５６】識別および認証の段階（たとえば「チャレンジ」を基本とする機構）を含むサ
ーバ４への接続は、「スマートプロキシ」２７に組み合わされたフィルタ２８−
以後任意に「？ｆ１」と呼ぶことにする−により制御される。フィルタ２８は非
対称である。なぜなら、いったん認証が行われると、サーバ４との間で交換され
るデータは暗号化されず、もはやフィルタ２８を経由しない。

【０１５７】（図６のシステムの本発明によるアーキテクチャを簡略的に示す）図７の線図
により概略的に示す非対称リダイレクトフィルタ２８の実施段階は以下の通りで
ある。

【０１５８】１．ナビゲータ１０が「ネットワーク」エージェントＴ_１（ＩＰアドレス：１
２７．０．０．１：８０８０）との接続を開始し、チップカード２ａのＷＥＢサ
ーバとのセッションＴ_１−Ｓ_１が開始する２．「ｈｔｔｐ」要求が、ナビゲータ１０から「ＷＥＢ」エージェントＳ_１に
送信され、「ＷＥＢ」エージェントＳ_１が、「／？ｆ１＝／ｗｗｗ．ｈｏｓｔ．
ｃｏｍ／ｕｎＦｉｃｈｉｅｒ」ファイルの名称から、個別リダイレクトフィルタ
２８（「？ｆ１」）への呼び出しを検出し、その瞬間から、「ネットワーク」エ
ージェントＴ_１が受信した全データがこのフィルタ２８により処理される３．フィルタ２８によりクライアントエージェントＳ_２のインスタンスが生成
される４．Ｓ_２が「ネットワーク」エージェントＴ_２とのセッションを開始し、送信
された最初の「ｐｄｕ」（「ＯＰＥＮ」フラグが位置決めされる）がリモート「
ＷＥＢ」サーバ４のアドレスおよびポート（「ｗｗｗ．ｈｏｓｔ．ｃｏｍ」）を
含む５．エージェントＴ_２がリモート「ＷＥＢ」サーバ４との接続を開始し、開始
後、トークンがエージェントＳ_２に送信される６．フィルタ２８（「？ｆ１」）とリモートサーバ４との間で認証手続が行わ
れ、セッションＳ_２−Ｔ_２によりデータのやりとりが行われる７．この手続が成功すると、フィルタ２８はコマンドの「ｐｄｕ」をエージェ
ントＴ_１に送り、エージェントＴ_１はフィルタに対し、エージェントＴ_２により
セッション外で送信された全データを受信することを許可し、「ネットワーク」
エージェントＴ_２にコマンドの「ｐｄｕ」を送る。このエージェントはフィルタ
に対し、ネットワークから受信した全データをエージェントＴ_１に送るよう指示
する。すなわち、リモートサーバ４からのデータはエージェントＴ_２およびＴ_１によりナビゲータ１０に中継されるため、チップカード２ａを通過することはし
なくなる８．（サーバ４のコマンドにより）「ＴＣＰ」切断が発生すると、エージェン
トのうちの一方Ｔ_１またはＴ_２が、「ＣＬＯＳＥ」状態のフラグを有する「ｐｄ
ｕ」を、エージェントのうちの一方Ｓ_１またはＳ_２に送信し、フィルタ２８は、
セッションＴ_１−Ｓ_１およびＴ_２−Ｓ_２の放棄を管理する。

【０１５９】例５：非対称「ＳＳＬ」フィルタこの例は、図６のシステムの本発明によるアーキテクチャの主要部分を簡略に
示した図８の線図により概略的に図示されている。

【０１６０】上の例３において記述したように、「ＳＳＬ」フィルタは、「カード」ＵＲＬ
（たとえば式（１１）のそれ）を使用して能動化することができる。このような
プロトコルにおいては、解読アルゴリズムおよび単一方向ハッシュ機能（または
英語で「ハッシュ」）を備える一対のエンティティ、ならびにある数の関連パラ
メータ（「ハッシュ」機能の鍵および現在値）を選択するために、クリティカル
データストリームが使用される。いったんネゴシエーション段階が終了すれば、
チップカード２ａ内でのこれらのアルゴリズムの実行は特別な意味を有するもの
ではない。なぜならデータは平文でインターネット網ＲＩから端末１に送られる
からである。

【０１６１】したがって有利には、「ＳＳＬ」機能が割り当てられた（サーバ型の）追加エ
ージェントＴ_３を使用することができる。このエージェントＴ_３は、端末１内に
配置される。いったん「ＳＳＬ」セッションのパラメータのネゴシエーションが
行われると、「ＳＳＬ」フィルタ２８は、追加クライアントエージェントＳ_３（
チップカード２ａ側）と「ＳＳＬ」サーバエージェントＴ_３（端末側）との間で
セッションを開始する。セッションの開始時、エージェントＴ_３は「ＤＥＳ」鍵
の値および「ハッシュ」機能の現在のパラメータで初期化される。「ＳＳＬ」フ
ィルタ２８はコマンドの「ｐｄｕ」をエージェントＴ_２に送るが、このエージェ
ントによりフィルタは、セッション外にＴ_３により送信されたデータをネットワ
ークＲＩに再送信し、ネットワークから受信したデータをＴ_３にリダイレクトす
ることができる。「ＳＳＬ」フィルタ２８は、エージェントＴ_３が、Ｔ_１および
Ｔ_２によって送信されたデータをセッション外で受信できるようにコマンドの「
ｐｄｕ」をエージェントＴ_３に送る。「ＳＳＬ」フィルタはエージェントＴ_１に
コマンドの「ｐｄｕ」を送るが、このエージェントによりフィルタは、セッショ
ン外にＴ_３により送信されたデータをネットワークＲＩに再送信し、このネット
ワークＲＩから受信したデータをＴ_３にリダイレクトすることができる。すると
、端末１内のＴ_１−Ｔ_２−Ｔ_３間にセッション外「トンネル」が確立される。エ
ージェントＴ_１またはＴ_２が、自身に関連するセッションを閉じると、フィルタ
２８は、残っている別の２つのセッションの閉動作を行う。

【０１６２】非対称フィルタ、一般的な場合より一般的には、図７および図８の線図のいずれか１つを再度参照すると、非
対称フィルタ２８使用手順の諸段階は以下の通りである。

【０１６３】２つのセッションＴ_１−Ｓ_１およびＴ_２−Ｓ_２により「カード」ＵＲＬから「
スマートプロキシ」２７（図６）が作製される。作製すべき個別２８がこのＵＲ
Ｌから決定される。最初にフィルタ２８が、「ＴＣＰ」クライアント（ナビゲー
タ１０）とリモートサーバ４との間のデータストリームを制御する。認証および
ネゴシエーション段階の終了時に一組のセキュリティパラメータが得られる。こ
のパラメータはクリティカルデータストリームから成る。

【０１６４】するとフィルタ２８は、セッションの開始時にフィルタ２８により定義される
一組のパラメータでネゴシエーションが行われるプロトコルを実施するセキュリ
ティエージェント（たとえばＴ_３）とのセッションを開始する。フィルタ２８は
、セッションＴ_１−Ｔ_２−Ｔ_３外のデータ転送「トンネル」を生成する。連Ｔ_１ −Ｔ_２−Ｔ_３により、あらかじめ決められた量のデータが帯域外で送信される。
別の言い方をすれば、オパークデータストリームはＴ_１−Ｔ_２−Ｔ_３のユニット
で処理されるため、チップカード２ａを経由しない。オパークデータは、周期的
に固定されるオパークデータ長、緊急データポインタによる「ＴＣＰ」パケット
内のマークなど種々の方法により識別することができる。これらの方法は周知の
ものである。クリティカルデータはオパークデータとは反対に、端末１のエージ
ェントＴ_１またはＴ_２によりフィルタ２８に送信される。その結果、フィルタは
、コマンドの「ｐｄｕ」により、エージェントＴ_３の機能パラメータを変更する
。端末１のエージェントＴ_１またはＴ_２が、自身に関連するセッションを閉じる
と、フィルタ２８は、残っている別の２つのセッションの閉動作を行う。

【０１６５】同様に、一般的には、オパークデータストリームは、セキュリティに関するあ
らゆる態様以外に、たとえばエージェントＴ_３と同様の追加エージェントにより
実行される種々の変更を受けることができる。「セキュリティ」という用語は、
特に「証明書」などを使用することにより、機密性、許可、封印、または署名な
どより広範な許容範囲で理解しなければならない。

【０１６６】この場合、結果として、フィルタ２８は上と同様に、個別の「ｐｄｕ」の使用
により、エージェントＴ_３のパラメータを変更することができる。

【０１６７】趣旨を明らかにするために、非限定的例として、フォーマットの変換を行うこ
とができる。音声データの場合、たとえば「ｍｐ３」フォーマットにより符号化
されて送信されるオパークデータは、「ｗａｖ」フォーマット、あるいは端末１
が受け入れる別のあらゆるフォーマットに変換することができる。ビデオデータ
についても同様であり、「ＭＰＥＧ」データで受信されるオパークデータは、「
ａｖｉ」フォーマット、あるいは端末１が受け入れる別のあらゆるフォーマット
に変換することができる。

【０１６８】いずれの場合も、クリティカルデータを構成する小サイズ低データレートデー
タストリームのみがチップカード２ａを経由する。次に、Ｔ_１およびＴ_２、場合
によってはＴ_３を経由する、端末内のオパークストリームのデータの通過ならび
にその処理を制御する適切なフィルタを選択するにはこれらのデータのみが必要
である。

【０１６９】言い換えれば、チップカードを「ＷＥＢ」クライアント／サーバに変換し、こ
の中に「プロキシ」を直接作製することができる本発明に固有な構成により、チ
ップカードは情報ストリームの処理を委任することができるが、情報量は、チッ
プカードが接続されている端末により固定される。きわめて高いデータレートを
有するグローバルストリームは、非対称通信プロトコルが実行されるおかげで、
最高の程度のセキュア化を保ちながら、チップカード端末により処理することが
できることがわかる。この高度なセキュア化は、主たる暗号化および／または認
証作業がチップカードの排他的制御下にあり、クリティカルデータがチップカー
ドを経由することによるものである。

【０１７０】前出の内容を読むことにより、本発明は設定した目的を達成したことが容易に
確認できよう。

【０１７１】しかしながら、本発明は、特に図２から図４ならびに図６から図８を参照して
明示的に記述した実施例に限定されるものではないことは明らかであろう。

【０１７２】また、記述した過程は反転可能であること、すなわちサーバと端末との間の送
信は双方向に行うことができることも明らかであろう。実際、端末は、常にチッ
プカードの制御下で、高データレートファイルをリモートサーバに送信すること
もできる。この場合、クリティカルデータは、万一、リモートサーバとのネゴシ
エーション段階があった場合にはその後に、チップカードに供給される。

【０１７３】最後に、高データレートセキュア化マルチメディアデータストリームの送信の
場合における方法を詳細に記述したが、上に示したような本発明による方法は、
この個別の適用例に何ら限定されるものではない。

【０１７４】本発明は、少なくとも１つのリモートサーバと、チップカードリーダを具備す
る端末との間における、インターネット型ネットワークを経由するデータストリ
ームの送信方法であって、前記端末が情報処理手段と情報記憶手段とを備え、情
報記憶手段が少なくとも１つの「ＴＣＰ／ＩＰクライアント」型アプリケーショ
ンを含み、チップカードが情報処理手段と情報記憶手段とを備え、前記端末と前
記サーバの双方が前記インターネット型ネットワークに接続され、ａ／前記チップカード（２ａ）の情報記憶手段内に、専用通信プロトコル層を
形成する第１ソフトウェア（２３ａ）をインプリメントすることから成る第１段
階と、ｂ／前記端末（１）の情報記憶手段内に、専用通信プロトコル層を形成し、少
なくとも１つの前記「ＴＣＰ／ＩＰ」型アプリケーション（１０）とのインタフ
ェースを形成する第２ソフトウェア（１３）をインプリメントすることから成る
第２段階とを備えること、 − さらに前記第１および第２ソフトウェア部（１３、２３ａ）がそれぞれ、
クライアント型の第１独立ソフトウェアエンティティ（Ｔ_２、Ｓ_１）と、サーバ
型の第２独立ソフトウェアエンティティ（Ｔ_１、Ｓ_２）とを備え、前記端末（１
）と前記チップカード（２ａ）との間で双方向データ交換セッションを確立し、
前記チップカード（２ａ）が「ＷＥＢ」型クライアント／サーバの機能を提供す
るようにし、かつ前記インターネット型網（ＲＩ）を経由して、前記端末（１）
と、前記リモートサーバ（４）との間で双方向データ交換セッションを確立する
よう、端末およびチップカードの情報処理手段により前記エンティティ（Ｔ_１、
Ｓ_１、Ｔ_２、Ｓ_２）が、協働し、前記独立ソフトウェアエンティティが、あらか
じめ決められたプロトコルのデータユニットで通信すること、 − 前記第２専用ソフトウェア部（２３ａ）内に含まれるクライアントおよび
サーバ型の前記第１および第２独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に
および／またはからプロトコルデータユニットを受信および／または送信する「
フィルタ」（２８）と呼ばれる所与の機能特性の適用ソフトウェア部を前記チッ
プカード（２ａ）の情報記憶手段内に実施する段階を備え、前記適用部分の実施
が前記サーバ（Ｓ_１）型独立ソフトウェアエンティティの制御下にあること、 − 前記専用第１ソフトウェア部（１３）の前記独立フトウェアエンティティ
（Ｔ_２、Ｔ_１）とのセッションを開始し、前記端末（１）と前記リモートサーバ
（４）との間で送信される前記データストリームのあらかじめ決められた特性を
変更するために、チップカードの前記情報処理手段により、前記フィルタ（２８
）が、前記専用第２ソフトウェア部（２３ａ）の前記独立ソフトウェアエンティ
ティ（Ｓ_２、Ｓ_１）と協働することを特徴とする方法にも関する。

【図面の簡単な説明】

【図１Ａ】知られている技術によるチップカードを基にするアプリケーションシステムの
例のそれぞれハードウェアアーキテクチャおよびソフトウェアアーキテクチャを
示す略図である。

【図１Ｂ】知られている技術によるチップカードを基にするアプリケーションシステムの
例のそれぞれハードウェアアーキテクチャおよびソフトウェアアーキテクチャを
示す略図である。

【図２】本発明による、「ＷＥＢ」サーバとして動作するチップカードを基にするアプ
リケーションシステムの例を示す略図である。

【図３】本発明の一態様によるインテリジェントエージェントと呼ばれるソフトウェア
エンタイティ間のセッションのステイタスダイアグラムである。

【図４】チップカードがインテリジェントエージェントを備える本発明によるシステム
のソフトウェアアーキテクチャの略図である。

【図５】知られている技術による「プロキシ」の略図である。

【図６】「プロキシ」と呼ばれるフィルタがチップカード上に作製される、図４のシス
テムに適合する本発明によるシステムのソフトウェアアーキテクチャの略図であ
る。

【図７】図６のアーキテクチャの種類の本発明によるアーキテクチャ内の（リダイレク
トと呼ばれる）非対称フィルタの第１実施例を示す概略線図である。

【図８】図６のアーキテクチャの種類の本発明によるアーキテクチャ内の（ＳＳＬと呼
ばれる）非対称フィルタの第２実施例を示す概略線図である。

Claims

【特許請求の範囲】

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