用于為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