JP2015043231A - データ保護方法、回路カード、及び移動無線通信装置 - Google Patents

Abstract

【課題】１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全の程度は、容易に強化されることができて、本当に、柔軟ですぐに適合できる。
【解決手段】複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、複数のデータ・エレメントのうち少なくとも１つは、ドメイン保護エレメント及びパスワード保護エレメントと関連し、少なくとも１つのデータ・エレメントに対して許可された動作の開始にはパスワードが要求され、当該動作は、ドメイン保護エレメントにより定義されている。
【選択図】図１

Description

本発明は、データ保護方法、回路カード、及び移動無線通信装置に関する。

機能の増加に伴い、携帯電話機及び携帯機器（ＭＥ：Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ）のための他のタイプのハンドヘルドデバイスは、ストレージ及び大量の（個人）データを保持するための一般的なデバイス／インターフェースとして普及している。

たとえば、そのようなデータは、個人的な写真、ビデオ、及びＳＭＳメッセージであり、ユーザは、一般的に、ＭＥ、例えばＳｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ（ＳＩＭ）カードのようなＵｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ（ＵＩＣＣ）の関連部分、又はネットワーク運営者により提供されるネットワークサイドストレージ、又はメモリカードのような他のメディア・デバイスの中に、そのようなデータを格納するオプションを有している。

格納されるデータの量と潜在的に個人的な／繊細な性質からみれば、エンド・ユーザの視点から、記憶領域は、十分な記憶容量、適切なセキュリティレベルを備えなければならず、更に利用しやすい状態でなければならない。

ＭＥそのものが、適切な保安の程度を提供すると考えられるが、そのようなレベルのセキュリティは、特定ＭＥ製造業者に限定されがちであり、ストレージ容量は、全てのタイプのユーザ・データ、特にマルチメディア・データのためには十分に考慮されない。データへ接続性も同様に、一般に、製造業者の特別なケーブルと、関連するソフトウェアの接続性を必要とする。

メモリカードのような装置が、大きな記憶容量と手早い接続性を提供することができる一方、ユーザ・データに対して保護するか、適当な保護を提供する手段がない。

勿論、アクセスの容易性は、保証とはかけ離れているかもしれないネットワーク・アクセスの利用可能性に依存するが、ネットワークサイドストレージ領域に関しては、十分な記憶容量と共に高度な安全対策を実現することができる。

近年の発展においては、ＵＩＣＣのような回路カードは、潜在的に魅力的な記憶領域を有している。例えば３ＧＰＰ／ＥＴＳＩ Ｒｅｌ−７からから開始された、高密度メモリをサポートしているＵＩＣＣが利用可能であり、同様な仕様で、単純なアダプターを経由して例えばＰＣ等へのデータ検索のような、ＵＩＣＣによる非常に簡単で高速にデータ変換するＵＩＣＣとＭＥ間の、ＵＳＢ２．０／ＵＳＢ ＩｎｔｅｒＣｈｉｐに基づく新しいインターフェースの供給が提案されている。

国際公開公報ＷＯ２００８／１３９６１５ 米国特許公開公報２００８／２５４８３４ 米国特許公開公報２００８／２５６６２９ 米国特許公開公報２００８／１５５８３０

特に個人識別情報Ｎｏ．（ＰＩＮ）コードの使用によりＵＩＣＣは比較的セキュアであるとされているが、以下の点で限界が残っている。つまり、一旦ＰＩＮが検証されたら、単にユーザがＵＳＩＭ／ＧＳＭアプリケーションを起動したいときは、記憶されたユーザ・データは、更なるセキュリティチェックを要求されることなく自由にアクセスすることができてしまう。

つまり、たとえば、一旦ＭＥを起動し、正しいＰＩＮのエンティティを経由して使用してＵＳＩＭに適切にアクセスしたら、ＵＳＩＭに保存される他の全てのデータは、直ちにアクセス可能となり、特に、現在のエンド・ユーザが単に、ＭＥに一時的なアクセスをする目的であれば、適当でないかもしれない。

国際特許公開ＷＯ２００８／１５９６１５には、サービスの範囲の動的な変化を許可するメモリカード、アクセス・コントロールシステム、アクセスコントロール方法が記載されている。また、ダウンロードされる内容と関連した情報にしたがったアクセス管理の実行を通してのユーザに従う異なるサービスを提供し、そこでは、回路カードはデータ管理部を含み、カード上のデータを保護するためにセキュリティ・メカニズムの供給よりもむしろサービスの動的変化範囲に依存することが記載されている。

更に、米国特許公報２００８／２５４８３４、２００８／２５６６２９、及び２００８／１５５８３０には、それぞれ、ユーザ識別子の比較の提供を通して、コンテンツの安全なストレージを提示するメモリカードが記載されている。

本発明は、既存のカード及び方法に対し有利な点を有する回路カード、そしてそのようなカードを含むＭＥ、そのようなカードにおけるデータ保護方法を提供することを目的とする。

特に、本発明は、既存のカード及び方法に対し有利な点を有するＵＩＣＣ、及びそこでのセキュリティ及びデータを提供するための方法を提供するものとする。

本発明の一態様においては、複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、前記複数のデータ・エレメントのうち少なくとも１つは、前記ドメイン保護エレメント及びパスワード保護エレメントと関連する。

本発明は、１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全性を容易に強化することができて、実際、柔軟でかつすぐに適用可能な方法を提供することができる点で有利である。

したがって、そのような回路カードは、エンド・ユーザに、特に、そのような回路カードは、特に、ユーザの特有で慎重に扱うべきデータに対し、セキュリティ、能力、及びアクセス容易性において適切なレベルを有利に提供することができる。

それらが、データ・エレメントの保護、例えば、パーテション、ディレクトリ又はファイルのコンビネーションで提供される範囲で提供される場合、特に強化されたセキュリティのレベルが、上述した「パスワード」及び「ドメイン」の特徴のコンビネーションを通して提供される。「パスワード」特徴は、言わば、一度パスワードが検証されデータ・エレメントへのアクセスが許可されるような動作の本質から独立したものとして提供される。一方、「ドメイン」特徴は、前述のパーテション、ディレクトリ又はファイルなどのデータ・エレメントに許可される可能性があるオペレーション（動作）を定義する。

１つの特定の例に、回路カードは、ＵＩＣＣから成る。

さらにまた、セキュリティの付加的レベルが、回路カードの１つ以上のアプリケーションに対するＰＩＮアクセス・コードの使用を通して提供される。

好ましくは、上述の複数のデータ・エレメントの各々は、ドメイン保護エレメントと関係する。

更に好ましくは、許可された動作は、１以上のリード及び／ライト動作を含む前記ドメイン保護エレメントによって定義されたものである。

さらにまた、本発明の方法においては、回路カードにおいてデータにアクセスすることができるエンティティは、一意の識別子に関連している。

また、本方法は、データ・エレメントを生成するエンティティの識別子が保存されているものとすることができる。

さらに、そして、本発明を具体化した回路カードと共に使用するように構成されたＭＥに関し、当該方法は、ＭＥの中で、データへのアクセスを要求するエンティティを識別するものとすることができる。

好ましくは、データ保護ステップは、ＭＥと回路カードとの間のＵＳＢインターフェース・クラスに適用される

更に好ましくは、回路カード上のデータ・エレメントが、スタンダードファイルフォーマットファイルにしたがって保存される。

さらにまた、データ・エレメントの生成及び管理は、回路カード内のデータ・エレメントの生成及び管理によって行われ、また、ＭＥ経由で提供されることができる。

また、ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能を有する。

本発明の他の態様においては、複数の保護可能なデータ・エレメントが保存された回路カードであって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに関連して配置された、少なくとも１つの前記複数の保護可能なデータ・エレメントを有するものである。

好ましくは、回路カードは、ＵＩＣＣから成る。

また、少なくとも１つのデータ・エレメントは、ドメイン保護エレメントによる許可された動作を開始するために、パスワードが要求されるように構成することができる。

好ましくは、複数のデータ・エレメントのそれぞれは、ドメイン保護エレメントに関連している。

また、前述のオペレーション（動作）は、少なくとも１つのリード及び／又はライトアクセスオペレーションを含むドメイン保護エレメントによって定義されている。

好ましくは、回路カードは、ＵＳＢインターフェース・クラスを経由してデータ・エレメントにアクセスを許可するように構成される。

さらに、回路カードは、そのファイルシステムのスタンダードファイル内に保存されたデータ・エレメントを含むように構成される。

本発明は、さらに、上で定められるように、回路カードを受け取るように構成されたＭＥも提供することができる。

好ましくは、ＭＥは、ＵＳＢインターフェース・クラスを経由して回路カードと通信することができるように構成される。

更に好ましくは、上述の保存されたデータ・エレメントを生成及び／または管理が可能に構成されている。

好ましくは、ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能により定義されている。

本発明は、ほんの一例として以下の添付の図面を参照して、説明される。

本発明によれば、１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全の程度は、容易に強化されることができて、本当に、柔軟ですぐに適合できる方法として提供される。

図１は、本発明の実施例におけるＵＩＣＣの略平面図である。 図２は、移動無線通信装置またはＭＥの略平面図であって、携帯電話機及び図１のＵＩＣＣで動作するようアレンジされた図である。 図３は、本発明にかかるＵＩＣＣにおけるディレクトリの生成に関連した信号伝達タイミングチャートである。 図４は、ＵＩＣＣ等のためのファイル生成のための信号伝達タイミングチャートである。 図５は、誤ったパスワードを用いて保護されたファイルを読もうとした場合の信号伝達タイミングチャートである。 図６は、正しいパスワードを用いて保護されたファイルを読みだす場合の信号伝達タイミングチャートである。

上記及び以下の特定の実施の形態の詳細な説明から明らかなように、本発明は、単純なＰＩＮコードに基づくデータ保護機構の提供に関係する現在の回路カードに見られる限界に対処するものである。前述のように、回路カードは、第１に、たとえばＧＳＭ／ＵＳＩＭ等のアプリケーション及びその関連データであるＩＭＳＩまたはＰＬＭＮリスト等に関連する。そして、回路カード内のデータ、例えば、同じセキュリティ体制下に移動された、例えばユーザの個人的なファイル、写真、ビデオ、個人的なメッセージなどは、そのようなアプリケーションのいずれにも直接接続されていない。

本発明は、回路カードに格納されるあらゆるタイプのデータに対して、強化したセキュリティのレベルを提供することを目的とし、必要とされるならば、既存のＰＩＮ保護に加えて使われることができるデータ保護メカニズムを定める。

また、回路カード内のデータ記憶装置は、一般的には、大量のデータの記憶に適していないＥｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓに基づいている。また、そのようなファイルは、ビデオや音楽のようなあるタイプのデータを記憶するために定義されないことがしばしばある。したがって、新しいデータ記憶配置が、本発明の一部として提案され、回路カードセキュリティ向上に関連した特別な用途が見つけられる。

最初に図１を参照すると、本発明が適切に具体化されている回路カードの１つの例の概略図が提供されている。

回路カードは、記憶領域１４とＭＥインターフェース１６の間に提供される処理機能１２を含むＵＩＣＣ１０を有する。

後述されるように、インターフェース１６は、ＵＳＰ２．０／ＵＳＰ ＩｎｔｅｒＣｈｉｐに有利に基づくものとすることができる。ＵＳＰ２．０／ＵＳＰ ＩｎｔｅｒＣｈｉｐは、たとえば、ＵＩＣＣ１０と、簡単な電気アダブタを介してＰＣと接続される図２の携帯電話機１８との間のデータ変換を簡便で高速化することができる。

図２に関して、例えば携帯電話機１８等の携帯機器（ＭＥ）のどんな形式も含む携帯無線通信デバイスの概略図が提供されている。携帯電話機１８は、内部に図１のＵＩＣＣ１０を備え、スタンダード・メモリ２２、プロセッサ２０、及び送信／受信機能部２４を備えている。

携帯電話機１８として提供されることができる様々なストレージオプションのうち、ＵＩＣＣ１０は、上述し、下記に詳細を記述するセキュリティエレメント領域及びセキュリティエレメントパスワードのコンビネーションに基づく、有利で保証された、高速アクセス可能な、適当に大きいデータの格納場所を提供することができる。

現在の説明と本発明の定義に関して、当然ながら、パスワードがチェックされとすぐに、オペレーションが許されるだろうことから独立して、「パスワード」は、ファイル／ディレクトリ／パーテションへのアクセスを保護する。これに対し、ドメインは、特定のエンティティが、ファイル／ディレクトリ／パーテション上で実行することができる異なるオペレーションを定義する。

したがって、１つの特定の例として、各データ・エレメント、例えばファイル、ディレクトリまたはパーテションでさえ、ドメインと関係することができ、パスワードによって保護されることができる（関連するドメインがパスワードを必要とする場合）。
許可されたオペレーションのそれぞれの定義を有するいろいろなドメインが提供されることができ、相互運用性（インターオペラビリティ）を可能とするために、一般に標準化された方法で提供される。

例として、可能性があるドメインは以下の通りである：
プライベート：オーナー（ファイル／ディレクトリ／パーテションにより生成されたエンティティ）だけがアクセスをすることができる。一旦パスワードがうまくチェックされれば、すべての権利は与えられる。
制限されたリード・ライト：もしパスワード・チェックにうまくパスするならば、どんなエンティティに対してもリード・ライトアクセス権が与えられる
制限されたリード：もしパスワード・チェックにうまくパスするならば、どんなエンティティに対してもリードアクセス権が与えられる
リードオンリー：いかなるエンティティも、パスワードなしで読むことができる。
パブリック：どのようなエンティティにも、パスワードなしで、リード・ライトアクセス権を与えられる。

ＵＩＣＣのデータにアクセスすることができる、特定のユーザ及び／又は他のデバイス／装置のような、いかなるエンティティも、「ｅｎｔｉｔｙ＿ｉｄ」と呼ばれる一意の識別子と関連づけられている。この識別子は、好ましくは、ＭＥからのリクエストの際に、ＵＩＣＣによって割り当てられる。そして、「リクエスト／結果」構造は以下の通りとすることができる：
ＭＥからＵＩＣＣまで：Ｇｅｎｅｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｎａｍｅ）
ＵＩＣＣからＭＥまで：Ｇｅｎｅｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｎａｍｅ、ｅｎｔｉｔｙ＿ｉｄ）；

「ｅｎｔｉｔｙ＿ｎａｍｅ」は、ＵＩＣＣのデータにアクセスすることができるエンティティの、公的に入手可能な名前を示す。この特定の図解された例は、少なくとも、それらのそれぞれのｅｎｔｉｔｙ＿ｎａｍｅｓを有する次の一般エンティティが定義されることを示している：
−ユーザ（ＵＳＥＲ）
−携帯機器（ＭＥ）
−遠隔サーバ（ＲＥＭＯＴＥ＿ＳＥＲＶＥＲ）
−ＭＥ内のサードパーティのアプリケーション（ＭＥ＿ＴＨＩＲＤ＿ＰＡＲＴＹ）
勿論、リストは完全なものではなく、よって他のエンティティも含まれ得る。

「ｅｎｔｉｔｙ＿ｉｄ」は、ＵＩＣＣによって、所定の「ｅｎｔｉｔｙ＿ｎａｍｅ」に割り当てられるプライベートの識別子である。
「ｅｎｔｉｔｙ＿ｎａｍｅ」、「ｅｎｔｉｔｙ＿ｉｄ」の組は、ＭＥ内のメモリに保存され、ＭＥはこれらの組の守秘性を保証する。

都合のよいことに、リクエスト中のエンティティ（ＵＩＣＣのデータにアクセスしたがっているエンティティ）を正確に識別する責任がある。例えば、もしリクエストがＭＥアプリケーションからきているならば、ＭＥは、このドキュメントに定義されたインターフェース機能におけるＭＥと関連かあるｅｎｔｉｔｙ＿ｉｄを使用する。
ＭＥにとって、異なる要求中のエンティティを識別するための簡単な方法は、ＭＥオペレーティングシステムによって割り当てられる、それぞれスレッド又はプロセス識別子の使用に基づいていてもよい。
いくつかの動作は、直接このｅｎｔｉｔｙ＿ｉｄに依存しているため、ＵＩＣＣは、ＭＥから渡された「ｅｎｔｉｔｙ＿ｉｄ」は、正確であるという事実に頼ることができる。つまり、ＭＥからＵＩＣＣへのそのような正確な「ｅｎｔｉｔｙ＿ｉｄ」の供給は、この提案で定義したセキュリティ・メカニズムを強調することができる。

ファイル／ディレクトリ／パーテションが生成されるとき、ＵＩＣＣは、生成されたエレメントのために、「オーナー」の概念を結びつけることができる。その目的のために、ＵＩＣＣは、単にリクエスト生成機能でパスされる「ｅｎｔｉｔｙ＿ｉｄ」を取り、生成されたエレメントのオーナーｅｎｒｉｔｙ＿ｉｄとして、それを保存する。
多くのオペレーションは、ファイル／ディレクトリ／パーテションのオーナーである場合にのみ許可される（例えば、上述のようにプライベートドメインと定義されたエレメントは、オーナーからしかアクセスすることができない）。このため、このオーナーシップの考えは重要であると証明することができる。

いろいろなセキュリティ・インターフェース機能を採用することができる。
第１には、エンティティがその自身のファイル／ディレクトリ／パーテションのためにだけこの機能を使用することができるセッティング・パスワード機能がある。リクエストを受けたとき、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄとマッチしなかったとＵＩＣＣが認識すれば、リクエストは拒絶され、「リクエスト／結果」構造は、以下の通りとなる：

ＭＥからＵＩＣＣまで： Ｓｅｔ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、パスワード）
ＵＩＣＣからＭＥまで： Ｓｅｔ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

有利にオーナーのパーテション／ディレクトリ／ファイルだけが、リクエストの実行を許可されることができるように、ｅｎｔｉｔｙ＿ｉｄは提供される。パス名は、パーテション／ディレクトリ／ファイルの名前を含むパスを有する。そして、パスワードは、パーテション／ディレクトリ／ファイルに設定されるパスワードを有する。最終結果は、成功か失敗のいずれかである。

パスワード変更機能は、エンティティにより使用可能であるが、それ自身のファイル／ディレクトリ／パーテションのためだけである。
リクエストを受け取ったとき、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄにマッチしないとＵＩＣＣが認識した場合、リクエストは拒絶されて、以下の「リクエスト／結果」構造となる。

ＭＥからＵＩＣＣまで： Ｃｈａｎｇｅ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、ｏｌｄ＿ｐａｓｓｗｏｒｄ、ｎｅｗ＿ｐａｓｓｗｏｒｄ）
ＵＩＣＣからＭＥまで：Ｃｈａｎｇｅ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

パーテション／ディレクトリ／ファイルの現在のパスワードを有するｏｌｄ＿ｐａｓｓｗｏｒｄと、パーテション／ディレクトリ／ファイルに設定される予定の新しいパスワードを含むｎｅｗ＿ｐａｓｓｗｏｒｄと共に、上述のそれらに対する同様なパラメータが採用される。

パスワード検証機能のためのリクエスト／結果構造は、以下のようにすることができる。

ＭＥからＵＩＣＣまで： Ｖｅｒｉｆｙ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、パスワード）
ＵＩＣＣからＭＥまで： Ｖｅｒｉｆｙ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

１例として、ひとつの任意の保護されたエレメント（ファイル、ディレクトリ、またはパーテション）に対する、各エンティティに対するパスワード検証のための「試み」の数は、３つに限られる。３つの試みが失敗した後、エレメントに対するアクセス条件が変更される（例えば、このエレメントのオーナーが変更するか、パスワードを消去するか）まで、エレメントはもはや、これらの試みを行ったエンティティにアクセスすることができない。

エンティティがそれ自身のファイル／ディレクトリ／パーテションのためにだけ「セットドメイン」機能を使用することができるよう構成することが可能である。ＵＩＣＣが、リクエストを受け取って、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄとマッチしないと認識した場合、当該リクエストは拒絶され、「リクエスト／結果」構造は以下の通りになる。

ＭＥからＵＩＣＣまで： Ｓｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、領域）
ＵＩＣＣからＭＥまで： Ｓｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

得られるドメイン機能は、以下の「リクエスト／結果」構造として提供することができる。

ＭＥからＵＩＣＣまで：Ｇｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名）
ＵＩＣＣからＭＥまで： Ｇｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名、領域）

さらに、アクセス状態通知機能は、以下の、対応する構造として提供することができる。

ＵＩＣＣからＭＥまで： Ａｃｃｅｓｓ＿Ｃｏｎｄｉｔｉｏｎ＿Ｎｏｔｉｆｉｃａｔｉｏｎ（ｅｎｔｉｔｙ＿ｉｄ、パス名、状態）

上述したこれらに対する同様なパラメータが、パス名（例えば、パスワードを必要とする）によって示されたエレメントのために検証される必要がある状態を有する状態パラメータを付加して採用される。

１つのエンティティ識別子生成機能は、以下の「リクエスト／結果」構造と共に提供され得る。
ＭＥからＵＩＣＣまで： Ｇｅｎｅ ｎｏｔｅｄ ａｂｏｖｅ ｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｎａｍｅ）
ＵＩＣＣからＭＥまで： Ｇｅｎｅｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｎａｍｅ、ｅｎｔｉｔｙ＿ｉｄ）；

関連したパラメータについては、前に述べたように、ｅｎｔｉｔｙ＿ｎａｍｅは、エンティティのパブリックネームを含み、ｅｎｔｉｔｙ＿ｉｄは、各エンティティ名ごとに、ＵＩＣＣによって割り当てられた一意の識別子を有する。

本発明の本実施の形態の更なる面の例として、下記は本発明の実施の例で、上述した「可能性がある領域」を示す。

先ず、ユーザが写真を撮り、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１．ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」領域は、「制限されたリード・ライト」として定義される。「ｄｉｒｅｃｔｏｒｙ１」と「ｉｍａｇｅ１．ｊｐｇ」は、パスワードによって保護されていない。
ユーザ又は他のどのエンティティも、「ｉｍａｇｅ１．ｊｐｇ」ファイルにアクセスすることは問わないが、唯一の条件として、「ｐａｒｔｉｔｉｏｎ１」のパスワードを知っている必要がある。

第２の例として、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１．ｊｐｇ」に保存する。 「ｐａｒｔｉｔｉｏｎ１」と「ｄｉｒｅｃｔｏｒｙ１」領域は、パブリック（したがって、パスワードは必要なし）と定義される。「ｉｍａｇｅ１．ｊｐｇ」は、パスワードによって保護される（ドメイン「制限されたリード」）。
ユーザ又は他のどのエンティティも「ｉｍａｇｅ１．ｊｐｇ」ファイルをリードすることは問わないが、唯一の条件として、「ｉｍａｇｅ１．ｊｐｇ」のパスワードを知っている必要がある。

第３の例に、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１．ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」領域は、プライベートと定義される。「ｄｉｒｅｃｔｏｒｙ１」と「ｉｍａｇｅ１．ｊｐｇ」は、パスワードによって保護されていない。

ユーザ又は他のどのエンティティも、「ｉｍａｇｅ１．ｊｐｇ」ファイルにアクセスするのは問わないが、ユーザだけが続くパスワード検証に成功した後にファイルにアクセスすることができる。たとえ正しいパスワードを知っていても、他のどのエンティティもこのファイルにアクセスすることができない（そのｅｎｔｉｔｙ＿ｉｄがオーナーｅｎｔｉｔｙ＿ｉｄと一致しないため）。

第４の例として、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１．ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」、「ｄｉｒｅｃｔｏｒｙ１」、「ｉｍａｇｅ１．ｊｐｇ」ドメインは、「リードオンリー」と定義される。

この例における最初の動作としては、ユーザ又は他のどのエンティティであっても「ｉｍａｇｅ１．ｊｐｇ」ファイルを読むことができ、そして、ファイルを読むためにパスワードを要求されないため、ファイルに直接アクセスすることができる。

しかしながら、第２の動作として、ユーザ又は他のどのエンティティでも「ｉｍａｇｅ１．ｊｐｇ」ファイルを更新するのは問わないが、オーナー（ユーザー）のみが続くパスワード検証に成功した後で、ファイルにアクセスすることができる。

上記の内容から分かるように、本発明は、将来のＵＩＣＣ−ＭＥ間の大きなデータのやり取りが主にＵＳＢインターフェースを介して行われるという事実をすぐに考慮することができる。したがって、上述の例は、ＵＳＢとＥＥＭ（Ｅｔｈｅｒｎｅｔ（登録商標）Ｅｍｕｌａｔｉｏｎ Ｍｏｄｅ）インターフェース・クラスをサポートしているＭＥ−ＵＩＣＣインターフェースに実装することを目的としている。しかし、この課題解決の方法は、スマートカードＣＣＩＤ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ（ｓ） Ｃａｒｄｓ Ｉｎｔｅｒｆａｃｅ Ｄｅｖｉｃｅ）のような他のＵＳＢインターフェース・クラスについて適用されることもできる。

このことについては、ＵＳＢパケットは、ＥＥＭ ＰａｃｋｅｔがＵＳＢパケットのペイロードを有するフォーマットを有することから理解されるべきである。ＥＥＭパケット自体が、ＥＥＭ ＤａｔａかＥＥＭ Ｃｏｍｍａｎｄフォーマットとして定義されたフォーマットを有している。

ＥＥＭ ＣｏｍｍａｎｄパケットがローカルＵＳＢリンク管理として使用され、したがって、ＵＳＢデバイス・ドライバ層を超えることができない。したがって、これら説明した例の規定のインターフェース機能は、ＥＥＭ Ｄａｔａタイプパケットのペイロード部分に要約されます。

上記したように、Ｅｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓに基づく現在のファイルシステムには若干の限界があるのに対し、大きなサイズ／マルチメディア・データのサポートを強化するために、本発明は、データストレージを向上することに役立つ特徴も含む。本発明は、大部分の既存のＥｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓファイルシステムを標準的なファイル形式ファイルシステムと取り替えることを目的とする。

その目的のために、特定にＭＥ−ＵＩＣＣインターフェース機能は、ＭＥに、ＵＩＣＣの中で、パーテション／ディレクトリ／ファイルを生成して管理することを許可するために定義されている。

そのようなＭＥ−ＵＩＣＣ機能の例は、以下で概説される。

（パーテションまたはディレクトリまたはファイルを生成する）Ｃｒｅａｔｉｏｎ機能は、以下の「リクエスト／結果」構造と関連する。

ＭＥからＵＩＣＣまで：Ｃｒｅａｔｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、ｅｌｅｍｅｎｔ＿ｔｙｐｅ、パス名、ｅｌｅｍｅｎｔ＿ｐａｒａｍｅｔｅｒｓ）
ＵＩＣＣからＭＥまで：Ｃｒｅａｔｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名、ａｄｄｉｔｉｏｎａｌ＿ｉｎｆｏ）

その中で使用されるパラメータは、以下の通りに定められる。
−ｅｎｔｉｔｙ＿ｉｄ：「Ｃｒｅａｔｉｏｎリクエスト」を送信したエンティティを示す
−ｅｌｅｍｅｎｔ＿ｔｙｐｅ：パーテションまたはディレクトリまたはファイル
−パス名：生成されるエレメントの「パス＋名前」を含む；例えば／パーテション／ｇｌｏｂａｌ＿ｄｉｒｅｃｔｏｒｙ／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１．ｊｐｇ
−ｅｌｅｍｅｎｔ＿ｐａｒａｍｅｔｅｒｓ：所定のエレメントタイプに特有のパラメータ；例えばパーテションの場合のサイズ、ファイルの場合のファイルタイプ、など… ）
−結果（ｒｅｓｕｌｔ）：リクエスト実行結果を含む（成功、失敗、修正して成功 … ）
−ａｄｄｉｔｉｏｎａｌ＿ｉｎｆｏ：ＵＩＣＣが単純な実行結果より多くの情報を送るとき、このパラメータ（例えばＵＩＣＣがリクエストされたものと異なるサイズでパーテションをつくる場合に備えて）に、これらの追加のデータが含まれる

（パーテションまたはディレクトリまたはファイルを読むための）採用されるＲｅａｄ機能は、以下のリクエスト／結果構造と関係する。

ＭＥからＵＩＣＣまで： Ｒｅａｄ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名）
ＵＩＣＣからＭＥまで： Ｒｅａｄ＿Ｅｌｅｍｅｎｔ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名、データ）
そして、ここでは、パラメータは以下のように定義される：

−ｅｎｔｉｔｙ＿ｉｄ：読み出しリクエストを送信したエンティティを示す
−パス名：読み出されるエレメントの（パス＋名前）を含む
−結果：エレメントの読み出し結果（成功または失敗）
−データ：読み出されたエレメントを含む（例えば、ファイルが生成された場合における、読み出された「パーテション／ディレクトリまたは内容自体」のディレクトリとファイルのリストなど）

Ｕｐｄａｔｅ機能は提供されるが、ファイルと以下のリクエスト／結果構造に関するもののためだけに定義される。

ＭＥからＵＩＣＣまで： Ｕｐｄａｔｅ＿Ｆｉｌｅ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、ｄａｔａ＿ｔｙｐｅ、データ）
ＵＩＣＣからＭＥまで： Ｕｐｄａｔｅ＿Ｆｉｌｅ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

ここでは、パラメータは以下から成る：
−ｅｎｔｉｔｙ＿ｉｄ：更新リクエストを送ったエンティティを示す
−パス名：アップデートされるファイルの「パス＋名前」を含む。例えば「／パーテション／ｇｌｏｂａｌ＿ｄｉｒｅｃｔｏｒｙ／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１．ｊｐｇ」など
−ｄａｔａ＿ｔｙｐｅ：生成されたファイルのデータのタイプ（例えばｊｐｇ、ＭＰＥＧ、ｔｘｔ、その他）を示す
−データ：ファイルの内容
−結果：更新されたファイルの結果（成功または失敗）

Ｒｅｎａｍｅ機能は、以下のリクエスト／結果構造に関連することができる。

ＭＥからＵＩＣＣまで： Ｒｅｎａｍｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、ｏｌｄ＿ｐａｔｈｎａｍｅ、ｎｅｗ＿ｎａｍｅ）
ＵＩＣＣからＭＥまで： Ｒｅｎａｍｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、ｎｅｗ＿ｐａｔｈｎａｍｅ）
そして、パラメータは以下のように定義される：

−ｅｎｔｉｔｙ＿ｉｄ：名前変更リクエストを送ったエンティティを示す
−ｏｌｄ＿ｐａｔｈｎａｍｅ：名前を変えられたエレメントの元の「パス＋名前」を含む
−ｎｅｗ＿ｎａｍｅ：名前を変えられたエレメントの新しい名前（経路はなし）を含む
−結果：名前変更実行結果（成功または失敗）
−ｎｅｗ＿ｐａｔｈｎａｍｅ：名前を変更されたエレメントｍｐ「パス＋新しい名前」を含む

Ｍｏｖｅ機能は、次のように具現化される
ＭＥからＵＩＣＣまで：Ｍｏｖｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、ｏｌｄ＿ｐａｔｈｎａｍｅ、ｎｅｗ＿ｐａｔｈｎａｍｅ）
ＵＩＣＣからＭＥまで：Ｍｏｖｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、ｎｅｗ＿ｐａｔｈｎａｍｅ）

そして、以下のパラメータ定義で定義される
−ｅｎｔｉｔｙ＿ｉｄ： 動きリクエストを送信したエンティティを示す
−ｏｌｄ＿ｐａｔｈｎａｍｅ： 動かされたエレメントの古い「パス＋名前」を含む
−ｎｅｗ＿ｐａｔｈｎａｍｅ： 動かされたエレメントの新しい「パス＋名前」を含む
−結果：動き実行結果（成功または失敗）

Ｄｅｌｅｔｅ機能は、例えばリクエスト／結果構造に従って同様に提供されることができる
ＭＥからＵＩＣＣまで：Ｄｅｌｅｔｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名）
ＵＩＣＣからＭＥまで：Ｄｅｌｅｔｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

パラメータは、以下のように定義されることができる
−ｅｎｔｉｔｙ＿ｉｄ：削除リクエストを送信したエンティティを示す
−パス名： 削除されるエレメントの「パス＋名前」を含む
−結果： 削除実行結果（成功または失敗）

なお、パス名が、保護されている、ある親ディレクトリを含む場合、これらのディレクトリのアクセス条件は、このリクエストを処理する前に、最初に満たされなければならない点に留意する必要がある。

Ｃｌｅａｎｉｎｇ機能は、オーナーが関連するパスワードを失った／忘れた場合（したがって、パーテション／ディレクトリ／ファイルにおけるいかなるデータにもアクセス不可）に、パーテション／ディレクトリ／ファイルを削除するために提供され、役立つこともできる。
パーテション／ディレクトリ／ファイルのオーナーだけが、この動作を実行することができる。
ＵＩＣＣは、ｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄと一致し、以下のような「リクエスト／結果」構造に関係することをチェックしなければならない。

ＭＥからＵＩＣＣまで：Ｃｌｅａｎ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名）
ＵＩＣＣからＭＥまで：Ｃｌｅａｎ＿Ｅｌｅｍｅｎｔ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）

そして、パラメータは、以下のように定義されることができる：
−ｅｎｔｉｔｙ＿ｉｄ：オーナーだけが、このリクエストを獲得することができる。
−パス名：クリーニング（すなわち削除される）エレメントの「パス＋名前」を含む
−結果：クリーニングリクエスト結果（成功または失敗）

更なる機能は、例えば、リサイズパーテションに関して、以下の「リクエスト／結果」構造で提供されることもできる。

ａ）リサイズパーテション
ＭＥからＵＩＣＣまで： Ｒｅｓｉｚｅ＿Ｐａｒｔｉｔｉｏｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、名前、ｎｅｗ＿ｓｉｚｅ）
ＵＩＣＣからＭＥまで： Ｒｅｓｉｚｅ＿Ｐａｒｔｉｔｉｏｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、ｎｅｗ＿ａｌｌｏｃａｔｅｄ＿ｓｉｚｅ）

関連するパラメータは、以下のように定義されることができる：
−ｅｎｔｉｔｙ＿ｉｄ：リサイズリクエストを送信したエンティティを示す
−名前：パーテションの名前
−ｎｅｗ＿ｓｉｚｅ：パーテションのために新しく要求されたメモリサイズを含む
−結果：リサイズパーテションの結果（成功、失敗、修正して成功（例えば、割り当てられたサイズがリクエストされたサイズと異なる場合）
−ｎｅｗ＿ａｌｌｏｃａｔｅｄ＿ｓｉｚｅ：パーテションによってＵＩＣＣにより割り当てられた実際のメモリサイズを表わす

これらのインターフェース機能は、必要に応じて組合せて提供されることは勿論である。

さて、図３に戻って、図１のＵＩＣＣ１０のメモリ記憶装置内に生成されたディレクトリを生成するための信号のシーケンスに関する信号伝達のタイミングチャートを示す。

信号のシーケンスは、エンド・ユーザ２６、例えば携帯電話機等のＭＥ２８、及び図１のＵＩＣＣ１０のようなＵＩＣＣ３０の間で発生するものである。

図３に図示されるシーケンスは、既存のパーテション／ディレクトリにおけるディレクトリの生成のために、ユーザ２６からのリクエスト３２により発生し、そして、パスワード名、ドメイン及びパスワードを含む適切なリクエスト動作３４がＭＥ２８に送られる。

もし、ドメインが「パブリック」であるとして要求されれば、ユーザ２６はパスワードをディレクトリに設定せず、よって「パスワード」パラメータは空文字列となる。

次に、ＭＥ２８がＵＩＣＣ３０に、ｅｎｔｉｔｙ＿ｉｄ、ｅｌｅｍｅｎｔ＿ｔｙｐｅ、パス名、及びｅｌｅｍｅｎｔ＿ｐａｒａｍｅｔｅｒｓを含むＣｒｅａｔｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑｕｅｓｔ３６を渡す。

本例において、ディレクトリ「ｅｌｅｍｅｎｔ＿ｔｙｐｅ」の生成では、「ディレクトリ」、及び「ｅｌｅｍｅｎｔ＿ｐａｒａｍｅｔｅｒｓ」は、ヌル値を有することに注意すべきである。

続く信号伝達の経過は、パスワード検証シーケンス３８を含む。これは、親ディレクトリに関連するが、親ディレクトリがパスワードによって保護されていない場合は要求されない。ただし、保護されている複数のディレクトリのレベルがある場合は、各ディレクトリに対するパスワードは検証されなければならない。

パスワード検証シーケンス３８は、親−ディレクトリ−パスを含み、そのうえパスワードが要求される状態を確かめる、ａｃｃｅｓｓ＿ｃｏｎｄｉｔｉｏｎ＿ｎｏｔｉｆｉｃａｔｉｏｎ信号４０により開始される。

ＭＥ２８からＭＥユーザ２６へ、パスワードが要求される通知４２が送られると、順に、ＭＥユーザ２６からＭＥ２８へパスワード４４が送り返され、次に、ＭＥ２８からＵＩＣＣ３０に、ｖｅｒｉｆｙ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ信号４６が送られる。ＵＩＣＣ３０は、次にＭＥ２８へ、ｖｅｒｉｆｙ＿ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ信号４８を送り、更なる信号伝達交換が、ＵＩＣＣ３０とＭＥ２８の間で行われる。ただし、もし、パスワード値がゼロであれば、このようなパスワード設定機能が生じ得ないことは当然であるが、この信号交換には、ｃｒｅａｔｅ＿ｅｌｅｍｅｎｔ結果信号５０、ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｑｕｅｓｔ信号５２、ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｓｕｌｔ信号５４、ｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ信号５６、及びｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ信号５８が含まれる。

シーケンスは、ＭＥ２８からユーザ２６に、生成ディレクトリ結果信号６０が送られて終了する。

比較として、本発明における本実施例の特徴の更なる詳細が図４に示される。図４は、ファイル生成に関して生成される信号のシーケンスを示す。

信号伝達もまた、ユーザ２６、ＭＥ２８、及びＵＩＣＣ３０に関して示される。

この例では、エンド・ユーザがＭＥのカメラ機能を使用して写真を撮って、既存のパーテション／ディレクトリにその写真を保存することに決めて、ファイル生成リクエスト６４が、モバイル機器２８に送られる。これは、関連データに関するパス名、ドメイン、パスワード、及びｄａｔａ＿ｔｙｐｅを含むファイル・リクエスト６４を生成する。

その後、ＭＥ２８からＵＩＣＣ３０に、ｃｒｅａｔｅ＿ｅｌｅｍｅｎｔ＿ｔｙｐｅ６６が送られる。この中では、ファイルの生成のために、ｅｌｅｍｅｎｔ＿ｔｙｐｅに「ファイル」が設定され、ｅｌｅｍｅｎｔ＿ｐａｒａｍｅｔｅｒｓは、ＰＧまたはＭＰ３等のｆｉｌｅ＿ｔｙｐｅと、データすなわちファイルそれ自体の内容が含まれる。

もし、６８において、ファイルを生成するための場所に到着する前にパスワードによって保護されているディレクトリがあることが分かれば、例えば、図３に示したものを図４のシーケンスにも同様に適用する等して、各ディレクトリのパスワードは検証されなければならない。

つまり、ｃｒｅａｔｅ＿ｅｌｅｍｅｎｔ＿ｒｅｓｕｌｔ７０がＵＩＣＣ ３０からＭＥ２８に送られる。これに応じて、ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｑｕｅｓｔ信号７２がＵＩＣＣ３０に送られ、ＵＩＣＣ３０がｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｓｕｌｔｓ信号７４を開始する。ここで、パスワードがゼロ（ｎｕｌｌ）と設定されていないｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ ７６が、ＭＥ２８からＵＩＣＣ３０に送られるものとする。これに応じて、ｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ７８がＵＩＣＣ３０からＭＥ２８へ送られる。そして、ＭＥ２８とＵＩＣＣ３０の間のこの信号伝達交換７０−７８のシグナリング交換の最後に、生成されたファイル結果表示８０がＭＥ２８からエンド・ユーザ２６に提供される。

最後に図５及び図６について、保護されたファイルの読み出しを行おうとする場合に関する信号伝達図であって、正しいパスワードが使用される例（図５）と、比較として、アクセス条件が満たされない例（図６）をここに示す。

最初に図５において、適切なエンティティ２６が、ＭＥ２８に対し、当該エンティティが「制限されたリード」ドメインに規定されたファイルを読むことを望む、読み出しファイル８４を提供する目的で、８２において指示８２を準備する。読み出しファイル指示８４内のパス名は、例えば「／ｐａｒｔｉｔｉｏｎ ／ｄｉｒｅｃｔｏｒｙ Ｉ／ｐｉｃｔｕｒｅ １．ｊｐｇ」のような、読み出されるまでの特定のパスを含む。

続いて、ｒｅａｄ＿ｅｌｅｍｅｎｔ＿ｒｅｑｕｅｓｔ８６がＥ２８からＵＩＣＣ３０へ送られる。

図５に示す範囲内では、パスワード検証シーケンス８８が、ファイルそのものと、そのうえ、パスワードで保護されている、前のディレクトリに適用される。この場合、図５に示されているような信号伝達及び指示９０−９８を含むパスワード検証シーケンスが提供される。

最初に、ａｃｃｅｓｓ＿ｃｏｎｄｉｔｉｏｎ＿ｎｏｔｉｆｉｃａｔｉｏｎ信号９０がＵＩＣＣ３０からＭＥ２８へ送られる。次に、パスワード要求指示９２がＭＥ２８からエンティティ２６へ送られ、検証されたパスワードａｔｔｅｍｐｔ９４が戻され、次に、ＭＥ２８からＵＩＣＣ３０へｖｅｒｉｆｙ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ９６を開始する。

それから、検証ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ９８は、パスワード検証シーケンス８８を完了するため、ＵＩＣＣ３０からＭＥ２８へ送り返される。

パスワードは検証されて、要求されたデータを含む読み出しエレメント結果１００がＵＩＣＣ３０からＭＥ２８へ送られ、要求されたデータを含む読み出されたエレメント結果が要求を出しているエンティティ２６へ送られる（１０２）。

図６に戻って、１０４においてもう一つの異なるエンティティによって「プライベート」ドメインに定められるファイルを読むための、あるエンティティによる試みに関するシーケンスが例示される。読み出しファイル指示１０６はＭＥ２８に提供される。

それから、ＭＥ２８からＵＩＣＣ３０へｒｅａｄ＿ｅｌｅｍｅｎｔ＿ｒｅｑｕｅｓｔ１０８が送られる。このリクエストにおいては、当然のことながら、ｅｎｔｉｔｙ＿ｉｄは、ファイルオーナーｅｎｔｉｔｙ＿ｉｄと異なっている。

ＵＩＣＣ３０は、ファイルのドメインが「プライベート」ドメインを含み、したがって、ファイルのオーナーだけがファイルにアクセスすることができるとわかる。受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄにマッチしないので、ＵＩＣＣ３０からＭＥ２８に送られたｒｅａｄ＿ｅｌｅｍｅｎｔ＿ｒｅｓｕｌｔ１１０の中にあるリードリクエストは拒絶される。

それから、読み出しファイル結果指示１１２は、ＭＥ２８からリクエストを出しているエンティティ２６へ送られる。そして、その中のデータ・パラメータがゼロ（ｎｕｌｌ）であり、結果は、読み出し失敗を示す。

本発明が前述の具体化の詳細に限られていないことは勿論である。

ＵＳＢスマートカードＩＣＣＤインターフェース・クラスで動作するアプリケーションのための実装（本明細書で説明したのと同様の特徴をサポートしている新しいＡＰＤＵコマンドの生成が含まれる）は、はっきりと記述されないが、上述したことと同じ特徴を、ＩＣＣＤクラス等に適用することができる。

また、ＵＳＢ大容量記憶装置インターフェース・クラスをサポートしているＵＩＣＣを含むシナリオとして、あるエンティティ（例えばＭＥ）によってデータ・エレメントが保存され、そのようなＵＩＣＣがパスワード検証なしでアクセスできると、すなわち、データ・エレメント自体及びその親データ・エレメントに対してパスワードを要求されないと、ＵＩＣＣがＵＳＢ大量の記憶装置のように構成され動作し、ＰＣのようなデバイスに接続された時、このデータ・エレメントもまたアクセス可能とするべきである。

ＵＩＣＣがＵＳＢ大量の記憶装置として構成され、パスワード検証プロセスをサポートしないデバイスに接続されているときは、パスワードで保護されているデータ・エレメントは、アクセスできない状態のままとしなければならない。

すなわち、より詳細には、ＵＩＣＣが、具体的にＵＳＢ大量の記憶装置のように構成され、例えばＰＣのような遠隔装置に接続される場合は、ＵＩＣＣは、シンプルなＵＳＢメモリースティックのように振る舞うことができる。それから、パスワードなしで、すなわち上で概説される「パブリック」ドメインのように、ＭＥまたは実際に他のいずれの装置によって保存されたＵＩＣＣの上のデータ・エレメントは、ＰＣ上でアクセスできる状態のままでなければならない。

しかし、パスワードによって保護されているデータ・エレメントのために、ＵＩＣＣが、メモリースティックのように振る舞い、ＰＣに接続されているとき、それらはアクセスできない状態にある。

たとえば、ユーザが、ＭＥのカメラを使って写真を撮って、パスワードなしでＵＩＣＣ内に保存する。それからユーザがＵＩＣＣをＰＣに電気アダプターを介して接続するとき、ＵＩＣＣは、ＵＳＢメモリースティックのように振る舞い、この写真はＰＣ上でアクセス可能となる。しかし、ユーザがパスワードと共にこの写真を保存すれば、ＵＩＣＣがＰＣと接続されても、この写真は見ることができない。

１０ ＵＩＣＣ
１２ 処理機能
１４ 記憶領域
１６ インターフェース
１８ 携帯電話機
２０ プロセッサ
２２ スタンダード・メモリ
２４ 送信／受信機能
２９ ユーザ
２８ ＭＥ
３０ ＵＩＣＣ
３２ リクエスト
３４ 適切なリクエスト動作
３６ Ｃｒｅａｔｅ＿Ｅｌｅｍｅｎｔ＿Ｒｅｑｕｅｓｔ
３８ パスワード検証シーケンス８
４０ ａｃｃｅｓｓ＿ｃｏｎｄｉｔｉｏｎ＿ｎｏｔｉｆｉｃａｔｉｏｎ信号
４６ ｖｅｒｉｆｙ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ信号
４８ ｖｅｒｉｆｙ＿ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ信号
５０ ｃｒｅａｔｅ＿ｅｌｅｍｅｎｔ結果信号
５２ ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｑｕｅｓｔ信号
５４ ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｓｕｌｔ信号
５６ ｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ信号
６０ 生成ディレクトリ結果信号
６４ ファイル生成リクエスト
６６ ｃｒｅａｔｅ＿ｅｌｅｍｅｎｔ＿ｒｅｑｕｅｓｔ
７０ ｃｒｅａｔｅ＿ｅｌｅｍｅｎｔ＿ｒｅｓｕｌｔ
７２ ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｑｕｅｓｔ信号
７４ ｓｅｔ＿ｄｏｍａｉｎ＿ｒｅｓｕｌｔｓ信号
７６ ｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ
７８ ｓｅｔ＿ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ
８０ ファイル結果徴候
８２ ａｔ２における指示
８４ 読み出しファイル指示
８６ ｒｅａｄ＿ｅｌｅｍｅｎｔ＿ｒｅｑｕｅｓｔ
９０ ａｃｃｅｓｓ＿ｃｏｎｄｉｔｉｏｎ＿ｎｏｔｉｆｉｃａｔｉｏｎ信号
９２ パスワードリクエスト指示
９４ 検証パスワード試み
９６ ｖｅｒｉｆｙ＿ｐａｓｓｗｏｒｄ＿ｒｅｑｕｅｓｔ
９８ 検証ｐａｓｓｗｏｒｄ＿ｒｅｓｕｌｔ
１００ 読み出しエレメント結果
１０２ 届けられる
１０６ 読み出しファイル指示
１０８ ｒｅａｄ＿ｅｌｅｍｅｎｔ＿ｒｅｑｕｅｓｔ
１１０ ｒｅａｄ＿ｅｌｅｍｅｎｔ＿ｒｅｓｕｌｔ
１１２ 読み出しファイル結果指示

Claims (20)

1. 複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、
   データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、
   前記複数のデータ・エレメントのうち少なくとも１つは、前記ドメイン保護エレメント及びパスワード保護エレメントと関連し、
   前記少なくとも１つのデータ・エレメントに対して前記許可された動作の開始にはパスワードが要求され、当該動作は、前記ドメイン保護エレメントにより定義されているデータ保護方法。
2. 前記回路カードの１以上のアプリケーションにアクセスするためにＰＩＮコードを使用する請求項１記載のデータ保護方法。
3. 前記複数のデータ・エレメントのそれぞれは、前記ドメイン保護エレメントに関連する請求項１又は２記載のデータ保護方法。
4. 前記許可された動作は、１以上のリード及び／ライト動作を含む前記ドメイン保護エレメントによって定義されたものである請求項１記載のデータ保護方法。
5. 前記回路カードでデータにアクセスすることができるエンティティは、一意の識別子に関連している請求項１記載のデータ保護方法。
6. 更に、前記データ・エレメントを生成するエンティティの識別子が保存されている請求項５に記載のデータ保護方法。
7. 前記回路カードは、前記データ・エレメントの前記エンティティの識別子を保存するために配置される請求項５又は６記載のデータ保護方法。
8. ＭＥの中で、前記データへのアクセスを要求するエンティティを識別する請求項５から７のいずれか１項に記載のデータ保護方法。
9. 前記データ保護は、ＵＳＢインターフェースがＭＥと前記回路カードとの間で起動された時、ＵＳＢインターフェース・クラスに適用される請求項１記載のデータ保護方法。
10. 前記回路カード上の前記データ・エレメントが、スタンダードファイルフォーマットファイルにしたがって保存される請求項１に記載のデータ保護方法。
11. 前記回路カード内の前記データ・エレメントの生成及び管理は、ＭＥ経由で制御されている請求項１に記載のデータ保護方法。
12. ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能を有する請求項１記載のデータ保護方法。
13. 前記回路カードは、ＵＩＣＣを有する請求項１から１２のいずれか１項記載のデータ保護方法。
14. 複数の保護可能なデータ・エレメントが保存された回路カードであって、
    データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに関連して配置された、少なくとも１つの前記複数の保護可能なデータ・エレメントを有し、前記ドメイン保護エレメントによる許可された動作を開始するために、パスワードが要求される回路カード。
15. 前記複数のデータ・エレメントのそれぞれは、ドメイン保護エレメントに関連している請求項１４に記載の回路カード。
16. 前記回路カードは、ＵＳＢインターフェース・クラスを経由して前記データ・エレメントにアクセスを許可するように構成される請求項１４又は１５記載の回路カード。
17. ＵＩＣＣを更に含んでいる請求項１４から１６のいずれか１項に記載の回路カード。
18. 請求項１４から１７のいずれか１項に定義された回路カードで動作するよう構成された移動無線通信装置。
19. 前記移動無線通信装置は、ＵＳＢインターフェース・クラス経由で前記回路カードと通信するよう構成される請求項１８記載の移動無線通信装置。
20. 前記移動無線通信装置は、前記保存されているデータ・エレメントを生成及び／又は管理するよう構成される請求項１８又は１９記載の移動無線通信装置。

Images