用于为eUICC安装配置文件的方法和装置与流程

本公开涉及在与被插入到移动通信终端中并且然后使用的与智能卡安全模块对应的通用集成电路卡(UICC)有关的
技术领域：
中的用于在终端中安装配置文件的方法和装置。更具体地，本公开涉及一种在制造处理期间在嵌入式UICC(eUICC)而不是包括通信服务公司信息的UICC中远程安装移动通信用户信息/从嵌入式UICC(eUICC)而不是包括通信服务公司信息的UICC移除移动通信用户信息的管理技术。
背景技术：
：通用集成电路卡(UICC)是被插入到移动通信终端中的智能卡，其存储诸如移动通信用户的网络访问认证信息、电话簿和短消息服务(SMS)的个人信息，并且执行对用户进行认证以及在该用户访问诸如全球移动通信系统(GSM)、宽带码分多址(WCDMA)或长期演进(LTE)的移动通信网络时生成业务安全密钥从而允许该用户使用稳定的移动通信的功能。UICC根据用户访问的移动通信网络的类型具有诸如用户标识模块(SIM)、通用SIM(USIM)或网际协议(IP)多媒体SIM(ISIM)的通信应用，并且也提供高级安全功能以具有诸如电子钱包、售票和电子护照的各种应用。相关技术的UICC在卡被制造时通过来自所对应的移动网络运营商的请求作为特定移动网络运营商的专用卡被制造，并且卡在用于由所对应的服务提供方访问网络的认证信息(例如，USIM应用和国际移动用户身份(IMSI)或K值)被插入到该卡之后被释放。因此，所制造的UICC被所对应的移动网络运营商接收并且然后提供给用户。然后，UICC内的应用根据需要被管理，例如，使用空中下载(OTA)技术来安装、修改和移除。用户能够通过将UICC插入到用户的移动通信终端中来使用所对应的移动网络运营商的网络和应用服务。另外，如果用户改变终端，则用户能够继续通过将相关技术的终端的UICC插入到新终端中经由新终端使用认证信息、移动通信电话号码以及个人电话簿。此外，UICC的物理形状和逻辑功能由诸如欧洲电信标准协会(ETSI)的标准化组织定义，并且因此其国际兼容性被维持。在定义物理形态的形态因数的一个方面中，被最广泛地使用的迷你SIM(miniSIM)、几年前已经开始使用的微型SIM(microSIM)以及最近被使用的纳米SIM(nanoSIM)的尺寸依次且逐步地减小。因此，它对移动通信终端的小尺寸有显著贡献。然而，由于UICC卡的丢失，很难期望比最近制造的纳米SIM(nanoSIM)更小的UICC卡的标准化。另外，因为UICC卡需要根据其特性在终端中安装可移除插槽的空间，所以预计更小尺寸的UICC卡将是困难的。另外，可移除的UICC不适合于需要在各种安装环境中在没有通过人的任何直接控制的情况下访问移动通信数据网络的诸如智能家用电器、电/水表以及闭路电视(CCTV)相机的机器到机器(M2M)的设备。为了解决以上问题，可以考虑用执行与UICC的功能类似的功能的安全模块替换UICC的方法。嵌入式UICC(eUICC)可以是指能够根据每个通信服务公司被下载和安装用户标识和加密密钥的UICC。安全模块可以在终端被制造时被安装在该终端内，使得安全模块不能够附接到终端的内部/从终端的内部分离。在这种情况下，除非终端被制造为专用于特定移动网络运营商的终端，否则终端不能够在该终端被制造时提前具有诸如USIM的IMSI和K的特定移动网络运营商的网络访问认证信息，并且购买所对应的终端的用户能够在用户订阅特定移动网络运营商之后配置认证信息。另外，与已仅为特定移动网络运营商而制造和分配的相关技术的UICC不同，eUICC能够在购买所对应的终端的用户订阅特定移动网络运营商并且放弃对特定移动网络运营商的订阅或者将对特定移动网络运营商的订阅改变为对另一移动网络运营商的订阅之后稳定地且灵活地安装和管理各种移动网络运营商的认证信息。更具体地，相关技术的移动网络运营商信息技术(IT)系统仅使用UICC来处理移动通信打开。因此，为了处理配备有eUICC的新终端的打开，需要改变移动网络运营商IT系统接口。上述信息仅作为背景信息被呈现来帮助理解本公开。至于上述中的任一个关于本公开是否可能适用作为现有技术，尚未作出确定，并且未做出断言。技术实现要素：技术问题本公开的各方面在于解决至少上述问题和/或缺点并且提供至少在下面所描述的优点。因此，本公开的一个方面在于提供一种将各种移动网络运营商的通用集成电路卡(UICC)信息通过网络远程插入到替换相关技术的UICC的安全模块中的稳定方法。本公开的另一方面在于提供用于允许终端主动地从网络服务器远程下载配置文件的方法和装置。也就是说，本公开提供用于允许终端在没有移动网络运营商信息技术(IT)系统接口方面的任何改变的情况下独自从网络服务器(订阅管理器数据准备(SM-DP)或订阅管理器安全路由(SM-SR))远程下载配置文件而不是允许该网络服务器主动下载终端的配置文件的方法和装置。问题的解决方案依照本公开的一个方面，提供了一种由包括UICC的终端安装配置文件的方法。该方法包括：获取用于在所述终端中安装配置文件的认证信息；将所获取的认证信息发送到用于管理包括在所述终端中的所述UICC的配置文件管理服务器；以及，在所述认证信息被所述配置文件管理服务器或配置文件生成服务器验证的情况下，从所述配置文件管理服务器接收与所述认证信息对应的配置文件。依照本公开的另一方面，提供了一种包括UICC的终端。该终端包括：通信单元以及控制器，该通信单元被配置为执行数据通信；该控制器被配置为向用于管理包括在所述终端中的所述UICC的配置文件管理服务器发送获取的认证信息，并且，在所述认证信息被所述配置文件管理服务器或配置文件生成服务器验证的情况下，从所述配置文件管理服务器接收与所述认证信息对应的配置文件。依照本公开的另一方面，提供了一种由配置文件生成服务器为包括UICC的终端提供配置文件的方法。该方法包括：生成用于对要提供给所述终端的配置文件进行认证并且用于所述终端下载所述配置文件的认证信息；以及基于用于所述终端下载所述配置文件的所述认证信息的验证结果来发送所述配置文件。依照本公开的另一方面，提供了一种用于向包括UICC的终端提供配置文件的服务器。该服务器包括通信单元和控制器，该通信单元被配置为执行数据通信；该控制器被配置为生成用于对要提供给终端的配置文件进行认证并且用于所述终端下载所述配置文件的认证信息，并且基于所述终端下载所述配置文件的所述认证信息的验证结果来发送所述配置文件。依照本公开的另一方面，提供了一种由配置文件管理服务器为包括UICC的终端提供配置文件的方法。该方法包括：从所述终端接收用于配置文件的安装的认证信息；根据所述认证信息的验证结果来接收所述配置文件；以及将所接收到的配置文件发送到包括在所述终端中的所述UICC。依照本公开的另一方面，提供了一种用于向包括UICC的终端提供配置文件的服务器。该服务器包括：通信单元和控制器，该通信单元被配置为执行数据通信；该控制器被配置为从所述终端接收用于配置文件的安装的认证信息，根据所述认证信息的验证结果来接收所述配置文件，并且将所接收到的配置文件发送到包括在所述终端中的所述UICC。有益效果根据本公开的各种实施方式，终端能够在没有移动网络运营商IT系统接口方面的任何改变的情况下独自从网络服务器(SM-DP或SM-SR)远程下载配置文件，而不是网络服务器主动下载终端的配置文件。根据本公开的各种实施方式，能够在没有移动网络运营商IT系统方面的任何改变的情况下在eUICC中下载配置文件。根据本公开的各种实施方式，能够执行验证以更稳定地下载配置文件。根据以下具体描述，本公开的其它方面、优点和突出特征对于本领域的技术人员而言将变得显而易见，以下具体描述结合附图公开了本公开的各种实施方式。附图说明根据结合附图进行的以下描述，本公开的特定实施方式的以上及其它方面、特征和优点将更显而易见，附图中：图1例示了使用根据本公开的实施方式的相关技术的通用集成电路卡(UICC)(用户信息模块(SIM)卡)来分配并打开终端的处理；图2例示了根据本公开的实施方式的下载嵌入式UICC(eUICC)的配置文件的处理；图3例示了根据本公开的实施方式的主动通过终端的配置文件下载方法的第一实施方式；图4是例示了根据本公开的实施方式的支持配置文件安装方法的终端的配置的框图；图5是例示了根据本公开的实施方式的订阅管理器数据准备(SM-DP)的操作的流程图；图6是例示了根据本公开的实施方式的订阅管理器安全路由(SM-SR)的操作的流程图；图7是例示了根据本公开的实施方式的终端的操作的流程图；图8是例示了根据本公开的实施方式的终端内的eUICC的操作的流程图；图9例示了根据本公开的实施方式的主动通过终端的配置文件下载方法的第二实施方式；图10是例示了根据本公开的实施方式的SM-DP的操作的流程图；图11是例示了根据本公开的实施方式的SM-SR的操作的流程图；图12例示了根据本公开的实施方式的主动通过终端的配置文件下载方法的第三实施方式；图13是例示了根据本公开的实施方式的SM-DP的操作的流程图；图14是例示了根据本公开的实施方式的SM-SR的操作的流程图；图15是例示了根据本公开的实施方式的终端的操作的流程图；图16是例示了根据本公开的实施方式的终端内的eUICC的操作的流程图；图17例示了根据本公开的实施方式的主动通过终端的配置文件下载方法的第四实施方式；图18是例示了根据本公开的实施方式的SM-SR的操作的流程图；图19是例示了根据本公开的实施方式的SM-DP或SM-SR的配置的框图；以及图20例示了根据本公开的实施方式的在eUICC中安装配置文件的终端的实施方式。遍及附图，相同的附图标记将被理解为是指相同的部分、组件和结构。具体实施方式参考附图的以下描述被提供来帮助对如由权利要求及其等同物所限定的本公开的各种实施方式的全面理解。它包括各种特定细节以帮助该理解，但是这些将被认为是仅示例性的。因此，本领域的普通技术人员将认识到，能够在不脱离本公开的范围和精神的情况下做出本文中所描述的各种实施方式的各种改变和修改。此外，为了清楚和简明可以省略众所周知的功能和构造的描述。在以下描述和权利要求中使用的术语和单词不限于书目意义，而是，仅被本发明人用来使得能实现对本公开的清楚且一致的理解。因此，对于本领域的技术人员而言应该显而易见的是，本公开的各种实施方式的以下描述是仅为了例示目的而不是为了限制如由所附权利要求及其等同物所限定的本公开的目的而提供的。应当理解的是，除非上下文另外清楚地规定，否则单数形式“一”、“一个”和“该”包括复数对象。因此，例如，对“组件表面”的提及包括对这些表面中的一个或多个的提及。首先，将定义本公开中使用的术语。在本公开中，通用集成电路卡(UICC)是被插入到移动通信终端中的智能卡，其是指存储诸如移动通信用户的网络访问认证信息、电话地址簿和短消息服务(SMS)的个人信息并且在该用户访问诸如全球移动通信系统(GSM)、宽带码分多址(WCDMA)或长期演进(LTE)的移动通信网络时执行对用户进行认证以及生成业务安全密钥从而允许该用户使用稳定的移动通信的功能的芯片。UICC根据用户访问的移动通信网络的类型而具有诸如用户标识模块(SIM)、通用SIM(USIM)或网际协议(IP)多媒体SIM(ISIM)的通信应用，并且也提供高级安全功能以具有诸如电子钱包、售票和电子护照的各种应用。在本公开中，术语UICC可交换地与术语SIM一起使用。eUICC可以是指能够根据每个通信服务公司来下载和安装用户标识和加密密钥的UICC。根据本公开的各种实施方式，eUICC可能是可分离的和/或可替换的。也就是说，eUICC被包括在UICC中，并且在本公开中可以被用作UICC、eUICC或嵌入式SIM(eSIM)。在本公开中，配置文件可以是指包括在UICC中的信息以软件形式的封装。在本公开中，USIM配置文件可以具有与配置文件相同的意义或者是指包括在配置文件内的USIM应用中的信息以软件形式的封装。在本公开中，运营配置文件可以是指终端的用户订阅的移动网络运营商的订阅信息以软件形式的封装。在本公开中，供应配置文件是当用户在订阅特定通信服务公司之前通过终端访问预定国家的预定移动通信网络时需要的配置文件，并且可以是指提前安装在eUICC中的配置文件。在本公开中，订阅管理器数据准备(SM-DP)可以被表达为配置文件提供服务器、配置文件域的卡外实体(off-cardentity)、配置文件加密服务器、配置文件生成服务器、配置文件供应者或配置文件提供方。在本公开中，订阅管理器安全路由(SM-SR)可以被表达为配置文件管理服务器、eUICC配置文件管理器的卡外实体或配置文件管理器。在本公开中，发行者安全域根域(ISD-R)(eUICC配置文件管理器)可以被表达为配置文件管理器，并且可以是对在eUICC/eSIM内加密且由SM-SR服务器发送的空中下载(OTA)消息进行解密并且执行下载、启用、禁用或者删除配置文件的功能的控制模块。在本公开中，配置文件标识符(ID)可以被称为与集成电路卡ID(ICCID)和发行者安全域配置文件(ISD-P)匹配的因数。配置文件ID可以是指每个配置文件的唯一标识。在本公开中，嵌入式通用集成电路卡(E-UICC)ID可以是包括在终端中的eUICC的唯一标识并且可以被称为EID。另外，当供应配置文件被预安装在eUICC中时，E-UICCID可以是所对应的供应配置文件的配置文件ID。此外，当终端不能够与根据本公开的实施方式的eUICC(或eSIM)芯片分开时，E-UICCID可以是终端ID。而且，E-UICCID可以是指eSIM芯片的特定安全域。在本公开中，Auth码(授权码)是由SM-DP生成的随机数，并且可以被用于只有当包括所对应的随机数的打开请求被做出时才处理正常的打开。在本公开中，SM-DP地址是IP地址、统一资源定位符(URL)或形式为ID的SM-SP服务器地址，并且可以在SM-SR在多个SM-DP当中标识可以生成特定配置文件的SM-DP时被使用。在本公开中，拉模式(pullmode)指示符可以是指示由eUICC/eSIM下载、由终端触发和下载而不是以推形式(PUSHform)从网络下载的配置文件的区分符。在本公开中，可以可交换地使用认证码的验证和认证。另外，对于本领域的技术人员显而易见的是，本公开中使用的术语控制单元和控制器可以具有相同的意义。图1例示了使用根据本公开的实施方式的相关技术的UICC(SIM卡)来分配并打开终端的处理。参考图1，能够被插入到终端中并从终端移除的可移除UICC可以在其中具有终端能够用来访问特定移动通信服务公司网络的认证信息(国际移动用户身份(IMSI)、K等)并且然后被销售。因此，可移动卡能够仅由所对应的移动网络运营商使用直到该卡被丢弃为止。UICC可以根据移动通信网络的类型在其中具有诸如SIM、USIM和ISIM的各种通信应用，并且还具有诸如移动信用卡、移动钱包和电子护照的各种应用。在这种情况下，能够通过OTA技术来管理被插入到终端中的UICC以在UICC内方便地安装、修改或者移除应用。如附图标记101所示，移动网络运营商(MNO)100向SIM厂商130发送诸如IMSI或ICCID的SIM信息。SIM厂商130通过使用所接收到的SIM信息来制造UICC并且如附图标记103所示将该UICC交付给MNO100。也就是说，在该UICC被制造时通过来自所对应的运营商的请求UICC被制造作为特定移动网络运营商的专用卡。因此，在用于通过所对应的运营商的网络访问的认证信息(例如，USIM应用以及IMSI或K值)被预先插入到UICC中之后，UICC被释放。然后，如附图标记105所示，MNO100为终端而向设备制造商150下订单，并且如附图标记107所示，设备制造商150制造终端并将该终端交付给MNO100。如附图标记111所示，MNO100将终端连同与所对应的用户的ICCID信息对应的UICC一起提供给销售者。当如附图标记109所示用户170做出向MNO100订阅移动通信网络的请求时，用户将UICC安装在所购买的终端中。当用户打开终端的状态时，终端连接到运营网络，并且必要时应用通过OTA技术被安装、修改并从UICC移除。用户能够通过将UICC插入到用户的移动通信终端中来使用所对应的移动网络运营商的网络和应用服务。另外，如果用户改变终端，则用户能够仍然通过将相关技术的终端的UICC插入到新终端中来经由新终端使用认证信息、移动通信电话号码以及个人电话簿。图2例示了根据本公开的实施方式的下载eUICC的配置文件的处理。参考图2，eUICC201可以通过使用OTA技术来下载和安装配置文件。MNO250可以向SIM厂商210提供关于IMSI或ICCID的信息，并且SIM厂商210可以基于所提供的信息来制造eUICC。与图1的差异是在图2中所制造的eUICC是由设备制造商230而不是由MNO250提供的。eUICC可以存储与每个eUICC的唯一标识对应的EID、OTA(SM-SR)密钥以及供应配置文件(移动站集成服务数字网络(MSISDN))。设备制造商230可以如附图标记202所示为了eUICC而向SIM厂商210下订单并且如附图标记203所示接收所制造的eUICC。设备制造商230可以制造配备有所接收到的eUICC的终端。另选地，可以之后将eUICC安装在终端中。MNO250可以如附图标记204所示为了终端而向设备制造商230下订单，并且设备制造商230可以如附图标记205所示响应于来自MNO250的订单而供应包括eUICC的终端。另选地，可以之后单独地供应eUICC。如附图标记206所示，用户270可以购买终端并且应用来向MNO250订阅移动通信服务。为了服务订阅，与包括在移动通信终端中的eUICC的唯一标识对应的EID可以是具有全局唯一值的唯一标识。当用户270订阅移动通信服务时，MNO250可以接收ICCID以及与eUICC的标识对应的EID，并且根据所对应的信息来对于配置文件到SM-DP280的下载(D/L)做出请求。SM-DP280可以由MNO直接操作或者可以由与MNO具有完全信任关系的另一公司来操作。根据商业和合同关系，SM-DP280可以为一个或多个MNO提供服务。SM-DP280可以用来为订阅所对应的MNO的用户生成配置文件并对其进行加密，并且将经加密的配置文件发送到SM-SR290。当用户270订阅服务时提供的EID和ICCID可以通过与当eUICC稍后下载配置文件时存储在eUICC中的值的比较来验证。当验证失败时，EID和ICCID可以被用来停止配置文件的安装。SM-SR290是服务器，该服务器用来管理特定eUICC的配置文件，并且将从SM-DP280接收到的经加密的配置文件稳定地发送到对应的终端安全模块。SM-SR290可以用来管理配置文件，例如，在配置文件被完全解密并且安装在eUICC中之后激活、停用或者移除配置文件。当用户270打开所购买的终端时，终端如附图标记207所示通过使用预安装在eUICC中的供应配置文件来访问供应网络(provisioningnetwork)。SM-DP280可以根据来自MNO250的配置文件D/L请求208来生成所对应的EID的配置文件，对所生成的配置文件进行加密，并且如附图标记209所示将经加密的配置文件发送到SM-SR290。SM-SR290可以如附图标记211所示通过用户终端的安全验证处理来向用户提供运营配置文件，并且终端可以通过使用所下载的运营配置文件来访问MNO250的移动通信网络。图3例示了根据本公开的实施方式的主动通过终端的配置文件下载方法的第一实施方式。参考图3，如附图标记301所示，MNO330可以首先向SM-DP320提供可以包括IMSI或ICCID的输入数据并且做出用于生成配置文件的请求。如附图标记302所示，SM-DP320可以根据来自MNO330的请求基于ICCID生成配置文件。SM-DP320可以生成Auth码作为配置文件的生成的结果。Auth码是由SM-DP320生成的随机数并且可以被用于只有当包括所对应的随机数的打开请求被做出时才处理正常的打开。另外，在本公开中Auth码也可以被表达为认证码并且可以根据每个ICCID被生成。当SM-DP320生成配置文件并且向MNO330发送与所生成的配置文件有关的输出数据时，SM-DP320也可以发送Auth码。另外，如附图标记303所示，SM-DP320可以发送关于SM-DP的地址的信息。此外，可以以纸卡(papercard)的形式将ICCID、Auth码和SM-DP地址提供给MNO330。在本公开中，尽管以纸卡的形式对ICCID、Auth码和SM-DP地址进行描述，然而通过SM-DP320的结果的物理形式没有限制并且ICCID、Auth码和SM-DP地址可以作为各种形式的结果被制造。当如附图标记304所示，用户300应用来向MNO330订阅服务时，MNO330可以如附图标记305所示向用户300发送关于所接收到的配置文件ID、Auth码和SM-DP地址的信息。这时，该信息可以被以纸卡的形式发送，并且可以被以文本字符串、条形码或快速响应(QR)码的形式在纸卡中指定。另外，所对应的信息可以在被插入到近场通信(NFC)标签中之后被发送给用户。此外，根据本公开的实施方式，纸卡可以由终端的销售者提供给终端的购买者，但是配置文件ID、SM-DP地址或Auth码可以通过MNO330的网站被以文本字符串、条形码或QR码的形式提供给购买包括eUICC的终端的用户。此后，如附图标记306所示，用户300可以将与配置文件有关的信息输入到终端350中，该信息包括为了配置文件下载启动而提供的Auth码。用户300可以在各种方法中将与配置文件下载(包括Auth码)有关的信息输入到终端350中。将参考图4描述详细的输入方法。图4是例示了根据本公开的实施方式的支持配置文件安装方法的终端的配置的框图。参考图4，终端400可以包括控制器410、通信单元420、eUICC430、显示单元440和输入单元450。通信单元420可以执行终端400与外部设备之间的数据通信。另外，通信单元420可以基于通过终端的控制器410的控制来操作，但是eUICC430可以在需要与外部设备的通信时通过终端的通信单元420来执行通信。eUICC430是终端的UICC芯片并且可以在其中包括ISD-R。ISD-R可以是控制模块，该控制模块对在eUICC/eSIM内加密且由SM-RS服务器发送的OTA消息进行解密并且执行下载、启用、禁用和删除配置文件的功能。显示单元440可以在显示设备上为终端的用户显示终端的操作和状态。显示单元440可以作为诸如液晶显示器(LCD)或有源矩阵有机发光二极管(AM-OLED)的面板被实现，并且可以被实现为可穿戴的。终端400的输入单元450可以包括接收各种类型的输入信号的设备。更具体地，根据本公开的实施方式，输入单元450可以包括音频模块，并且该音频模块可以包括扬声器、受话器、耳机或麦克风以接收通过该麦克风输入的声音信息。另外，根据本公开的实施方式，输入单元450可以包括相机模块，并且该相机模块可以包括图像传感器和透镜以接收通过相机输入的静止图像和运动图像。此外，根据本公开的实施方式，输入单元450可以是触摸面板，并且可以包括(数字)笔传感器、键或超声输入设备以识别用户的物理接触或接近。在本公开中，接收与通过用户300下载的配置文件有关的信息的终端350的输入单元可以通过处理电子信号的各种输入方法以及上述输入设备来操作。返回参考图3，将详细地描述操作306。在操作306中，用户300可以将与从MNO330接收到的配置文件的下载有关的信息输入到终端350中。将不同地配置由用户300将与配置文件下载有关的信息输入到终端350中的方法。例如，用户可以通过使用终端350的触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户可以通过经由终端350的相机模块给条形码或QR码形式的信息照相来将Auth码、配置文件ID或SM-DP地址输入到终端350中。另选地，用户可以通过使用NFC来以能够通过与终端350的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到终端350中。另选地，用户可以将Auth码、配置文件ID或SM-DP地址输入到被链接或者连接到终端350的设备中。在这种情况下，链接或者连接到终端350的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与终端350之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到终端350中。另外，终端350的数目可以是多个。在这种情况下，通过每个终端的操作，用于要存储在eUICC中的配置文件的认证码的验证可以由另一终端请求。将参考图20更详细地对此进行描述。此外，可以实现用于将Auth码、配置文件ID或SM-DP地址输入到终端350中的各种实施方式，并且本公开不限于上述方法中的一个。这可以是用于从将与配置文件下载有关的信息输入到终端350中的许多方法中选择随机方法的选项。如附图标记307所示，当与配置文件下载有关的信息被输入到终端350的输入单元中时，终端350的控制器可以向eUICC内的ISD-R发送以应用协议数据单元(APDU)命令的形式做出的用于下载配置文件的请求的命令。APDU可以是用于设备之间(例如，智能卡与计算机或移动电话之间)的数据传输的协议。eUICC的ISD-R可以通过使用与包括在从终端的控制器接收到的APDU命令中的配置文件的下载有关的信息中的至少一条(即，Auth码、配置文件ID或SM-DP地址)来生成要被发送到SM-SR的超文本传送协议(HTTP)POST消息，并且如附图标记308所示将所生成的HTTPPOST消息发送到SM-SR340。这时，所生成的HTTPPOST消息可以被表达为表1。【表1】根据本公开的实施方式，HTTPPOST消息可以被表达为表2。【表2】当SM-SR340通过终端的eUICC内的ISD-R接收到HTTPPOST消息时，可以如附图标记309所示确定终端主动下载配置文件。也就是说，与MNO330通过SM-SR或SM-DP来主动将配置文件提供给终端的现有技术不同，当终端直接做出对认证的请求并且下载配置文件时，SM-SR可以识别拉模式并且确定拉模式配置文件下载。这时，为了指示拉模式，可以定义和使用拉模式指示符或新参数。如附图标记310所示，SM-SR340向SM-DP320发送拉模式D/L请求。这时，所对应的请求消息可以包括EID和Auth码，并且在一些情况下可以包括配置文件ID和SM-DP地址。已接收到拉模式D/L请求的SM-DP320可以如附图标记311所示基于Auth码的匹配来验证做出了拉模式D/L请求的终端。当验证是成功的时，SM-DP320可以如附图标记312所示将配置文件发送到SM-SR340。此后，如附图标记313所示，eUICC从SM-SR340下载配置文件。图5是例示了根据本公开的第一实施方式的SM-DP的操作的流程图。参考图5，在操作501中，SM-DP从MNO接收用于生成配置文件的请求。这时，MNO可能不向SM-DP提供关于ICCID或IMSI的信息。在操作502中，SM-DP可以根据来自MNO的请求生成配置文件并且生成用于对所对应的配置文件进行认证的认证码。该认证码可以是Auth码并且可以根据每个ICCID被生成。所生成的配置文件可以被存储在SM-DP中，并且SM-DP可以将ICCID(或配置文件ID)和认证码发送到MNO。在本公开中，认证码和配置文件ID(或ICCID)可以被称作与配置文件下载有关的信息。此后，在操作503中SM-DP可以从SM-SR接收用于下载配置文件的请求。用于下载由SM-SR发送到SM-DP的配置文件的请求可以是由终端主动触发的拉模式D/L请求。终端可以通过包括在所接收到的拉模式D/L请求中的Auth码与存储在SM-DP中的Auth码之间的比较来验证所触发的配置文件下载。当验证是成功的时，在操作504中SM-DP将所生成的配置文件发送到SM-SR。图6是例示了根据本公开的第一实施方式的SM-SR的操作的流程图。参考图6，在操作601中，SM-SR可以从eUICC接收包括Auth码的用于下载配置文件的请求。这时，所接收到的请求的形式可以为表1或表2中所示出的HTTPPOST。在操作602中，SM-SR可以识别所接收到的用于下载配置文件的请求是从终端发送的并且将该下载确定为拉模式配置文件下载。因此，SM-SR可以向SM-DP发送从eUICC接收到的包括Auth码的拉模式D/L请求。在操作603中，当SM-DP在Auth码的验证上成功时，SM-SR可以从SM-DP接收配置文件，并且在操作604中将该配置文件发送到eUICC。图7是例示了根据本公开的第一实施方式的终端的操作的流程图。参考图7，在操作701中终端可以从用户接收配置文件ID(或ICCID)或Auth码的输入。在本公开中，可以不同地配置从用户接收与配置文件下载有关的信息的输入的方法。更具体地，用户可以通过使用触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户可以通过经由相机模块给形式为条形码或QR码的信息照相来将Auth码、配置文件ID或SM-DP地址输入到终端350中。另选地，用户可以通过使用NFC来以能够通过与终端350的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到终端350中。另选地，用户可以将Auth码、配置文件ID或SM-DP地址输入到链接或者连接到终端的设备中。在这种情况下，链接或者连接到终端的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与终端之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到终端350中。此外，可以实现用于将Auth码、配置文件ID或SM-DP地址输入到终端中的各种实施方式，并且本公开不限于上述方法中的一个。在操作702中，终端的控制器可以向终端内的eUICC发送指示要下载配置文件的APDU命令，并且所对应的命令可以包括输入到终端中的配置文件ID或Auth码。图8是例示了根据本公开的第一实施方式的终端内的eUICC的操作的流程图。参考图8，终端内的eUICC可以从终端的控制器接收指示要下载配置文件的APDU命令。这时，在操作801中所对应的命令可以包括输入到终端中的配置文件ID或Auth码。在操作802中，eUICC可以向SM-SR做出包括Auth码和配置文件ID的用于下载配置文件的请求。这时，由eUICC发送的消息可以形式为如以上所描述的表1或表2。当所发送的Auth码被完全验证时，在操作803中eUICC从SM-SR下载配置文件。图9例示了根据本公开的主动通过终端的配置文件下载方法的第二实施方式。参考图9，MNO930可以如附图标记901所示首先向SM-DP920提供可以包括IMSI或ICCID的输入数据并且做出用于生成配置文件的请求。如附图标记902所示，SM-DP920可以根据来自MNO930的请求基于ICCID生成配置文件。SM-DP920可以生成Auth码作为配置文件的生成的结果。Auth码是由SM-DP920生成的随机数并且可以被用于只有当包括所对应的随机数的打开请求被做出时才处理正常的打开。另外，在本公开中Auth码也可以被表达为认证码并且可以根据每个ICCID被生成。当SM-DP920生成配置文件并且向MNO930发送与所生成的配置文件有关的输出数据时，SM-DP920也可以发送Auth码。另外，SM-DP920也可以发送关于SM-DP的地址的信息。这时，在根据本公开的配置文件下载方法的第二实施方式中，当SM-DP920将配置文件ID(或ICCID)和Auth码发送到MNO时，SM-DP920可以如附图标记903所示将相同的信息发送到SM-SR940。当与配置文件有关的信息被发送到MNO930时，ICCID、Auth码和SM-DP地址可以被以纸卡的形式提供给MNO930。在本公开中，尽管以纸卡的形式对ICCID、Auth码和SM-DP地址进行描述，然而通过SM-DP920的结果的物理形式没有限制并且ICCID、Auth码和SM-DP地址可以制造为各种形式的结果。当如附图标记904所示用户900应用来向MNO930订阅服务时，MNO930可以如附图标记905所示向用户900发送关于所接收到的配置文件ID、Auth码和SM-DP地址的信息。这时，该信息可以被以纸卡的形式发送，并且可以被以文本字符串、条形码或QR码的形式在纸卡中指定。另外，所对应的信息可以在被插入到NFC标签中之后被发送给用户。此外，根据本公开的实施方式，纸卡可以由终端的销售者提供给终端的购买者，但是配置文件ID、SM-DP地址或Auth码可以通过MNO930的网站被以文本字符串、条形码或QR码的形式提供给购买包括eUICC的终端的用户。此后，如附图标记906所示，用户900可以将与配置文件有关的信息输入到终端950中，该信息包括被提供用于配置文件下载启动的Auth码。将不同地配置由用户900将与配置文件下载有关的信息输入到终端950中的方法。例如，用户可以通过使用触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户可以通过经由相机模块给形式为条形码或QR码的信息照相来将Auth码、配置文件ID或SM-DP地址输入到终端950中。另选地，用户可以通过使用NFC来以能够通过与终端950的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到终端950中。另选地，用户可以将Auth码、配置文件ID或SM-DP地址输入到链接或者连接到终端950的设备中。在这种情况下，链接或者连接到终端950的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与终端950之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到终端950中。此外，可以实现用于将Auth码、配置文件ID或SM-DP地址输入到终端950中的各种实施方式，并且本公开不限于上述方法中的一个。这可以是用于从将与配置文件下载有关的信息输入到终端950中的许多方法中选择随机方法的选项。当与配置文件下载有关的信息被输入到终端950的输入单元中时，如附图标记907所示，终端950的控制器可以向eUICC内的ISD-R发送以APDU命令的形式做出用于下载配置文件的请求的命令。APDU可以是用于设备之间(例如，智能卡与计算机或移动电话之间)的数据传输的协议。eUICC的ISD-R可以通过使用与包括在从终端的控制器接收到的APDU命令中的配置文件的下载有关的信息中的至少一条(即，Auth码、配置文件ID或SM-DP地址)来生成要发送到SM-SR的HTTPPOST消息，并且如附图标记908所示，将所生成的HTTPPOST消息发送到SM-SR940。这时，可以如表1或表2中所示出来表达所生成的HTTPPOST消息。当SM-SR940通过终端的eUICC内的ISD-R接收到HTTPPOST消息时，可以如附图标记909所示确定终端主动下载配置文件。也就是说，与MNO930通过SM-SR或SM-DP主动将配置文件提供给终端的现有技术不同，当终端直接做出对认证的请求并且下载配置文件时，SM-SR可以识别拉模式并且确定拉模式配置文件下载。这时，为了指示拉模式，可以定义和使用拉模式指示符或新参数。当SM-SR940确定拉模式配置文件D/L时，SM-SR940可以通过对预存储的Auth码和从eUICC接收到的Auth码进行比较来验证从eUICC接收到的Auth码。当验证成功时，如附图标记909所示，SM-SR940向SM-DP920发送做出用于发送配置文件的请求的拉模式D/L请求。这时，由SM-SR940发送的拉模式D/L请求消息可以包括EID和配置文件ID，并且也包括指示认证码的验证成功的Auth成功指示符。如附图标记911所示，SM-DP920可以通过识别包括在从SM-SR接收到的拉模式D/L请求消息中的Auth成功指示符来确定要下载配置文件。如附图标记912所示，SM-DP920可以将配置文件发送到SM-SR940，并且如附图标记913所示，SM-SR940可以发送从eUICC接收到的配置文件。图10是例示了根据本公开的第二实施方式的SM-DP的操作的流程图。参考图10，在操作1001中，SM-DP从MNO接收用于生成配置文件的请求。这时，MNO可能不向SM-DP提供关于ICCID或IMSI的信息。在操作1002中，SM-DP可以根据来自MNO的请求来生成配置文件并且生成用于对所对应的配置文件进行认证的Auth码。认证码可以是Auth码并且可以根据每个ICCID被生成。所生成的配置文件可以被存储在SM-DP中，并且SM-DP可以将ICCID(或配置文件ID)和认证码发送到MNO。在本公开中，认证码和配置文件ID(或ICCID)可以被称作与配置文件下载有关的信息。在操作1003中，SM-DP可以将配置文件ID(或ICCID)和Auth码发送到SM-SR。在操作1004中，SM-DP可以从SM-SR接收做出用于发送SM-DP的配置文件的请求的拉模式D/L请求。这时，由SM-SR发送的拉模式D/L请求可以包括EID和配置文件ID，并且也包括指示认证码的验证成功的Auth成功指示符。在操作1005中，SM-DP确定要下载配置文件并且将该配置文件发送到SM-SR。图11是例示了根据本公开的第二实施方式的SM-SR的操作的流程图。参考图11，在操作1101中，SM-SR从SM-DP接收配置文件ID(或ICCID)和Auth码。在操作1102中，SM-SR从eUICC的ISD-R接收包括Auth码、配置文件ID和SM-DP地址中的至少一个的HTTPPOST消息。该HTTPPOST消息可以是对主动通过终端的下载的配置文件下载请求。当SM-SR从eUICC的ISD-R接收到包括Auth码、配置文件ID和SM-DP地址中的至少一个的HTTPPOST消息时，在操作1103中SM-SR可以确定拉模式配置文件D/L并且通过对预存储的Auth码和从eUICC接收到的Auth码进行比较来验证从eUICC接收到的Auth码。当验证成功时，在操作1104中SM-SR向SM-DP发送做出用于发送配置文件的请求的拉模式D/L请求。这时，由SM-SR发送的拉模式D/L请求消息可以包括EID和配置文件ID，并且也包括指示认证码的验证成功的Auth成功指示符。此后，SM-SR可以在操作1105中从SM-DP接收配置文件，并且在操作1106中将所接收到的配置文件发送到eUICC。与Auth码的验证由SM-DP执行的情况(第一实施方式)不同，在本公开的第二实施方式中Auth码的验证由SM-SR执行，但是终端和eUICC的操作在第一实施方式和第二实施方式中是相等的。因此，根据本公开的第二实施方式，终端和eUICC的操作的详细描述被省略，因为已经在图7和图8中做出了相同的描述。图12例示了根据本公开的主动通过终端的配置文件下载方法的第三实施方式。参考图12，MNO1240可以如附图标记1201所示首先做出用于在不用向SM-DP1230提供特定信息的情况下生成配置文件的请求。SM-DP1230可以如附图标记1202所示根据来自MNO1240的请求基于ICCID生成配置文件。SM-DP1230可以生成Auth码作为配置文件的生成的结果。Auth码是由SM-DP1230生成的随机数并且可以被用于只有当包括所对应的随机数的打开请求被做出时才处理正常的打开。另外，在本公开中Auth码也可以被表达为认证码并且可以根据每个ICCID被生成。当SM-DP1230生成配置文件并且向MNO1240发送与所生成的配置文件有关的输出数据时，SM-DP1230也可以发送Auth码。另外，SM-DP1230可以发送关于SM-DP的地址的信息。当SM-DP1230向MNO1240发送与配置文件有关的信息时，SM-DP1230可以如附图标记1203所示以纸卡的形式将Auth码和SM-DP地址提供给MNO1240。在本公开中，尽管以纸卡的形式对ICCID、Auth码和SM-DP地址进行描述，然而通过SM-DP1230的结果的物理形式没有限制并且ICCID、Auth码和SM-DP地址可以作为各种形式的结果被制造。当用户1200如附图标记1204所示应用来向MNO1240订阅服务时，MNO1240可以如附图标记1205所示向用户1200发送关于从SM-DP1230接收到的配置文件ID、Auth码和SM-DP地址的信息。这时，该信息可以被以纸卡的形式发送，并且可以被以文本字符串、条形码或QR码的形式在纸卡中指定。另外，所对应的信息可以在被插入到NFC标签中之后被发送给用户。此外，根据本公开的实施方式，纸卡可以由终端的销售者提供给终端的购买者，但是配置文件ID、SM-DP地址或Auth码可以通过MNO1240的网站被以文本字符串、条形码或QR码的形式提供给购买包括eUICC的终端的用户。此后，如附图标记1206所示，用户1200可以将与配置文件有关的信息输入到终端1260中，该信息包括为了配置文件下载启动而提供的Auth码。将不同地配置由用户1200将与配置文件下载有关的信息输入到终端1260中的方法。例如，用户可以通过使用触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户可以通过经由终端1260的相机模块给形式为条形码或QR码的信息照相来将Auth码、配置文件ID或SM-DP地址输入到终端1260中。另选地，用户可以通过使用NFC来以能够通过与终端1260的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到终端1260中。另选地，用户可以将Auth码、配置文件ID或SM-DP地址输入到链接或者连接到终端1260的设备中。在这种情况下，链接或者连接到终端1260的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与终端1260之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到终端1260中。此外，可以实现用于将Auth码、配置文件ID或SM-DP地址输入到终端1260中的各种实施方式，并且本公开不限于上述方法中的一个。这可以是用于从将与配置文件下载有关的信息输入到终端1260中的许多方法中选择随机方法的选项。在根据本公开的第三实施方式的由终端执行的配置文件下载方法中，终端的控制器而不是eUICC将认证码的验证直接发送到SM-SR1250。当包括Auth码的与配置文件下载有关的信息被输入到终端中时，终端的控制器可以如附图标记1207所示读取与eUICC的标识对应的EID，并且生成做出用于由终端主动验证认证码的请求的HTTP安全(HTTPS)类型消息，以及如附图标记1208所示将所生成的HTTPS类型消息发送到SM-SR1250。这时，发送到SM-SR1250的拉模式Auth请求可以包括eUICC的EID和Auth码，并且在一些情况下也包括配置文件ID和SM-DP地址。当SM-SR1250从终端的控制器接收到用于验证认证码的请求时，SM-SR1250可以将拉模式Auth请求发送到SM-DP1230。如附图标记1209所示，发送到SM-DP1230的拉模式Auth请求可以包括EID、Auth码和配置文件ID。如附图标记1210所示，SM-DP1230可以通过使用包括在所接收到的拉模式Auth请求中的Auth码和配置文件ID来验证做出用于下载配置文件的请求的终端的认证码。当验证成功时，SM-DP1230可以将成功地验证的eUICC的EID和配置文件ID存储在数据库(DB)中。此后，SM-DP1230可以如附图标记1211所示响应于拉模式Auth请求而向SM-SR1250发送指示认证码的验证成功的拉模式Auth响应，并且SM-SR1250可以如附图标记1212所示将成功地认证的eUICC的EID、配置文件ID和SM-DP地址存储在DB中。随后，如附图标记1213所示，SM-SR1250可以将拉模式Auth响应发送到终端的控制器。当终端的控制器接收到指示认证码的验证成功的拉模式Auth响应时，终端的控制器可以如附图标记1214所示向eUICC内的ISD-R发送以APDU命令的形式做出用于下载配置文件的请求的命令。APDU可以是用于设备之间(例如，智能卡与计算机或移动电话之间)的数据传输的协议。当eUICC的ISD-R从终端的控制器接收到APDU命令时，eUICC的ISD-R可以生成要发送到SM-SR的如下表3中所示出的HTTPPOST消息，并且如附图标记1215所示将所生成的HTTPPOST消息发送到SM-SR1250。【表3】HTTPPOST(通过使用SCP81密钥的TLS)<报头>-EID-ISD-RAID已接收到HTTPPOST消息的SM-SR1250可以如附图标记1216所示确定所对应的EID是否和存储在DB中的EID匹配，并且如附图标记1217所示将拉模式D/L请求发送到SM-DP1230。这时，发送到SM-DP1230的拉模式D/L请求可以包括eUICC的EID和配置文件ID。SM-DP1230可以确定包括在所接收到的拉模式D/L请求中的EID是否和存储在DB中的EID匹配。当它们彼此匹配时，如附图标记1218所示，SM-DP1230确定要下载配置文件。此后，如附图标记1219所示，SM-DP1230将所对应的配置文件发送到SM-SR1250，并且如附图标记1220所示，SM-SR1250将配置文件发送到eUICC。图13是例示了根据本公开的第三实施方式的SM-DP的操作的流程图。参考图13，在操作1301中，SM-DP从MNO接收用于生成配置文件的请求。这时，MNO可能不向SM-DP提供关于ICCID或IMSI的信息。在操作1302中，SM-DP可以根据来自MNO的请求来生成配置文件并且生成用于对所对应的配置文件进行认证的认证码。该认证码可以是Auth码并且可以根据每个ICCID被生成。所生成的配置文件可以被存储在SM-DP中，并且SM-DP可以将ICCID(或配置文件ID)和认证码发送到MNO。在本公开中，认证码和配置文件ID(或ICCID)可以被称作与配置文件下载有关的信息。在操作1303中，SM-DP从SM-SR接收包括eUICC的认证(Auth)码的认证请求。SM-DP验证所对应的认证(Auth)码，并且，在验证成功时，在操作1304中将成功地验证的EID和配置文件ID存储在DB中。随后，SM-DP可以向SM-SR发送指示认证码的验证成功的消息。在操作1305中，SM-DP从SM-SR接收对主动通过终端的下载的拉模式D/L请求。所对应的请求可以包括EID和配置文件ID。SM-DP确定所接收到的EID是否和存储在DB中的EID匹配。当它们彼此匹配时，在操作1306中SM-DP可以将所对应的配置文件发送到SM-SR。图14是例示了根据本公开的第三实施方式的SM-SR的操作的流程图。参考图14，在操作1401中SM-SR可以从终端的控制器接收拉模式Auth请求。所接收到的拉模式Auth请求可以包括终端内的eUICC的EID和Auth码，并且在一些情况下也包括配置文件ID和SM-DP地址。在操作1402中，SM-SR可以向SM-DP发送做出用于验证从终端的控制器接收到的Auth码的请求的拉模式Auth请求。发送到SM-DP的拉模式Auth请求可以包括EID、Auth码和配置文件ID。当SM-DP成功地执行验证时，在操作1403中，SM-SR可以响应于拉模式Auth请求从SM-DP接收指示认证码的验证成功的拉模式Auth响应。SM-SR可以将认证码被成功地验证的eUICC的EID、配置文件ID和SM-DP地址存储在DB中，并且向终端的控制器发送指示验证成功的拉模式Auth响应。SM-SR可以在操作1404中从eUICC接收配置文件D/L请求并且识别所对应的eUICC的EID是否和存储在DB中的EID匹配，并且可以在操作1405中将拉模式D/L请求发送到SM-DP以做出用于下载配置文件的请求。当SM-DP发送所对应的配置文件时，在操作1406中，SM-SR可以接收配置文件并且将所接收到的配置文件发送到eUICC。图15是例示了根据本公开的第三实施方式的终端的操作的流程图。参考图15，在操作1501中，终端可以从用户接收配置文件(或ICCID)或认证(Auth)码的输入。在本公开中，可以不同地配置从用户接收与配置文件下载有关的信息的输入的方法。更具体地，用户可以通过使用触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户可以通过经由相机模块给形式为条形码或QR码的信息照相来将Auth码、配置文件ID或SM-DP地址输入到终端350中。另选地，用户可以通过使用NFC来以能够通过与终端350的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到终端中。另选地，用户可以将Auth码、配置文件ID或SM-DP地址输入到链接或者连接到终端的设备中。在这种情况下，链接或者连接到终端的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与终端之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到终端中。此外，可以实现用于将Auth码、配置文件ID或SM-DP地址输入到终端中的各种实施方式，并且本公开不限于上述方法中的一个。在操作1502中，终端可以识别与终端内的eUICC的标识对应的EID并且向SM-SR发送做出用于对所对应的eUICC进行认证的请求的消息。这时，做出用于验证认证码的请求的消息可以包括关于所输入的Auth码、配置文件ID和EID的信息。在操作1503中，终端可以从SM-SR接收表示认证码验证成功的认证成功消息，并且因此，向终端内的eUICC发送指示要下载配置文件的消息(APDU命令)。图16是例示了根据本公开的第三实施方式的终端内的eUICC的操作的流程图。参考图16，根据本公开的第三实施方式，因为终端的控制器做出验证认证码的请求而不是由eUICC进行对认证码的单独验证，所以eUICCC在操作1601中从终端的控制器接收做出用于下载配置文件的请求的消息。在这种情况下，Auth码由终端的控制器来验证，使得eUICC在操作1602中向SM-SR发送拉模式D/L请求。这时，所发送的请求可以包括表3中的内容。在操作1603中，eUICC可以从SM-SR下载配置文件。图17例示了根据本公开的第四实施方式的主动通过终端的配置文件下载方法的第四实施方式。参考图17，如附图标记1701所示，MNO1740可以首先做出用于在不用向SM-DP1730提供特定信息的情况下生成配置文件的请求。如附图标记1702所示，SM-DP1730可以根据来自MNO1740的请求基于ICCID生成配置文件。SM-DP1730可以生成Auth码作为配置文件的生成的结果。Auth码是由SM-DP1730生成的随机数并且可以被用于只有当包括所对应的随机数的打开请求被做出时才处理正常的打开。另外，在本公开中Auth码也可以被表达为认证码并且可以根据每个ICCID被生成。当SM-DP1730生成配置文件并且向MNO1740发送与所生成的配置文件有关的输出数据时，SM-DP1730也可以发送Auth码。另外，SM-DP1730可以发送关于SM-DP的地址的信息。这时，在根据本公开的配置文件下载方法的第四实施方式中，如附图标记1703所示，当SM-DP1730将配置文件ID(或ICCID)和Auth码发送到MNO1740时，SM-DP1730可以将相同的信息发送到SM-SR1750。当SM-DP1730向MNO1740发送与配置文件有关的信息时，如附图标记1703所示，SM-DP1730可以以纸卡的形式将Auth码和SM-DP地址提供给MNO1740。在本公开中，尽管以纸卡的形式对ICCID、Auth码和SM-DP地址进行描述，然而通过SM-DP1730的结果的物理形式没有限制并且ICCID、Auth码和SM-DP地址可以作为各种形式的结果被制造。如附图标记1704所示，当用户1700应用来向MNO1740订阅服务时，如附图标记1705所示，MNO1740可以向用户1700发送关于所接收到的配置文件ID、Auth码和SM-DP地址的信息。这时，该信息可以被以纸卡的形式发送，并且可以被以文本字符串、条形码或QR码的形式在纸卡中指定。另外，所对应的信息可以在被插入到NFC标签中之后被发送给用户。此外，根据本公开的实施方式，纸卡可以由终端的销售者提供给终端的购买者，但是配置文件ID、SM-DP地址或Auth码可以通过MNO1740的网站被以文本字符串、条形码或QR码的形式提供给购买包括eUICC的终端的用户。此后，如附图标记1706所示，用户1700可以将与配置文件有关的信息输入到终端1760中，该信息包括为了配置文件下载启动而提供的Auth码。将不同地配置由用户1700将与配置文件下载有关的信息输入到终端1760中的方法。例如，用户可以通过使用触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户可以通过经由终端1760的相机模块给形式为条形码或QR码的信息照相来将Auth码、配置文件ID或SM-DP地址输入到终端1760中。另选地，用户可以通过使用NFC来以能够通过与终端1760的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到终端1760中。另选地，用户可以将Auth码、配置文件ID或SM-DP地址输入到链接或者连接到终端1760的设备中。在这种情况下，链接或者连接到终端1760的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与终端1760之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到终端1760中。此外，可以实现用于将Auth码、配置文件ID或SM-DP地址输入到终端1760中的各种实施方式，并且本公开不限于上述方法中的一个。这可以是用于从将与配置文件下载有关的信息输入到终端1760中的许多方法中选择随机方法的选项。在根据本公开的第四实施方式的由终端执行的配置文件下载方法中，终端的控制器而不是eUICC将认证码的验证直接发送到SM-SR1750。与本公开的第三实施方式不同，认证码的验证由SM-SR而不是SM-DP1730来执行。当包括Auth码的与配置文件下载有关的信息被输入到终端中时，终端的控制器可以如附图标记1707所示读取与eUICC的标识对应的EID，并且生成做出用于由终端主动验证Auth码的请求的HTTPS类型消息，以及如附图标记1708所示将所生成的HTTPS类型消息发送到SM-SR1750。这时，发送到SM-SR1750的拉模式Auth请求可以包括终端内的eUICC的EID和Auth码，并且在一些情况下也包括配置文件ID和SM-DP地址。当SM-SR1750从终端的控制器接收到用于验证认证码的请求时，SM-SR1750可以如附图标记1709所示通过对预存储的Auth码和从eUICC接收到的Auth码进行比较来验证从eUICC接收到的Auth码。当验证成功时，SM-SR1750可以将成功地验证的EID和配置文件ID存储在DB中。另外，在这种情况下，也可以存储SM-DP地址。此后，如附图标记1710所示，SM-SR1750向终端的控制器发送表示从终端的控制器发送的EID和Auth码已被验证的拉模式Auth响应。当终端的控制器接收到表示认证码的验证成功的拉模式Auth响应时，如附图标记1711所示，终端的控制器可以向eUICC内的ISD-R发送以APDU命令的形式做出用于下载配置文件的请求的命令。APDU可以是用于设备之间(例如，智能卡与计算机或移动电话之间)的数据传输的协议。当eUICC的ISD-R从终端的控制器接收到APDU命令时，eUICC的ISD-R可以生成要发送到SM-SR的如表3中所示出的HTTPPOST消息，并且如附图标记1712所示将所生成的HTTPPOST消息发送到SM-SR1750。已接收到HTTPPOST消息的SM-SR1750可以如附图标记1713所示在DB中搜索所对应的EID并且查找配置文件ID。此后，SM-SR1750可以如附图标记1714所示向SM-DP1730发送拉模式D/L请求。这时，发送到SM-DP1730的拉模式D/L请求可以包括eUICC的EID和配置文件ID。另外，拉模式D/L请求可以包括表示认证码的成功的Auth成功指示符。SM-DP1730可以如附图标记1715所示识别包括在所接收到的拉模式D/L请求中的Auth成功指示符，或者如附图标记1716所示在没有任何标识处理(因为认证码的验证已经完成了)的情况下发送所对应的配置文件。SM-SR1750可以如附图标记1717所示将所接收到的配置文件发送到eUICC。图18是例示了根据本公开的第四实施方式的SM-SR的操作的流程图。参考图18，在操作1801中，SM-SR从SM-DP接收配置文件ID(或ICCID)和Auth码。在操作1802中，SM-SR可以从终端的控制器接收包括Auth码和EID的认证请求消息。这时，由终端的控制器发送的认证请求消息可以包括配置文件ID和SM-DP地址以及EID和Auth码。在操作1803中，SM-SR可以通过对预存储的认证码和从终端的控制器接收到的认证码进行比较来验证从终端的控制器接收到的认证码，并且，在验证成功时，向终端发送指示认证的成功的拉模式Auth响应消息。在操作1804中，SM-SR可以从eUICC接收配置文件D/L请求消息。在操作1805中，SM-SR可以向SM-DP发送包括表示认证码的验证成功的认证成功指示符的拉模式D/L请求。这时，拉模式D/L请求可以包括eUICC的EID和配置文件ID。在操作1806中，SM-SR可以从SM-DP接收所对应的配置文件并且将所接收到的配置文件发送到eUICC。与Auth码由SM-DP验证的情况(第三实施方式)不同，在本公开的第四实施方式中Auth码由SM-SR验证，但是剩余的实体操作是相等的。更具体地，SM-DP的操作等于图10中的操作，终端的操作等于图15中的操作，并且eUICC的操作等于图16中的操作。因此，其详细描述在本文中被省略。图19是例示了根据本公开的实施方式的SM-DP或SM-SR的配置的框图。参考图19，根据本公开的SM-DP或SM-SR可以是服务器，并且每个服务器1900可以包括通信单元1901、控制器1903和存储单元1905。通信单元1901可以执行数据通信。通信单元1901的通信方案不限于有线通信方案和无线通信方案中的一个。SM-DP的控制器1903可以生成用于对要提供给终端的配置文件进行认证并且用于终端下载该配置文件的认证信息并且基于终端下载配置文件的认证信息验证结果来发送配置文件。另外，控制器1903可以接收由配置文件管理服务器从终端获取的认证信息并且基于所接收到的认证信息验证结果将配置文件发送到配置文件管理服务器。此外，控制器1903向配置文件管理服务器发送所生成的配置文件和认证信息的标识，但是根据由配置文件管理服务器对终端的认证信息验证结果将配置文件发送到配置文件管理服务器。SM-SR的控制器可以从终端接收用于对配置文件的安装进行认证的认证信息，根据认证信息的验证结果来接收配置文件，并且将所接收到的配置文件发送到包括在终端中的eUICC。另外，控制器可以向配置文件生成服务器发送包括从终端接收到的认证信息的配置文件下载请求并且根据由配置文件生成服务器对认证信息的验证结果来接收配置文件。此外，控制器从配置文件生成服务器接收用于对配置文件的安装进行认证的认证信息，但是对从配置文件生成服务器接收到的认证信息和从终端接收到的认证信息进行比较。当从配置文件生成服务器接收到的认证信息和从终端接收到的认证信息基于比较的结果彼此匹配时，控制器可以向配置文件生成服务器发送配置文件下载请求。图20例示了根据本公开的实施方式的在eUICC中安装配置文件的终端的实施方式。参考图20，根据本公开当配置文件通过使用认证码的验证被安装在包括在终端中的eUICC中时，终端可以包括第一终端2050和第二终端2060。用户2040可以购买包括第一终端2050和第二终端2060的一组终端或者单独地购买第一终端2050和第二终端2060。第二终端2060可以是依赖于第一终端2050的终端。也就是说，第一终端2050可以是主终端，并且第二终端2060可以是子终端。在这种情况下，第一终端2050的第一控制器2052可以是主控制器，并且第二终端2060的第二控制器2061可以是子控制器。在本公开中，尽管作为示例为了描述的方便描述了eUICC2062未被包括在第一终端2050中而是被包括在第二终端2060中的情况，然而本公开不限于此并且eUICC可以被包括在多个终端中的全部中。另外，尽管描述了终端的数目为2的情况，然而通过与第一终端2050与第二终端2060之间的连接相同的连接来配置的两个或更多个终端可以操作。第一终端2050可以包括输入单元2051和第一控制器2052。输入单元2051可以包括接收各种类型的输入信号的设备。更具体地，根据本公开的实施方式，输入单元2051可以包括音频模块，并且该音频模块可以包括扬声器、受话器、耳机或麦克风以接收通过该麦克风输入的声音信息。根据本公开的实施方式，输入单元2051可以包括相机模块，并且该相机模块可以包括图像传感器和透镜以接收通过相机输入的静止图像和运动图像。根据本公开的实施方式，输入单元2051可以是触摸面板，并且可以包括(数字)笔传感器、键或超声输入设备以识别用户的物理接触或接近。根据本公开的实施方式，输入单元2051可以是RF传感器，并且可以通过使用NFC标签来接收输入。根据本公开的输入单元2051可以通过能够用来处理电子信号的各种输入方法以及上述输入设备来操作。第一终端2050的第一控制器2052可以执行用于下载要存储在第二终端2060内的eUICC2062中的配置文件的认证码的验证处理。第二终端2060可以包括第二控制器2061和eUICC2062。第二控制器2061可以用作用于允许第一终端2050的第一控制器2052获取第二终端2060的eUICC2062的EID的代理。另外，第二控制器2061可以用作用于触发根据本公开的认证码的验证的代理。在下文中，将参考图20详细地描述第一终端2050和第二终端2060的操作。首先，MNO2000可以如附图标记2001所示首先做出用于生成配置文件的请求，并且SM-DP2020可以生成配置文件，生成用于下载所对应的配置文件的认证码(Auth码)，并且如附图标记2002所示将所生成的Auth码发送到MNO2000。当用户2040如附图标记2003所示向MNO2000做出用于使用移动通信服务的请求以便使用该移动通信服务时，MNO2000如附图标记2004所示向用户发送认证码(Auth码)。这时，已经描述了MNO2000将配置文件ID和SM-DP地址以及认证码(Auth码)发送到用户2040。另外，由SM-DP2020发送到MNO2000的认证码被以纸卡的形式提供给MNO2000。在本公开中，尽管以纸卡的形式对ICCID、Auth码和SM-DP地址进行描述，然而通过SM-DP2020的结果的物理形式没有限制并且ICCID、Auth码和SM-DP地址可以作为各种形式的结果被制造。可以以文本字符串、条形码或QR码的形式在纸卡中指定信息。另外，所对应的信息可以在被插入到NFC标签中之后被发送给用户。用户2040可以将认证码或包括认证码的与配置文件下载有关的信息输入到第一终端2050的输入单元2051中。将不同地配置由用户2040将与配置文件下载有关的信息输入到输入单元2051中的方法。例如，用户2040可以通过使用第一终端2050的输入单元2051的触摸屏来以基于文本的信息的形式直接输入Auth码、配置文件ID或SM-DP地址。另选地，用户2040可以通过经由第一终端2050的输入单元2051的相机模块给形式为条形码或QR码的信息照相将Auth码、配置文件ID或SM-DP地址输入到第一终端2050的输入单元2051中。另选地，用户2040可以通过使用NFC来以能够通过与第一终端2050的输入单元2051的NFC模块接触而被读取的NFC标签的形式将Auth码、配置文件ID或SM-DP地址输入到第一终端2050的输入单元2051中。另选地，用户2040可以将Auth码、配置文件ID或SM-DP地址输入到链接或者连接到第一终端2050的设备中。在这种情况下，链接或者连接到第一终端2050的设备可以是智能电话或可穿戴设备。这时，形式为条形码或QR码的与配置文件的下载有关的信息是通过分别设置在已连接设备处的相机输入的，并且可以通过所对应的设备与第一终端2050之间的有线/无线通信来将Auth码、配置文件ID或SM-DP地址输入到第一终端2050中。当包括认证码的与配置文件下载有关的信息被输入到第一终端2050的输入单元2051中时，第一控制器2052可以确定与第一终端2050配对的第二终端2060的存在。当第一终端2050和第二终端2060通过蓝牙配对时，第一控制器2052可以如附图标记2006所示从第二控制器2061获取嵌入在第二终端2060中的eUICC2062的EID。此后，可以根据本公开的认证码的验证的各种实施方式来执行认证码的验证。根据本公开的各种实施方式，第二终端2060的eUICC2062做出用于验证认证码的请求，并且SM-DP2020验证认证码。这时，第一终端2050的第一控制器2052可以接收用于通过第二控制器2061来验证eUICC2062的请求，并且因此如附图标记2007所示向SM-SR2030发送拉模式D/L请求或拉模式Auth请求，并且如附图标记2005所示接收对请求的响应。第一终端2050的第一控制器2052将所接收到的响应发送到第二终端2060。这时，根据第一至第四实施方式认证码的验证可以由SM-SR2030和SM-DP2020中的一个来执行。更具体地，当SM-DP2020执行验证时，SM-SR2030可以将拉模式D/L请求发送到SM-DP2020。这时，所对应的请求消息可以包括EID和Auth码，并且在一些情况下可以包括配置文件ID和SM-DP地址。已接收到拉模式D/L请求的SM-DP2020可以基于Auth码的匹配来验证做出了拉模式D/L请求的终端。当验证成功时，SM-DP2020可以将配置文件发送到SM-SR2030。此后，eUICC2062从SM-SR2030下载配置文件。在这种情况下，通过eUICC2062的配置文件下载可以通过第一终端2050以及第一终端2050的第一控制器2052来执行。当SM-SR2030从SM-DP2020提前接收Auth码以直接验证认证码时，发送到第一终端2050的认证码验证响应可以是如附图标记2005所示指示验证成功的响应。当从SM-SR2030接收到表示验证成功的响应时，第一终端2050的第一控制器2052可以如附图标记2009所示将所对应的响应发送到第二终端2060的第二控制器2061，并且第二终端2060的第二控制器2061可以如附图标记2010所示根据所对应的响应来下载配置文件。也就是说，图20的实施方式可以使用利用认证码的上述验证方法中的全部，但是具有的差异仅在于终端被划分成两个终端并且第一终端2050和第二终端2060通过蓝牙配对。根据本公开，当在诸如主终端和子终端的终端之间存在预定依赖性(即，通过蓝牙或Wi-Fi连接配对)时，与下载嵌入在子终端中的eUICC的配置文件所需要的认证码的验证有关的一系列处理可以由主终端执行。在这种情况下，子终端的控制器(图20中的第二终端2060的第二控制器2061)可以根据相关技术仍然起供应作用。虽然已经参考本公开的各种实施方式示出并描述了本公开，但是本领域的技术人员应当理解的是，在不脱离如由所附权利要求及其等同物所限定的本公开的精神和范围的情况下，可以在其中做出形式和细节上的各种改变。当前第1页1 2 3