ＩＣカードのための鍵配送ユニット
【課題】性能をローディングおよび削除する選択的なアプリケーションを有するマルチアプリケーションＩＣカードシステムを提供する。
【解決手段】性能をローディングおよび削除する選択的なアプリケーションを有するマルチアプリケーションＩＣカードシステムは、ＩＣカード上へアプリケーションをロードする前に、カード上に格納されたパーソナル化データを使用し、かつ、アプリケーションをロードし得る１つ以上のカードのセットを示すアプリケーションに付随する許可データと比較する、アプリケーションをカードが受け取る資格があるかどうか判定するテストが行われる。カードのパーソナル化データは、アプリケーションのための許可可能のセット内にある場合、アプリケーションはカードにロードされ得る。好ましくは、許可データは、カード番号、発行者、製品クラスおよびカードがパーソナル化された日付を表すデータを含む。
【解決手段】性能をローディングおよび削除する選択的なアプリケーションを有するマルチアプリケーションＩＣカードシステムは、ＩＣカード上へアプリケーションをロードする前に、カード上に格納されたパーソナル化データを使用し、かつ、アプリケーションをロードし得る１つ以上のカードのセットを示すアプリケーションに付随する許可データと比較する、アプリケーションをカードが受け取る資格があるかどうか判定するテストが行われる。カードのパーソナル化データは、アプリケーションのための許可可能のセット内にある場合、アプリケーションはカードにロードされ得る。好ましくは、許可データは、カード番号、発行者、製品クラスおよびカードがパーソナル化された日付を表すデータを含む。
【発明の詳細な説明】
【背景技術】
【０００１】
（発明の背景）
集積回路（「ＩＣ」）カードは、今日世界中で、多くの異なる目的のためにますます多く使用されている。ＩＣカード（スマートカードとも呼ばれる）は、典型的に、従来のクレジットカードの大きさであり、コンピュータチップを有している。このコンピュータチップには、マイクロプロセッサ、リードオンリーメモリ（ＲＯＭ）、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、入力／出力（Ｉ／Ｏ）メカニズム、および、動作中にマイクロプロセッサをサポートするその他の回路が含まれている。ＩＣカードは、そのメモリ内に、単一のアプリケーションを有していてもよいし、あるいは、複数の独立したアプリケーションを有していてもよい。ＭＵＬＴＯＳＴＭは、他のプラットフォームの中でもとりわけＩＣカード上で動作し、そのカード上で複数のアプリケーションの実行を可能にするマルチアプリケーションオペレーティングシステムである。これにより、カードユーザは、そのカードを使用するために挿入した端末（即ち、ＡＴＭ、電話および／またはＰＯＳ）の種類に関わらず、そのカードに保存された多数のプログラム（例えば、クレジット／デビット、電子マネー／財布、および／またはロイヤリティアプリケーション）を実行することができるようになる。
【０００２】
テレフォンカードおよび電子キャッシュカードのような従来の単一アプリケーションＩＣカードは、カードユーザに与えられる前に、その製造の時点で、単一のアプリケーションを付与される。しかし、たとえカードユーザまたはカード発行者がアプリケーションの改変を望んだとしても、カード発行後にアプリケーションを改変または変更することはできない。さらに、あるカードユーザが、そのユーザに対して発行されたＩＣカードに、様々なアプリケーション機能、例えば、電子財布およびクレジット／デビット機能の両方を果たして欲しい場合、カードユーザは複数の物理的カードを持ち運ばなければならない。これは、非常に煩雑で不便である。アプリケーション開発者（ａｐｐｌｉｃａｔｉｏｎ ｄｅｖｅｌｏｐｅｒ）またはカードユーザが、２つの異なるアプリケーション間での相互作用またはデータ交換、例えば、財布機能がフリークエントフライヤーロイヤリティアプリケーションと相互作用することを望んだ場合、カードユーザは、カードを入れる端末に複数のカードを代わる代わる出し入れしなければならず、処理が、困難で、時間がかかり、不便なものになる。
【０００３】
従って、同じＩＣカード上に複数アプリケーションを保存することは有益である。例えば、カードユーザは、同じカード上に財布アプリケーションおよびクレジット／デビットアプリケーションの両方を有し、買物を行うときにどちらの種類の支払い（電子キャッシュまたはクリジットカード）を使用するのかを選択し得る。十分なメモリが存在し、且つ、複数のアプリケーションをサポートできるオペレーティングシステムがカード上にあれば、１枚のＩＣカードに複数のアプリケーションを付与することができる。複数のアプリケーションを予め選択して、それらを製造段階でカードのメモリ内に入れておくことも可能であるが、必要に応じて、製造後に、そのカードのアプリケーションをロードおよび削除できるようにすることも有益であろう。
【０００４】
１枚のカード上に複数のアプリケーションを保存する向上した柔軟性および性能は、個々のカードとアプリケーション提供者との間で交換され、また、アプリケーションをロードおよび削除する際に全システム内で交換される情報（アプリケーションコードおよび関連するデータを含む）の完全性および安全性に関して克服すべき新たな技術的課題を生み出す。カード、カード発行者、システムオペレータおよびアプリケーション提供者間で安全にデータを交換できる能力、ならびに、ローカル端末から、または、電話線、インターネット、イントラネット接続、もしくはその他のデータ経路上で遠隔的に、何時でも安全にアプリケーションをロードおよび削除できる能力をＩＣカードシステム内に持つことは有益であろう。典型的にこれらのデータ送信線は安全な線ではないので、これらの送信線上で送られるアプリケーションが改竄されることなく意図したカード上にのみロードされることを確実にするためには、複数のセキュリティおよびエンティティ認証技術を確立しなければならない。
【０００５】
特に、カード所有者が利用できる新たなアプリケーションが増え続けている状況では、上記のように、発行後にＩＣカード上にアプリケーションを追加する能力をシステムに持たせることが重要である。このことは、ＩＣカードの寿命の長さを守るために必要である。さもなくば、アプリケーションが古くなったときに、そのカードが無用になってしまう。遠隔位置から、および、アプリケーション提供者の端末からの直接接続によって、アプリケーションを追加できるようにすることは有益であろう。例えば、カードユーザが、そのユーザのＩＣカードをユーザのホームコンピュータに差し込んで、インターネット上でアプリケーションをダウンロードできれば有用であろう。アプリケーションコードおよび関連データをインターネット等のセキュリティが確立されていない通信線上で送信する場合、この種のアプリケーション遠隔ロードは複数のセキュリティ上のリスクを生じる。このような能力を提供するシステムにおいて、少なくとも３つの問題点に取り組む必要がある。
【０００６】
第１の問題点は、アプリケーションを受け取るＩＣカードが、目的のＩＣカードであり、別のＩＣカードにならないように確実に取り計らうことである。第２の問題点は、アプリケーションが適切なアプリケーションプロバイダから得られたものであって、未知の第三者から得られたものでないことを、ＩＣカードがどのようにして認証（ａｕｔｈｅｎｔｉｃａｔｅ）することができるかを判定することである。第３の問題点は、第三者がアプリケーションから読み出しを行って、認可されていない（ｕｎａｕｔｈｏｒｉｚｅｄ）コピーを作ることを防ぐことに関する。後半の問題点に取り組むために、アプリケーションの一部分が暗号化される場合、目的のＩＣカードは、アプリケーションを復号化するための正確な鍵へのアクセスを持っている必要がある。多くのＩＣカードおよびさらなる多くのアプリケーションプロバイダを有するシステムにおいて、目的のＩＣカードが、受け取られたアプリケーションについての正確な鍵を使用できるように、安全鍵伝送技術（ｓｅｃｕｒｅ ｋｅｙ ｔｒａｎｓｆｅｒ ｔｅｃｈｎｉｑｕｅ）が要求される。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、本発明の実施の目的の１つは安全な鍵配送技術を提供することであり、具体的には、ＩＣカード上にロードされ得るスマートカードアプリケーションのための改善された安全な配送を可能にする改善された安全なＩＣカードシステムを提供することである。
【課題を解決するための手段】
【０００８】
（発明の要旨）
ＩＣカードシステム、ならびにＩＣカード上へアプリケーションを安全にロードするための方法を提供する本発明により、これらおよび他の目的が達成される。ＩＣカード上へアプリケーションを安全にロードする方法は，ＩＣカードのための秘密鍵および公開鍵のペアを提供すること、転送鍵を用いアプリケーションの少なくとも一部を暗号化すること、ＩＣカードの公開鍵を用いて伝送鍵を暗号化し、鍵変換ユニットを形成すること、暗号化アプリケーションおよび鍵変形ユニットをＩＣカードに転送すること、ＩＣカードの秘密鍵を用いて鍵変換ユニットを復号化し、伝送鍵を提供すること、提供された伝送鍵を用いて暗号化アプリケーションを復号化すること、およびＩＣカード上の復号化アプリケーションを格納することを含む。
【０００９】
好適な実施形態において、ローディングシステムおよび方法により、アプリケーションプロバイダが、２つ以上の異なった鍵で転送されるアプリケーションの２つ以上の部分を暗号化すること、ＩＣカードの公開鍵で２つ以上の鍵を暗号化し、暗号化部分の位置を含む鍵変換ユニットを形成することが可能になる。暗号化アプリケーションおよび鍵変換ユニットの両方はＩＣカードに送信される。復号鍵は、ＩＣカードの公開鍵で暗号化されるので、ＩＣカードの秘密鍵のみが鍵変換ユニットを復号化することができる。伝送鍵および暗号化部分の位置は、復号化された鍵変換ユニットから回復され、アプリケーションは回復された伝送鍵を用いて復号化される。これにより、目的とされるＩＣカードは、復号化し、ＩＣカードに転送されたアプリケーションを使用することができる。
【００１０】
好適な実施形態において、アプリケーションのロード証明は、また、アプリケーションを受け取るＩＣカードに送信される。アプリケーションのロード証明は、証明機関（ＣＡ）の秘密鍵によって暗号化されたアプリケーションプロバイダの公開鍵、または、ＩＣカードシステムの全体のセキュリティを管理するエンティティを含む。次に、ＩＣカードは証明機関の公開鍵を用いて、ＣＡの公開鍵でアプリケーションのロード証明を検証することを試みることによって、証明が妥当であったかを確かめる。次に、ＩＣカードは回復されたアプリケーションプロバイダの公開鍵を使用し、アプリケーションプロバイダが実際に、アプリケーションプロバイダの対応する秘密鍵で生成された、送付されたアプリケーション署名を検証することによってアプリケーションの創設側（ｏｒｉｇｉｎａｔｏｒ）であったことを検証する。
（項目１）
ＩＣカード上へアプリケーションをロードする方法であって、
該ＩＣカードのための秘密鍵および公開鍵のペアを提供する工程と、
伝送鍵を用いて該アプリケーションの少なくとも一部分を暗号化する工程と、
該ＩＣカードの公開鍵を用いて該伝送鍵を暗号化し、鍵変形ユニットを形成する工程と、
該暗号化されたアプリケーションおよび該鍵変形ユニットを該ＩＣカードに転送する工程と、
該ＩＣカードの秘密鍵を用いて該鍵変形ユニットを復号化し、該伝送鍵を回復する工程と、
該回復された伝送鍵を用いて、該暗号化されたアプリケーションを復号化する工程と
を含む、方法。
（項目２）
前記ＩＣカード上に前記復号化されたアプリケーションを格納する工程を更に含む、項目１に記載の方法。
（項目３）
前記伝送鍵を用いる暗号化技術が、対称である、項目１または２に記載の方法。
（項目４）
前記対称技術はＤＥＳである、項目３に記載の方法。
（項目５）
前記ＩＣカードの公開鍵および秘密鍵は非対称技術を用いて提供される、項目１から４のいずれかに記載の方法。
（項目６）
前記非対称技術はＲＳＡである、項目５に記載の方法。
（項目７）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術をさらに示す、項目１から６のいずれかに記載の方法。
（項目８）
前記アプリケーションの前記少なくとも一部を除いた該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目１から７のいずれかに記載の方法。
（項目９）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目８に記載の方法。
（項目１０）
前記第２の部分は、第２の鍵を用いて暗号化され、前記鍵変形ユニットは、該第２の鍵を示す、項目８または９に記載の方法。
（項目１１）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目８から１０のいずれかに記載の方法。
（項目１２）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目１から１１のいずれかに記載の方法。
（項目１３）
前記鍵変形ユニットは、前記アプリケーションの暗号化された部分の数を示す、項目１から１２のいずれかに記載の方法。
（項目１４）
アプリケーションプロバイダのための公開鍵および秘密鍵のセットを提供する工程と、
証明機関のための公開鍵および秘密鍵のセットを提供する工程と、
該証明機関の秘密鍵を用いて、該アプリケーションプロバイダの公開鍵を暗号化し、アプリケーションのロード証明を生成する工程と、
該アプリケーションプロバイダの秘密鍵を用いて、該暗号化されたアプリケーションにさらに署名し、署名された暗号化されたアプリケーションを生成する工程と、
該署名されたアプリケーションおよび該アプリケーションのロード証明を該ＩＣカードに転送する工程と
をさらに含む、項目１から１３のいずれかに記載の方法。
（項目１５）
前記ＩＣカードが、前記証明機関の公開鍵でアプリケーションのロード証明を認証する工程をさらに含む、項目１４に記載の方法。
（項目１６）
復号化されたアプリケーションのロード証明から前記アプリケーションプロバイダの公開鍵を用いて、前記署名された暗号化されたアプリケーションを認証する工程をさらに含む、項目１５に記載の方法。
（項目１７）
認証されたアプリケーション署名は、送信された暗号化されたアプリケーションと比較され、それらが等価であるかを判定する、項目１６に記載の方法。
（項目１８）
少なくとも１つのＩＣカードと、
アプリケーションを該少なくとも１つのＩＣカードに提供するためのアプリケーションプロバイダと、
該少なくとも１つのＩＣカードおよび該アプリケーションプロバイダに連結された通信リンクと、
該ＩＣカードのために生成された、公開鍵および秘密鍵のセットと、
該アプリケーションプロバイダにより用いられるために生成されるトランスポート鍵と、
アプリケーションであって、該アプリケーションの少なくとも一部は該トランスポート鍵を用いて該アプリケーションプロバイダによって暗号化され；該トランスポート鍵が該ＩＣカードの公開鍵を用いて暗号化され、鍵変形ユニットを形成し；次に該暗号化されたアプリケーションおよび該鍵変形ユニットは、該通信リンクを介して該ＩＣカードに転送され；該転送された該鍵変形ユニットが該ＩＣカードの秘密鍵を用いて復号化され、該トランスポート鍵を回復し；該転送されたアプリケーションが該回復されたトランスポート鍵を用いて復号化され、該アプリケーションを回復する、アプリケーションと
を備える、ＩＣカードシステム。
（項目１９）
前記回復されたアプリケーションは、前記カード上に格納される、項目１８に記載のシステム。
（項目２０）
前記トランスポート鍵を用いた暗号化技術は、対称である、項目１８または１９に記載のシステム。
（項目２１）
前記対称技術は、ＤＥＳである、項目２０に記載のシステム。
（項目２２）
前記ＩＣカードの公開鍵および秘密鍵は、非対称技術を用いて提供される、項目１８から２１までのいずれかに記載のシステム。
（項目２３）
前記非対称技術は、ＲＳＡである、項目１１に記載のシステム。
（項目２４）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術をさらに示す、項目１８から２３のいずれかに記載のシステム。
（項目２５）
前記アプリケーションの前記少なくとも一部に独立な該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目１８から２４のいずれかに記載のシステム。
（項目２６）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目２５に記載のシステム。
（項目２７）
前記第２の部分は、第２の鍵を用いて暗号化され、前記鍵変形ユニットは、該第２の鍵を示す、項目２５または２６に記載のシステム。
（項目２８）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目２５から２７のいずれかに記載のシステム。
（項目２９）
前記鍵変形ユニットは、前記アプリケーションの少なくとも一部の位置を示す、項目１８から２８のいずれかに記載のシステム。
（項目３０）
前記鍵変形ユニットは、前記アプリケーションの暗号化された部分の数を示す、項目１８から２９のいずれかに記載のシステム。
（項目３１）
証明機関を更に含み、
公開鍵および秘密鍵のセットはアプリケーションプロバイダのために提供され；公開鍵および秘密鍵のセットは該証明機関のために提供され；該証明機関の秘密鍵は、前記アプリケーションプロバイダの公開鍵に署名するのに使用され、アプリケーションのロード証明を生成し；該アプリケーションプロバイダの秘密鍵は、前記暗号化されたアプリケーションにさらに署名するのに使用され、署名された暗号化されたアプリケーションを生成し、該署名された暗号化されたアプリケーションおよび該アプリケーションのロードの証明は、該ＩＣカードに転送される、項目１８から３０のいずれかに記載のシステム。
（項目３２）
前記ＩＣカードが、前記証明機関の公開鍵で前記アプリケーションのロード証明を認証する、項目３１に記載のシステム。
（項目３３）
前記ＩＣカードは、前記認証されたアプリケーションのロード証明から前記アプリケーションプロバイダの公開鍵を使用して前記署名された暗号化されたアプリケーションを認証する、項目３２に記載のシステム。
（項目３４）
認証されたアプリケーション署名を、前記暗号化されたアプリケーションと比較し、それらが等価であるかどうかを判定する、項目３３に記載のシステム。
（項目３５）
第１のマイクロプロセッサベースの装置から、第２のマイクロプロセッサベースの装置にデータを転送する方法であって、
伝送鍵を用いて該データの少なくとも一部を該第１の装置で暗号化する工程と、
該第１の装置において第２の鍵で該伝送鍵を暗号化し、鍵変形ユニットを形成する工程と、
該暗号化されたデータおよび該鍵変形ユニットを該第２の装置に転送する工程と、
該第２の装置で該鍵変形ユニットを復号化し、該伝送鍵を回復する工程と、
該回復された伝送鍵を用いて該暗号化されたデータを復号化する工程と
を含む、方法
（項目３６）
前記第２の装置で前記復号化されたデータを格納する工程を更に含む、項目３５に記載の方法。
（項目３７）
前記第２の鍵は、非対称暗号化において使用される公開鍵および秘密鍵のセットに由来する、項目３５または３６に記載の方法。
（項目３８）
前記鍵変形ユニットは、前記アプリケーションの少なくとも一部を暗号化するために使用される技術を更に示す、項目３５から３７のいずれかに記載の方法。
（項目３９）
前記アプリケーションの前記少なくとも一部に独立な該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目３５から３８のいずれかに記載の方法。
（項目４０）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目３９に記載の方法。
（項目４１）
前記第２の部分は第２の鍵を用いて暗号化され、前記第２の鍵変形ユニットは該第２の鍵を示す、項目３９または４０に記載の方法。
（項目４２）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目３９に記載の方法。
（項目４３）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目３５から４２のいずれかに記載の方法。
（項目４４）
アプリケーションプロバイダのための公開鍵および秘密鍵のセットを提供する工程と、
証明機関のための公開鍵および秘密鍵のセットを提供する工程と、
該証明機関を用いて該アプリケーションプロバイダの公開鍵に署名し、アプリケーションのロード証明を生成する工程と、
該アプリケーションプロバイダの秘密鍵を用いて該暗号化されたアプリケーションをさらに暗号化し、署名された暗号化されたアプリケーションを生成する工程と、
該署名されたアプリケーションおよび該アプリケーションのロード証明を該ＩＣカードに転送する工程と
をさらに含む、項目３５から４３のいずれかに記載の方法。
（項目４５）
データ転送を処理するための方法であって、
アプリケーションを含む該データ転送を受け取る工程であって、該アプリケーションは、第１の鍵で暗号化された少なくとも一部、および、第２の鍵で暗号化された鍵変形ユニットを含み、該鍵変形ユニットは該第１の鍵を含む、工程と、
該鍵変形ユニットを復号化し、該第１の鍵を回復する工程と、
該第１の鍵を用いて該暗号化されたアプリケーションを復号化する工程と、
該復号化されたアプリケーションを格納する工程と
を含む、方法。
（項目４６）
前記第２の鍵は、非対称暗号化において使用される公開鍵および秘密鍵のセットに由来する、項目４５に記載の方法。
（項目４７）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術を更に示す、項目４５または４６に記載の方法。
（項目４８）
前記アプリケーションの前記少なくとも一部に独立な該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目４５から４７のいずれかに記載の方法。
（項目４９）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目４８に記載の方法。
（項目５０）
前記第２の部分は第２の鍵を用いて暗号化され、前記鍵変形ユニットは該第２の鍵を示す、項目４８または４９に記載の方法。
（項目５１）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目４８に記載の方法。
（項目５２）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目４５から５１のいずれかに記載の方法。
（項目５３）
アプリケーションプロバイダのための公開鍵および秘密鍵のセットを提供する工程と、
証明機関のための公開鍵および秘密鍵のセットを提供する工程と、
該証明機関を用いて該アプリケーションプロバイダの公開鍵に署名し、アプリケーションのロード証明を生成する工程と、
該アプリケーションプロバイダの秘密鍵を用いて該暗号化されたアプリケーションをさらに暗号化し、署名された暗号化アプリケーションを生成する工程と、
該署名されたアプリケーションおよび該アプリケーションのロード証明を該ＩＣカードに転送する工程と
をさらに含む、項目４５から５２のいずれかに記載の方法。
（項目５４）
前記ＩＣカードが、前記証明機関の公開鍵で前記アプリケーションのロード証明を認証する工程をさらに含む、項目５３に記載の方法。
（項目５５）
前記認証されたアプリケーションのロード証明から前記アプリケーションプロバイダの公開鍵を用いて、署名された暗号化されたアプリケーションを認証する工程をさらに含む、項目５４に記載の方法。
（項目５６）
認証されたアプリケーション署名を前記暗号化されたアプリケーションと比較し、それらが等価であるか判定する、項目５５に記載の方法。
（項目５７）
データ転送を処理するための装置であって、
アプリケーションを含む該データ転送を受け取る手段であって、該アプリケーションは、第１の鍵で暗号化された少なくとも一部と、第２の鍵で暗号化された鍵変形ユニットを含み、該鍵変形ユニットは該第１の鍵を含む、手段と、
該鍵変形ユニットを復号化し、該第１の鍵を回復する手段と、
該第１の鍵を用いて該暗号化されたアプリケーションを復号化する手段と、
該復号化されたアプリケーションを格納する手段と
を含む、装置。
（項目５８）
前記第２の鍵は、非対称暗号において使用される公開鍵および秘密鍵のセットに由来する、項目５７に記載の装置。
（項目５９）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術をさらに示す、項目５７または５８に記載の装置。
（項目６０）
前記アプリケーションの前記少なくとも一部を除いた該アプリケーションの第２の部分を暗号化するための手段をさらに含む、項目５７から５９に記載の装置。
（項目６１）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目６０に記載の装置。
（項目６２）
前記第２の部分は、第２の鍵を用いて暗号化され、前記鍵変形ユニットは、該第２の鍵を示す、項目６０または６１に記載の装置。
（項目６３）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目６０から６２のいずれかに記載の装置。
（項目６４）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目５７から６３のいずれかに記載の装置。
（項目６５）
前記証明機関の公開鍵でアプリケーションのロード証明を認証するための手段をさらに含む、項目６０から６４のいずれかに記載の装置。
（項目６６）
前記認証されたアプリケーションのロード証明に位置するアプリケーションプロバイダの公開鍵を用いて前記署名された暗号化されたアプリケーションを認証する手段をさらに含む、項目６５に記載の装置。
（項目６７）
認証されたアプリケーション署名は、前記暗号化されたアプリケーションと比較され、それらが等価であるかを判定する、項目６６に記載の装置。
【図面の簡単な説明】
【００１１】
本発明の例示的な実施形態を示す添付の図面に関連して以下の詳細な説明を読むことにより、本発明のさらなる目的、特徴および利点が明らかになるであろう。
【図１】図１は、アプリケーション提供者からＩＣカードにアプリケーションをロードするアプリケーションロードシステムのブロック図である。
【図２】図２は、アプリケーションロードユニットの内容を図示したものである。
【図３】図３は、アプリケーションユニットを図示したものである。
【図４】図４は、あるＩＣカードについての個々の鍵組を提供する工程のフローチャートである。
【図５】図５は、鍵変換ユニットを図示したものである。
【図６】図６は、鍵変換ユニットの平文を図示したものである。
【図７】図７は、アプリケーションロード証明書（Ａｐｐｌｉｃａｔｉｏｎ Ｌｏａｄ Ｃｅｒｔｉｆｉｃａｔｅ）を図示したものである。
【図８】図８は、アプリケーションユニットが復号化される様子を図示したものである。
【図９】図９は、アプリケーションロードユニットを処理する際に行われる工程を示すフローチャートである。
【図１０】図１０は、ＫＴＵを処理する際に行われる工程を示すフローチャートである。
【図１１】図１１は、アプリケーションロードユニットを受け取り、これを処理することができるＩＣカードの構成要素を示すブロック図である。
【発明を実施するための形態】
【００１２】
そうでないことが記載されている場合を除き、全図面を通して、同じ参照番号および文字は、例示された各実施形態において同じ特徴部、部材、構成要素および部分を示すために用いられている。さらに、以下で図面を参照しながら本発明を説明するが、これは例示的な実施形態に関する説明である。添付のクレームによって規定される本発明の真の範囲および趣旨から逸脱することなく、記載された実施形態に変更および改変を加えることが可能であることが意図されている。
【００１３】
（発明の詳細な説明）
そのＩＣカードの寿命の任意の時点で、複数のアプリケーションオペレーティングシステムを含むＩＣカード上にアプリケーションをロードできる能力を持つことは有益である。この柔軟性によって、カードのユーザが、定期的に新しいアプリケーションをＩＣカードに追加すること、ならびに、より新しいバージョンのアプリケーションがリリースされたときに、新しいバージョンのアプリケーションを用いて古いアプリケーションを更新することが可能になる。例えば、カードユーザは、初めに、財布または電子キャッシュアプリケーション（例えば、ＭＯＮＤＥＸＴＭ）が保存されたＩＣカードを持ち得る。ユーザがこのカードを持ってからしばらくした後、このユーザは、クレジット／デビットアプリケーションのような追加アプリケーションをこのカード上にロードし得る。カード上にクレジット／デビットアプリケーションをロードしてからしばらくした後、そのクレジット／デビットアプリケーションの新しいバージョンが利用可能になり得る。その時、このカードユーザが、そのＩＣカード上の古いアプリケーションを消去して、さらなる機能を有し得るクレジット／デビットアプリケーションの新しいバージョンに置き換えることは可能であるべきである。
【００１４】
ＩＣカードの寿命サイクルにおける複数の異なる時点でアプリケーションのロードを行うという柔軟性は、カード上にアプリケーションをロードするプロセスに関してセキュリティ上の問題を生じる。マルチアプリケーションオペレーティングシステム環境においては、アプリケーションのロードを、銀行のＡＴＭマシンのような端末と、電話線、ケーブル線、インターネット、衛星または他の通信手段等の遠隔通信リンク上との両方で行えることが有益である。ＩＣカード上にアプリケーションをロードする際、アプリケーション提供者およびカード発行者（同じエンティティであり得る）は、ロードすべきアプリケーションに関するセキュリティを提供する必要がある。第１に、アプリケーション提供者は、そのアプリケーションを受け取ることが意図された正しいカードユーザにのみアプリケーションが送られることを確実にしなければならない。この問題に対する１つの解決方法が、１９９８年２月１９日に出願され、Ｍｏｎｄｅｘ Ｉｎｔｅｒｎａｔｉｏｎａｌに譲渡された、Ｅｖｅｒｅｔｔｅらによる”Ｍｕｌｔｉ−Ａｐｐｌｉｃａｔｉｏｎ ＩＣ Ｃａｒｄ Ｓｙｓｔｅｍ Ｈａｖｉｎｇ Ｓｅｌｅｃｔｉｖｅ Ｌｏａｄｉｎｇ ａｎｄ Ｄｅｌｅｔｉｎｇ Ｃａｐａｃｉｔｙ”という名称の関連ＰＣＴ出願において試みられている。この文献を、本明細書に添付したアネックスＢへの参考として本明細書中で援用する。アプリケーションを離れたソースから、またはローカルターミナルから、ＩＣカード上へとロードする場合に、２つのさらなるセキュリティに関する問題に取り組む必要がある。まず、ウイルスを含み得るか、または、単にＩＣカード内の限られた記憶メモリを占拠し得るアプリケーションをＩＣカード上にロードすることがないように、アプリケーションのソースは適切な発信元（ｏｒｉｇｉｎａｔｏｒ）として認証される必要がある。第２に、アプリケーションおよび関連データは、個人的または企業秘密情報を含み得る。このような個人的または企業秘密情報は暗号化することにより、暗号化されたアプリケーションコードおよびデータの内容を他の人々に見られないようにする必要がある。アプリケーションコードおよびデータの一部が秘密であり、他の部分は秘密ではない場合もある。本願では、カードにロードするアプリケーションおよび関連データの一部または全ての内容の認証および保護という問題に対処する。
【００１５】
本明細書中、複数の暗号化／復号化技術が記載される。対称暗号化および非対称暗号化という２つの基本的な種類の暗号化がある。対称暗号化では、式および鍵を用いてデータを変換することにより、データを暗号化する数式の一部として秘密鍵を用いる。データを暗号化した後、これと同じ秘密鍵を関連する復号化アルゴリズムとともに用いて、別のパーティが、この暗号化されたデータを復号化することができる。同じ鍵は暗号化および復号化のために用いられ、技術は対称的である。対称アルゴリズムの従来例の１つは、ＤＥＳである。
【００１６】
非対称暗号化技術では、１対をなす異なる２つの鍵を用いて情報の暗号化および復号化を行う。これらの２つの鍵は、通常、プライベートまたは秘密鍵および公開鍵と呼ばれる。この１対の鍵の一方を用いてデータを暗号化した場合、そのデータの復号化には他方の鍵が用いられる。データの送り主が、そのデータをその送り主の秘密鍵を用いて署名すると、公開鍵を持っていれば誰でもそのメッセージを検証できる。典型的に、公開鍵は公に知られているので、秘密鍵を用いて署名されたデータの内容を保護することはできないが、特定の秘密鍵によってそのデータが署名されているかどうかを判定することによってそのデータの起源（ｏｒｉｇｉｎａｔｉｏｎ）は検証できる。この認証プロセスは、デジタル署名と呼ばれる。人物Ａが人物Ｂに送ろうとしているメッセージを人物Ａが認証したい場合、人物Ａは、人物Ａの秘密鍵を用いてその文書を解読する。公開鍵が提供された後に文書が読み出されると、人物Ｂは、人物Ａの公開鍵を用いてそのメッセージを検証する。その公開鍵を用いてそのメッセージが検証されると、その文書が人物Ａの秘密鍵を用いて署名されたことを人物Ｂが知ることになる。このようにして、メッセージの起源（ｏｒｉｇｉｎ）が認証される。
【００１７】
非対称鍵組を用いてメッセージの内容を保護することも可能である。人物Ａが、人物Ｂに、他の誰も読むことのできない暗号化されたメッセージを送りたい場合、人物Ａは、そのデータまたはメッセージを人物Ｂの公開鍵を用いて暗号化し、それを人物Ｂに送る。そうすれば、人物Ｂの秘密鍵の所有者しかそのデータを復号化できなくなる。複数の鍵の組み合わせを用いれば、ある人物がそのメッセージの認証および暗号化の両方を行うことが可能である。非対称の鍵対には、カードセキュリティに関していくつかの強力な用途があり、対称暗号化よりもより頑強である。しかし、非対称暗号化は、対称暗号化と比べて比較的プロセッサコストがより高くつく（プロセッサコストは演算時間と関連している）。非対称暗号化方法の一例は、ＲＳＡ（Ｒ）である。
【００１８】
暗号化方法をより強力にするハイブリッド対称暗号化方法の１つは、２つの対称鍵を用いてデータを暗号化することである。この技術はトリプルＤＥＳと呼ばれ、対称鍵１を用いてデータを符号化し、対称鍵２を用いてそのデータを復号化し（これにより、そのデータをさらに符号化することになる）、そして、再び鍵１を用いてそのデータをさらに符号化するものである。データがその目的地に到着した後、鍵１を用いてそのデータを復号化し、鍵２を用いてそのデータを符号化し、そして、鍵１を用いてそのデータを復号化する。これらの余分な符号化および復号化ステップによって、この技術はより強力になるとともに、両方の鍵がそろっていない状態で適切に復号化することがより困難になる。
【００１９】
図１は、安全な遠隔アプリケーションローディングプロセスに使用されるエンティティのブロック図を示す。アプリケーションプロバイダ１０１は、カードの発行者、銀行、またはアプリケーションローディングサービスを提供する他のエンティティであり得る。アプリケーションプロバイダ１０１は、ＩＣカード１０３上へのアプリケーションローディングプロセスを起動する。アプリケーションプロバイダ１０１は、データコンデット１０７に接続され、データコンデット１０７は、インターフェイスデバイス１０５（例えば、ＩＣカードと通信する端末）に接続されている。データコンデット１０７は、電話回線、イントラネット、インターネット、衛星リンク、またはその他の任意のタイプの通信リンクであり得る。アプリケーションプロバイダ１０１は、ＩＣカード１０３から遠隔に配置され、ＩＣカードへアプリケーションを送信してロードすることを所望する。しかしながら、データリンクがオープンリンクであり、送信されるアプリケーションを妨害したり置換する第三者に晒されているために、アプリケーション自体を認証する安全手段、アプリケーションプロバイダ、およびＩＣカードが、システムの整合性を確実にするために使用されなければならない。送信されているいくつかのデータが識別されたシステム一部であることの認証を補助するためには、証明機構ＣＡ１０９も使用され得る。
【００２０】
図１では、アプリケーションプロバイダは、インターフェースデバイス１０５へ、そして最終的にはＩＣカード１０３へ、アプリケーションロードユニット１１１を送信する。ＡＬＵは、アプリケーション自体および認証に必要なセキュリティデータを含み、アプリケーションコードおよび関連データを保護する。ＡＬＵは、図２において詳細を論じたが、本明細書の他の図とも関連がある。ＡＬＵ１１１は、好適には、証明機構（ＣＡ）１０９からアプリケーションプロバイダ１０１に送信されるアプリケーションロード証明（ＡＬＣ）１１３データをも含む。証明機構は、ＩＣカード上にロードされるべき各アプリケーションに対するアプリケーションロード証明を供給することによって、システムの全体的なセキュリティを管理する。アプリケーションプロバイダ１０１およびＩＣカード１０３の両方は、それらに提供される個々の公開／秘密鍵セットを有する。認証とセキュリティのプロセスを以下に説明する。
【００２１】
図２は、アプリケーションロードプロセス中にアプリケーションローダからＩＣカードに送信されるアプリケーションロードユニットの構成要素を説明する図を示す。アプリケーションロードユニット（ＡＬＵ）２０１は、アプリケーションユニット（ＡＵ）２０３、アプリケーションユニット署名（ＡＵｓ）２０５、
鍵変換ユニット（ＫＴＵ）２０７、およびアプリケーションロード証明（ＡＬＣ）２０９を含む。ＡＬＣ２０１は、データ送信中に使用される従来フォーマットで初期化される。ＡＵ２０３は、ＩＣカード上に記憶されるべきアプリケーションコードおよびデータを含み、それらの一部またはすべてが、秘密部分を、もしくはコードおよび／またはデータ部分を保護するために暗号化される。ＡＵ２０３を、図３を参照してさらに詳細に説明する。
【００２２】
ＡＵｓ２０５は、アプリケーションプロバイダの秘密鍵でデジタル的に署名されたアプリケーションコードおよびデータＡＵ２０３である。アプリケーションプロバイダの公開鍵は、ＡＬＣ２０９の一部として送信され、アプリケーションの作成者としてアプリケーションプロバイダを認証するのに使用される。ＡＬＣ２０９は、カード識別情報およびアプリケーションプロバイダの公開鍵から構成され、証明機構の秘密鍵によって署名される。以下、これらの要素をすべて、より詳細に説明する。
【００２３】
ＫＴＵ２０７は、指定された部分をＩＣカードが復号化するのを可能にする、ＡＵ２０３（アプリケーションのコードおよびデータ）の暗号化に関する情報を含み、これにより、アプリケーションおよびデータはＩＣカードによってアクセスされ得るが、アプリケーションプロバイダとＩＣカードとの間での送信中にデータを保護する。ＫＴＵ２０７は、アプリケーションが意図されるＩＣカードの公開鍵で署名されており、これにより、意図されたＩＣカードのみが、ＫＴＵ情報を用いたアプリケーションコードおよびデータを復号化できることを確実にする。この要素は図５を参照して説明する。
【００２４】
図３は、アプリケーションロードユニットの一部であるアプリケーションユニット２０３の図を示す。ＡＵ２０３は、カードユーザのＩＣカード上にロードされるべきプログラムコードおよび関連データ両方を含む。プログラムコードは、ＩＣカードのマイクロプロセッサによって実行される複数のプログラム命令を含む。プログラム命令は、ＩＣカード上に記憶されているオペレーションシステムが解釈できる任意のプログラミング言語で記述され得る。
【００２５】
例えばＭＵＬＴＯＳシステムでは、プログラムはＭＥＬＴＭ（ＭＵＬＴＯＳ実行可能言語）で記述され得る。たいていのアプリケーションは、カード上にロードされなければならない関連データを有する。例えば、人名またはアカウント番号などカードユーザを識別するデータは、クレジット／デビットアプリケーションを伴う安全な方式においてロードされ得る。アプリケーションプロバイダは、データによって表される電子キャッシュを、電子パースアプリケーションをインストールするときに助成として提供し得る。このデータのいくつかまたは全部が、第三者から秘密に保たれることが所望される。ひいては、アプリケーションコード自体が独占物であると見なされ得、その一部が他者からは秘密であることが所望され得る。鍵変換ユニット（ＫＴＵ）の使用は、アプリケーションプロバイダーがアプリケーションの選択された部分を秘密として暗号化し、第三者からそれを保護することを可能にする。
【００２６】
アプリケーションユニット部分３０５は、アプリケーションプロバイダからＩＣカードに送信されるべきプログラムコードを指示する。アプリケーションユニット部分３０７は、ＩＣカード上にロードされるべきアプリケーションの一部として送信されるべき関連データを指示する。この例では、アプリケーションユニットの３つの個別領域が、単一のＤＥＳまたは３重のＤＥＳのいずれかを用いて暗号化されることが示されている。暗号化される部分および暗号化のタイプに関する任意の数の変更が、本願記載の技術を用いて実施され得る。
【００２７】
この例では、暗号化されたロケーション３０９は、３重ＤＥＳ技術を用いて暗号化されたアプリケーションユニット２０３の第１の部分を示す。上述の暗号化プロセスは、対称的鍵および従来公知のＤＥＳアルゴリズムを用いてデータを変換することを含む。データはその後、従来公知のＤＥＳベースアルゴリズムにデータを代入することにより復元され得る。暗号化ロケーション３１１は、３重ＤＥＳを用いて暗号化されたアプリケーションユニット２０３の第２の部分を示す。暗号化ロケーション３１３は、単一のＤＥＳを用いて暗号化された第３の部分を示す。単一ＤＥＳは、より少ない計算しか復号化に要さず、後述するＫＴＵの一部として、より少ない領域しか占有しない。アプリケーションローダからＩＣカードへ送信中に、第三者によってアプリケーションユニットが妨害された場合、第三者が正しい鍵を有するまで、暗号化された部分は、読み出され得ない。従って、情報はＫＴＵ内で保護される。
【００２８】
ＫＴＵは、アプリケーションユニットのどの部分が暗号化されるか、どの暗号化アルゴリズムが使用されるか、およびテキストの復号化に使用される単数または複数の鍵を記述することによって、アプリケーションおよび関連データの意図するＩＣカードが、アプリケーションユニットの暗号化部分を復号化することを可能にする。この情報は、アプリケーションプロバイダと意図されるＩＣカードとの間で高度に秘密であり、従って意図されるカードに極めて特殊な方式で保護される。送信されるＡＬＵ全体の一部であるＫＴＵを暗号化するために、特定の意図されるＩＣカードのための個別鍵セットが使用される。鍵セットおよびその作成を以下に説明する。
【００２９】
ＣＡにおいて実行される安全処理の一つは、カード上に記憶された各ＩＣカードのための個別化された鍵セットを作成することである。鍵は、オフカード検証（即ちカードが正真のカードであることを検証する）および安全なデータ配送に使用される。鍵作成プロセスを図４に概略的に示す。鍵セットは、３つの異なる鍵データアイテムから構成される。即ち、カードのみが知っているカード秘密鍵、カード上に記憶されているカードの公開鍵、およびＣＡの秘密鍵の一つによって署名されたカード公開鍵であるカード公開鍵証明である。以下、鍵セットの個々の鍵を、より詳細に説明する。
【００３０】
工程４０１は、カードのメモリ内の個別ＩＣカードに対して、カード特定的に配送された秘密鍵を記憶する。この秘密鍵は、ＣＡにより作成され、カード許可デバイスを介してカード上にロードされる。ひとたびカード上に記憶されれば、ＣＡはそれ自身のメモリから秘密鍵に関するあらゆるデータを消去する。従って、カード自体のみがその秘密鍵を知っている。カード内の秘密鍵情報を含んでいるデータ要素は、「ｍｋｄ＿ｓｋ」と呼ばれ、ＭＵＬＴＯＳ鍵データ秘密鍵を意味する。
【００３１】
工程４０３は、カードのメモリ内の個々のＩＣカードのためのカード特定的に配送された公開鍵を記憶する。この公開鍵は、好適には、工程４０１において秘密鍵を作成するのに使用された非対称暗号化技術からＣＡによって作成される。カードの公開鍵情報を含むデータ要素は「ｍｋｄ＿ｐｋ」と呼ばれ、ＭＵＬＴＯＳ鍵データ公開鍵を意味する。
【００３２】
工程４０５は、カードメモリ内の個々のＩＣカードのためのカード特定的に配送された公開鍵証明を記憶する。カードの公開鍵証明情報を含むデータ要素は、「ｍｋｄ＿ｐｋ＿ｃ」と呼ばれ、ＭＵＬＴＯＳ鍵データ公開鍵証明を意味する。この公開鍵証明は、好適には、以下に示すようにＣＡの秘密鍵で配送公開鍵「ｍｋｄ＿ｐｋ」に暗号化することにより作成される。
【００３３】
ｍｋｄ＿ｐｋ＿ｃ＝［ｍｋｄ＿ｐｋ］ＣＡ＿ｓｋ
これは、個々のカードの公開鍵証明が、ＣＡの秘密鍵を個々のカードの公開鍵に適用して作成されることを意味する。このプロセスは、ＣＡにおいて実施される。公開鍵証明はＣＡによって保存され、これにより、必要に応じて公開鍵を再作成することができる。
【００３４】
端末がＩＣカードから公開鍵証明を読み出し得、ＣＡが署名をし、それにより個々のＩＣカードを認可したことを検証できる。これは、ｍｋｄ＿ｐｋに署名するのに使用されたＣＡ鍵セットの公開要素で公開鍵証明を検証することによって達成される。暗号化公開鍵は、鍵認証がＣＡによって認証（署名）されたかを立証するために公開鍵と比較され得る。
【００３５】
図５は、ＫＴＵ２０７の内容を図示したものであり、ヘッダ部分５０１およびＫＴＵ暗号文部分５０３を含んでいる。図５に示すように、ヘッダ情報５０１は、例えば、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄ＿ｎｏ（アプリケーション識別番号）、ｍｃｄ＿ｎｏ（ＩＣカード番号）および／またはｍｓｍ＿ｃｏｎｔｒｏｌ＿ｄａｔａ＿ｄａｔｅ（ＩＣカードが発行された日付）などの識別子または許可情報５０５を含む。追加の識別子も含まれ得る。これらの識別子により、システムは、ＡＬＵを受信するＩＣカードが意図されたＩＣカードであることを検証できる。許可データは、上記参照した関連出願に詳細に記載されている。
【００３６】
ＫＴＵ暗号文５０３は、ボックス５０７に示す意図されたＩＣカードの公開鍵ｍｋｄ＿ｐｋで暗号化されたＫＴＵ平文（暗号化されていない）に対応する。ＫＴＵ平文は、図６においてさらに説明する。公開鍵ｍｋｄ＿ｐｋは、アプリケーションプロバイダーによって、意図されたＩＣカードから取得される。ＩＣカードの公開鍵は、誰でも自由に利用でき、カードまたはＣＡから直接入手できる。ＫＴＵ平文をＩＣカードの公開鍵で署名化することによって、意図されたＩＣカードのみが公開／秘密鍵対の秘密鍵を用いてＫＴＵ暗号文を復号化することができる。これは、意図されたＩＣカードのみが、ＫＴＵ平文の内容を決定し、ロードされるアプリケーションの暗号化部分を識別し、鍵を用いてアプリケーション全体および関連データを復号化し復元できることを意味する。その他のエンティティは、ＩＣカードの秘密鍵を有さないので、送信されているプログラムコードおよびデータのセキュリティと整合性とが確保される。
【００３７】
図６は、ＫＴＵ平文６０１を示す図である。ＫＴＵ平文６０１は、好適には、識別子フィールド６０３、ｎｏ＿ａｒｅａ＿ｄｉｓｃｒｉｐｔｏｒｓフィールド６０５、ａｌｇ＿ｉｄフィールド６０７、ａｒｅａ＿ｓｔａｒｔフィールド６０９、ａｒｅａ＿ｌｅｎｇｔｈ６１１、ｋｅｙ＿ｌｅｎｇｔｈフィールド６１３、ｋｅｙ＿ｄａｔａフィールド６１５、ならびに、アプリケーションユニット内に存在する暗号化領域の数によって追加の領域および鍵フィールドを含む。識別子６０３は、ＫＴＵが適用されるアプリケーションユニットの識別情報を含む。
【００３８】
Ｎｏ＿ａｒｅａ＿ｄｅｓｃｒｉｐｔｏｒｓ６０５は、いくつの数のＡＵの異なる部分が暗号化されたのかを示す。図３の例では、領域記述子の数は３である。フィールド６０７は、暗号化された第１の領域のためのアルゴリズム識別子を含む。アルゴリズムは、例えば、ＤＥＳまたは三重ＤＥＳであり得る。フィールド６０９は、第１の暗号化領域の開始を指示する。この指示は、ＡＵの開始からのオフセットであり得る。例えば、オフセットは、１００により得る。これは、第１の領域が、アプリケーションユニットの１００番目のバイトから開始することを意味する。フィールド６１１は、第１の暗号化部分の領域長を指示する。このフィールドにより、ＩＣカード上のマイクロプロセッサは、どの程度の大きさの領域が暗号化され、領域の開始といつ結合されたのかを知ることができ、ＩＣカードマイクロプロセッサは、アプリケーションユニットの正しい部分を暗号化できる。フィールド６１３は、アプリケーションユニットの特定の暗号化部分に対する鍵長を指示する。鍵の長さは、異なる暗号化技術によって異なる。鍵長フィールドによって、ＩＣカードは鍵データの長さを知ることができる。フィールド６１５は、特定の暗号化部分に対する鍵データを指示する。鍵データは、暗号化部分のアルゴリズム同一性およびロケーションとともに使用され、暗号化部分をデコードする。一つ以上の暗号化部分が指示されている場合、アルゴリズムを参照する追加のデータ、開始ロケーション、長さ、鍵長および鍵データが、ＫＴＵ平文内に存在する。複数のフィールドを記載したが、本発明にすべてのフィールドが必要なのではない。しかしながら、最も重要なフィールドは、鍵データ自体である。
【００３９】
図７は、アプリケーションロード証明（ＡＬＣ）２０９を示す図である。ＡＬＣ２０９は、ヘッダ７０１およびアプリケーションプロバイダ公開鍵７０３を含む。次に、ヘッダ７０１およびアプリケーションプロバイダ公開鍵７０３は、ＣＡの秘密鍵で署名（暗号化）される。従って、ＣＡのみがＣＡプライベート鍵を知っているので、ＡＬＣ２０９は、ロードされる各アプリケーションに対してＣＡによってアプリケーションプロバイダに供給されなければならない。ヘッダ７０１は、アプリケーションが意図されるアプリケーションプロバイダおよびＩＣカードに関する情報を含む。ＡＬＣ２０９は、識別情報を使用し得るアプリケーションプロバイダによって正しいＡＬＵ内に配置される。アプリケーションプロバイダ公開鍵７０３は、識別データとともにＣＡに供給される。次に、ＣＡは、認証性を検証したあとで、この情報に署名し、アプリケーションプロバイダに署名されたＡＬＣを返送する。ＩＣカードは、ＡＬＵ２０１の一部としてＡＬＣ２０９を受け取るとき、ＣＡの公開鍵でＡＬＣ２０９を検証する。これにより、ＣＡがアプリケーションロード証明に署名し、それが本物であることを確証する。情報を複号化した後で、ヘッダ識別情報７０１がチェックされ、アプリケーションプロバイダ公開鍵が復元される。この公開鍵は、 ＩＣカード上にロードされるべきアプリケーションおよびコードが適切なアプリケーションプロバイダによって作成されたことを検証するのに使用される。
【００４０】
図８は、ＡＵ２０３がアプリケーションプロバイダによって署名されたことを検証するために、アプリケーションプロバイダの公開鍵を使用してＡＵ署名２０５を複号化することを示した図である。ＡＵ署名２０５は、アプリケーションプロバイダ公開鍵８０１で検証される。受け取られたＡＵ８０３は、ＡＵ２０３と比較される。データブロックがマッチした場合、ＩＣカードは、アプリケーションプロバイダがアプリケーションユニットに署名（暗号化）し、アプリケーションが本物であることを検証した。この認証は、アプリケーションプロバイダのみが秘密鍵を有するので、有効である。アプリケーションプロバイダ公開鍵がＣＡによって署名されたアプリケーションロード証明２０９の一部として供給されているので、ＩＣカードは、この情報を効率よく処理し得る。従って、外部ロケーションから公開鍵を復元して、アプリケーションを認証する必要がない。
【００４１】
図９は、アプリケーションロードユニットがＩＣカードによって受け取られたときに、これを処理するための工程のフローチャートを示す。ＡＬＵを受け取る前に、所望により、ＩＣカードの同一性に関して同一性チェックが実行され得る。
ＡＬＵプロセス技術は、ロードされるアプリケーションが、（１）正しいアプリケーションプロバイダからであり、（２）意図されるカードにロードされ、（３）ＣＡによって証明されていることを検証することを含む、数々のさらなる検証を提供する。また、ＡＬＵプロセス技術は、プログラムコードおよび関連データの部分を、ＩＣカードが安全な方式で復号化できるようにする配送復号化鍵の配送を可能にする。工程９０１では、ＩＣカードがアプリケーションプロバイダからＡＬＵを受け取る。ＡＬＵは、端末接続、遠隔接続（ｃｏｎｔａｃｔｌｅｓｓ ｃｏｎｎｅｃｔｉｏｎ）、電話、コンピュータ、イントラネット、インターネット、または他の任意の通信手段を介して送信され得る。ＡＬＵは、ＩＣカードのＩ／Ｏバッファに、ＡＵ２０３、ＡＵ署名２０５、ＫＴＵ２０７、およびＡＬＣ２０９の開始アドレスを指示するヘッダ情報とともに配置される。あるいは、ＩＣカードは、これら４つのユニットの相対アドレスロケーションを決定し得る。
【００４２】
工程９０３は、ＣＡ公開鍵を備えたＡＬＣ２０９を複号化する。各ＩＣカードは、好適には、そのメモリ内にＣＡ公開鍵の複製を記憶する。これは、ＣＡ公開鍵が多くのトランスアクションに使用されるからである。あるいは、ＩＣカードは、公知の記憶ロケーションから公開鍵を取得し得る。 ＣＡ公開鍵がＡＬＣ２０９を適切に検証した場合、ＩＣカードは、ＣＡが秘密鍵によってＡＬＣ２０９に署名し、従って、アプリケーションロード証明は適切であることを検証する。ＩＣカードが、ＡＬＣを適切に検証しなかった場合、 ＡＬＣはＣＡによって署名されておらず、証明は適切でない。そこで、アプリケーションローディングプロセスは終了する。
【００４３】
次に、工程９０５が、アプリケーションロード証明において送られた識別情報に対してＩＣカードの同一性をチェックし、カードがアプリケーションを受け取ることを意図されたものであることを確実にする。この許可チェックは、上記に確認した関連特許出願に記載されている。識別データの一致が存在しない場合、アプリケーションローディングプロセスは終了する。識別データが一致する場合、プロセスは継続する。
【００４４】
工程９０７は、検証されたＡＬＣから復元されたアプリケーションプロバイダの公開鍵を用い、ＡＵ署名２０５を検証する。ＡＬＵがアプリケーションプロバイダにより作成されているとき、アプリケーションユニット２０３は、アプリケーションプロバイダの秘密鍵で署名される。次に、アプリケーションプロバイダは、ＡＬＣを介してＩＣカードに公開鍵を供給する。ひいては、ＩＣカードは、ＡＵ署名２０５を検証する。ＡＬＵが検証された場合、ＡＬＵはアプリケーションプロバイダによって作成されたとして検証される。アプリケーションプロバイダの公開鍵は、ＣＡによって署名されたＡＬＣの一部であるので、ＣＡは、適切な公開鍵がＩＣカードに供給されたことを確証する。アプリケーションプロバイダと、ＣＡと、意図されたＩＣカードとの間のこの特殊な鍵インタラクションは、安全システムの一部であるＩＣカードへの偽造、もしくは未許可のアプリケーションまたはデータが、ロードされないことを確証する。
【００４５】
次に、工程９１１が、唯一意図されたカードのみがアプリケーションを受け取ることをさらに検証するＫＴＵ認証チェックを処理する。ＫＴＵ認証チェックは、第三者が何らかにおいてＡＬＵを妨害した場合でも、第三者がＡＵの暗号部分を読み出せず、ＡＵを復号化する鍵を受け取れないことを確証する。この工程を図１０においてさらに示す。
【００４６】
図１０は、ＫＴＵ認証プロセスの工程を示す。工程１００１は、好適には任意であるので破線で示されているが、ＩＣカードの同一性を再度チェックする。識別情報は、ＫＴＵデータの一部として送られ得る。しかしながら、このチェックは既に工程９０５において実施されているので、任意である。
【００４７】
次に、工程１００３が、ＩＣカードの秘密鍵（ｍｋｄ＿ｓｋ）を用いてＫＴＵ暗号文５０３を復号化する。ＫＴＵ平文は、意図されるカードの公開鍵（ｍｋｄ＿ｐｋ）を用いて、先だって暗号化されている。これは、唯一意図されたカードの秘密鍵の保持者のみが、暗号化されたメッセージを復号化し得ることを意味する。アプリケーションプロバイダは、ＩＣカード自体から（図４およびｍｋｄ鍵セットに関する関連テキストを参照）、または公開鍵を保持するデータベースのいずれかから、意図されるＩＣカードの公開鍵を入手する。ＩＣカードがＫＴＵ暗号文を適切に復号化しない場合、ＫＴＵはそのカードには意図されておらず、アプリケーションローディングプロセスは停止する。ＩＣカードがＫＴＵ暗号文を適切に復号化した場合、プロセスは継続する。
【００４８】
工程１００５は、アプリケーションユニット（ＡＵ）の暗号化領域を識別する。図６を参照して説明したＫＴＵ平文の例では、ＩＣカードは、相対的開始アドレスおよび領域長フィールドを使用して、暗号化される部分を決定している。工程１００５も、識別された部分を暗号化するのにどの暗号化技術を用いるかを識別し、これにより、適切な復号化技術が使用され得る。例えば、この技術は単一または三重のＤＥＳにより得る。あるいは、この技術は、システムに使用され識別の必要がないデフォルト技術であり得る。
【００４９】
次に、工程１００７が、ＫＴＵ平文からの鍵を復元し、識別された部分を識別された復号化技術で復号化する。これにより、ひとたびすべての暗号化部分が復号化されれば、ＩＣカードはスタティックメモリに記憶されるＡＵの復号化された部分を有する。
【００５０】
工程１００９は、その他に任意の暗号化領域が存在する場合をチェックする。図３に記載の例では、３つの暗号化領域が存在する。暗号化領域の数は、図６の例ではフィールドである。しかしながら、部分の数は、他の従来手段を用いて決定し得る。追加の暗号化領域が存在する場合、プロセスは工程１００５に飛ぶ。追加の暗号化領域が存在しない場合、プロセスは工程１０１１から継続する。
【００５１】
次に、工程１０１１は、復号化されたＡＵをＩＣカードのメモリ内にロードする。ＡＬＵは、すべての認証および復号化チェックを通過し、ついにアプリケーションはＩＣカード上に適切に存在し、カードユーザによって実行され使用され得る。図９および図１０において、異なるチェックが特定順序で提示されたが、チェックは任意の順序で実施し得る。記載したすべての技術は、ＡＬＵに最良の安全性を提供することに関連して使用されたが、一つ以上の個別技術が、個別の目的のため、または他の従来安全技術との組み合わせで使用され得る。
【００５２】
図１１は、ＡＬＵがロードされ処理され得るＩＣカードチップのブロック図の例を示す。使用されるＩＣカード上には集積回路が配置される。ＩＣカードは、好適には、中央演算装置１１０１、ＲＡＭ１１０３、ＥＥＰＲＯＭ１１０５、ＲＯＭ１１０７、タイマ１１０９、制御ロジック１１１１、Ｉ／Ｏポート１１１３、および安全回路１１１５を含み、これらは従来のデータバスによって互いに接続されている。
【００５３】
メモリカード内の制御ロジック１１１１は、入力／出力ポートを介してカードのメモリへの読み出し／書き込みを取り扱うのに充分なシーケンスおよびスイッチングを供給する。制御ロジックを備えたＣＰＵ１１０１は、計算、メモリロケーションへのアクセス、メモリ内容の変更、および入力／出力ポートの管理を実施する。カードのなかには、暗号処理など複雑な演算を取り扱うためのコプロセッサを有するものがある。入力／出力ポート１１１３は、ＣＰＵおよび制御ロジックの制御下で、カードとカードインターフェイスデバイスの間の通信のために使用される。タイマ１１０９（クロックパルスを生成し供給する）は、メモリアクセス、メモリ読み出しまたは書き込み、処理、およびデータ通信を完成する一連の工程を介して、制御ロジック１１１１およびＣＰＵ１１０１を駆動する。タイマーは、呼び出し持続時間などのアプリケーションの特徴を供給するのに用いられ得る。セキュリティ回路１１１５は、製造中におけるテストの必要に応じて、入力／出力配線を内部回路に接続する可融性の（ｆｕｓｉｂｌｅ）接続を含んでいるが、この回路はテストの完了時に、その後のアクセスを防ぐために壊され（「溶融し（ｂｌｏｗｎ）」）、その後のアクセスを防ぐ。ＡＬＵが認証され検証された後のＡＵデータは、ＥＥＰＲＯＭ１１０５に記憶される。本明細書に記載される認証プロセスは、ＣＰＵ１１０１により実行される。
【００５４】
また、図１１は、アプリケーションプロバイダのためのおよび証明機構のための集積回路の可能な構成を示す。アプリケーションプロバイダのためのＩＣチップ内に存在するＣＰＵ１１０１は、本明細書に記載した暗号化技術を用いて必要な情報を暗号化し、必要なデータ処理を実行する。証明機構に存在するＣＰＵ１１０１は、本明細書に記載したアプリケーションロード証明に署名するのに使用される。
【００５５】
上記内容は、本願発明の原理を単に例示したものである。従って、本明細書には明示的に図示または記載しないが、本発明の原理を実施し、それにより、本発明の精神および範囲内にある多数のシステムおよび方法を、当業者が考案できることは理解される。
【００５６】
例えば、本明細書ではアプリケーションのロードを記載しているが、同等の安全ローディングプロセスを、データブロック、データファイル、ワードプロセッシング文書、または安全な方式で送信を要する他の任意のタイプのデータなど、他のタイプのデータの送信に適用し得る。
【００５７】
本開示の範囲は、請求された発明に関連するか否か、あるいは本発明で対処される課題の一部または全てを緩和するか否かに関わりなく、明示的または黙示的に開示された新規の特徴または特徴の組み合わせあるいはそれを一般化したものを含む。本出願は、本出願または本出願に由来する任意のさらなる出願の手続中に、そのような特徴に関する新しい請求項が作成され得ることの注意を促すものである。特に、付属の請求項に関しては、従属項に由来する特徴は、請求の範囲に挙げた特定の組み合わせのみならず、任意の適切な方法で独立項の特徴と組み合わせ得る。
【背景技術】
【０００１】
（発明の背景）
集積回路（「ＩＣ」）カードは、今日世界中で、多くの異なる目的のためにますます多く使用されている。ＩＣカード（スマートカードとも呼ばれる）は、典型的に、従来のクレジットカードの大きさであり、コンピュータチップを有している。このコンピュータチップには、マイクロプロセッサ、リードオンリーメモリ（ＲＯＭ）、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、入力／出力（Ｉ／Ｏ）メカニズム、および、動作中にマイクロプロセッサをサポートするその他の回路が含まれている。ＩＣカードは、そのメモリ内に、単一のアプリケーションを有していてもよいし、あるいは、複数の独立したアプリケーションを有していてもよい。ＭＵＬＴＯＳＴＭは、他のプラットフォームの中でもとりわけＩＣカード上で動作し、そのカード上で複数のアプリケーションの実行を可能にするマルチアプリケーションオペレーティングシステムである。これにより、カードユーザは、そのカードを使用するために挿入した端末（即ち、ＡＴＭ、電話および／またはＰＯＳ）の種類に関わらず、そのカードに保存された多数のプログラム（例えば、クレジット／デビット、電子マネー／財布、および／またはロイヤリティアプリケーション）を実行することができるようになる。
【０００２】
テレフォンカードおよび電子キャッシュカードのような従来の単一アプリケーションＩＣカードは、カードユーザに与えられる前に、その製造の時点で、単一のアプリケーションを付与される。しかし、たとえカードユーザまたはカード発行者がアプリケーションの改変を望んだとしても、カード発行後にアプリケーションを改変または変更することはできない。さらに、あるカードユーザが、そのユーザに対して発行されたＩＣカードに、様々なアプリケーション機能、例えば、電子財布およびクレジット／デビット機能の両方を果たして欲しい場合、カードユーザは複数の物理的カードを持ち運ばなければならない。これは、非常に煩雑で不便である。アプリケーション開発者（ａｐｐｌｉｃａｔｉｏｎ ｄｅｖｅｌｏｐｅｒ）またはカードユーザが、２つの異なるアプリケーション間での相互作用またはデータ交換、例えば、財布機能がフリークエントフライヤーロイヤリティアプリケーションと相互作用することを望んだ場合、カードユーザは、カードを入れる端末に複数のカードを代わる代わる出し入れしなければならず、処理が、困難で、時間がかかり、不便なものになる。
【０００３】
従って、同じＩＣカード上に複数アプリケーションを保存することは有益である。例えば、カードユーザは、同じカード上に財布アプリケーションおよびクレジット／デビットアプリケーションの両方を有し、買物を行うときにどちらの種類の支払い（電子キャッシュまたはクリジットカード）を使用するのかを選択し得る。十分なメモリが存在し、且つ、複数のアプリケーションをサポートできるオペレーティングシステムがカード上にあれば、１枚のＩＣカードに複数のアプリケーションを付与することができる。複数のアプリケーションを予め選択して、それらを製造段階でカードのメモリ内に入れておくことも可能であるが、必要に応じて、製造後に、そのカードのアプリケーションをロードおよび削除できるようにすることも有益であろう。
【０００４】
１枚のカード上に複数のアプリケーションを保存する向上した柔軟性および性能は、個々のカードとアプリケーション提供者との間で交換され、また、アプリケーションをロードおよび削除する際に全システム内で交換される情報（アプリケーションコードおよび関連するデータを含む）の完全性および安全性に関して克服すべき新たな技術的課題を生み出す。カード、カード発行者、システムオペレータおよびアプリケーション提供者間で安全にデータを交換できる能力、ならびに、ローカル端末から、または、電話線、インターネット、イントラネット接続、もしくはその他のデータ経路上で遠隔的に、何時でも安全にアプリケーションをロードおよび削除できる能力をＩＣカードシステム内に持つことは有益であろう。典型的にこれらのデータ送信線は安全な線ではないので、これらの送信線上で送られるアプリケーションが改竄されることなく意図したカード上にのみロードされることを確実にするためには、複数のセキュリティおよびエンティティ認証技術を確立しなければならない。
【０００５】
特に、カード所有者が利用できる新たなアプリケーションが増え続けている状況では、上記のように、発行後にＩＣカード上にアプリケーションを追加する能力をシステムに持たせることが重要である。このことは、ＩＣカードの寿命の長さを守るために必要である。さもなくば、アプリケーションが古くなったときに、そのカードが無用になってしまう。遠隔位置から、および、アプリケーション提供者の端末からの直接接続によって、アプリケーションを追加できるようにすることは有益であろう。例えば、カードユーザが、そのユーザのＩＣカードをユーザのホームコンピュータに差し込んで、インターネット上でアプリケーションをダウンロードできれば有用であろう。アプリケーションコードおよび関連データをインターネット等のセキュリティが確立されていない通信線上で送信する場合、この種のアプリケーション遠隔ロードは複数のセキュリティ上のリスクを生じる。このような能力を提供するシステムにおいて、少なくとも３つの問題点に取り組む必要がある。
【０００６】
第１の問題点は、アプリケーションを受け取るＩＣカードが、目的のＩＣカードであり、別のＩＣカードにならないように確実に取り計らうことである。第２の問題点は、アプリケーションが適切なアプリケーションプロバイダから得られたものであって、未知の第三者から得られたものでないことを、ＩＣカードがどのようにして認証（ａｕｔｈｅｎｔｉｃａｔｅ）することができるかを判定することである。第３の問題点は、第三者がアプリケーションから読み出しを行って、認可されていない（ｕｎａｕｔｈｏｒｉｚｅｄ）コピーを作ることを防ぐことに関する。後半の問題点に取り組むために、アプリケーションの一部分が暗号化される場合、目的のＩＣカードは、アプリケーションを復号化するための正確な鍵へのアクセスを持っている必要がある。多くのＩＣカードおよびさらなる多くのアプリケーションプロバイダを有するシステムにおいて、目的のＩＣカードが、受け取られたアプリケーションについての正確な鍵を使用できるように、安全鍵伝送技術（ｓｅｃｕｒｅ ｋｅｙ ｔｒａｎｓｆｅｒ ｔｅｃｈｎｉｑｕｅ）が要求される。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、本発明の実施の目的の１つは安全な鍵配送技術を提供することであり、具体的には、ＩＣカード上にロードされ得るスマートカードアプリケーションのための改善された安全な配送を可能にする改善された安全なＩＣカードシステムを提供することである。
【課題を解決するための手段】
【０００８】
（発明の要旨）
ＩＣカードシステム、ならびにＩＣカード上へアプリケーションを安全にロードするための方法を提供する本発明により、これらおよび他の目的が達成される。ＩＣカード上へアプリケーションを安全にロードする方法は，ＩＣカードのための秘密鍵および公開鍵のペアを提供すること、転送鍵を用いアプリケーションの少なくとも一部を暗号化すること、ＩＣカードの公開鍵を用いて伝送鍵を暗号化し、鍵変換ユニットを形成すること、暗号化アプリケーションおよび鍵変形ユニットをＩＣカードに転送すること、ＩＣカードの秘密鍵を用いて鍵変換ユニットを復号化し、伝送鍵を提供すること、提供された伝送鍵を用いて暗号化アプリケーションを復号化すること、およびＩＣカード上の復号化アプリケーションを格納することを含む。
【０００９】
好適な実施形態において、ローディングシステムおよび方法により、アプリケーションプロバイダが、２つ以上の異なった鍵で転送されるアプリケーションの２つ以上の部分を暗号化すること、ＩＣカードの公開鍵で２つ以上の鍵を暗号化し、暗号化部分の位置を含む鍵変換ユニットを形成することが可能になる。暗号化アプリケーションおよび鍵変換ユニットの両方はＩＣカードに送信される。復号鍵は、ＩＣカードの公開鍵で暗号化されるので、ＩＣカードの秘密鍵のみが鍵変換ユニットを復号化することができる。伝送鍵および暗号化部分の位置は、復号化された鍵変換ユニットから回復され、アプリケーションは回復された伝送鍵を用いて復号化される。これにより、目的とされるＩＣカードは、復号化し、ＩＣカードに転送されたアプリケーションを使用することができる。
【００１０】
好適な実施形態において、アプリケーションのロード証明は、また、アプリケーションを受け取るＩＣカードに送信される。アプリケーションのロード証明は、証明機関（ＣＡ）の秘密鍵によって暗号化されたアプリケーションプロバイダの公開鍵、または、ＩＣカードシステムの全体のセキュリティを管理するエンティティを含む。次に、ＩＣカードは証明機関の公開鍵を用いて、ＣＡの公開鍵でアプリケーションのロード証明を検証することを試みることによって、証明が妥当であったかを確かめる。次に、ＩＣカードは回復されたアプリケーションプロバイダの公開鍵を使用し、アプリケーションプロバイダが実際に、アプリケーションプロバイダの対応する秘密鍵で生成された、送付されたアプリケーション署名を検証することによってアプリケーションの創設側（ｏｒｉｇｉｎａｔｏｒ）であったことを検証する。
（項目１）
ＩＣカード上へアプリケーションをロードする方法であって、
該ＩＣカードのための秘密鍵および公開鍵のペアを提供する工程と、
伝送鍵を用いて該アプリケーションの少なくとも一部分を暗号化する工程と、
該ＩＣカードの公開鍵を用いて該伝送鍵を暗号化し、鍵変形ユニットを形成する工程と、
該暗号化されたアプリケーションおよび該鍵変形ユニットを該ＩＣカードに転送する工程と、
該ＩＣカードの秘密鍵を用いて該鍵変形ユニットを復号化し、該伝送鍵を回復する工程と、
該回復された伝送鍵を用いて、該暗号化されたアプリケーションを復号化する工程と
を含む、方法。
（項目２）
前記ＩＣカード上に前記復号化されたアプリケーションを格納する工程を更に含む、項目１に記載の方法。
（項目３）
前記伝送鍵を用いる暗号化技術が、対称である、項目１または２に記載の方法。
（項目４）
前記対称技術はＤＥＳである、項目３に記載の方法。
（項目５）
前記ＩＣカードの公開鍵および秘密鍵は非対称技術を用いて提供される、項目１から４のいずれかに記載の方法。
（項目６）
前記非対称技術はＲＳＡである、項目５に記載の方法。
（項目７）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術をさらに示す、項目１から６のいずれかに記載の方法。
（項目８）
前記アプリケーションの前記少なくとも一部を除いた該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目１から７のいずれかに記載の方法。
（項目９）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目８に記載の方法。
（項目１０）
前記第２の部分は、第２の鍵を用いて暗号化され、前記鍵変形ユニットは、該第２の鍵を示す、項目８または９に記載の方法。
（項目１１）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目８から１０のいずれかに記載の方法。
（項目１２）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目１から１１のいずれかに記載の方法。
（項目１３）
前記鍵変形ユニットは、前記アプリケーションの暗号化された部分の数を示す、項目１から１２のいずれかに記載の方法。
（項目１４）
アプリケーションプロバイダのための公開鍵および秘密鍵のセットを提供する工程と、
証明機関のための公開鍵および秘密鍵のセットを提供する工程と、
該証明機関の秘密鍵を用いて、該アプリケーションプロバイダの公開鍵を暗号化し、アプリケーションのロード証明を生成する工程と、
該アプリケーションプロバイダの秘密鍵を用いて、該暗号化されたアプリケーションにさらに署名し、署名された暗号化されたアプリケーションを生成する工程と、
該署名されたアプリケーションおよび該アプリケーションのロード証明を該ＩＣカードに転送する工程と
をさらに含む、項目１から１３のいずれかに記載の方法。
（項目１５）
前記ＩＣカードが、前記証明機関の公開鍵でアプリケーションのロード証明を認証する工程をさらに含む、項目１４に記載の方法。
（項目１６）
復号化されたアプリケーションのロード証明から前記アプリケーションプロバイダの公開鍵を用いて、前記署名された暗号化されたアプリケーションを認証する工程をさらに含む、項目１５に記載の方法。
（項目１７）
認証されたアプリケーション署名は、送信された暗号化されたアプリケーションと比較され、それらが等価であるかを判定する、項目１６に記載の方法。
（項目１８）
少なくとも１つのＩＣカードと、
アプリケーションを該少なくとも１つのＩＣカードに提供するためのアプリケーションプロバイダと、
該少なくとも１つのＩＣカードおよび該アプリケーションプロバイダに連結された通信リンクと、
該ＩＣカードのために生成された、公開鍵および秘密鍵のセットと、
該アプリケーションプロバイダにより用いられるために生成されるトランスポート鍵と、
アプリケーションであって、該アプリケーションの少なくとも一部は該トランスポート鍵を用いて該アプリケーションプロバイダによって暗号化され；該トランスポート鍵が該ＩＣカードの公開鍵を用いて暗号化され、鍵変形ユニットを形成し；次に該暗号化されたアプリケーションおよび該鍵変形ユニットは、該通信リンクを介して該ＩＣカードに転送され；該転送された該鍵変形ユニットが該ＩＣカードの秘密鍵を用いて復号化され、該トランスポート鍵を回復し；該転送されたアプリケーションが該回復されたトランスポート鍵を用いて復号化され、該アプリケーションを回復する、アプリケーションと
を備える、ＩＣカードシステム。
（項目１９）
前記回復されたアプリケーションは、前記カード上に格納される、項目１８に記載のシステム。
（項目２０）
前記トランスポート鍵を用いた暗号化技術は、対称である、項目１８または１９に記載のシステム。
（項目２１）
前記対称技術は、ＤＥＳである、項目２０に記載のシステム。
（項目２２）
前記ＩＣカードの公開鍵および秘密鍵は、非対称技術を用いて提供される、項目１８から２１までのいずれかに記載のシステム。
（項目２３）
前記非対称技術は、ＲＳＡである、項目１１に記載のシステム。
（項目２４）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術をさらに示す、項目１８から２３のいずれかに記載のシステム。
（項目２５）
前記アプリケーションの前記少なくとも一部に独立な該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目１８から２４のいずれかに記載のシステム。
（項目２６）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目２５に記載のシステム。
（項目２７）
前記第２の部分は、第２の鍵を用いて暗号化され、前記鍵変形ユニットは、該第２の鍵を示す、項目２５または２６に記載のシステム。
（項目２８）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目２５から２７のいずれかに記載のシステム。
（項目２９）
前記鍵変形ユニットは、前記アプリケーションの少なくとも一部の位置を示す、項目１８から２８のいずれかに記載のシステム。
（項目３０）
前記鍵変形ユニットは、前記アプリケーションの暗号化された部分の数を示す、項目１８から２９のいずれかに記載のシステム。
（項目３１）
証明機関を更に含み、
公開鍵および秘密鍵のセットはアプリケーションプロバイダのために提供され；公開鍵および秘密鍵のセットは該証明機関のために提供され；該証明機関の秘密鍵は、前記アプリケーションプロバイダの公開鍵に署名するのに使用され、アプリケーションのロード証明を生成し；該アプリケーションプロバイダの秘密鍵は、前記暗号化されたアプリケーションにさらに署名するのに使用され、署名された暗号化されたアプリケーションを生成し、該署名された暗号化されたアプリケーションおよび該アプリケーションのロードの証明は、該ＩＣカードに転送される、項目１８から３０のいずれかに記載のシステム。
（項目３２）
前記ＩＣカードが、前記証明機関の公開鍵で前記アプリケーションのロード証明を認証する、項目３１に記載のシステム。
（項目３３）
前記ＩＣカードは、前記認証されたアプリケーションのロード証明から前記アプリケーションプロバイダの公開鍵を使用して前記署名された暗号化されたアプリケーションを認証する、項目３２に記載のシステム。
（項目３４）
認証されたアプリケーション署名を、前記暗号化されたアプリケーションと比較し、それらが等価であるかどうかを判定する、項目３３に記載のシステム。
（項目３５）
第１のマイクロプロセッサベースの装置から、第２のマイクロプロセッサベースの装置にデータを転送する方法であって、
伝送鍵を用いて該データの少なくとも一部を該第１の装置で暗号化する工程と、
該第１の装置において第２の鍵で該伝送鍵を暗号化し、鍵変形ユニットを形成する工程と、
該暗号化されたデータおよび該鍵変形ユニットを該第２の装置に転送する工程と、
該第２の装置で該鍵変形ユニットを復号化し、該伝送鍵を回復する工程と、
該回復された伝送鍵を用いて該暗号化されたデータを復号化する工程と
を含む、方法
（項目３６）
前記第２の装置で前記復号化されたデータを格納する工程を更に含む、項目３５に記載の方法。
（項目３７）
前記第２の鍵は、非対称暗号化において使用される公開鍵および秘密鍵のセットに由来する、項目３５または３６に記載の方法。
（項目３８）
前記鍵変形ユニットは、前記アプリケーションの少なくとも一部を暗号化するために使用される技術を更に示す、項目３５から３７のいずれかに記載の方法。
（項目３９）
前記アプリケーションの前記少なくとも一部に独立な該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目３５から３８のいずれかに記載の方法。
（項目４０）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目３９に記載の方法。
（項目４１）
前記第２の部分は第２の鍵を用いて暗号化され、前記第２の鍵変形ユニットは該第２の鍵を示す、項目３９または４０に記載の方法。
（項目４２）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目３９に記載の方法。
（項目４３）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目３５から４２のいずれかに記載の方法。
（項目４４）
アプリケーションプロバイダのための公開鍵および秘密鍵のセットを提供する工程と、
証明機関のための公開鍵および秘密鍵のセットを提供する工程と、
該証明機関を用いて該アプリケーションプロバイダの公開鍵に署名し、アプリケーションのロード証明を生成する工程と、
該アプリケーションプロバイダの秘密鍵を用いて該暗号化されたアプリケーションをさらに暗号化し、署名された暗号化されたアプリケーションを生成する工程と、
該署名されたアプリケーションおよび該アプリケーションのロード証明を該ＩＣカードに転送する工程と
をさらに含む、項目３５から４３のいずれかに記載の方法。
（項目４５）
データ転送を処理するための方法であって、
アプリケーションを含む該データ転送を受け取る工程であって、該アプリケーションは、第１の鍵で暗号化された少なくとも一部、および、第２の鍵で暗号化された鍵変形ユニットを含み、該鍵変形ユニットは該第１の鍵を含む、工程と、
該鍵変形ユニットを復号化し、該第１の鍵を回復する工程と、
該第１の鍵を用いて該暗号化されたアプリケーションを復号化する工程と、
該復号化されたアプリケーションを格納する工程と
を含む、方法。
（項目４６）
前記第２の鍵は、非対称暗号化において使用される公開鍵および秘密鍵のセットに由来する、項目４５に記載の方法。
（項目４７）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術を更に示す、項目４５または４６に記載の方法。
（項目４８）
前記アプリケーションの前記少なくとも一部に独立な該アプリケーションの第２の部分を暗号化する工程をさらに含む、項目４５から４７のいずれかに記載の方法。
（項目４９）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目４８に記載の方法。
（項目５０）
前記第２の部分は第２の鍵を用いて暗号化され、前記鍵変形ユニットは該第２の鍵を示す、項目４８または４９に記載の方法。
（項目５１）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目４８に記載の方法。
（項目５２）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目４５から５１のいずれかに記載の方法。
（項目５３）
アプリケーションプロバイダのための公開鍵および秘密鍵のセットを提供する工程と、
証明機関のための公開鍵および秘密鍵のセットを提供する工程と、
該証明機関を用いて該アプリケーションプロバイダの公開鍵に署名し、アプリケーションのロード証明を生成する工程と、
該アプリケーションプロバイダの秘密鍵を用いて該暗号化されたアプリケーションをさらに暗号化し、署名された暗号化アプリケーションを生成する工程と、
該署名されたアプリケーションおよび該アプリケーションのロード証明を該ＩＣカードに転送する工程と
をさらに含む、項目４５から５２のいずれかに記載の方法。
（項目５４）
前記ＩＣカードが、前記証明機関の公開鍵で前記アプリケーションのロード証明を認証する工程をさらに含む、項目５３に記載の方法。
（項目５５）
前記認証されたアプリケーションのロード証明から前記アプリケーションプロバイダの公開鍵を用いて、署名された暗号化されたアプリケーションを認証する工程をさらに含む、項目５４に記載の方法。
（項目５６）
認証されたアプリケーション署名を前記暗号化されたアプリケーションと比較し、それらが等価であるか判定する、項目５５に記載の方法。
（項目５７）
データ転送を処理するための装置であって、
アプリケーションを含む該データ転送を受け取る手段であって、該アプリケーションは、第１の鍵で暗号化された少なくとも一部と、第２の鍵で暗号化された鍵変形ユニットを含み、該鍵変形ユニットは該第１の鍵を含む、手段と、
該鍵変形ユニットを復号化し、該第１の鍵を回復する手段と、
該第１の鍵を用いて該暗号化されたアプリケーションを復号化する手段と、
該復号化されたアプリケーションを格納する手段と
を含む、装置。
（項目５８）
前記第２の鍵は、非対称暗号において使用される公開鍵および秘密鍵のセットに由来する、項目５７に記載の装置。
（項目５９）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部を暗号化するために使用される技術をさらに示す、項目５７または５８に記載の装置。
（項目６０）
前記アプリケーションの前記少なくとも一部を除いた該アプリケーションの第２の部分を暗号化するための手段をさらに含む、項目５７から５９に記載の装置。
（項目６１）
前記第２の部分は、第２の暗号化技術を用いて暗号化され、前記鍵変形ユニットは、該第２の暗号化技術を示す、項目６０に記載の装置。
（項目６２）
前記第２の部分は、第２の鍵を用いて暗号化され、前記鍵変形ユニットは、該第２の鍵を示す、項目６０または６１に記載の装置。
（項目６３）
前記鍵変形ユニットは、前記アプリケーションの前記第２の部分の位置を示す、項目６０から６２のいずれかに記載の装置。
（項目６４）
前記鍵変形ユニットは、前記アプリケーションの前記少なくとも一部の位置を示す、項目５７から６３のいずれかに記載の装置。
（項目６５）
前記証明機関の公開鍵でアプリケーションのロード証明を認証するための手段をさらに含む、項目６０から６４のいずれかに記載の装置。
（項目６６）
前記認証されたアプリケーションのロード証明に位置するアプリケーションプロバイダの公開鍵を用いて前記署名された暗号化されたアプリケーションを認証する手段をさらに含む、項目６５に記載の装置。
（項目６７）
認証されたアプリケーション署名は、前記暗号化されたアプリケーションと比較され、それらが等価であるかを判定する、項目６６に記載の装置。
【図面の簡単な説明】
【００１１】
本発明の例示的な実施形態を示す添付の図面に関連して以下の詳細な説明を読むことにより、本発明のさらなる目的、特徴および利点が明らかになるであろう。
【図１】図１は、アプリケーション提供者からＩＣカードにアプリケーションをロードするアプリケーションロードシステムのブロック図である。
【図２】図２は、アプリケーションロードユニットの内容を図示したものである。
【図３】図３は、アプリケーションユニットを図示したものである。
【図４】図４は、あるＩＣカードについての個々の鍵組を提供する工程のフローチャートである。
【図５】図５は、鍵変換ユニットを図示したものである。
【図６】図６は、鍵変換ユニットの平文を図示したものである。
【図７】図７は、アプリケーションロード証明書（Ａｐｐｌｉｃａｔｉｏｎ Ｌｏａｄ Ｃｅｒｔｉｆｉｃａｔｅ）を図示したものである。
【図８】図８は、アプリケーションユニットが復号化される様子を図示したものである。
【図９】図９は、アプリケーションロードユニットを処理する際に行われる工程を示すフローチャートである。
【図１０】図１０は、ＫＴＵを処理する際に行われる工程を示すフローチャートである。
【図１１】図１１は、アプリケーションロードユニットを受け取り、これを処理することができるＩＣカードの構成要素を示すブロック図である。
【発明を実施するための形態】
【００１２】
そうでないことが記載されている場合を除き、全図面を通して、同じ参照番号および文字は、例示された各実施形態において同じ特徴部、部材、構成要素および部分を示すために用いられている。さらに、以下で図面を参照しながら本発明を説明するが、これは例示的な実施形態に関する説明である。添付のクレームによって規定される本発明の真の範囲および趣旨から逸脱することなく、記載された実施形態に変更および改変を加えることが可能であることが意図されている。
【００１３】
（発明の詳細な説明）
そのＩＣカードの寿命の任意の時点で、複数のアプリケーションオペレーティングシステムを含むＩＣカード上にアプリケーションをロードできる能力を持つことは有益である。この柔軟性によって、カードのユーザが、定期的に新しいアプリケーションをＩＣカードに追加すること、ならびに、より新しいバージョンのアプリケーションがリリースされたときに、新しいバージョンのアプリケーションを用いて古いアプリケーションを更新することが可能になる。例えば、カードユーザは、初めに、財布または電子キャッシュアプリケーション（例えば、ＭＯＮＤＥＸＴＭ）が保存されたＩＣカードを持ち得る。ユーザがこのカードを持ってからしばらくした後、このユーザは、クレジット／デビットアプリケーションのような追加アプリケーションをこのカード上にロードし得る。カード上にクレジット／デビットアプリケーションをロードしてからしばらくした後、そのクレジット／デビットアプリケーションの新しいバージョンが利用可能になり得る。その時、このカードユーザが、そのＩＣカード上の古いアプリケーションを消去して、さらなる機能を有し得るクレジット／デビットアプリケーションの新しいバージョンに置き換えることは可能であるべきである。
【００１４】
ＩＣカードの寿命サイクルにおける複数の異なる時点でアプリケーションのロードを行うという柔軟性は、カード上にアプリケーションをロードするプロセスに関してセキュリティ上の問題を生じる。マルチアプリケーションオペレーティングシステム環境においては、アプリケーションのロードを、銀行のＡＴＭマシンのような端末と、電話線、ケーブル線、インターネット、衛星または他の通信手段等の遠隔通信リンク上との両方で行えることが有益である。ＩＣカード上にアプリケーションをロードする際、アプリケーション提供者およびカード発行者（同じエンティティであり得る）は、ロードすべきアプリケーションに関するセキュリティを提供する必要がある。第１に、アプリケーション提供者は、そのアプリケーションを受け取ることが意図された正しいカードユーザにのみアプリケーションが送られることを確実にしなければならない。この問題に対する１つの解決方法が、１９９８年２月１９日に出願され、Ｍｏｎｄｅｘ Ｉｎｔｅｒｎａｔｉｏｎａｌに譲渡された、Ｅｖｅｒｅｔｔｅらによる”Ｍｕｌｔｉ−Ａｐｐｌｉｃａｔｉｏｎ ＩＣ Ｃａｒｄ Ｓｙｓｔｅｍ Ｈａｖｉｎｇ Ｓｅｌｅｃｔｉｖｅ Ｌｏａｄｉｎｇ ａｎｄ Ｄｅｌｅｔｉｎｇ Ｃａｐａｃｉｔｙ”という名称の関連ＰＣＴ出願において試みられている。この文献を、本明細書に添付したアネックスＢへの参考として本明細書中で援用する。アプリケーションを離れたソースから、またはローカルターミナルから、ＩＣカード上へとロードする場合に、２つのさらなるセキュリティに関する問題に取り組む必要がある。まず、ウイルスを含み得るか、または、単にＩＣカード内の限られた記憶メモリを占拠し得るアプリケーションをＩＣカード上にロードすることがないように、アプリケーションのソースは適切な発信元（ｏｒｉｇｉｎａｔｏｒ）として認証される必要がある。第２に、アプリケーションおよび関連データは、個人的または企業秘密情報を含み得る。このような個人的または企業秘密情報は暗号化することにより、暗号化されたアプリケーションコードおよびデータの内容を他の人々に見られないようにする必要がある。アプリケーションコードおよびデータの一部が秘密であり、他の部分は秘密ではない場合もある。本願では、カードにロードするアプリケーションおよび関連データの一部または全ての内容の認証および保護という問題に対処する。
【００１５】
本明細書中、複数の暗号化／復号化技術が記載される。対称暗号化および非対称暗号化という２つの基本的な種類の暗号化がある。対称暗号化では、式および鍵を用いてデータを変換することにより、データを暗号化する数式の一部として秘密鍵を用いる。データを暗号化した後、これと同じ秘密鍵を関連する復号化アルゴリズムとともに用いて、別のパーティが、この暗号化されたデータを復号化することができる。同じ鍵は暗号化および復号化のために用いられ、技術は対称的である。対称アルゴリズムの従来例の１つは、ＤＥＳである。
【００１６】
非対称暗号化技術では、１対をなす異なる２つの鍵を用いて情報の暗号化および復号化を行う。これらの２つの鍵は、通常、プライベートまたは秘密鍵および公開鍵と呼ばれる。この１対の鍵の一方を用いてデータを暗号化した場合、そのデータの復号化には他方の鍵が用いられる。データの送り主が、そのデータをその送り主の秘密鍵を用いて署名すると、公開鍵を持っていれば誰でもそのメッセージを検証できる。典型的に、公開鍵は公に知られているので、秘密鍵を用いて署名されたデータの内容を保護することはできないが、特定の秘密鍵によってそのデータが署名されているかどうかを判定することによってそのデータの起源（ｏｒｉｇｉｎａｔｉｏｎ）は検証できる。この認証プロセスは、デジタル署名と呼ばれる。人物Ａが人物Ｂに送ろうとしているメッセージを人物Ａが認証したい場合、人物Ａは、人物Ａの秘密鍵を用いてその文書を解読する。公開鍵が提供された後に文書が読み出されると、人物Ｂは、人物Ａの公開鍵を用いてそのメッセージを検証する。その公開鍵を用いてそのメッセージが検証されると、その文書が人物Ａの秘密鍵を用いて署名されたことを人物Ｂが知ることになる。このようにして、メッセージの起源（ｏｒｉｇｉｎ）が認証される。
【００１７】
非対称鍵組を用いてメッセージの内容を保護することも可能である。人物Ａが、人物Ｂに、他の誰も読むことのできない暗号化されたメッセージを送りたい場合、人物Ａは、そのデータまたはメッセージを人物Ｂの公開鍵を用いて暗号化し、それを人物Ｂに送る。そうすれば、人物Ｂの秘密鍵の所有者しかそのデータを復号化できなくなる。複数の鍵の組み合わせを用いれば、ある人物がそのメッセージの認証および暗号化の両方を行うことが可能である。非対称の鍵対には、カードセキュリティに関していくつかの強力な用途があり、対称暗号化よりもより頑強である。しかし、非対称暗号化は、対称暗号化と比べて比較的プロセッサコストがより高くつく（プロセッサコストは演算時間と関連している）。非対称暗号化方法の一例は、ＲＳＡ（Ｒ）である。
【００１８】
暗号化方法をより強力にするハイブリッド対称暗号化方法の１つは、２つの対称鍵を用いてデータを暗号化することである。この技術はトリプルＤＥＳと呼ばれ、対称鍵１を用いてデータを符号化し、対称鍵２を用いてそのデータを復号化し（これにより、そのデータをさらに符号化することになる）、そして、再び鍵１を用いてそのデータをさらに符号化するものである。データがその目的地に到着した後、鍵１を用いてそのデータを復号化し、鍵２を用いてそのデータを符号化し、そして、鍵１を用いてそのデータを復号化する。これらの余分な符号化および復号化ステップによって、この技術はより強力になるとともに、両方の鍵がそろっていない状態で適切に復号化することがより困難になる。
【００１９】
図１は、安全な遠隔アプリケーションローディングプロセスに使用されるエンティティのブロック図を示す。アプリケーションプロバイダ１０１は、カードの発行者、銀行、またはアプリケーションローディングサービスを提供する他のエンティティであり得る。アプリケーションプロバイダ１０１は、ＩＣカード１０３上へのアプリケーションローディングプロセスを起動する。アプリケーションプロバイダ１０１は、データコンデット１０７に接続され、データコンデット１０７は、インターフェイスデバイス１０５（例えば、ＩＣカードと通信する端末）に接続されている。データコンデット１０７は、電話回線、イントラネット、インターネット、衛星リンク、またはその他の任意のタイプの通信リンクであり得る。アプリケーションプロバイダ１０１は、ＩＣカード１０３から遠隔に配置され、ＩＣカードへアプリケーションを送信してロードすることを所望する。しかしながら、データリンクがオープンリンクであり、送信されるアプリケーションを妨害したり置換する第三者に晒されているために、アプリケーション自体を認証する安全手段、アプリケーションプロバイダ、およびＩＣカードが、システムの整合性を確実にするために使用されなければならない。送信されているいくつかのデータが識別されたシステム一部であることの認証を補助するためには、証明機構ＣＡ１０９も使用され得る。
【００２０】
図１では、アプリケーションプロバイダは、インターフェースデバイス１０５へ、そして最終的にはＩＣカード１０３へ、アプリケーションロードユニット１１１を送信する。ＡＬＵは、アプリケーション自体および認証に必要なセキュリティデータを含み、アプリケーションコードおよび関連データを保護する。ＡＬＵは、図２において詳細を論じたが、本明細書の他の図とも関連がある。ＡＬＵ１１１は、好適には、証明機構（ＣＡ）１０９からアプリケーションプロバイダ１０１に送信されるアプリケーションロード証明（ＡＬＣ）１１３データをも含む。証明機構は、ＩＣカード上にロードされるべき各アプリケーションに対するアプリケーションロード証明を供給することによって、システムの全体的なセキュリティを管理する。アプリケーションプロバイダ１０１およびＩＣカード１０３の両方は、それらに提供される個々の公開／秘密鍵セットを有する。認証とセキュリティのプロセスを以下に説明する。
【００２１】
図２は、アプリケーションロードプロセス中にアプリケーションローダからＩＣカードに送信されるアプリケーションロードユニットの構成要素を説明する図を示す。アプリケーションロードユニット（ＡＬＵ）２０１は、アプリケーションユニット（ＡＵ）２０３、アプリケーションユニット署名（ＡＵｓ）２０５、
鍵変換ユニット（ＫＴＵ）２０７、およびアプリケーションロード証明（ＡＬＣ）２０９を含む。ＡＬＣ２０１は、データ送信中に使用される従来フォーマットで初期化される。ＡＵ２０３は、ＩＣカード上に記憶されるべきアプリケーションコードおよびデータを含み、それらの一部またはすべてが、秘密部分を、もしくはコードおよび／またはデータ部分を保護するために暗号化される。ＡＵ２０３を、図３を参照してさらに詳細に説明する。
【００２２】
ＡＵｓ２０５は、アプリケーションプロバイダの秘密鍵でデジタル的に署名されたアプリケーションコードおよびデータＡＵ２０３である。アプリケーションプロバイダの公開鍵は、ＡＬＣ２０９の一部として送信され、アプリケーションの作成者としてアプリケーションプロバイダを認証するのに使用される。ＡＬＣ２０９は、カード識別情報およびアプリケーションプロバイダの公開鍵から構成され、証明機構の秘密鍵によって署名される。以下、これらの要素をすべて、より詳細に説明する。
【００２３】
ＫＴＵ２０７は、指定された部分をＩＣカードが復号化するのを可能にする、ＡＵ２０３（アプリケーションのコードおよびデータ）の暗号化に関する情報を含み、これにより、アプリケーションおよびデータはＩＣカードによってアクセスされ得るが、アプリケーションプロバイダとＩＣカードとの間での送信中にデータを保護する。ＫＴＵ２０７は、アプリケーションが意図されるＩＣカードの公開鍵で署名されており、これにより、意図されたＩＣカードのみが、ＫＴＵ情報を用いたアプリケーションコードおよびデータを復号化できることを確実にする。この要素は図５を参照して説明する。
【００２４】
図３は、アプリケーションロードユニットの一部であるアプリケーションユニット２０３の図を示す。ＡＵ２０３は、カードユーザのＩＣカード上にロードされるべきプログラムコードおよび関連データ両方を含む。プログラムコードは、ＩＣカードのマイクロプロセッサによって実行される複数のプログラム命令を含む。プログラム命令は、ＩＣカード上に記憶されているオペレーションシステムが解釈できる任意のプログラミング言語で記述され得る。
【００２５】
例えばＭＵＬＴＯＳシステムでは、プログラムはＭＥＬＴＭ（ＭＵＬＴＯＳ実行可能言語）で記述され得る。たいていのアプリケーションは、カード上にロードされなければならない関連データを有する。例えば、人名またはアカウント番号などカードユーザを識別するデータは、クレジット／デビットアプリケーションを伴う安全な方式においてロードされ得る。アプリケーションプロバイダは、データによって表される電子キャッシュを、電子パースアプリケーションをインストールするときに助成として提供し得る。このデータのいくつかまたは全部が、第三者から秘密に保たれることが所望される。ひいては、アプリケーションコード自体が独占物であると見なされ得、その一部が他者からは秘密であることが所望され得る。鍵変換ユニット（ＫＴＵ）の使用は、アプリケーションプロバイダーがアプリケーションの選択された部分を秘密として暗号化し、第三者からそれを保護することを可能にする。
【００２６】
アプリケーションユニット部分３０５は、アプリケーションプロバイダからＩＣカードに送信されるべきプログラムコードを指示する。アプリケーションユニット部分３０７は、ＩＣカード上にロードされるべきアプリケーションの一部として送信されるべき関連データを指示する。この例では、アプリケーションユニットの３つの個別領域が、単一のＤＥＳまたは３重のＤＥＳのいずれかを用いて暗号化されることが示されている。暗号化される部分および暗号化のタイプに関する任意の数の変更が、本願記載の技術を用いて実施され得る。
【００２７】
この例では、暗号化されたロケーション３０９は、３重ＤＥＳ技術を用いて暗号化されたアプリケーションユニット２０３の第１の部分を示す。上述の暗号化プロセスは、対称的鍵および従来公知のＤＥＳアルゴリズムを用いてデータを変換することを含む。データはその後、従来公知のＤＥＳベースアルゴリズムにデータを代入することにより復元され得る。暗号化ロケーション３１１は、３重ＤＥＳを用いて暗号化されたアプリケーションユニット２０３の第２の部分を示す。暗号化ロケーション３１３は、単一のＤＥＳを用いて暗号化された第３の部分を示す。単一ＤＥＳは、より少ない計算しか復号化に要さず、後述するＫＴＵの一部として、より少ない領域しか占有しない。アプリケーションローダからＩＣカードへ送信中に、第三者によってアプリケーションユニットが妨害された場合、第三者が正しい鍵を有するまで、暗号化された部分は、読み出され得ない。従って、情報はＫＴＵ内で保護される。
【００２８】
ＫＴＵは、アプリケーションユニットのどの部分が暗号化されるか、どの暗号化アルゴリズムが使用されるか、およびテキストの復号化に使用される単数または複数の鍵を記述することによって、アプリケーションおよび関連データの意図するＩＣカードが、アプリケーションユニットの暗号化部分を復号化することを可能にする。この情報は、アプリケーションプロバイダと意図されるＩＣカードとの間で高度に秘密であり、従って意図されるカードに極めて特殊な方式で保護される。送信されるＡＬＵ全体の一部であるＫＴＵを暗号化するために、特定の意図されるＩＣカードのための個別鍵セットが使用される。鍵セットおよびその作成を以下に説明する。
【００２９】
ＣＡにおいて実行される安全処理の一つは、カード上に記憶された各ＩＣカードのための個別化された鍵セットを作成することである。鍵は、オフカード検証（即ちカードが正真のカードであることを検証する）および安全なデータ配送に使用される。鍵作成プロセスを図４に概略的に示す。鍵セットは、３つの異なる鍵データアイテムから構成される。即ち、カードのみが知っているカード秘密鍵、カード上に記憶されているカードの公開鍵、およびＣＡの秘密鍵の一つによって署名されたカード公開鍵であるカード公開鍵証明である。以下、鍵セットの個々の鍵を、より詳細に説明する。
【００３０】
工程４０１は、カードのメモリ内の個別ＩＣカードに対して、カード特定的に配送された秘密鍵を記憶する。この秘密鍵は、ＣＡにより作成され、カード許可デバイスを介してカード上にロードされる。ひとたびカード上に記憶されれば、ＣＡはそれ自身のメモリから秘密鍵に関するあらゆるデータを消去する。従って、カード自体のみがその秘密鍵を知っている。カード内の秘密鍵情報を含んでいるデータ要素は、「ｍｋｄ＿ｓｋ」と呼ばれ、ＭＵＬＴＯＳ鍵データ秘密鍵を意味する。
【００３１】
工程４０３は、カードのメモリ内の個々のＩＣカードのためのカード特定的に配送された公開鍵を記憶する。この公開鍵は、好適には、工程４０１において秘密鍵を作成するのに使用された非対称暗号化技術からＣＡによって作成される。カードの公開鍵情報を含むデータ要素は「ｍｋｄ＿ｐｋ」と呼ばれ、ＭＵＬＴＯＳ鍵データ公開鍵を意味する。
【００３２】
工程４０５は、カードメモリ内の個々のＩＣカードのためのカード特定的に配送された公開鍵証明を記憶する。カードの公開鍵証明情報を含むデータ要素は、「ｍｋｄ＿ｐｋ＿ｃ」と呼ばれ、ＭＵＬＴＯＳ鍵データ公開鍵証明を意味する。この公開鍵証明は、好適には、以下に示すようにＣＡの秘密鍵で配送公開鍵「ｍｋｄ＿ｐｋ」に暗号化することにより作成される。
【００３３】
ｍｋｄ＿ｐｋ＿ｃ＝［ｍｋｄ＿ｐｋ］ＣＡ＿ｓｋ
これは、個々のカードの公開鍵証明が、ＣＡの秘密鍵を個々のカードの公開鍵に適用して作成されることを意味する。このプロセスは、ＣＡにおいて実施される。公開鍵証明はＣＡによって保存され、これにより、必要に応じて公開鍵を再作成することができる。
【００３４】
端末がＩＣカードから公開鍵証明を読み出し得、ＣＡが署名をし、それにより個々のＩＣカードを認可したことを検証できる。これは、ｍｋｄ＿ｐｋに署名するのに使用されたＣＡ鍵セットの公開要素で公開鍵証明を検証することによって達成される。暗号化公開鍵は、鍵認証がＣＡによって認証（署名）されたかを立証するために公開鍵と比較され得る。
【００３５】
図５は、ＫＴＵ２０７の内容を図示したものであり、ヘッダ部分５０１およびＫＴＵ暗号文部分５０３を含んでいる。図５に示すように、ヘッダ情報５０１は、例えば、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄ＿ｎｏ（アプリケーション識別番号）、ｍｃｄ＿ｎｏ（ＩＣカード番号）および／またはｍｓｍ＿ｃｏｎｔｒｏｌ＿ｄａｔａ＿ｄａｔｅ（ＩＣカードが発行された日付）などの識別子または許可情報５０５を含む。追加の識別子も含まれ得る。これらの識別子により、システムは、ＡＬＵを受信するＩＣカードが意図されたＩＣカードであることを検証できる。許可データは、上記参照した関連出願に詳細に記載されている。
【００３６】
ＫＴＵ暗号文５０３は、ボックス５０７に示す意図されたＩＣカードの公開鍵ｍｋｄ＿ｐｋで暗号化されたＫＴＵ平文（暗号化されていない）に対応する。ＫＴＵ平文は、図６においてさらに説明する。公開鍵ｍｋｄ＿ｐｋは、アプリケーションプロバイダーによって、意図されたＩＣカードから取得される。ＩＣカードの公開鍵は、誰でも自由に利用でき、カードまたはＣＡから直接入手できる。ＫＴＵ平文をＩＣカードの公開鍵で署名化することによって、意図されたＩＣカードのみが公開／秘密鍵対の秘密鍵を用いてＫＴＵ暗号文を復号化することができる。これは、意図されたＩＣカードのみが、ＫＴＵ平文の内容を決定し、ロードされるアプリケーションの暗号化部分を識別し、鍵を用いてアプリケーション全体および関連データを復号化し復元できることを意味する。その他のエンティティは、ＩＣカードの秘密鍵を有さないので、送信されているプログラムコードおよびデータのセキュリティと整合性とが確保される。
【００３７】
図６は、ＫＴＵ平文６０１を示す図である。ＫＴＵ平文６０１は、好適には、識別子フィールド６０３、ｎｏ＿ａｒｅａ＿ｄｉｓｃｒｉｐｔｏｒｓフィールド６０５、ａｌｇ＿ｉｄフィールド６０７、ａｒｅａ＿ｓｔａｒｔフィールド６０９、ａｒｅａ＿ｌｅｎｇｔｈ６１１、ｋｅｙ＿ｌｅｎｇｔｈフィールド６１３、ｋｅｙ＿ｄａｔａフィールド６１５、ならびに、アプリケーションユニット内に存在する暗号化領域の数によって追加の領域および鍵フィールドを含む。識別子６０３は、ＫＴＵが適用されるアプリケーションユニットの識別情報を含む。
【００３８】
Ｎｏ＿ａｒｅａ＿ｄｅｓｃｒｉｐｔｏｒｓ６０５は、いくつの数のＡＵの異なる部分が暗号化されたのかを示す。図３の例では、領域記述子の数は３である。フィールド６０７は、暗号化された第１の領域のためのアルゴリズム識別子を含む。アルゴリズムは、例えば、ＤＥＳまたは三重ＤＥＳであり得る。フィールド６０９は、第１の暗号化領域の開始を指示する。この指示は、ＡＵの開始からのオフセットであり得る。例えば、オフセットは、１００により得る。これは、第１の領域が、アプリケーションユニットの１００番目のバイトから開始することを意味する。フィールド６１１は、第１の暗号化部分の領域長を指示する。このフィールドにより、ＩＣカード上のマイクロプロセッサは、どの程度の大きさの領域が暗号化され、領域の開始といつ結合されたのかを知ることができ、ＩＣカードマイクロプロセッサは、アプリケーションユニットの正しい部分を暗号化できる。フィールド６１３は、アプリケーションユニットの特定の暗号化部分に対する鍵長を指示する。鍵の長さは、異なる暗号化技術によって異なる。鍵長フィールドによって、ＩＣカードは鍵データの長さを知ることができる。フィールド６１５は、特定の暗号化部分に対する鍵データを指示する。鍵データは、暗号化部分のアルゴリズム同一性およびロケーションとともに使用され、暗号化部分をデコードする。一つ以上の暗号化部分が指示されている場合、アルゴリズムを参照する追加のデータ、開始ロケーション、長さ、鍵長および鍵データが、ＫＴＵ平文内に存在する。複数のフィールドを記載したが、本発明にすべてのフィールドが必要なのではない。しかしながら、最も重要なフィールドは、鍵データ自体である。
【００３９】
図７は、アプリケーションロード証明（ＡＬＣ）２０９を示す図である。ＡＬＣ２０９は、ヘッダ７０１およびアプリケーションプロバイダ公開鍵７０３を含む。次に、ヘッダ７０１およびアプリケーションプロバイダ公開鍵７０３は、ＣＡの秘密鍵で署名（暗号化）される。従って、ＣＡのみがＣＡプライベート鍵を知っているので、ＡＬＣ２０９は、ロードされる各アプリケーションに対してＣＡによってアプリケーションプロバイダに供給されなければならない。ヘッダ７０１は、アプリケーションが意図されるアプリケーションプロバイダおよびＩＣカードに関する情報を含む。ＡＬＣ２０９は、識別情報を使用し得るアプリケーションプロバイダによって正しいＡＬＵ内に配置される。アプリケーションプロバイダ公開鍵７０３は、識別データとともにＣＡに供給される。次に、ＣＡは、認証性を検証したあとで、この情報に署名し、アプリケーションプロバイダに署名されたＡＬＣを返送する。ＩＣカードは、ＡＬＵ２０１の一部としてＡＬＣ２０９を受け取るとき、ＣＡの公開鍵でＡＬＣ２０９を検証する。これにより、ＣＡがアプリケーションロード証明に署名し、それが本物であることを確証する。情報を複号化した後で、ヘッダ識別情報７０１がチェックされ、アプリケーションプロバイダ公開鍵が復元される。この公開鍵は、 ＩＣカード上にロードされるべきアプリケーションおよびコードが適切なアプリケーションプロバイダによって作成されたことを検証するのに使用される。
【００４０】
図８は、ＡＵ２０３がアプリケーションプロバイダによって署名されたことを検証するために、アプリケーションプロバイダの公開鍵を使用してＡＵ署名２０５を複号化することを示した図である。ＡＵ署名２０５は、アプリケーションプロバイダ公開鍵８０１で検証される。受け取られたＡＵ８０３は、ＡＵ２０３と比較される。データブロックがマッチした場合、ＩＣカードは、アプリケーションプロバイダがアプリケーションユニットに署名（暗号化）し、アプリケーションが本物であることを検証した。この認証は、アプリケーションプロバイダのみが秘密鍵を有するので、有効である。アプリケーションプロバイダ公開鍵がＣＡによって署名されたアプリケーションロード証明２０９の一部として供給されているので、ＩＣカードは、この情報を効率よく処理し得る。従って、外部ロケーションから公開鍵を復元して、アプリケーションを認証する必要がない。
【００４１】
図９は、アプリケーションロードユニットがＩＣカードによって受け取られたときに、これを処理するための工程のフローチャートを示す。ＡＬＵを受け取る前に、所望により、ＩＣカードの同一性に関して同一性チェックが実行され得る。
ＡＬＵプロセス技術は、ロードされるアプリケーションが、（１）正しいアプリケーションプロバイダからであり、（２）意図されるカードにロードされ、（３）ＣＡによって証明されていることを検証することを含む、数々のさらなる検証を提供する。また、ＡＬＵプロセス技術は、プログラムコードおよび関連データの部分を、ＩＣカードが安全な方式で復号化できるようにする配送復号化鍵の配送を可能にする。工程９０１では、ＩＣカードがアプリケーションプロバイダからＡＬＵを受け取る。ＡＬＵは、端末接続、遠隔接続（ｃｏｎｔａｃｔｌｅｓｓ ｃｏｎｎｅｃｔｉｏｎ）、電話、コンピュータ、イントラネット、インターネット、または他の任意の通信手段を介して送信され得る。ＡＬＵは、ＩＣカードのＩ／Ｏバッファに、ＡＵ２０３、ＡＵ署名２０５、ＫＴＵ２０７、およびＡＬＣ２０９の開始アドレスを指示するヘッダ情報とともに配置される。あるいは、ＩＣカードは、これら４つのユニットの相対アドレスロケーションを決定し得る。
【００４２】
工程９０３は、ＣＡ公開鍵を備えたＡＬＣ２０９を複号化する。各ＩＣカードは、好適には、そのメモリ内にＣＡ公開鍵の複製を記憶する。これは、ＣＡ公開鍵が多くのトランスアクションに使用されるからである。あるいは、ＩＣカードは、公知の記憶ロケーションから公開鍵を取得し得る。 ＣＡ公開鍵がＡＬＣ２０９を適切に検証した場合、ＩＣカードは、ＣＡが秘密鍵によってＡＬＣ２０９に署名し、従って、アプリケーションロード証明は適切であることを検証する。ＩＣカードが、ＡＬＣを適切に検証しなかった場合、 ＡＬＣはＣＡによって署名されておらず、証明は適切でない。そこで、アプリケーションローディングプロセスは終了する。
【００４３】
次に、工程９０５が、アプリケーションロード証明において送られた識別情報に対してＩＣカードの同一性をチェックし、カードがアプリケーションを受け取ることを意図されたものであることを確実にする。この許可チェックは、上記に確認した関連特許出願に記載されている。識別データの一致が存在しない場合、アプリケーションローディングプロセスは終了する。識別データが一致する場合、プロセスは継続する。
【００４４】
工程９０７は、検証されたＡＬＣから復元されたアプリケーションプロバイダの公開鍵を用い、ＡＵ署名２０５を検証する。ＡＬＵがアプリケーションプロバイダにより作成されているとき、アプリケーションユニット２０３は、アプリケーションプロバイダの秘密鍵で署名される。次に、アプリケーションプロバイダは、ＡＬＣを介してＩＣカードに公開鍵を供給する。ひいては、ＩＣカードは、ＡＵ署名２０５を検証する。ＡＬＵが検証された場合、ＡＬＵはアプリケーションプロバイダによって作成されたとして検証される。アプリケーションプロバイダの公開鍵は、ＣＡによって署名されたＡＬＣの一部であるので、ＣＡは、適切な公開鍵がＩＣカードに供給されたことを確証する。アプリケーションプロバイダと、ＣＡと、意図されたＩＣカードとの間のこの特殊な鍵インタラクションは、安全システムの一部であるＩＣカードへの偽造、もしくは未許可のアプリケーションまたはデータが、ロードされないことを確証する。
【００４５】
次に、工程９１１が、唯一意図されたカードのみがアプリケーションを受け取ることをさらに検証するＫＴＵ認証チェックを処理する。ＫＴＵ認証チェックは、第三者が何らかにおいてＡＬＵを妨害した場合でも、第三者がＡＵの暗号部分を読み出せず、ＡＵを復号化する鍵を受け取れないことを確証する。この工程を図１０においてさらに示す。
【００４６】
図１０は、ＫＴＵ認証プロセスの工程を示す。工程１００１は、好適には任意であるので破線で示されているが、ＩＣカードの同一性を再度チェックする。識別情報は、ＫＴＵデータの一部として送られ得る。しかしながら、このチェックは既に工程９０５において実施されているので、任意である。
【００４７】
次に、工程１００３が、ＩＣカードの秘密鍵（ｍｋｄ＿ｓｋ）を用いてＫＴＵ暗号文５０３を復号化する。ＫＴＵ平文は、意図されるカードの公開鍵（ｍｋｄ＿ｐｋ）を用いて、先だって暗号化されている。これは、唯一意図されたカードの秘密鍵の保持者のみが、暗号化されたメッセージを復号化し得ることを意味する。アプリケーションプロバイダは、ＩＣカード自体から（図４およびｍｋｄ鍵セットに関する関連テキストを参照）、または公開鍵を保持するデータベースのいずれかから、意図されるＩＣカードの公開鍵を入手する。ＩＣカードがＫＴＵ暗号文を適切に復号化しない場合、ＫＴＵはそのカードには意図されておらず、アプリケーションローディングプロセスは停止する。ＩＣカードがＫＴＵ暗号文を適切に復号化した場合、プロセスは継続する。
【００４８】
工程１００５は、アプリケーションユニット（ＡＵ）の暗号化領域を識別する。図６を参照して説明したＫＴＵ平文の例では、ＩＣカードは、相対的開始アドレスおよび領域長フィールドを使用して、暗号化される部分を決定している。工程１００５も、識別された部分を暗号化するのにどの暗号化技術を用いるかを識別し、これにより、適切な復号化技術が使用され得る。例えば、この技術は単一または三重のＤＥＳにより得る。あるいは、この技術は、システムに使用され識別の必要がないデフォルト技術であり得る。
【００４９】
次に、工程１００７が、ＫＴＵ平文からの鍵を復元し、識別された部分を識別された復号化技術で復号化する。これにより、ひとたびすべての暗号化部分が復号化されれば、ＩＣカードはスタティックメモリに記憶されるＡＵの復号化された部分を有する。
【００５０】
工程１００９は、その他に任意の暗号化領域が存在する場合をチェックする。図３に記載の例では、３つの暗号化領域が存在する。暗号化領域の数は、図６の例ではフィールドである。しかしながら、部分の数は、他の従来手段を用いて決定し得る。追加の暗号化領域が存在する場合、プロセスは工程１００５に飛ぶ。追加の暗号化領域が存在しない場合、プロセスは工程１０１１から継続する。
【００５１】
次に、工程１０１１は、復号化されたＡＵをＩＣカードのメモリ内にロードする。ＡＬＵは、すべての認証および復号化チェックを通過し、ついにアプリケーションはＩＣカード上に適切に存在し、カードユーザによって実行され使用され得る。図９および図１０において、異なるチェックが特定順序で提示されたが、チェックは任意の順序で実施し得る。記載したすべての技術は、ＡＬＵに最良の安全性を提供することに関連して使用されたが、一つ以上の個別技術が、個別の目的のため、または他の従来安全技術との組み合わせで使用され得る。
【００５２】
図１１は、ＡＬＵがロードされ処理され得るＩＣカードチップのブロック図の例を示す。使用されるＩＣカード上には集積回路が配置される。ＩＣカードは、好適には、中央演算装置１１０１、ＲＡＭ１１０３、ＥＥＰＲＯＭ１１０５、ＲＯＭ１１０７、タイマ１１０９、制御ロジック１１１１、Ｉ／Ｏポート１１１３、および安全回路１１１５を含み、これらは従来のデータバスによって互いに接続されている。
【００５３】
メモリカード内の制御ロジック１１１１は、入力／出力ポートを介してカードのメモリへの読み出し／書き込みを取り扱うのに充分なシーケンスおよびスイッチングを供給する。制御ロジックを備えたＣＰＵ１１０１は、計算、メモリロケーションへのアクセス、メモリ内容の変更、および入力／出力ポートの管理を実施する。カードのなかには、暗号処理など複雑な演算を取り扱うためのコプロセッサを有するものがある。入力／出力ポート１１１３は、ＣＰＵおよび制御ロジックの制御下で、カードとカードインターフェイスデバイスの間の通信のために使用される。タイマ１１０９（クロックパルスを生成し供給する）は、メモリアクセス、メモリ読み出しまたは書き込み、処理、およびデータ通信を完成する一連の工程を介して、制御ロジック１１１１およびＣＰＵ１１０１を駆動する。タイマーは、呼び出し持続時間などのアプリケーションの特徴を供給するのに用いられ得る。セキュリティ回路１１１５は、製造中におけるテストの必要に応じて、入力／出力配線を内部回路に接続する可融性の（ｆｕｓｉｂｌｅ）接続を含んでいるが、この回路はテストの完了時に、その後のアクセスを防ぐために壊され（「溶融し（ｂｌｏｗｎ）」）、その後のアクセスを防ぐ。ＡＬＵが認証され検証された後のＡＵデータは、ＥＥＰＲＯＭ１１０５に記憶される。本明細書に記載される認証プロセスは、ＣＰＵ１１０１により実行される。
【００５４】
また、図１１は、アプリケーションプロバイダのためのおよび証明機構のための集積回路の可能な構成を示す。アプリケーションプロバイダのためのＩＣチップ内に存在するＣＰＵ１１０１は、本明細書に記載した暗号化技術を用いて必要な情報を暗号化し、必要なデータ処理を実行する。証明機構に存在するＣＰＵ１１０１は、本明細書に記載したアプリケーションロード証明に署名するのに使用される。
【００５５】
上記内容は、本願発明の原理を単に例示したものである。従って、本明細書には明示的に図示または記載しないが、本発明の原理を実施し、それにより、本発明の精神および範囲内にある多数のシステムおよび方法を、当業者が考案できることは理解される。
【００５６】
例えば、本明細書ではアプリケーションのロードを記載しているが、同等の安全ローディングプロセスを、データブロック、データファイル、ワードプロセッシング文書、または安全な方式で送信を要する他の任意のタイプのデータなど、他のタイプのデータの送信に適用し得る。
【００５７】
本開示の範囲は、請求された発明に関連するか否か、あるいは本発明で対処される課題の一部または全てを緩和するか否かに関わりなく、明示的または黙示的に開示された新規の特徴または特徴の組み合わせあるいはそれを一般化したものを含む。本出願は、本出願または本出願に由来する任意のさらなる出願の手続中に、そのような特徴に関する新しい請求項が作成され得ることの注意を促すものである。特に、付属の請求項に関しては、従属項に由来する特徴は、請求の範囲に挙げた特定の組み合わせのみならず、任意の適切な方法で独立項の特徴と組み合わせ得る。
【特許請求の範囲】
【請求項１】
本明細書に記載のシステム。
【請求項１】
本明細書に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１０−１３４９３３（Ｐ２０１０−１３４９３３Ａ）
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願番号】特願２００９−２７７０６５（Ｐ２００９−２７７０６５）
【出願日】平成２１年１２月４日（２００９．１２．４）
【分割の表示】特願平１０−５４８９３８の分割
【原出願日】平成１０年５月１４日（１９９８．５．１４）
【出願人】（５００３５６８９８）モンデックス インターナショナル リミテッド (3)
【Ｆターム（参考）】
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願日】平成２１年１２月４日（２００９．１２．４）
【分割の表示】特願平１０−５４８９３８の分割
【原出願日】平成１０年５月１４日（１９９８．５．１４）
【出願人】（５００３５６８９８）モンデックス インターナショナル リミテッド (3)
【Ｆターム（参考）】
[ Back to top ]