(57)【要約】【課題】外部端末から受信するコマンドに応じてフラッシュメモリの更新を行う電子情報記憶媒体において、適切なタイミングで当該フラッシュメモリにおける断片化した空き領域から連続した空き領域を生成する。【解決手段】フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除し、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する。【選択図】図３
2018014014.tif 000002
【特許請求の範囲】
【請求項１】
複数のページを含むフラッシュメモリと、外部端末から受信するコマンドに応じて前記フラッシュメモリの更新をページ単位で実行する実行部とを備える電子情報記憶媒体であって、
前記実行部は、
前記フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除する削除手段と、
前記削除手段がデータを削除した場合に、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する位置変更処理を行う変更手段と、
を備えることを特徴とする電子情報記憶媒体。
【請求項２】
請求項１に記載の電子情報記憶媒体であって、
前記削除手段は、前記フラッシュメモリに所定サイズ以上の連続する空きページがある場合には、前記位置変更処理を行わないことを特徴とする電子情報記憶媒体。
【請求項３】
請求項１又は２に記載の電子情報記憶媒体であって、
前記フラッシュメモリは、アプリケーションに関する前記データを記憶し、
前記削除手段は、前記アプリケーションに関する少なくとも一部のデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除し、
前記変更手段は、前記削除対象のデータの削除前に前記アプリケーションに関するデータが複数ページにわたって記憶されている場合に、当該削除対象のデータの削除によりできた空き領域に当該空き領域を含むページとは異なる他ページに記憶されているデータを移動するように当該データが記憶される位置を変更して前記他ページを空きページとする空きページ生成処理を行うことを特徴とする電子情報記憶媒体。
【請求項４】
請求項３に記載の電子情報記憶媒体であって、
前記変更手段は、前記空きページ生成処理を行う前に、前記削除対象のデータの削除によりできる空き領域に前記他ページに記憶されているデータを移動することにより当該他ページを前記空きページとすることができるか判定し、当該他ページを前記空きページとすることができると判定した場合に前記空きページ生成処理を行うことを特徴とする電子情報記憶媒体。
【請求項５】
請求項１に記載の電子情報記憶媒体であって、
前記実行部は、
２以上の所定数のページで構成されるページ群単位で、データが記憶されているか否かを管理する管理手段、を更に備え、
前記変更手段は、前記削除手段がデータを削除した結果、全てのページが前記空きページとなったページ群に対応する記憶領域に、前記空きページでないページを含む他のページ群に対応する記憶領域に記憶されているデータを移動させることを特徴とする電子情報記憶媒体。
【請求項６】
複数のページを含むフラッシュメモリと、外部端末から受信するコマンドに応じて前記フラッシュメモリの更新をページ単位で実行する実行部とを備える電子情報記憶媒体による情報処理方法であって、
前記実行部が、前記フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除する削除工程と、
前記実行部が、前記削除工程によりデータを削除した場合に、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する位置変更処理を行う変更工程と、
を含むことを特徴とする情報処理方法。
【請求項７】
複数のページを含むフラッシュメモリと、外部端末から受信するコマンドに応じて前記フラッシュメモリの更新をページ単位で実行するコンピュータとを備える電子情報記憶媒体における前記コンピュータを、
前記フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除する削除手段、
前記削除手段がデータを削除した場合に、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する位置変更処理を行う変更手段、
として機能させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
ＩＣチップ等の電子情報記憶媒体の技術分野に関する。
【背景技術】
【０００２】
従来のＮＦＣ（Near Field Communication）非対応のＵＩＭ（User Identity Module）カードは、ＵＩＭ上のアプリケーションとして基本的に携帯電話サービスに必要となるアプリケーション（以下、「ＴＥＬアプリ」という）のみを搭載していた。一方、近年普及が進むＮＦＣ対応のＵＩＭカードは、ＴＥＬアプリに加え、クレジット決済サービス等の付加サービス用アプリケーション（以下、「付加サービスアプリ」という）を搭載している。また、ＮＦＣ対応のＵＩＭカードは、不揮発性メモリとして従来のＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）ではなく、大容量なＮＯＲ型フラッシュメモリを搭載するようになっている。
【０００３】
ＮＦＣ非対応のＵＩＭカードは、付加サービスアプリの追加を想定していないため、メモリ上の各領域の境界アドレスが変わったり、新しくデータを記憶する領域が増えたり、データを記憶する既存の領域が削除されることはない。これに対して、ＮＦＣ対応のＵＩＭカードは、ユーザの意思によりさまざまな付加サービスアプリが導入、活性化、削除される。これらの付加サービスアプリはサービス内容に依存してプログラムコードサイズ、ユーザデータサイズはさまざまである。よって、付加サービスアプリに関するデータの追加、削除を繰り返すことにより複数の小さな空き領域（断片化した空き領域）が生まれる。これらの空き領域を柔軟に活用するためは、連続した空き領域を生成する処理（デフラグメンテーション処理／メモリコンパクション処理）が必要となる。
【０００４】
そうした中、特許文献１には、データファイルの分割度合いを検出して、分割度合いに応じて互いにデータの内容が連続する位置に記録されるようにデータを移動させるデフラグ処理について開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第３４２１８９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に記載の技術は、ＵＩＭカードのように外部端末から受信するコマンドに応じてメモリの更新等を行うことは想定されておらず、デフラグ処理を実行するタイミングについて何ら開示されていないため、ＵＩＭカード等の電子情報記憶媒体について適用することが困難であるという問題がある。
【０００７】
そこで、本発明は、外部端末から受信するコマンドに応じてフラッシュメモリの更新を行う電子情報記憶媒体において、適切なタイミングで当該フラッシュメモリにおける断片化した空き領域から連続した空き領域を生成することができる電子情報記憶媒体等を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、請求項１に記載の発明は、複数のページを含むフラッシュメモリと、外部端末から受信するコマンドに応じて前記フラッシュメモリの更新をページ単位で実行する実行部とを備える電子情報記憶媒体であって、前記実行部は、前記フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除する削除手段と、前記削除手段がデータを削除した場合に、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する位置変更処理を行う変更手段と、を備えることを特徴とする。
【０００９】
請求項２に記載の発明は、請求項１に記載の電子情報記憶媒体であって、前記削除手段は、前記フラッシュメモリに所定サイズ以上の連続する空きページがある場合には、前記位置変更処理を行わないことを特徴とする。
【００１０】
請求項３に記載の発明は、請求項１又は２に記載の電子情報記憶媒体であって、前記フラッシュメモリは、アプリケーションに関する前記データを記憶し、前記削除手段は、前記アプリケーションに関する少なくとも一部のデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除し、前記変更手段は、前記削除対象のデータの削除前に前記アプリケーションに関するデータが複数ページにわたって記憶されている場合に、当該削除対象のデータの削除によりできた空き領域に当該空き領域を含むページとは異なる他ページに記憶されているデータを移動するように当該データが記憶される位置を変更して前記他ページを空きページとする空きページ生成処理を行うことを特徴とする。
【００１１】
請求項４に記載の発明は、請求項３に記載の電子情報記憶媒体であって、前記変更手段は、前記空きページ生成処理を行う前に、前記削除対象のデータの削除によりできる空き領域に前記他ページに記憶されているデータを移動することにより当該他ページを前記空きページとすることができるか判定し、当該他ページを前記空きページとすることができると判定した場合に前記空きページ生成処理を行うことを特徴とする。
【００１２】
請求項５に記載の発明は、請求項１に記載の電子情報記憶媒体であって、前記実行部は、２以上の所定数のページで構成されるページ群単位で、データが記憶されているか否かを管理する管理手段、を更に備え、前記変更手段は、前記削除手段がデータを削除した結果、全てのページが前記空きページとなったページ群に対応する記憶領域に、前記空きページでないページを含む他のページ群に対応する記憶領域に記憶されているデータを移動させることを特徴とする。
【００１３】
請求項６に記載の発明は、複数のページを含むフラッシュメモリと、外部端末から受信するコマンドに応じて前記フラッシュメモリの更新をページ単位で実行する実行部とを備える電子情報記憶媒体による情報処理方法であって、前記実行部が、前記フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除する削除工程と、前記実行部が、前記削除工程によりデータを削除した場合に、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する位置変更処理を行う変更工程と、を含むことを特徴とする。
【００１４】
請求項７に記載の発明は、複数のページを含むフラッシュメモリと、外部端末から受信するコマンドに応じて前記フラッシュメモリの更新をページ単位で実行するコンピュータとを備える電子情報記憶媒体における前記コンピュータを、前記フラッシュメモリが記憶するデータを削除対象とする削除コマンドを受信した場合に、当該削除対象のデータを削除する削除手段、前記削除手段がデータを削除した場合に、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更する位置変更処理を行う変更手段、として機能させることを特徴とする。
【発明の効果】
【００１５】
本発明によれば、削除コマンドを受信した際にフラッシュメモリにおける断片化した空き領域から連続した空き領域を生成することができる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態に係る携帯端末１の概要構成例を示すブロック図である。
【図２】本実施形態に係るＵＩＭカード１８の概要構成例を示すブロック図である。
【図３】本実施形態に係るフラッシュメモリ１８３のデフラグ処理前のデータ記憶状況（図３（Ａ））と、デフラグ処理後のデータ記憶状況（図３（Ｂ））の例を示す図である。
【図４】本実施形態に係るフラッシュメモリ１８３のデータ削除前のデータ記憶状況（図４（Ａ））と、データ（ＦＡ３）削除後のデータ記憶状況（図４（Ｂ））の例を示す図である。
【図５】本実施形態に係るフラッシュメモリ１８３のデータ（ＦＡ２）削除後のデータ記憶状況（図５（Ａ））と、アプリ内デフラグ処理後のデータ記憶状況（図５（Ｂ））の例を示す図である。
【図６】ＣＰＵ１８１によるコマンド受信時処理の処理例を示すフローチャートである。
【図７】ＣＰＵ１８１による第１デフラグ処理の処理例を示すフローチャートである。
【図８】ＣＰＵ１８１による第２デフラグ処理の処理例を示すフローチャートである。
【図９】フラッシュメモリ１８３を複数ページ単位で管理する変形例において、フラッシュメモリ１８３のアプリＢ削除前のデータ記憶状況（図９（Ａ））と、アプリＢ削除後のデータ記憶状況（図９（Ｂ））の例を示す図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、携帯端末に備えられたＵＩＭカードに搭載されるＩＣチップに対して本発明を適用した場合の実施の形態である。
【００１８】
まず、図１等を参照して、本実施形態に係る携帯端末１の構成及び機能概要を説明する。
【００１９】
［１．携帯端末１の構成］
図１は、本実施形態に係る携帯端末１の概要構成例を示すブロック図である。図１に示すように、携帯端末１は、制御部１１、記憶部１２、無線通信部１３、表示部１４、入力部１５、ＣＬＦインターフェース１６ａ、ＩＣカードインターフェース１６ｂ、及びＣＬＦ１９等を備えて構成され、これらの構成要素はバス１７を介して相互に接続される。なお、携帯端末１は、例えば携帯電話機やスマートフォン、タブレット端末等である。
【００２０】
制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）等により構成される。記憶部１２は、例えばフラッシュメモリ等の不揮発性メモリにより構成される。上記ＲＯＭまたは記憶部１２には、ＯＳ（Operating System）及びミドルウェアが記憶される。また、記憶部１２には、携帯端末１にインストールされたＡＰＩ（Application Program Interface）及びアプリケーションソフトウェア（アプリケーションプログラム言語から構成されるソフトウェア）等が記憶される。ＡＰＩは、アプリケーションソフトウェアからオペレーティングシステムの機能を利用するためのインターフェースである。アプリケーションソフトウェアは、例えば所定のサーバからダウンロード可能なプログラムである。
【００２１】
無線通信部１３は、アンテナを有し、移動体通信網における基地局との間で行われる無線通信を制御する。表示部１４は、例えばタッチパネル方式の表示パネルを有し、表示パネルへの表示制御、及びユーザからの操作指示の受け付けを行う。入力部１５は、ユーザからの操作指示を入力するための操作ボタンを有し、操作ボタンに応じた信号を制御部１１に出力する。ＣＬＦインターフェースは、制御部１１とＣＬＦ１９との間のインターフェースを担い、ＩＣカードインターフェース１６ｂは、制御部１１とＵＩＭカード１８との間のインターフェースを担う。
【００２２】
ＵＩＭカード１８は、ＵＩＣＣ（Universal Integrated Circuit Card）の一つであり、例えば、従来のＳＩＭ（Subscriber Identity Module）をベースに機能を拡張された接触型ＩＣチップを搭載する。
【００２３】
ＣＬＦ１９は、ＮＦＣの規格で規定される非接触通信を行う非接触型ＩＣチップであり、非接触通信のフィールド内で読取装置（図示せず）との間で各種信号の送受信を行うためのアンテナに接続されている。そして、ユーザが携帯端末１を読取装置に翳すと、読取装置から送信されたコマンドを、インターフェイス（図示せず）を介してＵＩＭカード１８へ送信し、ＵＩＭカード１８から送信された、コマンドに対する応答を読取装置に返すようになっている。なお、ＣＬＦ１９は、携帯端末１のＯＳにより操作可能になっている。
【００２４】
［２．ＩＣチップＣの構成］
図２は、本実施形態に係るＵＩＭカード１８に搭載されるＩＣチップＣの概要構成例を示すブロック図である。図２に示すように、ＩＣチップＣは、ＣＰＵ１８１（「実行部」、「コンピュータ」の一例）、ＲＡＭ１８２、フラッシュメモリ１８３、及びＩ／Ｏ回路１８４等を備え、これらの構成要素はバス１８５を介して相互に接続される。
【００２５】
ＲＡＭ１８２には、例えばＯＳ、ミドルウェア、各種アプリケーションが機能するうえで一時的に必要となるデータが記憶される。
【００２６】
フラッシュメモリ１８３は、例えばＮＯＲ型フラッシュメモリであって、ＯＳ、ミドルウェア及びアプリケーション（ＴＥＬアプリや付加サービスアプリ）等を記憶する。フラッシュメモリ１８３はページ（又はブロック）と呼ばれる固定長サイズ（ページサイズは例えば６４／１２８／２５６バイト）単位で記憶領域の更新処理が行われる。例えば、ページ１にデータＡとデータＢが記憶されており、データＡのみを消去する場合、ページ１の内容をＲＡＭ１８２に退避（コピー）して、退避した内容からデータＡのみを削除しておき、そして、フラッシュメモリ１８３のページ１に対応する領域を消去した後、この領域にＲＡＭ１８２に退避した内容（データＡを削除した内容）を書き込む。
【００２７】
Ｉ／Ｏ回路１８４は、ＩＳＯ７８１６等によって定められた、Ｃ１〜Ｃ８の８個の接続端子を有する。ここで、Ｃ１端子は電源端子（ＶＣＣ）であり、Ｃ５端子はグランド端子（ＧＮＤ）である。また、Ｃ２端子は、リセット端子（ＲＳＴ）であり、Ｃ３端子は、クロック端子（ＣＬＫ）である。また、Ｃ７端子は、ＣＰＵ１８１と制御部１１との間の通信のために用いられる。また、Ｃ６端子は、ＣＰＵ１８１とＣＬＦ１９との間の通信のために用いられる。なお、ＣＰＵ１８１とＣＬＦ１９間の通信プロトコルには、ＳＷＰ（Single Wire Protocol）が適用される。
【００２８】
ＣＰＵ１８１は、ＣＬＦ１９からコマンドを受信すると、当該コマンドに応じたコマンド処理を実行し、コマンドに対する応答をＣＬＦ１９に対して行う。また、ＣＰＵ１８１は、制御部１１からコマンドを受信すると、当該コマンドに応じたコマンド処理を実行し、コマンドに対する応答を制御部１１に対して行う。
【００２９】
次に、付加サービスアプリの導入、活性化、削除について説明する。まず、付加サービスアプリの導入とは、付加サービスアプリのプログラム（バイナリデータ）をフラッシュメモリ１８３上へ書き込むことを意味する。この処理をロード（Ｌｏａｄ）処理という。なお、書き込むプログラムのサイズはアプリケーションの機能数やその内容に依存するが、一般的に大きなサイズ（数Ｋから数十Ｋバイト程度）であることが多いため、連続した大きなサイズの空き領域が必要となる。
【００３０】
付加サービスアプリの活性化とは、付加サービスアプリのロード処理で書き込んだプログラムを基にアプリの実態としてインスタンスを生成しフラッシュメモリ１８３上へ書き込むことを意味する。この処理をインストール（Ｉｎｓｔａｌｌ）処理という。なお、書き込む全インスタンスサイズはアプリケーションが保持するデータの数や各データのサイズに依存するが、ＵＩＭカード１８のようなＮＦＣ対応ＵＩＭカード向けアプリケーションの多くは、プログラム同様に大きなサイズであることが多いため、連続した大きなサイズの空き領域が必要となる。
【００３１】
付加サービスアプリの削除は主に２種類存在する。１つはロード処理したプログラムをフラッシュメモリ１８３から削除することをいう。もう１つはインストールしたインスタンスをフラッシュメモリ１８３から削除することをいう。これらの処理を、デリート（Ｄｅｌｅｔｅ）処理という。ここでいう削除とは、フラッシュメモリ１８３を所定の初期値で更新することを意味する。ユーザ視点では大きなデータを削除することになるが、ＯＳ処理としては、プログラムやインスタンスが格納された領域を空き領域へ更新するのではなく、ＯＳが管理するプログラムリストあるいはインスタンスリストの情報のみを削除することが多い。
【００３２】
付加サービスアプリの導入、活性化、削除によりフラッシュメモリ１８３に対するアロケートとリリースが繰り返されることにより、小さな複数の空き領域（断片化した空き領域）が生まれる。これらの領域を柔軟に活用するため、連続した空き領域を生み出すデフラグ処理が必要となる。デフラグ処理を実現するにあたり、仮想アドレス空間を用いたメモリ管理方法を採用した場合、断片化した物理アドレス空間を連続した仮想アドレス空間へマッピングするためのページテーブルを更新する。また、仮想アドレス空間を用いないメモリ管理方法を採用した場合、断片化した空き領域を他の空き領域と隣接させて領域を統合するために、非空き領域を移動（更新）する必要がある。何れのメモリ管理方法であっても、これらの処理は非常に時間を要する。そこで、デフラグ処理を実行するタイミングについて検討する。
【００３３】
ロード処理はフラッシュメモリ１８３内の連続した大きなサイズの空き領域へプログラムを書き込む処理である。フラッシュメモリ１８３のページサイズはある程度大きなサイズであるから、大きなデータを書き込む処理自体は効率的に実行することができる。しかし、実際のロード処理はＵＩＭカードが保持する内部ＡＰＩ（Application Programming Interface）とロードしたプログラムをリンクするためにプログラム内のリンク情報（サイズは非常に小さい）を更新する必要があり、ＯＳが管理するプログラムリストへのエントリ情報（サイズは非常に小さい）を追加するなどの処理が必要となる。結果として、フラッシュメモリ１８３への書き込み回数が多く、ロード処理の処理負荷は非常に高い。
【００３４】
インストール処理はフラッシュメモリ１８３内へ複数のインスタンスを書き込む処理である。インストールされるアプリケーションが保持するデータ数と各データのサイズによって書き込みのトータルサイズが決まる。また、ＯＳが管理するインスタンスリストへのエントリ情報を追加する処理も必要となる。結果として、ロード処理と同様にフラッシュメモリへの書き込み回数が多く、インストール処理の処理負荷は非常に高い。
【００３５】
デリート処理はロード処理あるいはインストール処理でフラッシュメモリ１８３へ書き込んだ大きなサイズの領域を空き領域へ更新する処理である。ロード処理あるいはインストール処理では非常に小さいサイズでの書き込みを繰り返すが、デリート処理ではまとめて一括更新することが可能なため、ロード処理やインストール処理と比較して、処理負荷は非常に低い。また、ＯＳが管理するリスト情報の更新をもって削除とする場合、処理負荷は更に低い。したがって、本実施形態では、デリート処理を実行する際に、デフラグ処理を行う。
【００３６】
ここで、図３を用いてデフラグ処理について説明する。図３（Ａ）はフラッシュメモリ１８３のデフラグ処理前のデータ記憶状況の例を示し、図３（Ｂ）はデフラグ処理後のデータ記憶状況の例を示している。図３では、説明の簡略化のためにフラッシュメモリ１８３はページＰ１−Ｐ１２で構成されているものとする。
【００３７】
図３（Ａ）の例では、ページＰ４の一部が、データが記憶されていない空き領域Ｅ１となっており、ページＰ７の全てが空き領域Ｅ２となっており、ページＰ９の一部が空き領域Ｅ３となっている。また、ページＰ１１及びページＰ１２にはデータが記憶されておらず、空き領域Ｅ４となっている。
【００３８】
ここで、本実施形態におけるＣＰＵ１８１によるデフラグ処理について説明する。ＣＰＵ１８１はフラッシュメモリ１８３において、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更することによりデフラグを実行する。つまり、一部でもデータが記憶されているページ、例えば、空き領域Ｅ１や空き領域Ｅ３を含むページＰ４やページＰ９は空きページとして取り扱わない。これは、上述したように、フラッシュメモリ１８３の更新はページ単位で実行され、ページサイズのデータ更新処理と、ページサイズ未満（例えば１バイト）のデータ更新処理の負荷は変わらないためである。これにより、未使用であるにも関らず使用できない領域が生まれてフラッシュメモリ１８３の使用効率は下がるが、ページサイズと書き込むデータサイズから影響は極めて小さい。
【００３９】
図３（Ａ）の例では、空きページはページＰ７、ページＰ１１及びページＰ１２であるので、ＣＰＵ１８１は、ページＰ１０に記憶されているデータの位置をページＰ７の位置に変更する（すなわち、ページＰ１０の内容をページＰ７に移動させる）。これにより、図３（Ｂ）に示すように、ページＰ１０が空きページとなり、ページＰ１０、ページＰ１１及びページＰ１２と空きページが連続することとなる。なお、ＣＰＵ１８１は、ページＰ８、ページＰ９及びページＰ１０に記憶されているデータの位置をページＰ７、ページＰ８及びページＰ９の位置に変更する（すなわち、ページＰ８、ページＰ９及びページＰ１０に記憶されているデータの位置を１ページ分前にシフト移動させる）こととしてもよい。この場合も、図３（Ｂ）に示すように、ページＰ１０、ページＰ１１及びページＰ１２と連続する空きページを生成することができる。
【００４０】
なお、ＣＰＵ１８１は、所定の連続した空き領域をＦＲＥＥＭＩＮＩとして、フラッシュメモリ１８３上にＦＲＥＥＭＩＮＩ以上の連続した空き領域が存在する場合には、デフラグ処理を実行しないこととしてもよい。ＦＲＥＥＭＩＮＩとして、例えば、６４Ｋバイトを設定する。これは、技術仕様上の制約により付加サービスアプリのプログラムサイズは最大６４Ｋバイトであることによる。すなわち、断片化した空き領域が存在したとしても、ＦＲＥＥＭＩＮＩ以上の連続した空き領域が存在する場合にはロード処理を行うことができるため、デフラグ処理を実行しないこととすることができる。これにより、直ぐには必要でないデフラグ処理を行わずに済み処理時間が短縮される。
【００４１】
次に、図４及び図５を用いてアプリ内デフラグ処理について説明する。アプリ内デフラグ処理とは、アプリケーションに関連するデータが複数ページにわたっている場合において、アプリケーションに関連するデータの一部が削除された際、その領域に、他ページのデータを移動させることにより当該他ページを空きページとする処理である。
【００４２】
図４及び図５において、ＯＸＹ（「Ｏ」で始まる３文字の文字列）はアプリケーションＸが保持するＹ番目のオブジェクトを示す。例えば、「ＯＡ１」は、アプリケーションＡが保持する１番目のオブジェクトを示す。次に、ＫＸＹ（「Ｋ」で始まる３文字の文字列）はアプリケーションＸが保持するＹ番目の鍵を示す。例えば、「ＫＡ１」は、アプリケーションＡが保持する１番目の鍵を示す。次に、ＦＸＹ（「Ｆ」で始まる３文字の文字列）はアプリケーションＸが保持するＹ番目のファイルを示す。例えば、「ＦＡ１」は、アプリケーションＡが保持する１番目のファイルを示す。なお、それぞれ、括弧内の数値はメモリ消費サイズを示している。
【００４３】
図４では、アプリＡに関連するデータがＰＸ及びＰＸ＋１の２ページに記憶されている。図４（Ａ）はフラッシュメモリ１８３のデータ削除前のデータ記憶状況を示しており、ここから、ＣＰＵ１８１がデリートコマンド（ＤＥＬＥＴＥ  ＦＩＬＥ（ＦＡ３）に基づいてＦＡ３を削除したとすると、図４（Ｂ）に示すようになる。このとき、ＦＡ３の削除によって、ＰＸ内に新たな空きサイズ９を確保できるが、ＰＸ＋１内のＫＡ２はサイズ１０であるため、アプリ内デフラグを実行してもＰＸ＋１を空きページとすることができない。よって、ＣＰＵ１８１は、コマンドに応じたＦＡ３の削除処理のみを行ってアプリ内デフラグ処理を実行しない。
【００４４】
一方、ＣＰＵ１８１がデリートコマンド（ＤＥＬＥＴＥ  ＦＩＬＥ（ＦＡ２）に基づいてＦＡ２を削除すると、図５（Ａ）に示すようになる。このとき、ＦＡ２の削除によって、ＰＸ内に新たな空きサイズ２１を確保できる。ここで、ＰＸ＋１内のＦＡ３の一部（３／１２）及びＫＡ２のサイズの合計は１３であるため、ＣＰＵ１８１がアプリ内デフラグを実行することによりＰＸ＋１を空きページとすることができる。よって、ＣＰＵ１８１は、コマンドに応じたＦＡ３の削除処理を行った後、アプリ内デフラグ処理を実行する。具体的には、図５（Ｂ）に示すように、ＦＡ３及びＫＡ２をページＰＸ内に移動させる。なお、ＦＡ３及びＫＡ２をページＰＸ内に移動させる際の、ＰＸに記憶させる各データの配置については適宜変更してもよい。
【００４５】
［３．ＣＰＵ１８１の動作例］
次に、図６−図８を用いてＣＰＵ１８１の動作例について説明する。図６は、コマンド受信時処理の例を示すフローチャートであり、図７は、第１デフラグ処理の例を示すフローチャートであり、図８は、第２デフラグ処理の例を示すフローチャートである。
【００４６】
図６に示すように、まず、ＣＰＵ１８１はコマンドを受信したか否かを判定する（ステップＳ１０１）。このとき、ＣＰＵ１８１はコマンドを受信するまでこの処理を繰り返し（ステップＳ１０１：ＮＯ）、コマンドを受信したと判定した場合には（ステップＳ１０１：ＹＥＳ）、当該コマンドに応じたコマンド処理を実行する（ステップＳ１０２）。なお、ＣＰＵ１８１は、ＤＥＬＥＴＥコマンド（ＤＥＬＥＴＥ  Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ＆Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  ＦＩＬＥ、ＤＥＬＥＴＥ  ＫＥＹ）を受信した場合には、削除対象のデータを削除する。
【００４７】
次に、ＣＰＵ１８１は、ステップＳ１０１の処理で受信したコマンドはＤＥＬＥＴＥ  Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ又はＤＥＬＥＴＥ  Ｐａｃｋａｇｅ＆Ａｐｐｌｉｃａｔｉｏｎであるか否かを判定する（ステップＳ１０３）。このとき、ＣＰＵは、受信したコマンドはＤＥＬＥＴＥ  Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ又はＤＥＬＥＴＥ  Ｐａｃｋａｇｅ＆Ａｐｐｌｉｃａｔｉｏｎであると判定した場合には（ステップＳ１０３：ＹＥＳ）、後述する第１デフラグ処理を実行し（ステップＳ１０４）、次いで、ステップＳ１０１の処理で受信したコマンドに対するレスポンスを送信して（ステップＳ１０７）、コマンド受信時処理を終了する。
【００４８】
一方、ＣＰＵは、受信したコマンドはＤＥＬＥＴＥ  Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ又はＤＥＬＥＴＥ  Ｐａｃｋａｇｅ＆Ａｐｐｌｉｃａｔｉｏｎではないと判定した場合には（ステップＳ１０３：ＮＯ）、次いで、ステップＳ１０１の処理で受信したコマンドはＤＥＬＥＴＥ  ＦＩＬＥ又はＤＥＬＥＴＥ  ＫＥＹであるか否かを判定する（ステップＳ１０５）。
【００４９】
ＣＰＵは、受信したコマンドはＤＥＬＥＴＥ  ＦＩＬＥ又はＤＥＬＥＴＥ  ＫＥＹであると判定した場合には（ステップＳ１０５：ＹＥＳ）、後述する第２デフラグ処理を実行し（ステップＳ１０６）、次いで、ステップＳ１０１の処理で受信したコマンドに対するレスポンスを送信して（ステップＳ１０７）、コマンド受信時処理を終了する。一方、ＣＰＵは、受信したコマンドはＤＥＬＥＴＥ  ＦＩＬＥ又はＤＥＬＥＴＥ  ＫＥＹではないと判定した場合には（ステップＳ１０５：ＮＯ）、次いで、ステップＳ１０１の処理で受信したコマンドに対するレスポンスを送信して（ステップＳ１０７）、コマンド受信時処理を終了する。
【００５０】
次に図７を用いて第１デフラグ処理について説明する。
【００５１】
まず、ＣＰＵ１８１は、フラッシュメモリ１８３に断片化した空き領域が存在するか否かを判定する（ステップＳ１３１）。このとき、ＣＰＵ１８１は、フラッシュメモリ１８３に断片化した空き領域が存在しないと判定した場合には（ステップＳ１３１：ＮＯ）、第１デフラグ処理を終了する。
【００５２】
一方、ＣＰＵ１８１は、フラッシュメモリ１８３に断片化した空き領域が存在すると判定した場合には（ステップＳ１３１：ＹＥＳ）、次いで、連続した空き領域の最大容量がＦＲＥＥＭＩＮＩ未満であるか否かを判定する（ステップＳ１３２）。このとき、ＣＰＵ１８１は、連続した空き領域の最大容量がＦＲＥＥＭＩＮＩ未満であると判定した場合には（ステップＳ１３２：ＹＥＳ）、デフラグ処理を実行し（ステップＳ１３３）、第１デフラグ処理を終了する。一方、ＣＰＵ１８１は、連続した空き領域の最大容量がＦＲＥＥＭＩＮＩ未満ではないと判定した場合には（ステップＳ１３２：ＮＯ）、第１デフラグ処理を終了する。
【００５３】
次に図８を用いて第２デフラグ処理について説明する。
【００５４】
まず、ＣＰＵ１８１は、該当アプリ（削除対象のファイル又はキーに対応するアプリ）の総データ量が、［Ｎ−Ｍ］ページ分のデータ量以下であるか否かを判定する（ステップＳ１５１）。ここで、Ｎはアプリケーションへ割り当てられた総ページ数である。Ｍはアプリ内デフラグ処理により作成する空きページ数（オペレータが設定する）である（空きページを１ページ作成する場合であれば、Ｍ＝１と設定する）。
【００５５】
ＣＰＵ１８１は、該当アプリの総データ量が、［Ｎ−Ｍ］ページ分のデータ量以下ではないと判定した場合には（ステップＳ１５１：ＮＯ）、第２デフラグ処理を終了する。一方、ＣＰＵ１８１は、該当アプリの総データ量が、［Ｎ−Ｍ］ページ分のデータ量以下であると判定した場合には（ステップＳ１５１：ＹＥＳ）、アプリ内デフラグ処理を実行し（ステップＳ１５２）、第２デフラグ処理を終了する。
【００５６】
以上説明したように、本実施形態におけるＩＣチップＣ（「電子情報記憶媒体」の一例）は、複数のページを含むフラッシュメモリ１８３と、携帯端末１（「外部端末」の一例）から受信するコマンドに応じてフラッシュメモリの更新をページ単位で実行するＣＰＵ１８１（「実行部」、「コンピュータ」の一例）とを備え、ＣＰＵ１８１（「削除手段」、「位置変更手段」の一例）は、フラッシュメモリ１８３が記憶するデータを削除対象とするＤＥＬＥＴＥコマンド（ＤＥＬＥＴＥ  Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ、ＤＥＬＥＴＥ  Ｐａｃｋａｇｅ＆Ａｐｐｌｉｃａｔｉｏｎ、ＤＥＬＥＴＥ  ＦＩＬＥ、ＤＥＬＥＴＥ  ＫＥＹ）（「削除コマンド」の一例）を受信した場合に、当該削除対象のデータを削除し、データを記憶していない空きページ同士が連続するようにデータが記憶される位置を変更するデフラグ処理を行う。
【００５７】
したがって、本実施形態におけるＩＣチップＣによれば、ＤＥＬＥＴＥコマンドを受信した際にフラッシュメモリ１８３における断片化した空き領域から連続した空き領域を生成することができる。
【００５８】
また、ＣＰＵ１８１はフラッシュメモリ１８３にＦＲＥＥＭＩＮＩ（「所定サイズ」の一例）以上の連続した空き領域が存在する場合には、デフラグ処理を行わない。この場合、直ぐには必要でないデフラグ処理を行わずに済み処理時間が短縮される。
【００５９】
更に、ＣＰＵ１８１は、アプリケーションに関する少なくとも一部のデータを削除対象とするＤＥＬＥＴＥコマンドを受信した場合に、当該削除対象のデータを削除し、削除対象のデータの削除前にアプリケーションに関するデータが複数ページにわたって記憶されている場合に、当該削除対象のデータの削除によりできた空き領域に当該空き領域を含むページとは異なる他ページに記憶されているデータを移動するように当該データが記憶される位置を変更して他ページを空きページとするアプリ内デフラグ処理（「空きページ生成処理」の一例）を行う。これにより、アプリケーションに関する一部のデータが削除されたことによりできる空き領域に他ページのデータを移動させることにより空きページを作成することができる。
【００６０】
更にまた、ＣＰＵ１８１は、アプリ内デフラグ処理を行う前に、削除対象のデータの削除によりできる空き領域に他ページに記憶されているデータを移動することにより当該他ページを空きページとすることができるか判定し（図８のステップＳ１５１）、当該他ページを空きページとすることができると判定した場合（図８のステップＳ１５１で「ＹＥＳ」と判定した場合）にアプリ内デフラグ処理を行う。空きページを作成することができないにもかかわらず、空きページの作成にチャレンジすることを回避することができる。
【００６１】
［４．変形例］
次に、上記実施形態の変形例について説明する。なお、以下に説明する変形例は適宜組み合わせることができる。
【００６２】
［４．１．変形例１］
ＣＰＵ１８１は、図６における第２デフラグ処理（ステップＳ１０６）の終了後、第１デフラグ処理（ステップＳ１０４）に移行することとしてもよい。これにより、大きなファイル等を削除した際、第２デフラグ処理により空きページ作成し、その後の第１デフラグ処理により当該空きページを利用して連続する空きページを作成することができる。この場合、ＣＰＵ１８１は第１デフラグ処理及び第２デフラグ処理を実行することとなり、第２デフラグ処理のみを実行する場合よりも処理時間が掛かってしまう。そこで、第２デフラグ処理から移行してきた第１デフラグ処理では、ＣＰＵ１８１は図７のステップＳ１３２の判定をせずに、ステップＳ１３３に移行することにより処理時間を削減してもよい。
【００６３】
なお、ＤＥＬＥＴＥ  ＦＩＬＥ又はＤＥＬＥＴＥ  ＫＥＹのコマンドに、第２デフラグ処理の後に第１デフラグ処理の実行を許可するか否かを指定する許可不許可情報を含めることとし、ＣＰＵ１８１は許可しない情報が含まれている場合には、第２デフラグ処理の後に第１デフラグ処理に移行しないこととしてもよい。これにより、コマンドを送信する側で処理時間を考慮して何れかを指定することができる。
【００６４】
また、フラッシュメモリ１８３におけるＯＳが使用するＯＳ領域に、第２デフラグ処理の後に第１デフラグ処理を実行することについて、「許可する」又は「許可しない」ことを示す許可不許可情報を記憶させておくこととし、ＣＰＵ１８１は「許可しない」ことを示す許可不許可情報が記憶されている場合には、第２デフラグ処理の後に第１デフラグ処理に移行しないこととしてもよい。なお、許可不許可情報は、例えば、ＵＩＭ発行時などに記憶させておくこととしてもよいし、発行後にコマンド等により記憶させることとしてもよい。
【００６５】
更に、これらの組み合わせにより第２デフラグ処理の後に第１デフラグ処理に移行するか否かを制御することとしてもよい。具体的には、フラッシュメモリ１８３におけるＯＳ領域に許可不許可情報（「メモリ許可不許可情報」という）を記憶させておくとともに、ＤＥＬＥＴＥ  ＦＩＬＥ又はＤＥＬＥＴＥ  ＫＥＹのコマンドに許可不許可情報（「コマンド許可不許可情報」という）を含めることとする。そして、ＣＰＵ１８１は、メモリ許可不許可情報及びコマンド許可不許可情報の示す内容に応じて、第２デフラグ処理の後に第１デフラグ処理に「移行する」又は「移行しない」を判定することとする。例えば、ＣＰＵ１８１は、（１）メモリ許可不許可情報が「許可する」を示し、且つ、コマンド許可不許可情報が「許可する」を示す場合には、「移行する」と判定し、（２）メモリ許可不許可情報が「許可しない」を示し、且つ、コマンド許可不許可情報が「許可しない」を示す場合には、「移行しない」と判定し、（３）メモリ許可不許可情報が「許可しない」を示し、且つ、コマンド許可不許可情報が「許可する」を示す場合には、コマンド許可不許可情報を優先して「移行する」と判定し、（４）メモリ許可不許可情報が「許可する」を示し、且つ、コマンド許可不許可情報が「許可しない」を示す場合には、コマンド許可不許可情報を優先して「移行しない」と判定する。
【００６６】
［４．２．変形例２］
上記実施形態では、デフラグ処理において、フラッシュメモリ１８３の更新単位であるページ毎に空き領域であるか確認し、間の空きページがなくなるようにデータを記憶するページの内容を移動させていくことが基本動作となっている。この基本動作の応用として、連続した空きページを作る、という目的は同じであっても、空きページ全てを詰めるのではなく、敢えて空きページのまま残す２つの機能について説明する。
【００６７】
まず、１つ目の機能は予約機能である。例えば、後からオブジェクトやファイル、鍵を追加することがわかっているようなアプリケーションの場合、まとまったページを使用予定領域として予約する機能がある。使用予定領域は、データを記憶していなくても、データを記憶しているとみなす。
【００６８】
したがって、ＣＰＵ１８１は、使用予定領域は空きページであっても空きページとして取り扱わないものとする。なお、使用予定領域のサイズはインストールコマンドのコマンドデータにて指定され、インスタンス化されたアプリケーションに対してサイズ分のメモリが確保（専有）される。
【００６９】
例えば、使用予定領域が設定されたアプリケーションのファイルデータを削除して、アプリ内デフラグ処理が実行された結果、空きページが発生したとしても、アプリ内デフラグ処理後のデフラグ処理で使用予定領域（たとえデータが書き込まれていなくても）への位置変更は行わない。また、使用予定領域が設定されたアプリケーションが専有するページに接するページを使用していたアプリケーションが削除され、デフラグ処理が実行されても、使用予定領域（たとえデータが書き込まれていなくても）への位置変更は行わない。
【００７０】
次いで、２つ目の機能は複数ページ単位管理機能である。上記実施形態では、ページ単位で空き領域であるか否かを管理していたが、２以上の所定数のページ（「ページ群」という場合がある）単位で空き領域であるか否かを管理する機能である。通常、空きページであるか否かはフラッシュメモリ管理テーブルで管理される。あるページがフラッシュメモリの初期値(０ｘＦＦ)であったとしても、空きページであるために初期値であるのか、アプリケーションのデータとして初期値が記録されているのかは書き込まれたデータのみでは判断できない。そのため、各ページが使用中であるか否かをＯＳがテーブルで管理する。このテーブルをフラッシュメモリ管理テーブルと呼ぶ。フラッシュメモリ管理テーブルで管理する単位がページ単位である場合、フラッシュメモリの容量が大きければ大きいほど、フラッシュメモリ管理テーブル自体が大きくなってしまい、アプリケーション用の記憶領域を圧迫してしまう。そこで、管理単位をページ単位ではなくページ群単位とすることにより、フラッシュメモリ管理テーブルを圧縮することができる（但し、メモリ使用効率は下がる）。なお、ページ群を構成するページ数を何ページとするかは、ＵＩＭカード１８が取り扱うプログラムやデータのサイズに応じてＵＩＭ製造時に設定することができる。
【００７１】
図９を用いて、管理単位（ページ群を構成するページ数）を４ページとした場合について説明する。図９（Ａ）は、アプリＡについてページ１−４が割り当てられ、ページ１、２にデータが書き込まれている様子を示している。同様に、アプリＢについてページ５−８が割り当てられ、ページ５−８にデータが書き込まれており、また、アプリＣについてページ９−１２が割り当てられ、ページ９、１０にデータが書き込まれている。ここで、アプリＢが削除される場合について説明する。ＣＰＵ１８１は、アプリＢを削除すると、ページ５−８で構成されるページ群が空き領域となるので、アプリＣに対応するページ９−１２で構成されるページ群に記憶されている内容をページ５−８で構成されるページ群に移動させることにより、ページ９−１２で構成されるページ群を空き領域とする。このとき、ＣＰＵ１８１は、ページ３、４はデータが書き込まれていないが、アプリＡに対応するページ群に含まれるので、アプリＣに対応するページ９−１２で構成されるページ群の内容をページ３−６で構成されるページ群に移動させることはない。      
【符号の説明】
【００７２】
１  携帯端末
１１  制御部
１２  記憶部
１３  無線通信部
１４  表示部
１５  入力部
１６ａ  ＣＬＦインターフェース
１６ｂ  ＩＣカードインターフェース
１７  バス
１８  ＵＩＭカード
Ｃ  ＩＣチップ
１８１  ＣＰＵ
１８２  ＲＡＭ
１８３  フラッシュメモリ
１８４  Ｉ／Ｏ回路
１８５  バス
１９  ＣＬＦ
【図１】
2018014014.tif 000003
【図２】
2018014014.tif 000004
【図３】
2018014014.tif 000005
【図４】
2018014014.tif 000006
【図５】
2018014014.tif 000007
【図６】
2018014014.tif 000008
【図７】
2018014014.tif 000009
【図８】
2018014014.tif 000010
【図９】
2018014014.tif 000011