IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ サムスン エレクトロニクス カンパニー リミテッドの特許一覧

特表2022-549182機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-11-24
(54)【発明の名称】機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置
(51)【国際特許分類】
   H04W 12/069 20210101AFI20221116BHJP
   H04W 12/42 20210101ALI20221116BHJP
   H04W 4/50 20180101ALI20221116BHJP
   H04W 8/24 20090101ALI20221116BHJP
   H04M 1/724 20210101ALI20221116BHJP
【FI】
H04W12/069
H04W12/42
H04W4/50
H04W8/24
H04M1/724
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022517517
(86)(22)【出願日】2020-09-21
(85)【翻訳文提出日】2022-03-17
(86)【国際出願番号】 KR2020012728
(87)【国際公開番号】W WO2021054808
(87)【国際公開日】2021-03-25
(31)【優先権主張番号】10-2019-0116222
(32)【優先日】2019-09-20
(33)【優先権主張国・地域又は機関】KR
(31)【優先権主張番号】10-2019-0140219
(32)【優先日】2019-11-05
(33)【優先権主張国・地域又は機関】KR
(31)【優先権主張番号】10-2019-0150329
(32)【優先日】2019-11-21
(33)【優先権主張国・地域又は機関】KR
(31)【優先権主張番号】10-2019-0150466
(32)【優先日】2019-11-21
(33)【優先権主張国・地域又は機関】KR
(31)【優先権主張番号】10-2020-0120292
(32)【優先日】2020-09-18
(33)【優先権主張国・地域又は機関】KR
(81)【指定国・地域】
(71)【出願人】
【識別番号】503447036
【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド
(74)【代理人】
【識別番号】110000051
【氏名又は名称】弁理士法人共生国際特許事務所
(72)【発明者】
【氏名】リム, テヒョン
(72)【発明者】
【氏名】ク, ジョンホェ
(72)【発明者】
【氏名】ユン, カンジン
(72)【発明者】
【氏名】イ, ドクキ
(72)【発明者】
【氏名】イ, ヘウォン
【テーマコード(参考)】
5K067
5K127
【Fターム(参考)】
5K067AA34
5K067DD17
5K067EE02
5K067EE16
5K067HH23
5K127BA03
5K127BB06
5K127CB02
5K127CB24
5K127DA11
5K127NA14
(57)【要約】
スマートセキュリティ媒体の間のバンドル移動が行われた後のバンドルの状態を設定する方法及び装置を提供する。本発明は、4Gシステム以後より高いデータ送信率をサポートするための5G通信システムをIoT技術とコンバージェンスする通信技法及びそのシステムに関する。本発明は5G通信技術及びIoT関連技術を基盤で知能型サービス(例えば、スマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、ヘルスケア、デジタル教育、小売り業、セキュリティ及び安全関連サービスなど)に適用され得る。本発明は、スマートセキュリティ媒体の間のバンドルが送信された後のバンドルの状態を設定する方法及び装置を記載する。
【選択図】 図17
【特許請求の範囲】
【請求項1】
第1端末の動作方法であって、
第2端末で、バンドルを送信する段階と、
前記第2端末から、第2端末のバンドル状態情報を含んで生成される第1証明書を受信する段階と、
前記受信した第1証明書を検証する段階と、
前記第1証明書を検証した後、第1端末のバンドル状態情報を含む第2証明書を生成する段階と、
前記第2端末で前記第2証明書を送信する段階と、を有することを特徴とする第1端末の動作方法。
【請求項2】
前記第1端末のバンドル状態情報は、前記第1端末のバンドル状態が「DELETE」、「IN TRANSITION」、「SUSPENSION」の内の少なくとも一つに設定されることを含み、
前記第1端末のバンドル状態が「IN TRANSITION」に設定された場合、前記第2端末から第2端末のバンドル状態変更に対する情報を含んで生成された第3証明書を受信する段階と、
前記受信した第3証明書を検証する段階と、
前記第3証明書を検証した後、前記第1端末のバンドルを削除(DELETE)する段階と、をさらに有することを特徴とする請求項1に記載の第1端末の動作方法。
【請求項3】
前記第2端末によって、前記第1証明書及び前記第2証明書の検証結果に対する情報を含む第4証明書が生成され、
前記第4証明書がサーバーに送信され、
前記サーバーによって、前記第4証明書は検証されることを特徴とする請求項1に記載の第1端末の動作方法。
【請求項4】
サーバーによって、前記サーバーとの認証結果を含む第5証明書が生成され、
前記第5証明書は、前記第2端末に送信され、
前記第2端末によって、前記第5証明書は検証されることを特徴とする請求項1に記載の第1端末の動作方法。
【請求項5】
第2端末の動作方法であって、
第1端末から、バンドルを受信する段階と、
前記バンドルを設置する段階と、
第2端末のバンドル状態情報を含む第1証明書を生成する段階と、
前記第1端末に、前記第1証明書を送信する段階と、
前記第1端末から、第1端末のバンドル状態情報を含んで生成される第2証明書を受信する段階と、
前記受信した第2証明書を検証する段階と、
前記第2証明書を検証した後、第2端末のバンドル状態設定情報を変更する段階と、を有することを特徴とする第2端末の動作方法。
【請求項6】
前記第2端末のバンドル状態設定情報を変更する段階は、前記第2端末のバンドル状態を活性化(enable)、駆動状態(Active)及び非活性化(Disabled)の内の少なくとも一つに変更する段階と、
前記第1端末のバンドル状態情報は、前記第1端末のバンドル状態が「DELETE」、「IN TRANSITION」、「SUSPENSION」の内の少なくとも一つに設定され、前記第1端末のバンドル状態が「IN TRANSITION」に設定された場合、第2端末のバンドル状態変更に対する情報を含む第3証明書を生成する段階と、
前記第1端末で、前記第3証明書を送信する段階と、をさらに有することを特徴とする請求項5に記載の第2端末の動作方法。
【請求項7】
前記第1証明書及び前記第2証明書の検証結果に対する情報を含む第4証明書を生成する段階と、
サーバーに、前記第4証明書を送信する段階をさらに有することを特徴とする請求項5に記載の第2端末の動作方法。
【請求項8】
サーバーから、前記サーバーとの認証結果を含んで生成された第5証明書を受信する段階と、
前記受信した第5証明書を検証する段階と、
前記第5証明書を検証した後、第2端末のバンドル状態設定情報を変更する段階と、をさらに有することを特徴とする請求項5に記載の第2端末の動作方法。
【請求項9】
第1端末であって、
少なくとも一つの信号を送受信ができる送受信部と、
前記送受信部と結合された制御部と、を有し、
前記制御部は、第2端末で、バンドルを送信し、前記第2端末から、第2端末のバンドル状態情報を含んで生成される第1証明書を受信し、前記受信した第1証明書を検証し、前記第1証明書を検証した後、第1端末のバンドル状態情報を含む第2証明書を生成し、前記第2端末で前記第2証明書を送信するように構成されることを特徴とする第1端末。
【請求項10】
前記制御部は、前記第1端末のバンドル状態が「IN TRANSITION」に設定された場合、前記第2端末から第2端末のバンドル状態変更に対する情報を含んで生成される第3証明書を受信し、
前記受信した第3証明書を検証し、
前記第3証明書を検証した後、前記第1端末のバンドルを削除(DELETE)するようにさらに構成され、
前記第1端末のバンドル状態情報は、前記第1端末のバンドル状態が「DELETE」、「IN TRANSITION」、「SUSPENSION」の内の少なくとも一つに設定されることを含むことを特徴とする請求項9に記載の第1端末。
【請求項11】
前記第2端末によって、前記第1証明書及び前記第2証明書の検証結果に対する情報を含む第4証明書が生成され、
前記第4証明書がサーバーに送信され、
前記サーバーによって、前記第4証明書は検証されることを特徴とする請求項9に記載の第1端末。
【請求項12】
サーバーによって、前記サーバーとの認証結果を含む第5証明書が生成され、
前記第5証明書は、前記第2端末に送信され、
前記第2端末によって、前記第5証明書は、検証されることを特徴とする請求項9に記載の第1端末。
【請求項13】
第2端末であって、
少なくとも一つの信号を送受信ができる送受信部と、
前記送受信部と結合された制御部と、を有し、
前記制御部は、第1端末から、バンドルを受信し、前記バンドルを設置し、第2端末のバンドル状態情報を含む第1証明書を生成し、前記第1端末に、前記第1証明書を送信し、前記第1端末から、第1端末のバンドル状態情報を含んで生成される第2証明書を受信し、前記受信された第2証明書を検証し、前記第2証明書を検証した後、第2端末のバンドル状態設定情報を変更するように構成されることを特徴とする第2端末。
【請求項14】
前記制御部は、前記第2端末のバンドル状態を活性化(enable)、駆動状態(Active)及び非活性化(Disabled)の内の少なくとも一つに変更するように構成され、
前記第1端末のバンドル状態が「IN TRANSITION」に設定された場合、第2端末のバンドル状態変更に対する情報を含む第3証明書を生成し、前記第1端末で前記第3証明書を送信するようにさらに構成され、
前記第1端末のバンドル状態情報は、前記第1端末のバンドル状態が「DELETE」、「IN TRANSITION」、「SUSPENSION」の内の少なくとも一つに設定されることを特徴とする請求項13に記載の第2端末。
【請求項15】
前記制御部は、前記第1証明書及び前記第2証明書の検証結果に対する情報を含む第4証明書を生成し、サーバーで、前記第4証明書を送信するようにさらに構成されることを特徴とする請求項13に記載の第2端末。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、スマートセキュリティ媒体に関し、より詳しくは、スマートセキュリティ媒体の間のバンドル移動が行われた後のバンドルの状態を設定する方法及び装置に関する。
また、本発明は、スマートセキュリティ媒体に関し、より詳しくは、スマートセキュリティ媒体の間のバンドル移動が行われた後のバンドル移動結果をサーバーに登録する方法及び装置に関する。
【背景技術】
【0002】
4G通信システム商用化以後に増加趨勢にある無線データトラフィック需要を満たすため、改善した5G通信システム又はpre-5G通信システムを開発するための努力が行われている。
このような理由で、5G通信システム又はpre-5G通信システムは、4Gネットワーク以後(Beyond 4G Network)通信システム又はLTEシステム以後(Post LTE)のシステムと呼ばれている。
高いデータ送信率を達成するために、5G通信システムは、超高周波数(mmWave)帯域(例えば、60ギガ60GHz)帯域のような)での具現が考慮されている。
【0003】
超高周波帯域での伝播の経路損失の緩和及び送信距離を増やすために、5G通信システムでは、ビームフォーミング(beamforming)、巨大配列多重入出力(massive MIMO)、FD-MIMO(Full Dimensional MIMO)、アレイアンテナ(array antenna)、アナログビームフォーミング(analog beam forming)、及び大規模アンテナ(largescale antenna)の技術が議論されている。
【0004】
さらに、システムのネットワーク改善のために、5G通信システムでは、進化した小型セル、改善した小型セル(advanced small cell)、クラウド無線アクセスネットワーク(cloud radio access network:cloud RAN)、超高密度ネットワーク(ultra-dense network)、D2D通信(Device to Device communication)、無線バックホール(wireless backhaul)、移動ネットワーク(moving network)、協力通信(cooperative communication)、CoMP(Coordinated Multi-Points)、及び受信干渉除去(interference cancellation)などの技術開発が行なわれている。
【0005】
その他、5Gシステムでは、進歩したコーディング変調(Advanced Coding Modulation:ACM)方式であるFQAM(Hybrid FSK and QAM Modulation)及びSWSC(Sliding Window Superposition Coding)と、進歩した接続技術であるFBMC(Filter Bank Multi Carrier)、NOMA(non orthogonal multiple access)、及びSCMA(sparse code multiple access)などが開発されている。
【0006】
一方、人間が情報を生成して消費する人間中心の接続ネットワークであるインターネットは、事物などの分散したエンティティーの間に情報を交換して処理するIoT(Internet of Things、モノのインターネット)網へ進化しつつある。
クラウドサーバーなどとの接続を通じるビックデータ(Big data)処理技術などがIoT技術に結合されたIoE(Internet of Everything)技術も台頭してきている。
IoTを具現のためにセンシング技術、有/無線通信及びネットワークインフラ、サービスインターフェース技術及びセキュリティ技術のような技術要素が要求され、最近では事物の間の接続のためのセンサーネットワーク(sensor network)、M2M(Machine to Machine)通信、MTC(Machine Type Communication)などの技術が研究されている。
【0007】
IoT環境では接続された事物で生成されるデータを収集、分析して人間の生活に新しい価値を創出する知能型IT(Internet Technology)サービスが提供され得る。
IoTは、既存のIT(Internet Technology)技術と多様な産業の間のコンバージェンス及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用することができる。
【0008】
これによって、5G通信システムをIoT網に適用するための多様な試みが行われた。
例えば、センサーネットワーク、M2M(Machine to Machine)及びMTC(Machine Type Communication )などの5G通信技術がビームフォーミング、MIMO及びアレイアンテナによって具現され得る。
また、前述したビックデータ処理技術としてクラウド無線アクセスネットワーク(cloud RAN)が適用されることも5G技術とIoT技術の間のコンバージェンスの一例として見なされる。
【発明の概要】
【発明が解決しようとする課題】
【0009】
本発明は、2つの電子装置に含まれたセキュリティモジュールの間にバンドルを移動する場合、バンドル送信が行なった後のバンドルの状態を設定する装置及び方法を提供することにある。
また、2つの電子装置に含まれたセキュリティモジュールの間にバンドルを移動する場合、バンドル送信が行なった後のバンドルの送信結果をサーバーに登録する装置及び方法を提供することにある。
【課題を解決するための手段】
【0010】
本発明の一態様による第1端末の動作方法は、第1端末の動作方法であって、第2端末で、バンドルを送信する段階と、前記第2端末から、第2端末のバンドル状態情報を含んで生成される第1証明書を受信する段階と、前記受信した第1証明書を検証する段階と、前記第1証明書を検証した後、第1端末のバンドル状態情報を含む第2証明書を生成する段階と、前記第2端末で前記第2証明書を送信する段階と、を有することを特徴とする。
【0011】
一部の例では、前記第1端末のバンドル状態情報は、前記第1端末のバンドル状態が「DELETE」、「IN TRANSITION」、「SUSPENSION」の内の少なくとも一つで設定されることを含むことを特徴とする。
【0012】
一部の例では、前記第1端末のバンドル状態が「IN TRANSITION」に設定された場合、前記第2端末から第2端末のバンドル状態変更に対する情報を含んで生成された第3証明書を受信する段階と、前記受信した第3証明書を検証する段階と、前記第3証明書を検証した後、前記第1端末のバンドルを削除(DELETE)する段階と、をさらに有することを特徴とする。
【0013】
一部の例では、前記第2端末によって、前記第1証明書及び前記第2証明書の検証結果に対する情報を含む第4証明書が生成され、前記第4証明書がサーバーに送信され、前記サーバーによって、前記第4証明書は検証されることを特徴とする。
【0014】
一部の例では、サーバーによって、前記サーバーとの認証結果を含む第5証明書が生成され、前記第5証明書は前記第2端末に送信され、前記第2端末によって、前記第5証明書は検証されることを特徴とする。
【0015】
本発明の一態様による第2端末の動作方法は、第2端末の動作方法であって、第1端末から、バンドルを受信する段階と、前記バンドルを設置する段階と、第2端末のバンドル状態情報を含む第1証明書を生成する段階と、前記第1端末に、前記第1証明書を送信する段階と、前記第1端末から、第1端末のバンドル状態情報を含んで生成される第2証明書を受信する段階と、前記受信した第2証明書を検証する段階と、前記第2証明書を検証した後、第2端末のバンドル状態設定情報を変更する段階と、を有することを特徴とする。
【0016】
本発明の一態様による第1端末は、第1端末であって、少なくとも一つの信号を送受信ができる送受信部と、前記送受信部と結合された制御部と、を有し、前記制御部は、第2端末で、バンドルを送信し、前記第2端末から、第2端末のバンドル状態情報を含んで生成される第1証明書を受信し、前記受信した第1証明書を検証し、前記第1証明書を検証した後、第1端末のバンドル状態情報を含む第2証明書を生成し、前記第2端末で前記第2証明書を送信するように構成されることを特徴とする。
【0017】
本発明の一態様による第2端末は、第2端末であって、少なくとも一つの信号を送受信ができる送受信部と、前記送受信部と結合された制御部と、を有し、前記制御部は、第1端末から、バンドルを受信し、前記バンドルを設置し、第2端末のバンドル状態情報を含む第1証明書を生成し、前記第1端末に、前記第1証明書を送信し、前記第1端末から、第1端末のバンドル状態情報を含んで生成される第2証明書を受信し、前記受信された第2証明書を検証し、前記第2証明書を検証した後、第2端末のバンドル状態設定情報を変更するように構成されることを特徴とする。
【発明の効果】
【0018】
本発明に係る第1、第2端末及びその動作方法によれば、一つの機器に設置されたバンドルは安全でかつ効率的な方法で他の機器へ送信及び設置されることができ、送信及び設置が済んだ後のバンドルの状態を設定することができる。
また、一つの機器に設置されたバンドルは安全でかつ効率的な方法で他の機器へ送信及び設置されることができ、送信及び設置が済んだ後のバンドルの送信結果をサーバーに登録することができる。
【図面の簡単な説明】
【0019】
図1】本発明の実施形態によるSSPの概念を示す図である。
図2】本発明の実施形態によるSSPの内部構造の概念を示す図である。
図3】本発明の実施形態による端末がSSPでバンドルをダウンロードして設置するために用いられる端末内の構成要素の例を示す図である。
図4】本発明の実施形態による2つの端末の間でバンドルの送信が行うために2つの端末が相互動作する方法の例を示す図である。
図5】本発明の一実施形態による「証明書(Attestaion)」の構成を示す図である。
図6】本発明の実施形態による一つの端末から他の端末にバンドルが送信される手順を概念的に示す図である。
図7図6で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。
図8図6で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図である。
図9図6で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。
図10図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図11図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図12図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図13】使用が中止されたバンドルをさらに使用可能に作る手順の例を示す図である。
図14】使用が中止されたバンドルをさらに使用可能に作るまた他の手順の例を示す図である。
図15】使用が中止されたバンドルをさらに使用可能に作るまた他の手順の例を示す図である。
図16】本発明の実施形態による端末の概略構成を示すブロック図である。
図17図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図18】本発明の一実施形態による「証明書(Attestaion)」の構成を示す図である。
図19】本発明の実施形態による一つの端末から他の端末にバンドルが送信される手順を概念的に示す図である。
図20図19で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。
図21図19で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図である。
図22図19で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。
図23図22で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
図24図19で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図25図24で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
図26図19で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図27図26で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
図28】本発明の実施形態による端末の概略構成を示すブロック図である。
図29】本発明の実施形態によるサーバーの概略構成を示すブロック図である。
図30図19で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順及びバンドルの送信結果がサーバーに登録される手順を示す図である。
【発明を実施するための形態】
【0020】
以下、本発明の実施形態を添付した図面を参照して詳細に説明する。
【0021】
実施形態を説明するにあたり、本発明が属する技術分野によく知られ、本発明と直接的に関連がない技術内容に対しては説明を省略する。
これは不必要な説明を省略することによって本発明の要旨を明瞭でかつより明確に伝達するためである。
同じ理由で添付図面において一部構成要素は、誇張したり省略するか概略的に示す。
また、各構成要素の大きさは、実際の大きさを全的に反映することではない。
各図面で同一又は対応する構成要素には同一参照番号を付与した。
【0022】
本発明の利点及び特徴、そしてそれらを達成する方法は、添付した図面と共に詳細に後述する実施形態を参照すると明確になるだろう。
しかし、本発明は、以下で開示する実施形態に限定されることではなく、互いに異なる多様な形態で具現することができ、ただ、本実施形態は本発明の開示が完全にし、本発明が属する技術分野で通常の知識を有する者に開示の範囲を完全に知らせるために提供するものであり、本発明は、請求項の範囲によって定義されるだけである。
明細書全体にかけて同一参照符号は、同一構成要素を指称する。
【0023】
このとき、処理フローチャートの各ブロックとフローチャートの図面の組み合せは、コンピュータープログラムインストラクションによって行なわれることができることを理解することができるだろう。
これらコンピュータープログラムインストラクションは、汎用コンピューター、特殊用コンピューター、又はその他のプログラム可能なデータプロセッシング装備のプロセッサに搭載されることができるため、コンピューター又はその他のプログラム可能なデータプロセッシング装備のプロセッサを介して行なわれるそのインストラクションが、フローチャートブロックで説明した機能を行う手段を生成する。
これらコンピュータープログラムインストラクションは、特定方式で機能を具現するためにコンピューター又はその他のプログラム可能なデータプロセッシング装備を志向することができるコンピューター利用可能、又はコンピューター可読メモリに記憶することも可能であるため、そのコンピューター利用可能又はコンピューター可読メモリに記憶されたインストラクションは、フローチャートブロックで説明した機能を行うインストラクション手段を内包する製造品目を生産することも可能である。
コンピュータープログラムインストラクションは、コンピューター又はその他のプログラム可能なデータプロセッシング装備上に搭載されることも可能であるため、コンピューター又はその他のプログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピューターで実行されるプロセスを生成してコンピューター又はその他のプログラム可能なデータプロセッシング装備を行うインストラクションは、フローチャートブロックで説明した機能を行うための段階を提供することもできる。
【0024】
また、各ブロックは、特定された論理的機能を行うための1つ以上の実行可能なインストラクションを含むモジュール、セグメント又はコードの一部を示すことができる。
また、幾つか代替実行例ではブロックで言及された機能が順序を外れて発生することも可能であることを注目すべきである。
例えば、接して示している2つのブロックは、実は実質的に同時に行なわれることも可能で、又はそのブロックが時々該当する機能によって逆順で行われることもできる。
【0025】
このとき、本実施形態に用いられる「~部」という用語は、ソフトウェア又はFPGAはASICのようなハードウェア構成要素を意味し、「~部」は、いかなる役目も行う。
しかし、「~部」は、ソフトウェア又はハードウェアに限定される意味ではない。
「~部」は、アドレシングすることができる記憶媒体にあるように構成することもでき、1つ又はその以上のプロセッサを再生させるように構成することもできる。
したがって、一例として「~部」は、ソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス構成要素、及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーティン、プログラムコードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。
構成要素と「~部」のうちで提供される機能は、より小さい数の構成要素及び「~部」に結合したり、追加的な構成要素と「~部」でさらに分離することができるだけでなく、構成要素及び「~部」は、デバイス又はセキュリティマルチメディアカード内の1つ又はその以上のCPUを再生させるように具現させることもできる。
【0026】
また、本発明ではSSPをセキュリティ媒体の一例を挙げて各実施形態を説明するが、本発明の権利範囲がSSPによることで制限されない。
例えば、SSPと実質的に同一又は類似の機能を行う他のセキュリティ媒体にも、以下に説明する多様な実施形態が実質的に同一又は類似に適用することができることは当該技術分野の通常の技術者に自明である。
以下の説明で用いられる特定用語は、本発明の理解を助けるために提供したもので、このような特定用語の使用は、本発明の技術的思想を逸脱せず範囲で他の形態で変更され得る。
【0027】
「SE(Secure Element)」は、セキュリティ情報(例えば、移動通信網の接続鍵、IDカード/パスポートなどのユーザ身元確認情報、クレジットカード情報、暗号化鍵など)を記憶し、記憶されたセキュリティ情報を用いる制御モジュール(例えば、USIMなどの網接続制御モジュール、暗号化モジュール、鍵生成モジュールなど)を搭載して操作することができる単一チップで構成されたセキュリティモジュールを意味する。
SEは、多様な電子装置(例えば、スマートフォン、タブレット、ウェアラブル装置、自動車、IoT装置など)に用いることができ、セキュリティ情報と制御モジュールを介してセキュリティサービス(例えば、移動通信通信網の接続、決済、ユーザ認証など)を提供することができる。
【0028】
SEは、UICC(Universal Integrated Circuit Card)、eSE(Embedded Secure Element)、UICCとeSEが統合された形態であるSSP(Smart Secure Platform)などに分けることができ、電子装置に接続又は設置される形態によって脱着式(Removable)、固定式(Embedded)、及び特定素子又はSoC(system on chip)に統合される統合式(Integrated)に細分化することができる。
【0029】
「UICC(Universal Integrated Circuit Card)」は、移動通信端末機などに挿入して用いるスマートカード(smart card)であり、UICCカードとも指称することができる。
UICCには移動通信事業者の網に接続するための接続制御モジュールが含まれ得る。
接続制御モジュールの例としては、USIM(Universal Subscriber Identity Module)、SIM(Subscriber Identity Module)、ISIM(IP Multimedia Service Identity Module)などがある。
USIMが含まれたUICCは、通常USIMカードとも呼ばれる。
同様に、SIMモジュールが含まれたUICCは、通常的にSIMカードとも呼ばれる。
一方、SIMモジュールは、UICC製造の時に搭載されるか、ユーザが望む時点で使用しようとする移動通信サービスのSIMモジュールをUICCカードにダウンロードすることができる。
【0030】
UICCカードは、さらに複数個のSIMモジュールをダウンロードして設置し、その内の少なくとも一つのSIMモジュールを選択して用いることができる。
このようなUICCカードは、端末に固定するか又は固定しなくても良い。
端末に固定して用いるUICCを、eUICC(embedded UICC)と指し、特に端末の通信プロセッサ(Communication Processor)、アプリケーションプロセッサ(Application Processor)又はこの2つのプロセッサが統合された単一プロセッサ構造を含む「System-On-Chip」(SoC)に内蔵したUICCをiUICC(Integrated UICC)と指称することができる。
通常的にeUICCとiUICCは、端末に固定して用い、リモートでSIMモジュールをダウンロードして選択することができるUICCカードを意味する。
本発明では、リモートでSIMモジュールをダウンロードして選択することができるUICCカードを、eUICC又はiUICCと通称する。
すなわち、リモートでSIMモジュールをダウンロードして選択することができるUICCカードの内で端末に固定するか固定しないUICCカードを通称してeUICC又はiUICCとして用いる。
さらに、ダウンロードするSIMモジュール情報を通称してeUICCプロファイル又はiUICCプロファイル、又はより簡単にプロファイルという用語で用いる。
【0031】
本発明で、用語「UICC」は、SIMと混用することができ、用語「eUICC」は、eSIMと混用することができる。
また、本発明で「USIM Profile」(USIM Profile)は、プロファイルと同じ意味又はプロファイル内のUSIMアプリケーションに含まれた情報をソフトウェア形態でパッケージングしたことを意味し得る。
【0032】
「eSE(Embedded Secure Element)」は、電子装置に固定して用いる固定式SEを意味する。
eSEは、通常的に端末製造会社のリクエストによって製造会社専用に製造され、ОSとフレームワークを含んで製造することができる。
eSEは、リモートでアプレット形態のサービス制御モジュールをダウンロードし設置して、電子財布、チケッティング、電子パスポート、デジタル鍵などのような多様なセキュリティサービス用途として用いることができる。
本発明ではリモートでサービス制御モジュールをダウンロードして設置することができる電子装置に付着した単一チップ形態のSEをeSEと通称する。
【0033】
「SSP(Smart Secure Platform)」は、UICCとeSEの機能を単一チップで統合サポートが可能なもので、脱着式(Removable SSP:rSSP)、固定式(Embedded SSP:eSSP)、及びSoCに内蔵した統合式(Integrated SSP:iSSP)に区分することができる。
SSPは、一つのプライマリープラットホーム(Primary Platform:PP)とPP上で動作する少なくとも一つのセカンダリープラットホームバンドル(Secondary Platform Bundle:SPB)を含み、プライマリープラットホームは、ハードウェアプラットホームと「low level Operating System」(LLOS)の内の少なくとも一つを含み、セカンダリープラットホームバンドルは、「High-level Operating System」(HLOS)及びHLOSの上で駆動されるアプリケーションの内の少なくとも一つを含む。
セカンダリープラットホームバンドルは、SPB又はバンドルとも呼ばれる。
バンドルは、PPが提供する「Primary Platform Interface」(PPI)を介してPPの中央処理装置、メモリなどのリソースにアクセスし、これを介してPP上で駆動する。
バンドルには、SIM(Subscriber Identification Module)、USIM(Universal SIM)、ISIM(IP Multimedia SIM)などの通信アプリケーションが搭載され得、また、電子財布、チケッティング、電子パスポート、デジタル鍵などのような多様な応用アプリケーションが搭載され得る。
本発明でSSPは、スマートセキュリティ媒体と名付けることもできる。
【0034】
SSPは、ダウンロードされて設置されるバンドルにしたがって、前述したUICC又は、eSE用途で用いることができ、複数個のバンドルを単一SSPに設置して同時に操作してUICCとeSEの用途を混用することができる。
すなわち、プロファイルを含むバンドルが動作する場合、SSPは、移動通信事業者網に接続するためのUICC用途として用いることができる。
UICCバンドルは、eUICC又はiUICCのように少なくても一つ以上のプロファイルをリモートでバンドル内にダウンロードさせ、選択して動作させる。
また、SSP上で電子財布、チケッティング、電子パスポート、又はデジタル鍵などのサービスを提供することができる応用アプリケーションを搭載したサービス制御モジュールを含むバンドルが動作する場合、SSPは、eSEの用途として用いられる。
複数のサービス制御モジュールは、一つのバンドルに統合されて設置されて動作するか、それぞれの独立的なバンドルで設置されて動作することができる。
【0035】
SSPは、OTA(Over The Air)技術を用いて外部のバンドル管理サーバー(Secondary Platform Bundle Manager:SPB Manager)からバンドルをダウンロードして設置することができ、また他の端末からバンドルが送信されて設置することもできる。
本発明で、ダウンロード又は送信されたバンドルを設置する方法は、端末に挿入及び脱去が可能な着脱式SSP(rSSP)、端末に設置される固定式SSP(eSSP)、端末に設置されるSoC内部に含まれる統合式SSP(iSSP)に同様に適用することができる。
【0036】
「SSP識別子(SSP ID)」は、端末に内蔵したSSPの固有識別子としてsspIDと指称され得る。
また、本発明の実施形態のように、端末とSSPチップが分離されない場合には、端末IDであって良い。
また、SSP内の特定のバンドル識別子(SPB ID)を指称することもできる。
より詳しくは、SSPで他のバンドルを設置して活性化、非活性化、削除を管理する管理バンドル又はローダー(Secondary Platform Bundle Loader:SPBL)のバンドル識別子を指称することもできる。
また、SSP内にあるプライマリープラットホームのアイディー(Primary Platform Identifier)を指称することもできる。
SSPは、複数個のSSP識別子を持つこともでき、複数個のSSP識別子は、固有の単一のSSP識別子から誘導された値であっても良い。
【0037】
「SPB(Secondary Platform Bundle)」は、SSPのプライマリープラットホーム(Primary Plaform:PP)上でPPのリソースを用いて駆動されることで、例えば、UICCバンドルは、既存のUICC内に記憶されるアプリケーション、ファイルシステム、認証鍵値などとこれらが動作するオペレーティングシステム(HLOS)をソフトウェア形態でパッケージングしたことを意味する。
本発明で、SPBはバンドルと指称されることができる。
【0038】
本発明で端末の「状態」は次の通りである。
[活性化(enable)]
本発明で、端末又は外部サーバーがバンドルを活性化(enable)する動作は、当該SPBの状態を活性化状態(enabled)に変更して端末が、当該バンドルが提供するサービス(例えば、通信事業者を介して通信サービス、クレジットカード決済サービス、ユーザ認証サービスなど)を受けることができるように設定する動作を意味する。
活性化状態のバンドルは「活性化されたバンドル(enabled Bundle)」として表現することができる。
活性化状態のバンドルは、SSP内部又は外部の記憶空間に暗号化された状態で記憶されても良い。
【0039】
[駆動状態(Active)]
本発明で、活性化されたバンドルは、バンドル外部入力(例えば、ユーザ入力、プッシュ、端末内のアプリケーションのリクエスト、通信事業者の認証リクエスト、PP管理メッセージなど)又はバンドル内部の動作(例えば、タイマー、Polling)によって駆動状態(Active)を変更することができる。
駆動状態のバンドルは、SSP内部又は外部の記憶空間でSSP内部の駆動メモリにローディングされて、SSP内部のセキュリティ制御装置(Secure CPU)を用いてセキュリティ情報を処理して端末にセキュリティサービスを提供することを意味する。
【0040】
[非活性化(Disabled)]
本発明で、端末又は外部サーバーがバンドルを非活性化(disable)する動作は、当該バンドルの状態を非活性化状態(disabled)に変更して端末が、当該バンドルが提供するサービスを受けることができないように設定する動作を意味する。
非活性化状態のSPBは、「非活性化されたバンドル(disabled Bundle)」として表現することができる。
非活性化状態のバンドルは、SSP内部又は外部の記憶空間に暗号化された状態に記憶されても良い。
【0041】
[削除(Deleted)]
本発明で、端末又は外部サーバーがバンドルを削除(delete)する動作は、当該バンドルの状態を削除状態(deleted)に変更するか、当該バンドルを含む当該バンドルの関連データを削除して端末又は外部サーバーがこれ以上の当該バンドルを駆動、活性化又は非活性化することができないように設定する動作を意味する。
削除状態のバンドルは、「削除されたバンドル(deleted Bundle)」として表現することができる。
【0042】
「バンドルイメージ(Bundle Image、又はImage)」は、バンドルと混用されるか、特定バンドルのデータ客体(data object)を指す用語として用いることができ、バンドルTLV又はバンドルイメージTLV(Bundle Image TLV)と名付けることができる。
バンドルイメージが暗号化パラメーターを用いて暗号化された場合、保護されたバンドルイメージ(Protected Bundle Image(PBI))又は保護されたバンドルイメージTLV(PBI TLV)と名付けることができる。
バンドルイメージが特定SSPによってだけ復号化化可能な暗号化パラメーターを用いて暗号化された場合、バウンドされたバンドルイメージ(Bound Bundle Image(BBI))又はバウンドされたバンドルイメージTLV(BBI TLV)と名付けることができる。
バンドルイメージTLVは、TLV(Tag、Length、Value)形式でバンドルを構成する情報を表すデータセット(set)であっても良い。
【0043】
「バンドル区分者」は、バンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)、バンドルMatching ID、イベント識別子(Event ID)とマッチングされる因子として指称され得る。
バンドル識別子(SPB ID)は、各バンドルの固有識別子を指すことができる。
バンドルファミリ識別子は、バンドル(例えば、移動通信会社網への接続のためのテレコムバンドル)の種類を区分する識別子を指すことができる。
本発明で、バンドルファミリ識別子は、「Famaily ID」、Fid、又はFIDとして指称され得る。
バンドルファミリ管理者識別子は、バンドルファミリ識別子を管理する主体(例えば、通信事業者、端末製造会社、特定団体など)を区分する識別子を指すことができる。
本発明で、バンドルファミリ管理者識別子は、OID又はOidで指称され得る。
バンドル区分者は、バンドル管理サーバー又は端末で、バンドルをインデックスすることができる値で用いることができる。
【0044】
「バンドルメタデータ」は、バンドルを指称又は記述することができる情報のセットを示す用語である。
バンドルメタデータは、上記に記述したバンドル区分者を含むことができる。
また、バンドルメタデータは、バンドルの属性や特性、若しくは設定に対する情報をさらに含むことができる。
バンドルメタデータは、「メタデータ」と表現することができる。
【0045】
「バンドル管理サーバー」は、サービス提供者(Service Provider)又は他のバンドル管理サーバーのリクエストによってバンドルを生成するか、生成されたバンドルを暗号化するか、バンドルリモート管理コマンドを生成するか、生成されたバンドルリモート管理コマンドを暗号化する機能を含む。
上記機能を提供するバンドル管理サーバーは、SPBM(Secondary Platform Bundle Manager)、RBM(Remote Bundle Manager)、IDS(Image Delivery Server)、「SM-DP」(Subscription Manager Data Preparation)、「SM-DP+」(Subscription Manager Data Preparation plus)、管理者バンドルサーバー、「Managing SM-DP+」(Managing Subscription Manager Data Preparation plus)、バンドル暗号化サーバー、バンドル生成サーバー、バンドル提供者(Bundle Provisioner:BP)、バンドル供給者(Bundle Provider)、BPC holder(Bundle Provisioning Credentials holder)の内の少なくとも一つで表される。
【0046】
本発明で、バンドル管理サーバーは、SSPでバンドルをダウンロード、設置又はアップデートしてバンドルの状態をリモート管理するための鍵及び認証書の設定を管理する役目を行う。
上記機能を提供するバンドル管理サーバーは、SPBM(Secondary Platform Bundle Manager)、RBM(Remote Bundle Manager)、IDS(Image Delivery Server)、「SM-SR」(Subscription Manager Secure Routing)、「SM-SR+」(Subscription Manager Secure Routing Plus)、「off-card entity of eUICC Profile Manager」又は「PMC holder」(Profile Management Credentials holder)、EM(eUICC Manager)の内の少なくとも一つで表される。
【0047】
本発明で、開通仲介サーバーは、一つ以上のバンドル管理サーバー、ないし開通仲介サーバーからイベント登録リクエスト(Register Event Request、Event Register Request)を受信する。
また、一つ以上の開通仲介サーバーを複合的に用いることができ、この場合、第1開通仲介サーバーは、バンドル管理サーバーだけではなく第2開通仲介サーバーからイベント登録リクエストを受信することもできる。
本発明で、開通仲介サーバーの機能は、バンドル管理サーバーに統合することもできる。
上記機能を提供する開通仲介サーバーは、SPBM(Secondary Platform Bundle Manager)、RBM(Remote Bundle Manager)、SPBDS(Secondary Platform Bundle Discovery Sever)、BDS(Bundle Discovery Sever)、「SM-DS」(Subscription Manager Discovery Service)、DS(Discovery Service)、ルート開通仲介サーバー(Root SM-DS)、代替開通仲介サーバー(Alternative SM-DS)の内の少なくとも一つで表される。
【0048】
本発明で、バンドル管理サーバーは、バンドル又はバンドルリモート管理コマンドを生成して暗号化して伝達する機能とSSPの設定及び設置されたバンドルを管理する機能を合わせたものとして通称しても良い。
また、開通仲介サーバー機能を合わせたものとして通称しても良い。
したがって、以下の本発明の多様な実施形態でバンドル管理サーバー及び開通仲介サーバーの動作は、一つのバンドル管理サーバーで行うこともできる。
また、各機能は、互いに分離した複数のバンドル管理サーバーで分けて行うこともできる。
また、本明細書でバンドル管理サーバー又は開通仲介サーバーは、バンドルサーバーとして表され得る。
バンドルサーバーは、バンドル管理サーバー、開通仲介サーバーの内の一つであっても良く、バンドル管理サーバーと開通仲介サーバーの両方を含む装置であっても良い。
【0049】
「サービス提供者(Service Provider)」は、バンドル管理サーバーに要求事項を発行してバンドル生成をリクエストし、当該バンドルを介して端末にサービスを提供する事業体を指す。
例えば、通信アプリケーションが搭載されたバンドルを介して通信網接続サービスを提供する通信事業者(Mobile Operator)を指すことができ、通信事業者の事業サポートシステム(Business Supporting System:BSS)、オペレーショナルサポートシステム(Operational Supporting System、OSS)、POS端末(Point of Sale Terminal)、そして、その他のITシステムをいずれも通称することができる。
【0050】
また、本発明で、サービス提供者は、特定事業体を一つだけ表すとは限定されず、一つ以上の事業体のグループ又は連合体(association又はconsortium)ないし、当該グループ又は連合体を代表する代表者(representative)を指称する用語として用いることもできる。
また、本発明で、サービス提供者は、事業者(Operator又はOP又はOp.)、バンドル所有者(Bundle Owner:BO)、イメージ所有者(Image Owner:IO)などとして名付けることもでき、各サービス提供者は、名前、及び/又は固有識別子(Object Identifier:OID)を少なくとも一つ以上設定するか割り当てることができる。
もし、サービス提供者が一つ以上の事業体のグループ又は連合体又は代表者を指称する場合、任意のグループ又は連合体又は代表者の名前又は固有識別子は、当該グループ又は連合体に所属したすべての事業体ないし当該代表者と協力するすべての事業体が共有する名前又は固有識別子であっても良い。
【0051】
「加入者(Subscriber)」は、端末に対する所有権を有するサービス供給者(Service Provider)を指称するか、端末に対する所有権を有しているユーザ(End User)を指称する用語として用いられる。
一般的に、前者はM2M端末(M2M Device)で、後者はユーザ端末(Consumer Device)として名付けることができる。
M2M端末の場合、端末に対する所有権を有しないがサービス供給者(Service Provider)から端末を譲渡又は賃貸を受けて用いるユーザ(End User)が存在することができ、この場合、ユーザはサービス供給者と異なるか、または同一の場合もある。
【0052】
「加入者意図(Subscriber intent)」は、加入者がバンドルをローカル管理又はリモート管理しようとする意図を通称する用語として用いられる。
また、ローカル管理の場合、加入者意図は、ユーザ意図(End User intent)を指称し、リモート管理の場合、加入者意図は、サービス供給者意図(Service Provider intent)を指称する用語として用いることもできる。
【0053】
「ユーザ同意(End User consent)」は、ユーザがローカル管理ないしリモート管理の実行に同意するかを指称する用語で用いられる。
【0054】
「端末」は、移動局(MS)、ユーザ装備(User Equipment:UE)、ユーザターミナル(User Terminal:UT)、無線ターミナル、アクセスターミナル(AT)、ターミナル、加入者ユニット(Subscriber Unit)、加入者ステーーション(Subscriber Station:SS)、無線機器(wireless device)、無線通信デバイス、無線送受信ユニット(Wireless Transmit/Receive Unit:WTRU)、移動ノード、モバイル、又は他の用語として指称され得る。
端末の多様な実施形態は、セルラー電話機、無線通信機能を持つスマートフォン、無線通信機能を持つ個人携帯用端末機(PDA)、無線モデム、無線通信機能を持つ携帯用コンピュータ、無線通信機能を持つデジタルカメラのような撮影装置、無線通信機能を持つゲーミング装置、無線通信機能を持つ音楽記憶及び再生家電製品、無線インターネット接続及びブラウジングが可能なインターネット家電製品だけではなく、そういう機能の組み合せを統合している携帯型ユニット又は端末機を含むことができる。
また、端末は、M2M(Machine to Machine)端末、MTC(Machine Type Communication)端末/デバイスを含み得るが、ここに限定されることではない。
本発明で、端末は、電子装置と指称することもできる。
【0055】
本発明で、電子装置にはバンドルをダウンロードして設置可能なSSPが内蔵され得る。
SSPが電子装置に内蔵されない場合、物理的に電子装置と分離されたSSPは、電子装置に挿入されて電子装置と接続され得る。
例えば、SSPは、カード形態で電子装置に挿入することができる。
電子装置は、端末を含むことができ、この時、端末は、バンドルをダウンロードして設置可能なSSPを含む端末であっても良い。
端末にSSPは内蔵することだけではなく、端末とSSPが分離された場合、SSPは端末に挿入することができ、端末に挿入されて端末と接続することができる。
【0056】
「Local Bundle Assistant(LBA)」は、SSPを制御するように端末又は電子装置内に設置されたソフトウェア又はアプリケーションを指称する。
このソフトウェア又はアプリケーションは、「Local Bundle Manager」(LBM)と指称することができる。
【0057】
「ローダー(Secondary Platform Bundle Loader:SPBL)」は、SSPで他のバンドルを設置して活性化、非活性化、削除を管理する管理バンドルを指称する。
端末のLBA又はリモートのサーバーは、ローダーを介して特定バンドルを設置、活性化、非活性化、削除することができる。
本発明で、ローダーの動作は、ローダーを含むSSPの動作としても記述することができる。
【0058】
「イベント(Event)」は、バンドルダウンロード(Bundle Download)、又はリモートバンドル管理(Remote Bundle Management)、又はその他のバンドルやSSPの管理/処理コマンドを通称する用語であり得る。
イベント(Event)は、リモートBundle提供動作(Remote Bundle Provisioning Operation、又はRBP動作、又はRBP Operation)又はイベント記録(Event Record)として名付けることができ、各イベント(Event)は、それに対応するイベント識別子(Event Identifier、Event ID、EventID)又はマッチング識別子(Matching Identifier、Matching ID、MatchingID)と、当該イベントが記憶されたバンドル管理サーバー又は開通仲介サーバーの住所(FQDN、IP Address、又はURL)又は各サーバー識別子を少なくとも一つ以上含むデータとして指称され得る。
バンドルダウンロード(Bundle Download)は、バンドル設置(Bundle Installation)と混用することができる。
また、イベント種類(Event Type)は、特定イベントがバンドルダウンロード、リモートバンドル管理(例えば、削除、活性化、非活性化、交替、アップデートなど)、又はその他のバンドルやSSP管理/処理命令であるかを示す用語として用いることができ、動作種類(Operation Type又はOperationType)、動作分類(Operation Class又はOperationClass)、イベントリクエスト種類(Event Request Type)、イベント分類(Event Class)、イベントリクエスト分類(Event Request Class)などとして名付けることができる。
【0059】
「ローカルバンドル管理(Local Bundle Management:LBM)」は、バンドルローカル管理(Bundle Local Management)、ローカル管理(Local Management)、ローカル管理コマンド(Local Management Command)、ローカルコマンド(Local Command)、ローカルバンドル管理パッケージ(LBM Package)、バンドルローカル管理パッケージ(Bundle Local Management Package)、ローカル管理パッケージ(Local Management Package)、ローカル管理コマンドパッケージ(Local Management Command Package)、ローカルコマンドパッケージ(Local Command Package)として名付けることができる。
LBMは、端末に設置されたソフトウェアなどを介して任意のバンドルを設置(Install)するか、特定バンドルの状態(Enabled、Disabled、Deleted)を変更するか、特定バンドルの内容(例えば、バンドルの別称(Bundle Nickname)、又はバンドル要約情報(Bundle Metadata)など)を変更(update)する用途で用いられる。
LBMは、一つ以上のローカル管理コマンドを含むこともでき、この場合、各ローカル管理コマンドの対象になるバンドルは、ローカル管理コマンドごとに互いに同一であるか、又は異なる場合もある。
【0060】
「リモートバンドル管理(Remote Bundle Management:RBM)」は、バンドルリモート管理(Bundle Remote Management)、リモート管理(Remote Management)、リモート管理コマンド(Remote Management Command)、リモートコマンド(Remote Command)、リモートバンドル管理パッケージ(RBM Package)、バンドルリモート管理パッケージ(Bundle Remote Management Package)、リモート管理パッケージ(Remote Management Package)、リモート管理コマンドパッケージ(Remote Management Command Package)、リモートコマンドパッケージ(Remote Command Package)として名付けることができる。
RBMは、任意のバンドルを設置(Install)するか、特定バンドルの状態(Enabled、Disabled、Deleted)を変更するか、特定バンドルの内容(例えば、バンドルの別称(Bundle Nickname)、又はバンドル要約情報(Bundle Metadata)など)を変更(update)する用途として用いることができる。
RBMは、一つ以上のリモート管理コマンドを含むこともでき、各リモート管理コマンドの対象になるバンドルは、リモート管理コマンドごとに同一であるか、又は異なる場合もある。
【0061】
「ターゲットバンドル(target Bundle)」は、ローカル管理コマンドないしリモート管理コマンドの対象になるバンドルを指称する用語として用いられる。
「バンドル規則(Bundle Rule)」は、目標バンドルに対してローカル管理ないしリモート管理を行う時の端末が確認しなければならない情報を指称する用語として用いられる。
また、バンドル規則は、バンドル方策(Bundle Policy)、規則(Rule)、方策(Policy)などの用語と混用することができる。
【0062】
「認証書(Certificate)」又はデジタル認証書(Digital Certificate)は、公開鍵(Public Key:PK)と秘密鍵(Secret Key:SK)の対から構成される非対称鍵(Asymmetric Key)基盤の相互認証(Mutual Authentication)に用いられるデジタル認証書(Digital Certificate)を指す。
各認証は、一つ又は一つ以上の公開鍵(Public Key:PK)と、各公開鍵に対応する公開鍵識別子(Public Key Identifier:PKID)と、当該認証書を発給した認証書発給者(Certificate Issuer:CI)の識別子(Certificate Issuer ID)及びデジタル署名(Digital Signature)を含む。
また、認証書発給者(Certificate Issuer)は、認証発給者(Certification Issuer)、認証書発給機関(Certificate Authority:CA)、認証発給機関(Certification Authority)などとして名付けることができる。
【0063】
本発明で、公開鍵(Public Key:PK)と公開鍵識別子(Public Key ID:PKID)は、特定公開鍵、ないし当該公開鍵が含まれた認証書、又は特定公開鍵の一部分、ないし当該公開鍵が含まれた認証書の一部分、又は特定公開鍵の演算結果(例えば、ハッシュ(Hash))値、ないし当該公開鍵が含まれた認証書の演算結果(例えば、ハッシュ(Hash))値、又は特定公開鍵の一部分の演算結果(例えば、ハッシュ(Hash))値、ないし当該公開鍵が含まれた認証書の一部分の演算結果(例えば、ハッシュ(Hash))値、又はデータが記憶された記憶空間を指称する同じ意味で混用することができる。
【0064】
「認証書チェーン(Certificate Chain)」又は認証書階層構造(Certificate Hierarchy)は、「認証書発給者(Certificate Issuer)」が発給した認証書(1次認証書)が他の認証書(2次認証書)を発給するのに用いられるか、2次認証書が3次以上の認証書を連係に発給するのに用いられる場合、当該認証書の相関関係を指すことができる。
この時、最初認証書発給に用いられたCI認証書は、認証書ルート(Root of Certificate)、最上位認証書、ルートCI(Root CI)、ルートCI認証書(Root CI Certificate)、ルートCA(RootCA)、ルートCA認証書(Root CA Certificate)などと名付けることができる。
【0065】
そして、本発明を説明するにおいて、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不必要に不明瞭にすることができると判断された場合、その詳細な説明は省略する。
以下、端末の間のバンドルを移動して設置する方法及び装置に関する多様な実施形態を説明する。
【0066】
図1は、本発明の実施形態によるSSPの概念を示す図である。
一実施形態によれば、図1の例のように、端末110は、SSP120を含む。
例えば、SSP120は、端末110のSoC130に内蔵される。
この時、SoC130は、通信プロセッサ(Communication Processor)、アプリケーションプロセッサ(Application Processor)又はこの2つのプロセッサが統合されたプロセッサであっても良い。
他の例として、SSP120は、SoCに統合されず独立されたチップ形態として着脱型122であっても良く、端末110に予め内蔵した内蔵型124であっても良い。
【0067】
一実施形態によれば、端末に含まれたSSP120は、一つ以上のテレコムバンドル、一つ以上のペイメントバンドル、又は一つ以上の電子IDカードバンドルの内の少なくとも一つを含む。
例えば、図1に示すように、SSP120に複数のテレコムバンドル(140、150)が含まれた場合、端末110は、設定によって複数のテレコムバンドル(140、150)を同時又は時分割で動作するようにして移動通信ネットワークを用いる。
また、SSP10にペイメントバンドル170及び電子IDカードバンドル180が含まれた場合、端末110は、ペイメントバンドル170を用いて端末アプリを通じるオンライン決済又は外部クレジットカードPoS(Point of Sale)機器を通じるオフライン決済を用いることができ、電子IDカードバンドル180を用いて端末所有者の身分を認証することができる。
【0068】
図2は、本発明の実施形態によるSSP(Smart Secure Platform)の内部構造の概念を示す図である。
一実施形態によれば、図2の例のように、SSP210は、一つのプライマリープラットホーム(Primary Platform、PP)220とその上で動作する少なくとも一つのセカンダリープラットホームバンドル(Secondary Platform Bundle、SPB)(230、240)を含む。
【0069】
一実施形態によれば、プライマリープラットホーム220は、ハードウェア(開示せず)と少なくとも一つの下位階層オペレーティングシステム(low level Operating System:LLOS)222を含む。
一実施形態によれば、セカンダリープラットホームバンドル230は、上位階層オペレーティングシステム(High-level Operating System:HLOS)232とその上で動作する少なくとも一つのアプリケーション234を含む。
【0070】
一実施形態によれば、各セカンダリープラットホームバンドル(230、240)は、プライマリープラットホームインターフェース(Primary Platform Interface:PPI)250を用いてプライマリープラットホーム220の中央処理装置、メモリなどのリソースに接近し、これを介してSSP210で駆動される。
【0071】
図3は、本発明の実施形態による端末がSSPでバンドルをダウンロードして設置するための端末内部構成要素の例を示す図である。
一実施形態によれば、図3の例のように、端末310は、SSP330及び/又はSSP330を制御するためのLBA312を含む。
例えば、端末310は、SSP330が装着されてSSP330を制御するためのLBA312が設置された端末であり得る。
例えば、SSP330は、端末310に内蔵されるか着脱型であり得る。
【0072】
一実施形態によれば、SSP330は、プライマリープラットホーム331、セカンダリープラットホームバンドルローダー(Secondary Platform Bundle Loader:SPBL)333、及び一つ以上のセカンダリープラットホームバンドル(335、337、339)の内の少なくとも一つを含む。
一実施形態によれば、セカンダリープラットホームバンドル(335、337、339)は、端末出荷時点にはSSP330内部に設置されず、出荷後にリモートでダウンロード及び設置することができる。
【0073】
一実施形態によれば、図3の例のように、各バンドルは、互いに異なるバンドルファミリ識別子及び/又はバンドルファミリ管理者識別子(341、342、343)を持つ。
このようなバンドルファミリ識別子とバンドルファミリ管理者識別子は、バンドルのダウンロード及び設置に必要な情報として用いられる。
すなわち、SSP330又はSPBL333は、バンドルファミリ識別子とバンドルファミリ管理者識別子に従って特定バンドルのダウンロードと設置を許容したり拒否したりすることができる。
【0074】
図4は、本発明の実施形態による2つの端末の間でバンドルの送信が行うために2つの端末が相互動作する方法の例を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図4の例のように、第1端末400は、LBA410とSSP420を含み、第2端末450は、LBA460とSSP470を含む。
【0075】
一実施形態によれば、ユーザは、端末にコマンドを送信するか、若しくはユーザが提供されなければならない情報を端末から受信する。
例えば、4010動作及び4060動作のように、第1ユーザ440及び第2ユーザ490は第1端末400及び第2端末450のLBA(410、460)に命令を送信するか、若しくはLBA(410、460)からユーザが提供されなければならない情報を受信する。
【0076】
一実施形態によれば、上記の動作は、ユーザが送信しようするバンドルを選択する過程を含む。
また、上記の動作は、ユーザが送信を受けようとするバンドルの情報を確認する過程をさらに含む。
また、上記の動作は、ユーザが送信しようとするバンドルの送信をするかどうかを承認する動作をさらに含み得る。
また、上記の動作は、ユーザが送信を受けようとするバンドルの送信をするかどうかを承認する動作をさらに含み得る。
【0077】
また、一実施形態によれば、上記の動作は、ユーザが、使用が中止されたバンドルを使用再開で造るためにバンドルを選択する過程を含み得る。
また、上記の動作は、ユーザが使用再開リクエストを受けたバンドルの情報を確認する過程をさらに含み得る。
また、上記の動作は、ユーザが使用再開で造るバンドルを承認する動作をさらに含み得る。
また、上記の動作は、ユーザが使用再開リクエストを受けたバンドルの使用再開を承認する動作をさらに含み得る。
【0078】
上述した選択と承認の動作は、互いに独立的な動作としていずれも動作されなくても良く、一つ以上の動作が互いに独立的に選択されて動作することもできる。
また、4020動作及び4070動作でLBA(410、460)は、SSP(420、470)に命令を下すか又はSSP(420、470)とデータを送受信する。
一実施形態によれば、上記の動作で、LBAは上述のユーザのコマンドを受信し、この命令をSSPに伝達する。
上記の動作で、LBAがユーザの命令を受信し、この命令をSSPに伝達した場合、LBAは、その結果としてSSPが送信する結果を受信する。
【0079】
他の実施形態によれば、上記の動作で、LBAは他の端末又は外部サーバーから受信した命令やデータをSSPに伝達する。
上記の動作で、LBAが異なる端末又は外部サーバーから受けた命令やデータをSSPに伝達した場合、LBAは、その結果としてSSPが送信する結果を受信する。
【0080】
一実施形態によれば、上記の動作で、LBAはユーザの命令又は他の端末又は外部サーバーから受けた命令やデータに基づいて新しい命令とデータを定義し、これをSSPに伝達する。
上記の動作で、LBAはユーザの命令又は他の端末又は外部サーバーから受けた命令やデータに基づいて新しい命令とデータを定義し、これをSSPに伝達した場合、LBAは、その結果としてSSPが送信する結果を受信する。
一実施形態によれば、上記の動作で、LBAとSSPは、互いにデータを送受信してバンドルを設置する。
【0081】
一実施形態によれば、4050動作で2つのLBA(410、460)は、互いに接続されて相手に命令を下すか相手とデータを送受信する。
この時、4050動作での接続は、端末と端末の直接的な機器の間の接続であっても良く、たとえ図に示さなかったが2つのLBA(410、460)の接続の間に外部個体(例えば、外部サーバー)が接続されている間接的な機器の間の接続であっても良い。
上述した2つのLBAの間の接続方法に対するより詳細な技術は、後述で、図面を参照して説明する。
【0082】
一実施形態によれば、4030動作及び4080動作で、SSP(420、470)は、SSP内部で必要なデータを生成するか処理、又は検証する。
一実施形態よれば、上記の動作で、SSPは、バンドル移動設定を確認する。
また、上記の動作で、SSPは、バンドル移動コードを生成して活用する。
上述したバンドル移動設定関連動作とバンドル移動コード関連動作は、互いに独立的な機能として、2つの機能いずれもが実行しないか、又は、2つの機能のいずれかの一つだけ実行するか、又は、2つ機能いずれもが実行することもできる。
2つ機能のいずれもが実行される場合にも2つ機能は、完全に独立された機能として行うことができる。
【0083】
一実施形態によれば、上記の動作で、SSPは、自分のSSP情報を生成するか、相手の端末及び/又はサーバーから受けたSSP情報を検証する。
また、上記の動作で、SSPは、自分を検証することができる認証データを生成することもでき、相手の端末から受けた認証データを検証することもできる。
【0084】
一実施形態によれば、上記の動作で、SSPは、図5で記述する「証明書」を生成し、受信した「証明書」を検証する。
SSPが生成/検証可能な多様な「証明書」の例は、後述する図10図15及び図22図27を参考する。
一実施形態によれば、上記の動作で、SSPは、バンドルの状態を設定する。
SSPが設定することができる多様なバンドルの状態と設定条件は、後述する図10図15及び図22図27を参考する。
一実施形態によれば、上記の動作で、SSPは、バンドルを生成する。
【0085】
図5は、本発明の一実施形態による「証明書(Attestation)」の構成を示す図である。
一実施形態によれば、証明書は、「バンドル区分者」を選択的に含む(符号510)。
例えば、証明書は、図5に示したようにバンドル区分者の内の一つのバンドル識別子(SPB ID)を選択的に含み得る。
【0086】
一実施形態によれば、証明書はまた、他の証明書を選択的にさらに含み得る(符号530)。
証明書の内に含まれるまた他の証明書の多様な実例は、後述する図10図15の説明を参照する。
一実施形態によれば、証明書は、「SSP識別子(SSP ID)」を選択的にさらに含み得る(符号540)。
一実施形態によれば、証明書は、SSPが行なった動作に対する情報を選択的にさらに含み得る(符号550)。
SSPが行う動作の多様な実例は、後述する図10図15の説明を参照する。
【0087】
一実施形態によれば、証明書は、必要な場合に前述した情報(符号530、符号540、符号550)以外の、その他のデータを選択的にさらに含み得る(符号520)。
証明書の内に含まれ得るその他のデータの多様な実例は、後述する図10図15の説明を参照する。
一実施形態によれば、証明書は、上述した情報に対する電子署名データを含み得る(符号560)。
この署名データは、SSPの署名用認証書によって生成された電子署名であっても良い。
【0088】
図6は、本発明の実施形態による一つの端末で他の端末でバンドルが送信される手順を概念的に示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図6の例のように、第1端末600は、第1LBA620と第1SSP610を含み、第2端末650は、第2LBA670と第2SSP660を含む。
例えば、第1端末600は、第1SSP610が装着されて第1SSP610を制御するための第1LBA620が設置された端末であり得、第2端末650は、第2SSP660が装着されて第2SSP660を制御するための第2LBA670が設置された端末であり得る。
【0089】
図6を参照すると、6000段階で、第1端末600の第1SSP610、第1LBA620と第2端末650の第2LBA670は、バンドル送信のために必要な準備手順(バンドル送信準備手順)を行う。
上記手順に対するより詳しい説明は、後述する図7の詳細説明を参照する。
図6を参照すると、6005段階で、第1端末600から第2端末650にバンドルが送信される手順(バンドル送信手順)が行われる。
上記手順に対するより詳しい説明は、後述する図8の詳細説明を参照する。
図6を参照すると、6010段階で第1端末600と第2端末660は、送信されたバンドルの設置手順とバンドルの状態を設定する手順(バンドル送信仕上げ手順)を行う。
上記手順に対する詳しい説明は、後述する図9図12の詳細説明を参照する。
【0090】
図7は、図6で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。
より詳しくは、図7は、本発明の実施形態による一つの端末が他の端末にバンドルを送信するために必要な準備過程を経る手順を例示的に示す図である。
本明細書で、図7の手順は、バンドル送信準備手順として指称され得る。
【0091】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図7の例のように、第1端末700は、第1LBA720と第1SSP710を含み、第2端末750は、第2LBA770と第2SSP760を含む。
例えば、第1端末700は、第1SSP710が装着されて第1SSP710を制御するための第1LBA720が設置された端末であり得、第2端末750は、第2SSP760が装着されて第2SSP760を制御するための第2LBA770が設置された端末であり得る。
【0092】
一実施形態によれば、第1端末700は、既に設置されたバンドルを保有しても良く、このバンドルと関連したメタデータをさらに保有しても良い。
一実施形態によれば、第1端末700は、当該バンドルと関連してバンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、又はバンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つを保有し得る。
【0093】
一実施形態によれば、第1端末700は、当該バンドルと関連して「バンドル移動設定」を保有し得る。
バンドル移動設定は、当該バンドルの機器の間の送信することができるかどうかに関連する情報を選択的に含み得る。
また、バンドル移動設定は、当該バンドルが複数の端末で重複使用が可能であるかどうかに対する情報を選択的にさらに含み得る。
例えば、当該バンドルが「複数の端末で、同時に重複して用いられることが禁止」されている場合、すなわち、「ある一時点で、バンドルは一つの端末にだけ使用すべきである」場合、これに対する情報が含まれ得る。
【0094】
図7を参照すると、7000段階で、機器の間の送信されるバンドルの情報を第1LBA720に伝達する。
この伝達過程は、例えば、図7に示したように、第1端末700が提供するUIを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第1LBA720に入力することもでき、又は、第1LBA720がリモートサーバーに接続して当該情報を読み取ることもできる。
【0095】
図7を参照すると、7005段階で、7000段階を介して選択されたバンドルに関連する情報を第1LBA720から第1SSP710に伝達する。
例えば、図7に示したように、上記選択されたバンドルに関連する情報を、「Select SPB command(SPBコマンド選択)」を介して第1LBA720から第1SSP710に伝達する。
この時、第1LBA720から第1SSP710に伝達する情報は、7000段階で選択されたバンドルを識別(identify)するための情報を含む。
【0096】
図7を参照すると、7010段階で、第1SSP710は、送信をリクエストしたバンドルの機器の間の送信可能であるかどうかを確認する。
この過程は、先ず7005段階で受信した情報に基づいて送信がリクエストされたバンドルを識別し、当該バンドルと関連した(associated with)「バンドル移動設定」を確認することによって行われる。
この過程で、「バンドル移動設定」が「当該バンドルが複数の端末で重複使用が可能であるかどうかに対する情報」を含んでいる場合、第1SSP710は、この事実を確認する。
また、7010段階で、第1SSP710は、選択的に「バンドル移動コード」を設定する。
「バンドル移動コード」は、当該バンドルの機器の間の送信過程で、当該バンドルを指称するために用いられるコードとして当該バンドルを識別することができる値ではなければならない。
第1SSP710は、前述した「バンドル移動コード」と送信しようとするバンドルの情報をバインディング(binding)する。
【0097】
図7を参照すると、7015段階で、7005段階に対する応答結果が第1SSP710から第1LBA720に送信される。
例えば、図7に示したように、「Select SPB command(SPBコマンド選択)」に対する応答が「Select SPB response(SPB応答選択)」を介して第1SPB710から第1LBA720に伝達される。
この応答値は、7010段階で記述された「バンドル移動コード」を含む。
【0098】
図7を参照すると、7020段階で、機器の間のバンドル送信のために必要な情報が第1端末700の第1LBA720から第2端末750の第2LBA770に伝達される。
この時、第1LBA720から第2LBA770に伝達する情報には「バンドル移動コード」が含まれる。
また、第1LBA820から第2LBA870に伝達する情報は、以後の7025段階で第1LBA720と第2LBA770の間に確立される(established)接続のために必要な情報を選択的にさらに含み得る。
また、第1LBA720から第2LBA770に伝達される情報には機器の間のバンドル移動が行われることを通知する情報が選択的にさらに含まれ得る。
【0099】
上述した7020段階を介して第1LBA720から第2LBA770に伝達する情報は、多様な方法で伝達することができる。
例えば、第1LBA720は、第2LBA770に伝達しなければならない情報を第1端末700のUIを介してユーザに提供し、ユーザは、提供された情報を第2端末750のUIを用いて第2LBA770に入力する。
若しくは、第1LBA720は、第2LBA770に伝達しなければならない情報をイメージ(例えば、QRコード(登録商標))の形態で作成し、第1端末700の画面に表示し、ユーザは、第2端末750を用いてこのイメージをスキャンすることによって第2LBA770に情報を伝達する。
しかし、第1LBA720から第2LBA770に情報を伝達する方法は、上記の方法に限らない。
【0100】
図7を参照すると、7025段階で、第1LBA720と第2LBA770の間に接続が確立(又は、設定)される。
もし、7020段階で接続のために必要な情報が送信されると、第1LBA720と第2LBA770はこの情報を用いて接続を確立することもできる。
第1LBA820と第2LBA870の接続は、直接的な機器の間の接続であっても良く(例えば、NFC、ブルートゥース(登録商標)、UWB、WiFi-Direct、LTE D2D(device-to-device)、5G D2D)又は第1LBA720と第2LBA770の間にリモートサーバー(例えば、リレーサーバー)が配置された遠距離接続であっても良い。
【0101】
図7を参照すると、7025段階は、最後の段階として図に示したが、この段階は前述の他の段階、すなわち、7000段階、7005段階、7010段階、7015段階、7020段階とは独立的な段階として他の段階と手順に関わらず行われることができる。
例えば、7025段階は、7015段階と7020段階の間で行うこともでき、この場合、7020段階で第1LBA720から第2LBA2770に送信される情報は、7025段階で確立された接続を介して送信される。
【0102】
図8は、図6で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図面である。
より詳しくは、図8は、本発明の実施形態による一つの端末が他の端末にバンドルを送信する手順を例示的に示す図である。
本発明で、図8の手順は、バンドル送信手順として指称され得る。
【0103】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図8の例のように、第1端末800は、第1LBA820と第1SSP810を含み、第2端末850は、第2LBA870と第2SSP860を含む。
例えば、第1端末800は、第1SSP810が装着されて第1SSP810を制御するための第1LBA820が設置された端末であっても良く、第2端末850は、第2SSP860が装着されて第2SSP860を制御するための第2LBA870が設置された端末であっても良い。
【0104】
図8を参照すると、8000段階で、第2LBA870は、第2SSP2860に「SSP情報(SspInfo)」をリクエストする。
8000段階で第2LBA870が第2SSP860に「SSP情報(SspInfo)」をリクエストする時、第2LBA870は、第2SSP860に機器の間のバンドル移動が行われることを通知する。
また、8000段階は、図8で図に示した過程に続いて直ちに自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第2端末850が提供するUIを介してユーザが直接送信されるバンドルを選択する過程を介して行うこともできて、リモートサーバーからプッシュ入力を介して第2LBA870に入力することもでき、又は第2LBA870がリモートサーバーに接続して当該情報を読み取ることもできる。
【0105】
図8を参照すると、8005段階で、第2SSP860は、自分の「SSP情報(SspInfo)」を生成する。
「SSP情報」にはバンドル送信のために提供しなければならない第2SSPの情報が含まれる。
この時、「SSP情報」には第2SSP860がバンドルを受信する前に経なければならない認証書交渉過程のための情報(認証書交渉情報)が含まれる。
この「認証書交渉情報」は、第2SSP860が他のSSPを検証するのに用いることができる認証書情報(SenderSpblVerification)と他のSSPが自分を検証するのに用いられることができる認証書情報(ReceiverSpblVerification)を含む。
また、「認証書交渉情報」は、第2SSP860がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第2SSP860がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また、「SSP情報」には第2SSP960が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むSSPバージョン情報が選択的にさらに含まれ得る。
【0106】
図8を参照すると、8010段階で、第2SSP860は、第2LBA870と第1LBA820を経て第1SSP810に8005段階で生成した「SSP情報」を伝達する。
以上、記述した段階で、8010段階によると、第2LBA870が第2SSP860に「SSP情報(SspInfo)」をリクエストし、第2SSP860が自分の「SSP情報」を生成した後、第2SSP860が第2LBA870と第1LBA820を経て第1SSP810に「SSP情報」を伝達する。
しかし、実施形態によって、第2端末850で第1端末800に「SSP情報」が伝達される過程は、次の通りである。
例えば、第2LBA870が、自ら「SSP情報」を生成した後に、第1LBA820を経て第1SSP810に「SSP情報」を伝達することができる。
【0107】
図8を参照すると、8015段階で、第1SSP810は、受信した「SSP情報」を確認してこの情報に基づいて自分を認証することができる「第1端末認証情報(Device 1.Auth)」を生成する。
この過程に対するより具体的な手順は、次の通りである。
第1SSP810は、受信した「SenderSpblVerification」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書(ssp1.Cert.KA)を選択する。
若しくは、第1SSP810は、受信した「第2SSP860がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「ssp1.ePK.KA」と秘密鍵「ssp1.ePK.KA」を生成した後、この鍵の対の内の公開鍵(ssp1.ePK.KA)を選択する。
【0108】
また、第1SSP810は、受信した「SenderSpblVerification」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の署名用認証書(ssp1.Cert.DS)をさらに選択する。
また、第1SSP810は、受信した「ReceiverSpblVerification」を用いて検証を行う第2SSP860の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「CiPkIdToBeUsedとして設定する。
また、第1SSP810は、受信した「第2SSP860がサポートする暗号化アルゴリズムのリスト」を用いて今後の用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「CryptoToBeUsed」として設定する。
また、第1SSP810は、受信した「第2SSP860が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認し、その中、自分もサポートする標準規格のバージョンが存在するかを確認する。
【0109】
「第1端末認証情報(Device 1.Auth)」は、前述した「ssp1.Cert.KA」、「ssp1.ePK.KA」、「CiPkIdToBeUsed」、「CryptoToBeUsed」の内の少なくとも一つを含む。
また、「第1端末認証情報(Device 1.Auth)」は、前述した「ssp1.Cert.DS」を選択的にさらに含み得る。
また、「第1端末認証情報(Device 1.Auth)」は、今後に送信されるバンドルに関連したバンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つを選択的にさらに含み得る。
【0110】
この時、上記で言及した「第1端末認証情報(Device 1.Auth)」の一部又は全体は、情報の無欠性を保障するために「ssp1.Cert.DS」を用いて検証可能になるようにデジタル署名され得、このデジタル署名データは、「第1端末認証情報」の一部として追加され得る。
【0111】
図8を参照すると、8020段階で、第1SSP810は、第1LBA820を経て第2LBA870に8015段階で生成した「第1端末認証情報(Device 1.Auth)」を伝達する。
図8を参照すると、8025段階で、第2LBA870は、第2SSP860に「第1端末認証情報(Device 1.Auth)」を伝達する。
また、第2LBA870は、第2SSP860に「バンドル移動コード」をさらに伝達する。
【0112】
図8を参照すると、8030段階で、第2SSP860は、受信した「第1端末認証情報(Device 1.Auth)」を検証する。
もし、第2SSP860が「ssp1.Cert.KA」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第2SSP860が「ssp1.ePK.KA」とこれに対するデジタル署名が送信された場合には、先ず、「ssp1.Cert.DS」の有効性を検査した後、この認証書を用いてデジタル署名を確認して受信した公開鍵「ssp1.ePK.KA」の無欠性を確認する。
また、第2SSP860は、受信した「CiPkIdToBeUsed」を確認して自分を検証することができる少なくとも一つ以上の署名用認証書(ssp2.Cert.DS)を選択する。
【0113】
また、図には示していないが、8030段階で、第2SSP960は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)として公開鍵「ssp2.ePK.KA」と秘密鍵「ssp2.eSK.KA」を生成した後、この鍵の対の内の公開鍵(ssp2.ePK.KA)を選択することができる。
また、第2SSP860は、「ssp1.Cert.KA」に含まれている鍵合意用公開鍵や「ssp1.ePK.KA」の内の一つを選択した後、この値と「ssp2.eSK.KA」を用いて以後の端末1との通信中の暗号化に用いられるセッション鍵(ShKey01)を生成することができる。
ShKey01は、受信した「CryptoToBeUsed」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
【0114】
また、8030段階で、第2SSP860は、自分を認証することができる「第2端末認証情報(Device 2.Auth)」を生成する。
この時、「第2端末認証情報(Device 2.Auth)」は、「ssp2.Cert.DS」を含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、「ssp2.ePK.KA」をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、SSP2860によって生成された現在セッションを指称するトランザクションアイディー(transaction ID)をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、「バンドル移動コード」をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、第2SSP960のSSP識別子をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、以後の送信されるバンドルに関連したバンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つを選択的にさらに含み得る。
【0115】
この時、上記で言及した「第2端末認証情報(Device 2.Auth)」の一部又は全体は、情報の無欠性を保障するために「ssp2.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「第2端末認証情報」の一部として追加され得る。
また、「第2端末認証情報(Device 2.Auth)」の一部又は全体は、先立って生成されたセッション鍵(ShKey01)を用いて暗号化される。
【0116】
図8を参照すると、8035段階で、第2SSP860は、第2LBA870と第1LBA820を経て第1SSP810に8030段階で生成した「第2端末認証情報(Device 2.Auth)」を伝達する。
この時、「バンドル移動コード」が選択的にさらに送信され得る。
【0117】
図8を参照すると、8040段階で、第1SSP810は、受信した「第2端末認証情報(Device 2.Auth)」を検証する。
第1SSP810は、受信した「ssp2.Cert.DS」の署名を検証して当該認証書の有効性を検証する。
また、第1SSP810は、受信したバンドルファミリ識別子(SPB Family ID)及び/又はバンドルファミリ管理者識別子(SPB Family Custodian Object ID)が、自分が送信しようとするバンドルと関連して正しく設定された値であるかを検査する。
また、第1SSP810は、受信したトランザクションアイディー(transaction ID)及び/又は第2SSP860のSSP識別子を記憶する。
また、第1SSP810は、受信したトランザクションアイディー(transaction ID)や第2SSP960のSSP識別子を、現在進行しているセッション又は送信しようとするバンドルとバインディング(binding)させる。
【0118】
この過程で、若し、「第2端末認証情報(Device 2.Auth)」に暗号化されたデータが含まれている場合、第1SSP810は、送信された「ssp2.ePK.KA」と自分の「ssp1.Cert.KA」に含まれている鍵合意用公開鍵に対応される秘密鍵や「ssp1.ePK.KA」を用いてセッション鍵(ShKey01)を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後の検証過程を行う。
また、この過程で、もし、「第2端末認証情報(Device 2.Auth)」にデジタル署名が含まれている場合、第1SSP810は、「ssp2.Cert.DS」を用いて受信したデジタル署名の有効性を検証する。
【0119】
また8040段階で、図8に示していないが、第1SSP810は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「ssp1.bundle.ePK.KA」と秘密鍵「ssp1.bundle.eSK.KA」を生成することができる。
この時、鍵の対「ssp1.bundle.ePK.KA」と「ssp1.bundle.eSK.KA」は、先立って生成された「ssp1.ePK.KA」と「ssp1.ePK.KA」と同一値で設定することもできる。
又は、鍵の対「ssp1.bundle.ePK.KA」と「ssp1.bundle.eSK.KA」は、先立って用いられた「「ssp1.Cert.KA」に含まれている公開鍵とここに対応される秘密鍵」と同一値で設定することもできる。
また、第1SSP810は、「ssp1.bundle.eSK.KA」と「ssp2.ePK.KA」を用いてセッション鍵(ShKey02)を生成することができる。
もし、「ssp1.bundle.eSK.KA」のために「ssp1.ePK.KA」又は「ssp1.Cert.Ka」に含まれている公開鍵に対応される秘密鍵が再使用されると、セッション鍵(ShKey02)の値も以前に生成されたShKey01の値で設定することができる。
【0120】
また8040段階で、第1SSP810は、第2端末850で送信するバンドル及び/又はバンドルと関連したメタデータを構成する。
この時、第1SSP810は、受信した「バンドル移動コード」を用いて自分が送信しようとするバンドルを識別する。
また、構成されるバンドルには「ssp1.Cert.DS」が含まれ得る。
また、構成されるバンドルには「ssp1.bundle.ePK.KA」がさらに含まれ得る。
また、構成されるバンドルは、当該セッションを識別するトランザクションアイディー(transaction ID)をさらに含み得る。
また、構成されるバンドルには、送信されるバンドルと関連したバンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが選択的にさらに含まれ得る。
一実施形態によれば、8040段階で、構成されるバンドル(又は、バンドルと関連したメタデータ)内には「バンドル移動設定」が含まれ得る。
【0121】
一実施形態によれば、8040段階で、構成されるバンドルには「ssp1.Cert.DS」を用いて生成されたデジタル署名データが追加される。
すなわち、上記で明示したバンドルの構成要素一部又は全体に対して生成されたデジタル署名データがバンドルの一部として追加される。
また、構成されるバンドルの一部又は全体は、ShKey02を用いて暗号化される。
【0122】
図8を参照すると、8045段階で、第1SSP810は、第1LBA820を経て第2LBA870に8040段階で生成した(構成された)バンドルを伝達する。
この時、送信されるバンドルと関連したメタデータが選択的にさらに送信され得る。
また、送信されるバンドルと関連した「バンドル移動設定」がさらに送信され得る。
例えば、「バンドル移動設定」がバンドル又はメタデータに含まれず、別途のフォーマット(例えば、メッセージ)で送信され得る。
【0123】
図9は、図6で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。
より詳しくは、図9は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順の可能な一例示を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図9の例のように、第1端末900は、第1LBA920と第1SSP910を含み、第2端末950は、第2LBA970と第2SSP960を含む。
例えば、第1端末900は、第1SSP910が装着されて第1SSP910を制御するための第1LBA920が設置された端末であっても良く、第2端末950は、第2SSP960が装着されて第2SSP960を制御するための第2LBA970が設置された端末であっても良い。
【0124】
1.〔バンドル設置〕
図9を参照すると、9000段階で、第2LBA970と第2SSP960は、互いに協業して第2端末950にバンドルを設置する。
この過程で次の手順が共に行われる。
もし、メタデータが送信された場合、第2LBA970又は第2SSP960は、メタデータに含まれた内容を検証する。
もし、「バンドル移動設定」が送信されると、第2LBA970は、この情報を第2SSP960に伝達する。
もし、トランザクションアイディー(transaction ID)が送信されると、第2LBA970又は第2SSP960は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
【0125】
もし、バンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが送信されると、第2LBA970又は第2SSP960は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ssp1.Cert.DS」が送信されると、第2SSP960は、この認証書の有効性を検証して第1SSP910を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第2SSP960は、送信された「ssp1.bundle.ePK.KA」と自分の「ssp2.eSK.KA」を用いてセッション鍵(ShKey02)を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第2SSP960は、「ssp1.Cer.DS」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
【0126】
2.〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第2LBA970及び/又は第2SSP960は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができる。
この判断をする幾つかの可能な方法は、次の通りである。
可能な一例として、もし、バンドル移動設定に当該バンドルが複数の端末で重複使用が可能であるかどうかが含まれていると、第2LBA970及び/又は第2SSP960は、この情報を確認することによって判断を下すことができる。
他の可能な例として、第2LBA970及び/又は第2SSP960は、受信したバンドルファミリ識別子(SPB Family ID)及び/又はバンドルファミリ管理者識別子(SPB Family Custodian Object ID)を用いて当該バンドルが複数の端末で重複使用が可能であるかどうかを確認することもできる。
この過程は、9000段階の一部として9000段階で行われる手順と順序に関わらず行うこともでき、若しくは9000段階以後に行うこともできる。
【0127】
3.〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能なバンドルで判断された場合、バンドルの状態を追加的に設定する過程は、必要ではないこともある。
若しくは、第2LBA970及び/又は第2SSP960が当該バンドルの重複使用をするかどうかを判断しない場合にも、第2LBA970及び/又は第2SSP960の具現によってバンドルの状態を追加的に設定する過程は、必要ではないこともある。
【0128】
図10は、図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図10は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順のまた他の例示を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図10の例のように、第1端末1000は、第1LBA1020と第1SSP1010を含み、第2端末1050は、第2LBA1070と第2SSP1060を含む。
例えば、第1端末1000は、第1SSP1010が装着されて第1SSP1010を制御するための第1LBA1020が設置された端末であっても良く、第2端末1050は第2SSP1060が装着されて第2SSP1060を制御するための第2LBA1070が設置された端末であっても良い。
【0129】
1.〔バンドル設置〕
図10を参照すると、10000段階で、第2LBA1070と第2SSP1060は、互いに協業して第2端末1050にバンドルを設置する。
これに対する詳細な説明は、図9の「バンドル設置」過程を参照する。
【0130】
2.〔重複使用可能であるかどうか確認〕
また、図には示してなかったが、第2LBA1070及び/又は第2SSP1060は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができる。
これに対する詳細な説明は、図9の「重複使用可能であるかどうか確認」過程を参照する。
【0131】
3.〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第2LBA1070及び/又は第2SSP1060が当該バンドルの重複使用をするかどうかを判断しない場合にも、第2LBA1070及び/又は第2SSP1060の具現によって下記のようにバンドルの状態を追加的に設定する過程を行うことができる。
【0132】
図10を参照すると、10005段階で、第2SSP1060は、当該バンドルの状態を「IN TRANSITION」として設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されたが未だ使用が不可能な状態(さらに、「他の端末のリクエスト(例えば、「finalizationResponse」や「recoveryRequest」を送信することによって行われるリクエスト)」及び/又は「(本発明では説明されなかったが)の外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態(Disabled、Enable、Active状態)で変更することができる状態)を意味する。
【0133】
図10を参照すると、10010段階で、第2LBA1070は、第2SSP1060に「証明書」をリクエストする。
図10を参照すると、10015段階で、第2SSP1060は、「証明書」を生成する。
図10で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図5で開示した構造による。
【0134】
この時、可能な証明書構成の一つ例は、次の通りである。
・「finalizationRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、符号550に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、符号520に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を生成した時間を選択的に含む。
・「finalizationRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0135】
図10を参照すると、10020段階で、第2SSP1060は、第1SSP1010に「finalizationRequest」を伝達する。
例えば、第2SSP1060は、第1SSP1010に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP1060は、第2LBA1070に10010段階の応答で「finalizationRequest」を伝達し、第2LBAは、第1LBA1020を経て第1SSPに「finalizationRequest」を伝達する。
【0136】
図10を参照すると、10025段階で、第1SSP1010は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含む。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含む。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報が、バンドルの状態を「IN TRANSITION」状態に変更するかを確認する過程をさらに含む。
【0137】
また、10025段階で、第1SSP1010は、検証が済んだ後のバンドルを削除する。
また、10025段階で、第1SSP1010は、「証明書」を生成する。
図10で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図5で開示した構造による。
【0138】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0139】
また、可能な証明書構成の他の例は、次の通りである。
・「finalizationResponse」は、符号530に受信した「finalizationRequest」を含む。
この時、受信した「finalizationRequest」の一部情報は、必要によって省略され得る。
例えば、「finalizationRequest」に含まれている第2SSPの署名情報は、場合によって省略され得る。
また、例えば、「finalizationRequest」に含まれている時間情報は、場合によって省略され得る。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0140】
図10を参照すると、10030段階で、第1SSP1010は、第2SSP1060に「finalizationResponse」を伝達する。
例えば、第1SSP1010は、第1LBA1020と第2LBA1070を経て第2SSP1060に「finalizationResponse」を伝達する。
【0141】
図10を参照すると、10035段階で、第2SSP1060は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
【0142】
また、10035段階で、第2SSP1060は、検証が済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP1060は、バンドルの状態を「Disabled」状態に変換する。
図10を参照すると、10040段階で、第2SSP1060は、10035段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第2LBA1070に送信する。
【0143】
図11は、図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図11は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順のまた他の例示を示す図である。
【0144】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図11の例のように、第1端末1100は、第1LBA1120と第1SSP1110を含み、第2端末1150は、第2LBA1170と第2SSP1160を含む。
例えば、第1端末1100は、第1SSP1110が装着されて第1SSP1110を制御するための第1LBA1120が設置された端末であっても良く、第2端末1150は、第2SSP1160が装着されて第2SSP1160を制御するための第2LBA1170が設置された端末であっても良い。
【0145】
1.〔バンドル設置〕
図11を参照すると、11000段階で、第2LBA1170と第2SSP1160は、互いに協業して第2端末1150にバンドルを設置する。
これに対する詳細な説明は、図9の「バンドル設置」過程を参照する。
【0146】
2.〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第2LBA1170及び/又は第2SSP1160は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができ、これに対する詳細な説明は、図9の「重複使用可能であるかどうか確認」過程を参照する。
【0147】
3.〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第2LBA1170及び/又は第2SSP1160が、当該バンドルの重複使用をするかどうかを判断しない場合にも、第2LBA1170及び/又は第2SSP1160の具現によって下記のようにバンドルの状態を追加的に設定する過程が行われる。
【0148】
図11を参照すると、11005段階で、第2SSP1160は、当該バンドルの状態を「IN TRANSITION」で設定する。
「IN TRANSITION」状態に対する説明は、10005段階の説明を参照する。
図11を参照すると、11010段階で、第2LBA1170は、第2SSP1160に「証明書」をリクエストする。
【0149】
図11を参照すると、11015段階で、第2SSP1160は、「証明書」を生成する。
図11で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0150】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、符号550に第2SSPがバンドルの状態を「IN TRANSITION」状態として設定したことを意味する情報を含む。
・「finalizationRequest」は、符号520に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を造った時間を選択的に含む。
・「finalizationRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0151】
図11を参照すると、11020段階で、第2SSP1160は、第1SSP1110に「finalizationRequest」を伝達する。
例えば、第2SSP1160は、第1SSP1110に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP1160は、第2LBA1170に11010段階の応答で「finalizationRequest」を伝達し、第2LBAは、第1LBA1120を経て第1SSPに「finalizationRequest」を伝達する。
【0152】
図11を参照すると、11025段階で、第1SSP1110は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP 識別子」が第2SSPの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0153】
また、11025段階で、第1SSP1110は、検証が済んだ後のバンドルの状態を「IN TRANSITION」状態に設定する。
また、11025段階で、第1SSP1110は、「証明書」を生成する。
図11で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0154】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルの状態を「IN TRANSITION」状態に変更したことを意味する情報をむ。
・「finalizationResponse」は、符号520に第1SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0155】
また、可能な証明書構成の他の例は、次の通りである。
・「finalizationResponse」は、符号530に受信した「finalizationRequest」を含む。
この時、受信した「finalizationRequest」の一部情報は、必要によって省略され得る。
例えば、「finalizationRequest」に含まれている第2SSPの署名情報は、場合によって省略され得る。
また、例えば、「finalizationRequest」に含まれている時間情報は、場合によって省略され得る。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルの状態を「IN TRANSITION」状態に変更したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0156】
図11を参照すると、11030段階で、第1SSP1110は、第2SSP1160に「finalizationResponse」を伝達する。
例えば、第1SSP1110は、第1LBA1120と第2LBA1170を経て第2SSP1160に「finalizationResponse」を伝達する。
【0157】
図11を参照すると、11035段階で、第2SSP1160は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報が正しいか確認する過程をさらに含み得る。
【0158】
また、11035段階で、第2SSP1160は、検証が済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP1160は、バンドルの状態を「Disabled」状態に変換する。
【0159】
また、11035段階で、第2SSP1160は、「証明書」を生成する。
図11で、この証明書は、「spblAttestation」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0160】
この時、可能な証明書構成の一例は、次の通りである。
・「spblAttestation」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「spblAttestation」は、符号540に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は、符号550に第2SSPがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「spblAttestation」は、符号520に第2SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「spblAttestation」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0161】
また、可能な証明書構成の他の例は、次の通りである。
・「spblAttestation」は、符号530に受信した「finalizationResponse」を含む。
この時、受信した「finalizationResponse」の一部情報は、必要によって省略され得る。
例えば、「finalizationResponse」に含まれている署名情報の一部は、場合によって省略され得る。
また、例えば、「finalizationResponse」に含まれている時間情報の一部は、場合によって省略され得る。
・「spblAttestation」は、符号540に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は、符号550に第2SSPがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「spblAttestation」は、符号520に第2SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「spblAttestation」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0162】
図11を参照すると、11040段階で、第2SSP1160は、第1SSP1110に「spblAttestation」を伝達する。
例えば、第2SSP1160は、第2LBA1170と第1LBA1120を経て第1SSPに「spblAttestation」を伝達する。
【0163】
図11を参照すると、11045段階で、第1SSP1110は、受信した「spblAttestation」を検証する。
この検証過程は、「spblAttestation」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「spblAttestation」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれた「finalizationResponse」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれたコマンド情報がバンドルの状態を使用可能な状態に変更することであるかを確認する過程をさらに含み得る。
【0164】
また、11045段階で、第1SSP1110は、検証が済んだ後のバンドルを削除する。
【0165】
図12は、図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図12は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順のまた他の例示を示す図である。
【0166】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図12の例のように、第1端末1200は、第1LBA1220と第1SSP1210を含み、第2端末1250は第2LBA1270と第2SSP1260を含む。
例えば、第1端末1200は、第1SSP1210が装着されて第1SSP1210を制御するための第1LBA1220が設置された端末であっても良く、第2端末1250は、第2SSP1260が装着されて第2SSP1260を制御するための第2LBA1270が設置された端末であっても良い。
【0167】
1.〔バンドル設置〕
図12を参照すると、12000段階で第2LBA1270と第2SSP1260は、互いに協業して第2端末1250にバンドルを設置する。
これに対する詳細な説明は、図9の「バンドル設置」過程を参照する。
【0168】
2.〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第2LBA1270及び/又は第2SSP1260は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができ、これに対する詳細な説明は、図9の「重複使用可能であるかどうか確認」過程を参照する。
【0169】
3.〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第2LBA1270及び/又は第2SSP1260が、当該バンドルの重複使用をするかどうかを判断しない場合にも、第2LBA1270及び/又は第2SSP1260の具現によって、下記のようにバンドルの状態を追加的に設定する過程が行われる。
【0170】
図12を参照すると、12005段階で、第2SSP1260は、当該バンドルの状態を「IN TRANSITION」で設定する。
「IN TRANSITION」状態に対する説明は、10005段階の説明を参照する。
図12を参照すると、12010段階で、第2LBA1270は、第2SSP1260に「証明書」をリクエストする。
【0171】
図12を参照すると、12015段階で、第2SSP1260は、「証明書」を生成する。
図12で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0172】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、符号550に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、符号520に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を生成した時間を選択的に含む。
・「finalizationRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0173】
図12を参照すると、12020段階で、第2SSP1260は、第1SSP1210に「finalizationRequest」を伝達する。
例えば、第2SSP1260は、第1SSP1210に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP1260は、第2LBA1270に12010段階の応答で「finalizationRequest」を伝達し、第2LBAは、第1LBA1220を経て第1SSPに「finalizationRequest」を伝達する。
【0174】
図12を参照すると、12025段階で、第1SSP1210は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0175】
また、12025段階で、第1SSP1210は、検証を済んだ後のバンドルの状態を「SUSPENSION」状態で設定する。
「SUSPENSION」は、バンドル使用が不可能な状態(さらに、「他の端末のリクエスト(例えば、「recoveryRequest」を送信することによって行われるリクエスト)」及び/又は「(本発明では説明しなかったが)外部サーバーのリクエスト」によってだけ使用可能な状態(Disabled、Enable、Active状態)に変更することができる状態)を意味する。
また、図に示さなかったが、前述した「SUSPENSION」状態は、「IN TRANSITION」状態に取り替えることもできる。
【0176】
また、12025段階で、第1SSP1210は、「証明書」を生成する。
図12で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0177】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルの状態を「SUSPENSION」(若しくは、「IN TRANSITION」)状態に変更したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0178】
また、可能な証明書構成の他の例は、次の通りである。
・「finalizationResponse」は、符号530に受信した「finalizationRequest」を含む。
この時、受信した「finalizationRequest」の一部情報は、必要によって省略され得る。
例えば、「finalizationRequest」に含まれている第2SSPの署名情報は、場合によって省略され得る。
また、例えば、「finalizationRequest」に含まれている時間情報は、場合によって省略され得る。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルの状態を「SUSPENSION」(若しくは、「IN TRANSITION」)状態に変更したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0179】
図12を参照すると、12030段階で、第1SSP1210は、第2SSP1260に「finalizationResponse」を伝達する。
例えば、第1SSP1210は、第1LBA1220と第2LBA1270を経て第2SSP1260に「finalizationResponse」を伝達する。
【0180】
図12を参照すると、12035段階で、第2SSP1260は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報が正しいか確認する過程をさらに含み得る。
【0181】
また、12035段階で、第2SSP1260は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP1260は、バンドルの状態を「Disabled」状態に変換する。
【0182】
図12を参照すると、12040段階で、第2SSP1260は、12035段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第2LBA1270に送信する。
【0183】
図13は、使用が中止されたバンドルをさらに使用可能にする手順の例を示す図である。
より詳しくは、「IN TRANSITION」状態や「SUSPENSION」状態にあるバンドルをさらに使用可能な状態で設定する手順の一例を示す図である。
【0184】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図13の例のように、第1端末1300は、第1LBA1320と第1SSP1310を含み、第2端末1350は、第2LBA1370と第2SSP1360を含む。
例えば、第1端末1300は、第1SSP1310が装着されて第1SSP1310を制御するための第1LBA1320が設置された端末であっても良く、第2端末1350は、第2SSP1360が装着されて第2SSP1360を制御するための第2LBA1370が設置された端末であっても良い。
【0185】
図13で開示した手順が行われる前のバンドルの状態が「IN TRANSITION」状態や「SUSPENSION」状態で設定されている場合の可能な例は、次の通りである。
例えば、図11に開示したバンドルの送信が仕上げられる段階で、11025段階が行われたが、11045段階が行われない場合、第1端末1300にあるバンドルの状態は「IN TRANSITION」状態で設定されているだろう。
また他の例で、図12に開示したバンドルの送信が仕上げられる段階で、12025段階が行われると、第1端末1300にあるバンドルの状態は、「IN TRANSITION」状態又は「SUSPENSION」状態で設定されているだろう。
【0186】
図13を参照すると、13000段階で、使用再開をリクエストするバンドルの情報を第2LBA1370に伝達する。
この伝達過程は、第2端末1350が提供するUIを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第2LBA1370に入力することもでき、又は第2LBA1370がリモートサーバーに接続して当該情報を読み取ることもできる。
【0187】
図13を参照すると、13005段階で、13000段階で選択されたバンドルの情報を第2LBA1370から第2SSP1360に伝達する。
この時、第2LBA1370から第2SSP1360に伝達する情報は、13000段階で選択されたバンドルを識別(identify)するための情報を含む。
図13を参照すると、13010段階で、第2SSP1360は、当該バンドルを削除する。
また、第2SSP1360は、「証明書」を生成する。
図13でこの証明書は、「recoveryRequest」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0188】
この時、可能な証明書構成の一例は、次の通りである。
・「recoveryRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「recoveryRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「recoveryRequest」は、符号550に第2SSPがバンドルを削除したことを意味する情報を含む。
・「recoveryRequest」は、符号520に第2SSPがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
・「recoveryRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0189】
図13を参照すると、13015段階で、第2SSP1360は、第1SSP1310に「recoveryRequest」を伝達する。
例えば、第2SSP1360は、第1SSP1310に次のような過程を経て「recoveryRequest」を伝達する。
すなわち、第2SSP1360は、第2LBA1370に13005段階の応答で「recoveryRequest」を伝達し、第2LBA1370は、第1LBA1320を経て第1SSP1310に「recoveryRequest」を伝達する。
【0190】
図13を参照すると、13020段階で、第1SSP1310は、受信した「recoveryRequest」を検証する。
この検証過程は、「recoveryRequest」に含まれた第2SSP1360の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「recoveryRequest」に含まれた「バンドル区分者」を確認する過程をさらに含み得る。
また、この検証過程は、「recoveryRequest」に含まれた「SSP識別子」を検査する過程をさらに含み得る。
また、この検証過程は、「recoveryRequest」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
【0191】
また、13020段階で、第1SSP1310は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)で変更する。
例えば、図に示したように、第1SSP1310は、バンドルの状態を「Disabled」状態で変換する。
図13を参照すると、13025段階で、第1SSP1310は、13020段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第1LBA1320に送信する。
【0192】
図14は、使用が中止されたバンドルをさらに使用可能にするまた他の手順の例を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図14の例のように、第1端末1400は、第1LBA1420と第1SSP1410を含み、第2端末1450は、第2LBA1470と第2SSP1460を含む。
例えば、第1端末1400は、第1SSP1410が装着されて第1SSP1410を制御するための第1LBA1420が設置された端末であっても良く、第2端末1450は、第2SSP1460が装着されて第2SSP1460を制御するための第2LBA1470が設置された端末であっても良い。
【0193】
図14で開示した手順が行われる前のバンドルの状態が「IN TRANSITION」状態や「SUSPENSION」状態で設定されている場合の可能な例は、次の通りである。
例えば、図11に開示したバンドルの送信が仕上げられる段階で、11025段階が行われたが11045段階が行われない場合、第1端末1400にあるバンドルの状態は、「IN TRANSITION」状態で設定されているだろう。
また他の例で、図12に開示したバンドルの送信が仕上げられる段階で、12025段階が行われると、第1端末1400にあるバンドルの状態は、「IN TRANSITION」状態又は「SUSPENSION」状態で設定されているだろう。
【0194】
図14を参照すると、14000段階で、使用再開をリクエストするバンドルの情報が第2LBA1470に伝達される。
この伝達過程は、第2端末1450が提供するUIを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第2LBA1470に入力することもでき、又は第2LBA1470がリモートサーバーに接続して当該情報を読み取ることもできる。
【0195】
図14を参照すると、14005段階から14000段階で選択されたバンドルの情報が第2LBA1470から第2SSP1460に伝達する。
この時、第2LBA1470から第2SSP1460に伝達される情報は、14000段階で選択されたバンドルを識別(identify)するための情報を含む。
【0196】
図14を参照すると、14010段階で、第2SSP1460は、当該バンドルの状態を「IN TRANSITION」状態で設定する。
また、第2SSP1460は、当該バンドルの状態変更に関連する「証明書」を生成する。
図14で、この証明書は、「recoveryRequest」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0197】
この時、可能な証明書構成の一例は、次の通りである。
・「recoveryRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「recoveryRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「recoveryRequest」は、符号550に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「recoveryRequest」は、符号520に第2SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「recoveryRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0198】
図14を参照すると、14015段階で、第2SSP1460は、第1SSP1410に「recoveryRequest」を伝達する。
例えば、第2SSP1460は、第1SSP1410に次のような過程を経て「recoveryRequest」を伝達する。
すなわち、第2SSP1460は、第2LBA1470に14005段階の応答で「recoveryRequest」を伝達し、第2LBA1470は、第1LBA1420を経て第1SSP1410に「recoveryRequest」を伝達する。
【0199】
図14を参照すると、14020段階で、第1SSP1410は、受信した「recoveryRequest」を検証する。
この検証過程は、「recoveryRequest」に含まれた第2SSP1460の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「recoveryRequest」に含まれた「バンドル区分者」を確認する過程をさらに含み得る。
また、この検証過程は、「recoveryRequest」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「recoveryRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更するものであるかを確認する過程をさらに含み得る。
【0200】
また、14020段階で、第1SSP1410は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第1SSP1410は、バンドルの状態を「Disabled」状態に変換する。
【0201】
また、14020段階で、第1SSP1410は、「証明書」を生成する。
図14で、この証明書は、「recoveryResponse」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0202】
この時、可能な証明書構成の一例は、次の通りである。
・「recoveryResponse」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「recoveryResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「recoveryResponse」は、符号550に第1SSPがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「recoveryResponse」は、符号520に第1SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「recoveryResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0203】
また、可能な証明書構成の他の例は、次の通りである。
・「recoveryResponse」は、符号530に受信した「recoveryRequest」を含む。
この時、受信した「recoveryRequest」の一部情報は、必要によって省略され得る。
例えば、「recoveryRequest」に含まれている第2SSPの署名情報は場合によって省略され得る。
また、例えば、「recoveryRequest」に含まれている時間情報は、場合によって省略され得る。
・「recoveryResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「recoveryResponse」は、符号550に第1SSPがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「recoveryResponse」は、符号520に第1SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「recoveryResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0204】
図14を参照すると、14025段階で、第1SSP1410は、第2SSP1460に「recoveryResponse」を伝達する。
例えば、第1SSP1410は、第1LBA1420と第2LBA1470を経て第2SSP1460に「recoveryResponse」を伝達する。
【0205】
図14を参照すると、14030段階で、第2SSP1460は、受信した「recoveryResponse」を検証する。
この検証過程は、「recoveryResponse」に含まれた第1SSP1460の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「recoveryResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「recoveryResponse」に含まれた「recoveryRequest」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「recoveryResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「recoveryResponse」に含まれたコマンド情報が正しいコマンド情報であるか確認する過程をさらに含み得る。
【0206】
また、14030段階で、第2SSP1460は、検証を済んだ後のバンドルを削除する。
図14を参照すると、14035段階で、第2SSP1460は、14030段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第2LBA1470に送信する。
【0207】
図15は、使用が中止されたバンドルをさらに使用可能にするまた他の手順の例を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図15の例のように、第1端末1500は、第1LBA1520と第1SSP1510を含み、第2端末1550は、第2LBA1570と第2SSP1560を含む。
例えば、第1端末1500は、第1SSP1510が装着されて第1SSP1510を制御するための第1LBA1520が設置された端末であっても良く、第2端末1550は、第2SSP1560が装着されて第2SSP1560を制御するための第2LBA1570が設置された端末であっても良い。
【0208】
図15で開示した手順が行われる前のバンドルの状態が「IN TRANSITION」状態や「SUSPENSION」状態で設定されている場合の可能な例は、次の通りである。
例えば、図11に開示したバンドルの送信が仕上げられる段階で、11025段階が行われたが11045段階が行われない場合、第1端末1500にあるバンドルの状態は「IN TRANSITION」状態で設定されているだろう。
また他の例で、図12に開示したバンドルの送信が仕上げられる段階で、12025段階が行われると、第1端末1500にあるバンドルの状態は「IN TRANSITION」状態又は「SUSPENSION」状態に設定されているだろう。
【0209】
図15を参照すると、15000段階で、使用再開をリクエストするバンドルの情報が第2LBAに伝達される。
この伝達過程は、第2端末1550が提供するUIを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第2LBA1570に入力することもでき、又は第2LBA1570がリモートサーバーに接続して当該情報を読み取ることもできる。
【0210】
図15を参照すると、15005段階で、15000段階で選択されたバンドルの情報を第2LBA1570から第2SSP1560に伝達する。
この時、第2LBA1570から第2SSP1560に伝達する情報は、15000段階で選択されたバンドルを識別(identify)するための情報を含み得る。
図15を参照すると、15010段階で、第2SSP1560は、当該バンドルの状態を「SUSPENSION」に変更する。
この時、図には示さなかったが、前述した「SUSPENSION」状態は、「IN TRANSITION」状態に取り替えられる。
【0211】
また、第2SSP1560は、「証明書」を生成する。
図15で、この証明書は、「recoveryRequest」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0212】
この時、可能な証明書構成の一例は、次の通りである。
・「recoveryRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「recoveryRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「recoveryRequest」は、符号550に第2SSPがバンドルの状態を「SUSPENSION」や「IN TRANSITION」に変更したことを意味する情報を含む。
・「recoveryRequest」は、符号520に第2SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「recoveryRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0213】
図15を参照すると、15015段階で、第2SSP1560は、第1SSP1510に「recoveryRequest」を伝達する。
例えば、第2SSP1560は、第1SSP1510に次のような過程を経て「recoveryRequest」を伝達する。
すなわち、第2SSP1560は、第2LBA1570に15005段階の応答で「recoveryRequest」を伝達し、第2LBA1570は、第1LBA1520を経て第1SSP1510に「recoveryRequest」を伝達する。
【0214】
図15を参照すると、15020段階で、第1SSP1510は、受信した「recoveryRequest」を検証する。
この検証過程は、「recoveryRequest」に含まれた第2SSP1560の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「recoveryRequest」に含まれた「バンドル区分者」を確認する過程をさらに含み得る。
また、この検証過程は、「recoveryRequest」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「recoveryRequest」に含まれたコマンド情報がバンドルの状態を正しく変更することか確認する過程をさらに含み得る。
【0215】
また、15020段階で、第1SSP1510は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)で変更する。
例えば、図に示したように、第1SSP1510は、バンドルの状態を「Disabled」状態に変更する。
図15を参照すると、15025段階で、第1SSP1510は、15020段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第1LBA1520に送信する。
【0216】
図16は、本発明の実施形態による端末の概略構成を示すブロック図である。
図16に示すように、端末は、送受信部(Transceiver)1610及び少なくとも一つのプロセッサ1620を含む。
また、端末は、SSP1630をさらに含む。
【0217】
例えば、SSP1630は、端末に挿入することもでき、端末に内蔵されることもできる。
少なくとも一つ以上のプロセッサ1620は、「制御部」として名付けることもできる。
ただ、端末の構成は、図16に制限されず、図16に示した構成要素より多い構成要素を含むか、より少ない構成要素を含むこともできる。
一実施形態によれば、送受信部1610、少なくとも一つのプロセッサ1620、及びメモリ(図示せず)は、一つのチップ(Chip)形態で具現され得る。
また、SSP1630が内蔵される場合、SSP1630を含み、一つのチップ形態で具現され得る。
【0218】
一実施形態によれば、送受信部1610は、他の端末の送受信部又は外部サーバーと本発明の実施形態による信号、情報、データなどを送信及び受信する。
送受信部1610は、送信される信号の周波数を上昇変換(up converting)及び増幅するRF送信機と、受信される信号を低雑音増幅して周波数を下降変換(down converting)するRF受信機などで構成される。
ただ、これは送受信部1610の一実施形態だけであって、送受信部1610の構成要素がRF送信機及びRF受信機に限定されることではない。
また、送受信部1610は、無線チャンネルを介して信号を受信して、少なくとも一つのプロセッサ1620に出力し、少なくとも一つのプロセッサ1620から出力された信号を、無線チャンネルを介して送信する。
【0219】
一実施形態によれば、送受信部1610は、他の端末の送受信部又は外部サーバーから他の端末に含まれたSSPの情報、他の端末を認証することができる認証情報、自分を認証することができる認証情報、バンドル移動コード、バンドル移動設定、バンドル、図10図15で記載した多様な証明書などを送信するか、受信する。
【0220】
一方、少なくとも一つのプロセッサ1620は、端末を全般的に制御するための構成要素である。
少なくとも一つのプロセッサ1620は、上述のような本発明の多様な実施形態によって、端末の全般的な動作を制御する。
一方、SSP1630は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置され得る。
【0221】
一実施形態によれば、SSP1630内の少なくとも一つのプロセッサ又はコントローラーは、バンドル移動設定を確認して、特定バンドルを送信するかどうかを決定する。
また、バンドル移動設定を確認して、当該バンドルが複数の端末で重複使用が可能であるかどうかを確認する。
また、一実施形態によれば、SSP内の少なくとも一つ以上のプロセッサ又はコントローラーは、バンドル移動コードを生成して特定バンドルの送信過程を制御する。
【0222】
また、一実施形態によれば、SSP内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分のSSP情報を生成し、外部から送信された他のSSPのSSP情報を確認して検証する。
また、一実施形態によれば、SSP内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分を検証することができる認証情報を生成し、外部から送信された他のSSPの認証情報を検証する。
【0223】
また、一実施形態によれば、SSP1330は、バンドルを生成し、単独又は一つ以上のプロセッサ1620と協力してバンドルを設置する。
また、SSP1630は、バンドルを管理する。
また、一実施形態によれば、SSP1630は、図10図15で記載した多様な形態の証明書を生成し、受信した証明書を検証する。
また、一実施形態によれば、SSP1630は、図10図15で記載したように受信した証明書の内容に基づいてバンドルの状態を変更する。
また、一実施形態によれば、SSP1630は、プロセッサ1620の制御によって動作する。
又は、SSP1630は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置されても良い。
アプリケーションの一部又は全部は、SSP1630又はメモリ(図示せず)に設置することもできる。
【0224】
一方、端末は、メモリ(図示せず)をさらに含み、端末の動作のための基本プログラム、アプリケーション、設定情報などのデータを記憶する。
また、メモリは、フラッシュメモリタイプ(Flash Memory Type)、ハードディスクタイプ(Hard Disk Type)、マルチメディアカードマイクロタイプ(Multimedia Card Micro Type)、カードタイプのメモリ(例えば、SD又はXDメモリなど)、磁気メモリ、磁気ディスク、光ディスク、RAM(Random Access Memory)、SRAM(Static Random Access Memory)、ROM(Read-Only Memory)、PROM(Programmable Read-Only Memory)、EEPROM(Electrically Erasable Programmable Read-Only Memory)の内の少なくとも一つの記憶媒体を含み得る。
また、プロセッサ1620は、メモリに記憶された各種プログラム、コンテンツ、データなどを用いて多様な動作を行う。
【0225】
図17は、図6で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図17は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順の他の例を示す図であるである。
【0226】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図17の例のように、第1端末1700は、第1LBA1720と第1SSP1710を含み、第2端末1750は、第2LBA1770と第2SSP1760を含む。
例えば、第1端末1700は、第1SSP1710が装着されて第1SSP1710を制御するための第1LBA1720が設置された端末であっても良く、第2端末1750は、第2SSP1760が装着されて第2SSP1760を制御するための第2LBA1770が設置された端末であっても良い。
【0227】
1.〔バンドル設置〕
図17を参照すると、17000段階で、第2LBA1770と第2SSP1760は、互いに協業して第2端末1750にバンドルを設置する。
これに対する詳細な説明は、図9の「バンドル設置」過程を参照する。
【0228】
2.〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第2LBA1770及び/又は第2SSP1760は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができ、これに対する詳細な説明は、図9の「重複使用可能であるかどうか確認」過程を参照する。
【0229】
3.〔バンドル状態設定〕
もし当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第2LBA1770及び/又は第2SSP1760が当該バンドルを重複使用するかどうかを判断しない場合にも、第2LBA1770及び/又は第2SSP1760の具現によって下記のようにバンドルの状態を追加的に設定する過程が行われる。
【0230】
図17を参照すると、17005段階で、第2SSP1760は、当該バンドルの状態を「IN TRANSITION」に設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されたが使用が不可能な状態(さらに、「他の端末のリクエスト(例えば、「finalizationResponse」や「recoveryRequest」を送信することによって行われるリクエスト)」及び/又は「外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態(Disabled、Enable、Active状態)に変更されることができる状態)を意味する。
【0231】
図17を参照すると、17010段階で、第2LBA1770は、第2SSP1760に「証明書」をリクエストする。
図17を参照すると、17015段階で、第2SSP1760は、「証明書」を生成する。
図17で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0232】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、符号540に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、符号550に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、符号520に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「finalizationRequest」は、符号560に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0233】
図17を参照すると、17020段階で、第2SSP1760は、第1SSP1710に「finalizationRequest」を伝達する。
例えば、第2SSP1760は、第1SSP1710に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP1760は、第2LBA1770に17010段階の応答で「finalizationRequest」を伝達し、第2LBAは、第1LBA1720を経て第1SSPに「finalizationRequest」を伝達する。
【0234】
図17を参照すると、17025段階で、第1SSP1710は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0235】
また、17025段階で、第1SSP1710は、バンドルを削除する。
【0236】
また、17025段階で、第1SSP1710は、「証明書」を生成する。
図17で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0237】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0238】
また、可能な証明書構成の他の例は、次の通りである。
・「finalizationResponse」は、符号530に「finalizationRequest」の一部及び/又は全体データを含む。
・「finalizationResponse」は、符号540に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、符号550に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、符号520に第1SSPがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「finalizationResponse」は、符号560に第1SSPの署名情報を含む。
この署名は、上述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0239】
図17を参照すると、17030段階で、第1SSP1710は、第2SSP1760に「finalizationResponse」を伝達する。
例えば、第1SSP1710は、第1LBA1720と第2LBA1770を経て第2SSP1760に「finalizationResponse」を伝達する。
【0240】
図17を参照すると、17035段階で、第2SSP1760は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」の一部及び/又は全体情報が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
【0241】
また、17035段階で、第2SSP1760は、バンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP1760は、バンドルの状態を「Disabled」状態に変換する。
【0242】
また、17035段階で、第2SSP1760は、「証明書」を生成する。
図17で、この証明書は、「spblAttestation」と呼ばれる。
この証明書の構造は、図5に開示した構造による。
【0243】
この時、可能な証明書構成の一例は、次の通りである。
・「spblAttestation」は、符号510(以下、図5参照)に当該バンドルの「バンドル区分者」を含む。
・「spblAttestation」は、符号540に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は、符号550に第2SSPがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「spblAttestation」は、符号520に第2SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「spblAttestation」は、符号560に第2SSPの署名情報を含む。
この署名は、上述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0244】
また、可能な証明書構成の他の例は、次の通りである。
・「spblAttestation」は、符号530に「finalizationRequest」及び/又は「finalizationResponse」の一部及び/又は全体データを含む。
・「spblAttestation」は、符号540に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は符号550に第2SSPがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「spblAttestation」は、符号520に第2SSPがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「spblAttestation」は、符号560に第2SSPの署名情報を含む。
この署名は、上述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0245】
図17を参照すると、17040段階で、第2SSP1760は、第1SSP1710に「spblAttestation」を伝達する。
例えば、第2SSP1760は、第2LBA1770と第1LBA1720を経て第1SSP1710に「spblAttestation」を伝達する。
【0246】
図17を参照すると、17045段階で、第1SSP1710は、受信した「spblAttestation」を検証する。
この検証過程は、「spblAttestation」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「spblAttestation」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれた「finalizationRequest」及び/又は「finalizationResponse」の一部及び/又は全体情報が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれたコマンド情報がバンドルの状態を使用可能な状態に変更することであるかを確認する過程をさらに含み得る。
【0247】
また、17045段階で、第1SSP1710は、「finalizationResponse」を削除する。
【0248】
17035段階で、「spblAttestation」を生成する段階及び/又は17040段階及び/又は17045段階は、必要によって省略され得る。
17020段階及び/又は17030段階及び/又は17040段階で、証明書送信が失敗時の当該証明書は、相手機器に再送信され得る。
【0249】
この時、再送信は、予め設定されている最大再送信回数ほど試みられる。
若しくは、当該証明書が相手の端末で送信されたことを確認するまで繰り返されて試みられる。
若しくは、端末の具現によって当該証明書が削除されるまで繰り返されて再送信することもできる。
例えば、「finalizationResponse」の場合、17045段階で削除される前まで、第1端末は、「finalizationResponse」の再送信を繰り返して試みる。
【0250】
再送信を試行の際、2つの機器の間の接続が切れた状態であれば2つの機器は新たに接続を形成した後の当該証明書を送受信する。
この時、2つの端末は、過去通信をして送受信した記録を用い、新たに確立される接続の対象を選択及び/又は検証し、新たに接続が確立された相手とどんなデータを送受信しなければならないかを決定し、また、相手の端末から受信したデータの有効性及び/又は内容を検証する。
この時、再送信は、端末内部の動作によって自動で開始され、外部サーバーのリクエストによっても開始され、若しくは、ユーザの入力によっても開始され得る。
【0251】
図18は、本発明の一実施形態による「証明書(Attestation)」の構成を示す図である。
一実施形態によれば、証明書は、「証明書情報(Attestation Info)」を選択的に含む(符号1810)。
証明書情報に含まれるデータの多様な実施形態は、後述する図22図27の説明を参照する。
【0252】
一実施形態によれば、証明書は、「証明書を発給した主体の識別子(Issuer ID)」を選択的にさらに含む(符号1830)。
証明書を発給する主体の多様な実施形態は、後述する図22図27の説明を参照する。
一実施形態によれば、証明書は、「証明書発給者が行なった動作に対する情報(Command)」を選択的にさらに含む(符号1850)。
証明書発給者が行う動作の多様な実施形態は、後述する図22図27の説明を参照する。
一実施形態によれば、証明書は、上述した情報以外のその他データを選択的にさらに含む(符号1870)。
証明書の内に含まれることができるその他データの多様な実施形態は、後述する図22図27の説明を参照する。
一実施形態によれば、証明書は、上述した情報に対する電子署名データを含む(符号1890)。
この署名データは、証明書発給者の署名用認証書によって生成された電子署名であっても良い。
【0253】
図19は、本発明の実施形態による一つの端末から他の端末にバンドルが送信される手順を概念的に示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図19の例のように、第1端末1900は、第1LBA1920と第1SSP1910を含み、第2端末1950は、第2LBA1970と第2SSP1960を含む。
例えば、第1端末1900は、第1SSP1910が装着されて第1SSP1910を制御するための第1LBA1920が設置された端末であっても良く、第2端末1950は、第2SSP1960が装着されて第2SSP1960を制御するための第2LBA1970が設置された端末であっても良い。
【0254】
図19を参照すると、19000段階で、第1端末1900の第1SSP1910、第1LBA1920と第2端末1950の第2LBA1970は、バンドル送信のために必要な準備手順(バンドル送信準備手順)を行う。
上記手順に対するより詳しい説明は、後述する図20の詳細説明を参照する。
【0255】
図19を参照すると、19005段階で、第1端末1900から第2端末1950にバンドルが送信される手順(バンドル送信手順)が行われる。
上記手順に対するより詳しい説明は、後述する図21の詳細説明を参照する。
【0256】
図19を参照すると、19010段階で、第1端末1900と第2端末1960は、送信されたバンドルの設置手順とバンドルの状態を設定する手順(バンドル送信仕上げ手順)を行う。
上記手順に対する詳しい説明は、後述する図22図24、及び図26の詳細説明を参照する。
【0257】
図20は、図19で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。
より詳しくは、図20は、本発明の実施形態による一つの端末が他の端末にバンドルを送信するために必要な準備過程を経る手順を例示的に示す図である。
本明細書で、図20の手順は、バンドル送信準備手順と指称される。
【0258】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図20の例のように、第1端末2000は、第1LBA2020と第1SSP2010を含み、第2端末2050は、第2LBA2070と第2SSP2060を含む。
例えば、第1端末2000は、第1SSP2010が装着されて第1SSP2010を制御するための第1LBA2020が設置された端末であっても良く、第2端末2050は、第2SSP2060が装着されて第2SSP2060を制御するための第2LBA2070が設置された端末であっても良い。
【0259】
一実施形態によれば、第1端末2000は、予め設置されたバンドルを保有しても良く、このバンドルと関連したメタデータをさらに保有しても良い。
一実施形態によれば、第1端末2000は、当該バンドルと関連してバンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、又はバンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つを保有しても良い。
【0260】
一実施形態によれば、第1端末2000は、当該バンドルと関連して「バンドル移動設定」を保有しても良い。
バンドル移動設定は、当該バンドルの機器の間の送信可能であるかどうかに関連する情報を選択的に含み得る。
また、バンドル移動設定は、当該バンドルの機器の間の送信結果をサーバーに登録する過程に対する「登録設定」を選択的にさらに含み得る。
可能な「登録設定」の多様な例示は、次の通りである。
【0261】
・〔告知(Notification)必要であるかどうか〕
機器の間のバンドル送信結果をサーバーに告知しなければならないかに対する設定。
・〔線告知(Pre-notification)必要であるかどうか〕
当該バンドルが一つの機器から新しい機器に送信された後の新しい機器で用いられる前、この送信内訳がサーバーに告知されなければならないか、若しくは、この送信内訳がサーバーに告知される前の新しい機器で用いられることができるかに対する設定。
・〔告知内容の暗号が化必要であるかどうか〕
告知をする過程で送信されるデータが告知を受けるサーバーと告知するSSPだけが内容を見られるように暗号化される必要があるかに対する設定。
【0262】
「登録設定」は、サービス提供者によって設定することもでき、バンドル管理サーバーによって設定することもでき、若しくは、サービス提供者とバンドル管理サーバーの協業によって設定することもできる。
また、このバンドル移動設定は、バンドル内部のデータで含まれることもでき、バンドルのメタデータの内に含まれていることもでき、若しくは、独立されたデータで存在することもできる。
また、バンドル移動設定は、サービス提供者及び/又はバンドル管理サーバーの電子署名を含み得る。
【0263】
図20を参照すると、20000段階で、機器の間の送信されるバンドルの情報を第1LBA2020に伝達する。
この伝達過程は、例えば、図20に示したように、第1端末2000が提供するUIを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第1LBA2020に入力することもでき、又は第1LBA2020がリモートサーバーに接続して当該情報を読み取ることもできる。
【0264】
図20を参照すると、20005段階で、20000段階を介して選択されたバンドルに関連する情報が第1LBA2020から第1SSP2010に伝達される。
例えば、図20に示したように、選択されたバンドルに関連する情報が「Select SPB command」を介して第1LBA2020から第1SSP2010に伝達される。
この時、第1LBA2020から第1SSP2010に伝達する情報は、20000段階で選択されたバンドルを識別(identify)するための情報を含む。
【0265】
図20を参照すると、20010段階で、第1SSP2010は、送信をリクエストされたバンドルの機器の間で送信可能であるかどうかを確認する。
この過程は、先ず20005段階で受信した情報に基づいて送信をリクエストされたバンドルを識別し、当該バンドルと関連した(associated with)「バンドル移動設定」を確認することによって行われる。
また、20010段階で、第1SSP2010は、選択的に「バンドル移動コード」を設定する。
「バンドル移動コード」は、当該バンドルの機器の間の送信過程で当該バンドルを指称するために用いられるコードとして、当該バンドルを識別することができる値ではなければならない。
第1SSP2010は、上述した「バンドル移動コード」と送信しようとするバンドルの情報をバインディング(binding)する。
【0266】
図20を参照すると、20015段階で、20005段階に対する応答結果が第1SSP2010から第1LBA2020に送信される。
例えば、図20に示したように、「Select SPB command」に対する応答を「Select SPB response」を介して第1SPB2010から第1LBA2020に伝達する。
この応答値は、20010段階で記載した「バンドル移動コード」を含み得る。
【0267】
図20を参照すると、20020段階から機器の間のバンドル送信のために必要な情報が第1端末2000の第1LBA2020から第2端末2050の第2LBA2070に伝達される。
この時、第1LBA2020から第2LBA2070に伝達する情報には「バンドル移動コード」が含まれ得る。
また、第1LBA2020から第2LBA2070に伝達される情報は、今後の20025段階で第1LBA720と第2LBA2070の間に確立される(established)接続のために必要な情報を選択的にさらに含み得る。
【0268】
上述した20020段階を介して第1LBA2020から第2LBA2070に伝達される情報は、多様な方法で伝達することができる。
例えば、第1LBAは、第2LBAに伝達しなければならない情報を第1端末2000のUIを介してユーザに提供し、ユーザは提供された情報を第2端末2050のUIを用いて第2LBAに入力する。
若しくは、第1LBAは、第2LBAで伝達しなければならない情報をイメージ(例えば、QRコード(登録商標))の形態で作成して第1端末の画面に表示し、ユーザは第2端末2050を用いてこのイメージをスキャンすることによって第2LBA2070に情報を伝達する。
しかし、第1LBA2020から第2LBA2070に情報を伝達する方法は、上記の方法に限らない。
【0269】
図20を参照すると、20025段階で、第1LBA2020と第2LBA2070の間に接続が確立(又は、設定)される。
もし、20020段階で接続のために必要な情報が送信されると、第1LBA2020と第2LBA2070は、この情報を用いて接続を確立することもできる。
第1LBA2020と第2LBA2070の接続は、直接的な機器の間の接続であっても良く(例えば、NFC、ブルートゥース(登録商標)、UWB、WiFi-Direct、「LTE D2D」(device-to-device)、「5G D2D」)又は第1LBA2020と第2LBA2070の間にリモートサーバー(例えば、リレーサーバー)が位置した遠距離接続であっても良い。
【0270】
図20を参照すると、20025段階は、最後の段階として図に示したがこの段階は前述の他の段階、すなわち、20000段階、20005段階、20010段階、20015段階、20020段階とは独立的な段階として他の段階と手順に関わらず行うことができる。
例えば、20025段階は、20015段階と20020段階の間で行うこともでき、この場合、20020段階で第1LBA2020から第2LBA22070に送信される情報は、20025段階で確立された接続を介して送信される。
【0271】
図21は、図19で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図である。
より詳しくは、図21は、本発明の実施形態による一つの端末が他の端末でバンドルを送信する手順を例示的に示す図である。
本発明で図21の手順は、バンドル送信手順と指称される。
【0272】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図21の例のように、第1端末2100は、第1LBA2120と第1SSP2110を含み、第2端末2150は、第2LBA2170と第2SSP2160を含む。
例えば、第1端末2100は、第1SSP2110が装着されて第1SSP2110を制御するための第1LBA2120が設置された端末であっても良く、第2端末2150は、第2SSP2160が装着されて第2SSP2160を制御するための第2LBA2170が設置された端末であっても良い。
【0273】
図21を参照すると、21000段階で、第2LBA2170は、第2SSP22160に「SSP情報(SspInfo)」をリクエストする。
21000段階で、第2LBA2170が第2SSP2160に「SSP情報(SspInfo)」をリクエストする時、第2LBA2170は、第2SSP2160に機器の間のバンドル移動が行われることを知らせる。
【0274】
また、21000段階は、図21で図に示した過程に続いて直ちに自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第2端末2150が提供するUIを介してユーザが直接送信を受けるバンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第2LBA2170に入力することもでき、又は第2LBA2170がリモートサーバーに接続して当該情報を読み取ることもできる。
【0275】
図21を参照すると、21005段階で、第2SSP2160は、自分の「SSP情報」を生成する。
「SSP情報」にはバンドル送信のために提供されなければならない第2SSPの情報が含まれる。
この時、「SSP情報」には第2SSP2160がバンドルを受信する前に経なければならない認証書交渉過程のための情報(認証書交渉情報)が含まれる。
この「認証書交渉情報」は、第2SSP2160が異なるSSPを検証するのに用いられる認証書情報(SenderSpblVerification)と異なるSSPが自分を検証するのに用いられる認証書情報(ReceiverSpblVerification)を含む。
また、「認証書交渉情報」は、第2SSP2160がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第2SSP2160がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また、「SSP情報」には第2SSP2160が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むSSPバージョン情報が選択的にさらに含まれ得る。
【0276】
図21を参照すると、21010段階で、第2SSP2160は、第2LBA2170と第1LBA2120を経て第1SSP2110に21005段階で生成した「SSP情報」を伝達する。
以上、記載した21000段階と21010段階によると、第2LBA2170が第2SSP2160に「SSP情報(SspInfo)」をリクエストし、第2SSP2160が自分の「SSP情報」を生成した後、第2SSP2160が第2LBA2170と第1LBA2120を経て第1SSP2110に「SSP情報」を伝達する。
しかし、実施形態によっては、第2端末2150が第1端末2100に「SSP情報」の伝達する過程は、次の通りである。
例えば、第2LBA2170が自ら「SSP情報」を生成した後に、第1LBA2120を経て第1SSP2110に「SSP情報」を伝達する。
【0277】
図21を参照すると、21015段階で、第1SSP2110は、受信した「SSP情報」を確認し、この情報に基づいて自分を認証することができる「第1端末認証情報(Device 1.Auth」を生成する。
この過程に対するより具体的な手順は、次の通りである。
【0278】
第1SSP2110は、受信した「SenderSpblVerification」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書(ssp1.Cert.KA)を選択する。
若しくは、第1SSP2110は、受信した「第2SSP2160がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「ssp1.ePK.KA」と秘密鍵「ssp1.ePK.KA」を生成した後、この鍵の対の内の公開鍵(ssp1.ePK.KA)を選択する。
また、第1SSP2110は、受信した「SenderSpblVerification」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の署名用認証書(ssp1.Cert.DS)をさらに選択する。
【0279】
また、第1SSP2110は、受信した「ReceiverSpblVerification」を用いて検証を行う第2SSP2160の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「CiPkIdToBeUsed」で設定する。
また、第1SSP2110は、受信した「第2SSP2160がサポートする暗号化アルゴリズムのリスト」を用いて今後に用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「CryptoToBeUsed」で設定する。
また、第1SSP2110は、受信した「第2SSP2160が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認して、そのうちに自身もサポートする標準規格のバージョンが存在するかを確認する。
【0280】
「第1端末認証情報(Device 1.Auth)」は、前述した「ssp1.Cert.KA」、「ssp1.ePK.KA」「CiPkIdToBeUsed」、「CryptoToBeUsed」の内の少なくとも一つを含む。
また、「第1端末認証情報(Device 1.Auth)」は、前述した「ssp1.Cert.DS」を選択的にさらに含み得る。
また、「第1端末認証情報(Device1.Auth」は、今後に送信されるバンドルに関連したバンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つを選択的にさらに含み得る。
【0281】
この時、上記で言及した「第1端末認証情報(Device 1.Auth」の一部又は全体は、情報の無欠性を保障するために「ssp1.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは「第1端末認証情報」の一部として追加される。
【0282】
図21を参照すると、21020段階で、第1SSP2110は、第1LBA2120を経て第2LBA2170に21015段階で生成した「第1端末認証情報(Device 1.Auth)」を伝達する。
図21を参照すると、21025段階で、第2LBA2170は、第2SSP2160に「第1端末認証情報(Device 1.Auth)」を伝達する。
また、第2LBA2170は、第2SSP2160に「バンドル移動コード」をさらに伝達する。
【0283】
図21を参照すると、21030段階で、第2SSP2160は、受信した「第1端末認証情報(Device 1.Auth)」を検証する。
若し、第2SSP2160が「ssp1.Cert.KA」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第2SSP2160に「ssp1.ePK.KA」とこれに対するデジタル署名が送信された場合には、先ず、「ssp1.Cert.DS」の有効性を検査した後、この認証書を用いてデジタル署名を確認して受信した公開鍵「ssp1.ePK.KA」の無欠性を確認する。
また、第2SSP2160は、受信した「CiPkIdToBeUsed」を確認して自分を検証することができる少なくとも一つ以上の署名用認証書(ssp2.Cert.DS)を選択する。
【0284】
また、図には示していないが、21030段階で、第2SSP2160は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)で公開鍵「ssp2.ePK.KA」と秘密鍵「ssp2.eSK.KA」を生成した後、この鍵の対の内の公開鍵(ssp2.ePK.KA)を選択する。
また、第2SSP2160は、「ssp1.Cert.KA」に含まれている鍵合意用公開鍵や「ssp1.ePK.KA」の内の一つを選択した後、この値と「ssp2.eSK.KA」を用いて今後に端末1との通信の内の暗号化に用いられるセッション鍵「ShKey01」を生成する。
「ShKey01」は、受信した「CryptoToBeUsed」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
【0285】
また、21030段階で、第2SSP2160は、自分を認証することができる「第2端末認証情報(Device 2.Auth)」を生成する。
この時、「第2端末認証情報(Device 2.Auth)」は、「ssp2.Cert.DS」を含む。
また、「第2端末認証情報(Device 2.Auth)」は、「ssp2.ePK.KA」をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、SSP22160によって生成された現在セッションを指称するトランザクションアイディー(transaction ID)をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、「バンドル移動コード」をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、第2SSP2160のSSP識別子をさらに含み得る。
また、「第2端末認証情報(Device 2.Auth)」は、今後に送信されるバンドルに関連したバンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つを選択的にさらに含み得る。
【0286】
この時、上記で言及した「第2端末認証情報(Device 2.Auth)」の一部又は全体は、情報の無欠性を保障するために「ssp2.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「第2端末認証情報」の一部として追加される。
また、「第2端末認証情報(Device 2.Auth)」の一部又は全体は、先立って生成されたセッション鍵「ShKey01」を用いて暗号化される。
【0287】
図21を参照すると、21035段階で、第2SSP2160は、第2LBA2170と第1LBA2120を経て第1SSP2110に21030段階で生成した「第2端末認証情報(Device 2.Auth)」を伝達する。
この時、「バンドル移動コード」が選択的にさらに送信される。
【0288】
図21を参照すると、21040段階で、第1SSP2110は、受信した「第2端末認証情報(Device 2.Auth)」を検証する。
第1SSP2110は、受信した「ssp2.Cert.DS」の署名を検証して当該認証書の有効性を検証する。
また、第1SSP2110は、受信したバンドルファミリ識別子(SPB Family ID)及び/又はバンドルファミリ管理者識別子(SPB Family Custodian Object ID)が、自分が送信しようとするバンドルと関連して正しく設定された値であるかを検査する。
また、第1SSP2110は、受信したトランザクションアイディー(transaction ID)及び/又は第2SSP2160のSSP識別子を記憶する。
また、第1SSP2110は、受信したトランザクションアイディー(transaction ID)や第2SSP2160のSSP識別子を、現在進行しているセッション又は送信しようとするバンドルとバインディング(binding)させる。
【0289】
この過程で、若し、「第2端末認証情報(Device 2.Auth)」に暗号化されたデータが含まれている場合、第1SSP2110は、送信された「ssp2.ePK.KA」と自分の「ssp1.Cert.KA」に含まれている鍵合意用公開鍵に対応される秘密鍵や「ssp1.ePK.KA」を用いてセッション鍵「ShKey01」を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後に、検証過程を行う。
またこの過程で、若し、「第2端末認証情報(Device 2.Auth)」にデジタル署名が含まれている場合、第1SSP2110は、「ssp2.Cert.DS」を用いて受信したデジタル署名の有効性を検証する。
【0290】
また、21040段階で、図21には示していないが、第1SSP2110は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「ssp1.bundle.ePK.KA」と秘密鍵「ssp1.bundle.eSK.KA」を生成する。
この時、鍵の対「ssp1.bundle.ePK.KA」と「ssp1.bundle.eSK.KA」は、先立って生成された「ssp1.ePK.KA」と「ssp1.ePK.KA」と同一値で設定され得る。
又は、鍵の対「ssp1.bundle.ePK.KA」と「ssp1.bundle.eSK.KA」は、先立って用いられた「ssp1.Cert.KA」に含まれている公開鍵とここに対応する秘密鍵」同一値で設定することもできる。
また、第1SSP2110は、「ssp1.bundle.eSK.KA」と「ssp2.ePK.KA」を用いてセッション鍵「ShKey02」を生成する。
もし、「ssp1.bundle.eSK.KA」のために「ssp1.ePK.KA」又は「ssp1.Cert.Ka」に含まれている公開鍵に対応する秘密鍵が再使用されると、セッション鍵「ShKey02」の値も以前に生成された「ShKey01」の値に設定され得る。
【0291】
また、21040段階で、第1SSP2110は、第2端末2150で送信するバンドル及び/又はバンドルと関連したメタデータを構成する。
この時、第1SSP2110は、受信した「バンドル移動コード」を用いて自分が送信しようとするバンドルを識別する。
また、構成されるバンドルには「ssp1.Cert.DS」が含まれる。
また、構成されるバンドルには「ssp1.bundle.ePK.KA」がさらに含まれる。
また、構成されるバンドルは、当該セッションを識別するトランザクションアイディー(transaction ID)をさらに含み得る。
また、構成されるバンドルには送信されるバンドルと関連したバンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが選択的にさらに含まれ得る。
一実施形態によれば、21040段階で、構成されるバンドル(又は、バンドルと関連したメタデータ)のうちには「バンドル移動設定」が含まれる。
【0292】
一実施形態によれば、21040段階で、構成されるバンドルには「ssp1.Cert.DS」を用いて生成されたデジタル署名データが追加される。
すなわち、上記で明示したバンドルの構成要素一部又は全体に対して、生成されたデジタル署名データがバンドルの一部として追加される。
また、構成されるバンドルの一部又は全体は、「ShKey02」を用いて暗号化される。
【0293】
図21を参照すると、21045段階で、第1SSP2110は、第1LBA2120を経て第2LBA2170に21040段階で生成した(構成された)バンドルを伝達する。
この時、送信されるバンドルと関連したメタデータが選択的にさらに送信される。
また、送信されるバンドルと関連した「バンドル移動設定」がさらに送信される。
例えば、「バンドル移動設定」がバンドル又はメタデータに含まれず、別途のフォーマット(例えば、メッセージ)で送信され得る。
【0294】
図22は、図19で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。
図22は、バンドルの機器の間の送信内訳が
・先告知(Pre-notification)される必要がなく、
・告知内容の暗号化が必要又は必要ではない、
場合、適用される手順であっても良い。
【0295】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図22の例のように、第1端末2200は、第1LBA2220と第1SSP2210を含み、第2端末2250は、第2LBA2270と第2SSP2260を含む。
例えば、第1端末2200は、第1SSP2210が装着されて第1SSP2210を制御するための第1LBA2220が設置された端末であっても良く、第2端末2250は、第2SSP2260が装着されて第2SSP2260を制御するための第2LBA2270が設置された端末であっても良い。
【0296】
図22を参照すると、22000段階で次の手順が行われる。
1.〔バンドル設置〕
図22を参照すると、22000段階で、第2LBA2270と第2SSP2260は、互いに協業して第2端末2250にバンドルを設置する。
この過程で、次の手順が共に行われる。
もし、メタデータが送信された場合、第2LBA2270又は第2SSP2260は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第2LBA2270は、上記情報を第2SSP2260で伝達する。
もし、トランザクションアイディー(transaction ID)が送信されると、第2LBA2270又は第2SSP2260は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが送信されると、第2LBA2270又は第2SSP2260は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ssp1.Cert.DS」が送信されると、第2SSP2260は、この認証書の有効性を検証して第1SSP2210を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第2SSP2260は、送信された「ssp1.bundle.ePK.KA」と自分の「ssp2.eSK.KA」を用いてセッション鍵「ShKey02」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後に検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第2SSP2260は、「ssp1.Cer.DS」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
【0297】
2.〔「登録設定」確認〕
また、図には示してなかったが、第2LBA2270及び/又は第2SSP2260は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び/又は「先告知必要であるかどうか」及び/又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、22000段階の一部として22000段階で行われる他の手順と手順に関わらず独立的に行われ得る。
若しくは、22000段階以後、22035段階が仕上げられる前、判断が必要な瞬間に行うこともできる。
本図で後述する手順は、「登録設定」を確認した結果、バンドルの機器の間の送信内訳が先告知される必要がない時に適用される手順であり得る。
【0298】
図22を参照すると、22005段階で、第2SSP2260は、当該バンドルの状態を「IN TRANSITION」で設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されたがまだ使用が不可能な状態(さらに、「本図で後述する追加動作」及び/又は「(本発明では説明されなかったが)外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態(Disabled、Enable、Active状態)で変更することができる状態)を意味する。
【0299】
図22を参照すると、22010段階で、第2LBA2270は、第2SSP2260に「証明書」をリクエストする。
図22を参照すると、22015段階で、第2SSP2260は、「証明書」を生成する。
図22で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0300】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、図18の1符号850に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、図18の1870に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を作成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationRequest」は、図18の1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0301】
図22を参照すると、22020段階で、第2SSP2260は、第1SSP2210に「finalizationRequest」を伝達する。
例えば、第2SSP2260は、第1SSP2210に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP2260は、第2LBA2270に22010段階の応答で「finalizationRequest」を伝達し、第2LBA2270は、第1LBA2220を経て第1SSP2210に「finalizationRequest」を伝達する。
【0302】
図22を参照すると、22025段階で、第1SSP2210は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0303】
また、22025段階で、第1SSP2210は、検証を済んだ後のバンドルを削除する。
【0304】
また、22025段階で、第1SSP2210は、「証明書」を生成する。
図22で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0305】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「finalizationRequest」の一部及び/又は全体データを含む。
・「finalizationResponse」は、図18の符号1830に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、図18の符号1850に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、図18の符号1870に第1SSPがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationResponse」は、図18の符号1890に第1SSPの署名情報を含む。
この署名は、上述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0306】
図22を参照すると、22030段階で、第1SSP2210は、第2SSP2260に「finalizationResponse」を伝達する。
例えば、第1SSP2210は、第1LBA2220と第2LBA2270を経て第2SSP2260に「finalizationResponse」を伝達する。
【0307】
図22を参照すると、22035段階で、第2SSP2260は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」のデータ一部又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
【0308】
また、22035段階で、第2SSP2260は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP2260は、バンドルの状態を「Disabled」状態に変換する。
【0309】
また、22035段階で、第2SSP2260は、「証明書」を生成する。
図22で、この証明書は、「spblAttestation」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0310】
この時、可能な証明書構成の一例は、次の通りである。
・「spblAttestation」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、「finalizationRequest」及び/又は「finalizationResponse」の一部及び/又は全体データを含む。
・「spblAttestation」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は、図18の符号1850に第2SSPがバンドルを使用可能な状態の内の一つに変更したことを意味する情報を含む。
・「spblAttestation」は、図18の符号1870に第2SSPがバンドルの状態を使用可能な状態の内の一つに変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「spblAttestation」は、図18の符号1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0311】
また、22035段階で、第2SSP2260は、自分の「選択されたSSP情報(sspInforSelected」を生成する。
「選択されたSSP情報」には機器の間のバンドル送信結果をサーバーに告知するために提供されなければならない第2SSPの情報が含まれる。
【0312】
この時、「選択されたSSP情報」には認証書交渉過程のための情報(認証書交渉情報)が含まれる。
この「認証書交渉情報」は、
・第2SSP2260がサーバーを検証に用いることができる認証書情報(spbmVerification)、
・サーバーが第1SSP2210を検証に用いることができる認証書情報(SenderSpblVerification)、
・サーバーが第2SSP2260を検証に用いることができる認証書情報(ReceiverSpblVerification)、
などの情報を選択的に含み得る。
【0313】
また、「認証書交渉情報」は、第2SSP2260がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第2SSP2260がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また「選択されたSSP情報」には第2SSP2260が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むSSPバージョン情報が選択的にさらに含まれ得る。
【0314】
図22を参照すると、22040段階で、第2SSP2260は、22035段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第2LBA2270に送信する。
また、22035段階で生成された「選択されたSSP情報」が共に送信され得る。
22035段階で、「選択されたSSP情報」を生成する過程と22040段階で「選択されたSSP情報」を伝達する過程は、省略され得る。
【0315】
図23は、図22で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図23の例のように、第2端末2350は、第2LBA2370と第2SSP2360を含む。
例えば、第2端末2350は、第2SSP2360が装着されて第2SSP2360を制御するための第2LBA2370が設置された端末であっても良い。
【0316】
また、一実施形態によれば、サーバー2300は、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び/又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明では、サーバー2300を指称するためにサーバーの可能な例の内の一つであるSPBMという用語を用いる場合もあるが、前述したようにサーバーの種類は、SPBMに限らない。
【0317】
図23を参照すると、23000段階で、SPBM2300とLBA2370の間にTLS(Transport Layer Security)接続が形成(established)される。
本図では、23000段階が23005段階~23015段階以前に行われることとして記載しているが、23000段階は、23020段階が行われる前の23005段階~23015段階とは独立的に行うことができる。
例えば、23000段階は、23015段階と23020段階の間に行うこともできる。
【0318】
図23を参照すると、23005段階で、第2LBA2370は、第2SSP22360に「選択されたSSP情報(SspInfoSelected)」をリクエストする。
この時、23005段階は、自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第2端末2350が提供するUIを介してユーザから与えられることもでき、リモートサーバーからプッシュ入力を介して第2端末2350に与えられることもできる。
【0319】
図23を参照すると、23010段階で、第2SSP2360は、自分の「選択されたSSP情報」を生成する。
「選択されたSSP情報」に対する説明は、図22に記載した説明を参照する。
図23を参照すると、23015段階で、第2SSP2360は、第2LBA2370に23010段階で生成した「選択されたSSP情報」を送信する。
23005段階~23015段階は、選択的に行われないこともある。
【0320】
図23を参照すると、23020段階で、第2LBA2370は、サーバー2300に「選択されたSSP情報」を送信する。
もし、第2LBA2370が、図22の22035段階~22040段階を介して「選択されたSSP情報」を受信したか、若しくは図23の23005段階~23015段階を介して「選択されたSSP情報」を受信する場合、第2LBA2370は、サーバー2300に受信した「選択されたSSP情報」を送信する。
若し、第2LBA2370が「選択されたSSP情報」を受信しない場合、第2LBA2370は、「選択されたSSP情報」を生成してサーバー2300に送信する。
【0321】
図23を参照すると、23025段階で、サーバー2300は、受信した「選択されたSSP情報」を確認してこの情報に基づいて自分を認証することができる「サーバー認証情報(SPBM.Auth)」を生成する。
この過程に対するより具体的な手順は、次の通りである。
【0322】
サーバー2300は、受信した「spbmVerification」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書(spbm.Cert.KA)を選択する。
若しくは、サーバー2300は、受信した「第2SSP2360がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「spbm.ePK.KA」と秘密鍵「spbm.eSK.KA」を生成した後、この鍵の対の内の公開鍵(spbm.ePK.KA)を選択する。
また、サーバー2300は、受信した「spbmVerification」を用いて自分を検証することができる認証書情報を確認して、少なくとも一つ以上の署名用認証書(spbm.Cert.DS)をさらに選択する。
【0323】
また、サーバー2300は、受信した「senderSpblVerification」を用いて検証を行う第1SSP2210の認証書情報が、自分が検証可能なことであるかどうかを確認する。
この過程は、選択的に行われないこともある。
また、サーバー2300は、受信した「ReceiverSpblVerification」を用いて検証を行う第2SSP2360の認証書情報が、自分が検証可能なことであるかどうかを確認する。
若しくは、「ReceiverSpblVerification」を用いて自分が検証することができる第2SSP2360の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「CiPkIdToBeUsed」に設定する。
【0324】
また、サーバー2300は、受信した「第2SSP2360がサポートする暗号化アルゴリズムのリスト」を用いて今後の用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「CryptoToBeUsed」に設定する。
また、サーバー2300は、受信した「第2SSP2360が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認して、その内に自身もサポートする標準規格のバージョンが存在するかを確認する。
【0325】
「サーバー認証情報(SPBM.Auth)」は、前述した「spbm.Cert.KA」、「spbm.ePK.KA」、「CiPkIdToBeUsed」、「CryptoToBeUsed」の内の少なくとも一つを含む。
また、「サーバー認証情報(SPBM.Auth」は、前述した「spbm.Cert.DS」を選択的にさらに含み得る。
この時、上記で言及した「サーバー認証情報(SPBM.Auth)」の一部又は全体は、情報の無欠性を保障するために「spbm.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「サーバー認証情報」の一部として追加される。
【0326】
図23を参照すると、23030段階で、サーバー2300は、第2LBA2370を経て第2SSP2360に23025段階で生成した「サーバー認証情報(SPBM.Auth)」を伝達する。
【0327】
図23を参照すると、23035段階で、第2SSP2360は、受信した「サーバー認証情報(SPBM.Auth)」を検証する。
若し、第2SSP2360が「spbm.Cert.KA」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第2SSP2360が「spbm.Cert.DS」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第2SSP2360が「spbm.ePK.KA」とこれに対するデジタル署名が送信された場合には、「spbm.Cert.DS」を用いてデジタル署名を確認して受信した公開鍵「spbm.ePK.KA」の無欠性を確認する。
また、第2SSP2360は、「CiPkIdToBeUsed」を受信した場合、これを確認して自分を検証することができる少なくとも一つ以上の署名用認証書(ssp2.Cert.DS)を選択する。
【0328】
また、図には示していないが、23035段階で、第2SSP2360は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)で公開鍵「ssp2.ePK.KA」と秘密鍵 「ssp2.eSK.KA」を生成した後、この鍵の対の内の公開鍵(ssp2.ePK.KA)を選択する。
また、第2SSP2360は、「spbm.Cert.KA」に含まれている鍵合意用公開鍵や「spbm.ePK.KA」の内の一つを選択した後、この値と「ssp2.eSK.KA」を用いて今後のサーバーとの通信の内の暗号化に用いられるセッション鍵「ShKey03」を生成する。
「ShKey03」は、受信した「CryptoToBeUsed」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
【0329】
また、23035段階で、第2SSP2360は、自分を認証することができる「端末認証情報(Device.Auth)」を生成する。
この時、「端末認証情報(Device.Auth)」は、「ssp2.Cert.DS」を含む。
また「端末認証情報(Device.Auth)」は、「ssp1.Cert.DS」を選択的にさらに含み得る。
また、「端末認証情報(Device.Auth)」は、「ssp2.Cert.DS)及び/又は「ssp1.Cert.DS」と連関された認証書チェーン情報をさらに含み得る。
また「端末認証情報(Device.Auth)」は、「spblAttestation」の一部及び/又は全体を含み得る。
また、「端末認証情報(Device.Auth)」は、「finalizationRequest」の一部及び/又は全体を含み得る。
また、「端末認証情報(Device.Auth)」は、「finalizationResponse」の一部及び/又は全体を含み得る。
また、「端末認証情報(Device.Auth)」は、「ssp2.ePK.KA」をさらに含み得る。
【0330】
この時、上記で言及した「端末認証情報(Device.Auth)」の一部又は全体は、情報の無欠性を保障するために「ssp2.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「端末認証情報」の一部として追加される。
また、「端末認証情報(Device.Auth)」の一部又は全体は、先立って生成されたセッション鍵「ShKey03」を用いて暗号化される。
【0331】
図23を参照すると、23040段階で、第2SSP2360は、第2LBA2370を経てサーバー2300に23035段階で生成した「端末認証情報(Device.Auth)」を伝達する。
【0332】
図23を参照すると、23045段階で、サーバー2300は、受信した「端末認証情報(Device.Auth)」を検証する。
検証過程の具体的手順は、次の通りである。
サーバー2300は、受信した「ssp1.Cert.DS」及び/又は「ssp2.Cert.DS」の署名を検証して当該認証書の有効性を検証する。
また、サーバー2300は、受信した「spblAttestation」及び/又は「finalizationRequest」及び/又は「finalizationResponse」の署名を検証する。
また、サーバー2300は、受信した「spblAttestation」及び/又は「finalizationRequest」及び/又は「finalizationResponse」の内容を検証する。
また、サーバー2300は、検証した内容に基づいて機器の間の送信されたバンドルの内訳をアップデートする。
例えば、サーバー2300は、当該バンドルと第1SSP2210の間に存在したマッピング(mapping)関係を当該バンドルと第2SSP2360のマッピング(mapping)関係にアップデートする。
この過程で、若し、「端末認証情報(Device.Auth)」に暗号化されたデータが含まれている場合、サーバー2300は、送信された「ssp2.ePK.KA」と自分の「spbm.Cert.KA」に含まれている鍵合意用公開鍵に対応する秘密鍵や「spbm.eSK.KA」を用いてセッション鍵「ShKey03」を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後に検証過程を行う。
【0333】
図23を参照すると、23050段階で、サーバー2300は、23045段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第2LBA2370に送信する。
【0334】
図24は、図19で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図24は、バンドルの機器の間の送信内訳が、
・先告知(Pre-notification)される必要がなく、
・告知内容の暗号化が必要ではない場合、適用される手順であっても良い。
【0335】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図24の例のように、第1端末2400は、第1LBA2420と第1SSP2410を含み、第2端末2450は、第2LBA2470と第2SSP2460を含む。
例えば、第1端末2400は、第1SSP2410が装着されて第1SSP2410を制御するための第1LBA2420が設置された端末であっても良く、第2端末2450は、第2SSP2460が装着されて第2SSP2460を制御するための第2LBA2470が設置された端末であっても良い。
【0336】
図24を参照すると、24000段階で次の手順が行われる。
1.〔バンドル設置〕
図24を参照すると、24000段階で、第2LBA2470と第2SSP2460は、互いに協業して第2端末2450にバンドルを設置する。
この過程で、次の手順が共に行われる。
もし、メタデータが送信された場合、第2LBA2470又は第2SSP2460は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第2LBA2470は、この情報を第2SSP2460で伝達する。
もし、トランザクションアイディー(transaction ID)が送信されると、第2LBA2470又は第2SSP2460は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが送信されると、第2LBA2470又は第2SSP2460は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ssp1.Cert.DS」が送信されると、第2SSP2460は、この認証書の有効性を検証して第1SSP2410を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第2SSP2460は、送信された「ssp1.bundle.ePK.KA」と自分の「ssp2.eSK.KA」を用いてセッション鍵「ShKey02」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後に検証を行う。
もし、受信したデータにデジタル署名が含まれていたら、第2SSP2460は、「ssp1.Cer.DS」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
【0337】
2.〔「登録設定」確認〕
また、図には示さなかったが、第2LBA2470及び/又は第2SSP2460は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び/又は「先告知必要であるかどうか」及び/又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、24000段階の一部として24000段階で行われる他の手順と手順に関わらず独立的に行われ得る。
若しくは、24000段階以後24035段階が仕上げられる前、判断が必要な瞬間に行うこともできる。
本図で後述する手順は、「登録設定」を確認した結果、バンドルの機器の間送信内訳が先告知される必要がなく告知内容が暗号化される必要がない時に適用される手順であり得る。
【0338】
図24を参照すると、24005段階で、第2SSP2460は、当該バンドルの状態を「IN TRANSITION」に設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されたがまだ使用が不可能な状態(さらに、「本図で後述する追加動作」及び/又は「(本発明では説明されなかったが)外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態(Disabled、Enable、Active状態)に変更することができる状態)を意味する。
【0339】
図24を参照すると、24010段階で、第2LBA2470は、第2SSP2460に「証明書」をリクエストする。
図24を参照すると、24015段階で、第2SSP2460は、「証明書」を生成する。
図24で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0340】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、図18の符号1850に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、図18の符号1870に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationRequest」は、図18の符号1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0341】
図2を参照すると、24020段階で、第2SSP2460は、第1SSP2410に「finalizationRequest」を伝達する。
例えば、第2SSP2460は、第1SSP2410に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP2460は、第2LBA2470に24010段階の応答で「finalizationRequest」を伝達し、第2LBA2470は、第1LBA2420を経て第1SSP2410に「finalizationRequest」を伝達する。
【0342】
図24を参照すると、24025段階で、第1SSP2410は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0343】
また、24025段階で、第1SSP2410は、検証を済んだ後のバンドルを削除する。
【0344】
また、24025段階で、第1SSP2410は「、証明書」を生成する。
図24で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0345】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「finalizationRequest」の一部及び/又は全体データを含む。
・「finalizationResponse」は、図18の符号1830に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、図18の符号1850に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、図18の符号1870に第1SSPがバンドルを削除した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationResponse」は、図18の符号1890に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0346】
図24を参照すると、24030段階で、第1SSP2410は、第2SSP2460に「finalizationResponse」を伝達する。
例えば、第1SSP2410は、第1LBA2420と第2LBA2470を経て第2SSP2460に「finalizationResponse」を伝達する。
【0347】
図24を参照すると、24035段階で、第2SSP2460は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」のデータ一部又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
【0348】
また、24035段階で、第2SSP2460は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP2460は、バンドルの状態を「Disabled」状態に変換する。
【0349】
また、24035段階で、第2SSP2460は、「証明書」を生成する。
図24で、この証明書は、「spblAttestation」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0350】
この時、可能な証明書構成の一例は、次の通りである。
・「spblAttestation」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、「finalizationRequest」及び/又は「finalizationResponse」の一部及び/又は全体データを含む。
・「spblAttestation」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は、図18の符号1850に第2SSPがバンドルを使用可能な状態の一つに変更したことを意味する情報を含む。
・「spblAttestation」は、図18の符号1870に第2SSPがバンドルの状態を使用可能な状態の一つに変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「spblAttestation」は、図18の符号1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0351】
図24を参照すると、24040段階で、第2SSP2460は、24035段階で生成した「spblAttestation」を送信する。
【0352】
図25は、図24で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図25の例のように、第2端末2550は、第2LBA2570と第2SSP2560を含む。
例えば、第2端末2550は、第2SSP2560が装着されて第2SSP2560を制御するための第2LBA2570が設置された端末であっても良い。
【0353】
また、一実施形態によれば、サーバー2500は、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び/又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明ではサーバー2500を指称するためにサーバーの可能な例の内のいずれか一つであるSPBMという用語を用いる場合もあるが、前述したようにサーバーの種類はSPBMに限らない。
【0354】
図25を参照すると、25000段階で、SPBM2500とLBA2570間にTLS(Transport Layer Security)接続が形成(established)される。
【0355】
図25を参照すると、25005段階で、第2LBA2570は、サーバー2500に「spblAttestation」及び/又は「finalizationRequest」及び/又は「finalizationResponse」の一部及び/又は全体を送信する。
この時、第2LBA2570は、サーバー2500に「選択されたSSP情報」を追加でさらに送信し得る。
「選択されたSSP情報」に対する説明は、図22の説明を参照する。
また、第2LBA2570は、サーバー2500に「ssp2.Cert.DS」を選択的にさらに送信し得る。
また、第2LBA2570は、サーバー2500に「ssp1.Cert.DS」を選択的にさらに送信し得る。
また、第2LBA2570は、サーバー2500に「ssp2.Cert.DS」及び/又は「ssp1.Cert.DS」と関連した認証書チェーン情報をさらに含み得る。
上記の情報は、第2LBA2570自ら構成して送信することもでき、本図に示さなかったが第2LBA2570が2SSP2560に当該情報をリクエストした後に、受信した情報を送信することもでき、若しくは、本図に示さなかったが第2LBA2570がSSP2560に当該情報の一部をリクエストした後の受信した情報と自分が保有した情報を組み合わせて送信することもできる。
【0356】
図25を参照すると、25010段階で、サーバー2500は、25005段階で受信した情報を検証する。
検証過程の具体的手順は、次の通りである。
サーバー2500は、受信した「ssp1.Cert.DS」及び/又は「ssp2.Cert.DS」の署名を検証して当該認証書の有効性を検証する。
また、サーバー2500は、受信した「spblAttestation」及び/又は「finalizationRequest」及び/又は「finalizationResponse」の署名を検証する。
また、サーバー2700は、受信した「spblAttestation」及び/又は「finalizationRequest」及び/又は「finalizationResponse」の内容を検証する。
また、サーバー2500は、検証した内容に基づいて機器の間の送信されたバンドルの内訳をアップデートする。
一例として、サーバー2500は、当該バンドルと第1SSP2410の間に存在したマッピング(mapping)関係を当該バンドルと第2SSP2560のマッピング(mapping)関係にアップデートする。
【0357】
図25を参照すると、25015段階で、サーバー2500は、第2LBA2570に25010段階で行なった検証作業の結果を送信する。
例えば、サーバー2500は、第2LBA2570に検証の成功又は失敗するかどうかを送信する。
【0358】
図26は、図19で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図26は、バンドルの機器の間の送信内訳が、
・先告知(Pre-notification)される必要があり、
・告知内容の暗号化が必要であるか必要ではない、
場合、適用される手順であり得る。
【0359】
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図26の例のように、第1端末2600は、第1LBA2620と第1SSP2610を含み、第2端末2650は、第2LBA2670と第2SSP2660を含む。
例えば、第1端末2600は、第1SSP2610が装着されて第1SSP2610を制御するための第1LBA2620が設置された端末であっても良く、第2端末2650は第2SSP2660が装着されて第2SSP2660を制御するための第2LBA2670が設置された端末であっても良い。
【0360】
図26を参照すると、26000段階で次の手順が行われる。
1.〔バンドル設置〕
図26を参照すると、26000段階で、第2LBA2670と第2SSP2660は、互いに協業して第2端末2650にバンドルを設置する。
この過程で、次の手順が一緒に行われる。
もし、メタデータが送信された場合、第2LBA2670又は第2SSP2660は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第2LBA2670は、この情報を第2SSP2660で伝達する。
もし、トランザクションアイディー(transaction ID)が送信されると、第2LBA2670又は第2SSP2660は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが送信されると、第2LBA2670又は第2SSP2660は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ssp1.Cert.DS」が送信されると、第2SSP2660は、この認証書の有効性を検証して第1SSP2610を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第2SSP2660は、送信された「ssp1.bundle.ePK.KA」と自分の「ssp2.eSK.KA」を用いてセッション鍵「ShKey02」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第2SSP2660は、「ssp1.Cer。DS」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
【0361】
2.〔先登録必要であるかどうか確認〕
また、図には示さなかったが、第2LBA2670及び/又は第2SSP2660は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び/又は「先告知必要であるかどうか」及び/又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、26000段階の一部として26000段階で行なわれる他の手順と手順に関わらず独立的に行うことができる。
若しくは、26000段階以後26035段階が仕上げられる前、判断が必要な瞬間に行うこともできる。
本図で後述する手順は、「登録設定」を確認した結果、バンドルの機器の間送信内訳の先告知される必要がある場合、適用される手順であり得る。
【0362】
図26を参照すると、26005段階で、第2SSP2660は、当該バンドルの状態を「IN TRANSITION」に設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されたがまだ使用が不可能な状態(さらに、「本図で後述する追加動作と図27で説明する追加動作」及び/又は「(本発明では説明されなかったが)外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態(Disabled、Enable、Active状態)に変更することができる状態)を意味する。
【0363】
図26を参照すると、26010段階で、第2LBA2670は、第2SSP2660に「証明書」をリクエストする。
【0364】
図26を参照すると、26015段階で、第2SSP2660は、「証明書」を生成する。
図26で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0365】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、図18の符号1850に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、図18の符号1870に第2SSPがバンドルの状態を「IN TRANSITION」状態に変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationRequest」は、図18の符号1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0366】
図26を参照すると、26020段階で、第2SSP2660は、第1SSP2610に「finalizationRequest」を伝達する。
例えば、第2SSP2660は、第1SSP2610に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP2660は、第2LBA2670に26010段階の応答で「finalizationRequest」を伝達し、第2LBAは第1LBA2620を経て第1SSPに「finalizationRequest」を伝達する。
【0367】
図26を参照すると、26025段階で、第1SSP2610は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0368】
また、26025段階で、第1SSP2610は、検証を済んだ後のバンドルを削除する。
【0369】
また、26025段階で、第1SSP2610は、「証明書」を生成する。
図26で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0370】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「finalizationRequest」の一部及び/又は全体データを含む。
・「finalizationResponse」は、図18の符号1830に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、図18の符号1850に第1SSPがバンドルを削除したことを意味する情報を含む。
・「finalizationResponse」は、図18の符号1870に第1SSPがバンドルを削除した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationResponse」は、図18の符号1890に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0371】
図26を参照すると、26030段階で、第1SSP2610は、第2SSP2660に「finalizationResponse」を伝達する。
例えば、第1SSP2610は、第1LBA2620と第2LBA2670を経て第2SSP2660に「finalizationResponse」を伝達する。
【0372】
図26を参照すると、26035段階で、第2SSP2660は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」のデータ情報又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
【0373】
また、26035段階で、第2SSP2660は、自分の「選択されたSSP情報(sspInforSelected)」を生成する。
「選択されたSSP情報」には機器の間のバンドル送信結果をサーバーに告知するために提供されなければならない第2SSPの情報が含まれる。
【0374】
この時、「選択されたSSP情報」には認証書交渉過程のための情報(認証書交渉情報)が含まれる。
この「認証書交渉情報」は、
・第2SSP2660がサーバーを検証に用いることができる認証書情報(spbmVerification)、
・サーバーが第1SSP2610を検証に用いることができる認証書情報(SenderSpblVerification)、
・サーバーが第2SSP2660を検証に用いることができる認証書情報(ReceiverSpblVerification)、
などの情報を選択的に含み得る。
また、「認証書交渉情報」は、第2SSP2660がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第2SSP2660がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また「選択されたSSP情報」には第2SSP2660が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むSSPバージョン情報が選択的にさらに含まれ得る。
【0375】
図26を参照すると、26040段階で、第2SSP2660は、26035段階で行なった作業に対する結果(例えば、成功/失敗するかどうか)を第2LBA2670に送信する。
また、26035段階で生成した「選択されたSSP情報」が共に送信され得る。
26035過程で、「選択されたSSP情報」を生成する過程と26040段階で「選択されたSSP情報」を伝達する過程は、省略され得る。
【0376】
図27は、図26で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図27の例のように、第2端末2750は、第2LBA2770と第2SSP2760を含む。
一例として、第2端末2750は、第2SSP2760が装着されて第2SSP2760を制御するための第2LBA2770が設置された端末であっても良い。
【0377】
また、一実施形態によれば、サーバー2700は、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び/又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明ではサーバー2700を指称するためにサーバーの可能な例の内のいずれか一つであるSPBMという用語を用いる場合もあるが、前述したようにサーバーの種類はSPBMに限らない。
【0378】
図27を参照すると、27000段階で、SPBM2700とLBA2770間にTLS(Transport Layer Security)接続が形成(established)される。
本図では27000段階が27005段階~27015段階以前に行われることとして記載しているが、27000段階は、27020段階が行われる前の27005段階~27015段階とは独立的に行われ得る。
例えば、27000段階は、27015段階と27020段階の間に行われ得る。
【0379】
図27を参照すると、27005段階で、第2LBA2770は、第2SSP22760に「選択されたSSP情報(SspInfoSelected)」をリクエストする。
この時、27005段階は、自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第2端末2750が提供するUIを介してユーザから与えることもでき、リモートサーバーからプッシュ入力を介して第2端末2750に与えることもできる。
【0380】
図27を参照すると、27010段階で、第2SSP2760は、自分の「選択されたSSP情報」を生成する。
「選択されたSSP情報」に対する説明は、図26に記載した説明を参照する。
図27を参照すると、27015段階で、第2SSP2760は、第2LBA2770に27010段階で生成した「選択されたSSP情報」を送信する。
27005段階~27015段階は、場合によって省略され得る。
【0381】
図27を参照すると、27020段階で、第2LBA2770は、サーバー2700に「選択されたSSP情報」を送信する。
もし、第2LBA2770が、図26の26035段階~26040段階を介して「選択されたSSP情報」を受信したか、若しくは、図27の27005段階~27015段階を介して「選択されたSSP情報」を受信する場合、第2LBA2770は、サーバー2700に受信した「選択されたSSP情報」を送信する。
若し、第2LBA2770が「選択されたSSP情報」を受信しない場合、第2LBA2770は、「選択されたSSP情報」を生成してサーバー2700に送信する。
【0382】
図27を参照すると、27025段階で、サーバー2700は、受信した「選択されたSSP情報」を確認してこの情報に基づいて自分を認証することができる「サーバー認証情報(SPBM.Auth)」を生成する。
この過程に対するより具体的な手順は、次の通りである。
【0383】
サーバー2700は、受信した「spbmVerification」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書(spbm.Cert.KA)を選択する。
若しくは、サーバー2700は、受信した「第2SSP2760がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「spbm.ePK.KA」と秘密鍵「spbm.eSK.KA」を生成した後、この鍵の対の内の公開鍵(spbm.ePK.KA)を選択する。
また、サーバー2700は、受信した「spbmVerification」を用いて自分を検証することができる認証書情報を確認して、少なくとも一つ以上の署名用認証書(spbm.Cert.DS)をさらに選択する。
【0384】
また、サーバー2700は、受信した「senderSpblVerification」を用いて検証を行う第1SSP2610の認証書情報が、自分が検証可能なことであるかどうかを確認する。
また、サーバー2700は、受信した「ReceiverSpblVerification」を用いて検証を行う第2SSP2760の認証書情報が、自分が検証可能なことであるかどうかを確認する。
若しくは、「ReceiverSpblVerification」を用いて自分が検証することができる第2SSP2760の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「CiPkIdToBeUsed」で設定する。
【0385】
また、サーバー2700は、受信した「第2SSP2760がサポートする暗号化アルゴリズムのリスト」を用いて今後の用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「CryptoToBeUsed」に設定する。
また、サーバー2700は、受信した「第2SSP2760が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認して、その内の自分もサポートする標準規格のバージョンが存在するかを確認する。
【0386】
「サーバー認証情報(SPBM.Auth」は、前述した「spbm.Cert.KA」、「spbm.ePK.KA」、「spbm.Cert.DS」、「CiPkIdToBeUsed」、「CryptoToBeUsed」の内の少なくとも一つを含む。
この時、上記に言及した「サーバー認証情報(SPBM.Auth)」の一部又は全体は、情報の無欠性を保障するために「spbm.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「サーバー認証情報」の一部として追加される。
【0387】
図27を参照すると、27030段階で、サーバー2700は、第2LBA2770を経て第2SSP2760に27025段階で生成した「サーバー認証情報(SPBM.Auth)」を伝達する。
【0388】
図27を参照すると、27035段階で、第2SSP2760は、受信した「サーバー認証情報(SPBM.Auth)」を検証する。
若し、第2SSP2760が「spbm.Cert.KA」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第2SSP2760が「spbm.Cert.DS」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第2SSP2760が「spbm.ePK.KA」とこれに対するデジタル署名が送信された場合には、「spbm.Cert.DS」を用いてデジタル署名を確認して受信した公開鍵「spbm.ePK.KA」の無欠性を確認する。
また、第2SSP2760は、「CiPkIdToBeUsed」を受信した場合、これを確認して自分を検証することができる少なくとも一つ以上の署名用認証書(ssp2.Cert.DS)を選択する。
【0389】
また、図には示していないが、27035段階で、第2SSP2760は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)で公開鍵 「ssp2.ePK.KA」と秘密鍵「ssp2.eSK.KA」を生成した後、この鍵の対の内の公開鍵(ssp2.ePK.KA)を選択する。
また、第2SSP2760は、「spbm.Cert.KA」に含まれている鍵合意用公開鍵や「spbm.ePK.KA」の中で一つを選択した後、この値と「ssp2.eSK.KA」を用いて今後のサーバーとの通信の中で暗号化に用いられるセッション鍵「ShKey03」を生成する。
「ShKey03」は、受信した「CryptoToBeUsed」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
【0390】
また、27035段階で、第2SSP2760は、自分を認証することができる「端末認証情報(Device.Auth)」を生成する。
この時、「端末認証情報(Device.Auth)」は、「ssp2.Cert.DS」を含む。
また、「端末認証情報(Device.Auth)」は、「ssp2.ePK.KA」をさらに含み得る。
また「端末認証情報(Device.Auth)」は、「ssp1.Cert.DS」を選択的にさらに含み得る。
また「端末認証情報(Device.Auth)」は、「finalizationRequest」の一部及び/又は全体を含み得る。
また「端末認証情報(Device.Auth)」は、「finalizationResponse」の一部及び/又は全体を含み得る。
【0391】
この時、上記で言及した「端末認証情報(Device.Auth)」の一部又は全体は、情報の無欠性を保障するために「ssp2.Cert.DS」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「端末認証情報」の一部として追加される。
また、「端末認証情報(Device.Auth)」の一部又は全体は、先立って生成されたセッション鍵「ShKey03」を用いて暗号化される。
【0392】
図27を参照すると、27040段階で、第2SSP2760は、第2LBA2770を経てサーバー2700に27035段階で生成した「端末認証情報(Device.Auth)」を伝達する。
【0393】
図27を参照すると、27045段階で、サーバー2700は、受信した「端末認証情報(Device.Auth)」を検証する。
検証過程の具体的手順は、次の通りである。
サーバー2700は、受信した「ssp1.Cert.DS」及び/又は「ssp2.Cert.DS」の署名を検証して当該認証書の有効性を検証する。
また、サーバー2700は、受信した「finalizationRequest」及び/又は「finalizationResponse」の署名を検証する。
また、サーバー2700は、受信した「finalizationRequest」及び/又は「finalizationResponse」の内容を検証する。
また、サーバー2700は、検証した内容に基づいて機器の間の送信されたバンドルの内訳をアップデートする。
例えば、サーバー2700は、当該バンドルと第1SSP2610の間に存在したマッピング(mapping)関係を当該バンドルと第2SSP2760のマッピング(mapping)関係にアップデートする。
この過程で、若し、「端末認証情報(Device.Auth)」に暗号化されたデータが含まれている場合、サーバー2700は、送信された「ssp2.ePK.KA」と自分の「spbm.Cert.KA」に含まれている鍵合意用公開鍵に対応する秘密鍵や「spbm.eSK.KA」を用いてセッション鍵「ShKey03」を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後に検証過程を行う。
【0394】
また、27045段階で、サーバー2700は、「証明書」を生成する。
図27で、この証明書は、「spbmAttestation」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0395】
この時、可能な証明書構成の一例は、次の通りである。
・「spbmAttestation」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「finalizationRequest」及び/又は「finalizationResponse」の一部及び/又は全体データを含む。
・「spbmAttestation」は、図18の符号1830にサーバーの識別子(例えば、サービス提供者の識別子及び/又はバンドル管理サーバーの識別子及び/又はサーバーの住所)を含む。
・「spbmAttestation」は、図18の符号1850にサーバーがバンドルの移動内訳を確認したことを意味する情報を含む。
・「spbmAttestation」は、図18の符号1870にサーバーがバンドルの移動内訳を確認した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「spbmAttestation」は、図18の符号1890にサーバーの署名情報を含む。
この署名は、前述した情報に対してサーバーの署名用認証書で電子署名をした署名情報であっても良い。
【0396】
また27045段階で、図27に示していないが、サーバー2700は、鍵合意に用いられる非対称暗号化用鍵の対(key pair)公開鍵「spbm.attestation.ePK.KA」と秘密鍵「spbm.attestation.eSK.KA」を生成する。
この時、鍵の対「spbm.attestation.ePK.KA」と「spbm.attestation.eSK.KA」は、先立って生成された「spbm.ePK.KA」と「spbm.eSK.KA」と同一値で設定され得る。
又は、鍵の対「spbm.attestation。ePK.KA」と「spbm.attestation.eSK.KA」は、先立って用いられた「spbm.Cert.KA」に含まれている公開鍵とここに対応する秘密鍵と同一値で設定され得る。
また、サーバー2700は、「spbm.attestation.eSK.KA」と「ssp2.ePK.KA」を用いてセッション鍵「ShKey04」を生成する。
もし、「spbm.attstation.eSK.KA」のために「spbm.eSK.KA」又は「spbm.Cert.Ka」に含まれている公開鍵に対応する秘密鍵が再使用されると、セッション鍵「ShKey04」の値も以前に生成された「ShKey03」の値に設定され得る。
【0397】
また27045段階で、図27に示していないが、サーバー2700は、「証明書検証資料」を構成する。
「証明書検証資料」には、「spbm.Cert.DS」が含まれる。
また、「spbm.attestation.ePK.KA」及び/又は「spbm.attestation.ePK.KA」に対するサーバーの電子署名値がさらに含まれ得る。
一実施形態によれば、27045段階で生成された「証明書」と「証明書検証資料」の一部及び/又は全体は、「ShKey04」を用いて暗号化される。
【0398】
図27を参照すると、27050段階で、サーバー2700は、第2LBA2770を経て第2SSP2760に27045段階で生成された「spbmAttestation」と「証明書検証資料」を送信する。
【0399】
図27を参照すると、27055段階で、第2SSP2760は、受信した「spbmAttestaion」及び/又は「証明書検証資料」を検証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第2SSP2760は、送信された「spbm.attestation.ePK.KA」と自分の「ssp2.eSK.KA」を用いてセッション鍵「ShKey04」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第2SSP2760は、「spbm.Cert.DS」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
【0400】
また、27055段階で、第2SSP2760は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP2760は、バンドルの状態を「Disabled」状態に変換する。
【0401】
図27を参照すると、27060段階で、第2SSP2760は、27060段階の実行結果を第2LBA2770に伝達する。
例えば、第2SSP2760は、27060段階の検証成功又は失敗結果を第2LBA2770に伝達する。
【0402】
図28は、本発明の一実施形態による端末の概略構成を示すブロック図である。
図28に示すように、端末は、送受信部(Transceiver)2810及び少なくとも一つのプロセッサ2820を含む。
また、端末は、SSP2830をさらに含む。
例えば、SSP2830は、端末に挿入することができ、端末に内蔵することもできる。
【0403】
少なくとも一つ以上のプロセッサ2820は、「制御部」で名付けることもできる。
ただ、端末の構成は、図28に制限されず、図28に示した構成要素より多い構成要素を含むか、より少ない構成要素を含むこともできる。
一実施形態によれば、送受信部2810、少なくとも一つのプロセッサ2820及びメモリ(図示せず)は,一つのチップ(Chip)形態に具現することができる。
また、SSP2830が内蔵する場合、SSP2830を含み、一つのチップ形態で具現することもできる。
【0404】
一実施形態によれば、送受信部2810は、他の端末の送受信部又は外部サーバーと本発明の実施形態による信号、情報、データなどを送信及び受信を行う。
送受信部2810は、送信する信号の周波数を上昇変換(up converting)及び増幅するRF送信機と、受信する信号を低雑音増幅して周波数を下降変換(down converting)するRF受信機などで構成される。
ただ、これは送受信部2810の一実施形態だけであって、送受信部2810の構成要素がRF送信機及びRF受信機に限定されることではない。
また、送受信部2810は、無線チャンネルを介して信号を受信して少なくとも一つのプロセッサ2820に出力し、少なくとも一つのプロセッサ2820から出力された信号を、無線チャンネルを介して送信する。
【0405】
一実施形態によれば、送受信部2810は、他の端末の送受信部又は外部サーバーから他の端末に含まれたSSPの情報、他の端末を認証することができる認証情報、サーバーを認証することができる認証情報、自分を認証することができる認証情報、バンドル移動コード、バンドル移動設定、バンドル、図22図27で記載した多様な証明書などを送信するか、受信する。
【0406】
一方、少なくとも一つのプロセッサ2820は、端末を全般的に制御するための構成要素である。
少なくとも一つのプロセッサ2820は、前述したような本発明の多様な実施形態によって、端末の全般的な動作を制御する。
【0407】
一方、SSP2830は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置され得る。
一実施形態によれば、SSP2830内の少なくとも一つのプロセッサ又はコントローラーは、バンドル移動設定を確認して、特定バンドルを送信するかどうかを決定する。
また、バンドル移動設定を確認して当該バンドルの機器の間のバンドル移動結果をサーバーに登録しなければならないか、登録が必要である場合、先告知が必要であるかどうかを判断する。
【0408】
また、一実施形態によれば、SSP内の少なくとも一つ以上のプロセッサ又はコントローラーは、バンドル移動コードを生成して特定バンドルの送信過程を制御する。
また、一実施形態によれば、SSP内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分のSSP情報を生成し、外部から送信された他のSSPのSSP情報を確認して検証する。
また、一実施形態によれば、SSP内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分を検証することができる認証情報を生成し、外部から送信された他のSSPの認証情報を検証する。
また、一実施形態によれば、SSP2830は、バンドルを生成し、単独又は一つ以上のプロセッサ2820と協力してバンドルを設置する。
また、SSP2830は、バンドルを管理する。
【0409】
また、一実施形態によれば、SSP2830は、図22図27で記載した多様な形態の証明書を生成し、受信した証明書を検証する。
また、一実施形態によれば、SSP2830は、図22図27で記載したように受信した証明書の内容に基づいてバンドルの状態を変更する。
また、一実施形態によれば、SSP2830は、プロセッサ2820の制御によって動作する。
又は、SSP2830は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置され得る。
アプリケーションの一部又は全部は、SSP2830又はメモリ(図示せず)に設置され得る。
【0410】
一方、端末は、メモリ(図示せず)をさらに含み、端末の動作のための基本プログラム、アプリケーション、設定情報などのデータを記憶する。
また、メモリは、フラッシュメモリタイプ(Flash Memory Type)、ハードディスクタイプ(Hard Disk Type)、マルチメディアカードマイクロタイプ(Multimedia Card Micro Type)、カードタイプのメモリ(例えば、SD又はXDメモリなど)、磁気メモリ、磁気ディスク、光ディスク、RAM(Random Access Memory)、SRAM(Static Random Access Memory)、RОM(Read-Only Memory)、PROM(Programmable Read-Only Memory)、EEPROM(Electrically Erasable Programmable Read-Only Memory)の内の少なくとも一つの記憶媒体を含み得る。
また、プロセッサ2820は、メモリに記憶された各種プログラム、コンテンツ、データなどを用いて多様な動作を行う。
【0411】
図29は、本発明の実施形態によるサーバーの概略構成を示すブロック図である。
この時、サーバーは、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び/又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明ではサーバーを指称するためにサーバーの可能な例の内のいずれか一つのバンドル管理サーバーという用語を用いるが、前述したようにサーバーの種類はバンドル管理サーバーに限らない。
【0412】
一実施形態よれば、バンドル管理サーバーは、送受信部(Transceiver)2910及び少なくとも一つ以上のプロセッサ2920を含む。
ただ、バンドル管理サーバーの構成は、図29に制限されず、図29に示した構成要素より多い構成要素を含むか、より少ない構成要素を含むこともできる。
一実施形態によれば、送受信部2910、少なくとも一つのプロセッサ2920、及びメモリ(図示せず)は、一つのチップ(Chip)形態で具現され得る。
【0413】
一実施形態によれば、送受信部2910は、端末と本発明の多様な実施形態による信号、情報、データなどを送信及び受信する。
送受信部2910は、送信する信号の周波数を上昇変換及び増幅するRF送信機と、受信する信号を低雑音増幅して周波数を下降変換するRF受信機などで構成される。
ただ、これは、送受信部2910の一実施形態だけであって、送受信部2910の構成要素がRF送信機及びRF受信機に限定されることではない。
また、送受信部2910は、無線チャンネルを介して信号を受信して、少なくとも一つのプロセッサ2920に出力し、少なくとも一つのプロセッサ2920から出力された信号を、無線チャンネルを介して送信する。
【0414】
一方、少なくとも一つ以上のプロセッサ2920は、バンドル管理サーバーを全般的に制御するための構成要素である。
プロセッサ2920は、前述のような本発明の多様な実施形態によって、バンドル管理サーバーの全般的な動作を制御する。
少なくとも一つ以上のプロセッサ2920は、制御部と名付けることができる。
【0415】
一方、バンドル管理サーバーは、メモリ(図示せず)をさらに含み、バンドル管理サーバーの動作のための基本プログラム、アプリケーション、設定情報などのデータを記憶する。
また、メモリは、フラッシュメモリタイプ(Flash Memory Type)、ハードディスクタイプ(Hard Disk Type)、マルチメディアカードマイクロタイプ(Multimedia Card Micro Type)、カードタイプのメモリ(例えば、SD又はXDメモリなど)、磁気メモリ、磁気ディスク、光ディスク、 RAM(Random Access Memory)、SRAM(Static Random Access Memory)、ROM(Read-Only Memory、ROM)、PROM(Programmable Read-Only Memory)、EEPROM(Electrically Erasable Programmable Read-Only Memory)の内の少なくとも一つの記憶媒体を含み得る。
また、プロセッサ2920は、メモリに記憶された各種プログラム、コンテンツ、データなどを用いて多様な動作を行う。
【0416】
図30は、図19で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順及びバンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのLBA及び少なくとも一つのSSPを含む。
例えば、図30の例のように、第1端末3000は、第1LBA3020と第1SSP3010を含み、第2端末3050は、第2LBA3070と第2SSP3060を含む。
例えば、第1端末3000は、第1SSP3010が装着されて第1SSP3010を制御するための第1LBA3020が設置された端末であっても良く、第2端末3050は、第2SSP3060が装着されて第2SSP3060を制御するための第2LBA3070が設置された端末であっても良い。
【0417】
図30を参照すると、30000段階で次の手順が行われる。
1.〔バンドル設置〕
図30を参照すると、30000段階で、第2LBA3070と第2SSP3060は、互いに協業して第2端末3050にバンドルを設置する。
この過程で次の手順が共に行われる。
もし、メタデータが送信された場合、第2LBA3070又は第2SSP3060は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第2LBA3070は、上記情報を第2SSP060へ伝達する。
もし、トランザクションアイディー(transaction ID)が送信されると、第2LBA3070又は第2SSP3060は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もしバンドル識別子(SPB ID)、バンドルファミリ識別子(SPB Family ID)、バンドルファミリ管理者識別子(SPB Family Custodian Object ID)の内の少なくとも一つが送信されると、第2LBA3070又は第2SSP3060は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「sp1.Cert.DS」が送信されると、第2SSP3060は、この認証書の有効性を検証して第1SSP3010を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第2SSP3060は、送信された「ssp1.bundle.ePK.KA」と自分の「ssp2.eSK.KA」を用いてセッション鍵「ShKey02」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第2SSP3060は、「ssp1.Cer.DS」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
【0418】
2.〔「登録設定」確認〕
また、図には示さなかったが、第2LBA3070及び/又は第2SSP3060は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び/又は「先告知必要であるかどうか」及び/又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、30000段階の一部として30000段階で行われる他の手順と手順に関わらず独立的に行われ得る。
若しくは、30000段階以後30040段階又は30050段階で告知が行う前、「登録設定」を確認して判断が必要な瞬間に行うこともできる。
【0419】
図30を参照すると、30005段階で、第2SSP3060は、当該バンドルの状態を「IN TRANSITION」に設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されているが使用が不可能な状態(さらに、「第1端末3000のリクエスト」及び/又は「外部サーバーのリクエスト」のような動作によってだけ使用可能な状態(Disabled、Enable、Active状態)に変更することができる状態)を意味する。
【0420】
図30を参照すると、30010段階で、第2LBA3070は、第2SSP3060に「証明書」をリクエストする。
【0421】
図30を参照すると、30015段階で、第2SSP3060は、「証明書」を生成する。
図30で、この証明書は、「finalizationRequest」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0422】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationRequest」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
・「finalizationRequest」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「finalizationRequest」は、図18の符号1850に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationRequest」は、図18の符号1870に第2SSPがバンドルの状態を「IN TRANSITION」状態に設定した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationRequest」は、図18の符号1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0423】
図30を参照すると、30020段階で、第2SSP3060は、第1SSP3010に「finalizationRequest」を伝達する。
例えば、第2SSP3060は、第1SSP3010に次のような過程を経て「finalizationRequest」を伝達する。
すなわち、第2SSP3060は、第2LBA3070に30010段階の応答で「finalizationRequest」を伝達し、第2LBA3070は、第1LBA3020を経て第1SSP3010に「finalizationRequest」を伝達する。
【0424】
図30を参照すると、30025段階で、第1SSP3010は、受信した「finalizationRequest」を検証する。
この検証過程は、「finalizationRequest」に含まれた第2SSPの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「finalizationRequest」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」状態に変更することであるかを確認する過程をさらに含み得る。
【0425】
また、30025段階で、第1SSP3010は、検証が済んだ後当該バンドルの状態を「IN TRANSITION」に設定する。
「IN TRANSITION」は、バンドルが成功裏に設置されているが使用が不可能な状態(さらに、「第2端末3050のリクエスト」及び/又は「外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態(Disabled、Enable、Active状態)に変更することができる状態)を意味する。
【0426】
また、30025段階で、第1SSP3010は、「証明書」を生成する。
図30で、この証明書は、「finalizationResponse」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0427】
この時、可能な証明書構成の一例は、次の通りである。
・「finalizationResponse」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「finalizationRequest」の一部及び/又は全体データを含む。
・「finalizationResponse」は、図18の符号1830に第1SSPの「SSP識別子」を含む。
・「finalizationResponse」は、図18の符号1850に第1SSPがバンドルの状態を「IN TRANSITION」状態に設定したことを意味する情報を含む。
・「finalizationResponse」は、図18の符号1870に第1SSPがバンドルの状態を「IN TRANSITION」状態に設定した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「finalizationResponse」は、図18の符号1890に第1SSPの署名情報を含む。
この署名は、前述した情報に対して第1SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0428】
図30を参照すると、30030段階で、第1SSP3010は、第2SSP3060に「finalizationResponse」を伝達する。
例えば、第1SSP3010は、第1LBA3020と第2LBA3070を経て第2SSP3060に「finalizationResponse」を伝達する。
【0429】
図30を参照すると、30035段階で、第2SSP3060は、受信した「finalizationResponse」を検証する。
この検証過程は、「finalizationResponse」に含まれた第1SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「finalizationResponse」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「finalizationRequest」のデータ一部又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「finalizationResponse」に含まれた「SSP識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「finalizationResponse」に含まれたコマンド情報がバンドルの状態を「IN TRANSITION」に設定することであるかを確認する過程をさらに含み得る。
【0430】
図30を参照すると、30040段階で、先告知(Pre-notification)手順が行われる。
この手順は、「登録設定」に先告知が必要であると設定されている場合、適用される手順であり得る。
もし、先告知手順が行われると、この手順は、以下の通りである。
【0431】
先ず、第2SSP3060が「sspInfoSelected」を生成してこの情報を第2LBA3070で送信する。
この過程は、必要によって省略されることもできる。
この時、「sspInfoSelected」に対する説明は、図26の説明を参照する。
以後、図27に記載した手順の内の27055段階の「バンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する手順」以前までの過程が行われる。
【0432】
図30を参照すると、30045段階で、第2SSP3060は、バンドルの状態を使用可能な状態の内の一つ(Disabled、Enable、Activeの内の一つ)に変更する。
例えば、図に示したように、第2SSP3060は、バンドルの状態を「Disabled」状態に変換する。
【0433】
また、30045段階で、第2SSP3060は、「証明書」を生成する。
図30で、この証明書は、「spblAttestation」と呼ばれる。
この証明書の構造は、図18に開示した構造による。
【0434】
この時、可能な証明書構成の一例は、次の通りである。
・「spblAttestation」は、図18の符号1810に当該バンドルの「バンドル区分者」を含む。
若しくは、「finalizationRequest」及び/又は「finalizationResponse」及び/又は「spbmAttestaion」の一部及び/又は全体データを含む。
・「spblAttestation」は、図18の符号1830に第2SSPの「SSP識別子」を含む。
・「spblAttestation」は、図18の符号1850に第2SSPがバンドルを使用可能な状態の内の一つに変更したことを意味する情報を含む。
・「spblAttestation」は、図18の符号1870に第2SSPがバンドルの状態を使用可能な状態の中の一つに変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「spblAttestation」は、図18の符号1890に第2SSPの署名情報を含む。
この署名は、前述した情報に対して第2SSPの署名用認証書で電子署名をした署名情報であっても良い。
【0435】
図30を参照すると、30050段階で、後告知(Post-notification)手順が行われる。
この手順は「登録設定」に先告知が必要であると設定されている場合、適用される手順であり得る。
もし、後告知手順が行われると、この手順は、以下の通りである。
【0436】
a.〔「登録設定」に告知内容の暗号化が必要と設定されている場合〕
先ず、第2SSP3060が「sspInfoSelected」を生成してこの情報を第2LBA3070で送信する。
この過程は、必要によって省略され得る。
この時、「sspInfoSelected」に対する説明は、図22の説明を参照する。
以後、図23に記載した手順が行われる。
【0437】
b.〔「登録設定」に告知内容の暗号化が必要ではないと設定されている場合〕
先ず、第2SSP3060が「spblAttestation」を第2LBA3070に送信する。
以後、図25に記載した手順が行われる。
【0438】
図30を参照すると、30055段階で、第2SSP3060は、第2LBA3070と第1LBA3020を経て第1SSP3010に「spblAttestation」を送信する。
【0439】
図30を参照すると、30060段階で、第1SSP3010は、受信した「spblAttestation」を検証する。
この検証過程は、「spblAttestation」に含まれた第2SSPの署名の有効性を検査する段階を含む。
また、この検証過程は、「spblAttestation」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれた「SSP識別子」が第2SSPの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「spblAttestation」に含まれたコマンド情報がバンドルの状態を使用可能な状態の内の一つに設定したことであるかを確認する過程をさらに含み得る。
【0440】
また、30060段階で、第1SSP3010は、バンドルを削除する。
【0441】
30045段階で、「spblAttestation」を生成する手順及び/又は30055段階及び/又は30060段階は、必要によって省略され得る。
30040段階又は30050段階に記載した告知過程が完了しない場合(例えば、サーバーに告知送信したがこれに対する応答を受けることができない場合)第2端末は、繰り返して告知サーバーに再送信する。
再送信過程は、予め設定された再送信最大回数によってこの最大値を満足するまで行うこともでき、若しくは、サーバーから応答を受信するまで繰り返して行うこともできる。
【0442】
「登録設定」によって先告知が必要だが30040段階が正常に行われなく、第1端末3000と第2端末3050の両機器でバンドルが使用不可能となった場合、図29で説明したサーバーのリクエストによって第1端末3000及び/又は第2端末3050に設置されたバンドルの状態が「IN TRANSITION」から使用可能な状態の内の一つ(例えば、「Disabled」状態)に変更される。
【0443】
上述した本発明の具体的な実施形態で、開示に含まれる構成要素は提示した具体的な実施形態によって単数又は複数で表現された。
しかし、単数又は複数の表現は、説明の便宜のために提示した状況に適合に選択されたことで、本発明が単数又は複数の構成要素で制限されることではなく、複数で表現された構成要素と言っても単数で構成されるか、単数で表現された構成要素と言っても複数で構成され得る。
【0444】
一方、本発明の詳細な説明では具体的な一実施形態に関して説明したが、本発明の範囲から逸脱せず範囲内で様々な変形が可能であることは勿論である。
したがって、本発明の範囲は、説明した実施形態に限って決定されてはなく、後述する特許請求の範囲だけではなくこの特許請求の範囲と均等なものなどによって定められなればならない。
【0445】
本発明の多様な実施形態及びここに用いられた用語は、本発明に記載した技術を特定の実施形態に対して限定しようとすることではなく、当該実施形態の多様な変更、均等物、及び/又は代替物を含むことに理解されなければならない。
図面の説明に関連して、類似の構成要素に対しては、類似の参照符号が用いた。
単数の表現は、文脈上の明白に異なるように意味しない限り、複数の表現を含むことができる。
本発明において、「A又はB」、「A及び/又はBの内の少なくとも一つ」、「A、B又はC」、「A、B及び/又はCの内の少なくとも一つ」などの表現は、共に羅列された項目のすべての可能な組み合せを含み得る。
「第1」、「第2」、「一番目」、又は「二番目」などの表現は、当該構成要素を、順序又は重要度に関わらず修飾することができ、一つの構成要素と他の構成要素と区分するために用いられるだけ、当該構成要素を限定しない。
ある(例えば、第1)構成要素が他(例えば、第2)の構成要素に「機能的に又は通信的に連結」されているか、「接続されて」いると言及されたときには、前記ある構成要素が前記他の構成要素に直接的に連結されたり、他の構成要素(例えば、第3構成要素)を介して連結され得る。
【0446】
本発明で用いる用語「モジュール」は、ハードウェア、ソフトウェア、又はファームウエアから構成されたユニットを含み、例えば、ロジック、論理ブロック、部品、又は回路などの用語と相互互換的に用いられる。
モジュールは、一体で構成された部品又は一つ又はその以上の機能を行う最小単位又はその一部になる。
例えば、モジュールは、ASIC(application-specific integrated circuit)で構成され得る。
【0447】
本明細書の多様な実施形態は、機器(machine)(例えば、コンピューター)によって読める記憶媒体(storage medium)(例えば、内蔵メモリ又は外蔵メモリ)に記憶されたコマンドを含むソフトウェア(例えば、プログラム)で具現することができる。
機器は、記憶媒体から記憶されたコマンドを呼び出し、呼び出されたコマンドによって動作が可能な装置として、多様な実施形態による他の端末を含み得る。
コマンドがプロセッサによって実行される場合、プロセッサが直接、又はプロセッサの制御下に他の構成要素を用いてコマンドに該当する機能を行う。
コマンドは、コンパイラー又はインタプリターによって生成又は実行されるコードを含み得る。
【0448】
機器で読める記憶媒体は、非一時的(non-transitory)記憶媒体の形態で提供され得る。
ここで、「非一時的」は、記憶媒体が信号(signal)を含まず実在(tangible)するということを意味するだけ、データが記憶媒体に半永久的又は臨時的に記憶されることを区分しない。
【0449】
本発明で開示した多様な実施形態による方法は、コンピュータープログラム製品(computer program product)に含まれて提供され得る。
コンピュータープログラム製品は、商品として販売者及び購買者の間で取り引きされる。
コンピュータープログラム製品は、機器で読める記憶媒体(例えば、compact disc read only memory(CD-ROM))の形態で、又はアプリケーションストア(例えば、プレイストア(登録商標))を介してオンラインで配布することができる。
オンライン配布の場合に、コンピュータープログラム製品の少なくとも一部は、製造者のサーバー、アプリケーションストアのサーバー、又は中継サーバーのメモリのように記憶媒体に少なくとも一時記憶されたり、臨時的に生成され得る。
一実施形態による構成要素(例えば、モジュール又はプログラム)それぞれは、単数又は複数の個体から構成され得、前述した当該サブ構成要素の内の一部サブ構成要素が省略されるか、又は他のサブ構成要素が多様な実施形態にさらに含み得る。
大体的又は追加的に、複数の構成要素(例えば、モジュール又はプログラム)は、一つの個体に統合され、統合される以前のそれぞれの当該構成要素によって行われる機能を同一又は類似に行うことができる。
多様な実施形態による、モジュール、プログラム又は他の構成要素によって行われる動作は、順次的、並列的に、繰り返し的に、又はヒューリスティックするように実行されたり、少なくとも一部動作が他の順序に実行されたり、省略されたり、又は他の動作が追加されることができる。
【符号の説明】
【0450】
110、310 端末
120、210、330、1630、2830 SSP
130 第1端末
140、150 テレコムバンドル
170 ペイメントバンドル
180 電子IDカードバンドル
220 プライマリープラットホーム
222 下位階層オペレーティングシステム
230、240、335、337、339 セカンダリープラットホームバンドル
232 上位階層オペレーティングシステム
234 アプリケーション
250 プライマリープラットホームインターフェース
312 LBA
331 プライマリープラットホーム
333 セカンダリープラットホームバンドルローダー
341、342、343 バンドルファミリ管理者識別子
1610、2810、2910 送受信部
1620、2820、2920 プロセッサ

図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
【国際調査報告】