KR101652445B1

KR101652445B1 - Ｉｐｔｖ 수신기 및 ｉｐｔｖ수신기에서 퍼스널 비디오 레코더 기능을 수행하는 방법

Info

Publication number: KR101652445B1
Application number: KR1020117018430A
Authority: KR
Inventors: 김경호; 손형호; 이준휘; 서종열
Original assignee: 엘지전자 주식회사
Priority date: 2009-01-05
Filing date: 2010-01-05
Publication date: 2016-09-09
Also published as: EP2377316A2; WO2010077123A3; WO2010077123A2; KR20110100675A; CN102365870B; CN102365870A; US8417091B2; US20100178031A1; EP2377316A4

Abstract

본 발명은 상기와 같은 과제를 해결하기 위한 것으로, 본 발명에 따라 인터넷 프로토콜 텔레비전(IPTV)에서 PVR 기능을 실행하는 방법의 일 예는, 서버로부터 위젯 애플리케이션을 다운로드하는 단계; 유저로부터 상기 다운로드된 위젯 애플리케이션을 실행하기 위한 제 1요청을 수신하는 단계; 상기 제 1 요청에 따라 다운로드된 위젯 애플리케이션을 브라우저에 실행하는 단계; 상기 유저로부터 실행된 위젯 애플리케이션을 통해 특정 PVR 기능을 실행하기 위한 제 2 요청을 수신하는 단계; 및 상기 제 2 요청에 따라 상기 특정 PVR 기능을 실행하는 단계를 포함한다. 다른 관점에서, 본 발명에 따른 PVR 기능을 실행하는 인터넷 프로토콜 텔레비전(IPTV)의 일 예는, 저장 장치; 서버로부터 위젯 애플리케이션을 다운로드하는 제 1 수신부; 유저로부터 상기 다운로드된 위젯 애플리케이션을 실행하기 위한 제 1요청을 수신하고, 상기 유저로부터 실행된 위젯 애플리케이션을 통해 특정 PVR 기능을 실행하기 위한 제 2 요청을 수신하는 제 2 수신부; 상기 제 1 요청에 따라 다운로드된 위젯 애플리케이션을 브라우저에 실행하고 상기 제 2 요청에 따라 상기 특정 PVR 기능을 실행하는 제어부; 및 상기 다운로드된 위젯 애플리케이션이 실행되기 위한 상기 브라우저를 포함하여 구성된다.

Description

ＩＰＴＶ 수신기 및 ＩＰＴＶ수신기에서 퍼스널 비디오 레코더 기능을 수행하는 방법{AN IPTV RECEIVER AND METHOD FOR PERFORMING A PERSONAL VIDEO RECORDER FUNCTION IN THE IPTV RECEIVER}

본 발명은 IPTV에 관한 것으로, 더욱 상세하게는 ITF에서 PVR 기능을 지원하는 PVR 위젯 애플리케이션을 제어하는 방법 및 IPTV에 관한 것이다.

종래 방송 수신기는 지상파, 위성, 케이블과 같은 방송 매체를 통해 방송 신호를 수신하여 사용자에게 제공하였으나, 최근에는 IP를 통해 방송 신호를 IP 패킷으로 송수신하는 IPTV 서비스가 활성화되고 있다. 이러한 IPTV 서비스는 다른 방송 매체와 달리 지리적인 제약이 없다. 즉, IP를 통해 연결되면 IPTV 서비스를 제공받을 수 있다.

다만, 종래 방송 수신기는 기 구비된 PVR 기능만을 이용할 수 있고, 자신만의 고유한 PVR 필터를 구성할 수 없다. 또한, 전송측에서도 수신기에서의 이런한 PVR 동작과 관련하여 컨텐츠에 대한 어떠한 제어도 불가능하였다.

본 발명의 목적은 IPTV 수신기에서 위젯과 같은 설치 가능한 애플리케이션을 이용하여 컨텐츠를 녹화하고 관리할 수 있도록 공통된 API를 제공하고자 한다. 따라서, 이를 통해 컨텐츠 제공자나 서비스 제공자들은 IPTV에서 녹화 및 재생되고 있는 컨텐츠를 제어할 수 있게 된다. 또한, 사용자에게 편리한 인터페이스를 제공하는 위젯들을 제공하여 선택적으로 다운로드하여 사용자가 자신의 IPTV의 레코딩 및 재생 기능을 활용할 수 있다.

본 발명은 상기와 같은 과제를 해결하기 위한 것으로, 본 발명에 따라 인터넷 프로토콜 텔레비전(IPTV)에서 PVR 기능을 실행하는 방법의 일 예는, 서버로부터 위젯 애플리케이션을 다운로드하는 단계; 유저로부터 상기 다운로드된 위젯 애플리케이션을 실행하기 위한 제 1요청을 수신하는 단계; 상기 제 1 요청에 따라 다운로드된 위젯 애플리케이션을 브라우저에 실행하는 단계; 상기 유저로부터 실행된 위젯 애플리케이션을 통해 특정 PVR 기능을 실행하기 위한 제 2 요청을 수신하는 단계; 및 상기 제 2 요청에 따라 상기 특정 PVR 기능을 실행하는 단계를 포함한다.

다른 관점에서, 본 발명에 따른 PVR 기능을 실행하는 인터넷 프로토콜 텔레비전(IPTV)의 일 예는, 저장 장치; 서버로부터 위젯 애플리케이션을 다운로드하는 제 1 수신부; 유저로부터 상기 다운로드된 위젯 애플리케이션을 실행하기 위한 제 1요청을 수신하고, 상기 유저로부터 실행된 위젯 애플리케이션을 통해 특정 PVR 기능을 실행하기 위한 제 2 요청을 수신하는 제 2 수신부; 상기 제 1 요청에 따라 다운로드된 위젯 애플리케이션을 브라우저에 실행하고 상기 제 2 요청에 따라 상기 특정 PVR 기능을 실행하는 제어부; 및 상기 다운로드된 위젯 애플리케이션이 실행되기 위한 상기 브라우저를 포함하여 구성된다.

본 발명에 따르면,

첫째, PVR 위젯 애플리케이션을 다운로드 하거나 사용자가 직접 PVR 서비스 위젯 컴포넌트를 이용하여 위젯을 만들 수 있도록 제조사측에서 API를 오픈 인터넷을 통하여 제공할 수 있는 효과가 있다.

둘째, 컨텐트를 전송하는 서비스 프로바이더에서는 수신기에 PVR 위젯 애플리케이션을 사용하도록 한다면, 엄격한 DRM 기능을 지원할 수 있을 뿐만 아니라 컨텐트의 실제 관리도 가능한 효과가 있다.

셋째, 컨텐츠 프로바이더 또는 서비스 프로바이더는 IPTV에서 녹화 및 재생 가능한 컨텐츠를 제어할 수 있는 효과가 있다.

넷째, 사용자 친화적인 인터페이사들을 제공하는 위젯들은 사용자가 다운로드된 위젯들을 이용하여 자신의 IPTV 수신기의 기능들을 녹화하고 재생 기능들을 이용하고 선택된 위젯들을 다운로드 가능하도록 사용자에게 제공될 수 있는 효과가 있다.

도 1은 본 발명에 따라 위젯 서비스를 제공할 수 있는 IPTV 환경을 설명하기 위해 도시한 도면,
도 2는 본 발명에 따라 IPTV 환경에서 위젯 애플리케이션의 전개(deployment)를 설명하기 위한 일 예를 도시한 도면,
도 3은 본 발명에 따라 IPTV 서비스 프로바이더 내에서 위젯 서비스를 제공하는 과정의 일 예를 설명하기 위한 도면,
도 4는 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제1실시 예를 도시한 것,
도 5는 수신기 프로파일의 스키마 다이어그램의 제2 실시 예를 도시한 것,
도 6은 도 5에 대한 XML 스키마 다이어그램의 일 예를 도시한 것,
도 7은 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제3 실시 예를 도시한 것,
도 8은 본 발명에 따라 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제4 실시 예를 도시한 것,
도 9와 10은 도 8의 XML 스키마를 도시한 것,
도 11은 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제5 실시 예를 도시한 것,
도 12은 도 11의 XML 스키마를 도시한 것,
도 13은 본 발명에 따른 사용자 프로파일의 스키마 다이어그램의 일 예를 도시한 것,
도 14는 도 13의 XML 스키마를 도시한 것,
도 15는 본 발명에 따른 PVR 위젯 익스텐션(Widget Extension)과 IPTV 소프트웨어와의 연관관계를 설명하기 위해 도시한 도면,
도 16은 PVR 익스텐션을 사용하는 PVR 위젯 애플리케이션의 설치 과정의 일 예를 설명하기 위해 도시한 순서도,
도 17은 PVR 위젯 애플리케이션을 이용한 PVR 녹화 방법의 일 예를 설명하기 위해 도시한 순서도,
도 18은 본 발명에 따른 PVR 위젯 애플리케이션을 이용한 Timeshift 방법의 일 예를 설명하기 위해 도시한 순서도,
도 19는 본 발명에 따른 PVR 위젯 애플리케이션을 이용한 컨텐트 이동 방법의 일 예를 설명하기 위해 도시한 순서도, 그리고
도 20은 본 발명에 따라 IPTV 수신기의 블록 다이어그램의 일 예를 도시한 도면이다.

이하, 본 발명의 일 실시예에 따른 광분배 장치를 첨부된 도면을 참고하여 상세히 설명한다. 첨부된 도면은 본 발명의 예시적인 형태를 도시한 것으로, 이는 본 발명을 보다 상세히 설명하기 위해 제공되는 것일 뿐, 이에 의해 본 발명의 기술적인 범위가 한정되는 것은 아니다.

또한, 도면 부호에 관계없이 동일하거나 대응되는 구성요소는 동일한 참조번호를 부여하고 이에 대한 중복 설명은 생략하기로 하며, 설명의 편의를 위하여 도시된 각 구성 부재의 크기 및 형상은 과장되거나 축소될 수 있다.

한편, 제 1 또는 제 2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들이 상기 용어들에 의해 한정되지 않으며, 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별시키는 목적으로만 사용된다.

이하 본 발명에 따라 IPTV 및 IPTV에서 PVR 위젯 애플리케이션을 제어하는 방법의 바람직한 실시 예를 첨부된 도면을 참조하여 설명하면, 다음과 같다. 이하 본 명세서에서 “PVR 위젯 애플리케이션(video widget application)”이라 함은, IPTV 환경에서의 애플리케이션(application)의 하나인 위젯 애플리케이션으로 특히, PVR 기능을 수행하기 위한 위젯 애플리케이션을 말한다.

또한, 이하 본 명세세에서는 본 발명에 따라 IPTV 환경에서 PVR 위젯 애플리케이션을 통해 PVR 기능을 제어하는 방법을 설명하고자 한다. 여기서, 상기 제어라 함은 예를 들어, 상기 PVR 위젯 애플리케이션을 이용하여 컨텐츠에 대한 PVR 기능을 수행하도록 하는 일련의 동작을 의미한다. 또한, 본 명세서에서는 상기 PVR 위젯 애플리케이션과 같은 위젯 애플리케이션이 모든 IPTV 수신기 즉, ITF (IPTV Terminal Function)에서 실행될 수 있도록 표준화된 프레임워크(framework)도 제공하고자 한다. 이는 IPTV 환경에서는 ITF는 각 업체별로 하드웨어와 OS(Operting System) 환경이 서로 다르기 때문이다.

따라서, 본 발명에 따르면, ITF는 PVR 위젯 애플리케이션을 통해 PVR 기능을 수행할 수 있다. 즉, 본 발명에 따르면, 위젯 애플리케이션을 이용하여 PVR 녹화 기능을 제공할 수 있으며, 녹화된 컨텐트를 재생할 수도 있다. 또한, 본 발명에 따르면, 공통된 API들을 IPTV에 내장하여 다양한 기능의 위젯들을 사용자가 선택적으로 다운로드 하여 설치할 수 있다. 그리고 본 발명에 따르면, 위젯 애플리케이션을 통해 트릭 플레이, 예약 녹화(Scheduled recording), 녹화된 컨텐트에 대한 편집이나 화상 추출 기능도 제공할 수 있다.

또한, 컨텐트 프로바이더의 관점에서, PVR 필터는 IPTV 수신기로 쉽게 전송될 수 있다. 그것에 의하여 상술한 PVR 필터를 검색 및 선택의 편의를 위하여, 본 발명은 위젯 애플리케이션을 제공할 수 있다. 또한, 본 발명에서는 비디오 컨텐츠에 적용 가능한 PVR 필터들 또는 수신기 프로파일의 리스트를 관리된다. 그리고 상세 정보는 PVR 필터들의 검색에 이용되도록 서비스 프로바이더 또는 컨텐트 프로바이더로 전송될 수 있다. 더구나, 본 발명에 따르면, PVR 기능이 설정되면, 위젯 애플리케이션은 자동으로 설정되도록 BCG(Broadband Content Guide) 정보 혹은 CoD(Content on Demand) XML(Extensible Markup Language) 스키마(Schema)의 Category 정보를 이용한다. 그리고 각 사용자별로 Widget 애플리케이션에 대한 Configuration 정보(즉, 사용자 프로파일)를 저장하고 IPTV Service Provider가 관리하도록 하여 사용자는 IP가 연결된 어느 곳에서나 자신만의 고유한 위젯 애플리케이션을 사용할 수 있도록 할 수 있다.

도 1은 본 발명에 따라 위젯 서비스를 제공할 수 있는 IPTV 환경을 설명하기 위해 도시한 도면이다.

도 1을 참조하면, IPTV 환경에서 위젯 서비스는 서버에서 네트워크(120)를 통해 수신기로 서비스된다. 상기 서버에는, IPTV 서비스에 포함된 컨텐트를 제작하는 컨텐츠 프로바이더(130)와 수신기 제조업체 서버(135), 위젯 서비스 프로바이더들(140,145) 등 서비스 프로바이더가 포함될 수 있다. 상기 수신기에는, IPTV 수신기(100), 상기 IPTV 수신기(100)를 통해 수신된 IPTV 서비스를 출력하는 디스플레이 기기(105), 상기 IPTV 수신기 (100)가 인터넷에 접근할 수 있도록 도와주는 (DNGDelivery Network Gateway)(110) 등이 포함될 수 있다. 여기서, 상기 네트워크(120)는 오픈 인터넷(Open Internet)(또는 Unmanaged Network) 또는 관리된 네트워크(Managed Network)일 수 있다.

도 1을 참조하면, 위젯 서비스는 서비스 프로바이더의 일종인 위젯 서비스 프로바이더들(140,145)에 제공되는 것으로 예시하였으나, 그 밖에 Content Provider또는 수신기 제조업체 서버(135)를 통해서도 제공될 수 있다. 이하에서는 상기 위젯 서비스로 본 발명에 따라 PVR 위젯 애플리케이션을 예로 하나 다른 기능을 수행할 수 있는 위젯 애플리케이션도 포함될 수 있다.

도 2는 본 발명에 따라 IPTV 환경에서 위젯 애플리케이션의 전개(deployment)를 설명하기 위한 일 예를 도시한 도면이다.

도 2를 참조하면, 서버는 게이트-웨이(210)를 통해 접근 가능한 ITF(200)로 위젯 서비스를 전송한다.

서버는 CoD 서버(CoD Server)(220), 위젯 서버(Widget Server)(230) 그리고 제조사 서버(Manufacturer Server)(240)를 포함할 수 있다. 상기 CoD 서버(220)는 CoD (Content on Demand) 서비스를 제공하는 서버로서, 컨텐트/DRM 서비스 위젯 컴포넌트(service widget component)가 저장된 데이터베이스를 포함한다. 상기 제조사 서버(240)는 예를 들어, ITF를 제조한 제조업체 서버로서, 자신들이 제조한 ITF에 적합한 PVR 서비스 위젯 컴포넌트가 저장된 데이터베이스를 포함한다. 상기 위젯 서버(230)는 PVR 위젯 애플리케이션을 제공하는 서비스 프로바이더로, PVR 위젯 애플리케이션을 직접 제작하여 제공하거나 또는 제작된 PVR 위젯 애플리케이션을 수신하여 서비스할 수 있다. 또한, 상기 CoD 서버(220)와 제조사 서버(240)는 구비된 데이터베이스에서 PVR 위젯 애플리케이션과 관련된 컴포넌트들을 게이트웨이(210)를 거쳐 ITF(200)로 임포트(import)할 수 있다.

ITF(200)는 위젯 애플리케이션(Widget application)을 실행하기 위해 필요한 모듈들, 위젯 애플리케이션을 저장하는 위젯 저장부(205), 사용자 프로파일 저장부(206) 및 PVR 저장부(207)를 포함할 수 있다. 도 2에서 상기 ITF(200) 내 위젯 애플리케이션 실행을 위해 필요한 모듈로 위젯 매니저/런쳐 모듈(a Widget Manager/Launcher module)(201), 위젯 런타임 프레임워크 모듈(a Widget Runtime Framework module)(202) 그리고 제너릭 PVR 오브젝트 익스텍션 모듈(Generic PVR object Exension (plug-in) module)(203)이 포함될 수 있다. 위젯 저장부(205), PVR 저장부(207), 유저 프로파일 저장부(206)은 PVR 하드웨어 추상 레이어(a PVR Hardware Abstraction Layer)(204)에 종속된다. 다만, 도 2에서 예시된 ITF의 구성은 위젯 애플리케이션 동작과 관련하여 최소한의 구성을 예시한 것으로 이에 한정되지 않는다.

위젯 매니저/런쳐(201)은 게이트웨이(210)를 통해 수신된 위젯 애플리케이션을 설치 및 관리할 수 있고, 유저 프로파일 저장부(206)에 따라 설치된 위젯 애플리케이션을 론치(launch)할 수 있다.

제조사 서버(240)는, ITF에 대한 하드웨어의 세부적인 동작을 제어할 수 있는 위젯 애플리케이션이나 PVR 관련 컴포넌트(component)와 같은 디바이스-스페스픽 정보(device-specific information)들을 만들어 다른 3rd 파티 위젯 애플리케이션과 연동할 수 있도록 배포할 수도 있다. 따라서, ITF(200)에서는 이를 수신하여 유저 프로파일 저장부(206)에 저장할 수 있다.

ITF(200)는 위젯 애플리케이션을 다운로드하고 설치할 수 있으며, IPTV의 하드웨어 프로파일 즉, 수신기 프로파일과 사용자 프로파일을 이용하여 각 ITF(200)에 따라 설치 가능한 위젯 애플리케이션을 식별할 수 있다.

도 3은 본 발명에 따라 IPTV 서비스 프로바이더 내에서 위젯 서비스를 제공하는 과정의 일 예를 설명하기 위한 도면이다.

여기서, 상기 위젯 서비스 과정(또는 위젯 서비스 제공 과정)에는 위젯 서비스 프로바이더(310), IPTV 서비스 프로바이더(320), 게이트 웨이(330) 그리고 IPTV 수신기(340)가 관여될 수 있다. 다만, 상기한 예시에 한정되는 것은 아니며, IPTV 환경에서 위젯 서비스의 제공과 관련하여 별도의 구성이 더 포함되거나 반대로 일부 구성이 제외되거나 특정 구성이 다른 구성으로 대체될 수도 있다. 예를 들어, 도 3에서 위젯 서비스 프로바이더(310)와 IPTV 서비스 프로바이더(320)는 동일한 개체(entity)일 수 있다.

사용자에 의해 IPTV 수신기(340)의 전원이 켜지면(STEP 1), IPTV 수신기(340)는 IPTV 서비스 프로바이더(320)로 웹 브라우저 초기 페이지를 요청을 전송한다(STEP 2). 그 이후, IPTV 수신기(340)는 IPTV 서비스 프로바이더(320)로부터 상기 요청에 따른 서비스 프로바이더의 페이지를 수신한다(STEP 3).

IPTV 수신기(340)는 수신된 요청된 서비스 프로바이더 페이지를 화면을 통해 사용자에게 제공한다(STEP 4). 또한, 상기 IPTV 서비스 프로바이더(320)는 IPTV 서비스 프로파일 기능적인 개체(FE: Functional Entity)와 동일한 개체(Entity)일 수 있다. 그리고 상기 IPTV 서비스 프로바이더(320)는 IPTV 수신기(340)에서 디폴트로 설정된 IPTV 서비스 프로바이더일 수 있다.

IPTV 수신기(340)는 사용자가 화면을 통해 제공된 초기 페이지로부터 IPTV 위젯 서비스 또는 제공자를 선택(또는 클릭)하면(STEP 5), 위젯 서비스 프로바이더(310)로 접속하여 IPTV 위젯 서비스 프로바이더 초기 페이지를 요청한다(STEP 6). 위젯 서비스 프로바이더(310)는 상기 요청에 따라 IPTV 위젯 서비스 페이지를 IPTV 수신기(340)로 전송하고, IPTV 수신기(340)는 상기 전송된 IPTV 위젯 서비스 페이지를 화면을 통해 사용자에게 제공한다(STEP 7). 여기서, 상기 위젯 서비스 프로바이더(310)는 예를 들어, IPTV 애플리케이션 FE와 동일한 개체(Entity)일 수 있다. 또한, 상기에서 IPTV 수신기(340)는 사용자가 위젯 서비스 또는 제공자를 선택하면 상기 초기 페이지 요청시에 IPTV 수신기(340)에 대한 프로파일(즉, 수신기 프로파일)을 프로톨콜에 따라 상기 요청과 함께 전송할 수도 있다.

IPTV 수신기(340)는 사용자가 특정 위젯 서비스를 선택하면(STEP 8), 선택된 위젯 서비스를 제공하는 위젯 서비스 프로바이더(310)로 해당 위젯 애플리케이션의 다운로드를 요청한다(STEP 9). 상기 위젯 서비스 프로바이더(310)는 상기 IPTV 수신기(340)의 다운로드 요청에 따라 선택된 IPTV 위젯 애플리케이션을 패키지 파일 형태로 전송한다(STEP 10). 이 과정에서 사용자는 IPTV 수신기(340)의 화면을 통해 표시된 IPTV 위젯 서비스 페이지로부터 위젯 애플리케이션을 검색할 수 있다. 즉, 사용자는 사용자 장비 클래스(User Equipment Class)(UE) 능력(Capacity)에 적합한 위젯 애플리케이션을 검색할 수 있다.

IPTV 수신기(340)는 위젯 서비스 프로바이더(310)로부터 수신된 패키지 내 IPTV 위젯 애플리케이션에 관하여, OSD(On Screen Display) 등을 통해 사용자의 설치 여부를 확인한다(STEP 11). IPTV 수신기(340)는 상기 확인 결과, 사용자가 설치를 원하면 상기 수신된 패키지 내 IPTV 위젯 애플리케이션의 설치를 승인한다(STEP 12).

IPTV 수신기(340)는 사용자로부터 승인이 이루어지면, 상기 수신된 패키지 내 IPTV 위젯 애플리케이션을 설치한다(STEP 13). 또한, IPTV 수신기(340)는 상기 설치된 IPTV 위젯 애플리케이션을 초기화하여(STEP 14) 사용자에게 제공하고, 사용자로부터 설치된 IPTV 위젯 애플리케이션에 대한 설정을 수신한다(STEP 15).

IPTV 수신기(340)는 사용자가 설치된 IPTV 위젯 애플리케이션과 관련하여 설정한 위젯 구성 정보가 포함된 사용자 프로파일을 저장하고(STEP 16), 저장된 사용자 프로파일을 게이트웨이(330)를 경유하여 IPTV 서비스 프로바이더(320)에 저장하도록 요청하고(STEP 17), IPTV 서비스 프로바이더(320)는 상기 사용자 프로파일을 저장한다(STEP 19). 이 과정에서 IPTV 수신기(340)는 상기 사용자의 설정이 적용된 위젯 애플리케이션을 동작시킬 수 있다(STEP 18). 여기서, 도 3에서는 IPTV 서비스 프로바이더(320)에 사용자 프로파일이 저장되는 것으로 예시하였으나 다른 예로 위젯 서비스 프로바이더(310)에 저장될 수도 있다. 이러한 사용자 프로파일은 서버(310 및/또는 320)에서 사용자 별로 구분되어 데이터베이스화되어 저장될 수 있다. 따라서, 사용자는 예를 들어, 언제 어디서든 상기 서버에 접속하여 자신의 사용자 프로파일 정보를 호출하여 자신의 IPTV 수신기가 아닌 다른 IPTV 수신기에서도 자신만의 위젯 애플리케이션을 이용할 수 있다.

이하에서는 상술한 도 3에서의 수신기 프로파일과 사용자 프로파일에 대해 도 4, 5 및 6을 참조하여 보다 상세하게 설명한다.

도 4는 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제1실시 예를 도시한 것이고, 도 5는 수신기 프로파일의 스키마 다이어그램의 제2 실시 예를 도시한 것이며, 도 6은 도 5에 대한 XML 스키마 다이어그램의 일 예를 도시한 것이다.

검색된 위젯 애플리케이션을 다운로드 받기 위하여, 위젯 애플리케이션을 검색/브라우징하고, 서버로 위젯 애플리케이션의 실행 조건(또는 환경) 예를 들어, IPTV 수신기 기능들, 이용 가능한 리소스 양(또는 사이즈) 기타 등등과 관련된 정보를 전송함으로써, IPTV 수신기에서는 적절한 위젯 애플리케이션을 선택적으로 다운로드 받을 수 있다.

이하에서는 IPTV 수신기로부터 전송되는 상술한 수신기 프로파일을 다음과 같이 설명하고자 한다.

도 4를 참조하면, 유저 프로파일은, UserEquipmentID 엘레멘트, UserEquipmentClass 엘레멘트, Resolution 엘레멘트, SupportedEncodings 엘레멘트, IPEncapsulations 엘레멘트와 Extension 엘레멘트가 포함되어 있다.

UserEquipmentID 엘레멘트는 해당 IPTV 수신기의 모델(Model) UID(Unique Identifier)를 포함한다. Resolution 엘레멘트는 해당 IPTV 수신기의 비디오 해상도(video resolution) 정보를 포함한다. 그리고 SupportedEncodings 엘레멘트는 해당 IPTV 수신기의 PVR 기능에 대한 정보를 포함한다.

도 5의 수신기 프로파일은 도 4의 수신기 프로파일에 Graphic Resolution 엘레멘트, Graphic colors 엘레멘트, Available Resources 엘레멘트 and PVR 엘레멘트를 더 포함한 예시이다.

도 5 내지 6을 참조하면, Graphic colors 엘레멘트는 tGraphicColor 타입(Type)으로 정의되어, 그래픽 컬러에 대한 IPTV 수신기의 처리 능력을 나타내는 정보를 포함한다. 여기서, 상기 그래픽 컬러는 OSD에 그래픽 데이터(graphic data)를 렌더링할 때 각 화소의 비트-깊이(Bit-depth)를 말한다. 상기 tGraphicColor 타입은 컬러 뎁쓰 속성에 기초하여 정의될 수 있다. 컬러 뎁쓰 속성의 평가 가치(enumeration value of the color depth attribute)는 32bpp, 24bpp, 16bpp 그리고 8bpp 중 어느 하나의 값을 가질 수 있다.

Graphic Resolution 엘레멘트는 tGraphicResolution 타입으로 정의되어, 그래픽 해상도에 대한 IPTV 수신기의 처리 능력을 나타내는 정보를 포함한다. 여기서, 상기 그래픽 해상도는 위젯 애플리케이션이 쓸 수 있는 OSD 그래픽의 해상도를 말한다. 상기 tGraphicResolution 타입은 Horizontal Size 속성, Vertical Size 속성과 Rotate 속성에 기초하여 정의될 수 있다.

Available Resources 엘레멘트는 tAvailableResolution 타입으로 정의되어, 위젯 애플리케이션을 위해 가용한 리소스 양을 나타내는 정보를 포함한다. 여기서, 상기 리소스 양은 비휘발성(Non-volatile) 메모리와 휘발성(Volatile) 메모리를 말한다.

PVR 엘레멘트는 tPVR 타입으로 정의되고, 사용자 장비에 의해 실행가능한많은 PVR 기능들 사이에서 하나의 기능을 지시하는 정보를 포함한다. 그러므로, 본 발명에서 묘사되는 PVR 기능들 사이에서 사용자 장비는 서버로 실행가능한 필터들을 전송할 수 있고, 그것에 의하여 사용자 장비에 의해 이용 가능한 PVR위젯 애플리케이션을 다운로드하고 이용 가능해진다.

도 7은 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제3 실시 예를 도시한 것이다.

수신기 프로파일의 제3 실시 예는 수신기 성능(Receiver Capabilities)과 관련된 정보를 포함한다. 이러한 수신기 성능(또는 performance)과 관련된 정보는 크게 DeviceInfo Type으로 정의된 DeviceInfo 엘레멘트와 STBService Type으로 정의된 STBService 엘레멘트로 구분된다.

DeviceInfor 엘레멘트는 Manufacturer 엘레멘트, Manufacturer OUI 엘레멘트, Model Name 엘레멘트, description 엘레멘트, productclass 엘레멘트, serial number 엘레멘트, hardware version 엘레멘트, software version 엘레멘트, enabled options 엘레멘트, additional hardware version 엘레멘ㅌ, additional software version 엘레멘트, provisioning 엘레멘트, device status 엘레멘트, Uptime 엘레멘트, DeviceI 엘레멘트, first use data 엘레멘트와 device log 엘레멘트를 포함할 수 있다.

STBService 엘레멘트는, FrontEnd 엘레멘트, PVR (Personal Video Recorder) 엘레멘트, AudioDecoder 엘레멘트, VideoDecoder 엘레멘트, an AudioOutput 엘레멘트, VideoOutput 엘레멘트, CA (Conditional Access) 엘레멘트, DRM (Digital Rights Management) 엘레멘트, ServiceMonitering 엘레멘트와 AudienceStatus 엘레멘트를 포함할 수 있다. 또한, STBService 엘레멘트의 속성들은 MaxActiveAVStreams 속성과 MaxActiveAVPlayers 속성일 수 있다.

도 8은 본 발명에 따라 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제4 실시 예를 도시한 것이고, 도 9와 10은 도 8의 XML 스키마를 도시한 것이다.

도 8에서는 도 7의 DeviceInfo 엘레멘트에 위젯 애플리케이션을 실행하기 위해 사용 가능한 리소스 정보에 관한 AvailableResouces 엘레멘트를 더 포함한다. 상기 AvailableResouces 엘레멘트는 nonVolatileMemory 엘레멘트와 VolatileMemory 엘레멘트를 포함할 수 있다.

도 9와 10을 참조하면, DeviceInfo 엘레멘트의 서브-엘레멘트들은 다음과 같이 설명된다.

DeviceInfo 엘레멘트는 오브젝트의 타입으로 정의된다. 오브젝트는 제너럴 디바이스 정보를 포함한다. Manufacturer 엘레멘트는 CPE (human readable string)의 제조사를 설명하는 스트링(64)의 타입으로 정의된다. Manufacturer OUI 엘레멘트는 조직적으로 디바이스 제조사의 유니크한 ID를 설명하는 스트링(6)의 타입으로 정의된다. Model Name 엘레멘트는 CPE (human readable string)의 모델 네임을 설명하는 스트링(64)의 타입의 정의된다. Description 엘레멘트는 CPE (human readable string)의 풀 디스크립션을 설명하는 스트링(256)의 타입으로 정의된다. Productclass 엘레멘트는 시리얼 넘버가 적용되는 제품의 클래스의 식별자를 설명하는 스트링(64)의 타입으로 정의된다. 즉, 주어진 제조사를 위하여, 이 파라미터는 SerialNumber 파라미터가 유일한 제품의 클래스 또는 제품을 식별하기 위해 사용된다. serial number 엘레멘트는 CPE의 시리얼 넘버를 설명하는 스트링(64)의 타입으로 정의된다.

hardware version 엘레멘트는 특정 CPE 모델과 버전을 식별하는 스트링을 설명하는 스트링(64)의 타입으로 정으된다. software version 엘레멘트는 CPE 내에 현재 설치된 소프트웨어 버전을 식별하는 스트링을 설명하는 스트링(64)의 타입으로 정으된다. enabled options 엘레멘트는 스트링들의 컴마-세퍼레이티드 목록(comma-separated list (maximum length 1024))을 설명하는 스트링(1024)의 타입으로 정으된다. 각 옵션의 OptionName의 컴마-세퍼레이티드 목록은 CPE 네에 현재 인에이블 가능하다. 각 OptionName은 OptionStruct의 OptionName 엘레멘트와 동일하다. 다만, 그러한 상태가 목록화된 그러한 옵션들은 옵션이 인에이블되는지 지시한다. additional hardware version 엘레멘트는 스트링의 컴마-세퍼레이티드 목록(최대 길이 64)을 설명하는 스트링(64)의 타입으로 정의된다. 상기에서 컴마-세퍼레이티드 목록은 어떤 추가적인 버전들이다. 벤더의 additional hardware version 정보의 표현은 제공될 수 있다. additional software version 엘레멘트는 스트링의 컴마-세퍼레이티드 목록(최대 64)을 설명하는 스트링(64)의 타입으로 정으된다. 상기에서 컴마-세퍼레이티드 목록은 어떤 추가적인 버전들이다. 벤더의 어떤 additional software version 정보의 표현은 제공될 수 있다.

provisioning 엘레멘트는, 서비스 프로바이더-스페스픽 커스터마이제이션과 프로비즈닝 파라미터들을 결정하기 위한 프라이머리 서비스 프로바이더와 다른 프로비즈닝 정보의 식별자를 설명하는 스트링(64)의 타입으로 정의된다. device status 엘레멘트는 디바이스의 현재 동작 상태를 설명하는 스트링(64)의 타입으로 정의된다. 현재 동작 상태는 업, 초기화, 에러, 및 불능 중 하나이다. Uptime 엘레멘트는 CPE가 이미 시작되었기 때문에 초단위로 시간을 설명하는 unsignedInt의 타입으로 정의된다. first use data 엘레멘트는 데이트와 UTC(Universal Time Coordinated)를 설명하는 dateTime의 타입으로 정의된다. 여기서, 상기 first use data 엘레멘트는, 처음으로 성공적으로 제창된 IP-레이어 네트워크 연결과 NTP를 이용하여 얻어진 절대 시간 참조 또는 네트워크 연결을 통하여 동등한 CPE에 관한 것이다. 상기 CPE는 팩토리 리셋 이후에 해당 날짜를 리셋할 수 있다. NTP 또는 동등은 이용할 수 없으며, 만약 이 파라미터가 존재하면, Unknown Time 값으로 설정될 수 있다. device log 엘레멘트는 벤더-스페스픽 로드(들)을 설명하는 스트링(32768)의 타입으로 정의될 수 있다.

nonVolatileMemory 엘레멘트는 이용 가능한 비-휘발성 메모리의 양을 설명하는 unsignedInt 타입으로 정의된다. VolatileMemory 엘레멘트는 이용 가능한 휘발성 메모리의 양을 설명하는 unsignedInt 타입으로 정의된다.

도 11은 본 발명에 따라 구성한 수신기 프로파일의 스키마 다이어그램의 제5 실시 예를 도시한 것이고, 도 12은 도 11의 XML 스키마를 도시한 것이다.

도 11에서는 도 7의 STBService 엘레멘트에 셋탑의 OSD Graphic 기능을 기술하기 위하여 Graphic 엘레멘트와 지원 가능한 PVR 기능을 설명하는 PVR 엘레멘트를 더 포함한다. Graphic 엘레멘트는, GraphiResolution 엘레멘트와 GraphicColor 엘레멘트를 더 포함한다.

도 12를 참조하면, STBService 엘레멘트의 서브-엘레멘트들이 다음과 같이설명된다.

FrontEnd 엘레멘트는 네트워크와 STB의 내부 기능 블록들 사이에서 인터페이스로 동작하는 프로트엔드의 기능을 설명한다. PVR 엘레멘트는 PVR의 기능을 설명한다. 여기서, PVR은 어떤 프로트 엔드로부터 오는 프로그램들을 저장할 수 있으며, 오디오 디코더들 및/또는 비디오 디코더들 또는 (출력) IP 프론트 엔드로 저장된 프로그램들을 전송할 수 있다. AudioDecoder 엘레멘트는 오디오 디코더의 기능을 설명한다. 여기서, 오디오 디코더는 엘레멘터리 오디오 스트림을 수신하고, 오디오를 디코딩하고 그리고 오디오 출력 오브젝트로 압축되지 않은 네이티브 오디오 스트림을 출력할 수 있다. VideoDecoder 엘레멘트는, 비디오 디코더의 기능을 설명한다. 여기서, 비디오 디코더는 엘레멘터리 비디오 스트림을 수신하고, 비디오를 디코딩하고 그리고 비디오 출력 오브젝트로 압축되지 않은 네이티브 비디오 스트림을 출력할 수 있다. AudioOutput 엘레멘트는 하나 또는 그 이상의 오디오 디코더들로부터 압축되지 않은 오디오 스트림들을 수신하는 오디오 출력의 기능을 설명한다. 그리고 AudioOutput 엘레멘트는 포맷 적응을 수행한다. VideoOutput 엘레멘트는 하나 또는 그 이상의 오디오 디코더들로부터 압축되지 않은 오디오 스트림들을 수신하는 오디오 출력의 기능을 설명한다. 그리고 VideoOutput 엘레멘트는 포맷 적응을 수행한다. CA 엘레멘트는 STB에 의해 지원되는 CA 메커니즘들의 하나의 상세를 포함하는 CA 컴포넌트의 기능을 설명한다. DRM 엘레멘트는 STB에 의해 지원되는 DRM 메커니즘들의 하나의 상세를 포함하는 DRM 컴포넌트의 기능을 설명한다. ServiceMonitering 엘레멘트는 서비스 타입에 의해 수집된 서비스 모니터링 전략들(service monitoring statistics)을 설명한다. 서비스 타입들을 정의하는 주된 이유는 다른 프로토콜 스택들 및 컨피규레이션들과 멀티플 서비스 타입을 통해 수집된 전략들에 대응되는 그것들이 의미없어지기 때문이다. 그리고 AudienceStatus 엘레멘트는 채널에 의해 오거나이즈된 오디언스 시청 전략들(audience viewing statistics)을 포함하는 전략들을 설명한다.

또한, 도 11과 12에서 추가된 Graphic 엘레멘트에 대한 설명은 전술한 도 5에서의 내용을 원용하고, 여기서 상세한 설명은 생략한다.

도 5와 6에 더하여, 도 11과 12의 PVR 엘레멘트는 MaxIOStreams 속성, MaxRecord-ingStreams 속성, MaxPlaybackStreams 속성, MaxTimeDelay 속성 등과 같은 다수의 속성들을 더 포함한다. 여기서, MaxIOStreams과 MaxRecord-ingStreams 속성은 PVR이 동시에 녹화할 수 있는 AV 스트림들의 최대 개수를 표현할 수 있다. MaxPlaybackStreams 속성은 PVR이 동시에 재생할 수 있는 AV 스트림들의 최대 개수를 표현할 수 있다. 그리고 MaxTimeDelay 속성은 PVR 타임-쉬프트 모드를 지원하는 초단위의 최대 시간 딜레이를 표현할 수 있다. 각 속성은 해당 속성의 값에 따라서 시간 지연 또는 스트림들의 개수에 관한 구체적인 제안이 없음을 지시할 수 있다. 따라서, IPTV 수신기는 복수의 스트림들(또는 컨텐츠)를 저장할 수 있다. 또한, 저장은 동시에 수행될 수 있다. 각 스트림은 메모리의 다른 영역에 저장될 수 있다. 또는 하나의 스트림은 네트워크(예를 들어, 위젯 서버나 IPTV 서비스 프로바이더)에 저장될 수 있고, 다른 스트림은 메모리에 저장될 수도 있다.

이상 상술한 내용은 IPTV 수신기의 수신기 프로파일에 대한 내용이다. 이하에서는 유저 프로파일에 대한 내용을 설명한다. 여기서, 유저 프로파일에는 예를 들어, 사용자가 컨텐츠에 대해 본 발명에 따른 PVR 위젯 애플리케이션을 이용하여 PVR 기능을 적용하는 과정에서 사용자의 설정에 따라 변경된 모든 내용 (예를 들어, 특정 기능의 값을 변경하는 설정 등)이 포함될 수 있다.

도 13은 본 발명에 따른 사용자 프로파일의 스키마 다이어그램의 일 예를 도시한 것이고, 도 14는 도 13의 XML 스키마를 도시한 것이다.

도 13과 14는, 각 IPTV 수신기 별로 설치된 위젯 애플리케이션의 정보 및 환경 설정을 사용자의 프로파일로 관리하여 사용자가 어떤 단말을 통하여 서비스에 접속하더라도 자신이 설정한 환경을 그대로 이용할 수 있도록 하기 위하여 UE 프로파일을 도시하였다.

이하에서는 사용자 프로파일에 포함되는 엘레멘트들 중 전술한 수신기 프로파일에 포함된 엘레멘트들과 중복되는 엘레멘트들에 대해서는 전술한 내용을 원용하여 여기서 상세한 설명은 생략하고, 이하에서는 상이한 부분만을 설명한다. 도 13 내지 14를 참조할 때, 사용자 프로파일은 수신기 프로파일과 달리 ApplicationSettings 엘레멘트를 포함하고 있다. ApplicationSettings 엘레멘트는 ApplicationID 엘레멘트, RevisionNumber 엘레멘트와 Settings 엘레멘트를 포함할 수 있다. 상기 ApplicationID 엘레멘트는 각 위젯 애플리케이션을 유일하게 식별하는 식별자에 대한 엘레멘트다. 상기 RevisionNumber 엘레멘트는 각 위젯 애플리케이션의 버전을 알 수 있도록 하는 엘레멘트다. 따라서, 사용자 프로파일에는 각 위젯 애플리케이션에 대한 ApplicationID와 버전 정보를 함께 저장하여 특정 위젯 애플리케이션만을 호출할 수 있다. 또한, 상기 Settings 엘레멘트는 각 위젯 application 별로 사용자에 의해 설정된 정보를 저장하는 엘레멘트다. 여기서, 상기 Settings 엘레멘트는 Position 엘레멘트, Extension 엘레멘트 및 기타 다른 엘레멘트들을 포함한다. 상기 Position 엘레멘트는 각 위젯 애플리케이션의 전체 위젯 애플리케이션 목록 중에서의 위치 정보를 나타내고, Extension 엘레멘트 등을 통해 각 위젯별 환경 설정 정보를 나타낸다. 따라서, 사용자는 상기 사용자 프로파일 정보를 통하여 ITF에 설치된 위젯 애플리케이션 및 각 위젯 애플리케이션 별 환경 설정 정보를 서버에 저장하여 어느 IPTV 수신기를 통해 서비스를 이용하더라도 동일한 환경을 손쉽게 이용할 수 있다.

도 15는 본 발명에 따른 PVR 위젯 익스텐션(Widget Extension)과 IPTV 소프트웨어와의 연관관계를 설명하기 위해 도시한 도면이다.

도 15에서, 위젯 매니저(1520)과 위젯 론쳐(1530)는 전술한 도 2의 내용을 원용하고 여기서 상세한 설명은 생략한다.

IPTV 수신기의 전원이 켜지고 나면, 위젯 런타임 프레임 워크 모듈(1540)은 사용자가 PVR 위젯 애플리케이션(1510)을 실행하여 이용할 수 있도록 환경을 제공한다.

또한, PVR 익스텐션 모듈(Extension module)(1550)은 PVR 위젯 애플리케이션(1510)을 통해 사용자가 요청하는 기능을 수행할 수 있도록 동작된다.

PVR 매니저 모듈(manger module)(1560)은 위젯 런타임 프레임 워크 모듈(1540) 또는 PVR 익스텐션 모듈(Extension module)(1550)을 통하여 PVR 위젯 애플리케이션(1510)에 의하여 사용자가 요청한 기능을 수행하기 위하여, 상기 기능과 관련된 각 하드웨어 디바이스의 기능을 제어한다.

더욱 상세하게는, IPTV 수신기의 전원이 켜지면 위젯 런타임 프레임 워크 모듈(1540)을 통해 PVR 위젯 애플리케이션(1510)이 동작할 수 있는 환경이 조성된다. PVR 위젯 애플리케이션(1510)이 실행되고, 사용자가 상기 PVR 위젯 애플리케이션(1510)을 통해 특정 기능을 요청하면, 상기 PVR 위젯 애플리케이션(1510)은 상기 요청된 기능과 관련하여 후술하는 바와 같이 정의된 API를 호출한다.

따라서, 위젯 런타임 프레임 워크 모듈(1540)는 상기 호출된 API가 PVR 기능과 관련된 경우에는 PVR 익스텐션 모듈(Extension module)(1550)로 특정 API가 호출되었음을 알린다. PVR 익스텐션 모듈(Extension module)(1550)은 상기 위젯 런타임 프레임 워크 모듈(1540)에서 알린 API를 확인하여 PVR 매니저 모듈(manger module)(1560)로 상기 API에 해당하는 기능 수행이 요청되었음을 알린다. PVR 매니저 모듈(manger module)(1560)은 상기 PVR 익스텐션 모듈(Extension module)(1550)로부터 수신된 사용자의 요청을 수신하여 해당 모듈이 동작되도록 제어한다. 또한, 필요한 경우에는 최초 사용자의 요청에 대응하는 값을 전술한 역순의 경로를 통해 리턴할 수 있다.

상술한 과정을 통해 사용자는 PVR 위젯 애플리케이션(1510)을 통하여 간편하게 PVR 기능을 수행할 수 있다.

이하에서는 IPTV 수신기에서 이용 가능한 PVR 기능의 제어를 위한 API(이하 PVR APIs)에 대해 설명한다.

표 1에서는 본 발명에 따른 PVR APIs의 일 예를 정의하였다. 이하에서는 표 1을 참조하여, 상기 PVR APIs에 대해 상세하게 설명한다.

Category	PVR Extension APIs	Description
Playback Control APIs
	Play	Play stored content
	Stop	Stop playing of content
	Pause	Temporarily stop on-going operation
	Resume	Resume stopped operation
	SlowMotion	Play content in slow motions
	FastForward	Play content in FF mode
	FastRewind	Play content in fast REW mode
	Speed	Play content at input play multiple speed
	FrameForward	Play content in units of frames
	FrameRewind	Rewind content in units of frames
	Jump	Move to target positions
	StartJump	Play content after moving to target position
	FinishiJump	Stop playing after moving to target position
	Replay	Replay video and audio of set area
	Skip	Play content, skipping
	Record	Record content
	RecordScheduledProgram	Record scheduled program. Information to be subjected to scheduled recording is transmitted
Stream Editor APIs
	SetEditStartPosition	Set start position of area to be edited
	SetEditEndPosision	Set end position of area to be edited
	CancelEditSection	Cancel area to be edited
	IsEditSectionFixed	Return information indicating whether an area to be edited is completely set
	DeleteEditInformation	Delete all of edit information
	SetRepeatStartPosition	Set start position for iterative play
	SetRepearEndPosition	Set end position for iterative play
	IsRepeatSectionFixed	Return information indicating whether iterative play setting is completed
	DeleteRepeat	Delete iterative play area
	SetBookmark	Bookmark selected area
	RemoveBookmark	Delete bookmarked area
	GetFavoriteList	Get favorite information set so far
	RegisterFavorite	Register bookmarked area in favorite list
	UnregisterFavorite	Remove bookmarked area from favorite list
	SetRateOfFacvorite	Set rating for each favorite
	OpenFavoriteList	Plural favorite lists may be available. They may be opened in different files
	LoadFacoriteList	Load favorite list file
	CloseFavoriteList	Close favorite list file
Content Manager APIs
	Copy	Copy stored content to designated output device
	Move	Move stored content to designated output device. After the movement, the content is deleted irrevocably in device that has executed this command
	Remove	Delete stored content from current device
	SetOutputInterface	Set output device to which content is to be copied or moved
	SetInputInterface	Set input device when content is copied or moved
	Stop	Cancel current operation
	GetOutputInterface	Confirm current designated output device
	GetInputInterface	Confirm current designated input device
	GetStatus	If progress status information is returned during movement, copy, or deletion, Widget may display this information
Time - Shift APIs
	Initialize	Initialize Timeshift object. Initialize memory or set hardware to timeshift-enabled state
	Finalize	Finalize Timeshift object. Finalize memory use or hardware use
	StartTimeshift	Start Timeshift
	StopTimeshift	Stop Timeshift
	ResumeTimeshift	Resume Timeshift
	Play	Play during timeshift
	Stop	Stop timeshift play
	GetStartPointOfTimeshift	Return to start point of Timeshift
	SetStartPointOfTimeshift	Set some point of Timeshift as start point
	GetCurrentSizeOfAvailableTimeshift	Return current available capacity for Timeshift
	GetTimeshiftStatus	DVR Widget Application invokes this API to check current Timeshift status, mainly to display timeshift available time or progressed time
	NotifyTimeshiftStatus	Function to report current timeshift status to DVR Widget Application

표 1을 참조하면, PVR APIs는 크게 Playback Control API들, Stream Editor

API들, Content Manager API들 및 Time-Shift API들로 카테고리화된다. 여기서, 상기 PVR API들은 PVR 기능들 중 유사한 기능들로 묶어 설명의 편의를 위해 구분한 것으로, 본 발명은 상기 표 1에서 예시된 바에 한정되는 것은 아니다. 예를 들어, 표 1에서, Bookmark와 관련된 기능을 제공하는 API들(즉, Bookmark API들)은 Stream Editor API들에 속하는 것으로 예시하였다. 다만, 이러한 API들은 다른 카테고리(예를 들어, Playback Control)에 속하거나 또는 별개의 독자적인 카테고리로 구성될 수도 있다.

그리고 상기 각 카테고리는 예를 들어, 각각 개별적인 PVR 위젯 애플리케이션을 위해 구현되거나 적어도 둘 이상의 카테고리가 조합되어 하나의 PVR 위젯 애플리케이션을 위해 구현되거나 또는 상기 예시한 모든 카테고리가 하나의 PVR 위젯 애플리케이션을 위해 구현될 수도 있다. 즉, 상기 각 카테고리 또는 각 API는 다양한 조합으로 PVR 위젯 애플리케이션을 위해 구현될 수 있다.

또한, 표 1에서 예시된 API들은 독자적으로 구현될 수도 있고 2개 이상의 API들이 하나의 세트(set)로 구현될 수도 있고, 특정 API는 다른 API에 종속적인 관계로 구현될 수도 있다.

이하에서는 본 발명에 따른 PVR APIs에 대해 보다 상세하게 설명하되, 설명의 편의를 위해 API 카테고리 별로 구분하여 설명한다.

먼저, Playback Control API들에 대해 설명하면, 다음과 같다. 사용자는 PVR 위젯 애플리케이션을 통해 비디오 컨텐트의 재생을 제어할 수 있다. 여기서, 상기 사용자의 비디오 컨텐트 재생 제어 요청과 관련하여, IPTV 수신기와 PVR 위젯 애플리케이션 사이에서는 후술하는 API들이 관계된다.

Play API는 비디오 컨텐트를 재생시키기 위한 API이다. 여기서, 상기 Play API는 일반적으로는 특정 비디오 컨텐트를 처음으로 실행시키고자 하는 경우에 사용되나 경우에 따라 후술하는 Resume API의 기능도 함께 수행할 수도 있다. 또한, 상기에서 비디오 컨텐트는 예를 들어, PVR 저장부에 미리 저장된 컨텐트이거나 또는 실시간 방송 컨텐트일 수 있다.

Stop API는 비디오 컨텐트의 재생을 중단시키는 API이고, Pause API는 비디오 컨텐트의 재생을 일시 중지시키는 API이다. 여기서, 상기 두 API는 모두 컨텐트가 재생되지 않도록 한다는 점에서는 유사하다. 다만, 전자는 컨텐트의 실행을 종료시키는 API로 해당 컨텐트를 재생하기 위해서는 상기 Play API를 통해서만 재생할 수 있으며, 상기 재생시 해당 컨텐트의 처음부터 재생된다. 또한, 후자는 컨텐트의 실행을 잠시 중지시키는 API로 해당 컨텐트를 재생하기 위해서는 상기 Play API나 또는 후술하는 Resume API를 통해 모두 재생할 수 있으며, 상기 재생시 해당 컨텐트는 중지된 부분 이후부터 다시 재생된다.

Resume API는, Play API와 같이 비디오 컨텐트를 재생시키는 API이다. 다만, 상기 Resume API는 Pause API에 의해 재생이 중지된 컨텐트를 해당 중지 부분 이후부터 다시 재생시키는 경우에 이용되는 API이다. 여기서, 상기 Resume API는 예를 들어, 특정 컨텐트의 처음부터 재생을 요청하거나 Stop API에 의해 컨텐트의 재생이 중단된 경우에는 불능(disable)되어 실행되지 않을 수 있다. 즉, 상기 Resume API는 상기 Play API를 실행시킨 이후에 상기 Pause API가 실행된 이후의 시점에서만 인에이블(enable)되고 실행될 수 있다. 이 경우 상기 Resume API와 상기 Play API는 모두 인에이블될 수도 있고 혼동을 피하기 위해 상기 두 API 중 어느 하나의 API만이 인에이블될 수도 있다.

다음으로 상기 Playback Control 카테고리 내 컨텐트에 대한 재생 속도 조절과 관련된 APIs에 대해 설명한다. 이러한 APIs로는 SlowMotion API, FastForward API, FastRewind API, SpeedRewind API, FrameForward API 및 FrameRewind API들이 포함될 수 있다. 이하에서 재생 속도 조절과 관련하여, 명시되는 수치 등은 본 발명의 이해를 돕기 위한 예시로써 본 발명이 이러한 수치 등에 한정되는 것은 아님을 미리 밝혀둔다.

SlowMotion API는, 컨텐트를 슬로우 모션(slow motion)으로 재생시키는 API이다. 여기서, 상기 슬로우 모션이라 함은, 컨텐트의 기본적인 재생 속도를 1배속이라 가정하면, 이보다 느린 재생 속도 예를 들어, 0.5 배속 정도를 의미한다.

FastForward API는, 컨텐트를 빨리 감기(fast forward)로 재생시키는 API이다. 여기서, 상기 빨리 감기라 함은, 상기 기본 재생 속도인 1보다 빠른 재생 속도 예를 들어, 2배속 정도를 의미하는 것으로, 일반적으로 빨리 감기에 해당하는 재생 속도는 디폴트(default)로 정해진다.

FastRewind API는, 컨텐트를 빨리 역감기(fast rewind)로 재생시키는 API이다. 여기서, 상기 빨리 역감기라 함은, 전술한 빨리 감기에 대응되는 개념으로 예를 들어, 2배속 되감기를 의미할 수 있다. 상기 FastForward API와의 차이는 재생 방향이 포워드(forward) 방향이냐 리와인드(rewind) 방향이냐의 차이만 있고 그 배속은 일반적으로 디폴트로 정해지므로 동일할 수 있다.

Speed API는, 사용자에 의해 입력된 재생 속도로 컨텐트를 재생시키는 API이다. 상기 FastForward API와 상기 FastRewind API의 경우에는 그 재생 속도가 default로 정해져서 사용자에 의해 제어가 불가능하나, 상기 Speed API는 사용자에 의해 재생 속도에 대한 제어가 가능하게 하는 API이다. 다만, 이때, 상기 제어되는 재생 속도는 어떤 값도 가능하다. 즉, 상기 Speed API에 의해 정의되는 재생 속도는 예를 들어, 전술한 슬로우 모션, 빨리 감기, 빨리 역감기에서 정의한 재생 속도와 동일할 수도 있다. 또한, 상기 Speed API는 재생 방향도 한정되지 않아 포워드 방향과 리와인드 방향 모두 설정 가능하다. 예를 들어, 사용자에 의해 재생 속도로 (-) 1.5가 입력되면, 재생 방향은 리와인드 방향이고 재생 속도는 1.5배속임을 의미할 수 있고, (+)1.5가 입력되면 f포워드 방향으로 1.5배속으로 재생됨을 의미할 수 있다. 이를 위해 IPTV 수신기는 사용자로부터 원하는 재생 속도를 입력받기 위한 UI를 구성하여 제공할 수 있다. 상기 UI에는 예를 들어, 미리 선택 가능한 재생 속도를 제공하여 선택하도록 하거나 또는 원하는 배속 입력을 위한 숫자 세트트를 제공하여 선택받을 수도 있다.

FrameForward API와 FrameRewind API는, 컨텐트를 프레임 단위로 재생시키는 API이다. 다만, 전자는 재생 방향이 포워드 방향이고, 후자는 재생 방향이 리와인드 방향이다. 또한, 상기에서 프레임 단위는 예를 들어, I, B, P 프레임 중 어느 하나의 프레임만을 의미할 수도 있고, 또는 동일하거나 동일하지 않은 다수 개의 프레임 묶음을 의미할 수도 있다. 그리고 상기 프레임 단위는 사용자 등에 선택될 수도 있다.

Jump API는, 현재 프레임에서 특정 프레임으로 점프시키는 API이다. StartJump API와 FinishJump API는 각각 현재 프레임에서 특정 프레임으로 점프하여 재생을 시작하거나 재생을 중지시키는 API이다. 상기에서 점프 위치는 기 재생된 부분과 재생할 부분이 모두 포함된다. 이 경우, 상기 Jump API는 상기 StartJump API와 FinishJump API가 사용자에 의해 설정된 특정 프레임으로 점프함에 비하여, 디폴트로 정해진 범위의 프레임만큼 점프할 수 있다. 또한, 점프 방향이난 점프 후 재생 또는 종료 여부도 부호를 이용하여 결정할 수 있다. 상기 APIs와 관련하여, IPTV 수신기는 점프 재생 위치와 점프 종료 위치 등을 설정할 수 있도록 사용자에게 별도로 구성한 UI를 제공할 수도 있다. 또한, 상기 StartJump API와 상기 FinishJump는 예를 들어, 상기 FrameForward API와 상기 FrameRewind API가 실행 시점 이후부터 각 프레임을 빠짐없이 순차 재생함에 반해, 특정 프레임으로 점프한 이후에 재생을 시작하거나 또는 재생을 중단한다.

Replay API는, 특정 프레임이나 또는 설정된 범위의 프레임을 반복 재생시키는 API이다. IPTV 수신기는 예를 들어, 반복 범위를 설정하기 위해 바-형식의 UI를 제공하여 사용자로부터 반복 범위를 설정하도록 할 수 있다.

Skip API는, 미리 정해진 범위의 프레임만큼 스킵하면서 재생시키는 API이다. 여기서, 상기 스킵은, 현재 프레임에서 기 재생된 프레임들 또는 재생할 프레임 방향으로 이루어질 수 있다. 또한, 상술한 FrameForward API와 FrameRewind API와 관계를 고려할 때, 상기 프레임 범위는 적어도 2 프레임 이상인 것이 바람직하다. 또한, 상기 Skip API는 계속하여 기 정해진 범위의 프레임만큼 건너뛰면서 재생됨에 반해 상기 Jump API는 특정 범위만큼 점프한 이후에는 기본 재생 속도로 재생되는 점이 상이하다. 이때, IPTV 수신기는 스킵 범위 설정과 관련하여 사용자가 선택 가능하도록 UI를 구성하여 제공할 수 있다.

Record API는, 컨텐트를 녹화시키는 API이다. 여기서, 상기 녹화는 컨텐트 단위 또는 컨텐트 내 특정 프레임 단위만큼 녹화될 수 있다. 또한, 상기 Record는 즉시 녹화, 예약 녹화 및 타임-쉬프트 중 어느 하나일 수 있으며 다른 API와 연동될 수도 있다. 예를 들어, 상기 Record가 타임-쉬프트인 경우에는 후술하는 Time-Shift APIs과 연동될 수 있다. 관련하여, IPTV 수신기는 사용자에게 상기 Record를 요청하는 경우에 상기 즉시 녹화, 예약 녹화 및 타임-쉬프트 중 하나를 선택할 수 있도록 UI를 구성하여 제공하고, 사용자의 선택에 따라 연동되는 기능의 존재와 선택을 위한 UI를 제공할 수도 있다. 또한, IPTV 수신기는 상기 Record API의 실행과 함께 녹화 또는 타임-쉬프트되는 컨텐트 또는 프레임을 구분하여 저장한다.

RecordScheduledProgram API는 컨텐트의 녹화 기능을 시작시키는 API이다. 다만, 상기 RecordScheduledProgram API는 사용자의 선택에 의해 호출되기 보다는 전술한 Record API와 연동되어 자동으로 호출될 수 있다. 또한, IPTV 수신기는 상기 RecordScheduledProgram API를 통해 예약 녹화될 컨텐트에 대한 정보를 사용자에게 제공할 수도 있다.

이상 Playback Control APIs에 대해 설명하였다. 상기에서 상기 Playback Control와 관련된 각 API는 개별적으로 실행될 수도 있으며, 또는 관련 API와 연동하여 실행될 수도 있다.

다음으로, IPTV 수신기는 사용자의 입력에 따라 PVR 위젯 애플리케이션을 통해 수신된 IP 패킷 내 콘텐츠에 대한 스트림을 편집할 수 있다. 이하에서는 IPTV 수신기에서 사용자의 요청에 따라 스트림의 편집을 적절하게 제어할 수 있도록 Stream Editor APIs를 정의한다. 이하에서는 상기 Stream Editor APIs에 대해 보다 상세하게 설명한다.

SetEditStartPosition API와 SetEditEndPosision API는, 스트림 내 편집 영역을 설정함에 있어서 각각 편집을 시작할 위치와 편집을 종료할 위치를 설정시키는 API로, 상기 두 API는 하나의 세트로 연동될 수 있다. 여기서, IPTV 수신기는 상기 두 API에 따른 편집 영역을 스트림 별로 메모리에 구분하여 저장할 수 있다. IPTV 수신기는 해당 기능을 실행하면, 메모리로부터 해당 스트림에 대한 정보를 추출하여 사용자가 스트림의 편집 시작 위치와 편집 종료 위치를 설정할 수 있도록 UI (예를 들어, 바 형식)를 구성하여 제공할 수 있다.

CancelEditSection API는, SetEditStartPosition API와 상기 SetEditEndPosision API를 통해 설정된 편집 영역(시작 영역과 종료 영역)에 대한 설정을 취소시키는 API이다. 예를 들어, IPTV 수신기는 해당 기능이 요청되는 경우에 메모리를 액세스한 결과 편집 영역이 존재하는 스트림이 다수 개 존재하거나 하나의 스트림에 편집 영역이 다수 개 존재하는 경우에는 사용자가 선택할 수 있도록 리스트 형식의 UI를 구성하여 제공할 수 있다.

IsEditSectionFixed API는, SetEditStartPosition API와 상기 SetEditEndPosision API를 통한 편집 영역 설정 기능을 종료할 지 여부를 리턴(return)하는 인터페이스이다. 여기서, IPTV 수신기는 해당 기능이 요청되면, 사용자에게 OSD를 통해 편집 영역 설정 기능의 종료를 확인하는 텍스트 형식의 UI를 제공할 수 있다.

DeleteEditInformation API 는, 스트림 편집과 관련하여 메모리에 저장된 편집 정보를 삭제시키는 API이다. 여기서, IPTV 수신기는 편집 정보가 존재하는 스트림이 다수 개이거나 또는 하나의 스트림에 편집 정보가 다수 개 존재하는 경우에 메모리를 액세스하여 편집 정보를 리스트 형식의 UI를 제공하여 사용자로부터 삭제할 편집 정보를 입력 받을 수 있다. 또는 IPTV 수신기는 상기 DeleteEditInformation API가 실행되면, 메모리에 저장된 모든 편집 정보를 삭제할 수도 있다. 다만, 이 경우 IPTV 수신기는 사용자에게 해당 기능 실행에 대한 UI를 제공하여 다시 한 번 컨퍼메이션(confirmation)을 받고 편집 정보들을 삭제할 수 있다.

SetRepeatStartPosition API와 SetRepearEndPosition API는, 스트림 내에서 반복 재생할 범위를 설정하기 위해 각각 시작 위치와 종료 위치를 설정받는 API이다. 여기서, IPTV 수신기는 상기 두 API에 따라 설정된 반복 영역에 대한 설정을 스트림 별로 메모리에 구분하여 저장할 수 있다. IPTV 수신기는 상기 스트림 내 반복 재생할 범위에 대한 시작 위치와 종료 위치를 설정 받기 위해 예를 들어, 바 형식의 UI를 제공할 수 있다.

IsRepeatSectionFixed API 는, SetRepeatStartPosition API와 SetRepearEndPosition API에 따른 반복 범위 설정이 모두 종료 여부를 리턴하는 API이다. 이를 위해 IPTV 수신기는 종료 여부를 확인하기 위한 UI를 제공할 수 있다.

DeleteRepeat API는, SetRepeatStartPosition API와 SetRepearEndPosition API를 이용하여 설정된 반복 재생 범위에 대한 설정을 삭제시키는 API이다. 여기서, IPTV 수신기는 메모리를 액세스하여 반복 재생 범위가 설정된 스트림이 다수 개이거나 하나의 스트림 내에 반복 재생 범위가 다수 개 설정된 경우에는 사용자의 선택을 입력 받기 위해 리스트 형식의 UI를 구성하여 제공할 수 있다.

이하에서는 북마크와 관련된 API를 설명한다. 이때, 상기 북마크 관련 API는 비록 Stream Editor 카테고리에서 설명되나, 다른 카테고리 예를 들어, Playback Control 카테고리에도 동일하게 존재할 수 있으며, 별도의 카테고리로 존재할 수도 있다. 별도로 존재하는 경우에도 다른 카테고리와 연동되어 사용될 수 있다.

SetBookmark API는, 선택된 영역을 북마크시키는 API이다. 여기서, 상기 영역은, 일반적으로는 범위의 의미로 사용되나 반드시 범위를 나타내는 것은 아니며 예를 들어, 특정 프레임만을 지칭하는 의미로 사용될 수도 있다. IPTV 수신기는 선택된 영역을 메모리 내에 북마크 구간에 구분하여 저장하거나 또는 북마크용으로 구비된 별도의 메모리에 저장할 수도 있다. 또한, IPTV 수신기는 선택된 영역을 스트림 별 또는 컨텐트 별로 구분하여 저장할 수도 있다.

RemoveBookmark API는, SetBookmark API에 의해 설정된 영역 또는 상기 영역에 대한 북마크를 삭제시키는 API이다. 여기서, IPTV 수신기는 메모리를 액세스하여 북마크가 설정된 스트림이 다수 개이거나 하나의 스트림 내 북마크가 여러 개 존재하는 경우 리스트 형식의 UI를 제공하여 사용자가 삭제할 영역 또는 영역에 대한 북마크를 선택하도록 할 수 있다. 또는 IPTV 수신기는 상기 API가 호출된 경우에는 메모리로부터 설정된 모든 북마크를 삭제할 수 있다. 또한, IPTV 수신기는 상기 API가 호출된 경우에는 별도로 상기 선택된 영역, 영역에 대한 북마크 또는 상기 API가 호출된 경우에는 삭제 여부를 확인하는 텍스트 형식의 UI를 OSD를 통해 제공하여 사용자의 컨퍼메이션 후에 삭제할 수도 있다.

GetFavoriteList API 는, Favorite으로 설정된 리스트를 얻는 API이다. 여기서, 상기 Favorite는 Bookmark보다 상위의 개념으로 Bookmark 중에서 별도 Favorite로 선택된 Bookmark를 의미한다. 다만, 이는 설명의 편의를 위한 것으로, 상기 Favorite가 상기 Bookmark와 동일한 의미로 사용될 수도 있다. 따라서, IPTV 수신기는 상기 GetFavoriteList API가 호출된 경우에는 상기 SetBookmark API에 의해 설정된 북마크에 대한 리스트로 대신하거나 또는 상기 북마크 리스트 중 특히 Favorite로 설정되거나 북마크 리스트에 포함되진 않았으나 사용자 등에 의해 특별히 설정된 스트림 내 영역에 대한 리스트를 제공할 수 있다. 또한, ITF는 예를 들어, 상기 Favorite 리스트를 UI로 제공하되, 스트림 별로 구분하여 제공할 수도 있다. 예를 들어, IPTV 수신기는 상기 GetFavoriteList API를 상기 RemoveBookmark API와 연동시켜, 상기 RemoveBookmark API 호출시에 상기 GetFavoriteList API를 호출하여 그에 따른 결과를 제공하여 사용자로부터 삭제 여부 선택을 받을 수도 있다.

RegisterFavorite API와 UnregisterFavorite API는, 각각 북마크 영역이나 기타 영역을 패이브리트 리스트(Favorite List)에 등록시키거나 또는 언레지스터(unregister) 시키는 API이다. 여기서, IPTV 수신기는 상기 각 API의 호출에 따라 패이브리트 리스트에서 해당 영역을 각각 등록시키거나 언레지스터시킨다. 또한, IPTV 수신기는 상기 RegisterFavorite API가 호출된 경우에는 장르와 같이 타입에 따라 Favorite을 등록 가능하도록 UI를 구성하여 제공할 수도 있다.

SetRateOfFavorite API는, 패이브리트 리스트 내 각 영역에 대하여 레이팅(rating)의 설정시키는 API이다. 여기서, 상기 레이팅은 일반적인 의미의 시청 등급을 의미한다. 또한, IPTV 수신기는 상기 레이팅이 설정된 경우에는 암호 등에 의해 특정인만 접근할 수 있도록 비밀 번호 설정 등을 할 수 있도록 UI를 구성하여 설정하도록 할 수 있다.

OpenFavoriteList API와 CloseFavoriteList API는, RegisterFavorite API에 의해 등록된 패이브리트 리스트를 각각 오픈(open)시키고 클로우즈(close)시키는 API이다. 이 경우 IPTV 수신기는 상기 등록시에 타입에 따라 구분한 경우에는 타입을 먼저 선택하도록 하는 UI를 구성하여 제공하고, 사용자의 입력에 따라 선택된 타입의 패이브리트 리스트만을 제공할 수도 있다. 또한, IPTV 수신기는 사용자가 특정 레이팅을 선택한 경우에는 해당 레이팅이 걸린 패이브리트 리스트만을 제공할 수도 있다.

LoadFavoriteList API는, 패이브리트 리스트를 로드(load)시키는 API이다. IPTV 수신기는 로드되는 패이브리트 리스트에 따라 메모리에 구분하여 저장할 수 있다.

다음으로, IPTV 수신기는 사용자의 입력에 따라 컨텐트를 제어할 수 있다. 이러한 컨텐트 마진(content managing)과 관련된 APIs가 포함된 Content Manager 카테고리에 대해 설명하면, 다음과 같다.

Copy API는, 메모리에 저장된 컨텐트를 지정된 출력 장치로 복사시키는 API이다. IPTV 수신기는 상기 함수가 호출되면, 복사할 컨텐트와 컨텐트가 복사될 출력 장치를 선택할 수 있는 UI를 구성하여 제공할 수 있다.

Move API는, 메모리에 저장된 컨텐트를 지정된 출력 장치로 이동시키는 API이다. IPTV 수신기는 상기 함수가 호출되면, 이동시킬 컨텐트와 컨텐트가 이동될 출력 장치를 선택할 수 있는 UI를 구성하여 제공할 수 있다. 상기 Move API는 상기 Copy API와 달리 이동과 동시에 이 명령을 수행한 장치에서 컨텐트가 삭제되어 복구할 수 없을 수 있다. 다만, 상기 Copy API의 경우에도 복사 이후에도 명령을 수행한 장치에서 컨텐트가 삭제되지 않고 존재한다.

Remove API는, 메모리에 저장된 컨텐트를 현재 장치에서 삭제시키는 API이다. IPTV 수신기는 상기 함수가 호출되면, 메모리에 저장된 컨텐트의 리스트를 UI로 구성하여 제공하고, 사용자에 의해 선택된 컨텐트를 삭제한다.

SetOutputInterface API는, 메모리에 저장된 컨텐트를 복사하거나 이동시킬 출력장치를 설정시키는 API이다. 이 경우 독자적으로 상기 API가 존재할 수도 있고, 상기 Copy API나 Move API가 호출되면 자동으로 호출되어 실행될 수 있다. IPTV 수신기는 사용자가 출력 장치를 선택할 수 있도록 접근 가능한 출력 장치의 리스트를 UI를 구성하여 제공할 수 있다.

SetInputInterface API는, 컨텐트를 복사하거나 이동하는 경우에 입력 장치를 설정시키는 API이다. IPTV 수신기는 사용자가 선택 가능하도록 접근 가능한 입력 장치의 리스트를 UI로 구성하여 제공할 수 있다.

Stop API는, 현재 호출된 함수에 의해 설정되는 동작을 취소시키는 API이다.

GetOutputInterface API와 상기 GetInputInterface API는, 각각 현재 설정된 출력 장치와 입력 장치를 확인시키는 API이다.

GetStatus API는, 상기에서 호출된 복사, 이동, 삭제 등의 API에 따른 동작이 수행될 때, 해당 모듈로부터 진행 상황 등을 파악하기 위한 정보가 리턴되면, 이를 출력시키는 API이다. 사용자는 PVR 위젯 애플리케이션을 통해 상기 진행 상황 등을 확인할 수 있다.

IPTV 수신기는 실시간 방송을 시청하고 있는 경우에 Time-shift 기능을 PVR 위젯 애플리케이션을 통해 수행할 수 있다. 이하에서는 상기 Time-shift 카테고리에 포함된 APIs에 대해 기술한다.

Initialize API는, time-shifting을 위한 객체를 초기화시키는 API이다. 여기서, 상기 객체라 함은 예를 들어, 메모리를 의미할 수 있다. 따라서, IPTV 수신기는 상기 함수가 호출되면, 메모리를 초기화하거나 하드웨어의 상태를 타임-쉬프트가 가능한 상태로 설정한다.

Finalize API는, 타임-쉬프트를 위한 객체를 종료한다. 여기서, 상기 객체는 상술한 객체와 동일한 의미로 사용된다. 따라서, IPTV 수신기는 상기 함수가 호출되면, 메모리의 사용이나 하드웨어 등을 정리한다.

StartTimeshift API와 StopTimeshift API는, 각각 타임-쉬프트를 시작시키거나 종료시키는 API이다.

PauseTimeshift API는 타임-쉬프트를 일시 중지시키는 API이고, 상기 ResumeTimeshift API는 상기 PauseTimeshift API 호출에 따라 일시 중지된 타임쉬프트를 재개한다.

Play API는 컨텐트를 타임-쉬프트하면서 동시에 재생시키는 API이고, Stop API는 상기 Play API 호출에 따라 컨텐트를 타임-쉬프트하면서 동시에 재생하던 것을 재생을 중지한다. 상기 Stop API가 호출되는 경우 타임-쉬프트와 동시에 재생되던 컨텐트는 재생이 중지되나 타임-쉬프트는 종료되지 않는다.

GetStartPointOfTimeshift API는 타임-쉬프트가 시작된 지점을 리턴시키는 API이고, 상기 SetStartPointOfTimeshift API는 특정 지점을 타임-쉬프트의 시작 지점으로 설정시키는 API이다.

GetCurrentSizeOfAvailableTimeshift API는, 타임-쉬프트를 하고자 하는 경우 현재 가용한 용량을 리턴시키는 API이다.

GetTimeshiftStatus API는, 현재 타임-쉬프트의 상태를 확인하기 위해 PVR widget application이 호출시키는 API이다. 상기 API는 상기 PVR widget application에서 주로 타임-쉬프트 가능 시간이나 현재 진행된 시간 등을 화면에 표시하여 사용자에게 제공하기 위함이다. 상기 NotifyTimeshiftStatus API는, 상기 GetTimeshiftStatus API가 호출되면 그에 대응하여 현재 타임-쉬프트되는 상태를 보고하기 위한 API이다. 따라서, 상기 NotifyTimeshiftStatus API는 상기 GetTimeshiftStatus API가 호출되면 자동으로 호출되는 API로서 사용자에 의해 선택 가능한 기능에 따른 API는 아닐 수 있다.

이하에서는 전술한 도 3 내지 15를 참조하여, IPTV 수신기에서 PVR 위젯 애플리케이션을 다운로드 받아 설치, PVR 녹화, 타임-쉬프팅 및 컨텐트를 복사 또는 이동하는 방법에 대해 설명한다.

도 16은 PVR 익스텐션을 사용하는 PVR 위젯 애플리케이션의 설치 과정의 일 예를 설명하기 위해 도시한 순서도이다.

도 16을 참조하면, S1601 단계에서, 사용자가 리모콘을 통해 위젯 포털을 접속한다.

S1603 단계에서, IPTV 수신기는 수신기 프로파일을 위젯 포털에 전송한다.

S1605 단계에서, IPTV 수신기는 수신기 프로파일에 근거하여 상기 접속한 위젯 포털과의 통신을 통해 자신이 구비하고 있는 위젯 런타임 프레임워크 모듈과 익스텐션의 종류 및 버전이 최신 버전인지 판단한다.

S1607 단계에서, 상기 판단 결과 만약 상기 위젯 런타임 프레임워크 모듈과 익스텐션의 종류 및 버전이 최신 버전이 아니라고 판단되면, IPTV 수신기는 상기 위젯 포털로부터 최신 버전을 다운로드 받아 업그레이드한다.

S1609 단계에서, 상기 S1605 단계 판단 결과 위젯 런타임 프레임워크 모듈과 익스텐션의 종류 및 버전이 최신 버전이거나 상기 S1607 단계를 통해 최신 버전으로 업그레이드가 완료되면, IPTV 수신기는 위젯 포털로부터 상기 S1605 단계에서 전송한 수신 프로파일에 근거하여 전송된 위젯 프로파일 리스트를 수신하고 이를 화면을 통해 출력한다.

S1611 단계에서, IPTV 수신기는 사용자로부터 상기 출력된 위젯 리스트로부터 PVR 위젯 설치와 관련된 선택을 입력받는다.

S1613 단계에서, IPTV 수신기는 상기 PVR 위젯 애플리케이션을 설치한다.

S1615 단계에서, 위젯 런쳐(Widget launcher)가 설치된 PVR 위젯 애플리케이션을 론치(launch)한다.

S1617 단계에서, PVR 위젯 애플리케이션이 화면 상에 표시한다.

상술한 과정을 통해 PVR 위젯 애플리케이션은 설치 및 업그레이드될 수 있다.

도 17은 PVR 위젯 애플리케이션을 이용한 PVR 녹화 방법의 일 예를 설명하기 위해 도시한 순서도이다.

도 17을 참조하면, S1701 단계에서, 사용자에 의해 PVR 위젯 애플리케이션이 실행된다.

S1703 단계에서, 사용자가 리모콘의 record 버튼이나 PVR 위젯 애플리케이션의 record 버튼을 실행한다.

S1705 단계에서, 위젯 런타임 프레임워크 모듈 및 PVR 익스텐션 모듈이 PVR 메니저에게 record 명령을 요청한다.

S1707 단계에서, 메모리에 용량이 없는지 확인한다.

S1709 단계에서, 상기 S1707 단계 판단 결과 메모리에 상기 record 명령에 따른 용량이 없어 상기 record 명령을 수행되지 못했음을 화면에 표시한다.

S1711 단계에서, 상기 S1707 단계 판단 결과 메모리에 용량이 있으면, PVR 매니저는 상기 record 명령을 수행한다.

S1713 단계에서, PVR 매니저는 상기 record 명령이 시작되었음을 상기 PVR 위젯 애플리케이션으로 리턴한다.

S1715 단계에서, PVR 위젯 애플리케이션은 PVR 매니저로부터 리턴된 정보를 화면에 표시한다.

S1717 단계에서, 사용자가 리모콘의 STOP 버턴을 누르거나 PVR 위젯 애플리케이션의 STOP 버턴을 수행하였는지 판단한다.

S1719 단계에서, 상기 S1717 단계에서 판단 결과, 사용자가 리모콘의 STOP 버턴을 누르지 않았고 PVR 위젯 애플리케이션의 STOP 버턴이 수행되지 않은 경우에는 다시 메모리에 저장 용량이 없는지 판단한다.

판단 결과 메모리에 저장 용량이 없으면 S1715 단계로 돌아가고, 저장 용량이 있으면 플로우를 종료한다.

S1721 단계에서, PVR 위젯 애플리케이션이 위젯 매니저 및 PVR 익스텐션 모듈에 STOP 명령을 요청한다.

S1723 단계에서, 위젯 매니저 및 PVR 익스텐션이 PVR 매니저에게 STOP 명령을 전달한다.

S1725 단계에서, PVR 매니저가 저장 장치를 제어하여 저장을 멈춘다.

도 18은 본 발명에 따른 PVR 위젯 애플리케이션을 이용한 Timeshift 방법의 일 예를 설명하기 위해 도시한 순서도이다.

도 18을 참조하면, S1801 단계에서, 사용자가 컨텐트를 시청하다 타임쉬프트 버튼을 클릭하거나 PVR 위젯 애플리케이션을 실행한다.

S1803 단계에서, PVR 위젯 애플리케이션이 위젯 매니저 및 PVR 익스텐션에 타임쉬프트 시작을 요청한다.

S1805 단계에서, PVR 매니저가 타임쉬프트 동작을 수행한다.

S1807 단계에서, PVR 위젯이 주기적으로 타임쉬프트 상태를 요청하고 화면에 출력한다.

S1809 단계에서, 사용자가 타임쉬프트 상태에서 리모콘의 재생 버튼을 누르거나 PVR 위젯 애플리케이션에서 재생 수행을 요청하였는지 판단한다.

만약 사용자가 타임쉬프트 상태에서 리모콘의 재생 버튼을 누르거나 PVR 위젯 애플리케이션에서 재생 수행을 요청을 하지 않았다면 S1807 단계로 피드백한다. 다만, 사용자가 타임쉬프트 상태에서 리모콘의 재생 버튼을 누르거나 PVR 위젯 애플리케이션에서 재생 수행을 요청하였으면, 타임쉬프트한 컨텐트를 재생한다(S1811 단계).

S1813 단계에서, 사용자가 리모콘을 통해 타임쉬프트 상태에서 스톱 버튼이나 PVR 위젯 애플리케이션에서 스톱 수행을 요청하였는지 판단한다.

S1815 단계에서, 상기 S1813 단계 판단 결과, 사용자가 리모콘을 통해 타임쉬프트 상태에서 스탑 버튼이나 PVR 위젯 애플리케이션에서 스탑 수행을 요청하지 않았다면, 계속하여 타임쉬프트한 컨텐트를 재생한다. 다만, 상기 S1813 단계 판단 결과, 사용자가 리모콘을 통해 타임쉬프트 상태에서 스탑 버튼이나 PVR 위젯 애플리케이션에서 스탑 수행을 요청하였으면, PVR 위젯 애플리케이션이 타입 쉬프트 동작 종료를 요청한다

S1817 단계에서, PVR 매니저가 타임쉬프트를 종료한다.

도 19는 본 발명에 따른 PVR 위젯 애플리케이션을 이용한 컨텐트 이동 방법의 일 예를 설명하기 위해 도시한 순서도이다.

도 19를 참조하면, S1901 단계에서, 사용자가 PVR 위젯 애플리케이션을 실행시킨다.

S1903 단계에서, PVR 위젯 애플리케이션은 저장된 모든 컨텐츠를 표시한다.

S1905 단계에서, 사용자가 복사/이동할 컨텐트를 PVR 위젯 애플리케이션에서 리모콘으로 설정한다.

S1907 단계에서, 사용자가 PVR 위젯 애플리케이션에서 이동(또는 출력)할 장치를 선택한다.

S1909 단계에서, PVR 위젯 애플리케이션은 출력 장치의 용량이 충분한지 확인한다.

S1911 단계에서, 만약 용량이 충분하지 않다면 PVR 위젯 애플리케이션이 출력 저장 장치의 용량이 부족함을 화면에 표시하고 S1907 단계로 피드백한다.

S1913 단계에서, 만약 용량이 충분하다면 컨텐트에 DRM이 걸려 있는지 판단하기 위해 컨텐트 프로바이더 서버에 요청한다.

S1915 단계에서, 컨텐트에 대한 복사/이동 등에 대한 권한이 있는지 판단한다.

S1917 단계에서, 상기 S1915 단계 판단 결과, 권한이 없다면 S1903 단계로 피드백된다. 다만, 상기 권한이 있다면 선택된 출력 장치로 컨텐트를 복사/이동 등을 수행한다.

S1919 단계에서, PVR 매니저는 PVR 위젯 애플리케이션에게 명령이 완료되었음을 알려준다.

S1921 단계에서, PVR 위젯 애플리케이션은 컨텐트 DB를 업데이트하고, 화면을 다시 표시한다.

다음은 PVR 위젯 애플리케이션을 구동하는 IPTV 수신기의 일 예에 대해 설명한다.

도 20은 본 발명에 따라 IPTV 수신기의 블록 다이어그램의 일 예를 도시한 도면이다.

도 20을 참조하면, OITF는 오픈 IPTV 터미널 펑션(Open IPTV Terminal Function)의 약자이다. 상기 OITF는 논-IMS에 기초한 IPTV 서비스를 지원(support)하는 필요한 적어도 하나 이상의 펑셔널 모듈(functional module)로 구성된 수신기의 펑셔널 콜렉션(functional collection)이다.

여기에서, 사용자는 IMS 게이터웨이(IG)가 추가된 OITF 내의 IPTV 서비스를 이용할 수 있다. 상기 IG는 IMS 코어 네트워크(IMS core network)에 기초한 IMS에 기초하여 IPTV 서비스를 액세스하기 위한 필요한 펑션들을 포함할 수 있다.

OITF와 IG는 HNI-IGI라고 불리우는 인터페이스에 의해 연결된다. 상기 HNI-IGI 인터페이스는 IG 펑션을 이용하기 위한 OITF를 만들 수 있다. 상기 IG 펑션은 IMS에 기초하여 IPTV 서비스를 이용하기 위해 OITF를 만들 수 있다.

도 20을 참조하면, IPTV 수신기(2000)는, 네트워크 인터페이스(Network Interface)(2010), TCP/IP 매니저(TCP/IP Manager)(2020), 서비스 전달 매니저(Service Delivery Manager)(2030), 역다중화부(Demultiplexer)(2040), 시그널링 정보 디코더(Signaling information decoder)(2050), A/V 프로세서(A/V processor)(2060), 디스플레이 유닛(Display unit)(2070), 서비스 제어 매니저(Service control manager)(2080), 서비스 디스커버리 매니저(Service Discovery Manager)(2090), 메타데이터 매니저(Metadata manager)(2100), SI&메타데이터 데이터베이스(SI&Metadata DB)(2110), 애플리케이션 매니저(Application manager)(21020), 위젯 프로세서(Widget processor)(2130) 그리고 유저 프로필 & 프리퍼런시즈 저장부(User profile & Preferences Storage)(2140)를 포함한다.

네트워크 인터페이스부(2010)는, IPTV 패킷들을 수신하고 전송한다. 상기 네트워크 인터페이스부(2010)는 피지컬 & 데이터 링크 레이어들(physical & data link layers)을 통해 네트워크와 연결된다.

TCP/IP 매니저(또는 인터넷 프로토콜 매니저)(2020)는, 엔드 투 엔드(소스에서 목적지로)(end to end (source to destination)) 패킷 전달을 책임진다. 상기 TCP/IP 매니저(2020)는, 각 패킷을 적절한 프로토콜 매니저로 분류한다.

서비스 전달 매니저(Service Delivery Manager)(2030), 리얼-타임 스트리밍 데이터와 컨텐트 다운로딩에 대한 핸들링을 책임진다. 또한, 서비스 전달 매니저(2030)는 이후 소비를 위해 컨텐트 데이터베이스로부터 컨텐츠의 복구를 책임진다. 이 경우, RTP/RTCP(Real-Time Transport Protocol/RTP Control Protocol) 프로토콜이 MPEG-2 TS에 대해 사용될 수 있다. MPEG-2 패킷들은 RTP 내로 인캡슐레이트(encapsulated)된다. 서비스 전달 매니저(2030)는 RTP 패킷들은 파싱하고, 파싱된 트랜스포트 패킷들을 역다중화부(2040)으로 전송한다. 서비스 전달 매니저(2030)는 RTCP를 이용하여 네트워크 수신 퀄리티에 대한 피드백을 전송한다. MPEG-2 트랜스포트 패킷들은 RTP 없이 UDP 내에서 직접 전송(carried)될 수도 있다. 컨텐트 다운로딩을 위하여, 전달 프로토콜로 HTTP 또는 FLUTE 프로토콜이 이용될 수 있다.

역다중화부(Demultiplexer)(2040), 입력되는 트랜스포트 패킷들로부터 오디오, 비디오 그리고 PSI/PSIP 테이블들(Program Specific Information/Program and System Information Protocol tables)을 역다중화한다. 이 경우, 역다중화부(2040)는, PSI 테이블들 역다중화를 위해 시그널링 정보 디코더(2050)의 제어를 받는다. 이때, 역다중화부(2040)는, PSI 테이블들의 섹션들을 만들고(make), 상기 만들어진 섹션들을 시그널링 정보 디코더(2050)로 전송한다. 또한, 역다중화부(2040)는 A/V 트랜스포트 패킷들의 역다중화를 위해 A/V 프로세서(2060)의 제어를 받는다.

시그널링 정보 디코더(Signaling information decoder)(2050)는, 시그널링 정보(즉, PSI 테이블들과 PSIP/DVB-SI 테이블들)을 위한 PID들을 역다중화부(2040)에 설정하고, 상기 역다중화부(2040)에서 전송된 PSI와 PSIP/DVB-SI 테이블의 개별 섹션들(private sections)을 디코딩한다. 상기 디코딩의 결과는 입력되는 트랜스포트 패킷들의 역다중화에 이용된다(예를 들어, 오디오와 비디오 PID를 역다중화부(2040)에 설정).

A/V 프로세서(A/V processor)(2060), A/V 디코더(A/V decoder)(2061), 비디오 필터 프로세서(Video Filter Processor)(2062), 비디오 디스플레이 프로세서(Video Display Processor)(2063) 그리고 그래픽 프로세서(Graphic Processor)(2064)를 포함할 수 있다. 상기 A/V 디코더(2061)는, A/V 엘리멘터리 스트림(elementary stream) 패킷들을 디코딩한다. 상기 비디오 필터 프로세서(2062)는, 유저 섹션들 또는 모든 비디오 스크린의 모든 영역 내 비디오 필터를 처리할 것이다. 상기 비디오 필터 프로세서(2062)는 비디오 픽쳐 또는 스틸 픽쳐를 다루거나 조절하기 위해 비디오 프레임 버퍼 메모리(미도시)를 액세스할 수 있다. 상기 비디오 디스플레이 프로세서(2063)는 스크린 상의 PIP(Picture In Picture)와 POP(Picture on Picture) 비디오를 제어한다. 또한, 그것은 MPEG-2 디코더 시스템의 마지막에 비디오 스케일을 포함한다. 상기 그래픽 프로세서(2064)는 UI 메뉴와 다이얼로그 메시지들(dialogue messages)의 노티피케이션(notification)을 디스플레이하기 위해 스크린 상의 OSD 플레인(plane)을 제어한다.

디스플레이 유닛(Display unit)(2070)은, A/V 디코더(2061)로부터 오디오와 비디오 데이터를 수신한다. 디스플레이 유닛(2070)은 비디오 데이터, 오디오 데이터를 제어하고 그것들이 스크린과 스피커 상에서 디스플레이되도록 제어한다. 디스플레이 유닛(2070)은 OSD 그래픽 데이터를 제어한다.

애플리케이션 매니저(Application manager)(2120), TV 스크린상의 GUI(Graphic User Interface)를 지원할 수 있다. 상기 애플리케이션 매니저(2120)는 리모컨 또는 프론트 패널에 의해 유저 키를 수신할 수 있다. 그리고, 애플리케이션 매니저(2120)는 전체 TV 시스템의 상태를 관리할 수 있다.

서비스 매니저(2122)는 서비스 제어 매니저(2080), 서비스 전달 매니저(2030), IG-OITF 클라이언트(미도시), 서비스 디스커버리 매니저(2090)과 메타데이터 매니저(2100)과 같은 서비스들과 관련된 다른 모든 매니저들을 제어할 수 있다. 상기 서비스 매니저(2122)는 IPTV 서비스의 서비스를 책임질 수 있다.

SI&메타데이터 데이터베이스(SI&Metadata DB)(2110)는, 서비스들과 관련된 서비스 디스커버리 정보와 메타데이터를 위한 데이터베이스이다.

서비스 디스커버리 매니저(Service Discovery Manager)(2090)는, 양방향 IP 네트워크를 통해 IPTV 서비스들의 디스커버리를 가능하게 할 수 있고, 해당 서비스를 선택하기 위한 모든 정보를 제공할 수 있다.

서비스 제어 매니저(Service control manager)(2080), 서비스들의 선택 및 제어와 세션들의 관리를 책임진다. 상기 서비스 제어 매니저(2080)는 IGMP(Internet Group Management Protocol) 또는 RTSP(Real Time Streaming Protocol) 프로토콜을 이용하여 생방송을 선택할 수 있다. 또한, 상기 서비스 제어 매니저(2080)는 RTSP 프로토콜을 이용하여 VOD 컨텐츠를 선택할 수 있다. IMS(International Measurement System)를 이용할 때, SIP(Session Initiation Protocol) 프로토콜은 IMS 게이트웨이를 통하여 세션들을 초기화하고 관리하는데 사용될 수 있다. 상기 RTSP 프로토콜은 주문형 딜리버리와 TV 방송 및 오디오의 딜리버리의 제어에 이용될 수 있다. 상기 RTSP 프로토콜은 지속적인 TCP 연결에 이용될 수 있고, 실시간 미디어 스트리밍에 대한 트릭 모드 제어를 허락할 수도 있다.

유저 프로필 & 프리퍼런스 저장부(User profile & Preferences Storage)(2140)는 사용자 정보, 위젯(설치된 위젯과 액티브/인액티브 위젯들)에 관계된 모든 정보, 선호도(preferences)와 IPTV 수신기의 하드웨어 컴패터빌러티(hardware compatibility)와 스탠다드 프로파일(standard profile)을 유지(keep)할 수 있다. 상기 유저 프로필 데이터는 사용자가 시스템으로 로그하거나 또는 다운로드된 위젯 애플리케이션들을 삭제하는 경우, 위젯 런쳐(2132), 위젯 매니저(2133)과 웹 브라우저(2131)에 의해 읽힐 수 있다.

위젯 프로세서(Widget processor)(2030)는, 웹 브라우저(2131), 위젯 런쳐(2132), 위젯 매니저(2133), 그리고 위젯 런타임 프레임워크(2134)를 포함할 수 있다. 상기 위젯 런쳐(2132)는 사용자가 로그인하면 설치된 위젯 애플리케이션을 실행할 수 있다. 그리고 위젯 런쳐(2132)는 사용자가 다운로드된 위젯 애플리케이션을 변경하면 활성화된(activated) 위젯 애플리케이션을 실행할 수 있다. 상기 위젯 매니저(2133)는 IPTV 수신기에서 설치되고 실행 가능한 모든 위젯 애플리케이션들을 디스플레이할 수 있다. 그리고 상기 위젯 매니저(2133)는 서버로부터 사용자가 선택한 위젯 애플리케이션의 다운로드를 요청할 수 있다. 또한, 위젯 매니저(2133)는 다운로드된 위젯을 활성화/비활성화할 수 있다. 상기 위젯 매니저(2133)는 다운로드된 또는 실행중인 위젯 애플리케이션(또는 재생중인 위젯 애플리케이션)을 삭제할 수 있다. 상기 위젯 매니저(2133)는 디스플레이 스크린 내에 위젯 애플리케이션의 위치 변경과 위제 애플리케이션의 실행을 제어할 수 있다. 상기 위젯 런타임 프레임워크(2134)는 IPTV 수신기 내 인터페이스의 제어나 미리 정의된 모듈의 호출을 위해 위젯 애플리케이션이 이용될 수 있다. 상기 위젯 런타임 프레임워크(2134)는 위젯 런타임 미들웨어(widget runtime middleware)와 동작되고 제조사의 익스텐션의 하나인 PVR 익스텐션을 제어할 수 있다. 상기 PVR 위젯 애플리케이션은 PVR 매니저들의 동작들과 많이 연결(link)되며 미리 정의된 PVR 익스텐션 API들을 호출할 수 있다. 상기 웹 브라우저(DAE: declarative application environment)(2131)는 스크린 상에 HTML(Hypertext Mark-up Language) 페이지들을 렌더(render)할 수 있으며, W3C 규격에 따른 다큐먼트들(documents)를 파싱할 수 있다.

IMS 게이트웨이(2150)는 IG-OITF 서버(2151), 네트워크 디스커버리(2152), 인증/세션 매니지먼트 클라이언트/서버(2153)과 RMS(2154)를 포함할 수 있다. 상기 IG-OITF 서버(2151)은 요구되는 HTTP 및/또는 다른 프로토콜들을 통해 관리된 IPTV 서비스들을 위한 OITF에 인증 및 세션 매니지먼트 클라이언트/서버 펑셔낼러티들(authentication and session management client/server functionalities)을 노출(expose)시킬 수 있다. 상기 네트워크 디스커버리(2152)는 IMS 서비스에 접속 및 디스커버리를 책임진다. 상기 인증/세션 매니지먼트 클라이언트/서버(2153) 관리된 환경 어떤 세션 매니지먼트와 가입자 인증을 책임진다. 상기 RMS(2154)는 관리된 환경에서 원격 매니지먼트 펑션들을 책임질 수 있다.

이상 상술한 본 발명에서는 Manufacturer가 일반적인 PVR Service Widget Component를 Widget Application에서 사용할 수 있는 구조를 설명하였다. 이것은 위젯 런타임이나 프레임워크라고 불리우는 미들웨어에 디지털 TV에 사용되는 PVR 저장부를 제어하는 위젯 오브젝트(Widget Object)를 정의를 한 것이다. 또한, PVR Widget Object를 수신기에서 구현하였을 때 필요한 메쏘드(Method)들을 정의하였다. 한편으로는 PVR 위젯 애플리케이션을 다운로드 하거나 사용자가 직접 PVR 서비스 위젯 컴포넌트를 이용하여 위젯을 만들 수 있도록 제조사측에서 API를 오픈 인터넷을 통하여 제공할 수 있다 뿐만 아니라 컨텐트를 전송하는 서비스 프로바이더에서는 수신기에 PVR 위젯 애플리케이션을 사용하도록 한다면, 엄격한 DRM 기능을 지원할 수 있을 뿐만 아니라 컨텐트의 실제 관리도 가능하다. 이것은 기본적으로 IPTV 및 인터넷이 가능한 Internet TV을 위한 PVR Extension과 함께 DRM Extension이 있으면 이것도 가능할 것이다.

컨텐츠 프로바이더 또는 서비스 프로바이더는 IPTV에서 녹화 및 재생 가능한 컨텐츠를 제어할 수 있다는 것은 상술한 바와 같이 명백하다. 또한, 사용자 친화적인 인터페이사들을 제공하는 위젯들은 사용자가 다운로드된 위젯들을 이용하여 자신의 IPTV 수신기의 기능들을 녹화하고 재생 기능들을 이용하고 선택된 위젯들을 다운로드 가능하도록 사용자에게 제공될 수 있다.

위에서 설명된 본 발명의 바람직한 실시예는 예시의 목적을 위해 개시된 것이고, 본 발명에 대한 통상의 지식을 가지는 당업자라면 본 발명의 사상과 범위 안에서 다양한 수정, 변경, 부가가 가능할 것이며, 이러한 수정, 변경 및 부가는 하기의 특허청구범위에 속하는 것으로 보아야 할 것이다.

2000: IPTV 수신기 2010: 네트워크 인터페이스
2020: TCP/IP 매니저 2030: 서비스 전달 매니저
2040: 역다중화부 2050: 시그널링 정보 디코더
2060: A/V 프로세서 2070: 디스플레이 유닛
2080: 서비스 제어 매니저 2090: 서비스 디스커버리 매니저
2100: 메타데이터 매니저 2110: SI&메타데이터 데이터베이스
2120: 애플리케이션 매니저 2130: 위젯 프로세서
2140: 유저 프로필 & 프리퍼런시즈 저장부

Claims

청구항 1은(는) 설정등록료 납부시 포기되었습니다.

IPTV(Internet Protocol Television) 수신기에서 IPTV 서비스를 처리하는 방법에 있어서,
서버(server)를 액세스하는 단계;
상기 액세스한 서버로 수신기 프로파일(receiver profile)을 전송하는 단계;
상기 전송된 수신기 프로파일에 기초하여 상기 액세스한 서버로부터 이용 가능한 위젯 애플리케이션 리스트(widget application list)를 수신하는 단계;
상기 수신한 이용 가능한 위젯 애플리케이션 리스트를 디스플레이하는 단계;
상기 디스플레이된 이용 가능한 위젯 애플리케이션 리스트로부터 하나의 위젯 애플리케이션을 선택받는 단계;
상기 선택받은 위젯 애플리케이션을 인스톨(install)하는 단계;
컨텐트(content)를 포함한 IPTV 서비스를 수신하는 단계;
브라우저(browser)에서 상기 인스톨된 위젯 애플리케이션을 실행하는 단계; 및
상기 실행된 위젯 애플리케이션을 통하여 상기 IPTV 서비스에 포함된 컨텐트를 처리하여 디스플레이하는 단계를 포함하되,
상기 인스톨된 위젯 애플리케이션은 PVR(Personal Video Recorder) 위젯 애플리케이션이고,
상기 IPTV 수신기는, PVR 위젯 애플리케이션을 위하여 API(Application Programming Interface)를 포함하고,
상기 API는, 상기 PVR 위젯 애플리케이션의 기능으로 트릭 플레이(trick play), 예약 녹화(scheduled recording), 녹화된 컨텐트의 편집(editing), 타임-쉬프트(time-shift) 기능 중 적어도 하나의 기능을 호출하고,
상기 선택된 위젯 애플리케이션과 관련된 유저 설정(user setting)이 포함된 유저 프로파일(user profile)을 저장하고, 상기 유저 프로파일을 포함한 PVR 위젯 애플리케이션의 구성 정보(configuration information)는 상기 서버에 저장되어 상기 서버와 IP 연결된 어느 위치의 디바이스에서 상기 PVR 위젯 애플리케이션을 실행되도록 하는 IPTV 수신기에서 IPTV 서비스 처리 방법.
삭제
청구항 3은(는) 설정등록료 납부시 포기되었습니다.

제1항에 있어서,
상기 수신기 프로파일은, 상기 IPTV 수신기에 대응하는 이용 가능한 PVR 기능에 대한 PVR 엘레멘트(element)를 포함하는 것을 특징으로 하는 IPTV 서비스 처리 방법.
청구항 4은(는) 설정등록료 납부시 포기되었습니다.

제3항에 있어서,
상기 PVR 엘레멘트는, 플레이 백 컨트롤(playback control) 엘레멘트, 스트림 에디터(stream editor) 엘레멘트, 컨텐트 매니저(content manager) 엘레멘트 및 타임 쉬프트 엘레멘트를 포함하는 것을 특징으로 하는 IPTV 서비스 처리 방법.
청구항 5은(는) 설정등록료 납부시 포기되었습니다.

제4항에 있어서,
상기 PVR 엘레멘트는, 북마크(bookmark) 엘레멘트를 더 포함하는 것을 특징으로 하는 IPTV 서비스 처리 방법.
삭제
삭제
청구항 8은(는) 설정등록료 납부시 포기되었습니다.

제1항에 있어서,
상기 저장된 유저 프로파일을 상기 서버로 전송하는 단계를 더 포함하는 것을 특징으로 하는 IPTV 서비스 처리 방법.
청구항 9은(는) 설정등록료 납부시 포기되었습니다.

제5항에 있어서,
상기 플레이 백 컨트롤 엘레멘트는, 저장된 컨텐트 재생과 관련된 기능을 수행하는 엘레멘트, 저장된 컨텐트 재생을 중지시키는 엘레멘트, 저장된 컨텐트의 재생 스피드 제어에 관한 엘레멘트 및 재생 위치에 관한 엘레멘트를 포함하는 것을 특징으로 하는 IPTV 서비스 처리 방법.
청구항 10은(는) 설정등록료 납부시 포기되었습니다.

제5항에 있어서,
상기 플레이 백 컨트롤 엘레멘트는, 적어도 하나의 컨텐트 저장에 관련 된 기능을 수행하는 엘레멘트를 포함하고, 상기 저장은 임시 저장(instant recording), 예약 저장(prescheduled recording) 및 타임 쉬프트를 포함하는 것을 특징으로 하는 IPTV 서비스 처리 방법.
IPTV(Internet Protocol Television) 서비스를 처리하는 IPTV 수신기에 있어서,
위젯 애플리케이션들을 위한 적어도 하나의 APIs(Application Programming Interfaces)를 저장하는 저장 장치;
서버(server)로부터 컨텐트(content)를 포함한 IPTV 서비스와 수신기 프로파일(receiver profile)에 기초하여 이용 가능한 위젯 애플리케이션 리스트(widget application list)를 수신하고, 상기 이용 가능한 위젯 애플리케이션 리스트로부터 선택된 위젯 애플리케이션을 다운로드(download)하는 제1 수신부;
상기 이용 가능한 위젯 애플리케이션 리스트로부터 상기 위젯 애플리케이션 선택을 위한 제1 요청을 수신하고, 상기 선택된 위젯 애플리케이션의 실행을 위한 제2 요청을 수신하고, 실행된 위젯 애플리케이션을 통하여 상기 IPTV 서비스 내 포함된 컨텐트의 처리를 위한 제3 요청을 수신하는 제2 수신부;
상기 수신된 이용 가능한 위젯 애플리케이션 리스트를 화면상에 디스플레이되도록 제어하고, 상기 제1 요청에 따라 상기 다운로드된 위젯 애플리케이션의 인스톨(install)하고, 상기 제2 요청에 따라 상기 인스톨된 위젯 애플리케이션을 브라우저(browser)상에서 실행하고, 상기 제3 요청에 따라 상기 실행된 위젯 애플리케이션을 통하여 상기 컨텐트를 처리하고 디스플레이되도록 제어하는 제어부; 및
상기 브라우저를 통하여 상기 인스톨된 위젯 애플리케이션을 위한 페이지(page)를 렌더링(rendering)하는 UI(User Interface) 매니저를 포함하되,
상기 인스톨된 위젯 애플리케이션은 PVR(Personal Video Recorder) 위젯 애플리케이션이고,
상기 API는, 상기 PVR 위젯 애플리케이션의 기능으로 트릭 플레이(trick play), 예약 녹화(scheduled recording), 녹화된 컨텐트의 편집(edit), 타임-쉬프트(time-shift) 기능 중 적어도 하나의 기능을 호출하고,
상기 제어부는, 상기 선택된 위젯 애플리케이션과 관련된 유저 설정(user setting)을 포함한 유저 프로파일(user profile)이 저장되도록 제어하고, 상기 유저 프로파일이 포함된 상기 PVR 위젯 애플리케이션의 구성 정보(configuration information)를 상기 서버에 저장되도록 상기 저장 장치를 제어하여 상기 서버와 IP 연결된 어느 위치의 디바이스에서 상기 PVR 위젯 애플리케이션을 실행되도록 제어하는 IPTV 수신기.
제11항에 있어서,
상기 제어부는, 상기 IPTV 수신기에서 이용 가능한 PVR 기능에 대한 PVR 엘레멘트(element)를 포함한 상기 수신기 프로파일을 상기 서버로 전송하도록 제어하는 IPTV 수신기.
삭제
제12항에 있어서,
상기 PVR 엘레멘트는, 플레이 백 컨트롤(playback control) 엘레멘트, 스트림 에디터(stream editor) 엘레멘트, 컨텐트 매니저(content manager) 엘레멘트 및 타임 쉬프트 엘레멘트를 포함하는 것을 특징으로 하는 IPTV 수신기.
제14항에 있어서,
상기 PVR 엘레멘트는, 북마크(bookmark) 엘레멘트를 더 포함하는 것을 특징으로 하는 IPTV 수신기.
삭제
삭제
제12항에 있어서,
상기 제어부는, 상기 저장된 유저 프로파일을 서버로 전송하는 것을 특징으로 하는 IPTV 수신기.
제15항에 있어서,
상기 플레이 백 컨트롤 엘레멘트는, 저장된 컨텐트 재생과 관련된 기능을 수행하는 엘레멘트, 저장된 컨텐트 재생을 중지시키는 엘레멘트, 저장된 컨텐트의 재생 스피드 제어에 관한 엘레멘트 및 재생 위치에 관한 엘레멘트를 포함하는 것을 특징으로 하는 IPTV 수신기.
제15항에 있어서,
상기 플레이 백 컨트롤 엘레멘트는, 적어도 하나의 컨텐트 저장에 관련된 기능을 수행하는 엘레멘트를 포함하고, 상기 저장은 임시 저장(instant recording), 예약 저장(prescheduled recording) 및 타임 쉬프트를 포함하는 것을 특징으로 하는 IPTV 수신기.