"外部からのコマンド指示を解釈実行し、その結果を応答する携帯可能電子装置において、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを生成するコマンド生成部と、前記生成した要求コマンドをメモリに記憶する記憶部と、前記特定のコマンド指示に対する応答の際前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際前記要求コマンドを前記外部に通知する通知部と、外部から前記要求コマンドの廃棄を指示された際前記記憶部内の要求コマンドを廃棄する廃棄部とを備えたことを特徴とする携帯可能電子装置。前記通知部は、前記廃棄を指示するコマンド指示以外のコマンド指示を受信した際前記メモリ内に前記要求コマンドがある場合は前記要求コマンドの発生を前記外部に通知することを特徴とする請求項1に記載の携帯可能電子装置。前記廃棄部は、前記メモリ内の要求コマンドを全て廃棄することを特徴とする請求項2に記載の携帯可能電子装置。前記廃棄部は、前記メモリ内の一番古い要求コマンドを廃棄することを特徴とする請求項2に記載の携帯可能電子装置。外部から初期化を指示するコマンド指示を受信した際前記携帯可能電子装置を初期化するリセット部を有し、前記リセット部は、前記メモリ内の要求コマンドを廃棄しないことを特徴とする請求項2に記載の携帯可能電子装置。前記記憶部は、前記生成した要求コマンドを不揮発性メモリに記憶することを特徴とする請求項5に記載の携帯可能電子装置。請求項1乃至6の内いずれか1項に記載の各部を有するICモジュールと、このICモジュールを収納したICカード本体とを備えたことを特徴とするICカード。上記規格によると、UIMにおいて、ToolKitAppletと呼ばれるApplet、もしくは、組込ソフトウエアが実行された場合、UIMではProactiveコマンド送信要求が発生することがある。この時、UIMは、MEから送信されるFetchコマンドに対するレスポンスデータとして、Proactiveコマンドを送信する。しかし、MEがFetchコマンドを送信するまで、UIMは、Proactiveコマンドを出力することができない。一方、UIMでは、この状態とは独立にAppletの動作によって別のProactiveコマンド送信要求が発生し得る。そのため、UIMがFetchコマンドを受信しないMEがFetchを送信しない状態が継続すると、UIMにおいて、未送信のProactiveコマンドが蓄積する。また、MEからUIMに対してリセット信号が供給されると、未送信のProactiveコマンドの情報もリセットされてしまうため、送信すべきProactiveコマンドが送信できない場合がある。従って、UIMにおいて特定のコマンドによって発生したMEへの送信データが未送信のまま蓄積されること、また特定のコマンドによって発生したMEへの送信データが意図せずに消去されることを防止するニーズがある。上記課題を解決するための本発明の実施の形態によれば、外部からのコマンド指示を解釈実行し、その結果を応答する携帯可能電子装置において、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを生成するコマンド生成部と、前記生成した要求コマンドをメモリに記憶する記憶部と、前記特定のコマンド指示に対する応答の際前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際前記要求コマンドを前記外部に通知する通知部と、外部から前記要求コマンドの廃棄を指示された際前記記憶部内の要求コマンドを廃棄する廃棄部とを備えた携帯可能電子装置が提供される。第1の実施の形態図1は、本実施の形態の携帯電話端末ME1とUIM2との接続とそれぞれの構成ブロックとを示す図である。UIM2は、携帯可能電子機器であり、ME1に装着されて携帯電話アプリ利用時のデータをハンドリングする。ME1には、制御部11、表示部12、通信部14及び入力部15が設けられている。制御部11は、ME1内の各部の動作を統括して制御する。表示部12は、ユーザに対して情報を表示する。通信部14は、UIM2との間のデータ通信を実行する。入力部15は、ユーザからの指示を入力する。UIM2は、通信インターフェース部21、制御部22、RAM23、ROM24、不揮発性メモリ25を備えている。通信インターフェース部21は、ME1から送信されるデータを受信して制御部22に出力する。制御部22は、演算、制御などを行い、UIM2を統括して制御する。ROM24は、読み出し専用メモリである。ROM24には、オペレーティングシステムOSなどの基本ソフトウエア、アプリケーション及びデータが格納されている。RAM23は、制御部22の処理における作業領域として使用される。不揮発性メモリ25は、EEPROM、フラッシュメモリなどの書き換え可能な不揮発性のメモリであり、通常ユーザのワークエリア、プログラムエリアなどとして使用されている。後述のAppletは、不揮発性メモリ25に格納されている。図2は、本実施の形態のME1とUIM2との間での通常のコマンド授受手順を示す図である。ステップS01において、ME1はUIM2にEnvelopeコマンドを送信する。ここで、Envelopeコマンドには、上述の規格において複数種類のフォーマットが規定されている。Eventdownloadはこのフォーマットの1種類であり、ME1で所定のイベントが発生したことをUIM2に通知する内容である。UIM2では、受信したEnvelopeコマンドに対応したAppletが起動し、Appletに記載されているプログラムが実行される。この際にME1に何らかの動作を起こさせる場合、例えば、ME1の表示部12に画面を表示する処理を実行させる場合は、ME1に対して画面表示を指定したProactiveコマンド送信することが必要である。そこでステップS02において、UIM2は、ME1に91XXのステータスワードを送信する。この91XXのステータスワードは、Proactiveコマンドの送信要求を表す。即ち、UIM2に送信すべきProactiveコマンドがあるということを表している。91XXのステータスワードを受信したME1は、ステップS03において、UIM2に対してFetchコマンドを出力する。Fetchコマンドを受信したUIM2は、ステップS04において、Proactiveコマンドと9000のステータスワードをME1に送信する。Proactiveコマンドを受信したME1は、そのProactiveコマンドに対応した処理を実行する。例えば、音声を出力する、画面表示を行なう、電話を発信するなどの動作を実行する。ステップS05において、ME1は実行結果をTerminalResponseとしてUIM2に出力する。例えば、実行完了した、ユーザが操作中により実行できない、エラーが発生して実行を中止したなどの応答を返送する。ステップS06において、UIM2は、Appletのプログラムに従い、以降の処理を行なう。Appletが後続で処理するProactiveコマンドがない場合、9000のステータスワードを送信する。次にProactiveコマンド送信が正常に行われず、Proactiveコマンドが蓄積される場合の手続きについて説明する。図3は、本実施の形態のME1とUIM2との間でのProactiveコマンドが蓄積された際に破棄する通信手順を示す図である。ステップS11において、ME1は、EnvelopeEventdownloadを送信する。UIM2は、このコマンドの受信をトリガとして、Appletを起動する。そして、UIM2は、ステップS12において、送信すべきProactiveコマンドがあることを示すステータスワードSW=91xxをME1に送信する。ここまでの処理は、図2で説明した手順と同様である。通常であれば、ME1は、FetchコマンドをUIM2に送信する。しかし、MEがFetchコマンドを送信できない処理を実行している場合、FetchコマンドはUIM2に送信されず、実行している処理に関する他のコマンドが送信される。ステップS13において、ME1はSelectコマンドを送信する。UIM2は、Selectコマンドを受信し、正常に処理を行う。次にUIM2は、コマンドが送信される毎に、送信すべきProactiveコマンドがあるか否かを調べる。そして、未送信のProactiveコマンドが存在するため、ステップS14において、SW=91xxをME1に送信する。その後、ME1はFetchコマンドを送信せず、ステップS15において、ステップS11とは異なる別のEnvelopeMenuSelectionnコマンドをUIM2に送信する。UIM2は、このEnvelopeコマンドをトリガとして、Appletを起動する。すると、Appletは、Proactiveコマンド送信要求をUIM2に対して行う。ステップS16において、UIM2はME1にSW=91xxを送信する。上述のケースでは、1回目のApplet起動で発生したProactiveコマンドと、2回目のApplet起動で発生したProactiveコマンドの2つのProactiveコマンドがUIM2に蓄積されている。このように、Proactiveコマンドを受信した後、ME1側の理由によりME1がFetchコマンドを送信しない場合には、UIM2にはProactiveコマンドが蓄積される状態が発生する。次に、ME1側の対応について説明する。例えば、ユーザがME1にメールの文章を入力しているなど操作を実行中である場合を考える。このとき、Proactiveコマンドを受信してそのコマンドに対応した画面が表示されると、現在ユーザが使用している機能が一時中断されることになり、甚だ不都合な状態となる。従って、このときは、ME1ではProactiveコマンドを受信できないようにする。即ち、ME1がProactiveコマンドを受信、処理出来る状況に無い場合、UIM2からのSW=91XXを受信したME1はUIM2に対し、Proactiveコマンドの破棄を要求することができる。ステップS17において、ME1は、Proactiveコマンド破棄を示すSelectコマンドをUIM2に送信する。このSelectコマンドの送信は、ME1において所定のジョブを実行中におけるステップS16に示すSW=91xxの受信に対応して実行する。UIM2はコマンドデータにおいて、Proactiveコマンド破棄が示されているときは、現状蓄積しているProactiveコマンドを破棄する。なお、Proactiveコマンドを破棄する方法は、Selectコマンドで指定することができる。例えば、一番古いProactiveコマンドを破棄するように指定することができ、あるいは蓄積している全てのProactiveコマンドを破棄するように指定することができる。UIM2は、Proactiveコマンドを破棄し、ステップS18において、ステータスワードを送信する。Proactiveコマンドがない場合はSW=9000を送信し、Proactiveコマンドが残っている場合はSW=91xxを返す。なお、Proactiveコマンド破棄を指示する場合、コマンドをT=1プロトコルのI-blockとして送信して、そのPCBでProactiveコマンド破棄を示すことができる。図4は、本実施の形態のT-1プロトコルフォーマットを示す図である。T-1プロトコルフォーマットISO07816では、コマンドはNAD、PCB、LEN、INF、EDCで構成される。NADは、アドレスを表す。PCBは、モードを示す制御コードである。LENは、コマンドの長さを示す。INFはコマンドの種類Select,Proactiveなどを表す。EDCは、誤り検出用チェックコードである。PCBは、モードがI-blockのときは、8バイトで構成され、右の5バイトが未使用となっている。そこで、この未使用のデータ領域にコマンド破棄を示すデータを記載することができる。図5は、本実施の形態のME1とUIM2との間でのProactiveコマンドが蓄積された際に再送信する通信手順を示す図である。ステップS21~S26の手順は、図3に示すステップS11~S16の手順と同一であるためその詳細の説明は省略する。ME1は、Proactiveコマンドの受信を再開する場合は、ステップS31において、UIM2にResetコマンドを送信する。このResetコマンドは、例えばME1の電源をオフからオンした場合にUIM2を初期化するために送信されるコマンドである。従って、Resetコマンドを受信したUIM2は、RAM23をクリアする。従来では、ProactiveコマンドはRAM23に蓄積されていたため破棄されることになる。しかし、本実施の形態ではProactiveコマンドは不揮発性メモリ25に蓄積されているため、破棄されない。ステップS32において、UIM2は、リセットに対する応答としてATRanswertoresetを返す。ステップS33において、ME1は、Selectコマンドを送信する。UIM2は、Selectコマンドを受信し、正常に処理を行う。次にUIM2は、送信すべきProactiveコマンドがあるか否かを調べる。不揮発性メモリ25には、送信したいProactiveコマンドが存在するため、ステップS34において、SW=91xxをME1に送信する。91XXのステータスワードを受信したME1は、ステップS35において、UIM2に対してFetchコマンドを出力する。Fetchコマンドを受信したUIM2は、ステップS36において、Proactiveコマンドと9000のステータスワードをME1に送信する。Proactiveコマンドを受信したME1は、そのProactiveコマンドに対応した処理を実行する。例えば、音声を出力する、画面表示を行なう、電話を発信するなどの動作を実行する。ステップS37において、ME1は実行結果をTerminalResponseとしてUIM2に出力する。例えば、実行完了した、ユーザが操作中により実行できない、エラーが発生して実行を中止したなどの応答を返送する。TerminalResponseを受信したUIM2は、さらに送信すべきProactiveコマンドがあるか否かを調べる。送信すべきProactiveコマンドがある場合は、ステップS38において、SW=91xxをME1に送信する。以降、残存するProactiveコマンドの数だけステップS35~S38の処理を繰り返して実行する。ステップS41において、91XXのステータスワードを受信したME1は、UIM2に対してFetchコマンドを出力する。Fetchコマンドを受信したUIM2は、ステップS42において、Proactiveコマンドと9000のステータスワードをME1に送信する。Proactiveコマンドを受信したME1は、そのProactiveコマンドに対応した処理を実行する。ステップS43において、ME1は実行結果をTerminalResponseとしてUIM2に出力する。TerminalResponseを受信したUIM2は、ステップS44において、送信すべきProactiveコマンドがないことを示す、SW=9000をME1に送信する。以上、図3乃至図5で説明した手順によれば、Proactiveコマンドを所望のタイミングで破棄し、また、リセット後に再開することができる。次に、上述の通信手順を実現するためのUIM2の処理フローについて図6を参照しつつ説明する。なお、図6に示すUIM-制御部は制御部22を示し、UIM-Applet部は、不揮発性メモリ25に格納されているAppletを示す。ステップS50において、ME1がコマンドを送信する。ステップT01において、UIM-制御部はコマンドを受信し、ステップT02において、コマンドを解釈する。ステップT03において、受信コマンドにProactiveコマンドの破棄が指示されているか否かを判断する。受信コマンドにProactiveコマンドの破棄が指示されている場合、ステップT04において、不揮発性メモリ25に蓄積されているProactiveコマンドを破棄する。そして、ステップT05に進む。受信コマンドにProactiveコマンドの破棄が指示されていない場合、ステップT05において、コマンドを解釈する。ステップT06において、Appletの実行が必要か否かを判断する。例えば、上述の例では、コマンドがEnvelope、Fetchの場合はAppletの実行が必要と判断し、コマンドがTerminalResponseの場合はAppletの実行が不要と判断する。ステップT06において、Appletの実行が不要と判断した場合は、ステップT10において、コマンドを実行する。ステップT11において、不揮発性メモリ25にProactiveコマンドが蓄積されているか否かを調べる。不揮発性メモリ25にProactiveコマンドが蓄積されていない場合は、ステップT12において、SW=9000とする。不揮発性メモリ25にProactiveコマンドが蓄積されている場合は、ステップT13において、SW=91XXとする。ステップT14において、レスポンスを送信する。ステップS51において、ME1はレスポンスを受信する。ステップT06において、Appletの実行が必要と判断した場合は、ステップP01において、Appletを実行し、ステップP02において、コマンドを解釈する。ステップP03において、コマンドはFetchかどうかを判断する。コマンドがFetchでない場合は、ステップP04においてAppletを実行する。ステップP05において、Proactiveコマンド送信の要否を判断する。Proactiveコマンド送信が不要のときは、ステップT12において、SW=9000とする。そして、ステップT14において、レスポンスを送信する。Proactiveコマンド送信が要のときは、ステップP06において、Proactiveコマンドを不揮発性メモリ25に格納する。ステップT13において、SW=91XXとする。そして、ステップT14において、レスポンスを送信する。ステップP03において、コマンドがFetchの場合は、ステップP07において、ProactiveコマンドとSW=91XXを送信データにセットする。ステップP08において、送信するProactiveコマンドを不揮発性メモリ25から削除する。ステップT14において、レスポンスを送信する。なお、図6に示すフロー図では、ステップT03において、受信コマンドにProactiveコマンドの破棄が指示されている場合、ステップT04において、不揮発性メモリ25に蓄積されているProactiveコマンドを破棄したが、不揮発性メモリ25内の全てのProactiveコマンドを破棄するのではなく、一番古いProactiveコマンドを破棄するようにしても良い。なお上述のUIM2は、ICカードに組み込み、カードリーダライタとの間でデータの送受信を行なうように構成することができる。図7は、本実施の形態のUIMをICカード100に組み込んで構成した例について説明するためのブロック図である。図7に示すように、ICカード100は、プラスチックなどで形成されたカード状の本体101と、本体101内に内蔵されたICモジュール102とを備えている。ICモジュール102は、1つ又は複数のICチップ103と、通信I/F部21とを備える。ICチップ103と通信インターフェース部21とは、互いに接続された状態でICモジュール102内に埋設して形成されている。本実施の形態のUIMはICモジュール102として構成することができる。尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。"