２つの装置間の通信方法および該方法を用いる端末
第１の装置（２）は、アプリケーションの第１および第２のファミリーのそれぞれに属するアプリケーション（３、４）を具備する。第２のファミリーは、第１のファミリーより経験的に低い信用のレベルを有する。第２のファミリーに属するアプリケーション（４）を送信元とし、第２の装置を宛先としてネットワーク（Ｒ）を介して送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むか、あるいは、第１のファミリーに関係づけられたマークを含まないか、のいずれかでなければならず、第１のファミリーに関係づけられたマークは、ネットワークを介して送信され、第１のファミリーに属するアプリケーション（３）を送信元とするリクエストうち少なくともいくつかに含まれる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークブラウザ型の活用ができるとともに、ユーザにアプリケーションのインストールを可能とするコンピュータ端末に関する。
【背景技術】
【０００２】
上記のような端末は、特に、ＷＡＰ（Wireless Application Protocol）を用いた電話機、オフィス用のコンピュータ、携帯型のコンピュータ、あるいは、ＰＤＡ（Personal Digital Assistants）であり得る。これらは、実際多くの場合はＩＰプロトコル（Internet Protocol）に基づいて運用されるデジタルデータネットワーク、特に、インターネットに接続されるという共通の特性を有する。
【０００３】
“クローズ”端末（例えばＭｉｎｉｔｅｌ）の場合は、端末に存在するアプリケーションは知られており、その端末が存在する間は変更することはできない。
端末のオープン性は、ユーザがその端末自身によって実行しようとする新たなアプリケーションをインストールし、かつ多くの場合ダウンロードするために提供される機能とされる。この機能を組み込んだ“オープン”端末の例は、
・例えば、Ｊａｖａ（登録商標）ＭＩＤＰ型（Mobile Information Device Profile、
サンマイクロシステムズ（登録商標）社）のアプリケーションダウンロード電話機
・例えば、ＷＭＬスクリプト型（「ＷＡＰ ＷＭＬスクリプト言語仕様」、バージョン
１．１、ＷＡＰフォーラム、２００１年１１月を参照）またはＥＣＭＡスクリプト
型（Ｊａｖａ（登録商標）スクリプトとも呼ばれる。「ＥＣＭＡスクリプト言語仕様」、
ＥＣＭＡ−２６２標準、第３版、１９９９年１２月を参照）のスクリプト処理機能
を有するブラウザ、または、アプレットを実行可能なブラウザ
・Ｐａｌｍ（登録商標）ＯＳ、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ、Ｓｙｍｂｉａｎ
（登録商標）等のオペレーティングシステムのもとで運用される大多数のＰＤＡ
・オフィス用または携帯型のコンピュータ
【０００４】
“セミオープン”端末は、ある機能がユーザによってインストールまたはダウンロードされたアプリケーションに直接利用可能でないオープン端末である。例えば、唯一“オープン”であるのはＥＣＭＡスクリプトである端末において、ダウンロードされたアプリケーションは全てのネットワーク機能を利用できるわけではない（例えば、最も一般的なトランスポートプロトコル、すわなち、ＴＣＰ（Transmission Control Protocol）またはＵＤＰ（User Datagram Protocol）のフォーマットに準拠していないＩＰパケットの送信）。これらの機能は間接的でかつ制御された方法で利用可能となりうる。例えば、ＥＣＭＡスクリプトの関数はＨＴＴＰ（Hypertext Transfer Protocol）によりページの読み込みを命令することができ、これはネットワークを利用するが制御された方法である。
“セミオープン”端末には次のようなものが共存している。
・例えば、端末メーカによって工場でインストールされたため、または、アプリケー
ションへの電子署名のような手法で獲得された保証のため、等、“信用できる”アプ
リケーションとみなされるアプリケーション、
・ユーザ自身によってユーザ自身の判断で端末にインストールされたが、信用できる
アプリケーションと同じ利用権限は有しないその他のアプリケーション。
【０００５】
一方、“フルオープン”端末は、ダウンロードされたアプリケーションに全ての機能が利用可能であるオープン端末である。端末のオープン性の概念は、それが生じる状況に大きく依存する。例えば、ＯＳＩモデル（データリンク層、ネットワーク層、セッション層、トランスポート層、等）の異なる階層においては、オープン性の程度も異なる。
【０００６】
ここで、サーバから遠隔で監視することができる機能、すなわち、ネットワーク機能に着目する。この状況においては、端末の“セミオープン”の特性は、一般に遠隔から監視することができかつ信用できるアプリケーションを利用できる実行権限が、信用できないアプリケーションを利用できないことを意味する（例えば、ＩＰネットワークにおいてＨＴＴＰ以外のリクエストを送信する権限）。これによりサーバは、受信したリクエストのうち信用できるアプリケーションを送信元とするリクエストと、その他のアプリケーションを送信元とするリクエストとを区別することができる。特に、ダウンロードされたアプリケーションを送信元とするリクエストと、最初から端末に存在するアプリケーションを送信元とするリクエストとを区別することができる。
【０００７】
オープン端末においては、プログラムがユーザをだますように振舞う可能性（トロイの木馬）を考慮しなければならない。したがって、リクエストが本当にユーザを送信元とするものであり、かつネットワークにおいてユーザの承諾を装うプログラムを送信元とするものでないことは、サーバに対して何も保証しない。このリスクは、クライアントから受信したデータに対するサーバの信用を低下させる。トロイの木馬がユーザの代わりにリクエストを送信する機能を有するならば、サーバ宛に送信されたリクエストがユーザの行動を反映するという前提は理にかなっていない。
【０００８】
したがって、端末に存在するアプリケーションは下記のように区別される。
・信用できるアプリケーション：サーバは、これらのアプリケーションがトロイの
木馬でないことを前提とする。例えば、ＷＡＰ電話機のＷＡＰブラウザは信用でき
るアプリケーションである。他の例は、署名付きでダウンロードされたＪａｖａ
（登録商標）ＭＩＤＰアプリケーションである。
・信用できないアプリケーション：サーバは、これらのアプリケーションはトロイの
木馬である可能性があると判断する。例えば、署名なしで端末にダウンロードされ
たＪａｖａ（登録商標）ＭＩＤＰアプリケーションは信用できないアプリケーショ
ンの可能性がある。
【０００９】
トロイの木馬のリスクに対する従来の対応は、信用できないアプリケーションの能力を制限することである。
セミオープン端末からのフレーム送信の制限は、通常は極めて厳しい方法が強いられている。（端末のオペレーティングシステムとともに提供された）システムアプリケーションのみ、所定のフレーム送信が許可される。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、そのアプリケーションが送信したフレームの内容（例えば、署名されたデータの送信）あるいはアプリケーションの特性（例えば、アプリケーションの内容に関係づけられた署名）によってサーバの信用を得る他の情報源による手段を有しているとしても、（信用できるかまたは信用できない）ダウンロードされたアプリケーションはサーバへフレームを送信することは不可能となる。
【００１１】
本発明の目的は、アプリケーションに対して柔軟であるにもかかわらず受信するサーバが識別可能な、“信用できる”アプリケーションと“信用できない”アプリケーションの間で、新たな種類の、リクエストを送信する能力の区別をすることである。信用の概念は様々な基準（署名、情報交換のタイプ、アプリケーションがダウンロードされるＵＲＬ等）に依存する。
【課題を解決するための手段】
【００１２】
したがって、本発明は、第１の装置は、第１のファミリーと、第１のファミリーより経験的に信用度が低い第２のファミリーとのそれぞれに属する第１および第２のアプリケーションを具備する、通信ネットワークを介した第１の装置と第２の装置との間での通信方法を提案する。本発明の１つの側面によれば、第２のファミリーに属するアプリケーションを送信元とし、ネットワークを介して第２の装置へ送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制される。本発明のもう１つの側面によれば、第２のファミリーに属するアプリケーションを送信元とし、ネットワークを介して第２の装置へ送信される各々のリクエストは、第１のファミリーに関係づけられたマークを除外することを強制され、マークは、ネットワークを介して送信され、第１のファミリーに属するアプリケーションを送信元とするリクエストのうち少なくともいくつかに含まれる。また、本発明は、第１の装置としてそのような通信方法を用いる手段を具備する通信端末を提案する。
【発明の効果】
【００１３】
この通信方法によれば、第１の装置で実行されるある特定の（“信用できる”）アプリケーションは、この第２の装置に対するこれらのフレームの信頼できる送信元の保証とともに、通常は遠隔のサーバである第２の装置の注意を喚起するためのフレームを送信することができる。第２のファミリーに属する経験的に信用できないアプリケーションへ強制的にマークを付与（あるいは対称的にはそれを除外）することによって、送信する場合に、これらの経験的に信用できないアプリケーションによって送信されたフレームと、信用できるアプリケーションから送信されたフレームとを区別する。これによりサーバは、信用でき受信すべきリクエストと拒否すべきリクエストとを区別することができる。
【００１４】
付与されるマークは完全に“隙のない（ｗａｔｅｒｔｉｇｈｔ）”ものでなければならない。すなわち、経験的に信用できないアプリケーションが、最も下位のレイヤ（例えばＴＣＰ接続要求）を攻撃することによって、あるレベル（例えば、ＨＴＴＰリクエスト関数）で行われる検査を免れることが不可能でなければならない。
【００１５】
この通信方法の一実施形態において、ネットワークを介して送信され、かつ第２のファミリーに属するアプリケーションを送信元とするリクエストに含まれるマークは、第２のファミリーに属するアプリケーションの特質および／または送信元の表示を含むことを強制される。この表示は例えば署名されたアプリケーションの署名の証明書、または、ネットワークを介してダウンロードされたアプリケーションのダウンロードアドレスに関するデータ中に存在する。これは、第１の装置によって、経験的に信用できないアプリケーションにすぎないと判断される可能性のあるアプリケーションが信用を有するか否かを評価するために遠隔の装置によって用いられる。
【００１６】
この通信方法によれば、ダウンロード機能（端末の“オープン性”）に本来備わっているリスクにもかかわらず、アプリケーションのダウンロードをサポートする端末は、サーバと完全に信用してデータを交換することができる。したがって、この通信方法はトロイの木馬に対して簡単で効果的な防御を提供する。
本発明の他の特徴及び利点は、添付図面を参照して限定のない典型的な実施形態について以下のように記載される。添付図面における唯一の図は本発明を用いたシステムの概要である。
【発明を実施するための最良の形態】
【００１７】
サーバ１のような遠隔の装置が、安全で柔軟な方法で、セミオープン端末２から通信ネットワークＲを介して受信したリクエストにおける信用を獲得させることを目的とするものである。この端末は、一方で例えばウェブブラウザのような信用できるアプリケーション３と、他方で特に端末のユーザがネットワークＲを介してダウンロードした経験的に信用できないアプリケーション４とを有する。
【００１８】
経験的に信用できないアプリケーション４は、ネットワークＲを介して送信するフレームまたはリクエストについて、図において、ネットワークにアクセスするために端末２に設けられたリソース６の一部を構成する制御レイヤ５の符号で表された制約がされる。
【００１９】
前記制御レイヤ５は、経験的に信用できないアプリケーション４によって送信されるフレームが満たす所定の属性を検証する。これらの属性が満たされれば、制御レイヤ５はフレームを通過させる。そうでない場合は、そのフレームをネットワークＲへ通過させずにそれらを送信したアプリケーション４に通知するか、あるいは、経験的に信用できないアプリケーションの要求条件を満たすようにフレームを修正する。後者の場合、そのフレームはサーバ１における信用を失い、サーバ１はそのフレームを利用することができない。
前述の制約は、あるアプリケーションからネットワークＲを介して送信されるリクエストに含まれる特定のマークの存否に関係する。
【００２０】
本発明の第１実施形態において制御レイヤ５は、経験的に信用できないアプリケーション４を送信元とするリクエストが、このアプリケーションのファミリーに関係づけられたマークを含むことを強制する。信用できるアプリケーション３は制御レイヤ５を迂回しかつマークが付与されていないリクエストを送信することを許可する機能を利用することができる。一方、ネットワークＲへアクセスするためのリソース６は、経験的に信用できないアプリケーション４の処理においてこの機能を有しない。
【００２１】
この第１実施形態の図示例において、端末２（例えば携帯電話機）は、図のモジュール６に対応するＪａｖａ（登録商標）仮想マシンを有する。仮想マシンはサンマイクロシステムズ（登録商標）社によって開発されたＪａｖａ（登録商標）プログラミング言語で記述されダウンロードされたアプリケーションを実行するために用いることができる。Ｊａｖａ（登録商標）言語の全ての命令は所定の検査の後、システム関数を呼び出す仮想マシンによって実行される。検査せずにシステム関数を呼び出すことはないので、Ｊａｖａ（登録商標）アプリケーションは明らかにセミオープン環境である。この端末２は、Ｊａｖａ（登録商標）コードのみをダウンロードすることができ、ユーザによってインストールされうるその他の種類のアプリケーションはダウンロードすることはできない。
経験的に信用できないアプリケーション４は、Ｊａｖａ（登録商標）言語で記述されている。
【００２２】
この実施形態において、ネットワークＲを介した端末２における情報交換に用いられるプロトコルは、ＨＴＴＰプロトコル（１９９６年５月にＩＥＴＦ（Internet Engineering Task Force）によって発行されたＲＦＣ（Request For Comment）１９４５）、ＴＣＰ（ＲＦＣ ７９３、ＩＥＴＦ、１９８１年９月）およびＩＰ（ＲＦＣ ７９１、ＩＥＴＦ、１９８１年９月）である。
【００２３】
前記サービスは、ユーザに属するコンテンツを格納するＨＴＴＰサーバ１によって提供される。リクエスト（例えば全てのファイルの削除をリクエスト）は、事実上ユーザから送信され、かつ悪意のあるＪａｖａ（登録商標）プログラムから送信されたものでないという条件を満たさなければならない。このサービスはもちろん一例であり、他のどのようなサービス（電子商取引、出版、メッセージング等）もこの技術を用いることができる。
【００２４】
前記マークは、ＨＴＴＰリクエストの”user-agent”ヘッダ領域（前述のＲＦＣ １９４５の１０．１５節を参照）に含まれる。このマークは”Non-confidence application: VM Java 1.2”のような特定の文字列に含まれ、それが存在することによってリクエストは経験的に信用できるアプリケーションから送信されていないことを示す。この文字列はアプリケーション４によって生成されたリクエストに既に存在していてもよい。その場合、仮想マシン６の制御レイヤ５はその存在を検証するのみである。そうでない場合、この制御レイヤ５はリクエストに正しくマークが付与されるようにその文字列を挿入する。
【００２５】
前記仮想マシン６によって付与されるマークの完璧さは、経験的に信用できないアプリケーション４がこの特定の文字列を含まないＨＴＴＰリクエストをネットワークＲを介して送信することが不可能であるという事実に基づく。特に、アプリケーション４は、ＨＴＴＰより下位のプロトコルレイヤ、特にＴＣＰソケットに接続することによってネットワークＲにアクセスすることはできない。マークは、経験的に信用できないアプリケーションが実行を強制され、どのような方法においても回避することができない仮想マシン６において直接実施される。
【００２６】
したがって、前記サーバ１は受信するリクエストの中から、経験的に信用できないアプリケーション４を送信元とするリクエストと、ウェブブラウザのような信用できるアプリケーション３を送信元とするリクエストとを区別する。
【００２７】
あるサイトについてのみ信用できるアプリケーションも存在する。例えば、Ｊａｖａ（登録商標）アプレットは、通常は、ダウンロードされたサイトからは信用できるアプレットであると判断されるが、その他のサイトからは信用できるアプレットであるとは判断されない。したがって、このダウンロードサイトへ送信されるリクエストにおいては、マークは必要であるとは限らない。すなわち、仮想マシン６は、そのようなアプレットを送信元とするとともに、ダウンロードされたサイト以外のサイトへ送信されるリクエストにマークを強制し、かつアプレットがそのソースサイトへ送信するリクエストにマークを含めるか除外するかはそのアプレットの自由に任せてもよい。もう１つの可能性は、そのようなアプレットから送信されるどのようなリクエストにも、送信先に関係なくマークを強制することである。
【００２８】
信用できないリクエストへのマーク付与の変形例として、これらのリクエストのいくつかを禁止してもよい。例えば、所定のサーバからダウンロードされた信用できないアプリケーションに対して、異なるサーバへ向けたリクエストを禁止してもよい。ソースサーバへのリクエストはマークを付与して可能なままとする。
他の実施形態においては、リクエストの送信元となる経験的に信用できないアプリケーション４の特質および／または送信元の表示をマークに補足すると効果的である。
【００２９】
この経験的に信用できないアプリケーション４は署名してもよい。それを送信元とするリクエストは、このアプリケーションにおいて遠隔のサーバの信用を確立するために適した次の構成要素のうち少なくとも１つを含むヘッダを有するマークが付与される。
・アプリケーションの署名者の証明書またはその証明書のダイジェスト
・アプリケーションの署名者の証明書から始まる証明列またはその証明書のダイジェ
スト
・この目的のためにアプリケーションのコードに含まれる特定の文字列
・動的な方法でアプリケーションを識別する可変要素
【００３０】
このような本発明の実施形態は、特に証明書によって署名されたＪａｖａ（登録商標）アプリケーションの場合に適用できる。
この場合、仮想マシン６は、リクエストの送信前にＪａｖａ（登録商標）アプリケーションの署名を検証しなければならない。実際、この検証はアプリケーション４が実行される前に行われる。
【００３１】
マークは、例えば”Confidence content - Application signed by <C>”のような特定の文字列をＨＴＴＰヘッダに付加して構成してもよい。ここで<C>はアプリケーションの署名者の証明書またはその証明書のダイジェストの値である。このヘッダはその存在によりリクエストがユーザから直接送信され、出所の知られたソフトウェアプログラムによって生成されたことを示す。
この方法により、サーバ１が証明書<C>に対応付けられた秘密鍵の所有者を信用するならば、この特定のヘッダにマークが付与されたリクエストがユーザの有効な同意に正しく対応するものであることがサーバ１に保証される。マーク付与の要求条件は、アプリケーションがサーバに対し実際の署名者以外の署名者の権限を主張することができないことを意味する。
【００３２】
ダウンロードされたＪａｖａ（登録商標）アプレットの場合、仮想マシン６はアプリケーションのダウンロードアドレスを識別することができる。したがって、そのようなアプレットを送信元とする経験的に信用できないリクエストに、そのダウンロードアドレスまたはそのアドレスに関するデータを含むことを強制してもよい。
【００３３】
本発明のもう１つの実施形態は、マークの構文を逆にする。制御レイヤ５は、経験的に信用できないアプリケーション４を送信元とするリクエストに、信用できるアプリケーション３に特有のマークを除外することを強制する。
サーバ１に対してそれ自身が信用できるアプリケーションであることを明らかにするために、アプリケーション３は、アプリケーション３がサーバ１へ送信するリクエストにマークを含める。制御レイヤ５は経験的に信用できないアプリケーション４を送信元とする各々のリクエストにこのマークが存在しないことを確認し、信用できない特性は前述のようにリクエストの送信先サイトに従って判断することができる。経験的に信用できないアプリケーション４を送信元とするリクエストにこのマークが存在する場合は、次のように、そのリクエストは送信されない。そのマークは制御レイヤ５によって削除され、制御レイヤ５はネットワークＲを介して“マークが削除された”リクエストを送信してもよいし送信しなくてもよく、アプリケーション４に通知してもよいし、通知しなくてもよい。
マークの構文に用いられる規約は、もちろん、端末とサーバで共通であり、送受信前に双方が知らなければならない。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施形態によるシステムの構成を示すブロック図である。
【符号の説明】
【００３５】
１ サーバ
２ セミオープン端末
３ 信用できるアプリケーション
４ 信用できないアプリケーション
５ 制御レイヤ
６ 仮想マシン
Ｒ ネットワーク
【技術分野】
【０００１】
本発明は、ネットワークブラウザ型の活用ができるとともに、ユーザにアプリケーションのインストールを可能とするコンピュータ端末に関する。
【背景技術】
【０００２】
上記のような端末は、特に、ＷＡＰ（Wireless Application Protocol）を用いた電話機、オフィス用のコンピュータ、携帯型のコンピュータ、あるいは、ＰＤＡ（Personal Digital Assistants）であり得る。これらは、実際多くの場合はＩＰプロトコル（Internet Protocol）に基づいて運用されるデジタルデータネットワーク、特に、インターネットに接続されるという共通の特性を有する。
【０００３】
“クローズ”端末（例えばＭｉｎｉｔｅｌ）の場合は、端末に存在するアプリケーションは知られており、その端末が存在する間は変更することはできない。
端末のオープン性は、ユーザがその端末自身によって実行しようとする新たなアプリケーションをインストールし、かつ多くの場合ダウンロードするために提供される機能とされる。この機能を組み込んだ“オープン”端末の例は、
・例えば、Ｊａｖａ（登録商標）ＭＩＤＰ型（Mobile Information Device Profile、
サンマイクロシステムズ（登録商標）社）のアプリケーションダウンロード電話機
・例えば、ＷＭＬスクリプト型（「ＷＡＰ ＷＭＬスクリプト言語仕様」、バージョン
１．１、ＷＡＰフォーラム、２００１年１１月を参照）またはＥＣＭＡスクリプト
型（Ｊａｖａ（登録商標）スクリプトとも呼ばれる。「ＥＣＭＡスクリプト言語仕様」、
ＥＣＭＡ−２６２標準、第３版、１９９９年１２月を参照）のスクリプト処理機能
を有するブラウザ、または、アプレットを実行可能なブラウザ
・Ｐａｌｍ（登録商標）ＯＳ、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ、Ｓｙｍｂｉａｎ
（登録商標）等のオペレーティングシステムのもとで運用される大多数のＰＤＡ
・オフィス用または携帯型のコンピュータ
【０００４】
“セミオープン”端末は、ある機能がユーザによってインストールまたはダウンロードされたアプリケーションに直接利用可能でないオープン端末である。例えば、唯一“オープン”であるのはＥＣＭＡスクリプトである端末において、ダウンロードされたアプリケーションは全てのネットワーク機能を利用できるわけではない（例えば、最も一般的なトランスポートプロトコル、すわなち、ＴＣＰ（Transmission Control Protocol）またはＵＤＰ（User Datagram Protocol）のフォーマットに準拠していないＩＰパケットの送信）。これらの機能は間接的でかつ制御された方法で利用可能となりうる。例えば、ＥＣＭＡスクリプトの関数はＨＴＴＰ（Hypertext Transfer Protocol）によりページの読み込みを命令することができ、これはネットワークを利用するが制御された方法である。
“セミオープン”端末には次のようなものが共存している。
・例えば、端末メーカによって工場でインストールされたため、または、アプリケー
ションへの電子署名のような手法で獲得された保証のため、等、“信用できる”アプ
リケーションとみなされるアプリケーション、
・ユーザ自身によってユーザ自身の判断で端末にインストールされたが、信用できる
アプリケーションと同じ利用権限は有しないその他のアプリケーション。
【０００５】
一方、“フルオープン”端末は、ダウンロードされたアプリケーションに全ての機能が利用可能であるオープン端末である。端末のオープン性の概念は、それが生じる状況に大きく依存する。例えば、ＯＳＩモデル（データリンク層、ネットワーク層、セッション層、トランスポート層、等）の異なる階層においては、オープン性の程度も異なる。
【０００６】
ここで、サーバから遠隔で監視することができる機能、すなわち、ネットワーク機能に着目する。この状況においては、端末の“セミオープン”の特性は、一般に遠隔から監視することができかつ信用できるアプリケーションを利用できる実行権限が、信用できないアプリケーションを利用できないことを意味する（例えば、ＩＰネットワークにおいてＨＴＴＰ以外のリクエストを送信する権限）。これによりサーバは、受信したリクエストのうち信用できるアプリケーションを送信元とするリクエストと、その他のアプリケーションを送信元とするリクエストとを区別することができる。特に、ダウンロードされたアプリケーションを送信元とするリクエストと、最初から端末に存在するアプリケーションを送信元とするリクエストとを区別することができる。
【０００７】
オープン端末においては、プログラムがユーザをだますように振舞う可能性（トロイの木馬）を考慮しなければならない。したがって、リクエストが本当にユーザを送信元とするものであり、かつネットワークにおいてユーザの承諾を装うプログラムを送信元とするものでないことは、サーバに対して何も保証しない。このリスクは、クライアントから受信したデータに対するサーバの信用を低下させる。トロイの木馬がユーザの代わりにリクエストを送信する機能を有するならば、サーバ宛に送信されたリクエストがユーザの行動を反映するという前提は理にかなっていない。
【０００８】
したがって、端末に存在するアプリケーションは下記のように区別される。
・信用できるアプリケーション：サーバは、これらのアプリケーションがトロイの
木馬でないことを前提とする。例えば、ＷＡＰ電話機のＷＡＰブラウザは信用でき
るアプリケーションである。他の例は、署名付きでダウンロードされたＪａｖａ
（登録商標）ＭＩＤＰアプリケーションである。
・信用できないアプリケーション：サーバは、これらのアプリケーションはトロイの
木馬である可能性があると判断する。例えば、署名なしで端末にダウンロードされ
たＪａｖａ（登録商標）ＭＩＤＰアプリケーションは信用できないアプリケーショ
ンの可能性がある。
【０００９】
トロイの木馬のリスクに対する従来の対応は、信用できないアプリケーションの能力を制限することである。
セミオープン端末からのフレーム送信の制限は、通常は極めて厳しい方法が強いられている。（端末のオペレーティングシステムとともに提供された）システムアプリケーションのみ、所定のフレーム送信が許可される。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、そのアプリケーションが送信したフレームの内容（例えば、署名されたデータの送信）あるいはアプリケーションの特性（例えば、アプリケーションの内容に関係づけられた署名）によってサーバの信用を得る他の情報源による手段を有しているとしても、（信用できるかまたは信用できない）ダウンロードされたアプリケーションはサーバへフレームを送信することは不可能となる。
【００１１】
本発明の目的は、アプリケーションに対して柔軟であるにもかかわらず受信するサーバが識別可能な、“信用できる”アプリケーションと“信用できない”アプリケーションの間で、新たな種類の、リクエストを送信する能力の区別をすることである。信用の概念は様々な基準（署名、情報交換のタイプ、アプリケーションがダウンロードされるＵＲＬ等）に依存する。
【課題を解決するための手段】
【００１２】
したがって、本発明は、第１の装置は、第１のファミリーと、第１のファミリーより経験的に信用度が低い第２のファミリーとのそれぞれに属する第１および第２のアプリケーションを具備する、通信ネットワークを介した第１の装置と第２の装置との間での通信方法を提案する。本発明の１つの側面によれば、第２のファミリーに属するアプリケーションを送信元とし、ネットワークを介して第２の装置へ送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制される。本発明のもう１つの側面によれば、第２のファミリーに属するアプリケーションを送信元とし、ネットワークを介して第２の装置へ送信される各々のリクエストは、第１のファミリーに関係づけられたマークを除外することを強制され、マークは、ネットワークを介して送信され、第１のファミリーに属するアプリケーションを送信元とするリクエストのうち少なくともいくつかに含まれる。また、本発明は、第１の装置としてそのような通信方法を用いる手段を具備する通信端末を提案する。
【発明の効果】
【００１３】
この通信方法によれば、第１の装置で実行されるある特定の（“信用できる”）アプリケーションは、この第２の装置に対するこれらのフレームの信頼できる送信元の保証とともに、通常は遠隔のサーバである第２の装置の注意を喚起するためのフレームを送信することができる。第２のファミリーに属する経験的に信用できないアプリケーションへ強制的にマークを付与（あるいは対称的にはそれを除外）することによって、送信する場合に、これらの経験的に信用できないアプリケーションによって送信されたフレームと、信用できるアプリケーションから送信されたフレームとを区別する。これによりサーバは、信用でき受信すべきリクエストと拒否すべきリクエストとを区別することができる。
【００１４】
付与されるマークは完全に“隙のない（ｗａｔｅｒｔｉｇｈｔ）”ものでなければならない。すなわち、経験的に信用できないアプリケーションが、最も下位のレイヤ（例えばＴＣＰ接続要求）を攻撃することによって、あるレベル（例えば、ＨＴＴＰリクエスト関数）で行われる検査を免れることが不可能でなければならない。
【００１５】
この通信方法の一実施形態において、ネットワークを介して送信され、かつ第２のファミリーに属するアプリケーションを送信元とするリクエストに含まれるマークは、第２のファミリーに属するアプリケーションの特質および／または送信元の表示を含むことを強制される。この表示は例えば署名されたアプリケーションの署名の証明書、または、ネットワークを介してダウンロードされたアプリケーションのダウンロードアドレスに関するデータ中に存在する。これは、第１の装置によって、経験的に信用できないアプリケーションにすぎないと判断される可能性のあるアプリケーションが信用を有するか否かを評価するために遠隔の装置によって用いられる。
【００１６】
この通信方法によれば、ダウンロード機能（端末の“オープン性”）に本来備わっているリスクにもかかわらず、アプリケーションのダウンロードをサポートする端末は、サーバと完全に信用してデータを交換することができる。したがって、この通信方法はトロイの木馬に対して簡単で効果的な防御を提供する。
本発明の他の特徴及び利点は、添付図面を参照して限定のない典型的な実施形態について以下のように記載される。添付図面における唯一の図は本発明を用いたシステムの概要である。
【発明を実施するための最良の形態】
【００１７】
サーバ１のような遠隔の装置が、安全で柔軟な方法で、セミオープン端末２から通信ネットワークＲを介して受信したリクエストにおける信用を獲得させることを目的とするものである。この端末は、一方で例えばウェブブラウザのような信用できるアプリケーション３と、他方で特に端末のユーザがネットワークＲを介してダウンロードした経験的に信用できないアプリケーション４とを有する。
【００１８】
経験的に信用できないアプリケーション４は、ネットワークＲを介して送信するフレームまたはリクエストについて、図において、ネットワークにアクセスするために端末２に設けられたリソース６の一部を構成する制御レイヤ５の符号で表された制約がされる。
【００１９】
前記制御レイヤ５は、経験的に信用できないアプリケーション４によって送信されるフレームが満たす所定の属性を検証する。これらの属性が満たされれば、制御レイヤ５はフレームを通過させる。そうでない場合は、そのフレームをネットワークＲへ通過させずにそれらを送信したアプリケーション４に通知するか、あるいは、経験的に信用できないアプリケーションの要求条件を満たすようにフレームを修正する。後者の場合、そのフレームはサーバ１における信用を失い、サーバ１はそのフレームを利用することができない。
前述の制約は、あるアプリケーションからネットワークＲを介して送信されるリクエストに含まれる特定のマークの存否に関係する。
【００２０】
本発明の第１実施形態において制御レイヤ５は、経験的に信用できないアプリケーション４を送信元とするリクエストが、このアプリケーションのファミリーに関係づけられたマークを含むことを強制する。信用できるアプリケーション３は制御レイヤ５を迂回しかつマークが付与されていないリクエストを送信することを許可する機能を利用することができる。一方、ネットワークＲへアクセスするためのリソース６は、経験的に信用できないアプリケーション４の処理においてこの機能を有しない。
【００２１】
この第１実施形態の図示例において、端末２（例えば携帯電話機）は、図のモジュール６に対応するＪａｖａ（登録商標）仮想マシンを有する。仮想マシンはサンマイクロシステムズ（登録商標）社によって開発されたＪａｖａ（登録商標）プログラミング言語で記述されダウンロードされたアプリケーションを実行するために用いることができる。Ｊａｖａ（登録商標）言語の全ての命令は所定の検査の後、システム関数を呼び出す仮想マシンによって実行される。検査せずにシステム関数を呼び出すことはないので、Ｊａｖａ（登録商標）アプリケーションは明らかにセミオープン環境である。この端末２は、Ｊａｖａ（登録商標）コードのみをダウンロードすることができ、ユーザによってインストールされうるその他の種類のアプリケーションはダウンロードすることはできない。
経験的に信用できないアプリケーション４は、Ｊａｖａ（登録商標）言語で記述されている。
【００２２】
この実施形態において、ネットワークＲを介した端末２における情報交換に用いられるプロトコルは、ＨＴＴＰプロトコル（１９９６年５月にＩＥＴＦ（Internet Engineering Task Force）によって発行されたＲＦＣ（Request For Comment）１９４５）、ＴＣＰ（ＲＦＣ ７９３、ＩＥＴＦ、１９８１年９月）およびＩＰ（ＲＦＣ ７９１、ＩＥＴＦ、１９８１年９月）である。
【００２３】
前記サービスは、ユーザに属するコンテンツを格納するＨＴＴＰサーバ１によって提供される。リクエスト（例えば全てのファイルの削除をリクエスト）は、事実上ユーザから送信され、かつ悪意のあるＪａｖａ（登録商標）プログラムから送信されたものでないという条件を満たさなければならない。このサービスはもちろん一例であり、他のどのようなサービス（電子商取引、出版、メッセージング等）もこの技術を用いることができる。
【００２４】
前記マークは、ＨＴＴＰリクエストの”user-agent”ヘッダ領域（前述のＲＦＣ １９４５の１０．１５節を参照）に含まれる。このマークは”Non-confidence application: VM Java 1.2”のような特定の文字列に含まれ、それが存在することによってリクエストは経験的に信用できるアプリケーションから送信されていないことを示す。この文字列はアプリケーション４によって生成されたリクエストに既に存在していてもよい。その場合、仮想マシン６の制御レイヤ５はその存在を検証するのみである。そうでない場合、この制御レイヤ５はリクエストに正しくマークが付与されるようにその文字列を挿入する。
【００２５】
前記仮想マシン６によって付与されるマークの完璧さは、経験的に信用できないアプリケーション４がこの特定の文字列を含まないＨＴＴＰリクエストをネットワークＲを介して送信することが不可能であるという事実に基づく。特に、アプリケーション４は、ＨＴＴＰより下位のプロトコルレイヤ、特にＴＣＰソケットに接続することによってネットワークＲにアクセスすることはできない。マークは、経験的に信用できないアプリケーションが実行を強制され、どのような方法においても回避することができない仮想マシン６において直接実施される。
【００２６】
したがって、前記サーバ１は受信するリクエストの中から、経験的に信用できないアプリケーション４を送信元とするリクエストと、ウェブブラウザのような信用できるアプリケーション３を送信元とするリクエストとを区別する。
【００２７】
あるサイトについてのみ信用できるアプリケーションも存在する。例えば、Ｊａｖａ（登録商標）アプレットは、通常は、ダウンロードされたサイトからは信用できるアプレットであると判断されるが、その他のサイトからは信用できるアプレットであるとは判断されない。したがって、このダウンロードサイトへ送信されるリクエストにおいては、マークは必要であるとは限らない。すなわち、仮想マシン６は、そのようなアプレットを送信元とするとともに、ダウンロードされたサイト以外のサイトへ送信されるリクエストにマークを強制し、かつアプレットがそのソースサイトへ送信するリクエストにマークを含めるか除外するかはそのアプレットの自由に任せてもよい。もう１つの可能性は、そのようなアプレットから送信されるどのようなリクエストにも、送信先に関係なくマークを強制することである。
【００２８】
信用できないリクエストへのマーク付与の変形例として、これらのリクエストのいくつかを禁止してもよい。例えば、所定のサーバからダウンロードされた信用できないアプリケーションに対して、異なるサーバへ向けたリクエストを禁止してもよい。ソースサーバへのリクエストはマークを付与して可能なままとする。
他の実施形態においては、リクエストの送信元となる経験的に信用できないアプリケーション４の特質および／または送信元の表示をマークに補足すると効果的である。
【００２９】
この経験的に信用できないアプリケーション４は署名してもよい。それを送信元とするリクエストは、このアプリケーションにおいて遠隔のサーバの信用を確立するために適した次の構成要素のうち少なくとも１つを含むヘッダを有するマークが付与される。
・アプリケーションの署名者の証明書またはその証明書のダイジェスト
・アプリケーションの署名者の証明書から始まる証明列またはその証明書のダイジェ
スト
・この目的のためにアプリケーションのコードに含まれる特定の文字列
・動的な方法でアプリケーションを識別する可変要素
【００３０】
このような本発明の実施形態は、特に証明書によって署名されたＪａｖａ（登録商標）アプリケーションの場合に適用できる。
この場合、仮想マシン６は、リクエストの送信前にＪａｖａ（登録商標）アプリケーションの署名を検証しなければならない。実際、この検証はアプリケーション４が実行される前に行われる。
【００３１】
マークは、例えば”Confidence content - Application signed by <C>”のような特定の文字列をＨＴＴＰヘッダに付加して構成してもよい。ここで<C>はアプリケーションの署名者の証明書またはその証明書のダイジェストの値である。このヘッダはその存在によりリクエストがユーザから直接送信され、出所の知られたソフトウェアプログラムによって生成されたことを示す。
この方法により、サーバ１が証明書<C>に対応付けられた秘密鍵の所有者を信用するならば、この特定のヘッダにマークが付与されたリクエストがユーザの有効な同意に正しく対応するものであることがサーバ１に保証される。マーク付与の要求条件は、アプリケーションがサーバに対し実際の署名者以外の署名者の権限を主張することができないことを意味する。
【００３２】
ダウンロードされたＪａｖａ（登録商標）アプレットの場合、仮想マシン６はアプリケーションのダウンロードアドレスを識別することができる。したがって、そのようなアプレットを送信元とする経験的に信用できないリクエストに、そのダウンロードアドレスまたはそのアドレスに関するデータを含むことを強制してもよい。
【００３３】
本発明のもう１つの実施形態は、マークの構文を逆にする。制御レイヤ５は、経験的に信用できないアプリケーション４を送信元とするリクエストに、信用できるアプリケーション３に特有のマークを除外することを強制する。
サーバ１に対してそれ自身が信用できるアプリケーションであることを明らかにするために、アプリケーション３は、アプリケーション３がサーバ１へ送信するリクエストにマークを含める。制御レイヤ５は経験的に信用できないアプリケーション４を送信元とする各々のリクエストにこのマークが存在しないことを確認し、信用できない特性は前述のようにリクエストの送信先サイトに従って判断することができる。経験的に信用できないアプリケーション４を送信元とするリクエストにこのマークが存在する場合は、次のように、そのリクエストは送信されない。そのマークは制御レイヤ５によって削除され、制御レイヤ５はネットワークＲを介して“マークが削除された”リクエストを送信してもよいし送信しなくてもよく、アプリケーション４に通知してもよいし、通知しなくてもよい。
マークの構文に用いられる規約は、もちろん、端末とサーバで共通であり、送受信前に双方が知らなければならない。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施形態によるシステムの構成を示すブロック図である。
【符号の説明】
【００３５】
１ サーバ
２ セミオープン端末
３ 信用できるアプリケーション
４ 信用できないアプリケーション
５ 制御レイヤ
６ 仮想マシン
Ｒ ネットワーク
【特許請求の範囲】
【請求項１】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制されることを特徴とする通信方法。
【請求項２】
前記マークは、前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とする各々のリクエストに含まれることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とするリクエストに含まれるマークは、前記第２のファミリーに属するアプリケーションの特質および／または送信元の表示を含むことを強制されることを特徴とする請求項１または２に記載の通信方法。
【請求項４】
前記第２のファミリーに属するアプリケーション（４）は署名され、前記アプリケーションを送信元とするリクエストに含まれるマークは、署名の証明書に関するデータを含むことを強制されることを特徴とする請求項３に記載の通信方法。
【請求項５】
前記第２のファミリーに属するアプリケーション（４）は、ある１つのダウンロードアドレスから前記ネットワーク（Ｒ）を介してダウンロードされ、前記アプリケーションを送信元とするリクエストに含まれるマークは、前記アプリケーションのダウンロードアドレスに関するデータを含むことを強制されることを特徴とする請求項３または４に記載の通信方法。
【請求項６】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、前記第１のファミリーに関係づけられたマークを除外することを強制され、前記マークは前記ネットワークを介して送信され、かつ前記第１のファミリーに属するアプリケーション（３）を送信元とするリクエストのうち少なくともいくつかに含まれることを特徴とする通信方法。
【請求項７】
前記第２の装置（１）は、そのリクエストに付与された信用度を評価するため、前記第１の装置（２）から前記ネットワーク（Ｒ）を介して受信したリクエストに前記マークが存在するか否かを検査することを特徴とする請求項１から６のいずれか１項に記載の通信方法。
【請求項８】
前記リクエストに前記マークが存在するときには、前記第２の装置（１）は前記リクエストに付与された信用度を評価するため、前記マークに含まれるデータを検査することを特徴とする請求項７に記載の通信方法。
【請求項９】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションの署名の証明書に関するデータを有することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションのダウンロードアドレスに関するデータを有することを特徴とする請求項８に記載の通信方法。
【請求項１１】
前記リクエストはＨＴＴＰリクエストであり、かつ前記マークは前記ＨＴＴＰリクエストのヘッダに挿入されることを特徴とする請求項１から１０のいずれか１項に記載の通信方法。
【請求項１２】
前記マークに関する要求条件は、前記第１の装置（２）に備えられた仮想マシン（６）に属するソフトウェアレイヤ（５）によって制御され、前記第２のファミリーに属するアプリケーション（４）が前記仮想マシンと前記ソフトウェアレイヤとを介してのみ前記ネットワーク（Ｒ）にアクセス可能であることを特徴とする請求項１から１１のいずれか１項に記載の通信方法。
【請求項１３】
前記仮想マシン（６）は、Ｊａｖａ（登録商標）仮想マシンであることを特徴とする請求項１２に記載の通信方法。
【請求項１４】
第１の装置として請求項１から１３のいずれか１項に記載の通信方法を用いる手段を具備する通信端末（２）。
【特許請求の範囲】
【請求項１】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信されるリクエストのうち少なくとも１つは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制されることを特徴とする通信方法。
【請求項２】
前記マークは、前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とするリクエストのうち少なくとも１つに含まれることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とするリクエストに含まれるマークは、前記第２のファミリーに属するアプリケーションの特質および／または送信元の表示を含むことを強制されることを特徴とする請求項１または２に記載の通信方法。
【請求項４】
前記第２のファミリーに属するアプリケーション（４）は署名され、前記アプリケーションを送信元とするリクエストに含まれるマークは、署名の証明書に関するデータを含むことを強制されることを特徴とする請求項３に記載の通信方法。
【請求項５】
前記第２のファミリーに属するアプリケーション（４）は、ある１つのダウンロードアドレスから前記ネットワーク（Ｒ）を介してダウンロードされ、前記アプリケーションを送信元とするリクエストに含まれるマークは、前記アプリケーションのダウンロードアドレスに関するデータを含むことを強制されることを特徴とする請求項３または４に記載の通信方法。
【請求項６】
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制されることを特徴とする請求項１から５のいずれか１項に記載の通信方法。
【請求項７】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信されるリクエストのうち少なくとも１つは、前記第１のファミリーに関係づけられたマークを除外することを強制され、前記マークは前記ネットワークを介して送信され、かつ前記第１のファミリーに属するアプリケーション（３）を送信元とするリクエストのうち少なくともいくつかに含まれることを特徴とする通信方法。
【請求項８】
前記第２の装置（１）は、そのリクエストに付与された信用度を評価するため、前記第１の装置（２）から前記ネットワーク（Ｒ）を介して受信したリクエストに前記マークが存在するか否かを検査することを特徴とする請求項１から７のいずれか１項に記載の通信方法。
【請求項９】
前記リクエストに前記マークが存在するときには、前記第２の装置（１）は前記リクエストに付与された信用度を評価するため、前記マークに含まれるデータを検査することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションの署名の証明書に関するデータを有することを特徴とする請求項９に記載の通信方法。
【請求項１１】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションのダウンロードアドレスに関するデータを有することを特徴とする請求項９に記載の通信方法。
【請求項１２】
前記リクエストはＨＴＴＰリクエストであり、かつ前記マークは前記ＨＴＴＰリクエストのヘッダに挿入されることを特徴とする請求項１から１１のいずれか１項に記載の通信方法。
【請求項１３】
前記マークに関する要求条件は、前記第１の装置（２）に備えられた仮想マシン（６）に属するソフトウェアレイヤ（５）によって制御され、前記第２のファミリーに属するアプリケーション（４）が前記仮想マシンと前記ソフトウェアレイヤとを介してのみ前記ネットワーク（Ｒ）にアクセス可能であることを特徴とする請求項１から１２のいずれか１項に記載の通信方法。
【請求項１４】
前記仮想マシン（６）は、Ｊａｖａ（登録商標）仮想マシンであることを特徴とする請求項１３に記載の通信方法。
【請求項１５】
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、前記第１のファミリーに関係づけられたマークを除外することを強制され、前記マークは前記ネットワークを介して送信され、かつ前記第１のファミリーに属するアプリケーション（３）を送信元とするリクエストのうち少なくともいくつかに含まれることを特徴とする請求項７から１４のいずれか１項に記載の通信方法。
【請求項１６】
第１の装置として請求項１から１５のいずれか１項に記載の通信方法を用いる手段を具備する通信端末（２）。
【請求項１７】
通信ネットワーク（Ｒ）を介して第１の装置（２）によって第２の装置（１）へ送信されるリクエストであって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備し、
前記リクエストは、前記第２のファミリーに属するアプリケーション（４）を送信元とし、アプリケーションの第２のファミリーに関係づけられたマークを含み、前記第１の装置と前記第２の装置との間で、請求項１から６および８から１４のいずれか１項に記載の通信方法において用いられるリクエスト。
【請求項１８】
通信ネットワーク（Ｒ）を介して第１の装置（２）によって第２の装置（１）へ送信されるリクエストであって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備し、
前記リクエストは、前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記第１のファミリーに関係づけられたマークを除外し、前記第１の装置と前記第２の装置との間で、請求項７から１５のいずれか１項に記載の通信方法において用いられるリクエスト。
【請求項１】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制されることを特徴とする通信方法。
【請求項２】
前記マークは、前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とする各々のリクエストに含まれることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とするリクエストに含まれるマークは、前記第２のファミリーに属するアプリケーションの特質および／または送信元の表示を含むことを強制されることを特徴とする請求項１または２に記載の通信方法。
【請求項４】
前記第２のファミリーに属するアプリケーション（４）は署名され、前記アプリケーションを送信元とするリクエストに含まれるマークは、署名の証明書に関するデータを含むことを強制されることを特徴とする請求項３に記載の通信方法。
【請求項５】
前記第２のファミリーに属するアプリケーション（４）は、ある１つのダウンロードアドレスから前記ネットワーク（Ｒ）を介してダウンロードされ、前記アプリケーションを送信元とするリクエストに含まれるマークは、前記アプリケーションのダウンロードアドレスに関するデータを含むことを強制されることを特徴とする請求項３または４に記載の通信方法。
【請求項６】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、前記第１のファミリーに関係づけられたマークを除外することを強制され、前記マークは前記ネットワークを介して送信され、かつ前記第１のファミリーに属するアプリケーション（３）を送信元とするリクエストのうち少なくともいくつかに含まれることを特徴とする通信方法。
【請求項７】
前記第２の装置（１）は、そのリクエストに付与された信用度を評価するため、前記第１の装置（２）から前記ネットワーク（Ｒ）を介して受信したリクエストに前記マークが存在するか否かを検査することを特徴とする請求項１から６のいずれか１項に記載の通信方法。
【請求項８】
前記リクエストに前記マークが存在するときには、前記第２の装置（１）は前記リクエストに付与された信用度を評価するため、前記マークに含まれるデータを検査することを特徴とする請求項７に記載の通信方法。
【請求項９】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションの署名の証明書に関するデータを有することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションのダウンロードアドレスに関するデータを有することを特徴とする請求項８に記載の通信方法。
【請求項１１】
前記リクエストはＨＴＴＰリクエストであり、かつ前記マークは前記ＨＴＴＰリクエストのヘッダに挿入されることを特徴とする請求項１から１０のいずれか１項に記載の通信方法。
【請求項１２】
前記マークに関する要求条件は、前記第１の装置（２）に備えられた仮想マシン（６）に属するソフトウェアレイヤ（５）によって制御され、前記第２のファミリーに属するアプリケーション（４）が前記仮想マシンと前記ソフトウェアレイヤとを介してのみ前記ネットワーク（Ｒ）にアクセス可能であることを特徴とする請求項１から１１のいずれか１項に記載の通信方法。
【請求項１３】
前記仮想マシン（６）は、Ｊａｖａ（登録商標）仮想マシンであることを特徴とする請求項１２に記載の通信方法。
【請求項１４】
第１の装置として請求項１から１３のいずれか１項に記載の通信方法を用いる手段を具備する通信端末（２）。
【特許請求の範囲】
【請求項１】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信されるリクエストのうち少なくとも１つは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制されることを特徴とする通信方法。
【請求項２】
前記マークは、前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とするリクエストのうち少なくとも１つに含まれることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記ネットワーク（Ｒ）を介して送信され、かつ前記第２のファミリーに属するアプリケーション（４）を送信元とするリクエストに含まれるマークは、前記第２のファミリーに属するアプリケーションの特質および／または送信元の表示を含むことを強制されることを特徴とする請求項１または２に記載の通信方法。
【請求項４】
前記第２のファミリーに属するアプリケーション（４）は署名され、前記アプリケーションを送信元とするリクエストに含まれるマークは、署名の証明書に関するデータを含むことを強制されることを特徴とする請求項３に記載の通信方法。
【請求項５】
前記第２のファミリーに属するアプリケーション（４）は、ある１つのダウンロードアドレスから前記ネットワーク（Ｒ）を介してダウンロードされ、前記アプリケーションを送信元とするリクエストに含まれるマークは、前記アプリケーションのダウンロードアドレスに関するデータを含むことを強制されることを特徴とする請求項３または４に記載の通信方法。
【請求項６】
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、アプリケーションの第２のファミリーに関係づけられたマークを含むことを強制されることを特徴とする請求項１から５のいずれか１項に記載の通信方法。
【請求項７】
通信ネットワーク（Ｒ）を介した第１の装置（２）と第２の装置（１）との間の通信方法であって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備する通信方法において、
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信されるリクエストのうち少なくとも１つは、前記第１のファミリーに関係づけられたマークを除外することを強制され、前記マークは前記ネットワークを介して送信され、かつ前記第１のファミリーに属するアプリケーション（３）を送信元とするリクエストのうち少なくともいくつかに含まれることを特徴とする通信方法。
【請求項８】
前記第２の装置（１）は、そのリクエストに付与された信用度を評価するため、前記第１の装置（２）から前記ネットワーク（Ｒ）を介して受信したリクエストに前記マークが存在するか否かを検査することを特徴とする請求項１から７のいずれか１項に記載の通信方法。
【請求項９】
前記リクエストに前記マークが存在するときには、前記第２の装置（１）は前記リクエストに付与された信用度を評価するため、前記マークに含まれるデータを検査することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションの署名の証明書に関するデータを有することを特徴とする請求項９に記載の通信方法。
【請求項１１】
前記第２の装置（１）によって検査されるデータは、前記リクエストの送信元であるアプリケーションのダウンロードアドレスに関するデータを有することを特徴とする請求項９に記載の通信方法。
【請求項１２】
前記リクエストはＨＴＴＰリクエストであり、かつ前記マークは前記ＨＴＴＰリクエストのヘッダに挿入されることを特徴とする請求項１から１１のいずれか１項に記載の通信方法。
【請求項１３】
前記マークに関する要求条件は、前記第１の装置（２）に備えられた仮想マシン（６）に属するソフトウェアレイヤ（５）によって制御され、前記第２のファミリーに属するアプリケーション（４）が前記仮想マシンと前記ソフトウェアレイヤとを介してのみ前記ネットワーク（Ｒ）にアクセス可能であることを特徴とする請求項１から１２のいずれか１項に記載の通信方法。
【請求項１４】
前記仮想マシン（６）は、Ｊａｖａ（登録商標）仮想マシンであることを特徴とする請求項１３に記載の通信方法。
【請求項１５】
前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記ネットワークを介して前記第２の装置へ送信される各々のリクエストは、前記第１のファミリーに関係づけられたマークを除外することを強制され、前記マークは前記ネットワークを介して送信され、かつ前記第１のファミリーに属するアプリケーション（３）を送信元とするリクエストのうち少なくともいくつかに含まれることを特徴とする請求項７から１４のいずれか１項に記載の通信方法。
【請求項１６】
第１の装置として請求項１から１５のいずれか１項に記載の通信方法を用いる手段を具備する通信端末（２）。
【請求項１７】
通信ネットワーク（Ｒ）を介して第１の装置（２）によって第２の装置（１）へ送信されるリクエストであって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備し、
前記リクエストは、前記第２のファミリーに属するアプリケーション（４）を送信元とし、アプリケーションの第２のファミリーに関係づけられたマークを含み、前記第１の装置と前記第２の装置との間で、請求項１から６および８から１４のいずれか１項に記載の通信方法において用いられるリクエスト。
【請求項１８】
通信ネットワーク（Ｒ）を介して第１の装置（２）によって第２の装置（１）へ送信されるリクエストであって、
前記第１の装置は、第１のファミリーと、前記第１のファミリーより経験的に低い信用度を有する第２のファミリーとのそれぞれに属するアプリケーション（３、４）を具備し、
前記リクエストは、前記第２のファミリーに属するアプリケーション（４）を送信元とし、前記第１のファミリーに関係づけられたマークを除外し、前記第１の装置と前記第２の装置との間で、請求項７から１５のいずれか１項に記載の通信方法において用いられるリクエスト。
【図１】
【公表番号】特表２００６−５１１８９０（Ｐ２００６−５１１８９０Ａ）
【公表日】平成１８年４月６日（２００６．４．６）
【国際特許分類】
【出願番号】特願２００４−５６６９６８（Ｐ２００４−５６６９６８）
【出願日】平成１５年１０月２７日（２００３．１０．２７）
【国際出願番号】ＰＣＴ／ＦＲ２００３／００３１８１
【国際公開番号】ＷＯ２００４／０６６５８０
【国際公開日】平成１６年８月５日（２００４．８．５）
【出願人】（５９１０３４１５４）フランス・テレコム (290)
【Ｆターム（参考）】
【公表日】平成１８年４月６日（２００６．４．６）
【国際特許分類】
【出願日】平成１５年１０月２７日（２００３．１０．２７）
【国際出願番号】ＰＣＴ／ＦＲ２００３／００３１８１
【国際公開番号】ＷＯ２００４／０６６５８０
【国際公開日】平成１６年８月５日（２００４．８．５）
【出願人】（５９１０３４１５４）フランス・テレコム (290)
【Ｆターム（参考）】
[ Back to top ]