回路カードデータ保護
本発明は、複数のデータ・エレメントの格納部が配置され、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに基づく保護を提供する、ＵＩＣＣのような回路カードにおいて保護を行う方法を提供するものである。そして、複数のデータ・エレメントのうち少なくとも１つは、ドメイン保護エレメント及びパスワード保護エレメントと関連し、本発明はさらに、そのようなデータ・エレメントの保護された記憶部が構成された回路カード及びそのような回路カードを採用するように構成されたＭＥを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、回路カードに関し、特に、配置、方法、及びそれらに記憶されるデータの保護に関する。
【背景技術】
【０００２】
機能の増加に伴い、携帯電話機及び携帯機器（ＭＥ：Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ）のための他のタイプのハンドヘルドデバイスは、ストレージ及び大量の（個人）データを保持するための一般的なデバイス／インターフェースとして普及している。
【０００３】
たとえば、そのようなデータは、個人的な写真、ビデオ、及びＳＭＳメッセージであり、ユーザは、一般的に、ＭＥ、例えばＳｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ（ＳＩＭ）カードのようなＵｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ（ＵＩＣＣ）の関連部分、又はネットワーク運営者により提供されるネットワークサイドストレージ、又はメモリカードのような他のメディア・デバイスの中に、そのようなデータを格納するオプションを有している。
【０００４】
格納されるデータの量と潜在的に個人的な／繊細な性質からみれば、エンド・ユーザの視点から、記憶領域は、十分な記憶容量、適切なセキュリティレベルを備えなければならず、更に利用しやすい状態でなければならない。
【０００５】
ＭＥそのものが、適切な保安の程度を提供すると考えられるが、そのようなレベルのセキュリティは、特定ＭＥ製造業者に限定されがちであり、ストレージ容量は、全てのタイプのユーザ・データ、特にマルチメディア・データのためには十分に考慮されない。データへ接続性も同様に、一般に、製造業者の特別なケーブルと、関連するソフトウェアの接続性を必要とする。
【０００６】
メモリカードのような装置が、大きな記憶容量と手早い接続性を提供することができる一方、ユーザ・データに対して保護するか、適当な保護を提供する手段がない。
【０００７】
勿論、アクセスの容易性は、保証とはかけ離れているかもしれないネットワーク・アクセスの利用可能性に依存するが、ネットワークサイドストレージ領域に関しては、十分な記憶容量と共に高度な安全対策を実現することができる。
【０００８】
近年の発展においては、ＵＩＣＣのような回路カードは、潜在的に魅力的な記憶領域を有している。例えば３ＧＰＰ／ＥＴＳＩ Ｒｅｌ-７からから開始された、高密度メモリをサポートしているＵＩＣＣが利用可能であり、同様な仕様で、単純なアダプターを経由して例えばＰＣ等へのデータ検索のような、ＵＩＣＣによる非常に簡単で高速にデータ変換するＵＩＣＣとＭＥ間の、ＵＳＢ２．０／ＵＳＢ ＩｎｔｅｒＣｈｉｐに基づく新しいインターフェースの供給が提案されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】国際公開公報ＷＯ２００８／１３９６１５
【特許文献２】米国特許公開公報２００８／２５４８３４
【特許文献３】米国特許公開公報２００８／２５６６２９
【特許文献４】米国特許公開公報２００８／１５５８３０
【発明の概要】
【発明が解決しようとする課題】
【００１０】
特に個人識別情報Ｎｏ．（ＰＩＮ）コードの使用によりＵＩＣＣは比較的セキュアであるとされているが、以下の点で限界が残っている。つまり、一旦ＰＩＮが検証されたら、単にユーザがＵＳＩＭ／ＧＳＭアプリケーションを起動したいときは、記憶されたユーザ・データは、更なるセキュリティチェックを要求されることなく自由にアクセスすることができてしまう。
【００１１】
つまり、たとえば、一旦ＭＥを起動し、正しいＰＩＮのエンティティを経由して使用してＵＳＩＭに適切にアクセスしたら、ＵＳＩＭに保存される他の全てのデータは、直ちにアクセス可能となり、特に、現在のエンド・ユーザが単に、ＭＥに一時的なアクセスをする目的であれば、適当でないかもしれない。
【００１２】
国際特許公開ＷＯ２００８／１５９６１５には、サービスの範囲の動的な変化を許可するメモリカード、アクセス・コントロールシステム、アクセスコントロール方法が記載されている。また、ダウンロードされる内容と関連した情報にしたがったアクセス管理の実行を通してのユーザに従う異なるサービスを提供し、そこでは、回路カードはデータ管理部を含み、カード上のデータを保護するためにセキュリティ・メカニズムの供給よりもむしろサービスの動的変化範囲に依存することが記載されている。
【００１３】
更に、米国特許公報２００８／２５４８３４、２００８／２５６６２９、及び２００８／１５５８３０には、それぞれ、ユーザ識別子の比較の提供を通して、コンテンツの安全なストレージを提示するメモリカードが記載されている。
【００１４】
本発明は、既存のカード及び方法に対し有利な点を有する回路カード、そしてそのようなカードを含むＭＥ、そのようなカードにおけるデータ保護方法を提供することを目的とする。
【００１５】
特に、本発明は、既存のカード及び方法に対し有利な点を有するＵＩＣＣ、及びそこでのセキュリティ及びデータを提供するための方法を提供するものとする。
【課題を解決するための手段】
【００１６】
本発明の一態様においては、複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、前記複数のデータ・エレメントのうち少なくとも１つは、前記ドメイン保護エレメント及びパスワード保護エレメントと関連する。
【００１７】
本発明は、１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全性を容易に強化することができて、実際、柔軟でかつすぐに適用可能な方法を提供することができる点で有利である。
【００１８】
したがって、そのような回路カードは、エンド・ユーザに、特に、そのような回路カードは、特に、ユーザの特有で慎重に扱うべきデータに対し、セキュリティ、能力、及びアクセス容易性において適切なレベルを有利に提供することができる。
【００１９】
それらが、データ・エレメントの保護、例えば、パーテション、ディレクトリ又はファイルのコンビネーションで提供される範囲で提供される場合、特に強化されたセキュリティのレベルが、上述した「パスワード」及び「ドメイン」の特徴のコンビネーションを通して提供される。「パスワード」特徴は、言わば、一度パスワードが検証されデータ・エレメントへのアクセスが許可されるような動作の本質から独立したものとして提供される。一方、「ドメイン」特徴は、前述のパーテション、ディレクトリ又はファイルなどのデータ・エレメントに許可される可能性があるオペレーション（動作）を定義する。
【００２０】
１つの特定の例に、回路カードは、ＵＩＣＣから成る。
【００２１】
さらにまた、セキュリティの付加的レベルが、回路カードの１つ以上のアプリケーションに対するＰＩＮアクセス・コードの使用を通して提供される。
【００２２】
好ましくは、上述の複数のデータ・エレメントの各々は、ドメイン保護エレメントと関係する。
【００２３】
更に好ましくは、許可された動作は、１以上のリード及び／ライト動作を含む前記ドメイン保護エレメントによって定義されたものである。
【００２４】
さらにまた、本発明の方法においては、回路カードにおいてデータにアクセスすることができるエンティティは、一意の識別子に関連している。
【００２５】
また、本方法は、データ・エレメントを生成するエンティティの識別子が保存されているものとすることができる。
【００２６】
さらに、そして、本発明を具体化した回路カードと共に使用するように構成されたＭＥに関し、当該方法は、ＭＥの中で、データへのアクセスを要求するエンティティを識別するものとすることができる。
【００２７】
好ましくは、データ保護ステップは、ＭＥと回路カードとの間のＵＳＢインターフェース・クラスに適用される
【００２８】
更に好ましくは、回路カード上のデータ・エレメントが、スタンダードファイルフォーマットファイルにしたがって保存される。
【００２９】
さらにまた、データ・エレメントの生成及び管理は、回路カード内のデータ・エレメントの生成及び管理によって行われ、また、ＭＥ経由で提供されることができる。
【００３０】
また、ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能を有する。
【００３１】
本発明の他の態様においては、複数の保護可能なデータ・エレメントが保存された回路カードであって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに関連して配置された、少なくとも１つの前記複数の保護可能なデータ・エレメントを有するものである。
【００３２】
好ましくは、回路カードは、ＵＩＣＣから成る。
【００３３】
また、少なくとも１つのデータ・エレメントは、ドメイン保護エレメントによる許可された動作を開始するために、パスワードが要求されるように構成することができる。
【００３４】
好ましくは、複数のデータ・エレメントのそれぞれは、ドメイン保護エレメントに関連している。
【００３５】
また、前述のオペレーション（動作）は、少なくとも１つのリード及び／又はライトアクセスオペレーションを含むドメイン保護エレメントによって定義されている。
【００３６】
好ましくは、回路カードは、ＵＳＢインターフェース・クラスを経由してデータ・エレメントにアクセスを許可するように構成される。
【００３７】
さらに、回路カードは、そのファイルシステムのスタンダードファイル内に保存されたデータ・エレメントを含むように構成される。
【００３８】
本発明は、さらに、上で定められるように、回路カードを受け取るように構成されたＭＥも提供することができる。
【００３９】
好ましくは、ＭＥは、ＵＳＢインターフェース・クラスを経由して回路カードと通信することができるように構成される。
【００４０】
更に好ましくは、上述の保存されたデータ・エレメントを生成及び／または管理が可能に構成されている。
【００４１】
好ましくは、ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能により定義されている。
【００４２】
本発明は、ほんの一例として以下の添付の図面を参照して、説明される。
【発明の効果】
【００４３】
本発明によれば、１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全の程度は、容易に強化されることができて、本当に、柔軟ですぐに適合できる方法とし提供される。
【図面の簡単な説明】
【００４４】
【図１】図１は、本発明の実施例におけるＵＩＣＣの略平面図である。
【図２】図２は、移動無線通信装置またはＭＥの略平面図であって、携帯電話機及び図１のＵＩＣＣで動作するようアレンジされた図である。
【図３】図３は、本発明にかかるＵＩＣＣにおけるディレクトリの生成に関連した信号伝達タイミングチャートである。
【図４】図４は、ＵＩＣＣ等のためのファイル生成のための信号伝達タイミングチャートである。
【図５】図５は、誤ったパスワードを用いて保護されたファイルを読もうとした場合の信号伝達タイミングチャートである。
【図６】図６は、正しいパスワードを用いて保護されたファイルを読みだす場合の信号伝達タイミングチャートである。
【発明を実施するための形態】
【００４５】
上記及び以下の特定の実施の形態の詳細な説明から明らかなように、本発明は、単純なＰＩＮコードに基づくデータ保護機構の提供に関係する現在の回路カードに見られる限界に対処するものである。前述のように、回路カードは、第１に、たとえばＧＳＭ／ＵＳＩＭ等のアプリケーション及びその関連データであるＩＭＳＩまたはＰＬＭＮリスト等に関連する。そして、回路カード内のデータ、例えば、同じセキュリティ体制下に移動された、例えばユーザの個人的なファイル、写真、ビデオ、個人的なメッセージなどは、そのようなアプリケーションのいずれにも直接接続されていない。
【００４６】
本発明は、回路カードに格納されるあらゆるタイプのデータに対して、強化したセキュリティのレベルを提供することを目的とし、必要とされるならば、既存のＰＩＮ保護に加えて使われることができるデータ保護メカニズムを定める。
【００４７】
また、回路カード内のデータ記憶装置は、一般的には、大量のデータの記憶に適していないＥｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓに基づいている。また、そのようなファイルは、ビデオや音楽のようなあるタイプのデータを記憶するために定義されないことがしばしばある。したがって、新しいデータ記憶配置が、本発明の一部として提案され、回路カードセキュリティ向上に関連した特別な用途が見つけられる。
【００４８】
最初に図１を参照すると、本発明が適切に具体化されている回路カードの１つの例の概略図が提供されている。
【００４９】
回路カードは、記憶領域１４とＭＥインターフェース１６の間に提供される処理機能１２を含むＵＩＣＣ１０を有する。
【００５０】
後述されるように、インターフェース１６は、ＵＳＰ２．０／ＵＳＰ ＩｎｔｅｒＣｈｉｐに有利に基づくものとすることができる。ＵＳＰ２．０／ＵＳＰ ＩｎｔｅｒＣｈｉｐは、たとえば、ＵＩＣＣ１０と、簡単な電気アダブタを介してＰＣと接続される図２の携帯電話機１８との間のデータ変換を簡便で高速化することができる。
【００５１】
図２に関して、例えば携帯電話機１８等の携帯機器（ＭＥ）のどんな形式も含む携帯無線通信デバイスの概略図が提供されている。携帯電話機１８は、内部に図１のＵＩＣＣ１０を備え、スタンダード・メモリ２２、プロセッサ２０、及び送信／受信機能部２４を備えている。
【００５２】
携帯電話機１８として提供されることができる様々なストレージオプションのうち、ＵＩＣＣ１０は、上述し、下記に詳細を記述するセキュリティエレメント領域及びセキュリティエレメントパスワードのコンビネーションに基づく、有利で保証された、高速アクセス可能な、適当に大きいデータの格納場所を提供することができる。
【００５３】
現在の説明と本発明の定義に関して、当然ながら、パスワードがチェックされとすぐに、オペレーションが許されるだろうことから独立して、「パスワード」は、ファイル／ディレクトリ／パーテションへのアクセスを保護する。これに対し、ドメインは、特定のエンティティが、ファイル／ディレクトリ／パーテション上で実行することができる異なるオペレーションを定義する。
【００５４】
したがって、１つの特定の例として、各データ・エレメント、例えばファイル、ディレクトリまたはパーテションでさえ、ドメインと関係することができ、パスワードによって保護されることができる（関連するドメインがパスワードを必要とする場合）。
許可されたオペレーションのそれぞれの定義を有するいろいろなドメインが提供されることができ、相互運用性（インターオペラビリティ）を可能とするために、一般に標準化された方法で提供される。
【００５５】
例として、可能性があるドメインは以下の通りである：
プライベート：オーナー（ファイル／ディレクトリ／パーテションにより生成されたエンティティ）だけがアクセスをすることができる。一旦パスワードがうまくチェックされれば、すべての権利は与えられる。
制限されたリード・ライト：もしパスワード・チェックにうまくパスするならば、どんなエンティティに対してもリード・ライトアクセス権が与えられる
制限されたリード：もしパスワード・チェックにうまくパスするならば、どんなエンティティに対してもリードアクセス権が与えられる
リードオンリー：いかなるエンティティも、パスワードなしで読むことができる。
パブリック：どのようなエンティティにも、パスワードなしで、リード・ライトアクセス権を与えられる。
【００５６】
ＵＩＣＣのデータにアクセスすることができる、特定のユーザ及び／又は他のデバイス／装置のような、いかなるエンティティも、「ｅｎｔｉｔｙ_ｉｄ」と呼ばれる一意の識別子と関連づけられている。この識別子は、好ましくは、ＭＥからのリクエストの際に、ＵＩＣＣによって割り当てられる。そして、「リクエスト／結果」構造は以下の通りとすることができる：
ＭＥからＵＩＣＣまで：Ｇｅｎｅｒａｔｅ_Ｅｎｔｉｔｙ_Ｉｄ_Ｒｅｑ（ｅｎｔｉｔｙ_ｎａｍｅ）
ＵＩＣＣからＭＥまで：Ｇｅｎｅｒａｔｅ_Ｅｎｔｉｔｙ_Ｉｄ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｎａｍｅ、ｅｎｔｉｔｙ_ｉｄ）;
【００５７】
「ｅｎｔｉｔｙ_ｎａｍｅ」は、ＵＩＣＣのデータにアクセスすることができるエンティティの、公的に入手可能な名前を示す。この特定の図解された例は、少なくとも、それらのそれぞれのｅｎｔｉｔｙ_ｎａｍｅｓを有する次の一般エンティティが定義されることを示している：
−ユーザ（ＵＳＥＲ）
−携帯機器（ＭＥ）
−遠隔サーバ（ＲＥＭＯＴＥ＿ＳＥＲＶＥＲ）
−ＭＥ内のサードパーティのアプリケーション（ＭＥ＿ＴＨＩＲＤ＿ＰＡＲＴＹ）
勿論、リストは完全なものではなく、よって他のエンティティも含まれ得る。
【００５８】
「ｅｎｔｉｔｙ＿ｉｄ」は、ＵＩＣＣによって、所定の「ｅｎｔｉｔｙ＿ｎａｍｅ」に割り当てられるプライベートの識別子である。
「ｅｎｔｉｔｙ＿ｎａｍｅ」、「ｅｎｔｉｔｙ＿ｉｄ」の組は、ＭＥ内のメモリに保存され、ＭＥはこれらの組の守秘性を保証する。
【００５９】
都合のよいことに、リクエスト中のエンティティ（ＵＩＣＣのデータにアクセスしたがっているエンティティ）を正確に識別する責任がある。例えば、もしリクエストがＭＥアプリケーションからきているならば、ＭＥは、このドキュメントに定義されたインターフェース機能におけるＭＥと関連かあるｅｎｔｉｔｙ＿ｉｄを使用する。
ＭＥにとって、異なる要求中のエンティティを識別するための簡単な方法は、ＭＥオペレーティングシステムによって割り当てられる、それぞれスレッド又はプロセス識別子の使用に基づいていてもよい。
いくつかの動作は、直接このｅｎｔｉｔｙ＿ｉｄに依存しているため、ＵＩＣＣは、ＭＥから渡された「ｅｎｔｉｔｙ_ｉｄ」は、正確であるという事実に頼ることができる。つまり、ＭＥからＵＩＣＣへのそのような正確な「ｅｎｔｉｔｙ＿ｉｄ」の供給は、この提案で定義したセキュリティ・メカニズムを強調することができる。
【００６０】
ファイル／ディレクトリ／パーテションが生成されるとき、ＵＩＣＣは、生成されたエレメントのために、「オーナー」の概念を結びつけることができる。その目的のために、ＵＩＣＣは、単にリクエスト生成機能でパスされる「ｅｎｔｉｔｙ＿ｉｄ」を取り、生成されたエレメントのオーナーｅｎｒｉｔｙ＿ｉｄとして、それを保存する。
多くのオペレーションは、ファイル／ディレクトリ／パーテションのオーナーである場合にのみ許可される（例えば、上述のようにプライベートドメインと定義されたエレメントは、オーナーからしかアクセスすることができない）。このため、このオーナーシップの考えは重要であると証明することができる。
【００６１】
いろいろなセキュリティ・インターフェース機能を採用することができる。
第１には、エンティティがその自身のファイル／ディレクトリ／パーテションのためにだけこの機能を使用することができるセッティング・パスワード機能がある。リクエストを受けたとき、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄとマッチしなかったとＵＩＣＣが認識すれば、リクエストは拒絶され、「リクエスト／結果」構造は、以下の通りとなる：
【００６２】
ＭＥからＵＩＣＣまで： Ｓｅｔ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、パスワード）
ＵＩＣＣからＭＥまで： Ｓｅｔ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００６３】
有利にオーナーのパーテション／ディレクトリ／ファイルだけが、リクエストの実行を許可されることができるように、ｅｎｔｉｔｙ＿ｉｄは提供される。パス名は、パーテション／ディレクトリ／ファイルの名前を含むパスを有する。そして、パスワードは、パーテション／ディレクトリ／ファイルに設定されるパスワードを有する。最終結果は、成功か失敗のいずれかである。
【００６４】
パスワード変更機能は、エンティティにより使用可能であるが、それ自身のファイル／ディレクトリ／パーテションのためだけである。
リクエストを受け取ったとき、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄにマッチしないとＵＩＣＣが認識した場合、リクエストは拒絶されて、以下の「リクエスト／結果」構造となる。
【００６５】
ＭＥからＵＩＣＣまで： Ｃｈａｎｇｅ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、ｏｌｄ＿ｐａｓｓｗｏｒｄ、ｎｅｗ＿ｐａｓｓｗｏｒｄ）
ＵＩＣＣからＭＥまで：Ｃｈａｎｇｅ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００６６】
パーテション／ディレクトリ／ファイルの現在のパスワードを有するｏｌｄ＿ｐａｓｓｗｏｒｄと、パーテション／ディレクトリ／ファイルに設定される予定の新しいパスワードを含むｎｅｗ＿ｐａｓｓｗｏｒｄと共に、上述のそれらに対する同様なパラメータが採用される。
【００６７】
パスワード検証機能のためのリクエスト／結果構造は、以下のようにすることができる。
【００６８】
ＭＥからＵＩＣＣまで： Ｖｅｒｉｆｙ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、パスワード）
ＵＩＣＣからＭＥまで： Ｖｅｒｉｆｙ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００６９】
１例として、ひとつの任意の保護されたエレメント（ファイル、ディレクトリ、またはパーテション）に対する、各エンティティに対するパスワード検証のための「試み」の数は、３つに限られる。３つの試みが失敗した後、エレメントに対するアクセス条件が変更される（例えば、このエレメントのオーナーが変更するか、パスワードを消去するか）まで、エレメントはもはや、これらの試みを行ったエンティティにアクセスすることができない。
【００７０】
エンティティがそれ自身のファイル／ディレクトリ／パーテションのためにだけ「セットドメイン」機能を使用することができるよう構成することが可能である。ＵＩＣＣが、リクエストを受け取って、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄとマッチしないと認識した場合、当該リクエストは拒絶され、「リクエスト／結果」構造は以下の通りになる。
【００７１】
ＭＥからＵＩＣＣまで： Ｓｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、領域）
ＵＩＣＣからＭＥまで： Ｓｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００７２】
得られるドメイン機能は、以下の「リクエスト／結果」構造として提供することができる。
【００７３】
ＭＥからＵＩＣＣまで：Ｇｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名）
ＵＩＣＣからＭＥまで： Ｇｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名、領域）
【００７４】
さらに、アクセス状態通知機能は、以下の、対応する構造として提供することができる。
【００７５】
ＵＩＣＣからＭＥまで： Ａｃｃｅｓｓ＿Ｃｏｎｄｉｔｉｏｎ＿Ｎｏｔｉｆｉｃａｔｉｏｎ（ｅｎｔｉｔｙ＿ｉｄ、パス名、状態）
【００７６】
上述したこれらに対する同様なパラメータが、パス名（例えば、パスワードを必要とする）によって示されたエレメントのために検証される必要がある状態を有する状態パラメータを付加して採用される。
【００７７】
１つのエンティティ識別子生成機能は、以下の「リクエスト／結果」構造と共に提供され得る。
ＭＥからＵＩＣＣまで： Ｇｅｎｅ ｎｏｔｅｄ ａｂｏｖｅ ｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｎａｍｅ）
ＵＩＣＣからＭＥまで： Ｇｅｎｅｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｎａｍｅ、ｅｎｔｉｔｙ＿ｉｄ）;
【００７８】
関連したパラメータについては、前に述べたように、ｅｎｔｉｔｙ_ｎａｍｅは、エンティティのパブリックネームを含み、ｅｎｔｉｔｙ_ｉｄは、各エンティティ名ごとに、ＵＩＣＣによって割り当てられた一意の識別子を有する。
【００７９】
本発明の本実施の形態の更なる面の例として、下記は本発明の実施の例で、上述した「可能性がある領域」を示す。
【００８０】
先ず、ユーザが写真を撮り、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」領域は、「制限されたリード・ライト」として定義される。「ｄｉｒｅｃｔｏｒｙ１」と「ｉｍａｇｅ１.ｊｐｇ」は、パスワードによって保護されていない。
ユーザ又は他のどのエンティティも、「ｉｍａｇｅ１.ｊｐｇ」ファイルにアクセスすることは問わないが、唯一の条件として、「ｐａｒｔｉｔｉｏｎ１」のパスワードを知っている必要がある。
【００８１】
第２の例として、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。 「ｐａｒｔｉｔｉｏｎ１」と「ｄｉｒｅｃｔｏｒｙ１」領域は、パブリック（したがって、パスワードは必要なし）と定義される。「ｉｍａｇｅ１.ｊｐｇ」は、パスワードによって保護される（ドメイン「制限されたリード」）。
ユーザ又は他のどのエンティティも「ｉｍａｇｅ１.ｊｐｇ」ファイルをリードすることは問わないが、唯一の条件として、「ｉｍａｇｅ１.ｊｐｇ」のパスワードを知っている必要がある。
【００８２】
第３の例に、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」領域は、プライベートと定義される。「ｄｉｒｅｃｔｏｒｙ１」と「ｉｍａｇｅ１.ｊｐｇ」は、パスワードによって保護されていない。
【００８３】
ユーザ又は他のどのエンティティも、「ｉｍａｇｅ１.ｊｐｇ」ファイルにアクセスするのは問わないが、ユーザだけが続くパスワード検証に成功した後にファイルにアクセスすることができる。たとえ正しいパスワードを知っていても、他のどのエンティティもこのファイルにアクセスすることができない（そのｅｎｔｉｔｙ_ｉｄがオーナーｅｎｔｉｔｙ_ｉｄと一致しないため）。
【００８４】
第４の例として、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」、「ｄｉｒｅｃｔｏｒｙ１」、「ｉｍａｇｅ１.ｊｐｇ」ドメインは、「リードオンリー」と定義される。
【００８５】
この例における最初の動作としては、ユーザ又は他のどのエンティティであっても「ｉｍａｇｅ１.ｊｐｇ」ファイルを読むことができ、そして、ファイルを読むためにパスワードを要求されないため、ファイルに直接アクセスすることができる。
【００８６】
しかしながら、第２の動作として、ユーザ又は他のどのエンティティでも「ｉｍａｇｅ１.ｊｐｇ」ファイルを更新するのは問わないが、オーナー（ユーザー）のみが続くパスワード検証に成功した後で、ファイルにアクセスすることができる。
【００８７】
上記の内容から分かるように、本発明は、将来のＵＩＣＣ−ＭＥ間の大きなデータのやり取りが主にＵＳＢインターフェースを介して行われるという事実をすぐに考慮することができる。したがって、上述の例は、ＵＳＢとＥＥＭ（Ｅｔｈｅｒｎｅｔ（登録商標） Ｅｍｕｌａｔｉｏｎ Ｍｏｄｅ）インターフェース・クラスをサポートしているＭＥ−ＵＩＣＣインターフェースに実装することを目的としている。しかし、この課題解決の方法は、スマートカードＣＣＩＤ（Integrated Circuit(s) Cards Interface Device）のような他のＵＳＢインターフェース・クラスについて適用されることもできる。
【００８８】
このことについては、ＵＳＢパケットは、ＥＥＭ ＰａｃｋｅｔがＵＳＢパケットのペイロードを有するフォーマットを有することから理解されるべきである。ＥＥＭパケット自体が、ＥＥＭ ＤａｔａかＥＥＭ Ｃｏｍｍａｎｄフォーマットとして定義されたフォーマットを有している。
【００８９】
ＥＥＭ ＣｏｍｍａｎｄパケットがローカルＵＳＢリンク管理として使用され、したがって、ＵＳＢデバイス・ドライバ層を超えることができない。したがって、これら説明した例の規定のインターフェース機能は、ＥＥＭ Ｄａｔａタイプパケットのペイロード部分に要約されます。
【００９０】
上記したように、Ｅｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓに基づく現在のファイルシステムには若干の限界があるのに対し、大きなサイズ／マルチメディア・データのサポートを強化するために、本発明は、データストレージを向上することに役立つ特徴も含む。本発明は、大部分の既存のＥｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓファイルシステムを標準的なファイル形式ファイルシステムと取り替えることを目的とする。
【００９１】
その目的のために、特定にＭＥ−ＵＩＣＣインターフェース機能は、ＭＥに、ＵＩＣＣの中で、パーテション／ディレクトリ／ファイルを生成して管理することを許可するために定義されている。
【００９２】
そのようなＭＥ-ＵＩＣＣ機能の例は、以下で概説される。
【００９３】
（パーテションまたはディレクトリまたはファイルを生成する）Ｃｒｅａｔｉｏｎ機能は、以下の「リクエスト／結果」構造と関連する。
【００９４】
ＭＥからＵＩＣＣまで：Ｃｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、ｅｌｅｍｅｎｔ_ｔｙｐｅ、パス名、ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓ）
ＵＩＣＣからＭＥまで：Ｃｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名、ａｄｄｉｔｉｏｎａｌ_ｉｎｆｏ）
【００９５】
その中で使用されるパラメータは、以下の通りに定められる。
−ｅｎｔｉｔｙ_ｉｄ：「Ｃｒｅａｔｉｏｎリクエスト」を送信したエンティティを示す
−ｅｌｅｍｅｎｔ_ｔｙｐｅ：パーテションまたはディレクトリまたはファイル
−パス名：生成されるエレメントの「パス＋名前」を含む；例えば／パーテション／ｇｌｏｂａｌ_ｄｉｒｅｃｔｏｒｙ／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ
−ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓ：所定のエレメントタイプに特有のパラメータ；例えばパーテションの場合のサイズ、ファイルの場合のファイルタイプ、など… ）
−結果（ｒｅｓｕｌｔ）：リクエスト実行結果を含む（成功、失敗、修正して成功 … ）
−ａｄｄｉｔｉｏｎａｌ_ｉｎｆｏ：ＵＩＣＣが単純な実行結果より多くの情報を送るとき、このパラメータ（例えばＵＩＣＣがリクエストされたものと異なるサイズでパーテションをつくる場合に備えて）に、これらの追加のデータが含まれる
【００９６】
（パーテションまたはディレクトリまたはファイルを読むための）採用されるＲｅａｄ機能は、以下のリクエスト／結果構造と関係する。
【００９７】
ＭＥからＵＩＣＣまで： Ｒｅａｄ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名）
ＵＩＣＣからＭＥまで： Ｒｅａｄ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名、データ）
そして、ここでは、パラメータは以下のように定義される：
【００９８】
−ｅｎｔｉｔｙ_ｉｄ：読み出しリクエストを送信したエンティティを示す
−パス名：読み出されるエレメントの（パス＋名前）を含む
−結果：エレメントの読み出し結果（成功または失敗）
−データ：読み出されたエレメントを含む（例えば、ファイルが生成された場合における、読み出された「パーテション／ディレクトリまたは内容自体」のディレクトリとファイルのリストなど）
【００９９】
Ｕｐｄａｔｅ機能は提供されるが、ファイルと以下のリクエスト／結果構造に関するもののためだけに定義される。
【０１００】
ＭＥからＵＩＣＣまで： Ｕｐｄａｔｅ_Ｆｉｌｅ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名、ｄａｔａ_ｔｙｐｅ、データ）
ＵＩＣＣからＭＥまで： Ｕｐｄａｔｅ_Ｆｉｌｅ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名）
【０１０１】
ここでは、パラメータは以下から成る：
−ｅｎｔｉｔｙ_ｉｄ：更新リクエストを送ったエンティティを示す
−パス名：アップデートされるファイルの「パス＋名前」を含む。例えば「／パーテション／ｇｌｏｂａｌ_ｄｉｒｅｃｔｏｒｙ／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」など
−ｄａｔａ_ｔｙｐｅ：生成されたファイルのデータのタイプ（例えばｊｐｇ、ＭＰＥＧ、ｔｘｔ、その他）を示す
−データ：ファイルの内容
−結果：更新されたファイルの結果（成功または失敗）
【０１０２】
Ｒｅｎａｍｅ機能は、以下のリクエスト／結果構造に関連することができる。
【０１０３】
ＭＥからＵＩＣＣまで： Ｒｅｎａｍｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、ｏｌｄ_ｐａｔｈｎａｍｅ、ｎｅｗ_ｎａｍｅ）
ＵＩＣＣからＭＥまで： Ｒｅｎａｍｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、ｎｅｗ_ｐａｔｈｎａｍｅ）
そして、パラメータは以下のように定義される：
【０１０４】
−ｅｎｔｉｔｙ_ｉｄ：名前変更リクエストを送ったエンティティを示す
−ｏｌｄ_ｐａｔｈｎａｍｅ：名前を変えられたエレメントの元の「パス＋名前」を含む
−ｎｅｗ_ｎａｍｅ：名前を変えられたエレメントの新しい名前（経路はなし）を含む
−結果：名前変更実行結果（成功または失敗）
−ｎｅｗ_ｐａｔｈｎａｍｅ：名前を変更されたエレメントｍｐ「パス＋新しい名前」を含む
【０１０５】
Ｍｏｖｅ機能は、次のように具現化される
ＭＥからＵＩＣＣまで：Ｍｏｖｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、ｏｌｄ_ｐａｔｈｎａｍｅ、ｎｅｗ_ｐａｔｈｎａｍｅ）
ＵＩＣＣからＭＥまで：Ｍｏｖｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、ｎｅｗ_ｐａｔｈｎａｍｅ）
【０１０６】
そして、以下のパラメータ定義で定義される
−ｅｎｔｉｔｙ_ｉｄ： 動きリクエストを送信したエンティティを示す
−ｏｌｄ_ｐａｔｈｎａｍｅ： 動かされたエレメントの古い「パス＋名前」を含む
−ｎｅｗ_ｐａｔｈｎａｍｅ： 動かされたエレメントの新しい「パス＋名前」を含む
−結果：動き実行結果（成功または失敗）
【０１０７】
Ｄｅｌｅｔｅ機能は、例えばリクエスト／結果構造に従って同様に提供されることができる
ＭＥからＵＩＣＣまで：Ｄｅｌｅｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名）
ＵＩＣＣからＭＥまで：Ｄｅｌｅｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名）
【０１０８】
パラメータは、以下のように定義されることができる
−ｅｎｔｉｔｙ_ｉｄ：削除リクエストを送信したエンティティを示す
−パス名： 削除されるエレメントの「パス＋名前」を含む
−結果： 削除実行結果（成功または失敗）
【０１０９】
なお、パス名が、保護されている、ある親ディレクトリを含む場合、これらのディレクトリのアクセス条件は、このリクエストを処理する前に、最初に満たされなければならない点に留意する必要がある。
【０１１０】
Ｃｌｅａｎｉｎｇ機能は、オーナーが関連するパスワードを失った／忘れた場合（したがって、パーテション／ディレクトリ／ファイルにおけるいかなるデータにもアクセス不可）に、パーテション／ディレクトリ／ファイルを削除するために提供され、役立つこともできる。
パーテション／ディレクトリ／ファイルのオーナーだけが、この動作を実行することができる。
ＵＩＣＣは、ｅｎｔｉｔｙ_ｉｄがオーナーのｅｎｔｉｔｙ_ｉｄと一致し、以下のような「リクエスト／結果」構造に関係することをチェックしなければならない。
【０１１１】
ＭＥからＵＩＣＣまで：Ｃｌｅａｎ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名）
ＵＩＣＣからＭＥまで：Ｃｌｅａｎ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名）
【０１１２】
そして、パラメータは、以下のように定義されることができる：
−ｅｎｔｉｔｙ_ｉｄ：オーナーだけが、このリクエストを獲得することができる。
−パス名：クリーニング（すなわち削除される）エレメントの「パス＋名前」を含む
−結果：クリーニングリクエスト結果（成功または失敗）
【０１１３】
更なる機能は、例えば、リサイズパーテションに関して、以下の「リクエスト／結果」構造で提供されることもできる。
【０１１４】
ａ）リサイズパーテション
ＭＥからＵＩＣＣまで： Ｒｅｓｉｚｅ_Ｐａｒｔｉｔｉｏｎ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、名前、ｎｅｗ_ｓｉｚｅ）
ＵＩＣＣからＭＥまで： Ｒｅｓｉｚｅ_Ｐａｒｔｉｔｉｏｎ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、ｎｅｗ_ａｌｌｏｃａｔｅｄ_ｓｉｚｅ）
【０１１５】
関連するパラメータは、以下のように定義されることができる：
−ｅｎｔｉｔｙ_ｉｄ：リサイズリクエストを送信したエンティティを示す
−名前：パーテションの名前
−ｎｅｗ_ｓｉｚｅ：パーテションのために新しく要求されたメモリサイズを含む
−結果：リサイズパーテションの結果（成功、失敗、修正して成功（例えば、割り当てられたサイズがリクエストされたサイズと異なる場合）
−ｎｅｗ_ａｌｌｏｃａｔｅｄ_ｓｉｚｅ：パーテションによってＵＩＣＣにより割り当てられた実際のメモリサイズを表わす
【０１１６】
これらのインターフェース機能は、必要に応じて組合せて提供されることは勿論である。
【０１１７】
さて、図３に戻って、図１のＵＩＣＣ１０のメモリ記憶装置内に生成されたディレクトリを生成するための信号のシーケンスに関する信号伝達のタイミングチャートを示す。
【０１１８】
信号のシーケンスは、エンド・ユーザ２６、例えば携帯電話機等のＭＥ２８、及び図１のＵＩＣＣ１０のようなＵＩＣＣ３０の間で発生するものである。
【０１１９】
図３に図示されるシーケンスは、既存のパーテション／ディレクトリにおけるディレクトリの生成のために、ユーザ２６からのリクエスト３２により発生し、そして、パスワード名、ドメイン及びパスワードを含む適切なリクエスト動作３４がＭＥ２８に送られる。
【０１２０】
もし、ドメインが「パブリック」であるとして要求されれば、ユーザ２６はパスワードをディレクトリに設定せず、よって「パスワード」パラメータは空文字列となる。
【０１２１】
次に、ＭＥ２８がＵＩＣＣ３０に、ｅｎｔｉｔｙ_ｉｄ、ｅｌｅｍｅｎｔ_ｔｙｐｅ、パス名、及びｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓを含むＣｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑｕｅｓｔ３６を渡す。
【０１２２】
本例において、ディレクトリ「ｅｌｅｍｅｎｔ_ｔｙｐｅ」の生成では、「ディレクトリ」、及び「ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓ」は、ヌル値を有することに注意すべきである。
【０１２３】
続く信号伝達の経過は、パスワード検証シーケンス３８を含む。これは、親ディレクトリに関連するが、親ディレクトリがパスワードによって保護されていない場合は要求されない。ただし、保護されている複数のディレクトリのレベルがある場合は、各ディレクトリに対するパスワードは検証されなければならない。
【０１２４】
パスワード検証シーケンス３８は、親−ディレクトリ−パスを含み、そのうえパスワードが要求される状態を確かめる、ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号４０により開始される。
【０１２５】
ＭＥ２８からＭＥユーザ２６へ、パスワードが要求される通知４２が送られると、順に、ＭＥユーザ２６からＭＥ２８へパスワード４４が送り返され、次に、ＭＥ２８からＵＩＣＣ３０に、ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号４６が送られる。ＵＩＣＣ３０は、次にＭＥ２８へ、ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ信号４８を送り、更なる信号伝達交換が、ＵＩＣＣ３０とＭＥ２８の間で行われる。ただし、もし、パスワード値がゼロであれば、このようなパスワード設定機能が生じ得ないことは当然であるが、この信号交換には、ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ結果信号５０、ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号５２、ｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔ信号５４、ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号５６、及びｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ信号５８が含まれる。
【０１２６】
シーケンスは、ＭＥ２８からユーザ２６に、生成ディレクトリ結果信号６０が送られて終了する。
【０１２７】
比較として、本発明における本実施例の特徴の更なる詳細が図４に示される。図４は、ファイル生成に関して生成される信号のシーケンスを示す。
【０１２８】
信号伝達もまた、ユーザ２６、ＭＥ２８、及びＵＩＣＣ３０に関して示される。
【０１２９】
この例では、エンド・ユーザがＭＥのカメラ機能を使用して写真を撮って、既存のパーテション／ディレクトリにその写真を保存することに決めて、ファイル生成リクエスト６４が、モバイル機器２８に送られる。これは、関連データに関するパス名、ドメイン、パスワード、及びｄａｔａ_ｔｙｐｅを含むファイル・リクエスト６４を生成する。
【０１３０】
その後、ＭＥ２８からＵＩＣＣ３０に、ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｔｙｐｅ６６が送られる。この中では、ファイルの生成のために、ｅｌｅｍｅｎｔ_ｔｙｐｅに「ファイル」が設定され、ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓは、ＰＧまたはＭＰ３等のｆｉｌｅ_ｔｙｐｅと、データすなわちファイルそれ自体の内容が含まれる。
【０１３１】
もし、６８において、ファイルを生成するための場所に到着する前にパスワードによって保護されているディレクトリがあることが分かれば、例えば、図３に示したものを図４のシーケンスにも同様に適用する等して、各ディレクトリのパスワードは検証されなければならない。
【０１３２】
つまり、ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ７０がＵＩＣＣ ３０からＭＥ２８に送られる。これに応じて、ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号７２がＵＩＣＣ３０に送られ、ＵＩＣＣ３０がｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔｓ信号７４を開始する。ここで、パスワードがゼロ（ｎｕｌｌ）と設定されていないｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ ７６が、ＭＥ２８からＵＩＣＣ３０に送られるものとする。これに応じて、ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ７８がＵＩＣＣ３０からＭＥ２８へ送られる。そして、ＭＥ２８とＵＩＣＣ３０の間のこの信号伝達交換７０−７８のシグナリング交換の最後に、生成されたファイル結果表示８０がＭＥ２８からエンド・ユーザ２６に提供される。
【０１３３】
最後に図５及び図６について、保護されたファイルの読み出しを行おうとする場合に関する信号伝達図であって、正しいパスワードが使用される例（図５）と、比較として、アクセス条件が満たされない例（図６）をここに示す。
【０１３４】
最初に図５において、適切なエンティティ２６が、ＭＥ２８に対し、当該エンティティが「制限されたリード」ドメインに規定されたファイルを読むことを望む、読み出しファイル８４を提供する目的で、８２において指示８２を準備する。読み出しファイル指示８４内のパス名は、例えば「／ｐａｒｔｉｔｉｏｎ ／ｄｉｒｅｃｔｏｒｙ Ｉ／ｐｉｃｔｕｒｅ １.ｊｐｇ」のような、読み出されるまでの特定のパスを含む。
【０１３５】
続いて、ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ８６がＥ２８からＵＩＣＣ３０へ送られる。
【０１３６】
図５に示す範囲内では、パスワード検証シーケンス８８が、ファイルそのものと、そのうえ、パスワードで保護されている、前のディレクトリに適用される。この場合、図５に示されているような信号伝達及び指示９０−９８を含むパスワード検証シーケンスが提供される。
【０１３７】
最初に、ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号９０がＵＩＣＣ３０からＭＥ２８へ送られる。次に、パスワード要求指示９２がＭＥ２８からエンティティ２６へ送られ、検証されたパスワードａｔｔｅｍｐｔ９４が戻され、次に、ＭＥ２８からＵＩＣＣ３０へｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ９６を開始する。
【０１３８】
それから、検証ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ９８は、パスワード検証シーケンス８８を完了するため、ＵＩＣＣ３０からＭＥ２８へ送り返される。
【０１３９】
パスワードは検証されて、要求されたデータを含む読み出しエレメント結果１００がＵＩＣＣ３０からＭＥ２８へ送られ、要求されたデータを含む読み出されたエレメント結果が要求を出しているエンティティ２６へ送られる（１０２）。
【０１４０】
図６に戻って、１０４においてもう一つの異なるエンティティによって「プライベート」ドメインに定められるファイルを読むための、あるエンティティによる試みに関するシーケンスが例示される。読み出しファイル指示１０６はＭＥ２８に提供される。
【０１４１】
それから、ＭＥ２８からＵＩＣＣ３０へｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ１０８が送られる。このリクエストにおいては、当然のことながら、ｅｎｔｉｔｙ_ｉｄは、ファイルオーナーｅｎｔｉｔｙ_ｉｄと異なっている。
【０１４２】
ＵＩＣＣ３０は、ファイルのドメインが「プライベート」ドメインを含み、したがって、ファイルのオーナーだけがファイルにアクセスすることができるとわかる。受け取ったｅｎｔｉｔｙ_ｉｄがオーナーのｅｎｔｉｔｙ_ｉｄにマッチしないので、ＵＩＣＣ３０からＭＥ２８に送られたｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ１１０の中にあるリードリクエストは拒絶される。
【０１４３】
それから、読み出しファイル結果指示１１２は、ＭＥ２８からリクエストを出しているエンティティ２６へ送られる。そして、その中のデータ・パラメータがゼロ（ｎｕｌｌ）であり、結果は、読み出し失敗を示す。
【０１４４】
本発明が前述の具体化の詳細に限られていないことは勿論である。
【０１４５】
ＵＳＢスマートカードＩＣＣＤインターフェース・クラスで動作するアプリケーションのための実装（本明細書で説明したのと同様の特徴をサポートしている新しいＡＰＤＵコマンドの生成が含まれる）は、はっきりと記述されないが、上述したことと同じ特徴を、ＩＣＣＤクラス等に適用することができる。
【０１４６】
また、ＵＳＢ大容量記憶装置インターフェース・クラスをサポートしているＵＩＣＣを含むシナリオとして、あるエンティティ（例えばＭＥ）によってデータ・エレメントが保存され、そのようなＵＩＣＣがパスワード検証なしでアクセスできると、すなわち、データ・エレメント自体及びその親データ・エレメントに対してパスワードを要求されないと、ＵＩＣＣがＵＳＢ大量の記憶装置のように構成され動作し、ＰＣのようなデバイスに接続された時、このデータ・エレメントもまたアクセス可能とするべきである。
【０１４７】
ＵＩＣＣがＵＳＢ大量の記憶装置として構成され、パスワード検証プロセスをサポートしないデバイスに接続されているときは、パスワードで保護されているデータ・エレメントは、アクセスできない状態のままとしなければならない。
【０１４８】
すなわち、より詳細には、ＵＩＣＣが、具体的にＵＳＢ大量の記憶装置のように構成され、例えばＰＣのような遠隔装置に接続される場合は、ＵＩＣＣは、シンプルなＵＳＢメモリースティックのように振る舞うことができる。それから、パスワードなしで、すなわち上で概説される「パブリック」ドメインのように、ＭＥまたは実際に他のいずれの装置によって保存されたＵＩＣＣの上のデータ・エレメントは、ＰＣ上でアクセスできる状態のままでなければならない。
【０１４９】
しかし、パスワードによって保護されているデータ・エレメントのために、ＵＩＣＣが、メモリースティックのように振る舞い、ＰＣに接続されているとき、それらはアクセスできない状態にある。
【０１５０】
たとえば、ユーザが、ＭＥのカメラを使って写真を撮って、パスワードなしでＵＩＣＣ内に保存する。それからユーザがＵＩＣＣをＰＣに電気アダプターを介して接続するとき、ＵＩＣＣは、ＵＳＢメモリースティックのように振る舞い、この写真はＰＣ上でアクセス可能となる。しかし、ユーザがパスワードと共にこの写真を保存すれば、ＵＩＣＣがＰＣと接続されても、この写真は見ることができない。
【０１５１】
＜参照による取り込み＞
本明細書は、２００９年１月１６日に出願された英国特許出願番番号０９００６６４.４号の優先権を要求する。そして、参照によってその開示の全てをここに取り込む。
【符号の説明】
【０１５２】
１０ ＵＩＣＣ
１２ 処理機能
１４ 記憶領域
１６ インターフェース
１８ 携帯電話機
２０ プロセッサ
２２ スタンダード・メモリ
２４ 送信／受信機能
２９ ユーザ
２８ ＭＥ
３０ ＵＩＣＣ
３２ リクエスト
３４ 適切なリクエスト動作
３６ Ｃｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑｕｅｓｔ
３８ パスワード検証シーケンス８
４０ ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号ｌ０
４６ ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号ｌ６
４８ ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ信号ｌ８
５０ ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ結果信号ｌ０
５２ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号
５４ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔ信号
５６ ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号
６０ 生成ディレクトリ結果信号
６４ ファイル生成リクエスト
６６ ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ
７０ ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ
７２ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号
７４ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔｓ信号
７６ ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ
７８ ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ
８０ ファイル結果徴候
８２ ａｔ２における指示
８４ 読み出しファイル指示
８６ ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ
９０ ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号
９２ パスワードリクエスト指示
９４ 検証パスワード試み
９６ ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ
９８ 検証ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ
１００ 読み出しエレメントリクエスト０
１０２ 届けられる
１０６ 読み出しファイル指示
１０８ ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ
１１０ ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ
１１２ 読み出しファイル結果指示
【技術分野】
【０００１】
本発明は、回路カードに関し、特に、配置、方法、及びそれらに記憶されるデータの保護に関する。
【背景技術】
【０００２】
機能の増加に伴い、携帯電話機及び携帯機器（ＭＥ：Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ）のための他のタイプのハンドヘルドデバイスは、ストレージ及び大量の（個人）データを保持するための一般的なデバイス／インターフェースとして普及している。
【０００３】
たとえば、そのようなデータは、個人的な写真、ビデオ、及びＳＭＳメッセージであり、ユーザは、一般的に、ＭＥ、例えばＳｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ（ＳＩＭ）カードのようなＵｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ（ＵＩＣＣ）の関連部分、又はネットワーク運営者により提供されるネットワークサイドストレージ、又はメモリカードのような他のメディア・デバイスの中に、そのようなデータを格納するオプションを有している。
【０００４】
格納されるデータの量と潜在的に個人的な／繊細な性質からみれば、エンド・ユーザの視点から、記憶領域は、十分な記憶容量、適切なセキュリティレベルを備えなければならず、更に利用しやすい状態でなければならない。
【０００５】
ＭＥそのものが、適切な保安の程度を提供すると考えられるが、そのようなレベルのセキュリティは、特定ＭＥ製造業者に限定されがちであり、ストレージ容量は、全てのタイプのユーザ・データ、特にマルチメディア・データのためには十分に考慮されない。データへ接続性も同様に、一般に、製造業者の特別なケーブルと、関連するソフトウェアの接続性を必要とする。
【０００６】
メモリカードのような装置が、大きな記憶容量と手早い接続性を提供することができる一方、ユーザ・データに対して保護するか、適当な保護を提供する手段がない。
【０００７】
勿論、アクセスの容易性は、保証とはかけ離れているかもしれないネットワーク・アクセスの利用可能性に依存するが、ネットワークサイドストレージ領域に関しては、十分な記憶容量と共に高度な安全対策を実現することができる。
【０００８】
近年の発展においては、ＵＩＣＣのような回路カードは、潜在的に魅力的な記憶領域を有している。例えば３ＧＰＰ／ＥＴＳＩ Ｒｅｌ-７からから開始された、高密度メモリをサポートしているＵＩＣＣが利用可能であり、同様な仕様で、単純なアダプターを経由して例えばＰＣ等へのデータ検索のような、ＵＩＣＣによる非常に簡単で高速にデータ変換するＵＩＣＣとＭＥ間の、ＵＳＢ２．０／ＵＳＢ ＩｎｔｅｒＣｈｉｐに基づく新しいインターフェースの供給が提案されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】国際公開公報ＷＯ２００８／１３９６１５
【特許文献２】米国特許公開公報２００８／２５４８３４
【特許文献３】米国特許公開公報２００８／２５６６２９
【特許文献４】米国特許公開公報２００８／１５５８３０
【発明の概要】
【発明が解決しようとする課題】
【００１０】
特に個人識別情報Ｎｏ．（ＰＩＮ）コードの使用によりＵＩＣＣは比較的セキュアであるとされているが、以下の点で限界が残っている。つまり、一旦ＰＩＮが検証されたら、単にユーザがＵＳＩＭ／ＧＳＭアプリケーションを起動したいときは、記憶されたユーザ・データは、更なるセキュリティチェックを要求されることなく自由にアクセスすることができてしまう。
【００１１】
つまり、たとえば、一旦ＭＥを起動し、正しいＰＩＮのエンティティを経由して使用してＵＳＩＭに適切にアクセスしたら、ＵＳＩＭに保存される他の全てのデータは、直ちにアクセス可能となり、特に、現在のエンド・ユーザが単に、ＭＥに一時的なアクセスをする目的であれば、適当でないかもしれない。
【００１２】
国際特許公開ＷＯ２００８／１５９６１５には、サービスの範囲の動的な変化を許可するメモリカード、アクセス・コントロールシステム、アクセスコントロール方法が記載されている。また、ダウンロードされる内容と関連した情報にしたがったアクセス管理の実行を通してのユーザに従う異なるサービスを提供し、そこでは、回路カードはデータ管理部を含み、カード上のデータを保護するためにセキュリティ・メカニズムの供給よりもむしろサービスの動的変化範囲に依存することが記載されている。
【００１３】
更に、米国特許公報２００８／２５４８３４、２００８／２５６６２９、及び２００８／１５５８３０には、それぞれ、ユーザ識別子の比較の提供を通して、コンテンツの安全なストレージを提示するメモリカードが記載されている。
【００１４】
本発明は、既存のカード及び方法に対し有利な点を有する回路カード、そしてそのようなカードを含むＭＥ、そのようなカードにおけるデータ保護方法を提供することを目的とする。
【００１５】
特に、本発明は、既存のカード及び方法に対し有利な点を有するＵＩＣＣ、及びそこでのセキュリティ及びデータを提供するための方法を提供するものとする。
【課題を解決するための手段】
【００１６】
本発明の一態様においては、複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、前記複数のデータ・エレメントのうち少なくとも１つは、前記ドメイン保護エレメント及びパスワード保護エレメントと関連する。
【００１７】
本発明は、１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全性を容易に強化することができて、実際、柔軟でかつすぐに適用可能な方法を提供することができる点で有利である。
【００１８】
したがって、そのような回路カードは、エンド・ユーザに、特に、そのような回路カードは、特に、ユーザの特有で慎重に扱うべきデータに対し、セキュリティ、能力、及びアクセス容易性において適切なレベルを有利に提供することができる。
【００１９】
それらが、データ・エレメントの保護、例えば、パーテション、ディレクトリ又はファイルのコンビネーションで提供される範囲で提供される場合、特に強化されたセキュリティのレベルが、上述した「パスワード」及び「ドメイン」の特徴のコンビネーションを通して提供される。「パスワード」特徴は、言わば、一度パスワードが検証されデータ・エレメントへのアクセスが許可されるような動作の本質から独立したものとして提供される。一方、「ドメイン」特徴は、前述のパーテション、ディレクトリ又はファイルなどのデータ・エレメントに許可される可能性があるオペレーション（動作）を定義する。
【００２０】
１つの特定の例に、回路カードは、ＵＩＣＣから成る。
【００２１】
さらにまた、セキュリティの付加的レベルが、回路カードの１つ以上のアプリケーションに対するＰＩＮアクセス・コードの使用を通して提供される。
【００２２】
好ましくは、上述の複数のデータ・エレメントの各々は、ドメイン保護エレメントと関係する。
【００２３】
更に好ましくは、許可された動作は、１以上のリード及び／ライト動作を含む前記ドメイン保護エレメントによって定義されたものである。
【００２４】
さらにまた、本発明の方法においては、回路カードにおいてデータにアクセスすることができるエンティティは、一意の識別子に関連している。
【００２５】
また、本方法は、データ・エレメントを生成するエンティティの識別子が保存されているものとすることができる。
【００２６】
さらに、そして、本発明を具体化した回路カードと共に使用するように構成されたＭＥに関し、当該方法は、ＭＥの中で、データへのアクセスを要求するエンティティを識別するものとすることができる。
【００２７】
好ましくは、データ保護ステップは、ＭＥと回路カードとの間のＵＳＢインターフェース・クラスに適用される
【００２８】
更に好ましくは、回路カード上のデータ・エレメントが、スタンダードファイルフォーマットファイルにしたがって保存される。
【００２９】
さらにまた、データ・エレメントの生成及び管理は、回路カード内のデータ・エレメントの生成及び管理によって行われ、また、ＭＥ経由で提供されることができる。
【００３０】
また、ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能を有する。
【００３１】
本発明の他の態様においては、複数の保護可能なデータ・エレメントが保存された回路カードであって、データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに関連して配置された、少なくとも１つの前記複数の保護可能なデータ・エレメントを有するものである。
【００３２】
好ましくは、回路カードは、ＵＩＣＣから成る。
【００３３】
また、少なくとも１つのデータ・エレメントは、ドメイン保護エレメントによる許可された動作を開始するために、パスワードが要求されるように構成することができる。
【００３４】
好ましくは、複数のデータ・エレメントのそれぞれは、ドメイン保護エレメントに関連している。
【００３５】
また、前述のオペレーション（動作）は、少なくとも１つのリード及び／又はライトアクセスオペレーションを含むドメイン保護エレメントによって定義されている。
【００３６】
好ましくは、回路カードは、ＵＳＢインターフェース・クラスを経由してデータ・エレメントにアクセスを許可するように構成される。
【００３７】
さらに、回路カードは、そのファイルシステムのスタンダードファイル内に保存されたデータ・エレメントを含むように構成される。
【００３８】
本発明は、さらに、上で定められるように、回路カードを受け取るように構成されたＭＥも提供することができる。
【００３９】
好ましくは、ＭＥは、ＵＳＢインターフェース・クラスを経由して回路カードと通信することができるように構成される。
【００４０】
更に好ましくは、上述の保存されたデータ・エレメントを生成及び／または管理が可能に構成されている。
【００４１】
好ましくは、ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能により定義されている。
【００４２】
本発明は、ほんの一例として以下の添付の図面を参照して、説明される。
【発明の効果】
【００４３】
本発明によれば、１つ以上のドメイン保護エレメントの提供を通して、回路カードに格納されるデータの安全の程度は、容易に強化されることができて、本当に、柔軟ですぐに適合できる方法とし提供される。
【図面の簡単な説明】
【００４４】
【図１】図１は、本発明の実施例におけるＵＩＣＣの略平面図である。
【図２】図２は、移動無線通信装置またはＭＥの略平面図であって、携帯電話機及び図１のＵＩＣＣで動作するようアレンジされた図である。
【図３】図３は、本発明にかかるＵＩＣＣにおけるディレクトリの生成に関連した信号伝達タイミングチャートである。
【図４】図４は、ＵＩＣＣ等のためのファイル生成のための信号伝達タイミングチャートである。
【図５】図５は、誤ったパスワードを用いて保護されたファイルを読もうとした場合の信号伝達タイミングチャートである。
【図６】図６は、正しいパスワードを用いて保護されたファイルを読みだす場合の信号伝達タイミングチャートである。
【発明を実施するための形態】
【００４５】
上記及び以下の特定の実施の形態の詳細な説明から明らかなように、本発明は、単純なＰＩＮコードに基づくデータ保護機構の提供に関係する現在の回路カードに見られる限界に対処するものである。前述のように、回路カードは、第１に、たとえばＧＳＭ／ＵＳＩＭ等のアプリケーション及びその関連データであるＩＭＳＩまたはＰＬＭＮリスト等に関連する。そして、回路カード内のデータ、例えば、同じセキュリティ体制下に移動された、例えばユーザの個人的なファイル、写真、ビデオ、個人的なメッセージなどは、そのようなアプリケーションのいずれにも直接接続されていない。
【００４６】
本発明は、回路カードに格納されるあらゆるタイプのデータに対して、強化したセキュリティのレベルを提供することを目的とし、必要とされるならば、既存のＰＩＮ保護に加えて使われることができるデータ保護メカニズムを定める。
【００４７】
また、回路カード内のデータ記憶装置は、一般的には、大量のデータの記憶に適していないＥｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓに基づいている。また、そのようなファイルは、ビデオや音楽のようなあるタイプのデータを記憶するために定義されないことがしばしばある。したがって、新しいデータ記憶配置が、本発明の一部として提案され、回路カードセキュリティ向上に関連した特別な用途が見つけられる。
【００４８】
最初に図１を参照すると、本発明が適切に具体化されている回路カードの１つの例の概略図が提供されている。
【００４９】
回路カードは、記憶領域１４とＭＥインターフェース１６の間に提供される処理機能１２を含むＵＩＣＣ１０を有する。
【００５０】
後述されるように、インターフェース１６は、ＵＳＰ２．０／ＵＳＰ ＩｎｔｅｒＣｈｉｐに有利に基づくものとすることができる。ＵＳＰ２．０／ＵＳＰ ＩｎｔｅｒＣｈｉｐは、たとえば、ＵＩＣＣ１０と、簡単な電気アダブタを介してＰＣと接続される図２の携帯電話機１８との間のデータ変換を簡便で高速化することができる。
【００５１】
図２に関して、例えば携帯電話機１８等の携帯機器（ＭＥ）のどんな形式も含む携帯無線通信デバイスの概略図が提供されている。携帯電話機１８は、内部に図１のＵＩＣＣ１０を備え、スタンダード・メモリ２２、プロセッサ２０、及び送信／受信機能部２４を備えている。
【００５２】
携帯電話機１８として提供されることができる様々なストレージオプションのうち、ＵＩＣＣ１０は、上述し、下記に詳細を記述するセキュリティエレメント領域及びセキュリティエレメントパスワードのコンビネーションに基づく、有利で保証された、高速アクセス可能な、適当に大きいデータの格納場所を提供することができる。
【００５３】
現在の説明と本発明の定義に関して、当然ながら、パスワードがチェックされとすぐに、オペレーションが許されるだろうことから独立して、「パスワード」は、ファイル／ディレクトリ／パーテションへのアクセスを保護する。これに対し、ドメインは、特定のエンティティが、ファイル／ディレクトリ／パーテション上で実行することができる異なるオペレーションを定義する。
【００５４】
したがって、１つの特定の例として、各データ・エレメント、例えばファイル、ディレクトリまたはパーテションでさえ、ドメインと関係することができ、パスワードによって保護されることができる（関連するドメインがパスワードを必要とする場合）。
許可されたオペレーションのそれぞれの定義を有するいろいろなドメインが提供されることができ、相互運用性（インターオペラビリティ）を可能とするために、一般に標準化された方法で提供される。
【００５５】
例として、可能性があるドメインは以下の通りである：
プライベート：オーナー（ファイル／ディレクトリ／パーテションにより生成されたエンティティ）だけがアクセスをすることができる。一旦パスワードがうまくチェックされれば、すべての権利は与えられる。
制限されたリード・ライト：もしパスワード・チェックにうまくパスするならば、どんなエンティティに対してもリード・ライトアクセス権が与えられる
制限されたリード：もしパスワード・チェックにうまくパスするならば、どんなエンティティに対してもリードアクセス権が与えられる
リードオンリー：いかなるエンティティも、パスワードなしで読むことができる。
パブリック：どのようなエンティティにも、パスワードなしで、リード・ライトアクセス権を与えられる。
【００５６】
ＵＩＣＣのデータにアクセスすることができる、特定のユーザ及び／又は他のデバイス／装置のような、いかなるエンティティも、「ｅｎｔｉｔｙ_ｉｄ」と呼ばれる一意の識別子と関連づけられている。この識別子は、好ましくは、ＭＥからのリクエストの際に、ＵＩＣＣによって割り当てられる。そして、「リクエスト／結果」構造は以下の通りとすることができる：
ＭＥからＵＩＣＣまで：Ｇｅｎｅｒａｔｅ_Ｅｎｔｉｔｙ_Ｉｄ_Ｒｅｑ（ｅｎｔｉｔｙ_ｎａｍｅ）
ＵＩＣＣからＭＥまで：Ｇｅｎｅｒａｔｅ_Ｅｎｔｉｔｙ_Ｉｄ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｎａｍｅ、ｅｎｔｉｔｙ_ｉｄ）;
【００５７】
「ｅｎｔｉｔｙ_ｎａｍｅ」は、ＵＩＣＣのデータにアクセスすることができるエンティティの、公的に入手可能な名前を示す。この特定の図解された例は、少なくとも、それらのそれぞれのｅｎｔｉｔｙ_ｎａｍｅｓを有する次の一般エンティティが定義されることを示している：
−ユーザ（ＵＳＥＲ）
−携帯機器（ＭＥ）
−遠隔サーバ（ＲＥＭＯＴＥ＿ＳＥＲＶＥＲ）
−ＭＥ内のサードパーティのアプリケーション（ＭＥ＿ＴＨＩＲＤ＿ＰＡＲＴＹ）
勿論、リストは完全なものではなく、よって他のエンティティも含まれ得る。
【００５８】
「ｅｎｔｉｔｙ＿ｉｄ」は、ＵＩＣＣによって、所定の「ｅｎｔｉｔｙ＿ｎａｍｅ」に割り当てられるプライベートの識別子である。
「ｅｎｔｉｔｙ＿ｎａｍｅ」、「ｅｎｔｉｔｙ＿ｉｄ」の組は、ＭＥ内のメモリに保存され、ＭＥはこれらの組の守秘性を保証する。
【００５９】
都合のよいことに、リクエスト中のエンティティ（ＵＩＣＣのデータにアクセスしたがっているエンティティ）を正確に識別する責任がある。例えば、もしリクエストがＭＥアプリケーションからきているならば、ＭＥは、このドキュメントに定義されたインターフェース機能におけるＭＥと関連かあるｅｎｔｉｔｙ＿ｉｄを使用する。
ＭＥにとって、異なる要求中のエンティティを識別するための簡単な方法は、ＭＥオペレーティングシステムによって割り当てられる、それぞれスレッド又はプロセス識別子の使用に基づいていてもよい。
いくつかの動作は、直接このｅｎｔｉｔｙ＿ｉｄに依存しているため、ＵＩＣＣは、ＭＥから渡された「ｅｎｔｉｔｙ_ｉｄ」は、正確であるという事実に頼ることができる。つまり、ＭＥからＵＩＣＣへのそのような正確な「ｅｎｔｉｔｙ＿ｉｄ」の供給は、この提案で定義したセキュリティ・メカニズムを強調することができる。
【００６０】
ファイル／ディレクトリ／パーテションが生成されるとき、ＵＩＣＣは、生成されたエレメントのために、「オーナー」の概念を結びつけることができる。その目的のために、ＵＩＣＣは、単にリクエスト生成機能でパスされる「ｅｎｔｉｔｙ＿ｉｄ」を取り、生成されたエレメントのオーナーｅｎｒｉｔｙ＿ｉｄとして、それを保存する。
多くのオペレーションは、ファイル／ディレクトリ／パーテションのオーナーである場合にのみ許可される（例えば、上述のようにプライベートドメインと定義されたエレメントは、オーナーからしかアクセスすることができない）。このため、このオーナーシップの考えは重要であると証明することができる。
【００６１】
いろいろなセキュリティ・インターフェース機能を採用することができる。
第１には、エンティティがその自身のファイル／ディレクトリ／パーテションのためにだけこの機能を使用することができるセッティング・パスワード機能がある。リクエストを受けたとき、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄとマッチしなかったとＵＩＣＣが認識すれば、リクエストは拒絶され、「リクエスト／結果」構造は、以下の通りとなる：
【００６２】
ＭＥからＵＩＣＣまで： Ｓｅｔ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、パスワード）
ＵＩＣＣからＭＥまで： Ｓｅｔ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００６３】
有利にオーナーのパーテション／ディレクトリ／ファイルだけが、リクエストの実行を許可されることができるように、ｅｎｔｉｔｙ＿ｉｄは提供される。パス名は、パーテション／ディレクトリ／ファイルの名前を含むパスを有する。そして、パスワードは、パーテション／ディレクトリ／ファイルに設定されるパスワードを有する。最終結果は、成功か失敗のいずれかである。
【００６４】
パスワード変更機能は、エンティティにより使用可能であるが、それ自身のファイル／ディレクトリ／パーテションのためだけである。
リクエストを受け取ったとき、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄにマッチしないとＵＩＣＣが認識した場合、リクエストは拒絶されて、以下の「リクエスト／結果」構造となる。
【００６５】
ＭＥからＵＩＣＣまで： Ｃｈａｎｇｅ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、ｏｌｄ＿ｐａｓｓｗｏｒｄ、ｎｅｗ＿ｐａｓｓｗｏｒｄ）
ＵＩＣＣからＭＥまで：Ｃｈａｎｇｅ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００６６】
パーテション／ディレクトリ／ファイルの現在のパスワードを有するｏｌｄ＿ｐａｓｓｗｏｒｄと、パーテション／ディレクトリ／ファイルに設定される予定の新しいパスワードを含むｎｅｗ＿ｐａｓｓｗｏｒｄと共に、上述のそれらに対する同様なパラメータが採用される。
【００６７】
パスワード検証機能のためのリクエスト／結果構造は、以下のようにすることができる。
【００６８】
ＭＥからＵＩＣＣまで： Ｖｅｒｉｆｙ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、パスワード）
ＵＩＣＣからＭＥまで： Ｖｅｒｉｆｙ＿Ｐａｓｓｗｏｒｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００６９】
１例として、ひとつの任意の保護されたエレメント（ファイル、ディレクトリ、またはパーテション）に対する、各エンティティに対するパスワード検証のための「試み」の数は、３つに限られる。３つの試みが失敗した後、エレメントに対するアクセス条件が変更される（例えば、このエレメントのオーナーが変更するか、パスワードを消去するか）まで、エレメントはもはや、これらの試みを行ったエンティティにアクセスすることができない。
【００７０】
エンティティがそれ自身のファイル／ディレクトリ／パーテションのためにだけ「セットドメイン」機能を使用することができるよう構成することが可能である。ＵＩＣＣが、リクエストを受け取って、受け取ったｅｎｔｉｔｙ＿ｉｄがオーナーのｅｎｔｉｔｙ＿ｉｄとマッチしないと認識した場合、当該リクエストは拒絶され、「リクエスト／結果」構造は以下の通りになる。
【００７１】
ＭＥからＵＩＣＣまで： Ｓｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名、領域）
ＵＩＣＣからＭＥまで： Ｓｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名）
【００７２】
得られるドメイン機能は、以下の「リクエスト／結果」構造として提供することができる。
【００７３】
ＭＥからＵＩＣＣまで：Ｇｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｉｄ、パス名）
ＵＩＣＣからＭＥまで： Ｇｅｔ＿Ｄｏｍａｉｎ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｉｄ、パス名、領域）
【００７４】
さらに、アクセス状態通知機能は、以下の、対応する構造として提供することができる。
【００７５】
ＵＩＣＣからＭＥまで： Ａｃｃｅｓｓ＿Ｃｏｎｄｉｔｉｏｎ＿Ｎｏｔｉｆｉｃａｔｉｏｎ（ｅｎｔｉｔｙ＿ｉｄ、パス名、状態）
【００７６】
上述したこれらに対する同様なパラメータが、パス名（例えば、パスワードを必要とする）によって示されたエレメントのために検証される必要がある状態を有する状態パラメータを付加して採用される。
【００７７】
１つのエンティティ識別子生成機能は、以下の「リクエスト／結果」構造と共に提供され得る。
ＭＥからＵＩＣＣまで： Ｇｅｎｅ ｎｏｔｅｄ ａｂｏｖｅ ｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｑ（ｅｎｔｉｔｙ＿ｎａｍｅ）
ＵＩＣＣからＭＥまで： Ｇｅｎｅｒａｔｅ＿Ｅｎｔｉｔｙ＿Ｉｄ＿Ｒｅｓ（結果、ｅｎｔｉｔｙ＿ｎａｍｅ、ｅｎｔｉｔｙ＿ｉｄ）;
【００７８】
関連したパラメータについては、前に述べたように、ｅｎｔｉｔｙ_ｎａｍｅは、エンティティのパブリックネームを含み、ｅｎｔｉｔｙ_ｉｄは、各エンティティ名ごとに、ＵＩＣＣによって割り当てられた一意の識別子を有する。
【００７９】
本発明の本実施の形態の更なる面の例として、下記は本発明の実施の例で、上述した「可能性がある領域」を示す。
【００８０】
先ず、ユーザが写真を撮り、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」領域は、「制限されたリード・ライト」として定義される。「ｄｉｒｅｃｔｏｒｙ１」と「ｉｍａｇｅ１.ｊｐｇ」は、パスワードによって保護されていない。
ユーザ又は他のどのエンティティも、「ｉｍａｇｅ１.ｊｐｇ」ファイルにアクセスすることは問わないが、唯一の条件として、「ｐａｒｔｉｔｉｏｎ１」のパスワードを知っている必要がある。
【００８１】
第２の例として、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。 「ｐａｒｔｉｔｉｏｎ１」と「ｄｉｒｅｃｔｏｒｙ１」領域は、パブリック（したがって、パスワードは必要なし）と定義される。「ｉｍａｇｅ１.ｊｐｇ」は、パスワードによって保護される（ドメイン「制限されたリード」）。
ユーザ又は他のどのエンティティも「ｉｍａｇｅ１.ｊｐｇ」ファイルをリードすることは問わないが、唯一の条件として、「ｉｍａｇｅ１.ｊｐｇ」のパスワードを知っている必要がある。
【００８２】
第３の例に、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」領域は、プライベートと定義される。「ｄｉｒｅｃｔｏｒｙ１」と「ｉｍａｇｅ１.ｊｐｇ」は、パスワードによって保護されていない。
【００８３】
ユーザ又は他のどのエンティティも、「ｉｍａｇｅ１.ｊｐｇ」ファイルにアクセスするのは問わないが、ユーザだけが続くパスワード検証に成功した後にファイルにアクセスすることができる。たとえ正しいパスワードを知っていても、他のどのエンティティもこのファイルにアクセスすることができない（そのｅｎｔｉｔｙ_ｉｄがオーナーｅｎｔｉｔｙ_ｉｄと一致しないため）。
【００８４】
第４の例として、ユーザは写真を撮って、画像ファイルを「／ｐａｒｔｉｔｉｏｎ１／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」に保存する。「ｐａｒｔｉｔｉｏｎ１」、「ｄｉｒｅｃｔｏｒｙ１」、「ｉｍａｇｅ１.ｊｐｇ」ドメインは、「リードオンリー」と定義される。
【００８５】
この例における最初の動作としては、ユーザ又は他のどのエンティティであっても「ｉｍａｇｅ１.ｊｐｇ」ファイルを読むことができ、そして、ファイルを読むためにパスワードを要求されないため、ファイルに直接アクセスすることができる。
【００８６】
しかしながら、第２の動作として、ユーザ又は他のどのエンティティでも「ｉｍａｇｅ１.ｊｐｇ」ファイルを更新するのは問わないが、オーナー（ユーザー）のみが続くパスワード検証に成功した後で、ファイルにアクセスすることができる。
【００８７】
上記の内容から分かるように、本発明は、将来のＵＩＣＣ−ＭＥ間の大きなデータのやり取りが主にＵＳＢインターフェースを介して行われるという事実をすぐに考慮することができる。したがって、上述の例は、ＵＳＢとＥＥＭ（Ｅｔｈｅｒｎｅｔ（登録商標） Ｅｍｕｌａｔｉｏｎ Ｍｏｄｅ）インターフェース・クラスをサポートしているＭＥ−ＵＩＣＣインターフェースに実装することを目的としている。しかし、この課題解決の方法は、スマートカードＣＣＩＤ（Integrated Circuit(s) Cards Interface Device）のような他のＵＳＢインターフェース・クラスについて適用されることもできる。
【００８８】
このことについては、ＵＳＢパケットは、ＥＥＭ ＰａｃｋｅｔがＵＳＢパケットのペイロードを有するフォーマットを有することから理解されるべきである。ＥＥＭパケット自体が、ＥＥＭ ＤａｔａかＥＥＭ Ｃｏｍｍａｎｄフォーマットとして定義されたフォーマットを有している。
【００８９】
ＥＥＭ ＣｏｍｍａｎｄパケットがローカルＵＳＢリンク管理として使用され、したがって、ＵＳＢデバイス・ドライバ層を超えることができない。したがって、これら説明した例の規定のインターフェース機能は、ＥＥＭ Ｄａｔａタイプパケットのペイロード部分に要約されます。
【００９０】
上記したように、Ｅｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓに基づく現在のファイルシステムには若干の限界があるのに対し、大きなサイズ／マルチメディア・データのサポートを強化するために、本発明は、データストレージを向上することに役立つ特徴も含む。本発明は、大部分の既存のＥｌｅｍｅｎｔａｒｙ Ｆｉｌｅｓファイルシステムを標準的なファイル形式ファイルシステムと取り替えることを目的とする。
【００９１】
その目的のために、特定にＭＥ−ＵＩＣＣインターフェース機能は、ＭＥに、ＵＩＣＣの中で、パーテション／ディレクトリ／ファイルを生成して管理することを許可するために定義されている。
【００９２】
そのようなＭＥ-ＵＩＣＣ機能の例は、以下で概説される。
【００９３】
（パーテションまたはディレクトリまたはファイルを生成する）Ｃｒｅａｔｉｏｎ機能は、以下の「リクエスト／結果」構造と関連する。
【００９４】
ＭＥからＵＩＣＣまで：Ｃｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、ｅｌｅｍｅｎｔ_ｔｙｐｅ、パス名、ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓ）
ＵＩＣＣからＭＥまで：Ｃｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名、ａｄｄｉｔｉｏｎａｌ_ｉｎｆｏ）
【００９５】
その中で使用されるパラメータは、以下の通りに定められる。
−ｅｎｔｉｔｙ_ｉｄ：「Ｃｒｅａｔｉｏｎリクエスト」を送信したエンティティを示す
−ｅｌｅｍｅｎｔ_ｔｙｐｅ：パーテションまたはディレクトリまたはファイル
−パス名：生成されるエレメントの「パス＋名前」を含む；例えば／パーテション／ｇｌｏｂａｌ_ｄｉｒｅｃｔｏｒｙ／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ
−ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓ：所定のエレメントタイプに特有のパラメータ；例えばパーテションの場合のサイズ、ファイルの場合のファイルタイプ、など… ）
−結果（ｒｅｓｕｌｔ）：リクエスト実行結果を含む（成功、失敗、修正して成功 … ）
−ａｄｄｉｔｉｏｎａｌ_ｉｎｆｏ：ＵＩＣＣが単純な実行結果より多くの情報を送るとき、このパラメータ（例えばＵＩＣＣがリクエストされたものと異なるサイズでパーテションをつくる場合に備えて）に、これらの追加のデータが含まれる
【００９６】
（パーテションまたはディレクトリまたはファイルを読むための）採用されるＲｅａｄ機能は、以下のリクエスト／結果構造と関係する。
【００９７】
ＭＥからＵＩＣＣまで： Ｒｅａｄ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名）
ＵＩＣＣからＭＥまで： Ｒｅａｄ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名、データ）
そして、ここでは、パラメータは以下のように定義される：
【００９８】
−ｅｎｔｉｔｙ_ｉｄ：読み出しリクエストを送信したエンティティを示す
−パス名：読み出されるエレメントの（パス＋名前）を含む
−結果：エレメントの読み出し結果（成功または失敗）
−データ：読み出されたエレメントを含む（例えば、ファイルが生成された場合における、読み出された「パーテション／ディレクトリまたは内容自体」のディレクトリとファイルのリストなど）
【００９９】
Ｕｐｄａｔｅ機能は提供されるが、ファイルと以下のリクエスト／結果構造に関するもののためだけに定義される。
【０１００】
ＭＥからＵＩＣＣまで： Ｕｐｄａｔｅ_Ｆｉｌｅ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名、ｄａｔａ_ｔｙｐｅ、データ）
ＵＩＣＣからＭＥまで： Ｕｐｄａｔｅ_Ｆｉｌｅ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名）
【０１０１】
ここでは、パラメータは以下から成る：
−ｅｎｔｉｔｙ_ｉｄ：更新リクエストを送ったエンティティを示す
−パス名：アップデートされるファイルの「パス＋名前」を含む。例えば「／パーテション／ｇｌｏｂａｌ_ｄｉｒｅｃｔｏｒｙ／ｄｉｒｅｃｔｏｒｙ１／ｉｍａｇｅ１.ｊｐｇ」など
−ｄａｔａ_ｔｙｐｅ：生成されたファイルのデータのタイプ（例えばｊｐｇ、ＭＰＥＧ、ｔｘｔ、その他）を示す
−データ：ファイルの内容
−結果：更新されたファイルの結果（成功または失敗）
【０１０２】
Ｒｅｎａｍｅ機能は、以下のリクエスト／結果構造に関連することができる。
【０１０３】
ＭＥからＵＩＣＣまで： Ｒｅｎａｍｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、ｏｌｄ_ｐａｔｈｎａｍｅ、ｎｅｗ_ｎａｍｅ）
ＵＩＣＣからＭＥまで： Ｒｅｎａｍｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、ｎｅｗ_ｐａｔｈｎａｍｅ）
そして、パラメータは以下のように定義される：
【０１０４】
−ｅｎｔｉｔｙ_ｉｄ：名前変更リクエストを送ったエンティティを示す
−ｏｌｄ_ｐａｔｈｎａｍｅ：名前を変えられたエレメントの元の「パス＋名前」を含む
−ｎｅｗ_ｎａｍｅ：名前を変えられたエレメントの新しい名前（経路はなし）を含む
−結果：名前変更実行結果（成功または失敗）
−ｎｅｗ_ｐａｔｈｎａｍｅ：名前を変更されたエレメントｍｐ「パス＋新しい名前」を含む
【０１０５】
Ｍｏｖｅ機能は、次のように具現化される
ＭＥからＵＩＣＣまで：Ｍｏｖｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、ｏｌｄ_ｐａｔｈｎａｍｅ、ｎｅｗ_ｐａｔｈｎａｍｅ）
ＵＩＣＣからＭＥまで：Ｍｏｖｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、ｎｅｗ_ｐａｔｈｎａｍｅ）
【０１０６】
そして、以下のパラメータ定義で定義される
−ｅｎｔｉｔｙ_ｉｄ： 動きリクエストを送信したエンティティを示す
−ｏｌｄ_ｐａｔｈｎａｍｅ： 動かされたエレメントの古い「パス＋名前」を含む
−ｎｅｗ_ｐａｔｈｎａｍｅ： 動かされたエレメントの新しい「パス＋名前」を含む
−結果：動き実行結果（成功または失敗）
【０１０７】
Ｄｅｌｅｔｅ機能は、例えばリクエスト／結果構造に従って同様に提供されることができる
ＭＥからＵＩＣＣまで：Ｄｅｌｅｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名）
ＵＩＣＣからＭＥまで：Ｄｅｌｅｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名）
【０１０８】
パラメータは、以下のように定義されることができる
−ｅｎｔｉｔｙ_ｉｄ：削除リクエストを送信したエンティティを示す
−パス名： 削除されるエレメントの「パス＋名前」を含む
−結果： 削除実行結果（成功または失敗）
【０１０９】
なお、パス名が、保護されている、ある親ディレクトリを含む場合、これらのディレクトリのアクセス条件は、このリクエストを処理する前に、最初に満たされなければならない点に留意する必要がある。
【０１１０】
Ｃｌｅａｎｉｎｇ機能は、オーナーが関連するパスワードを失った／忘れた場合（したがって、パーテション／ディレクトリ／ファイルにおけるいかなるデータにもアクセス不可）に、パーテション／ディレクトリ／ファイルを削除するために提供され、役立つこともできる。
パーテション／ディレクトリ／ファイルのオーナーだけが、この動作を実行することができる。
ＵＩＣＣは、ｅｎｔｉｔｙ_ｉｄがオーナーのｅｎｔｉｔｙ_ｉｄと一致し、以下のような「リクエスト／結果」構造に関係することをチェックしなければならない。
【０１１１】
ＭＥからＵＩＣＣまで：Ｃｌｅａｎ_Ｅｌｅｍｅｎｔ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、パス名）
ＵＩＣＣからＭＥまで：Ｃｌｅａｎ_Ｅｌｅｍｅｎｔ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、パス名）
【０１１２】
そして、パラメータは、以下のように定義されることができる：
−ｅｎｔｉｔｙ_ｉｄ：オーナーだけが、このリクエストを獲得することができる。
−パス名：クリーニング（すなわち削除される）エレメントの「パス＋名前」を含む
−結果：クリーニングリクエスト結果（成功または失敗）
【０１１３】
更なる機能は、例えば、リサイズパーテションに関して、以下の「リクエスト／結果」構造で提供されることもできる。
【０１１４】
ａ）リサイズパーテション
ＭＥからＵＩＣＣまで： Ｒｅｓｉｚｅ_Ｐａｒｔｉｔｉｏｎ_Ｒｅｑ（ｅｎｔｉｔｙ_ｉｄ、名前、ｎｅｗ_ｓｉｚｅ）
ＵＩＣＣからＭＥまで： Ｒｅｓｉｚｅ_Ｐａｒｔｉｔｉｏｎ_Ｒｅｓ（結果、ｅｎｔｉｔｙ_ｉｄ、ｎｅｗ_ａｌｌｏｃａｔｅｄ_ｓｉｚｅ）
【０１１５】
関連するパラメータは、以下のように定義されることができる：
−ｅｎｔｉｔｙ_ｉｄ：リサイズリクエストを送信したエンティティを示す
−名前：パーテションの名前
−ｎｅｗ_ｓｉｚｅ：パーテションのために新しく要求されたメモリサイズを含む
−結果：リサイズパーテションの結果（成功、失敗、修正して成功（例えば、割り当てられたサイズがリクエストされたサイズと異なる場合）
−ｎｅｗ_ａｌｌｏｃａｔｅｄ_ｓｉｚｅ：パーテションによってＵＩＣＣにより割り当てられた実際のメモリサイズを表わす
【０１１６】
これらのインターフェース機能は、必要に応じて組合せて提供されることは勿論である。
【０１１７】
さて、図３に戻って、図１のＵＩＣＣ１０のメモリ記憶装置内に生成されたディレクトリを生成するための信号のシーケンスに関する信号伝達のタイミングチャートを示す。
【０１１８】
信号のシーケンスは、エンド・ユーザ２６、例えば携帯電話機等のＭＥ２８、及び図１のＵＩＣＣ１０のようなＵＩＣＣ３０の間で発生するものである。
【０１１９】
図３に図示されるシーケンスは、既存のパーテション／ディレクトリにおけるディレクトリの生成のために、ユーザ２６からのリクエスト３２により発生し、そして、パスワード名、ドメイン及びパスワードを含む適切なリクエスト動作３４がＭＥ２８に送られる。
【０１２０】
もし、ドメインが「パブリック」であるとして要求されれば、ユーザ２６はパスワードをディレクトリに設定せず、よって「パスワード」パラメータは空文字列となる。
【０１２１】
次に、ＭＥ２８がＵＩＣＣ３０に、ｅｎｔｉｔｙ_ｉｄ、ｅｌｅｍｅｎｔ_ｔｙｐｅ、パス名、及びｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓを含むＣｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑｕｅｓｔ３６を渡す。
【０１２２】
本例において、ディレクトリ「ｅｌｅｍｅｎｔ_ｔｙｐｅ」の生成では、「ディレクトリ」、及び「ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓ」は、ヌル値を有することに注意すべきである。
【０１２３】
続く信号伝達の経過は、パスワード検証シーケンス３８を含む。これは、親ディレクトリに関連するが、親ディレクトリがパスワードによって保護されていない場合は要求されない。ただし、保護されている複数のディレクトリのレベルがある場合は、各ディレクトリに対するパスワードは検証されなければならない。
【０１２４】
パスワード検証シーケンス３８は、親−ディレクトリ−パスを含み、そのうえパスワードが要求される状態を確かめる、ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号４０により開始される。
【０１２５】
ＭＥ２８からＭＥユーザ２６へ、パスワードが要求される通知４２が送られると、順に、ＭＥユーザ２６からＭＥ２８へパスワード４４が送り返され、次に、ＭＥ２８からＵＩＣＣ３０に、ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号４６が送られる。ＵＩＣＣ３０は、次にＭＥ２８へ、ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ信号４８を送り、更なる信号伝達交換が、ＵＩＣＣ３０とＭＥ２８の間で行われる。ただし、もし、パスワード値がゼロであれば、このようなパスワード設定機能が生じ得ないことは当然であるが、この信号交換には、ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ結果信号５０、ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号５２、ｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔ信号５４、ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号５６、及びｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ信号５８が含まれる。
【０１２６】
シーケンスは、ＭＥ２８からユーザ２６に、生成ディレクトリ結果信号６０が送られて終了する。
【０１２７】
比較として、本発明における本実施例の特徴の更なる詳細が図４に示される。図４は、ファイル生成に関して生成される信号のシーケンスを示す。
【０１２８】
信号伝達もまた、ユーザ２６、ＭＥ２８、及びＵＩＣＣ３０に関して示される。
【０１２９】
この例では、エンド・ユーザがＭＥのカメラ機能を使用して写真を撮って、既存のパーテション／ディレクトリにその写真を保存することに決めて、ファイル生成リクエスト６４が、モバイル機器２８に送られる。これは、関連データに関するパス名、ドメイン、パスワード、及びｄａｔａ_ｔｙｐｅを含むファイル・リクエスト６４を生成する。
【０１３０】
その後、ＭＥ２８からＵＩＣＣ３０に、ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｔｙｐｅ６６が送られる。この中では、ファイルの生成のために、ｅｌｅｍｅｎｔ_ｔｙｐｅに「ファイル」が設定され、ｅｌｅｍｅｎｔ_ｐａｒａｍｅｔｅｒｓは、ＰＧまたはＭＰ３等のｆｉｌｅ_ｔｙｐｅと、データすなわちファイルそれ自体の内容が含まれる。
【０１３１】
もし、６８において、ファイルを生成するための場所に到着する前にパスワードによって保護されているディレクトリがあることが分かれば、例えば、図３に示したものを図４のシーケンスにも同様に適用する等して、各ディレクトリのパスワードは検証されなければならない。
【０１３２】
つまり、ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ７０がＵＩＣＣ ３０からＭＥ２８に送られる。これに応じて、ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号７２がＵＩＣＣ３０に送られ、ＵＩＣＣ３０がｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔｓ信号７４を開始する。ここで、パスワードがゼロ（ｎｕｌｌ）と設定されていないｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ ７６が、ＭＥ２８からＵＩＣＣ３０に送られるものとする。これに応じて、ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ７８がＵＩＣＣ３０からＭＥ２８へ送られる。そして、ＭＥ２８とＵＩＣＣ３０の間のこの信号伝達交換７０−７８のシグナリング交換の最後に、生成されたファイル結果表示８０がＭＥ２８からエンド・ユーザ２６に提供される。
【０１３３】
最後に図５及び図６について、保護されたファイルの読み出しを行おうとする場合に関する信号伝達図であって、正しいパスワードが使用される例（図５）と、比較として、アクセス条件が満たされない例（図６）をここに示す。
【０１３４】
最初に図５において、適切なエンティティ２６が、ＭＥ２８に対し、当該エンティティが「制限されたリード」ドメインに規定されたファイルを読むことを望む、読み出しファイル８４を提供する目的で、８２において指示８２を準備する。読み出しファイル指示８４内のパス名は、例えば「／ｐａｒｔｉｔｉｏｎ ／ｄｉｒｅｃｔｏｒｙ Ｉ／ｐｉｃｔｕｒｅ １.ｊｐｇ」のような、読み出されるまでの特定のパスを含む。
【０１３５】
続いて、ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ８６がＥ２８からＵＩＣＣ３０へ送られる。
【０１３６】
図５に示す範囲内では、パスワード検証シーケンス８８が、ファイルそのものと、そのうえ、パスワードで保護されている、前のディレクトリに適用される。この場合、図５に示されているような信号伝達及び指示９０−９８を含むパスワード検証シーケンスが提供される。
【０１３７】
最初に、ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号９０がＵＩＣＣ３０からＭＥ２８へ送られる。次に、パスワード要求指示９２がＭＥ２８からエンティティ２６へ送られ、検証されたパスワードａｔｔｅｍｐｔ９４が戻され、次に、ＭＥ２８からＵＩＣＣ３０へｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ９６を開始する。
【０１３８】
それから、検証ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ９８は、パスワード検証シーケンス８８を完了するため、ＵＩＣＣ３０からＭＥ２８へ送り返される。
【０１３９】
パスワードは検証されて、要求されたデータを含む読み出しエレメント結果１００がＵＩＣＣ３０からＭＥ２８へ送られ、要求されたデータを含む読み出されたエレメント結果が要求を出しているエンティティ２６へ送られる（１０２）。
【０１４０】
図６に戻って、１０４においてもう一つの異なるエンティティによって「プライベート」ドメインに定められるファイルを読むための、あるエンティティによる試みに関するシーケンスが例示される。読み出しファイル指示１０６はＭＥ２８に提供される。
【０１４１】
それから、ＭＥ２８からＵＩＣＣ３０へｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ１０８が送られる。このリクエストにおいては、当然のことながら、ｅｎｔｉｔｙ_ｉｄは、ファイルオーナーｅｎｔｉｔｙ_ｉｄと異なっている。
【０１４２】
ＵＩＣＣ３０は、ファイルのドメインが「プライベート」ドメインを含み、したがって、ファイルのオーナーだけがファイルにアクセスすることができるとわかる。受け取ったｅｎｔｉｔｙ_ｉｄがオーナーのｅｎｔｉｔｙ_ｉｄにマッチしないので、ＵＩＣＣ３０からＭＥ２８に送られたｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ１１０の中にあるリードリクエストは拒絶される。
【０１４３】
それから、読み出しファイル結果指示１１２は、ＭＥ２８からリクエストを出しているエンティティ２６へ送られる。そして、その中のデータ・パラメータがゼロ（ｎｕｌｌ）であり、結果は、読み出し失敗を示す。
【０１４４】
本発明が前述の具体化の詳細に限られていないことは勿論である。
【０１４５】
ＵＳＢスマートカードＩＣＣＤインターフェース・クラスで動作するアプリケーションのための実装（本明細書で説明したのと同様の特徴をサポートしている新しいＡＰＤＵコマンドの生成が含まれる）は、はっきりと記述されないが、上述したことと同じ特徴を、ＩＣＣＤクラス等に適用することができる。
【０１４６】
また、ＵＳＢ大容量記憶装置インターフェース・クラスをサポートしているＵＩＣＣを含むシナリオとして、あるエンティティ（例えばＭＥ）によってデータ・エレメントが保存され、そのようなＵＩＣＣがパスワード検証なしでアクセスできると、すなわち、データ・エレメント自体及びその親データ・エレメントに対してパスワードを要求されないと、ＵＩＣＣがＵＳＢ大量の記憶装置のように構成され動作し、ＰＣのようなデバイスに接続された時、このデータ・エレメントもまたアクセス可能とするべきである。
【０１４７】
ＵＩＣＣがＵＳＢ大量の記憶装置として構成され、パスワード検証プロセスをサポートしないデバイスに接続されているときは、パスワードで保護されているデータ・エレメントは、アクセスできない状態のままとしなければならない。
【０１４８】
すなわち、より詳細には、ＵＩＣＣが、具体的にＵＳＢ大量の記憶装置のように構成され、例えばＰＣのような遠隔装置に接続される場合は、ＵＩＣＣは、シンプルなＵＳＢメモリースティックのように振る舞うことができる。それから、パスワードなしで、すなわち上で概説される「パブリック」ドメインのように、ＭＥまたは実際に他のいずれの装置によって保存されたＵＩＣＣの上のデータ・エレメントは、ＰＣ上でアクセスできる状態のままでなければならない。
【０１４９】
しかし、パスワードによって保護されているデータ・エレメントのために、ＵＩＣＣが、メモリースティックのように振る舞い、ＰＣに接続されているとき、それらはアクセスできない状態にある。
【０１５０】
たとえば、ユーザが、ＭＥのカメラを使って写真を撮って、パスワードなしでＵＩＣＣ内に保存する。それからユーザがＵＩＣＣをＰＣに電気アダプターを介して接続するとき、ＵＩＣＣは、ＵＳＢメモリースティックのように振る舞い、この写真はＰＣ上でアクセス可能となる。しかし、ユーザがパスワードと共にこの写真を保存すれば、ＵＩＣＣがＰＣと接続されても、この写真は見ることができない。
【０１５１】
＜参照による取り込み＞
本明細書は、２００９年１月１６日に出願された英国特許出願番番号０９００６６４.４号の優先権を要求する。そして、参照によってその開示の全てをここに取り込む。
【符号の説明】
【０１５２】
１０ ＵＩＣＣ
１２ 処理機能
１４ 記憶領域
１６ インターフェース
１８ 携帯電話機
２０ プロセッサ
２２ スタンダード・メモリ
２４ 送信／受信機能
２９ ユーザ
２８ ＭＥ
３０ ＵＩＣＣ
３２ リクエスト
３４ 適切なリクエスト動作
３６ Ｃｒｅａｔｅ_Ｅｌｅｍｅｎｔ_Ｒｅｑｕｅｓｔ
３８ パスワード検証シーケンス８
４０ ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号ｌ０
４６ ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号ｌ６
４８ ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ信号ｌ８
５０ ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ結果信号ｌ０
５２ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号
５４ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔ信号
５６ ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ信号
６０ 生成ディレクトリ結果信号
６４ ファイル生成リクエスト
６６ ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ
７０ ｃｒｅａｔｅ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ
７２ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｑｕｅｓｔ信号
７４ ｓｅｔ_ｄｏｍａｉｎ_ｒｅｓｕｌｔｓ信号
７６ ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ
７８ ｓｅｔ_ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ
８０ ファイル結果徴候
８２ ａｔ２における指示
８４ 読み出しファイル指示
８６ ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ
９０ ａｃｃｅｓｓ_ｃｏｎｄｉｔｉｏｎ_ｎｏｔｉｆｉｃａｔｉｏｎ信号
９２ パスワードリクエスト指示
９４ 検証パスワード試み
９６ ｖｅｒｉｆｙ_ｐａｓｓｗｏｒｄ_ｒｅｑｕｅｓｔ
９８ 検証ｐａｓｓｗｏｒｄ_ｒｅｓｕｌｔ
１００ 読み出しエレメントリクエスト０
１０２ 届けられる
１０６ 読み出しファイル指示
１０８ ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｑｕｅｓｔ
１１０ ｒｅａｄ_ｅｌｅｍｅｎｔ_ｒｅｓｕｌｔ
１１２ 読み出しファイル結果指示
【特許請求の範囲】
【請求項１】
複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、
データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、
前記複数のデータ・エレメントのうち少なくとも１つは、前記ドメイン保護エレメント及びパスワード保護エレメントと関連するデータ保護方法。
【請求項２】
前記少なくとも１つのデータ・エレメントに対して前記許可された動作の開始にはパスワードが要求され、当該動作は、前記ドメイン保護エレメントにより定義されている請求項１記載のデータ保護方法。
【請求項３】
前記回路カードの１以上のアプリケーションにアクセスするためにＰＩＮコードを使用する請求項１又は２記載のデータ保護方法。
【請求項４】
前記複数のデータ・エレメントのそれぞれは、前記ドメイン保護エレメントに関連する請求項１乃至３のいずれか１項記載のデータ保護方法。
【請求項５】
前記許可された動作は、１以上のリード及び／ライト動作を含む前記ドメイン保護エレメントによって定義されたものである請求項１記載のデータ保護方法。
【請求項６】
前記回路カードでデータにアクセスすることができるエンティティは、一意の識別子に関連している請求項１記載のデータ保護方法。
【請求項７】
更に、前記データ・エレメントを生成するエンティティの識別子が保存されている請求項６に記載のデータ保護方法。
【請求項８】
前記回路カードは、前記データ・エレメントの前記エンティティの識別子を保存するために配置される請求項６又は７記載のデータ保護方法。
【請求項９】
ＭＥの中で、前記データへのアクセスを要求するエンティティを識別する請求項６、７及び８のいずれか１項記載のデータ保護方法。
【請求項１０】
前記データ保護は、ＵＳＢインターフェースがＭＥと前記回路カードとの間で起動された時、ＵＳＢインターフェース・クラスに適用される請求項１記載のデータ保護方法。
【請求項１１】
前記回路カード上の前記データ・エレメントが、スタンダードファイルフォーマットファイルにしたがって保存される請求項１に記載のデータ保護方法。
【請求項１２】
前記回路カード内の前記データ・エレメントの生成及び管理は、ＭＥ経由で制御されている請求項１に記載のデータ保護方法。
【請求項１３】
ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能を有する請求項１記載のデータ保護方法。
【請求項１４】
前記回路カードは、ＵＩＣＣを有する請求項１乃至１３のいずれか１項記載のデータ保護方法。
【請求項１５】
複数の保護可能なデータ・エレメントが保存された回路カードであって、
データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに関連して配置された、少なくとも１つの前記複数の保護可能なデータ・エレメントを有する回路カード。
【請求項１６】
前記ドメイン保護エレメントによる許可された動作を開始するために、パスワードが要求される請求項１５に記載の回路カード。
【請求項１７】
前記複数のデータ・エレメントのそれぞれは、ドメイン保護エレメントに関連している請求項１５に記載の回路カード。
【請求項１８】
前記回路カードは、ＵＳＢインターフェース・クラスを経由して前記データ・エレメントにアクセスを許可するように構成される請求項１５乃至１７のいずれか１項記載の回路カード。
【請求項１９】
ＵＩＣＣを更に含んでいる請求項１５乃至１８のいずれか１項記載の回路カード。
【請求項２０】
回路カードがＵＳＢ大容量記憶装置を構成し、遠隔装置に接続するよう構成され、もし、パスワード検証機構をサポートしていない場合は、パスワード保護エレメントと関連していないデータ・エレメントは、前記遠隔装置によりアクセス可能であり、パスワード保護エレメントと関連しているデータ・エレメントは、前記遠隔装置によりアクセス不可である請求項１５乃至１９のいずれか１項記載の回路カード。
【請求項２１】
請求項１５乃至２０のいずれか１つに定義された回路カードで動作するよう構成された移動無線通信装置。
【請求項２２】
前記移動無線通信装置は、ＵＳＢインターフェース・クラス経由で前記回路カードと通信するよう構成される請求項２１記載の移動無線通信装置。
【請求項２３】
前記移動無線通信装置は、前記保存されているデータ・エレメントを生成及び／又は管理するよう構成される請求項２１又は２２記載の移動無線通信装置。
【請求項１】
複数のデータ・エレメントの格納部が配置された回路カードのデータ保護の方法であって、
データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントのいずれかに基づき保護を提供するものであって、
前記複数のデータ・エレメントのうち少なくとも１つは、前記ドメイン保護エレメント及びパスワード保護エレメントと関連するデータ保護方法。
【請求項２】
前記少なくとも１つのデータ・エレメントに対して前記許可された動作の開始にはパスワードが要求され、当該動作は、前記ドメイン保護エレメントにより定義されている請求項１記載のデータ保護方法。
【請求項３】
前記回路カードの１以上のアプリケーションにアクセスするためにＰＩＮコードを使用する請求項１又は２記載のデータ保護方法。
【請求項４】
前記複数のデータ・エレメントのそれぞれは、前記ドメイン保護エレメントに関連する請求項１乃至３のいずれか１項記載のデータ保護方法。
【請求項５】
前記許可された動作は、１以上のリード及び／ライト動作を含む前記ドメイン保護エレメントによって定義されたものである請求項１記載のデータ保護方法。
【請求項６】
前記回路カードでデータにアクセスすることができるエンティティは、一意の識別子に関連している請求項１記載のデータ保護方法。
【請求項７】
更に、前記データ・エレメントを生成するエンティティの識別子が保存されている請求項６に記載のデータ保護方法。
【請求項８】
前記回路カードは、前記データ・エレメントの前記エンティティの識別子を保存するために配置される請求項６又は７記載のデータ保護方法。
【請求項９】
ＭＥの中で、前記データへのアクセスを要求するエンティティを識別する請求項６、７及び８のいずれか１項記載のデータ保護方法。
【請求項１０】
前記データ保護は、ＵＳＢインターフェースがＭＥと前記回路カードとの間で起動された時、ＵＳＢインターフェース・クラスに適用される請求項１記載のデータ保護方法。
【請求項１１】
前記回路カード上の前記データ・エレメントが、スタンダードファイルフォーマットファイルにしたがって保存される請求項１に記載のデータ保護方法。
【請求項１２】
前記回路カード内の前記データ・エレメントの生成及び管理は、ＭＥ経由で制御されている請求項１に記載のデータ保護方法。
【請求項１３】
ＭＥ回路カード・インターフェース機能は、生成機能、リード機能、更新機能、改名機能、動作機能、削除機能、及びクリーニング機能のうちいずれか１以上の機能を有する請求項１記載のデータ保護方法。
【請求項１４】
前記回路カードは、ＵＩＣＣを有する請求項１乃至１３のいずれか１項記載のデータ保護方法。
【請求項１５】
複数の保護可能なデータ・エレメントが保存された回路カードであって、
データ・エレメントに許可される動作を定義するためのドメイン保護エレメント、及びデータ・エレメントへのアクセスを制御するためのパスワード保護エレメントに関連して配置された、少なくとも１つの前記複数の保護可能なデータ・エレメントを有する回路カード。
【請求項１６】
前記ドメイン保護エレメントによる許可された動作を開始するために、パスワードが要求される請求項１５に記載の回路カード。
【請求項１７】
前記複数のデータ・エレメントのそれぞれは、ドメイン保護エレメントに関連している請求項１５に記載の回路カード。
【請求項１８】
前記回路カードは、ＵＳＢインターフェース・クラスを経由して前記データ・エレメントにアクセスを許可するように構成される請求項１５乃至１７のいずれか１項記載の回路カード。
【請求項１９】
ＵＩＣＣを更に含んでいる請求項１５乃至１８のいずれか１項記載の回路カード。
【請求項２０】
回路カードがＵＳＢ大容量記憶装置を構成し、遠隔装置に接続するよう構成され、もし、パスワード検証機構をサポートしていない場合は、パスワード保護エレメントと関連していないデータ・エレメントは、前記遠隔装置によりアクセス可能であり、パスワード保護エレメントと関連しているデータ・エレメントは、前記遠隔装置によりアクセス不可である請求項１５乃至１９のいずれか１項記載の回路カード。
【請求項２１】
請求項１５乃至２０のいずれか１つに定義された回路カードで動作するよう構成された移動無線通信装置。
【請求項２２】
前記移動無線通信装置は、ＵＳＢインターフェース・クラス経由で前記回路カードと通信するよう構成される請求項２１記載の移動無線通信装置。
【請求項２３】
前記移動無線通信装置は、前記保存されているデータ・エレメントを生成及び／又は管理するよう構成される請求項２１又は２２記載の移動無線通信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２０１２−５１５３７２（Ｐ２０１２−５１５３７２Ａ）
【公表日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願番号】特願２０１１−５３０３１２（Ｐ２０１１−５３０３１２）
【出願日】平成２１年１２月２８日（２００９．１２．２８）
【国際出願番号】ＰＣＴ／ＪＰ２００９／０７１９２６
【国際公開番号】ＷＯ２０１０／０８２４５０
【国際公開日】平成２２年７月２２日（２０１０．７．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公表日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願日】平成２１年１２月２８日（２００９．１２．２８）
【国際出願番号】ＰＣＴ／ＪＰ２００９／０７１９２６
【国際公開番号】ＷＯ２０１０／０８２４５０
【国際公開日】平成２２年７月２２日（２０１０．７．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]