KR20210147822A - 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치 - Google Patents

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 발명은 기기 간의 프로파일 이동 시 사용자가 어떤 단말에서 기기 변경을 시작하더라도 사용자의 기기 변경 시작 단말과 사업자 지원 방식을 조합하여 편리한 기기간 통신서비스 이동이 가능하도록 하기 위한 방법 및 장치를 제안한다. 특히, 본 발명의 일 실시 예에 따르면, 제1 단말에 설치된 제1 프로파일을 이동시키는 입력이 수신 되는 단계, 제1 단말에서 통신사업자의 기기 변경 방식을 프로파일 메타데이터 또는 Configuration Server 또는 단말 메모리로부터 확인하여 ODSA 방식임을 결정하는 단계, ECS가 기기 변경을 위한 가입자 인증 방식으로 ECS/DP+인증 방식을 결정하여, ECS 생성 Nonce, SM-DP+주소와 함께 단말에 송신하는 단계, ECS가 제 1 단말로부터 SM-DP+에서 처리한 인증 결과 데이터를 회신 받아서 해당 데이터에 포함된 ECS 생성하여 전달한 Nonce와 SM-DP+서버의 서명 데이터를 GSMA Root CI 인증서를 통해서 검증하는 단계, 검증되면 Activation Code를 단말에 제공하고 제 1 단말의 화면에 QR 코드로 Display하는 단계를 포함하는 방법을 제공할 수 있다.

Description

이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치 {METHOD AND APPARATUS TO TRANSFER NETWORK ACCESS INFORMATION BETWEEN DEVICES IN MOBILE COMMUNICATION SYSTEM}

본 발명은 무선 통신 시스템에서 하나의 기기에 설치된 통신 시스템에 접속하기 위한 접속 정보를 다른 기기에 이전 재설치 하는 방법 및 장치에 관한 것이다.

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)는 이동 통신 단말기 등에 삽입하여 사용하는 스마트카드 (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 모듈정보를 통칭하여 eSIM 프로파일 이라는 용어로 사용하겠다. 즉 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하는 UICC 카드 및 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용한다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 프로파일(Profile) 이라는 용어로 사용하겠다.

한편, 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드하여 통신 서비스를 개통할 수 있는 이점을 충분히 활용하고자, 통신사업자들은 단말에서 On Device Service Activation 서비스를 도입하고 있다. On Device Service Activation은 사용자가 단말기에서 웹 포탈 또는 앱을 통해서 신규 통신 서비스 가입 및 개통, 기기 변경 시 통신서비스 이전 설치 개통 등을 가능하게 하는 솔루션을 통칭한다. On Device Service Activation 서비스는 ODSA 또는 ODA라는 용어로 혼용될 수 있다. 또한 ODSA를 지원하기 위해 단말에 설치가 필요한 모듈을 ODSA Client라고 하는데, ODSA 또는 ODA라는 용어와 혼용되어 사용할 수 있다.

서비스 사업자는 단말 또는 특정 서비스를 사용하고자 하는 가입자가 해당 서비스를 접근/사용할 권한이 있는지를 판단하기 위해서 Entitlement Configuration Server(ECS)를 도입할 수 있다. ECS는 요청 단말에서 통신 기반 서비스 제공이 가능한지를 해당 단말 사용자의 가입자 정보 및 단말의 네트워크 상태를 고려해 판단하고, 가능하다고 판단한 경우, 해당 단말에서 통신 기반 서비스를 제공하기 위한 소정의 정보를 단말에 전송할 수 있다. ECS는 현재 VoLTE(Voice over LTE), VoWiFi(Voice over Wi-Fi), ODSA(On Device Service Activation) 등 서비스를 위해 도입되고 있다. ODSA에서 ECS는 단말의 ODSA Client가 접근하는 사업자의 ODSA Gateway 서버로의 역할을 수행하며, ODSA Client와 ECS간 메시지 프로토콜은 GSMA(GSM Association, 통신사업자연합)에서 TS.43 규격에 정의하고 있다. ECS 주소는 다양하게 표기될 수 있으나, 표기의 한 예로는 FQDN(Full Qualified Domain Name)으로 통신사업자의 고유 식별 번호인 MCC와 MNC 조합에 따른 ase.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org 와 같이 생성하여 사용할 수 있다. <MNC>와 <MCC>는 각 해당 MNC와 MCC의 decimal format으로 만약 해당 정보가 2자리 수인 경우에 0을 맨 앞에 추가하여 3자리 수로 사용할 수도 있다.

단말기 교체 시, 통신 서비스 가입자는 상기 SIM 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 상기 UICC 카드에 저장된 인증정보를 이용하여 이동통신망 접속을 그대로 사용할 수 있다. 그러나 상기 eUICC를 탑재한 단말의 경우, 다운로드된 프로파일은 해당 eUICC 내부에서만 복호화되어 설치되는 것으로, 설치된 후에는 다시 단말 외부로 추출될 수 없어 새 단말에서 프로파일 다운로드 및 (재) 설치가 필요하다.

본 발명을 개시하는 시점에 통신사업자들은 eUICC 탑재 단말기의 기기 변경 시 통신서비스를 이전 설치를 제공하고자 LPA와 SM-DP+를 사용하는 방식과 ODSA Client와 ECS를 사용하는 방식을 GSMA 표준화하고 있으며, 통신사업자들은 해당 방식 중 하나를 선택하여 통신서비스 이전 설치를 지원할 것으로 예상된다. 하지만, 현재 각 방식에 따라 기존 단말(프로파일이 설치되어 있는 기존 단말) 또는 변경할 신규 단말에서만 지원 가능하여 사용자의 시작 단말과 사업자의 지원 방식의 조합에 따라서, 사용자가 통신서비스를 이전 설치하지 못한다는 불편함이 있다. 이는 도 2에서 추가적으로 설명하겠다.

한편 기존에 이동통신사는 SIM 카드 분실 시, 가입자의 신원 또는 ID 인증 과정을 확인하여, SIM카드를 재발급하는 절차를 제공하고 있으며, eUICC 탑재 단말기의 기기 교체 시 신규 단말기의 eUICC로 프로파일을 다운로드하는 용도에 적용이 가능하다. 하지만, 이러한 과정은 통상 가입자가 오프라인 영업점에 방문한 경우에만 처리해 주거나 온라인으로 처리할 경우에는 오프라인 영업점 대비 더욱 엄격한 신원 인증 또는 ID 확인 과정이 요구된다. 단말기 변경 시 가입자는 프로파일을 신규 단말기에 재설치를 위해서, 이러한 엄격한 신원 인증 또는 ID 확인 과정을 거쳐야 하는 불편이 있다. 가입자가 기존 단말기를 보유하고 있는 경우, 통신사업자는 통신서비스에서 가입자 인증을 위해 통신사업자가 보편적으로 사용하는 방식으로 EAP-AKA 방식을 사용하여 가입자 인증을 할 수도 있으나, 이는 SIM 모듈이 활성화되어 SIM 정보에 접근이 가능한 상태여야 인증이 가능하며 SIM 모듈이 비활성화 되어 있는 경우에 사용할 수 없다.

본 발명이 이루고자 하는 기술적 과제는, 통신 시스템에서 기존 단말에서 사용하던 통신 서비스를 교체된 신규 단말로 이전 재 설치/개통하여 사용하게 하는 것이다. 이를 위해, 기존 단말의 eUICC에 저장된 프로파일에 대응되는 신규 eUICC 프로파일을 온라인으로 다운로드 하여 설치할 때, 사용자 시작 단말과 사업자 지원 방식의 조합을 고려해 기기 변경 방식을 선택하는 것이다. 특히, 기존 단말에서의 ODSA 방식 지원, 신규 단말에서의 LPA 방식 지원을 지원하는 방법을 포함해 제공하고자 한다. 또한, SIM 모듈이 비 활성화 되어 있는 경우에도 제공 가능한, 별도의 가입자 ID 인증이 필요 없는 다운로드 방안을 제공하고자 한다.

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

상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 다음 제1 단말의 방법은, 설치된 제1 프로파일을 이동시키는 입력이 수신되는 단계, 통신사업자의 기기변경 지원 유무 및 지원 방식 정보를 획득하는 단계, 프로파일 서버 인증 방식 지원을 포함한 가입자 인증 방식 선택에 필요한 소정의 정보를 ECS에 전송하는 단계, ECS로부터 프로파일 서버로 가입자 인증 처리에 대한 ECS 요청 임을 증빙하는 ECS 생성 데이터와 프로파일 서버 주소를 획득하는 단계, 프로파일 서버를 통해 가입자 인증을 수행하고 이를 ECS에 회신하는 단계를 포함한다.

상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 단말의 방법은, 사용자 시작 단말과 사업자 지원 방식을 확인하여 단말에서 사용할 사업자 지원 방식을 결정하는 단계, 단말에서 지원 가능한 사용자 인증 방식을 수집하여 ECS 서버에 송신하는 단계를 포함한다.

상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 ECS의 방법은, 제 1단말이 제공하는 가능한 인증 방식 정보를 참조하여 인증 방식을 선택하는 단계, 선택된 인증 방식에 따라 인증에 활용할 소정의 데이터를 생성하여 단말에 전송하는 단계, 단말로부터 수신한 사용자의 인증 결과를 검증하는 단계, 검증 결과에 따라 기기 변경에 필요한 일련의 절차를 처리하고 프로파일 다운로드에 필요한 소정의 정보를 제 1 단말에 전송하는 단계를 포함한다.

상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 프로파일 서버의 방법은, ECS에서 생성한 데이터가 포함된 가입자 인증 요청을 제 1단말 로부터 수신하는 단계, 가입자 인증을 수행하여 제 1 단말에 회신하는 단계를 포함하다.

상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 제 2 단말의 방법은, ECS가 제 1 단말에 전송한 소정의 정보를 제 1 단말로부터 획득하는 단계, 해당 소정의 정보를 프로파일 서버에 전송하여 프로파일을 수신하여 설치하는 단계를 포함한다.

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

본 발명의 실시 예에 따르면, 통신사업자의 eSIM 단말의 기기 변경 시 통신서비스를 이전 설치하는 방법에 있어서, 통신사업자의 기기 변경 지원 방식과 사용자의 기기 변경 시작 단말의 조합을 고려하여 사용자에게 Seamless한 UI/UX를 제공해 줄 수 있다. 또한, 사용자가 eUICC를 탑재한 단말의 단말 교체 시, 사용자의 신원 인증 정보에 대한 추가적인 정보 입력 없이, 단말과 ECS가 USIM 또는 프로파일 서버와의 인증 정보를 활용하여 편리하게 기기 간 프로파일을 이동할 수 있다. 특히, USIM 인증이 불가능한 경우에도 사용자에게 ID 입력을 요구하지 않고, 프로파일 서버와의 인증 정보를 활용하여 편리하게 기기 간 프로파일을 이동할 수 있다. 또한, 통신 사업자는 필요에 따라 기존 단말에 설치된 프로파일을 삭제 처리하여 추후 프로파일을 재사용할 수 있다.

도 1은 본 발명의 실시 예가 적용되는 통신 시스템의 구성을 나타낸 도면이다.
도 2는 eSIM 기기 변경에 대한 통신사의 통신 서비스 이동 지원 방식과 사용자 시작 단말의 조합에 따른 기기 변경 지원 여부를 도시한다.
도 3은 eSIM 기기 변경 절차 처리 절차 및 단말의 판단 기준을 나타낸 도면이다.
도 4는 단말에서 사업자의 eSIM 기기 변경 설정 정보를 획득하는 방법을 도시한다.
도 5a는 통신사가 ODSA 방식을 제공하며 EAP-AKA 인증을 사용하는 실시 예를 나타내는 도면이다.
도 5b는 통신사가 ODSA 방식을 제공하며 ECS/SM-DP+ 인증을 사용하는 실시 예를 나타내는 도면이다.
도 5c는 통신사가 LPA 방식을 제공하며 사용자가 기기 변경을 시작 시 UI/UX에 대한 절차를 나타낸 실시 예를 나타내는 도면이다.
도 5d는 제 1단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience)에 대한 대표적인 처리 절차를 나타낸 도면이다.
도 6a는 통신사가 ODSA 방식을 제공하며 OTP 또는 OAuth/Open ID 인증을 사용하는 실시 예를 나타내는 도면이다.
도 6b는 통신사가 LPA 방식을 제공하며 제 1단말(구 단말)에서 LPA와 SM-DP+인증을 사용하는 실시 예를 나타내는 도면이다.
도 6c는 제 2단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience)에 대한 대표적인 처리 절차를 나타낸 도면이다.
도 7은 본 발명의 실시 예에 따른 무선 통신 시스템에서 단말의 블록 구성을 도시한다.

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

이하, 기지국은 단말의 자원할당을 수행하는 주체로서, 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는 이동통신 단말기에 삽입하여 사용하는 스마트카드로서 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS와 같은 개인정보가 저장되어 GSM, WCDMA, LTE, 5G 등과 같은 이동통신 시스템에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미한다. 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 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.

본 명세서에서 프로파일서버는 프로파일을 생성하거나, 생성된 프로파일을 암호화 하거나, 프로파일 원격관리 명령어를 생성하거나, 생성된 프로파일 원격관리 명령어를 암호화하는 기능을 포함하고, SM-DP(Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), SM-SR (Subscription Manager Secure Routing)으로 표현될 수 있다.

본 명세서에서 사용하는 용어 '단말' 또는 '기기'는 이동국(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 또는 eUICC를 제어하도록 단말 또는 기기 내에 설치된 소프트웨어 또는 애플리케이션을 포함할 수 있다. 상기 소프트웨어 또는 애플리케이션은, 예를 들어 Local Profile Assistant(LPA)라 지칭할 수 있다. 본 명세서에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC의 고유 식별자일 수 있고, EID로 지칭될 수 있다.

본 명세서에서 APDU(application protocol data unit)는 단말 또는 기기내의 Controller가 eUICC와 연동하기 위한 메시지 일수 있다.

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

본 명세서에서 AKA는 인증 및 키 합의 (Authentication and Key agreement)로, 3GPP 및 3GPP2망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다. K 는 AKA 인증 알고리즘에 사용되는 eUICC에 저장되는 암호키 값이며, 본 명세서에서 OPc는 AKA 인증 알고리즘에 사용되는 eUICC에 저장될 수 있는 파라미터 값이다.

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

본 명세서에서 ECS는 Entitlement Configuration Server, 가입증명서버, 가입서버, 자격증명서버, Entitlement Server(ES)와 혼용되어 사용될 수 있고 ODSA Client는 ODSA, ODA와 혼용되어 사용될 수 있다.

본 발명에서 End-user, 사용자, 가입자, 서비스 가입자, user는 기기 변경을 수행하는 자를 의미하며 혼용되어 사용될 수 있다.

본 발명에서 eSIM Transfer, 기기 변경, subscription Transfer, 통신서비스의 단말간 가입 정보 이동, 기기변경 시 프로파일 이동은 eUICC를 탑재한, 제 1단말에서 제 2단말로 기기 변경 시 USIM카드 이동에 상응하는 프로파일 이동을 의미하며, 혼용되어 사용될 수 있다. 이는 문맥에 따라 해석되어야 한다.

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

이하에서는 도면들을 통해 제안하는 실시 예를 설명한다.

도 1은 본 발명의 실시 예가 적용되는 통신 시스템의 구성을 나타낸 도면이다.

도 1에서 연두색으로 표기된 부분은 GSMA TS.43에 정의된 표준 Entity 및 Interface 를 나타내며, 파란색으로 표기된 부분은 GSMA.22에 정의된 표준 Entity 및 Interface를 나타낸다. 본 발명에서 End User(100)은 기기간 프로파일 이동을 수행하는 사용자이며, Device(105)는 무선통신서비스가 가능한 단말 또는 기기를 의미한다. 해당 Device(105)는 LPA(140), eUICC(160)을 포함하며, ECS와의 Entitlement Configuration 교환을 지원하는 경우에, ODSA Client(110)을 포함한다. LPA(140)와 SM-DP+는 GSMA SGP.22에 정의된 표준 Entity로써, LPA는 eUICC에 프로파일을 다운로드 및 설치, 기기 변경 시 프로파일을 타 프로파일로 이동에 관여할 수 있다. 단말(105)은 사용자(100)로부터 프로파일 이동에 대한 Input을 ODSA Client(110) 또는 LPA(140)로부터 입력 받아 단말에서 기기 변경 절차를 시작할 수 있다. 이 때, 단말은 사전에 정의된 기기변경을 지원 여부 및 처리 방식 등에 대한 소정의 정보가 없는 경우에, 해당 정보를 획득하기 위해 별도 서버인 Configuration Server(170)에 접속하여 단말의 기기 변경 방식 결정에 필요한 전체 또는 일부 정보를 획득하여 활용할 수 있다. 해당 Configuration Server(170)는 단독 또는 통신사업자의 BSS/OSS(130)의 하나로 구현될 수도 있다. MNO(Mobile Network Operator) BSS/OSS(130)는 통신사업자가 통신서비스의 운영 및 처리를 위한 서버 시스템으로 통신사의 Back-end System이라고 불리기도 하며, 본 발명의 일부 설명에서 MNO BSS/OSS(130)와 통신사업자가 혼용해서 사용될 수 있다. MNO BSS/OSS는 프로파일 서버인 SM-DP+(150)서버 또는 서비스 가입 관리를 처리하는 서버인 ECS(120)와 정보 교환을 통해서 eUICC 기기에서의 통신서비스의 가입 및 해지, 기기 변경에 대한 처리를 수행할 수 있다. ECS(120)과 SM-DP+(150)서버는 통신사업자의 Back-end 시스템과 연동되고 통신 서비스의 Back-end 시스템과 독립 또는 Back-end 시스템의 일부로 구현되어 있을 수도 있다. ODSA Client(110)와 LPA(140)는 하나의 애플리케이션에 통합 구현 또는 개별적으로 구현될 수 있다. 도 1에서 Configuration Server(170)은 ODSA Client(110)와 연결된 것으로 표기되어 있으나, 이에 한정하지 아니하고 단말의 다른 애플리케이션 또는 LPA에서도 직접 Configuration Server(170)에 접속하여 기기 변경 처리를 위한 정보를 획득해 이후 절차를 처리할 수 있다.

도 2는 eSIM 기기 변경에 대한 통신사의 통신 서비스 이동 지원 방식과 사용자 시작 단말의 조합에 따른 기기 변경 지원 여부를 도시한다.

전술한 바와 같이 eUICC 단말(200)의 기기 변경 시 통신 서비스를 이전 설치하는 방법에 있어서 2가지 방식이 혼재할 것으로 보이며, 사업자는 이 중 한 가지 방식을 선택하여 지원할 것으로 예상된다. As-Is 표(200)는 본 발명을 개시하는 시점에서 사용자 시작 단말과 사업자 지원 방식의 조합을 고려하여 제공 가능한 방법을 나타낸 것이다. 사업자 지원 방식이 ODSA 방식이며 제 1단말(300)에서 사용자가 기기변경을 시작하는 것에 대하여 사업자가 제공하지 않고 있으며, 해당 처리 절차에 대해서도 TS. 43 표준에 정의된 바가 없다. 한편, 사업자 지원 방식이 LPA 방식이며 제 2단말(350)에서 사용자가 기기변경을 시작하는 경우에, 해당 제 2단말(350)에서 이를 처리하기 위한 방법이 없다. LPA 방식은 해당 단말에 기 설치되어 이동하고자 하는 프로파일의 ICCID 정보를 사용하므로, 제 2단말(350)에서 현재는 지원할 수 없는 방식이나, 사용자(100)가 제 1단말(100)을 사용 가능한 경우에 해당 단말을 통해서 처리할 수 있도록 하여 사용 가능할 수 있다. 하지만, 현재 본 발명을 개시하는 시점에서 단말에서는 해당 처리 방법을 제공하지 않고 있다. 따라서 본 발명을 도입했을 때 제공하고자 하는 기기 변경의 방법은 To-Be 표(210)와 같다. AS-IS표(210)에서 미지원 즉, FAIL로 표기된 부분에 대해서 본 발명을 통해서 모두 지원할 수 있고, 이를 위해서 도 5와 도 6을 통해 이를 지원할 경우의 UI/UX와 Call Flow를 도시하였다.

도 3은 eSIM 기기 변경 절차 처리 절차 및 단말의 판단 기준을 나타낸 도면이다.

먼저, 기기 변경 시 프로파일 이동을 진행함에 있어 단말(105)는 사용자가 기기 변경에 대한 이벤트를 발생시키는 단말이 기존 프로파일을 이동시키고자 하는 기존 단말인지 또는 프로파일을 재설치 받을 신규 단말인지 유무(300,350)를 판단할 수 있다. 이하 설명의 편의를 위해, 기존 프로파일을 이동하고자 하는 단말은 제 1단말 (300), 프로파일을 재설치 받을 단말은 제 2단말 (350)이라고 칭하기로 한다. 제 1단말과 제2단말의 구분이 필요 없는 경우에, Device(105)로 사용할 수 있다. Device(105)는 사용자(100) 진입 메뉴를 분리하여 사용자가 제 1단말인지 또는 제 2단말에서 진입하는지 식별할 수 있다. Device(105)에서 사용자가 기기 변경 메뉴를 선택하여 기기 변경에 대한 요청이 입력(300)되면, Device(105)는 도 4에서 후술한 바와 같이 Configuration Server(170)또는 단말에 사전 저장된 정보 또는 프로파일의 메타데이터를 통해서 수집된 정보를 확인하여 해당 프로파일에 대한 통신사업자의 기기 변경 지원 유무(305) 및 지원 방식(310)을 확인하고, 기기 변경을 수행함에 있어 해당 기기 변경 요청 단말(105)이 제 1단말(300)인지 2단말(350)인지를 포함하여 단말의 상태를 확인하여, 단말(105)에서 사용할 통신 서비스의 기기 변경 방식을 최종 결정(310)할 수 있다. 기기 변경의 지원 유무(305)라 함은 제 1단말(300)의 eUICC에 기 설치된 프로파일을 제 2단말(350)에 동일 또는 동일한 통신서비스 가입 설정을 가지는 프로파일로 다운로드 가능한지 여부에 대하여 판단하는 것을 의미한다.

해당 프로파일에 대한 통신사업자의 기기 변경 지원 유무(305) 및 지원 방식(310)을 확인하여, 단말(105)은 통신사업자의 해당 프로파일에 대한 기기 변경 지원 방식으로 ODSA Client와 ECS를 활용한 기기 변경 방식을 지원하는지, LPA와 SM-DP+ 서버를 활용한 기기 변경 방식을 지원하는 지에 대한 정보를 획득할 수 있다. 통신 사업자는 상기 언급한 2개의 기기 변경 방식 중에 1개 이상의 기기변경 방식 지원을 지원할 수 있다. 만약 단말에서 수집한 해당 통신사업자의 이동하고자 하는 프로파일에 대한 기기 변경 지원 방식이 1개 보다 많은 경우에 통신사업자는 해당 기기 변경 방식 적용에 대한 우선 순위에 대한 정보를 추가적으로 프로파일 메타데이터 또는 Configuration Server(170)에 저장해 두었다가 이를 단말에 제공하여 줄 수도 있다. 또한, 단말(105)은 사용자(100)에게 선택을 요청하는 화면을 표기하여 사용자가 선택하게 하거나, 단말 기본 설정에 의해서 해당 2개 방식 중에 하나를 골라서 적용해 사용할 수도 있다. ODSA Client와 ECS를 활용한 기기 변경 방식은 이후 설명의 편의를 위해 ODSA 방식, LPA와 SM-DP+ 서버를 활용한 기기 변경 방식은 LPA 방식으로 설명하며, 각 기기 변경 방식을 포함한 상세 절차는 도 5a 내지 도 5d와 도6a 내지 도 6c에서 상세 설명하기로 한다. 단말(105)이 상기와 같이 방식으로 획득한 정보에 따라 LPA 방식으로 처리해야 하는 경우에, 해당 기기 변경을 시작하는 단말(105)이 제 1 단말(300)인지 제 2 단말(350)인지 여부에 따라 이후 절차를 다르게 처리해야 한다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 LPA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 1 단말(300)인 경우, 단말의 LPA(140)가 SM-DP+(150)에 기기 변경을 할 프로파일에 대한 소정의 정보를 포함하여 프로파일 이동을 요청하는 Command를 요청할 수 있다. SM-DP+(150)는 통신사업자(130)에 해당 기기 변경 요청에 대해 통보하고, SM-DP+(150)는 통신사업자(130)와 GSMA SGP.22에 정의된 ES2+ Interface를 통해 제 2단말(350)에 기기 변경을 위해 다운로드를 해 줄 프로파일을 생성 처리할 수 있다. SM-DP+(150)는 이동할 프로파일이 설치되어 있는 제 1단말(300)의 eUICC(160)와 상호 간에 SM-DP+와 eUICC 인증서의 서명 값을 교환(Common Mutual Authentication)하여, 프로파일이 설치된 해당 단말 및 eUICC(160)를 인증하는 것으로, 가입자를 인증할 수 있다. 이하 설명의 편의를 위해 본 발명에서는 이 방식을 SM-DP+ 인증 방식(315)으로 부르기로 한다. SM-DP+ 인증을 통해 가입자가 인증되면, SM-DP+(150)는 제 2단말(350)이 생성한 프로파일을 다운로드 받기 위해 필요한 데이터를 제 1단말(300)로 회신할 수 있다. 제 1단말이 해당 데이터는 획득하여 QR코드 형태로 제 1단말(300)에 Display하면 제 2단말(350)은 해당 상기 제 1 단말의 화면에 Display된 QR코드를 스캔(340)하고, 해당 QR코드에 포함된 프로파일서버(150)로부터 상기 프로파일을 수신하여 설치하여 기기 변경에 따른 프로파일 이동 설치를 완료(390)할 수 있다. 제 1단말(300)은 정보를 QR코드로 Display하는 대신, 제 2단말(350)에 NFC, 블루투스, UWB 등의 근거리 통신이나 WiFi 통신, 서버를 경유해서 전달 할 수 있다. 그러나, 제 1단말(300)에서 QR코드로 Display 할 경우, 제 2단말(350)에서는 QR코드를 Scan 하는 통상의 eSIM 프로파일 다운로드 과정을 통해 프로파일을 설치할 수 있어서, 기존 프로파일 다운로드 절차의 수정 없이도 기기변경 동작을 수행하는데 장점이 있다. 이하 QR 코드를 사용하는 것으로 예를 들어 설명하지만, 본 발명의 실시 예가 이에 한정되지는 않는다. 다음은 QR코드로 Display할 프로파일을 다운로드 받기 위해 필요한 데이터의 일 구성 예를 보여준다.

LPA:x$SMDP.TEST.COM$XXXXX

상기 예시에서, SMDP.TEST.COM은 예시로 든 프로파일 서버 주소를 의미하며, $는 각 정보를 구분하는 구분자이며, LPA: 부분은 이 데이터가 프로파일 다운로드에 사용되는 Activation Code 포맷임을 의미하며, x부분은 Activation Code의 종류를 뜻하는 것으로 일 예로 이 값은 1 또는 2 또는 3 또는 4 등의 숫자일 수 있으며, XXXXX 부분은 ACToken(Activation Code Token) 영역의 데이터로 아래 ASN.1 Data의 일부분 또는 전부를 포함한 정보를 Encoding 한 정보일 수 있고 편의상 XXXXX로 표시한 것이다.

ASN.1 Data

OtherSignedNotification ::= SEQUENCE {

tbsOtherNotification NotificationMetadata,

euiccNotificationSignature [APPLICATION 55] OCTET STRING, -- eUICC signature of tbsOtherNotification, Tag '5F37'

euiccCertificate Certificate, -- eUICC Certificate (CERT.EUICC.ECDSA) signed by the EUM

eumCertificate Certificate -- EUM Certificate (CERT.EUM.ECDSA) signed by the requested CI

}

NotificationMetadata ::= [47] SEQUENCE { -- Tag 'BF2F'

seqNumber [0] INTEGER,

profileManagementOperation [1] NotificationEvent, /*Only one bit SHALL be set to 1*/

notificationAddress UTF8String, -- FQDN to forward the notification

iccid Iccid OPTIONAL

}

이 때 상기 Encoding은 1) 하기와 같은 ASN.1형식의 Data를 DER 방식으로 인코딩을 한 후 다시 Hexademical 인코딩을 하여 문자로 표현 가능하게 하는 방식 2) 하기와 같은 ASN.1형식의 Data를 DER 방식으로 인코딩을 한 후 다시 BASE64 인코딩을 하여 문자로 표현 가능하게 하는 방식일 수 있다. 이하 설명의 편의를 위해 프로파일을 다운로드 받기 위해 필요한 해당 데이터는 Activation Code로 통칭하여 사용하고자 한다. 한편, 도면에는 기술되지 않았지만, 제 1단말(300)에서 프로파일 이동을 위해 프로파일을 삭제하기 전, 제 1단말(300)은 제 2단말(350)의 기기정보 (예를 들면 eUICCInfo, DeviceInfo)를 획득 후, 프로파일서버에 이를 전달하여 제 2단말(350)에 프로파일 재설치가 가능한지를 체크한 후, 이후 과정을 진행할 수도 있다. 또한, 도면에서는 기술하지 않았으나, 제 1단말(300)에서 사용자 화면을 통해서 제 2단말(350)의 IMEI(International Mobile Equipment Identity)를 획득 및 입력을 요청하여(예를 들어, 단말 키패드에서 *#06#로 확인 등)하여 ECS 또는 LPA에 기기 변경 요청 전송 시 추가하여 전송할 수도 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 LPA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 2 단말(350)인 경우, 제 2단말(380)은 사용자에게 제 1 단말(300) 사용 여부에 따라 다른 절차를 안내할 수 있는 메뉴를 생성하여 화면에 표기한다. 제 1단말(300) 사용이 가능한 경우, 제 2단말(350)은 제 1 단말(300)에서 진행에 대한 안내 메시지를 띄우고 제 1단말(300)로부터 Display된 QR코드를 스캔할 수 있는 메뉴로 이동하여 대기할 수 있다. 사용자는 제 1단말(300)에서 상기 언급한 LPA 방식을 수행한 다음에 제 1단말이 프로파일 서버로부터 프로파일을 다운로드 받는데 필요한 해당 데이터를 획득하여 QR코드 형태로 제 1단말(300)에 Display(340)하면 해당 QR코드를 제 2단말에서 스캔(385)하여 이후 절차를 동일하게 처리할 수 있다. 사용자(100)로부터 제 1단말이 없다고 입력되는 경우에, 단말(350)은 해당 통신사업자는 기존 단말(300) 없이 프로파일의 기기 변경 서비스를 지원할 수 없다는 안내 메시지를 띄우고 절차를 종료할 수 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 ODSA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 1 단말(300)인 경우, 단말은 단말에 설치된 이동할 프로파일의 상태 정보와 단말에 구현된 인증 방식에 대한 정보를 수집하여 ODSA Client(110)에서 ECS(120)으로 전송하고, 단말 또는 서버에서는 해당 프로파일에 대한 인증 방식을 결정할 수 있다. 프로파일의 상태 정보라 함은 프로파일이 enabled 또는 disabled 되어 있는 지에 대한 정보로 enabled되었다는 의미는 단말(105)이 해당 프로파일의 파일 데이터에 접근 가능한 상태로 네트워크가 활성화되어 있는 상태를 의미한다. disabled되었다는 의미는 단말(105)에서 해당 프로파일의 파일 데이터에 접근 불가능한 상태로 네트워크가 활성화되어 있지 않은 상태를 의미한다. 단말은 단말에 설정된 인증 방식의 우선 순위에 따라 인증 방식을 결정하여 ECS(120)전송하고 ECS(120)에서 이를 최종 컨펌하여 회신하는 방식으로 인증 방식을 결정할 수 있다. 또는, 단말이 단말(120)에서 이동할 프로파일 상태 정보와 단말에서 지원 가능한 모든 인증 방식에 대한 정보를 ECS(120)에 전송하고 ECS(120)에서 해당 프로파일에 대한 서비스 사업자의 인증 방식 및 인증 방식 적용에 대한 우선 순위를 고려하여 1개를 선택해 사용할 방식으로 회신하는 방법도 가능할 수 있다. 본 발명에서는 ODSA 서비스 접근 자격에 대한 증명을 위해 단말에서 지원 가능한 인증 방식으로 제 1단말(300)은 ECS(120)와 SM-DP+(150) 협력 인증 방식(315)인 ECS&DP+방식(325), 전술한 SIM 모듈에 저장된 가입자 식별자 정보인 IMSI(Internal Mobile Subscriber Identifier)와 k값을 활용하는 EAP-AKA 방식(330), 웹 서비스 로그인 기반 인증 방식인 OAuth/Open ID 방식(335) 중 하나를 선택하여 이후 ECS(120)와 데이터 교환을 통해 해당 접근 단말 및 가입자가 ODSA 서비스 자격 인증이 있는지 수행할 수 있다. 각각의 인증 방식을 포함한 절차는 도 5a 내지 도 5d에서 상세하게 후술한다. ECS(120)에서 ODSA 서비스 접근에 대한 단말 및 가입의 자격이 인증되면, ECS(120)는 통신사 Back-end 시스템(130)를 통해서 제 2단말(350)이 SM-DP+(150)로부터 프로파일을 다운로드 받기 위해 필요한 데이터를 획득하여 제 1단말(300)의 ODSA Client로 회신할 수 있다. 또는, 통신사 Back-end 시스템(130)은 해당 SM-DP+(150)로부터 프로파일을 다운로드 받기 위해 필요한 데이터를 전송하는 대신, 제 1단말(300)이 자체 생성 등으로 획득하는 방법을 포함하여 회신할 수도 있다. 제 1단말(300)이 해당 데이터를 획득하는 자세한 방법에 대해서는 도 5c에서 후술하기로 한다. 제 1단말이 해당 데이터는 획득하여 QR코드 형태로 제 1단말(300)에 Display하면 제 2단말(350)은 해당 상기 제 1 단말의 화면에 Display된 QR코드를 스캔(340)하고, 해당 QR코드에 포함된 프로파일서버(150)로부터 상기 프로파일을 수신하여 설치하여 기기 변경에 따른 프로파일 이동 설치를 완료(390)할 수 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 ODSA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 2 단말(350)인 경우, 단말은 제 1 단말(300) 보유 여부에 대한 사용자 입력을 통해 사용자(100)로부터 해당 정보를 획득할 수 있다. 제 2 단말(300)에서 사용자(100)가 제 1단말(300)을 사용할 수 있다는 정보가 입력되는 경우, 제 2 단말(300)은 제 1단말(300)은 사용자로부터 인증 코드를 수신할 제 1단말(300)의 전화번호(MSISDN) 입력 받아 ECS(120)로 전송할 수 있다. ECS(120)은 통신사의 별도 인증 서버와의 메시지 교환을 진행하고, 통신사의 별도 인증 서버에서 해당 MSISDN에 문자 메시지로 인증코드를 송신한다. 제 1단말(300)에서 문자 메시지로 인증 코드가 수신되면, 사용자는 인증 코드를 제 2 단말(350)에 입력하여 ODSA 서비스에 대한 접근 권한이 있음을 인증할 수 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 ODSA 방식이며, 제 2단말(350)에 사용자(100)가 제 1단말(300)을 사용할 수 없다고 입력하는 경우에, 제 2단말(350)은 웹 포탈 또는 웹 애플리케이션으로 연결하여 로그인 방식을 통한 가입자 인증 방식인 OAuth/Open ID 방식(370)을 선택하여 인증할 수 있다. 이러한 SMS-OTP(One time Password or Password) 방식(365) 또는 OAuth/Open ID 방식(370)을 통해 접근 단말 및 해당 가입자가 ODSA 서비스 접근 자격이 있음이 인증되면, ECS(120)는 제 2단말(350)이 프로파일 서버(170)로부터 프로파일 다운로드에 필요한 데이터를 Activation Code 포맷으로 제 2단말(350)의 ODSA Client(110)에 전송할 수 있다. 해당 데이터는 단말의 ODSA Client(110)에서 LPA(140)에 전달되며, LPA(140)에서는 이동 설치할 프로파일을 SM-DP+서버(150)로부터 다운로드하여 eUICC(160)설치함으로써 기기 변경에 따른 프로파일 이동을 처리할 수 있다.

도 4는 eUICC를 탑재한 단말(105)에서 기기 변경 시 프로파일 이동 처리를 위한 설정 정보를 획득하는 방법을 도시한다.

Device(105)에서 End User(100)는 단말에서 기기 변경 시 신규 단말로 이동할 프로파일을 선택하는 경우, 해당 프로파일을 선택하는 경우에 단말은 프로파일의 메타데이터 정보에서 모바일 통신사 식별 정보로 MCC+MNC (The ITU-T Recommendation E.212에 정의된 mobile country codes (MCC)와 mobile network codes (MNC)를 의미) 값을 획득할 수 있다. 또는, 단말에 이동할 프로파일이 없는 경우, 즉 신규 단말에서 기기 변경을 시도하는 하는 경우, 단말(105)는 사용자(100)로 하여금 통신사업자를 선택하는 메뉴를 제공함으로써, 통신사업자의 MCC+MNC 정보를 획득할 수 있다. 해당 MCC+MNC 정보를 통해 단말은 어떤 사업자의 프로파일을 이동 설정을 확인해야 하는지 판단할 수 있다. 단말(105)은 또한, End User(100)가 프로파일 이동에 대한 메뉴를 선택할 수 있도록 제공하여, 해당 프로파일의 기기 변경을 위한 절차 수행 시작 및 제 1단말(300) 또는 제 2단말(350) 중 어떤 단말을 통해 접속하는지 정보를 획득할 수 있다. 단말(105)은 이제 단말은 이후 프로파일 이동을 위한 사업자의 기기 변경 설정 정보를 확인하여 프로파일 이동에 사용할 방식으로 LPA 방식 또는 ECS 방식 중 하나를 선택(470)할 수 있다. 단말이 필요한 기기 변경 설정 정보로 해당 프로파일에 대한 통신사업자의 기기 변경 지원 여부를 포함하며, 기기 변경 지원 방식(LPA 방식 또는 ODSA 방식), 및 지원 방식에 따른 SM-DP+ 서버 주소 또는 ECS 주소, 지원하는 사용자 인증 방식, 예를 들어 EAP-AKA, ECS&DP+, OAuth/Open ID 등의 인증 방식 식별 정보 및 선호 우선 순위에 대한 정보를 포함할 수 있다. 기기 변경 설정 정보를 확인하는 방법으로는, 단말(105)은 다음을 수행할 수 있다.

- 옵션 1: 사용자(100)가 단말의 UI를 통해 이동할 프로파일을 선택하는 경우에, LPA(140)에서 eUICC(160)로 GSMA SGP.22에 정의된 ES10c.GetProfilesInfo() Function Call을 수행하여 해당 프로파일의 상태 정보와 메타데이터 정보를 획득할 수 있다.

- 옵션 2: 기기 변경 수행을 처리하기 위해 Configuration Server(170)가 있고 단말(105)에 해당 서버 주소가 설정되어 있는 경우에, 단말은 최초 부팅 시 또는 단말 설정에 따라 특정 주기로 해당 서버에서 기기 변경 설정 정보를 일부 또는 전체를 가져와 저장해 두었다가 활용할 수 있다. 사용자가 특정 통신사업자를 선택 또는 이동할 프로파일을 선택하는 경우에, 단말(105)은 단말의 메모리에 저장된 해당 정보를 확인하여 매칭되는 값을 획득하여 활용할 수 있다.

- 옵션 3: 단말(105)은 메모리 및 배터리 절약 등을 위해서 Configuration Server(170)에 저장된 통신사업자들의 기기 변경 설정 정보를 특정 주기 또는 최초 단말 부팅 시 모두 한꺼번에 받아 오지 않고, 단말(105)이 사용자(100)가 단말(105)의 UI에서 통신사를 선택하면, Configuration Server(170)에 해당 통신사의 MCC+MNC에 대한 기기 변경 설정 정보를 요청하고, 해당 요청에 대한 회신으로 특정 사업자의 기기 변경 설정 정보를 획득할 수 있다.

- 옵션 4: 통신사업자 별 기기 변경 방식 또는 사업자 향 단말로 출시된 경우, 해당 통신사의 기기 변경 방식을 preloaded 해 두었다가 전술한 바와 같이 사용자(105)가 프로파일 또는 이동할 프로파일의 통신사업자를 메뉴에서 선택하면 단말(105)은 메모리에 저장된 정보와 매칭하여 기기 변경 설정 정보를 확인할 수 있다.

단말(105)은 위의 언급한 4가지 방법 중 하나 또는 그 이상을 복합적으로 활용할 수 있으며, 해당 옵션을 통해서 획득한 기기 변경 설정 정보가 다른 경우, 단말 설정에 따라 방법을 결정하여 설정할 수 있다. 한 예로, 단말은 가장 최근에 설정 정보 또는 다른 예로 프로파일의 메타데이터를 선택하는 데 있어 우선 순위로 결정할 수 있다. 이하 도 5와 도 6에서 언급할 실시 예 들을 통해 해당 설정 정보를 받아오고 활용하는 절차를 상황 별로 구체적으로 설명하겠다.

도 5a 내지 도 5d는 제 1단말에서 시작하는 경우의 기기 변경 방식에 대한 실시 예들을 도시한다. 기기 변경 처리에 대한 전체 절차는 다음과 같은 절차로 크게 구분할 수 있다. 제 1단말(300)이 eSIM 설정 정보를 파악하는 단계, ODSA 서비스 자격을 확인하기 위한 단말 및 사용자 인증을 진행하는 단계, 인증이 완료되면 Activation Code를 발급해 주는 단계, 제 2 단말(350)에서 해당 정보를 획득하여 프로파일을 다운로드 받아 이동 설치를 완료하는 단계이다.

도 5a는 통신사가 ODSA 방식을 제공하며 EAP-AKA 인증을 사용하는 실시 예를 나타내는 도면이다.

End User(100)는 제 1단말(300)의 LPA 또는 LPA가 구현된 애플리케이션의 화면에서 기기 변경을 위해 이동할 프로파일을 선택하고, 해당 프로파일을 이동 메뉴를 선택(5a-10 단계)할 수 있다. 해당 메뉴가 선택되면, 단말(300)은 해당 프로파일의 통신사업자 식별 ID 정보(MCC+MNC)를 가지고, 해당 통신사의 eSIM 기기 변경을 위한 설정 정보가 단말에 저장되어 있는지 확인하는 한편, 단말의 LPA1(140)에서 단말 1의 eUICC(160)로 GSMA SGP.22에 정의된 ES10c.GetProfilesInfo() Function Call을 수행하여 해당 프로파일의 상태 정보를 획득할 수 있다. 상태 정보와 더불어 LPA1(410)는 단말 1의 eUICC(160)로터 해당 프로파일의 메타데이터에 기기변경 지원 여부, 지원 방식에 대한 식별 정보 또는 이후 처리를 위한 서버 주소가 있는지 추가적으로 확인할 수 있다. 5a-10 단계 내지 5a-30 단계에서는 옵션 1과 2를 통해서 확인하는 방법을 예로 도시하였으나, 획득하는 방법은 이에 한정하지 아니하고 도 4에서 전술한 바와 같이 옵션 1 내지 4를 1개 이상 활용 및 조합하여 획득할 수 있다. 해당 수집된 정보를 통해 제 1 단말(300)은 해당 프로파일을 통신사가 ODSA Client(110)와 ECS(120)을 활용하는 ODSA 방식을 지원하는 것과 해당 방식을 처리하기 위한 ECS 주소를 획득하여 이후 단말에서 처리할 기기 변경 방식을 결정(5a-40 단계)할 수 있다. 제 1 단말의 ODSA Client 또는 ODSA Client가 구현된 앱인 ODSA 1(400)은 앞서 프로파일 메타데이터 확인(5a-30 단계)을 통해서 획득한 프로파일의 상태 정보를 LPA로부터 획득하고, 단말의 Capability를 확인하여 가능한 단말의 인증 방식을 수집하여 ECS(120)에 인증 요청을 송신할 수 있다. 한 예로 (5a-50 단계)와 같이 나타낼 수 있다. 해당 인증 요청 메시지에는 단말 식별자로 IMEI, 단말에서 구현된 인증 방식들에 대한 식별 정보, 요청 단말이 제 1단말(300)임을 추측할 수 있는 식별 정보로써 ICCID, IMEI, 또는 EAP(Extensible Authentication Protocol) ID 또는 신규 식별자를 정의하여 포함할 수 있으며, 이동할 대상 프로파일 ID로 ICCID, 해당 프로파일의 상태 정보를 포함할 수 있다. 해당 인증 요청 메시지에 포함된 상기 정보에서 요청 단말이 제 1단말(300)임을 나타내는 식별 정보, 이동할 대상 프로파일 ID로 ICCID, 해당 프로파일의 상태 정보와 같은 기기 변경 처리에 요구되는 정보들은 인증 요청 메시지에 추가하지 않고, 인증이 완료된 후에 기기 변경 요청하는 시점(5a-160)에 포함하여 단말에서 전송하는 방법도 가능하다. 단말에서 구현된 인증 방식에 대한 식별 정보라 함은 해당 인증 방식이 단말에 구현되었거나 또는 단말에 구현되었으며 해당 송신하는 시점에서 사용 가능한지를 나타내는 식별자로 사용할 수 있다. 해당 인증 방식에 대한 식별 정보를 통해 ECS(120)에서 프로파일의 상태 정보를 판단할 수 있는 경우에 단말은 프로파일 상태 정보를 포함하지 않고 송신할 수 있다. 단말에 구현된 인증 방식에 대한 식별 정보로, 단말에 EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement)가 구현된 경우에 단말은 인증 요청에 EAP ID를 포함해 전송(5a-50 단계)할 수 있다. 단말에서 사용 가능한 인증 방식으로써 ECS&DP+방식을 사용하는 경우에 이를 구분할 신규 식별자를 정의하거나 기존 식별자(예를 들어 SM-DP+Address)를 해당 식별 정보로 활용할 수 있다. 해당 식별자는 본 발명에서는 편의를 위해 DP+AuthSupport라고 칭하여 설명하겠다. 만약 단말에서 인증 방식에 대한 식별 정보 또는 인증 토큰이 없는 경우에 ECS는 해당 단말이 OAuth/Open ID 만 제공 가능하다고 판단할 수 있다. ECS(120)가 단말로부터 단말이 지원하는 1개 또는 그 이상의 인증 방식에 대한 인증 식별 정보를 수신(5a-60 단계) 받으면, 예를 들어, EAP-AKA 식별자로 EAP ID, ECS&DP+인증을 위한 식별자로 DP+AuthSupport를 포함해 수신 받으면, ECS(100)는 사업자의 선호도 및 사업자의 인증 서버 지원 여부에 따라 가능한 1개의 방식을 선택하여, 단말에 회신할 수 있다. 한편, 요청 단말이 제 1단말(300)임을 나타내는 식별 정보 또는 신규 식별자의 일 예는 (5a-50 단계)의 OldTerminal=True와 같은 신규 값일 수 있고, 또는 이동할 프로파일의 고유 식별 번호인 ICCID가 포함 된 경우에, ECS(120)가 제 1단말(300)로 판단하는 것도 가능하다. ECS(120)는 EAP-AKA 인증을 수행하기 위해 사업자의 AAA(Authentication, Authorization and Accounting) 인증 서버와의 Relay가 지원 가능한지 여부, 여러 개의 인증 방식이 가능한 경우에 사업자가 제공하고자 하는 인증 방식의 우선 순위 등을 확인할 수 있다. (5a-60 단계)에서 (5a-170 단계)까지는 해당 확인을 통해서 ECS(120)가 인증을 EAP-AKA로 진행했을 때의 방법을 도시한다. 단말에 구현된 인증 방식에 대한 식별 정보로, 단말에 EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement)가 구현된 경우에 단말은 전술한 바와 같이 인증 요청에 EAP_ID를 포함해 전송(5a-50 단계)할 수 있다. 제 1 단말은 사용자가 이동하고자 선택한 프로파일의 IMSI(International Subscriber Identity Module)값을 EAP ID 에 포함하여 ECS(120)에 전송할 수 있고, 해당 값을 획득할 수 없으나 단말에 EAP-AKA가 구현된 경우에 EAP ID 값을 NULL, empty value로 하여 전송하거나 또는 이를 나타내기 위한 별도 식별자 또는 값을 정의하여 제공할 수 있다. IMSI값은 프로파일의 상태 정보가 Enabled 되어 있을 때 프로파일의 내부 데이터 또는 프로파일의 메타데이터에서 획득 가능한 정보로, EAP-AKA가 제공 가능하게 구현되어 있고, 기기 변경을 수행하는 현 요구 시점에서 해당 인증을 사용할 수 있음을 나타낼 수 있다. 한편, 해당 정보를 획득하지 못한다는 것은 해당 시점에 단말에 EAP-AKA가 구현되어 있으나 프로파일의 상태 정보가 disabled라는 것으로 ECS(110)가 판단할 수도 있다. 한편, 제 1단말(300)은 5a-30 단계에서 취득한 프로파일의 상태 정보를 ECS(5a-50 단계)에 함께 포함해 전송함으로써 ECS(120)에게 해당 단말에서 EAP-AKA 인증을 사용 가능함을 명확하게 알려줄 수 있다. ECS(120) 수신된 인증 요청 메시지를 통해서 단말에 EAP-AKA가 구현되어 있으나 프로파일 상태가 Disabled 되어 있는 경우에, ECS(120)는 EAP-AKA로 사용자 인증을 수행할 지 여부와 처리 가이드 등을 포함해 사업자 메시지를 포함해 단말에 회신(5a-70 단계)할 수 있다. 해당 경우에 단말은 사업자 메시지를 단말에 표시하여 사용자의 동의를 획득하며, 사용자(100)는 EAP-AKA로 인증을 처리를 승낙하거나 거절할 수 있다(5a-80 단계). 만약 승낙하는 경우에, LPA1(510)에서 eUICC로 프로파일의 상태를 일시적으로 disabled 상태에서 enabled 상태로 변경(5a-90 단계)하여 EAP-AKA 인증이 가능하도록 사용자 동의를 획득한 후, 사용자가 허가한 경우 LPA1에서 eUICC로 10c.EnabldProfile() 처리할 수 있다. enabled 상태로 변경되면 LPA 1(510)에서는 eUICC로부터 해당 프로파일 상태 정보와 IMSI값을 획득하여 ODSA1(500)에 전달할 수 있다. 이를 받은 제 1단말의 ODSA1(500)은 5a-95 단계와 같이 EAP_ID를 IMSI값으로 하여 인증 요청 메시지를 ECS(120)에 전송할 수 있다. 또는 프로파일 상태 정보를 추가적으로 포함하여 보내어 프로파일 상태가 변경되었고 EAP-AKA 인증이 가능함으로 ECS(120)에 알릴 수 있다. 만약 사용자가 거절(5a-170 단계)하는 경우에, 제 1단말(300)은 해당 거절 메시지를 ECS(120)에 송신하고 ECS(120)은 해당 거절 메시지를 받게 되면, 기존의 수신된 (5a-50 단계)를 통해 수신된 단말의 다른 인증 방식을 참조하여 사용할 인증 방식을 선택해 인증 절차를 처리할 수 있다. (5a-180 단계) EAP-AKA방식은 Challenge-response 메커니즘을 사용하며 대칭키 기반의 인증을 통한 암호화된 세션을 생성할 수 있다. ECS(120)가 단말의 인증 식별 정보 또는 단말의 식별 정보와 프로파일 상태 정보의 조합으로 EAP-AKA 방식 사용이 가능하다고 판단되어 EAP-AKA 방식을 선택하면, ECS는 사업자의 인증 서버(440)에 EAP-AKA Challenge를 요청할 수 있다. 사업자 인증서버(440)는 AKA 알고리즘을 수행하여 "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)" 에 정의된 바와 같이 EAP-AKA Challenge 값을 생성하여 ECS(120)에 회신하고 ECS(120)는 선택한 인증 방식(여기서는 EAP-AKA 방식)과 검증에 필요한 값으로 EAP-AKA Challenge를 함께 단말에 회신(5a-110 단계) 할 수 있다. ECS(120)이 선택한 인증 방식은 별도 구분자로 알려줄 수도 있고 (예. (5a-110 단계)의 AuthType(EAP-AKA)) 해당 인증 방식임을 판단할 수 있는 소정의 정보의 수신으로 (예. (5a-110 단계)의 EAP-AKA Challenge 값만을 수신)하여 해당 인증 방식을 ECS(120)가 결정했다고 판단할 수 있다. 해당 EAP-AKA Challenge가 수신되면, 제 1단말(300) eUICC은 해당 Challenge 값과 해당 SIM 모듈의 보안 키 값을 활용해 EAP-AKA 알고리즘을 수행하여 해당 결과 값을 포함해 ECS(5a-130 단계)에 회신할 수 있다. ECS(120)는 해당 수신된 정보를 사업자 인증서버(440)에 Relay하고 사업자 인증서버(440)는 제 1단말로부터 수신된 값(5a-130 단계)으로부터 EAP-AKA Challenge값을 검증하여 인증 여부를 ECS에 회신(5a-140 단계) 할 수 있다. 해당 인증 결과(5a-140 단계)가 성공인 경우에, ECS(120)는 이후 ECS(120)와의 세션 연결에 사용할 수 있는 인증토큰을 생성하여 제 1단말에 전송(5a-150 단계)할 수 있다. 이제 제 1단말(300)은 단말의 고유 식별 정보로 IMEI와 수신된 인증토큰을 파라미터로 하여(5a-160 단계) 통신 서비스 가입된 기기의 이동을 요청(5a-160 단계) 할 수 있다. 전술한 바와 같이 요청 단말이 제 1단말(300)임을 나타내는 식별 정보, 이동할 대상 프로파일 ID로 ICCID, 해당 프로파일의 상태 정보와 같은 기기 변경 처리에 요구되는 정보들은 인증 요청 메시지에 추가하지 않고, 인증이 완료된 후에 기기 변경 요청하는 시점(5a-160 단계)에 포함하여 단말에서 전송하는 방법도 가능하다. 이는 제 1단말에서 기기 변경을 요청하는 다른 실시 예에서도 동일하게 적용될 수 있다. EAP-AKA를 활용한 단말과 인증 서버 간의 구체적인 인증 절차 및 파라미터는 "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)" 규격을 참조한다.

해당 인증이 완료되면, ECS와 SM-DP+서버, MNO BSS/OSS(130)은 서비스 가입 정보 변경에 필요한 정보를 획득하고 SM-DP+서버(150)- MNO BSS/OSS(130)은 프로파일을 생성을 준비(5a-190 단계) 할 수 있다. 해당 단계(5a-190 단계)에서 ECS(120)는 현재의 해당 프로파일의 ICCID에 맵핑되어 있는 Subscription ID, 또는 여기에 추가로 신규 단말의 IMEI를 포함하여 신규 가입 정보를 통신사업자의 Back-end 시스템(130)에 요청할 수 있다. 이를 수신한 MNO BSS/OSS(130)에서는 SM-DP+서버와 SGP.22에 정의된 ES2+Interface를 통해 프로파일 생성에 대한 일련의 과정을 수행하여 제 2단말(350)에 설치할 프로파일의 ICCID와 Activation Code를 포함하여 획득하여 ECS(130)에 회신할 수 있다. ECS 서비스 가입 정보 변경에 필요한 정보를 해당 시점에 또는 이후 특정 시점에 업데이트하여 ECS에 저장된 가입 정보를 변경 처리할 수 있다. ECS(130)는 제 1단말의 ODSA1(500)에 수신된 Activation Code를 송신(5a-200 단계) 할 수 있다. 사업자의 정책에 따라 ECS(120)는 해당 프로파일의 제 1단말(300)에서의 삭제 여부에 대한 값을 함께 포함하여 송신(5a-200 단계) 할 수 있다. 해당 정보가 수신되면, 제 1단말(300)은 해당 단말의 사용자 안내 메시지로 제 2단말(350)에서 제 1단말에 수신한 Activation Code를 획득하는 방법을 띄운다(5a-210 단계). 만약, 제 1단말(300)에서의 삭제 여부에 대한 값을 함께 수신(5a-200 단계)한 경우, 제 1단말은 사용자에게 기존 프로파일의 삭제를 안내하고 삭제해야만 기기 변경을 처리할 수 있음을 알려주어 사용자의 동의를 획득할 수 있다. 사용자가 삭제를 동의하는 경우에, 제 1단말에서 ODSA Client 또는 ODSA Client가 구현된 앱인 ODSA1(500)에서 LPA1(510)에 프로파일 Delete을 요청하면, LPA1(510)에서 해당 이동할 프로파일에 대한 "ES10c.DeleteProfile" Function Call을 수행해 eUICC에서 해당 프로파일을 삭제 처리하고, 해당 프로파일이 삭제에 대한 notification을 LPA1 또는 ODSA1에 회신할 수 있다. 단말은 LPA1 또는 LPA1을 통해 ODSA1이 해당 프로파일 삭제에 대한 notification을 수신해야 Activation Code를 활성화하여 제공해 주도록 처리할 수도 있다. End User(100)는 제 2단말(350)에서 (5a-210 단계)에 안내된 바에 따라 Activation Code를 획득할 수 있다. 예를 들어, 제 2단말(350)의 사용자의 UI로 Activation Code가 QR코드 형태로 Display하고 제 1단말(300)의 카메라를 사용해 해당 QR 코드를 스캔할 수 있다. 해당 Activation Code가 제 2단말에 입력되면, LPA2(430)에서 Activation Code를 획득하여 Activation Code에 설정된 SM-DP+ 서버 주소로 접속하여 GSMA SGP. 22에 정의된 Remote SIM Provisioning 절차에 따라 프로파일을 제 2단말에 다운로드하여 설치 완료(5a-230 단계) 할 수 있다. 다운로드 설치 처리가 완료되면, MNO의 Back-end시스템(130)은 ECS(120)에 제 2단말(350)에 설치된 신규 프로파일의 ICCID 또는 ICCID와 제 2단말(350)의 IMEI를 함께 전송하고, ECS(120)는 해당 ICCID와 (5a-120 단계)에서 획득한 ICCID 값을 매칭하여 동일한 경우, 해당 Subscription 정보를 업데이트하고 선택적으로 업데이트 결과를 사업자 Back-end시스템(130)에 회신할 수도 있다.

도 5b는 제 1단말에서 시작하는 ODSA 방식을 지원하는 프로파일 이동으로, 인증 방식으로 ECS/DP+방식을 사용하는 실시 예를 나타내는 도면이다.

도 5a의 5a-10 단계 내지 5a-50 단계에 대한 설명으로 전술한 바와 같이 제 1단말은 프로파일, 메모리, Configuration Server를 통해 기기 변경에 대한 Configuration 정보를 획득할 수 있다. 이후 단말 및 가입자 인증을 수행함에 있어, ECS&DP+인증 방식을 수행하고자 하는 경우에 단말은 ECS(120)에 송신하는 인증 요청에 DP+AuthSupport 이 가능함을 나타내는 식별자를 포함하여 인증을 요청할 수 있다. 본 발명에서는 이후 설명의 편의를 편의를 위해 임의의 식별자로 (5a-50 단계)의 DP+AuthSupport로 표기하였으나, 해당 이름에 한정하지 않으며, SM-DP+로 인증이 수행이 가능함을 나타내는 식별자 정보로 단말은 인증 수행이 가능한 SM-DP+주소를 식별자로 사용할 수도 있다.

해당 인증 방식이 수신되면 ECS(120)는 GSMA Root CI(Certification Issuer) 인증서와 해당 인증을 수행을 위해 Redirect할 SM-DP+주소가 Configure 되어 있는지를 포함하여 해당 인증 방식 지원을 위한 Capability를 확인하여, 해당 인증 방식으로 처리를 결정할 수 있다. 앞서 단말에서 인증 수행이 가능한 SM-DP+주소를 식별자로 사용한 경우에 ECS는 수신된 SM-DP+주소를 Redirect할 SM-DP+주소로 사용할지 여부를 추가적으로 결정할 수 있다.

해당 인증 방식을 결정하면, ECS(120)는 임의의 데이터인 Nonce값을 생성(5b-20 단계)하여 제 1단말(300)에 ECS&DP+인증방식, 인증 받을 SM-DP+서버 주소, 그리고 생성한 Nonce값을 포함해 회신(5b-30 단계) 할 수 있다.

도 5a에서 전술한 바와 같이 ECS(120)은 단말에 선택한 인증 타입을 명시적으로 알려 줄 수도 있고, 선택한 인증 타입에 대한 명시적 제공이 없더라도, 단말이 판단할 수 있는 소정의 정보 제공을 통해서, 즉 예를 들어 인증 받을 SM-DP+서버 주소 회신, 단말이 이를 판단하여 결정할 수도 있다. ECS는 ECS가 OAuth/Open ID 인증 방식을 선택 시 회신하는 HTTP(s) "302 Found" 응답 구조로, 인증 받을 SM-DP+서버 주소로의 Redirection 을 요청할 수 있으며, 이 경우에 다음 예시들을 포함할 수 있다.

예시 1) Http(s) Response - 302 Found

Header에 다음을 포함

Location: <인증을 수행할 SM-DP+주소>/authorize?

Body에 다음을 포함

response type=code&

scope= SM-DP+Auth&

nonce=<ECS 생성 nonce 값>&

Client ID=<ECS가 인증을 수행할 SM-DP+로부터 사전 발급 받은 ID>&

redirect URL=<회신할 주소로 AES로 암호화된 ECS 주소>

예시 2) Http(s) Response - 302 Found

Header에 다음을 포함

Location: < 인증을 수행할 SM-DP+주소>/authorize?

Body에 다음을 포함

response type=SM-DP+Auth&

nonce=ECS 생성 nonce 값&

client ID=<ECS가 인증을 수행할 SM-DP+로부터 사전 발급 받은 ID>&

redirect URI=<회신할 주소로 AES로 암호화된 ECS 주소>

예시 1) 또는 예시 2)와 같이 HTTP(s) "302 Found" 응답 구조의 scope 또는 response type에 DP+인증을 나타내는 식별자가 포함되어 회신 되는 경우, 단말은 ECS가 OAuth/Open ID 방식이 아닌 ECS&DP+로 인증 수행을 요청함으로 판단하고 제 1단말(300) 내부 동작으로 ODSA1(500)가 LPA1(510)에 해당 수신된 데이터를 전달(5b-40 단계) 하여 이후 아래와 같이 DP+인증 절차 수행으로 처리할 수 있다. OAuth/Open ID 인증 방식인 경우, response type으로 수신되는 code는 client id와 redirection URI와 binding이 요구되며, 최초 Http(s) Response - 302 Found에 client id와 redirection URI가 포함되어 전송되어야 한다. OAuth2.0/OIDC Sever는 사전 계약을 통해 ECS에 대한 Client ID를 사전 발급, redirection URI에 대한 정보를 가지고 있다가 단말이 특정 Client ID와 redirection URI를 가지고 인증 요청 하면, 해당 정보를 검증하여 code를 발급하여 회신해 줄 수 있다. 하지만, ECS/SM-DP+인증은 사전 SM-DP+와 ECS의 계약 없이 처리가 가능하므로 ECS에서 Http(s) Response - 302 Found에 DP+인증을 나타내는 식별자가 포함된 경우 client ID와 redirect URI 중 하나 또는 전체를 포함하지 않아도 단말은 이를 에러 처리하지 않고 DP+인증 절차 수행으로 처리해야 한다.

해당 도면에서는 도시하지 않았으나, eUICC와 SM-DP+간에 (5b-50 단계)절차를 수행하기에 앞서, 상호 인증 절차를 먼저 수행할 수 있다. 먼저 LPA1(500)은 해당 프로파일이 설치된 제 1단말의 eUICC에 ES10b.GetEUICCChallenge를 요청하여 해당 메시지 값으로 eUICCChallenge값을 수신하여, LPA1(500)에서 해당 eUICCChallenge포함한 메시지로 ES9+.InitiateAuthenticate 요청 메시지를 SM-DP+(150)에 전송할 수 있다. 해당 프로파일 서버에서는 해당 값을 검증하여 Transaction ID를 생성하고 Transaction ID와 eUICCChallenge값이 포함된 데이터에 대한 프로파일 서버의 서명을 생성하여 회신할 수 있다. 이때 회신 하는 InitiateAuthenticate 회신 메시지는 상기 프로파일 서명값, Transaction ID를 포함할 수 있다. 제 1단말(300)은 상기 InitiateAuthenticate 회신 메시지를 수신 후, ECS로부터 수신된 Nonce값(5b-40 단계), 기기 변경 대상 프로파일의 ICCID, 해당 ICCID가 설치된 eUICC 서명 데이터를 생성해 이를 포함하는 데이터를 SM-DP+서버(150)에 전송할 수 있다. eUICC 서명 데이터에 추가적으로 또는 eUICC 서명 데이터를 대체하는 정보로 EID를 포함해 전송할 수도 있다. 전송되는 메시지의 일 예는 ES9+.AuthenticateClient Request (MatchingID=ICCID1, AuthRequest (Nonce, eUICC Signature) (5b-50 단계)와 같은 메시지일 수 있다. SM-DP+서버(150)는 상기 AuthenticateClientRequest 메시지를 수신하면 AuthenticateClientRequest메시지에 포함된 가입 정보 이전 처리하고자 하는 프로파일의 ICCID (ICCID1로 표기), 제 1단말의 해당 eUICC의 서명 Data 검증을 포함한 유효성 검증과정을 수행하여, 해당 ICCID의 제 1단말의 eUICC 설치를 검증하여 검증 결과로 프로파일 서버의 서명을 생성하고 5b-50 단계 에서 수신한 Nonce, eUICC서멍데이터, 프로파일 서버의 서명 데이터를 포함한 인증 토큰을 AuthenticateClientResponse메시지(5b-60 단계)에 포함하여 회신할 수 있다. 해당 회신하는 정보는 ICCID에 매핑되는 EID가 추가적으로 포함될 수 있다. 해당 회신 메시지의 일 예로ES9+.AuthenticateClient Response (AuthResponse (AuthToken (EID, ICCID, Nonce, DP+ Signature))) (5b-60 단계)와 같이 표기될 수 있다.

SM-DP+(150)서버에서 상기 제 1단말(300)의 eUICC(160)의 서명데이터검증은 상기 ICCID 또는 상기 ICCID에 추가적인 데이터(ECS Nounce, eUICC 서명 값, 처리 순번 번호)를 포함한 데이터에 대해서 제 1단말(300)의 eUICC(160)의 인증서를 이용한 서명 검증일 수 있다. 상기 서명검증은 ECDSA (Elliptic Curve Digital Signature Authentication)일 수 있다. 상기 eUICC 인증서는 상기 EUM(eUICC Manufacturer)인증서로 인증할 수 있다. 상기 EUM 인증서는 프로파일 서버(150)가 가지고 있는 CA (Certificate Authority) 인증서로 검증할 수 있다. 상기 CA 인증서는 Root CI (Certificate Issuer) 인증서로도 명명할 수 있다. 또한 상기 유효성 검증과정는 상기 ICCID에 대해서 최종 설치되었던 eUICC가 제 1단말(300)의 eUICC(160)임을 확인하는 과정 및 메시지의 처리순번정보(Sequence Number)를 이용하여 메시지의 유효성을 확인하는 과정을 포함할 수도 있다. 또한 프로파일서버(150)의 상기 유효성 검증 과정은, 도면에는 표시되어 있지 않지만, 프로파일서버(150)가 사업자 서버에게 상기 ICCID에 대한 인증을 위해 프로파일의 재설치 허용 여부를 질의하고, 그 결과를 회신하는 과정을 포함할 수도 있다. LPA1(510)이 SM-DP+로부터 해당 인증 토큰을 수신(5b-60 단계)하면 LPA1(510)은 해당 정보를 ODSA1(500)에 전달하고 ODSA1(500)은 해당 인증 토큰을 단말 식별 정보와 함께 ECS(120)에 회신(5b-70 단계) 할 수 있다.

ECS(120)은 수신된 인증 토큰에서 최초 생성(5b-20 단계)해 전달했던 Nonce 값의 유효성을 검증하고, SM-DP+서명 값을 검증(5b-80 단계)하여 이후 절차를 전술(5a-190 단계 내지 5a-230 단계)한 바와 같이 수행하여 기기 변경 절차를 완료할 수 있다. ECS(120)가 생성한 해당 Nonce값은 해당 인증 요청에 대한 재사용 여부 판단 및 해당 ECS(120)에서의 요청인지를 증명/검증하는 식별자로 사용될 수 있다. ECS(120)가 Nonce값이 포함된 메시지를 수신 받으면, ECS(120)는 해당 전달된 메시지가 최초 ECS에서 발생한 메시지에 대한 회신 값이라는 것과 해당 Nonce 값의 재 사용되지 않았는지 판단하는 과정을 포함하여 해당 Nonce 값의 유효성을 판단할 수 있다. 또한, 전술한 바와 같이, 해당 인증을 지원하는 ECS(120)는 SM-DP+서버와 동일한 Root CI 인증서로 GSMA CI 인증서를 저장하고 있으므로, SM-DP+ 서명 값은 ECS서버(150)가 가지고 있는 해당 CI 인증서로 검증할 수 있다(5b-80 단계). 또한, SM-DP+(150)와 ECS(120)가 GSMA의 Root CI 인증서를 가지고 있고, 해당 ECS(120)가 SM-DP+(150)와 동일 GSMA 인증서 체인에 있으므로 ECS(120)는 SM-DP+(150) 서버에 직접적인 연동이 없더라도 해당 인증을 지원할 수 있다.

도 5c는 통신사가 LPA 방식을 제공하며 제 1단말(구 단말)에서 LPA와 SM-DP+인증을 사용하는 실시 예를 나타내는 도면이다.

전술한 바와 같이 사용자(300)가 제 1단말(300)의 UI에서 이동할 프로파일을 선택하고 프로파일 이동 메뉴를 선택하면, 단말은 기기 변경 방식에 대한 Configuration 정보를 확인하여 LPA 방식으로 처리를 결정(5c-30 단계)할 수 있다. 기기 변경 방식에 대한 Configuration 정보를 확인에 대한 절차는 도 4에서 전술한 것과 동일하거나 또는 유사하므로 여기서의 상세 설명은 생략한다. LPA1(510)은 SM-DP+(150)와 상호 인증을 수행하고 나서 ES9+.AuthenticationClientRequest 메시지로 이동할 프로파일의 ICCID, 기기변경 Indicator를 포함하여 기기변경을 요청(5c-40 단계) 할 수 있다. 해당 메시지를 수신한 프로파일서버(150)는 사업자 서버(130)에게 상기 ICCID에 대한 프로파일의 재설치 허용 여부를 질의하고, 그 결과를 회신하는 과정을 포함(5c-50 단계)할 수도 있다 또한, 해당 프로파일에 대한 사업자의 정책은 사업자 서버가 (5c-20 단계)을 시작하기 전 또는 5c-50 단계 의 과정 중의 하나로 하여 프로파일 서버에 알려줄 수도 있다. 통신사업자가 해당 ICCID에 대한 프로파일 기기변경을 지원하는 경우, SM-DP+와 사업자 서버(130)에 프로파일 주문, 준비, 생성을 처리(5c-60 단계) 할 수 있다. 해당 메시지는 ES2+.DownloadOrder 또는 ES2+.ConfirmOrder 또는 ES2+.ReleaseProfile 명령메시지 일 수 있다. 해당 처리를 완료(5c-60 단계)하면, SM-DP+(150)서버는 ES9+.AuthenticationClientResponse 메시지로 TransferType, ServiceProviderMesage, 그리고 추가적으로 Activation Code를 포함하여 회신할 수 있다. TranferType은 해당 사업자의 기기 변경 지원 방식에 대한 식별자로 해당 식별 정보로 신규 Activation Code 재발급을 통한 프로파일 다운로드 인지 아니면, 기존 프로파일을 삭제 처리하고 이에 대한 Delete Notification을 가지고 단말에서 해당 정보를 포함하여 Activation Code를 생성하고 프로파일 서버에서 추후에 해당 생성된 Activation Code에 포함된 일부 또는 전체의 Delete Notification을 통해서 검증할지 여부 등을 나타낼 수 있다. ServiceProviderMesage는 기기 변경을 위한 프로파일 처리 등을 사용자에게 안내하기 위한 데이터를 나타낸다. 사용자(100)가 최종적으로 기기 변경 절차 처리에 동의하는 경우(5c-80 단계), LPA1(510)은 SM-DP+에 기기변경 처리에 대한 사용자 답변을 포함하여 회신할 수 있다. 일 예로 ES9+.CancelSession (End User confirmation result) (5c-90 단계)메시지 일 수 있다. 5c-70 단계에서 수신된 통신사업자는 정책에 따라, 제 1단말(300)은 프로파일 이동 시 기존 설치된 프로파일을 삭제 처리하고 해당 삭제 메시지를 통해서 Activation Code를 단말에서 생성하여 활용하는 절차(5c-95 단계, 5c-100 단계)를 수행할 수 있다. 한편, (5c-95 단계, 5c-100 단계) 절차는 5a-200 단계 와 같이 프로파일을 삭제에 대한 요청 (DeleteOldProfile)이 포함된 경우에도 제공할 수 있다. 제 1단말(300)은 프로파일을 삭제(5c-95 단계)하고 생성된 Delete Notification 정보의 전부 또는 일부 정보를 이용하여 QR코드는 구성하여 보여줄 수 있다(5c-100 단계). 사용자(100)가 로컬 프로파일 관리를 통해서 기기 변경을 위해 프로파일을 삭제하는 Input이 입력되면 (예. 5d-40 단계 에서 OK 버튼 클릭), eUICC(160)는 프로파일을 삭제(5c-95 단계) 후 결과 메시지를 LPA1(510)에 전달할 수 있다. LPA1(510)는 제2 제어 메시지(예를 들어, ES10c.ListNotificationRequest 메시지)에 수신 받을 Event정보(NotificationEvent) 데이터에서 DeleteProfile을 의미하는 bit를 set해서 eUICC(160)에 전달할 수 있다. 상기 제2 메시지를 수신한 eUCIC(160)는 DeleteProfile에 해당하는 모든 notification 정보를 LPA1(510)에 회신할 수 있다. 해당 notification은 처리순번정보(Sequence 또는 Seq 또는 seqNumber로 표기), 프로파일 ID (또는 iccid 또는 ICCID) 중 적어도 하나를 포함한다. LPA1(500)은 삭제한 프로파일과 대응되는 notification을 또는 Seq값을 선별하고 해당 Seq값을 포함한 제3 제어 메시지(예를 들어, ES10c.RetrieveNotification 메시지)를 eUICC에 보낼 수 있다. eUICC(160)는 저장된 Notification정보들 중 해당 Seq값에 대응되는 Notification 정보를 LPA1(500)에게 전달할 수 있다. 상기 Notification정보에 포함되는 정보는 다음 정보들 중 적어도 하나를 포함할 수 있다. 이후 제 1단말(300)은 상기 정보를 포함한 정보를 QR 코드로 Encoding 하여 보여줄 수 있다 (5c-100 단계).

- seqNumber: 처리순번정보

- profileManagementOperation: 해당 프로파일이 삭제됐는지 구분자

- notificationAddress: 프로파일서버주소

- ICCID: 삭제된 프로파일 ID

- euiccNotificationSignature: 해당 프로파일의 ICCID를 증빙하고, 처리된 동작은 삭제됨을 의미하는 Indicator임을 증빙하고, 처리순번정보는 SEQ값임을 증빙하는데 사용되는 eUICC(160)의 디지털 서명

- eUICCCertificate: eUICC서명의 유효성을 증빙하는데 사용되는 eUICC인증서

- EUMCertificate: eUICC인증서의 유효성을 증빙하는데 사용되는 추가 인증서

한편, 이러한 QR코드는 제 2단말(350)에 프로파일 다운로드 설치를 위해 전달할 정보인데, 본 발명의 실시 예에 의하면 제 2단말(350)은 QR코드를 통해 얻은 정보의 일부 또는 전부를 최종적으로는 프로파일서버로 전달한다. 제 2 단말(350)은 QR코드를 스캔하여 프로파일 다운로드 절차를 개시할 수 있다. (5a-230 단계)에서 프로파일 Delete Notification으로 Activation Code를 생성하지 않고 (5c-95 단계, 5c-100 단계) 사업자로부터 Activation Code를 발급(5c-70 단계)받아서 설치하는 경우는 GSMA SGP.22에 v2에 정의된 절차에 따라 이후 프로파일 다운로드 절차를 수행할 수 있다. 만약, (5a-230 단계)에서 (5c-95 단계) 또는 (5c-100 단계)와 같이 프로파일 삭제를 처리하고 해당 삭제 정보를 활용하는 경우에 있어서 제 2단말(350)은 QR코드에 포함된 프로파일서버주소에 해당하는 프로파일서버로 해당 프로파일을 설치할 eUICC의eUICCChallenge포함하여 InitiateAuthenticate 메시지를 전송할 수 있다. 해당 프로파일 서버에서는 해당 값을 검증하여 Transaction ID를 생성하고 Transaction ID와 eUICCChallenge값이 포함된 데이터에 대한 프로파일 서버의 서명을 생성하여 회신할 수 있다. 이때 회신 하는 InitiateAuthenticate 회신 메시지는 상기 프로파일서명값, Transaction ID를 포함할 수 있다. 제 2단말(300)은 상기 InitiateAuthenticate 회신 메시지를 수신한 후, QR Code에 포함된 ICCID 및 제 1단말(300)의 eUICC서명데이터를 포함하는 Data와 이 데이터에 대해 제 2단말의 eUICC가 서명한 eUICC 서명 데이터를 생성하여 AuthenticateClientRequest 메시지에 포함하여 프로파일서버에 전송할 수 있다. 프로파일서버(150)는 상기 AuthenticateClientRequest를 메시지를 수신하면 AuthenticateClientRequest메시지에 포함된 이동할 프로파일의 ICCID, 제 1 단말(300)의 해당 프로파일이 설치된 eUICC의 서명Data 검증, 제 2단말(350)의 프로파일을 설치할 eUICC의 서명 Data 검증을 포함한 유효성 검증 과정을 수행하여, 해당 프로파일의 다운로드 여부를 결정하고, 해당 프로파일에 대응되는 ProfileMetadata를 포함한 데이터를 AuthenticateClientResponse메시지에 포함하여 회신할 수 있다. 또한, 상기 제 1단말의 eUICC(160)의 서명Data 검증은 상기 ICCID및 추가적인 데이터를 포함한 Data (처리 순번번호, 프로파일삭제 구분자, 프로파일 서버 주소, 삭제된 ㅍ로파일 ICCID, eUICC 서명 값)에 대해서 상기 제 1단말(300)의 eUICC(160)의 인증서를 이용한 서명검증일 수 있다. 이후 제 2단말(350)은 상기 AuthenticateClientResponse메시지를 수신하여 ProfileMetadata가 포함되어 있으면, 사용자에게 보여주는 UI를 통해 해당 프로파일의 수신을 동의 받는 과정을 수행하는 과정과, Confirmation Code 입력을 요청하여 입력 받는 과정과, 또한 eUICC의 one time Public key (otpk.eUICC)를 생성하는 과정 중 일부 또는 전체 과정을 수행할 수 있다. 이어 제 2단말(350)이 상기 otpk.eUICC를 포함하는 GetBoundProfilePackage Request 를 프로파일서버(150)에 전달하면, 프로파일서버는 otpk.eUICC를 활용하여 생성된 암호키로 암호화한 정보를 포함한 BoundProfilePackage 를 제 2단말(350) 회신할 수 있다. 제 2단말(350)은 BoundProfilePackage 를 수신하면, 프로파일을 제 2단말(350)의 eUICC 내부에 설치하여 모든 절차를 완료할 수 있다.

도 5d는 제 1단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience에 대한 대표적인 처리 절차를 나타낸 도면이다. 도 5d는 도 5a 내지도 5c의 절차 처리를 단말에 구현했을 때, 예상되는 사용자의 UI(User Interface) 및 UX(User Experience)의 일 예시이다. 숫자로 표기된 순서는 해당 절차 처리 순서이며, 3-A 내지 3-C로 표기된 순서는 해당 절차를 처리함에 있어 기기변경 방식 및 사업자 지원 방식에 따라 분기되는 시점을 나타낸 것이다. 사용자(100)은 제 1단말(300)의 단말 설정 등의 메뉴를 통해서 현재 해당 단말에 설치된 SIM 카드 정보를 확인할 수 있다. 예를 들어 SIM카드와 eUICC에 저장된 프로파일의 정보를 1번 그림과 같이 사용자에게 보여 줄 수 있다. 해당 화면에서 사용자는 이동할 프로파일을 선택(5d-10 단계)하거나 또는 별도의 메뉴(예. 모두 이동) 등을 통해서 1개 이상의 프로파일을 선택할 수 있다. 해당 이동할 프로파일을 선택하면 5d-20 단계 과 같이 해당 프로파일에 대한 어떤 명령을 처리할지를 단말이 수신할 수 있도록 별도의 메뉴 목록이 보여질 수 있으며 이 중의 하나로 기기 변경을 수행함을 나타내는 식별자로 별도 메뉴를 제공해 줄 수 있다. 해당 메뉴 진입은 신규 단말에서 처리하는 경우와 구별되게 메뉴를 처리하거나 또는 동일 기기 변경 메뉴에 진입을 하는 경우에라도 단말에서 사용자가 이동할 프로파일을 선택하고 해당 메뉴를 선택하는 경우에 제 1단말(300)로 인식하여 처리할 수도 있다. 해당 프로파일에 대한 기기 변경을 선택하는 경우에, 제 1단말(300)의 LPA1(510)에서 eUICC에 ES10c.GetProfilesInfo() Function Call을 수행하여 프로파일의 메타데이터 정보를 가져옴으로써, 해당 프로파일의 통신사업자의 고유 식별 번호로 MCC+MNC를 확인할 수도 있다. 또한, 이 때 해당 프로파일의 상태 정보도 확인할 수 있다. 단말은 사용자의 Interaction 없이 단말에서 사용자가 이동할 프로파일의 사업자 식별 번호를 획득하고 또한 이와 함께 해당 프로파일의 메타데이터 등을 통해 획득한 소정의 정보를 통해서 2번과 같은 화면을 구성하여 표기해 줄 수 있다. 사용자(100)가 해당 2번 화면의 5d-20 단계와 같이 기기 변경 메뉴 선택을 통해 기기 변경 요청을 발생 시키면, 단말은 도 4에서 전술한 바와 같이 통신사업자의 기기 변경 지원 여부 및 방식을 포함한 기기 변경에 대한 사업자 설정 정보를 획득하기 위한 절차를 시작하여 이동할 프로파일의 메타데이터, 또는 단말의 메모리, 또는 별도 Configuration Server로부터 획득한 정보를 통해서 단말에서 사용할 기기 변경 방식을 확정할 수 있다. 사용자(100)가 기기 변경 메뉴 선택 시(5d-20 단계)의 제 1단말(300)은 (5d-30 단계), (5d-40 단계), (5d-50 단계)과 같이 기기변경방식 지원 여부 및 방식에 따라 서로 다른 화면을 보여줄 수 있다. 5d-30 단계는 선택한 프로파일의 통신사가 기기변경 방식을 지원하지 않는 경우에 화면에 표기에 대한 예를 나타낸 것이다. 도 5d에서는 명시하지 않았으나, 5d-10 단계에서 프로파일을 선택하였을 때, 단말이 메타데이터 또는 단말의 메모리에서 사업자의 기기 변경 설정 정보를 가져오고, 해당 정보에 기기 변경 지원에 대한 정보가 없는 경우에 5d-20 단계의 메뉴 자체에 기기 변경 메뉴를 선택적으로 노출하지 않게 처리할 수도 있다. 이 경우에 기기 변경 지원 사업자의 경우에만 해당 기기 변경 메뉴를 노출시킬 수도 있다. 또한, eSIM Transfer 메뉴를 진입하는 5d-20 단계의 시점에 사업자가 EAP-AKA 방식을 지원 정보와 프로파일 상태 정보에 대해 판단하여, EAP-AKA 방식을 지원을 위해서는 프로파일을 Enabled해야 함을 사용자에게 알려줄 수도 있다. 단말이 5d-10 단계와 5d-20 단계에서 획득한 정보를 통해 확인한 결과로 LPA 방식으로 처리를 결정하는 경우, 해당 제 1단말(300)은 도 5c와 같이 SM-DP+를 통해 인증을 처리하고 LPA에 사전 설정되었거나 또는 SM-DP+를 통해 수신한 사업자 메시지를 단말 화면에 표시할 수 있다. 일 예로 5d-40 단계와 같이 해당 프로파일 이동에 대한 기존 프로파일 삭제에 대한 사용자 동의를 처리하기 위한 메시지를 표시해 줄 수 있다. 한편, 단말이 5d-10 단계와 5d-20 단계에서 획득한 정보를 통해 확인한 결과로 ODSA방식으로 처리를 결정하는 경우, 단말은 단말의 ODSA Client인 ODSA1(500)을 trigger하여 ODSA1(500)에서 ECS(120)에 기기변경 요청을 요청(5a-50 단계)하여 도 5a 또는 도5b와 같이 가입자 인증을 수행하고 해당 가입자 수행 인증을 결과로 가입자가 인증되는 경우에, 5d-50 단계와 같이 이동할 (프로파일의) 통신 서비스의 기기 이동 처리를 위한 정보에 대한 사업자의 웹 화면을 보여줄 수 있다. 해당 웹 화면의 구성은 사업자에 따라 달라질 수 있다. 만약 ODSA1(500)에서 ECS(120)로 단말에서 인증 식별자 없이 기기 변경 요청하는 경우에, ECS는 도6a의 6a-140단계와 같이 가입자 인증 방식으로 OAuth/Open ID를 선택할 수 있다. 이 경우, 단말은 ECS(120)로부터 사용자의 ID와 패스워드 입력을 요청하는 로그인 페이지를 회신 받아 사용자 화면에 Display(6c-70 단계)하여 ID 및 패스워드로 가입자 인증을 처리하고 나서, 5d-50 단계와 같은 화면으로 이동할 수 있다. EAP-AKA 방식 또는 ECS&DP+인증 방식을 전술한 바와 같이 단말 설정, 사용자 선택 또는 ECS 선택을 통해 결정한 경우에 사용자는 ID 생성 등과 같은 단말 UI에서의 Interaction 없이 가입자 인증 처리를 완료할 수 있다. LPA 또는 ODSA 방식으로 기기 변경을 진행하여 가입자 인증까지 완료되면, 제 1단말(300)은 Activation Code를 생성하여 제 2단말(350)에서 이를 획득하는 방법과 함께 제공(5d-60 단계) 할 수 있다. 5d-60 단계에서는 이를 QR코드 형태로 제공하는 방법을 도시하였으나 단말간 전송 프로토콜을 통해서 Activation Code 정보를 전달할 수도 있다. 이제 사용자(100)는 (5d-60 단계)에서 제공된 방법을 통해서 제 2단말의 LPA2(530)에 Activation Code 정보를 입력할 수 있다 (5d-70 단계, 5d-80 단계). 해당 정보가 입력되면 제 2단말(350)은 앞서 5a-230 단계에 전술한 바와 같이 프로파일 다운로드 및 설치하여 완료하고 해당 완료되면 사용자는 5d-90 단계의 예와 같이 제 1단말에서 통신프로파일의 재설치가 완료되었음을 확인할 수 있다. 한편, 5d-100 단계와 같이 기기 변경 처리가 완료된 프로파일은 제 1단말(300)의 사업자 정책 및 삭제 처리에 대한 사용자의 동의에 따라 제 1단말(300)의 프로파일 리스트에서 삭제 처리되어 더 이상 사용자에게 노출되지 않게 처리할 수 있다

도 6a 내지 도 6c 는 제 2단말(신 단말)에서 사용자가 기기 변경을 시작하는 절차들을 도시한다. 도 6a는 통신사가 ODSA 방식을 제공하며 OTP 또는 OAuth/Open ID 인증을 사용하는 실시 예를 나타내는 도면이다. End User(100)가 제 2단말에서 사용자가 기기변경을 진행할 통신사를 선택하고, 단말이 도 4에서 언급한 바와 같이 Configuration 정보를 획득함으로써, 단말에서 ODSA 방식으로 이후 기기변경 처리를 결정(6a-30 단계) 할 수 있다. 도 4에서 Configuration 정보 획득에 대한 상세 방법을 전술하였으므로 여기서는 추가 설명을 생략한다. 제 2단말(350)에서는 SMS 수신이 가능한 사용자 보유 단말이 있는지에 대한 메뉴를 생성하여 표시하고(6a-40 단계), 사용자(100)는 기존 단말(300)을 통해 인증 코드 수신이 가능한 경우에 모바일 네트워크에서 가입자를 식별하는 고유 번호인 가입자 전화 번호 즉, MSISDN을 화면에 입력(6a-60 단계) 할 수 있다. 한편, 앞서 명시하지 않았으나, 단말의 ODSA(110)과 ECS(120)간에는 HTTP(s)기반의 메커니즘을 사용하여 메시지를 주고 받는다. 해당 입력을 받은 제 2단말(350)의 ODSA2(520)은 해당 요청 단말(350)의 IMEI와 제 1단말(300)의 MSISDN를 포함하여 인증 요청 Https Request 메시지를 ECS(120)전송(6a-70 단계)할 수 있다. 해당 메시지를 전송 받은 ECS(120)는 해당 메시지를 parsing하여 MSISDN값이 있는 경우에, ECS(120)은 End User(100)가 제공한 MSISDN으로 OTP를 전송(6a-90 단계)하는 한편, HTTP(S) 200 OK 에 Cookie를 포함하여 ODSA2(520)에 전송(6a-80 단계) 할 수 있다. 해당 ODSA2(520)은 End User가 제 1단말을 통해 수신하여 입력한 OTP 파라미터와 이전의 HTTP 200 OK response로부터 수신된 Cookie를 포함하여 새로운 Get Request를 ECS(120)에 회신(6a-110 단계) 할 수 있다. ECS(120)는 수신된 OTP를 검증하고, ECS에서 새로운 인증토큰을 생성하여 ODSA2(520)에 회신(6a-120 단계) 할 수 있다. 이후 ODSA2는 해당 인증토큰(AuthToken)을 포함하여 기기변경을 ECS(120)에 요청(6a-130 단계) 할 수 있다. 전술한 바와 같이 기기 변경 처리를 위한 프로파일 설치를 위한 기기 변경설정 정보를 획득하고 단말의 서비스 상태를 검증하기 위해서 ODSA(110)은 ECS(120)에 HTTP(s) Request를 전송하면 ECS에서는 해당 요청을 처리하여 ODSA에서 결과값을 회신할 수 있다. 한편, ECS(120)는 수신된 Get request에서 EAP_ID, DP+AuthSupport, 또는 MSISDN이 포함되지 않았거나 또는 단말에서 제공하는 해당 또는 다른 인증 하는 수단이 사용 가능하지 않다고 표기된 경우에, OAuth/Open ID 인증(6a-140) 을 단말에 요청할 수 있다. 다음은 OAuth/Open Id 인증(6a-100 단계) 수행에 대한 방법을 좀 더 상세하게 설명한다. 제 2단말(350)에서 시작하는 경우에 기존 단말(300)이 사용 불가(6a-40 단계)하여 ECS에서 MSISDN 정보를 수신하지 못하면, ECS는 사용 가능한 인증 수단이 없으므로 해당 수신 받은 GET request를 단말의 ODSA Client로부터 Service Provider의 인증 서버로 재전송하기 "302 Found" 를 Response로 회신할 수 있다. 해당 "302 Found"에 Open ID 처리를 위해 Redirect할 인증 포인트의 URL 주소를 전술한 바와 같이 Header의 Location 값으로 전송할 수 있다. 또한, "302 Found"의 본문 메시지로, response type=code와 함께 scope의 value로 "openid"를 포함하여 scope= openid 와 같이 회신할 수 있다. 'openid'는 Scope 파라미터가 가질 수 있는 값 중의 하나로, 애플리케이션이 Open ID Connect 표준 프로토콜을 사용자 신원 확인에 사용하고자 함을 나타낼 수 있다. Response type=code는 해당 Location에 표기된 인증 서버로부터 code를 회신해야 함을 나타내는 식별자로 사용될 수 있다.

Open ID 인증 서버(Redirect할 인증 포인트)는 해당 서비스 사업자의 정책에 따라 인증 방식을 선택(추가적인 SMS 인증 등)해 사용자(100)를 인증하고 이에 대한 결과로 code값을 회신할 수 있다. 여기서는 OAuth2.0 인증코드(접속 토큰으로 교환을 위해 제공되는 임시 코드)를 단말에 회신할 수 있다. 단말은 ECS(120)에 "302 Found"에 대한 회신 값으로 해당 인증코드를 포함하여 송신한다. ECS(120)가 해당 인증코드를 받으면, ECS(120)는 해당 인증코드를 Open ID 인증 서버에 송신하여 접속 토큰과 ID 토큰을 요청할 수 있다. Open ID 인증 서버가 OAuth2.0 인증코드를 검증하여 승인되면, ECS(120)에 접속 토큰과 ID 토큰을 회신할 수 있다. ECS(120)는 해당 토큰 값들을 가지고 해당 사용자의 가입자 정보를 확인할 수 있고 original GET resource 요청을 재개하여 기기 변경에 대한 이후 절차를 수행할 수 있다. ECS(120), SM-DP+(150), MNO BSS/OSS(130)간 가입자의 통신서비스에 대한 가입자 정보 업데이트와 프로파일 생성에 대한 절차는 앞서 도 5a에서 설명한 바 있으므로 자세한 설명은 생략한다. 한편, 해당 절차를 처리하고 나서 ECS(120)은 MNO BSS/OSS(130) 또는 SM-DP+(150)로부터 해당 프로파일의 다운로드에 필요한 소정의 정보로 Activation Code를 전달 받아 이를 ODSA2(520)에 전송해 주고, ODSA2(520)가 LPA API를 통해 해당 에 Activation Code 정보를 LPA2(530)에 전달함으로써, LPA2(530)가 SM-DP+(150)에서 프로파일 다운로드를 Trigger하여 GSMA SGP.22에 정의된 절차에 따라서 프로파일 다운로드 및 설치를 처리를 완료(5a-230 단계) 할 수 있다.

도 6b는 통신사가 LPA 방식을 제공하며 제 1단말(구 단말)에서 LPA와 SM-DP+인증을 사용하는 실시 예를 나타내는 도면이다.

도 5a에서 전술한 바와 End User(100)가 제 2단말에서 사용자가 기기변경을 진행할 통신사를 선택하고, 단말이 도 4에서 언급한 바와 같이 Configuration 정보를 획득하여 해당 조합을 통해, 사업자의 기기변경 방식을 LPA임을 확인할 수 있다. 단말은 이 경우 LPA 방식으로 처리(6b-10 단계)를 결정하여 진행할 수 있다. 제 2단말(350)에서 본 발명을 개시하는 현 시점에는 LPA 방식을 처리할 수 있는 방법이 없으므로, 단말은 사용자에게 기존 단말의 사용 여부를 확인하는 메시지를 제 2단말(350)의 화면에 Display(6b-20 단계) 할 수 있다. LPA 기반 기기 변경 방식은 기존 단말의 프로파일 상태 정보와 관계 없이 제공 가능하므로, 6b-20에서의 기존 단말의 사용 여부 메시지는 6a-40 단계와 다르게 처리할 수 있다. 예를 들어 6a-40 단계의 메시지는 기존 단말의 사용 여부 및 SMS 수신 가능한 단말인지 여부를 함께 확인할 수 있으나, 6b-20 단계에서는 기존 단말의 사용 여부만 확인하여 처리가 가능할 수 있다. 사용자가 해당 제 2단말(350)에서 제 1단말(300) 사용이 가능하다고 입력 (6b-30 단계)한 경우, 제 2단말(350)은 (6b-40 단계)과 같이 제 1단말(300)에서 LPA 절차를 통해 기기 변경절차를 처리하도록 할 수 있다. 한 예로, 사용자(100)가 이후 절차를 제 1단말에서 진행할 수 있도록 제 2단말(350)의 화면에 제 1단말(300)에서 도 5c의 5c-10 단계에서 5c-100 단계의 절차로 처리(6b-50 단계)하라고 안내 메시지를 생성하여 표기한 다음에, 제 2단말(350)의 화면은 Activation Code 수신을 위한 LPA2(530)의 화면으로 이동하여 대기할 수 있다. 해당 처리에 대한 UI/UX는 도 6c에서 후술하기로 한다. 사용자(100)는 이제 5c에서 전술한 바와 같이 제 1단말에서 LPA 기반 기기 변경을 처리하고 Activation Code를 수신(5c-70 단계)또는 생성(5c-100 단계)하여 화면에 Display하게 되면, 제 2단말(350)은 LPA2(530)에서 카메라를 통해 해당 Display된 Activation Code 스캔(5c-110 단계)을 통해 해당 정보를 입력 받아 Activation Code에서 추출한 SM-DP+서버 주소로 접속, 프로파일 다운로드 및 설치를 완료할 수 있다. 만약 단말이 사용자가 제 1단말(300)이 없다고 입력 받는 경우(6b-30 단계)에, 단말은 통신사업자로 문의하라는 사용자 안내 메시지를 표시하고(6b-50 단계) 모든 절차를 종료할 수 있다.

도 6c는 제 2단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience에 대한 대표적인 처리 절차를 나타낸 도면이다. 도 6c는 사용자가 제 2단말(350)에서 기기변경을 시작하는 경우로 도 6a 및 도 6b가 구현된 UI/UX를 대표적으로 나타낸 도면이다. 해당 제 2단말(350)에서 시작하는 시나리오에서 핸드폰 화면의 (4-A, 4-B)와 (6-A, 6-B)는 대표적으로 분기되는 시점을 나타낸다. 사용자가 제 2단말(350)에서 기기변경을 메뉴에 진입(6c-20 단계)하면 단말은 도 4에서 전술한 바와 같이, 기기 변경에 대한 사업자 Configuration 정보를 수집하여 화면에 표시할 수 있다(6-30 단계). 예를 들어, Configuration Server를 이용(도 4의 옵션 3)하거나 메모리에 저장된 정보(도 4의 옵션 4)를 통해 획득한 모든 통신사업자 정보를 나열할 수 있고 또는 해당 정보에서 추가적으로 단말의 위치 정보 등을 조합하여 해당 지역에서 기기변경을 제공 가능한 사업자 만을 추출한 다음에 화면에 해당 리스트를 노출할 수도 있다. 다른 예로, 사용자(100)가 프로파일 이동을 진행할 통신사업자 정보를 제공하면, 도 4의 옵션2와 같이 단말에서 해당 선택한 통신사업자 이름 또는 해당 통신사업자의 MCC+MNC를 Configuration Server 또는 단말에 메모리에서 확인하여 맵핑 되는 사업자의 정보만을 선택적으로 띄워줄 수도 있다. 이 경우에, 확인하여 만약 해당 사업자가 기기 변경을 미 지원하는 경우, 도 6c에서는 도시하지 않았으나, 6c-30 단계 다음에 6c-40 단계 또는 6c-90 단계로 진입하지 않고 별도 안내 메시지를 화면에 띄워주고 해당 절차를 종료할 수 있다. 6c-30 단계에서 사용자(100)이 사업자를 선택하면 확인한 해당 사업자의 기기변경 지원 방식에 따라 단말은 6c-40 단계 또는 6c-90 단계의 화면으로 분기하여 처리할 수 있다. 6c-40 단계로 처리시는 선택 통신사가 ODSA 기반 기기 변경을 지원하는 경우로 이 때, 단말은 6c-50 단계와 같이 기존 단말의 보유 유무에 대한 추가 메뉴를 제공하고 사용자의 응답에 따라 단말에서 제공하는 SMS-OTP 인증 진행 화면(6c-60 단계) 또는 ECS(120)로부터 302 Found Http(s) Response 를 통해 수신된 Location Header에 있는 URL로 연결 처리하여, 사업자 제공 화면(6c-70 단계)을 표시할 수 있다. 해당 인증 방식에 따라 가입자 인증이 처리 완료되면, 제 2 단말의 통신서비스 가입 앱 또는 웹 포탈에서 Activation Code 정보를 수신하여, LPA2(530)로 LPA API를 통해 해당 Activation Code 정보를 전달하고, 이를 수신한 LPA2(530)가 프로파일 다운로드 처리/설치를 모두 완료하면, 6c-80 단계와 같이 이동할 프로파일이 설치되었음으로 사용자(100)에게 표기하여 보여줄 수 있다. 한편, 6c-30 단계를 통해서 단말이 판단한 사업자의 기기 변경 지원 방식이 LPA 방식인 경우에, 제 2단말(350)에서는 6c-90 단계와 같이 사용자에게 기존 단말(300)의 보유 여부에 따라 처리 여부가 달라짐을 알려주고 만약 기존 단말(300)이 사용 불가한 경우, 6c-100 단계와 같이 사업자 Contact 메시지를 띄우고 모든 절차를 종료할 수 있다. 한편, 사용이 가능하다고 응답하는 경우에, 추가적인 안내 메시지를 생성하여 사용자가 제 1단말(300)에서 처리할 수 있도록 안내하고 Scan QR 코드 등 Activation Code가 입력을 위한 절차에서 대기할 수 있다(6c-110 단계). 단말의 설정에 따라 Timer를 통해 사용자의 응답(예. Activation Code 입력)이 일정 시간 동안 발생하지 않는 경우에 단말은 사용자 안내 메시지를 띄우고 기기 변경 절차를 종료하거나 대기를 연장할 수 있다. 한편, 사용자는 도5d에서의 제 1단말(300)에서 LPA 처리 절차를 따라서 기기 변경을 진행하고 Activation Code를 발급받으면, 6c-110 단계의 예와 같이 제 2단말(350)에서 Activation Code 수신을 위한 메뉴 선택을 통해 도 5d의 이후 절차를 처리하여 기기 변경을 완료할 수 있다.

도 7은 본 발명의 실시 예에 따른 무선 통신 시스템에서 단말의 블록 구성을 도시한다.

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

또한, 송수신부(710)는 무선 채널을 통해 신호를 수신하여 프로세서(730)로 출력하고, 프로세서(730)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다. 도 7에서 하나의 안테나만이 도시되었으나, 상기 단말은 다수의 안테나들을 구비할 수 있다. 또한, 송수신부(710)에는 복수의 RF 체인들을 포함할 수 있다.

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

또한, 데이터 수신 시, 기저대역 처리부는 RF처리부로부터 제공되는 기저대역 신호를 OFDM 심벌 단위로 분할하고, FFT(fast Fourier transform) 연산을 통해 부반송파들에 매핑된 신호들을 복원한 후, 복조 및 복호화를 통해 수신 비트열을 복원할 수 있다.

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

제어부(730)는 단말(700)의 전반적인 동작들을 제어한다. 예를 들어, 제어부(730)는 메시지 처리부(720)를 통해 신호를 송수신한다. 또한, 제어부(730)는 메모리(740)에 데이터를 기록하고 읽는다. 제어부(730)는 적어도 하나일 수 있다. 예를 들어, 제어부(730)는 통신을 위한 제어를 수행하는 CP(communication processor) 및 응용 프로그램 등 상위 계층을 제어하는 AP(application processor)를 포함할 수 있다. 일부 실시 예에 따르면, 메모리(740)에 사전에 저장된 기기 변경에 대한 사업자 Configuration 정보가 있는 경우에 제어부(730)는 해당 정보를 메모리(740)에 요청하여 화면표시부(850)가 표시하거나 해당 정보를 받아서 추가적인 동작을 처리할 수 있다.

상기 제어부(730) 및 메시지 처리부(720), 송수신부(710)는 사용자 또는 단말 설정에 따라 선택한 사업자 망으로의 접속을 수행하도록 단말(700)을 제어할 수 있다. 또한, 일부 실시예에 따르면, 제어부(730)는 메모리(740)를 통해서 읽은 데이터 기록, 또는 제어부(730) 및 메시지 처리부(720), 송수신부(710)를 통해 수집된 정보를 매칭하여 서비스 선택에 참조할 수 있는 정보를 단말이 추론하는 처리 과정을 수행할 수 있다. 일부 실시예에 따르면, 제어부(730)는 단말(700)에 저장된 특정 정보에 대한 사용자 동의가 필요한지 여부를 판단하고, 화면 표시부(850)에 표시할 수 있다.

또한, 제어부(730)는 이에 대응하는 동작을 수행하도록 단말(700)을 제어할 수 있다. 일부 실시 예에 따르면, 제어부(730)는 eUICC의 구동 및 제어를 담당하는 LPA, 통신서비스 가입 및 기기 변경 처리를 위한 ODSA Client, 그리고 LPA 또는 ODSA Client 또는 이 둘이 통합 구현된 애플리케이션을 포함할 수 있다. 또한, 제어부(730)는 제어부(730), 메모리(740)를 통해 기기 변경에 필요한 소정의 정보를 취득하여 통신 서비스 기기 변경을 위해 LPA 또는 ODSA Client 동작이 필요한지를 판단하여 이후 과정을 처리할 수 있다. 또한, 제어부(730)는 메시지 처리부(720), 송수신부(710)를 통해 수집된 통신사업자가 제공 가능한 기기 변경 정보를 취득하여, 단말(700)의 메모리(740)를 통해 파악한 기기 변경 추가 정보 및 제어부(730)를 통해 취득한 프로파일 상태 정보와 결합하여 LPA 또는 ODSA 기기 변경 방식 중 어떤 방식으로 처리할 지와 어떤 인증 방식을 적용할 지 단말(700)을 제어할 수 있다.

제어부(730)는 메시지 처리부(720), 송수신부(710), 메모리(740)로부터 취득한 단말의 Capability 정보. 사업자의 기기변경 방식 정보와 화면 표시부(850)에서 입력된 소정의 정보를 조합하여 단말에서 프로파일 이동을 지원할지 여부를 판별하고 지원하는 경우에, 제 1단말 또는 제 2단말의 역할로 수행할지, 그리고 어떤 기기 변경 방식 절차로 진행할지를 여부를 판별할 수 있다.

제어부(730)는 메모리(740)에 기기 변경에 대한 사업자의 기기 변경 지원 유무, 지원 방식 및 지원을 위해 연결할 Configuration Server 주소, ECS 또는 DP+서버 주소, 또는 지원하는 가입자 인증 방식 등을 확보하기 위한 요청을 전송하여 처리하도록 단말(700)을 제어할 수 있다. 일부 실시 예에 따르면, 단말의 인증 방식 지원 Capability에 추가적으로 기기변경 Configuration 정보를 메모리(740)로부터 받아 메시지 처리부(720) 및 메시지 송수신부(710)을 통해서 ECS 서버로 정보를 전송하거나 특정 파라미터를 선택하여 메시지 처리부(720) 및 메시지 송수신부(710)을 통해서 정보를 전송할 수 있다. 또한, 프로세서(840)는 단말이 EAP-AKA 기능을 해당 시점에서 제공하지 못한다고 판단하는 경우(예를 들어 프로파일이 비 활성화 되어 있는 경우), EAP-AKA 처리를 위한 동작을 제한하도록 단말(700)을 제어할 수 있다.

메모리(740)는 단말(700)의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 메모리(740)는 단말에 내장된 하드웨어 보안 모듈인 UICC, eUICC, iSSP, iUICC를 포함할 수 있다. 실시 예에서는 메모리(740)는 롬(ROM), 램(RAM), 하드디스크, CD-ROM 및 DVD 등과 같은 저장 매체 또는 저장 매체들의 조합으로 구성되며 제어부(730)의 요청에 따라 Transfer Configuration 등 저장된 데이터를 제공할 수 있다. 또한, 메모리(740)은 제어부(730)와 SoC(System on Chip)으로 통합 구현되어 있을 수 있다.

화면표시부(850)는 제어부(730)에서 처리/가공한 정보를 표시하거나 제어부(730) 처리를 통해 단말(700)이 수행하는 동작에 대한 진행 과정 또는 사용자에게 수행을 요청하는 event에 대한 동의 등을 표시할 수 있다. 일부 실시 예에 따르면, 저장된 프로파일 정보, 프로파일 기기간 이동 메뉴, Activation Code에 대한 입력 및 입력된 결과를 사용자에게 회신하여 표시할 수 있다. 일부 실시 예에 따르면, LPA 또는 ODSA 애플리케이션, 또는 이 둘이 통합 구현된 애플리케이션은 화면표시부(850)와 제어부(730)를 포함할 수 있다. 물론 상기 예시에 제한되지 않는다.

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

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

Claims (1)

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

Images