JP2020501437A - ｅＳＩＭプロファイルを設置及び管理する方法及び装置 - Google Patents

Abstract

通信システムの端末でプロファイルを安全に提供する方法及び装置を提供すること。装置及び方法は４Ｇシステム以後より高いデータ送信率をサポートするための５Ｇ通信システムをＩｏＴ技術と融合する通信技法及びそのシステムを含む。本開示は、５Ｇ通信技術及びＩｏＴ関連技術に基づいて知能型サービス(例えば、スマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、ヘルスケア、デジタル教育、小売り業、保安及び安全関連サービス等)に適用されることができる。

Description

本発明は、通信システムにおいて端末に通信サービスをダウンロード及び設置して通信接続をするための方法及び装置に関する。より具体的に、本発明は通信システムにおいてオンラインでプロファイルをダウンロードして設置して管理する方法及び装置に関する。

４Ｇ通信システムの商用化以後に増加趨勢にある無線データトラフィックに対するニーズを満たすため、改善された５Ｇ通信システム又はプレ−５Ｇ通信システムを開発するための努力が成りつつある。このような理由で、５Ｇ通信システム又はｐｒｅ−５Ｇ通信システムは４Ｇネットワーク以後(Ｂｅｙｏｎｄ ４Ｇ Ｎｅｔｗｏｒｋ)通信システム又はＬＴＥシステム以後(Ｐｏｓｔ ＬＴＥ)のシステムと呼ばれている。高いデータ送信率を達成するために、５Ｇ通信システムは超高周波(ｍｍＷａｖｅ)帯域(例えば、６０ギガ(６０ＧＨｚ)帯域のような)での具現が考慮されている。超高周波帯域での電波の経路損失の緩和及び電波の伝達距離を増加させるために、５Ｇ通信システムではビームフォーミング(ｂｅａｍｆｏｒｍｉｎｇ)、巨大配列多重入出力(ｍａｓｓｉｖｅ ＭＩＭＯ)、全次元多重入出力(Ｆｕｌｌ Ｄｉｍｅｎｓｉｏｎａｌ ＭＩＭＯ：ＦＤ−ＭＩＭＯ)、アレイアンテナ(ａｒｒａｙ ａｎｔｅｎｎａ)、アナログビームフォーミング(ａｎａｌｏｇ ｂｅａｍ−ｆｏｒｍｉｎｇ)、及び大規模アンテナ(ｌａｒｇｅ ｓｃａｌｅ ａｎｔｅｎｎａ)技術が論議されている。また、システムのネットワーク改善のために、５Ｇ通信システムでは進化された小型セル、改善した小型セル(ａｄｖａｎｃｅｄ ｓｍａｌｌ ｃｅｌｌ)、クラウド無線アクセスネットワーク(ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ：ｃｌｏｕｄ ＲＡＮ)、超高密度ネットワーク(ｕｌｔｒａ−ｄｅｎｓｅ ｎｅｔｗｏｒｋ)、機器間の通信(Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ：Ｄ２Ｄ)、無線バックホール(ｗｉｒｅｌｅｓｓ ｂａｃｋｈａｕｌ)、移動ネットワーク(ｍｏｖｉｎｇ ｎｅｔｗｏｒｋ)、協力通信(ｃｏｏｐｅｒａｔｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ)、ＣｏＭＰ(Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ−Ｐｏｉｎｔｓ)、及び受信干渉除去(ｉｎｔｅｒｆｅｒｅｎｃｅ ｃａｎｃｅｌｌａｔｉｏｎ)などの技術開発が成りつつある。この以外にも、５Ｇシステムでは進歩されたコーディング変調(Ａｄｖａｎｃｅｄ Ｃｏｄｉｎｇ Ｍｏｄｕｌａｔｉｏｎ：ＡＣＭ)方式であるＦＱＡＭ(ＨｙｂｒｉｄＦＳＫａｎｄＱＡＭＭｏｄｕｌａｔｉｏｎ)及びＳＷＳＣ(Ｓｌｉｄｉｎｇ Ｗｉｎｄｏｗ Ｓｕｐｅｒ ｐｏｓｉｔｉｏｎ Ｃｏｄｉｎｇ)と、進歩された接続技術であるＦＢＭＣ(ＦｉｌｔｅｒＢａｎｋ Ｍｕｌｔｉ Ｃａｒｒｉｅｒ)、ＮＯＭＡ(ｎｏｎ ｏｒｔｈｏｇｏｎａｌ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ)、及びＳＣＭＡ(ｓｐａｒｓｅ ｃｏｄｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ)などが開発されている。

一方、インターネットは人間が情報を生成して消費する人間中心の接続網から、事物など分散した構成要素の間に情報を取り交わして処理するＩｏＴ(Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ、事物インターネット)網に進化しつつある。クラウドサーバーなどとの接続を通じるビックデータ(Ｂｉｇｄａｔａ)処理技術などがＩｏＴ技術に結合されたＩｏＥ(Ｉｎｔｅｒｎｅｔ ｏｆ Ｅｖｅｒｙｔｈｉｎｇ)技術も台頭している。ＩｏＴを具現するため、センシング技術、有無線通信及びネットワークインフラ、サービスインターフェース技術、及び保安技術のような技術要素が要求され、最近には事物間の接続のためのセンサーネットワーク(ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ)、マシンツーマシン(Ｍａｃｈｉｎｅｏ Ｍａｃｈｉｎｅ、Ｍ２Ｍ)、ＭＴＣ(Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)などの技術が研究されている。ＩｏＴ環境では接続された事物で生成されたデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ(Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ)サービスが提供されることができる。ＩｏＴは既存のＩＴ(ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ)技術と多様な産業間の融合及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用されることができる。

これに、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが成っている。例えば、センサーネットワーク(ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ)、Ｍ２Ｍ、ＭＴＣなどの技術が５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されていることである。前述したビックデータ処理技術としてクラウド無線アクセスネットワーク(ｃｌｏｕｄ ＲＡＮ)が適用されることも５Ｇ技術とＩｏＴ技術融合の一例と言えるだろう。

ＵＩＣＣ(Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ)は、移動通信端末機などに挿入して用いるスマートカード(ｓｍａｒｔ ｃａｒｄ)でＵＩＣＣカードとも呼ぶ。前記ＵＩＣＣに移動通信事業者の網に接続するための接続制御モジュールが含まれることができる。このような接続制御モジュールの例としてＵＳＩＭ(Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ)、ＳＩＭ(Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ)、ＩＳＩＭ(ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ)などがある。ＵＳＩＭが含まれたＵＩＣＣを通常、ＵＳＩＭカードと呼んだりする。同様にＳＩＭモジュールが含まれたＵＩＣＣを通常的にＳＩＭカードと呼んだりする。本発明の以後説明でＳＩＭカードとはＵＩＣＣカード、ＵＳＩＭカード、ＩＳＩＭが含まれたＵＩＣＣなどを含む通常の意味として用いる。すなわち、ＳＩＭカードと言ってもその技術的適用がＵＳＩＭカード又はＩＳＩＭカード若しくは一般的なＵＩＣＣカードにも同様に適用されることができる。

前記ＳＩＭカードは移動通信加入者の個人情報を記憶し、移動通信ネットワークに接続時の加入者認証及びトラフィック(ｔｒａｆｆｉｃ)保安キー(ｋｅｙ)生成を行って安全な移動通信を用いることができるようにする。

前記ＳＩＭカードは、本発明を提案するとき点で一般的にカード製造時の特定移動通信事業者の要請によって当該事業者のための専用カードで製造され、当該事業者のネットワーク接続のための認証情報、例えば、ＵＳＩＭアプリケーション及びＩＭＳＩ(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ)、Ｋ値、ＯＰｃ値などが事前にカードに搭載されて出庫する。したがって、製造された前記ＳＩＭカードは当該移動通信事業者が納品を受けて加入者に提供し、以後必要時にはＯＴＡ(Ｏｖｅｒ Ｔｈｅ Ａｉｒ)などの技術を活用して前記ＵＩＣＣ内のアプリケーションの設置、修正、削除などの管理も行うことができる。加入者は所有した移動通信端末機に前記ＵＩＣＣカードを挿入して当該移動通信事業者のネットワーク及び応用サービスの利用が可能であり、端末機の交替時に前記ＵＩＣＣカードを既存の端末機から新しい端末機に移動挿入することによって前記ＵＩＣＣカードに記憶された認証情報、移動通信電話番号、個人電話帳などを新しい端末機でそのまま使用が可能である。

しかし、前記ＳＩＭカードは、移動通信端末機のユーザが他の移動通信社のサービスを提供受けるのにあって不便な点がある。移動通信端末機のユーザは移動通信事業者からサービスを受けるためにＳＩＭカードを物理的に獲得しなければならない不便がある。例えば、他の国に旅行をした時に現地移動通信サービスを受けるためには現地のＳＩＭカードを求めなければならない不便がある。ローミングサービスの場合、前記不便が多少解決されるが、高い料金及び通信社間の契約がなされていない場合、サービスを受けることができない問題もある。

一方、ＵＩＣＣカードに前記ＳＩＭモジュールを遠隔でダウンロードして設置する場合、このような不便を相当部分解決することができる。すなわち、ユーザが望む時点に使用しようとする移動通信サービスのＳＩＭモジュールをＵＩＣＣカードにダウンロードすることができる。このようなＵＩＣＣカードはさらに複数個のＳＩＭモジュールをダウンロードして設置し、その中の一つのＳＩＭモジュールのみを選択して用いることができる。このようなＵＩＣＣカードは端末に固定したり固定しないこともある。特に、端末に固定して用いるＵＩＣＣをｅＵＩＣＣ(ｅｍｂｅｄｄｅｄＵＩＣＣ)というが、通常的にｅＵＩＣＣは端末に固定して用い、遠隔でＳＩＭモジュールをダウンロードして選択することができるＵＩＣＣカードを意味する。本発明においては遠隔でＳＩＭモジュールをダウンロードして選択することができるＵＩＣＣカードをｅＵＩＣＣで通称する。すなわち、遠隔でＳＩＭモジュールをダウンロードして選択することができるＵＩＣＣカードの中で端末に固定したり固定しないＵＩＣＣカードを通称してｅＵＩＣＣで用いる。さらに、ダウンロードするＳＩＭモジュール情報を通称してｅＵＩＣＣプロファイルという用語で用いる。

前記情報は本発明の理解を助けるための背景情報としてだけ提供される。上述した事項のうちのどんなものでも本開示に係る先行技術として適用されることができるか否かに対してはどんな決定も下ろされなく、主張されない。

本開示の一態様(ａｓｐｅｃｔ)は、少なくとも上述した問題点及び／又は短所を解消して少なくとも後述する利点を提供することである。これにより、本発明が達成しようとする技術的課題は、通信システムにおいて端末が通信サービスを選択して通信接続をするための方法及び装置を提供することである。

本開示のまた他の態様(ａｓｐｅｃｔ)は、通信システムにおいて端末が通信接続をするためのプロファイルをオンラインでダウンロードして設置して管理する方法及び装置を提供することである。

本開示のまた他の態様(ａｓｐｅｃｔ)は、通信システムにおいて端末にプロファイルを安全に提供する装置及び方法を提供することである。

特に、本発明では前記目的のために以下の部分の解決方法を提案する。

−端末がプロファイル管理サーバー(ＳＭ−ＤＰ＋、ｓｕｂｓｃｒｉｐｔｉｏｎ ｍａｎｇｅｒ ｄａｔａ ｐｒｅｐａｒａｔｉｏｎ ｐｌｕｓ)でプロファイルダウンロード又はプロファイル遠隔管理を要請するメッセージを伝達する方法

−プロファイル管理サーバー(ＳＭ−ＤＰ＋)が端末でプロファイルダウンロード又はプロファイル遠隔管理を選択的に返信し、端末が次の段階に伝達しなければならないプロファイルダウンロード又はプロファイル遠隔管理要請メッセージを生成するときに用いる参照情報を返信する方法

− 前記端末及びプロファイル管理サーバー(ＳＭ−ＤＰ＋)間のメッセージ交換手続き

本発明の実施形態によれば、無線通信システムの端末が提供される。端末は、ユーザから端末が実行しようとするイベント(プロファイルダウンロード又はプロファイル遠隔管理)の種類を表記(ｄｉｓｐｌａｙ)して入力(ｉｎｐｕｔ)される入力部(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ)を含み、プロファイル管理サーバー(ＳＭ−ＤＰ＋)で端末内のｅＵＩＣＣ(ｅｍｂｅｄｄｅｄ ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)の識別子(ＥＩＤ)と、端末が実行しようとするイベントの種類を示す識別子(ＥｖｅｎｔＲｅｑｕｅｓｔＴｙｐｅ)と、端末がプロファイル遠隔管理を許容するかを示す識別子(ＲＰＭＣｏｎｆｉｇ)と、端末がプロファイル遠隔管理を行う対象となるプロファイルの識別子(ＩＣＣＩＤ、ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ ＩＤ)と、端末に現在の通信サービスを提供している事業者の識別子(ＯｐｅｒａｔｏｒＩＤ)のうちの一つ以上を送信することができる送信部を含み、その応答でプロファイル管理サーバー(ＳＭ−ＤＰ＋)から端末が実行しなければならない一つ以上のイベントと、端末が次に実行しなければならない一つ以上のイベントの種類及び個数中の一つ以上を受信することができる受信部を含み、端末が行う一つ以上のイベントに対する情報をユーザに表記(ｄｉｓｐｌａｙ)して当該イベントの実行に対するユーザの同意が入力される入力部(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ部)を含み、入力された同意に基づいて予め受信した一つ以上のイベントの実行を進行するか、又は止めるかを決定する制御部を含み、イベントの実行を進行することに決定された場合(すなわち、ユーザ同意がある場合)イベントを行う制御部を含み、イベントの実行結果をプロファイル管理サーバー(ＳＭ−ＤＰ＋)に送信することができる制御部及び送信部を含み、端末が次に実行しなければならない一つ以上のイベントの種類及び個数によってプロファイル管理サーバー(ＳＭ−ＤＰ＋)に次のイベントを要請するメッセージを送信することができる制御部及び送信部を含むことを特徴とする。

本発明の実施形態によれば、無線通信システムのプロファイル管理サーバー(ＳＭ−ＤＰ＋)が提供される。プロファイル管理サーバーは、端末のｅＵＩＣＣが実行しなければならないイベント(プロファイルダウンロード又はプロファイル遠隔管理)を記憶するイベント記憶装置(Ｅｖｅｎｔ Ｓｔｏｒａｇｅ)を含み、イベント記憶装置に記憶されたイベントの優先順位を制御して判断することができる制御部及び判断部を含み、端末から端末内のｅＵＩＣＣの識別子(ＥＩＤ)と、端末が実行しようとするイベントの種類を示す識別子(ＥｖｅｎｔＲｅｑｕｅｓｔＴｙｐｅ)と、端末がプロファイル遠隔管理を許容するかを示す識別子(ＲＰＭＣｏｎｆｉｇ)と、端末がプロファイル遠隔管理を行う対象となるプロファイルの識別子(ＩＣＣＩＤ)と、端末に現在の通信サービスを提供している事業者の識別子(ＯｐｅｒａｔｏｒＩＤ)のうちの一つ以上を受信することができる受信部を含み、シグネチャーを含むｅＵＩＣＣ認証情報を受信することができる受信部を含み、受信した端末のメッセージとプロファイル管理サーバー(ＳＭ−ＤＰ＋)のイベント記憶装置に記憶されたイベントの優先順位を比べて端末が実行しなければならない一つ以上のイベントを選択する判断部を含み、イベント記憶装置に記憶されたイベントの中で端末が次に実行しなければならない一つ以上のイベントの種類及び個数を把握する判断部を含み、端末で端末が実行しなければならない一つ以上のイベントと、端末が次に実行しなければならない一つ以上の種類及び個数中の一つ以上を送信することができる送信部を含み、端末からイベントの実行結果を受信することができる受信部を含み、端末から次のイベントを要請するメッセージを受信することができる受信部を含むことを特徴とする。

本開示のまた他の実施形態によれば、無線通信システムにおいて端末の方法が提供される。方法は、端末のイベントを要請してイベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)関連メッセージをサーバーに送信する段階と、サーバーからｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを受信する段階と、受信されたデータに基づいて動作を行う段階と、を含む。

本開示のまた他の実施形態によれば、無線通信システムの端末が提供される。端末は送受信部と、及び送受信部と結合されて端末のイベントを要請してイベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)関連メッセージをサーバーに送信し、サーバーからｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを受信し、受信されたデータに基づいて動作を行うように設定された制御部と、を含む。

本開示のまた他の実施形態によれば、無線通信システムのサーバーの方法が提供される。方法は、端末からイベントを要請してイベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ関連メッセージを受信する段階と、ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを端末で送信する段階と、を含む。

本開示のまた他の実施形態によれば、無線通信システムのサーバーが提供される。サーバーは送受信部と、及び送受信部と結合されて端末からイベントを要請してイベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ関連メッセージを受信し、ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを端末で送信するように設定された制御部と、を含む。

本発明において達成しようとする技術的課題は、以上で言及した技術的課題で制限されず、言及しない他の技術的課題は以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解されることができるだろう。

本発明の実施形態によれば、通信システムにおいて、端末がプロファイル管理サーバー(ＳＭ−ＤＰ＋)に現在ユーザの入力を通知し、端末がプロファイル管理サーバー(ＳＭ−ＤＰ＋)からプロファイルダウンロード又はプロファイル遠隔管理の中で現在実行しなければならないイベントを選択的に受信し、次に実行しなければならないイベントに対する案内を受けることができる。これを介して端末は一つ以上のイベント(プロファイルダウンロード又はプロファイル遠隔管理)がプロファイル管理サーバー(ＳＭ−ＤＰ＋)に待機中の場合、自動的に次のイベントを要請して受信した後に行うことができる。

本開示の他の態様、利点、及び顕著な特徴は以下の詳細な説明から当業者に明白であろう。さらに詳細な説明は添付された図面と共に本開示の多様な実施形態を開示する。

本開示の特定実施形態で上述した及び他の態様、特徴及び利点は添付された図面と関連して取られた後の説明からより明らかになるだろう。

本開示の一実施形態による端末が固定されたプロファイルが搭載されたＵＩＣＣを用いて移動通信ネットワークに接続する方法を示す図面である。 本開示の一実施形態によるプロファイルサーバーを介して一つ以上のプロファイルを設置する場合、端末とプロファイルサーバーのメッセージ交換手続きを示す図面である。 本開示の一実施形態によるプロファイルサーバーを介して一つ以上のプロファイルを設置し、一つ以上のプロファイル遠隔管理を行う場合、端末とプロファイルサーバーのメッセージ交換手続きを示す図面である。 本発明の一実施形態によって端末がプロファイルサーバーにイベントを要請するときにユーザが入力したコマンドに該当するイベント種類を明示する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーがイベント記憶装置を管理する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが一つ以上のイベントをバンドル送信することができるかを設定する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが一つ以上のイベントをバンドル送信することができるかを設定する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが一つ以上のイベントをバンドル送信することができるかを設定する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが一つ以上のイベントをバンドル送信することができるかを設定する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーがイベント応答メッセージを構成するときの現在実行するイベントを伝達する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーがイベント応答メッセージを構成するときの現在実行するイベントを伝達する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーがイベント応答メッセージを構成するときの現在実行するイベントを伝達する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーがイベント応答メッセージを構成するときの次に実行するイベントを伝達する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーがイベント応答メッセージを構成する手続きを示す図面である。 本発明の一実施形態によって端末とプロファイルサーバーが一つ以上のイベントを順次に受信して行うメッセージ手続きを示す図面である。 本発明の一実施形態によって端末とプロファイルサーバーが一つ以上のイベントを順次に受信して行うメッセージ手続きを示す図面である。 本発明の一実施形態によって端末とプロファイルサーバーが一つ以上のイベントを順次に受信して行うメッセージ手続きを示す図面である。 本発明の一実施形態によって端末がサーバーに‘プロファイルダウンロード’を要請してこれに対する応答を受信する手続きを示す図面である。 本発明の一実施形態によって端末がサーバーに‘プロファイル遠隔管理’を要請してこれに対する応答を受信する手続きを示す図面である。 本発明の一実施形態によって端末がサーバーにすべての種類のイベントを要請してこれに対する応答を受信する手続きを示す図面である。 本発明の一実施形態によって端末がすべてのイベントに対するデータを優先確保した後の順次にイベントを処理する方法を示す図面である。 本発明の一実施形態によって端末がイベントの受信手順によって各イベントに対するデータを確保して処理する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが各プロファイル遠隔管理及びプロファイル要約情報データに別途のシグネチャーを生成して添付する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが各プロファイル遠隔管理及びプロファイル要約情報データに別途のシグネチャーを生成して添付しながら、各データの処理手順を明示する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが各プロファイル遠隔管理及びプロファイル要約情報データの中で一部に共通シグネチャーを生成して添付する方法を示す図面である。 本発明の一実施形態によってプロファイルサーバーが各プロファイル遠隔管理及びプロファイル要約情報データの中で一部に共通シグネチャーを生成して添付しながら、各データの処理手順を明示する方法を示す図面である。 本発明の一実施形態によってシグネチャー生成及びデータ配置方法を示す図面である。 本発明の一実施形態によってシグネチャー生成及びデータ配置方法を示す図面である。 本発明の一実施形態によって端末にユーザインターフェース(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＵＩ)を構成する方法を示す図面である。 本発明の一実施形態によって端末にユーザインターフェース(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＵＩ)を構成する方法を示す図面である。 本発明の一実施形態によって端末にユーザインターフェース(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＵＩ)を構成する方法を示す図面である。 本発明の一実施形態によって端末にユーザインターフェース(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＵＩ)を構成する方法を示す図面である。 本開示の一実施形態による端末の動作を時系列な流れによって示す図面である。 本発明の一実施形態による端末の構成要素を示すブロック図である。 本発明の一実施形態によるサーバーの構成要素を示すブロック図である。図面を介して、同一な参照番号は同一又は類似の要素、特徴及び構造を示すために用いられるという点に留意すべきである。

図面を介して、同一な参照番号は同一又は類似の要素、特徴及び構造を示すために用いられるという点に留意すべきである。

添付された図面を参照した次の説明は請求範囲及びその均等なものにより定義された本開示の多様な実施形態に対する包括的な理解を助けるために提供される。これはその理解を助けるための多様な細部事項を含むが、これらはただ例示的なものとして見なされなければならない。したがって、本技術分野の当業者は本願に記載された多様な実施形態の多様な変更及び修正が本開示の範囲及び思想を逸脱せず成ることができることを認識するだろう。また、公知された機能及び構成に対する説明は明確性及び簡潔性のために省略されることができる。

次の詳細な説明及び請求範囲で用いられる用語及び単語は書誌的意味に限定されず、発明者がただ本開示に対する明確で一貫された理解ができるようにするために用いられたものである。したがって、本開示の多様な実施形態に対する次の説明は説明の目的だけで提供され、添付された請求範囲及びその等価物によって定義される本開示を制限する目的ではないということが当業者に明白であろう。

単数形態“ａ”、“ａｎ”及び“ｔｈｅ”は文脈上明確に異なるように指示しない限り、複数対象を含むということを理解すべきである。したがって、例えば、“構成要素表面”に対する言及はそういう一つ以上の表面に対する言及を含む。

多様な実施形態を説明するにあたって、本発明が属する技術分野の良く知られており、本発明と直接関連がない技術内容については説明を省略する。これは、不必要な説明を省略することによって、本発明の要旨を明瞭にして、より明確に伝達するためである。

同じ理由で添付図面において一部構成要素は誇張されたり省略されたり概略的に図示された。また、各構成要素のサイズは実際サイズを全的に反映するのではない。各図面で同一又は対応する構成要素には同一参照番号を付した。

本発明の利点及び特徴、そして、それらを達成する方法は添付される図面と共に詳細に後述されている実施形態を参照すれば明確となるだろう。しかし、本発明は以下で開示される実施形態に限定されるのではなく互いに異なる多様な形態で具現されることができ、ただ本実施形態は本発明の開示が完全にさせて、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであり、本発明は請求項の範疇により定義されるだけである。明細書全体にかけて同一参照符号は同一構成要素を指称する。

このとき、処理フローチャートの各ブロックとフローチャートの図面の組合は、コンピュータープログラムインストラクションによって行われることができることを理解することができるだろう。これらコンピュータープログラムインストラクションは、汎用コンピューター、特殊用コンピューター又はその他のプログラム可能なデータプロセッシング装備のプロセッサに搭載されることができるので、コンピューター又はその他のプログラム可能なデータプロセッシング装備のプロセッサを介して行われるそのインストラクションが、フローチャートブロックで説明された機能を行う手段を生成するようになる。これらコンピュータープログラムインストラクションは、特定方式で機能を具現するためにコンピューター又はその他のプログラム可能なデータプロセッシング装備を志向することができるコンピューター利用可能、又はコンピューター判読可能メモリーに記憶されることも可能であるので、そのコンピューター利用可能又はコンピューター判読可能メモリーに記憶されたインストラクションは、フローチャートブロックで説明された機能を行うインストラクション手段を内包する製造品目を生産することも可能である。コンピュータープログラムインストラクションは、コンピューター又はその他のプログラム可能なデータプロセッシング装備上に搭載されることも可能であるので、コンピューター又はその他のプログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピューターで実行されるプロセスを生成してコンピューター又はその他のプログラム可能なデータプロセッシング装備を行うインストラクションはフローチャートブロックで説明された機能を行うための段階を提供することも可能である。

また、各ブロックは、特定された論理的機能を行うための１つ以上の実行可能なインストラクションを含むモジュール、セグメント又はコードの一部を示すことができる。また、幾つか代替実行例ではブロックで言及された機能が段階を外れて発生することも可能であることを注目しなければならない。例えば、接して示されている２つのブロックは、実は実質的に同時に行われることも可能で、又はそのブロックが時々当該する機能によって逆順に行われることも可能である。

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

以下の説明で使用する特定用語は本発明の理解を助けるために提供されたもので、このような特定用語の使用は本発明の技術的思想を逸脱せず範囲で他の形態で変更されることができる。

先ず、本明細書で使用する用語に対して定義する。

本明細書においてＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)は、移動通信端末機に挿入して用いるスマートカードとして移動通信加入者のネットワーク接続認証情報、電話帳、ＳＭＳ(ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ)のような個人情報が記憶されてＧＳＭ（登録商標）(ｇｌｏｂａｌ ｓａｔｅｌｌｉｔｅ ｍｏｖｅｍｅｎｔ)、ＷＣＤＭＡ（登録商標）(ｗｉｄｅｂａｎｄ ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ)、ＬＴＥ(ｌｏｎｇ−ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ)などのような移動通信ネットワークに接続時の加入者認証及びトラフィック保安キー生成を行って安全な移動通信利用ができるようにするチップを意味する。ＵＩＣＣには加入者が接続する移動通信ネットワークの種類によってＳＩＭ(Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅ)、ＵＳＩＭ(Ｕｎｉｖｅｒｓａｌ ＳＩＭ)、ＩＳＩＭ(ＩＰ(ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ)Ｍｕｌｔｉｍｅｄｉａ ＳＩＭ)などの通信アプリケーションが搭載され、さらに、電子財布、ティケッティング、電子パスポートなどのような多様な応用アプリケーションの搭載のための上位レベルの保安機能を提供することができる。

本明細書においてｅＵＩＣＣ(ｅｍｂｅｄｄｅｄＵＩＣＣ)は、端末に挿入及び脱去が可能な着脱式ではない端末に内装したチップ形態の保安モジュールである。ｅＵＩＣＣはＯＴＡ(Ｏｖｅｒ Ｔｈｅ Ａｉｒ)技術を用いてプロファイルをダウンして設置することができる。ｅＵＩＣＣはプロファイルダウンロード及び設置が可能なＵＩＣＣで命名することができる。

本明細書においてｅＵＩＣＣにＯＴＡ技術を用いてプロファイルをダウンして設置する方法は、端末に挿入及び脱去が可能な着脱式ＵＩＣＣにも適用されることができる。すなわち、本発明の実施形態にはＯＴＡ技術を用いてプロファイルをダウンして設置可能なＵＩＣＣに適用されることができる。

本明細書において用語ＵＩＣＣはＳＩＭと混用されることができ、用語ｅＵＩＣＣはｅＳＩＭと混用されることができる。

本明細書においてプロファイル(Ｐｒｏｆｉｌｅ)は、ＵＩＣＣ内に記憶されるアプリケーション、ファイルシステム、認証キー値などをソフトウェア形態でパッケージングしたことを意味することができる。

本明細書においてＵＳＩＭ Ｐｒｏｆｉｌｅはプロファイルと同一の意味又はプロファイル内のＵＳＩＭアプリケーションに含まれた情報をソフトウェア形態でパッケージングしたことを意味することができる。

本明細書においてプロファイル提供サーバーは、プロファイルを生成したり、生成されたプロファイルを暗号化したり、プロファイル遠隔管理コマンドを生成したり、生成されたプロファイル遠隔管理コマンドを暗号化する機能を含み、ＳＭ−ＤＰ(Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｄａｔａ Ｐｒｅｐａｒａｔｉｏｎ)、ＳＭ−ＤＰ＋(Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｄａｔａ Ｐｒｅｐａｒａｔｉｏｎ ｐｌｕｓ)、ｏｆｆ−ｃａｒｄ ｅｎｔｉｔｙ ｏｆ Ｐｒｏｆｉｌｅ Ｄｏｍａｉｎ、プロファイル暗号化サーバー、プロファイル生成サーバー、プロファイル提供者(Ｐｒｏｆｉｌｅ Ｐｒｏｖｉｓｉｏｎｅｒ、ＰＰ)、プロファイル供給者(Ｐｒｏｆｉｌｅ Ｐｒｏｖｉｄｅｒ)、ＰＰＣ ｈｏｌｄｅｒ(Ｐｒｏｆｉｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｃｒｅｄｅｎｔｉａｌｓ ｈｏｌｄｅｒ)で表現されることができる。

本明細書においてプロファイル管理サーバーは、ＳＭ−ＳＲ(Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｓｅｃｕｒｅ Ｒｏｕｔｉｎｇ)、ＳＭ−ＳＲ＋(Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｓｅｃｕｒｅ Ｒｏｕｔｉｎｇ Ｐｌｕｓ)、ｏｆｆ−ｃａｒｄ ｅｎｔｉｔｙ ｏｆ ｅＵＩＣＣＰｒｏｆｉｌｅ Ｍａｎａｇｅｒ又はＰＭＣ ｈｏｌｄｅｒ(Ｐｒｏｆｉｌｅ Ｍａｎａｇｅｍｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ ｈｏｌｄｅｒ)、ＥＭ(ｅＵＩＣＣ Ｍａｎａｇｅｒ)で表現されることができる。

本明細書において前記プロファイル提供サーバーを指称するとき、前記プロファイル管理サーバーの機能を合したことを通称すれば良い。したがって、本発明の多様な実施形態で、すなわち、以後の技術でプロファイル提供サーバーの動作に対して前記動作はプロファイル管理サーバーからなることも可能であることは勿論である。同様にプロファイル管理サーバー又はＳＭ−ＳＲに対して記述する動作はプロファイル提供サーバーで行われることもできることは勿論である。

本明細書において用いる用語‘端末’は、移動局(ＭＳ)、ユーザ装備(ＵＥ；Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)、ユーザターミナル(ＵＴ；Ｕｓｅｒ Ｔｅｒｍｉｎａｌ)、無線ターミナル、アクセスターミナル(ＡＴ)、ターミナル、加入者ユニット(Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ)、加入者ステーション(ＳＳ；Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ)、無線機器(ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ)、無線通信デバイス、無線送受信ユニット(ＷＴＲＵ；Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ)、移動ノード、モバイル又は他の用語として指称されることができる。端末の多様な実施形態は、セルラー電話機、無線通信機能を有するスマートフォン、無線通信機能を有する個人携帯用端末機(ＰＤＡ)、無線モデム、無線通信機能を有する携帯用コンピューター、無線通信機能を有するデジタルカメラのような撮影装置、無線通信機能を有するゲーミング装置、無線通信機能を有する音楽記憶及び再生家電製品、無線インターネット接続及びブラウジングが可能なインターネット家電製品だけではなくそれらの機能の組み合せを統合している携帯型ユニット又は端末機を含むことができる。さらに、端末は、Ｍ２Ｍ(Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ)端末、ＭＴＣ(Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)端末／デバイスを含むことができるが、ここに限定されるのではない。本明細書において前記端末は電子装置と指称することもできる。

本明細書において電子装置は、プロファイルをダウンロードして設置可能なＵＩＣＣが内装されることができる。ＵＩＣＣが電子装置に内装されない場合、物理的に電子装置と分離したＵＩＣＣは電子装置に挿入されて電子装置と接続されることができる。例えば、カード形態でＵＩＣＣは電子装置に挿入されることができる。前記電子装置は前記端末を含むことができ、この時、端末はプロファイルをダウンロードして設置可能なＵＩＣＣを含む端末であれば良い。前記端末にＵＩＣＣは内装されることだけではなく、端末とＵＩＣＣが分離された場合、ＵＩＣＣは端末に挿入されることができ、端末に挿入されて端末と接続されることができる。プロファイルをダウンロードして設置可能なＵＩＣＣは例えば、ｅＵＩＣＣと指称することができる。

本明細書において前記端末又は電子装置は、ＵＩＣＣ又はｅＵＩＣＣを制御するように端末又は電子装置内に設置されたソフトウェア又はアプリケーションを含むことができる。前記ソフトウェア又はアプリケーションは、例えば、Ｌｏｃａｌ Ｐｒｏｆｉｌｅ Ａｓｓｉｓｔａｎｔ(ＬＰＡ)と指称することができる。

本明細書においてプロファイルディスクリミネーターは、プロファイル識別子(Ｐｒｏｆｉｌｅ ＩＤ)、ＩＣＣＩＤ(Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ ＩＤ)、Ｍａｔｃｈｉｎｇ ＩＤ、イベント識別子(Ｅｖｅｎｔ ＩＤ)、活性化コード(Ａｃｔｉｖａｔｉｏｎ Ｃｏｄｅ)、活性化コードトークン(Ａｃｔｉｖａｔｉｏｎ Ｃｏｄｅ Ｔｏｋｅｎ)、ＩＳＤ−Ｐ又はプロファイルドメイン(Ｐｒｏｆｉｌｅ Ｄｏｍａｉｎ、ＰＤ)とマッチングされる因子で指称されることができる。Ｐｒｏｆｉｌｅ ＩＤは各プロファイルの固有識別子を示すことができる。前記プロファイルディスクリミネーターはプロファイルをインデックスすることができるプロファイル提供サーバー(ＳＭ−ＤＰ＋)の住所を含むことができる。

本明細書においてｅＵＩＣＣ識別子(ｅＵＩＣＣ ＩＤ)は、端末に内装されたｅＵＩＣＣの固有識別子であってもよく、ＥＩＤ(ｅＵＩＣＣ ｉｄｅｎｔｉｆｉｅｒ)で指称されることができる。また、ｅＵＩＣＣにプロビジョニングプロファイル(Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｆｉｌｅ)が予め搭載されている場合、当該プロビジョニングプロファイルの識別子(Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｆｉｌｅの Ｐｒｏｆｉｌｅ ＩＤ)であれば良い。さらに、本発明の実施形態のように端末とｅＵＩＣＣチップが分離しない場合には端末ＩＤであれば良い。また、ｅＵＩＣＣチップの特定保安ドメイン(Ｓｅｃｕｒｅ Ｄｏｍａｉｎ)を指称することもできる。

本明細書においてプロファイルコンテナ(Ｐｒｏｆｉｌｅ Ｃｏｎｔａｉｎｅｒ)は、プロファイルドメイン(Ｐｒｏｆｉｌｅ Ｄｏｍａｉｎ)で命名されることができる。プロファイルコンテナ(Ｐｒｏｆｉｌｅ Ｃｏｎｔａｉｎｅｒ)は保安ドメイン(Ｓｅｃｕｒｉｔｙ Ｄｏｍａｉｎ)であれば良い。

本明細書においてＡＰＤＵ(ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ)は、端末がｅＵＩＣＣと連動するためのメッセージであれば良い。また、ＡＰＤＵはＰＰ又はＰＭがｅＵＩＣＣと連動するためのメッセージであれば良い。

本明細書においてＰＰＣはプロファイル提供サーバーとｅＵＩＣＣの間の相互認証及びプロファイル暗号化、シグネチャーをするのに用いられる手段であれば良い。ＰＰＣは対称キー、ＲＳＡ(Ｒｉｖｅｓｔ Ｓｈａｍｉｒ Ａｄｌｅｍａｎ)認証書と個人キー、ＥＣＣ(ｅｌｌｉｐｔｉｃ ｃｕｒｖｅｄ ｃｒｙｐｔｏｇｒａｐｈｙ)認証書と個人キー、最上位認証機関(Ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｉｏｎ ａｕｔｈｏｒｉｔｙ(ＣＡ))及び認証書チェーン(ｃｈａｉｎ)のうちの一つ以上を含むことができる。さらに、プロファイル提供サーバーが複数個の場合には複数個のプロファイル提供サーバー別で他のＰＰＣをｅＵＩＣＣに記憶したり用いることができる。

本明細書においてＰＭＣはプロファイル管理サーバーとｅＵＩＣＣの間の相互認証及び送信データ暗号化、シグネチャーをするのに用いられる手段であれば良い。ＰＭＣは対称キー、ＲＳＡ認証書と個人キー、ＥＣＣ認証書と個人キー、Ｒｏｏｔ ＣＡ及び認証書チェーンのうちの一つ以上を含むことができる。さらに、プロファイル管理サーバーが複数個の場合には複数個のプロファイル管理サーバー別で他の ＰＭＣをｅＵＩＣＣに記憶したり用いることができる。

本明細書においてＡＩＤはアプリケーション識別子(Ａｐｐｌｉｃａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ)であれば良い。この値はｅＵＩＣＣ内で互いに異なるアプリケーション(Ａｐｐｌｉｃａｔｉｏｎ)を区分するディスクリミネーターであっても良い。

本明細書においてイベント(Ｅｖｅｎｔ)はプロファイルダウンロード(Ｐｒｏｆｉｌｅ Ｄｏｗｎｌｏａｄ)又は遠隔プロファイル管理(Ｒｅｍｏｔｅ Ｐｒｏｆｉｌｅ Ｍａｎａｇｅｍｅｎｔ)又はその他プロファイルやｅＵＩＣＣの管理／処理コマンドを通称する用語であっても良い。プロファイルダウンロード(Ｐｒｏｆｉｌｅ Ｄｏｗｎｌｏａｄ)はプロファイル設置(Ｐｒｏｆｉｌｅ Ｉｎｓｔａｌｌａｔｉｏｎ)と混用されることができる。さらに、イベント種類(Ｅｖｅｎｔ Ｔｙｐｅ)は特定イベントがプロファイルダウンロードであるか遠隔プロファイル管理であるか、又はその他のプロファイルやｅＵＩＣＣ管理／処理コマンドであることかを示す用語として用いられることができ、動作種類(Ｏｐｅｒａｔｉｏｎ Ｔｙｐｅ又はＯｐｅｒａｔｉｏｎＴｙｐｅ)、動作分類(Ｏｐｅｒａｔｉｏｎ Ｃｌａｓｓ又はＯｐｅｒａｔｉｏｎＣｌａｓｓ)、イベント要請種類(Ｅｖｅｎｔ Ｒｅｑｕｅｓｔ Ｔｙｐｅ)、イベント分類(Ｅｖｅｎｔ Ｃｌａｓｓ)、イベント要請分類(Ｅｖｅｎｔ Ｒｅｑｕｅｓｔ Ｃｌａｓｓ)などで命名されることができる。

本明細書においてプロファイルパッケージ(Ｐｒｏｆｉｌｅ Ｐａｃｋａｇｅ)は、プロファイルと混用されたり特定プロファイルのデータ客体(ｄａｔａ ｏｂｊｅｃｔ)を示す用語で用いられることができ、Ｐｒｏｆｉｌｅ ＴＬＶ又はプロファイルパッケージＴＬＶ(Ｐｒｏｆｉｌｅ Ｐａｃｋａｇｅ ＴＬＶ)で命名されることができる。プロファイルパッケージが暗号化パラメーターを用いて暗号化された場合、保護されたプロファイルパッケージ(Ｐｒｏｔｅｃｔｅｄ Ｐｒｏｆｉｌｅ Ｐａｃｋａｇｅ(ＰＰＰ))又は保護されたプロファイルパッケージＴＬＶ(ＰＰＰ ＴＬＶ)で命名されることができる。プロファイルパッケージが特定ｅＵＩＣＣによってだけ復号化可能な暗号化パラメーターを用いて暗号化された場合、バウンドプロファイルパッケージ(Ｂｏｕｎｄ Ｐｒｏｆｉｌｅ Ｐａｃｋａｇｅ(ＢＰＰ))又はバウンドプロファイルパッケージＴＬＶ(ＢＰＰ ＴＬＶ)で命名されることができる。プロファイルパッケージＴＬＶはＴＬＶ(Ｔａｇ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ)形式でプロファイルを構成する情報を表現するデータセット(ｓｅｔ)であれば良い。

本明細書において遠隔プロファイル管理(Ｒｅｍｏｔｅ Ｐｒｏｆｉｌｅ Ｍａｎａｇｅｍｅｎｔ、ＲＰＭ)は、プロファイル遠隔管理(Ｐｒｏｆｉｌｅ Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ)、遠隔管理(Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ)、遠隔管理コマンド(Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ)、遠隔コマンド(Ｒｅｍｏｔｅ Ｃｏｍｍａｎｄ)、遠隔プロファイル管理パッケージ(ＲＰＭ Ｐａｃｋａｇｅ)、プロファイル遠隔管理パッケージ(Ｐｒｏｆｉｌｅ Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋａｇｅ)、遠隔管理パッケージ(Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋａｇｅ)、遠隔管理コマンドパッケージ(Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ)、遠隔コマンドパッケージ(Ｒｅｍｏｔｅ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ)で命名されることができる。ＲＰＭは特定プロファイルの状態(Ｅｎａｂｌｅｄ、Ｄｉｓａｂｌｅｄ、Ｄｅｌｅｔｅｄ)を変更したり、特定プロファイルの内容(例えば、プロファイルの別称(Ｐｒｏｆｉｌｅ Ｎｉｃｋｎａｍｅ)、又はプロファイル要約情報(Ｐｒｏｆｉｌｅ Ｍｅｔａｄａｔａ)など)を変更(ｕｐｄａｔｅ)する用途で用いられることができる。ＲＰＭは一つ以上の遠隔管理コマンドを含むこともでき、この場合、各遠隔管理コマンドの対象となるプロファイルは遠隔管理コマンドごとに互いに同一であっても良く異なっても良い。

本明細書においてＡＫＡは認証及びキー合意(Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ ａｇｒｅｅｍｅｎｔ)を示すことができ、３ＧＰＰ(３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ)及び３ＧＰＰ２網に接続するための認証アルゴリズムを示すことができる。

本明細書においてＫはＡＫＡ認証アルゴリズムに用いられるｅＵＩＣＣに記憶される暗号キー値である。

本明細書においてＯＰｃはＡＫＡ認証アルゴリズムに用いられるｅＵＩＣＣに記憶されることができるパラメーター値である。

本明細書においてＮＡＡはネットワーク接続アプリケーション(Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ)応用プログラムで、ＵＩＣＣに記憶されて網に接続するためのＵＳＩＭ又はＩＳＩＭのような応用プログラムであれば良い。ＮＡＡは網接続モジュールであっても良い。

そして、本発明を説明するにおいて、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不明瞭にすることができると判断された場合、その詳細な説明は省略する。

図１は、本開示の一実施形態による端末に固定されたプロファイルが搭載されたＵＩＣＣを用いた端末の移動通信ネットワーク接続方法を示す図面である。

図１を参照すれば、端末１１０にＵＩＣＣ１２０が挿入されることができる。この時、前記ＵＩＣＣは着脱型であっても良く端末に予め内装されても良い。前記固定されたプロファイルが搭載されたＵＩＣＣの固定されたプロファイルは特定通信社に接続することができる ‘接続情報’が固定されていることを意味する。前記接続情報は例えば、ＩＭＳＩ(ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ)及び加入者ディスクリミネーターと共に網に認証するのに用いられるＫ又はＫｉ値であれば良い。

すると、前記端末は前記ＵＩＣＣを用いて移動通信社の認証処理システム(例えば、ＨＬＲ(ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ)やＡｕＣ)と認証を行うことができる。前記認証過程はＡＫＡ(Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ)過程であっても良い。認証に成功すれば、以後端末は前記移動通信システムの移動通信サービス提供者ネットワーク１３０を用いて電話やモバイルデータ利用などの移動通信サービスを用いることができるようになる。

以下、端末２３０及びプロファイルサーバー２５０を参照する。端末２３０は端末１１０であれば良い。端末２３０はＬＰＡ又はｅＵＩＣＣのうちの少なくとも一つを含むことができる。前記プロファイルサーバー２５０はＳＭ−ＤＰ＋を含むことができる。

図２は、本開示の一実施形態によるプロファイルサーバーを介して一つ以上のプロファイルを設置する場合、端末２３０とプロファイルサーバー２５０のメッセージ交換手続きを示す図面である。

図２を参照すれば、２０１段階で端末２３０はユーザから“プロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)”コマンドを受信し、２０３段階でプロファイルサーバー２５０とＴＬＳ接続及び相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)を行うことができる。２０５段階で端末は前記相互認証手続きの最後の手続きで端末のｅＵＩＣＣ識別子(ＥＩＤ)をプロファイルサーバー２５０に伝達することができる。２０７段階でプロファイルサーバーはＥＩＤを介して当該端末に設置されなければならないイベントのリストを確認することができる。２０９段階でプロファイルサーバーは前記イベントのリストの中で最も優先順位が高いイベント(本実施形態ではプロファイル１設置)を選択することができる。２１１段階でプロファイルサーバーは前記選択したプロファイルの要約情報を端末に返信することができる。２１３段階で端末は前記プロファイル要約情報をユーザに図示してプロファイル設置に対するユーザ同意を得ることができる。２１５段階で端末は前記ユーザ同意をプロファイルサーバーに伝達してプロファイルパッケージを受信することができる。２１７段階で端末は前記プロファイルパッケージを成功的に設置し、その結果を２１９段階でプロファイルサーバーに伝達することができる。

前記プロファイルパッケージ設置手続きによれば、プロファイルサーバーに一つ以上のイベントが待機中の場合、特定イベントの実行及び処理以後のプロファイルサーバーに待機中のイベントがさらに残っていることを端末に公知することができない。だけでなく、ユーザは一つ以上のプロファイルを設置するために端末に“プロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)”コマンドを数回入力しなければならない不都合がある。

図３は、本開示の一実施形態によるプロファイルサーバーを介して一つ以上のプロファイルを設置し、一つ以上の遠隔管理を行う場合、端末２３０とプロファイルサーバー２５０のメッセージ交換手続きを示す図面である。

図３を参照すれば、３０１段階で端末２３０はユーザから“プロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)”コマンドを受信し、３０３段階でプロファイルサーバー２５０とＴＬＳ接続及び相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)を行うことができる。３０５段階で端末は前記相互認証手続きの最後の手続きで端末のｅＵＩＣＣ識別子(ＥＩＤ)をプロファイルサーバー２５０に伝達することができる。３０７段階でプロファイルサーバーはＥＩＤを介して当該端末に設置されなければならないイベントのリスト(プロファイル又は遠隔管理)を確認することができる。３０９段階でプロファイルサーバーは前記イベントリストの中で最も優先順位が高いイベント(本実施形態では遠隔管理１)を選択することができる。３１１段階でプロファイルサーバーは前記選択した遠隔管理コマンドを端末に返信することができる。３１３段階で端末は前記受信した遠隔管理コマンドを行うことができる。３１５段階で端末は前記遠隔管理コマンドの実行結果をプロファイルサーバーに伝達することができる。

前記プロファイル設置及び遠隔管理実行手続きによれば、プロファイルサーバーに一つ以上のイベントが待機中の場合、特定イベントの実行及び処理以後のプロファイルサーバーに待機中のイベントがさらに残っていることを端末に公知することができない。だけでなく、本実施形態によれば、３０１段階でユーザが端末に“プロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)”コマンドしたにもかかわらず、端末はプロファイルサーバーから最も優先順位が高いイベントである遠隔管理コマンドを優先受信してユーザの意図と異なる動作を行うので、ユーザに混同を与える余地がある。

図４は、本発明の実施形態によって、端末２３０がプロファイルサーバー２５０にイベントを要請するとき、ユーザが入力したコマンドに該当するイベント種類(Ｅｖｅｎｔ Ｔｙｐｅ)を明示する方法を示す図面である。図４のｃａｓｅ１、ｃａｓｅ２、ｃａｓｅ３はそれぞれ独立的な実施形態を示すが、２つ以上のｃａｓｅが連続的に行われることもできる。

図４を参照すれば、４０１段階で端末はユーザから“プロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)” コマンドを受信することができる。前記ユーザ入力に対して４０３段階で端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを完了し、プロファイルダウンロードに該当するイベント種類を明示してプロファイルサーバー２５０にイベントを要請することができる。この時、イベント種類はテキスト(本実施形態の場合、“ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ”)で表記したり、それに対応する数字列(ｅｎｕｍｅｒａｔｅ)中の一つの値で表記することができる。例えば、数字列“０、１”がそれぞれ‘プロファイルダウンロード’と‘プロファイル遠隔管理’に対応する場合、“ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ”というテキストの代わりに数字‘０’を用いることができる。さらに、４０３段階で端末は現在ユーザが端末のプロファイル遠隔管理機能を活性化(ｏｎ)したかをプロファイルサーバーに公知するか、当該端末に現在通信サービスを提供している事業者の識別子(ＯｐｅｒａｔｏｒＩＤ)を公知することができる。４０５段階でプロファイルサーバーは端末の要請に応じて優先順位が高いプロファイル設置イベントを選択することができる。前記イベント種類、プロファイル管理機能活性化可否、事業者識別子情報をプロファイルサーバーが活用する方法及びイベントの優先順位管理方法は後述する実施形態で詳しく説明する。

また、図４を参照すれば、４０７段階で端末はユーザから“プロファイル更新(Ｒｅｆｒｅｓｈ Ｐｒｏｆｉｌｅ)”コマンドを受信することができる。前記ユーザ入力に対して４０９段階で端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを完了し、プロファイル遠隔管理に該当するイベント種類を明示してプロファイルサーバー２５０にイベントを要請することができる。この時、イベント種類はテキスト(本実施形態の場合、“ＲＰＭ”)で表記したり、それに対応する数字列(ｅｎｕｍｅｒａｔｅ)中の一つの値で表記することができる。例えば、数字列“０、１”がそれぞれ‘プロファイルダウンロード’と‘プロファイル遠隔管理’に対応する場合、“ＲＰＭ”というテキストの代わりに数字‘１’を用いることができる。また、４０９段階で端末は現在ユーザが端末のプロファイル遠隔管理機能を活性化(ｏｎ)したかをプロファイルサーバーに公知するか、当該端末に現在通信サービスを提供している事業者の識別子(ＯｐｅｒａｔｏｒＩＤ)を公知することができる。４１１段階でプロファイルサーバーは端末の要請に応じて優先順位が高いプロファイル遠隔管理イベントを選択することができる。前記イベント種類、プロファイル管理機能活性化可否、事業者識別子情報をプロファイルサーバーが活用する方法及びイベントの優先順位管理方法は後述する実施形態で詳細に説明する。

また、図４を参照すれば、４１３段階で端末はユーザから“すべてのイベント受信(Ｕｐｄａｔｅ Ａｌｌ)”コマンドを受信することができる。前記ユーザ入力に対して４１５段階で端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを完了し、プロファイルダウンロード及びプロファイル遠隔管理に該当するイベント種類を明示してプロファイルサーバー２５０にイベントを要請することができる。この時、イベント種類は単一テキスト(本実施形態の場合、“ＡＮＹ”)で表記したり、それに該当する数字列の中の一つ以上の値で表記したり、前記プロファイルダウンロード又はプロファイル遠隔管理の実施形態で用いられた方法を複合的に適用して表記することができる。例えば、テキスト“ＡＮＹ”の代わり“ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ、ＲＰＭ”のテキストを利用するか、数字列“０、１、２”がそれぞれ‘プロファイルダウンロード’、‘プロファイル遠隔管理’、‘すべてのイベント’に対応する場合、数字‘２’を用いるか、数字列“０、１”を用いることができる。また、４１５段階で端末は現在ユーザが端末のプロファイル遠隔管理機能を活性化(ｏｎ)したかをプロファイルサーバーに公知するか、当該端末に現在通信サービスを提供している事業者の識別子(ＯｐｅｒａｔｏｒＩＤ)を公知することができる。４１７段階でプロファイルサーバーは端末の要請に応じて優先順位が高いイベント(プロファイルダウンロード又はプロファイル遠隔管理)を選択することができる。前記イベント種類、プロファイル管理機能活性化可否、事業者識別情報をプロファイルサーバーが活用する方法及びイベントの優先順位管理方法は後述する実施形態で詳しく説明する。
図５は、本発明の実施形態によって、プロファイルサーバーがイベント記憶装置(Ｅｖｅｎｔ Ｓｔｏｒａｇｅ)を管理する方法を示す図面である。

図５を参照すれば、プロファイルサーバーはｅＵＩＣＣ識別子(ＥＩＤ)で区分されるイベント記憶装置(Ｅｖｅｎｔ Ｓｔｏｒａｇｅ)を管理することができる。各イベント記憶装置には当該ｅＵＩＣＣ(又は端末)が実行しなければならないイベント(‘プロファイルダウンロード’又は‘プロファイル遠隔管理’)が一つ以上記憶されることができる。さらに、各イベント記憶装置に記憶されたイベントはそれぞれの優先順位を持ち、優先順位を算定する方法は次の例示中の一つ又は２つ以上の複合的な方法によることができるが、以下のリストに限定されない。

−イベント記憶装置にイベントが登録された手順

−事業者がイベントを登録するときの割り当てる優先順位値

−イベントの種類(例えば、プロファイルダウンロードがプロファイル遠隔管理より優先順位が高いことがある)

−プロファイルサーバーが任意に判断して割り当てる優先順位値

さらに、一つ以上のイベントが同一な優先順位を持つ場合、プロファイルサーバーは当該イベントを任意の手順で整列することができる。本発明の実施形態ではイベント記憶装置にイベントが登録された手順によって先入先出(Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ、ＦＩＦＯ)形態でイベントの優先順位が管理される例が説明されたが、上述したように各イベントの優先順位は多様な方法で算定されることができるに留意しなければならない。

図６Ａ、６Ｂ、６Ｃ、６Ｄは、本発明の実施形態によって、プロファイルサーバーが一つ以上のイベントを端末に送信するとき、複数個のイベントを一つのメッセージのなかにバンドル送信することができるかを設定する方法を示す図面である。

図６Ａ、６Ｂ、６Ｃ及び６Ｄを参照すれば、プロファイルサーバーはイベント種類(Ｅｖｅｎｔ Ｔｙｐｅ)別で特定イベント種類を他のイベント種類とバンドル送信することができるかを設定する図表(ｔａｂｌｅ)を管理することができる。

図６Ａを参照すれば、プロファイルサーバーはイベント種類に関係なくすべてのイベントをバンドル送信するように設定することができる。

図６Ｂを参照すれば、プロファイルサーバーはプロファイル遠隔管理イベントをバンドル送信することだけ許容し、プロファイルダウンロードイベントをバンドル送信したりプロファイルダウンロードイベントとプロファイル遠隔管理イベントをバンドル送信することは許容しないように設定することができる。

図６Ｃを参照すれば、プロファイルサーバーはプロファイル遠隔管理イベントとプロファイルダウンロードイベントをバンドル送信することだけ許容し、プロファイルダウンロードイベントをバンドル送信したりプロファイル遠隔管理イベントをバンドル送信することは許容しないように設定することができる。

図６Ｄを参照すれば、プロファイルサーバーはどんなイベントもバンドル送信することを許容しないこともある。

本実施形態では２つのイベントに対する例を説明しているが、上述したように３つ以上にイベント種類が増える場合にはそれに当たるように図表の大きさが増えることができることは勿論である。さらに、イベント種類別バンドル送信可能可否の設定は図６Ａ、６Ｂ、６Ｃ及び６Ｄに図示されたイベント種類別バンドル送信設定の例は限定されず、バンドル送信しようとするイベントの組み合せによって異なるように設定されることができるに留意しなければならない。

図７Ａ、７Ｂ及び７Ｃは、本開示の一実施形態によって、端末のイベント要請メッセージに対し、端末が現在処理しなければならない‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’及びイベント記憶装置(Ｅｖｅｎｔ Ｓｔｏｒａｇｅ)に待機中の‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’を含んでプロファイルサーバーが端末に返信する応答メッセージを構成するとき、‘現在イベント’の情報を構成する方法を示す図面である。

図７Ａ、７Ｂ及び７Ｃを参照すれば、７０１ａ、７０１ｂ、及び７０１ｃ段階で端末２３０はプロファイルサーバー２５０にイベント要請メッセージを送信することができる。イベント要請メッセージの構成と詳細説明は図４の実施形態を参照する。前記端末のイベント要請メッセージに対し、７０３ａ、７０３ｂ及び７０３ｃ段階でプロファイルサーバーは、イベント記憶装置で優先順位によって選択した一つ以上の‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’と、当該イベントを除いてイベント記憶装置に残っているイベントの情報を用い、イベント応答メッセージを構成することができる。この時、現在イベントの選択は端末のイベント要請メッセージに明示されたイベント種類と、プロファイルサーバーのイベント記憶装置状態及び優先送信許容可否設定によって次のように行われることができる。

プロファイルサーバーは各イベント種類によって下位優先順位のイベントが上位優先順位イベントより先ず端末に送信されることができるかを許容する優先順位設定図表を管理することができる。

図７Ｂを参照すれば、プロファイルダウンロードイベントはプロファイル遠隔管理イベントより優先順位が低くても端末が要請すれば端末に優先送信なることができるが、プロファイル遠隔管理イベントはプロファイルダウンロードイベントより優先順位が低いと、端末が要請しても端末に優先送信なれないように設定されることができる。この時、プロファイルサーバー２５０の実施形態のような手順でイベント記憶装置のイベント優先順位が整列されている場合、端末がプロファイルダウンロードイベントを明示して要請すれば第３の優先順位に該当するプロファイルダウンロードイベント(Ｐｒｏｆｉｌｅ１)が第１及び第２の優先順位に該当するプロファイル遠隔管理イベント(ＲＰＭ１及びＲＰＭ２)より優先選択されて‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔ)’ フィールドを介して端末に送信されることができる。この場合、残余イベント(ＲＰＭ１、ＲＰＭ２、ＲＰＭ３、Ｐｒｏｆｉｌｅ２)は後述する図８の実施形態によって‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’に含まれて端末２３０で送信されることができる。

図７Ｃを参照すれば、イベントの優先順位を除くと、どんなイベントも他のイベントより優先送信されることができないように設定されることができる。この時、プロファイルサーバー２５０の実施形態のような手順でイベント記憶装置のイベント優先順位が整列されている場合、端末がプロファイルダウンロードイベントを明示して要請しても最優先順位イベントであるプロファイル遠隔管理イベント(ＲＰＭ１)が優先実行されなければならないので、‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔ)’フィールドは空いているフィールドとなり、どんなイベントも端末に送信されないこともある。の場合、残余イベント(ＲＰＭ１、ＲＰＭ２、Ｐｒｏｆｉｌｅ１、ＲＰＭ３、Ｐｒｏｆｉｌｅ２)は後述する図８の実施形態によって‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’に含まれて送信されることができる。

前記図７Ａ、７Ｂ及び７Ｃの多様な実施形態で‘現在イベント'は優先送信設定可否によって一つのイベントだけ選択される場合を説明したが、これは図６Ａ、６Ｂ、６Ｃ及び６Ｄの実施形態で上述したように一つ以上のイベントが選択されることもできることに留意しなければならない。例えば、図７Ｂの実施形態で追加で図６Ａの実施形態のようにプロファイルダウンロードイベントのバンドル送信が可能となるように設定された場合、図７Ｂの７０３ｂ段階で‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’フィールドは２つのプロファイルダウンロードイベント(Ｐｒｏｆｉｌｅ１、Ｐｒｏｆｉｌｅ２)を同時に含みながら端末２３０で送信されることもできる。

図８は、本開示の一実施形態による端末のイベント要請メッセージに対し、端末が現在処理しなければならない‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’及びイベント記憶装置(Ｅｖｅｎｔ Ｓｔｏｒａｇｅ)に待機中の‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’を含んでプロファイルサーバーが端末に返信する応答メッセージを構成するとき、‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’の情報を構成する方法を示す図面である。

図８を参照すれば、８０１段階で端末２３０はプロファイルサーバー２５０にイベント要請メッセージを送信することができる。イベント要請メッセージの構成と詳細説明は図４の実施形態を参照する。前記端末のイベント要請メッセージに対し、８０３段階でプロファイルサーバーは、イベント記憶装置で優先順位によって選択した一つ以上の‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’と、当該イベントを除いてイベント記憶装置に残っているイベントの情報を用い、イベント応答メッセージを構成することができる。この時、現在イベントの選択に対して本実施形態では端末の要請に当たるように一つの遠隔管理イベント(ＲＰＭ１)が選択された場合を図示しているが、図６Ａ、６Ｂ、６Ｃ及び６Ｄの実施形態のようにプロファイルサーバーのバンドル送信可能可否の設定によって一つ以上のイベントが選択されることができ、図７Ａ、７Ｂ及び７Ｃの実施形態のように端末のイベント要請メッセージに明示されたイベント種類をイベント記憶装置で検索して最優先順位イベントより優先送信することもできることに留意しなければならない。さらに、次のイベントの情報は次のうちの一つ以上の情報要素(ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ)を用いて複合的に構成されることができるし、使用可能な情報要素はここに限定されない。

−残余イベントのうちの最も優先順位が高いイベントのイベント種類

−一つ以上の残余イベントのイベント種類

−一つ以上の残余イベントの存在有無

−残余イベントをイベント種類別で分類するときの各イベント種類の個数

例えば、図８の実施形態で最も優先順位が高いイベントのイベント種類だけ返信する場合、イベント応答メッセージは次のように構成されることができる。

− Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ＝ＲＰＭ１、Ｎｅｘｔ Ｅｖｅｎｔｓ＝“ＲＰＭ”

他の例として、図８の実施形態で、残っているすべてのイベントのイベント種類を返信する場合、イベント応答メッセージは次のように構成されることができる。

− Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ＝ＲＰＭ１、Ｎｅｘｔ Ｅｖｅｎｔｓ＝“ＲＰＭ、ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ、ＲＰＭ、ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ ”

他の例で、図８の実施形態で、残余イベントをイベント種類別で分類して各イベント種類の個数を返信する場合、イベント応答メッセージは次のように構成されることができる。

− Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ＝ＲＰＭ１、Ｎｅｘｔ Ｅｖｅｎｔｓ＝“ＲＰＭ(２)、ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ(２)”

他の例として、図８の実施形態で、イベント種類に関係なく残余イベントが一つ以上残っていることを返信する場合、イベント応答メッセージは次のように構成されることができる。

− Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ＝ＲＰＭ１、Ｎｅｘｔ Ｅｖｅｎｔｓ＝ＴＲＵＥ

前記実施形態でイベント種類の表記はテキスト(“ＲＰＭ”又は“ＰｒｏｆｉｌｅＤｏｗｎｌｏａｄ”)を用いたが、図４の実施形態で前述したようにテキストだけではなく数字列を用いることもできることは勿論である。また、イベント種類に関係なく一つ以上のイベントが存在することを端末に公知しようとする場合、テキストや数字列の代わりに正／偽(ＴＲＵＥ／ＦＡＬＳＥ)を有するバイナリー認知者(Ｂｏｏｌｅａｎ)を用いることもできる。

図９は、本開示の一実施形態によって、前記図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ及び図８の多様な実施形態で説明したイベントバンドル送信及びイベント優先送信設定可否を参照し、プロファイルサーバーが端末のイベント要請メッセージに対するイベント応答メッセージを構成する手続きを示す図面である。

図９を参照すれば、９０１段階でプロファイルサーバーは端末からイベント要請メッセージを受信することができる。前記イベント要請メッセージには上述した図４の実施形態によって端末が要請するイベントの種類と、現在端末にプロファイル遠隔管理機能が活性化／非活性化(Ｏｎ／Ｏｆｆ)されたか否かが明示されることができる。

９０１段階の実行以後、又は９１３段階の確認が失敗する場合、９０３段階でプロファイルサーバーは前記イベント要請メッセージを送信した端末のｅＵＩＣＣに対応するイベント記憶装置内のイベントを上述した図５の実施形態によって優先順位手順で整列することができる。

９０５段階でプロファイルサーバーはイベント記憶装置内の最優先順位イベントの種類が端末が９０１段階で要請したイベント種類と符合するか確認する。

９０５段階の確認手続きが失敗したり、９０９段階の確認手続きが成功する場合、９０７段階でプロファイルサーバーは上述した図７Ａ、７Ｂ及び７Ｃの実施形態によって端末が要請したイベント種類に該当するイベントを９０５段階で確認したイベント記憶装置内最優先順位イベントより優先送信することができるか確認する。

９０７段階の確認手続きが成功する場合、９１５段階でプロファイルサーバーはイベント記憶装置で端末が要請したイベント種類に符合するイベントのうちの最も優先順位が高いイベントを探索する。

９０５段階の確認手続きが成功したり、９１５段階の実行以後、９０９段階でプロファイルサーバーは当該のイベントがプロファイル遠隔管理イベントであり、同時に９０１段階で受信した端末のイベント要請メッセージに現在端末のプロファイル遠隔管理機能が非活性化(Ｏｆｆ)されているかを確認する。

９０９段階の確認手続きが失敗する場合、プロファイルサーバーは上述した図７Ａ、７Ｂ及び７Ｃの実施形態によってイベント記憶装置で当該イベントを抽出して‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’ フィールドに当該イベントを追加する。

９１１段階の実行以後、９１３段階でプロファイルサーバーは上述した図６Ａ、６Ｂ、６Ｃ及び６Ｄの実施形態によって他のイベントを当該イベントとバンドル送信可能か確認する。

９１３段階の確認手続きに失敗したり、９０７段階の確認手続きに失敗する場合、９１７段階でプロファイルサーバーは上述した図８の実施形態によって‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’フィールドを構成する。

９１７段階の実行以後、９１９段階でプロファイルサーバーは‘現在イベント(Ｃｕｒｒｅｎｔ Ｅｖｅｎｔｓ)’と‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’から構成されたイベント応答メッセージを端末に送信することができる。もし、イベント応答メッセージの送信に失敗したり、追後端末からイベント応答メッセージの処理失敗に対する返信を受信する場合、プロファイルサーバーは１回以上行われた９１１段階のイベント記憶装置内のイベント抽出動作を復元(ｒｅｓｔｏｒｅ)することができる。

図１０は、本発明の実施形態によって、端末２３０がプロファイルサーバー２５０から一つ以上のイベントを順次に受信して行う手続きの一例を示す図面である。

本実施形態では端末にＩＣＣＩＤ１に該当するプロファイルが設置／活性化されており、端末のプロファイル遠隔管理機能は活性化(Ｏｎ)されており、プロファイルサーバーのイベント記憶装置はイベント登録時間手順によって整列されており、プロファイル遠隔管理イベントはバンドル送信が不可能であるがプロファイルダウンロードイベントはバンドル送信が可能であり、どんなイベントも優先順位を外れた優先送信が不可能であり、‘次のイベント’の構成はイベント記憶装置内の最優先順位イベントのイベント種類のみを記載する場合を仮定する。

図１０を参照すれば、１００１段階で端末はユーザから“プロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)”に対するコマンドを受信することができる。

１００３段階で端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを行い、上述した図４の実施形態によってユーザの要請に当たるようにプロファイルダウンロードイベントをプロファイルサーバーに要請することができる。

１００５段階でプロファイルサーバーは上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の多様な実施形態によってイベント記憶装置の最優先順位イベントであるプロファイルダウンロードイベント(ＩＣＣＩＤ２)と共に一つ以上のプロファイル遠隔管理イベントが待機中であることを端末に公知することができる。

１００７段階で端末は前記受信したプロファイルダウンロードイベントによってプロファイル(ＩＣＣＩＤ２)を設置することができる。

１００９段階で端末は前記遂行完了したプロファイルダウンロードイベントに対してその実行結果(すなわち、プロファイルの設置結果(ＩＣＣＩＤ２ Ｉｎｓｔａｌｌａｔｉｏｎ Ｒｅｓｕｌｔ))をプロファイルサーバーに送信することができる。

１０１１段階でプロファイルサーバーは前記イベント実行結果を成功的に受信したことを端末に公知することができる。さらに、プロファイルサーバーは前記１００５段階だけではなく１０１１段階でもイベント記憶装置に残っている ‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’を端末に公知することができる。前記‘次のイベント(Ｎｅｘｔ Ｅｖｅｎｔｓ)’を公知する２つの種類のメッセージは相互補完的で、２つのメッセージのいずれも‘次のイベント’を公知したり、２のうちの一つのメッセージでばかり‘次のイベント’を公知することもできる。２つのメッセージのいずれも‘次のイベント’を公知する場合、２つのメッセージに含まれた‘次のイベント’リストは互いに異なることができる。例えば、１００５段階のメッセージ送信以後１００７乃至１００９段階の実行途中のプロファイルサーバーのイベント記憶装置内のイベントの優先順位が変更される場合、１０１１段階のメッセージ内に含まれた‘次のイベント’ リストは変更されることができる。

１０１３段階で端末は、前記１００５乃至１０１１段階でプロファイルサーバーが公知した‘次のイベント’リストによって、次の順番に行うイベントをプロファイルサーバーに再び要請することができる。本再要請メッセージの送信時、前記１００３段階の端末とプロファイルサーバー間のＴＬＳ保安接続及び相互認証手続きがまだ有効な場合、端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを省略することができる。また、端末は必要な場合、プロファイルサーバーにイベントを要請する予定であることをユーザに通知し、ユーザの同意を求めた後にプロファイルサーバーにイベント要請メッセージを送信することができる。もし、ユーザが同意しない場合、端末は追加的なイベント要請なしに手続きを終了することができる。また、端末は‘次のイベント' リストによって次の順番に行うイベントがプロファイル遠隔管理イベントの場合、当該イベントの対象となるプロファイルの識別子が明確ではないので、イベント要請種類(ＥｖｅｎｔＲｅｑＴｙｐｅ)をプロファイル遠隔管理で設定してプロファイル識別子を明示しないこともある。プロファイル識別子を明示しない方法はＮＵＬＬ文字列を送信したり、プロファイル識別子フィールドを送信しないこともある。

１０１５段階でプロファイルサーバーは上述した図６乃至図９の実施形態によってイベント記憶装置の最優先順位イベントであるプロファイル遠隔管理イベント(Ｕｐｄａｔｅ ＩＣＣＩＤ１)と共に一つ以上のプロファイル遠隔管理イベントが待機中であることを端末に公知することができる。

１０１７段階で端末は前記受信したプロファイル遠隔管理イベントによってプロファイルを管理(ＩＣＣＩＤ１)に該当するプロファイルの内容を変更)できる。

１０１９段階で端末は前記実行完了したプロファイル遠隔管理イベントに対してその実行結果(すなわち、プロファイルの変更結果(ＩＣＣＩＤ１ Ｕｐｄａｔｅ Ｒｅｓｕｌｔ))をプロファイルサーバーに送信することができる。

１０２１段階でプロファイルサーバーは前記イベント実行結果を成功的に受信したことを端末に公知することができる。さらに、プロファイルサーバーは、上述した１０１１段階の手続きと同様に、前記１０１５段階だけではなく１０２１段階でもイベント記憶装置に残っている‘次のイベント’を端末に公知することができる。‘次のイベント’ リストの構成に対する詳細な説明は１０１１段階の説明を参照する。

１０２３段階で端末は、上述した１０１３段階の手続きと同様に、前記１０１５乃至１０２１段階でプロファイルサーバーが公知した‘次のイベント’ リストによって、次の順番に行うイベントをプロファイルサーバーに再要請することができる。ＴＬＳ及び保安接続とユーザ同意に対する詳細な説明は１０１３段階の説明を参照する。また、端末は‘次のイベント’リストによって次の順番に行うイベントがプロファイル遠隔管理イベントの場合、当該イベントの対象となるプロファイルの識別子が明確ではないので、イベント要請種類(ＥｖｅｎｔＲｅｑＴｙｐｅ)をすべてのイベント(“ＡＮＹ”)で設定してプロファイル識別子(ＰｒｏｆｉｌｅＩＤ)を明示しないこともある。‘すべてのイベント’を明示する方法は上述した図４の実施形態を参照する。また、以後の手続きは上述した１００１段階乃至１０２３段階の繰り返しを介して行われることができることは容易に理解されることができるだろう。

図１１は、本発明の実施形態によって端末２３０がプロファイルサーバー２５０から一つ以上のイベントを順次に受信して行う手続きの一実施形態を示す図面である。

本実施形態では端末にＩＣＣＩＤ１に該当するプロファイルが設置／活性化されており、端末のプロファイル遠隔管理機能は活性化(Ｏｎ)されており、プロファイルサーバーのイベント記憶装置はイベント登録時間手順によって整列されており、プロファイル遠隔管理イベントはバンドル送信が可能であるがプロファイルダウンロードイベントはバンドル送信が不可能で、どんなイベントも優先順位を外れた優先送信が不可能で、‘次のイベント’の構成はイベント記憶装置内のすべてのイベントの種類及び個数を記載する場合を仮定する。

図１１を参照すれば、１１０１段階で端末はユーザから特定プロファイル(本実施形態ではＩＣＣＩＤ１)が選択されて“プロファイル更新(Ｒｅｆｒｅｓｈ Ｐｒｏｆｉｌｅ)”に対するコマンドを受信することができる。

１１０３段階で端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを行い、上述した図４の実施形態によってユーザの要請に当たるようにプロファイル遠隔管理イベントをプロファイルサーバーに要請することができる。

１１０５段階でプロファイルサーバーは上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の実施形態によってイベント記憶装置の最優先順位イベントであるプロファイルダウンロードイベントを探索し、当該イベントが端末が要請したイベント種類(プロファイル遠隔管理)と符合せず優先順位を外れた優先送信が不可能であるのでどんなイベントも伝達せず、‘次のイベント’リストを用いて一つのプロファイルダウンロードイベントと３つのプロファイル遠隔管理イベントが待機中であることを端末に公知することができる。

１１０７段階で端末は前記受信した‘次のイベント’リストによって、プロファイル更新コマンドを下したユーザに‘プロファイル更新は現在不可能でプロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)を優先的に実行しなければならない’ことを通知してユーザの同意を求めることができる。もし、ユーザが同意しない場合、端末は追加的な動作なしに手続きを終了することができる。

１１０９段階で端末は、前記１１０５段階でプロファイルサーバーが公知した‘次のイベントリスト’及び１１０７段階で受信したユーザ同意によって、次の順番に行うイベントをプロファイルサーバーに再び要請することができる。本再要請メッセージの送信時、前記１１０３段階の端末とプロファイルサーバー間のＴＬＳ保安接続又は相互認証手続き中の一つ以上が予め終了されたり、プロファイルサーバーの政策上の新しいイベント要請メッセージが新しいトランザクション識別子(Ｔｒａｎｓａｃｔｉｏｎ ＩＤ)で区分されなければならない場合、端末はプロファイルサーバーと新しいＴＬＳ保安接続及び相互認証手続きを行うことができる。

１１１１段階でプロファイルサーバーは、上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の多様な実施形態によって、イベント記憶装置の最優先順位イベントであるプロファイルダウンロードイベント(ＩＣＣＩＤ２)と共に、‘次のイベント’リストを用いて３つのプロファイル遠隔管理イベントが待機中であることを端末に公知することができる。本実施形態では１１０９段階に対する即刻的な応答でプロファイルパッケージが送信される場合を図示したが、上述した図２の例示のように、プロファイル要約情報(Ｐｒｏｆｉｌｅ Ｍｅｔａｄａｔａ)を優先送信(２１１段階)と、プロファイル設置に対するユーザ同意を再び求めた以後(２１３段階)、端末がプロファイルパッケージをプロファイルサーバーに要請(２１５段階)し、プロファイルパッケージを端末で送信することができる。この場合、追加的なユーザ同意は前記１１０７段階のユーザ同意と統合されることができる。

１１１３段階で端末は前記受信したプロファイルダウンロードイベント(より具体的にはプロファイルパッケージ)によってプロファイル(ＩＣＣＩＤ２)を設置することができる。

１１１５段階で端末は前記遂行完了したプロファイルダウンロードイベントに対してその実行結果(すなわち、プロファイルの設置結果(ＩＣＣＩＤ２ Ｉｎｓｔａｌｌａｔｉｏｎ Ｒｅｓｕｌｔ))をプロファイルサーバーに送信することができる。

１１１９段階でプロファイルサーバーは前記イベント実行結果を成功的に受信したことを端末に公知することができる。また、プロファイルサーバーは、本図面には図示しないが、上述した図１０の実施形態と同様に、前記１１１１段階の‘次のイベント’リストを１１１９段階で繰り返すことができる。

１１１９段階で端末は、上述した１１０９段階の手続きと同様に、前記１１１１乃至１１１７段階でプロファイルサーバーが公知した‘次のイベント’リストによって、次の順番に行うイベントをプロファイルサーバーに再び要請することができる。ＴＬＳ及び保安接続とユーザ同意に対する詳細な説明は１１０９段階の説明を参照する。さらに、端末は‘次のイベント’ リストによって次の順番に行うイベントがプロファイル遠隔管理イベントの場合、当該イベントの対象となるプロファイルの識別子が明確ではないので、イベント要請種類(ＥｖｅｎｔＲｅｑＴｙｐｅ)をすべてのイベント(“ＡＮＹ”)で設定することができる。

１１２１段階でプロファイルサーバーは上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の多様な実施形態によってイベント記憶装置の最優先順位イベントであるプロファイル遠隔管理イベント(Ｕｐｄａｔｅ ＩＣＣＩＤ１)と共に他のプロファイル遠隔管理イベント(Ｅｎａｂｌｅ ＩＣＣＩＤ２、Ｄｉｓａｂｌｅ ＩＣＣＩＤ１)をバンドル送信することができる。また、当該プロファイル遠隔管理イベントのバンドル送信以後にイベント記憶装置に待機中のイベントがないので‘次のイベント’ リストに何も無し(“Ｎｏｔｈｉｎｇ Ｍｏｒｅ”)を公知することができる。‘次のイベント’ リストが空いていることを公知する方法は、本実施形態のようにテキストを利用したり、ＮＵＬＬデータを利用したり、‘次のイベント’リスト自体を省略したり、すべてのイベント種類に対して残余イベントが０であることを通知するなどの方法を用いることができる。

１１２３段階で端末は前記受信したプロファイル遠隔管理イベントを順次に処理することができる。さらに、以後の手続きは上述した１１０１乃至１１２３段階の繰り返しを介して行われることができることは容易に理解されることができるだろう。

図１２は、本発明の実施形態によって端末２３０がプロファイルサーバー２５０から一つ以上のイベントを順次に受信して行う手続きの一例を示す図面である。

本実施形態では端末にＩＣＣＩＤ１に該当するプロファイルが設置／活性化されており、端末のプロファイル遠隔管理機能は活性化(Ｏｎ)されており、プロファイルサーバーのイベント記憶装置はイベント登録時間手順によって整列されており、どんなイベントもバンドル送信が不可能で、端末が要請する場合、プロファイル遠隔管理イベントだけプロファイルダウンロードイベントより優先送信が可能で、‘次のイベント'の構成はイベント記憶装置内の最優先順位イベントのイベント種類のみを記載する場合を仮定する。

図１２を参照すれば、１２０１段階で端末はユーザから特定プロファイル(本実施形態ではＩＣＣＩＤ１)を選択して“プロファイル更新(Ｒｅｆｒｅｓｈ Ｐｒｏｆｉｌｅ)”に対するコマンドを受信することができる。

１２０３段階で端末はプロファイルサーバーとＴＬＳ保安接続及び相互認証手続きを行い、上述した図４の実施形態によってユーザの要請に当たるようにプロファイル遠隔管理イベントをプロファイルサーバーに要請することができる。

１２０５段階でプロファイルサーバーは、上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の実施形態によってイベント記憶装置の最優先順位イベントであるプロファイルダウンロードイベントを探索し、当該のイベントが端末が要請したイベント種類(プロファイル遠隔管理)と符合しないが、プロファイル遠隔管理イベントは優先順位を外れた優先送信が可能であるので、イベント記憶装置で端末が要請したイベント種類(プロファイル遠隔管理)に当たるイベントの中で最も優先順位が高いイベント(本実施形態ではＵｐｄａｔｅ ＩＣＣＩＤ１)を優先送信することができる。またプロファイルサーバーは、‘次のイベント' リストを用いて当該イベントを除いてイベント記憶装置で最優先順位イベントであるプロファイルダウンロードイベントが待機中であることを端末に公知することができる。

１２０７段階で端末は前記受信したプロファイル遠隔管理イベントを行うことができる。以後プロファイル遠隔管理イベントの実行結果に対する報告は必要な場合、省略されることができる。

１２０９段階で端末は前記受信した‘次のイベント’リストによって、プロファイル更新コマンドしたユーザに‘プロファイル更新以後にプロファイル設置(Ａｄｄ Ｐｒｏｆｉｌｅ)が行われる必要が有り’ことを通知してユーザの同意を求めることができる。もし、ユーザが同意しない場合、端末は追加的な動作なしに手続きを終了することができる。

１２１１段階で端末は、前記１２０５段階でプロファイルサーバーが公知した‘次のイベント' リストによって、次の順番に行うイベントをプロファイルサーバーに再び要請することができる。本再要請メッセージの送信時、前記１２０３段階の端末とプロファイルサーバー間のＴＬＳ保安接続又は相互認証手続き中の一つ以上が予め終了されたり、プロファイルサーバーの政策上の新しいイベント要請メッセージが新しいトランザクション識別子(Ｔｒａｎｓａｃｔｉｏｎ ＩＤ)で区分されなければならない場合、端末はプロファイルサーバーと新しいＴＬＳ保安接続及び相互認証手続きを行うことができる。

１２１３段階でプロファイルサーバーは、上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の多様な実施形態によって、イベント記憶装置の最優先順位イベントであるプロファイルダウンロードイベント(ＩＣＣＩＤ２)と共に、‘次のイベント’リストを用いて２つのプロファイル遠隔管理イベントが待機中であることを端末に公知することができる。本実施形態では１２１１段階に対する即刻的な応答でプロファイルパッケージが送信される場合を図示したが、上述した図２の例示のように、プロファイル要約情報(Ｐｒｏｆｉｌｅ Ｍｅｔａｄａｔａ)を優先送信(２１１段階)し、プロファイル設置に対するユーザ同意を再び求めた以後(２１３段階)、端末がプロファイルパッケージをプロファイルサーバーに要請(２１５段階)し、プロファイルパッケージを端末で送信することができる。この場合追加的なユーザ同意は前記１２０９段階のユーザ同意と統合されることができる。

１２１５段階で端末は前記受信したプロファイルダウンロードイベント(より具体的にはプロファイルパッケージ)によってプロファイル(ＩＣＣＩＤ２)を設置することができる。

１２１７段階で端末は前記実行完了したプロファイルダウンロードイベントに対してその実行結果(すなわち、プロファイルの設置結果(ＩＣＣＩＤ２ Ｉｎｓｔａｌｌａｔｉｏｎ Ｒｅｓｕｌｔ))をプロファイルサーバーに送信することができる。

１２１９段階でプロファイルサーバーは前記イベント遂行結果を成功的に受信したことを端末に公知することができる。さらに、プロファイルサーバーは、本図面には図示しないが、上述した図１０の実施形態と同様に、前記１１１３段階の‘次のイベント’リストを１２１９段階で繰り返すことができる。

１２２１段階で端末は、上述した１２１１段階の手続きと同様に、前記１２１３乃至１２１９段階でプロファイルサーバーが公知した‘次のイベント’リストによって、次の順番に行うイベントをプロファイルサーバーに再び要請することができる。ＴＬＳ及び保安接続とユーザ同意に対する詳細な説明は１２１１段階の説明を参照する。また、端末は‘次のイベント’リストによって次の順番に行うイベントがプロファイル遠隔管理イベントの場合、当該イベントの対象となるプロファイルの識別子が明確ではないので、イベント要請種類(ＥｖｅｎｔＲｅｑＴｙｐｅ)をすべてのイベント(“ＡＮＹ”)で設定することができる。

１２２３段階でプロファイルサーバーは上述した図６Ａ、６Ｂ、６Ｃ、６Ｄ、７Ａ、７Ｂ、７Ｃ、８及び９の多様な実施形態によってイベント記憶装置の最優先順位イベントであるプロファイル遠隔管理イベント(Ｅｎａｂｌｅ ＩＣＣＩＤ２)と共に、‘次のイベント' リストを用いてプロファイル遠隔管理イベントが待機中であることを端末に公知することができる。

１２２５段階で端末は前記受信したプロファイル遠隔管理イベントによってプロファイルを管理(ＩＣＣＩＤ２を活性化)することができる。また、以後の手続きは上述した１２０１乃至１２２５段階の繰り返しを介して行われることができるだろう。

図１３は、本発明の一実施形態によって、プロファイルサーバーを介してプロファイルを設置する場合、端末２３０がプロファイルサーバー２５０に‘プロファイルダウンロード’を要請してこれに対する応答を受信する手続きを示す図面である。

図１３を参照すれば、１３０１段階で端末２３０はプロファイルサーバー２５０に‘任意の文字列(Ｃｈａｌｌｅｎｇｅ)’を送信することができる。前記１３０１段階の通信はＨＴＴＰＳ乃至ＴＬＳ 保安接続を介して保護されることができる。１３０３段階でプロファイルサーバー２５０は端末２３０にサーバーのシグネチャー(Ｓｉｇｎａｔｕｒｅ)のように‘任意の文字列(Ｃｈａｌｌｅｎｇｅ)’を送信することができる。１３０５段階で端末２３０は端末認証要請メッセージをプロファイルサーバー２５０で送信することができる。具体的に、端末２３０はプロファイルサーバー２５０に端末認証要請メッセージを用い、端末２３０のシグネチャー(Ｓｉｇｎａｔｕｒｅ)と共に要請する特定イベントの種類(Ｏｐｅｒａｔｉｏｎ Ｔｙｐｅ)に対する情報を送信することができる。本実施形態では、プロファイルサーバーのイベント記憶装置２７０にプロファイルが待機中で、端末が‘プロファイルダウンロード(Ｐｒｏｆｉｌｅ ＤＬ)’を要請する場合を説明する。前記１３０３乃至１３０５段階で端末２３０とプロファイルサーバー２５０のメッセージ交換手続きは相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)で命名されることができる。１３０７段階でプロファイルサーバー２５０は端末２３０で端末認証応答メッセージを送信することができる。具体的に、プロファイルサーバー２５０は、端末２３０が前記１３０５段階で要請した通り、プロファイルダウンロードのための準備の一環でプロファイル要約情報(Ｐｒｏｆｉｌｅ Ｍｅｔａｄａｔａ)と使い捨て公開キー(Ｏｎｅ−ｔｉｍｅ Ｐｕｂｌｉｃ Ｋｅｙ)を含む端末認証応答メッセージを端末２３０に送信することができる。前記プロファイル要約情報はサービス提供者の名前と、サービス提供者が設定したロゴ及び料金制の情報などを含むことができる。１３０９段階で端末２３０は前記１３０７段階で受信したプロファイル要約情報に基づいてプロファイル設置に対するユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力されることができる。ユーザがプロファイル設置に同意する場合、１３１１段階で端末２３０は使い捨て公開キー(Ｏｎｅ−ｔｉｍｅ Ｐｕｂｌｉｃ Ｋｅｙ)をプロファイルサーバー２５０に送信することができる。１３１３段階で端末２３０とプロファイルサーバー２５０は前記１３０７乃至１３１１段階で相互交換した使い捨て公開キー及びそれに相応する使い捨て個人キー(Ｏｎｅ−ｔｉｍｅ Ｐｒｉｖａｔｅ Ｋｅｙ)を組み合わせてセッションキー(Ｓｅｓｓｉｏｎ Ｋｅｙ)を生成することができる。１３１５段階でプロファイルサーバー２５０は前記１３１３段階で生成したセッションキーを用いて暗号化されたプロファイルパッケージを端末２３０に返信することができる。以後、１３１７段階で端末２３０は暗号化されたプロファイルパッケージを復号化(Ｄｅｃｒｙｐｔ)及び設置(Ｉｎｓｔａｌｌａｔｉｏｎ)することができる。

前記プロファイルダウンロード手続きは、後述するプロファイル遠隔管理手続きに比べ、前記１３１１乃至１３１５段階で後述したように、実際プロファイル設置に必要なプロファイルパッケージを受信するために端末２３０とプロファイルサーバー２５０間の１個のメッセージ交換を追加で活用する。

図１４は、本開示の一実施形態の他のプロファイルサーバーを介して遠隔管理を行う場合、端末２３０がプロファイルサーバー２５０に‘プロファイル遠隔管理’を要請し、前記要請に対する応答を受信する手続きを示す図面である。

図１４を参照すれば、１４０１段階で端末２３０はプロファイルサーバー２５０に‘任意の文字列(Ｃｈａｌｌｅｎｇｅ)’を送信することができる。前記１４０１段階の通信はＨＴＴＰＳ乃至ＴＬＳ保安接続を介して保護されることができる。１４０３段階でプロファイルサーバー２５０は端末２３０にサーバーのシグネチャー(Ｓｉｇｎａｔｕｒｅ)と共に‘任意の文字列(Ｃｈａｌｌｅｎｇｅ)’を送信することができる。１４０５段階で端末２３０はプロファイルサーバー２５０に端末のシグネチャー(Ｓｉｇｎａｔｕｒｅ)と共に特定イベントの種類(ＯｐｅｒａｔｉｏｎＴｙｐｅ)を要請することができる。本実施形態では、プロファイルサーバーのイベント記憶装置２７０に遠隔管理コマンドが待機中で、端末２３０が‘プロファイル遠隔管理(ＲＰＭ)’を要請する場合を説明する。前記１４０３乃至１４０５段階で端末２３０とプロファイルサーバー２５０のメッセージ交換手続きは相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)で命名されることができる。１４０７段階でプロファイルサーバー２５０は、端末２３０が前記１４０５段階で要請した通り、プロファイル遠隔管理コマンドを含むパッケージ(ＲＰＭ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ)を端末２３０に送信することができる。１４０９段階で端末２３０は前記１４０７段階で受信したプロファイル遠隔管理に基づいてプロファイル管理に対するユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力されることができる。ユーザがプロファイル遠隔管理に同意する場合、１４１１段階で端末２３０はプロファイル遠隔管理コマンドを行うことができる。

前記プロファイル遠隔管理手続きで端末２３０は、前記１４０７段階ですべてのプロファイル遠隔管理コマンドを受信することができるので、図１３で前述したプロファイルダウンロード手続きに比べ、図１３の１３１１乃至１３１５段階に該当する端末２３０とプロファイルサーバー２５０間の１回メッセージ交換を追加で所要しない。

図１５は、本開示の一実施形態による、プロファイルサーバーを介して二つのプロファイルを設置して２回の遠隔管理を行う場合、端末２３０がプロファイルサーバー２５０にすべての種類のイベントを要請し、前記要請に対する応答を受信する手続きを示す図面である。

図１５を参照すれば、１５０１段階で端末２３０はプロファイルサーバー２５０に‘任意の文字列(Ｃｈａｌｌｅｎｇｅ)’を送信することができる。前記１５０１段階の通信はＨＴＴＰＳ乃至ＴＬＳ保安接続を介して保護されることができる。１５０３段階でプロファイルサーバー２５０は端末２３０にサーバーのシグネチャー(Ｓｉｇｎａｔｕｒｅ)と共に‘任意の文字列(Ｃｈａｌｌｅｎｇｅ)’を送信することができる。１５０５段階で端末２３０はプロファイルサーバー２５０に端末のシグネチャー(Ｓｉｇｎａｔｕｒｅ)と共に特定イベントの種類(ＯｐｅｒａｔｉｏｎＴｙｐｅ)を要請することができる。本実施形態ではプロファイルサーバーのイベント記憶装置２７０に２つの遠隔管理コマンドと２つのプロファイルが待機中で、端末が‘すべてのタイプ(ＡＬＬ)’を要請する場合を説明する。前記１５０３乃至１５０５段階で端末２３０とプロファイルサーバー２５０のメッセージ交換手続きは相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)で命名されることができる。１５０７段階でプロファイルサーバー２５０は、端末２３０が前記１５０５段階で要請した通り、プロファイル遠隔管理１、プロファイル要約情報１、プロファイル遠隔管理２、プロファイル要約情報２を同時に送信することができる。１５０９段階で端末２３０は前記１５０７段階で受信したプロファイル遠隔管理乃至プロファイル要約情報に基づいてプロファイル管理及び設置に対するユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力されることができる。

前記１５０９段階以後端末２３０は、ユーザが同意する場合、各プロファイル遠隔管理及びプロファイル設置手続きを実行しなければならない。この時、プロファイル遠隔管理(プロファイル遠隔管理１及びプロファイル遠隔管理２)は前記１５０９段階以後、直ちに実行可能な一方、プロファイル設置(プロファイル要約情報１及びプロファイル要約情報２)は各プロファイル設置ごとに前記図１３の１３１１乃至１３１５段階で上述したように端末２３０とプロファイルサーバー２５０間の１個のメッセージ交換を追加で行ってプロファイルパッケージを確保しなければならない。端末２３０がプロファイル遠隔管理とプロファイル設置を順次に処理する具体的な方案は図１６乃至図１７で詳しく説明する。

だけでなく、前記１５０７段階の各プロファイル要約情報及びプロファイル遠隔管理データは端末２３０がデータ無欠性(ｉｎｔｅｇｒｉｔｙ)を検証するためのプロファイルサーバー２５０のシグネチャー(Ｓｉｇｎａｔｕｒｅ)を伴う。この時、プロファイル要約情報データのためのシグネチャーとプロファイル遠隔管理データのためのシグネチャーの生成方法(例えば、デジタルシグネチャーアルゴリズム又はシグネチャー用デジタル認証書の種類など)が異なる場合、プロファイルサーバー２５０はシグネチャーの生成とデータの配置を適切に調律して端末２３０が容易にシグネチャーを検証して各データを処理するようにサポートすることができる。プロファイルサーバー２５０がデジタルシグネチャーを生成してデータを配置する方法は図１８乃至図２１で詳しく説明する。

図１６は、本発明の実施形態によって、端末２３０がすべてのイベントに対するデータを先ず確保した後順次にイベントを処理する方法を示す図面である。

図１６を参照すれば、１６０１段階で端末２３０とプロファイルサーバー２５０は相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)を行うことができる。相互認証手続き及び端末２３０の動作要請メッセージに対する詳細な説明は前記図１５の１５０３乃至１５０５段階の説明を参照する。１６０３段階でプロファイルサーバー２５０はプロファイル遠隔管理１、プロファイル要約情報１、プロファイル遠隔管理２、プロファイル要約情報２を同時に送信することができる。１６０５段階で端末２３０は前記１６０３段階で受信したプロファイル遠隔管理乃至プロファイル要約情報に基づいてプロファイル遠隔管理及び設置に対するユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力されることができる。ユーザが同意する場合、端末２３０は１６０７段階乃至１６０９段階でプロファイル要約情報１及びプロファイル要約情報２に該当するプロファイルパッケージ１及びプロファイルパッケージ２をそれぞれ要請してプロファイルサーバー２５０から受信することができる。以後端末２３０は、前記１６０３段階でプロファイルサーバー２５０が明示したデータ処理手順によって、１６１１段階でプロファイル遠隔管理１を行い、１６１３段階でプロファイルパッケージ１を設置し、１６１５段階でプロファイル遠隔管理２を行い、１６１７段階でプロファイルパッケージ２を設置することができる。

前記手続きで端末２３０は、前記１６０３段階で受信したすべての種類のイベントに対し、各イベントを処理するのに用いられるデータ(すなわち、プロファイル設置のためのプロファイルパッケージ)を前記１６０７乃至１６０９段階で一括確保し、前記１６０３段階でプロファイルサーバー２５０が明示したデータ処理手順によってプロファイル遠隔管理及びプロファイル設置を処理することができる。

図１７は、本発明の実施形態によって、端末２３０がイベントの受信手順によって各イベントに対するデータを確保して処理する方法を示す図面である。

図１７を参照すれば、１７０１段階で端末２３０とプロファイルサーバー２５０は相互認証手続き(Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ)を行うことができる。相互認証手続き及び端末２３０の動作要請メッセージに対する詳細な説明は前記図１５の１５０３乃至１５０５段階の説明を参照する。１７０３段階でプロファイルサーバー２５０はプロファイル遠隔管理１、プロファイル要約情報１、プロファイル遠隔管理２、プロファイル要約情報２を同時に送信することができる。１７０５段階で端末２３０は前記１７０３段階で受信したプロファイル遠隔管理乃至プロファイル要約情報に基づいてプロファイル遠隔管理及び設置に対するユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力されることができる。ユーザが同意する場合、端末２３０は前記１７０３段階でプロファイルサーバー２５０が明示したデータ処理手順によって、１７０７段階でプロファイル遠隔管理１を行い、１７０９段階でプロファイル要約情報１に該当するプロファイルパッケージ１を受信して１７１１段階でプロファイルパッケージ１を設置し、１７１３段階でプロファイル遠隔管理２を行い、１７１５段階でプロファイル要約情報２に該当するプロファイルパッケージ２を受信して１７１７段階でプロファイルパッケージ２を設置することができる。

前記手続きで端末２３０は、前記１７０３段階で受信したすべての種類のイベントに対し、１７０３段階でプロファイルサーバー２５０が明示したデータ処理手順によって、プロファイル遠隔管理は追加データ確保なしに優先実行し、必要な場合、前記１７０９又は１７１５段階のようにプロファイルサーバー２５０からプロファイルパッケージを追加確保してプロファイル設置を処理することができる。

図１８は、本発明の実施形態によって、前記図１６の １６０３段階乃至前記図１７の１７０３段階のプロファイルサーバー２５０メッセージに対し、プロファイルサーバー２５０がプロファイル遠隔管理ないしプロファイル要約情報を伝達するとき、各プロファイル遠隔管理及びプロファイル要約情報データに別途のシグネチャーを生成して添付する方法を示す図面である。

図１８を参照すれば、プロファイルサーバー２５０は１８０１プロファイル遠隔管理１データ及び １８０９プロファイル遠隔管理２データに対してそれぞれ１８０３及び１８１１のデジタルシグネチャーを生成することができる。また、プロファイルサーバー２５０は１８０５プロファイル要約情報１データ及び１８１３プロファイル要約情報２データに対してそれぞれ１８０７及び１８１５のデジタルシグネチャーを生成することができる。この時、端末２３０は、プロファイルサーバー２５０が各データの処理手順を明示しなくても、プロファイルサーバー２５０からデータを受信する順に処理することができる。本実施形態で端末２３０はプロファイル遠隔管理１、プロファイル要約情報１、プロファイル遠隔管理２、プロファイル要約情報２の手順でデータを処理することができる。

前記構成でプロファイルサーバー２５０は、各データが別に区分されたシグネチャーを伴うので、各データのシグネチャー生成に用いられるアルゴリズム及びデジタル認証書の種類を多様に活用することができる長所がある。

図１９は、本発明の実施形態によって、前記図１６の１６０３段階乃至前記図１７の１７０３段階のプロファイルサーバー２５０メッセージに対し、プロファイルサーバー２５０がプロファイル遠隔管理ないしプロファイル要約情報を伝達するとき、各プロファイル遠隔管理及びプロファイル要約情報データに別途のシグネチャーを生成して添付して各データの処理手順を明示する方法を示す図面である。

図１９を参照すれば、プロファイルサーバー２５０は１９０１プロファイル遠隔管理１データ及び １９０９プロファイル遠隔管理２データに対してそれぞれ１９０３及び１９１１のデジタルシグネチャーを生成することができる。さらに、プロファイルサーバー２５０は１９０５プロファイル要約情報１データ及び１９１３プロファイル要約情報２データに対してそれぞれ１９０７及び１９１５のデジタルシグネチャーを生成することができる。追加的にプロファイルサーバー２５０は各データの処理手順を銘記することができる。例えば、４つのデータを送信する本実施形態でプロファイルサーバー２５０は、１９０１プロファイル遠隔管理１データは４つのうちで第１(１／４)、１９０５プロファイル要約情報１データは４つのうちで第２(２／４)、１９０９プロファイル遠隔管理２データは４つのうちで第３(３／４)、１９１３プロファイル要約情報２データは４つのうちので第４(４／４)であることを各データに明示することができる。

前記構成でプロファイルサーバー２５０は、各データが別で区分されたシグネチャーを伴うので、各データのシグネチャー生成に用いられるアルゴリズム及びデジタル認証書の種類を多様に活用することができる長所がある。さらに、プロファイルサーバー２５０は、各データが処理手順を別で明示しているので、データの送信手順を自由に調節することができる長所がある。この時、プロファイルサーバー２５０がデータの処理手順を明示する本実施形態は前記図１９にだけ限定されず、データを受信順に処理する前記図１８の実施形態でもデータの処理手順を明示することができる。

図２０は、本発明の実施形態によって、前記図１６の１６０３段階乃至前記図１７の１７０３段階のプロファイルサーバー２５０メッセージに対し、プロファイルサーバー２５０がプロファイル遠隔管理ないしプロファイル要約情報を伝達するとき、各プロファイル遠隔管理及びプロファイル要約情報データのうちの一部に共通シグネチャーを生成して添付する方法を示す図面である。

図２０を参照すれば、プロファイルサーバー２５０は２００１プロファイル遠隔管理１データと２００９プロファイル遠隔管理２データ全体に対して２０１１のデジタルシグネチャー(すなわち、共通シグネチャー)を生成することができる。さらに、プロファイルサーバー２５０は２００５プロファイル要約情報１データと２０１３プロファイル要約情報２データ全体に対して２０１５のデジタルシグネチャー(すなわち、共通シグネチャー)を生成することができる。この時、端末２３０は、プロファイルサーバー２５０が各データの処理手順を明示しなくても、プロファイルサーバー２５０からデータを受信する順に処理することができる。本実施形態で端末２３０はプロファイル遠隔管理１、プロファイル要約情報１、プロファイル遠隔管理２、プロファイル要約情報２の手順でデータを処理することができる。

前記構成でプロファイルサーバー２５０が共通シグネチャーを生成するデータは必ず同一種類のデータに限るのではないことを留意しなければならない。例えば、図２０はプロファイル遠隔管理とプロファイル要約情報を分けて共通シグネチャーを生成する場合を図示すしたが、プロファイルサーバー２５０はシグネチャー生成方法(すなわち、シグネチャー生成アルゴリズム及びデジタル認証書)が等しいデータに対して共通シグネチャーを生成することができる。前記構成でプロファイルサーバー２５０は、シグネチャーを共有するデータに対してシグネチャーを省略することができるので、プロファイルサーバー２５０から端末２３０に送信されるデータの羊を減らすことができる。前記図２０の構成で端末２３０はプロファイルサーバー２５０のデータ全体を受信した後、シグネチャーを検証するためにシグネチャーの対象となるデータを別で集める必要がある。本実施形態で端末２３０は、２０１１のシグネチャーを検証するために、第１で受信した２００１プロファイル遠隔管理１データと第３で受信した２００９プロファイル遠隔管理２データを選別して集めなければならなく、２０１５のシグネチャーを検証するために、第２で受信した２００５プロファイル要約情報１データと第４で受信した２０１３プロファイル要約情報２データを選別して集めなければならない。

図２１は、本発明の実施形態によって、前記図１６の１６０３段階乃至前記図１７の１７０３段階のプロファイルサーバー２５０メッセージに対し、プロファイルサーバー２５０がプロファイル遠隔管理ないしプロファイル要約情報を伝達するとき、各プロファイル遠隔管理及びプロファイル要約情報データのうちの一部に共通シグネチャーを生成して添付して各データの処理手順を明示する方法を示す図面である。

図２１を参照すれば、プロファイルサーバー２５０は２１０１プロファイル遠隔管理１データと２１０９プロファイル遠隔管理２データ全体に対して２１１１のデジタルシグネチャー(すなわち、共通シグネチャー)を生成することができる。また、プロファイルサーバー２５０は２１０５プロファイル要約情報１データと２１１３プロファイル要約情報２データ全体に対して２１１５のデジタルシグネチャー(すなわち、共通シグネチャー)を生成することができる。追加的にプロファイルサーバー２５０は各データの処理手順を銘記することができる。例えば、４つのデータを送信する本実施形態でプロファイルサーバー２５０は、２１０１プロファイル遠隔管理１データは４つのうちので第１(１／４)、２１０５プロファイル要約情報１データは４つのうちの第２(２／４)、２１０９プロファイル遠隔管理２データは４つのうちで第３(３／４)、２１１３プロファイル要約情報２データは４つのうちで第４(４／４)であることを各データに明示することができる。

前記図２０の場合と同様に、前記図２１の構成でプロファイルサーバー２５０が共通シグネチャーを生成するデータは必ず同一種類のデータに限るのではないことを留意しなければならない。前記構成でプロファイルサーバー２５０は、シグネチャーを共有するデータに対してシグネチャーを省略することができるので、プロファイルサーバー２５０から端末２３０に送信されるデータの量を減らすことができる。さらに、プロファイルサーバー２５０は、各データが処理手順を別で明示しているので、データの送信手順を自由に調節することができる長所がある。例えば、プロファイルサーバー２５０は、前記図２０の実施形態で端末２３０がシグネチャー検証のためにデータを選別して集める手続きを除去するために、２１１１シグネチャーを共有する２１０１プロファイル遠隔管理１データと２１０９プロファイル遠隔管理２データを２１１１シグネチャー直前に配置し、２１１５シグネチャーを共有する２１０５プロファイル要約情報１データと２１１３プロファイル要約情報２データを２１１５シグネチャー直前に配置することができる。この時、端末２３０は２１１１及び２１１５のシグネチャー検証後、プロファイルサーバー２５０が明示したデータ処理順にプロファイル遠隔管理１、プロファイル要約情報１、プロファイル遠隔管理２、プロファイル要約情報２の手順でデータを処理することができる。

前記図１８乃至図２１のシグネチャー生成及びデータ配置の多様な実施形態は、前記図１６乃至図１７の手続きと併合して用いられることができることに留意しなければならない。このような場合、前記図１８乃至図２１の各シグネチャーを検証する手続きは、前記図１６乃至図１７の手続き内の時点に選択的に行われることができる。具体的な実施形態の一部は次の通りであるが、次の実施形態で限定されず、端末２３０の具現によってシグネチャー検証が必要な時点に行うことができる。

図２２は、本開示の一実施形態による前記図１７の手続きで前記図１８のシグネチャー生成及びデータ配置方法を用いる場合の実施形態を示す。

この時、前記図１７及び図１８で上述した手続きに対する説明及び参照番号は省略し、２２０１段階で端末２３０がプロファイルサーバー２５０から２２９０のような形態のメッセージを受信した場合を仮定する。端末２３０は ２２０３段階でユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力され、２２０５のシグネチャーを検証し、２２０７段階でプロファイル遠隔管理１を行い、２２０９のシグネチャーを検証し、２２１１段階でプロファイル要約情報１に該当するプロファイルパッケージ１を受信し、２２１３段階でプロファイルパッケージ１を設置し、２２１５のシグネチャーを検証し、２２１７段階でプロファイル遠隔管理２を行い、２２１９のシグネチャーを検証し、２２２１段階でプロファイル要約情報２に該当するプロファイルパッケージ２を受信し、２２２３段階でプロファイルパッケージ２を設置することができる。

図２３は、本開示の一実施形態による前記図１６の手続きで前記図１８のシグネチャー生成及びデータ配置方法を用いる場合のまた他の実施形態を示す。

この時、前記図１６及び図１８で上述した手続きに対する説明及び参照番号は省略し、２３０１段階で端末２３０がプロファイルサーバー２５０から２３９０のような形態のメッセージを受信した場合を仮定する。端末２３０は２３０３段階でユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力され、２３０５のシグネチャーを検証し、２３０７段階でプロファイル要約情報１に該当するプロファイルパッケージ１を受信し、２３０９のシグネチャーを検証し、２３１１段階でプロファイル要約情報２に該当するプロファイルパッケージ２を受信し、２３１３のシグネチャーを検証し、２３１５段階でプロファイル遠隔管理１を行い、２３１７段階でプロファイルパッケージ１を設置し、２３１９のシグネチャーを検証し、２３２１段階でプロファイル遠隔管理２を行い、２３２３段階でプロファイルパッケージ２を設置することができる。

上述したように端末２３０が受信したデータのうちのシグネチャーの検証は、データを受信した以後端末２３０が必要な時点に行うことができるので、ユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力される手続き以前に行われることもできる。例えば、別途の図面は図示しないが前記図１６の手続きで前記図２１のシグネチャー生成及びデータ配置方法を用いる場合、端末２３０は前記図１６の１６０３段階以後、前記図２１の２１１１シグネチャー及び２１１５シグネチャーを検証し、前記図１６の１６０５段階及びその後の段階を行うことができる。

また他の例として、別途の図面は図示しないが前記図１７の手続きで前記図１９のシグネチャー生成及びデータ配置方法を用いる場合、端末２３０は前記図１７の１７０５段階以後、前記図１９の１９０３シグネチャーを検証し、前記図１７の１７０７段階を行い、前記図１９の１９０７シグネチャーを検証し、前記図１７の１７０９乃至１７１１段階を行い、前記図１９の１９１１シグネチャーを検証し、前記図１７の１７１３段階を行い、前記図１９の８１５シグネチャーを検証し、前記図１７の１７１５乃至１７１７段階を行うことができる。

図２４Ａ、２４Ｂ、２５及び２６は本開示の一実施形態によって、前記図１６乃至図１７の手続きで端末２３０が１６０５又は１７０５段階でユーザ同意(Ｅｎｄ Ｕｓｅｒ Ｃｏｎｓｅｎｔ)が入力されるためにユーザインターフェース(Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＵＩ)を構成する方法の多様な実施例を示す。

図２７は、本開示の一実施形態による端末の動作を時系列な流れによって示す図面である。

図２４Ａ、２４Ｂ、２５及び２６を参照すれば、図２７が示されたようなプロファイル遠隔管理１(２７１０)、プロファイル要約情報１(２７３０)、プロファイル遠隔管理２(２７５０)、プロファイル要約情報２(２７７０)のデータを受信した場合を仮定し、端末２３０にはプロファイル０が設置されて活性化され、プロファイル遠隔管理１(２７１０)は‘プロファイル０更新２７１１’、‘プロファイル０非活性化(２７１３)’ 遠隔コマンドが含まれ、プロファイル要約情報１(２７３０)は‘プロファイル１設置(２７３１)’のためのデータが含まれ、プロファイル遠隔管理２(２７５０)は‘プロファイル１アップデート(２７５１)’、‘プロファイル１活性化(２７５３)’‘プロファイル０削除(２７５５)’ 遠隔コマンドが含まれ、プロファイル要約情報２(２７７０)は‘プロファイル２設置(２７７１)’のためのデータを含んでいる場合を仮定する。

図２４Ａ、図２４Ｂを参照すれば、端末２３０が図２７のようなデータを受信する場合、端末２３０はユーザに図２４Ａの図面符号２４０１又は図２４Ｂの図面符号２４０３のような形態のユーザインターフェースを出力することができる。２４０１又は２４０３メッセージで端末２３０は図２７のデータが含むすべての手続きを順次に出力してユーザの同意を求めることができる。各手続きが出力される順序は、端末２３０が各手続きを受信した手順によるか、端末２３０が各手続きを処理する手順によることができる。各手続きに対する同意は２４０１のように個別的なユーザのチェックを要求することもでき、２４０３のように全体を統合するユーザの同意を要求することもできる。さらに、図２４Ａ、図２４Ｂに別で図示しないが、端末２３０は各手続きの対象となるプロファイルに対してサービス提供者の名前やロゴ、サービス料金などを追加的に表記したり、ユーザ乃至サービス提供者が設定した別途のパスワード又は個人識別番号(Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ、ＰＩＮ)などが入力されるユーザインターフェースを追加に出力することができる。

図２５を参照すれば、端末２３０が図２７のようなデータを受信する場合、端末２３０はユーザに ２５０１のような形態のユーザインターフェースを出力することができる。２５０１メッセージで端末２３０は図２７のデータが含む手続きを各手続きの対象となるプロファイル別で分類して出力してユーザの同意を求めることができる。さらに、図２５に別に図示しないが、前記図２４Ａ、図２４Ｂの２４０１メッセージと同様に端末２３０は各プロファイル別で分類された手続きのセットに対して個別的なユーザの同意を要求することもできる。さらに、図２５に別に図示しないが、端末２３０は各手続きの対象となるプロファイルに対してサービス提供者の名前やロゴ、サービス料金などを追加的に表記したり、ユーザ乃至サービス提供者が設定した別途のパスワード又は個人識別番号(ＰＩＮ)などが入力されるユーザインターフェースを追加に出力することができる。

図２６を参照すれば、端末２３０図２７のようなデータを受信する場合、端末２３０はユーザに２６０１のような形態のユーザインターフェースを出力することができる。２６０１メッセージで端末２３０は図２７のデータが含む手続きを各手続きの種類別で分類して出力してユーザの同意を求めることができる。さらに、図２６に別に図示しないが、前記図２４Ａ、図２４Ｂの２４０１メッセージと同様に端末２３０は各種類別で分類された手続きのセットに対して個別的なユーザの同意を要求することもできる。さらに、図２６に別で図示しないが、端末２３０は各手続きの対象となるプロファイルに対してサービス提供者の名前やロゴ、サービス料金などを追加的に表記したり、ユーザ乃至サービス提供者が設定した別途のパスワード又は個人識別番号(ＰＩＮ)などが入力されるユーザインターフェースを追加に出力することができる。

図２４Ａ、２４Ｂ、２５及び２６に該当するユーザインターフェースは上述した図１６乃至図１７が適用されるすべての実施形態適用されることができることを留意すべきである。したがって、図２４Ａ、２４Ｂ、２５及び２６に該当するユーザインターフェースが前記図２２乃至図２３の多様な実施形態のうちの２２０３又は２３０３段階でユーザ同意を受ける手続きにも同様に適用されることができることは勿論である。

一方、図２８は本発明の一実施形態による端末２８００を示す図面である。

図２８を参照すれば、端末２８００は送受信部２８１０及びプロセッサ２８２０を含むことができる。さらに、端末２８００はＵＩＣＣ２８３０を含むことができる。ＵＩＣＣ２８３０は端末２８００に挿入されることができ、端末２８００に内装されたｅＵＩＣＣであれば良い。

送受信部２８１０は信号、情報、データなどを送信及び受信することができる。

一方、プロセッサ２８２０は端末２８００の全般的な動作を制御することができる。プロセッサ２８２０は前述したような本発明の実施形態によって、端末２８００の全般的な動作を制御することができる。

さらに、ＵＩＣＣ２８３０はプロファイルをダウンロードし、プロファイルを設置することができる。だけでなく、ＵＩＣＣ２８３０はプロファイルを管理することができる。ＵＩＣＣ２８３０はプロセッサ２８２０の制御によって動作することもできる。又はＵＩＣＣ２８３０はプロファイルを設置するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置されてあり得る。

図２９は、本発明の一実施形態によるサーバー２９００の構成要素を示す図面である。例えば、前記サーバー２９００はプロファイルサーバーであれば良い。

サーバー２９００は送受信部２９１０及びプロセッサ２９２０を含むことができる。

送受信部２９１０は信号、情報、データなどを送信及び受信することができる。例えば、前記送受信部２９１０は端末でプロファイルを送信することができる。

一方、プロセッサ２９２０はサーバー２９００を全般的に制御するための構成要素である。プロセッサ２９２０は前述したような本発明の実施形態によって、サーバー２９００の全般的な動作を制御することができる。

上述した本発明の具体的な実施形態で、発明に含まれる構成要素は提示された具体的な実施形態によって単数又は複数で表現された。しかし、単数又は複数の表現は説明の便宜のために提示した状況に適合に選択されたもので、本発明が単数又は複数の構成要素に制限されるのではなく、複数で表現された構成要素と言っても単数から構成されたり、単数で表現された構成要素と言っても複数から構成されることができる。

本開示がその多様な実施形態を参照して図示されて説明されたが、本技術分野の当業者は本発明の思想及び範囲を逸脱せず添付された請求範囲及びその均等なものによって定義された本開示の形態及び詳細事項の多様な変化が成ることができることを理解するだろう。

１１０ 端末
１２０ ＵＩＣＣ
１３０ 移動通信サービス提供者ネットワーク

Claims (15)

1. 無線通信システムにおいて端末がプロファイル関連情報を受信する方法であって、
   サーバーで、端末に対するイベントを要請して前記イベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)関連メッセージを送信する段階と、
   前記サーバーから前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを受信する段階と、及び
   前記データに基づいて動作を行う段階と、を含む、方法。
2. 前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報は第１プロファイルのダウンロード及び第２プロファイルに対するＲＰＭ(ｒｅｍｏｔｅ ｐｒｏｆｉｌｅ ｍａｎａｇｅｍｅｎｔ)のうちの少なくとも一つを指示することである、請求項１に記載の方法。
3. 前記データは第１プロファイルに対するメタデータ及び第２プロファイルに対する少なくても一つのＲＰＭコマンドを含むＲＰＭパッケージのうちの少なくとも一つを含むことである、請求項１に記載の方法。
4. 前記ＵＩＣＣ関連メッセージは認証クライアント要請メッセージで、前記端末のＵＩＣＣのシグネチャーを含み、
   前記応答メッセージは前記データに対する前記サーバーのシグネチャーをさらに含むことである、請求項１に記載の方法。
5. 無線通信システムにおいてプロファイル関連情報を受信する端末であって、
   送受信部と、及び
   前記送受信部と結合され、
   サーバーで、端末に対するイベントを要請して前記イベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)関連メッセージを送信し、
   前記サーバーから前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを受信し、
   前記データに基づいて動作を行うように設定された制御部と、を含む、端末。
6. 前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報は第１プロファイルのダウンロード及び第２プロファイルに対するＲＰＭ(ｒｅｍｏｔｅ ｐｒｏｆｉｌｅ ｍａｎａｇｅｍｅｎｔ)のうちの少なくとも一つを指示することである、請求項５に記載の端末。
7. 前記データは第１プロファイルに対するメタデータ及び第２プロファイルに対する少なくても一つのＲＰＭコマンドを含むＲＰＭパッケージのうちの少なくとも一つを含むことである、請求項５に記載の端末。
8. 前記ＵＩＣＣ関連メッセージは認証クライアント要請メッセージで、前記端末のＵＩＣＣのシグネチャーを含み、
   前記応答メッセージは前記データに対する前記サーバーのシグネチャーをさらに含むことである、請求項５に記載の端末。
9. 無線通信システムにおいてサーバーがプロファイル関連情報を送信する方法であって、
   端末から、前記端末に対するイベントを要請して前記イベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)関連メッセージを受信する段階と、及び
   前記端末で、前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを送信する段階と、を含む、方法。
10. 前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報は第１プロファイルのダウンロード及び第２プロファイルに対するＲＰＭ(ｒｅｍｏｔｅ ｐｒｏｆｉｌｅ ｍａｎａｇｅｍｅｎｔ)のうちの少なくとも一つを指示し、
    前記データは第１プロファイルに対するメタデータ及び第２プロファイルに対する少なくても一つのＲＰＭコマンドを含むＲＰＭパッケージのうちの少なくとも一つを含むことである、請求項９に記載の方法。
11. 前記ＵＩＣＣ関連メッセージは認証クライアント要請メッセージで、前記端末のＵＩＣＣのシグネチャーを含み、
    前記応答メッセージは前記データに対する前記サーバーのシグネチャーをさらに含むことである、請求項９に記載の方法。
12. 無線通信システムにおいてプロファイル関連情報を送信するサーバーであって、
    送受信部と、及び
    前記送受信部と結合され、
    端末から、前記端末に対するイベントを要請して前記イベントのｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報を含むＵＩＣＣ(ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ)関連メッセージを受信し、
    前記端末で、前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対応するデータを含む応答メッセージを送信するように設定された制御部と、を含む、サーバー。
13. 前記ｏｐｅｒａｔｉｏｎ ｔｙｐｅに対する情報は第１プロファイルのダウンロード及び第２プロファイルに対するＲＰＭ(ｒｅｍｏｔｅ ｐｒｏｆｉｌｅ ｍａｎａｇｅｍｅｎｔ)のうちの少なくとも一つを指示することである、請求項１２に記載のサーバー。
14. 前記データは第１プロファイルに対するメタデータ及び第２プロファイルに対する少なくても一つのＲＰＭコマンドを含むＲＰＭパッケージのうちの少なくとも一つを含むことである、請求項１２に記載のサーバー。
15. 前記ＵＩＣＣ関連メッセージは認証クライアント要請メッセージで、前記端末のＵＩＣＣのシグネチャーを含み、
    前記応答メッセージは前記データに対する前記サーバーのシグネチャーをさらに含むことである、請求項１６に記載のサーバー。