KR101314605B1 - Iptv 환경에서 소프트웨어 업그레이드 방법 및 장치 - Google Patents

Iptv 환경에서 소프트웨어 업그레이드 방법 및 장치 Download PDF

Info

Publication number
KR101314605B1
KR101314605B1 KR1020060127692A KR20060127692A KR101314605B1 KR 101314605 B1 KR101314605 B1 KR 101314605B1 KR 1020060127692 A KR1020060127692 A KR 1020060127692A KR 20060127692 A KR20060127692 A KR 20060127692A KR 101314605 B1 KR101314605 B1 KR 101314605B1
Authority
KR
South Korea
Prior art keywords
information
software
network
iptv
broadcast receiver
Prior art date
Application number
KR1020060127692A
Other languages
English (en)
Other versions
KR20080047227A (ko
Inventor
김경호
김봉석
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of KR20080047227A publication Critical patent/KR20080047227A/ko
Application granted granted Critical
Publication of KR101314605B1 publication Critical patent/KR101314605B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1433Saving, restoring, recovering or retrying at system level during software upgrading
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof

Abstract

본 발명은 IPTV 환경에서 소프트웨어 업그레이드 방법, 장치에 관한 것으로, 서비스 제공업자는 네트워크로 연결된 적어도 하나 이상의 IPTV 방송 수신기의 소프트웨어 상태를 파악한 후 상기 네트워크를 관리할 수 있는 프로토콜을 이용하여 업그레이드하고, 각 IPTV 방송 수신기는 상기 서비스 제공업자로 자신이 관리하는 객체들 중 어느 하나에 중요한 이벤트나 응급상황이 발생하였음을 나타내는 정보를 상기 네트워크를 관리할 수 있는 프로토콜을 이용하여 전송할 수 있다. 따라서, 서비스 제공업자는 네트워크로 연결된 IPTV 방송 수신기로 소프트웨어를 업그레이드하여 설치할 수 있으며, IPTV 방송 수신기는 네트워크로 연결된 서비스 제공업자로 자신이 관리하는 객체들 중에서 중요한 이벤트나 응급 상황이 발생한 경우에 그에 대한 정보를 제공할 수 있으며, 업그레이드한 소프트웨어가 제대로 기능을 수행하지 않는 경우 기존의 소프트웨어를 이용하여 작동하도록 함으로써 업그레이드한 소프트웨어의 버그에 따른 문제를 최소화할 수 있으며, A/S(after service)등의 경우에 각 가정을 방문하지 않아도 원격지에서 문제를 파악하여 처리하여 비용 및 고객의 불만을 최소화할 수 있는 효과가 있다.
IPTV, SNMP, 프로그램 제공업자, 서비스 제공업자, 커스터머

Description

IPTV 환경에서 소프트웨어 업그레이드 방법 및 장치 {Method and apparatus for upgrading software in IPTV environment}
도 1은 본 발명과 관련하여 IPTV 환경을 개념적으로 도시한 것
도 2는 본 발명과 관련하여 SNMP 매니저와 SNMP 에이전트의 기능을 설명하기 위해 도시한 것
도 3a는 본 발명에 따라 구성한 호스트 소프트웨어 인포메이션 테이블(host software information table)의 일 예를 도시한 것
도 3b는 본 발명에 따라 구성한 호스트 소프트웨어 콘트롤 테이블(host software control table)의 일 예를 도시한 것
도 3c는 본 발명에 따라 구성한 호스트 소프트웨어 로그 테이블(host software log table)의 일 예를 도시한 것
도 3d는 본 발명에 따라 구성한 호스트 소프트웨어 트랩 테이블(host software traps table)의 일 예를 도시한 것
도 3e는 본 발명에 따라 구성한 호스트 소프트웨어 그룹 디바이스 테이블의 일 예를 도시한 것
도 4는 본 발명에 따라 IPTV 환경에서 소프트웨어 업그레이드를 위하여 구성한 시스템의 일 예를 도시한 것
도 5는 본 발명에 따라 구성한 IPTV 방송 수신기 블록도의 일 예를 도시한 것
도 6은 본 발명에 따라 IPTV 환경에서 원격에서 IPTV 방송 수신기의 소프트웨어를 업그레이드하는 방법의 일 예를 도시한 순서도
도 7은 본 발명에 따라 IPTV 환경에서 원격에서 에러 관리하는 방법의 일 예를 도시한 순서도
*도면의 주요 부분에 대한 부호의 설명
501; 네트워크 인터페이스 502; IP 매니저
503; CAS/DRM부 504; 서비스 전달 매니저
505; 역다중화부 506; 오디오/비디오 디코더
507; 디스플레이부 508; 애플리케이션 제어부
509; 채널 매니저 510; 서비스 정보 디코더
511; 서비스 디스커버리 매니저 512; 서비스 제어 매니저
513; 시스템 매니저 514; 저장부
본 발명은 IPTV 환경에서 소프트웨어를 업그레이드하는 방법 및 장치에 관한 것이다.
기존의 방송 환경에서는 방송국 등 송신단에서 제작한 콘텐츠를 지상파, 케 이블 또는 위성 등의 매체를 통하여 전송하고, 수신단에서는 상기 각 매체를 통해 수신하는 콘텐츠를 시청하는 단일 방향의 방송 환경이었다.
그러나 디지털 방송이 구축되면서 기존의 아날로그 방송에 비해 훨씬 많고 다양한 서비스의 제공과 양방향 서비스에 대한 요구가 대두하고 있다.
이에 따라 양방향 서비스를 구현하기 위한 여러 방안이 모색되고 있으며, 이러한 방안의 하나로 최근 대두되고 있는 IPTV 환경이 있다.
즉, 이미 개발되고 상용화가 이루어지고 있는 디지털 텔레비전에서 기존의 지상파, 케이블 및 위성이 아닌 IP 네트워크 환경을 이용하여 다양하고 많은 양의 서비스를 실시간으로 전송할 수 있으며, 양방향 서비스를 제공할 수 있다.
상술한 것과 같이, IP 네트워크 환경에서 방송을 수신할 수 있는 기기가 IPTV(Internet Protocol TV)이다. 상기 IPTV는 기 구축되어 있는 인프라 또는 네트워크상에서 초고속 인터넷을 이용하여 송신단에서 제공하는 멀티미디어 데이터를 포함한 다양한 서비스를 수신하여 사용자에게 제공하며, 사용자의 요청이나 요구 사항 등을 송신단으로 전송할 수 있는 수신장치를 통칭할 수 있을 것이다.
상기 IPTV 환경에서 수신기는 사용자의 다양한 요구에 따라 많은 기능들을 제공하고 있으며, 사용자에게 제공되는 많은 기능들은 하드웨어보다는 소프트웨어를 통해 구현된다. 따라서, 많은 기능들을 제공하기 위하여 방송 수신기의 소프트웨어는 복잡해지고, 그에 따라 소프트웨어의 에러 가능성이 증가할 수 있다.
한편, 방송 수신기는 기 설치된 소프트웨어에 오류가 발생하거나 새로운 버전의 소프트웨어가 제공되는 경우 등에 상기 기 설치된 소프트웨어를 업그레이드해 야 한다.
이러한 경우에 각각 서로 다른 방송 수신기에 설치된 소프트웨어를 업그레이드하기 위해서는 사용자, 방송 수신기 및 소프트웨어 매니저가 각각 방송 수신기에 소프트웨어를 설치해야 하는 불편함 문제점이 있었다.
즉, 현재 IPTV 환경에서 상기와 같은 문제점이 대두하고 있으나 그에 대한 방법이 아직 강구되지 않은바, 본 발명에서는 IPTV 환경에서 소프트웨어를 업그레이드하는 방법, 장치 및 시스템을 제안하고자 한다. 또한, 이와 함께 IPTV 환경에서는 양방향 서비스가 가능한바, 각 IPTV 방송 수신기의 문제점 등에 대해 원격에서 관리할 수 있는 방법에 대해서도 제안하고자 한다.
이에 따라 상기와 같은 제안을 위해, 본 발명에서는 IPTV(internet protocol television) 환경에서 소프트웨어 업그레이드 방법, 장치 및 시스템을 제공하고자 한다.
또한, 본 발명에서는 원격에서 각 IPTV 방송 수신기를 관리하고 제어할 수 있는 방법, 장치 및 시스템을 제공하고자 한다.
따라서, 상기 목적을 달성하기 위하여, 본 발명에 따라 네트워크로 연결된 적어도 하나 이상의 IPTV 방송 수신기에 구비된 소프트웨어에 대한 정보를 상기 네트워크를 관리하는 프로토콜을 이용하여 업그레이드하는 방법의 일 예는, 상기 소프트웨어에 대한 정보를 요청하는 단계; 상기 요청에 따라 수집한 정보를 수신하는 단계 및 업그레이드할 소프트웨어에 대한 정보와 소프트웨어를 전송하여 설치하는 단계를 포함함을 특징으로 한다.
이때, 상기 수집한 정보를 수신하여 소프트웨어의 업그레이드 여부를 판단하는 단계를 더 포함할 수 있다.
그리고 상기 판단 결과 업그레이드하여야 한다고 판단하면, 소프트웨어 업그레이드 여부를 문의하는 단계를 더 포함할 수 있다.
또한, 상기 문의 결과 사용자가 업그레이드를 거부한 경우에는 상기 업그레이드와 관련한 모든 동작은 종료할 수 있다.
그리고 상기 수신하는 수집 정보는 상기 소프트웨어 인포메이션에 대한 정보, 소프트웨어 제어에 대한 정보, 소프트웨어 로그에 대한 정보와 소프트웨어 그룹에 대한 정보 중 적어도 하나 이상을 포함할 수 있다.
또한, 상기 소프트웨어 인포메이션에 대한 정보는 부팅 성공 횟수, 제조 회사 이름, 모델 이름, 해당 모델의 시리얼 넘버, 하드웨어 버전, 저장장치의 인덱스, 상기 저장장치의 크기, 해당 소프트웨어 크기, 소프트웨어 이미지의 버전, 상기 소프트웨어 이미지의 생산 날짜 및 발행일을 나타내는 정보 중 적어도 하나 이상을 포함할 수 있다.
그리고 상기 소프트웨어의 제어에 대한 정보는 소프트웨어 이미지의 서버 주소나 URL, 압축된 소프트웨어 이미지를 풀 수 있는 액세스 코드, 소프트웨어 서버에 입장하기 위한 패스워드, 새로운 소프트웨어 이미지 파일 이름, 화면에 표시할 메시지, 상기 화면에 표시한 메시지에 대한 사용자의 반응, 다운로드 동작 설정에 대한 정보 중 적어도 하나 이상을 포함할 수 있다.
또한, 상기 다운로드 동작 설정에 대한 정보는 다운로드한 소프트웨어 수신하였다는 정보, 복구했다는 정보, 업그레이드했다는 정보 및 재부팅했다는 정보 중 어느 하나일 수 있다.
그리고 상기 소프트웨어 로그에 대한 정보는 엔트리를 생성한 날짜, 벤더에 의해 정의된 로그의 레벨 및 로그 메시지에 대한 정보 중 적어도 하나 이상을 포함할 수 있다.
또한, 상기 소프트웨어 그룹에 대한 정보는 부트 이미지에 사용할 인덱스에 대한 정보를 포함할 수 있다.
본 발명에 따라 네트워크로 연결된 서비스 제공업자로 상기 네트워크를 관리할 수 있는 프로토콜을 이용하여 정보를 전달하는 방법의 일 예는, 자신이 관리하는 정보들 중 적어도 어느 하나에 기정의한 중요한 이벤트나 응급 상황이 발생한 경우, 상기 중요한 이벤트나 응급 상황의 발생을 나타내는 정보를 전송하는 단계를 포함하는 것을 특징으로 한다.
이때, 상기 중요한 이벤트나 응급 상황의 발생하였음을 나타내는 정보는 소프트웨어 다운로드 완료, 상기 다운로드 실패, 저장장치에 수신한 소프트웨어 이미지를 성공적으로 프로그램했음, 소프트웨어를 제공하는 서버에 접속할 수 없음, 부팅시 중요한 문제가 발생했음을 나타내는 정보 중 적어도 하나 이상을 포함할 수 있다.
그리고 상기 중요한 이벤트나 응급 상황의 발생을 나타내는 정보는 상기 서 비스 제공업자가 액세스할 수 없는 정보일 수 있다.
또한, 상기 네트워크를 관리하는 프로토콜은 SNMP 프로토콜을 포함할 수 있다.
본 발명에 따라 네트워크로 연결된 적어도 하나 이상의 IPTV 방송 수신기에 구비된 소프트웨어에 대한 정보를 상기 네트워크를 관리하는 프로토콜을 이용하여 업그레이함에 있어서, 상기 소프트웨어에 대한 정보는 상기 각 수신기가 구비한 소프트웨어 인포메이션에 대한 정보, 소프트웨어 제어에 대한 정보, 소프트웨어 로그에 대한 정보와 소프트웨어 그룹에 대한 정보 중 적어도 하나 이상을 포함하는 것을 특징으로 한다.
이때, 상기 소프트웨어 인포메이션에 대한 정보는 부팅 성공 횟수, 제조 회사 이름, 모델 이름, 해당 모델의 시리얼 넘버, 하드웨어 버전, 저장장치의 인덱스, 상기 저장장치의 크기, 해당 소프트웨어 크기, 소프트웨어 이미지의 버전, 상기 소프트웨어 이미지의 생산 날짜 및 발행일을 나타내는 정보 중 적어도 하나 이상을 포함할 수 있다.
그리고 상기 소프트웨어의 제어에 대한 정보는 소프트웨어 이미지의 서버 주소나 URL, 압축된 소프트웨어 이미지를 풀 수 있는 액세스 코드, 소프트웨어 서버에 입장하기 위한 패스워드, 새로운 소프트웨어 이미지 파일 이름, 화면에 표시할 메시지, 상기 화면에 표시한 메시지에 대한 사용자의 반응, 다운로드 동작 설정에 대한 정보 중 적어도 하나 이상을 포함할 수 있다.
또한, 상기 다운로드 동작 설정에 대한 정보는 다운로드한 소프트웨어 수신 하였다는 정보, 복구했다는 정보, 업그레이드했다는 정보 및 재부팅했다는 정보 중 어느 하나일 수 있다.
그리고 상기 소프트웨어 로그에 대한 정보는 엔트리를 생성한 날짜, 벤더에 의해 정의된 로그의 레벨 및 로그 메시지에 대한 정보 중 적어도 하나 이상을 포함할 수 있다.
또한, 상기 소프트웨어 그룹에 대한 정보는 부트 이미지에 사용할 인덱스에 대한 정보를 포함할 수 있다.
본 발명에 따라 네트워크로 연결된 서비스 제공업자로 상기 네트워크를 관리할 수 있는 프로토콜을 이용하여 자신이 관리하는 정보들 중 적어도 어느 하나에 기정의한 중요한 이벤트나 응급 상황이 발생하였음을 나타내는 정보를 전달함에 있어서, 상기 중요한 이벤트나 응급 상황의 발생하였음을 나타내는 정보는 소프트웨어 다운로드 완료, 상기 다운로드 실패, 저장장치에 수신한 소프트웨어 이미지를 성공적으로 프로그램했음, 소프트웨어를 제공하는 서버에 접속할 수 없음, 부팅시 중요한 문제가 발생했음을 나타내는 정보 중 적어도 하나 이상을 포함하는 것을 특징으로 한다.
이때, 상기 중요한 이벤트나 응급 상황의 발생을 나타내는 정보는 상기 서비스 제공업자가 액세스할 수 없는 정보일 수 있다.
본 발명에 따른 네트워크로 연결되어 양방향 통신이 가능한 IPTV 방송 수신기의 일 예는, 상기 네트워크와 연결하는 네트워크 인터페이스; 기구비한 소프트웨어에 대한 정보를 저장하는 영역과 업그레이드하는 소프트웨어에 대한 정보를 저장 하는 영역을 구비하는 저장부; 및 상기 네트워크를 관리하는 프로토콜에 따라 외부로부터 기구비한 소프트웨어에 대한 정보 수집 요청에 따라 정보를 수집하도록 제어하거나 상기 수집한 정보를 외부로 전송하도록 제어하거나 상기 외부로부터 소프트웨어 업그레이드에 관한 문의를 수신하고 그에 따른 결과를 보고하도록 제어하거나 상기 외부로부터 전달되는 소프트웨어에 대한 정보와 소프트웨어를 수신하여 설치하도록 제어하는 제어부를 구비하는 것을 특징으로 한다.
이때, 상기 외부로부터 소프트웨어 업그레이드에 관한 문의를 수신하여 표시하는 표시부를 더 구비할 수 있다.
그리고 상기 제어부는 자신이 관리하는 정보들 중 어느 하나에 중요한 이벤트나 응급상황이 발생한 경우에는 그에 따른 정보를 상기 네트워크를 관리하는 프로토콜에 따라 외부로 전송하도록 제어할 수 있다.
또한, 상기 네트워크를 관리할 수 있는 프로토콜은 SNMP 프로토콜을 포함할 수 있다.
본 발명에 따라 소프트웨어 업그레이드를 위한 시스템의 일 예는, 상기 소프트웨어 업그레이드 여부 판단을 위한 정보 요청과 업그레이드할 소프트웨어에 대한 정보 및 업그레이드할 소프트웨어를 네트워크를 통해 연결된 IPTV 방송 수신기로 상기 네트워크를 관리할 수 있는 프로토콜에 따라 전송하는 서비스 제공업자; 및 상기 업그레이드 여부 판단을 위한 정보 요청에 따른 응답을 하거나 수신하는 업그레이드할 소프트웨어를 설치하는 IPTV 방송 수신기를 구비하는 것을 특징으로 한다.
이때, 상기 IPTV 방송 수신기는 자신이 관리하는 정보들 중에서 중요한 이벤트나 응급 상황이 발생한 경우 그에 따른 정보를 상기 네트워크를 관리하는 프로토콜에 따라 상기 서비스 제공업자로 전송할 수 있다.
그리고 상기 서비스 제공업자는 상기 정보를 수신하여 각 수신기의 정보를 데이터베이스화하여 각 수신기를 관리할 수 있다.
또한, 상기 네트워크를 관리할 수 있는 프로토콜은 SNMP 프로토콜을 포함할 수 있다.
본 발명의 다른 목적, 특성 및 이점들은 첨부한 도면을 참조한 실시 예들의 상세한 설명을 통해 명백해질 것이다. 아울러 본 발명에서 사용되는 용어는 가능한 한 현재 널리 사용되는 일반적인 용어를 선택하였다. 그러나 특정한 경우는 출원인이 임의로 용어를 선정하였으며, 이 경우에는 해당되는 부분에서 상세히 그 의미를 기재하였다. 따라서, 본 발명에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미로서 파악하여야 할 것이다.
이하 본 발명에 따라 IPTV(internet protocol television) 환경에서 소프트웨어 업그레이드 및 원격에서 각 IPTV 방송 수신기를 에러 관리하는 방법, 장치 및 시스템에 대해 첨부한 도면을 참조하여 설명한다.
이때, 본 발명에서는 설명의 편의를 위해 원격에서 네트워크를 통해 연결된 각 수신기의 소프트웨어와 에러를 관리하는 매니지먼트 스테이션으로 서비스 제공업자(service provider, 이하 'SP')를, 업그레이드할 소프트웨어를 수신하여 설치하는 장치로서 IPTV 방송 수신기를 예로 하여 설명한다. 그리고 상기 IPTV 방송 환 경에서 소프트웨어 업그레이드와 에러 관리를 위하여 이용되는 네트워크를 관리하는 프로토콜로 SNMP(simple network management protocol) 프로토콜을 이용하는 것을 일 예로 하여 설명한다.
본 발명과 관련하여 IPTV는 지상파(terristrial), 위성(satellite) 혹은 케이블(cable) 방송과 같이 인터넷(internet)으로 방송 프로그램을 시청할 수 있으며, 제공되는 부가 서비스를 이용하여 원하는 영화나 음악, 전자 상거래 및 PC(personal computer)로 인터넷을 사용하듯 전자 메일 등의 서비스를 텔레비전에서 이루어질 수 있도록 한 것을 말한다.
먼저, 상기 IPTV 환경에 대해 설명한다. 도 1은 본 발명과 관련하여 IPTV 환경을 개념적으로 도시한 것이다.
IPTV 환경 또는 전체적인 시스템을 보면, 크게 프로그램 제공업자(program provider, 이하 'PP')(10), 서비스 제공업자(SP)(20)와 커스터머(customer or consumer)(30)로 구분할 수 있다. 이때, 상기 프로그램 제공업자(PP)(10)는 플랫폼 제공업자(platform provider)라고도 한다.
프로그램 제공업자(PP)(10)는 방송 프로그램에 대한 전반적인 모든 서비스와 데이터를 제공하는 하나의 큰 그룹을 일컫는다.
서비스 제공업자(SP)(20)는 멀티미디어 데이터(multimedia data)를 커스터머로 전송하거나 상기 커스터머의 안정적인 수신 환경을 제공하기 위해 전송망을 유지, 보수 및 관리하고, 프로그램 제공업자(PP)(10)에게 네트워크 전송을 위한 기반 시설과 기능을 제공한다.
커스터머(30)는 수신하는 데이터를 xDSL(x digital subscriber line)이나 케이블과 같은 기반 시설을 이용하여 재생하고, 사용자의 요구에 즉시 반응하는 등의 역할을 한다. 이러한 커스터머(30)는 대부분이 IPTV를 생산하는 업체들로 구성되고, IPTV, IP STB(IP settop box), IP Phone 등이 있을 수 있다. IP Phone의 경우 일반적으로 IPTV가 있으면 폰(phone) 서비스도 같이 서비스할 수 있다.
이하에서는 상술한 바와 같이, 서로 다른 역할을 수행하는 각 그룹에 대해 보다 상세하게 설명한다.
먼저, 프로그램 제공업자(PP)(10)에는 예를 들어, TV 방송국(station), 라디오 방송국(radio station), VoD(video on demand)/AoD(audio on demand) 서비스, MoD(music on demand) 서비스, PF 서버(server), EPG(electronic program guide) 서버, ECG(electronic content guide) 서버, 포털 서버(portal server) 등이 있을 수 있다. 이하 각각에 대해 살펴보면, 다음과 같다.
TV 방송국은 방송 프로그램을 만드는 곳으로, 기존의 지상파 방송국이나 케이블 방송국 등을 포함하며, 사용자들이 시청할 수 있는 프로그램을 만들어 저장하고 이를 디지털(digital)로 바꾸어 여러 가지 방송 형태로 전송할 수 있다.
라디오 방송국은 일반적으로 비디오 채널 없이 운영되나, 비디오 채널이 있을 수도 있다.
VoD/AoD 서비스는 상기 TV 방송국이나 라디오 방송국과는 다른 특성이 있다. 프로그램 제공업자(PP)에서도 방송할 프로그램을 저장해서 보관하겠지만, 이는 연속성이 있는 라이브(live) 방송으로 레코딩(recording)을 하지 않는 이상 되감아서 보거나 정지시켜서 볼 수 없는 특징이 있다.
그러나 VoD나 AoD의 경우에는 사용자가 원하는 방송 프로그램 혹은 영화, 음악들을 먼저 저장한 뒤 이를 재생하여 시청할 수 있도록 서비스할 수 있다. 예를 들어, 사용자는 시간이 없어서 제대로 시청하지 못한 방송 프로그램이 있는 경우, 해당 방송 서비스를 제공하는 사이트에 접속하여 파일을 다운로드하거나 바로 재생할 수 있다. AoD도 마찬가지로 오디오 프로그램을 녹화하기 어렵거나 실시간으로 들을 수 있는 기능을 제공한다.
MoD 서비스는 내가 원하는 음악을 다운로드 받아서 들을 수 있다. MoD는 AoD와 유사하나, 그 서비스의 대상은 음반사 또는 음반 배포사가 기존의 웹 서비스를 확대하여 사용할 수 있다.
PF 서버는 프로그램 제공업자(PP)(10)가 제공하는 모든 방송 정보와 로케이션(location) 정보 등을 대신 관리해주는 업체가 서비스를 할 수 있다. 상기 PF 서버는 주로 해당 방송국의 방송 시간이나 방송에 필요한 위치 정보 및 사용자가 접속을 할 수 있는 정보를 서비스한다.
따라서, 상기 PF 서버의 서비스는 IPTV 환경에서 반드시 제공하여야 하며, 이를 위해 각 방송국은 PF 서버를 구비하여야 한다. 각 방송국이 상기 IPTV 환경에서 만약 PF 서버를 구비하지 못한 경우에는 사용자가 해당 방송국에 접속하지 못할 수 있다. 또한, 커스터머(30)는 상기 PF 서버에서 제공하는 서비스를 통해 수신하는 정보를 처리하여 화면에 표시할 수 있어야 한다.
EPG 서버에서 제공하는 서비스는 사용자가 방송 프로그램을 시간대별로 조회 하거나 채널별로 파악할 수 있도록 하는 서비스로써, 이미 TV 가이드 사에서 제공하는 형태가 대표적이라고 할 수 있을 만큼 자주 사용하는 서비스이나 상기 EPG 서버는 프로그램이 자동으로 커스터머(30)에 설치되어 실행할 수 있도록 할 수 있다.
커스터머(30)는 상기 PF 서버에서 제공하는 서비스를 수신하여 해당 방송국에 대한 정보만을 얻을 수 있지만, 상기 EPG 서버에서 제공하는 서비스를 수신하여 모든 방송국의 실시간 방송 채널에 대한 정보들을 한꺼번에 얻을 수 있다. 예를 들어, 커스터머(30)는 상기 EPG 서버에서 제공하는 EPG 서비스를 수신하여 CNN 뉴스를 예약 녹화하거나 디즈니(disney) 방송을 시청 예약할 수 있다. 따라서, EPG 서버는 해당 지역의 방송 프로그램의 정보를 시간대별로 자세하게 제공하여야 한다.
특히, 상기 EPG 서비스는 예를 들어, 드라마의 경우 드라마의 내용을 검색하거나 해당 드라마의 카테고리가 SF(science fiction), 드라마(drama), 애니메이션(animation) 등인지를 구분할 수 있으며, 방영하는 프로그램 즉, 영화나 드라마의 줄거리나 등장 인물들에 대한 세부적인 정보도 제공할 수 있다.
또한, 커스터머(30)는 간단하게 리모콘(remote controller)에 구비되어 있는 EPG 키를 이용하여 EPG 서비스에 접속할 수 있다.
ECG 서버에서 제공하는 ECG 서비스는 사용자가 프로그램 제공업자(PP)(10)가 구비하고 있는 콘텐츠(content)의 정보와 접속 서버의 위치 및 접근 권한 등을 편리하게 사용할 수 있도록 한다. 이때, 상기 ECG 서비스는 콘텐츠를 구비한 서버들을 쉽게 접속하도록 하는 기능과 콘텐츠의 정보를 상세하게 제공할 수 있다. 즉, ECG 서비스는 실시간 방송이 아니라 VoD/AoD 및 MoD와 같은 서비스들을 EPG와 같이 비슷하게 하나로 묶어서 사용자가 어떤 콘텐츠 서비스를 통해 콘텐츠를 보거나 다운로드하기 위해 개별 접속하는 부담을 덜어 준다.
ECG 서비스는 상기 EPG 서비스와 달리 실시간 방송 채널 정보를 알려 주는 것이 아니라 이미 서버에 저장된 방송 채널 정보에 대한 정보를 제공하여 사용자가 언제든지 시청할 수 있고 다운로드 하여 저장할 수 있도록 편리를 제공하는 정보이다.
예를 들어, 사용자는 매우 어려운 주소나 PF 서버들을 접속하여 각 콘텐츠가 있는 서버에 대한 정보를 얻어 접속하여야 하나, 이는 많은 시간과 노력을 요구한다. 그러나 , 사용자는 간단하게 리모콘 등에 구비된 ECG 버튼을 이용하여 ECG 서비스를 신청하면, 자동으로 설치된 ECG 프로그램을 통해 모든 콘텐츠에 대하여 수집하여 제공하는 정보를 한꺼번에 확인하여 원하는 서버에만 접속하여 해당 데이터를 얻을 수 있어 사용자의 편리성을 추구할 수 있다.
포털 서버에서 제공하는 서비스는 각 방송국에서 제공하는 웹 서비스(web service)로, 방송국이나 콘텐츠를 서비스하는 업체의 웹서버로 연결할 수 있는 정보를 제공할 수 있다. 이러한 상기 포털 서버는 각 방송국이나 콘텐츠 서비스를 제공하는 프로그램 제공업자(PP)들이 제공하는 프로그램 리스트를 검색할 수 있어, 마치 ECG나 EPG와 같은 기능을 제공할 수 있다.
그러나 포털 서비스는 사용자의 인증이나 라이센스(license) 계약 등과 같은 기능도 갖추고 있어서 내가 원하는 프로그램을 시청하기 위해서 접속할 필요가 있다. 또한, ECG나 EPG 서비스는 통합된 방송이나 콘텐츠 리스트를 제공하지만, 포털 서비스는 해당 프로그램 제공 업체에 대한 방송이나 콘텐츠 리스트 정보를 제공하여 세부적인 검색이 가능할 수 있다. 그리고 사용자는 간단하게 리모콘 등을 통해 포털 서비스에 접속할 수 있다.
상술한 내용은 프로그램 제공업자(PP)(10)가 제공할 수 있는 서비스들에 대한 것으로, 상기 각 방송국이나 서버는 실시간으로 프로그램을 전송하거나 방송 정보를 전송할 수 있도록 인터넷에 접속하고 있어야 한다.
또한, 각 방송국이나 서버는 RTP(real-time transport protocol), RTSP(real-time streaming protocol), RSVP(resource reservation protocol) 또는 MPLS(multi protocol label switching) 등의 인터넷 (실시간) 프로토콜을 이용하여 서비스 제공업자(SP)(20)의 네트워크에 연결하여 멀티미디어 데이터를 지연과 에러 없이 전송할 수 있는 시스템을 갖추어야 한다.
예를 들어, IPTV 환경에서 프로그램 제공업자(PP)(10)는 MPEG-2(moving picture experts group-2) 및/또는 AC-3(audio coding-3) 방식에 따른 멀티미디어를 실시간으로 전송하려면, 특정 서버에서 상기 IPTV 환경에 맞게 트랜스코드(transcode) 한 후 캡션(caption)이나 립싱크(lipync)를 맞출 수 있도록 시간 정보가 포함된 RTP/UDP(user datagram protocol) 프로토콜을 붙여 서비스 제공업자(SP)가 제공한 IP 네트워크를 통과하도록 시스템을 구성할 수 있다.
서비스 제공업자(SP)(20)는 상기와 같은 과정을 거쳐 프로그램 제공업자(PP)로부터 수신하는 멀티미디어 데이터 및/또는 방송 데이터들을 잘 전송할 수 있도록 네트워크의 안정성과 대역폭을 제공한다.
이때, 서비스 제공업자(SP)(20)들은 기존의 케이블 망을 이용하여 IPTV 서비스를 제공할 수도 있다. 그러나 상기와 같은 경우 서비스 제공업자(SP)(20)들은 전송망(delivery network)의 장비들을 변경하여야 한다. 즉, 서비스 제공업자(SP)(20)들은 데이터를 실시간으로 전송할 수 있는 네트워크 장비들을 구비하되, 커스터머(30)의 대역폭을 고려하여야 한다.
또한, 서비스 제공업자(SP)(20)들은 상기와 같은 장비와 IPTV의 기본적인 네트워크 서비스인 멀티캐스트(multicast) 서비스를 사용하여 대용량의 멀티미디어 데이터들을 처리하여 대역폭을 줄여야 할 것이다. 그러나 서비스 제공업자(SP)(20)들은 만약 충분한 대역폭을 확보하지 못하는 경우에는 광케이블 망 구성이나 프로그램 제공업자(PP)(10)로부터 수신하는 멀티미디어 데이터 및/또는 방송 데이터들을 다시 트랜스코드하여 MPEG-4나 MPEG-7과 같은 형태로 변형하여 전송할 수도 있다.
서비스 제공업자(SP)(20)는 상기와 같은 경우에 NMS 매니저(network management system manager), DHCP(dynamic host control protocol) 서버 및 CDN(contents delivery network) 서버를 구비할 수 있다.
NMS 매니저는 서비스 제공업자(SP)(20)가 각 커스터머로 전송할 수 있는 전송망과 커스터머(30)의 IPTV 방송 수신기를 관리한다. 예를 들어, 서비스 제공업자(SP)(20)는 상기 NMS 매니저를 통해 전송망에 문제가 발생하여 커스터머(30)에서 정상적인 방송 수신이 이루어지지 않음을 알 수 있고, 해당 문제를 처리할 응급 수단을 구비하고 있어야 한다.
상술한 NMS 매니저는 원격의 전송 계층의 기계들을 원활하게 제어하고 관리할 수 있는 표준화된 수단으로 널리 사용하고 있다. 즉, 서비스 제공업자(SP)(20)는 상기 NMS 매니저를 이용하여 어떤 방송에 대하여 얼마만큼의 트래픽(traffic)이 발생하고 있고, 어떤 지역에서 대역폭이 모자라는지를 확인할 수 있다.
또한, 서비스 제공업자(SP)(20)는 멀티캐스트 시에 그룹을 생성하고 관리할 수 있도록 프로그램 제공업자(PP)(10)에게 상기 NMS 매니저의 서비스를 제공하여야 한다. 이는 프로그램 제공업자(PP)(10)가 특정한 경우에는 멀티캐스트 그룹을 더 생성할 수도 있어야 하기 때문이다.
DHCP 서버는 자동으로 커스터머의 IPTV 방송 수신기로 IP를 할당할 수 있도록 하고, CDN 서버의 주소를 알려준다. 상기 DHCP 서버는 일반 네트워크에서도 PC에 IP를 할당하는 수단으로 사용하고 있다.
즉, 서비스 제공업자(SP)(20)는 상기 DHCP 서버를 통해 사용이 허락된 IPTV 방송 수신기로 접속할 수 있는 주소를 전송하여 사용자가 최초 접속할 때 등록 절차를 할 수 있도록 해야 한다. 서비스 제공업자(SP)(20)는 IPTV 환경에서 일반적으로 IPv4(internet protocol version 4)를 IPTV 방송 수신기에 제공할 수 있으나, IPv6(internet protocol version 6)를 제공할 수도 있다. 따라서, IPv4를 제공하는 IPTV 수신기라고 해서 사용하지 못하는 것은 아니다.
CDN 서버는 IPTV 방송 수신기가 최초로 전원이 인가되어 동작할 때 IP와 함께 CDN 정보를 제공하기 위한 것으로, 상기 CDN 정보는 IPTV 방송 사업자의 사용자의 등록이나 인증 및 상술한 PF 정보들을 포함한다. 따라서, IPTV 방송 수신기는 서비스 제공업자(SP)(20)로부터 상기 CDN 정보를 수신하지 못하면 방송 수신이 불가능하다.
커스터머(30)는 여러 가지 형태의 IPTV 방송 수신기를 포함한다. 사용자가 만약 일반 TV를 가지고 있으면, IPTV STB를 임대하여 저렴하게 IPTV 방송 서비스를 즐길 수 있으며, 이에 더하여 서비스 제공업자(SP)(20)에게 저렴한 가격으로 추가적인 서비스 비용을 지불하고 IP Phone도 함께 신청하여 사용할 수 있다.
IPTV 방송 수신기는 기본적으로 네트워크 인터페이스(network interface)를 구비하여 네트워크에 접속하고, 인터넷 프로토콜(IP)을 이용하여 데이터 패킷을 수신하여 멀티미디어 데이터를 화면에 재생할 수 있다. 또한, IPTV 방송 수신기는 리모콘(remote controller)을 조작하여 데이터 패킷을 네트워크를 통해 신속하게 전송하여 해당 정보를 서버로부터 수신하여 반응하여야 한다. 즉, IPTV 방송 수신기는 멀티미디어 데이터를 처리하면서 양방향으로 사용자의 요구 사항을 전송할 수 있어야 한다.
또한, 리모콘과 같은 외부 입력 장치는 상기와 같은 양방향 서비스를 제공할 수 있도록 IPTV 방송 서비스를 위한 기능 버튼을 구비하여야 할 것이다. 따라서, 사용자는 상기 외부 입력 장치를 이용하여 드라마에 나오는 멋진 장면을 저장하여 볼 수 있고, 위치 정보나 호텔 예약과 같은 부가 서비스를 이용할 수 있다.
한편, 상기 NMS 매니저는 전송망 및 IPTV 방송 수신기를 제어하고 관리한다고 하였는바, 향후 IPTV 환경에서 방송 서비스의 영역은 더욱 확장되고 부가 서비스가 증가될 수 있다. 이에 따라, 일 예로 향후 IPTV 방송 수신기가 급증하고 부가 서비스들이 더욱 늘어나면, 상기 NMS 매니저의 역할이 중요할 것이다.
따라서, 서비스 제공업자(SP)(20)와 IPTV 방송 수신기는 상기와 같은 환경 때문에 SNMP 프로토콜을 이용할 수 있다. 즉, 서비스 제공업자(SP)(20)는 SNMP 프로토콜을 이용하여 IPTV 방송 수신기가 현재 통신하는 프로토콜의 통계자료, 사용하는 프로세서의 정보, TV 제조 업체명 등에 대하여 상세하게 파악할 수 있다.
상기 SNMP는 네트워크에 있는 장비나 서버들을 효과적으로 제어하고 관리하기 위한 애플리케이션 레이어 프로토콜(application layer protocol)의 하나로써, 현재는 버전 1(version 1)에서 버전 3(version 3)까지 있으나, 보안을 위하여 계속 업그레이드되고 있다.
상기 SNMP는 여러 업체가 각각 자신들이 만들어 놓은 장치에 대한 제어 및 정보를 기술할 수 있도록 언어를 제공하고, 상기 언어를 이용하여 관리될 정보(management information base; MIB)를 정의한다. 상기 관리될 정보(MIB)는 구조화된 기술 언어(structure of management information; SMI)로 표현하여 관리자와 객체에 어떤 객체들을 관리할 수 있는지 그리고 어떤 객체들이 관리되어야 하는지를 명확하게 정의할 수 있다.
이하에서는 상기 SNMP 프로토콜을 이용하여 양방향 통신을 하는 것에 대해 살펴보면, 도 2는 본 발명과 관련하여 SNMP 매니저와 SNMP 에이전트의 기능을 설명하기 위해 도시한 것이다.
이때, 설명의 편의를 위해, 상기 SNMP 매니지먼트 스테이션은 상기 SNMP 프로토콜을 이용하여 IPTV 방송 수신기로 소프트웨어를 업그레이드시키거나 원격에서 각 IPTV 방송 수신기의 상태 등을 포함한 에러 관리를 하며, SNMP 에이전트는 상기 SNMP 매니지먼트 스테이션으로부터 소프트웨어를 수신하여 설치하거나 IPTV 방송 수신기의 상태 등을 포함한 에러 관리에 대한 정보를 상기 SNMP 매니지먼트로 전송하여 상기 SNMP 매니지먼트가 각 IPTV 방송 수신기를 관리할 수 있도록 하는 것이다. 이때, 상기 SNMP 매니지먼트는 상술한 서비스 제공업자(SP)(20)나 NMS 서버를 지칭할 수 있으며, SNMP 매니저(manager)를 구비하며, 상기 SNMP 에이전트는 IPTV 방송 수신기 내에 구비되어야 한다.
SNMP 매니지먼트 스테이션은 "GetRequest", "GetNextRequest", "SetRequest" 패킷을 IPTV 방송 수신기로 전송할 수 있고, 상기 IPTV 방송 수신기는 "GetResponse"와 "Trap" 패킷을 전송할 수 있다.
즉, SNMP 매니저는 "GetRequest", "GetNextRequest" 및 "SetRequest" 패킷을 UDP와 IP를 통해 네트워크 환경으로 전달하고 SNMP 에이전트에 전달된다.
SNMP 에이전트는 상기 SNMP 매니저로부터 UDP와 IP를 통해 패킷을 수신하면, 상기 수신한 패킷이 "GetRequest", "GetNextRequest" 및 "SetRequest" 패킷인지를 확인한다. 그리고 SNMP 에이전트는 상기 확인 결과에 따라 해당 동작(operation)을 관리 객체(SNMP managed object)에 대하여 수행한다.
상기 SNMP 패킷 종류 중 "GetRequest"와 "GetNextRequest" 패킷은 관리 객체의 정보를 요청하는 패킷이고, "SetRequest" 패킷은 관리 객체에 어떤 동작을 시키기 위한 설정을 위한 패킷이다.
따라서, SNMP 에이전트는 "GetRequest" 또는 "GetNextRequest" 패킷을 수신 하면, 정상적인 객체(object)에 대한 요청인지 여부를 판단하고, 상기 판단 결과 관리하는 객체인 경우에는 "GetResponse" 패킷을 전송하여 요청한 객체에 대한 값을 순서대로 정렬하여 전송한다.
한편, SNMP 에이전트는 이벤트가 발생하면 SNMP 매니지먼트 스테이션으로 트랩(trap) 패킷을 전송할 수 있다. 상기 트랩 패킷은 예를 들어, 관리 객체가 MIB에 정의한 범위를 넘거나 특정 값으로 변경하면 SNMP 매니지먼트 스테이션로 트랩을 전송하여 관리 객체를 처리할 수 있다.
즉, SNMP 매니지먼트 스테이션이 MIB에 정의된 객체에 대한 정보를 요청(request)하면, SNMP 에이전트는 해당되는 객체가 자신이 관리하는 객체인지를 확인하고 그에 대한 응답(response)을 한다. 그러나 그렇지 않은 경우에는 응답하지 않을 수 있다.
또한, SNMP 에이전트는 상기 SNMP 매니지먼트 스테이션의 요청과 상관없이 자신이 관리하는 객체들 중에서 중요한 이벤트나 응급 상황이 발생하면, SNMP 매니지먼트 스테이션으로 트랩 패킷을 전송할 수 있다.
즉, SNMP 에이전트는 수신기에서 어떤 특별한 동작을 할 수 있도록 MIB를 정의하기만 하면, 상기 SNMP 에이전트를 만들 수 있다.
따라서, NMS 매니저는 IPTV 방송 서비스를 위하여 필요한 정보나 제어가 MIB 형태로 정해지면, IPTV 방송 수신기들은 이러한 규격에 대하여 반드시 지원해야 한다.
이하에서는 서비스 제공업자(SP)(20)가 SNMP 프로토콜을 이용하여 IPTV 방송 수신기의 소프트웨어를 업그레이드하는 방법에 대해 설명한다.
상술한 바와 같이, IPTV 환경에서 수신기는 다양한 기능을 구비하고 있으며, 그 동작 또한 매우 복잡한바, 원격으로 소프트웨어를 자동으로 업그레이드할 필요가 있다.
즉, SNMP 프로토콜은 기 정해진 MIB 파일에 의하여 구현되고, SNMP 매니저는 해당하는 객체를 읽어서 정보를 얻는다. 또한, IPTV 방송 수신기는 어떤 정보들을 관리해야 하고, 필요한지 그 요구 사항을 정할 수 있다. 예를 들어, 본 발명과 같은 원격으로 다운로드하는 기능을 SNMP로 하는 것을 들 수 있다.
이하에서는 본 발명에 따라 서비스 제공업자 측에서 SNMP 프로토콜을 이용하여 IPTV 방송 수신기에 소프트웨어를 원격으로 다운로드하여 설치하고 각 IPTV 방송 수신기의 문제점 등 에러 관리에 대한 정보를 파악할 수 있도록 로그를 저장할 수 있도록 정의한 관리 정보에 대해 설명한다. 즉, IPTV 방송 수신기에서 소프트웨어를 다운로드하고, 수신기의 문제 상황을 파악할 수 있는 로그 정보를 저장할 수 있는 객체들을 정의한다.
이하에서는 설명의 편의를 위해, 상기 IPTV 방송 수신기를 호스트(host)로, 상기 호스트를 운용하는 소프트웨어를 호스트 소프트웨어(host software)라고 한다.
상기 호스트 소프트웨어는 호스트에 문제가 발생하면, 원격에서 관리할 수 있도록 하고, 현재 파티션(partition)이 어떤 것이 있는지 등의 정보들을 포함하는 관리 정보의 큰 그룹으로 정의한다.
호스트 소프트웨어 그룹(host software group)은 IPTV 방송 수신기에 구비된 SNMP 에이전트에서 소프트웨어의 관리를 위한 객체를 기술하며, M/O(mandatory/optional)은 강제사항/선택사항을 의미하고, 액세스(access)는 해당 객체에 접근할 때 RO(read-only), RW(read-write) 및 N-acc(not accessible)를 구분한다.
상기 호스트 소프트웨어 그룹은 본 발명과 관련하여 정의한 적어도 하나 이상의 테이블을 구비할 수 있으며, 각 테이블은 연관성이 높은 객체들을 포함할 수 있다. 이하 상기 호스트 소프트웨어 그룹을 구성하는 각 테이블에 대해 설명한다. 이때, 각 테이블은 호스트에 다운로드되는 소프트웨어를 관리하고 제어할 수 있다.
도 3a는 본 발명에 따라 구성한 호스트 소프트웨어 인포메이션 테이블(host software information table)의 일 예를 도시한 것이다. 이때, 상기 테이블에 포함되는 각 객체의 영문명은 그대로 사용하되, 큰 따옴표를 이용하여 표시한다. 또한, 상기 영문명은 본 발명의 기술 사상을 설명하기 위한 예시로써, 상기 각 객체의 명칭이 아닌 그 의미로써 본 발명을 파악하여야 함을 밝혀둔다.
호스트 소프트웨어 인포메이션 테이블은 호스트 소프트웨어가 가지고 있는 정보와 소프트웨어가 다운로드 되어 있는 하드웨어의 물리적인 파티션에 대한 정보를 포함할 수 있다.
“HostSoftwareInfoIndex"는 해당 테이블의 인덱스를 나타내고, 액세스는 RW이다. 일반적으로 다운로드가 지원되는 시스템의 경우에는 독립적인 파티션을 구분하여 다운로드가 실패하면, 그에 대응할 수 있도록 백업을 위한 파티션을 하나 더 가지고 있는 것이 특징이다.
따라서, 호스트 소프트웨어 인포메이션 테이블의 "HostSoftwareInfoIndex"는 '0'부터 증가하고, '1'까지의 값을 가질 수 있다. 즉, 부트(boot) 가능한 디바이스 파티션(device partition)이 '0'과 '1'이라는 파티션으로 나누어져 있음을 의미한다.
그러나 상기 인덱스 값이 만약 '2'라면, 이는 부트 가능한 디바이스 파티션이 3개가 있다는 것인데, 일반적으로는 비용 문제 등으로 인하여 부트 디바이스 파티션은 2개 이상 만들지 않는다. 그러나 특수한 경우를 대비하기 위하여 상기 인덱스 값은 SMI에서 정의하는 부호를 정하지 않은 정수(unsigned integer) 값을 가진다. 부팅이 되면서 소프트웨어 버전과 소프트웨어 제조자 그리고 실행파일의 크기 등등의 정보들이 SNMP 에이전트에 업그레이드되어야 한다.
“HostSoftwareBootCount"는 해당 디바이스에서 성공적으로 부팅한 횟수를 나타내고, 액세스는 RO이다.
“HostSoftwareManufacturer"는 해당 디바이스의 제조사의 이름을 나타내고, 액세스는 RO이다.
“HostSoftwareModel"는 해당 디바이스의 제품 모델 이름을 나타내고, 액세스는 RO이다.
“HostSoftwareSerialNumber"는 해당 제품 모델의 고유 번호 또는 시리얼 넘버를 나타내고, 액세스는 RO이다.
“HostSoftwareCompatibleHwVersion"는 해당 하드웨어의 버전을 나타내고, 액세스는 RO이다.
“HostSoftwareBootDeviceIndex"는 플래쉬 메모리(flash memory)나 비휘발성 메모리 디바이스(non volatile memory device)의 인덱스를 나타내고, 액세스는 RO이다.
“HostSoftwareDeviceCapacity"는 플래쉬 메모리나 비휘발성 메모리 디바이스의 크기(size)를 나타내고, 액세스는 RO이다.
“HostSoftwareExcutableImageSize"는 상기 소프트웨어의 크기를 나타내고, 액세스는 RO이다.
“HostSoftwareImageVersion"는 상기 소프트웨어 이미지의 버전을 나타내고, 액세스는 RO이다.
“HostSoftwareImageBuildDate"는 상기 소프트웨어 이미지의 제조 일자를 나타내고, 액세스는 RO이다.
“HostSoftwareImageReleaseDate"는 상기 소프트웨어의 발행 일자(release date)를 나타내고, 액세스는 RO이다.
다음으로, 도 3b는 본 발명에 따라 구성한 호스트 소프트웨어 콘트롤 테이블(host software control table)의 일 예를 도시한 것이다.
상기 호스트 소프트웨어 컨트롤 테이블은 주로 호스트에 구비된 SNMP 에이전트가 소프트웨어를 다운로드하거나 상기 다운로드 완료 후에 실행시키기 위해 재부팅(rebooting)할 수 있도록 정의한 객체들을 포함할 수 있다. 이때, 서비스 제공업자(SP)는 다운로드시킬 소프트웨어가 있는 서버의 URL(uniform resource locator) 을 설정할 수 있는 객체인 "HostSoftwareControlServerURL"를 원격으로 설정할 수 있다.
"HostSoftwareControlServer"는 상기 소프트웨어 이미지의 URL, FTP(file transfer protocol) 혹은 서버 주소를 나타내고, 액세스는 RW이다.
"HostSoftwareControlAccessCode"는 상기 압축된 소프트웨어 이미지의 압축을 풀기 위한 액세스 코드를 나타내고, 액세스는 RW이다.
"HostSoftwareControlPassword"는 상기 소프트웨어 서버로 접속하기 위한 패스워드를 나타내고, 액세스는 RW이다.
"HostSoftwareControlFilename"는 새로운 소프트웨어 이미지의 파일 이름을 나타내고, 액세스는 RW이다.
"HostSoftwareControlMessageOnScreen"는 "HostSoftwareControlOperation"에 대한 어떤 메시지들을 화면에 디스플레이하는 것을 나타내고, 액세스는 RW이다. 이때, 상기 메시지들은 타겟(target)의 그래픽 하드웨어(graphic hardware)를 사용함으로써 디스플레이하여야 한다. 예를 들어, 서비스 제공업자(SP)(20) 또는 NMS 매니저에서 해당 시스템의 재부팅을 원하다면, 상기 옥텟-스트링 값은 “이 시스템 재부팅(Reboot this system)"이 될 것이다.
"HostSoftwareControlUserResponse"는 상기 "HostSoftwareControlMessageOnScreen" 객체에 의해 화면에 표시된 메시지들에 대한 사용자의 응답을 나타내고, 액세스는 RO이다. 이때, 상기 디폴트 값(default value)이 ‘0’이면 ‘아니오(No)'를, '1'이면 '예(Yes)'를 나타낼 수 있다.
"HostSoftwareControlOperation"는 다운로드 동작을 설정함을 나타내고, 액세스 RW이다. 이때, 호스트 소프트웨어를 다운로드 하기 위하여 설정해야 하는 객체들은 상기 다운로드 동작과 관련하여 패스워드를 나타내는 "HostSoftwareControlPassword", 액세스 코드를 나타내는"HostSoftwareControlAccessCode" 및 동작을 나타내는 "HostSoftwareControlOperation" 중 적어도 하나 이상을 포함할 수 있다.
특히, 상기 객체들 중 "HostSoftwareControlAccessCode"는 다운로드된 이미지의 압축 혹은 암호화를 해제할 때 필요한 암호 혹은 CAS(conditional access system) 시스템에 사용되는 키(key)가 될 수 있다. 즉, 호스트는 서비스 제공업자(SP)가 제공하는 상기 압축 혹은 암호화를 해제할 수 있는 키를 수신하여 이미지를 해제하여야 자신이 수신한 이미지가 정상적인 이미지인지 확실하게 알 수 있다.
여기에 부가하여 "HostSoftwareControlMessageOnScreen"에 화면에 표시할 간단한 메시지를 텍스트로 써주면, 호스트 시스템에 있는 그래픽 프로세서(graphic processor)를 통하여 메시지를 출력하여 상황에 따라서 사용자에게 알려 줄 수 있다.
또한, 그에 대한 반응을 "HostSoftwareControlUserResponse"로 얻어올 수 있다. OSD에 대한 반응을 얻기 위한 것이다.
그러나 SNMP 매니저는 상기와 같은 반응을 기대하지 않을 수도 있다. 이는 SNMP 매니저가 관리하여야 할 IPTV 방송 수신기가 많기 때문인데, 상기와 같은 방법이 아니라 일괄적으로 세팅하고 리부팅시킬 수 있다.
다음으로, 도 3c는 본 발명에 따라 구성한 호스트 소프트웨어 로그 테이블(host software log table)의 일 예를 도시한 것이다.
상기 호스트 소프트웨어 로그 테이블은 현재 동작하는 소프트웨어의 로그 메시지를 저장하는 테이블로서, 부팅이 완료되고 나서 시스템에서 알려 줄 수 있는 메시지를 다음의 몇 가지로 구분할 수 있을 것이다.
“HostSoftwareLogIndex"는 상기 호스트 소프트웨어 로그 테이블의 인덱스를 나타내고, 액세스는 RO이다.
“HostSoftwareLogTime"는 해당 엔트리가 생성된 시각을 나타내고, 액세스는 RO이다.
“HostSoftwareLogLevel"는 벤더(vendor)에 의해 정의된 메시지의 종류에 따라서 사용할 수 있는 레벨들을 나타내고, 액세스는 RO이다. 이때, 상기 각 레벨은 하기의 표 1과 같이 정의할 수 있다.
Value Object Description
1 emergency 응급 상황의 로그
2 alert 경고 상황의 로그
3 critical 위급 상황의 로그
4 error 에러
5 warning 호스트 동작 중에 위험한 상황인 경우 발생하는 메시지
6 notice 호스트 시스템 동작 관련 메시지
7 information 일반 정보
8 debug 디버그가 필요한 메시지
상기 표 1에 정의서 보아 알 수 있듯이 각각의 레벨들은 각 벤더(vendor)가 정한 메시지의 종류에 따라서 사용할 수 있다. 상기와 같이 메시지를 구분함으로써 원격의 NMS 매니저는 각각의 메시지를 분류해서 처리할 수 있다.
“HostSoftwareLogText"는 상기 로그의 메시지를 나타내고, 액세스는 RO이다.
상술한 바와 같이 호스트 소프트웨어 로그 테이블을 정의함으로써 즉, 에러가 발생한 시간은 상기 "HostsoftwareLogTime" 객체에 "DateAndTime" 값으로 기록할 수 있고, 상기 시간 정보가 저장되어 있지 않은 경우에는 임의의 호스트에 설정된 시간 값을 저장할 수 있다.
또한, 메시지를 저장할 수 있도록 "HostSoftwareLogText" 객체를 이용하며 이때, 상기 객체는 최대 255 바이트를 저장할 수 있도록 "octet-string" 값을 설정할 수 있다. 따라서, 상기 값으로 로그 메시지를 저장할 수 있고, NMS 매니저에서 상기 로그 메시지를 원격의 시스템에서 얻을 수 있어서 호스트를 관리하는데 매우 유용하다.
다음으로, 도 3d는 본 발명에 따라 구성한 호스트 소프트웨어 트랩 테이블(host software traps table)의 일 예를 도시한 것이다.
도 3d의 호스트 소프트웨어 트랩 테이블에 포함되는 각 객체는 상기 객체에 대한 정보를 정의하여 호스트에서 원격으로 전송하기 위한 것으로, 상술한 도 3a 내지 3c와 차이가 있다.
상기 호스트 소프트웨어 트랩 테이블은 트랩 패킷을 종류를 소프트웨어 다운로드의 상태 그리고 호스트의 상황에 따라서 NMS 매니저에게 알릴 수 있도록 몇 가지의 종류로 구분하고 있다. 그러나 각각의 패킷들은 호스트의 IP 주소, 현재 호스트 소프트웨어 버전 정보 등의 필요한 데이터들이 함께 포함하여 보내질 수 있다. 트랩들은 일반적으로 리포트(report)를 원하지 않을 경우에는 보내지지 않을 수 있다.
“HostSoftwareTrapsDownloadCompleted"는 전체 소프트웨어 이미지를 받았을 때 현재 소프트웨어를 가진 호스트 정보를 나타내고, 액세스는 N-Acc이다.
“HostSoftwareTrapsDownloadFailed"는 전체 소프트웨어 이미지를 적절하게 받지 못하였을 때 현재 소프트웨어를 가진 호스트 정보를 나타내고, 액세스는 N-Acc이다.
“HostSoftwareTrapsProgramCompleted"는 상기 수신한 소프트웨어 이미지를 플래쉬나 비휘발성 메모리 디바이스에서 성공적으로 프로그램할 때 현재 소프트웨어를 가진 호스트 정보를 나타내고, 액세스는 N-Acc이다.
“HostSoftwareTrapsCannotAccessServer"는 호스트가 소프트웨어 공급 서버로 접속할 수 없음을 나타내고, 액세스는 N-Acc이다.
“HostSoftwareTrapsBootFailed"는 호스트 이미지는 부팅시에 중요한(critical) 문제가 있음을 나타내고, 액세스는 N-Acc이다.
마지막으로, 도 3e는 본 발명에 따라 구성한 호스트 소프트웨어 그룹 디바이스 테이블의 일 예를 도시한 것이다.
"HostSoftwareBootDeviceId"는 NMS 매니저가 "HostSoftwareBootDeviceIndex"에 있는 값들 중에 선택하여 쓰면(write), 호스트에 구비된 SNMP 에이전트가 부트 디바이스(boot device)를 스위치(switch)해서 다음 부팅시에 해당 부트 디바이스 파티션으로 부팅시켜 주는 기능을 담고 있다.
상기 값은 현재 호스트가 보고한 "HostSoftwareInfoIndex"의 최댓값을 넘을 수 없다. 상기 값이 넘을 경우에는 호스트의 SNMP 에이전트는 이 요청을 무시할 수 있다.
도 4는 본 발명에 따라 IPTV 환경에서 소프트웨어 업그레이드를 위하여 구성한 시스템의 일 예를 도시한 것이다.
SNMP 매니지먼트 스테이션(220)은 매니저로써 IPTV 방송 수신기(420)를 관리한다. 이때, 상기 IPTV 방송 수신기(420)는 SNMP 에이전트(424)를 구비한다.
IPTV 방송 수신기(420)는 제 1 메모리(421), 제 2 메모리(422), 네트워크 인터페이스(423), SNMP 에이전트(424) 및 OSD 유닛(425)을 구비할 수 있다.
제 1 메모리(21)와 제 2 메모리(22)는 소프트웨어가 다운로드되는 곳으로, 플래쉬 메모리, 비휘발성 메모리 혹은 하드 디스크일 수 있다. 도 4에서는 IPTV 방송 수신기(420)에 2개의 메모리를 구비한 예를 들었으나, 하나의 메모리를 사용하더라도 적어도 두 영역으로 구분할 수 있으면 족한다.
네트워크 인터페이스(423)는 방송망에 접속 가능한 네트워크나 인터넷과 연결하는 인터페이스들 중 하나일 수 있다.
IPTV 방송 수신기(420)는 상기 네트워크 인터페이스(423)를 통해 IP 네트워크로 연결하여 SNMP 매니지먼트 스테이션(220)과 양방향 통신을 할 수 있다.
SNMP 에이전트(424)는 IPTV 방송 수신기(420)의 제어부를 이용하여 동작할 수 있으며, SNMPv1(SNMP version 1), SNMPv2(SNMP version 2) 및 SNMPv3(SNMP version 3)을 만족하도록 설계할 수 있다. 이때, 상기 SNMP 에이전트(424)는 SNMP 규격에 맞게 제작하며, 도 3a 내지 3e에서 상술한 바와 같은 소프트웨어 관리 객체를 포함한다.
OSD 유닛(OSD unit, 425)은 그래픽 프로세서(graphic processor)로써 수신하는 메시지나 그래픽을 해상도에 상관없이 화면에 표시할 수 있다.
즉, IPTV 방송 수신기(420)는 전원이 인가되면 네트워크 인터페이스(423)를 통해 네트워크 또는 인터넷과 연결한다. 그리고 상기 IPTV 방송 수신기(420)에 구비된 SNMP 에이전트(423)는 상기 네트워크 또는 인터넷과 연결을 확인한다.
SNMP 매니지먼트 스테이션(220)은 SNMP 에이전트(424)가 연결된 것을 확인하고, 상기 연결된 IPTV 방송 수신기에 원하는 정보가 있는 경우 상기 SNMP 에이전트(424)로 "GetRequest"와 "GetNextRequest"를 전송하여 요청한다. 이때, 상기 SNMP 매니지먼트 스테이션(220)은 소프트웨어 정보 관리 객체에 관한 정보를 요청할 수 있다.
그리고 SNMP 에이전트(424)는 상기 SNMP 매니지먼트 스테이션(220)의 요청이 수신되면, IPTV 방송 수신기에 기 구비된 제 1 메모리(421)와 제 2 메모리(422)로부터 해당 요청에 따른 정보 예를 들어, 수신기 내 구비된 소프트웨어 버전과 제조 회사 등에 관한 정보를 수집하고 상기 수집된 정보를 다시 상기 SNMP 매니지먼트 스테이션(220)으로 전송할 수 있다.
예를 들어, SNMP 매니지먼트 스테이션(220)은 IPTV 방송 수신기 내 호스트 소프트웨어의 시리얼 넘버에 대한 정보가 필요하면, 상기 도 3a에서 정의한 객체인 "HostSoftwareSerialNumber"를 "GetRequest" 패킷에 실어 전송하고, SNMP 에이전트(424)는 상기 "GetRequest" 패킷을 수신하여 상기 패킷에 포함된 객체인 "HostSoftwareSerialNumber"를 확인하고 상기 확인된 객체에 따라 제 1 메모리 등을 액세스하여 그 결과를 "GetResponse" 패킷에 실어 다시 SNMP 매니지먼트 스테이션(220)으로 전송한다.
또한, SNMP 매니지먼트 스테이션(220)은 상기와 같은 과정을 통해 IPTV 방송 수신기의 소프트웨어 정보를 확인한 후 상기 IPTV 방송 수신기에 구비된 소프트웨어의 업그레이드 유무를 판단할 수 있다.
따라서, SNMP 매니지먼트 스테이션(220)은 상기 판단 결과 IPTV 방송 수신기 내 소프트웨어의 업그레이드가 필요하면, IPTV 방송 수신기 내 SNMP 에이전트(424)로 업그레이드 여부를 문의할 수 있다. 이때, SNMP 매니지먼트 스테이션(220)은 IPTV 방송 수신기 내 SNMP 에이전트(424)에 "SetRequest" 패킷을 전송하여 호스트의 OSD 유닛(425) 또는 그래픽 프로세서(미도시) 등을 통하여 상기와 같은 업그레이드 여부 문의를 표시하도록 할 수 있다.
예를 들어, SNMP 매니지먼트 스테이션(220)은 상기 도 3a에서 정의한 객체 중 "HostSoftwareControlMessageOnScreen"를 "SetRequest" 패킷에 실어 전송하고, IPTV 방송 수신기 내 SNMP 에이전트(424)는 상기 "SetRequest" 패킷을 수신하여 상기 패킷에 포함된 메시지를 디스플레이한다.
그리고 사용자가 업그레이드를 거부하면, SNMP 매니지먼트 스테이션(220)은 상기 업그레이드와 관련하는 모든 동작을 종료하고, 그에 따라 IPTV 방송 수신기 내 SNMP 에이전트(424)는 SNMP 매니지먼트 스테이션(220)으로 트랩 메시지를 전송하여 소프트웨어 업그레이드가 중단되었음을 알릴 수 있다.
그러나 사용자가 소프트웨어 업그레이드를 수락하면, IPTV 방송 수신기 내 SNMP 에이전트(424)는 제 2 메모리(422)로 업그레이드할 소프트웨어를 다운로드 한다. 물론, 사용자는 상기와 같은 소프트웨어 다운로드 중에도 방송을 시청할 수 있다.
그리고 SNMP 에이전트(424)는 제 2 메모리(422)에 다운로드가 완료되면, 다운로드가 완료되었음을 OSD 유닛(425)을 통하여 화면에 디스플레이하고 사용자에게 IPTV 방송 수신기(420)의 전원을 오프(off)하거나 다시 동작(부팅)할 것을 권유할 수 있다.
이에 따라 전원이 오프되거나 다시 동작하는 IPTV 방송 수신기(420)는 제 1 메모리(421)가 아닌 새로운 소프트웨어를 다운로드한 제 2 메모리(422)를 사용하여 시스템을 동작한다.
그러나 IPTV 방송 수신기(420)는 상기와 같이 제 2 메모리(422)에 저장한 소프트웨어에 결함이 발생하여 시스템이 정상적으로 동작하지 않으면, SNMP 에이전트(424)는 제 1 메모리(421)의 임의의 영역에 에러를 기록하고 기존의 소프트웨어가 저장된 제 1 메모리(421)를 사용하여 시스템을 동작시킨다.
상술한 바와 같이 SNMP 매니지먼트 스테이션(220)은 양방향 통신을 통해 IPTV 방송 수신기에 구비된 소프트웨어의 업그레이드를 할 수 있다.
즉, SNMP 매니지먼트 스테이션은 SNMP 프로토콜의 매니저로서 SNMP 에이전트(424)를 구비한 IPTV(양방향 디지털 TV)를 관리할 수 있다. IPTV 방송 수신기(420)는 상기 SNMP 에이전트(424)를 구비한 케이블 모뎀(Cable Modem)을 내장한 을 내장한 디지털 텔레비전(Digital TV)으로 케이블 모뎀에 의하여 인터넷에 연결할 수 있다.
일단 IPTV 방송 수신기(420)가 켜지면, 자체 내장된 네트워크 인터페이스(423)를 통하여 네트워크와 연결할 수 있다. 이때, SNMP 에이전트(424)가 네트워크 연결을 확인하고, SNMP 매니저가 상기 IPTV 방송 수신기(420)와 연결을 시도한다. 그리고 SNMP 매니저는 연결이 되면, 현재 IPTV 방송 수신기에 동작중인 소프트웨어에 대한 정보(예를 들어, 버전(version))을 SNMP 에이전트(424)에 요청하고, 상기 SNMP 에이전트(424)는 제 1 메모리(421)로부터 상기 요청에 따른 정보를 수집하고, 상기 수집한 정보를 상기 SNMP 매니저로 보고할 수 있다.
SNMP 매니저는 상기 보고 결과를 확인하여 IPTV 방송 수신기(420)의 업그레이드 필요 유무를 판단하고, 상기 판단 결과 업그레이드가 필요하다고 판단되면, SNMP 에이전트를 통해 OSD를 통하여 사용자에게 최신 소프트웨어를 업그레이드 또는 다운로드할 지를 문의할 수 있다. 이때, 상기 일련의 과정은 사용자가 OSD를 통해 상기 문의에 대해 거부의 응답을 하면 모두 종료한다.
만약 사용자가 업그레이드를 수락하면, SNMP 에이전트(424)는 제 2 메모리(422)에 기 설정된 호스트 소프트웨어의 이미지 서버에서 이미지 다운로드를 하여 저장하도록 제어한다.
이때, SNMP 매니저는 호스트 소프트웨어 콘트롤(Host Software Control)에 속해 있는 객체들을 이용하여 이미지를 구비하고 있는 서버의 주소, 포트, 암호 등의 정보는 "SetRequest" 패킷에 실어 SNMP 에이전트(424)를 통해 IPTV 방송 수신기로 전달하여 미리 설정해 두어야 한다. 이때, 사용자는 상기 업그레이드 또는 다운로드 중이라도 기 시청중인 방송을 계속하여 시청할 수 있다.
SNMP 에이전트(424)는 호스트 소프트웨어의 파일이 모두 전송되고 문제가 없다면, 상기 다운로드한 이미지의 압축을 해제하여 제 2 메모리(422)에 기록하고, 상기 기록 후에 사용자에게 현재 다운로드 상태 및 완료에 대한 정보를 OSD 유닛(425)을 통해 표시하고, 사용자에게 수신기를 재부팅할 것을 알리거나 권유할 수 있다.
그리고 SNMP 에이전트(424)는 상기 재부팅시에 기존 소프트웨어가 저장된 제 1 메모리(421)가 아닌 새로운 소프트웨어가 저장되어 있는 제 2 메모리(422)를 이용하여 부팅하도록 제어할 수 있다. 이때, 만약 상기 재부팅시에 제 2 메모리(422)에 저장된 소프트웨어의 결함 등으로 인해 재부팅에 실패할 경우에는 상기 제 1 메모리(421)의 유효한 특정 구간에 에러를 기록하고 상기 제 1 메모리(421)를 이용하여 다시 재부팅할 수 있다.
상기와 같이 함으로써, IPTV 방송 수신기는 다운로드한 소프트웨어의 에러 등으로 인한 시스템의 피해를 최소화할 수 있다.
또한, 특정 공간에 에러를 기록하는 이유는 나중에 IPTV 방송 수신기가 동작할 때 호스트 소프트웨어 로그 테이블(host software log table)에 표시하여 SNMP 매니저가 접근할 경우 관련 문제점을 알 수 있도록 해야 한다.
즉, SNMP 에이전트(424)는 IPTV 방송 수신기의 제 1 메모리(421) 및 제 2 메모리(422)를 액세스할 수 있으며, 네트워크 인터페이스(423)를 통해 소켓(socket) 통신을 할 수 있다. 또한, SNMP 에이전트(424)는 에러를 보고할 수 있다. 즉, SNMP 에이전트(424)는 어떤 위험한 상황에 대하여 알려야 할 경우에는 호스트 소프트웨어 트랩(Host Software Trap)을 SNMP 매니저로 전송하여 소프트웨어의 버전, 제조사 이름과 함께 트랩의 필요한 정보들도 전송해야 한다.
상술한 IPTV 시스템에는 향후에는 네트워크가 가능한 DSG(DOCSIS(data over cable service interface specifications) settop gateway) 모뎀이 내장할 수 있다. 따라서, 향후에는 상기 DSG 모뎀을 통하여 인터넷으로 메일, 방송 정보, 호텔 및 기차 등과 같은 대중 교통 수단의 예약 발권 그리고 인터넷에서 할 수 있는 대부분의 서비스들을 IPTV 시스템을 통하여 이용할 수 있게 된다.
일반적으로 네트워크 시스템에서 네트워크 리소스(라우터(router), 허브(herb) 등)들을 관리하기 위하여 사용하는 네트워크 프로토콜을 SNMP라고 부르며, 이 프로토콜을 사용하여 멀리 있는 원격지의 네트워크 리소스(network resources)들을 제어하고 중요한 값들을 변경함으로써 치명적일 수 있는 조건의 환경에서 벗어날 수 있도록 그 기능을 제공한다.
도 5는 본 발명에 따라 구성한 IPTV 방송 수신기 블록도의 일 예를 도시한 것이다.
상기 수신기는 네트워크 인터페이스부(network interface)(501), IP 매니저(IP manager)(502), CAS(conditional access system)/DRM(Digital Rights Managment)부(503), 서비스 전달 매니저(service delivery manager)(504), 역다중화부(demultiplexer)(505), 오디오/비디오 디코더(audio/video decoder)(506), 디스플레이부(display apparatus)(507), 애플리케이션 제어부(application controller)(508), 채널 매니저(channel manager)(509), 서비스 정보 디코더(service information decoder)(510), 서비스 디스커버리 매니저(service discovery manager)(511), 서비스 제어 매니저(service control manager)(512), 시스템 매니저(system manager)(513) 및 저장부(storing apparatus)(514)를 구비할 수 있다.
네트워크 인터페이스부(501)는 방송 서비스를 위해 수신기를 네트워크 망과 연결하는 기능을 하는 것으로, 상기 연결된 네트워크 망을 통해 패킷(packet)을 수신하거나 전송할 수 있다.
IP 매니저(502)는 상기 연결된 네트워크 망을 통해 수신하는 패킷이나 전송하는 패킷에 대해 소스(source)로부터 목적지(destination)까지의 상기 패킷의 전달에 관여할 수 있다. 즉, 해당 패킷을 적절한 프로토콜에 대응하도록 분류할 수 있다.
CAS/DRM부(503)는 방송 서비스의 수신 제한과 디지털 저작권 관리와 관련한 기능을 담당한다. 즉, CAS/DRM부(503)는 네트워크 인터페이스부(501)를 통해 연결된 네트워크 망으로부터 방송 서비스와 관련하여 수신한 패킷을 IP 매니저(502)를 통해 수신하여 해당 패킷이 수신 제한되거나 디지털 저작권 관리와 관련하여 제한이 있으면 그 제한을 풀 수 있다. 즉, CAS/DRM부(503)는 수신되는 패킷을 접근하거나 재분배를 통해 제어를 책임진다.
서비스 전달 매니저(504)는 실시간 스트리밍 데이터의 취급을 책임진다. 이때, RTP/RTCP는 MPEG-2 전송 스트림(transport stream)에 사용될 수 있다. 즉, 상기 MPEG-2 패킷들은 RTP에서 캡슐화(captulation)된다. 따라서, 상기 서비스 전달 매니저(504)는 상기 RTP 패킷들을 파싱하여 상기 파싱 결과 캡슐화된 MPEG-2 패킷을 역다중화부(505)로 전송한다. 또는 서비스 전달 매니저(504)는 RTCP를 사용하여 네트워크 수신의 퀄리티(quality)에 대한 피드백(feedback)을 전송할 수 있다. 이때, 상기 MPEG-2 전송 패킷들은 RTP 없이 UDP에 직접적으로 전달할 수 있다.
역다중화부(505)는 수신하는 전송 스트림 패킷들로부터 오디오, 비디오 및 PSI 테이블들을 역다중화한다. 이때, 상기 역다중화부(505)는 PSI 디코더의 제어에 의해 상기 PSI 테이블들을 역다중화하고, 채널 매니저의 제어에 의해 오디오/비디오 전송 패킷들을 역다중화할 것이다. 또한, 상기 역다중화부(505)는 상기 역다중화한 PSI 테이블들의 섹션(section)을 만들어 PSI 디코더로 전송한다.
오디오/비디오 디코더(506)는 상기 역다중화부(505)로부터 역다중화된 오디오/비디오 패킷을 수신하여 처리한다.
디스플레이부(507)는 상기 오디오/비디오 디코더(506)에서 처리된 오디오/비디오 신호를 수신하여 디스플레이(display)한다.
애플리케이션 제어부(508)는 사용자를 위하여 디스플레이부 상의 GUI(graphic user interface)를 지원하며, 리모콘이나 전면 패널(front panel)과 같은 외부 입력 장치를 통한 사용자의 입력을 수신하여, 상기 사용자의 입력이 만약 채널 선택과 관련한 경우에는 상기 입력을 채널 매니저(509)로 전달한다. 또한, 애플리케이션 제어부(508)는 수신기 전체 시스템의 키(key) 상태들을 제어하거나 저장부(514)로 설정 데이터를 저장할 수 있다.
채널 매니저(509)는 채널 맵(channel map)을 만들거나 서비스 디스커버리 매니저(511)를 제어한다. 또한, 채널 매니저(509)는 채널 정보를 위해 서비스 정보 디코더(510)에 요청(request)하거나 재설정(reset)한다. 그리고 채널 매니저(509)는 오디오/비디오 패킷을 수신하도록 역다중화부(505)에 해당 PID(packet identifier)를 설정한다.
서비스 정보 디코더(510)는 PSI/PSIP/DVB-SI와 같은 서비스 정보들을 제어하는 모듈로서, 채널 매니저(509)의 제어에 의한 슬레이브 동작(slave operation)을 한다. 서비스 정보 디코더(510)는 상기 PSI/PSIP/DVB-SI와 같은 서비스 정보들을 역다중화할 수 있도록 해당 PID를 상기 역다중화부(505)로 설정한다. 그리고 서비스 정보 디코더(510)는 상기 설정에 따라 역다중화부에서 만든 각 서비스 정보에 대한 섹션을 수신하여 처리한다. 또한, 서비스 정보 디코더(510)는 서비스 전달 매니저(504)로부터 서비스 정보를 수신하고, 방송 서비스를 위한 서비스 정보 데이터 베이스(service information database)를 만든다.
서비스 디스커버리 매니저(511)는 양방향 서비스가 가능한 IPTV 네트워크를 통해 IPTV 서비스들을 찾아 인에이블(enables)한다. 그리고 서비스 디스커버리 매니저(511)는 선택한 서비스를 위한 모든 정보를 제공한다.
서비스 제어 매니저(512)는 서비스들의 선택과 제어를 담당한다. 예를 들어, 서비스 제어 매니저(512)는 IGMP(internet group management protocol)나 RTSP 프로토콜을 사용하여 라이브 방송 서비스를 선택하거나 RTSP 프로토콜을 사용하여 VOD 콘텐츠를 선택한다. 이때, RTSP 프로토콜은 직접 전달되거나 방송되는 텔레비전과 오디오의 전달의 제어할 때 사용된다. 또한, 상기 RTSP 프로토콜은 지속적인 TCP(transmission control procedure) 연결에 사용하거나 실시간 방송 미디어 스트리밍(real-time broadcasting media string)을 위한 트릭 모드 제어(trick mode control)를 허락하는데 사용한다.
시스템 매니저(513)는 수신기 시스템의 전원의 온/오프에 따른 부트 플로우(boot flow)를 제어하고, 다운로드한 소프트웨어 이미지(software image)를 포함하는 ROM 이미지를 저장부(514)에 쓰거나 저장한다.
저장부(514)는 시스템에 대한 셋업 데이터(setup data) 등을 저장한다. 상기 저장부로 비휘발성 메모리(nonvolatile RAM; NVRAM) 또는 플래쉬 메모리 등을 사용할 수 있다.
저장매체(516)는 역다중화부(505) 또는 오디오/비디오 디코더(506)로부터 전송되는 신호를 일시 저장하였다가 다시 상기 역다중화부(505) 또는 오디오/비디오 디코더(506)로 전송하는 기능을 한다. 이때, 상기 저장매체(516)는 저장매체 제어부(515)의 제어를 받아 수신되는 신호로부터 데이터를 쓰고, 신호를 저장하고 역다중화부(505)로 제공한다.
이하에서는 IPTV 환경에서 원격에서 소프트웨어 업그레이드하는 방법과 에러 관리를 하는 방법의 실시 예를 살펴보되, 이를 나누어서 살펴본다.
먼저, 도 6은 본 발명에 따라 IPTV 환경에서 원격에서 IPTV 방송 수신기의 소프트웨어를 업그레이드하는 방법의 일 예를 도시한 순서도이다. 이때, 원격은 서비스 제공업자(SP)를 예시로 한다. 즉, IPTV 환경에서 서비스 제공업자(SP)가 네트워크로 연결된 각 IPTV 방송 수신기의 소프트웨어를 업그레이드하는 방법에 대한 내용이다.
이를 위해, 서비스 제공업자(SP)는 먼저, 네트워크로 연결된 각 IPTV 방송 수신기 중 해당 수신기에 접속을 요청하고, 네트워크를 관리할 수 있는 프로토콜(SNMP)의 버전에 따라 접속을 허용한 사용자에게 접속한다. 그리고 서비스 제공업자(SP)는 해당 수신기의 소프트웨어 업그레이드와 관련하여 필요한 정보를 요청한다.
상기 요청에 따라 해당 수신기는 해당 정보를 수집하여 상기 서비스 제공업자(SP)에게 전송하고, 상기 서비스 제공업자(SP)가 업그레이드가 필요하여 전송하는 소프트웨어의 정보를 각 단계별로 수신하여 설정하고, 소프트웨어를 다운로드하여 압축을 해제하는 등의 동작을 한다. 그리고 IPTV 방송 수신기는 최종적으로 소프트웨어를 업그레이드한다.
상술한 내용을 보다 구체적으로 설명하면, 다음과 같다.
서비스 제공업자(SP)는 기 정해진 MIB 파일에 의해 구현되는 SNMP 프로토콜을 이용하여 네트워크로 연결된 각 IPTV 방송 수신기가 구비하고 있는 소프트웨어에 대한 정보를 요청한다(S601). 이는 서비스 제공업자(SP)는 네트워크로 연결된 각 IPTV 방송 수신기에서 구비하고 있는 소프트웨어의 업그레이드 유무를 판단하기 위함이다. 즉, 서비스 제공업자(SP)는 각 IPTV 방송 수신기가 현재 구동중인 소프트웨어에 대한 정보를 알아야만 업그레이드 유무를 판단할 수 있기 때문이다.
그리고 상기 요청을 수신하는 각 IPTV 방송 수신기는 상기 서비스 제공업자(SP)의 요청이 자신이 관리하고 있는 객체에 대한 요청인지 먼저 판단하고, 상기 판단 결과 자신이 관리하는 객체에 대한 요청이면 그에 따른 정보를 수집한다. 그리고 상기 수집한 정보를 다시 서비스 제공업자(SP)로 전송하고, 상기 서비스 제공업자(SP)는 각 IPTV 방송 수신기에서 수집한 정보를 수신한다(S602).
이에 따라 서비스 제공업자(SP)는 각 IPTV 방송 수신기로부터 수신한 정보를 이용하여, 해당 수신기에서 구비하고 있는 소프트웨어의 업그레이드 유무를 판단한다.
그리고 서비스 제공업자(SP)는 상기 업그레이드 유무 판단 결과 업그레이드가 필요한 IPTV 방송 수신기로 소프트웨어 업그레이드가 필요함을 화면에 표시하여 사용자에게 문의하도록 제어하는 신호를 해당 수신기로 전송한다.
이에 따라 IPTV 방송 수신기는 상기 서비스 제공업자(SP)의 문의 요청에 따라 소프트웨어 업그레이드가 필요하고, 업그레이드 여부를 화면에 표시하여 사용자에게 문의하고, 상기 문의 결과를 서비스 제공업자(SP)로 전송한다.
서비스 제공업자(SP)는 상기 문의 결과가 수신하고, 상기 문의 결과가 업그레이드를 수락한다는 내용이면, 업그레이드에 필요한 소프트웨어 정보, 업그레이드할 소프트웨어 및 상기 업그레이드할 소프트웨어가 해당 수신기에 설정되도록 하는 제어 신호를 해당 수신기로 전송한다(S603). 그러나 서비스 제공업자(SP)는 상기 문의 결과가 업그레이드를 거부한다는 내용이라면, 상기 업그레이드와 관련된 모든 과정을 종료한다.
다음으로, IPTV 환경에서 원격에서 에러 관리를 포함한 각 IPTV 방송 수신기를 관리하는 방법의 실시 예를 설명한다. 도 7은 본 발명에 따라 IPTV 환경에서 원격에서 에러 관리하는 방법의 일 예를 도시한 순서도이다.
도 7은 상술한 도 6이 원격에서 네트워크로 연결된 각 IPTV 방송 수신기의 소프트웨어를 SNMP 프로토콜을 이용하여 업그레이드하는 것에 대한 내용인데 반해, 원격에서 네트워크로 연결된 각 IPTV 방송 수신기를 관리할 수 있도록 하는 방법에 대한 내용이다.
이를 위해 각 IPTV 방송 수신기는 원격에서 요청이 없더라도 자신이 관리하는 객체들 중에서 특정 이벤트나 응급 상황 등이 발생하면 상기 원격으로 보고하여야 한다.
보다 구체적으로 설명하면, 다음과 같다.
IPTV 방송 수신기는 자신이 관리하는 객체들 중에서 특정 이벤트나 응급 상황 등이 발생하면, 그에 따른 정보를 수집하고(S701), 상기 수집한 정보를 네트워크를 관리할 수 있는 프로토콜(SNMP)에 따라 원격으로 전송한다(S702).
이에 따라 원격에서는 네트워크로 연결된 각 IPTV 방송 수신기의 상태를 실시간으로 알 수 있으며, 필요한 조치를 강구할 수 있다. 이 또한, IPTV 환경에서의 양방향 서비스의 장점 중에 하나로, 원격(예를 들어, 서비스 제공업자(SP))에서 실시간으로 각 IPTV 방송 수신기를 항상 감시한다는 것은 너무 많은 부담을 지게 된다.
따라서, 상기와 같이 원격이 아닌 각 IPTV 방송 수신기에서 자신이 관리하는 객체들에 특정 이벤트나 응급 상황 등이 발생할 때마다 실시간으로 그 정보를 수집하여 전송하면, 원격에서는 손쉽게 네트워크로 연결된 각 IPTV 방송 수신기를 관리할 수 있으며, 필요한 경우 그에 따른 조치를 적절하게 취할 수 있다.
이때, 상기 특정 이벤트나 응급 상황은 예를 들어, 원격에서 업그레이드를 위해 다운로드 시킨 소프트웨어에 대한 다운로드가 완료되었음을 나타내는 정보, 상기 다운로드에 실패하였음을 나타내는 정보, 저장장치에 수신한 소프트웨어 이미지를 성공적으로 저장 내지 프로그램했음을 나타내는 정보, 상기 업그레이드를 위하여 소프트웨어를 제공하는 서버에 접속할 수 없음을 나타내는 정보, 업그레이드한 소프트웨어를 이용하여 부팅시에 문제가 발생했음을 나타내는 정보 중 적어도 하나 이상을 포함할 수 있다.
이상에서 설명한 바와 같은 본 발명에 따른 IPTV 환경에서 소프트웨어 업그레이드 방법에 의하면,
첫째, 서비스 제공업자는 네트워크로 연결된 IPTV 방송 수신기의 소프트웨어를 업그레이드할 수 있다.
둘째, IPTV 방송 수신기는 네트워크로 연결된 서비스 제공업자로 수신기에 문제와 같이 기 설정한 이벤트 등이 발생한 경우에 그에 대한 정보를 제공할 수 있는 효과가 있다.
셋째, IPTV 방송 수신기는 업그레이드한 소프트웨어가 제대로 기능을 수행하 지 않는 경우 기존의 소프트웨어를 이용하여 방송 수신기가 작동하도록 하여 소프트웨어의 버그에 따른 문제를 최소화할 수 있는 효과가 있다.
넷째, IPTV 방송 수신기의 문제가 발생하여 A/S(after service)등의 경우에 각 가정을 방문하지 않아도 원격지에서 각 IPTV 방송 수신기의 문제를 파악할 수 있으며 소프트웨어 업그레이드 등을 통해 처리함으로써 A/S에 따른 비용 및 고객의 불만을 최소화할 수 있는 효과가 있다.
이상 설명한 내용을 통해 당업자라면 본 발명의 기술 사상을 일탈하지 아니하는 범위에서 다양한 변경 및 수정 가능함을 알 수 있을 것이다.
따라서, 본 발명의 기술적 범위는 실시 예에 기재된 내용으로 한정되는 것이 아니라 특허 청구의 범위에 의하여 정해져야 한다.

Claims (30)

  1. 네트워크로 연결된 적어도 하나 이상의 IPTV 방송 수신기에 포함된 소프트웨어에 대한 정보를 상기 네트워크를 관리하는 프로토콜을 이용하여 업그레이드하는 방법에 있어서,
    상기 소프트웨어에 대한 정보를 요청하는 단계;
    상기 요청에 따라 수집한 정보를 수신하는 단계로서, 상기 수신하는 수집 정보는 소프트웨어 인포메이션에 대한 정보, 소프트웨어 제어에 대한 정보, 소프트웨어 로그에 대한 정보와 소프트웨어 그룹에 대한 정보 중 적어도 하나 이상을 포함하고; 및
    업그레이드할 소프트웨어에 대한 정보와 소프트웨어를 전송하여 설치하는 단계를 포함하는 소프트웨어 업그레이드 방법.
  2. 삭제
  3. 제1항에 있어서,
    상기 소프트웨어 인포메이션에 대한 정보는 부팅 성공 횟수, 제조 회사 이름, 모델 이름, 해당 모델의 시리얼 넘버, 하드웨어 버전, 저장장치의 인덱스, 상기 저장장치의 크기, 해당 소프트웨어 크기, 소프트웨어 이미지의 버전, 상기 소프트웨어 이미지의 생산 날짜 및 발행일을 나타내는 정보 중 적어도 하나 이상을 포함하는 소프트웨어 업그레이드 방법.
  4. 제1항에 있어서,
    상기 소프트웨어의 제어에 대한 정보는 소프트웨어 이미지의 서버 주소나 URL, 압축된 소프트웨어 이미지를 풀 수 있는 액세스 코드, 소프트웨어 서버에 입장하기 위한 패스워드, 새로운 소프트웨어 이미지 파일 이름, 화면에 표시할 메시지, 상기 화면에 표시한 메시지에 대한 사용자의 반응, 다운로드 동작 설정에 대한 정보 중 적어도 하나 이상을 포함하는 소프트웨어 업그레이드 방법.
  5. 제 4항에 있어서,
    상기 다운로드 동작 설정에 대한 정보는 다운로드한 소프트웨어를 수신하였다는 정보, 복구했다는 정보, 업그레이드했다는 정보 및 재부팅했다는 정보 중 어느 하나인 소프트웨어 업그레이드 방법.
  6. 제1항에 있어서,
    상기 소프트웨어 로그에 대한 정보는 엔트리를 생성한 날짜, 벤더에 의해 정의된 로그의 레벨 및 로그 메시지에 대한 정보 중 적어도 하나 이상을 포함하는 소프트웨어 업그레이드 방법.
  7. 제1항에 있어서,
    상기 소프트웨어 그룹에 대한 정보는 부트 이미지에 사용할 인덱스에 대한 정보를 포함하는 소프트웨어 업그레이드 방법.
  8. 네트워크로 연결된 서비스 제공업자로 상기 네트워크를 관리하는 프로토콜을 이용하여 정보를 송신하는 방법에 있어서,
    원격에서 요청이 없는 경우에, IPTV 방송수신기가 자신이 관리하는 정보들 중 적어도 어느 하나에 기정의한 중요한 이벤트나 응급 상황이 발생한 경우, 상기 중요한 이벤트나 응급 상황의 발생을 나타내는 정보를 전송하는 단계를 포함하는 정보 송신 방법.
  9. 제 8항에 있어서,
    상기 중요한 이벤트나 응급 상황의 발생하였음을 나타내는 정보는 소프트웨어 다운로드 완료, 상기 다운로드 실패, 저장장치에 수신한 소프트웨어 이미지를 성공적으로 프로그램했음, 소프트웨어를 제공하는 서버에 접속할 수 없음, 부팅시 중요한 문제가 발생했음을 나타내는 정보 중 적어도 하나 이상을 포함하는 정보 송신 방법.
  10. 제 8항에 있어서,
    상기 중요한 이벤트나 응급 상황의 발생을 나타내는 정보는 상기 서비스 제공업자가 액세스할 수 없는 정보인 정보 송신 방법.
  11. 제 8항에 있어서,
    상기 네트워크를 관리하는 프로토콜은 Simple Network Management Protocol(SNMP) 프로토콜을 포함하는 정보 송신 방법.
  12. 네트워크로 연결되어 양방향 통신이 가능한 IPTV 방송 수신기에 있어서,
    상기 네트워크와 연결하는 네트워크 인터페이스;
    기존 소프트웨어에 대한 정보를 저장하는 영역과 업그레이드하는 소프트웨어에 대한 정보를 저장하는 영역을 포함하는 저장부; 및
    상기 네트워크를 관리하는 프로토콜에 따라 기존 소프트웨어에 대한 정보 수집 요청에 따라 정보를 수집하도록 제어하거나, 상기 수집한 정보를 전송하도록 제어하거나, 소프트웨어 업그레이드에 관한 문의를 수신하고 그에 따른 결과를 보고하도록 제어하거나, 소프트웨어에 대한 정보와 소프트웨어를 수신하여 설치하도록 제어하는 제어부, 여기서 상기 제어부는 자신이 관리하는 정보들 중 어느 하나에 중요한 이벤트나 응급상황이 발생한 경우에는 그에 따른 정보를 상기 네트워크를 관리하는 프로토콜에 따라 전송하도록 제어하는 것을 특징으로 함;
    를 포함하는 IPTV 방송 수신기.
  13. 제 12항에 있어서, 상기 IPTV 방송 수신기는
    상기 소프트웨어 업그레이드에 관한 문의를 수신하여 표시하는 표시부를 더 포함하는 IPTV 방송 수신기.
  14. 삭제
  15. 제12항에 있어서,
    상기 네트워크를 관리하는 프로토콜은 SNMP 프로토콜을 포함하는 IPTV 방송 수신기.
  16. 제 1항에 있어서,
    상기 네트워크를 관리하는 프로토콜은 Simple Network Management Protocol(SNMP) 프로토콜을 포함하는 소프트웨어 업그레이드 방법.
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
KR1020060127692A 2006-11-24 2006-12-14 Iptv 환경에서 소프트웨어 업그레이드 방법 및 장치 KR101314605B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US86081206A 2006-11-24 2006-11-24
US60/860,812 2006-11-24

Publications (2)

Publication Number Publication Date
KR20080047227A KR20080047227A (ko) 2008-05-28
KR101314605B1 true KR101314605B1 (ko) 2013-10-07

Family

ID=39663887

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020060127692A KR101314605B1 (ko) 2006-11-24 2006-12-14 Iptv 환경에서 소프트웨어 업그레이드 방법 및 장치

Country Status (1)

Country Link
KR (1) KR101314605B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101253472B1 (ko) * 2012-09-17 2013-04-10 한화에스앤씨주식회사 소켓 통신을 이용한 원거리 셋톱박스 제어 방법 및 시스템

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100318876B1 (ko) * 1997-12-26 2002-03-25 모리시타 요이찌 전송장치와수신장치를포함하는소프트웨어다운로드시스템
JP2006018359A (ja) * 2004-06-30 2006-01-19 Sony Corp クライアントサーバシステム、クライアント端末、更新情報提供サーバ、更新処理プログラム、及び更新情報提供プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100318876B1 (ko) * 1997-12-26 2002-03-25 모리시타 요이찌 전송장치와수신장치를포함하는소프트웨어다운로드시스템
JP2006018359A (ja) * 2004-06-30 2006-01-19 Sony Corp クライアントサーバシステム、クライアント端末、更新情報提供サーバ、更新処理プログラム、及び更新情報提供プログラム

Also Published As

Publication number Publication date
KR20080047227A (ko) 2008-05-28

Similar Documents

Publication Publication Date Title
US10911834B2 (en) User selection of software components in a television set-top box
EP1909459B1 (en) Apparatus for receiving adaptive broadcast signal and method thereof
US8112775B2 (en) IPTV receiver and method of providing channel details information
US8813155B2 (en) Method for receiving service information data and an IPTV receiver
US8397256B2 (en) IPTV receiver and method of providing channel map information
US8893205B2 (en) IPTV receiver and method of providing channel map management information
US8893200B2 (en) IPTV receiver and method of acquiring a resource for an IPTV service
EP2139237B1 (en) An IPTV receiver and method for controlling contents viewing in the IPTV receiver
US20150172731A1 (en) Methods and apparatus for providing alternate content
US8869219B2 (en) Method for controlling a channel and an IPTV receiver
US20090144790A1 (en) Broadcast receiver and method for receiving adaptive broadcast signal
CA2609820C (en) Method and system of configuring media units
US8484689B2 (en) IPTV receiver and method of discovering an IPTV service
US9204204B2 (en) System for managing a configuration of a media content processor
CA2645979C (en) A method for controlling a channel and an iptv receiver
US8667551B2 (en) System for configuring a media processor
US20090070471A1 (en) Method for recovering a video-on-demand session
KR101314605B1 (ko) Iptv 환경에서 소프트웨어 업그레이드 방법 및 장치
CN101257612B (zh) Iptv接收器和在iptv接收器中处理分级信息的方法
KR102493299B1 (ko) 전자장치, 그의 제어 방법, 프로그램, 기록매체 및 iptv 시스템
KR20110032723A (ko) 소프트웨어 다운로드 방법

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20160824

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20170814

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20180814

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20190814

Year of fee payment: 7