"外部からのコマンド指示を解釈実行し、その結果を応答する携帯可能電子装置において、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを複数生成するコマンド生成部と、前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドを一つの応答要求コマンドにまとめて前記外部に通知する通知部と、複数の前記要求コマンドそれぞれの前記外部における実行結果をまとめた一つの応答結果コマンドを前記外部から取得する取得部とを備えたことを特徴とする携帯可能電子装置。前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順を指定する情報が含まれ、前記応答結果コマンドには、前記複数の要求コマンドそれぞれを実行した順序を表す情報が含まれることを特徴とする請求項1に記載の携帯可能電子装置。前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順が配列順によって指定され、前記応答結果コマンドには、前記複数の要求コマンドそれぞれを実行した順序が配列順として表されることを特徴とする請求項1に記載の携帯可能電子装置。外部からのコマンド指示を解釈実行し、その結果を応答する携帯可能電子装置において、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを複数生成するコマンド生成部と、前記特定のコマンド指示に対する応答の際前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドを一つの応答要求コマンドにまとめて前記外部に通知する通知部と、前記外部における前記要求コマンドの実行結果を表す応答結果コマンドを複数の前記要求コマンドそれぞれについて前記外部から取得する取得部とを備えたことを特徴とする携帯可能電子装置。前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順を指定する情報が含まれ、それぞれの前記応答結果コマンドには、前記要求コマンドそれぞれを実行した順序を表す情報が含まれることを特徴とする請求項4に記載の携帯可能電子装置。前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順が配列順によって指定され、前記取得部は、前記複数の要求コマンドが実行された順に対応する前記応答結果コマンドを取得することを特徴とする請求項4に記載の携帯可能電子装置。請求項1乃至6の内いずれか1項に記載の各部を有するICモジュールと、このICモジュールを収納したICカード本体とを備えたことを特徴とするICカード。上記規格によると、UIMにおいて、ToolKitAppletと呼ばれるApplet、もしくは、組込ソフトウエアが実行された場合、UIMではProactiveコマンド送信要求が発生することがある。この時、UIMは、MEから送信されるFetchコマンドに対するレスポンスデータとして、Proactiveコマンドを送信する。その後、MEは、受信したProactiveコマンドに基づき処理を行い、その実行結果を示すため、TerminalResponseコマンドを出力する。この時、現状の規格においては、1度に送信できるProactiveコマンドは1つのProactiveコマンドのみである。そのため、MEに対して、ユーザからのキー入力要求と音出力要求の2つの要求を送信したい場合、2つのProactiveコマンドを出力する必要がある。そのため、上記規格で規定される手順である、Fetch→TerminalResponseのコマンド送受信の手順を2度繰り返して実行する必要があり、実行処理が煩雑である。また、ユーザによるキー入力要求と音出力とをほぼ同時に実行させたい場合であっても、2つのProactiveコマンドの送受信に長いタイムラグが生じるため所望の動作が行なわれない恐れがある。更に2つの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は、第1の実施の形態の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に出力する。例えば、実行完了した、あるいはユーザが他の操作を実行中により実行できない、またはエラーが発生して実行を中止したなどの応答を返送する。UIM2のAppletは、応答結果を確認し、その後、後続の処理を実行して、例えば、音を出力させるProactiveコマンドを生成する。ステップS06において、UIM2は、音声出力を指定したProactiveコマンドの送信要求として、ME1に対し、91YYのステータスワードを送信する。ME1は、91YYのステータスワードにより、UIM2内にProactiveコマンドが蓄積されていると判断し、それを取得するため、ステップS07において、Fetchコマンドを送信する。UIM2は、Fetchコマンドを受信し、その応答として、ステップS08において、音声出力を指定したProactiveコマンドと9000のステータスワードをME1に送信する。Proactiveコマンドを受信したME1は、そのProactiveコマンドに対応した音声出力処理を実行する。ステップS09において、ME1は実行結果をTerminalResponseとしてUIM2に出力する。ステップS10において、UIM2は9000のステータスワードを送信してProactiveコマンドの送信を終了する。これ以降の処理は、Appletのプログラムに従う。図3は、第1の実施の形態のME1とUIM2との間での複数コマンド授受手順を示す図である。図4は、第1の実施の形態の通信手順を実現するためのUIM2の処理手順を示すフロー図である。以下では、UIM2において、ME1に送信しようとするProactiveコマンドがApplet処理において一時に複数発生した場合の通信手順について図3及び図4を参照しつつ説明する。ステップS11において、ME1はUIM2にEnvelopeコマンドを送信する。UIM2では、受信したEnvelopeコマンドに対応したAppletが起動し、Appletに記載されているプログラムが実行される。この際に、例えば、ME1の表示部12にキー入力要求画面を表示する処理と、更に音声を出力する処理を少ないタイムラグで実行させる場合は、ME1に対して画面表示を指定したProactiveコマンド1と音声出力を指定したProactiveコマンド2を送信することが必要である。そこでステップS12において、UIM2は、ME1に91ZZのステータスワードを送信する。この91ZZのステータスワードについての詳細は後述するが、UIM2に送信すべきProactiveコマンドがあるということを表している。91ZZのステータスワードを受信したME1は、ステップS13において、UIM2に対してFetchコマンドを出力する。Fetchコマンドを受信したUIM2は、ステップS14において、画面表示を指定したProactiveコマンド1、音声出力を指定したProactiveコマンド2及び9000のステータスワードをME1に送信する。図5は、第1の実施の形態の通常のコマンド授受手順におけるProactiveコマンドデータフォーマットを示す図である。図51はProactiveコマンド1のデータフォーマットを示し、図52はProactiveコマンド2のデータフォーマットを示す。Proactiveコマンドデータは、Tag、Length、Valueの各ブロックを含んでいる。Tagはコマンドの種類を表す。LengthはValueブロックの長さを表す。Valueはデータの内容を表す。そしてValueブロックには、例えばCommandDetails、DeviceIdentities、TextStringなどのブロックが更に含まれ、それぞれのブロックはデータとしてTag、Length、Valueを含んでいる。図5に示す各ブロックのデータはHexa16進表示で表される。即ち、Proactiveコマンド1のValueブロックの長さLengthは、Hexaで14バイト即ち10進表示で20バイトである。またProactiveコマンド2のValueブロックの長さLengthは、Hexaで09バイト即ち10進表示で09バイトである。なお、図2のステップS02及びS06でUIM2からME1に送信されるステータスワード91XX及び91YYのXX、YYはそれぞれ送信するProactiveコマンド1,2の長さを表している。図6は、第1の実施の形態の複数コマンド授受手順におけるProactiveコマンドデータフォーマットを示す図である。複数コマンド授受手順においてUIM2からME1に送信されるデータフォーマットは、図5に示すProactiveコマンド1のデータフォーマットとProactiveコマンド2のデータフォーマットとが連結して構成されている。なお、図3のステップS12でUIM2からME1に送信されるステータスワード91ZZのZZは、上述のXXとYYとを加算した値である。Proactiveコマンドデータを受信したME1は、そのコマンドデータからProactiveコマンド1,2を抽出する。ME1は、図6に示すLengthブロックを参照することでProactiveコマンド1,2を識別して抽出することができる。ME1は、Proactiveコマンド1に従ったキー入力要求画面表示処理と、Proactiveコマンド2に従った音声出力処理を実行する。ステップS15において、ME1はProactiveコマンド1,2に従った実行結果をTerminalResponseとしてUIM2に出力する。図7は、第1の実施の形態の通常のコマンド授受手順におけるTerminalResponseデータフォーマットを示す図である。図71はProactiveコマンド1に対応するTerminalResponse1のデータフォーマットを示し、図72はProactiveコマンド2に対応するTerminalResponse2のデータフォーマットを示す。TerminalResponseデータは、Tag、Length、Valueの各ブロックを含んでいる。Tagはコマンドの種類を表す。LengthはValueブロックの長さを表す。Valueはデータの内容を表す。これらのブロックのフォーマットは、Proactiveコマンドデータのブロックのフォーマットと同様の構成であるため、その詳細の説明は省略する。図8は、第1の実施の形態の複数コマンド授受手順におけるTerminalResponseデータフォーマットを示す図である。複数コマンド授受手順においてME1からUIM2に送信されるTerminalResponseデータフォーマットは、図7示すTerminalResponse1のデータフォーマットとTerminalResponse2のデータフォーマットとが連結して構成されている。UIM2は、TerminalResponseデータの内容を解析し、実行結果を確認する。ステップS16において、UIM2は9000のステータスワードを送信してProactiveコマンドの送信を終了する。これ以降の処理は、Appletのプログラムに従う。なお、ME1が処理するProactiveコマンド1,2についての実行順は、ProactiveコマンドデータのCommandDetailsのValueブロックにデータとして含めることができる。したがって、Proactiveコマンドの送信順序は実行順に配列されていても良く、配列されていなくても良い。一方、実行順が指定されていない場合は、ME1が処理するProactiveコマンド1,2についての実行順は、適宜ME1が選択しても良い。また、ME1が送信するTerminalResponseデータのCommandDetailsのValueブロックに実行順をデータとして含めることができる。したがって、この場合は、TerminalResponseデータは実行順に配列されていなくても良い。一方、ME1はTerminalResponseデータを実行順に配列して送信しても良い。第1の実施の形態のバリエーション第1の実施の形態のバリエーションでは、ME1がUIM2に対して送信するTerminalResponseデータの通信手順が第1の実施の形態と異なっている。第1の実施の形態と同一の部位には同一の符号を付してその詳細の説明は省略する。図9は、バリエーションの形態のME1とUIM2との間での複数コマンド授受手順を示す図である。ステップS21~ステップS24は、図3において説明したステップS11~ステップS14を同じであるため、その詳細の説明は省略する。Proactiveコマンドデータを受信したME1は、そのコマンドデータからProactiveコマンド1,2を抽出する。そして、ME1は、Proactiveコマンド1に従ったキー入力要求画面表示処理を実行する。ステップS25において、ME1はProactiveコマンド1に従った実行結果をTerminalResponse1としてUIM2に出力する。UIM2は、TerminalResponse1データの内容を解析し、実行結果を確認する。その後、ステップS30において、UIM2は9000のステータスワードを送信してProactiveコマンド1の送信を終了し、Proactiveコマンド2の実行結果を待つ。ME1は、Proactiveコマンド1に従った処理の後、Proactiveコマンド2に従った音声出力処理を実行する。ステップS26において、ME1はProactiveコマンド2に従った実行結果をTerminalResponse2としてUIM2に出力する。UIM2は、TerminalResponse2データの内容を解析し、実行結果を確認する。その後、ステップS27において、UIM2は9000のステータスワードを送信してProactiveコマンドの送信を終了する。これ以降の処理は、Appletのプログラムに従う。なお、ME1が処理するProactiveコマンド1,2についての実行順は、ProactiveコマンドデータのCommandDetailsのValueブロックにデータとして含めることができる。したがって、Proactiveコマンドの順序は実行順に配列されていても良く、配列されていなくても良い。一方、実行順が指定されていない場合は、ME1が処理するProactiveコマンド1,2についての実行順は、適宜ME1が選択しても良い。ME1からのTerminalResponseデータは実行順に送信されるため、UIM2は、TerminalResponseデータの実行順を容易に把握することができる。なお、上述の各実施の形態で述べた送信手順では、2つのProactiveコマンドを取り扱ったが、2個以上のProactiveコマンドを取り扱うことも可能である。1度の送信に含めることのできるコマンド数データ長は、通信規約あるいは製品のスペックによって最大データ長が定められている。従って、この範囲内において、複数のコマンド数を1つの送信データとすることができる。以上、説明した実施の形態によれば、一つの送信データに複数のProactiveコマンドを含むことができるため、ME1は複数の処理をタイムラグを少なくして実行することができる。また、複数コマンドを取り扱う際、ME1が処理する実行順を指定することができ、さらにME1が処理した実行順を容易に把握することができる。さらに、ME1とUIM2との間のコマンドレスポンスのやり取りを短縮化することができる。なお上述のUIM2は、ICカードに組み込み、カードリーダライタとの間でデータの送受信を行なうように構成することができる。図10は、本実施の形態のUIMをICカード100に組み込んで構成した例について説明するためのブロック図である。図10に示すように、ICカード100は、プラスチックなどで形成されたカード状の本体101と、本体101内に内蔵されたICモジュール102とを備えている。ICモジュール102は、1つ又は複数のICチップ103と、通信I/F部21とを備える。ICチップ103と通信I/F部21とは、互いに接続された状態でICモジュール102内に埋設して形成されている。本実施の形態のUIMはICモジュール102として構成することができる。尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。"