Portable mass storage with virtual machine activation
68 claims: 14 independent, 54 dependent
- 1大容量記憶装置型メモリカードであって、 フラッシュメモリと、 コントローラと、 前記フラッシュメモリの読み出し動作および書き込み動作を制御するファームウェアであって、前記読み出し動作および書き込み動作へのアクセスを制限するセキュリティルーチンを前記ファームウェア内に含むファームウェアと、を備え、 前記ファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記カードは、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記カードが第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記カードが第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる大容量記憶装置型メモリカード。
- 2請求項1記載の大容量記憶装置型メモリカードにおいて、 前記仮想マシンのためのメモリスペースは、前記フラッシュメモリ内に確保される大容量記憶装置型メモリカード。
- 3請求項1記載の大容量記憶装置型メモリカードにおいて、 前記カードは、仮想マシンが前記カードにロードされるまでは第1の動作状態で動作し、その後は第2の動作状態で動作する大容量記憶装置型メモリカード。
- 4請求項3記載の大容量記憶装置型メモリカードにおいて、 前記仮想マシンとともにアプレットがロードされる大容量記憶装置型メモリカード。
- 5請求項4 記載の大容量記憶装置型メモリカードにおいて、 前記アプレットは、デジタル著作権管理(DRM)アプリケーションを含む大容量記憶装置型メモリカード。
- 6ソフトウェアアプリケーションを大容量記憶装置型メモリカードで使用することを可能にする方法であって、 前記カードのデータ記憶動作を実行させるファームウェア、前記カード内の1つ以上のアプリケーションプログラミングインターフェイス、およびアクティブ化されない仮想マシンを備える大容量記憶装置型メモリカードで、ユーザが前記仮想マシンを利用するソフトウェアアプリケーションを使用するため、アクティブ化コマンドなどによって前記仮想マシンをアクティブ化することを実行し、 前記ファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記カードは、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記カードが第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記カードが第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる方法。
- 7請求項6記載の方法において、 前記仮想マシンについてのライセンス料を前記仮想マシンがアクティブ化された場合に限って支払う方法。
- 8請求項6記載の方法において、 前記ソフトウェアアプリケーションは、前記カードのプロセッサにより実行されるために前記仮想マシンに依拠する方法。
- 9請求項6記載の方法において、 前記仮想マシンは、消費者が前記カードを受け取る前に前記カードにロードされる方法。
- 10請求項6記載の方法において、 前記仮想マシンは、消費者が前記カードを受け取った後に前記カードに現場でロードされる方法。
- 11請求項6記載の方法において、 前記ファームウェアは、前記カードに格納されているデータに前記仮想マシンがアクセスすることをアクティブ化後に初めて可能にする方法。
- 12請求項8記載の方法において、 前記ソフトウェアアプリケーションは、デジタル著作権管理(DRM)を含む方法。
- 13請求項12記載の方法において、 前記仮想マシンは、暗号化される方法。
- 14請求項13記載の方法において、 前記仮想マシンは、前記カードのハードウェアにより、前記カードにロードされるときに暗号化される方法。
- 15請求項13記載の方法において、 前記暗号化された仮想マシンは、前記カードのハードウェアの署名を含み、前記署名を作ったハードウェア以外のハードウェアによっては実行され得ない方法。
- 16請求項10記載の方法において、 前記仮想マシンおよび/または前記仮想マシンのプロバイダの真正性をベリファイすることをさらに含む方法。
- 17携帯可能なフラッシュメモリ大容量記憶装置を提供する方法であって、 データ記憶動作を実行させるファームウェアを備えるフラッシュメモリ大容量記憶装置で、前記装置にロードするべきアプリケーションを有する第1者の信用証明書をベリファイすることを実行し、 前記信用証明書は、第1者が仮想マシンを含むアプリケーションをロードすることを可能にし、 前記フラッシュメモリ大容量記憶装置が有する、データ記憶動作を実行させるファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記フラッシュメモリ大容量記憶装置は、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記カードが第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記フラッシュメモリ大容量記憶装置が第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる方法。
- 18請求項17記載の方法において、 前記アプリケーションを前記携帯可能なフラッシュメモリ大容量記憶装置に受け取ることをさらに含む方法。
- 19請求項18記載の方法において、 前記アプリケーションは、前記携帯可能なフラッシュメモリ大容量記憶装置が消費者に販売された後に、現場で前記携帯可能なフラッシュメモリ大容量記憶装置に受け取られる方法。
- 20大容量記憶装置型メモリカードのユーザにソフトウェアアプリケーションを提供する方法であって、 大容量記憶装置型メモリカードのデータ記憶動作を実行させるファームウェアおよび前記カード内の1つ以上のアプリケーションプログラミングインターフェイスを備える大容量記憶装置型メモリカードで、 ソフトウェアアプリケーションをロードするリクエストを受け取ることと、 前記リクエストを受け取った 後に、 仮想マシンを前記カードに受け取り、かつソフトウェアアプリケーションも前記カードに受け取ることと、を実行し、 前記ファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記カードは、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記カードが第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記カードが第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる方法。
- 21請求項20記載の方法において、 前記仮想マシンは、ソフトウェアアプリケーションの要求側に知られずに受け取られる方法。
- 22請求項20記載の方法において、 前記仮想マシンを前記カードに受け取るリクエストを提供することをさらに含む方法。
- 23請求項20記載の方法において、 ソフトウェアアプリケーションを受け取る前に、ソフトウェアアプリケーションのプロバイダを認証することをさらに含む方法。
- 24請求項20記載の方法において、 前記仮想マシンを受け取る前に、前記仮想マシンのプロバイダを認証することをさらに含む方法。
- 25請求項23または24のいずれか記載の方法において、 前記認証することは、対称認証を含む方法。
- 26請求項23または24のいずれか記載の方法において、 前記認証することは、非対称認証を含む方法。
- 27請求項20記載の方法において、 前記カード内のソフトウェアアプリケーションを暗号化することをさらに含む方法。
- 28請求項20記載の方法において、 前記カード内の仮想マシンを暗号化することをさらに含む方法。
- 29請求項27または28のいずれか記載の方法において、 前記暗号化することは、前記カードのコントローラに格納されている鍵を利用することを含む方法。
- 30請求項20記載の方法において、 ソフトウェアアプリケーションは、動作するために前記仮想マシンを必要とする方法。
- 31大容量記憶装置型メモリカードとともに使用されるように提供される仮想マシンを動作可能にする方法であって、 大容量記憶装置型メモリカードのデータ記憶動作を実行させるファームウェアを備える大容量記憶装置型メモリカードで、 仮想マシンを前記カードに受け取ることと、 前記仮想マシンの機能を利用するリクエストを前記カードの中に受け取ることと、 前記リクエストを前記カードの中に受け取った 後に、 前記仮想マシンが機能するために必要なアプリケーションプログラミングインターフェイスを受け取り、 前記アプリケーションプログラミングインターフェイスを受け取ること により前記仮想マシンが利用されることを可能にすることと、を実行し、 前記ファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記カードは、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記カードが第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記カードが第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる方法。
- 32大容量記憶装置型メモリカードに用いられるソフトウェアアプリケーションをアクティブ化または非アクティブ化する方法であって、 大容量記憶装置型メモリカードのデータ記憶動作を実行させるファームウェアおよび前記カードに格納されているデータにアクセスするためにファームウェアに依拠するソフトウェアアプリケーションを備える大容量記憶装置型メモリカードで、 前記カードのファームウェアでワンタイムパスワード値を生成することと、 前記カードのファームウェアで生成されたワンタイムパスワード値を前記カードの外で生成されたワンタイムパスワード値と比較することと、 前記カードにより生成された値が前記カードの外で生成された値と一致することを比較することでベリファイされたならば、前記ソフトウェアアプリケーションの実行を可能にするかまたは不可能にすることと、を実行し、 前記ファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記カードは、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記カードが第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記カードが第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる方法。
- 33請求項32記載の方法において、 前記ワンタイムパスワード値を生成することは、パスワードを、種と、ソフトウェアアプリケーションに関連付けられた一意の識別子および前記カードに関連付けられた一意の識別子のうちの1つ以上との関数として作成することを含む方法。
- 34請求項33記載の方法において、 前記ワンタイムパスワード値を生成することは、パスワードを前記カードの関数として作成することをさらに含む方法。
- 35請求項32記載の方法において、 前記カードは複数 生産され、前記カードの各々は、同じ種を含むけれども、一意の識別子に基づいて値を様々に変化させるワンタイムパスワード生成アルゴリズムを利用することによって所与のカウントについて異なるワンタイムパスワード値を生じさせる方法。
- 36請求項32記載の方法において、 一意の識別子は、特定のカードに一意に関連付けられた数を含む方法。
- 37請求項32記載の方法において、 一意の識別子は、ソフトウェアアプリケーションの特定の要求に一意に関連付けられた数を含む方法。
- 38大容量記憶装置型フラッシュメモリ装置であって、 コントローラと、 ランダムアクセスメモリと、 フラッシュメモリおよびデータ記憶動作を実行させるファームウェアを備える大容量記憶装置と、 仮想マシンと、 仮想マシンの動作が望まれるときに、 前記仮想マシンの 動作を可能にするメカニズムと、を備え、 前記装置のユーザの活動によって前記メカニズムがトリガされたならば、前記仮想マシンに関連するライセンス料が支払われ、 前記大容量記憶装置が有する、データ記憶動作を実行させるファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記大容量記憶装置は、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記大容量記憶装置が第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記大容量記憶装置が第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる大容量記憶装置型フラッシュメモリ装置。
- 39請求項38記載の装置において、 前記仮想マシンは、前記大容量記憶装置のフラッシュメモリに格納される装置。
- 40大容量記憶装置型フラッシュメモリ装置であって、 コントローラと、 ランダムアクセスメモリと、 フラッシュメモリおよびデータ記憶動作を実行させるファームウェアを備える大容量記憶装置と、 仮想マシンと、 前記仮想マシンを動作可能にするための手段と、を備え、 前記動作可能にするための手段がトリガされたときに、前記仮想マシンについての料金の支払いが開始され、 前記大容量記憶装置が有する、データ記憶動作を実行させるファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記大容量記憶装置は、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記大容量記憶装置が第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記大容量記憶装置が第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる大容量記憶装置型フラッシュメモリ装置。
- 41データ記憶動作を実行させるファームウェアを備える記憶装置であって、 メモリと、 非アクティブ状態である仮想マシンと、 前記メモリの読み出し動作および書き込み動作を制御するように動作可能なコントローラと、を備え、 前記コントローラは、前記仮想マシンをアクティブ状態にするようにさらに動作可能であり、 前記仮想マシンについてのライセンス料の支払いは、前記仮想マシンがアクティブ状態にされた場合に限って必要とされ、 前記コントローラは、前記仮想マシンが非アクティブ状態である第1の動作状態または前記仮想マシンがアクティブ状態である第2の動作状態のいずれかで動作可能であり、 前記記憶装置が有する、データ記憶動作を実行させるファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記記憶装置は、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記記憶装置が第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記記憶装置が第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる記憶装置。
- 42請求項41記載の記憶装置において、 前記コントローラは、アクティブ化コードを受け取ったことに応答して前記仮想マシンをアクティブ状態にするように動作可能である記憶装置。
- 43請求項42記載の記憶装置において、 前記コントローラは、アクティブ化コードを前記記憶装置に格納されているアクティブ化コードの暗号化されたバージョンと照合することによって、アクティブ化コードを確認するように動作可能である記憶装置。
- 44請求項42記載の記憶装置において、 前記コントローラは、アクティブ化コードを確認のためにサーバに送るように動作可能である記憶装置。
- 45請求項42記載の記憶装置において、 前記コントローラは、認証されているエンティティからアクティブ化コードを受け取った場合に限って前記仮想マシンをアクティブ状態にするように動作可能である記憶装置。
- 46請求項42記載の記憶装置において、 アクティブ化コードは、前記仮想マシンの識別子および前記記憶装置の識別子のうちの1つまたは両方に基づく記憶装置。
- 47請求項42記載の記憶装置において、 アクティブ化コードは、デジタル著作権管理(DRM)許可をさらに提供する記憶装置。
- 48請求項42記載の記憶装置において、 アクティブ化コードは、暗号認証方式に基づく記憶装置。
- 49請求項42記載の記憶装置において、 アクティブ化コードは、ワンタイムパスワードに基づく記憶装置。
- 50請求項41記載の記憶装置において、 前記コントローラは、アプリケーションプログラミングインターフェイスを受け取ったことに応答して前記仮想マシンをアクティブ状態にするように動作可能である記憶装置。
- 51請求項41記載の記憶装置において、 前記コントローラは、前記メモリに格納されているデータを保護するセキュリティシステムを実行するように動作可能であり、さらに前記仮想マシンがアクティブ状態にされているときに前記仮想マシンがデータの少なくとも一部にアクセスすることを可能にするように動作可能である記憶装置。
- 52請求項41記載の記憶装置において、 前記仮想マシンは、エンドユーザへの販売時より前に前記記憶装置にロードされる記憶装置。
- 53請求項41記載の記憶装置において、 前記仮想マシンは、エンドユーザへの販売時より後に前記記憶装置にダウンロードされる記憶装置。
- 54請求項53記載の記憶装置において、 前記仮想マシンをアクティブ状態にするためのアクティブ化コードは、前記仮想マシンとともにダウンロードされる記憶装置。
- 55請求項41記載の記憶装置において、 前記仮想マシンは、新しいファームウェアと一緒に前記記憶装置にロードされる記憶装置。
- 56データ記憶動作を実行させるファームウェアを備える記憶装置で仮想マシンをアクティブ化する方法であって、 メモリと非アクティブ状態である仮想マシンとを備える記憶装置のコントローラで、 前記仮想マシンをアクティブ状態にするためのアクティブ化コードを受け取ることと、 前記仮想マシンをアクティブ状態にすることと、を実行し、 前記仮想マシンについてのライセンス料の支払いは、前記仮想マシンがアクティブ状態にされた場合に限って必要とされ、 前記コントローラは、前記仮想マシンが非アクティブ状態である第1の動作状態または前記仮想マシンがアクティブ状態である第2の動作状態のいずれかで動作可能であり、 前記記憶装置が有する、データ記憶動作を実行させるファームウェアは、第1の動作状態または第2の動作状態のいずれかで選択的に動作するように構成され、前記記憶装置は、アクティブ化された仮想マシンがないときに第1の動作状態で動作し、アクティブ化された仮想マシンがあるときに第2の動作状態で動作し、 前記記憶装置が第2の動作状態で動作している間、前記ファームウェアのセキュリティルーチンは読み出しおよび書き込み保護されるデータからのデータへのアクセスを前記仮想マシンに許し、前記記憶装置が第2の動作状態で動作しているときに前記仮想マシンに関連するライセンス料が支払われる方法。
- 57請求項56記載の方法において、 アクティブ化コードを前記記憶装置に格納されているアクティブ化コードの暗号化されたバージョンと照合することによって、アクティブ化コードを確認することをさらに含む方法。
- 58請求項56記載の方法において、 アクティブ化コードを確認のためにサーバに送ることをさらに含む方法。
- 59請求項56記載の方法において、 前記仮想マシンは、認証されているエンティティからアクティブ化コードが受け取られた場合に限ってアクティブ状態にされる方法。
- 60請求項56記載の方法において、 アクティブ化コードは、前記仮想マシンの識別子および前記記憶装置の識別子のうちの1つまたは両方に基づく方法。
- 61請求項56記載の方法において、 アクティブ化コードは、デジタル著作権管理(DRM)許可をさらに提供する方法。
- 62請求項56記載の方法において、 アクティブ化コードは、暗号認証方式に基づく方法。
- 63請求項56記載の方法において、 アクティブ化コードは、ワンタイムパスワードに基づく方法。
- 64請求項56記載の方法において、 前記メモリに格納されているデータを保護するセキュリティシステムを実行することと、前記仮想マシンがアクティブ状態にされているときに前記仮想マシンがデータの少なくとも一部にアクセスすることを可能にすることとをさらに含む方法。
- 65請求項56記載の方法において、 前記仮想マシンは、エンドユーザへの販売時より前に前記記憶装置にロードされる方法。
- 66請求項56記載の方法において、 前記仮想マシンは、エンドユーザへの販売時より後に前記記憶装置にダウンロードされる方法。
- 67請求項66記載の方法において、 アクティブ化コードは、前記仮想マシンとともにダウンロードされる方法。
- 68請求項56記載の方法において、 前記仮想マシンは、新しいファームウェアと一緒に前記記憶装置にロードされる方法。
Independent claims68
61 paragraphs, as filed
The present invention generally relates to portable mass storage devices and firmware and Soweto running on these devices, in particular providing software and other content to activate and pay for it. Regarding.
Smart cards have been around for some time and are often used, especially as cash cards and credit cards. Smart cards, as the name suggests, are processor-controlled and also contain a small amount of memory that holds identification data and transaction-related data. The ability to create and run Java-based programs on smart cards has recently been developed and is becoming more widespread. Java-based programs can also be run on other intelligent devices such as mass storage memory cards commonly used in digital cameras and music players. These other cards are recognized as mass storage because they must store and access a library of very large data such as photos and music that are orders of magnitude larger than the transaction and identification data stored on the smart card. Has been done. Examples of these mass storage cards are CompactFlash (CF) cards, Secure Digital (SD) cards, Mini SD cards, Micro SD cards, Multimedia (MMC) cards, and Memory Sticks. is there. In addition to the examples listed, there are many high-capacity storage cards in different formats. A portable flash memory-based universal serial bus (USB) drive is another type of portable mass storage device.
Java Card (Java Card®) technology allows programs written in the Java programming language to run on smart cards and other small, resource-constrained devices. Developers can create and test programs using standard software development tools and environments, and then convert them into forms that can be installed on Java Card technology-enabled devices. Application software for the Java Card platform is referred to as applets, or more clearly Java Card applets or card applets (to distinguish it from browser applets).
Although Java Card technology allows programs written in the Java programming language to run on small memory cards, such small devices are too powerless to support the full functionality of the Java platform. Therefore, the Java Card platform supports only a carefully selected and customized subset of Java platform functionality. This subset provides features that are well suited for writing programs for small devices and maintains the object-oriented capabilities of the Java programming language.
Java Card is a type of virtual machine. Other virtual machines are also available, where a virtual machine is an abstraction of a physical processor and has a virtual relative of a conventional processor. For the Java language, the Java Virtual Machine is software that acts as an interface between compiled Java binary code and the microprocessor of the underlying hardware platform.
One application that is particularly useful when run on such small devices is related to payments for protected content such as music and movies.
To run an application written in Java, Java The Card virtual machine must be loaded and activated on the card. Each request for a machine requires a license fee to be paid to Sun or the supplier of such components. Since the main purpose of smart cards is transactions, the cost of license fees is acceptable to the card issuer as the cost of doing business. However, users of high-capacity storage memory cards may or may not have additional application applications that virtual machines enable. This is because a typical user owns and uses a card primarily for the purpose of storing data. Therefore, the manufacturer cannot take over or absorb the cost of the license fee as a matter of course. In addition, each of the applets or other programs running on one or more virtual machines can, of course, take over or absorb (for users who may not have that purpose). You may need a license fee that you can't.
The role of the Java Card virtual machine is best understood in the context of the process for producing and deploying software for the Java Card platform. There are several components that make up the Java Card system, including the Java Card virtual machine, converters for the Java Card platform (Java Card converters), terminal installation tools, and installation programs that run on the device. Java Card applet development begins as with any other Java program. That is, the developer writes one or more Java classes, compiles the source code with a Java compiler, and generates one or more class files. The applet is run, tested, and debugged on the workstation using simulation tools to emulate the device environment. Then, when the applet is ready to be downloaded to the device, the class files that make up the applet are Java. Converted to a CAP (converted applet) file using a Card converter. The Java Card converter considers all the class files that make up a Java package as input. The Java Card converter also considers one or more export files as input. The export file contains name and link information about the contents of other packages imported by the converted class. When an applet or library package is converted, the converter can also create an export file for that package.
Usually, after conversion, the CAP file is copied to a card terminal device such as a desktop computer with a card reader peripheral. The installation tool on the terminal then loads the CAP file and sends it to a Java Card technology-enabled device. The installation program on the device receives the contents of the CAP file and prepares the applet for operation by the Java Card virtual machine. The virtual machine itself does not have to load or manipulate the CAP file, it only needs to execute the applet code found in the CAP file loaded on the device by the installation program.
These and other aspects of the Java Card platform are described in the Sun Microsystems specification, namely Application Programming Interface, Java Card.<sup>TM</sup> Platform, Version 2.2.1 (Non-Patent Document 1), Runtime Environment Specification, Java Card<sup>TM</sup> Platform, Version 2.2.1 (Non-Patent Document 2), and Virtual Machine Specification, Java Card<sup>TM</sup> It is described in Platform, Version 2.2.1 (Non-Patent Document 3), and the whole is incorporated by reference in the present specification.
As mentioned briefly earlier, a Java Card virtual machine must be loaded and activated on the card in order for an application written in Java to work.
In one conventional approach described in US Pat. No. 6,772,955 by Yoshimoto et al., The virtual machine is provided as part of a memory card controller chip so that the card is used in point-based transactions. To. The source code for using the card as a loyalty card is written in Java and loaded onto the card. The point balance is updated for each item purchased with the card.
Each Java Virtual Machine request requires a license fee to be paid to Sun or another supplier. Similarly, any other proprietary virtual machine may require payment to the licensee of such machine. With smart cards, each card has an active, paid copy of the Java Card virtual machine. This adds to the cost of each smart card, perhaps in addition to the system described in Yoshimoto et al.'S patent (Patent Document 1). Since the basic function of a smart card is a transaction in most applications, this cost can be absorbed and / or passed on to the manufacturer, middleman, or consumer. However, for consumer mass storage, where virtual machine functionality may never be utilized, it is not desirable to absorb or pass on the cost of the license.
The Global Platform is an industrial consortium for the advancement and standardization of smart cards. The Global Platform acts as a standard body for the smart card industry and creates and maintains a public technology framework for the global rollout of smart card programs by many service providers in many industries. The Global Platform Card Specification V.2.1.1 (Non-Patent Document 4) dated December 2004, where the application programming interface (API) of the global platform and other aspects of the global platform are available at www.globalplatform.com. And The Formal Specification of Global Platform Card Security It is described in Requirements (Non-Patent Document 5), and the whole is incorporated by reference in the present specification. The global platform is concerned about downloading applets to smart cards or other devices that already have virtual machines. However, although it provides the required applet and associated functionality, it is provided for cards that already have the virtual machines needed to run the applet.
<p><patcit num="1"><text>U.S. Pat. No. 6,772,955</text></patcit><patcit num="2"><text>U.S. Patent Application No. 11 / 053,273</text></patcit><patcit num="3"><text>U.S. Patent Application No. 11,314,032</text></patcit><patcit num="4"><text>U.S. Patent Application No. 11 / 317,339</text></patcit></p>
<p><nplcit num="1"><text>Application Programming Interface, Java CardTM Platform, Version 2.2.1</text></nplcit><nplcit num="2"><text>Runtime Environment Specification, Java CardTM Platform, Version 2.2.1</text></nplcit><nplcit num="3"><text>Virtual Machine Specification, Java CardTM Platform, Version 2.2.1</text></nplcit><nplcit num="4"><text>The Global Platform Card Specification V.2.1.1</text></nplcit><nplcit num="5"><text>The Formal Specification of Global Platform Card Security Requirements</text></nplcit></p>
The present invention minimizes manufacturing and use costs while increasing the potential use of portable mass storage devices. Although the present invention allows the device to run a variety of dedicated software applications, the cost of those applications is borne only if the user chooses to take advantage of the features of those applications. In other words, the costs associated with the potential use are only incurred if the potential is realized. This is beneficial for both manufacturers and consumers. Manufacturers can increase product functionality and market penetration without absorbing or passing on costs for features that may only be desirable to some consumers. Consumers who want to take advantage of features can pay for them as needed, while those who don't want to take advantage of features pay for what they don't want or need. You don't have to.
Virtual machines are very useful in portable mass storage, as they allow you to use a wider variety of applications than those that would otherwise be available to run directly on the device. .. The reason is that virtual machines provide independence from a particular processing platform. A virtual machine is a self-contained operating environment run by a microprocessor, but behaves as if it were a separate computer. Virtual machine applications run and run the same way in a virtual machine, no matter what kind of processor and operating system it runs on.
Although the traditional solution is to embed a virtual machine in a memory card, the cost of that virtual machine must be borne by the manufacturer and the consumer, regardless of whether the consumer wanted or needed the virtual machine. I had to. This is acceptable for devices intended primarily as transaction cards or "electronic wallets", but is ideal for portable mass storage devices that may be used initially or primarily for other purposes. is not it. In the present invention, the license fee for a virtual machine only needs to be paid if the user wishes to use an application that requires the presence of one or more virtual machines. Therefore, the cost of the underlying mass storage can be kept to a minimum, and add-on applications and virtual machines can only be paid if needed or desired. A virtual machine can be activated at any time during the life of the device and payments will only be made if it is activated. The machine can also be loaded onto the card at any time, either alone or in combination with applications that utilize the machine. In one preferred embodiment, when a virtual machine is needed, the virtual machine installation is done behind the scenes as part of the activation of the virtual machine or higher level application without the user's knowledge.
The present invention considers paying a license fee only when a program that requires a fee is used. This makes it possible to incorporate these programs in an environment where it is otherwise infeasible. This is especially useful when there are a large number of diverse applications that can be run on small devices such as large storage memory cards.
The present invention allows users to quickly and easily select, activate and pay for only the programs they desire. This takes into account that while keeping the basic equipment available to everyone, customized applications are used by those who find it desirable.
Integrating virtual machines with the underlying firmware that runs portable mass storage is not an easy task. This is especially true for "secure" devices where access to protected content must be restricted. In such devices, the device firmware is responsible for protecting the content, at least in part. Therefore, it limits access to read / write operations. Because of this, it is a target for anyone who wants to make an unauthenticated copy of protected content. Therefore, the underlying firmware must protect the content from hackers and also allow applications such as virtual machines to access the content. In situations where a virtual machine can be loaded at any time (or when an application running on a device that uses such content is turned on), the firmware can be loaded even if the virtual machine (or application) is present. It must be able to work without it, and it must prevent malicious software from disguising itself as a virtual machine (or application).
<figref num="1">It is a schematic diagram of a large-capacity storage device 100.</figref><figref num="2">FIG. 5 is a schematic representation of the software components of mass storage 100 and the host 105.</figref><figref num="3A">It is explanatory drawing of the software component of the mass storage device according to one Embodiment of this invention.</figref><figref num="3B">FIG. 3 is an explanatory diagram of a downloaded application according to one embodiment of the present invention.</figref><figref num="4A">It is a flowchart of the 1st supply scene according to this invention.</figref><figref num="4B">It is a flowchart of the 2nd supply scene according to this invention.</figref><figref num="4C">It is a flowchart of the 3rd supply scene according to this invention.</figref><figref num="5">It is a flowchart which shows the application protocol interface management according to one Embodiment of this invention.</figref><figref num="6">The public key infrastructure and mass storage 100 are shown.</figref><figref num="7">A table that describes some components of the public key infrastructure.</figref><figref num="8">It is explanatory drawing of the flow of profit according to one Embodiment of this invention.</figref><figref num="9">It is explanatory drawing of a part of the memory space of a flash memory 140.</figref>
As discussed in the Background Technology section, portable flash memory-based mass storage devices are widely used today for storing large files and software programs. Due to the widespread use of digital devices that rely on memory cards or pocket-sized USB flash devices, many already have one or several of these portable high-capacity storage devices. The present invention minimizes manufacturing and use costs while increasing the potential use of these devices. Although the present invention allows the device to run a variety of dedicated software applications, the cost of those applications is borne only if the user chooses to take advantage of the features of those applications. In other words, the costs associated with the potential use are only incurred if the potential is realized. This is beneficial for both manufacturers and consumers. Manufacturers can increase product functionality and market penetration without absorbing or passing on costs for features that may only be desirable to some consumers. Consumers who want to take advantage of features can pay for them as needed, while those who don't want to take advantage of features pay for what they don't want or need. You don't have to.
Much of the software and other content that can be operated and / or stored in mass storage requires payment to the owner or licensee. For example, software programs require payment of a license fee to the creator, and content such as music, movies, photographs or copyrights also requires payment to resellers, creators, providers and / or licensees. And. An example of a software program that is particularly useful when run on mass storage is a virtual machine. The reason is that virtual machines take into account the creation and execution of software that does not have to be tailored to the specificity of the underlying hardware platform. One example of a virtual machine is a Java-based virtual machine provided by Sun Microsystems, Inc., as described in the Background Technology section.
Although Sun Microsystems virtual machines are given as an example, other virtual machines may exist and others may be developed. A virtual machine is a self-contained operating environment run by a microprocessor, but behaves as if it were a separate computer. Virtual machine applications run and run in the same way no matter what kind of processor and operating system the virtual machine is running on. It provides independence from any processing platform. Therefore, a wider range of software programs should be available to run on virtual machines and underlying equipment than would be available without virtual machines. The present invention can work with any virtual machine and the applications it enables.
The general architecture of a mass storage memory card is shown in Figure 1. The various components of the mass storage device 100 are coupled and communicate with each other via the system bus 150. The device 100 communicates with the external device 105, also referred to as the host 105, via the host interface 140. Host interface 140 includes both logical and hardware components that exchange data between host 105 and device 100. If the device 100 has the shape factor of a mass storage memory card, the interface includes, for example, an electrical contact that interfaces with the contact structure of the digital camera. If the device 100 has the shape factor of a USB device, the host interface 140 includes electrical contacts and required drivers to interface with the USB port. The controller 110 controls the device and manages the read / write operation and the data distribution in the cell of the mass storage flash memory 140. The device 100 also includes a random access memory (RAM) 120 that may be a separate component as shown or integrated within the controller 110. The controller 110 executes firmware from RAM 120 stored in read-only memory 130 or large-capacity storage flash memory 140. The read-only memory 130 is electrically erasable and can therefore be EEPROM or EPROM. The firmware is executed by the controller to control the operation of the memory card. If the firmware is corrupted, the memory card will no longer function properly.
The mass storage device 100 preferably includes security measures. These measures ensure that the state of the application (eg, from inactive to active) can only be changed by an authenticated person. The state is controlled by the device firmware, which can check the state to ensure that a particular application can be active and used. These means are also preferably implemented in both the hardware and software (firmware) of the device, and in certain embodiments, the data stored in the device and transferred to and from the device is encrypted. For further information on this type of secure mass storage, US Patent Application No. 11 / 053,273, "Secure Memory Card With Life Cycle Phases," by Holtzman et al., Which is incorporated herein by reference in its entirety. Patent Document 2), Holtzman et al., Memory System with in Stream Data US Patent Application No. 11 / 314,032 (Patent Document 3) entitled "Encryption / Decryption" and US Patent Application No. 11 / 317,339 (Patent Document 4) entitled "Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory" Please refer.
The device 100 is referred to as a memory card, which is an embodiment of the device, but as described above, the device 100 can be in the form of a memory card, a USB device, or other shape factor.
The firmware provides a path to the data on the card, some of which can be protected data. The integrity of the firmware that runs the controller is important, especially for secure cards. If the card is a secure card (for example, one that performs some form of digital rights management (DRM)), one of the features of the firmware is to restrict access to protected content. Is. DRM is a broad term used to describe some techniques for limiting the free use and transfer of digital content, so those who think it more appropriate to describe it as "digital rights management". There are also. FIG. 2 shows some of the software components of device 100, including firmware. The virtual machine 220 can also access content in flash memory, although it contains features that are not present in the basic card firmware 210. Therefore, in a sense it may be considered a type of firmware in the card and must be fully integrated and compatible with firmware 210. Therefore, the card firmware 210 must be implemented so that it can function robustly with or without the VM220. Similarly, the VM 220 is implemented to work with the card firmware 210. The design aspect implemented in the firmware 210 code that allows the firmware 210 to be integrated with the VM 220 may be considered a "hook" within the firmware 210. These hooks and the compatibility they require are represented by a double arrow between firmware 210 and VM220. The applet loaded in the card 100 can communicate with the firmware via the VM220 to provide any number of different software applications on the card. These applets 240A ... X run on a virtual machine, so other hardware of controller 110 and device 110 It does not have to be adjusted to the details of the air component. Open the device to a library of various software applications that would otherwise be incompatible with the card.
As can be seen in Figure 2, Host 105 must communicate with Firmware 210 (including VM220) through the application programming interface (API). Any number of API 250A ... X can be implemented on the card. This includes standard or native device API 250A, industry standard or widely accepted API 250B such as Global Platform API, and proprietary API 250C (eg API for Java Virtual Machine). APIs tied to the VM220, or APIs for Applet 240 or one of Applet 240) and any other API Including 250X. One way to activate a particular virtual machine is to activate an API that is compatible with that particular virtual machine and because the VM220 must have the right API in the right place to work. / Or to load. Of course, the VM can be activated directly with various other triggers. A VM is a type of firmware, as described below with respect to FIG. Various activation methods are discussed below.
Whatever the card's application is, the above-mentioned addition of virtual machine functionality requires integration with the card's other firmware. The card must work seamlessly whether the virtual machine and its various applets are integrated with the firmware before or after the card leaves the factory. In the context of an applet being downloaded in the field, the content and nature of the applet, if possible, cannot be easily verified. Therefore, the card's base firmware must be flexible enough to facilitate field downloads and the data access required by applets, while at the same time being sufficient to work with poorly written applets. Must be robust. In addition, if the applet aims to break the DRM of the card, the firmware must protect the data from the applet and continue to provide content to authenticated users.
Unlike smart cards built for the purpose of protecting small amounts of highly protected transactional data, high-capacity storage memory cards must provide frequent access to a very large library of content. .. This user content, like the applications the card may encounter, is constantly changing during the life of the card. The card's firmware and hardware always protect the contents of the card while at the same time taking into account the user's desire for new applications and allowing them to be downloaded in the field (or at the factory). This is not an easy task.
FIG. 3A is a representation of some of the software components within the card 100. Various applets 240A ~ X are running in the card. The preferred virtual machine 220 is a Java Card virtual machine, and in the case of Java Card or other Java virtual machines, the Java Card framework is also required or desired based on a particular applet and virtual machine 220. Exists. All of these components run on the card operating system or firmware 210. In this case, the Java Card framework and other industry add-ons 230 and the Java Virtual Machine 220 run on the card operating system 210.
FIG. 3B shows a software component or package that can be loaded into a card and activated at any time to function as part of the firmware and system of the present invention. The package can include (optionally) one or more software applications 270 as well as virtual machine 220. The underlying firmware 210 is provided to work with additional software called VM220 and Application 270. Any software application 270 running on the virtual machine can be loaded on the card at any time. The dotted line helps indicate that the VM200 can be loaded with or without the application 270 and that the application installation does not have to occur at the same time as the VM's. Payments related to the components of the package need only be made when i) the package is on the card and ii) the package is activated.
The package seen in Figure 3B can be provided to the user in several ways. As can be seen in Figure 4A, the package can be provided as a card at the time of sale. In this case, the package must be activated "in the field" before it can be used. Alternatively, the package may be downloaded "in the field" by the user either as a complete package or individually, as seen in Figure 4B. Alternatively, new firmware 210 can be loaded onto the card, as seen in Figure 4C. This firmware download also includes all or part of the package found in Figure 3B. In one embodiment, this means that the firmware 210, VM220, and applet 240 seen in FIG. 2 are all loaded during the firmware update process. These basic methods are shown in the flowcharts of FIGS. 4A, 4B and 4C described later.
As mentioned above, virtual machines and applets need to be active or activated in order to be utilized. Of course, that's not what you want in many situations, but you may not have the security measures you need to download the active component. This seems to be suitable for a secure or reliable environment where card distribution is limited, but not always. Also, in certain embodiments, security can be part of the download process without the additional activation required. In other words, if the user is first authenticated to download or the activation can be done as part of the download sequence, the component can be downloaded in the activated state.
Card 100 has an activation manager that receives and activates activation commands. The activation manager can be part of firmware 210 or can be considered as a separate software module. Activation Manager turns application or operating system features on and off. This activation is preferably done securely, for example over a secure channel. In one embodiment, the activation manager activates the package upon receiving the correct code. The activation manager receives the code and matches it with the server that validates the code, or against the encrypted version of the code stored in the card's memory. The activation manager also tracks failed activations, and in some embodiments can limit the number of failed attempts and lock the card if the number is exceeded.
The code can be based on various parameters and can be calculated in any number of ways. The code may be as simple as you would expect to turn on matching applications. The code can be inclusive for activation and may also be associated with and / or based on the application ID, which is the number uniquely associated with a particular application. The code can be partially based on the unique ID of the card, which is the number associated only with a particular card. The code can also have a part that specifies the application and whether the application should be activated or deactivated, and the activation code itself. The code can also specify or include specific application states such as inactive, active, suspended, or canceled. It can also manifest and provide access to various other required permissions, such as different permission levels in DRM schemes. The code can also be based on or include some or all aspects of all the aforementioned schemes.
The code can also be part of a symmetric or asymmetric cryptographic authentication method. For example, in symmetric schemes, the code can be a kind of one-time password (OTP), which is well known in the art. In this case, both the card and the validation server have the same species and independently create code or OTP based on that species and any number of selected algorithms. The code or OTP is incremented or updated at regular intervals, and at any given time, the OTP calculated on the card can be verified against the OTP calculated by the verify server. In the OTP scheme, if two cards are initially loaded with the same species, then one card if the two cards use different algorithms to increment the password (inside the card and the server). Even if the value of the seed or one-time password in is compromised, it cannot be used to hack into other cards. In one example, the activation code or OTP is a function of card ID, card type, application ID, and OTP type. The card type can be any well-known card type such as compact flash card, SD card, mini SD card, MMC card, transformer flash card, XD card, memory stick, or can be a USB flash drive. ..
In embodiments where the activation code contains (a function of) OTP or is based on (a function of) OTP, the OTP and / or code can be used to turn the application or software layer on or off. .. An OTP (generated by a remote server or other device) or code is sent to the card and compared to the OTP generated by the card to verify the activation code or OTP. Once it has been verified as correct, the application or software layer can be turned on or off. The use of OTP for these purposes is not possible because its value can only be used once and therefore cannot be used for multiple activations or passed in an unauthenticated way. It is advantageous. In certain embodiments, the application ID of the application to be activated can also be used to generate the activation code or OTP. In this way, OTP is specific to certain applications.
As mentioned above, in some embodiments the same species can be used for multiple cards. That kind is the basis of OTP calculation. Also, the activation code or OTP is a function of card ID, card type, application ID, and OTP type. This allows the same secret seed to be loaded onto multiple cards, which reduces the number of records on the server database. At the same time, various algorithms that can be a function of one or more of the card ID, card type, and application ID can be used to generate a unique OTP and activation code, thus providing a high degree of security. Can be done.
The most common asymmetric method involves public key infrastructure (PKI), in which case the device or entity has two keys, a private key and a public key, which are the data encrypted with one key. Is cryptographically associated so that can be decrypted on the other hand and there is no way to mathematically derive the private key from the public key. In such a scheme, the public key is freely distributed and the private key is kept secret by the owning entity. Authentication of an entity is accomplished by performing a challenge / response sequence that requires proof of possession of the private key by decrypting an encrypted message with that public key. One embodiment of the invention using a PKI is shown in FIGS. 6 and 7, which will be described later.
Further, in one embodiment, aspects of the symmetric scheme are combined with aspects of the asymmetric scheme. In one example of such an embodiment, OTP is used to verify the card in one step and challenge / response dialogue is used in the other one step.
Having discussed the activation process, we now return to the flowcharts in Figures 4A, 4B, and 4C showing both download and activation aspects.
Figure 4A shows the process by which activation of a loaded virtual machine is performed. In step 405 of Figure 4A, the virtual machine is provided by the card issuer or provider at some point before the card is sold to the user. This is done at the time of manufacture or at some point thereafter, and the firmware for the card is also present. The virtual machine is dormant or inactive, that is, it cannot be used by the consumer. Therefore, you do not have to pay a license fee for virtual machines (unused or inactive). Preferably, the consumer is unaware of its presence before it is activated or "unlocked". The virtual machine can be any type or brand of virtual machine. Some examples of currently available virtual machines are Java, MULTOS, Java Card, Embedded Linux (embedded linux), Embedded Java (embedded). java), dot.net, and Windows CE. Different virtual machines are needed to support different applets, so multiple VMs can be loaded into the device. The device firmware manages the availability of resources required for various VMs and applets.
In step 410, the system user, card, or server determines if a virtual machine is needed or desired. Then, in step 415, a trusted institution activates the virtual machine. It is at this point that you have to pay the license fee associated with the virtual machine. In public key infrastructure, a trusted authority is often referred to as a certification authority. Certification authority 620 is shown in Figure 6.
Figure 6 shows an embodiment that utilizes a public key infrastructure for verification / authentication of credit certificates. Transactions can never be more secure than the systems in which they occur, so a way for correspondents to locate each other and be confident that they really belong to the person (or machine) they want to communicate with the public key they use. Is the most important factor. The public key infrastructure is designed to provide this trust. With a data element called a digital certificate or public key certificate that binds a public key to identification information about its owner, the infrastructure creates that bond and makes it for everything in the community of use. Designed to manage. Once the credit certificate has been verified, the package can be activated with code or OTP as described above. Alternatively, the credit certificate itself or its verification is sufficient for verification / authentication of the credit certificate and allows or triggers activation.
Using a combination of private and public key cryptography, PKI enables several other security services, including data confidentiality, data integrity, and key management. The basis or framework for PKI is defined in the ITU-T X.509 Recommendation [X.509], which is incorporated herein by reference in its entirety.
End entities are sometimes considered end users. As is often the case, the term end entity is intended to be much more inclusive. The end entity can be an end user, a device such as a router or server, a process, or anything that can be identified in the subject name of a public key certificate. End entities can also be thought of as consumers of PKI-related services. In the present invention, as seen in the embodiment shown in FIG. 6, the end entities are the mass storage device 100 and its users.
The public key is distributed in the form of a public key certificate. The CA (Certificate Authority) 620 is the basis of PKI because it is a component that can issue public key certificates. The public key certificate is sent to device 100 and repository 610. The public key certificate is digitally signed by the issuing CA, which effectively ties the subject name to the public key. The CA is also responsible for issuing a certificate revocation list (CRL), unless it is delegated to a separate CRL issuer 630. The CA may also be involved in some administrative tasks such as end-user registration, which is often delegated to the Registration Authority (RA), but is optional and not shown in Figure 6. In practice, the CA can also serve as a key backup and recovery function, but this function can also be delegated to a separate component. CAs are often considered the "source of trust" in PKI. In an embodiment that utilizes a public key infrastructure, the CA610 demonstrates that the device 100 and the server that downloads the package can be trusted. This trust is used for download, activation, and payment purposes. Figure 7 is a table describing the components of Figure 6 and is provided as a quick reference.
Figure 4B is another process that provides a virtual machine alone or as part of a larger software package. At step 435, card firmware 210 is provided. This firmware has "hooks" for future integration and use with virtual machines, or is designed to be compatible with virtual machines in other words. This virtual machine compatible firmware is preferably provided at the time the card is manufactured, but may be loaded at any time during the life of the card. Firmware has a security mechanism designed to restrict access to certain types of data on the card. This includes the security mechanism itself against the protected content stored in the card's memory in the firmware. Before the virtual machine is installed or activated, the firmware (security mechanism) does not allow software applications running inside or outside the card to access protected data. However, the firmware can also work to detect the virtual machine and allow the virtual machine to access some of the protected data once it has been installed and activated. is there. In other words, the firmware can be considered to have a number of different operating states, one that is used without the virtual machine and one that is used with the virtual machine. In both situations, the firmware must protect the data on the card, including the firmware itself, and restrict access to it. In the second state, the firmware must allow the virtual machine to read and write data, while at the same time not allowing unauthenticated read and write access for any malicious application.
Then, in step 440, after the manufacturer leaves, the user or middleman, or the card itself, determines whether a virtual machine is desired or needed. The virtual machine and its provider are then authenticated in step 445. This may be symmetric and / or asymmetric authentication as described above. At step 450, the virtual machine is downloaded to the card and activated. It is at this point that the license fees associated with the virtual machine must be paid. Once activated, payment is triggered.
Figure 4C is another process that provides a virtual machine alone or as part of a larger software bundle. In step 460, the user or card determines whether a virtual machine is needed or desired. Then, in step 465, the virtual machine and its provider are authenticated in step 445. This may be symmetric or asymmetrical authentication as described above. At step 470, a new copy or version of firmware 210 with virtual machine 220 is downloaded to the card. At the same time, additional applets 240 or other programs can be loaded arbitrarily.
Figure 5 shows API management with virtual machine downloads. At step 510, a request to download the applet is received. This request can be made on the server from any intelligent device via any network, including the Internet. The server can be operated by the card issuer or provider, or any third party. The issuer of the card can be the manufacturer or its representative, and the provider can be any entity that handles, distributes, or sells the card. If the issuer or provider did not receive the request directly, the server that received the request in step 510 then notifies the card issuer or provider of the request. In step 520, the publisher or provider quickly finds the virtual machine (if any) needed to run the applet. Then in step 530, the virtual machine and applet are seamlessly loaded onto the card. This means that the user does not have to know (but can) know that the virtual machine has been searched and loaded into his card. The virtual machine and applet are activated in step 440, which can occur before, after, or at the same time as step 540. At step 550, the card selects and utilizes the appropriate APIs for virtual machines and applets. If the appropriate API does not exist, the issuer or provider loads the appropriate API into the card. Also, as in step 520, the user preferably does not need (but can) know that the API has been loaded into the card. In summary, this process is as fast and easy as possible for the user. When a request for an applet is made, the applet and all the software needed to make the applet work are the various things that can be needed to load and run your applet. The steps can be loaded very quickly and automatically without the user knowing. As mentioned earlier, providing the appropriate API is one way to activate virtual machines and / or applets.
<u style="single">Fee and royalty collection and distribution</u> If a virtual machine, applet, or other software application is activated, a license fee must be paid for the application. For example, if an applet requires digital rights management (DRM) used to control secure content loaded on a card, royalties may also be required for that content. In either case, the invention may be used for any type of royalty or license payment. Figure 8 depicts a system for payments to and from different entities. The consumer charge 805A is collected by the price collector 810. This preferably requires a secure service provided on the Internet. The price collector 810 reserves a portion of the charge for its service and transfers the rest of the charge to the device issuer 820. For example, if the content or program is loaded onto an SD card issued by SanDisk, SanDisk will be the card issuer 820 and will receive a portion 805B of fee 805. The publisher then saves some portion of the fee 805 and sends the portion 805C to the content owner or licensee 830. In the embodiments described so far, a Java virtual machine license and various applets running on the virtual machine can be paid for. The system can also be used more commonly to pay for other types of content that require a license. This payment system is also very useful for paying for content and the software required to represent that content to users of the device.
<u style="single">Security</u> In addition to safely activating virtual machines, device 100 also provides other security measures. Before the virtual machine is stored in flash memory, the card can require the card to be signed by the trusted authority mentioned above. In addition, various cryptographic techniques can be implemented to prevent the virtual machine (or other software application) from being tampered with, secretly activated, or illegally copied and installed on the device. The VM can be encrypted with various well-known hash functions, or instead the unique key of the device.
This encryption can be accomplished in software and / or hardware. This may require the use of MAC values, SHA-1 values, or hash values. The principles of these encryption / decryption techniques are well known and will not be discussed in detail here.
In one embodiment, the encryption is performed by an encryption engine implemented in the hardware of the controller. The crypto engine hardware loads the incoming data of the application into the memory of the card on the fly. Encrypt with fly). A controller is used to create a hash value that is specific to that controller, and binding to the controller serves as a kind of signature for the controller. This signature is then verified before the application is run. Implementing an encryption engine, at least in part (rather than entirely in firmware), in controller hardware provides a robust device that is extremely crack resistant. That's because the controller can't be replaced by an alternative controller (with a different signature), which is a common way to crack the security of a device. The controller signature cannot be easily forged. As can be seen in FIG. 9, the firmware 210 can have a boot loader part 210a, a system part 210b, and various MAC values, SHA-1 values, or hash values for the firmware, which they execute. It can be divided into multiple segments or overlays that can be individually loaded into RAM memory as much as possible. A US patent application by Holtzman et al. (Patent Document), which is hereby incorporated by reference in its entirety, to obtain further information on this and other aspects of the cryptographic technique utilized in certain embodiments of the present invention. Please refer to 2 ~ 4).
Various firmware applications can be seen stored in the flash memory space shown in Figure 9. Virtual machines and applets can be considered firmware applications. For example, the APP FW1 numbered 202a can contain a virtual machine, and the applet is the APP numbered 202b. Can be configured in / by FW2. If these pieces of firmware are split into overlays, the application firmware overlay map 201a shows where the various pieces of the application firmware "puzzle" are stored. Overlay hash values, SHA-1 values, or MAC values are stored in table 201b in flash memory in their own encrypted format. These values may themselves be encrypted and, in certain embodiments, may be encrypted with device-specific hardware encryption techniques as described above. In some embodiments, space is reserved in the flash memory for the virtual machine to facilitate integration and operation of the card with other firmware. This is partly secure that the security of the card provided by the firmware may be compromised by the virtual machine or by other applications running on the card and accessing the data stored in it. Especially important for cards.
Although embodiments of the present invention have been shown and described, modifications and modifications to those embodiments that are examples can be made without departing from the invention in its broader aspects. Thus, there are other embodiments of the invention that are not explicitly described earlier but are within the scope of the invention, and thus the scope of the invention is not limited to the embodiments presented in the embodiments. That should be clear. Therefore, it is understood that the appended claims describe the established limitations of the present invention. However, since words are an incomplete method of describing the scope of the invention, it is also understood that equivalent structures and methods not found in the words specified in the claims are also within the true scope of the invention. Should be.
3 sheets
Sheet 1 Sheet 2 Sheet 3
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2002279372A | Cites | Japan |
| JP2003323597A | Cites | Japan |
| JP2002358205A | Cites | Japan |
| JP2005190276A | Cites | Japan |
| JP2004259265A | Cites | Japan |
| JP2006018815A | Cites | Japan |
| JP2002169622A | Cites | Japan |
16 members in 7 offices
Priority claims14
| Document | Office | Kind | Date |
|---|---|---|---|
| 11463256 | United States of America | – | |
| 11463264 | United States of America | – | |
| 46325606 | United States of America | A | |
| 46325606 | United States of America | A | |
| 46326406 | United States of America | A | |
| 46326406 | United States of America | A | |
| 2007074399 | United States of America | W | |
| 2007074399 | United States of America | W | |
| 2006463256 | – | – | – |
| 2006463264 | – | – | – |
| 2007074399 | – | – | – |
| US20060463256 | – | – | – |
| US20060463264 | – | – | – |
| WO2007US74399 | – | – | – |
Members16
| Document | Office | Kind | |
|---|---|---|---|
| WO2008021682A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2008082447A1 | United States of America | A1 | |
| TW200820076A | Taiwan Province of China | A | |
| US2008126705A1 | United States of America | A1 | |
| WO2008021682A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2049991A2 | European Patent Office (EPO) | A2 | |
| KR20090048581A | Republic of Korea | A | |
| CN101501642A | China | A | |
| JP2010500656A | Japan | A | |
| US7725614B2 | United States of America | B2 | |
| US2010205457A1 | United States of America | A1 | |
| TWI357572B | Taiwan Province of China | B | |
| JP5118700B2This record | Japan | B2 | |
| US8447889B2 | United States of America | B2 | |
| KR101504647B1 | Republic of Korea | B1 | |
| CN101501642B | China | B |
21 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of change in applicantJAPANESE INTERMEDIATE CODE: A711A711 | A711 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 |
Numbers
- Publication
- 5118700
- Publication, DOCDB
- 5118700
- Publication, EPODOC
- JP5118700B
- Application
- 2009523886
- Application, DOCDB
- 2009523886
- Application, EPODOC
- JP20090523886
Titles2
- Japanese
- 仮想マシンのアクティブ化を伴う携帯可能な大容量記憶装置
- English
- Portable mass storage with virtual machine activation
Classification
- CPC, 5
- G06F21/10
- G06F8/54
- G06F21/79
- G06F3/06
- G06F12/00
- IPC, 4
- G06F21 10
- G06F21 74
- G06F12 00
- G06F21 79
