CN115280815A - 在设备之间在线移动捆绑包或配置文件的方法和设备 - Google Patents
在设备之间在线移动捆绑包或配置文件的方法和设备 Download PDFInfo
- Publication number
- CN115280815A CN115280815A CN202180020406.4A CN202180020406A CN115280815A CN 115280815 A CN115280815 A CN 115280815A CN 202180020406 A CN202180020406 A CN 202180020406A CN 115280815 A CN115280815 A CN 115280815A
- Authority
- CN
- China
- Prior art keywords
- terminal
- bundle
- information
- profile
- management server
- 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
Links
- 238000000034 method Methods 0.000 title claims description 210
- 238000004891 communication Methods 0.000 claims abstract description 118
- 230000005540 biological transmission Effects 0.000 claims abstract description 93
- 238000007726 management method Methods 0.000 claims description 435
- 230000008569 process Effects 0.000 claims description 113
- 230000004044 response Effects 0.000 claims description 25
- 238000012546 transfer Methods 0.000 description 83
- 238000010586 diagram Methods 0.000 description 51
- 101150038317 SSP1 gene Proteins 0.000 description 50
- 101100125020 Schizosaccharomyces pombe (strain 972 / ATCC 24843) pss1 gene Proteins 0.000 description 50
- 101100018019 Schizosaccharomyces pombe (strain 972 / ATCC 24843) ssc1 gene Proteins 0.000 description 50
- 101100532584 Clostridium perfringens (strain 13 / Type A) sspC1 gene Proteins 0.000 description 42
- 230000006870 function Effects 0.000 description 40
- 238000002360 preparation method Methods 0.000 description 26
- 230000004913 activation Effects 0.000 description 24
- 238000005516 engineering process Methods 0.000 description 22
- 101100256651 Homo sapiens SENP6 gene Proteins 0.000 description 18
- 102100023713 Sentrin-specific protease 6 Human genes 0.000 description 18
- 101100014396 Staphylococcus saprophyticus subsp. saprophyticus (strain ATCC 15305 / DSM 20229 / NCIMB 8711 / NCTC 7292 / S-41) gcvPB gene Proteins 0.000 description 18
- 238000003860 storage Methods 0.000 description 15
- 101100095550 Homo sapiens SENP7 gene Proteins 0.000 description 14
- 101150098865 SSP2 gene Proteins 0.000 description 14
- 102100031406 Sentrin-specific protease 7 Human genes 0.000 description 14
- 238000012545 processing Methods 0.000 description 13
- 230000008859 change Effects 0.000 description 10
- 238000012795 verification Methods 0.000 description 9
- 238000004590 computer program Methods 0.000 description 8
- 238000010295 mobile communication Methods 0.000 description 7
- 238000009434 installation Methods 0.000 description 6
- 239000003607 modifier Substances 0.000 description 5
- 238000012797 qualification Methods 0.000 description 5
- CPLXHLVBOLITMK-UHFFFAOYSA-N Magnesium oxide Chemical compound [Mg]=O CPLXHLVBOLITMK-UHFFFAOYSA-N 0.000 description 4
- 101100257820 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) ssp-1 gene Proteins 0.000 description 4
- 230000014509 gene expression Effects 0.000 description 4
- 230000000977 initiatory effect Effects 0.000 description 4
- 238000012005 ligant binding assay Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 241000760358 Enodes Species 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 230000007774 longterm Effects 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000002124 flame ionisation detection Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 241000282412 Homo Species 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000000060 site-specific infrared dichroism spectroscopy Methods 0.000 description 1
- 208000037918 transfusion-transmitted disease Diseases 0.000 description 1
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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
用于在无线通信***中向第二终端提供捆绑包的第一终端，其包括收发器以及至少一个处理器，处理器配置成：获得关于要传输到所述第二终端的捆绑包的信息；基于捆绑包传送配置信息包括指示第一终端是否能够向另一个终端传输捆绑包的指示符，确定第一终端能够向第二终端传输捆绑包；生成包括要传输到第二终端的捆绑包的标识信息的捆绑包传输代码；将生成的捆绑包传输代码传输到第二终端；将要传输到第二终端的捆绑包上传到捆绑包管理服务器。
Description
技术领域
本公开涉及一种智能安全介质，并且更具体地，涉及一种用于在智能安全媒体之间在线地传送捆绑包或配置文件的方法和装置。
背景技术
为了满足在***(4G)通信***的商业化之后对于无线数据业务的需求的增加，已经做出了相当大的努力来开发第五代准(5G)通信***或5G通信***。这是为什么“5G通信***”或“准5G通信***”被称为“超4G网络通信***”或“后长期演进(LTE)***”的一个原因。为了实现高数据速率，正在开发5G通信***以在超高频频段(毫米波(mmwave))中实现，例如60GHz的频段。为了减小无线电波的传播路径损耗和增加无线电波在毫米波频段中的传播距离，在5G通信***中，正在讨论诸如波束成形、大规模多输入多输出(MIMO)、全维度MIMO(FD-MIMO)、阵列天线、模拟波束成形和大规模天线等技术。为了改进用于5G通信***的***网络，已经开发了各种技术，例如，演进小小区(cell)、高级小小区、云无线电接入网络(Cloud-RAN)、超密集网络、设备到设备通信(D2D)、无线回程、移动网络、协作通信、协作多点(CoMP)和接收干扰消除。此外，对于5G通信***，已经开发了其它技术，例如作为高级编码调制(ACM)方案的混合频移键控(FSK)和正交幅度调制(QAM)(FQAM)以及滑动窗口叠加编码(SWSC)，以及例如作为高级接入方案的滤波器组多载波(FBMC)、非正交多址接入(NOMA)和稀疏码多址接入(SCMA)。
因特网已经从其中人类创建和消费信息的基于人类的连接网络发展到物联网(IoT)，在IoT中，诸如对象的分布式组件彼此交换信息以处理信息。万联网(IoE)技术是IoT技术和大数据处理技术通过利用云服务器进行连接而结合在一起的一种技术。为了实现IoT，需要诸如感测技术、有线/无线通信和网络基础设施、服务接口技术和安全技术的技术元素，因此最近已经研究了用于对象间连接的技术，诸如传感器网络、机器到机器(M2M)通信或机器类型通信(MTC)。在IoT环境中，可以提供智能因特网技术(IT)服务，其收集和分析由被连接对象生成的数据并在人类生活中创建新的值。通过现有的信息技术(IT)和各种工业应用之间的融合和组合，IoT可以应用于各种领域，例如，智能家居、智能建筑物、智能城市、智能汽车或联网汽车、智能电网、健康护理、智能家电和高级医疗服务。
已经进行了各种尝试来将5G通信***应用到IoT网络。例如，诸如传感器网络、M2M通信或MTC的技术由诸如波束成形、MIMO或阵列天线的5G通信技术来实现。云无线电接入网络(RAN)作为大数据处理技术的应用也可以视作5G技术和IoT技术融合的示例。
如上所述，由于移动通信***的发展，能够提供各种服务，因此，需要用于有效地提供这种服务的方法。例如，需要一种在两个设备之间安全有效地在线地传送捆绑包(bundle)或配置文件(或配置文件包)的方法。
发明内容
技术问题
提供了一种当在两个电子设备中所包括的安全模块之间在线传送捆绑包或配置文件时能够实现可靠的捆绑包或配置文件在线传送服务的装置和方法。
问题的解决方案
根据本公开的实施例，用于在无线通信***中向第二终端提供捆绑包的第一终端：基于捆绑包传送配置信息包括指示第一终端是否能够向另一个终端传输捆绑包的指示符，获得关于要传输到第二终端的捆绑包的信息；确定出第一终端能够向第二终端传输捆绑包；生成包括要传输到第二终端的捆绑包的标识信息的捆绑包传输代码；将生成的捆绑包传输代码传输到第二终端；以及将要传输到第二终端的捆绑包上传至捆绑包管理服务器，其中，要传输到第二终端的捆绑包可通过经由捆绑包管理服务器被传输到第二终端而安装在第二终端中。
本公开的有益效果
根据本公开的各种实施例，安装在一个设备中的捆绑包或配置文件可以通过安全和有效的方法在线传输到另一个设备或者安装在另一个设备中。
附图说明
图1示出根据本公开的实施例的智能安全平台(SSP)的示意图。
图2示出根据本公开的实施例的SSP的内部结构的示意图。
图3是示出根据本公开的实施例的终端中的组件的示例的图，其中终端使用所述组件将捆绑包下载到SSP并且安装到SSP中。
图4是示出根据本公开的实施例的两个终端和服务器通过其相互操作使得捆绑包从一个终端在线传输到另一个终端的方法的示例的图。
图5是示意性示出根据本公开的实施例的用于从一个终端向另一个终端在线传输捆绑包的过程的示例的示图。
图6是示出根据本公开的实施例的图5中提出的过程之中的、准备传输捆绑包的过程的详细过程的图。
图7是示出根据本公开的实施例的图5中提出的过程之中的、要传输捆绑包的终端将要传输的捆绑包上传到服务器的过程的图。
图8是示出根据本公开的实施例的图5中提出的过程之中的、用于将上传到服务器的捆绑包下载到要接收该捆绑包的终端的过程的图。
图9是示意性示出根据本公开的实施例的用于从一个终端向另一个终端在线传输捆绑包的过程的另一个示例的示图。
图10是示出根据本公开的实施例的图9中提出的过程之中的、准备传输捆绑包的过程的详细过程的图。
图11是示出根据本公开的实施例的图9中提出的过程之中的、接收捆绑包的终端通过与服务器通信来接收许可的过程的图。
图12是示出根据本公开的实施例的图9中提出的过程之中的、要传输捆绑包的终端将要传输的捆绑包上传到服务器的过程的图。
图13是示出根据本公开的实施例的图9中提出的过程之中的、用于将被上传到服务器的捆绑包下载到要接收捆绑包的终端的过程的图。
图14是示出根据本公开的一些实施例的其上安装有SSP的终端的配置的图。
图15是示出根据本公开的一些实施例的捆绑包管理服务器的配置的图。
图16是示出根据本公开的实施例的两个终端和服务器相互操作以使配置文件从一个终端在线传输到另一个终端的方法的示例的图。
图17是示出根据本公开的实施例的将配置文件从一个终端在线传输到另一个终端的过程的前半个过程的图。
图18是示出根据本公开的实施例的将配置文件从一个终端在线传输到另一个终端的过程的后半个过程的图。
图19是示出根据本公开的实施例的其上安装有嵌入式通用集成电路卡(eUICC)的终端的配置的图。
图20是示出根据本公开的实施例的远程订户身份模块(SIM)供应(RSP)服务器的配置的图。
图21是示意性示出根据本公开的实施例的用于将配置文件从一个终端在线传输到另一个终端的过程的另一个示例的图。
图22是示出根据本公开的实施例的准备传输配置文件的过程的详细过程的图。
图23是示出根据本公开的实施例的第二终端请求RSP服务器传输配置文件的过程的图。
图24是示出根据本公开的实施例的第一终端将要传输到第二终端的配置文件上传到RSP服务器的过程的图。
图25是示出根据本公开的实施例的第二终端通过其下载从RSP服务器上传的准备好的配置文件并安装准备好的配置文件的过程的图。
具体实施方式
根据本公开的实施例，用于在无线通信***中向第二终端提供捆绑包的第一终端包括收发器和至少一个处理器。所述至少一个处理器可配置成：基于捆绑包传送配置信息包括指示所述第一终端是否能够向另一个终端传输捆绑包的指示符，获得关于要传输到所述第二终端的捆绑包的信息；确定所述第一终端能够向所述第二终端传输所述捆绑包；生成包括要传输到所述第二终端的所述捆绑包的标识信息的捆绑包传输代码；将所生成的捆绑包传输代码传输到所述第二终端；以及将要传输到第二终端的捆绑包上传到捆绑包管理服务器，其中，要传输到第二终端的捆绑包通过经由捆绑包管理服务器传输到第二终端而安装在第二终端中。
捆绑包传送配置信息可以包括以下至少之一：关于在第一终端和第二终端之间的捆绑包传输所需的条件的信息、或者指示是否允许通过捆绑包管理服务器在第一终端和第二终端之间进行捆绑包传输的指示符。
捆绑包的标识信息可以包括要传输到第二终端的捆绑包的身份(ID)、捆绑包族ID(Fid)或捆绑包族托管对象ID(Oid)中的至少之一，并且捆绑包传输代码还可以包括以下至少之一：与要传输到第二终端的捆绑包的属性有关的信息、捆绑包管理服务器的地址、用于将第一终端连接到第二终端的信息、或第一终端支持的加密算法信息。
至少一个处理器还可配置成：向所述捆绑包管理服务器传输捆绑包传送认证信息，所述捆绑包传送认证信息包括所述第一终端的第一智能安全平台(SSP)信息、用于所述第一终端与所述捆绑包管理服务器之间的认证的证书协商信息、或所述第一SSP的版本信息中的至少一者；基于所传输的捆绑包传送认证信息从所述捆绑包管理服务器接收服务器认证信息；基于所接收的服务器认证信息，将第一终端认证信息和要传输到第二终端的捆绑包的捆绑包ID传输到捆绑包管理服务器；响应于捆绑包管理服务器基于第一终端认证信息将第一终端确定为能够将要传输到第二终端的捆绑包传输到第二终端的终端，从捆绑包管理服务器接收捆绑包请求消息；以及基于所接收的捆绑包请求消息，将要传输到第二终端的捆绑包上传到捆绑包管理服务器。
根据本公开的另一个实施例，用于在无线通信***中从第一终端接收捆绑包的第二终端包括收发器和至少一个处理器。所述至少一个处理器可配置成：从所述第一终端接收包含将被所述第二终端接收的捆绑包的标识信息的捆绑包传输代码；基于所接收的捆绑包传输代码与所述捆绑包管理服务器执行认证过程；响应于所述捆绑包管理服务器成功执行了所述认证过程，将待接收捆绑包的信息传输到所述捆绑包管理服务器；以及响应于捆绑包管理服务器确定出被第二终端接收的捆绑包对应于待接收捆绑包，接收第一捆绑包和第一捆绑包信息。
要被第二终端接收的捆绑包的标识信息可以包括要被第二终端接收的捆绑包的身份(ID)、捆绑包族ID(Fid)或捆绑包族托管对象ID(Oid)中的至少之一，并且捆绑包传输代码可以进一步包括以下至少之一：与要被第二终端接收的捆绑包的属性相关的信息、所述捆绑包管理服务器的地址、用于连接所述第一终端和所述第二终端的信息、或所述第一终端支持的加密算法信息。
所述至少一个处理器还可配置成：向所述捆绑包管理服务器传输包括用于所述捆绑包管理服务器与所述第二终端的第二SSP之间的认证的证书协商信息的第二智能安全平台(SSP)信息；从所述捆绑包管理服务器接收由所述捆绑包管理服务器基于所述第二SSP信息生成的服务器认证信息；基于所述服务器认证信息，向所述捆绑包管理服务器传输包括所述第二SSP的ID和待接收捆绑包的ID的第二终端信息；以及响应于所述捆绑包管理服务器确定出从所述第一终端接收的、所述第二SSP的ID和要被所述第二终端接收的捆绑包的标识信息分别对应于从所述第二终端接收的所述第二SSP的ID和待接收捆绑包的ID，从所述捆绑包管理服务器接收所述第一捆绑包和所述第一捆绑包信息。
捆绑包管理服务器可以基于捆绑包传送配置信息将第二终端确定为能够从另一个终端接收捆绑包的终端，并且捆绑包管理服务器可以将待接收捆绑包确定为能够安装在第二终端中的捆绑包。
根据本公开的另一个实施例，用于在无线通信***中向第二终端提供配置文件的第一终端包括收发器和至少一个处理器。所述至少一个处理器被配置成：从安装在所述第一终端中的配置文件之中确定要传输到所述第二终端的第一配置文件；基于包括所述第二终端的嵌入式通用集成电路卡(eUICC)的身份(ID)的配置文件传送配置信息，确定出所述第一配置文件能够通过配置文件管理服务器被传输到所述第二终端；响应于验证了配置文件管理服务器，向所述配置文件管理服务器传输包括第一终端的第一配置文件ID和eUICCID的第一终端认证信息；响应于配置文件管理服务器通过使用第一终端的第一配置文件ID和eUICC ID验证了第一终端正在使用第一配置文件，从配置文件管理服务器接收配置文件请求消息；以及基于配置文件请求消息，向配置文件管理服务器传输第一配置文件的配置文件包。
所述至少一个处理器还可配置成：从所述第二终端接收包括所述eUICC的ID和所述第二终端的eUICC信息的所述配置文件传送配置信息，其中所述第二终端的eUICC信息可包括用于确定要从所述第一终端接收的配置文件是否能够在所述第二终端的eUICC中正常安装和操作的信息。
所述至少一个处理器还可配置成：将所述第一终端的所述eUICC信息传输到所述配置文件管理服务器；接收由所述配置文件管理服务器基于所述第一终端的所述eUICC信息而生成的、所述配置文件管理服务器的服务器认证信息；以及基于所述第一终端的所述eUICC信息和所述配置文件管理服务器的所述服务器认证信息来验证所述配置文件管理服务器。
配置文件包可以包括以下至少之一：关于第一配置文件的信息、第一终端用来对第一配置文件进行编码的第一加密密钥生成信息、第一终端的第一公开密钥、配置文件管理服务器用来对第一配置文件进行编码的第二加密密钥生成信息、或配置文件管理服务器的第二公开密钥。
根据本公开的另一个实施例，用于在无线通信***中从第一终端接收配置文件的第二终端包括收发器和至少一个处理器。所述至少一个处理器可配置成：将包括所述第二终端的嵌入式通用集成电路卡(eUICC)的身份(ID)的配置文件传送配置信息传输到所述第一终端；将所述第二终端的eUICC信息传输到配置文件管理服务器；基于所述第二终端的eUICC信息接收所述配置文件管理服务器的认证信息；响应于基于配置文件管理服务器的认证信息验证了配置文件管理服务器，将包括要接收的配置文件的ID和第二终端的eUICCID的第二终端认证信息传输到所述配置文件管理服务器；以及基于第二终端认证信息从配置文件管理服务器接收用于第一配置文件的配置文件包。
第二终端认证信息可以包括用于确定要从第一终端接收的配置文件是否能够在第二终端的eUICC中正常安装和操作的信息。
配置文件包可以包括以下至少之一：关于第一配置文件的信息、由第一终端用来对第一配置文件进行编码的第一加密密钥生成信息、第一终端的第一公开密钥、由配置文件管理服务器用来对第一配置文件进行编码的第二加密密钥生成信息、或配置文件管理服务器的第二公开密钥，并且至少一个处理器还可以被配置成：当所接收的用于第一配置文件的配置文件包由第一终端编码时，利用所述第一终端的第一公开密钥和所述第二终端的私密密钥对所述第一配置文件的所述配置文件包进行解码；当所述配置文件管理服务器对所接收的所述第一配置文件的所述配置文件包进行编码时，利用所述配置文件管理服务器的第二公开密钥和所述第二终端的私密密钥对所述第一配置文件的所述配置文件包进行解码。
本公开的实施例
在下文中，将参考附图描述本公开的实施例。
在描述实施例时，将省略对本公开所属技术领域中熟知且不直接与本公开相关的技术内容的描述。通过省略不必要的描述，可以更清楚地传达本公开的要点而不会使主题模糊。
出于相同的原因，为了清楚起见，在附图中可能夸大、省略或示意性地示出组件。此外，每个组件的尺寸不完全反映实际尺寸。在附图中，相同的附图标记表示相同的元件。
通过参考以下实施例的详细描述和附图，可以更容易地理解本公开的优点和特征以及实现本公开的优点和特征的方法。在这方面，本公开的实施例可以具有不同的形式，而不应被解释为限于本文所述的描述。相反，提供这些实施例使得本公开将是透彻和完整的，并且将充分地将本公开的当前实施例的构思传达给本领域普通技术人员，并且本公开将仅由所附权利要求来限定。在整个说明书中，相同的附图标记表示相同的元件。
这里，将理解，流程图中的框的组合或者过程流程图可以由计算机程序指令来执行。因为这些计算机程序指令可以被加载到通用计算机、专用计算机或其它可编程数据处理装置的处理器中，所以由计算机或其它可编程数据处理装置的处理器执行的指令创建用于执行流程图框中所描述的功能的单元。计算机程序指令可以存储在能够指导计算机或其它可编程数据处理装置以特定方式实现功能的计算机可执行或计算机可读存储器中，并且因此存储在计算机可执行或计算机可读存储器中的指令也能够生成包含用于执行流程图框中所描述的功能的指令单元的制造项目。计算机程序指令还可以被加载到计算机或其它可编程数据处理装置中，并且因此，当在计算机或其它可编程数据处理装置中执行一系列操作时用于通过生成计算机可执行过程来操作计算机或其它可编程数据处理装置的指令可以提供用于执行流程图框中所描述的功能的操作。
此外，每个框可以表示包括用于执行指定逻辑功能的一个或更多可执行指令的模块、段或代码的一部分。还应当注意，在一些可替代的实现方式中，框中所提到的功能可以偏离顺序地发生。例如，根据所涉及的功能，连续示出的两个框实际上可以基本上同时执行，或者这些框有时可以以相反的顺序执行。
在本文中，实施例中所使用的术语“单元”意指软件组件或者诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC)的硬件组件，并且执行特定功能。然而，术语“单元”不限于软件或硬件。“单元”可以形成为存在于可寻址存储介质中，或者可以形成为操作一个或更多处理器。因此，例如，术语“单元”可以指代这样的组件，诸如软件组件、面向对象的软件组件、类组件和任务组件，并且可以包括过程、功能、属性、过程、子例程、程序代码段、驱动器、固件、微代码、电路、数据、数据库、数据结构、表、阵列或变量。由组件和“单元”提供的功能可以与较少数量的组件和“单元”相关联，或者可以被划分为附加的组件和“单元”。此外，组件和“单元”可以被实施成在设备或安全多媒体卡中再现一个或更多中央处理单元(CPU)。
在下文中，基站(base station)是向终端分配资源的实体，并且可以是gNode B(gNB)、eNode B(eNB)、Node B(NB)、基站(BS)、无线电接入单元、BS控制器或网络上的节点中的至少之一。终端的示例可以包括：能够执行通信功能的用户设备(UE)、移动台(MS)、蜂窝电话、智能电话、计算机和多媒体***。本公开不限于上述实施例。在下文中，将描述一种由终端在无线通信***中从基站接收广播信息的技术。本公开涉及一种用于将第五代(5G)通信***与物联网(IoT)技术融合的通信技术和***，其中该5G通信***用于支持比***(4G)***更高的数据速率。本公开可应用于基于5G通信技术和IoT相关技术的智能服务(例如，智能家居、智能建筑物、智能城市、智能汽车或联网汽车、健康护理、数字教育、零售业务以及安保和安全相关服务)。
在下文中，为了便于描述，示例了指示广播信息的术语、指示控制信息的术语、与通信覆盖范围有关的术语、指示状态改变的术语(例如，事件)、指示网络实体的术语、指示消息的术语、以及指示装置的组件的术语。因此，在本公开中使用的术语不受限制，并且可以使用具有相同技术含义的其它术语。
在下文中，为了描述的方便，可以使用由第三代合作伙伴计划长期演进(3GPPLTE)标准定义的一些术语和名称。然而，本公开不限于这样的术语和名称，并且可以等同地应用于符合其它标准的***。
无线通信***已经从早期阶段中提供以语音为中心的服务的无线通信***朝向提供高速、高质量分组数据服务的宽带无线通信***发展，如3GPP的高速分组接入(HSPA)、长期演进(LTE或演进的通用陆地无线电接入(E-UTRA))、LTE高级(LTE-A)和LTE-Pro的通信标准、3GPP2的高速率分组数据(HRPD)和超移动宽带(UMB)、IEEE 802.16e等那样。
作为宽带无线通信***的代表性示例，LTE***在下行链路(DL)中采用正交频分复用(OFDM)方案，并且在上行链路(UL)中采用单载波频分多址(SC-FDMA)方案。UL是指终端(UE或MS)通过其向基站(BS)(例如，eNode B)传输数据或控制信号的无线电链路，并且DL是指BS通过其向终端传输数据或控制信号的无线电链路。如上所述的多址方案通常分配和操作用于携带不同用户的数据或控制信息的时频资源以防止时频资源彼此重叠，即，在它们之间建立正交性，从而识别每个用户的数据或控制信息。
作为LTE***之后的未来通信***，即5G通信***，必须能够自由地反映用户和服务提供方的各种需求，因此，需要支持满足各种需求的服务。为5G通信***考虑的服务包括增强型移动宽带(eMBB)、海量机器类型通信(mMTC)、超可靠低时延通信(以下称为URLLC)等。
根据一些实施例，eMBB旨在提供比LTE、LTE-A或LTE-Pro***所支持的数据速率更高的数据速率。例如，在5G通信***中，从一个BS的视角来看，eMBB应该能够在DL中提供20Gbps的峰值数据速率，在UL中提供10Gbps的峰值数据速率。同时，eMBB应该提供增加的用户感知数据速率。为了满足这种要求，可能需要对各种传输/接收技术的改进，包括进一步改进的多输入多输出(MIMO)传输技术。此外，eMBB可以通过在3到6GHz或者等于或大于6GHz(而不是当前LTE所使用的2GHz)的频段中使用宽于20MHz的频带带宽来满足5G通信***中所需的数据速率。
同时，mMTC被认为在5G通信***中支持诸如IoT的应用服务。为了有效地提供IoT，mMTC需要用于小区中的大规模终端的接入支持、终端的覆盖范围增强、改进的电池时间以及终端的成本降低。IoT需要能够支持小区中的大量终端(例如，1,000,000个终端/km2)，因为它连接到各种传感器和各种设备以提供通信功能。此外，支持mMTC的终端更可能位于没有被小区覆盖的阴影区域中，例如由于服务的性质而位于建筑物的地下，因此，终端可能需要比由5G通信***提供的其它服务更宽的覆盖范围。支持mMTC的终端应该被配置成便宜的终端，并且由于很难频繁地替换终端的电池，因此需要非常长的电池寿命。
最后，URLLC(其是用于关键任务目的的基于蜂窝的无线通信服务)需要提供具有超低时延(latency)和超高可靠性的通信，作为在用于机器人或机器、工业自动化、非管理飞行器、远程健康护理或紧急警报的远程控制中使用的服务。例如，支持URLLC的服务应该满足小于0.5毫秒的空中接口时延，并且同时需要10-5或更小的分组差错率。因此，对于支持URLLC的服务，需要5G通信***提供比用于其它服务的传输时间间隔(TTI)短的TTI，同时在频段中分配宽的资源。然而，mMTC、URLLC和eMBB是不同服务类型的示例，并且本公开所应用的服务类型不限于此。
在上述5G通信***中考虑的服务可以相互转换并基于一个架构(framework)来提供。换句话说，为了有效的资源管理和控制，服务可以经由一个***而被集成、控制和传输，而不是独立操作。
此外，在下文中，本公开的一个或更多实施例将被描述为LTE、LTE-A、LTE Pro或新无线电(NR)***的示例，但是本公开的一个或更多实施例也可以应用于具有类似技术背景或信道形式的其它通信***。此外，在没有显著偏离本公开的范围的情况下，本公开的实施例通过在本领域普通技术人员的判断下进行修改而可应用于其它通信***。
在本公开中，指示术语的修饰词，例如第一、第二等，可以用于在描述实施例的同时将这些术语彼此区分开。被修饰词(例如第一、第二等)修饰的术语可以指不同的对象。或者，被修饰词(例如第一、第二等)修饰的术语可以指同一对象。换句话说，例如第一、第二等修饰词可以用来从不同的角度指代相同的对象。例如，例如第一、第二等修饰词可用于在功能或操作方面区分相同的对象。例如，第一用户和第二用户可以指相同的用户。
此外，在本公开中，以智能安全平台(SSP)作为安全介质的示例来描述每个实施例，但是本公开的权利范围不受SSP的限制。例如，对于本领域的普通技术人员将显而易见的是，下面描述的各种实施例可以基本等同或类似地应用于执行与SSP基本相同或类似的功能的另一个安全介质。
为了帮助理解本公开，提供了在以下描述中使用的特定术语，并且在本公开的技术构思的范围内，可以将所述特定术语改变为其它形式。
安全元件(SE)表示包括这样的单个芯片的安全模块，该单个芯片能够存储安全信息(例如，移动通信网络接入密钥、用户标识信息(诸如身份证/护照)、***信息、或加密密钥)并且利用所存储的安全信息来加载和操作控制模块(例如，网络接入控制模块(诸如通用订户身份模块(USIM))、加密模块、或密钥生成模块)。SE可用于各种电子设备(例如，智能电话、平板计算机、可穿戴设备、车辆和IoT设备)中，并通过安全信息和控制模块提供安全服务(例如，接入移动通信网络、支付或用户认证)。
SE可以被分类为通用集成电路卡(UICC)、嵌入式安全元件(eSE)、或者其中集成有UICC和eSE的SSP，并且可以根据SE如何连接到或安装在电子设备中而被划分为可移除类型、嵌入式类型或集成到特定设备或片上***(SoC)的集成类型。
通用集成电路卡(UICC)是***到移动通信终端等中以被使用的智能卡，并且也称为UICC卡。UICC可以包括用于接入移动运营商的网络的接入控制模块。接入控制模块的示例包括通用订户身份模块(USIM)、订户身份模块(SIM)和因特网协议(IP)多媒体服务身份模块(ISIM)。包括USIM的UICC通常也可以被称为USIM卡。类似地，包括SIM的UICC通常也可以被称为SIM卡。同时，可以在制造UICC时安装SIM，或者可以在用户希望时将要使用的移动通信服务的SIM下载到UICC。此外，可以将多个SIM下载并安装在UICC中，并且可以选择并使用SIM中的至少之一。UICC可以固定或不固定到终端。通过固定到终端而使用的UICC被称为嵌入式UICC(eUICC)，并且特别地，嵌入在SoC中的UICC被称为集成UICC(iUICC)，所述SoC包括通信处理器、应用处理器或其中集成了这两个处理器的单个处理器结构。通常，eUICC和iUICC可以表示通过固定到终端而使用的UICC，并且包括远程下载至少一个SIM并且选择所下载的至少一个SIM中的一个的功能。在本公开中，包括远程下载至少一个SIM和选择SIM的功能的UICC统称为eUICC或iUICC。换句话说，在包括远程下载SIM和选择SIM的功能的UICC之中，固定或不固定到终端的UICC统称为eUICC或iUICC。
在本公开中，术语UICC和SIM可以互换地使用，并且术语eUICC和eSIM可以互换地使用。
eUICC标识符(ID)可以是嵌入在终端中的eUICC的固有ID，并且可以被称为EID。当授权配置文件(provisioning profile)预先安装在eUICC上时，eUICC ID可以是授权配置文件的配置文件ID。此外，在本公开的实施例中，当终端和eUICC芯片不分离时，eUICC ID可以是终端ID。eUICC ID可以指eUICC芯片的特定安全域。
嵌入式安全元件(eSE)表示通过固定到电子设备而使用的固定SE。eSE通常根据终端制造商的请求专门为制造商制造，并且可以制造成包括操作***和架构。eSE可以作为服务控制模块以applet形式被远程下载而被安装，并且所安装的服务控制模块可以被用于各种安全服务，诸如电子钱包、票务、电子护照和数字钥匙。在本公开中，可以作为服务控制模块安装的SE被远程下载，并且以附接到电子设备的单个芯片的形式被统称为eSE。
智能安全平台(SSP)表示能够整体支持UICC的功能和eSE的功能的单个芯片。SSP可以被划分为可移除类型(可移除SSP(rSSP))、嵌入式类型(嵌入式SSP(eSSP))或者嵌入在SoC中的集成类型(集成SSP(iSSP))。SSP可以包括一个主平台(PP)和在PP上操作的至少一个次平台捆绑包(SPB)，其中主平台可以包括硬件平台和低级操作***(LLOS)中的至少一个，并且次平台捆绑包可以包括高级操作***(HLOS)和在HLOS上驱动的应用中的至少一种。次平台捆绑包也被称为SPB或捆绑包。捆绑包可以通过由PP提供的主平台接口(PPI)访问PP的中央处理单元或存储器的资源，并通过资源在PP上驱动。通信应用(例如订户身份模块(SIM)、通用SIM(USIM)或IP多媒体SIM(ISIM))可以安装在捆绑包上，或者各种应用(例如电子钱包、票务、电子护照和数字钥匙)可以安装在捆绑包上。在本公开中，SSP也可以被称为智能安全介质。
根据所下载和安装的捆绑包，SSP可以用于上述UICC或eSE，并且当在单个SSP中安装并同时操作多个捆绑包时，SSP可以用于UICC和eSE。换句话说，当包括配置文件的捆绑包***作时，SSP可以被UICC用来接入移动运营商的网络。一个或更多配置文件(例如上述的eUICC或iUICC)可以被远程地下载到UICC捆绑包，并且可以选择一个或更多配置文件中的至少之一。此外，当包括服务控制模块(在该服务控制模块上在SSP上安装有能够提供诸如电子钱包、票务、电子护照或数字钥匙之类的服务的应用)的捆绑包进行操作时，SSP可以被用于eSE。多个服务控制模块可以在一个捆绑包中整体进行安装和操作，或者可以在独立的捆绑包中进行安装和操作。
可以通过使用空中(OTA，over-the-air)技术从外部捆绑包管理服务器(次平台捆绑包管理器(SPB管理器))将捆绑包下载到SSP并安装在SSP中，或者可以从另一个终端传输捆绑包并将捆绑包安装在SSP中。在本公开中，安装所下载的或所接收的捆绑包的方法可以同样地应用于能够***到终端中或从终端中移除的可移除SSP(rSSP)、安装在终端中的嵌入式SSP(eSSP)、以及安装在终端中的SoC中所包括的集成SSP(iSSP)。
SSP ID是嵌入在终端中的SSP的唯一ID，并且可以被称为sspID。此外，如在本公开的实施例中那样，当终端和SSP芯片彼此不分离时，SSP ID可以是终端ID。而且，SSP ID可以指SSP中的特定捆绑包ID(SPB ID)。详细地，SSP ID可以指用于管理SSP中的另一捆绑包的安装、启用、禁用和删除的次平台捆绑包加载器(SPBL)或管理捆绑包的捆绑包ID。而且，SSPID可以指SSP中的主平台标识符。SSP可以具有多个SSP ID，并且多个SSP ID可以是从唯一的单个SSP ID导出的值。
部件号ID是连接到嵌入在终端中的SSP的信息，并且可以用于推导出安装在SSP上的主平台的制造商以及主平台的模型信息。
通过使用SSP的主平台(PP)的资源来在PP上驱动次平台捆绑包(SPB)，并且例如，可以通过封装成存储在现有UICC以及用于操作该UICC的操作***(HLOS)中的软件、应用、文件***、认证密钥等的形式来获得UICC捆绑包。在本公开中，SPB可以被称为捆绑包。
在本公开中，捆绑包的状态可以如下。
[Enabled](已启用)
在本公开中，终端或外部服务器的已启用捆绑包的操作可以表示这样的操作：将SPB的状态改变为已启用状态，以便终端可以接收由捆绑包提供的服务(例如，通过移动运营商的通信服务、***支付服务或用户认证服务)。处于已启用状态的捆绑包可以被称为已启用捆绑包。处于已启用状态的捆绑包可以以编码状态存储在SSP内部或外部的存储空间中。
[Active](活动)
在本公开中，可以根据捆绑包外部输入(例如，用户输入、推送、终端中应用的请求、移动运营商的认证请求、或PP管理消息)或捆绑包中的操作(例如，定时器或轮询)将已激活捆绑包(activated bundle)改变为活动状态(active state)。处于活动状态的捆绑包可以表示处于这样一种状态的捆绑包：在该状态下，从SSP内部或外部的存储空间将捆绑包加载到SSP内部的驱动存储器中，通过使用SSP内部的安全CPU来处理安全信息，并且向终端提供安全服务。
[Disabled](已禁用)
在本公开中，终端或外部服务器的禁用捆绑包的操作可以表示这样的操作：将配置文件的状态改变为已禁用状态，使得终端不能接收由捆绑包提供的服务。处于已禁用状态的SPB可以被称为已禁用捆绑包。处于已禁用状态的捆绑包可以以编码状态存储在SSP内部或外部的存储空间中。
[Deleted](已删除)
在本公开中，终端或外部服务器的删除捆绑包的操作可以表示这样的操作：将捆绑包的状态改变为已删除状态或者删除捆绑包以及捆绑包的相关数据，使得终端或外部服务器不再能够激活、启用或禁用捆绑包。处于已删除状态的捆绑包可以被称为已删除捆绑包。
捆绑包图像或图像可以与捆绑包互换地使用或者用于指示特定捆绑包的数据对象，并且可以被称为捆绑包标签、长度、值(TLV)或捆绑包图像TLV。当通过使用加密参数对捆绑包图像进行编码时，可以将捆绑包图像称为受保护捆绑包图像(PBI)或受保护捆绑包图像TLV(PBI TLV)。当通过使用仅可由特定SSP解码的加密参数对捆绑包图像进行编码时，捆绑包图像可被称为绑定捆绑包图像(BBI)或绑定捆绑包图像TLV(BBI TLV)。捆绑包图像TLV可以是表示以TLV的形式配置捆绑包的信息的数据集。
捆绑包分隔符(bundle delimiter)可以被称为与捆绑包ID(SPB ID)、捆绑包族ID(SPB族ID)、捆绑包族托管对象ID(SPB族托管对象ID)、捆绑包匹配ID或事件ID进行匹配的因子。捆绑包ID(SPB ID)可以指示每个捆绑包的唯一ID。捆绑包族ID可以指示区分捆绑包的类型的ID(例如，用于接入移动通信网络的电信捆绑包)。在本公开中，捆绑包族ID可以被称为族ID、Fid或FID。捆绑包族托管对象ID可以指示区别管理捆绑包族ID的对象(例如，移动运营商、终端制造商或特定组织)的ID。在本公开中，捆绑包族托管对象ID可以被称为OID或Oid。捆绑包分隔符可以用作在捆绑包管理服务器或终端中对捆绑包进行索引的值。
捆绑包元数据指示引用或描述捆绑包的一组信息片段。捆绑包元数据可以包括上述捆绑包分隔符。此外，捆绑包元数据还可以包括关于捆绑包的属性、特性或配置的信息。捆绑包元数据也可以被称为元数据。
配置文件可以表示数据对象，例如存储在UICC中的应用、文件***或认证密钥值。
在本公开中，可以通过以可安装在UICC中的软件的形式对配置文件的内容进行打包来获得配置文件包。配置文件包可被称为配置文件TLV或配置文件包TLV。当通过使用加密参数对配置文件包进行编码时，配置文件包可被称为受保护配置文件包(PPP)或PPPTLV。当通过使用仅可由特定eUICC解码的加密参数来对配置文件包进行编码时，配置文件包可被称为绑定配置文件包(BPP)或BPP TLV。配置文件包TLV可以是表示以TLV的形式对配置文件进行配置的信息的数据集。
在本公开中，配置文件图像可以表示其中配置文件包被安装在UICC中的二进制数据。配置文件图像可以被称为配置文件TLV或配置文件图像TLV。当通过使用加密参数对配置文件图像进行编码时，配置文件图像可以被称为受保护配置文件图像(PPI)或受保护配置文件图像TLV(PPI TLV)。当通过使用仅可由特定eUICC解码的加密参数对配置文件图像进行编码时，配置文件图像可被称为绑定配置文件图像(BPI)或绑定配置文件图像TLV(BPITLV)。配置文件图像TLV可以是表示以TLV的形式对配置文件进行配置的信息的数据集。
在本公开中，配置文件的状态可以如下。
[Enabled](已启用)
在本公开中，终端的启用配置文件的操作可以表示这样的操作：将配置文件的状态改变为已启用状态，使得终端能够经由提供配置文件的移动运营商接收通信服务。处于已启用状态的配置文件可被称为已启用配置文件。
[Disabled](已禁用)
在本公开中，终端的禁用配置文件的操作可以表示这样的操作：将配置文件的状态改变为已禁用状态，使得终端不能经由提供配置文件的移动运营商接收通信服务。处于已禁用状态的配置文件可以被称为已禁用配置文件。
[Deleted](已删除)
在本公开中，终端的删除配置文件的操作可以表示这样的操作：将配置文件的状态改变为已删除状态，使得终端不再能够启用或禁用配置文件。处于已删除状态的配置文件可以被称为已删除配置文件。
在本公开中，终端启用、禁用或删除配置文件的操作可以表示这样的操作：其中，配置文件的状态不会立即改变为已启用状态、已禁用状态或已删除状态，而是首先被标记为待启用状态(to-be-enabled state)、待禁用状态(to-be-disabled state)或待删除状态(to-be-deleted state)，并且在终端或终端的UICC执行特定操作(例如，刷新或复位命令)之后，被改变为已启用状态(enabled state)、已禁用状态(disabled state)或已删除状态(deleted state)。将特定配置文件标记为待定状态(to-be-state)(例如，待启用状态、待禁用状态或待删除状态)的操作不必限于针对一个配置文件标记一个待定状态，并且可以将一个或更多配置文件标记为相同或不同的待定状态，可以将一个配置文件标记为一个或更多待定状态，或者可以将一个或更多配置文件标记为相同或不同的一个或更多待定状态。
此外，当终端将任意配置文件标记为一个或更多待定状态时，两个待定状态标记可以被集成到一个中。例如，当任意配置文件被标记为待禁用状态和待删除状态时，配置文件可以被整体地标记为待禁用和删除状态(to-be-disabled and deleted state)。
可以顺序地或同时地执行终端的为一个或更多配置文件标记待定状态的操作。此外，可以顺序地或同时地执行终端的标记一个或更多配置文件的待定状态然后实际上改变配置文件的状态的操作。
配置文件分隔符可被称为与配置文件ID、集成电路卡ID(ICCID)、匹配ID、事件ID、激活代码、激活代码令牌、命令码、命令码令牌、已签名命令码、未签名命令码或者ISD-P或配置文件域(PD)进行匹配的因子。配置文件ID可以指示每个配置文件的唯一ID。配置文件分隔符还可以包括能够对配置文件进行索引的配置文件提供服务器(SM-DP+)的地址。配置文件分隔符可以进一步包括配置文件提供服务器(SM-DP+)的签名。
捆绑包管理服务器可以包括根据服务提供方或另一捆绑包管理服务器的请求来生成捆绑包、对所生成的捆绑包进行编码、生成捆绑包远程管理指令、或者对所生成的捆绑包远程管理指令进行编码的功能。提供这种功能的捆绑包管理服务器可以被表示为以下至少之一：次平台捆绑包管理器(SPBM)、远程捆绑包管理器(RBM)、图像递送服务器(IDS)、订阅管理器数据准备(SM-DP)、订阅管理器数据准备增强(SM-DP+)、管理器捆绑包服务器、管理SM-DP+、捆绑包编码服务器、捆绑包生成服务器、捆绑包供应器(BP)、捆绑包提供方和捆绑包供应凭证(BPC)所有者。
在本公开中，捆绑包管理服务器可以执行以下功能：管理用于从SSP下载捆绑包、安装或更新捆绑包的证书和密钥的配置以及远程管理捆绑包的状态。提供这种功能的捆绑包管理服务器可以被表示为以下至少之一：次平台捆绑包管理器(SPBM)、远程捆绑包管理器(RBM)、图像递送服务器(IDS)、订阅管理器安全路由(SM-SR)、订阅管理器安全路由增强(SM-SR+)、eUICC配置文件管理者或配置文件管理凭证(PMC)所有者的卡外实体、以及eUICC管理器(EM)。
在本公开中，订阅中介服务器可以从一个或更多捆绑包管理服务器或订阅中介服务器接收登记事件请求(事件登记请求)。一个或更多订阅中介服务器可以组合使用，并且在这种情况下，第一订阅中介服务器不仅可以从捆绑包管理服务器接收事件登记请求，而且可以从第二订阅中介服务器接收事件登记请求。在本公开中，订阅中介服务器的功能可以被集成到捆绑包管理服务器中。提供这种功能的订阅中介服务器可以被表示为以下至少之一：次平台捆绑包管理器(SPBM)、远程捆绑包管理器(RBM)、次平台捆绑包发现服务器(SPBDS)、捆绑包发现服务器(BDS)、订阅管理器发现服务(SM-DS)、发现服务(DS)、根SM-DS以及备选SM-DS。
在本公开中，捆绑包管理服务器可以表示既执行生成、编码和传递捆绑包或捆绑包远程管理指令的功能又执行配置SSP和管理所安装的捆绑包的功能的服务器。此外，捆绑包管理服务器可以表示能够进一步执行订阅中介服务器的功能的服务器。因此，在以下本公开的各种实施例中，捆绑包管理服务器和订阅中介服务器的操作可以由一个捆绑包管理服务器执行。或者，功能可以由多个分离的捆绑包管理服务器单独执行。此外，在本公开的说明书中，捆绑包管理服务器或订阅中介服务器可以被称为捆绑包服务器。捆绑包服务器可以是捆绑包管理服务器和订阅中介服务器中的一个，或者可以是包括捆绑包管理服务器和订阅中介服务器两者的功能或配置的装置。
可以使用远程SIM供应(RSP)服务器来指代以下描述的配置文件提供服务器和/或配置文件管理服务器和/或订阅中介服务器。RSP服务器可以被称为订阅管理器XX(SM-XX)。
在本公开中，配置文件提供服务器可以包括以下功能：生成配置文件，对所生成的配置文件进行编码，生成配置文件远程管理指令，或者对所生成的配置文件远程管理指令进行编码。配置文件提供服务器可以被称为订阅管理器数据准备(SM-DP)、订阅管理器数据准备增强(SM-DP+)、配置文件域的卡外实体、配置文件加密服务器、配置文件生成服务器、配置文件供应器(PP)、配置文件提供方、或配置文件供应凭证(PPC)所有者。
在本公开中，配置文件管理服务器可以包括管理配置文件的功能。配置文件管理服务器可以被称为订阅管理器安全路由(SM-SR)、订阅管理器安全路由增强(SM-SR+)、eUICC配置文件管理者的卡外实体、配置文件管理凭证(PMC)所有者、eUICC管理器(EM)或配置文件管理器(PP)。
在本公开中，配置文件提供服务器还可以包括配置文件管理服务器的功能。因此，根据本公开的各种实施例，配置文件提供服务器的操作可由配置文件管理服务器执行。类似地，配置文件管理服务器或SM-SR的操作可以由配置文件提供服务器执行。
在本公开中，订阅中介服务器可以被称为订阅管理器发现服务(SM-DS)、发现服务(DS)、根SM-DS或可替换SM-DS。订阅中介服务器可以从一个或更多配置文件提供服务器或订阅中介服务器接收登记事件请求(事件登记请求)。可以组合使用一个或更多订阅中介服务器，并且在这种情况下，第一订阅中介服务器不仅可以从配置文件提供服务器接收事件登记请求，而且可以从第二订阅中介服务器接收事件登记请求。
服务提供方可以表示这样的企业：其发出请求捆绑包管理服务器生成捆绑包的要求并且通过捆绑包向终端提供服务。例如，服务提供方可以表示通过其上安装有通信应用的捆绑包来提供通信网络接入服务的移动运营商，并且可以统称为移动运营商的业务支持***(BSS)、操作支持***(OSS)、销售点(POS)终端和其它IT***中的全部。此外，在本公开中，服务提供方不限于仅表示特定企业中的一个，并且可以用于指代一个或更多企业的组或联合(或联盟)或者该组或联合的代表。在本公开中，服务提供方可以被称为运营商(或OP或Op.)，捆绑包所有者(BO)或图像所有者(IO)，并且每个服务提供方可以被配置或分配有名称和/或唯一标识符(对象标识符(OID))中的至少之一。当服务提供方涉及一个或更多企业的组或联合或代表时，该组或联合或者该代表的名称或唯一ID可以是由属于该组或联合的所有企业或者与该代表合作的所有企业共享的名称或唯一ID。
移动运营商可以指示向终端提供通信服务的企业，并且可以统称为移动运营商的企业支持***(BSS)、操作支持***(OSS)、销售点(POS)终端和其它IT***中的全部。此外，在本公开中，移动运营商不限于仅表示提供通信服务的特定企业中的一个，并且可以用于指一个或更多企业的组或联合(或联盟)或者表示该组或联合的代表。在本公开中，移动运营商可以被称为运营商(或OP或Op.)、移动网络运营商(MNO)、移动虚拟网络运营商(MVNO)、服务提供方(SP)或配置文件所有者(PO)，并且每个移动运营商可以被配置或分配有移动运营商的名称和/或唯一标识符(对象标识符(OID))中的至少之一。当移动运营商涉及一个或更多企业的组或联合或者代表时，组或联合或者代表的名称或唯一ID可以是由属于组或联合的所有企业或者与代表合作的所有企业共享的名称或唯一ID。
订户可用于指具有终端所有权的服务提供方或具有终端所有权的终端用户。通常，由服务提供方拥有的终端可以被称为M2M设备，并且由终端用户拥有的终端可以被称为用户终端(消费设备)。对于M2M设备，可能存在不具有终端所有权但通过从服务提供方接管或租用终端来使用终端的终端用户，并且在这种情况下，订户可以与服务提供方相同或不同。
订户意图可以被用于共同地指订户本地管理或远程管理捆绑包的意图。对于本地管理，订户意图可被用于指代终端用户意图，而对于远程管理，订户意图可被用于指代服务提供方意图。
终端用户意图可用于指示用户是否同意执行本地管理或远程管理。
终端可以被称为移动站(MS)、用户设备(UE)、用户终端(UT)、无线终端、接入终端(AT)、终端、订户单元、订户站(SS)、无线设备、无线通信设备、无线传输/接收单元(WTRU)、移动节点、移动或其它术语。终端的各种实施例不仅可以包括蜂窝电话、具有无线通信功能的智能电话、具有无线通信功能的个人数字助理(PDA)、无线调制解调器、具有无线通信功能的便携式计算机、具有无线通信功能的成像设备(诸如数字相机)、具有无线通信功能的游戏设备、具有无线通信功能的音乐存储和再现家电、以及能够进行无线因特网访问和浏览的因特网家电，而且可以包括其中集成有这些功能的组合的便携式单元或终端。终端还可以包括机器到机器(M2M)终端或机器类型通信(MTC)终端/设备，但不限于此。在本公开中，终端也可以被称为电子设备。
在本公开中，能够下载和安装捆绑包的SSP可以被嵌入到电子设备中。当SSP没有嵌入电子设备中时，可以将与电子设备物理分离的SSP***并连接到电子设备。例如，SSP可以以卡的形式***到电子设备中。电子设备可以包括终端，并且所述终端可以是包括能够下载和安装捆绑包的SSP的终端。SSP能够嵌入到终端中，并且当终端和SSP分离时，SSP可以被***到终端中以连接到终端。
在本公开中，能够下载和安装配置文件的UICC可以被嵌入在电子设备中。当UICC没有嵌入电子设备中时，可以将与电子设备物理分离的UICC***并连接到电子设备。例如，UICC可以以卡的形式***到电子设备中。电子设备可以包括终端，并且此时，终端可以是包括能够下载和安装配置文件的UICC的终端。UICC能够嵌入到终端中，并且当终端和UICC分离时，UICC可以***到终端中以连接到终端。能够下载和安装配置文件的UICC可以被称为例如eUICC。
本地捆绑包助理(LBA)可以指安装在终端或电子设备中以控制SSP的软件或应用。软件或应用可以被称为本地捆绑包管理器(LBM)。
加载器(次平台捆绑包加载器(SPBL))可以指用于管理SSP中的另一捆绑包的安装、启用、禁用和删除的管理捆绑包。终端或远程服务器的LBA可以通过加载器来安装、启用、禁用或删除特定的包。在本公开中，加载器的操作也可以被描述为包括加载器的SSP的操作。
本地配置文件助理(LPA)可以指安装在终端或电子设备中使得终端或电子设备控制UICC或eUICC的软件或应用。
在本公开中，事件可以用于以下目的。
[When used in relation to a bundle](当与捆绑包相关地使用时)
事件(event)可以是统称为捆绑包下载、远程捆绑包管理、或另一捆绑包或SSP管理/处理命令的术语。事件可以被称为远程SIM供应操作(RSP操作)或事件记录，并且每个事件可以被标识为这样的数据：该数据包括对应的事件标识符(事件ID或EventID)或匹配标识符(匹配ID或MatchingID)、存储该事件的捆绑包管理服务器或订阅中介服务器的地址(完全限定域名(FQDN)、IP地址或统一资源定位符(URL))、或每个服务器的标识符中的至少之一。捆绑包下载和捆绑包安装可以互换使用。此外，事件类型可用作指示特定事件是捆绑包下载、远程捆绑包管理(例如，删除、启用、禁用、替换或更新)还是另一捆绑包或SSP管理/处理命令的术语。此外，事件类型可以被称为操作类型(OperationType)、操作类(OperationClass)、事件请求类型、事件类或事件请求类。
本地捆绑包管理(LBM)可以被称为捆绑包本地管理、本地管理、本地管理命令、本地命令、LBM包、捆绑包本地管理包、本地管理包、本地管理命令包或本地命令包。LBM可用于通过安装在终端中的软件等安装任意捆绑包、改变特定捆绑包的状态(已启用、已禁用或已删除)、或改变(更新)特定捆绑包的内容(例如，捆绑包别名或捆绑包元数据)。LBM可以包括一个或更多本地管理命令，并且在这种情况下，受本地管理命令支配的捆绑包对于每个本地管理命令可以相同或不同。
远程捆绑包管理(RBM)可以被称为捆绑包远程管理、远程管理、远程管理命令、远程命令、RBM包、捆绑包远程管理包、远程管理包、远程管理命令包或远程命令包。RBM可用于安装任意捆绑包，改变特定捆绑包的状态(已启用、已禁用或已删除)，或改变特定配置文件的(更新)内容(例如，捆绑包别名或捆绑包元数据)。RBM可以包括一个或更多远程管理命令，并且在这种情况下，受远程管理命令支配的捆绑包对于每个远程管理命令可以相同或不同。
目标捆绑包可用于引用受本地管理命令或远程管理命令支配的捆绑包。
可以使用捆绑包规则来引用在对目标捆绑包执行本地管理或远程管理时需要由终端识别的信息。此外，捆绑包规则可以与捆绑包策略、规则或策略互换使用。
[When used in relation to a profile](当与配置文件相关地使用时)
事件可以是统称为配置文件下载、远程配置文件管理、或另一个配置文件或eUICC管理/处理命令的术语。事件可以被称为远程SIM供应操作(RSP操作)或事件记录，并且每个事件可以被称为这样的数据，该数据包括对应的事件标识符(事件ID或EventID)或匹配标识符(匹配ID或MatchingID)、存储该事件的配置文件提供服务器(SM-DP+)或订阅中介服务器(SM-DS)的地址(FQDN、IP地址或URL)、配置文件提供服务器(SM-DP+)或订阅中介服务器(SM-DS)的签名、以及配置文件提供服务器(SM-DP+)或订阅中介服务器(SM-DS)的数字证书中的至少之一。
对应于事件的数据可以被称为命令代码。使用命令代码的过程的一部分或全部可以被称为命令代码处理过程、命令代码过程、或本地配置文件助理(LPA)应用编程接口(API)。配置文件下载和配置文件安装可以互换使用。
事件类型可用作指示某一事件是配置文件下载、远程配置文件管理(例如，删除、启用、禁用、替换或更新)、还是另一配置文件或eUICC管理/处理命令的术语，且可称为操作类型(OperationType)、操作类(OperationClass)、事件请求类型、事件类、或事件请求类。可以向任意事件标识符(EventID或MatchingID)分配获得终端事件标识符(EventID或MatchingID)的路径或使用目的(EventID源或MatchingID源)。
本地配置文件管理(LPM)可以被称为配置文件本地管理、本地管理、本地管理命令、本地命令、LPM包、配置文件本地管理包、本地管理包、本地管理命令包或本地命令包。LPM可用于通过安装在终端中的软件等来改变特定配置文件的状态(已启用、已禁用或已删除)，或改变特定配置文件的内容(例如，配置文件别名或配置文件元数据)。LPM可以包括一个或更多本地管理命令，并且在这种情况下，服从本地管理命令支配的配置文件对于每个本地管理命令可以相同或不同。
远程配置文件管理(RPM)可以被称为配置文件远程管理、远程管理、远程管理命令、远程命令、RPM包、配置文件远程管理包、远程管理包、远程管理命令包或远程命令包。RPM可用于改变特定配置文件的状态(已启用、已禁用或已删除)或者改变(更新)特定配置文件的内容(例如，配置文件别名或配置文件元数据)。RPM可以包括一个或更多远程管理命令，并且在这种情况下，服从远程管理命令支配的配置文件对于每个远程管理命令可以相同或不同。
证书或数字证书可以指基于包括一对公共密钥(PK)和私密密钥(SK)的非对称密钥来用于相互认证的数字证书。每个证书可以包括一个或更多PK、对应于每个PK的PK标识符(PKID)、发布相应证书的证书发布方(CI)的标识符(ID)、以及数字签名。证书发布方可以被称为证明发布方、证书机构(CA)或证明机构。在本公开中，PK和PKID可以用作指示这样的存储空间的含义，该存储空间存储特定PK或包括特定PK的证书、特定PK的一部分或包括特定PK的证书的一部分、特定PK的操作结果(例如散列值)或包括特定PK的证书的操作结果(例如散列值)、特定PK的一部分的操作结果(例如散列值)或包括特定PK的证书的一部分的操作结果(例如散列值)、或者数据。
证书链或证书层次结构可以指：当证书发布方所发布的证书(主证书)用于发布另一证书(二级证书)时，或者当二级证书用于连接地发布三级或更高级证书时，相应证书之间的相关性。这里，最初用于发布证书的CI证书可以被称为证书的根、顶层证书、根CI、根CI证书、根CA或根CA证书。
在描述本公开时，当认为相关功能或配置可能不必要地模糊本公开的实质时，可省略相关功能或配置的详细描述。
在下文中，将描述与用于在终端之间传送捆绑包和安装捆绑包的方法和装置有关的各种实施例。
图1示出根据本公开的实施例的智能安全平台(SSP)的示意图。
参考图1，根据本公开的实施例，终端110可以包括SSP 120。例如，SSP 120可以嵌入在终端110的SoC 130中。这里，SoC 130可以是通信处理器、应用处理器、或其中集成了这两种处理器的处理器。作为另一个示例，SSP 120可以是独立芯片形式的可移除类型122，其不与SoC集成，或者可以是预嵌入在终端110中的嵌入式类型124。
根据各种实施例，包括在终端中的SSP 120可以包括以下至少之一：一个或更多电信捆绑包、一个或更多支付捆绑包、或一个或更多电子ID捆绑包。例如，如图1所示，当SSP包括多个电信捆绑包140和150时，终端110可以通过根据配置同时或按时分操作多个电信捆绑包140和150来使用移动通信网络。此外，当SSP 120包括支付捆绑包170和电子ID捆绑包180时，终端110可以使用支付捆绑包170通过终端应用使用在线支付或者通过外部***销售点(PoS)设备使用离线支付，并且可以使用电子ID捆绑包180认证终端持有者的身份。
图2示出根据本公开的实施例的SSP的内部结构的示意图。
参照图2，根据本公开的实施例，SSP 210可以包括一个主平台(PP)220，以及包括在PP 220上操作的次平台捆绑包(SPB)230和240中的至少之一。
根据各种实施例，PP 220可以包括硬件(未示出)和至少一个低级操作***(LLOS)222。
根据各种实施例，SPB 230可以包括高级操作***(HLOS)232和在其上操作的至少一个应用234。
根据各种实施例，SPB 230和240中的每一个可以使用主平台接口(PPI)250来访问PP 220的资源，例如中央处理单元和存储器，并且通过资源在SSP 210中被驱动。
图3是示出根据本公开的实施例的终端中的、由终端用来将捆绑包下载到并安装在SSP中的组件的示例的图。
参考图3，根据本公开的实施例，终端310可以包括SSP 330和/或用于控制SSP 330的LBA 312。例如，终端310可以是安装了SSP 330并且安装了用于控制SSP 330的LBA 312的终端。SSP 330可以嵌入在终端310中或者可以从终端310拆除。
根据各种实施例，SSP 330可以包括主平台331、次平台捆绑包加载器(SPBL)333以及一个或更多次平台捆绑包335、337和339中的至少之一。
根据各种实施例，在终端被发布时，次平台捆绑包335、337或339可以不被安装在SSP 330中，而是可以在发布之后被远程下载和安装。
根据各种实施例，如图3所示，捆绑包可以包括不同的FID和/或OID 341、342和343。这种FID和/或OID 341、342和343可以用作下载和安装捆绑包所需的信息。换句话说，SSP 330或SPBL 333可以根据FID和/或OID 341、342和343允许或拒绝下载和安装特定的捆绑包。
图4是示出根据本公开的实施例的、两个终端和服务器通过其相互操作使得捆绑包从一个终端在线传输到另一个终端的方法的示例的图。
参考图4，根据本公开的实施例，终端可以包括至少一个LBA和至少一个SSP。例如，第一终端400可以包括第一LBA 410和第一SSP420，并且第二终端450可以包括第二LBA 460和第二SSP 470。
根据各种实施例，在操作4020和4070中，第一LBA 410和第二LBA 460可以向第一SSP 420和第二SSP 470传输命令，或者向第一SSP 420和第二SSP 470传输/从第一SSP 420和第二SSP 470接收数据。此外，在操作4030和4080中，第一SSP 420和第二SSP 470可以生成、处理或验证第一SSP 420和第二SSP 470内部所需的数据。
根据各种实施例，在操作4050(以下称为第三操作)中，第一LBA 410和第二LBA460可以彼此连接以向对方传输命令，或者向对方传输数据/从对方接收数据。在第三操作中，操作4050中的连接可以是第一终端400和第二终端450之间的直接连接，或者虽然未示出，但是可以是其中外部实体(例如，外部服务器)连接在第一LBA 410和第二LBA 460之间的间接连接。下面将参考附图描述关于连接第一LBA 410和第二LBA 460的方法的详细描述。
根据各种实施例，用户可以向终端传输命令或从终端接收要被提供的信息。例如，如在操作4010和4060中，第一用户440和第二用户490可以向第一终端400和第二终端450的第一LBA 410和第二LBA 460传输命令，或者从第一LBA 410和第二LBA 460接收要提供给用户的信息。第一用户440和第二用户490可以表示不同的用户或者可以表示相同的用户。
根据各种实施例，捆绑包管理服务器可以向/从终端传输/接收数据。例如，如在操作4040和4090中那样，第一捆绑包管理服务器430和第二捆绑包管理服务器480可以从第一终端400和第二终端450的第一LBA 410和第二LBA 460接收消息或向第一终端400和第二终端450的第一LBA 410和第二LBA 460传输消息。第一捆绑包管理服务器430和第二捆绑包管理服务器480可以是不同的捆绑包管理服务器或相同的捆绑包管理服务器。当第一捆绑包管理服务器430和第二捆绑包管理服务器480彼此不同时，如在操作4000中那样，两个服务器可以传输/接收消息。
图4示出其中第一捆绑包管理服务器430和第二捆绑包管理服务器480直接传输/接收消息的示例，但是根据实施例，在两个捆绑包管理服务器之间可以存在一个或更多其它捆绑包管理服务器。例如，虽然未示出，但是在第一捆绑包管理服务器和第二捆绑包管理服务器之间可以存在第三捆绑包管理服务器，并且当第一或第二捆绑包管理服务器要向第二或第一捆绑包管理服务器传输消息时，第一或第二捆绑包管理服务器可以首先向第三捆绑包管理服务器传输消息，并且第三捆绑包管理服务器可以向第二或第一捆绑包管理服务器传输消息。类似地，在第一捆绑包管理服务器和第二捆绑包管理服务器之间可以存在多个捆绑包管理服务器和/或中继服务器。
在本公开中，为了便于描述，可以将一个或更多捆绑包管理服务器中的全部称为一个捆绑包管理服务器。例如，第一捆绑包管理服务器430和第二捆绑包管理服务器480可以被整体地称为捆绑包管理服务器。在这种情况下，例如，第一终端通过第一捆绑包管理服务器和第二捆绑包管理服务器向/从第二终端传输/接收消息的过程可以被描述为第一终端通过捆绑包管理服务器向/从第二终端传输/接收消息的过程。即使当如上所述那样，在第一捆绑包管理服务器和第二捆绑包管理服务器之间存在一个或更多捆绑包管理服务器时，这些捆绑包管理服务器也可以统称为捆绑包管理服务器。
图5是示意性示出根据本公开的实施例的用于从一个终端向另一个终端在线传输捆绑包的过程的示例的示图。
参考图5，终端可以包括至少一个LBA和至少一个SSP。例如，第一终端510可以包括第一LBA 530和第一SSP 520，并且第二终端560可以包括第二LBA 580和第二SSP 570。已经参考图4描述了关于捆绑包管理服务器的细节。
在操作5000中，第一终端510和第二终端560可执行传输捆绑包所需的准备过程(捆绑包传输准备过程)。下面将参考图6描述关于捆绑包传输准备过程的细节。
在操作5005中，第一终端510可以将要传输到第二终端的捆绑包上传到捆绑包管理服务器550。下面将参考图7描述有关相应过程的细节。
在操作5010中，第二终端560可以从捆绑包管理服务器550下载在操作5005中上传的捆绑包，并安装该捆绑包。下面将参考图8描述有关相应过程的细节。
图6是示出根据本公开的实施例的图5中提出的过程之中的、准备传输捆绑包的过程的详细过程的图。
参考图6，终端可以包括至少一个LBA和至少一个SSP。例如，第一终端610可以包括第一LBA 630和第一SSP 620，并且第二终端660可以包括第二LBA 680和第二SSP 670。
根据各种实施例，第一终端610可以包括预装捆绑包，并且还包括与预装捆绑包相关联的元数据。
根据各种实施例，第一终端610可以包括与预装捆绑包相关的捆绑包ID(SPB ID)、FID(SPB族ID)或OID(SPB族托管对象ID)中的至少之一。
根据各种实施例，第一终端610可以包括与预装捆绑包相关的捆绑包传送配置。
捆绑包传送配置是关于设备之间的捆绑包传送是否可行的信息，并且可以由服务提供方(其是初始提供方)、由捆绑包管理服务器、或由服务提供方和捆绑包管理服务器的协作来生成。捆绑包传送配置可由服务提供方、捆绑包管理服务器、或者服务提供方与捆绑包管理服务器的协作来更新。或者，可以通过终端与服务提供方和捆绑包管理服务器之中的至少一个实体的协作来更新捆绑包传送配置。更新时间点和/或更新方法可以由服务提供方、捆绑包管理服务器和终端制造商的策略来确定。
捆绑包传送配置可以选择性地包括指示是否允许在设备之间传送捆绑包的因子(或指示符)。此外，捆绑包传送配置还可以选择性地包括指定允许在设备之间传送捆绑包的条件的因子。例如，可以包括指示设备之间的捆绑包的在线传送是否的因子。
参照图6，在操作6000中，第一LBA 630可以获得关于要在设备之间传输的捆绑包的信息。或者，可以将关于要在设备之间传输的捆绑包的信息传递到第一LBA 630。例如，第一LBA 630可以通过经由第一终端610提供的用户界面(UI)接收用户选择捆绑包的用户输入来获得关于要传输的捆绑包的信息。或者，可以通过来自远程服务器的推送输入将关于要传输的捆绑包的信息输入到第一LBA 630，或者第一LBA 630可以通过访问远程服务器来读取关于要传输的捆绑包的信息。
在操作6002中，第一LBA 630可以通过使用捆绑包传送配置来识别捆绑包在设备之间的传输是否可行。此外，第一LBA 630可以通过检查捆绑包传送配置来识别捆绑包在设备之间的在线传输是否可行。
在操作6004中，第一LBA630可以生成捆绑包传输代码。捆绑包传输代码可以包括要传输的捆绑包的捆绑包分隔符，诸如捆绑包ID(SPB ID)、FID(SPB族ID)或OID(SPB族托管对象ID)。此外，捆绑包传输代码还可以包括指示捆绑包的属性的其它信息(例如，捆绑包的元数据或元数据的一部分)。捆绑包传输代码可以包括与要传输的捆绑包相关联的捆绑包管理服务器的n个地址(SPBM Addr)。捆绑包传输代码可以包括在操作6010中连接两个终端所需的信息。例如，可以包括两个终端的Wi-Fi连接所需的信息(例如，第一终端610的SSID和/或BSSID、用于两个终端的连接认证的预共享密钥、第一终端的IP地址、以及用于两个终端之间的通信的端口号)。
此外，捆绑包传输代码可以包括关于由第一终端(例如，第一SSP)支持的加密算法的信息(SupportedCryptoInfo)。关于由第一终端支持的加密算法的信息可以选择性地包括以下信息中的至少之一：由第一终端支持的椭圆曲线列表、由第一终端支持的密钥协商算法列表、以及由第一终端支持的加密算法列表。
尽管在附图中描述了第一LBA 630识别捆绑包传送配置，但是该过程可以由以下过程代替：第一LBA 630可以将关于要传输的捆绑包的信息(例如捆绑包ID)传输到第一SSP620，第一SSP 620可以识别与所接收的捆绑包ID对应的捆绑包的捆绑包传送配置，并且第一SSP 620可以将识别的结果传输到第一LBA 630。
尽管描述了第一LBA630生成捆绑包传输代码，但是该过程可以由以下过程代替：第一LBA630可以向第一SSP 620传输捆绑包传输代码所需的信息，第一SSP 620可以向第一LBA 630传输所请求的信息，并且第一LBA 630可以基于该信息来配置捆绑包传输代码。
参照图6，在操作6005中，在操作6004中生成的捆绑包传输代码可以从第一LBA630传输到第二LBA 680。可以经由各种方法中的任何一种来传输捆绑包传输代码。
例如，第一LBA 630可以通过第一终端610的UI向第一终端610的第一用户提供要传递到第二LBA 680的信息。第一用户可以向第二终端660的第二用户提供所提供的信息。第二用户可以通过使用第二终端660的UI将所提供的信息输入到第二LBA 680。
或者，第一LBA 630可以生成要传递到第二LBA 680的信息的图像(例如，QR代码)，并且在第一终端610的屏幕上显示该信息，并且第二用户可以通过使用第二终端660来扫描在第一终端610的屏幕上显示的图像，并且将该信息传递到第二LBA 680。
参照图6，在操作6010中，可以在第一LBA 630和第二LBA 680之间建立(或配置)连接。第一LBA 630和第二LBA 680可以通过使用包括在捆绑包传输代码中的信息来建立连接。第一LBA 630和第二LBA 680之间的连接可以是设备之间的直接连接(例如，NFC、蓝牙、UWB、Wi-Fi直连、LTE设备到设备(D2D)或5G D2D)或者其中远程服务器(例如，中继服务器)位于第一LBA 630和第二LBA 680之间的远程连接。
在图中示出首先执行操作6005然后执行操作6010，但是可以切换这种顺序。换句话说，可以首先建立第一LBA 630和第二LBA 680之间的连接(对应于操作6010)，并且可以通过所建立的连接将捆绑包传输代码从第一LBA 630传输到第二LBA 680(对应于操作6005)。
参照图6，在操作6015中，第二LBA 680可以向第二SSP 670传输所接收的捆绑包传输代码的一部分和/或全部。
参照图6，在操作6020中，第二SSP 670可以识别所接收的由第一终端支持的加密算法，以识别在其之中是否存在由第二终端(例如，第二SSP)支持的加密算法。当在所接收的由第一终端支持的加密算法之中存在由第二终端支持的加密算法时，可以选择由第二终端支持的加密算法中的一个来配置与所选择的加密算法相同的加密算法。所选择的加密算法可以选择性地包括以下信息中的至少之一：椭圆曲线信息、密钥协商算法信息和加密算法信息。
第二SSP 670可以基于所选择的加密算法生成第二终端660的密钥对(临时公共密钥ssp2.ePK.BT和相应的私密密钥ssp2.eSK.BT)，以便稍后用于生成用于与第一终端610进行加密通信的加密密钥。第二SSP 670可以将所生成的密钥对映射到所接收的捆绑包ID(SPB ID)。第二SSP 670可以生成所选择的加密信息(ssp2.SelectedCryptoInfo)。所选择的加密信息可以选择性地包括以下信息中的至少之一：所选择的加密算法的一部分和/或全部以及ssp2.eEPK.BT。
在操作6020中，第二SSP 670可以生成这样的信息(统称为资格包(eligibilitypackage)或ssp2.EligibilityPackage)，该信息稍后可以用于确定是否能够从RSP服务器接收并安装要由第一终端610传输的捆绑包。
资格包可以包括稍后当RSP服务器和第二终端彼此通信时所使用的、第二终端660的证书协商信息。证书协商信息可选择地包括以下信息中的至少之一：与可用于验证第二SSP的证书有关的信息、与可由第二SSP用来验证RSP服务器的证书有关的信息、与第二SSP支持的密钥协商算法有关的信息、以及与由第二SSP支持的加密算法有关的信息。
资格包可包括可用于确定特定捆绑包是否能够在第二终端中正常安装和/或操作的信息。这种信息可以选择性地包括以下信息中的至少之一：第二SSP的SSP ID和第二SSP的部件号ID。
在操作6020中，第二SSP可以生成ReceiverInfo。ReceiverInfo可以选择性地包括以下信息中的至少之一：所选择的加密信息(ssp2.SelectedCryptoInfo)以及资格包(ssp2.EligibilityPackage)。
参照图6，在操作6025中，第二SSP 670可以通过第二LBA 680向第一LBA 630传输ReceiverInfo。
图7是示出根据本公开的实施例的图5中提出的过程之中的、要传输捆绑包的终端将要传输的捆绑包上传到服务器的过程的图。
参考图7，终端可以包括至少一个LBA和至少一个SSP。例如，第一终端710可以包括第一LBA730和第一SSP 720，并且第二终端760可以包括第二LBA780和第二SSP 770。已经参考图4描述了关于捆绑包管理服务器的细节。
参照图7，在操作7000中，第一LBA730可以向第一SSP 720请求SSP信息(SspInfo)。
当向第一SSP 720请求SSP信息(SspInfo)时，第一LBA 730可以通知第一SSP 720要执行设备之间的捆绑包传送。当向第一SSP 720请求SSP信息(SspInfo)时，第一LBA 730可以通知第一SSP 720要执行设备之间的在线捆绑包传送。例如，请求消息可以包括指示要执行设备之间的捆绑包传送的指示符。作为另一个示例，请求消息可以包括指示要执行设备之间的在线捆绑包传送的指示符。请求消息可以包括指示符或者指示符的值可以被配置成1，从而通知第一SSP 720要执行设备之间的捆绑包传送或者设备之间的在线捆绑包传送。
第一LBA 730可以向第一SSP 720提供关于要传输的捆绑包的信息。该信息可以包括FID(SPB族ID)和OID(SPB族托管对象ID)中的至少之一。
操作7000可以在图6中描述的所有过程之后立即自动执行，或者可以在接收到外部输入之后执行。这里，外部输入可以是第一终端710的第一用户通过第一终端710提供的UI而输入的用户输入，或者是从远程服务器到第一LBA 730的推送输入。此外，当第一LBA730访问远程服务器时，可以启动操作7000。
参照图7，在操作7005中，第一SSP 720可以生成其SSP信息(ssp1.SspInfo)，并通过第一LBA730将SSP信息传输到捆绑包管理服务器(SPBM)750。
SSP信息可以包括针对捆绑包传输所要提供的、关于第一SSP 720的信息。这里，SSP信息可以包括用于证书协商过程的信息(证书协商信息)，其中，第一SSP 720执行该证书协商过程以与捆绑包管理服务器通信。证书协商信息可以包括可以被第一SSP 720用于验证捆绑包管理服务器的证书信息和/或可以被捆绑包管理服务器用于验证第一SSP 720的证书信息。此外，证书协商信息还可以包括由第一SSP720支持的密钥协商算法的列表，并且还包括由第一SSP 720支持的加密算法的列表。
SSP信息还可以包括SSP版本信息，该SSP版本信息包括来自包括在第一SSP 720中的加载器和主平台所支持的标准的多项版本信息之中的至少一项版本信息。
根据实施例，第一SSP 720可以通过第一LBA 730将SSP信息传输到捆绑包管理服务器750。
在操作7000至7005中，第一LBA 730可以向第一SSP 720请求SSP信息，第一SSP720可以生成其SSP信息，并且第一SSP 720可以通过第一LBA 730向捆绑包管理服务器750传输SSP信息。然而，根据实施例，第一LBA 730可以自生成SSP信息并将SSP信息传输到捆绑包管理服务器750。
参照图7，在操作7010中，捆绑包管理服务器750可以识别所接收的SSP信息，基于SSP信息生成服务器认证信息(SPBM.Auth1)，并将服务器认证信息传输到第一LBA 730。
服务器认证信息可以包括以下信息中的至少之一。
a)密钥协议证书(称为SPBM.Cert.KA)，其可用于对SPBM本身以及用于验证密钥协议证书所需的证书进行验证。
b)证书信息(被称为CiPkIdToBeUsed)，其可以被SPBM用于验证第一SSP。
c)加密算法信息(称为CryptoToBeUsed)，其供SPBM用于执行与第一SSP的加密通信。
根据实施例，捆绑包管理服务器750可以将服务器认证信息传输到第一LBA 730。
参照图7，在操作7015中，第一LBA 730可以将服务器认证信息传输到第一SSP720。此外，第一LBA 730还可以向第一SSP 720传输要传输的捆绑包的捆绑包分隔符。
根据实施例，第一SSP 720可以执行以下指定的操作中的至少之一。
a)可以识别所接收的SPBM.Cert.KA的有效性。
b)可以选择能够基于所接收的CiPkIdToBeUsed来验证第一SSP的签名证书(ssp1.Cert.DS)中的至少之一。
c)可以识别所接收的CryptoToBeUsed，并且可以生成加密密钥对，即，公共密钥ssp1.ePK.KA和私密密钥ssp1.eSK.KA，该加密密钥对被用于生成用于与捆绑包管理服务器进行加密通信的加密密钥。而且，第一SSP 720可以通过使用ssp1.eSK.KA和包括在SPBM.Cert.KA中的密钥协议公共密钥来生成ShKeyM1，该ShKeyM1是用于与捆绑包管理服务器750进行加密通信的会话密钥。
在操作7020中，第一SSP 720可以生成第一终端认证信息(Device1.Auth)，并将第一终端认证信息(Device1.Auth)传输到第一LBA 730。第一终端认证信息(Device1.Auth)可以包括以下信息中的至少之一。
a)ssp1.Cert.DS
b)ssp1.ePK.KA
c)参考当前会话的事务ID
d)第一SSP 720的SSP ID
e)要传输捆绑包的捆绑包分隔符
可以对第一终端认证信息(Device1.Auth)的一部分或全部进行数字签名，使得可以通过使用ssp1.Cert.DS保证信息的完整性来进行验证，并且可以将数字签名数据添加为第一终端认证信息的一部分。
此外，可以通过使用所生成的会话密钥ShKeyM1来对第一终端认证信息(Device1.Auth)的一部分或全部进行编码。
根据实施例，第一SSP 720可以向第一LBA 730传输第一终端认证信息(Device1.Auth)。
参照图7，在操作7025中，第一LBA 730可以将第一终端认证信息传输到捆绑包管理服务器750。第一LBA 730还可以将ssp2.EligibilityPackage传输到捆绑包管理服务器750。关于ssp2.EligibilityPackage的细节已经参考图6进行了描述。第一LBA 730还可以将要传输的捆绑包的捆绑包分隔符传输到捆绑包管理服务器750。
参照图7，在操作7030中，捆绑包管理服务器750可以执行以下过程中的至少之一。
a)捆绑包管理服务器可以验证包括在第一终端认证信息中的ssp1.Cert.DS的有效性。此外，当第一终端认证信息包括电子签名时，捆绑包管理服务器可以通过使用ssp1.Cert.DS来验证签名的有效性。
b)当第一终端认证信息包括经编码数据时，捆绑包管理服务器可以通过使用ssp1.ePK.KA以及与包括在SPBM.Cert.KA中的密钥协议公共密钥对应的私密密钥来生成用于与第一终端进行加密通信的会话密钥ShKeyM1，并且通过使用会话密钥来对经编码数据进行解码。
c)捆绑包管理服务器可以识别和/或存储所接收的事务ID和/或第一SSP的SSPID。
d)捆绑包管理服务器可以识别和/或存储要由第一终端传输的捆绑包的捆绑包分隔符。
在操作7030中，捆绑包管理服务器还可以执行以下过程中的至少之一。
a)捆绑包管理服务器可以通过使用第一SSP的SSP ID和将由第一终端传输的捆绑包的捆绑包分隔符来验证第一终端(例如，第一SSP)是否是使用当前捆绑包的合法主体。
b)捆绑包管理服务器可以验证要由第一终端传输的捆绑包是否是能够在线传输的捆绑包。
c)捆绑包管理服务器可以通过验证ssp2.EligibilityPackage来验证以下事项中的至少之一：与第二终端的证书协商是否成功，以及要由第一终端传输的捆绑包是否被正常安装和/或操作在第二终端(例如，第二SSP)中。
在操作7030中，捆绑包管理服务器750可以生成用于向第一终端710请求捆绑包的消息(称为spbRequest)，并将该spbRequest传输到第一LBA。spbRequest可以包括以下信息中的至少之一。
a)第一SSP的SSP ID
b)第二SSP的SSP ID
c)第一终端要传输的捆绑包的捆绑包分隔符
d)事务ID
包括在spbRequest中的信息的一部分和/或全部可以通过使用ShKeyM1来编码，并且ShKeyM1可以被包括作为spbRequest的一部分。
包括在spbRequest中的信息的一部分和/或全部可以通过使用SPBM.Cert.DS进行电子签名，并且电子签名的值可以被包括作为spbRequest的一部分。
根据实施例，捆绑包管理服务器可以向第一LBA传输spbRequest。
参照图7，在操作7035中，第一LBA 730可以向第一SSP 720传输spbRequest。在操作7035中，第一LBA 730还可以向第一SSP 720传输ssp2.SelectedCryptoInfo。已经参考图6描述了关于ssp2.SelectedCryptoInfo的细节。
根据实施例，第一SSP 720可以执行以下过程中的至少之一。
a)当spbRequest包括经编码信息时，通过使用ShKeyM1对经编码信息进行解码。
b)当spbRequest包括电子签名的值时，使用SPBM.Cert.DS验证该值。
c)验证包括在spbRequest中的第一SSP的SSP ID和/或第二SSP的SSP ID和/或要由第一终端传输的捆绑包的捆绑包分隔符和/或事务ID是否具有正确的值。
第一SSP 720可以识别包括在ssp2.SelectedCryptoInfo中的信息。
第一SSP 720可以配置作为加密密钥对的公共密钥ssp1.ePK.BT和私密密钥ssp1.eSK.BT。根据实施例，加密密钥值的值可以与ssp1.ePK.KA和ssp1.eSK.KA的值相同。
根据实施例，第一SSP 720可以通过使用所生成的ssp1.eSK.BT和与包括在SPBM.Cert.KA中的公开密钥对应的私密密钥来生成用于与捆绑包管理服务器750进行加密通信的密钥ShKeyBT。
根据实施例，第一SSP 720可以通过使用所生成的ssp1.eSK.BT和ssp2.ePK.BT来生成用于与第二终端进行加密通信的密钥ShKeyBT。
第一SSP 720可以准备要传输到第二终端760的捆绑包。可以通过使用ShKeyBT对捆绑包中所包括的信息的一部分和/或全部进行编码。准备好的捆绑包可以被称为boundSpbImage。
第一SSP 720可以删除准备好的捆绑包。
第一SSP 720可以删除该捆绑包并且生成用于向捆绑包管理服务器750通知有关删除的信息的令牌(被称为ssp1.Notification)。
在操作7040中，第一SSP 720可以将boundSpbImage传输到捆绑包管理服务器750。第一SSP 720还可以将ssp1.ePK.BT传输到捆绑包管理服务器750。第一SSP 720还可以将ssp1.Notification传输到捆绑包管理服务器750。
参照图7，在操作7045中，捆绑包管理服务器750可以验证ssp1.Notification，并向第一LBA 730传输响应消息。
当boundSpbImage由通过使用ssp1.eSK.BT和包括在SPBM.Cert.KA中的公开密钥而生成的加密密钥进行编码时，捆绑包管理服务器750可以通过使用ssp1.ePK.BT和与包括在SPBM.Cert.KA中的公开密钥对应的私密密钥来生成加密密钥ShKeyBT，然后通过使用加密密钥对包括在boundSpbImage中的经编码数据进行解码。
由捆绑包管理服务器750接收的boundSpbImage可以被称为捆绑包。
捆绑包管理服务器750可以将以下信息中的一些或全部相互映射：捆绑包、要由第一终端传输的捆绑包的捆绑包分隔符、以及第二SSP的SSP ID。
捆绑包管理服务器750可以将响应消息传输到第一LBA 730。
参照图7，在操作7050中，第一LBA 730可以通知第二LBA 780捆绑包请求发起是可行的。第一LBA 730可以向第二LBA 780传输用于通知捆绑包请求发起可行的消息(被称为startRequest)。该startRequest可以包括安装在第二终端中的第二SSP的SSP ID。该startRequest可以包括要传输的捆绑包的捆绑包分隔符。该startRequest可以包括指示捆绑包请求发起现在可行的指示符。第一LBA可以将指示符添加到startRequest，或者可以将特定值设置到指示符然后将其添加到startRequest，并且将startRequest传输到第二LBA，从而通知第二LBA捆绑包请求发起可行。
图8是示出根据本公开的实施例的图5中提出的过程之中的、用于将上传到服务器的捆绑包下载到要接收该捆绑包的终端的过程的图。
参考图8，终端可以包括至少一个LBA和至少一个SSP。例如，第二终端860可以包括第二LBA 880和第二SSP 870。已经参考图4描述了关于捆绑包管理服务器的细节。
参照图8，在操作8000中，第二LBA 880可以向第二SSP 870请求SSP信息(SspInfo)。
当向第二SSP 870请求SSP信息(SspInfo)时，第二LBA 880可以通知第二SSP要执行设备之间的捆绑包传送。当向第二SSP 870请求SSP信息(SspInfo)时，第二LBA 880可以进一步通知第二SSP要执行设备之间的在线捆绑包传送。例如，请求消息可以包括指示要执行设备之间的捆绑包传送的指示符。作为另一个示例，请求消息可以包括指示要执行设备之间的在线捆绑包传送的指示符。请求消息可以包括指示符或者指示符的值可以被设置为特定值，从而通知第二SSP要执行设备之间的捆绑包传送或者设备之间的在线捆绑包传送。
第二LBA 880可以向第二SSP 870提供关于要传输的捆绑包的信息。该信息可以包括FID(SPB族ID)和OID(SPB族托管对象ID)中的至少之一。
参照图8，在操作8005中，第二SSP 870可以生成其SSP信息(ssp2.SspInfo)，并通过第二LBA 880将SSP信息传输到捆绑包管理服务器850。
SSP信息可以包括针对捆绑包传输所要提供的、关于第二SSP的信息。这里，SSP信息可以包括供第二SSP 870执行证书协商过程以与捆绑包管理服务器850通信的信息(证书协商信息)。证书协商信息可以包括可以被第二SSP 870用于验证捆绑包管理服务器的证书信息和/或可以被捆绑包管理服务器850用于验证第二SSP的证书信息。此外，证书协商信息还可以包括由第二SSP 870支持的密钥协商算法的列表，并且还包括由第二SSP 870支持的加密算法的列表。
SSP信息还可以包括SSP版本信息，该SSP版本信息包括由第二SSP 870中所包括的加载器和主平台支持的标准的多项版本信息之中的至少一项版本信息。
根据实施例，第二SSP 870可以通过第二LBA将SSP信息传输到捆绑包管理服务器850。
在操作8000至8005中，第二LBA 880可以向第二SSP 870请求SSP信息，第二SSP870可以生成其SSP信息，并且第二SSP 870可以通过第二LBA 880将SSP信息传输到捆绑包管理服务器850。然而，根据实施例，第二LBA 880可以自生成SSP信息并将SSP信息传输到捆绑包管理服务器850。
参照图8，在操作8010中，捆绑包管理服务器850可以识别所接收的SSP信息，基于SSP信息生成服务器认证信息(SPBM.Auth2)，并将服务器认证信息传输到第二LBA。
服务器认证信息可以包括以下信息中的至少之一。
a)密钥协议证书(称为SPBM.Cert.KA)，其可用于对SPBM本身和用于验证密钥协议证书所需的证书进行验证。
b)证书信息(称为CiPkIdToBeUsed)，其可以由SPBM用于验证第二SSP。
c)加密算法信息(称为CryptoToBeUsed)，其供SPBM用于执行与第二SSP的加密通信。
根据实施例，捆绑包管理服务器850可以将服务器认证信息传输到第二LBA 880。
参照图8，在操作8015中，第二LBA 880可以将服务器认证信息传输到第二SSP870。第二LBA 880还可以向第二SSP 870传输待接收捆绑包的捆绑包分隔符。
根据实施例，第二SSP 870可以执行以下指定的操作中的至少之一.
a)可以验证SPBM.Cert.KA的有效性。
b)可以选择能够基于所接收的CiPkIdToBeUsed来验证第二SSP的签名证书(ssp2.Cert.DS)中的至少之一。
c)可以识别所接收的CryptoToBeUsed，并且可以生成加密密钥对，即，公共密钥ssp2.ePK.KA和私密密钥ssp2.eSK.KA，该加密密钥对用于生成用于与捆绑包管理服务器进行加密通信的加密密钥。此外，第二SSP可以通过使用ssp2.eSK.KA和包括在SPBM.Cert.KA中的密钥协议公共密钥来生成ShKeyM2，该ShKeyM2是用于与捆绑包管理服务器进行加密通信的会话密钥。
在操作8020中，第二SSP 870可以生成第二终端认证信息(Device2.Auth)，并将第二终端认证信息(Device2.Auth)传输到捆绑包管理服务器850。第二终端认证信息(Device2.Auth)可以包括以下信息中的至少之一。
a)ssp2.Cert.DS
b)ssp2.ePK.KA
c)参考当前会话的事务ID
d)第二SSP 870的SSP ID
e)待接收捆绑包的捆绑包分隔符
可以对第二终端认证信息(Device2.Auth)的一部分或全部进行数字签名，使得可以通过使用ssp2.Cert.DS保证信息的完整性来进行验证，并且可以将数字签名数据添加为第二终端认证信息的一部分。
此外，可以通过使用所生成的会话密钥ShKeyM2对第二终端认证信息(Device2.Auth)的一部分或全部进行编码。
根据实施例，第二SSP 870可以通过第二LBA 880将第二终端认证信息(Device2.Auth)传输到捆绑包管理服务器850。
根据实施例，捆绑包管理服务器850可以执行以下过程中的至少之一。
a)捆绑包管理服务器可以验证包括在第二终端认证信息中的ssp2.Cert.DS的有效性。此外，当第二终端认证信息包括电子签名时，捆绑包管理服务器可以通过使用ssp2.Cert.DS来验证签名的有效性。
b)当第二终端认证信息包括经编码数据时，捆绑包管理服务器可以通过使用ssp2.ePK.KA和与包括在SPBM.Cert.KA中的密钥协议公共密钥对应的私密密钥来生成用于与第二终端进行加密通信的会话密钥ShKeyM2，并且通过使用会话密钥来对经编码数据进行解码。
c)捆绑包管理服务器可以识别和/或存储所接收的事务ID和/或第二SSP的SSPID。
d)捆绑包管理服务器可以识别和/或存储要由第二终端接收的捆绑包的捆绑包分隔符。
根据实施例，捆绑包管理服务器850还可以执行以下过程中的至少之一。
a)捆绑包管理服务器可以通过使用第二SSP的SSP ID来识别是否存在要传输到第二终端的捆绑包。
b)捆绑包管理服务器可以通过使用要由第二终端接收的捆绑包的捆绑包分隔符来识别是否存在要传输到第二终端的捆绑包。
c)当存在要传输到第二终端的捆绑包时，捆绑包管理服务器可以准备捆绑包。(准备好的捆绑包被称为boundSpbImage)
例如，当图7中的从第一终端上传的捆绑包之中存在映射到第二SSP的SSP ID的捆绑包和/或要由第二终端接收的捆绑包的捆绑包分隔符时，可以选择这样的捆绑包。
这里，当所选择的捆绑包不需要再次编码时，捆绑包管理服务器可以准备传输该捆绑包。
或者，当需要通过使用在捆绑包管理服务器和第二终端之间的加密密钥对所选择的捆绑包进行编码时，捆绑包管理服务器可以通过使用ShKeyM2对捆绑包的一部分和/或全部进行编码，然后准备传输捆绑包。
或者，当需要通过使用在捆绑包管理服务器和第二终端之间的加密密钥对所选择的捆绑包进行编码时，捆绑包管理服务器可以生成作为密钥对的公开密钥SPBM.ePK.BT和私密密钥SPBM.eSK.BT，通过使用SPBM.eSK.BT和ssp2.ePK.KA生成加密密钥ShKeyBT，通过使用所述加密密钥对所述捆绑包的所述部分和/或全部进行编码，然后准备传输所述捆绑包。
在操作8025中，捆绑包管理服务器850可以将boundSpbImage传输到第二LBA 880。捆绑包管理服务器850还可以将SPBM.ePK.BT传输到第二LBA 880。捆绑包管理服务器850还可以将ssp1.ePK.BT传输到第二LBA 880。
参照图8，在操作8030中，可以在第二SSP中安装捆绑包。
根据实施例，当通过使用用于在捆绑包管理服务器850和第二终端860之间进行加密的密钥对捆绑包进行编码时，第二SSP 870可以通过使用ShKeyM2对经编码信息进行解码。
根据另一个实施例，当通过使用用于在捆绑包管理服务器850和第二终端860之间进行加密的密钥对捆绑包进行编码时，第二SSP 870可以通过使用SPBM.ePK.BT来生成加密密钥ShKeyBT，然后通过使用加密密钥来对经编码信息进行解码。
根据另一个实施例，当通过使用用于在第一终端和第二终端之间加密的密钥对捆绑包进行编码时，第二SSP 870可以通过使用ssp1.ePK.BT来生成加密密钥ShKeyBT，然后通过使用加密密钥对经编码信息进行解码。
参照图8，在操作8035中，第二SSP 870可以向捆绑包管理服务器850通知安装捆绑包的结果。例如，第二SSP 870可以向捆绑包管理服务器850传输包含安装捆绑包的结果的消息(被称为ssp2.Notification)。
图9是示意性示出根据本公开的实施例的用于从一个终端向另一个终端在线传输捆绑包的过程的另一个示例的示图。
参考图9，终端可以包括至少一个LBA和至少一个SSP。例如，如图9所示，第一终端910可以包括第一LBA 930和第二SSP 920，并且第二终端960可以包括第二LBA 980和第二SSP 970。已经参考图4描述了关于捆绑包管理服务器的细节。
在操作9000中，第一终端910和第二终端960可执行传输捆绑包所需的准备过程(捆绑包传输准备过程)。关于捆绑包传输准备过程的细节将在下面参考图10进行描述。
在操作9005中，第二终端960可以从捆绑包管理服务器950接收捆绑包传输许可。下面将参考图11描述有关相应过程的细节。
在操作9010中，第一终端910可以将要传输到第二终端的捆绑包上传到捆绑包管理服务器950。下面将参考图12描述有关相应过程的细节。
在操作9015中，第二终端960可以从捆绑包管理服务器950下载在操作9010中上传的捆绑包，并安装该捆绑包。下面将参考图13描述有关相应过程的细节。
图10是示出根据本公开的实施例的图9中提出的过程之中的、用于准备传输捆绑包的过程的详细过程的图。
参考图10，终端可以包括至少一个LBA和至少一个SSP。例如，第一终端1010可以包括第一LBA 1030和第一SSP 1020，并且第二终端1060可以包括第二LBA 1080和第二SSP1070。
根据各种实施例，第一终端1010可以包括预装捆绑包，并且还包括与预装捆绑包相关联的元数据。根据各种实施例，第一终端1010可以包括与预装捆绑包相关的捆绑包ID(SPB ID)、FID(SPB族ID)或OID(SPB族托管对象ID)中的至少之一。
根据各种实施例，第一终端1010可以包括与预装捆绑包相关的捆绑包传送配置。已经参考图6描述了关于捆绑包传送配置的细节。
参照图10，在操作10000中，第一LBA 1030可以获得关于要在设备之间传输的捆绑包的信息。或者，可以将关于要在设备之间传输的捆绑包的信息传递到第一LBA。例如，第一LBA可以通过经由第一终端1010所提供的UI接收用户的选择捆绑包的用户输入来获得关于要传输的捆绑包的信息，可以通过来自远程服务器的推送输入将关于要传输的捆绑包的信息输入到第一LBA，或者第一LBA可以通过访问远程服务器来读取关于要传输的捆绑包的信息。
在操作10002中，第一LBA 1030可以通过使用捆绑包传送配置来识别捆绑包在设备之间的传输是否可行。此外，第一LBA 1030可以通过检查捆绑包传送配置来识别捆绑包在设备之间的在线传输是否可行。
在操作10004中，第一LBA 1030可以生成捆绑包传输代码。捆绑包传输代码可以包括要传输的捆绑包的捆绑包分隔符，诸如捆绑包ID(SPB ID)、FID(SPB族ID)或OID(SPB族托管对象ID)。此外，捆绑包传输代码还可以包括指示捆绑包的属性的其它信息(例如，捆绑包的元数据或元数据的一部分)。捆绑包传输代码可以包括与要传输的捆绑包相关联的捆绑包管理服务器的n个地址(SPBM Addr)。
此外，捆绑包传输代码可以包括关于第一终端(例如，第一SSP)所支持的加密算法的信息(SupportedCryptoInfo)。关于由第一终端支持的加密算法的信息可以选择性地包括以下信息中的至少之一：由第一终端支持的椭圆曲线列表、由第一终端支持的密钥协商算法列表、以及由第一终端支持的加密算法列表。
参照图10，在操作10005中，可以将在操作10000中生成的捆绑包传输代码从第一LBA 1030传输到第二LBA 1080。可以经由各种方法中的任何一种来传输捆绑包传输代码。
例如，第一LBA 1030可以通过第一终端的UI向第一终端的第一用户提供要传输到第二LBA 1080的信息。第一用户可以向第二终端的第二用户提供所提供的信息。第二用户可以通过使用第二终端的UI向第二LBA输入所提供的信息。
或者，第一LBA 1030可以生成要被传递到第二LBA 1080的信息的图像(例如，QR代码)，并且在第一终端的屏幕上显示该信息；并且第二用户可以通过使用第二终端来扫描在第一终端的屏幕上显示的图像，并且将该信息传输到第二LBA。
或者，第一LBA 1030可以在第一LBA 1030和第二LBA 1080之间建立连接，并通过使用所建立的连接来传递要传输的信息。这里，第一LBA 1030和第二LBA 1080之间的连接可以是设备之间的直接连接(例如，NFC、蓝牙、UWB、Wi-Fi直连、LTE设备到设备(D2D)或5GD2D)或者其中远程服务器(例如，中继服务器)位于第一LBA1030和第二LBA 1080之间的远程连接。
图11是示出根据本公开的实施例的图9中所提出的过程之中的、接收了捆绑包的终端通过与服务器通信来接收许可的过程的图。
参照图11，终端可以包括至少一个LBA和至少一个SSP。例如，第二终端1160可以包括第二LBA1180和第二SSP 1170。关于捆绑包管理服务器1150的细节已经参考图4进行了描述。
参照图11，在操作11000中，第二LBA 1180可以向第二SSP 1170请求SSP信息(SspInfo)。
当向第二SSP 1170请求SSP信息(SspInfo)时，第二LBA 1180可以通知第二SSP要执行设备之间的捆绑包传送。当向第二SSP 1170请求SSP信息(SspInfo)时，第二LBA 1180可以进一步通知第二SSP要执行设备之间的在线捆绑包传送。例如，请求消息可以包括指示要执行设备之间的捆绑包传送的指示符。作为另一个示例，请求消息可以包括指示要执行设备之间的在线捆绑包传送的指示符。请求消息可以包括指示符或者指示符的值可以被设置为特定值，从而通知第二SSP要执行设备之间的捆绑包传送或者设备之间的在线捆绑包传送。
第二LBA 1180可以向第二SSP 1170提供关于要传输的捆绑包的信息。该信息可以包括FID(SPB族ID)和OID(SPB族托管对象ID)中的至少之一。
参照图11，在操作11005中，第二SSP可以生成其SSP信息(ssp2.SspInfo)，并通过第二LBA 1180将SSP信息传输到捆绑包管理服务器1150。
SSP信息可以包括针对捆绑包传输所要提供的、关于第二SSP的信息。这里，SSP信息可以包括用于供第二SSP 1170执行证书协商过程以与捆绑包管理服务器1150通信的信息(证书协商信息)。证书协商信息可以包括可以被第二SSP 1170用于验证捆绑包管理服务器1150的证书信息和/或可以被捆绑包管理服务器1150用于验证第二SSP 1170的证书信息。此外，证书协商信息还可以包括由第二SSP支持的密钥协商算法的列表，并且还包括由第二SSP支持的加密算法的列表。
SSP信息还可以包括SSP版本信息，该SSP版本信息包括由第二SSP中所包括的加载器和主平台支持的标准的多项版本信息之中的至少一项版本信息。
根据实施例，第二SSP 1170可以通过第二LBA 1180将SSP信息传输到捆绑包管理服务器1150。
根据操作11000和11005，第二LBA可以向第二SSP请求SSP信息，第二SSP可以生成其SSP信息，然后第二SSP可以通过第二LBA向捆绑包管理服务器传输SSP信息。然而，根据实施例，第二LBA可以自生成SSP信息并将SSP信息传输到捆绑包管理服务器。
参照图11，在操作11010中，捆绑包管理服务器1150可以识别所接收的SSP信息，基于SSP信息生成服务器认证信息(SPBM.Auth2)，并将所生成的服务器认证信息传输到第二LBA。
服务器认证信息可以包括以下信息中的至少之一。
a)密钥协议证书(称为SPBM.Cert.KA)，其可用于对SPBM本身和用于验证密钥协议证书所需的证书进行验证。
b)证书信息(称为CiPkIdToBeUsed)，其可以由SPBM用于验证第二SSP。
c)加密算法信息(称为CryptoToBeUsed)，其供SPBM用于执行与第二SSP的加密通信。
根据实施例，捆绑包管理服务器1150可以将服务器认证信息传输到第二LBA1180。
参照图11，在操作11015中，第二LBA 1180可以将服务器认证信息传输到第二SSP1170。第二LBA 1180还可以向第二SSP 1170传输待接收捆绑包的捆绑包分隔符。第二LBA1180还可以向第二SSP1170传输SupportedCryptoInfo。已经参考图10描述了关于SupportedCryptoInfo的细节。
参照图11，在操作11020中，第二SSP 1170可以执行以下指定的操作中的至少之一。
a)可以识别SPBM.Cert.KA的有效性。
b)可以选择能够基于所接收的CiPkIdToBeUsed来验证第二SSP的签名证书(ssp2.Cert.DS)中的至少之一。
c)可以识别所接收的CryptoToBeUsed，并且可以生成加密密钥对，即，公共密钥ssp2.ePK.KA和私密密钥ssp2.eSK.KA，该加密密钥对用于生成用于与捆绑包管理服务器进行加密通信的加密密钥。此外，第二SSP可以通过使用ssp2.eSK.KA和包括在SPBM.Cert.KA中的密钥协议公共密钥来生成ShKeyM2，该ShKeyM2是用于与捆绑包管理服务器进行加密通信的会话密钥。
根据实施例，第二SSP 1170可以生成第二终端认证信息(Device2.Auth)。第二终端认证信息(Device2.Auth)可以包括以下信息中的至少之一。
a)ssp2.Cert.DS
b)ssp2.ePK.KA
c)参考当前会话的事务ID
d)第二SSP的SSP ID
e)第二SSP的部件号ID
f)待接收捆绑包的捆绑包分隔符
根据实施例，第二SSP 1170可识别所接收的SupportedCryptoInfo，并且识别在这之中是否存在第二终端(例如，第二SSP)支持的加密算法。当所接收的SupportedCryptoInfo之中存在第二终端支持的加密算法时，第二SSP 1170可以选择加密算法之一作为所选择的加密算法。所选择的加密算法可以选择性地包括以下信息中的至少之一：椭圆曲线信息、密钥协商算法信息和加密算法信息。
第二SSP 1170可以基于所选择的加密算法生成第二终端的密钥对(临时公共密钥ssp2.ePK.BT和相应的私密密钥ssp2.eSK.BT)，以便稍后用于生成用于与第一终端进行加密通信的加密密钥。第二SSP1170可以将所生成的密钥对映射到所接收的捆绑包ID(SPBID)。第二SSP 1170可以生成所选择的加密信息(ssp2.SelectedCryptoInfo)。所选择的加密信息可以选择性地包括以下信息中的至少之一：所选择的加密算法的一部分和/或全部以及ssp2.eEPK.BT。
为了保证信息的完整性，可以对第二终端认证信息(Device2.Auth)和/或所选择的加密信息(ssp2.SelectedCryptoInfo)的一部分或全部进行数字签名以便可以通过使用ssp2.Cert.DS来被验证，并且可以添加数字签名数据作为第二终端认证信息的一部分。
此外，第二终端认证信息(Device2.Auth)和/或所选择的加密信息(ssp2.SelectedCryptoInfo)的一部分或全部可以通过使用上面生成的会话密钥ShKeyM2来被编码。
在操作11020中，第二SSP 1170可以通过第二LBA 1180将第二终端认证信息(Device2.Auth)和/或所选择的加密信息(ssp2.SelectedCryptoInfo)传输到捆绑包管理服务器1150。
参照图11，在操作11025中，捆绑包管理服务器1150可以执行以下过程中的至少之一。
a)捆绑包管理服务器可以验证包括在第二终端认证信息中的ssp2.Cert.DS的有效性。此外，当第二终端认证信息包括电子签名时，捆绑包管理服务器可以通过使用ssp2.Cert.DS来验证签名的有效性。
b)当第二终端认证信息包括经编码数据时，捆绑包管理服务器可以通过使用ssp2.ePK.KA和与包括在SPBM.Cert.KA中的密钥协议公共密钥对应的私密密钥来生成用于与第二终端进行加密通信的会话密钥ShKeyM2，并且通过使用会话密钥来对经编码数据进行解码。
c)捆绑包管理服务器可以识别和/或存储所接收的事务ID和/或第二SSP的SSPID。
d)捆绑包管理服务器可以识别和/或存储要由第二终端接收的捆绑包的捆绑包分隔符。
根据实施例，捆绑包管理服务器1150还可以执行以下过程中的至少之一。
a)捆绑包管理服务器可以识别要由第二终端接收的捆绑包的捆绑包分隔符，并验证该捆绑包是否是能够在线传输的捆绑包。例如，当捆绑包管理服务器1150通过使用捆绑包的捆绑包传送配置的值来执行验证时，可以执行验证该捆绑包是否是能够在线传输的捆绑包的过程。
b)捆绑包管理服务器可以识别要由第二终端接收的捆绑包是否被正常安装和/或操作在第二终端(例如，第二SSP)中。例如，可以通过使用第二终端的部件号ID(例如，第二SSP)和/或将由第二终端接收的捆绑包的捆绑包分隔符来执行这种识别过程。
根据实施例，捆绑包管理服务器1150可以映射以下各项信息中的一些或全部：第二SSP的SSP ID、待接收捆绑包的捆绑包分隔符以及所选择的加密信息(ssp2.SelectedCryptoInfo)。
在操作11025中，捆绑包管理服务器1150可以向第二LBA 1180传输指示所有过程完成的响应消息。可以省略传输指示所有过程完成的响应消息的过程。
图12是示出根据本公开的实施例的图9中提出的过程之中的、要传输捆绑包的终端将要传输的捆绑包上传到服务器的过程的图。
参考图12，终端可以包括至少一个LBA和至少一个SSP。例如，第一终端1210可以包括第一LBA 1230和第一SSP 1220。关于捆绑包管理服务器1250的细节已经参考图4进行了描述。
参照图12，在操作12000中，第一LBA 1230可以向第一SSP 1220请求SSP信息(SspInfo)。
当向第一SSP请求SSP信息(SspInfo)时，第一LBA可以通知第一SSP要执行设备之间的捆绑包传送。当向第一SSP请求SSP信息(SspInfo)时，第一LBA可以进一步通知第一SSP要执行设备之间的在线捆绑包传送。例如，请求消息可以包括指示要执行设备之间的捆绑包传送的指示符。作为另一个示例，请求消息可以包括指示要执行设备之间的在线捆绑包传送的指示符。请求消息可以包括指示符或者指示符的值可以被设置为1，从而通知第一SSP要执行设备之间的捆绑包传送或者设备之间的在线捆绑包传送。
第一LBA可以向第一SSP提供关于要传输的捆绑包的信息。该信息可以包括FID(SPB族ID)和OID(SPB族托管对象ID)中的至少之一。
参照图12，在操作12005中，第一SSP可以生成其SSP信息(ssp1.SspInfo)，并通过第一LBA 1230将SSP信息传输到捆绑包管理服务器1250。
SSP信息可以包括针对捆绑包传输所要提供的、关于第一SSP的信息。这里，SSP信息可以包括用于供第一SSP执行证书协商过程以与捆绑包管理服务器通信的信息(证书协商信息)。证书协商信息可以包括可以由第一SSP用来验证捆绑包管理服务器的证书信息和/或可以由捆绑包管理服务器用来验证第一SSP的证书信息。此外，证书协商信息还可以包括由第一SSP支持的密钥协商算法的列表，并且还包括由第一SSP支持的加密算法的列表。
SSP信息还可以包括SSP版本信息，该SSP版本信息包括由第一SSP中所包括的加载器和主平台所支持的标准的多项版本信息之中的至少一项版本信息。
根据实施例，第一SSP 1220可以通过第一LBA 1230将SSP信息传输到捆绑包管理服务器1250。
根据操作12000和12005，第一LBA可以向第一SSP请求SSP信息，第一SSP可以生成其SSP信息，然后第一SSP可以通过第一LBA将SSP信息传输到捆绑包管理服务器。然而，根据实施例，第一LBA可以自生成SSP信息并将SSP信息传输到捆绑包管理服务器。
参照图12，在操作12010中，捆绑包管理服务器1250可以识别所接收的SSP信息，基于SSP信息生成服务器认证信息(SPBM.Auth1)，并将服务器认证信息传输到第一LBA 1230。
服务器认证信息可以包括以下信息中的至少之一。
a)密钥协议证书(称为SPBM.Cert.KA)，其可用于对SPBM本身和用于验证密钥协议证书所需的证书进行验证。
b)证书信息(称为CiPkIdToBeUsed)，其可以被SPBM用于验证第一SSP。
c)加密算法信息(称为CryptoToBeUsed)，其供SPBM用于执行与第一SSP的加密通信。
根据实施例，捆绑包管理服务器1250可以将服务器认证信息传输到第一LBA1230。
参照图12，在操作12015中，第一LBA 1230可以将服务器认证信息传输到第一SSP1220。此外，第一LBA 1230还可以向第一SSP1220传输要传输的捆绑包的捆绑包分隔符。
参照图12，在操作12020中，第一SSP 1220可以执行以下指定的操作中的至少之一。
a)可以识别所接收的SPBM.Cert.KA的有效性。
b)可以选择能够基于所接收的CiPkIdToBeUsed来验证第一SSP的签名证书(ssp1.Cert.DS)中的至少之一。
c)可以识别所接收的CryptoToBeUsed，并且可以生成加密密钥对，即，公共密钥ssp1.ePK.KA和私密密钥ssp1.eSK.KA，该加密密钥对被用于生成用于与捆绑包管理服务器进行加密通信的加密密钥。而且，第一SSP可以通过使用ssp1.eSK.KA和包括在SPBM.Cert.KA中的密钥协议公共密钥来生成ShKeyM1，该ShKeyM1是用于与捆绑包管理服务器进行加密通信的会话密钥。
在操作12020中，第一SSP 1220可以生成第一终端认证信息(Device1.Auth)，并将第一终端认证信息(Device1.Auth)传输到捆绑包管理服务器1250。第一终端认证信息(Device1.Auth)可以包括以下信息中的至少之一。
a)ssp1.Cert.DS
b)ssp1.ePK.KA
c)参考当前会话的事务ID
d)第一SSP的SSP ID
e)要传输的捆绑包的捆绑包分隔符
可以对第一终端认证信息(Device1.Auth)的一部分或全部进行数字签名，使得可以通过使用ssp1.Cert.DS保证信息的完整性来进行验证，并且可以将数字签名数据添加为第一终端认证信息的一部分。
此外，可以通过使用所生成的会话密钥ShKeyM1对第一终端认证信息(Device1.Auth)的一部分或全部进行编码。
根据实施例，第一SSP 1220可以通过第一LBA 1230将第一终端认证信息(Device1.Auth)传输到捆绑包管理服务器1250。
参照图12，在操作12025中，捆绑包管理服务器1250可以执行以下过程中的至少之一。(在下文中，一系列这样的过程将被称为过程A)。
a)捆绑包管理服务器可以验证包括在第一终端认证信息中的ssp1.Cert.DS的有效性。此外，当第一终端认证信息包括电子签名时，捆绑包管理服务器可以通过使用ssp1.Cert.DS来验证签名的有效性。
b)当第一终端认证信息包括经编码数据时，捆绑包管理服务器可以通过使用ssp1.ePK.KA和与包括在SPBM.Cert.KA中的密钥协议公共密钥对应的私密密钥来生成用于与第一终端进行加密通信的会话密钥ShKeyM1，并且通过使用会话密钥来对经编码数据进行解码。
c)捆绑包管理服务器可以识别和/或存储所接收的事务ID和/或第一SSP的SSPID。
d)捆绑包管理服务器可以识别和/或存储要由第一终端传输的捆绑包的捆绑包分隔符。
根据实施例，捆绑包管理服务器1250还可以执行以下过程中的至少之一。(在下文中，一系列这样的过程将被称为过程B)。
a)捆绑包管理服务器可以通过使用第一SSP的SSP ID和要由第一终端传输的捆绑包的捆绑包分隔符来验证第一终端(例如，第一SSP)是否是使用当前捆绑包的合法主体。
b)捆绑包管理服务器可以验证要由第一终端传输的捆绑包是否是已经请求和许可捆绑包传输的捆绑包。例如，捆绑包管理服务器可以识别要由第一终端传输的捆绑包的捆绑包分隔符是否是在图11的操作11025中存储的捆绑包分隔符。
在过程A和过程B之间，捆绑包管理服务器1250可以待命(stand)，直到图11中提出的操作完成。换句话说，无论图11中提出的操作是否完成，都可以执行过程A，但是过程B仅在图11中提出的操作完成之后才执行，并且在这种情况下，捆绑包管理服务器可以在执行过程B之前待命，直到图11中提出的操作完成。这种待命过程可以通过下面描述的各种方法中的任何一种来执行。然而，过程的待命不受以下描述的各种方法的限制，并且不一定是以下描述的方法中的一种。
a)捆绑包管理服务器可以向第一LBA传输消息，该消息指示现在已经接收到所请求的操作，但是需要待命直到接收到响应。第一LBA可以待命一段时间，然后将消息传输到捆绑包管理服务器以验证是否已经执行了所请求的操作。当完成了操作的执行时，可以执行过程B。当操作的执行没有完成时，捆绑包管理服务器可以将消息传输到第一LBA，以更长时间地待命。可以重复这样的过程，直到图11中提出的操作完成。
b)捆绑包管理服务器可以在过程A和过程B之间在所确定的时间范围内待命。换句话说，当在执行过程A之后的确定时间内完成图11中提出的操作时，可以执行过程B。当在执行过程A之后的确定时间内没有完成图11中提出的操作时，可以停止捆绑包传输。
c)在执行过程A之后，捆绑包管理服务器可以通知第一LBA现在已经接收到所请求的操作。然后，可以在完成图11中提出的操作之后执行过程B。
在操作12025中，捆绑包管理服务器1250可以生成向第一终端请求捆绑包的消息(spbRequest，这也可以被称为TransferOption)，并且向第一SSP 1220传输请求捆绑包的消息(spbRequest)。捆绑包管理服务器1250还可以向第一SSP 1220传输ssp2.SelectedCryptoInfo。
spbRequest可以包括以下信息中的至少之一。
a)第一SSP的SSP ID
b)第二SSP的SSP ID
c)第一终端要传输的捆绑包的捆绑包分隔符
d)事务ID
包括在spbRequest中的信息的一部分和/或全部可以通过使用ShKeyM1来编码，并且ShKeyM1可以被包括作为spbRequest的一部分。
包括在spbRequest中的信息的一部分和/或全部可以通过使用SPBM.Cert.DS进行电子签名，并且电子签名的值可以被包括作为spbRequest的一部分。在这种情况下，验证SPBM.Cert.DS和SPBM.Cert.DS的有效性所需的一系列信息可以被包括作为spbRequest的一部分。
根据实施例，捆绑包管理服务器1250可以通过第一LBA 1230将spbRequest传输到第一SSP 1220。
根据实施例，捆绑包管理服务器1250还可以通过第一LBA 1230向第一SSP 1220传输ssp2.SelectedCryptoInfo。已经参考图6描述了关于ssp2.SelectedCryptoInfo的细节。
参照图12，在操作12030中，第一SSP 1220可以执行以下过程中的至少之一。
a)当spbRequest包括经编码信息时，通过使用ShKeyM1对经编码信息进行解码。
b)当spbRequest包括电子签名值时，检验SPBM.Cert.DS的有效性，然后使用SPBM.Cert.DS检验电子签名值的有效性。
c)检验包括在spbRequest中的第一SSP的SSP ID和/或第二SSP的SSP ID和/或要由第一终端传输的捆绑包的捆绑包分隔符和/或事务ID是否具有正确的值。
第一SSP 1220可以识别包括在ssp2.SelectedCryptoInfo中的信息。
第一SSP 1220可以配置作为加密密钥对的公共密钥ssp1.ePK.BT和私密密钥ssp1.eSK.BT。根据实施例，加密密钥值的值可以与ssp1.ePK.KA和ssp1.eSK.KA的值相同。
根据实施例，第一SSP 1220可以通过使用所准备的ssp1.eSK.BT和包括在SPBM.Cert.KA中的公共密钥来生成用于与捆绑包管理服务器进行加密通信的密钥ShKeyBT。
根据实施例，第一SSP 1220可以通过使用所准备的ssp1.eSK.BT和ssp2.ePK.BT来生成用于与第二终端进行加密通信的密钥ShKeyBT。
第一SSP 1220可以准备和/或生成要传输到第二终端的捆绑包。可以通过使用ShKeyBT对捆绑包中包括的信息的一部分和/或全部进行编码。准备好的捆绑包可以被称为boundSpbImage。
第一SSP 1220可以提取和/或准备要传输到第二终端的捆绑包的内容的一部分(例如，i)包括在捆绑包中的个人信息；和/或ii)设置值；和/或iii)在捆绑包安装之后执行的更新的一部分和/或全部)。这里，可以通过使用ShKeyBT对信息的一部分和/或全部进行编码。准备好的数据可以被称为boundSpbImageData，或者为了便于描述，被统称为boundSpbImage
第一SSP 1220可以删除要传输到第二终端的捆绑包。
第一SSP 1220可以删除该捆绑包，并生成用于向捆绑包管理服务器1250通知有关删除的信息的令牌(被称为ssp1.Notification)。
在操作12030中，第一SSP 1220可以将boundSpbImage或boundSpbImageData传输到捆绑包管理服务器1250。第一SSP 1220还可以将ssp1.ePK.BT传输到捆绑包管理服务器1250。第一SSP 1220还可以将ssp1.Notification传输到捆绑包管理服务器1250。
参照图12，在操作12035中，捆绑包管理服务器1250可以验证ssp1.Notification，并向第一LBA 1230传输指示所有过程都被执行的响应消息。
当boundSpbImage或boundSpbImageData由通过使用ssp1.eSK.BT和包括在SPBM.Cert.KA中的公开密钥准备的加密密钥编码时，捆绑包管理服务器1250可以通过使用ssp1.ePK.BT和对应于包括在SPBM.Cert.KA中的公开密钥的私密密钥来生成加密密钥ShKeyBT。然后通过使用加密密钥对包括在boundSpbImage或boundSpbImageData中的经编码数据进行解码。
换句话说，可以由捆绑包管理服务器执行以下情形之一。
[情形A]
当捆绑包管理服务器接收到通过利用ssp1.eSK.BT和SPBM.Cert.KA中包括的公共密钥生成的ShKeyBT进行编码的SpbImage时
当捆绑包管理服务器通过使用ShKeyBT执行解码时生成的结果可以被称为经解码的捆绑包。
[情形B]
当捆绑包管理服务器接收到通过利用ssp1.eSK.BT和SPBM.Cert.KA中包括的公开密钥生成的ShKeyBT进行编码的SpbImageData时
当捆绑包管理服务器通过使用ShKeyBT执行解码时生成的结果可以被称为经解码的捆绑包数据。
[情形C]
当捆绑包管理服务器接收到通过利用ssp1.eSK.BT和ssp2.ePK.BT生成的ShKeyBT进行编码的SpbImage时
捆绑包管理服务器可以存储所接收的结果，并且所存储的结果可以被称为所接收的捆绑包。
[情形D]
当捆绑包管理服务器接收到通过利用ssp1.eSK.BT和ssp2.ePK.BT生成的ShKeyBT进行编码的SpbImageData时
捆绑包管理服务器可以存储所接收的结果，并且所存储的结果可以被称为所接收的捆绑包数据。
捆绑包管理服务器1250可以将以下信息的一些或全部相互映射：如上所述的第二SSP的SSP ID、将由第二SSP接收的捆绑包的捆绑包分隔符、以及经解码的捆绑包、经解码的捆绑包数据、所接收的捆绑包和所接收的捆绑包数据。
根据实施例，捆绑包管理服务器1250可以向第一LBA 1230传输指示所有过程都被执行的响应消息。
图13是示出根据本公开的实施例的图9中提出的过程之中的、用于将被上传到服务器的捆绑包下载到要接收捆绑包的终端的过程的图。
参考图13，终端可以包括至少一个LBA和至少一个SSP。例如，第二终端1360可以包括第二LBA 1380和第二SSP 1370。关于捆绑包管理服务器1350的细节已经参考图4进行了描述。
参照图13，在操作13000中，第二LBA 1380可以向捆绑包管理服务器1350请求要接收的捆绑包。该请求可以通过各种方法中的任何一种来执行。例如，第二LBA 1380可以向捆绑包管理服务器1350传输第二终端认证信息(Device2.Auth)。已经参考图11描述了关于第二终端认证信息(Device2.Auth)的细节。
操作13000可由以下过程代替。换句话说，在执行了图11中提出的操作11020之后，第二终端1360可以待命，直到执行下面描述的操作13005。这种待命过程可以通过下面描述的各种方法中的任何一种来执行。然而，待命过程不受其限制，并且不一定是下面描述的方法之一。
a)捆绑包管理服务器1350可以向第二LBA 1380传输指示现在已经接收到所请求的操作的消息，但是需要待命直到接收到响应。第二LBA 1380可以待命一段时间，然后将消息传输到捆绑包管理服务器1350，以验证是否已经执行了所请求的操作。当完成操作的执行时，可以执行操作13005。当操作的执行没有完成时，捆绑包管理服务器1350可以将消息传输到第二LBA 1380，以便更长时间地待命。在这种情况下，第二LBA 1380可以再次待命一段时间，然后再次向捆绑包管理服务器1350传输消息，以验证是否已经执行了所请求的操作。可以重复这样的过程，直到执行操作13005。
b)第二LBA 1380可以待命，直到在确定的时间范围内执行操作13005。当在所确定的时间内没有执行操作13005时，可以停止捆绑包传输。
c)捆绑包管理服务器1350可通知第二LBA 1380已接收到所请求的操作。然后，当准备完成时，可以执行操作13005。
参照图13，在操作13005中，捆绑包管理服务器1350可以执行以下过程中的至少之一。
当在操作13000中捆绑包管理服务器1350已经从第二LBA 1380接收到捆绑包请求消息时，可以执行以下过程。
a)捆绑包管理服务器可以识别所接收的第二终端认证信息是否与在图11的操作11020中接收的第二终端认证信息相同。或者，捆绑包管理服务器可以通过所接收的第二终端认证信息来识别哪个终端请求当前捆绑包。
b)捆绑包管理服务器可以通过使用第二SSP的SSP ID来识别是否存在要传输到第二终端的捆绑包。
c)捆绑包管理服务器可以通过使用将由第二终端接收的捆绑包的捆绑包分隔符来识别是否存在要传输到第二终端的捆绑包。
在操作13005中，捆绑包管理服务器1350可以准备要传输到第二终端1360的捆绑包。换句话说，在以下之中：
-经解码的捆绑包，
-经解码的捆绑包数据，
-所接收的捆绑包，以及
-所接收的捆绑包数据
它们在图12中已准备好，当它们之一被映射到第二SSP的SSP ID和/或要由第二终端接收的捆绑包的捆绑包分隔符时，可以准备要传输到第二终端的捆绑包。该捆绑包可以通过以下方法之一来准备。
[情形A]
当作为图12中提出的过程的结果存在经解码的捆绑包时，捆绑包管理服务器可以通过使用经解码的捆绑包来准备要传输到第二终端的捆绑包。根据实施例，捆绑包管理服务器可以通过使用ShKeyM2对捆绑包的一部分和/或全部进行编码，并且准备传输捆绑包。根据另一个实施例，捆绑包管理服务器可以生成作为密钥对的公开密钥SPBM.ePK.BT和密钥SPBM.eSK.BT，通过使用SPBM.ePK.BT和ssp2.ePK.KA生成加密密钥ShKeyBT，通过使用加密密钥对捆绑包的部分和/或全部进行编码，然后准备所述捆绑包。
[情形B]
当作为图12中提出的过程的结果存在经解码的捆绑包数据时，捆绑包管理服务器可以通过使用经解码的捆绑包数据来准备要传输到第二终端的捆绑包。根据实施例，捆绑包管理服务器可以准备包括经解码的捆绑包数据的一部分的捆绑包。根据另一个实施例，捆绑包管理服务器可以准备要传输到第二终端的捆绑包，然后添加经解码的捆绑包数据作为附加数据。根据实施例，捆绑包管理服务器可以对通过使用ShKeyM2和/或附加数据准备的捆绑包的一部分和/或全部进行编码。根据另一个实施例，捆绑包管理服务器可以生成作为密钥对的公开密钥SPBM.ePK.BT和密钥SPBM.eSK.BT，通过使用SPBM.ePK.BT和ssp2.ePK.KA生成加密密钥ShKeyBT，然后对通过使用加密密钥ShKeyBT和/或附加数据准备的捆绑包的部分和/或全部进行编码。
[情形C]
当作为图12中提出的过程的结果存在所接收的捆绑包时，捆绑包管理服务器可以将所接收的捆绑包准备为要传输到第二终端的捆绑包。
[情形D]
当作为图12中提出的过程的结果存在所接收的捆绑包数据时，捆绑包管理服务器可以通过使用所接收的捆绑包数据来准备要传输到第二终端的捆绑包。根据实施例，捆绑包管理服务器可以生成要传输到第二终端的捆绑包，并将所接收的捆绑包数据添加为附加数据。根据实施例，可以通过使用ShKeyM2对由捆绑包管理服务器生成的捆绑包的一部分和/或全部进行编码。根据另一个实施例，可以通过使用加密密钥ShKeyBT(其是利用由捆绑包管理服务器生成的密钥对SPBM.ePK.BT和SPBM.eSK.BT而生成的)来对由捆绑包管理服务器生成的捆绑包的一部分和/或全部进行编码。
在【情形A】至【情形D】中准备的捆绑包和附加数据可以被称为boundSpbImage。
在操作13005中，捆绑包管理服务器1350可以将boundSpbImage传输到第二LBA1380。捆绑包管理服务器1350还可以将SPBM.ePK.BT传输到第二LBA 1380。捆绑包管理服务器1350还可以将ssp1.ePK.BT传输到第二LBA 1380。
参照图13，在操作13010中，可以将捆绑包安装在第二SSP中。第二SSP 1370和/或第二LBA 1380可以通过使用在操作13005中接收的boundSpbImage来将捆绑包安装在第二SSP 1370中。
根据实施例，当从捆绑包管理服务器1350接收的捆绑包和/或附加数据通过用于在捆绑包管理服务器和第二终端之间加密的密钥进行编码时，第二SSP 1370可以通过使用ShKeyM2来对经编码的信息进行解码。根据另一个实施例，当从捆绑包管理服务器1350接收的捆绑包和/或附加数据通过用于在捆绑包管理服务器和第二终端之间加密的密钥进行编码时，第二SSP 1370可以通过使用SPBM.ePK.BT来生成加密密钥ShKeyBT，然后通过使用加密密钥来对经编码的信息进行解码。
根据另一个实施例，当从捆绑包管理服务器1350接收的捆绑包和/或附加数据通过用于在第一终端和第二终端之间加密的密钥编码时，第二SSP 1370可以通过使用ssp1.ePK.BT来生成加密密钥ShKeyBT，然后通过使用加密密钥来对经编码的信息进行解码。参照图13，在操作13015中，第二SSP 1370可以向捆绑包管理服务器1350通知安装捆绑包的结果。例如，第二SSP 1370可以向捆绑包管理服务器1350传输包含安装捆绑包的结果的消息(被称为ssp2.Notification)。
图14是示出根据本公开的一些实施例的其上安装有SSP的终端的配置的图。
如图4所示，终端可以包括收发器1410和至少一个处理器1420。此外，终端还可以包括SSP 1430。例如，SSP 1430可以被***到终端中或者可以被嵌入到终端中。至少一个处理器1420也可以被称为控制器。然而，终端的配置不限于图14，并且终端可以包括比图14所示的更多或更少的组件。根据一些实施例，收发器1410、至少一个处理器1420和存储器(未示出)可以以一个芯片的形式来实现。此外，当SSP 1430被嵌入时，可以通过进一步包括SSP1430来实现一个芯片。
根据各种实施例，收发器1410可以将根据本公开的各种实施例的信号、信息和数据传输到另一个终端或外部服务器的收发器以及从另一个终端或外部服务器的收发器接收根据本公开的各种实施例的信号、信息和数据。收发器1410可以包括用于对发射信号的频带进行上变频和放大的RF发射器以及用于对接收信号的频带进行低噪声放大和下变频的RF接收器。然而，这仅是收发器1410的实施例，且收发器1410的组件不限于RF发射器和RF接收器。此外，收发器1410可以通过无线信道接收信号并将该信号输出到至少一个处理器1420，并且可以通过无线信道传输从至少一个处理器1420输出的信号。
同时，至少一个处理器1420通常是用于控制终端的组件。至少一个处理器1420可以控制根据上面公开的各种实施例的终端的总体操作。
同时，SSP 1430可以包括用于安装和控制捆绑包的处理器或控制器，或者可以与应用一起安装。此外，根据各种实施例，SSP 1430可以根据处理器1420的控制进行操作。或者，SSP 1430可以包括用于安装和控制捆绑包的处理器或控制器，或者可以与应用一起安装。应用的一部分或全部可以安装在SSP 1430或存储器(未示出)中。
终端还可以包括存储器(未示出)，并且可以存储用于终端的操作的数据，例如基础程序、应用、配置信息等。存储器可以包括闪存类型、硬盘类型、多媒体卡微型类型、卡类型存储器(例如，安全数字(SD)或极限数字(XD)存储器)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)和电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。此外，处理器可以通过使用存储在存储器中的各种程序、内容和数据来执行各种操作。
图15是示出根据本公开的一些实施例的捆绑包管理服务器的配置的图。
根据一些实施例，捆绑包管理服务器可以包括收发器1510和至少一个处理器1520。然而，捆绑包管理服务器的配置不限于图15，并且捆绑包管理服务器可以包括比图15所示的组件更多或更少的组件。
根据一些实施例，收发器1510可以向终端传输根据本公开的各种实施例的信号、信息和数据以及从终端接收根据本公开的各种实施例的信号、信息和数据。收发器1450可以包括用于对发射信号的频带进行上变频和放大的RF发射器以及用于对接收信号的频带进行低噪声放大和下变频的RF接收器。然而，这仅是收发器1510的实施例，且收发器1510的组件不限于RF发射器和RF接收器。此外，收发器1510可以通过无线信道接收信号并将该信号输出到至少一个处理器1520，并且可以通过无线信道传输从至少一个处理器1520输出的信号。
同时，至少一个处理器1520通常是用于控制捆绑包管理服务器的组件。处理器1520可以控制根据上述公开的各种实施例的捆绑包管理服务器的总体操作。至少一个处理器1520也可以被称为控制器。
同时，捆绑包管理服务器还可以包括存储器(未示出)，并且存储器可以存储用于捆绑包管理服务器的操作的数据，例如基础程序、应用、配置信息等。存储器可以包括闪存类型、硬盘类型、多媒体卡微型类型、卡类型存储器(例如，安全数字(SD)或极限数字(XD)存储器)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)和电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。
图16是示出根据本公开的实施例的两个终端和服务器相互操作以使配置文件从一个终端在线传输到另一个终端的方法的示例的图。
如图16所示，第一终端1600和第二终端1620可以分别包括第一eSIM 1603和第二eSIM 1623，并且配置文件(未示出)可以被安装在第一eSIM 1603和第二eSIM 1623中的每一个中。此外，第一LPA 1601和第二LPA 1621可以分别安装在第一终端1600和第二终端1620中。第一eSIM 1603和第二eSIM 1623可以分别由第一LPA 1601和第二LPA 1621控制。第一用户1605和第二用户1625可以分别通过第一LPA 1601和第二LPA 1621控制安装在每个终端的eSIM(第一eSIM1603和第二eSIM 1623)中的配置文件。这里，第一用户1605和第二用户1625可以是同一用户。而且，第一LPA 1601和第二LPA 1621可以彼此连接和通信。这里，下面将参考附图描述连接LPA的可能方法。
第一终端1600的第一LPA 1601可连接到第一RSP服务器1640，且第二终端1620的第二LPA 1621可连接到第二RSP服务器1680。这里，第一RSP服务器1640和第二RSP服务器1680可以是相同的RSP服务器。此外，在图16中，为了方便起见，第一RSP服务器1640和第二RSP服务器1680每个都被示为单个服务器，但是根据实施例，可以在服务器配置中包括一个或更多配置文件提供服务器(SM-DP+)，或者可以在服务器配置中包括帮助在特定配置文件提供服务器和终端之间建立连接的一个或更多订阅中介服务器(SM-DS)。此外，虽然未示出，但是一个或更多RSP服务器和/或中继服务器可以连接在第一RSP服务器1640和第二RSP服务器1680之间。
此外，虽然未示出，但是每个RSP服务器和/或中继服务器可以连接到运营商服务器。此外，当配置中包括一个或更多运营商服务器时，每个运营商服务器可以连接到单独的RSP服务器和/或中继服务器，或者至少一个运营商服务器可以连接到相同的RSP服务器和/或中继服务器。
应当注意，在以下附图中，这种各种服务器配置可以被简化地显示为单个RSP服务器。例如，当一个或更多RSP服务器和/或中继服务器连接在第一终端1600和第二终端1620之间，并且一些或全部RSP服务器和/或中继服务器连接到运营商服务器时，存在于第一终端和第二终端之间的各种服务器配置可以被表示为单个RSP服务器，并且这样的单个RSP服务器在附图和实施例中可以被称为SM-XX。
图17是示出根据本公开的实施例的将配置文件从一个终端在线传输到另一个终端的过程中的前半个过程的图。
尽管在图17中未示出，但是如图16所示那样，第一终端1710和第二终端1750中的每一个都可以包括eUICC和LPA。而且，如图16所示那样，RSP服务器1730可以包括至少一个RSP服务器和/或中继服务器和/或运营商服务器。
尽管在图17中未示出，但是第一终端1710可以包括配置文件传送配置。根据各种实施例，配置文件传送配置是关于在设备之间传送配置文件的可能性的策略，并且可能已经由如上所述的移动运营商、RSP服务器或者移动运营商和RSP服务器的协作生成。根据各种实施例，终端中的配置文件传送配置可由移动运营商、RSP服务器或移动运营商与RSP服务器的协作来更新。或者，可以通过终端与移动运营商和RSP服务器中的至少一个实体的协作来更新配置文件传送配置。用于更新配置文件传送配置的时间点和/或方法可以由移动运营商、RSP服务器或终端制造商的策略来确定。
配置文件传送配置可以包括指示是否允许在设备之间传送配置文件的因子(或指示符)。此外，配置文件传送配置还可以选择性地包括指定允许在设备之间传送配置文件的条件的因子。例如，可以对配置文件是否能够从一个终端在线传输(或传送)到另一个终端进行配置。这种因子可以由RSP服务器、移动运营商、终端制造商、eUICC或eUICC制造商之中的至少一个实体进行电子签名。电子签名的值可以作为配置文件传送配置的一部分或者与配置文件传送配置一起存储在第一终端中。
参照图17，在操作17000中，可以将配置文件传送准备信息从第二终端1750传输到第一终端1710。配置文件传送准备信息可以包括安装在第二终端1750中的eUICC的eUICCID(称为EID)。
配置文件传送准备信息可以包括当第二终端1750与RSP服务器协商证书时使用的证书协商信息。证书协商信息可以是下面描述的第二终端的eUICC2.Info1的部分信息。证书协商信息可以包括关于第二终端的eUICC所支持的版本的信息。证书协商信息可包括可用于验证第二终端的eUICC的证书信息。证书协商信息可包括可用于验证RSP服务器的证书信息。
配置文件传送准备信息可以包括用于确定稍后将从第一终端1710接收的配置文件是否可以正常安装并且可以在第二终端1750的eUICC中操作的信息。该信息可以是以下描述的第二终端的eUICC2.Info2的一部分和/或全部。例如，该信息可以包括安装在第二终端1750中的eUICC的硬件和/或软件信息。例如，该信息可以包括第二终端的硬件和/或软件信息。
配置文件传送准备信息可以包括指示由第二终端1750支持的加密方法的因子。这些因子可以包括由第二终端1750支持的密钥协商算法的列表和/或要用于密钥协议的、第二终端的加密算法和/或公开密钥的列表。
从第二终端1750传送到第一终端1710的信息可以经由各种方法中的任何一种来传输。例如，第二终端可以通过第二终端的UI向第二终端的第二用户提供要传递到第一终端的信息。第二用户可以向第一终端的第一用户提供所提供的信息。第一用户可以通过使用第一终端的UI将所提供的信息输入到第一终端。或者，第二终端可以生成要传递到第一终端的信息的图像(例如，QR代码)并且在第二终端的屏幕上显示该图像，并且第一用户可以扫描在第二终端的屏幕上显示的图像并且将该信息传输到第一终端。然而，将信息从第二终端传递到第一终端的方法不限于上述方法，并且可以被不同地确定。第一用户和第二用户可以表示不同的用户或者可以表示相同的用户。
根据实施例，第一终端1710可通过识别配置文件传送配置来确定配置文件是否可传输。此外，第一终端可以通过识别配置文件传送配置来确定配置文件是否可在线传送。第一终端可以通过识别配置文件传送配置来选择在线传输配置文件。
根据实施例，第一终端1710可以识别所接收的配置文件传送信息。例如，第一终端1710可以验证在配置文件传送信息中所包括的由第二终端1750支持的加密方法之中是否存在自身所支持的加密方法。详细地，第一终端可以从第二终端所支持的密钥协商算法和/或加密算法之中识别是否存在自身所支持的算法。当存在所支持的算法时，第一终端可以选择密钥协商算法和/或加密算法。此外，第一终端可以选择第二终端的公共密钥，以便稍后用于生成加密密钥。
在操作17005中，第一终端1710可以将其eUICC信息(eUICC1.Info1)传输到RSP服务器1730。eUICC1.Info1可以包括由第一终端的eUICC生成的随机字符串(eUICC1.Challenge)。所述eUICC1.Info1可以包括关于由第一终端的eUICC支持的版本的信息。所述eUICC1.Info1可包括可用于验证第一终端的eUICC的证书信息。所述eUICC1.Info1可包括可用于验证RSP服务器的证书信息。所述eUICC1.Info1可以包括由第一终端支持的加密算法的列表。
参照图17，在操作17010中，RSP服务器1730可以识别所接收的eUICC1.Info1并生成RSP服务器认证信息(Server.Auth1)。RSP服务器可以通过使用所接收的eUICC1.Info1，从第一终端所支持的eUICC版本之中识别是否存在自身所支持的版本。RSP服务器可以通过使用所接收的eUICC1.Info1来选择能够验证其自身的证书Server.Cert。RSP服务器可以通过使用所接收的eUICC1.Info1来选择要由第一终端1710使用的证书信息。RSP服务器可以通过使用所接收的eUICC1.Info1来选择在稍后与第一终端进行加密通信期间要使用的加密算法。
根据实施例，RSP服务器1730可以生成RSP服务器认证信息(Server.Auth1)。RSP服务器认证信息(Server.Auth1)可以包括eUICC1.Info1的一部分或全部。例如，RSP服务器认证信息(Server.Auth1)可以包括已经由第一终端1710接收的eUICC1.Challenge。RSP服务器认证信息(Server.Auth1)可以包括由RSP服务器生成的随机字符串(Server.Challenge1)。
RSP服务器认证信息(Server.Auth1)可以包括要由第一终端使用的证书信息。RSP服务器认证信息(Server.Auth1)可以包括与能够由第一终端验证其自身的证书Server.Cert有关的证书链信息。RSP服务器认证信息(Server.Auth1)可以包括稍后在与第一终端的加密通信期间使用的加密算法。
上述的RSP服务器认证信息(Server.Auth1)的一部分或全部可以通过使用RSP服务器的证书Server.Cert进行电子签名，并且这种电子签名的数据可以作为RSP服务器认证信息(Server.Auth1)的一部分被包括。
参照图17，在操作17015中，RSP服务器1730可以将RSP服务器认证信息(Server.Auth1)传输到第一终端1710。
参照图17，在操作17020中，第一终端1710可以验证所接收的RSP服务器认证信息(Server.Auth1)，并且基于验证的结果(例如，当验证成功时)生成第一终端认证信息(Device1.Auth)。第一终端可以验证包括在RSP服务器认证信息(Server.Auth1)中的Server.Cert的有效性，并且还可以通过使用Server.Cert来验证包括在RSP服务器信息(Server.Auth1)中的签名的有效性。第一终端可以验证包括在RSP服务器认证信息(Server.Auth1)中的eUICC1.Challenge的值是否与在操作17005中自身传输的eUICC1.Challenge的值相同。例如，当Server.Cert有效、RSP服务器认证信息(Server.Auth1)中包含的签名有效、并且eUICC1.Challenge的值相同时，验证可能成功。
第一终端可以基于验证的结果(例如，当验证成功时)生成第一终端认证信息(Device1.Auth)。第一终端认证信息(Device1.Auth)可以包括Server.Auth1的一部分或全部。例如，第一终端认证信息(Device1.Auth)可以包括已经由第一终端接收的Server.Challenge1。
第一终端认证信息(Device1.Auth)可以包括安装在第一终端中的eUICC的eUICCID。此外，第一终端认证信息(Device1.Auth)可以包括要传输的配置文件的配置文件分隔符。
第一终端认证信息(Device1.Auth)可以包括与能够验证其自身的证书eUICC1.Cert有关的证书链信息。
此外，第一终端可以选择在操作17000中从第二终端1750接收的配置文件传送准备信息的一部分和/或全部。(在下文中，为方便起见，所选择的信息将被称为传送准备选择信息。)例如，传送准备选择信息可以包括已经从第二终端接收的、当第二终端与第二终端协商证书时使用的证书协商信息，以及用于确定要由第一终端传输的配置文件是否可正常安装并且可在第二终端的eUICC中操作的信息。此外，传送准备选择信息可以包括第二终端的eUICC ID。
可以通过使用第一终端的证书eUICC1.Cert来对上述第一终端认证信息(Device1.Auth)和传送准备选择信息的部分和/或全部进行电子签名。
参照图17，在操作17025中，第一终端1710可以向RSP服务器1730传输在操作17020中生成的第一终端认证信息(Device1.Auth)和/或传送准备选择信息和/或电子签名信息。
参照图17，在操作17030中，RSP服务器1730可以验证所接收的第一终端认证信息(Device1.Auth)。RSP服务器1730可以验证包括在第一终端认证信息(Device1.Auth)中的eUICC1.Cert的有效性，并且通过使用eUICC1.Cert来验证所接收的电子签名的有效性。RSP服务器可以验证包括在第一终端认证信息(Device1.Auth)中的Server.Challenge1的值是否与在操作17015中由其自身传输的Server.Challenge1的值相同。例如，当eUICC1.Cert有效、包括在第一终端认证信息(Device1.Auth)中的签名有效、并且Server.Challenge1的值相同时，验证可以成功。
根据实施例，RSP服务器可以通过使用所接收的第一终端的eUICC ID和配置文件分隔符来验证出第一终端是使用配置文件的终端。
根据实施例，RSP服务器可以识别当第二终端与RSP服务器协商证书时使用的证书协商信息以及用于确定要由第一终端传输的配置文件是否可正常安装并且可在第二终端的eUICC中操作的信息(它们包括在传送准备选择信息中)，以及当第二终端稍后请求要由第一终端上传的配置文件时，验证RSP服务器和第二终端之间的证书协商是否将成功以及配置文件是否将在第二终端中正常运行。
而且，RSP服务器可以存储所接收的配置文件分隔符和第二终端的eUICC ID。
参照图17，在操作17035中，基于确定的结果，RSP服务器1730可以向第一终端1710传输请求配置文件(或配置文件包)的消息。这种请求消息可以包括请求配置文件所需的一系列数据片段。例如，请求消息可以包括要被请求的配置文件的配置文件分隔符。此外，请求消息还可以包括RSP服务器的密钥协议公共密钥。RSP服务器的密钥协议公共密钥可以是临时密钥。
包括在请求消息中的数据的一部分和/或全部可以通过使用RSP服务器的证书服务器来电子签名，并且这样的电子签名数据可以作为请求消息的一部分被包括。
参照图17，在操作17040中，第一终端1710可以识别RSP服务器的所传输的请求消息，并且当对RSP服务器的验证成功时，准备与RSP服务器所请求的配置文件相关的配置文件包。例如，第一终端可以验证包括在RSP服务器的请求消息中的电子签名的有效性。而且，第一终端可以验证包括在RSP服务器的请求消息中的配置文件分隔符是否与要传输的配置文件的分隔符匹配。
当验证成功时，第一终端可以准备与RSP服务器所请求的配置文件相关的配置文件包。配置文件包可以包括要由第一终端传输到第二终端的配置文件信息。
可以对要由第一终端传输到第二终端的配置文件信息的一部分和/或全部进行编码。生成此时使用的加密密钥的方法的一些示例如下。
A)通过使用在操作17035中提供的RSP服务器的密钥协议公共密钥以及由第一终端生成的密钥协议私密密钥来生成加密密钥。
B)通过使用在操作17005中选择的用于生成加密密钥的第二终端的公共密钥以及使用由第一终端生成的私密密钥来生成加密密钥。
配置文件包可包括对应于由第一终端生成的私密密钥的公开密钥。配置文件包可以包括与加密密钥有关的信息，例如，用于生成加密密钥的密钥协商算法和/或用于使用加密密钥的加密算法信息。
配置文件包的内容可以通过第一终端的证书eUICC1.Cert电子签名，并且电子签名的值可以被包括作为配置文件包的一部分。
第一终端可以在生成配置文件包之前禁用要传输的配置文件的状态。
参照图17，在操作17045中，第一终端1710可以将配置文件包传输到RSP服务器1730。
参照图17，在操作17050中，RSP服务器1730可以存储所接收的配置文件包。而且，RSP服务器可以将所接收的配置文件包链接到第二终端的eUICC ID。此外，当在操作17040中使用通过利用服务器的密钥协议公开密钥和第一终端生成的密钥协议密钥而生成的加密密钥进行编码时，RSP服务器可以通过使用服务器的密钥协议公开密钥和与第一终端生成的私密密钥对应的公开密钥生成加密密钥，然后通过使用加密密钥对所接收的配置文件包进行解码。
图18是示出根据本公开的实施例的将配置文件从一个终端在线传输到另一个终端的过程的后半个过程的图。
尽管在图18中未示出，但是第一终端1810和第二终端1850中的每一个都可以在其中包括eUICC和LPA，如图16所示那样。而且，RSP服务器1830可以包括至少一个RSP服务器和/或中继服务器和/或运营商服务器，如图16所示那样。
参照图18，在操作18000中，可以初始化第二终端1850向RSP服务器1830请求配置文件并接收配置文件的过程。这种初始化过程可以通过各种方法中的任何一种方法开始。
例如，请求和接收配置文件的初始化过程可以随着第二终端接收请求配置文件所需的代码(以下称为激活代码)的输入而开始。
这里，输入到第二终端的激活代码可以通过各种方法中的任何一种来输入。例如，第一终端可以生成包括激活代码信息的图像，例如QR代码，并且在第一终端的屏幕上显示该图像，并且第二用户可以通过使用第二终端扫描在第一终端的屏幕上显示的代码，并且因此激活代码可以被输入到第二终端。或者，可以建立第一终端和第二终端之间的连接(此时可能的连接方法可以是设备之间的直接连接(例如NFC、蓝牙、UWB、Wi-Fi直连、LTE D2D或5G D2D)或远程服务器(例如中继服务器)位于第一终端和第二终端之间的远程连接)，并且激活代码可以通过该连接被传输到第二终端。或者，当第二用户通过第二终端提供的UI向第二终端输入激活代码时，激活代码可以被输入到第二终端。或者，激活代码可以随着RSP服务器和/或与RSP服务器相关联的随机服务器将激活代码传输到第二终端而被输入到第二终端。或者，激活代码可以随着第二终端通过访问RSP服务器和/或与RSP服务器相关联的随机服务器来获得激活代码而被输入到第二终端。
激活代码可以包括第二终端的eUICC ID。激活代码可以包括要由第一终端传输的配置文件的配置文件分隔符。激活代码可以包括要由第二终端访问以请求配置文件的RSP服务器的地址。激活代码可以包括由第一终端用来生成加密密钥以对图17中的配置文件进行编码的信息，例如，用于生成加密密钥的密钥协商算法、和/或用于使用加密密钥的加密算法信息、和/或由第一终端用来生成加密密钥的密钥协议公共密钥。
或者，初始化过程可以随着第二终端使用发现服务而启动。例如，初始化过程可以在第二终端通过访问发现服务器来识别事件之后启动，然后识别出配置文件下载事件已经发生。
或者，当RSP服务器向第二终端通知事件已经发生时，初始化过程可以启动。例如，当RSP服务器或与RSP服务器相关联的随机服务器向第二终端通知配置文件下载事件已经发生时，初始化过程可以启动(例如，可以使用服务器的推送服务)。
或者，随着第二用户请求第二终端下载配置文件，初始化过程可以启动。例如，初始化过程可以随着第二用户通过第二终端提供的UI显示下载配置文件的意图而开始，并提供下载配置文件所需的信息。
参照图18，在操作18005中，第二终端1850可以向RSP服务器1830传输其eUICC信息(eUICC2.Info1)。所述eUICC2.Info1可以包括由第二终端的eUICC生成的随机字符串(eUICC2.Challenge)。所述eUICC2.Info1可以包括关于由第二终端的eUICC支持的版本的信息。所述eUICC2.Info1可包括可用于验证第二终端的eUICC的证书信息。所述eUICC2.Info1可以包括可以用于验证RSP服务器的eUICC的证书信息。所述eUICC2.Info1可以包括由第二终端支持的加密算法的列表。
参照图18，在操作18010中，RSP服务器1830可以识别所接收的eUICC2.Info1并生成RSP服务器认证信息(Server.Auth2)。RSP服务器1830可以通过使用所接收的eUICC2.Info1从第二终端支持的eUICC版本之中识别是否存在其自身支持的版本。RSP服务器1830可以通过使用所接收的eUICC2.Info1来选择能够验证其自身的证书Server.Cert。RSP服务器1830可以通过使用所接收的eUICC2.Info1来选择要由第二终端1850使用的证书信息。RSP服务器1830可以通过使用所接收的eUICC2.Info1来选择在稍后与第二终端进行加密通信期间要使用的加密算法。
根据实施例，RSP服务器1830可以生成RSP服务器认证信息(Server.Auth2)。RSP服务器认证信息(Server.Auth2)可以包括eUICC2.Info1的一部分或全部。例如，RSP服务器认证信息(Server.Auth2)可以包括已经接收的eUICC2.Challenge。RSP服务器认证信息(Server.Auth2)可以包括由RSP服务器生成的随机字符串(Server.Challenge2)。
RSP服务器认证信息(Server.Auth2)可以包括用于验证第二终端的证书信息。RSP服务器认证信息(Server.Auth2)可以包括与能够验证其自身的证书Server.Cert相关的证书链信息。RSP服务器认证信息(Server.Auth2)可以包括稍后在与第二终端的加密通信期间使用的加密算法。
上述的RSP服务器认证信息(Server.Auth2)的一部分和/或全部可以通过使用RSP服务器的证书Server.Cert进行电子签名，并且这种经电子签名的数据可以作为RSP服务器认证信息(Server.Auth2)的一部分被包括。
参照图18，在操作18015中，RSP服务器1830可以向第二终端1850传输RSP服务器认证信息(Server.Auth2)。
参照图18，在操作18020中，第二终端1850可以验证所接收的RSP服务器认证信息(Server.Auth2)，并生成第二终端认证信息(Device2.Auth)。第二终端1850可以验证包括在RSP服务器认证信息(Server.Auth2)中的Server.Cert的有效性，并且还可以通过使用Server.Cert来验证包括在RSP服务器认证信息(Server.Auth2)中的签名的有效性。第二终端1850可以验证包括在RSP服务器认证信息(Server.Auth2)中的eUICC2.Challenge的值是否与在操作18005中由自身传输的eUICC2.Challenge的值相同。
第二终端1850可以生成第二终端认证信息(Device2.Auth)。第二终端认证信息(Device2.Auth)可以包括Server.Auth2的一部分或全部。例如，第二终端认证信息可以包括所接收的Server.Challenge2。
第二终端认证信息(Device2.Auth)可以包括用于对安装在第二终端中的eUICC进行资格检查的信息eUICC2.Info2。所述eUICC2.Info2可以是用于确定以后要从第一终端接收的配置文件是否可以正常安装并且可以在第二终端的eUICC中操作的信息。例如，eUICC2.Info2可以包括安装在第二终端上的eUICC的硬件和/或软件信息。或者，eUICC2.Info2可以包括第二终端的硬件和/或软件信息。
第二终端认证信息(Device2.Auth)可以包括安装在第二终端中的eUICC的eUICCID。此外，第二终端认证信息(Device2.Auth)可以包括将由第二终端请求的配置文件的配置文件分隔符。第二终端认证信息(Device2.Auth)可以包括在操作18000中接收的激活代码。
第二终端认证信息(Device2.Auth)可以包括由第二终端的eUICC生成的密钥协议公共密钥。
第二终端认证信息(Device2.Auth)可以包括与能够验证其自身的证书eUICC2.Cert相关的证书链信息。
上述的第二终端认证信息(Device2.Auth)的一部分和/或全部可以通过使用第二终端的证书eUICC2.Cert进行电子签名，并且这种经电子签名的数据可以作为第二终端认证信息(Device2.Auth)的一部分被包括。
参照图18，在操作18025中，第二终端1850可以向RSP服务器1830传输第二终端认证信息(Device2.Auth)。
参照图18，在操作18030中，RSP服务器1830可以验证所接收的第二终端认证信息(Device2.Auth)。RSP服务器1830可以验证包括在第二终端认证信息(Device2.Auth)中的eUICC2.Cert的有效性，并且通过使用eUICC2.Cert来验证包括在第二终端认证信息(Device2.Auth)中的签名的有效性。RSP服务器1830可以验证包括在第二终端认证信息(Device2.Auth)中的Server.Challenge2的值是否与在操作18015中由自身传输的Server.Challenge2的值相同。
RSP服务器1830可以识别用于包括在第二终端认证信息(Device2.Auth)中的eUICC的资格检查(eligibility check)的信息eUICC2.Info2，并且确定要传输的配置文件是否可正常地安装在第二终端中并且可在第二终端中操作。
RSP服务器1830可以识别所接收的第二终端的eUICC ID。RSP服务器可以识别所接收的第二终端的eUICC ID，以识别是否存在要传输的配置文件。RSP服务器可以识别所接收的第二终端的eUICC ID，以准备要传输的配置文件。
RSP服务器1830可以识别所接收的配置文件分隔符。RSP服务器可以识别所接收的配置文件分隔符，以识别是否存在要传输的配置文件。RSP服务器可以识别所接收的配置文件分隔符，以准备要传输的配置文件。
RSP服务器1830可以识别所接收的激活代码。RSP服务器可以识别包括在所接收的激活代码中的第二终端的eUICC ID。RSP服务器可以识别包括在所接收的激活代码中的第二终端的eUICC ID，以识别是否存在要传输的配置文件。RSP服务器可以识别包括在所接收的激活代码中的第二终端的eUICC ID，以准备要传输的配置文件。RSP服务器可以识别包括在所接收的激活代码中的配置文件分隔符。RSP服务器可以识别包括在所接收的激活代码中的配置文件分隔符，以识别是否存在要传输的配置文件。RSP服务器可以识别包括在所接收的激活代码中的配置文件分隔符，以准备要传输的配置文件。
RSP服务器1830可以通过使用所接收的由第二终端的eUICC生成的密钥协议公共密钥以及由RSP服务器生成的密钥协议私密密钥来生成用于编码的加密密钥。RSP服务器1830可以通过使用加密密钥对要传输的配置文件进行编码。
在操作18030中，RSP服务器可以准备与第二终端1850所请求的配置文件相关的配置文件包。配置文件包可以包括要由RSP服务器传输到第二终端的配置文件信息。
配置文件包可以包括由第一终端用来生成加密密钥以对图17中的配置文件进行编码的信息，例如，用于生成加密密钥的密钥协商算法、和/或用于使用加密密钥的加密算法信息、和/或由第一终端用来生成加密密钥的密钥协议公共密钥。
配置文件包可以包括由RSP服务器用来生成加密密钥以对配置文件进行编码的信息，例如，用于生成加密密钥的密钥协商算法、和/或用于使用加密密钥的加密算法信息、和/或由RSP服务器用来生成加密密钥的密钥协议公共密钥。
配置文件包的内容可以由RSP服务器的证书服务器进行电子签名，并且电子签名的值可以被包括作为配置文件包的一部分。
参照图18，在操作18035中，RSP服务器1830可以将配置文件包传输到第二终端1850。
参照图18，在操作18040中，第二终端1850可以安装所接收的配置文件包。这里，当配置文件包的部分和/或全部内容由第一终端编码时，第二终端可以通过使用所接收的第一终端的密钥协议公共密钥和第二终端的密钥协议私密密钥来生成加密密钥，然后对经编码的内容进行解码。这里，当RSP服务器对配置文件包的部分和/或全部内容进行编码时，第二终端可以通过使用所接收的RSP服务器的密钥协议公共密钥和第二终端的密钥协议私密密钥来生成加密密钥，然后对经编码的内容进行解码。
图19是示出根据本公开的一些实施例的其上安装有eUICC的终端的配置的图。
参考图19，终端可以包括收发器1910、处理器1920和eUICC1930。在本公开中，上面描述的一些终端可以对应于图19中描述的终端。例如，图16至图18中描述的第一终端和第二终端可以各自包括图19中描述的终端的配置。
然而，终端的配置不限于图19，并且终端可以包括比图19所示的更多或更少的组件。根据一些实施例，收发器1910、处理器1920和eUICC 1930可以以一个芯片的形式来实现。此外，终端还可以包括存储器，并且处理器1920可以被配置成至少一个处理器。
根据各种实施例，收发器1910可以将根据本公开的各种实施例的信号、信息和数据传输到另一个终端或外部服务器的收发器和从另一个终端或外部服务器的收发器接收信号、信息和数据。收发器1910可以包括对发射信号的频带进行上变频和放大的RF发射器以及用于对接收信号的频带进行放大低噪声和下变频的RF接收器。然而，这仅是收发器1910的实施例，且收发器1910的组件不限于RF发射器和RF接收器。此外，收发器1910可以在无线信道上接收信号并将该信号输出到处理器1920，或者在无线信道上传输从处理器1920输出的信号。
同时，处理器1920通常是用于控制终端的组件。处理器1920可以控制根据上述公开的各种实施例的终端的总体操作。
终端还可以包括存储器(未示出)，并且可以存储用于终端的操作的数据，例如基础程序、应用程序、配置信息等。存储器可以包括闪存类型、硬盘类型、多媒体卡微型类型、卡类型存储器(例如，安全数字(SD)或极限数字(XD)存储器)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)和电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。此外，处理器1920可以通过使用存储在存储器中的各种程序、内容和数据来执行各种操作。
图20是示出根据本公开的一些实施例的RSP服务器的配置的图。
参照图20，服务器可以包括收发器2010和处理器2020。在本公开中，上面描述的一些服务器可以对应于图20中描述的服务器。例如，图16至图18中描述的服务器可以包括图20中描述的服务器的配置。
然而，服务器的配置不限于图20，并且服务器可以包括比图20所示的组件更多或更少的组件。根据一些实施例，收发器2010和处理器2020可以以一个芯片的形式来实现。此外，服务器还可以包括存储器，并且处理器2020可以被配置成至少一个处理器。
根据一些实施例，收发器2010可以将根据本公开的各种实施例的信号、信息和数据传输到终端和从终端接收信号、信息和数据。收发器2010可以包括用于对发射信号的频带进行上变频和放大的RF发射器以及用于对接收信号的频带进行放大低噪声和下变频的RF接收器。然而，这仅是收发器2010的实施例，且收发器2010的组件不限于RF发射器和RF接收器。此外，收发器2010可以在无线信道上接收信号并将该信号输出到处理器2020，或者在无线信道上传输从处理器2020输出的信号。
同时，至少一个处理器2020通常是用于控制服务器的组件。处理器2020可以根据上述公开的各种实施例来控制服务器的总体操作。至少一个处理器2020也可以被称为控制器。
同时，服务器还可以包括存储器(未示出)，并且存储器可以存储用于服务器的操作的数据，例如基础程序、应用程序、配置信息等。存储器可以包括闪存类型、硬盘类型、多媒体卡微型类型、卡类型存储器(例如，安全数字(SD)或极限数字(XD)存储器)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)和电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。此外，处理器2020可以通过使用存储在存储器中的各种程序、内容和数据来执行各种操作。
图21是示意性示出说明根据本公开的实施例的用于将配置文件从一个终端在线传输到另一个终端的过程的另一个示例的图。
参考图21，终端可以包括至少一个LPA和至少一个eSIM。例如，如图16所示，第一终端2110可以包括第一LPA 2130和第二eSIM2120，并且第二终端2160可以包括第二LPA 2180和第二eSIM 2170。上面已经描述了关于RSP服务器的细节(例如，在图16中)。
在操作21000中，第一终端2110和第二终端2160可执行传输配置文件所需的准备过程(配置文件传输准备过程)。下面将参考图22描述关于配置文件传输准备过程的细节。
在操作21005中，第二终端2160可以请求RSP服务器2150传输配置文件。下面将参考图23描述有关相应过程的细节。
在操作21010中，第一终端2110可以将要传输到第二终端的配置文件上传到RSP服务器2150。下面将参考图24描述有关相应过程的细节。
在操作21015中，第二终端2160可以从RSP服务器2150下载在操作21010中上传的配置文件，并安装该配置文件。下面将参考图25描述有关相应过程的细节。
图22是示出根据本公开的实施例的准备传输配置文件的过程的详细过程的图。
参考图22，终端可以包括至少一个LPA和至少一个eSIM。例如，第一终端2210可以包括第一LPA 2230和第一eSIM 2220，并且第二终端2260可以包括第二LPA 2280和第二eSIM 2270。
根据各个实施例，第一终端2210可以包括预装配置文件，并且还包括与预装配置文件相关联的元数据。根据各种实施例，第一终端2210可包括与预装配置文件相关的配置文件分隔符。
根据各种实施例，第一终端2210可包括与预装配置文件相关的配置文件传送配置。根据各种实施例，配置文件传送配置是与设备之间的配置文件传送相关的一系列策略，并且可能已经由如上所述的移动运营商、RSP服务器、或者移动运营商和RSP服务器的协作生成。根据各种实施例，终端中的配置文件传送配置可由移动运营商、RSP服务器、或者移动运营商与RSP服务器的协作来更新。或者，可以通过终端与移动运营商和RSP服务器之中的至少一个实体的协作来更新配置文件传送配置。用于更新配置文件传送配置的时间点和/或方法可以由移动运营商、RSP服务器或终端制造商的策略来确定。
配置文件传送配置可以包括指示是否允许在设备之间传送配置文件的因子(或指示符)。此外，配置文件传送配置还可以选择性地包括指定允许在设备之间传送配置文件的条件的因子。例如，可以在配置文件传送配置中对配置文件是否能够从一个终端在线传输(或传送)到另一个终端进行配置。作为另一个示例，可以在配置文件传送配置中对用于传送配置文件的格式进行配置。例如，可以以配置文件包的形式或以配置文件图像的形式传输配置文件，或者可以传输配置文件的仅部分数据(例如，可以表示在配置文件被安装在第一终端中之后发生的一系列更新的一部分或全部。所述更新可以包括由用户存储的数据、由用户设置的值、或者关于由移动运营商或RSP服务器执行的更新的细节)。配置文件传送配置可以包括关于从上述配置文件的可能传输格式中允许哪种(或哪些)的信息。这种因子可以由RSP服务器、移动运营商、终端制造商、eUICC或eUICC制造商中的至少一个实体进行电子签名。电子签名的值可以作为配置文件传送配置的一部分或者与配置文件传送配置一起存储在第一终端中。
参照图22，在操作22000中，第一LPA 2230可以获得关于要传输的配置文件的信息。或者，可以将关于要传输的配置文件的信息传递到第一LPA 2230。例如，第一LPA 2230可以通过接收用户经由第一终端2210提供的UI选择配置文件的用户输入来获得关于要传输的配置文件的信息。或者，可以通过来自远程服务器的推送输入将关于要传输的配置文件的信息输入到第一LPA 2230，或者第一LPA 2230可以通过访问远程服务器来读取关于要传输的配置文件的信息。然而，第一LPA 2230获得关于要传输的配置文件的信息的方法不限于此。
参照图22，在操作22005中，第一LPA 2230可通过使用配置文件传送配置来识别配置文件是否可传输。此外，第一LPA 2230可以通过检查配置文件传送配置来识别配置文件的在线传输是否可行。而且，第一LPA 2230可以通过检查配置文件传送配置来识别用于传送配置文件的格式(例如，配置文件图像、配置文件包或配置文件的部分数据)。
参照图22，在操作22010中，第一LPA 2230可以生成配置文件传输代码。配置文件传输代码可以包括要传输的配置文件的配置文件分隔符。此外，配置文件传输代码可以包括与要传输的配置文件相关的RSP服务器的地址。(稍后，第二终端2260可通过使用所述地址访问RSP服务器来下载配置文件。)此外，配置文件传输代码还可以包括指示配置文件的属性的其它信息(例如，配置文件的元数据或元数据的一部分)。此外，配置文件传输代码可以包括关于第一终端(例如，第一eSIM)所支持的加密算法的信息(SupportedCryptoInfo)。关于由第一终端支持的加密算法的信息可以选择性地包括以下信息中的至少之一：由第一终端支持的椭圆曲线列表、由第一终端支持的密钥协商算法列表、以及由第一终端支持的加密算法列表。
参照图22，在操作22015中，在操作22010中生成的配置文件传输代码可以从第一LPA 2230传输到第二LPA 2280。可以经由各种方法中的任何一种来传输配置文件传输代码。
例如，第一LPA 2230可以通过第一终端的UI向第一终端的第一用户提供要传输到第二LPA 2280的信息。第一用户可以向第二终端的第二用户提供所提供的信息。第二用户可以通过使用第二终端的UI向第二LPA输入所提供的信息。
或者，第一LPA 2230可以生成要传递到第二LPA 2280的信息的图像(例如，QR代码)，并且在第一终端的屏幕上显示该信息，并且第二用户可以通过使用第二终端扫描在第一终端的屏幕上显示的图像，并且将该信息传输到第二LPA。
或者，第一LPA 2230可以在第一LPA 2230和第二LPA 2280之间建立连接，并通过使用所建立的连接来传输要传输的信息。这里，在第一LPA 2230和第二LPA 2280之间建立的连接可以是设备之间的直接连接(例如，诸如NFC、蓝牙、UWB、Wi-Fi直连、LTE设备到设备(D2D)或5G D2D之类的无线连接，或者诸如电缆连接之类的有线连接)，或者其中远程服务器(例如，中继服务器)位于第一LPA 2230和第二LPA 2280之间的远程连接。
图23是示出根据本公开的实施例的第二终端2360通过其请求RSP服务器2350传输配置文件的过程的图。
参考图23，终端可以包括至少一个LPA和至少一个eSIM。例如，第二终端2360可以包括第二LPA 2380和第二eSIM 2370。已经参考图16描述了关于RSP服务器2350的细节。
参照图23，在操作23000中，可以在第二终端2360和RSP服务器2350之间执行相互认证。这样的相互认证过程可以包括以下过程中的至少之一。
-相互认证过程可以包括要被执行以便用于在第二终端和RSP服务器之间通信的证书协商过程。例如，第二终端可以向RSP服务器传输可以用于验证RSP服务器的多条证书信息和/或可以由RSP服务器用来验证第二终端的多条证书信息。在接收到这样的信息时，RSP服务器可以选择可以由第二终端用来验证RSP服务器的证书信息和由RSP服务器用来验证第二终端的证书信息。这里，由RSP服务器选择的多条证书信息可以被传输到第二终端。通过这样的过程，第二终端和RSP服务器可以获得用于相互验证的证书信息。这里，证书信息可以表示证书和/或包括在证书中的信息和/或可以引用证书的一系列信息。
-第二终端可以向RSP服务器传输自身生成的随机数(eUICC Challenge)的值。RSP服务器可以对所接收的值或随机数进行电子签名，并将签名的值传输到第二终端。第二终端可以验证所接收的签名的值以认证RSP服务器。
-RSP服务器可以向第二终端传输自身生成的随机数(server Challenge)的值。第二终端可以对所接收的值或随机数进行电子签名，并将签名的值传输到RSP服务器。RSP服务器可以验证所接收的签名的值以认证第二终端。
-当RSP服务器和第二终端彼此通信时，可以交换用于管理会话的ID(事务ID)。例如，RSP服务器可以生成事务ID，并将其值传输到第二终端。这里，RSP服务器的电子签名的值可以被添加以识别事务ID的可靠性和完整性。
-RSP服务器和第二终端可以交换与本公开中要传输的配置文件相关联的配置文件分隔符。例如，第二终端可以向RSP服务器传输要被接收的配置文件的分隔符。这里，配置文件分隔符可以与第二终端的电子签名值一起被传输，以保证可靠性和完整性。
-RSP服务器和第二终端可以交换彼此的ID。例如，RSP服务器可以向第二终端提供其对象标识符(OID)。作为另一个示例，第二终端可以将其eUICC ID提供给RSP服务器。
参照图23，可以在操作23005中执行以下过程。
RSP服务器2350可以识别配置文件传送配置。例如，RSP服务器2350可以识别所接收的配置文件分隔符，并通过检查与配置文件相关联的配置文件传送配置来识别配置文件的传输是否可行。而且，RSP服务器2350可以通过检查配置文件传送配置来识别配置文件的在线传输是否可行。而且，RSP服务器2350可以通过检查配置文件传送配置来识别用于传输配置文件的格式(例如，配置文件图像、配置文件包或配置文件的部分数据)。
RSP服务器2350可以执行资格检查以识别配置文件是否能够在第二终端中安装和使用。例如，RSP服务器2350可以通过使用所接收的第二终端的eUICC ID和所接收的配置文件分隔符来检查配置文件是否能够在第二终端中安装和操作。
RSP服务器2350可以响应于第二终端的配置文件接收请求而生成传送选项。传送选项可包括关于配置文件是否可传输到第二终端的信息，以及当传输可行时，关于传输类型的信息。例如，传送选项可以包括以下值中的至少之一。
-配置文件可以以配置文件图像的形式传输
-配置文件可以以配置文件包的形式传输
-配置文件的部分数据是可传输的
-配置文件的传输不可行
RSP服务器2350可以向第二LPA 2380传输传送选项。这里，传送选项可以由RSP服务器2350进行电子签名。电子签名的值可以与传送选项一起被传输到第二LPA 2380。此外，RSP服务器的证书和相关信息(包括用于电子签名的加密密钥)可以被传输到第二LPA2380。
参照图23，可以在操作23010中执行以下过程。
第二LPA 2380可以识别所接收的传送选项并获得用户的同意。
第二LPA 2380可以将所接收的传送选项传输到第二eSIM 2370。第二LPA 2380可以向第二eSIM 2370传输所接收的传送选项的签名的值。第二LPA 2380可以向第二eSIM2370传输证书和相关信息，该证书和相关信息用于验证所接收的传送选项的电子签名的值。
第二LPA 2380可以选择性地进一步向第二eSIM 2370传输在操作22015中接收的SupportedCryptoInfo。
参照图23，可以在操作23015中执行以下过程。
第二eSIM 2370可以验证在操作23010中接收的证书和相关信息的有效性。
第二eSIM 2370可以验证在操作23010中接收的电子签名的值的有效性。
第二eSIM 2370可以识别在操作23010中接收的传送选项的细节。
当接收到SupportedCryptoInfo时，第二eSIM 2370可以识别所所接收的SupportedCryptoInfo的细节，并且识别自身所支持的加密算法是否存在于其中。当第二eSIM所支持的加密算法存在于所接收的SupportedCryptoInfo之中时，第二eSIM 2370可以选择加密算法之一作为所选择的加密算法(SelectedCryptoInfo)。所选择的加密算法可以选择性地包括以下信息中的至少之一：椭圆曲线信息、密钥协商算法信息和加密算法信息。
第二eSIM 2370可以生成公开密钥otPK.EUICC.KA和私密密钥otSK.EUICC.KA，它们是用于加密的密钥对，该密钥对用于生成用于加密通信的加密密钥。这里，所生成的加密密钥可以用于RSP服务器和第二终端之间的加密通信，或者用于第一终端和第二终端之间的加密通信。这里，当所生成的加密密钥用于第一终端和第二终端之间的加密通信时，加密密钥(otPK.EUICC.KA和otSK.EUICC.KA)可以是遵循SelectedCryptoInfo中所包括的加密算法的加密密钥。
第二eSIM 2370可以将生成的otPK.EUICC.KA传输到RSP服务器2350。加密密钥可以由第二eSIM电子签名。由第二eSIM生成的电子签名的值可以被传输到RSP服务器。加密密钥和/或电子签名的值可以被称为Device2.Auth。
第二eSIM 2370还可以选择性地通过第二LPA 2380向RSP服务器2350传输所选择的加密信息。
图24是示出根据本公开的实施例的第一终端2410将要传输到第二终端的配置文件上传到RSP服务器2450的过程的图。
参考图24，终端可以包括至少一个LPA和至少一个eSIM。例如，第一终端2410可以包括第一LPA 2430和第一eSIM 2420。已经参考图16描述了关于RSP服务器2450的细节。
参照图24，在操作24000中，可以在第一终端2410和RSP服务器2450之间执行相互认证。这样的相互认证过程可以包括以下过程中的至少之一。
-相互认证过程可以包括要被执行以用于在第一终端2410和RSP服务器2450之间通信的证书协商过程。例如，第一终端2410可以向RSP服务器2450传输可以用于验证RSP服务器2450的多条证书信息和/或可以由RSP服务器2450用于验证第一终端2410的多条证书信息。在接收到这样的信息时，RSP服务器2450可以选择要由第一终端2410使用以验证RSP服务器2450的多条证书信息以及要由RSP服务器2450使用以验证第一终端2410的多条证书信息。这里，由RSP服务器2450选择的各条证书信息可以被传输到第一终端2410。通过这样的过程，第一终端2410和RSP服务器2450可以获得用于相互验证的证书信息。这里，证书信息可以表示证书、和/或包括在证书中的信息、和/或可以引用证书的一系列信息。
-第一终端2410可以向RSP服务器2450传输自身生成的随机数(eUICC Challenge)的值。RSP服务器2450可以对所接收的值或随机数进行电子签名，并将签名的值传输到第一终端2410。第一终端2410可验证所接收的签名的值以认证RSP服务器2450。
-RSP服务器2450可以向第一终端2410传输自身生成的随机数(serverChallenge)的值。第一终端2410可对所接收的值或随机数进行电子签名，并将签名的值传输到RSP服务器2450。RSP服务器2450可以验证所接收的签名的值以认证第一终端2410。
-当RSP服务器2450和第一终端2410彼此通信时，可以交换用于管理会话的ID(事务ID)。例如，RSP服务器2450可以生成事务ID，并将其值传输到第一终端2410。这里，RSP服务器的电子签名的值可以被添加以识别事务ID的可靠性和完整性。
-RSP服务器2450和第一终端2410可以交换与本公开中要传输的配置文件相关联的配置文件分隔符。例如，第一终端2410可以向RSP服务器2450传输要传输的配置文件的分隔符。这里，配置文件分隔符可以与第一终端2410的电子签名的值一起被传输，以保证可靠性和完整性。
-RSP服务器2450和第一终端2410可以相互交换ID。例如，RSP服务器2450可以向第一终端2410提供其对象标识符(OID)。作为另一个示例，第一终端2410可以将其eUICC ID提供给RSP服务器2450。
虽然未示出，但是第一终端2410可以在操作24000和24005之间待命。
参照图24，可在操作24005中执行以下过程。
RSP服务器2450可以生成公共密钥otPK.DP.KA和私密密钥otSK.DP.KA，它们是用于加密的密钥对，该密钥对用于生成用于与第一eSIM 2420进行加密通信的加密密钥。
RSP服务器2450可以通过第一LPA 2430向第一eSIM 2420传输公开密钥otPK.XX.KA。这里，otPK.XX.KA可以是在操作23015中接收的otPK.EUICC.KA或者是otPK.DP.KA。
RSP服务器2450可以通过第一LPA 2430向第一eSIM 2420传输传送选项。传送选项可包括关于配置文件是否可传输到第二终端的信息，以及当传输可行时，关于传输类型的信息。例如，传送选项可以包括以下值中的至少之一。
-配置文件可以以配置文件图像的形式传输
-配置文件可以以配置文件包的形式传输
-配置文件的部分数据是可传输的
-配置文件的传输不可行
这里，传输到第一eSIM 2420的otPK.XX.KA和/或传送选项可以由RSP服务器2450电子签名。可以通过第一LPA 2430将电子签名的值传输到第一eSIM 2420。此外，可用于验证电子签名的、RSP服务器的证书和相关信息可通过第一LPA 2430传输到第一eSIM 2420。
RSP服务器2450还可以选择性地通过第一LPA 2430将在操作23015中接收的SelectedCryptoInfo传输到第一eSIM 2420。
第一终端2410(例如，第一LPA 2430)可接收与所接收的传送选项有关的终端用户许可。
参照图24，可在操作24010中执行以下过程。
第一eSIM 2420可以验证在操作24005中接收的证书和相关信息的有效性。
第一eSIM 2420可以验证在操作24005中接收的电子签名的值的有效性。
第一eSIM 2420可以识别在操作24005中接收的传送选项的细节。
第一eSIM 2420可以生成公开密钥otPK.EUICC.KA和密钥otSK.EUICC.KA，它们是用于加密的密钥对，该密钥对用于生成用于加密通信的加密密钥。这里，所生成的加密密钥可以用于RSP服务器和第一终端之间的加密通信，或者用于第一终端和第二终端之间的加密通信。可以基于在操作24005中接收的otPK.XX.KA的值来确定针对哪个加密通信使用所生成的加密密钥。第一eSIM 2420可以计算所生成的otPK.EUICC.KA的电子签名的值。otPK.EUICC.KA和/或电子签名的值可以统称为Device1.Auth。
第一eSIM 2420可以通过使用自身生成的otSK.EUICC.KA和在操作24005中接收的otPK.XX.KA来生成用于加密通信的会话密钥。
第一eSIM 2420(在必要时，借助于第一LPA)可以准备要传输到第二终端的配置文件。这里，准备好的配置文件的格式可以与在操作24005中接收的传送选项相匹配。换句话说，准备好的配置文件的格式可以是以下之一。
-配置文件图像
-配置文件包
-配置文件的部分数据
准备好的配置文件中的全部和/或部分可以由会话密钥编码。而且，准备好的配置文件中的全部和/或部分可以由第一终端进行电子签名，并且电子签名的值可以被包括作为准备好的配置文件的一部分。
第一eSIM 2420可以删除配置文件。是否删除配置文件可以被通知给RSP服务器2450。
第一eSIM 2420可以通过第一LPA 2430向RSP服务器2450传输Device1.Auth和/或准备好的配置文件。
参照图24，在操作24015中，RSP服务器2450可以向第一LPA2430传输指示所有过程都被执行的响应消息。
图25是示出根据本公开的实施例的第二终端2560通过其下载从RSP服务器2550上传的准备好的配置文件并安装准备好的配置文件的过程的图。
参考图25，终端可以包括至少一个LPA和至少一个eSIM。例如，第二终端2560可以包括第二LPA 2580和第二eSIM 2570。已经参考图16描述了关于RSP服务器2550的细节。
虽然未示出，但是在执行图23中提出的操作23015之后，第二终端2560可以待命，直到执行下面描述的操作25000。这种待命过程可以通过下面描述的各种方法中的任何一种来执行。然而，待命过程不受其限制，并且不一定是下面描述的方法之一。
a)RSP服务器2550可以向第二LPA 2580传输消息，该消息指示现在已经接收到所请求的操作，但是需要待命直到接收到响应。第二LPA 2580可以待命一段时间，然后向RSP服务器2550传输消息以验证是否已经执行了所请求的操作。当完成了操作的执行时，可以执行操作25000。当操作的执行未完成时，RSP服务器2550可以传输指示待命稍微更长时间的消息。在这种情况下，第二LPA 2580可以再次待命一段时间，然后再次向捆绑包管理服务器传输消息，以验证是否已经执行了所请求的操作。可以重复这样的过程，直到执行操作25000。
b)第二LPA 2580可以待命，直到在确定的时间范围内执行操作25000。当在所确定的时间内没有执行操作25000时，可以停止配置文件传输。
c)RSP服务器2550可通知第二LPA 2580已接收到所请求的操作。(例如，RSP服务器可以向第二LPA传输推送消息。)然后，可以执行操作25000。
参照图25，可以在操作25000中执行以下过程。
RSP服务器2550可以验证在操作23015接收的Device2.Auth的电子签名值的有效性。
RSP服务器2550可以识别在操作23015中接收的Device2.Auth的细节。
RSP服务器2550可以生成公开密钥otPK.DP.KA和密钥otSK.DP.KA，它们是用于加密的密钥对，该密钥对用于生成用于加密通信的加密密钥。这里，所生成的加密密钥可以用于RSP服务器和第二终端之间的加密通信。RSP服务器可以通过使用所生成的用于加密的密钥对来生成用于与第二终端进行加密通信的会话密钥。
RSP服务器2550可以准备要传输到第二终端的绑定配置文件。
这里，准备好的绑定配置文件可以是下列格式之一。
-在操作24010中接收的配置文件图像
-在操作24010中接收的配置文件包
-通过包括在操作24010中接收的配置文件的部分数据而生成的配置文件包和/或图像
-包括在操作24010中接收的配置文件的部分数据作为附加数据的配置文件包或图像
当在操作24010中接收的数据通过用于第一终端和RSP服务器之间的加密通信的会话密钥被编码时，可以另外执行以下过程。RSP服务器可以对所接收的数据进行解码。RSP服务器可以通过会话密钥对经解码的数据进行编码，以便在第二终端和RSP服务器之间进行加密通信。
RSP服务器2550可以将绑定配置文件传输到第二LPA 2580。
参照图25，可以在操作25005中执行以下过程。
第二LPA 2580可验证所接收的绑定配置文件。例如，第二LPA2580可以识别和验证包括在绑定配置文件中的元数据的细节。此外，第二LPA 2580可以接收与绑定配置文件有关的终端用户许可。
第二LPA 2580和第二eSIM 2570可以将所接收的绑定配置文件安装在第二eSIM中。
参照图25，在操作25010中，第二eSIM 2570可以通过第二LPA2580通知RSP服务器2550安装了配置文件。
在本公开的上述实施例中，包括在本公开中的元件根据实施例以单数或复数形式表示。然而，为了便于解释而适当地选择单数或复数形式，并且本公开不限于此。这样，以复数形式表示的元件也可以被配置成单个元件，并且以单数形式表示的元件也可以被配置成复数元件。
同时，在本公开的详细描述中已经描述了具体实施例，但是在不脱离本公开的范围的情况下，可以进行各种修改。因此，本公开的范围不应限于上述实施例，而应不仅由所附权利要求的范围确定，而且由权利要求的等同物确定。
应当理解，本公开的各种实施例和本文使用的术语不是旨在将本公开中描述的技术限制为具体实施例，而是包括相应实施例的各种修改、等同物和/或替代方案。关于附图的描述，相同的附图标记可以表示相同的元件。除非在上下文中具有明显不同的含义，否则以单数使用的表述可以包括复数的表述。在本公开中，诸如“A或B”、“A和/或B中的至少一个”、“A、B或C”或“A、B和/或C中的至少一个”的表述包括所列要素的所有可能的组合。诸如“第一”、“第二”等的表述可以修饰相应的元件，而不管它们的顺序或重要性，并且仅仅用于将一个元件与另一个元件区分开，而不限制相应的元件。当一个元件(例如，第一元件)(功能上或通信上)连接或接入到另一个元件(例如，第二元件)时，该元件可以直接或通过另一个元件(例如，第三元件)连接到另一个元件。
在本公开中使用的术语“模块”包括由硬件、软件或固件组成的单元，并且例如，可以与诸如逻辑、逻辑块、组件或电路之类的术语互换地使用。模块可以是整体配置的组件、执行一个或更多功能的最小单元或其一部分。例如，模块可以被配置成专用集成电路(ASIC)。
本公开的各种实施例可以实现为机器(例如，计算机)可读存储介质(例如，存储在内部存储器或外部存储器(例如，程序)中的包括指令的软件)。机器是能够从存储介质调用所存储的指令并根据所调用的指令操作的设备，并且可以包括根据各个实施例的终端。当指令由处理器(例如，图14的处理器1420)执行时，处理器可直接或通过使用由处理器控制的其它组件来执行对应于指令的功能。指令可以包括由编译器或解释器生成或执行的代码。
机器可读存储介质可以以非暂时性存储介质的形式提供。术语“非暂时性”仅指存储介质不包括信号并且是有形的，并且不区分数据是半永久地还是临时地存储在存储介质中。
根据本公开的各种实施例的方法可以通过被包括在计算机程序产品中来提供。计算机程序产品是可以在卖方和买方之间交易的产品。计算机程序产品可以以机器可读存储介质(例如，光盘只读存储器(CD-ROM))的形式分发，或者通过应用商店(例如，PlayStoreTM)在线分发。在在线分发的情况下，计算机程序产品的至少一部分可以在存储介质中被临时存储或临时生成，该存储介质例如为制造商的服务器、应用商店的服务器或中继服务器的存储器。根据各个实施例的组件(例如，模块或程序)中的每一个可包括单个或多个实体，并且上述子组件中的一些子组件可被省略，或者其它子组件可进一步包括在各个实施例中。可替代地或附加地，一些组件(例如，模块或程序)可以被集成到一个实体中，并且在集成之前由每个组件执行的功能可以相同或类似地执行。根据各种实施例，由模块、程序或其它组件执行的操作可以顺序地、并行地、重复地或试探地执行，至少一些操作可以以不同的顺序执行或被省略，或者可以添加其它操作。
Claims (15)
1.用于在无线通信***中向第二终端提供捆绑包的第一终端，所述第一终端包括：
收发器；以及
至少一个处理器，配置成：
获取与要传输到所述第二终端的捆绑包有关的信息；
基于捆绑包传送配置信息包括指示所述第一终端是否能够向另一个终端传输捆绑包的指示符，确定出所述第一终端能够向所述第二终端传输所述捆绑包；
生成包括要传输到所述第二终端的捆绑包的标识信息的捆绑包传输代码；
将所生成的捆绑包传输代码传输到所述第二终端；以及将要传输到所述第二终端的捆绑包上传到捆绑包管理服务器，
其中，要传输到所述第二终端的捆绑包通过经由所述捆绑包管理服务器被传输到所述第二终端而安装在所述第二终端中。
2.如权利要求1所述的第一终端，其中，所述捆绑包传送配置信息包括以下至少之一：与所述第一终端与所述第二终端之间的捆绑包传输所需的条件有关的信息、或者指示是否允许通过所述捆绑包管理服务器在所述第一终端与所述第二终端之间进行捆绑包传输的指示符。
3.如权利要求1所述的第一终端，其中，
所述捆绑包的标识信息包括以下至少之一：要传输到所述第二终端的捆绑包的身份ID、捆绑包族ID(Fid)或捆绑包族托管对象ID(Oid)，以及
所述捆绑包传输代码进一步包括以下至少之一：与要传输到所述第二终端的捆绑包的属性有关的信息、所述捆绑包管理服务器的地址、用于连接所述第一终端和所述第二终端的信息、或者由所述第一终端支持的加密算法信息。
4.如权利要求1所述的第一终端，其中，所述至少一个处理器还配置成：
向所述捆绑包管理服务器传输捆绑包传送认证信息，所述捆绑包传送认证信息包括所述第一终端的第一智能安全平台SSP信息、所述第一终端与所述捆绑包管理服务器之间进行认证的证书协商信息、或所述第一SSP的版本信息中的至少之一；
基于所传输的捆绑包传送认证信息，从所述捆绑包管理服务器接收服务器认证信息；
基于所接收的服务器认证信息，向所述捆绑包管理服务器传输第一终端认证信息以及要传输到所述第二终端的捆绑包的捆绑包ID；
响应于所述捆绑包管理服务器基于所述第一终端认证信息将所述第一终端确定为能够对要传输到所述第二终端的捆绑包进行传输的终端，从所述捆绑包管理服务器接收捆绑包请求消息；以及
基于所接收的捆绑包请求消息，将要传输到所述第二终端的捆绑包上传到所述捆绑包管理服务器。
5.用于在无线通信***中从第一终端接收捆绑包的第二终端，所述第二终端包括：
收发器；以及
至少一个处理器，配置成：
从所述第一终端接收包括要被所述第二终端接收的捆绑包的标识信息的捆绑包传输代码；
基于所接收的捆绑包传输代码，与捆绑包管理服务器执行认证过程；
响应于成功执行了与所述捆绑包管理服务器的所述认证过程，向所述捆绑包管理服务器传输所述待接收捆绑包的信息；以及
响应于所述捆绑包管理服务器确定出被所述第二终端接收的捆绑包对应于所述待接收捆绑包，接收第一捆绑包和第一捆绑包信息。
6.如权利要求5所述的第二终端，其中，
要被所述第二终端接收的捆绑包的标识信息包括以下至少之一：要被所述第二终端接收的捆绑包的身份ID、捆绑包族ID(Fid)或捆绑包族托管对象ID(Oid)，以及
所述捆绑包传输代码还包括以下至少之一：与要被所述第二终端接收的捆绑包的属性有关的信息、所述捆绑包管理服务器的地址、用于将所述第一终端连接到所述第二终端的信息、或者由所述第一终端支持的加密算法信息。
7.如权利要求5所述的第二终端，其中，所述至少一个处理器还配置成：
向所述捆绑包管理服务器传输第二智能安全平台SSP信息，所述第二SSP信息包括用于所述捆绑包管理服务器与所述第二终端的第二SSP之间的认证的证书协商信息；
从所述捆绑包管理服务器接收由所述捆绑包管理服务器基于所述第二SSP信息而生成的服务器认证信息；
基于所述服务器认证信息，向所述捆绑包管理服务器传输包括所述第二SSP的ID和所述待接收捆绑包的ID的第二终端信息；以及
响应于所述捆绑包管理服务器确定出从所述第一终端接收的、所述第二SSP的ID和要被所述第二终端接收的捆绑包的所述标识信息分别对应于从所述第二终端接收的、所述第二SSP的ID和所述待接收捆绑包的ID，从所述捆绑包管理服务器接收所述第一捆绑包和所述第一捆绑包信息。
8.如权利要求5所述的第二终端，其中，
所述捆绑包管理服务器配置成：基于捆绑包传送配置信息将所述第二终端确定为能够从另一个终端接收捆绑包的终端，以及
所述捆绑包管理服务器配置成：将所述待接收捆绑包确定为能够安装在所述第二终端中的捆绑包。
9.用于在无线通信***中向第二终端提供配置文件的第一终端，所述第一终端包括：
收发器；以及
至少一个处理器，配置成：
从安装在所述第一终端中的配置文件之中确定要传输到所述第二终端的第一配置文件；
基于配置文件传送配置信息包括所述第二终端的嵌入式通用集成电路卡eUICC的身份ID，确定出所述第一配置文件能够通过配置文件管理服务器传输到所述第二终端；
响应于验证了所述配置文件管理服务器，向所述配置文件管理服务器传输包括所述第一终端的第一配置文件ID和eUICCID的第一终端认证信息；
响应于所述配置文件管理服务器通过使用所述第一终端的第一配置文件ID和eUICCID验证出所述第一终端正在使用所述第一配置文件，从所述配置文件管理服务器接收配置文件请求消息；以及
基于所述配置文件请求消息，向所述配置文件管理服务器传输用于所述第一配置文件的配置文件包。
10.如权利要求9所述的第一终端，
其中，所述至少一个处理器还配置成：从所述第二终端接收包括所述eUICC的ID和所述第二终端的eUICC信息的所述配置文件传送配置信息，
其中，所述第二终端的eUICC信息包括用于确定要从所述第一终端接收的配置文件是否能够在所述第二终端的eUICC中正常安装和操作的信息。
11.如权利要求9所述的第一终端，其中，所述至少一个处理器还配置成：
将所述第一终端的eUICC信息传输到所述配置文件管理服务器；
接收所述配置文件管理服务器的服务器认证信息，其中所述服务器认证信息由所述配置文件管理服务器基于所述第一终端的eUICC信息而生成；以及
基于所述第一终端的eUICC信息和所述配置文件管理服务器的服务器认证信息，验证所述配置文件管理服务器。
12.如权利要求9所述的第一终端，其中，所述配置文件包包括以下至少之一：与所述第一配置文件有关的信息、由所述第一终端用来对所述第一配置文件进行编码的第一加密密钥生成信息、所述第一终端的第一公开密钥、由所述配置文件管理服务器用来对所述第一配置文件进行编码的第二加密密钥生成信息、或所述配置文件管理服务器的第二公开密钥。
13.用于在无线通信***中从第一终端接收配置文件的第二终端，所述第二终端包括：
收发器；以及
至少一个处理器，配置成：
向所述第一终端传输包括所述第二终端的嵌入式通用集成电路卡eUICC的身份ID的配置文件传送配置信息；
将所述第二终端的eUICC信息传输到配置文件管理服务器；
基于所述第二终端的eUICC信息，接收所述配置文件管理服务器的认证信息；
响应于基于所述配置文件管理服务器的认证信息验证了所述配置文件管理服务器，向所述配置文件管理服务器传输第二终端认证信息，所述第二终端认证信息包括要被接收的配置文件的ID和所述第二终端的eUICCID；以及
基于所述第二终端认证信息，从所述配置文件管理服务器接收用于第一配置文件的配置文件包。
14.如权利要求13所述的第二终端，其中，所述第二终端认证信息包括用于确定要从所述第一终端接收的配置文件是否能够在所述第二终端的eUICC中正常安装和操作的信息。
15.如权利要求13所述的第二终端，其中，
所述配置文件包包括以下至少之一：与所述第一配置文件有关的信息、由所述第一终端用来对所述第一配置文件进行编码的第一加密密钥生成信息、所述第一终端的第一公开密钥、由所述配置文件管理服务器用来对所述第一配置文件进行编码的第二加密密钥生成信息、或所述配置文件管理服务器的第二公开密钥，以及
所述至少一个处理器还配置成：
当所接收的用于所述第一配置文件的配置文件包由所述第一终端编码时，通过使用所述第一终端的第一公开密钥和所述第二终端的私密密钥对用于所述第一配置文件的配置文件包进行解码；以及
当所接收的用于所述第一配置文件的配置文件包由所述配置文件管理服务器编码时，通过使用所述配置文件管理服务器的第二公开密钥和所述第二终端的所述私密密钥来对所述第一配置文件的配置文件包进行解码。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR20200032054 | 2020-03-16 | ||
| KR10-2020-0032054 | 2020-03-16 | ||
| KR10-2020-0087663 | 2020-07-15 | ||
| KR1020200087663A KR20210116169A (ko) | 2020-03-16 | 2020-07-15 | 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치 |
| PCT/KR2021/003252 WO2021187874A1 (ko) | 2020-03-16 | 2021-03-16 | 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115280815A true CN115280815A (zh) | 2022-11-01 |
Family
ID=77771749
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202180020406.4A Pending CN115280815A (zh) | 2020-03-16 | 2021-03-16 | 在设备之间在线移动捆绑包或配置文件的方法和设备 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20230136288A1 (zh) |
| CN (1) | CN115280815A (zh) |
| WO (1) | WO2021187874A1 (zh) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8560708B2 (en) * | 2010-06-29 | 2013-10-15 | Alcatel Lucent | Method and apparatus for allocating bundles of sessions in a network element |
| CN107873137B (zh) * | 2015-04-13 | 2021-11-23 | 三星电子株式会社 | 用于管理通信***中的简档的技术 |
| KR20170098110A (ko) * | 2016-02-19 | 2017-08-29 | 삼성전자주식회사 | 임베디드 심 운용 지원 방법 및 이를 지원하는 전자 장치 |
| KR102559471B1 (ko) * | 2018-06-25 | 2023-07-26 | 삼성전자주식회사 | 무선 통신 시스템에서 통신사 정보를 처리하는 방법 및 장치 |
-
2021
- 2021-03-16 US US17/911,081 patent/US20230136288A1/en active Pending
- 2021-03-16 CN CN202180020406.4A patent/CN115280815A/zh active Pending
- 2021-03-16 WO PCT/KR2021/003252 patent/WO2021187874A1/ko active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021187874A1 (ko) | 2021-09-23 |
| US20230136288A1 (en) | 2023-05-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110870281B (zh) | 由esim终端和服务器讨论数字证书的方法和装置 | |
| CN110024426B (zh) | 通过eSIM进行访问控制的装置及方法 | |
| CN112956155B (zh) | Ssp设备和服务器协商数字证书的装置和方法 | |
| CN113273155B (zh) | 用于管理智能安全平台的绑定的方法和装置 | |
| US11989543B2 (en) | Method for interoperating between bundle download process and eSIM profile download process by SSP terminal | |
| CN113785532B (zh) | 用于管理和验证证书的方法和装置 | |
| US11589212B2 (en) | Method and apparatus for managing event in communication system | |
| CN112913263A (zh) | 用于处理远程简档管理异常的方法和装置 | |
| CN111919458B (zh) | 用于协商euicc版本的方法和装置 | |
| CN115997398A (zh) | 用于在设备改变期间移动具有不同版本的简档的方法和设备 | |
| CN116097636A (zh) | 用于设备之间的链接或配置文件传输的装置和方法 | |
| CN113455025A (zh) | Ssp终端在捆绑包下载过程和esim配置文件下载过程之间进行互操作的方法 | |
| CN115280815A (zh) | 在设备之间在线移动捆绑包或配置文件的方法和设备 | |
| EP4017047A1 (en) | Method and device for setting state of bundle after transfer of bundle between apparatuses | |
| JP7383693B2 (ja) | プロファイル遠隔管理権限設定方法、その装置及びそのシステム | |
| US20220377081A1 (en) | Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer | |
| KR20210034475A (ko) | 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치 | |
| KR20220152912A (ko) | 논리 인터페이스를 지원하는 단말 및 카드 간 Proactive Command를 획득하여 처리하는 방법 및 장치 | |
| KR20210116169A (ko) | 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치 | |
| CN114556887A (zh) | 用于在设备之间传送捆绑包的方法和设备 | |
| CN117280722A (zh) | 当euicc终端变化时识别简档删除的方法和装置 | |
| KR20200130044A (ko) | 인증서 관리 및 검증 방법 및 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |