JP5472935B2 - 携帯可能電子機器及びｉｃカード - Google Patents

Description

本発明の実施の形態は、携帯可能電子機器及びＩＣカードに関する。

海外の多くの国は携帯電話システム方式としてＧＳＭ（登録商標）（Global System for Mobile communications）方式を採用している。ＧＳＭ（登録商標）方式においては携帯電話機内にＩＣカードの一種であるＳＩＭ（Subscriber Identitiy Module）カードが必須となっている。
日本では、ＧＳＭ（登録商標）でなく、３ＧＰＰ（3rd Generation Partnership Project）規格を採用した携帯電話システムが立ちあがっている。３ＧＰＰ規格でもＳＩＭカードと同様なＩＣカード、ＵＳＩＭ（Universal Subscriber Identitiy Module）カードが必須となっている。

ＧＳＭ（登録商標）や３ＧＰＰで使用されているＳＩＭ、ＵＳＩＭは携帯電話端末内に挿入される。ＳＩＭ、ＵＳＩＭには通信事業者の通信ネットワークに接続するのに必要な鍵情報、暗号アルゴリズム、各種ネットワークパラメータが記録されている。携帯電話端末はそれらの情報を通信事業者のＯＴＡ（Over The Air）サーバ、認証・管理サーバ等に送信し、これらのサーバと認証を行い、認証結果が正しければ、通信事業者の通信サービスを受けることが可能となる。

非特許文献１、２には、ＣＡＴ（Ｃａｒｄ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ）と呼ばれる仕様を規定している。ＣＡＴは、ＩＣカードの中のＳＩＭ、ＵＳＩＭ、ＵＩＭ等に代表される携帯電話等の加入者情報を識別する為のカード（以下、ＵＩＭと呼ぶ）に実装される。このＣＡＴの仕様の一つに、ＵＩＭから携帯電話（以下、ＭＥと呼ぶ）、または、ネットワークサーバに対して、各種操作要求や情報送信を行う、Ｐｒｏａｃｔｉｖｅコマンドと呼ばれる機能が規定されている。

ＥＴＳＩ ＴＳ １０２ ２２３ ＥＴＳＩ ＴＳ １０２ ２４１

上記規格によると、ＵＩＭにおいて、ＴｏｏｌＫｉｔ Ａｐｐｌｅｔと呼ばれるＡｐｐｌｅｔ、もしくは、組込ソフトウエアが実行された場合、ＵＩＭではＰｒｏａｃｔｉｖｅコマンド送信要求が発生することがある。この時、ＵＩＭは、ＭＥから送信されるＦｅｔｃｈコマンドに対するレスポンスデータとして、Ｐｒｏａｃｔｉｖｅコマンドを送信する。しかし、ＭＥがＦｅｔｃｈコマンドを送信するまで、ＵＩＭは、Ｐｒｏａｃｔｉｖｅコマンドを出力することができない。

一方、ＵＩＭでは、この状態とは独立にＡｐｐｌｅｔの動作によって別のＰｒｏａｃｔｉｖｅコマンド送信要求が発生し得る。そのため、ＵＩＭがＦｅｔｃｈコマンドを受信しない（ＭＥがＦｅｔｃｈを送信しない）状態が継続すると、ＵＩＭにおいて、未送信のＰｒｏａｃｔｉｖｅコマンドが蓄積する。
また、ＭＥからＵＩＭに対してリセット信号が供給されると、未送信のＰｒｏａｃｔｉｖｅコマンドの情報もリセットされてしまうため、送信すべきＰｒｏａｃｔｉｖｅコマンドが送信できない場合がある。

従って、ＵＩＭにおいて特定のコマンドによって発生したＭＥへの送信データが未送信のまま蓄積されること、また特定のコマンドによって発生したＭＥへの送信データが意図せずに消去されることを防止するニーズがある。

上記課題を解決するための本発明の実施の形態によれば、外部からのコマンド指示を解釈・実行し、その結果を応答する携帯可能電子装置において、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを生成するコマンド生成部と、前記生成した要求コマンドをメモリに記憶する記憶部と、前記特定のコマンド指示に対する応答の際前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際前記要求コマンドを前記外部に通知する通知部と、外部から前記要求コマンドの廃棄を指示された際前記記憶部内の要求コマンドを廃棄する廃棄部とを備えた携帯可能電子装置が提供される。

本実施の形態のＭＥとＵＩＭとの接続とそれぞれの構成ブロックとを示す図。 本実施の形態のＭＥとＵＩＭとの間での通常のコマンド授受手順を示す図。 本実施の形態のＭＥとＵＩＭとの間でのＰｒｏａｃｔｉｖｅコマンドが蓄積された際に破棄する通信手順を示す図。 本実施の形態のＴ−１プロトコルフォーマットを示す図。 本実施の形態のＭＥとＵＩＭとの間でのＰｒｏａｃｔｉｖｅコマンドが蓄積された際に再送信する通信手順を示す図。 本実施の形態の通信手順を実現するためのＵＩＭの動作手順を示すフローチャート。 本実施の形態のＵＩＭをＩＣカードに組み込んで構成した例について説明するためのブロック図。

[第１の実施の形態]
図１は、本実施の形態の携帯電話端末（ＭＥ）１とＵＩＭ２との接続とそれぞれの構成ブロックとを示す図である。ＵＩＭ２は、携帯可能電子機器であり、ＭＥ１に装着されて携帯電話アプリ利用時のデータをハンドリングする。

ＭＥ１には、制御部１１、表示部１２、通信部１４及び入力部１５が設けられている。制御部１１は、ＭＥ１内の各部の動作を統括して制御する。表示部１２は、ユーザに対して情報を表示する。通信部１４は、ＵＩＭ２との間のデータ通信を実行する。入力部１５は、ユーザからの指示を入力する。

ＵＩＭ２は、通信インターフェース部２１、制御部２２、ＲＡＭ２３、ＲＯＭ２４、不揮発性メモリ２５を備えている。

通信インターフェース部２１は、ＭＥ１から送信されるデータを受信して制御部２２に出力する。制御部２２は、演算、制御などを行い、ＵＩＭ２を統括して制御する。ＲＯＭ２４は、読み出し専用メモリである。ＲＯＭ２４には、オペレーティングシステム（ＯＳ）などの基本ソフトウエア、アプリケーション及びデータが格納されている。ＲＡＭ２３は、制御部２２の処理における作業領域として使用される。不揮発性メモリ２５は、ＥＥＰＲＯＭ、フラッシュメモリなどの書き換え可能な不揮発性のメモリであり、通常ユーザのワークエリア、プログラムエリアなどとして使用されている。後述のＡｐｐｌｅｔは、不揮発性メモリ２５に格納されている。

図２は、本実施の形態のＭＥ１とＵＩＭ２との間での通常のコマンド授受手順を示す図である。

ステップＳ０１において、ＭＥ１はＵＩＭ２にＥｎｖｅｌｏｐｅコマンドを送信する。ここで、Ｅｎｖｅｌｏｐｅコマンドには、上述の規格において複数種類のフォーマットが規定されている。Ｅｖｅｎｔｄｏｗｎｌｏａｄはこのフォーマットの１種類であり、ＭＥ１で所定のイベントが発生したことをＵＩＭ２に通知する内容である。

ＵＩＭ２では、受信したＥｎｖｅｌｏｐｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際にＭＥ１に何らかの動作を起こさせる場合、例えば、ＭＥ１の表示部１２に画面を表示する処理を実行させる場合は、ＭＥ１に対して画面表示を指定したＰｒｏａｃｔｉｖｅコマンド送信することが必要である。そこでステップＳ０２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、Ｐｒｏａｃｔｉｖｅコマンドの送信要求を表す。即ち、ＵＩＭ２に送信すべきＰｒｏａｃｔｉｖｅコマンドがあるということを表している。

「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ０３において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ステップＳ０４において、Ｐｒｏａｃｔｉｖｅコマンドと「９０００」のステータスワードをＭＥ１に送信する。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。例えば、音声を出力する、画面表示を行なう、電話を発信するなどの動作を実行する。

ステップＳ０５において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。例えば、実行完了した、ユーザが操作中により実行できない、エラーが発生して実行を中止したなどの応答を返送する。ステップＳ０６において、ＵＩＭ２は、Ａｐｐｌｅｔのプログラムに従い、以降の処理を行なう。Ａｐｐｌｅｔが後続で処理するＰｒｏａｃｔｉｖｅコマンドがない場合、「９０００」のステータスワードを送信する。

次にＰｒｏａｃｔｉｖｅコマンド送信が正常に行われず、Ｐｒｏａｃｔｉｖｅコマンドが蓄積される場合の手続きについて説明する。
図３は、本実施の形態のＭＥ１とＵＩＭ２との間でのＰｒｏａｃｔｉｖｅコマンドが蓄積された際に破棄する通信手順を示す図である。

ステップＳ１１において、ＭＥ１は、Ｅｎｖｅｌｏｐｅ（Ｅｖｅｎｔ ｄｏｗｎｌｏａｄ）を送信する。ＵＩＭ２は、このコマンドの受信をトリガとして、Ａｐｐｌｅｔを起動する。そして、ＵＩＭ２は、ステップＳ１２において、送信すべきＰｒｏａｃｔｉｖｅコマンドがあることを示すステータスワード（ＳＷ）＝９１ｘｘをＭＥ１に送信する。ここまでの処理は、図２で説明した手順と同様である。

通常であれば、ＭＥ１は、ＦｅｔｃｈコマンドをＵＩＭ２に送信する。しかし、ＭＥがＦｅｔｃｈコマンドを送信できない処理を実行している場合、ＦｅｔｃｈコマンドはＵＩＭ２に送信されず、実行している処理に関する他のコマンドが送信される。ステップＳ１３において、ＭＥ１はＳｅｌｅｃｔコマンドを送信する。ＵＩＭ２は、Ｓｅｌｅｃｔコマンドを受信し、正常に処理を行う。次にＵＩＭ２は、コマンドが送信される毎に、送信すべきＰｒｏａｃｔｉｖｅコマンドがあるか否かを調べる。そして、未送信のＰｒｏａｃｔｉｖｅコマンドが存在するため、ステップＳ１４において、ＳＷ＝９１ｘｘをＭＥ１に送信する。

その後、ＭＥ１はＦｅｔｃｈコマンドを送信せず、ステップＳ１５において、ステップＳ１１とは異なる別のＥｎｖｅｌｏｐｅ（Ｍｅｎｕ Ｓｅｌｅｃｔｉｏｎｎ）コマンドをＵＩＭ２に送信する。ＵＩＭ２は、このＥｎｖｅｌｏｐｅコマンドをトリガとして、Ａｐｐｌｅｔを起動する。すると、Ａｐｐｌｅｔは、Ｐｒｏａｃｔｉｖｅコマンド送信要求をＵＩＭ２に対して行う。ステップＳ１６において、ＵＩＭ２はＭＥ１にＳＷ＝９１ｘｘを送信する。

上述のケースでは、１回目のＡｐｐｌｅｔ起動で発生したＰｒｏａｃｔｉｖｅコマンドと、２回目のＡｐｐｌｅｔ起動で発生したＰｒｏａｃｔｉｖｅコマンドの２つのＰｒｏａｃｔｉｖｅコマンドがＵＩＭ２に蓄積されている。このように、Ｐｒｏａｃｔｉｖｅコマンドを受信した後、ＭＥ１側の理由によりＭＥ１がＦｅｔｃｈコマンドを送信しない場合には、ＵＩＭ２にはＰｒｏａｃｔｉｖｅコマンドが蓄積される状態が発生する。

次に、ＭＥ１側の対応について説明する。例えば、ユーザがＭＥ１にメールの文章を入力しているなど操作を実行中である場合を考える。このとき、Ｐｒｏａｃｔｉｖｅコマンドを受信してそのコマンドに対応した画面が表示されると、現在ユーザが使用している機能が一時中断されることになり、甚だ不都合な状態となる。従って、このときは、ＭＥ１ではＰｒｏａｃｔｉｖｅコマンドを受信できないようにする。即ち、ＭＥ１がＰｒｏａｃｔｉｖｅコマンドを受信、処理出来る状況に無い場合、ＵＩＭ２からのＳＷ＝９１ＸＸを受信したＭＥ１はＵＩＭ２に対し、Ｐｒｏａｃｔｉｖｅコマンドの破棄を要求することができる。

ステップＳ１７において、ＭＥ１は、Ｐｒｏａｃｔｉｖｅコマンド破棄を示すＳｅｌｅｃｔコマンドをＵＩＭ２に送信する。このＳｅｌｅｃｔコマンドの送信は、ＭＥ１において所定のジョブを実行中におけるステップＳ１６に示すＳＷ＝９１ｘｘの受信に対応して実行する。ＵＩＭ２はコマンドデータにおいて、Ｐｒｏａｃｔｉｖｅコマンド破棄が示されているときは、現状蓄積しているＰｒｏａｃｔｉｖｅコマンドを破棄する。なお、Ｐｒｏａｃｔｉｖｅコマンドを破棄する方法は、Ｓｅｌｅｃｔコマンドで指定することができる。例えば、一番古いＰｒｏａｃｔｉｖｅコマンドを破棄するように指定することができ、あるいは蓄積している全てのＰｒｏａｃｔｉｖｅコマンドを破棄するように指定することができる。ＵＩＭ２は、Ｐｒｏａｃｔｉｖｅコマンドを破棄し、ステップＳ１８において、ステータスワードを送信する。Ｐｒｏａｃｔｉｖｅコマンドがない場合はＳＷ＝９０００を送信し、Ｐｒｏａｃｔｉｖｅコマンドが残っている場合はＳＷ＝９１ｘｘを返す。

なお、Ｐｒｏａｃｔｉｖｅコマンド破棄を指示する場合、コマンドをＴ＝１プロトコルのＩ−ｂｌｏｃｋとして送信して、そのＰＣＢでＰｒｏａｃｔｉｖｅコマンド破棄を示すことができる。

図４は、本実施の形態のＴ−１プロトコルフォーマットを示す図である。
Ｔ−１プロトコルフォーマット（ＩＳＯ０７８１６）では、コマンドはＮＡＤ、ＰＣＢ、ＬＥＮ、ＩＮＦ、ＥＤＣで構成される。ＮＡＤは、アドレスを表す。ＰＣＢは、モードを示す制御コードである。ＬＥＮは、コマンドの長さを示す。ＩＮＦはコマンドの種類（Ｓｅｌｅｃｔ，Ｐｒｏａｃｔｉｖｅなど）を表す。ＥＤＣは、誤り検出用チェックコードである。
ＰＣＢは、モードがＩ−ｂｌｏｃｋのときは、８バイトで構成され、右の５バイトが未使用となっている。そこで、この未使用のデータ領域にコマンド破棄を示すデータを記載することができる。

図５は、本実施の形態のＭＥ１とＵＩＭ２との間でのＰｒｏａｃｔｉｖｅコマンドが蓄積された際に再送信する通信手順を示す図である。
ステップＳ２１〜Ｓ２６の手順は、図３に示すステップＳ１１〜Ｓ１６の手順と同一であるためその詳細の説明は省略する。

ＭＥ１は、Ｐｒｏａｃｔｉｖｅコマンドの受信を再開する場合は、ステップＳ３１において、ＵＩＭ２にＲｅｓｅｔコマンドを送信する。このＲｅｓｅｔコマンドは、例えばＭＥ１の電源をオフからオンした場合にＵＩＭ２を初期化するために送信されるコマンドである。従って、Ｒｅｓｅｔコマンドを受信したＵＩＭ２は、ＲＡＭ２３をクリアする。従来では、ＰｒｏａｃｔｉｖｅコマンドはＲＡＭ２３に蓄積されていたため破棄されることになる。しかし、本実施の形態ではＰｒｏａｃｔｉｖｅコマンドは不揮発性メモリ２５に蓄積されているため、破棄されない。ステップＳ３２において、ＵＩＭ２は、リセットに対する応答としてＡＴＲ（ａｎｓｗｅｒ ｔｏ ｒｅｓｅｔ）を返す。

ステップＳ３３において、ＭＥ１は、Ｓｅｌｅｃｔコマンドを送信する。ＵＩＭ２は、Ｓｅｌｅｃｔコマンドを受信し、正常に処理を行う。次にＵＩＭ２は、送信すべきＰｒｏａｃｔｉｖｅコマンドがあるか否かを調べる。不揮発性メモリ２５には、送信したいＰｒｏａｃｔｉｖｅコマンドが存在するため、ステップＳ３４において、ＳＷ＝９１ｘｘをＭＥ１に送信する。

「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ３５において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ステップＳ３６において、Ｐｒｏａｃｔｉｖｅコマンドと「９０００」のステータスワードをＭＥ１に送信する。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。例えば、音声を出力する、画面表示を行なう、電話を発信するなどの動作を実行する。

ステップＳ３７において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。例えば、実行完了した、ユーザが操作中により実行できない、エラーが発生して実行を中止したなどの応答を返送する。Ｔｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅを受信したＵＩＭ２は、さらに送信すべきＰｒｏａｃｔｉｖｅコマンドがあるか否かを調べる。送信すべきＰｒｏａｃｔｉｖｅコマンドがある場合は、ステップＳ３８において、ＳＷ＝９１ｘｘをＭＥ１に送信する。

以降、残存するＰｒｏａｃｔｉｖｅコマンドの数だけステップＳ３５〜Ｓ３８の処理を繰り返して実行する。

ステップＳ４１において、「９１ＸＸ」のステータスワードを受信したＭＥ１は、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ステップＳ４２において、Ｐｒｏａｃｔｉｖｅコマンドと「９０００」のステータスワードをＭＥ１に送信する。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。ステップＳ４３において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。Ｔｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅを受信したＵＩＭ２は、ステップＳ４４において、送信すべきＰｒｏａｃｔｉｖｅコマンドがないことを示す、ＳＷ＝９０００をＭＥ１に送信する。

以上、図３乃至図５で説明した手順によれば、Ｐｒｏａｃｔｉｖｅコマンドを所望のタイミングで破棄し、また、リセット後に再開することができる。

次に、上述の通信手順を実現するためのＵＩＭ２の処理フローについて図６を参照しつつ説明する。なお、図６に示す「ＵＩＭ−制御部」は制御部２２を示し、「ＵＩＭ−Ａｐｐｌｅｔ部」は、不揮発性メモリ２５に格納されているＡｐｐｌｅｔを示す。

ステップＳ５０において、ＭＥ１がコマンドを送信する。ステップＴ０１において、ＵＩＭ−制御部はコマンドを受信し、ステップＴ０２において、コマンドを解釈する。ステップＴ０３において、受信コマンドにＰｒｏａｃｔｉｖｅコマンドの破棄が指示されているか否かを判断する。

受信コマンドにＰｒｏａｃｔｉｖｅコマンドの破棄が指示されている場合、ステップＴ０４において、不揮発性メモリ２５に蓄積されているＰｒｏａｃｔｉｖｅコマンドを破棄する。そして、ステップＴ０５に進む。受信コマンドにＰｒｏａｃｔｉｖｅコマンドの破棄が指示されていない場合、ステップＴ０５において、コマンドを解釈する。ステップＴ０６において、Ａｐｐｌｅｔの実行が必要か否かを判断する。

例えば、上述の例では、コマンドがＥｎｖｅｌｏｐｅ、Ｆｅｔｃｈの場合はＡｐｐｌｅｔの実行が必要と判断し、コマンドがＴｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅの場合はＡｐｐｌｅｔの実行が不要と判断する。

ステップＴ０６において、Ａｐｐｌｅｔの実行が不要と判断した場合は、ステップＴ１０において、コマンドを実行する。ステップＴ１１において、不揮発性メモリ２５にＰｒｏａｃｔｉｖｅコマンドが蓄積されているか否かを調べる。

不揮発性メモリ２５にＰｒｏａｃｔｉｖｅコマンドが蓄積されていない場合は、ステップＴ１２において、ＳＷ＝９０００とする。不揮発性メモリ２５にＰｒｏａｃｔｉｖｅコマンドが蓄積されている場合は、ステップＴ１３において、ＳＷ＝９１ＸＸとする。

ステップＴ１４において、レスポンスを送信する。ステップＳ５１において、ＭＥ１はレスポンスを受信する。

ステップＴ０６において、Ａｐｐｌｅｔの実行が必要と判断した場合は、ステップＰ０１において、Ａｐｐｌｅｔを実行し、ステップＰ０２において、コマンドを解釈する。ステップＰ０３において、コマンドはＦｅｔｃｈかどうかを判断する。

コマンドがＦｅｔｃｈでない場合は、ステップＰ０４においてＡｐｐｌｅｔを実行する。ステップＰ０５において、Ｐｒｏａｃｔｉｖｅコマンド送信の要否を判断する。
Ｐｒｏａｃｔｉｖｅコマンド送信が不要のときは、ステップＴ１２において、ＳＷ＝９０００とする。そして、ステップＴ１４において、レスポンスを送信する。
Ｐｒｏａｃｔｉｖｅコマンド送信が要のときは、ステップＰ０６において、Ｐｒｏａｃｔｉｖｅコマンドを不揮発性メモリ２５に格納する。ステップＴ１３において、ＳＷ＝９１ＸＸとする。そして、ステップＴ１４において、レスポンスを送信する。
ステップＰ０３において、コマンドがＦｅｔｃｈの場合は、ステップＰ０７において、ＰｒｏａｃｔｉｖｅコマンドとＳＷ＝９１ＸＸを送信データにセットする。ステップＰ０８において、送信するＰｒｏａｃｔｉｖｅコマンドを不揮発性メモリ２５から削除する。ステップＴ１４において、レスポンスを送信する。

なお、図６に示すフロー図では、ステップＴ０３において、受信コマンドにＰｒｏａｃｔｉｖｅコマンドの破棄が指示されている場合、ステップＴ０４において、不揮発性メモリ２５に蓄積されているＰｒｏａｃｔｉｖｅコマンドを破棄したが、不揮発性メモリ２５内の全てのＰｒｏａｃｔｉｖｅコマンドを破棄するのではなく、一番古いＰｒｏａｃｔｉｖｅコマンドを破棄するようにしても良い。

なお上述のＵＩＭ２は、ＩＣカードに組み込み、カードリーダライタとの間でデータの送受信を行なうように構成することができる。
図７は、本実施の形態のＵＩＭをＩＣカード１００に組み込んで構成した例について説明するためのブロック図である。

図７に示すように、ＩＣカード１００は、プラスチックなどで形成されたカード状の本体１０１と、本体１０１内に内蔵されたＩＣモジュール１０２とを備えている。ＩＣモジュール１０２は、１つ又は複数のＩＣチップ１０３と、通信Ｉ／Ｆ部２１とを備える。ＩＣチップ１０３と通信インターフェース部２１とは、互いに接続された状態でＩＣモジュール１０２内に埋設して形成されている。本実施の形態のＵＩＭはＩＣモジュール１０２として構成することができる。

尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１…携帯電話端末、２…携帯可能電子装置、１１…制御部、１２…表示部、１４…通信部、１５…入力部、２１…通信インターフェース部、２２…制御部、２３…ＲＡＭ、２４…ＲＯＭ、２５…不揮発性メモリ、１００…ＩＣカード、１０１…本体、１０２…ＩＣモジュール、１０３…ＩＣチップ。

Claims (7)

1. 外部からのコマンド指示を解釈・実行し、その結果を応答する携帯可能電子装置において、
   外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを生成するコマンド生成部と、
   前記生成した要求コマンドをメモリに記憶する記憶部と、
   前記特定のコマンド指示に対する応答の際前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際前記要求コマンドを前記外部に通知する通知部と、
   外部から前記要求コマンドの廃棄を指示された際前記記憶部内の要求コマンドを廃棄する廃棄部と
   を備えたことを特徴とする携帯可能電子装置。
2. 前記通知部は、
   前記廃棄を指示するコマンド指示以外のコマンド指示を受信した際前記メモリ内に前記要求コマンドがある場合は前記要求コマンドの発生を前記外部に通知すること
   を特徴とする請求項１に記載の携帯可能電子装置。
3. 前記廃棄部は、前記メモリ内の要求コマンドを全て廃棄することを特徴とする請求項２に記載の携帯可能電子装置。
4. 前記廃棄部は、前記メモリ内の一番古い要求コマンドを廃棄することを特徴とする請求項２に記載の携帯可能電子装置。
5. 外部から初期化を指示するコマンド指示を受信した際前記携帯可能電子装置を初期化するリセット部を有し、
   前記リセット部は、前記メモリ内の要求コマンドを廃棄しないことを特徴とする請求項２に記載の携帯可能電子装置。
6. 前記記憶部は、前記生成した要求コマンドを不揮発性メモリに記憶することを特徴とする請求項５に記載の携帯可能電子装置。
7. 請求項１乃至６の内いずれか１項に記載の各部を有するＩＣモジュールと、
   このＩＣモジュールを収納したＩＣカード本体と
   を備えたことを特徴とするＩＣカード。

Images