JP2022549182A - 機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置 - Google Patents

機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置 Download PDF

Info

Publication number
JP2022549182A
JP2022549182A JP2022517517A JP2022517517A JP2022549182A JP 2022549182 A JP2022549182 A JP 2022549182A JP 2022517517 A JP2022517517 A JP 2022517517A JP 2022517517 A JP2022517517 A JP 2022517517A JP 2022549182 A JP2022549182 A JP 2022549182A
Authority
JP
Japan
Prior art keywords
ssp
bundle
terminal
certificate
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022517517A
Other languages
English (en)
Inventor
テヒョン リム，
ジョンホェ ク，
カンジン ユン，
ドクキ イ，
ヘウォン イ，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020200120292A external-priority patent/KR20210034522A/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2022549182A publication Critical patent/JP2022549182A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Abstract

スマートセキュリティ媒体の間のバンドル移動が行われた後のバンドルの状態を設定する方法及び装置を提供する。本発明は、４Ｇシステム以後より高いデータ送信率をサポートするための５Ｇ通信システムをＩｏＴ技術とコンバージェンスする通信技法及びそのシステムに関する。本発明は５Ｇ通信技術及びＩｏＴ関連技術を基盤で知能型サービス（例えば、スマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、ヘルスケア、デジタル教育、小売り業、セキュリティ及び安全関連サービスなど）に適用され得る。本発明は、スマートセキュリティ媒体の間のバンドルが送信された後のバンドルの状態を設定する方法及び装置を記載する。【選択図】 図１７

Description

本発明は、スマートセキュリティ媒体に関し、より詳しくは、スマートセキュリティ媒体の間のバンドル移動が行われた後のバンドルの状態を設定する方法及び装置に関する。
また、本発明は、スマートセキュリティ媒体に関し、より詳しくは、スマートセキュリティ媒体の間のバンドル移動が行われた後のバンドル移動結果をサーバーに登録する方法及び装置に関する。
４Ｇ通信システム商用化以後に増加趨勢にある無線データトラフィック需要を満たすため、改善した５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムを開発するための努力が行われている。
このような理由で、５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムは、４Ｇネットワーク以後（Ｂｅｙｏｎｄ ４Ｇ Ｎｅｔｗｏｒｋ）通信システム又はＬＴＥシステム以後（Ｐｏｓｔ ＬＴＥ）のシステムと呼ばれている。
高いデータ送信率を達成するために、５Ｇ通信システムは、超高周波数（ｍｍＷａｖｅ）帯域（例えば、６０ギガ６０ＧＨｚ）帯域のような）での具現が考慮されている。
超高周波帯域での伝播の経路損失の緩和及び送信距離を増やすために、５Ｇ通信システムでは、ビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）、巨大配列多重入出力（ｍａｓｓｉｖｅ ＭＩＭＯ）、ＦＤ－ＭＩＭＯ（Ｆｕｌｌ Ｄｉｍｅｎｓｉｏｎａｌ ＭＩＭＯ）、アレイアンテナ（ａｒｒａｙ ａｎｔｅｎｎａ）、アナログビームフォーミング（ａｎａｌｏｇ ｂｅａｍ ｆｏｒｍｉｎｇ）、及び大規模アンテナ（ｌａｒｇｅｓｃａｌｅ ａｎｔｅｎｎａ）の技術が議論されている。
さらに、システムのネットワーク改善のために、５Ｇ通信システムでは、進化した小型セル、改善した小型セル（ａｄｖａｎｃｅｄ ｓｍａｌｌ ｃｅｌｌ）、クラウド無線アクセスネットワーク（ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ：ｃｌｏｕｄ ＲＡＮ）、超高密度ネットワーク（ｕｌｔｒａ－ｄｅｎｓｅ ｎｅｔｗｏｒｋ）、Ｄ２Ｄ通信（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、無線バックホール（ｗｉｒｅｌｅｓｓ ｂａｃｋｈａｕｌ）、移動ネットワーク（ｍｏｖｉｎｇ ｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ－Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅ ｃａｎｃｅｌｌａｔｉｏｎ）などの技術開発が行なわれている。
その他、５Ｇシステムでは、進歩したコーディング変調（Ａｄｖａｎｃｅｄ Ｃｏｄｉｎｇ Ｍｏｄｕｌａｔｉｏｎ：ＡＣＭ）方式であるＦＱＡＭ（Ｈｙｂｒｉｄ ＦＳＫ ａｎｄ ＱＡＭ Ｍｏｄｕｌａｔｉｏｎ）及びＳＷＳＣ（Ｓｌｉｄｉｎｇ Ｗｉｎｄｏｗ Ｓｕｐｅｒｐｏｓｉｔｉｏｎ Ｃｏｄｉｎｇ）と、進歩した接続技術であるＦＢＭＣ（Ｆｉｌｔｅｒ Ｂａｎｋ Ｍｕｌｔｉ Ｃａｒｒｉｅｒ）、ＮＯＭＡ（ｎｏｎ ｏｒｔｈｏｇｏｎａｌ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、及びＳＣＭＡ（ｓｐａｒｓｅ ｃｏｄｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）などが開発されている。
一方、人間が情報を生成して消費する人間中心の接続ネットワークであるインターネットは、事物などの分散したエンティティーの間に情報を交換して処理するＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ、モノのインターネット）網へ進化しつつある。
クラウドサーバーなどとの接続を通じるビックデータ（Ｂｉｇ ｄａｔａ）処理技術などがＩｏＴ技術に結合されたＩｏＥ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｅｖｅｒｙｔｈｉｎｇ）技術も台頭してきている。
ＩｏＴを具現のためにセンシング技術、有／無線通信及びネットワークインフラ、サービスインターフェース技術及びセキュリティ技術のような技術要素が要求され、最近では事物の間の接続のためのセンサーネットワーク（ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）通信、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が研究されている。
ＩｏＴ環境では接続された事物で生成されるデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ（Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ）サービスが提供され得る。
ＩｏＴは、既存のＩＴ（Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ）技術と多様な産業の間のコンバージェンス及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用することができる。
これによって、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが行われた。
例えば、センサーネットワーク、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）及びＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ）などの５Ｇ通信技術がビームフォーミング、ＭＩＭＯ及びアレイアンテナによって具現され得る。
また、前述したビックデータ処理技術としてクラウド無線アクセスネットワーク（ｃｌｏｕｄ ＲＡＮ）が適用されることも５Ｇ技術とＩｏＴ技術の間のコンバージェンスの一例として見なされる。
本発明は、２つの電子装置に含まれたセキュリティモジュールの間にバンドルを移動する場合、バンドル送信が行なった後のバンドルの状態を設定する装置及び方法を提供することにある。
また、２つの電子装置に含まれたセキュリティモジュールの間にバンドルを移動する場合、バンドル送信が行なった後のバンドルの送信結果をサーバーに登録する装置及び方法を提供することにある。
本発明の一態様による第１端末の動作方法は、第１端末の動作方法であって、第２端末で、バンドルを送信する段階と、前記第２端末から、第２端末のバンドル状態情報を含んで生成される第１証明書を受信する段階と、前記受信した第１証明書を検証する段階と、前記第１証明書を検証した後、第１端末のバンドル状態情報を含む第２証明書を生成する段階と、前記第２端末で前記第２証明書を送信する段階と、を有することを特徴とする。
一部の例では、前記第１端末のバンドル状態情報は、前記第１端末のバンドル状態が「ＤＥＬＥＴＥ」、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」、「ＳＵＳＰＥＮＳＩＯＮ」の内の少なくとも一つで設定されることを含むことを特徴とする。
一部の例では、前記第１端末のバンドル状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定された場合、前記第２端末から第２端末のバンドル状態変更に対する情報を含んで生成された第３証明書を受信する段階と、前記受信した第３証明書を検証する段階と、前記第３証明書を検証した後、前記第１端末のバンドルを削除（ＤＥＬＥＴＥ）する段階と、をさらに有することを特徴とする。
一部の例では、前記第２端末によって、前記第１証明書及び前記第２証明書の検証結果に対する情報を含む第４証明書が生成され、前記第４証明書がサーバーに送信され、前記サーバーによって、前記第４証明書は検証されることを特徴とする。
一部の例では、サーバーによって、前記サーバーとの認証結果を含む第５証明書が生成され、前記第５証明書は前記第２端末に送信され、前記第２端末によって、前記第５証明書は検証されることを特徴とする。
本発明の一態様による第２端末の動作方法は、第２端末の動作方法であって、第１端末から、バンドルを受信する段階と、前記バンドルを設置する段階と、第２端末のバンドル状態情報を含む第１証明書を生成する段階と、前記第１端末に、前記第１証明書を送信する段階と、前記第１端末から、第１端末のバンドル状態情報を含んで生成される第２証明書を受信する段階と、前記受信した第２証明書を検証する段階と、前記第２証明書を検証した後、第２端末のバンドル状態設定情報を変更する段階と、を有することを特徴とする。
本発明の一態様による第１端末は、第１端末であって、少なくとも一つの信号を送受信ができる送受信部と、前記送受信部と結合された制御部と、を有し、前記制御部は、第２端末で、バンドルを送信し、前記第２端末から、第２端末のバンドル状態情報を含んで生成される第１証明書を受信し、前記受信した第１証明書を検証し、前記第１証明書を検証した後、第１端末のバンドル状態情報を含む第２証明書を生成し、前記第２端末で前記第２証明書を送信するように構成されることを特徴とする。
本発明の一態様による第２端末は、第２端末であって、少なくとも一つの信号を送受信ができる送受信部と、前記送受信部と結合された制御部と、を有し、前記制御部は、第１端末から、バンドルを受信し、前記バンドルを設置し、第２端末のバンドル状態情報を含む第１証明書を生成し、前記第１端末に、前記第１証明書を送信し、前記第１端末から、第１端末のバンドル状態情報を含んで生成される第２証明書を受信し、前記受信された第２証明書を検証し、前記第２証明書を検証した後、第２端末のバンドル状態設定情報を変更するように構成されることを特徴とする。
本発明に係る第１、第２端末及びその動作方法によれば、一つの機器に設置されたバンドルは安全でかつ効率的な方法で他の機器へ送信及び設置されることができ、送信及び設置が済んだ後のバンドルの状態を設定することができる。
また、一つの機器に設置されたバンドルは安全でかつ効率的な方法で他の機器へ送信及び設置されることができ、送信及び設置が済んだ後のバンドルの送信結果をサーバーに登録することができる。
本発明の実施形態によるＳＳＰの概念を示す図である。 本発明の実施形態によるＳＳＰの内部構造の概念を示す図である。 本発明の実施形態による端末がＳＳＰでバンドルをダウンロードして設置するために用いられる端末内の構成要素の例を示す図である。 本発明の実施形態による２つの端末の間でバンドルの送信が行うために２つの端末が相互動作する方法の例を示す図である。 本発明の一実施形態による「証明書（Ａｔｔｅｓｔａｉｏｎ）」の構成を示す図である。 本発明の実施形態による一つの端末から他の端末にバンドルが送信される手順を概念的に示す図である。 図６で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。 図６で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図である。 図６で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。 図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。 図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。 図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。 使用が中止されたバンドルをさらに使用可能に作る手順の例を示す図である。 使用が中止されたバンドルをさらに使用可能に作るまた他の手順の例を示す図である。 使用が中止されたバンドルをさらに使用可能に作るまた他の手順の例を示す図である。 本発明の実施形態による端末の概略構成を示すブロック図である。 図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。 本発明の一実施形態による「証明書（Ａｔｔｅｓｔａｉｏｎ）」の構成を示す図である。 本発明の実施形態による一つの端末から他の端末にバンドルが送信される手順を概念的に示す図である。 図１９で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。 図１９で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図である。 図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。 図２２で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。 図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。 図２４で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。 図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。 図２６で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。 本発明の実施形態による端末の概略構成を示すブロック図である。 本発明の実施形態によるサーバーの概略構成を示すブロック図である。 図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順及びバンドルの送信結果がサーバーに登録される手順を示す図である。
以下、本発明の実施形態を添付した図面を参照して詳細に説明する。
実施形態を説明するにあたり、本発明が属する技術分野によく知られ、本発明と直接的に関連がない技術内容に対しては説明を省略する。
これは不必要な説明を省略することによって本発明の要旨を明瞭でかつより明確に伝達するためである。
同じ理由で添付図面において一部構成要素は、誇張したり省略するか概略的に示す。
また、各構成要素の大きさは、実際の大きさを全的に反映することではない。
各図面で同一又は対応する構成要素には同一参照番号を付与した。
本発明の利点及び特徴、そしてそれらを達成する方法は、添付した図面と共に詳細に後述する実施形態を参照すると明確になるだろう。
しかし、本発明は、以下で開示する実施形態に限定されることではなく、互いに異なる多様な形態で具現することができ、ただ、本実施形態は本発明の開示が完全にし、本発明が属する技術分野で通常の知識を有する者に開示の範囲を完全に知らせるために提供するものであり、本発明は、請求項の範囲によって定義されるだけである。
明細書全体にかけて同一参照符号は、同一構成要素を指称する。
このとき、処理フローチャートの各ブロックとフローチャートの図面の組み合せは、コンピュータープログラムインストラクションによって行なわれることができることを理解することができるだろう。
これらコンピュータープログラムインストラクションは、汎用コンピューター、特殊用コンピューター、又はその他のプログラム可能なデータプロセッシング装備のプロセッサに搭載されることができるため、コンピューター又はその他のプログラム可能なデータプロセッシング装備のプロセッサを介して行なわれるそのインストラクションが、フローチャートブロックで説明した機能を行う手段を生成する。
これらコンピュータープログラムインストラクションは、特定方式で機能を具現するためにコンピューター又はその他のプログラム可能なデータプロセッシング装備を志向することができるコンピューター利用可能、又はコンピューター可読メモリに記憶することも可能であるため、そのコンピューター利用可能又はコンピューター可読メモリに記憶されたインストラクションは、フローチャートブロックで説明した機能を行うインストラクション手段を内包する製造品目を生産することも可能である。
コンピュータープログラムインストラクションは、コンピューター又はその他のプログラム可能なデータプロセッシング装備上に搭載されることも可能であるため、コンピューター又はその他のプログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピューターで実行されるプロセスを生成してコンピューター又はその他のプログラム可能なデータプロセッシング装備を行うインストラクションは、フローチャートブロックで説明した機能を行うための段階を提供することもできる。
また、各ブロックは、特定された論理的機能を行うための１つ以上の実行可能なインストラクションを含むモジュール、セグメント又はコードの一部を示すことができる。
また、幾つか代替実行例ではブロックで言及された機能が順序を外れて発生することも可能であることを注目すべきである。
例えば、接して示している２つのブロックは、実は実質的に同時に行なわれることも可能で、又はそのブロックが時々該当する機能によって逆順で行われることもできる。
このとき、本実施形態に用いられる「～部」という用語は、ソフトウェア又はＦＰＧＡはＡＳＩＣのようなハードウェア構成要素を意味し、「～部」は、いかなる役目も行う。
しかし、「～部」は、ソフトウェア又はハードウェアに限定される意味ではない。
「～部」は、アドレシングすることができる記憶媒体にあるように構成することもでき、１つ又はその以上のプロセッサを再生させるように構成することもできる。
したがって、一例として「～部」は、ソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス構成要素、及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーティン、プログラムコードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。
構成要素と「～部」のうちで提供される機能は、より小さい数の構成要素及び「～部」に結合したり、追加的な構成要素と「～部」でさらに分離することができるだけでなく、構成要素及び「～部」は、デバイス又はセキュリティマルチメディアカード内の１つ又はその以上のＣＰＵを再生させるように具現させることもできる。
また、本発明ではＳＳＰをセキュリティ媒体の一例を挙げて各実施形態を説明するが、本発明の権利範囲がＳＳＰによることで制限されない。
例えば、ＳＳＰと実質的に同一又は類似の機能を行う他のセキュリティ媒体にも、以下に説明する多様な実施形態が実質的に同一又は類似に適用することができることは当該技術分野の通常の技術者に自明である。
以下の説明で用いられる特定用語は、本発明の理解を助けるために提供したもので、このような特定用語の使用は、本発明の技術的思想を逸脱せず範囲で他の形態で変更され得る。
「ＳＥ（Ｓｅｃｕｒｅ Ｅｌｅｍｅｎｔ）」は、セキュリティ情報（例えば、移動通信網の接続鍵、ＩＤカード／パスポートなどのユーザ身元確認情報、クレジットカード情報、暗号化鍵など）を記憶し、記憶されたセキュリティ情報を用いる制御モジュール（例えば、ＵＳＩＭなどの網接続制御モジュール、暗号化モジュール、鍵生成モジュールなど）を搭載して操作することができる単一チップで構成されたセキュリティモジュールを意味する。
ＳＥは、多様な電子装置（例えば、スマートフォン、タブレット、ウェアラブル装置、自動車、ＩｏＴ装置など）に用いることができ、セキュリティ情報と制御モジュールを介してセキュリティサービス（例えば、移動通信通信網の接続、決済、ユーザ認証など）を提供することができる。
ＳＥは、ＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）、ｅＳＥ（Ｅｍｂｅｄｄｅｄ Ｓｅｃｕｒｅ Ｅｌｅｍｅｎｔ）、ＵＩＣＣとｅＳＥが統合された形態であるＳＳＰ（Ｓｍａｒｔ Ｓｅｃｕｒｅ Ｐｌａｔｆｏｒｍ）などに分けることができ、電子装置に接続又は設置される形態によって脱着式（Ｒｅｍｏｖａｂｌｅ）、固定式（Ｅｍｂｅｄｄｅｄ）、及び特定素子又はＳｏＣ（ｓｙｓｔｅｍ ｏｎ ｃｈｉｐ）に統合される統合式（Ｉｎｔｅｇｒａｔｅｄ）に細分化することができる。
「ＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）」は、移動通信端末機などに挿入して用いるスマートカード（ｓｍａｒｔ ｃａｒｄ）であり、ＵＩＣＣカードとも指称することができる。
ＵＩＣＣには移動通信事業者の網に接続するための接続制御モジュールが含まれ得る。
接続制御モジュールの例としては、ＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）、ＩＳＩＭ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）などがある。
ＵＳＩＭが含まれたＵＩＣＣは、通常ＵＳＩＭカードとも呼ばれる。
同様に、ＳＩＭモジュールが含まれたＵＩＣＣは、通常的にＳＩＭカードとも呼ばれる。
一方、ＳＩＭモジュールは、ＵＩＣＣ製造の時に搭載されるか、ユーザが望む時点で使用しようとする移動通信サービスのＳＩＭモジュールをＵＩＣＣカードにダウンロードすることができる。
ＵＩＣＣカードは、さらに複数個のＳＩＭモジュールをダウンロードして設置し、その内の少なくとも一つのＳＩＭモジュールを選択して用いることができる。
このようなＵＩＣＣカードは、端末に固定するか又は固定しなくても良い。
端末に固定して用いるＵＩＣＣを、ｅＵＩＣＣ（ｅｍｂｅｄｄｅｄ ＵＩＣＣ）と指し、特に端末の通信プロセッサ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）又はこの２つのプロセッサが統合された単一プロセッサ構造を含む「Ｓｙｓｔｅｍ－Ｏｎ－Ｃｈｉｐ」（ＳｏＣ）に内蔵したＵＩＣＣをｉＵＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ ＵＩＣＣ）と指称することができる。
通常的にｅＵＩＣＣとｉＵＩＣＣは、端末に固定して用い、リモートでＳＩＭモジュールをダウンロードして選択することができるＵＩＣＣカードを意味する。
本発明では、リモートでＳＩＭモジュールをダウンロードして選択することができるＵＩＣＣカードを、ｅＵＩＣＣ又はｉＵＩＣＣと通称する。
すなわち、リモートでＳＩＭモジュールをダウンロードして選択することができるＵＩＣＣカードの内で端末に固定するか固定しないＵＩＣＣカードを通称してｅＵＩＣＣ又はｉＵＩＣＣとして用いる。
さらに、ダウンロードするＳＩＭモジュール情報を通称してｅＵＩＣＣプロファイル又はｉＵＩＣＣプロファイル、又はより簡単にプロファイルという用語で用いる。
本発明で、用語「ＵＩＣＣ」は、ＳＩＭと混用することができ、用語「ｅＵＩＣＣ」は、ｅＳＩＭと混用することができる。
また、本発明で「ＵＳＩＭ Ｐｒｏｆｉｌｅ」（ＵＳＩＭ Ｐｒｏｆｉｌｅ）は、プロファイルと同じ意味又はプロファイル内のＵＳＩＭアプリケーションに含まれた情報をソフトウェア形態でパッケージングしたことを意味し得る。
「ｅＳＥ（Ｅｍｂｅｄｄｅｄ Ｓｅｃｕｒｅ Ｅｌｅｍｅｎｔ）」は、電子装置に固定して用いる固定式ＳＥを意味する。
ｅＳＥは、通常的に端末製造会社のリクエストによって製造会社専用に製造され、ОＳとフレームワークを含んで製造することができる。
ｅＳＥは、リモートでアプレット形態のサービス制御モジュールをダウンロードし設置して、電子財布、チケッティング、電子パスポート、デジタル鍵などのような多様なセキュリティサービス用途として用いることができる。
本発明ではリモートでサービス制御モジュールをダウンロードして設置することができる電子装置に付着した単一チップ形態のＳＥをｅＳＥと通称する。
「ＳＳＰ（Ｓｍａｒｔ Ｓｅｃｕｒｅ Ｐｌａｔｆｏｒｍ）」は、ＵＩＣＣとｅＳＥの機能を単一チップで統合サポートが可能なもので、脱着式（Ｒｅｍｏｖａｂｌｅ ＳＳＰ：ｒＳＳＰ）、固定式（Ｅｍｂｅｄｄｅｄ ＳＳＰ：ｅＳＳＰ）、及びＳｏＣに内蔵した統合式（Ｉｎｔｅｇｒａｔｅｄ ＳＳＰ：ｉＳＳＰ）に区分することができる。
ＳＳＰは、一つのプライマリープラットホーム（Ｐｒｉｍａｒｙ Ｐｌａｔｆｏｒｍ：ＰＰ）とＰＰ上で動作する少なくとも一つのセカンダリープラットホームバンドル（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ：ＳＰＢ）を含み、プライマリープラットホームは、ハードウェアプラットホームと「ｌｏｗ ｌｅｖｅｌ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ」（ＬＬＯＳ）の内の少なくとも一つを含み、セカンダリープラットホームバンドルは、「Ｈｉｇｈ－ｌｅｖｅｌ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ」（ＨＬＯＳ）及びＨＬＯＳの上で駆動されるアプリケーションの内の少なくとも一つを含む。
セカンダリープラットホームバンドルは、ＳＰＢ又はバンドルとも呼ばれる。
バンドルは、ＰＰが提供する「Ｐｒｉｍａｒｙ Ｐｌａｔｆｏｒｍ Ｉｎｔｅｒｆａｃｅ」（ＰＰＩ）を介してＰＰの中央処理装置、メモリなどのリソースにアクセスし、これを介してＰＰ上で駆動する。
バンドルには、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅ）、ＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ ＳＩＭ）、ＩＳＩＭ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ ＳＩＭ）などの通信アプリケーションが搭載され得、また、電子財布、チケッティング、電子パスポート、デジタル鍵などのような多様な応用アプリケーションが搭載され得る。
本発明でＳＳＰは、スマートセキュリティ媒体と名付けることもできる。
ＳＳＰは、ダウンロードされて設置されるバンドルにしたがって、前述したＵＩＣＣ又は、ｅＳＥ用途で用いることができ、複数個のバンドルを単一ＳＳＰに設置して同時に操作してＵＩＣＣとｅＳＥの用途を混用することができる。
すなわち、プロファイルを含むバンドルが動作する場合、ＳＳＰは、移動通信事業者網に接続するためのＵＩＣＣ用途として用いることができる。
ＵＩＣＣバンドルは、ｅＵＩＣＣ又はｉＵＩＣＣのように少なくても一つ以上のプロファイルをリモートでバンドル内にダウンロードさせ、選択して動作させる。
また、ＳＳＰ上で電子財布、チケッティング、電子パスポート、又はデジタル鍵などのサービスを提供することができる応用アプリケーションを搭載したサービス制御モジュールを含むバンドルが動作する場合、ＳＳＰは、ｅＳＥの用途として用いられる。
複数のサービス制御モジュールは、一つのバンドルに統合されて設置されて動作するか、それぞれの独立的なバンドルで設置されて動作することができる。
ＳＳＰは、ＯＴＡ（Ｏｖｅｒ Ｔｈｅ Ａｉｒ）技術を用いて外部のバンドル管理サーバー（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ：ＳＰＢ Ｍａｎａｇｅｒ）からバンドルをダウンロードして設置することができ、また他の端末からバンドルが送信されて設置することもできる。
本発明で、ダウンロード又は送信されたバンドルを設置する方法は、端末に挿入及び脱去が可能な着脱式ＳＳＰ（ｒＳＳＰ）、端末に設置される固定式ＳＳＰ（ｅＳＳＰ）、端末に設置されるＳｏＣ内部に含まれる統合式ＳＳＰ（ｉＳＳＰ）に同様に適用することができる。
「ＳＳＰ識別子（ＳＳＰ ＩＤ）」は、端末に内蔵したＳＳＰの固有識別子としてｓｓｐＩＤと指称され得る。
また、本発明の実施形態のように、端末とＳＳＰチップが分離されない場合には、端末ＩＤであって良い。
また、ＳＳＰ内の特定のバンドル識別子（ＳＰＢ ＩＤ）を指称することもできる。
より詳しくは、ＳＳＰで他のバンドルを設置して活性化、非活性化、削除を管理する管理バンドル又はローダー（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｌｏａｄｅｒ：ＳＰＢＬ）のバンドル識別子を指称することもできる。
また、ＳＳＰ内にあるプライマリープラットホームのアイディー（Ｐｒｉｍａｒｙ Ｐｌａｔｆｏｒｍ Ｉｄｅｎｔｉｆｉｅｒ）を指称することもできる。
ＳＳＰは、複数個のＳＳＰ識別子を持つこともでき、複数個のＳＳＰ識別子は、固有の単一のＳＳＰ識別子から誘導された値であっても良い。
「ＳＰＢ（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ）」は、ＳＳＰのプライマリープラットホーム（Ｐｒｉｍａｒｙ Ｐｌａｆｏｒｍ：ＰＰ）上でＰＰのリソースを用いて駆動されることで、例えば、ＵＩＣＣバンドルは、既存のＵＩＣＣ内に記憶されるアプリケーション、ファイルシステム、認証鍵値などとこれらが動作するオペレーティングシステム（ＨＬＯＳ）をソフトウェア形態でパッケージングしたことを意味する。
本発明で、ＳＰＢはバンドルと指称されることができる。
本発明で端末の「状態」は次の通りである。
［活性化（ｅｎａｂｌｅ）］
本発明で、端末又は外部サーバーがバンドルを活性化（ｅｎａｂｌｅ）する動作は、当該ＳＰＢの状態を活性化状態（ｅｎａｂｌｅｄ）に変更して端末が、当該バンドルが提供するサービス（例えば、通信事業者を介して通信サービス、クレジットカード決済サービス、ユーザ認証サービスなど）を受けることができるように設定する動作を意味する。
活性化状態のバンドルは「活性化されたバンドル（ｅｎａｂｌｅｄ Ｂｕｎｄｌｅ）」として表現することができる。
活性化状態のバンドルは、ＳＳＰ内部又は外部の記憶空間に暗号化された状態で記憶されても良い。
［駆動状態（Ａｃｔｉｖｅ）］
本発明で、活性化されたバンドルは、バンドル外部入力（例えば、ユーザ入力、プッシュ、端末内のアプリケーションのリクエスト、通信事業者の認証リクエスト、ＰＰ管理メッセージなど）又はバンドル内部の動作（例えば、タイマー、Ｐｏｌｌｉｎｇ）によって駆動状態（Ａｃｔｉｖｅ）を変更することができる。
駆動状態のバンドルは、ＳＳＰ内部又は外部の記憶空間でＳＳＰ内部の駆動メモリにローディングされて、ＳＳＰ内部のセキュリティ制御装置（Ｓｅｃｕｒｅ ＣＰＵ）を用いてセキュリティ情報を処理して端末にセキュリティサービスを提供することを意味する。
［非活性化（Ｄｉｓａｂｌｅｄ）］
本発明で、端末又は外部サーバーがバンドルを非活性化（ｄｉｓａｂｌｅ）する動作は、当該バンドルの状態を非活性化状態（ｄｉｓａｂｌｅｄ）に変更して端末が、当該バンドルが提供するサービスを受けることができないように設定する動作を意味する。
非活性化状態のＳＰＢは、「非活性化されたバンドル（ｄｉｓａｂｌｅｄ Ｂｕｎｄｌｅ）」として表現することができる。
非活性化状態のバンドルは、ＳＳＰ内部又は外部の記憶空間に暗号化された状態に記憶されても良い。
［削除（Ｄｅｌｅｔｅｄ）］
本発明で、端末又は外部サーバーがバンドルを削除（ｄｅｌｅｔｅ）する動作は、当該バンドルの状態を削除状態（ｄｅｌｅｔｅｄ）に変更するか、当該バンドルを含む当該バンドルの関連データを削除して端末又は外部サーバーがこれ以上の当該バンドルを駆動、活性化又は非活性化することができないように設定する動作を意味する。
削除状態のバンドルは、「削除されたバンドル（ｄｅｌｅｔｅｄ Ｂｕｎｄｌｅ）」として表現することができる。
「バンドルイメージ（Ｂｕｎｄｌｅ Ｉｍａｇｅ、又はＩｍａｇｅ）」は、バンドルと混用されるか、特定バンドルのデータ客体（ｄａｔａ ｏｂｊｅｃｔ）を指す用語として用いることができ、バンドルＴＬＶ又はバンドルイメージＴＬＶ（Ｂｕｎｄｌｅ Ｉｍａｇｅ ＴＬＶ）と名付けることができる。
バンドルイメージが暗号化パラメーターを用いて暗号化された場合、保護されたバンドルイメージ（Ｐｒｏｔｅｃｔｅｄ Ｂｕｎｄｌｅ Ｉｍａｇｅ（ＰＢＩ））又は保護されたバンドルイメージＴＬＶ（ＰＢＩ ＴＬＶ）と名付けることができる。
バンドルイメージが特定ＳＳＰによってだけ復号化化可能な暗号化パラメーターを用いて暗号化された場合、バウンドされたバンドルイメージ（Ｂｏｕｎｄ Ｂｕｎｄｌｅ Ｉｍａｇｅ（ＢＢＩ））又はバウンドされたバンドルイメージＴＬＶ（ＢＢＩ ＴＬＶ）と名付けることができる。
バンドルイメージＴＬＶは、ＴＬＶ（Ｔａｇ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ）形式でバンドルを構成する情報を表すデータセット（ｓｅｔ）であっても良い。
「バンドル区分者」は、バンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）、バンドルＭａｔｃｈｉｎｇ ＩＤ、イベント識別子（Ｅｖｅｎｔ ＩＤ）とマッチングされる因子として指称され得る。
バンドル識別子（ＳＰＢ ＩＤ）は、各バンドルの固有識別子を指すことができる。
バンドルファミリ識別子は、バンドル（例えば、移動通信会社網への接続のためのテレコムバンドル）の種類を区分する識別子を指すことができる。
本発明で、バンドルファミリ識別子は、「Ｆａｍａｉｌｙ ＩＤ」、Ｆｉｄ、又はＦＩＤとして指称され得る。
バンドルファミリ管理者識別子は、バンドルファミリ識別子を管理する主体（例えば、通信事業者、端末製造会社、特定団体など）を区分する識別子を指すことができる。
本発明で、バンドルファミリ管理者識別子は、ＯＩＤ又はＯｉｄで指称され得る。
バンドル区分者は、バンドル管理サーバー又は端末で、バンドルをインデックスすることができる値で用いることができる。
「バンドルメタデータ」は、バンドルを指称又は記述することができる情報のセットを示す用語である。
バンドルメタデータは、上記に記述したバンドル区分者を含むことができる。
また、バンドルメタデータは、バンドルの属性や特性、若しくは設定に対する情報をさらに含むことができる。
バンドルメタデータは、「メタデータ」と表現することができる。
「バンドル管理サーバー」は、サービス提供者（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）又は他のバンドル管理サーバーのリクエストによってバンドルを生成するか、生成されたバンドルを暗号化するか、バンドルリモート管理コマンドを生成するか、生成されたバンドルリモート管理コマンドを暗号化する機能を含む。
上記機能を提供するバンドル管理サーバーは、ＳＰＢＭ（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ）、ＲＢＭ（Ｒｅｍｏｔｅ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ）、ＩＤＳ（Ｉｍａｇｅ Ｄｅｌｉｖｅｒｙ Ｓｅｒｖｅｒ）、「ＳＭ－ＤＰ」（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｄａｔａ Ｐｒｅｐａｒａｔｉｏｎ）、「ＳＭ－ＤＰ＋」（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｄａｔａ Ｐｒｅｐａｒａｔｉｏｎ ｐｌｕｓ）、管理者バンドルサーバー、「Ｍａｎａｇｉｎｇ ＳＭ－ＤＰ＋」（Ｍａｎａｇｉｎｇ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｄａｔａ Ｐｒｅｐａｒａｔｉｏｎ ｐｌｕｓ）、バンドル暗号化サーバー、バンドル生成サーバー、バンドル提供者（Ｂｕｎｄｌｅ Ｐｒｏｖｉｓｉｏｎｅｒ：ＢＰ）、バンドル供給者（Ｂｕｎｄｌｅ Ｐｒｏｖｉｄｅｒ）、ＢＰＣ ｈｏｌｄｅｒ（Ｂｕｎｄｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｃｒｅｄｅｎｔｉａｌｓ ｈｏｌｄｅｒ）の内の少なくとも一つで表される。
本発明で、バンドル管理サーバーは、ＳＳＰでバンドルをダウンロード、設置又はアップデートしてバンドルの状態をリモート管理するための鍵及び認証書の設定を管理する役目を行う。
上記機能を提供するバンドル管理サーバーは、ＳＰＢＭ（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ）、ＲＢＭ（Ｒｅｍｏｔｅ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ）、ＩＤＳ（Ｉｍａｇｅ Ｄｅｌｉｖｅｒｙ Ｓｅｒｖｅｒ）、「ＳＭ－ＳＲ」（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｓｅｃｕｒｅ Ｒｏｕｔｉｎｇ）、「ＳＭ－ＳＲ＋」（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｓｅｃｕｒｅ Ｒｏｕｔｉｎｇ Ｐｌｕｓ）、「ｏｆｆ－ｃａｒｄ ｅｎｔｉｔｙ ｏｆ ｅＵＩＣＣ Ｐｒｏｆｉｌｅ Ｍａｎａｇｅｒ」又は「ＰＭＣ ｈｏｌｄｅｒ」（Ｐｒｏｆｉｌｅ Ｍａｎａｇｅｍｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ ｈｏｌｄｅｒ）、ＥＭ（ｅＵＩＣＣ Ｍａｎａｇｅｒ）の内の少なくとも一つで表される。
本発明で、開通仲介サーバーは、一つ以上のバンドル管理サーバー、ないし開通仲介サーバーからイベント登録リクエスト（Ｒｅｇｉｓｔｅｒ Ｅｖｅｎｔ Ｒｅｑｕｅｓｔ、Ｅｖｅｎｔ Ｒｅｇｉｓｔｅｒ Ｒｅｑｕｅｓｔ）を受信する。
また、一つ以上の開通仲介サーバーを複合的に用いることができ、この場合、第１開通仲介サーバーは、バンドル管理サーバーだけではなく第２開通仲介サーバーからイベント登録リクエストを受信することもできる。
本発明で、開通仲介サーバーの機能は、バンドル管理サーバーに統合することもできる。
上記機能を提供する開通仲介サーバーは、ＳＰＢＭ（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ）、ＲＢＭ（Ｒｅｍｏｔｅ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ）、ＳＰＢＤＳ（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｄｉｓｃｏｖｅｒｙ Ｓｅｖｅｒ）、ＢＤＳ（Ｂｕｎｄｌｅ Ｄｉｓｃｏｖｅｒｙ Ｓｅｖｅｒ）、「ＳＭ－ＤＳ」（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ Ｄｉｓｃｏｖｅｒｙ Ｓｅｒｖｉｃｅ）、ＤＳ（Ｄｉｓｃｏｖｅｒｙ Ｓｅｒｖｉｃｅ）、ルート開通仲介サーバー（Ｒｏｏｔ ＳＭ－ＤＳ）、代替開通仲介サーバー（Ａｌｔｅｒｎａｔｉｖｅ ＳＭ－ＤＳ）の内の少なくとも一つで表される。
本発明で、バンドル管理サーバーは、バンドル又はバンドルリモート管理コマンドを生成して暗号化して伝達する機能とＳＳＰの設定及び設置されたバンドルを管理する機能を合わせたものとして通称しても良い。
また、開通仲介サーバー機能を合わせたものとして通称しても良い。
したがって、以下の本発明の多様な実施形態でバンドル管理サーバー及び開通仲介サーバーの動作は、一つのバンドル管理サーバーで行うこともできる。
また、各機能は、互いに分離した複数のバンドル管理サーバーで分けて行うこともできる。
また、本明細書でバンドル管理サーバー又は開通仲介サーバーは、バンドルサーバーとして表され得る。
バンドルサーバーは、バンドル管理サーバー、開通仲介サーバーの内の一つであっても良く、バンドル管理サーバーと開通仲介サーバーの両方を含む装置であっても良い。
「サービス提供者（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）」は、バンドル管理サーバーに要求事項を発行してバンドル生成をリクエストし、当該バンドルを介して端末にサービスを提供する事業体を指す。
例えば、通信アプリケーションが搭載されたバンドルを介して通信網接続サービスを提供する通信事業者（Ｍｏｂｉｌｅ Ｏｐｅｒａｔｏｒ）を指すことができ、通信事業者の事業サポートシステム（Ｂｕｓｉｎｅｓｓ Ｓｕｐｐｏｒｔｉｎｇ Ｓｙｓｔｅｍ：ＢＳＳ）、オペレーショナルサポートシステム（Ｏｐｅｒａｔｉｏｎａｌ Ｓｕｐｐｏｒｔｉｎｇ Ｓｙｓｔｅｍ、ＯＳＳ）、ＰＯＳ端末（Ｐｏｉｎｔ ｏｆ Ｓａｌｅ Ｔｅｒｍｉｎａｌ）、そして、その他のＩＴシステムをいずれも通称することができる。
また、本発明で、サービス提供者は、特定事業体を一つだけ表すとは限定されず、一つ以上の事業体のグループ又は連合体（ａｓｓｏｃｉａｔｉｏｎ又はｃｏｎｓｏｒｔｉｕｍ）ないし、当該グループ又は連合体を代表する代表者（ｒｅｐｒｅｓｅｎｔａｔｉｖｅ）を指称する用語として用いることもできる。
また、本発明で、サービス提供者は、事業者（Ｏｐｅｒａｔｏｒ又はＯＰ又はＯｐ．）、バンドル所有者（Ｂｕｎｄｌｅ Ｏｗｎｅｒ：ＢＯ）、イメージ所有者（Ｉｍａｇｅ Ｏｗｎｅｒ：ＩＯ）などとして名付けることもでき、各サービス提供者は、名前、及び／又は固有識別子（Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ：ＯＩＤ）を少なくとも一つ以上設定するか割り当てることができる。
もし、サービス提供者が一つ以上の事業体のグループ又は連合体又は代表者を指称する場合、任意のグループ又は連合体又は代表者の名前又は固有識別子は、当該グループ又は連合体に所属したすべての事業体ないし当該代表者と協力するすべての事業体が共有する名前又は固有識別子であっても良い。
「加入者（Ｓｕｂｓｃｒｉｂｅｒ）」は、端末に対する所有権を有するサービス供給者（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）を指称するか、端末に対する所有権を有しているユーザ（Ｅｎｄ Ｕｓｅｒ）を指称する用語として用いられる。
一般的に、前者はＭ２Ｍ端末（Ｍ２Ｍ Ｄｅｖｉｃｅ）で、後者はユーザ端末（Ｃｏｎｓｕｍｅｒ Ｄｅｖｉｃｅ）として名付けることができる。
Ｍ２Ｍ端末の場合、端末に対する所有権を有しないがサービス供給者（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）から端末を譲渡又は賃貸を受けて用いるユーザ（Ｅｎｄ Ｕｓｅｒ）が存在することができ、この場合、ユーザはサービス供給者と異なるか、または同一の場合もある。
「加入者意図（Ｓｕｂｓｃｒｉｂｅｒ ｉｎｔｅｎｔ）」は、加入者がバンドルをローカル管理又はリモート管理しようとする意図を通称する用語として用いられる。
また、ローカル管理の場合、加入者意図は、ユーザ意図（Ｅｎｄ Ｕｓｅｒ ｉｎｔｅｎｔ）を指称し、リモート管理の場合、加入者意図は、サービス供給者意図（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ ｉｎｔｅｎｔ）を指称する用語として用いることもできる。
「ユーザ同意（Ｅｎｄ Ｕｓｅｒ ｃｏｎｓｅｎｔ）」は、ユーザがローカル管理ないしリモート管理の実行に同意するかを指称する用語で用いられる。
「端末」は、移動局（ＭＳ）、ユーザ装備（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ）、ユーザターミナル（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ：ＵＴ）、無線ターミナル、アクセスターミナル（ＡＴ）、ターミナル、加入者ユニット（Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）、加入者ステーーション（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ：ＳＳ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、無線通信デバイス、無線送受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ：ＷＴＲＵ）、移動ノード、モバイル、又は他の用語として指称され得る。
端末の多様な実施形態は、セルラー電話機、無線通信機能を持つスマートフォン、無線通信機能を持つ個人携帯用端末機（ＰＤＡ）、無線モデム、無線通信機能を持つ携帯用コンピュータ、無線通信機能を持つデジタルカメラのような撮影装置、無線通信機能を持つゲーミング装置、無線通信機能を持つ音楽記憶及び再生家電製品、無線インターネット接続及びブラウジングが可能なインターネット家電製品だけではなく、そういう機能の組み合せを統合している携帯型ユニット又は端末機を含むことができる。
また、端末は、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）端末、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）端末／デバイスを含み得るが、ここに限定されることではない。
本発明で、端末は、電子装置と指称することもできる。
本発明で、電子装置にはバンドルをダウンロードして設置可能なＳＳＰが内蔵され得る。
ＳＳＰが電子装置に内蔵されない場合、物理的に電子装置と分離されたＳＳＰは、電子装置に挿入されて電子装置と接続され得る。
例えば、ＳＳＰは、カード形態で電子装置に挿入することができる。
電子装置は、端末を含むことができ、この時、端末は、バンドルをダウンロードして設置可能なＳＳＰを含む端末であっても良い。
端末にＳＳＰは内蔵することだけではなく、端末とＳＳＰが分離された場合、ＳＳＰは端末に挿入することができ、端末に挿入されて端末と接続することができる。
「Ｌｏｃａｌ Ｂｕｎｄｌｅ Ａｓｓｉｓｔａｎｔ（ＬＢＡ）」は、ＳＳＰを制御するように端末又は電子装置内に設置されたソフトウェア又はアプリケーションを指称する。
このソフトウェア又はアプリケーションは、「Ｌｏｃａｌ Ｂｕｎｄｌｅ Ｍａｎａｇｅｒ」（ＬＢＭ）と指称することができる。
「ローダー（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｌｏａｄｅｒ：ＳＰＢＬ）」は、ＳＳＰで他のバンドルを設置して活性化、非活性化、削除を管理する管理バンドルを指称する。
端末のＬＢＡ又はリモートのサーバーは、ローダーを介して特定バンドルを設置、活性化、非活性化、削除することができる。
本発明で、ローダーの動作は、ローダーを含むＳＳＰの動作としても記述することができる。
「イベント（Ｅｖｅｎｔ）」は、バンドルダウンロード（Ｂｕｎｄｌｅ Ｄｏｗｎｌｏａｄ）、又はリモートバンドル管理（Ｒｅｍｏｔｅ Ｂｕｎｄｌｅ Ｍａｎａｇｅｍｅｎｔ）、又はその他のバンドルやＳＳＰの管理／処理コマンドを通称する用語であり得る。
イベント（Ｅｖｅｎｔ）は、リモートＢｕｎｄｌｅ提供動作（Ｒｅｍｏｔｅ Ｂｕｎｄｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｏｐｅｒａｔｉｏｎ、又はＲＢＰ動作、又はＲＢＰ Ｏｐｅｒａｔｉｏｎ）又はイベント記録（Ｅｖｅｎｔ Ｒｅｃｏｒｄ）として名付けることができ、各イベント（Ｅｖｅｎｔ）は、それに対応するイベント識別子（Ｅｖｅｎｔ Ｉｄｅｎｔｉｆｉｅｒ、Ｅｖｅｎｔ ＩＤ、ＥｖｅｎｔＩＤ）又はマッチング識別子（Ｍａｔｃｈｉｎｇ Ｉｄｅｎｔｉｆｉｅｒ、Ｍａｔｃｈｉｎｇ ＩＤ、ＭａｔｃｈｉｎｇＩＤ）と、当該イベントが記憶されたバンドル管理サーバー又は開通仲介サーバーの住所（ＦＱＤＮ、ＩＰ Ａｄｄｒｅｓｓ、又はＵＲＬ）又は各サーバー識別子を少なくとも一つ以上含むデータとして指称され得る。
バンドルダウンロード（Ｂｕｎｄｌｅ Ｄｏｗｎｌｏａｄ）は、バンドル設置（Ｂｕｎｄｌｅ Ｉｎｓｔａｌｌａｔｉｏｎ）と混用することができる。
また、イベント種類（Ｅｖｅｎｔ Ｔｙｐｅ）は、特定イベントがバンドルダウンロード、リモートバンドル管理（例えば、削除、活性化、非活性化、交替、アップデートなど）、又はその他のバンドルやＳＳＰ管理／処理命令であるかを示す用語として用いることができ、動作種類（Ｏｐｅｒａｔｉｏｎ Ｔｙｐｅ又はＯｐｅｒａｔｉｏｎＴｙｐｅ）、動作分類（Ｏｐｅｒａｔｉｏｎ Ｃｌａｓｓ又はＯｐｅｒａｔｉｏｎＣｌａｓｓ）、イベントリクエスト種類（Ｅｖｅｎｔ Ｒｅｑｕｅｓｔ Ｔｙｐｅ）、イベント分類（Ｅｖｅｎｔ Ｃｌａｓｓ）、イベントリクエスト分類（Ｅｖｅｎｔ Ｒｅｑｕｅｓｔ Ｃｌａｓｓ）などとして名付けることができる。
「ローカルバンドル管理（Ｌｏｃａｌ Ｂｕｎｄｌｅ Ｍａｎａｇｅｍｅｎｔ：ＬＢＭ）」は、バンドルローカル管理（Ｂｕｎｄｌｅ Ｌｏｃａｌ Ｍａｎａｇｅｍｅｎｔ）、ローカル管理（Ｌｏｃａｌ Ｍａｎａｇｅｍｅｎｔ）、ローカル管理コマンド（Ｌｏｃａｌ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ）、ローカルコマンド（Ｌｏｃａｌ Ｃｏｍｍａｎｄ）、ローカルバンドル管理パッケージ（ＬＢＭ Ｐａｃｋａｇｅ）、バンドルローカル管理パッケージ（Ｂｕｎｄｌｅ Ｌｏｃａｌ Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋａｇｅ）、ローカル管理パッケージ（Ｌｏｃａｌ Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋａｇｅ）、ローカル管理コマンドパッケージ（Ｌｏｃａｌ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ）、ローカルコマンドパッケージ（Ｌｏｃａｌ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ）として名付けることができる。
ＬＢＭは、端末に設置されたソフトウェアなどを介して任意のバンドルを設置（Ｉｎｓｔａｌｌ）するか、特定バンドルの状態（Ｅｎａｂｌｅｄ、Ｄｉｓａｂｌｅｄ、Ｄｅｌｅｔｅｄ）を変更するか、特定バンドルの内容（例えば、バンドルの別称（Ｂｕｎｄｌｅ Ｎｉｃｋｎａｍｅ）、又はバンドル要約情報（Ｂｕｎｄｌｅ Ｍｅｔａｄａｔａ）など）を変更（ｕｐｄａｔｅ）する用途で用いられる。
ＬＢＭは、一つ以上のローカル管理コマンドを含むこともでき、この場合、各ローカル管理コマンドの対象になるバンドルは、ローカル管理コマンドごとに互いに同一であるか、又は異なる場合もある。
「リモートバンドル管理（Ｒｅｍｏｔｅ Ｂｕｎｄｌｅ Ｍａｎａｇｅｍｅｎｔ：ＲＢＭ）」は、バンドルリモート管理（Ｂｕｎｄｌｅ Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ）、リモート管理（Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ）、リモート管理コマンド（Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ）、リモートコマンド（Ｒｅｍｏｔｅ Ｃｏｍｍａｎｄ）、リモートバンドル管理パッケージ（ＲＢＭ Ｐａｃｋａｇｅ）、バンドルリモート管理パッケージ（Ｂｕｎｄｌｅ Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋａｇｅ）、リモート管理パッケージ（Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋａｇｅ）、リモート管理コマンドパッケージ（Ｒｅｍｏｔｅ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ）、リモートコマンドパッケージ（Ｒｅｍｏｔｅ Ｃｏｍｍａｎｄ Ｐａｃｋａｇｅ）として名付けることができる。
ＲＢＭは、任意のバンドルを設置（Ｉｎｓｔａｌｌ）するか、特定バンドルの状態（Ｅｎａｂｌｅｄ、Ｄｉｓａｂｌｅｄ、Ｄｅｌｅｔｅｄ）を変更するか、特定バンドルの内容（例えば、バンドルの別称（Ｂｕｎｄｌｅ Ｎｉｃｋｎａｍｅ）、又はバンドル要約情報（Ｂｕｎｄｌｅ Ｍｅｔａｄａｔａ）など）を変更（ｕｐｄａｔｅ）する用途として用いることができる。
ＲＢＭは、一つ以上のリモート管理コマンドを含むこともでき、各リモート管理コマンドの対象になるバンドルは、リモート管理コマンドごとに同一であるか、又は異なる場合もある。
「ターゲットバンドル（ｔａｒｇｅｔ Ｂｕｎｄｌｅ）」は、ローカル管理コマンドないしリモート管理コマンドの対象になるバンドルを指称する用語として用いられる。
「バンドル規則（Ｂｕｎｄｌｅ Ｒｕｌｅ）」は、目標バンドルに対してローカル管理ないしリモート管理を行う時の端末が確認しなければならない情報を指称する用語として用いられる。
また、バンドル規則は、バンドル方策（Ｂｕｎｄｌｅ Ｐｏｌｉｃｙ）、規則（Ｒｕｌｅ）、方策（Ｐｏｌｉｃｙ）などの用語と混用することができる。
「認証書（Ｃｅｒｔｉｆｉｃａｔｅ）」又はデジタル認証書（Ｄｉｇｉｔａｌ Ｃｅｒｔｉｆｉｃａｔｅ）は、公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ：ＰＫ）と秘密鍵（Ｓｅｃｒｅｔ Ｋｅｙ：ＳＫ）の対から構成される非対称鍵（Ａｓｙｍｍｅｔｒｉｃ Ｋｅｙ）基盤の相互認証（Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）に用いられるデジタル認証書（Ｄｉｇｉｔａｌ Ｃｅｒｔｉｆｉｃａｔｅ）を指す。
各認証は、一つ又は一つ以上の公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ：ＰＫ）と、各公開鍵に対応する公開鍵識別子（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｄｅｎｔｉｆｉｅｒ：ＰＫＩＤ）と、当該認証書を発給した認証書発給者（Ｃｅｒｔｉｆｉｃａｔｅ Ｉｓｓｕｅｒ：ＣＩ）の識別子（Ｃｅｒｔｉｆｉｃａｔｅ Ｉｓｓｕｅｒ ＩＤ）及びデジタル署名（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ）を含む。
また、認証書発給者（Ｃｅｒｔｉｆｉｃａｔｅ Ｉｓｓｕｅｒ）は、認証発給者（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｉｓｓｕｅｒ）、認証書発給機関（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ：ＣＡ）、認証発給機関（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ）などとして名付けることができる。
本発明で、公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ：ＰＫ）と公開鍵識別子（Ｐｕｂｌｉｃ Ｋｅｙ ＩＤ：ＰＫＩＤ）は、特定公開鍵、ないし当該公開鍵が含まれた認証書、又は特定公開鍵の一部分、ないし当該公開鍵が含まれた認証書の一部分、又は特定公開鍵の演算結果（例えば、ハッシュ（Ｈａｓｈ））値、ないし当該公開鍵が含まれた認証書の演算結果（例えば、ハッシュ（Ｈａｓｈ））値、又は特定公開鍵の一部分の演算結果（例えば、ハッシュ（Ｈａｓｈ））値、ないし当該公開鍵が含まれた認証書の一部分の演算結果（例えば、ハッシュ（Ｈａｓｈ））値、又はデータが記憶された記憶空間を指称する同じ意味で混用することができる。
「認証書チェーン（Ｃｅｒｔｉｆｉｃａｔｅ Ｃｈａｉｎ）」又は認証書階層構造（Ｃｅｒｔｉｆｉｃａｔｅ Ｈｉｅｒａｒｃｈｙ）は、「認証書発給者（Ｃｅｒｔｉｆｉｃａｔｅ Ｉｓｓｕｅｒ）」が発給した認証書（１次認証書）が他の認証書（２次認証書）を発給するのに用いられるか、２次認証書が３次以上の認証書を連係に発給するのに用いられる場合、当該認証書の相関関係を指すことができる。
この時、最初認証書発給に用いられたＣＩ認証書は、認証書ルート（Ｒｏｏｔ ｏｆ Ｃｅｒｔｉｆｉｃａｔｅ）、最上位認証書、ルートＣＩ（Ｒｏｏｔ ＣＩ）、ルートＣＩ認証書（Ｒｏｏｔ ＣＩ Ｃｅｒｔｉｆｉｃａｔｅ）、ルートＣＡ（ＲｏｏｔＣＡ）、ルートＣＡ認証書（Ｒｏｏｔ ＣＡ Ｃｅｒｔｉｆｉｃａｔｅ）などと名付けることができる。
そして、本発明を説明するにおいて、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不必要に不明瞭にすることができると判断された場合、その詳細な説明は省略する。
以下、端末の間のバンドルを移動して設置する方法及び装置に関する多様な実施形態を説明する。
図１は、本発明の実施形態によるＳＳＰの概念を示す図である。
一実施形態によれば、図１の例のように、端末１１０は、ＳＳＰ１２０を含む。
例えば、ＳＳＰ１２０は、端末１１０のＳｏＣ１３０に内蔵される。
この時、ＳｏＣ１３０は、通信プロセッサ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）又はこの２つのプロセッサが統合されたプロセッサであっても良い。
他の例として、ＳＳＰ１２０は、ＳｏＣに統合されず独立されたチップ形態として着脱型１２２であっても良く、端末１１０に予め内蔵した内蔵型１２４であっても良い。
一実施形態によれば、端末に含まれたＳＳＰ１２０は、一つ以上のテレコムバンドル、一つ以上のペイメントバンドル、又は一つ以上の電子ＩＤカードバンドルの内の少なくとも一つを含む。
例えば、図１に示すように、ＳＳＰ１２０に複数のテレコムバンドル（１４０、１５０）が含まれた場合、端末１１０は、設定によって複数のテレコムバンドル（１４０、１５０）を同時又は時分割で動作するようにして移動通信ネットワークを用いる。
また、ＳＳＰ１０にペイメントバンドル１７０及び電子ＩＤカードバンドル１８０が含まれた場合、端末１１０は、ペイメントバンドル１７０を用いて端末アプリを通じるオンライン決済又は外部クレジットカードＰｏＳ（Ｐｏｉｎｔ ｏｆ Ｓａｌｅ）機器を通じるオフライン決済を用いることができ、電子ＩＤカードバンドル１８０を用いて端末所有者の身分を認証することができる。
図２は、本発明の実施形態によるＳＳＰ（Ｓｍａｒｔ Ｓｅｃｕｒｅ Ｐｌａｔｆｏｒｍ）の内部構造の概念を示す図である。
一実施形態によれば、図２の例のように、ＳＳＰ２１０は、一つのプライマリープラットホーム（Ｐｒｉｍａｒｙ Ｐｌａｔｆｏｒｍ、ＰＰ）２２０とその上で動作する少なくとも一つのセカンダリープラットホームバンドル（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ、ＳＰＢ）（２３０、２４０）を含む。
一実施形態によれば、プライマリープラットホーム２２０は、ハードウェア（開示せず）と少なくとも一つの下位階層オペレーティングシステム（ｌｏｗ ｌｅｖｅｌ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＬＬＯＳ）２２２を含む。
一実施形態によれば、セカンダリープラットホームバンドル２３０は、上位階層オペレーティングシステム（Ｈｉｇｈ－ｌｅｖｅｌ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＨＬＯＳ）２３２とその上で動作する少なくとも一つのアプリケーション２３４を含む。
一実施形態によれば、各セカンダリープラットホームバンドル（２３０、２４０）は、プライマリープラットホームインターフェース（Ｐｒｉｍａｒｙ Ｐｌａｔｆｏｒｍ Ｉｎｔｅｒｆａｃｅ：ＰＰＩ）２５０を用いてプライマリープラットホーム２２０の中央処理装置、メモリなどのリソースに接近し、これを介してＳＳＰ２１０で駆動される。
図３は、本発明の実施形態による端末がＳＳＰでバンドルをダウンロードして設置するための端末内部構成要素の例を示す図である。
一実施形態によれば、図３の例のように、端末３１０は、ＳＳＰ３３０及び／又はＳＳＰ３３０を制御するためのＬＢＡ３１２を含む。
例えば、端末３１０は、ＳＳＰ３３０が装着されてＳＳＰ３３０を制御するためのＬＢＡ３１２が設置された端末であり得る。
例えば、ＳＳＰ３３０は、端末３１０に内蔵されるか着脱型であり得る。
一実施形態によれば、ＳＳＰ３３０は、プライマリープラットホーム３３１、セカンダリープラットホームバンドルローダー（Ｓｅｃｏｎｄａｒｙ Ｐｌａｔｆｏｒｍ Ｂｕｎｄｌｅ Ｌｏａｄｅｒ：ＳＰＢＬ）３３３、及び一つ以上のセカンダリープラットホームバンドル（３３５、３３７、３３９）の内の少なくとも一つを含む。
一実施形態によれば、セカンダリープラットホームバンドル（３３５、３３７、３３９）は、端末出荷時点にはＳＳＰ３３０内部に設置されず、出荷後にリモートでダウンロード及び設置することができる。
一実施形態によれば、図３の例のように、各バンドルは、互いに異なるバンドルファミリ識別子及び／又はバンドルファミリ管理者識別子（３４１、３４２、３４３）を持つ。
このようなバンドルファミリ識別子とバンドルファミリ管理者識別子は、バンドルのダウンロード及び設置に必要な情報として用いられる。
すなわち、ＳＳＰ３３０又はＳＰＢＬ３３３は、バンドルファミリ識別子とバンドルファミリ管理者識別子に従って特定バンドルのダウンロードと設置を許容したり拒否したりすることができる。
図４は、本発明の実施形態による２つの端末の間でバンドルの送信が行うために２つの端末が相互動作する方法の例を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図４の例のように、第１端末４００は、ＬＢＡ４１０とＳＳＰ４２０を含み、第２端末４５０は、ＬＢＡ４６０とＳＳＰ４７０を含む。
一実施形態によれば、ユーザは、端末にコマンドを送信するか、若しくはユーザが提供されなければならない情報を端末から受信する。
例えば、４０１０動作及び４０６０動作のように、第１ユーザ４４０及び第２ユーザ４９０は第１端末４００及び第２端末４５０のＬＢＡ（４１０、４６０）に命令を送信するか、若しくはＬＢＡ（４１０、４６０）からユーザが提供されなければならない情報を受信する。
一実施形態によれば、上記の動作は、ユーザが送信しようするバンドルを選択する過程を含む。
また、上記の動作は、ユーザが送信を受けようとするバンドルの情報を確認する過程をさらに含む。
また、上記の動作は、ユーザが送信しようとするバンドルの送信をするかどうかを承認する動作をさらに含み得る。
また、上記の動作は、ユーザが送信を受けようとするバンドルの送信をするかどうかを承認する動作をさらに含み得る。
また、一実施形態によれば、上記の動作は、ユーザが、使用が中止されたバンドルを使用再開で造るためにバンドルを選択する過程を含み得る。
また、上記の動作は、ユーザが使用再開リクエストを受けたバンドルの情報を確認する過程をさらに含み得る。
また、上記の動作は、ユーザが使用再開で造るバンドルを承認する動作をさらに含み得る。
また、上記の動作は、ユーザが使用再開リクエストを受けたバンドルの使用再開を承認する動作をさらに含み得る。
上述した選択と承認の動作は、互いに独立的な動作としていずれも動作されなくても良く、一つ以上の動作が互いに独立的に選択されて動作することもできる。
また、４０２０動作及び４０７０動作でＬＢＡ（４１０、４６０）は、ＳＳＰ（４２０、４７０）に命令を下すか又はＳＳＰ（４２０、４７０）とデータを送受信する。
一実施形態によれば、上記の動作で、ＬＢＡは上述のユーザのコマンドを受信し、この命令をＳＳＰに伝達する。
上記の動作で、ＬＢＡがユーザの命令を受信し、この命令をＳＳＰに伝達した場合、ＬＢＡは、その結果としてＳＳＰが送信する結果を受信する。
他の実施形態によれば、上記の動作で、ＬＢＡは他の端末又は外部サーバーから受信した命令やデータをＳＳＰに伝達する。
上記の動作で、ＬＢＡが異なる端末又は外部サーバーから受けた命令やデータをＳＳＰに伝達した場合、ＬＢＡは、その結果としてＳＳＰが送信する結果を受信する。
一実施形態によれば、上記の動作で、ＬＢＡはユーザの命令又は他の端末又は外部サーバーから受けた命令やデータに基づいて新しい命令とデータを定義し、これをＳＳＰに伝達する。
上記の動作で、ＬＢＡはユーザの命令又は他の端末又は外部サーバーから受けた命令やデータに基づいて新しい命令とデータを定義し、これをＳＳＰに伝達した場合、ＬＢＡは、その結果としてＳＳＰが送信する結果を受信する。
一実施形態によれば、上記の動作で、ＬＢＡとＳＳＰは、互いにデータを送受信してバンドルを設置する。
一実施形態によれば、４０５０動作で２つのＬＢＡ（４１０、４６０）は、互いに接続されて相手に命令を下すか相手とデータを送受信する。
この時、４０５０動作での接続は、端末と端末の直接的な機器の間の接続であっても良く、たとえ図に示さなかったが２つのＬＢＡ（４１０、４６０）の接続の間に外部個体（例えば、外部サーバー）が接続されている間接的な機器の間の接続であっても良い。
上述した２つのＬＢＡの間の接続方法に対するより詳細な技術は、後述で、図面を参照して説明する。
一実施形態によれば、４０３０動作及び４０８０動作で、ＳＳＰ（４２０、４７０）は、ＳＳＰ内部で必要なデータを生成するか処理、又は検証する。
一実施形態よれば、上記の動作で、ＳＳＰは、バンドル移動設定を確認する。
また、上記の動作で、ＳＳＰは、バンドル移動コードを生成して活用する。
上述したバンドル移動設定関連動作とバンドル移動コード関連動作は、互いに独立的な機能として、２つの機能いずれもが実行しないか、又は、２つの機能のいずれかの一つだけ実行するか、又は、２つ機能いずれもが実行することもできる。
２つ機能のいずれもが実行される場合にも２つ機能は、完全に独立された機能として行うことができる。
一実施形態によれば、上記の動作で、ＳＳＰは、自分のＳＳＰ情報を生成するか、相手の端末及び／又はサーバーから受けたＳＳＰ情報を検証する。
また、上記の動作で、ＳＳＰは、自分を検証することができる認証データを生成することもでき、相手の端末から受けた認証データを検証することもできる。
一実施形態によれば、上記の動作で、ＳＳＰは、図５で記述する「証明書」を生成し、受信した「証明書」を検証する。
ＳＳＰが生成／検証可能な多様な「証明書」の例は、後述する図１０～図１５及び図２２～図２７を参考する。
一実施形態によれば、上記の動作で、ＳＳＰは、バンドルの状態を設定する。
ＳＳＰが設定することができる多様なバンドルの状態と設定条件は、後述する図１０～図１５及び図２２～図２７を参考する。
一実施形態によれば、上記の動作で、ＳＳＰは、バンドルを生成する。
図５は、本発明の一実施形態による「証明書（Ａｔｔｅｓｔａｔｉｏｎ）」の構成を示す図である。
一実施形態によれば、証明書は、「バンドル区分者」を選択的に含む（符号５１０）。
例えば、証明書は、図５に示したようにバンドル区分者の内の一つのバンドル識別子（ＳＰＢ ＩＤ）を選択的に含み得る。
一実施形態によれば、証明書はまた、他の証明書を選択的にさらに含み得る（符号５３０）。
証明書の内に含まれるまた他の証明書の多様な実例は、後述する図１０～図１５の説明を参照する。
一実施形態によれば、証明書は、「ＳＳＰ識別子（ＳＳＰ ＩＤ）」を選択的にさらに含み得る（符号５４０）。
一実施形態によれば、証明書は、ＳＳＰが行なった動作に対する情報を選択的にさらに含み得る（符号５５０）。
ＳＳＰが行う動作の多様な実例は、後述する図１０～図１５の説明を参照する。
一実施形態によれば、証明書は、必要な場合に前述した情報（符号５３０、符号５４０、符号５５０）以外の、その他のデータを選択的にさらに含み得る（符号５２０）。
証明書の内に含まれ得るその他のデータの多様な実例は、後述する図１０～図１５の説明を参照する。
一実施形態によれば、証明書は、上述した情報に対する電子署名データを含み得る（符号５６０）。
この署名データは、ＳＳＰの署名用認証書によって生成された電子署名であっても良い。
図６は、本発明の実施形態による一つの端末で他の端末でバンドルが送信される手順を概念的に示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図６の例のように、第１端末６００は、第１ＬＢＡ６２０と第１ＳＳＰ６１０を含み、第２端末６５０は、第２ＬＢＡ６７０と第２ＳＳＰ６６０を含む。
例えば、第１端末６００は、第１ＳＳＰ６１０が装着されて第１ＳＳＰ６１０を制御するための第１ＬＢＡ６２０が設置された端末であり得、第２端末６５０は、第２ＳＳＰ６６０が装着されて第２ＳＳＰ６６０を制御するための第２ＬＢＡ６７０が設置された端末であり得る。
図６を参照すると、６０００段階で、第１端末６００の第１ＳＳＰ６１０、第１ＬＢＡ６２０と第２端末６５０の第２ＬＢＡ６７０は、バンドル送信のために必要な準備手順（バンドル送信準備手順）を行う。
上記手順に対するより詳しい説明は、後述する図７の詳細説明を参照する。
図６を参照すると、６００５段階で、第１端末６００から第２端末６５０にバンドルが送信される手順（バンドル送信手順）が行われる。
上記手順に対するより詳しい説明は、後述する図８の詳細説明を参照する。
図６を参照すると、６０１０段階で第１端末６００と第２端末６６０は、送信されたバンドルの設置手順とバンドルの状態を設定する手順（バンドル送信仕上げ手順）を行う。
上記手順に対する詳しい説明は、後述する図９～図１２の詳細説明を参照する。
図７は、図６で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。
より詳しくは、図７は、本発明の実施形態による一つの端末が他の端末にバンドルを送信するために必要な準備過程を経る手順を例示的に示す図である。
本明細書で、図７の手順は、バンドル送信準備手順として指称され得る。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図７の例のように、第１端末７００は、第１ＬＢＡ７２０と第１ＳＳＰ７１０を含み、第２端末７５０は、第２ＬＢＡ７７０と第２ＳＳＰ７６０を含む。
例えば、第１端末７００は、第１ＳＳＰ７１０が装着されて第１ＳＳＰ７１０を制御するための第１ＬＢＡ７２０が設置された端末であり得、第２端末７５０は、第２ＳＳＰ７６０が装着されて第２ＳＳＰ７６０を制御するための第２ＬＢＡ７７０が設置された端末であり得る。
一実施形態によれば、第１端末７００は、既に設置されたバンドルを保有しても良く、このバンドルと関連したメタデータをさらに保有しても良い。
一実施形態によれば、第１端末７００は、当該バンドルと関連してバンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、又はバンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つを保有し得る。
一実施形態によれば、第１端末７００は、当該バンドルと関連して「バンドル移動設定」を保有し得る。
バンドル移動設定は、当該バンドルの機器の間の送信することができるかどうかに関連する情報を選択的に含み得る。
また、バンドル移動設定は、当該バンドルが複数の端末で重複使用が可能であるかどうかに対する情報を選択的にさらに含み得る。
例えば、当該バンドルが「複数の端末で、同時に重複して用いられることが禁止」されている場合、すなわち、「ある一時点で、バンドルは一つの端末にだけ使用すべきである」場合、これに対する情報が含まれ得る。
図７を参照すると、７０００段階で、機器の間の送信されるバンドルの情報を第１ＬＢＡ７２０に伝達する。
この伝達過程は、例えば、図７に示したように、第１端末７００が提供するＵＩを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第１ＬＢＡ７２０に入力することもでき、又は、第１ＬＢＡ７２０がリモートサーバーに接続して当該情報を読み取ることもできる。
図７を参照すると、７００５段階で、７０００段階を介して選択されたバンドルに関連する情報を第１ＬＢＡ７２０から第１ＳＳＰ７１０に伝達する。
例えば、図７に示したように、上記選択されたバンドルに関連する情報を、「Ｓｅｌｅｃｔ ＳＰＢ ｃｏｍｍａｎｄ（ＳＰＢコマンド選択）」を介して第１ＬＢＡ７２０から第１ＳＳＰ７１０に伝達する。
この時、第１ＬＢＡ７２０から第１ＳＳＰ７１０に伝達する情報は、７０００段階で選択されたバンドルを識別（ｉｄｅｎｔｉｆｙ）するための情報を含む。
図７を参照すると、７０１０段階で、第１ＳＳＰ７１０は、送信をリクエストしたバンドルの機器の間の送信可能であるかどうかを確認する。
この過程は、先ず７００５段階で受信した情報に基づいて送信がリクエストされたバンドルを識別し、当該バンドルと関連した（ａｓｓｏｃｉａｔｅｄ ｗｉｔｈ）「バンドル移動設定」を確認することによって行われる。
この過程で、「バンドル移動設定」が「当該バンドルが複数の端末で重複使用が可能であるかどうかに対する情報」を含んでいる場合、第１ＳＳＰ７１０は、この事実を確認する。
また、７０１０段階で、第１ＳＳＰ７１０は、選択的に「バンドル移動コード」を設定する。
「バンドル移動コード」は、当該バンドルの機器の間の送信過程で、当該バンドルを指称するために用いられるコードとして当該バンドルを識別することができる値ではなければならない。
第１ＳＳＰ７１０は、前述した「バンドル移動コード」と送信しようとするバンドルの情報をバインディング（ｂｉｎｄｉｎｇ）する。
図７を参照すると、７０１５段階で、７００５段階に対する応答結果が第１ＳＳＰ７１０から第１ＬＢＡ７２０に送信される。
例えば、図７に示したように、「Ｓｅｌｅｃｔ ＳＰＢ ｃｏｍｍａｎｄ（ＳＰＢコマンド選択）」に対する応答が「Ｓｅｌｅｃｔ ＳＰＢ ｒｅｓｐｏｎｓｅ（ＳＰＢ応答選択）」を介して第１ＳＰＢ７１０から第１ＬＢＡ７２０に伝達される。
この応答値は、７０１０段階で記述された「バンドル移動コード」を含む。
図７を参照すると、７０２０段階で、機器の間のバンドル送信のために必要な情報が第１端末７００の第１ＬＢＡ７２０から第２端末７５０の第２ＬＢＡ７７０に伝達される。
この時、第１ＬＢＡ７２０から第２ＬＢＡ７７０に伝達する情報には「バンドル移動コード」が含まれる。
また、第１ＬＢＡ８２０から第２ＬＢＡ８７０に伝達する情報は、以後の７０２５段階で第１ＬＢＡ７２０と第２ＬＢＡ７７０の間に確立される（ｅｓｔａｂｌｉｓｈｅｄ）接続のために必要な情報を選択的にさらに含み得る。
また、第１ＬＢＡ７２０から第２ＬＢＡ７７０に伝達される情報には機器の間のバンドル移動が行われることを通知する情報が選択的にさらに含まれ得る。
上述した７０２０段階を介して第１ＬＢＡ７２０から第２ＬＢＡ７７０に伝達する情報は、多様な方法で伝達することができる。
例えば、第１ＬＢＡ７２０は、第２ＬＢＡ７７０に伝達しなければならない情報を第１端末７００のＵＩを介してユーザに提供し、ユーザは、提供された情報を第２端末７５０のＵＩを用いて第２ＬＢＡ７７０に入力する。
若しくは、第１ＬＢＡ７２０は、第２ＬＢＡ７７０に伝達しなければならない情報をイメージ（例えば、ＱＲコード（登録商標））の形態で作成し、第１端末７００の画面に表示し、ユーザは、第２端末７５０を用いてこのイメージをスキャンすることによって第２ＬＢＡ７７０に情報を伝達する。
しかし、第１ＬＢＡ７２０から第２ＬＢＡ７７０に情報を伝達する方法は、上記の方法に限らない。
図７を参照すると、７０２５段階で、第１ＬＢＡ７２０と第２ＬＢＡ７７０の間に接続が確立（又は、設定）される。
もし、７０２０段階で接続のために必要な情報が送信されると、第１ＬＢＡ７２０と第２ＬＢＡ７７０はこの情報を用いて接続を確立することもできる。
第１ＬＢＡ８２０と第２ＬＢＡ８７０の接続は、直接的な機器の間の接続であっても良く（例えば、ＮＦＣ、ブルートゥース（登録商標）、ＵＷＢ、ＷｉＦｉ－Ｄｉｒｅｃｔ、ＬＴＥ Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）、５Ｇ Ｄ２Ｄ）又は第１ＬＢＡ７２０と第２ＬＢＡ７７０の間にリモートサーバー（例えば、リレーサーバー）が配置された遠距離接続であっても良い。
図７を参照すると、７０２５段階は、最後の段階として図に示したが、この段階は前述の他の段階、すなわち、７０００段階、７００５段階、７０１０段階、７０１５段階、７０２０段階とは独立的な段階として他の段階と手順に関わらず行われることができる。
例えば、７０２５段階は、７０１５段階と７０２０段階の間で行うこともでき、この場合、７０２０段階で第１ＬＢＡ７２０から第２ＬＢＡ２７７０に送信される情報は、７０２５段階で確立された接続を介して送信される。
図８は、図６で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図面である。
より詳しくは、図８は、本発明の実施形態による一つの端末が他の端末にバンドルを送信する手順を例示的に示す図である。
本発明で、図８の手順は、バンドル送信手順として指称され得る。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図８の例のように、第１端末８００は、第１ＬＢＡ８２０と第１ＳＳＰ８１０を含み、第２端末８５０は、第２ＬＢＡ８７０と第２ＳＳＰ８６０を含む。
例えば、第１端末８００は、第１ＳＳＰ８１０が装着されて第１ＳＳＰ８１０を制御するための第１ＬＢＡ８２０が設置された端末であっても良く、第２端末８５０は、第２ＳＳＰ８６０が装着されて第２ＳＳＰ８６０を制御するための第２ＬＢＡ８７０が設置された端末であっても良い。
図８を参照すると、８０００段階で、第２ＬＢＡ８７０は、第２ＳＳＰ２８６０に「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」をリクエストする。
８０００段階で第２ＬＢＡ８７０が第２ＳＳＰ８６０に「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」をリクエストする時、第２ＬＢＡ８７０は、第２ＳＳＰ８６０に機器の間のバンドル移動が行われることを通知する。
また、８０００段階は、図８で図に示した過程に続いて直ちに自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第２端末８５０が提供するＵＩを介してユーザが直接送信されるバンドルを選択する過程を介して行うこともできて、リモートサーバーからプッシュ入力を介して第２ＬＢＡ８７０に入力することもでき、又は第２ＬＢＡ８７０がリモートサーバーに接続して当該情報を読み取ることもできる。
図８を参照すると、８００５段階で、第２ＳＳＰ８６０は、自分の「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」を生成する。
「ＳＳＰ情報」にはバンドル送信のために提供しなければならない第２ＳＳＰの情報が含まれる。
この時、「ＳＳＰ情報」には第２ＳＳＰ８６０がバンドルを受信する前に経なければならない認証書交渉過程のための情報（認証書交渉情報）が含まれる。
この「認証書交渉情報」は、第２ＳＳＰ８６０が他のＳＳＰを検証するのに用いることができる認証書情報（ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）と他のＳＳＰが自分を検証するのに用いられることができる認証書情報（ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）を含む。
また、「認証書交渉情報」は、第２ＳＳＰ８６０がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第２ＳＳＰ８６０がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また、「ＳＳＰ情報」には第２ＳＳＰ９６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むＳＳＰバージョン情報が選択的にさらに含まれ得る。
図８を参照すると、８０１０段階で、第２ＳＳＰ８６０は、第２ＬＢＡ８７０と第１ＬＢＡ８２０を経て第１ＳＳＰ８１０に８００５段階で生成した「ＳＳＰ情報」を伝達する。
以上、記述した段階で、８０１０段階によると、第２ＬＢＡ８７０が第２ＳＳＰ８６０に「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」をリクエストし、第２ＳＳＰ８６０が自分の「ＳＳＰ情報」を生成した後、第２ＳＳＰ８６０が第２ＬＢＡ８７０と第１ＬＢＡ８２０を経て第１ＳＳＰ８１０に「ＳＳＰ情報」を伝達する。
しかし、実施形態によって、第２端末８５０で第１端末８００に「ＳＳＰ情報」が伝達される過程は、次の通りである。
例えば、第２ＬＢＡ８７０が、自ら「ＳＳＰ情報」を生成した後に、第１ＬＢＡ８２０を経て第１ＳＳＰ８１０に「ＳＳＰ情報」を伝達することができる。
図８を参照すると、８０１５段階で、第１ＳＳＰ８１０は、受信した「ＳＳＰ情報」を確認してこの情報に基づいて自分を認証することができる「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を生成する。
この過程に対するより具体的な手順は、次の通りである。
第１ＳＳＰ８１０は、受信した「ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書（ｓｓｐ１．Ｃｅｒｔ．ＫＡ）を選択する。
若しくは、第１ＳＳＰ８１０は、受信した「第２ＳＳＰ８６０がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｓｐ１．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ１．ｅＰＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｓｐ１．ｅＰＫ．ＫＡ）を選択する。
また、第１ＳＳＰ８１０は、受信した「ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の署名用認証書（ｓｓｐ１．Ｃｅｒｔ．ＤＳ）をさらに選択する。
また、第１ＳＳＰ８１０は、受信した「ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて検証を行う第２ＳＳＰ８６０の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄとして設定する。
また、第１ＳＳＰ８１０は、受信した「第２ＳＳＰ８６０がサポートする暗号化アルゴリズムのリスト」を用いて今後の用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」として設定する。
また、第１ＳＳＰ８１０は、受信した「第２ＳＳＰ８６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認し、その中、自分もサポートする標準規格のバージョンが存在するかを確認する。
「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」は、前述した「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」、「ｓｓｐ１．ｅＰＫ．ＫＡ」、「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」、「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」の内の少なくとも一つを含む。
また、「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」は、前述した「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を選択的にさらに含み得る。
また、「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」は、今後に送信されるバンドルに関連したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つを選択的にさらに含み得る。
この時、上記で言及した「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され得、このデジタル署名データは、「第１端末認証情報」の一部として追加され得る。
図８を参照すると、８０２０段階で、第１ＳＳＰ８１０は、第１ＬＢＡ８２０を経て第２ＬＢＡ８７０に８０１５段階で生成した「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を伝達する。
図８を参照すると、８０２５段階で、第２ＬＢＡ８７０は、第２ＳＳＰ８６０に「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を伝達する。
また、第２ＬＢＡ８７０は、第２ＳＳＰ８６０に「バンドル移動コード」をさらに伝達する。
図８を参照すると、８０３０段階で、第２ＳＳＰ８６０は、受信した「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を検証する。
もし、第２ＳＳＰ８６０が「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第２ＳＳＰ８６０が「ｓｓｐ１．ｅＰＫ．ＫＡ」とこれに対するデジタル署名が送信された場合には、先ず、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」の有効性を検査した後、この認証書を用いてデジタル署名を確認して受信した公開鍵「ｓｓｐ１．ｅＰＫ．ＫＡ」の無欠性を確認する。
また、第２ＳＳＰ８６０は、受信した「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」を確認して自分を検証することができる少なくとも一つ以上の署名用認証書（ｓｓｐ２．Ｃｅｒｔ．ＤＳ）を選択する。
また、図には示していないが、８０３０段階で、第２ＳＳＰ９６０は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）として公開鍵「ｓｓｐ２．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ２．ｅＳＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｓｐ２．ｅＰＫ．ＫＡ）を選択することができる。
また、第２ＳＳＰ８６０は、「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵や「ｓｓｐ１．ｅＰＫ．ＫＡ」の内の一つを選択した後、この値と「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いて以後の端末１との通信中の暗号化に用いられるセッション鍵（ＳｈＫｅｙ０１）を生成することができる。
ＳｈＫｅｙ０１は、受信した「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
また、８０３０段階で、第２ＳＳＰ８６０は、自分を認証することができる「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」を生成する。
この時、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、「ｓｓｐ２．ｅＰＫ．ＫＡ」をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、ＳＳＰ２８６０によって生成された現在セッションを指称するトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、「バンドル移動コード」をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、第２ＳＳＰ９６０のＳＳＰ識別子をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、以後の送信されるバンドルに関連したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つを選択的にさらに含み得る。
この時、上記で言及した「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「第２端末認証情報」の一部として追加され得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」の一部又は全体は、先立って生成されたセッション鍵（ＳｈＫｅｙ０１）を用いて暗号化される。
図８を参照すると、８０３５段階で、第２ＳＳＰ８６０は、第２ＬＢＡ８７０と第１ＬＢＡ８２０を経て第１ＳＳＰ８１０に８０３０段階で生成した「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」を伝達する。
この時、「バンドル移動コード」が選択的にさらに送信され得る。
図８を参照すると、８０４０段階で、第１ＳＳＰ８１０は、受信した「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」を検証する。
第１ＳＳＰ８１０は、受信した「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」の署名を検証して当該認証書の有効性を検証する。
また、第１ＳＳＰ８１０は、受信したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）及び／又はバンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）が、自分が送信しようとするバンドルと関連して正しく設定された値であるかを検査する。
また、第１ＳＳＰ８１０は、受信したトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）及び／又は第２ＳＳＰ８６０のＳＳＰ識別子を記憶する。
また、第１ＳＳＰ８１０は、受信したトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）や第２ＳＳＰ９６０のＳＳＰ識別子を、現在進行しているセッション又は送信しようとするバンドルとバインディング（ｂｉｎｄｉｎｇ）させる。
この過程で、若し、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」に暗号化されたデータが含まれている場合、第１ＳＳＰ８１０は、送信された「ｓｓｐ２．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵に対応される秘密鍵や「ｓｓｐ１．ｅＰＫ．ＫＡ」を用いてセッション鍵（ＳｈＫｅｙ０１）を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後の検証過程を行う。
また、この過程で、もし、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」にデジタル署名が含まれている場合、第１ＳＳＰ８１０は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を用いて受信したデジタル署名の有効性を検証する。
また８０４０段階で、図８に示していないが、第１ＳＳＰ８１０は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」を生成することができる。
この時、鍵の対「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」は、先立って生成された「ｓｓｐ１．ｅＰＫ．ＫＡ」と「ｓｓｐ１．ｅＰＫ．ＫＡ」と同一値で設定することもできる。
又は、鍵の対「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」は、先立って用いられた「「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」に含まれている公開鍵とここに対応される秘密鍵」と同一値で設定することもできる。
また、第１ＳＳＰ８１０は、「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」と「ｓｓｐ２．ｅＰＫ．ＫＡ」を用いてセッション鍵（ＳｈＫｅｙ０２）を生成することができる。
もし、「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」のために「ｓｓｐ１．ｅＰＫ．ＫＡ」又は「ｓｓｐ１．Ｃｅｒｔ．Ｋａ」に含まれている公開鍵に対応される秘密鍵が再使用されると、セッション鍵（ＳｈＫｅｙ０２）の値も以前に生成されたＳｈＫｅｙ０１の値で設定することができる。
また８０４０段階で、第１ＳＳＰ８１０は、第２端末８５０で送信するバンドル及び／又はバンドルと関連したメタデータを構成する。
この時、第１ＳＳＰ８１０は、受信した「バンドル移動コード」を用いて自分が送信しようとするバンドルを識別する。
また、構成されるバンドルには「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」が含まれ得る。
また、構成されるバンドルには「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」がさらに含まれ得る。
また、構成されるバンドルは、当該セッションを識別するトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）をさらに含み得る。
また、構成されるバンドルには、送信されるバンドルと関連したバンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが選択的にさらに含まれ得る。
一実施形態によれば、８０４０段階で、構成されるバンドル（又は、バンドルと関連したメタデータ）内には「バンドル移動設定」が含まれ得る。
一実施形態によれば、８０４０段階で、構成されるバンドルには「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を用いて生成されたデジタル署名データが追加される。
すなわち、上記で明示したバンドルの構成要素一部又は全体に対して生成されたデジタル署名データがバンドルの一部として追加される。
また、構成されるバンドルの一部又は全体は、ＳｈＫｅｙ０２を用いて暗号化される。
図８を参照すると、８０４５段階で、第１ＳＳＰ８１０は、第１ＬＢＡ８２０を経て第２ＬＢＡ８７０に８０４０段階で生成した（構成された）バンドルを伝達する。
この時、送信されるバンドルと関連したメタデータが選択的にさらに送信され得る。
また、送信されるバンドルと関連した「バンドル移動設定」がさらに送信され得る。
例えば、「バンドル移動設定」がバンドル又はメタデータに含まれず、別途のフォーマット（例えば、メッセージ）で送信され得る。
図９は、図６で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。
より詳しくは、図９は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順の可能な一例示を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図９の例のように、第１端末９００は、第１ＬＢＡ９２０と第１ＳＳＰ９１０を含み、第２端末９５０は、第２ＬＢＡ９７０と第２ＳＳＰ９６０を含む。
例えば、第１端末９００は、第１ＳＳＰ９１０が装着されて第１ＳＳＰ９１０を制御するための第１ＬＢＡ９２０が設置された端末であっても良く、第２端末９５０は、第２ＳＳＰ９６０が装着されて第２ＳＳＰ９６０を制御するための第２ＬＢＡ９７０が設置された端末であっても良い。
１．〔バンドル設置〕
図９を参照すると、９０００段階で、第２ＬＢＡ９７０と第２ＳＳＰ９６０は、互いに協業して第２端末９５０にバンドルを設置する。
この過程で次の手順が共に行われる。
もし、メタデータが送信された場合、第２ＬＢＡ９７０又は第２ＳＳＰ９６０は、メタデータに含まれた内容を検証する。
もし、「バンドル移動設定」が送信されると、第２ＬＢＡ９７０は、この情報を第２ＳＳＰ９６０に伝達する。
もし、トランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）が送信されると、第２ＬＢＡ９７０又は第２ＳＳＰ９６０は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが送信されると、第２ＬＢＡ９７０又は第２ＳＳＰ９６０は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」が送信されると、第２ＳＳＰ９６０は、この認証書の有効性を検証して第１ＳＳＰ９１０を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第２ＳＳＰ９６０は、送信された「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いてセッション鍵（ＳｈＫｅｙ０２）を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第２ＳＳＰ９６０は、「ｓｓｐ１．Ｃｅｒ．ＤＳ」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
２．〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第２ＬＢＡ９７０及び／又は第２ＳＳＰ９６０は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができる。
この判断をする幾つかの可能な方法は、次の通りである。
可能な一例として、もし、バンドル移動設定に当該バンドルが複数の端末で重複使用が可能であるかどうかが含まれていると、第２ＬＢＡ９７０及び／又は第２ＳＳＰ９６０は、この情報を確認することによって判断を下すことができる。
他の可能な例として、第２ＬＢＡ９７０及び／又は第２ＳＳＰ９６０は、受信したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）及び／又はバンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）を用いて当該バンドルが複数の端末で重複使用が可能であるかどうかを確認することもできる。
この過程は、９０００段階の一部として９０００段階で行われる手順と順序に関わらず行うこともでき、若しくは９０００段階以後に行うこともできる。
３．〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能なバンドルで判断された場合、バンドルの状態を追加的に設定する過程は、必要ではないこともある。
若しくは、第２ＬＢＡ９７０及び／又は第２ＳＳＰ９６０が当該バンドルの重複使用をするかどうかを判断しない場合にも、第２ＬＢＡ９７０及び／又は第２ＳＳＰ９６０の具現によってバンドルの状態を追加的に設定する過程は、必要ではないこともある。
図１０は、図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図１０は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順のまた他の例示を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１０の例のように、第１端末１０００は、第１ＬＢＡ１０２０と第１ＳＳＰ１０１０を含み、第２端末１０５０は、第２ＬＢＡ１０７０と第２ＳＳＰ１０６０を含む。
例えば、第１端末１０００は、第１ＳＳＰ１０１０が装着されて第１ＳＳＰ１０１０を制御するための第１ＬＢＡ１０２０が設置された端末であっても良く、第２端末１０５０は第２ＳＳＰ１０６０が装着されて第２ＳＳＰ１０６０を制御するための第２ＬＢＡ１０７０が設置された端末であっても良い。
１．〔バンドル設置〕
図１０を参照すると、１００００段階で、第２ＬＢＡ１０７０と第２ＳＳＰ１０６０は、互いに協業して第２端末１０５０にバンドルを設置する。
これに対する詳細な説明は、図９の「バンドル設置」過程を参照する。
２．〔重複使用可能であるかどうか確認〕
また、図には示してなかったが、第２ＬＢＡ１０７０及び／又は第２ＳＳＰ１０６０は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができる。
これに対する詳細な説明は、図９の「重複使用可能であるかどうか確認」過程を参照する。
３．〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第２ＬＢＡ１０７０及び／又は第２ＳＳＰ１０６０が当該バンドルの重複使用をするかどうかを判断しない場合にも、第２ＬＢＡ１０７０及び／又は第２ＳＳＰ１０６０の具現によって下記のようにバンドルの状態を追加的に設定する過程を行うことができる。
図１０を参照すると、１０００５段階で、第２ＳＳＰ１０６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」として設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されたが未だ使用が不可能な状態（さらに、「他の端末のリクエスト（例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」や「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を送信することによって行われるリクエスト）」及び／又は「（本発明では説明されなかったが）の外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）で変更することができる状態）を意味する。
図１０を参照すると、１００１０段階で、第２ＬＢＡ１０７０は、第２ＳＳＰ１０６０に「証明書」をリクエストする。
図１０を参照すると、１００１５段階で、第２ＳＳＰ１０６０は、「証明書」を生成する。
図１０で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５で開示した構造による。
この時、可能な証明書構成の一つ例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を生成した時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１０を参照すると、１００２０段階で、第２ＳＳＰ１０６０は、第１ＳＳＰ１０１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１０６０は、第１ＳＳＰ１０１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１０６０は、第２ＬＢＡ１０７０に１００１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡは、第１ＬＢＡ１０２０を経て第１ＳＳＰに「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図１０を参照すると、１００２５段階で、第１ＳＳＰ１０１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報が、バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更するかを確認する過程をさらに含む。
また、１００２５段階で、第１ＳＳＰ１０１０は、検証が済んだ後のバンドルを削除する。
また、１００２５段階で、第１ＳＳＰ１０１０は、「証明書」を生成する。
図１０で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図５で開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５３０に受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を含む。
この時、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部情報は、必要によって省略され得る。
例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれている第２ＳＳＰの署名情報は、場合によって省略され得る。
また、例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれている時間情報は、場合によって省略され得る。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１０を参照すると、１００３０段階で、第１ＳＳＰ１０１０は、第２ＳＳＰ１０６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ１０１０は、第１ＬＢＡ１０２０と第２ＬＢＡ１０７０を経て第２ＳＳＰ１０６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図１０を参照すると、１００３５段階で、第２ＳＳＰ１０６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
また、１００３５段階で、第２ＳＳＰ１０６０は、検証が済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ１０６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
図１０を参照すると、１００４０段階で、第２ＳＳＰ１０６０は、１００３５段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第２ＬＢＡ１０７０に送信する。
図１１は、図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図１１は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順のまた他の例示を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１１の例のように、第１端末１１００は、第１ＬＢＡ１１２０と第１ＳＳＰ１１１０を含み、第２端末１１５０は、第２ＬＢＡ１１７０と第２ＳＳＰ１１６０を含む。
例えば、第１端末１１００は、第１ＳＳＰ１１１０が装着されて第１ＳＳＰ１１１０を制御するための第１ＬＢＡ１１２０が設置された端末であっても良く、第２端末１１５０は、第２ＳＳＰ１１６０が装着されて第２ＳＳＰ１１６０を制御するための第２ＬＢＡ１１７０が設置された端末であっても良い。
１．〔バンドル設置〕
図１１を参照すると、１１０００段階で、第２ＬＢＡ１１７０と第２ＳＳＰ１１６０は、互いに協業して第２端末１１５０にバンドルを設置する。
これに対する詳細な説明は、図９の「バンドル設置」過程を参照する。
２．〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第２ＬＢＡ１１７０及び／又は第２ＳＳＰ１１６０は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができ、これに対する詳細な説明は、図９の「重複使用可能であるかどうか確認」過程を参照する。
３．〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第２ＬＢＡ１１７０及び／又は第２ＳＳＰ１１６０が、当該バンドルの重複使用をするかどうかを判断しない場合にも、第２ＬＢＡ１１７０及び／又は第２ＳＳＰ１１６０の具現によって下記のようにバンドルの状態を追加的に設定する過程が行われる。
図１１を参照すると、１１００５段階で、第２ＳＳＰ１１６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」で設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に対する説明は、１０００５段階の説明を参照する。
図１１を参照すると、１１０１０段階で、第２ＬＢＡ１１７０は、第２ＳＳＰ１１６０に「証明書」をリクエストする。
図１１を参照すると、１１０１５段階で、第２ＳＳＰ１１６０は、「証明書」を生成する。
図１１で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態として設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１１を参照すると、１１０２０段階で、第２ＳＳＰ１１６０は、第１ＳＳＰ１１１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１１６０は、第１ＳＳＰ１１１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１１６０は、第２ＬＢＡ１１７０に１１０１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡは、第１ＬＢＡ１１２０を経て第１ＳＳＰに「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図１１を参照すると、１１０２５段階で、第１ＳＳＰ１１１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ 識別子」が第２ＳＳＰの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、１１０２５段階で、第１ＳＳＰ１１１０は、検証が済んだ後のバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定する。
また、１１０２５段階で、第１ＳＳＰ１１１０は、「証明書」を生成する。
図１１で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更したことを意味する情報をむ。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５３０に受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を含む。
この時、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部情報は、必要によって省略され得る。
例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれている第２ＳＳＰの署名情報は、場合によって省略され得る。
また、例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれている時間情報は、場合によって省略され得る。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１１を参照すると、１１０３０段階で、第１ＳＳＰ１１１０は、第２ＳＳＰ１１６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ１１１０は、第１ＬＢＡ１１２０と第２ＬＢＡ１１７０を経て第２ＳＳＰ１１６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図１１を参照すると、１１０３５段階で、第２ＳＳＰ１１６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報が正しいか確認する過程をさらに含み得る。
また、１１０３５段階で、第２ＳＳＰ１１６０は、検証が済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ１１６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
また、１１０３５段階で、第２ＳＳＰ１１６０は、「証明書」を生成する。
図１１で、この証明書は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５５０に第２ＳＳＰがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５２０に第２ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５３０に受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を含む。
この時、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部情報は、必要によって省略され得る。
例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれている署名情報の一部は、場合によって省略され得る。
また、例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれている時間情報の一部は、場合によって省略され得る。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５５０に第２ＳＳＰがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５２０に第２ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１１を参照すると、１１０４０段階で、第２ＳＳＰ１１６０は、第１ＳＳＰ１１１０に「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を伝達する。
例えば、第２ＳＳＰ１１６０は、第２ＬＢＡ１１７０と第１ＬＢＡ１１２０を経て第１ＳＳＰに「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を伝達する。
図１１を参照すると、１１０４５段階で、第１ＳＳＰ１１１０は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を検証する。
この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれたコマンド情報がバンドルの状態を使用可能な状態に変更することであるかを確認する過程をさらに含み得る。
また、１１０４５段階で、第１ＳＳＰ１１１０は、検証が済んだ後のバンドルを削除する。
図１２は、図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図１２は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順のまた他の例示を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１２の例のように、第１端末１２００は、第１ＬＢＡ１２２０と第１ＳＳＰ１２１０を含み、第２端末１２５０は第２ＬＢＡ１２７０と第２ＳＳＰ１２６０を含む。
例えば、第１端末１２００は、第１ＳＳＰ１２１０が装着されて第１ＳＳＰ１２１０を制御するための第１ＬＢＡ１２２０が設置された端末であっても良く、第２端末１２５０は、第２ＳＳＰ１２６０が装着されて第２ＳＳＰ１２６０を制御するための第２ＬＢＡ１２７０が設置された端末であっても良い。
１．〔バンドル設置〕
図１２を参照すると、１２０００段階で第２ＬＢＡ１２７０と第２ＳＳＰ１２６０は、互いに協業して第２端末１２５０にバンドルを設置する。
これに対する詳細な説明は、図９の「バンドル設置」過程を参照する。
２．〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第２ＬＢＡ１２７０及び／又は第２ＳＳＰ１２６０は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができ、これに対する詳細な説明は、図９の「重複使用可能であるかどうか確認」過程を参照する。
３．〔バンドル状態設定〕
もし、当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第２ＬＢＡ１２７０及び／又は第２ＳＳＰ１２６０が、当該バンドルの重複使用をするかどうかを判断しない場合にも、第２ＬＢＡ１２７０及び／又は第２ＳＳＰ１２６０の具現によって、下記のようにバンドルの状態を追加的に設定する過程が行われる。
図１２を参照すると、１２００５段階で、第２ＳＳＰ１２６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」で設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に対する説明は、１０００５段階の説明を参照する。
図１２を参照すると、１２０１０段階で、第２ＬＢＡ１２７０は、第２ＳＳＰ１２６０に「証明書」をリクエストする。
図１２を参照すると、１２０１５段階で、第２ＳＳＰ１２６０は、「証明書」を生成する。
図１２で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を生成した時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１２を参照すると、１２０２０段階で、第２ＳＳＰ１２６０は、第１ＳＳＰ１２１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１２６０は、第１ＳＳＰ１２１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１２６０は、第２ＬＢＡ１２７０に１２０１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡは、第１ＬＢＡ１２２０を経て第１ＳＳＰに「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図１２を参照すると、１２０２５段階で、第１ＳＳＰ１２１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、１２０２５段階で、第１ＳＳＰ１２１０は、検証を済んだ後のバンドルの状態を「ＳＵＳＰＥＮＳＩＯＮ」状態で設定する。
「ＳＵＳＰＥＮＳＩＯＮ」は、バンドル使用が不可能な状態（さらに、「他の端末のリクエスト（例えば、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を送信することによって行われるリクエスト）」及び／又は「（本発明では説明しなかったが）外部サーバーのリクエスト」によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）に変更することができる状態）を意味する。
また、図に示さなかったが、前述した「ＳＵＳＰＥＮＳＩＯＮ」状態は、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に取り替えることもできる。
また、１２０２５段階で、第１ＳＳＰ１２１０は、「証明書」を生成する。
図１２で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルの状態を「ＳＵＳＰＥＮＳＩＯＮ」（若しくは、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」）状態に変更したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５３０に受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を含む。
この時、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部情報は、必要によって省略され得る。
例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれている第２ＳＳＰの署名情報は、場合によって省略され得る。
また、例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれている時間情報は、場合によって省略され得る。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルの状態を「ＳＵＳＰＥＮＳＩＯＮ」（若しくは、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」）状態に変更したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１２を参照すると、１２０３０段階で、第１ＳＳＰ１２１０は、第２ＳＳＰ１２６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ１２１０は、第１ＬＢＡ１２２０と第２ＬＢＡ１２７０を経て第２ＳＳＰ１２６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図１２を参照すると、１２０３５段階で、第２ＳＳＰ１２６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報が正しいか確認する過程をさらに含み得る。
また、１２０３５段階で、第２ＳＳＰ１２６０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ１２６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
図１２を参照すると、１２０４０段階で、第２ＳＳＰ１２６０は、１２０３５段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第２ＬＢＡ１２７０に送信する。
図１３は、使用が中止されたバンドルをさらに使用可能にする手順の例を示す図である。
より詳しくは、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態や「ＳＵＳＰＥＮＳＩＯＮ」状態にあるバンドルをさらに使用可能な状態で設定する手順の一例を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１３の例のように、第１端末１３００は、第１ＬＢＡ１３２０と第１ＳＳＰ１３１０を含み、第２端末１３５０は、第２ＬＢＡ１３７０と第２ＳＳＰ１３６０を含む。
例えば、第１端末１３００は、第１ＳＳＰ１３１０が装着されて第１ＳＳＰ１３１０を制御するための第１ＬＢＡ１３２０が設置された端末であっても良く、第２端末１３５０は、第２ＳＳＰ１３６０が装着されて第２ＳＳＰ１３６０を制御するための第２ＬＢＡ１３７０が設置された端末であっても良い。
図１３で開示した手順が行われる前のバンドルの状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態や「ＳＵＳＰＥＮＳＩＯＮ」状態で設定されている場合の可能な例は、次の通りである。
例えば、図１１に開示したバンドルの送信が仕上げられる段階で、１１０２５段階が行われたが、１１０４５段階が行われない場合、第１端末１３００にあるバンドルの状態は「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態で設定されているだろう。
また他の例で、図１２に開示したバンドルの送信が仕上げられる段階で、１２０２５段階が行われると、第１端末１３００にあるバンドルの状態は、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態又は「ＳＵＳＰＥＮＳＩＯＮ」状態で設定されているだろう。
図１３を参照すると、１３０００段階で、使用再開をリクエストするバンドルの情報を第２ＬＢＡ１３７０に伝達する。
この伝達過程は、第２端末１３５０が提供するＵＩを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第２ＬＢＡ１３７０に入力することもでき、又は第２ＬＢＡ１３７０がリモートサーバーに接続して当該情報を読み取ることもできる。
図１３を参照すると、１３００５段階で、１３０００段階で選択されたバンドルの情報を第２ＬＢＡ１３７０から第２ＳＳＰ１３６０に伝達する。
この時、第２ＬＢＡ１３７０から第２ＳＳＰ１３６０に伝達する情報は、１３０００段階で選択されたバンドルを識別（ｉｄｅｎｔｉｆｙ）するための情報を含む。
図１３を参照すると、１３０１０段階で、第２ＳＳＰ１３６０は、当該バンドルを削除する。
また、第２ＳＳＰ１３６０は、「証明書」を生成する。
図１３でこの証明書は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１３を参照すると、１３０１５段階で、第２ＳＳＰ１３６０は、第１ＳＳＰ１３１０に「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１３６０は、第１ＳＳＰ１３１０に次のような過程を経て「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１３６０は、第２ＬＢＡ１３７０に１３００５段階の応答で「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡ１３７０は、第１ＬＢＡ１３２０を経て第１ＳＳＰ１３１０に「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
図１３を参照すると、１３０２０段階で、第１ＳＳＰ１３１０は、受信した「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰ１３６０の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」を確認する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」を検査する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
また、１３０２０段階で、第１ＳＳＰ１３１０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）で変更する。
例えば、図に示したように、第１ＳＳＰ１３１０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態で変換する。
図１３を参照すると、１３０２５段階で、第１ＳＳＰ１３１０は、１３０２０段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第１ＬＢＡ１３２０に送信する。
図１４は、使用が中止されたバンドルをさらに使用可能にするまた他の手順の例を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１４の例のように、第１端末１４００は、第１ＬＢＡ１４２０と第１ＳＳＰ１４１０を含み、第２端末１４５０は、第２ＬＢＡ１４７０と第２ＳＳＰ１４６０を含む。
例えば、第１端末１４００は、第１ＳＳＰ１４１０が装着されて第１ＳＳＰ１４１０を制御するための第１ＬＢＡ１４２０が設置された端末であっても良く、第２端末１４５０は、第２ＳＳＰ１４６０が装着されて第２ＳＳＰ１４６０を制御するための第２ＬＢＡ１４７０が設置された端末であっても良い。
図１４で開示した手順が行われる前のバンドルの状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態や「ＳＵＳＰＥＮＳＩＯＮ」状態で設定されている場合の可能な例は、次の通りである。
例えば、図１１に開示したバンドルの送信が仕上げられる段階で、１１０２５段階が行われたが１１０４５段階が行われない場合、第１端末１４００にあるバンドルの状態は、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態で設定されているだろう。
また他の例で、図１２に開示したバンドルの送信が仕上げられる段階で、１２０２５段階が行われると、第１端末１４００にあるバンドルの状態は、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態又は「ＳＵＳＰＥＮＳＩＯＮ」状態で設定されているだろう。
図１４を参照すると、１４０００段階で、使用再開をリクエストするバンドルの情報が第２ＬＢＡ１４７０に伝達される。
この伝達過程は、第２端末１４５０が提供するＵＩを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第２ＬＢＡ１４７０に入力することもでき、又は第２ＬＢＡ１４７０がリモートサーバーに接続して当該情報を読み取ることもできる。
図１４を参照すると、１４００５段階から１４０００段階で選択されたバンドルの情報が第２ＬＢＡ１４７０から第２ＳＳＰ１４６０に伝達する。
この時、第２ＬＢＡ１４７０から第２ＳＳＰ１４６０に伝達される情報は、１４０００段階で選択されたバンドルを識別（ｉｄｅｎｔｉｆｙ）するための情報を含む。
図１４を参照すると、１４０１０段階で、第２ＳＳＰ１４６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態で設定する。
また、第２ＳＳＰ１４６０は、当該バンドルの状態変更に関連する「証明書」を生成する。
図１４で、この証明書は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１４を参照すると、１４０１５段階で、第２ＳＳＰ１４６０は、第１ＳＳＰ１４１０に「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１４６０は、第１ＳＳＰ１４１０に次のような過程を経て「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１４６０は、第２ＬＢＡ１４７０に１４００５段階の応答で「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡ１４７０は、第１ＬＢＡ１４２０を経て第１ＳＳＰ１４１０に「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
図１４を参照すると、１４０２０段階で、第１ＳＳＰ１４１０は、受信した「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰ１４６０の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」を確認する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更するものであるかを確認する過程をさらに含み得る。
また、１４０２０段階で、第１ＳＳＰ１４１０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第１ＳＳＰ１４１０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
また、１４０２０段階で、第１ＳＳＰ１４１０は、「証明書」を生成する。
図１４で、この証明書は、「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５３０に受信した「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を含む。
この時、受信した「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」の一部情報は、必要によって省略され得る。
例えば、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれている第２ＳＳＰの署名情報は場合によって省略され得る。
また、例えば、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれている時間情報は、場合によって省略され得る。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１４を参照すると、１４０２５段階で、第１ＳＳＰ１４１０は、第２ＳＳＰ１４６０に「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ１４１０は、第１ＬＢＡ１４２０と第２ＬＢＡ１４７０を経て第２ＳＳＰ１４６０に「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」を伝達する。
図１４を参照すると、１４０３０段階で、第２ＳＳＰ１４６０は、受信した「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰ１４６０の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」に含まれた「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｓｐｏｎｓｅ」に含まれたコマンド情報が正しいコマンド情報であるか確認する過程をさらに含み得る。
また、１４０３０段階で、第２ＳＳＰ１４６０は、検証を済んだ後のバンドルを削除する。
図１４を参照すると、１４０３５段階で、第２ＳＳＰ１４６０は、１４０３０段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第２ＬＢＡ１４７０に送信する。
図１５は、使用が中止されたバンドルをさらに使用可能にするまた他の手順の例を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１５の例のように、第１端末１５００は、第１ＬＢＡ１５２０と第１ＳＳＰ１５１０を含み、第２端末１５５０は、第２ＬＢＡ１５７０と第２ＳＳＰ１５６０を含む。
例えば、第１端末１５００は、第１ＳＳＰ１５１０が装着されて第１ＳＳＰ１５１０を制御するための第１ＬＢＡ１５２０が設置された端末であっても良く、第２端末１５５０は、第２ＳＳＰ１５６０が装着されて第２ＳＳＰ１５６０を制御するための第２ＬＢＡ１５７０が設置された端末であっても良い。
図１５で開示した手順が行われる前のバンドルの状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態や「ＳＵＳＰＥＮＳＩＯＮ」状態で設定されている場合の可能な例は、次の通りである。
例えば、図１１に開示したバンドルの送信が仕上げられる段階で、１１０２５段階が行われたが１１０４５段階が行われない場合、第１端末１５００にあるバンドルの状態は「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態で設定されているだろう。
また他の例で、図１２に開示したバンドルの送信が仕上げられる段階で、１２０２５段階が行われると、第１端末１５００にあるバンドルの状態は「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態又は「ＳＵＳＰＥＮＳＩＯＮ」状態に設定されているだろう。
図１５を参照すると、１５０００段階で、使用再開をリクエストするバンドルの情報が第２ＬＢＡに伝達される。
この伝達過程は、第２端末１５５０が提供するＵＩを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第２ＬＢＡ１５７０に入力することもでき、又は第２ＬＢＡ１５７０がリモートサーバーに接続して当該情報を読み取ることもできる。
図１５を参照すると、１５００５段階で、１５０００段階で選択されたバンドルの情報を第２ＬＢＡ１５７０から第２ＳＳＰ１５６０に伝達する。
この時、第２ＬＢＡ１５７０から第２ＳＳＰ１５６０に伝達する情報は、１５０００段階で選択されたバンドルを識別（ｉｄｅｎｔｉｆｙ）するための情報を含み得る。
図１５を参照すると、１５０１０段階で、第２ＳＳＰ１５６０は、当該バンドルの状態を「ＳＵＳＰＥＮＳＩＯＮ」に変更する。
この時、図には示さなかったが、前述した「ＳＵＳＰＥＮＳＩＯＮ」状態は、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に取り替えられる。
また、第２ＳＳＰ１５６０は、「証明書」を生成する。
図１５で、この証明書は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルの状態を「ＳＵＳＰＥＮＳＩＯＮ」や「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に変更したことを意味する情報を含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
・「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１５を参照すると、１５０１５段階で、第２ＳＳＰ１５６０は、第１ＳＳＰ１５１０に「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１５６０は、第１ＳＳＰ１５１０に次のような過程を経て「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１５６０は、第２ＬＢＡ１５７０に１５００５段階の応答で「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡ１５７０は、第１ＬＢＡ１５２０を経て第１ＳＳＰ１５１０に「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を伝達する。
図１５を参照すると、１５０２０段階で、第１ＳＳＰ１５１０は、受信した「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰ１５６０の署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」を確認する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を正しく変更することか確認する過程をさらに含み得る。
また、１５０２０段階で、第１ＳＳＰ１５１０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）で変更する。
例えば、図に示したように、第１ＳＳＰ１５１０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変更する。
図１５を参照すると、１５０２５段階で、第１ＳＳＰ１５１０は、１５０２０段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第１ＬＢＡ１５２０に送信する。
図１６は、本発明の実施形態による端末の概略構成を示すブロック図である。
図１６に示すように、端末は、送受信部（Ｔｒａｎｓｃｅｉｖｅｒ）１６１０及び少なくとも一つのプロセッサ１６２０を含む。
また、端末は、ＳＳＰ１６３０をさらに含む。
例えば、ＳＳＰ１６３０は、端末に挿入することもでき、端末に内蔵されることもできる。
少なくとも一つ以上のプロセッサ１６２０は、「制御部」として名付けることもできる。
ただ、端末の構成は、図１６に制限されず、図１６に示した構成要素より多い構成要素を含むか、より少ない構成要素を含むこともできる。
一実施形態によれば、送受信部１６１０、少なくとも一つのプロセッサ１６２０、及びメモリ（図示せず）は、一つのチップ（Ｃｈｉｐ）形態で具現され得る。
また、ＳＳＰ１６３０が内蔵される場合、ＳＳＰ１６３０を含み、一つのチップ形態で具現され得る。
一実施形態によれば、送受信部１６１０は、他の端末の送受信部又は外部サーバーと本発明の実施形態による信号、情報、データなどを送信及び受信する。
送受信部１６１０は、送信される信号の周波数を上昇変換（ｕｐ ｃｏｎｖｅｒｔｉｎｇ）及び増幅するＲＦ送信機と、受信される信号を低雑音増幅して周波数を下降変換（ｄｏｗｎ ｃｏｎｖｅｒｔｉｎｇ）するＲＦ受信機などで構成される。
ただ、これは送受信部１６１０の一実施形態だけであって、送受信部１６１０の構成要素がＲＦ送信機及びＲＦ受信機に限定されることではない。
また、送受信部１６１０は、無線チャンネルを介して信号を受信して、少なくとも一つのプロセッサ１６２０に出力し、少なくとも一つのプロセッサ１６２０から出力された信号を、無線チャンネルを介して送信する。
一実施形態によれば、送受信部１６１０は、他の端末の送受信部又は外部サーバーから他の端末に含まれたＳＳＰの情報、他の端末を認証することができる認証情報、自分を認証することができる認証情報、バンドル移動コード、バンドル移動設定、バンドル、図１０～図１５で記載した多様な証明書などを送信するか、受信する。
一方、少なくとも一つのプロセッサ１６２０は、端末を全般的に制御するための構成要素である。
少なくとも一つのプロセッサ１６２０は、上述のような本発明の多様な実施形態によって、端末の全般的な動作を制御する。
一方、ＳＳＰ１６３０は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置され得る。
一実施形態によれば、ＳＳＰ１６３０内の少なくとも一つのプロセッサ又はコントローラーは、バンドル移動設定を確認して、特定バンドルを送信するかどうかを決定する。
また、バンドル移動設定を確認して、当該バンドルが複数の端末で重複使用が可能であるかどうかを確認する。
また、一実施形態によれば、ＳＳＰ内の少なくとも一つ以上のプロセッサ又はコントローラーは、バンドル移動コードを生成して特定バンドルの送信過程を制御する。
また、一実施形態によれば、ＳＳＰ内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分のＳＳＰ情報を生成し、外部から送信された他のＳＳＰのＳＳＰ情報を確認して検証する。
また、一実施形態によれば、ＳＳＰ内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分を検証することができる認証情報を生成し、外部から送信された他のＳＳＰの認証情報を検証する。
また、一実施形態によれば、ＳＳＰ１３３０は、バンドルを生成し、単独又は一つ以上のプロセッサ１６２０と協力してバンドルを設置する。
また、ＳＳＰ１６３０は、バンドルを管理する。
また、一実施形態によれば、ＳＳＰ１６３０は、図１０～図１５で記載した多様な形態の証明書を生成し、受信した証明書を検証する。
また、一実施形態によれば、ＳＳＰ１６３０は、図１０～図１５で記載したように受信した証明書の内容に基づいてバンドルの状態を変更する。
また、一実施形態によれば、ＳＳＰ１６３０は、プロセッサ１６２０の制御によって動作する。
又は、ＳＳＰ１６３０は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置されても良い。
アプリケーションの一部又は全部は、ＳＳＰ１６３０又はメモリ（図示せず）に設置することもできる。
一方、端末は、メモリ（図示せず）をさらに含み、端末の動作のための基本プログラム、アプリケーション、設定情報などのデータを記憶する。
また、メモリは、フラッシュメモリタイプ（Ｆｌａｓｈ Ｍｅｍｏｒｙ Ｔｙｐｅ）、ハードディスクタイプ（Ｈａｒｄ Ｄｉｓｋ Ｔｙｐｅ）、マルチメディアカードマイクロタイプ（Ｍｕｌｔｉｍｅｄｉａ Ｃａｒｄ Ｍｉｃｒｏ Ｔｙｐｅ）、カードタイプのメモリ（例えば、ＳＤ又はＸＤメモリなど）、磁気メモリ、磁気ディスク、光ディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）の内の少なくとも一つの記憶媒体を含み得る。
また、プロセッサ１６２０は、メモリに記憶された各種プログラム、コンテンツ、データなどを用いて多様な動作を行う。
図１７は、図６で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
より詳しくは、図１７は、本発明の実施形態によるバンドルの送信が行われた後、端末にバンドルが設置される過程とバンドル状態設定が行われる手順の他の例を示す図であるである。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１７の例のように、第１端末１７００は、第１ＬＢＡ１７２０と第１ＳＳＰ１７１０を含み、第２端末１７５０は、第２ＬＢＡ１７７０と第２ＳＳＰ１７６０を含む。
例えば、第１端末１７００は、第１ＳＳＰ１７１０が装着されて第１ＳＳＰ１７１０を制御するための第１ＬＢＡ１７２０が設置された端末であっても良く、第２端末１７５０は、第２ＳＳＰ１７６０が装着されて第２ＳＳＰ１７６０を制御するための第２ＬＢＡ１７７０が設置された端末であっても良い。
１．〔バンドル設置〕
図１７を参照すると、１７０００段階で、第２ＬＢＡ１７７０と第２ＳＳＰ１７６０は、互いに協業して第２端末１７５０にバンドルを設置する。
これに対する詳細な説明は、図９の「バンドル設置」過程を参照する。
２．〔重複使用可能であるかどうか確認〕
また、図には示さなかったが、第２ＬＢＡ１７７０及び／又は第２ＳＳＰ１７６０は、当該バンドルが複数の端末で重複使用が可能であるかどうかを選択的に判断することができ、これに対する詳細な説明は、図９の「重複使用可能であるかどうか確認」過程を参照する。
３．〔バンドル状態設定〕
もし当該バンドルが複数の端末で重複使用が可能ではないバンドルであると判断された場合、下記のようにバンドルの状態を追加的に設定する。
若しくは、第２ＬＢＡ１７７０及び／又は第２ＳＳＰ１７６０が当該バンドルを重複使用するかどうかを判断しない場合にも、第２ＬＢＡ１７７０及び／又は第２ＳＳＰ１７６０の具現によって下記のようにバンドルの状態を追加的に設定する過程が行われる。
図１７を参照すると、１７００５段階で、第２ＳＳＰ１７６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されたが使用が不可能な状態（さらに、「他の端末のリクエスト（例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」や「ｒｅｃｏｖｅｒｙＲｅｑｕｅｓｔ」を送信することによって行われるリクエスト）」及び／又は「外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）に変更されることができる状態）を意味する。
図１７を参照すると、１７０１０段階で、第２ＬＢＡ１７７０は、第２ＳＳＰ１７６０に「証明書」をリクエストする。
図１７を参照すると、１７０１５段階で、第２ＳＳＰ１７６０は、「証明書」を生成する。
図１７で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５２０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１７を参照すると、１７０２０段階で、第２ＳＳＰ１７６０は、第１ＳＳＰ１７１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ１７６０は、第１ＳＳＰ１７１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ１７６０は、第２ＬＢＡ１７７０に１７０１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡは、第１ＬＢＡ１７２０を経て第１ＳＳＰに「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図１７を参照すると、１７０２５段階で、第１ＳＳＰ１７１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、１７０２５段階で、第１ＳＳＰ１７１０は、バンドルを削除する。
また、１７０２５段階で、第１ＳＳＰ１７１０は、「証明書」を生成する。
図１７で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５３０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体データを含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５４０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５２０に第１ＳＳＰがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、符号５６０に第１ＳＳＰの署名情報を含む。
この署名は、上述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１７を参照すると、１７０３０段階で、第１ＳＳＰ１７１０は、第２ＳＳＰ１７６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ１７１０は、第１ＬＢＡ１７２０と第２ＬＢＡ１７７０を経て第２ＳＳＰ１７６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図１７を参照すると、１７０３５段階で、第２ＳＳＰ１７６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体情報が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
また、１７０３５段階で、第２ＳＳＰ１７６０は、バンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ１７６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
また、１７０３５段階で、第２ＳＳＰ１７６０は、「証明書」を生成する。
図１７で、この証明書は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」と呼ばれる。
この証明書の構造は、図５に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５１０（以下、図５参照）に当該バンドルの「バンドル区分者」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５５０に第２ＳＳＰがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５２０に第２ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、上述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、可能な証明書構成の他の例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５３０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体データを含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５４０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は符号５５０に第２ＳＳＰがバンドルの状態を使用可能な状態に変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５２０に第２ＳＳＰがバンドルの状態を変更した時間又は証明書を造った時間を選択的に含む。
若しくは、以後の電子署名に用いられる認証書の情報を選択的にさらに含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、符号５６０に第２ＳＳＰの署名情報を含む。
この署名は、上述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図１７を参照すると、１７０４０段階で、第２ＳＳＰ１７６０は、第１ＳＳＰ１７１０に「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を伝達する。
例えば、第２ＳＳＰ１７６０は、第２ＬＢＡ１７７０と第１ＬＢＡ１７２０を経て第１ＳＳＰ１７１０に「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を伝達する。
図１７を参照すると、１７０４５段階で、第１ＳＳＰ１７１０は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を検証する。
この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体情報が、自分が送信した情報と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかを検査する過程をさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれたコマンド情報がバンドルの状態を使用可能な状態に変更することであるかを確認する過程をさらに含み得る。
また、１７０４５段階で、第１ＳＳＰ１７１０は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を削除する。
１７０３５段階で、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を生成する段階及び／又は１７０４０段階及び／又は１７０４５段階は、必要によって省略され得る。
１７０２０段階及び／又は１７０３０段階及び／又は１７０４０段階で、証明書送信が失敗時の当該証明書は、相手機器に再送信され得る。
この時、再送信は、予め設定されている最大再送信回数ほど試みられる。
若しくは、当該証明書が相手の端末で送信されたことを確認するまで繰り返されて試みられる。
若しくは、端末の具現によって当該証明書が削除されるまで繰り返されて再送信することもできる。
例えば、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の場合、１７０４５段階で削除される前まで、第１端末は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の再送信を繰り返して試みる。
再送信を試行の際、２つの機器の間の接続が切れた状態であれば２つの機器は新たに接続を形成した後の当該証明書を送受信する。
この時、２つの端末は、過去通信をして送受信した記録を用い、新たに確立される接続の対象を選択及び／又は検証し、新たに接続が確立された相手とどんなデータを送受信しなければならないかを決定し、また、相手の端末から受信したデータの有効性及び／又は内容を検証する。
この時、再送信は、端末内部の動作によって自動で開始され、外部サーバーのリクエストによっても開始され、若しくは、ユーザの入力によっても開始され得る。
図１８は、本発明の一実施形態による「証明書（Ａｔｔｅｓｔａｔｉｏｎ）」の構成を示す図である。
一実施形態によれば、証明書は、「証明書情報（Ａｔｔｅｓｔａｔｉｏｎ Ｉｎｆｏ）」を選択的に含む（符号１８１０）。
証明書情報に含まれるデータの多様な実施形態は、後述する図２２～図２７の説明を参照する。
一実施形態によれば、証明書は、「証明書を発給した主体の識別子（Ｉｓｓｕｅｒ ＩＤ）」を選択的にさらに含む（符号１８３０）。
証明書を発給する主体の多様な実施形態は、後述する図２２～図２７の説明を参照する。
一実施形態によれば、証明書は、「証明書発給者が行なった動作に対する情報（Ｃｏｍｍａｎｄ）」を選択的にさらに含む（符号１８５０）。
証明書発給者が行う動作の多様な実施形態は、後述する図２２～図２７の説明を参照する。
一実施形態によれば、証明書は、上述した情報以外のその他データを選択的にさらに含む（符号１８７０）。
証明書の内に含まれることができるその他データの多様な実施形態は、後述する図２２～図２７の説明を参照する。
一実施形態によれば、証明書は、上述した情報に対する電子署名データを含む（符号１８９０）。
この署名データは、証明書発給者の署名用認証書によって生成された電子署名であっても良い。
図１９は、本発明の実施形態による一つの端末から他の端末にバンドルが送信される手順を概念的に示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図１９の例のように、第１端末１９００は、第１ＬＢＡ１９２０と第１ＳＳＰ１９１０を含み、第２端末１９５０は、第２ＬＢＡ１９７０と第２ＳＳＰ１９６０を含む。
例えば、第１端末１９００は、第１ＳＳＰ１９１０が装着されて第１ＳＳＰ１９１０を制御するための第１ＬＢＡ１９２０が設置された端末であっても良く、第２端末１９５０は、第２ＳＳＰ１９６０が装着されて第２ＳＳＰ１９６０を制御するための第２ＬＢＡ１９７０が設置された端末であっても良い。
図１９を参照すると、１９０００段階で、第１端末１９００の第１ＳＳＰ１９１０、第１ＬＢＡ１９２０と第２端末１９５０の第２ＬＢＡ１９７０は、バンドル送信のために必要な準備手順（バンドル送信準備手順）を行う。
上記手順に対するより詳しい説明は、後述する図２０の詳細説明を参照する。
図１９を参照すると、１９００５段階で、第１端末１９００から第２端末１９５０にバンドルが送信される手順（バンドル送信手順）が行われる。
上記手順に対するより詳しい説明は、後述する図２１の詳細説明を参照する。
図１９を参照すると、１９０１０段階で、第１端末１９００と第２端末１９６０は、送信されたバンドルの設置手順とバンドルの状態を設定する手順（バンドル送信仕上げ手順）を行う。
上記手順に対する詳しい説明は、後述する図２２、図２４、及び図２６の詳細説明を参照する。
図２０は、図１９で提示した手順の内のバンドル送信のために準備する手順に対する詳細手順を示す図である。
より詳しくは、図２０は、本発明の実施形態による一つの端末が他の端末にバンドルを送信するために必要な準備過程を経る手順を例示的に示す図である。
本明細書で、図２０の手順は、バンドル送信準備手順と指称される。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２０の例のように、第１端末２０００は、第１ＬＢＡ２０２０と第１ＳＳＰ２０１０を含み、第２端末２０５０は、第２ＬＢＡ２０７０と第２ＳＳＰ２０６０を含む。
例えば、第１端末２０００は、第１ＳＳＰ２０１０が装着されて第１ＳＳＰ２０１０を制御するための第１ＬＢＡ２０２０が設置された端末であっても良く、第２端末２０５０は、第２ＳＳＰ２０６０が装着されて第２ＳＳＰ２０６０を制御するための第２ＬＢＡ２０７０が設置された端末であっても良い。
一実施形態によれば、第１端末２０００は、予め設置されたバンドルを保有しても良く、このバンドルと関連したメタデータをさらに保有しても良い。
一実施形態によれば、第１端末２０００は、当該バンドルと関連してバンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、又はバンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つを保有しても良い。
一実施形態によれば、第１端末２０００は、当該バンドルと関連して「バンドル移動設定」を保有しても良い。
バンドル移動設定は、当該バンドルの機器の間の送信可能であるかどうかに関連する情報を選択的に含み得る。
また、バンドル移動設定は、当該バンドルの機器の間の送信結果をサーバーに登録する過程に対する「登録設定」を選択的にさらに含み得る。
可能な「登録設定」の多様な例示は、次の通りである。
・〔告知（Ｎｏｔｉｆｉｃａｔｉｏｎ）必要であるかどうか〕
機器の間のバンドル送信結果をサーバーに告知しなければならないかに対する設定。
・〔線告知（Ｐｒｅ－ｎｏｔｉｆｉｃａｔｉｏｎ）必要であるかどうか〕
当該バンドルが一つの機器から新しい機器に送信された後の新しい機器で用いられる前、この送信内訳がサーバーに告知されなければならないか、若しくは、この送信内訳がサーバーに告知される前の新しい機器で用いられることができるかに対する設定。
・〔告知内容の暗号が化必要であるかどうか〕
告知をする過程で送信されるデータが告知を受けるサーバーと告知するＳＳＰだけが内容を見られるように暗号化される必要があるかに対する設定。
「登録設定」は、サービス提供者によって設定することもでき、バンドル管理サーバーによって設定することもでき、若しくは、サービス提供者とバンドル管理サーバーの協業によって設定することもできる。
また、このバンドル移動設定は、バンドル内部のデータで含まれることもでき、バンドルのメタデータの内に含まれていることもでき、若しくは、独立されたデータで存在することもできる。
また、バンドル移動設定は、サービス提供者及び／又はバンドル管理サーバーの電子署名を含み得る。
図２０を参照すると、２００００段階で、機器の間の送信されるバンドルの情報を第１ＬＢＡ２０２０に伝達する。
この伝達過程は、例えば、図２０に示したように、第１端末２０００が提供するＵＩを介してユーザが直接バンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第１ＬＢＡ２０２０に入力することもでき、又は第１ＬＢＡ２０２０がリモートサーバーに接続して当該情報を読み取ることもできる。
図２０を参照すると、２０００５段階で、２００００段階を介して選択されたバンドルに関連する情報が第１ＬＢＡ２０２０から第１ＳＳＰ２０１０に伝達される。
例えば、図２０に示したように、選択されたバンドルに関連する情報が「Ｓｅｌｅｃｔ ＳＰＢ ｃｏｍｍａｎｄ」を介して第１ＬＢＡ２０２０から第１ＳＳＰ２０１０に伝達される。
この時、第１ＬＢＡ２０２０から第１ＳＳＰ２０１０に伝達する情報は、２００００段階で選択されたバンドルを識別（ｉｄｅｎｔｉｆｙ）するための情報を含む。
図２０を参照すると、２００１０段階で、第１ＳＳＰ２０１０は、送信をリクエストされたバンドルの機器の間で送信可能であるかどうかを確認する。
この過程は、先ず２０００５段階で受信した情報に基づいて送信をリクエストされたバンドルを識別し、当該バンドルと関連した（ａｓｓｏｃｉａｔｅｄ ｗｉｔｈ）「バンドル移動設定」を確認することによって行われる。
また、２００１０段階で、第１ＳＳＰ２０１０は、選択的に「バンドル移動コード」を設定する。
「バンドル移動コード」は、当該バンドルの機器の間の送信過程で当該バンドルを指称するために用いられるコードとして、当該バンドルを識別することができる値ではなければならない。
第１ＳＳＰ２０１０は、上述した「バンドル移動コード」と送信しようとするバンドルの情報をバインディング（ｂｉｎｄｉｎｇ）する。
図２０を参照すると、２００１５段階で、２０００５段階に対する応答結果が第１ＳＳＰ２０１０から第１ＬＢＡ２０２０に送信される。
例えば、図２０に示したように、「Ｓｅｌｅｃｔ ＳＰＢ ｃｏｍｍａｎｄ」に対する応答を「Ｓｅｌｅｃｔ ＳＰＢ ｒｅｓｐｏｎｓｅ」を介して第１ＳＰＢ２０１０から第１ＬＢＡ２０２０に伝達する。
この応答値は、２００１０段階で記載した「バンドル移動コード」を含み得る。
図２０を参照すると、２００２０段階から機器の間のバンドル送信のために必要な情報が第１端末２０００の第１ＬＢＡ２０２０から第２端末２０５０の第２ＬＢＡ２０７０に伝達される。
この時、第１ＬＢＡ２０２０から第２ＬＢＡ２０７０に伝達する情報には「バンドル移動コード」が含まれ得る。
また、第１ＬＢＡ２０２０から第２ＬＢＡ２０７０に伝達される情報は、今後の２００２５段階で第１ＬＢＡ７２０と第２ＬＢＡ２０７０の間に確立される（ｅｓｔａｂｌｉｓｈｅｄ）接続のために必要な情報を選択的にさらに含み得る。
上述した２００２０段階を介して第１ＬＢＡ２０２０から第２ＬＢＡ２０７０に伝達される情報は、多様な方法で伝達することができる。
例えば、第１ＬＢＡは、第２ＬＢＡに伝達しなければならない情報を第１端末２０００のＵＩを介してユーザに提供し、ユーザは提供された情報を第２端末２０５０のＵＩを用いて第２ＬＢＡに入力する。
若しくは、第１ＬＢＡは、第２ＬＢＡで伝達しなければならない情報をイメージ（例えば、ＱＲコード（登録商標））の形態で作成して第１端末の画面に表示し、ユーザは第２端末２０５０を用いてこのイメージをスキャンすることによって第２ＬＢＡ２０７０に情報を伝達する。
しかし、第１ＬＢＡ２０２０から第２ＬＢＡ２０７０に情報を伝達する方法は、上記の方法に限らない。
図２０を参照すると、２００２５段階で、第１ＬＢＡ２０２０と第２ＬＢＡ２０７０の間に接続が確立（又は、設定）される。
もし、２００２０段階で接続のために必要な情報が送信されると、第１ＬＢＡ２０２０と第２ＬＢＡ２０７０は、この情報を用いて接続を確立することもできる。
第１ＬＢＡ２０２０と第２ＬＢＡ２０７０の接続は、直接的な機器の間の接続であっても良く（例えば、ＮＦＣ、ブルートゥース（登録商標）、ＵＷＢ、ＷｉＦｉ－Ｄｉｒｅｃｔ、「ＬＴＥ Ｄ２Ｄ」（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）、「５Ｇ Ｄ２Ｄ」）又は第１ＬＢＡ２０２０と第２ＬＢＡ２０７０の間にリモートサーバー（例えば、リレーサーバー）が位置した遠距離接続であっても良い。
図２０を参照すると、２００２５段階は、最後の段階として図に示したがこの段階は前述の他の段階、すなわち、２００００段階、２０００５段階、２００１０段階、２００１５段階、２００２０段階とは独立的な段階として他の段階と手順に関わらず行うことができる。
例えば、２００２５段階は、２００１５段階と２００２０段階の間で行うこともでき、この場合、２００２０段階で第１ＬＢＡ２０２０から第２ＬＢＡ２２０７０に送信される情報は、２００２５段階で確立された接続を介して送信される。
図２１は、図１９で提示した手順の内のバンドルの送信が行う手順に対する詳細手順を示す図である。
より詳しくは、図２１は、本発明の実施形態による一つの端末が他の端末でバンドルを送信する手順を例示的に示す図である。
本発明で図２１の手順は、バンドル送信手順と指称される。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２１の例のように、第１端末２１００は、第１ＬＢＡ２１２０と第１ＳＳＰ２１１０を含み、第２端末２１５０は、第２ＬＢＡ２１７０と第２ＳＳＰ２１６０を含む。
例えば、第１端末２１００は、第１ＳＳＰ２１１０が装着されて第１ＳＳＰ２１１０を制御するための第１ＬＢＡ２１２０が設置された端末であっても良く、第２端末２１５０は、第２ＳＳＰ２１６０が装着されて第２ＳＳＰ２１６０を制御するための第２ＬＢＡ２１７０が設置された端末であっても良い。
図２１を参照すると、２１０００段階で、第２ＬＢＡ２１７０は、第２ＳＳＰ２２１６０に「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」をリクエストする。
２１０００段階で、第２ＬＢＡ２１７０が第２ＳＳＰ２１６０に「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」をリクエストする時、第２ＬＢＡ２１７０は、第２ＳＳＰ２１６０に機器の間のバンドル移動が行われることを知らせる。
また、２１０００段階は、図２１で図に示した過程に続いて直ちに自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第２端末２１５０が提供するＵＩを介してユーザが直接送信を受けるバンドルを選択する過程を介して行うこともでき、リモートサーバーからプッシュ入力を介して第２ＬＢＡ２１７０に入力することもでき、又は第２ＬＢＡ２１７０がリモートサーバーに接続して当該情報を読み取ることもできる。
図２１を参照すると、２１００５段階で、第２ＳＳＰ２１６０は、自分の「ＳＳＰ情報」を生成する。
「ＳＳＰ情報」にはバンドル送信のために提供されなければならない第２ＳＳＰの情報が含まれる。
この時、「ＳＳＰ情報」には第２ＳＳＰ２１６０がバンドルを受信する前に経なければならない認証書交渉過程のための情報（認証書交渉情報）が含まれる。
この「認証書交渉情報」は、第２ＳＳＰ２１６０が異なるＳＳＰを検証するのに用いられる認証書情報（ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）と異なるＳＳＰが自分を検証するのに用いられる認証書情報（ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）を含む。
また、「認証書交渉情報」は、第２ＳＳＰ２１６０がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第２ＳＳＰ２１６０がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また、「ＳＳＰ情報」には第２ＳＳＰ２１６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むＳＳＰバージョン情報が選択的にさらに含まれ得る。
図２１を参照すると、２１０１０段階で、第２ＳＳＰ２１６０は、第２ＬＢＡ２１７０と第１ＬＢＡ２１２０を経て第１ＳＳＰ２１１０に２１００５段階で生成した「ＳＳＰ情報」を伝達する。
以上、記載した２１０００段階と２１０１０段階によると、第２ＬＢＡ２１７０が第２ＳＳＰ２１６０に「ＳＳＰ情報（ＳｓｐＩｎｆｏ）」をリクエストし、第２ＳＳＰ２１６０が自分の「ＳＳＰ情報」を生成した後、第２ＳＳＰ２１６０が第２ＬＢＡ２１７０と第１ＬＢＡ２１２０を経て第１ＳＳＰ２１１０に「ＳＳＰ情報」を伝達する。
しかし、実施形態によっては、第２端末２１５０が第１端末２１００に「ＳＳＰ情報」の伝達する過程は、次の通りである。
例えば、第２ＬＢＡ２１７０が自ら「ＳＳＰ情報」を生成した後に、第１ＬＢＡ２１２０を経て第１ＳＳＰ２１１０に「ＳＳＰ情報」を伝達する。
図２１を参照すると、２１０１５段階で、第１ＳＳＰ２１１０は、受信した「ＳＳＰ情報」を確認し、この情報に基づいて自分を認証することができる「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ」を生成する。
この過程に対するより具体的な手順は、次の通りである。
第１ＳＳＰ２１１０は、受信した「ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書（ｓｓｐ１．Ｃｅｒｔ．ＫＡ）を選択する。
若しくは、第１ＳＳＰ２１１０は、受信した「第２ＳＳＰ２１６０がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｓｐ１．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ１．ｅＰＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｓｐ１．ｅＰＫ．ＫＡ）を選択する。
また、第１ＳＳＰ２１１０は、受信した「ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の署名用認証書（ｓｓｐ１．Ｃｅｒｔ．ＤＳ）をさらに選択する。
また、第１ＳＳＰ２１１０は、受信した「ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて検証を行う第２ＳＳＰ２１６０の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」で設定する。
また、第１ＳＳＰ２１１０は、受信した「第２ＳＳＰ２１６０がサポートする暗号化アルゴリズムのリスト」を用いて今後に用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」で設定する。
また、第１ＳＳＰ２１１０は、受信した「第２ＳＳＰ２１６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認して、そのうちに自身もサポートする標準規格のバージョンが存在するかを確認する。
「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」は、前述した「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」、「ｓｓｐ１．ｅＰＫ．ＫＡ」「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」、「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」の内の少なくとも一つを含む。
また、「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」は、前述した「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を選択的にさらに含み得る。
また、「第１端末認証情報（Ｄｅｖｉｃｅ１．Ａｕｔｈ」は、今後に送信されるバンドルに関連したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つを選択的にさらに含み得る。
この時、上記で言及した「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ」の一部又は全体は、情報の無欠性を保障するために「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは「第１端末認証情報」の一部として追加される。
図２１を参照すると、２１０２０段階で、第１ＳＳＰ２１１０は、第１ＬＢＡ２１２０を経て第２ＬＢＡ２１７０に２１０１５段階で生成した「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を伝達する。
図２１を参照すると、２１０２５段階で、第２ＬＢＡ２１７０は、第２ＳＳＰ２１６０に「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を伝達する。
また、第２ＬＢＡ２１７０は、第２ＳＳＰ２１６０に「バンドル移動コード」をさらに伝達する。
図２１を参照すると、２１０３０段階で、第２ＳＳＰ２１６０は、受信した「第１端末認証情報（Ｄｅｖｉｃｅ １．Ａｕｔｈ）」を検証する。
若し、第２ＳＳＰ２１６０が「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第２ＳＳＰ２１６０に「ｓｓｐ１．ｅＰＫ．ＫＡ」とこれに対するデジタル署名が送信された場合には、先ず、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」の有効性を検査した後、この認証書を用いてデジタル署名を確認して受信した公開鍵「ｓｓｐ１．ｅＰＫ．ＫＡ」の無欠性を確認する。
また、第２ＳＳＰ２１６０は、受信した「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」を確認して自分を検証することができる少なくとも一つ以上の署名用認証書（ｓｓｐ２．Ｃｅｒｔ．ＤＳ）を選択する。
また、図には示していないが、２１０３０段階で、第２ＳＳＰ２１６０は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）で公開鍵「ｓｓｐ２．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ２．ｅＳＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｓｐ２．ｅＰＫ．ＫＡ）を選択する。
また、第２ＳＳＰ２１６０は、「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵や「ｓｓｐ１．ｅＰＫ．ＫＡ」の内の一つを選択した後、この値と「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いて今後に端末１との通信の内の暗号化に用いられるセッション鍵「ＳｈＫｅｙ０１」を生成する。
「ＳｈＫｅｙ０１」は、受信した「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
また、２１０３０段階で、第２ＳＳＰ２１６０は、自分を認証することができる「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」を生成する。
この時、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を含む。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、「ｓｓｐ２．ｅＰＫ．ＫＡ」をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、ＳＳＰ２２１６０によって生成された現在セッションを指称するトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、「バンドル移動コード」をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、第２ＳＳＰ２１６０のＳＳＰ識別子をさらに含み得る。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」は、今後に送信されるバンドルに関連したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つを選択的にさらに含み得る。
この時、上記で言及した「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「第２端末認証情報」の一部として追加される。
また、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」の一部又は全体は、先立って生成されたセッション鍵「ＳｈＫｅｙ０１」を用いて暗号化される。
図２１を参照すると、２１０３５段階で、第２ＳＳＰ２１６０は、第２ＬＢＡ２１７０と第１ＬＢＡ２１２０を経て第１ＳＳＰ２１１０に２１０３０段階で生成した「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」を伝達する。
この時、「バンドル移動コード」が選択的にさらに送信される。
図２１を参照すると、２１０４０段階で、第１ＳＳＰ２１１０は、受信した「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」を検証する。
第１ＳＳＰ２１１０は、受信した「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」の署名を検証して当該認証書の有効性を検証する。
また、第１ＳＳＰ２１１０は、受信したバンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）及び／又はバンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）が、自分が送信しようとするバンドルと関連して正しく設定された値であるかを検査する。
また、第１ＳＳＰ２１１０は、受信したトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）及び／又は第２ＳＳＰ２１６０のＳＳＰ識別子を記憶する。
また、第１ＳＳＰ２１１０は、受信したトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）や第２ＳＳＰ２１６０のＳＳＰ識別子を、現在進行しているセッション又は送信しようとするバンドルとバインディング（ｂｉｎｄｉｎｇ）させる。
この過程で、若し、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」に暗号化されたデータが含まれている場合、第１ＳＳＰ２１１０は、送信された「ｓｓｐ２．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵に対応される秘密鍵や「ｓｓｐ１．ｅＰＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０１」を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後に、検証過程を行う。
またこの過程で、若し、「第２端末認証情報（Ｄｅｖｉｃｅ ２．Ａｕｔｈ）」にデジタル署名が含まれている場合、第１ＳＳＰ２１１０は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を用いて受信したデジタル署名の有効性を検証する。
また、２１０４０段階で、図２１には示していないが、第１ＳＳＰ２１１０は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」を生成する。
この時、鍵の対「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」は、先立って生成された「ｓｓｐ１．ｅＰＫ．ＫＡ」と「ｓｓｐ１．ｅＰＫ．ＫＡ」と同一値で設定され得る。
又は、鍵の対「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」は、先立って用いられた「ｓｓｐ１．Ｃｅｒｔ．ＫＡ」に含まれている公開鍵とここに対応する秘密鍵」同一値で設定することもできる。
また、第１ＳＳＰ２１１０は、「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」と「ｓｓｐ２．ｅＰＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０２」を生成する。
もし、「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＳＫ．ＫＡ」のために「ｓｓｐ１．ｅＰＫ．ＫＡ」又は「ｓｓｐ１．Ｃｅｒｔ．Ｋａ」に含まれている公開鍵に対応する秘密鍵が再使用されると、セッション鍵「ＳｈＫｅｙ０２」の値も以前に生成された「ＳｈＫｅｙ０１」の値に設定され得る。
また、２１０４０段階で、第１ＳＳＰ２１１０は、第２端末２１５０で送信するバンドル及び／又はバンドルと関連したメタデータを構成する。
この時、第１ＳＳＰ２１１０は、受信した「バンドル移動コード」を用いて自分が送信しようとするバンドルを識別する。
また、構成されるバンドルには「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」が含まれる。
また、構成されるバンドルには「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」がさらに含まれる。
また、構成されるバンドルは、当該セッションを識別するトランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）をさらに含み得る。
また、構成されるバンドルには送信されるバンドルと関連したバンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが選択的にさらに含まれ得る。
一実施形態によれば、２１０４０段階で、構成されるバンドル（又は、バンドルと関連したメタデータ）のうちには「バンドル移動設定」が含まれる。
一実施形態によれば、２１０４０段階で、構成されるバンドルには「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を用いて生成されたデジタル署名データが追加される。
すなわち、上記で明示したバンドルの構成要素一部又は全体に対して、生成されたデジタル署名データがバンドルの一部として追加される。
また、構成されるバンドルの一部又は全体は、「ＳｈＫｅｙ０２」を用いて暗号化される。
図２１を参照すると、２１０４５段階で、第１ＳＳＰ２１１０は、第１ＬＢＡ２１２０を経て第２ＬＢＡ２１７０に２１０４０段階で生成した（構成された）バンドルを伝達する。
この時、送信されるバンドルと関連したメタデータが選択的にさらに送信される。
また、送信されるバンドルと関連した「バンドル移動設定」がさらに送信される。
例えば、「バンドル移動設定」がバンドル又はメタデータに含まれず、別途のフォーマット（例えば、メッセージ）で送信され得る。
図２２は、図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対する詳細手順を示す図である。
図２２は、バンドルの機器の間の送信内訳が
・先告知（Ｐｒｅ－ｎｏｔｉｆｉｃａｔｉｏｎ）される必要がなく、
・告知内容の暗号化が必要又は必要ではない、
場合、適用される手順であっても良い。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２２の例のように、第１端末２２００は、第１ＬＢＡ２２２０と第１ＳＳＰ２２１０を含み、第２端末２２５０は、第２ＬＢＡ２２７０と第２ＳＳＰ２２６０を含む。
例えば、第１端末２２００は、第１ＳＳＰ２２１０が装着されて第１ＳＳＰ２２１０を制御するための第１ＬＢＡ２２２０が設置された端末であっても良く、第２端末２２５０は、第２ＳＳＰ２２６０が装着されて第２ＳＳＰ２２６０を制御するための第２ＬＢＡ２２７０が設置された端末であっても良い。
図２２を参照すると、２２０００段階で次の手順が行われる。
１．〔バンドル設置〕
図２２を参照すると、２２０００段階で、第２ＬＢＡ２２７０と第２ＳＳＰ２２６０は、互いに協業して第２端末２２５０にバンドルを設置する。
この過程で、次の手順が共に行われる。
もし、メタデータが送信された場合、第２ＬＢＡ２２７０又は第２ＳＳＰ２２６０は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第２ＬＢＡ２２７０は、上記情報を第２ＳＳＰ２２６０で伝達する。
もし、トランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）が送信されると、第２ＬＢＡ２２７０又は第２ＳＳＰ２２６０は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが送信されると、第２ＬＢＡ２２７０又は第２ＳＳＰ２２６０は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」が送信されると、第２ＳＳＰ２２６０は、この認証書の有効性を検証して第１ＳＳＰ２２１０を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第２ＳＳＰ２２６０は、送信された「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０２」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後に検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第２ＳＳＰ２２６０は、「ｓｓｐ１．Ｃｅｒ．ＤＳ」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
２．〔「登録設定」確認〕
また、図には示してなかったが、第２ＬＢＡ２２７０及び／又は第２ＳＳＰ２２６０は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び／又は「先告知必要であるかどうか」及び／又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、２２０００段階の一部として２２０００段階で行われる他の手順と手順に関わらず独立的に行われ得る。
若しくは、２２０００段階以後、２２０３５段階が仕上げられる前、判断が必要な瞬間に行うこともできる。
本図で後述する手順は、「登録設定」を確認した結果、バンドルの機器の間の送信内訳が先告知される必要がない時に適用される手順であり得る。
図２２を参照すると、２２００５段階で、第２ＳＳＰ２２６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」で設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されたがまだ使用が不可能な状態（さらに、「本図で後述する追加動作」及び／又は「（本発明では説明されなかったが）外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）で変更することができる状態）を意味する。
図２２を参照すると、２２０１０段階で、第２ＬＢＡ２２７０は、第２ＳＳＰ２２６０に「証明書」をリクエストする。
図２２を参照すると、２２０１５段階で、第２ＳＳＰ２２６０は、「証明書」を生成する。
図２２で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の１符号８５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の１８７０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を作成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２２を参照すると、２２０２０段階で、第２ＳＳＰ２２６０は、第１ＳＳＰ２２１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ２２６０は、第１ＳＳＰ２２１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ２２６０は、第２ＬＢＡ２２７０に２２０１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡ２２７０は、第１ＬＢＡ２２２０を経て第１ＳＳＰ２２１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図２２を参照すると、２２０２５段階で、第１ＳＳＰ２２１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、２２０２５段階で、第１ＳＳＰ２２１０は、検証を済んだ後のバンドルを削除する。
また、２２０２５段階で、第１ＳＳＰ２２１０は、「証明書」を生成する。
図２２で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体データを含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８３０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８７０に第１ＳＳＰがバンドルを削除した時間又は証明書を造った時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８９０に第１ＳＳＰの署名情報を含む。
この署名は、上述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２２を参照すると、２２０３０段階で、第１ＳＳＰ２２１０は、第２ＳＳＰ２２６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ２２１０は、第１ＬＢＡ２２２０と第２ＬＢＡ２２７０を経て第２ＳＳＰ２２６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図２２を参照すると、２２０３５段階で、第２ＳＳＰ２２６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」のデータ一部又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
また、２２０３５段階で、第２ＳＳＰ２２６０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ２２６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
また、２２０３５段階で、第２ＳＳＰ２２６０は、「証明書」を生成する。
図２２で、この証明書は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体データを含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８５０に第２ＳＳＰがバンドルを使用可能な状態の内の一つに変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８７０に第２ＳＳＰがバンドルの状態を使用可能な状態の内の一つに変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
また、２２０３５段階で、第２ＳＳＰ２２６０は、自分の「選択されたＳＳＰ情報（ｓｓｐＩｎｆｏｒＳｅｌｅｃｔｅｄ」を生成する。
「選択されたＳＳＰ情報」には機器の間のバンドル送信結果をサーバーに告知するために提供されなければならない第２ＳＳＰの情報が含まれる。
この時、「選択されたＳＳＰ情報」には認証書交渉過程のための情報（認証書交渉情報）が含まれる。
この「認証書交渉情報」は、
・第２ＳＳＰ２２６０がサーバーを検証に用いることができる認証書情報（ｓｐｂｍＶｅｒｉｆｉｃａｔｉｏｎ）、
・サーバーが第１ＳＳＰ２２１０を検証に用いることができる認証書情報（ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）、
・サーバーが第２ＳＳＰ２２６０を検証に用いることができる認証書情報（ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）、
などの情報を選択的に含み得る。
また、「認証書交渉情報」は、第２ＳＳＰ２２６０がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第２ＳＳＰ２２６０がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また「選択されたＳＳＰ情報」には第２ＳＳＰ２２６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むＳＳＰバージョン情報が選択的にさらに含まれ得る。
図２２を参照すると、２２０４０段階で、第２ＳＳＰ２２６０は、２２０３５段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第２ＬＢＡ２２７０に送信する。
また、２２０３５段階で生成された「選択されたＳＳＰ情報」が共に送信され得る。
２２０３５段階で、「選択されたＳＳＰ情報」を生成する過程と２２０４０段階で「選択されたＳＳＰ情報」を伝達する過程は、省略され得る。
図２３は、図２２で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２３の例のように、第２端末２３５０は、第２ＬＢＡ２３７０と第２ＳＳＰ２３６０を含む。
例えば、第２端末２３５０は、第２ＳＳＰ２３６０が装着されて第２ＳＳＰ２３６０を制御するための第２ＬＢＡ２３７０が設置された端末であっても良い。
また、一実施形態によれば、サーバー２３００は、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び／又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明では、サーバー２３００を指称するためにサーバーの可能な例の内の一つであるＳＰＢＭという用語を用いる場合もあるが、前述したようにサーバーの種類は、ＳＰＢＭに限らない。
図２３を参照すると、２３０００段階で、ＳＰＢＭ２３００とＬＢＡ２３７０の間にＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）接続が形成（ｅｓｔａｂｌｉｓｈｅｄ）される。
本図では、２３０００段階が２３００５段階～２３０１５段階以前に行われることとして記載しているが、２３０００段階は、２３０２０段階が行われる前の２３００５段階～２３０１５段階とは独立的に行うことができる。
例えば、２３０００段階は、２３０１５段階と２３０２０段階の間に行うこともできる。
図２３を参照すると、２３００５段階で、第２ＬＢＡ２３７０は、第２ＳＳＰ２２３６０に「選択されたＳＳＰ情報（ＳｓｐＩｎｆｏＳｅｌｅｃｔｅｄ）」をリクエストする。
この時、２３００５段階は、自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第２端末２３５０が提供するＵＩを介してユーザから与えられることもでき、リモートサーバーからプッシュ入力を介して第２端末２３５０に与えられることもできる。
図２３を参照すると、２３０１０段階で、第２ＳＳＰ２３６０は、自分の「選択されたＳＳＰ情報」を生成する。
「選択されたＳＳＰ情報」に対する説明は、図２２に記載した説明を参照する。
図２３を参照すると、２３０１５段階で、第２ＳＳＰ２３６０は、第２ＬＢＡ２３７０に２３０１０段階で生成した「選択されたＳＳＰ情報」を送信する。
２３００５段階～２３０１５段階は、選択的に行われないこともある。
図２３を参照すると、２３０２０段階で、第２ＬＢＡ２３７０は、サーバー２３００に「選択されたＳＳＰ情報」を送信する。
もし、第２ＬＢＡ２３７０が、図２２の２２０３５段階～２２０４０段階を介して「選択されたＳＳＰ情報」を受信したか、若しくは図２３の２３００５段階～２３０１５段階を介して「選択されたＳＳＰ情報」を受信する場合、第２ＬＢＡ２３７０は、サーバー２３００に受信した「選択されたＳＳＰ情報」を送信する。
若し、第２ＬＢＡ２３７０が「選択されたＳＳＰ情報」を受信しない場合、第２ＬＢＡ２３７０は、「選択されたＳＳＰ情報」を生成してサーバー２３００に送信する。
図２３を参照すると、２３０２５段階で、サーバー２３００は、受信した「選択されたＳＳＰ情報」を確認してこの情報に基づいて自分を認証することができる「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」を生成する。
この過程に対するより具体的な手順は、次の通りである。
サーバー２３００は、受信した「ｓｐｂｍＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書（ｓｐｂｍ．Ｃｅｒｔ．ＫＡ）を選択する。
若しくは、サーバー２３００は、受信した「第２ＳＳＰ２３６０がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｐｂｍ．ｅＰＫ．ＫＡ」と秘密鍵「ｓｐｂｍ．ｅＳＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｐｂｍ．ｅＰＫ．ＫＡ）を選択する。
また、サーバー２３００は、受信した「ｓｐｂｍＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して、少なくとも一つ以上の署名用認証書（ｓｐｂｍ．Ｃｅｒｔ．ＤＳ）をさらに選択する。
また、サーバー２３００は、受信した「ｓｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて検証を行う第１ＳＳＰ２２１０の認証書情報が、自分が検証可能なことであるかどうかを確認する。
この過程は、選択的に行われないこともある。
また、サーバー２３００は、受信した「ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて検証を行う第２ＳＳＰ２３６０の認証書情報が、自分が検証可能なことであるかどうかを確認する。
若しくは、「ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分が検証することができる第２ＳＳＰ２３６０の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」に設定する。
また、サーバー２３００は、受信した「第２ＳＳＰ２３６０がサポートする暗号化アルゴリズムのリスト」を用いて今後の用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」に設定する。
また、サーバー２３００は、受信した「第２ＳＳＰ２３６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認して、その内に自身もサポートする標準規格のバージョンが存在するかを確認する。
「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」は、前述した「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」、「ｓｐｂｍ．ｅＰＫ．ＫＡ」、「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」、「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」の内の少なくとも一つを含む。
また、「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ」は、前述した「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を選択的にさらに含み得る。
この時、上記で言及した「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「サーバー認証情報」の一部として追加される。
図２３を参照すると、２３０３０段階で、サーバー２３００は、第２ＬＢＡ２３７０を経て第２ＳＳＰ２３６０に２３０２５段階で生成した「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」を伝達する。
図２３を参照すると、２３０３５段階で、第２ＳＳＰ２３６０は、受信した「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」を検証する。
若し、第２ＳＳＰ２３６０が「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第２ＳＳＰ２３６０が「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第２ＳＳＰ２３６０が「ｓｐｂｍ．ｅＰＫ．ＫＡ」とこれに対するデジタル署名が送信された場合には、「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を用いてデジタル署名を確認して受信した公開鍵「ｓｐｂｍ．ｅＰＫ．ＫＡ」の無欠性を確認する。
また、第２ＳＳＰ２３６０は、「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」を受信した場合、これを確認して自分を検証することができる少なくとも一つ以上の署名用認証書（ｓｓｐ２．Ｃｅｒｔ．ＤＳ）を選択する。
また、図には示していないが、２３０３５段階で、第２ＳＳＰ２３６０は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）で公開鍵「ｓｓｐ２．ｅＰＫ．ＫＡ」と秘密鍵 「ｓｓｐ２．ｅＳＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｓｐ２．ｅＰＫ．ＫＡ）を選択する。
また、第２ＳＳＰ２３６０は、「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵や「ｓｐｂｍ．ｅＰＫ．ＫＡ」の内の一つを選択した後、この値と「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いて今後のサーバーとの通信の内の暗号化に用いられるセッション鍵「ＳｈＫｅｙ０３」を生成する。
「ＳｈＫｅｙ０３」は、受信した「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
また、２３０３５段階で、第２ＳＳＰ２３６０は、自分を認証することができる「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」を生成する。
この時、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を含む。
また「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を選択的にさらに含み得る。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ）及び／又は「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」と連関された認証書チェーン情報をさらに含み得る。
また「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」の一部及び／又は全体を含み得る。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体を含み得る。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体を含み得る。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ２．ｅＰＫ．ＫＡ」をさらに含み得る。
この時、上記で言及した「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「端末認証情報」の一部として追加される。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」の一部又は全体は、先立って生成されたセッション鍵「ＳｈＫｅｙ０３」を用いて暗号化される。
図２３を参照すると、２３０４０段階で、第２ＳＳＰ２３６０は、第２ＬＢＡ２３７０を経てサーバー２３００に２３０３５段階で生成した「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」を伝達する。
図２３を参照すると、２３０４５段階で、サーバー２３００は、受信した「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」を検証する。
検証過程の具体的手順は、次の通りである。
サーバー２３００は、受信した「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」及び／又は「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」の署名を検証して当該認証書の有効性を検証する。
また、サーバー２３００は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の署名を検証する。
また、サーバー２３００は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の内容を検証する。
また、サーバー２３００は、検証した内容に基づいて機器の間の送信されたバンドルの内訳をアップデートする。
例えば、サーバー２３００は、当該バンドルと第１ＳＳＰ２２１０の間に存在したマッピング（ｍａｐｐｉｎｇ）関係を当該バンドルと第２ＳＳＰ２３６０のマッピング（ｍａｐｐｉｎｇ）関係にアップデートする。
この過程で、若し、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」に暗号化されたデータが含まれている場合、サーバー２３００は、送信された「ｓｓｐ２．ｅＰＫ．ＫＡ」と自分の「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵に対応する秘密鍵や「ｓｐｂｍ．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０３」を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後に検証過程を行う。
図２３を参照すると、２３０５０段階で、サーバー２３００は、２３０４５段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第２ＬＢＡ２３７０に送信する。
図２４は、図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図２４は、バンドルの機器の間の送信内訳が、
・先告知（Ｐｒｅ－ｎｏｔｉｆｉｃａｔｉｏｎ）される必要がなく、
・告知内容の暗号化が必要ではない場合、適用される手順であっても良い。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２４の例のように、第１端末２４００は、第１ＬＢＡ２４２０と第１ＳＳＰ２４１０を含み、第２端末２４５０は、第２ＬＢＡ２４７０と第２ＳＳＰ２４６０を含む。
例えば、第１端末２４００は、第１ＳＳＰ２４１０が装着されて第１ＳＳＰ２４１０を制御するための第１ＬＢＡ２４２０が設置された端末であっても良く、第２端末２４５０は、第２ＳＳＰ２４６０が装着されて第２ＳＳＰ２４６０を制御するための第２ＬＢＡ２４７０が設置された端末であっても良い。
図２４を参照すると、２４０００段階で次の手順が行われる。
１．〔バンドル設置〕
図２４を参照すると、２４０００段階で、第２ＬＢＡ２４７０と第２ＳＳＰ２４６０は、互いに協業して第２端末２４５０にバンドルを設置する。
この過程で、次の手順が共に行われる。
もし、メタデータが送信された場合、第２ＬＢＡ２４７０又は第２ＳＳＰ２４６０は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第２ＬＢＡ２４７０は、この情報を第２ＳＳＰ２４６０で伝達する。
もし、トランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）が送信されると、第２ＬＢＡ２４７０又は第２ＳＳＰ２４６０は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが送信されると、第２ＬＢＡ２４７０又は第２ＳＳＰ２４６０は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」が送信されると、第２ＳＳＰ２４６０は、この認証書の有効性を検証して第１ＳＳＰ２４１０を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第２ＳＳＰ２４６０は、送信された「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０２」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後に検証を行う。
もし、受信したデータにデジタル署名が含まれていたら、第２ＳＳＰ２４６０は、「ｓｓｐ１．Ｃｅｒ．ＤＳ」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
２．〔「登録設定」確認〕
また、図には示さなかったが、第２ＬＢＡ２４７０及び／又は第２ＳＳＰ２４６０は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び／又は「先告知必要であるかどうか」及び／又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、２４０００段階の一部として２４０００段階で行われる他の手順と手順に関わらず独立的に行われ得る。
若しくは、２４０００段階以後２４０３５段階が仕上げられる前、判断が必要な瞬間に行うこともできる。
本図で後述する手順は、「登録設定」を確認した結果、バンドルの機器の間送信内訳が先告知される必要がなく告知内容が暗号化される必要がない時に適用される手順であり得る。
図２４を参照すると、２４００５段階で、第２ＳＳＰ２４６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されたがまだ使用が不可能な状態（さらに、「本図で後述する追加動作」及び／又は「（本発明では説明されなかったが）外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）に変更することができる状態）を意味する。
図２４を参照すると、２４０１０段階で、第２ＬＢＡ２４７０は、第２ＳＳＰ２４６０に「証明書」をリクエストする。
図２４を参照すると、２４０１５段階で、第２ＳＳＰ２４６０は、「証明書」を生成する。
図２４で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８７０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２を参照すると、２４０２０段階で、第２ＳＳＰ２４６０は、第１ＳＳＰ２４１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ２４６０は、第１ＳＳＰ２４１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ２４６０は、第２ＬＢＡ２４７０に２４０１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡ２４７０は、第１ＬＢＡ２４２０を経て第１ＳＳＰ２４１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図２４を参照すると、２４０２５段階で、第１ＳＳＰ２４１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、２４０２５段階で、第１ＳＳＰ２４１０は、検証を済んだ後のバンドルを削除する。
また、２４０２５段階で、第１ＳＳＰ２４１０は「、証明書」を生成する。
図２４で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体データを含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８３０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８７０に第１ＳＳＰがバンドルを削除した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８９０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２４を参照すると、２４０３０段階で、第１ＳＳＰ２４１０は、第２ＳＳＰ２４６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ２４１０は、第１ＬＢＡ２４２０と第２ＬＢＡ２４７０を経て第２ＳＳＰ２４６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図２４を参照すると、２４０３５段階で、第２ＳＳＰ２４６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」のデータ一部又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
また、２４０３５段階で、第２ＳＳＰ２４６０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ２４６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
また、２４０３５段階で、第２ＳＳＰ２４６０は、「証明書」を生成する。
図２４で、この証明書は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体データを含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８５０に第２ＳＳＰがバンドルを使用可能な状態の一つに変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８７０に第２ＳＳＰがバンドルの状態を使用可能な状態の一つに変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２４を参照すると、２４０４０段階で、第２ＳＳＰ２４６０は、２４０３５段階で生成した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を送信する。
図２５は、図２４で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２５の例のように、第２端末２５５０は、第２ＬＢＡ２５７０と第２ＳＳＰ２５６０を含む。
例えば、第２端末２５５０は、第２ＳＳＰ２５６０が装着されて第２ＳＳＰ２５６０を制御するための第２ＬＢＡ２５７０が設置された端末であっても良い。
また、一実施形態によれば、サーバー２５００は、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び／又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明ではサーバー２５００を指称するためにサーバーの可能な例の内のいずれか一つであるＳＰＢＭという用語を用いる場合もあるが、前述したようにサーバーの種類はＳＰＢＭに限らない。
図２５を参照すると、２５０００段階で、ＳＰＢＭ２５００とＬＢＡ２５７０間にＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）接続が形成（ｅｓｔａｂｌｉｓｈｅｄ）される。
図２５を参照すると、２５００５段階で、第２ＬＢＡ２５７０は、サーバー２５００に「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体を送信する。
この時、第２ＬＢＡ２５７０は、サーバー２５００に「選択されたＳＳＰ情報」を追加でさらに送信し得る。
「選択されたＳＳＰ情報」に対する説明は、図２２の説明を参照する。
また、第２ＬＢＡ２５７０は、サーバー２５００に「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を選択的にさらに送信し得る。
また、第２ＬＢＡ２５７０は、サーバー２５００に「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を選択的にさらに送信し得る。
また、第２ＬＢＡ２５７０は、サーバー２５００に「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」及び／又は「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」と関連した認証書チェーン情報をさらに含み得る。
上記の情報は、第２ＬＢＡ２５７０自ら構成して送信することもでき、本図に示さなかったが第２ＬＢＡ２５７０が２ＳＳＰ２５６０に当該情報をリクエストした後に、受信した情報を送信することもでき、若しくは、本図に示さなかったが第２ＬＢＡ２５７０がＳＳＰ２５６０に当該情報の一部をリクエストした後の受信した情報と自分が保有した情報を組み合わせて送信することもできる。
図２５を参照すると、２５０１０段階で、サーバー２５００は、２５００５段階で受信した情報を検証する。
検証過程の具体的手順は、次の通りである。
サーバー２５００は、受信した「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」及び／又は「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」の署名を検証して当該認証書の有効性を検証する。
また、サーバー２５００は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の署名を検証する。
また、サーバー２７００は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の内容を検証する。
また、サーバー２５００は、検証した内容に基づいて機器の間の送信されたバンドルの内訳をアップデートする。
一例として、サーバー２５００は、当該バンドルと第１ＳＳＰ２４１０の間に存在したマッピング（ｍａｐｐｉｎｇ）関係を当該バンドルと第２ＳＳＰ２５６０のマッピング（ｍａｐｐｉｎｇ）関係にアップデートする。
図２５を参照すると、２５０１５段階で、サーバー２５００は、第２ＬＢＡ２５７０に２５０１０段階で行なった検証作業の結果を送信する。
例えば、サーバー２５００は、第２ＬＢＡ２５７０に検証の成功又は失敗するかどうかを送信する。
図２６は、図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順を示す図である。
図２６は、バンドルの機器の間の送信内訳が、
・先告知（Ｐｒｅ－ｎｏｔｉｆｉｃａｔｉｏｎ）される必要があり、
・告知内容の暗号化が必要であるか必要ではない、
場合、適用される手順であり得る。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２６の例のように、第１端末２６００は、第１ＬＢＡ２６２０と第１ＳＳＰ２６１０を含み、第２端末２６５０は、第２ＬＢＡ２６７０と第２ＳＳＰ２６６０を含む。
例えば、第１端末２６００は、第１ＳＳＰ２６１０が装着されて第１ＳＳＰ２６１０を制御するための第１ＬＢＡ２６２０が設置された端末であっても良く、第２端末２６５０は第２ＳＳＰ２６６０が装着されて第２ＳＳＰ２６６０を制御するための第２ＬＢＡ２６７０が設置された端末であっても良い。
図２６を参照すると、２６０００段階で次の手順が行われる。
１．〔バンドル設置〕
図２６を参照すると、２６０００段階で、第２ＬＢＡ２６７０と第２ＳＳＰ２６６０は、互いに協業して第２端末２６５０にバンドルを設置する。
この過程で、次の手順が一緒に行われる。
もし、メタデータが送信された場合、第２ＬＢＡ２６７０又は第２ＳＳＰ２６６０は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第２ＬＢＡ２６７０は、この情報を第２ＳＳＰ２６６０で伝達する。
もし、トランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）が送信されると、第２ＬＢＡ２６７０又は第２ＳＳＰ２６６０は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もし、バンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが送信されると、第２ＬＢＡ２６７０又は第２ＳＳＰ２６６０は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」が送信されると、第２ＳＳＰ２６６０は、この認証書の有効性を検証して第１ＳＳＰ２６１０を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第２ＳＳＰ２６６０は、送信された「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０２」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第２ＳＳＰ２６６０は、「ｓｓｐ１．Ｃｅｒ。ＤＳ」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
２．〔先登録必要であるかどうか確認〕
また、図には示さなかったが、第２ＬＢＡ２６７０及び／又は第２ＳＳＰ２６６０は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び／又は「先告知必要であるかどうか」及び／又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、２６０００段階の一部として２６０００段階で行なわれる他の手順と手順に関わらず独立的に行うことができる。
若しくは、２６０００段階以後２６０３５段階が仕上げられる前、判断が必要な瞬間に行うこともできる。
本図で後述する手順は、「登録設定」を確認した結果、バンドルの機器の間送信内訳の先告知される必要がある場合、適用される手順であり得る。
図２６を参照すると、２６００５段階で、第２ＳＳＰ２６６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されたがまだ使用が不可能な状態（さらに、「本図で後述する追加動作と図２７で説明する追加動作」及び／又は「（本発明では説明されなかったが）外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）に変更することができる状態）を意味する。
図２６を参照すると、２６０１０段階で、第２ＬＢＡ２６７０は、第２ＳＳＰ２６６０に「証明書」をリクエストする。
図２６を参照すると、２６０１５段階で、第２ＳＳＰ２６６０は、「証明書」を生成する。
図２６で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８７０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２６を参照すると、２６０２０段階で、第２ＳＳＰ２６６０は、第１ＳＳＰ２６１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ２６６０は、第１ＳＳＰ２６１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ２６６０は、第２ＬＢＡ２６７０に２６０１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡは第１ＬＢＡ２６２０を経て第１ＳＳＰに「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図２６を参照すると、２６０２５段階で、第１ＳＳＰ２６１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、２６０２５段階で、第１ＳＳＰ２６１０は、検証を済んだ後のバンドルを削除する。
また、２６０２５段階で、第１ＳＳＰ２６１０は、「証明書」を生成する。
図２６で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体データを含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８３０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８５０に第１ＳＳＰがバンドルを削除したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８７０に第１ＳＳＰがバンドルを削除した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８９０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図２６を参照すると、２６０３０段階で、第１ＳＳＰ２６１０は、第２ＳＳＰ２６６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ２６１０は、第１ＬＢＡ２６２０と第２ＬＢＡ２６７０を経て第２ＳＳＰ２６６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図２６を参照すると、２６０３５段階で、第２ＳＳＰ２６６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」のデータ情報又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報がバンドルを削除することであるかを確認する過程をさらに含み得る。
また、２６０３５段階で、第２ＳＳＰ２６６０は、自分の「選択されたＳＳＰ情報（ｓｓｐＩｎｆｏｒＳｅｌｅｃｔｅｄ）」を生成する。
「選択されたＳＳＰ情報」には機器の間のバンドル送信結果をサーバーに告知するために提供されなければならない第２ＳＳＰの情報が含まれる。
この時、「選択されたＳＳＰ情報」には認証書交渉過程のための情報（認証書交渉情報）が含まれる。
この「認証書交渉情報」は、
・第２ＳＳＰ２６６０がサーバーを検証に用いることができる認証書情報（ｓｐｂｍＶｅｒｉｆｉｃａｔｉｏｎ）、
・サーバーが第１ＳＳＰ２６１０を検証に用いることができる認証書情報（ＳｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）、
・サーバーが第２ＳＳＰ２６６０を検証に用いることができる認証書情報（ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ）、
などの情報を選択的に含み得る。
また、「認証書交渉情報」は、第２ＳＳＰ２６６０がサポートする鍵合意アルゴリズムのリストを選択的にさらに含み得、第２ＳＳＰ２６６０がサポートする暗号化アルゴリズムのリストを選択的にさらに含み得る。
また「選択されたＳＳＰ情報」には第２ＳＳＰ２６６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報の内の少なくとも一つを含むＳＳＰバージョン情報が選択的にさらに含まれ得る。
図２６を参照すると、２６０４０段階で、第２ＳＳＰ２６６０は、２６０３５段階で行なった作業に対する結果（例えば、成功／失敗するかどうか）を第２ＬＢＡ２６７０に送信する。
また、２６０３５段階で生成した「選択されたＳＳＰ情報」が共に送信され得る。
２６０３５過程で、「選択されたＳＳＰ情報」を生成する過程と２６０４０段階で「選択されたＳＳＰ情報」を伝達する過程は、省略され得る。
図２７は、図２６で提示した手順の後、バンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図２７の例のように、第２端末２７５０は、第２ＬＢＡ２７７０と第２ＳＳＰ２７６０を含む。
一例として、第２端末２７５０は、第２ＳＳＰ２７６０が装着されて第２ＳＳＰ２７６０を制御するための第２ＬＢＡ２７７０が設置された端末であっても良い。
また、一実施形態によれば、サーバー２７００は、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び／又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明ではサーバー２７００を指称するためにサーバーの可能な例の内のいずれか一つであるＳＰＢＭという用語を用いる場合もあるが、前述したようにサーバーの種類はＳＰＢＭに限らない。
図２７を参照すると、２７０００段階で、ＳＰＢＭ２７００とＬＢＡ２７７０間にＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）接続が形成（ｅｓｔａｂｌｉｓｈｅｄ）される。
本図では２７０００段階が２７００５段階～２７０１５段階以前に行われることとして記載しているが、２７０００段階は、２７０２０段階が行われる前の２７００５段階～２７０１５段階とは独立的に行われ得る。
例えば、２７０００段階は、２７０１５段階と２７０２０段階の間に行われ得る。
図２７を参照すると、２７００５段階で、第２ＬＢＡ２７７０は、第２ＳＳＰ２２７６０に「選択されたＳＳＰ情報（ＳｓｐＩｎｆｏＳｅｌｅｃｔｅｄ）」をリクエストする。
この時、２７００５段階は、自動に行うこともでき、外部の入力を受けた後に行うこともできる。
この時、「外部の入力」は、第２端末２７５０が提供するＵＩを介してユーザから与えることもでき、リモートサーバーからプッシュ入力を介して第２端末２７５０に与えることもできる。
図２７を参照すると、２７０１０段階で、第２ＳＳＰ２７６０は、自分の「選択されたＳＳＰ情報」を生成する。
「選択されたＳＳＰ情報」に対する説明は、図２６に記載した説明を参照する。
図２７を参照すると、２７０１５段階で、第２ＳＳＰ２７６０は、第２ＬＢＡ２７７０に２７０１０段階で生成した「選択されたＳＳＰ情報」を送信する。
２７００５段階～２７０１５段階は、場合によって省略され得る。
図２７を参照すると、２７０２０段階で、第２ＬＢＡ２７７０は、サーバー２７００に「選択されたＳＳＰ情報」を送信する。
もし、第２ＬＢＡ２７７０が、図２６の２６０３５段階～２６０４０段階を介して「選択されたＳＳＰ情報」を受信したか、若しくは、図２７の２７００５段階～２７０１５段階を介して「選択されたＳＳＰ情報」を受信する場合、第２ＬＢＡ２７７０は、サーバー２７００に受信した「選択されたＳＳＰ情報」を送信する。
若し、第２ＬＢＡ２７７０が「選択されたＳＳＰ情報」を受信しない場合、第２ＬＢＡ２７７０は、「選択されたＳＳＰ情報」を生成してサーバー２７００に送信する。
図２７を参照すると、２７０２５段階で、サーバー２７００は、受信した「選択されたＳＳＰ情報」を確認してこの情報に基づいて自分を認証することができる「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」を生成する。
この過程に対するより具体的な手順は、次の通りである。
サーバー２７００は、受信した「ｓｐｂｍＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して少なくとも一つ以上の鍵合意用認証書（ｓｐｂｍ．Ｃｅｒｔ．ＫＡ）を選択する。
若しくは、サーバー２７００は、受信した「第２ＳＳＰ２７６０がサポートする鍵合意アルゴリズムのリスト」を用いて鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｐｂｍ．ｅＰＫ．ＫＡ」と秘密鍵「ｓｐｂｍ．ｅＳＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｐｂｍ．ｅＰＫ．ＫＡ）を選択する。
また、サーバー２７００は、受信した「ｓｐｂｍＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分を検証することができる認証書情報を確認して、少なくとも一つ以上の署名用認証書（ｓｐｂｍ．Ｃｅｒｔ．ＤＳ）をさらに選択する。
また、サーバー２７００は、受信した「ｓｅｎｄｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて検証を行う第１ＳＳＰ２６１０の認証書情報が、自分が検証可能なことであるかどうかを確認する。
また、サーバー２７００は、受信した「ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて検証を行う第２ＳＳＰ２７６０の認証書情報が、自分が検証可能なことであるかどうかを確認する。
若しくは、「ＲｅｃｅｉｖｅｒＳｐｂｌＶｅｒｉｆｉｃａｔｉｏｎ」を用いて自分が検証することができる第２ＳＳＰ２７６０の認証書情報を少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」で設定する。
また、サーバー２７００は、受信した「第２ＳＳＰ２７６０がサポートする暗号化アルゴリズムのリスト」を用いて今後の用いられる暗号化アルゴリズムを少なくとも一つ以上選択した後に、ここに該当する情報を「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」に設定する。
また、サーバー２７００は、受信した「第２ＳＳＰ２７６０が含むプライマリープラットホーム及びローダーがサポートする標準規格のバージョン情報」のリストを確認して、その内の自分もサポートする標準規格のバージョンが存在するかを確認する。
「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ」は、前述した「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」、「ｓｐｂｍ．ｅＰＫ．ＫＡ」、「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」、「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」、「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」の内の少なくとも一つを含む。
この時、上記に言及した「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「サーバー認証情報」の一部として追加される。
図２７を参照すると、２７０３０段階で、サーバー２７００は、第２ＬＢＡ２７７０を経て第２ＳＳＰ２７６０に２７０２５段階で生成した「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」を伝達する。
図２７を参照すると、２７０３５段階で、第２ＳＳＰ２７６０は、受信した「サーバー認証情報（ＳＰＢＭ．Ａｕｔｈ）」を検証する。
若し、第２ＳＳＰ２７６０が「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第２ＳＳＰ２７６０が「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を受信した場合、当該認証書の署名を確認して認証書の有効性を確認する。
また、第２ＳＳＰ２７６０が「ｓｐｂｍ．ｅＰＫ．ＫＡ」とこれに対するデジタル署名が送信された場合には、「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を用いてデジタル署名を確認して受信した公開鍵「ｓｐｂｍ．ｅＰＫ．ＫＡ」の無欠性を確認する。
また、第２ＳＳＰ２７６０は、「ＣｉＰｋＩｄＴｏＢｅＵｓｅｄ」を受信した場合、これを確認して自分を検証することができる少なくとも一つ以上の署名用認証書（ｓｓｐ２．Ｃｅｒｔ．ＤＳ）を選択する。
また、図には示していないが、２７０３５段階で、第２ＳＳＰ２７６０は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）で公開鍵 「ｓｓｐ２．ｅＰＫ．ＫＡ」と秘密鍵「ｓｓｐ２．ｅＳＫ．ＫＡ」を生成した後、この鍵の対の内の公開鍵（ｓｓｐ２．ｅＰＫ．ＫＡ）を選択する。
また、第２ＳＳＰ２７６０は、「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵や「ｓｐｂｍ．ｅＰＫ．ＫＡ」の中で一つを選択した後、この値と「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いて今後のサーバーとの通信の中で暗号化に用いられるセッション鍵「ＳｈＫｅｙ０３」を生成する。
「ＳｈＫｅｙ０３」は、受信した「ＣｒｙｐｔｏＴｏＢｅＵｓｅｄ」に含まれている暗号化アルゴリズム用セッション鍵ではなければならない。
また、２７０３５段階で、第２ＳＳＰ２７６０は、自分を認証することができる「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」を生成する。
この時、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を含む。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ２．ｅＰＫ．ＫＡ」をさらに含み得る。
また「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」を選択的にさらに含み得る。
また「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体を含み得る。
また「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体を含み得る。
この時、上記で言及した「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」の一部又は全体は、情報の無欠性を保障するために「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」を用いて検証可能になるようにデジタル署名され、このデジタル署名データは、「端末認証情報」の一部として追加される。
また、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」の一部又は全体は、先立って生成されたセッション鍵「ＳｈＫｅｙ０３」を用いて暗号化される。
図２７を参照すると、２７０４０段階で、第２ＳＳＰ２７６０は、第２ＬＢＡ２７７０を経てサーバー２７００に２７０３５段階で生成した「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」を伝達する。
図２７を参照すると、２７０４５段階で、サーバー２７００は、受信した「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」を検証する。
検証過程の具体的手順は、次の通りである。
サーバー２７００は、受信した「ｓｓｐ１．Ｃｅｒｔ．ＤＳ」及び／又は「ｓｓｐ２．Ｃｅｒｔ．ＤＳ」の署名を検証して当該認証書の有効性を検証する。
また、サーバー２７００は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の署名を検証する。
また、サーバー２７００は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の内容を検証する。
また、サーバー２７００は、検証した内容に基づいて機器の間の送信されたバンドルの内訳をアップデートする。
例えば、サーバー２７００は、当該バンドルと第１ＳＳＰ２６１０の間に存在したマッピング（ｍａｐｐｉｎｇ）関係を当該バンドルと第２ＳＳＰ２７６０のマッピング（ｍａｐｐｉｎｇ）関係にアップデートする。
この過程で、若し、「端末認証情報（Ｄｅｖｉｃｅ．Ａｕｔｈ）」に暗号化されたデータが含まれている場合、サーバー２７００は、送信された「ｓｓｐ２．ｅＰＫ．ＫＡ」と自分の「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」に含まれている鍵合意用公開鍵に対応する秘密鍵や「ｓｐｂｍ．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０３」を生成し、このセッション鍵を用いて暗号化されたデータを復号化した後に検証過程を行う。
また、２７０４５段階で、サーバー２７００は、「証明書」を生成する。
図２７で、この証明書は、「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」の一部及び／又は全体データを含む。
・「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８３０にサーバーの識別子（例えば、サービス提供者の識別子及び／又はバンドル管理サーバーの識別子及び／又はサーバーの住所）を含む。
・「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８５０にサーバーがバンドルの移動内訳を確認したことを意味する情報を含む。
・「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８７０にサーバーがバンドルの移動内訳を確認した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８９０にサーバーの署名情報を含む。
この署名は、前述した情報に対してサーバーの署名用認証書で電子署名をした署名情報であっても良い。
また２７０４５段階で、図２７に示していないが、サーバー２７００は、鍵合意に用いられる非対称暗号化用鍵の対（ｋｅｙ ｐａｉｒ）公開鍵「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＰＫ．ＫＡ」と秘密鍵「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＳＫ．ＫＡ」を生成する。
この時、鍵の対「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＰＫ．ＫＡ」と「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＳＫ．ＫＡ」は、先立って生成された「ｓｐｂｍ．ｅＰＫ．ＫＡ」と「ｓｐｂｍ．ｅＳＫ．ＫＡ」と同一値で設定され得る。
又は、鍵の対「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ。ｅＰＫ．ＫＡ」と「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＳＫ．ＫＡ」は、先立って用いられた「ｓｐｂｍ．Ｃｅｒｔ．ＫＡ」に含まれている公開鍵とここに対応する秘密鍵と同一値で設定され得る。
また、サーバー２７００は、「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＳＫ．ＫＡ」と「ｓｓｐ２．ｅＰＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０４」を生成する。
もし、「ｓｐｂｍ．ａｔｔｓｔａｔｉｏｎ．ｅＳＫ．ＫＡ」のために「ｓｐｂｍ．ｅＳＫ．ＫＡ」又は「ｓｐｂｍ．Ｃｅｒｔ．Ｋａ」に含まれている公開鍵に対応する秘密鍵が再使用されると、セッション鍵「ＳｈＫｅｙ０４」の値も以前に生成された「ＳｈＫｅｙ０３」の値に設定され得る。
また２７０４５段階で、図２７に示していないが、サーバー２７００は、「証明書検証資料」を構成する。
「証明書検証資料」には、「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」が含まれる。
また、「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＰＫ．ＫＡ」及び／又は「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＰＫ．ＫＡ」に対するサーバーの電子署名値がさらに含まれ得る。
一実施形態によれば、２７０４５段階で生成された「証明書」と「証明書検証資料」の一部及び／又は全体は、「ＳｈＫｅｙ０４」を用いて暗号化される。
図２７を参照すると、２７０５０段階で、サーバー２７００は、第２ＬＢＡ２７７０を経て第２ＳＳＰ２７６０に２７０４５段階で生成された「ｓｐｂｍＡｔｔｅｓｔａｔｉｏｎ」と「証明書検証資料」を送信する。
図２７を参照すると、２７０５５段階で、第２ＳＳＰ２７６０は、受信した「ｓｐｂｍＡｔｔｅｓｔａｉｏｎ」及び／又は「証明書検証資料」を検証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第２ＳＳＰ２７６０は、送信された「ｓｐｂｍ．ａｔｔｅｓｔａｔｉｏｎ．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０４」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第２ＳＳＰ２７６０は、「ｓｐｂｍ．Ｃｅｒｔ．ＤＳ」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
また、２７０５５段階で、第２ＳＳＰ２７６０は、検証を済んだ後のバンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ２７６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
図２７を参照すると、２７０６０段階で、第２ＳＳＰ２７６０は、２７０６０段階の実行結果を第２ＬＢＡ２７７０に伝達する。
例えば、第２ＳＳＰ２７６０は、２７０６０段階の検証成功又は失敗結果を第２ＬＢＡ２７７０に伝達する。
図２８は、本発明の一実施形態による端末の概略構成を示すブロック図である。
図２８に示すように、端末は、送受信部（Ｔｒａｎｓｃｅｉｖｅｒ）２８１０及び少なくとも一つのプロセッサ２８２０を含む。
また、端末は、ＳＳＰ２８３０をさらに含む。
例えば、ＳＳＰ２８３０は、端末に挿入することができ、端末に内蔵することもできる。
少なくとも一つ以上のプロセッサ２８２０は、「制御部」で名付けることもできる。
ただ、端末の構成は、図２８に制限されず、図２８に示した構成要素より多い構成要素を含むか、より少ない構成要素を含むこともできる。
一実施形態によれば、送受信部２８１０、少なくとも一つのプロセッサ２８２０及びメモリ（図示せず）は，一つのチップ（Ｃｈｉｐ）形態に具現することができる。
また、ＳＳＰ２８３０が内蔵する場合、ＳＳＰ２８３０を含み、一つのチップ形態で具現することもできる。
一実施形態によれば、送受信部２８１０は、他の端末の送受信部又は外部サーバーと本発明の実施形態による信号、情報、データなどを送信及び受信を行う。
送受信部２８１０は、送信する信号の周波数を上昇変換（ｕｐ ｃｏｎｖｅｒｔｉｎｇ）及び増幅するＲＦ送信機と、受信する信号を低雑音増幅して周波数を下降変換（ｄｏｗｎ ｃｏｎｖｅｒｔｉｎｇ）するＲＦ受信機などで構成される。
ただ、これは送受信部２８１０の一実施形態だけであって、送受信部２８１０の構成要素がＲＦ送信機及びＲＦ受信機に限定されることではない。
また、送受信部２８１０は、無線チャンネルを介して信号を受信して少なくとも一つのプロセッサ２８２０に出力し、少なくとも一つのプロセッサ２８２０から出力された信号を、無線チャンネルを介して送信する。
一実施形態によれば、送受信部２８１０は、他の端末の送受信部又は外部サーバーから他の端末に含まれたＳＳＰの情報、他の端末を認証することができる認証情報、サーバーを認証することができる認証情報、自分を認証することができる認証情報、バンドル移動コード、バンドル移動設定、バンドル、図２２～図２７で記載した多様な証明書などを送信するか、受信する。
一方、少なくとも一つのプロセッサ２８２０は、端末を全般的に制御するための構成要素である。
少なくとも一つのプロセッサ２８２０は、前述したような本発明の多様な実施形態によって、端末の全般的な動作を制御する。
一方、ＳＳＰ２８３０は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置され得る。
一実施形態によれば、ＳＳＰ２８３０内の少なくとも一つのプロセッサ又はコントローラーは、バンドル移動設定を確認して、特定バンドルを送信するかどうかを決定する。
また、バンドル移動設定を確認して当該バンドルの機器の間のバンドル移動結果をサーバーに登録しなければならないか、登録が必要である場合、先告知が必要であるかどうかを判断する。
また、一実施形態によれば、ＳＳＰ内の少なくとも一つ以上のプロセッサ又はコントローラーは、バンドル移動コードを生成して特定バンドルの送信過程を制御する。
また、一実施形態によれば、ＳＳＰ内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分のＳＳＰ情報を生成し、外部から送信された他のＳＳＰのＳＳＰ情報を確認して検証する。
また、一実施形態によれば、ＳＳＰ内の少なくとも一つ以上のプロセッサ又はコントローラーは、自分を検証することができる認証情報を生成し、外部から送信された他のＳＳＰの認証情報を検証する。
また、一実施形態によれば、ＳＳＰ２８３０は、バンドルを生成し、単独又は一つ以上のプロセッサ２８２０と協力してバンドルを設置する。
また、ＳＳＰ２８３０は、バンドルを管理する。
また、一実施形態によれば、ＳＳＰ２８３０は、図２２～図２７で記載した多様な形態の証明書を生成し、受信した証明書を検証する。
また、一実施形態によれば、ＳＳＰ２８３０は、図２２～図２７で記載したように受信した証明書の内容に基づいてバンドルの状態を変更する。
また、一実施形態によれば、ＳＳＰ２８３０は、プロセッサ２８２０の制御によって動作する。
又は、ＳＳＰ２８３０は、バンドルを設置して制御するためのプロセッサ又はコントローラーを含むか、アプリケーションが設置され得る。
アプリケーションの一部又は全部は、ＳＳＰ２８３０又はメモリ（図示せず）に設置され得る。
一方、端末は、メモリ（図示せず）をさらに含み、端末の動作のための基本プログラム、アプリケーション、設定情報などのデータを記憶する。
また、メモリは、フラッシュメモリタイプ（Ｆｌａｓｈ Ｍｅｍｏｒｙ Ｔｙｐｅ）、ハードディスクタイプ（Ｈａｒｄ Ｄｉｓｋ Ｔｙｐｅ）、マルチメディアカードマイクロタイプ（Ｍｕｌｔｉｍｅｄｉａ Ｃａｒｄ Ｍｉｃｒｏ Ｔｙｐｅ）、カードタイプのメモリ（例えば、ＳＤ又はＸＤメモリなど）、磁気メモリ、磁気ディスク、光ディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲОＭ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）の内の少なくとも一つの記憶媒体を含み得る。
また、プロセッサ２８２０は、メモリに記憶された各種プログラム、コンテンツ、データなどを用いて多様な動作を行う。
図２９は、本発明の実施形態によるサーバーの概略構成を示すブロック図である。
この時、サーバーは、サービス提供者によって操作されるサーバーであっても良く、バンドル管理サーバーであっても良く、サービス提供者とバンドル管理サーバーの協業によって操作されるサーバーであっても良く、若しくは、サービス提供者及び／又はバンドル管理サーバーと連係して操作される任意のサーバーであっても良い。
本図の説明ではサーバーを指称するためにサーバーの可能な例の内のいずれか一つのバンドル管理サーバーという用語を用いるが、前述したようにサーバーの種類はバンドル管理サーバーに限らない。
一実施形態よれば、バンドル管理サーバーは、送受信部（Ｔｒａｎｓｃｅｉｖｅｒ）２９１０及び少なくとも一つ以上のプロセッサ２９２０を含む。
ただ、バンドル管理サーバーの構成は、図２９に制限されず、図２９に示した構成要素より多い構成要素を含むか、より少ない構成要素を含むこともできる。
一実施形態によれば、送受信部２９１０、少なくとも一つのプロセッサ２９２０、及びメモリ（図示せず）は、一つのチップ（Ｃｈｉｐ）形態で具現され得る。
一実施形態によれば、送受信部２９１０は、端末と本発明の多様な実施形態による信号、情報、データなどを送信及び受信する。
送受信部２９１０は、送信する信号の周波数を上昇変換及び増幅するＲＦ送信機と、受信する信号を低雑音増幅して周波数を下降変換するＲＦ受信機などで構成される。
ただ、これは、送受信部２９１０の一実施形態だけであって、送受信部２９１０の構成要素がＲＦ送信機及びＲＦ受信機に限定されることではない。
また、送受信部２９１０は、無線チャンネルを介して信号を受信して、少なくとも一つのプロセッサ２９２０に出力し、少なくとも一つのプロセッサ２９２０から出力された信号を、無線チャンネルを介して送信する。
一方、少なくとも一つ以上のプロセッサ２９２０は、バンドル管理サーバーを全般的に制御するための構成要素である。
プロセッサ２９２０は、前述のような本発明の多様な実施形態によって、バンドル管理サーバーの全般的な動作を制御する。
少なくとも一つ以上のプロセッサ２９２０は、制御部と名付けることができる。
一方、バンドル管理サーバーは、メモリ（図示せず）をさらに含み、バンドル管理サーバーの動作のための基本プログラム、アプリケーション、設定情報などのデータを記憶する。
また、メモリは、フラッシュメモリタイプ（Ｆｌａｓｈ Ｍｅｍｏｒｙ Ｔｙｐｅ）、ハードディスクタイプ（Ｈａｒｄ Ｄｉｓｋ Ｔｙｐｅ）、マルチメディアカードマイクロタイプ（Ｍｕｌｔｉｍｅｄｉａ Ｃａｒｄ Ｍｉｃｒｏ Ｔｙｐｅ）、カードタイプのメモリ（例えば、ＳＤ又はＸＤメモリなど）、磁気メモリ、磁気ディスク、光ディスク、 ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭ）、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）の内の少なくとも一つの記憶媒体を含み得る。
また、プロセッサ２９２０は、メモリに記憶された各種プログラム、コンテンツ、データなどを用いて多様な動作を行う。
図３０は、図１９で提示した手順の内のバンドルの送信が仕上げられる手順に対するまた他の詳細手順及びバンドルの送信結果がサーバーに登録される手順を示す図である。
一実施形態によれば、端末は、少なくとも一つのＬＢＡ及び少なくとも一つのＳＳＰを含む。
例えば、図３０の例のように、第１端末３０００は、第１ＬＢＡ３０２０と第１ＳＳＰ３０１０を含み、第２端末３０５０は、第２ＬＢＡ３０７０と第２ＳＳＰ３０６０を含む。
例えば、第１端末３０００は、第１ＳＳＰ３０１０が装着されて第１ＳＳＰ３０１０を制御するための第１ＬＢＡ３０２０が設置された端末であっても良く、第２端末３０５０は、第２ＳＳＰ３０６０が装着されて第２ＳＳＰ３０６０を制御するための第２ＬＢＡ３０７０が設置された端末であっても良い。
図３０を参照すると、３００００段階で次の手順が行われる。
１．〔バンドル設置〕
図３０を参照すると、３００００段階で、第２ＬＢＡ３０７０と第２ＳＳＰ３０６０は、互いに協業して第２端末３０５０にバンドルを設置する。
この過程で次の手順が共に行われる。
もし、メタデータが送信された場合、第２ＬＢＡ３０７０又は第２ＳＳＰ３０６０は、メタデータに含まれた内容を検証する。
若し、「バンドル移動設定」が送信されると、第２ＬＢＡ３０７０は、上記情報を第２ＳＳＰ０６０へ伝達する。
もし、トランザクションアイディー（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）が送信されると、第２ＬＢＡ３０７０又は第２ＳＳＰ３０６０は、このトランザクションアイディーが現在セッションで用いられたトランザクションアイディーと同一であるかどうかを検査する。
もしバンドル識別子（ＳＰＢ ＩＤ）、バンドルファミリ識別子（ＳＰＢ Ｆａｍｉｌｙ ＩＤ）、バンドルファミリ管理者識別子（ＳＰＢ Ｆａｍｉｌｙ Ｃｕｓｔｏｄｉａｎ Ｏｂｊｅｃｔ ＩＤ）の内の少なくとも一つが送信されると、第２ＬＢＡ３０７０又は第２ＳＳＰ３０６０は、この情報が現在受信しようとするバンドルの情報と一致するかどうかを確認する。
もし、「ｓｐ１．Ｃｅｒｔ．ＤＳ」が送信されると、第２ＳＳＰ３０６０は、この認証書の有効性を検証して第１ＳＳＰ３０１０を認証する。
もし、送信されたデータに暗号化されたデータが含まれていると、第２ＳＳＰ３０６０は、送信された「ｓｓｐ１．ｂｕｎｄｌｅ．ｅＰＫ．ＫＡ」と自分の「ｓｓｐ２．ｅＳＫ．ＫＡ」を用いてセッション鍵「ＳｈＫｅｙ０２」を生成し、このセッション鍵を用いて暗号化されたデータを復号した後の検証を行う。
もし、受信したデータにデジタル署名が含まれていると、第２ＳＳＰ３０６０は、「ｓｓｐ１．Ｃｅｒ．ＤＳ」を検証した後、この認証書を用いてデジタル署名の有効性を検証する。
２．〔「登録設定」確認〕
また、図には示さなかったが、第２ＬＢＡ３０７０及び／又は第２ＳＳＰ３０６０は、当該バンドルの「登録設定」を用いて「告知必要であるかどうか」及び／又は「先告知必要であるかどうか」及び／又は「告知内容の暗号化必要であるかどうか」を確認する。
この過程は、３００００段階の一部として３００００段階で行われる他の手順と手順に関わらず独立的に行われ得る。
若しくは、３００００段階以後３００４０段階又は３００５０段階で告知が行う前、「登録設定」を確認して判断が必要な瞬間に行うこともできる。
図３０を参照すると、３０００５段階で、第２ＳＳＰ３０６０は、当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されているが使用が不可能な状態（さらに、「第１端末３０００のリクエスト」及び／又は「外部サーバーのリクエスト」のような動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）に変更することができる状態）を意味する。
図３０を参照すると、３００１０段階で、第２ＬＢＡ３０７０は、第２ＳＳＰ３０６０に「証明書」をリクエストする。
図３０を参照すると、３００１５段階で、第２ＳＳＰ３０６０は、「証明書」を生成する。
図３０で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８５０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８７０に第２ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」は、図１８の符号１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図３０を参照すると、３００２０段階で、第２ＳＳＰ３０６０は、第１ＳＳＰ３０１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
例えば、第２ＳＳＰ３０６０は、第１ＳＳＰ３０１０に次のような過程を経て「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
すなわち、第２ＳＳＰ３０６０は、第２ＬＢＡ３０７０に３００１０段階の応答で「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達し、第２ＬＢＡ３０７０は、第１ＬＢＡ３０２０を経て第１ＳＳＰ３０１０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を伝達する。
図３０を参照すると、３００２５段階で、第１ＳＳＰ３０１０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に変更することであるかを確認する過程をさらに含み得る。
また、３００２５段階で、第１ＳＳＰ３０１０は、検証が済んだ後当該バンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定する。
「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」は、バンドルが成功裏に設置されているが使用が不可能な状態（さらに、「第２端末３０５０のリクエスト」及び／又は「外部サーバーのリクエスト」のような追加動作によってだけ使用可能な状態（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅ状態）に変更することができる状態）を意味する。
また、３００２５段階で、第１ＳＳＰ３０１０は、「証明書」を生成する。
図３０で、この証明書は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、以前段階で受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」の一部及び／又は全体データを含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８３０に第１ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８５０に第１ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定したことを意味する情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８７０に第１ＳＳＰがバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」状態に設定した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」は、図１８の符号１８９０に第１ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第１ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図３０を参照すると、３００３０段階で、第１ＳＳＰ３０１０は、第２ＳＳＰ３０６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
例えば、第１ＳＳＰ３０１０は、第１ＬＢＡ３０２０と第２ＬＢＡ３０７０を経て第２ＳＳＰ３０６０に「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を伝達する。
図３０を参照すると、３００３５段階で、第２ＳＳＰ３０６０は、受信した「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」を検証する。
この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた第１ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程を選択的にさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」のデータ一部又は全体が、自分が送信した情報と一致するかどうかを検査する過程を含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれた「ＳＳＰ識別子」を確認する過程をさらに含み得る。
また、この検証過程は、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」に含まれたコマンド情報がバンドルの状態を「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定することであるかを確認する過程をさらに含み得る。
図３０を参照すると、３００４０段階で、先告知（Ｐｒｅ－ｎｏｔｉｆｉｃａｔｉｏｎ）手順が行われる。
この手順は、「登録設定」に先告知が必要であると設定されている場合、適用される手順であり得る。
もし、先告知手順が行われると、この手順は、以下の通りである。
先ず、第２ＳＳＰ３０６０が「ｓｓｐＩｎｆｏＳｅｌｅｃｔｅｄ」を生成してこの情報を第２ＬＢＡ３０７０で送信する。
この過程は、必要によって省略されることもできる。
この時、「ｓｓｐＩｎｆｏＳｅｌｅｃｔｅｄ」に対する説明は、図２６の説明を参照する。
以後、図２７に記載した手順の内の２７０５５段階の「バンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する手順」以前までの過程が行われる。
図３０を参照すると、３００４５段階で、第２ＳＳＰ３０６０は、バンドルの状態を使用可能な状態の内の一つ（Ｄｉｓａｂｌｅｄ、Ｅｎａｂｌｅ、Ａｃｔｉｖｅの内の一つ）に変更する。
例えば、図に示したように、第２ＳＳＰ３０６０は、バンドルの状態を「Ｄｉｓａｂｌｅｄ」状態に変換する。
また、３００４５段階で、第２ＳＳＰ３０６０は、「証明書」を生成する。
図３０で、この証明書は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」と呼ばれる。
この証明書の構造は、図１８に開示した構造による。
この時、可能な証明書構成の一例は、次の通りである。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８１０に当該バンドルの「バンドル区分者」を含む。
若しくは、「ｆｉｎａｌｉｚａｔｉｏｎＲｅｑｕｅｓｔ」及び／又は「ｆｉｎａｌｉｚａｔｉｏｎＲｅｓｐｏｎｓｅ」及び／又は「ｓｐｂｍＡｔｔｅｓｔａｉｏｎ」の一部及び／又は全体データを含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８３０に第２ＳＳＰの「ＳＳＰ識別子」を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８５０に第２ＳＳＰがバンドルを使用可能な状態の内の一つに変更したことを意味する情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８７０に第２ＳＳＰがバンドルの状態を使用可能な状態の中の一つに変更した時間又は証明書を生成した時間を選択的に含む。
若しくは、後述する電子署名に用いられた署名用認証書の情報とそれに関連する認証書チェーンの情報を含む。
・「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」は、図１８の符号１８９０に第２ＳＳＰの署名情報を含む。
この署名は、前述した情報に対して第２ＳＳＰの署名用認証書で電子署名をした署名情報であっても良い。
図３０を参照すると、３００５０段階で、後告知（Ｐｏｓｔ－ｎｏｔｉｆｉｃａｔｉｏｎ）手順が行われる。
この手順は「登録設定」に先告知が必要であると設定されている場合、適用される手順であり得る。
もし、後告知手順が行われると、この手順は、以下の通りである。
ａ．〔「登録設定」に告知内容の暗号化が必要と設定されている場合〕
先ず、第２ＳＳＰ３０６０が「ｓｓｐＩｎｆｏＳｅｌｅｃｔｅｄ」を生成してこの情報を第２ＬＢＡ３０７０で送信する。
この過程は、必要によって省略され得る。
この時、「ｓｓｐＩｎｆｏＳｅｌｅｃｔｅｄ」に対する説明は、図２２の説明を参照する。
以後、図２３に記載した手順が行われる。
ｂ．〔「登録設定」に告知内容の暗号化が必要ではないと設定されている場合〕
先ず、第２ＳＳＰ３０６０が「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を第２ＬＢＡ３０７０に送信する。
以後、図２５に記載した手順が行われる。
図３０を参照すると、３００５５段階で、第２ＳＳＰ３０６０は、第２ＬＢＡ３０７０と第１ＬＢＡ３０２０を経て第１ＳＳＰ３０１０に「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を送信する。
図３０を参照すると、３００６０段階で、第１ＳＳＰ３０１０は、受信した「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を検証する。
この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた第２ＳＳＰの署名の有効性を検査する段階を含む。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「バンドル区分者」が当該バンドルのバンドル区分者と一致するかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれた「ＳＳＰ識別子」が第２ＳＳＰの正しい識別子であるかどうかを検査する過程をさらに含み得る。
また、この検証過程は、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」に含まれたコマンド情報がバンドルの状態を使用可能な状態の内の一つに設定したことであるかを確認する過程をさらに含み得る。
また、３００６０段階で、第１ＳＳＰ３０１０は、バンドルを削除する。
３００４５段階で、「ｓｐｂｌＡｔｔｅｓｔａｔｉｏｎ」を生成する手順及び／又は３００５５段階及び／又は３００６０段階は、必要によって省略され得る。
３００４０段階又は３００５０段階に記載した告知過程が完了しない場合（例えば、サーバーに告知送信したがこれに対する応答を受けることができない場合）第２端末は、繰り返して告知サーバーに再送信する。
再送信過程は、予め設定された再送信最大回数によってこの最大値を満足するまで行うこともでき、若しくは、サーバーから応答を受信するまで繰り返して行うこともできる。
「登録設定」によって先告知が必要だが３００４０段階が正常に行われなく、第１端末３０００と第２端末３０５０の両機器でバンドルが使用不可能となった場合、図２９で説明したサーバーのリクエストによって第１端末３０００及び／又は第２端末３０５０に設置されたバンドルの状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」から使用可能な状態の内の一つ（例えば、「Ｄｉｓａｂｌｅｄ」状態）に変更される。
上述した本発明の具体的な実施形態で、開示に含まれる構成要素は提示した具体的な実施形態によって単数又は複数で表現された。
しかし、単数又は複数の表現は、説明の便宜のために提示した状況に適合に選択されたことで、本発明が単数又は複数の構成要素で制限されることではなく、複数で表現された構成要素と言っても単数で構成されるか、単数で表現された構成要素と言っても複数で構成され得る。
一方、本発明の詳細な説明では具体的な一実施形態に関して説明したが、本発明の範囲から逸脱せず範囲内で様々な変形が可能であることは勿論である。
したがって、本発明の範囲は、説明した実施形態に限って決定されてはなく、後述する特許請求の範囲だけではなくこの特許請求の範囲と均等なものなどによって定められなればならない。
本発明の多様な実施形態及びここに用いられた用語は、本発明に記載した技術を特定の実施形態に対して限定しようとすることではなく、当該実施形態の多様な変更、均等物、及び／又は代替物を含むことに理解されなければならない。
図面の説明に関連して、類似の構成要素に対しては、類似の参照符号が用いた。
単数の表現は、文脈上の明白に異なるように意味しない限り、複数の表現を含むことができる。
本発明において、「Ａ又はＢ」、「Ａ及び／又はＢの内の少なくとも一つ」、「Ａ、Ｂ又はＣ」、「Ａ、Ｂ及び／又はＣの内の少なくとも一つ」などの表現は、共に羅列された項目のすべての可能な組み合せを含み得る。
「第１」、「第２」、「一番目」、又は「二番目」などの表現は、当該構成要素を、順序又は重要度に関わらず修飾することができ、一つの構成要素と他の構成要素と区分するために用いられるだけ、当該構成要素を限定しない。
ある（例えば、第１）構成要素が他（例えば、第２）の構成要素に「機能的に又は通信的に連結」されているか、「接続されて」いると言及されたときには、前記ある構成要素が前記他の構成要素に直接的に連結されたり、他の構成要素（例えば、第３構成要素）を介して連結され得る。
本発明で用いる用語「モジュール」は、ハードウェア、ソフトウェア、又はファームウエアから構成されたユニットを含み、例えば、ロジック、論理ブロック、部品、又は回路などの用語と相互互換的に用いられる。
モジュールは、一体で構成された部品又は一つ又はその以上の機能を行う最小単位又はその一部になる。
例えば、モジュールは、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）で構成され得る。
本明細書の多様な実施形態は、機器（ｍａｃｈｉｎｅ）（例えば、コンピューター）によって読める記憶媒体（ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）（例えば、内蔵メモリ又は外蔵メモリ）に記憶されたコマンドを含むソフトウェア（例えば、プログラム）で具現することができる。
機器は、記憶媒体から記憶されたコマンドを呼び出し、呼び出されたコマンドによって動作が可能な装置として、多様な実施形態による他の端末を含み得る。
コマンドがプロセッサによって実行される場合、プロセッサが直接、又はプロセッサの制御下に他の構成要素を用いてコマンドに該当する機能を行う。
コマンドは、コンパイラー又はインタプリターによって生成又は実行されるコードを含み得る。
機器で読める記憶媒体は、非一時的（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）記憶媒体の形態で提供され得る。
ここで、「非一時的」は、記憶媒体が信号（ｓｉｇｎａｌ）を含まず実在（ｔａｎｇｉｂｌｅ）するということを意味するだけ、データが記憶媒体に半永久的又は臨時的に記憶されることを区分しない。
本発明で開示した多様な実施形態による方法は、コンピュータープログラム製品（ｃｏｍｐｕｔｅｒ ｐｒｏｇｒａｍ ｐｒｏｄｕｃｔ）に含まれて提供され得る。
コンピュータープログラム製品は、商品として販売者及び購買者の間で取り引きされる。
コンピュータープログラム製品は、機器で読める記憶媒体（例えば、ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ（ＣＤ－ＲＯＭ））の形態で、又はアプリケーションストア（例えば、プレイストア（登録商標））を介してオンラインで配布することができる。
オンライン配布の場合に、コンピュータープログラム製品の少なくとも一部は、製造者のサーバー、アプリケーションストアのサーバー、又は中継サーバーのメモリのように記憶媒体に少なくとも一時記憶されたり、臨時的に生成され得る。
一実施形態による構成要素（例えば、モジュール又はプログラム）それぞれは、単数又は複数の個体から構成され得、前述した当該サブ構成要素の内の一部サブ構成要素が省略されるか、又は他のサブ構成要素が多様な実施形態にさらに含み得る。
大体的又は追加的に、複数の構成要素（例えば、モジュール又はプログラム）は、一つの個体に統合され、統合される以前のそれぞれの当該構成要素によって行われる機能を同一又は類似に行うことができる。
多様な実施形態による、モジュール、プログラム又は他の構成要素によって行われる動作は、順次的、並列的に、繰り返し的に、又はヒューリスティックするように実行されたり、少なくとも一部動作が他の順序に実行されたり、省略されたり、又は他の動作が追加されることができる。
１１０、３１０ 端末
１２０、２１０、３３０、１６３０、２８３０ ＳＳＰ
１３０ 第１端末
１４０、１５０ テレコムバンドル
１７０ ペイメントバンドル
１８０ 電子ＩＤカードバンドル
２２０ プライマリープラットホーム
２２２ 下位階層オペレーティングシステム
２３０、２４０、３３５、３３７、３３９ セカンダリープラットホームバンドル
２３２ 上位階層オペレーティングシステム
２３４ アプリケーション
２５０ プライマリープラットホームインターフェース
３１２ ＬＢＡ
３３１ プライマリープラットホーム
３３３ セカンダリープラットホームバンドルローダー
３４１、３４２、３４３ バンドルファミリ管理者識別子
１６１０、２８１０、２９１０ 送受信部
１６２０、２８２０、２９２０ プロセッサ

Claims (15)

  1. 第１端末の動作方法であって、
    第２端末で、バンドルを送信する段階と、
    前記第２端末から、第２端末のバンドル状態情報を含んで生成される第１証明書を受信する段階と、
    前記受信した第１証明書を検証する段階と、
    前記第１証明書を検証した後、第１端末のバンドル状態情報を含む第２証明書を生成する段階と、
    前記第２端末で前記第２証明書を送信する段階と、を有することを特徴とする第１端末の動作方法。
  2. 前記第１端末のバンドル状態情報は、前記第１端末のバンドル状態が「ＤＥＬＥＴＥ」、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」、「ＳＵＳＰＥＮＳＩＯＮ」の内の少なくとも一つに設定されることを含み、
    前記第１端末のバンドル状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定された場合、前記第２端末から第２端末のバンドル状態変更に対する情報を含んで生成された第３証明書を受信する段階と、
    前記受信した第３証明書を検証する段階と、
    前記第３証明書を検証した後、前記第１端末のバンドルを削除（ＤＥＬＥＴＥ）する段階と、をさらに有することを特徴とする請求項１に記載の第１端末の動作方法。
  3. 前記第２端末によって、前記第１証明書及び前記第２証明書の検証結果に対する情報を含む第４証明書が生成され、
    前記第４証明書がサーバーに送信され、
    前記サーバーによって、前記第４証明書は検証されることを特徴とする請求項１に記載の第１端末の動作方法。
  4. サーバーによって、前記サーバーとの認証結果を含む第５証明書が生成され、
    前記第５証明書は、前記第２端末に送信され、
    前記第２端末によって、前記第５証明書は検証されることを特徴とする請求項１に記載の第１端末の動作方法。
  5. 第２端末の動作方法であって、
    第１端末から、バンドルを受信する段階と、
    前記バンドルを設置する段階と、
    第２端末のバンドル状態情報を含む第１証明書を生成する段階と、
    前記第１端末に、前記第１証明書を送信する段階と、
    前記第１端末から、第１端末のバンドル状態情報を含んで生成される第２証明書を受信する段階と、
    前記受信した第２証明書を検証する段階と、
    前記第２証明書を検証した後、第２端末のバンドル状態設定情報を変更する段階と、を有することを特徴とする第２端末の動作方法。
  6. 前記第２端末のバンドル状態設定情報を変更する段階は、前記第２端末のバンドル状態を活性化（ｅｎａｂｌｅ）、駆動状態（Ａｃｔｉｖｅ）及び非活性化（Ｄｉｓａｂｌｅｄ）の内の少なくとも一つに変更する段階と、
    前記第１端末のバンドル状態情報は、前記第１端末のバンドル状態が「ＤＥＬＥＴＥ」、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」、「ＳＵＳＰＥＮＳＩＯＮ」の内の少なくとも一つに設定され、前記第１端末のバンドル状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定された場合、第２端末のバンドル状態変更に対する情報を含む第３証明書を生成する段階と、
    前記第１端末で、前記第３証明書を送信する段階と、をさらに有することを特徴とする請求項５に記載の第２端末の動作方法。
  7. 前記第１証明書及び前記第２証明書の検証結果に対する情報を含む第４証明書を生成する段階と、
    サーバーに、前記第４証明書を送信する段階をさらに有することを特徴とする請求項５に記載の第２端末の動作方法。
  8. サーバーから、前記サーバーとの認証結果を含んで生成された第５証明書を受信する段階と、
    前記受信した第５証明書を検証する段階と、
    前記第５証明書を検証した後、第２端末のバンドル状態設定情報を変更する段階と、をさらに有することを特徴とする請求項５に記載の第２端末の動作方法。
  9. 第１端末であって、
    少なくとも一つの信号を送受信ができる送受信部と、
    前記送受信部と結合された制御部と、を有し、
    前記制御部は、第２端末で、バンドルを送信し、前記第２端末から、第２端末のバンドル状態情報を含んで生成される第１証明書を受信し、前記受信した第１証明書を検証し、前記第１証明書を検証した後、第１端末のバンドル状態情報を含む第２証明書を生成し、前記第２端末で前記第２証明書を送信するように構成されることを特徴とする第１端末。
  10. 前記制御部は、前記第１端末のバンドル状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定された場合、前記第２端末から第２端末のバンドル状態変更に対する情報を含んで生成される第３証明書を受信し、
    前記受信した第３証明書を検証し、
    前記第３証明書を検証した後、前記第１端末のバンドルを削除（ＤＥＬＥＴＥ）するようにさらに構成され、
    前記第１端末のバンドル状態情報は、前記第１端末のバンドル状態が「ＤＥＬＥＴＥ」、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」、「ＳＵＳＰＥＮＳＩＯＮ」の内の少なくとも一つに設定されることを含むことを特徴とする請求項９に記載の第１端末。
  11. 前記第２端末によって、前記第１証明書及び前記第２証明書の検証結果に対する情報を含む第４証明書が生成され、
    前記第４証明書がサーバーに送信され、
    前記サーバーによって、前記第４証明書は検証されることを特徴とする請求項９に記載の第１端末。
  12. サーバーによって、前記サーバーとの認証結果を含む第５証明書が生成され、
    前記第５証明書は、前記第２端末に送信され、
    前記第２端末によって、前記第５証明書は、検証されることを特徴とする請求項９に記載の第１端末。
  13. 第２端末であって、
    少なくとも一つの信号を送受信ができる送受信部と、
    前記送受信部と結合された制御部と、を有し、
    前記制御部は、第１端末から、バンドルを受信し、前記バンドルを設置し、第２端末のバンドル状態情報を含む第１証明書を生成し、前記第１端末に、前記第１証明書を送信し、前記第１端末から、第１端末のバンドル状態情報を含んで生成される第２証明書を受信し、前記受信された第２証明書を検証し、前記第２証明書を検証した後、第２端末のバンドル状態設定情報を変更するように構成されることを特徴とする第２端末。
  14. 前記制御部は、前記第２端末のバンドル状態を活性化（ｅｎａｂｌｅ）、駆動状態（Ａｃｔｉｖｅ）及び非活性化（Ｄｉｓａｂｌｅｄ）の内の少なくとも一つに変更するように構成され、
    前記第１端末のバンドル状態が「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」に設定された場合、第２端末のバンドル状態変更に対する情報を含む第３証明書を生成し、前記第１端末で前記第３証明書を送信するようにさらに構成され、
    前記第１端末のバンドル状態情報は、前記第１端末のバンドル状態が「ＤＥＬＥＴＥ」、「ＩＮ ＴＲＡＮＳＩＴＩＯＮ」、「ＳＵＳＰＥＮＳＩＯＮ」の内の少なくとも一つに設定されることを特徴とする請求項１３に記載の第２端末。
  15. 前記制御部は、前記第１証明書及び前記第２証明書の検証結果に対する情報を含む第４証明書を生成し、サーバーで、前記第４証明書を送信するようにさらに構成されることを特徴とする請求項１３に記載の第２端末。
JP2022517517A 2019-09-20 2020-09-21 機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置 Pending JP2022549182A (ja)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
KR20190116222 2019-09-20
KR10-2019-0116222 2019-09-20
KR10-2019-0140219 2019-11-05
KR20190140219 2019-11-05
KR10-2019-0150329 2019-11-21
KR20190150329 2019-11-21
KR20190150466 2019-11-21
KR10-2019-0150466 2019-11-21
KR10-2020-0120292 2020-09-18
KR1020200120292A KR20210034522A (ko) 2019-09-20 2020-09-18 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치
PCT/KR2020/012728 WO2021054808A1 (ko) 2019-09-20 2020-09-21 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치

Publications (1)

Publication Number Publication Date
JP2022549182A true JP2022549182A (ja) 2022-11-24

Family

ID=74883499

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022517517A Pending JP2022549182A (ja) 2019-09-20 2020-09-21 機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置

Country Status (5)

Country Link
US (1) US20220385670A1 (ja)
EP (1) EP4017047A4 (ja)
JP (1) JP2022549182A (ja)
CN (1) CN114731505A (ja)
WO (1) WO2021054808A1 (ja)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013048084A2 (ko) * 2011-09-28 2013-04-04 주식회사 케이티 프로파일 관리 방법, 내장 ｕｉｃｃ 및 내장 ｕｉｃｃ 탑재 기기
FR2999319B1 (fr) * 2012-12-10 2015-01-09 Oberthur Technologies Procede et systeme de gestion d'un element securise integre ese
KR102193619B1 (ko) * 2013-07-01 2020-12-21 삼성전자주식회사 전자 디바이스에서 어플리케이션의 상태정보를 업데이트하는 방법, 관리하는 방법 및 그 전자 디바이스
KR102329824B1 (ko) * 2014-09-16 2021-11-23 삼성전자주식회사 네트워크 서비스를 제공하는 방법과 전자 장치
KR102293683B1 (ko) * 2017-02-13 2021-08-26 삼성전자 주식회사 eSIM 접근 제어 방법 및 장치
KR102458790B1 (ko) * 2017-09-07 2022-10-25 삼성전자 주식회사 무선 통신 시스템에서 디바이스들의 프로파일 이동을 지원하는 방법 및 장치

Also Published As

Publication number Publication date
US20220385670A1 (en) 2022-12-01
WO2021054808A1 (ko) 2021-03-25
CN114731505A (zh) 2022-07-08
EP4017047A4 (en) 2022-10-19
EP4017047A1 (en) 2022-06-22

Similar Documents

Publication Publication Date Title
CN112956155B (zh) Ssp设备和服务器协商数字证书的装置和方法
CN113273155B (zh) 用于管理智能安全平台的绑定的方法和装置
US20220398080A1 (en) METHOD FOR INTEROPERATING BETWEEN BUNDLE DOWNLOAD PROCESS AND eSIM PROFILE DOWNLOAD PROCESS BY SSP TERMINAL
CN113785532B (zh) 用于管理和验证证书的方法和装置
US11963261B2 (en) Method and apparatus for recovering profile in case of device change failure
US20240015508A1 (en) Method and device for remote management and verification of remote management authority
KR102658615B1 (ko) SSP 단말의 번들 다운로드 과정과 eSIM 프로파일 다운로드 과정 호환 연동 방법
JP2022549182A (ja) 機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置
CN115362700A (zh) 用于管理智能安全平台的事件的方法和装置
KR20210034522A (ko) 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치
US11950320B2 (en) Apparatus and methods for linkage of or profile transfer between devices
US20220377081A1 (en) Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer
KR20210116169A (ko) 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치
KR20210034475A (ko) 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치
US20220278985A1 (en) Method and device for transferring bundle between devices
KR20210020725A (ko) 기기 간 번들 이동 방법 및 장치
KR20210020770A (ko) 기기 간 번들 이동 방법 및 장치
KR102637120B1 (ko) eUICC 프로파일 설치 권한을 관리하는 방법 및 장치
US20220095095A1 (en) Method and apparatus for moving profiles with different versions during device change
KR20200130044A (ko) 인증서 관리 및 검증 방법 및 장치
KR20210123191A (ko) 스마트 보안 매체를 위한 이벤트 관리 방법 및 장치
KR20210110145A (ko) 원격 관리 및 원격 관리 권한 검증 방법 및 장치
KR20200127812A (ko) 번들 정보를 제공하는 방법 및 장치

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230726