JP2012533101A - 保全された電子トークン中に埋込まれたアプリケーションを管理する方法 - Google Patents

Abstract

本発明は保全された電子トークン中に埋込まれたアプリケーションを管理する方法に係る。トークンはサーバマシンからメッセージを受信するように意図されている。メッセージはヘッダとボディとからなる。トークンはメッセージを管理可能なエージェントを含む。本方法は、ａ）アプリケーションの参照符号をメッセージのヘッダ中のエレメントの値と関連付けてアプリケーションをエージェント中に登録するステップと、ｂ）サーバマシンからメッセージを受信したとき、メッセージのヘッダがアプリケーションの参照符号に関連付けられた値を有するエレメントを含んでいればメッセージの一部をアプリケーションに送るステップと、を備える。
【選択図】 図１

Description

本発明は、保全された電子トークン中に埋込まれたアプリケーションを管理する方法に係り、より詳細には、スマートカード中に埋込まれたアプリケーションを管理する方法に関する。

スマートカードのような保全された電子トークンには、アプレット形式でアプリケーションを備えるものがある。それらアプレットには、ＯＴＡとして知られる無線（ｏｖｅｒ ｔｈｅ ａｉｒ）チャンネルを介したリモートサーバによってアクセスすることができる。ＯＴＡメカニズムは、ＥＴＳＩ ＳＣＰ １０２．２２５やＥＴＳＩ−ＳＣＰ １０２．２２６、及びＲＡＭ用ＧｌｏｂａｌＰｌａｔｆｏｒｍ ２．２規格によって規定されている。ＯＴＡチャンネルによって、ＳＩＭカード専用に開発されたデータやアプリケーションにアクセスすることができる。テレコムドメイン又はマシンツーマシン（Ｍ２Ｍ）で使用されることを意図されたスマートカードのみが、ＯＴＡ通信を管理することができる。

特にＳＩＭカードは、ＯＴＡ特性を提供する。通常ＨＴＴＰとして知られるハイパーテキスト転送プロトコル（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を介しても、当該スマートカードにアクセスすることができる。具体的には、ＯＭＡ−ＳＣＷＳ規格の１．０バージョン及びそれ以降のバージョンによって、スマートカードウェブサーバ（Ｓｍａｒｔ Ｃａｒｄ Ｗｅｂ Ｓｅｒｖｅｒ：ＳＣＷＳ）リソースのＯＴＡ管理のための管理プロトコルが規定されている。

当該プロトコルは、アドミンエージェント・アプリケーションによってＯＴＡサーバへ送信されるＨＴＴＰ ＰＯＳＴメッセージに基づくものである。アドミンエージェント・アプリケーションは、スマートカード内に位置する。ＯＴＡサーバはその応答として、ＳＣＷＳ管理命令をＨＴＴＰ ＰＯＳＴ応答のボディ内に入れて送り返す。前述の規格では、固有のコンテントタイプがＨＴＴＰ ＰＯＳＴ応答のヘッダに規定される。

このメッセージを受信すると、当該コンテントタイプに基づき、アドミンエージェント・アプリケーションはＨＴＴＰ ＰＯＳＴ応答のボディ部をＳＣＷＳへ転送することができ、ＨＴＴＰ ＰＯＳＴ応答のボディに含まれる管理命令を実行させるようにする。そして、一旦それらの管理命令がＳＣＷＳで実行されると、別のＨＴＴＰ ＰＯＳＴ要求がアドミンエージェント・アプリケーションによって送信され、ＯＴＡサーバに命令実行結果を通知する。この結果データは当該ＨＴＴＰ ＰＯＳＴメッセージのボディに記載され、特定のコンテントタイプが当該ＨＴＴＰ ＰＯＳＴのヘッダに設定される。

同様の原理を利用して、ＧｌｏｂａｌＰｌａｔｆｏｒｍ ２．２規格（修正Ｂ「ＲＡＭ ｏｖｅｒ ＨＴＴＰ」）が、スマートカードコンテンツのＯＴＡ管理のための管理プロトコルを規定している。このチャンネルは、セキュリティドメインやパッケージ及びアプレットを管理するためのリモートアプレット管理（Ｒｅｍｏｔｅ Ａｐｐｌｅｔ Ｍａｎａｇｅｍｅｎｔ：ＲＡＭ）に非常に適している。ＧｌｏｂａｌＰｌａｔｆｏｒｍ ２．２規格は、ＨＴＴＰ ＰＯＳＴ要求やＨＴＴＰ ＰＯＳＴ応答メッセージ内で使用されるコンテントタイプの固有パターンを特定する。

ＳＩＭカード用に開発されたアプリケーションの多くは、ＯＴＡチャンネルを管理することができるアプリケーション・プログラミング・インターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ：ＡＰＩ）を備えるように設計されている。スマートカードの当該アプリケーションは、ＨＴＴＰチャンネルを管理することはできない。現時点において、当該アプリケーションをその対象とすることができない。なぜならば、ＨＴＴＰ応答のルーティングは、アドミンエージェントによって確保されなければならず、また、アドミンエージェントはＯＭＡ−ＳＣＷＳ、ＨＴＴＰを介したＲＡＭ、及びＨＴＴＰを介したＲＦＭ以外のコンテントタイプ特定値を認識することができないためである。前述の３つの規格では、アドミンエージェント・アプリケーションが、「ＨＴＴＰを介したＯＴＡ」プロトコルを管理するために鍵となる構成要素となる。さらに、アドミンエージェント・アプリケーションは一般的に、スマートカードのオペレーティングシステムの一部である。そのため、その動作を変更することは容易にはできない。

ＳＣＷＳリソース管理や、ＧｌｏｂａｌＰｌａｔｆｏｒｍ規格又はＥＴＳＩ規格によって規定されるカードコンテント管理とは異なる目的にも、同一の「ＨＴＴＰを介したＯＴＡ」プロトコルのメカニズムを再利用する必要性がある。特に、スマートカード中に埋込まれた如何なるアプリケーションにも、ＨＴＴＰメカニズムを介してアクセスする必要性がある。特に、アプリケーションをパーソナライズしたり、アプリケーションによって提供されるサービスを利用したりするために、遠隔サーバが、スマートカード中に埋込まれたアプリケーションとＨＴＴＰセッションを介して通信できるようにする必要がある。

本発明は、上述の技術的問題を解決することを目的とする。
本発明の目的は、保全された電子トークン中に埋込まれたアプリケーションを管理する方法に係る。保全された電子トークンは、サーバマシンからメッセージを受信するように意図されている。保全された電子トークンは、このメッセージを管理可能なエージェントを含む。当該メッセージは、ヘッダとボディとからなる。本方法は、
ａ）アプリケーションの参照符号をメッセージのヘッダ中のエレメントの値と関連付けてアプリケーションをエージェント中に登録するステップと、
ｂ）サーバマシンからメッセージを受信したとき、メッセージのヘッダがアプリケーションの参照符号に関連付けられた値を含んでいればメッセージの一部をアプリケーションに送るステップと、を備える。

好適には、アプリケーションがメッセージに対する応答を発生したとき、当該方法は、当該応答をサーバマシンに送るステップを含むようにしてもよい。
好適な実施例によれば、当該メッセージはＨＴＴＰ又はＨＴＴＰＳのフォーマットに適合するようにしてもよい。
好適には、ヘッダのエレメントがＨＴＴＰ−ＲＦＣ ２６１６ ＨＴＴＰ／１．１規格に規定されるコンテントタイプであってもよい。
好適な実施例によれば、エージェントは、アプリケーションが前もってセットされた安全ルールに適合しないときには、前述の登録するステップを拒否するようにしてもよい。

好適には、エージェントは、エレメントの値が他のアプリケーションに既に登録されているときには、前述の登録するステップを拒否するようにしてもよい。
登録するステップがアプリケーションから要請されるようにしてもよい。
好適には、保全された電子トークンが第２のアプリケーションを含んでもよく、登録するステップが第２のアプリケーションから要請されるようにしてもよい。
代替的に、登録するステップがサーバマシンから要請されるようにしてもよい。

本発明の他の目的は、サーバマシンからメッセージを受信するように意図された保全された電子トークンに係る。保全された電子トークンは、メッセージを管理可能なエージェントを含む。メッセージはヘッダとボディとからなる。保全された電子トークンは、マイクロプロセッサと、通信インターフェースと、オペレーティングシステムと、ワーキングメモリ及び不揮発性メモリと、を備える。保全された電子トークンは、アプリケーションと、第１及び第２の手段とを含むよう意図される。第１の手段は、アプリケーションの参照符号をメッセージのヘッダ中のエレメントの値と関連付けてアプリケーションを登録することを可能にする。第２の手段は、メッセージのヘッダがアプリケーションの参照符号に関連付けられた値を有するエレメントを含んでいればメッセージの一部をアプリケーションに送付することを可能にする。

好適には、エージェントは、アプリケーションが前もってセットされた安全ルールに適合するか否かをチェックし、適合しないときにはアプリケーションの登録を拒否可能な第３の手段を含んでもよい。
好適な実施例によれば、アプリケーションはメッセージに対する応答を発生するようにしてもよく、エージェントは当該応答をサーバマシンに送付可能な第４の手段を含んでもよい。
好適には、アプリケーションは、アプリケーションをエージェントに登録するよう要請可能な第５の手段を含んでもよい。

好適な実施例によれば、メッセージはＨＴＴＰ又はＨＴＴＰのフォーマットに適合するようにしてもよく、ヘッダのエレメントはＨＴＴＰ−ＲＦＣ ２６１６ ＨＴＴＰ／１．１規格に規定されるコンテントタイプであってもよい。
好適な実施例によれば、保全された電子トークンは、スマートカードであってもよい。

本発明のその他の特徴点及び利点は、以下に記載する本発明のいくつかの好適な実施例を、対応する添付図面を参照しながら読むことによってさらに明らかになる。

本発明による、ホストマシンを介して遠隔サーバと通信する保全された電子トークンの構造の一例を概略的に示す図。 本発明による、エージェント内に埋込まれたレジスタの第１実施例の一例を示す図。 本発明による、エージェントの構造の一例を示す図。 本発明による、エージェント内に埋込まれたレジスタの第２実施例の一例を示す図。

本発明は、保全された電子トークンの如何なる形態にも適用することができる。特に、本発明は、通常ＨＴＴＰＳと呼ばれるハイパーテキスト転送プロトコル保全（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）を利用する保全された電子トークンにも適用することができる。本明細書では保全された電子トークンはＳＩＭカードとするが、ＨＴＴＰ又はＨＴＴＰＳメカニズムを利用することができる保全された電子機器の如何なる形態であってもよい。保全された電子トークンは、携帯可能であってもよく、また、一つ又はいくつかのメモリ、マイクロプロセッサ、及び通信インターフェースを含んでもよい。本明細書では、保全された電子トークンはホストマシンに接続される。具体的には、ホストマシンが携帯電話や電気通信端末であってもよい。電子トークンは、ホストマシンを介してリモートサーバにアクセスする。代替的に、如何なるホストマシンも介せずに、保全された電子トークンとサーバマシンとの間でＨＴＴＰＳメッセージを直接交換するようにしてもよい。

本発明は、アプリケーションの登録を可能にするエージェントに依存する。エージェント及びアプリケーションの両方とも、保全された電子トークンに貯蔵される。遠隔サーバは、ヘッダとボディとからなるメッセージを送信する。メッセージのボディは、登録されたアプリケーションが受信することを意図されている。アプリケーションが登録されると、当該アプリケーションは、ヘッダ領域の特定の値に関連付けられる。本発明によれば、エージェントは改良されたアドミンエージェントである。遠隔サーバからメッセージを受信すると、エージェントは、このメッセージの一部を対応するアプリケーションへと導く経路を決定することができる。

本発明によれば、遠隔サーバは、常に標準のＨＴＴＰメカニズムを使用することができ、かつ、目標とするアプリケーションのインターフェースの制約から完全に独立した状態を維持することができる。エージェントは、目標とするアプリケーションにフォーマットされたイシュー及びデータを管理する。

本発明の有利な点は、使用される電気通信端末をアップグレードすることを回避する点にある。流通している電気通信端末の数が膨大であるため、そのようなアップグレードは管理が大変であり、費用がかかってしまう。さらに、様々な種類の携帯電話が既に展開されている。

本発明の別の利点は、埋込まれたアプリケーションが特定の命令や応答を利用することを可能にする点にある。特定の命令や応答は、如何なるフォーマットに適合されていてもよい。
本発明のさらなる利点は、一つのトークン内に基本的なアドミンエージェント・アプリケーションを複数配備することを回避する点にある。エージェントを複数配備すると、メモリ容量が消費され、保全問題に関する多大な検討、監督及び認証が必要となる。

本発明の別の利点は、独特なＨＴＴＰ ＯＴＡセッションにより、様々なビジネスのＯＴＡ管理を混合させることができる点にある。例えば、本発明は、Ａｃｔｉｖａｔｉｏｎの動作をＩＭＥＩのトラッキング動作に混合することができる。
本発明のさらに別の利点は、遠隔サーバが、目標とするアプレットのアプレット識別子（Ａｐｐｌｅｔ Ｉｄｅｎｔｉｆｉｅｒ：ＡＩＤ）を有していないメッセージを送信することを可能にする点にある。

本発明のさらなる利点は、アドミンエージェントに如何なる影響も与えずに、カードが発行された後にダウンロードされたアプリケーションに対してＯＴＡがアクセスすることを可能にする点にある。言い換えれば、パーソナライズ後の段階においてダウンロードされたアプリケーションに対し、アドミンエージェントを変更せずとも、ＯＴＡチャンネルが到達することができる。

図１は、本発明の好適な実施例に基づく、ＳＩＭカード形式の保全された電子トークンＳＣの構造を示す。
保全された電子トークンＳＣは、ＲＡＭタイプのワーキングメモリＭＥＭ１と、二つの不揮発性メモリＭＥＭ２及びＭＥＭ３と、マイクロプロセッサＭＰと、通信インターフェースＩＮとを備える。不揮発性メモリＭＥＭ２は、Ｊａｖａ（登録商標）仮想マシンを含みうるオペレーティングシステムＯＳを備える。

不揮発性メモリＭＥＭ３は、二つのアプレットＡＰ１及びＡＰ２と、スマートカードウェブサーバＳＣＷＳと、セキュリティドメインＳＤと、エージェントＡＡとを備える。セキュリティドメインＳＤは、ＧｌｏｂａｌＰｌａｔｆｏｒｍ規格に適合する。
二つのメモリＭＥＭ２及びＭＥＭ３は、一つ又は二つ若しくはそれ以上のメモリの組み合わせで実現されてもよい。それらのメモリは、ＮＡＮＤフラッシュメモリやＥＥＰＲＯＭメモリ又はその他の種類の不揮発性メモリであってもよい。

ＳＩＭカードＳＣは、通信インターフェースＩＮを介して通信電話機ＨＭとメッセージを交換することを意図されている。通信電話機ＨＭは、ＯＴＡメカニズムを介して遠隔サーバＳＲとメッセージを交換することを意図されている。従って、ＳＩＭカードＳＣは、接続されたホストマシンＨＭを介して遠隔サーバＳＲとメッセージを交換することができる。

エージェントＡＡは、Ｊａｖａカード内のアプレットとして実現されてもよい。本実施例では、二つのアプリケーションＡＰ１及びＡＰ２は、セキュリティドメインＳＤに依存する。アプレットＡＰ１は、アプレットＡＰ１を登録することをエージェントＡＡに対して要求することができる手段Ｍ５を含む。
好適な実施例では、エージェントＡＡは、セキュリティドメインＳＤに併合されてもよい。

図２は、本発明によるエージェントＡＡ内に埋込まれたレジスタＲＧの第１実施例の一例を示す。
レジスタＲＧは、いくつかの組｛エレメント値、アプリケーションの参照符号｝を含むように意図されている。図２の例では、レジスタＲＧは、二つの組｛ＥＶ１、ＲＦ１｝と｛ＥＶ２、ＲＦ２｝とを備える。

ＲＦ１はアプレットＡＰ１の参照符号であり、ＲＦ２はアプレットＡＰ２の参照符号である。例えばＲＦ１は、アプレットＡＰ１のＡＩＤと同一であってもよく、また、ＡＰ１を特定するアドレス若しくは専用レジストリに貯蔵された識別子を特定するアドレスであってもよい。

ＥＶ１はアプレットＡＰ１に関連付けられた値であり、ＥＶ２はアプレットＡＰ２に関連付けられた値である。第１実施例では、値ＥＶ１及びＥＶ２は、ＨＴＴＰメッセージのヘッダ中の潜在的に前もって設定された領域の可能値になるべきものである。具体的には、二つの値ＥＶ１及びＥＶ２は、ＨＴＴＰヘッダ中のコンテントタイプ領域において見つかるように意図されてもよい。例えば、ＥＶ１は「ａｐｐｌｉｃａｔｉｏｎ／ＩｍｅｉＴｒａｃｋｎｇ／１．０」と同一でもよく、ＥＶ２は「ａｐｐｌｉｃａｔｉｏｎ／ＰＤＭ／１．０」と同一でもよい。本実施例では、ＥＶ２は電話帳アプリケーションに対応してもよい。ここでＰＤＭとは、個人データマネージャ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ｍａｎａｇｅｒ）の略である。

図３は、エージェントＡＡの構造の一例を示す。エージェントは、レジスタＲＧと４つの手段Ｍ１，Ｍ２，Ｍ３及びＭ４とを備える。
手段Ｍ１は、アプレットＡＰ１を登録することを可能にする。登録は、アプリケーションＡＰ１の参照符号ＲＦ１とＨＴＴＰメッセージのヘッダ中のエレメントの値とを関連付けることにより実行される。レジスタＲＧにおいて使用される参照符号によって、エージェントＡＡが、動作を開始する目標のアプリケーションを識別することを可能にする。

サーバＳＲからＨＴＴＰメッセージを受信したとき、ＨＴＴＰメッセージのヘッダが、参照符号ＲＦ１に関連付けられた値ＥＶ１と同一のエレメントを含んでいれば、手段Ｍ２はＨＴＴＰメッセージの一部をアプレットＡＰ１に送付することを可能にする。同様に、ＨＴＴＰメッセージのヘッダが参照符号ＲＦ２に関連付けられた値ＥＶ２と同一のエレメントを含んでいれば、手段Ｍ２は受信されたＨＴＴＰメッセージの一部をアプレットＡＰ２に送付することを可能にする。一般的には、目標のアプレットに送付される当該ＨＴＴＰメッセージの一部は、サーバＳＲによって送付されるＨＴＴＰメッセージのボディ全体である。

手段Ｍ３は、アプレットＡＰ１が前もってセットされた安全ルールに適合するか否かをチェックすることを可能にする。当該安全チェックに失敗した場合、手段Ｍ３はアプレットの登録を拒否する。例えば、手段Ｍ３はアプレットＡＰ１がエージェントＡＡと同一のセキュリティドメイン内にあるか否かをチェックするようにしてもよい。
ほとんどの場合、アプレットＡＰ１はエージェントＡＡから受信したデータに対する応答を発生する。手段Ｍ４は、当該応答を遠隔サーバＳＲに送付することを可能にする。当該応答の送付は、応答を含むＨＴＴＰメッセージのおかげで実行することができる。

図４は、本発明によるエージェントＡＡ内に埋込まれたレジスタＲＧの第２実施例の一例を示す。レジスタＲＧは、サブセット｛ヘッダエレメントの識別子、エレメント値、及びアプリケーションの参照符号｝を含む。図４の例では、レジスタＲＧは、一つのサブセット｛ＨＥ１、ＥＶ１、ＲＦ１｝を含む。ＲＦ１はアプレットＡＰ１の参照符号であり、ＥＶ１はアプレットＡＰ１に関連付けられた値である。ＨＥ１はＨＴＴＰメッセージのヘッダ領域の識別子である。

例えば、識別子ＨＥ１はコンテントタイプ領域を指すようにしてもよい。例えば、識別子ＨＥ１がコンテントタイプ領域に対応する場合、ＨＥ１は「コンテントタイプ」と同一であってもよい。代替的には、ＨＴＴＰメッセージが、独自に設定された領域を用いて定義される他のヘッダを含んでもよい。例えば、識別子ＨＥ１がＨＴＴＰメッセージの追加的に独自に設定されたヘッダに対応する場合、ＨＥ１は「Ｘ−Ａｄｍｉｎ−Ｔｏ」と同一になるようにしてもよい。

本発明の実施例によると、第１のステップは、アプレットＡＰ１をエージェントＡＡに登録することに対応する。例えば、登録はアプレットＡＰ１自身によって要求されうる。アプレットは、ＨＴＴＰメッセージのヘッダ中のエレメントの値ＥＶ１とアプレットＡＰ１の参照符号ＲＦ１との組を貯蔵することによってエージェントＡＡに登録される。好適な実施例によると、ＨＴＴＰメッセージのヘッダ中のエレメントは、コンテントタイプである。値ＥＶ１は、ＯＭＡ−ＳＣＷＳ規格やＧｌｏｂａｌＰｌａｔｆｏｒｍ２．２規格によって規定されるパターンとは異なるように選択されなければならない。

アプリケーションＡＰ１がＯＴＡセッションを開始するための要求を発生するようにしてもよい。そのような場合、アプリケーションＡＰ１はこの要求をエージェントＡＡに送付する。

次に、エージェントＡＡは、接続されたホストマシンＨＭを介して第１のＨＴＴＰ ＰＯＳＴメッセージをリモートサーバＳＲに送付する。
そして、リモートサーバＳＲは、ＨＴＴＰ応答メッセージをトークンＳＣに送付する。当該ＨＴＴＰ応答メッセージのヘッダには、ＥＶ１と同一のコンテントタイプ領域が含まれる。ＨＴＴＰ応答メッセージはトークンＳＣ中のエージェントＡＡによって受信される。

エージェントＡＡは、アプレットがその値ＥＶ１で登録されているか否かをチェックする。アプレットＡＰ１は登録され、かつ、コンテントタイプ領域のための値ＥＶ１と関連付けられているため、エージェントＡＡは受信したＨＴＴＰ応答メッセージのボディを展開する。一例として、電話帳を更新することを目的とした応用コマンドがボディに含まれるようにしてもよい。またボディは、ＴＬＶ構造又はその他関連するフォーマットに基づく応用メッセージを含むようにしてもよい。続いて、エージェントＡＡは展開したデータをアプレットＡＰ１に送付する。好適な実施例では、ＲＦ１はアプレットＡＰ１のＡＩＤと同一である。従って、エージェントＡＡは目標とするアプリケーションを容易に見つけることができる。

次に、アプレットＡＰ１は受信したデータを処理し、受信した応用コマンドに対応する応答を算出する。アプレットＡＰ１はエージェントＡＡに当該応答を送付する。するとエージェントＡＡは、アプレットからの応答を含むＨＴＴＰ ＰＯＳＴメッセージを発生させ、当該ＨＴＴＰ ＰＯＳＴメッセージをサーバＳＲに送付する。アプレットＡＰ１はエージェントＡＡにサーバＳＲのＵＲＬを提供する。ＨＴＴＰ ＰＯＳＴメッセージは、コンテントタイプがＥＶ１に設定されたヘッダとアプレットＡＰ１から提供される応答を含むボディとを有して発生する。従ってサーバＳＲは最初のＨＴＴＰ応答メッセージに対応するＨＴＴＰ ＰＯＳＴメッセージを受信する。

好適な実施例では、サーバＳＲとエージェントＡＡとは両方ともＨＴＴＰＳを介したＨＴＴＰ通信を保全するための認証情報を有する。
代替的には、レジスタＲＧは、図４に記載されているような、サブセット｛ＨＥ１、ＥＶ１、ＲＦ１｝を含むようにしてもよい。具体的には、識別子ＨＥ１がＨＴＴＰヘッダのコンテントタイプ領域に対応するようにしてもよい。このような場合、エージェントＡＡは、アプレットがヘッダ領域ＨＥ１中の値ＥＶ１で登録されているのか否かをチェックする。

本発明によれば、遠隔ＨＴＴＰサーバは、保全された電子トークン中に埋込まれたアプリケーションに完全なＯＴＡスクリプトを送付することができる。特に、リモートＨＴＴＰサーバは、スマートカードウェブサーバとは異なるアプリケーションへ、完全なＯＴＡスクリプトを送付することができる。
好適には、既にアプレットに登録されているエレメントの値を別のアプレットに登録しようとする試みは拒否される。

代替的には、エージェントＡＡは、レジスタＲＧにより、目標とするアプリケーションを選択する際に起こりうる対立を管理することができる。主要なルールとして、最大でも一つのアプリケーションを選択するようにする。前もって設定された専用の指針に従って、アプリケーションが一つも選択されないか、一つだけ選択される。例えば、エージェントＡＡは、レジスタＲＧ中の登録事項に最初に合致するアプリケーションを選択する。

ある実施例では、自己登録のみが許可されるようにしてもよい。すなわち、アプレットは、それ自体の登録を要求することしかできないようにする。
代替的には、保全された電子トークン中に埋込まれた別のアプリケーションからの委任によって登録されるようにしてもよい。従って、あるアプレットの登録を別のアプレットが行うように権限を与えてもよい。そのような場合、登録される目標とするアプレットは、どちらにしても、既にトークンＳＣ内に必ず存在する。

他の実施例では、エージェントＡＡは、アプレットの登録を遠隔から行えるようにしてもよい。従って、遠隔サーバＳＲがアプレットＡＰ１の登録を依頼するようにしてもよい。例えば、エージェントＡＡは、遠隔登録専用のＯＴＡコマンドを提供する。従って、遠隔サーバは保全されたトークン中の新規のアプレットを、ロード、インストール及び登録することができる。
好適には、エージェントＡＡが、レジスタＲＧ内のアプレットの登録の削除を要求することを可能にする特徴を有してもよい。この特徴は、Ｊａｖａカード又はＯＴＡのエントリポイントにより実現することができる。

本発明の利点は、遠隔サーバと保全されたトークン中に埋込まれたアプリケーションとの間で、ＨＴＴＰＳチャンネルの動的管理を可能にする点にある。登録メカニズムにより、実用上及び管理上のニーズに従って、アプリケーションとリモートサーバとの間のリンクを設定したり解除したりすることができる。

Claims (15)

1. 保全された電子トークン（ＳＣ）中に埋込まれたアプリケーション（ＡＰ１）を管理する方法であって、
   前記保全された電子トークン（ＳＣ）はヘッダとボディとからなるメッセージを管理可能なエージェント（ＡＡ）を含み、サーバマシン（ＳＲ）から前記メッセージを受信するよう意図されており、
   前記方法は、
   ａ）前記アプリケーション（ＡＰ１）の参照符号（ＲＦ１）を前記メッセージの前記ヘッダ中のエレメントの値と関連付けて前記アプリケーション（ＡＰ１）を前記エージェント（ＡＡ）中に登録するステップと、
   ｂ）前記サーバマシン（ＳＲ）から前記メッセージを受信したとき、前記メッセージの前記ヘッダが前記アプリケーション（ＡＰ１）の前記参照符号（ＲＦ１）に関連付けられた前記値を含んでいれば前記メッセージの一部を前記アプリケーション（ＡＰ１）に送るステップと、
   を備えることを特徴とする方法。
2. 請求項１に記載の方法において、
   ｃ）前記アプリケーション（ＡＰ１）が前記メッセージに対する応答を発生したとき、
   前記応答を前記サーバマシン（ＳＲ）に送るステップを更に備えることを特徴とする方法。
3. 請求項１又は２に記載の方法において、
   前記メッセージはＨＴＴＰ又はＨＴＴＰＳのフォーマットに適合することを特徴とする方法。
4. 請求項３に記載の方法において、
   前記ヘッダの前記エレメントはＨＴＴＰ−ＲＦＣ ２６１６ ＨＴＴＰ／１．１規格に規定されるコンテントタイプであることを特徴とする方法。
5. 請求項１乃至４のいずれか１項に記載の方法において、
   前記エージェント（ＡＡ）は、前記アプリケーション（ＡＰ１）が前もってセットされた安全ルールに適合しないときには、前記登録するステップａ）を拒否することを特徴とする方法。
6. 請求項１乃至５のいずれか１項に記載の方法において、
   前記エージェント（ＡＡ）は、前記エレメントの前記値が他のアプリケーションに既に登録されているときには、前記登録するステップａ）を拒否することを特徴とする方法。
7. 請求項１乃至６のいずれか１項に記載の方法において、
   前記登録するステップａ）が前記アプリケーション（ＡＰ１）から要請されることを特徴とする方法。
8. 請求項１乃至６のいずれか１項に記載の方法において、
   前記保全された電子トークン（ＳＣ）が第２のアプリケーション（ＡＰ２）を含み、
   前記登録するステップａ）が前記第２のアプリケーション（ＡＰ２）から要請されることを特徴とする方法。
9. 請求項１乃至６のいずれか１項に記載の方法において、
   前記登録するステップａ）が前記サーバマシン（ＳＲ）から要請されることを特徴とする方法。
10. ヘッダとボディとからなるメッセージを管理可能なエージェント（ＡＡ）を含み、サーバマシン（ＳＲ）から前記メッセージを受信するよう意図された保全された電子トークン（ＳＣ）であって、
    マイクロプロセッサ（ＭＰ）と、
    通信インターフェース（ＩＮ）と、
    オペレーティングシステム（ＯＳ）と、
    ワーキングメモリ（ＭＥＭ１）及び不揮発性メモリ（ＭＥＭ２）と、を備え、
    アプリケーション（ＡＰ１）を構成するよう意図された前記電子トークン（ＳＣ）において、
    前記エージェント（ＡＡ）は、
    前記アプリケーション（ＡＰ１）の参照符号（ＲＦ１）を前記メッセージの前記ヘッダ中のエレメントの値と関連付けて前記アプリケーション（ＡＰ１）を登録可能な第１の手段（Ｍ１）と、
    前記メッセージの前記ヘッダが前記アプリケーション（ＡＰ１）の前記参照符号（ＲＦ１）に関連付けられた前記値を含んでいれば前記メッセージの一部を前記アプリケーション（ＡＰ１）に送付可能な第２の手段（Ｍ２）と、を含むことを特徴とする保全された電子トークン（ＳＣ）。
11. 請求項１０に記載の保全された電子トークン（ＳＣ）において、
    前記エージェント（ＡＡ）は、
    前記アプリケーション（ＡＰ１）が前もってセットされた安全ルールに適合するか否かをチェックし、適合しないときには前記アプリケーション（ＡＰ１）の登録を拒否可能な第３の手段（Ｍ３）を含むことを特徴とする保全された電子トークン（ＳＣ）。
12. 請求項１０又は１１に記載の保全された電子トークン（ＳＣ）において、
    前記エージェント（ＡＡ）は、
    前記アプリケーション（ＡＰ１）が前記メッセージに対する応答を発生したとき、前記応答を前記サーバマシン（ＳＲ）に送付可能な第４の手段（Ｍ４）を含むことを特徴とする保全された電子トークン（ＳＣ）。
13. 請求項１０乃至１２のいずれか１項に記載の保全された電子トークン（ＳＣ）において、
    前記アプリケーション（ＡＰ１）は、前記アプリケーション（ＡＰ１）を前記エージェント（ＡＡ）に登録するよう要請可能な第５の手段（Ｍ５）を含むことを特徴とする保全された電子トークン（ＳＣ）。
14. 請求項１０乃至１３のいずれか１項に記載の保全された電子トークン（ＳＣ）において、
    前記メッセージはＨＴＴＰ又はＨＴＴＰＳのフォーマットに適合し、前記ヘッダの前記エレメントはＨＴＴＰ−ＲＦＣ ２６１６ ＨＴＴＰ／１．１規格に規定されるコンテントタイプであることを特徴とする保全された電子トークン（ＳＣ）。
15. 請求項１０乃至１４のいずれか１項に記載の保全された電子トークン（ＳＣ）において、
    前記保全された電子トークン（ＳＣ）はスマートカードであることを特徴とする保全された電子トークン（ＳＣ）。

Images