JP2005518033A - スマートカードのデータ編成 - Google Patents

Abstract

解決策は、スマートカード（ＳＩＭ）などのデータ処理装置において、データの更新に加えてメモリ空間を最適化することに関する。更新されるデータは、このカードと通信を行う遠隔マシン（ＳＲＶ）から得られる。このマシンは、多数のデータ（Ｓｎ）を格納し、装置の異なるメモリ領域（Ｚ２、Ｚ３）のデータ形式の各々を格納するステップを含む。

Description

解決策は、アプリケーションに含まれる情報についてのオクテットのサイズの最適化、及び、通信ネットワークを通して互いに接続される２つのマシン間のデータ交換の最適化に関する。マシンは、情報を処理することができるプログラム可能な装置であることを忘れてはならない。
こうした解決策は、特に、通過帯域が制限される無線通信ネットワーク、具体的には、ＧＳＭ型（携帯通信用広域システム）の無線デジタル携帯通信システムに適用される。本発明は、ＧＳＭシステムに限定されず、ＵＭＴＳ、ＧＰＲＳシステムなどのあらゆるタイプのシステムに拡張することができる。

これらの解決策は、特に、材料の制約（メモリサイズ、プログラムを実行するための時間）及び／又はソフトウェアの制約が最大となるオンボード・システムに適用される。オンボード・システムは、携帯電話、電子機器、オンボード・システムのためのスマートカード等のいずれかとすることができる。
本発明を説明するために採用する例は、ＧＳＭ型（携帯通信用広域システム）の無線デジタル携帯通信システムと接続される端末のＳＩＭカード（加入者識別モジュール）と呼ばれるタイプのスマートカードの例とする。本発明者らの実施例においては、この端末は、スマートカードにダウンロードされるアプリケーションの幾つかを格納するサーバ型のマシンと通信することになる。

スマートカード型のオンボード・システムは、一般に、ユーザに多くの機能を提供するアプリケーションを格納する。これらの機能は時間が経つと進歩することが多く、こうしたシステムに新たな機能を導入して更新するためのデータのダウンロードの問題が存在する。
ＧＳＭ型のネットワークを通じて、サーバなどの遠隔マシンからのアプリケーション全体をダウンロードし、オンボード・システムのメモリ内のアプリケーションの状態及び位置を該サーバから管理することは、既に可能である。こうしたアプリケーションは、用いられるオンボード・システムのプログラミングのための共通インターフェースを用いて実行可能に開発される。この共通インターフェースは、ＳＩＭカードの例では、ＪＡＶＡインターフェースである。
この解決策の欠点は、こうしたダウンロードのために発生し、ネットワーク及び現行の基盤設備では一般に受容することが困難なトラフィックのサイズからもたらされる。

サービスによってとられるメモリ空間を軽視しないことも必要である。これらは、極めて多くの空間を必要とする。例えば、現在では、サービス（インデックス及びコマンド）は、同一のデータ・ブロック内に格納される。サービスが消去されると、サービスのためのコマンド及びそれに関連するコマンド・インデックスが同一のデータ・ブロック内に格納されるたびに、モータは、データ形式と結びついたシフト規則を適用する前に、データ形式（インデックスかコマンドか）を識別しなければならず、このことが処理速度の低下及びリソースの消費をもたらし、材料及びソフトウェアの制約が最大であるスマートカードには受け入れられないものとなる。

主な目的は、
カード内でデータによって占有されたメモリ空間を最適化すること、
アプリケーションのオクテットのサイズを減少させること、及び、
スマートカードとサーバとの間でデータの交換が行われるとき、データのトラフィックを減少させること、
である。
これらの目的を達成するために、解決策の幾つかを記載する。こうした解決策は、一例として与えられる以下の詳細な説明を読み、添付図面を参照することによってより良く理解されるであろう。

トラフィックを減少させるための第１の解決策は、次のステップ、すなわち、
異なるサービス機能Ｓｎを集めるステップ、
Ｓｎサービスの各々について、Ｉｄｎ識別子を指定するステップ、
を含む。
ＳＩＭカードは、サービスの各々に付随するメモリアドレスと、サービスＳｎを識別する受け取ったＩｄｎの機能とを管理するエンジンを格納し、このエンジンは、メモリ内のこのサービスＳｎの対応する位置を検索する。
したがって、スマートカードとサーバとの間でデータの交換が行われるとき、メッセージは、識別子Ｉｄｎを用いるのみである。このように、メッセージＳＭＳは、サービスのオフセットアドレスを含まない。そのため、通信の際のデータのバイトは減少させられる。さらに、アプリケーションをサービスの幾つかに分割することで、アプリケーションの一部のみを示すことが可能となる。この解決策は、カードに送られるメッセージのサイズを大きく減少させる。一般に、スマートカードに格納されたデータは、更新（データの削除、追加、置き換え、．．．）、アプリケーションの起動、停止、カードの一般的な状態を知るためにカードに問い合わせを行う要求、などのためにアクセスされる。

第２の解決策は、様々な型のデータ（ＯＦＦｎ、Ｓｎ）を格納するデータ処理装置、特にスマートカード（ＳＩＭ）のデータの更新に加えて、メモリ空間を最適化することに向けられる。本発明による処理は、この装置の異なるメモリ領域（Ｚ２、Ｚ３）に各々の型のデータを格納するステップを含む。このように、領域の各々は、同一の型のデータで関連付けられる。したがって、同一のシフト規則は、同一の領域におけるデータのすべてに適用される。サービスが削除され、メモリ空間を最適化するためにシフトを用いなければならないとき、シフトを担当するプログラムは、領域の型を識別し、同一のシフト規則をこの領域のデータに適用する。

アプリケーションのサイズを減少させる第３の解決策は、次のステップを含む、すなわち、
同一の情報を含むコマンドのすべて又は一部のための参照を指定するステップ、
該コマンドのすべて又は一部を、所望の情報を格納しているデータ・ブロックを正確に指し示す関連する参照に置き換えることからなる書き込みステップ、
である。
このように、アプリケーションの参照の存在により、アプリケーションにおいて同一のコマンドを「ｎ」回書き込むことを防止する。こうした技術は、アプリケーションのオクテットのサイズを著しく減少させることが明らかである。アプリケーション又はサービスがサーバからカードにダウンロードされるとき、データトラフィックは減少する。ダウンロードされると、アプリケーションは、カードに格納されたデータ復元プログラムによって再構築される。回復プログラムは、参照（ポインタ）を用いる。この回復処理は、以下の説明においてより詳細に与えられる。

記述を簡単にするために、図に示される同一の要素は、同じ数字を有するものとする。
図１は、解決策のすべてに適用できる実行例を伴うコンピュータ・アーキテクチャを示す。本発明者らの実行例においては、このアーキテクチャは、電気接点（図示せず）によって携帯電話ＭＯＢと接続されるＳＩＭスマートカードを含む。本発明者らの例においては、電話は、ＧＳＭ通信ネットワークを経由して、サーバＳＲＶと通信を行う。
示されるような本発明者らの例においては、サーバＳＲＶは、ＳＩＭカードにダウンロードできる利用可能なアプリケーションを含むアプリケーション・データベースＳＤＢを含む。

本発明者らの例においては、サーバは、電話オペレータに属するセンタＭＭＩも含む。このセンタは、ユーザからの要求を勘案して、特に信頼性のあるものである。これらの要求は、カードに格納されるアプリケーションを更新するための要求か、又は単にサーバＳＤＢ内の利用可能な新たなアプリケーションを導入するための要求に関するものとすることができる。本発明者らの実行例においては、ユーザは、自らの端末ＭＯＢを用いて、このＭＭＩセンタと通信を行う。
示される例においては、ゲートウェイＧＷを設けて、データベースＳＤＢとセンタＭＭＩとを相互接続する。ゲートウェイは、様々なマシンが相互に通信することを可能にする装置（ソフトウェア及び／又は材料）であることを強調しなければならない。

本発明者らの実施例においては、アプリケーションＯＤＳを設けて、新たなアプリケーションをデータベースＳＤＢに読み込む。本発明者らの例においては、このアプリケーションはコンピュータに格納され、オペレータが用いることで新たなアプリケーションを作成し、データベースＳＤＢにアプリケーションを供給する。
本発明者らの実施例においては、データベースＳＤＢ、ゲートウェイＧＷ、及びセンタＭＭＩを、同一のサーバＳＲＶに格納することを選択した。しかしながら、この構成は、限定的なものではなく、解決策を説明するためには、他の如何なる構成も選択可能であった。例えば、これらの３つの要素を、３つの異なるサーバに格納することも可能であった。

こうしたアーキテクチャにおいては、アプリケーションは、データベースＳＤＢからＳＩＭカードにダウンロードされる。本発明者らの実施例においては、サーバＳＲＶによって送出される更新メッセージは、ＳＭＳ（ショート・メッセージ・サービス）として知られる短いメッセージである。本発明者らの実施例においては、物理的モジュール及び／又はＳＭＳ−ｃソフトウェアを、サーバＳＲＶのゲートウェイＧＷと電話機ＭＯＢとの間に挿入する。このモジュールは、サーバＳＲＶからのメッセージを、ＳＭＳ型のネットワーク・メッセージの形態で、電話機ＭＯＢに送出することができる。さらに、サーバＳＲＶのゲートウェイに、メッセージを埋め込む手段を設ける。ゲートウェイＧＷ又はカードへのメッセージのすべてを安全なものとするために、安全手段も用いる。

以前に明らかにしたように、アプリケーションのサイズは小さいものではない。さらに、ネットワーク全体に分布したＳＩＭカードの数は、極めて多い。
以前に明らかにしたように、アプリケーションのサイズは小さいものではない。例えばＳＩＭカードのアプリケーションを更新することからなるダウンロードは、次に、更新に関わるＳＩＭカードの数によって増大した多数のＳＭＳを送信するものとなる。更新によって相当なトラフィックが発生するため、例えばＧＳＭネットワークといったネットワークの幾つかは、こうしたトラフィックを受け入れるようには設計されていないので、受け入れに係る問題を抱えることになる。

Ｉ）解決策によると、アプリケーションはもはや管理されないが、アプリケーションのサブアセンブリはそうではない。サブアセンブリの各々は、オンボード・システムのユーザに提供される多数の機能を含む。こうしたサブアセンブリは、本明細書の次の部分では、「サービス」（Ｓｎ）と呼ばれる。サービスは、コマンドの集合であり、コマンドの各々は、一連の連続するオクテットである。その結果、サービスには、アプリケーション構成の細分性が存在する。サービスは、一連の機能を組み合わせることができる。

第１の解決策は、次のステップ、すなわち、
サービスＳｎの各々に対して識別子Ｉｄｎを指定するステップと、
コンピュータ及びサーバＳＲＶの両方に、識別子Ｉｄｎの各々と、関連するサービスＳｎとを格納するステップと、
サービスを識別する識別子を用いて通信を行うステップと、
を含む。

図２は、ＳＩＭカードに格納されたアプリケーションのツリー構造図である。本発明者らの実施例においては、このアプリケーションは、ツリーのそれぞれの位置（ＰＯＳ１、ＰＯＳ１１、ＰＯＳ１２、ＰＯＳ２、ＰＯＳ３）を伴う５つのサービス（Ｓ１、Ｓ１１、Ｓ１２、Ｓ２、Ｓ３）を含む。アプリケーションの幾つかは、同一のＳＩＭカードに格納することができる。発明の原理は、カードに格納されたアプリケーションの各々について同様に適用されるので、単一のアプリケーションＡＰＰの実施例を説明するには制限があるであろう。同様に、本発明を説明するために採用されるサービス数は、全くの任意である。

具体的には、サービスＳ１は、ニュースを得ることを可能にするサービスとすることができる。サービスＳ１に付随するサービスＳ１１及びＳ１２は、例えば、それぞれ、スポーツ情報及び政治情報に関するものとすることができる。サービスＳ２は、消費についてのコンサルティングに関するものとすることができ、サービスＳ３は、ユーザが例えば宝くじに参加できるようにするゲームサービスとすることができる。
ツリーの巡回は、通常は、携帯電話ＭＯＢのキーボードのキーを用いて行う。ユーザがこのツリーを見るときはいつでも、例えば、ＰＯＳ１に配置されたサービスを見る。ユーザが別のサービスを見ることを望む場合は、キーボードを用いて、例えばサービスＳ２等に自分自身が位置するように移動させる。
好ましくは、アプリケーションの各々は、格納され、更新要求があったときは削除されるように、例えばＥＥＰＲＯＭ型の揮発性メモリに格納させる。

図３は、アプリケーションＡＰＰを格納するメモリ・ブロックＣＥＡ（図４）において、サービスＳｎの各々の位置ＰＯＳｎを格納するテーブルＴＡＢの図である。アプリケーションのサービスＳｎの位置ＰＯＳｎは、必須のパラメータではない。このパラメータは、一般に、販売目的で用いられる。一般に、このツリーの巡回は、ルートから始まる。商業戦略は、メモリ空間の価格をツリー内のサービスの位置によって変化させることからなるものとすることができる。例えば、ルートに配置されたアプリケーションＡＰＰを選択した後、携帯電話の画面のサイズによって、該ルートに付随する多数のサービスを該画面上で見ることができる。これらのサービスは、画面上で目にする最初のサービスであり、おそらくは最も用いられるものであるため、一般に、最も高価なものである。

本発明者らの実施例においては、サービスＳｎの各々は、メモリ・ブロックＣＥＡの第１のオクテットに関連する該サービスＳｎについての第１のオクテットの位置をオクテット数で与えることで、それぞれのインデックスＯＦＦｎによって認識される。このパラメータＯＦＦｎは、一般に、専門家によって「オフセット」と呼ばれる。このテーブルＴＡＢはまた、サービスＳｎの各々について識別子（ＩＤｎ）を格納する。本発明者らの例においては、サービスＳ１はアプリケーションの位置ＰＯＳ１（ＯＦＦ１）に配置され、その識別子はＩｄ１である。本発明者らの例においては、サービスＳ２はアプリケーションの位置ＰＯＳ２（ＯＦＦ２）に配置され、その識別子はＩｄ２である。サービスＳ３はアプリケーションの位置ＰＯＳ３（ＯＦＦ３）に配置され、その識別子はＩｄ３であり、以下同様である。
本発明者らの説明例においては、ＰＯＳｎ、（Ｉｄｎ）、及びＯＦＦｎの情報は、テーブルで示される。しかしながら、他の何らかの手段を、この情報を示すのに用いてもよい。
図４は、メモリ・ブロックＣＥＡ内のサービス編成の概略図である。サービスは、連結、すなわち、次々に格納される。第１のサービスは、インデックスＯＦＦ１をもつ位置ＰＯＳ１に格納される。第２のサービスは、インデックスＯＦＦ２をもつ位置ＰＯＳ２に格納され、以下同様である。サービスの格納順は問わない。

以前に明らかにしたように、サービスＳｎの各々は、それを特徴付ける単一の識別子（Ｉｄｎ）によって定められる。例えばサービスを追加し、起動し、停止させ、又は削除するといったサービスを処理するための全ての要求などは、この識別子（Ｉｄｎ）を用いる。
例えば、ＳＩＭカードに格納された（又は、サービスがカード上にない場合は、格納されたものと仮定した）サービスの状態及び／又は位置（及び、最終的には、サービスがカード上にないことを示す何らかの情報）を認識するためには、要求に、
識別子（Ｉｄｎ）と、
該要求が状態及び／又は位置に関する問い合わせであることを示す特徴又は他の何らかの手段と、
が含まれれば十分である。
別の例は、新たなサービスを導入するための要求からなるものとすることができる。
この要求は、
サービスの識別子（Ｉｄｎ）と、
この新たなサービスＳｎに関連するオクテットと、
該要求がサービスの追加に関するものであることを示す特徴又は他の何らかの手段と、
最後に、ツリー内のサービスの位置ＰＯＳｎと、
を含む。

別の例は、ＳＩＭカードに格納されたサービスを起動させるための要求とすることができる。
こうした要求は、
サービスの識別子と、
該要求がコマンドを起動させるためのものであることを示す特徴又は他の何らかの手段と、
を含む。
本発明者らの説明例では、こうした処理要求は、専門家に知られているＡＺＰＤＵ（アプリケーション・プロトコル・データ単位）型のメッセージである。

図５は、１つの８ビット・オクテットを含む識別子（Ｉｄｎ）の概略図を示す。本発明者らの実施例においては、このオクテットの第１のビットＢ１は、サービスの（起動又は停止した）状態を示すように設定される。このビットは、その値（０又は１）によって、当該サービスが起動されているかどうかを示す。識別子のこのビットの存在は、カード上のサービスの（起動又は停止した）状態を認識するには、該カードの識別子をこのアプリケーションについてのサーバＳＤＢに送信すれば十分であるという点で利点となる。
サービスがカードに格納され、且つ、停止している場合、サーバは、ビットの状態を変更することによって該サービスを起動させ、カード上の該サービスを起動させるためにこのように変更された識別子を送出する。起動に加えて、このサービスに関する新たなメニューを電話ＭＯＢの画面で見ることができる。

アプリケーションの格納域の割り当ての動的管理は、専門家によって一般に「モータ」と呼ばれるプログラムＰ１により行われる。格納域の割り当ての動的管理に加えて、このモータは、メモリＣＥＡのデータを翻訳すること、言い換えると、このデータをカードが解釈可能なフォーマット、すなわち本発明者らの例においてはＪＡＶＡ言語に変換するという第２の機能を確実なものとする。また、削除によって生成された空き空間をサービスが占有するので、このモータは、該サービスの削除後に、メモリに格納されたサービスのシフトを実行するために、それらを移動させる。こうしたシフトの説明は、さらに先で記載されることになる。
利点として、変更の結果は、携帯電話のユーザによるアプリケーションの実行時に、メモリ内に一時的に格納されるのみである。言い換えると、ＣＥＡデータのみが、不揮発性の方法で格納される。
この格納域の割り当ての動的管理は、メモリ分割に応じて、様々な方法で実行することができる。以下の異なるバージョンによって、この動的管理の説明が可能となる。

第１バージョン
格納域を分割する第１の方法は、以下のとおりとすることができる。メモリ構造は、サービスの長さ若しくはインデックスの長さなどの様々なデータの長さ、又は、サービス当たりの最大コマンド数を設定して、あらかじめメモリ空間を構成するように設計される。メモリは、固定されたサイズのレコードに分割される。
こうしたメモリ編成は、多くのメモリ空間を、メモリ全体に分散させて使用されないまま残し、それらをさらに使用することを困難にする。

第２バージョン
この解決策を説明するのに用いられることになる第２のバージョンは、先の問題、すなわち、利用可能な格納空間の分散を防止するような特殊なメモリ分割からなるものとすることができる。
この第２のバージョンによると、サービスＳｎの機能の始まりの各々は、アプリケーションの位置及び利用可能なサービスの最大数としてＹを用いて、位置ＯＦＦｎでアプリケーションに配置することができる。
本発明者らの説明例においては、サービスのコマンドＣｎの各々は、（該サービスが機能するように配置される）ＯＦＦＣｎと呼ばれるインデックスと、（該サービスに関連し、０から増加する番号付けを伴う）コマンドＣｎ数によって識別される。
メモリＣＥＡのサイズを、単一のオクテットを用いてインデックスをコード化できるような大きさにするものとする。したがって、本発明者らの実施例においては、ＸのインデックスＯＦＦｎがメモリに格納される場合、それらは、該メモリのＸオクテットを占有することが明らかである。
このバージョンは、図６Ａを参照して説明される。このバージョンによると、格納空間ＣＥＡは、領域に分割される。本発明者らの例においては、３つのデータ形式、すなわち、
サービスについてのインデックスＯＦＦｎ
各サービスのコマンドの各々についてのインデックスＯＦＦＣｎ、及び、
アプリケーションに含まれるサービスの各々を構成するオクテット列（コマンド）、
である。

領域を編成する幾つかの方法（Ａ及びＢ）が考えられる。
Ａ− 第１の方法は、例えば、テーブルＴＡＢの第３列（すなわち、サービスのインデックス）を第１の領域に格納し、インデックス及びサービスのデータを含む、それに続くブロックを第２の領域に格納することからなる。
Ｂ− メモリを編成する別の有利な方法は、次のとおりである。図６Ａは、こうした編成の概略図である。
第１の領域Ｚ１は、メモリＣＥＡの先頭においてインデックス（．．．、ＯＦＦｋ、ＯＦＦｙ、．．．）を格納するために確保しておく。本発明者らの例においては、この領域は、図３に見られるテーブルＴＡＢのＯＦＦｎ列のためのものである。これらのインデックスは、第２の領域Ｚ２上を指し示すことができる。
第２の領域Ｚ２は、サービスＳｎの各々についてのコマンドのインデックスを含む。この第２の領域は、メモリＣＥＡの最後のオクテットを占有する。図６Ｂは、この領域Ｚ２におけるサービスＳ１についてのコマンドのインデックスの拡大図である。

本発明者らの説明例においては、この領域は、６つのインデックス（ＯＦＦ１、ＯＦＦＣ２、ＯＦＦＣ３、ＯＦＦＣ４、ＯＦＦＣ５、ＯＦＦＣ６）を含む。この例においては、第１のインデックスは、メモリＣＥＡ内でサービスＳ１を見つけることと、実行される第１のコマンドを見つけることの両方を可能にする。他のインデックスは、このサービスＳ１のコマンドのインデックス（Ｃ２、Ｃ３、Ｃ４、Ｃ５、Ｃ６）である。図６Ｃは、図６Ａに見られるサービスＳ１の拡大図である。この図６Ｃでは、コマンドと、コマンドの各々についてのインデックスとを見ることができる。
第３の領域Ｚ３は、サービスＳｎを含む。この領域は、領域Ｚ１の直後から始まることが好ましい。この領域は、サービスＳｎの各々のコマンドを含む。
領域Ｚ２とＺ３との間は、空き空間Ｚ４である。
領域Ｚ２及びＺ３には、固定サイズを持たないという利点がある、すなわち、これらの領域のサイズは、ユーザの必要性に応じて展開することができる。例えば、新たなサービスが利用可能であるとき、それらのサービスは、空き空間Ｚ４に追加することができる。

本発明者らの説明例においては、サービスＳ１の実行は以下のとおりである。
識別子（Ｉｄｎ）は、領域Ｚ１において、選択されたサービスＳ１の６つのコマンドのインデックス（ＯＦＦ１、ＯＦＦＣ２、ＯＦＦＣ３、ＯＦＦＣ４、ＯＦＦＣ５、ＯＦＦＣ６）を含む領域Ｚ２のデータ・ブロックを指し示すインデックスＯＦＦｋを見つけることを可能にする。
これらのインデックス（ＯＦＦ１、ＯＦＦＣ２、ＯＦＦＣ３、ＯＦＦＣ４、ＯＦＦＣ５、ＯＦＦＣ６）は、対応するサービスが存在する領域Ｚ３を指し示す。本発明者らの例においては、第１のインデックスＯＦＦ１は、領域Ｚ３内のサービスについてのインデックスを与える。このように、領域Ｚ２のデータ・ブロックが識別されたとき、モータは、実行されるべき第１のコマンドを見つけることができ、選択されたサービスの該領域Ｚ２におけるインデックスを通して、該モータは、実行する次のコマンドのインデックスを見つけることができることになる。

以前に述べたとおり、このモータの機能の１つは、新たなサービスの格納を管理することである。本発明者らの説明例においては、新たなサービスについての格納機構は以下のとおりである。
ＳＩＭカードが、新たなサービスＳｎ及びその識別子（Ｉｄｎ）を受け取る。
次いで、モータは、領域の分割にしたがって、メモリ空間を割り当てる。図６Ａでは、矢印Ｆ１及びＦ２は、それぞれ、領域Ｚ４のサービス及び該領域Ｚ４のサービスについてのコマンドのインデックスを格納する方向を表すように示される。

以前に述べたように、このモータの機能の１つは、新たなサービスを追加するために、利用可能な空間を再編成することでもある。例えば、サービスが削除された場合、解放されたメモリ空間を再利用可能にするために、該メモリ空間はモータによって自動的に再編成される。
例えば、処理が、識別子がＩｄ３であるサービスＳ３の完全な更新であると考える。図７Ａ及び図７Ｂは、それぞれ、サービスを削除する演算の考え方、及び、シフト後に得られる結果の考え方を与える。
本発明者らの例においては、このサービスＳ３は、３つのコマンドＣ１、Ｃ２、Ｃ３を含む。図７Ｂは、このサービスＳ３の３つのコマンドのインデックスを格納するデータ・ブロックの拡大図である。

本発明者らの例においては、サービスＳ３を更新するステップは以下のとおりである。
ステップ１
モータは、取り扱うサービスの識別子Ｉｄ３をエントリ・パラメータとして受け取る。
ステップ２
テーブルＴＡＢ及び識別子（Ｉｄｎ）を用いて、モータは、サービスＳ３のコマンドのインデックス（ＯＦＦ３、ＯＦＦＣ２、ＯＦＦＣ１）を格納する領域Ｚ２のインデックスＯＦＦｋを見つけることになる位置を、Ｚ１において検索する。
ステップ３
モータは、メモリのサービス配置に関する情報の全てを保持し、次いで、サービスＳ３を領域Ｚ３から削除することができる（図７Ａの線を引いた領域を参照）。
ステップ４
サービスのデータが領域Ｚ３から削除され、領域２内の関連するインデックスが削除されると、メモリは、空間Ｚ４と同時に、２つの余分な空き空間を含む。次に、モータは、２つの空き空間を消滅させるために、領域Ｚ３のサービス及び領域Ｚ２のインデックスをシフトする。図７Ａの矢印は、シフトに関係するサービスを示す。

メモリを３つの領域Ｚ１、Ｚ２、Ｚ３に分割することは、処理のこのステップにおいて、特に有利である。第２の解決法によると、領域の各々は、同一のデータ形式と関連付けられる。したがって、同一のシフト規則が、同一の領域のデータのすべてに適用される。サービス（インデックス及びコマンド）が、同一のデータ・ブロックに格納されたとすると、モータは、該サービスの各々に対して、順に２つの異なる規則を適用することになる。これは、シフトが行われるとき、
サービスは、このデータにおいて唯一のシフト対象であり、
それに対して、インデックスは、
サービスのコマンドについての新たなインデックスを指し示すための除去と、
メモリのシフトと、
を同時に行うシフト規則の対象となる、
ことが理由である。
サービスのコマンドと対応するコマンドについてのインデックスとが同一のデータ・ブロック内に格納されると、モータは、データ形式に関連するシフト規則を適用する前に、該データ形式（コマンドであるか又はインデックスであるか）を識別しなければならず、このことが余計な処理をもたらすことになる。
したがって、メモリを異なる領域Ｚ１、Ｚ２、Ｚ３に編成することで、メモリ内のサービスの更新が簡単なものになる。

モータは、領域Ｚ３において、削除されたブロック長と等しい長さのシフトを実行することが好ましい。このシフトは、領域Ｚ３のインデックスＯＦＦ４の後ろに配置されたデータのすべてに適用する。本発明者らの説明例においては、図７Ａを参照すると、インデックスＯＦＦ４に配置されたサービスＳ１１と、インデックスＯＦＦ５に配置されたサービスＳ１２とが、シフトされる。
同様に、領域Ｚ１が更新される。この領域Ｚ１においては、インデックスは、領域Ｚ２で削除されたブロック長と等しい長さを差し引く対象となる。
同様に、領域Ｚ２において、モータは、削除されたブロック長と等しい長さのシフトを実行する。このシフトは、ＯＦＦｋより小さいインデックスをもつデータ・ブロックのすべて、すなわち、説明例では、サービスＳ１１及びＳ１２についてのコマンドのインデックスを含むブロックに適用する。さらに、Ｚ２において、コマンドＯＦＦＣｎのインデックスは、領域Ｚ３のサービスＳ３に対応するブロック長と等しい長さを差し引く対象となる。
解決策は、サービスの更新に限定されるものではない。同一の原理を用いて、コマンドの更新が完全に可能である。

本発明者らの例においては、新たなサービスをカード上に受け取る前は、このサービスＳｎのコマンドの最大数は未知である。サービスＳｎ又はコマンドＣｎの最大サイズもまた、未知である。メモリ割り当ての動的管理の際、定期的に、すなわち、空き空間Ｚ４のサイズを認識することからなるサーバ要求時に、計算が行われることが有利である。
空き空間Ｚ４を計算する第１の方法は、領域Ｚ２の第１のインデックスを領域Ｚ４の第１のインデックスから差し引くことからなるものとすることができる。
空き空間Ｚ４を計算する第２の方法は、アプリケーションを格納するために確保されたメモリ空間ＺＴのサイズＺＴと、このメモリ空間ＺＴの区画Ｚ１、Ｚ２、及びＺ３によって同時に占有されるメモリ空間との間の差し引きからなるものとすることができる。このため、サーバは、揮発性メモリ内でアプリケーションＡＰＰに割り当てられたメモリ空間のサイズＺＴの情報を受け取らなければならない。このように、サーバＳＲＶは、ＳＩＭカードに格納されたアプリケーションの各々についての新たなサービスを格納するための利用可能サイズを知ることができる。この計算は、アプリケーションの供給者が代わり、新たな供給者がカードの状態を知らない場合、有利となることがある。

以前に明らかにしたように、アプリケーションのメモリ割り当ての動的管理は、モータによって動的に行われる。好ましくは、このモータは、カードに格納され、ＳＩＭカードの供給者間の相互運用性を確実なものとするように、オンボード・システムのための共通インターフェースを用いて開発される。モータをカード外に格納することを当然考えることができるが、このケースには利点がない。例えば、このモータは、携帯電話ＭＯＢに格納させて実行することができる。しかしながら、こうした解決策は、こうしたモータを必ず格納する電話の使用を強いることになるので、困難である。

スマートカードには、ＪａｖａＣａｒｄ型のＳＩＭカードの製造者のすべてに共通のインターフェースをもつＪＡＶＡ仮想マシンを搭載することが有利である。好ましくは、このカードは、プログラミングのためのＡＰＩ共通インターフェースに完全に適合するものである。この解決策を用いることは、ＳＩＭスマートカードのためのＪＡＶＡアプリケーションの範囲内で有利である。メモリ空間の節約が重要なこうした状況においては、本発明は、制約（サービス、コマンドのサイズ、サービス当たりのコマンド数）の幾つかを免れると同時に、厳密に必要な空間のみを消費することを可能にする技術的な解決策を提供する。

利点として、コンピュータシステムは、ユーザの各々の情報を備えるデータベースＵＤＢを含む。このデータベースは、サーバＳＲＶの他の構成要素と通信を行うことができるように、ゲートウェイに接続される。このＵＤＢデータベースは任意である。それは、特に、例えばアプリケーションを格納するカードの各々についてのメモリサイズ、又はＳＩＭカードの各々に既に格納されたアプリケーションなどの様々な情報の格納を可能にする。より一般的には、それは、ＳＩＭカードの状態の記述を含むデータベースを含む。このように、新たなサービスを導入する前に、サーバＵＤＢは、例えばベースＳＤＢによって、このサービスが該当するカードに既に導入されているかどうかを知るために問い合わせされる。それは、導入されたサービスのバージョンに関する情報を格納することもできる。好ましくは、このデータベースは、主に識別子（Ｉｄｎ）を格納し、図３に記載されたテーブルの位置ＰＯＳｎを格納することも有利である。したがって、このサーバとの通信は、サービスの（Ｉｄｎ）識別子を用いて行うことが好ましい。

本発明者らの実施例においては、識別子は明確な構造を有する。それは、１つ又は幾つかのオクテットでコード化することができる。理想的には、識別子の第１のビットは、サービスの状態を定めるのに用いられる。このように、可能なサービス数が０から１２８までの間の場合は、１つのオクテットが用いられ、サービス数が０から１２８＊２５５までの間の場合は、２つのオクテットを用いることになり、サービス数が０から１２８＊２５５＊２５５の場合は、３つのオクテットを用いることになり、以下同様である。

本発明者らの実施例において、図２を参照すると、サービスＳ１は、メインメニューＭ１と、ノードＳ１の下位のサービスＳ１１及びＳ１２に関連するサブメニューＭ２１及びＭ２２とを含む。コマンドは、例えばＳＭＳの送出とすることができる。例えば、サービスＳ１が情報の取得を可能にするサービスであり、該サービスＳ１に付随する下位サービスＳ１１及びＳ１２が、例えばそれぞれスポーツ情報及び政治情報に関するものである場合、ユーザは、スポーツに関する情報を得ようと望む場合には項目Ｓ１２を選択し、コマンドＳＭＳはネットワークを通して送出される。
コマンドは、
ローカルサーバに電話をかけること、
ＳＭＳメッセージを送って天気予報又はスポーツ結果などの情報を受け取ること、
ＷＡＰサービスを作動させること、
などとすることもできる。
一般的には、メニューはツリー形態で示すことができる。ツリーは、ノード及びリーフを含む。本発明者らの説明例において、ツリーのリーフ上のメニューは、それらを選択することでカードから電話へのコマンドが発生する「事前対応型」と呼ばれるコマンドである。コマンドの各々は、極めて正確な機能を有する。本明細書の次の部分で、例として幾つかの機能を説明することになる。

前述のように、携帯電話の画面上で、メニュー及びサブメニューによってサービスを起動させることができる。図８は、そのノードにメニュー及びサブメニューの幾つかを含むツリー構造図である。図２とは異なり、この図は、ノード数が幾つでもよいツリーを示す。ツリーの階層数も幾つでもよい。しかしながら、この例の記載を簡単にするため、３つの階層Ｎ１、Ｎ２及びＮ３を含むツリーを用いて本発明を説明することを選択した。
階層１は、アプリケーションＡＰＰに関連するメインメニューＭＰのためのものである。
階層２は、階層Ｎ１の下位の階層であり、ｙａ個のメニューを含む。図では、それらに、Ｍ１、Ｍ２、．．．、Ｍｙａと印をつける。
階層Ｎ３は、階層Ｎ２の下位であり、サブメニューを含む。メニューの各々（Ｍ１、Ｍ２、．．．、Ｍｙａ）は、ｙｂ数のサブメニューを備える。したがって、メニューＭ１は、図においてＭ１１、Ｍ１２、．．．、Ｍ１ｙｂと印をつけたｙｂ個のサブメニューを備える。メニューＭ２は、図においてＭ２１、Ｍ２２、．．．、Ｍ２ｙｂと参照されるｙｂ個のサブメニューを備え、以下同様である。

次に、アプリケーションＡＰＰについてメモリに格納されるメニュー及びサブメニューの数は、次の数式、
Ｙ＝ＹＡ＋ＹＡ×ＹＢ
を用いて得られることが理解できる。
パラメータＹは、互いに独立にサービスを導入し、更新することが可能な位置の数を与える。サーバは、或るＳＩＭカードから別のカードにかけて異なることがあるこのパラメータを知ることになる。
このパラメータＹを知ることで、スマートカード型のオン・ボードシステムに置かれたアプリケーションの正確な作動状態を、最小のトラフィック（より少ないコスト）で知ることが可能となる。

本発明者らは、アセンブリ・ステップが、コンピュータのメモリ（ＣＥＡ）及びマシンのメモリ（ＳＲＶ）の両方に、識別子（Ｉｄｎ）の各々及び関連するサービスＳｎの幾つかを格納するステップを含むことを明らかにした。このように、識別子（Ｉｄｎ）をカードに、又はカードから送出することで充分である。カード及びサーバに格納されたプログラムは、この識別子を処理し、関連サービスを見つけることを可能にする。このプログラムは、カードのメモリ、好ましくは、サービスの更新を行うことができるように揮発性メモリに格納しているサービスを管理することも可能である。格納後、モータは、サービスが格納されるインデックスを格納する。このように、このプログラムは、その識別子（Ｉｄｎ）から始まるメモリＣＥＡ内の関連するサービスの位置に戻ることができる。

この識別子を処理するステップは、アプリケーションを取り扱うときに行われる。
有利なことに、プログラムは、ネットワーク全体に分布したＳＩＭカード間の相互運用性を確実なものとするために、ＪＡＶＡインターフェースを用いて開発される。
帰属ステップの際、識別子（Ｉｄｎ）のビットの一部は、装置のメモリ内のサービスの（起動又は停止した）状態を示すのに用いられることも明らかにした。サーバが、この識別子ａｎを取得するためにカードに問い合わせをして、その状態を知ることで十分である。この識別子は、カード上のサービスを起動又は停止させるために、マシン（ＳＲＶ）で用いられる。

本発明者らの実施例において、本発明者らは、こうしたプログラムは、サービスＳｎの識別子（Ｉｄｎ）及びそのインデックスＯＦＦｎに関連するデータを、端末が理解できる言語に変換することを明らかにした。利点として、プログラムは、サービスの削除後、削除によって生成された空き空間を占有するようにサービスを移動させるために、サービスを格納したメモリのシフトも行う。

この解決策は、１つ又は幾つかのサービスを更新するために、アプリケーションを幾つかのサービスに分割することを可能にする。この解決策は、システムのユーザに新たなサービスを提供することを可能にするように、ネットワークに接続されたオンボード・システムに機能的な自由度を取り入れる。
この解決策はまた、マーケティングを行い、より良い方法でユーザの希望を目標とし、該ユーザに興味を起こさせるサービスのみを該ユーザのために更新する際に、新たな解決策の実行を可能にする。
この解決策はまた、所与の期間、サービスを導入し、後にそれらを置き換えることを可能にする。
この解決策は、ユーザの特定の要求により適切に適用されるため、カードに格納されたアプリケーションの該ユーザによる利用を増加させることが明らかである。
サービスの各々を識別することからなる解決策によって、ネットワークを通過するメッセージのサイズを減少させることが可能となる。

今後、インデックスの管理は、カードに導入されたモータによって、カード上で実行される。サーバがカードに問い合わせを行うとき、カードのメモリ内のサービスのインデックスを特定することはもはや不要である。更新時のサービスのシフト管理はまた、新たなサービスを格納するための空き空間を増加させる。メモリ空間の損失は発生しない。この技術は、サーバをクライアントの各々について異なるこのパラメータの管理から解放することを可能にし、サーバについての処理を極めて簡単なものにする。
一般的には、この解決策は、分散型システムの場の全体にアプリケーションを配布するための実行可能な管理システムを提供する。

II）以前に明らかにしたように、スマートカードは、極めて制限されたサイズのメモリ空間を有する。一連のオクテットで構成されたコマンドのすべては、メモリ空間に順番に格納される。しかし、同一のコマンドがサービスの幾つかによって用いられることが多い。
別の解決策は、コマンドのオクテットを含むデータ・ブロックを指し示すことができる参照を、同一のオクテットを含む命令のすべて又は一部に割り当て、コマンドのすべて又は一部を関連する参照によって置き換えることからなる。
この解決策は、サービスのオクテットのサイズを減少させるために、冗長な情報を分解することからなる。
以下の２つの例によって、この解決策を説明する。

第１の実施例
図２を参照して前述されたようなサービスツリーにおいては、ツリーのリーフ、すなわち、該ツリーの末端に配置されたノードは、事前対応型コマンドである。ルートとリーフとの間の中間層に配置されたノードとは異なり、事前対応型コマンドの実行は、携帯電話ＭＯＢに送出されたコマンドである。
これらのコマンドは、異なるクラスのオクテット列を含む。本発明者らの実行例においては、３つのクラスのオクテット列を考えるものとする。図９には、コマンドＣｎのための様々なオクテットのクラスを概略的に示す。

オクテットの３つのクラスは以下のとおりである。
１−コマンドの型と同一の第１のオクテットのクラスＴ１であり、したがって、これらのオクテットは、メモリ内にこの型のコマンドが現れるのと同程度に何度も該メモリ内に現れる。
２−実行のためのコマンドに特定の第２のオクテットのクラスＴ２であり、コマンドの各々について本来的に異なる。オクテット・ストリングは、多くの場合１つのコマンドから別のコマンドへと繰り返されることが起こる場合がある（しかし、コマンドのすべてについて繰り返されるわけではなく、このことが、それらを、同一の型のコマンドのすべてにおいて同一のストリングが繰り返されるクラスＴ１のオクテットとは異なるものとする）。
３−先の２つの型のオクテットに従って計算された第３のオクテットのクラスＴ３である（例えば、コマンドの長さは、両方の型のオクテットＴ１及びＴ２に基づいた計算を用いて得られる）
冗長な情報の分解は、関連するオクテットのクラスによって、様々な方法で実行することができる。以下のバージョンでは、この分解を説明する。

バージョン１
原理は、Ｔ２型のカード情報と、モータが構成規則を見つけて戻ることを可能にする参照（すなわち、ポインタ）とを与えることである。この規則は、Ｔ１型の情報を含む。このバージョンによると、Ｔ１型の情報は、サーバとカードとの間の如何なる通信にも先立って、メモリに格納される。この格納は、例えばカードのカスタマイズ時に行われる。次に、Ｔ３型の情報は、再構成規則を指し示す参照を用いて情報Ｔ１からＴ３までをもつメッセージを最終的に復元するカードのモータによって、自動的に計算される。

バージョン２
Ｔ２型の情報の間では、オクテット・ストリングが１つのコマンドから別のコマンドへと繰り返される場合が多い。その時は、情報を複製しないように、第２の参照機構が導入される。コマンドポインタＡは、例えばコマンドＢのためのバイト・ストリングを指し示す。

バージョン３
コマンドの集合体を備えるサービスにおいては、多くの場合、同一のコマンドの集合がアプリケーション内の幾つかの場所に存在することが起こる。こうした場合には、機構は、アプリケーションを、事前対応型コマンドの集合が集まったモジュールの形態に分割することを可能にし、モジュール間をラッピングすることを可能にする。このように、サービスに格納されたポインタは、コマンドの組を置き換えることができる。

バージョン４
Ｔ２型のパラメータにおいては、ストリングの幾つかは、アプリケーション内でユーザがたどった経路に従って、動的に見つけることができる。例えば、事前対応型コマンドの中で、その幾つかはメッセージを含むＳＭＳを送出することを可能にする。このメッセージは、要求されたサービス（天気予報、情報、．．．）によって異なる。実際には、ＳＭＳの内容は、選択されたツリーのリーフによって部分的に決まることになる。

事前対応型コマンドの別の例は、通話の送出とすることができる。
ＳＭＳの送出は、選択されたサービスにそれ自体がリンクされるパラメータに取り付けられる。ＳＭＳメッセージを送出することからなる処理は、次のように実行することができる。
第１に、ツリー全体を巡回する際、連続的に選択されたノードの各々（例えば、名称、又はこのコマンドに関連するオクテット・ストリング）は、例えばカードのバッファメモリに保存される。例えば、ユーザがコマンドＣ１を選択する場合、該コマンドの名称はバッファメモリに保存され、次いで、該ユーザがツリーの下位コマンドを選択する場合、このサービスの名称も、バッファメモリに保存される。
ユーザがツリーのリーフを選択する場合、これは事前対応型コマンド、例えばＳＭＳの送出の実行を要求する。次いで、プログラムが起動して、このバッファメモリからパラメータ（コマンドの名称）を引き出し、それらをＳＭＳメッセージに、より正確にはこのために与えられたパラメータを取得することができるフィールドに挿入する。

言い換えると、所与の型の事前対応型コマンドに関する強調表示をもつリーフの各々は、ツリー内で行われた巡回にしたがって、コマンドを構築している同一のプログラムを起動させることになる。例えば、同一のＳＭＳコマンド発生器は、選択によってＳＭＳの送出が要求されるツリーのリーフのすべてによって用いられることになる。
利点として、巡回時に、ユーザがより低い階層（ｎ−１）からより高い階層（ｎ）へ進む場合、機構は、階層（ｎ−１）のノードの名称をバッファメモリから削除することに留意すべきである。

第２の実施例
この第２の解決策を説明する第２の実現例は、以下のとおりである。この第２の例は、コマンドのちょうど中央での分解機構を説明するものである。
図１０は、サービスを格納するのに用いられるメモリＣＥＡのメモリ・ブロックを示す。この例においては、記載を簡単にするために、コマンドのインデックス及び対応するコマンドは、同一のデータ・ブロックで表した。当然のことながら、コマンドのインデックス及びコマンドは、図６Ａ又は図７Ｂについて記載された内訳に従って、すなわち、領域Ｚ２にはインデックスを、領域Ｚ３にはコマンドを格納することができた。

このサービスは、好ましくはメモリ占有を最適化するためにコマンド間に空間を空けずに、次々に格納されるコマンド（Ｃ１−Ｃ１１）の幾つかを含む。本発明者らの実現例においては、コマンドのインデックスのすべてを含むフィールドＣＨ１は、このメモリ・ブロックの第１のバイトを占有する。
コマンドＣｎの各々は、独自のインデックスを有し、コマンド型に特定のデコード規則を用いる。したがって、コマンドＣｘ実行後のユーザの反応次第で、このコマンドの実行は、それぞれのインデックスによって識別される他の様々なコマンドのきっかけとなることができる。例えば、コマンドがユーザによるＰＩＮコードの登録に関するものである場合、次のコマンドは、該ユーザが該コードを正確に入力したか又は誤って入力したかによって決まる。
結果として、インデックスは、将来可能性のあるコマンドの各々について、サービスのコマンドの各々に格納されなければならない。
特定のコマンドＣ１の実行に関係するコマンドＣ３、Ｃ５、Ｃ８の各々についてのデコード規則もまた、実行されるコマンドＣ１のバイト・ストリングに含まれなければならない。
コマンドに関連するバイト数は、極めて大きくなる可能性がある。

図１１は、コマンドＣ１の実行がコマンドＣ３、Ｃ５、又はＣ８の実行のきっかけとなることができる例を表した図である。したがって、このコマンドは、コマンドＣ３、Ｃ５、及びＣ８のインデックスと、それらのそれぞれのデコード規則とを含む。
例えば、１０個のコマンド型が存在する場合を考えることができる。したがって、コマンドのバイト・ストリングをデコードするために、１０個の異なる規則が必要となる。

この第２の例を説明するために、
コマンドの実行が、Ｃ３、Ｃ５、及びＣ８のうち少なくとも２つの異なるコマンドの実行の原因となる場合があることと、
コマンドの総数Ａは、サービス当たり２５を超えないこと、
を仮定する。
解決策の原理によれば、コマンドの各々は、参照Ｘ（５８、３５、１３）に置き換えられ、該参照は、
それぞれ、フィールドＣＨ１を直接指し示して、実行されるべき次のコマンドのインデックス（ＯＦＦＣ３、ＯＦＦＣ５、ＯＦＦＣ８）を取得し、
関連するデコード規則を実行するために、実行されるべきコマンドの型Ｚを与える、
ことになる。
当該コマンドのインデックス及びその型が見つかると、次のコマンドを実行することができる。

本発明者らの例においては、この参照は、図１０でＸの符号を付けた仮想パラメータである。好ましくは、この参照は、所要の空間を最小化するために、できるだけ少ないバイト数しか持たないものである。それは、コマンド型の各々について取り得る最大数によって決まることになる。

解決策は、この参照Ｘを用いることと、２つの結果を提供することができる２つの別個の数学的関数を用いることからなり、該関数の一方はインデックスを与え、他方はデコード規則に対するポインタを与える。
次に、このバイトについて取り得る値の範囲は、コマンド型の各々について等間隔に分割される。コマンド型を決定する限定されない方法は、次のとおりとすることができる、すなわち、
参照Ｘが０から２４までの場合、コマンドは１型であり、
参照Ｘが２５から４９までの場合、コマンドは２型であり、
以下同様である。

本発明者らの実現例においては、ＤＩＶ演算子がこうした結果を与えることになる。コマンド型は、数学的演算、
Ｚ＝ＸｄｉｖＡ、すなわち、Ａ＝２５の場合、Ｚ＝Ｘｄｉｖ２５、
によって得られる。
数学的演算、
Ｙ＝ＸｍｏｄＡ、すなわち、Ａ＝２５の場合、Ｚ＝Ｘｍｏｄ２５、
は、事前に定められたフィールドＣＨ１において、実行される次のコマンドのインデックスを取得するのに用いられる。
ＤＩＶ演算子及びＭＯＤ演算子の性質は、次のとおりであることに留意されたい。
ｎＤＩＶｐ＝ｑ：ｐによるｎの整数除算が、商の整数部を与える。
ｎＭＯＤｐ＝ｑ：ｐによるｎのモジュロ除算が、剰余ｒを与える。
本解決策は、これらの２つの型の数学的演算に限定されるものではない。

冗長な情報を分解するこの技術は、カード上のサービス及びコマンドのサイズを著しく減少させる。この技術は、
サーバＳＤＢからカードに送ることが必要なＳＭＳメッセージ数の減少、及び、
スマートカード上でアプリケーションによって占有されるメモリ空間の減少、
の両方を可能とする。
この解決策は、カード内のサービス又はアプリケーションの数を増加させることを可能にする。
この発明は、また、コマンド間のこの巡回を管理するのに必要なメモリサイズの最大限の削減を可能にし、コマンドシフトのデコード規則の識別子を格納することからメモリ自体を解放することも可能にする。
一般的に言えば、カードのメモリ空間を最適化する解決策は、データ形式の各々を該装置の異なるメモリ領域（Ｚ２、Ｚ３）に格納することで特徴付けられる。領域の各々は、更新のための独自の規則を有する。

本発明者らの説明例においては、更新がデータを削除することからなる場合、マイクロコントローラユニットは、領域（Ｚ２）のデータ形式が別の領域（Ｚ３）に配置されたデータの位置に関連するものであるとき、
解放されたメモリ空間を使えるように戻すために、この領域（Ｚ２）を再編成するメモリのシフトと、
該領域（Ｚ３）のデータシフトに加えて、新たな位置を考慮した位置の更新と、
を実行するためにプログラムされることを明らかにした。
反対に、領域（Ｚ３）のデータ形式がサービス（Ｓｎ）に関連するものであるとき、この更新は、解放されたメモリ空間を使えるように戻すために、領域（Ｚ３）のサービスをシフトさせることからなる。

好ましくは、サービス（Ｓｎ）の各々は、識別子（Ｉｄｎ）によって識別される。したがって、この識別子（Ｉｄｎ）を含むデータを更新するためにコマンドを受け取るとき、このサービスに関連する種々の形成のデータに付随する様々なメモリ領域を識別することが残る。
この第２の解決策は、明らかに、材料の制約が極めて厳しく、メモリ空間の節約が極めて重要となるスマートカードに適したアプリケーションであることがわかる。この第２の解決策は、事前対応型コマンド間の巡回を確実なものとするために必要な空間の削減を可能にする。
この第２の解決策はまた、処理と、該処理のステップを実行するためのプログラムに関する。

解決策のすべてを適用できるコンピュータシステムの図である。 カード上にツリー構造によって格納されたアプリケーションの概略図である。 サービスの各々と、その機能が発明を実施するための最良の形態に記載される１つの識別子と、アプリケーションのツリー構造におけるサービスのそれぞれの位置とを含むテーブルを示す実施例の図である。このテーブルは、カードと、該カードと通信を行うマシンとによって、認識される。 カードのメモリのサービス編成の図である。 識別子を構成するビットの概略図である。 カードに格納されたデータの概略図であり、この図は、該データを第１の解決策に従ってメモリに格納する方法を示す。 図６Ａの２つの異なる部分の拡大図である。 図６Ａの２つの異なる部分の拡大図である。 カードに格納されたデータの概略図であり、この図は、サービスの削除に加えて、メモリデータをシフトする方法を示す。 図７Ａの囲み部分の拡大図である。 シフトが完了した後のメモリの図である。 ２つの階層にわたるアプリケーションのツリー構造を説明する例を示し、カード上で未決定の多数のノードを含むものである。 サービスのコマンドにおけるオクテットの様々なクラスの概略図である。 メモリ内のサービスの図である。この図は、第２の解決策の実行の第２の例である。この第２の例は、コマンドのちょうど中央に配置される。 図１０の第２の例の理解を助けるものである。

Claims (8)

1. マイクロコントローラを備え、種々の形成のデータ（ＯＦＦｎ、Ｓｎ）を格納するデータ処理装置、特にスマートカードであって、前記データ形式の各々は、前記装置の異なるメモリ領域（Ｚ２、Ｚ３）に格納され、前記マイクロコントローラは、該装置のメモリ内のデータを更新するとき、前記領域（Ｚ２、Ｚ３）の各々に固有の更新規則を実行するようにプログラムされることを特徴とする装置。
2. 前記更新がデータの削除からなる場合、前記マイクロコントローラは、領域（Ｚ２）の前記データ形式が別の領域（Ｚ３）に配置されたデータの位置に関連するものであるとき、
   解放されたメモリ空間を使える状態に戻すために、前記領域（Ｚ２）を再編成するメモリシフトと、
   前記領域（Ｚ３）のデータのシフトに加えて、新たな位置を考慮した位置の更新と、
   を実行するようにプログラムされることを特徴とする、請求項１に記載の装置。
3. 前記更新がデータの削除からなる場合、前記マイクロコントローラは、領域（Ｚ３）の前記データ形式がサービス（Ｓｎ）に関連するものであるとき、解放されたメモリ空間を使える状態に戻すために、前記領域（Ｚ３）のサービスのシフトを実行するようにプログラムされることを特徴とする、請求項１に記載の装置。
4. 前記サービス（Ｓｎ）の各々は、識別子（Ｉｄｎ）によって識別され、前記マイクロコントローラは、前記識別子（Ｉｄｎ）を含むデータ更新のためのコマンドを受け取るとき、該サービスに関連する種々の形成のデータに付随する様々なメモリ領域を識別するようにプログラムされることを特徴とする、請求項３に記載の装置。
5. 種々の形成のデータ（ＯＦＦｎ、Ｓｎ）を格納するデータ処理装置、特にスマートカード（ＳＩＭ）において、データの更新に加えてメモリ空間を最適化する処理であって、前記データ形式の各々を前記装置の異なるメモリ領域（Ｚ２、Ｚ３）に格納するステップと、該装置のメモリのデータを更新するとき、前記領域（Ｚ２、Ｚ３）の各々に固有の更新規則を利用するステップとを含むことを特徴とする処理。
6. 前記更新がデータの削除からなる場合であって、領域（Ｚ２）の前記データ形式が別の領域（Ｚ３）に配置されたデータの位置に関連するものであるとき、
   解放されたメモリ空間を使える状態に戻すために、メモリをシフトして前記領域（Ｚ２）を再編成するステップと、
   前記領域（Ｚ３）のデータのシフトに加えて、新たな位置を考慮して位置を更新するステップと、
   を含むことを特徴とする、請求項５に記載の処理。
7. 前記更新がデータの削除からなる場合であって、領域（Ｚ３）の前記データ形式がサービス（Ｓｎ）に関連するものであるとき、前記領域（Ｚ３）のサービスをシフトするステップを含むことを特徴とする、請求項５に記載の処理。
8. 請求項１から請求項４までのうちの１つに定められたデータ処理装置上で実行されるとき、請求項５から請求項７までのうちの１つに定められたステップを実行するためのプログラムコード命令を含むコンピュータプログラム。

Images