JP2005275744A - 携帯可能電子装置 - Google Patents

Abstract

【課題】アプリケーションがアプリケーション自身を削除（自己削除）することが可能となる携帯可能電子装置を提供する。
【解決手段】外部から入力されるアプリケーションを不揮発性メモリにロードし、このロードしたアプリケーションを実行することが可能な携帯可能電子装置において、アプリケーションの動作時、当該アプリケーションの状況や処理内容等により当該アプリケーションを削除するか否かを判断し、削除すると判断した場合には削除フラグをセットし、当該アプリケーションの処理が終了した後、削除フラグを確認し、セットされている場合、当該アプリケーションを削除する。
【選択図】 図１

Description

本発明は、たとえば、書込み、書換え可能な不揮発性メモリおよびＣＰＵなどの制御素子を有したＩＣチップを内蔵し、外部から入力されるコマンドに対応した処理を実行してその処理結果を外部へ出力し、かつ、外部から入力されるアプリケーションを不揮発性メモリにロード（あるいは、インストール）し、このロードしたアプリケーションを実行することが可能なＩＣカードなどの携帯可能電子装置に関する。

最近、たとえば、電子商取引（ＥＣ）などの分野で電子マネーとして注目されているＩＣカードは、書込み、書換えが可能な不揮発性メモリおよびこれを管理、制御するためのＣＰＵなどの制御素子を有したＩＣチップがプラスチック板などで構成されるカードの内部に埋設されている構造となっている。

ところで、この種のＩＣカードは、通常、カード内のアプリケーション（アプリケーションプログラム）がＩＣカード（ＩＣチップ）の製造メーカ独自の言語で作成され、そのうえＲＯＭに記憶されていたために、ＩＣカード（ＩＣチップ）の提供者以外が、アプリケーションを（一般言語で）作成することや、アプリケーションを追加したり削除したりすることが不可能であった。

そこで、これらの不都合を解決するために、いわゆるＪａｖａカード（Ｊａｖａは米サン・マイクロシステムズ社の登録商標）と称されるＩＣカードが開発された（たとえば、特許文献１参照）。Ｊａｖａカードは、一般的なＩＣカードのＯＳ（オペレーティングシステム）の上にバーチャルマシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）をのせたＩＣカードであり、その特徴は、Ｊａｖａ言語でアプリケーション（以下、アプレットとも言う）を作成することが可能で、カード発行者などの権限を持った人であれば、Ｊａｖａカード内のアプリケーションを追加したり削除したりすることが可能であることにある。
特開２０００−３４８１４６号公報

しかし、アプレット自身には、アプレットを追加したり削除したりする機能が存在しない。各アプレットの独立性を確保するために、アプレットの追加は必要ないとしても、アプレットによって自身のアプレットを削除する機能は必要とされている。たとえば、アプレットの有効期限超過をアプレットが認識している場合、残高が「０」などで使用されないことが明確な電子マネーのアプレットの場合、あるいは、不具合が存在しシステムへの影響から自主的に削除されることが望まれるアプレットの場合、あるいは、発行者の権限を必要としないでアプレットを削除したい場合など、の場合に自己削除機能が有効と考えられる。

ただし、実行しているアプレットを削除することは、実際には不可能である。また、アプレットが削除されることにより、ＩＣカードがレスポンスを送信することができなくなる恐れがある。

そこで、本発明は、アプリケーションがアプリケーション自身を削除（自己削除）することが可能となる携帯可能電子装置を提供することを目的とする。

本発明の携帯可能電子装置は、外部から入力されるアプリケーションをメモリにロードし、このロードしたアプリケーションを実行することが可能な携帯可能電子装置において、アプリケーションの動作時、当該アプリケーションの状況や処理内容等により当該アプリケーションを削除するか否かを判断し、削除すると判断した場合にはアプリケーションを削除するか否かを示す削除確認情報を有効状態にセットする第１の手段と、当該アプリケーションの処理が終了した後、前記削除確認情報を参照し、当該削除確認情報が有効状態にセットされている場合、当該アプリケーションを前記メモリから削除する第２の手段とを具備している。

本発明によれば、アプリケーションにコマンドを送信するシステムのみならず、アプリケーションが状況、処理内容を判断してアプリケーション自身を削除することが可能となる携帯可能電子装置を提供できる。

以下、本発明の実施の形態について図面を参照して説明する。
図１は、本実施の形態に係るＩＣカードの一例としてＪａｖａカードのハードウエア構成を概略的に示すものである。このＪａｖａカードは、全体的な管理、制御を司るＣＰＵ（セントラル・プロセッシング・ユニット）１１、ＣＰＵ１１の制御用プログラムなどが格納されたＲＯＭ（リード・オンリ・メモリ）１２、ワーキングメモリとしてのＲＡＭ（ランダム・アクセス・メモリ）１３、上位装置（カードリーダライタなど）と通信を行なうための通信ユニット（ＵＡＲＴ）１４、各種データやアプリケーション（アプリケーションプログラム）を記憶する不揮発性メモリ（ＮＶ（ＥＥＰＲＯＭ））１５、演算の補助を行なうコプロセッサ（Ｃｏ−Ｐｒｏ）１６、計時動作を行なうタイマ１７から構成されている。

図２は、上述したＪａｖａカードのソフトウエア構成を模式的に示すものである。前述した通信ユニット（ＵＡＲＴ）１４、不揮発性メモリ（ＮＶ（ＥＥＰＲＯＭ））１５、コプロセッサ１６などのハードウエア（Ｈ／Ｗ）層２１は、ＯＳ（オペレーティングシステム）層２２のカードＯＳで制御される。ＯＳ層２２は、Ｊａｖａカードを動作させるための環境を含めたバーチャルマシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）、アプレット（アプリケーション）の管理をするＩ．Ｓ．Ｄ．（Ｉｓｓｕｅｒ Ｓｅｃｕｒｉｔｙ Ｄｏｍａｉｎ）、アプレットの関数であるＡＰＩ（ＡＰｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）といったモジュールがカードＯＳにのった状態となっていて、アプリケーション（アプレット）層２３が最上位に位置する。アプリケーション層２３は、たとえば、複数のアプレット（Ａｐｐｌｅｔ１、Ａｐｐｌｅｔ２、Ａｐｐｌｅｔ３）からなる。

次に、このような構成において、アプレットの自己削除に係る処理の流れについて説明する。
たとえば、上述したＩＣカードにおいて、Ａｐｐｌｅｔ１が自己削除する場合、Ａｐｐｌｅｔ１が削除されるタイミングは、以下の４つが考えられる。
ａ．カードリーダライタへの送信データを設定し、Ａｐｐｌｅｔ１の処理が終了した
直後
ｂ．次のコマンドを受信した直後
ｃ．次に活性化された直後
ｄ．次に当該Ａｐｐｌｅｔ１を選択する直前
また、アプレットの構成上、削除対象も以下の２パターンが考えられる。
Ａ．アプレットのインスタンス（データ）のみを削除、すなわち、Ａｐｐｌｅｔ１の
インスタンスのみ削除
Ｂ．アプレットの全てを削除、すなわち、Ａｐｐｌｅｔ１のロードファイル（コー
ド）とインスタンス（データ）の全てを削除
したがって、アプレットを削除するＡＰＩのインタフェイスは、最低でもＡ、Ｂを識別する引数を必要とし、場合によっては、削除するタイミングａ〜ｄを識別する引数も実装する必要がある。また、戻り値として、正常（ＴＲＵＥ）／異常終了（ＦＡＬＳＥ）を実装する必要もある。

以下、削除するタイミングが上記ａで、削除対象パターンが上記Ｂの場合について具体例を挙げて説明する。アプレットを削除する関数（ｄｅｌｅｔｅＡｐｐｌｅｔ（））は、カードＯＳに実装されていて、引数として、上記ＡまたはＢの設定を必要とし、戻り値として正常（ＴＲＵＥ）／異常終了（ＦＡＬＳＥ）を返すインタフェイスを持つ。また、アプレットは、たとえば、電子マネーを取扱うアプレットであり、商品等を購入すると、アプレット内の電子マネーが減算される。ただし、電子マネーを補充できないために、残高が０円に到達した場合、アプレットの存在意義がなくなるので、自己削除処理を実行するものとする。

図３に示すフローチャートは、アプレットの自己削除が発生しない、つまりは電子マネーの残高が０円にならない場合の処理の流れを示すもので、以下それについて説明する。
たとえば、電子マネーが残高として１、０００円存在し、１００円の商品を購入すると、上位装置からカードリーダライタ経由で電子マネーを１００円減算するコマンドが送信される（図３の丸数字「１」に対応）。すると、カードＯＳは、そのコマンドをカレント状態の（選択されている）電子マネーのアプレットに転送する。

当該コマンドを受取ったアプレットは、電子マネーの残高を計算し（図３の丸数字「２」に対応）、正常に処理できたことを上位装置に伝えるための送信データを作成し（図３の丸数字「３」に対応）、アプレットの処理を終了する。アプレットの処理が終了すると、カードＯＳは、カレント状態のアプレットに対応する削除フラグ（削除確認情報）の有効性を確認する（図３の丸数字「４」に対応）。この場合、削除フラグはリセット状態（無効状態）にあるので、作成した送信データを上位装置に送信する（図３の丸数字「５」に対応）。ここに、削除フラグは不揮発性メモリ１５内に設けられているものとする。

図４に示すフローチャートは、アプレットの自己削除が発生する、つまりは電子マネーの残高が０円になる場合の処理の流れを示すもので、以下それについて説明する。
たとえば、電子マネーが残高として１００円存在し、１００円の商品を購入すると、上位装置からカードリーダライタ経由で電子マネーを１００円減算するコマンドが送信される（図４の丸数字「１」に対応）。すると、カードＯＳは、そのコマンドをカレント状態の（選択されている）電子マネーのアプレットに転送する。

当該コマンドを受取ったアプレットは、電子マネーの残高を計算する（図４の丸数字「２」に対応）。残高が０円になる今回は、アプレット自己削除用のＡＰＩであるｄｅｌｅｔｅＡｐｐｌｅｔ（全て）を呼出す（図４の丸数字「３」に対応）。インスタンスのみならず、ロードファイルも削除するために、引数は（全て）である。呼び出されたＡＰＩ（ｄｅｌｅｔｅＡｐｐｌｅｔ（））は、カードＯＳ内に保持しているアプレット（全てなので、Ａｐｐｌｉｃａｔｉｏｎ（Ｉｎｓｔａｎｃｅ）とＬｏａｄ Ｆｉｌｅ）の管理情報における削除フラグをセットする（図４の丸数字「４」、「５」に対応）。そして、当該ｄｅｌｅｔｅＡｐｐｌｅｔ（）の処理を正常終了（ＴＲＵＥ）する。

次に、アプレットは、ｄｅｌｅｔｅＡｐｐｌｅｔ（）の戻り値が正常終了であることを確認のうえ、減算が正常に処理できたことを上位装置に伝えるための送信データを作成し（図４の丸数字「６」に対応）、アプレットの処理を終了する。アプレットの処理が終了すると、カードＯＳは、カレント状態のアプレットに対応する削除フラグの有効性を確認する（図４の丸数字「７」に対応）。

この場合には、既にアプレットの管理情報内の削除フラグがセット（有効状態に）されているので、上位装置に正常終了データを送信する前に、不揮発性メモリ１５からの当該アプレットの削除を実施する（図４の丸数字「８」に対応）。アプレットの削除後は、別のアプレットがロード（インストール）可能な状態になる。最後に、作成した送信データを上位装置に送信する（図４の丸数字「９」に対応）。

次に、削除するタイミングが前記ｂで、削除対象パターンが前記Ｂの場合で、アプレットの自己削除が発生する、つまりは電子マネーの残高が０円になる場合の具体的な処理の流れについて図５に示すフローチャートを参照して説明する。

たとえば、電子マネーが残高として１００円存在し、１００円の商品を購入すると、上位装置からカードリーダライタ経由で電子マネーを１００円減算するコマンドが送信される（図５の丸数字「１」に対応）。すると、カードＯＳは、そのコマンドをカレント状態の（選択されている）電子マネーのアプレットに転送する。

当該コマンドを受取ったアプレットは、電子マネーの残高を計算する（図５の丸数字「２」に対応）。残高が０円になる今回は、アプレット自己削除用のＡＰＩであるｄｅｌｅｔｅＡｐｐｌｅｔ（全て）を呼出す（図５の丸数字「３」に対応）。インスタンスのみならず、ロードファイルも削除するために、引数は（全て）である。呼出されたＡＰＩ（ｄｅｌｅｔｅＡｐｐｌｅｔ（））は、カードＯＳ内に保持しているアプレット（全てなので、Ａｐｐｌｉｃａｔｉｏｎ（Ｉｎｓｔａｎｃｅ）とＬｏａｄ Ｆｉｌｅ）の管理情報における削除フラグをセットする（図５の丸数字「４」、「５」に対応）。そして、当該ｄｅｌｅｔｅＡｐｐｌｅｔ（）の処理を正常終了（ＴＲＵＥ）する。

次に、アプレットは、ｄｅｌｅｔｅＡｐｐｌｅｔ（）の戻り値が正常終了であることを確認のうえ、減算が正常に処理できたことを上位装置に伝えるための送信データを作成し（図５の丸数字「６」に対応）、アプレットの処理を終了する。そして、作成した送信データを上位装置に送信する（図５の丸数字「７」に対応）。

その後、次の処理に対するコマンドが送信されると（図５の丸数字「８」に対応）、カードＯＳは、削除フラグの有効性を確認する（図５の丸数字「９」に対応）。この場合、既に削除フラグがセット（有効状態に）されているので、不揮発性メモリ１５からの当該アプレットの削除を実施する（図５の丸数字「１０」に対応）。アプレットの削除後は、別のアプレットがロード（インストール）可能な状態になる。

次に、次のコマンドに対する本来の処理を実施し（図５の丸数字「１１」に対応）、当該処理の終了後、正常終了データ（送信データ）を上位装置に送信する（図５の丸数字「１２」に対応）。

次に、削除するタイミングが前記ｃで、削除対象パターンが前記Ｂの場合で、アプレットの自己削除が発生する、つまりは電子マネーの残高が０円になる場合の具体的な処理の流れについて図６に示すフローチャートを参照して説明する。

たとえば、電子マネーが残高として１００円存在し、１００円の商品を購入すると、上位装置からカードリーダライタ経由で電子マネーを１００円減算するコマンドが送信される（図６の丸数字「１」に対応）。すると、カードＯＳは、そのコマンドをカレント状態の（選択されている）電子マネーのアプレットに転送する。

当該コマンド受取ったアプレットは、電子マネーの残高を計算する（図６の丸数字「２」に対応）。残高が０円になる今回は、アプレット自己削除用のＡＰＩであるｄｅｌｅｔｅＡｐｐｌｅｔ（全て）を呼出す（図６の丸数字「３」に対応）。インスタンスのみならず、ロードファイルも削除するために、引数は（全て）である。呼出されたＡＰＩ（ｄｅｌｅｔｅＡｐｐｌｅｔ（））は、カードＯＳ内に保持しているアプレット（全てなので、Ａｐｐｌｉｃａｔｉｏｎ（Ｉｎｓｔａｎｃｅ）とＬｏａｄ Ｆｉｌｅ）の管理情報における削除フラグをセットする（図６の丸数字「４」、「５」に対応）。そして、当該ｄｅｌｅｔｅＡｐｐｌｅｔ（）の処理を正常終了（ＴＲＵＥ）する。

次に、アプレットは、ｄｅｌｅｔｅＡｐｐｌｅｔ（）の戻り値が正常終了であることを確認のうえ、減算が正常に処理できたことを上位装置に伝えるための送信データを作成し（図６の丸数字「６」に対応）、アプレットの処理を終了する。そして、作成した送信データをホスト装置に送信する（図６の丸数字「７」に対応）。

その後、再びＩＣカードが挿入され（図６の丸数字「８」に対応）、リセットが解除されると（図６の丸数字「９」に対応）、カードＯＳは、たとえば、自己診断処理を実行し（図６の丸数字「１０」に対応）、当該自己診断の終了後、削除フラグの有効性を確認する（図６の丸数字「１１」に対応）。この場合、既に削除フラグがセット（有効状態に）されているので、不揮発性メモリ１５からの当該アプレットの削除を実施する（図６の丸数字「１１」に対応）。アプレットの削除後は、別のアプレットがロード（インストール）可能な状態になる。
次に、カードＯＳは、初期応答データ（ＡＴＲ）を上位装置に送信する（図６の丸数字「１３」に対応）。

なお、削除するタイミングが前記ｄで、削除対象パターンが前記Ｂの場合で、アプレットの自己削除が発生する場合の具体的な処理の流れについての詳細な説明は省略するが、この場合は、上位装置から電子マネーのアプレットを選択するコマンドをカードＯＳが受信した直後に、削除フラグの確認処理とアプレットの削除処理を実施すればよい。

このように、アプレットの処理が正常に終了し、送信データ（正常終了データ）を送信した上で、アプレットの自己削除が可能となる。すなわち、アプレット（アプリケーション）が、アプレット自身を削除（自己削除）するＡＰＩを持ったＩＣカード（Ｊａｖａカード）が得られるものである。したがって、アプレットにコマンドを送信するシステムのみならず、アプレットが状況、処理内容を判断して自身のアプレットを削除することが可能となる。ただし、実際には、ＡＰＩ実行時にアプレットの削除を実施するのではなく、アプレットの処理終了後にカードＯＳが削除処理を実施するものである。

これにより、たとえば、アプレットに不具合が発生した場合、アプレットの有効期限が超過した場合などに、自身でアプレットを削除することが可能となる。自己削除をするＡＰＩを実行しても、アプレット自身の処理が終わるまで、削除は開始されず、アプレットは削除される前に、任意のデータ（レスポンス）を上位装置へ送信することが可能である。

本発明の実施の形態に係るＩＣカードの一例としてＪａｖａカードのハードウエア構成を概略的に示すブロック図。 Ｊａｖａカードのソフトウエア構成を模式的に示す図。 アプレットの自己削除が発生しない場合の処理の流れを説明するフローチャート。 アプレットの自己削除が発生する場合の第１の処理例の流れを説明するフローチャート。 アプレットの自己削除が発生する場合の第２の処理例の流れを説明するフローチャート。 アプレットの自己削除が発生する場合の第３の処理例の流れを説明するフローチャート。

符号の説明

１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…通信ユニット（ＵＡＲＴ）、１５…不揮発性メモリ（ＮＶ（ＥＥＰＲＯＭ））、１６…コプロセッサ（Ｃｏ−Ｐｒｏ）。

Claims (6)

1. 外部から入力されるアプリケーションをメモリにロードし、このロードしたアプリケーションを実行することが可能な携帯可能電子装置において、
   アプリケーションの動作時、当該アプリケーションの状況や処理内容等により当該アプリケーションを削除するか否かを判断し、削除すると判断した場合にはアプリケーションを削除するか否かを示す削除確認情報を有効状態にセットする第１の手段と、
   当該アプリケーションの処理が終了した後、前記削除確認情報を参照し、当該削除確認情報が有効状態にセットされている場合、当該アプリケーションを前記メモリから削除する第２の手段と、
   を具備したことを特徴とする携帯可能電子装置。
2. 外部から入力されるコマンドに対応した処理を実行してその処理結果を外部へ出力し、かつ、外部から入力されるアプリケーションをメモリにロードし、このロードしたアプリケーションを実行することが可能な携帯可能電子装置において、
   外部からコマンドが入力され、そのコマンドに対応したアプリケーションの動作時、当該アプリケーションの状況や処理内容等により当該アプリケーションを削除するか否かを判断し、削除すると判断した場合にはアプリケーションを削除するか否かを示す削除確認情報を有効状態にセットする第１の手段と、
   外部から次のコマンドが入力された際、前記削除確認情報を参照し、当該削除確認情報が有効状態にセットされている場合、当該アプリケーションを前記メモリから削除する第２の手段と、
   を具備したことを特徴とする携帯可能電子装置。
3. 外部から入力されるアプリケーションをメモリにロードし、このロードしたアプリケーションを実行することが可能な携帯可能電子装置において、
   アプリケーションの動作時、当該アプリケーションの状況や処理内容等により当該アプリケーションを削除するか否かを判断し、削除すると判断した場合にはアプリケーションを削除するか否かを示す削除確認情報を有効状態にセットする第１の手段と、
   当該携帯可能電子装置の起動後、前記削除確認情報を参照し、当該削除確認情報が有効状態にセットされている場合、当該アプリケーションを前記メモリから削除する第２の手段と、
   を具備したことを特徴とする携帯可能電子装置。
4. 外部から入力されるアプリケーションをメモリにロードし、このロードしたアプリケーションを実行することが可能な携帯可能電子装置において、
   アプリケーションの動作時、当該アプリケーションの状況や処理内容等により当該アプリケーションを削除するか否かを判断し、削除すると判断した場合にはアプリケーションを削除するか否かを示す削除確認情報を有効状態にセットする第１の手段と、
   当該携帯可能電子装置の起動後に行なわれるアプリケーションの選択時、前記削除確認情報を参照し、当該削除確認情報が有効状態にセットされている場合、当該アプリケーションを前記メモリから削除する第２の手段と、
   を具備したことを特徴とする携帯可能電子装置。
5. 前記第２の手段は、アプリケーションの全てを前記メモリから削除することを特徴とする請求項１ないし請求項４のうちいずれか１つに記載の携帯可能電子装置。
6. 前記第２の手段は、アプリケーションの特定部分のみを前記メモリから削除することを特徴とする請求項１ないし請求項４のうちいずれか１つに記載の携帯可能電子装置。

Images