JP3653048B2 - インターネット型ネットワークを介するマルチメディアデータの伝送、特に電話データまたはテレビ電話データの伝送を管理する方法、および前記方法を実施するためのスマートカード - Google Patents

Description

【０００１】
本発明は、スマートカードの読取装置を備えた端末に接続されたスマートカードを用いたインターネット型ネットワークを介するマルチメディアデータの伝送管理方法に関する。
【０００２】
本発明は、より詳細には、インターネット型ネットワークを介する電話伝送またはテレビ電話伝送の管理に関する。
【０００３】
本発明はまた、その方法の実施のためのスマートカードにも関する。
【０００４】
上記の伝送は、適切なハードウェアゲートウェイおよびソフトウェアゲートウェイを介して、その全体をインターネット型ネットワーク上で、または、一部をネットワーク上で、また一部を標準電話ネットワーク（たとえば交換型）上で行うことができる。
【０００５】
本発明の範囲を限定することなく、分かりやすくするために、好ましい実施形態、すなわちインターネットを介する電話の枠組みで本方法について説明する。
【０００６】
本発明の枠組みにおいては、「インターネット」という用語は、最も一般的な意味において理解されなければならない。それは、厳密な意味でのインターネットに加えて、「イントラネット」と呼ばれる型の企業の専用ネットワークまたはそれに類するネットワーク、および「エクストラネット」と呼ばれる型の外部に向けてイントラネットを延長するネットワーク、さらに一般的には、そこでデータ交換がインターネット型プロトコルに従ってなされるネットワーク全体を対象とする。以降、このようなネットワークを一般的に「インターネット」と呼ぶ。
【０００７】
同様に、「端末」という用語も一般的な意味で理解されなければならない。上記の端末は、特に、ＷＩＮＤＯＷＳやＵＮＩＸ（両方とも登録商標である）などのさまざまなオペレーティングシステムの下で動作するパーソナルコンピュータによって構成することができる。端末はまた、ワークステーション、可搬コンピュータ、またはいわゆる専用カード端末によって構成することもできる。
【０００８】
ここ５年間のインターネットの目覚しい発展にともない、特に、「ＷＥＢ」型遠隔サーバとリンクできるようにするために、ますます多くの端末がこのネットワークに接続している。インターネット網を構成する回線を介して搬送されるデータに関しては限界が存在する。しかしながら、それら限界は、まず最初にデータの性質に関連するのではなく、特に、回線が許可する容量に関連する。最近、設置されている大容量回線（ケーブル、「ＡＤＳＬ」型回線、衛星回線、ＲＮＩＳ等）が、今後、マルチメディア型のデータを伝達し、それをリアルタイムで処理するのを可能にすることになる。
【０００９】
さらに、インターネットを介して電話通信、さらにはテレビ電話通信が行われるようにすることが特に興味深い。データ自体の伝送には、特に問題はない。データは、この型のネットワークで通常使用されているプロトコルによって処理することができる。しかしながら、通信管理は、特有の問題、具体的には、従来の電話において「シグナリング」と呼ばれるものに関連した問題が存在する。一般に、この概念は、通信相手のコール、コールの受入れ、会話の開始と終了、呼出し音、受話器を外すこと等のような動作を指している。
【００１０】
１９９０年代に、インターネットを介する電話コールを実現できるように、多数のシステムおよびソフトウェアが提案された。
【００１１】
「インターネットフォン」（登録商標）と呼ばれるインターネット上の最初の電話は、１９９５年にＶｏｃａｌｔｅｃ社が開発した。今日では、Ｍｉｃｒｏｓｏｆｔ社の「ＷｅｂＰｈｏｎｅ」「ＮｅｔＭｅｅｔｉｎｇ」（両方とも登録商標）など、数十種類の製品が存在する。
【００１２】
したがって、そこから生じた従来の技術は、大きな多様性、規格の欠如、または少なくとも実質的な標準の欠如という特徴を有する。そのことから、それらの製品は相互運用性を持っていない。
【００１３】
しかしながら、現在、以下のような傾向を認めることができる。
【００１４】
ａ．擬似シグナリング（コールの通知、コールの受入れまたは拒否のための発呼者の識別等）を実現するための「ＴＣＰ」型のポートの使用。
【００１５】
ｂ．たとえば、５．３Ｋｂｐｓから６．３ＫｂｐｓまでのＵＩＴ−Ｔ Ｇ７２３（国際電気通信連合）方法による音声信号の圧縮。
【００１６】
ｃ．「ＲＴＰ」プロトコル（ＲＦＣ１８８９仕様に準拠する「リアルタイムプロトコル」）を利用する音声の伝播。これは、それ自体「ＵＤＰ」（「ユーザデータグラムプロトコル」）伝送プロトコルや日付入り「ＰＤＵｓ」（「プロトコルデータユニット」）を使用し、「ＲＴＣＰ」コントロールプロトコル（「リアルタイムトランスポートコントロールプロトコル」）に関連する。
【００１７】
ｄ．その「ＩＰ」アドレスによる被呼者の識別。数多くのサーバが、固定メールアドレスにサービス提供者または「プロバイダ」（英語では、「ＩＳＰ」または「インターネットサービスプロバイダ」）の「ＰＰＰ」型のサーバ、たとえば「ＩＣＱ」という略語で知られたサーバによって付与される「ＩＰ」アドレスを関連付けるのを可能にしている。
【００１８】
通信がインターネットから出なければならない場合には、「ＩＴＧ」（「インターネット電話ゲートウェイ」）と呼ばれる電話インターネットゲートウェイによって、一般に英語略語「ＰＳＴＮ」（「公衆交換電話ネットワーク」）で知られている交換型の公衆ネットワークを、インターネットに接続することが可能になる。ローカルネットワーク内および「ＲＮＩＳ」ネットワーク上（「デジタル総合サービス網」または英語で「ＩＳＤＮ」）で使用されるパケットのフォーマットを規定するプロトコル「Ｈ３２３」は、「ＣＣＰ」（「Ｃａｌｌ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ」）と呼ばれるコールプロトコルの主要な規格となるように思われる。
【００１９】
インターネット上の電話には３種類の重要な問題がある。
【００２０】
ａ．ネットワークにおける加入者探索、すなわち（情報処理装置の）「ＩＰ」アドレス関連を確立すること。
【００２１】
ｂ．電話コールのシグナリング管理（通信相手のコール、コールの受入れ、会話の始まり、会話の終了）。この機能は、「インターネット−インターネット」型のコールについてはいわゆる「プロプラエタリ」プロトコル（一般には、「シグナリングプロプラエタリプロトコル」または「ＰＳＰ」）によって、または、「インターネット−ＲＴＣ」型のコールについては、標準化をめざす個別のプロトコル（上記の「ＣＣＰ」プロトコル）によって実行され、シグナリングは、以下「シグナリングチャネル」または「ＣＳ」と呼ばれる「ＴＣＰ」接続を用いて実行される。
【００２２】
ｃ．マルチメディアデータフローの交換。採用されるプロトコルは一般に、「ＲＴＰ」（上記の仕様「ｒｆｃ１８８９」に準拠する「Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ」）と呼ばれるプロトコルであり、マルチメディアデータの交換は、データチャネルを介して実行され、情報は上記のプロトコル「ＵＤＰ」によって搬送される。
【００２３】
インターネットでの電話の会話を確立するためには、発呼者および被呼者は、同一ソフトウェアを使用しなければならない。図１は、電話ソフトウェア（「ＬＴ」）、たとえば上記の「ＮｅｔＭｅｅｔｉｎｇ」ソフトウェアを構成する主要モジュールを概略で示している。従来の電話ソフトウェアおよび関連伝送システムのアーキテクチャは、以下のサブセットを含む。
【００２４】
ａ．加入者の識別を可能にする一連の情報を含む加入者プロファイル（「ＰＡ」）
ｂ．ディレクトリサーバ（たとえばポートＮｏ．３８９のような特定の「ＴＣＰ」ポート番号によって識別される「ＳＡ」）への加入者登録を実行する登録プロトコル（「ＰＥ」）
ｃ．加入者のサーチ機能をその識別子（一般にはｅメール）に基づいて実行する探索プロトコル（「ＰＬ」）。この機能は、ディレクトリサーバ（「ＳＡ」）への接続を用いて実行される。
【００２５】
ｄ．特定のポート（ＮｅｔＭｅｅｔｉｎｇについてはＮｏ．１５０３）上のＴＣＰ接続を介して電話コールを管理する、プロプラエタリシグナリングプロトコル（「ＰＳＰ」）を実施するシグナリングチャネル（「ＣＳ」）。
【００２６】
ｅ．「ＲＴＰ」のようなデータ交換プロトコルを用いてリアルタイムデータ（音声および／または画像）の交換を管理するデータチャネル（ＣＤ）。
【００２７】
オプションとして、インターネット上の電話ソフトウェアは、「ＴＣＰ」接続（「ＮｅｔＭｅｅｔｉｎｇ」ソフトウェアの場合にはポートＮｏ．１７３１上の）を用いて、コール管理プロトコル（「ＣＣＰ」）を使用しながら、標準電話ネットワークの加入者に向かって発呼することができる。
【００２８】
本明細書に添付の図１は、上述した型の電話ソフトウェアを利用する、従来の技術による、インターネットＲＩを介する電話システム９のアーキテクチャを概略で示している。
【００２９】
この図では、２つの端末９ａおよび９ｂが概略的に示されているが、それぞれ、それらを備えた電話ソフトウェア９０ａおよび９０ｂだけを示している。
【００３０】
これらのソフトウェアの構成要素は、各端末、９ａ、９ｂごとに、加入者プロファイル（「ＰＡ」）９０３ａまたは９０３ｂに関連した、登録プロトコル「ＰＥ」９００ａまたは９００ｂ、および探索プロトコル「ＰＬ」９０１ａまたは９０１ｂを有する。加入者プロファイル「ＰＡ」は、一般に「ユーザＩＤ」という呼称で知られている加入者の基本識別子ＡａまたはＡｂおよび、この加入者をより完璧に識別する、以下に明示する種々のデータを有する。
【００３１】
登録プロトコル「ＰＥ」、９００ａまたは９００ｂによって、端末９ａまたは９ｂに関連付けられた加入者、ＡａおよびＡｂは、インターネットＲＩに接続されるディレクトリサーバ９１内に登録することができる。登録は、上記の加入者プロファイル「ＰＡ」、９０３ａまたは９０３ｂ内に含まれる識別データを使用することによって行われる。
【００３２】
２人の加入者間の通信を確立しようとすると、着呼側加入者の探索段階に進むことが必要となる。たとえば、端末９ａが、端末９ｂと通信を確立しなければならない場合には、インターネットＲＩ上の端末９ｂのアドレス「ＩＰ」を知ることが必要になる。
【００３３】
それらプロセスは、それ自体純粋交換型ネットワーク上の従来の電話にも共通である。各加入者に対してコール番号、すなわち、１つまたは複数のディレクトリ内にリストアップされた番号が割り当てられる。
【００３４】
しかしながら、加入者間、すなわち端末間の電話伝送を確実に行うのにインターネットに頼ることは、特有の制約を課す。
【００３５】
まず第１に、ネットワークにおける通信プロトコルの主要特性を思い起すことが有益であると思われる。
【００３６】
通信ネットワークのアーキテクチャは、さまざまな層により説明される。例として、「ＩＳＯ」によって規定される「ＯＳＩ」（「Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ」）標準は、中間層、特に「トランスポート」層を通過して、低層（たとえば物理伝送サポートに関する「物理」層）から高層（たとえば「アプリケーション」層）までの７層を有する。任意の層は、適切なインターフェイスを介して、すぐ上の層にサービスを提供し、すぐ下の層に他のサービスを要求する。それらの層はプリミティブを用いて通信する。それらはまた、同じレベルの層と通信することができる。特定のアーキテクチャにおいては、複数の層を省くことも可能である。
【００３７】
インターネット型の環境においては、層は５つあり、より厳密に言えば、上層から下層に向かって、アプリケーション層（「ＨＴＴＰ」、「ＦＴＰ」、「ｅメール」等）、トランスポート層（「ＴＣＰ」）、ネットワークアドレシング層（「ＩＰ」）、データリンク層（「ＰＰＰ」、「スリップ」等）、物理層がある。
【００３８】
従来の技術においては、加入者、ＡａおよびＡｂが、固定アドレス「ＩＰ」または、英語略語「ＩＳＰ」（「インターネットサービスプロバイダ」）で一般に知られているインターネットサービス提供者に頼る場合には、可変アドレス「ＩＰ」を所有するインターネット端末、９ａまたは９ｂを使用する。
【００３９】
第１の欠点は、「ＩＰ」アドレスが加入者にではなく、インターネットに接続された情報処理システムに関連付けられる点である。情報処理システムが固定アドレスを備えている場合であっても、「ＩＰ」アドレスと個人との間に先験的な対応が存在しない。実質的に、このような関係を確立するために、加入者はディレクトリサーバ「ＳＡ」９１（「Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ」については、「ＩＲＣ」と呼ばれる型とすることができる）に接続される。このサーバは、加入者の識別子、または「ユーザＩＤ」に、その「ＩＰ」アドレスを関連付ける。識別子は、一般に、そのｅメール通信アドレス、または英語用語によれば「ｅメール」によって構成されるが、何らかの仮名を使用することもできる。
【００４０】
こうした関連付けは、一般に認証されないので、サービス（通常は無料）が、できるだけ便利な方法で利用できる。しかしながら、こうした措置もまた、とりわけ「敏感な」アプリケーションについては欠点をもっている。
【００４１】
したがって、第１の制約のうちの１つは、インターネットＲＩにおける加入者の探索、すなわち固定識別子と「ＩＰ」アドレスとの間の通信の確立である。
【００４２】
インターネットＲＩにおける加入者の探索、すなわち上記の通信の確立は、加入者があらかじめ、ディレクトリサーバ「ＳＡ」内に登録されていることを前提とする。
【００４３】
したがって、インターネット内の加入者のアドレスは、「ＳＡアドレス」と「ユーザＩＤ」との組み合わせで構成される。通常、「加入者」とは、「物理的」エンティティを意味する。拡大解釈によって、「機能」を対象とすることもできる。しかしながら、以下においては「加入者」とはその一般的な意味で使用し、それは、本発明の範囲を限定するものではない。
【００４４】
実質的に、加入者は、上記の登録プロトコル「ＰＥ」を用いて、現在の「ＩＰ」アドレスを（ディレクトリ）サーバに与えながら、自発的行為によってインターネットＲＩ内のその探索を指定する。
【００４５】
このオペレーションは、端末９ａまたは９ｂが、サービスプロバイダによって付与され、個別の加入者プロファイル「ＰＡ」９０３ａまたは９０３ｂによって個人化された特有のソフトウェア（またはアプリケーション）、この場合には、ソフトウェア「ＰＥ」９００ａまたは９００ｂを所有することを意味している。
【００４６】
以上に示したように、加入者の基本的識別子（「ユーザＩＤ」）に加えて、加入者プロファイル「ＰＡ」１０３ａまたは１０３ｂは、加入者の登録の際に、ディレクトリサーバ「ＳＡ」９１に提供される情報全体、たとえば以下を有する。
【００４７】
− 「ディレクトリサーバ」（ＳＡ）のアドレス
− ユーザが通信を始めることを承諾した相手、またはネットワーク内で自らの場所を通知することを望む相手である加入者（その「ユーザＩＤ」によって識別される）、
− ディレクトリサーバにおいて公表されることを加入者が承諾する情報（たとえば、名前、国籍、求められる連絡等）。
【００４８】
インターネットＲＩを通して通信相手と連絡するためには、その通信相手が正式に登録されているのであれば、その「ＩＰ」アドレスを知る必要がある。こうした情報は、ディレクトリサーバ「ＳＡ」９１、および探索プロトコル「ＰＬ」それぞれ９０１ａまたは９０１ｂを用いて得られる。
【００４９】
加入者プロファイル「ＰＡ」は、本来、加入者に固有のものであるが、ディレクトリサーバ「ＳＡ」の特徴、具体的にはそれに提供されるべき、またはそれが受け入れることのできる情報の型と種類に依存することができる点に留意しなければならない。
【００５０】
さらに、プロトコル「ＰＬ」９０１ａまたは９０１ｂは、先験的に標準化されていない、または世界的に認められている規格に適合していないディレクトリサーバ「ＳＡ」９１をアドレスすることから、プロトコル「ＰＥ」９００ａまたは９００ｂのように、プロプラエタリ型である点に留意しなければならない。端末のプロトコル「ＰＥ」および「ＰＬ」は、それぞれ参照符号９１０と９１１が付されたディレクトリサーバ「ＳＡ」９１内に設置された対応プロトコルと互換性がなければならない。
【００５１】
これら２つの特徴は、さらに別の欠点を有する。
【００５２】
以上の点をまとめると、発呼側加入者Ａａが着呼側加入者Ａｂを探索し、着呼側加入者によって探索されることができるためには、発呼側加入者が使用する端末、たとえば９ａが、プロトコル「ＰＥ」および「ＰＬ」を実施できる、特定のソフトウェア、９００ａまたは９００ｂ、９０１ａまたは９０１ｂを保存することが必要である。同じく、その加入者は、その加入者プロファイル「ＰＡ」９０３ａに割り当てられたデータを保存することが必要な場合もある。こうした指摘は、他の加入者の端末、たとえば端末９ｂにも同様に当てはまる。
【００５３】
言い換えれば、いずれかの加入者ＡａまたはＡｂによって使用されている、端末９ａまたは９ｂもまた、この加入者が端末を変えようとする場合には、最初の端末において登録予備段階をすでに行ったことを認め、プロトコル「ＰＥ」を頼り、ディレクトリサーバ「ＳＡ」にそのプロファイル「ＰＡ」を提供することによって、新しく使用する端末において、少なくとも１つまたは複数のプロトコル「ＰＬ」に関連したソフトウェアを見つけ出さなければならないという意味において、それもまた特有である。実際に、プロトコル「ＰＬ」の存在は、ディレクトリサーバ「ＳＡ」９１をアドレシングし、その中に登録されているデータ、特にサーチされた通信相手のアドレス「ＩＰ」およびそのプロファイル「ＰＡ」にアクセスするために必要である。
【００５４】
端末９ａまたは９ｂはまた、同じくプロプラエタリ型の２つの追加ソフトウェアの各々を備えていなければならない。２つの追加ソフトウェアとは、信号プロトコルＰＳＰ９０２ａまたは９０２ｂ、および上記のデータ交換プロトコル「ＲＴＰ」（またはそれに類するプロトコル）９０５ａまたは９０５ｂである。プロトコル「ＰＳＰ」に関連したモジュールは、インターネットＲＩを通し、シグナリングチャネルＣＳを介して互いに連絡する。同様に、プロトコル「ＲＴＰ」に関連したモジュールは、インターネットＲＩを通し、データチャネルＣＤを介して、互いに連絡する。
【００５５】
さらに、電話通信が、切替えられた標準ネットワーク９３に向かってインターネットＲＩから出なければならない場合には、同じくプロプラエタリ型の上記のコール管理プロトコル「ＣＣＰ」（またはそれに類するプロトコル）９０４ａまたは９０４ｂを備えることが必要になる。また、プロトコル「ＣＣＰ」に関連したモジュール９０４ａとネットワーク「ＲＴＣ」９２との間で、ただ１つの参照符号９２で示された、上記の「ＩＴＧ」型の１つまたは複数のゲートウェイを備えることが必要である。加入者の電話機９５は、従来の「ＰＢＸ」局（構内電話交換システム）９４または他の何らかの類似したシステムを介して、ネットワーク「ＲＴＣ」と通信する。ゲートウェイ「ＩＴＧ」９２と加入者端末、図１で表されている例においては９ａとの間の通信は、「ＴＣＰ」型の接続を利用する。「交換電話ネットワーク」における通信は、従来の方法で行われるので、ここでこれ以上説明するのは無駄である。
【００５６】
したがって、登録段階、特にインターネットＲＩにおける加入者の探索、シグナリング（探索された加入者のコール等）、データ交換の段階などを実施するために最適化された端末を使用することは興味深いであろう。そのことから「ノマディズム」と呼ばれるコンセプトに便宜上アクセスすることが可能になる。
【００５７】
さらに、シグナリング段階において、着呼者と発呼者との間で確実な単純または相互認証手続きを実施することができることが興味深いであろう。ルーティング経路の「予約」と呼ばれるオペレーションまたはデジタル化の鍵の交渉のような、さまざまな交渉もまた、このシグナリング段階において実施できるにちがいない。同様に、データ交換段階においては、たとえば先に交渉した暗号化の鍵に基づいて、情報の堅牢な暗号化／暗号解読を行えることが興味深い。さらに、交換されたデータの量（容量）および／または使用可能なルーティング経路の量に基づいて、料金決定を実施できることが興味深く、この経路は、たとえば、シグナリングの先の段階において交渉された。
【００５８】
上記のプロトコルに関連したソフトウェア「ＰＥ」および「ＰＬ」は、通常、大量のメモリを使用する必要はない。プロファイル「ＰＡ」のデータについても同様である。したがって、スマートカードのメモリ回路の中で、それら全部または一部を登録しようと考えることができるだろう。これは現行の技術で可能である。
【００５９】
しかしながら、以下に示すように、二重の技術的困難に直面し、その結果、インターネットＲＩとスマートカードとの間のあらゆる直接通信が行えなくなってしまう。
【００６０】
まず第１に、図２Ａおよび２Ｂを参照して、インターネットに接続された、スマートカードに基づいてアプリケーションシステムの全体的アーキテクチャを簡単に思い起そう。
【００６１】
スマートカードに基づくアプリケーションシステムは、一般に、以下の主要エレメントを有する。
【００６２】
− スマートカード
− 上記端末を構成するホストシステム
− 通信ネットワーク、すなわち好ましいアプリケーションにおけるインターネット
− インターネットに接続されるアプリケーションサーバ。
【００６３】
図２Ａは、この型のアーキテクチャの一例を概略で示している。端末１、例えば個別コンピュータは、スマートカード２の読取装置３を有する。この読取装置３は、端末１内に物理的に一体化することも一体化しないことも可能である。本発明の枠組みにおいて、端末１は、図１のシステムの端末９ａまたは９ｂの役割を果たす。スマートカード２は、入出力接続が、端末１との通信および電気エネルギー供給を許可するためにそのサポートの表面と同じ高さにある集積回路２０を有する。この端末は、インターネットＲＩへのアクセス回路１１を有する。これら回路は、交換電話回線または、より高容量の通信手段、すなわち、サービス統合型デジタルネットワーク（「ＲＮＩＳ」）、衛星によるケーブルまたは回線等に接続されるために、モデムで構成される。回路１１は、直接またはインターネットサービス提供者（英語では「インターネットサービスプロバイダ」または「ＩＳＰ」）を介して、インターネッＲＩに接続されることができる。同じく、「プロキシ」または「ファイアウォール」と呼ばれる（（フランス語では）「ｐａｒｅ−ｆｅｕ」または「ｇａｒｄｅ ｂａｒｒｉｅｒｅ」とも呼ばれる）システムのような中間システムに頼ることもできる。
【００６４】
端末１は、当然のことながら、図面を簡略化するためにここには図示されていないが、中央処理装置、ＲＡＭおよびＲＯＭ、磁気ディスク大容量メモリ、ディスクドライブおよび／またはＣＤＲＯＭドライブ等といった、その円滑な作動に必要なあらゆる回路および機構を備える。
【００６５】
通常、端末１はまた、ディスプレイスクリーン５、キーボード６ａ、マウス６ｂ等のような、一体型または非一体型の従来の周辺装置に接続される。
【００６６】
端末１は、ネットワークＲＩに接続されたあらゆる情報処理システムまたはサーバと通信することができるが、そのうちの１つのサーバ４だけが、図２Ａに表されている。本発明の範囲内で、サーバ４は、ディレクトリサーバ９１（図１）で構成され、端末１は、加入者ＡａまたはＡｂに関連した、システムの１つ９ａまたは９ｂで構成される。アクセス回路１１は、「ＷＥＢ」ブラウザまたは英語によれば「ブラウザ」と呼ばれる、個別のソフトウェア１０によって、端末１をサーバ４と通信させる。ブラウザは、一般に「クライアント−サーバ」モードに従って、ネットワークＲＩ全体に分配されたさまざまなアプリケーションまたはデータファイルにアクセスすることができる。
【００６７】
インターネットＲＩにおける通信プロトコルは、「ＷＥＢ」ページの問合わせ、ファイルの転送、電子郵便（ｅメール）、フォーラムまたは「ニュース」等のとりわけターゲットとなるアプリケーションに応じて選択される。
【００６８】
端末、スマートカードの読取装置、スマートカードを有するシステムの論理アーキテクチャは、図２Ｂに概略的に表わされている。また、それ自体が以下のような複数のサブアセンブリを有する、規格ＩＳＯ ７８１６に記載されている。
【００６９】
− カードの寸法およびマーキングに関してはＩＳＯ ７８１６−１および７８１６−２。
【００７０】
− 端末のスマートカード間のデータの転送に関してはＩＳＯ ７８１６−３。
【００７１】
− 一式の命令の構造とコマンドのフォーマットに関してはＩＳＯ ７８１６−４。
【００７２】
図２Ｂでは、端末側１に、参照符号１０１として規格ＩＳＯ ７８１６−３に合致した層と、参照符号１０２の命令管理「ＡＰＤＵ」（規格ＩＳＯ ７８１６−４）のみが表されている。スマートカード２側では、規格７８１６−３に適合した層に参照符号２００が付され、命令管理「ＡＤＰＵ」（規格ＩＳＯ７８１６―４）に参照符号２０１が付されている。アプリケーションには、参照符号Ａ_１、…、Ａ_ｊ…、Ａ_ｎが付されるが、この場合、ｎは、スマートカード２上に存在する最大数のアプリケーションである。
【００７３】
アプリケーションＡ_ｊは、スマートカード２内に存在し、一式の命令を用いて端末１と対話する。この一式の命令は、通常、書込み命令と読取り命令を有する。命令のフォーマットは、英語略語「ＡＰＤＵ」（「アプリケーションプロトコルデータユニット」）で知られている。これは上記の規格ＩＳＯ ７８１６−４によって規定される。コマンド用「ＡＰＤＵ」は、「ＡＰＤＵ．ｃｏｍｍａｎｄ」と記され、応答用「ＡＰＤＵ」は「ＡＰＤＵ．ｒｅｓｐｏｎｓｅ」と記される。「ＡＰＤＵ」は、上記の規格ＩＳＯ ７８１６−３によって特定されたプロトコルを用いて、カードの読取装置とスマートカードとの間で交換される（たとえば、キャラクタモードではＴ＝０となる。またはブロックモードではＴ＝１となる）。
【００７４】
スマートカード２が、図２Ｂに表されているように、複数の別々のアプリケーションを含むと、マルチアプリケーションカードが問題となる。しかしながら、端末１は、同時にただ１つのアプリケーションとしか対話しない。
【００７５】
個別のアプリケーションＡ_ｊの選別は、選別型の「ＡＰＤＵ」（「ＳＥＬＥＣＴ」）を用いて得られる。いったんこの選択がなされると、それに続く「ＡＰＤＵ」が、そのアプリケーションに向って辿られる。新しい「ＡＰＤＵ ＳＥＬＥＣＴ」は、結果的に、進行中のアプリケーションを放棄して、そこから他のアプリケーションを選択する。「ＡＰＤＵ」２０１の管理者ソフトウェアのサブアセンブリによって、スマートカード２内で個別のアプリケーションＡ_ｊを選択し、そのように選択されたアプリケーションを記憶し、そのアプリケーションに向かって「ＡＰＤＵ」を伝達し、またそのアプリケーションから「ＡＰＤＵ」を受取ることが可能になる。
【００７６】
以上をまとめると、アプリケーションＡ_ｊの選別と、そのアプリケーションとの対話は、命令「ＡＰＤＵ」の交換によって行われる。アプリケーションＡ_ｊは、以下「ＧＣＡ」（「包括的カードアプリケーション」）と呼ばれる従来のアプリケーションであると仮定される。
【００７７】
以上の点を思い起した上で、スマートカード２は、市販の標準ブラウザ１０のコードを変更しない限り、そうしたブラウザとは直接対話できない点に留意されたい。
【００７８】
さらに、また特に、そもそも上述の標準および規格に合致している現在のスマートカードは、同じくインターネットＲＩと直接通信できないハードウェアおよびソフトウェアの構成を有する。とりわけ、それらは、この型のネットワークで使用されるプロトコルのいずれかに従って、データパケットを受取り、伝達することができない。したがって、一般には、英語で「プラグイン」で呼ばれるものの形で、端末内１に設置される追加ソフトウェアを備えることが必要である。図２Ａでは参照符号１２が付されているこのソフトウェアは、ブラウザ１０とカード２との、より厳密にはこのカード２の電子回路２０との間のインターフェイスを実施する。
【００７９】
本発明は、必要であると判断されるものに適合させながらも、上述したいくつかの欠点を含む従来の技術による方法および装置の欠点を解消することにある。
【００８０】
本発明によれば、登録プロトコル「ＰＥ」および探索プロトコル「ＰＬ」の実施に必要なアプリケーション、ならびに、加入者プロファイル「ＰＡ」を特徴付けるデータは、好ましくは、スマートカードのメモリ内に全体または一部が保存されるファイルであり、実行ファイルは上記の「ＧＣＡ」型の標準アプリケーションである。
【００８１】
本発明によれば、スマートカードは、それに関連した端末のための「ＷＥＢ」型のサーバ／クライアントとして行動する。
【００８２】
そのために、スマートカード内に特有の通信ソフトウェア層と、端末内にその対になるものが備えられる。「特有の」という用語は、本発明の方法に特有と解釈されなければならない。というのも、特有と呼ばれるこれらの通信層は、当該のアプリケーションがどのようなものであれ一般化されるからである。とりわけ、それらは、上記の種々のプロトコルの実施に必要なアプリケーションからは独立している。それらは、一方ではスマートカードと端末との間の、他方ではスマートカードとネットワークとの間の双方向データ交換プロセスにしか関わらない。
【００８３】
特有の通信ソフトウェア層は、とりわけプロトコルの会話を可能にする、「インテリジェントエージェント」と呼ばれるソフトウェアの構成要素を有する。インテリジェントエージェントは、以下、より単純に「エージェント」と呼ぶ。それぞれ端末とスマートカードに関連した特有の通信層内に並べられたエージェントが存在する。本発明の方法によれば、こうしたエージェント間にセッションが確立される。
【００８４】
本発明の方法は、従来の型、すなわち、いかなる点においても変更の必要なく、スマートカード内で探索された、上記の「ＧＣＡ」型のアプリケーションの起動を可能にする点に留意されたい。
【００８５】
そのために、ブラウザの要求を受取り、それらを「ＧＣＡ」型のアプリケーションによって理解可能な命令「ＡＰＤＵ」に翻訳するスクリプト変換と呼ばれる個別のインテリジェントエージェントが備えられる。そのことから、スマートカード内に、そもそも従来の「ＷＥＢ」サーバ内では「ＣＧＩ」の名称で知られている類似機能が設けられる。この機能は「ＨＴＴＰ」型のインターネットプロトコルによって、スマートカード内でのアプリケーションの実施を可能にする。
【００８６】
これらのさまざまな措置によって、スマートカード、より厳密にはスマートカード内に存在するアプリケーションは、インターネット型のプロトコルの実施によってインターネットに接続された遠隔サーバと直接的に通信することを可能にする。スマートカードによって提供される「ＣＧＩ」機能によって、その部分については、端末内にプロプラエタリ型のアプリケーションの存在を必要とせずに、登録プロトコル「ＰＥ」と探索プロトコル「ＰＬ」に関連したアプリケーションへのアクセスが可能になる。有利にも、市販されている標準型のブラウザのみが必要となる。
【００８７】
本発明の有利な特徴によれば、スマートカード内に、以下「フィルタ」と呼ばれる個別のアプリケーションが設置される。ここでは「プロキシ」と類似の役割を果たすソフトウェアエンティティが問題となる。そのためには、エージェントを利用する上記の措置に頼ることになる。
【００８８】
こうした措置によって、スマートカードは、信号プロトコルの「プロキシ」（「ＴＣＰ」型）および／またはデータ交換プロトコルの「プロキシ（「ＵＤＰ」型）として行動することが可能になる。
【００８９】
シグナリングプロキシの利点は、たとえば、通信の受入れのために役に立つこともできる発呼者と被呼者との間の単純なまたは相互の認証手続きを実施することができる点である。また、暗号化の鍵の交渉が可能になる。さらに、たとえば、一定の伝送の品質または高い通過周波数帯を保証することによって、先験的に、最適化されたルーティング経路を交渉することができる。
【００９０】
データ交換プロキシの主な利点は、情報の暗号化／暗号解読の堅固な手続きを実施できることにある。プロキシはまた、たとえば先に交渉された経路の型または容量に基づいて、料金決定手続きを実施することもできる。
【００９１】
したがって、これらの特徴は、上述した必要性に十分に応えることができる。
【００９２】
したがって、本発明は、第１の加入者と第２の加入者との間のインターネット型ネットワークを介するマルチメディアデータの伝送管理方法であって、シグナリングチャネルを介する少なくとも１つのシグナリングデータ交換段階と、データチャネルを介する少なくとも１つのマルチメディアデータ交換段階とを含み、さらに少なくとも前記の第１の加入者システムは、「ＷＥＢ」型ブラウザと、スマートカードと協働するスマートカード用の読取装置とを備えた端末を有し、前記のスマートカードは、特有の通信プロトコル層を形成する第１のソフトウェアを有し、前記の端末は、少なくとも前記の「ＷＥＢ」型ブラウザとのインターフェイスを形成する第２のソフトウェアを有する方法を主な対象とする。前記の第１および第２のソフトウェアは各々、さらに、クライアント型の第１の独立ソフトウェアエンティティと、サーバ型の第２の独立ソフトウェアエンティティを有し、前記のエンティティは、前記端末と前記スマートカードとの間の双方向データ交換セッションの確立を可能にし、前記スマートカードが「ＷＥＢ」型のクライアント／サーバの機能を提供することが可能になり、さらに前記のインターネット型ネットワークを介して、前記の第１の加入者システムと前記の第２の加入者システムとの間の双方向データ交換セッションを確立することが可能になるように協働し、前記の独立ソフトウェアユニットは、あらかじめ設定されたプロトコルデータユニットを用いて通信することを特徴とし、
− 前記の特有の第２のソフトウェア内に含まれる、クライアントとサーバそれぞれの型の前記の第１および第２の独立ソフトウェアエンティティに向かっておよび／またはそれらエンティティからプロトコルデータユニットを受信および／または送信する、フィルタと呼ばれる一定の機能的特徴を持つアプリケーションソフトウェアの前記スマートカード内での実装を含み、前記アプリケーションソフトウェアの実装は、サーバ型の前記の独立ソフトウェアエンティティの制御の下になされることを特徴とし、
− 前記のフィルタは、前記の信号データおよび／またはマルチメディアデータの交換段階中に、前記シグナリングチャネルおよび／またはデータチャネルの少なくともいずれか１つを介して、「プロキシ」と呼ばれる機能を形成し、前記の第１の加入者システムと前記の第２の加入者システムとの間を通過するデータ交換のあらかじめ設定された特徴を制御するために、特有の前記の第１のソフトウェアの前記の独立ソフトウェアエンティティとのセッションを開くために特有の前記の第２のソフトウェアの独立ソフトウェアエンティティと協働することを特徴とする。
【００９３】
本発明はまた、この方法の実施のためのスマートカードを対象とする。
【００９４】
添付の図面を参照して、以下に、本発明の好ましく、しかも限定的でない実施形態を説明する。
【００９５】
以下において、反対の記載がない限り、本発明の好ましい適用の枠組み、すなわちインターネットを介する電話伝送の場合には、範囲は限定しないものとする。
【００９６】
図３は、スマートカードが「ＷＥＢ」クライアント／サーバとして作動することを可能にする、本発明の第一の様態によるスマートカードに基づくアプリケーションシステムの一例を概略的に表わす図である。
【００９７】
端末１およびスマートカード２ａ内にそれぞれ設置された、参照符号１３および２３ａの特有の通信プロトコルソフトウェア層を例外として、他のハードウェアまたはソフトウェアエレメントは、従来の技術、特に、図２Ａおよび２Ｂを参照して説明した技術に共通するため、ここで再び詳細に説明する必要はない。
【００９８】
端末１は、たとえばモデムで構成されたネットワークＲＩへのアクセス回路１１を有する。これら回路は、「物理」層と「データリンク」層に対応する、ソフトウェア下層、Ｃ_１およびＣ_２を包括する。
【００９９】
また、「ネットワークアドレシング」層（インターネットの場合には「ＩＰ」）と「トランスポート」層（「ＴＣＰ」）に対応する、上層、Ｃ_３およびＣ_４が示されている。アプリケーション上層（「ＨＴＴＰ」、「ＦＴＰ」、「ｅメール」等）は示されていない。
【０１００】
下層、Ｃ_１およびＣ_２と上層、Ｃ_３およびＣ_４との間のインターフェースは、一般に「ドライバ下層」と呼ばれるソフトウェア層によって構成される。上層、Ｃ_３およびＣ_４は、このインターフェイス上に支持され、それらに対応する特有の機能のライブラリまたはネットワークライブラリ１４を介して利用される。インターネットの場合には、「ＴＣＰ／ＩＰ」は、「ソケット」と呼ばれるライブラリを用い利用される。
【０１０１】
こうした構造から、ブラウザ１０は、ファイル転送用または電子郵便の送信用の「ＷＥＢ」ページ（「ＨＴＴＰ」プロトコル）の閲覧のために、サーバ４に向かって要求を出すことが可能であり、それはまったく従来の方法で行われる。
【０１０２】
端末１はまた、一体型または非一体型のカード読取装置３を有する。スマートカード２ａと通信するために、カード読取装置３０はまた、層Ｃ_１およびＣ_２と類似の役割を果たす、２つの低層ＣＣ_１（物理層）とＣＣ_２（データリンク層）を包括する。層ＣＣ_１およびＣＣ_２とのソフトウェアインターフェイスは、たとえば、仕様「ＰＣ／ＳＣ」（「第６部、サービスプロバイダ」）によって説明される。層自体、ＣＣ_１およびＣＣ_２は、特に、上述したように、規格ＩＳＯ ７８１６−１から７８１６−４によって説明される。
【０１０３】
補足的ソフトウェア層１６は、応用層（ここには図示されていない）と下層ＣＣ_１およびＣＣ_２との間で、インターフェイスを形成する。この層１６に割り当てられる主要機能は、マルチプレキシング／デマルチプレキシング機能である。
【０１０４】
スマートカード２ａとの通信は、「ＵＮＩＸ」型オペレーティングシステム、すなわちＯＵＶＲＩＲ（「ＯＰＥＮ」）、ＬＩＲＥ（「ＲＥＡＤ」）、ＥＣＲＩＲＥ（「ＷＲＩＴＥ」）、ＦＥＲＭＥＲ（「ＣＬＯＳＥ」）等におけるファイルの操作のために使用されるものと類似のパラダイムに従って行われる。
【０１０５】
スマートカード２ａ側には、類似の構造、すなわち参照符号ＣＣａ_１（物理層）およびＣＣａ_２（データリンク層）が付された２つの低層の存在、さらには層１６とまったく同じインターフェイス層２６ａが見られる。
【０１０６】
本発明によれば、両側に、すなわち端末１およびスマートカード２ａにおいて、特有の２つのプロトコル層、つまり、それぞれ１３および２３ａが備えられる。
【０１０７】
端末１においては、特有の層１３は、マルチプレキシング層１６を介して、「ドライバ低層」１５、ネットワーク層Ｃ_３およびＣ_４のライブラリ１４、さらに、カード読取装置３のプロトコル層、すなわち下層ＣＣ_１およびＣＣ_２とインターフェイスしている。特有の層１３は、スマートカード２ａから、またスマートカード２ａに向かって、ネットワークパケットの転送を可能にする、さらに、この層は、スマートカード２ａを利用する用途に、インターネットブラウザ１０や電子郵便等のような既存のアプリケーションを適合させる。
【０１０８】
スマートカード２ａ側には、層１３と対をなして、参照符号２３ａが付された特有の層の補足的インスタンスで構成されたまったく同様の構造が見られる。
【０１０９】
より厳密には、特有の層１３および２３ａは、以下の３つの主要なソフトウェアエレメントに細分割される。
【０１１０】
− 従来の層ＣＣ_１、ＣＣ_２、ＣＣａ_１およびＣＣａ_２を介する、層１３と２３ａの間の情報ブロックの転送モジュール１３０または２３０ａ、
− たとえば、プロトコルの変換機能を実行する「インテリジェントエージェント」１３２または２３２ａと呼ばれる１つまたは複数のソフトウェア、
− 個別のインテリジェントエージェントと同一視することができるモジュールである、特有の構成の管理モジュール１３１および２３１ａ。
【０１１１】
以下、簡略化するために、先述したように、インテリジェントエージェントを「エージェント」と呼ぶ。
【０１１２】
したがって、端末１とスマートカード２ａ内に、２つのエンティティ間の通信プロトコルスタックが見られる。
【０１１３】
レベル２の層（データリンク層）ＣＣ_２およびＣＣａ_２は、スマートカード２ａと端末１との間の交換を行う。それらの層は、伝送エラーの検出と、場合によっては補正を行う。種々のプロトコルが使用可能であり、以下は限定的ではなく、あくまで例示的なものである。
【０１１４】
− 勧告ＥＴＳＩ ＧＳＭ１１．１１、
− キャラクタモードＴ＝０における、規格ＩＳＯ ７８１６−３によって規定されたプロトコル、
− ブロックモードＴ＝１における、規格ＩＳＯ ７８１６−３によって規定されたプロトコル、または
− フレームモード「ＨＤＬＣ」（「Ｈｉｇｈ−Ｌｅｖｅｌ Ｄａｔａ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ｐｒｏｃｅｄｕｒｅ」の略）において、規格ＩＳＯ ３３０９によって規定されるプロトコル。
【０１１５】
本発明の枠組みにおいては、好ましくは、ブロックモードにおけるプロトコルＩＳＯ ７８１６−３が使用される。
【０１１６】
それ自体良く知られている方法で、各プロトコル層に対して、同レベルの層間、さらに層から層へのデータの交換を可能にする一定数のプリミティブが関連付けられる。例として、レベル２の層に関連付けられるプリミティブは、カードによる「データ要求（「Ｄａｔａ．ｒｅｑｕｅｓｔ」）および「データの確認」（「Ｄａｔａ．ｃｏｎｆｉｒｍ」）等の型である。
【０１１７】
より特有の方法では、層１３および２３ａは、スマートカード２ａとホスト、すなわち端末１との間の対話を担当する。それらの層は、たとえば、「ＨＴＭＬ」フォーマットにおけるハイパーテキストの形で実行されるメニュを介して、端末１のユーザ（図示せず）とスマートカード２ａとの間の情報交換を可能にする。それらはまた、データパケットの送信および／または受信のために適合した構成の設置を可能にする。
【０１１８】
上述したように、層は３つの別々のエンティティを有する。
【０１１９】
第一の層１３０または２３０ａは、主に、ソフトウェアマルチプレクサで構成される。それは、プロトコルのデータユニットの形で、スマートカード２ａとホスト端末１との間の情報交換を可能にする。第一の層は、データパケットの交換器と類似の役割を果たす。それらのユニットは、レベル２の層（データリンク層）を介して送信または受信される。この通信用の個別プロトコルは、少なくとも一対のエージェントの連絡を確立させることができる。各対の第１のエージェント１３２は、端末１側の層１３内に位置し、第２のエージェント２３２ａは、スマートカード２ａ側の層２３ａ内に位置する。２つの「エージェント」間のリンクは、「Ｓ−エージェント」と呼ぶことができるセッションに関連付けられる。セッションは、これら２つのエージェント間の双方向データ交換である。層１３および２３ａのいずれか一方が、複数のエージェントを有する場合には、同一層のエージェントはまた、互いの間で、および／または、個別のエージェントを構成するモジュール１３１および２３１ａとのセッションを確立することができる。
【０１２０】
より厳密には、エージェントは、端末１によって実施される構成に応じて、レベル３および４の層の機能の全体または一部を実行することができる独立ソフトウェアエンティティである。
【０１２１】
エージェントは、個別の特性または属性に関連付けられる。分かりやすくするために、限定的でなく例示的なものとして、以下の６つの特性がエージェントに関連付けられる。
【０１２２】
− 「ホスト」：端末内で探索されるエージェント
− 「カード」：スマートカード内で探索されるエージェント
− 「ローカル」：ネットワークと通信しないエージェント
− 「ネットワーク」：ネットワークと通信するエージェント（端末側）
− 「クライアント」：セッションを初期化するエージェント
− 「サーバ」：セッションの要求を受取るエージェント
個別のエージェントは、リファレンス、たとえば１６ビットの整数によって識別される（すなわち、０から６５５３５の間）。上位ビット（ｂ１５＝１）は、リファレンスがローカルであるか（スマートカードまたは端末へのローカル通信）、または、遠隔であるか（ｂ１５＝０）を示す。
【０１２３】
エージェントには２つの大きなカテゴリが存在する。固定リファレンスによって識別される「サーバ」型のエージェントと、構成管理モジュールによって付与される一時的と形容されることもある可変リファレンスによって識別される「クライアント」型のエージェント１３１または２３１ａである。
【０１２４】
エージェントは、宛先リファレンスとソースリファレンスとを構成する「プロトコルデータユニット」または「ｐｄｕ」（英語「ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉ」の略）と呼ばれるエンティティを用いて互いに通信する。さらに、この「ｐｄｕ」を、一般に使用されている英語「Ｓｍａｒｔ Ｃａｒｄ」を参考にして、「ＳｍａｒｔＴＰ ｐｄｕ」と呼ぶこともできる。「ｐｄｕ」は、特に、以上に規定したリファレンスを使用する。
【０１２５】
「ＳｍａｒｔＴＰ ｐｄｕ」または、以下、より簡単に「ｐｄｕ」は、「ｐｄｕ」の性質を明示する以下のようなフラグおよびオプションのデータを構成する、ソースリファレンス、宛先リファレンス、ビット集合を有する。
【０１２６】
− 「ＯＰＥＮ」（開始）フラグは、セッション開始を示すために位置決めされる。
【０１２７】
− 「ＣＬＯＳＥ」（閉鎖）フラグは、セッションの閉鎖を示す。
【０１２８】
− 「ＢＬＯＣＫ」（鎖錠）フラグは、エージェントが、その通信相手の応答を待っている状態であり、あらゆる活動を一時停止することを示す。
【０１２９】
データをもたない「ｐｄｕ」はトークンと呼ばれる。
【０１３０】
「ＳｍａｒｔＴＰ」エンティティは、宛先エージェントの存在をコントロールし、そのエージェントに向かってパケットの通信を実行する。
【０１３１】
セッションエージェント「Ｓ−Ａｇｅｎｔ」は、３つの注目すべき状態を有する。すなわち、
− 接続解除されている状態。いかなるセッションも他のエージェントには開始されていない。
【０１３２】
− 接続されている状態。セッションが他のエージェントに開始されている。「Ｓ−Ａｇｅｎｔ」セッションは、一対のリファレンスによって識別される。
【０１３３】
− ブロックされている状態。エージェントが接続され、その通信相手の応答を待つ状態。
【０１３４】
「Ｓ−エージェント」セッションの確立メカニズムは、以下の通りである。
【０１３５】
− クライアントエージェントの新しいインスタンスが創設され（スマートカードまたは端末側）、このエージェントは、擬似単一一時リファレンスによって識別される。
【０１３６】
− クライアントエージェントは、位置決めされた「ＯＰＥＮ」フラグとともにサーバエージェント（そもそも、そのリファレンスはすでに知られている）宛てに「ｐｄｕ」を送信し、クライアントエージェントは、「ブロック」フラグの値に従って接続またはブロックされる状態に移行する。さらに
− サーバエージェントは、「ＯＰＥＮ」フラグとともに「ｐｄｕ」を受け取り、接続された状態に移行する。
【０１３７】
いったんセッションが開始されると、２人のエージェントが「ｐｄｕ」を介してデータを交換する。
【０１３８】
セッションの閉鎖メカニズムは以下の通りである。
【０１３９】
− エージェントは、場合によってはデータを有する、位置決めされたフラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を送信する。
【０１４０】
− 他のエージェントは、（場合によってはデータを有する）位置決めされたフラグ「ＣＬＯＳＥ」とともに「ｐｄｕ」を受取り、「Ｓ−Ａｇｅｎｔ」セッションは、接続解除された状態に移行する。
【０１４１】
図４は、上述したような「Ｓ−Ａｇｅｎｔ」セッションの状態のフローチャートを概略的に表わしている。
【０１４２】
層１３０および２３０ａは、ホスト端末１およびスマートカード２ａ側で、存在するエージェントリストを含む表（ここには図示されていない）を管理する。
【０１４３】
実際に、エージェントは、（たとえば、ハイパーテキストの）データの交換を可能にするが、しかも、スマートカード２ａと遠隔サーバ４との間の通信を許可する、ネットワークトランザクションを開始することができる（図３）。
【０１４４】
構成管理モジュール、それぞれ１３１および２３１ａは、個別のエージェントと同一視することができる。たとえば、ホスト端末１側のモジュール１３１は、特に、この端末の構成（作動モード）に関連する情報、たとえば他のエージェントリスト等を管理する。スマートカード２ａ側のモジュール２３１ａは、類似機能を有する。これら２つのエージェントは、セッションを確立するために互いに通信を確立することができる。
【０１４５】
実際に、スマートカード２ａは、有利には、外部サーバへのポインティングではなく、端末１それ自体へのループバックを規定する「ＵＲＬ」アドレス（「Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」の略）の使用によって「アドレシング」される。例として、この「ＵＲＬ」の構造は通常以下の通りである：
ｈｔｔｐ：／／１２７．０．０．１：８０８０ （１）
ここで、１２７．０．０．１は、ループバックの「ＩＰ」アドレスであり、８０８０は、ポート番号である。
【０１４６】
図５は、図３に示された型の本発明によるシステムの論理アークテクチャを簡略に、しかもより詳細に表している。スマートカード２ａは、複数のエージェントを有するが、そのうちの２つだけがここに図示されている。厳密には規定されていない型のエージェント２３２ａ_１と「ＷＥＢ」型と呼ばれるエージェント２３２ａ_２である。論理スタックは、規格ＩＳＯ ７８１６−３に合致した参照符号２００ａを付された、プロトコル下層（図２：ＣＣａ_１およびＣＣａ_２）と、コマンド管理「ＡＰＤＵ」２０１ａ_１と、パケットのマルチプレクサ２３０ａとを有し、このマルチプレクサは、エージェント、特に「ＷＥＢ」エージェント２３１ａ_２にインターフェイスされる。
【０１４７】
端末１側には、２つのスタックが存在するが、一方はインターネットＲＩと通信し、他方はスマートカード２ａと通信する。第１のスタックは、ネットワーク（規格ＯＳＩ １および２）へのアクセス機構１１（図２：Ｃ_１およびＣ_２）と、参照符号１００が付されたプロトコル「ＴＣＰ／ＩＰ」（図３：Ｃ_３およびＣ_４）層とを有する。それらの層は「ＷＥＢ」ブラウザ１０とインターフェイスされる。他方のスタックは、規格ＩＳＯ ７８１６−３に合致した参照符号１０１が付されたプロトコル下層（図３：Ｃ_１およびＣ_２）と、命令管理「ＡＰＤＵ」１０２と、パケットマルチプレクサ１３０とを有し、このマルチプレクサはエージェントとインターフェイスされるが、そうちの１つだけ、１３２がここに図示されている。このエージェントは「ネットワーク型」と想定され、さらに、一方では「ＴＣＰ／ＩＰ」層１０１を介して、ブラウザ１０と、他方では、それら「ＴＣＰ／ＩＰ」層１０１とネットワークＲＩへのアクセス機構１１とを介してインターネットＲＩと通信することができる。
【０１４８】
命令管理「ＡＰＤＵ」２０１ａはまた、単にアプリケーションと呼ばれるアプリケーションレベルの１つまたは複数の層とインターフェイスされる。それらアプリケーションＡ_１…、Ａ_ｉ…、Ａ_ｎ…、は、すでに示したように、従来型のアプリケーションである。
【０１４９】
要約すると、スマートカード２ａによって与えられる「ＷＥＢ」サーバ／クライアント機能は、すでに説明したように、スマートカード内の「ＷＥＢ」エージェント２３２ａ_１と、端末１内のネットワークエージェント１３２との関連付けによって、また、エージェント間のセッションによって実行することができる。
【０１５０】
したがって、スマートカード２ａは「ＷＥＢ」クライアント／サーバ機能を明確に表している。さらに、本発明によると、上記の「ＣＧＡ」型の従来のどんなアプリケーションＡ_１からＡ_ｎも、この「ＷＥＢ」クライアント／サーバを通して、端末１内に存在する「ＷＥＢ」ブラウザ１０によって、もしくは、エージェント間のセッションの実施によって、インターネットＲＩの何らかのポイントで探索された遠隔ブラウザ４によって、起動することができる。本発明の方法によれば、アプリケーションＡ_１からＡ_ｎは、書き直す必要なく、そのまま利用することができる。
【０１５１】
本発明の枠組みにおいては、アプリケーション、Ａ_１からＡ_ｎの全体または一部は、上記のプロトコル「ＰＥ」、「ＰＬ」の１つまたはいくつかに関連付けられるアプリケーションによって構成され、スマートカード２ａのメモリ内にロードすることができる。さらに、１つまたは複数の「ＰＡ」プロファイルを表わすデータも、スマートカード２ａ内に保存される。
【０１５２】
スマートカード２ａによって与えられる「ＷＥＢ」クライアント／サーバ機能だけでは、１つのアプリケーションを実行するのに十分ではない。さらに補足機能を付け加える必要がある。
【０１５３】
というのも、本発明の他の様態によれば、スマートカード２ａによって与えられる「ＷＥＢ」クライアント／サーバ機能は、従来の「ＷＥＢ」サーバ内に設置された「ＣＧＩ」（「Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ−共通ゲートウェイインターフェイス」の略）と呼ばれる機能に類似のメカニズムを含む。
【０１５４】
スマートカード内であっても、この型の機能を実行できる本発明に合致したアーキテクチャの一例を示す前に、「ＣＧＩ」作動モードの主要な特徴を思い起すことが有益である。
【０１５５】
「ＣＧＩ」は、オペレーティングシステム「ＵＮＩＸ」（登録商標）、「ＤＯＳ」、または「ＷＩＮＤＯＷＳ」（商標）のために書き込まれたアプリケーションの「ＷＥＢ」サーバからの実施仕様である。例として、「ＵＮＩＸ」オペレーティングシステムについては、仕様は「ＣＧＩ １．１」であり、「ＷＩＮＤＯＷＳ９５」オペレーティングシステムについては、仕様は「ＣＧＩ １．３」である。
【０１５６】
常に例示的なものとして、「ホスト」がホストシステム（一般に遠隔）を参照する、
「ｈｔｔｐ：／／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｘｘｘ．ｃｇｉ」 （２）
の型の「ＵＲＬ」アドレスについての要求「ＨＴＴＰ」は、「ｘｘｘ」と名付けられ、このホストシステムのディレクトリ内に存在する「ＣＧＩ」型のコマンドスクリプトの実行として、「ＷＥＢ」サーバによって解釈される。ディレクトリの名前は、先験的に何でもよいにもかかわらず、それは、従来、「ＣＧＩ」型のスクリプトを保存するディレクトリに与えられる名前である。スクリプトは、ホストシステムのオペレーティングシステムの命令セットであり、その最終的結果は、上記の要求を送信する「ＷＥＢ」ブラウザに伝送される。このスクリプトを書き込むために、種々の言語、たとえば「ＰＥＲＬ」言語（登録商標）を使用することができる。
【０１５７】
実際には、要求は、通常、「ＨＴＬＭ」ページ内に含まれる書式の形で情報処理スクリーンに表示される。「ＨＴＬＭ」言語は、書式を「ＵＲＬ」アドレスに翻訳することができる。書式は、強制的または非強制的に１つまたは複数のフィールドを有し、それらは、通常の入力手段、すなわち、テキスト用にはキーボード、チェックボックスにはマウス、または「ラジオ」と呼ばれるボタン等を用いてユーザによって書き込まれる。書式の内容（さらに、場合によっては「隠し」情報と呼ばれる情報および命令）は、「ＷＥＢ」サーバ宛てに送信される。ページの「ＨＴＬＭ」コードは、書式のハードウェア構造（枠、デザイン、色、他のあらゆる属性）、ならびにインプットされるデータフィールドの構造（名称、長さ、データの型等）を説明する。
【０１５８】
伝送は、２つの型の主要なフォーマットに従って行うことができる。最初のフォーマットは、「ＰＯＳＴ」と呼ばれる方法を使用し、第２のフォーマットは「ＧＥＴ」と呼ばれる方法を使用する。フォーマット型情報は、書式ページのコード内に存在する。
【０１５９】
しかしながら、このメカニズムは、スマートカードが、本発明の特徴のいずれか１つに従って「ＷＥＢ」クライアント／サーバ機能を提供するとしても、直接スマートカードに移し替えられるわけではない。
【０１６０】
ここで、図６を参照して、スマートカードにおける「ＷＥＢ」サーバを介して、従来型の何らかのアプリケーションを起動することができるアーキテクチャの一例を説明しよう。
【０１６１】
本発明の様態の１つに従って備えられたインテリジェントエージェントの中には、以下、「スクリプト変換エージェント」、または略して「ＡＴＳ」と呼ばれる個別のインテリジェントエージェントが備えられる。こうして、スクリプトは、これら「ＡＴＳ」エージェントの１つによって解釈される。この翻訳は、以下のように種々の方法で実行することができる。
【０１６２】
ａ．この場合、二重の容量を備える、「ＷＥＢ」エージェント２３２ａ_１によって、
ｂ．スマートカード２ａ内に存在するスクリプトの集合を翻訳することができる単一のスクリプトエージェントによって、
ｃ．以下「ＡＴＳＤ」と呼ばれる専用スクリプトエージェント（スクリプトごとに１つのエージェント）によって、または
ｄ．その場合、二重の容量を備えた、命令管理「ＡＰＤＵ」２０１ａの「ＡＰＤＵ」エージェント２０１０ａによって。
【０１６３】
「ＡＰＤＵ」エージェント２０１０ａは、命令管理「ＡＰＤＵ」層２０１ａの構成要素である。この層は、システムによって送信および／または受信されるあらゆる「ＡＰＤＵ」命令を集中させ、Ａ_１からＡ_ｎの中からアプリケーションを選別し、しかもインテリジェントエージェント型のインターフェイスを提供することができる層である。したがって、本発明の特徴の１つによれば、それらエージェントが端末１内で探索されようと、スマートカード２ａ内で探索されようと、あらゆるインテリジェントエージェントと通信することができる。
【０１６４】
上記のｃ．の場合には、セッションは、「ＷＥＢ」エージェント２３２ａ_１と「ＡＴＳＤ」エージェントの１つとの間で開始される。
【０１６５】
図６は、変換エージェントが「ＡＴＳＤ」型であるようなアーキテクチャの一例を表している。それらは、参照符号ＡＴＳ_１からＡＴＳ_ｎが付されているが、アプリケーションＡ_１からＡ_ｎに関連付けられる。選別されたアプリケーションは、アプリケーションＡ_ｉであると想定されるので、セッションは「ＷＥＢ」エージェント２３２ａ_１とエージェントＡＴＳ_ｉとの間に確立される。
【０１６６】
スクリプト変換エージェントは、命令セット「ＡＰＤＵ」を発生する。セッションは、変換エージェント、たとえばエージェントＡＴＳ_ｉと「ＡＰＤＵ」エージェント２１０１ａの間で開始される。こうして、命令は、「ＡＰＤＵ」命令２１０１ａに向かって送信される。命令管理「ＡＰＤＵ」２１０ａは、「ＣＧＡ」アプリケーションＡ_ｉを選別し、そのアプリケーションが理解することができる命令「ＡＰＤＵ」、翻訳された命令、すなわち従来の命令をそのアプリケーションに伝達する。したがって、このアプリケーションは、それを変更するまたは再び書き込みする必要なく、正確に起動される。
【０１６７】
アプリケーションＡ_ｉの応答は、命令管理「ＡＰＤＵ」２１０ａ、「ＡＰＤＵ」エージェント２０１０ａに、さらに再びエージェントＡＴＳ_ｉ（一般的にはスクリプト変換エージェントに）に伝送される。
【０１６８】
種々の経路が、関数型ブロックをつなぐ実線によって、またはこれらブロックの内部の点線によって図６に記号で表されている。
【０１６９】
１つまたは複数のディレクトリサーバにおける加入登録オペレーションおよび／または着呼側加入探索を実施するために、本発明による方法は、上記の２つの特徴、すなわち、「ＣＧＩ」機能を含む、「ＷＥＢ」サーバ／クライアントとしてスマートカードの作動を利用する。
【０１７０】
本発明の好ましい実施形態によれば、加入登録プロトコル「ＰＥ」および／または加入探索プロトコル「ＰＬ」に関連付けられるアプリケーション、さらに１つまたは複数の加入プロファイルは、スマートカード２ａ内に登録される。
【０１７１】
ここで、図７Ａから９を参照して、加入者登録および／または着呼側加入者探索のための本発明による方法の種々の段階およびステップを、より詳細に説明しよう。
【０１７２】
第１のステップは、以下の参照符号ＳＡ_ｉが付される個別のディレクトリサーバ内の加入者プロファイルの登録に関するものである。このディレクトリは、従来の技術に合致したディレクトリであり（たとえば図１：９１）、本発明による方法は、既存の方法と完全に互換性をもったままである。
【０１７３】
図７Ａに表された第１のステップにおいては、スマートカード２ａは、層１３および２３ａを介して、端末１のブラウザ１０によってアドレシングされる。たとえば、「ＧＥＴ」型のコマンドによって、スマートカード２ａからのロード書式、すなわち恣意的に「ｄｏｗｎｌｏａｄ．ｈｔｍｌ」と呼ばれる書式「ＨＴＭＬ」をリトリーブする。
【０１７４】
このリトリーブは、ＵＲＬが通常、以下の形をとる、対応ページを閲覧することによって行われる。
【０１７５】
ｈｔｔｐ：／／１２７．０．０．１：８０８０／ｄｏｗｎｌｏａｄ．ｈｔｍｌ （３）
ｈｔｔｐ：／／１２７．０．０．１：８０８０は、関係式（１）によって規定したような、いわゆるループバックのＵＲＬアドレスであり、「ｄｏｗｎｌｏａｄ．ｈｔｍｌ」は、得られる「ＨＴＭＬ」ページである。この要求は、本発明の第１の様態による、図２から４を参照してすでに説明したように対になったエージェント間のセッションを利用する。
【０１７６】
スマートカード２ａは、常に、本発明の方法による、対をなすインテリジェントエージェント間のセッションの開始によって、第２ステップの場合に書式「ｄｏｗｎｌｏａｄ．ｈｔｍｌ」を送信する。得られた書式は、ブラウザ１０を介して、スクリーン５ａに表示することができ、このプロセスを概略的に表わす図７Ａでは参照符号Ｐで表わされる。この書式は、ディレクトリサーバＳＡ_ｉに登録しようとする加入者のための受入れページを構成する。こうして、スマートカード２ａは、「ＷＥＢ」サーバとして行動する。
【０１７７】
ページＰは、通常、グラフィック型および／またはテキスト型の種々のエレメントと、さらにコマンドの相互作用エレメント（「ラジオ」と呼ばれる型のボタン、ダイアログボックス、データの入力ゾーン等）を有することができる。
【０１７８】
まず第一に、スマートカード２ａは、そのキャリア（図示せず）に、ＰＡ_ｕと呼ぶことができる単一の加入プロファイルに従って、ＳＡ_ｕと呼ぶことができる、単一ディレクトリサーバに登録する可能性を与えると想定しよう。さらに、この単一プロファイルＰＡ_ｕは、スマートカード２ａ内に登録される。この仮説において、スクリーン５ａ上に表示される書式Ｐ（すなわち受入れページ）は、最小レイアウトに縮小することができ、図７Ｂは、その可能な一例、書式Ｐ_１を表している。
【０１７９】
書式Ｐ_１は、単一のリファレンスＺ_ｔの下で、テキストの種々のゾーンを有する。これらゾーンは、通常、ディレクトリサーバ（ＳＡ_ｕ）の名「ｘｘｘ」と提案されたアクション「登録」とさまざまなヘルプ（たとえば、ここをクリックしなさい」）を表示する。加入プロファイルＰＡ_ｕのデータがスマートカード２ａ内に登録されていると想定した以上、送信ボタンＢ_ｓを備えればよい。加入者にとって、マウスを用いてこのボタンをクリックする（図２Ａ：６ｂ）、またはキーボードの「エントリー」キーを押すことで（図２Ａ：６ａ）、スマートカード２ａに向かって書式の送信が始まる。
【０１８０】
本発明による方法の他の変形形態においては、加入プロファイルに割り当てられるデータは、その方法によって直接インプットされる。この仮説において、書式はより複雑である。図７Ｃは、参照符号Ｐ_２が付された書式の可能な一例を表している。それは、単一リファレンスＺ_ｔ２の下に、図７Ｂのゾーン（Ｚ_ｔ）に類似の固定テキストの第１ゾーンＺ_ｔ１と、１つまたは複数のデータインプットゾーンとを有する。先述したように、送信ボタンＢ_ｓだけでなく、有利には、エラーの場合にインプットされたデータを消去することができる書式Ｐ_２の再初期化ボタンＢ_ｒａｚが備えられる。１つまたは複数のデータのインプットゾーンは、「ＨＴＭＬ」言語において「ＴＥＸＴＡＲＥＡ」と呼ばれる型であり、長文テキストの表示のために「エレベータ」と呼ばれるファシリティを有することができる。
【０１８１】
このような書式をプログラミングするのに必要な「ＨＴＭＬ」コードは、それ自体良く知られており、当業者に理解される。したがって、ここで、これ以上詳しく説明する必要はない。しかしながら、特に、通常、以下の形をとる「ＨＴＭＬ」言語におけるコードラインを含む点を指摘できる。
【０１８２】
＜ｆｏｒｍ ａｃｔｉｏｎ＝”ｈｔｔｐ：／／１２７．０．０１：８０８０／ｃｇｉ−ｓｍａｒｔ／ｐｅ”＞ （４）
ここで、ｈｔｔｐ：／／１２７．０．０．１：８０８０は、関係式（１）のループバックのＵＲＬであり、「ｃｇｉ−ｓｍａｒｔ」は、たとえば参照符号Ａ_ｅが付された、スマートカード２ａ内に保存されたアプリケーションに関連付けられたスクリプト「ｐｅ」である。このアプリケーションは、プロファイルＰＡ_ｕとともに、ディレクトリＳＡ_ｕへの加入者登録を可能にする。このアクションは、スマートカード２ａによって提供される機能、一方では「ＣＧＩ」、他方ではクライアント／サーバを利用することによって、図５および６を参照して説明した方法で行われる。アプリケーションＡ_ｅは、クライアントとして行動する。
【０１８３】
前者の場合には（図７Ｂ）、パラメータをスマートカード２ａに通す必要はない。というのも、加入者プロファイルデータＰＡ_ｕは、単一であり、スマートカード２ａ内に登録されるからである。
【０１８４】
後者の場合には（図７Ｃ）、インプットされたデータは、要求「ＨＴＴＰ」の形で、パラメータとして、スマートカード２ａを通る。
【０１８５】
図７Ｄは、インターネットＲＩを介して、ディレクトリサーバＳＡ_ｕへの加入者の登録段階の総合的プロセスを、概略的に示している。
【０１８６】
単一リファレンスＳ_ＷＥＢは、図５および６を参照して詳しく述べられた種々のモジュール、すなわち、スマートカード２ａが、クライアント／ＷＥＢサーバとゲートウェイ「ＣＧＩ」とを組み合わせた機能を提供することを可能にするモジュールを包括する。さらに、登録プロトコル「ＰＥ」の利用を可能にするアプリケーションは、専用のスクリプト変換エージェントＡｔ_ｅに関連付けられると想定された。図６に表されたものと合致する構成が対象となる。しかしながら、すでに示したように、スクリプトの翻訳は、他の方法（「ＷＥＢ」エージェント２３２ａ_１により）等で行うこともできる。対になったエージェント間のセッションの開始による、書式の送信は、スクリプト変換エージェントＡｔ_ｅを介して、アプリケーションＡ_ｅを起動することができる。
【０１８７】
その後のステップにおいては、アプリケーションＡ_ｅは、エージェント対の間の、特に「ネットワーク」型のエージェントを関係させるセッションの開始のために要求「ＨＴＴＰ」を出す（図６：１３２）。要求は、パラメータの通過とともに、ディレクトリサーバＳＡ_ｉに伝達される。パラメータは、ディレクトリ内の登録が可能になるように、特に加入者プロファイルデータによって構成される。ディレクトリサーバの「ＵＲＬ」アドレスは、スマートカード２ａ内に登録される加入者プロファイルから、または、書式Ｐ_２内にインプットされるデータから得られる（図７Ｃ）。
【０１８８】
先験的に、登録プロセスは、この段階で終了する。しかしながら、１つまたは複数の補足ステップをもつこともできる。それらのステップの１つは、スマートカード２ａをアドレシングする要求「ＨＴＴＰ」の形で、受信通知のディレクトリによる送信とすることもできる。受信通知は、登録が十分な形で行われたことを示す情報、または反対にエラーコードを含むこともできる。後者の場合には、登録プロセスは、繰り返されなければならない。サーバは、不足データの送信または不正確なまたは改竄されたデータの再送信を要求することができる。登録の要求はまた、特に加入の有効期限が過ぎている場合には、拒否されることもある。
【０１８９】
本発明による方法の好ましい変形実施形態においては、加入者にとっては、複数の異なるディレクトリに登録することが可能である。この変形実施形態においては、一般に、複数の登録プロトコルも使用できるようにすることが必要である。そのためには、それらプロトコルに関連付けられた複数のアプリケーションが、スマートカード２ａ内に保存され、別々のプロトコルの最大数をｎとすると、参照符号Ａ_ｅ１…、Ａ_ｅｉ…、Ａ_ｅｎ…、を付すことができる。
【０１９０】
先述したように、加入者プロファイルに関連付けられたデータＰＡ_１…、ＰＡ_ｉ…、ＰＡ_ｑ…、は、スマートカード２ａ内に保存される、または反対に、適切な書式内にインプットすることによって、図７Ｃを参照して説明したものと類似の方法によって、加入者によってその場その場で与えられることができる。この場合、ｑは、使用可能な加入者プロファイルの最大数である。ｑは必ずしもｎと等しくない点が留意される。というのも、恣意的に参照符号ＳＡ_ｉが付される、任意のディレクトリサーバは、一方では同一加入者の複数の別々の状況を受入れることができる。他方では、複数の加入者サーバが、別々にもかかわらず、同一の加入者プロファイルを受け入れ、場合によっては共通の登録プロトコルを共有することができる。
【０１９１】
ディレクトリサーバ全体または一部の選別を行うために使用される方法にかかわらず、スマートカード２ａに移行したパラメータは、１つまたは複数の加入者プロファイルからＰＡ_ＡからＰＡ_Ｄを選別し、そこから１つまたは複数の「ＵＲＬ」アドレスを派生させることができる。スマートカード２ａに移行されたパラメータによって要求されるアクションは、通常以下の型である。
【０１９２】
？ｓａ_ｉ＝ｅｎｒ＋ｐａ_ｊ （５）
ここで、「Ｓａ_ｉ」は、可能なｎ個の中の任意の指数ｉのディレクトリサーバの名であり、「ｅｎｒ」は、いわゆる登録の要求アクションであり、「ｐａ_ｊ」が可能なｑ個の中から使用される加入者プロファイルである。
【０１９３】
１つまたは複数の要求「ＨＴＴＰ」が出され、当該のディレクトリサーバに伝達されるが、選別可能なｎ個のディレクトリサーバが存在する場合には、ＳＡ_ＡからＳＡ_ｎの参照符号が付される。
【０１９４】
受入れページＰにおける選択は、必然的に、読取装置３内に挿入されたスマートカード２ａに応じて異なる。そこで提示された選択は、スマートカード２ａを所有する加入者に与えられる権利、特に任意のサービスに申し込んだ加入およびそれらの有効期間に左右される。
【０１９５】
本発明による方法の第２の段階、すなわち、何らかの識別子に関連付けられた加入者のインターネットでの探索は、登録段階と非常に類似した方法で行うことができる。
【０１９６】
そのためには、１つまたは複数のサーバに問い合わせることが必要である。また、この加入者の探索の少なくとも１つの特有プロトコル「ＰＬ」を使用できるようにすることが必要である。さらに、問合わせ可能な複数のサーバＳＡ_１からＳＡ_ｎが存在する場合には、登録の場合におけるように、別々の複数の探索プロトコルを使用できるようにすることが必要である。
【０１９７】
それら探索プロトコルは、スマートカード２ａ内に保存されたアプリケーションを用いて実施される。
【０１９８】
探索プロセスは、１つまたは複数のディレクトリサーバＳＡ_ｉへの登録と完全に類似した方法で行われる。唯一の留意すべき例外は、加入者プロファイルＰＡ_ｊが、もはや明白に要求されないという点である。スマートカード２ａに、サーチされている加入者の識別子とディレクトリサーバＳＡ_ｉのアドレス、または、少なくとも、探索プロトコルに関連付けられたアプリケーションがこの「ＵＲＬ」アドレスを決定するのを可能にするパラメータを与えるだけでよい。ただし、加入者プロファイルＰＡ_ｊは、ディレクトリサーバＳＡ_ｉの「ＵＲＬ」アドレスを自動的にそこから派生させるために使用することができる。そのディレクトリサーバを用いて、発呼側加入者は、着呼側加入者を探索しようとする。すでに示されているように、サーチされた加入者の識別子は、そのｅメールアドレス、すなわち通常、以下の形をとるアドレスとすることができる。
【０１９９】
ｐｓｅｕｄｏ＠ｆｏｕｒｎｉｓｓｅｕｒ．ｃｏｍ （６）
ここで、「ｐｓｅｕｄｏ」は、加入者のメールのユーザ名、またはより一般的にはペンネームであり、「ｆｏｕｒｎｉｓｓｅｕｒ．ｃｏｍ」は、インターネットサービスの提供者の名と接尾辞であり、「．ｃｏｍ」は、場合によってはさまざまな接尾辞、「．ｆｒ」、「．ｎｅｔ」等によって置き換えることができる。
【０２００】
図８は、ディレクトリＳＡ_ｉの問合わせによって電話通信を確立しようとする加入者の探索段階の主要なステップを表している。
【０２０１】
第１のステップでは、スマートカード２ａは、層１３および２３ａを介して、端末１のブラウザ１０によってアドレシングされる。たとえば、「ＧＥＴ」型のコマンドによって、参照符号が付された受入れページＰ’の形でスマートカード２ａからのローディング書式がリトリーブされる。この受入れページは、特に、図７Ｃを参照して説明したものと類似の種々の様態をとることができる。１つまたは複数の可能な選択肢が存在するか否かによって、加入者は１つまたは複数のディレクトリサーバを選別し、サーチされる加入者の識別データを提供する。図８では、ただ１つのディレクトリサーバＳＡ_ｉが問合わせ可能であると想定されている。
【０２０２】
ページは、要求「ＨＴＴＰ」の形で、スマートカード２ａに伝達され、プロトコル「ＰＬ」の実施用アプリケーションＡ_Ｉに関連付けられたスクリプト変換エージェントＡｔ_Ｉによって解釈される。
【０２０３】
クライアント／「ＷＥＢ」と「ＣＧＩ」サーバの二重のメカニズム（先述したように、参照符号Ｓ_ｗｅｂが付されたモジュール）によって、以下の型の要求は、
ｈｔｔｐ：／／１２７．０．０．１／？ ｓａ_ｉ＝ｌｏｃ＋ｐｓｅｕｄｏ＠ｆｏｕｒｎｉｓｓｅｕｒ．ｃｏｍ （７）
スマートカード２ａによって、識別子がディレクトリサーバＳＡ_ｉ上（６）であるような、加入者の探索要求として解釈される。
【０２０４】
要求「ＨＴＴＰ」は、要求された情報が入手可能である限りにおいて、要求された情報を送り返すこのサーバに伝達される。このサーバは、受け取った識別データに対応する「ＩＰ」アドレスをそのデータベース内でサーチする。成功した場合、すなわち、要求側加入者が実際に登録されており、その加入者がこのアドレスを取得する権利を有し、さらに受け取ったデータが正確である場合には、再伝送されたデータは、サーチされた加入者の「ＩＰ」アドレスを含み、そのことからその加入者を探索することが可能になる。
【０２０５】
それら種々の段階は、本発明の１つの様態に従って、対をなすエージェント間のセッションを実施する。
【０２０６】
さらに、スマートカード２ａの枠の中に複数のアプリケーションを保存することができ、各々は、別々のディレクトリサーバに先験的に関連付けられた、別々の探索プロトコルの実施用である。
【０２０７】
本発明による好ましい他の変形実施形態によれば、スマートカード２ａ内に、複数の登録プロトコルと複数の探索プロトコルの実施を可能にするアプリケーションと、複数の加入者プロファイルの登録のための加入者ファイルとを保存する。こうした有利な措置から、スマートカード２ａを、マルチディレクトリポータブルデータベースに変えることが可能になる。
【０２０８】
本発明による方法のさらに他の変形実施形態においては、スマートカード２ａの仕様は、登録段階および／または探索段階の際に、その所有者の確固たる認証を可能にする。というのも、その所有者が所有しているままのスマートカード内に安全性データを保存することが可能だからである。このような安全性データは、暗号化の鍵によって構成することができる。
【０２０９】
本発明による方法の有利な様態の１つによれば、スマートカード２ａは、エージェント間のセッションの実施によって、インターネットと直接通信できることから、それらのデータは、端末１であったとしても、外部装置に伝送される必要がない。安全性に関わる処理は、スマートカード２ａによって直接行われる。したがって、こうした方法は、英語で「ＳＳＬ」（「Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ」の略）の略語で知られている、最近の「ＷＥＢ」ブラウザの安全化されたと言われるソフトウェア層の単純な使用よりはるかに高い安全度を与える。
【０２１０】
いわゆる認証は、スマートカード２ａ内に保存された上記の暗号化の鍵と関連させることによって、証明書と呼ばれる技術に頼ることによって行うことができる。この手続きは、インターネットＲＩを通過する要求「ＨＴＴＰ」を用いて、１つまたは複数の当該のディレクトリサーバとスマートカード２ａとの間の補足的トランザクションを必要とすることができる。認証の肯定的または否定的な結果に応じて、加入者は、実行しようとする処理、登録または探索を行うことを許可される、または許可されない。
【０２１１】
本発明の他の様態によれば、再びインテリジェントエージェントに頼ることによって、スマートカード２ａ上に直接、「プロキシＴＣＰ／ＩＰ」と呼ばれる機能を設置する。この機能は、以下「フィルタ」と呼ばれる独自のソフトウェアアプリケーションによって実行される。
【０２１２】
「プロキシ」機能は、インターネットアプリケーションの領域においてよく知られているが、従来の技術によるシステムのスマートカード内に設置することができない。
【０２１３】
本発明に合致するアーキテクチャを説明する前に、まず第一に、図９を参照して、従来の技術による従来の「プロキシ」の特徴を簡単に思い起こしてみよう。
【０２１４】
「ＴＣＰ／ＩＰ」テクノロジーにおいて、一方では「ＴＣＰ／ＩＰ」サーバＳｖと、「ＴＣＰ／ＩＰ」クライアントＣｌを実行するソフトウェアエンティティＰｙを「プロキシ」と名づける。ソフトウェアエンティティＰｙは、ローカルクライアントと他の遠隔「ＴＣＰ／ＩＰ」サーバとの間の接続を実施する。
【０２１５】
プロキシＰｙは、通常は、フィルタおよび／または安全性機能を行う。たとえば、ある企業では、「ＨＴＴＰ」プロキシは、一般に、ブラウザ、たとえば端末１のブラウザ１０を、「ＷＥＢ」サーバ４に接続する（そのことは「ファイアウォール」または「防火壁」の名で知られている）。同じく、インターネットＲＩを通して安全化されたトンネルの確立に必要な安全性オペレーション（認証−機密性−完全性）を実行する、端末におけるローカル「プロキシ」として定義することができる、「ＳＳＬ」と呼ばれるプロキシを対象とすることができる。
【０２１６】
ここで、図１０を参照して、本発明の補足的な様態に従って、スマートカードの中に直接「プロキシ」機能を組み入れる論理アーキテクチャについて説明しよう。
【０２１７】
先の図に共通のエレメントは、同じ参照符号を付すとともに、必要がある場合にのみ再び説明する。説明を簡単にするために、端末１側のエージェントは、単一の参照符号１３２に包括し、スマートカード２ａ側のエージェントは、単一参照符号２３２ａに包括した。それらは、以下では、添数に関連付けられた文字、「端末」については文字「Ｔ」、「スマートカード」については文字「Ｓ」によって違いを表わす。スマートカード２ａ上で実行される「プロキシ」２７は、以下、「スマートプロキシ」と呼ぶ。
【０２１８】
「スマートプロキシ」２７は、以下に記載するように、４つのエージェント、２つは端末側のＴ_１およびＴ_２、２つはスマートカード２ａ側のＳ_１およびＳ_２と、フィルタ機能との結びつきによって実行される。
【０２１９】
− 「端末／クライアント／ネットワーク」エージェントＴ_１は、ＴＣＰ／ＩＰサーバを実行する（たとえばポート８０８０上で）。
【０２２０】
− 「カード／サーバ／ローカル」エージェントＳ_１は、セッションによってエージェントＴ_１に関連付けられ、このエージェントは通常、「ＷＥＢ」サーバの機能を実行する。
【０２２１】
− エージェントＴ_１から出された情報に応じて決定されるフィルタ機能２８。この機能は、エージェントに向かって、またエージェントＳ_１およびＳ_２から「ｐｄｕ」を送信または受信することができる。
【０２２２】
− 「カード／クライアント／ローカル」エージェントＳ_２、このエージェントのインスタンスは、フィルタ機能２７によってダイナミックに創り出され、Ｓ_２は、「ネットワーク」エージェントＴ_２とのセッションを開始し、そのエージェントに、Ｓ_２が接続しようとしているインターネット遠隔サーバのアドレス４が示される。
【０２２３】
− 「端末／サーバ／ネットワーク」エージェントＴ_２は、インターネットサーバ４に接続される、「ＴＣＰ／ＩＰ」クライアントの機能を実行する。
【０２２４】
以下に、「スマートプロキシ」の創設メカニズム２７について述べる。
【０２２５】
以下「ｃＴＣＰ」と呼ぶ「ＴＣＰ」クライアント、通常「ＷＥＢ」ブラウザ１０は、「ネットワーク」エージェントＴ_１との接続を開く。次にセッションＴ_１−Ｓ_１がつくりだされる、たとえば、以下のＵＲＬは、
ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｘｘｘ．ｃｏｍ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （８）
エージェントＴ_１およびＳ_１間のセッションの開始を引き起こす。
【０２２６】
Ｔ_１およびＳ_１によって交換されたデータから、エージェント（ＷＥＢサーバ）Ｓ_１に関連付けられたアプリケーションは、どのフィルタ機能２８が使用されなければならないかを決定する。このようにして「ｄｅｓ１」は、個別のフィルタの名であり、「ｘｘｘ．ｃｏｍ」は、インターネットサーバ、たとえばサーバ４の任意の名であり、「８０」はポート番号であり、「／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ」は、この例では「ＨＴＭＬ」言語におけるページによって構成される、このサーバ上のファイルの任意の名である。この例においては、フィルタ「ｄｅｓ１」は、「ＤＥＳ」（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｙｓｔｅｍの略）型のアルゴリズムによる暗号解読および／または暗号化オペレーションを行うことができるフィルタである。本発明の枠組みの中では、サーバ４は、ディレクトリサーバによって構成される（たとえば、図７Ｄおよび８ではＳＡ_ｉ）。
【０２２７】
言い換えれば、関係式２によって規定されたＵＲＬ「カード」は、外の世界に向けての他のＵＲＬをカプセル化し、このＵＲＬの第１の部分は、関係式（１）によって規定したようなループバックのＵＲＬで構成される。
【０２２８】
フィルタ２８「ｄｅｓ１」は、クライアントのインスタンスＳ_２を創設し、セッションはエージェントＳ_２およびＴ_２の間で開始される。第１の「ｐｄｕ」内に挿入されたデータ（「ｐｄｕ ＯＰＥＮ」）は、インターネットサーバの名（「ｘｘｘ．ｃｏｍ」）とその関連付けられたポートの番号（８０）を明示する。
【０２２９】
エージェントＴ_２は、「ｓＴＣＰ」遠隔サーバ（「ｚｚｚ．ｃｏｍ」）との「ＴＣＰ」型の接続を開始する。この接続がいったん確立されると、Ｓ_２宛てにトークンが送信される。
【０２３０】
これらの交換が終わると、「スマートプロキシ」２７が創設され、スマートカード２ａ内にあるフィルタ機能２８が、「ネットワーク」エージェントが受け取ったデータ（インターネットＲＩから出た）を処理することができる。フィルタ２８は、「ネットワーク」エージェントＴ_１およびＴ_２によって送信されたデータを論理的に制御する。それは、「ｃＴＣＰ」クライアントと「ｓＴＣＰ」サーバとの間で交換されたデータを制御する「ＴＣＰプロキシ」として行動する。
【０２３１】
分かりやすくするために、図１０に、種々のエージェントの任意の参照符号を表している。固定エージェントは２と５、サーバ型エージェントはそれぞれ、Ｔ_２およびＳ_１、さらに、可変またはイフェメラルエージェントは「１５３６０」および「２５５９」、クライアント型エージェントは、それぞれ、Ｔ_１およびＳ_２となる。
【０２３２】
他の型のフィルタもスマートカード２ａ内に設置することができる。こうして、それらフィルタは、個別の特徴をもつルーティング経路の予約交渉または暗号化の鍵の交換交渉を実施するために使用することができる。例として、発呼側加入者が、高容量のマルチメディアファイル、または大量のデータを伝送したい場合には、有償であっても、最小限の通過周波帯および／またはトラフィックが場所を取らないことの保証を得たいと考える。
【０２３３】
厳密には、スマートカード２ａ上の他の型のフィルタは、従来は、交換されたデータの容量または数量に基づいて、しかもシグナリング段階中にサービス提供者と交渉された経路の型に基づいて行われていた料金決定機能を行うことができる。そのためには、それ自体良く知られているように、主に、カウンタが使用される。
【０２３４】
いったん加入者が探索されると、スマートカード２ａ内に直接設置された「プロキシ」機能が、発呼側加入者と探索された着呼側加入者との間のいわゆるデータの交換および／またはシグナリングオペレーションに対応するステップのために使用される。
【０２３５】
発呼側加入者によって使用される本発明による方法は、着呼側加入者もまたその同じ方法を利用することを要求しない点がきちんと理解されなければならない。というのも、加入者のいずれか一方、たとえば着呼側加入者は、従来の技術に合致した標準端末を使用できるという点が、本発明の補足的な利点だからである（図１：９ｂ）。特に、この端末がスマートカードの読取装置を備えていることは必要ない。言い換えれば、少なくとも、発呼側または着呼側という加入者のいずれか一方に関連付けられた設備の一方に関しては、本発明による方法は、既存の電話ハードウェアおよびソフトウェアと完全な互換性をもち、他方の設備は、本発明の方法に合致するためにはほんの少しの改良しか必要としない。
【０２３６】
しかしながら、本発明の好ましい変形実施形態においては、発呼側加入者と着呼側加入者、両方ともが、本発明による方法を利用する端末を使用するという場合を想定してみよう。以下、「発呼」側は、恣意的に参照文字「ａ」で示され、「着呼」側は、参照文字「ｂ」で示される。
【０２３７】
図１１Ａは、発呼側加入者Ａａも、着呼側加入者Ａｂも、信号経路ＣＳ用の「プロキシ」機能を利用する電話のシステムのアーキテクチャを概略的に表している。
【０２３８】
この図において、説明しやすくするために、発呼側端末１ａおよび１ｂは、「ＰＳＰ」シグナリングプロトコル、それぞれ９０２ａおよび９０２ｂに関連付けられるソフトウェアのみに縮小している。それらソフトウェアは、先験的に従来の技術の対応するソフトウェアに合致する（図１参照）。
【０２３９】
しかしながら、「プロキシ」機能は、本発明による方法を利用するインターネットスマートカードをサポートすることができるように、それらを適合させることを必要とする場合もある。少なくとも、以下に示すように、それらは、シグナリングポート（「ＴＣＰ」型）を変更できるように、パラメータ化されることができなければならない。市販の標準版における特定の電話ソフトウェアは、このパラメータ化を行うことができない。限定的でない例として、「ＮｅｔＭｅｅｔｉｎｇ」ソフトウェアを挙げることができるのに対して、「Ｗｅｂｐｈｏｎｅ」ソフトウェアはそれが可能である。どちらのソフトウェアも、本発明の明細書の序文に挙げられている。
【０２４０】
しかしながら、シグナリング「プロキシ」を使用する利点は、たとえば通信の受入れのために役立つこともある発呼側加入者Ａａと着呼側加入者Ａｂとの間の単純なまたは相互の認証手続きを実施することができる点である。
【０２４１】
発呼側加入者Ａａのスマートカード２ａは、本発明によれば、「ＴＣＰ」ポート上で、シグナリング用と呼ばれる、「ＴＣＰ」サーバネットワークエージェントによって構成されるサーバに関連付けられる。このポートは、「Ｐｏｒｔ Ｓｉｇｎａｌｉｓａｔｉｏｎ Ｃａｒｔｅ Ｓｏｕｒｃｅ」を略して「ＰＳＣＳ」と呼ばれる。発呼側加入者Ａａのスマートカード２ａは、着呼側加入者Ａｂのスマートカード２ｂの対応するシグナリングポートに接続される。このポートは、「Ｐｏｒｔ Ｓｉｇｎａｌｉｓａｔｉｏｎ Ｃａｒｔｅ Ｄｅｓｔｉｎａｔｉｏｎ」を略して「ＰＳＣＤ」と呼ばれる。それは、恣意的に「＠ｉｐ」と呼ぶ「ＩＰ」アドレスに探索される。着呼側カード２ｂは、「ＴＣＰ」「ＰＳＣＤ」ポートと、着呼側加入者Ａｂの端末１ｂの「ＰＳＬＴ」ポートまたは「電話ソフトウェアシグナリングポート」との間のシグナリング「プロキシ」を実行する。
【０２４２】
これらのトランザクションは、図３から図５を参照して詳しく説明された本発明の方法の特徴の１つによって、対をなすエージェント間のセッションの確立と、また図１０を参照して詳しく説明された本発明の方法の他の特徴によって、「プロキシ」機能の実施を必要とする。
【０２４３】
図１１Ａでは、スマートカードの「プロキシ」２ａおよび２ｂが、参照符号２７ａおよび２７ｂによって概略的に表されている。それらは、実際に、図１０に表された種々のエレメント、エージェントＳ_１およびＳ_２およびフィルタ２８を含む。
【０２４４】
分かりやすくするために、ここで、実際の実施形態の中で、シグナリング段階の主要ステップについて説明する。分かりやすくするために、カードのループバックの「ＵＲＬ」アドレスは関係式（１）によって与えられたアドレス、すなわち１２７．０．０．１であり、任意のポート番号は１７３１であると想定する。電話ソフトウェアのポート番号は、一般的には１５０３である。探索段階で定めたように、着呼側加入者Ａｂのアドレスは＠ｉｐとする。
【０２４５】
発呼側加入者Ａａ
１．準備段階：＠ｉｐ：１５０３において翻訳１２７．０．０．１：１７３１が行えるように「プロキシ」の構成２７ａを準備する。
【０２４６】
２．発呼段階
２ａ．発呼側「ＰＳＰ」９０２ａが、１２７．０．０．１：１７３１を呼出す。
【０２４７】
２ｂ．発呼側スマートカード２ａが、＠ｉｐ：１５０３を呼出す。
【０２４８】
２ｃ．着呼側スマートカード２ｂが、＠ｉｐ：１５０２を呼出す。
着呼側加入者Ａｂ
１．予備準備段階：１５０３から１５０２の「ＰＳＰ」（着呼側）のシグナリングポート番号の変更。
【０２４９】
２．ポート１５０３の「ＴＣＰ」ネットワーク型のエージェントおよびカードの入力におけるポート１５０３と出力における１５０２との間の「プロキシ」機能２７ｂの利用による、マートカード２ｂと端末１ｂとの間の通信段階。
【０２５０】
当然のことながら、発呼側加入者システム、１ａ−２ａだけが、本発明に合致している型である場合には、スマートカード２ａは、「ＵＲＬ」アドレス＠ｉｐ：１５０２における着呼側加入システムを直接呼び出す。
【０２５１】
オプションとして、一対の暗号化の鍵は、シグナリング手続き中に交渉することができる。対応するデータの交換はまた、対をなすエージェント間のセッションの確立によって行われる。
【０２５２】
本発明の方法に合致したスマートカードはまた、データチャネルＣＤにおいて、データ交換プロトコルの「プロキシ」（「ＵＤＰ」型）として行動することができる。先述したように、この機能は、本発明の方法に合致したスマートカードをサポートするように電話ソフトウェアを適合させることを必要とすることもある。
【０２５３】
しかしながら、ここでもまた、データ交換「プロキシ」を利用することで、大きな利点が生まれる。その利点とは、情報の暗号化と暗号解読手続きを実行できるという点である。たとえば、５．３Ｋｂｐｓから６．３Ｋｂｐの間の容量で音声を圧縮する規格Ｇ７２３は、現在のスマートカードの容量、通常９６００ｂｐｓから１０５９００ｂｐｓの容量と互換性をもつ。図１０を参照してすでに説明したように、「プロキシ」フィルタは、特に、「ＤＥＳ」型のアルゴリズムに従って暗号解読および／または暗号化オペレーションの実行を可能にするフィルタとすることができる。
【０２５４】
図１１Ｂは、発呼側加入者Ａａと着呼側加入者ＡｂのデータチャネルＣＤについて、「プロキシ」機能を実施する電話システムのアーキテクチャを概略的に示している。図１１Ｂにおいては、スマートカード２ａおよび２ｂの「プロキシ」は、参照符号２７ａおよび２７ｂによって概略的に表わされる。それらは、実際には、先述したように、図１０に表わされる種々のエレメント：エージェントＳ_１およびＳ_２およびフィルタ２８を有する。
【０２５５】
発呼側加入者Ａａのスマートカード２ａは、「Ｐｏｒｔ Ｄｏｎｎｅｅｓ Ｃａｒｔｅ Ｓｏｕｒｃｅ」を略して「ＰＤＣＳ」と呼ばれる、「ＵＤＰ」ポート上のデータ交換用「ＵＤＰ」型サーバネットワークエージェントによって構成されるサーバに関連付けられる。発呼側加入者Ａａのスマートカード２ａは、任意の「ＩＰ」アドレス「＠ｉｐ」で探索されるカード、「Ｐｏｒｔ Ｄｏｎｎｅｅｓ Ｃａｒｔｅ Ｄｅｓｔｉｎａｔｉｏｎ」を略して「ＰＤＣＤ」と呼ばれる、着呼側加入者Ａｂのスマートカード２ｂのデータ交換ポートに接続される。着呼側加入者のスマートカード２ｂは、「ＵＤＰ」ポート「ＰＤＣＤ」と、端末１ｂの「ＰＤＬＴ」または「Ｐｏｒｔ ｄｅ Ｄｏｎｎｅｅｓ ｄｕ Ｌｏｇｉｃｉｅｌ ｄｅ Ｔｅｌｅｐｈｏｎｉｅ」ポートとの間のデータ交換「プロキシ」を実行する。その場合、２つのデータ交換「プロキシ」を実施する必要がある。着呼側加入者Ａｂに向かう発呼側加入者Ａａの「プロキシ」２７ａと、発呼側加入者Ａａに向かう着呼側加入者の他方の「プロキシ」２７ｂである。
【０２５６】
先述したように、発呼側加入システム、１ａ−２ａだけが、本発明に合致した型である場合には、スマートカード２ａは、着呼側加入者システムを直接呼出す。
【０２５７】
図１１Ａおよび１１Ｂの総括である図１２は、発呼側加入者Ａａと着呼側加入者Ａｂとの間、より厳密には、スマートカード２ａと協働する発呼側端末１ａを含む発呼側システムと、全体的に参照符号１’ｂが付される、サーバと呼ばれる着呼側システムとの間の電話データ（また、より一般的には、マルチメディアデータ）の伝送管理システムＳＧＤＴの一般的アーキテクチャを概略的に表している。着呼側加入者１’ｂは、（図１１Ａおよび／または１１Ｂに示されているような）スマートカード２ａとの協働する端末１ａ、または従来の技術のシステムの構成（図１参照：９ｂ）といった、発呼側システムに類似の、すなわち本発明に合致した構成を無差別に有することができる。先の図面に共通のエレメントには、同じ参照符号を付し、必要がある場合にのみ再び説明する。
【０２５８】
図１２は、特に、図３から図８、および図１０から図１１Ｂを参照して詳しく説明したように、本発明による電話データ伝送管理システムの基本的構成要素間の種々の相互作用を表わす。より厳密には、スマートカード２ａは、（図７Ｄおよび図８によって詳しく説明されるているように）「ＰＥ」登録プロトコル９００ａおよび「ＰＬ」探索プロトコル９０１ａに関連付けられるアプリケーション、さらに「ＰＡ」加入者プロファイル９０３ａが、このスマートカード２ａのメモリ内に登録される本発明の好ましい実施形態を表している。同様に、スマートカード２ａは、シグナリングチャネルＣＳについてもデータチャネルＣＤについても、「プロキシ」機能２７ａを有することが想定された（図１１Ａおよび図１１Ｂ）。先述したように、プロキシ２７ａは、スマートカード２ａのクライアント／ＳＷＥＢサーバのコントロール下にある。
【０２５９】
さらに、ただ１つのディレクトリサーバＳＡ_ｉが図１２に示されているにもかかわらず、さらに好ましい実施形態においては、複数の加入者プロファイルの登録のためのデータファイルおよび複数の探索プロトコル、さらに複数の登録プロトコルの実施を可能にするアプリケーションをスマートカード２ａ内に保存する。こうした有利な措置は、スマートカード２ａをマルチディレクトリポータブルデータベースに変換させることができる。それ自体において、１つまたは複数のサーバは、従来の技術のサーバ、たとえば図１のサーバ９１とまったく同じである。サーバは、加入者の「ＰＥ」登録プロトコル９１０および「ＰＬ」探索プロトコル９１１を有する。
【０２６０】
以上のことから、本発明の方法は、定められた目的を正しく達成できることが容易にわかる。
【０２６１】
スマートカード内に直接設置された「プロキシ」と呼ばれる機能は、このスマートカードによって与えられる「ＷＥＢ」クライアント／サーバの機能と協働することによって、シグナリングプロトコルおよび／またはデータ交換プロトコルの「プロキシ」としてスマートカードを使用することを可能にする。
【０２６２】
スマートカードが、シグナリングプロトコルの「プロキシ」として使用される場合には、特に、発呼側加入者と着呼側加入者との間の単純なまたは相互の認証手続きの実施が可能になる。さらに、暗号化の鍵によって交渉し、さらに／またはあらかじめ確立された伝送特性を与えるルーティング経路を予約することが可能になる。
【０２６３】
スマートカードが通信プロトコルの「プロキシ」として使用される場合には、特に、暗号化／暗号解読手続きを実施することが可能になる。さらに、、交換されたデータの容量または数量に基づいて、または先に実施された予約を考慮に入れて、料金決定オペレーションを実施することが可能である。
【０２６４】
本発明による方法によって、また、たとえば発呼側加入者は、１つまたは複数のディレクトリサーバ上に登録することができ、さらに／または、１つまたは複数のディレクトリを介して、インターネット上で、着呼側と呼ばれる他方の加入者を探索することができる。スマートカードは、「ＷＥＢ」クライアント／サーバと「ＣＧＩ」ゲートウェイを組み合わされた機能を有することから、こうした措置は、スマートカードとディレクトリサーバとの間の直接通信を可能にする。こうしたカードは、そのことによって、登録プロトコルおよび／または探索プロトコルの実施に必要な特有のソフトウェアの保存を許可し、その結果、大きな移動性が可能になる。１つまたは複数の加入者プロファイルがまた、スマートカード内に保存される。加入者はもはや、特に上記のプロトコルのために配置された端末の使用に制限されることはない。
【０２６５】
本発明による方法は、既存の方法と完全な互換性をもっている。発呼側または着呼側の加入者は、本発明の方法を使用することによって、１つまたは複数のディレクトリサーバ上に登録されることを要求されることもないし、本発明によるスマートカードの読取装置を備えた端末を有する必要もない。インターネット上の伝送は、現行のプロトコルに従って行われ、本発明による方法を利用する加入者端末とそのスマートカードとの間の通信は、上記の規格化プロトコル「ＩＳＯ」を利用して行われる。したがって、標準スマートカードの読取り装置を利用することができる。端末における特有のソフトウェア層の存在のみが必要であり、その結果、ほとんど変更を必要とせず、登録プロトコル、探索プロトコルおよび／またはスマートカードによってもたらされる加入者プロファイルの数に関係なく、また、それらの性質にも関係なく、一度にすべてを行うことができる。スマートカード内に設置された「プロキシ」フィルタについても同様である。
【０２６６】
さらに、スマートカードの使用は、トランザクションの安全化、特に「確固とした」認証を可能にする。また、ルーティング経路の交渉および／または交換されたデータの料金決定を可能にする。
【０２６７】
しかしながら、本発明は、特に、一方では、図３から図８と関連して、他方では図１０から図１２と関連して、詳しく説明した実施形態のみに限定されるわけではないことを明らかにしなればならない。
【０２６８】
そうした措置はとりわけ有利であるにもかかわらず、プロプラエタリソフトウェアの２つのシリーズ「ＰＥ」および「ＰＬ」が、スマートカード内に保存されることは必要ない。限定的でない例として、１つまたは複数のディレクトリサーバにおける登録段階は、一度ですべてを行うことができる、または、少なくとも、先験的に探索段階より少ない頻度ですむので、スマートカード内に、この探索オペレーションに関連付けられた特有のアプリケーションだけを保存すればよい。同様に、すでに示したように、スマートカード内に加入者プロファイル「ＰＡ」を登録しなくてもよい（データは、個別のディレクトリサーバ内で加入者登録時にリアルタイムで与えられることができる）。さらに、自動的に提供されることが可能なプロファイルである、加入者プロファイルの一部のみを登録することが可能である。
【０２６９】
さらに、すでに示したように、本発明は、電話型のデータだけの管理に限定されるわけではない。それは、より一般的には、他の型のマルチメディアデータ、特にテレビ電話データの管理を可能にする。
【０２７０】
本発明はまた、第１の加入システムと第２の加入システムとの間のインターネット型ネットワークを介するマルチメディアデータの伝送管理方法であって、一定のシグナリングプロトコルを用い、シグナリングチャネルを介して、少なくとも、シグナリングと呼ばれるデータ交換段階と、一定の通信プロトコルを用い、データチャネルを介して、前記マルチメディアデータの交換段階とを有し、さらに、前記の第１の加入システムは、「ＷＥＢ」型ブラウザと、スマートカードと協働するスマートカードの読取装置を備えた端末とを有し、端末およびスマートカードは、情報処理手段と情報保存手段とを有し、前記のスマートカード（２ａ）は、特有の通信プロトコル層を形成する第１のソフトウェア（２３ａ）を有し、前記の端末（１ａ）は、特有の通信プロトコル層を形成し、さらに前記の「ＷＥＢ」型ブラウザ（１０）とのインターフェイスを形成する、第２のソフトウェア（１３）を有し、前記の第１および第２のソフトウェア（１３、２３ａ）は、各々、さらに、クライアント型の第１の独立ソフトウェアエンティティ（Ｔ_２、Ｓ_１）と、サーバ型の第２の独立ソフトウェアエンティティ（Ｔ_１、Ｓ_２）とを有し、前記エンティティ（Ｔ_１、Ｓ_２、Ｔ_１、Ｓ_２）は、前記の情報処理手段によって、前記端末（１ａ）と前記スマートカード（２ａ）との間の双方向データ交換セッションを確立できるように、さらに、前記スマートカード（２ａ）が、クライアント／「ＷＥＢ」型サーバの機能を提供し、さらに前記のインターネット型ネットワーク（ＲＩ）を介する前記の第１の加入システムの端末（１ａ）と、第２の加入システム（１’ｂ）との間の双方向データ交換セッションの確立を可能にするように協働し、前記独立ソフトウェアエンティティは、あらかじめ定められたプロトコルデータユニットを用いて通信し、
− 前記スマートカード（２ａ）の保存手段の中で、前記の第２の特有ソフトウェア（２３ａ）内に含まれる、それぞれクライアント型とサーバ型の、前記の第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に向かって、および／または、それらから、プロトコルデータユニットを受信および／または送信する、フィルタと呼ばれる一定の機能持性を有するアプリケーションソフトウェア（２８）を実行し、
− 前記のシグナリングデータおよび／またはマルチメディアデータの交換段階中に、前記のシグナリングチャネル（ＣＳ）および／またはデータチャネル（ＣＤ）の少なくともいずれか一方を介して、前記の第１の加入システム（１ａ、２ａ）と前記の第２の加入システム（１’ｂ）との間を通過するデータ交換のあらかじめ定められた特性をコントロールし、「プロキシ」と呼ばれる機能を形成するために特有の前記の第１の特有ソフトウェア（２７ａ）の前記独立ソフトウェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを、前記の情報処理、端末、スマートカード手段によって開始するために、前記フィルタ（２８）が、特有の第２のソフトウェア（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）と協働する
ことを特徴とする方法を対象とする。
【０２７１】
本発明はまた、情報処理手段と情報保存手段とを有し、前記の第１の加入システムと前記の第２の加入システムとの間でインターネット型ネットワークを介するマルチメディアデータ伝送管理のための第１の加入システムを形成できるように、スマートカードの読取装置を備えた端末と協働するためのスマートカードであって、前記管理は、少なくとも、一定のシグナリングプロトコルを用い、シグナリングチャネルを介するシグナリングデータ交換段階と、一定の通信プロトコルを用い、データチャネルを介する、前記マルチメディアデータの交換段階とを有し、さらに、前記スマートカード（２ａ）が、情報保存手段の中に、特有の通信プロトコル層を形成するソフトウェア（２３ａ）を含み、さらに、少なくとも、クライアント型の第１の独立ソフトウェアエンティティ（Ｓ_１）と、サーバ型の第２の独立ソフトウェアエンティティ（Ｓ_２）とを有し、前記エンティティ（Ｓ_２、Ｓ_２）は、前記スマートカード（２ａ）がクライアント／「ＷＥＢ」型サーバの機能を与え、前記のインターネット型ネットワーク（ＲＩ）を介して前記の第１の加入システムの端末（１ａ）と前記の第２の加入システム（１’ｂ）との間のデータ交換を確立することができるように協働し、前記スマートカード（２ａ）は、さらに、情報保存手段の中で、前記の特有ソフトウェア（２３ａ）内に含まれる、それぞれクライアント型とサーバ型の、前記の第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に向かって、および／またはそれらから、プロトコルデータユニットを受信および／または送信する、フィルタと呼ばれる一定の機能持性を有するアプリケーションソフトウェア（２８）を有し、前記アプリケーションソフトウェアは、サーバ型の前記独立ソフトウェアエンティティ（Ｓ_１）のコントロール下で実施され、前記のシグナリングデータおよび／またはマルチメディアデータの交換段階中に、前記のシグナリングチャネル（ＣＳ）および／またはデータチャネル（ＣＤ）の少なくともいずれか一方を介して、前記の第１の加入システム（１ａ、２ａ）と前記の第２の加入システム（１’ｂ）との間を通過するデータ交換のあらかじめ定められた特性をコントロールし、「プロキシ」と呼ばれる機能を形成するために特有の前記の第１の特有ソフトウェア（２７ａ）の前記独立ソフトウェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを開始できるように、前記情報処理によって、前記フィルタ（２８）が、第２の特有のソフトウェア（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）と協働することを特徴とするスマートカードを対象とする。
【図面の簡単な説明】
【図１】 従来の技術による電話ソフトウェアを構成する主要モジュールを概略的に表わす図である。
【図２Ａ】 従来の技術によるインターネットに接続されたスマートカードに基づくアプリケーションシステムの一例のハードウェアアーキテクチャを表わす図である。
【図２Ｂ】 従来の技術によるインターネットに接続されたスマートカードに基づくアプリケーションシステムの一例のソフトウェアアーキテクチャを表わす図である。
【図３】 本発明によるスマートカードに基づくアプリケーションシステムの一例を概略的に表わす図であり、そのスマートカードは、本発明の一様態に従って、「ＷＥＢ」クライアント／サーバとして作動する。
【図４】 本発明の一様態による、インテリジェントエージェントと呼ばれるソフトウェアエンティティ間のセッションの状態のフローチャートである。
【図５】 スマートカードがインテリジェントエージェントを有する、本発明によるシステムのソフトウェアアーキテクチャを簡略に表わす図である。
【図６】 スマートカードが、「ＣＧＩ」と呼ばれる機能を設置できるように、スクリプト変換インテリジェントエージェントを有する、本発明の他の様態によるシステムのソフトウェアアーキテクチャを簡略に表わす図である。
【図７Ａ】 ディレクトリサーバへの加入者登録段階の第１ステップを概略的に表わす図である。
【図７Ｂ】 その登録段階のために使用可能な「ＨＴＬＭ」書式例を表わす図である。
【図７Ｃ】 その登録段階のために使用可能な「ＨＴＬＭ」書式例を表わす図である。
【図７Ｄ】 ディレクトリサーバへの加入者登録段階の主要なステップを概略的に表わす図である。
【図８】 ディレクトリサーバの問合わせによってインターネットへの加入者探索段階の主要なステップを概略的に表わす図である。
【図９】 従来の技術による「プロキシ」を概略的に表わす図である。
【図１０】 「プロキシ」と呼ばれるフィルタがスマートカード上に実装される、図４に合致した本発明のシステムのソフトウェアアーキテクチャを概略的に表わす図である。
【図１１Ａ】 加入者発呼側と加入者着呼側の信号経路のための「プロキシ」機能を実行する、本発明による電話システムのアーキテクチャを概略的に表わす図である。
【図１１Ｂ】 加入者発呼側と加入者着呼側のデータ経路のための「プロキシ」機能を実行する、本発明による電話システムのアーキテクチャを概略的に表わす図である。
【図１２】 端末とスマートカードを有する発呼側システムと着呼側システムとの間で、本発明の好ましい実施形態による、電話データの伝送管理システムの一般的アーキテクチャを概略的に表わす図である。

Claims (17)

1. 第１の加入システムと第２の加入システムとの間のインターネット型ネットワークを介するマルチメディアデータの伝送管理方法であって、一定のシグナリングプロトコルを用い、シグナリングチャネルを介する、少なくとも１つのシグナリングデータ交換段階と、一定の通信プロトコルを用い、データチャネルを介する、前記マルチメディアデータの交換段階とを有する方法であり、少なくとも前記第１の加入システムが、「ＷＥＢ」型ブラウザと、スマートカードと協働するスマートカードの読取装置とを備えた端末を有し、前記スマートカード（２ａ）が、特有の通信プロトコル層を形成する第１のソフトウェア（２３ａ）を有し、前記端末（１ａ）が、特有の通信プロトコル層を形成し、少なくとも前記「ＷＥＢ」型ブラウザ（１０）とのインターフェイスを形成する、第２のソフトウェア（１３）を有し、前記第１および第２のソフトウェア（１３、２３ａ）が、各々、さらに少なくとも、クライアント型の第１の独立ソフトウェアエンティティ（Ｔ_２、Ｓ_１）と、サーバ型の第２の独立ソフトウェアエンティティ（Ｔ_１、Ｓ_２）とを有し、前記エンティティ（Ｔ_１、Ｓ_２、Ｔ_１、Ｓ_２）が、前記端末（１ａ）と前記スマートカード（２ａ）との間の双方向データの交換セッションの確立を可能にし、前記スマートカード（２ａ）が、クライアント／ＷＥＢ型サーバの機能を提供し、さらに、インターネット型ネットワーク（ＲＩ）を介する、前記第１の加入システムの端末（１ａ）と前記の第２の加入システム（１’ｂ）との間の双方向データの交換セッションの確立を可能にするように、協働し、前記独立ソフトウェアエンティティは、あらかじめ定められたプロトコルデータユニットを用いて通信し、
   − 前記スマートカード（２ａ）の中で、前記第２の特有ソフトウェア（２３ａ）内に含まれる、それぞれクライアント型とサーバ型の、前記第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に向かって、および／または、前記第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）から、プロトコルデータユニットを受信および／または送信する、フィルタと呼ばれる一定の機能持性を有するアプリケーションソフトウェア（２８）を実行し、前記アプリケーションソフトウェアの実行は、サーバ型の独立ソフトウェアエンティティ（Ｓ_１）のコントロール下にあり、
   − 前記シグナリングデータおよび／またはマルチメディアデータの交換段階中に、前記シグナリングチャネル（ＣＳ）および／またはデータチャネル（ＣＤ）の少なくともいずれか一方を介して、前記第１の加入システム（１ａ、２ａ）と前記第２の加入システム（１’ｂ）との間を通過するデータ交換のあらかじめ定められた特性をコントロールし、「プロキシ」と呼ばれる機能（２７ａ）を形成するために、前記第１の特有ソフトウェアの前記独立ソフトウェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを開始するために、前記フィルタ（２８）が、第２の特有ソフトウェア（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）と協働することを特徴とする、第１の加入システムと第２の加入システムとの間のインターネット型ネットワークを介するマルチメディアデータの伝送管理方法。
2. 前記独立ソフトウェアエンティティが、インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）で構成されることを特徴とする、請求項１に記載の方法。
3. 前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）の各々は、
   − 「ホスト」、前記端末（１）内で探索されるインテリジェントエージェント、
   − 「カード」、前記スマートカード（２ａ）内で探索されるインテリジェントエージェント、
   − 「ローカル」、前記ネットワーク（ＲＩ）と通信しないインテリジェントエージェント、
   − 「ネットワーク」、前記ネットワーク（ＲＩ）と通信するインテリジェントエージェント、
   − 「クライアント」、前記セッションの１つを初期化するインテリジェントエージェント、および
   − 「サーバ」、前記セッションの１つのための要求を受取るインテリジェントエージェント
   の６つの特性の少なくともいずれか１つに関連付けられることを特徴とする、請求項２に記載の方法。
4. 前記第１の特有のソフトウェアが、「ＴＣＰ／ＩＰ」型のサーバの機能を実行する、Ｔ_１と呼ばれる前記特性「端末」、「サーバ」、および「ローカル」に関連付けられる第１のインテリジェントエージェント（Ｔ_１）を有し、前記第２の特有のソフトウェアが、Ｓ_１と呼ばれる「カード」、「サーバ」、および「ローカル」特性に関連付けられる第１のインテリジェントエージェント（Ｓ_１）を有し、このエージェントＳ_１は、セッションによって前記第１のインテリジェントエージェントＴ_１に関連付けられ、さらに前記フィルタ（２８）の前記一定の機能特性は、前記第１のインテリジェントエージェントＴ_１から出される情報の機能であり、前記第１の特有のソフトウェアは、前記インターネット型ネットワーク（ＲＩ）を介して、前記第２加入システム（１’ｂ）に接続するために、「ＴＣＰ／ＩＰ」または「ＵＤＰ／ＩＰ」型サーバの機能を実行する、Ｔ_２と呼ばれる前記「端末」、「サーバ」、および「ネットワーク」特性に関連付けられる第２のインテリジェントエージェント（Ｔ_２）を有し、前記第２の特有ソフトウェア（２３ａ）は、Ｓ_２と呼ばれる前記「カード」、および「クライアント」、「ローカル」特性に関連付けられる第２のインテリジェントエージェント（Ｓ_２）を有し、該インテリジェントエージェントＳ_２のインスタンスは、前記フィルタ（２８）によって動的に前記セッションの各々につくりだされ、該エージェントＳ_２は、前記第２のインテリジェントエージェントＴ_２とセッションを開き、前記インテリジェントエージェント（Ｔ_２、Ｔ_１、Ｓ_２、Ｓ_１）および前記フィルタ（２８）が、前記「ＴＣＰ プロキシ」（２７ａ）機能を形成するために協働し、前記シグナリングチャネル（ＣＳ）および／またはデータチャネル（ＣＤ）を介して、前記第１の加入システム（Ａａ）と前記第２の加入システム（Ａｂ）との間の前記データ交換特性をコントロールすることができるように、前記第２のインテリジェントエージェントに、前記第２の加入システム（１’ｂ）に接続することができるアドレスを指示することを特徴とする、請求項３に記載の方法。
5. 前記「プロキシ」機能が、前記シグナリングチャネル上を通過する前記シグナリングデータの前記特性をコントロールし、前記第１の加入者システムの端末（１ａ）と前記第２の加入者システム（１’ｂ）は、あらかじめ定められたポート番号によって指定された、シグナリング用と呼ばれる「ＴＣＰ」型ポートに関連付けられる、シグナリング用と呼ばれる特有のソフトウェア（９０２ａ、９０２ｂ）を有し、少なくとも、
   − ループバック用と呼ばれる「ＵＲＬ」型アドレス上で、前記スマートカード（２ａ）を呼出すことができるように、発呼側と呼ばれる前記第１の加入システムの端末（１ａ）と、「ＴＣＰ」型サーバの利用によって、関連付けられる前記スマートカード（２ａ）との間の双方向交換セッションの確立段階と、
   − 前記探索段階中に定められた、前記着呼側加入者（Ａｂ）を指定する「ＩＰ」型アドレスと、前記シグナリングポート番号で構成される、「ＵＲＬ」型アドレス上で、前記インターネット（ＲＩ）を介する、前記スマートカード（２ａ）による、着呼側と呼ばれる前記第２の加入システム（１’ｂ）の呼出し段階と、
   − 前記「プロキシ」（２７ａ）を通してまた前記インターネットネットワーク（ＲＩ）を介して、前記シグナリングチャネル（ＣＳ）上に前記シグナリングデータを伝送する段階とを有することを特徴とする、請求項１に記載の方法。
6. 前記着呼側加入システムが、中に前記第２のソフトウェアが設けられる端末（１ｂ）を有し、前記「プロキシ」（２７ｂ）を形成するために、中に前記第２のソフトウェアと前記アプリケーションソフトウェアが設けられるスマートカード（２ｂ）と協働し、さらに
   − 前記発呼側システムのスマートカード（２ａ）による前記着呼側システムのスマートカード（２ｂ）の呼出し段階と、
   − 前記スマートカードに関連付けられる前記「プロキシ」を通した、前記着呼側システムの端末（１ｂ）のスマートカード（２ｂ）と端末との間の通信段階という補足的ステップを有する、請求項５に記載の方法。
7. 前記シグナリングデータの交換のあらかじめ定められた特性の前記コントロールが、前記「プロキシ」（２７ａ、２７ｂ）によって実行される、前記発呼側加入者（Ａａ）と着呼側加入者（Ａｂ）との間の単純または相互の認証段階を有することを特徴とする、請求項５に記載の方法。
8. 前記シグナリングデータの交換のあらかじめ定められた特性の前記コントロールが、前記「プロキシ」（２７ａ、２７ｂ）によって実行される前記データ交換段階中に前記データによって利用されるルーティング経路の予約交渉段階を有することを特徴とする、請求項５に記載の方法。
9. 前記「プロキシ」機能（２７ａ）が、前記データチャネル（ＣＤ）上を通過する前記マルチメディアデータをコントロールし、前記第１の加入システムの端末（１ａ）と前記第２の加入システム（１’ｂ）とが、あらかじめ定められたポート番号によって指定された、データ用と呼ばれる「ＵＤＰ」型ポートに関連付けられる、データ交換用と呼ばれる、特有のソフトウェア（９０５ａ、９０５ｂ）を有し、少なくとも、
   − ループバック用と呼ばれる「ＵＲＬ」型アドレス上で、前記スマートカード（２ａ）を呼出すことができるように、発呼側と呼ばれる前記第１の加入システムの端末（１ａ）と、「ＵＤＰ」型サーバの利用によって、関連付けられる前記スマートカード（２ａ）との間の双方向交換セッションの確立段階と、
   − 前記探索段階中に定められた、前記着呼側加入者（Ａｂ）を指定する「ＩＰ」型アドレスと、前記シグナリングポート番号とで構成される、「ＵＲＬ」型アドレス上で、前記インターネットネットワーク（ＲＩ）を介する、前記スマートカード（２ａ）による、着呼側と呼ばれる前記第２の加入システム（１’ｂ）の呼出し段階と、
   − 前記「プロキシ」（２７ａ）を通して、また前記インターネットネットワーク（ＲＩ）を介する、前記データチャネル（ＣＤ）上に前記マルチメディアデータを伝送する段階とを有することを特徴とする、請求項１に記載の方法。
10. 前記着呼側加入システムが、中に前記第２のソフトウェアが設けられる端末（１ｂ）を有し、前記「プロキシ」（２７ｂ）を形成するために、中に前記第２のソフトウェアと前記アプリケーションソフトウェアが設けられるスマートカード（２ｂ）と協働し、さらに、
    − 前記発呼側システムのスマートカード（２ａ）による、前記着呼側システムのスマートカード（２ｂ）の呼出し段階と、
    − 前記スマートカード（２ｂ）に関連付けられる前記「プロキシ」（２７ｂ）を通した、前記着呼側システムの端末（１ｂ）のスマートカード（２ｂ）と端末との間の通信段階という補足的ステップを有することを特徴とする、請求項９に記載の方法。
11. さらに、定められた登録プロトコル（９００ａ）と前記加入者を説明する加入者プロファイル用と呼ばれるデータ（９０３ａ）とを用いて、少なくとも１つのディレクトリサーバ（ＳＡ_ｉ）内に前記加入者を登録する段階と、定められた探索プロトコル（９０１ａ）を用いて、前記ディレクトリサーバ（ＳＡ_ｉ）の少なくとも１つの問合わせによって前記着呼側加入者を探索する段階とを有し、前記一定の登録および探索プロトコルは、ソフトウェア（Ａ_ｅ、Ａ_ｉ）に関連付けられ、前記ソフトウェアの少なくとも１つが、前記の第１の加入システムの少なくともスマートカード（２ａ）内に保存され、さらに前記スマートカード（２ａ）は、前記スマートカードが「ＣＧＩ」と呼ばれるゲートウェイインターフェイス機能を提供するために、前記第２の特有ソフトウェア（２３ａ）と協働できるように、指示セットを解釈し、該指示セットを命令セットに翻訳することができる、少なくとも１つの第２のソフトウェアエンティティ（ＡＴ_ｅ、ＡＴ_ｉ）を有し、前記スマートカードは、少なくとも１つのプロプラエタリソフトウェアに関連付けられた、少なくとも１つの前記指示セットを含み、
    さらに少なくとも、
    １．前記ディレクトリサーバ（ＳＡ）の選別のために、前記「ＷＥＢ」ブラウザ（１０）が、前記ソフトウェアの１つ（Ａ_ｅ、Ａ_ｉ）を選別および起動することができるデータを検索するための要求の伝送用に、少なくとも、前記端末（１）と前記スマートカード（２ａ）との間の第１のデータ交換シーケンスを開始する段階と、
    ２．前記データを伝達するために、前記スマートカード（２ａ）と前記端末（１）との間の第２のデータ交換シーケンスを開始する段階と、
    ３．選別データとオプションのパラメータを伝達するために、前記端末（１）と前記スマートカード（２ａ）との間の第３のデータ交換シーケンスを開始する段階であって、前記データと前記オプションのパラメータが、前記プロプラエタリソフトウェアに関連付けられる前記指示セットの１つへのリファレンスを有する段階と、
    ４．前記「ＣＧＩ」機能の実行と前記プロプラエタリソフトウェア（Ａ_ｅ、Ａ_ｉ）の実行によって、前記指示セットを解釈する段階と
    ５．前記実行の結果として、登録または探索の定められたオペレーションの実行のために要求を伝達できるように、前記選別データによって選別された、前記スマートカード（２ａ）と前記ディレクトリサーバ（ＳＡ_ｉ）との間の第４のデータ交換シーケンスを開始する段階とを有することを特徴とする、請求項５に記載の方法。
12. 前記マルチメディアデータが電話データであり、前記プロプラエタリソフトウェアの各々に関連付けられる解釈される前記指示セットが、スクリプトによって構成され、また、前記第２のソフトウェアエンティティが、前記ソフトウェア（Ａ_ｅ、Ａ_ｉ）によって理解可能な命令を与える、スクリプトトランスレータインテリジェントエージェント（ＡＴ_ｅ、ＡＴ_ｉ）と呼ばれるソフトウェアモジュールで構成されることを特徴とする、請求項１に記載の方法。
13. 前記のステップ１．が、前記選別データとオプションのパラメータとを含む、「ＨＴＭＬ」言語における定められたページ（Ｐ_１、Ｐ_２）のアドレシングによってインターネット型プロトコルに従う、「ＨＴＴＰ」と呼ばれる型の要求の送信を含み、前記アドレスが、前記スマートカード（２ａ）上のループバック用「ＵＲＬ」型アドレスであることを特徴とする、請求項１１に記載の方法。
14. 第１の型と呼ばれるソフトウェア（Ａ_ｅ）が、定められたディレクトリサーバ（ＳＡ_ｉ）上の前記加入者の１人（Ａａ、Ａｂ）の登録を可能にする前記プロトコルに関連付けられ、前記オプションのパラメータが、少なくとも、前記登録される加入者（Ａａ、Ａｂ）の識別用と呼ばれるデータを有する、加入者用プロファイルを規定するデータで構成され、前記ステップ３．の前記「ＨＴＴＰ」要求は、要求されたオペレーションが前記登録であることを指示する第１のデータと、前記第１の型（Ａ_ｅ）のソフトウェアによって、定められた前記ディレクトリサーバ（ＳＡ_ｉ）の特徴的な「ＵＲＬ」型アドレスを作成することができる第２のデータとを有し、前記加入者プロファイルに関連付けられたデータが、前記ステップ４．の間に、前記加入者（Ａａ、Ａｂ）の前記登録を実行できるように、前記ディレクトリサーバ（ＳＡ_ｉ）に伝達され、前記登録が、前記ディレクトリサーバの（ＳＡ_ｉ）アドレスと加入者（Ａａ、Ａｂ）の前記識別データとの組み合わせによって「ＩＰ」型アドレスの決定を含むことを特徴とする、請求項１１に記載の方法。
15. 第２の型と呼ばれるソフトウェア（Ａ_ｉ）が、前記インターネット型ネットワーク（ＲＩ）上の着呼側加入者（Ａｂ）の探索を可能にする前記プロトコルに関連付けられ、前記着呼側加入者（Ａｂ）が、定められたディレクトリサーバ（ＳＡ_ｉ）上に登録され、さらに、該登録が、少なくとも、前記着呼側加入者の識別用と呼ばれるデータを有し、前記ステップ３．の前記「ＨＴＴＰ」要求は、要求されたオペレーションが前記探索であることを指示する第１のデータと、探索される前記着呼側加入者（Ａｂ）を識別する第２のデータと、第２の型のプロプラエタリソフトウェア（Ａ_ｉ）によって、定められた前記ディレクトリサーバ（ＳＡ_ｉ）の特徴的な「ＵＲＬ」型アドレスを作成することができる第３のデータとを有し、さらに、前記ディレクトリサーバ（ＳＡ_ｉ）が受け取ったこの着呼側加入者の前記識別データを、前記サーバ内に保存された登録データに関連付けながら、「ＩＰ」型アドレスのサーチによって、また前記「ＩＰ」型アドレスを前記探索を可能にするように前記スマートカード（２ａ）に再送することによって、前記着呼型加入者の前記探索段階を実行することができるように、前記ステップ４．の間に、前記着呼側加入者を識別するデータがディレクトリサーバ（ＳＡ_ｉ）に伝達されることを特徴とする、請求項１１に記載の方法。
16. 前記第１の加入システムと第２の加入システムとの間でインターネット型ネットワークを介して、マルチメディアデータの伝送管理のために第１の加入システムを形成できるように、スマートカードの読取装置を備えた端末と協働するためのスマートカードであって、前記伝送管理が、定められたシグナリングプロトコルを用いて、シグナリングチャネルを介して、少なくともシグナリング用と呼ばれるデータ交換段階と、定められた通信プロトコルを用い、データチャネルを介して前記マルチメディアデータの交換段階とを有し、さらに、前記スマートカード（２ａ）が、特有の通信プロトコル層を形成するソフトウェア（２３ａ）を有し、さらに、少なくとも、クライアント型の第１の独立ソフトウェアエンティティ（Ｓ_１）と、サーバ型の第２の独立ソフトウェアエンティティ（Ｓ_２）とを有し、前記エンティティ（Ｓ_２、Ｓ_２）は、前記スマートカード（２ａ）が、「ＷＥＢ」型クライアント／サーバの機能を提供し、前記インターネット型ネットワーク（ＲＩ）を介して、前記第１の加入システムの端末（１ａ）と前記の第２加入システム（１’ｂ）との間のデータ交換を確立できるように協働し、前記スマートカード（２ａ）が、さらに、前記特有のソフトウェア（２３ａ）内に含まれる、それぞれクライアント型とサーバ型の、前記第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に向かって、および／または、前記第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）から、プロトコルデータユニットを受信および／または送信する、フィルタと呼ばれる一定の機能持性を有するアプリケーションソフトウェア（２８）を有し、前記アプリケーションは、サーバ型独立ソフトウェアエンティティ（Ｓ_１）の制御の下で実現され、前記シグナリングデータおよび／またはマルチメディアデータの交換段階中に、前記シグナリングチャネル（ＣＳ）および／またはデータチャネル（ＣＤ）の少なくともいずれか一方を介して、前記第１の加入システム（１ａ、２ａ）と前記第２の加入システム（１’ｂ）との間を通過するデータ交換のあらかじめ定められた特性をコントロールし、「プロキシ」（２７ａ）と呼ばれる機能を形成するために前記第１の特有ソフトウェアの前記独立ソフトウェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを開始するために、前記フィルタ（２８）が、特有の第２のソフトウェア（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）と協働することを特徴とする、スマートカード。
17. 前記マルチメディアデータの伝送管理が、さらに、前記加入者を説明する加入者プロフィル用と呼ばれるデータ（９０３ａ）と定められた登録プロトコル（９００ａ）とを用い、少なくとも１つのディレクトリサーバ（ＳＡ_ｉ）内に前記加入者を登録する段階と、定められた探索プロトコル（９０１ａ）を用いて、前記ディレクトリサーバ（ＳＡ_ｉ）の少なくとも１つの問合わせによって前記着呼側加入者を探索する段階とを有し、前記スマートカード（２ａ）が、前記定められた登録および探索の定められたプロトコルに関連付けられた少なくとも１つのソフトウェア（Ａ_ｅ、Ａ_ｉ）を保存し、前記スマートカード（２ａ）が、前記登録または探索プロトコルに関連付けられる前記ソフトウェア（Ａ_ｅ、Ａ_ｉ）を起動できるように、前記スマートカード（２ａ）が、「ＣＧＩ」と呼ばれるゲートウェイインターフェイスの機能を与えるために、前記特有ソフトウェア（２３ａ）と協働する少なくとも第２のソフトウェアエンティティ（ＡＴ_ｅ、ＡＴ_ｉ）を有することを特徴とする、請求項１６に記載のスマートカード。

Images