(57)【要約】方法は特に電気通信端末と協働するセキュリティエレメント（３０）を更新する方法に関し、更新は、セキュリティエレメント（３０）によって策定された問い合わせに基づいて、ＯＴＡプラットフォーム（３１）によって実行され、セキュリティエレメント（３０）はＰＳＫ−ＩＤをＯＴＡプラットフォーム（３１）に送信し、方法は、ＯＴＡプラットフォーム（３１）が同じ問い合わせを処理する要求の優先順位を規定するアイデンティティＩＤを、セキュリティエレメント（３０）からＯＴＡプラットフォーム（３１）に送信することを含む。【選択図】  図２
2019520002.tif 000002
【特許請求の範囲】
【請求項１】
電気通信端末と相互作用するセキュリティエレメント（３０）を更新する方法であって、前記更新が前記セキュリティエレメント（３０）からの要求に基づいてＯＴＡプラットフォーム（３１）により実行され、前記セキュリティエレメント（３０）がＰＳＫ ＩＤを前記ＯＴＡプラットフォーム（３１）に送信し、前記ＰＳＫ ＩＤがアイデンティティ（ＩＤ）を含み、
前記アイデンティティ（ＩＤ）が、前記セキュリティエレメントによって策定された、前記ＯＴＡプラットフォーム（３１）への要求の優先順位を規定することを特徴とする方法。
【請求項２】
前記ＰＳＫ ＩＤをプロキシサーバ（３２）を介して前記ＯＴＡプラットフォーム（３１）に送信することを含む、請求項１に記載の方法。
【請求項３】
前記プロキシサーバ（３２）が、前記アイデンティティ（ＩＤ）が前記プロキシサーバ（３２）に格納されている値より高い優先順位を有する場合に、前記要求を前記ＯＴＡプラットフォーム（３１）に転送する前に前記アイデンティティ（ＩＤ）に基づいてフィルタリングする、請求項２に記載の方法。
【請求項４】
前記アイデンティティ（ＩＤ）が、ＩＤを追加及び削除するだけでなく、前記優先順位を変更するためにＯＴＡ（３１）で変更可能である、請求項１乃至３のいずれかに記載の方法。
【請求項５】
電気通信端末と相互作用するセキュリティエレメント（３０）であって、前記セキュリティエレメント（３０）が、前記セキュリティエレメント（３０）とリモートプラットフォーム（３１、３２）の間にセキュアチャネルを確立するために、ＰＳＫ ＩＤを前記リモートプラットフォーム（３１、３２）に送信するように構成され、
前記ＰＳＫ ＩＤのアイデンティティ（ＩＤ）が、前記セキュリティエレメントによって策定された前記リモートプラットフォーム（３１、３２）への要求が考慮されることを要求する優先順位を規定することを特徴とするセキュリティエレメント（３０）。
【請求項６】
前記リモートプラットフォームがＯＴＡプラットフォーム（３１）である、請求項５に記載のセキュリティエレメント（３０）。
【請求項７】
前記リモートプラットフォームが、前記セキュリティエレメント（３０）とＯＴＡプラットフォーム（３１）の間に配置されたプロキシ（３２）である、請求項５に記載のセキュリティエレメント（３０）。
【請求項８】
端末と相互作用するセキュリティエレメント（３０）を管理するように設計されたＯＴＡプラットフォーム（３１）であって、前記セキュリティエレメント（３０）が前記ＯＴＡプラットフォーム（３１）に更新要求を送信し、前記ＯＴＡプラットフォーム（３１）が前記セキュリティエレメント（３０）を管理する手段（５１）を備え、
前記ＯＴＡプラットフォーム（３１）が前記要求をフィルタリングする手段（５０）を備え、前記要求がＰＳＫ ＩＤを含み、前記ＰＳＫ ＩＤのアイデンティティ（ＩＤ）が、前記ＯＴＡプラットフォーム（３１）によって前記要求が考慮されることを要求する優先順位を規定し、前記フィルタリングする手段（５０）が、前記管理する手段（５１）が前記要求を発した前記セキュリティエレメント（３０）を管理できるように、前記ＰＳＫ ＩＤの前記アイデンティティ（ＩＤ）が基準値未満の前記要求のみを、前記セキュリティエレメント（３０）を管理する手段（５１）に送信することを特徴とするＯＴＡプラットフォーム（３１）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信の分野に係り、より具体的には、例えば電話機、スマートフォン、ＰＤＡやコンピュータなどの端末、携帯端末と相互作用するＵＩＣＣ（汎用集積回路カード）などのセキュリティエレメントのリモート管理の分野に関する。セキュリティエレメントは、Ｍ２Ｍ（マシンツーマシン）の領域におけるようなマシン内の集積回路の形をとってもよい。セキュリティエレメントは、必ずしも物理的に端末に接続されているわけではないが、セキュリティエレメントが遠隔で短距離チャネルを介して端末と通信する短距離リンク（例えばＢｌｕｅｔｏｏｔｈ（登録商標）又はＷｉｆｉ）を介して端末と通信することができる。
【背景技術】
【０００２】
このようなセキュリティエレメントの管理は、一般的にセキュリティエレメントにおいてデータ又はプログラムを更新又はインストールするためにＯＴＡ（無線）で行われる。この種の管理は、ｈｔｔｐプロトコル（ハイパーテキスト転送プロトコル）又はＳＭＳ（ショートメッセージサービス）を使用することができる。
【０００３】
セキュリティエレメントを管理する２つの方法がある。
【０００４】
第１の方法は、例えば更新キャンペーン中にデータ又はプログラムをＯＴＡプラットフォームから目標のセキュリティエレメントに送信することを含む。この種の管理は「プッシュ（ｐｕｓｈ）」として知られており、ＳＭＳモードでの伝送に基づいている。この方法に関する問題は、ＳＭＳをサポートしていない（これは完全にｈｔｔｐである）純粋なＬＴＥネットワークなどの新世代ネットワークに適合しないことである。さらに、ＳＭＳなどの信頼性が低いプロトコルを回避するために、ｈｔｔｐによるＲＡＭ又はＲＦＭタイプ管理が開発されている。
【０００５】
第２の方法は、利用できる更新があるかどうかを調べるために、例えば、定期的に又はイベントの発生時にＯＴＡプラットフォームに問い合わせを行うことを含む。この問い合わせはセキュリティエレメントによって開始され、“ポーリング（polling）”又は“プル（pull）”と呼ばれている（セキュリティエレメントはＯＴＡプラットフォームが送信すべきものを持っているかどうかを確認する）。問い合わせはｈｔｔｐプロトコルを介して行われる。
【０００６】
図１は、この原理に基づいてセキュリティエレメントを管理するためのシステムを示している。
【０００７】
この図において、セキュリティエレメント１０はＯＴＡプラットフォーム１１又はサーバによって管理される。
【０００８】
セキュリティエレメント１０は、図示されていない電気通信端末と相互作用する。
【０００９】
プロセスは、セキュリティエレメント１０の主導でＯＴＡプラットフォーム１１に問い合わせを行い、ＯＴＡプラットフォーム１１がセキュリティエレメント１０に送信すべきデータ又はプログラムを有しているかどうかを調べる段階１２から始まる。図示されている全てのやりとりは、ＳＣＰ８１プロトコルに従って実行される。
【００１０】
段階１３において、サーバ１１は、セキュリティエレメント１０の要求を受信した旨の応答をセキュリティエレメント１０に対して行い、段階１４においてこの受信を確認する。
【００１１】
段階１５において、セキュリティエレメント１０はサーバ１１にＰＳＫ ＩＤを送信する。ＰＳＫ ＩＤは、セキュリティエレメント１０とサーバ１１の間で共有され、アイデンティティ（ＩＤ）と関連付けられたあらかじめ設定された鍵（ＰＳＫ）を指す。このＰＳＫ鍵によって、サーバ１１はセキュリティエレメント１０を識別する。
【００１２】
有利には、アドレスｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４２７９で入手可能なＩＥＴＦ勧告を参照すべきである。
【００１３】
段階１６において、セキュリティエレメント１０は暗号スイート、例えばＡＥＳ１２８や３ＤＥＳスイートを選択する。
【００１４】
サーバ１１は、段階１７において、提案された暗号スイートを受け入れた後、段階１８において、セキュリティエレメント１０とのハンドシェイクチャネルの確立を終了させる。
【００１５】
その後段階１９は、このようにして確立されたセキュアなＴＬＳ−ＰＳＫチャネルでデータ交換を行うことを含む。特に、この段階１９において、セキュリティエレメント１０は、要求理由（単純なデータ更新、最初の使用の場合のセキュリティエレメント１０のアクティブ化）に対応するＵＲＬをサーバ１１に送信する。
【００１６】
この解決策に関する問題は、一般にセキュリティエレメント１０が、ＯＴＡプラットフォーム１１に問い合わせするためのイベントの発生を待たないことである。したがって、「ポーリング」は定期的、例えば１５日毎又は月毎に行われ、ほとんどの時間、ＯＴＡプラットフォーム１１はセキュリティエレメント１０に対して送信すべきものを持っていない。例えば、出願人は、この分野でセキュリティエレメント１０によるＯＴＡプラットフォーム１１への問い合わせの９０％で、更新やプログラム又はデータがセキュリティエレメント１０に送信されることはないということに気付いた。これは、不必要な無線トラフィックとＯＴＡプラットフォームの過負荷とをもたらす（セキュリティエレメントの問い合わせ毎にＴＬＳ−ＰＳＫリンクがセキュリティエレメントとＯＴＡプラットフォームの間に確立される）。したがって、通例、２０で参照される段階１２から１８は、大抵の場合不必要である。
【００１７】
別の問題は、ＯＴＡプラットフォーム１１が、全てが同じ緊急度を有するわけではない様々なタスクに常に使用されていることである。例えば、加入者が自身のＰＬＭＮ（公衆陸上移動体ネットワーク−セキュリティエレメント１０がローミングの際に接続するのが好ましい外国のネットワークのリスト）を更新するより、素早く呼び出しする（例えば自身の連絡帳をダウンロードする又は完全なサブスクリプションをダウンロードする）ことができるように、セキュリティエレメント１０を（加入者が初めて端末に挿入したときに）初期化することが重要である。
【００１８】
したがって、緊急の要求とそうでないものの処理に区別がない。この場合、他のセキュリティエレメントからの緊急性が低い他の要求に圧倒される場合に、緊急に更新する必要があるセキュリティエレメント１０からの接続要求をＯＴＡサーバ１１に拒否させる可能性がある。
【００１９】
また、データセンター（例えば移動体オペレータがともにそのサービスを位置付けるセキュリティエレメント製造業者のデータセンター）の内部ネットワークがセキュリティエレメントの更新に関与する場合、このネットワークにも不要な負担がかかることになる。さらに、このネットワークが物理的に分散されたサーバを使用する場合、追加の通信が付加されることになる。
【００２０】
第２の動作方法のこの欠点を克服するために、２つの解決策が可能である：
−２つのＯＴＡプラットフォームの問い合わせ（「ポーリング」）間の期間を延長すること。（セキュリティエレメントのアプリケーションを更新してこの期間を延長する）。この欠点は、更新が前回の問い合わせの直後に利用可能となった場合に、セキュリティエレメントがずっと後になってようやく更新されることである。
−“プッシュ”モードに切替えること。この場合、前述の問題に再び直面する。
【発明の概要】
【発明が解決しようとする課題】
【００２１】
より詳細には、本発明はこれらの欠点を克服することを目的とする。
【課題を解決するための手段】
【００２２】
より具体的には、本発明は、特に電気通信端末と相互作用するセキュリティエレメントを更新する方法であって、更新がセキュリティエレメントの要求に基づいてＯＴＡプラットフォームによって実行され、セキュリティエレメントがＰＳＫ ＩＤをＯＴＡプラットフォームに送信し、プロセスが、ＯＴＡプラットフォームにより要求が考慮されることを要求する優先順位を規定するアイデンティティ（ＩＤ）をセキュリティエレメントからＯＴＡプラットフォームに送信することを含む方法に関する。
【００２３】
好ましい実施形態において、この方法は、ＰＳＫ ＩＤをプロキシサーバを介してＯＴＡプラットフォームに送信することを含む。
【００２４】
有利には、プロキシサーバは、アイデンティティ（ＩＤ）がプロキシサーバに格納されている値より高い優先順位を有する場合に、ＯＴＡプラットフォームに転送する前にアイデンティティ（ＩＤ）に基づいて要求をフィルタリングする。
【００２５】
好ましくは、アイデンティティ（ＩＤ）は、ＩＤを追加及び削除するだけでなく優先順位を変更するために、ＯＴＡで変更されてよい。
【００２６】
本発明はまた、電気通信端末と相互作用するセキュリティエレメントであって、セキュリティエレメントが、セキュリティエレメントとリモートプラットフォームの間にセキュアチャネルを確立するためにＰＳＫ ＩＤをリモートプラットフォームに送信するように構成され、アイデンティティ（ＩＤ）が、リモートプラットフォームによって要求が考慮されることを要求する優先順位を規定するセキュリティエレメントに関する。
【００２７】
有利な実施形態において、リモートプラットフォームはＯＴＡプラットフォームである。
【００２８】
別の実施形態において、リモートプラットフォームはセキュリティエレメントとＯＴＡプラットフォームの間に配置されたプロキシである。
【００２９】
本発明はまた、端末と相互作用するセキュリティエレメントを管理するように設計されたＯＴＡプラットフォームであって、セキュリティエレメントが更新要求をＯＴＡプラットフォームに送信し、ＯＴＡプラットフォームがセキュリティエレメントを管理する手段を備え、プラットフォームが要求をフィルタリングする手段を備え、要求がＰＳＫ ＩＤを含み、ＰＳＫ ＩＤのアイデンティティ（ＩＤ）が、ＯＴＡプラットフォームによって要求が考慮されることを要求する優先順位を規定し、フィルタリングする手段が、管理する手段が要求を発したセキュリティエレメントを管理できるように、ＰＳＫ ＩＤのアイデンティティ（ＩＤ）が基準値未満の要求のみを、セキュリティエレメントを管理する手段に送信するＯＴＡプラットフォームに関する。
【図面の簡単な説明】
【００３０】
本発明の他の特徴及び利点は、非制限的な例として与えられ、添付の図面を参照する２つの好ましい実施形態の以下の説明を読めば明らかになるだろう。
【００３１】
【図１】技術水準を示す図。
【図２】本発明の第１の実施形態を示す図。
【図３】本発明の第２の実施形態を示す図。
【図４】セキュリティエレメントの管理要求が拒否された場合に本発明がどのように機能するかを示す図。
【図５】本発明に係るＯＴＡプラットフォームを示す図。
【発明を実施するための形態】
【００３２】
図１は技術水準を参照して以上で説明された。図２は本発明の第１の実施形態を示す。
【００３３】
この第１の実施形態では、セキュリティエレメント３０がプロキシサーバ３２を介してＯＴＡプラットフォーム３１に問い合わせを行い、ＯＴＡプラットフォームにセキュリティエレメントに送信すべきデータがあるかどうかを尋ねる。ここでいう「データ」という用語は広い意味で用いられ、プログラム、サブスクリプションデータ（セキュリティドメインを含む新しいサブスクリプションのためのＩＭＳＩ／Ｋｉ及び対応する鍵）の送信、又はデータやプログラムの単純な更新を含む場合がある。
【００３４】
段階３３から３６は、図１の段階１２から１５と同様である。すなわち
−セキュリティエレメント３０はプロキシサーバ３２に接触し（段階３３）；
−プロキシサーバ３２は応答し（段階３４）；
−プロキシサーバ３２は応答を確認し（段階３５）；
−セキュリティエレメント３０はＰＳＫ ＩＤをプロキシサーバ３２に送信する（段階３６）。
【００３５】
段階３６の特徴は、セキュリティエレメント３０とＯＴＡプラットフォーム３１との間で共有されるＰＳＫ鍵のアイデンティティ（ＩＤ）が、上記ＯＴＡプラットフォーム３１によってその要求が考慮されることを要求する優先順位を規定することである。
【００３６】
セキュリティエレメントの各ＰＳＫ鍵に対して、各々が優先順位に対応するいくつかのＩＤが提供される。
【００３７】
一例として、セキュリティエレメントのＰＳＫ鍵が１２３４５である場合、複数のアイデンティティがこの同じ鍵に割り当てられる。したがって、例えば下記のＰＳＫ ＩＤが得られる：
−  １２３４５−１
−  １２３４５−２
−  １２３４５−３
−  １２３４５−Ｎ
【００３８】
ここで、１は最も優先度が高いＩＤであり、Ｎは最も優先度が低いＩＤである。優先度は、ＯＴＡプラットフォーム３１にセキュリティエレメント３０が発した要求をより大きい順位のＩＤに優先して処理するように要求するアイデンティティ（ＩＤ）を意味する。
【００３９】
優先順位が第１位のアイデンティティ（ＩＤ）は、例えばサブスクリプションメンバーシップのためのオペレータパラメータを用いて初期化せよとのセキュリティエレメントの要求に関連する場合がある。そしてオペレータは、加入者にとって特に重要なこの要求を（後述するとおり）ＯＴＡプラットフォーム３１を介して優先して処理する。
【００４０】
優先順位が第２位のアイデンティティ（ＩＤ）は、例えば加入者からの電話帳ダウンロード要求に対応する場合がある。この動作は上述の動作より重要性が低い。
【００４１】
優先順位が第３位のアイデンティティ（ＩＤ）は、セキュリティエレメント３０がローミングの際に接続するのが好ましい推奨ネットワークのリストのダウンロード要求に対応する場合がある。
【００４２】
ＩＤは、セキュリティエレメント３０においてＯＴＡで変更可能であることが好ましい。したがって、ＩＤを追加及び削除するだけでなく優先順位を変更することも可能である。
【００４３】
プロキシサーバ３２の機能は、セキュリティエレメントが発する要求のプレフィルタリングを実行することである。プロキシサーバ３２は、所定の値を上回るＩＤを有するセキュリティエレメントが発した要求を体系的に拒否するように構成することができる。このため、プロキシサーバ３２は、ＯＴＡプラットフォーム３１の負荷状況を認識し、これに応じてセキュリティエレメントからの要求をフィルタリングする。プロキシサーバ３２は、プラットフォームの負荷状況が分からない場合、その使用に関する統計を取ることによって負荷状況をシミュレーションすることができる。セキュリティエレメントからの要求の（そのＩＤによって規定される）優先度が十分に高い場合、プロキシサーバは、段階３７において、段階３６において受信したＰＳＫ ＩＤをＯＴＡサーバ３１に送信する。
【００４４】
したがって、プロキシサーバ３２は、アイデンティティ（ＩＤ）がプロキシサーバ３２に格納されている値より高い優先順位を有する場合に、ＯＴＡプラットフォーム３１に転送する前にアイデンティティ（ＩＤ）に基づいてセキュリティエレメントの要求をフィルタリングする。したがって、プロキシサーバ３２は、ＯＴＡプラットフォーム３１を「ポーリングする」セキュリティエレメント間のＴＬＳ−ＰＳＫセッションの確立に本質的に起因する不要なデータトラフィックを回避することを可能にする。
【００４５】
段階３８において、セキュリティエレメント３０は、暗号スイート、例えばＡＥＳ１２８や３ＤＥＳスイートを選択する。この段階は段階３７に先行することもできる。
【００４６】
ＯＴＡプラットフォーム３１が、セキュリティエレメント３０が策定した要求を実行することを（その負荷レベル及びセキュリティエレメントの要求に割り当てられた優先度に応じて）認める場合、プラットフォームは、段階３９においてセッション鍵をプロキシサーバ３２に送信し、プロキシサーバ３２は段階４０においてセッション鍵をセキュリティエレメント３０に転送する。
【００４７】
段階４１において、プロキシサーバ３２は、セキュリティエレメントとのＴＬＳ−ＰＳＫセッションを確立する段階を終了させ、セキュリティエレメントは、その後プロキシサーバ３２を介してＯＴＡサーバ３１と対話可能になる（段階４２及び４３）。それからプロキシサーバ３２は代理（仲介）のみを行う。これらの段階（４２及び４３）において、セキュリティエレメント３０は、（図１の段階１９と同様に）その要求に対応するＵＲＬを送信する。
【００４８】
代替的に、プロキシサーバ３２は、段階３３の後、ＯＴＡプラットフォーム３１に問い合わせを行い、ビジーかどうかを確認することができる。ＯＴＡサーバはビジーである場合にその旨をプロキシサーバに伝える。次にプロキシサーバ３２は、ＯＴＡサーバがプロキシサーバに利用可能であることを伝えるまで、その要求を繰り返すのを少し待つ。プロキシサーバ３２は、その後段階３５において、（段階３６において送信されるＰＳＫ ＩＤがプロキシサーバ３２及びＯＴＡプラットフォーム３１に受け入れられるならば）その要求に応える用意があることをセキュリティエレメントに通知する。
【００４９】
図３は、本発明の第２の実施形態を示している。
【００５０】
この実施形態では、セキュリティエレメントは、プロキシサーバを介在させずにＯＴＡプラットフォームに直接アクセスする。
【００５１】
セキュリティエレメント３０は、参照される図２で参照した段階に従ってＯＴＡプラットフォーム３１と対話する。段階３６においてセキュリティエレメント３０のＰＳＫ ＩＤを受信した後、以下で説明されるＯＴＡプラットフォームに含まれたフィルタリング手段が要求のアイデンティティ（ＩＤ）を解析し、要求を発したセキュリティエレメント３０を管理できるようにアイデンティティ（ＩＤ）が基準値未満である場合にのみこの要求を受け入れる。
【００５２】
したがって、例えばプラットフォーム３１に送信されたアイデンティティ（ＩＤ）が２に等しく、基準値が３に等しい場合、セキュリティエレメントの管理要求は受け入れられ、プラットフォーム３１は、段階３９においてセキュリティエレメントにセッション鍵を送信する。逆に、プラットフォーム３１に送信されたアイデンティティ（ＩＤ）が４に等しく、基準値が３に等しい場合、セキュリティエレメントの管理要求は拒否される（フィルタリング手段によりフィルタリングされ、セキュリティエレメント３０を管理する機能を有するプラットフォームのエレメントに送信されない）。
【００５３】
図４は、セキュリティエレメントの管理要求が拒否される場合を示している。
【００５４】
この図では、段階３３から３６が図２及び３に示すものと同一である。
【００５５】
段階３６においてアイデンティティ（ＩＤ）を受信すると、フィルタリング手段は、ＯＴＡプラットフォームのセキュリティエレメントを管理する手段はセキュリティエレメント３０を管理できないと認め、段階４３において、このセキュリティエレメントに管理が失敗したことを示すメッセージを返す。次にセキュリティエレメント３０は、ＯＴＡプラットフォーム３１に問い合わせを行う将来の「ポーリング」セッションを待つ（段階３３）。
【００５６】
図５は、本発明に従うＯＴＡプラットフォームを示している。
【００５７】
本発明に係るＯＴＡプラットフォーム３１は、フィルタリング手段５０と、セキュリティエレメントを管理する手段５１とを備える。フィルタリング手段は、特に、セキュリティエレメントのＰＳＫ ＩＤを受信し、ＰＳＫ ＩＤからアイデンティティ（ＩＤ）を取り出し、受信したアイデンティティが基準値ＲＥＦより小さいかどうか（又は場合により大きいかどうか）をチェックする。基準値ＲＥＦは、例えば負荷状況（アクティビティ）に応じて管理手段５１によりフィルタリング手段５０に提供される。
【００５８】
基準値ＲＥＦは、有利には、例えばトラフィックのピーク時（例えば販売期間）に低くなり、トラフィックレベルが低い期間（例えば夜）に高くなるように、ＯＴＡプラットフォーム又はプロキシの管理中に変更可能である。
【００５９】
フィルタリング手段５０は、アイデンティティ（ＩＤ）が基準値未満の要求のみを、これらの管理手段５１が要求を発したセキュリティエレメントを管理できるように、セキュリティエレメントを管理する手段５１に送信する。したがって、フィルタリング手段５０は「ファイアウォール」として機能する。
【００６０】
これに関して、フィルタリング手段５０が受信したアイデンティティ（ＩＤ）が基準値ＲＥＦ未満である場合、要求は、管理手段５１が段階３９においてこのＰＳＫ ＩＤを発したセキュリティエレメントにセッション鍵を送信できるように、受信したＰＳＫ ＩＤを段階５２において管理手段５１に送信するフィルタリング手段５０により受け入れられる。そうでない場合、フィルタリング手段５０は、管理が失敗したことを示すメッセージをセキュリティエレメントに送信する（図４の段階４３参照）。
【００６１】
したがって、フィルタリング手段は、受信したアイデンティティ（ＩＤ）を基準値ＲＥＦと比較する簡易な比較器を備える。
【００６２】
本発明はまた、それ自身のニーズ及び／又はユーザのニーズに応じて異なるＩＤを生成可能な、ＳＩＭ、ＵＩＣＣ又はｅＵＩＣＣカードなどのセキュリティエレメントに関する。
【００６３】
ＵＩＣＣのニーズは、例えばその所有者が初めてこれを端末に挿入し、確定的なサブスクリプションを含まない（オペレータネットワーク、又はオペレータへの完全なサブスクリプションを提供できる専用プラットフォームに接続することを可能にする、いわゆる「ブートストラップ」アプリケーションしか含まない）場合に検出可能である。セキュリティエレメントが海外にあることを検出すると、推奨ネットワークのリストの自動要求を生成することもできる。
【００６４】
これらの異なるＩＤはセキュリティエレメントに格納されており、各ＩＤは、その要求がリモートプラットフォームによって考慮される優先順位を規定する。このリモートプラットフォームは、例えばＯＴＡプラットフォーム（図３）や、セキュリティエレメントとＯＴＡプラットフォームの間に配置されたプロキシ（図２）である。
【図１】
2019520002.tif 000003
【図２】
2019520002.tif 000004
【図３】
2019520002.tif 000005
【図４】
2019520002.tif 000006
【図５】
2019520002.tif 000007
【国際調査報告】
2019520002.tif 000008
2019520002.tif 000009
2019520002.tif 000010
2019520002.tif 000011
2019520002.tif 000012
2019520002.tif 000013