ＩＣカード
【課題】ＵＩＭにおいてタイムラグを少なくしてＭＥに実行させたい複数のコマンドがある場合、これら複数のコマンドの送受信を効率的に実行でき、ＭＥがこれら複数のコマンドを少ないタイムラグで実行する。
【解決手段】外部装置１からのコマンド指示を解釈・実行し、その結果を応答するＩＣカード２において、外部装置の処理能力を表す情報を取得する能力情報取得部と、外部装置からの特定のコマンド指示に対して外部装置に特定の動作を求める要求コマンドを複数生成するコマンド生成部と、特定のコマンド指示に対する応答の際、要求コマンドの発生を外部に通知する通知部と、外部から要求コマンドの取り出しを指示された際、生成した複数の要求コマンドの内、外部装置の処理能力に応じた少なくとも一つの要求コマンドを一つの応答要求コマンドにまとめて外部装置に送出する送出部とを備えた。
【解決手段】外部装置１からのコマンド指示を解釈・実行し、その結果を応答するＩＣカード２において、外部装置の処理能力を表す情報を取得する能力情報取得部と、外部装置からの特定のコマンド指示に対して外部装置に特定の動作を求める要求コマンドを複数生成するコマンド生成部と、特定のコマンド指示に対する応答の際、要求コマンドの発生を外部に通知する通知部と、外部から要求コマンドの取り出しを指示された際、生成した複数の要求コマンドの内、外部装置の処理能力に応じた少なくとも一つの要求コマンドを一つの応答要求コマンドにまとめて外部装置に送出する送出部とを備えた。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、ＩＣカードに関する。
【背景技術】
【０００２】
海外の多くの国は携帯電話システム方式としてＧＳＭ（登録商標）（Global System for Mobile communications）方式を採用している。ＧＳＭ（登録商標）方式においては携帯電話機内にＩＣカードの一種であるＳＩＭ（Subscriber Identitiy Module）カードが必須となっている。
日本では、ＧＳＭ（登録商標）でなく、３ＧＰＰ（3rd Generation Partnership Project）規格を採用した携帯電話システムが立ちあがっている。３ＧＰＰ規格でもＳＩＭカードと同様なＩＣカード、ＵＳＩＭ（Universal Subscriber Identitiy Module）カードが必須となっている。
【０００３】
ＧＳＭ（登録商標）や３ＧＰＰで使用されているＳＩＭ、ＵＳＩＭは携帯電話端末内に挿入される。ＳＩＭ、ＵＳＩＭには通信事業者の通信ネットワークに接続するのに必要な鍵情報、暗号アルゴリズム、各種ネットワークパラメータが記録されている。携帯電話端末はそれらの情報を通信事業者のＯＴＡ（Over The Air）サーバ、認証・管理サーバ等に送信し、これらのサーバと認証を行い、認証結果が正しければ、通信事業者の通信サービスを受けることが可能となる。
【０００４】
非特許文献１乃至３には、ＣＡＴ（Ｃａｒｄ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ）と呼ばれる仕様を規定している。ＣＡＴは、ＩＣカードの中のＳＩＭ、ＵＳＩＭ、ＵＩＭ等に代表される携帯電話等の加入者情報を識別する為のカード（以下、ＵＩＭと呼ぶ）に実装される。このＣＡＴの仕様の一つに、ＵＩＭから携帯電話（以下、ＭＥと呼ぶ）、または、ネットワークサーバに対して、各種操作要求や情報送信を行う、Ｐｒｏａｃｔｉｖｅコマンドと呼ばれる機能が規定されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＥＴＳＩ ＴＳ １０２ ２２３
【非特許文献２】ＥＴＳＩ ＴＳ １０２ ２４１
【非特許文献３】ＥＴＳＩ ＴＳ １０２ ２２１
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記規格によると、ＵＩＭにおいて、ＴｏｏｌＫｉｔ Ａｐｐｌｅｔと呼ばれるＡｐｐｌｅｔ、もしくは、組込ソフトウエアが実行された場合、ＵＩＭではＰｒｏａｃｔｉｖｅコマンド送信要求が発生することがある。この時、ＵＩＭは、ＭＥから送信されるＦｅｔｃｈコマンドに対するレスポンスデータとして、Ｐｒｏａｃｔｉｖｅコマンドを送信する。その後、ＭＥは、受信したＰｒｏａｃｔｉｖｅコマンドに基づき処理を行い、その実行結果を示すため、Ｔｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅコマンドを出力する。
【０００７】
この時、現状の規格においては、１度に送信できるＰｒｏａｃｔｉｖｅコマンドは１つのＰｒｏａｃｔｉｖｅコマンドのみである。そのため、ＭＥに対して、ユーザからのキー入力要求と音出力要求の２つの要求を送信したい場合、２つのＰｒｏａｃｔｉｖｅコマンドを出力する必要がある。そのため、上記規格で規定される手順である、Ｆｅｔｃｈ→Ｔｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅのコマンド送受信の手順を２度繰り返して実行する必要があり、実行処理が煩雑である。また、ユーザによるキー入力要求と音出力とをほぼ同時に実行させたい場合であっても、２つのＰｒｏａｃｔｉｖｅコマンドの送受信に長いタイムラグが生じるため所望の動作が行なわれない恐れがある。更に２つのＰｒｏａｃｔｉｖｅコマンドを所望の順序で実施させたい場合もある。
【０００８】
従って、ＵＩＭにおいてタイムラグを少なくしてＭＥに実行させたい複数のコマンドがある場合、これら複数のコマンドの送受信を効率的に実行でき、ＭＥがこれら複数のコマンドを少ないタイムラグで実行できる技術に対するニーズがある。
【課題を解決するための手段】
【０００９】
上記課題を解決するための本発明の実施の形態によれば、外部装置からのコマンド指示を解釈・実行し、その結果を応答するＩＣカードにおいて、前記外部装置の処理能力を表す情報を取得する能力情報取得部と、前記外部装置からの特定のコマンド指示に対して前記外部装置に特定の動作を求める要求コマンドを複数生成するコマンド生成部と、前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知する通知部と、前記外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドの内、前記外部装置の処理能力に応じた少なくとも一つの前記要求コマンドを一つの応答要求コマンドにまとめて前記外部装置に送出する送出部とを備えたＩＣカードが提供される。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態のＭＥとＵＩＭとの接続とそれぞれの構成ブロックとを示す図。
【図２】第１の実施の形態のＭＥとＵＩＭとの間での通常のコマンド授受手順を示す図。
【図３】第１の実施の形態のＭＥとＵＩＭとの間でのコマンド授受手順を示す図。
【図４】第１の実施の形態のＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドデータの構成を示す図。
【図５】第１の実施の形態のＵＩＭにおけるＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンド処理手順を示すフロー図。
【図６】第１の実施の形態のＵＩＭにおけるＦｅｔｃｈコマンド処理手順を示すフロー図。
【図７】本実施の形態のＵＩＭをＩＣカードに組み込んで構成した例について説明するためのブロック図。
【発明を実施するための形態】
【００１１】
以下、本実施の形態のＩＣカードを携帯可能電子機器であるＵＩＭとして説明する。また、ＩＣカードと情報を授受するＴｅｒｍｉｎａｌを携帯電話端末として説明する。
【００１２】
[第１の実施の形態]
図１は、本実施の形態の携帯電話端末（ＭＥ）１とＵＩＭ２との接続とそれぞれの構成ブロックとを示す図である。ＵＩＭ２は、携帯可能電子機器であり、ＭＥ１に装着されて携帯電話アプリ利用時のデータをハンドリングする。
【００１３】
ＭＥ１には、制御部１１、表示部１２、通信部１４及び入力部１５が設けられている。制御部１１は、ＭＥ１内の各部の動作を統括して制御する。表示部１２は、ユーザに対して情報を表示する。通信部１４は、ＵＩＭ２との間のデータ通信を実行する。入力部１５は、ユーザからの指示を入力する。
【００１４】
ＵＩＭ２は、通信インターフェース部２１、制御部２２、ＲＡＭ２３、ＲＯＭ２４、不揮発性メモリ２５を備えている。
【００１５】
通信インターフェース部２１は、ＭＥ１から送信されるデータを受信して制御部２２に出力する。また、通信インターフェース部２１は、制御部２２からデータを入力してＭＥ１に送信する。制御部２２は、演算、制御などを行い、ＵＩＭ２を統括して制御する。ＲＯＭ２４は、読み出し専用メモリである。ＲＯＭ２４には、オペレーティングシステム（ＯＳ）などの基本ソフトウエア、アプリケーション及びデータが格納されている。ＲＡＭ２３は、制御部２２の処理における作業領域として使用される。不揮発性メモリ２５は、ＥＥＰＲＯＭ、フラッシュメモリなどの書き換え可能な不揮発性のメモリであり、通常ユーザのワークエリア、プログラムエリアなどとして使用されている。後述のＡｐｐｌｅｔは、不揮発性メモリ２５に格納されている。
【００１６】
図２は、第１の実施の形態のＭＥ１とＵＩＭ２との間での通常のコマンド授受手順を示す図である。
【００１７】
ステップＳ０１において、ＭＥ１はＵＩＭ２にＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドを送信する。Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドには、ＭＥ１によってサポートされているＣＡＴ機能を表したリストがコンテンツとして含まれる。
【００１８】
ＵＩＭ２では、受信したＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際にＭＥ１に何らかの動作を起こさせる場合、例えば、ＭＥ１の表示部１２にユーザキー入力要求を表示する処理を実行させる場合は、ＭＥ１に対してキー入力要求画面表示を指定したＰｒｏａｃｔｉｖｅコマンドを送信することが必要である。そこでステップＳ０２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、Ｐｒｏａｃｔｉｖｅコマンドの送信要求を表す。即ち、ＵＩＭ２に送信すべきＰｒｏａｃｔｉｖｅコマンドがあるということを表している。
【００１９】
ＵＩＭ２から「９１ＸＸ」の応答コードが返されると、ＭＥ１はＵＩＭ２が長さ「ＸＸ」のデータを送出する準備ができたと判断し、ステップＳ０３において、ＦＥＴＣＨコマンドをＵＩＭ２に送信する。
【００２０】
ステップＳ０４において、ＵＩＭ２はＦＥＴＣＨコマンドに対して一個のＰｒｏａｃｔｉｖｅコマンド（例えば、Ｓｅｔ Ｕｐ Ｍｅｎｕコマンド）を送出する。Ｓｅｔ Ｕｐ Ｍｅｎｕコマンドは、ＭＥ１がＵＩＭ２に対して利用可能な機能についての情報を、ＵＩＭ２がＭＥ１に通知するためのコマンドである。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。
【００２１】
ステップＳ０５において、ＭＥ１は処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ０６において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。
【００２２】
続いて、ＭＥ１では、ユーザが例えば所望の操作を実行する。ステップＳ０７において、ＭＥ１はＵＩＭ２にＥｎｖｅｌｏｐｅコマンドを送信する。ここで、Ｅｎｖｅｌｏｐｅコマンドには、上述の規格において複数種類のフォーマットが規定されている。「Ｍｅｎｕ Ｓｅｌｅｃｔｉｏｎ」はこのフォーマットの１種類であり、ＭＥ１でメニューが選択されたというイベントが発生したことをＵＩＭ２に通知する内容である。
【００２３】
ＵＩＭ２では、受信したＥｎｖｅｌｏｐｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際にＭＥ１に何らかの動作を起こさせる場合、例えば、ＭＥ１の表示部１２に文字情報を表示する処理を実行させる場合は、ＭＥ１に対して表示文字情報を指定したＰｒｏａｃｔｉｖｅコマンドを送信することが必要である。そこでステップＳ０８において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、Ｐｒｏａｃｔｉｖｅコマンドの送信要求を表す。即ち、ＵＩＭ２に送信すべきＰｒｏａｃｔｉｖｅコマンドがあるということを表している。
【００２４】
「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ０９において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ステップＳ１０において、表示文字情報（１）を指定したＰｒｏａｃｔｉｖｅコマンドをＭＥ１に送信する。
【００２５】
Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した情報表示処理を実行する。そして、ステップＳ１１において、ＭＥ１は情報表示処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。
【００２６】
ＵＩＭ２は、未送信のＰｒｏａｃｔｉｖｅコマンドが残っているかどうかを調べる。
【００２７】
表示文字情報（２）及び表示文字情報（３）が未送信であるため、ステップＳ１２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。
【００２８】
ステップＳ１３〜Ｓ１８において、上述の手順を繰り返して、ＭＥ１とＵＩＭ２との間で、表示文字情報（２）及び表示文字情報（３）についての送受信が実行される。
【００２９】
ステップＳ１９において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ２０において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。これ以降の処理は、Ａｐｐｌｅｔのプログラムに従う。
【００３０】
上述のように、通常の手順ではＭＥ１がＵＩＭ２に対してＦｅｔｃｈコマンドを実行する毎に、ＵＩＭ２は内部に用意した複数のＰｒｏａｃｔｉｖｅコマンド（この例ではＤｉｓｐｌａｙ Ｔｅｘｔコマンド）を一個づつ送出する。
【００３１】
図３は、第１の実施の形態のＭＥ１とＵＩＭ２との間でのコマンド授受手順を示す図である。
【００３２】
ステップＳ３１において、ＭＥ１はＵＩＭ２にＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドを送信する。このＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドには、ＭＥ１の動作環境に関する情報、例えばＭＥ１の表示器に表示できるデータ容量などの情報が追加して含まれている。
【００３３】
図４は、第１の実施の形態のＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドデータの構成を示す図である。
Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドデータのコマンドパラメータには、「Ｄｅｓｃｒｉｐｔｉｏｎ」、「Ｃｌａｕｓｅ」、「Ｍ／Ｏ／Ｃ」、「Ｌｅｎｇｔｈ」の各ブロックが設けられている。「Ｄｅｓｃｒｉｐｔｉｏｎ」ブロックには、ＭＥ１によってサポートされているＣＡＴ機能を表したリストがコンテンツとして含まれる。
【００３４】
このコンテンツには、それぞれの機能ごとにＭＥ１によってサポートされているか否かのビット情報がバイトデータ（バイト単位）として記録されている。このバイトデータには、未使用領域であるＲＦＵ（Reserved For Future Use）ビットが設けられているものがある。また、複数のサブシークェント（Subsequent）バイトは、全てがＲＦＵビットで構成されている追加可能な未使用領域である。
【００３５】
従って、この未使用領域に上述の動作環境に関する情報を格納することができる。例えば、動作環境が表示機能の場合は、表示できる全文字数、表示できる文字の種類などを規定することができる。動作環境が音声機能の場合は、音声データの容量、音声方式などを規定することができる。
【００３６】
図３のステップＳ３２において、ＵＩＭ２では、受信したＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際、ＡｐｐｌｅｔはＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに記録されているＭＥ１の動作環境に関する情報（表示機能＝５０文字）を取得して保存する。そして、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、上述のようにＰｒｏａｃｔｉｖｅコマンドの送信要求を表す。
【００３７】
ＵＩＭ２から「９１ＸＸ」の応答コードが返されると、ＭＥ１はＵＩＭ２が長さ「ＸＸ」のデータを送出する準備ができたと判断し、ステップＳ３３において、ＦＥＴＣＨコマンドをＵＩＭ２に送信する。
【００３８】
ステップＳ３４において、ＵＩＭ２はＦＥＴＣＨコマンドに対して一個のＰｒｏａｃｔｉｖｅコマンド（Ｓｅｔ Ｕｐ Ｍｕｎｅ）を送出する。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。
【００３９】
ステップＳ３５において、ＭＥ１は処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ３６において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。
【００４０】
図５は、第１の実施の形態のＵＩＭ２におけるＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンド処理手順を示すフロー図である。
【００４１】
ステップＳ５１において、ＵＩＭ２は、ＭＥ１からのコマンドの受信を待機する。そして、コマンドを受信した場合は、ステップＳ５２において、受信したコマンドがＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドかどうかを調べる。
【００４２】
受信したコマンドがＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドでない場合（ステップＳ５２ ＮＯ）は、ステップＳ５３において、受信したコマンドに対応した処理を実行する。
【００４３】
受信したコマンドがＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドである場合（ステップＳ５２ Ｙｅｓ）は、ステップＳ５４において、ＵＩＭ２は、コマンドデータ部にＭＥ１の処理能力・動作環境に関する情報があればその情報を保存する。ステップＳ５５において、ＵＩＭ２は、コマンドデータ部にあるその他の情報を保存する。そして、ステップＳ５６において、ＵＩＭ２は、Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドを受信済みのフラグを設定する。
【００４４】
図３のステップＳ３７において、ＭＥ１はＵＩＭ２にメニュー選択のイベントが発生したことを表すＥｎｖｅｌｏｐｅコマンドを送信する。
【００４５】
ＵＩＭ２では、受信したＥｎｖｅｌｏｐｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行され、複数のＰｒｏａｃｔｉｖｅコマンド（Ｄｉｓｐｌａｙ Ｔｅｘｔ）が生成される。そして、ステップＳ３８において、ＭＥ１にＰｒｏａｃｔｉｖｅコマンドの送信要求を表す「９１ＸＸ」のステータスワードを送信する。
【００４６】
「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ３９において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、複数の表示文字情報のうち、ＭＥ１の動作環境に関する情報（表示機能＝５０文字）に
適合するように表示文字情報を選択する。例えば、表示文字情報（１）の情報量が２０文字、表示文字情報（２）の情報量が３０文字、表示文字情報（３）の情報量が３０文字であるときは、ＭＥ１の表示機能＝５０文字の条件に適合するように、表示文字情報（１）及び表示文字情報（２）が選択される。そして、ＵＩＭ２は、ステップＳ４０において、表示文字情報（１）及び表示文字情報（２）の情報を記録したＰｒｏａｃｔｉｖｅコマンドをＭＥ１に送信する。
【００４７】
Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した表示文字情報（１）及び表示文字情報（２）について情報表示処理を実行する。そして、ステップＳ４１において、ＭＥ１は情報表示処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。
【００４８】
ＵＩＭ２は、未送信のＰｒｏａｃｔｉｖｅコマンドが残っているかどうかを調べる。表示文字情報（３）が未送信である。従って、ステップＳ４２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。
【００４９】
「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ４３において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ＭＥ１の動作環境に関する情報（表示機能＝５０文字）に適合するように残っている表示文字情報を選択する。残っている表示文字情報（３）の情報量が３０文字であるため、ＭＥ１の表示機能＝５０文字の条件に適合する。そこでＵＩＭ２は、ステップＳ４４において、表示文字情報（３）の情報を記録したＰｒｏａｃｔｉｖｅコマンドをＭＥ１に送信する。
【００５０】
ステップＳ４５において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ４６において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。これ以降の処理は、Ａｐｐｌｅｔのプログラムに従う。
【００５１】
図６は、第１の実施の形態のＵＩＭ２におけるＦｅｔｃｈコマンド処理手順を示すフロー図である。
【００５２】
ステップＳ６１において、ＵＩＭ２は、ＭＥ１からのコマンドの受信を待機する。そして、コマンドを受信した場合は、ステップＳ６２において、受信したコマンドがＦｅｔｃｈコマンドかどうかを調べる。
【００５３】
受信したコマンドがＦｅｔｃｈコマンドでない場合（ステップＳ６２ ＮＯ）は、ステップＳ６３において、受信したコマンドに対応した処理を実行する。
【００５４】
受信したコマンドがＦｅｔｃｈコマンドである場合（ステップＳ６２ Ｙｅｓ）は、ステップＳ６４において、ＵＩＭ２は、Ｐｒｏａｃｔｉｖｅコマンドが準備されているかどうかを調べる。Ｐｒｏａｃｔｉｖｅコマンドが準備されていない場合（ステップＳ６４ ＮＯ）は、ステップＳ６５において、ＵＩＭ２は、エラー処理を実行する。
【００５５】
Ｐｒｏａｃｔｉｖｅコマンドが準備されている場合（ステップＳ６４ Ｙｅｓ）は、ステップＳ６６において、残っている最初のＰｒｏａｃｔｉｖｅコマンドをＭＥ１に対するレスポンスデータとして設定する。
【００５６】
ステップＳ６７において、ＵＩＭ２は、残っているＰｒｏａｃｔｉｖｅコマンドが複数あるかどうかを調べる。残っているＰｒｏａｃｔｉｖｅコマンドが１つの場合（ステップＳ６７ ＮＯ）は、ステップＳ７５において、ＵＩＭ２は、設定した１つのレスポンスデータをＭＥ１に送信する。
【００５７】
残っているＰｒｏａｃｔｉｖｅコマンドが複数の場合（ステップＳ６７ Ｙｅｓ）は、ステップＳ６９において、ＭＥ１の処理能力・動作環境に関する情報を、ＭＥ１から取得済みかどうかを調べる。ＭＥ１から情報を取得していない場合（ステップＳ６９ ＮＯ）は、ステップＳ７５において、ＵＩＭ２は、設定した１つのレスポンスデータをＭＥ１に送信する。この後、通常の送信方法と同様にして１個単位でＰｒｏａｃｔｉｖｅコマンドの送信が行われる。
【００５８】
ＭＥ１から情報を取得している場合（ステップＳ６９ Ｙｅｓ）は、ステップＳ７０において、変数パラメータｎ＝２を設定する。ステップＳ７１において、ＵＩＭ２は、１〜ｎ番目までのＰｒｏａｃｔｉｖｅコマンドを一括して処理可能かどうかを調べる。一括して処理可能でない場合（ステップＳ７１ ＮＯ）、ステップＳ７５において、ＵＩＭ２は、１〜（ｎ−１）番目までのレスポンスデータを１つのＰｒｏａｃｔｉｖｅコマンドにまとめてＭＥ１に送信する。
【００５９】
一括して処理可能である場合（ステップＳ７１ Ｙｅｓ）、ステップＳ７２において、ＵＩＭ２は、ｎ番目のＰｒｏａｃｔｉｖｅコマンドをレスポンスデータに追加して設定する。ステップＳ７３において、変数パラメータｎに１を加算（ｎ＝ｎ＋１）する。ステップＳ７４において、更にＰｒｏａｃｔｉｖｅコマンドが残っているかどうかを調べる。
【００６０】
次のＰｒｏａｃｔｉｖｅコマンドが残っていない場合（ステップＳ７４ ＮＯ）、ステップＳ７５において、ＵＩＭ２は、１〜（ｎ−１）番目までのレスポンスデータを一つのＰｒｏａｃｔｉｖｅコマンドにまとめてＭＥ１に送信する。次のＰｒｏａｃｔｉｖｅコマンドが残っている場合（ステップＳ７４ Ｙｅｓ）、ＵＩＭ２は、ステップＳ７１からの処理を実行する。
【００６１】
以上、説明した実施の形態によれば、一つのＰｒｏａｃｔｉｖｅコマンドに複数の送信データを含むことができるため、ＭＥ１は複数の処理をタイムラグを少なくして実行することができる。また、複数コマンドを取り扱う際、ＭＥ１の動作環境、処理能力等を考慮した上で複数のＰｒｏａｃｔｉｖｅコマンドをまとめて送出することができるため、処理手順の簡略化、高速化を図ることができる。
【００６２】
なお、上述の実施の形態ではＭＥ１の表示器の能力に応じてＰｒｏａｃｔｉｖｅコマンドをまとめて送出する例を説明したが、この実施例に限られず、音声装置の能力に応じてＰｒｏａｃｔｉｖｅコマンドをまとめて送出することができる。さらに、これらの例に限られず、ＭＥ１の処理能力などの情報をもとに適正な処理量を判断して一時に送信するＰｒｏａｃｔｉｖｅコマンドの量を決定する内容であれば、Ｐｒｏａｃｔｉｖｅコマンドの種類は問わない。
【００６３】
また、Ｐｒｏａｃｔｉｖｅコマンドの処理内容によって、まとめて送出することが適当でないと判断された場合は、ＵＩＭ２は、複数のＰｒｏａｃｔｉｖｅコマンドをまとめて送出することを行わないように構成することができる。
【００６４】
[第１の実施の形態のバリエーション]
第１の実施の形態のバリエーションでは、ＵＩＭ２は、Ｐｒｏａｃｔｉｖｅコマンドの実行順を指定することができる。
【００６５】
例えば、ＭＥ１が処理する複数のＰｒｏａｃｔｉｖｅコマンドについての実行順は、Ｐｒｏａｃｔｉｖｅコマンドデータの「Ｃｏｍｍａｎｄ Ｄｅｔａｉｌｓ」の「Ｖａｌｕｅ」ブロックにデータとして含めることができる。Ｐｒｏａｃｔｉｖｅコマンドの順序は実行順に配列されていても良く、実行順に配列されていなくても別に実行順が指定されていても良い。一方、実行順が指定されていない場合は、ＭＥ１が処理するＰｒｏａｃｔｉｖｅコマンドについての実行順は、適宜ＭＥ１が選択しても良い。
【００６６】
なお上述のＵＩＭ２は、ＩＣカードに組み込み、カードリーダライタとの間でデータの送受信を行なうように構成することができる。
図７は、本実施の形態のＵＩＭをＩＣカード１００に組み込んで構成した例について説明するためのブロック図である。
【００６７】
図７に示すように、ＩＣカード１００は、プラスチックなどで形成されたカード状の本体１０１と、本体１０１内に内蔵されたＩＣモジュール１０２とを備えている。ＩＣモジュール１０２は、１つ又は複数のＩＣチップ１０３と、通信Ｉ／Ｆ部２１とを備える。ＩＣチップ１０３と通信Ｉ／Ｆ部２１とは、互いに接続された状態でＩＣモジュール１０２内に埋設して形成されている。本実施の形態のＵＩＭはＩＣモジュール１０２として構成することができる。
【００６８】
尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００６９】
１…携帯電話端末、２…携帯可能電子装置、１１…制御部、１２…表示部、１４…通信部、１５…入力部、２１…通信インターフェース部、２２…制御部、２３…ＲＡＭ、２４…ＲＯＭ、２５…不揮発性メモリ、１００…ＩＣカード、１０１…本体、１０２…ＩＣモジュール、１０３…ＩＣチップ。
【技術分野】
【０００１】
本発明の実施の形態は、ＩＣカードに関する。
【背景技術】
【０００２】
海外の多くの国は携帯電話システム方式としてＧＳＭ（登録商標）（Global System for Mobile communications）方式を採用している。ＧＳＭ（登録商標）方式においては携帯電話機内にＩＣカードの一種であるＳＩＭ（Subscriber Identitiy Module）カードが必須となっている。
日本では、ＧＳＭ（登録商標）でなく、３ＧＰＰ（3rd Generation Partnership Project）規格を採用した携帯電話システムが立ちあがっている。３ＧＰＰ規格でもＳＩＭカードと同様なＩＣカード、ＵＳＩＭ（Universal Subscriber Identitiy Module）カードが必須となっている。
【０００３】
ＧＳＭ（登録商標）や３ＧＰＰで使用されているＳＩＭ、ＵＳＩＭは携帯電話端末内に挿入される。ＳＩＭ、ＵＳＩＭには通信事業者の通信ネットワークに接続するのに必要な鍵情報、暗号アルゴリズム、各種ネットワークパラメータが記録されている。携帯電話端末はそれらの情報を通信事業者のＯＴＡ（Over The Air）サーバ、認証・管理サーバ等に送信し、これらのサーバと認証を行い、認証結果が正しければ、通信事業者の通信サービスを受けることが可能となる。
【０００４】
非特許文献１乃至３には、ＣＡＴ（Ｃａｒｄ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ）と呼ばれる仕様を規定している。ＣＡＴは、ＩＣカードの中のＳＩＭ、ＵＳＩＭ、ＵＩＭ等に代表される携帯電話等の加入者情報を識別する為のカード（以下、ＵＩＭと呼ぶ）に実装される。このＣＡＴの仕様の一つに、ＵＩＭから携帯電話（以下、ＭＥと呼ぶ）、または、ネットワークサーバに対して、各種操作要求や情報送信を行う、Ｐｒｏａｃｔｉｖｅコマンドと呼ばれる機能が規定されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＥＴＳＩ ＴＳ １０２ ２２３
【非特許文献２】ＥＴＳＩ ＴＳ １０２ ２４１
【非特許文献３】ＥＴＳＩ ＴＳ １０２ ２２１
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記規格によると、ＵＩＭにおいて、ＴｏｏｌＫｉｔ Ａｐｐｌｅｔと呼ばれるＡｐｐｌｅｔ、もしくは、組込ソフトウエアが実行された場合、ＵＩＭではＰｒｏａｃｔｉｖｅコマンド送信要求が発生することがある。この時、ＵＩＭは、ＭＥから送信されるＦｅｔｃｈコマンドに対するレスポンスデータとして、Ｐｒｏａｃｔｉｖｅコマンドを送信する。その後、ＭＥは、受信したＰｒｏａｃｔｉｖｅコマンドに基づき処理を行い、その実行結果を示すため、Ｔｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅコマンドを出力する。
【０００７】
この時、現状の規格においては、１度に送信できるＰｒｏａｃｔｉｖｅコマンドは１つのＰｒｏａｃｔｉｖｅコマンドのみである。そのため、ＭＥに対して、ユーザからのキー入力要求と音出力要求の２つの要求を送信したい場合、２つのＰｒｏａｃｔｉｖｅコマンドを出力する必要がある。そのため、上記規格で規定される手順である、Ｆｅｔｃｈ→Ｔｅｒｍｉｎａｌ Ｒｅｓｐｏｎｓｅのコマンド送受信の手順を２度繰り返して実行する必要があり、実行処理が煩雑である。また、ユーザによるキー入力要求と音出力とをほぼ同時に実行させたい場合であっても、２つのＰｒｏａｃｔｉｖｅコマンドの送受信に長いタイムラグが生じるため所望の動作が行なわれない恐れがある。更に２つのＰｒｏａｃｔｉｖｅコマンドを所望の順序で実施させたい場合もある。
【０００８】
従って、ＵＩＭにおいてタイムラグを少なくしてＭＥに実行させたい複数のコマンドがある場合、これら複数のコマンドの送受信を効率的に実行でき、ＭＥがこれら複数のコマンドを少ないタイムラグで実行できる技術に対するニーズがある。
【課題を解決するための手段】
【０００９】
上記課題を解決するための本発明の実施の形態によれば、外部装置からのコマンド指示を解釈・実行し、その結果を応答するＩＣカードにおいて、前記外部装置の処理能力を表す情報を取得する能力情報取得部と、前記外部装置からの特定のコマンド指示に対して前記外部装置に特定の動作を求める要求コマンドを複数生成するコマンド生成部と、前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知する通知部と、前記外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドの内、前記外部装置の処理能力に応じた少なくとも一つの前記要求コマンドを一つの応答要求コマンドにまとめて前記外部装置に送出する送出部とを備えたＩＣカードが提供される。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態のＭＥとＵＩＭとの接続とそれぞれの構成ブロックとを示す図。
【図２】第１の実施の形態のＭＥとＵＩＭとの間での通常のコマンド授受手順を示す図。
【図３】第１の実施の形態のＭＥとＵＩＭとの間でのコマンド授受手順を示す図。
【図４】第１の実施の形態のＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドデータの構成を示す図。
【図５】第１の実施の形態のＵＩＭにおけるＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンド処理手順を示すフロー図。
【図６】第１の実施の形態のＵＩＭにおけるＦｅｔｃｈコマンド処理手順を示すフロー図。
【図７】本実施の形態のＵＩＭをＩＣカードに組み込んで構成した例について説明するためのブロック図。
【発明を実施するための形態】
【００１１】
以下、本実施の形態のＩＣカードを携帯可能電子機器であるＵＩＭとして説明する。また、ＩＣカードと情報を授受するＴｅｒｍｉｎａｌを携帯電話端末として説明する。
【００１２】
[第１の実施の形態]
図１は、本実施の形態の携帯電話端末（ＭＥ）１とＵＩＭ２との接続とそれぞれの構成ブロックとを示す図である。ＵＩＭ２は、携帯可能電子機器であり、ＭＥ１に装着されて携帯電話アプリ利用時のデータをハンドリングする。
【００１３】
ＭＥ１には、制御部１１、表示部１２、通信部１４及び入力部１５が設けられている。制御部１１は、ＭＥ１内の各部の動作を統括して制御する。表示部１２は、ユーザに対して情報を表示する。通信部１４は、ＵＩＭ２との間のデータ通信を実行する。入力部１５は、ユーザからの指示を入力する。
【００１４】
ＵＩＭ２は、通信インターフェース部２１、制御部２２、ＲＡＭ２３、ＲＯＭ２４、不揮発性メモリ２５を備えている。
【００１５】
通信インターフェース部２１は、ＭＥ１から送信されるデータを受信して制御部２２に出力する。また、通信インターフェース部２１は、制御部２２からデータを入力してＭＥ１に送信する。制御部２２は、演算、制御などを行い、ＵＩＭ２を統括して制御する。ＲＯＭ２４は、読み出し専用メモリである。ＲＯＭ２４には、オペレーティングシステム（ＯＳ）などの基本ソフトウエア、アプリケーション及びデータが格納されている。ＲＡＭ２３は、制御部２２の処理における作業領域として使用される。不揮発性メモリ２５は、ＥＥＰＲＯＭ、フラッシュメモリなどの書き換え可能な不揮発性のメモリであり、通常ユーザのワークエリア、プログラムエリアなどとして使用されている。後述のＡｐｐｌｅｔは、不揮発性メモリ２５に格納されている。
【００１６】
図２は、第１の実施の形態のＭＥ１とＵＩＭ２との間での通常のコマンド授受手順を示す図である。
【００１７】
ステップＳ０１において、ＭＥ１はＵＩＭ２にＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドを送信する。Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドには、ＭＥ１によってサポートされているＣＡＴ機能を表したリストがコンテンツとして含まれる。
【００１８】
ＵＩＭ２では、受信したＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際にＭＥ１に何らかの動作を起こさせる場合、例えば、ＭＥ１の表示部１２にユーザキー入力要求を表示する処理を実行させる場合は、ＭＥ１に対してキー入力要求画面表示を指定したＰｒｏａｃｔｉｖｅコマンドを送信することが必要である。そこでステップＳ０２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、Ｐｒｏａｃｔｉｖｅコマンドの送信要求を表す。即ち、ＵＩＭ２に送信すべきＰｒｏａｃｔｉｖｅコマンドがあるということを表している。
【００１９】
ＵＩＭ２から「９１ＸＸ」の応答コードが返されると、ＭＥ１はＵＩＭ２が長さ「ＸＸ」のデータを送出する準備ができたと判断し、ステップＳ０３において、ＦＥＴＣＨコマンドをＵＩＭ２に送信する。
【００２０】
ステップＳ０４において、ＵＩＭ２はＦＥＴＣＨコマンドに対して一個のＰｒｏａｃｔｉｖｅコマンド（例えば、Ｓｅｔ Ｕｐ Ｍｅｎｕコマンド）を送出する。Ｓｅｔ Ｕｐ Ｍｅｎｕコマンドは、ＭＥ１がＵＩＭ２に対して利用可能な機能についての情報を、ＵＩＭ２がＭＥ１に通知するためのコマンドである。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。
【００２１】
ステップＳ０５において、ＭＥ１は処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ０６において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。
【００２２】
続いて、ＭＥ１では、ユーザが例えば所望の操作を実行する。ステップＳ０７において、ＭＥ１はＵＩＭ２にＥｎｖｅｌｏｐｅコマンドを送信する。ここで、Ｅｎｖｅｌｏｐｅコマンドには、上述の規格において複数種類のフォーマットが規定されている。「Ｍｅｎｕ Ｓｅｌｅｃｔｉｏｎ」はこのフォーマットの１種類であり、ＭＥ１でメニューが選択されたというイベントが発生したことをＵＩＭ２に通知する内容である。
【００２３】
ＵＩＭ２では、受信したＥｎｖｅｌｏｐｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際にＭＥ１に何らかの動作を起こさせる場合、例えば、ＭＥ１の表示部１２に文字情報を表示する処理を実行させる場合は、ＭＥ１に対して表示文字情報を指定したＰｒｏａｃｔｉｖｅコマンドを送信することが必要である。そこでステップＳ０８において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、Ｐｒｏａｃｔｉｖｅコマンドの送信要求を表す。即ち、ＵＩＭ２に送信すべきＰｒｏａｃｔｉｖｅコマンドがあるということを表している。
【００２４】
「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ０９において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ステップＳ１０において、表示文字情報（１）を指定したＰｒｏａｃｔｉｖｅコマンドをＭＥ１に送信する。
【００２５】
Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した情報表示処理を実行する。そして、ステップＳ１１において、ＭＥ１は情報表示処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。
【００２６】
ＵＩＭ２は、未送信のＰｒｏａｃｔｉｖｅコマンドが残っているかどうかを調べる。
【００２７】
表示文字情報（２）及び表示文字情報（３）が未送信であるため、ステップＳ１２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。
【００２８】
ステップＳ１３〜Ｓ１８において、上述の手順を繰り返して、ＭＥ１とＵＩＭ２との間で、表示文字情報（２）及び表示文字情報（３）についての送受信が実行される。
【００２９】
ステップＳ１９において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ２０において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。これ以降の処理は、Ａｐｐｌｅｔのプログラムに従う。
【００３０】
上述のように、通常の手順ではＭＥ１がＵＩＭ２に対してＦｅｔｃｈコマンドを実行する毎に、ＵＩＭ２は内部に用意した複数のＰｒｏａｃｔｉｖｅコマンド（この例ではＤｉｓｐｌａｙ Ｔｅｘｔコマンド）を一個づつ送出する。
【００３１】
図３は、第１の実施の形態のＭＥ１とＵＩＭ２との間でのコマンド授受手順を示す図である。
【００３２】
ステップＳ３１において、ＭＥ１はＵＩＭ２にＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドを送信する。このＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドには、ＭＥ１の動作環境に関する情報、例えばＭＥ１の表示器に表示できるデータ容量などの情報が追加して含まれている。
【００３３】
図４は、第１の実施の形態のＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドデータの構成を示す図である。
Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドデータのコマンドパラメータには、「Ｄｅｓｃｒｉｐｔｉｏｎ」、「Ｃｌａｕｓｅ」、「Ｍ／Ｏ／Ｃ」、「Ｌｅｎｇｔｈ」の各ブロックが設けられている。「Ｄｅｓｃｒｉｐｔｉｏｎ」ブロックには、ＭＥ１によってサポートされているＣＡＴ機能を表したリストがコンテンツとして含まれる。
【００３４】
このコンテンツには、それぞれの機能ごとにＭＥ１によってサポートされているか否かのビット情報がバイトデータ（バイト単位）として記録されている。このバイトデータには、未使用領域であるＲＦＵ（Reserved For Future Use）ビットが設けられているものがある。また、複数のサブシークェント（Subsequent）バイトは、全てがＲＦＵビットで構成されている追加可能な未使用領域である。
【００３５】
従って、この未使用領域に上述の動作環境に関する情報を格納することができる。例えば、動作環境が表示機能の場合は、表示できる全文字数、表示できる文字の種類などを規定することができる。動作環境が音声機能の場合は、音声データの容量、音声方式などを規定することができる。
【００３６】
図３のステップＳ３２において、ＵＩＭ２では、受信したＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行される。この際、ＡｐｐｌｅｔはＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに記録されているＭＥ１の動作環境に関する情報（表示機能＝５０文字）を取得して保存する。そして、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。この「９１ＸＸ」のステータスワードは、上述のようにＰｒｏａｃｔｉｖｅコマンドの送信要求を表す。
【００３７】
ＵＩＭ２から「９１ＸＸ」の応答コードが返されると、ＭＥ１はＵＩＭ２が長さ「ＸＸ」のデータを送出する準備ができたと判断し、ステップＳ３３において、ＦＥＴＣＨコマンドをＵＩＭ２に送信する。
【００３８】
ステップＳ３４において、ＵＩＭ２はＦＥＴＣＨコマンドに対して一個のＰｒｏａｃｔｉｖｅコマンド（Ｓｅｔ Ｕｐ Ｍｕｎｅ）を送出する。Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した処理を実行する。
【００３９】
ステップＳ３５において、ＭＥ１は処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ３６において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。
【００４０】
図５は、第１の実施の形態のＵＩＭ２におけるＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンド処理手順を示すフロー図である。
【００４１】
ステップＳ５１において、ＵＩＭ２は、ＭＥ１からのコマンドの受信を待機する。そして、コマンドを受信した場合は、ステップＳ５２において、受信したコマンドがＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドかどうかを調べる。
【００４２】
受信したコマンドがＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドでない場合（ステップＳ５２ ＮＯ）は、ステップＳ５３において、受信したコマンドに対応した処理を実行する。
【００４３】
受信したコマンドがＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドである場合（ステップＳ５２ Ｙｅｓ）は、ステップＳ５４において、ＵＩＭ２は、コマンドデータ部にＭＥ１の処理能力・動作環境に関する情報があればその情報を保存する。ステップＳ５５において、ＵＩＭ２は、コマンドデータ部にあるその他の情報を保存する。そして、ステップＳ５６において、ＵＩＭ２は、Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドを受信済みのフラグを設定する。
【００４４】
図３のステップＳ３７において、ＭＥ１はＵＩＭ２にメニュー選択のイベントが発生したことを表すＥｎｖｅｌｏｐｅコマンドを送信する。
【００４５】
ＵＩＭ２では、受信したＥｎｖｅｌｏｐｅコマンドに対応したＡｐｐｌｅｔが起動し、Ａｐｐｌｅｔに記載されているプログラムが実行され、複数のＰｒｏａｃｔｉｖｅコマンド（Ｄｉｓｐｌａｙ Ｔｅｘｔ）が生成される。そして、ステップＳ３８において、ＭＥ１にＰｒｏａｃｔｉｖｅコマンドの送信要求を表す「９１ＸＸ」のステータスワードを送信する。
【００４６】
「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ３９において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、複数の表示文字情報のうち、ＭＥ１の動作環境に関する情報（表示機能＝５０文字）に
適合するように表示文字情報を選択する。例えば、表示文字情報（１）の情報量が２０文字、表示文字情報（２）の情報量が３０文字、表示文字情報（３）の情報量が３０文字であるときは、ＭＥ１の表示機能＝５０文字の条件に適合するように、表示文字情報（１）及び表示文字情報（２）が選択される。そして、ＵＩＭ２は、ステップＳ４０において、表示文字情報（１）及び表示文字情報（２）の情報を記録したＰｒｏａｃｔｉｖｅコマンドをＭＥ１に送信する。
【００４７】
Ｐｒｏａｃｔｉｖｅコマンドを受信したＭＥ１は、そのＰｒｏａｃｔｉｖｅコマンドに対応した表示文字情報（１）及び表示文字情報（２）について情報表示処理を実行する。そして、ステップＳ４１において、ＭＥ１は情報表示処理の実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。
【００４８】
ＵＩＭ２は、未送信のＰｒｏａｃｔｉｖｅコマンドが残っているかどうかを調べる。表示文字情報（３）が未送信である。従って、ステップＳ４２において、ＵＩＭ２は、ＭＥ１に「９１ＸＸ」のステータスワードを送信する。
【００４９】
「９１ＸＸ」のステータスワードを受信したＭＥ１は、ステップＳ４３において、ＵＩＭ２に対してＦｅｔｃｈコマンドを出力する。Ｆｅｔｃｈコマンドを受信したＵＩＭ２は、ＭＥ１の動作環境に関する情報（表示機能＝５０文字）に適合するように残っている表示文字情報を選択する。残っている表示文字情報（３）の情報量が３０文字であるため、ＭＥ１の表示機能＝５０文字の条件に適合する。そこでＵＩＭ２は、ステップＳ４４において、表示文字情報（３）の情報を記録したＰｒｏａｃｔｉｖｅコマンドをＭＥ１に送信する。
【００５０】
ステップＳ４５において、ＭＥ１は実行結果をＴｅｒｍｉｎａｌ ＲｅｓｐｏｎｓｅとしてＵＩＭ２に出力する。ステップＳ４６において、ＵＩＭ２は「９０００」のステータスワードを送信してＰｒｏａｃｔｉｖｅコマンドの送信を終了する。これ以降の処理は、Ａｐｐｌｅｔのプログラムに従う。
【００５１】
図６は、第１の実施の形態のＵＩＭ２におけるＦｅｔｃｈコマンド処理手順を示すフロー図である。
【００５２】
ステップＳ６１において、ＵＩＭ２は、ＭＥ１からのコマンドの受信を待機する。そして、コマンドを受信した場合は、ステップＳ６２において、受信したコマンドがＦｅｔｃｈコマンドかどうかを調べる。
【００５３】
受信したコマンドがＦｅｔｃｈコマンドでない場合（ステップＳ６２ ＮＯ）は、ステップＳ６３において、受信したコマンドに対応した処理を実行する。
【００５４】
受信したコマンドがＦｅｔｃｈコマンドである場合（ステップＳ６２ Ｙｅｓ）は、ステップＳ６４において、ＵＩＭ２は、Ｐｒｏａｃｔｉｖｅコマンドが準備されているかどうかを調べる。Ｐｒｏａｃｔｉｖｅコマンドが準備されていない場合（ステップＳ６４ ＮＯ）は、ステップＳ６５において、ＵＩＭ２は、エラー処理を実行する。
【００５５】
Ｐｒｏａｃｔｉｖｅコマンドが準備されている場合（ステップＳ６４ Ｙｅｓ）は、ステップＳ６６において、残っている最初のＰｒｏａｃｔｉｖｅコマンドをＭＥ１に対するレスポンスデータとして設定する。
【００５６】
ステップＳ６７において、ＵＩＭ２は、残っているＰｒｏａｃｔｉｖｅコマンドが複数あるかどうかを調べる。残っているＰｒｏａｃｔｉｖｅコマンドが１つの場合（ステップＳ６７ ＮＯ）は、ステップＳ７５において、ＵＩＭ２は、設定した１つのレスポンスデータをＭＥ１に送信する。
【００５７】
残っているＰｒｏａｃｔｉｖｅコマンドが複数の場合（ステップＳ６７ Ｙｅｓ）は、ステップＳ６９において、ＭＥ１の処理能力・動作環境に関する情報を、ＭＥ１から取得済みかどうかを調べる。ＭＥ１から情報を取得していない場合（ステップＳ６９ ＮＯ）は、ステップＳ７５において、ＵＩＭ２は、設定した１つのレスポンスデータをＭＥ１に送信する。この後、通常の送信方法と同様にして１個単位でＰｒｏａｃｔｉｖｅコマンドの送信が行われる。
【００５８】
ＭＥ１から情報を取得している場合（ステップＳ６９ Ｙｅｓ）は、ステップＳ７０において、変数パラメータｎ＝２を設定する。ステップＳ７１において、ＵＩＭ２は、１〜ｎ番目までのＰｒｏａｃｔｉｖｅコマンドを一括して処理可能かどうかを調べる。一括して処理可能でない場合（ステップＳ７１ ＮＯ）、ステップＳ７５において、ＵＩＭ２は、１〜（ｎ−１）番目までのレスポンスデータを１つのＰｒｏａｃｔｉｖｅコマンドにまとめてＭＥ１に送信する。
【００５９】
一括して処理可能である場合（ステップＳ７１ Ｙｅｓ）、ステップＳ７２において、ＵＩＭ２は、ｎ番目のＰｒｏａｃｔｉｖｅコマンドをレスポンスデータに追加して設定する。ステップＳ７３において、変数パラメータｎに１を加算（ｎ＝ｎ＋１）する。ステップＳ７４において、更にＰｒｏａｃｔｉｖｅコマンドが残っているかどうかを調べる。
【００６０】
次のＰｒｏａｃｔｉｖｅコマンドが残っていない場合（ステップＳ７４ ＮＯ）、ステップＳ７５において、ＵＩＭ２は、１〜（ｎ−１）番目までのレスポンスデータを一つのＰｒｏａｃｔｉｖｅコマンドにまとめてＭＥ１に送信する。次のＰｒｏａｃｔｉｖｅコマンドが残っている場合（ステップＳ７４ Ｙｅｓ）、ＵＩＭ２は、ステップＳ７１からの処理を実行する。
【００６１】
以上、説明した実施の形態によれば、一つのＰｒｏａｃｔｉｖｅコマンドに複数の送信データを含むことができるため、ＭＥ１は複数の処理をタイムラグを少なくして実行することができる。また、複数コマンドを取り扱う際、ＭＥ１の動作環境、処理能力等を考慮した上で複数のＰｒｏａｃｔｉｖｅコマンドをまとめて送出することができるため、処理手順の簡略化、高速化を図ることができる。
【００６２】
なお、上述の実施の形態ではＭＥ１の表示器の能力に応じてＰｒｏａｃｔｉｖｅコマンドをまとめて送出する例を説明したが、この実施例に限られず、音声装置の能力に応じてＰｒｏａｃｔｉｖｅコマンドをまとめて送出することができる。さらに、これらの例に限られず、ＭＥ１の処理能力などの情報をもとに適正な処理量を判断して一時に送信するＰｒｏａｃｔｉｖｅコマンドの量を決定する内容であれば、Ｐｒｏａｃｔｉｖｅコマンドの種類は問わない。
【００６３】
また、Ｐｒｏａｃｔｉｖｅコマンドの処理内容によって、まとめて送出することが適当でないと判断された場合は、ＵＩＭ２は、複数のＰｒｏａｃｔｉｖｅコマンドをまとめて送出することを行わないように構成することができる。
【００６４】
[第１の実施の形態のバリエーション]
第１の実施の形態のバリエーションでは、ＵＩＭ２は、Ｐｒｏａｃｔｉｖｅコマンドの実行順を指定することができる。
【００６５】
例えば、ＭＥ１が処理する複数のＰｒｏａｃｔｉｖｅコマンドについての実行順は、Ｐｒｏａｃｔｉｖｅコマンドデータの「Ｃｏｍｍａｎｄ Ｄｅｔａｉｌｓ」の「Ｖａｌｕｅ」ブロックにデータとして含めることができる。Ｐｒｏａｃｔｉｖｅコマンドの順序は実行順に配列されていても良く、実行順に配列されていなくても別に実行順が指定されていても良い。一方、実行順が指定されていない場合は、ＭＥ１が処理するＰｒｏａｃｔｉｖｅコマンドについての実行順は、適宜ＭＥ１が選択しても良い。
【００６６】
なお上述のＵＩＭ２は、ＩＣカードに組み込み、カードリーダライタとの間でデータの送受信を行なうように構成することができる。
図７は、本実施の形態のＵＩＭをＩＣカード１００に組み込んで構成した例について説明するためのブロック図である。
【００６７】
図７に示すように、ＩＣカード１００は、プラスチックなどで形成されたカード状の本体１０１と、本体１０１内に内蔵されたＩＣモジュール１０２とを備えている。ＩＣモジュール１０２は、１つ又は複数のＩＣチップ１０３と、通信Ｉ／Ｆ部２１とを備える。ＩＣチップ１０３と通信Ｉ／Ｆ部２１とは、互いに接続された状態でＩＣモジュール１０２内に埋設して形成されている。本実施の形態のＵＩＭはＩＣモジュール１０２として構成することができる。
【００６８】
尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００６９】
１…携帯電話端末、２…携帯可能電子装置、１１…制御部、１２…表示部、１４…通信部、１５…入力部、２１…通信インターフェース部、２２…制御部、２３…ＲＡＭ、２４…ＲＯＭ、２５…不揮発性メモリ、１００…ＩＣカード、１０１…本体、１０２…ＩＣモジュール、１０３…ＩＣチップ。
【特許請求の範囲】
【請求項１】
外部装置からのコマンド指示を解釈・実行し、その結果を応答するＩＣカードにおいて、
前記外部装置の処理能力を表す情報を取得する能力情報取得部と、
前記外部装置からの特定のコマンド指示に対して前記外部装置に特定の動作を求める要求コマンドを複数生成するコマンド生成部と、
前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知する通知部と、
前記外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドの内、前記外部装置の処理能力に応じた少なくとも一つの前記要求コマンドを一つの応答要求コマンドにまとめて前記外部装置に送出する送出部と
を備えたことを特徴とするＩＣカード。
【請求項２】
前記ＩＣカードはＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドをサポートし、
前記外部装置の処理能力を表す情報は、前記Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに含まれることを特徴とする請求項１に記載のＩＣカード。
【請求項３】
前記ＩＣカードは更にＰｒｏａｃｔｉｖｅコマンドをサポートし、
前記外部装置に送出する前記応答要求コマンドは、Ｐｒｏａｃｔｉｖｅコマンドであることを特徴とする請求項２に記載のＩＣカード。
【請求項４】
Ｐｒｏａｃｔｉｖｅコマンドには、前記複数の要求コマンドそれぞれの実行順を指定する情報が含まれることを特徴とする請求項３に記載のＩＣカード。
【請求項５】
請求項１乃至４の内いずれか１項に記載の各部を有するＩＣモジュールと、
このＩＣモジュールを収納したＩＣカード本体と
を備えたことを特徴とするＩＣカード。
【請求項１】
外部装置からのコマンド指示を解釈・実行し、その結果を応答するＩＣカードにおいて、
前記外部装置の処理能力を表す情報を取得する能力情報取得部と、
前記外部装置からの特定のコマンド指示に対して前記外部装置に特定の動作を求める要求コマンドを複数生成するコマンド生成部と、
前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知する通知部と、
前記外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドの内、前記外部装置の処理能力に応じた少なくとも一つの前記要求コマンドを一つの応答要求コマンドにまとめて前記外部装置に送出する送出部と
を備えたことを特徴とするＩＣカード。
【請求項２】
前記ＩＣカードはＴｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドをサポートし、
前記外部装置の処理能力を表す情報は、前記Ｔｅｒｍｉｎａｌ Ｐｒｏｆｉｌｅコマンドに含まれることを特徴とする請求項１に記載のＩＣカード。
【請求項３】
前記ＩＣカードは更にＰｒｏａｃｔｉｖｅコマンドをサポートし、
前記外部装置に送出する前記応答要求コマンドは、Ｐｒｏａｃｔｉｖｅコマンドであることを特徴とする請求項２に記載のＩＣカード。
【請求項４】
Ｐｒｏａｃｔｉｖｅコマンドには、前記複数の要求コマンドそれぞれの実行順を指定する情報が含まれることを特徴とする請求項３に記載のＩＣカード。
【請求項５】
請求項１乃至４の内いずれか１項に記載の各部を有するＩＣモジュールと、
このＩＣモジュールを収納したＩＣカード本体と
を備えたことを特徴とするＩＣカード。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−７０１４０（Ｐ２０１３−７０１４０Ａ）
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願番号】特願２０１１−２０５８１７（Ｐ２０１１−２０５８１７）
【出願日】平成２３年９月２１日（２０１１．９．２１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願日】平成２３年９月２１日（２０１１．９．２１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]