JP2008537370A - 無線ネットワークを使用してクレジットカード個人化を利用可能にすることができる方法、システム、及びモバイルデバイス - Google Patents

Abstract

クレジットカード個人化データを無線（ＯＴＡ）で送信することができるセキュアチャンネルを作成する方法が提供される。詳細には、汎用認証アーキテクチャ（ＧＡＡ）を使用して、ユーザ装置（ＵＥ）とネットワークアプリケーション機能（ＮＡＦ）サーバとして機能を果たす個人化アプリケーションサーバ又はビューロー間のセキュア通信チャンネルを設定することができる。ユーザ装置、個人化アプリケーションサーバ（例えばＮＡＦサーバ）、個人化アプリケーションサーバ及びユーザ装置を具現化するシステム、及びコンピュータプログラム製品もまた、クレジットカード個人化データをＯＴＡで送信することができるＧＡＡなどを介したセキュアチャンネルを作成するために提供される。
【選択図】図６

Description

本発明は、モバイル端末をクレジットカード個人化に対して利用可能にすることに関し、更に詳細には、無線ネットワークを使用してモバイル端末をクレジットカード個人化に利用可能にすることに関する。

ＭａｓｔｅｒＣａｒｄ及びＶｉｓａなどのクレジットカード会社は、現在のところクレジットカード個人化を行うためにＥＭＶ（Ｅｕｒｏｐａｙ、Ｍａｓｔｅｒｃａｒｄ、及びＶｉｓａ）クレジットカード決済規格を利用することに成功している。クレジットカード個人化とは、ＥＭＶチップを含むスマートカードなどのユーザのクレジットカードにセキュリティ及びユーザデータが送信されるプロセスのことを指す。この個人化プロセスの最初のステップは、発行者セキュリティドメインを設定する段階であり、現在では通常スマートカード製造業者の工場で行われる。セキュリティドメインは、アプリケーションデータのダウンロード及び実際の個人化を行うのに使用される個人化デバイスと、クレジットカードに埋め込まれたＥＭＶチップとの間でセキュアチャンネルを作成するのに使用される。セキュアチャンネルは、公的に容易に入手可能ではない状態で情報を送信することができるあらゆるチャンネルであり、例えば、種々の暗号化方式を使用して或いはチャンネルのエンドポイント両方を認証することによって作成することができる。セキュアチャンネルが作成されると、個人化デバイスはＥＭＶチップを起動し、最終的には個人化データをＥＭＶチップに送信することができる。クレジットカード会社は、この個人化プロセスを行うためにＯｒｇａ、Ａｘａｌｔｏ、Ｇｉｅｓｅｃｋｅ及びＤｅｖｒｉｅｎｔ、又はＣｅｄｅｘなどのスマートカード製造業者に頼ることが多い。これらの製造業者は、ユーザ固有のデータを各クレジットカードに埋め込むために、必要とされるユーザ個人化データをクレジットカード会社から受け取り、以下に説明されるステップを行う。このように、スマートカード製造業者は、クレジットカード会社に代わってクレジットカード発行者として役割を果たすことができる。

図１は、今日クレジットカード個人化を行う場合に、例えばスマートカード製造業者が行うことができるステップを示すフローチャートである。ステップ１０１で、個人化デバイスは、ＥＭＶチップにリセットコマンドを送ることによってＥＭＶチップを起動する。ステップ１０２で、ＥＭＶチップは、リセット応答（ＡＴＲ）を個人化デバイスに送ることによって応答する。次いでステップ１０３で、個人化する必要のあるアプリケーション、例えばカードに予めロードされていた特定のクレジットカードアプリケーションが選択コマンドを使用して選択される。ステップ１０４で、ＥＭＶチップは、ファイルデータ構造情報などの必要なファイル制御情報を返し、ステップ１０５で、初期化更新コマンドがＥＭＶチップに個人化デバイス乱数を提供する。この乱数は、セキュアチャンネルを設定するために暗号文作成の一部として使用される。

ステップ１０６で、チップは、シーケンスカウンタ（セッションキー導出用）、チャレンジ（暗号文作成の一部として使用される）、カード暗号文（チップを認証するのに使用される）、セッションＤＥＳ（データ暗号化標準）マスターキーの識別子及びバージョン、暗号化用導出データ、解読及びメッセージ認証コード（ＭＡＣ）ＤＥＳ（データ暗号化標準）キー、及びソースチャンネルプロトコル識別子を送ることによって応答する。

ステップ１０７で、個人化デバイスは、外部認証コマンドで暗号文を提供することによって自らをＥＭＶチップに対して認証する。次にステップ１０８で、ＥＭＶチップは外部認証を確認し、次いで、ステップ１０９で、個人化デバイスが、幾つかの格納データコマンドの１つ及び最終的には特別な最後の格納データを送出することによってデータのＥＭＶチップへの転送を開始する。最後にステップ１１０で、データ記憶が確認される。

最近では、ＭａｓｔｅｒＣａｒｄ及びＶｉｓａなどの会社が、例えばＰａｙＰａｓｓ又はＶｉｓａ Ｗａｖｅｒとして知られる新しい決済方法を導入しており、ＲＦＩＤ（無線識別）機能を有するクレジットカードが製造されている。この新しい方法では、ＲＦＩＤデバイスが小売店に備え付けられ、該ＲＦＩＤデバイスは、ユーザが読取装置の数センチメートル手前に自分のカードを置くと、これらのＲＦＩＤ対応クレジットカードを読み取ることができる。この新しい方法によってクレジットカードの決済がより早くより簡単になる。類似の近接ＲＦＩＤシステムは、Ｏｃｔｏｐｕｓ（オクトパス）又はヘルシンキ公共交通などの公共交通システムでも使用されている。例えば、ＲＦＩＤ機能を含むプリペイドのバス又は列車のカードが顧客によって購入され、バス停又は列車の駅にあるＲＦＩＤ読取装置と共に使用して、バス又は列車に乗るためのチケットを購入することができる。

種々のベンダーロケーション、並びに種々の公共交通ステーションでのＲＦＩＤ読取装置の使用は、これらの販売時点情報管理（ＰＯＳ）ＲＦＩＤ読取装置を利用できる他のタイプの決済方法の機会を与える。このような１つの決済方法によって、個人が自分の携帯電話或いは携帯電話又はＰＤＡに接続（例えば、ブルートゥース、ケーブル、ＲＦＩＤ、又は赤外線を介して）されているパーソナルデジタルアシスタント（ＰＤＡ）又はモバイルパーソナルコンピュータ（ＰＣ）などのある他のモバイルデバイスを使用して、クレジットカード又は他のユーザ固有の情報を転送することが可能になる。言い換えると、個人が、自分のクレジットカード又はプリペイド公共交通カードを使用する場合と同じ状況で自分の携帯電話を使用することができるようになる。例えば、ユーザの個人クレジットカードの詳細をモバイルデバイスに組み込み、ＰＯＳ ＲＦＩＤ読取装置に送信することができるようになる。例えば、ＰａｙＰａｓｓ及びＶｉｓａＷａｖｅに使用されるのと同じプロトコルを使用することができる。この場合、モバイルデバイスは、ＰＣに接続されることになり、ＰＣは、モバイルデバイスに必要なデータを要求し、次いで、このデータをＰＯＳに（インターネットを介して）転送することになる。

このモバイルＥＭＶシステムを実施するために、最初にシステム全体を証明する必要がある。ＥＭＶ証明は、ＥＭＶ発行者として役割を果たすことを意図する全てのスマートカード発行者が従う必要のある、ＥＭＶによって定められた高価な手続である。証明なしでは、クレジットカード会社は、内包する固有リスクを受け入れてモバイルＥＭＶソリューションを会社の決済インフラストラクチャに「接続する」可能性は低い。しかしながら、モバイルデバイスは、付加的なソフトウェアアプリケーションを実行しスマートカードよりも多くの外部インターフェースを有することができるので、スマートカードよりも遙かにオープンである。この結果、既存のモバイルデバイスハードウェア上で構築されたモバイルＥＭＶソフトウェアアプリケーションは、ＥＭＶ証明を取得しようとする場合に重大な問題に直面する可能性があり、従って、必要な証明の取得が非常に困難で費用のかかるものになる。

１つの代替の解決策は、既存のモバイルデバイスハードウェア上にモバイルＥＭＶソフトウェアアプリケーションを構築するのではなく、既に証明済みのＥＭＶチップ又はスマートカードをモバイルデバイスに組み込むことである。これを行うための１つの選択肢は、第２のスロットをモバイルデバイスに取り入れることであり、この場合、ＥＭＶチップは、例えばスマートカード製造業者で通常通り個人化し、次いで、後でユーザによってモバイルデバイスに挿入することができる。しかしながら、この方法も大量市場に対するモバイルデバイスのハードウェアコストが追加されることに起因して、極めて高価になる可能性がある。他の選択肢は、多くのアプリケーションをサポートする汎用ＩＣカード（ＵＩＣＣ）をモバイルデバイスに組み込むか、或いは、証明済みのＥＭＶチップをモバイルデバイスの製造中にデバイスに埋め込むかのいずれかになる。

しかしながら、製造中には、最終的に誰が各モバイルデバイスを所有するかが分からず、従って、通常の製造プロセス中にあらゆる決済データが完全に個人化されるのが阻止される。これは、カードの受取人がカードの発行中に既知である今日のクレジットカードビジネスとは相違する。１つの解決策は、クレジットカードに関して上述されたのと類似の方法で、製造中にモバイルデバイスにＵＩＣＣを組み込むか或いは証明済みＥＭＶチップを埋め込み、次いで、ユーザがスマートカード製造業者又は個人化ビューローに自分のモバイルデバイスを送ることを必要とし、そこで個人化を行うことができるようにすることである。しかしながら、これには、ユーザがある時間期間の間自分のモバイルデバイスをスマートカード製造業者に明け渡すことが必要になる。別の解決策では、ユーザがクレジットカードを申し込むのと同じ方法でクレジットカード機能を有する電話を申し込むことが必要である。次いで、クレジットカード機能を有する完全に個人化されたモバイルデバイスは、直接ユーザに送られることになる。しかしながら、これらの選択肢では、既存の製造プロセス及び販売網を変更することが必要になり、これらは、高コストで時間がかかることになる。

別の解決策は、ユーザが自分のモバイルデバイスを購入した後で、無線（ＯＴＡ）で個人化を行うことである。しかしながら、セキュリティデータのＯＴＡ送信には一定のリスクが内在する。上述のように、個人化プロセスを開始する前に、個人化デバイスとＥＭＶチップ又はＵＩＣＣとの間のセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する必要がある。従って、モバイルデバイスにＯＴＡでクレジットカード個人化データを送信する安全な手段、すなわち必要な発行者セキュリティドメイン及びセキュアチャンネルを作成する手段に対するニーズがある。

一般的に言えば、本発明の例示的な実施形態は、クレジットカード個人化又は公共交通チケット発券データなどの個人化データを無線（ＯＴＡ）で送信することができるセキュアチャンネルの設定のための発行者セキュリティドメインを作成する方法を提供することによって、公知の従来技術に対して改善をもたらす。詳細には、例示的な実施形態では、汎用認証アーキテクチャ（ＧＡＡ）を使用して、ユーザ装置（ＵＥ）とネットワークアプリケーション機能（ＮＡＦ）サーバとして働く個人化アプリケーションサーバ又はビューローとの間のセキュア通信チャンネルを作成するのに使用することができる共有秘密を設定することができる。

一般に、本明細書で使用されるユーザ装置とは、ユーザ装置のユーザによってリクエストされた商品又はサービスに課金する機能を組み込んだモバイルデバイス（例えば、セルラー電話、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップ、ページャーなど）を指す。例えばユーザ装置は、モバイルデバイスに埋め込まれたＥＭＶ証明済みチップ、或いはモバイルデバイスに関連したＵＩＣＣ又はスマートカードに記憶された１つ又はそれ以上のＥＭＶアプリケーションのいずれかを介してＥＭＶ機能を有するモバイルデバイスを意味することができる。１つの例示的な実施形態では、ＥＭＶアプリケーションは、ネットワークオペレータのＵＩＣＣ又はスマートカード上に記憶することができる。或いは、１つ又はそれ以上のＥＭＶアプリケーションを含む別個のＥＭＶ固有ＵＩＣＣ又はスマートカードを提供することができる。この実施形態では、モバイルデバイスは、それぞれのＵＩＣＣ（すなわち、ネットワークオペレータＵＩＣＣとＥＭＶ固有のＵＩＣＣ）に対して２つのスロットを含み、ＥＭＶ固有のＵＩＣＣ又はスマートカードは、取り除くことができ、２つのスロットを所有する別のモバイルデバイスと共に使用することができる。このようにしてユーザは、ＥＭＶ固有のＵＩＣＣ又はスマートカードをモバイルデバイスに挿入することによって異なるモバイルデバイス（例えばユーザ自身の、並びにユーザの母親、父親、姉妹などの）をクレジットカード又は公共交通チケット発券カードとして簡単に使用することができる。

例示的な実施形態において、セキュアチャンネルを介して個人化データを受信することができるユーザ装置、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバ（例えばＧＡＡが使用されているＮＡＦサーバ）、及びこのユーザ装置と個人化アプリケーションサーバを実現するシステムもまた備えられる。

従って本発明の１つの態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データの無線（ＯＴＡ）送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するための方法が提供される。１つの例示的な実施形態では、本方法は、（１）ユーザ装置及び個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する段階と、（２）１つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する段階とを含み、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる。

本発明の別の態様によれば、第１エンティティから第２エンティティにセキュアな方法で個人化データをＯＴＡで送信する方法が提供される。１つの例示的な実施形態では、本方法は、（１）汎用認証アーキテクチャ（ＧＡＡ）を使用して第１及び第２エンティティに既知の１つ又はそれ以上の共有秘密鍵を生成する段階と、（２）１つ又はそれ以上の共有秘密鍵を使用して第１と第２エンティティとの間に発行者セキュリティドメインを作成する段階と、（３）発行者セキュリティドメインを使用して第１と第２エンティティとの間にセキュアチャンネルを設定する段階と、（４）セキュアチャンネルを介して個人化データを送信する段階とを含む。

本発明の更に別の態様によれば、セキュアチャンネルを介して個人化アプリケーションサーバからの個人化データを受信することができるユーザ装置が提供される。１つの例示的な実施形態では、ユーザ装置は、該ユーザ装置に固有の少なくとも１つの秘密鍵を含むユーザ識別モジュールと、ユーザ識別モジュールと通信するセキュアコアとを含む。秘密鍵は、セキュアコア上に記憶することができる個人化アプリケーションサーバ及びユーザ装置に既知の１つ又はそれ以上の共有秘密鍵を生成するのに使用することができる。これらの共有秘密鍵は次いで、発行者セキュリティドメインを作成するのに使用され、該発行者セキュリティドメインが、ユーザ装置が個人化データを受信することができるセキュアチャンネルを設定するのに使用することができる。

本発明の別の態様によれば、モバイルクレジットカード決済システムが提供される。１つの例示的な実施形態では、本システムは、個人化アプリケーションサーバと、個人化アプリケーションサーバからユーザ装置に個人化データをＯＴＡで送信するためのセキュアチャンネルを介して個人化アプリケーションサーバと通信するユーザ装置とを含む。個人化アプリケーションサーバ及びユーザ装置に既知の１つ又はそれ以上の共有秘密鍵は、セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用することができる。

本発明の更に別の態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのシステムが提供される。１つの例示的な実施形態において、本システムは、（１）ユーザ装置及び個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する手段と、（２）１つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する手段と、を含み、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる。

本発明の更に別の態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのコンピュータプログラム製品が提供される。１つの例示的な実施形態では、コンピュータプログラム製品は、コンピュータ可読プログラムコード部分が記憶された少なくとも１つのコンピュータ可読記憶媒体を含む。コンピュータ可読プログラムコード部分は、（１）ユーザ装置及び個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成するための第１の実行可能部分と、（２）１つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する第２の実行可能部分と、を含むことができ、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる。

本発明の別の態様によれば、セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置が提供される。１つの例示的な実施形態では、このユーザ装置は、（１）ユーザ装置及び個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成するための手段と、（２）ユーザ装置に共有秘密鍵を記憶するための手段と、（３）共有秘密鍵を使用して、発行者セキュリティドメインを作成する手段とを含むことができる。発行者セキュリティドメインは、ユーザ装置が個人化データを受信することができるセキュアチャンネルを設定するのに使用することができる。１つの例示的な実施形態では、共用鍵をユーザ装置上でセキュアな環境で記憶することができる。

本発明の更に別の態様によれば、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバが提供される。１つの例示的な実施形態では、個人化アプリケーションサーバは、プロセッサと、該プロセッサと通信するメモリとを備え、該メモリは、プロセッサによって実行可能なアプリケーションを記憶する。１つの例示的な実施形態では、このアプリケーションは、実行時にセキュリティデータに対するリクエストを受信し、該リクエストに応答して認証チャレンジを送信することができ、ここでチャレンジは、共有秘密鍵を認証に使用するようにする旨のリクエストを含む。本アプリケーションは更に、実行時に共有秘密鍵を使用して暗号化された応答を受信し、該応答を検証し、検証時に共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化して、暗号化されたセキュリティデータを送信することができる。暗号化されたセキュリティデータは次に、セキュアチャンネルを設定するのに更に使用することができる発行者セキュリティドメインを作成するために使用することができる。メモリ上に記憶されたアプリケーションは更に、実行時に設定されたセキュアチャンネルを介して個人化データを送信することができる。

本発明の更に別の態様によれば、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバが提供される。１つの例示的な実施形態では、個人化アプリケーションサーバは、（１）セキュリティデータに対するリクエストを受信する手段と、（２）このリクエストに応答して、共有秘密鍵を認証に使用する旨のリクエストを含む認証チャレンジを送信する手段と、（３）共有秘密鍵を使用して暗号化された応答を受信する手段と、（４）応答を検証する手段と、（５）検証時に、共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化し、セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するために使用することができる暗号化されたセキュリティデータを送信する手段と、（６）セキュアチャンネルを介して個人化データを送信する手段とを含む。

このように本発明について概略的に説明したが、ここで、必ずしも一定の縮尺ではない添付図面について述べる。

添付図面を参照しながら本発明を以下により詳細に説明するが、該図面には本発明の全てではなく一部の実施形態が図示されている。実際、これらの発明は、多くの異なる形式で具現化することができ、本明細書に記載される実施形態に限定されるものと解釈すべきではなく、逆に、これらの実施形態は、本開示が適用される法的要件を満たすように提供される。同じ番号は全体を通して同じ要素を示す。

１つの例示的な実施形態では、クレジットカード個人化又は公共交通チケット発券データなどの個人化情報をＯＴＡでモバイルデバイスに送信するためのセキュアチャンネルを作成するのに使用することができる発行者セキュリティドメインが作成される。有利な実施形態では、この発行者セキュリティドメインは、汎用認証アーキテクチャ（ＧＡＡ）を使用して設定される。ＧＡＡは、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって提案され、「Ｇｅｎｅｒｉｃ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＡＡ：汎用認証アーキテクチャ）；システム概要（２００５年３月６日発行）（３ＧＰＰ ＴＳ３３．９１９ｖ６．２．０（２００５−０３）」と題された３ＧＰＰ技術仕様３３．９１９において説明された認証メカニズムであり、この内容は引用により全体が本明細書に組み込まれる。ＧＡＡは、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、又はモバイルＰＣ（パーソナルコンピュータ）、或いは同様のものなどのモバイルデバイスのユーザのための種々のアプリケーション及びサービスに対するセキュリティ手続として使用されることを目的とする。

ＧＡＡ及び汎用ブートストラッピング手続
ＧＡＡは、ユーザ装置（ＵＥ）に関連して提供された特定のセキュア記憶エンティティ上、並びにモバイルオペレータネットワークの加入者データベース内に記憶されている共有秘密鍵に基づく。ＵＥのセキュア記憶エンティティは、加入者識別モジュール（ＳＩＭ）又は例えばユニバーサルＳＩＭ（ＵＳＩＭ）であるＳＩＭ様アプリケーションを含み汎用ＩＣカード（ＵＩＣＣ）などの適切なセキュリティモジュール又は識別モジュールによって提供することができる。加入者データベースは、ホームロケーションレジスタ（ＨＬＲ）又はホーム加入者サーバ（ＨＳＳ）などのネットワークエンティティによって提供することができる。セキュアユーザ識別記憶エンティティ及び加入者データベースエンティティは通常、ユーザ識別を発行し、通常は加入者データベースを実行し所有するモバイルネットワークオペレータによって制御される。オペレータは、例えば、モバイルデバイスに関連するＧＡＡのアプリケーションにおいて、モバイルデバイスユーザのサービスプロバイダ（例えばＴ−Ｍｏｂｉｌｅ又はＳｐｒｉｎｔ）とすることができる。ＧＡＡ下で、ＨＳＳ又はＨＲＬ及びＵＥのセキュア記憶エンティティは、モバイルネットワークオペレータによってＨＳＳ／ＨＲＬ及びセキュア記憶エンティティに与えられ、ユーザ及びモバイルネットワークを認証するのに使用される共通の共有秘密を有する。次いで、このオペレータ所有の共有秘密は、新しいアプリケーション固有の共用鍵を導出するためにＧＡＡによって使用される。

図２は、ホーム加入者サーバ（ＨＳＳ）３０、ユーザ装置（ＵＥ）４０、及びネットワークエンティティ（ＮＥ）５０と相互関係にあるＧＡＡ環境２０の概要である。ＧＡＡ２０は、基本的に、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）２２、加入者証明書２４、及び認証プロキシ（ＡＰ）２６からなる。ＧＡＡ２０の例示的な使用は、モバイルデバイス及びアプリケーションサーバにクレデンシャル（例えば共有秘密）を提供することになり、該クレデンシャルは、後でＨＴＴＰＳ（セキュアハイパーテキスト転送プロトコル）に対して使用することができる。ＧＢＡ２２は、共有秘密に基づく種々のアプリケーションに対して汎用認証機能を提供することによって加入者証明書２４及びＡＰ２６の両方に対する基礎を構築する。ＧＢＡ機能とは通常、アプリケーションセキュリティに対する認証及び鍵共有をブートストラップすることであり、更にこれは、通常、Ｎｉｅｍｉ等による「Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ （ＨＴＴＰ） Ｄｉｇｅｓｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｕｓｉｎｇ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ （ＡＫＡ）（認証及び鍵共有（ＡＫＡ）を使用したハイパーテキスト転送プロトコル（ＨＴＴＰ）ダイジェスト認証）」（２００２年９月）と題するインターネットエンジニアリングタスクフォース（ＩＥＴＦ）、ネットワークワーキンググループ、コメントに対するリクエスト：３３１０に従うＨＴＴＰダイジェストＡＫＡ（認証及び鍵共有）メカニズムに基づいており、この内容は、引用により全体が本明細書に組み込まれる。

図３は、汎用ブートストラッピングのための例示的なネットワークモデルを示す。図に示すように、ブートストラッピングサーバ機能（ＢＳＦ）６０は、双方向リンクを介してユーザ装置（ＵＥ）４０に接続されている。ＢＳＦ６０及びＵＥ４０は、ＡＫＡプロトコルを使用して相互に認証し、セッション鍵に合意することができる。これらのセッション鍵は、後で、ユーザ装置とネットワークアプリケーション機能（ＮＡＦ）サーバ７０との間のセッションに使用することができ、該サーバは、双方向リンクによってユーザ装置４０及びＢＳＦ６０に接続されている。１つの例示的な実施形態では、ＮＡＦサーバ７０は、オペレータのシステム内に含まれる。或いは、ＮＡＦサーバ７０は単に、セキュリティクレデンシャルサービスを提供するためにオペレータと契約することができる。サードパーティネットワークの場合には、アーキテクチャは、図示されていないが「Ｇｅｎｅｒｉｃ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＡＡ：汎用認証アーキテクチャ）；Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（汎用ブートストラッピングアーキテクチャ）」（２００５年６月７日発行）（３ＧＰＰ ＴＳ３３．２２０ｖ７．０．０（２００５−０６））（以下「ＴＳ３３．２２０」）と題された３ＧＰＰ技術仕様３３．２２０に説明されるようなＤｉａｍｅｔｅｒ（ダイアメータ）−プロキシ（Ｄ−プロキシ）を含むことができ、この内容は、引用により全体が本明細書に組み込まれ、ｗｗｗ．３ｇｐｐ．ｏｒｇで見ることができる。

以下に詳細に説明されるブートストラッピング手続の後で、ユーザ装置４０及びＮＡＦ７０は、例えばクレジットカード個人化又は公共交通チケット発券アプリケーションであるアプリケーション固有プロトコルを実行することができ、ここでは、メッセージの認証及び機密保護が相互認証の間に生成されたセッション鍵に基づくことになる。従って、ＧＡＡ／ＧＢＡ２２は、一般的に、３パーティ認証ケースとして見なすことができ、ＢＳＦ６０は更に、例えばＧＢＡユーザセキュリティ設定（ＧＵＳＳ）を記憶するＨＳＳ３０又はＨＬＲに接続される。幾つかのＨＳＳが存在する場合には、ＢＳＦとＨＳＳとの間の接続はＳＬＦ（サーバロケーション機能）を利用でき、これによってＢＳＦは、適切なユーザデータを記憶するＨＳＳを見つけることができる。

図３の個々のエンティティ間の基準ポイント（インターフェース）は、Ｕｂ、Ｕａ、Ｚｎ、及びＺｈで示されている。１つの実施形態では、インターフェースＺｎ及びＺｈはダイアメータに基づく（Ｄｉａｍｅｔｅｒ Ｂａｓｅ Ｐｒｏｔｏｃｏｌ（ダイアメータベースプロトコル）に従う。これは、Ｃａｌｈｏｕｎ等による「Ｄｉａｍｅｔｅｒ Ｂａｓｅ Ｐｒｏｔｏｃｏｌ（ダイアメータベースプロトコル）」（２００３年９月）と題されたＩＥＴＦ、ネットワークワーキンググループ、コメントに対するリクエスト：３５８８で規定されており、この内容は引用により全体が本明細書に組み込まれる）。或いは、インターフェースＺｎは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に基づくことができる。インターフェースＵｂは、ＨＴＴＰダイジェストＡＫＡメッセージの再利用又はＨＴＴＰダイジェストメッセージの変形に基づき、インターフェースＵａによって使用されるプロトコルは、実行されることになるアプリケーションに依存する。訪問側ＮＡＦの場合には、付加的なＺｎ基準ポイントが挿入されることになる。

汎用ブートストラッピングアーキテクチャの利用は、２つの段階に分けることができる。図４は、第１段階、すなわちそれ自体（汎用）ブートストラッピング手続を示し、図５は、第２段階、すなわち汎用ブートストラッピング利用手続を示す。

図４に示されるように、ブートストラッピング手続の第１段階では、ユーザ装置（ＵＥ）４０がＨＴＴＰリクエストをＢＳＦ６０に送る。ステップ２で、ＢＳＦ６０は、ユーザプロファイル（Ｐｒｏｆ）及び認証ベクトル（ＡＶ）をＨＳＳ３０からＺｈインターフェースを通じて検索し、該認証ベクトルは、５つの要素、すなわち乱データ（ＲＡＮＤ）、認証トークン（ＡＵＴＮ）、予測される応答（ＸＲＥＳ）、保全鍵（ＩＫ）、及び機密鍵（ＣＫ）を含む。ＢＳＦ６０はまた、ＧＢＡユーザセキュリティ設定（ＧＵＳＳ）を検索することができる。次にステップ３で、ＢＳＦ６０は、認証パラメータＲＡＮＤ及びＡＵＴＮをＵＥ４０に転送し、ＵＥ４０が自己を認証するよう要求するようにする。ＵＥ４０は、ステップ４で認証済みネットワークからのチャレンジを検証するためにメッセージ認証コード（ＭＡＣ）を計算し、セッション鍵ＣＫ、ＩＫ、及び応答ＲＥＳを導出する。これらのセッション鍵ＣＫ、ＩＫ、及び応答ＲＥＳは、ＢＳＦ６０とＵＥ４０の両方が利用可能である。ステップ５で、ＵＥ４０は、ここではＨＴＴＰダイジェストのパスワードとして応答ＲＥＳを使用してＢＳＦ６０にリクエストを再送する。ＢＳＦ６０は、ステップ６で、受信パラメータがＲＥＳを使用して計算されており、且つＨＳＳ３０から認証ベクトルの一部として前に取得されていたＸＲＥＳを使用して同様に計算されたパラメータに等しいかどうかをチェックする。これらのパラメータが等しい場合、ＵＥ４０は認証され、ＢＳＦ６０は、ステップ７でセッション鍵ＣＫ及びＩＫを連結することによって鍵（「マスターキー」）Ｋｓを生成する。

ステップ８で、ＢＳＦ６０は、ブートストラッピングトランザクション識別子Ｂ−ＴＩＤ及び他のデータ（例えば、鍵Ｋｓの有効期間など）を含むＯＫメッセージをＵＥ４０に送り、これによって認証の成功が示される。次に、セッション鍵ＣＫとＩＫを連結することによって、鍵ＫｓがＵＥ４０で生成される（ステップ９）。この後すぐに、ユーザ装置（クライアント）４０とブートストラッピングサーバ機能（ＢＳＦ）６０との間のブートストラッピングセッションが正常に開始される。

図５は、ブートストラップされたセキュリティアソシエーションを用いた例示的な手続（すなわち第２段階）を示す。ブートストラッピングセッションを開始した後、ＵＥ４０は、ＮＡＦ７０との通信を開始することができる。これによって、ＵＥ４０及びＢＳＦ６０においてブートストラッピング手続中に生成されたマスターキーＫｓを用いて、Ｋｓ＿ＮＡＦ、又はＫｓ＿ｅｘｔ＿ＮＡＦ及びＫｓ＿ｉｎｔ＿ＮＡＦで示される１つ又は２つのＮＡＦ固有鍵（以下に説明されるように、ＵＥがＧＢＡ対応のＵＩＣＣを備えているかどうかで異なる）を導出する。ステップ１で、ＵＥ４０は、アプリケーションリクエストをＵａインターフェースを介してＮＡＦ７０に送信する。アプリケーションリクエストは、ブートストラッピング中に取得されたトランザクション識別子Ｂ−ＴＩＤ、ｍｓｇで示されるアプリケーション固有データセット、及びＭＡＣで示される全てのクレデンシャルを含む。

ステップ２で、ＮＡＦ７０は、１つ又はそれ以上の鍵と、場合によってはＵＥ４０により提供された情報に対応するユーザプロファイルデータをＺｎインターフェースを介してＢＳＦ６０にリクエストする。このようなリクエストは、例えば、トランザクション識別子に基づくことができる。ステップ２と３の間で、ＮＡＦ固有鍵Ｋｓ＿ＮＡＦ、又はＫｓ＿ｅｘｔ＿ＮＡＦ及びＫｓ＿ｉｎｔ＿ＮＡＦがＢＳＦエンティティ６０で生成される。ステップ３で、ＢＳＦ６０は、要求された１つ又は複数の鍵（ＮＡＦ固有鍵、ブートストラッピング時間、鍵の有効期間、及びＰｒｏｆで示されるユーザプロファイルのアプリケーション固有部分を含む）をＮＡＦ７０に提供することによって応答し、これをＮＡＦ７０が直接使用するか、或いはこれを用いてＮＡＦ７０が、ＵＥ４０に向けたＵａインターフェースを介して使用されるプロトコルを保護するのに必要な別の鍵を導出することができ、これはアプリケーション固有の機能であり、ＧＡＡ仕様では対処されない。このような導出は、ＵＥ４０が事前に行ったのと同じ方法で行われる。次に、ＮＡＦエンティティ７０は、少なくとも、ＮＡＦ固有鍵、ブートストラッピング時間、Ｐｒｏｆ、及び鍵の有効期間といったパラメータを記憶する。ステップ４で、ＮＡＦ７０は、アプリケーション応答をＵＥ４０に送ることによってＵａインターフェースを介して用いられたプロトコルを継続する。

汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に関する更なる詳細については、上記に引用されたＴＳ３３．２２０を参照されたい。

セキュア方式でのＯＴＡ個人化送信
本発明の例示的な実施形態は、セキュアチャンネルを介したユーザ装置（ＵＥ）への個人化データの無線（ＯＴＡ）送信を可能にする手段を提供する。上述のように、セキュアチャンネルは、公的に容易に識別され又は修正されることなく情報を転送することができる何らかのチャンネルであり、ユーザ装置は、製造中にモバイルデバイスに埋め込まれたＥＭＶ証明済みチップ、或いはモバイルデバイスに関連するＵＩＣＣ又はスマートカードに記憶された１つ又はそれ以上のＥＭＶアプリケーションのいずれかに基づくＥＭＶ機能を有するモバイルデバイスを指す。特に、例示的な実施形態は、個人化アプリケーションサーバからＵＥにクレジットカード個人データ化又は公共交通チケット発券データなどの個人化データを送信するためのセキュアチャンネルを作成するのに用いることができる発行者セキュリティドメインを設定する段階を含む。発行者セキュリティドメインは、例えば、以下に説明されるＥＭＶアプリケーションなどのモバイルデバイスによって実行される１つ又はそれ以上のアプリケーションプログラムを含む種々の手段によって設定できる。この結果、ユーザは、クレジットカード又は公共交通カードを使用する場合と同じように自分のモバイルデバイスを使用することができる。例示的な実施形態は更に、ＵＥと個人化アプリケーションサーバとの間で共有される１つ又はそれ以上の秘密鍵の生成を含み、生成された共有秘密鍵は、セキュアチャンネルを設定するのに使用される。この鍵は、例えば、以下に説明されるブートストラッピングサーバ機能（ＢＳＦ）サーバと共にＧＢＡ又はＧＢＡ＿ＵなどのＵＥによって実行される１つ又はそれ以上のアプリケーションプログラムを含む種々の手段によって生成することができる。

当業者には理解されるように、セキュアチャンネルの設定に必要な共有秘密鍵は、本発明の例示的な実施形態による種々の方法で生成することができる。単に例証の目的で、本発明の実施形態は、ＵＥとネットワークアプリケーション機能（ＮＡＦ）サーバとして動作する個人化アプリケーションサーバ又はビューローとの間で共有できる共有秘密鍵を生成するために汎用認証アーキテクチャ（ＧＡＡ）を使用するものとして説明される。しかしながら、例示的な実施形態におけるＧＡＡの使用は、どのような点でも本発明をこのＧＡＡの使用に限定するものとみなすべきではない。

本発明の１つの例示的な実施形態では、セキュアチャンネルを介して個人化データをモバイルデバイスにＯＴＡ送信できるようにするために、製造中のモバイルデバイスにブランクチップがインストールされる。共有秘密鍵のインストレーションプロセスは、エンドユーザがモバイルデバイスを所有した後に行うことができ（すなわち、発行者セキュリティドメインを作成することができる）、共有秘密鍵が生成され（例えば上述のＧＡＡ手続に従って）、次いでブランクチップに記憶される。１つの例示的な実施形態では、このブランクチップへの通信インターフェースを保護することができる。次に、ＵＥ（すなわち、モバイルデバイス＋ＥＭＶ証明済みチップ）がこれらの鍵を使用して、クレジットカード用の個人化アプリケーションサーバ（例えばＮＡＦサーバ）又は類似の個人化手続へのセキュアリンクを設定することができる。

他の例示的な実施形態では、１つ又はそれ以上のＥＭＶアプリケーションを含むＵＩＣＣ又はスマートカードは、モバイルデバイスに関連付けられる。上述のように、１つの例示的な実施形態では、製造中にモバイルデバイスに組み込まれたネットワークオペレータＵＩＣＣ又はスマートカード上にＥＭＶアプリケーションを記憶することができる。或いは、モバイルデバイスは、取り外し可能であり且つ２つのスロットを有するあらゆるモバイルデバイスと共に利用可能なＥＭＶ固有ＵＩＣＣ又はスマートカードに第２スロットを設けることができる。

従って、例示的な実施形態のシステムは、ハードウェア要素、ソフトウェア要素、又はこれらの何らかの組み合わせなど、共有秘密鍵を生成して該鍵を記憶し、鍵を使用して発行者セキュリティドメインを設定するための手段を含み、該手段は、例えばモバイルデバイス、ＢＳＦサーバ又は個人化アプリケーション（例えばＮＡＦ）サーバに埋め込まれ、以下で詳細に説明される。このような説明がなされていない他のこうした手段はまた、本発明の例示的な実施形態の精神から逸脱することなく、これらの機能を実行するのに使用することができる。

図６は、本発明の例示的な実施形態に従って動作することができるＵＥのブロック図である。ＵＥは、以下に説明されるようなＥＭＶ機能を有する、例えば携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、ページャー、パーソナルコンピュータ（ＰＣ）、ラップトップ、タブレット、又は他のいずれかの類似のデバイスなどのモバイルデバイスを含むことができる。図示のように、ＵＥは、少なくともセキュアコア６１０、ＵＩＣＣ（汎用ＩＣカード）６２０、ＥＭＶアプリケーション６３２、及びＧＢＡアプリケーション６３４からなることができる。セキュアコア６１０は、モバイルデバイスの中心又は最も内側の部分である必要はなく、本明細書で説明されるように機能することができるいずれかの１つ又は複数の要素を単に表わすものであって、製造中にインストールされ、生成された共有秘密鍵６１２を記憶することができるブランクチップ、並びに決済又はチケット発券のためにＵＥの使用を可能にするためにユーザによって或いはユーザに代わってインストールされた１つ又はそれ以上の決済又はチケット発券アプリケーション６１４からなることができる。

ＵＩＣＣ６２０は、これが配置されるモバイルデバイスのユーザに固有の識別情報６２６を記憶するユーザ識別モジュールを含むことができる。ユーザ識別モジュールは、実際にはモジュラーである必要はない。言い換えると、ユーザ識別モジュール内に記憶されている識別情報は、１つのモジュラーエンティティの一部として記憶する必要はなく、代わりに、モバイルデバイス全体に分散されてもよい。この識別情報６２６は、ＧＡＡ手続（又は共有秘密鍵インストレーションプロセス）中に使用して、ＢＳＦサーバに対してＵＥを識別することができる。１つの実施形態では、ＵＩＣＣ６２０は更にＥＭＶ＿Ｕ６２２及びＧＢＡ＿Ｕ６２４アプリケーションを含み、これらはまた、ＵＩＣＣ６２０とＮＡＦサーバとの間にセキュアリンクを設定するために共有秘密鍵インストレーションプロセスにおいて使用される。詳細には、ＧＢＡ＿Ｕアプリケーション６２４を用いてＮＡＦ固有鍵を生成することができ、該固有鍵を用いて、モバイルネットワークオペレータとＵＩＣＣ６２０との間で共有される秘密鍵（すなわちＣＫ及びＩＫ）に基づいて、ＵＥをＮＡＦサーバに対して認証するか、或いは２つの間の通信をセキュアにすることができる。１つの実施形態では、ＵＥは、ＵＩＣＣ６２０においてＧＢＡ＿Ｕアプリケーション６２４を含まない場合がある。この場合、鍵生成及び記憶機能は、ＵＥのＧＢＡアプリケーション６３４によって行われ、ＵＩＣＣは必要な情報を配信するだけである。１つの実施形態では、ＥＭＶ＿Ｕアプリケーションは、共有秘密鍵インストレーションプロセスの進行をモニターするのに使用される状態機械を含む。この実施形態では、インストレーションプロセスが中断された場合、状態機械は、インストレーションを再開する必要があることを指示する。ＵＥがＧＢＡ＿Ｕアプリケーションを含まない場合、ＥＭＶ＿Ｕアプリケーションはまた、モバイル端末に常駐し、ＵＩＣＣには常駐しない。

ＵＥに含まれるＥＭＶアプリケーション６３２は、ＵＥの外部にあるエンティティ（例えばＮＡＦ及びＢＳＦサーバ）と、ＵＩＣＣ６２０及びセキュアコア６１０との間の通信を可能にすることによって通信エンティティとして動作する。例えば、共有秘密鍵インストレーションプロセスにおいて、ＥＭＶアプリケーション６３２は、以下に詳細に説明されるように、ＮＡＦサーバに発行者セキュリティドメイン鍵を要求し、これらを解読するためにＵＩＣＣ６２０に渡し、更にこれらの鍵をセキュアコア６１０上に記憶する役割を果たす。上述のように、ＵＩＣＣ６２０内にＧＢＡ＿Ｕアプリケーション６２４が存在しない１つの実施形態では、ＵＥにあるＧＢＡアプリケーション６３４が、以下に説明される鍵生成及び記憶機能を実行する。

図７Ａは、クレジットカード用にＵＥを準備する場合、或いは類似の個人化、すなわちセキュリティ及びユーザデータをＵＥに送信することができるセキュア通信チャンネルを設定するのに用いることができる発行者セキュリティドメインを作成する場合の例示的な実施形態において実行されるステップを示す信号フロー図である。第１のステップで、ＥＭＶアプリケーション（モバイル／ユーザデバイス（ＵＥ）に常駐している）は、ＮＡＦサーバ（すなわち、オペレータによってホストされるか或いはオペレータとビジネス関係にある個人化ビューロー）に付加的なセキュリティデータをリクエストする。付加的なセキュリティデータは、実際の個人化プロセスに後で使用され、例えば暗号化鍵及び／又はＭＡＣ（メッセージ認証コード）鍵とすることができる発行者セキュリティドメイン鍵を表わす。ステップ２で、ＮＡＦサーバは、認証チャレンジをＥＭＶアプリケーションに返し、ＥＭＶアプリケーションがＧＡＡ共有秘密方法を使用して自らを認証するようリクエストする。次にステップ３で、ＵＥのＥＭＶアプリケーションは、ＵＥに同様に位置付けられたＧＢＡアプリケーションにＧＡＡ共有秘密をリクエストする。

ステップ４で、共有秘密は、上記に詳細に説明されたブートストラッピング手続を使用して設定される。ＵＥのＧＢＡアプリケーション、ＵＩＣＣのＧＢＡ＿Ｕアプリケーション、及びブートストラッピングサーバ機能（ＢＳＦ）サーバは各々、このプロセスに含まれる。この手続の最後で鍵が生成される（ＧＢＡ＿ＵがＵＩＣＣによってサポートされる場合、Ｋｓ＿ｅｘｔ＿ＮＡＦ及びＫｓ＿ｉｎｔ＿ＮＡＦ、そうでない場合はＫｓ＿ＮＡＦ）。Ｋｓ＿ｉｎｔ＿ＮＡＦ及び／又はＫｓ＿ｅｘｔ＿ＮＡＦは、ＧＢＡ＿Ｕアプリケーション及びＢＳＦの両方に既知である。ＧＢＡ＿Ｕが使用されない場合、ＢＳＦはＫｓ＿ＮＡＦを認知しており、ＮＡＦはこれらの鍵をＢＳＦにリクエストすることができる。ＵＥは、Ｋｓ＿ｅｘｔ＿ＮＡＦとＫｓ＿ＮＡＦのみを認知している。共有秘密が設定されると、ＧＢＡアプリケーションは、ステップ５で、Ｋｓ＿ｅｘｔ＿ＮＡＦをＵＥのＥＭＶアプリケーションに与える（或いは、ＧＢＡ手続がＵＥのみに依存する場合には、ＵＥは既にＫｓ＿ＮＡＦを有している）。ステップ６で、ＥＭＶアプリケーションは、Ｋｓ＿ｅｘｔ＿ＮＡＦ又はＫｓ＿ＮＡＦを使用してＮＡＦサーバの認証チャレンジへの応答をＮＡＦサーバに返す。

ステップ７で、ＮＡＦサーバは、ＢＳＦサーバからＮＡＦ固有鍵（すなわちＫｓ＿ｅｘｔ＿ＮＡＦ及びＫｓ＿ｉｎｔ＿ＮＡＦ、又はＫｓ＿ＮＡＦ）をフェッチする。次いでステップ８で、ＮＡＦサーバは認証応答を検証し、例えばＫｓ＿ｉｎｔ＿ＮＡＦ又はＫｓ＿ＮＡＦを使用して付加的なセキュリティデータを暗号化し、暗号化されたデータをＵＥのＥＭＶアプリケーションに転送する。しかしながら、ＥＭＶアプリケーションは、Ｋｓ＿ｉｎｔ＿ＮＡＦで暗号化された受信データを解読することができない。一方では、データがＫｓ＿ＮＡＦで暗号化された場合には、ＵＥはこれを解読することができ、ステップ１１でセキュリティデータのインストレーションに進むことになる点に留意されたい。ＵＥが受信されたデータを解読できないと仮定すると、ステップ９で、ＥＭＶアプリケーションは、暗号化された付加的なセキュリティデータ（すなわち発行者セキュリティドメイン鍵）をＵＩＣＣ上のＥＭＶ＿Ｕアプリケーションに渡す。ＵＥでのセキュリティオペレーションは、セキュアな環境又は信頼できるプラットフォームにおいて実行することができる。

ステップ１０で、ＥＭＶ＿Ｕアプリケーションは、メッセージを解読するために必要なＫｓ＿ｉｎｔ＿ＮＡＦ鍵をＥＭＶ＿Ｕが持たないので、暗号化された付加的なセキュリティデータ（すなわち発行者セキュリティドメイン鍵）をＧＢＡ＿Ｕに与える。ＧＢＡ＿Ｕアプリケーションは、ステップ１１でデータを解読し、これをＥＭＶ＿Ｕアプリケーションに返す。或いは、ステップ１０及び１１で、ＥＭＶ＿Ｕアプリケーションは、ＧＢＡ＿ＵアプリケーションにＫｓ＿ｉｎｔ＿ＮＡＦ鍵をリクエストすることができる。Ｋｓ＿ｉｎｔ＿ＮＡＦ鍵を受け取ると、ＥＭＶ＿Ｕアプリケーションは自らデータを解読することができる。これによって、ＵＩＣＣ上でのＥＭＶ＿Ｕアプリケーションが付加的なセキュリティデータのインストレーション及び発行者セキュリティドメインの作成を行うことが可能となる。付加的なセキュリティデータ、例えば鍵、鍵の有効期間、鍵生成時間、及び／又はＢ−ＴＩＤは、セキュアコア上に発行者セキュリティドメインを作成するのに使用される。次いで、この発行者セキュリティドメインを用いて、決済アプリケーションデータ、クレジットカード個人化データ、又は同様のものなどのアプリケーション固有のセキュリティドメインを記憶することができる。

インストレーションプロセスが図７Ｂに示されており、ＥＭＶ＿ＵがＵＥ内のＥＭＶアプリケーションに解読された付加的なセキュリティデータを渡すステップ１１ａから始まる。次いで、ＥＭＶアプリケーションは、ステップ１１ｂで、付加的なセキュリティデータを使用してセキュアコア上に発行者セキュリティドメインを作成することができる。ステップ１１ｃで、発行者セキュリティドメインの成功した作成の確認が、セキュアコアからＵＥ内のＥＭＶアプリケーションに送られる。最後に、任意選択であるステップ１１ｄで、ＥＭＶアプリケーションがＥＭＶ＿Ｕに発行者セキュリティドメインの成功した作成を確認する。

図７Ａ及び７Ｂに示されるステップ１２で、ＥＭＶ＿Ｕアプリケーションは、任意選択的であるが、成功（又は失敗）メッセージをＵＥ上のＥＭＶアプリケーションに返す。次いで、ＥＭＶアプリケーションは、ステップ１３（図７Ｂには示されていない）でこの成功（又は失敗）メッセージをＮＡＦサーバに返す。１つの実施形態では、ＥＭＶ及びＥＭＶ＿Ｕアプリケーションの両方によって返された成功メッセージは、送信側の真正性を与えるためにＮＡＦ固有鍵を使用して暗号化される。最後に、同様に任意選択であるステップ１４（図７Ｂには示されていない）で、ＮＡＦサーバは成功メッセージに対する肯定応答を返す。

幾つかの実施形態では、セキュアチャンネルプロトコル２（ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂａｌＰｌａｔｆｏｒｍ．ｏｒｇ／ｓｐｅｃｉｆｉｃａｔｉｏｎｖｉｅｗ．ａｓｐ？ｉｄ＝ｃａｒｄで入手可能な、グローバルプラットフォームカード仕様バージョン２．１．１を参照、本内容は、引用により全体が本明細書に組み込まれる）、ＴＬＳ、事前共用鍵（ＰＳＫ）ＴＬＳ、ＩＰＳｅｃ又はＨＴＴＰダイジェストなどの付加的なセキュリティプロトコルは、上述されたプロセスの幾つかのステップにおいてＧＡＡと共に使用することができる。セキュリティドメイン鍵は、個人化データのダウンロードをセキュアにするためのセキュアチャンネルプロトコル２によって使用することができる。ＮＡＦ固有鍵はまた、例えばＰＳＫ ＴＬＳを使用して通信チャンネルをセキュアにするのに使用することができる。

上記のステップの終わりで、クレジットカード個人化データ又は公共交通チケット発券データなどの個人化データをセキュアチャンネルがＵＥにＯＴＡで送信することができるように共用鍵が設定され、これによってＵＥは、例えばユーザのクレジットカード又はプリペイド公共交通カードとして機能を果たすことができるようになる。

例示的な使用のケース
図８−１１は、本発明の例示的な実施形態によるクレジットカード個人化のためのモバイルデバイスを準備するための４つの段階を示すフローチャートである。これらの段階のステップは、本質的には例示的なものに過ぎず、各状況において当てはまる場合もあればそうでない場合もある幾つかの仮定に基づいている。例えば、以下の例証では、モバイルデバイスユーザは、該ユーザが例えば自分のパーソナルコンピュータ（ＰＣ）を使用しているいずれかの場所からアクセスできるパーソナルインターネットバンキングアカウントを有していると仮定する。このインターネットバンキングアカウントを介して、ユーザは自分のモバイルデバイスにクレジットカード機能を使用することができるようにリクエストする。しかしながら、インターネットバンキングアカウントなどを持たないモバイルデバイスユーザでも、本発明の使用を禁じられてはいない。これらのユーザは、例えばメール又はファクシミリを介して利用可能性をリクエストすることができる。

図８に示される段階１では、ユーザは、例えばクレジットカード又は公共交通チケット発券カードとして自分のモバイルデバイスを利用可能にすることを決定し、すなわち、ユーザは、製造中の自分のモバイルデバイスにインストールされたセキュアコア／チップを利用可能にするプロセスを開始する。ステップ８０１で、ユーザは、自分のＰＣを使用して自分のインターネットバンキングアカウントにアクセスし、自分のモバイルデバイスを利用可能にすることを選択する。ステップ８０２で、ユーザは、自分の電話番号を入力するよう促されて入力する。図１２及び１３は、クレジットカード機能に対して自分のモバイルデバイスを利用可能にするよう選択した場合にユーザが見ることのできる例示的なウェブページを示す。ステップ８０３で、ユーザが口座を持っている金融機関、すなわち銀行このリクエストを受け取り、モバイルデバイスを利用可能にすることに同意する。最後にステップ８０４で、金融機関は、個人化アプリケーションサーバ又はビューロー（例えば、ＧＡＡが使用される場合にＮＡＦサーバとして働く）と連絡を取り、必要なユーザデータを個人化アプリケーションサーバに送信する。このユーザデータは、例えば、ユーザの名前、個人化コード、又はＰＩＮ、電話番号などを含むことができる。

図９に示される段階２では、発行者セキュリティドメイン鍵がユーザのモバイルデバイスにインストールされたセキュアコード／チップに無線（ＯＴＡ）で提供される。１つの実施形態では、セキュアチップは、シリアルナンバーのみによって製造中に初期化される。或いは、発行者セキュリティドメインクレデンシャルが発行時にセキュアコア／チップ上に既に配置させることができる。この実施形態では、段階２は完全に無排除され、図では以下に説明される段階３に直接進む。しかしながら、セキュアチップがシリアルナンバーだけを有すると仮定すると、段階２は、ステップ９０１で始まり、ここでは、金融サーバがＮＡＦサーバに対して、モバイルデバイスがＧＡＡ及び共有秘密法を使用する旨のリクエストを通知する。このステップは、例えばＷＡＰプッシュ、ＯＭＡデバイス管理手段、ＳＭＳ、又はＨＴＴＰメッセージを電話へのローカル接続を有するＰＣに送ることによって、或いはユーザがその番号に電話をかけるか又は専用ウェブサイトを閲覧するようリクエストすることによって行われる。

ステップ９０２で、共有秘密は、上述の方法でモバイルデバイスのＵＩＣＣとＢＳＦサーバとの間に設定される。次にステップ９０３で、ＮＡＦサーバは、ＢＳＦサーバからの共有秘密をリクエストする。ステップ９０４で、ＵＩＣＣは、後でＵＥを介してセキュアコアに与えられる新しい秘密鍵を取得する。１つの実施形態では、ＢＳＦサーバはまたこの秘密鍵を導出する。次にステップ９０５で、ユーザのモバイルデバイス上のセキュアコア／チップは、共有秘密鍵を記憶する。セキュアコアはここで、セキュリティ発行者ドメイン鍵として使用することができる秘密鍵を有する。

図１０に示される段階３では、セキュリティドメインは、非接触型決済又はチケット発券アプリケーション用のユーザのモバイルデバイスのセキュアコアに提供される。ステップ１００１で、例えば図７Ａ及び７Ｂに示されるように生成され記憶されたセキュリティ発行者ドメイン鍵を使用して、セキュアコアとＮＡＦサーバとの間にセキュアトンネルが設定される。モバイルデバイスは、例えばＨＴＴＰ又はＧＰＲＳ（汎用パケット無線サービス）を使用してこのトンネルの設定をサポートする。このトンネルは、ステップ１００２でセキュリティドメインデータをセキュアコアにダウンロードするのに使用される。最後にステップ１００３で、セキュアコアは、非接触型決済又はチケット発券アプリケーション用のセキュリティドメインを設定する。

図１１に示される最後の段階である段階４は、決済アプリケーション（例えばモバイルクレジットカード個人化）のダウンロードを表わす。ステップ１１０１で、ユーザは、自分のＰＣでアクセスしたウェブサイト上で個人化コードを受け取る。次いでステップ１１０２で、ＮＡＦサーバ又は個人化ビューローは、例えばＷＡＰプッシュを使用してＵＲＬをユーザにプッシュし、ユーザに自分のモバイルデバイスを使用して当該ＵＲＬを閲覧するように指示する。ステップ１１０３で、ユーザは受け取ったＵＲＬを閲覧し、受け取った個人化コードを自分のモバイルデバイスに挿入して、妥当性確認のためにこれをＮＡＦサーバに送るように促される。ステップ１１０４で、ＮＡＦサーバは、段階２で設定されたセキュリティドメイン鍵によって暗号化された個人化コードをセキュアコアにプッシュする。ステップ１１０５で、モバイルデバイスは、セキュアコアを個人化し（すなわち、アプリケーション固有のセキュリティドメインを作成し、公共交通チケット又はクレジットカード番号などの個人ユーザデータを当該ドメインに入れる）、金融機関及び／又はＮＡＦサーバにセキュアコアの正しい初期化を確認する。最後に、ステップ１１０６及び１１０７それぞれにおいて、端末決済アプリケーション及びセキュアコア決済アプリケーションがダウンロードされインストールされる。図１４は、上記のステップを実行した場合にユーザが自分のモバイルデバイス上で見ることのできる例示的な画面を示す。これ以降、ユーザは、自分のモバイルデバイスを利用してＲＦＩＤ通信などを介してカードリーダーと対話することができ、クレジット又はデビットカードと同様の方法で商品又はサービスを購入し、或いは公共交通チケットの決済を行うことができる。

結論
上述され並びに当業者によって理解されるように、本発明の実施形態は、システム、方法、モバイルデバイス又は他の装置、或いはコンピュータプログラム製品として構成することができる。従って、本発明の実施形態は、完全にハードウェアだけ、完全にソフトウェアだけ、或いはソフトウェア及びハードウェアのあらゆる組合せを含む種々の手段から構成することができる。更に、本発明の実施形態は、記憶媒体に組み込まれたコンピュータ可読プログラム命令（例えばコンピュータソフトウェア）を有するコンピュータ可読記憶媒体上のコンピュータプログラム製品の形式を取ることができる。ハードディスク、ＣＤ−ＲＯＭ、光記憶デバイス、又は磁気記憶デバイスを含むあらゆる適切なコンピュータ可読記憶媒体を利用することができる。

本発明の例示的な実施形態について、方法、装置（すなわちシステム）、及びコンピュータプログラム製品のブロック図及びフローチャートを参照しながら上記で説明してきた。ブロック図の各ブロック及びフローチャート図、並びにブロック図のブロックとフローチャート図との組み合わせはそれぞれ、コンピュータプログラム命令を含む種々の手段によって実施することができる。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置にロードして、コンピュータ又は他のプログラム可能データ処理装置上で実行される命令が、１つ又は複数のフローチャートブロックにおいて指定された機能を実施するための手段を生成するような機械をもたらす。

これらのコンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理装置に特定の方法で機能するよう指示できるコンピュータ可読メモリ内に記憶することができ、これによってコンピュータ可読メモリ内に記憶された命令は、１つ又は複数のフローチャートブロックにおいて指定される機能を実施するためのコンピュータ可読命令を含む製造物品を生成する。コンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理装置にロードし、コンピュータ又は他のプログラム可能装置上で一連の動作ステップを行わせ、コンピュータ又は他のプログラム可能装置上で実行される命令が１つ又は複数のフローチャートブロックで指定される機能を実施するためのステップを提供するようにコンピュータ実装プロセスを生成することができる。

従って、ブロック図のブロック及びフローチャート図は、指定された機能を実行する手段の組み合わせ、指定された機能を実行するステップの組み合わせ、及び指定された機能を実行するプログラム命令手段の組み合わせをサポートする。ブロック図の各ブロック及びフローチャート図、並びにブロック図のブロックとフローチャート図の組み合わせが、指定された機能又はステップ、或いは専用ハードウェア及びコンピュータ命令の組み合わせを行う専用ハードウェアベースのコンピュータシステムによって実現できる。

本明細書に記載される本発明の多くの修正形態及び他の実施形態は、これらの発明が上記の説明及び関連の図面で提示された教示の利益を有することが本発明の関連する当業者には想起されるであろう。従って、本発明は、開示された特定の実施形態に限定されるものではなく、当該修正及び他の実施形態は、添付の請求項の範囲に含まれるものとすることを理解されたい。特定の用語を本明細書で用いているが、これらは一般的且つ説明的な意味でのみ使用されており、限定を目的とするものではない。

クレジットカードの個人化を行う従来技術のステップを示すフローチャートである。 従来技術による汎用認証アーキテクチャ環境の概要を示す図である。 従来技術による汎用ブートストラッピングのためのネットワークモデルを示す図である。 従来技術による汎用ブートストラッピング手続を示す図である。 従来技術による汎用ブートストラッピング使用手続を示す図である。 本発明の例示的な実施形態による動作可能なユーザ装置を示すブロック図である。 本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備する場合に行われるステップを示す信号フロー図である。 本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備する場合に行われるステップを示す信号フロー図である。 本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための４つの段階を示すフローチャートである。 本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための４つの段階を示すフローチャートである。 本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための４つの段階を示すフローチャートである。 本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための４つの段階を示すフローチャートである。 本発明の例示的な実施形態によるクレジットカード機能に自分のユーザ装置を利用可能にするように選択する場合にユーザが見ることのできる例示的なウェブページを示す図である。 本発明の例示的な実施形態によるクレジットカード機能に自分のユーザ装置を利用可能にするように選択する場合にユーザが見ることのできる例示的なウェブページを示す図である。 本発明の例示的な実施形態によるクレジットカード機能を利用可能にする場合にユーザが自分のユーザ装置で見ることのできる例示的な画面を示す図である。

符号の説明

６１０ セキュアコア
６１２ 共有秘密鍵
６１４ １つ又はそれ以上の決済又はチケット発券アプリケーション
６２０ ＵＩＣＣ
６２２ ＥＭＶ＿Ｕアプリケーション
６２４ ＧＢＡ＿Ｕアプリケーション
６２６ ユーザに固有の識別情報
６３２ ＥＭＶアプリケーション
６３４ ＧＢＡアプリケーション

Claims (39)

1. 個人化アプリケーションサーバからユーザ装置への個人化データの無線（ＯＴＡ:over the air）送信のためのセキュアチャンネル(secure channel)を設定するのに使用することができる発行者セキュリティドメインを作成する方法であって、前記方法は、
   前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する段階と、
   前記１つ又はそれ以上の共有秘密鍵を使用して、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する段階と、
   を含む方法。
2. 前記ユーザ装置は、ＥＭＶ証明済みチップが埋め込まれたモバイルデバイスを含む、
   ことを特徴とする請求項１に記載の方法。
3. 前記ユーザ装置は、１つ又はそれ以上のＥＭＶアプリケーションを記憶している汎用ＩＣカード（ＵＩＣＣ）を更に含むモバイルデバイスを含む、
   ことを特徴とする請求項１に記載の方法。
4. 前記ＵＩＣＣは、前記モバイルデバイスから取り除くことができ、別のモバイルデバイスと共に使用することができる、
   ことを特徴とする請求項３に記載の方法。
5. 前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する段階は、汎用認証アーキテクチャ（ＧＡＡ）に従って行われ、前記個人化アプリケーションサーバは、ネットワークアプリケーション機能（ＮＡＦ）サーバを含む、
   ことを特徴とする請求項１に記載の方法。
6. 前記１つ又はそれ以上の共有秘密鍵を前記ユーザ装置上に記憶する段階を更に含む、
   ことを特徴とする請求項１に記載の方法。
7. 前記個人化データは、クレジットカード個人化データを含む、
   ことを特徴とする請求項１に記載の方法。
8. 前記個人化データは、公共交通チケット発券データを含む、
   ことを特徴とする請求項１に記載の方法。
9. 第１エンティティから第２エンティティにセキュアな方法で個人化データを無線（ＯＴＡ）で送信する方法であって、
   汎用認証アーキテクチャ（ＧＡＡ）を使用して前記第１及び前記第２エンティティに既知の１つ又はそれ以上の共有秘密鍵を生成する段階と、
   前記１つ又はそれ以上の共有秘密鍵を使用して前記第１と前記第２エンティティとの間に発行者セキュリティドメインを作成する段階と、
   前記発行者セキュリティドメインを使用して前記第１と前記第２エンティティとの間にセキュアチャンネルを設定する段階と、
   前記セキュアチャンネルを介して前記個人化データを送信する段階と、
   を含む方法。
10. 前記第１エンティティはネットワークアプリケーション機能（ＮＡＦ）サーバであり、前記第２エンティティはユーザ装置である、
    ことを特徴とする請求項９に記載の方法。
11. 前記ユーザ装置は、ＥＭＶ証明済みチップが埋め込まれたモバイルデバイスを含む、
    ことを特徴とする請求項９に記載の方法。
12. 前記ユーザ装置は、１つ又はそれ以上のＥＭＶアプリケーションを記憶した汎用ＩＣカード（ＵＩＣＣ）を更に含むモバイルデバイスを含む、
    ことを特徴とする請求項９に記載の方法。
13. 前記ＵＩＣＣは、前記モバイルデバイスから取り外すことができ、且つ別のモバイルデバイスと共に使用することができる、
    ことを特徴とする請求項１２に記載の方法。
14. 前記個人化データは、クレジットカード個人化データを含む、
    ことを特徴とする請求項９に記載の方法。
15. 前記個人化データは、公共交通チケット発券データを含む、
    ことを特徴とする請求項９に記載の方法。
16. セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置であって、前記ユーザ装置は、
    前記ユーザ装置に固有の少なくとも１つの秘密鍵を含むユーザ識別モジュールと、
    前記ユーザ識別モジュールと通信するセキュアコア(secure core)と、
    を備え、
    前記秘密鍵は、前記セキュアコア上に記憶されることになる、前記個人化アプリケーションサーバ及び前記ユーザ装置に既知の１つ又はそれ以上の共有秘密鍵を生成するのに使用され、前記１つ又はそれ以上の共有秘密鍵は、発行者セキュリティドメインを作成するのに使用され、該発行者セキュリティドメインが、前記ユーザ装置が前記個人化データを受信することができる前記セキュアチャンネルを設定するのに使用される、
    ことを特徴とするユーザ装置。
17. 前記１つ又はそれ以上の共有秘密鍵は、汎用認証アーキテクチャ（ＧＡＡ）に従って生成され、前記個人化アプリケーションサーバは、ネットワークアプリケーション機能（ＮＡＦ）サーバを含む、
    ことを特徴とする請求項１６に記載のユーザ装置。
18. コンピュータ可読媒体に記憶され、前記ユーザ識別モジュール及び前記セキュアコアと通信する１つ又はそれ以上のＧＡＡサポーティングアプリケーションを更に備え、
    前記ＧＡＡサポーティングアプリケーションは、前記１つ又はそれ以上の共有秘密鍵を生成するために前記ＮＡＦサーバ及びブートストラッピングサーバ機能（ＢＳＦ）サーバと通信するように構成されている、
    ことを特徴とする請求項１７に記載のユーザ装置。
19. 前記個人化データは、クレジットカード個人化データを含む、
    ことを特徴とする請求項１６に記載のユーザ装置。
20. 前記個人化データは、公共交通チケット発券データを含む、
    ことを特徴とする請求項１６に記載のユーザ装置。
21. 個人化アプリケーションサーバと、
    前記個人化アプリケーションサーバから無線（ＯＴＡ）で個人化データを送信するためのセキュアチャンネルを介して前記個人化アプリケーションサーバと通信するユーザ装置と、
    を備え、
    前記個人化アプリケーションサーバ及び前記ユーザ装置に既知の１つ又はそれ上の共有秘密鍵が、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用される、
    ことを特徴とするモバイルクレジットカード決済システム。
22. 前記１つ又はそれ以上の共有秘密鍵が、汎用認証アーキテクチャ（ＧＡＡ）に従って作成され、前記個人化アプリケーションサーが、ネットワークアプリケーション機能（ＮＡＦ）サーバを含む、
    ことを特徴とする請求項２１に記載のシステム。
23. 前記１つ又はそれ以上の共有秘密鍵が、前記ユーザ装置上に記憶される、
    ことを特徴とする請求項２１に記載のシステム。
24. 前記ユーザ装置が、ＥＭＶ証明済みチップが埋め込まれたモバイルデバイスを含む、
    ことを特徴とする請求項２１に記載のシステム。
25. 前記ユーザ装置が、１つ又はそれ以上のＥＭＶアプリケーションが記憶された汎用ＩＣカード（ＵＩＣＣ）を更に含むモバイルデバイスを備える、
    ことを特徴とする請求項２１に記載のシステム。
26. 前記ＵＩＣＣが、前記モバイルデバイスから取り除くことができ、且つ別のモバイルデバイスと共に使用することができる、
    ことを特徴とする請求項２５に記載のシステム。
27. 前記ＮＡＦサーバ及び前記ユーザ装置と通信するブートストラッピングサーバ機能（ＢＳＦ）サーバを更に備え、
    前記ＢＳＦが、前記１つ又はそれ以上の共有秘密鍵の生成を可能にする、
    ことを特徴とする請求項２２に記載のシステム。
28. 個人化アプリケーションサーバからユーザ装置への個人化データの無線（ＯＴＡ）送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのシステムであって、前記システムは、
    前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する手段と、
    前記１つ又はそれ以上の共有秘密鍵を使用して、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する手段と、
    を含むシステム。
29. 前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する前記手段が、汎用認証アーキテクチャ（ＧＡＡ）に従って前記１つ又はそれ以上の共有秘密鍵を生成する手段を含み、
    前記個人化アプリケーションサーバが、ネットワークアプリケーション機能（ＮＡＦ）サーバを含む、
    ことを特徴とする請求項２８に記載のシステム。
30. 前記ユーザ装置上に前記１つ又はそれ以上の共有秘密鍵を記憶する手段を更に含む、
    ことを特徴とする請求項２８に記載のシステム。
31. 個人化アプリケーションサーバからユーザ装置への個人化データの無線（ＯＴＡ）送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品が、コンピュータ可読プログラムコード部分が記憶された少なくとも１つのコンピュータ可読記憶媒体を含み、前記コンピュータ可読プログラムコード部分が、
    前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成するための第１実行可能部分と、
    前記１つ又はそれ以上の共有秘密鍵を使用して、発行者セキュリティドメインを作成するための第２実行可能部分と、
    を含み、
    前記発行者セキュリティドメインが、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる、
    ことを特徴とするコンピュータプログラム製品。
32. 前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する段階が、汎用認証アーキテクチャ（ＧＡＡ）に従って前記１つ又はそれ以上の共有秘密鍵を生成する段階を含み、前記個人化アプリケーションサーバが、ネットワークアプリケーション機能（ＮＡＦ）サーバを含む、
    ことを特徴とする請求項３１に記載のコンピュータプログラム製品。
33. 前記ユーザ装置上に前記１つ又はそれ以上の共有秘密鍵を記憶するための第３実行可能部分を更に含む、
    ことを特徴とする請求項３１に記載のコンピュータプログラム製品。
34. セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置であって、前記ユーザ装置が、
    前記ユーザ装置及び前記個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する手段と、
    前記１つ又はそれ以上の共有秘密鍵を前記ユーザ装置に記憶する手段と、
    前記１つ又はそれ以上の共有秘密鍵を使用して、発行者セキュリティドメインを作成する手段と、
    を備え、
    前記発行者セキュリティドメインが、前記ユーザ装置が前記個人化データを受信することができる前記セキュアチャンネルを設定するのに使用することができる、
    ことを特徴とするユーザ装置。
35. セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバであって、前記個人化アプリケーションサーバが、
    プロセッサと、
    前記プロセッサによって実行可能なアプリケーションを記憶する前記プロセッサと通信するメモリと、
    を備え、
    前記アプリケーションが、実行時にセキュリティデータに対するリクエストを受信し、該リクエストに応答して認証チャレンジを送信することができ、前記チャレンジが共有秘密鍵を認証に使用するようにするリクエストを含み、前記アプリケーションが更に、実行時に前記共有秘密鍵を使用して暗号化された応答を受信し、前記応答を検証し、更に検証時に、前記共有秘密鍵を使用してリクエストされた前記セキュリティデータを暗号化して、前記暗号化されたセキュリティデータを送信することができ、前記暗号化されたセキュリティデータは、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用でき、前記アプリケーションは更に、実行時に前記セキュアチャンネルを介して前記個人化データを送信することができる、
    ことを特徴とする個人化アプリケーションサーバ。
36. 前記個人化アプリケーションサーバが、ネットワークアプリケーション機能（ＮＡＦ）サーバを含む、
    ことを特徴とする請求項３５に記載の個人化アプリケーションサーバ。
37. 前記セキュリティデータは、１つ又はそれ以上の発行者セキュリティドメイン鍵を含む、
    ことを特徴とする請求項３５に記載の個人化アプリケーションサーバ。
38. 前記セキュリティデータが更に、前記１つ又はそれ以上の発行者セキュリティドメイン鍵の有効期間及び作成時期を含む、
    ことを特徴とする請求項３５に記載の個人化アプリケーションサーバ。
39. セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバであって、前記個人化アプリケーションサーバが、
    セキュリティデータに対するリクエストを受信する手段と、
    前記リクエストに応答して、共有秘密鍵を認証に使用する旨のリクエストを含む認証チャレンジを送信する手段と、
    前記共有秘密鍵を使用して暗号化された応答を受信する手段と、
    前記応答を検証する手段と、
    検証時に、前記共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化し、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するために使用することができる前記暗号化されたセキュリティデータを送信する手段と、
    前記セキュアチャンネルを介して前記個人化データを送信する手段と、
    を含む個人化アプリケーションサーバ。

Images