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

Abstract

(57)【要約】 本発明は、発呼側加入者Ａａと着呼側加入者Ａｂとの間のインターネットＲＩを介するデータ伝送管理方法に関するものである。カード２ａは、端末１ａと協働し、「ＣＧＩ」および「プロキシ」２７ａ用の「ＷＥＢ」クライアント／サーバＳ_ｗｅｂ機能を有する。「プロキシ」機能は、シグナリングチャネルＣＳとデータチャネルＣＤのために使用される。端末１ａとカード２ａは、相互の、および／または、インターネットＲＩとの双方向伝送セッションの確立を可能にする固有の通信プロトコル層を有する。スマートカード２ａは、加入者の登録プロトコル９００ａおよび探索プロトコル９０１ａさらに加入者プロファイルプロトコル９０３に関連付けられるアプリケーションを保存する。スマートカードは、シグナリングチャネルＣＳおよび／またはデータチャネルＣＤ上で「プロキシ」の役割を果たす。本発明はまた、関連付けられるカードを対象とする。

Description

【発明の詳細な説明】

【０００１】 本発明は、スマートカードの読取装置を備えた端末に接続されたスマートカー
ドを用いたインターネット型ネットワークを介するマルチメディアデータの伝送
管理方法に関する。

【０００２】 本発明は、より詳細には、インターネット型ネットワークを介する電話伝送ま
たはテレビ電話伝送の管理に関する。

【０００３】 本発明はまた、その方法の実施のためのスマートカードにも関する。

【０００４】 上記の伝送は、適切なハードウェアゲートウェイおよびソフトウェアゲートウ
ェイを介して、その全体をインターネット型ネットワーク上で、または、一部を
ネットワーク上で、また一部を標準電話ネットワーク（たとえば交換型）上で行
うことができる。

【０００５】 本発明の範囲を限定することなく、分かりやすくするために、好ましい実施形
態、すなわちインターネットを介する電話の枠組みで本方法について説明する。

【０００６】 本発明の枠組みにおいては、「インターネット」という用語は、最も一般的な
意味において理解されなければならない。それは、厳密な意味でのインターネッ
トに加えて、「イントラネット」と呼ばれる型の企業の専用ネットワークまたは
それに類するネットワーク、および「エクストラネット」と呼ばれる型の外部に
向けてイントラネットを延長するネットワーク、さらに一般的には、そこでデー
タ交換がインターネット型プロトコルに従ってなされるネットワーク全体を対象
とする。以降、このようなネットワークを一般的に「インターネット」と呼ぶ。

【０００７】 同様に、「端末」という用語も一般的な意味で理解されなければならない。上
記の端末は、特に、ＷＩＮＤＯＷＳやＵＮＩＸ（両方とも登録商標である）など
のさまざまなオペレーティングシステムの下で動作するパーソナルコンピュータ
によって構成することができる。端末はまた、ワークステーション、可搬コンピ
ュータ、またはいわゆる専用カード端末によって構成することもできる。

【０００８】 ここ５年間のインターネットの目覚しい発展にともない、特に、「ＷＥＢ」型
遠隔サーバとリンクできるようにするために、ますます多くの端末がこのネット
ワークに接続している。インターネット網を構成する回線を介して搬送されるデ
ータに関しては限界が存在する。しかしながら、それら限界は、まず最初にデー
タの性質に関連するのではなく、特に、回線が許可する容量に関連する。最近、
設置されている大容量回線（ケーブル、「ＡＤＳＬ」型回線、衛星回線、ＲＮＩ
Ｓ等）が、今後、マルチメディア型のデータを伝達し、それをリアルタイムで処
理するのを可能にすることになる。

【０００９】 さらに、インターネットを介して電話通信、さらにはテレビ電話通信が行われ
るようにすることが特に興味深い。データ自体の伝送には、特に問題はない。デ
ータは、この型のネットワークで通常使用されているプロトコルによって処理す
ることができる。しかしながら、通信管理は、特有の問題、具体的には、従来の
電話において「シグナリング」と呼ばれるものに関連した問題が存在する。一般
に、この概念は、通信相手のコール、コールの受入れ、会話の開始と終了、呼出
し音、受話器を外すこと等のような動作を指している。

【００１０】 １９９０年代に、インターネットを介する電話コールを実現できるように、多
数のシステムおよびソフトウェアが提案された。

【００１１】 「インターネットフォン」（登録商標）と呼ばれるインターネット上の最初の
電話は、１９９５年にＶｏｃａｌｔｅｃ社が開発した。今日では、Ｍｉｃｒｏｓ
ｏｆｔ社の「ＷｅｂＰｈｏｎｅ」「ＮｅｔＭｅｅｔｉｎｇ」（両方とも登録商標
）など、数十種類の製品が存在する。

【００１２】 したがって、そこから生じた従来の技術は、大きな多様性、規格の欠如、また
は少なくとも実質的な標準の欠如という特徴を有する。そのことから、それらの
製品は相互運用性を持っていない。

【００１３】 しかしながら、現在、以下のような傾向を認めることができる。

【００１４】 ａ．擬似シグナリング（コールの通知、コールの受入れまたは拒否のための発
呼者の識別等）を実現するための「ＴＣＰ」型のポートの使用。

【００１５】 ｂ．たとえば、５．３Ｋｂｐｓから６．３ＫｂｐｓまでのＵＩＴ−Ｔ Ｇ７２
３（国際電気通信連合）方法による音声信号の圧縮。

【００１６】 ｃ．「ＲＴＰ」プロトコル（ＲＦＣ１８８９仕様に準拠する「リアルタイムプ
ロトコル」）を利用する音声の伝播。これは、それ自体「ＵＤＰ」（「ユーザデ
ータグラムプロトコル」）伝送プロトコルや日付入り「ＰＤＵｓ」（「プロトコ
ルデータユニット」）を使用し、「ＲＴＣＰ」コントロールプロトコル（「リア
ルタイムトランスポートコントロールプロトコル」）に関連する。

【００１７】 ｄ．その「ＩＰ」アドレスによる被呼者の識別。数多くのサーバが、固定メー
ルアドレスにサービス提供者または「プロバイダ」（英語では、「ＩＳＰ」また
は「インターネットサービスプロバイダ」）の「ＰＰＰ」型のサーバ、たとえば
「ＩＣＱ」という略語で知られたサーバによって付与される「ＩＰ」アドレスを
関連付けるのを可能にしている。

【００１８】 通信がインターネットから出なければならない場合には、「ＩＴＧ」（「イン
ターネット電話ゲートウェイ」）と呼ばれる電話インターネットゲートウェイに
よって、一般に英語略語「ＰＳＴＮ」（「公衆交換電話ネットワーク」）で知ら
れている交換型の公衆ネットワークを、インターネットに接続することが可能に
なる。ローカルネットワーク内および「ＲＮＩＳ」ネットワーク上（「デジタル
総合サービス網」または英語で「ＩＳＤＮ」）で使用されるパケットのフォーマ
ットを規定するプロトコル「Ｈ３２３」は、「ＣＣＰ」（「Ｃａｌｌ Ｃｏｎｔ
ｒｏｌ Ｐｒｏｔｏｃｏｌ」）と呼ばれるコールプロトコルの主要な規格となる
ように思われる。

【００１９】 インターネット上の電話には３種類の重要な問題がある。

【００２０】 ａ．ネットワークにおける加入者探索、すなわち（情報処理装置の）「ＩＰ」
アドレス関連を確立すること。

【００２１】 ｂ．電話コールのシグナリング管理（通信相手のコール、コールの受入れ、会
話の始まり、会話の終了）。この機能は、「インターネット−インターネット」
型のコールについてはいわゆる「プロプラエタリ」プロトコル（一般には、「シ
グナリングプロプラエタリプロトコル」または「ＰＳＰ」）によって、または、
「インターネット−ＲＴＣ」型のコールについては、標準化をめざす個別のプロ
トコル（上記の「ＣＣＰ」プロトコル）によって実行され、シグナリングは、以
下「シグナリングチャネル」または「ＣＳ」と呼ばれる「ＴＣＰ」接続を用いて
実行される。

【００２２】 ｃ．マルチメディアデータフローの交換。採用されるプロトコルは一般に、「
ＲＴＰ」（上記の仕様「ｒｆｃ１８８９」に準拠する「Ｒｅａｌ Ｔｉｍｅ Ｐ
ｒｏｔｏｃｏｌ」）と呼ばれるプロトコルであり、マルチメディアデータの交換
は、データチャネルを介して実行され、情報は上記のプロトコル「ＵＤＰ」によ
って搬送される。

【００２３】 インターネットでの電話の会話を確立するためには、発呼者および被呼者は、
同一ソフトウェアを使用しなければならない。図１は、電話ソフトウェア（「Ｌ
Ｔ」）、たとえば上記の「ＮｅｔＭｅｅｔｉｎｇ」ソフトウェアを構成する主要
モジュールを概略で示している。従来の電話ソフトウェアおよび関連伝送システ
ムのアーキテクチャは、以下のサブセットを含む。

【００２４】 ａ．加入者の識別を可能にする一連の情報を含む加入者プロファイル（「ＰＡ
」） ｂ．ディレクトリサーバ（たとえばポートＮｏ．３８９のような特定の「ＴＣ
Ｐ」ポート番号によって識別される「ＳＡ」）への加入者登録を実行する登録プ
ロトコル（「ＰＥ」） ｃ．加入者のサーチ機能をその識別子（一般にはｅメール）に基づいて実行す
る探索プロトコル（「ＰＬ」）。この機能は、ディレクトリサーバ（「ＳＡ」）
への接続を用いて実行される。

【００２５】 ｄ．特定のポート（ＮｅｔＭｅｅｔｉｎｇについてはＮｏ．１５０３）上のＴ
ＣＰ接続を介して電話コールを管理する、プロプラエタリシグナリングプロトコ
ル（「ＰＳＰ」）を実施するシグナリングチャネル（「ＣＳ」）。

【００２６】 ｅ．「ＲＴＰ」のようなデータ交換プロトコルを用いてリアルタイムデータ（
音声および／または画像）の交換を管理するデータチャネル（ＣＤ）。

【００２７】 オプションとして、インターネット上の電話ソフトウェアは、「ＴＣＰ」接続
（「ＮｅｔＭｅｅｔｉｎｇ」ソフトウェアの場合にはポートＮｏ．１７３１上の
）を用いて、コール管理プロトコル（「ＣＣＰ」）を使用しながら、標準電話ネ
ットワークの加入者に向かって発呼することができる。

【００２８】 本明細書に添付の図１は、上述した型の電話ソフトウェアを利用する、従来の
技術による、インターネットＲＩを介する電話システム９のアーキテクチャを概
略で示している。

【００２９】 この図では、２つの端末９ａおよび９ｂが概略的に示されているが、それぞれ
、それらを備えた電話ソフトウェア９０ａおよび９０ｂだけを示している。

【００３０】 これらのソフトウェアの構成要素は、各端末、９ａ、９ｂごとに、加入者プロ
ファイル（「ＰＡ」）９０３ａまたは９０３ｂに関連した、登録プロトコル「Ｐ
Ｅ」９００ａまたは９００ｂ、および探索プロトコル「ＰＬ」９０１ａまたは９
０１ｂを有する。加入者プロファイル「ＰＡ」は、一般に「ユーザＩＤ」という
呼称で知られている加入者の基本識別子ＡａまたはＡｂおよび、この加入者をよ
り完璧に識別する、以下に明示する種々のデータを有する。

【００３１】 登録プロトコル「ＰＥ」、９００ａまたは９００ｂによって、端末９ａまたは
９ｂに関連付けられた加入者、ＡａおよびＡｂは、インターネットＲＩに接続さ
れるディレクトリサーバ９１内に登録することができる。登録は、上記の加入者
プロファイル「ＰＡ」、９０３ａまたは９０３ｂ内に含まれる識別データを使用
することによって行われる。

【００３２】 ２人の加入者間の通信を確立しようとすると、着呼側加入者の探索段階に進む
ことが必要となる。たとえば、端末９ａが、端末９ｂと通信を確立しなければな
らない場合には、インターネットＲＩ上の端末９ｂのアドレス「ＩＰ」を知るこ
とが必要になる。

【００３３】 それらプロセスは、それ自体純粋交換型ネットワーク上の従来の電話にも共通
である。各加入者に対してコール番号、すなわち、１つまたは複数のディレクト
リ内にリストアップされた番号が割り当てられる。

【００３４】 しかしながら、加入者間、すなわち端末間の電話伝送を確実に行うのにインタ
ーネットに頼ることは、特有の制約を課す。

【００３５】 まず第１に、ネットワークにおける通信プロトコルの主要特性を思い起すこと
が有益であると思われる。

【００３６】 通信ネットワークのアーキテクチャは、さまざまな層により説明される。例と
して、「ＩＳＯ」によって規定される「ＯＳＩ」（「Ｏｐｅｎ Ｓｙｓｔｅｍ
Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ」）標準は、中間層、特に「トランスポート」
層を通過して、低層（たとえば物理伝送サポートに関する「物理」層）から高層
（たとえば「アプリケーション」層）までの７層を有する。任意の層は、適切な
インターフェイスを介して、すぐ上の層にサービスを提供し、すぐ下の層に他の
サービスを要求する。それらの層はプリミティブを用いて通信する。それらはま
た、同じレベルの層と通信することができる。特定のアーキテクチャにおいては
、複数の層を省くことも可能である。

【００３７】 インターネット型の環境においては、層は５つあり、より厳密に言えば、上層
から下層に向かって、アプリケーション層（「ＨＴＴＰ」、「ＦＴＰ」、「ｅメ
ール」等）、トランスポート層（「ＴＣＰ」）、ネットワークアドレシング層（
「ＩＰ」）、データリンク層（「ＰＰＰ」、「スリップ」等）、物理層がある。

【００３８】 従来の技術においては、加入者、ＡａおよびＡｂが、固定アドレス「ＩＰ」ま
たは、英語略語「ＩＳＰ」（「インターネットサービスプロバイダ」）で一般に
知られているインターネットサービス提供者に頼る場合には、可変アドレス「Ｉ
Ｐ」を所有するインターネット端末、９ａまたは９ｂを使用する。

【００３９】 第１の欠点は、「ＩＰ」アドレスが加入者にではなく、インターネットに接続
された情報処理システムに関連付けられる点である。情報処理システムが固定ア
ドレスを備えている場合であっても、「ＩＰ」アドレスと個人との間に先験的な
対応が存在しない。実質的に、このような関係を確立するために、加入者はディ
レクトリサーバ「ＳＡ」９１（「Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ」に
ついては、「ＩＲＣ」と呼ばれる型とすることができる）に接続される。このサ
ーバは、加入者の識別子、または「ユーザＩＤ」に、その「ＩＰ」アドレスを関
連付ける。識別子は、一般に、そのｅメール通信アドレス、または英語用語によ
れば「ｅメール」によって構成されるが、何らかの仮名を使用することもできる
。

【００４０】 こうした関連付けは、一般に認証されないので、サービス（通常は無料）が、
できるだけ便利な方法で利用できる。しかしながら、こうした措置もまた、とり
わけ「敏感な」アプリケーションについては欠点をもっている。

【００４１】 したがって、第１の制約のうちの１つは、インターネットＲＩにおける加入者
の探索、すなわち固定識別子と「ＩＰ」アドレスとの間の通信の確立である。

【００４２】 インターネットＲＩにおける加入者の探索、すなわち上記の通信の確立は、加
入者があらかじめ、ディレクトリサーバ「ＳＡ」内に登録されていることを前提
とする。

【００４３】 したがって、インターネット内の加入者のアドレスは、「ＳＡアドレス」と「
ユーザＩＤ」との組み合わせで構成される。通常、「加入者」とは、「物理的」
エンティティを意味する。拡大解釈によって、「機能」を対象とすることもでき
る。しかしながら、以下においては「加入者」とはその一般的な意味で使用し、
それは、本発明の範囲を限定するものではない。

【００４４】 実質的に、加入者は、上記の登録プロトコル「ＰＥ」を用いて、現在の「ＩＰ
」アドレスを（ディレクトリ）サーバに与えながら、自発的行為によってインタ
ーネットＲＩ内のその探索を指定する。

【００４５】 このオペレーションは、端末９ａまたは９ｂが、サービスプロバイダによって
付与され、個別の加入者プロファイル「ＰＡ」９０３ａまたは９０３ｂによって
個人化された特有のソフトウェア（またはアプリケーション）、この場合には、
ソフトウェア「ＰＥ」９００ａまたは９００ｂを所有することを意味している。

【００４６】 以上に示したように、加入者の基本的識別子（「ユーザＩＤ」）に加えて、加
入者プロファイル「ＰＡ」１０３ａまたは１０３ｂは、加入者の登録の際に、デ
ィレクトリサーバ「ＳＡ」９１に提供される情報全体、たとえば以下を有する。

【００４７】 − 「ディレクトリサーバ」（ＳＡ）のアドレス − ユーザが通信を始めることを承諾した相手、またはネットワーク内で自ら
の場所を通知することを望む相手である加入者（その「ユーザＩＤ」によって識
別される）、 − ディレクトリサーバにおいて公表されることを加入者が承諾する情報（た
とえば、名前、国籍、求められる連絡等）。

【００４８】 インターネットＲＩを通して通信相手と連絡するためには、その通信相手が正
式に登録されているのであれば、その「ＩＰ」アドレスを知る必要がある。こう
した情報は、ディレクトリサーバ「ＳＡ」９１、および探索プロトコル「ＰＬ」
それぞれ９０１ａまたは９０１ｂを用いて得られる。

【００４９】 加入者プロファイル「ＰＡ」は、本来、加入者に固有のものであるが、ディレ
クトリサーバ「ＳＡ」の特徴、具体的にはそれに提供されるべき、またはそれが
受け入れることのできる情報の型と種類に依存することができる点に留意しなけ
ればならない。

【００５０】 さらに、プロトコル「ＰＬ」９０１ａまたは９０１ｂは、先験的に標準化され
ていない、または世界的に認められている規格に適合していないディレクトリサ
ーバ「ＳＡ」９１をアドレスすることから、プロトコル「ＰＥ」９００ａまたは
９００ｂのように、プロプラエタリ型である点に留意しなければならない。端末
のプロトコル「ＰＥ」および「ＰＬ」は、それぞれ参照符号９１０と９１１が付
されたディレクトリサーバ「ＳＡ」９１内に設置された対応プロトコルと互換性
がなければならない。

【００５１】 これら２つの特徴は、さらに別の欠点を有する。

【００５２】 以上の点をまとめると、発呼側加入者Ａａが着呼側加入者Ａｂを探索し、着呼
側加入者によって探索されることができるためには、発呼側加入者が使用する端
末、たとえば９ａが、プロトコル「ＰＥ」および「ＰＬ」を実施できる、特定の
ソフトウェア、９００ａまたは９００ｂ、９０１ａまたは９０１ｂを保存するこ
とが必要である。同じく、その加入者は、その加入者プロファイル「ＰＡ」９０
３ａに割り当てられたデータを保存することが必要な場合もある。こうした指摘
は、他の加入者の端末、たとえば端末９ｂにも同様に当てはまる。

【００５３】 言い換えれば、いずれかの加入者ＡａまたはＡｂによって使用されている、端
末９ａまたは９ｂもまた、この加入者が端末を変えようとする場合には、最初の
端末において登録予備段階をすでに行ったことを認め、プロトコル「ＰＥ」を頼
り、ディレクトリサーバ「ＳＡ」にそのプロファイル「ＰＡ」を提供することに
よって、新しく使用する端末において、少なくとも１つまたは複数のプロトコル
「ＰＬ」に関連したソフトウェアを見つけ出さなければならないという意味にお
いて、それもまた特有である。実際に、プロトコル「ＰＬ」の存在は、ディレク
トリサーバ「ＳＡ」９１をアドレシングし、その中に登録されているデータ、特
にサーチされた通信相手のアドレス「ＩＰ」およびそのプロファイル「ＰＡ」に
アクセスするために必要である。

【００５４】 端末９ａまたは９ｂはまた、同じくプロプラエタリ型の２つの追加ソフトウェ
アの各々を備えていなければならない。２つの追加ソフトウェアとは、信号プロ
トコルＰＳＰ９０２ａまたは９０２ｂ、および上記のデータ交換プロトコル「Ｒ
ＴＰ」（またはそれに類するプロトコル）９０５ａまたは９０５ｂである。プロ
トコル「ＰＳＰ」に関連したモジュールは、インターネットＲＩを通し、シグナ
リングチャネルＣＳを介して互いに連絡する。同様に、プロトコル「ＲＴＰ」に
関連したモジュールは、インターネットＲＩを通し、データチャネルＣＤを介し
て、互いに連絡する。

【００５５】 さらに、電話通信が、切替えられた標準ネットワーク９３に向かってインター
ネットＲＩから出なければならない場合には、同じくプロプラエタリ型の上記の
コール管理プロトコル「ＣＣＰ」（またはそれに類するプロトコル）９０４ａま
たは９０４ｂを備えることが必要になる。また、プロトコル「ＣＣＰ」に関連し
たモジュール９０４ａとネットワーク「ＲＴＣ」９２との間で、ただ１つの参照
符号９２で示された、上記の「ＩＴＧ」型の１つまたは複数のゲートウェイを備
えることが必要である。加入者の電話機９５は、従来の「ＰＢＸ」局（構内電話
交換システム）９４または他の何らかの類似したシステムを介して、ネットワー
ク「ＲＴＣ」と通信する。ゲートウェイ「ＩＴＧ」９２と加入者端末、図１で表
されている例においては９ａとの間の通信は、「ＴＣＰ」型の接続を利用する。
「交換電話ネットワーク」における通信は、従来の方法で行われるので、ここで
これ以上説明するのは無駄である。

【００５６】 したがって、登録段階、特にインターネットＲＩにおける加入者の探索、シグ
ナリング（探索された加入者のコール等）、データ交換の段階などを実施するた
めに最適化された端末を使用することは興味深いであろう。そのことから「ノマ
ディズム」と呼ばれるコンセプトに便宜上アクセスすることが可能になる。

【００５７】 さらに、シグナリング段階において、着呼者と発呼者との間で確実な単純また
は相互認証手続きを実施することができることが興味深いであろう。ルーティン
グ経路の「予約」と呼ばれるオペレーションまたはデジタル化の鍵の交渉のよう
な、さまざまな交渉もまた、このシグナリング段階において実施できるにちがい
ない。同様に、データ交換段階においては、たとえば先に交渉した暗号化の鍵に
基づいて、情報の堅牢な暗号化／暗号解読を行えることが興味深い。さらに、交
換されたデータの量（容量）および／または使用可能なルーティング経路の量に
基づいて、料金決定を実施できることが興味深く、この経路は、たとえば、シグ
ナリングの先の段階において交渉された。

【００５８】 上記のプロトコルに関連したソフトウェア「ＰＥ」および「ＰＬ」は、通常、
大量のメモリを使用する必要はない。プロファイル「ＰＡ」のデータについても
同様である。したがって、スマートカードのメモリ回路の中で、それら全部また
は一部を登録しようと考えることができるだろう。これは現行の技術で可能であ
る。

【００５９】 しかしながら、以下に示すように、二重の技術的困難に直面し、その結果、イ
ンターネットＲＩとスマートカードとの間のあらゆる直接通信が行えなくなって
しまう。

【００６０】 まず第１に、図２Ａおよび２Ｂを参照して、インターネットに接続された、ス
マートカードに基づいてアプリケーションシステムの全体的アーキテクチャを簡
単に思い起そう。

【００６１】 スマートカードに基づくアプリケーションシステムは、一般に、以下の主要エ
レメントを有する。

【００６２】 − スマートカード − 上記端末を構成するホストシステム − 通信ネットワーク、すなわち好ましいアプリケーションにおけるインター
ネット − インターネットに接続されるアプリケーションサーバ。

【００６３】 図２Ａは、この型のアーキテクチャの一例を概略で示している。端末１、例え
ば個別コンピュータは、スマートカード２の読取装置３を有する。この読取装置
３は、端末１内に物理的に一体化することも一体化しないことも可能である。本
発明の枠組みにおいて、端末１は、図１のシステムの端末９ａまたは９ｂの役割
を果たす。スマートカード２は、入出力接続が、端末１との通信および電気エネ
ルギー供給を許可するためにそのサポートの表面と同じ高さにある集積回路２０
を有する。この端末は、インターネットＲＩへのアクセス回路１１を有する。こ
れら回路は、交換電話回線または、より高容量の通信手段、すなわち、サービス
統合型デジタルネットワーク（「ＲＮＩＳ」）、衛星によるケーブルまたは回線
等に接続されるために、モデムで構成される。回路１１は、直接またはインター
ネットサービス提供者（英語では「インターネットサービスプロバイダ」または
「ＩＳＰ」）を介して、インターネッＲＩに接続されることができる。同じく、
「プロキシ」または「ファイアウォール」と呼ばれる（（フランス語では）「ｐ
ａｒｅ−ｆｅｕ」または「ｇａｒｄｅ ｂａｒｒｉｅｒｅ」とも呼ばれる）シス
テムのような中間システムに頼ることもできる。

【００６４】 端末１は、当然のことながら、図面を簡略化するためにここには図示されてい
ないが、中央処理装置、ＲＡＭおよびＲＯＭ、磁気ディスク大容量メモリ、ディ
スクドライブおよび／またはＣＤＲＯＭドライブ等といった、その円滑な作動に
必要なあらゆる回路および機構を備える。

【００６５】 通常、端末１はまた、ディスプレイスクリーン５、キーボード６ａ、マウス６
ｂ等のような、一体型または非一体型の従来の周辺装置に接続される。

【００６６】 端末１は、ネットワークＲＩに接続されたあらゆる情報処理システムまたはサ
ーバと通信することができるが、そのうちの１つのサーバ４だけが、図２Ａに表
されている。本発明の範囲内で、サーバ４は、ディレクトリサーバ９１（図１）
で構成され、端末１は、加入者ＡａまたはＡｂに関連した、システムの１つ９ａ
または９ｂで構成される。アクセス回路１１は、「ＷＥＢ」ブラウザまたは英語
によれば「ブラウザ」と呼ばれる、個別のソフトウェア１０によって、端末１を
サーバ４と通信させる。ブラウザは、一般に「クライアント−サーバ」モードに
従って、ネットワークＲＩ全体に分配されたさまざまなアプリケーションまたは
データファイルにアクセスすることができる。

【００６７】 インターネットＲＩにおける通信プロトコルは、「ＷＥＢ」ページの問合わせ
、ファイルの転送、電子郵便（ｅメール）、フォーラムまたは「ニュース」等の
とりわけターゲットとなるアプリケーションに応じて選択される。

【００６８】 端末、スマートカードの読取装置、スマートカードを有するシステムの論理ア
ーキテクチャは、図２Ｂに概略的に表わされている。また、それ自体が以下のよ
うな複数のサブアセンブリを有する、規格ＩＳＯ ７８１６に記載されている。

【００６９】 − カードの寸法およびマーキングに関してはＩＳＯ ７８１６−１および７
８１６−２。

【００７０】 − 端末のスマートカード間のデータの転送に関してはＩＳＯ ７８１６−３
。

【００７１】 − 一式の命令の構造とコマンドのフォーマットに関してはＩＳＯ ７８１６
−４。

【００７２】 図２Ｂでは、端末側１に、参照符号１０１として規格ＩＳＯ ７８１６−３に
合致した層と、参照符号１０２の命令管理「ＡＰＤＵ」（規格ＩＳＯ ７８１６
−４）のみが表されている。スマートカード２側では、規格７８１６−３に適合
した層に参照符号２００が付され、命令管理「ＡＤＰＵ」（規格ＩＳＯ７８１６
―４）に参照符号２０１が付されている。アプリケーションには、参照符号Ａ_１ 、…、Ａ_ｊ…、Ａ_ｎが付されるが、この場合、ｎは、スマートカード２上に存在
する最大数のアプリケーションである。

【００７３】 アプリケーションＡ_ｊは、スマートカード２内に存在し、一式の命令を用いて
端末１と対話する。この一式の命令は、通常、書込み命令と読取り命令を有する
。命令のフォーマットは、英語略語「ＡＰＤＵ」（「アプリケーションプロトコ
ルデータユニット」）で知られている。これは上記の規格ＩＳＯ ７８１６−４
によって規定される。コマンド用「ＡＰＤＵ」は、「ＡＰＤＵ．ｃｏｍｍａｎｄ
」と記され、応答用「ＡＰＤＵ」は「ＡＰＤＵ．ｒｅｓｐｏｎｓｅ」と記される
。「ＡＰＤＵ」は、上記の規格ＩＳＯ ７８１６−３によって特定されたプロト
コルを用いて、カードの読取装置とスマートカードとの間で交換される（たとえ
ば、キャラクタモードではＴ＝０となる。またはブロックモードではＴ＝１とな
る）。

【００７４】 スマートカード２が、図２Ｂに表されているように、複数の別々のアプリケー
ションを含むと、マルチアプリケーションカードが問題となる。しかしながら、
端末１は、同時にただ１つのアプリケーションとしか対話しない。

【００７５】 個別のアプリケーションＡ_ｊの選別は、選別型の「ＡＰＤＵ」（「ＳＥＬＥＣ
Ｔ」）を用いて得られる。いったんこの選択がなされると、それに続く「ＡＰＤ
Ｕ」が、そのアプリケーションに向って辿られる。新しい「ＡＰＤＵ ＳＥＬＥ
ＣＴ」は、結果的に、進行中のアプリケーションを放棄して、そこから他のアプ
リケーションを選択する。「ＡＰＤＵ」２０１の管理者ソフトウェアのサブアセ
ンブリによって、スマートカード２内で個別のアプリケーションＡ_ｊを選択し、
そのように選択されたアプリケーションを記憶し、そのアプリケーションに向か
って「ＡＰＤＵ」を伝達し、またそのアプリケーションから「ＡＰＤＵ」を受取
ることが可能になる。

【００７６】 以上をまとめると、アプリケーションＡ_ｊの選別と、そのアプリケーションと
の対話は、命令「ＡＰＤＵ」の交換によって行われる。アプリケーションＡ_ｊは
、以下「ＧＣＡ」（「包括的カードアプリケーション」）と呼ばれる従来のアプ
リケーションであると仮定される。

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

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

【００７９】 本発明は、必要であると判断されるものに適合させながらも、上述したいくつ
かの欠点を含む従来の技術による方法および装置の欠点を解消することにある。

【００８０】 本発明によれば、登録プロトコル「ＰＥ」および探索プロトコル「ＰＬ」の実
施に必要なアプリケーション、ならびに、加入者プロファイル「ＰＡ」を特徴付
けるデータは、好ましくは、スマートカードのメモリ内に全体または一部が保存
されるファイルであり、実行ファイルは上記の「ＧＣＡ」型の標準アプリケーシ
ョンである。

【００８１】 本発明によれば、スマートカードは、それに関連した端末のための「ＷＥＢ」
型のサーバ／クライアントとして行動する。

【００８２】 そのために、スマートカード内に特有の通信ソフトウェア層と、端末内にその
対になるものが備えられる。「特有の」という用語は、本発明の方法に特有と解
釈されなければならない。というのも、特有と呼ばれるこれらの通信層は、当該
のアプリケーションがどのようなものであれ一般化されるからである。とりわけ
、それらは、上記の種々のプロトコルの実施に必要なアプリケーションからは独
立している。それらは、一方ではスマートカードと端末との間の、他方ではスマ
ートカードとネットワークとの間の双方向データ交換プロセスにしか関わらない
。

【００８３】 特有の通信ソフトウェア層は、とりわけプロトコルの会話を可能にする、「イ
ンテリジェントエージェント」と呼ばれるソフトウェアの構成要素を有する。イ
ンテリジェントエージェントは、以下、より単純に「エージェント」と呼ぶ。そ
れぞれ端末とスマートカードに関連した特有の通信層内に並べられたエージェン
トが存在する。本発明の方法によれば、こうしたエージェント間にセッションが
確立される。

【００８４】 本発明の方法は、従来の型、すなわち、いかなる点においても変更の必要なく
、スマートカード内で探索された、上記の「ＧＣＡ」型のアプリケーションの起
動を可能にする点に留意されたい。

【００８５】 そのために、ブラウザの要求を受取り、それらを「ＧＣＡ」型のアプリケーシ
ョンによって理解可能な命令「ＡＰＤＵ」に翻訳するスクリプト変換と呼ばれる
個別のインテリジェントエージェントが備えられる。そのことから、スマートカ
ード内に、そもそも従来の「ＷＥＢ」サーバ内では「ＣＧＩ」の名称で知られて
いる類似機能が設けられる。この機能は「ＨＴＴＰ」型のインターネットプロト
コルによって、スマートカード内でのアプリケーションの実施を可能にする。

【００８６】 これらのさまざまな措置によって、スマートカード、より厳密にはスマートカ
ード内に存在するアプリケーションは、インターネット型のプロトコルの実施に
よってインターネットに接続された遠隔サーバと直接的に通信することを可能に
する。スマートカードによって提供される「ＣＧＩ」機能によって、その部分に
ついては、端末内にプロプラエタリ型のアプリケーションの存在を必要とせずに
、登録プロトコル「ＰＥ」と探索プロトコル「ＰＬ」に関連したアプリケーショ
ンへのアクセスが可能になる。有利にも、市販されている標準型のブラウザのみ
が必要となる。

【００８７】 本発明の有利な特徴によれば、スマートカード内に、以下「フィルタ」と呼ば
れる個別のアプリケーションが設置される。ここでは「プロキシ」と類似の役割
を果たすソフトウェアエンティティが問題となる。そのためには、エージェント
を利用する上記の措置に頼ることになる。

【００８８】 こうした措置によって、スマートカードは、信号プロトコルの「プロキシ」（
「ＴＣＰ」型）および／またはデータ交換プロトコルの「プロキシ（「ＵＤＰ」
型）として行動することが可能になる。

【００８９】 シグナリングプロキシの利点は、たとえば、通信の受入れのために役に立つこ
ともできる発呼者と被呼者との間の単純なまたは相互の認証手続きを実施するこ
とができる点である。また、暗号化の鍵の交渉が可能になる。さらに、たとえば
、一定の伝送の品質または高い通過周波数帯を保証することによって、先験的に
、最適化されたルーティング経路を交渉することができる。

【００９０】 データ交換プロキシの主な利点は、情報の暗号化／暗号解読の堅固な手続きを
実施できることにある。プロキシはまた、たとえば先に交渉された経路の型また
は容量に基づいて、料金決定手続きを実施することもできる。

【００９１】 したがって、これらの特徴は、上述した必要性に十分に応えることができる。

【００９２】 したがって、本発明は、第１の加入者と第２の加入者との間のインターネット
型ネットワークを介するマルチメディアデータの伝送管理方法であって、シグナ
リングチャネルを介する少なくとも１つのシグナリングデータ交換段階と、デー
タチャネルを介する少なくとも１つのマルチメディアデータ交換段階とを含み、
さらに少なくとも前記の第１の加入者システムは、「ＷＥＢ」型ブラウザと、ス
マートカードと協働するスマートカード用の読取装置とを備えた端末を有し、前
記のスマートカードは、特有の通信プロトコル層を形成する第１のソフトウェア
を有し、前記の端末は、少なくとも前記の「ＷＥＢ」型ブラウザとのインターフ
ェイスを形成する第２のソフトウェアを有する方法を主な対象とする。前記の第
１および第２のソフトウェアは各々、さらに、クライアント型の第１の独立ソフ
トウェアエンティティと、サーバ型の第２の独立ソフトウェアエンティティを有
し、前記のエンティティは、前記端末と前記スマートカードとの間の双方向デー
タ交換セッションの確立を可能にし、前記スマートカードが「ＷＥＢ」型のクラ
イアント／サーバの機能を提供することが可能になり、さらに前記のインターネ
ット型ネットワークを介して、前記の第１の加入者システムと前記の第２の加入
者システムとの間の双方向データ交換セッションを確立することが可能になるよ
うに協働し、前記の独立ソフトウェアユニットは、あらかじめ設定されたプロト
コルデータユニットを用いて通信することを特徴とし、 − 前記の特有の第２のソフトウェア内に含まれる、クライアントとサーバそ
れぞれの型の前記の第１および第２の独立ソフトウェアエンティティに向かって
および／またはそれらエンティティからプロトコルデータユニットを受信および
／または送信する、フィルタと呼ばれる一定の機能的特徴を持つアプリケーショ
ンソフトウェアの前記スマートカード内での実装を含み、前記アプリケーション
ソフトウェアの実装は、サーバ型の前記の独立ソフトウェアエンティティの制御
の下になされることを特徴とし、 − 前記のフィルタは、前記の信号データおよび／またはマルチメディアデー
タの交換段階中に、前記シグナリングチャネルおよび／またはデータチャネルの
少なくともいずれか１つを介して、「プロキシ」と呼ばれる機能を形成し、前記
の第１の加入者システムと前記の第２の加入者システムとの間を通過するデータ
交換のあらかじめ設定された特徴を制御するために、特有の前記の第１のソフト
ウェアの前記の独立ソフトウェアエンティティとのセッションを開くために特有
の前記の第２のソフトウェアの独立ソフトウェアエンティティと協働することを
特徴とする。

【００９３】 本発明はまた、この方法の実施のためのスマートカードを対象とする。

【００９４】 添付の図面を参照して、以下に、本発明の好ましく、しかも限定的でない実施
形態を説明する。

【００９５】 以下において、反対の記載がない限り、本発明の好ましい適用の枠組み、すな
わちインターネットを介する電話伝送の場合には、範囲は限定しないものとする
。

【００９６】 図３は、スマートカードが「ＷＥＢ」クライアント／サーバとして作動するこ
とを可能にする、本発明の第一の様態によるスマートカードに基づくアプリケー
ションシステムの一例を概略的に表わす図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１４３】 実際に、エージェントは、（たとえば、ハイパーテキストの）データの交換を
可能にするが、しかも、スマートカード２ａと遠隔サーバ４との間の通信を許可
する、ネットワークトランザクションを開始することができる（図３）。

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

【０１４５】 実際に、スマートカード２ａは、有利には、外部サーバへのポインティングで
はなく、端末１それ自体へのループバックを規定する「ＵＲＬ」アドレス（「Ｕ
ｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」の略）の使用によって
「アドレシング」される。例として、この「ＵＲＬ」の構造は通常以下の通りで
ある： ｈｔｔｐ：／／１２７．０．０．１：８０８０ （１） ここで、１２７．０．０．１は、ループバックの「ＩＰ」アドレスであり、８
０８０は、ポート番号である。

【０１４６】 図５は、図３に示された型の本発明によるシステムの論理アークテクチャを簡
略に、しかもより詳細に表している。スマートカード２ａは、複数のエージェン
トを有するが、そのうちの２つだけがここに図示されている。厳密には規定され
ていない型のエージェント２３２ａ_１と「ＷＥＢ」型と呼ばれるエージェント２
３２ａ_２である。論理スタックは、規格ＩＳＯ ７８１６−３に合致した参照符
号２００ａを付された、プロトコル下層（図２：ＣＣａ_１およびＣＣａ_２）と、
コマンド管理「ＡＰＤＵ」２０１ａ_１と、パケットのマルチプレクサ２３０ａと
を有し、このマルチプレクサは、エージェント、特に「ＷＥＢ」エージェント２
３１ａ_２にインターフェイスされる。

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

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

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

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

【０１５１】 本発明の枠組みにおいては、アプリケーション、Ａ_１からＡ_ｎの全体または一
部は、上記のプロトコル「ＰＥ」、「ＰＬ」の１つまたはいくつかに関連付けら
れるアプリケーションによって構成され、スマートカード２ａのメモリ内にロー
ドすることができる。さらに、１つまたは複数の「ＰＡ」プロファイルを表わす
データも、スマートカード２ａ内に保存される。

【０１５２】 スマートカード２ａによって与えられる「ＷＥＢ」クライアント／サーバ機能
だけでは、１つのアプリケーションを実行するのに十分ではない。さらに補足機
能を付け加える必要がある。

【０１５３】 というのも、本発明の他の様態によれば、スマートカード２ａによって与えら
れる「ＷＥＢ」クライアント／サーバ機能は、従来の「ＷＥＢ」サーバ内に設置
された「ＣＧＩ」（「Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ−共
通ゲートウェイインターフェイス」の略）と呼ばれる機能に類似のメカニズムを
含む。

【０１５４】 スマートカード内であっても、この型の機能を実行できる本発明に合致したア
ーキテクチャの一例を示す前に、「ＣＧＩ」作動モードの主要な特徴を思い起す
ことが有益である。

【０１５５】 「ＣＧＩ」は、オペレーティングシステム「ＵＮＩＸ」（登録商標）、「ＤＯ
Ｓ」、または「ＷＩＮＤＯＷＳ」（商標）のために書き込まれたアプリケーショ
ンの「ＷＥＢ」サーバからの実施仕様である。例として、「ＵＮＩＸ」オペレー
ティングシステムについては、仕様は「ＣＧＩ １．１」であり、「ＷＩＮＤＯ
ＷＳ９５」オペレーティングシステムについては、仕様は「ＣＧＩ １．３」で
ある。

【０１５６】 常に例示的なものとして、「ホスト」がホストシステム（一般に遠隔）を参照
する、 「ｈｔｔｐ：／／ｗｗｗ．ｈｏｓｔ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｘｘｘ．ｃｇ ｉ」 （２） の型の「ＵＲＬ」アドレスについての要求「ＨＴＴＰ」は、「ｘｘｘ」と名付け
られ、このホストシステムのディレクトリ内に存在する「ＣＧＩ」型のコマンド
スクリプトの実行として、「ＷＥＢ」サーバによって解釈される。ディレクトリ
の名前は、先験的に何でもよいにもかかわらず、それは、従来、「ＣＧＩ」型の
スクリプトを保存するディレクトリに与えられる名前である。スクリプトは、ホ
ストシステムのオペレーティングシステムの命令セットであり、その最終的結果
は、上記の要求を送信する「ＷＥＢ」ブラウザに伝送される。このスクリプトを
書き込むために、種々の言語、たとえば「ＰＥＲＬ」言語（登録商標）を使用す
ることができる。

【０１５７】 実際には、要求は、通常、「ＨＴＬＭ」ページ内に含まれる書式の形で情報処
理スクリーンに表示される。「ＨＴＬＭ」言語は、書式を「ＵＲＬ」アドレスに
翻訳することができる。書式は、強制的または非強制的に１つまたは複数のフィ
ールドを有し、それらは、通常の入力手段、すなわち、テキスト用にはキーボー
ド、チェックボックスにはマウス、または「ラジオ」と呼ばれるボタン等を用い
てユーザによって書き込まれる。書式の内容（さらに、場合によっては「隠し」
情報と呼ばれる情報および命令）は、「ＷＥＢ」サーバ宛てに送信される。ペー
ジの「ＨＴＬＭ」コードは、書式のハードウェア構造（枠、デザイン、色、他の
あらゆる属性）、ならびにインプットされるデータフィールドの構造（名称、長
さ、データの型等）を説明する。

【０１５８】 伝送は、２つの型の主要なフォーマットに従って行うことができる。最初のフ
ォーマットは、「ＰＯＳＴ」と呼ばれる方法を使用し、第２のフォーマットは「
ＧＥＴ」と呼ばれる方法を使用する。フォーマット型情報は、書式ページのコー
ド内に存在する。

【０１５９】 しかしながら、このメカニズムは、スマートカードが、本発明の特徴のいずれ
か１つに従って「ＷＥＢ」クライアント／サーバ機能を提供するとしても、直接
スマートカードに移し替えられるわけではない。

【０１６０】 ここで、図６を参照して、スマートカードにおける「ＷＥＢ」サーバを介して
、従来型の何らかのアプリケーションを起動することができるアーキテクチャの
一例を説明しよう。

【０１６１】 本発明の様態の１つに従って備えられたインテリジェントエージェントの中に
は、以下、「スクリプト変換エージェント」、または略して「ＡＴＳ」と呼ばれ
る個別のインテリジェントエージェントが備えられる。こうして、スクリプトは
、これら「ＡＴＳ」エージェントの１つによって解釈される。この翻訳は、以下
のように種々の方法で実行することができる。

【０１６２】 ａ．この場合、二重の容量を備える、「ＷＥＢ」エージェント２３２ａ_１によ
って、 ｂ．スマートカード２ａ内に存在するスクリプトの集合を翻訳することができ
る単一のスクリプトエージェントによって、 ｃ．以下「ＡＴＳＤ」と呼ばれる専用スクリプトエージェント（スクリプトご
とに１つのエージェント）によって、または ｄ．その場合、二重の容量を備えた、命令管理「ＡＰＤＵ」２０１ａの「ＡＰ
ＤＵ」エージェント２０１０ａによって。

【０１６３】 「ＡＰＤＵ」エージェント２０１０ａは、命令管理「ＡＰＤＵ」層２０１ａの
構成要素である。この層は、システムによって送信および／または受信されるあ
らゆる「ＡＰＤＵ」命令を集中させ、Ａ_１からＡ_ｎの中からアプリケーションを
選別し、しかもインテリジェントエージェント型のインターフェイスを提供する
ことができる層である。したがって、本発明の特徴の１つによれば、それらエー
ジェントが端末１内で探索されようと、スマートカード２ａ内で探索されようと
、あらゆるインテリジェントエージェントと通信することができる。

【０１６４】 上記のｃ．の場合には、セッションは、「ＷＥＢ」エージェント２３２ａ_１と
「ＡＴＳＤ」エージェントの１つとの間で開始される。

【０１６５】 図６は、変換エージェントが「ＡＴＳＤ」型であるようなアーキテクチャの一
例を表している。それらは、参照符号ＡＴＳ_１からＡＴＳ_ｎが付されているが、
アプリケーションＡ_１からＡ_ｎに関連付けられる。選別されたアプリケーション
は、アプリケーションＡ_ｉであると想定されるので、セッションは「ＷＥＢ」エ
ージェント２３２ａ_１とエージェントＡＴＳ_ｉとの間に確立される。

【０１６６】 スクリプト変換エージェントは、命令セット「ＡＰＤＵ」を発生する。セッシ
ョンは、変換エージェント、たとえばエージェントＡＴＳ_ｉと「ＡＰＤＵ」エー
ジェント２１０１ａの間で開始される。こうして、命令は、「ＡＰＤＵ」命令２
１０１ａに向かって送信される。命令管理「ＡＰＤＵ」２１０ａは、「ＣＧＡ」
アプリケーションＡ_ｉを選別し、そのアプリケーションが理解することができる
命令「ＡＰＤＵ」、翻訳された命令、すなわち従来の命令をそのアプリケーショ
ンに伝達する。したがって、このアプリケーションは、それを変更するまたは再
び書き込みする必要なく、正確に起動される。

【０１６７】 アプリケーションＡ_ｉの応答は、命令管理「ＡＰＤＵ」２１０ａ、「ＡＰＤＵ
」エージェント２０１０ａに、さらに再びエージェントＡＴＳ_ｉ（一般的にはス
クリプト変換エージェントに）に伝送される。

【０１６８】 種々の経路が、関数型ブロックをつなぐ実線によって、またはこれらブロック
の内部の点線によって図６に記号で表されている。

【０１６９】 １つまたは複数のディレクトリサーバにおける加入登録オペレーションおよび
／または着呼側加入探索を実施するために、本発明による方法は、上記の２つの
特徴、すなわち、「ＣＧＩ」機能を含む、「ＷＥＢ」サーバ／クライアントとし
てスマートカードの作動を利用する。

【０１７０】 本発明の好ましい実施形態によれば、加入登録プロトコル「ＰＥ」および／ま
たは加入探索プロトコル「ＰＬ」に関連付けられるアプリケーション、さらに１
つまたは複数の加入プロファイルは、スマートカード２ａ内に登録される。

【０１７１】 ここで、図７Ａから９を参照して、加入者登録および／または着呼側加入者探
索のための本発明による方法の種々の段階およびステップを、より詳細に説明し
よう。

【０１７２】 第１のステップは、以下の参照符号ＳＡ_ｉが付される個別のディレクトリサー
バ内の加入者プロファイルの登録に関するものである。このディレクトリは、従
来の技術に合致したディレクトリであり（たとえば図１：９１）、本発明による
方法は、既存の方法と完全に互換性をもったままである。

【０１７３】 図７Ａに表された第１のステップにおいては、スマートカード２ａは、層１３
および２３ａを介して、端末１のブラウザ１０によってアドレシングされる。た
とえば、「ＧＥＴ」型のコマンドによって、スマートカード２ａからのロード書
式、すなわち恣意的に「ｄｏｗｎｌｏａｄ．ｈｔｍｌ」と呼ばれる書式「ＨＴＭ
Ｌ」をリトリーブする。

【０１７４】 このリトリーブは、ＵＲＬが通常、以下の形をとる、対応ページを閲覧するこ
とによって行われる。

【０１７５】 ｈｔｔｐ：／／１２７．０．０．１：８０８０／ｄｏｗｎｌｏａｄ．ｈｔｍｌ （３） ｈｔｔｐ：／／１２７．０．０．１：８０８０は、関係式（１）によって規定
したような、いわゆるループバックのＵＲＬアドレスであり、「ｄｏｗｎｌｏａ
ｄ．ｈｔｍｌ」は、得られる「ＨＴＭＬ」ページである。この要求は、本発明の
第１の様態による、図２から４を参照してすでに説明したように対になったエー
ジェント間のセッションを利用する。

【０１７６】 スマートカード２ａは、常に、本発明の方法による、対をなすインテリジェン
トエージェント間のセッションの開始によって、第２ステップの場合に書式「ｄ
ｏｗｎｌｏａｄ．ｈｔｍｌ」を送信する。得られた書式は、ブラウザ１０を介し
て、スクリーン５ａに表示することができ、このプロセスを概略的に表わす図７
Ａでは参照符号Ｐで表わされる。この書式は、ディレクトリサーバＳＡ_ｉに登録
しようとする加入者のための受入れページを構成する。こうして、スマートカー
ド２ａは、「ＷＥＢ」サーバとして行動する。

【０１７７】 ページＰは、通常、グラフィック型および／またはテキスト型の種々のエレメ
ントと、さらにコマンドの相互作用エレメント（「ラジオ」と呼ばれる型のボタ
ン、ダイアログボックス、データの入力ゾーン等）を有することができる。

【０１７８】 まず第一に、スマートカード２ａは、そのキャリア（図示せず）に、ＰＡ_ｕと
呼ぶことができる単一の加入プロファイルに従って、ＳＡ_ｕと呼ぶことができる
、単一ディレクトリサーバに登録する可能性を与えると想定しよう。さらに、こ
の単一プロファイルＰＡ_ｕは、スマートカード２ａ内に登録される。この仮説に
おいて、スクリーン５ａ上に表示される書式Ｐ（すなわち受入れページ）は、最
小レイアウトに縮小することができ、図７Ｂは、その可能な一例、書式Ｐ_１を表
している。

【０１７９】 書式Ｐ_１は、単一のリファレンスＺ_ｔの下で、テキストの種々のゾーンを有す
る。これらゾーンは、通常、ディレクトリサーバ（ＳＡ_ｕ）の名「ｘｘｘ」と提
案されたアクション「登録」とさまざまなヘルプ（たとえば、ここをクリックし
なさい」）を表示する。加入プロファイルＰＡ_ｕのデータがスマートカード２ａ
内に登録されていると想定した以上、送信ボタンＢ_ｓを備えればよい。加入者に
とって、マウスを用いてこのボタンをクリックする（図２Ａ：６ｂ）、またはキ
ーボードの「エントリー」キーを押すことで（図２Ａ：６ａ）、スマートカード
２ａに向かって書式の送信が始まる。

【０１８０】 本発明による方法の他の変形形態においては、加入プロファイルに割り当てら
れるデータは、その方法によって直接インプットされる。この仮説において、書
式はより複雑である。図７Ｃは、参照符号Ｐ_２が付された書式の可能な一例を表
している。それは、単一リファレンスＺ_ｔ２の下に、図７Ｂのゾーン（Ｚ_ｔ）に
類似の固定テキストの第１ゾーンＺ_ｔ１と、１つまたは複数のデータインプット
ゾーンとを有する。先述したように、送信ボタンＢ_ｓだけでなく、有利には、エ
ラーの場合にインプットされたデータを消去することができる書式Ｐ_２の再初期
化ボタンＢ_ｒａｚが備えられる。１つまたは複数のデータのインプットゾーンは
、「ＨＴＭＬ」言語において「ＴＥＸＴＡＲＥＡ」と呼ばれる型であり、長文テ
キストの表示のために「エレベータ」と呼ばれるファシリティを有することがで
きる。

【０１８１】 このような書式をプログラミングするのに必要な「ＨＴＭＬ」コードは、それ
自体良く知られており、当業者に理解される。したがって、ここで、これ以上詳
しく説明する必要はない。しかしながら、特に、通常、以下の形をとる「ＨＴＭ
Ｌ」言語におけるコードラインを含む点を指摘できる。

【０１８２】 ＜ｆｏｒｍ ａｃｔｉｏｎ＝”ｈｔｔｐ：／／１２７．０．０１：８０８０／ ｃｇｉ−ｓｍａｒｔ／ｐｅ”＞ （４） ここで、ｈｔｔｐ：／／１２７．０．０．１：８０８０は、関係式（１）のル
ープバックのＵＲＬであり、「ｃｇｉ−ｓｍａｒｔ」は、たとえば参照符号Ａ_ｅ が付された、スマートカード２ａ内に保存されたアプリケーションに関連付けら
れたスクリプト「ｐｅ」である。このアプリケーションは、プロファイルＰＡ_ｕ とともに、ディレクトリＳＡ_ｕへの加入者登録を可能にする。このアクションは
、スマートカード２ａによって提供される機能、一方では「ＣＧＩ」、他方では
クライアント／サーバを利用することによって、図５および６を参照して説明し
た方法で行われる。アプリケーションＡ_ｅは、クライアントとして行動する。

【０１８３】 前者の場合には（図７Ｂ）、パラメータをスマートカード２ａに通す必要はな
い。というのも、加入者プロファイルデータＰＡ_ｕは、単一であり、スマートカ
ード２ａ内に登録されるからである。

【０１８４】 後者の場合には（図７Ｃ）、インプットされたデータは、要求「ＨＴＴＰ」の
形で、パラメータとして、スマートカード２ａを通る。

【０１８５】 図７Ｄは、インターネットＲＩを介して、ディレクトリサーバＳＡ_ｕへの加入
者の登録段階の総合的プロセスを、概略的に示している。

【０１８６】 単一リファレンスＳ_ＷＥＢは、図５および６を参照して詳しく述べられた種々
のモジュール、すなわち、スマートカード２ａが、クライアント／ＷＥＢサーバ
とゲートウェイ「ＣＧＩ」とを組み合わせた機能を提供することを可能にするモ
ジュールを包括する。さらに、登録プロトコル「ＰＥ」の利用を可能にするアプ
リケーションは、専用のスクリプト変換エージェントＡｔ_ｅに関連付けられると
想定された。図６に表されたものと合致する構成が対象となる。しかしながら、
すでに示したように、スクリプトの翻訳は、他の方法（「ＷＥＢ」エージェント
２３２ａ_１により）等で行うこともできる。対になったエージェント間のセッシ
ョンの開始による、書式の送信は、スクリプト変換エージェントＡｔ_ｅを介して
、アプリケーションＡ_ｅを起動することができる。

【０１８７】 その後のステップにおいては、アプリケーションＡ_ｅは、エージェント対の間
の、特に「ネットワーク」型のエージェントを関係させるセッションの開始のた
めに要求「ＨＴＴＰ」を出す（図６：１３２）。要求は、パラメータの通過とと
もに、ディレクトリサーバＳＡ_ｉに伝達される。パラメータは、ディレクトリ内
の登録が可能になるように、特に加入者プロファイルデータによって構成される
。ディレクトリサーバの「ＵＲＬ」アドレスは、スマートカード２ａ内に登録さ
れる加入者プロファイルから、または、書式Ｐ_２内にインプットされるデータか
ら得られる（図７Ｃ）。

【０１８８】 先験的に、登録プロセスは、この段階で終了する。しかしながら、１つまたは
複数の補足ステップをもつこともできる。それらのステップの１つは、スマート
カード２ａをアドレシングする要求「ＨＴＴＰ」の形で、受信通知のディレクト
リによる送信とすることもできる。受信通知は、登録が十分な形で行われたこと
を示す情報、または反対にエラーコードを含むこともできる。後者の場合には、
登録プロセスは、繰り返されなければならない。サーバは、不足データの送信ま
たは不正確なまたは改竄されたデータの再送信を要求することができる。登録の
要求はまた、特に加入の有効期限が過ぎている場合には、拒否されることもある
。

【０１８９】 本発明による方法の好ましい変形実施形態においては、加入者にとっては、複
数の異なるディレクトリに登録することが可能である。この変形実施形態におい
ては、一般に、複数の登録プロトコルも使用できるようにすることが必要である
。そのためには、それらプロトコルに関連付けられた複数のアプリケーションが
、スマートカード２ａ内に保存され、別々のプロトコルの最大数をｎとすると、
参照符号Ａ_ｅ１…、Ａ_ｅｉ…、Ａ_ｅｎ…、を付すことができる。

【０１９０】 先述したように、加入者プロファイルに関連付けられたデータＰＡ_１…、ＰＡ _ｉ …、ＰＡ_ｑ…、は、スマートカード２ａ内に保存される、または反対に、適切
な書式内にインプットすることによって、図７Ｃを参照して説明したものと類似
の方法によって、加入者によってその場その場で与えられることができる。この
場合、ｑは、使用可能な加入者プロファイルの最大数である。ｑは必ずしもｎと
等しくない点が留意される。というのも、恣意的に参照符号ＳＡ_ｉが付される、
任意のディレクトリサーバは、一方では同一加入者の複数の別々の状況を受入れ
ることができる。他方では、複数の加入者サーバが、別々にもかかわらず、同一
の加入者プロファイルを受け入れ、場合によっては共通の登録プロトコルを共有
することができる。

【０１９１】 ディレクトリサーバ全体または一部の選別を行うために使用される方法にかか
わらず、スマートカード２ａに移行したパラメータは、１つまたは複数の加入者
プロファイルからＰＡ_ＡからＰＡ_Ｄを選別し、そこから１つまたは複数の「ＵＲ
Ｌ」アドレスを派生させることができる。スマートカード２ａに移行されたパラ
メータによって要求されるアクションは、通常以下の型である。

【０１９２】 ？ｓａ_ｉ＝ｅｎｒ＋ｐａ_ｊ （５） ここで、「Ｓａ_ｉ」は、可能なｎ個の中の任意の指数ｉのディレクトリサーバ
の名であり、「ｅｎｒ」は、いわゆる登録の要求アクションであり、「ｐａ_ｊ」
が可能なｑ個の中から使用される加入者プロファイルである。

【０１９３】 １つまたは複数の要求「ＨＴＴＰ」が出され、当該のディレクトリサーバに伝
達されるが、選別可能なｎ個のディレクトリサーバが存在する場合には、ＳＡ_Ａ からＳＡ_ｎの参照符号が付される。

【０１９４】 受入れページＰにおける選択は、必然的に、読取装置３内に挿入されたスマー
トカード２ａに応じて異なる。そこで提示された選択は、スマートカード２ａを
所有する加入者に与えられる権利、特に任意のサービスに申し込んだ加入および
それらの有効期間に左右される。

【０１９５】 本発明による方法の第２の段階、すなわち、何らかの識別子に関連付けられた
加入者のインターネットでの探索は、登録段階と非常に類似した方法で行うこと
ができる。

【０１９６】 そのためには、１つまたは複数のサーバに問い合わせることが必要である。ま
た、この加入者の探索の少なくとも１つの特有プロトコル「ＰＬ」を使用できる
ようにすることが必要である。さらに、問合わせ可能な複数のサーバＳＡ_１から
ＳＡ_ｎが存在する場合には、登録の場合におけるように、別々の複数の探索プロ
トコルを使用できるようにすることが必要である。

【０１９７】 それら探索プロトコルは、スマートカード２ａ内に保存されたアプリケーショ
ンを用いて実施される。

【０１９８】 探索プロセスは、１つまたは複数のディレクトリサーバＳＡ_ｉへの登録と完全
に類似した方法で行われる。唯一の留意すべき例外は、加入者プロファイルＰＡ _ｊ が、もはや明白に要求されないという点である。スマートカード２ａに、サー
チされている加入者の識別子とディレクトリサーバＳＡ_ｉのアドレス、または、
少なくとも、探索プロトコルに関連付けられたアプリケーションがこの「ＵＲＬ
」アドレスを決定するのを可能にするパラメータを与えるだけでよい。ただし、
加入者プロファイルＰＡ_ｊは、ディレクトリサーバＳＡ_ｉの「ＵＲＬ」アドレス
を自動的にそこから派生させるために使用することができる。そのディレクトリ
サーバを用いて、発呼側加入者は、着呼側加入者を探索しようとする。すでに示
されているように、サーチされた加入者の識別子は、そのｅメールアドレス、す
なわち通常、以下の形をとるアドレスとすることができる。

【０１９９】 ｐｓｅｕｄｏ＠ｆｏｕｒｎｉｓｓｅｕｒ．ｃｏｍ （６） ここで、「ｐｓｅｕｄｏ」は、加入者のメールのユーザ名、またはより一般的
にはペンネームであり、「ｆｏｕｒｎｉｓｓｅｕｒ．ｃｏｍ」は、インターネッ
トサービスの提供者の名と接尾辞であり、「．ｃｏｍ」は、場合によってはさま
ざまな接尾辞、「．ｆｒ」、「．ｎｅｔ」等によって置き換えることができる。

【０２００】 図８は、ディレクトリＳＡ_ｉの問合わせによって電話通信を確立しようとする
加入者の探索段階の主要なステップを表している。

【０２０１】 第１のステップでは、スマートカード２ａは、層１３および２３ａを介して、
端末１のブラウザ１０によってアドレシングされる。たとえば、「ＧＥＴ」型の
コマンドによって、参照符号が付された受入れページＰ’の形でスマートカード
２ａからのローディング書式がリトリーブされる。この受入れページは、特に、
図７Ｃを参照して説明したものと類似の種々の様態をとることができる。１つま
たは複数の可能な選択肢が存在するか否かによって、加入者は１つまたは複数の
ディレクトリサーバを選別し、サーチされる加入者の識別データを提供する。図
８では、ただ１つのディレクトリサーバＳＡ_ｉが問合わせ可能であると想定され
ている。

【０２０２】 ページは、要求「ＨＴＴＰ」の形で、スマートカード２ａに伝達され、プロト
コル「ＰＬ」の実施用アプリケーションＡ_Ｉに関連付けられたスクリプト変換エ
ージェントＡｔ_Ｉによって解釈される。

【０２０３】 クライアント／「ＷＥＢ」と「ＣＧＩ」サーバの二重のメカニズム（先述した
ように、参照符号Ｓ_ｗｅｂが付されたモジュール）によって、以下の型の要求は
、 ｈｔｔｐ：／／１２７．０．０．１／？ ｓａ_ｉ＝ｌｏｃ＋ｐｓｅｕｄｏ＠ｆ ｏｕｒｎｉｓｓｅｕｒ．ｃｏｍ （７） スマートカード２ａによって、識別子がディレクトリサーバＳＡ_ｉ上（６）であ
るような、加入者の探索要求として解釈される。

【０２０４】 要求「ＨＴＴＰ」は、要求された情報が入手可能である限りにおいて、要求さ
れた情報を送り返すこのサーバに伝達される。このサーバは、受け取った識別デ
ータに対応する「ＩＰ」アドレスをそのデータベース内でサーチする。成功した
場合、すなわち、要求側加入者が実際に登録されており、その加入者がこのアド
レスを取得する権利を有し、さらに受け取ったデータが正確である場合には、再
伝送されたデータは、サーチされた加入者の「ＩＰ」アドレスを含み、そのこと
からその加入者を探索することが可能になる。

【０２０５】 それら種々の段階は、本発明の１つの様態に従って、対をなすエージェント間
のセッションを実施する。

【０２０６】 さらに、スマートカード２ａの枠の中に複数のアプリケーションを保存するこ
とができ、各々は、別々のディレクトリサーバに先験的に関連付けられた、別々
の探索プロトコルの実施用である。

【０２０７】 本発明による好ましい他の変形実施形態によれば、スマートカード２ａ内に、
複数の登録プロトコルと複数の探索プロトコルの実施を可能にするアプリケーシ
ョンと、複数の加入者プロファイルの登録のための加入者ファイルとを保存する
。こうした有利な措置から、スマートカード２ａを、マルチディレクトリポータ
ブルデータベースに変えることが可能になる。

【０２０８】 本発明による方法のさらに他の変形実施形態においては、スマートカード２ａ
の仕様は、登録段階および／または探索段階の際に、その所有者の確固たる認証
を可能にする。というのも、その所有者が所有しているままのスマートカード内
に安全性データを保存することが可能だからである。このような安全性データは
、暗号化の鍵によって構成することができる。

【０２０９】 本発明による方法の有利な様態の１つによれば、スマートカード２ａは、エー
ジェント間のセッションの実施によって、インターネットと直接通信できること
から、それらのデータは、端末１であったとしても、外部装置に伝送される必要
がない。安全性に関わる処理は、スマートカード２ａによって直接行われる。し
たがって、こうした方法は、英語で「ＳＳＬ」（「Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ
Ｌａｙｅｒ」の略）の略語で知られている、最近の「ＷＥＢ」ブラウザの安全
化されたと言われるソフトウェア層の単純な使用よりはるかに高い安全度を与え
る。

【０２１０】 いわゆる認証は、スマートカード２ａ内に保存された上記の暗号化の鍵と関連
させることによって、証明書と呼ばれる技術に頼ることによって行うことができ
る。この手続きは、インターネットＲＩを通過する要求「ＨＴＴＰ」を用いて、
１つまたは複数の当該のディレクトリサーバとスマートカード２ａとの間の補足
的トランザクションを必要とすることができる。認証の肯定的または否定的な結
果に応じて、加入者は、実行しようとする処理、登録または探索を行うことを許
可される、または許可されない。

【０２１１】 本発明の他の様態によれば、再びインテリジェントエージェントに頼ることに
よって、スマートカード２ａ上に直接、「プロキシＴＣＰ／ＩＰ」と呼ばれる機
能を設置する。この機能は、以下「フィルタ」と呼ばれる独自のソフトウェアア
プリケーションによって実行される。

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

【０２１３】 本発明に合致するアーキテクチャを説明する前に、まず第一に、図９を参照し
て、従来の技術による従来の「プロキシ」の特徴を簡単に思い起こしてみよう。

【０２１４】 「ＴＣＰ／ＩＰ」テクノロジーにおいて、一方では「ＴＣＰ／ＩＰ」サーバＳ
ｖと、「ＴＣＰ／ＩＰ」クライアントＣｌを実行するソフトウェアエンティティ
Ｐｙを「プロキシ」と名づける。ソフトウェアエンティティＰｙは、ローカルク
ライアントと他の遠隔「ＴＣＰ／ＩＰ」サーバとの間の接続を実施する。

【０２１５】 プロキシＰｙは、通常は、フィルタおよび／または安全性機能を行う。たとえ
ば、ある企業では、「ＨＴＴＰ」プロキシは、一般に、ブラウザ、たとえば端末
１のブラウザ１０を、「ＷＥＢ」サーバ４に接続する（そのことは「ファイアウ
ォール」または「防火壁」の名で知られている）。同じく、インターネットＲＩ
を通して安全化されたトンネルの確立に必要な安全性オペレーション（認証−機
密性−完全性）を実行する、端末におけるローカル「プロキシ」として定義する
ことができる、「ＳＳＬ」と呼ばれるプロキシを対象とすることができる。

【０２１６】 ここで、図１０を参照して、本発明の補足的な様態に従って、スマートカード
の中に直接「プロキシ」機能を組み入れる論理アーキテクチャについて説明しよ
う。

【０２１７】 先の図に共通のエレメントは、同じ参照符号を付すとともに、必要がある場合
にのみ再び説明する。説明を簡単にするために、端末１側のエージェントは、単
一の参照符号１３２に包括し、スマートカード２ａ側のエージェントは、単一参
照符号２３２ａに包括した。それらは、以下では、添数に関連付けられた文字、
「端末」については文字「Ｔ」、「スマートカード」については文字「Ｓ」によ
って違いを表わす。スマートカード２ａ上で実行される「プロキシ」２７は、以
下、「スマートプロキシ」と呼ぶ。

【０２１８】 「スマートプロキシ」２７は、以下に記載するように、４つのエージェント、
２つは端末側のＴ_１およびＴ_２、２つはスマートカード２ａ側のＳ_１およびＳ_２ と、フィルタ機能との結びつきによって実行される。

【０２１９】 − 「端末／クライアント／ネットワーク」エージェントＴ_１は、ＴＣＰ／Ｉ
Ｐサーバを実行する（たとえばポート８０８０上で）。

【０２２０】 − 「カード／サーバ／ローカル」エージェントＳ_１は、セッションによって
エージェントＴ_１に関連付けられ、このエージェントは通常、「ＷＥＢ」サーバ
の機能を実行する。

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

【０２２２】 − 「カード／クライアント／ローカル」エージェントＳ_２、このエージェン
トのインスタンスは、フィルタ機能２７によってダイナミックに創り出され、Ｓ _２ は、「ネットワーク」エージェントＴ_２とのセッションを開始し、そのエージ
ェントに、Ｓ_２が接続しようとしているインターネット遠隔サーバのアドレス４
が示される。

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

【０２２４】 以下に、「スマートプロキシ」の創設メカニズム２７について述べる。

【０２２５】 以下「ｃＴＣＰ」と呼ぶ「ＴＣＰ」クライアント、通常「ＷＥＢ」ブラウザ１
０は、「ネットワーク」エージェントＴ_１との接続を開く。次にセッションＴ_１ −Ｓ_１がつくりだされる、たとえば、以下のＵＲＬは、 ｈｔｔｐ：／／１２７．０．０．１：８０８０／？ｄｅｓ１＝ｘｘｘ．ｃｏｍ ：８０／ｙｙｙ／ｃｏｎｔｅｎｔ．ｈｔｍｌ （８） エージェントＴ_１およびＳ_１間のセッションの開始を引き起こす。

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

【０２２７】 言い換えれば、関係式２によって規定されたＵＲＬ「カード」は、外の世界に
向けての他のＵＲＬをカプセル化し、このＵＲＬの第１の部分は、関係式（１）
によって規定したようなループバックのＵＲＬで構成される。

【０２２８】 フィルタ２８「ｄｅｓ１」は、クライアントのインスタンスＳ_２を創設し、セ
ッションはエージェントＳ_２およびＴ_２の間で開始される。第１の「ｐｄｕ」内
に挿入されたデータ（「ｐｄｕ ＯＰＥＮ」）は、インターネットサーバの名（
「ｘｘｘ．ｃｏｍ」）とその関連付けられたポートの番号（８０）を明示する。

【０２２９】 エージェントＴ_２は、「ｓＴＣＰ」遠隔サーバ（「ｚｚｚ．ｃｏｍ」）との「
ＴＣＰ」型の接続を開始する。この接続がいったん確立されると、Ｓ_２宛てにト
ークンが送信される。

【０２３０】 これらの交換が終わると、「スマートプロキシ」２７が創設され、スマートカ
ード２ａ内にあるフィルタ機能２８が、「ネットワーク」エージェントが受け取
ったデータ（インターネットＲＩから出た）を処理することができる。フィルタ
２８は、「ネットワーク」エージェントＴ_１およびＴ_２によって送信されたデー
タを論理的に制御する。それは、「ｃＴＣＰ」クライアントと「ｓＴＣＰ」サー
バとの間で交換されたデータを制御する「ＴＣＰプロキシ」として行動する。

【０２３１】 分かりやすくするために、図１０に、種々のエージェントの任意の参照符号を
表している。固定エージェントは２と５、サーバ型エージェントはそれぞれ、Ｔ _２ およびＳ_１、さらに、可変またはイフェメラルエージェントは「１５３６０」
および「２５５９」、クライアント型エージェントは、それぞれ、Ｔ_１およびＳ _２ となる。

【０２３２】 他の型のフィルタもスマートカード２ａ内に設置することができる。こうして
、それらフィルタは、個別の特徴をもつルーティング経路の予約交渉または暗号
化の鍵の交換交渉を実施するために使用することができる。例として、発呼側加
入者が、高容量のマルチメディアファイル、または大量のデータを伝送したい場
合には、有償であっても、最小限の通過周波帯および／またはトラフィックが場
所を取らないことの保証を得たいと考える。

【０２３３】 厳密には、スマートカード２ａ上の他の型のフィルタは、従来は、交換された
データの容量または数量に基づいて、しかもシグナリング段階中にサービス提供
者と交渉された経路の型に基づいて行われていた料金決定機能を行うことができ
る。そのためには、それ自体良く知られているように、主に、カウンタが使用さ
れる。

【０２３４】 いったん加入者が探索されると、スマートカード２ａ内に直接設置された「プ
ロキシ」機能が、発呼側加入者と探索された着呼側加入者との間のいわゆるデー
タの交換および／またはシグナリングオペレーションに対応するステップのため
に使用される。

【０２３５】 発呼側加入者によって使用される本発明による方法は、着呼側加入者もまたそ
の同じ方法を利用することを要求しない点がきちんと理解されなければならない
。というのも、加入者のいずれか一方、たとえば着呼側加入者は、従来の技術に
合致した標準端末を使用できるという点が、本発明の補足的な利点だからである
（図１：９ｂ）。特に、この端末がスマートカードの読取装置を備えていること
は必要ない。言い換えれば、少なくとも、発呼側または着呼側という加入者のい
ずれか一方に関連付けられた設備の一方に関しては、本発明による方法は、既存
の電話ハードウェアおよびソフトウェアと完全な互換性をもち、他方の設備は、
本発明の方法に合致するためにはほんの少しの改良しか必要としない。

【０２３６】 しかしながら、本発明の好ましい変形実施形態においては、発呼側加入者と着
呼側加入者、両方ともが、本発明による方法を利用する端末を使用するという場
合を想定してみよう。以下、「発呼」側は、恣意的に参照文字「ａ」で示され、
「着呼」側は、参照文字「ｂ」で示される。

【０２３７】 図１１Ａは、発呼側加入者Ａａも、着呼側加入者Ａｂも、信号経路ＣＳ用の「
プロキシ」機能を利用する電話のシステムのアーキテクチャを概略的に表してい
る。

【０２３８】 この図において、説明しやすくするために、発呼側端末１ａおよび１ｂは、「
ＰＳＰ」シグナリングプロトコル、それぞれ９０２ａおよび９０２ｂに関連付け
られるソフトウェアのみに縮小している。それらソフトウェアは、先験的に従来
の技術の対応するソフトウェアに合致する（図１参照）。

【０２３９】 しかしながら、「プロキシ」機能は、本発明による方法を利用するインターネ
ットスマートカードをサポートすることができるように、それらを適合させるこ
とを必要とする場合もある。少なくとも、以下に示すように、それらは、シグナ
リングポート（「ＴＣＰ」型）を変更できるように、パラメータ化されることが
できなければならない。市販の標準版における特定の電話ソフトウェアは、この
パラメータ化を行うことができない。限定的でない例として、「ＮｅｔＭｅｅｔ
ｉｎｇ」ソフトウェアを挙げることができるのに対して、「Ｗｅｂｐｈｏｎｅ」
ソフトウェアはそれが可能である。どちらのソフトウェアも、本発明の明細書の
序文に挙げられている。

【０２４０】 しかしながら、シグナリング「プロキシ」を使用する利点は、たとえば通信の
受入れのために役立つこともある発呼側加入者Ａａと着呼側加入者Ａｂとの間の
単純なまたは相互の認証手続きを実施することができる点である。

【０２４１】 発呼側加入者Ａａのスマートカード２ａは、本発明によれば、「ＴＣＰ」ポー
ト上で、シグナリング用と呼ばれる、「ＴＣＰ」サーバネットワークエージェン
トによって構成されるサーバに関連付けられる。このポートは、「Ｐｏｒｔ Ｓ
ｉｇｎａｌｉｓａｔｉｏｎ Ｃａｒｔｅ Ｓｏｕｒｃｅ」を略して「ＰＳＣＳ」
と呼ばれる。発呼側加入者Ａａのスマートカード２ａは、着呼側加入者Ａｂのス
マートカード２ｂの対応するシグナリングポートに接続される。このポートは、
「Ｐｏｒｔ Ｓｉｇｎａｌｉｓａｔｉｏｎ Ｃａｒｔｅ Ｄｅｓｔｉｎａｔｉｏ
ｎ」を略して「ＰＳＣＤ」と呼ばれる。それは、恣意的に「＠ｉｐ」と呼ぶ「Ｉ
Ｐ」アドレスに探索される。着呼側カード２ｂは、「ＴＣＰ」「ＰＳＣＤ」ポー
トと、着呼側加入者Ａｂの端末１ｂの「ＰＳＬＴ」ポートまたは「電話ソフトウ
ェアシグナリングポート」との間のシグナリング「プロキシ」を実行する。

【０２４２】 これらのトランザクションは、図３から図５を参照して詳しく説明された本発
明の方法の特徴の１つによって、対をなすエージェント間のセッションの確立と
、また図１０を参照して詳しく説明された本発明の方法の他の特徴によって、「
プロキシ」機能の実施を必要とする。

【０２４３】 図１１Ａでは、スマートカードの「プロキシ」２ａおよび２ｂが、参照符号２
７ａおよび２７ｂによって概略的に表されている。それらは、実際に、図１０に
表された種々のエレメント、エージェントＳ_１およびＳ_２およびフィルタ２８を
含む。

【０２４４】 分かりやすくするために、ここで、実際の実施形態の中で、シグナリング段階
の主要ステップについて説明する。分かりやすくするために、カードのループバ
ックの「ＵＲＬ」アドレスは関係式（１）によって与えられたアドレス、すなわ
ち１２７．０．０．１であり、任意のポート番号は１７３１であると想定する。
電話ソフトウェアのポート番号は、一般的には１５０３である。探索段階で定め
たように、着呼側加入者Ａｂのアドレスは＠ｉｐとする。

【０２４５】 発呼側加入者Ａａ １．準備段階：＠ｉｐ：１５０３において翻訳１２７．０．０．１：１７３１
が行えるように「プロキシ」の構成２７ａを準備する。

【０２４６】 ２．発呼段階 ２ａ．発呼側「ＰＳＰ」９０２ａが、１２７．０．０．１：１７３１を呼出す
。

【０２４７】 ２ｂ．発呼側スマートカード２ａが、＠ｉｐ：１５０３を呼出す。

【０２４８】 ２ｃ．着呼側スマートカード２ｂが、＠ｉｐ：１５０２を呼出す。 着呼側加入者Ａｂ １．予備準備段階：１５０３から１５０２の「ＰＳＰ」（着呼側）のシグナリ
ングポート番号の変更。

【０２４９】 ２．ポート１５０３の「ＴＣＰ」ネットワーク型のエージェントおよびカード
の入力におけるポート１５０３と出力における１５０２との間の「プロキシ」機
能２７ｂの利用による、マートカード２ｂと端末１ｂとの間の通信段階。

【０２５０】 当然のことながら、発呼側加入者システム、１ａ−２ａだけが、本発明に合致
している型である場合には、スマートカード２ａは、「ＵＲＬ」アドレス＠ｉｐ
：１５０２における着呼側加入システムを直接呼び出す。

【０２５１】 オプションとして、一対の暗号化の鍵は、シグナリング手続き中に交渉するこ
とができる。対応するデータの交換はまた、対をなすエージェント間のセッショ
ンの確立によって行われる。

【０２５２】 本発明の方法に合致したスマートカードはまた、データチャネルＣＤにおいて
、データ交換プロトコルの「プロキシ」（「ＵＤＰ」型）として行動することが
できる。先述したように、この機能は、本発明の方法に合致したスマートカード
をサポートするように電話ソフトウェアを適合させることを必要とすることもあ
る。

【０２５３】 しかしながら、ここでもまた、データ交換「プロキシ」を利用することで、大
きな利点が生まれる。その利点とは、情報の暗号化と暗号解読手続きを実行でき
るという点である。たとえば、５．３Ｋｂｐｓから６．３Ｋｂｐの間の容量で音
声を圧縮する規格Ｇ７２３は、現在のスマートカードの容量、通常９６００ｂｐ
ｓから１０５９００ｂｐｓの容量と互換性をもつ。図１０を参照してすでに説明
したように、「プロキシ」フィルタは、特に、「ＤＥＳ」型のアルゴリズムに従
って暗号解読および／または暗号化オペレーションの実行を可能にするフィルタ
とすることができる。

【０２５４】 図１１Ｂは、発呼側加入者Ａａと着呼側加入者ＡｂのデータチャネルＣＤにつ
いて、「プロキシ」機能を実施する電話システムのアーキテクチャを概略的に示
している。図１１Ｂにおいては、スマートカード２ａおよび２ｂの「プロキシ」
は、参照符号２７ａおよび２７ｂによって概略的に表わされる。それらは、実際
には、先述したように、図１０に表わされる種々のエレメント：エージェントＳ _１ およびＳ_２およびフィルタ２８を有する。

【０２５５】 発呼側加入者Ａａのスマートカード２ａは、「Ｐｏｒｔ Ｄｏｎｎｅｅｓ Ｃ
ａｒｔｅ Ｓｏｕｒｃｅ」を略して「ＰＤＣＳ」と呼ばれる、「ＵＤＰ」ポート
上のデータ交換用「ＵＤＰ」型サーバネットワークエージェントによって構成さ
れるサーバに関連付けられる。発呼側加入者Ａａのスマートカード２ａは、任意
の「ＩＰ」アドレス「＠ｉｐ」で探索されるカード、「Ｐｏｒｔ Ｄｏｎｎｅｅ
ｓ Ｃａｒｔｅ Ｄｅｓｔｉｎａｔｉｏｎ」を略して「ＰＤＣＤ」と呼ばれる、
着呼側加入者Ａｂのスマートカード２ｂのデータ交換ポートに接続される。着呼
側加入者のスマートカード２ｂは、「ＵＤＰ」ポート「ＰＤＣＤ」と、端末１ｂ
の「ＰＤＬＴ」または「Ｐｏｒｔ ｄｅ Ｄｏｎｎｅｅｓ ｄｕ Ｌｏｇｉｃｉ
ｅｌ ｄｅ Ｔｅｌｅｐｈｏｎｉｅ」ポートとの間のデータ交換「プロキシ」を
実行する。その場合、２つのデータ交換「プロキシ」を実施する必要がある。着
呼側加入者Ａｂに向かう発呼側加入者Ａａの「プロキシ」２７ａと、発呼側加入
者Ａａに向かう着呼側加入者の他方の「プロキシ」２７ｂである。

【０２５６】 先述したように、発呼側加入システム、１ａ−２ａだけが、本発明に合致した
型である場合には、スマートカード２ａは、着呼側加入者システムを直接呼出す
。

【０２５７】 図１１Ａおよび１１Ｂの総括である図１２は、発呼側加入者Ａａと着呼側加入
者Ａｂとの間、より厳密には、スマートカード２ａと協働する発呼側端末１ａを
含む発呼側システムと、全体的に参照符号１’ｂが付される、サーバと呼ばれる
着呼側システムとの間の電話データ（また、より一般的には、マルチメディアデ
ータ）の伝送管理システムＳＧＤＴの一般的アーキテクチャを概略的に表してい
る。着呼側加入者１’ｂは、（図１１Ａおよび／または１１Ｂに示されているよ
うな）スマートカード２ａとの協働する端末１ａ、または従来の技術のシステム
の構成（図１参照：９ｂ）といった、発呼側システムに類似の、すなわち本発明
に合致した構成を無差別に有することができる。先の図面に共通のエレメントに
は、同じ参照符号を付し、必要がある場合にのみ再び説明する。

【０２５８】 図１２は、特に、図３から図８、および図１０から図１１Ｂを参照して詳しく
説明したように、本発明による電話データ伝送管理システムの基本的構成要素間
の種々の相互作用を表わす。より厳密には、スマートカード２ａは、（図７Ｄお
よび図８によって詳しく説明されるているように）「ＰＥ」登録プロトコル９０
０ａおよび「ＰＬ」探索プロトコル９０１ａに関連付けられるアプリケーション
、さらに「ＰＡ」加入者プロファイル９０３ａが、このスマートカード２ａのメ
モリ内に登録される本発明の好ましい実施形態を表している。同様に、スマート
カード２ａは、シグナリングチャネルＣＳについてもデータチャネルＣＤについ
ても、「プロキシ」機能２７ａを有することが想定された（図１１Ａおよび図１
１Ｂ）。先述したように、プロキシ２７ａは、スマートカード２ａのクライアン
ト／ＳＷＥＢサーバのコントロール下にある。

【０２５９】 さらに、ただ１つのディレクトリサーバＳＡ_ｉが図１２に示されているにもか
かわらず、さらに好ましい実施形態においては、複数の加入者プロファイルの登
録のためのデータファイルおよび複数の探索プロトコル、さらに複数の登録プロ
トコルの実施を可能にするアプリケーションをスマートカード２ａ内に保存する
。こうした有利な措置は、スマートカード２ａをマルチディレクトリポータブル
データベースに変換させることができる。それ自体において、１つまたは複数の
サーバは、従来の技術のサーバ、たとえば図１のサーバ９１とまったく同じであ
る。サーバは、加入者の「ＰＥ」登録プロトコル９１０および「ＰＬ」探索プロ
トコル９１１を有する。

【０２６０】 以上のことから、本発明の方法は、定められた目的を正しく達成できることが
容易にわかる。

【０２６１】 スマートカード内に直接設置された「プロキシ」と呼ばれる機能は、このスマ
ートカードによって与えられる「ＷＥＢ」クライアント／サーバの機能と協働す
ることによって、シグナリングプロトコルおよび／またはデータ交換プロトコル
の「プロキシ」としてスマートカードを使用することを可能にする。

【０２６２】 スマートカードが、シグナリングプロトコルの「プロキシ」として使用される
場合には、特に、発呼側加入者と着呼側加入者との間の単純なまたは相互の認証
手続きの実施が可能になる。さらに、暗号化の鍵によって交渉し、さらに／また
はあらかじめ確立された伝送特性を与えるルーティング経路を予約することが可
能になる。

【０２６３】 スマートカードが通信プロトコルの「プロキシ」として使用される場合には、
特に、暗号化／暗号解読手続きを実施することが可能になる。さらに、、交換さ
れたデータの容量または数量に基づいて、または先に実施された予約を考慮に入
れて、料金決定オペレーションを実施することが可能である。

【０２６４】 本発明による方法によって、また、たとえば発呼側加入者は、１つまたは複数
のディレクトリサーバ上に登録することができ、さらに／または、１つまたは複
数のディレクトリを介して、インターネット上で、着呼側と呼ばれる他方の加入
者を探索することができる。スマートカードは、「ＷＥＢ」クライアント／サー
バと「ＣＧＩ」ゲートウェイを組み合わされた機能を有することから、こうした
措置は、スマートカードとディレクトリサーバとの間の直接通信を可能にする。
こうしたカードは、そのことによって、登録プロトコルおよび／または探索プロ
トコルの実施に必要な特有のソフトウェアの保存を許可し、その結果、大きな移
動性が可能になる。１つまたは複数の加入者プロファイルがまた、スマートカー
ド内に保存される。加入者はもはや、特に上記のプロトコルのために配置された
端末の使用に制限されることはない。

【０２６５】 本発明による方法は、既存の方法と完全な互換性をもっている。発呼側または
着呼側の加入者は、本発明の方法を使用することによって、１つまたは複数のデ
ィレクトリサーバ上に登録されることを要求されることもないし、本発明による
スマートカードの読取装置を備えた端末を有する必要もない。インターネット上
の伝送は、現行のプロトコルに従って行われ、本発明による方法を利用する加入
者端末とそのスマートカードとの間の通信は、上記の規格化プロトコル「ＩＳＯ
」を利用して行われる。したがって、標準スマートカードの読取り装置を利用す
ることができる。端末における特有のソフトウェア層の存在のみが必要であり、
その結果、ほとんど変更を必要とせず、登録プロトコル、探索プロトコルおよび
／またはスマートカードによってもたらされる加入者プロファイルの数に関係な
く、また、それらの性質にも関係なく、一度にすべてを行うことができる。スマ
ートカード内に設置された「プロキシ」フィルタについても同様である。

【０２６６】 さらに、スマートカードの使用は、トランザクションの安全化、特に「確固と
した」認証を可能にする。また、ルーティング経路の交渉および／または交換さ
れたデータの料金決定を可能にする。

【０２６７】 しかしながら、本発明は、特に、一方では、図３から図８と関連して、他方で
は図１０から図１２と関連して、詳しく説明した実施形態のみに限定されるわけ
ではないことを明らかにしなればならない。

【０２６８】 そうした措置はとりわけ有利であるにもかかわらず、プロプラエタリソフトウ
ェアの２つのシリーズ「ＰＥ」および「ＰＬ」が、スマートカード内に保存され
ることは必要ない。限定的でない例として、１つまたは複数のディレクトリサー
バにおける登録段階は、一度ですべてを行うことができる、または、少なくとも
、先験的に探索段階より少ない頻度ですむので、スマートカード内に、この探索
オペレーションに関連付けられた特有のアプリケーションだけを保存すればよい
。同様に、すでに示したように、スマートカード内に加入者プロファイル「ＰＡ
」を登録しなくてもよい（データは、個別のディレクトリサーバ内で加入者登録
時にリアルタイムで与えられることができる）。さらに、自動的に提供されるこ
とが可能なプロファイルである、加入者プロファイルの一部のみを登録すること
が可能である。

【０２６９】 さらに、すでに示したように、本発明は、電話型のデータだけの管理に限定さ
れるわけではない。それは、より一般的には、他の型のマルチメディアデータ、
特にテレビ電話データの管理を可能にする。

【０２７０】 本発明はまた、第１の加入システムと第２の加入システムとの間のインターネ
ット型ネットワークを介するマルチメディアデータの伝送管理方法であって、一
定のシグナリングプロトコルを用い、シグナリングチャネルを介して、少なくと
も、シグナリングと呼ばれるデータ交換段階と、一定の通信プロトコルを用い、
データチャネルを介して、前記マルチメディアデータの交換段階とを有し、さら
に、前記の第１の加入システムは、「ＷＥＢ」型ブラウザと、スマートカードと
協働するスマートカードの読取装置を備えた端末とを有し、端末およびスマート
カードは、情報処理手段と情報保存手段とを有し、前記のスマートカード（２ａ
）は、特有の通信プロトコル層を形成する第１のソフトウェア（２３ａ）を有し
、前記の端末（１ａ）は、特有の通信プロトコル層を形成し、さらに前記の「Ｗ
ＥＢ」型ブラウザ（１０）とのインターフェイスを形成する、第２のソフトウェ
ア（１３）を有し、前記の第１および第２のソフトウェア（１３、２３ａ）は、
各々、さらに、クライアント型の第１の独立ソフトウェアエンティティ（Ｔ_２、
Ｓ_１）と、サーバ型の第２の独立ソフトウェアエンティティ（Ｔ_１、Ｓ_２）とを
有し、前記エンティティ（Ｔ_１、Ｓ_２、Ｔ_１、Ｓ_２）は、前記の情報処理手段に
よって、前記端末（１ａ）と前記スマートカード（２ａ）との間の双方向データ
交換セッションを確立できるように、さらに、前記スマートカード（２ａ）が、
クライアント／「ＷＥＢ」型サーバの機能を提供し、さらに前記のインターネッ
ト型ネットワーク（ＲＩ）を介する前記の第１の加入システムの端末（１ａ）と
、第２の加入システム（１’ｂ）との間の双方向データ交換セッションの確立を
可能にするように協働し、前記独立ソフトウェアエンティティは、あらかじめ定
められたプロトコルデータユニットを用いて通信し、 − 前記スマートカード（２ａ）の保存手段の中で、前記の第２の特有ソフト
ウェア（２３ａ）内に含まれる、それぞれクライアント型とサーバ型の、前記の
第１および第２の独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に向かって、お
よび／または、それらから、プロトコルデータユニットを受信および／または送
信する、フィルタと呼ばれる一定の機能持性を有するアプリケーションソフトウ
ェア（２８）を実行し、 − 前記のシグナリングデータおよび／またはマルチメディアデータの交換段
階中に、前記のシグナリングチャネル（ＣＳ）および／またはデータチャネル（
ＣＤ）の少なくともいずれか一方を介して、前記の第１の加入システム（１ａ、
２ａ）と前記の第２の加入システム（１’ｂ）との間を通過するデータ交換のあ
らかじめ定められた特性をコントロールし、「プロキシ」と呼ばれる機能を形成
するために特有の前記の第１の特有ソフトウェア（２７ａ）の前記独立ソフトウ
ェアエンティティ（Ｔ_２、Ｔ_１）とのセッションを、前記の情報処理、端末、ス
マートカード手段によって開始するために、前記フィルタ（２８）が、特有の第
２のソフトウェア（２３ａ）の前記独立ソフトウェアエンティティ（Ｓ_２、Ｓ_１ ）と協働する ことを特徴とする方法を対象とする。

【０２７１】 本発明はまた、情報処理手段と情報保存手段とを有し、前記の第１の加入シス
テムと前記の第２の加入システムとの間でインターネット型ネットワークを介す
るマルチメディアデータ伝送管理のための第１の加入システムを形成できるよう
に、スマートカードの読取装置を備えた端末と協働するためのスマートカードで
あって、前記管理は、少なくとも、一定のシグナリングプロトコルを用い、シグ
ナリングチャネルを介するシグナリングデータ交換段階と、一定の通信プロトコ
ルを用い、データチャネルを介する、前記マルチメディアデータの交換段階とを
有し、さらに、前記スマートカード（２ａ）が、情報保存手段の中に、特有の通
信プロトコル層を形成するソフトウェア（２３ａ）を含み、さらに、少なくとも
、クライアント型の第１の独立ソフトウェアエンティティ（Ｓ_１）と、サーバ型
の第２の独立ソフトウェアエンティティ（Ｓ_２）とを有し、前記エンティティ（
Ｓ_２、Ｓ_２）は、前記スマートカード（２ａ）がクライアント／「ＷＥＢ」型サ
ーバの機能を与え、前記のインターネット型ネットワーク（ＲＩ）を介して前記
の第１の加入システムの端末（１ａ）と前記の第２の加入システム（１’ｂ）と
の間のデータ交換を確立することができるように協働し、前記スマートカード（
２ａ）は、さらに、情報保存手段の中で、前記の特有ソフトウェア（２３ａ）内
に含まれる、それぞれクライアント型とサーバ型の、前記の第１および第２の独
立ソフトウェアエンティティ（Ｓ_２、Ｓ_１）に向かって、および／またはそれら
から、プロトコルデータユニットを受信および／または送信する、フィルタと呼
ばれる一定の機能持性を有するアプリケーションソフトウェア（２８）を有し、
前記アプリケーションソフトウェアは、サーバ型の前記独立ソフトウェアエンテ
ィティ（Ｓ_１）のコントロール下で実施され、前記のシグナリングデータおよび
／またはマルチメディアデータの交換段階中に、前記のシグナリングチャネル（
ＣＳ）および／またはデータチャネル（ＣＤ）の少なくともいずれか一方を介し
て、前記の第１の加入システム（１ａ、２ａ）と前記の第２の加入システム（１
’ｂ）との間を通過するデータ交換のあらかじめ定められた特性をコントロール
し、「プロキシ」と呼ばれる機能を形成するために特有の前記の第１の特有ソフ
トウェア（２７ａ）の前記独立ソフトウェアエンティティ（Ｔ_２、Ｔ_１）とのセ
ッションを開始できるように、前記情報処理によって、前記フィルタ（２８）が
、第２の特有のソフトウェア（２３ａ）の前記独立ソフトウェアエンティティ（
Ｓ_２、Ｓ_１）と協働することを特徴とするスマートカードを対象とする。

【図面の簡単な説明】

【図１】 従来の技術による電話ソフトウェアを構成する主要モジュールを概略的に表わ
す図である。

【図２Ａ】 従来の技術によるインターネットに接続されたスマートカードに基づくアプリ
ケーションシステムの一例のハードウェアアーキテクチャを表わす図である。

【図２Ｂ】 従来の技術によるインターネットに接続されたスマートカードに基づくアプリ
ケーションシステムの一例のソフトウェアアーキテクチャを表わす図である。

【図３】 本発明によるスマートカードに基づくアプリケーションシステムの一例を概略
的に表わす図であり、そのスマートカードは、本発明の一様態に従って、「ＷＥ
Ｂ」クライアント／サーバとして作動する。

【図４】 本発明の一様態による、インテリジェントエージェントと呼ばれるソフトウェ
アエンティティ間のセッションの状態のフローチャートである。

【図５】 スマートカードがインテリジェントエージェントを有する、本発明によるシス
テムのソフトウェアアーキテクチャを簡略に表わす図である。

【図６】 スマートカードが、「ＣＧＩ」と呼ばれる機能を設置できるように、スクリプ
ト変換インテリジェントエージェントを有する、本発明の他の様態によるシステ
ムのソフトウェアアーキテクチャを簡略に表わす図である。

【図７Ａ】 ディレクトリサーバへの加入者登録段階の第１ステップを概略的に表わす図で
ある。

【図７Ｂ】 その登録段階のために使用可能な「ＨＴＬＭ」書式例を表わす図である。

【図７Ｃ】 その登録段階のために使用可能な「ＨＴＬＭ」書式例を表わす図である。

【図７Ｄ】 ディレクトリサーバへの加入者登録段階の主要なステップを概略的に表わす図
である。

【図８】 ディレクトリサーバの問合わせによってインターネットへの加入者探索段階の
主要なステップを概略的に表わす図である。

【図９】 従来の技術による「プロキシ」を概略的に表わす図である。

【図１０】 「プロキシ」と呼ばれるフィルタがスマートカード上に実装される、図４に合
致した本発明のシステムのソフトウェアアーキテクチャを概略的に表わす図であ
る。

【図１１Ａ】 加入者発呼側と加入者着呼側の信号経路のための「プロキシ」機能を実行する
、本発明による電話システムのアーキテクチャを概略的に表わす図である。

【図１１Ｂ】 加入者発呼側と加入者着呼側のデータ経路のための「プロキシ」機能を実行す
る、本発明による電話システムのアーキテクチャを概略的に表わす図である。

【図１２】 端末とスマートカードを有する発呼側システムと着呼側システムとの間で、本
発明の好ましい実施形態による、電話データの伝送管理システムの一般的アーキ
テクチャを概略的に表わす図である。

Claims (17)

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