KR20200145775A - 통신서비스를 제공하는 방법 및 장치 - Google Patents

Abstract

본 개시의 일 실시예에 따른 주 단말의 통신 서비스를 제공하는 방법은, 디스커버리 절차를 통해, 액세스 포인트로 동작하는 IoT(Internet of Things) 단말을 인지하여 접속(access)하는 단계, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 상기 IoT 단말로 전송하는 단계, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 IoT 단말과의 제1 연결을 해지하는 단계, 상기 IoT 단말의 접속 요청에 따라, 상기 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행하는 단계 및 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하는 단계를 포함할 수 있다.

Description

통신서비스를 제공하는 방법 및 장치{METHOD AND APPARATUS FOR PROVIDING COMMUNICATION SERVICE}

본 개시는 eSIM을 적용한 IoT 단말(이하 eSIM IoT단말)에 프로파일을 다운로드 설치하여 통신 서비스를 제공 하기 위한 주 단말과 eSIM IoT단말간의 통신 서비스 제공 방법에 관한 것이다. 또한, 본 개시는 eUICC를 선택하는 방법 및 장치에 관한 것으로, eSIM 프로파일을 설치하고 관리하는 방법 및 장치에 관한 것이다.

4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE(Long Term Evolution) 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및SCMA(sparse code multiple access) 등이 개발되고 있다. 한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다. 이에, 기존 4G 및 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 4G 및 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다.

상술한 것과 이동통신 시스템의 발전에 따라 다양한 이동통신 기반 서비스를 제공할 수 있게 됨으로써, 이러한 서비스들을 효과적으로 제공하기 위한 방안이 요구되고 있다. 이러한 이동통신 시스템에 접속하기 위해 가입자의 망 접속을 위한 인증 제어 모듈을 포함한 무선통신시스템에서 UICC(Universal Integrated Circuit Card)의 진화된 형태로, eUICC(embedded UICC), iUICC(integrated UICC), iSSP(integrated Secure Service Platform)등의 Secure Element 들이 개발되어 IoT단말에 적용 또는 적용을 위해 개발 중에 있다.

eUICC 적용 단말을 구매하여 해당 단말에서의 직접 개통을 원하거나 eUICC에 다운로드된 eUICC 프로파일에 문제가 있어 망 접속을 시도하는 경우, 네트워크에서는 해당 가입자를 성공적으로 인증할 수 없으므로 망 접속을 허용하지 않는다.

이를 해소하기 위한 방법으로 eUICC 프로파일을 eUICC 카드로 다운로드하는 방법에 대한 표준화 단체인 GSMA(Global System for Mobile communication Association)는, eUICC 프로파일을 단말 내의 eUICC에 다운로드를 하기 위한 네트워크를 획득하는 방법으로 Wi-Fi 또는 eUICC 프로파일과 동일하나 그 용도를 Connectivity 제공을 위해서만 한정한 프로파일인 ProvisioningProfile (이하 Provisioning 프로파일로 표기)을 제시하고 있다.

본 개시의 다양한 실시 예에 따르면, 주 단말과의 연동을 통해 eSIM IoT단말에 프로파일을 다운로드 하여 설치하기 위한 표준 기반의 통신 개통 방법 및 절차를 제공하고자 한다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말이 통신 서비스를 선택하여 통신 연결을 하기 위한 방법 및 장치를 제공할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말이 통신 연결을 하기 위한 프로파일을 온라인으로 다운로드 하여 설치하고 관리하는 방법 및 장치를 제공할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말이 이벤트를 효율적으로 다운로드 받을 수 있는 방법 및 장치를 제공할 수 있다.

주 단말이 특정 IoT단말이 eSIM을 적용한 단말이며 해당 단말에 프로파일 다운로드 설치가 필요한 단말임을 인지하는 동작, 주 단말이 eSIM IoT단말에서 프로파일 다운로드를 위한 소정의 정보로써 Activation Code를 발급받기 위해 eSIM IoT단말로부터 필요한 정보를 수집하는 동작, eSIM IoT단말이 주 단말을 AP로 하여 OCF연결 eSIM Easyseup을 수행 중임에 대한 증빙을 포함해 접속을 시도하는 동작, 주 단말에서OCF eSIM Setup과정 중이었음을 판단하고 기존 연결을 재 설정하는 동작, 주 단말에서 eSIM IoT단말에 Activation Code를 전달하여, eSIM IoT단말이 프로파일 다운로드를 시작하는 동작, eSIM IoT단말에서는 프로파일 다운로드 과정에 필요한 사용자 Interaction 처리를 주 단말에 통지하고 이에 대한 응답을 처리하여 프로파일 다운로드를 완료하는 동작을 포함하여 해결하고자 한다.

본 개시의 일 실시예에 따른 주 단말의 통신 서비스를 제공하는 방법은, 디스커버리 절차를 통해, 액세스 포인트로 동작하는 IoT(Internet of Things) 단말을 인지하여 접속(access)하는 단계, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 상기 IoT 단말로 전송하는 단계, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 IoT 단말과의 제1 연결을 해지하는 단계, 상기 IoT 단말의 접속 요청에 따라, 상기 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행하는 단계 및 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하는 단계를 포함할 수 있다.

일 실시예에서, 상기 제1 eSIM 셋업 절차는, 상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계 및 통신 서비스 플랜 구매 단계를 포함할 수 있다.

일 실시예에서, 상기 제2 eSIM 셋업 절차는, 상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함할 수 있다.

일 실시예에서, 상기 주 단말은, 상기 IoT 단말의 접속 요청에 따라, 상기 주 단말의 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행 하는 단계에서, 액세스 포인트로 동작할 수 있다.

일 실시예에서, 상기 인증 정보는, SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함할 수 있다.

일 실시예에서, IoT(Internet of Things) 단말의 통신 서비스를 제공하는 방법은, 주 단말의 접속 요청에 따라, 상기 주 단말과 제1 연결을 수행하는 단계, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 수신하는 단계, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 주 단말과의 제1 연결을 해지하는 단계, 상기 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행하는 단계 및 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하는 단계를 포함할 수 있다.

일 실시예에서, 상기 제1 eSIM 셋업 절차는, 상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계 및 통신 서비스 플랜 구매 단계를 포함할 수 있다.

일 실시예에서, 상기 제2 eSIM 셋업 절차는, 상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함할 수 있다.

일 실시예에서, 상기 주 단말의 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행하는 단계에서, 상기 주 단말은 액세스 포인트로 동작할 수 있다.

일 실시예에서, 상기 인증 정보는, SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함할 수 있다.

일 실시예에서, 통신 서비스를 제공하는 주 단말은, 통신부 및 디스커버리 절차를 통해, 액세스 포인트로 동작하는 IoT(Internet of Things) 단말을 인지하여 접속(access)하고, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 상기 IoT 단말로 전송하며, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 IoT 단말과의 제1 연결을 해지하고, 상기 IoT 단말의 접속 요청에 따라, 상기 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행하고, 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하도록 제어하는 프로세서를 포함할 수 있다.

일 실시예에서, 상기 제1 eSIM 셋업 절차는, 상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계 및 통신 서비스 플랜 구매 단계를 포함할 수 있다.

일 실시예에서, 상기 제2 eSIM 셋업 절차는, 상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함할 수 있다.

일 실시예에서, 상기 주 단말은, 상기 IoT 단말의 접속 요청에 따라, 상기 주 단말의 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행 시 액세스 포인트로 동작할 수 있다.

일 실시예에서, 상기 인증 정보는, SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함할 수 있다.

일 실시예에서, 통신 서비스를 제공하는 IoT(Internet of Things) 단말은, 통신부 및 주 단말의 접속 요청에 따라, 상기 주 단말과 제1 연결을 수행하고, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 수신하며, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 주 단말과의 제1 연결을 해지하고, 상기 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행하며, 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하도록 제어하는 프로세서를 포함할 수 있다.

일 실시예에서, 상기 제1 eSIM 셋업 절차는, 상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계 및 통신 서비스 플랜 구매 단계를 포함할 수 있다.

일 실시예에서, 상기 제2 eSIM 셋업 절차는, 상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함할 수 있다.

일 실시예에서, 상기 주 단말은, 상기 주 단말의 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행 시, 액세스 포인트로 동작할 수 있다.

일 실시예에서, 상기 인증 정보는, SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함할 수 있다.

본 개시의 일 실시예에 따른 무선 통신 시스템에서 단말의 통신 방법은, eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API(Local Profile Assistant Application Programming Interface) 정보를 적어도 하나 이상 포함하는 LPA API 목록(List)을 생성하는 단계; 상기 LPA API 목록을 서버로 전송하며, 상기 서버로부터 적어도 하나 이상의 활성화 코드와 상기 적어도 하나 이상의 활성화 코드 각각에 대응되는 적어도 하나 이상의 eUICC 식별 정보를 수신하는 단계; 상기 적어도 하나 이상의 eUICC 식별 정보에 기초하여 eUICC를 선택하는 단계; 및 상기 선택한 eUICC에 대하여, 상기 선택한 eUICC의 eUICC 식별 정보에 대응되는 활성화 코드를 처리하는 단계를 포함할 수 있다.

일 실시예에서, 상기 LPA API 목록을 생성하는 단계는, 복수 개의 eUICC 중 제1 eUICC를 선택하는 단계 및 상기 선택한 제1 eUICC에 대한 제1 LPA API 정보를 생성하는 단계를 포함하고, 상기 LPA API 정보는, 상기 단말의 단말 정보, 상기 제1 eUICC에 대한 eUICC 정보, 및 상기 제1 eUICC에 대한 식별 정보를 포함할 수 있다.

일 실시예에서, 상기 LPA API 목록을 생성하는 단계는, 추가적으로 선택할 eUICC가 있는지 여부를 판단하는 단계, 상기 추가적으로 선택할 eUICC가 있는 경우, 상기 복수 개의 eUICC 중 제2 eUICC를 선택하는 단계 및 상기 선택한 제2 eUICC에 대한 제2 LPA API 정보를 생성하는 단계를 포함할 수 있다.

일 실시예에서, 상기 LPA API 목록을 생성하는 단계는, 상기 추가적으로 선택할 eUICC가 없는 경우, 상기 제1 LPA API 정보와 상기 제2 LPA API 정보를 포함하는 상기 LPA API 목록을 생성하는 단계를 포함할 수 있다.

일 실시예에서, 상기 eUICC 식별 정보는, eUICC 색인번호(index)를 포함할 수 있다.

일 실시예에서, 상기 eUICC 색인 번호는, eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID), eUICC와 모뎀을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID) 또는 eUICC에 대해 단말 내지 LPA가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID) 중 적어도 하나 이상을 기초로 생성될 수 있다.

일 실시예에서, 상기 eUICC를 선택하는 단계는, 상기 서버로부터 하나의 eUICC에 대한 식별 정보를 수신한 경우, 상기 하나의 eUICC에 대한 식별 정보에 대응된 eUICC를 선택하고, 상기 서버로부터 복수 개의 eUICC에 대한 식별 정보를 수신하거나 또는 eUICC에 대한 식별 정보 없이 활성화 코드를 수신하는 경우, 기 설정된 기준에 따라 eUICC를 선택하는 단계를 포함할 수 있다.

일 실시예에서, 상기 기 설정된 기준에 따라 eUICC를 선택하는 단계는, 상기 복수 개의 eUICC 각각에 대한 잔여 가용 메모리 양, 설치된 프로파일 개수, 지원하는 eSIM 기능, 연결된 모뎀이 지원 가능한 무선 접속 기술 또는 LPA가 지원하는 eSIM 기능 중 적어도 하나 이상을 기초로 eUICC를 선택하는 단계를 포함할 수 있다.

본 개시의 다른 일 실시예에 따른 무선 통신 시스템에서 기지국의 통신 방법은, 단말로부터 eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API 정보를 적어도 하나 이상 포함하는 LPA API 목록을 수신하는 단계; 상기 LPA API 목록에서 하나의 LPA API 정보를 선택하는 단계; 상기 선택한 LPA API 정보에 기초하여 이벤트에 대응하는 활성화 코드를 생성하는 단계; 상기 생성한 활성화 코드와 상기 선택한 LPA API 정보에 대응되는 eUICC 식별 정보를 상기 단말로 전송하는 단계; 및 상기 활성화 코드에 대응하는 상기 이벤트를 처리하는 단계를 포함할 수 있다.

일 실시예에서, 상기 LPA API 정보는 상기 단말의 단말 정보, 상기 제1 eUICC에 대한 eUICC 정보, 및 상기 제1 eUICC에 대한 식별 정보를 포함할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템의 단말은, 송수신부; 프로파일이 저장되는 적어도 복수 개의 eUICC(embedded Universal Integrated Circuit Card); 및 eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API(Local Profile Assistant Application Programming Interface) 정보를 적어도 하나 이상 포함하는 LPA API 목록(List)을 생성하고, 상기 LPA API 목록을 서버로 전송하며, 상기 서버로부터 적어도 하나 이상의 활성화 코드와 상기 적어도 하나 이상의 활성화 코드 각각에 대응되는 적어도 하나 이상의 eUICC 식별 정보를 수신하며, 상기 적어도 하나 이상의 eUICC 식별 정보에 기초하여 eUICC를 선택하고, 상기 선택한 eUICC에 대하여, 상기 선택한 eUICC의 eUICC 식별 정보에 대응되는 활성화 코드를 처리하는 적어도 하나 이상의 프로세서를 포함할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 복수 개의 eUICC 중 제1 eUICC를 선택하고, 상기 선택한 제1 eUICC에 대한 제1 LPA API 정보를 생성하며, 상기 LPA API 정보는, 상기 단말의 단말 정보, 상기 제1 eUICC에 대한 eUICC 정보, 및 상기 제1 eUICC에 대한 식별 정보를 포함할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 추가적으로 선택할 eUICC가 있는지 여부를 판단하고, 상기 추가적으로 선택할 eUICC가 있는 경우, 상기 복수 개의 eUICC 중 제2 eUICC를 선택하며, 상기 선택한 제2 eUICC에 대한 제2 LPA API 정보를 생성할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 상기 추가적으로 선택할 eUICC가 없는 경우, 상기 제1 LPA API 정보와 상기 제2 LPA API 정보를 포함하는 상기 LPA API 목록을 생성할 수 있다 .

일 실시예에서, 상기 eUICC 식별 정보는, eUICC 색인번호(index)를 포함할 수 있다.

일 실시예에서, 상기 eUICC 색인 번호는, eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID), eUICC와 모뎀을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID) 또는 eUICC에 대해 단말 내지 LPA가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID) 중 적어도 하나 이상을 기초로 생성될 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 상기 서버로부터 하나의 eUICC에 대한 식별 정보를 수신한 경우, 상기 하나의 eUICC에 대한 식별 정보에 대응된 eUICC를 선택하고, 상기 서버로부터 복수 개의 eUICC에 대한 식별 정보를 수신하거나 또는 eUICC에 대한 식별 정보 없이 활성화 코드를 수신하는 경우, 기 설정된 기준에 따라 eUICC를 선택할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 상기 복수 개의 eUICC 각각에 대한 잔여 가용 메모리 양, 설치된 프로파일 개수, 지원하는 eSIM 기능, 연결된 모뎀이 지원 가능한 무선 접속 기술 또는 LPA가 지원하는 eSIM 기능 중 적어도 하나 이상을 기초로 eUICC를 선택할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템의 기지국은, 송수신부; 및 단말로부터 eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API 정보를 적어도 하나 이상 포함하는 LPA API 목록을 수신하고, 상기 LPA API 목록에서 하나의 LPA API 정보를 선택하며, 상기 선택한 LPA API 정보에 기초하여 이벤트에 대응하는 활성화 코드를 생성하고, 상기 생성한 활성화 코드와 상기 선택한 LPA API 정보에 대응되는 eUICC 식별 정보를 상기 단말로 전송하며, 상기 활성화 코드에 대응하는 상기 이벤트를 처리하는 적어도 하나 이상의 프로세서를 포함할 수 있다.

일 실시예에서, 상기 LPA API 정보는 상기 단말의 단말 정보, 상기 단말이 선택한 eUICC에 대한 eUICC 정보, 및 상기 단말이 선택한 eUICC에 대한 식별 정보를 포함할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 단말은, 송수신부; 및 적어도 하나 이상의 프로세서; 를 포함하고, 상기 적어도 하나 이상의 프로세서는 서버로부터 활성화 코드 절차 시작 요청 메시지를 수신하고, LPA API 정보 목록을 생성 및 선별하고, 서버로 LPA API 정보 목록을 송신하고, 서버로부터 적어도 활성화 코드와 eUICC 색인번호를 수신하고, 활성화 코드를 참조하여 서버로 이벤트 요청 메시지를 송신하고, 서버로부터 이벤트의 일부 또는 전체를 수신하도록 상기 송수신부를 제어할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 서버는, 송수신부; 및 적어도 하나 이상의 프로세서; 를 포함하고, 상기 적어도 하나 이상의 프로세서는 단말로 활성화 코드 절차 시작 요청 메시지를 송신하고, 단말로부터 LPA API 정보 목록을 수신하고, 서버로 이벤트 생성 요청 메시지를 송신하고, 서버로부터 이벤트 식별자를 수신하고, 단말로 활성화 코드와 선택된 eUICC 색인번호를 송신하도록 상기 송수신부를 제어할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 단말은, 서버로부터 활성화 코드 절차 시작 요청 메시지를 수신하는 수신부를 포함하고, 단말에 장착된 하나 이상의 eUICC 그리고/또는 하나 이상의 모뎀의 정보를 수집하는 제어부를 포함하고, LPA API 정보 목록을 생성하고 선별하는 제어부를 포함하고, 서버로 LPA API 정보 목록을 송신하는 송신부를 포함하고, 서버로부터 적어도 활성화 코드와 eUICC 색인번호를 수신하는 수신부를 포함하고, eUICC 색인번호를 참조하여 eUICC를 선택하는 제어부를 포함하고, 활성화 코드를 참조하여 서버로 이벤트 요청 메시지를 송신하는 송신부를 포함하고, 서버로부터 이벤트의 일부 또는 전체를 수신하는 수신부를 포함하고, 수신한 일부 또는 전체의 이벤트를 선택된 eUICC에 대해 처리하는 제어부를 포함할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 서버는, 단말로 활성화 코드 절차 시작 요청 메시지를 송신하는 송신부를 포함하고, 단말로부터 LPA API 정보 목록을 수신하는 수신부를 포함하고, LPA API 정보 목록을 참조하여 eUICC를 적어도 하나 이상 선택하는 제어부를 포함하고, 서버로 이벤트 생성 요청 메시지를 송신하는 송신부를 포함하고, 서버로부터 이벤트 식별자를 수신하는 수신부를 포함하고, 이벤트 식별자를 참조하여 이벤트에 대응하는 활성화 코드를 생성하는 제어부를 포함하고, 단말로 활성화 코드와 선택된 eUICC 색인번호를 송신하는 송신부를 포함할 수 있다.

본 개시에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 개시의 다양한 실시 예에 따르면, 주 단말과의 제조사가 다르거나, 이동통신망 접속을 위한 Credential이 없이 출시(예. Provisioning Profile이 없이 출시)되었거나 통신서비스 가입을 위한 사용자 인증 정보(예. SIM 카드)가 없는 eSIM 탑재 IoT 단말의 경우에도 주 단말과 연동을 통해 통신 서비스를 가입/개통할 수 있다.

본 개시의 다양한 실시 예에 따르면, IoT단말이 주 단말과 AP 역할을 변경하여 재 연결하는 경우에, eSIM Easyseup을 수행 중이던 단말을 판별하고, 이전 세션을 이어서 남은 프로파일 다운로드 절차를 안전하게 완료할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말이 통신 서비스를 선택하여 통신 연결을 하기 위한 방법 및 장치를 제공할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말이 통신 연결을 하기 위한 프로파일을 온라인으로 다운로드 하여 설치하고 관리하는 방법 및 장치를 제공할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말이 이벤트를 효율적으로 다운로드 받을 수 있는 방법 및 장치를 제공할 수 있다.

도 1은 OCF모듈과 GSMA 모듈 간 관계도 및 통신 처리를 도시한 도면이다.
도 2는 본 개시의 실시 예에 따른OCF 표준을 사용하여 eSIM IoT단말의 통신 개통을 제공하는 전체적인 과정을 도시한 도면이다.
도 3는 앞선 도 4에 데이터 플랜 정보 제공/플랜 구매에 대한 동작을 상세하게 도시한 도면이다.
도 4는 앞선 도 4에 GSMA SGP.22를 준용하는 Profile D/L 수행에 대한 동작을 상세하게 도시한 도면이다.
도 5는 주 단말이 단말이 지정한 조건을 참조하여 eSIM Easyseup을 위한 절차로 진행 여부를 판단하고 이후 작업을 수행하는 방법을 도시한 도면이다.
도 6은 임시 사용할 SSID와 Password를 전달하여 사용하는 방법을 도시한 도면이다.
도 7는 단말간 연결 시 확보한 Device 식별 ID를 활용하는 방법을 도시한 도면이다.
도 8는 기존 단말간 OCF 세션 생성을 위해 수행했던 DTLS Handshaking 의 정보를 활용하는 방법을 도시한 도면이다.
도 9는 신규로 Application Layer에서의 Transaction ID를 생성/저장해 두었다가 사용하는 방법을 도시한 도면이다.
도 10는 IoT단말과 주 단말의 재 연결 시 이전 EPS 정보를 가지고 사용하는 방법을 도시한 도면이다.
도 11은 본 개시의 일부 실시예에 따른 무선 통신 시스템에서 단말의 세부 구성을 도시한 도면이다.
도 12는 본 개시의 일 실시 예에 따른 단말이 고정된 프로파일이 탑재된 UICC를 이용하여 이동통신 네트워크에 연결하는 방법을 도시하는 도면이다.
도 13은 본 개시의 일 실시 예에 따른 단말에 하나의 모뎀과 하나의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 시스템의 구성을 도시하는 도면이다.
도 14는 본 개시의 일 실시 예에 따른 단말에 하나의 모뎀과 하나의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 절차를 도시하는 도면이다.
도 15는 본 개시의 일 실시 예에 따른 단말에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 시스템의 구성을 도시하는 도면이다.
도 16은 본 개시의 일 실시 예에 따른 단말에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 절차를 도시하는 도면이다.
도 17은 본 개시의 일 실시 예에 따른 단말에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 사용자 및 단말과 사업자 서버가 활성화 코드를 처리할 eUICC를 선택하는 절차의 예를 도시하는 도면이다.
도 18은 본 개시의 일 실시 예에 따른 단말 동작 절차의 예를 도시하는 순서도이다.
도 19는 본 개시의 일 실시 예에 따른 단말(400)의 구성요소를 도시하는 블록도이다.
도 20은 본 개시의 일 실시 예에 따른 사업자 서버(450)의 구성요소를 도시하는 블록도이다.

이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명하기에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성 요소에는 동일한 참조 번호를 부여하였다. 본 개시에 따른 기술적 사상의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다. 또한 본 개시를 설명함에 있어서 관련된 기능 또는 구성에 대한 구체적인 설명이 본 개시에 따른 기술적 사상의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.

이하, 기지국은 단말의 자원할당을 수행하는 주체로서, gNode B, eNode B, Node B, BS (Base Station), 무선 접속 유닛, 기지국 제어기, 또는 네트워크 상의 노드 중 적어도 하나일 수 있다. 단말은 UE (User Equipment), MS (Mobile Station), 셀룰러폰, 스마트폰, 컴퓨터, 또는 통신기능을 수행할 수 있는 멀티미디어시스템을 포함할 수 있다. 본 개시에서 하향링크(Downlink; DL)는 기지국이 단말에게 전송하는 신호의 무선 전송 경로이고, 상향링크는(Uplink; UL)는 단말이 기국에게 전송하는 신호의 무선 전송경로를 의미한다. 또한, 이하에서 LTE 혹은 LTE-A 시스템을 일 예로서 설명할 수도 있지만, 유사한 기술적 배경 또는 채널형태를 갖는 다른 통신시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어 LTE-A 이후에 개발되는 5세대 이동통신 기술(5G, new radio, NR)이 본 개시의 실시예가 적용될 수 있는 시스템에 포함될 수 있으며, 이하의 5G는 기존의 LTE, LTE-A 및 유사한 다른 서비스를 포함하는 개념일 수도 있다. 또한, 본 개시는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다. 이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다.

이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.

또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예를 들면, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다. 이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 실시예에서 '~부'는 하나 이상의 프로세서를 포함할 수 있다.

무선통신시스템에서 UICC(Universal Integrated Circuit Card)는 이동 통신 단말기 등에 삽입하여 사용하는 스마트카드(smart card)이고, UICC는 이동통신사업자의 망에 접속하기 위한 접속 제어 모듈을 포함할 수 있다. 일부 실시예에 따르면, 접속 제어 모듈의 예로는 USIM(Universal Subscriber Identity Module), SIM(Subscriber Identity Module), ISIM(IP Multimedia Service Identity Module) 등이 있으며, 상기 예시에 제한되지 않는다. UICC는 UICC카드 또는 USIM카드, SIM카드로도 불리며 통상 SIM카드로 불릴 수 있다. UICC는 이동 통신 가입자의 개인정보를 저장할 수 있고, 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 (traffic) 보안 키(key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 한다.

IoT(Internet of Things) 분야의 확산 등으로 eUICC(embedded UICC)가 웨어러블 디바이스(Wearable Device), 자동차, 스마트 미터 등의 다양한 단말에 적용되고 있다. eUICC는 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 의미할 수 있다. 즉 eUICC는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 포함할 수 있으며, eUICC에 다운로드 받는 SIM 모듈정보를 eUICC 프로파일이라고 할 수 있다. eUICC 프로파일은 SIM 프로파일(SIM Profile), eSIM Profile, eSIM Profile Package, eSIM 프로파일 이라는 용어로 혼용해서 설명될 수 있다.

eSIM 프로파일이 다운로드 될 수 있도록 생성, 준비 또는 저장하고 있는 서버를Subscription Manager and Data Preparation 서버 또는 SM-DP서버, Subscription Manager and Data Preparation+ 서버, SM-DP+ 서버, DP+서버라고 칭할 수 있다. eUICC가 적용된 단말에서 사용자가 eUICC에 저장된 정보를 읽고 단말에 디스플레이 해 주기 위해서는 단말은 GSMA(Global System for Mobile Communication Association)에서 정의한 LPA(Local Profile Agent) 애플리케이션을 실행해야 한다.

이하의 명세서에서 SIM 카드라 함은 UICC 카드, USIM 카드, ISIM이 포함된 UICC 등을 포함하는 의미로 사용될 수 있다. 다시 말해서, SIM 카드에 대한 기술적 적용은 USIM 카드, ISIM 카드 또는 일반적인 UICC 카드에도 동일하게 적용될 수 있다. 일부 실시 예에 따르면, SIM 카드는 이동 통신 가입자의 개인정보를 저장하고, 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 (traffic) 보안 키(key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 할 수 있다. 또한 일부 실시 예에 따르면, SIM 카드는 SIM 카드 제조 시 특정 이동통신 사업자의 요청에 의해 해당 사업자를 위한 전용 카드로 제조될 수 있으며, 해당 사업자의 네트워크 접속을 위한 인증 정보, 예를 들어, USIM(Universal Subscriber Identity Module) 어플리케이션 및 IMSI (International Mobile Subscriber Identity), K(Subscriber Key) 값, OPc(Operator Constant) 값 등이 사전에 SIM 카드에 탑재되어 출고될 수 있다. 따라서 제조된 SIM 카드는 해당 이동통신 사업자가 납품 받아 가입자에게 제공하며, 이후 필요 시에는 단말이 OTA (Over The Air) 등의 기술을 활용하여 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리를 수행할 수 있다.

가입자는 소유한 이동통신 단말기에 UICC 카드를 삽입하여 이동통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하며, 단말기 교체 시 UICC 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 UICC 카드에 저장된 인증정보, 이동통신 전화번호, 개인 전화번호부 등을 새로운 단말기에서 그대로 사용할 수 있다. 일부 실시 예에 따르면, UICC 카드에 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 또한 일부 실시 예에 따르면, UICC 카드는 복수개의 SIM 모듈을 다운로드 받아서 설치하고 그 중 하나의 SIM 모듈만을 선택하여 사용할 수 있다. UICC 카드는 단말에 고정되거나 고정되지 않을 수 있다. 특히 단말에 고정하여 사용하는 UICC를 eUICC (embedded UICC)라고 한다.

이하에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 모두 eUICC로 설명하도록 하며, 원격으로 다운로드 받은 SIM 모듈을 eSIM이라고 표현할 수 있다. 또한, 다운로드 받는 SIM 모듈정보를 eUICC 프로파일 또는 eSIM Profile, Profile, 프로파일이라고 설명하도록 한다, 또한, 이하의 명세서에서 통신 서비스 사업자는 서비스 사업자, 통신 사업자, 이동 통신 사업자, 이통사와 동일한 의미로 사용될 수 있다. 설명의 편의를 위하여, eUICC의 경우 GSMA 규격에서 정의하고 있는 용어 및 명칭들을 사용한다. 하지만, 본 개시가 상기 용어 및 명칭들에 의해 한정되는 것은 아니며, 다른 규격을 따르는 시스템에도 동일하게 적용될 수 있다.

OCF(Open Connectivity Foundation)는 사물 인터넷(IoT) 단말 간의 상호운용성 제공 및 관련 기술의 표준화를 담당하는 단체로써, 사물 인터넷 단말의 제조사, 소프트웨어 등에 관계없이 상호 연결성을 위한 프로토콜, 운영 환경 등을 정의한다. OCF는 리소스 기반의 운영환경을 정의하며 각각의 실제 환경에서의 엔티티(Entity)들은 리소스들로 표현된다. OCF에서는 기기를 탐색하거나 또는 물리적 OCF의 리소스들을 탐색하여 특정 단말에서 지원하는 OCF 기능을 판단할 수 있다. (OCF 단말은 Client, 서버, Intermediary(중개자) 중 한 개 또는 한 개 이상의 역할을 수행할 수 있으며, 역할에 따라 OCF Client, OCF 서버, OCF Intermediary로 설명될 수 있다. OCF 클라이언트는 트랜잭션(Transaction)을 개시하며, 서비스를 얻기 위해 서버에 접속할 수 있다. OCF 서버는 Resources을 저장(host)하고 OCF 클라이언트가 응답 및 요청하는 서비스를 제공할 수 있다. OCF intermediary는 Client와 서버 사이에서 메시지를 전달하는 데 있어 프로토콜 변환 등 중간에 메시지 전달에 필요한 매개 작업이 필요한 경우 이를 제공할 수 있다. 서버에서 호스트(host)하고 있는 리소스들은 실제 세계에서의 하나의 엔티티(Entity)를 표현한다. 설명의 편의를 위하여 OCF 규격에서 정의하고 있는 용어 및 명칭들을 사용한다. 하지만, 본 개시가 상기 용어 및 명칭 등에 의해 한정되는 것은 아니며, 본 개시는 다른 규격을 따르는 시스템에도 동일하게 적용될 수 있다.

GSMA가 단일 단말 내부의 애플리케이션과 LPA 사이의 인터페이스(Interface)를 정의한다면, OCF는 IoT 단말의 OCF 애플리케이션과 주 단말의 OCF 애플리케이션 사이의 메시지 전송을 위한 인터페이스(Interface)를 정의한다. 이하의 명세서에서 주 단말, Primary Device, Mediator, OCF Client, Enroller, Mobile Device은 IoT 단말의 개통을 위해 UI 처리 및 IP Connectivity를 제공하는 단말로 해석될 수 있으며 스마트폰을 대표적인 단말로 생각할 수 있다. 또한, 보조단말, Secondary Device, OCF Server, Enrollee, (eSIM) IoT 단말, (eSIM) IoT Device은 해당 단말 단독으로 표준 기반의 프로파일의 다운로드를 수행하여 통신 개통을 하기 어려운 단말로 해석할 수 있다. 대표적인 단말로써 eSIM이 탑재된, 워치 또는 도그 칼라 (Dog collar), 펫 캠 등을 생각할 수 있다.

전술한 바와 같이, 본 개시가 이루고자 하는 기술적 과제는

OCF를 주 단말과 IoT단말간 Interface로 사용하여 eSIM IoT단말에서eSIM Profile Package를 다운로드 및 설치, 개통하여 통신서비스를 할 수 있도록 하는 방법 및 장치를 제공하는 것이다.

특히, 본 개시에서는 상기 목적을 위한 다음의 방법들을 포함한다

본 개시의 일 실시예에 따르면, 주 단말이 디바이스 디스커버리(Device Discovery) 과정을 수행하여 OCF를 지원하는 IoT단말을 발견하고, 해당 IoT 단말에 접속하여 IoT단말의 Capability 및 저장된 리소스들을 확보할 수 있다.

본 개시의 다른 실시예에 따르면, 주 단말이 IoT 단말을 통해 획득한 소정의 정보에서 eSIM IoT 단말임을 판별할 수 있는 정보를 검출하여, 통신 개통 가입 및 처리를 위한 UI를 생성 및 표기할 수 있다.

본 개시의 다른 실시예에 따르면, 주 단말에서 서비스사업자에게 액티베이션 코드(Activation Code) 생성 요청을 하는 데 필요한 소정의 정보를 eSIM IoT단말과의 메시지 교환을 통해 확보하여 서비스사업자에 전달하고 액티베이션 코드 (Activation Code)를 발급 받을 수 있다.

본 개시의 다른 실시예에 따르면, 주 단말은 단말이 지정한 조건을 참조하여 eSIM 셋업(Setup) 과정 중 사용할 AP 정보를 생성 또는 선택하여 eSIM IoT단말에 전달할 수 있다.

본 개시의 다른 실시예에 따르면, 주 단말은 AP(예. Wi-Fi 핫스팟 또는 Bluetooth 테더링)로 동작할 때, 접속을 시도하는 단말들 중에 eSIM Easysup을 수행의 과정 중의 일부로 접속하는 단말이 존재하는지 판별하고 이전 세션을 이어갈 수 있다

본 개시의 다른 실시예에 따르면, 기존 eSIM Easysup 절차를 연결하여 Profile을 다운로드 하는 과정에서 eSIM IoT단말에서 주 단말에서 처리해야 하는 동작, 예를 들어 사용자의 인터랙션(Interaction) 필요한 경우에 콜백(callback)하여 이를 주 단말에서 처리하게 할 수 있다.

본 개시의 다른 실시예에 따르면, eSIM IoT단말에 eSIM Easyetup이 완료되었음을 주 단말이 인지 시, 주 단말과 IoT단말간의 SoftAP 연결을 해제하고, 선택적으로 eSIM IoT단말이 주변 AP에 접속하도록 할 수 있다.

도 1은 OCF모듈과 GSMA 모듈 간의 관계를 설명하기 위한 도면이다.

OCF 프레임워크(Framework)는 트랜스포트(Transport)계층과 프로파일(Profile)계층 사이에 위치한다. 이에 따라, OFC 프레임워크는 통신 방식으로 Bluetooth, Wi-Fi등 어떠한 것을 사용해도 상호호환이 보장될 수 있다. OCF표준은 RESTful(Representational State Transfer) 소프트웨어(Software) 아키텍쳐 구조로 설계되어 있고, CRUDN (Create, Retrieve, Update, Delete, Notify) 의 기능을 정의하여 사용할 수 있다. OCF 서버(100)는 리소스들의 형태로 정의된 데이터 묶음들을 저장(hosting)할 수 있다. OCF Client(110)는 OCF 서버(100)가 저장하고 있는 리소스(Resource)에 대해서 CRUDN(Create, Retrieve, Update, Delete, Notify) 중 하나의 Request()를 요청(120)할 수 있다. 또한, OCF 서버(100)는 OCF Client(110)의 요청을 자체 또는 단말 내부 다른 모듈과의 통신을 통하여 수집하고, 해당 수집된 내용을 리소스들의 형태로(130) OCF Client(110)에게 회신(140)할 수 있다. 본 개시에서 eSIM IoT단말은 OCF 서버(100)로 동작하면서, LPA(170) 및 eUICC(180)을 탑재할 수 있다. 또한, eSIM IoT 단말은 스마트폰 등 OCF Client(110)로 동작하는 단말의 요청에 대한 처리(130)가 프로파일 다운로드 및 프로파일 다운로드 및 관리와 관련된 처리인 경우에 GSMA에서 정의한 eSIM 접근/제어 소프트웨어 모듈인 LPA(170)와 GSMA RSP(Remote SIM Provisioning) 프로토콜에 기반하여 메시지 교환을 수행(150, 160)하여 확인할 수 있다.

LPA(170)는 OCF 서버(100)와의 인터페이스를 통해서 메시지 교환을 수행할 수 있으나, OCF 서버(100)는 eUICC칩(180) 또는 SM-DP+(170) 서버에 직접 접근 및 통신은 할 수 없다.

도 2는 본 개시의 실시 예에 따른 OCF 표준을 사용하여 eSIM IoT단말의 통신 개통을 제공하는 전체적인 과정을 도시한 도면이다.

End User(200)는 eSIM IoT단말의 통신 서비스를 개통하고자 하는 사용자를 의미한다. OCF에서 Enrollee(203)는 구성(configuration) 및 네트워크 접속이 필요한 단말로, 일반적으로 구매 후 처음 개봉하여 서비스 프로비져닝(Provisioning) 및 설정이 필요한 단말이다. 본 개시에서 Enrollee(203)는 eSIM을 탑재한 IoT단말로 eSIM IoT단말 또는 IoT단말로 설명될 수 있다. OCF에서 Enroller(209)는 Enrollee(203)에게 네트워크를 제공해 주는 단말을 의미하며, OCF에서 Mediator(209)는 Enrollee(203)와 Enroller(209)의 중개자로써 네트워크 접속에 대한 정보를 Enroller(209)에서 Enrollee(203)로 전달해 주는 역할을 하는 엔티티(Entity)이다. eSIM IoT단말은 프로파일의 다운로드를 위해 LPA및 eUICC(205), 그리고 OCF 애플리케이션(207)을 포함할 수 있다. LPA는 Local Profile Agent로써, eUICC에 대한 접근 제어 및 권한 관리를 제어하는 소프트웨어 모듈이다. LPA는 eUICC와 통신하며 OCF애플리케이션(207)에서 요청하는 정보를 eUICC에 요청 또는 단말 내 특정 동작을 통해 수집하여 애플리케이션으로 회신할 수 있다. OCF Enrollee는 일반적으로 OCF Server 역할로 동작할 수 있다. Mediator 이며 Enroller로 동작하는 주 단말(209)은 사용자와의 인터랙션(Interaction)을 포함하는 OCF 애플리케이션(211)을 구현하며, OCF 애플리케이션(211)은 일반적으로 Client 역할로 동작할 수 있다.

주 단말(209)에서의 OCF App(211)이라고 함은, OCF 기능을 지원하는 애플리케이션을 의미한다. OCF 기능을 지원하는 애플리케이션은, 예를 들어 OCF Client 기능을 포함하는 통신사업자 또는 제 3의 서비스 사업자의 애플리케이션이 될 수 있다. 만약, OCF 기능을 지원하는 애플리케이션이 OCF Client 기능을 포함하는 서비스 사업자의 애플리케이션인 경우, 해당 애플리케이션에 IoT단말에서 가입 가능한 데이터 플랜 정보, 가입자 인증 정보 들은 해당 앱에 연동된 통신 사업자의 웹 포탈을 통해서 처리될 수 있다. Enrollee(203)에서의 OCF App이라고 함은, OCF Client에서 요청하는 명령에 대응하여 단말 내부 동작을 통해서 필요한 값을 수집(예. LPA와 연동을 통한 eUICC 정보 수집)하고 전달해 주는 서버(Server) 역할을 수행할 수 있다.

플랜을 단말에서 선택하여 통신 개통 서비스를 단말에서 직접 제공하고자 하는 동작에 있어서, 주 단말(209)은 Enrollee(203)에게 자신의 AP정보를 전달하는 역할을 할 뿐만 아니라 Enrollee(203)에게 통신망을 제공하는 단말로써 Enroller의 역할을 동시에 수행할 수 있다. 본 개시에서 주 단말을 Enroller로 표기하는 경우, 해당 단말은 Enroller의 역할만을 수행하는 것이 아니며 Mediator의 역할을 수행할 수도 있다. Service Provider Server(213)는 통신서비스 개통 서비스를 제공하는 사업자의 서버로써 통신 서비스 가입 및 인증, 결제 등 처리하고, Activation Code를 발급하는 서버(Server)를 통칭한다. 해당 서버는 하나로 구성될 수도 있고 여러 개의 다른 서버의 묶음으로 구성될 수도 있다.

이하에서, End User(200)가 esSIM IoT단말(203)을 구매하여 개봉하는 시나리오(Unboxing)의 경우를 예로 들어 전체 동작을 설명하고자 한다. esSIM IoT단말(203)을 개봉하여 전원을 켜면 해당 단말은 SoftAP를 생성하여 신호를 전송(215)할 수 있다, 또한, 단말은 BLE 또는 BT 기술을 활용하여 비콘(Beacon)을 생성하여 전송할 수 있다. 사용자는 주 단말(예. 스마트폰)(209)에서 IoT단말을 관리하는 애플리케이션(211)을 실행시키고 주변을 스캔하여 AP 정보를 수집하고 수집되어 단말에 표기되는 단말 식별 정보(예. SSID, 단말 이름) 및 Beacon을 통해 전달되는 정보를 통해 해당 단말이 OCF를 지원하는 단말임을 인지하고 Easyup 수행이 필요한 Unboxing 단말임을 인지(217)한다. Beacon을 통해 전달되는 정보에서 Easyseup 중에 어떤 Easysetup인지에 대한 식별자 정보를 추가하여 전달할 수도 있다. 주 단말은 해당 IoT단말을 인지하면, 사용자의 선택 또는 단말의 셋팅을 통해 해당 OCF 단말에 접속을 시도(219)할 수 있다. 해당 접속을 승인하기 위해서 OCF에서 정의한 다양한 보안 인증 방법 (예를 들어, IoT단말에서 Random PIN을 생성하여 해당 정보를 주 단말에 입력하여 승인 등) 등이 OCF에서 활용되고 있다.

주 단말(209)이 IoT단말(203)의 AP에 조인(219)하면, 주 단말은 해당 IoT단말이 제공하는 리소스들에 대한 리스트를 수집(221)할 수 있다. 주 단말(209)은 해당 리스트에서 (Wi-Fi) Easysetup 및 eSIM Easyseup를 지원하는지 검출할 수 있다. 또한, OCF의 device type 확인을 통해 eSIM 단말인지 여부를 확인할 수도 있다. 만약, 주 단말(209)이 IoT단말(203)의 리소스List로 eSIM Easyseup가 있다고 판단하고, 주 단말이 eSIM IoT단말로부터 획득한 특정 식별 정보(예. 비콘 에 포함된 Easysetup 식별자 등)로 최초 셋업이 필요한 단말인지 확인하게 되면, "통신서비스 플랜 구매" 버튼을 화면의 UI에 추가로 구성하여 표기(227)할 수 있다. 이 때, 사용자가 "통신서비스 플랜 구매" 버튼을 선택하지 않은 경우에는, 이후 주 단말에서 해당 단말과의 연결 시 리소스들을 확인하는 과정에서 WiFi Easysetup Resouce가 리스트로 표기되더라도 버튼을 생성하지 않고 별도 메뉴를 통해서 선택할 수 있게 처리할 수 있다. 또한, 사용자가 이후에 플랜 구매 시, 메뉴 접근 가이드가 UI로 제공될 수 있다. 사용자가 플랜메뉴 구매를 선택(227)하면, 주 단말은 eSIM Setup시작(231)을 인지하고, 주 단말에서 필요한 이후 동작을 설정할 수 있다. eSIM Setup 시작(231)을 인지하는 분기는 Activation Code가 주 단말에서 확보되는 시점(255)으로 처리될 수도 있다. 주 단말이 eSIM Setup임을 인지하는 경우에, 주 단말은 eSIM Setup 절차가 완료되기 전까지 Wi-Fi Easysetup 시 전달할 AP 정보를 주 단말 자신의 것으로 설정 변경하며, Connect(253)을 수행할 때 사용할 추가 정보들을 SoftAP 연결 해지(245) 이전에 확보해야 함을 인지하여 추가 동작을 수행할 수 있다.

주 단말(209)은 사업자 웹 포탈을 연결하여 가입 가능한 요금제 제공 및 (요금제) 플랜 구매에 대한 절차를 수행(233)할 수 있다. 이에 대한 상세 내용은 도 3에서 후술하도록 한다. 이 후, 애플리케이션에서 사용자의 통신 서비스 구매에 대한 절차가 모두 완료되면 서비스 사업자는 해당 애플리케이션에 Activation Code를 전달(235)할 수 있다. Activation Code는 GSMA를 정의하고 있으며, SIM 서버 주소 및 해당 Subscription에 매칭되는 ID로서 토큰 값을 포함하고 있다.

주 단말(209)은 eSIM IoT단말(203)이 프로파일(Profile)을 다운로드 받기 위한 초기 연결(Connectivity) 제공을 위해 자신의 AP 정보로 기존의 eSIM IoT 단말의 WiFi Conf 값을 업데이트 요청(237)할 수 있다. eSIM IoT단말(203)의 OCF App(207)에서는 해당 요청에 대해 처리 결과를 회신(239)할 수 있다. 주 단말(203)에서는 Connect(253) 명령을 통해서 해당 정보로 접속을 명령할 수 있다. 해당 Connect 명령에 대해 eSIM IoT 단말이 명령을 수신했다는 정보를 보내면(243) 주 단말(203)과 IoT단말은 SoftAP 접속을 해제 (245, 247)할 수 있다.

주 단말(209)은 IP Connectivity를 제공하기 위한 SoftAP를 생성(249)하여 신호를 전송할 수 있다. 본 개시에서는 IP Connectivity를 제공하는 방법으로 Wi-Fi를 중심으로 기술하고 있으나, Easysetup 정보로 Bluetooth 테더링 정보가 전달되었고 주 단말에서 Bluetooth 기반 IP Connectivity지원을 위한 Bluetooth의 서비스 프로파일을 지원할 경우 Bluetooth기반 IP테터링도 사용될 수 있다.

IoT단말에서는 전달된 Wi-Fi Configuration 정보 (예. SSID/PW)를 사용하여 주변 AP정보를 검색하여, 매칭(251)되는 AP에 접속을 시도(253)할 수 있다. 주 단말에서는 접속을 시도하는 단말이 이전에 eSIM Easyseup을 진행 중이었던 단말의 OCF 연결인지를 판별하기 위해서 이전 연결에서 사용한 소정의 정보 또는 이전 연결을 해제하기 전에 징표로 전달한 정보를 추가 활용하여 접속 여부를 판별하여 접속을 허용하고 세션을 연결할 수 있다. 다시 접속을 허용하는 방법에 있어서는 도 8 내지 도 11를 통해 상세하게 후술하도록 한다. IoT단말이 주 단말에 접속하여 이전 세션을 연결하여 진행하면,

IoT단말은 제공하는 IP Connectivity를 통해 GSMA SGP.22를 준용하는 Profile D/L 절차를 수행(255)할 수 있다. 해당 과정에 대해서는 도 4에서 상세하게 후술하도혹 한다.

프로파일(Profile) 다운로드가 완료 또는 완료 후 Profile 이 실행(enabled) 되었다는 정보를 주 단말(209)이 eSIM IoT단말(203)로부터 수신하면, 주 단말은 eSIM Easysetup 절차가 완료되었음을 인지(257)하고 IP 테더링/핫스팟을 종료(261)할 수 있다. 이후 WiFi Easyseup에 대한 처리가 필요할 경우에 일반적인 동작 - 즉, 주변의 무선 공유기의 AP 정보를 탐색하여 해당 AP 정보를 IoT단말에 전달하고 IoT단말이 해당 AP정보를 가지고 대상 무선 공유기의 AP로 접속하도록 처리-이 수행될 수 있다. 한편, 주 단말의 Wi-Fi AP 정보는 IoT 단말에서는 계속 가지고 있을 필요가 없으므로 폐기될 수 있다. 예를 들어, WiFi Conf Resouce에 추가적으로 eSIM Provisioning을 위한 것임을 표기하는 indication이 있는 경우, 프로파일 다운로드 작업이 모두 수행 완료되면, 해당 Wi-Fi Conf 정보는 삭제처리될 수 있다.

본 도면에서 밑줄로 표기한 부분은 현재 OCF WiFi Easyseup 표준 규격 대비 변경/추가되는 End to End동작 및 Entity 들이며, 굵은 글씨로 표기된 eSIM Easysetup 은 본 개시의 시점에서 표준화되지 않은 추가 데이터 모델(264)이다. eSIM Easyseup은 eSIM에 프로파일을 다운로드를 위해 신규로 정의한 리소스들의 묶음이며 IoT단말의 리소스 검색에서 해당 리소스가 발견되면, eSIM을 탑재한 단말이라는 것을 알 수 있다. 또한. 해당 리소스에 정의된 Proporty(데이터 값)의 변경을 통해서 단말이 OCF에서 정의된 eSIM에 프로파일을 다운로드 처리에 대한 작업을 시작 또는 종료에 대한 식별이 가능하다.

예를 들어 eSIM Easysetup Resouce에는(223) 아래와 같은 정보들이 포함될 수 있다. 아래에서 RSP는 Remote SIM Provisioning, Conf는 Configuration을, ES9+, ES10, ESeu는 각 LPA -- SM-DP+, LPA-eUICC, LPA-End User간 Interface를 의미한다.

eUICC 정보와 Device Information for RSP로 전달되는 정보들은 GSMA에서 기 정의된 정보들이다. Device Information for RSP의 정보로는 단말에서 지원하는 무선 접속 기술 및 Release 정보, 단말 제조번호인 IMEI, TAC(Type Allocation Code) 등이 포함될 수 있다. eUICC Information은 eUICC 가용 메모리, 버전 정보, RSP(Remote SIM Provisioning) Capability, Profile Policy Rules과 같은 정보가 포함될 수 있다. Confirmation Code는 일부 통신사업자에 의해 요구되는 eSIM eanbleing을 위해 필요한 비밀번호를 의미한다. 각 리소스들은 OCF표준 Resource포멧에 따라 정의된, 아래 데이터 모델 형태로 표현될 수 있으며 Property로써 다음을 가질 수 있으며, 이에 한정하지 아니한다.

도 3은 전술한 도 2의 데이터 플랜 정보 제공/플랜 구매에 대한 동작을 상세하게 도시한 도면이다.

사용자(200)가 플랜 구매를 요청하여 eSIM Setup 시작이 인지(231)되면, 주 단말(209)의 OCF 앱(211)에서는 해당 IoT단말의 정보 및 eUICC의 정보를 eSIM IoT 단말(203)의 OCF앱(207)에 요청(300)할 수 있다. 해당 요청을 받은 eSIM IoT 단말의 OCF 앱에서는 LPA로 GSMA에서 정의한 InitiateLPAApi () 를 호출(305)하고 LPA는 eUICC와의 통신을 통해 OCF앱에 LpaApiInfo() 로써 Device 및 eUICC 정보를 수집하여 전달(310)할 수 있다. OCF 앱(207)은 해당 데이터를 OCF 프로토콜을 통해서 주 단말(209)의 OCF앱(211)으로 전달(315)할 수 있다. 전달된 Device/eUICC 정보는 다시 서비스 사업자 서버로 전달(320)되고, 해당 서비스 사업자는 전달 받은 해당 정보에 기반하여 해당eSIM IoT단말에서 사용 가능한 통신 서비스가 있는지 판단하고 플랜 정보를 선별하여 주 단말의 OCF 앱에 회신(325)할 수 있다. 회신된 정보는 사용자의 UI로 표기(330)될 수 있다. 사용자(200)가 이 중에 사용하고자 하는 플랜을 메뉴 클릭 등을 통해 선택(335)하면, 통신사업자의 웹 포탈을 연결하여 이후 구독(Subscription)을 위한 일련의 절차를 수행하여 가입을 완료(340)할 수 있다. 예를 들어, ID/PW 또는 주 단말의 SIM 정보를 활용한 가입자 신원 인증, 서비스 구매에 대한 계약 및 결제 처리 등이 수행될 수 있다. 모든 절차가 완료되면 서비스 사업자 서버에서는 Activation Code(255)를 발급할 수 있다.

도 4는 전술한 도 2의 GSMA SGP.22를 준용하는 Profile D/L 수행에 대한 동작을 상세하게 도시한 도면이다.

IoT단말은 주 단말의 AP에 이전 연결에서 전달받은 SSID/PW 정보를 가지고 접속 및 추가적인 OCF 단말 인증 과정을 통해 이전 OCF기반 eSIM Easyseup에 대한 세션을 재개(253)할 수 있다. 재 연결이 되면, 주 단말에서는 eSIM IoT 단말에 Get (RSPStatusconf)를 요청(400)하며, 이 때, RSP Status의 initial status와 Observe 기능에 대한 식별자가 추가되어 전송될 수 있다. 이에 대해, eSIM IoT 단말(203)의 OCF 앱(207)에서 Observer기능 수행에 대한 응답 메시지를 보냄(405)으로써, 이후 RSPStatusConf의 세부 값이 변경되는 경우에 주 단말로 콜백(Callback)하겠다는 것을 알려줄 수 있다. 이제 OCF앱에 Activation Code를 OCF 프로토콜을 사용하여 eSIM IoT 단말의 OCF앱에 전달(410)해 주고, OCF앱(207)은 LPA(205)에 GSMA에서 정의한 ExecuteCommandCode (Activation Code) 명령을 전달(415)하여, ExecuteCommandCode (Activation Code)을 받은 LPA(205)에서 eUICC 및 SM-DP+와 통신을 통해서 GSMA SGP.22에 정의된 Profile 다운로드 절차를 시작을 수행하게 할 수 있다. ExecuteCommandCode (Activation Code)을 받은 LPA(205)는 Activation Code 를 받았다는 알림을 OCF앱(207)으로 전달할 수 있다.

LPA(205)에서는 프로파일 다운로드를 진행하는 과정에서 표준으로 요구되는 사용자의 Interaction 필요시점을 각 Status분기로 OCF앱(207)에 회신할 수 있다. 해당 회신을 받으면 OCF앱(207)은 RSPStatus Resource의 Property값을 업데이트하며, 해당 값이 업데이트되면, OCF앱(207)은 이를 주 단말의 OCF앱(211)에 회신할 수 있다.

주 단말의 OCF앱(211)은 각 Status 변화 값에 따라, 주 단말(209)에서 처리가 필요한 지정 동작을 수행하고 수행에 대한 결과값을 다시 IoT단말(203)의 OCF앱(207)에 전달하여 처리할 수 있다. 예를 들어, LPA(205)가 Activation Code를 Profile Server인 SM-DP+에 전달하면 SM-DP+에서는 Profile metadata를 LPA(205)에 전달해 주고, 표준에 의거하여 Profile metadata에 대한 사용자(200)의 확인을 요구할 수 있다. 따라서, LPA(205)에서 SM-DP+로부터 Profile metadata를 받으면, eSIM IoT 단말(203)내에서는 LPA(205)가 OCF앱(207)에 Profile metadata를 받았으며 사용자의 확인이 필요한 상태 임을 전달하고 이를 수신한 OCF앱(207)은 RSP Status 상태를 변경하여 주 단말의 OCF앱(211)에 회신할 수 있다. 주 단말의 OCF앱(211)에서는 RSP Status 변화 값을 감지하고, 변화된 Status에 대응하여 단말에 사전 지정된 절차를 수행할 수 있다. 사전 지정된 절차 (445)의 한 예로, 주 단말(209)이 Profile metadata에 대한 사용자(200)의 확인을 처리하기 위해서,

주 단말(209)는 다시 profile metadata의 값을 eSIM IoT단말(203)로 요청하여 수집한 후에 사용자(200)에 이를 재 구성하여 선택 Profile의 다운로드 동의를 재 확인 처리하고, 처리 결과를 다시 eSIM IoT단말(203)에 전달해 줌으로써 LPA(205)가 다음 단계의 Profile 다운로드를 절차를 진행하여 모든 절차를 완료할 수 있다.

도 5는 주 단말이 단말이 지정한 조건을 참조하여 eSIM Easyseup을 위한 절차로 진행 여부를 판단하고 이후 작업을 수행하는 방법을 도시한 도면이다.

앞서 도 2에서 언급한 바와 같이 주 단말과 IoT단말이 OCF 기반으로 단말 Discovery 및 해당 단말의 Resources 들을 검색하는 과정을 수행하는 과정에서 주 단말은 해당 IoT단말이 eSIM을 탑재한 단말이며, eSIM Easyseup이 지원 가능한 단말인지 확인(405)할 수 있다.

“플랜 메뉴 구매”등 특정 사용자의 Input값이 입력되거나 또는 OCF에서 정의한 eSIM Setup에 관한 Resource의 Property값 변경, 또는 주 단말의 설정 등을 통해 주 단말은 eSIM IoT단말의 eSIM EasySetup 절차의 시작을 인지(410)할 수 있다. OCF단말에 있어서 (WiFi) Easyseup의 일반 절차는 주 단말이 무선랜 공유기의 AP정보를 IoT 단말에 전달하는 것이나, eSIM EasySetup 시작을 인지하면 주 단말은 해당 절차가 종료되었음을 감지할 때까지, WiFi Configuration 정보를 eSIM IoT단말에 전달이 필요할 경우, 자신의 Access Point 정보를 전달하는 것으로 설정을 변경 적용할 수 있다.

주 단말에서 eSIM Easysetup 절차의 수행 시작이 인지(410)되면, 주 단말은 사업자 웹 포탈 등을 연결하여 플랜 구매 절차를 위한 요금제 가입, 가입자 인증, 결제를 진행하고 (415) 해당 과정이 완료되면, 사업자 서버로부터Activation Code정보를 발급(420)받을 수 있다. Activation Code는 SM-DP+주소와 해당 가입 정보와 연계된 Token값을 포함하는 것으로, 주 단말은 Activation Code의 보안을 위해서 Activation Code가 단말에서 웹 사이트 또는 포탈을 통해서 가입한 결과물로 주 단말에 내려주는 경우에 선택적으로 사용자 단말에 UI로 띄워주지 않게 처리할 수 있다.

주 단말이 서비스 사업자의 웹 포탈 또는 애플리케이션을 통해 Activation Code를 발급받아 확보하면, 주 단말은 먼저 해당 eSIM IoT단말에 저장된 WiFi Conf 정보가 있는지를 eSIM IoT단말에 요청하여 단말에 저장(430)해 놓을 수 있다. 그리고 나서, 주 단말은 기존의 WiFi Conf 동작을 수행하여 자신의 Access Point 정보(예. SSID, Password, 인증 정보 등)를 eSIM IoT단말에 전달(435)하고 해당 AP가 활성화되어 감지되면, 감지된 AP에 접속하도록 명령할 수 있다. 이 때, 주 단말은 eSIM IoT단말이 해당 AP가 eSIM Provisioning을 위한 1회성 WiFi Configuration라는 것을 인지할 수 있도록 Wi-Fi Configuration에Indicator로 Property를 추가할 수 있다. eSIM IoT단말은 SoftAP 모드를 실행하여 IP 핫스팟/테더링을 수행(440)한다

eSIM IoT단말이 Access Point에 대한 정보를 수신하면, 일정 시간 동안 주기적으로 해당 AP를 탐색하여 주 단말로의 접속을 시도할 수 있다. 다른 방법으로는 주 단말에서 IP테더링을 수행 사용자에 UI를 통해 요청하여, 사용자가 IP 테더링 수행을 위한 SoftAP를 동작시키고 나서 IoT단말에서 AP 스캔을 trigger하는 특정 동작 (예. 버튼 클릭 등) 을 후속으로 요청할 수도 있다.

주 단말은 일정 시간 동안 전달된 SSID/PW로 하여 해당 SoftAP로 접속하는 단말이 없는 경우에 주 단말의 UI에 에러 메시지를 띄우거나 또는 기존의 WiFi Conf 동작을 수행하여 자신의 Access Point 정보(예. SSID, Password, 인증 정보 등)를 eSIM IoT단말에 전달을 일정 횟수 추가 수행하여 재 연결을 시도할 수 있다. 또한, eSIM IoT단말의 경우, 전달받은 AP로 일정 시간 동안 스캔되는 AP가 없는 경우(예. AP정보를 전달하고 주 단말의 배터리 방전 등) 사용자가 인지할 수 있게 Notification(예. 불빛 깜빡임 등)을 통해 추가 사용자의 action을 유도할 수 있다. 다음에 주 단말의 OCF애플리케이션이 다시 동작하는 경우에, 해당 OCF 애플리케이션은 미 전송된 Activation Code가 있다는 것을 감지하고, 사용자와의 Interaction을 통해서 미 전송된 Activation Code에 대한 처리 여부를 판단할 수 있다.

주 단말이 SoftAP모드로 전환하고, IoT단말이 IP Tethering을 위해 접속하여 양 단말간 기존 eSIM Setsup을 위한 OCF 연결이 재개되면 주 단말은 Profile 다운로드를 위한 소정의 정보로써 Activation Code를 eSIM IoT단말에 전달함으로써, eSIM IoT단말에서 남은 eSIM Easysetup 절차를 주 단말과 연동하여 완료하도록 처리(445)할 수 있다. 단말간 연결 재개 후의 남은 eSIM Easysetup에 대한 상세 절차는 도2및 도 4에서 이미 설명하였으므로 생략한다.

eSIM Easyseup 이 완료 되었음을 인지할 수 있는 식별정보로서 RSP(Remote SIM Provisioning) 절차에 대한 정보를 주 단말이eSIM IoT단말로부터 수신(Notify 또는 Response로 회신)하면(450) 주 단말은 SoftAP를 해제하고 종료할 지 여부를 사용자 동의 또는 단말의 설정 값을 통해서 판단(455)할 수 있다. 주 단말은 eSIM IoT 단말의 전력 소비 감소 또는 데이터 사용량 절감을 위해 절차(430)에서 저장한 WiFiConf 정보로 복구(465)하여 기존 무선랜 공유기에 기본 연결되어 있게 처리 하거나 또는 WiFi Easysetup 동작을 실행하여 주변 무선 공유기의 Access Point를 감지하여 해당 정보를 eSIM IoT단말에 전달(470)해 주고, 사용자의 선택 또는 단말의 기본 설정에 따라 무선랜 AP에 접속 또는 이동통신망으로 접속을 처리할 수 있다. 만약, 주 단말이 RSP 절차 종료에 대한 메시지를 일정 시간 동안 받지 못하는 경우에 주 단말은 사용자에게 에러메시지를 띄우고, WiFi Conf처리에 대한 기본 셋팅 값으로 복구할 수 있다.

도 6에서 도10은 eSIM IoT단말과 주 단말이 eSIM Setup을 수행하는 과정에서

단말간 AP의 역할을 변경하여 재 연결하는 경우에 기존에 연결했던 OCF 서버와 연결을 재개하는 방법들을 도시한 도면이다. 도6 내지 도 10에서 언급한 방법들은 Mutually Exclusive하게 사용해야 하는 것으로 한정하지 않으며, 결합하여 사용할 수 있다.

도 6은 임시 사용할 SSID와 Password를 사용하여 기존 OCF연결을 재개하는 방법을 도시한 도면이다.

앞서 언급한대로 주 단말(610)에서 eSIM IoT단말(600)의 통신 개통을 위한 Activation Code의 확보(630)등을 통해 주 단말(610)은 eSIM Easyseup 시작을 감지하고 해당 절차를 수행하기 위한 추가 설정을 처리할 수 있다.

주 단말의 OCF애플리케이션에서는 사용자 입력 또는 난수 생성기 등을 활용하여 임시로 1회성 SSID와 Password를 생성(635)하여 전달하거나, 또는 기존 SSID/PW Set 의 하나를 골라서 eSIM IoT 단말에게 전달(640)한다. eSIM IoT단말이 SoftAP를 해제하여 상호 단말간 연결이 해제 되면(650), 주 단말(610)에서 Soft AP를 실행(650)할 수 있다. 주 단말(610)에서는 임시로 생성한 SSID 및 PW로 기존 SSID와 PW 정보를 교체하여 일정 시간 동안 임시로 생성된 SSID 및 PW로만 입력을 허용하거나 또는 여러 개의 AP를 가진 것처럼 동작(virtual AP기능)하도록 SSID/PW를 추가로 설정하여 접속 단말을 구분할 수 있다.

만약 임시 생성 및 전송한 SSID/PW를 사용했을 경우에 OCF 애플리케이션에서는 별도 추가 검증 절차 없이 해당 접속된 단말이 기존 eSIM Easyseup을 진행 중이었던 단말로 인지하여 이전 애플리케이션 세션을 연결하여 진행(660)할 수 있다. 만약 여러 리스트 중에 하나를 골라서 전달한 경우에, OCF 애플리케이션은 시스템 API 등을 통해서 접속한 SSID/PW 정보를 추가 판별하여 애플리케이션 세션 재개에 활용할 수 있다(660). 만약 SSID 및 PW등 Configuration 정보가 일치하는 경우(670)에, OCF 애플리케이션은 기존의 eSIM Easyseup을 수행 중이었던 OCF 단말로 인지하고 기존 세션을 연결하여 이후 작업을 수행(680)한다.

1회성 SSID와 Password를 생성하여 기존 SSID/PW를 일정 시간 교체하여 사용하는 경우에는, 주 단말에서 SSID/PW가 일치 에 대한 검증이 끝나거나 또는 기타 단말의 설정, 예를 들어 타이머를 통해 교체 후 일정 시간 후 원래 SSID/PW로 복구할 수 있다. 또한, 기존 SSID/PW에 추가적인 SSID와 Password Set을 제공하는 경우에는, 주 단말의 설정에 따라 해당 정보의 삭제 처리 여부를 결정할 수 있다.

도 7은 기존 단말간 연결 시 확보한 Device 식별 ID를 활용하여 기존 연결했던 OCF연결을 재개하는 방법을 도시한 도면이다.

앞서 언급한대로 주 단말(710)에서 eSIM IoT단말(700)의 통신 개통을 위한 Activation Code의 확보(730)등을 통해 주 단말(710)은 eSIM Easyseup 시작을 감지하고 해당 절차를 수행하기 위한 추가 설정을 처리할 수 있다.

주 단말(710)은 eSIM Easyseup을 시작을 감지하면, eSIM IoT단말(700)에 자신의 SSID/PW 등 접속 정보를 전달(740)할 수 있다. 그리고, eSIM IoT 단말(700)과 주단말(710)이 SoftAP를 해제하기에 앞서 주 단말은 eSIM IoT 단말의 ID 정보를 수집하여 저장(745)할 수 있다. Device ID는 기존 OCF Device를 인지할 수 있는 고유 또는 임시의 식별 정보로써 MAC 주소 또는 Device UUID를 포함할 수 있다. 예를 들어, OCF Device는 고유 단말 식별 번호를 가지며, 해당 ID는 단말의 보안 영역 또는 인증서에 저장되어 있다. OCF Client로 동작하는 주 단말은 서버 역할을 하는 IoT단말에 RETRIVE /oic/d를 요청함으로써 Device UUID 정보를 수집할 수 있다. 한편, 주 단말은 이전의 연결을 해제하기 전, 시스템 API등을 통해 연결 중인 eSIM IoT 단말의 MAC 주소를 수집, 캐쉬해 놓았다가 활용할 수도 있다. 연결이 해제된 이후에 주 단말이 AP로 동작(760)하고, 해당 AP의 SSID/PW로 접속을 시도(765)하여 SSID/PW가 일치하고 DTLS 세션이 생성된 단말(770)에 대해서, OCF애플리케이션은 Device ID를 부가정보로 요청하고, 해당 요청에 대해서 접속을 시도하는 단말이 Device ID를 회신(785)할 수 있다. 주 단말(710)은 Device ID값이 연결을 해제하기 전에 저장해 놓은 이전 Device의 ID값과 매칭되는지 여부를 판단(790)할 수 있다. 매칭되는 경우에 OCF 애플리케이션은 기존의 eSIM Easyseup을 수행 중이었던 OCF 단말로 인지하고 기존 세션을 연결하여 이후 작업을 수행(795)할 수 있다.

도 8은 기존 단말간 OCF 세션 생성을 위해 수행했던 DTLS Handshaking 의 정보를 활용하여 기존 연결했던 OCF연결을 재개하는 방법을 도시한 도면이다.

eSIM IoT단말(800)과 주 단말(810)은 OCF Device Discovery, Onboarding 후에 통신서비스를 가입하기 위한 요금제 가입을 완료(820)할 수 있다. Onboarding은 OCF에서는 서로 다른 암호화 기능을 사용하는 다양한 단말들 간 통신 및 제어를 위한 IoT단말의 초기 설정 방법을 나타내며 IoT단말과 주 단말은 DTLS Session을 생성하기 위한 일련의 절차(Handshake 과정)를 포함(820)하고 있다.

DTLS는 Transport layer의 TCP 프로토콜에 보안을 제공해 주는 TLS (Transport Layer Security) 프로토콜을 UDP에 적용한 보안 프로토콜이다. OCF는 기본적으로 HTTP를 IoT단말을 위해 경량화된 CoAP (Constrained Application Protocol, RFC 7252) 프로토콜을 사용하며, OCF에서의 CoAP 프로토콜은 UDP/DTLS 위에서 동작한다. DTLS 세션을 생성하기 위한 과정(Handshake)에서 Server는 Client에게 해당 세션 및 세션 재개(Resumption) 대한 소정의 정보를 전달(820)해 줄 수 있다. 예를 들어, 서버는 클라이언트에게 Session ID, Cookie값 또는 Session ID, Session Resumption을 위해 도입된 Ticket을 전달해 줄 수 있다. 양 단말간 초기DTLS 생성을 위해 Full Handshake를 끝내고 DTLS 세션이 생성되면, 이후에 eSIM IoT단말(800)과 주 단말(810)은 암호화된 세션으로 통신을 시작할 수 있다. DTL에서의 Session ID 및 Cookie값 생성 및 사용은 IETF의 RFC 6347 규격, Ticket 사용에 대한 설명은 IETF의 RFC7925규격을 참조하고 부가 설명은 생략한다.

주 단말(810)의 애플리케이션에서 사용자가 통신 플랜 구매를 완료하고 Activation Code를 확보(825)하면, 주 단말은 자신의 SSID/PW 정보를 eSIM IoT단말에 전달(830)할 수 있다. eSIM IoT 단말(800)은 자신의 SoftAP를 해제(835)하고 주 단말(810)에서 SoftAP를 시작(845)하면 전달 받은 접속 정보를 가지고 해당 Soft AP에 접속을 시도(850)할 수 있다.

SSID/PW가 매칭되면, OCF Client로써 주 단말은 이전 연결에 사용되었던 세션 연결정보로써, Session ID, Cookie, Ticket 중 적어도 하나를 포함하여

eSIM IoT단말(OCF Server)에 전달함으로써 이전 세션을 Resumption하거나 또는 세션initiation을 요청할 수 있다. 서버로서, IoT단말은 전달받은 정보의 일치 여부를 판단(860)하여 기존 OCF Easystup을 위해 사용했던 DTLS 세션 Resumption 또는 해당 연결을 이어서 진행하기 위한 세션 Initiation 을 수행(865)한다. 매칭되는 경우에 OCF 애플리케이션은 기존의 eSIM Easyseup을 수행 중이었던 OCF 단말로 인지하고 기존 세션을 연결하여 이후 작업을 수행(870)할 수 있다.

도 9는 신규로 Application Layer에서의 Transaction ID를 생성/저장해 두었다가 이를 가지고 기존 연결했던 OCF연결을 재개하는 방법을 도시한 도면이다.

주 단말(910)과 eSIM IoT단말(900)의 연동을 통해 eSIM IoT 단말의 OCF Device Discovery를 수행하고 Onboarding, 플랜 구매를 모두 완료(920)할 수 있다. 주 단말의 애플리케이션은 eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 구분자로 트랜잭션(Transaction) ID를 임의 생성(925)하여 저장하고 해당 ID를 eSIM IoT 단말에도 전달(930)할 수 있다. 트랜잭션(Transaction ID)는 SoftAP연결을 해제하기 전 임의 시점에 주 단말이 생성(925)하여 eSIM IoT단말(900)에 전달(930) 및 저장할 수 있다. 해당 Transaction ID를 받은 eSIM IoT단말은 해당 정보를 저장해 두고, 양 단말간의 연결이 끊어졌을 때 해당 Transaction ID를 추가 제시함으로써 이전 애플리케이션에서의 세션을 재개할 수 있다. Transaction ID는 주 단말과 IoT단말간에 연결을 통해서만 주 단말이 획득 가능한 정보를 Input으로 하여 단말의 보안 키를 활용해 생성할 수도 있으며, 그 방법을 제한하지 않는다. 다만, 다른 단말이 동일Transaction ID값을 사용할 수 없다. 예를 들어, 2개의eSIM IoT단말들이 eSIM 프로파일 개통을 위한Transaction을 수행하고 있다고 할 경우, 해당 ID는 서로 다르게 지정되어야 한다.

주 단말에서는 Activation Code를 확보(935)하면 자신의 AP 접속 정보를 eSIM IoT단말에 전달(940)할 수 있다. 해당 정보를 받은 eSIM IoT단말(900)은 자신의 SoftAP를 해제(945)하고 양 단말간의 연결은 해제(950)될 수 있다. 그리고, 주 단말이 SoftAP를 시작(960)하면, 기존에 전달받은 SSID/PW 등의 접속 정보(965)를 가지고 IoT단말이 주 단말의 AP에 접속 및 이후 양 단말간 DTLS세션을 생성(970)한다. 이후, 주 단말의 애플리케이션에서는 eSIM 프로파일 다운로드를 하는 과정이라는 것을 판별하여 이전 대화를 속개하기 위해서, Traction ID를 요청(975)하고, IoT단말은 기존에 주 단말로부터 전달 받은 Traction ID를 제시(980)할 수 있다. 주 단말은(910) 전달받은 transaction ID와 이전 연결에서 생성/저장한 transaction ID의 일치 여부를 판단(985)하고, 일치하는 경우에 기존 프로파일 다운로드를 위한 절차를 속개하여 처리(990)한다. 선택적으로, IoT단말에 프로파일 다운로드 절차가 완료되었음을 나타내는 식별 정보를 받으면, 주 단말과 IoT단말은 Transaction ID를 파기 처리할 수 있다.

도 10은 IoT단말과 주 단말의 재 연결 시 이전 EPS 정보를 가지고 기존 OCF 연결을 재개하는 방법을 도시한 도면이다.

OCF 애플리케이션은 주어진 Transport 프로토콜 Suite에서 요청과 응답 메시지가 전달되는 최종 목적지로 (OCF) Endpoint를 정의하고 있으며, 보통 EPS로 표기할 수 있다.

EPS 정보는 IP주소+Port Number 또는 DNS name 등으로 표현되며, OCF단말을 탐색하는 용도로 사용될 수 있다. EPS에 대한 상세 설명 및 정의되는 파라미터는 OCF Core Specification의 Endpoint Discovery를 참조한다.

eSIM IoT 단말(1000)이 SoftAP로 동작하여 Device Discovery 절차를 수행 시, 해당 eSIM IoT단말은 AP로써 접속을 시도한 주 단말(1010)에 로컬 IP주소를 할당하게 된다. eSIM IoT 단말(1000)과 주 단말(1010)간 SoftAP 해제 전 임의의 시점에 eSIM IoT단말(1000)과 주 단말(1010)은 양 단의 EPS 를 확인하여 임시 저장(1025)해 둔다. 해당 정보는 RETRIVE /oic/res 명령을 통해서 확인 가능하며 또한 OCF 의 메시지 전송 시 일부로 포함되어 전송 및 응답 회신 될 수 있다. Activation Code 확보(1035) 등 일련의 절차가 끝나고 나서 주 단말은 자신의 SSID/PW를 IoT단말에 전달(1040)할 수 있다. 해당 전달을 받으면 IoT단말은 자신의 SoftAP를 해제(1045)하고 주 단말의 AP로 연결을 시도(1060)할 수 있다.

주 단말이 AP로 동작하게 되면 양 단말의 Port Number는 같을 수 있으나 AP로 동작하는 주 단말(1010)에서 로컬 IP주소를 eSIM IoT단말(1000)에 신규 할당하므로 IP주소 정보가 달라질 수 있다. 연결이 종료되고 다시 재 연결이 되는 경우에, 주 단말은 이전 EPS 정보를 접속을 시도한 OCF단말에 요청(1075)할 수 있다. 요청을 받은 해당 IoT단말은 연결을 해제하기 전에 저장해 둔 EPS 정보를 검색하여 회신(1080)할 수 있다. 주 단말에서는 이 둘의 EPS 정보를 매칭(1085)하여, 동일한 경우 기존의 eSIM 프로파일 다운로드를 위한 세션을 연결해서 진행(1090)할 수 있다. 만약에, 이전 EPS 정보를 요청하였으나 IoT단말에서 해당 정보가 없다고 응답하거나 이전 EPS 정보값이 다를 경우, 주 단말은 해당 단말이 OCF 단말이나 이전에 eSIM Easysetup을 위해 재 연결 설정한 그 단말이 아닌 것으로 판단하고, 일반적인 OCF단말 연결을 위해 정의한 절차를 처리하거나 종료할 수 있다.

.도 11은 본 개시의 일부 실시예에 따른 무선 통신 시스템에서 단말의 세부 구성을 도시한다.

도 11을 참고하면, 단말(1100)은 송수신부(1110) 메시지 처리부 (1120), 프로세서(제어부)(1130), 메모리(1140), 화면 표시부(1160)를 포함할 수 있다. 다만, 단말(1100)의 구성 요소가 전술한 예에 한정되는 것은 아니다. 예를 들어, 단말(1100)은 전술한 구성 요소보다 더 많은 구성 요소를 포함하거나 더 적은 구성 요소를 포함할 수 있다. 뿐만 아니라, 단말(1100)의 적어도 하나의 구성이 하나의 칩 형태로 구현될 수 있다. 일부 실시예에 따르면, 송수신부(transceiver)(1110)에는 신호의 대역 변환, 증폭 등 무선 채널을 통해 신호를 송수신하기 위한 기능을 수행한다. 즉, 송수신부(1110)는 기저대역 신호를 RF 대역 신호로 상향변환한 후 안테나를 통해 송신하고, 안테나를 통해 수신되는 RF 대역 신호를 기저대역 신호로 하향변환하는 RF 처리부를 포함하며, 송신 필터, 수신 필터, 증폭기, 믹서(mixer), 오실레이터(oscillator), DAC(digital to analog convertor), ADC(analog to digital convertor) 등을 더 포함할 수 있다.

또한 송수신부(1110)는 무선 채널을 통해 신호를 수신하고, 수신된 신호를 프로세서(1130)로 출력하며, 프로세서(1130)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다. 또한, 일부 실시예에 따르면, 도 11에는 하나의 안테나만이 도시되었으나, 상단말(1100)은 다수의 안테나들을 구비할 수 있다. 또한, 송수신부(1110)에는 복수의 RF 체인들이 포함될 수 있다.

송수신부(1110)는 빔포밍(beamforming)을 수행할 수 있다. 빔포밍을 위해, 송수신부(1110)는 복수의 안테나들 또는 안테나 요소(element)들을 통해 송수신되는 신호들 각각의 위상 및 크기를 조절할 수 있다. 또한 송수신부(1110) 내의 기저대역처리부는 시스템의 물리 계층 규격에 따라 기저대역 신호 및 비트열 간 변환 기능을 수행한다. 예를 들어, 데이터 송신 시, 기저대역처리부는 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성한다. 또한, 데이터 수신 시, 기저대역처리부는 RF처리부로부터 제공되는 기저대역 신호를 복조 및 복호화를 통해 수신 비트열을 복원한다. 예를 들어, OFDM(orthogonal frequency division multiplexing) 방식에 따르는 경우, 데이터 송신 시, 기저대역처리부는 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성하고, 복소 심벌들을 부반송파들에 매핑한 후, IFFT(inverse fast Fourier transform) 연산 및 CP(cyclic prefix) 삽입을 통해 OFDM 심벌들을 구성한다. 또한, 데이터 수신 시, 기저대역처리부는 RF처리부로부터 제공되는 기저대역 신호를 OFDM 심벌 단위로 분할하고, FFT(fast Fourier transform) 연산을 통해 부반송파들에 매핑된 신호들을 복원한 후, 복조 및 복호화를 통해 수신 비트열을 복원한다.

송수신부(1110)는 송수신기(transceiver)로 정의될 수 있으며, 메시지 송수신부를 포함할 수 있다. 메시지 처리부(1120)는 송수신부(1110)를 통해 송신하거나 혹은 수신한 데이터가 어떠한 메시지인지를 판단하는 동작을 수행할 수 있다. 예를 들어, 상기 메시지 처리부(1120)는 수신한 메시지가 (SIB(System Information Block)를 포함한) RRC(Radio Resource Control) 계층의 제어 메시지인지 혹은 사용자의 데이터 메시지인지를 판단할 수 있다. 메시지처리부(1120)는 프로세서(1130)에 포함될 수 있다.

프로세서(1130)는 단말(1100)의 전반적인 동작들을 제어한다. 예를 들어, 프로세서(1130)는 메시지 처리부(1120)를 통해 신호를 송수신한다. 또한, 프로세서(1130)는 메모리(1140)에 데이터를 기록하고 읽는다. 프로세서(1130)는 적어도 하나일 수 있다. 예를 들어, 프로세서(1130)는 통신을 위한 제어를 수행하는 CP(communication processor) 및 응용 프로그램 등 상위 계층을 제어하는 AP(application processor)를 포함할 수 있다.

주 단말의 동작에 대한 일부 실시 예에 따르면, 프로세서(1130)는 메시지 처리부(1120), 송수신부(1110), 메모리(1140)로부터 취득한 연결된 eSIM IoT단말의 Capability 정보와 화면 표시부(1160)에서 입력된 소정의 정보를 조합하여 단말에서 eSIM Profile 다운로드를 지원할지 여부를 판별할 수 있다. 상기 프로세서(1130) 및 메시지 처리부(1120), 송수신부(1110)는 사용자가 선택한 사업자 망으로의 접속을 수행하도록 단말(1100)을 제어할 수 있다. 또한, 일부 실시 예에 따르면, 프로세서(1130)는 메모리(1140)를 통해서 읽은 데이터 기록, 또는 프로세서(1130) 및 메시지 처리부(1120), 송수신부(1110)를 통해 수집된 정보를 매칭하여 서비스 선택에 참조할 수 있는 정보를 단말이 추론하는 처리 과정을 수행한다. 예를 들어, 메모리(1140)에 사전에 저장된 정보(예. Device ID, 이전 EPS 등)가 있는 경우, 프로세서(1130)가 해당 정보를 메모리(1140)에 요청하여 화면표시부(1160)가 표시하거나 해당 정보를 받아서 기존 세션 재개 여부 등 동작이 필요한지 여부를 추론할 수 있다. 일부 실시예에 따르면, 프로세서(1130)는 메시지송수신부(1110)에서 수신된 특정 정보에 대한 사용자 동의가 필요한지 여부를 판단하고, 화면 표시부(1160)에 표시할 수 있다. 또한, 프로세서(1130)는 이에 대응하는 동작을 수행하도록 단말(1100)을 제어할 수 있다.

eSIM IoT단말의 동작에 대한 일부 실시 예에서는, 프로세서(1130)는 eSIM Profile 처리 및 eUICC 정보 수집을 위한 LPA 동작이 필요한지를 판단하여 프로세서(1130), 메모리(1140)를 통해 프로파인 다운로드에 필요한 소정의 정보를 취득하여 메시지 처리부(1120) 및 송수신부(1110)을 통해 주 단말의 메시지송수신부(1110)으로 전달하는 과정을 처리할 수 있다. 일부 실시 예에 따르면, 프로세서(1130)는 LPA 등 Secure Element의 구동 및 제어를 담당하는 애플리케이션을 포함할 수 있다. 일부 실시 예에 따르면, 프로세서(1130)은 Activation Code를 메모리(1140) 또는 메시지 송수신부(1110) 및 메시지 처리부(1120)을 통해 수신하고, 다시 메시지 처리부(1120) 및 메시지 송수신부(1110)을 통해서 SM-DP+서버에 정보를 전송할 수 있다. 또한, 프로세서(1140)는 단말에서 LPA 기능을 제공하지 못한다고 판단하는 경우, eSIM Profile 다운로드를 위한 동작을 제한하도록 단말(1100)을 제어할 수 있다.

단말(1100)의 프로세서(1130) 및 메모리(1140)는 소정의 인증 정보를 생성하여 메모리(1140)에 저장하거나, 또는 메시지 송수신부(1110)를 통해서 소정의 인증 정보들이 확보하기 위한 요청을 전송하여 처리하도록 단말(1100)을 제어할 수 있다. 메모리(1140)는 단말(1100)의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 또한 OCF Server단말에서의 메모리(1140)에는 해당 단말에서 지원하는 리소스들에 대한 정보를 저장하는 DB를 포함한다. 메모리(1140)는 단말에 내장된 하드웨어 보안 모듈인 UICC, eUICC, iSSP, iUICC를 포함할 수 있다. 실시 예에서는 메모리(1140)는 롬(ROM), 램(RAM), 하드디스크, CD-ROM 및 DVD 등과 같은 저장 매체 또는 저장 매체들의 조합으로 구성되며 프로세서(1130)의 요청에 따라 저장된 데이터를 제공할 수 있다. 또한, 메모리(1140)은 프로세서(1130)와 SoC(System on Chip)으로 통합 구현되어 있을 수 있다. 예를 들어iSSP의 경우 메모리(1140)가 프로세서(1130)과 통합되어 있다. 또한, 메모리(1140)는 복수 개의 메모리로 구성될 수도 있다

화면표시부(1160)는 프로세서(1130)에서 처리/가공한 정보를 표시하거나 프로세서(1130) 처리를 통해 단말(1100)이 수행하는 동작에 대한 진행 과정 또는 사용자에게 수행을 요청하는 event에 대한 동의 등을 표시할 수 있다. 단말(1100)은 프로세서(1130)의 판단을 통해 화면 표시부(1160)가 단말(1100)이 수행하는 동작에 대한 진행 과정 또는 사용자에게 수행을 요청하는 event에 대한 동의 등을 처리를 수행할 수 없다고 판단하는 경우에 이를 메시지 처리부(1120) 및 메시지송수신부(1110)을 통해 다른 단말의 화면표시부(1160)에 표시할 수 있다. 일부 실시 예에 따르면, 주 단말은 화면표시부(1160)에서 플랜 구매 및 Activation Code에 대한 입력 및 입력된 결과를 사용자에게 회신하여 표시할 수 있으며, 송수신부(1110) 및 처리부(1120)을 통해 (eSIM IoT단말로부터) 요청된 정보를 프로세서(1130)에서 판단하여 화면표시부(1160)에 표기해 줄 수 있다. 다만, 이는 일 예일 뿐, 화면표시부(1160)에 표시되는 정보가 전술한 예시에 제한되지 않는다.

이하, 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.

실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.

마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.

본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시의 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 개시 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.

또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.

이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.

이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.

먼저, 본 개시에서 사용되는 용어에 대해서 정의한다.

UICC (Universal Integrated Circuit Card)는 이동 통신 단말기 등에 삽입하여 사용하는 스마트카드 (smart card)이고 UICC 카드라고도 부른다. UICC에 이동통신사업자의 망에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 이러한 접속 제어 모듈의 예로는 USIM (Universal Subscriber Identity Module), SIM (Subscriber Identity Module), ISIM (IP Multimedia Service Identity Module) 등이 있다. USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM카드라고 부르기도 한다.

본 개시에 개시된 용어 "SIM 카드", "UICC 카드", "USIM 카드", "ISIM이 포함된 UICC"는 본 개시에서 같은 의미로 사용될 수 있다. 즉 SIM 카드라 하여도 그 기술적 적용이 USIM 카드 또는 ISIM 카드 또는 일반적인 UICC 카드에도 동일하게 적용될 수 있다.

SIM 카드는 이동 통신 가입자의 개인정보를 저장하고, 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 (traffic) 보안 키(key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 한다.

SIM 카드는 본 개시를 제안하는 시점에서 일반적으로 카드 제조 시 특정 이동통신 사업자의 요청에 의해 해당 사업자를 위한 전용 카드로 제조되며, 해당 사업자의 네트워크 접속을 위한 인증 정보, 예를 들어, USIM (Universal Subscriber Identity Module) 어플리케이션 및 IMSI (International Mobile Subscriber Identity), K 값, OPc 값 등이 사전에 카드에 탑재되어 출고된다. 따라서 제조된 SIM 카드는 해당 이동통신 사업자가 납품 받아 가입자에게 제공하며, 이후 필요 시에는 OTA (Over The Air) 등의 기술을 활용하여 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리도 수행할 수 있다. 가입자는 소유한 이동통신 단말기에 UICC 카드를 삽입하여 해당 이동통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하며, 단말기 교체 시 UICC 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 UICC 카드에 저장된 인증정보, 이동통신 전화번호, 개인 전화번호부 등을 새로운 단말기에서 그대로 사용이 가능하다.

그러나 SIM카드는 이동통신 단말기 사용자가 다른 이동통신사의 서비스를 제공받는데 있어 불편한 점이 있다. 이동통신 단말기 사용자는 이동통신사업자로부터 서비스를 받기 위해 SIM 카드를 물리적으로 획득해야 되는 불편함이 있다. 예를 들면, 다른 나라로 여행을 했을 때 현지 이동통신 서비스를 받기 위해서는 현지 SIM 카드를 구해야 하는 불편함이 있다. 로밍 서비스의 경우 불편함을 어느 정도 해결해 주지만, 요금이 상대적으로 비싸고, 통신사간 계약이 되어 있지 않은 경우 서비스를 받을 수 없는 문제도 있다.

한편, UICC 카드에 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 이러한 불편함을 상당부분 해결할 수 있다. 즉 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 이러한 UICC 카드는 또한 복수개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 한 개의 SIM 모듈만을 선택하여 사용할 수 있다. 이러한 UICC 카드는 단말에 고정하거나 고정하지 않을 수 있다. 특히 단말에 고정하여 사용하는 UICC를 eUICC (embedded UICC)라고 하는데, 통상적으로 eUICC는 단말에 고정하여 사용하고, 원격으로 SIM 모듈을 다운로드 받아서 선택할 수 있는 UICC 카드를 의미한다. 본 개시에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC로 통칭한다. 즉 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용한다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 eUICC 프로파일, 또는 더 간단히 프로파일 이라는 용어로 사용한다.

이하에서는 본 개시에서 사용되는 용어에 대해서 더 자세히 설명한다.

본 개시에서 UICC는 이동통신 단말기에 삽입하여 사용하는 스마트카드로서 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS와 같은 개인정보가 저장되어 GSM, WCDMA, LTE 등과 같은 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미한다. UICC에는 가입자가 접속하는 이동통신 네트워크의 종류에 따라 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재되며, 또한 전자지갑, 티켓팅, 전자여권 등과 같은 다양한 응용 어플리케이션의 탑재를 위한 상위 레벨의 보안 기능을 제공할 수 있다.

본 개시에서 eUICC(embedded UICC)는 단말에 삽입 및 탈거가 가능한 착탈식 이 아닌 단말에 내장된 칩 형태의 보안 모듈이다. eUICC는 OTA(Over The Air)기술을 이용하여 프로파일을 다운받아 설치할 수 있다. eUICC는 프로파일 다운로드 및 설치가 가능한 UICC로 명명할 수 있다.

본 개시에서 eUICC에 OTA 기술을 이용하여 프로파일을 다운받아 설치하는 방법은 단말에 삽입 및 탈거가 가능한 착탈식 UICC에도 적용될 수 있다. 즉, 본 개시의 실시 예에는 OTA 기술을 이용하여 프로파일을 다운 받아 설치 가능한 UICC에 적용될 수 있다.

본 개시에서 용어 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다.

본 개시에서 프로파일(Profile)은 UICC내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등을 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.

본 개시에서 USIM Profile은 프로파일과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.

본 개시에서 단말이 프로파일을 활성화(enable)하는 동작은, 해당 프로파일의 상태를 활성화 상태(enabled)로 변경하여 단말이 해당 프로파일을 제공한 통신사업자를 통해 통신서비스를 받을 수 있도록 설정하는 동작을 의미할 수 있다. 활성화 상태의 프로파일은 "활성화된 프로파일(enabled Profile)"로 표현될 수 있다.

본 개시에서 단말이 프로파일을 비활성화(disable)하는 동작은, 해당 프로파일의 상태를 비활성화 상태(disabled)로 변경하여 단말이 해당 프로파일을 제공한 통신사업자를 통해 통신서비스를 받을 수 없도록 설정하는 동작을 의미할 수 있다. 비활성화 상태의 프로파일은 "비활성화된 프로파일(disabled Profile)"로 표현될 수 있다.

본 개시에서 단말이 프로파일을 삭제(delete)하는 동작은, 해당 프로파일의 상태를 삭제 상태(deleted)로 변경하여 단말이 더 이상 해당 프로파일을 활성화 또는 비활성화할 수 없도록 설정하는 동작을 의미할 수 있다. 삭제 상태의 프로파일은 "삭제된 프로파일(deleted Profile)"로 표현될 수 있다.

본 개시에서 단말이 프로파일을 활성화(enable), 비활성화(disable), 또는 삭제(delete)하는 동작은, 각 프로파일의 상태를 활성화 상태(enabled), 비활성화 상태(disabled), 또는 삭제 상태(deleted)로 즉시 변경하지 않고, 각 프로파일을 활성화 예정 상태(to be enabled), 비활성화 예정 상태(to be disabled), 또는 삭제 예정 상태(to be deleted)로 우선 표시(marking)만 해두고 단말 내지 단말의 UICC가 특정 동작(예를 들면, 새로 고침(REFRESH) 또는 초기화(RESET) 명령의 수행)을 수행한 이후에 각 프로파일을 활성화 상태(enabled), 비활성화 상태(disabled), 또는 삭제 상태(deleted)로 변경하는 동작을 의미할 수도 있다. 특정 프로파일을 예정 상태(즉 활성화 예정 상태(to be enabled), 비활성화 예정 상태(to be disabled), 또는 삭제 예정 상태(to be deleted))로 표시(marking)하는 동작은 반드시 하나의 프로파일에 대해서 하나의 예정 상태를 표시하는 것으로 제한되지 않으며, 하나 이상의 프로파일을 각각 서로 같거나 다른 예정 상태로 표시하거나, 하나의 프로파일을 하나 이상의 예정 상태로 표시하거나, 하나 이상의 프로파일을 각각 서로 같거나 다른 하나 이상의 예정 상태로 표시하는 것도 가능하다.

또한 단말이 임의의 프로파일에 대해 하나 이상의 예정 상태를 표시하는 경우, 두 개의 표시는 하나로 통합될 수도 있다. 예를 들어 임의의 프로파일이 비활성화 예정 상태(to be disabled) 및 삭제 예정 상태(to be deleted)로 표시된 경우, 해당 프로파일은 비활성화 및 삭제 예정 상태(to be disabled and deleted)로 통합 표시될 수도 있다.

또한 단말이 하나 이상의 프로파일에 대해 예정 상태를 표시하는 동작은 순차적으로 혹은 동시에 수행될 수도 있다. 또한 단말이 하나 이상의 프로파일에 대해 예정 상태를 표시하고 이후 실제 프로파일의 상태를 변경하는 동작은 순차적으로 혹은 동시에 수행될 수도 있다.

본 개시에서 프로파일 제공서버는 프로파일을 생성하거나, 생성된 프로파일을 암호화 하거나, 프로파일 원격관리 명령어를 생성하거나, 생성된 프로파일 원격관리 명령어를 암호화하는 기능을 포함할 수 있다. 프로파일 제공 서버는, SM-DP(Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), off-card entity of Profile Domain, 프로파일 암호화 서버, 프로파일 생성서버, 프로파일 제공자 (Profile Provisioner, PP), 프로파일 공급자 (Profile Provider), PPC holder (Profile Provisioning Credentials holder) 로 표현될 수 있다.

본 개시에서 프로파일 관리서버는 SM-SR(Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing Plus), off-card entity of eUICC Profile Manager 또는 PMC holder (Profile Management Credentials holder), EM (eUICC Manager)로 표현될 수 있다.

본 개시에서 프로파일 제공서버를 지칭할 때, 프로파일 관리서버의 기능을 합친 것을 통칭하는 것일 수도 있다. 따라서 본 개시의 다양한 실시 예에서 즉, 이후의 기술에서 프로파일 제공서버의 동작은 프로파일 관리서버 에서 이루어지는 것도 가능함은 물론이다. 마찬가지로 프로파일 관리서버 또는 SM-SR에 대하여 기술하는 동작은 프로파일 제공서버에서 수행될 수도 있음은 물론이다.

본 개시에서 개통중개서버는 SM-DS (Subscription Manager Discovery Service), DS (Discovery Service), 근원개통중개서버(Root SM-DS), 대체개통중개서버(Alternative SM-DS)로 표현될 수 있다. 개통중개서버는 하나 이상의 프로파일 제공서버 내지 개통중개서버로부터 이벤트 등록 요청(Register Event Request, Event Register Request)을 수신할 수 있다. 또한 하나 이상의 개통중개서버가 복합적으로 사용될 수 있으며, 이 경우 제1 개통중개서버는 프로파일 제공서버뿐만 아니라 제2 개통중개서버로부터 이벤트 등록 요청을 수신할 수도 있다.

본 개시에서 프로파일 제공서버와 개통중개서버는 'RSP (Remote SIM Provisioning) 서버'라는 명칭으로 통칭될 수 있다. RSP 서버는 SM-XX (Subscription Manager XX)로 표현될 수 있다.

본 개시에서 eSIM 기능(eSIM Capability)은 '원격 SIM 제공 기능(Remote SIM Provisioning Capability, 또는 RSP Capability)'이라는 명칭으로 통칭될 수 있다.

본 개시에서 '단말'은 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 일 실시예에서, 단말은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 개시에서 단말은 전자장치라 지칭할 수도 있다.

본 개시에서 전자장치는 프로파일을 다운로드 하여 설치 가능한 UICC가 내장될 수 있다. UICC가 전자장치에 내장되지 않은 경우, 물리적으로 전자장치와 분리된 UICC는 전자장치에 삽입되어 전자장치와 연결될 수 있다. 예를 들어, 카드 형태로 UICC는 전자장치에 삽입될 수 있다. 전자 장치는 단말을 포함할 수 있고, 이때, 단말은 프로파일을 다운로드하여 설치 가능한 UICC를 포함하는 단말일 수 있다. UICC는 단말에 내장될 수 있을 뿐만 아니라, 단말과 UICC가 분리된 경우 UICC는 단말에 삽입될 수 있고, 단말에 삽입되어 단말과 연결될 수도 있다. 프로파일을 다운로드하여 설치 가능한 UICC는 예를 들어 eUICC라 지칭할 수 있다.

본 개시에서 단말 또는 전자장치는 UICC 또는 eUICC를 제어하도록 단말 또는 전자장치 내에 설치된 소프트웨어 또는 애플리케이션을 포함할 수 있다. UICC 또는 eUICC를 제어하도록 단말 또는 전자 장치 내에 설치된 소프트웨어 또는 애플리케이션은, 예를 들어 Local Profile Assistant(LPA)라 지칭할 수 있다.

본 개시에서 프로파일 구분자는 프로파일 식별자 (Profile ID), ICCID (Integrated Circuit Card ID), Matching ID, 이벤트 식별자 (Event ID), 활성화 코드(Activation Code), 활성화 코드 토큰(Activation Code Token), 명령 코드(Command Code), 명령 코드 토큰(Command Code Token), 서명된 명령 코드(Signed Command Code), 서명되지 않은 명령 코드(Unsigned Command Code), ISD-P 또는 프로파일 도메인(Profile Domain, PD)과 매칭되는 인자로 지칭될 수 있다. 프로파일 식별자(Profile ID)는 각 프로파일의 고유 식별자를 나타낼 수 있다. 프로파일 구분자는 프로파일을 색인할 수 있는 프로파일 제공서버(SM-DP+)의 주소를 더 포함할 수 있다. 또한 프로파일 구분자는 프로파일 제공서버(SM-DP+)의 서명을 더 포함할 수 있다.

본 개시에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC의 고유 식별자일 수 있고, EID로 지칭될 수 있다. 또한 eUICC에 프로비저닝 프로파일 (Provisioning Profile)이 미리 탑재되어 있는 경우 해당 프로비저닝 프로파일의 식별자 (Provisioning Profile의 Profile ID)일 수 있다. 또한 본 개시의 실시 예에서와 같이 단말과 eUICC 칩이 분리되지 않을 경우에는 단말 ID일 수 있다. 또한, eUICC칩의 특정 보안 도메인 (Secure Domain)을 지칭할 수도 있다.

본 개시에서 프로파일 컨테이너(Profile Container)는 프로파일 도메인(Profile Domain) 으로 명명될 수 있다. 프로파일 컨테이너 (Profile Container)는 보안 도메인 (Security Domain) 일 수 있다.

본 개시에서 APDU(application protocol data unit)는 단말이 eUICC와 연동하기 위한 메시지 일수 있다. 또한 APDU는 PP(Profile Provider) 또는 PM(Profile Manager)이 eUICC와 연동하기 위한 메시지 일 수다.

본 개시에서 PPC (Profile Provisioning Credentials)는 프로파일 제공서버와 eUICC 간 상호 인증 및 프로파일 암호화, 서명을 하는데 이용되는 수단일 수 있다. PPC는 대칭키, RSA (Rivest Shamir Adleman) 인증서와 개인키, ECC (elliptic curved cryptography) 인증서와 개인키, 최상위 인증 기관(Root certification authority (CA)) 및 인증서 체인(chain) 중 하나 이상을 포함할 수 있다. 또한 프로파일 제공서버가 복수개인 경우에는 복수개의 프로파일 제공서버 별로 다른 PPC를 eUICC에 저장하거나 사용할 수 있다.

본 개시에서 PMC (Profile Management Credentials)는 프로파일 관리서버와 eUICC 간 상호 인증 및 전송 데이터 암호화, 서명을 하는데 이용되는 수단일 수 있다. PMC는 대칭키, RSA 인증서와 개인키, ECC 인증서와 개인키, Root CA 및 인증서 체인 중 하나 이상을 포함할 수 있다. 또한 프로파일 관리서버가 복수개인 경우에는 복수개의 프로파일 관리서버 별로 다른 PMC를 eUICC에 저장하거나 사용할 수 있다.

본 개시에서 AID는 어플리케이션 식별자 (Application Identifier) 일 수 있다. 이 값은 eUICC 내에서 서로 다른 어플리케이션 (Application) 을 구분해주는 구분자일 수 있다.

본 개시에서 이벤트(Event)는 프로파일 다운로드(Profile Download), 또는 원격 프로파일 관리(Remote Profile Management), 또는 기타 프로파일이나 eUICC의 관리/처리 명령어를 통칭하는 용어일 수 있다. 이벤트(Event)는 원격 SIM 제공 동작(Remote SIM Provisioning Operation, 또는 RSP 동작, 또는 RSP Operation) 또는 이벤트 기록(Event Record)으로 명명될 수 있으며, 각 이벤트(Event)는 그에 대응하는 이벤트 식별자(Event Identifier, Event ID, EventID) 또는 매칭 식별자(Matching Identifier, Matching ID, MatchingID)와, 해당 이벤트가 저장된 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 주소(FQDN, IP Address, 또는 URL)와, 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 서명과, 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 디지털 인증서를 적어도 하나 이상 포함하는 데이터로 지칭될 수 있다. 이벤트(Event)에 대응하는 데이터는 활성화 코드(Activation Code) 또는 명령코드(Command Code)로 지칭될 수 있다. 명령코드를 이용하는 절차의 일부 또는 전체를 "활성화 코드 처리 절차" 또는 "명령코드 처리 절차" 또는 "활성화 코드 절차" 또는 "명령코드 절차" 또는 "LPA API(Local Profile Assistant Application Programming Interface)" 또는 "LPA API 절차" 또는 "LPA API 처리 절차"라 지칭할 수 있다. 프로파일 다운로드(Profile Download)는 프로파일 설치(Profile Installation)와 혼용될 수 있다. 또한 이벤트 종류(Event Type)는 특정 이벤트가 프로파일 다운로드인지 원격 프로파일 관리(예를 들어, 삭제, 활성화, 비활성화, 교체, 업데이트 등)인지 또는 기타 프로파일이나 eUICC 관리/처리 명령인지를 나타내는 용어로 사용될 수 있으며, 동작 종류(Operation Type 또는 OperationType), 동작 분류(Operation Class 또는 OperationClass), 이벤트 요청 종류(Event Request Type), 이벤트 분류(Event Class), 이벤트 요청 분류(Event Request Class) 등으로 명명될 수 있다. 임의의 이벤트 식별자(EventID 또는 MatchingID)는 단말이 해당 이벤트 식별자(EventID 또는 MatchingID)를 획득한 경로 또는 사용 용도(EventID Source 또는 MatchingID Source)가 지정되어 있을 수 있다.

본 개시에서 프로파일 패키지(Profile Package)는 프로파일과 혼용되거나 특정 프로파일의 데이터 객체(data object)를 나타내는 용어로 사용될 수 있으며, Profile TLV 또는 프로파일 패키지 TLV (Profile Package TLV)로 명명될 수 있다. 프로파일 패키지가 암호화 파라미터를 이용해 암호화된 경우 보호된 프로파일 패키지(Protected Profile Package (PPP)) 또는 보호된 프로파일 패키지 TLV (PPP TLV)로 명명될 수 있다. 프로파일 패키지가 특정 eUICC에 의해서만 복호화 가능한 암호화 파라미터를 이용해 암호화된 경우 묶인 프로파일 패키지(Bound Profile Package (BPP)) 또는 묶인 프로파일 패키지 TLV (BPP TLV)로 명명될 수 있다. 프로파일 패키지 TLV는 TLV (Tag, Length, Value) 형식으로 프로파일을 구성하는 정보를 표현하는 데이터 세트 (set) 일 수 있다.

본 개시에서 로컬 프로파일 관리(Local Profile Management, LPM)는 프로파일 로컬관리(Profile Local Management), 로컬관리(Local Management), 로컬관리 명령 (Local Management Command), 로컬 명령(Local Command), 로컬 프로파일 관리 패키지 (LPM Package), 프로파일 로컬 관리 패키지(Profile Local Management Package), 로컬관리 패키지(LOCAL MANAGEMENT PACKAGE), 로컬관리 명령 패키지(Local Management Command Package), 로컬명령 패키지(Local Command Package)로 명명될 수 있다. LPM은 단말에 설치된 소프트웨어 등을 통해 특정 프로파일의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 프로파일의 내용 (예를 들면, 프로파일의 별칭(Profile Nickname), 또는 프로파일 요약 정보(Profile Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. LPM은 하나 이상의 로컬관리명령을 포함할 수도 있으며, 이 경우 각 로컬관리명령의 대상이 되는 프로파일은 로컬관리명령마다 서로 같거나 다를 수 있다.

본 개시에서 원격 프로파일 관리(Remote Profile Management, RPM)는 프로파일 원격관리(Profile Remote Management), 원격관리(Remote Management), 원격관리 명령(Remote Management Command), 원격 명령(Remote Command), 원격 프로파일 관리 패키지(RPM Package), 프로파일 원격 관리 패키지(Profile Remote Management Package), 원격관리 패키지(Remote Management Package), 원격관리 명령 패키지(Remote Management Command Package), 원격명령 패키지(Remote Command Package)로 명명될 수 있다. RPM은 특정 프로파일의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 프로파일의 내용(예를 들면, 프로파일의 별칭(Profile Nickname), 또는 프로파일 요약 정보(Profile Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. RPM은 하나 이상의 원격관리명령을 포함할 수도 있으며, 이 경우 각 원격관리명령의 대상이 되는 프로파일은 원격관리명령마다 서로 같거나 다를 수 있다.

본 개시에서 인증서(Certificate) 또는 디지털 인증서(Digital Certificate)는 공개 키(Public Key, PK)와 비밀 키(Secret Key, SK)의 쌍으로 구성되는 비대칭 키(Asymmetric Key) 기반의 상호 인증(Mutual Authentication)에 사용되는 디지털 인증서(Digital Certificate)를 나타낼 수 있다. 각 인증서는 하나 또는 하나 이상의 공개 키(Public Key, PK)와, 각 공개 키에 대응하는 공개 키 식별자(Public Key Identifier, PKID)와, 해당 인증서를 발급한 인증서 발급자(Certificate Issuer, CI)의 식별자(Certificate Issuer ID) 및 디지털 서명(Digital Signature)을 포함할 수 있다.

또한 인증서 발급자(Certificate Issuer)는 인증 발급자(Certification Issuer), 인증서 발급기관(Certificate Authority, CA), 인증 발급기관(Certification Authority) 등으로 명명될 수 있다.

본 개시에서 공개 키(Public Key, PK)와 공개 키 식별자(Public Key ID, PKID)는 특정 공개 키 내지 해당 공개 키가 포함된 인증서, 또는 특정 공개 키의 일부분 내지 해당 공개 키가 포함된 인증서의 일부분, 또는 특정 공개 키의 연산 결과(예를 들면, 해시(Hash))값 내지 해당 공개 키가 포함된 인증서의 연산 결과(예를 들면, 해시(Hash))값, 또는 특정 공개 키의 일부분의 연산 결과(예를 들면, 해시(Hash))값 내지 해당 공개 키가 포함된 인증서의 일부분의 연산 결과(예를 들면, 해시(Hash))값, 또는 데이터들이 저장된 저장 공간을 지칭하는 동일한 의미로 혼용될 수 있다.

본 개시에서 하나의 인증서 발급자(Certificate Issuer)가 발급한 인증서들(1차 인증서)이 다른 인증서(2차 인증서)를 발급하는데 사용되거나, 2차 인증서들이 3차 이상의 인증서들을 연계적으로 발급하는데 사용되는 경우, 해당 인증서들의 상관관계는 인증서 연쇄(Certificate Chain) 또는 인증서 계층구조(Certificate Hierarchy)로 명명될 수 있으며, 이 때 최초 인증서 발급에 사용된 CI 인증서는 인증서 근원(Root of Certificate), 최상위 인증서, 근원 CI(Root CI), 근원 CI 인증서(Root CI Certificate), 근원 CA(Root CA) 근원 CA 인증서(Root CA Certificate)등으로 명명될 수 있다.

본 개시에서 통신사업자 (mobile operator)는 단말에 통신서비스를 제공하는 사업체를 나타낼 수 있으며, 통신사업자의 사업지원시스템 (business supporting system: BSS), 운영지원시스템 (operational supporting system: OSS), POS 단말 (point of sale terminal), 그리고 기타 IT 시스템을 모두 통칭할 수 있다. 또한 본 개시에서 통신사업자는 통신서비스를 제공하는 특정 사업체를 하나만 표현하는데 한정되지 않고, 하나 이상의 사업체의 그룹 또는 연합체 (association 또는 consortium) 내지 해당 그룹 또는 연합체를 대표하는 대행사 (representative)를 지칭하는 용어로 사용될 수도 있다. 또한 본 개시에서 통신사업자는 사업자 (operator 또는 OP 또는 Op.), 모바일 네트워크 운영자 (mobile network operator: MNO), 서비스 제공자 (service provider 또는 SP), 프로파일 소유자 (profile owner: PO) 등으로 명명될 수 있으며, 각 통신사업자는 통신사업자의 이름 그리고/또는 고유 식별자 (object identifier: OID)를 적어도 하나 이상 설정하거나 할당 받을 수 있다. 만일 통신사업자가 하나 이상의 사업체의 그룹 또는 연합체 또는 대행사를 지칭하는 경우, 임의의 그룹 또는 연합체 또는 대행사의 이름 또는 고유 식별자는 해당 그룹 또는 연합체에 소속한 모든 사업체 내지 해당 대행사와 협력하는 모든 사업체가 공유하는 이름 또는 고유 식별자일 수 있다.

본 개시에서 AKA는 인증 및 키 합의 (Authentication and Key agreement) 를 나타낼 수 있으며, 3GPP 및 3GPP2망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다.

본 개시에서 K 는 AKA 인증 알고리즘에 사용되는 eUICC에 저장되는 암호키 값이다.

본 개시에서 OPc는 AKA 인증 알고리즘에 사용되는 eUICC에 저장될 수 있는 파라미터 값이다.

본 개시에서 NAA는 네트워크 접속 어플리케이션 (Network Access Application) 응용프로그램으로, UICC에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망접속 모듈일 수 있다.

본 개시에서 표지자(indicator)는 임의의 기능, 설정, 동작이 필요하거나 필요하지 않음을 표현하는 용도로 사용될 수 있고, 또는 해당 기능, 설정, 동작 자체를 표현하는 용도로도 사용될 수 있다. 또한, 본 개시에서 표지자는 문자열이나 숫자열(alphanumeric string), 참/거짓을 나타내는 연산자(boolean - TRUE or FALSE), 비트맵(bitmap), 어레이(array) 등 다양한 형태로 표현될 수 있으며, 동일한 의미를 가지는 다른 표현법들이 혼용될 수 있다.

그리고, 본 개시를 설명함에 있어서, 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.

도 12는 본 개시의 일 실시 예에 따른 단말에 고정된 프로파일이 탑재된 UICC를 이용한 단말의 이동통신 네트워크 연결방법을 도시하는 도면이다.

도 12에서 도시한 바와 같이, UICC(Universal Integrated Circuit Card,120)는 단말(110)에 삽입될 수 있다. 예를 들면, UICC(120)는 착탈형 일 수도 있고 단말에 미리 내장된 것 일 수도 있다.

고정된 프로파일이 탑재된 UICC에서, 고정된 프로파일은 특정 통신사에 접속할 수 있는 '접속정보'가 고정되어 있음을 의미한다. 예를 들면, 접속정보는 가입자 구분자인 IMSI 및 가입자 구분자와 함께 망에 인증하는데 필요한 K 또는 Ki 값일 수 있다.

다양한 실시 예에 따른 단말(110)은 UICC(120)를 이용하여 이동통신사의 인증처리시스템 (예를 들면, HLR(home location register)이나 AuC(Authentication Center))과 인증을 수행할 수 있다. 예를 들면, 인증과정은 AKA (Authentication and Key Agreement) 과정일 수 있다. 단말은 인증에 성공하면 이동통신시스템의 이동통신네트워크(130)를 이용하여 전화나 모바일 데이터 이용 등의 이동통신 서비스를 이용할 수 있다.

도 13은 본 개시의 일 실시 예에 따른 단말에 하나의 모뎀과 하나의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 시스템의 구성을 도시하는 도면이다.

도 13에 도시된 바와 같이, 단말(200)에는 모뎀(210)과 eUICC(220)가 장착되어 있고, eUICC(220)에는 프로파일(미도시)이 설치되어 있을 수 있다. 또한 단말(200)에는 LPA(Local Profile Assistant, 230)가 설치되어 있을 수 있다.

단말(200)에는 모뎀(210)과 그에 연결된 eUICC(220)가 장착되어 있을 수 있다. 또한, 도 13에는 편의상 모뎀(210)과 eUICC(220)가 별도의 구성요소인 것과 같이 도시되어 있으나, 단말의 구현에 따라 같이 모뎀(210)과 eUICC(220)는 하나의 구성요소로 단말(200)에 포함될 수도 있다. 모뎀(210)과 eUICC(220)의 연결 링크는, 예를 들면, SIM 포트(SIM port)로 통칭될 수 있다. eUICC(220)는 LPA(230)의 제어를 받을 수 있다.

단말(200)에는 임의의 통신사업자의 애플리케이션(이하 "사업자 앱", 240)이 더 설치되어 있을 수 있다. 사업자 앱(240)은 LPA(230) 및 임의의 통신사업자의 서버(이하 "사업자 서버" 또는 "사업자", 260)와 연결되어 있을 수 있다. 또한 도 13에는 편의상 단말에 사업자 앱(240)이 하나만 설치되어 있고 하나의 사업자 서버(260)가 연결된 경우를 도시하였으나, 구현 및 실시 예에 따라 하나 이상의 사업자 앱(240)이 단말에 설치되거나 하나 이상의 사업자 서버(260)가 구성에 포함될 수도 있다. 이렇게 다양한 단말과 서버의 구성을 도 13 및 이하 도면들에서는 간략하게 사업자 앱(240)과 사업자 서버(260)로 표기함에 유의해야 한다.

한편, 도 13은 모뎀(210), eUICC(220), LPA(230), 사업자 앱(240)이 모두 같은 단말(200)에 설치되어 있는 것으로 도시되어 있으나, 다양한 실시 예에 따라 각 구성 요소들은 하나 이상 구성에 포함될 수 있으며, 또한, 하나 이상의 서로 다른 단말에 설치되어 있을 수도 있다. 이와 같이 다양한 단말(200) 및 모뎀(210), eUICC(220), LPA(230), 사업자 앱(240)의 구성을 도 13 및 이하 도면들에는 간단하게 하나의 단말로 표기함에 유의해야 한다.

사업자 서버(260)와 LPA(230)는 프로파일 서버(250)와 연결되어 있을 수 있다. 또한, 하나 이상의 사업자 서버(240)가 구성에 포함되는 경우, 각 사업자 서버는 별도의 각 프로파일 서버와 연결되어 있을 수도 있고, 적어도 하나 이상의 사업자 서버가 동일한 프로파일 서버에 연결되어 있을 수도 있다. 이하 임의의 사업자 서버와 해당 사업자 서버에 연결된 프로파일 서버를 통틀어 "사업자 영역(MNO domain 또는 operator domain)이라 명명할 수 있다. 또한, 도면에는 편의상 프로파일 서버(250)가 단일 서버로 구성되는 경우를 도시하였으나, 구현 및 실시 예에 따라 하나 이상의 프로파일 서버(SM-DP+)가 서버 구성에 포함될 수 있고, 특정 프로파일 서버와 단말의 연결 생성을 보조하는 하나 이상의 개통중개서버(SM-DS)가 서버 구성에 포함될 수도 있다. 이와 같이 다양한 서버의 구성을 도 13 및 이하 도면들에는 간략하게 프로파일 서버(250)로 표기함에 유의해야 한다.

도 13을 참조하면, 2001 동작에서 단말(200)은, 활성화 코드를 생성하기 위한 정보를 LPA(230)에서 생성하고, 사업자 앱(240)을 거쳐 사업자 서버(260)로 전달할 수 있다. 활성화 코드를 생성하기 위한 정보는, 예를 들면, LPA API 정보(LPA API info 또는 lpaApiInfo 또는 LPA API configuration 또는 lpaApiConfig)로 표현될 수 있다. LPA API 정보(LPA API info)는, 적어도 단말(200)과 모뎀(210)에 대한 정보와, eUICC(220)에 대한 정보를 포함할 수 있다. 단말(200)과 모뎀(210)에 대한 정보는, 예를 들면, 단말 정보(device info 또는 deficeInfo)로 표현될 수 있다. eUICC(220)에 대한 정보는, 예를 들면, eUICC 정보(eUICC info 또는 euiccInfo)로 표현될 수 있다. 단말 정보(device info)는, 적어도 모뎀(210)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(230)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. eUICC 정보(euicc info)는, 적어도 eUICC(220)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, eUICC(220)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 2001 단계는, 예를 들면, LPA API 시작 요청(initiate LPA API request) 메시지와, LPA API 시작 응답(initiate LPA API response) 메시지와, eUICC 정보 요청(get eUICC info request 또는 get eUICC info1 request 또는 get eUICC info2 request) 메시지와, eUICC 정보 응답(get eUICC info response 또는 get eUICC info1 response 또는 get eUICC info2 response) 메시지와, eUICC 식별자 요청(get eUICC ID request) 메시지와, eUICC 식별자 응답(get eUICC ID response) 중 적어도 하나 이상을 이용할 수 있다.

2003 단계에서 사업자 서버(260)는 LPA API 정보를 이용하여 프로파일 서버(250)와 함께 이벤트(Event)를 준비할 수 있다. 이벤트는 프로파일 다운로드(profile download)를 수행하거나, 원격 프로파일 관리(remote profile management)를 수행하거나, 기타 프로파일 또는 eUICC를 제어하거나 처리하는 동작일 수 있다. 또한, 2003 단계에서 사업자 서버(260)와 프로파일 서버(250)는 이벤트에 대응하는 활성화 코드(activation code)를 더 생성할 수 있다. 2003 단계는, 예를 들면, 다운로드 주문 요청(download order request) 메시지와, 다운로드 주문 응답(download order response) 메시지와, 확정 주문 요청(confirm order request) 메시지와, 확정 주문 응답(confirm order response) 메시지와, 배포 주문 요청(release order request) 메시지와, 배포 주문 응답(release order response) 메시지와, 원격관리 주문 요청(RPM order request) 메시지와, 원격관리 주문 응답(RPM order response) 메시지 중 적어도 하나 이상을 사용할 수 있다. 2003 단계의 일부 또는 전체는 2003 단계 이전에 수행될 수도 있다. 예를 들어, 2003 단계 이전에 하나 이상의 이벤트를 사전에 준비하고, 2003 동작에서 LPA API 정보에 기반하여 이벤트를 선택하고 해당 이벤트에 대응하는 활성화 코드(activation code)를 생성할 수도 있다. 활성화 코드를 생성하는 절차는 하나 이상의 프로파일 서버를 더 포함하거나 사용자(미도시)를 더 포함하는 절차일 수도 있다.

2005 단계에서 사업자 서버(260)는 사업자 앱(240)을 통해 활성화 코드(activation code)를 LPA(230)에 전달할 수 있다. 2005 단계는, 예를 들면, LPA API 실행 요청(execute LPA API request) 메시지와, LPA API 실행 응답(execute LPA API response) 메시지와, 활성화 코드 실행 요청(execute activation code request) 메시지와, 활성화 코드 실행 응답(execute activation code response) 메시지와, 명령 코드 실행 요청(execute command code response) 메시지와, 명령 코드 실행 응답(execute command code response) 메시지와, 활성화 코드 입력 요청(push activation code request) 메시지와, 활성화 코드 입력 응답(push activation code response) 메시지와, 명령 코드 입력 요청(push command code request) 메시지와, 명령 코드 입력 응답(push command code response) 메시지 중 적어도 하나 이상을 사용할 수 있다.

2007 단계에서 LPA(230)는 활성화 코드를 이용하여 프로파일 서버(250)로부터 이벤트를 수신하고, eUICC(220)로 해당 이벤트의 일부 또는 전체를 전달하여 처리할 수 있다. 2007 단계는, 예를 들면, 인증 시작 요청(initiate authentication request) 메시지와, 인증 시작 응답(initiate authentication response) 메시지와, 단말 인증 요청(authenticate client request) 메시지와, 단말 인증 응답(authenticate client response) 메시지와, 프로파일 패키지 요청(get bound profile package request) 메시지와, 프로파일 패키지 응답(get bound profile package response) 메시지와, 서버 인증 요청(authenticate server request) 메시지와, 서버 인증 응답(authenticate server response) 메시지와, 다운로드 준비 요청(prepare download request) 메시지와, 다운로드 준비 응답(prepare download response) 메시지와, 프로파일 패키지 설치 요청(load bound profile package request) 메시지와, 프로파일 패키지 설치 응답(load bound profile package response) 메시지와, 원격관리 패키지 설치 요청(load RPM package request) 메시지와, 원격관리 패키지 설치 응답(load RPM package response) 메시지와, 공지 처리 요청(handle notification request) 메시지 중 적어도 하나 이상을 사용할 수 있다.

다양한 실시 예에 따른 단말(200), 모뎀(210), eSIM(220), LPA(230), 사업자 앱(240), 프로파일 서버(250), 사업자 서버(260)의 상세한 동작 및 메시지 교환 절차는 후술할 도면들을 참조하여 자세히 살펴보기로 한다.

도 14는 본 개시의 일 실시 예에 따른 단말에 하나의 모뎀과 하나의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 절차를 도시하는 도면이다.

도 14에서 단말(200), 모뎀(210), eUICC(220), LPA(430), 사업자 앱(240), 사업자 서버(250), 프로파일 서버(260)에 대한 자세한 구성과 설명은 도 13을 참조하기로 한다. 또한, 도 14에는 편의상 모뎀(210)과 eUICC(220)가 하나의 구성요소인 것과 같이 도시되어 있으나, 단말의 구현에 따라 도 13과 같이 모뎀(210)과 eUICC(220)는 서로 다른 구성요소로 단말(200)에 포함될 수도 있다.

도 14를 참조하면, 3001 단계에서 LPA(230)와 사업자 앱(240)은 LPA API 절차를 시작할 수 있다. 또한, 3001 단계는 사업자 서버(250)와의 연동을 더 포함할 수도 있다. 또한, 3001 단계는 LPA(230)에 의해 시작되거나, 사업자 앱(240)에 의해 시작되거나, 단말(200)이 특정 조건(예를 들면, 단말이 최초 부팅되거나 재부팅 되는 경우, 단말이 로밍(roaming) 상태임을 감지한 경우 등)을 만족했을 때 단말(200)에 설치된 운영체제(operating system, OS) 및 기타 구성요소에 의해 시작되거나, 사용자(미도시)가 LPA(230)에 요청해 시작되거나, 사용자(미도시)가 사업자 앱(240)에 요청해 시작되거나, 사업자 서버(250)가 사업자 앱(240)에 요청해 시작될 수도 있다. 3001 단계가 사용자의 입력에 의해 시작되거나, 다른 조건에 의해 시작되었더라도 사용자의 추가 입력이 필요한 경우, 3001 단계는 사용자(미도시)의 입력을 포함할 수도 있다. 3001 단계는, 예를 들면, LPA API 시작 요청(initiate LPA API request) 메시지를 이용할 수 있다.

3003 단계에서 LPA(230)는 모뎀(210)과 eUICC(220)를 통해 단말 정보(device info)와 eUICC 정보(eUICC info)를 획득할 수 있다. 단말 정보(device info)는, 적어도 모뎀(210)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(230)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. eUICC 정보(eUICC info)는, 적어도 eUICC(220)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, eUICC(220)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 3003 단계는, eUICC 정보 요청(get eUICC info request) 메시지와, eUICC 정보 응답(get eUICC info response) 메시지 중 적어도 하나 이상을 이용할 수 있다. 또한, 3003 단계는, 단말(200)의 구현에 따라 모뎀(210)과 eUICC(220)가 별도의 구성 요소로 포함된 경우, 한 번 이상의 요청 메시지 및 응답 메시지 교환을 포함할 수 있으며, 단말(200)의 동작에 따라 단말 정보(device info)와 eUICC 정보(eUICC info)의 일부 또는 전체가 LPA(230)에 이미 알려져 있는 경우, 3003 단계의 일부 또는 전체는 생략될 수도 있다.

3005 단계에서 LPA(230)는 적어도 단말 정보(device info)와 eUICC 정보(eUICC info)를 포함하는 LPA API 정보(LPA API info)를 구성하여 사업자 앱(240)에 회신할 수 있다. 이 때, LPA API 정보를 구성하는 동작은 3003 단계와 함께 수행될 수도 있다. 3005 단계는, 예를 들면, LPA API 시작 응답(initiate LPA API response) 메시지를 이용할 수 있다.

3007 단계에서 사업자 앱(240)는 사업자 서버(250)로 상기 LPA API 정보(LPA API info)를 전달할 수 있다. 또한, 도 14에는 도시되지 않았으나, 3007 단계은 사업자 앱(240)의 정보(예를 들면, 앱의 버전 정보)나 사용자에 관련된 정보(예를 들면, 사용자의 이름, 주소, 연락처 등 개인정보와 결제정보)를 더 포함할 수도 있다.

3009 단계에서 사업자 서버(250)는 LPA API 정보(LPA API info)를 이용하여 프로파일 서버(260)와 함께 이벤트(Event)를 준비하고, 해당 이벤트에 대응하는 활성화 코드(activation code)를 더 생성할 수 있다. 3009 단계는, 예를 들면, 다운로드 주문 요청(download order request) 메시지와, 다운로드 주문 응답(download order response) 메시지와, 확정 주문 요청(confirm order request) 메시지와, 확정 주문 응답(confirm order response) 메시지와, 배포 주문 요청(release order request) 메시지와, 배포 주문 응답(release order response) 메시지와, 원격관리 주문 요청(RPM order request) 메시지와, 원격관리 주문 응답(RPM order response) 메시지 중 적어도 하나 이상을 사용할 수 있다. 3009 단계의 일부 또는 전체는 3009 단계 이전에 수행될 수도 있다. 예를 들어, 3009 단계 이전에 하나 이상의 이벤트를 사전에 준비하고, 3009 단계에서 LPA API 정보에 기반하여 이벤트를 선택하고 해당 이벤트에 대응하는 활성화 코드(activation code)를 생성할 수도 있다. 활성화 코드를 생성하는 절차는 하나 이상의 프로파일 서버를 더 포함하거나 사용자(미도시)를 더 포함하는 절차일 수도 있다.

3011 딘계에서 사업자 서버(250)는 사업자 앱(240)으로 활성화 코드(activation code)를 전달할 수 있다.

3013 단계에서 사업자 앱(240)는 LPA(230)로 상기 활성화 코드(activation code)를 전달할 수 있다. 3013 단계는, 예를 들면, LPA API 실행 요청(execute LPA API request) 메시지와, 활성화 코드 실행 요청(execute activation code request) 메시지와, 명령 코드 실행 요청(execute command code response) 메시지와, 활성화 코드 입력 요청(push activation code request) 메시지와, 명령 코드 입력 요청(push command code request) 메시지 중 적어도 하나 이상을 사용할 수 있다.

3015 단계에서 단말(200), 사업자 서버(250), 프로파일 서버(260)는 상기 활성화 코드에 대응하는 이벤트를 처리할 수 있다. 또한 단말(200)은 이벤트 처리 이후 이벤트 처리 결과를 이용하여 네트워크에 더 접속할 수 있다. 이벤트를 처리하는 동작은, 프로파일 다운로드(profile download)를 수행하거나, 원격 프로파일 관리(remote profile management)를 수행하거나, 기타 프로파일 또는 eUICC를 제어하거나 처리하는 동작일 수 있다. 3015 단계는, 예를 들면, LPA API 실행 응답(execute LPA API response) 메시지와, 활성화 코드 실행 응답(execute activation code response) 메시지와, 명령 코드 실행 응답(execute command code response) 메시지와, 활성화 코드 입력 응답(push activation code response) 메시지와, 명령 코드 입력 응답(push command code response) 메시지와, 인증 시작 요청(initiate authentication request) 메시지와, 인증 시작 응답(initiate authentication response) 메시지와, 단말 인증 요청(authenticate client request) 메시지와, 단말 인증 응답(authenticate client response) 메시지와, 프로파일 패키지 요청(get bound profile package request) 메시지와, 프로파일 패키지 응답(get bound profile package response) 메시지와, 서버 인증 요청(authenticate server request) 메시지와, 서버 인증 응답(authenticate server response) 메시지와, 다운로드 준비 요청(prepare download request) 메시지와, 다운로드 준비 응답(prepare download response) 메시지와, 프로파일 패키지 설치 요청(load bound profile package request) 메시지와, 프로파일 패키지 설치 응답(load bound profile package response) 메시지와, 원격관리 패키지 설치 요청(load RPM package request) 메시지와, 원격관리 패키지 설치 응답(load RPM package response) 메시지와, 공지 처리 요청(handle notification request) 메시지 중 적어도 하나 이상을 사용할 수 있다.

도 14를 참조하면, 단말(200)에 하나의 모뎀(210)과 하나의 eUICC(220)가 장착된 경우, LPA API 정보(LPA API info)가 별도의 eUICC 식별 정보를 포함하지 않더라도, 활성화 코드(activation code)에 대응하는 이벤트(event)를 처리할 대상인 eUICC(220)가 자명하므로, 이벤트의 처리에 문제가 없다.

도 15는 본 개시의 일 실시 예에 따른 단말에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 시스템의 구성을 도시하는 도면이다.

도 15에 도시된 바와 같이, 단말(400)에는 제1 모뎀(410) 및 제2 모뎀(415)과 제1 eUICC(420) 및 제2 eUICC(425)가 장착되어 있고, 제1 eUICC(420) 그리고/또는 제2 eUICC(425)에는 프로파일(미도시)이 설치되어 있을 수 있다. 또한 단말(400)에는 LPA(430)가 설치되어 있을 수 있다.

단말(400)에는 제1 모뎀(410)과 그에 연결된 제1 eUICC(420)가 장착되어 있고, 제2 모뎀(415)와 그에 연결된 제2 eUICC(425)가 장착되어 있을 수 있다. 또한 도 15에는 편의상 제1 모뎀(410), 제1 eUICC(420), 제2 모뎀(415), 제2 eUICC(425)가 각각 별도의 구성요소인 것과 같이 도시되어 있으나, 단말의 구현에 따라 제1 모뎀(410), 제1 eUICC(420), 제2 모뎀(415), 제2 eUICC(425) 중 적어도 하나 이상은 하나의 구성요소로 단말(200)에 포함될 수도 있다. 예를 들어, 제1 모뎀(410)과 제2 모뎀(415)가 하나의 모뎀으로 구성될 수도 있고, 제1 eUICC(420)와 제2 eUICC(425)가 하나의 eUICC로 구성될 수도 있고, 제1 모뎀(410)과 제2 모뎀(415)과 제1 eUICC(420)와 제2 eUICC(425)가 모두 하나의 칩 시스템(system on chip, SoC)로 구성될 수도 있다. 제1 모뎀(410)과 제1 eUICC(420)의 연결 링크는, 예를 들면, 제1 SIM 포트(SIM port)로 통칭될 수 있다. 제2 모뎀(415)과 제2 eUICC(425)의 연결 링크는, 예를 들면, 제2 SIM 포트(SIM port)로 통칭될 수 있다. 또한, 도 15에는 편의상 제1 모뎀(410)과 제1 eUICC(420)이 연결되어 있고, 제2 모뎀(415)과 제2 eUICC(425)가 연결되어 있는 것으로 도시되어 있으나, 단말(400)의 구현에 따라 제1 모뎀(410), 제1 eUICC(420), 제2 모뎀(415), 제2 eUICC(425)의 연결은 단말(400) 또는 사용자(미도시)에 의해 동적으로 변경될 수도 있다. 단말(400)은, 예를 들어, 제1 모뎀(410)과 제2 eUICC(425)를 연결하고, 제2 모뎀(415)와 제1 eUICC(420)를 연결할 수도 있다. 또 다른 예로, 제1 모뎀(410)과 제1 eUICC(420)를 연결하고, 제1 모뎀(410)과 제2 eUICC(425)를 연결하고, 제2 모뎀(415)는 어떠한 eUICC에도 연결되지 않은 상태로 설정할 수도 있다. 또 다른 예로, 제1 모뎀(410)과 제1 eUICC(420)를 연결하고, 제2 모뎀(415)과 제1 eUICC(420)를 연결하고, 제2 eUICC는 어떠한 모뎀에도 연결되지 않은 상태로 설정할 수도 있다. 이와 같이 제1 모뎀(410), 제1 eUICC(420), 제2 모뎀(415), 제2 eUICC(425)의 연결은 다양한 형태로 변경될 수 있으나, 도 15 및 이하의 도면들에서는 임의의 시점에서 모뎀과 eUICC의 연결상태를 가정하고 모뎀과 eUICC가 일대 일로 대응되는 것과 같이 표기함에 유의해야 한다. 제1 eUICC(420)와 제2 eUICC(425)는 LPA(430)의 제어를 받을 수 있다. 또한, 도 15에는 편의상 LPA(430)가 하나의 구성요소인 것과 같이 도시되어 있으나, 단말(400)의 구현에 따라 LPA(430)는 하나 이상의 구성요소로 분리되어, 하나 이상의 eUICC를 각각 제어할 수도 있다. 이와 같은 다양한 LPA(430)의 구성을 도 15 및 이하의 도면들에서는 하나의 LPA(430)로 표기함에 유의해야 한다.

단말(400)에는 임의의 통신사업자의 애플리케이션(이하 "사업자 앱", 440)이 더 설치되어 있을 수 있다. 사업자 앱(440)은 LPA(430) 및 임의의 통신사업자의 서버(이하 "사업자 서버" 또는 "사업자", 460)와 연결되어 있을 수 있다. 또한, 도면에는 편의상 단말에 사업자 앱(440)이 하나만 설치되어 있고 하나의 사업자 서버(460)가 연결된 경우를 도시하였으나, 구현 및 실시 예에 따라 하나 이상의 사업자 앱(440)이 단말에 설치되거나 하나 이상의 사업자 서버(460)가 구성에 포함될 수도 있다. 이렇게 다양한 단말과 서버의 구성을 도 15 및 이하 도면들에서는 간략하게 사업자 앱(440)과 사업자 서버(460)로 표기함에 유의해야 한다.

한편, 도 15는 제1 모뎀(410), 제2 모뎀(415), 제1 eUICC(420), 제2 eUICC(425), LPA(430), 사업자 앱(440)이 모두 같은 단말(400)에 설치되어 있는 것으로 도시되어 있으나, 다양한 실시 예에 따라 각 구성 요소들은 하나 이상 구성에 포함될 수 있으며, 또한, 하나 이상의 서로 다른 단말에 설치되어 있을 수도 있다. 이와 같이 다양한 제1 모뎀(410), 제2 모뎀(415), 제1 eUICC(420), 제2 eUICC(425), LPA(430), 사업자 앱(440)의 구성을 도 4 및 이하 도면들에는 간단하게 하나의 단말로 표기함에 유의해야 한다.

사업자 서버(460)와 LPA(430)는 프로파일 서버(450)와 연결되어 있을 수 있다. 또한 하나 이상의 사업자 서버(440)가 구성에 포함되는 경우, 각 사업자 서버는 별도의 각 프로파일 서버와 연결되어 있을 수도 있고, 적어도 하나 이상의 사업자 서버가 동일한 프로파일 서버에 연결되어 있을 수도 있다. 이하 임의의 사업자 서버와 해당 사업자 서버에 연결된 프로파일 서버를 통틀어 "사업자 영역(MNO domain 또는 operator domain)이라 명명할 수 있다. 또한 도면에는 편의상 프로파일 서버(450)가 단일 서버로 구성되는 경우를 도시하였으나, 구현 및 실시 예에 따라 하나 이상의 프로파일 서버(SM-DP+)가 서버 구성에 포함될 수 있고, 특정 프로파일 서버와 단말의 연결 생성을 보조하는 하나 이상의 개통중개서버(SM-DS)가 서버 구성에 포함될 수도 있다. 이와 같이 다양한 서버의 구성을 도 15 및 이하 도면들에는 간략하게 프로파일 서버(450)로 표기함에 유의해야 한다.

도 15를 참조하면, 4001 단계에서 단말(400)은, 제1 eUICC(420)가 처리할 활성화 코드를 생성하기 위한 정보를 LPA(430)에서 생성할 수 있다. 제1 eUICC(420)가 처리할 활성화 코드를 생성하기 위한 정보는, 예를 들면, 제1 LPA API 정보(LPA API info 1 또는 lpaApiInfo1)로 표현될 수 있다. 제1 LPA API 정보(LPA API info 1)는, 적어도 단말(400)과 제1 모뎀(410)에 대한 정보와, 제1 eUICC(420)에 대한 정보와, 제1 eUICC(420)의 색인번호(index)를 포함할 수 있다. 단말(400)과 제1 모뎀(410)에 대한 정보는, 예를 들면, 제1 단말 정보(device info 1 또는 deficeInfo1)로 표현될 수 있다. 제1 eUICC(420)에 대한 정보는, 예를 들면, 제1 eUICC 정보(eUICC info 1 또는 euiccInfo1)로 표현될 수 있다. 제1 단말 정보(device info 1)는, 적어도 제1 모뎀(410)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제1 eUICC 정보(euicc info 1)는, 적어도 제1 eUICC(420)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제1 eUICC(420)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 제1 eUICC(420)의 색인번호(index)는, 예를 들면, 제1 eUICC(420)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)를 이용하거나, 제1 eUICC(420)와 제1 모뎀(410)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)를 이용하거나, 제1 eUICC(420)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)를 이용할 수 있다. 4001 단계는, 예를 들면, eUICC 정보 요청(get eUICC info request) 메시지와, eUICC 정보 응답(get eUICC info response) 메시지와, eUICC 식별자 요청(get eUICC ID request) 메시지와, eUICC 식별자 응답(get eUICC ID response) 중 적어도 하나 이상을 이용할 수 있다.

4002 단계에서 단말(400)은, 제2 eUICC(425)가 처리할 활성화 코드를 생성하기 위한 정보를 LPA(430)에서 생성할 수 있다. 제2 eUICC(425)가 처리할 활성화 코드를 생성하기 위한 정보는, 예를 들면, 제2 LPA API 정보(LPA API info 2 또는 lpaApiInfo2)로 표현될 수 있다. 제2 LPA API 정보(LPA API info 2)는, 적어도 단말(400)과 제2 모뎀(415)에 대한 정보와, 제2 eUICC(425)에 대한 정보와, 제2 eUICC(425)의 색인번호(index)를 포함할 수 있다. 단말(400)과 제2 모뎀(415)에 대한 정보는, 예를 들면, 제2 단말 정보(device info 2 또는 deficeInfo2)로 표현될 수 있다. 제2 eUICC(425)에 대한 정보는, 예를 들면, 제2 eUICC 정보(eUICC info 2 또는 euiccInfo2)로 표현될 수 있다. 제2 단말 정보(device info 2)는, 적어도 제2 모뎀(415)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제2 eUICC 정보(euicc info 2)는, 적어도 제2 eUICC(425)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제2 eUICC(425)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 제2 eUICC(425)의 색인번호(index)는, 예를 들면, 제2 eUICC(425)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)를 이용하거나, 제2 eUICC(425)와 제2 모뎀(415)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)를 이용하거나, 제2 eUICC(425)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)를 이용할 수 있다. 4002 단계는, 예를 들면, eUICC 정보 요청(get eUICC info request) 메시지와, eUICC 정보 응답(get eUICC info response) 메시지와, eUICC 식별자 요청(get eUICC ID request) 메시지와, eUICC 식별자 응답(get eUICC ID response) 중 적어도 하나 이상을 이용할 수 있다.

4001 단계와 4002 단계의 일부 또는 전체는 4003 단계 이후에 수행될 수도 있다. 예를 들어, 4003 단계에서 사업자 앱(440)이 LPA(430)에 LPA API 실행을 요청하면, LPA(430)는 4001 단계 및 4002 단계를 통해 제1 LPA API 정보와 제2 LPA API 정보를 준비하고, 사업자 앱(440)에 제1 LPA API 정보와 제2 LPA API 정보를 회신해 LPA API 실행을 응답할 수 있다. 또 다른 예로, LPA(430)는 4003 단계 전에 4001 단계와 4002 단계를 통해 제1 LPA API 정보와 제2 LPA API 정보를 준비하고, 사업자 앱(440)이 LPA(430)에 LPA API 실행을 요청하면, LPA(430)는 사업자 앱(440)에 제1 LPA API 정보와 제2 LPA API 정보를 회신해 LPA API 실행을 응답할 수 있다. 또 다른 예로, LPA(430)는 4003 단계 전에 4001 단계를 통해 제1 LPA API 정보를 준비하고, 사업자 앱(440)이 LPA(430)에 LPA API 실행을 요청하면, LPA(430)는 4002 단계를 통해 제2 LPA API 정보를 더 준비하고, 사업자 앱(440)에 제1 LPA API 정보와 제2 LPA API 정보를 회신해 LPA API 실행을 응답할 수 있다.

4003 단계에서 단말(400)은 제1 LPA API 정보(LPA API info1)와 제2 LPA API 정보(LPA API info2) 중 적어도 하나 이상을 선택하고, 사업자 앱(440)을 거쳐 사업자 서버(460)로 전달할 수 있다. 4003 단계는, 예를 들면, LPA API 실행 요청(execute LPA API request) 메시지와, LPA API 실행 응답(execute LPA API response) 메시지 중 적어도 하나 이상을 사용할 수 있다.

4005 단계에서 사업자 서버(460)는 제1 LPA API 정보와 제2 LPA API 정보 중 적어도 하나 이상을 선택하고, 선택된 정보를 이용하여 프로파일 서버(450)와 함께 이벤트(Event)를 준비할 수 있다. 이벤트는 프로파일 다운로드(profile download)를 수행하거나, 원격 프로파일 관리(remote profile management)를 수행하거나, 기타 프로파일 또는 eUICC를 제어하거나 처리하는 동작일 수 있다. 또한, 4005 단계에서 사업자 서버(460)와 프로파일 서버(450)는 이벤트에 대응하는 활성화 코드(activation code)를 더 생성할 수 있다. 4005 단계는, 예를 들면, 다운로드 주문 요청(download order request) 메시지와, 다운로드 주문 응답(download order response) 메시지와, 확정 주문 요청(confirm order request) 메시지와, 확정 주문 응답(confirm order response) 메시지와, 배포 주문 요청(release order request) 메시지와, 배포 주문 응답(release order response) 메시지와, 원격관리 주문 요청(RPM order request) 메시지와, 원격관리 주문 응답(RPM order response) 메시지 중 적어도 하나 이상을 사용할 수 있다. 4005 단계의 일부 또는 전체는 4005 단계 이전에 수행될 수도 있다. 예를 들어, 4005 단계 이전에 하나 이상의 이벤트를 사전에 준비하고, 4005 단계에서 LPA API 정보에 기반하여 이벤트를 선택하고 해당 이벤트에 대한 활성화 코드(activation code)를 생성할 수도 있다. 활성화 코드를 생성하는 절차는 하나 이상의 프로파일 서버를 더 포함하거나 사용자(미도시)를 더 포함하는 절차일 수도 있다.

4007 단계에서 사업자 서버(460)는 사업자 앱(440)을 통해 활성화 코드(activation code)를 LPA(430)에 전달하고, 추가적으로 해당 활성화 코드를 처리해야 할 대상이 되는 eUICC의 색인번호를 하나 이상 더 공지(notify)할 수 있다. eUICC의 색인 번호는, 4005 단계에서 사업자 서버(460)가 제1 LPA API 정보와 제2 LPA API 정보 중 적어도 하나 이상 선택한 결과를 참조할 수 있다. 예를 들어, 4005 단계에서 사업자 서버(460)가 제1 LPA API 정보를 선택한 경우, 4007 단계에서 사업자 서버(460)는 제1 LPA API 정보에 포함된 제1 eUICC(420)의 색인번호를 공지(notify)할 수 있다. 또 다른 예로, 4005 단계에서 사업자 서버(460)가 제1 LPA API 정보와 제2 LPA API 정보를 선택한 경우, 4007 단계에서 사업자 서버(460)는 제1 LPA API 정보에 포함된 제1 eUICC(420)의 색인번호와 제2 LPA API 정보에 포함된 제2 eUICC(425)의 색인번호를 공지할 수 있다. 4007 단계는, 예를 들면, 활성화 코드 실행 요청(execute activation code request) 메시지와, 활성화 코드 실행 응답(execute activation code response) 메시지와, 명령 코드 실행 요청(execute command code response) 메시지와, 명령 코드 실행 응답(execute command code response) 메시지와, 활성화 코드 입력 요청(push activation code request) 메시지와, 활성화 코드 입력 응답(push activation code response) 메시지와, 명령 코드 입력 요청(push command code request) 메시지와, 명령 코드 입력 응답(push command code response) 메시지 중 적어도 하나 이상을 사용할 수 있다.

4009 단계에서 LPA(430)는 사업자 서버(460)가 공지한 eUICC 색인번호를 참조하여 활성화 코드를 처리해야 할 대상이 되는 eUICC를 선택할 수 있다. 만일 사업자 서버가 어떠한 eUICC 색인번호도 공지하지 않은 경우, LPA(430)는 제1 eUICC(410)와 제2 eUICC(425) 중 하나를 임의로 선택할 수 있다. 만일 사업자 서버가 복수의 eUICC 색인번호를 공지한 경우, LPA(430)는 공지된 eUICC 색인번호 중 하나를 임의로 선택할 수 있다. LPA(430)가 eUICC를 임의로 선택하는 기준은, 예를 들면, 각 eUICC의 잔여 가용 메모리를 참조하거나, 각 eUICC에 설치된 프로파일의 개수를 참조하거나, 각 eUICC에 연결된 모뎀의 정보를 참조할 수 있다. 또한 LPA(430)는 활성화 코드를 이용하여 프로파일 서버(450)로부터 이벤트를 수신하고, 선택된 eUICC로 해당 이벤트의 일부 또는 전체를 전달하여 처리할 수 있다. 4009 단계는, 예를 들면, 인증 시작 요청(initiate authentication request) 메시지와, 인증 시작 응답(initiate authentication response) 메시지와, 단말 인증 요청(authenticate client request) 메시지와, 단말 인증 응답(authenticate client response) 메시지와, 프로파일 패키지 요청(get bound profile package request) 메시지와, 프로파일 패키지 응답(get bound profile package response) 메시지와, 서버 인증 요청(authenticate server request) 메시지와, 서버 인증 응답(authenticate server response) 메시지와, 다운로드 준비 요청(prepare download request) 메시지와, 다운로드 준비 응답(prepare download response) 메시지와, 프로파일 패키지 설치 요청(load bound profile package request) 메시지와, 프로파일 패키지 설치 응답(load bound profile package response) 메시지와, 원격관리 패키지 설치 요청(load RPM package request) 메시지와, 원격관리 패키지 설치 응답(load RPM package response) 메시지 중 적어도 하나 이상을 사용할 수 있다.

다양한 실시 예에 따른 단말(400), 모뎀(410), eSIM(420), LPA(430), 사업자 앱(440), 프로파일 서버(450), 사업자 서버(460), 사용자(미도시)의 상세한 동작 및 메시지 교환 절차는 후술할 도면들을 참조하여 자세히 살펴보기로 한다.

도 16은 본 개시의 일 실시 예에 따른 단말에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 단말이 단말에 설치된 사업자 애플리케이션 및 사업자 서버를 통해 활성화 코드를 수신하고, 프로파일 서버로부터 이벤트를 다운로드 받아 처리하는 절차를 도시하는 도면이다.

도 16에서 단말(400), 제1 모뎀(410), 제2 모뎀(415), 제1 eUICC(420), 제2 eUICC(425), LPA(430), 사업자 앱(440), 사업자 서버(450), 프로파일 서버(460)에 대한 자세한 구성과 설명은 도 15를 참조하기로 한다. 또한, 도 16에는 편의상 제1 모뎀(410)과 제1 eUICC(420)가 하나의 구성요소이고, 제2 모뎀(415)과 제2 eUICC(425)가 하나의 구성요소인 것과 같이 도시되어 있으나, 단말의 구현에 따라 도 4와 같이 제1 모뎀(410)과 제1 eUICC(420)는 서로 다른 구성요소로 단말(400)에 포함될 수도 있고, 제2 모뎀(415)과 제2 eUICC(425)는 서로 다른 구성요소로 단말(400)에 포함될 수도 있다.

도 16를 참조하면, 5001 단계에서 LPA(430)와 사업자 앱(440)은 LPA API 절차를 시작할 수 있다. 또한, 5001 단계는 사업자 서버(450)와의 연동을 더 포함할 수도 있다. 또한, 5001 단계는 LPA(430)에 의해 시작되거나, 사업자 앱(440)에 의해 시작되거나, 단말(400)이 특정 조건(예를 들면, 단말이 최초 부팅되거나 재부팅 되는 경우, 단말이 로밍(roaming) 상태임을 감지한 경우 등)을 만족했을 때 단말(400)에 설치된 운영체제(operating system, OS) 및 기타 구성요소에 의해 시작되거나, 사용자(미도시)가 LPA(430)에 요청해 시작되거나, 사용자(미도시)가 사업자 앱(440)에 요청해 시작되거나, 사업자 서버(450)가 사업자 앱(440)에 요청해 시작될 수도 있다. 5001 단계가 사용자의 입력에 의해 시작되거나, 다른 조건에 의해 시작되었더라도 사용자의 추가 입력이 필요한 경우, 5001 단계는 사용자(미도시)의 입력을 포함할 수도 있다. 5001 단계는, 예를 들면, LPA API 시작 요청(initiate LPA API request) 메시지를 이용할 수 있다.

5003 단계에서 LPA(430)는 제1 모뎀(410)과 제1 eUICC(420)를 통해 제1 단말 정보(device info 1)와 제1 eUICC 정보(eUICC info 1)를 획득할 수 있다. 제1 단말 정보(device info 1)는, 적어도 제1 모뎀(410)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제1 eUICC 정보(eUICC info)는, 적어도 제1 eUICC(420)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제1 eUICC(420)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 5003 단계는, eUICC 정보 요청(get eUICC info request) 메시지와, eUICC 정보 응답(get eUICC info response) 메시지 중 적어도 하나 이상을 이용할 수 있다. 또한, 5003 단계는, 단말(400)의 구현에 따라 제1 모뎀(410)과 제1 eUICC(420)가 별도의 구성 요소로 포함된 경우, 한 번 이상의 요청 메시지 및 응답 메시지 교환을 포함할 수 있으며, 단말(400)의 동작에 따라 제1 단말 정보(device info 1)와 제1 eUICC 정보(eUICC info 1)의 일부 또는 전체가 LPA(430)에 이미 알려져 있는 경우, 5003 단계의 일부 또는 전체는 생략될 수도 있다.

5005 단계에서 LPA(430)는 적어도 상기 제1 단말 정보(device info 1)와 제1 eUICC 정보(eUICC info 1)를 포함하고, 제1 eUICC의 색인번호(index 1)를 더 포함하는 제1 LPA API 정보(LPA API info 1)를 구성할 수 있다. 제1 eUICC의 색인번호는 다음과 같은 정보를 활용할 수 있으나 반드시 다음의 목록에 제한되지는 않는다.

- 제1 eUICC(420)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)

- 제1 eUICC(420)와 제1 모뎀(410)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)

- 제1 eUICC(420)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)

5007 단계에서 LPA(430)는 제2 모뎀(415)과 제2 eUICC(425)를 통해 제2 단말 정보(device info 2)와 제2 eUICC 정보(eUICC info 2)를 획득할 수 있다. 제2 단말 정보(device info 2)는, 적어도 제2 모뎀(415)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제2 eUICC 정보(eUICC info)는, 적어도 제2 eUICC(425)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제2 eUICC(425)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 5007 단계는, eUICC 정보 요청(get eUICC info request) 메시지와, eUICC 정보 응답(get eUICC info response) 메시지 중 적어도 하나 이상을 이용할 수 있다. 또한, 5007 단계는, 단말(400)의 구현에 따라 제2 모뎀(415)과 제2 eUICC(425)가 별도의 구성 요소로 포함된 경우, 한 번 이상의 요청 메시지 및 응답 메시지 교환을 포함할 수 있으며, 단말(400)의 동작에 따라 제2 단말 정보(device info 2)와 제2 eUICC 정보(eUICC info 2)의 일부 또는 전체가 LPA(430)에 이미 알려져 있는 경우, 5007 단계의 일부 또는 전체는 생략될 수도 있다.

5009 단계에서 LPA(430)는 적어도 제2 단말 정보(device info 2)와 제2 eUICC 정보(eUICC info 2)를 포함하고, 제2 eUICC의 색인번호(index 2)를 더 포함하는 제2 LPA API 정보(LPA API info 2)를 구성할 수 있다. 제2 eUICC의 색인번호는 다음과 같은 정보를 활용할 수 있으나 반드시 다음의 목록에 제한되지는 않는다.

- 제2 eUICC(420)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)

- 제2 eUICC(420)와 제2 모뎀(410)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)

- 제2 eUICC(420)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)

5011 단계에서 LPA(430)와 사업자 앱(440)과 사업자 서버(450)는 제1 LPA API 정보와 제2 LPA API 정보 중 적어도 하나 이상을 선택할 수 있다. 5011 단계에 대한 보다 상세한 설명은 도 17의 설명을 참조하기로 한다. 또한, 도 16에는 도시되지 않았으나, 5011 단계는 사업자 앱(440)의 정보(예를 들면, 앱의 버전 정보)나 사용자에 관련된 정보(예를 들면, 사용자의 이름, 주소, 연락처 등 개인정보와 결제정보)를 더 포함할 수도 있다. 5011 단계는, 예를 들면, LPA API 시작 응답(initiate LPA API response) 메시지를 이용할 수 있다.

5013 단계에서 사업자 서버(450)는 선택된 하나 이상의 LPA API 정보를 이용하여 프로파일 서버(460)와 함께 이벤트(Event)를 준비하고, 해당 이벤트에 대응하는 활성화 코드(activation code)를 더 생성할 수 있다. 5013 단계는, 예를 들면, 다운로드 주문 요청(download order request) 메시지와, 다운로드 주문 응답(download order response) 메시지와, 확정 주문 요청(confirm order request) 메시지와, 확정 주문 응답(confirm order response) 메시지와, 배포 주문 요청(release order request) 메시지와, 배포 주문 응답(release order response) 메시지와, 원격관리 주문 요청(RPM order request) 메시지와, 원격관리 주문 응답(RPM order response) 메시지 중 적어도 하나 이상을 사용할 수 있다. 5013 단계의 일부 또는 전체는 5013 단계 이전에 수행될 수도 있다. 예를 들어, 5013 단계 이전에 하나 이상의 이벤트를 사전에 준비하고, 5013 단계에서 LPA API 정보에 기반하여 이벤트를 선택하고 해당 이벤트에 대응하는 활성화 코드(activation code)를 생성할 수도 있다. 활성화 코드를 생성하는 절차는 하나 이상의 프로파일 서버를 더 포함하거나 사용자(미도시)를 더 포함하는 절차일 수도 있다.

5015 단계에서 사업자 서버(450)는 사업자 앱(440)으로 상기 활성화 코드(activation code)를 전달하고, 추가적으로 해당 활성화 코드를 처리해야 할 대상이 되는 eUICC의 색인번호를 하나 이상 더 공지(notify)할 수 있다.

5017 단계에서 사업자 앱(440)은 LPA(430)로, 활성화 코드(activation code)와, 활성화 코드를 처리해야 할 대상이 되는 eUICC의 색인번호를 하나 이상 전달할 수 있다. 5017 단계는, 예를 들면, LPA API 실행 요청(execute LPA API request) 메시지와, 활성화 코드 실행 요청(execute activation code request) 메시지와, 명령 코드 실행 요청(execute command code response) 메시지와, 활성화 코드 입력 요청(push activation code request) 메시지와, 명령 코드 입력 요청(push command code request) 메시지 중 적어도 하나 이상을 사용할 수 있다.

5019 단계에서 LPA(430)는 eUICC 색인번호를 참조하여 활성화 코드를 처리할 대상이 되는 eUICC를 식별하고 선택할 수 있다.

5021 단계에서 단말(400), 사업자 서버(450), 프로파일 서버(460)는 활성화 코드를 처리할 대상이 되는 eUICC에 대해, 활성화 코드에 대응하는 이벤트를 처리할 수 있다. 또한, 단말(400)은 이벤트 처리 이후 이벤트 처리 결과를 이용하여 네트워크에 더 접속할 수 있다. 이벤트를 처리하는 동작은, 프로파일 다운로드(profile download)를 수행하거나, 원격 프로파일 관리(remote profile management)를 수행하거나, 기타 프로파일 또는 eUICC를 제어하거나 처리하는 동작일 수 있다. 5021 단계는, 예를 들면, LPA API 실행 응답(execute LPA API response) 메시지와, 활성화 코드 실행 응답(execute activation code response) 메시지와, 명령 코드 실행 응답(execute command code response) 메시지와, 활성화 코드 입력 응답(push activation code response) 메시지와, 명령 코드 입력 응답(push command code response) 메시지와, 인증 시작 요청(initiate authentication request) 메시지와, 인증 시작 응답(initiate authentication response) 메시지와, 단말 인증 요청(authenticate client request) 메시지와, 단말 인증 응답(authenticate client response) 메시지와, 프로파일 패키지 요청(get bound profile package request) 메시지와, 프로파일 패키지 응답(get bound profile package response) 메시지와, 서버 인증 요청(authenticate server request) 메시지와, 서버 인증 응답(authenticate server response) 메시지와, 다운로드 준비 요청(prepare download request) 메시지와, 다운로드 준비 응답(prepare download response) 메시지와, 프로파일 패키지 설치 요청(load bound profile package request) 메시지와, 프로파일 패키지 설치 응답(load bound profile package response) 메시지와, 원격관리 패키지 설치 요청(load RPM package request) 메시지와, 원격관리 패키지 설치 응답(load RPM package response) 메시지와, 공지 처리 요청(handle notification request) 메시지 중 적어도 하나 이상을 사용할 수 있다.

도 16을 참조하면, 단말(400)에 복수의 모뎀(410, 415) 또는 복수의 eUICC(420, 425)가 장착된 경우, 단말(400)은 복수의 LPA API 정보(LPA API info)를 생성할 때, 각 LPA API 정보에 대응하는 eUICC의 색인번호를 LPA API 정보에 포함시킬 수 있다. 이를 통해 단말(400)과 사업자 서버(450)는 활성화 코드(activation code)에 대응하는 이벤트(event)의 처리 대상이 되는 eUICC를 식별하고, 이벤트를 효율적으로 처리할 수 있다. 또한, 단말(400)에 복수의 모뎀(410, 415) 또는 복수의 eUICC(420, 425)가 장착된 경우, 사업자 서버(450)가 활성화 코드를 단말(400)에 회신할 때 eUICC 색인번호를 지정하지 않거나 둘 이상을 지정할 때, 단말(400)은 단말(400)에 장착된 eUICC 중 이벤트의 처리 대상이 되는 eUICC를 자율적으로 선택하여, 이벤트를 효율적으로 처리할 수 있다.

도 17은 본 개시의 일 실시 예에 따른 단말에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 사용자 및 단말과 사업자 서버가 활성화 코드를 처리할 eUICC를 선택하는 절차의 예를 도시하는 도면이다.

도 17에서 단말(400), 제1 모뎀(410), 제2 모뎀(415), 제1 eUICC(420), 제2 eUICC(425), LPA(430), 사업자 앱(440), 사업자 서버(450), 프로파일 서버(460)에 대한 자세한 구성과 설명은 도 15를 참조하기로 한다. 단말(400)에는 제3 모뎀(419) 및 제3 eUICC(429)가 더 설치되어 있을 수 있다. 제1 모뎀(410), 제2 모뎀(415), 제3 모뎀(419)과 제1 eUICC(420), 제2 eUICC(425), 제3 eUICC(429)의 연결 및 구성이 도 15의 설명과 같이 동적으로 변경될 수 있음은 물론이다. 또한, 도 17에는 편의상 제1 모뎀(410)과 제1 eUICC(420)가 하나의 구성요소이고, 제2 모뎀(415)과 제2 eUICC(425)가 하나의 구성요소이고, 제3 모뎀(419)와 제3 eUICC(429)가 하나의 구성요소인 것과 같이 도시되어 있으나, 단말의 구현에 따라 도 15와 같이 제1 모뎀(410)과 제1 eUICC(420)는 서로 다른 구성요소로 단말(400)에 포함될 수도 있고, 제2 모뎀(415)과 제2 eUICC(425)는 서로 다른 구성요소로 단말(400)에 포함될 수도 있고, 제3 모뎀(419)와 제3 eUICC(429)는 서로 다른 구성요소로 단말(400)에 포함될 수도 있다.

도 17을 참조하면, 6001 단계에서 LPA(430)는 제1 모뎀(410) 및 제1 eUICC(420)로부터 제1 LPA API 정보(LPA API Info 1)를 준비하고, 제1 LPA API 정보에 제1 eUICC의 색인번호(index 1)를 더 할당하고, 제2 모뎀(415) 및 제2 eUICC(425)로부터 제2 LPA API 정보(LPA API Info 2)를 준비하고, 제2 LPA API 정보에 제2 eUICC의 색인번호(index 2)를 더 할당하고, 제3 모뎀(419) 및 제3 eUICC(429)로부터 제3 LPA API 정보(LPA API Info 3)를 준비하고, 제3 LPA API 정보에 제3 eUICC의 색인번호(index 3)를 더 할당할 수 있다. 6001 단계는, 예를 들면, eUICC 정보 요청(get eUICC info request) 메시지와, eUICC 정보 응답(get eUICC info response) 메시지와, eUICC 식별자 요청(get eUICC ID request) 메시지와, eUICC 식별자 응답(get eUICC ID response) 중 적어도 하나 이상을 이용할 수 있다. 6001 단계는 도 16의 5003 단계부터 5009 단계까지의 동작에 대응할 수 있다. 6001 단계에서 준비된 제1 LPA API 정보와 제2 LPA API 정보와 제3 LPA API 정보는, 예를 들면, LPA API 정보 목록(list of LPA API info)로 표현될 수 있다.

제1 LPA API 정보(LPA API info 1)는, 적어도 단말(400)과 제1 모뎀(410)에 대한 정보와, 제1 eUICC(420)에 대한 정보와, 제1 eUICC(420)의 색인번호(index)를 포함할 수 있다. 단말(400)과 제1 모뎀(410)에 대한 정보는, 예를 들면, 제1 단말 정보(device info 1 또는 deficeInfo1)로 표현될 수 있다. 제1 eUICC(420)에 대한 정보는, 예를 들면, 제1 eUICC 정보(eUICC info 1 또는 euiccInfo1)로 표현될 수 있다. 제1 단말 정보(device info 1)는, 적어도 제1 모뎀(410)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제1 eUICC 정보(euicc info 1)는, 적어도 제1 eUICC(420)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제1 eUICC(420)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 제1 eUICC(420)의 색인번호(index)는, 예를 들면, 제1 eUICC(420)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)를 이용하거나, 제1 eUICC(420)와 제1 모뎀(410)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)를 이용하거나, 제1 eUICC(420)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)를 이용할 수 있다.

제2 LPA API 정보(LPA API info 2)는, 적어도 단말(400)과 제2 모뎀(415)에 대한 정보와, 제2 eUICC(425)에 대한 정보와, 제2 eUICC(425)의 색인번호(index)를 포함할 수 있다. 단말(400)과 제2 모뎀(415)에 대한 정보는, 예를 들면, 제2 단말 정보(device info 2 또는 deficeInfo2)로 표현될 수 있다. 제2 eUICC(425)에 대한 정보는, 예를 들면, 제2 eUICC 정보(eUICC info 2 또는 euiccInfo2)로 표현될 수 있다. 제2 단말 정보(device info 2)는, 적어도 제2 모뎀(415)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제2 eUICC 정보(euicc info 2)는, 적어도 제2 eUICC(425)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제2 eUICC(425)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 제2 eUICC(425)의 색인번호(index)는, 예를 들면, 제2 eUICC(425)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)를 이용하거나, 제2 eUICC(425)와 제2 모뎀(415)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)를 이용하거나, 제2 eUICC(425)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)를 이용할 수 있다.

제3 LPA API 정보(LPA API info 3)는, 적어도 단말(400)과 제3 모뎀(419)에 대한 정보와, 제3 eUICC(429)에 대한 정보와, 제3 eUICC(429)의 색인번호(index)를 포함할 수 있다. 단말(400)과 제3 모뎀(419)에 대한 정보는, 예를 들면, 제3 단말 정보(device info 3 또는 deficeInfo3)로 표현될 수 있다. 제3 eUICC(429)에 대한 정보는, 예를 들면, 제3 eUICC 정보(eUICC info 3 또는 euiccInfo3)로 표현될 수 있다. 제3 단말 정보(device info 3)는, 적어도 제3 모뎀(419)이 지원하는 무선접속기술(radio access technology 또는 RAT)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전정보(version type 또는 versionType)와, LPA(430)가 지원하는 eSIM 기능(LPA RSP capability 또는 lpaRspCapability)을 포함할 수 있다. 제3 eUICC 정보(euicc info 3)는, 적어도 제3 eUICC(429)의 현재 총 가용 메모리 용량(current total available memory 또는 external card resource 또는 extCardResource)과, 제3 eUICC(429)가 지원하는 eSIM 기능(eUICC RSP capability 또는 euiccRspCapability)을 포함할 수 있다. 제3 eUICC(429)의 색인번호(index)는, 예를 들면, 제3 eUICC(429)의 eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)를 이용하거나, 제3 eUICC(429)와 제3 모뎀(419)을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)를 이용하거나, 제3 eUICC(429)에 대해 LPA(430)가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)를 이용할 수 있다.

6003 단계에서 LPA(430)는 LPA API 정보 목록에서 적어도 하나 이상의 LPA API 정보를 선택할 수 있다. LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 기준의 예는 다음과 같은 방법을 하나 이상 복합적으로 적용할 수 있으나, 선택하는 기준의 예가 반드시 하기의 목록으로 제한되지는 않는다:

- eUICC의 잔여 가용 메모리 양을 참조(예를 들어, 잔여 가용 메모리가 가장 많거나, 가장 적은, 설치될 프로파일의 크기에 가장 가까운)하여, 적절한 eUICC가 포함된 LPA API 정보를 선택

- eUICC에 설치된 프로파일의 개수를 참조(예를 들어, 설치된 프로파일의 개수가 가장 적거나, 가장 많은)하여, 적절한 eUICC가 포함된 LPA API 정보를 선택

- eUICC가 지원하는 eSIM 기능을 참조(예를 들어, 하나 이상 임의의 eSIM 기능을 지원하거나, 지원하지 않는)하여, 적절한 eUICC가 포함된 LPA API 정보를 선택

- 모뎀이 지원 가능한 무선접속기술의 목록을 참조(예를 들어, 특정 통신서비스에 적합한 무선접속기술을 지원하는)하여, 적절한 모뎀이 포함된 LPA API 정보를 선택

- LPA가 지원하는 eSIM 기능을 참조(예를 들어, 하나 이상 임의의 eSIM 기능을 지원하거나, 지원하지 않는)하여, 적절한 LPA가 포함된 LPA API 정보를 선택

6005 단계에서 LPA(430)는 사용자(미도시)에게 LPA API 정보 목록의 일부 또는 전체를 출력하고, 사용자로부터 적어도 하나 이상의 LPA API 정보를 선택 받을 수 있다. LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 기준의 예는 6003 단계의 예를 참조하기로 한다.

6007 단계에서 LPA(430)는 LPA API 정보 목록을 사업자 앱(440)에 전달할 수 있다. 6007 단계에서 전달되는 LPA API 정보 목록은, 6001 단계에서 준비된 LPA API 정보 목록 중, 6003 단계 내지 6005 단계를 통해 적어도 하나 이상 선택된 LPA API 정보가 될 수 있다. 만일, 6003 단계 내지 6005 단계를 통해 하나 이상의 LPA API 정보를 선택할 수 없는 경우, 6007 단계에서 LPA(430)는 LPA API 정보를 선택할 수 없음을 나타내는 오류코드(error code)를 사업자 앱(400)에 전달하고 동작을 종료할 수 있다. 6007 단계는, 예를 들면, LPA API 시작 응답(initiate LPA API response) 메시지를 이용할 수 있다.

6009 단계에서 사업자 앱(440)은 LPA API 정보 목록에서 적어도 하나 이상의 LPA API 정보를 선택할 수 있다. LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 기준의 예는 6003 단계의 예를 참조하기로 한다.

6011 단계에서 사업자 앱(440)은 사용자(미도시)에게 LPA API 정보 목록의 일부 또는 전체를 출력하고, 사용자로부터 적어도 하나 이상의 LPA API 정보를 선택 받을 수 있다. LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 기준의 예는 6003 단계의 예를 참조하기로 한다.

6013 단계에서 사업자 앱(440)은 LPA API 정보 목록을 사업자 서버(450)에 전달할 수 있다. 6013 단계에서 전달되는 LPA API 정보 목록은, 6007 단계에서 수신한 LPA API 정보 목록 중, 6009 단계 내지 6011 단계를 통해 적어도 하나 이상 선택된 LPA API 정보가 될 수 있다. 만일 6009 단계 내지 6011 단계를 통해 하나 이상의 LPA API 정보를 선택할 수 없는 경우, 6013 단계에서 사업자 앱(440)은 LPA API 정보를 선택할 수 없음을 나타내는 오류코드(error code)를 사업자 서버(450)에 전달하고 동작을 종료할 수 있다.

6015 단계에서 사업자 서버(450)는 LPA API 정보 목록에서 적어도 하나 이상의 LPA API 정보를 선택할 수 있다. LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 기준의 예는 6003 단계의 예를 참조하기로 한다.

6017 단계에서 사업자 서버(450)는 하나 이상의 LPA API 정보를 이용하여 프로파일 서버(460)와 함께 이벤트(Event)를 준비하고, 해당 이벤트에 대응하는 활성화 코드(activation code)를 더 생성할 수 있다. 6017 단계는, 예를 들면, 다운로드 주문 요청(download order request) 메시지와, 다운로드 주문 응답(download order response) 메시지와, 확정 주문 요청(confirm order request) 메시지와, 확정 주문 응답(confirm order response) 메시지와, 배포 주문 요청(release order request) 메시지와, 배포 주문 응답(release order response) 메시지와, 원격관리 주문 요청(RPM order request) 메시지와, 원격관리 주문 응답(RPM order response) 메시지 중 적어도 하나 이상을 사용할 수 있다. 6017 단계의 일부 또는 전체는 6017 단계 이전에 수행될 수도 있다. 예를 들어, 6017 단계 이전에 하나 이상의 이벤트를 사전에 준비하고, 6017 단계에서 LPA API 정보에 기반하여 이벤트를 선택하고 해당 이벤트에 대응하는 활성화 코드(activation code)를 생성할 수도 있다. 활성화 코드를 생성하는 절차는 하나 이상의 프로파일 서버를 더 포함하거나 사용자(미도시)를 더 포함하는 절차일 수도 있다. 6017 단계는 도 16의 5013 단계에 대응할 수 있다.

6019 단계에서 사업자 서버(450)는 사업자 앱(440)으로 활성화 코드(activation code)를 전달하고, 추가적으로 해당 활성화 코드를 처리해야 할 대상이 되는 eUICC의 색인번호를 하나 이상 더 공지할 수 있다. 만일, 6015 단계에서 하나 이상의 LPA API 정보를 선택할 수 없거나, 6017 단계에서 이벤트 내지 활성화 코드를 생성할 수 없는 경우, 6019 단계에서 사업자 서버(450)는 사업자 앱(440)에 LPA API 절차를 완료할 수 없음을 공지하고 동작을 종료할 수 있다. 6019 단계는 도 16의 5015 단계에 대응할 수 있다.

6021 단계에서 사업자 앱(440)은 eUICC 색인번호를 참조하여 활성화 코드를 처리할 대상이 되는 eUICC를 식별하고 선택할 수 있다. 만일 6019 단계에서 사업자 서버(450)가 활성화 코드만 공지하고 어떠한 eUICC 색인번호도 공지하지 않은 경우, 사업자 앱(440)은 6103 단계에서 사업자 서버(450)로 전달된 LPA API 정보 목록 중 하나 이상의 LPA API 정보를 선택할 수 있다. 만일 6019 단계에서 사업자 서버(450)가 활성화 코드와 함께 복수의 eUICC 색인번호를 공지한 경우, 사업자 앱(440)은 6019 단계에서 공지된 eUICC 색인번호에 대응하는 LPA API 정보로 구성된 LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택할 수 있다. 6021 단계에서, LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 동작은, 6009 단계 내지 6011 단계를 적어도 한 번 이상 반복하는 동작일 수 있다. 만일 6021 동작에서 하나 이상의 LPA API 정보를 선택할 수 없는 경우, 사업자 서버(450)는 동작을 종료할 수 있다

6023 단계에서 사업자 앱(440)은 LPA(430)로 활성화 코드(activation code)를 전달하고, 추가적으로 해당 활성화 코드를 처리해야 할 대상이 되는 eUICC의 색인번호를 하나 이상 더 공지할 수 있다. 6023 단계는, 예를 들면, LPA API 실행 요청(execute LPA API request) 메시지와, 활성화 코드 실행 요청(execute activation code request) 메시지와, 명령 코드 실행 요청(execute command code response) 메시지와, 활성화 코드 입력 요청(push activation code request) 메시지와, 명령 코드 입력 요청(push command code request) 메시지 중 적어도 하나 이상을 사용할 수 있다. 6023 단계는 도 16의 5017 단계에 대응할 수 있다.

6025 단계에서 LPA(430)는 eUICC 색인번호를 참조하여 활성화 코드를 처리할 대상이 되는 eUICC를 식별하고 선택할 수 있다. 만일 6023 단계에서 사업자 앱(440)이 활성화 코드만 공지하고 어떠한 eUICC 색인번호도 공지하지 않은 경우, LPA(430)는 6007 단계에서 사업자 앱(440)으로 전달된 LPA API 정보 목록 중 하나 이상의 LPA API 정보를 선택할 수 있다. 만일, 6023 단계에서 사업자 앱(440)이 활성화 코드와 함께 복수의 eUICC 색인번호를 공지한 경우, LPA(430)는 6023 단계에서 공지된 eUICC 색인번호에 대응하는 LPA API 정보로 구성된 LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택할 수 있다. 6025 단계에서, LPA API 정보 목록에서 하나 이상의 LPA API 정보를 선택하는 동작은, 6003 단계 내지 6005 단계를 적어도 한 번 이상 반복하는 동작일 수 있다. 만일 6025 단계에서 하나 이상의 LPA API 정보를 선택할 수 없는 경우, LPA(430)는 사업자 앱(440)으로 활성화 코드를 처리할 수 없음을 나타내는 오류코드(error code)를 회신하고 동작을 종료할 수 있다. 6025 단계는 도 16의 5019 단계에 대응할 수 있다.

이후, 단말(400)은 도 16의 5021 단계와 같이 이벤트를 처리할 수 있다.

도 17의 절차에서 LPA API 정보 목록 중 하나 이상의 LPA API 정보를 선택하는 6003 동작, 6005 동작, 6009 동작, 6011 동작, 6015 동작, 6021 동작, 6025 동작은 적어도 한 번 이상 복합적으로 또는 선택적으로 수행될 수도 있음에 유의해야 한다. 예를 들어, 6003 단계에서 LPA(430)가 제1 LPA API 정보와 제2 LPA API 정보와 제3 LPA API 정보를 선택하고, 6011 단계에서 사업자 앱(440)이 사용자에게 제1 LPA API 정보와 제2 LPA API 정보와 제3 LPA API 정보의 일부 또는 전체를 출력해 제1 LPA API 정보와 제2 LPA API 정보를 선택 받고, 6015 단계에서 사업자 서버(450)가 제1 LPA API 정보를 선택하고, 6021 단계에서 사업자 앱(440)이 제1 eUICC 색인번호를 식별하고, 6025 단계에서 LPA(430)가 제1 eUICC 색인번호를 식별해 제1 eUICC를 선택하는 것도 가능하다. 또 다른 예로, 6003 단계에서 LPA(430)가 제1 LPA API 정보와 제2 LPA API 정보와 제3 LPA API 정보를 선택하고, 6009 단계에서 사업자 앱(440)이 제1 LPA API 정보와 제2 LPA API 정보와 제3 LPA API 정보를 선택하고, 6015 단계에서 사업자 서버(450)가 제2 LPA API 정보와 제3 LPA API 정보를 선택하고, 6021 단계에서 사업자 앱(440)이 제2 eUICC 색인번호와 제3 eUICC 색인번호를 식별하고, 6025 단계에서 LPA(430)가 제2 eUICC 색인번호와 제3 eUICC 색인번호에 기반하여 사용자에게 제2 LPA API 정보와 제3 LPA API 정보의 일부 또는 전체를 출력해 제2 LPA API 정보를 선택 받는 것도 가능하다.

도 17을 참조하면, 단말(400)에 복수의 모뎀 또는 복수의 eUICC가 장착된 경우, 단말(400)과 사업자 서버(450)는 하나 이상의 LPA API 정보를 포함하는 LPA API 정보 목록 중에서, 단말(400)이나 모뎀(410, 415, 419) 내지 eUICC(420, 425, 429)의 정보를 참조하여, 이벤트의 처리에 적절한 eUICC를 효율적으로 선택하고 이벤트를 처리할 수 있다.

도 18은 본 개시의 일 실시 예에 따른 단말 동작 절차의 예를 도시하는 순서도이다.

7001 단계에서 단말은 동작을 시작할 수 있다.

7003 단계에서 단말은 LPA API 절차를 시작(trigger)할 수 있다. 7003 단계는 단말 외부의 서버로부터 요청을 받아 시작될 수도 있고, 사용자로부터 입력 받아 시작될 수도 있고, 외부의 입력 없이 단말 스스로 시작(예를 들면, 단말이 최초 부팅되거나 재부팅 되는 경우, 단말이 로밍(roaming) 상태임을 감지한 경우 등)할 수도 있다.

7005 단계에서 단말은 단말에 장착된 eUICC 중 하나를 선택할 수 있다. 또한, 단말은 해당 eUICC에 대해 색인번호를 할당할 수 있다. eUICC 색인번호는 다음과 같은 정보를 활용할 수 있으나 반드시 다음의 목록에 한정되지는 않는다.

- eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID)

- eUICC와 모뎀을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID)

- eUICC에 대해 단말 내지 LPA가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID)

7007 단계에서 단말은 선택된 eUICC에 대해 LPA API 정보를 생성할 수 있다. LPA API 정보는 적어도 다음 정보를 포함할 수 있다.

- 단말 정보(device info): 모뎀이 지원하는 무선접속기술(radio access technology)의 목록 및 각 무선접속기술이 지원하는 표준규격의 버전 정보(version type), 단말 내 LPA가 지원하는 eSIM 기능(LPA RSP capability)의 목록

- eUICC 정보(eUICC info): eUICC의 현재 총 가용 메모리 용량(current total available memory 또는 extCardResource), eUICC가 지원하는 eSIM 기능(eUICC RSP capability)의 목록

7009 단계에서 단말은 더 선택할 수 있는 다음 eUICC가 단말에 장착되어 있는지 판단할 수 있다. 만일 더 선택할 수 있는 다음 eUICC가 있는 경우, 단말은 7005 단계를 수행하여 다음 eUICC를 선택할 수 있다. 만일 더 선택할 수 있는 다음 eUICC가 없는 경우(예를 들어, 단말에 단 하나의 eUICC가 장착되어 있거나, 모든 eUICC에 대해 이미 7005 단계 내지 7007 단계를 수행한 경우), 단말은 7011 단계를 수행할 수 있다.

7011 단계에서 단말은 적어도 7005 단계부터 7009 단계까지를 1회 이상 반복하여 생성된 LPA API 정보들을 포함하는 LPA API 정보 목록을 사업자 서버로 전달할 수 있다.

7013 단계에서 단말은 사업자 서버로부터 적어도 활성화 코드를 수신하고, LPA API 정보 목록에서 선택된 eUICC 색인번호를 더 수신할 수 있다.

7015 단계에서 단말은 활성화 코드와 함께 사업자 서버가 eUICC 색인번호를 적어도 하나 이상 송신하였는지 판단할 수 있다. 만일 사업자 서버가 eUICC 색인번호를 하나만 송신한 경우, 단말은 7017 동작을 수행할 수 있다. 만일 사업자 서버가 eUICC 색인번호를 송신하지 않았거나, 사업자 서버가 eUICC 색인번호를 둘 이상 송신한 경우, 단말은 7019 단계을 수행할 수 있다.

7017 단계에서 단말은 eUICC 색인번호를 참조하여 eUICC를 선택할 수 있다.

7019 단계에서 단말은 eUICC 색인번호의 개수를 참조하여 eUICC를 선택할 수 있다. 보다 구체적으로, 만일 사업자 서버가 eUICC 색인번호를 송신하지 않은 경우, 단말은 단말에 장착된 eUICC 중 임의의 eUICC를 선택할 수 있다. 만일 사업자 서버가 eUICC 색인번호를 둘 이상 송신한 경우, 단말은 사업자 서버가 송신한 eUICC 색인번호 중 하나에 대응하는 eUICC를 선택할 수 있다. 7019 단계에서 단말이 eUICC를 선택하는 기준은 다음과 같은 방법을 하나 이상 복합적으로 적용할 수 있으나, 선택하는 기준의 예가 반드시 하기의 목록으로 제한되지는 않는다.

- eUICC의 잔여 가용 메모리 양을 참조(예를 들어, 잔여 가용 메모리가 가장 많거나, 가장 적은, 설치될 프로파일의 크기에 가장 가까운)하여 적절한 eUICC를 선택

- eUICC에 설치된 프로파일의 개수를 참조(예를 들어, 설치된 프로파일의 개수가 가장 적거나, 가장 많은)하여, 적절한 eUICC를 선택

- eUICC가 지원하는 eSIM 기능을 참조(예를 들어, 하나 이상 임의의 eSIM 기능을 지원하거나, 지원하지 않는)하여, 적절한 eUICC를 선택

- 모뎀이 지원 가능한 무선접속기술의 목록을 참조(예를 들어, 특정 통신서비스에 적합한 무선접속기술을 지원하는)하여, 적절한 모뎀이 연결된 eUICC를 선택

- LPA가 지원하는 eSIM 기능을 참조(예를 들어, 하나 이상 임의의 eSIM 기능을 지원하거나, 지원하지 않는)하여, 적절한 LPA가 제어하는 eUICC를 선택

7021 단계에서 단말은 선택된 eUICC에 대해 수신한 활성화 코드를 처리할 수 있다.

7023 단계에서 단말은 동작을 종료하고 추가적인 LPA API 절차의 시작을 대기할 수 있다.

도 19는 본 개시의 일 실시 예에 따른 단말(400)의 구성요소를 도시하는 블록도이다.

도 19 에서 도시된 바와 같이, 단말(400)은 송수신부(810) 및 적어도 하나 이상의 프로세서(820)를 포함할 수 있다. 또한, 단말은 UICC(830)를 포함할 수 있다. 예를 들면, UICC(830)는 단말에 삽입될 수 있고, 단말에 내장된 eUICC 일 수도 있다.

다양한 실시 예에 따른 송수신부(810)는 사업자 서버(450) 또는 프로파일 서버(460)와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다.

예를 들면, 송수신부(810)는 사업자 서버(450)로부터 활성화 코드 절차 시작 요청 메시지를 수신하고, 사업자 서버(450)로 LPA API 정보 목록을 송신하고, 사업자 서버(450)로부터 적어도 활성화 코드를 수신하고, 사업자 서버(450)로부터 eUICC 색인번호를 선택적으로 더 수신하고, 프로파일 서버(460)로 이벤트를 요청하는 메시지를 송신하고, 프로파일 서버(460)로부터 이벤트의 일부 또는 전체를 수신할 수 있다.

또한, 다양한 실시 예에서, 송수신부(810)는 모뎀을 포함할 수 있다.

한편, 적어도 하나 이상의 프로세서(820)는 단말(400)을 전반적으로 제어하기 위한 구성요소이다. 프로세서(820)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 단말(400)의 전반적인 동작을 제어할 수 있다. 적어도 하나 이상의 프로세서(820)는 제어부로 명명할 수 있다.

예를 들면, 다양한 실시 예에 따른 적어도 하나 이상의 프로세서(820)는 사업자 서버(450)로부터 활성화 코드 절차 시작 요청 메시지를 수신하고, 단말에 장착된 하나 이상의 eUICC 그리고/또는 하나 이상의 모뎀의 정보를 수집하고, LPA API 정보 목록을 생성하고, 필요한 경우 LPA API 정보 목록 중 적어도 하나 이상의 LPA API 정보를 선별하고, 사업자 서버(450)로 LPA API 정보 목록을 송신하고, 사업자 서버(450)로부터 적어도 활성화 코드를 수신하고, 사업자 서버(450)가 적어도 하나 이상의 eUICC 색인번호를 송신하였는지 여부를 판단하고, 사업자 서버(450)가 송신한 eUICC 색인번호를 참조하여 eUICC를 선택하고, 활성화 코드를 참조하여 이벤트 요청 메시지를 생성하고, 프로파일 서버(460)로 이벤트 요청 메시지를 송신하고, 프로파일 서버(460)로부터 이벤트의 일부 또는 전체를 수신하고, 이벤트를 처리하도록 단말을 제어할 수 있다.

다양한 실시 예에 따른 UICC(830)는 프로파일을 다운로드하고, 프로파일을 설치할 수 있다. 또한, UICC(830)는 프로파일을 관리할 수 있다.

UICC(830)는 프로세서(820)의 제어에 따라 동작할 수도 있다. 또는 UICC(830)는 프로파일을 설치하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다. 어플리케이션의 일부는 프로세서(820)에 설치되어 있을 수도 있다.

한편, 단말은 메모리(미도시)를 더 포함할 수 있으며, 상기 단말의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(Flash Memory Type), 하드 디스크 타입(Hard Disk Type), 멀티미디어 카드 마이크로 타입(Multimedia Card Micro Type), 카드 타입의 메모리(예를 들면, SD 또는 XD 메모리 등), 자기 메모리, 자기 디스크, 광디스크, 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), PROM(Programmable Read-Only Memory), EEPROM(Electrically Erasable Programmable Read-Only Memory) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(820)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.

도 20은 본 개시의 일 실시 예에 따른 사업자 서버(450)의 구성요소를 도시하는 블록도이다.

다양한 실시 예에 따른 사업자 서버(450)는 송수신부(910) 및 적어도 하나 이상의 프로세서(920)를 포함할 수 있다.

다양한 실시 예에 따른 송수신부(910)는 단말(400) 또는 프로파일 서버(456)와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다.

예를 들면, 다양한 실시 예에 따른 송수신부(910)는 단말(400)로 활성화 코드 절차 시작 요청 메시지를 송신하고, 단말(400)로부터 LPA API 정보 목록을 수신하고, 프로파일 서버(460)로 이벤트 생성 요청 메시지를 송신하고, 프로파일 서버(460)로부터 이벤트 식별자를 수신하고, 단말(400)로 활성화 코드와 eUICC 색인번호를 송신할 수 있다.

한편, 적어도 하나 이상의 프로세서(920)는 사업자 서버(450)를 전반적으로 제어하기 위한 구성요소이다. 프로세서(920)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 사업자 서버(450)의 전반적인 동작을 제어할 수 있다. 적어도 하나 이상의 프로세서(920)는 제어부로 명명할 수 있다.

예를 들면, 다양한 실시 예에 따른 적어도 하나 이상의 프로세서(920)는 단말(400)로 활성화 코드 절차 시작 요청 메시지를 송신하고, 단말(400)로부터 LPA API 정보 목록을 수신하고, LPA API 정보 목록을 참조하여 eUICC를 적어도 하나 이상 선택하고, 프로파일 서버(460)로 이벤트 생성 요청 메시지를 송신하고, 프로파일 서버(460)로부터 이벤트 식별자를 수신하고, 이벤트 식별자를 참조하여 이벤트에 대응하는 활성화 코드를 생성하고, 단말(400)로 활성화 코드와 선택된 eUICC 색인번호를 송신하도록 사업자 서버(450)를 제어할 수 있다.

한편, 사업자 서버 는 메모리(미도시)를 더 포함할 수 있으며, 상기 사업자 서버의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(Flash Memory Type), 하드 디스크 타입(Hard Disk Type), 멀티미디어 카드 마이크로 타입(Multimedia Card Micro Type), 카드 타입의 메모리(예를 들면, SD 또는 XD 메모리 등), 자기 메모리, 자기 디스크, 광디스크, 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), PROM(Programmable Read-Only Memory), EEPROM(Electrically Erasable Programmable Read-Only Memory) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(920)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 단말은 복수의 eUICC 또는 복수의 모뎀이 장착된 경우, 활성화 코드 생성을 위한 단말 정보를 하나 이상 서버로 송신하여, 서버가 이벤트 처리 대상이 될 적절한 eUICC를 선택하도록 지원하고, 프로파일 서버로부터 이벤트를 다운로드하고 처리할 수 있다.

본 개시의 다양한 실시 예에 따르면, 통신 시스템에서 서버는 단말로부터 활성화 코 생성을 위한 단말 정보를 하나 이상 수신하고, 하나 이상의 단말 정보를 참조하여 적절한 eUICC를 선택하고, 선택된 eUICC가 처리할 이벤트를 생성하고, 이벤트에 대응하는 활성화 코드를 단말로 송신하여, 단말이 이벤트를 다운로드하고 처리하도록 할 수 있다.

본 개시의 일 실시예에 따른 무선 통신 시스템에서 단말의 통신 방법은, eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API(Local Profile Assistant Application Programming Interface) 정보를 적어도 하나 이상 포함하는 LPA API 목록(List)을 생성하는 단계; 상기 LPA API 목록을 서버로 전송하며, 상기 서버로부터 적어도 하나 이상의 활성화 코드와 상기 적어도 하나 이상의 활성화 코드 각각에 대응되는 적어도 하나 이상의 eUICC 식별 정보를 수신하는 단계; 상기 적어도 하나 이상의 eUICC 식별 정보에 기초하여 eUICC를 선택하는 단계; 및 상기 선택한 eUICC에 대하여, 상기 선택한 eUICC의 eUICC 식별 정보에 대응되는 활성화 코드를 처리하는 단계를 포함할 수 있다.

일 실시예에서, 상기 LPA API 목록을 생성하는 단계는, 복수 개의 eUICC 중 제1 eUICC를 선택하는 단계 및 상기 선택한 제1 eUICC에 대한 제1 LPA API 정보를 생성하는 단계를 포함하고, 상기 LPA API 정보는, 상기 단말의 단말 정보, 상기 제1 eUICC에 대한 eUICC 정보, 및 상기 제1 eUICC에 대한 식별 정보를 포함할 수 있다.

일 실시예에서, 상기 LPA API 목록을 생성하는 단계는, 추가적으로 선택할 eUICC가 있는지 여부를 판단하는 단계, 상기 추가적으로 선택할 eUICC가 있는 경우, 상기 복수 개의 eUICC 중 제2 eUICC를 선택하는 단계 및 상기 선택한 제2 eUICC에 대한 제2 LPA API 정보를 생성하는 단계를 포함할 수 있다.

일 실시예에서, 상기 LPA API 목록을 생성하는 단계는, 상기 추가적으로 선택할 eUICC가 없는 경우, 상기 제1 LPA API 정보와 상기 제2 LPA API 정보를 포함하는 상기 LPA API 목록을 생성하는 단계를 포함할 수 있다.

일 실시예에서, 상기 eUICC 식별 정보는, eUICC 색인번호(index)를 포함할 수 있다.

일 실시예에서, 상기 eUICC 색인 번호는, eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID), eUICC와 모뎀을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID) 또는 eUICC에 대해 단말 내지 LPA가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID) 중 적어도 하나 이상을 기초로 생성될 수 있다.

일 실시예에서, 상기 eUICC를 선택하는 단계는, 상기 서버로부터 하나의 eUICC에 대한 식별 정보를 수신한 경우, 상기 하나의 eUICC에 대한 식별 정보에 대응된 eUICC를 선택하고, 상기 서버로부터 복수 개의 eUICC에 대한 식별 정보를 수신하거나 또는 eUICC에 대한 식별 정보 없이 활성화 코드를 수신하는 경우, 기 설정된 기준에 따라 eUICC를 선택하는 단계를 포함할 수 있다.

일 실시예에서, 상기 기 설정된 기준에 따라 eUICC를 선택하는 단계는, 상기 복수 개의 eUICC 각각에 대한 잔여 가용 메모리 양, 설치된 프로파일 개수, 지원하는 eSIM 기능, 연결된 모뎀이 지원 가능한 무선 접속 기술 또는 LPA가 지원하는 eSIM 기능 중 적어도 하나 이상을 기초로 eUICC를 선택하는 단계를 포함할 수 있다.

본 개시의 다른 일 실시예에 따른 무선 통신 시스템에서 기지국의 통신 방법은, 단말로부터 eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API 정보를 적어도 하나 이상 포함하는 LPA API 목록을 수신하는 단계; 상기 LPA API 목록에서 하나의 LPA API 정보를 선택하는 단계; 상기 선택한 LPA API 정보에 기초하여 이벤트에 대응하는 활성화 코드를 생성하는 단계; 상기 생성한 활성화 코드와 상기 선택한 LPA API 정보에 대응되는 eUICC 식별 정보를 상기 단말로 전송하는 단계; 및 상기 활성화 코드에 대응하는 상기 이벤트를 처리하는 단계를 포함할 수 있다.

일 실시예에서, 상기 LPA API 정보는 상기 단말의 단말 정보, 상기 제1 eUICC에 대한 eUICC 정보, 및 상기 제1 eUICC에 대한 식별 정보를 포함할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템의 단말은, 송수신부; 프로파일이 저장되는 적어도 복수 개의 eUICC(embedded Universal Integrated Circuit Card); 및 eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API(Local Profile Assistant Application Programming Interface) 정보를 적어도 하나 이상 포함하는 LPA API 목록(List)을 생성하고, 상기 LPA API 목록을 서버로 전송하며, 상기 서버로부터 적어도 하나 이상의 활성화 코드와 상기 적어도 하나 이상의 활성화 코드 각각에 대응되는 적어도 하나 이상의 eUICC 식별 정보를 수신하며, 상기 적어도 하나 이상의 eUICC 식별 정보에 기초하여 eUICC를 선택하고, 상기 선택한 eUICC에 대하여, 상기 선택한 eUICC의 eUICC 식별 정보에 대응되는 활성화 코드를 처리하는 적어도 하나 이상의 프로세서를 포함할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 복수 개의 eUICC 중 제1 eUICC를 선택하고, 상기 선택한 제1 eUICC에 대한 제1 LPA API 정보를 생성하며, 상기 LPA API 정보는, 상기 단말의 단말 정보, 상기 제1 eUICC에 대한 eUICC 정보, 및 상기 제1 eUICC에 대한 식별 정보를 포함할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 추가적으로 선택할 eUICC가 있는지 여부를 판단하고, 상기 추가적으로 선택할 eUICC가 있는 경우, 상기 복수 개의 eUICC 중 제2 eUICC를 선택하며, 상기 선택한 제2 eUICC에 대한 제2 LPA API 정보를 생성할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 상기 추가적으로 선택할 eUICC가 없는 경우, 상기 제1 LPA API 정보와 상기 제2 LPA API 정보를 포함하는 상기 LPA API 목록을 생성할 수 있다 .

일 실시예에서, 상기 eUICC 식별 정보는, eUICC 색인번호(index)를 포함할 수 있다.

일 실시예에서, 상기 eUICC 색인 번호는, eUICC 식별자(eUICC identifier, eUICC ID, 또는 EID), eUICC와 모뎀을 연결하는 SIM 포트의 식별자(SIM port identifier 또는 SIM port ID) 또는 eUICC에 대해 단말 내지 LPA가 임의로 할당하는 가상 식별자(virtual identifier, virtual ID, 또는 VID) 중 적어도 하나 이상을 기초로 생성될 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 상기 서버로부터 하나의 eUICC에 대한 식별 정보를 수신한 경우, 상기 하나의 eUICC에 대한 식별 정보에 대응된 eUICC를 선택하고, 상기 서버로부터 복수 개의 eUICC에 대한 식별 정보를 수신하거나 또는 eUICC에 대한 식별 정보 없이 활성화 코드를 수신하는 경우, 기 설정된 기준에 따라 eUICC를 선택할 수 있다.

일 실시예에서, 상기 적어도 하나 이상의 프로세서는, 상기 복수 개의 eUICC 각각에 대한 잔여 가용 메모리 양, 설치된 프로파일 개수, 지원하는 eSIM 기능, 연결된 모뎀이 지원 가능한 무선 접속 기술 또는 LPA가 지원하는 eSIM 기능 중 적어도 하나 이상을 기초로 eUICC를 선택할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템의 기지국은, 송수신부; 및 단말로부터 eUICC에 대한 활성화 코드를 생성하기 위한 정보인 LPA API 정보를 적어도 하나 이상 포함하는 LPA API 목록을 수신하고, 상기 LPA API 목록에서 하나의 LPA API 정보를 선택하며, 상기 선택한 LPA API 정보에 기초하여 이벤트에 대응하는 활성화 코드를 생성하고, 상기 생성한 활성화 코드와 상기 선택한 LPA API 정보에 대응되는 eUICC 식별 정보를 상기 단말로 전송하며, 상기 활성화 코드에 대응하는 상기 이벤트를 처리하는 적어도 하나 이상의 프로세서를 포함할 수 있다.

일 실시예에서, 상기 LPA API 정보는 상기 단말의 단말 정보, 상기 단말이 선택한 eUICC에 대한 eUICC 정보, 및 상기 단말이 선택한 eUICC에 대한 식별 정보를 포함할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 단말은, 송수신부; 및 적어도 하나 이상의 프로세서; 를 포함하고, 상기 적어도 하나 이상의 프로세서는 서버로부터 활성화 코드 절차 시작 요청 메시지를 수신하고, LPA API 정보 목록을 생성 및 선별하고, 서버로 LPA API 정보 목록을 송신하고, 서버로부터 적어도 활성화 코드와 eUICC 색인번호를 수신하고, 활성화 코드를 참조하여 서버로 이벤트 요청 메시지를 송신하고, 서버로부터 이벤트의 일부 또는 전체를 수신하도록 상기 송수신부를 제어할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 서버는, 송수신부; 및 적어도 하나 이상의 프로세서; 를 포함하고, 상기 적어도 하나 이상의 프로세서는 단말로 활성화 코드 절차 시작 요청 메시지를 송신하고, 단말로부터 LPA API 정보 목록을 수신하고, 서버로 이벤트 생성 요청 메시지를 송신하고, 서버로부터 이벤트 식별자를 수신하고, 단말로 활성화 코드와 선택된 eUICC 색인번호를 송신하도록 상기 송수신부를 제어할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 단말은, 서버로부터 활성화 코드 절차 시작 요청 메시지를 수신하는 수신부를 포함하고, 단말에 장착된 하나 이상의 eUICC 그리고/또는 하나 이상의 모뎀의 정보를 수집하는 제어부를 포함하고, LPA API 정보 목록을 생성하고 선별하는 제어부를 포함하고, 서버로 LPA API 정보 목록을 송신하는 송신부를 포함하고, 서버로부터 적어도 활성화 코드와 eUICC 색인번호를 수신하는 수신부를 포함하고, eUICC 색인번호를 참조하여 eUICC를 선택하는 제어부를 포함하고, 활성화 코드를 참조하여 서버로 이벤트 요청 메시지를 송신하는 송신부를 포함하고, 서버로부터 이벤트의 일부 또는 전체를 수신하는 수신부를 포함하고, 수신한 일부 또는 전체의 이벤트를 선택된 eUICC에 대해 처리하는 제어부를 포함할 수 있다.

본 개시의 또다른 일 실시예에 따른 무선 통신 시스템에서 서버는, 단말로 활성화 코드 절차 시작 요청 메시지를 송신하는 송신부를 포함하고, 단말로부터 LPA API 정보 목록을 수신하는 수신부를 포함하고, LPA API 정보 목록을 참조하여 eUICC를 적어도 하나 이상 선택하는 제어부를 포함하고, 서버로 이벤트 생성 요청 메시지를 송신하는 송신부를 포함하고, 서버로부터 이벤트 식별자를 수신하는 수신부를 포함하고, 이벤트 식별자를 참조하여 이벤트에 대응하는 활성화 코드를 생성하는 제어부를 포함하고, 단말로 활성화 코드와 선택된 eUICC 색인번호를 송신하는 송신부를 포함할 수 있다.

상술한 본 개시의 구체적인 실시 예들에서, 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.

한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

본 개시의 다양한 실시 예들 및 이에 사용된 용어들은 본 개시에 기재된 기술을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 및/또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 본 개시에서, "A 또는 B", "A 및/또는 B 중 적어도 하나", "A, B 또는 C" 또는 "A, B 및/또는 C 중 적어도 하나" 등의 표현은 함께 나열된 항목들의 모든 가능한 조합을 포함할 수 있다. "제1", "제2", "첫째" 또는 "둘째" 등의 표현들은 해당 구성요소들을, 순서 또는 중요도에 상관없이 수식할 수 있고, 한 구성요소를 다른 구성요소와 구분하기 위해 사용될 뿐 해당 구성요소들을 한정하지 않는다. 어떤(예: 제1) 구성요소가 다른(예: 제2) 구성요소에 "(기능적으로 또는 통신적으로) 연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로 연결되거나, 다른 구성요소(예: 제3 구성요소)를 통하여 연결될 수 있다.

본 개시에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구성된 유닛을 포함하며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 모듈은 ASIC(application-specific integrated circuit)으로 구성될 수 있다.

본 개시의 다양한 실시 예들은 기기(machine)(예: 컴퓨터)로 읽을 수 있는 저장 매체(machine-readable storage media)(예: 내장 메모리 또는 외장 메모리에 저장된 명령어를 포함하는 소프트웨어(예: 프로그램)로 구현될 수 있다. 기기는, 저장 매체로부터 저장된 명령어를 호출하고, 호출된 명령어에 따라 동작이 가능한 장치로서, 다양한 실시 예들에 따른 단말(예: 제1 단말(230) 또는 제2 단말(230))을 포함할 수 있다. 상기 명령이 프로세서에 의해 실행될 경우, 프로세서가 직접, 또는 상기 프로세서의 제어 하에 다른 구성요소들을 이용하여 상기 명령에 해당하는 기능을 수행할 수 있다. 명령은 컴파일러 또는 인터프리터에 의해 생성 또는 실행되는 코드를 포함할 수 있다.

기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 신호(signal)를 포함하지 않으며 실재(tangible)한다는 것을 의미할 뿐 데이터가 저장매체에 반영구적 또는 임시적으로 저장됨을 구분하지 않는다.

본 개시에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 온라인으로 배포될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.

다양한 실시 예들에 따른 구성 요소(예: 모듈 또는 프로그램) 각각은 단수 또는 복수의 개체로 구성될 수 있으며, 전술한 해당 서브 구성 요소들 중 일부 서브 구성 요소가 생략되거나, 또는 다른 서브 구성 요소가 다양한 실시 예에 더 포함될 수 있다. 대체적으로 또는 추가적으로, 일부 구성 요소들(예: 모듈 또는 프로그램)은 하나의 개체로 통합되어, 통합되기 이전의 각각의 해당 구성 요소에 의해 수행되는 기능을 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따른, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적, 병렬적, 반복적 또는 휴리스틱하게 실행되거나, 적어도 일부 동작이 다른 순서로 실행되거나, 생략되거나, 또는 다른 동작이 추가될 수 있다.

Claims (20)

1. 주 단말의 통신 서비스를 제공하는 방법에 있어서,
   디스커버리 절차를 통해, 액세스 포인트로 동작하는 IoT(Internet of Things) 단말을 인지하여 접속(access)하는 단계;
   상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 상기 IoT 단말로 전송하는 단계;
   상기 제1 eSIM 셋업 절차를 종료 후, 상기 IoT 단말과의 제1 연결을 해지하는 단계;
   상기 IoT 단말의 접속 요청에 따라, 상기 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행하는 단계; 및
   상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하는 단계를 포함하는, 방법.
   
2. 제1항에 있어서,
   상기 제1 eSIM 셋업 절차는,
   상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계; 및
   통신 서비스 플랜 구매 단계를 포함하는, 방법.
   
3. 제1항에 있어서,
   상기 제2 eSIM 셋업 절차는,
   상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함하는, 방법.
   
4. 제1항에 있어서,
   상기 주 단말은,
   상기 IoT 단말의 접속 요청에 따라, 상기 주 단말의 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행 하는 단계에서, 액세스 포인트로 동작하는, 방법.
   
5. 제1항에 있어서,
   상기 인증 정보는,
   SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함하는, 방법.
   
6. IoT(Internet of Things) 단말의 통신 서비스를 제공하는 방법에 있어서,
   주 단말의 접속 요청에 따라, 상기 주 단말과 제1 연결을 수행하는 단계;
   상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 수신하는 단계;
   상기 제1 eSIM 셋업 절차를 종료 후, 상기 주 단말과의 제1 연결을 해지하는 단계;
   상기 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행하는 단계; 및
   상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하는 단계를 포함하는, 방법.
   
7. 제6항에 있어서,
   상기 제1 eSIM 셋업 절차는,
   상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계; 및
   통신 서비스 플랜 구매 단계를 포함하는, 방법.
   
8. 제6항에 있어서,
   상기 제2 eSIM 셋업 절차는,
   상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함하는, 방법.
   
9. 제6항에 있어서,
   상기 주 단말의 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행하는 단계에서,
   상기 주 단말은 액세스 포인트로 동작하는, 방법.
   
10. 제6항에 있어서,
    상기 인증 정보는,
    SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함하는, 방법.
    
11. 통신 서비스를 제공하는 주 단말에 있어서,
    통신부; 및
    디스커버리 절차를 통해, 액세스 포인트로 동작하는 IoT(Internet of Things) 단말을 인지하여 접속(access)하고, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 상기 IoT 단말로 전송하며, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 IoT 단말과의 제1 연결을 해지하고, 상기 IoT 단말의 접속 요청에 따라, 상기 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행하고, 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하도록 제어하는 프로세서를 포함하는, 주 단말.
    
12. 제11항에 있어서,
    상기 제1 eSIM 셋업 절차는,
    상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계; 및
    통신 서비스 플랜 구매 단계를 포함하는, 주 단말.
    
13. 제11항에 있어서,
    상기 제2 eSIM 셋업 절차는,
    상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함하는, 주 단말.
    
14. 제11항에 있어서,
    상기 주 단말은,
    상기 IoT 단말의 접속 요청에 따라, 상기 주 단말의 인증 정보에 기초하여 상기 IoT 단말과 제2 연결을 수행 시 액세스 포인트로 동작하는, 주 단말.
    
15. 제11항에 있어서,
    상기 인증 정보는,
    SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함하는, 주 단말.
    
16. 통신 서비스를 제공하는 IoT(Internet of Things) 단말에 있어서,
    통신부; 및
    주 단말의 접속 요청에 따라, 상기 주 단말과 제1 연결을 수행하고, 상기 IoT 단말에 대한 제1 eSIM 셋업(eSIM setup) 절차를 수행 중, 상기 제1 eSIM 셋업 절차에 이어 제2 eSIM 셋업 절차를 수행하기 위한 인증 정보를 수신하며, 상기 제1 eSIM 셋업 절차를 종료 후, 상기 주 단말과의 제1 연결을 해지하고, 상기 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행하며, 상기 제1 eSIM 셋업 절차의 후속 절차로 제2 eSIM 셋업 절차를 수행하도록 제어하는 프로세서를 포함하는, IoT 단말.
    
17. 제16항에 있어서,
    상기 제1 eSIM 셋업 절차는,
    상기 IoT 단말의 자원을 기초로, 상기 IoT 단말이 eSIM 셋업이 필요한 단말인지 여부를 판단하는 단계; 및
    통신 서비스 플랜 구매 단계를 포함하는, IoT 단말.
    
18. 제16항에 있어서,
    상기 제2 eSIM 셋업 절차는,
    상기 IoT 단말에 대한 프로파일을 다운로드 하는 단계를 포함하는, IoT 단말.
    
19. 제16항에 있어서,
    상기 주 단말은,
    상기 주 단말의 인증 정보에 기초하여, 상기 주 단말에 접속하여 상기 주 단말과 제2 연결을 수행 시, 액세스 포인트로 동작하는, IoT 단말.
    
20. 제16항에 있어서,
    상기 인증 정보는,
    SSID(Service Set IDentifier)/PW(Password), eSIM 프로파일 개통을 위한 트랜잭션(Transaction)을 나타내는 트랜잭션 ID 및 상기 IoT 단말의 EPS (Evolved Packet System) 정보 중 적어도 하나 이상을 포함하는, IoT 단말.

Images