JP2006202286A - 識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法及び装置 - Google Patents

Abstract

【課題】識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法及び装置を提供する。
【解決手段】アプリケーションから識別モジュールに保存された所定レコードの入出力に対する要請を受信する段階、識別モジュールでの要請されたレコードのメタデータと入出力要請とを識別モジュールに送信する段階、及び識別モジュールから入出力要請に対応する結果を受信して、アプリケーションに送信する段階を含む識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
【選択図】図６

Description

本発明は、識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法及び装置に関する。

ＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）またはＳＩＭカードは、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）またはＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）端末機に挿入される一種のスマートカードであって、ネットワーク情報、ローミング情報、電話番号、料金内訳などの加入者情報とユーザ認証、データ暗号化などの保安情報とが内蔵されたカードである。このカードと携帯電話などの端末機が結合されて通信がなされる。ヨーロッパでは、ＧＳＭからＵＭＴＳにサービスを移転しており、北米地域も次世代ＣＤＭＡを導入中である。前述したＵＳＩＭまたはＳＩＭカードは、通信に必要な情報と端末機とを分離して、誰でもＵＳＩＭカードだけ有していれば、どんな端末機を通じても通信がなされる。

ＳＩＭカードは、データをファイルとして保存し、情報を階層的に管理するためにディレクトリ下にファイルが位置する。このようなファイルの経路を探すためにアプリケーションは、ＳＩＭカードに対して検索手続きを要求しており、ディレクトリの深さによって検索手続きを反復的に行う。

また、ＳＩＭクライアント（端末機）がＳＩＭサーバー（ＳＩＭデバイス）に比べて性能がはるかに高い一方、ＳＩＭサーバーは、１つの命令に対して処理を完了し、その応答を伝送するシングルウィンドウ方式でＳＩＭサーバー、すなわち、ＳＩＭカードでのデータ処理方式がシステムの速度を低下させる要因となる。

図１は、従来のＵＩＭ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅ）ソフトウェアの構造を示す例示図である。ＵＩＭ応用プログラム１０は、ＵＩＭカード１００に保存されたデータを読出し／書込みするために、ＵＩＭタスク５０に命令語を伝送し、命令に対する結果を受信する。ＵＩＭ適応階層８０は、ＵＩＭタスク５０が伝送する命令語をＵＩＭデバイスドライバー９０との相互作用で処理する。そして、その結果をＵＩＭタスクに伝送する。ところで、ＵＩＭタスクに伝送する方式が、シングルウィンドウ方式である。シングルウィンドウ方式とは、ＵＩＭタスクが１つの命令語を送れば、ＵＩＭ適応階層８０を経てＵＩＭデバイスドライバー９０に伝送され、ＵＩＭデバイスドライバー９０は、その命令語の処理結果をＵＩＭタスクに送信する。このような一連の手続きが終わるまで、ＵＩＭタスク５０は次の命令語をＵＩＭデバイスドライバー９０に送信できないということを意味する。したがって、複数回の命令実行が必要である場合、一回ずつ応答を受けた後に命令語を伝送する。これは、システムの性能を落とす要因となる。特に、ＳＩＭ関連サービスを提供するサーバー８０、９０、１００側は、通常８／１６ｂｉｔ級の低速デバイスでクライアントより性能が非常に落ちるという点で性能全体の低下に連結される。

図２は、従来のＳＩＭカード内にデータが保存される方式を示す構造図である。

ＳＩＭカードでデータはＥＦ（Ｅｌｅｍｅｎｔ Ｆｉｌｅ）というファイル形態に保存され、ＭＦ、ＤＦ、ＡＤＦというファイル経路を有する。ＭＦ（Ｍａｓｔｅｒ Ｆｉｌｅ）は、ルートディレクトリと類似しており、ＤＦ（Ｄｅｄｉｃａｔｅｄ Ｆｉｌｅ）は、サブディレクトリの意味を有する。ＡＤＦ（Ａｐｐｌｃａｔｉｏｎ ＤＦ）は、応用プログラムのディレクトリを示す。ＳＩＭ規格は、ＭＦ、ＤＦ、ＡＤＦディレクトリの構造を定義しており、ユーザは、ディレクトリ構造を変えることはできない。ＳＩＭカードのデータは、エッジノードであるＥＦに保存され、ディレクトリ経路であるＭＦ、ＤＦ、ＡＤＦは、経路以外に他の情報を持たない。

したがって、あるデータを読出し／書込みするには、まずＥＦが位置した経路全体をＭＦ、ＤＦ、ＡＤＦ、ＥＦ順に探した後、該当ＥＦファイルにデータを読出し／書込みせねばならない。

図３は、ＳＩＭデータを構成するファイル構造体を示す例示図である。

ファイル構造体は、ヘッダとボディーで構成され、ボディーにデータが保存される。ボディーを構成する方式で（ａ）、（ｂ）、（ｃ）がある。まず、（ａ）は、透明ＥＦ（Ｔｒａｎｓｐａｒｅｎｔ ＥＦ）で１つのブロックデータに保存される方式がある。短文メッセージ（Ｓｈｏｒｔ Ｍｅｓｓａｇｉｎｇ Ｓｙｓｔｅｍ：ＳＭＳ）文字のように一連のビットストリームを保存するのに使われる。（ｂ）は、順次的固定ＥＦ（Ｌｉｎｅａｒ Ｆｉｘｅｄ ＥＦ）で、一連のレコードが順次に保存された方式である。（ｃ）は、環状ＥＦ（Ｃｙｃｌｉｃ ＥＦ）で一連のレコードが順次に保存され、最後のレコードが開始レコードを示す環状データ構造体である。

図４は、従来のＵＩＭモジュールでデータを読出す順序図である。応用プログラムのアプリケーション１０が特定サービスの情報を要請する（Ｓ１０１）。ＵＩＭタスク５０は、このサービスの情報を得るために、一連の作業を行う。まず、デバイスドライバー９０にＭＦを選択する命令語を伝送する（Ｓ１０２）。これはあらゆる情報が、ＭＦ／ＤＦ１／ＤＦ２／ＥＦのようにＭＦを基準にその下位に存在するからである。これに対する応答として、デバイスドライバー９０は、ＭＦの位置情報と、ＭＦを構成する下位ディレクトリについての情報を伝送する（Ｓ１０３）。受信した情報に基づいてＵＩＭタスク５０は、最初ＤＦを選択する（Ｓ１０４）。そして、デバイスドライバー９０は、最初ＤＦを構成する情報を伝送する（Ｓ１０５）。この情報に基づいて２番目のＤＦを選択する（Ｓ１０６）。やはりデバイスドライバー９０は、２番目のＤＦについての情報を伝送する（Ｓ１０７）。ＵＩＭタスクは、所望のサービスのある特定ＥＦを選択する（Ｓ１０８）。デバイスドライバー９０は、このＥＦを構成するデータについての情報を伝送する（Ｓ１１１）。ここで、どんなレコードを読むかを選択し、ＥＦとレコードについての情報を伝送する（Ｓ１１０）。そして、デバイスドライバーは、これに対する応答としてレコード情報を伝送する（Ｓ１１１）。そして、このような過程は読出そうとするレコードの情報をいずれも得るまで、反復される。

図４から分かるように、１つのデータを読出すためにＥＦの位置を探すのに４回のアクセスが必要である。１つのデータを読出す作業が頻繁になる場合、位置の検索のために使う命令語はオーバーヘッドになりうる。そして、このようなシングルウィンドウ方式は、ボットルネック現象を招く。

したがって、データが位置したファイルの経路と関係なくファイルの位置を検索し、検索されたファイルの経路を管理する方法及び装置が必要である。
特開平9-289524号公報

本発明の技術的課題は、端末機と識別モジュールとの間のデータ処理速度を向上させるところにある。

本発明の他の技術的課題は、識別モジュールにレコードの情報を保存して処理速度を向上させるところにある。

本発明の目的は、以上で言及した目的に制限されず、言及されていない他の目的は以下の記載から当業者に明確に理解されうる。

識別モジュールにレコードの情報を保存し、処理速度を向上させる方法及び装置に関する。

本発明の一実施形態による識別モジュールのレコード情報を保存して、データ処理速度を向上させる方法は、アプリケーションから識別モジュールに保存された所定レコードの入出力に対する要請を受信する段階、前記識別モジュールでの前記要請されたレコードのメタデータと前記入出力要請とを前記識別モジュールに送信する段階、及び前記識別モジュールから前記入出力要請に対応する結果を受信して前記アプリケーションに送信する段階を含む。

本発明の一実施形態による識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置は、アプリケーションから識別モジュールに保存された所定レコードの入出力に対する要請を受信するアプリケーション通信部、前記要請されたレコードのメタデータを検索するノード情報検索部、及び前記検索されたメタデータと前記入出力要請とを前記識別モジュールに送信する識別モジュール通信部を含む。

本発明を具現することによって、端末機と識別モジュールとの間のデータ処理速度を向上させうる。

本発明を具現することによって、識別モジュールに保存されたレコードの情報をキャッシュしてデータ処理速度を向上させうる。

説明に先立って本明細書で使用する用語の意味を簡略に説明する。しかし、用語の説明は、本明細書の理解を助けるためのものであって、明示的に本発明を限定する事項として記載していない場合に、本発明の技術的思想を限定する意味として使用するものではないということを注意せねばならない。

−ＳＩＭ、ＵＩＭ、ＵＳＩＭ、識別モジュール
ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｙ Ｍｏｄｕｌｅ）は、ユーザ認証カードとして端末機に挿入される一種のスマートカードであって、ネットワーク情報、ローミング情報、電話番号、料金内訳などの加入者情報とユーザ認証、データ暗号化などの保安情報が内蔵されたカードである。このカードと携帯電話などの端末機とが結合されて通信がなされる。

ＵＩＭ（Ｕｓｅｒ Ｉｄｅｎｔｉｆｙ Ｍｏｄｕｌｅ）は、一種のＣＤＭＡ ＳＩＭカードであり、事業者のうち、中国のチャイナユニコムが導入したものであって、ＳＩＭカードの機能を提供する。

ＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｙ Ｍｏｄｕｌｅ）は、ＳＩＭとＵＩＭとをいずれも受け入れる、さらに拡張された概念の３世代用の移動通信チップカードである。今後、非同期式３世代サービスは、ＵＳＩＭカードを必須仕様と決めている。

本明細書で使用する識別モジュール（Ｉｄｅｎｔｉｆｙ Ｍｏｄｕｌｅ）は、上記のＳＩＭ、ＵＩＭ、ＵＳＩＭをいずれも備えることを意味する。

−タスクモジュール
ＵＩＭタスクのようにアプリケーションと識別モジュールとの間にデータを入出力し、識別モジュール機能の使用に必要なインターフェースを提供する。アプリケーションから特定行為を行うことを要請されれば、デバイスドライバーが理解しうる命令語に変換し、逆にデバイスドライバーから応答を受ければ、これをアプリケーションが理解できる形に変換する役割を行う。

以下、添付された図面を参照して本発明の望ましい実施例を詳細に説明する。

図５は、本発明の一実施形態によるノード情報部の構成を示すテーブルである。

ノード情報部は、識別モジュールに保存されたディレクトリの情報を保存するモジュールである。ノードは、識別モジュールで１つ以上のファイルを含むディレクトリを意味する。ノードは、図２でＭＦ、ＤＦ ＴＥＬＥＣＯＭ、ＡＤＦ１、ＡＤＦ２、ＤＦ１（ＡＤＦ１）、ＤＦ１（ＡＤＦ２）のようなディレクトリを含む。

ノード情報部は、識別モジュールに保存された情報、すなわち、レコードに対するメタデータを保存する。レコードを含むファイルについての情報であるファイルの位置、大きさ、含むレコードの数などがメタデータになりうる。ノード情報部は、一種のデータベースのようにディレクトリの位置及び如何なるファイルを有しているかなどを保存する。ノード情報部は、識別モジュールのディレクトリを検索する時に更新され、それぞれのＥＦについてのエントリー情報を含む。ＥＦについてのエントリー情報としては、ファイル固有識別子（ＥＦＩＤ）、ファイル識別子（Ｆｉｌｅ Ｄｅｓｃｒｉｐｔｏｒ）、ファイルサイズ、レコードの数、レコード長などを含みうる。したがって、ノード情報部の数は、各ディレクトリ数に比例する。

ノード情報部に保存されるＥＦファイルについての情報は、アプリケーションに提供するレコードの性格によって分けられる。レコードは、電話帳情報、短文メッセージ情報、ネットワークローミング情報、通話した電話番号に関する情報などになりうる。

ＥＦファイルは、これらレコードを１つのファイルに含むファイル情報となる。したがって、電話帳を探そうとするアプリケーションは、これに該当するＥＦファイルの情報を検索して、電話帳に関連した作業を行える。

図２の場合、ＭＦ、ＤＦ ＴＥＬＥＣＯＭ、ＡＤＦ１、ＡＤＦ２、ＤＦ１（ＡＤＦ１のＤＦ１）、ＤＦ１（ＡＤＦ２のＤＦ１）のように総６個のディレクトリが存在し、６回の登録手続きが必要である。ＭＦノードについての情報は、ＥＦＰＬファイルとＥＦＩＣＣＩＤファイルに対するエントリー情報を有する。ＤＦ ＴＥＬＥＣＯＭノードについての情報は、ｘ個のファイル（ＥＦ１，ＥＦ２，…，ＥＦｘ）についてのエントリー情報を有する。ＡＤＦ１は、ｚ個のファイルに対するエントリーを、ＡＤＦ２はｙ個のファイルに対するエントリーを、そして、ＡＤＦ１に存在するＤＦ１ノードは、ＥＦ３とＥＦ４、ＥＦ５ファイルに対するエントリーを、そしてＡＤＦ２に存在するＤＦ１ノードは、ＥＦ３とＥＦ４ファイルに対するエントリーを含む。このようなエントリー情報はいずれもレコードのメタデータになりうる。

ノード情報部は、通信端末のメモリ、またはデータベースに保存されることができ、タスクモジュール内にも位置しうる。ノード情報部の原本は、ＳＩＭカードやＵＩＭカードなど識別モジュール内に存在しうる。そして、通信端末と識別モジュールとが結合する場合、ノード情報部の原本が通信端末のメモリまたはデータベースにコピーされて保存されうる。通常、識別モジュールが、通信端末との結合時には、データ交換が起こり、初期セット過程があるので、この時期に情報をあらかじめ読出せば、時間を短縮できる。ノード情報部は、検索の速度を速くするためのものであって、テーブルのように構造化された形式に保存することが望ましい。そして、ノード情報部は、識別モジュールに存在するレコードまたはノードの情報をキャッシュのように保存して使用するので、レコードに変更があるときに、ノード情報部にも変更が同一に起こるように同期化が行われねばならない。

図５に示されたノード情報部を通じてどんなファイルがどんなディレクトリ内に位置しているか、レコード数字と大きさ、ファイルサイズなどについての情報が分かる。ノード情報部を通じてタスクモジュールは、検索時間を短縮してデータを速かに入出力できる。また、タスクモジュールは、多重コマンドの場合、重畳される作業を最小化して処理速度を向上させる。

図６は、本発明の一実施形態によるタスクモジュールの構成要素を表す構成図である。

本実施例で使われる”部”という用語、すなわち、”モジュール”あるいは”テーブル”はソフトウェアまたはＦＰＧＡまたはＡＳＩＣのようなハードウェア構成要素を意味し、モジュールは所定の役割を行う。しかし、モジュールはソフトウェアまたはハードウェアに限定されるものではない。モジュールはアドレッシングできる保存媒体に位置すべく構成されても良く、１つまたはそれ以上のプロセッサーを再生させるように構成されても良い。したがって、一例としてモジュールはソフトウェア構成要素、客体向けソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャー、サブルーチン、プログラムコードのセグメント、ドライバー、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ及び変数を含む。構成要素とモジュール内で提供される機能はより少数の構成要素及びモジュールに結合されるか、追加的な構成要素とモジュールにさらに分離されうる。のみならず、構成要素及びモジュールはディバイスまたは保安マルチメディアカード内の１つまたはそれ以上のＣＰＵを再生させるように具現されることもある。

タスクモジュール５０は、シングルレコード命令処理部５１０、多重レコード命令処理部５２０、命令分析部５３０、ノード情報検索部５４０、高速照会部５５０、ノード情報更新部５６０、アプリケーション通信部５８０、結果処理部５８５、識別モジュール通信部５９０を含む。

ノード情報更新部５６０は、識別モジュールから受けたファイルの状態情報をノード情報部に更新して管理する作業を行う。識別モジュールと通信端末との結合時にノードまたはディレクトリ情報を受信し、これをノード情報部に保存する。識別モジュール通信部５９０からノード情報を受信する。一方、ノード情報更新部５６０に保存された情報は、レコードを検索するために必要な情報であるために、レコードを保存するか、削除する場合に、このような変更事項をノード情報部にも反映することによって同期化を合わせられうる。

ノード情報検索部５４０は、アプリケーションなど外部から識別モジュールに対するサービス要請またはデータ入出力の要請がある場合、関連した情報がノード情報部に保存されているかを検索する。アプリケーション通信部５９０から命令語を受信し、この命令語に該当するノードを探す。該当ＥＦがノード情報部に存在しているか否かをチェックし、一致する情報がない時には、ノード情報更新部５６０が該当ＥＦを含むノードまたはディレクトリを構成する全体ＥＦの情報で構成されたテーブルを生成できる。

高速照会部５５０は、前記ノード情報検索部５４０で探そうとするデータが存在していない場合、迅速にファイルを検索する機能を提供する。すなわち、探そうとするＥＦ情報がノード情報部に存在していない場合、ＥＦ親ノードの情報を獲得する。初期に識別モジュールと端末機とが結合する場合、識別モジュール通信部５９０を通じて識別モジュール内のノード、ディレクトリ、ファイルについての情報をあらかじめ読出す機能も提供する。読込んだデータは、ノード情報更新部５６０によりノード情報部に保存される。

命令を処理する部分である命令処理部５０５は、命令分析部５３０、シングルレコード命令処理部５１０、多重レコード命令処理部５２０を含む。命令分析部５３０は、アプリケーションなど外部で要請するサービス要請、またはデータ入出力に対する命令を分析し、この命令が１つのレコードに関するものか、または多重のレコードに関するものかを判別する。その結果に応じて、如何なる方式で命令を処理するかを決定する。命令分析部５３０は、ＥＦファイルの情報を分析して、図３のファイルの形態によって複数個のレコードを一度に要求する多重レコード命令であるか、そうでなければ、１つのレコードを送るシングルレコード命令であるかを判別しうる。

シングルレコード命令処理部５１０は、命令分析部５３０を通じて１つのレコードに関する命令と判別された場合を処理する。例えば、１つのレコードを読出すか、書込むか、あるいは削除する場合がこれに該当する。

多重レコード命令処理部５２０は、命令分析部５３０を通じて多重のレコードに関する命令と判別された場合を処理する。例えば、２つ以上のレコードを読出すか、書込むか、あるいは削除する場合がこれに該当する。２つ以上の電話番号を削除するか、電話帳全体を削除する場合がこれに該当する。

アプリケーション通信部５８０は、アプリケーションから命令を受信し、これをノード情報検索部５４０に渡し、この命令に対する結果を識別モジュール通信部５９０または結果処理部５８５から受信してアプリケーションに伝送する。

識別モジュール通信部５９０は、識別モジュールからデータを読出し、命令処理部５０５で生成した命令語を識別モジュールに伝送する機能を有する。また、識別モジュールで処理された結果をアプリケーション通信部５８０に伝送する。結果をアプリケーションに合わせて加工すべく、結果処理部５８５に伝送しうる。

結果処理部５８５は、識別モジュール通信部５９０が受信した処理結果をアプリケーションに合わせて加工して、アプリケーション通信部５８０に伝送する。

前述したように、ノード情報部３００は、端末装置内のメモリに保存されうる。この場合、タスクモジュール５０のノード情報検索部５４０は、メモリ入出力演算を通じてノード情報を検索しうる。一方、タスクモジュール５０が独自のメモリを有する場合には、タスクモジュール５０にノード情報部３００を設けられる。

図７は、本発明の一実施形態によるノード情報部にノード情報が保存されたか否かによって異なって展開される順序図である。

アプリケーション１０でタスクモジュール５０に特定ファイルＥＦのアクセスを要請する（Ｓ２０１）。タスクモジュールは、ノード情報部でＥＦ情報を検索する（Ｓ２０５）。検索した結果、ノード情報部にＥＦファイルについての情報がなければ、ＥＦファイルを含む情報を読出す作業が必要である。図６の高速照会部５５０では、識別モジュールでノードの情報を読出す。デバイスドライバーに高速検索を要請し（Ｓ２１１）、この要請に対する応答として前記検索しようとするＥＦファイルを含む特定ノードまたはディレクトリＤＦ１を構成する１つ以上のＥＦの情報を読出す。これらＥＦファイルの情報は、ノード情報部に保存される。もちろん、Ｓ２０１段階で検索しようとしたＥＦファイルについての情報もこれに含まれる。この情報に基づいてＥＦファイルを読出し／書込み作業を行う（Ｓ２１５）。そして、この作業に対する処理結果を受信する（Ｓ２１６）。

もし、Ｓ２０５段階で、ノード情報部に該当ＥＦファイルの情報が存在するならば、この情報でＥＦファイルの位置が分かる。したがって、ＥＦファイルの読出し／書込み作業が直ちになされる（Ｓ２２１）。そして、この作業に対する処理結果を受信する（Ｓ２２２）。

タスクモジュールは、Ｓ２１６またはＳ２２２段階で受信した処理結果をアプリケーションに伝送する（Ｓ２３１）。

図８は、本発明の一実施形態によるタスクモジュールがノード情報を受信して使用する過程を示す順序図である。

タスクモジュールは、アプリケーションからレコード入出力を要請する命令を受信する（Ｓ２５０）。レコード入出力を要請する命令としては、端末機の特性によって異なり、電話帳の入出力、削除、ユーザ情報の入出力など多様である。これは端末機が如何なるデータを入出力するかによって、すなわち、アプリケーションによって多様である。タスクモジュールは、識別モジュールのレコードのメタデータが存在しているかを検討する（Ｓ２５１）。レコードのメタデータとは、識別モジュールで探そうとするレコードの保存されたファイルについての情報でありうる。図５のノード情報部に保存された情報がレコードのメタデータになりうる。レコードのメタデータの例としては、このレコードの保存されたファイルの位置情報、ファイルの大きさ、ファイルを構成するレコードの数についての情報を含む。レコードのメタデータが存在するならば、このメタデータでレコードを入出力できる。レコードのメタデータが存在していない場合には、識別モジュールから受信して保存する（Ｓ２５２）。受信したメタデータは、ノード情報部に保存される。今後、レコード入出力と関連した命令語の受信時に、ノード情報部を参照しうる。もし、探そうとするレコードのメタデータがノード情報部に存在していない場合には、Ｓ２５２過程を行ってノード情報部にメタデータを保存しうる。

ノード情報部に保存されたメタデータに基づいてレコードの入出力命令を行う前にレコードの入出力命令が２つ以上のレコードの入出力を要請する命令であるかを検討する（Ｓ２５４）。もし、２つ以上のレコードの入出力を要請する命令語であれば、従来の複数回の入出力命令語を伝送する方式と異なり、一度に伝送できるように処理するためである。Ｓ２５４段階で、２以上のレコードに対する入出力命令であると判断された場合、これらレコードを含むファイルについての情報及びレコード識別子を識別モジュールに送信する（Ｓ２５６）。識別モジュールに対して、複数のレコードに対する入出力命令であるということを知らせる情報を付加しうる。一方、１つのレコードに対する入出力命令である場合には、そのレコードを含むファイルの情報とレコード情報とを識別モジュールに送信する（Ｓ２５７）。この場合には、従来の入出力方式を使用しうる。タスクモジュールは、識別モジュールに送信した命令の結果を受信する（Ｓ２５８）。受信した結果は，再びアプリケーションに伝送する（Ｓ２５９）。この際、アプリケーションの性格に合わせて結果を加工しうる。

図９は、本発明の一実施形態による多重レコードを読出す過程を示す順序図である。

アプリケーション１０がタスクモジュール５０にＥＦ Ｒｅａｄ要請を行う（Ｓ３０１）。ＥＦ Ｒｅａｄ要請とは、ＥＦファイル内に保存されたレコードを要請することを意味する。例えば、複数の電話帳を読出すか、複数の通話内訳情報を読出すなどが、これに該当する。ＥＦファイルが保存するデータの種類が、ＥＦによって分けられうる。電話帳は、ＥＦ１に保存され、ＳＭＳメッセージはＥＦ２に保存されるとあらかじめ定義された場合に、アプリケーションは、目的によって如何なるＥＦファイルに接近するかを判断する。そして、このようなＥＦファイルについての情報は、ノード情報部に保存される。

タスクモジュール５０は、ノード情報部でＥＦ情報を検索する（Ｓ３０２）。このファイルの位置、大きさ、レコード数についての情報が保存されたかを検索し、検索された場合、ノード情報部でＥＦ情報を検出する（Ｓ３０３）。検出された情報を通じてＥＦファイルの位置情報が分かる。検出されたＥＦファイルの位置とレコードリストを共にデバイスドライバー９０に伝送すれば（Ｓ３１０）、デバイスドライバー９０は前記ＥＦファイルの位置でレコードを読出し、これをタスクモジュール５０に伝送する（Ｓ３１１）。タスクモジュール５０は、受信したデータリストをアプリケーションに送信する（Ｓ３１２）。送信前にこのデータリストをアプリケーションに合わせて加工しうる。

図１０は、本発明の一実施形態による多重レコードを保存する過程を示す順序図である。

アプリケーション１０がタスクモジュール５０にＥＦ Ｗｒｉｔｅ要請を行う（Ｓ４０１）。ＥＦ Ｗｒｉｔｅ要請とは、ＥＦファイル内にあるレコードを保存、変更または削除することを意味する。例えば、複数の電話帳を削除するか、外部アプリケーションから複数の電話番号を受信して保存する場合、または多量のレコードを通信を通じて受信して保存する場合などがこれに該当する。タスクモジュール５０は、ノード情報部でＥＦ情報を検索する（Ｓ４０２）。ＥＦファイルの位置、大きさ、レコード数についての情報が保存されたかを検索し、検索された場合、ノード情報部でＥＦ情報を検出する（Ｓ４０３）。検出された情報を通じてＥＦファイルの位置情報が分かる。検出されたＥＦファイルの位置と保存するレコードリストを共にデバイスドライバー９０に伝送すれば（Ｓ４１０）、デバイスドライバー９０は、前記ＥＦファイルの位置でレコードを読出し、これをタスクモジュール５０に伝送する（Ｓ４１１）。タスクモジュール５０は、受信したデータリストをアプリケーションに送信する（Ｓ４１２）。送信前にこのデータリストをアプリケーションに合わせて加工しうる。

本発明が属する技術分野で当業者ならば本発明がその技術的思想や必須特徴を変更せずとも他の具体的な形に実施されうるということが理解できるであろう。したがって、前述した実施例はあらゆる面で例示的なものであり、限定的なものと理解してはならない。本発明の範囲は前述した詳細な説明よりは特許請求の範囲によって現れ、特許請求の範囲の意味及び範囲、そしてその均等概念から導かれるあらゆる変更または変形された形が本発明の範囲に含まれると解釈せねばならない。

本発明は、識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法及び装置に関連した技術分野に好適に適用されうる。

従来のＵＩＭ（Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅ）ソフトウェアの構造を示す例示図である。 従来のＳＩＭカード内にデータが保存される方式を示す構造図である。 ＳＩＭデータを構成するファイル構造体を示す例示図である。 従来のＵＩＭモジュールでデータを読出す順序図である。 本発明の一実施形態によるノード情報部の構成を示すテーブルである。 本発明の一実施形態によるタスクモジュールの構成要素を表す構成図である。 本発明の一実施形態によるノード情報部にノード情報が保存されたか否かによって異なって展開される順序図である。 本発明の一実施形態によるタスクモジュールがノード情報を受信して使用する過程を示す順序図である。 本発明の一実施形態による多重レコードを読む過程を示す順序図である。 本発明の一実施形態による多重レコードを保存する過程を示す順序図である。

符号の説明

５０ タスクモジュール
３００ ノード情報部
５３０ 命令分析部
５４０ ノード情報検索部

Claims (15)

1. アプリケーションから識別モジュールに保存された所定レコードの入出力に対する要請を受信する段階と、
   前記識別モジュールでの前記要請されたレコードのメタデータと前記入出力要請とを前記識別モジュールに送信する段階と、
   前記識別モジュールから前記入出力要請に対応する結果を受信して、前記アプリケーションに送信する段階と、を含む、識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
2. 前記レコードのメタデータを前記識別モジュールから受信する段階をさらに含む請求項１記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
3. 前記レコードのメタデータは、前記レコードを含むファイルの位置と識別子、レコードの数、レコード長、そして、ファイルの大きさを選択的に含む請求項１記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
4. 前記入出力に対する要請を、前記識別モジュールに送信する命令語に変換する段階をさらに含む請求項１記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
5. 前記入出力に対する要請が、２つ以上のレコードに関する要請である場合、前記識別モジュールに送信する段階は、前記２つ以上のレコードのメタデータと前記２つ以上のレコードの情報を前記識別モジュールに送信する段階である請求項１記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
6. 前記レコードは、電話帳情報、短文メッセージ情報、ネットワークローミング情報、通話した電話番号に関する情報のうち、いずれか１つである請求項１記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
7. 前記識別モジュールは、ＳＩＭカード、ＵＩＭカード、ＵＳＩＭカードのうち、いずれか１つである請求項１記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる方法。
8. アプリケーションから識別モジュールに保存された所定レコードの入出力に対する要請を受信するアプリケーション通信部と、
   前記要請されたレコードのメタデータを検索するノード情報検索部と、
   前記検索されたメタデータと前記入出力要請とを前記識別モジュールに送信する識別モジュール通信部と、を備える識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
9. 前記アプリケーション通信部で受信した入出力に対する要請を前記識別モジュールに送信する命令語に変換する命令処理部をさらに含む請求項８記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
10. 前記アプリケーション通信部から受信した入出力の要請が二以上のレコードに関する命令である場合、前記命令処理部は前記二以上のレコードのメタデータと前記二以上のレコードの情報とを前記識別モジュールに送信する請求項９記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
11. 前記識別モジュールのノードに関する情報を含むノード情報部をさらに備える請求項８記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
12. 前記レコードのメタデータを前記識別モジュールから受信する高速照会部と、前記高速照会部が受信したノード情報を前記ノード情報部に保存するノード情報更新部と、をさらに備える請求項８記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
13. 前記レコードのメタデータは、前記レコードを含むファイルの位置と識別子、レコードの数、レコード長、そして、ファイルの大きさを選択的に含む請求項８記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
14. 前記レコードは、電話帳情報、短文メッセージ情報、ネットワークローミング情報、通話した電話番号に関する情報のうち、いずれか１つである請求項８記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。
15. 前記識別モジュールは、ＳＩＭカード、ＵＩＭカード、ＵＳＩＭカードのうち、いずれか１つである請求項８記載の識別モジュールのレコード情報を保存してデータ処理速度を向上させる装置。