説明

携帯可能電子機器及びICカード

【課題】 UIMにおいてタイムラグを少なくしてMEに実行させたい複数のコマンドがある場合、これら複数のコマンドの送受信を効率的に実行でき、MEがこれら複数のコマンドを少ないタイムラグで実行する。
【解決手段】 外部1からのコマンド指示を解釈・実行し、その結果を応答する携帯可能電子装置2であって、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを複数生成するコマンド生成部と、前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドを一つの応答要求コマンドにまとめて前記外部に通知する通知部と、複数の前記要求コマンドそれぞれの前記外部における実行結果をまとめた一つの応答結果コマンドを前記外部から取得する取得部とを備えた携帯可能電子装置である。

【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施の形態は、携帯可能電子機器及びICカードに関する。
【背景技術】
【0002】
海外の多くの国は携帯電話システム方式としてGSM(登録商標)(Global System for Mobile communications)方式を採用している。GSM(登録商標)方式においては携帯電話機内にICカードの一種であるSIM(Subscriber Identitiy Module)カードが必須となっている。
日本では、GSM(登録商標)でなく、3GPP(3rd Generation Partnership Project)規格を採用した携帯電話システムが立ちあがっている。3GPP規格でもSIMカードと同様なICカード、USIM(Universal Subscriber Identitiy Module)カードが必須となっている。
【0003】
GSM(登録商標)や3GPPで使用されているSIM、USIMは携帯電話端末内に挿入される。SIM、USIMには通信事業者の通信ネットワークに接続するのに必要な鍵情報、暗号アルゴリズム、各種ネットワークパラメータが記録されている。携帯電話端末はそれらの情報を通信事業者のOTA(Over The Air)サーバ、認証・管理サーバ等に送信し、これらのサーバと認証を行い、認証結果が正しければ、通信事業者の通信サービスを受けることが可能となる。
【0004】
非特許文献1、2には、CAT(Card Application Toolkit)と呼ばれる仕様を規定している。CATは、ICカードの中のSIM、USIM、UIM等に代表される携帯電話等の加入者情報を識別する為のカード(以下、UIMと呼ぶ)に実装される。このCATの仕様の一つに、UIMから携帯電話(以下、MEと呼ぶ)、または、ネットワークサーバに対して、各種操作要求や情報送信を行う、Proactiveコマンドと呼ばれる機能が規定されている。
【先行技術文献】
【非特許文献】
【0005】
【非特許文献1】ETSI TS 102 223
【非特許文献2】ETSI TS 102 241
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記規格によると、UIMにおいて、ToolKit Appletと呼ばれるApplet、もしくは、組込ソフトウエアが実行された場合、UIMではProactiveコマンド送信要求が発生することがある。この時、UIMは、MEから送信されるFetchコマンドに対するレスポンスデータとして、Proactiveコマンドを送信する。その後、MEは、受信したProactiveコマンドに基づき処理を行い、その実行結果を示すため、Terminal Responseコマンドを出力する。
【0007】
この時、現状の規格においては、1度に送信できるProactiveコマンドは1つのProactiveコマンドのみである。そのため、MEに対して、ユーザからのキー入力要求と音出力要求の2つの要求を送信したい場合、2つのProactiveコマンドを出力する必要がある。そのため、上記規格で規定される手順である、Fetch→Terminal Responseのコマンド送受信の手順を2度繰り返して実行する必要があり、実行処理が煩雑である。また、ユーザによるキー入力要求と音出力とをほぼ同時に実行させたい場合であっても、2つのProactiveコマンドの送受信に長いタイムラグが生じるため所望の動作が行なわれない恐れがある。更に2つのProactiveコマンドを所望の順序で実施させたい場合もある。
【0008】
従って、UIMにおいてタイムラグを少なくしてMEに実行させたい複数のコマンドがある場合、これら複数のコマンドの送受信を効率的に実行でき、MEがこれら複数のコマンドを少ないタイムラグで実行できる技術に対するニーズがある。
【課題を解決するための手段】
【0009】
上記課題を解決するための本発明の実施の形態によれば、外部からのコマンド指示を解釈・実行し、その結果を応答する携帯可能電子装置であって、外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを複数生成するコマンド生成部と、前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドを一つの応答要求コマンドにまとめて前記外部に通知する通知部と、複数の前記要求コマンドそれぞれの前記外部における実行結果をまとめた一つの応答結果コマンドを前記外部から取得する取得部とを備えた携帯可能電子装置が提供される。
【図面の簡単な説明】
【0010】
【図1】第1の実施の形態のMEとUIMとの接続とそれぞれの構成ブロックとを示す図。
【図2】第1の実施の形態のMEとUIMとの間での通常のコマンド授受手順を示す図。
【図3】第1の実施の形態のMEとUIMとの間での複数コマンド授受手順を示す図。
【図4】第1の実施の形態の通信手順を実現するためのUIMの処理手順を示すフロー図。
【図5】第1の実施の形態の通常のコマンド授受手順におけるProactiveコマンドデータフォーマットを示す図。
【図6】第1の実施の形態の複数コマンド授受手順におけるProactiveコマンドデータフォーマットを示す図。
【図7】第1の実施の形態の通常のコマンド授受手順におけるTerminal Responseデータフォーマットを示す図。
【図8】第1の実施の形態の複数コマンド授受手順におけるTerminal Responseデータフォーマットを示す図。
【図9】バリエーションの形態のMEとUIMとの間での複数コマンド授受手順を示す図。
【図10】本実施の形態のUIMをICカードに組み込んで構成した例について説明するためのブロック図。
【発明を実施するための形態】
【0011】
[第1の実施の形態]
図1は、本実施の形態の携帯電話端末(ME)1とUIM2との接続とそれぞれの構成ブロックとを示す図である。UIM2は、形態可能電子機器であり、ME1に装着されて携帯電話アプリ利用時のデータをハンドリングする。
【0012】
ME1には、制御部11、表示部12、通信部14及び入力部15が設けられている。制御部11は、ME1内の各部の動作を統括して制御する。表示部12は、ユーザに対して情報を表示する。通信部14は、UIM2との間のデータ通信を実行する。入力部15は、ユーザからの指示を入力する。
【0013】
UIM2は、通信インターフェース部21、制御部22、RAM23、ROM24、不揮発性メモリ25を備えている。
【0014】
通信インターフェース部21は、ME1から送信されるデータを受信して制御部22に出力する。制御部22は、演算、制御などを行い、UIM2を統括して制御する。ROM24は、読み出し専用メモリである。ROM24には、オペレーティングシステム(OS)などの基本ソフトウエア、アプリケーション及びデータが格納されている。RAM23は、制御部22の処理における作業領域として使用される。不揮発性メモリ25は、EEPROM、フラッシュメモリなどの書き換え可能な不揮発性のメモリであり、通常ユーザのワークエリア、プログラムエリアなどとして使用されている。後述のAppletは、不揮発性メモリ25に格納されている。
【0015】
図2は、第1の実施の形態のME1とUIM2との間での通常のコマンド授受手順を示す図である。
【0016】
ステップS01において、ME1はUIM2にEnvelopeコマンドを送信する。ここで、Envelopeコマンドには、上述の規格において複数種類のフォーマットが規定されている。例えば、Eventdownloadはこのフォーマットの1種類であり、ME1で所定のイベントが発生したことをUIM2に通知する内容である。
【0017】
UIM2では、受信したEnvelopeコマンドに対応したAppletが起動し、Appletに記載されているプログラムが実行される。この際にME1に何らかの動作を起こさせる場合、例えば、ME1の表示部12にユーザキー入力要求を表示する処理を実行させる場合は、ME1に対してキー入力要求画面表示を指定したProactiveコマンドを送信することが必要である。そこでステップS02において、UIM2は、ME1に「91XX」のステータスワードを送信する。この「91XX」のステータスワードは、Proactiveコマンドの送信要求を表す。即ち、UIM2に送信すべきProactiveコマンドがあるということを表している。
【0018】
「91XX」のステータスワードを受信したME1は、ステップS03において、UIM2に対してFetchコマンドを出力する。Fetchコマンドを受信したUIM2は、ステップS04において、キー入力要求画面表示を指定したProactiveコマンドと「9000」のステータスワードをME1に送信する。Proactiveコマンドを受信したME1は、そのProactiveコマンドに対応した画面表示処理を実行する。
【0019】
ステップS05において、ME1は実行結果をTerminal ResponseとしてUIM2に出力する。例えば、実行完了した、あるいはユーザが他の操作を実行中により実行できない、またはエラーが発生して実行を中止したなどの応答を返送する。UIM2のAppletは、応答結果を確認し、その後、後続の処理を実行して、例えば、音を出力させるProactiveコマンドを生成する。ステップS06において、UIM2は、音声出力を指定したProactiveコマンドの送信要求として、ME1に対し、「91YY」のステータスワードを送信する。
【0020】
ME1は、「91YY」のステータスワードにより、UIM2内にProactiveコマンドが蓄積されていると判断し、それを取得するため、ステップS07において、Fetchコマンドを送信する。UIM2は、Fetchコマンドを受信し、その応答として、ステップS08において、音声出力を指定したProactiveコマンドと「9000」のステータスワードをME1に送信する。Proactiveコマンドを受信したME1は、そのProactiveコマンドに対応した音声出力処理を実行する。
【0021】
ステップS09において、ME1は実行結果をTerminal ResponseとしてUIM2に出力する。ステップS10において、UIM2は「9000」のステータスワードを送信してProactiveコマンドの送信を終了する。これ以降の処理は、Appletのプログラムに従う。
【0022】
図3は、第1の実施の形態のME1とUIM2との間での複数コマンド授受手順を示す図である。図4は、第1の実施の形態の通信手順を実現するためのUIM2の処理手順を示すフロー図である。以下では、UIM2において、ME1に送信しようとするProactiveコマンドがApplet処理において一時に複数発生した場合の通信手順について図3及び図4を参照しつつ説明する。
【0023】
ステップS11において、ME1はUIM2にEnvelopeコマンドを送信する。UIM2では、受信したEnvelopeコマンドに対応したAppletが起動し、Appletに記載されているプログラムが実行される。この際に、例えば、ME1の表示部12にキー入力要求画面を表示する処理と、更に音声を出力する処理を少ないタイムラグで実行させる場合は、ME1に対して画面表示を指定したProactiveコマンド1と音声出力を指定したProactiveコマンド2を送信することが必要である。そこでステップS12において、UIM2は、ME1に「91ZZ」のステータスワードを送信する。この「91ZZ」のステータスワードについての詳細は後述するが、UIM2に送信すべきProactiveコマンドがあるということを表している。
【0024】
「91ZZ」のステータスワードを受信したME1は、ステップS13において、UIM2に対してFetchコマンドを出力する。Fetchコマンドを受信したUIM2は、ステップS14において、画面表示を指定したProactiveコマンド1、音声出力を指定したProactiveコマンド2及び「9000」のステータスワードをME1に送信する。
【0025】
図5は、第1の実施の形態の通常のコマンド授受手順におけるProactiveコマンドデータフォーマットを示す図である。図5(1)はProactiveコマンド1のデータフォーマットを示し、図5(2)はProactiveコマンド2のデータフォーマットを示す。
【0026】
Proactiveコマンドデータは、「Tag」、「Length」、「Value」の各ブロックを含んでいる。「Tag」はコマンドの種類を表す。「Length」は「Value」ブロックの長さを表す。「Value」はデータの内容を表す。
そして「Value」ブロックには、例えば「Command Details」、「Device Identities」、「Text String」などのブロックが更に含まれ、それぞれのブロックはデータとして「Tag」、「Length」、「Value」を含んでいる。
【0027】
図5に示す各ブロックのデータはHexa(16進)表示で表される。即ち、Proactiveコマンド1の「Value」ブロックの長さ(Length)は、Hexaで14バイト即ち10進表示で20バイトである。またProactiveコマンド2の「Value」ブロックの長さ(Length)は、Hexaで09バイト即ち10進表示で09バイトである。
【0028】
なお、図2のステップS02及びS06でUIM2からME1に送信されるステータスワード「91XX」及び「91YY」の「XX」、「YY」はそれぞれ送信するProactiveコマンド1,2の長さを表している。
【0029】
図6は、第1の実施の形態の複数コマンド授受手順におけるProactiveコマンドデータフォーマットを示す図である。
【0030】
複数コマンド授受手順においてUIM2からME1に送信されるデータフォーマットは、図5に示すProactiveコマンド1のデータフォーマットとProactiveコマンド2のデータフォーマットとが連結して構成されている。
【0031】
なお、図3のステップS12でUIM2からME1に送信されるステータスワード「91ZZ」の「ZZ」は、上述の「XX」と「YY」とを加算した値である。
【0032】
Proactiveコマンドデータを受信したME1は、そのコマンドデータからProactiveコマンド1,2を抽出する。ME1は、図6に示す「Length」ブロックを参照することでProactiveコマンド1,2を識別して抽出することができる。
【0033】
ME1は、Proactiveコマンド1に従ったキー入力要求画面表示処理と、Proactiveコマンド2に従った音声出力処理を実行する。
ステップS15において、ME1はProactiveコマンド1,2に従った実行結果をTerminal ResponseとしてUIM2に出力する。
【0034】
図7は、第1の実施の形態の通常のコマンド授受手順におけるTerminal Responseデータフォーマットを示す図である。図7(1)はProactiveコマンド1に対応するTerminal Response1のデータフォーマットを示し、図7(2)はProactiveコマンド2に対応するTerminal Response2のデータフォーマットを示す。
【0035】
Terminal Responseデータは、「Tag」、「Length」、「Value」の各ブロックを含んでいる。「Tag」はコマンドの種類を表す。「Length」は「Value」ブロックの長さを表す。「Value」はデータの内容を表す。これらのブロックのフォーマットは、Proactiveコマンドデータのブロックのフォーマットと同様の構成であるため、その詳細の説明は省略する。
【0036】
図8は、第1の実施の形態の複数コマンド授受手順におけるTerminal Responseデータフォーマットを示す図である。
【0037】
複数コマンド授受手順においてME1からUIM2に送信されるTerminal Responseデータフォーマットは、図7示すTerminal Response1のデータフォーマットとTerminal Response2のデータフォーマットとが連結して構成されている。
【0038】
UIM2は、Terminal Responseデータの内容を解析し、実行結果を確認する。ステップS16において、UIM2は「9000」のステータスワードを送信してProactiveコマンドの送信を終了する。これ以降の処理は、Appletのプログラムに従う。
【0039】
なお、ME1が処理するProactiveコマンド1,2についての実行順は、Proactiveコマンドデータの「Command Details」の「Value」ブロックにデータとして含めることができる。したがって、Proactiveコマンドの送信順序は実行順に配列されていても良く、配列されていなくても良い。一方、実行順が指定されていない場合は、ME1が処理するProactiveコマンド1,2についての実行順は、適宜ME1が選択しても良い。
【0040】
また、ME1が送信するTerminal Responseデータの「Command Details」の「Value」ブロックに実行順をデータとして含めることができる。したがって、この場合は、Terminal Responseデータは実行順に配列されていなくても良い。一方、ME1はTerminal Responseデータを実行順に配列して送信しても良い。
【0041】
[第1の実施の形態のバリエーション]
第1の実施の形態のバリエーションでは、ME1がUIM2に対して送信するTerminal Responseデータの通信手順が第1の実施の形態と異なっている。第1の実施の形態と同一の部位には同一の符号を付してその詳細の説明は省略する。
【0042】
図9は、バリエーションの形態のME1とUIM2との間での複数コマンド授受手順を示す図である。
ステップS21〜ステップS24は、図3において説明したステップS11〜ステップS14を同じであるため、その詳細の説明は省略する。
【0043】
Proactiveコマンドデータを受信したME1は、そのコマンドデータからProactiveコマンド1,2を抽出する。そして、ME1は、Proactiveコマンド1に従ったキー入力要求画面表示処理を実行する。ステップS25において、ME1はProactiveコマンド1に従った実行結果をTerminal Response1としてUIM2に出力する。UIM2は、Terminal Response1データの内容を解析し、実行結果を確認する。
【0044】
その後、ステップS30において、UIM2は「9000」のステータスワードを送信してProactiveコマンド1の送信を終了し、Proactiveコマンド2の実行結果を待つ。
【0045】
ME1は、Proactiveコマンド1に従った処理の後、Proactiveコマンド2に従った音声出力処理を実行する。ステップS26において、ME1はProactiveコマンド2に従った実行結果をTerminal Response2としてUIM2に出力する。UIM2は、Terminal Response2データの内容を解析し、実行結果を確認する。
【0046】
その後、ステップS27において、UIM2は「9000」のステータスワードを送信してProactiveコマンドの送信を終了する。これ以降の処理は、Appletのプログラムに従う。
【0047】
なお、ME1が処理するProactiveコマンド1,2についての実行順は、Proactiveコマンドデータの「Command Details」の「Value」ブロックにデータとして含めることができる。したがって、Proactiveコマンドの順序は実行順に配列されていても良く、配列されていなくても良い。一方、実行順が指定されていない場合は、ME1が処理するProactiveコマンド1,2についての実行順は、適宜ME1が選択しても良い。
【0048】
ME1からのTerminal Responseデータは実行順に送信されるため、UIM2は、Terminal Responseデータの実行順を容易に把握することができる。
【0049】
なお、上述の各実施の形態で述べた送信手順では、2つのProactiveコマンドを取り扱ったが、2個以上のProactiveコマンドを取り扱うことも可能である。1度の送信に含めることのできるコマンド数(データ長)は、通信規約あるいは製品のスペックによって最大データ長が定められている。従って、この範囲内において、複数のコマンド数を1つの送信データとすることができる。
【0050】
以上、説明した実施の形態によれば、一つの送信データに複数のProactiveコマンドを含むことができるため、ME1は複数の処理をタイムラグを少なくして実行することができる。また、複数コマンドを取り扱う際、ME1が処理する実行順を指定することができ、さらにME1が処理した実行順を容易に把握することができる。さらに、ME1とUIM2との間のコマンドレスポンスのやり取りを短縮化することができる。
【0051】
なお上述のUIM2は、ICカードに組み込み、カードリーダライタとの間でデータの送受信を行なうように構成することができる。
図10は、本実施の形態のUIMをICカード100に組み込んで構成した例について説明するためのブロック図である。
【0052】
図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として構成することができる。
【0053】
尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【0054】
1…携帯電話端末、2…携帯可能電子装置、11…制御部、12…表示部、14…通信部、15…入力部、21…通信インターフェース部、22…制御部、23…RAM、24…ROM、25…不揮発性メモリ、100…ICカード、101…本体、102…ICモジュール、103…ICチップ。

【特許請求の範囲】
【請求項1】
外部からのコマンド指示を解釈・実行し、その結果を応答する携帯可能電子装置において、
外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを複数生成するコマンド生成部と、
前記特定のコマンド指示に対する応答の際、前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドを一つの応答要求コマンドにまとめて前記外部に通知する通知部と、
複数の前記要求コマンドそれぞれの前記外部における実行結果をまとめた一つの応答結果コマンドを前記外部から取得する取得部と
を備えたことを特徴とする携帯可能電子装置。
【請求項2】
前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順を指定する情報が含まれ、
前記応答結果コマンドには、前記複数の要求コマンドそれぞれを実行した順序を表す情報が含まれること
を特徴とする請求項1に記載の携帯可能電子装置。
【請求項3】
前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順が配列順によって指定され、
前記応答結果コマンドには、前記複数の要求コマンドそれぞれを実行した順序が配列順として表されること
を特徴とする請求項1に記載の携帯可能電子装置。
【請求項4】
外部からのコマンド指示を解釈・実行し、その結果を応答する携帯可能電子装置において、
外部からの特定のコマンド指示に対して外部に対して特定の動作を求める要求コマンドを複数生成するコマンド生成部と、
前記特定のコマンド指示に対する応答の際前記要求コマンドの発生を外部に通知し、外部から前記要求コマンドの取り出しを指示された際、生成した複数の前記要求コマンドを一つの応答要求コマンドにまとめて前記外部に通知する通知部と、
前記外部における前記要求コマンドの実行結果を表す応答結果コマンドを複数の前記要求コマンドそれぞれについて前記外部から取得する取得部と
を備えたことを特徴とする携帯可能電子装置。
【請求項5】
前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順を指定する情報が含まれ、
それぞれの前記応答結果コマンドには、前記要求コマンドそれぞれを実行した順序を表す情報が含まれること
を特徴とする請求項4に記載の携帯可能電子装置。
【請求項6】
前記応答要求コマンドには、前記複数の要求コマンドそれぞれの実行順が配列順によって指定され、
前記取得部は、前記複数の要求コマンドが実行された順に対応する前記応答結果コマンドを取得すること
を特徴とする請求項4に記載の携帯可能電子装置。
【請求項7】
請求項1乃至6の内いずれか1項に記載の各部を有するICモジュールと、
このICモジュールを収納したICカード本体と
を備えたことを特徴とするICカード。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate


【公開番号】特開2012−198812(P2012−198812A)
【公開日】平成24年10月18日(2012.10.18)
【国際特許分類】
【出願番号】特願2011−63287(P2011−63287)
【出願日】平成23年3月22日(2011.3.22)
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】