KR20220027002A

KR20220027002A - 기기 변경 실패 시 프로파일 복구 방법 및 장치

Info

Publication number: KR20220027002A
Application number: KR1020210043754A
Authority: KR
Inventors: 임태형; 윤강진; 구종회; 이덕기
Original assignee: 삼성전자주식회사
Priority date: 2020-08-26
Filing date: 2021-04-05
Publication date: 2022-03-07

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다.
본 개시는 스마트 보안 매체 간 프로파일 이동에 있어 프로파일 이동 실패 시 프로파일을 복구하기 위한 방법 및 장치를 개시한다.

Description

기기 변경 실패 시 프로파일 복구 방법 및 장치{METHOD AND APPARATUS FOR RECOVERING PROFILE IN THE CASE OF FAILURE OF DEVICE CHANGE}

본 개시는 스마트 보안 매체에 관한 것으로, 보다 상세하게는, 스마트 보안 매체 간 프로파일 이동 시 프로파일 이동이 실패했을 경우 프로파일을 복구하기 위한 방법 및 장치에 관한 것이다.

4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (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)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.

이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.

상술한 것과 같이 이동통신 시스템의 발전에 따라 다양한 서비스를 제공할 수 있게 됨으로써, 이러한 서비스들을 효과적으로 제공하기 위한 방안이 요구되고 있다. 예를 들면, 두 기기 간에 프로파일(또는, 프로파일 패키지)을 안전하고 효율적으로 온라인상 이동하는 방법 등이 필요하다.

개시된 실시 예는 두 전자 장치에 포함된 보안 모듈 사이에 프로파일을 이동하던 중 프로파일 이동이 실패했을 시 프로파일을 복구하는 장치 및 방법을 제공하는 것이다.

상기와 같은 문제점을 해결하기 위한 본 발명은 무선 통신 시스템에서 제어 신호 처리 방법에 있어서, 기지국으로부터 전송되는 제1 제어 신호를 수신하는 단계; 상기 수신된 제1 제어 신호를 처리하는 단계; 및 상기 처리에 기반하여 생성된 제2 제어 신호를 상기 기지국으로 전송하는 단계를 포함하는 것을 특징으로 한다.

본 개시의 다양한 실시 예에 따르면, 하나의 기기에 설치되었던 프로파일이 다른 기기로 이동 중 상기 이동이 실패되는 경우 원래 기기에 설치되어 있던 프로파일이 복구될 수 있다.

도 1은 본 개시의 일 실시 예에 따른 단말에 고정된 프로파일이 탑재된 UICC를 이용한 단말의 이동통신 네트워크 연결방법을 도시하는 도면이다.
도 2는 본 개시의 일 실시 예에 따른 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연관된 서비스가 오프라인상 혹은 온라인상 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 3은 본 개시의 일 실시 예에 따른 프로파일의 가능한 상태와 각 상태로의 전이(transition) 조건을 도시하는 도면이다.
도 4는 본 개시의 일 실시 예에 따른 기기 변경을 준비하는 과정을 도시하는 도면이다.
도 5는 본 개시의 일 실시 예에 따른 기기 변경이 이루어지는 과정의 한 예를 도시하는 도면이다.
도 6은 본 개시의 일 실시 예에 따른 기기 변경이 이루어지는 과정의 또 다른 예를 도시하는 도면이다.
도 7은 본 개시의 일 실시 예에 따른 도 4에 개시된 4010 단계의 세부 절차를 도시하는 도면이다.
도 8은 본 개시의 일 실시 예에 따른 원격 프로파일 관리를 통해 프로파일을 '사용중지' 상태로 만들거나 '사용중지'된 프로파일을 사용 가능한 상태로 복구하는 방법을 도시하는 도면이다.
도 9는 본 개시의 일 실시 예에 따른 '사용중지'된 프로파일이 사용 가능한 상태로 복구되는 또 다른 방법을 도시하는 도면이다.
도 10은 본 개시의 일 실시 예에 따른 소스 단말에서 기기 변경을 위해 삭제된 프로파일을 재설치하는 방법을 도시하는 도면이다.
도 11은 본 개시의 일 실시 예에 따른 기기 변경이 이루어지는 과정의 또 다른 예를 도시하는 도면이다.
도 12은 본 개시의 일 실시 예에 따른 eUICC가 탑재된 단말의 구성을 도시하는 도면이다.
도 13는 본 개시의 일 실시 예에 따른 RSP 서버의 구성을 도시하는 도면이다.

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

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

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

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

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

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

본 개시에서, 용어를 지칭하는 제1, 제2 등의 수식어는, 실시예를 설명하는 데에 있어서 각 용어들을 서로 구분하기 위하여 사용될 수 있다. 제1, 제2 등의 수식어가 수식하는 용어는 서로 상이한 대상을 지칭할 수 있다. 그러나, 제1, 제2 등의 수식어가 수식하는 용어는 동일한 대상을 지칭할 수도 있다. 즉, 제1, 제2 등의 수식어는 동일한 대상을 서로 다른 관점에서 지칭하기 위하여 사용될 수도 있다. 예를 들면, 제1, 제2 등의 수식어는 동일한 대상을 기능적 측면 또는 동작의 측면에서 구분하기 위하여 사용될 수도 있다. 예를 들면, 제1 사용자 및 제2 사용자는 동일한 사용자를 지칭할 수도 있다.

또한, 본 개시에서는 SSP 및 UICC를 보안 매체의 예로 들어 각 실시예들을 설명하지만, 본 개시의 권리범위가 SSP 및 UICC에 의한 것으로 제한되지는 않는다. 예를 들면, SSP 및 UICC와 실질적으로 동일 또는 유사한 기능을 수행하는 다른 보안 매체에도, 이하 설명할 다양한 실시예들이 실질적으로 동일 또는 유사하게 적용될 수 있음은 해당 기술분야의 통상의 기술자들에게 자명하다.

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

"UICC(universal integrated circuit card)"는 이동 통신 단말기 등에 삽입하여 사용하는 스마트카드(smart card)로서 UICC 카드라고도 부른다. UICC는 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS와 같은 개인정보가 저장되어 GSM, WCDMA, LTE 등과 같은 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미한다.

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 모듈은 UICC 제조시 탑재되거나 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 UICC 카드에 다운로드될 수 있다. 또한, UICC 카드에는 복수개의 SIM 모듈이 다운로드 되어서 설치될 수 있고, 그 중의 적어도 한 개의 SIM 모듈이 선택되어 사용될 수 있다. 이러한 UICC 카드는 단말에 고정되거나 고정되지 않을 수 있다. 단말에 고정하여 사용되는 UICC를 eUICC(embedded UICC)라고 하며, 특히 단말의 통신 프로세서(communication processor), 어플리케이션 프로세서(application processor) 또는 이 두 프로세서가 통합된 단일 프로세서 구조를 포함하는 system-on-chip(SoC)에 내장된 UICC는 iUICC(integrated UICC)로 지칭될 수 있다. 통상적으로 eUICC와 iUICC는, 단말에 고정되어 사용되고, 원격으로 적어도 하나의 SIM 모듈이 UICC 카드에 다운로드되며, 상기 다운로드된 SIM 모듈 중 어느 하나의 SIM 모듈이 선택될 수 있도록 하는 기능을 포함하는 UICC 카드를 의미할 수 있다. 본 개시에서는 원격으로 적어도 하나의 SIM 모듈이 다운로드되고 SIM 모듈이 선택될 수 있도록 하는 기능을 포함하는 UICC 카드를 eUICC 또는 iUICC로 통칭한다. 즉, 원격으로 SIM 모듈이 다운로드되고 SIM 모듈이 선택될 수 있도록 하는 기능을 포함하는 UICC 카드 중 단말에 고정되거나 고정되지 않는 UICC 카드를 통칭하여 eUICC 또는 iUICC로 지칭한다.

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

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

"프로파일(profile)"은 UICC내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등의 데이터 객체(data object)를 의미할 수 있다.

본 개시에서 "프로파일 패키지"란 "프로파일"의 내용이 UICC 내에 설치될 수 있는 소프트웨어 형태로 패키징된 것을 의미할 수 있다. '프로파일 패키지'는 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) 일 수 있다. 본 개시에서 “프로파일 패키지”는 “프로파일”과 혼용될 수 있다.

본 개시에서 프로파일의 "상태"는 다음과 같을 수 있다.

[활성화(enable)]

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

[비활성화(disable)]

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

[삭제(delete)]

본 개시에서 단말이 프로파일을 삭제(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)로 통합되어 표시될 수도 있다.

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

"프로파일 구분자"는 프로파일 식별자 (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+)의 서명을 더 포함할 수 있다.

“RSP 서버(remote SIM provisioning server)”는 후술될 프로파일 제공서버 및/또는 프로파일 관리 서버 및/또는 개통중개서버를 지칭하는 명칭으로 사용될 수 있다. RSP 서버는 SM-XX (subscription manager XX)로 표현될 수 있다.

본 개시에서 "프로파일 제공서버"는 프로파일을 생성하거나, 생성된 프로파일을 암호화 하거나, 프로파일 원격관리 명령어를 생성하거나, 생성된 프로파일 원격관리 명령어를 암호화하는 기능을 포함할 수 있다. 프로파일 제공서버는, 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), PP (Profile 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 개통중개서버로부터 이벤트 등록 요청을 수신할 수도 있다.

"통신사업자 (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), 모바일 가상 네트워크 운영자 (mobile virtual network operator: MVNO), 서비스 제공자 (service provider 또는 SP), 프로파일 소유자 (profile owner: PO) 등으로 명명될 수 있으며, 각 통신사업자는 통신사업자의 이름 그리고/또는 고유 식별자 (object identifier: OID)를 적어도 하나 이상 설정하거나 할당 받을 수 있다. 만일 통신사업자가 하나 이상의 사업체의 그룹 또는 연합체 또는 대행사를 지칭하는 경우, 임의의 그룹 또는 연합체 또는 대행사의 이름 또는 고유 식별자는 해당 그룹 또는 연합체에 소속한 모든 사업체 내지 해당 대행사와 협력하는 모든 사업체가 공유하는 이름 또는 고유 식별자일 수 있다.

"가입자(subscriber)"는 단말에 대한 소유권을 지닌 서비스 공급자(service provider)를 지칭하거나, 단말에 대한 소유권을 가지고 있는 사용자(end user)를 지칭하는 용어로서 사용될 수 있다. 일반적으로 서비스 공급자가 소유권을 가지는 단말은 M2M 단말(M2M device)로, 사용자가 소유권을 가지는 단말은 사용자 단말(consumer device)로 명명될 수 있다. M2M 단말의 경우 단말에 대한 소유권을 지니지는 않았으나 서비스 공급자(service provider)로부터 단말을 양도 또는 임대 받아 사용하는 사용자(end user)가 존재할 수 있고, 이 경우 가입자는 서비스 공급자와 다르거나 같을 수도 있다.

"가입자 의도(subscriber intent)"는 가입자가 프로파일을 로컬관리 또는 원격관리하고자 하는 의도를 통칭하는 용어로 사용될 수 있다. 또한, 로컬관리의 경우 가입자 의도는 사용자 의도(end user intent)를 지칭하고, 원격관리의 경우 가입자 의도는 서비스 공급자 의도(service provider intent)를 지칭하는 용어로서 사용될 수도 있다.

"사용자 동의(end user consent)"는 사용자가 로컬관리 내지 원격관리의 수행에 동의하는지 여부를 지칭하는 용어로 사용될 수 있다.

'단말'은 이동국(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라 지칭할 수 있다.

“LPA(local profile assistant)”는 단말 또는 전자장치에서 UICC 또는 eUICC를 제어하도록 단말 또는 전자장치 내에 설치된 소프트웨어 또는 애플리케이션을 지칭할 수 있다.

"이벤트(event)"는 프로파일 다운로드(profile download), 또는 원격 프로파일 관리(remote profile management), 또는 기타 프로파일이나 eUICC의 관리/처리 명령어를 통칭하는 용어일 수 있다. 이벤트(event)는 원격 SIM 제공 동작(remote SIM provisioning operation, 또는 RSP 동작, 또는 RSP operation) 또는 이벤트 기록(event record)으로 명명될 수 있으며, 각 이벤트(event)는 그에 대응하는 이벤트 식별자(event identifier, event ID) 또는 매칭 식별자(matching identifier, matching ID)와, 해당 이벤트가 저장된 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 주소(FQDN, IP address, 또는 URL)와, 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 서명과, 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 디지털 인증서를 적어도 하나 이상 포함하는 데이터로 지칭될 수 있다.

이벤트(Event)에 대응하는 데이터는 "명령코드(Command Code)"로 지칭될 수 있다. 명령코드를 이용하는 절차의 일부 또는 전체는 "명령코드 처리 절차" 또는 "명령코드 절차" 또는 "LPA API(local profile assistant application programming interface)"로 지칭될 수 있다. 프로파일 다운로드(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 Management)”는 크게 “로컬 프로파일 관리”와 “원격 프로파일 관리”로 나뉠 수 있다.

"로컬 프로파일 관리(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))값, 특정 공개 키의 일부분의 연산 결과값 내지 해당 공개 키가 포함된 인증서의 일부분의 연산 결과값, 또는 데이터들이 저장된 저장 공간 등을 지칭하는 의미로서 사용될 수 있다.

"인증서 연쇄(certificate chain)" 또는 인증서 계층구조(certificate hierarchy)는 "인증서 발급자(certificate issuer)"가 발급한 인증서들(1차 인증서)이 다른 인증서(2차 인증서)를 발급하는데 사용될 수 있다. 또한, 인증서 연쇄 또는 인증서 계층구조는 상기 2차 인증서들이 3차 이상의 인증서들을 연계적으로 발급하는데 사용되는 경우, 해당 인증서들의 상관관계를 나타낼 수 있다. 이 때 최초 인증서 발급에 사용된 CI 인증서는 인증서 근원(root of certificate), 최상위 인증서, 근원 CI(root CI), 근원 CI 인증서(root CI certificate), 근원 CA(root CA) 근원 CA 인증서(root CA certificate)등으로 명명될 수 있다.

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

이하에서는 단말 간 프로파일을 이동하고 설치하는 방법 및 장치에 관한 다양한 실시 예들을 설명한다.

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

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

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

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

도 2는 본 개시의 일 실시 예에 따른 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연관된 서비스가 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.

도 2에 도시된 바와 같이, 제1 단말(200) 및 제2 단말(220)에는 각각 제1 eSIM(203) 및 제2 eSIM(223)이 장착되어 있고, 제1 eSIM(203) 및 제2 eSIM(223)에는 각각 프로파일(미도시)이 설치될 수 있다. 또한 제1 단말(200) 및 제2 단말(220)에는 각각 제1 LPA(201) 및 제2 LPA(221)가 설치될 수 있다. 제1 eSIM(203) 및 제2 eSIM(223)은 각각 제1 LPA(201) 및 제2 LPA(221)의 제어를 받을 수 있다. 제1 사용자(205) 및 제2 사용자(225)는 각각 제1 LPA(201) 및 제2 LPA(221)를 통해 각 단말의 eSIM(제1 eSIM(203) 및 제2 eSIM(223))에 설치된 프로파일을 제어할 수 있다. 이때, 제1 사용자(205)와 제2 사용자(225)는 서로 같을 수 있다. 또한 제1 LPA(201)와 제2 LPA(221)은 서로 연결되어 통신할 수 있다. 이하, LPA 간의 가능한 연결 방법을 후술한다.

제1 단말(200)의 제1 LPA(201)는 제1 RSP 서버(240)와 연결되어 있고, 제2 단말(220)의 제2 LPA(221)는 제2 RSP 서버(280)와 연결될 수 있다. 이 때 제1 RSP 서버(240)와 제2 RSP 서버(280)는 서로 같을 수도 있다. 또한 도면에는 편의상 제1 RSP 서버(240) 및 제2 RSP 서버(280) 각각이 단일 서버로서 구성되는 경우를 도시하였지만, 구현 및 실시예에 따라, 하나 이상의 프로파일 제공서버(SM-DP+)가 서버 구성에 포함될 수 있고, 특정 프로파일 제공서버와 단말의 연결 생성을 보조하는 하나 이상의 개통중개서버(SM-DS)가 서버 구성에 포함될 수도 있다. 또한, 본 도면에 도시되지는 않았지만 제1 RSP 서버(240)와 제2 RSP 서버(280) 사이에는 하나 이상의 RSP 서버 및/또는 릴레이 서버가 연결될 수 있다.

또한, 도면에 도시되어 있지는 않지만, 각 RSP 서버 및/또는 릴레이 서버는 사업자 서버에 연결될 수 있다. 하나 이상의 사업자 서버가 구성에 포함되는 경우, 각 사업자 서버는 별도의 각 RSP 서버 및/또는 릴레이 서버와 연결될 수 있고, 적어도 하나 이상의 사업자 서버가 동일한 RSP 서버 및/또는 릴레이 서버에 연결될 수도 있다.

이와 같이 다양한 서버의 구성은 이하 도면에서 간략하게 단일 RSP 서버로 표기될 수 있다. 예를 들어, 제1 단말(200)과 제2 단말(220) 사이에 하나 이상의 RSP 서버 및/또는 릴레이 서버가 연결되어 있고, 일부 혹은 전체 RSP 서버 및/또는 릴레이 서버가 사업자 서버와 연결되어 있을 경우, 제1 단말과 제2 단말 사이에 존재하는 다양한 서버의 구성은 단일 RSP 서버로 표현될 수 있으며, 상기 단일 RSP 서버는 도면 및 실시예에서 SM-XX로 지칭될 수 있다.

도 3은 본 개시의 일 실시 예에 따른 프로파일의 가능한 상태와 각 상태로의 전이(transition) 조건을 도시하는 도면이다.

도 3을 참조하면, 프로파일은 활성화(enabled) 상태(310)를 가질 수 있다. 활성화 상태의 프로파일은 해당 프로파일을 제공한 통신사업자를 통해 통신서비스를 받을 수 있다.

도 3을 참조하면, 프로파일은 비활성화(disabled) 상태(350)를 가질 수 있다. 비활성화 상태의 프로파일은 해당 프로파일을 제공한 통신사업자를 통해 통신서비스를 받을 수 없다.

활성화 상태와 비활성화 상태는 현재 통신서비스를 받느냐 받지 못하느냐의 차이가 있지만, 후술한 바와 같이, 사용자의 의도에 따라 두 상태가 상호 전이될 수 있기 때문에 두 경우 모두 '사용 가능한 상태'라 볼 수 있다. 즉, 활성화 상태 혹은 비활성화 상태의 프로파일은 사용자가 원할 경우 RSP 서버의 도움 없이 통신서비스를 사용할 수 있기 때문에 (비활성화의 경우 사용자가 활성화 상태로 상태를 변경하게 되면 통신서비스 사용이 가능) 모두 사용 가능한 상태라 볼 수 있다.

도 3을 참조하면, 프로파일은 사용중지(suspended) 상태(390)를 가질 수 있다. 사용중지 상태의 프로파일은 후술할 조건에 의해 활성화 상태나 비활성화 상태가 되지 않는 이상 사용될 수 없다. 즉, 후술할 설명처럼, 사용자의 의도에 따라 활성화 상태나 비활성화 상태로 전이될 수 없기 때문에 '사용중지' 상태는 '사용이 가능하지 않은 상태'라 볼 수 있다. 즉, '사용중지' 상태의 프로파일은 사용자가 원한다 해도 RSP 서버의 도움 및/또는 승인이 있어야만 통신서비스를 사용할 수 있게 되기 때문에 사용이 가능하지 않은 상태라 볼 수 있다.

도 3을 참조하면, 활성화 상태의 프로파일은 로컬 프로파일 관리나 원격 프로파일 관리에 의해 비활성화 상태가 될 수 있다. 이때, 로컬 프로파일 관리는 사용자의 입력을 통해 이루어질 수 있다. 또한, 도면에는 도시 되지 않았지만, 활성화 상태의 프로파일은 로컬 프로파일 관리나 원격 프로파일 관리에 의해 사용중지 상태가 될 수 있다. 로컬 프로파일 관리는 사용자의 입력을 통해 이루어질 수도 있고, 다른 동작의 부분으로서 (예를 들어, 본 개시에서 설명하는 기기 변경 동작) 수행될 수도 있다.

도 3을 참조하면, 비활성화 상태의 프로파일은 로컬 프로파일 관리나 원격 프로파일 관리에 의해 활성화 상태가 될 수 있다. 이때, 로컬 프로파일 관리는 사용자의 입력을 통해 이루어질 수 있다. 또한, 비활성화 상태의 프로파일은 로컬 프로파일 관리나 원격 프로파일 관리에 의해 사용중지 상태가 될 수 있다. 이때, 로컬 프로파일 관리는 사용자의 입력을 통해 이루어질 수도 있고, 다른 동작의 부분으로서 (예를 들어, 본 개시에서 설명하는 기기 변경 동작) 수행될 수도 있다.

도 3을 참조하면, 사용중지 상태의 프로파일은 원격 프로파일 관리에 의해 비활성화 상태가 될 수 있다. 혹은, 도면에 도시 되지는 않았지만, 원격 프로파일 관리에 의해 활성화 상태가 될 수 있다. 사용중지 상태의 프로파일이 원격 프로파일 관리에 의해 비활성화 및/또는 활성화 상태가 되는 과정은 도 8 혹은 도 9의 설명을 참조하기로 한다.

상기 '사용중지 상태'는 '비활성화 상태'의 일 형태일 수 있다. 예를 들어 '비활성화 상태'에 '사용중지'와 관련된 플래그(Flag)나 파라미터(Parameter)가 추가적으로 포함될 수 있다. 이 플래그나 파라미터는 프로파일 또는 프로파일 메타데이터에 위치해 있을 수 있다.

상기 플래그나 파라미터를 이용해 '사용중지 상태'와 '비활성화 상태'를 구분하는 몇 가지 가능한 예는 아래와 같다.

(1) 일 예로, 상기 플래그나 파라미터가 추가적으로 포함되어 있으면 상기 프로파일은 '사용중지 상태'로 간주될 수 있고, 포함되어 있지 않으면 상기 프로파일은 '비활성화 상태'로 간주될 수 있다.

(2) 다른 예로, 상기 플래그나 파라미터가 추가적으로 포함되어 있더라도, 상기 플래그나 파라미터의 값에 따라 '사용중지 상태'와 '비활성화 상태'가 구분될 수 있다. 예를 들어, 이 플래그나 파라미터의 값이 1이면 '사용중지' 상태를 의미하고 이 플래그나 파라미터의 값이 0이면 '비활성화' 상태를 의미할 수 있다.

상기 기재된 '사용중지 상태'와 '비활성화 상태'를 구분하는 방법은 예시일 뿐, 이에 국한되지 않는다.

도 4는 본 개시의 일 실시 예에 따른 기기 변경을 준비하는 과정을 도시하는 도면이다.

도 4에 도시된 소스 단말(410)은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(490)에 대한 설명은 도 2를 참조하기로 한다.

다양한 실시 예에 따르면, 소스 단말(410)은 기 설치된 프로파일을 보유하고 있을 수 있다.

다양한 실시 예에 따르면, 소스 단말(410)은 기 설치된 프로파일과 관련된 '기기 변경 정보(device change info)'을 보유하고 있을 수 있다. '기기 변경 정보'는 기기 변경이 이루어지기 전 통신사업자에 의해 설정되어 단말에 저장되어 있을 수 있다. 상기 과정은 소스 단말(410)이 해당 프로파일을 설치했을 때 수행될 수 있다.

'기기 변경 정보'에는 다음의 정보를 포함하는 인자가 포함될 수 있다.

- 해당 프로파일은 기기 변경이 지원되지 않음

- 해당 프로파일은 기기 변경이 지원됨. 단, '기기 변경 방법'을 획득하기 위해 먼저 원격 과정(Remote Process)를 거쳐야 함.

- 해당 프로파일은 기기 변경이 지원됨. 기기 변경 방법은 기기 변경 정보 안에 포함되어 있음. 이 경우 원격 과정을 거치지 않고 지역 과정(Local Process)를 통해 기기 변경이 수행될 수 있음.

해당 프로파일이 '원격 과정'을 거쳐야 하는 것으로 설정되어 있다면, 다음의 정보가 '기기 변경 정보'에 더 포함되어 있을 수 있다.

- 기기 변경 방법을 획득하기 위해 접속해야 할 서버의 주소

- 기기 변경 방법을 획득하기 위해 서버에 접속할 때, 소스 단말(410)이 타겟 단말의 eUICC 식별자를 제시해야 하는지의 여부

- 기기 변경 방법을 획득하기 위해 서버에 접속할 때 서비스를 이양 받기 원하는 타겟 단말이 해당 프로파일을 다운로드 및 설치할 수 있는지 적합성 검사(Eligibility Check)를 수행하기 위해 필요한 정보를 제시해야 하는지의 여부

기기 변경 정보 안에 기 저장되어 있거나, 혹은 전술한 '원격 과정'을 통해 획득될 수 있는 정보인, '기기 변경 방법(device change method 혹은 device change type)'은 다음의 인자 중 일부 혹은 전체를 포함할 수 있다.

- 소스 단말에 설치된 프로파일을 어떻게 처리해야 하는지에 대한 정보. 상기 정보는 이하의 정보를 포함할 수 있다.

-- 해당 프로파일을 삭제함

-- 해당 프로파일을 사용중지(suspended) 상태로 설정함

-- 해당 프로파일에 특별한 작업을 하지 않음

- 소스 단말(410)이 프로파일을 삭제하거나 사용중지 상태로 설정했을 경우 이 결과가 어떠한 방식으로 RSP 서버에 고지가 이루어져야 하는지에 대한 정보. 상기 정보는 이하의 정보를 포함할 수 있다.

-- 소스 단말(410)이 RSP 서버로 직접 고지를 해야 함

-- 소스 단말(410)이 타겟 단말을 통해 RSP 서버로 고지를 함. 이 경우 '부분 고지(partial notification)' 방법이 사용될 수 있음. 부분 고지에 대한 상세한 사항은 후술할 도 5와 도 6의 설명을 참조한다.

- 삭제되거나 혹은 사용중지 상태로 설정된 프로파일의 복구를 요청할 수 있는지를 나타내는 인자, 즉 복구 요청 허용 인자(recovery request allowance indicator)를 포함할 수 있다. 상기 인자의 사용 예는 다음과 같을 수 있다.

-- 삭제된 프로파일의 복구를 요청할 수 있는지를 나타내는 복구 요청 허용 인자가 '요청이 허용됨'으로 설정된 경우에만, 단말은 삭제된 프로파일의 복구를 요청할 수 있다. 이 경우, 삭제된 프로파일의 복구란 삭제되었던 프로파일과 기능적으로 동일한 프로파일을 단말에 재설치하는 과정을 의미할 수 있다.

-- 사용중지 상태로 설정된 프로파일의 복구를 요청할 수 있는지를 나타내는 복구 요청 허용 인자가 '요청이 허용됨'으로 설정된 경우에만, 단말은 사용중지 상태로 설정된 프로파일의 복구를 요청할 수 있다. 이 경우, 사용중지 상태로 설정된 프로파일의 복구란 사용중지 상태로 설정된 프로파일의 상태를 사용가능 상태로 설정하는 과정을 의미할 수 있다.

도 4를 참조하면 4000 단계에서 서비스 가입자 혹은 단말 사용자가, 현재 단말(즉, 소스 단말(410))에서 사용하고 있는 통신 서비스 중 타겟 단말로 이전하고 싶은 서비스와 연관된(associated) 소스 프로파일(source profile)을 선택할 수 있다. 이때, 소스 단말(410)은 기기 변경과 관련해 필요한 정보를 서비스 가입자 혹은 단말 사용자에게 제공할 수 있다.

도 4를 참조하면 4005 단계에서 소스 단말(410)은 사용자가 이전하고자 하는 서비스와 연관된 프로파일의 '기기 변경 정보'를 확인할 수 있다.

'기기 변경 정보'에 해당 프로파일은 기기 변경이 지원되지 않는 것으로 표시되어 있을 때, 상기 기기 변경 과정은 중단될 수 있다.

'기기 변경 정보'에 해당 프로파일은 기기 변경이 지원되지만, '기기 변경 방법'을 획득하기 위해 먼저 원격 과정(remote process)를 거쳐야 한다고 표시되어 있을 경우 4010 단계가 수행될 수 있다.

'기기 변경 정보'에 해당 프로파일은 기기 변경이 지원되며, '기기 변경 방법'이 기기 변경 정보 안에 포함되어 있을 경우 4015 단계가 수행될 수 있다.

도 4를 참조하면, 4010 단계에서 원격 과정(remote process)이 수행될 수 있다. 원격 과정(remote process)에 대한 상세한 설명은 도 7을 참조하기로 한다. 4010 단계를 통해 소스 단말(410)은 RSP 서버(490)로부터 '기기 변경 방법'을 획득할 수 있다.

도 4를 참조하면, 소스 단말(410)이 4015 단계에서 기기 변경 수행 여부 및/또는 기기 변경 수행 방법에 대해 사용자 동의를 받는 과정이 수행될 수 있다.

“4010 단계를 통해 RSP 서버로부터 제공 받은 '기기 변경 방법' 혹은 단말에 기 저장되어 있다가 4015 단계를 통해 사용자 동의를 받은 '기기 변경 방법'” 의 '소스 단말(410)에 설치된 프로파일을 어떻게 처리해야 하는지에 대한 정보'에, 해당 프로파일을 삭제하도록 설정이 되어 있다면 도 6의 과정이 수행될 수 있으며, 해당 프로파일을 사용중지(suspended) 상태로 설정하도록 설정이 되어 있다면 도 5의 과정이 수행될 수 있으며, 해당 프로파일에 특별한 작업을 하지 않도록 설정이 되어 있다면 도 11의 과정이 수행될 수 있다.

도 5는 본 개시의 일 실시 예에 따른 기기 변경이 이루어지는 과정의 한 예를 도시하는 도면이다.

구체적으로, 도 5의 과정은 '기기 변경 방법'의 '소스 단말에 설치된 프로파일을 어떻게 처리해야 하는지에 대한 정보'에, 해당 프로파일을 사용중지(suspended) 상태로 설정하도록 설정이 되어 있는 경우에 수행될 수 있다.

도 5에 도시된 소스 단말(510)과 타겟 단말(550)은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(590)에 대한 설명은 도 2를 참조하기로 한다.

도 5를 참조하면 5000 단계에서, 소스 단말(510)은 타겟 단말(550)로 이전하려는 서비스와 연관된 소스 프로파일을 '사용중지(suspended)' 상태로 설정할 수 있다.

이후, '기기 변경 방법'의 '소스 단말(510)이 프로파일을 사용중지 상태로 설정했을 경우 이 결과가 어떠한 방식으로 RSP 서버(590)에 고지가 이루어져야 하는지에 대한 정보'에 적힌 내용에 따라 다음과 같이 분기가 일어날 수 있다.

만일 '소스 단말(510)이 RSP 서버(590)로 직접 고지를 해야 함'이라는 정보가 설정되어 있다면, 5005 단계가 수행될 수 있다.

만일 '소스 단말(510)이 타겟 단말(550)을 통해 RSP 서버(590)로 고지를 함'이라는 정보가 설정되어 있다면, 5010 단계가 수행될 수 있다.

5005 단계 혹은 5010 단계 이후 5015 단계가 수행될 수 있다.

도 5를 참조하면 5005 단계에서, 소스 단말(510)은 RSP 서버(590)으로 자신이 소스 프로파일을 사용중지 상태로 설정하였음을 고지할 수 있다. 상기 과정은 소스 단말(510)이 RSP 서버(590)로 사용중지 고지서(suspend notification)를 전송함으로써 수행될 수 있다.

'사용중지 고지서(suspend notification)'는 다음의 정보를 적어도 하나 이상 포함할 수 있다.

- 고지서 일련 번호 (notification sequence number)

- 소스 단말(510)이 프로파일을 사용중지 상태로 설정했음을 의미하는 인자

- 고지서를 받을 RSP 서버(590)의 주소

- 사용중지 상태로 설정된 프로파일의 프로파일 구분자

- 소스 단말(510) (예를 들어, 소스 단말에 장착된 eUICC)이 위의 정보의 일부 및/또는 전체에 전자 서명한 서명 값

- 상기 서명 값을 검증하기 위한 일련의 인증서 정보들

5005 단계에서, 도면에는 도시되지 않았지만 소스 단말(510)은 타겟 단말(550)로 전송할 활성화 코드(activation code)를 준비할 수 있다. 이때, 타겟 단말(550)로 전송할 활성화 코드는 '기기 변경 방법'의 일부로 포함되어 있을 수 있다. 이 경우, 소스 단말(510)은 '기기 변경 방법'에 포함되어 있는 활성화 코드를 추출해 타겟 단말(550)로 전송할 준비를 할 수 있다.

상기 활성화 코드는 다음의 정보를 하나 이상 포함할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(550)이 프로파일을 다운로드 받기 위해 접속해야 할 RSP 서버(590)의 정보 (예를 들어, 주소 및/또는 OID)

- 타겟 단말(550)이 다운로드 받고자 하는 프로파일을 지칭하는 정보 (한 예로, 다운로드 받고자 하는 프로파일과 연관된 매칭 아이디(Matching ID). 이 매칭 아이디는 RSP 서버에 의해 생성되어 해당 프로파일과 연결되어 RSP 서버에 의해 관리되고 있을 수 있음.)

도 5를 참조하면 5010 단계에서, 소스 단말(510)은 타겟 단말(550)을 통해 RSP 서버(590)로 전송할 '부분 사용중지 고지서(partial suspend notification)'을 생성할 수 있다.

'부분 사용중지 고지서(partial suspend notification)는 다음의 정보를 하나 이상 포함할 수 있다.

- 고지서 일련 번호 (notification sequence number)

- 소스 단말이 프로파일을 사용중지 상태로 설정했음을 의미하는 인자

- 고지서를 받을 RSP 서버(590)의 주소

- 사용중지 상태로 설정된 프로파일의 프로파일 구분자

- 소스 단말 (예를 들어, 소스 단말에 장착된 eUICC)이 위의 정보의 일부 및/또는 전체에 전자 서명한 서명 값

즉, 부분 사용중지 고지서는 사용중지 고지서에서 서명 값을 검증하기 위한 일련의 인증서 정보들을 제외한 일련의 정보일 수 있다.

5010 단계에서, 도면에는 도시되지 않았지만, 소스 단말(510)은 타겟 단말(550)로 전송할 활성화 코드(activation code)를 준비할 수 있다. 예를 들어, 소스 단말(510)은 활성화 코드를 생성해 타겟 단말(550)로 전송할 준비를 할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(550)이 다운로드 받고자 하는 프로파일을 지칭하는 정보 (한 예로, 다운로드 받고자 하는 프로파일의 프로파일 구분자)

- 부분 사용중지 고지서 (예를 들어, 5010 단계에서 소스 단말(510)이 타겟 단말(550)로 전송한 부분 사용중지 고지서)

도 5를 참조하면, 5015 단계에서 소스 단말(510)은 타겟 단말(550)로 5005 단계 혹은 5010 단계에서 준비한 활성화 코드를 전송할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(550)이 다운로드 받고자 하는 프로파일을 지칭하는 정보

- 부분 사용중지 고지서

상기의 활성화 코드는 아래에 제시된 다양한 방법 중 하나를 통해 전송될 수 있다.

예를 들어, 소스 단말(510)은 타겟 단말(550)로 전송해야 할 정보를 소스 단말(510)의 UI를 통해 사용자에게 제공할 수 있다. 사용자는 제공받은 정보를 타겟 단말(550)의 UI를 이용해 입력할 수 있다.

혹은, 소스 단말(510)은 타겟 단말(550)로 전달해야 할 정보를 이미지(예를 들어, QR 코드)의 형태로 만들어 소스 단말(510)의 화면에 표시하고, 사용자는 소스 단말의 화면에 표시된 이미지를 타겟 단말(550)을 이용해 스캔함으로써 타겟 단말(550)에 정보가 전송될 수 있다.

혹은, 소스 단말(510)과 타겟 단말(550) 사이에 연결이 수립되고 이 수립된 연결을 이용해 정보가 전송될 수 있다. 이때, 소스 단말(510)과 타겟 단말(550) 사이에 수립되는 연결은 직접적인 기기 간 연결(예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D 와 같은 무선 연결 및 케이블 연결과 같은 유선 연결)일 수도 있고 혹은 소스 단말(510)과 타겟 단말(550) 사이에 원격 서버(예를 들어, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.

도 5를 참조하면, 5020 단계에서 타겟 단말(550)은 RSP 서버(590)로부터 프로파일을 다운로드 받아 설치할 수 있다.

타겟 단말(550)은 RSP 서버(590)와 연결을 수립하고 활성화 코드에 포함된 정보(예를 들면, 타겟 단말(550)이 다운로드 받고자 하는 프로파일을 지칭하는 정보)를 사용해 RSP 서버(590)로 프로파일을 요청할 수 있다. RSP 서버(590)는 수신한 정보를 바탕으로 타겟 단말(550)로 전송할 프로파일을 준비할 수 있다. 상기 과정에서 다음의 과정 중 적어도 하나가 추가적으로 더 포함될 수 있다.

- 타겟 단말(550)과 RSP 서버 사이의 상호 인증(mutual authentication)

- RSP 서버에 의한, 전송할 프로파일이 타겟 단말(550)에 정상적으로 설치되어 동작할 수 있는지 적합성 검사(eligibility check)

- 해당 프로파일을 타겟 단말(550)에 설치하기 위한 사용자 동의

RSP 서버는 타겟 단말(550)로 준비한 프로파일을 전송할 수 있다. 타겟 단말(550)은 RSP 서버로부터 수신한 프로파일을 타겟 단말(550) 내 (예를 들어, 타겟 단말(550)의 eUICC)에 설치할 수 있다.

도 5를 참조하면, 5025 단계에서 타겟 단말(550)은 RSP 서버(590)으로 프로파일 설치 결과(profile installation result)를 전송할 수 있다.

도 6은 본 개시의 일 실시 예에 따른 기기 변경이 이루어지는 과정의 또 다른 예를 도시하는 도면이다.

구체적으로, 도 6의 과정은 '기기 변경 방법'의 '소스 단말(610)에 설치된 프로파일을 어떻게 처리해야 하는지에 대한 정보'에, 해당 프로파일을 삭제하도록 설정이 되어 있는 경우에 수행될 수 있다.

도 6에 도시된 소스 단말(610)과 타겟 단말(650)은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(690)에 대한 설명은 도 2를 참조하기로 한다.

도 6를 참조하면 6000 단계에서, 소스 단말(610)은 타겟 단말(650)로 이전하려는 서비스와 연관된 소스 프로파일을 삭제할 수 있다.

이후, '기기 변경 방법'의 '소스 단말(610)이 프로파일을 삭제했을 경우 이 결과가 어떠한 방식으로 RSP 서버(690)에 고지가 이루어져야 하는지에 대한 정보'에 포함된 내용에 따라 다음과 같이 분기가 일어날 수 있다.

만일 '소스 단말(610)이 RSP 서버(690)로 직접 고지를 해야 함'이라는 정보가 설정되어 있다면 6005 단계가 수행될 수 있다.

만일 '소스 단말(610)이 타겟 단말(650)을 통해 RSP 서버(690)로 고지를 함'이라는 정보가 설정되어 있다면 6010 단계가 수행될 수 있다.

6005 단계 혹은 6010 단계 이후 6015 단계가 수행될 수 있다.

도 6를 참조하면 6005 단계에서, 소스 단말(610)은 RSP 서버(690)으로 자신이 소스 프로파일을 삭제했음을 고지할 수 있다. 상기 과정은 소스 단말(610)이 RSP 서버(690)로 삭제 고지서(delete notification)를 전송함으로써 수행될 수 있다.

'삭제 고지서(delete notification)'는 다음의 정보를 적어도 하나 이상 포함할 수 있다.

- 고지서 일련 번호 (notification sequence number)

- 소스 단말(610)이 프로파일을 삭제했음을 의미하는 인자

- 고지서를 받을 RSP 서버(690)의 주소

- 삭제된 프로파일의 프로파일 구분자

- 소스 단말(610) (예를 들어, 소스 단말에 장착된 eUICC)이 위의 정보의 일부 및/또는 전체에 전자 서명한 서명 값

- 상기 서명 값을 검증하기 위한 일련의 인증서 정보들

6005 단계에서, 도면에는 도시되지 않았지만 소스 단말(610)은 타겟 단말(650)로 전송할 활성화 코드(activation code)를 준비할 수 있다. 이때, 타겟 단말(650)로 전송할 활성화 코드는 '기기 변경 방법'의 일부로 포함되어 있을 수 있다. 이 경우, 소스 단말(610)은 '기기 변경 방법'에 포함되어 있는 활성화 코드를 추출해 타겟 단말(650)로 전송할 준비를 할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(650)이 프로파일을 다운로드 받기 위해 접속해야 할 RSP 서버(690)의 정보 (예를 들어, 주소 및/또는 OID)

- 타겟 단말(650)이 다운로드 받고자 하는 프로파일을 지칭하는 정보 (한 예로, 다운로드 받고자 하는 프로파일과 연관된 매칭 아이디(Matching ID). 이 매칭 아이디는 RSP 서버에 의해 생성되어 해당 프로파일과 연결되어 RSP 서버에 의해 관리되고 있을 수 있음.)

도 6를 참조하면 6010 단계에서, 소스 단말(610)은 타겟 단말(650)을 통해 RSP 서버(690)로 전송할 '부분 삭제 고지서(partial delete notification)'을 생성할 수 있다.

'부분 삭제 고지서(partial delete notification)는 다음의 정보를 하나 이상 포함할 수 있다.

- 고지서 일련 번호 (notification sequence number)

- 소스 단말이 프로파일을 삭제했음을 의미하는 인자

- 고지서를 받을 RSP 서버의 주소

- 삭제된 프로파일의 프로파일 구분자

- 소스 단말(610)(예를 들어, 소스 단말에 장착된 eUICC)이 위의 정보의 일부 및/또는 전체에 전자 서명한 서명 값

즉, 부분 삭제 고지서는 삭제 고지서에서 서명 값을 검증하기 위한 일련의 인증서 정보들을 제외한 일련의 정보일 수 있다.

6010 단계에서, 도면에는 도시되지 않았지만, 소스 단말(610)은 타겟 단말(650)로 전송할 활성화 코드(activation code)를 준비할 수 있다. 예를 들어, 소스 단말(610)은 활성화 코드를 생성해 타겟 단말(650)로 전송할 준비를 할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(650)이 다운로드 받고자 하는 프로파일을 지칭하는 정보 (한 예로, 다운로드 받고자 하는 프로파일의 프로파일 구분자)

- 부분 삭제 고지서 (예를 들어, 6010 단계에서 소스 단말(610)이 타겟 단말(650)로 전송한 부분 삭제 고지서)

도 6를 참조하면, 6015 단계에서 소스 단말(610)은 타겟 단말(650)로 6005 단계 혹은 6010 단계에서 준비한 활성화 코드를 전송할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(650)이 프로파일을 다운로드 받기 위해 접속해야 할 RSP 서버의 정보 (예를 들어, 주소 및/또는 OID)

- 타겟 단말(650)이 다운로드 받고자 하는 프로파일을 지칭하는 정보

- 부분 삭제 고지서

예를 들어, 소스 단말(610)은 타겟 단말(650)로 전송해야 할 정보를 소스 단말(610)의 UI를 통해 사용자에게 제공할 수 있다. 사용자는 제공받은 정보를 타겟 단말(650)의 UI를 이용해 입력할 수 있다.

혹은, 소스 단말(610)은 타겟 단말(650)로 전달해야 할 정보를 이미지(예를 들어, QR 코드)의 형태로 만들어 소스 단말의 화면에 표시하고, 사용자는 소스 단말(610)의 화면에 표시된 이미지를 타겟 단말(650)을 이용해 스캔함으로써 타겟 단말(650)에 정보가 전송될 수 있다.

혹은, 소스 단말(610)과 타겟 단말(650) 사이에 연결이 수립되고 이 수립된 연결을 이용해 정보가 전송될 수 있다. 이때, 소스 단말(610)과 타겟 단말(650) 사이에 수립되는 연결은 직접적인 기기 간 연결(예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D 와 같은 무선 연결 및 케이블 연결과 같은 유선 연결)일 수도 있고 혹은 소스 단말(610)과 타겟 단말(650) 사이에 원격 서버(예를 들어, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.

도 6를 참조하면, 6020 단계에서 타겟 단말(650)은 RSP 서버(690)로부터 프로파일을 다운로드 받아 설치할 수 있다. 상기 과정은 아래의 절차를 포함할 수 있다.

타겟 단말(650)은 RSP 서버(690)와 연결을 수립하고 활성화 코드에 포함된 정보(예를 들면, 타겟 단말(650)이 다운로드 받고자 하는 프로파일을 지칭하는 정보)를 사용해 RSP 서버(690)로 프로파일을 요청할 수 있다. RSP 서버(690)는 수신한 정보를 바탕으로 타겟 단말(650)로 전송할 프로파일을 준비할 수 있다. 상기 과정에서 다음의 과정 중 적어도 하나가 추가적으로 더 수행될 수 있다.

- 타겟 단말(650)과 RSP 서버 사이의 상호 인증(mutual authentication)

- RSP 서버에 의한, 전송할 프로파일이 타겟 단말(650)에 정상적으로 설치되어 동작할 수 있는지의 적합성 검사(eligibility check)

- 해당 프로파일을 타겟 단말(650)에 설치하기 위한 사용자 동의

SP 서버는 타겟 단말(650)로 준비한 프로파일을 전송할 수 있다. 타겟 단말(650)은 RSP 서버로부터 수신한 프로파일을 타겟 단말(650) 내 (예를 들어, 타겟 단말의 eUICC)에 설치할 수 있다.

도 6를 참조하면, 6025 단계에서 타겟 단말(650)은 RSP 서버(690)으로 프로파일 설치 결과(profile installation result)를 전송할 수 있다.

도 7은 본 개시의 일 실시 예에 따른 도 4에 개시된 4010 단계의 세부 절차를 도시하는 도면이다.

도 7에 도시된 소스 단말(710)과 타겟 단말(750)은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(790)에 대한 설명은 도 2를 참조하기로 한다.

도 7을 참조하면 7000 단계에서 소스 단말(710)은 '기기 변경 방법'을 획득하기 위해 접속을 시도해야 하는 RSP 서버(790)의 주소를 획득할 수 있다. 소스 단말이 접속을 시도해야 하는 RSP 서버(790)의 주소는 '기기 변경 정보'에 포함되어 있을 수 있다.

도 7을 참조하면 7005 단계에서 다음의 과정이 수행될 수 있다.

만일 '기기 변경 정보'에, 소스 단말(710)이 기기 변경 방법을 획득하기 위해 서버에 접속할 때 타겟 단말(750)의 eUICC 식별자를 제시해야 한다고 설정되어 있다면, 소스 단말(710)은 타겟 단말(750)의 eUICC 식별자를 획득할 수 있다. 이 과정은 소스 단말(710)이 타겟 단말(750)로부터 타겟 단말(750)의 eUICC 식별자를 전송 받음으로써 수행될 수 있다.

만일 '기기 변경 정보'에, 소스 단말(710)이 기기 변경 방법을 획득하기 위해 서버에 접속할 때 타겟 단말(750)이 이양 받기 원하는 서비스와 연관된 프로파일을 다운로드 및 설치할 수 있는지 적합성 검사(eligibility check)를 수행하기 위해 필요한 정보를 제시해야 한다고 설정되어 있다면, 소스 단말(710)은 적합성 검사를 위해 필요한 타겟 단말(750)의 정보를 획득할 수 있다. 이 과정은 소스 단말(710)이 타겟 단말(750)로부터 타겟 단말(750)의 eUICC 정보 (euiccinfo2)와 LPA 및 모뎀 등의 정보(deviceinfo)를 전송 받음으로써 수행될 수 있다.

도 7을 참조하면 7010 단계에서 소스 단말(710)과 RSP 서버(790) 사이에 상호 인증이 수행될 수 있다. 상기 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.

- 상호 인증 과정은 소스 단말(710)과 RSP 서버(790)가 통신하기 위하여 거쳐야 할 인증서 협상 과정을 포함할 수 있다. 예를 들어 소스 단말(710)은 RSP 서버(790)를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 RSP 서버(790)가 소스 단말(710)을 검증하기 위해 사용할 수 있는 인증서 정보들을 RSP 서버(790)에게 전송할 수 있다. 이 정보를 수신한 RSP 서버(790)는, 소스 단말(710)이 RSP 서버(790)를 검증하는데 이용하게 될 인증서 정보들 및/또는 RSP 서버(790)가 소스 단말(710)을 검증하기 위해 사용할 인증서 정보들을 선택할 수 있다. 이때, RSP 서버(790)에 의해 선택된 인증서 정보들은 소스 단말(710)로 전송될 수 있다. 이러한 과정을 거쳐 소스 단말(710)과 RSP 서버(790)는 상호 인증할 수 있는 인증서 정보들을 획득할 수 있다. 이때, 인증서 정보란 인증서 및/또는 인증서에 포함된 정보 및/또는 인증서를 지칭할 수 있는 일련의 정보일 수 있다.

- 소스 단말(710)은 자신이 생성한 임의의 난수(eUICC challenge) 값을 RSP 서버(790)에게 전송할 수 있다. RSP 서버(790)는 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 소스 단말(710)로 전송할 수 있다. 소스 단말(710)은 수신한 서명 값을 검증함으로써 RSP 서버(790)를 인증할 수 있다.

- RSP 서버(790)는 자신이 생성한 임의의 난수(server challenge) 값을 소스 단말(710)로 전송할 수 있다. 소스 단말(710)은 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 RSP 서버(790)에게 전송할 수 있다. RSP 서버(790)는 수신한 서명 값을 검증함으로써 소스 단말(710)을 인증할 수 있다.

- RSP 서버(790)와 소스 단말(710)이 통신하는 동안 세션을 관리하기 위한 ID(transaction ID)가 교환될 수 있다. 예를 들어, RSP 서버(790)가 transaction ID를 생성한 뒤 이 값을 소스 단말(710)로 전송할 수 있다. 이때, transaction ID의 신뢰성과 무결성을 확인하기 위해 RSP 서버(790)의 전자 서명 값이 추가될 수 있다.

- RSP 서버(790)와 소스 단말(710)은 서로의 ID를 교환할 수 있다. 예를 들어, RSP 서버(790)는 소스 단말(710)에게 자신의 OID(object identifier)를 제공할 수 있다. 또 다른 예로, 소스 단말(710)은 RSP 서버(790)에게 자신의 eUICC 식별자를 제공할 수 있다.

도 7을 참조하면 7015 단계에서 다음의 과정이 수행될 수 있다.

소스 단말(710)은 RSP 서버(790)로 타겟 단말(750)로 이전하고자 하는 서비스와 연관된 프로파일의 프로파일 구분자를 전송할 수 있다.

소스 단말(710)은 RSP 서버(790)로 서비스 이전을 신청하는 메시지, 즉 기기 변경 요청(devicechangerequest)을 전송할 수 있다. devicechangerequest에는 타겟 단말(750)의 eUICC 식별자가 포함될 수 있다. devicechangerequest에는 타겟 단말(750)의 eUICC 정보 (euiccinfo2)와 LPA 및 모뎀 등의 정보(deviceinfo)가 포함될 수 있다.

도 7을 참조하면 7020 단계에서 RSP 서버(790)는 타겟 단말(750)로 전송할 프로파일을 준비할 수 있다.

프로파일을 준비하는 과정에서 해당 프로파일이 타겟 단말(750)에 정상적으로 설치되어 동작할 수 있는지 여부를 확인하기 위한 적합성 검사(eligibility check)를 수행해야 할 필요가 있을 경우, RSP 서버는 7015 단계에서 전송 받은 타겟 단말(750)의 eUICC 정보 (euiccinfo2)와 LPA 및 모뎀 등의 정보(deviceinfo)를 이용해 적합성 검사를 수행할 수 있다.

프로파일을 준비하는 과정에서 해당 프로파일을 타겟 단말(750)의 eUICC 식별자와 매칭(matching) 시켜야 할 필요가 있을 경우, RSP 서버(790)는 7015 단계에서 수신한 타겟 단말(750)의 eUICC 식별자를 이용해 상기 매칭을 수행할 수 있다.

도 7을 참조하면 7025 단계에서 RSP 서버(790)는 타겟 단말(750)로 기기 변경 요청에 대한 응답 메시지, 즉 기기 변경 응답(devicechangeresponse)을 전송할 수 있다. 기기 변경 응답은 '기기 변경 방법'을 포함하고 있을 수 있다. '기기 변경 방법'에 대한 설명은 도 4를 참조하기로 한다. 기기 변경 응답은 통신 사업자가 기기 변경과 관련해 사용자에게 고지하고자 하는 메시지를 추가로 더 포함할 수 있다.

도 7을 참조하면 7030 단계에서 소스 단말(710)은 기기 변경과 관련하여 사용자 동의를 받을 수 있다. 만일 7025 단계에서 통신 사업자가 기기 변경과 관련해 사용자에게 고지하고자 하는 메시지가 전송되었을 경우 상기 메시지는 사용자 동의를 받는 과정에서 사용자에게 제공될 수 있다.

도 7을 참조하면 7035 단계에서 소스 단말(710)은 RSP 서버(790)으로 사용자 동의 결과를 전송할 수 있다.

사용자 동의 결과는 다음의 메시지 중 하나를 포함할 수 있다.

- 사용자가 기기 변경에 동의함

- 사용자가 기기 변경에 동의하지 않음

- 사용자가 기기 변경을 보류함

- 사용자의 응답이 없음

도 7을 참조하면 7040 단계에서 다음의 과정이 수행될 수 있다.

사용자가 기기 변경에 동의했을 경우 RSP 서버(790)는 소스 단말(710)에게 기기 변경 과정을 계속 진행하라는 의미의 성공 메시지를 보낼 수 있다.

사용자가 기기 변경에 동의하지 않았을 경우 RSP 서버(790)는 7020 단계에서 준비했던 프로파일의 다운로드 준비를 취소할 수 있다.

도 8은 본 개시의 일 실시 예에 따른 원격 프로파일 관리를 통해 프로파일을 '사용중지' 상태로 만들거나 '사용중지'된 프로파일을 사용 가능한 상태로 복구하는 방법을 도시하는 도면이다.

도 8에 도시된 단말(810) 은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(890)에 대한 설명은 도 2를 참조하기로 한다.

도 8을 참조하면 8000 단계에서, 단말(810)은 원격 프로파일 관리 패키지(RPMpackage)를 받아올 RSP 서버(890)의 주소를 획득할 수 있다. 단말(810)이 접속해야 할 RSP 서버의 주소는 단말(810) 내부에 기 저장되어 있을 수도 있고, 단말(810)이 다른 RSP 서버 (예를 들면, 다른 개통 중개 서버(SM-DS))에 접속해 원격 프로파일 관리 패키지(RPMpackage)를 받기 위해 접속해야 할 RSP 서버의 주소를 획득할 수도 있다.

도 8을 참조하면, 8005 단계에서 단말(810)과 RSP 서버(890) 사이에 상호 인증이 수행될 수 있다. 이 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.

- 상호 인증 과정은 단말(810)과 RSP 서버(890)가 통신하기 위하여 거쳐야 할 인증서 협상 과정을 포함할 수 있다. 예를 들어 단말(810)은 RSP 서버(890)를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 RSP 서버(890)가 단말(810)을 검증하기 위해 사용할 수 있는 인증서 정보들을 RSP 서버(890)에게 전송할 수 있다. 이 정보를 수신한 RSP 서버(890)는, 단말(810)이 RSP 서버(890)를 검증하는데 이용하게 될 인증서 정보들 및/또는 RSP 서버(890)가 단말(810)을 검증하기 위해 사용할 인증서 정보들을 선택할 수 있다. 이때, RSP 서버(890)에 의해 선택된 인증서 정보들은 단말(810)로 전송될 수 있다. 이러한 과정을 거쳐 단말(810)과 RSP 서버(890)는 상호 인증할 수 있는 인증서 정보들을 획득할 수 있다. 이때, 인증서 정보란 인증서 및/또는 인증서에 포함된 정보 및/또는 인증서를 지칭할 수 있는 일련의 정보일 수 있다.

- 단말(810)은 자신이 생성한 임의의 난수(eUICC challenge) 값을 RSP 서버(890)에게 전송할 수 있다. RSP 서버(890)는 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 단말(810)로 전송할 수 있다. 단말(810)은 수신한 서명 값을 검증함으로써 RSP 서버(890)를 인증할 수 있다.

- RSP 서버(890)는 자신이 생성한 임의의 난수(server challenge) 값을 단말(810)로 전송할 수 있다. 단말(810)은 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 RSP 서버(890)에게 전송할 수 있다. RSP 서버(890)는 수신한 서명 값을 검증함으로써 단말(810)을 인증할 수 있다.

- RSP 서버(890)와 단말(810)이 통신하는 동안 세션을 관리하기 위한 ID(transaction ID)가 교환될 수 있다. 예를 들어, RSP 서버(890)가 transaction ID를 생성한 뒤 이 값을 단말(810)로 전송할 수 있다. 이때, transaction ID의 신뢰성과 무결성을 확인하기 위해 RSP 서버(890)의 전자 서명 값이 추가될 수 있다.

- RSP 서버(890)와 단말(810)은 본 개시에서 원격 프로파일 관리를 수행할 프로파일의 프로파일 구분자를 교환할 수 있다. 예를 들어, 단말(810)은 원격 프로파일 관리를 수행할 프로파일의 구분자를 RSP 서버(890)에게 전송할 수 있다. 이때, 프로파일 구분자는 신뢰성과 무결성을 보장하기 위해 단말(810)의 전자 서명 값과 함께 전송될 수 있다.

- RSP 서버(890)와 단말(810)은 서로의 ID를 교환할 수 있다. 예를 들어, RSP 서버(890)는 단말(810)에게 자신의 OID(object identifier)를 제공할 수 있다. 또 다른 예로, 단말(810)은 RSP 서버(890)에게 자신의 eUICC 식별자를 제공할 수 있다.

도 8을 참조하면, 8010 단계에서 다음의 과정이 수행될 수 있다.

RSP 서버(890)는 수신한 단말(810)의 eUICC 식별자 및/또는 프로파일 구분자를 이용해 단말(810)로 전송할 원격 프로파일 관리 패키지(RPMpackage)가 있는지 여부를 확인할 수 있다. RPMpackage는 다음의 원격 프로파일 관리 명령 (RPMcommand) 중 적어도 하나 이상을 포함할 수 있다.

- 프로파일을 활성화(enable) 시킬 것

- 프로파일을 비활성화(disable) 시킬 것

- 프로파일을 사용중지(suspended) 상태로 만들 것

- 프로파일을 복구(recover) 할 것

RSP 서버(890)는 상기 RPMpackage를 단말(810)로 전송할 수 있다.

도 8을 참조하면, 8015 단계에서 단말(810)은 수신한 원격 프로파일 관리 명령을 수행할 수 있다.

단말(810)이 '프로파일을 사용중지(suspended) 상태로 만들 것'이라는 원격 프로파일 관리 명령을 받았다면 다음의 과정 중 하나가 수행될 수 있다. 해당 프로파일이 비활성화(disabled) 상태였다면 프로파일의 상태를 사용중지 상태로 변경할 수 있다. 해당 프로파일이 활성화(enabled) 상태였다면 프로파일의 상태를 사용중지 상태로 변경할 수 있다. 또는, 해당 프로파일이 활성화 상태였다면 프로파일의 상태를 비활성화 상태로 만든 뒤 사용중지 상태로 변경할 수 있다.

단말(810)이 '프로파일을 활성화(enable) 시킬 것'이라는 원격 프로파일 관리 명령을 받았다면 다음의 과정 중 하나가 수행될 수 있다. 해당 프로파일이 비활성화(disabled) 상태였다면 프로파일의 상태를 활성화 상태로 변경할 수 있다. 해당 프로파일이 사용중지(suspended) 상태였다면 프로파일의 상태를 활성화 상태로 변경할 수 있다. 또는, 해당 프로파일이 사용중지 상태였다면 프로파일의 상태를 비활성화 상태로 만든 뒤 활성화 상태로 변경할 수 있다.

단말(810)이 '프로파일을 비활성화(disable) 시킬 것'이라는 원격 프로파일 관리 명령을 받았다면 다음의 과정 중 하나가 수행될 수 있다. 해당 프로파일이 활성화(enabled) 상태였다면 프로파일의 상태를 비활성화 상태로 변경할 수 있다. 해당 프로파일이 사용중지(suspended) 상태였다면 프로파일의 상태를 비활성화 상태로 변경할 수 있다.

단말(810)이 '프로파일을 복구할 것'이라는 원격 프로파일 관리 명령을 받았다면 다음의 과정 중 하나가 수행될 수 있다. 단말(810)은 사용중지(suspended) 상태의 프로파일을 비활성화(disabled) 상태로 변경할 수 있다. 단말(810)은 사용중지 (suspended) 상태의 프로파일을 활성화(enabled) 상태로 변경할 수 있다. 단말(810)은 사용중지(suspend) 상태의 프로파일을 비활성화(disabled) 상태로 변경한 뒤 활성화(enabled) 상태로 변경할 수 있다.

도 8을 참조하면, 8020 단계에서 단말(810)은 수행한 원격 프로파일 관리 명령의 결과를 바탕으로 원격 프로파일 관리 수행 결과 (loadRPMpackageresult) 를 생성할 수 있다. '원격 프로파일 관리 수행 결과'는 다음의 정보를 적어도 하나 이상 포함할 수 있다.

- 원격 프로파일 관리 명령을 수행한 프로파일의 프로파일 구분자

- 수행한 원격 프로파일 관리 명령

-- 해당 프로파일을 활성화 시켰음

-- 해당 프로파일을 비활성화 시켰음

-- 해당 프로파일을 사용중지 상태로 변경하였음

-- 해당 프로파일을 복구하였음

도 8을 참조하면, 8025 단계에서 단말(810)은 RSP 서버(890)로 8020 단계에서 생성한 '원격 프로파일 관리 수행 결과'를 전송할 수 있다.

상기에 기술한 원격 프로파일 관리 과정, 특히 사용중지 상태의 프로파일을 복구 및/또는 활성화 및/또는 비활성화 하는 과정 (편의를 위해 추후 '사용중지 상태의 프로파일을 복구 및/또는 활성화 및/또는 비활성화 하는 과정'은 '프로파일을 복구하는 과정'이라 통칭될 수 있다.)은, 도 5의 5000 단계에서 사용중지 되었던 프로파일을, 5020 단계에서 오류가 발생해 복구해야 할 경우 사용될 수 있다. 즉, 도 5의 5020 단계에서 오류가 발생해 타겟 단말에 프로파일이 정상적으로 설치되어 사용될 수 없게 된 경우, 소스 단말에서 사용중지 상태가 되었던 프로파일 (즉, 5000 단계에서)을 사용 가능한 상태로 만들기 위해 상기에 기술한 도 8의 개시가 실시될 수 있다. 이에 대한 보다 구체적인 내용은 아래와 같다.

(1) RSP 서버가 복구를 준비하는 단계

도 5의 5020 단계에서 타겟 단말(550)이 RSP 서버(590)로부터 프로파일을 다운로드 및/또는 설치하는 과정에서 오류가 생겼을 경우 RSP 서버(590)는 소스 단말(510)로 전송할 원격 프로파일 관리 패키지(RPMpackage)를 준비할 수 있으며, 이때 RPMpackage는 프로파일을 복구하기 위해 다음의 원격 프로파일 관리 명령 (RPMcommand) 중 적어도 하나 이상을 포함할 수 있다.

- 프로파일을 활성화(enable) 시킬 것

- 프로파일을 비활성화(disable) 시킬 것

- 프로파일을 복구(recover) 할 것

이때 RSP 서버가 소스 단말로 전송할 원격 프로파일 관리 패키지 (RPMpackage)를 준비하는 조건은 아래에 나열된 경우 중 적어도 하나일 수 있다.

- 프로파일 다운로드 시 오류 발생

-- 5020 단계에서 타겟 단말과 RSP 서버 사이 상호 인증 실패

-- 5020 단계에서 적합성 검사 실패

-- 5020 단계에서 사용자의 프로파일 설치 거부

- 프로파일 설치 시 영구적 오류(permanent error) 발생

프로파일 설치 시 발생하는 영구적 오류(permanent error)란, 타겟 단말이 해당 프로파일의 설치를 재시도한다 해도 여전히 프로파일을 설치할 수 없는 종류의 오류를 뜻한다.

프로파일 설치 시 발생하는 일시적 오류(temporary error)란, 타겟 단말이 해당 프로파일의 설치를 재시도했을 경우 프로파일 설치가 가능할 수도 있는 종류의 오류를 뜻한다.프로파일 설치 시 발생 가능한 일시적 오류는 다음의 예 중 하나일 수 있다.

- 메모리 부족 (install failed due to insufficient memory): eUICC 내의 설치 공간 부족으로 인한 설치 오류

- 인터럽션 (install failed due to interruption): 예기치 못한 동작 수행의 방해로 인한 설치 오류

5020 단계에서 상기 기술한 일시적 오류가 발생하였을 경우 다음의 과정 중 하나가 수행될 수 있다.

- RSP 서버가 소스 단말로 전송할 RPMpackage를 준비하지 않음

- RSP 서버가 소스 단말로 전송할 RPMpackage를 준비함

- 허용된 재시도 횟수(retry limit) 만큼 타겟 단말에 프로파일 설치를 시도하고, 이 횟수 동안 프로파일 설치가 실패했을 시, RSP 서버가 소스 단말로 전송할 RPMpackage를 준비함

상기의 과정을 통해 RSP 서버가 소스 단말로 전송할 RPMpackage를 준비한 뒤, RSP 서버는 다음의 동작 중 하나 이상을 수행할 수 있다.

- 소스 단말로 전송할 RPMpackage를 저장

- 소스 단말로 전송할 RPMpackage가 있음을 다른 RSP 서버 (다른 개통 중개 서버(SM-DS))에 등록

(2) 소스 단말이 복구를 수행하는 단계

이후 도 8에 도시된, 원격 프로파일 관리를 통해 '사용중지 상태의 프로파일을 복구하는 과정'이 수행됨으로써 소스 단말(510)에서 5000 단계를 통해 사용중지 되었던 프로파일이 복구(즉, 활성화 상태나 비활성화 상태가 되어 사용이 가능한 상태가 되는 것)될 수 있다.

이때 도 8에 도시된 과정 중 8000 단계 수행이 시작되는 경우는 다음 중 하나가 될 수 있다.

- 소스 단말(510)이 외부 입력 없이 8000 단계를 수행 시작

- 소스 단말(510)이 프로파일 설정에 따라 8000 단계를 수행 시작

- 소스 단말(510)이 주기적으로 8000 단계를 수행 시작

- 소스 단말(510)이 사용자로부터 입력을 받아 8000 단계를 수행 시작. 예를 들어, 사용자가 소스 단말이 제공하는 UI를 통해 해당 프로파일을 복구하겠다는 의사를 밝힘으로써 8000 단계가 수행 시작

- 소스 단말(510)이 RSP 서버로부터 입력을 받아 8000 단계를 수행 시작

도 9은 본 개시의 일 실시 예에 따른 '사용중지'된 프로파일이 사용 가능한 상태로 복구되는 또 다른 방법을 도시하는 도면이다. 본 도면에서 사용중지 상태의 프로파일을 사용가능한 상태로 복구한다는 것은 프로파일의 상태를 '활성화'하거나 '비활성화'하는 동작을 의미할 수 있다. '사용중지 상태의 프로파일을 사용가능한 상태로 복구'하는 과정은 간략히 '프로파일을 복구'하는 과정이라 기술될 수 있다.

도 9에 도시된 소스 단말(910) 은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(990)에 대해서는 도 2의 설명을 참조하기로 한다.

본 도면에서 프로파일을 복구하는 과정은 도 5의 과정 이후에 수행될 수 있다. 도 5의 5020 단계에서 오류가 발생해 복구해야 할 경우 5000 단계에서 사용중지 되었던 프로파일이 사용될 수 있다. 즉, 도 5의 5020 단계에서 오류가 발생해 타겟 단말에 프로파일이 정상적으로 설치되어 사용될 수 없게 된 경우, 소스 단말에서 사용중지 상태가 되었던 프로파일 (즉, 5000 단계에서)을 사용 가능한 상태로 만들기 위해 이하의 절차가 수행될 수 있다.

도 9를 참조하면 9000 단계에서 다음의 과정이 수행될 수 있다.

소스 단말(910)은 프로파일의 복구를 요청하기 위해 접속해야 할 RSP 서버(990)의 주소를 획득할 수 있다. 소스 단말(910)이 접속해야 할 RSP 서버의 주소는 소스 단말(910) 내부에 기 저장되어 있을 수도 있고, 소스 단말(910)이 다른 RSP 서버 (예를 들면, 다른 개통 중개 서버(SM-DS))에 접속해 복구를 위해 접속해야 할 RSP 서버의 주소를 획득할 수도 있다.

이때 소스 단말이 9000 단계를 수행하기 시작하게 되는 조건은 아래 중 하나일 수 있다.

- 소스 단말(910)이 자동으로 9000 단계를 수행 시작

- 소스 단말(910)이 사용자로부터 입력을 받아 9000 단계를 수행 시작. 예를 들어, 사용자가 소스 단말이 제공하는 UI를 통해 해당 프로파일을 복구하겠다는 의사를 밝힘으로써 9000 단계가 수행 시작

- 소스 단말(910)이 RSP 서버(가령, 990에 도시된 RSP 서버나 다른 RSP 서버)로부터 입력을 받아 9000 단계를 수행 시작

도 9를 참조하면, 9005 단계에서 소스 단말(910)과 RSP 서버(990) 사이에 상호 인증이 수행될 수 있다. 상기 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.

- 상호 인증 과정은 소스 단말(910)과 RSP 서버(990)가 통신하기 위하여 거쳐야 할 인증서 협상 과정을 포함할 수 있다. 예를 들어 소스 단말(910)은 RSP 서버(990)를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 RSP 서버(990)가 소스 단말(910)을 검증하기 위해 사용할 수 있는 인증서 정보들을 RSP 서버(990)에게 전송할 수 있다. 이 정보를 수신한 RSP 서버(990)는, 소스 단말(910)이 RSP 서버(990)를 검증하는데 이용하게 될 인증서 정보들 및/또는 RSP 서버(990)가 소스 단말(910)을 검증하기 위해 사용할 인증서 정보들을 선택할 수 있다. 이때, RSP 서버(990)에 의해 선택된 인증서 정보들은 소스 단말(910)로 전송될 수 있다. 이러한 과정을 거쳐 소스 단말(910)과 RSP 서버(990)는 상호 인증할 수 있는 인증서 정보들을 획득할 수 있다. 인증서 정보란 인증서 및/또는 인증서에 포함된 정보 및/또는 인증서를 지칭할 수 있는 일련의 정보일 수 있다.

- 소스 단말(910)은 자신이 생성한 임의의 난수(eUICC challenge) 값을 RSP 서버(990)에게 전송할 수 있다. RSP 서버(990)는 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 소스 단말(910)로 전송할 수 있다. 소스 단말(910)은 수신한 서명 값을 검증함으로써 RSP 서버(990)를 인증할 수 있다.

- RSP 서버(990)는 자신이 생성한 임의의 난수(server challenge) 값을 소스 단말(910)로 전송할 수 있다. 소스 단말(910)은 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 RSP 서버(990)에게 전송할 수 있다. RSP 서버(990)는 수신한 서명 값을 검증함으로써 소스 단말(910)을 인증할 수 있다.

- RSP 서버(990)와 소스 단말(910)이 통신하는 동안 세션을 관리하기 위한 ID(transaction ID)가 교환될 수 있다. 예를 들어, RSP 서버(990)가 transaction ID를 생성한 뒤 이 값을 소스 단말(910)로 전송할 수 있다. transaction ID의 신뢰성과 무결성을 확인하기 위해 RSP 서버(990)의 전자 서명 값이 추가될 수 있다.

- RSP 서버(990)와 소스 단말(910)은 서로의 ID를 교환할 수 있다. 예를 들어, RSP 서버(990)는 소스 단말(910)에게 자신의 OID(object identifier)를 제공할 수 있다. 또 다른 예로, 소스 단말(910)은 RSP 서버(990)에게 자신의 eUICC 식별자를 제공할 수 있다.

도 9를 참조하면, 9010 단계에서 다음의 과정이 수행될 수 있다.

소스 단말(910)은 RSP 서버(990)에게 프로파일의 복구를 요청할 수 있다. 이때, 소스 단말(910)은 RSP 서버(990)로 복구를 요청할 프로파일의 프로파일 구분자를 전송할 수 있다.

도 9를 참조하면, 9015 단계에서 다음의 과정이 수행될 수 있다.

RSP 서버(990)는 9010 단계에서 수신한 요청 메시지를 바탕으로 다음의 과정 중 하나 이상을 수행할 수 있다.

- 수신한 '소스 단말의 eUICC 식별자'와 복구를 요청 받은 프로파일의 '프로파일 구분자'를 사용하여 소스 단말이 해당 프로파일의 유효한 사용자였음을 확인할 수 있다.

- 복구를 요청 받은 프로파일이 복구를 요청한 소스 단말에서 복구가 가능한 것인지 여부를 확인할 수 있다.

상기 '복구를 요청 받은 프로파일이 복구를 요청한 소스 단말에서 복구가 가능한 것인지 여부'를 판단하는 과정에 대한 상세한 설명은 다음과 같다.

도 5의 5020 단계에서 타겟 단말(550)이 프로파일을 다운로드 및/또는 설치하는 과정에서 오류가 생겼을 경우 RSP 서버(990)는 해당 프로파일이 소스 단말(910)에서 복구가 가능한 것으로 판단할 수 있다.

이때 RSP 서버(990)가 해당 프로파일의 복구가 가능하다고 판단하는 '타겟 단말의 다운로드 및/또는 설치하는 과정에서의 오류'는 아래에 나열된 경우 중 적어도 하나를 포함할 수 있다.

- 프로파일 다운로드 시 오류 발생

-- 5020 단계에서 타겟 단말과 RSP 서버 사이 상호 인증 실패

-- 5020 단계에서 적합성 검사 실패

-- 5020 단계에서 사용자의 프로파일 설치 거부

- 프로파일 설치 시 영구적 오류(permanent error) 발생

- 프로파일 설치 시 일시적 오류(temporary error)가 허용된 재시도 횟수(retry limit) 초과 발생. 즉, 일시적 오류가 발생했을 경우 RSP 서버와 타겟 단말은 허용된 재시도 횟수 (단, 허용된 재시도 횟수는 0을 포함한 양의 정수 값이다.) 만큼 프로파일 설치를 시도할 수 있는데, 이 횟수 초과 프로파일 설치가 실패했을 경우.

프로파일 설치 시 발생하는 일시적 오류(temporary error)란, 타겟 단말이 해당 프로파일의 설치를 재시도했을 경우 프로파일 설치가 가능할 수도 있는 종류의 오류를 뜻한다. 프로파일 설치 시 발생 가능한 일시적 오류는 다음의 예 중 하나일 수 있다.

9015 단계 이후 9020 내지 9025 단계의 동작은 아래와 같이 다양한 방식으로 수행될 수 있다.

(1) 요청된 프로파일의 복구가 불가능한 것으로 판단되었을 경우

도 9를 참조하면, 9020 단계에서 RSP 서버(990)는 소스 단말(910)로 9010 단계에서 요청한 프로파일의 복구가 불가능함을 고지할 수 있다.

(2) 요청된 프로파일의 복구가 가능한 것으로 판단되었을 경우 (시나리오 1)

도 9를 참조하면, 9020 단계에서 RSP 서버(990)는 소스 단말(910)로 9010 단계에서 요청한 프로파일의 복구가 가능함을 고지할 수 있다.

예를 들어, RSP 서버에서 소스 단말로 전송되는 메시지에는 다음의 정보 중 하나 이상이 포함되어 있을 수 있다.

- 복구를 수행할 프로파일의 프로파일 구분자

- RSP 서버의 정보 (예를 들어, RSP 서버를 지칭하는 OID)

- 소스 단말의 eUICC 식별자

- 해당 프로파일의 복구가 가능함을 의미하는 플래그(Flag) 혹은 파라미터(Parameter), 해당 플래그와 파라미터는 특정한 값으로 설정되어 있을 수 있음

- 해당 프로파일의 복구 방법. 가령, 해당 프로파일을 '활성화' 상태로 만들거나 '비활성화' 상태로 만들어야 함을 지시.

- 상기 메시지의 일부 및/또는 전체에 대해 RSP 서버(990)가 서명한 전자 서명 값.

도 9를 참조하면, 9025 단계에서 다음의 과정이 수행될 수 있다.

소스 단말(910)은 9020 단계에서 수신한 메시지를 확인할 수 있다. 소스 단말은 수신한 메시지의 전자 서명이 유효함을 검증할 수 있다. 소스 단말은 수신한 메시지의 내용을 확인할 수 있다. 즉, 소스 단말은 수신한 메시지의 내용이 올바른지 여부를 확인할 수 있으며 자신이 어떠한 동작을 수행해야 하는지를 확인할 수 있다.

소스 단말(910)은 해당 프로파일을 복구할 수 있다. 즉, 소스 단말은 해당 프로파일을 사용 가능한 상태로 만들 수 있다. 예를 들어, 소스 단말은 해당 프로파일을 '활성화' 시키거나 '비활성화' 시킬 수 있다.

(3) 요청된 프로파일의 복구가 가능한 것으로 판단되었을 경우 (시나리오 2)

도 9를 참조하면, 9020 단계에서 RSP 서버(990)는 소스 단말(910)로 전송할 원격 프로파일 관리 패키지(RPMpackage)를 생성할 수 있다. 이때, RPMpackage는 다음의 원격 프로파일 관리 명령(RPMcommand) 중 적어도 하나 이상을 포함할 수 있다.

- 프로파일을 활성화(enable) 시킬 것

- 프로파일을 비활성화(disable) 시킬 것

- 프로파일을 복구(recover) 할 것

RSP 서버(990)는 상기 RPMpackage를 단말(910)로 전송할 수 있다. 이때 RPMpackage의 신뢰성과 무결성을 보장하기 위해 RSP 서버는 전자 서명 값을 추가로 더 전송할 수 있다.

소스 단말(910)은 9020 단계에서 수신한 메시지를 확인할 수 있다. 소스 단말은 수신한 전자 서명의 유효성을 검증할 수 있다. 소스 단말은 수신한 RPMpackage의 내용을 확인함으로써 자신이 어떠한 동작을 수행해야 하는지를 확인할 수 있다.

소스 단말(910)은 수행한 원격 프로파일 관리 명령의 결과를 바탕으로 원격 프로파일 관리 수행 결과 (loadRPMpackageresult) 를 생성할 수 있다. '원격 프로파일 관리 수행 결과'는 다음의 정보를 적어도 하나 이상 포함할 수 있다.

- 수행한 원격 프로파일 관리 명령

-- 해당 프로파일을 활성화 시켰음

-- 해당 프로파일을 비활성화 시켰음

-- 해당 프로파일을 복구하였음

소스 단말(910)은 RSP 서버(990)로 생성한 '원격 프로파일 관리 수행 결과'를 전송할 수 있다.

(4) 요청된 프로파일의 복구가 가능한 것으로 판단되었을 경우 (시나리오 3)

도 9를 참조하면, 9020 단계에서 다음의 과정이 수행될 수 있다.

RSP 서버(990)는 소스 단말(910)로 전송할 원격 프로파일 관리 패키지(RPMpackage)를 준비할 수 있다. 이때 RPMpackage는 프로파일을 복구하기 위해 다음의 원격 프로파일 관리 명령 (RPMcommand) 중 적어도 하나 이상을 포함할 수 있다.

- 프로파일을 활성화(enable) 시킬 것

- 프로파일을 비활성화(disable) 시킬 것

- 프로파일을 복구(recover) 할 것

- 소스 단말로 전송할 RPMpackage를 저장

RSP 서버(990)는 소스 단말(910)로 다음의 정보 중 하나 이상을 전송할 수 있다.

- 프로파일 복구가 승인되었음

- RPMpackage가 준비되었음

이후 도 8에 도시된, 원격 프로파일 관리를 통해 '사용중지 상태의 프로파일을 복구하는 과정'이 수행될 수 있다.

도 10은 본 개시의 일 실시 예에 따른 소스 단말에서 기기 변경을 위해 삭제된 프로파일을 재설치하는 방법을 도시하는 도면이다. 본 도면에서 삭제된 프로파일을 '재설치' 한다는 용어는 삭제된 프로파일을 '복구'한다는 용어와 동일한 의미로 사용될 수 있다.

도 10에 도시된 소스 단말(1010) 은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(1090)에 대해서는 도 2의 설명을 참조하기로 한다.

본 도면에 개시된 방법의 일 실시 예는 도 6에 도시된 과정을 통해 타겟 단말에 프로파일이 정상적으로 설치되지 않았을 경우 수행될 수 있다. 즉, 6000 단계 실행 후, 6005 이후의 단계에서 오류가 발생해 타겟 단말에 프로파일이 정상적으로 설치되지 않았을 경우 도 10의 과정이 수행될 수 있다. 상기 타겟 단말에 프로파일이 정상적으로 설치되지 않았을 경우를 '타겟 단말에 프로파일 정상 설치 실패 경우'라 부르기로 하며, '타겟 단말에 프로파일 정상 설치 실패 경우'의 상세한 설명은 아래와 같다.

[타겟 단말에 프로파일 정상 설치 실패 경우]

'타겟 단말에 프로파일 정상 설치 실패 경우'는 아래에 나열된 경우 중 적어도 하나를 포함할 수 있다.

- 타겟 단말이 프로파일 다운로드 및 설치를 요청하지 않은 경우

- 타겟 단말이 프로파일 다운로드 및 설치를 요청하였지만 프로파일 다운로드 시 오류 발생. 상기 프로파일 다운로드 시 오류 발생의 가능한 예는 아래와 같을 수 있다.

-- 6020 단계에서 타겟 단말과 RSP 서버 사이 상호 인증 실패

-- 6020 단계에서 적합성 검사 실패

-- 6020 단계에서 사용자의 프로파일 설치 거부

- 타겟 단말이 프로파일 다운로드 및 설치를 요청하였지만 프로파일 설치 시 영구적 오류(permanent error) 발생

- 타겟 단말이 프로파일 다운로드 및 설치를 요청하였지만 프로파일 설치 시 일시적 오류(temporary error)가 허용된 재시도 횟수(retry limit)를 초과하여 발생. 즉, 일시적 오류가 발생했을 경우 RSP 서버와 타겟 단말은 허용된 재시도 횟수 (단, 허용된 재시도 횟수는 0을 포함한 양의 정수 값이다.) 만큼 프로파일 설치를 시도할 수 있는데,상기 횟수를 초과하여 프로파일 설치가 실패했을 경우.

프로파일 설치 시 발생하는 영구적 오류(permanent error)란, 타겟 단말이 해당 프로파일의 설치를 재시도한다 해도 여전히 프로파일을 설치할 수 없는 종류의 오류를 뜻한다. 예를 들어, 영구적 오류는 후술할 일시적 오류를 제외한 설치 시 발생 가능한 오류들을 지칭할 수 있다.

- 메모리 부족으로 인한 오류 (install failed due to insufficient memory): eUICC 내의 설치 공간 부족으로 인한 설치 오류

- 인터럽션으로 인한 오류 (install failed due to interruption): 예기치 못한 동작 수행의 방해로 인한 설치 오류

본 도면에서는 10000 내지 10040 단계에 걸쳐, 삭제되었던 프로파일을 소스 단말에 다시 설치하는 다양한 실시 예를 도시하기로 한다.

본 도면에서 기술할, 삭제되었던 프로파일을 소스 단말에 다시 설치하는 다양한 실시 예들은 모두 크게 다음의 두 과정으로 구성될 수 있다.

- STEP1. 요청: 소스 단말이 RSP 서버로 복구 요청

- STEP2. 수락: RSP 서버가 소스 단말의 요청을 받아들여 복구 수행

상기에 기술된 것처럼, 후술하게 될 모든 실시 예들에 공통되는 두 가지 과정(STEP1. 요청, STPE2. 수락)의 실행 조건은 아래와 같을 수 있다.

[STEP1. 요청]

도 4에서 전술하였듯 소스 단말은 삭제된 프로파일과 관련한 '기기 변경 방법(device change method 혹은 device change type)'을 보유할 수 있고, '기기 변경 방법'은 삭제된 프로파일의 복구를 요청할 수 있는지를 나타내는 '복구 요청 허용 인자'를 포함할 수 있다. 소스 단말은, 복구 요청 허용 인자가 '요청이 허용됨'으로 설정된 경우에만, 삭제된 프로파일의 복구를 요청할 수 있을 수 있다.

[STEP2. 수락]

서버는 단말로부터 삭제된 프로파일의 복구를 요청받았을 때, 복구를 수행할 것인지를 판단한 뒤 복구를 수행할 수 있다. 이때, 복구를 수행하게 되는 조건은 아래에 기술된 조건 중 일부 또는 전체를 포함할 수 있다.

- 단말로부터 프로파일의 복구(또는 재설치)를 요청 받았음

- 해당 프로파일과 연관된 복구 요청 허용 인자는 '요청이 허용됨'으로 설정되어 있음.

- 상기 복구 요청 인자를 소스 단말로 보낸 적이 있음

- 프로파일의 복구를 요청한 단말이 소스 단말과 동일함

- [타겟 단말에 프로파일 정상 설치 실패 경우]가 발생한 것을 확인함

상기에 기술한 조건에 기반을 두고, 아래에서는 10000 내지 10040 단계에 걸쳐, 삭제되었던 프로파일을 소스 단말에 다시 설치하는 다양한 실시 예를 도시하기로 한다.

도 10을 참조하면 10000 단계에서 다음의 과정이 실행될 수 있다.

소스 단말은 재설치할 프로파일의 정보를 획득할 수 있다. 예를 들어, 사용자 혹은 가입자가 소스 단말이 제공하는 UI를 통해 재설치할 프로파일의 정보를 선택할 수 있다. 이때 가능한 UI의 한 예는 다음과 같다:

i) 소스 단말은 기기 변경을 위해 삭제된 프로파일의 내역을 사용자 혹은 가입자에게 제공할 수 있다.

ii) 소스 단말은 기기 변경을 위해 삭제된 프로파일의 재설치를 위한 입력 방법을 사용자 혹은 가입자에게 제공할 수 있다.

iii) 사용자 혹은 가입자는 상기의 입력 방법을 이용해 기기 변경을 위해 삭제된 프로파일 중 재설치를 원하는 프로파일을 선택할 수 있다.

iv) 소스 단말은 상기 사용자 혹은 가입자의 입력을 통해 재설치할 프로파일을 식별할 수 있다.

소스 단말은 선택된 프로파일을 재설치하기 위해 접속할 RSP 서버(1090)의 주소를 획득할 수 있다. 이때 소스 단말이 접속해야 할 RSP 서버의 주소를 획득하는 방법의 몇 가지 가능한 예는 아래와 같다.

- 해당 프로파일을 재설치하기 위해 접속해야 할 RSP 서버의 주소가 단말 및/또는 프로파일 (메타 데이터) 내부에 기 저장되어 있음.

- 도 6에 도시된 RSP 서버의 주소를 활용. 즉, 기기 변경을 위해 접속해야 할 RSP 서버의 주소를 (재)활용.

- 다른 RSP 서버 (예를 들면, 다른 개통 중개 서버(SM-DS))에 접속해 재설치를 위해 접속해야 할 RSP 서버의 주소를 획득.

도 10을 참조하면, 10000 단계 이후 경우에 따라 다음의 과정 중 하나가 수행될 수 있다.

[CASE 1]

본 경우는, 소스 단말이 도 6의 6005 단계 혹은 6010 단계에서 준비했던 활성화 코드를 저장하고 있을 때 수행될 수 있다(본 활성화 코드를 '저장된 활성화 코드'라 지칭).

본 경우는, 소스 단말이 도 4의 4010 단계(즉, 도 7의 과정)을 거치지 않거나, 혹은 도 4의 4010 단계(즉, 도 7의 과정)을 거쳤지만 타겟 단말의 eUICC 식별자를 RSP 서버로 전송하지 않았거나, 또는 도 4의 4010 단계(즉, 도 7의 과정)을 거쳐 타겟 단말의 eUICC 식별자를 RSP 서버로 전송하였지만 RSP 서버가 '기기 변경을 위해 준비한 프로파일'과 '상기 타겟 단말의 eUICC 식별자'를 바인딩 시켜 놓지 않았을 때 (즉, 해당 eUICC 식별자를 가진 단말만이 해당 프로파일을 받을 수 있도록 설정), 수행될 수 있다. 본 경우는 RSP 서버가 '기기 변경을 위해 준비한 프로파일'을 수신할 수 있는 단말로 소스 단말이 아닌 특정 단말(예를 들어, 타겟 단말)을 지정해 놓지 않은 경우 개시될 수 있다. (이 경우를 간단히 '타겟 단말로 프로파일이 바인딩 되지 않은 경우'라 부르기로 한다.)

이 경우 다음의 과정이 수행될 수 있다.

도 10을 참조하면, 10005 단계에서 다음의 과정이 수행될 수 있다.

- 소스 단말은 '저장된 활성화 코드'를 사용해 RSP 서버로 재설치를 요청할 수 있다. 이때, 소스 단말이 재설치를 요청할 수 있는 조건은 상술한 [STEP1. 요청] 조건을 따를 수 있다.

- RSP 서버는 소스 단말의 요청을 받은 후 재설치를 수행할 것인지 여부를 결정할 수 있다. 이때, RSP 서버가 재설치 수락 여부를 결정하는 조건은 [STEP2. 수락] 조건을 따를 수 있다.

- 또한 RSP 서버는 기존에 준비된 '기기변경을 위해 준비된 프로파일'이 소스 단말(1010)에 설치 가능한지 적합성 검사를 수행할 수 있다. 상기 적합성 검사는 소스 단말(1010)의 eUICC 정보 (euiccinfo2)와 LPA 및 모뎀 등의 정보(deviceinfo)를 전송 받음으로써 수행될 수 있다. '기기변경을 위해 준비된 프로파일'이 소스 단말(1010)에 적합하지 않은 경우, RSP 서버는 재설치를 위해 소스 단말(1010)에 적합한 프로파일을 준비할 수 있다.

- 상기에 기술된 세 가지 과정 (즉, 소스 단말이 '저장된 활성화 코드'를 사용해 RSP 서버로 재설치를 요청하는 과정 / RSP 서버가 소스 단말의 요청을 받은 후 재설치를 수행할 것인지 여부를 결정하는 과정 / RSP 서버가 적합성 검사를 수행하고 필요 시 소스 단말에 적합한 프로파일을 준비하는 과정)의 일부 또는 전체는 후술할 과정, 즉 소스 단말이 RSP 서버로부터 프로파일을 받아 재설치하는 과정의 일부로서 수행될 수 있다. 예를 들어, 소스 단말이 RSP 서버로부터 프로파일을 받아 재설치하기 위해 RSP 서버와 상호 인증을 수행할 수 있는데, 이 과정의 일부로서 수행될 수 있다.

- 소스 단말은 RSP 서버로부터 프로파일을 받아 재설치할 수 있다. 상기 과정은 도 6에 개시된 6020 내지 6025 단계와 유사하다. (6020 내지 6026 단계에서 타겟 단말이 수행하던 동작을 본 개시에서는 소스 단말이 수행한다는 차이점이 존재한다.)

[CASE 2]

본 경우는 '타겟 단말로 프로파일이 바운딩 된 경우'에 수행될 수 있다. 즉, RSP 서버가 '기기 변경을 위해 준비한 프로파일'을 수신할 수 있는 단말로 소스 단말이 아닌 특정 단말(예를 들어, 타겟 단말)을 지정해 놓은 경우에 수행될 수 있다. 그렇지만, 본 경우는 '타겟 단말로 프로파일이 바운딩 되지 않은 경우'에도 수행될 수 있다.

이 경우 다음의 과정이 수행될 수 있다.

도 10을 참조하면, 10010 단계에서 소스 단말(1010)과 RSP 서버(1090) 사이에 상호 인증이 수행될 수 있다. 상기 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.

- 상호 인증 과정은 소스 단말(1010)과 RSP 서버(1090)가 통신하기 위하여 거쳐야 할 인증서 협상 과정을 포함할 수 있다. 예를 들어 소스 단말(1010)은 RSP 서버(1090)를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 RSP 서버(1090)가 소스 단말(1010)을 검증하기 위해 사용할 수 있는 인증서 정보들을 RSP 서버(1090)에게 전송할 수 있다.상기 정보를 수신한 RSP 서버(1090)는, 소스 단말(1010)이 RSP 서버(1090)를 검증하는데 이용하게 될 인증서 정보들 및/또는 RSP 서버(1090)가 소스 단말(1010)을 검증하기 위해 사용할 인증서 정보들을 선택할 수 있다. 이때, RSP 서버(1090)에 의해 선택된 인증서 정보들은 소스 단말(1010)로 전송될 수 있다. 이러한 과정을 거쳐 소스 단말(1010)과 RSP 서버(1090)는 상호 인증할 수 있는 인증서 정보들을 획득할 수 있다. 인증서 정보란 인증서 및/또는 인증서에 포함된 정보 및/또는 인증서를 지칭할 수 있는 일련의 정보일 수 있다.

- 소스 단말(1010)은 자신이 생성한 임의의 난수(eUICC challenge) 값을 RSP 서버(1090)에게 전송할 수 있다. RSP 서버(1090)는 수신한 난수 값에 전자 서명을 한 뒤상기 서명 값을 소스 단말(1010)로 전송할 수 있다. 소스 단말(1010)은 수신한 서명 값을 검증함으로써 RSP 서버(1090)를 인증할 수 있다.

- RSP 서버(1090)는 자신이 생성한 임의의 난수(server challenge) 값을 소스 단말(1010)로 전송할 수 있다. 소스 단말(1010)은 수신한 난수 값에 전자 서명을 한 뒤상기 서명 값을 RSP 서버(1090)에게 전송할 수 있다. RSP 서버(1090)는 수신한 서명 값을 검증함으로써 소스 단말(1010)을 인증할 수 있다.

- RSP 서버(1090)와 소스 단말(1010)이 통신하는 동안 세션을 관리하기 위한 ID(transaction ID)가 교환될 수 있다. 예를 들어, RSP 서버(1090)가 transaction ID를 생성한 뒤상기 ID 값을 소스 단말(1010)로 전송할 수 있다. transaction ID의 신뢰성과 무결성을 확인하기 위해 RSP 서버(1090)의 전자 서명 값이 추가될 수 있다.

- RSP 서버(1090)와 소스 단말(1010)은 서로의 ID를 교환할 수 있다. 예를 들어, RSP 서버(1090)는 소스 단말(1010)에게 자신의 OID(object identifier)를 제공할 수 있다. 또 다른 예로, 소스 단말(1010)은 RSP 서버(1090)에게 자신의 eUICC 식별자를 제공할 수 있다.

도 10을 참조하면, 10015 단계에서 다음의 과정이 수행될 수 있다.

소스 단말(1010)은 RSP 서버(1090)에게 프로파일의 재설치를 요청할 수 있다. 이때, 소스 단말(1010)은 RSP 서버(1090)로 재설치를 요청할 프로파일의 프로파일 구분자를 전송할 수 있다. 또한, 소스 단말이 재설치를 요청할 수 있는 조건은 상술한 [STEP1. 요청] 조건을 따를 수 있다.

도 10을 참조하면, 10020 단계에서 다음의 과정이 수행될 수 있다.

RSP 서버(1090)는 10015 단계에서 수신한 요청 메시지를 바탕으로 재설치를 수행할 것인지 여부를 결정할 수 있다. RSP 서버가 재설치 수락 여부를 결정하는 조건은 [STEP2. 수락] 조건을 따를 수 있다.

위의 확인 결과 RSP 서버가 해당 프로파일의 재설치를 수행하기로 결정하였다면, RSP 서버는 해당 프로파일의 설치를 위해 필요한 활성화 코드를 준비해 소스 단말로 전송할 수 있다. 이때, 활성화 코드는 다음의 정보들 중 하나 이상을 포함할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 소스 단말이 프로파일을 다운로드 받기 위해 접속해야 할 RSP 서버의 정보 (예를 들어, 주소 및/또는 OID)

- 소스 단말이 다운로드 받고자 하는 프로파일을 지칭하는 정보. (예를 들면, 다운로드 받고자 하는 프로파일과 연결된 매칭 아이디(Matching ID).상기 매칭 아이디는 RSP 서버에 의해 생성되어 해당 프로파일과 연결되어 RSP 서버에 의해 관리되고 있을 수 있음.)

상기 RSP 서버로부터 소스 단말로 전송된 활성화 코드는 '수신한 활성화 코드'라 불릴 수 있다.

또한 RSP 서버가 해당 프로파일의 재설치를 수행하기로 결정하였을 때, RSP 서버는 기존에 준비된 '기기변경을 위해 준비된 프로파일'이 소스 단말(1010)에 설치 가능한지 적합성 검사를 수행할 수 있다. 이 과정은 소스 단말(1010)의 eUICC 정보 (euiccinfo2)와 LPA 및 모뎀 등의 정보(deviceinfo)를 전송 받음으로써 수행될 수 있다. '기기변경을 위해 준비된 프로파일'이 소스 단말(1010)에 적합하지 않은 경우, RSP 서버는 재설치를 위해 소스 단말(1010)에 적합한 프로파일을 준비할 수 있다.

상기 10015 단계와 10020 단계의 일부 또는 전체는 상술한 10010 단계의 일부로서 수행될 수 있다. 즉, 10010 단계에서 상호 인증을 수행하기 위해 RSP 서버와 소스 단말이 메시지를 주고 받게 되는데, 이 주고 받는 메시지에 10015 단계와 10020 단계를 위해 필요한 메시지의 일부 또는 전체를 포함하여 전송할 수 있다. 또한, 10010 단계에서 상호 인증을 수행하기 위해 RSP 서버와 소스 단말은 수신한 메시지를 처리하고 송신할 메시지를 생성하는 등 상호 인증을 위해 필요한 동작을 수행하는데, 이 동작의 일부로서 10015 단계와 10020 단계를 위해 필요한 동작의 일부 또는 전체가 수행될 수 있다.

도 10을 참조하면, 10025 단계에서 소스 단말은 '수신한 활성화 코드'를 사용해 RSP 서버로부터 프로파일을 다운로드 받아 설치할 수 있다. 상기 과정은 전술한 10005 단계와 동일하며, 10005 단계와의 차이는 10005 단계에서 '저장된 활성화 코드'가 사용되었다면 10025 단계에서는 '수신한 활성화 코드'가 사용된다는 점이다.

[CASE 3]

이 경우 다음의 과정이 수행될 수 있다.

도 10을 참조하면, 10030 단계에서 소스 단말(1010)과 RSP 서버(1090) 사이에 상호 인증이 수행될 수 있다. 상기 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.

도 10을 참조하면, 10035 단계에서 다음의 과정이 수행될 수 있다.

RSP 서버(1090)는 수신한 요청 메시지를 바탕으로 재설치를 수행할 것인지 여부를 결정할 수 있다. RSP 서버가 재설치 수락 여부를 결정하는 조건은 [STEP2. 수락] 조건을 따를 수 있다.

위의 확인 결과 RSP 서버가 해당 프로파일의 재설치를 수행하기로 결정하였다면 10040 단계가 수행될 수 있다.

상기 10035 단계의 일부 또는 전체는 상술한 10030 단계의 일부로서 수행될 수 있다. 즉, 10030 단계에서 상호 인증을 수행하기 위해 RSP 서버와 소스 단말이 메시지를 주고 받게 되는데, 이 주고 받는 메시지에 10035 단계를 위해 필요한 메시지의 일부 또는 전체를 함께 담아 전송할 수 있다. 또한, 10030 단계에서 상호 인증을 수행하기 위해 RSP 서버와 소스 단말은 수신한 메시지를 처리하고 송신할 메시지를 생성하는 등 상호 인증을 위해 필요한 동작을 수행하는데, 이 동작의 일부로서 10035 단계를 위해 필요한 동작의 일부 또는 전체가 수행될 수 있다.

도 10을 참조하면, 10040 단계에서 소스 단말(1010)과 RSP 서버(1090) 사이에 프로파일 다운로드 및 설치 과정이 수행될 수 있다. RSP 서버(1090)는 소스 단말(1010)로 준비된 프로파일을 전송할 수 있다. 상기 프로파일은 10035 단계에서 기 준비된 프로파일이거나, 혹은 소스 단말의 요청을 받아 본 단계에서 준비한 프로파일일 수 있다. 소스 단말(1010)은 수신한 프로파일을 설치할 수 있다.

도 11은 본 개시의 일 실시 예에 따른 기기 변경이 이루어지는 과정의 또 다른 예를 도시하는 도면이다.

구체적으로, 도 11의 과정은 '기기 변경 방법'의 '소스 단말(1110)에 설치된 프로파일을 어떻게 처리해야 하는지에 대한 정보'에, 해당 프로파일에 특별한 작업을 하지 않음으로 설정이 되어 있는 경우에 수행될 수 있다. 즉, 해당 파일을 삭제하거나 사용중지 상태로 설정하지 않는 경우에 수행될 수 있다.

도 11에 도시된 소스 단말(1110)과 타겟 단말(1150)은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. RSP 서버(1190)에 대한 설명은 도 2를 참조하기로 한다.

도 11을 참조하면, 11005 단계에서 소스 단말(1110)은 타겟 단말(1150)로 활성화 코드를 전송할 수 있다.

타겟 단말(1150)로 전달될 활성화 코드는 다양한 방법으로 준비될 수 있다. 예를 들어, 가능한 두 가지 방법은 아래와 같다.

- 소스 단말(1110)은 '기기 변경 방법'에 포함되어 있는 활성화 코드를 추출해 타겟 단말(1150)로 전송할 준비를 할 수 있다.

- 소스 단말(1110)은 스스로 활성화 코드를 생성해 타겟 단말(1150)로 전송할 준비를 할 수 있다.

상기에 기술된 타겟 단말로 전달될 활성화 코드는 다음의 정보를 하나 이상 포함할 수 있다.

- 활성화 코드의 포맷을 지칭하는 정보

- 타겟 단말(1150)이 프로파일을 다운로드 받기 위해 접속해야 할 RSP 서버의 정보 (예를 들어, 주소 및/또는 OID)

- 타겟 단말(1150)이 다운로드 받고자 하는 프로파일을 지칭하는 정보. 예를 들어, 가능한 정보는 아래와 같다.

-- 다운로드 받고자 하는 프로파일의 프로파일 구분자

-- 다운로드 받고자 하는 프로파일과 연관된 매칭 아이디(Matching ID). 이 매칭 아이디는 RSP 서버에 의해 생성되어 해당 프로파일과 연결되어 RSP 서버에 의해 관리되고 있을 수 있음.

- 소스 단말(1110)은 타겟 단말(1150)로 전송해야 할 정보를 소스 단말(1110)의 UI를 통해 사용자에게 제공할 수 있다. 사용자는 제공받은 정보를 타겟 단말(1150)의 UI를 이용해 입력할 수 있다.

- 소스 단말(1110)은 타겟 단말(1150)로 전달해야 할 정보를 이미지(예를 들어, QR 코드)의 형태로 만들어 소스 단말의 화면에 표시하고, 사용자는 소스 단말(1110)의 화면에 표시된 이미지를 타겟 단말(1150)을 이용해 스캔함으로써 타겟 단말(1150)에 정보가 전송될 수 있다.

- 소스 단말(1110)과 타겟 단말(1150) 사이에 연결이 수립되고 이 수립된 연결을 이용해 정보가 전송될 수 있다. 이때, 소스 단말(1110)과 타겟 단말(1150) 사이에 수립되는 연결은 직접적인 기기 간 연결(예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D 와 같은 무선 연결 및 케이블 연결과 같은 유선 연결)일 수도 있고 혹은 소스 단말(1110)과 타겟 단말(1150) 사이에 원격 서버(예를 들어, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.

도 11을 참조하면, 11010 단계에서 타겟 단말(1150)은 RSP 서버(1190)로부터 프로파일을 다운로드 받아 설치할 수 있다. 상기 과정은 아래의 절차를 포함할 수 있다.

타겟 단말(1150)은 RSP 서버(1190)와 연결을 수립하고 활성화 코드에 포함된 정보(예를 들면, 타겟 단말(1150)이 다운로드 받고자 하는 프로파일을 지칭하는 정보)를 사용해 RSP 서버(1190)로 프로파일을 요청할 수 있다. RSP 서버(1190)는 수신한 정보를 바탕으로 타겟 단말(1150)로 전송할 프로파일을 준비할 수 있다. 상기 과정에서 다음의 과정 중 적어도 하나가 추가적으로 더 수행될 수 있다.

- 타겟 단말(1150)과 RSP 서버(1190) 사이의 상호 인증(mutual authentication)

- RSP 서버(1190)에 의한, 전송할 프로파일이 타겟 단말(1150)에 정상적으로 설치되어 동작할 수 있는지의 적합성 검사(eligibility check)

- 해당 프로파일을 타겟 단말(1150)에 설치하기 위한 사용자 동의

RSP 서버(1190)는 타겟 단말(1150)로 준비한 프로파일을 전송할 수 있다. 타겟 단말(1150)은 RSP 서버(1190)로부터 수신한 프로파일을 타겟 단말(1150) 내 (예를 들어, 타겟 단말의 eUICC)에 설치할 수 있다.

도 11을 참조하면, 11015 단계에서 다음의 과정이 수행될 수 있다.

만일 프로파일 설치가 실패하였다면 타겟 단말(1150)은 RSP 서버(1190)으로 프로파일 설치가 실패했음을 의미하는 프로파일 설치 결과(profile installation result)를 전송할 수 있다. 이 경우, 11020 내지 11035 단계는 생략될 수 있다. 또한 이 경우, 소스 단말(1110)은 설치되어 있던 해당 프로파일을 계속 이용할 수 있다.

만일 프로파일 설치가 성공하였다면 이 설치된 프로파일은 '사용불가(Unusable)' 상태로 설정되어 있을 수 있다. '사용불가' 상태란, 프로파일이 단말 내에 정상적으로 설치되었지만, RSP 서버의 승인 절차 (예를 들어 후술할 11020 내지 11035 단계)가 없이는 사용이 될 수 없는 상태 (예를 들어 '활성화 상태'나 '비활성화 상태'로 변경될 수 없는 상태)를 의미할 수 있다. 이 경우 타겟 단말(1150)은 RSP 서버(1190)으로 프로파일 설치가 성공하였음을 의미하는 프로파일 설치 결과(profile installation result)를 전송할 수 있다. 이때, 프로파일 설치 결과는 프로파일 설치가 성공하였지만 현재 사용불가 상태로 설정이 되어 있음을 의미하는 정보를 더 포함할 수 있다.

도 11을 참조하면, 11020 단계에서 RSP 서버(1190)는 소스 단말(1110)로 프로파일의 상태 변경을 요청할 수 있다. 상세한 과정은 아래와 같다.

RSP 서버(1190)와 소스 단말(1110)이 통신을 위해 연결을 수립하는 과정은 다양한 방법으로 개시될 수 있다. 몇 가지 가능한 예는 아래와 같다.

- 도 4의 4010 단계에서 소스 단말과 RSP 서버가 통신을 했을 경우 이때 수립된 연결이 끊어지지 않고 유지되었다 11020 단계의 통신을 위해 사용될 수 있다. 몇 가지 가능한 예는 아래와 같다.

-- 소스 단말은 7040 단계를 마친 후 연결을 유지한 채 대기하고 있을 수 있다. 이후 RSP 서버가 프로파일의 상태 변경을 요청하기 위해 11020 단계를 수행할 수 있다. (예를 들어, RSP 서버가 푸쉬(Push) 방식을 이용할 수 있다.)

-- 도면에 도시되지는 않았지만, 소스 단말은 7040 단계를 마친 후 RSP 서버가 보낼 프로파일의 상태 변경 메시지가 있는지 확인하기 위해 메시지를 보낼 수 있다. 만일 RSP 서버가 보낼 프로파일의 상태 변경 메시지가 있다면 11020 단계가 수행될 수 있다. 만일 RSP 서버가 프로파일의 상태 변경 메시지를 보낼 일이 없다고 결정하면 11020 단계 이후의 과정은 생략될 수 있다. 만일 RSP 서버가 소스 단말의 확인 요청 메시지를 받은 시점에 아직 프로파일의 상태 변경 메시지를 보내야 하는지 결정하지 못했을 경우 RSP 서버는 프로파일의 상태 변경 메시지를 보내야 하는지 결정이 될 때까지 기다렸다 11020 단계를 수행할 수 있다. 혹은 만일 RSP 서버가 소스 단말의 확인 요청 메시지를 받은 시점에 아직 프로파일의 상태 변경 메시지를 보내야 하는지 결정하지 못했을 경우 RSP 서버는 조금 더 기다려야 한다는 메시지를 소스 단말에게 보낼 수 있고, 소스 단말은 다시 프로파일의 상태 변경 메시지가 있는지를 확인하기 위해 RSP 서버로 확인 메시지를 보낼 수 있다. (즉, 다양한 방식의 폴링(Polling) 방식이 이용될 수 있다.

- 도 4의 4010 단계가 수행되지 않았거나, 4010 단계가 수행되었더라도 소스 단말과 RSP 서버의 연결이 끊어졌다면, 소스 단말과 RSP 서버 사이에 새로운 연결이 수립될 수 있다. 몇 가지 가능한 예는 아래와 같다.

-- 소스 단말이, 자동으로 혹은 사용자의 요청에 의해, 먼저 RSP 서버와의 연결을 시도하고, 이후 수립된 연결을 통해 11020 단계가 수행될 수 있다.

-- RSP 서버가 소스 단말로 푸쉬(Push) 등의 방식을 통해 11020 단계를 수행할 수 있다.

-- RSP 서버(1190)가 프로파일의 상태 변경 요청이 있음을 다른 RSP 서버 (예를 들면, 디스커버리(DS) 서버)에 등록해 놓고, 소스 단말은 이 다른 RSP 서버로부터 RSP 서버(1190)에 접속해야 함을 확인한 뒤 RSP 서버(1190)에 접속함으로써 11020 단계가 수행될 수 있다.

RSP 서버(1190)가 소스 단말(1110)로 전송하는 프로파일의 상태 변경 요청 메시지는 다음의 사항 중 하나 이상을 포함할 수 있다.

- 상태 변경을 요청할 프로파일의 프로파일 구분자

- RSP 서버의 정보 (예를 들어, RSP 서버를 지칭하는 OID)

- 소스 단말의 eUICC 식별자

- 원하는 변경 방법

-- 프로파일을 삭제

-- 프로파일을 사용중지(suspended) 상태로 변경

- 상기 메시지의 일부 및/또는 전체에 대해 RSP 서버(1190)가 서명한 전자 서명 값.

도 11을 참조하면, 11025 단계에서 다음의 과정이 수행될 수 있다.

소스 단말은 RSP 서버의 상태 변경 요청에 따라 프로파일의 상태를 변경할 수 있다. 예를 들어 다음의 두 과정 중 하나가 수행될 수 있다.

- 해당 프로파일을 삭제

- 해당 프로파일을 사용중지(suspended) 상태로 설정

소스 단말은 RSP 서버로 자신이 수행한 상태 변경의 결과를 전송할 수 있다. 이때, 소스 단말이 RSP 서버로 전송하는 상태 변경 결과 메시지는 다음의 사항 중 하나 이상을 포함할 수 있다.

- 상태 변경을 한 프로파일의 프로파일 구분자

- RSP 서버의 정보 (예를 들어, RSP 서버를 지칭하는 OID)

- 소스 단말의 eUICC 식별자

- 수행한 상태 변경 결과

-- 프로파일을 삭제

-- 프로파일을 사용중지(suspended) 상태로 변경

- 상기 메시지의 일부 및/또는 전체에 대해 소스 단말이 서명한 전자 서명 값.

소스 단말이 RSP 서버로 전송하는 상태 변경 결과 메시지는 다양한 방식으로 전송될 수 있다. 몇 가지 가능한 예는 아래와 같다.

- 111020 단계에 대한 응답 메시지로 전송

- 독립적인 고지 과정(notification procedure)을 통해 전송

도 11을 참조하면, 11030 단계에서 RSP 서버(1190)는 타겟 단말(1110)로 프로파일의 상태 변경을 요청할 수 있다. 상세한 과정은 아래와 같다.

RSP 서버(1190)와 타겟 단말(1150)이 통신을 위해 연결을 수립하는 과정은 다양한 방법으로 개시될 수 있다. 몇 가지 가능한 예는 아래와 같다.

- 111015 단계 이후에도, 타겟 단말과 RSP 서버 사이에 수립된 연결이 끊어지지 않고 유지되었을 경우 이 연결이 재사용될 수 있다. 몇 가지 가능한 예는 아래와 같다.

-- 타겟 단말은 11015 단계를 마친 후 연결을 유지한 채 대기하고 있을 수 있다. 이후 RSP 서버가 프로파일의 상태 변경을 요청하기 위해 11030 단계를 수행할 수 있다.

--도면에 도시되지는 않았지만, RSP 서버는 11015 단계 이후 타겟 단말로 대기를 요청하는 메시지를 보낼 수 있다. 이후 RSP 서버가 프로파일의 상태 변경을 요청해야 할 시점에 11030 단계를 수행할 수 있다.

-- 도면에 도시되지는 않았지만, RSP 서버는 11015 단계 이후 타겟 단말로 대기를 요청하는 메시지를 보낼 수 있다. 이후 타겟 단말은 RSP 서버가 보낼 프로파일의 상태 변경 메시지가 있는지 확인하기 위해 메시지를 보낼 수 있다. 만일 RSP 서버가 보낼 프로파일의 상태 변경 메시지가 있다면 11030 단계가 수행될 수 있다. 만일 RSP 서버가 프로파일의 상태 변경 메시지를 보낼 일이 없다고 결정하면 11030 단계 이후의 과정은 생략될 수 있다. 만일 RSP 서버가 타겟 단말의 확인 요청 메시지를 받은 시점에 아직 프로파일의 상태 변경 메시지를 보내야 하는지 결정하지 못했을 경우 RSP 서버는 프로파일의 상태 변경 메시지를 보내야 하는지 결정이 될 때까지 기다렸다 11030 단계를 수행할 수 있다. 혹은 만일 RSP 서버가 타겟 단말의 확인 요청 메시지를 받은 시점에 아직 프로파일의 상태 변경 메시지를 보내야 하는지 결정하지 못했을 경우 RSP 서버는 조금 더 기다려야 한다는 메시지를 타겟 단말에게 보낼 수 있고, 타겟 단말은 다시 프로파일의 상태 변경 메시지가 있는지를 확인하기 위해 RSP 서버로 확인 메시지를 보낼 수 있다. (즉, 다양한 방식의 폴링(Polling) 방식이 이용될 수 있다.

- 111015 단계 이후 타겟 단말과 RSP 서버의 연결이 끊어졌다면, 타겟 단말과 RSP 서버 사이에 새로운 연결이 수립될 수 있다. 몇 가지 가능한 예는 아래와 같다.

-- 타겟 단말이, 자동으로 혹은 사용자의 요청에 의해, 먼저 RSP 서버와의 연결을 시도하고, 이후 수립된 연결을 통해 11030 단계가 수행될 수 있다.

-- RSP 서버가 타겟 단말로 푸쉬(Push) 등의 방식을 통해 11030 단계를 수행할 수 있다.

-- RSP 서버(1190)가 프로파일의 상태 변경 요청이 있음을 다른 RSP 서버 (예를 들면, 디스커버리(DS) 서버)에 등록해 놓고, 타겟 단말은 이 다른 RSP 서버로부터 RSP 서버(1190)에 접속해야 함을 확인한 뒤 RSP 서버(1190)에 접속함으로써 11030 단계가 수행될 수 있다.

RSP 서버(1190)가 타겟 단말(1150)로 전송하는 프로파일의 상태 변경 요청 메시지는 다음의 사항 중 하나 이상을 포함할 수 있다.

- 상태 변경을 요청할 프로파일의 프로파일 구분자

- RSP 서버의 정보 (예를 들어, RSP 서버를 지칭하는 OID)

- 타겟 단말의 eUICC 식별자

- 원하는 변경 방법

-- 프로파일을 사용 가능한 상태로 만들 것. 예를 들어 다음의 두 상태 변경이 가능하다.

--- 프로파일을 활성화 상태(enabled) 상태로 변경할 것

--- 프로파일을 비활성화 상태(disabled) 상태로 변경할 것

도 11을 참조하면, 11035 단계에서 다음의 과정이 수행될 수 있다.

타겟 단말은 RSP 서버의 상태 변경 요청에 따라 프로파일의 상태를 변경할 수 있다. 즉, 소스 단말은 RSP 서버의 상태 변경 요청에 따라 프로파일을 사용 가능한 상태로 설정할 수 있다. 예를 들어 다음의 두 과정 중 하나가 수행될 수 있다.

- 해당 프로파일을 활성화 상태로 설정

- 해당 프로파일을 비활성화 상태로 설정

타겟 단말은 RSP 서버로 자신이 수행한 상태 변경의 결과를 전송할 수 있다. 이때, 타겟 단말이 RSP 서버로 전송하는 상태 변경 결과 메시지는 다음의 사항 중 하나 이상을 포함할 수 있다.

- 상태 변경을 한 프로파일의 프로파일 구분자

- RSP 서버의 정보 (예를 들어, RSP 서버를 지칭하는 OID)

- 타겟 단말의 eUICC 식별자

- 수행한 상태 변경 결과

-- 프로파일을 사용 가능한 상태로 설정. (예를 들어 다음의 두 결과가 가능하다.)

--- 프로파일을 활성화 상태로 설정

--- 프로파일을 사용중지(suspended) 상태로 설정

- 상기 메시지의 일부 및/또는 전체에 대해 타겟 단말이 서명한 전자 서명 값.

타겟 단말이 RSP 서버로 전송하는 상태 변경 결과 메시지는 다양한 방식으로 전송될 수 있다. 몇 가지 가능한 예는 아래와 같다.

- 111030 단계에 대한 응답 메시지로 전송

- 독립적인 고지 과정(notification)을 통해 전송

도 12은 본 개시의 일 실시 예에 따른 eUICC가 탑재된 단말의 구성을 도시하는 도면이다.

도 12을 참조하면, 단말은 송수신부(1210), 프로세서(1220) 및 eUICC(1230)를 포함할 수 있다. 본 개시에서 상술한 일부 단말들은 도 12에서 설명하는 단말에 대응될 수 있다. 다만, 단말의 구성은 도 12에 제한되지 않으며, 도 12에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일 실시예에 따르면, 송수신부(1210), 프로세서(1220) 및 eUICC(1230)는 하나의 칩(Chip) 형태로 구현될 수 있다. 또한, 단말은 메모리를 추가로 포함할 수 있고, 프로세서(1220)는 적어도 하나의 프로세서로서 구성될 수 있다.

다양한 실시예에 따르면, 송수신부(1210)는 다른 단말의 송수신부 혹은 외부 서버와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(1210)는 송신되는 신호의 주파수를 상승 변환(up converting) 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환(down converting)하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(1210)의 일 실시예일뿐이며, 송수신부(1210)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(1210)는 무선 채널을 통해 신호를 수신하여 프로세서(1220)로 출력하고, 프로세서(1220)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.

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

한편, 단말은 메모리(미도시)를 더 포함할 수 있으며, 단말의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(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) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(1220)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.

도 13는 본 개시의 일 실시 예에 따른 RSP 서버의 구성을 도시하는 도면이다.

도 13를 참조하면, 서버는 송수신부(1310) 및 프로세서(1320)를 포함할 수 있다. 본 개시에서 상술한 일부 서버(들)은 도 13에서 설명하는 서버에 대응될 수 있다. 다만, 서버의 구성은 도 13에 제한되지 않으며, 도 13에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일 실시예에 따르면, 송수신부(1310) 및 프로세서(1320)는 하나의 칩(chip) 형태로 구현될 수 있다. 또한, 서버는 메모리를 추가로 포함할 수 있고, 프로세서(1320)는 적어도 하나의 프로세서로서 구성될 수 있다.

일 실시예에 따르면, 송수신부(1310)는 단말과 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(1310)는 송신되는 신호의 주파수를 상승 변환 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(1310)의 일 실시 예일 뿐이며, 송수신부(1310)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(1310)는 무선 채널을 통해 신호를 수신하여 프로세서(1320)로 출력하고, 프로세서(1320)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.

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

한편, 서버는 메모리(미도시)를 더 포함할 수 있으며, 서버의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(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) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(1320)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.

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

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

본 개시의 다양한 실시 예들 및 이에 사용된 용어들은 본 개시에 기재된 기술을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 및/또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 본 개시에서, "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)(예: 내장 메모리 또는 외장 메모리)에 저장된 명령어를 포함하는 소프트웨어(예: 프로그램)로 구현될 수 있다. 기기는, 저장 매체로부터 저장된 명령어를 호출하고, 호출된 명령어에 따라 동작이 가능한 장치로서, 다양한 실시 예들에 따른 단말을 포함할 수 있다. 상기 명령이 프로세서(예: 도 14의 프로세서(1420))에 의해 실행될 경우, 프로세서가 직접, 또는 상기 프로세서의 제어 하에 다른 구성요소들을 이용하여 상기 명령에 해당하는 기능을 수행할 수 있다. 명령은 컴파일러 또는 인터프리터에 의해 생성 또는 실행되는 코드를 포함할 수 있다.

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

본 개시에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 온라인상으로 배포될 수 있다. 온라인상 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.다양한 실시 예들에 따른 구성 요소(예: 모듈 또는 프로그램) 각각은 단수 또는 복수의 개체로 구성될 수 있으며, 전술한 해당 서브 구성 요소들 중 일부 서브 구성 요소가 생략되거나, 또는 다른 서브 구성 요소가 다양한 실시 예에 더 포함될 수 있다. 대체적으로 또는 추가적으로, 일부 구성 요소들(예: 모듈 또는 프로그램)은 하나의 개체로 통합되어, 통합되기 이전의 각각의 해당 구성 요소에 의해 수행되는 기능을 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따른, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적, 병렬적, 반복적 또는 휴리스틱하게 실행되거나, 적어도 일부 동작이 다른 순서로 실행되거나, 생략되거나, 또는 다른 동작이 추가될 수 있다.

Claims

무선 통신 시스템에서 제어 신호 처리 방법에 있어서,
기지국으로부터 전송되는 제1 제어 신호를 수신하는 단계;
상기 수신된 제1 제어 신호를 처리하는 단계; 및
상기 처리에 기반하여 생성된 제2 제어 신호를 상기 기지국으로 전송하는 단계를 포함하는 것을 특징으로 하는 제어 신호 처리 방법.