KR20220017212A - 기기 간 번들 또는 프로파일 이동 시 연계 방법 및 장치 - Google Patents
기기 간 번들 또는 프로파일 이동 시 연계 방법 및 장치 Download PDFInfo
- Publication number
- KR20220017212A KR20220017212A KR1020200097436A KR20200097436A KR20220017212A KR 20220017212 A KR20220017212 A KR 20220017212A KR 1020200097436 A KR1020200097436 A KR 1020200097436A KR 20200097436 A KR20200097436 A KR 20200097436A KR 20220017212 A KR20220017212 A KR 20220017212A
- Authority
- KR
- South Korea
- Prior art keywords
- bundle
- terminal
- profile
- ssp
- information
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/40—Security arrangements using identity modules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
- H04W8/20—Transfer of user or subscriber data
- H04W8/205—Transfer to or from user equipment or user record carrier
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
- H04W8/183—Processing at user equipment or user record carrier
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 개시는 스마트 보안 매체 간 번들 또는 프로파일 이동에 있어 가능한 다양한 옵션을 자연스럽게 연계하기 위한 방법 및 장치를 개시한다.
Description
본 개시는 스마트 보안 매체에 관한 것으로, 보다 상세하게는, 스마트 보안 매체 간 번들 또는 프로파일 이동을 위한 다양한 옵션을 연계시키는 방법 및 장치에 관한 것이다.
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은 본 개시의 실시 예에 따른 SSP의 개념도를 나타낸다.
도 2는 본 개시의 실시 예에 따른 SSP의 내부 구조에 대한 개념도를 나타낸다.
도 3은 본 개시의 실시 예에 따른 단말이 SSP로 번들을 다운로드하고 설치하기 위해 사용되는 단말 내 구성 요소의 예를 도시하는 도면이다.
도 4는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들 혹은 번들과 연관된 서비스가 오프라인 혹은 온라인 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 5는 본 개시의 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 번들 혹은 번들과 연관된 서비스를 이동하기 위해 준비하는 절차를 도시하는 도면이다.
도 6은 본 개시의 실시 예에 따른 번들의 오프라인 이동 절차를 도시하는 도면이다.
도 7은 본 개시의 실시 예에 따른 번들 혹은 번들과 연관된 서비스의 온라인 이동 절차를 개념적으로 도시하는 도면이다.
도 8은 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제2 단말이 번들 관리 서버로부터 온라인 이동 승인을 받는 절차를 도시하는 도면이다.
도 9는 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제1 단말이 번들 관리 서버의 요청에 따라 이동하고자 하는 서비스와 연관된 번들에 대해 일련의 작업을 수행하는 절차를 도시하는 도면이다.
도 10은 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제2 단말이 번들 관리 서버로부터 번들을 다운로드 받아 설치하는 절차를 도시하는 도면이다.
도 11은 하나의 단말에서 다른 단말로 번들 혹은 번들과 연결된 서비스가 오프라인 혹은 온라인 이동되는 전체 과정의 한 가지 예를 도시하는 도면이다.
도 12는 본 개시의 일부 실시 예에 따른 SSP가 탑재된 단말의 구성을 도시하는 도면이다.
도 13은 본 개시의 일부 실시 예에 따른 번들 관리 서버의 구성을 도시하는 도면이다.
도 14는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연관된 서비스가 오프라인 혹은 온라인 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 15는 본 개시의 일 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 프로파일 혹은 프로파일과 연관된 서비스를 이동하기 위해 준비하는 절차를 도시하는 도면이다.
도 16은 본 개시의 실시 예에 따른, 프로파일의 오프라인 이동 절차를 개념적으로 도시하는 도면이다.
도 17은 본 개시의 실시 예에 따른 도 16에서 제시된 절차 중 제1 단말과 제2 단말 간 상호 인증이 수행되는 세부 절차를 도시하는 도면이다.
도 18은 본 개시의 실시 예에 따른 도 16에서 제시된 절차 중, 제1 단말로부터 제2 단말로 프로파일이 전송되고, 전송된 프로파일이 제2 단말에 설치되는 세부 절차를 도시하는 도면이다.
도 19는 본 개시의 일 실시 예에 따른 하나의 단말에서 사용되던 프로파일과 연관된 서비스가 온라인 방식을 이용해 다른 단말로 이동되는 절차를 개념적으로 도시하는 도면이다.
도 20은 본 개시의 실시 예에 따른 도 19에서 제시된 절차 중 제2 단말이 RSP 서버로부터 프로파일과 연관된 서비스의 이동 승인을 받는 절차를 도시하는 도면이다.
도 21은 본 개시의 실시 예에 따른 도 19에서 제시된 절차 중 제1 단말이 RSP 서버의 요청에 따라 이동하고자 하는 서비스와 연관된 프로파일에 대해 일련의 작업을 수행하는 절차를 도시하는 도면이다.
도 22는 본 개시의 일 실시 예에 따른 도 19에서 제시된 절차 중 제2 단말이 RSP 서버로부터 프로파일을 다운로드 받아 설치하는 절차를 도시하는 도면이다.
도 23은 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연결된 서비스가 오프라인 혹은 온라인 이동 방식을 통해 전달되는 전체 과정의 한 가지 예를 도시하는 도면이다.
도 24는 본 개시의 일부 실시 예에 따른 eUICC가 탑재된 단말의 구성을 도시하는 도면이다.
도 25는 본 개시의 일부 실시 예에 따른 RSP 서버의 구성을 도시하는 도면이다.
도 2는 본 개시의 실시 예에 따른 SSP의 내부 구조에 대한 개념도를 나타낸다.
도 3은 본 개시의 실시 예에 따른 단말이 SSP로 번들을 다운로드하고 설치하기 위해 사용되는 단말 내 구성 요소의 예를 도시하는 도면이다.
도 4는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들 혹은 번들과 연관된 서비스가 오프라인 혹은 온라인 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 5는 본 개시의 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 번들 혹은 번들과 연관된 서비스를 이동하기 위해 준비하는 절차를 도시하는 도면이다.
도 6은 본 개시의 실시 예에 따른 번들의 오프라인 이동 절차를 도시하는 도면이다.
도 7은 본 개시의 실시 예에 따른 번들 혹은 번들과 연관된 서비스의 온라인 이동 절차를 개념적으로 도시하는 도면이다.
도 8은 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제2 단말이 번들 관리 서버로부터 온라인 이동 승인을 받는 절차를 도시하는 도면이다.
도 9는 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제1 단말이 번들 관리 서버의 요청에 따라 이동하고자 하는 서비스와 연관된 번들에 대해 일련의 작업을 수행하는 절차를 도시하는 도면이다.
도 10은 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제2 단말이 번들 관리 서버로부터 번들을 다운로드 받아 설치하는 절차를 도시하는 도면이다.
도 11은 하나의 단말에서 다른 단말로 번들 혹은 번들과 연결된 서비스가 오프라인 혹은 온라인 이동되는 전체 과정의 한 가지 예를 도시하는 도면이다.
도 12는 본 개시의 일부 실시 예에 따른 SSP가 탑재된 단말의 구성을 도시하는 도면이다.
도 13은 본 개시의 일부 실시 예에 따른 번들 관리 서버의 구성을 도시하는 도면이다.
도 14는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연관된 서비스가 오프라인 혹은 온라인 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 15는 본 개시의 일 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 프로파일 혹은 프로파일과 연관된 서비스를 이동하기 위해 준비하는 절차를 도시하는 도면이다.
도 16은 본 개시의 실시 예에 따른, 프로파일의 오프라인 이동 절차를 개념적으로 도시하는 도면이다.
도 17은 본 개시의 실시 예에 따른 도 16에서 제시된 절차 중 제1 단말과 제2 단말 간 상호 인증이 수행되는 세부 절차를 도시하는 도면이다.
도 18은 본 개시의 실시 예에 따른 도 16에서 제시된 절차 중, 제1 단말로부터 제2 단말로 프로파일이 전송되고, 전송된 프로파일이 제2 단말에 설치되는 세부 절차를 도시하는 도면이다.
도 19는 본 개시의 일 실시 예에 따른 하나의 단말에서 사용되던 프로파일과 연관된 서비스가 온라인 방식을 이용해 다른 단말로 이동되는 절차를 개념적으로 도시하는 도면이다.
도 20은 본 개시의 실시 예에 따른 도 19에서 제시된 절차 중 제2 단말이 RSP 서버로부터 프로파일과 연관된 서비스의 이동 승인을 받는 절차를 도시하는 도면이다.
도 21은 본 개시의 실시 예에 따른 도 19에서 제시된 절차 중 제1 단말이 RSP 서버의 요청에 따라 이동하고자 하는 서비스와 연관된 프로파일에 대해 일련의 작업을 수행하는 절차를 도시하는 도면이다.
도 22는 본 개시의 일 실시 예에 따른 도 19에서 제시된 절차 중 제2 단말이 RSP 서버로부터 프로파일을 다운로드 받아 설치하는 절차를 도시하는 도면이다.
도 23은 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연결된 서비스가 오프라인 혹은 온라인 이동 방식을 통해 전달되는 전체 과정의 한 가지 예를 도시하는 도면이다.
도 24는 본 개시의 일부 실시 예에 따른 eUICC가 탑재된 단말의 구성을 도시하는 도면이다.
도 25는 본 개시의 일부 실시 예에 따른 RSP 서버의 구성을 도시하는 도면이다.
이하에서는 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성한다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
본 개시에서, 용어를 지칭하는 제1, 제2 등의 수식어는, 실시예를 설명하는 데에 있어서 각 용어들을 서로 구분하기 위하여 사용될 수 있다. 제1, 제2 등의 수식어가 수식하는 용어는 서로 상이한 대상을 지칭할 수 있다. 그러나, 제1, 제2 등의 수식어가 수식하는 용어는 동일한 대상을 지칭할 수도 있다. 즉, 제1, 제2 등의 수식어는 동일한 대상을 서로 다른 관점에서 지칭하기 위하여 사용될 수도 있다. 예를 들면, 제1, 제2 등의 수식어는 동일한 대상을 기능적 측면 또는 동작의 측면에서 구분하기 위하여 사용될 수도 있다. 예를 들면, 제1 사용자 및 제2 사용자는 동일한 사용자를 지칭할 수도 있다.
또한, 본 개시에서는 SSP 및 UICC를 보안 매체의 예로 들어 각 실시예들을 설명하지만, 본 개시의 권리범위가 SSP 및 UICC에 의한 것으로 제한되지는 않는다. 예를 들면, SSP 및 UICC와 실질적으로 동일 또는 유사한 기능을 수행하는 다른 보안 매체에도, 이하 설명할 다양한 실시예들이 실질적으로 동일 또는 유사하게 적용될 수 있음은 해당 기술분야의 통상의 기술자들에게 자명하다.
이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
"SE(Secure Element)"는 보안 정보(예: 이동통신망 접속 키, 신분증/여권 등의 사용자 신원확인 정보, 신용카드 정보, 암호화 키 등)를 저장하고, 저장된 보안 정보를 이용하는 제어 모듈(예: USIM 등의 망 접속 제어 모듈, 암호화 모듈, 키 생성 모듈 등)을 탑재하고 운영할 수 있는 단일 칩으로 구성된 보안 모듈을 의미한다. SE는 다양한 전자 장치(예: 스마트폰, 태블릿, 웨어러블 장치, 자동차, IoT 장치 등)에 사용될 수 있으며, 보안 정보와 제어 모듈을 통해 보안 서비스(예: 이통통신 망 접속, 결제, 사용자 인증 등)를 제공할 수 있다.
SE는 UICC(Universal Integrated Circuit Card), eSE (Embedded Secure Element), UICC와 eSE가 통합된 형태인 SSP(Smart Secure Platform)등으로 나뉠 수 있으며, 전자 장치에 연결 또는 설치되는 형태에 따라 탈착식(Removable), 고정식(Embedded), 그리고 특정 소자 또는 SoC(system on chip)에 통합되는 통합식(Integrated)으로 세분화 될 수 있다.
"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 제조시 탑재되거나 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 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)을 지칭할 수도 있다.
"eSE(Embedded Secure Element)"는 전자 장치에 고정하여 사용하는 고정식 SE를 의미한다. eSE는 통상적으로 단말 제조사의 요청에 의해 제조사 전용으로 제조되며, 운영체제와 프레임워크를 포함하여 제조될 수 있다. eSE에는 원격으로 애플릿 형태의 서비스 제어 모듈이 다운로드되어서 설치될 수 있고, 설치된 서비스 제어 모듈은 전자지갑, 티켓팅, 전자여권, 디지털키 등과 같은 다양한 보안 서비스 용도로 사용될 수 있다. 본 개시에서는 원격으로 서비스 제어 모듈이 다운로드되어서 설치될 수 있고, 전자 장치에 부착된 단일 칩 형태의 SE를 eSE로 통칭한다.
"SSP(Smart Secure Platform)"는 UICC의 기능 및 eSE의 기능의 통합 지원이 가능한 단일 칩을 의미한다. SSP는 탈착식(rSSP, Removable SSP), 고정식(eSSP, Embedded SSP) 그리고 SoC에 내장된 통합식(iSSP, Integrated SSP)로 구분 될 수 있다. SSP는 하나의 프라이머리 플랫폼(PP, Primary Platform)과 PP상에서 동작하는 적어도 하나의 세컨더리 플랫폼 번들(SPB, Secondary Platform Bundle)을 포함할 수 있으며, 프라이머리 플랫폼은 하드웨어 플랫폼과 low level Operating System(LLOS)을 중 적어도 하나를 포함할 수 있고, 세컨더리 플랫폼 번들은 High-level Operating System(HLOS) 및 HLOS 위에서 구동되는 애플리케이션 중 적어도 하나를 포함할 수 있다. 세컨더리 플랫폼 번들은 SPB 또는 번들이라고 불리기도 한다. 번들은 PP가 제공하는 Primary Platform Interface (PPI)를 통해 PP의 중앙처리장치, 메모리 등의 자원에 접근하고 이를 통해 PP상에서 구동될 수 있다. 번들에는 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재될 수 있으며, 또한 전자지갑, 티켓팅, 전자여권, 디지털 키 등과 같은 다양한 응용 어플리케이션이 탑재될 수 있다. 본 개시에서 SSP는 스마트 보안 매체로 명명될 수도 있다.
SSP는 다운로드 되고 설치되는 번들에 따라서 상술한 UICC 또는 eSE의 용도로 사용될 수 있으며, 복수개의 번들이 단일 SSP에 설치되고 동시에 운영됨으로써 SSP는 UICC와 eSE의 용도를 혼용한 용도로 사용될 수 있다. 즉, 프로파일을 포함하는 번들이 동작하는 경우 SSP는 이동통신사업자의 망에 접속하기 위한 UICC 용도로 사용 될 수 있다. UICC 번들에는 상술한 eUICC 또는 iUICC와 같이 적어도 하나 이상의 프로파일이 원격에서 번들 내로 다운로드 되고 그 중 어느 하나 이상의 프로파일이 선택될 수 있다. 또한, SSP상에서 전자지갑, 티켓팅, 전자여권 또는 디지털키 등의 서비스를 제공할 수 있는 응용 어플리케이션을 탑재한 서비스 제어 모듈을 포함하는 번들이 동작하는 경우 SSP는 상술한 eSE의 용도로 사용될 수 있다. 다수의 서비스 제어 모듈은 하나의 번들에 통합되어 설치되고 동작하거나, 각기 독립적인 번들로 설치되고 동작할 수 있다.
SSP에는 OTA(Over The Air)기술을 이용하여 외부의 번들 관리 서버(Secondary Platform Bundle Manager, SPB Manager)로부터 번들이 다운로드되어 설치될 수 있고, 또한, 다른 단말로부터 번들이 전송되어 설치될 수도 있다. 본 개시에서 다운 혹은 전송 받은 번들이 설치되는 방법은 단말에 삽입 및 탈거가 가능한 착탈식 SSP(rSSP), 단말에 설치되는 고정식 SSP(eSSP), 단말에 설치되는 SoC내부에 포함되는 통합식 SSP(iSSP)에 동일하게 적용될 수 있다.
"SSP 식별자(SSP ID)"는, 단말에 내장된 SSP의 고유 식별자로서 sspID로 지칭될 수 있다. 또한, 본 개시의 실시 예에서와 같이 단말과 SSP 칩이 분리되지 않을 경우에는 SSP ID는 단말 ID일 수 있다. 또한, SSP ID는 SSP 내의 특정한 번들 식별자(SPB ID)를 지칭할 수도 있다. 좀더 자세히는, SSP ID는 SSP에서 다른 번들을 설치, 활성화, 비활성화, 및 삭제를 관리하는 관리 번들 또는 로더(SPBL, Secondary Platform Bundle Loader)의 번들 식별자를 지칭 할 수도 있다. 또한, SSP ID는 SSP 내에 있는 프라이머리 플랫폼의 아이디(Primary Platform Identifier)를 지칭할 수도 있다. SSP는 복수개의 SSP 식별자를 가질 수도 있으며, 복수개의 SSP 식별자는 고유한 단일의 SSP 식별자로부터 유도된 값일 수 있다.
"파트 넘버 아이디(Part Number ID)"는, 단말에 내장된 SSP와 연결된 정보로서, 해당 정보를 이용하여 'SSP에 탑재된 프라이머리 플랫폼의 제조사(manufacturer)'와 '프라이머리 플랫폼의 모델 정보'를 유추해낼 수 있는 정보일 수 있다.
"SPB(Secondary Platform Bundle)"은 SSP의 프라이머리 플랫폼(PP, Primary Platform) 상에서 PP의 리소스를 사용하여 구동되는 것으로서, 예를 들면, UICC 번들은 기존 UICC 내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등과 이들이 동작하는 운영체체(HLOS)를 소프트웨어 형태로 패키징한 것을 의미할 수 있다. 본 개시에서, SPB는 번들로 지칭될 수 있다.
본 개시에서 번들의 "상태"는 다음과 같을 수 있다.
[활성화(enable)]
본 개시에서 단말 또는 외부 서버가 번들을 활성화(enable)하는 동작은, 해당 SPB의 상태를 활성화 상태(enabled)로 변경하여 단말이 해당 번들이 제공하는 서비스(예: 통신사업자를 통해 통신서비스, 신용카드 결제 서비스, 사용자 인증 서비스 등)를 받을 수 있도록 설정하는 동작을 의미할 수 있다. 활성화 상태의 번들은 "활성화된 번들 (enabled Bundle)"로 표현될 수 있다. 활성화 상태의 번들은 SSP 내부 또는 외부의 저장공간에 암호화된 상태로 저장되어 있을 수 있다.
[구동 상태(Active)]
본 개시에서 활성화된 번들은 번들 외부 입력(예: 사용자 입력, 푸쉬, 단말 내 어플리케이션의 요청, 통신 사업자의 인증 요청, PP 관리 메시지 등) 또는 번들 내부의 동작(예: 타이머, Polling)에 따라 구동 상태(Active)로 변경될 수 있다. 구동 상태의 번들은 SSP 내부 또는 외부의 저장공간에서 SSP 내부의 구동 메모리에 로딩되고 SSP 내부의 보안 제어 장치 (Secure CPU)를 이용하여 보안 정보가 처리되고 단말에 보안 서비스가 제공될 수 있는 상태의 번들을 의미 할 수 있다.
[비활성화(Disabled)]
본 개시에서 단말 또는 외부 서버가 번들을 비활성화(disable)하는 동작은, 해당 번들의 상태를 비활성화 상태(disabled)로 변경하여 단말이 해당 번들이 제공하는 서비스를 받을 수 없도록 설정하는 동작을 의미할 수 있다. 비활성화 상태의 SPB는 "비활성화된 번들(disabled Bundle)"로 표현될 수 있다. 비활성화 상태의 번들은 SSP 내부 또는 외부의 저장공간에 암호화된 상태로 저장되어 있을 수 있다.
[삭제(Deleted)]
본 개시에서 단말 또는 외부 서버가 번들을 삭제(delete)하는 동작은, 해당 번들의 상태를 삭제 상태(deleted)로 변경하거나 해당 번들을 포함한 해당 번들의 관련 데이터를 삭제하여 단말 또는 외부 서버가 더 이상 해당 번들을 구동, 활성화 또는 비활성화할 수 없도록 설정하는 동작을 의미할 수 있다. 삭제 상태의 번들은 "삭제된 번들(deleted Bundle)"로 표현될 수 있다.
"번들 이미지(Bundle Image, 또는 Image)"는 번들과 혼용되거나 특정 번들의 데이터 객체(data object)를 나타내는 용어로 사용될 수 있으며, 번들 TLV(Tag, Length, Value) 또는 번들 이미지 TLV(Bundle Image TLV)로 명명될 수 있다. 번들 이미지가 암호화 파라미터를 이용해 암호화된 경우 번들 이미지는 보호된 번들 이미지 (Protected Bundle Image(PBI)) 또는 보호된 번들 이미지 TLV (PBI TLV)로 명명될 수 있다. 번들 이미지가 특정 SSP에 의해서만 복호화 가능한 암호화 파라미터를 이용해 암호화된 경우 묶인 번들 이미지(Bound Bundle Image(BBI)) 또는 묶인 번들 이미지 TLV(BBI TLV)로 명명될 수 있다. 번들 이미지 TLV는 TLV(Tag, Length, Value) 형식으로 번들을 구성하는 정보를 표현하는 데이터 세트(set) 일 수 있다.
"번들 구분자"는 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID), 번들 Matching ID, 이벤트 식별자(Event ID)와 매칭되는 인자로 지칭될 수 있다. 번들 식별자(SPB ID)는 각 번들의 고유 식별자를 나타낼 수 있다. 번들 패밀리 식별자는 번들 (예를 들어, 이동통신사 망 접속을 위한 텔레콤 번들)의 종류를 구분하는 식별자를 나타낼 수 있다. 본 개시에서 번들 패밀리 식별자는 Family ID, Fid 또는 FID로 지칭될 수 있다. 번들 패밀리 관리자 식별자는 번들 패밀리 식별자를 관리하는 주체 (예를 들어, 통신사업자, 단말제조사, 특정 단체 등)를 구분하는 식별자를 나타낼 수 있다. 본 개시에서 번들 패밀리 관리자 식별자는 OID 또는 Oid로 지칭될 수 있다. 번들 구분자는 번들 관리 서버 혹은 단말에서 번들을 색인할 수 있는 값으로서 사용될 수 있다.
"번들 메타데이터"는 번들을 지칭 혹은 기술할 수 있는 정보의 집합을 나타내는 용어이다. 번들 메타데이터는 상술한 번들 구분자를 포함할 수 있다. 또한, 번들 메타데이터는 번들의 속성이나 특성, 혹은 설정에 대한 정보를 더 포함할 수 있다. 번들 메타데이터는 "메타데이터"라 표현될 수 있다.
"프로파일(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) 일 수 있다.
본 개시에서 '프로파일 이미지'란 프로파일 패키지가 UICC 내에 설치되어 있는 바이너리 데이터를 의미할 수 있다. '프로파일 이미지'는 Profile TLV 또는 프로파일 이미지 TLV로 명명될 수 있다. 프로파일 이미지가 암호화 파라미터를 이용해 암호화된 경우, '프로파일 이미지'는 보호된 프로파일 이미지(Protected Profile Image (PPI)) 또는 보호된 프로파일 이미지 TLV (PPI TLV)로 명명될 수 있다. 프로파일 이미지가 특정 eUICC에 의해서만 복호화 가능한 암호화 파라미터를 이용해 암호화된 경우, '프로파일 이미지'는 묶인 프로파일 이미지(Bound Profile Image (BPI)) 또는 묶인 프로파일 이미지 TLV (BPI 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+)의 서명을 더 포함할 수 있다.
"번들 관리서버"는 서비스 제공자(Service Provider) 또는 다른 번들 관리서버의 요청에 의해 번들을 생성하거나, 생성된 번들을 암호화 하거나, 번들 원격관리 명령어를 생성하거나, 생성된 번들 원격관리 명령어를 암호화하는 기능을 포함할 수 있다. 상술한 기능을 제공하는 번들 관리서버는 SPBM (Secondary Platform Bundle Manager), RBM(Remote Bundle Manager), IDS(Image Delivery Server), SM-DP(Subscription Manager Data Preparation), SM-DP+(Subscription Manager Data Preparation plus), 관리자 번들 서버, Managing SM-DP+(Managing Subscription Manager Data Preparation plus), 번들 암호화 서버, 번들 생성서버, 번들 제공자(Bundle Provisioner, BP), 번들 공급자(Bundle Provider), BPC holder(Bundle Provisioning Credentials holder) 중 적어도 하나로 표현될 수 있다.
본 개시에서 번들 관리서버는 SSP에서 번들을 다운로드, 설치 또는 업데이트하고 번들의 상태를 원격 관리하기 위한 키 및 인증서를 설정을 관리하는 역할을 수행할 수 있다. 상술한 기능을 제공하는 번들 관리 서버는 SPBM(Secondary Platform Bundle Manager), RBM(Remote Bundle Manager), IDS(Image Delivery Server), 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) 중 적어도 하나로 표현될 수 있다.
본 개시에서 개통중개서버는 하나 이상의 번들 관리서버 내지 개통중개서버로부터 이벤트 등록 요청(Register Event Request, Event Register Request)을 수신할 수 있다. 또한 하나 이상의 개통중개서버가 복합적으로 사용될 수 있으며, 이 경우 제1 개통중개서버는 번들 관리서버뿐만 아니라 제2 개통중개서버로부터 이벤트 등록 요청을 수신할 수도 있다. 본 개시에서 개통중개서버의 기능은 번들 관리서버에 통합될 수 있다. 상술한 기능을 제공하는 개통중개서버는 SPBM(Secondary Platform Bundle Manager), RBM(Remote Bundle Manager), SPBDS(Secondary Platform Bundle Discovery Sever), BDS(Bundle Discovery Sever), SM-DS(Subscription Manager Discovery Service), DS(Discovery Service), 근원개통중개서버(Root SM-DS), 대체개통중개서버(Alternative SM-DS) 중 적어도 하나로 표현될 수 있다.
본 개시에서 번들 관리서버는 번들 또는 번들 원격 관리 명령어를 생성하고 암호화 하여 전달하는 기능과 SSP의 설정 및 설치된 번들을 관리하는 기능을 모두 수행하는 서버를 의미하는 것일 수도 있다. 또한, 번들 관리서버는 개통중개서버 기능을 더 수행할 수 있는 서버를 의미하는 것일 수도 있다. 따라서 이하 본 개시의 다양한 실시 예에서 번들 관리서버 및 개통 중개서버의 동작은 하나의 번들 관리서버에서 이루어질 수도 있다. 또한 각 기능은 서로 분리된 다수의 번들 관리 서버에서 나누어 수행될 수도 있다. 또한, 본 개시의 명세서에서 번들 관리서버 또는 개통중개서버는 번들 서버로 표현될 수 있다. 번들 서버는 번들 관리서버, 개통중개서버 중 하나 일 수 있고 번들 관리서버와 개통중개서버의 기능 또는 구성을 모두 포함하는 장치일 수도 있다.
"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 개통중개서버로부터 이벤트 등록 요청을 수신할 수도 있다.
"서비스 제공자(Service Provider)"는 번들 관리서버에 요구사항을 발행하여 번들 생성을 요청하고, 해당 번들을 통해 단말에 서비스를 제공하는 사업체를 의미할 수 있다. 예를 들면, 서비스 제공자는 통신 어플리케이션이 탑재된 번들을 통해 통신망 접속 서비스를 제공하는 통신사업자(Mobile Operator)를 의미할 수 있으며, 통신사업자의 사업지원시스템(Business Supporting System, BSS), 운영지원시스템(Operational Supporting System, OSS), POS 단말(Point of Sale Terminal), 그리고 기타 IT 시스템을 모두 통칭할 수 있다. 또한, 본 개시에서 서비스 제공자는 특정 사업체를 하나만 표현하는데 한정되지 않고, 하나 이상의 사업체의 그룹 또는 연합체(association 또는 consortium) 내지 해당 그룹 또는 연합체를 대표하는 대행사(representative)를 지칭하는 용어로서 사용될 수도 있다. 또한, 본 개시에서 서비스 제공자는 사업자(Operator 또는 OP 또는 Op.), 번들 소유자(Bundle Owner, BO), 이미지 소유자(Image Owner, IO) 등으로 명명될 수 있으며, 각 서비스 제공자는 이름 그리고/또는 고유 식별자(Object Identifier, OID)를 적어도 하나 이상 설정하거나 할당 받을 수 있다. 만일 서비스 제공자가 하나 이상의 사업체의 그룹 또는 연합체 또는 대행사를 지칭하는 경우, 임의의 그룹 또는 연합체 또는 대행사의 이름 또는 고유 식별자는 해당 그룹 또는 연합체에 소속한 모든 사업체 내지 해당 대행사와 협력하는 모든 사업체가 공유하는 이름 또는 고유 식별자일 수 있다.
"통신사업자 (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) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 개시에서 단말은 전자장치라 지칭될 수도 있다.
본 개시에서 전자장치에는 번들의 다운로드 및 설치가 가능한 SSP가 내장될 수 있다. SSP가 전자장치에 내장되지 않은 경우, 물리적으로 전자장치와 분리된 SSP는 전자장치에 삽입되어 전자장치와 연결될 수 있다. 예를 들어, SSP는 카드 형태로 전자장치에 삽입될 수 있다. 전자 장치는 단말을 포함할 수 있고, 단말은 번들의 다운로드 및 설치가 가능한 SSP를 포함하는 단말일 수 있다. SSP는 단말에 내장될 수 있을 뿐만 아니라, 단말과 SSP가 분리된 경우 단말에 삽입될 수 있고, 단말에 삽입되어 단말과 연결될 수 있다.
본 개시에서 전자장치에는 프로파일을 다운로드 하여 설치 가능한 UICC가 내장될 수 있다. UICC가 전자장치에 내장되지 않은 경우, 물리적으로 전자장치와 분리된 UICC는 전자장치에 삽입되어 전자장치와 연결될 수 있다. 예를 들어, 카드 형태로 UICC는 전자장치에 삽입될 수 있다. 전자 장치는 단말을 포함할 수 있고, 이때, 단말은 프로파일을 다운로드하여 설치 가능한 UICC를 포함하는 단말일 수 있다. 단말에 UICC는 내장될 수 있을 뿐만 아니라, 단말과 UICC가 분리된 경우 UICC는 단말에 삽입될 수 있고, 단말에 삽입되어 단말과 연결될 수 있다. 프로파일을 다운로드하여 설치 가능한 UICC는 예를 들어 eUICC라 지칭할 수 있다.
"LBA(Local Bundle Assistant)"는 SSP를 제어하도록 단말 또는 전자장치 내에 설치된 소프트웨어 또는 애플리케이션을 지칭할 수 있다. 상술한 소프트웨어 또는 애플리케이션은 Local Bundle Manager(LBM)라 지칭할 수 있다.
"로더(SPBL, Secondary Platform Bundle Loader)"는 SSP에서 다른 번들의 설치, 활성화, 비활성화 및 삭제 등을 관리하는 관리 번들을 지칭할 수 있다. 단말의 LBA 또는 원격의 서버는 로더를 통해 특정 번들을 설치, 활성화, 비활성화 또는 삭제할 수 있다. 본 개시에서 로더의 동작은 로더를 포함하는 SSP의 동작으로도 기술될 수 있다.
"LPA(Local Profile Assistant)"는 단말 또는 전자장치에서 UICC 또는 eUICC를 제어하도록 단말 또는 전자장치 내에 설치된 소프트웨어 또는 애플리케이션을 지칭할 수 있다.
"이벤트(Event)"는 본 개시에서 다음과 같은 용도로 사용될 수 있다.
[번들과 관련되어 사용될 경우]
"이벤트(Event)"는 번들 다운로드(Bundle Download), 또는 원격 번들 관리(Remote Bundle Management), 또는 번들이나 SSP의 기타 관리/처리 명령어를 통칭하는 용어일 수 있다. 이벤트(Event)는 원격 Bundle 제공 동작(Remote Bundle Provisioning Operation, 또는 RBP 동작, 또는 RBP Operation) 또는 이벤트 기록(Event Record)으로 명명될 수 있으며, 각 이벤트(Event)는 그에 대응하는 이벤트 식별자(Event Identifier, Event ID, EventID) 또는 매칭 식별자(Matching Identifier, Matching ID, MatchingID)와, 해당 이벤트가 저장된 번들 관리서버 또는 개통중개서버의 주소(FQDN, IP Address, 또는 URL) 또는 각 서버 식별자를 적어도 하나 이상 포함하는 데이터로써 식별될 수 있다. 번들 다운로드(Bundle Download)는 번들 설치(Bundle Installation)와 혼용될 수 있다. 또한, 이벤트 종류(Event Type)는 특정 이벤트가 번들 다운로드인지 원격 번들 관리(예를 들어, 삭제, 활성화, 비활성화, 교체, 업데이트 등)인지 또는 번들이나 SSP의 기타 관리/처리 명령인지를 나타내는 용어로서 사용될 수 있다. 또한, 이벤트 종류(Event Type)는 동작 종류(Operation Type 또는 OperationType), 동작 분류(Operation Class 또는 OperationClass), 이벤트 요청 종류(Event Request Type), 이벤트 분류(Event Class), 이벤트 요청 분류(Event Request Class) 등으로 명명될 수 있다.
"로컬 번들 관리(Local Bundle Management, LBM)"는 번들 로컬관리(Bundle Local Management), 로컬관리(Local Management), 로컬관리 명령(Local Management Command), 로컬 명령(Local Command), 로컬 번들 관리 패키지(LBM Package), 번들 로컬 관리 패키지(Bundle Local Management Package), 로컬관리 패키지(Local Management Package), 로컬관리 명령 패키지(Local Management Command Package), 로컬명령 패키지(Local Command Package) 등으로 명명될 수 있다. LBM은 단말에 설치된 소프트웨어 등을 통해 임의의 번들을 설치(Install)하거나, 특정 번들의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 번들의 내용(예를 들면, 번들의 별칭(Bundle Nickname), 또는 번들 요약 정보(Bundle Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. LBM은 하나 이상의 로컬관리명령을 포함할 수도 있으며, 각 로컬관리명령의 대상이 되는 번들은 로컬관리명령마다 서로 같거나 다를 수 있다.
"원격 번들 관리(Remote Bundle Management, RBM)"는 번들 원격관리(Bundle Remote Management), 원격관리(Remote Management), 원격관리 명령(Remote Management Command), 원격 명령(Remote Command), 원격 번들 관리 패키지(RBM Package), 번들 원격 관리 패키지(Bundle Remote Management Package), 원격관리 패키지(Remote Management Package), 원격관리 명령 패키지(Remote Management Command Package), 원격명령 패키지(Remote Command Package) 등으로 명명될 수 있다. RBM은 임의의 번들을 설치(Install)하거나, 특정 번들의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 번들의 내용(예를 들면, 번들의 별칭(Bundle Nickname), 또는 번들 요약 정보(Bundle Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. RBM은 하나 이상의 원격관리명령을 포함할 수도 있으며, 각 원격관리명령의 대상이 되는 번들은 원격관리명령마다 서로 같거나 다를 수 있다.
"목표 번들(target Bundle)"은 로컬관리명령 내지 원격관리명령의 대상이 되는 번들을 지칭하는 용어로서 사용될 수 있다.
"번들 규칙(Bundle Rule)"은 목표 번들에 대해 로컬관리 내지 원격관리를 수행할 때 단말이 확인해야 할 정보를 지칭하는 용어로서 사용될 수 있다. 또한 번들 규칙은 번들 정책(Bundle Policy), 규칙(Rule), 정책(Policy) 등의 용어와 혼용될 수 있다.
[프로파일과 관련되어 사용될 경우]
"이벤트(Event)"는 프로파일 다운로드(Profile Download), 또는 원격 프로파일 관리(Remote Profile Management), 또는 기타 프로파일이나 eUICC의 관리/처리 명령어를 통칭하는 용어일 수 있다. 이벤트(Event)는 원격 SIM 제공 동작(Remote SIM Provisioning Operation, 또는 RSP 동작, 또는 RSP Operation) 또는 이벤트 기록(Event Record)으로 명명될 수 있으며, 각 이벤트(Event)는 그에 대응하는 이벤트 식별자(Event Identifier, Event ID, EventID) 또는 매칭 식별자(Matching Identifier, Matching ID, MatchingID)와, 해당 이벤트가 저장된 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 주소(FQDN, IP Address, 또는 URL)와, 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 서명과, 프로파일 제공서버(SM-DP+) 또는 개통중개서버(SM-DS)의 디지털 인증서를 적어도 하나 이상 포함하는 데이터로 지칭될 수 있다.
이벤트(Event)에 대응하는 데이터는 "명령코드(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)가 지정되어 있을 수 있다.
"로컬 프로파일 관리(Local Profile Management, LPM)"는 프로파일 로컬관리(Profile Local Management), 로컬관리(Local Management), 로컬관리 명령 (Local Management Command), 로컬 명령(Local Command), 로컬 프로파일 관리 패키지 (LPM Package), 프로파일 로컬 관리 패키지(Profile Local Management Package), 로컬관리 패키지(LOCAL MANAGEMENT PACKAGE), 로컬관리 명령 패키지(Local Management Command Package), 로컬명령 패키지(Local Command Package) 등으로 명명될 수 있다. LPM은 단말에 설치된 소프트웨어 등을 통해 특정 프로파일의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 프로파일의 내용 (예를 들면, 프로파일의 별칭(Profile Nickname), 또는 프로파일 요약 정보(Profile Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. LPM은 하나 이상의 로컬관리명령을 포함할 수도 있으며, 이 경우 각 로컬관리명령의 대상이 되는 프로파일은 로컬관리명령마다 서로 같거나 다를 수 있다.
"원격 프로파일 관리(Remote Profile Management, RPM)"는 프로파일 원격관리(Profile Remote Management), 원격관리(Remote Management), 원격관리 명령(Remote Management Command), 원격 명령(Remote Command), 원격 프로파일 관리 패키지(RPM Package), 프로파일 원격 관리 패키지(Profile Remote Management Package), 원격관리 패키지(Remote Management Package), 원격관리 명령 패키지(Remote Management Command Package), 원격명령 패키지(Remote Command Package) 등으로 명명될 수 있다. RPM은 특정 프로파일의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 프로파일의 내용(예를 들면, 프로파일의 별칭(Profile Nickname), 또는 프로파일 요약 정보(Profile Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. RPM은 하나 이상의 원격관리명령을 포함할 수도 있으며, 이 경우 각 원격관리명령의 대상이 되는 프로파일은 원격관리명령마다 서로 같거나 다를 수 있다.
"인증서(Certificate)" 또는 디지털 인증서(Digital Certificate)는 공개 키(Public Key, PK)와 비밀 키(Secret Key, SK)의 쌍으로 구성되는 비대칭 키(Asymmetric Key) 기반의 상호 인증(Mutual Authentication)에 사용되는 디지털 인증서(Digital Certificate)를 나타낼 수 있다. 각 인증서는 하나 이상의 공개 키(Public Key, PK)와, 각 공개 키에 대응하는 공개 키 식별자(Public Key Identifier, PKID)와, 해당 인증서를 발급한 인증서 발급자(Certificate Issuer, CI)의 식별자(Certificate Issuer ID) 및 디지털 서명(Digital Signature)을 포함할 수 있다. 또한 인증서 발급자(Certificate Issuer)는 인증 발급자(Certification Issuer), 인증서 발급기관(Certificate Authority, CA), 인증 발급기관(Certification Authority) 등으로 명명될 수 있다. 본 개시에서 공개 키(Public Key, PK)와 공개 키 식별자(Public Key ID, PKID)는 특정 공개 키 내지 해당 공개 키가 포함된 인증서, 또는 특정 공개 키의 일부분 내지 해당 공개 키가 포함된 인증서의 일부분, 또는 특정 공개 키의 연산 결과(예를 들면, 해시(Hash))값 내지 해당 공개 키가 포함된 인증서의 연산 결과(예를 들면, 해시(Hash))값, 또는 특정 공개 키의 일부분의 연산 결과(예를 들면, 해시(Hash))값 내지 해당 공개 키가 포함된 인증서의 일부분의 연산 결과(예를 들면, 해시(Hash))값, 또는 데이터들이 저장된 저장 공간 등을 지칭하는 의미로서 사용될 수 있다.
"인증서 연쇄(Certificate 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은 본 개시의 실시 예에 따른 SSP의 개념도를 나타낸다.
도 1을 참조하면, 본 개시의 일 실시예에 따르면, 단말(110)은 SSP(120)를 포함할 수 있다. 예를 들면, SSP(120)는 단말(110)의 SoC(130)에 내장될 수 있다. 이때, SoC(130)는 통신 프로세서(Communication Processor), 어플리케이션 프로세서(Application Processor) 또는 이 두 프로세서가 통합된 프로세서일 수 있다. 다른 예를 들면, SSP(120)는 SoC에 통합되지 않고 독립된 칩 형태로 착탈형(122)일 수도 있고, 단말(110)에 미리 내장된 내장형(124)일 수도 있다.
다양한 실시예에 따르면, 단말에 포함된 SSP(120)는 하나 이상의 텔레콤 번들, 하나 이상의 페이먼트 번들 또는 하나 이상의 전자신분증 번들 중 적어도 하나를 포함할 수 있다. 예를 들면, 도 1에 도시된 바와 같이, SSP(120)에 복수의 텔레콤 번들(140, 150)이 포함된 경우, 단말(110)은 설정에 따라 복수의 텔레콤 번들(140, 150)을 동시 또는 시분할로 동작하게 하여 이동통신 네크워크를 이용할 수 있다. 또한, SSP(120)에 페이먼트 번들(170) 및 전자신분증 번들(180)이 포함된 경우, 단말(110)은 페이먼트 번들(170)을 이용하여 단말 앱을 통한 온라인 결제 또는 외부 신용카드 PoS (Point of Sale) 기기를 통한 오프라인 결제를 이용할 수 있으며, 전자신분증 번들(180)을 이용하여 단말 소유자의 신분을 인증할 수 있다.
도 2는 본 개시의 실시 예에 따른 SSP의 내부 구조에 대한 개념도를 나타낸다.
도 2를 참조하면, 본 개시의 일 실시예에 따르면, SSP(210)는 하나의 프라이머리 플랫폼(Primary Platform, PP)(220)과 그 위에서 동작하는 적어도 하나의 세컨더리 플랫폼 번들(Secondary Platform Bundle, SPB)(230, 240)을 포함할 수 있다.
다양한 실시예에 따르면, 프라이머리 플랫폼(220)은 하드웨어(미도시)와 적어도 하나의 하위계층 운영체제(low level Operating System, LLOS)(222)를 포함할 수 있다.
다양한 실시예에 따르면, 세컨더리 플랫폼 번들(230)은 상위계층 운영체제(High-level Operating System, HLOS)(232)와 그 위에서 동작하는 적어도 하나의 애플리케이션(234)을 포함할 수 있다.
다양한 실시예에 따르면, 각 세컨더리 플랫폼 번들(230, 240)은 프라이머리 플랫폼 인터페이스(Primary Platform Interface, PPI)(250)를 이용하여 프라머리 플랫폼(220)의 중앙처리장치, 메모리 등의 자원에 접근하고 이를 통해 SSP(210)에서 구동될 수 있다.
도 3은 본 개시의 실시 예에 따른 단말이 SSP로 번들을 다운로드하고 설치하기 위해 사용되는 단말 내 구성 요소의 예를 도시하는 도면이다.
도 3을 참조하면, 본 개시의 일 실시예에 따르면, 단말(310)은 SSP(330) 및/또는 SSP(330)를 제어하기 위한 LBA(312)를 포함할 수 있다. 예를 들면, 단말(310)은 SSP(330)가 장착되고 SSP(330)을 제어하기 위한 LBA(312)가 설치된 단말일 수 있다. 일 예로, SSP(330)은 단말(310)에 내장되거나 착탈형일 수도 있다.
다양한 실시예에 따르면, SSP(330)는 프라이머리 플랫폼(331), 세컨더리 플랫폼 번들 로더(Secondary Platform Bundle Loader, SPBL)(333), 및 하나 이상의 세컨더리 플랫폼 번들(335, 337, 또는 339) 중 적어도 하나를 포함할 수 있다.
다양한 실시예에 따르면, 세컨더리 플랫폼 번들(335, 337, 또는 339)은 단말 출하 시점에는 SSP(330)내부에 설치되지 않고, 출하 후 원격으로 다운로드 및 설치될 수 있다.
다양한 실시예에 따르면, 도 3의 예에서와 같이, 각 번들은 서로 다른 번들 패밀리 식별자 및/또는 번들 패밀리 관리자 식별자(341, 342, 343)를 가질 수 있다. 이러한 번들 패밀리 식별자 및/또는 번들 패밀리 관리자 식별자(341, 342, 343)는 번들의 다운로드 및 설치에 필요한 정보로서 이용될 수 있다. 즉, SSP(330) 또는 SPBL(333)은 번들 패밀리 식별자 및/또는 번들 패밀리 관리자 식별자(341, 342, 343)에 따라 특정 번들의 다운로드와 설치를 허용하거나 거부할 수 있다.
도 4는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들 혹은 번들과 연관된 서비스가 오프라인 혹은 온라인 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 4를 참조하면, 본 개시의 일 실시예에서, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 제1 단말(400)은 제1 LBA(410)과 제1 SSP(420)을 포함하고, 제2 단말(450)은 제2 LBA(460)과 제2 SSP(470)을 포함할 수 있다.
다양한 실시예에 따르면, 4020 동작 및 4070 동작에서 제1/제2 LBA(410, 460)는 제1/제2 SSP(420, 470)에 명령을 내리거나 혹은 제1/제2 SSP(420, 470)와 데이터를 송수신할 수 있다. 또한, 4030 동작 및 4080 동작에서 제1/제2 SSP(420, 470)는 제1/ 제2 SSP(420, 470)의 내부에서 필요한 데이터를 생성하거나 처리, 혹은 검증할 수 있다.
다양한 실시예에 따르면, 4050 동작(이하, 제3 동작)에서 제1/제2 LBA(410, 460)는 서로 연결되어 상대에게 명령을 내리거나 상대와 데이터를 송수신할 수 있다. 제3 동작에서, 4050의 연결은 제1 단말(400)과 제2 단말(450) 간의 직접적인 기기 간 연결일 수도 있고, 비록 도시되지는 않았으나 제1 LBA(410)와 제2 LBA(460) 사이에 외부 개체(예컨대, 외부 서버)가 연결되어 있는 간접적인 기기 간 연결일 수도 있다. 제1 LBA(410)와 제2 LBA(460) 간의 연결 방법에 대한 보다 상세한 기술은 후술한 도면들을 참조하여 설명하기로 한다.
다양한 실시예에 따르면, 사용자는 단말에 명령을 보내거나, 혹은 사용자가 제공받아야 할 정보를 단말로부터 수신할 수 있다. 예를 들면, 4010 동작 및 4060 동작에서와 같이, 제1/제2 사용자(440, 490)는 제1/제2 단말(400, 450)의 제1/제2 LBA(410, 460) 에 명령을 보내거나, 혹은 제1/제2 LBA(410, 460)로부터 사용자가 제공받아야 할 정보를 수신할 수 있다. 제1 사용자(440) 및 제2 사용자(490)는 서로 상이한 사용자를 지칭할 수 있고, 동일한 하나의 사용자를 지칭할 수도 있다.
다양한 실시예에 따르면, 번들 관리 서버는 단말과 데이터를 송수신할 수 있다. 예를 들면, 4040 동작 및 4090 동작에서와 같이, 제1/제2 번들 관리 서버(430, 480)는 제1/제2 단말(400, 450)의 제1/제2 LBA(410, 460) 로부터 메시지를 수신하거나 메시지를 송신할 수 있다. 제1 번들 관리 서버(430)와 제2 번들 관리 서버(480)은 서로 상이한 번들 관리 서버일 수 있고, 동일한 번들 관리 서버일 수도 있다. 제1 번들 관리 서버(430)와 제2 번들 관리 서버(480)가 상이할 경우 4000 동작에서와 같이, 두 서버는 메시지를 송수신할 수 있다.
본 도면에서는 제1 번들 관리 서버(430)와 제2 번들 관리 서버(480)이 직접 메시지를 송수신하는 예가 도시되어 있지만, 실시예에 따라 두 번들 관리 서버 사이에는 또 다른 하나 이상의 번들 관리 서버가 위치해 있을 수 있다. 가령, 도면에서는 도시되어 있지 않지만, 제3 번들 관리 서버가 제1 번들 관리 서버와 제2 번들 관리 서버 사이에 존재하여, 제1/제2 번들 관리 서버가 제2/제1 번들 관리 서버에 메시지를 송신할 시, 먼저 제1/제2 번들 관리 서버가 제3 번들 관리 서버로 메시지를 보내고 제3 번들 관리 서버가 이 메시지를 제2/제1 번들 관리 서버에 송신할 수 있다. 유사한 방식으로 제1 번들 관리 서버와 제2 번들 관리 서버의 사이에는 복수 개의 번들 관리 서버 및/또는 릴레이 서버가 존재할 수 있다.
본 개시에서는 기술의 편의성을 위해 하나 이상의 번들 관리 서버 전체를 하나의 번들 관리 서버로 지칭할 수 있다. 가령 도면에서 제1 번들 관리 서버(430)과 제2 번들 관리 서버(480)를 하나로 묶어 번들 관리 서버라 칭할 수 있다. 이 경우, 가령 제1 단말이 제1 번들 관리 서버와 제2 번들 관리 서버를 거쳐 제2 단말과 메시지를 송수신하는 동작은, 제1 단말이 번들 관리 서버를 거쳐 제2 단말과 메시지를 송수신하는 동작으로 기술될 수 있다. 제1 번들 관리 서버와 제2 번들 관리 서버 사이에 하나 이상의 번들 관리 서버가 존재하는 경우에도, 앞서 설명한 것처럼, 이 번들 관리 서버들을 통칭하여 번들 관리 서버라 지칭할 수 있다.
도 5는 본 개시의 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 번들 혹은 번들과 연관된 서비스를 이동하기 위해 준비하는 절차를 도시하는 도면이다.
도 5를 참조하면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 제1 단말(510)은 제1 LBA(530)과 제1 SSP(520)을 포함하고, 제2 단말(560)은 제2 LBA(580)과 제2 SSP(570)을 포함할 수 있다.
하나의 단말에서 다른 하나의 단말로 번들 혹은 번들과 연관된 서비스가 이동되는 방법은 크게 다음과 같이 분류될 수 있다.
- 오프라인 이동: 오프라인 방식을 통한 번들 혹은 번들과 연관된 서비스의 이동이란 두 단말이 사이에 번들 관리 서버를 두지 않은 채 연결을 맺고, 이 연결을 통해 하나의 단말에서 다른 단말로 번들이 이동하는 것을 의미할 수 있다. 번들의 전송을 통해 이와 연관된 서비스가 이동될 수 있다. 이때 가능한 연결의 방법은 도 6의 설명을 참조하기로 한다. 이 오프라인 이동 과정은 '오프라인 전송(Offline Transfer)'이라 지칭될 수도 있다.
- 온라인 이동: 온라인 방식을 통한 번들 혹은 번들과 연관된 서비스의 이동이란 두 단말과 번들 관리 서버가 각각 연결을 맺고, 번들 관리 서버의 도움을 받아 번들 혹은 번들과 연관된 서비스가 이동하는 것을 의미할 수 있다.
또한, 온라인 이동은 다음과 같이 분류될 수 있다.
- 온라인 전송(Online Transfer): 두 단말과 번들 관리 서버가 각각 연결을 맺고, 하나의 단말에 설치된 번들 혹은 번들의 일부 데이터가 번들 관리 서버로 전송된 뒤 다른 단말로 전송되는 과정을 의미할 수 있다. 번들의 전송을 통해 이와 연관된 서비스가 이동될 수 있다.
- 리프로비저닝(Re-provisioning): 두 단말과 번들 관리 서버가 각각 연결을 맺되, 선택적으로 본래 번들이 설치되어 있던 단말의 번들은 삭제되고, 번들 관리 서버가 이동하려는 서비스와 연관된 번들을 생성해 다른 단말로 전송하는 과정을 의미할 수 있다.
다양한 실시예에 따르면, 제1 단말(510)은 기 설치된 번들을 보유하고 있을 수 있으며, 기 설치된 번들과 연계된 메타데이터를 더 보유하고 있을 수 있다. 다양한 실시예에 따르면, 제1 단말(510)은 기 설치된 번들과 관련된 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 또는 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 보유하고 있을 수 있다.
다양한 실시예에 따르면, 제1 단말(510)은 기 설치된 번들과 관련된 '번들 이동 설정'을 보유하고 있을 수 있다.
'번들 이동 설정'에는 다음의 정보를 포함하는 인자가 포함되어 있을 수 있다.
- 해당 번들 혹은 번들과 연관된 서비스가 하나의 단말에서 다른 단말로 옮겨질 수 있는지 여부
또한, '번들 이동 설정'에는 해당 번들 혹은 번들과 연관된 서비스가 하나의 단말에서 다른 단말로 옮겨질 수 있는 경우, 어떠한 방식을 통해 이동될 수 있는지를 나타내는 인자가 포함되어 있을 수 있다.
예컨대, '번들 이동 설정'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 이동
- 온라인 이동
또 다른 예로, '번들 이동 설정'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 전송
- 온라인 전송
- 리프로비저닝
도 5를 참조하면, 5000 단계에서, 제1 LBA(530)는 이동할 (서비스와 연관된) 번들의 정보를 획득할 수 있다. 또는, 이동할 (서비스와 연관된) 번들의 정보가 제1 LBA에 전달될 수 있다. 예를 들면, 제1 LBA는 이동할 (서비스와 연관된) 번들의 정보를 사용자가 제1 단말(510)이 제공하는 UI를 통해 번들을 선택하는 사용자 입력을 수신함으로써 획득할 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 이동할 (서비스와 연관된) 번들의 정보가 제1 LBA에게 입력될 수도 있으며, 또는 제1 LBA가 원격 서버에 접속하여 이동할 (서비스와 연관된) 번들의 정보를 읽어올 수도 있다.
도 5를 참조하면, 5005 단계에서, 제1 LBA(530)는 자신이 이동하려는 번들 혹은 번들과 연관된 서비스를, 어떤 방식을 통해 이동할 수 있는지를 나타내는 정보, "가능한 옵션(Available Option)"을 구성할 수 있다. 예컨대, "가능한 옵션(Available Option)"은 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함될 수 있다.
- 오프라인 이동
- 온라인 이동
또 다른 예로, '가능한 옵션(Available Option)'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 전송
- 온라인 전송
- 리프로비저닝
이때 "가능한 옵션(Available Option)"을 구성하기 위해 다음의 정보 중 하나 이상이 사용될 수 있다.
- 이동할 (서비스와 연관된) 번들의 '번들 이동 설정'
- 제1 단말에 구현되어 있는 기능 (즉, 어떠한 방식의 이동을 단말 기능이 지원하는지)
- 제1 단말의 현재 가능한 연결 방법 (예를 들어, 현재 제1 단말이 온라인 연결을 통해 서버와 통신할 수 있는지의 여부)
즉, 제1 단말 (예를 들어, 제1 LBA(530))은 '번들 이동 설정에서 허용된 이동 방식' 및/또는 '제1 단말에 구현되어 있어 지원이 가능한 이동 방식' 및/또는 '제1 단말의 현재 가능한 연결 방법을 통해 수행이 가능한 이동 방식'을 확인한 뒤, 이 정보들을 이용해 "가능한 옵션"을 구성할 수 있다.
도 5를 참조하면, 5010 단계에서, 제1 LBA(530)는 '번들 전송 코드'를 생성할 수 있다. 번들 전송 코드에는 전송하고자 하는 번들의 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID)와 같은 번들 구분자가 포함될 수 있다. 또한, 번들 전송 정보에는 번들의 속성을 나타내는 기타 정보들(가령, 번들의 메타데이터 혹은 메타데이터의 일부)이 더 포함될 수 있다. 또한 번들 전송 정보에는 전송하고자 하는 번들과 연계되어 있는 번들 관리 서버의 주소(SPBM Addr)이 포함될 수 있다.
또한, 번들 전송 코드에는 제1 단말 (가령, 제1 SSP)가 지원하는 암호화 알고리즘들의 정보(Supported Crypto Info)가 포함될 수 있다. 제1 단말이 지원하는 암호화 알고리즘들의 정보는 다음의 정보들을 하나 이상 선택적으로 포함할 수 있다; 제1 단말이 지원하는 타원 곡선 커브 리스트, 제1 단말이 지원하는 키 합의 알고리즘 리스트, 제1 단말이 지원하는 암호화 알고리즘 리스트.
또한, 번들 전송 코드에는 향후 제1 단말과 제2 단말이 연결을 맺어야 할 경우 이 연결을 맺기 위해 필요한 정보가 포함될 수 있다.
또한, 번들 전송 코드에는 "가능한 옵션(Available Option)"이 포함될 수 있다.
도 5를 참조하면, 5015 단계에서, 5010 단계에서 생성된 번들 전송 코드가 제1 LBA (530) 로부터 제2 LBA(580)으로 전송될 수 있다. 번들 전송 코드는 다양한 방법으로 전송될 수 있다.
예를 들어, 제1 LBA(530)는 제2 LBA(580)로 전송해야 할 정보를 제1 단말의 UI를 통해 제1 단말의 제1 사용자에게 제공할 수 있다. 제1 사용자는 제공받은 정보를 제2 단말의 제2 사용자에게 제공할 수 있다. 제2 사용자는 제공받은 정보를 제2 단말의 UI를 이용해 제2 LBA에 입력할 수 있다.
혹은, 제1 LBA(530)는 제2 LBA(580)로 전달해야 할 정보를 이미지(예를 들어, QR 코드)의 형태로 만들어 제1 단말의 화면에 표시하고, 제2 사용자는 제1 단말의 화면에 표시된 이미지를 제2 단말을 이용해 스캔함으로써 제2 LBA에 정보를 전송할 수 있다.
혹은, 제1 LBA(530)는 제1 LBA(530)와 제2 LBA(580) 사이에 연결을 수립하고 이 수립된 연결을 이용해 전송해야 할 정보를 전달할 수 있다. 이때, 제1 LBA(530)과 제2 LBA(580) 사이에 수립되는 연결은 직접적인 기기 간 연결(예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D)일 수도 있고 혹은 제1 LBA(530)과 제2 LBA(580) 사이에 원격 서버(가령, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.
도 5를 참조하면, 5020 단계에서 제2 LBA(580)는 자신이 수신하게 될 번들 혹은 번들과 연관된 서비스를, 어떤 방식을 통해 수신할 수 있는지를 나타내는 정보, "결정된 옵션(Determined Option)"을 구성할 수 있다. 예컨대, "결정된 옵션(Determined Option)"은 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함될 수 있다.
- 오프라인 이동
- 온라인 이동
또 다른 예로, "결정된 옵션(Determined Option)"에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 전송
- 온라인 전송
- 리프로비저닝
이때 "결정된 옵션(Determined Option)"을 구성하기 위해 다음의 정보 중 하나 이상이 사용될 수 있다.
- 5015 단계에서 수신한 "가능한 옵션"
- 제2 단말에 구현되어 있는 기능 (즉, 어떠한 방식의 이동을 단말 기능이 지원하는지)
- 제2 단말의 현재 가능한 연결 방법 (예를 들어, 현재 제2 단말이 온라인 연결을 통해 서버와 통신할 수 있는지의 여부)
즉, 제2 단말 (예를 들어, 제2 LBA(580))은 '수신한"가능한 옵션"에서 허용된 이동 방식' 및/또는 '제2 단말에 구현되어 있어 지원이 가능한 이동 방식' 및/또는 '제2 단말의 현재 가능한 연결 방법을 통해 수행이 가능한 이동 방식'을 확인한 뒤, 이 정보들을 이용해 "결정된 옵션(Determined Option)"을 구성할 수 있다.
도 6은 본 개시의 실시 예에 따른 번들의 오프라인 이동 절차를 도시하는 도면이다.
다양한 실시 예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 6의 예에서와 같이, 제1 단말(600)은 제1 LBA(620)과 제1 SSP(610)을 포함하고, 제2 단말(650)은 제2 LBA(670)과 제2 SSP(660)을 포함할 수 있다.
도 6에 도시된 절차는 도 5에 도시된 절차 이후에 이루어질 수 있다.
도 6을 참조하면, 6000 단계에서 제1 LBA(620)과 제2 LBA(670) 사이에 연결이 수립(또는, 설정)될 수 있다. 만일 5015 단계에서 연결을 위해 필요한 정보들이 전송되었다면, 제1 LBA(620)과 제2 LBA(670)는 이 정보를 이용해 연결을 수립할 수도 있다. 제1 LBA(620)과 제2 LBA(670)의 연결은 직접적인 기기 간 연결일 수도 있고 (예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D와 같은 무선 연결이나 케이블을 통한 유선 연결) 혹은 제1 LBA(620)과 제2 LBA(670) 사이에 원격 서버(가령, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.
도 6을 참조하면, 6005 단계에서 제2 LBA(670)은 제2 SSP 2(660)에게 "SSP 정보 (SspInfo)"를 요청할 수 있다. 제2 LBA(670)가 제2 SSP(660)에게 "SSP 정보 (SspInfo)"를 요청할 때, 제2 LBA(670)는 제2 SSP(660)에게 오프라인 방식의 번들 이동이 수행될 것임을 알려줄 수 있다. 또한, 제2 LBA(670)는 제2 SSP(660)에게 전송될 번들에 대한 정보를 선택적으로 제공할 수 있다. 이 정보에는 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 선택적으로 포함될 수 있다.
도 6을 참조하면, 6010 단계에서 다음의 과정 중 적어도 하나가 수행될 수 있다.
제2 SSP(660)는 자신의 "SSP 정보"를 생성할 수 있다. "SSP 정보"에는 번들 이동을 위해 제공되어야 하는 제2 SSP의 정보가 포함될 수 있다. 예를 들면, "SSP 정보"에는 제2 SSP(660)가 번들을 수신하기 전 거쳐야 할 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. 이 "인증서 협상 정보"는 제2 SSP(660)가 다른 SSP를 검증하는데 이용할 수 있는 인증서 정보들(SenderSpblVerification)과 다른 SSP가 자신을 검증하는데 이용될 수 있는 인증서 정보들(ReceiverSpblVerification)를 포함할 수 있다. 또한, "인증서 협상 정보"는 제2 SSP(660)가 지원하는 키 합의 알고리즘의 리스트를 선택적으로 더 포함할 수 있으며, 제2 SSP (660)가 지원하는 암호화 알고리즘의 리스트를 선택적으로 더 포함할 수 있다. 또한, "인증서 협상 정보"는, 만일 6005 단계에서 번들 패밀리 식별자(SPB Family ID)와 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID)를 제공받았다면, 번들 패밀리 식별자 혹은 번들 패밀리 관리자 식별자의 값에 의존적으로 선택될 수 있으며, 이 경우 "SSP 정보"에는 인증서 협상 정보와 함께 번들 패밀리 식별자와 번들 패밀리 관리자 식별자가 선택적으로 더 포함될 수 있다. 또한 "SSP 정보"에는 제2 SSP(660)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보 중 적어도 하나를 포함하는 SSP 버전 정보가 선택적으로 더 포함될 수 있다.
제2 SSP(660)는 제2 LBA(670)에게 생성한 "SSP 정보"를 전달할 수 있다.
이상에 기술된 6005에서 6010 단계에 따르면 제2 LBA(670)가 제2 SSP(660)에게 "SSP 정보 (SspInfo)" 를 요청하고, 제2 SSP(660)가 자신의 "SSP 정보"를 생성한 뒤 제2 LBA(670)에게 "SSP 정보"를 전달할 수 있다. 하지만, 실시예에 따라서는, 제2 LBA(670)가 스스로 "SSP 정보"를 생성할 수 있다.
도 6을 참조하면, 6015 단계에서 제2 LBA(670)은 제1 LBA(620)에게 "SSP 정보"를 전송할 수 있다. 또한, 제2 LBA(670)은 제1 LBA(620)에게 "결정된 옵션(Determined Option)"을 더 전송할 수 있다. "결정된 옵션(Determined Option)"에 대한 설명은 도 5를 참조한다.
도 6을 참조하면, 6020 단계에서 제1 LBA(620)은 제1 SSP(610)에게 "SSP 정보"를 전송할 수 있다.
도 6을 참조하면, 6025 단계에서 다음의 과정이 수행될 수 있다.
제1 SSP(610)은 수신한 "SSP 정보"를 이용해 '인증서 협상 과정'을 수행할 수 있다. 이 과정은 아래와 같다.
제1 SSP(610)은 수신한 "SenderSpblVerification"과 "제2 SSP(660)가 지원하는 키 합의 알고리즘의 리스트"를 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 키 합의용 인증서(ssp1.Cert.KA)를 선택할 수 있다. 혹은, 제1 SSP(610)은 수신한 "제2 SSP(660)가 지원하는 키 합의 알고리즘의 리스트"를 이용해 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "ssp1.ePK.KA"와 비밀키 "ssp1.eSK.KA"를 을 생성한 뒤, 이 키 쌍 중 공개키(ssp1.ePK.KA)를 선택할 수 있다. 또한, 제1 SSP(610)은 수신된 "SenderSpblVerification"를 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 서명용 인증서(ssp1.Cert.DS)를 더 선택할 수 있다.
또한, 제1 SSP(610)은 수신된 "ReceiverSpblVerification"을 이용해 자신이 검증할 수 있는 제2 SSP(660)의 인증서를 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CiPkIdToBeUsed"로 설정할 수 있다.
또한, 제1 SSP(610)은 수신한 "제2 SSP(660)가 지원하는 암호화 알고리즘의 리스트"를 이용해 향후 사용될 암호화 알고리즘을 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CryptoToBeUsed"로 설정할 수 있다.
또한, 제1 SSP(610)은 수신된 "제2 SSP(660)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보"의 리스트를 확인하여 그 중 자신 역시 지원하는 표준 규격의 버전이 존재하는지를 확인할 수 있다.
상술한 '인증서 협상 과정'이 실패했을 경우 (가령, "SenderSpblVerification"를 확인하여 자신(즉, 제1 SSP)를 검증할 수 있는 인증서 정보가 그 속에 포함되어 있지 않거나, "ReceiverSpblVerification"을 확인하여 자신(즉, 제1 SSP)이 다른 SSP를 검증하기 위해 사용할 수 있는 인증서 정보가 포함되어 있지 않은 경우) 두 단말 간 오프라인 방식을 이용한 번들 전송은 중단될 수 있다. 이때, "결정된 옵션(Determined Option)"에 온라인 방식을 이용한 서비스 이동이 허용되어 있다면, 두 단말 간 온라인 방식을 이용한 서비스 이동이 개시될 수 있다. 이 과정은, 제1 단말이 제2 단말로 오프라인 방식을 이용한 서비스 이동이 실패했음을 알리고, 제1 단말과 제2 단말이 온라인 방식의 서비스 이동을 개시함으로써 시작될 수 있다. 온라인 방식의 서비스 이동에 대한 설명은 도7 내지 도10의 설명을 참조하기로 한다.
도 6을 참조하면 6030 단계에서 다음의 과정이 수행될 수 있다.
제 1 SSP(610)은 자신을 인증할 수 있는 "제1 단말 인증 정보(Device1.Auth)"를 생성할 수 있다. 이 과정에 대한 보다 구체적인 절차는 다음과 같다.
상술한 "제1 단말 인증 정보(Device1.Auth)"는 6025 단계에서 설명된 "ssp1.Cert.KA", "ssp1.ePK.KA" "CiPkIdToBeUsed", "CryptoToBeUsed" 중 적어도 하나를 포함할 수 있다. 또한, "제1 단말 인증 정보(Device1.Auth)"는 상기에 설명된 "ssp1.Cert.DS"를 선택적으로 더 포함할 수 있다. 또한, "제1 단말 인증 정보(Device1.Auth)"는 향후 전송될 번들에 연관된 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "제1 단말 인증 정보(Device1.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp1.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "제1 단말 인증 정보"의 일부로서 추가될 수 있다.
제1 SSP(610)은 제1 LBA(620)을 거쳐 제2 LBA(670)에게 "제1 단말 인증 정보(Device1.Auth)"를 전달할 수 있다.
도 6을 참조하면, 6035단계에서 제2 LBA(670)은 제2 SSP(660)에게 "제1 단말 인증 정보(Device1.Auth)"를 전달할 수 있다. 또한, 제2 LBA(670)은 제2 SSP(660)에게 이동하고자 하는 번들을 지칭할 수 있는 정보 (예컨대, 번들 식별자(SPB ID))를 전달할 수 있다.
도 6을 참조하면, 6040 단계에서 다음의 과정 중 적어도 하나가 수행될 수 있다.
제2 SSP(660)은 수신한 "제1 단말 인증 정보(Device1.Auth)"를 검증할 수 있다. 만일, 제2 SSP(660)이 "ssp1.Cert.KA"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(660)이 "ssp1.ePK.KA"와 이에 대한 디지털 서명을 전송 받은 경우, 먼저 ssp1.Cert.DS의 유효성을 검사한 뒤 이 인증서를 이용하여 디지털 서명을 확인해 수신된 공개키 ssp1.ePK.KA 의 무결성을 확인할 수 있다. 또한, 제2 SSP(660)은 수신된 "CiPkIdToBeUsed"를 확인해 자신을 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp2.Cert.DS)를 선택할 수 있다.
또한, 도면에는 도시되어 있지 않지만, 제2 SSP(660)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair)으로 공개키 "ssp2.ePK.KA"와 비밀키 "ssp2.eSK.KA"를 생성한 뒤, 이 키 쌍 중 공개키(ssp2.ePK.KA)를 선택할 수 있다. 또한, 제2 SSP(660)은 ssp1.Cert.KA에 포함되어 있는 키 합의용 공개키나 ssp1.ePK.KA 중 하나를 선택한 뒤, 이 값과 ssp2.eSK.KA를 이용하여 향후 단말 1과의 통신 중 암호화에 사용될 세션 키 ShKey01을 생성할 수 있다. ShKey01은 수신된 "CryptoToBeUsed"에 포함되어 있는 암호화 알고리즘용 세션 키여야 한다.
제2 SSP(660)은 자신을 인증할 수 있는 "제2 단말 인증 정보(Device2.Auth)"를 생성할 수 있다. 이때, "제2 단말 인증 정보(Device2.Auth)"는 "ssp2.Cert.DS"를 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 "ssp2.ePK.KA"를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 제2 SSP (660)에 의해 생성된 현재 세션을 지칭하는 트랜잭션 아이디(transaction ID)를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 이동하고자 하는 번들을 지칭할 수 있는 정보 (예컨대, 번들 식별자(SPB ID))를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 제2 SSP(660)의 SSP 식별자를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 제2 SSP(660)의 파트 넘버 아이디(Part Number ID)를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 향후 전송될 번들에 연관된 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "제2 단말 인증 정보(Device2.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp2.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "제2 단말 인증 정보"의 일부로서 추가될 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKey01를 이용해 암호화될 수 있다.
제2 SSP(660)은 제2 LBA(670)과 제1 LBA(620)을 거쳐 제1 SSP(610)로 "제2 단말 인증 정보(Device2.Auth)"를 전달할 수 있다.
도 6을 참조하면, 6045 단계에서 다음의 과정 중 적어도 하나가 수행될 수 있다.
제1 SSP(610)은 수신한 "제2 단말 인증 정보(Device2.Auth)"를 검증할 수 있다. 제1 SSP(610)은 수신한 "ssp2.Cert.DS"의 서명을 검증하여 해당 인증서의 유효성을 검증할 수 있다. 또한, 제1 SSP(610)은 수신한 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 혹은 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID)가 자신이 이동하고자 하는 서비스와 연관된 번들의 정보와 일치하는지 검사할 수 있다.
제1 SSP(610)은 수신한 번들 식별자와 연관된 번들의 번들 이동 설정을 확인하여 해당 번들이 제2 단말로 전송이 가능한 번들인지를 확인할 수 있다. 또한, 제1 SSP(610)은 수신된 트랜잭션 아이디(transaction ID)나 제2 SSP(660)에 탑재된 프라이머리 플랫폼의 아이디(Primary Platform Identifier)를 저장할 수 있다.
제1 SSP(610)는 수신한 프라이머리 플랫폼의 아이디 및/또는 파트 넘버 아이디를 이용해 제 2 SSP(660)가 자신이 전송한 번들을 설치하고 사용할 수 있는 SSP인지를 확인할 수 있다(이 과정은 적합성 검사(Eligibility Check)라 지칭될 수 있다.). 만일 적합성 검사 결과 제1 단말이 전송할 번들이 제2 단말에 설치되어 동작하지 않는 것으로 판단되고, “결정된 옵션(Determined Option)"에 온라인 방식을 이용한 서비스 이동이 허용되어 있다면, 두 단말 간 온라인 방식을 이용한 서비스 이동이 개시될 수 있다. 이 과정은, 제1 단말이 제2 단말로 오프라인 방식을 이용한 서비스 이동이 실패했음을 알리고, 제1 단말과 제2 단말이 온라인 방식의 서비스 이동을 개시함으로써 시작될 수 있다.
상기에 기술된 과정에서, 만일 "제2 단말 인증 정보(Device2.Auth)"에 암호화된 데이터가 포함되어 있을 경우, 제1 SSP(610)은 전송 받은 ssp2.ePK.KA와 자신의 ssp1.Cert.KA에 포함되어 있는 키 합의용 공개키에 대응되는 비밀키나 ssp1.eSK.KA를 이용하여 세션 키 ShKey01를 생성하고, 이 세션 키를 이용하여 암호화된 데이터를 복호화한 뒤 검증 과정을 수행할 수 있다. 또한 이 과정에서, 만일 "제2 단말 인증 정보(Device2.Auth)"에 디지털 서명이 포함되어 있을 경우, 제1 SSP(610)은 "ssp2.Cert.DS"를 이용하여 수신된 디지털 서명의 유효성을 검증할 수 있다.
도 6을 참조하면, 6050 단계에서 다음의 과정 중 적어도 하나가 수행될 수 있다.
제1 SSP(610)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "ssp1.bundle.ePK.KA"와 비밀키 "ssp1.bundle.eSK.KA"를 을 생성할 수 있다. 이때, 키 쌍 "ssp1.bundle.ePK.KA 와 ssp1.bundle.eSK.KA"는 앞서 생성되었던 "ssp1.ePK.KA 와 ssp1.eSK.KA"와 동일한 값으로 설정될 수도 있다. 또는, 키 쌍 "ssp1.bundle.ePK.KA 와 ssp1.bundle.eSK.KA"는 앞서 사용되었던 "ssp1.Cert.KA에 포함되어 있는 공개키와 이에 대응되는 비밀키"와 동일한 값으로 설정될 수도 있다. 또한, 제1 SSP(710)은 ssp1.bundle.eSK.KA와 ssp2.ePK.KA를 이용하여 세션 키 ShKey02를 생성할 수 있다. 만일 ssp1.bundle.eSK.KA를 위해 ssp1.eSK.KA 혹은' ssp1.Cert.Ka에 포함되어 있는 공개키에 대응되는 비밀키'가 재사용되었다면, 세션 키 ShKey02의 값 역시 이전에 생성되었던 ShKey01의 값으로 설정될 수 있다.
제1 SSP(610)은 제2 단말(650)으로 전송할 번들 및/또는 번들과 연관된 메타데이터를 구성할 수 있다. 이때, 제1 SSP(610)은 수신된 '번들 구분자'를 이용하여 자신이 전송하고자 하는 번들을 식별할 수 있다. 또한, 구성될 번들에는 "ssp1.Cert.DS"가 포함될 수 있다. 또한, 구성될 번들에는 "ssp1.bundle.ePK.KA"가 더 포함될 수 있다. 또한, 구성될 번들은 해당 세션을 식별하는 트랜잭션 아이디(transaction ID)를 더 포함할 수 있다. 또한, 구성될 번들에는 전송될 번들과 연관된 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 선택적으로 더 포함될 수 있다. 또한, 구성될 번들은 해당 번들의 메타데이터를 선택적으로 더 포함할 수 있다. 또한, 구성될 번들에는 번들 관리 서버의 주소(SPBM Addr)가 선택적으로 더 포함될 수 있다.
다양한 실시예에 따르면, 상술한 번들에는 ssp1.Cert.DS를 이용하여 생성된 디지털 서명 데이터가 추가될 수 있다. 즉, 상기에 명시된 번들의 구성 요소 일부 혹은 전체에 대하여 생성된 디지털 서명 데이터가 번들의 일부로서 추가될 수 있다. 또한, 구성될 번들의 일부 혹은 전체는 ShKey02를 이용해 암호화될 수 있다.
상술한 번들은 묶인 번들 재료(Bound Bundle Material)라 지칭될 수 있다.
제1 SSP(610)은 제1 LBA(620)을 거쳐 제2 LBA(670)에게 묶인 번들 재료를 전송할 수 있다.
도 6을 참조하면, 6055 단계에서 제2 LBA(670)과 제2 SSP(660)은 서로 협업하여 제2 단말(650)에 번들을 설치할 수 있다.
만일 메타데이터가 전송된 경우, 제2 LBA(670) 혹은 제2 SSP(660)은 메타데이터에 포함된 내용을 검증할 수 있다. 만일 트랜잭션 아이디(transaction ID)가 전송되었다면, 제2 LBA(670) 혹은 제2 SSP(660)은 이 트랜잭션 아이디가 현재 세션에서 사용되었던 트랜잭션 아이디와 동일한지 여부를 검사할 수 있다. 만일 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 전송되었다면, 제2 LBA(670) 혹은 제2 SSP(660)은 이 정보가 현재 설치하려는 번들의 정보와 일치하는지 여부를 확인할 수 있다.
만일 수신한 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(660)은 전송 받은 ssp1.bundle.ePK.KA와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey02를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(660)은 ssp1.Cer.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
도 7은 본 개시의 실시 예에 따른 번들 혹은 번들과 연관된 서비스의 온라인 이동 절차를 개념적으로 도시하는 도면이다.
도 7을 참조하면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 4에 도시된 것처럼, 제1 단말(710)은 제1 LBA(730)과 제1 SSP(720)을 포함하고, 제2 단말(760)은 제2 LBA(780)과 제2 SSP(770)을 포함할 수 있다. 번들 관리 서버(750)에 대한 설명은 도 4를 참조하기로 한다.
도 7에 도시된 절차는 도 5에 도시된 절차 이후에 이루어질 수 있다.
7005 단계에서, 제2 단말(760)은 번들 관리 서버(750)로부터 번들과 연관된 서비스의 이동 승인을 받을 수 있다. 해당 절차에 대한 보다 자세한 설명은 후술할 도 8의 상세 설명을 참조하기로 한다.
7010 단계에서, 제1 단말(710)은 번들 관리 서버(750)의 요청에 따라 이동하고자 하는 서비스와 연관된 번들에 대해 일련의 작업을 수행할 수 있다. 예를 들어, 제1 단말(710)은 자신이 보유한 번들 및/또는 번들의 일부 데이터를 번들 관리 서버(750)로 업로드할 수 있다. 또 다른 예로, 제1 단말(710)은 자신이 보유한 번들을 삭제할 수 있다. 해당 절차에 대한 보다 자세한 설명은 후술할 도 9의 상세 설명을 참조하기로 한다.
7015 단계에서, 제2 단말(760)은 번들 관리 서버(750)로부터 번들을 다운로드 받아 설치할 수 있다. 해당 절차에 대한 보다 자세한 설명은 후술할 도 10의 상세 설명을 참조하기로 한다.
도 8은 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제2 단말(860)이 번들 관리 서버(850)로부터 온라인 이동 승인을 받는 절차를 도시하는 도면이다.
도 8을 참조하면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 제2 단말(860)은 제2 LBA(880)과 제2 SSP(870)을 포함할 수 있다. 번들 관리 서버(850)에 대한 설명은 도 4를 참조하기로 한다.
도 8을 참조하면, 8000 단계에서, 제2 LBA(880)은 제2 SSP(870)에게 "SSP 정보 (SspInfo)"를 요청할 수 있다.
제2 LBA(880)는 제2 SSP(870)에게 "SSP 정보 (SspInfo)"를 요청할 때, 제2 SSP에게 번들과 관련된 서비스의 이동이 수행될 것임을 알려줄 수 있다. 제2 LBA(980)는 제2 SSP(870)에게 "SSP 정보 (SspInfo)"를 요청할 때, 제2 SSP에게 번들과 관련된 서비스의 온라인 이동이 수행될 것임을 더 알려줄 수 있다. 예를 들면, 요청 메시지에는 번들과 관련된 서비스의 이동이 수행될 것임을 알리는 지시자(indicator)가 포함될 수 있다. 다른 예로, 요청 메시지에는 번들과 관련된 서비스의 온라인 이동이 수행될 것임을 알리는 지시자(indicator)가 포함될 수 있다. 요청 메시지는 지시자를 포함시키거나, 지시자의 값을 특정한 값으로 설정함으로써 제2 SSP에게 번들과 연관된 서비스의 이동이 수행될 것 또는 번들과 연관된 서비스의 온라인 이동이 수행될 것임을 알려줄 수 있다.
제2 LBA(880)는 제2 SSP(870)에게 이동될 서비스와 연관된 번들에 대한 정보를 제공할 수 있다. 이 정보에는 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 포함될 수 있다.
도 8을 참조하면, 8005 단계에서, 제2 SSP는 자신의 "SSP 정보(ssp2.SspInfo)"를 생성하고, 제2 LBA(880)을 거쳐 번들 관리 서버(850)에게 "SSP 정보"를 전송할 수 있다.
"SSP 정보"에는 번들과 연관된 서비스의 이동을 위해 제공되어야 하는 제2 SSP의 정보가 포함될 수 있다. 이때, "SSP 정보"에는 제2 SSP(870)가 번들 관리 서버(850)와 통신하기 위해 거쳐야 할 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. "인증서 협상 정보"는 제2 SSP(870)가 번들 관리 서버(850)를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 번들 관리 서버(850)가 제2 SSP(870)를 검증하기 위해 사용할 수 있는 인증서 정보들을 포함할 수 있다. 또한, "인증서 협상 정보"는 제2 SSP가 지원하는 키 합의 알고리즘의 리스트를 더 포함할 수 있으며, 제2 SSP가 지원하는 암호화 알고리즘의 리스트를 더 포함할 수 있다.
또한, "SSP 정보"에는 제2 SSP가 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보들 중에서 적어도 하나의 버전 정보를 포함하는 SSP 버전 정보가 더 포함될 수 있다.
일 실시 예에서, 제2 SSP(870)는 제2 LBA(880)를 거쳐 번들 관리 서버(850)에게 "SSP 정보"를 전송할 수 있다.
8000 단계 내지 8005 단계에 따르면, 제2 LBA가 제2 SSP에게 "SSP 정보"를 요청하고, 제2 SSP가 자신의 "SSP 정보"를 생성한 뒤, 제2 SSP가 제2 LBA를 거쳐 번들 관리 서버에게 "SSP 정보"를 전송할 수 있다. 하지만, 실시 예에 따라서는, 제2 LBA가 스스로 "SSP 정보"를 생성한 뒤 번들 관리 서버에게 "SSP 정보"를 전송할 수도 있다.
도 8을 참조하면, 8010 단계에서 번들관리서버(850)는 수신한 "SSP 정보"를 확인하고 이 정보에 기반하여 "서버 인증 정보(SPBM.Auth2)"를 생성하고, 제2 LBA에게 생성된 "서버 인증 정보"를 전송할 수 있다.
"서버 인증 정보는 다음과 같은 정보를 하나 이상 포함할 수 있다.
a)
SPBM 자신을 검증하는데 사용될 수 있는 키 합의용 인증서 (SPBM.Cert.KA라 칭함) 와 이 인증서를 검증하기 위해 필요한 인증서들.
b)
SPBM이 제2 SSP를 검증하기 위해 사용할 인증서 정보 (CiPkIdToBeUsed라 칭함)
c)
SPBM이 제2 SSP와 암호화 통신을 할 때 사용할 암호화 알고리즘의 정보 (CryptoToBeUsed라 칭함)
일 실시예에서, 번들관리서버(850)은 제2 LBA(880)에게 "서버 인증 정보"를 전송할 수 있다.
도 8을 참조하면, 8015 단계에서 제2 LBA(880)은 제2 SSP(870)에게 "서버 인증 정보"를 전달할 수 있다. 제2 LBA(880)은 제2 SSP(1170)에게 이동될 서비스와 연관된 번들의 번들 구분자를 더 전송할 수 있다. 제2 LBA(880)은 제2 SSP(870)에게 Supported Crypto Info 를 더 전송할 수 있다. Supported Crypto Info 에 관한 설명은 도 5를 참고한다.
도 8을 참조하면, 8020 단계에서, 제2 SSP(870)은 다음에 명시된 작업 중 하나 이상을 실행할 수 있다.
a)
"SPBM.Cert.KA"의 유효성을 확인할 수 있다.
b)
수신한 "CiPkIdToBeUsed"에 기초하여 제2 SSP를 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp2.Cert.DS)를 선택할 수 있다.
c)
수신한 "CryptoToBeUsed"를 확인하고, 번들 관리 서버와 암호화 통신 용 암호화 키를 만들기 위해 사용될 암호화용 키 쌍(key pair)인 공개키 "ssp2.ePK.KA"와 비밀키 "ssp2.eSK.KA"를 생성할 수 있다. 또한, 제2 SSP는 SPBM.Cert.KA에 포함되어 있는 키 합의용 공개키와 ssp2.eSK.KA를 이용하여 번들 관리 서버와 암호화 통신에 사용될 세션 키인 ShKeyM2을 생성할 수 있다.
일 실시예에서, 제2 SSP(1170)은 "제2 단말 인증 정보(Device2.Auth)"를 생성할 수 있다. "제2 단말 인증 정보(Device2.Auth)"는 다음의 정보들을 하나 이상 포함할 수 있다.
a)
Ssp2.Cert.DS
b)
Ssp2.ePK.KA
c)
현재 세션을 지칭하는 트랜잭션 아이디(transaction ID)
d)
제2 SSP의 SSP 식별자
e)
제2 SSP의 파트 넘버 아이디
f)
이동될 서비스와 연관된 번들의 번들 구분자
일 실시 예에서, 제2 SSP(870)는 수신한 Supported Crypto Info를 확인해 그 중 제2 단말(가령 제2 SSP)가 지원하는 암호화 알고리즘들이 존재하는지 확인할 수 있다. 수신한 supported Crypto Info 중 제2 단말이 지원하는 암호화 알고리즘들이 존재할 경우 제2 SSP(870)는 이것들 중 하나를 택해 '선택된 암호화 알고리즘'으로 설정할 수 있다. '선택된 암호화 알고리즘'은 다음의 정보들을 하나 이상 선택적으로 포함할 수 있다: 타원 곡선 커브 정보, 키 합의 알고리즘 정보, 암호화 알고리즘 정보.
제2 SSP(870)는 '선택된 암호화 알고리즘'에 기반하여 추후 '제1 단말과의 암호화 통신 용 암호화 키'를 만들기 위해 사용될 제2 단말의 키 쌍(임시 공개키 ssp2.ePK.BT 와 그에 대응되는 비밀키 ssp2.eSK.BT) 을 만들 수 있다. 제2 SSP(870)는 생성한 키 쌍과 이동될 서비스와 연관된 번들의 번들 구분자(SPB ID)를 매핑 시킬 수 있다. 제2 SSP(870)는 "선택된 암호화 정보 (ssp2.SelectedCryptoInfo)"를 생성할 수 있다. "선택된 암호화 정보"는 다음의 정보들을 하나 이상 선택적으로 포함할 수 있다: 선택된 암호화 알고리즘의 일부 및/또는 전체, ssp2.eEPK.BT
"제2 단말 인증 정보(Device2.Auth)" 및/또는 "선택된 암호화 정보 (ssp2.SelectedCryptoInfo)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp2.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 디지털 서명 데이터는 "제2 단말 인증 정보"의 일부로서 추가될 수 있다.
또한, "제2 단말 인증 정보(Device2.Auth)" 및/또는 "선택된 암호화 정보 (ssp2.SelectedCryptoInfo)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKeyM2를 이용해 암호화될 수 있다.
제2 SSP(870)는 제2 LBA(880)에게 "제2 단말 인증 정보(Device2.Auth)" 및/또는 "선택된 암호화 정보 (ssp2.SelectedCryptoInfo)"를 전송할 수 있다.
도 8을 참조하면, 8025 단계에서, 다음에 명시된 작업 중 하나 이상이 실행할 수 있다. 제2 LBA(880)는 번들 관리 서버(850)에게 "제2 단말 인증 정보(Device2.Auth)"를 전송할 수 있다. 제2 LBA(880)는 번들 관리 서버(850)에게 선택된 암호화 정보 (ssp2.SelectedCryptoInfo)"를 전송할 수 있다. 제2 LBA(880)는 번들 관리 서버(850)에게 "결정된 옵션(Determined Option)"를 전송할 수 있다. "결정된 옵션(Determined Option)"에 대한 설명은 도 5를 참조하기로 한다.
도 8을 참조하면, 8030 단계에서, 번들 관리 서버(850)은 다음의 과정 중 하나 이상을 수행할 수 있다.
a)
번들 관리 서버는, "제2 단말 인증 정보"에 포함된 ssp2.Cert.DS의 유효성을 검증할 수 있다. 또한, 번들 관리 서버는 "제2 단말 인증 정보"에 전자 서명이 포함되어 있는 경우 ssp2.Cert.DS를 이용해 서명의 유효성을 검증할 수 있다.
b)
번들 관리 서버는, "제2 단말 인증 정보"에 암호화되어 있는 데이터가 있는 경우, 'SPBM.Cert.KA에 포함되어 있는 키 합의 용 공개키에 대응되는 비밀키'와 ssp2.ePK.KA를 이용하여 제2 단말과 암호화 통신에 사용될 세션 키인 ShKeyM2를 생성하고, 이 세션 키를 이용해 암호화되어 있는 데이터를 복호할 수 있다
c)
번들 관리 서버는, 수신된 트랜잭션 아이디 및/또는 제2 SSP의 SSP 식별자를 확인 및/또는 저장할 수 있다.
d)
번들 관리 서버는 제2 단말이 이용하고자 하는 서비스와 연관된 번들의 번들 구분자를 확인 및/또는 저장할 수 있다.
일 실시예에서, 번들 관리 서버(850)는 다음의 과정 중 하나 이상을 더 수행할 수 있다.
a)
번들 관리 서버는 제2 단말이 이용하고자 하는 서비스와 연관된 번들의 번들 구분자를 확인하여 해당 서비스가 온라인 방식을 통하여 이동이 가능한 번들인지를 검사할 수 있다. 예를 들어, 온라인 이동이 가능한 서비스인지를 검사하는 과정은 번들 관리 서버(850)가 이동하고자 하는 서비스와 연관된 번들의 '번들 이동 설정' 값을 이용해 검증을 수행함으로써 이루어질 수 있다.
b)
번들 관리 서버는 제 2 단말이 이용하고자 하는 서비스와 연관된 번들 및/또는 번들의 일부 데이터가 제2 단말로 이동할 경우, 이 번들 및/또는 번들의 일부 데이터가 제2 단말(가령, 제2 SSP)에 정상적으로 설치 및/또는 작동이 되는지의 여부를 확인할 수 있다. (이 과정은 적합성 검사 혹은 Eligibility Check 라 명명될 수 있다.) 예를 들어, 이 확인 과정은 제2 단말(가령, 제2 SSP)의 파트 넘버 아이디 및/또는 제2 단말이 이용하고자 하는 서비스와 연관된 번들의 번들 구분자를 이용하여 수행될 수 있다.
일 실시 예에서, 번들 관리 서버(850)는 다음의 정보 중 일부 혹은 전체를 서로 매핑 시킬 수 있다: 제2 SSP의 SSP 식별자, 제2 단말이 이용하고자 하는 서비스와 연관된 번들의 번들 구분자, "선택된 암호화 정보 (ssp2.SelectedCryptoInfo)"
도 9는 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제1 단말(910)이 번들 관리 서버(950)의 요청에 따라 이동하고자 하는 서비스와 연관된 번들에 대해 일련의 작업을 수행하는 절차를 도시하는 도면이다.
도 9를 참조하면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 제1 단말(910)은 제1 LBA(930)과 제1 SSP(920)을 포함할 수 있다. 번들 관리 서버(950)에 대한 설명은 도 4를 참조하기로 한다.
도 9를 참조하면, 9000 단계에서, 제1 LBA(930)은 제1 SSP(920)에게 "SSP 정보 (SspInfo)"를 요청할 수 있다.
제1 LBA는 제1 SSP에게 "SSP 정보 (SspInfo)"를 요청할 때, 제1 SSP에게 서비스의 이동이 수행될 것임을 알려줄 수 있다. 제1 LBA는 제1 SSP에게 "SSP 정보 (SspInfo)"를 요청할 때, 제1 SSP에게 서비스의 온라인 방식 이동이 수행될 것임을 더 알려줄 수 있다. 예를 들면, 요청 메시지에는 서비스 이동이 수행될 것임을 알리는 지시자(indicator)가 포함될 수 있다. 다른 예로, 요청 메시지에는 서비스의 온라인 방식 이동이 수행될 것임을 알리는 지시자(indicator)가 포함될 수 있다. 요청 메시지는 지시자를 포함하거나, 지시자의 값을 특정한 값으로 설정함으로써 제1 SSP에게 서비스의 이동이 수행될 것 또는 서비스의 온라인 방식 이동이 수행될 것임을 알려줄 수 있다.
제1 LBA는 제1 SSP에게 이동할 서비스와 연관된 번들에 대한 정보를 제공할 수 있다. 이 정보에는 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 포함될 수 있다.
도 9를 참조하면, 9005 단계에서, 제1 SSP(920)는 자신의 "SSP 정보(ssp1.SspInfo)"를 생성하고, 제1 LBA(930)을 거쳐 번들 관리 서버(950)에게 "SSP 정보"를 전송할 수 있다.
"SSP 정보"에는 서비스의 온라인 이동을 위해 제공되어야 하는 제1 SSP의 정보가 포함될 수 있다. 이때, "SSP 정보"에는 제1 SSP가 번들 관리 서버와 통신하기 위해 거쳐야 할 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. "인증서 협상 정보"는 제1 SSP가 번들 관리 서버를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 번들 관리 서버가 제1 SSP를 검증하기 위해 사용할 수 있는 인증서 정보들을 포함할 수 있다. 또한, "인증서 협상 정보"는 제1 SSP가 지원하는 키 합의 알고리즘의 리스트를 더 포함할 수 있으며, 제1 SSP가 지원하는 암호화 알고리즘의 리스트를 더 포함할 수 있다.
또한, "SSP 정보"에는 제1 SSP가 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보들 중에서 적어도 하나의 버전 정보를 포함하는 SSP 버전 정보가 더 포함될 수 있다.
일 실시 예에서, 제1 SSP(920)는 제1 LBA(930)를 거쳐 번들 관리 서버(950)에게 "SSP 정보"를 전송할 수 있다.
9000 단계 내지 9005 단계에 따르면, 제1 LBA가 제1 SSP에게 "SSP 정보" 를 요청하고, 제1 SSP가 자신의 "SSP 정보"를 생성한 뒤, 제1 SSP가 제1 LBA를 거쳐 번들 관리 서버에게 "SSP 정보"를 전송할 수 있다. 하지만, 실시예에 따라서는, 제1 LBA가 스스로 "SSP 정보"를 생성한 뒤 번들 관리 서버에게 "SSP 정보"를 전송할 수도 있다.
도 9를 참조하면, 9010 단계에서 번들관리서버(1250)는 수신한 "SSP 정보"를 확인하고 이 정보에 기반하여 "서버 인증 정보(SPBM.Auth1)"를 생성하고, 제1 LBA(930)에게 "서버 인증 정보"를 전송할 수 있다.
"서버 인증 정보"는 다음과 같은 정보를 하나 이상 포함할 수 있다.
a)
번들 관리 서버 자신을 검증하는데 사용될 수 있는 키 합의용 인증서 (SPBM.Cert.KA라 칭함) 와 이 인증서를 검증하기 위해 필요한 인증서들.
b)
번들 관리 서버가 제1 SSP를 검증하기 위해 사용할 인증서 정보 (CiPkIdToBeUsed라 칭함)
c)
번들 관리 서버가 제1 SSP와 암호화 통신을 할 때 사용할 암호화 알고리즘의 정보 (CryptoToBeUsed라 칭함)
일 실시 예에서, 번들관리서버(950)은 제1 LBA(930)에게 "서버 인증 정보"를 전송할 수 있다.
도 9를 참조하면, 9015 단계에서 제1 LBA(930)은 제1 SSP(920)에게 "서버 인증 정보"를 전달할 수 있다. 제1 LBA(930)은 제1 SSP(920)에게 "이동하고자 하는 서비스와 연관된 번들의 번들 구분자"를 더 전송할 수 있다.
도 9를 참조하면, 9020 단계에서, 제1 SSP(920)은 다음에 명시된 작업 중 하나 이상을 실행할 수 있다.
a)
수신한 "SPBM.Cert.KA"의 유효성을 확인할 수 있다.
b)
수신한 "CiPkIdToBeUsed"에 기초하여 제1 SSP를 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp1.Cert.DS)를 선택할 수 있다.
c)
수신한 "CryptoToBeUsed"를 확인하고, 번들 관리 서버와 암호화 통신 용 암호화 키를 만들기 위해 사용될 암호화용 키 쌍(key pair)인 공개키 "ssp1.ePK.KA"와 비밀키 "ssp1.eSK.KA"를 생성할 수 있다. 또한, 제1 SSP는 SPBM.Cert.KA에 포함되어 있는 키 합의용 공개키와 ssp1.eSK.KA를 이용하여 번들 관리 서버와 암호화 통신에 사용될 세션 키인 ShKeyM1을 생성할 수 있다.
제1 SSP(920)은 "제1 단말 인증 정보(Device1.Auth)"를 생성하고 번들 관리 서버(950)에게 "제1 단말 인증 정보(Device1.Auth)"를 전송할 수 있다. "제1 단말 인증 정보(Device1.Auth)"는 다음의 정보들을 하나 이상 포함할 수 있다.
a)
ssp1.Cert.DS
b)
ssp1.ePK.KA
c)
현재 세션을 지칭하는 트랜잭션 아이디(transaction ID)
d)
제1 SSP의 SSP 식별자
e)
이동하고자 하는 서비스와 연관된 번들의 번들 구분자
"제1 단말 인증 정보(Device1.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp1.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 디지털 서명 데이터는 "제1 단말 인증 정보"의 일부로서 추가될 수 있다.
또한, "제1 단말 인증 정보(Device1.Auth)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKeyM1를 이용해 암호화될 수 있다.
일 실시 예에서, 제1 SSP(920)는 제1 LBA(930)를 거쳐 번들 관리 서버(950)에게 "제1 단말 인증 정보(Device1.Auth)"를 전송할 수 있다.
도 9를 참조하면, 9025 단계에서, 번들 관리 서버(950)은 다음의 과정 중 하나 이상을 수행할 수 있다.
a)
번들 관리 서버는, "제1 단말 인증 정보"에 포함된 ssp1.Cert.DS의 유효성을 검증할 수 있다. 또한, 번들 관리 서버는 "제1 단말 인증 정보"에 전자 서명이 포함되어 있는 경우 ssp1.Cert.DS를 이용해 서명의 유효성을 검증할 수 있다.
b)
번들 관리 서버는, "제1 단말 인증 정보"에 암호화되어 있는 데이터가 있는 경우, 'SPBM.Cert.KA에 포함되어 있는 키 합의 용 공개키에 대응되는 비밀키'와 ssp1.ePK.KA를 이용하여 제1 단말과 암호화 통신에 사용될 세션 키인 ShKeyM1을 생성하고, 이 세션 키를 이용해 암호화되어 있는 데이터를 복호할 수 있다
c)
번들 관리 서버는, 수신된 트랜잭션 아이디 및/또는 제1 SSP의 SSP 식별자를 확인 및/또는 저장할 수 있다.
d)
번들 관리 서버는 제1 단말이 전송한 번들의 번들 구분자를 확인 및/또는 저장할 수 있다.
일 실시예에서, 번들 관리 서버(950)는 다음의 과정 중 하나 이상을 더 수행할 수 있다.
a)
번들 관리 서버는 '제1 SSP의 SSP 식별자'와 '제1 단말이 전송한 번들의 번들 구분자'를 사용해 제1 단말(가령, 제1 SSP)가 현재 해당 번들의 정당한 사용 주체임을 검사할 수 있다.
b)
번들 관리 서버는 '제1 단말이 전송한 번들 구분자에 대응되는 번들과 연관된 서비스'가 이미 다른 단말(가령, 도8에 도시된 것과 같이 제2 단말에 의해)에 의해 이동이 요청되었는지를 검사할 수 있다. 가령, 번들 관리 서버는 '제1 단말이 전송한 번들 구분자'가 도 8의 8030 단계를 통해 저장된 번들 구분자인지 여부를 확인할 수 있다.
상술한 검사의 결과 '제1 단말이 전송한 번들 구분자와 연관된 번들의 정당한 사용 주체가 제1 단말'임이 확인되었고, 이 번들과 연관된 서비스가 다른 단말(가령, 도8에 도시된 것과 같이 제2 단말)에 의해 이동이 요청된 것이라면, 번들 관리 서버는 8025 단계에서 수신한 "결정된 옵션(Determined Option)" 및/또는 8030 단계에서 수행한 "적합성 검사(Eligibility Check)"의 결과를 사용해, 제1 단말이 어떠한 동작을 수행해야 하는지를 결정해 "전송 옵션(Transfer Option)"을 생성할 수 있다. 예를 들어, 번들 관리 서버는, "결정된 옵션"에서 허용되었고 동시에 "적합성 검사" 결과 수행이 가능한, 이동 방식들 중 하나를 선택한 뒤 이것을 기반으로 "전송 옵션"을 구성할 수 있다. 가령, "전송 옵션"은 다음의 데이터들 중 적어도 하나 이상을 포함할 수 있다.
a)
번들 관리 서버(950)을 지칭하는 정보 (가령, 번들 관리 서버의 OID)
b)
제1 단말(910)을 지칭하는 정보 (가령, 제1 SSP의 SSP 식별자)
c)
제2 단말(860)을 지칭하는 정보 (가령, 제2 SSP의 SSP의 식별자)
d)
이동하고자 하는 서비스와 연관된 번들의 번들 구분자(SPB ID)
e)
제1 단말이 전송해야 하는 정보를 지칭하는 정보
- 제1 단말이 이동하고자 하는 서비스와 연관된 번들을 번들 관리 서버에 전송해야 함
- 제1 단말이 이동하고자 하는 서비스와 연관된 번들의 정보 중 일부(가령, 제1 단말에 번들이 설치된 후 이루어진 일련의 업데이트, 가령 서비스 제공자에 의해 이루어진 업데이트 및/또는 사용자에 의해 추가된 설정이나 개인 정보 및/또는 제 3의 서비스 제공자에 의해 이루어진 업데이트 등)를 번들 관리 서버에 전송해야 함
f)
제1 단말이 이동하고자 하는 서비스와 연관된 번들을 삭제해야 하는지 여부
g)
제1 단말이 정보를 전송할 경우 이 정보가 "제1 단말과 제2 단말 사이의 종단 간 암호화"가 되어야 하는지 "제1 단말과 번들 관리 서버 사이의 암호화"가 되어야 하는지를 지칭하는 정보
h)
트랜잭션 아이디
상술한 정보의 일부 및/또는 전체는 ShKeyM1을 사용해 암호화될 수 있고 이것은 "전송 옵션"의 일부로 포함될 수 있다.
상술한 정보의 일부 및/또는 전체는 SPBM.Cert.DS를 사용해 전자 서명될 수 있고 이 전자 서명 값은 "전송 옵션"의 일부로 포함될 수 있다. 이 경우 SPBM.Cert.DS와 SPBM.Cert.DS의 유효성을 검증하기 위해 필요한 일련의 정보가 "전송 옵션"의 일부로 포함될 수 있다.
번들 관리 서버 (950)는 제1 LBA(930)을 거쳐 제1 SSP(920)에게 "전송 옵션 (Transfer Option)"을 전송할 수 있다. 번들 관리 서버(1250)는 제1 LBA(930)을 거쳐 제1 SSP(920)에게 ssp2.SelectedCryptoInfo를 더 전송할 수 있다.
도 9를 참조하면, 9030 단계에서, 제1 SSP(920)는 다음의 과정 중 하나 이상을 수행할 수 있다.
a)
수신한 "전송 옵션"에 암호화된 정보가 포함되어 있을 경우 ShKeyM1을 이용해 복호
b)
수신한 "전송 옵션"에 전자 서명 값이 포함되어 있을 경우 SPBM.Cert.DS의 유효성을 검증한 후 SPBM.Cert.DS를 이용해 전자 서명 값의 유효성을 검증
c)
수신한 "전송 옵션"에 포함되어 있는 번들 관리 서버의 OID 및/또는 제1 SSP의 SSP 식별자 및/또는 제2 SSP의 SSP 식별자 및/또는 이동하고자 하는 서비스와 연관된 번들의 번들 구분자 및/또는 트랜잭션 아이디가 올바른 값인지 검증
제1 SSP(920)는 "전송 옵션"을 이용해 자신이 번들 관리 서버에게 전송해야 할 번들 (혹은 번들 이미지) 및/또는 번들의 일부 데이터가 있는지 여부를 확인할 수 있다.
만일 번들 관리 서버가 번들 및/또는 번들의 일부 데이터를 전송 받기 원할 경우 제1 SSP (920)는 요청된 번들 및/또는 번들의 일부 데이터를 준비할 수 있다.
제1 SSP(920)는 ssp2.SelectedCryptoInfo에 포함된 정보들을 확인할 수 있다.
제1 SSP(920)는 암호화용 키 쌍(key pair)인 공개키 "ssp1.ePK.BT"와 비밀키 "ssp1.eSK.BT"를 설정할 수 있다. 이 값은, 실시 예에 따라 "ssp1.ePK.KA" 및 "ssp1.eSK.KA"의 값과 같을 수 있다.
일 실시 예에 따라, 제1 SSP(920)는 준비한 ssp1.eSK.BT와 'SPBM.Cert.KA에 포함되어 있는 공개키'를 사용해 번들관리서버와의 암호화 통신을 위한 키 ShKeyBT를 생성할 수 있다.
일 실시 예에 따라, 제1 SSP(920)는 준비한 ssp1.eSK.BT와 ssp2.SelectedCryptoInfo에 포함된 ssp2.ePK.BT를 사용해 제2 단말과 암호화 통신을 위한 키 ShKeyBT를 만들 수 있다.
제1 SSP(920)는 '앞서 준비했던 번들 및/또는 번들의 일부 데이터'의 일부 및/또는 전체를 ShKeyBT를 이용해 암호화할 수 있다.
상술한 '준비된 번들 및/또는 번들의 일부 데이터'는 묶인 번들 재료(Bound Bundle Material)'이라 지칭될 수 있다.
제1 SSP(920)는 "전송 옵션"을 이용해 번들 관리 서버가 해당 번들을 삭제하기 원하는지 여부를 확인할 수 있다. 번들 관리 서버가 해당 번들의 삭제를 원할 경우 제1 SSP는 해당 번들을 삭제할 수 있다.
제1 SSP(920)는 제1 LBA(930)에게 "묶인 번들 재료(Bound Bundle Material)"을 전송할 수 있다. 제1 SSP(920)은 제1 LBA(930)에게 ssp1.ePK.BT를 더 전송할 수 있다.
도 9를 참조하면, 9035 단계에서 제1 LBA(930)는 번들 관리 서버(950)에게 "묶인 번들 재료(Bound Bundle Material)을 전송할 수 있다. 제1 LBA(930)는 번들 관리 서버(950)에게 ssp1.ePK.BT를 더 전송할 수 있다.
도 9를 참조하면, 9040 단계에서 번들관리서버(950)는 제1 LBA(930)에게 모든 과정이 수행되었음을 알리는 응답 메시지를 전송할 수 있다.
제1 단말(910)이 번들 관리 서버(950)로 번들 및/또는 번들의 일부 데이터를 보내야 할 필요가 없을 경우 9035 단계와 9040 단계는 생략될 수 있다.
도 10은 본 개시의 실시 예에 따른 도 7에서 제시된 절차 중 제2 단말(1060)이 번들 관리 서버(1050)로부터 번들을 다운로드 받아 설치하는 절차를 도시하는 도면이다.
도 10을 참조하면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 제2 단말(1060)은 제2 LBA(1080)과 제2 SSP(1070)을 포함할 수 있다. 번들 관리 서버(1050)에 대한 설명은 도 4를 참조하기로 한다.
도 10을 참조하면, 10000 단계에서 다음의 과정이 수행될 수 있다.
번들 관리 서버(1050)은 제2 단말(1060)로 전송할 번들과 관련된 데이터를 준비할 수 있다. 이 준비 과정의 가능한 예는 다음과 같다.
[CASE A]
9035 단계에서, 번들 관리 서버가 '제1 단말과 번들 관리 서버 사이의 암호화'가 된 '번들'을 받았다면 복호화를 수행할 수 있다. 일 실시 예에서, 번들 관리 서버는 ShKeyM2를 사용하여 복호화된 번들을 암호화한 뒤 이 번들의 전송을 준비할 수 있다. 또 다른 일 실시 예에서, 번들 관리 서버는 키 쌍(key pair) 인 공개키 "SPBM.ePK.BT"와 비밀키 "SPBM.eSK.BT"를 생성한 뒤, SPBM.eSK.BT와 ssp2.ePK.KA를 사용해 암호화 키 ShKeyBT를 생성하고 이 키를 사용하여 복호화된 번들을 암호화한 뒤 이 번들의 전송을 준비할 수 있다.
[CASE B]
9035 단계에서, 번들 관리 서버가 '제1 단말과 번들 관리 서버 사이의 암호화'가 된 '번들의 일부 데이터'를 받았다면 복호화를 수행할 수 있다. 일 실시 예에서, 번들 관리 서버는 복호화된 번들 데이터를 일부로 포함하는 번들을 준비할 수 있다. 다른 실시 예에서 번들 관리 서버는 제2 단말에 전송할 번들을 준비한 뒤, 복호화된 번들 데이터를 추가 데이터로 포함할 수 있다. 일 실시 예에서, 번들 관리 서버는 ShKeyM2를 사용하여 준비한 번들 및/또는 추가 데이터의 일부 및/또는 전체를 암호화할 수 있다. 또 다른 실시 예에서, 번들 관리 서버는 키 쌍(key pair) 인 공개키 "SPBM.ePK.BT"와 비밀키 "SPBM.eSK.BT"를 생성하고, SPBM.eSK.BT와 ssp2.ePK.KA를 사용해 암호화 키 ShKeyBT를 생성한 뒤, 암호화 키 ShKeyBT를 사용하여 준비한 번들 및/또는 추가 데이터의 일부 및/또는 전체를 암호화할 수 있다.
[CASE C]
9035 단계에서, 번들 관리 서버가 '제1 단말과 제2 단말 사이의 암호화'가 된 '번들'을 받았다면 이 번들을 제2 단말에 전송할 번들로 준비할 수 있다.
[CASE D]
9035 단계에서, 번들 관리 서버가 '제1 단말과 제2 단말 사이의 암호화'가 된 '번들의 일부 데이터'를 받았다면, 번들 관리 서버는 제2 단말로 전송할 번들을 생성하고, 상기의 수신한 번들 데이터를 추가 데이터로 포함할 수 있다. 일 실시 예에서, 번들 관리 서버가 생성한 번들의 일부 및/또는 전체는, ShKeyM2를 사용하여 암호화될 수 있다. 다른 실시 예에서, 번들 관리 서버가 생성한 번들의 일부 및/또는 전체는, 번들 관리 서버가 키 쌍(key pair) 인 공개키 "SPBM.ePK.BT"와 비밀키 "SPBM.eSK.BT"를 생성하고, SPBM.eSK.BT와 ssp2.ePK.KA를 사용해 암호화 키 ShKeyBT를 생성한 뒤, 암호화 키 ShKeyBT를 사용하여 암호화될 수 있다.
[CASE E]
번들 관리 서버가 제1 단말로부터 번들 및/또는 번들의 일부 데이터를 수신하지 않은 경우, 번들 관리 서버는 제2 단말로 전송할 번들을 생성할 수 있다. 일 실시 예에서, 번들 관리 서버가 생성한 번들의 일부 및/또는 전체는, ShKeyM2를 사용하여 암호화될 수 있다. . 다른 실시 예에서, 번들 관리 서버가 생성한 번들의 일부 및/또는 전체는, 번들 관리 서버가 키 쌍(key pair) 인 공개키 "SPBM.ePK.BT"와 비밀키 "SPBM.eSK.BT"를 생성하고, SPBM.eSK.BT와 ssp2.ePK.KA를 사용해 암호화 키 ShKeyBT를 생성한 뒤, 암호화 키 ShKeyBT를 사용하여 암호화될 수 있다.
상기, [CASE A] 내지 [CASE E] 에서 언급한 준비된 번들 및 추가 데이터는 묶인 번들 재료(Bound Bundle Material)라 지칭될 수 있다.
번들 관리 서버(1050)는 제2 LBA(1080)에게 '묶인 번들 재료'를 전송할 수 있다. 번들 관리 서버(1050)는 제2 LBA(1080)에게 SPBM.ePK.BT를 더 전송할 수 있다. 번들 관리 서버(1050)는 제2 LBA(1080)에게 ssp1.ePK.BT를 더 전송할 수 있다.
도 10을 참조하면, 10005 단계에서 제2 SSP에 번들이 설치될 수 있다. 제2 SSP(1070) 및/또는 제2 LBA(1080)는 10000 단계에서 수신한 "묶인 번들 재료"를 사용해 제2 SSP(1070)에 번들을 설치할 수 있다.
일 실시 예에서, 번들 관리 서버(1050)로부터 수신한 번들 및/또는 추가 데이터가 번들 관리 서버와 제2 단말 사이의 암호화 용 키로 암호화되어 있을 경우, 제2 SSP(1070)는 SHkeyM2를 사용해 암호화된 정보를 복호할 수 있다.
다른 일 실시 예에서, 번들 관리 서버(1050)로부터 수신한 번들 및/또는 추가 데이터가, 번들 관리 서버와 제2 단말 사이의 암호화 용 키로 암호화되어 있을 경우, 제2 SSP(1070)는 SPBM.ePK.BT를 사용해 암호화 키 ShKeyBT를 생성한 뒤 이 키를 사용하여 암호화된 정보를 복호할 수 있다.
또 다른 일 실시 예에서, 번들 관리 서버(1050)로부터 수신한 번들 및/또는 추가 데이터가 제1 단말과 제2 단말 사이의 암호화 용 키로 암호화되어 있을 경우, 제2 SSP(1070)는 ssp1.ePK.BT를 사용해 암호화 키 ShKeyBT를 생성한 뒤 이 키를 사용하여 암호화된 정보를 복호할 수 있다.
도 10을 참조하면, 10010 단계에서 제2 SSP(1070)는 번들 관리 서버(1050)로 번들 설치 결과를 고지할 수 있다.
도 11은 하나의 단말에서 다른 단말로 번들 혹은 번들과 연결된 서비스가 오프라인 혹은 온라인 이동되는 전체 과정의 한 가지 예를 도시하는 도면이다.
도 11을 참조하면, 11001 단계의 설명은 다음과 같다.
도 5에 도시된 과정이 수행되고 5020 단계에서 제2 LBA는 "결정된 옵션(Determined Option)"을 생성할 수 있다.
"결정된 옵션"에 "오프라인 이동"이 허용되는 옵션으로 포함되어 있고, "오프라인 이동"이 "결정된 옵션"에 포함된 옵션 중에서 가장 먼저 수행되어야 할 방법이라면 11003 단계가 수행될 수 있다. "결정된 옵션"에 포함된 옵션 중에서 "오프라인 이동"이 가장 먼저 수행되어야 하는지의 여부는 다양한 방법에 의해 결정될 수 있다: 즉, 서비스 제공자의 정책에 의해 결정될 수도 있고, 단말 제조사의 정책에 의해 결정될 수도 있으며, 혹은 "결정된 옵션"에 "오프라인 이동"이 포함되어 있을 경우 이 옵션이 가장 먼저 시도될 수도 있다.
"결정된 옵션"에 "온라인 이동" (혹은 온라인 이동의 두 가지 예인 "온라인 전송"이나 "리프로비저닝")이 허용되는 옵션으로 포함되어 있고, "온라인 이동"이 "결정된 옵션"에 포함된 옵션 중에서 가장 먼저 수행되어야 할 방법이라면 11010 단계가 수행될 수 있다. "결정된 옵션"에 포함된 옵션 중에서 "온라인 이동"이 가장 먼저 수행되어야 하는지의 여부는 다양한 방법에 의해 결정될 수 있다: 즉, 서비스 제공자의 정책에 의해 결정될 수도 있고, 단말 제조사의 정책에 의해 결정될 수도 있으며, 혹은 "결정된 옵션"에 "오프라인 이동"이 포함되어 있지 않고 "온라인 이동"이 포함되어 있을 경우 "온라인 이동"이 가장 먼저 수행되어야 하는 방법일 수 있다.
도 11을 참조하면, 11003 단계의 설명은 다음과 같다.
도 6에 도시된 6000 단계 내지 6020 단계가 수행될 수 있다.
도6에 도시된 6025 단계에서 "인증서 협상 과정"이 실패하고 "결정된 옵션"에 "온라인 이동"이 포함되어 있을 경우, 11010 단계가 수행될 수 있다. 이 과정에 대한 보다 상세한 설명은 도 6을 참조하기로 한다.
도 6에 도시된 6025 단계에서 "인증서 협상 과정"이 성공했을 경우 11005 단계가 수행될 수 있다.
도 11을 참조하면, 11005 단계의 설명은 다음과 같다.
도 6에 도시된 6030 단계 내지 6040 단계가 수행될 수 있다.
도6에 도시된 6045 단계에서 "적합성 검사"가 실패하고 "결정된 옵션"에 "온라인 이동"이 포함되어 있을 경우, 11010 단계가 수행될 수 있다. 이 과정에 대한 보다 상세한 설명은 도 6을 참조하기로 한다.
도 6에 도시된 6045 단계에서 "적합성 검사"가 성공한 경우 도 6에 제시된 나머지 과정이 수행될 수 있다. 이처럼 "두 단말이 사이에 번들 관리 서버를 두지 않은 채 연결을 맺고, 이 연결을 통해 하나의 단말에서 다른 단말로 번들이 이동하는 과정"은 "오프라인 이동" 혹은 "오프라인 전송(Offline Transfer)"이라 명명될 수 있다.
도 11을 참조하면, 11010 단계의 설명은 다음과 같다.
도 8에 도시된 과정이 수행될 수 있다.
도 9에 도시된 과정 중 9000 단계 내지 9020 단계가 수행될 수 있다.
도 9에 도시된 과정 중 9025 단계에서 번들 관리 서버는 "전송 옵션"을 생성할 수 있다. "전송 옵션"의 정의와 생성 과정에 대해서는 도 9의 설명을 참조한다.
"전송 옵션"에 제1 단말이 번들 관리 서버로 번들 및/또는 번들의 일부 데이터를 전송해야 할 필요가 있을 경우 9030 단계에서 요청 받은 데이터를 전송하고 9035 단계 내지 9040 단계가 수행될 수 있다. 다음으로 도 10의 과정이 수행될 수 있다. 이처럼 "두 단말과 번들 관리 서버가 각각 연결을 맺고, 하나의 단말에 설치된 번들 혹은 번들의 일부 데이터가 번들 관리 서버로 전송된 뒤 다른 단말로 전송되는 과정"은 "온라인 전송(Online Transfer)"이라 명명될 수 있다.
"전송 옵션"에 제1 단말이 번들 관리 서버로 번들 및/또는 번들의 일부 데이터를 전송해야 할 필요가 없을 경우 9030 단계에서 번들 및/또는 번들의 일부 데이터가 전송될 필요가 없으며 9035 단계 내지 9040 단계는 생략될 수 있다. 다음으로 도 10의 과정이 수행될 수 있다. 이처럼 "두 단말과 번들 관리 서버가 각각 연결을 맺되, 선택적으로 본래 번들이 설치되어 있던 단말의 번들은 삭제되고, 번들 관리 서버가 이동하려는 서비스와 연관된 번들을 생성해 다른 단말로 전송하는 과정"은 "리프로비저닝(Re-provisioning)"이라 명명될 수 있다.
도 12는 본 개시의 일부 실시 예에 따른 SSP가 탑재된 단말의 구성을 도시하는 도면이다.
도 12 에서 도시된 바와 같이, 단말은 송수신부(Transceiver)(1210) 및 적어도 하나의 프로세서(1220)를 포함할 수 있다. 또한, 단말은 SSP(1230)를 더 포함할 수 있다. 예를 들면, SSP(1230)는 단말에 삽입될 수 있고, 단말에 내장될 수도 있다. 상기 적어도 하나 이상의 프로세서(1220)는 '제어부'로 명명할 수도 있다. 다만, 단말의 구성은 도 12에 제한되지 않으며, 도 12에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일부 실시예에 따르면, 송수신부(1210), 적어도 하나의 프로세서(1220) 및 메모리(미도시)는 하나의 칩(Chip) 형태로 구현될 수 있다. 또한, SSP(1230)가 내장되는 경우, SSP(1230)를 포함하여, 하나의 칩 형태로 구현될 수 있다.
다양한 실시예에 따르면, 송수신부(1210)는 다른 단말의 송수신부 혹은 외부 서버와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(1210)는 송신되는 신호의 주파수를 상승 변환(up converting) 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환(down converting)하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(1210)의 일 실시예일뿐이며, 송수신부(1210)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(1210)는 무선 채널을 통해 신호를 수신하여 적어도 하나의 프로세서(1220)로 출력하고, 적어도 하나의 프로세서(1220)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.
한편, 적어도 하나의 프로세서(1220)는 단말을 전반적으로 제어하기 위한 구성요소이다. 적어도 하나의 프로세서(1220)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 단말의 전반적인 동작을 제어할 수 있다.
한편, SSP(1230)는 번들을 설치하고 제어하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다. 또한, 다양한 실시예에 따르면, SSP(1230)는 프로세서(1220)의 제어에 따라 동작할 수도 있다. 또는 SSP(1230)는 번들을 설치하고 제어하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다. 어플리케이션의 일부 또는 전부는 SSP(1230) 또는 메모리(미도시)에 설치되어 있을 수도 있다.
한편, 단말은 메모리(미도시)를 더 포함할 수 있으며, 단말의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(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) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
도 13은 본 개시의 일부 실시 예에 따른 번들 관리 서버의 구성을 도시하는 도면이다.
일부 실시 예에 따르면, 번들 관리 서버는 송수신부(Transceiver)(1510) 및 적어도 하나 이상의 프로세서(1320)를 포함할 수 있다. 다만, 번들 관리 서버의 구성은 도 13에 제한되지 않으며, 도 13에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다.
일부 실시예에 따르면, 송수신부(1310)는 단말과 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(1350)는 송신되는 신호의 주파수를 상승 변환 및 증폭하는 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) 중 적어도 하나의 저장매체를 포함할 수 있다.
도 14은 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연관된 서비스가 오프라인 혹은 온라인 이동되기 위해 두 단말 및 서버가 상호 동작하는 방법의 예를 도시하는 도면이다.
도 14에 도시된 바와 같이, 제1 단말(1400) 및 제2 단말(1420)에는 각각 제1 eSIM(1403) 및 제2 eSIM(1423)이 장착되어 있고, 제1 eSIM(1403) 및 제2 eSIM(1423)에는 각각 프로파일(미도시)이 설치되어 있을 수 있다. 또한 제1 단말(1400) 및 제2 단말(1420)에는 각각 제1 LPA(1401) 및 제2 LPA(1421)가 설치되어 있을 수 있다. 제1 eSIM(1403) 및 제2 eSIM(1423)은 각각 제1 LPA(1401) 및 제2 LPA(1421)의 제어를 받을 수 있다. 제1 사용자(1405) 및 제2 사용자(1425)는 각각 제1 LPA(1401) 및 제2 LPA(1421)를 통해 각 단말의 eSIM(제1 eSIM(1403) 및 제2 eSIM(1423))에 설치된 프로파일을 제어할 수 있다. 이때, 제1 사용자(1405)와 제2 사용자(1425)는 서로 같을 수 있다. 또한 제1 LPA(1401)와 제2 LPA(1421)은 서로 연결되어 통신할 수 있다. 이때 LPA 간의 가능한 연결 방법은 후술될 도면의 설명을 참조하기로 한다.
제1 단말(1400)의 제1 LPA(1401)는 제1 RSP 서버(1440)와 연결되어 있고, 제2 단말(1420)의 제2 LPA(1421)는 제2 RSP 서버(1480)와 연결되어 있을 수 있다. 이 때 제1 RSP 서버(1440)와 제2 RSP 서버(1480)는 서로 같을 수도 있다. 또한 도면에는 편의상 제1 RSP 서버(1440) 및 제2 RSP 서버(1480) 각각이 단일 서버로서 구성되는 경우를 도시하였지만, 구현 및 실시예에 따라, 하나 이상의 프로파일 제공서버(SM-DP+)가 서버 구성에 포함될 수 있고, 특정 프로파일 제공서버와 단말의 연결 생성을 보조하는 하나 이상의 개통중개서버(SM-DS)가 서버 구성에 포함될 수도 있다. 또한, 본 도면에 도시되지는 않았지만 제1 RSP 서버(1440)와 제2 RSP 서버(1480) 사이에는 하나 이상의 RSP 서버 및/또는 릴레이 서버가 연결되어 있을 수 있다.
또한, 도면에 도시되어 있지는 않지만, 각 RSP 서버 및/또는 릴레이 서버는 사업자 서버에 연결되어 있을 수 있다. 하나 이상의 사업자 서버가 구성에 포함되는 경우, 각 사업자 서버는 별도의 각 RSP 서버 및/또는 릴레이 서버와 연결되어 있을 수도 있고, 적어도 하나 이상의 사업자 서버가 동일한 RSP 서버 및/또는 릴레이 서버에 연결되어 있을 수도 있다.
이와 같이 다양한 서버의 구성을 이하 도면에는 간략하게 단일 RSP 서버로 표기할 수도 있다. 가령, 제1 단말(1400)과 제2 단말(1420) 사이에 하나 이상의 RSP 서버 및/또는 릴레이 서버가 연결되어 있고, 일부 혹은 전체 RSP 서버 및/또는 릴레이 서버가 사업자 서버와 연결되어 있을 경우, 제1 단말과 제2 단말 사이에 존재하는 다양한 서버의 구성을 단일 RSP 서버로 표현할 수 있으며, 이 단일 RSP 서버는 도면 및 실시예에서 SM-XX로 지칭될 수 있다.
도 15는 본 개시의 일 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 프로파일 혹은 프로파일과 연관된 서비스를 이동하기 위해 준비하는 절차를 도시하는 도면이다.
도 15를 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 제1 단말(1510)은 제1 LPA(1530)과 제1 eSIM(1520)을 포함하고, 제2 단말(1560)은 제2 LPA(1580)과 제2 eSIM(1570)을 포함할 수 있다.
하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연관된 서비스가 이동되는 방법은 크게 다음과 같이 분류될 수 있다.
- 오프라인 이동: 오프라인 방식을 통한 프로파일 혹은 프로파일과 연관된 서비스의 이동이란 두 단말이 사이에 RSP 서버를 두지 않은 채 연결을 맺고, 이 연결을 통해 하나의 단말에서 다른 단말로 프로파일이 이동하는 것을 의미할 수 있다. 프로파일의 이동을 통해 해당 프로파일과 연관된 서비스가 이동될 수 있다. 이때 가능한 연결의 방법은 도 17의 설명을 참조하기로 한다.
- 온라인 이동: 온라인 방식을 통한 프로파일 혹은 프로파일과 연관된 서비스의 이동이란 두 단말과 RSP 서버가 각각 연결을 맺고, RSP 서버의 도움을 받아 프로파일 혹은 프로파일과 연관된 서비스가 이동하는 것을 의미할 수 있다.
이때, 오프라인 이동은 다음과 같이 분류될 수 있다.
- 오프라인 이미지 전송: 오프라인 이동을 통해 하나의 단말에서 다른 단말로 프로파일 이미지가 전송되는 것을 의미할 수 있다.
- 오프라인 패키지 전송: 오프라인 이동을 통해 하나의 단말에서 다른 단말로 프로파일 패키지가 전송되는 것을 의미할 수 있다.
또한, 온라인 이동은 다음과 같이 분류될 수 있다.
- 온라인 이미지 전송: 온라인 이동을 통해 하나의 단말에서 다른 단말로 프로파일 이미지가 전송되는 것을 의미할 수 있다.
- 온라인 패키지 전송: 온라인 이동을 통해 하나의 단말에서 다른 단말로 프로파일 패키지가 전송되는 것을 의미할 수 있다.
- 리프로비저닝(Re-provisioning): 두 단말과 RSP 서버가 각각 연결을 맺되, 본래 프로파일이 설치되어 있던 단말의 프로파일은 선택적으로 삭제되고, RSP 서버가 이동하려는 서비스와 연관된 프로파일을 생성해 다른 단말로 전송하는 과정을 의미할 수 있다.
상기의 '오프라인 이미지 전송'과 '오프라인 패키지 전송'은 '오프라인 전송(Offline Transfer)'이라 지칭될 수 있으며, '오프라인 패키지 전송'은 '오프라인 이동'과 같은 의미로 사용될 수 있다.
상기의 '온라인 이미지 전송'과 '온라인 패키지 전송'은 '온라인 전송(Online Transfer)'이라 지칭될 수 있다.
상기의 내용을 정리하면 아래와 같은 방식의 분류가 가능할 수 있다.
- 오프라인 이동
-- 오프라인 전송 (Offline Transfer)
--- 오프라인 이미지 전송
--- 오프라인 패키지 전송
- 온라인 이동
-- 온라인 전송 (Online Transfer)
--- 온라인 이미지 전송
--- 온라인 패키지 전송
-- 리프로비저닝 (Re-provisioning)
다양한 실시예에 따르면, 제1 단말(1510)은 기 설치된 프로파일을 보유하고 있을 수 있으며, 기 설치된 프로파일과 연계된 메타데이터를 더 보유하고 있을 수 있다. 다양한 실시 예에 따르면, 제1 단말(1510)은 기 설치된 프로파일과 관련된 '프로파일 구분자'를 보유하고 있을 수 있다.
다양한 실시 예에 따르면, 제1 단말(1510)은 기 설치된 프로파일과 관련된 '프로파일 이동 설정'을 보유하고 있을 수 있다.
'프로파일 이동 설정'에는 다음의 정보를 포함하는 인자가 포함되어 있을 수 있다.
- 해당 프로파일 혹은 프로파일과 연관된 서비스가 하나의 단말에서 다른 단말로 옮겨질 수 있는지 여부
또한, '프로파일 이동 설정'에는 해당 프로파일 혹은 프로파일과 연관된 서비스가 하나의 단말에서 다른 단말로 옮겨질 수 있는 경우, 어떠한 방식을 통해 이동될 수 있는지를 나타내는 인자가 포함되어 있을 수 있다.
예컨대, '프로파일 이동 설정'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 이동
- 온라인 이동
또 다른 예로, '프로파일 이동 설정'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 전송
- 온라인 전송
- 리프로비저닝
또 다른 예로, '프로파일 이동 설정'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 이미지 전송
- 오프라인 패키지 전송
- 온라인 이미지 전송
- 온라인 패키지 전송
- 리프로비저닝
도 15를 참조하면, 15000 단계에서, 제1 LPA(1530)는 이동할 (서비스와 연관된) 프로파일의 정보를 획득할 수 있다. 또는, 이동할 (서비스와 연관된) 프로파일의 정보가 제1 LPA에 전달될 수 있다. 예를 들면, 제1 LPA는 이동할 (서비스와 연관된) 프로파일의 정보를 사용자가 제1 단말(1510)이 제공하는 UI를 통해 프로파일을 선택하는 사용자 입력을 수신함으로써 획득할 수도 있고, 원격 서버로부터 푸쉬(Push) 입력을 통해 이동할 (서비스와 연관된) 프로파일의 정보가 제1 LPA에게 입력될 수도 있으며, 또는 제1 LPA가 원격 서버에 접속하여 이동될 (서비스와 연관된) 프로파일의 정보를 읽어올 수도 있다. 다만, 제1 LPA가 이동할 (서비스와 연관된) 프로파일의 정보를 획득하는 방법이 이에 제한되는 것은 아니다.
도 15를 참조하면, 15005 단계에서 제1 LPA(1530)는 자신이 이동하려는 프로파일 혹은 프로파일과 연관된 서비스를, 어떤 방식을 통해 이동할 수 있는지를 나타내는 정보, "가능한 옵션(Available Option)"을 구성할 수 있다. 예컨대, "가능한 옵션(Available Option)"은 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함될 수 있다.
- 오프라인 이동
- 온라인 이동
또 다른 예로, '가능한 옵션(Available Option)'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 전송
- 온라인 전송
- 리프로비저닝
또 다른 예로, '가능한 옵션(Available Option)'에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 이미지 전송
- 오프라인 패키지 전송
- 온라인 이미지 전송
- 온라인 패키지 전송
- 리프로비저닝
이때 "가능한 옵션(Available Option)"을 구성하기 위해 다음의 정보 중 하나 이상이 사용될 수 있다.
- 이동할 (서비스와 연관된) 프로파일의 '프로파일 이동 설정'
- 제1 단말에 구현되어 있는 기능 (즉, 어떠한 방식의 이동을 단말 기능이 지원하는지)
- 제1 단말의 현재 가능한 연결 방법 (예를 들어, 현재 제1 단말이 온라인 연결을 통해 서버와 통신할 수 있는지의 여부)
즉, 제1 단말 (예를 들어, 제1 LPA(1530))은 '프로파일 이동 설정에서 허용된 이동 방식' 및/또는 '제1 단말에 구현되어 있어 지원이 가능한 이동 방식' 및/또는 '제1 단말의 현재 가능한 연결 방법을 통해 수행이 가능한 이동 방식'을 확인한 뒤, 이 정보들을 이용해 "가능한 옵션"을 구성할 수 있다.
도 15를 참조하면, 15010단계에서 제1 LPA(1530)는 '프로파일 전송 코드(Transfer Code)'를 생성할 수 있다. 프로파일 전송 코드에는 전송하고자 하는 프로파일의 '프로파일 구분자'가 포함되어 있을 수 있다. 또한, 프로파일 전송 코드에는 전송하고자 하는 프로파일과 관련된 RSP 서버의 주소가 포함되어 있을 수 있다. (향후, 제2 단말(1560)은 이 주소를 이용해 RSP 서버에 접속해 프로파일을 다운로드 받을 수 있다.) 또한, 프로파일 전송 코드에는 프로파일의 속성을 나타내는 기타 정보들(가령, 프로파일의 메타데이터 혹은 메타데이터의 일부)이 더 포함될 수 있다.
또한, 프로파일 전송 코드에는 제1 단말 (가령, 제1 eSIM)이 지원하는 암호화 알고리즘들의 정보(Supported Crypto Info)가 포함될 수 있다. 제1 단말이 지원하는 암호화 알고리즘들의 정보는 다음의 정보들을 하나 이상 선택적으로 포함할 수 있다; 제1 단말이 지원하는 타원 곡선 커브 리스트/ 제1 단말이 지원하는 키 합의 알고리즘 리스트/ 제1 단말이 지원하는 암호화 알고리즘 리스트.
또한, 프로파일 전송 코드에는 향후 제1 단말과 제2 단말이 연결을 맺어야 할 경우 이 연결을 맺기 위해 필요한 정보가 포함될 수 있다.
또한, 프로파일 전송 코드에는 "가능한 옵션(Available Option)"이 포함될 수 있다.
도 15를 참조하면, 15015 단계에서, 15010 단계에서 생성된 프로파일 전송 코드가 제1 LPA(1530) 로부터 제2 LPA(1580)으로 전송될 수 있다. 프로파일 전송 코드는 다양한 방법으로 전송될 수 있다.
예를 들어, 제1 LPA(1530)는 제2 LPA(1580)로 전송해야 할 정보를 제1 단말의 UI를 통해 제1 단말의 제1 사용자에게 제공할 수 있다. 제1 사용자는 제공받은 정보를 제2 단말의 제2 사용자에게 제공할 수 있다. 제2 사용자는 제공받은 정보를 제2 단말의 UI를 이용해 제2 LPA에 입력할 수 있다.
혹은, 제1 LPA(1530)는 제2 LPA(1580)로 전달해야 할 정보를 이미지(예를 들어, QR 코드)의 형태로 만들어 제1 단말의 화면에 표시하고, 제2 사용자는 제1 단말의 화면에 표시된 이미지를 제2 단말을 이용해 스캔(Scan)함으로써 제2 LPA에 정보가 전송될 수 있다.
혹은, 제1 LPA(1530)는 제1 LPA(1530)와 제2 LPA(1580) 사이에 연결을 수립하고 이 수립된 연결을 이용해 전달해야 할 정보를 전송할 수 있다. 이때, 제1 LPA(1530)과 제2 LPA(1580) 사이에 수립되는 연결은 직접적인 기기 간 연결(예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D 와 같은 무선 연결 및 케이블 연결과 같은 유선 연결)일 수도 있고 혹은 제1 LPA(1530)과 제2 LPA(1580) 사이에 원격 서버(가령, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.
도 15를 참조하면, 15020 단계에서, 제2 LPA(1580)는 자신이 수신하려는 프로파일 혹은 프로파일과 연관된 서비스를, 어떤 방식을 통해 수신할 수 있는지를 나타내는 정보, "결정된 옵션(Determined Option)"을 구성할 수 있다. 예컨대, "결정된 옵션(Determined Option)"은 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함될 수 있다.
- 오프라인 이동
- 온라인 이동
또 다른 예로, "결정된 옵션(Determined Option)"에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 전송
- 온라인 전송
- 리프로비저닝
또 다른 예로, "결정된 옵션(Determined Option)"에는 다음의 방식 중 어떠한 방법(들)이 허용되는지에 대한 정보가 포함되어 있을 수 있다.
- 오프라인 이미지 전송
- 오프라인 패키지 전송
- 온라인 이미지 전송
- 온라인 패키지 전송
- 리프로비저닝
이때 "결정된 옵션(Determined Option)"을 구성하기 위해 다음의 정보 중 하나 이상이 사용될 수 있다.
- 15015 단계에서 수신한 "가능한 옵션"
- 제2 단말에 구현되어 있는 기능 (즉, 어떠한 방식의 이동을 단말 기능이 지원하는지)
- 제2 단말의 현재 가능한 연결 방법 (예를 들어, 현재 제2 단말이 온라인 연결을 통해 서버와 통신할 수 있는지의 여부)
즉, 제2 단말 (예를 들어, 제2 LPA(1580))은 '수신한"가능한 옵션"에서 허용된 이동 방식' 및/또는 '제2 단말에 구현되어 있어 지원이 가능한 이동 방식' 및/또는 '제2 단말의 현재 가능한 연결 방법을 통해 수행이 가능한 이동 방식'을 확인한 후, 이 정보들을 이용해 "결정된 옵션(Determined Option)"을 구성할 수 있다.
도 16은 본 개시의 실시 예에 따른, 프로파일의 오프라인 이동 절차를 개념적으로 도시하는 도면이다.
다양한 실시 예에 따르면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 도 16의 예에서와 같이, 제1 단말(1610)은 제1 LBA(1630)과 제1 eSIM(1620)을 포함하고, 제2 단말(1660)은 제2 LPA(1680)과 제2 eSIM(1670)을 포함할 수 있다.
도 16에 도시된 절차는 도 15에 도시된 절차 이후에 수행될 수 있다.
도 16을 참조하면, 16005 단계에서 제1 단말(1610)과 제2 단말(1660) 사이(예를 들면, 제1 eSIM(1620)과 제2 eSIM(1670) 사이)에 상호 인증 과정이 수행될 수 있다. 상기 절차에 대한 보다 자세한 설명은 후술될 도 17을 참조하기로 한다.
도 16을 참조하면, 16010 단계에서 제1 단말(1610)으로부터 제2 단말(1660)로 프로파일이 전송되고, 전송된 프로파일이 제2 단말에 설치되는 절차가 수행될 수 있다. 상기 절차에 대한 보다 자세한 설명은 후술될 도 18 을 참조하기로 한다.
도 17은 본 개시의 실시 예에 따른 도 16에서 제시된 절차 중 제1 단말(1710)과 제2 단말(1760) 간 상호 인증이 수행되는 세부 절차를 도시하는 도면이다.
도 17을 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 제1 단말(1710)은 제1 LPA(1730)과 제1 eSIM(1720)을 포함하고, 제2 단말(1760)은 제2 LPA(1780)과 제2 eSIM(1770)을 포함할 수 있다.
도 17을 참조하면, 17000 단계에서 제1 LPA(1730)과 제2 LPA(1780) 사이에 연결이 수립(또는, 설정)될 수 있다. 제1 LPA(1730)과 제2 LPA(1780)의 연결은 직접적인 기기 간 연결일 수도 있고 (예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D와 같은 무선 연결이나 케이블을 통한 유선 연결) 혹은 제1 LPA(1730)과 제2 LPA(1780) 사이에 원격 서버(가령, 릴레이 서버)가 위치한 원거리 연결일 수도 있다.
도 17을 참조하면, 17005 단계에서 제2 LPA(1780)은 제2 eSIM(1770)에 Euicc2.Info1을 요청할 수 있다.
도 17을 참조하면, 17010 단계에서 제2 eSIM(1770)은 Euicc2.Info1를 형성할 수 있다. Euicc2.Info1은 다음의 정보들을 포함할 수 있다.
-
제1 eSIM이 제2 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들
-
제2 eSIM이 제1 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들
-
제2 단말이 지원하는 버전 정보들
또한, 제2 eSIM은 제2 LPA(1780)에게 Euicc2.Info1를 제공할 수 있다.
도 17을 참조하면, 17015 단계에서 제2 LPA(1780)은 제2 eSIM(1770)에게 Euicc2.Challenge를 요청할 수 있다.
도 17을 참조하면, 17020 단계에서 제2 eSIM(1770)은 Euicc2.Challenge를 생성할 수 있다. Euicc2.Challenge는 제2 eSIM(1770)이 생성한 임의의 난수일 수 있다. 제2 eSIM(1770)은 제2 LPA(1780)에게 Euicc2.Challenge를 제공할 수 있다.
도 17을 참조하면, 17025 단계에서 제2 LPA(1780)은 제1 LPA(1730)을 거쳐 제1 eSIM(1720)에게 Euicc2.Info1을 제공할 수 있다. 또한, 제2 LPA(1780)은 제1 LPA(1730)을 거쳐 제1 eSIM(1720)에게 Euicc2.Challenge를 제공할 수 있다.
또한, 제2 LPA(1780)은 제1 LPA(1730)을 거쳐 제1 eSIM(1720)에게 "결정된 옵션(Determined Option)"을 제공할 수 있다. 하지만, 제1 LPA(1730)가 (제2 LPA로부터 제공 받은) "결정된 옵션(Determined Option)"을 제1 eSIM(1720)에게 제공하는 것은 반드시 현 단계에서 이루어질 필요는 없다. 가령, 17045 단계의 일부로서 제1 LPA(1730)가 제1 eSIM(1720)에게 "결정된 옵션(Determined Option)"을 제공할 수도 있다.
또한, 제1 LPA(1730)는 제1 eSIM(1720)에게 전송하고자 하는 프로파일의 '프로파일 구분자'를 더 제공할 수 있다.
도 17을 참조하면, 17030 단계에서 다음의 과정이 수행될 수 있다.
제1 eSIM(1720)은 Euicc2.Info1에 포함된 '제2 eSIM이 제1 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들'을 이용하여 자신이 사용할 인증서 Euicc1.Certificate를 선택할 수 있다.
제1 eSIM(1720)은 Euicc2.Info1에 포함된 '제1 eSIM이 제2 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들'을 이용하여 제2 eSIM(1770)이 사용할 인증서를 선택할 수 있다. 이때 선택된 인증서 정보 혹은 선택된 인증서를 지칭할 수 있는 정보는 euiccCiPKIdToBeUsed라 지칭될 수 있다.
제1 eSIM(1720)은 Euicc2.Info1에 포함된 제2 단말이 지원하는 버전 정보들을 확인하여 그 중 자신이 지원하는 버전이 존재하는지 여부를 확인할 수 있다.
상기에 언급된 과정 중 적어도 하나가 실패했을 경우 (가령, '제2 eSIM이 제1 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들'을 확인하여 자신 (즉, 제1 eSIM)을 검증할 수 있는 인증서 정보가 그 속에 포함되어 있지 않거나, '제1 eSIM이 제2 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들'을 확인하여 자신 (즉, 제1 eSIM)이 다른 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보가 포함되어 있지 않은 경우) 두 단말 간 오프라인 이동은 중단될 수 있다. 이때, "결정된 옵션(Determined Option)"에 온라인 이동 (혹은 온라인 이동의 범주에 속하는 이동 방식 중 하나 이상)이 허용되어 있다면, 두 단말 간 온라인 이동이 시도될 수 있다. 이 과정은, 제1 단말이 제2 단말로 오프라인 이동이 실패했음을 알리고, 제1 단말과 제2 단말이 온라인 이동 과정을 개시함으로써 시작될 수 있다. 온라인 방식의 서비스 이동에 대한 설명은 도19 내지 도22의 설명을 참조하기로 한다.
제1 eSIM(1720)은 수신한 프로파일 구분자와 연관된 프로파일의 '프로파일 이동 설정'을 확인할 수 있다. 제1 eSIM(1720)은 해당 프로파일이 오프라인 이동될 수 있는지 여부를 검사할 수 있다.
제1 eSIM(1720)은 향후 제2 eSIM과의 통신을 지칭하기 위해 사용되는 세션 아이디 혹은 트랜잭션 아이디(Transaction ID)를 생성할 수 있다.
제1 eSIM(1720)은 Euicc1.Challenge를 생성할 수 있다. Euicc1.Challenge는 제1 eSIM(1720)이 생성한 임의의 난수일 수 있다.
제1 eSIM(1720)은 아래의 값들 중 전체 및/또는 일부에 전자 서명을 할 수 있다. 이때 전자 서명은 Euicc1.Certificate를 이용해 수행될 수 있다.
-
Transaction ID
-
Euicc1.Challenge
-
Euicc2.Challenge
도 17을 참조하면, 17035 단계에서 제1 eSIM(1720)은 제1 LPA(1730)을 거쳐 제2 LPA(1780)에게 다음의 데이터 전체 및/또는 일부를 전송할 수 있다.
-
Transaction ID 및/또는 Euicc1.Challenge 및/또는 Euicc2.Challenge 와 이들의 전자 서명 값
-
euiccCiPKIdToBeUsed
-
Euicc1.Certificate 와 이 인증서를 검증하기 위해 필요한 일련의 인증서 체인 정보들
상기의 제공되는 데이터는 Device1.Auth1이라 지칭될 수 있다.
도 17을 참조하면, 17040 단계에서 제2 LPA(1780)은 제2 eSIM(1770)에게 다음의 데이터 전체 및/또는 일부를 전송할 수 있다.
-
Device1.Auth1
-
제1 단말이 제2 단말로 전송하려는 프로파일의 프로파일 구분자
도 17을 참조하면, 17045 단계에서 다음의 과정이 수행될 수 있다.
제2 eSIM(1770)은 Euicc1.Certificate의 유효성을 검증할 수 있다.
제2 eSIM(1770)은 Device1.Auth1에 포함된 전자 서명 값을 검증할 수 있다.
제2 eSIM(1770)은 Device1.Auth1에 포함된 Euicc2.Challenege가 17020 단계에서 자신이 전송하였던 Euicc2.Challenge와 동일한 값인지 검사할 수 있다.
제2 eSIM(1770)은 euiccCiPKIdToBeUsed를 이용해 자신이 사용할 인증서 Euicc2.Certificate를 선택할 수 있다.
제2 eSIM(1770)은 아래의 값들 중 전체 및/또는 일부에 전자 서명을 할 수 있다. 이때 전자 서명은 Euicc2.Certificate를 이용해 수행될 수 있다.
-
Transaction ID
-
Euicc1.Challenge
-
Euicc2.Info2. 여기서 Euicc2.Info2는, '제1 단말이 제2 단말로 전송하는 프로파일'이 제2 단말에 설치되어 작동될 수 있는지 적합성 확인(eligibility check)을 하는데 이용될 수 있는 정보일 수 있다. 예컨대, Euicc2.Info2는 제2 eSIM의 하드웨어 및/또는 소프트웨어 정보를 포함할 수 있다.
-
제1 단말이 제2 단말로 전송하려는 프로파일의 프로파일 구분자
제2 eSIM(1770)은 제2 LPA(1780)와 제1 LPA(1730)을 거쳐 제1 eSIM(1720)에게 다음의 데이터 전체 및/또는 일부를 전송할 수 있다.
-
Transaction ID 및/또는 Euicc1.Challenge 및/또는 Euicc2.Info2 및/또는 '제1 단말이 제2 단말로 전송하려는 프로파일의 프로파일 구분자'와 이들의 전자 서명 값
-
Euicc2.Certificate 와 이 인증서를 검증하기 위해 필요한 일련의 인증서 체인 정보들
상기의 데이터는 Device2.Auth1이라 지칭될 수 있다.
제1 LPA(1730)는 제1 eSIM(1720)에게 "결정된 옵션(Determined Option)"을 더 전송할 수 있다.
도 18은 본 개시의 실시 예에 따른 도 16에서 제시된 절차 중, 제1 단말(1810)으로부터 제2 단말(1860)로 프로파일이 전송되고, 전송된 프로파일이 제2 단말에 설치되는 세부 절차를 도시하는 도면이다.
도 18을 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 제1 단말(1810)은 제1 LPA(1830)과 제1 eSIM(1820)을 포함하고, 제2 단말(1860)은 제2 LPA(1880)과 제2 eSIM(1870)을 포함할 수 있다.
도 18을 참조하면, 18000 단계에서 다음의 과정이 수행될 수 있다.
제1 eSIM(1820)은 Euicc2.Certificate의 유효성을 검증할 수 있다.
제1 eSIM(1820)은 Device2.Auth1에 포함된 전자 서명 값을 검증할 수 있다.
제1 eSIM(1820)은 Device2.Auth1에 포함된 Euicc1.Challenege가 자신이 전송하였던 Euicc1.Challenge와 동일한 값인지 검사할 수 있다.
제1 eSIM(1820)은 Device2.Auth1에 포함된 프로파일 구분자를 확인하여 자신이 전송하려는 프로파일을 특정 지을 수 있다. 혹은, Device2.Auth1에 포함된 프로파일 구분자가 17045 단계에서 수신한 프로파일 구분자와 일치하는지 여부를 검사할 수 있다.
제1 eSIM(1820)은 수신한 프로파일 구분자와 연관된 프로파일의 '프로파일 이동 설정'을 확인할 수 있다.
제1 eSIM(1820)은 해당 프로파일이 제2 단말 (예컨대, 제2 eSIM)에 정상적으로 설치되어 동작할 수 있는지 적합성 확인(eligibility check)을 할 수 있다. 이때, 적합성 확인을 위해 프로파일 구분자와 Euicc2.Info2가 사용될 수 있다.
제1 eSIM(1820)은 지금까지 수신한 데이터와 수행했던 검사의 결과 (예를 들어, 수신한 "결정된 옵션' 및/또는 "적합성 검사" 등)를 바탕으로 어떤 방식의 이동을 계속 진행할 것인지 결정할 수 있다. 예를 들어, 제1 eSIM(1820)은 "오프라인 이동"을 계속 진행할 것인지 결정할 수 있다. 또 다른 예로, 제1 eSIM(1820)은 "오프라인 이동"을 중단하고 "온라인 이동"으로 전환할 것인지 결정할 수 있다. 또 다른, 제1 eSIM(1820)은 프로파일 혹은 프로파일과 연관된 서비스의 이동 절차를 중단할 것인지 결정할 수 있다. 상술한 결정을 위해 서비스 제공자의 정책이 사용될 수 있다. 또는, 상술한 결정을 위해 단말 제조사의 정책이 사용될 수 있다. 상술한 결정을 위해 필요한 정보는 제1 eSIM(1820)에 기 설정 혹은 저장되어 있을 수 있다.
제1 eSIM(1820)은 상술한 결정의 결과를 이용해 transferOption을 생성할 수 있다. transferOption은 다음의 방법 중 어떠한 방식이 진행될 것인지에 대한 정보를 포함할 수 있다.
-
오프라인 이미지 전송
-
오프라인 패키지 전송
-
온라인 이동으로의 이동 방식 전환
-
서비스 이동 과정의 중지
도 18을 참조하면, 18005 단계에서 다음의 과정이 수행될 수 있다.
제1 eSIM(1820)은 아래의 값들 중 전체 및/또는 일부에 전자 서명을 할 수 있다. 이때 전자 서명은 Euicc1.Certificate를 이용해 수행될 수 있다.
-
Transaction ID
-
transferOption
제1 eSIM(1820)은 제1 LPA(1830)과 제2 LPA(1880)을 거쳐 제2 eSIM(1870)에게 Tranction ID 및/또는 transferOption과 이들의 전자 서명 값을 전송할 수 있다. 이때 전송되는 값은 Device1.Auth2라 지칭될 수 있다.
제1 단말(1810)은 수신한 transferOption을 확인하고 해당 방식의 진행에 대해 사용자 동의를 받을 수 있다.
도 18을 참조하면, 18010 단계에서 다음의 과정이 수행될 수 있다.
제2 eSIM(1870)은 Device1.Auth2에 포함된 전자 서명 값을 검증할 수 있다.
제2 eSIM(1870)은 transferOption을 확인하여 프로파일 혹은 프로파일과 연관된 서비스의 이동이 어떻게 진행될 것인지를 확인할 수 있다.
만일, transferOption에 따라 '온라인 이동'으로 전환이 이루어져야 한다면 제1 단말과 제 2 단말은 '오프라인 이동'을 종료하고 '온라인 이동' 방식을 개시할 수 있다. 이 과정은, 제1 단말과 제2 단말이 도 19내지 도 22에 도시된 과정을 개시함으로써 시작될 수 있다.
제2 eSIM(1870)은 제1 eSIM(1820)과 암호화 통신을 위해 사용될 세션 키 생성을 위해 필요한 자신의 암호화 키 쌍(예컨대, 공개키 otPK.EUICC2.KA와 이에 대응되는 비밀키 otSK.EUICC2.KA)을 생성할 수 있다.
제2 eSIM(1870)은 아래의 값들 중 전체 및/또는 일부에 전자 서명을 할 수 있다. 이때 전자 서명은 Euicc2.Certificate를 이용해 수행될 수 있다.
-
Transaction ID
-
otPK.EUICC2.KA
제2 eSIM(1870)은 제2 LPA(1880)과 제1 LPA(1830)을 거쳐 제1 eSIM(1820)에게 Transaction ID 및/또는 otPK.EUICC2.KA 와 이들의 전자 서명 값을 전송할 수 있다. 이때 전송되는 값은 Device2.Auth2라 지칭될 수 있다.
도 18을 참조하면, 18015 단계에서 다음의 과정이 수행될 수 있다.
제1 eSIM(1820)은 Device2.Auth2에 포함된 전자 서명 값을 검증할 수 있다.
제1 eSIM(1820)은 제2 eSIM(1870)과 암호화 통신을 위해 사용될 세션 키 생성을 위해 필요한 자신의 암호화 키 쌍(예컨대, 공개키 otPK.EUICC1.KA와 이에 대응되는 비밀키 otSK.EUICC1.KA)을 생성할 수 있다.
제1 eSIM(1820)은 자신이 생성한 otSK.EUICC1.KA 와 수신한 otPK.EUICC2.KA를 사용해 제2 단말(1860)과의 암호화 통신을 위한 세션 키를 생성할 수 있다.
제1 eSIM(1820)은 제2 단말(1860)로 전송할 프로파일 이미지 및/또는 프로파일 패키지를 준비할 수 있다. 이때 준비된 프로파일 이미지 또는 프로파일 패키지는 묶인 프로파일 패키지(Bound Profile Package) 또는 묶인 프로파일 이미지(Bound Profile Image)라 지칭될 수 있다. 또한, 묶인 프로파일 패키지와 묶인 프로파일 이미지는 Bound Profile이라 통칭될 수 있다.
이 준비 과정에서, '전송할 프로파일 이미지 및/또는 프로파일 패키지'의 전체 및/또는 일부는 앞서 생성한 세션 키에 의해 암호화될 수 있다. 또한, '전송할 프로파일 이미지 및/또는 프로파일 패키지'의 전체 및/또는 일부는 Euicc1.Certificate를 이용해 전자 서명될 수 있으며 이 값은 Bound Profile의 일부로 포함될 수 있다. 또한, otPK.EUICC1.KA가 Bound Profile의 일부로 포함될 수 있다.
제1 eSIM(1820)은 제1 LPA(1830)를 거쳐 제2 LPA(1880) 에게 Bound Profile을 전송할 수 있다. 이때 해당 프로파일과 연관된 메타데이터가 함께 전송될 수 있다. 이때 메타데이터는 Bound Profile의 일부로 포함되어 있을 수도 있고, Bound Profile과 별개의 데이터로 전송될 수도 있다.
제1 eSIM(1820)은 해당 프로파일을 삭제할 수 있다.
도 18을 참조하면, 18020 단계에서 다음의 과정이 수행될 수 있다.
제2 단말(1860)은 전송한 메타데이터를 확인할 수 있다.
제2 단말(1860)은 수신한 Bound Profile의 설치와 관련되어 사용자 동의를 받을 수 있다.
제2 단말(1860)은 수신한 Bound Profile을 제2 eSIM(1870)에 설치할 수 있다. 이 과정은 제2 LPA(1880)와 제2 eSIM(1870)의 협업에 의해 이루어질 수 있다. 이 과정에서 Bound Profile에 암호화된 데이터가 있다면, 제2 eSIM(1870)은 otSK.EUICC2.KA 와 otPK.EUICC1.KA를 사용해 세션 키를 생성한 뒤, 이 키를 이용해 데이터를 복호할 수 있다. 또한, Bound Profile에 전자 서명 값이 포함되어 있다면, 제2 eSIM(1870)은 Euicc1.Certificate를 이용해 전자 서명 값의 유효성을 검증할 수 있다.
도 19는 본 개시의 일 실시 예에 따른 하나의 단말에서 다른 하나의 단말로 프로파일 혹은 프로파일과 연관된 서비스가 온라인 이동되는 절차를 개념적으로 도시하는 도면이다.
도 19를 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 도 19에 도시된 것처럼, 제1 단말(1910)은 제1 LPA(1930)과 제1 eSIM(1920)을 포함하고, 제2 단말(1960)은 제2 LPA(1980)과 제2 eSIM(1970)을 포함할 수 있다. RSP 서버에 대한 설명은 도 14를 참조하기로 한다.
19000 단계에서, 제2 단말(1960)은 RSP 서버(1950)로 프로파일과 연관된 서비스의 이동 승인을 받을 수 있다. 해당 절차에 대한 보다 자세한 설명은 도 20의 상세 설명을 참조하기로 한다.
19005 단계에서, 제1 단말(1910)은 RSP 서버(1950) 의 요청에 따라 이동하고자 하는 (서비스와 연관된) 프로파일에 대해 일련의 작업을 수행할 수 있다. 예를 들어, 제1 단말(1910)은 자신이 보유한 프로파일을 RSP 서버(750)로 업로드할 수 있다. 또 다른 예로, 제1 단말(1910)은 자신이 보유한 프로파일을 삭제할 수 있다. 해당 절차에 대한 보다 자세한 설명은 도 21의 상세 설명을 참조하기로 한다.
19010 단계에서, 제2 단말(1960)은 RSP 서버(1950)로부터 프로파일을 다운로드 받아 설치할 수 있다. 해당 절차에 대한 보다 자세한 설명은 도 22의 상세 설명을 참조하기로 한다.
도 20은 본 개시의 실시 예에 따른 도 19에서 제시된 절차 중 제2 단말(2060)이 RSP 서버(2050)로부터 프로파일과 연관된 서비스의 이동 승인을 받는 절차를 도시하는 도면이다.
도 20을 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 제2 단말(2060)은 제2 LPA(2080)과 제2 eSIM(2070)을 포함할 수 있다. RSP 서버(2050)에 대한 설명은 도 14를 참조하기로 한다.
도 20을 참조하면, 20000 단계에서, 제2 단말(2060)과 RSP 서버(2050) 사이에 상호 인증이 수행될 수 있다. 이 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.
-
상호 인증 과정은 제2 단말과 RSP 서버가 통신하기 위하여 거쳐야 할 인증서 협상 과정을 포함할 수 있다. 예를 들어 제2 단말은 RSP 서버를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 RSP 서버가 제2 단말을 검증하기 위해 사용할 수 있는 인증서 정보들을 RSP 서버에게 전송할 수 있다. 이 정보를 수신한 RSP 서버는, 제2 단말이 RSP 서버를 검증하는데 이용하게 될 인증서 정보들 및/또는 RSP 서버가 제2 단말을 검증하기 위해 사용할 인증서 정보들을 선택할 수 있다. 이때, RSP 서버에 의해 선택된 인증서 정보들은 제2 단말로 전송될 수 있다. 이러한 과정을 거쳐 제2 단말과 RSP 서버는 서로가 서로를 인증할 수 있는 인증서 정보들을 획득할 수 있다. 이때, 인증서 정보란 인증서 및/또는 인증서에 포함된 정보 및/또는 인증서를 지칭할 수 있는 일련의 정보일 수 있다.
-
제2 단말은 자신이 생성한 임의의 난수(eUICC Challenge) 값을 RSP 서버에게 전송할 수 있다. RSP 서버는 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 제2 단말로 전송할 수 있다. 제2 단말은 수신한 서명 값을 검증함으로써 RSP 서버를 인증할 수 있다.
-
RSP 서버는 자신이 생성한 임의의 난수(server Challenge) 값을 제2 단말로 전송할 수 있다. 제2 단말은 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 RSP 서버에게 전송할 수 있다. RSP 서버는 수신한 서명 값을 검증함으로써 제2 단말을 인증할 수 있다.
-
RSP 서버와 제2 단말이 통신하는 동안 세션을 관리하기 위한 ID(Transaction ID)가 교환될 수 있다. 예를 들어, RSP 서버가 transaction ID를 생성한 뒤 이 값을 제2 단말로 전송할 수 있다. 이때, transaction ID의 신뢰성과 무결성을 확인하기 위해 RSP 서버의 전자 서명 값이 추가될 수 있다.
-
RSP 서버와 제2 단말은 본 개시에서 이동할 서비스와 연관된 프로파일의 프로파일 구분자를 교환할 수 있다. 예를 들어, 제2 단말은 자신이 수신하고자 하는 서비스와 연관된 프로파일의 프로파일의 구분자를 RSP 서버에게 전송할 수 있다. 이때, 프로파일 구분자는 신뢰성과 무결성을 보장하기 위해 제2 단말의 전자 서명 값과 함께 전송될 수 있다.
-
RSP 서버와 제2 단말은 서로의 ID를 교환할 수 있다. 예를 들어, RSP 서버는 제2 단말에게 자신의 OID(object identifier)를 제공할 수 있다. 또 다른 예로, 제2 단말은 RSP 서버에게 자신의 eUICC 식별자를 제공할 수 있다.
-
제2 단말은 RSP 서버에게 "결정된 옵션"을 전송할 수 있다.
도 20을 참조하면, 20005 단계에서 다음의 과정이 수행될 수 있다.
RSP 서버(2050)은 수신한 "결정된 옵션"을 확인할 수 있다. 특히 RSP 서버(2050)은 수신한 프로파일 구분자를 확인하여 해당 프로파일과 연관된 '프로파일 이동 설정'을 선택하고, "결정된 옵션"에 포함된 온라인 이동 방식들이 '프로파일 이동 설정'에서 허용된 온라인 이동 방식들인지 검사할 수 있다.
RSP 서버(2050)은 제2 단말이 이동 받기 원하는 서비스가 제2 단말에서 사용될 수 있는지를 확인하기 위해 '적합성 검사(Eligibility Check)'를 수행할 수 있다. 예를 들어, RSP 서버(2350)는 수신한 제2 단말의 eUICC 식별자와 수신한 프로파일 구분자를 이용하여 '적합성 검사'를 수행할 수 있다.
예를 들어, RSP 서버(2050)은 제1 단말에서 사용되던 프로파일의 이미지가 제2 단말에 설치되어 작동될 수 있는지의 여부를 검사할 수 있다. 또다른 예로, RSP 서버(2050)은 제1 단말이 저장하고 있던 프로파일 패키지가 제2 단말에 설치되어 작동될 수 있는지 여부를 검사할 수 있다. 또한, RSP 서버(2050)은 이동하고자 하는 서비스와 관련하여 제2 단말에 설치되어 작동할 수 있는 프로파일을 생성할 수 있는지 여부를 검사할 수 있다.
다시 말해, RSP 서버(2050)은 "결정된 옵션" 중에서 실제로 수행이 가능한 (즉, 수행의 결과로 제1 단말에서 사용하던 서비스가 제2 단말로 이동하는) 옵션(들)을 확인할 수 있다. RSP 서버(2050)은 이 가능한 옵션(들) 중 하나를 선택하여 전송 옵션(Transfer Option)을 생성할 수 있다.
가령, "전송 옵션"은 다음의 데이터들 중 적어도 하나 이상을 포함할 수 있다.
a)
RSP 서버(2050)을 지칭하는 정보 (가령, RSP 서버의 OID)
b)
제2 단말(2060)을 지칭하는 정보 (가령, 제2 eSIM의 eUICC 식별자)
c)
이동하고자 하는 서비스와 연관된 프로파일의 프로파일 구분자
d)
어떤 방식의 온라인 이동이 진행될 것인지를 지칭하는 정보
- 온라인 이미지 전송
- 온라인 패키지 전송
- 리프로비저닝
- 온라인 이동이 가능하지 않음
e)
"제1 단말과 제2 단말 사이의 종단 간 암호화"와 "제2 단말과 RSP 서버 사이의 암호화" 중 어느 것이 사용될 것인지를 지칭하는 정보
f)
트랜잭션 아이디
상술한 정보의 일부 및/또는 전체는 RSP 서버(2050)에 의해 전자 서명될 수 있고 이 전자 서명 값은 "전송 옵션"의 일부로 포함될 수 있다.
도 20을 참조하면, 20010 단계에서 RSP 서버(2050)은 제2 LPA(2080)에게 전송 옵션을 전송할 수 있다. 또한, RSP 서버(2050)은 제2 LPA(2080)에게 20005 단계의 전자 서명에 사용된 RSP 서버의 인증서 및 관련 정보들을 전송할 수 있다. 상기의 RSP 서버(2050)가 제2 LPA(2080)에게 전송하는 일련의 정보들은 Server.Auth2라 지칭될 수 있다.
도 20을 참조하면, 20015 단계에서 다음의 과정이 수행될 수 있다.
제2 LPA(2080)은 수신한 전송 옵션을 확인한 뒤 사용자의 동의를 받을 수 있다.
제2 LPA(2080)은 제2 eSIM(2070)에게 Server.Auth2를 전송할 수 있다.
제2 LPA(2080)은 제2 eSIM(2070)에게 'Supported Crypto Info'를 선택적으로 더 전송할 수 있다.
도 20을 참조하면, 20020 단계에서 다음의 과정이 수행될 수 있다.
제2 eSIM(2070)은 20015 단계에서 수신한 인증서 및 관련 정보의 유효성을 검증할 수 있다.
제2 eSIM(2070)은 20015 단계에서 수신한 전자 서명 값의 유효성을 검증할 수 있다.
제2 eSIM(2070)은 20015 단계에서 수신한 전송 옵션의 내용을 확인할 수 있다.
제2 eSIM(2070)은 'Supported Crypto Info'를 수신한 경우, 수신한 'Supported Crypto Info'의 내용을 확인하고 이 중 자신이 지원하는 암호화 알고리즘이 존재하는지의 여부를 확인할 수 있다. 수신한 supported Crypto Info 중 제2 eSIM이 지원하는 암호화 알고리즘들이 존재할 경우, 제2 eSIM(2070)은 이것들 중 하나를 택해 '선택된 암호화 알고리즘(Selected Crypto Info)'로 설정할 수 있다. '선택된 암호화 알고리즘'은 다음의 정보들을 하나 이상 선택적으로 포함할 수 있다: 타원 곡선 커브 정보, 키 합의 알고리즘 정보, 암호화 알고리즘 정보.
제2 eSIM(2070)은 암호화 통신 용 암호화 키를 만들기 위해 사용될 암호화 용 키 쌍(key pair)인 공개키 "otPK.EUICC.KA"와 비밀키 "otSK.EUICC.KA"를 생성할 수 있다. 이 때, 생성된 암호화 키는 'RSP 서버와 제2 단말 사이의 암호화 통신'을 위한 것일 수도 있고 '제1 단말과 제2 단말 사이의 암호화 통신'을 위한 것일 수도 있다. 이때, 생성된 암호화 키가 '제1 단말과 제2 단말 사이의 암호화 통신'을 위한 것이라면, 이 암호화 키(otPK.EUICC.KA 와 otSK.EUICC.KA)는 전술한 Selected Crypto Info에 포함된 암호화 알고리즘을 따르는 암호화 키일 수 있다.
제2 eSIM(2070)은 제2 LPA(2380)을 거쳐 RSP 서버(2050)에게 생성한 otPK.EUICC.KA를 전송할 수 있다. 이 암호화 키는 제2 eSIM에 의해 전자 서명될 수 있으며, 이 전자 서명 값 또한 RSP 서버로 전송될 수 있다. 상기의 암호화 키 및/또는 전자 서명 값은 Device2.Auth라 지칭될 수 있다.
제2 eSIM(2070)은 제2 LPA(2080)을 거쳐 RSP 서버(2050)에게 Selected Crypto Info를 더 전송할 수 있다.
도 21은 본 개시의 실시 예에 따른 도 19에서 제시된 절차 중 제1 단말(2110)이 RSP 서버(2150)의 요청에 따라 이동하고자 하는 서비스와 연관된 프로파일에 대해 일련의 작업을 수행하는 절차를 도시하는 도면이다.
도 21을 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 제1 단말(2110)은 제1 LPA(2130)과 제1 eSIM(2120)을 포함할 수 있다. RSP 서버(2150)에 대한 설명은 도 14를 참조하기로 한다.
도 21을 참조하면, 21000 단계에서, 제1 단말(2110)과 RSP 서버(2150) 사이에 상호 인증이 수행될 수 있다. 이 상호 인증 과정은 아래의 과정 중 하나 이상을 포함할 수 있다.
-
상호 인증 과정은 제1 단말(2110)과 RSP 서버(2150)가 통신하기 위하여 거쳐야 할 인증서 협상 과정을 포함할 수 있다. 예를 들어 제1 단말(2110)은 RSP 서버(2150)를 검증하는데 이용할 수 있는 인증서 정보들 및/또는 RSP 서버(2150)가 제1 단말(2110)을 검증하기 위해 사용할 수 있는 인증서 정보들을 RSP 서버(2150)에게 전송할 수 있다. 이 정보를 수신한 RSP 서버(2150)는, 제1 단말(2110)이 RSP 서버(2150)를 검증하는데 이용하게 될 인증서 정보들 및/또는 RSP 서버(2150)가 제1 단말(2110)을 검증하기 위해 사용할 인증서 정보들을 선택할 수 있다. 이때, RSP 서버(2150)에 의해 선택된 인증서 정보들은 제1 단말(2110)에게 전송될 수 있다. 이러한 과정을 거쳐 제1 단말(2110)과 RSP 서버(2150)는 서로가 서로를 인증할 수 있는 인증서 정보들을 획득할 수 있다. 이때, 인증서 정보란 인증서 및/또는 인증서에 포함된 정보 및/또는 인증서를 지칭할 수 있는 일련의 정보일 수 있다.
-
제1 단말(2110)은 자신이 생성한 임의의 난수(eUICC Challenge) 값을 RSP 서버(2150)에게 전송할 수 있다. RSP 서버(2150)는 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 제1 단말(2110)에게 전송할 수 있다. 제1 단말(2110)은 수신한 서명 값을 검증함으로써 RSP 서버(2150)를 인증할 수 있다.
-
RSP 서버(2150)는 자신이 생성한 임의의 난수(server Challenge) 값을 제1 단말(2110)에게 전송할 수 있다. 제1 단말(2110)은 수신한 난수 값에 전자 서명을 한 뒤 이 서명 값을 RSP 서버(2150)에게 전송할 수 있다. RSP 서버(2150)는 수신한 서명 값을 검증함으로써 제1 단말(2110)을 인증할 수 있다.
-
RSP 서버(2150)와 제1 단말(2110)이 통신하는 동안 세션을 관리하기 위한 ID(Transaction ID)가 교환될 수 있다. 예를 들어, RSP 서버(2150)가 transaction ID를 생성한 뒤 이 값을 제1 단말(2110)에게 전송할 수 있다. 이때, transaction ID의 신뢰성과 무결성을 확인하기 위해 RSP 서버의 전자 서명 값이 추가될 수 있다.
-
RSP 서버(2150)와 제1 단말(2110)은 본 개시에서 전송될 프로파일과 연관된 프로파일 구분자를 교환할 수 있다. 예를 들어, 제1 단말(2110)은 자신이 전송하고자 하는 프로파일의 구분자를 RSP 서버(2150)에게 전송할 수 있다. 이때, 프로파일 구분자는 신뢰성과 무결성을 보장하기 위해 제1 단말(2110)의 전자 서명 값과 함께 전송될 수 있다.
-
RSP 서버(2150)와 제1 단말(2110)은 서로의 ID를 교환할 수 있다. 예를 들어, RSP 서버(2150)는 제1 단말(2110)에게 자신의 OID(object identifier)를 제공할 수 있다. 또 다른 예로, 제1 단말(2110)은 RSP 서버(2150)에게 자신의 eUICC 식별자를 제공할 수 있다.
도 21을 참조하면, 21005 단계에서 다음의 과정이 수행될 수 있다.
RSP 서버(2150)는 다음의 과정 중 하나 이상을 수행할 수 있다.
a)
RSP 서버는 '제1 eSIM의 eUICC 식별자'와 '제1 단말이 전송한 프로파일의 프로파일 구분자'를 사용해 제1 단말(가령, 제1 eSIM)가 현재 해당 프로파일의 정당한 사용 주체임을 검사할 수 있다.
b)
RSP 서버는 '제1 단말이 전송한 프로파일 구분자에 대응되는 프로파일과 연관된 서비스'가 이미 다른 단말(가령, 도 20에 도시된 것과 같이 제2 단말)에 의해 이동이 요청되었는지를 검사할 수 있다. 가령, RSP 서버는 '제1 단말이 전송한 프로파일 구분자'가 도 20에서 요청되었던 서비스 이동과 연관된 프로파일 구분자인지 여부를 확인할 수 있다.
상술한 검사의 결과 '제1 단말이 전송한 프로파일 구분자와 연관된 프로파일의 정당한 사용 주체가 제1 단말'임이 확인되었고, 이 프로파일과 연관된 서비스가 다른 단말(가령, 도20에 도시된 것과 같이 제2 단말)에 의해 이동이 요청된 것이라면, RSP 서버는 20000 단계에서 수신한 "결정된 옵션(Determined Option)" 및/또는 20005 단계에서 수행한 "적합성 검사(Eligibility Check)"의 결과를 사용해, 제1 단말이 어떠한 동작을 수행해야 하는지를 결정해 "전송 옵션(Transfer Option)"을 생성할 수 있다. 예를 들어, 번들 관리 서버는, "결정된 옵션"에서 허용되었고 동시에 "적합성 검사" 결과 수행이 가능한, 이동 방식들 중 하나를 선택한 뒤 이것을 기반으로 "전송 옵션"을 구성할 수 있다. 가령, "전송 옵션"은 다음의 데이터들 중 적어도 하나 이상을 포함할 수 있다.
a)
RSP 서버(2150)을 지칭하는 정보 (가령, RSP 서버의 OID)
b)
제1 단말(2110)을 지칭하는 정보 (가령, 제1 eSIM의 eUICC 식별자)
c)
제2 단말(2060)을 지칭하는 정보 (가령, 제2 eSIM의 eUICC 식별자)
d)
이동하고자 하는 서비스와 연관된 프로파일의 프로파일 구분자
e)
제1 단말이 전송해야 하는 정보를 지칭하는 정보
- 제1 단말이 이동하고자 하는 서비스와 연관된 프로파일 이미지
- 제1 단말이 이동하고자 하는 서비스와 연관된 프로파일 패키지
f)
제1 단말이 이동하고자 하는 서비스와 연관된 프로파일을 삭제해야 하는지 여부
g)
"제1 단말과 제2 단말 사이의 종단 간 암호화"와 "제1 단말과 번들 관리 서버 사이의 암호화" 중 어떤 방식의 보안이 사용되어야 하는지를 지칭하는 정보
h)
트랜잭션 아이디
상술한 정보의 일부 및/또는 전체는 RSP 서버에 의해 전자 서명될 수 있고 이 전자 서명 값은 "전송 옵션"의 일부로 포함될 수 있다.
RSP 서버(2150)는 제1 eSIM(2120)과의 암호화 통신 용 암호화 키를 만들기 위해 사용될 암호화 용 키 쌍(key pair)인 공개키 "otPK.DP.KA"와 비밀키 "otSK.DP.KA"를 생성할 수 있다.
RSP 서버(2150)은 제1 LPA(2130)을 거쳐 제1 eSIM(2120)에게 전송 옵션(Transfer Option)을 전송할 수 있다. RSP 서버(2150)은 제1 LPA(2130)을 거쳐 제1 eSIM(2120)에게 공개키 otPK.XX.KA를 전송할 수 있다. 이때, otPK.XX.KA는 20020 단계에서 수신한 otPK.EUICC.KA일 수도 있고, otPK.DP.KA일 수도 있다.
이때, RSP 서버(2150)로부터 제1 eSIM(2120)에게 전송되는 otPK.XX.KA 및/또는 전송 옵션은 RSP 서버(2150)에 의해 전자 서명될 수 있다. 상기 전자 서명 값은 RSP 서버(2150)로부터 제1 LPA(2430)을 거쳐 제1 eSIM(2420)에게 전송될 수 있다. 또한, 상기 전자 서명을 검증하는 데 사용될 수 있는 RSP 서버의 인증서 및 관련 정보들이 RSP 서버(2150)로부터 제1 LPA(2130)을 거쳐 제1 eSIM(2120)에게 전송될 수 있다.
RSP 서버(2150)은 제1 LPA(2130)을 거쳐 제1 eSIM(2120)에게 20020 단계에서 수신한 Selected Crypto Info를 선택적으로 더 전송할 수 있다.
제1 단말(2110) (예를 들어, 제1 LPA(2430))은 수신한 전송 옵션과 관련하여 사용자 동의를 받을 수 있다. 즉, 수신한 전송 옵션을 기반으로 어떠한 방식의 이동이 이루어질 것인지에 대해 사용자에게 고지하고 동의를 받을 수 있다.
도 21을 참조하면, 21010 단계에서 다음의 과정이 수행될 수 있다.
제1 eSIM(2120)은 21005 단계에서 수신한 인증서 및 관련 정보의 유효성을 검증할 수 있다.
제1 eSIM(2120)은 21005 단계에서 수신한 전자 서명 값의 유효성을 검증할 수 있다.
제1 eSIM(2120)은 21005 단계에서 수신한 전송 옵션의 내용을 확인한 뒤 다음의 과정 중 적어도 하나를 수행할 수 있다.
제1 eSIM(2120)는 "전송 옵션"을 이용해 자신이 RSP 서버에게 프로파일 이미지 또는 프로파일 패키지를 전송해야 할 필요가 있는지를 확인할 수 있다.
만일 RSP 서버에게 프로파일 이미지 또는 프로파일 패키지를 전송해야 할 필요가 있을 경우, 제1 eSIM(2120)는 요청된 데이터를 준비할 수 있다. 상세 절차는 다음과 같다.
제1 eSIM(2120)는 Selected Crypto Info에 포함된 정보들을 확인할 수 있다.
제1 eSIM(2120)은 암호화 통신 용 암호화 키를 만들기 위해 사용될 암호화 용 키 쌍(key pair)인 공개키 "otPK.EUICC.KA"와 비밀키 "otSK.EUICC.KA"를 생성할 수 있다. 이 때, 생성된 암호화 키는 'RSP 서버와 제1 단말 사이의 암호화 통신'을 위한 것일 수도 있고 '제1 단말과 제2 단말 사이의 암호화 통신'을 위한 것일 수도 있다. 생성된 암호화 키가 어떤 암호화 통신을 위한 것인지는 21005 단계에서 수신한 otPK.XX.KA이 어떤 값이냐에 따라 결정될 수 있다. 또는, 생성된 암호화 키가 어떤 암호화 통신을 위한 것인지는 "전송 옵션"의 내용에 따를 수 있다. 제1 eSIM(2120)은 생성한 otPK.EUICC.KA의 전자 서명 값을 계산할 수 있다. 상술한 otPK.EUICC.KA 및/또는 전자 서명 값은 Device1.Auth라고 통칭될 수 있다.
제1 eSIM(2120)은 자신이 생성한 "otSK.EUICC.KA"와 21005 단계에서 수신한 otPK.XX.KA를 사용해 암호화 통신에 사용할 세선 키를 생성할 수 있다.
제1 eSIM(2120)은 (경우에 따라, 제1 LPA의 도움을 받아) 제2 단말로 전송할 프로파일을 준비할 수 있다. 이 때, 준비된 프로파일의 형태는 21005 단계에서 수신한 전송 옵션에 부합될 수 있다, 즉, 준비된 프로파일의 형태는 다음 중 하나일 수 있다.
-
프로파일 이미지
-
프로파일 패키지
상기의 준비된 프로파일의 전체 및/또는 일부는, 전술한 세션 키에 의해 암호화될 수 있다. 또한, 상기의 준비된 프로파일의 전체 및/또는 일부는, 제1 단말에 의해 전자 서명될 수 있으며, 이 전자 서명 값은 준비된 프로파일의 일부로 포함될 수 있다.
상술한 '준비된 프로파일 이미지' 혹은 '준비된 프로파일 패키지'는 '묶인 프로파일 재료(Bound Profile Material)'이라 지칭될 수 있다.
제1 eSIM(2120)는 "전송 옵션"을 이용해 RSP 서버가 해당 프로파일을 삭제하기 원하는지 여부를 확인할 수 있다. RSP 서버가 해당 프로파일의 삭제를 원할 경우 제1 eSIM은 해당 프로파일을 삭제할 수 있다.
제1 eSIM(2120)는 제1 LPA(2130)을 거쳐 RSP 서버(2150)로 "묶인 프로파일 재료(Bound Profile Material)"을 전송할 수 있다. 제1 eSIM(2120)는 제1 LPA(2130)을 거쳐 RSP 서버(2150)로 Device1.Auth를 더 전송할 수 있다.
도 21을 참조하면, 21015 단계에서 다음의 과정이 수행될 수 있다.
RSP 서버(2150)은 수신한 Device1.Auth의 유효성을 검증할 수 있다. 이 과정은 Device1.Auth에 대해 제1 eSIM이 계산한 전자 서명 값의 유효성을 검증함으로써 수행될 수 있다.
도 22는 본 개시의 일 실시 예에 따른 도 19에서 제시된 절차 중 제2 단말(2260)이 RSP 서버(2250)로부터 프로파일을 다운로드 받아 설치하는 절차를 도시하는 도면이다.
도 22를 참조하면, 단말은 적어도 하나의 LPA 및 적어도 하나의 eSIM을 포함할 수 있다. 예를 들면, 제2 단말(2260)은 제2 LPA(2280)과 제2 eSIM(2270)을 포함할 수 있다. RSP 서버(2250)에 대한 설명은 도 14를 참조하기로 한다.
도 22를 참조하면, 22000 단계에서 다음의 과정이 수행될 수 있다.
RSP 서버(2250)은 제2 단말(2260)로 전송할 프로파일을 준비할 수 있다. 이 준비 과정의 가능한 예는 다음과 같다.
[CASE F]
21010 단계에서, RSP 서버가 '제1 단말과 RSP 서버 사이의 암호화'가 된 '프로파일(프로파일 이미지 혹은 프로파일 패키지)'을 받았다면 복호화를 수행할 수 있다. 이때, 복호화는 21005 단계에서 생성했던 otSK.DP.KA와 21010 단계에서 수신한 제1 단말의 otPK.EUICC.KA를 이용해 만들어진 세션 키를 사용해 수행될 수 있다. 복호화된 프로파일은 제2 단말로서의 전송을 위해 '제2 단말과 RSP 서버 사이의 암호화' 과정을 거칠 수 있다. RSP 서버(2250)은 '제2 단말과 RSP 서버 사이의 암호화' 통신 용 암호화 키를 만들기 위해 사용될 키 쌍(key pair)인 공개키 "otPK.DP.KA"와 비밀키 "otSK.DP.KA"를 생성할 수 있다. RSP 서버(2250)은 생성한 otSK.DP.KA와 20020 단계에서 수신한 제2 단말의 otPK.EUICC.KA를 사용해 세션 키를 만들고 이 키를 사용해 프로파일을 암호화한 뒤 전송을 준비할 수 있다.
[CASE G]
21010 단계에서, RSP 서버가 '제1 단말과 제2 단말 사이의 암호화'가 된 '프로파일(프로파일 이미지 혹은 프로파일 패키지)'을 받았다면 이 프로파일을 제2 단말에 전송할 프로파일로 준비할 수 있다.
[CASE H]
21010 단계에서, RSP 서버가 제1 단말로부터 프로파일을 수신하지 않은 경우, RSP 서버는 제2 단말로 전송할 프로파일 (예를 들어, 프로파일 패키지)을 생성할 수 있다. RSP 서버(2250)은 '제2 단말과 RSP 서버 사이의 암호화' 통신 용 암호화 키를 만들기 위해 사용될 키 쌍(key pair)인 공개키 "otPK.DP.KA"와 비밀키 "otSK.DP.KA"를 생성할 수 있다. RSP 서버(2250)은 생성한 otSK.DP.KA와 20020 단계에서 수신한 제2 단말의 otPK.EUICC.KA를 사용해 세션 키를 만들고 이 키를 사용해 프로파일을 암호화한 뒤 전송을 준비할 수 있다.
상기, [CASE F] 내지 [CASE H] 에서 준비된 프로파일은 묶인 프로파일 재료(Bound Profile Material)라 지칭될 수 있다.
RSP 서버(2250)은 제2 LPA(2280)에게 '묶인 프로파일 재료'를 전송할 수 있다.
도 22를 참조하면, 22005 단계에서 다음의 과정이 수행될 수 있다.
제2 LPA(2280)은 수신한 '묶인 프로파일 재료'를 검증할 수 있다. 예를 들어, 제2 LPA(2280)는 '묶인 프로파일 재료'에 포함되어 있는 메타 데이터의 내용을 확인 및 검증할 수 있다. 또한, 제2 LPA(2580)는 '묶인 프로파일 재료'의 설치 여부에 대해 사용자 동의를 받을 수 있다.
제2 LPA(2280) 과 제2 eSIM(2270)은 제2 eSIM에 수신한 '묶인 프로파일 재료'를 설치할 수 있다.
도 22를 참조하면, 22010 단계에서 제2 eSIM(2270)은 제2 LPA(2280)을 거쳐 RSP 서버(2250)에게 프로파일이 설치되었음을 고지(notification)할 수 있다.
도 23은 하나의 단말에서 다른 단말로 프로파일 혹은 프로파일과 연결된 서비스가 오프라인 혹은 온라인 이동 방식을 통해 전달되는 전체 과정의 한 가지 예를 도시하는 도면이다.
도 23을 참조하면, 23001 단계의 설명은 다음과 같다.
도 15에 도시된 과정이 수행되고 15020 단계에서 제2 LPA는 "결정된 옵션(Determined Option)"을 생성할 수 있다.
"결정된 옵션"에 "오프라인 이동 (혹은 오프라인 이동에 속하는 이동 방식(들))"이 허용되는 옵션으로 포함되어 있고, 상기의 포함된 오프라인 이동 혹은 오프라인 이동에 속하는 이동 옵션 중 적어도 하나가 "결정된 옵션"에 포함된 옵션 중에서 가장 먼저 수행되어야 할 방법이라면 23003 단계가 수행될 수 있다.
"결정된 옵션"에 "온라인 이동" (혹은 온라인 이동에 속하는 이동 방식(들))이 허용되는 옵션으로 포함되어 있고, 상기의 포함된 온라인 이동 혹은 온라인 이동에 속하는 이동 옵션 중 적어도 하나가 "결정된 옵션"에 포함된 옵션 중에서 가장 먼저 수행되어야 할 방법이라면 23010 단계가 수행될 수 있다.
"결정된 옵션"에 포함된 옵션 중에서 어떠한 옵션이 먼저 수행되어야 하는지에 대한 우선순위는 다양한 방법에 의해 결정될 수 있다. 즉, 서비스 제공자의 정책에 의해 결정될 수도 있고, 단말 제조사의 정책에 의해 결정될 수도 있다.
"결정된 옵션"에 포함된 옵션 중에서 어떠한 옵션이 먼저 수행되어야 하는지에 대한 우선순위에 대한 정보는 단말에 저장되어 있을 수 있다.
도 23을 참조하면, 23003 단계의 설명은 다음과 같다.
도 17에 도시된 17000 단계 내지 17025 단계가 수행될 수 있다.
도 17에 도시된 17030 단계에서 "인증서 협상 과정"이 실패하고 (가령, '제2 eSIM이 제1 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들'을 확인하여 자신 (즉, 제1 eSIM)을 검증할 수 있는 인증서 정보가 그 속에 포함되어 있지 않거나, '제1 eSIM이 제2 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보들'을 확인하여 자신 (즉, 제1 eSIM)이 다른 eSIM을 검증하기 위해 사용할 수 있는 인증서 정보가 포함되어 있지 않은 경우), "결정된 옵션"에 "온라인 이동" (혹은 온라인 이동에 속하는 이동 방식(들))이 포함되어 있을 경우, 23010 단계가 수행될 수 있다. 이 과정에 대한 보다 상세한 설명은 도 17을 참조하기로 한다.
도 17에 도시된 17030 단계에서 "인증서 협상 과정"이 성공했을 경우 23005 단계가 수행될 수 있다.
도 23을 참조하면, 23005 단계의 설명은 다음과 같다.
도 17에 도시된 17035 단계 내지 17045 단계가 수행될 수 있다.
도 18에 도시된 18000 단계에서 "적합성 검사" 결과 오프라인 이동이 불가능하지만 "결정된 옵션"에 "온라인 이동" (혹은 온라인 이동에 속하는 이동 방식(들))이 포함되어 있을 경우, 23010 단계가 수행될 수 있다. 이 과정에 대한 보다 상세한 설명은 도 18을 참조하기로 한다.
도 18에 도시된 18000 단계에서 "적합성 검사" 결과 오프라인 이동이 가능할 경우 도 18에 제시된 나머지 과정이 수행될 수 있다. 이처럼 "두 단말이 사이에 RSP 서버를 두지 않은 채 연결을 맺고, 이 연결을 통해 하나의 단말에서 다른 단말로 프로파일(프로파일 패키지 혹은 프로파일 이미지)이 이동하는 과정"은 "오프라인 이동" 혹은 "오프라인 전송(Offline Transfer)"이라 명명될 수 있다.
도 23을 참조하면, 23010 단계의 설명은 다음과 같다.
도 20에 도시된 과정이 수행될 수 있다.
도 21에 도시된 과정 중 21000 단계가 수행될 수 있다.
도 21에 도시된 과정 중 21005 단계에서 RSP 서버는 "전송 옵션"을 생성할 수 있다. "전송 옵션"의 정의와 생성 과정에 대해서는 도 21의 설명을 참조한다.
"전송 옵션"에 제1 단말이 RSP 서버로 프로파일을 전송해야 할 필요가 있을 경우, 21010 단계에서 요청된 데이터가 제1 단말로부터 RSP 서버로 전송된다. 다음으로 도 22의 과정은 RSP 서버가 수신한 프로파일을 제2 단말로 전송함으로써 수행될 수 있다. 이처럼 "두 단말과 RSP 서버가 각각 연결을 맺고, RSP 서버의 도움을 받아 하나의 단말에서 다른 단말로 프로파일(프로파일 패키지 혹은 프로파일 이미지)이 이동되는 과정"은 "온라인 전송(Online Transfer)"이라 명명될 수 있다.
"전송 옵션"에 제1 단말이 RSP 서버로 프로파일을 전송해야 할 필요가 없을 경우 21010 단계에서 프로파일과 관련된 데이터가 전송될 필요가 없다. 다음으로 도 22의 과정은 RSP 서버가 프로파일을 생성해 제2 단말로 전송함으로써 수행될 수 있다. 이처럼 "두 단말과 RSP 서버가 각각 연결을 맺되, 본래 프로파일이 설치되어 있던 단말의 프로파일은 선택적으로 삭제되고, RSP 서버가 이동하려는 서비스와 연관된 프로파일을 생성해 다른 단말로 전송하는 과정"은 "리프로비저닝(Re-provisioning)"이라 명명될 수 있다.
도 24는 본 개시의 일부 실시 예에 따른 eUICC가 탑재된 단말의 구성을 도시하는 도면이다.
도 24를 참조하면, 단말은 송수신부(2410), 프로세서(2420) 및 eUICC(2430)를 포함할 수 있다. 본 개시에서 상술한 일부 단말들은 도 24에서 설명하는 단말에 대응될 수 있다. 다만, 단말의 구성은 도 24에 제한되지 않으며, 도 24에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일부 실시예에 따르면, 송수신부(2410), 프로세서(2420) 및 eUICC(2430)는 하나의 칩(Chip) 형태로 구현될 수 있다. 또한, 단말은 메모리를 추가로 포함할 수 있고, 프로세서(2420)는 적어도 하나의 프로세서로서 구성될 수 있다.
다양한 실시예에 따르면, 송수신부(2410)는 다른 단말의 송수신부 혹은 외부 서버와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(2410)는 송신되는 신호의 주파수를 상승 변환(up converting) 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환(down converting)하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(2410)의 일 실시예일뿐이며, 송수신부(2410)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(2410)는 무선 채널을 통해 신호를 수신하여 프로세서(2420)로 출력하고, 프로세서(2420)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.
한편, 프로세서(2420)는 단말을 전반적으로 제어하기 위한 구성요소이다. 프로세서(2420)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 단말의 전반적인 동작을 제어할 수 있다.
한편, 단말은 메모리(미도시)를 더 포함할 수 있으며, 단말의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(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) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(2420)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
도 25는 본 개시의 일부 실시 예에 따른 RSP 서버의 구성을 도시하는 도면이다.
도 25를 참조하면, 서버는 송수신부(2510) 및 프로세서(2520)를 포함할 수 있다. 본 개시에서 상술한 일부 서버(들)은 도 25에서 설명하는 서버에 대응될 수 있다. 다만, 서버의 구성은 도 25에 제한되지 않으며, 도 25에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일부 실시예에 따르면, 송수신부(2510) 및 프로세서(2520)는 하나의 칩(Chip) 형태로 구현될 수 있다. 또한, 서버는 메모리를 추가로 포함할 수 있고, 프로세서(2520)는 적어도 하나의 프로세서로서 구성될 수 있다.
일부 실시예에 따르면, 송수신부(2510)는 단말과 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(2510)는 송신되는 신호의 주파수를 상승 변환 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(2510)의 일 실시 예일 뿐이며, 송수신부(2510)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(2510)는 무선 채널을 통해 신호를 수신하여 프로세서(2520)로 출력하고, 프로세서(2520)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.
한편, 적어도 하나 이상의 프로세서(2520)는 서버를 전반적으로 제어하기 위한 구성요소이다. 프로세서(2520)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 서버의 전반적인 동작을 제어할 수 있다. 상기 적어도 하나 이상의 프로세서(2520)는 제어부로 명명할 수 있다.
한편, 서버는 메모리(미도시)를 더 포함할 수 있으며, 서버의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(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) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(2520)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
상술한 본 개시의 구체적인 실시 예들에서, 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.
본 개시의 다양한 실시 예들 및 이에 사용된 용어들은 본 개시에 기재된 기술을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 및/또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 본 개시에서, "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 제어 신호를 수신하는 단계;
상기 수신된 제1 제어 신호를 처리하는 단계; 및
상기 처리에 기반하여 생성된 제2 제어 신호를 상기 관리 서버로 전송하는 단계를 포함하는 것을 특징으로 하는 제어 신호 처리 방법.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020200097436A KR20220017212A (ko) | 2020-08-04 | 2020-08-04 | 기기 간 번들 또는 프로파일 이동 시 연계 방법 및 장치 |
| US17/444,359 US11950320B2 (en) | 2020-08-04 | 2021-08-03 | Apparatus and methods for linkage of or profile transfer between devices |
| PCT/KR2021/010163 WO2022030960A1 (en) | 2020-08-04 | 2021-08-03 | Apparatus and methods for linkage of or profile transfer between devices |
| CN202180057105.9A CN116097636A (zh) | 2020-08-04 | 2021-08-03 | 用于设备之间的链接或配置文件传输的装置和方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020200097436A KR20220017212A (ko) | 2020-08-04 | 2020-08-04 | 기기 간 번들 또는 프로파일 이동 시 연계 방법 및 장치 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20220017212A true KR20220017212A (ko) | 2022-02-11 |
Family
ID=80114434
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020200097436A KR20220017212A (ko) | 2020-08-04 | 2020-08-04 | 기기 간 번들 또는 프로파일 이동 시 연계 방법 및 장치 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US11950320B2 (ko) |
| KR (1) | KR20220017212A (ko) |
| CN (1) | CN116097636A (ko) |
| WO (1) | WO2022030960A1 (ko) |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102227262B1 (ko) * | 2015-02-17 | 2021-03-15 | 삼성전자주식회사 | 프로파일을 전달하는 방법과 이를 지원하는 전자 장치 |
| WO2018076711A1 (zh) * | 2016-10-31 | 2018-05-03 | 华为技术有限公司 | 一种简档下载方法及设备 |
| US10396987B2 (en) | 2017-01-26 | 2019-08-27 | Wickr Inc. | Securely provisioning an application with user information |
| KR102293683B1 (ko) * | 2017-02-13 | 2021-08-26 | 삼성전자 주식회사 | eSIM 접근 제어 방법 및 장치 |
| KR102458790B1 (ko) * | 2017-09-07 | 2022-10-25 | 삼성전자 주식회사 | 무선 통신 시스템에서 디바이스들의 프로파일 이동을 지원하는 방법 및 장치 |
| KR102657876B1 (ko) * | 2018-09-07 | 2024-04-17 | 삼성전자주식회사 | Ssp 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치 |
| US11290268B2 (en) * | 2018-09-13 | 2022-03-29 | Apple Inc. | Mode switching with multiple security certificates in a wireless device |
| KR102536948B1 (ko) | 2018-10-29 | 2023-05-25 | 삼성전자주식회사 | Ssp의 번들을 관리하는 방법 및 장치 |
| WO2020145623A1 (en) * | 2019-01-08 | 2020-07-16 | Samsung Electronics Co., Ltd. | Apparatus and method for handling esim profile for issp device |
| KR20200101257A (ko) | 2019-02-19 | 2020-08-27 | 삼성전자주식회사 | 이동 통신 시스템의 기기변경 방법 및 장치 |
| US11363449B2 (en) * | 2019-07-12 | 2022-06-14 | Apple Inc. | Cellular wireless service preferences transfer |
| US11516650B2 (en) * | 2019-09-09 | 2022-11-29 | Apple Inc. | Methods and apparatus for efficient transfer of multiple cellular service credentials |
| US11533607B2 (en) * | 2020-06-19 | 2022-12-20 | Apple Inc. | Cloud-based cellular service management for mobile wireless devices |
-
2020
- 2020-08-04 KR KR1020200097436A patent/KR20220017212A/ko unknown
-
2021
- 2021-08-03 US US17/444,359 patent/US11950320B2/en active Active
- 2021-08-03 CN CN202180057105.9A patent/CN116097636A/zh active Pending
- 2021-08-03 WO PCT/KR2021/010163 patent/WO2022030960A1/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| US20220046409A1 (en) | 2022-02-10 |
| US11950320B2 (en) | 2024-04-02 |
| WO2022030960A1 (en) | 2022-02-10 |
| CN116097636A (zh) | 2023-05-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102536948B1 (ko) | Ssp의 번들을 관리하는 방법 및 장치 | |
| KR102657876B1 (ko) | Ssp 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치 | |
| KR102546972B1 (ko) | 프로파일 원격관리 예외 처리 방법 및 장치 | |
| US20240015508A1 (en) | Method and device for remote management and verification of remote management authority | |
| US20230379685A1 (en) | Apparatus and method for managing events in communication system | |
| US20220174495A1 (en) | Method and device for changing euicc terminal | |
| US11950320B2 (en) | Apparatus and methods for linkage of or profile transfer between devices | |
| EP4017047A1 (en) | Method and device for setting state of bundle after transfer of bundle between apparatuses | |
| US20220278985A1 (en) | Method and device for transferring bundle between devices | |
| KR20210116169A (ko) | 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치 | |
| KR102180481B1 (ko) | 번들 정보를 제공하는 방법 및 장치 | |
| US20220377081A1 (en) | Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer | |
| KR102637120B1 (ko) | eUICC 프로파일 설치 권한을 관리하는 방법 및 장치 | |
| KR20210034475A (ko) | 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치 | |
| KR20210020770A (ko) | 기기 간 번들 이동 방법 및 장치 | |
| KR20210110145A (ko) | 원격 관리 및 원격 관리 권한 검증 방법 및 장치 | |
| KR20220039417A (ko) | 기기 변경 시 서로 다른 버전의 프로파일 이동을 위한 방법 및 장치 | |
| KR20210020725A (ko) | 기기 간 번들 이동 방법 및 장치 | |
| KR20220027002A (ko) | 기기 변경 실패 시 프로파일 복구 방법 및 장치 | |
| KR20210034522A (ko) | 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 | |
| KR20220153456A (ko) | eUICC 단말을 변경시 프로파일 삭제를 확인하는 방법 및 장치 | |
| KR20200130044A (ko) | 인증서 관리 및 검증 방법 및 장치 | |
| KR20220142318A (ko) | 무선 통신 시스템에서 이벤트를 관리하기 위한 방법 및 장치 | |
| CN115280815A (zh) | 在设备之间在线移动捆绑包或配置文件的方法和设备 |