KR102040623B1 - 양방향 서비스를 처리하는 장치 및 방법 - Google Patents

양방향 서비스를 처리하는 장치 및 방법 Download PDF

Info

Publication number
KR102040623B1
KR102040623B1 KR1020157010988A KR20157010988A KR102040623B1 KR 102040623 B1 KR102040623 B1 KR 102040623B1 KR 1020157010988 A KR1020157010988 A KR 1020157010988A KR 20157010988 A KR20157010988 A KR 20157010988A KR 102040623 B1 KR102040623 B1 KR 102040623B1
Authority
KR
South Korea
Prior art keywords
trigger
application
activation
receiver
event
Prior art date
Application number
KR1020157010988A
Other languages
English (en)
Other versions
KR20150090049A (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 KR20150090049A publication Critical patent/KR20150090049A/ko
Application granted granted Critical
Publication of KR102040623B1 publication Critical patent/KR102040623B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4122—Peripherals receiving signals from specially adapted client devices additional display device, e.g. video projector
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H04N21/41265—The peripheral being portable, e.g. PDAs or mobile phones having a remote control device for bidirectional communication between the remote control device and client device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Abstract

디지털 서비스 신호를 처리하는 방법 및 장치가 개시된다. 본 발명은 상기 디지털 서비스 신호에 대한 프라이머리 애플이케이션을 실행하는 단계, 상기 프라이머리 애플리케이션은 트리거된 애플리케이션 또는 트리거되지 않은 애플리케이션이고; 상기 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지를 송신하는 단계, 상기 인터랙티브 서비스는 상기 트리거된 애플리케이션에 관련된 제1 모드 및 상기 트리거되지 않은 애플리케이션에 관련된 제2 모드를 포함하고; 상기 인터랙티브 서비스를 식별하는 기술(description)에 대한 요청을 수신하는 단계; 상기 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 상기 인터랙티브 서비스의 각각의 타입을 나타내는 서비스 타입 정보를 갖는 기술을 송신하는 단계; 및 상기 인터랙티브 서비스에 대한 정보를 송신함으로써 상기 인터랙티브 서비스를 제공하는 단계를 포함한다.

Description

양방향 서비스를 처리하는 장치 및 방법{APPARATUS AND METHOD FOR PROCESSING AN INTERACTIVE SERVICE}
본 발명은 방송 서비스를 제공하고 이를 수신 처리 하기 위한 방법 및 장치에 관한 것이다. 보다 상세하게는, 방송 콘텐트와 관련된 부가 서비스를 제공하는 방법 및 장치에 관한 것이다.
TV는 19세기 말에 처음 등장한 이후, 화면 표시 방법이나 디자인 등이 지속적으로 발전하면서 20세기 후반부터 가장 대중적인 정보 전달 기기로 확고히 자리잡았다. 다만, 방송국에서 전해주는 단방향의 정보를 시청자들이 일방적으로 수용한다는 근본적인 형태를 가지고 있었다. 이러한 TV의 한계는 1990년대부터 PC(개인용컴퓨터) 및 인터넷이 대중화되면서 더욱 분명하게 부각되기 시작했다. 이에 TV는 쌍방향 서비스가 가능한 방향으로 진화를 하고 있다.
그러나, 현재 콘텐츠 제공자와 시청자 사이에 이러한 양방향 서비스를 본격적으로 실행할 시스템이 부재한 실정이다. 특히 이러한 양방향 서비스의 제공을 위해 방영중인 방송 콘텐츠와 관련된 어플리케이션을 특정 시점에 구동하고, 정보의 특정 처리를 통해, 시청자에게 관련 정보를 제공하는 방법 및 포맷에 관한 기술적 지원이 필요한 상황이다.
본 발명이 이루고자 하는 기술적 과제는, 전술한 문제점을 해결하기 위한 것으로, 방송 콘텐트가 재생되는 기간 중 적절한 시기에 방송 콘텐트와 관련된 부가 정보를 제공하는 것에 있다.
본 발명의 목적은 디지털 서비스 신호를 처리하는 방법으로서, 상기 디지털 서비스 신호에 대한 프라이머리 애플이케이션을 실행하는 단계, 상기 프라이머리 애플리케이션은 트리거된 애플리케이션 또는 트리거되지 않은 애플리케이션임; 상기 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지를 송신하는 단계, 상기 인터랙티브 서비스는 상기 트리거된 애플리케이션에 관련된 제1 모드 및 상기 트리거되지 않은 애플리케이션에 관련된 제2 모드를 포함함; 상기 인터랙티브 서비스를 식별하는 기술(description)에 대한 요청을 수신하는 단계; 상기 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 상기 인터랙티브 서비스의 각각의 타입을 나타내는 서비스 타입 정보를 갖는 기술을 송신하는 단계; 및 상기 인터랙티브 서비스에 대한 정보를 송신함으로써 상기 인터랙티브 서비스를 제공하는 단계를 포함하는 방법에 의해 달성된다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보는 상기 인터랙티브 서비스의 각각에 따라 정의되고, 상기 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나이다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보가 트리거이면, 상기 트리거 중의 적어도 하나는 상기 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함한다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보가 트리거이면, 상기 방법은 TPT 내의 정보와 결합함으로써 상기 트리거를 증가(augment)시키는 단계, 상기 TPT는 상기 트리거된 애플리케이션에 대한 메타데이터를 포함함; 및 상기 트리거 내에서 식별된 이벤트를 나타내는 이벤트 지시자를 갖는 증가된 트리거를 송신하는 단계를 더 포함한다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보가 바이트이면, 상기 인터랙티브 서비스는 상기 애플리케이션이 실행되어 상기 세컨더리 애플리케이션과의 통신에 참여할 준비가 되어 있는지를 나타내는 status 상태 변수를 포함하고, 상기 방법은 상기 satus 상태 변수를 설정하는 단계를 더 포함한다.
바람직하게, 상기 프라이머리 애플리케이션은 API를 이용하여 인터랙티브 서비스를 제공한다.
바람직하게, 상기 API는 바이트 및 바이트 인수(argument)에 대한 어드레스 및 포트에 관한 정보를 갖는 어드레스 인수를 포함한다.
바람직하게, 상기 방법은 상기 메시지를 송신하기 전에 상기 프라이머리 애플리케이션과 연관된 상기 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 수신하는 단계를 더 포함한다.
본 발명의 다른 형태에 있어서, 디지털 서비스 신호를 처리하는 방법으로서, 상기 디지털 서비스 신호에 대한 애플리케이션을 실행하는 단계; 상기 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지를 수신하는 단계; 상기 인터랙티브 서비스를 식별하는 기술(description)에 대한 요청을 전송하는 단계; 상기 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 상기 인터랙티브 서비스의 각각의 타입을 나타내는 서비스 타입 정보를 갖는 기술을 수신하는 단계; 상기 기술을 이용하여 적어도 하나의 인터랙티브 서비스를 액세스하는 단계, 상기 액세스하는 단계는 상기 적어도 하나의 인터랙티브 서비스에 대한 통지를 위한 프로토콜에 가입하는 단계, 상기 통지를 수신하는 단계, 및 상기 수신된 통지를 이용하여 상기 적어도 하나의 인터랙티브 서비스에 대한 정보를 수신하는 단계를 포함함; 및 상기 액세스된 인터랙티브 서비스에 대한 파일을 다운로드하는 단계를 포함하는 방법이 제공된다.
바람직하게, 상기 적어도 하나의 인터랙티브 서비스에 대한 정보는 상기 인터랙티브 서비스에 따라 정의되고, 상기 적어도 하나의 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나이다.
바람직하게, 상기 탐색된 인터랙티브 서비스에 대한 정보가 트리거이면, 상기 트리거 중의 적어도 하나는 상기 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함한다.
바람직하게, 상기 액세스된 인터랙티브 서비스에 대한 정보가 바이트이면, 상기 방법은 상기 수신된 통지를 이용하여 상기 인터랙티브 서비스가 시작될 준비가 되었는지를 결정하는 단계; 및 상기 수신된 통지를 이용하여 바이트를 송신하기 위한 접속에 대한 요청을 송신하는 단계를 더 포함한다.
바람직하게, 상기 방법은 상기 메시지를 수신하기 전에 상기 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 전송하는 단계를 더 포함한다.
본 발명의 다른 형태에 있어서, 디지털 서비스 신호를 처리하는 장치로서, 상기 디지털 서비스 신호에 대한 프라이머리 애플리케이션을 실행하도록 구성되는 실행 모듈, 상기 프라이머리 애플리케이션은 트리거된 애플리케이션 또는 트리거되지 않은 애플리케이션임; 상기 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지 및 상기 인터랙티브 서비스를 식별하는 기술(description)을 송신하도록 구성된 송신 모듈, 상기 인터랙티브 서비스 모듈은 상기 트리거된 애플리케이션에 관련된 제1 모드 또는 상기 트리거되지 않은 애플리케이션에 관련된 제2 모드를 포함하고, 상기 기술은 요청에 따라 송신됨; 상기 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 상기 인터랙티브 서비스의 각각의 타입을 나타내는 서비스 타입 정보를 갖는 기술에 대한 요청을 수신하도록 구성되는 수신 모듈; 및 상기 인터랙티브 서비스에 대한 정보를 송신함으로써 상기 인터랙티브 서비스를 제공하도록 구성되는 제공 모듈을 포함하는 장치가 제공된다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보는 상기 인터랙티브 서비스에 따라 정의되고, 상기 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나이다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보가 트리거이면, 상기 트리거 중의 적어도 하나는 상기 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함한다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보가 트리거이면, 상기 장치는 TPT 내의 정보와 결합함으로써 상기 트리거를 증가(augment)시키도록 구성되는 증가 모듈을 더 포함하고, 상기 TPT는 상기 트리거된 애플리케이션에 대한 메타데이터를 포함하고, 상기 송신 모듈은 또한 상기 트리거 내에서 식별된 이벤트를 나타내는 이벤트 지시자를 갖는 증가된 트리거를 송신한다.
바람직하게, 상기 인터랙티브 서비스에 대한 정보가 바이트이면, 상기 인터랙티브 서비스는 상기 애플리케이션이 실행되어 상기 세컨더리 애플리케이션과의 통신에 참여할 준비가 되어 있는지를 나타내는 status 상태 변수를 포함하고, 상기 장치는 또한 상기 satus 상태 변수를 설정하는 것을 포함한다.
바람직하게, 상기 프라이머리 API를 이용하여 인터랙티브 서비스를 제공한다.
바람직하게, 상기 API는 바이트 및 바이트 인수(argument)에 대한 어드레스 및 포트에 관한 정보를 갖는 어드레스 인수를 포함한다.
바람직하게, 상기 수신 모듈은 또한 상기 송신 모듈이 상기 메시지를 송신하기 전에 상기 프라이머리 애플리케이션과 연관된 상기 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 수신하도록 구성된다.
본 발명의 다른 형태에 있어서, 디지털 서비스 신호를 처리하는 장치로서, 상기 디지털 서비스 신호에 대한 애플리케이션을 실행하도록 구성되는 실행 모듈; 상기 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지 및 기술(description)을 수신하도록 구성되는 수신 모듈; 상기 인터랙티브 서비스를 식별하는 기술에 대한 요청을 전송하도록 구성되는 전송 모듈, 상기 기술은 상기 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 상기 인터랙티브 서비스의 각각의 타입을 나타내는 서비스 타입 정보를 가짐; 상기 기술을 이용하여 적어도 하나의 인터랙티브 서비스를 액세스하도록 구성되는 액세스 모듈, 상기 액세스 모듈은, 상기 적어도 하나의 인터랙티브 서비스에 대한 통지를 위한 프로토콜에 가입하고, 상기 통지를 수신하고, 상기 수신된 통지를 이용하여 상기 적어도 하나의 인터랙티브 서비스에 대한 정보를 수신함; 및 상기 액세스된 인터랙티브 서비스에 대한 파일을 다운로드하도록 구성되는 다운로드 모듈을 포함하는 장치가 제공된다.
바람직하게, 상기 적어도 하나의 인터랙티브 서비스에 대한 정보는 상기 인터랙티브 서비스에 따라 정의되고, 상기 적어도 하나의 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나이다.
바람직하게, 상기 탐색된 인터랙티브 서비스에 대한 정보가 트리거이면, 상기 트리거 중의 적어도 하나는 상기 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함한다.
바람직하게, 상기 액세스된 인터랙티브 서비스에 대한 정보가 바이트이면, 상기 액세스 모듈은 또한 상기 수신된 통지를 이용하여 상기 인터랙티브 서비스가 시작될 준비가 되었는지를 결정하고, 상기 수신된 통지를 이용하여 바이트를 송신하기 위한 접속에 대한 요청을 송신한다.
바람직하게, 상기 전송 모듈은 상기 수신 모듈이 상기 메시지를 수신하기 전에 상기 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 전송하도록 구성된다.
상술한 일반적인 설명과 다음의 본 발명의 상세한 설명은 단지 예시적이고 설명하기 위한 것으로 청구된 본 발명의 추가 설명을 제공하는 것으로 의도된다.
본 발명에 따르면, 기존 방송 시스템을 이용하여 방송 콘텐츠와 관련된 부가 정보를 제공할 수 있다.
본 발명에 따르면, 방송 콘텐츠와 관련된 부가 정보가 표시되어야 하는 시기를 검출하여, 적절한 시기에 부가 정보를 사용자에게 제공할 수 있다.
본 발명에 따르면, 제2 스크린 디바이스에 방송 컨텐츠와 연관된 부가정보를 제공할 수 있는 효과가 있다.
도 1은 일반적인 방송 스트림의 일 실시예를 나타낸 도면.
도 2는 기 생성된 콘텐츠의 경우에, 트리거 타이밍의 일 실시예를 나타낸 도면.
도 3은 라이브 콘텐트의 경우에, 트리거 타이밍의 일 실시예를 나타낸 도면.
도 4는 트리거 신택스의 일 실시예를 나타낸 도면.
도 5는 TDO 파라미터 테이블의 일 실시예를 나타낸 도면.
도 6은 TDO 파라미터 테이블 의 일 실시예를 나타낸 도면.
도 7은 'Frequency of Use' 속성 값들의 의미의 일 실시예를 나타낸 도면.
도 8은 'destination' 속성 값들의 의미의 일 실시예를 나타낸 도면.
도 9는 TDO 파라미터 테이블의 이진형태의 신택스의 일 실시예를 나타낸 도면.
도 10은 TDO 파라미터 테이블의 이진형태의 신택스의 일 실시예를 나타낸 도면.
도 11은 TDO 파라미터 테이블의 이진형태의 신택스의 일 실시예를 나타낸 도면.
도 12는 TDO 파라미터 테이블의 이진형태의 신택스의 일 실시예를 나타낸 도면.
도 13은 TDO 파라미터 테이블의 이진형태의 신택스의 일 실시예를 나타낸 도면.
도 14는 활성화 메시지 테이블 구조의 일 실시예를 나타낸 도면.
도 15는 URL 리스트 구조도의 일 실시예를 나타낸 도면.
도 16은 TPT들을 포함하는 프라이빗 섹션(private section)들의 이진 포맷의 일 실시예를 나타낸 도면.
도 17는 XML 문서로 인코딩된 URL 목록의 일 실시예를 나타낸 도면.
도 18은 addTriggerEventListener의 일 실시예를 나타낸 도면.
도 19는 removeTriggerEventListener의 일 실시예를 나타낸 도면.
도 20은 EventListener 타입의 정의의 일 실시예를 나타낸 도면.
도 21은 TriggerEvent 타입의 정의의 일 실시예를 나타낸 도면.
도 22는 WM 기법을 위한 아키텍처의 일실시예를 도시한 도면.
도 23은 FP 기법의 아키텍처의 일실시예를 도시한 도면.
도 24는 요청/응답 ACR 경우의 정적 활성화의 일 실시예를 도시한 도면.
도 25는 요청/응답 ACR 경우의 정적 활성화의 일 실시예를 도시한 도면.
도 26은 요청/응답 ACR 경우의 동적 활성화의 일 실시예를 도시한 도면.
도 27은 요청/응답 ACR 경우의 동적 활성화의 일 실시예를 도시한 도면.
도 28은 ACR 서버 활성화를 위한 아키텍처의 일 실시예를 도시한 도면.
도 29는 EndTime이 없는 경우 (a)와 경우 (b)에서의 활성화 트리거들의 일 실시예를 도시한 도면.
도 30은 EndTime이 없는 경우 (a)와 경우 (b)에서의 활성화 트리거들의 일 실시예를 도시한 도면.
도 31은 EndTime이 있는 경우 (a)의 활성화 트리거들의 일 실시예를 도시한 도면.
도 32는 EndTime이 있는 경우 (a)의 활성화 트리거들의 일 실시예를 도시한 도면.
도 33은 경우 (c)에 대한 활성화 트리거들의 일 실시예를 도시한 도면.
도 34는 경우 (c)에 대한 활성화 트리거들의 일 실시예를 도시한 도면.
도 35는 마지막에 전달되는 동적 활성화 트리거의 일 실시예를 도시한 도면.
도 36은 마지막에 전달되는 동적 활성화 트리거의 일 실시예를 도시한 도면.
도 37은 요청/응답 경우에서 ACR 클라이언트와 다른 서버 사이의 순서도.
도 38은 이벤트 주도형 ACR 경우에서 ACR 클라이언트와 다른 서버 사이의 순서도.
도 39 UPnP RemoteUI 클라이언트 서비스의 액션 리스트의 일 실시예이다.
도 40는 UPnP RemoteUI 클라이언트 서비스의 일 실시예이다.
도 41는 Trigger in DTVCC Service Number 6의 일 실시예이다.
도 42는 제2 스크린 시나리오용 시스템 아키텍쳐의 일 실시예이다.
도 43는 ATSC 2.0 수신기 및 제2 스크린 간의 토폴로지(직접 연결)의 일 실시예이다.
도 44는 ATSC 2.0 수신기 및 제2 스크린 간의 토폴로지(간접 연결)의 일 실시예이다.
도 45는 중앙집중형 실행 모델(Centeralized Execution model)의 동작 개념도의 일 실시예이다.
도 46는 중앙집중형 실행 모델 기반 수신기 및 제2 스크린 간의 연동에 대한 플로우의 일 실시예이다.
도 47는 분산형 실행 모델(Distributed Execution model)의 동작 개념도의 일 실시예이다.
도 48는 분산형 실행 모델 기반 수신기와 제2 스크린 간의 연동에 대한 플로우의 일 실시예이다.
도 49는 분산형 실행 모델 기반 수신기와 제2 스크린 간의 연동에 대한 플로우의 일 실시예이다.
도 50는 제2 스크린 서비스 애플리케이션의 소프트웨어층의 일 실시예이다.
도 51는 제2 스크린 서비스 애플리케이션의 소프트웨어층의 일 실시예이다.
도 52는 제2 스크린 애플리케이션 라이프사이클 관리에 따른 전송 순서와 전송 데이터의 차이를 나타낸 도표의 일 실시예이다.
도 53는 수신기가 제2 스크린 디바이스에게 UI 정보를 알려 주는 방법의 일 실시예이다.
도 54는 수신기가 제2 스크린 디바이스에게 UI 정보를 알려 주는 방법의 일 실시예이다.
도 55는 수신기가 제2 스크린 디바이스에게 TDO 및 이벤트 정보를 알려 주는 방법의 일 실시예이다.
도 56는 제2 스크린 디바이스가 TPT 및 제2 스크린 애플리케이션 접근 방법의 일 실시예이다.
도 57는 제2 스크린 디바이스가 TPT 및 제2 스크린 애플리케이션 접근 방법의 일 실시예이다.
도 58는 RemoteUI 서버 서비스를 위한 방송 시그널링의 일 실시예이다.
도 59는 RemoteUI 서버 서비스를 위한 방송 시그널링의 다른 실시예이다.
도 60는 제2 스크린 서비스를 위한 장치 디스커버리 및 장치 능력 교환의 일 실시예이다.
도 61는 UPnP 포럼의 DeviceProfile XML 스키마의 일 실시예이다.
도 62는 제2 스크린 디바이스의 디바이스 프로파일의 일 실시예이다.
도 63는 제2 스크린 서비스에 대한 Protocolnfo의 설명의 일 실시예이다.
도 64는 제2 스크린 디바이스에서 AddUIListing 및 RemoteUIListing이 실행되는 동안의 UIListing의 일 실시예이다.
도 65는 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예이다.
도 66는 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예이다.
도 67는 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예이다.
도 68는 ProcessInput 액션으로 제2 스크린 디바이스에 전달되는 "EventInfo"정보의 일 실시예이다.
도 69는 수신기와 제2 스크린 디바이스간의 구성의 일 실시예이다.
도 70는 서비스의 서비스 타입 및 서비스 ID의 일 실시예이다.
도 71는 트리거 전달 서비스의 동작 개념도의 일 실시예이다.
도 72는 확장된 활성화 트리거(expanded activation trigger) 생성 과정의 일 실시예이다.
도 73는 증가된 활성화 트리거(Augmented Activation Trigger)에 대한 XML 스키마 기술(Schema Description)의 일 실시예이다.
도 74는 URI_data()의 신택스의 일 실시예이다.
도 75는 URI_type의 의미의 일 실시예이다.
도 76는 증가되지 않은 트리거에 대한 XML 스키마 기술의 일 실시예이다.
도 77는 증가된 활성화 트리거의 포맷의 일 실시예이다.
도 78는 증가된 활성화 트리거의 포맷의 일 실시예이다.
도 79는 증가된 활성화 트리거의 포맷의 일 실시예이다.
도 80는 증가된 활성화 트리거의 포맷의 일 실시예이다.
도 81는 HTTP 롱 폴링 기반 어프로치(long polling based approach)에 따른 트리거 서비스 상태 변수의 일 실시예이다.
도 82는 HTTP 롱 폴링 기반 어프로치에 따른 트리거 서비스 액션의 일 실시예이다.
도 83는 HTTP 롱 폴링 기반 어프로치에 따른 GetTrigServerURL 액션의 인수(Arguments)의 일 실시예이다.
도 84는 트리거 서비스 상태 변수의 실시예를 나타내는 도면이다.
도 85는 트리거 서비스 액션의 실시예를 나타내는 도면이다.
도 86은 GetLatestUnfilteredTrigger 액션의 인수의 실시예를 나타내는 도면이다.
도 87은 GetLatestFilteredTrigger 액션의 인수의 실시예를 나타내는 도면이다.
도 88은 UPnP 이벤팅 메커니즘 기반 어프로치의 실시예이다.
도 89는 트리거 서비스 상태 변수의 실시예를 나타내는 도면이다.
도 90는 트리거 서비스 액션의 실시예를 나타내는 도면이다.
도 91은 트리거 전달 서비스를 통해 트리거를 획득할 때 제2 스크린 상의 동작의 실시예를 나타내는 도면이다.
도 92는 트리거 전달 서비스의 동작 개념을 나타내는 도면이다.
도 93은 제1 어프로치에 따른 양방향 통신 서비스 상태 변수의 일 실시예이다.
도 94는 제1 어프로치에 따른 ClientList 상태 변수의 XML 스키마 테이블의 일 실시예이다.
도 95는 제1 어프로치에 따른 트리거 서비스 액션의 일 실시예이다.
도 96는 제1 어프로치에 따른 SignUp 액션의 인수의 일 실시예이다.
도 97는 제1 어프로치에 따른 SignOff 액션의 인수의 일 실시예이다.
도 98는 제2 어프로치에 따른 양방향 통신 서비스 상태 변수의 일 실시예이다.
도 99는 제2 어프로치에 따른 onBytesReceived 함수의 일 실시예이다.
도 100는 제2 어프로치에 따른 setStatusYes()의 일 실시예이다.
도 101는 제2 어프로치에 따른 setStatusNo()의 일 실시예이다.
도 102는 제2 어프로치에 따른 setStatus()의 일 실시예이다.
도 103는 제2 어프로치에 따른 sendBytes()의 일 실시예이다.
도 104는 AppURL 서비스 상태 변수의 일 실시예이다.
도 105는 AppURL 서비스 액션의 일 실시예이다.
도 106는 GetAppURL 액션의 인수의 일 실시예이다.
도 107는 프록시 HTTP 서버 서비스(Proxy HTTP Server service)의 동작 개념도의 일 실시예이다.
도 108는 프록시 서버 서비스 상태 변수(Proxy Server Service State Variable)의 일 실시예이다.
도 109는 프록시 서버 서비스 액션(Proxy Server Service Action)의 일 실시예이다.
도 110는 GetProxyURL 액션의 인수의 일 실시예이다.
도 111는 RequestFiles()의 일 실시예이다.
도 112는 제2 스크린 디바이스 아키텍쳐의 일 실시예이다.
도 113는 수신기의 간략화된 구조도의 일 실시예이다.
도 114는 제2 스크린 디바이스의 구조도의 일 실시예이다.
도 115는 제2 스크린 디바이스 시나리오의 일 실시예이다.
도 116는 제1 디바이스에서 인터랙티브 서비스를 처리하는 방법의 일 실시예이다.
도 117는 제2 디바이스에서 실행되는 제2 스크린 애플리케이션에서 인터랙티브 서비스를 처리하는 방법의 일 실시예이다.
도 118는 제1 디바이스로서 인터랙티브 서비스를 처리하는 장치의 일 실시예이다.
도 119는 제2 디바이스에서 실행되는 제2 스크린 애플리케이션으로서 인터랙티브 서비스를 처리하는 장치의 일 실시예이다.
본 명세서에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도, 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한 특정 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 아닌 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다.
본 명세서에서 미디어 시간은 오디오/비디오 또는 오디오 콘텐트 아이템의 재생(playout) 중 어느 지점을 참조하는 파라미터를 말한다. ACR는 자동 콘텐트 인식(Automatic Content Recognition)을 나타낸다. AMT는 활성화 메시지 테이블(Activation Messages Table)을 나타낸다. API는 어플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 나타낸다. DAE는 선언적 응용 환경(Declarative Application Environment)을 나타낸다. DO는 선언적 객체(Declarative Object)를 나타낸다. FLUTE는 단방향 전송을 통한 파일 전달(File Delivery over Unidirectional Transport)을 나타낸다. GPS는 위치확인시스템(Global Positioning System)을 나타낸다. HTTP는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)을 나타낸다. IP는 인터넷 프로토콜(Internet Protocol)을 나타낸다. IPTV는 인터넷 프로토콜 텔레비전(Internet Protocol Television)을 나타낸다. iTV는 양방향 텔레비전(Interactive Television)을 나타낸다. MIME는 인터넷 미디어 타입(Internet Media Type)을 나타낸다. NDO는 NRT 선언적 객체(NRT Declarative Object)를 나타낸다. NRT는 비실시간(Non-Real Time)을 나타낸다. SMT는 서비스 맵 테이블(Service Map Table)을 나타낸다. SSC는 서비스 시그널링 채널(Service Signaling Channel)을 나타낸다. TDO는 트리거된 선언적 객채(Triggered Declarative Object)를 나타낸다. TPT는 TDO 파라미터 테이블(TDO Parameters Table)을 나타낸다. UDO는 언바운드 선언적 객체(Unbound Declarative Object)를 나타낸다. UPnP는 유저 플러그 앤 플레이(User Plug and Play)를 나타낸다. URI는 통합 자원 식별자(Uniform Resource Identifier)를 나타낸다. URL은 자원위치 표시자(Uniform Resource Locator)를 나타낸다. XML는 확장성 생성 언어(eXtensible Markup Language)를 나타낸다. TFT는 텍스트 프래그먼트 테이블(Text Fragment Table)을 나타낸다. 자세한 내용은 후술한다.
이 명세서에서, DO, TDO, NDO, UDO는 다음과 같은 의미일 수 있다.
DO (Declarative Object)는 양방향 어플리케이션(예를 들어, HTML, JavaScript, CSS, XML 및 멀티미디어 파일)을 구성하는 컬렉션(collection)일 수 있다.
트리거된 양방향 부가 데이터 서비스에 의해 개시된 선언적 객체 또는 트리거에 의해 개시된 DO에 의해 실행된 DO 등을 지정하기 위해 "트리거된 선언적 객체(TDO)"를 사용한다.
트리거된 양방향 데이터 서비스가 아닌 NRT 서비스의 일부로서 실행된 선언적 객체를 지정하기 위해 용어 "NRT 선언적 객체"(NDO)를 사용한다.
패키지형 앱과 같이 서비스에 바인드되지 않은 선언적 객체, 링크에 의해 실행된 DO, 또는 그와 같은 DO에 의해 실행된 DO 등을 지정하기 위해 "언바운드 선언적 객체(UDO)"라는 용어를 사용한다.
"링크"는 현재의 TV 프로그램 또는 NRT 서비스와 관련된 온라인 정보 또는 기능을 제공하는 웹사이트를 가리키는 방송국 제공 URL이다.
"패키지형 앱"은 방송국이 시청자에게 제공하고자 하는 정보 또는 기능을 제공하며 시청자가 다운로드하여 설치할 수 있는 하나의 파일로 묶인 방송국 제공 선언적 객체(DO)이다.
이에 대해 이하에서 상세히 설명한다.
이 명세서에서, 시간 베이스 메시지(time base message)는 시간 베이스 트리거 및 그 등가물을 포함한다. 따라서 "시간 베이스 메시지"는 "시간 베이스 트리거"와 혼용될 수 있다.
이 명세서에서, 활성화 메시지는 활성화 트리거 및/또는 AMT 내의 활성화 엘리먼트와 같은 활성화를 일으키는 모든 정보전달을 포함한다.
도 1는 일반적인 방송 스트림의 일 실시예를 나타낸 도면이다.
일반적인 방송 스트림은 TV 프로그램들의 시퀀스로 구성되어 있다. 각 TV 프로그램은 기본이 되는 쇼(show)로 구성되며, 쇼는 일반적으로 광고 및/또는 다른 개재물(interstitial material)에 의해 분리된 블록들로 나뉘어진다.
도 1 에서 방송스트림에 쇼 A(Show A) 세그먼트, 광고1(Ad1), 광고2(Ad2), 쇼 B(Show B) 세그먼트 등이 차례로 포함되어 있음을 알 수 있다. 각 쇼를 이루는 세그먼트들을 쇼 재료, 광고들을 개재물이라고 부를 수 있다.
각 쇼 또는 개재물은 연관된 양방향 부가 데이터 서비스를 가질 수 있다.
본 명세서에서는 통합 유닛으로서 방송국에 의해 다루어지는 양방향 부가 서비스의 일부를 지칭하기 위해 "양방향 서비스 세그먼트," 또는 단순히 "세그먼트"라는 용어를 사용한다. 양방향 서비스 세그먼트는 일반적으로 단일 쇼 또는 한 개의 개재물과 연관되지만, 반드시 그렇지는 않다.
이러한 양방향 부가 데이터 서비스를 실행하기 위해서는 두 가지 모델이 있을 수 있다. 직접 실행 모델과 트리거된 선언적 객체(Triggered Declarative Object; TDO) 모델이 그것이다.
직접 실행 모델에서는, 가상 채널이 선택되면 선언적 객체(Declarative Object; DO)가 자동으로 개시될 수 있다. DO는 스크린 상의 특정 위치에서의 화면의 생성, 여론 조사 수행, 다른 특수 DO들의 개시 등과 같이 오디오-비디오 프로그램과 동기화되는 양방향 특징들의 제공을 위한 구체적인 지시사항들을 얻기 위해 백엔드(backend) 서버와 인터넷을 통해 통신할 수 있다.
TDO 모델에서는, TDO의 개시, TOD의 종료, 또는 TDO에 의한 일부 작업의 유발과 같이 TDO 이벤트를 개시하기 위해 신호들을 방송 스트림으로 전달하거나 인터넷을 통해 전달할 수 있다. 이러한 이벤트들은 특정 시간에 개시될 수 있으며, 일반적으로 오디오-비디오 프로그램과 동기화된다. TDO가 개시되면, 프로그램된 대로 양방향 특징들을 제공할 수 있다.
TDO 모델의 기본 개념은, TDO를 구성하는 파일들 및 어떤 동작을 취하기 위해 TDO에 의해 사용되는 데이터 파일들은 모두 그 크기로 인하여 수신기에 전달되는데 일정한 양의 시간이 필요하다는 것이다. 양방향 엘리먼트들에 대한 사용자 경험은 콘텐트의 방송 전에 저작될 수 있지만, 어떤 거동들은 프로그램 내의 이벤트들, 예를 들어 상업 광고 세그먼트의 발생과 동시에 일어나도록 주의하여 시간이 맞추어져야 한다.
TDO 모델에서는 선언적 객체, 연관된 데이터, 스트립트, 텍스트 및 그래픽의 전달을 양방향 이벤트들의 재생에 대한 특정 타이밍의 시그널링과 구별한다.
양방향 이벤트들의 타이밍을 설정하는 엘리먼트는 트리거(Trigger)이다.
하나의 세그먼트 내에서 사용되는 TDO들과 트리거에 의해 개시되는 관련 TDO 이벤트들에 대한 정보는 "TDO 파라미터 테이블"(TPT)라고 불리는 데이터 구조에 의해 제공된다.
이하 트리거에 관하여 설명한다.
도 2는 기 생성된 콘텐트의 경우에, 트리거 타이밍의 일 실시예를 나타낸 도면 이다.
트리거는 시그널링을 식별하고 양방향 이벤트들의 재생 타이밍을 설정하는 기능을 하는 시그널링 엘리먼트이다.
트리거는 양방향 서비스와 관련된 세그먼트에 대한 미디어 시간을 지시하는 역할을 하는 시간 베이스 트리거와, 양방향 서비스와 관련된 어플리케이션의 이벤트 발생 시간을 지시하는 역할을 하는 활성화 트리거를 포함한다.
트리거들은 양방향 서비스의 지원을 위해 타이밍과 관련된 다양한 시그널링 기능들을 수행할 수 있다. 트리거들은 그 기능에 따라 다기능적일 수 있으며, 그 구조에 따라 특정 트리거 인스턴스(instance)는 다음 기능들 중 하나 이상을 수행할 수 있다.
1. TPT(방출 스트림 내 FLUTE 세션, 인터넷 서버, 또는 이들 모두를 통해 접근가능한 TPT)의 위치를 시그널링한다.
2. 다음 프로그램 세그먼트에 대한 양방향 콘텐트가 프리로딩(pre-load)될 수 있음을 지시한다.
3. 연관된 오디오/비디오 콘텐트 또는 오디오 콘텐트의 현재 미디어 시간(Media Time)을 지시한다.
4. TPT 내 특정 양방향 이벤트를 참조하고, 상기 이벤트가 지금 또는 특정한 미래 미디어 시간에 실행됨을 알린다.
5. 수요가 최대가 되는 것을 피하기 위해 인터넷 서버에 대한 접속들이 특정한 시간구간 상에서 랜덤하게 분산됨을 지시한다.
도 2는 두 개의 프로그래밍 세그먼트들과 연관되어 전달되는 트리거들을 나타낸다. 이 예에서는 두 세그먼트 모두 "기 생성"되는데, 이는 콘텐트가 라이브 콘텐트가 아니며 양방향 엘리먼트들은 추후 생성(post-production)으로 추가되었음을 의미한다.
도시된 바와 같이, 프로그래밍 세그먼트 1의 발생 전 짧은 시간에 "프리로드(pre-load)" 트리거가 전달되어 수신기들과 연관된 TPT 및 양방향 콘텐트를 획득할 수 있는 기회를 허용하도록 할 수 있다. 만일 프리로드 트리거가 전송되지 않으면, 수신기들은 콘텐트를 획득하기 위해 해당 세그먼트 내에서 만나는 첫 번째 트리거를 사용하는 것으로 생각할 수 있다.
도시된 바와 같이, 트리거들은 Segment 1을 통해 전송되어 해당 세그먼트에 대한 현재 미디어 시간(도면에서 "m"으로 표기)를 지시하도록 할 수 있다. 해당 채널을 만나는 트리거들이 양방향 콘텐트를 동기화하여 획득할 수 있도록 하기 위해, 미디어 시간 트리거들의 주기적인 전달이 필요할 수 있다.
Segment 2의 시작 직전에 해당 세그먼트에 대한 프리로드 트리거가 전송된다.
기 생성된 콘텐트(비라이브(non-live) 콘텐트)의 경우, 수신가가 첫 번째 트리거를 처리한 후 획득할 수 있는 TPT는 해당 세그먼트에 대한 양방향 경험의 모든 엘리먼트들의 타이밍을 정의할 수 있다. 해당 수신기와 TDO가 양방향 엘리먼트들을 재생하도록 하기 위해 필요한 것은 미디어 타이밍에 대한 지식일 수 있다. 상기 TPT는 미디어 시간에 대하여 양방향 이벤트들을 기술할 수 있다.
도 3은 라이브 콘텐트의 경우에, 트리거 타이밍의 일 실시예를 나타낸 도면이다.
라이브 콘텐트의 경우에도, TPT는 서로 다른 양방향 이벤트들과 관련된 데이터 및 정보를 포함하지만, 방송 중 프로그램 내 동작이 전개될 때까지는 그러한 이벤트들의 재생 타이밍은 알려지지 않을 수 있다. 이와 같은 라이브의 경우, 트리거의 "이벤트-타이밍(event-timing)" 기능이 활용된다. 이 모드에서 트리거는 특정한 양방향 이벤트가 새로운 특정 미디어 시간 값으로 재설정(re-timed)됨을 알릴 수 있다. 또는, 트리거는 어떤 이벤트가 즉시 실행됨을 지시할 수 있다.
도 3에서 Segment 3에 대한 각 트리거의 기능은 다음과 같다.
1번 트리거는 프리로드 트리거로서, 세그먼트 3에 관한 파일들을 얻을 수 있는 디렉토리를 참조한다.
2번 트리거는 미디어 시간 트리거로서, Segment 3에 대한 재생 타이밍을 지시하기 위해 사용된다.
3번 트리거는 이벤트 리타이밍(re-timing) 트리거로서, TPT에서 eventID = 2인 이벤트가 미디어 시간 240에 발생하도록 시간이 재설정됨을 지시한다. 빗금 친 영역은 3번 트리거가 수신기들에 전달될 수 있는 240 이전의 시간 구간을 지시한다.
4번 트리거는 미디어 시간 트리거이다.
5번 트리거는 이벤트 리타이밍 트리거로서, TPT에서 eventID = 5인 이벤트가 미디어 시간 444에 발생하도록 시간이 재설정됨을 지시한다.
6번, 7번 트리거는 미디어 시간 트리거이다.
8번 트리거는 이벤트 트리거로서, TPT에서 eventID = 12인 이벤트가 즉시 실행됨을 지시한다.
9번 트리거는 이벤트 리타이밍 트리거로서, TPT에서 eventID = 89인 이벤트가 미디어 시간 900에 발생하도록 시간이 재설정됨을 지시한다.
이하 TDO의 라이프 사이클(life cycle)과 상태, 및 상태 변화 이벤트에 대해 설명한다.
TDO는 해제(Released), 준비(Ready), 활동(Active), 및 중지(Suspended)의 서로 다른 네 가지 상태로 존재할 수 있다. 상이한 많은 요소들(트리거, 유저 동작, 변경되는 채널들, 등)이 하나의 상태에서 다른 상태로의 변동을 야기할 수 있다.
TDO는 다음 네 가지 상태를 포함할 수 있다. 네 가지 상태들은 준비(Ready), 활동(Active), 중지(Suspended) 및 해제(Released)이다. 준비 상태는 TDO가 다운로드되어 실행 준비가 되었지만, 아직 실행되지 않음을 의미한다. 활동 상태는 TDO가 실행중임을 의미한다. 중지 상태는 이 상태의 저장과 함께 TDO의 실행이 일시적으로 중지됨을 의미한다. 해제 상태는 TDO가 준비, 활동 또는 중지 상태가 아님을 의미한다.
TDO에 대한 상태 변화를 일으킬 수 있는 이벤트들 중 일부는 다음과 같다.
1. "prepare" 트리거: 장치는 TDO가 실행(자원 할당, 주 메모리로의 로딩, 등)을 하도록 준비되기를 요청하는 트리거를 (현재 선택된 1차 가상 채널에서) 수신한다.
2. "execute" 트리거: 장치는 TDO의 활성화를 요청하는 트리거를 (현재 선택된 1차 가상 채널에서) 수신한다.
3. "suspend" 트리거: 장치는 TDO의 중지를 지시하는 트리거를 (현재 선택된 1차 가상 채널에서) 수신한다.
4. "kill" 트리거: 장치는 TDO의 종료를 지시하는 트리거를 (현재 선택된 1차 가상 채널에서) 수신한다.
도 4는 트리거 신택스의 일 실시예를 나타낸 도면이다.
활성화 메시지와 시간 베이스 메시지들은 모두 일정 전송 환경에서 일반적인 "트리거" 포맷을 가질 수 있다.
여기에서 신택스 상의 정의는, 얼터너티브(alternative)들을 지정하기 위해 수직 바 심볼 "|"이 사용되는 경우 이외에는 ABNF (Augmented Backus-Naur Form) 문법을 사용하여 기술한다. 룰(rule)들은 등호 "="에 의해 정의들과 분리되며, 하나 이상의 줄에 걸쳐 룰 정의를 계속할 때는 들여쓰기를 이용하고, 리터럴(literal)들은 큰따옴표 ""로 인용하고, 엘리먼트들의 그룹화에는 괄호 "("와 ")"를 이용하고, 선택적인 엘리먼트들은 "["와 "]" 사이에 넣는다. 그리고 엘리먼트들 앞에 <n>*이 붙으면 그 뒤의 엘리먼트의 n번 이상의 반복을 지정할 수 있고, n은 기본값으로 0으로 설정된다. 그리고 엘리먼트들 앞에 <n>*<m>이 붙으면 그 다음에 오는 엘리먼트의 n번 이상 m번 이하의 반복을 지정할 수 있다.
이러한 트리거 신택스는 <scheme>과 "://" 부분을 제외하고 부가적인 제한사항들과 함께 URI (Uniform Resource Identifier): 제너릭 신택스(Generic Syntax)를 바탕으로 한다.
트리거는 locator_part와 terms로 이루어 질 수 있다. terms는 생략 가능한 구성이다. terms가 존재한다면 locator_part와 terms는 '?'로 연결될 수 있다.
locator_part는 hostname 부분과 path_segments 부분으로 이루어 질 수 있고, 그 사이는 '/' 로 연결될 수 있다.
hostname은 domainlabel 과 toplabel로 이루어 질 수 있고, domainlabel은 그 뒤에 '.' 과 함께 0번 이상 반복될 수 있다. 즉, hostname은 반복된 domainlabel가 toplabel과 연결된 형태, 또는 toplabel만으로 이루어진 형태일 수 있다.
domainlabel은 alphanum 하나로 이루어진 형태일 수 있다. 또는 두 alphanum 사이에 alphanum 또는 '-' 가 0번이상 반복된 것이 끼여있는 형태일 수 있다.
여기서 alphanum은 alpha 또는 digit을 의미할 수 있다.
여기서 alpha는 lowalpha 또는 upalpha 중 하나 일 수 있다.
여기서 lowalpha 는 a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z 중 하나 일 수 있다.
여기서 upalpha는 A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z 중 하나일 수 있다.
여기서 digit은 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 중 하나일 수 있다.
toplabel은 alpha 하나로 된 형태일 수 있다. 또는 alpha와 alkphanum 사이에 alphanum 또는 '-'가 0번 이상 반복된 것이 끼여있는 형태일 수 있다.
path_segments는 세그먼트 하나가 있고, 그 뒤로 세그먼트가 0번 이상 반복된 것이 뒤따르는 형태일 수 있다. 이 때 세그먼트 사이는 '/' 로 연결될 수 있다.
여기서 세그먼트는 alphanum이 1회 이상 반복된 형태일 수 있다.
terms는 event_time 또는 media_time 중 하나로 이루어진 형태일 수 있다. 그 뒤로 spread 또는 others가 뒤따를 수 있다. spread와 others는 생략가능한 구성일 수 있다. spread와 others가 존재한다면 이는 '&' 를 앞에 두고 있는 형태로 event_time 또는 media_time의 뒤에 있을 수 있다.
여기서 spread는 's=' 뒤에 digit이 1회 이상 반복된 것이 뒤따르는 형태일 수 있다.
event_time은 'e=' 뒤로 digit이 1회 이상 반복된 것이 뒤따르는 형태일 수 있다. 또는 그 뒤로 '&t=' 뒤에 hexdigit이 1회 이상 7회 이하 반복된 것이 뒤따르는 형태일 수 있다. '&t=' 과 그 뒷부분은 생략가능한 구성일 수 있다.
여기서 hexdigit은 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f 중 하나일 수 있다.
media_time은 'm=' 뒤로 hexdigit이 1회 이상 7회 미만 반복된 것이 뒤따르는 형태일 수 있다.
others는 other 하나로 이루어진 형태일 수 있다. 또는 그 뒤로 '&' 과 other가 뒤따르는 것이 추가된 형태일 수 있다.
여기서 other는 resv_cmd와 alphanum 이 1회 이상 반복된 것이 '=' 에 의해 연결된 형태일 수 있다.
여기서 resv_cmd는'c', 'e', 'E', 'm', 'M', 's', 'S', 't', 'T' 를 제외한 alphanum일 수 있다.
트리거의 길이는 52 bytes를 넘지 않을 수 있다. 그리고 트리거의 hostname 부분은 등록된 인터넷 도메인 이름일 수 있다.
트리거는 세 부분으로 구성되는 것으로 볼 수 있다.
<domain name part> / <directory path> [ ? <parameters> ]
<domain name part>는 등록된 도메인 이름일 수 있고, <directory path>는 도메인 이름이 URI에서 등장하게 될 경로일 수 있다.
<domain name part>는 등록된 인터넷 도메인 이름을 참조할 수 있다. <directory path>는 식별된 도메인 이름에 대한 권한을 가지는 엔티티(entity)의 제어 및 관리 하에서 디렉토리 경로를 식별하는 임의의 문자열일 수 있다.
TDO 모델에서, <domain name part>와 <directory path>의 조합은 연관된 콘텐트에 양방향성을 추가하기 위해 수신기에 의해 처리될 수 있는 TPT를 고유하게 식별할 수 있다.
<domain name part>와 <directory path>의 조합은 현재 세그먼트에 대한 TPT를 얻을 수 있는 인터넷 위치의 URL일 수 있다.
즉, 트리거는 <domain name part>와 <directory path>를 이용해서 TPT를 식별해 낼 수 있고, 이를 통해 트리거가 적용될 TPT를 알 수 있다. 해당 트리거가 TPT에 적용되어 어떤 역할을 수행하게 될 것인지는 <parameters> 부분에 달려 있다.
이하 <parameters> 부분에 대해서는 설명한다.
<parameters>는 "event_time", "media_time", 또는 "spread" 중 하나 이상으로 구성될 수 있다.
다음은 도 4 에서 보았던 신택스 중 "event_time", "media_time", "spread" 에 관한 부분이다.
event_time = "e=" 1*digit [ "&t=" 1*7hexdigit ]
media_time = "m=" 1*7hexdigit
spread = "s=" 1*digit
"event_time" 항은 타겟이 된 이벤트("e=" 항)와 해당 이벤트가 활성화되어야 할 시간("t=" 항)을 식별하기 위해 활성화 트리거에서 사용될 수 있다. "t=" 항이 없으면, 이는 트리거가 도달하는 시간에 이벤트가 활성화되어야 함을 의미한다.
즉, 양방향 이벤트 ID 항인 "e="는 해당 이벤트의 타겟인 TDO의 연관된 TPT 내의 appID, 해당 특정 이벤트의 eventide, 및 이 이벤트 활성화를 위해 사용될 데이터 엘리먼트의 dataID를 참조할 수 있다,
선택적인 타이밍 값 항인 "t=" 지정된 이벤트를 위한 새로운 미디어 타이밍을 지시할 수 있다. "t=" 부분이 존재하지 않으면, 이는 지정된 이벤트를 위한 타이밍이 트리거의 도달 시점임을 의미할 수 있다.
"media_time" 항("m=" 항)은 시간 베이스 트리거에 의해 나타내어지는 시간 베이스에 대한 현재 시간을 식별하기 위해 시간 베이스 트리거에서 사용될 수 있다. 그리고 현재 보여지는 콘텐츠를 식별할 수 있는 콘텐트 식별자 정보("c=" 항)이 media_time에 더 포함될 수 있다. "c=" 항에 대해서는 직접 실행 모델에 대한 설명에서 후술한다.
즉, "m="은 그 뒤에 16진수를 나타내는 1 내지 8 문자 길이의 문자열이 이어지는 미디어 타임스탬프(timestamp) 항으로서, 현재의 미디어 시간을 지시할 수 있다.
"spread" 항은 서버 상에서 작업부하가 분산되도록 하기 위해 시간 베이스 트리거에 응답하여 이루어지는 동작(서버로부터의 TPT의 검색과 같은 동작) 또는 활성화 트리거에 응답하여 이루어지는 동작(TDO가 서버에 접속하게 하는 것과 같은 동작)이 램덤한 시간 동안 지연되어야 함을 지시하기 위해 사용될 수 있다.
"s=" 항은 모든 수신기들이 트리거에서 식별된 인터넷 서버에 접속을 시도해야 하는 초 단위의 시간 수를 지시할 수 있다. 각각의 개별 수신기는 지정된 구간 내에서 램덤한 시간을 도출하여 해당 양만큼 접속 요청을 지연시킴으로써, 수신기에서 트리거가 처음 나타날 때 발생할 수 있는 수요의 최대치를 시간 상에서 분산시키는 것으로 생각할 수 있다.
<media time> 파라미터를 포함하는 트리거는 이벤트 시간들에 대한 시간 베이스를 설정하기 이해 사용되므로, 시간 베이스 트리거라고 칭할 수 있다.
<event time> 파라미터를 포함하는 트리거는 이벤트에 대한 활성화 시간을 설정하므로 활성화 트리거라고 칭할 수 있다.
도 5와 도 6은 TDO 파라미터 테이블의 일 실시예를 나타낸 도면 이다.
TDO 파라미터 테이블(TPT)는 하나의 세그먼트의 TDO들 및 이들의 타겟인 이벤트들에 관한 메타데이터를 포함한다.
이하 테이블에 포함되는 각 필드들을 살펴본다. 각 필드의 크기와 테이블에 포함될 수 있는 필드의 종류는 설계자의 의도에 따라 추가 또는 변경 가능하다
TPT 구조 내 필드들의 구체적인 시맨틱(semantics)는 다음과 같다.
TDO 파라미터 테이블(TPT) 는 @majorProtocolVersion, @minorProtocolVersion, @id, @tptVersion, @expireDate, @updatingTime, @serviceID, @baseURL 속성, Capabilities, LiveTrigger, 및/또는 TDO 엘리먼트를 포함할 수 있다.
TPT는 해당 TPT의 루트(root) 엘리먼트이다. 하나의 TPT 엘리먼트는 하나의 프로그래밍 세그먼트의 (시간 상) 전체 또는 일부분을 기술한다.
4비트 속성일 수 있는 @MajorProtocolVersion는 테이블 정의의 주 버전 넘버를 지시할 수 있다. 주 버전 넘버는 1로 설정될 수 있다. 수신기들은 이들이 지원하지 않는 주 버전 값들을 지시하는 TPT의 인스턴스들은 버리는 것으로 생각할 수 있다.
4비트 속성일 수 있는 @MinorProtocolVersion이 존재하는 경우, 테이블 정의의 부 버전 넘버를 지시할 수 있다. 존재하지 않는 경우, 그 값은 0으로 디폴트될 수 있다. 부 버전 넘버는 0으로 설정될 있다. 수신기들은 이들이 지원하도록 되어 있지 않은 부 버전 넘버 값들을 지시하는 TPT의 인스턴스들을 버리지 않을 것으로 예상된다. 이 경우 수신기들은 이들이 지원하지 않는 개별 엘리먼트들 또는 속성들을 무시할 것으로 예상된다.
URI인 @id는 이 TPT 엘리먼트에 연관된 양방향 프로그래밍 세그먼트를 고유하게 식별할 수 있다. @id는 세그먼트의 식별자 역할을 한다. 따라서 수신기가 TPT를 파싱한 후 @id 정보를 이용하여, 하나의 세그먼트에 연관된 트리거, AMT 등을 해당 세그먼트를 식별하기 위한 @id를 가진 TPT 와 매칭시킬 수 있다. 따라서 해당 트리거와 AMT가 적용되는 세그먼트를 찾을 수 있게 된다. AMT에 관련된 자세한 내용은 후술한다.
8비트 정수일 수 있는 @tptVersion은 id 속성에 의해 식별되는 TPT 엘리먼트의 버전 넘버를 지시할 수 있다. tptVersion는 TPT가 변경될 때마다 증분될 수 있다.
TPT 엘리먼트의 @expireDate 속성은 존재할 경우, 해당 TPT 인스턴스에 포함된 정보의 만료 날짜 및 시간을 지시할 수 있다. 수신기가 TPT를 캐시에 저장하는 경우, 만료날짜까지 재사용될 수 있다.
16비트 엘리먼트일 수 있는 @updatingTime은 존재할 경우, TPT가 수정됨을 지시할 수 있고, TPT를 다시 다운로드하여 새로이 다운로드 된 TPT가 새로운 버전인지 확인하기 위한 초 단위의 추천 구간을 제공한다.
16비트 엘리먼트일 수 있는 @serviceID는 존재할 경우, 이 TPT 인스턴스에서 기술된 양방향 서비스와 연관된 NRT service_id를 지시할 수 있다. 이것은 이 양방향 서비스를 위한 파일들이 방송 스트림으로 전달될 때 수신기들이 서비스 맵 테이블로부터 FLUTE 파라미터들을 얻기 위해 필요하다.
@baseURL 속성은 존재할 경우, 해당 TPT에서 등장하는 임의의 상대 URL들의 앞에 붙으면 베이스 URL을 제공할 수 있다. 이 속성은 파일들의 절대 URL들을 제공할 수 있다.
Capabilities 엘리먼트는 존재할 경우, 해당 TPT와 연관된 양방향 서비스의 의미있는 표출을 위해 필수적인 능력들을 지시할 수 있다. 요구되는 능력들 중 하나 이상을 가지지 않은 수신기들은 서비스의 표출을 시도하지 않을 것으로 예상된다.
LiveTrigger 엘리먼트는 인터넷을 통한 활성화 트리거들의 전달이 이용 가능한 경우에만 존재한다. 존재할 경우, 활성화 트리거들을 얻기 위해 수신기에서 필요로 하는 정보를 제공할 수 있다. LiveTrigger의 차일드(child) 엘리먼트 및 속성에 대해서는 후술한다.
TPT 엘리먼트의 차일드 엘리먼트인 TDO는 해당 TPT 인스턴스에 의해 기술된 세그먼트 동안 양방향 서비스의 일부를 제공하는 어플리케이션(예를 들어, TDO)를 나타낼 수 있다. TDO의 차일드 엘리먼트와 속성에 대해서는 후술한다.
LiveTrigger 엘리먼트는 @URL와 @pollPeriod 속성을 포함할 수 있다.
위에서 말한 바와 같이, LiveTrigger 엘리먼트는 인터넷을 통한 활성화 트리거들의 전달이 이용 가능한 경우에만 존재한다. 존재할 경우, 활성화 트리거들을 얻기 위해 수신기에서 필요로 하는 정보를 제공할 수 있다.
LiveTrigger 엘리먼트의 속성인 @URL은 인터넷을 통해 활성화 트리거들을 전달할 수 있는 서버의 URL을 지시할 수 있다. 활성화 트리거들은 양방향 서비스 제공자의 선택에 따라 HTTP 숏 폴링(short polling), HTTP 롱 폴링(long polling), 또는 HTTP 스트리밍을 이용하여 인터넷을 통해 전달될 수 있다.
LiveTrigger 엘리먼트의 속성인 @pollPeriod는 존재할 경우, 활성화 트리거들의 전달을 위해 숏 폴링이 사용 중임을 지시할 수 있고, pollPeriod 속성 값은 수신기가 폴링 주기로 사용하는 초 단위의 추천 시간을 지시할 수 있다.
LiveTrigger 엘리먼트가 존재할 경우, 수신기는 해당 TPT를 파싱하여, 활성화 트리거를 인터넷을 이용하여 전달하기 위한 정보들을 얻을 수 있다. @URL 정보를 이용하여 활성화 트리거를 전달받을 수 있는 서버의 URL을 얻을 수 있다. @pollPeriod 정보를 통해, 혹은 @pollPeriod 속성이 존재하지 않는다는 정보를 통해 활성화 트리거가 인터텟을 통해 전달받는 방식과 폴링 주기에 대한 정보를 얻을 수 있다. @pollPeriod에 대한 자세한 설명은 후술한다.
TDO 엘리먼트는 @appID, @appType, @appName, @globalID, @appVersion, @cookieSpace, @frequencyOfUse, @expireDate, @testTDO, @availInternet, @availBroadcast 속성과, URL, Capabilities, Contentitem, 및/또는 Event 엘리먼트를 포함할 수 있다.
위에서 밝힌 바와 같이, TPT 엘리먼트의 차일드 엘리먼트인 TDO는 해당 TPT 인스턴스에 의해 기술된 세그먼트 동안 양방향 서비스의 일부를 제공하는 어플리케이션(예를 들어, TDO)를 나타낼 수 있다.
16비트 정수일 수 있는 @appID는 TPT 범위 내에서 어플리케이션을 고유하게 식별할 수 있다. 활성화 트리거는 appID를 참조하여 트리거에 대한 타겟 어플리케이션을 식별할 수 있다. @appID 의 경우, 어플리케이션의 식별자이다. 하나의 TPT에는 여러 개의 어플리케이션(TDO와 같은 어플리케이션)이 있을 수 있다. 따라서 TPT를 파싱한 후에 @appID 정보를 이용하여, 어플리케이션들을 식별할 수 있다. 한 어플리케이션에 적용될 트리거 또는 AMT 등을, 그 어플리케이션을 식별하는 @appID를 가진 어플리케이션과 매칭시킬 수 있다. 따라서 트리거와 AMT가 적용될 어플리케이션을 찾을 수 있게 된다. AMT와 관련된 자세한 내용은 후술한다.
8비트 정수일 수 있는 @appType은 어플리케이션 포맷 유형을 지시할 수 있다. 기본값은 1일 수 있으며, 이 값은 TDO를 나타낼 수 있다. 다른 값들은 다른 포맷들을 나타낼 수 있다.
TDO 엘리먼트의 속성인 @appName는 어플리케이션을 개시하기 위해 시청자의 허가를 구할 때 시청자에게 표시될 수 있는 인간이 판독가능한 이름일 수 있다.
TDO 엘리먼트의 속성인 @globalID은 어플리케이션의 전역적으로 고유한 식별자일 수 있다. 많은 경우에, 수신기는 너무 오래되기 전에 다시 사용하게 될 앱을 캐시에 저장하게 된다. 이와 같은 것이 유용하려면, 해당 앱이 다음 번에 등장하면 수신기가 이 앱을 인식할 수 있어야 한다. 해당 앱이 새로운 세그먼트에서 다시 등장하면 수신기가 이를 인식할 수 있도록 하기 위해서 globalID가 필요하다.
@appVersion은 TDO 엘리먼트의 속성으로서, 어플리케이션의 버전 넘버일 수 있다. appVersion 값은 해당 어플리케이션(globalID에 의해 식별된 어플리케이션)이 변경될 때마다 증분될 수 있다. appVersion 속성은 globalID 속성이 존재하지 않으면 존재할 수 없다.
8비트 정수일 수 있는 @cookieSpace는 각 호출(invocation) 사이에 지속성 데이터(persistent data)를 저장하기 위해 어플리케이션이 얼마나 많은 공간을 필요로 하는지를 지시할 수 있다.
4비트 정수일 수 있는 @frequencyOfUse는 수신기들에게 그 어플리케이션 코드 캐시 공간의 관리에 관한 안내를 제공하기 위해 대략적으로 얼마나 자주 해당 어플리케이션이 방송에서 사용되는 지를 지시할 수 있다. '@frequencyOfUse'의 상세한 설명은 후술한다
@expireDate는 TDO 엘리먼트의 속성으로서, 수신기가 해당 어플리케이션 및 관련된 리소스들을 안전하게 삭제할 수 있는 날짜 및 시간을 지시할 수 있다.
불린(Boolean) 속성인 @testTDO는 그 값이 "true"로 존재할 경우, 해당 어플리케이션이 테스트용이며 일반 수신기들에 의해 무시될 수 있음을 지시할 수 있다.
@availInternet 속성에 대한 "true" 값은 해당 어플리케이션이 인터넷을 통한 다운로드로 이용 가능함을 지시할 수 있다. 그 값이 "false"이면, 해당 어플리케이션이 인터넷을 통한 다운로드로 이용 가능하지 않음을 지시할 수 있다. 속성이 존재하지 않을 경우, 기본값은 "true"일 수 있다.
@availBroadcast 속성에 대한 "true" 값은 해당 어플리케이션이 방송으로부터의 추출로 이용 가능함을 지시할 수 있다. "false" 값은 해당 어플리케이션이 방송으로부터의 추출로 이용 가능하지 않음을 지시할 수 있다. 속성이 존재하지 않을 경우, 기본값은 "true"일 수 있다.
TDO 엘리먼트의 차일드 엘리먼트인 URL의 각 인스턴스는 해당 어플리케이션의 일부인 파일을 식별할 수 있다. URL 엘리먼트는 @entry 속성을 포함할 수 있다. URL 엘리먼트의 속성인 @entry는 "true" 값을 가지면, 해당 URL이 해당 어플리케이션의 엔트리 포인트(entry point), 즉 해당 어플리케이션을 개시하기 위해 개시될 수 있는 파일임을 지시할 수 있다. "false" 값을 가지면, 해당 URL이 해당 어플리케이션의 엔트리 포인트가 아님을 지시할 수 있다. 해당 속성이 등장하지 않을 때 기본값은 "false"일 수 있다. TDO 엘리먼트의 차일드 엘리먼트인 URL 엘리먼트는 위에서 말한 바와 같이 해당 어플리케이션을 이루는 파일을 식별한다. 수신단에서는 TPT를 파싱하여 이 URL 정보를 얻은 뒤, 이를 이용해 서버에 접속하여 해당 URL 정보가 지시하는 어플리케이션을 다운로드 받게 된다.
TDO 엘리먼트의 차일드 엘리먼트인 Capabilities는 존재할 경우, 해당 어플리케이션의 의미있는 표출을 위해 필수적인 능력들을 지시할 수 있다. . 요구되는 능력들 중 하나 이상을 가지지 않은 수신기들은 해당 어플리케이션의 개시를 시도하지 않을 것으로 예상된다.
TDO 엘리먼트의 차일드 엘리먼트인 ContentItem은 해당 어플리케이션에서 필요로 하는 하나 이상의 데이터 파일로 구성된 콘텐트 아이템을 지시할 수 있다. ContentItem 엘리먼트는 이 엘리먼트가 속해있는 TDO 엘리먼트가 나타내는 어플리케이션이 필요로 하는 데이터 파일들에 대한 정보를 가지고 있다. 수신단에서는 파싱을 거친 후, ContentItem 엘리먼트가 존재할 경우, ContentItem 내의 URL 정보 등을 이용하여 해당 어플리케이션이 필요로 하는 데이터 파일들을 다운로드 받거나 할 수 있다. ContentItem의 차일드 엘리먼트와 속성에 대해서는 후술한다.
TDO 엘리먼트의 차일드 엘리먼트인 Event는 해당 어플리케이션을 위한 이벤트를 나타낼 수 있다. Event 엘리먼트는 이 엘리먼트가 속해있는 어플리케이션의 이벤트를 나타낸다. 어떠한 이벤트들을 가지고 있는 지, 해당 데이터는 어떤 것이 있는지, 해당 동작은 어떤 것이 있는 지 등에 대한 정보를 담고 있다. 수신단에서는 이를 파싱하여 어플리케이션의 이벤트들에 대한 정보를 얻을 수 있다. Event의 차일드 엘리먼트와 속성에 대해서는 후술한다.
수신단에서 TPT를 받아 파싱하면 TDO 및 위에서 설명한 TDO의 차일드 엘리먼트와 속성의 정보를 얻을 수 있다.
TDO 엘리먼트의 차일드 엘리먼트 중 하나인, contentItem 엘리먼트는 @updateAvail, @pollPeriod, @size, @availInternet, @availBroadcast attribute 및/또는 URL 엘리먼트를 포함할 수 있다.
여기서, URL 엘리먼트는 @entry 속성을 포함할 수 있다. ContentItem 엘리먼트의 차일드 엘리먼트인 URL의 각 인스턴스는 콘텐트 아이템의 일부인 파일을 식별할 수 있다. URL 엘리먼트는 @entry 속성을 포함할 수 있다. URL 엘리먼트의 속성인 @entry는 "true" 값을 가지면, 해당 URL이 해당 콘텐트 아이템의 엔트리 포인트, 즉 해당 콘텐트 아이템을 개시하기 위해 개시될 수 있는 파일임을 지시할 수 있다. 이 속성이 "false" 값을 가지면, 해당 URL이 해당 콘텐트 아이템의 엔트리 포인트가 아님을 지시할 수 있다. 이 속성이 등장하지 않을 때 기본값은 "false"일 수 있다. 수신기는 파싱 후 ContentItem의 URL 정보를 이용하여 해당 어플리케이션의 요구되는 데이터 파일들을 다운로드할 수 있다. 이 과정에서, 상술한 다른 속성들과 같은 정보가 이용될 수 있다.
ContentItem 엘리먼트의 불린 속성인 @updatesAvail은 해당 콘텐트 아이템이 가끔씩 업데이트되는 지, 즉 콘텐트 아이템이 고정 파일(static file)들로 구성되는지, 아니면 해당 아이템이 실시간 데이터 피드(feed)인 지를 지시할 수 있다. 그 값이 "true"이면 해당 콘텐트 아이템은 가끔씩 업데이트되고, 그 값이 "false"이면 해당 콘텐트 아이템은 업데이트되지 않는다. 이 속성이 등장하지 않은면 기본값은 "false"일 수 있다.
ContentItem 엘리먼트의 속성인 @pollPeriod는 updatesAvail 속성의 값이 "true"일 때만 존재할 수 있다. @pollPeriod가 존재할 경우, 활성화 트리거들을 전달하기 위해 숏 폴링이 이용되고 있음을 지시할 수 있고, @pollPeriod 속성의 값은 수신기가 폴링 주기로서 사용하기 위한 초 단위의 추천 시간을 지시할 수 있다.
ContentItem 엘리먼트의 속성인 @Size는 해당 콘텐트 아이템의 크기를 지시할 수 있다.
@availInternet 속성은 그 값이 "true"이면, 해당 콘텐트 아이템이 인터넷을 통한 다운로드로 이용 가능함을 지시할 수 있다. 그 값이 "false"이면, 해당 콘텐트 아이템이 인터넷을 통한 다운로드로 이용 가능하지 않음을 지시할 수 있다. 이 속성이 존재하지 않을 경우, 기본값은 "true"일 수 있다."
@availBroadcast 속성은 그 값이 "true"이면, 해당 콘텐트 아이템이 방송으로부터의 추출로 이용 가능함을 지시할 수 있다. "false" 값은 해당 콘텐트 아이템이 방송으로부터의 추출로 이용 가능하지 않음을 지시할 수 있다. 속성이 존재하지 않을 경우, 기본값은 "true"일 수 있다.
Event 엘리먼트는 이 Event 엘리먼트가 속하는 TDO 엘리먼트에 의해 지시된 어플리케이션의 이벤트에 대한 정보를 포함한다. 수신기는 해당 이벤트에 대한 정보를 얻기 위해 이 Event 엘리먼트를 파싱할 수 있다.
TDO 엘리먼트의 차일드 엘리먼트인 Event 엘리먼트는 @eventID, @action, @destination, @diffusion 속성 및/또는 Data 엘리먼트를 포함할 수 있다. 여기에서, Data 엘리먼트는 @dataID 속성을 포함할 수 있다.
상기 Event 엘리먼트의 16비트 정수 속성일 수 있는 @eventID는 이를 포함하는 TDO 엘리먼트의 범위 내에서 해당 이벤트를 고유하게 식별할 수 있다. 활성화 트리거 (또는 AMT 내 활성화 엘리먼트)는 appID와 eventID의 조합에 의해 해당 트리거에 대한 타겟 어플리케이션 및 이벤트를 식별할 수 있다. 이벤트가 활성화되면, 수신기들은 이 이벤트를 해당 어플리케이션으로 넘긴다. @eventID는 이벤트의 식별자 역할을 한다. @eventID 정보를 이용하여, 해당 이벤트를 활성화시키기 위한 트리거, AMT 등을 이 이벤트를 식별하기 위한 @eventID를 가진 어플리케이션과 매칭시킬 수 있다. 즉, 활성화 트리거 (또는 AMT 내 활성화 엘리먼트)는 appID와 eventID의 조합에 의해 해당 트리거에 대한 타겟 어플리케이션 및 이벤트를 식별할 수 있다. 이벤트가 활성화되면, 수신기들은 이 이벤트를 해당 어플리케이션으로 넘긴다. AMT에 대한 자세한 내용은 후술한다.
Event 엘리먼트의 속성인 @action은 해당 이벤트가 활성화될 때 적용되는 동작의 유형을 지시할 수 있다. 허용되는 값들은 "prep", "exec", "susp" 및 "kill"일 수 있다.
"prep"은 "Trig prep" 동작에 대응할 수 있다. 타겟이 된 어플리케이션의 상태가 "Released"이면, 이 동작은 "Ready"로의 상태 변경을 일으킬 수 있다.
"exec"은 "Trig exec" 동작에 대응할 수 있다. 이 트리거를 수신하면, 타겟이 된 어플리케이션의 상태는 "Active"로 될 수 있다.
"susp"는 "Trig susp" 동작에 대응할 수 있다. 이 트리거를 수신한면, 타겟이 된 어플리케이션의 상태가 "Active"인 경우 "Suspended"로 변경될 수 있고, 그렇지 않은 경우에는 변경되지 않는다.
"kill"은 "Trig kill" 동작에 대응할 수 있다. 이 트리거를 수신하면, 타겟이 된 어플리케이션의 상태는 "Released"로 될 수 있다.
@action는 해당 이벤트가 활성화될 때 적용될 동작의 유형을 지시할 수 있다.
Event 엘리먼트의 속성인 @destination는 해당 이벤트를 위한 타겟 장치를 지시할 수 있다. @destination에 대한 자세한 내용은 후술한다.
Event 엘리먼트의 8비트 정수 속성일 수 있는 @diffusion은 존재할 경우, 초 단위의 시간 주기 T를 나타낼 수 있다. 이 확산 파라미터의 목적은 서버 로딩의 최대치들을 고르게 만드는 것이다. 수신기는 0~T 범위에서 10 밀리세컨드 단위로 램덤 시간을 산출하고, TPT에서 URL들에 의해 참조된 콘텐트를 검색하기 위해 인터넷 서버에 접속하기 전에 이 시간량으로 지연되는 것으로 예상할 수 있다.
Event 엘리먼트의 차일드 엘리먼트인 Data는 존재할 경우 해당 이벤트에 관련된 데이터를 제공할 수 있다. Event의 서로 다른 활성화들은 이들과 연관된 서로 다른 Data 엘리먼트들을 가질 수 있다. 여기서 Data 엘리먼트는 @dataID 속성을 포함할 수 있다. 16비트 정수 속성인 @dataID는 이를 포함하는 Event 엘리먼트의 범위 내에서 Data 엘리먼트를 고유하게 식별할 수 있다. 이벤트의 활성화가 이와 연관된 데이터를 가지는 경우, 활성화 트리거는 AppID, EventID 및 DataID의 조합에 의해 해당 Data 엘리먼트를 식별할 수 있다. Data 엘리먼트의 경우, 해당 이벤트에 쓰이는 데이터를 의미한다. 하나의 이벤트 엘리먼트는 여러 개의 데이터 엘리먼트를 가질 수 있다. 데이터 엘리먼트의 @dataID 속성을 이용해 데이터의 식별을 한다. 수신단에서는 해당 데이터와 관련 있는 이벤트가 활성화된 경우, 활성화 트리거(또는 AMT 내 활성화 엘리먼트)는 AppID, EventID, 및 DataID의 조합에 의해 Data 엘리먼트를 식별할 수 있다. AMT 와 관련된 자세한 내용은 후술한다.
도 7은 'Frequency of Use' 속성 값들의 의미의 일 실시예를 나타낸 도면이다.
"의미" 열은 해당 어플리케이션을 포함하는 세그먼트들의 발생 빈도를 지시한다. (물론, 하나의 세그먼트 내에서 하나의 속성이 여러 번 등장할 수 있다.) frequencyOfUse 속성은 globalID이 존재하지 않으면 존재할 수 없다. 만일 앱이 캐시에 저장되어 나중에 다시 사용될 것이라면, 수신기는 해당 앱이 나중에 다시 등장하면 동일한 앱으로 인식해야 한다. 이를 위해 globalId 속성이 필요하다.
도 8은 'destination' 속성 값들의 의미의 일 실시예를 나타낸 도면이다.
도 8 에서 보는 바와 같이, 'destination' 속성의 값이 0일 경우 예약되고, 1일 경우 주 장치만을 의미하고, 2일 경우 하나 이상의 보조 장치만을 의미하며, 3일 경우 주 장치 및/또는 하나 이상의 보조 장치들을 의미할 수 있다.
도 9, 도 10, 도 11, 도 12, 도 13는 TDO 파라미터 테이블의 이진 형태의 신택스의 일 실시예를 나타낸 도면 이다.
이는 상기에서 언급했던 TPT 구조의 이진 포맷이다. 이 구조는 NRT로 TPT를 전송할 경우에 필요한 포맷으로 TPT의 XML 구조를 NRT로 전송하기에 적합하게 만들어 둔 것 이다.
TPT의 XML 버전에 포함된 다음의 엘리먼트들 및/또는 속성들, 즉 @protocolVersion (major/minor), @serviceID 및 @tptVersion은 이진 테이블을 전달하기 위한 캡슐화 헤더(encapsulation header)에 의해 방송 스트림으로 제공될 수 있으므로, 이진 버전에서 생략될 수 있다.
필드들의 시맨틱은 다음과 같다. 도 9, 도 10, 도 11, 도 12, 도 13 순서대로 이어지는 TDO 파라미터 테이블의 이진 포맷에서, 위에서 아래로 등장하는 순서대로 기술하였다.
1비트 필드일 수 있는 expire_date_included는 expire_date field가 포함되는 지를 지시할 수 있다. 그 값이 '1'이면 해당 필드가 포함됨을 의미할 수 있고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
5비트 필드일 수 있는 segment_id_length는 segment_id의 바이트 길이를 지시할 수 있다.
가변 길이 필드인 segment_id는 세그먼트 아이디의 바이트들을 포함할 수 있는데, 이는 TPT XML 포맷의 "id" 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 base_URL_length는 base_URL 필드의 바이트 길이를 지시할 수 있다.
가변 길이 필드인 base_URL은 베이스 URL의 바이트들을 포함할 수 있는데, 이는 TPT XML 포맷의 baseURL 속성과 동일한 시맨틱을 가질 수 있다.
32비트 필드일 수 있는 expire_date는 해당 TPT 인스턴스에 포함된 정보의 만료 날짜 및 시간을 지시할 수 있다. 수신기가 TPT를 캐시에 저장한다면 만료날짜까지 재사용될 수 있다. 무부호 정수는 1980년 1월 6일 00:00:00 UTC 이후 GPS 초(second)의 수에서 GPS-UTC_offset을 뺀 것으로 해석될 수 있다. GPS UTC 옵셋은 GPS와 UTC 시간표준 사이의 현재의 전체 초 단위 옵셋을 정의하는 8비트 무부호 정수일 수 있다.
8비트 필드일 수 있는 trigger_server_URL_length는 trigger_server_URL 필드의 바이트 길이를 지시할 수 있다. 이 필드의 값이 0이면, 개개의 활성화 트리거들의 인터넷 전달이 이용 가능하지 않음을 지시할 수 있다.
trigger_server_URL_length 필드가 0이 아니면, trigger_server_URL는 Trigger Server URL의 바이트들을 포함할 수 있으며, 이는 TPT XML 포맷의 LiveTrigger 엘리먼트의 URL 속성과 동일한 시맨틱을 가질 수 있다.
1비트 필드일 수 있는 trigger_delivery_type는 인터넷을 통한 개별 활성화 트리거들의 전달 모드를 지시할 수 있다, '0' 값을 가지면 HTTP 숏 폴링이 사용 중임을 지시할 수 있고, '1' 값을 가지면 HTTP 롱 폴링 또는 HTTP 스트리밍이 사용 중임을 지시할 수 있다.
8비트 정수일 수 있는 poll_period는 HTTP 숏 폴링이 사용 중일 때, 폴 사이의 권장되는 초의 수를 지시할 수 있다.
8비트 필드일 수 있는 num_apps_in_table은 해당 TPT 인스턴스에서 기술된 어플리케이션들(TDO들)의 수를 지시할 수 있다.
16비트 필드일 수 있는 app_id는 해당 어플리케이션(num_apps_in_table 루프(loop)의 반복에서 기술되는 어플리케이션)에 대한 식별자를 포함할 수 있다. 이는 해당 TPT 인스턴스 내에서 고유할 수 있다.
1비트 필드일 수 있는 app_type_included는 app_type 필드가 해당 어플리케이션에 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
1비트 필드일 수 있는 app_name_included는 app_name 필드가 해당 어플리케이션에 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
1비트 필드일 수 있는 global_id_included는 global_id 필드가 해당 어플리케이션에 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
1비트 필드일 수 있는 app_version_included는 app_version 필드가 이 어플리케이션에 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
1비트 필드일 수 있는 cookie_space_included는 cookie_space 필드가 이 어플리케이션에 대하여 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
1비트 필드일 수 있는 frequency_of_use_included는 frequency_of_use 필드가 이 어플리케이션에 대하여 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
1비트 필드일 수 있는 expire_date_included는 expire_date 필드가 이 어플리케이션에 대하여 포함되는 지를 지시할 수 있다. 그 값이 '1'이면, 해당 필드가 포함됨을 의미하고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
8비트 필드일 수 있는 app_type은 존재할 경우, 이 어플리케이션의 포맷 유형을 지시할 수 있다. 그 값이 0이면, 그 어플리케션이 TDO임을 지시할 수 있다. 만일 이 필드가 존재하지 않을 경우, 그 값은 0으로 디폴트된다. 다른 값들은 다른 포맷들을 나타낼 있다.
8비트 필드일 수 있는 app_name_length는 존재할 경우, 그 뒤에 바로 이어지는 app_name 필드의 바이트 길이를 지시할 수 있다. 이 필드의 값이 0이면 해당 어플리케이션을 위한 app_name 필드가 존재하지 않음을 지시할 수 있다.
가변 길이 필드인 app_name는 TPT XML 포맷인 TDO 엘리먼트의 appName 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 global_id_length는 그 뒤에 바로 이어지는 global_id 필드의 바이트 길이를 지시할 있다. 이 필드 값이 0이면, 해당 어플리케이션을 위한 global_id 필드가 존재하지 않음을 지시할 수 있다.
가변 길이 필드인 global_id는 TPT XML 포맷의 TDO 엘리먼트의 globalId 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 app_version는 TPT XML 포맷의 TDO 엘리먼트의 appVersion 속성과 동일한 시맨틱을 갖는다.
8비트 필드일 수 있는 cookie_space는 TPT XML 포맷의 TDO 엘리먼트의 cookieSpace 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 frequency_of_use는 존재할 경우, TPT XML 포맷의 TDO 엘리먼트의 frequencyOfUse 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 expire_date는 TPT XML 포맷의 TDO 엘리먼트의 expireDate 속성과 동일한 시맨틱을 가질 수 있다.
1비트 필드일 있는 test_app는 해당 어플리케이션이 일반 수신기들에 의해 무시되도록 되어 있는 테스트 어플리케이션인 지의 여부를 지시할 수 있다. 그 값이 '1'이면, 테스트 어플리케이션임을 의미할 수 있고, 그 값이 '0'이면, 테스트 어플리케이션이 아님을 의미할 수 있다.
1비트 필드일 수 있는 available_on_internet은 해당 어플리케이션이 인터넷을 통해 이용 가능한 지 여부를 지시할 수 있다. 그 값이 '1'이면, 인터넷을 통해 이용 가능함을 의미할 수 있고, 그 값이 '0'이면 인터넷을 통해 이용 가능하지 않음을 의미할 수 있다.
1비트 필드일 있는 available_in_broadcast는 해당 어플리케이션이 방송을 통해 이용 가능한 지 여부를 지시할 수 있다. 그 값이 '1'이면, 방송을 통해 이용 가능함을 의미할 수 있고, 그 값이 '0'이면 방송을 통해 이용 가능하지 않음을 의미할 수 있다. 4비트 필드일 수 있는 number_URLs는 해당 어플리케이션을 포함하는 파일들의 수를 지시할 수 있다.
8비트 필드일 수 있는 URL_length는 그 뒤에 이어지는 URL 필드의 길이를 지시할 수 있다.
가변 길이 필드인 URL은 TPT XML 포맷인 TDO 엘리먼트의 URL 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 number_content_items는 이 어플리케이션에 의한 사용을 위해 다운로드 되어야 하는 콘텐트 아이템의 수를 지시할 수 있다.
1비트 필드일 수 있는 updates_avail은 이 콘텐트 아이템이 가끔씩 업데이트되는 지, 즉 콘텐트 아이템이 고정 파일들의 집합인 지 아니면 실시간 데이터 피드인 지를 지시할 수 있다. 그 값이 '1'이면, 업데이트 됨을 지시할 수 있고, 그 값이 '0'이면 업데이트 되지 않음을 지시할 수 있다.
1비트 필드일 수 있는 avail_internet는 이 콘텐트 아이템을 포함하는 파일(들)이 인터넷을 통해 다운로드 될 수 있는 지 여부를 지시할 수 있다. 그 값이 '1'이면, 인터넷을 통한 다운로드로 이용 가능함을 의미할 수 있고, 그 값이 '0'이면 인터넷을 통한 다운로드로 이용 가능하지 않음을 의미할 수 있다.
1비트 필드일 있는 avail_broadcast는 이 콘텐트 아이템을 포함하는 파일(들)이 방송을 통해 다운로드 될 수 있는 지 여부를 지시할 수 있다. 그 값이 '1'이면, 방송을 통한 다운로드로 이용 가능함을 의미할 수 있고, 그 값이 '0'이면 방송을 통한 다운로드로 이용 가능하지 않음을 의미할 수 있다.
1비트 필드일 있는 content_size_included는 이 어플리케이션을 위해 content_size 필드가 포함되는 지 여부를 지시할 수 있다. 그 값이 '1'이면 해당 필드가 포함됨을 의미할 수 있고, 그 값이 '0'이면 포함되지 않음을 의미할 수 있다.
4비트 필드일 수 있는 number_URLs는 이 콘텐트 아이템을 포함하는 파일들의 수를 지시할 수 있다.
8비트 필드일 수 있는 URL_length는 그 뒤에 이어지는 URL 필드의 길이를 지시할 수 있다.
가변 길이 필드인 URL은 TPT XML 포맷인 TDO 엘리먼트의 차일드 엘리먼트인 ContentItem의 URL 속성과 동일한 시맨틱을 가질 수 있다.
24비트 필드일 수 있는 content_size는 TPT XML 포맷인 TDO 엘리먼트의 차일드 엘리먼트인 ContentItem의 contentSize 속성과 동일한 시맨틱을 가질 수 있다.
8비트 필드일 수 있는 num_content_descriptors는 그 뒤에 바로 이어지는 디스크립터 루프 내의 콘텐트 디스크립터의 수를 지시할 수 있다.
가변 길이 필드인 content_descriptor()는 MPEG-2 디스크립터 포맷(태그, 길이, 데이터)를 따르는 디스크립터일 수 있다. 이 필드는 해당 콘텐트 아이템에 대한 부가 정보를 제공할 수 있다. 이 디스크립터 루프에 포함될 수 있는 디스크립터들 중에 이 콘텐트 아이템의 의미 있는 표출을 위해 필요한 수신기 능력들을 지시하는 Capabilities 디스크립터가 있을 수 있다.
8비트 필드일 수 있는 number_events는 이 TDO에 대하여 정의된 이벤트들의 수를 지시할 수 있다.
16비트 필드일 수 있는 event_id는 해당 이벤트(number_events 루프의 반복으로 기술된 이벤트)를 위한 식별자를 포함할 수 있다. 이 필드는 해당 어플리케이션의 범위 내에서 유일할 수 있다. 해당 이벤트는 app_id와 event_id의 조합에 의해 활성화 트리거들 내에서 참조될 수 있다.
5비트 필드일 수 있는 action은 TPT XML 포맷인 TDO 엘리먼트의 Event 차일드 엘리먼트의 action 속성과 동일한 시맨틱을 가질 수 있다.
1비트 필드일 수 있는 destination_included는 해당 이벤트를 위해 destination 필드가 포함되는 지 여부를 지시할 수 있다. 그 값이 '1'이면 이 필드가 포함됨을 지시할 수 있고, 그 값이 '0'이면 포함되지 않음을 지시할 수 있다.
1비트 필드일 수 있는 diffusion_included는 해당 이벤트를 위해 diffusion 필드가 포함되는 지 여부를 지시할 수 있다. 그 값이 '1'이면 이 필드가 포함됨을 지시할 수 있고, 그 값이 '0'이면 포함되지 않음을 지시할 수 있다.
1비트 필드일 수 있는 data_included는 해당 이벤트를 위해 data_size와 data_bytes 필드가 포함되는 지 여부를 지시할 수 있다. 그 값이 '1'이면 이 필드들이 포함됨을 지시할 수 있고, 그 값이 '0'이면 포함되지 않음을 지시할 수 있다.
destination 필드의 시맨틱은 존재할 경우, TPT XML 포맷인 TDO 엘리먼트의 Event 차일드 엘리먼트의 destination 속성의 시맨틱과 동일할 수 있다.
diffusion 필드의 시맨틱은 존재할 경우, TPT XML 포맷인 TDO 엘리먼트의 Event 차일드 엘리먼트의 diffusion 속성의 시맨틱과 동일할 수 있다.
data_size 필드는 존재할 경우 그 뒤에 바로 이어지는 data_bytes 필드의 크기를 지시할 수 있다.
data_bytes 필드는 존재할 경우, 해당 이벤트와 관련 있는 데이터를 제공할 수 있다. 해당 이벤트과 활성화될 때마다 타겟 어플리케이션은 그 데이터를 판독하고 이를 이용하여 원하는 동작의 수행을 도울 수 있다. 이 필드는 원시(raw) 이진 값을 포함할 수 있다는 것을 제외하고 그 내용이 TPT XML 포맷인 해당 TDO 엘리먼트의 해당 Event 차일드 엘리먼트의 해당 Data 차일드 엘리먼트와 동일할 있으며, TPT XML 포맷인 이 Data 엘리먼트는 그 이진 값의 베이스64 인코딩을 포함할 수 있다.
8비트 필드일 수 있는 num_app_descriptors는 그 뒤에 바로 이어지는 디스크립터 루프 내의 디스크립터의 수를 지시할 수 있다.
가변 길이 필드인 app_descriptor()는 MPEG-2 디스크립터 포맷(태그, 길이, 데이터)를 따르는 디스크립터일 수 있다. 이 필드는 해당 어플리케이션 (TDO)에 대한 부가 정보를 제공할 수 있다. 이 디스크립터 루프에 포함될 수 있는 디스크립터들 중에 이 어플리케이션의 의미 있는 표출을 위해 필요한 수신기 능력들을 지시하는 Capabilities 디스크립터가 있을 수 있다.
8비트 필드일 수 있는 그 뒤에 바로 이어지는 디스크립터 루프 내의 디스크립터들의 수를 지시할 수 있다.
가변 길이 필드인 TPT_descriptor()는 MPEG-2 디스크립터 포맷(태그, 길이, 데이터)를 따르는 디스크립터일 수 있다. 이 필드는 해당 TPT에 대한 부가 정보를 제공할 수 있다. 이 디스크립터 루프에 포함될 수 있는 디스크립터들 중에 이 TPT에 의해 나타내어지는 양방향 서비스의 의미 있는 표출을 위해 필요한 수신기 능력들을 지시하는 Capabilities 디스크립터가 있을 수 있다.
도 14는 활성화 메시지 테이블 구조의 일 실시예를 나타낸 도면이다. 이하 테이블에 포함되는 각 필드들을 살펴본다. 각 필드의 크기와 테이블에 포함될 수 있는 필드의 종류는 설계자의 의도에 따라 추가 또는 변경 가능하다
활성화 메시지 테이블(AMT)는 세그먼트를 위한 활성화 트리거들에 상응하는 것을 포함할 수 있다. 어떤 환경에서는 활성화 트리거들 대신에 이것이 수신기들에 전달될 수 있다. 트리거는 "live trigger" 서버에 의해 ACR 서버들에서 AMT를 통해 클로즈드 캡션(closed caption) 스트림으로 전달될 수 있다
AMT 구조 내 필드들의 구체적인 시맨틱은 다음과 같다.
활성화 메시지 테이블(AMT)는 @majorProtocolVersion, @minorProtocolVersion, @segmentId, @beginMT 속성 및/또는 Activation 엘리먼트를 포함할 수 있다.
AMT 엘리먼트의 4비트 속성일 수 있는 @majorProtocolVersion는 AMT 정의의 주 버전 넘버를 지시할 수 있다. 주 번전 번호는 1로 설정될 수 있다. 수신기들은 이들이 지원하도록 구비되지 않은 주 버전 값들을 지시하는 AMT의 인스턴스들을 버리는 것으로 예상할 수 있다.
AMT 엘리먼트의 4비트 속성일 수 있는 @minorProtocolVersion은 존재할 경우, AMT 정의의 부 버전 넘버를 지시할 수 있다. 존재하지 않을 경우 그 값은 0으로 디폴트될 수 있다. 부 번전 번호는 0으로 설정될 수 있다. 수신기들은 이들이 지원하도록 구비되지 않은 부 버전 값들을 지시하는 AMT의 인스턴스들을 버리지 않을 것으로 예상할 수 있다. 이 경우, 수신기들은 이들이 지원하지 않는 개별 엘리먼트 또는 속성들을 무시하는 것으로 예상할 수 있다.
AMT의 식별자인 @segmentID는 AMT내 Activation들이 적용되는 어플리케이션 및 이벤트들을 포함하는 TPT의 식별자와 매칭된다. @segmentId는 AMT의 식별자 역할을 할 수 있다. 따라서 수신단에서 AMT를 수신한 후 이를 파싱하여 @segmentId 정보를 통해 AMT를 식별할 수 있다. @segmentId는 AMT 가 어느 세그먼트에 적용되어야 하는지에 관한 정보를 담고 있으며, 그 세그먼트에 관련된 TPT 가 가진 @id와 매칭되어 AMT와 TPT를 연결시켜주는 역할을 할 수 있다. 더 나아가 먼저 해당 segment 를 식별함으로써, AMT 내의 각각의 Activation 엘리먼트가 타겟으로 하는 TDO, 이벤트를 식별하게 되는데 있어 필요한 기본적인 정보를 제공할 수 있다.
AMT 엘리먼트의 속성인 @beginMT는 존재할 경우, AMT 인트턴스가 활성화 시간들을 제공하는 세그먼트의 미디어 시간의 시작을 지시할 수 있다 @beginMT 는 속해있는 AMT가 적용될 세그먼트에 대해 미디어 시간의 시작을 지시할 수 있다. 이로 인해, Activation 엘리먼트가 지시하는 활성화가 발생할 시간의 기준을 정할 수 있다. 따라서 @beginMT가 있을 경우, Activation 엘리먼트 내의 @startTime 속성은 @beginMT가 지시하는 미디어 시간의 시작에 영향을 받을 수 있다.
AMT의 Activation 엘리먼트 각 인스턴스는 어떤 이벤트를 이 이벤트와 연관된 어떤 데이터와 함께 어떤 시간에 활성화하는 명령을 나타낼 수 있다 Activation 엘리먼트는 AMT 내에 다수 개가 존재할 수 있다. 하나 하나의 Activation 엘리먼트는 활성화 트리거와 유사한 역할을 할 수 있다. Activation 엘리먼트들은 모두 AMT 내의 @segmentId가 지시하는 세그먼트에 적용될 수 있다. Activation 엘리먼트 내의 속성들에, 해당 활성화가 어떤 어플리케이션의, 어떤 이벤트에, 언제 일어나게 될지에 대한 정보 등을 담을 수 있다. Activation 엘리먼트 내부의 속성들에 대한 자세한 설명은 후술한다.
Activation 엘리먼트는 @targetTDO, @targetEvent, @targetData, @startTime, @endTime 속성을 포함할 수 있다.
Activation 엘리먼트의 속성인 @targetTDO는 AMT와 연관된 TPT 내의 TDO 엘리먼트의 appID 속성과 매칭됨으로써, 활성화 명령에 대한 타겟 어플리케이션을 식별할 수 있다. @targetTDO는 AMT 내의 Activation 엘리먼트가 어느 어플리케이션에 적용될지에 관한 정보를 담을 수 있다. 수신단에서는 AMT를 수신한 후 파싱하여 @targetTDO를 얻고, 매칭되는 TPT 내의 TDO 엘리먼트 내의 @appID를 찾아 Activation 엘리먼트가 적용될 어플리케이션을 식별할 수 있다.
Activation 엘리먼트의 속성인 @targetEvent는 targetTDO 속성에 의해 식별되는 TDO 엘리먼트 포함된 Event 엘리먼트의 eventID 속성과 매칭됨으로써, 해당 활성화 명령에 대한 타겟 이벤트를 식별할 수 있다. @targetEvent는 AMT 내의 Activation 엘리먼트가 어느 어플리케이션의 어느 이벤트에 적용될지에 관한 정보를 담을 수 있다. 수신단에서는 AMT를 수신한 후 파싱하여 @targetEvent를 얻고, 매칭되는 TPT 내의 TDO 엘리먼트 내의 @eventID를 찾아 Activation 엘리먼트가 적용될 이벤트를 식별할 수 있다.
Activation 엘리먼트의 속성인 @targetData는 targetTDO와 targetEvent 속성들에 의해 식별되는 Event 엘리먼트에 포함된 Data 엘리먼트의 dataID와 매칭됨으로써, 활성화 명령이 적용될 때 타겟 이벤트와 연관되는 데이터를 식별할 수 있다. @targetData는 활성화 명령이 적용될 때, 타겟이 된 이벤트와 관련된 데이터를 식별할 수 있다. 수신단에서는 AMT를 수신한 후 파싱하여 @targetData를 얻고, TPT 내의 해당 Event 엘리먼트 내의 @dataID를 찾을 수 있다.
이벤트 엘리먼트의 속성인 @startTime은 미디어 시간에 대한 이벤트의 유효 기간의 시작을 지시할 수 있다. 수신기들은 미디어 시간이 startTime 내 값에 도달할 때 또는 그 후 최대한 빨리 해당 명령을 실행하는 것으로 예상할 수 있다. @startTime은 해당 이벤트가 일어날 시작 시간을 지시할 수 있다. 이 시작 시간은 미디어 시간을 기준으로 한다. 수신단에서는 AMT를 파싱하여 @startTime 정보를 얻고 이를 이용해 이벤트가 일어날 시간을 알 수 있다. 수신단에서는 @segmentId에 의해 식별된 세그먼트의 미디어 시간을 기준으로 미디어 시간이 시작 시간(startTime) 에 이를 경우 이벤트를 활성화 시킬 수 있다. 만일 이미 시작 시간을 지난 경우 최대한 빨리 이벤트를 활성화 시킬 수 있다.
이벤트 엘리먼트의 속성인 @endTime은 미디어 시간에 대한 해당 이벤트를 위한 유효 기간의 끝을 지시할 수 있다. 수신기는 미디어 시간이 endTime의 값을 경과하면 해당 명령을 실행하지 않는 것으로 예상할 수 있다. @endTime 은 해당 이벤트가 끝나는 시간을 지시할 수 있다. 미디어 시간이 끝나는 시점에 도달할 경우, 수신단에서는 이벤트를 실행시키지 않을 수 있다.
AMT 내 Activation 엘리먼트들은 startTime 값들의 오름 차순으로 등장할 수 있다.
수신기가 AMT 내 Activation들에 따라 이벤트들을 활서화시킬 때 수신기는 각 활성화를 해당 시작 시간에 적용하거나 또는 그 후 최대한 빨리 적용(예를 들어, 수신기가 서비스에 가입하여 시작 시간 이후와 끝 시간 전의 어떤 시간에 AMT를 수신하는 경우)하는 것으로 예상할 수 있다. TPT 내 이벤트 엘리먼트의 "action" 속성이 "exec"이면, 수신기는 TriggerEvent를 타겟 어플리케이션으로 넘기는 것으로 예상할 수 있다. TriggerEvent에 대해서는 API와 관련된 부분에서 후술한다.
도 15는 URL 리스트 구조도의 일 실시예를 나타낸 도면이다.
URL 리스트는 수신기에 대하여 사용 잠재성이 있는 어떤 URL들을 포함할 수 있다. 다음과 같은 URL 등을 포함할 수 있다.
1. 하나 또는 그 이상의 미래 세그먼트들에 대한 TPT들을 위한 URL. 수신기가 파일들을 미리 다운로드할 수 있게 한다.
2. 방송 스트림 내 독립형 NRT 서비스들에 대한 정보가 검색될 수 있는 NRT 시그널링 서버의 URL. 수신기가 방송 스트림 내 NRT 서비스 시그널링의 전달에 대한 접근 권한이 없어도 이들 서비스들에 접근할 수 있게 한다.
3. 가상 채널에 대한 사용 보고가 전송되는 사용 보고 서버의 URL. 수신기에 방송 스트림 내 이 URL의 전달에 대한 접근 권한이 없어도 이와 같은 보고드을 전송할 수 있게 한다.
4. 가상 채널에 대한 PDI-Q 테이블의 URL. 수신기가 방송 스트림으로 전달된 PDI-Q 테이블에 대한 접근 권한이 없어도 시청 경험을 개인화할 수 있게 한다. (PDI-Q 테이블은 양방향 서비스를 제공함에 있어, 사용자에게 맞춤 서비스를 제공하기 위한 개인화(personalization) 관련 있는 테이블이다. PDI-Q 테이블을 통해 사용자에게 개인화를 위한 질문을 할 수 있다.)
그 중 UsrUrl 엘리먼트에 관하여, URL 리스트를 만들어 추가로 사용 보고를 위한 서버의 URL을 알려 줄 필요가 있을 수 있다. 이것은 현재 수신기가 시청하고 소모하고 있는 콘텐츠의 종류와 선호하는 데이터를 활용하여 비즈니스에 활용하기 위함일 수 있다. URL 리스트에 있는 UsrUrl 엘리먼트는 다음과 같이 여러 가지로 해석이 가능할 수 있다.
첫번째 사용 보고 서버인 경우에는 수신기는 이 사용 보고 서버의 URL을 가지고 미리 정해진 프로토콜(예, 데이터 구조, XML 파일 등)에 의하여 수신기의 사용 보고 기능을 수행할 수 있다.
두 번째로는 수신기의 웹 브라우저에서 실행되는 TDO일 수도 있다. 이 경우에는 사용 보고 TDO의 위치를 알려 주며, 이 경우에는 TDO가 직접 수신기의 웹 브라우저의 API(예, 파일 API, 사용 보고 API)를 이용하여 수신기에 저장된 혹은 현재 소모하고 있는 콘텐츠의 정보들을 수집하여 보고할 수 있다. TDO는 자체적으로 XMLHttpRequest라는 자바스크립트 API를 활용하여 수집된 데이터들을 전송할 수 있다.
URLlist는 UrlList, TptUrl, UrsUrl, 및/또는 PdiUrl 등을 포함할 수 있다. 이 엘리먼트들의 시맨틱은 다음과 같다.
UrlList 엘리먼트의 엘리먼트인 TptUrl는 현재의 양방향 부가 서비스 내 미래 세그먼트에 대한 TPT의 URL을 포함할 수 있다. 다수의 TptUrl 엘리먼트들이 포함된 경우, 방송 내 세그먼트들의 등장 순서대로 배열될 수 있다.
UrlList 엘리먼트의 엘리먼트인 NrtSignalingUrl은 수신기들이 현재의 트랜스포트 스트림 내 모든 가상 채널들에 대한 NRT 시그널링 테이블을 얻을 수 있는 서버의 URL을 포함할 수 있다.
UrlList 엘리먼트의 엘리먼트인 UrsUrl은 수신기들이 현재의 가상 채널에 대한 사용시청률 조사) 보고를 전송할 수 있는 서버의 URL을 포함할 수 있다.
UrlList 엘리먼트의 엘리먼트인 PdiUrl은 현재의 가상 채널에 대한 PDI-Q 테이블의 URL을 포함할 수 있다.
도 16은 TPT들을 포함하는 프라이빗 섹션들의 이진 포맷의 일 실시예를 나타낸 도면이다. 도 16은 후술하는 전달 메커니즘에서 방송 스트림으로 TPT가 전달되는 경우를 도시한다. 자세한 내용은 후술한다.
트리거, TPT 등을 전달하는 전달 메커니즘에 대해 서술한다. 양방향 서비스 생성으로부터의 결과, 방송 스트림에서의 트리거의 전달, 인터넷을 통한 시간 베이스 트리거의 전달, 인터넷을 통한 활성화 트리거의 전달 (ACR 시나리오), 방송 스트림에서의 TPT의 전달, 인터넷을 통한 TPT의 전달, TDO 및 콘텐츠 아이템의 이동, 다수의 세그먼트를 하나의 세그먼트로 합치기에 대해 순차적으로 설명한다.
이하 양방향 서비스 생성으로부터의 결과에 대해 설명한다.
하나의 세그먼트에 대한 서비스 생성 과정은 모든 TDO 및 다른 콘텐트 아이템들을 포함하는 폴더, XML 포맷의 TPT 파일, 및 XML 포맷의 AMT 파일을 생성할 수 있다. 그 밖에 다른 결과물도 생성될 수 있다.
이하 방송 스트림에서의 트리거의 전달에 대해 설명한다.
방송 스트림으로 전달될 경우, 트리거들은 URLString 명령 내에서 서비스 #6에서 DTV 클로즈드 캡션 채널로 전달될 수 있다.
만일 트리거의 길이가 26개 문자 이하이면, 트리거는 세그먼트화되지 않고 전송될 수 있다. (Type=11) 만일 트리거의 길이가 27 내지 52개 문자이면 두 개의 세그먼트 (Type=00 세그먼트 내 첫 번째 세그먼트와 Type=10 세그먼트 내 두 번째 세그먼트)로 전송될 수 있다.
해당 명령의 주어진 임의의 인스턴스에서 전달된 URI의 유형은 8비트 파라미터에 의해 주어질 수 있다.
TDO 모델을 사용하는 양방향 서비스들의 경우, URI 데이터 구조의 URI 유형은 0 (TDO 모델을 위한 양방향 TV 트리거)로 설정될 수 있다. 이 전달 메커니즘은 시간 베이스 트리거와 활성화 트리거를 모두 포함한다.
시간 베이스 트리거가 (클로즈드 캡션 서비스 #6에서) 방송 스트림으로 전달되는 경우에, "m=" 항이 부재하면 시간 베이스 트리거들은 단순히 시그널링 서버의 URL을 전달할 수 있다. 그리고 "m=" 항이 부재하면, "t=" 항은 활성화 트리거들에 부재해야 한다.
활성화 트리거가 (클로즈드 캡션 서비스 #6에서) 방송 스트림으로 전달되는 경우에, 즉, "Trigger" 포맷이 "e=" 항을 가지고 있고, "t=" 항은 가지고 있거나 없는 경우에, "t=" 항이 존재하면, 활성화 시간은 시간 베이스에 대한 타임 스탬프일 수 있다. 그리고 "t=" 항이 부재하면, 활성화 시간은 메시지의 도달 시간이 될 수 있다.
시간 베이스 트리거와 활성화 트리거가 CC 서비스 #6를 통해 전달되는 경우, 방송국에서 시간 베이스 트리거와 활성화 트리거들을 다루는 방법에는 세 가지 가능한 방법이 있다. 이 세 가지 방법은 '명시적인 시간 베이스가 없는 세그먼트 모드', '명시적인 시간 베이스가 있는 세그먼트 모드', 그리고 '명시적인 시간 베이스가 없는 서비스 모드'이다.
이들은 방송 내에서 세그먼트 단위로 혼합될 수 있다.
명시적인 시간 베이스가 없는 세그먼트 모드에서는, 활성화 메시지들이 타임 스탬프를 포함하지 않아, 각 메시지의 활성화 시간은 그 메시지의 전달 시간이 될 수 있고, 또한 시간 베이스 메시지들이 타임 스탬프를 포함하지 않아, 그 유일한 목적은 TPT 파일들을 전달할 수 있는 시그널링 서버의 URL을 제공하는 것일 수 있다. 이 모드에서는 시그널링 서버의 URL을 제공하기 위한 활성화 메시지 내의 URL에 따라 시간 베이스 메시지들이 완전히 생략될 수도 있지만, 이 경우 수신기들은 첫 번째 활성화 메시지들이 등장할 때까지 TPT를 검색하거나 TDO의 다운로드를 시작할 수 없게 되고, 활성화 메시지에 대한 응답을 상당히 지연하게 된다.
이러한 경우, CC 서비스 #6에 등장할 수 있는 시간 베이스 메시지들은 "Trigger" 포맷의 "locator_part"를 포함할 수 있고, "spread" 항도 포함할 수도 있지만, "media_time" 항은 포함하지 않을 수 있다. 그리고 CC 서비스 #6에서 등장할 수 있는 활성화 메시지들은 "Trigger" 포맷의 "locator_part"와 "event_time" 항을 포함할 수 있고, "spread" 항도 포함할 수 있지만, "이벤트_time" 항에는 "t=" 부분이 없을 수 있다. 시간 베이스 및 활성화 메시지들의 "locator_part"는 현재의 segmentId일 수 있다. 이 URL은 인터넷을 통해 세그먼트를 위한 TPT를 검색하는 데도 사용될 수 있다.
명시적인 시간 베이스가 있는 서비스 모드에서, 시간 베이스 메시지들은 시간 베이스를 정의하기 위해 이 타임 스탬프를 포함한다. 활성화 메시지들은 시간 베이스에 대한 활성화 시간을 정의하기 위해 시간 스탬프를 포함한다. 또는 이 메시지들은 타임 스탬프를 포함하지 않을 수 있으며, 이 경우 활성화 시간은 메시지의 도달 시간이다.
이 경우, CC 서비스 #6에서 등장할 수 있는 시간 베이스 메시지들은 Trigger" 포맷의 "locator_part"와 "media_time" 항을 포함할 수 있고, "spread" 항을 포함하는 것도 가능하며, CC 서비스 #6에서 등장할 수 있는 활성화 메시지들은 "Trigger" 포맷의 "locator_part"와 "event_time" 항을 포함할 수 있고, "spread" 항을 포함하는 것도 가능하며, 이 때 "event_time" 항 내 "t=" 부분은 있을 수도 있고 없을 수도 있다. 시간 베이스 및 활성화 메시지들의 "locator_part"는 현재의 segmentId일 수 있고, 해당 시간 베이스는 해당 세그먼트에 대해 특정하다. 이 URL은 인터넷을 통해 세그먼트를 위한 TPT를 검색하는데도 사용될 수 있다.
명시적인 시간 베이스가 있는 서비스 모드에서, 시간 베이스 메시지들은 시간 베이스를 정의하기 위해 타임 스탬프를 포함하고, 활성화 메시지들은 시간 스탬프를 포함하거나 하지 않을 수 있다. 시간 베이스는 하나의 세그먼트에 특정되기 보다는 다수의 세그먼트에 걸쳐 연장할 있다. 시간 베이스 메시지들의 "locator_part"는 시간 베이스의 식별자일 수 있으며, 인터넷을 통해 서비스를 위한 TPT들을 검색하기 위해 사용될 수 있는 URL일 수도 있다.
어떤 경우이든지 CC 서비스 #6에 트리거들을 삽입하는 트리거 삽입 서버는 AMT로부터 작업을 하여 활성화 메시지들을 AMT 내의 XMS 포맷으로부터 CC 서비스 #6에서의 전달에 특정된 트리거 포맷으로 옮겨야 한다. endTime 속성이 없는 Activation 엘리먼트의 경우에는, 활성화 시간이 startTime 속성과 동일하고, 단일 트리거가 삽입될 수 있다. startTime과 endTime 엘리먼트들을 모두 가진 Activation 엘리먼트의 경우에는 동일한 타겟을 가지고 트리거 시퀀스가 삽입될 수 있다. 시퀀스 내 첫 번째 트리거는 startTime 속성과 동일한 활성화 시간을 가질 수 있고, 해당 시퀀스 내 마지막 트리거는 endTime 속성과 동일한 활성화 시간을 가질 수 있으며, 시퀀스 내 트리거들의 활성화 시간들 사이에는 고정된 시간 구간이 존재할 수 있다. (예외적으로 시퀀스 내 마지막 트리거와 그 바로 앞의 트리거 사이의 구간은 더 짧을 수 있다.) 이 고정된 시간 구간의 길이는 설정 가능할 수 있다.
시간 베이스 및 활성화 메시지들이 세그먼트 모드일 때, 시간 베이스는 세그먼트에 대하여 특정될 수 있다. 이 베이스는 해당 세그먼트의 시작 때 "beginMT" 값으로 시작하여 세그먼트를 통하여 이어질 수 있다. 개개의 활성화들의 "startTime"과 "endTime" 값들은 "beginMT" 값에 대하여 상대적일 수 있다. 시간 베이스 및 활성화 메시지들이 서비스 모드에 있을 때, 시간 베이스는 세그먼트들에 걸쳐 이어질 수 있고, 각 세그먼트에 대한 "beginMT" 값은 서비스 시간 베이스와 방송 스케줄을 고려하여 조정될 수 있다.
이하 인터넷을 통한 시간 베이스 트리거의 전달에 대해 설명한다.
시간 베이스 트리거의 인터넷 전달은 소위 자동콘텐츠인식(Automatic Content Recognition; ACR) 상황에서 유용할 수 있는데, 이러한 상황들에서 시간 베이스 트리거의 수신측은 클로즈드 캡션 서비스 #6에 대한 접근 권한이 없다. 이러한 상황에서 수신기는 비디오 프레임들을 인식하고 시간 베이스들을 이 프레임들과 동기화시키기 위해 ACR을 사용해야 한다. ACR 상황에서 시간 베이스 메시지들은 워터마크 또는 ACR 서버들로부터 얻을 수 있다. ACR 서버로부터 받는 경우, 시간 베이스 메시지들은 ACR 서버로부터 응답으로서 전달될 수 있다.
이하 인터넷을 통한 활성화 트리거의 전달 (ACR 시나리오)에 대해 설명한다.
활성화 메시지들은 숏 폴링, 롱 폴링 또는 스트리밍을 통해 전달될 수 있지만, 이들 메시지들은 모두 수신기와 서버에 상당한 오버로드를 발생시킬 수 있다. 활성화 메시지들은 AMT의 형태로 전달될 수도 있지만, 세그먼트들의 길이에 대한 많은 양의 정보를 제공하여, 광고사이트 차단기(ad killer)를 가능하게 할 수 있다. 다른 방법들도 있을 수 있다.
활성화 메시지가 활성화 트리거의 형태로 전달되는 경우, 즉 "Trigger" format에서 "e=" 항은 있고, "t=" 항은 있거나 없는 경우에, 이는 HTTP 숏 폴링, 롱 폴링 또는 스트리밍을 통해 전달될 수 있다.
인터넷을 통해 전달되는 경우, 활성화 메시지들은 개별적 활성화 트리거 전달 메커니즘이나 일괄적 활성화 트리거 전달 메커니즘 중 하나 또는 이 두 메커니즘을 모두 사용하여 전달될 수 있다.
이하 개별적 활성화 트리거 전달에 대해 설명한다.
앞서 언급했던 바와 같이, 개별 활성화 트리거들은 인터넷을 통해 전달될 때, HTTP 숏 폴링, 롱 폴링 또는 스트리밍을 이용하여 전달될 수 있다. 활성화 트리거의 포맷은 DTVCC 서비스 #6을 통해 전달될 때와 동일할 있다.
숏 폴링의 경우에는 그 폴링 주기를 지정해 주어야 한다. 이 주기는 다음의 설명과 같이, TPT에 있는 pollPeriod를 이용하여 숏 폴링 동작을 설정할 수 있다.
활성화 트리거들의 인터넷 전달이 이용 가능할 경우, TPT 내 LiveTrigger 엘리먼트의 URL 속성은 활성화 트리거를 전달할 수 있는 활성화 트리거 서버를 지시할 수 있다. LiveTrigger 엘리먼트의 pollPeriod 속성이 TPT에 존재할 경우, 이는 HTTP 숏 폴링이 사용 중임을 지시할 수 있고, 이 속성은 수신기가 사용해야 할 폴링 주기를 지시할 수 있다. LiveTrigger 엘리먼트의 pollPeriod 속성이 TPT에 존재하지 않을 경우, 이는 HTTP 롱 폴링과 HTTP 스트리밍 중 어느 하나가 사용 중임을 지시할 수 있다.
어떤 프로토콜이 사용되는지에 관계없이, 수신기는 질의 형식으로 활성화 트리거 서버에 HTTP 요청을 하는 것으로 예상할 수 있다.
?mt=<media_time>
여기에서 <media_time>은 시청되고 있는 콘텐트의 현재 미디어 시간일 수 있다.
숏 폴링이 사용 중인 경우, 활성화 트리거 서버로부터의 응답은 <media_time>에서 끝나는 pollPeriod 길이의 시간 구간 내에서 발생된 모든 트리거들을 포함할 수 있다. 하나 이상의 활성화 트리거가 리턴되는 경우, 이들은 하나 이상의 공백(white space) 문자들에 의해 분리될 수 있다. 만일 리턴되는 활성화 트리거가 없으면, 해당 응답은 비어 있을 수 있다.
HTTP 롱 폴링 또는 HTTP 스트리밍이 사용 중인 경우에는, 활성화 트리거 서버는 활성화 트리거가 방송 스트림으로 전달될 미디어 시간까지 응답의 리턴을 대기할 수 있다. 이 때, 활성화 트리거를 리턴할 수 있다.
HTTP 롱 폴링이 사용 중인 경우, 활성화 트리거 서버는 활성화 트리거를 리턴 후 세션을 닫을 수 있다. 수신기는 업데이트된 미디어 시간을 이용하여 즉시 또 다른 요청을 하는 것으로 예상할 수 있다.
HTTP 스트리밍이 사용 중인 경우, 활성화 트리거 서버는 각 활성화 트리거를 리턴한 후 해당 세션을 열린 상태로 유지하고, 추가적인 활성화 트리거들을 전달할 시간이 도달하면 해당 세션에서 이 트리거들을 전달할 수 있다.
어느 경우이든지 HTTP 응답은 전달 모드를 알리기 위해 다음 형태들 중 어느 하나의 형태로 된 HTTP 응답 헤더 필드를 포함할 수 있다.
ATSC-Delivery-Mode: ShortPolling [<poll-period>]
ATSC-Delivery-Mode: LongPolling
ATSC-Delivery-Mode: Streaming
<poll-period> 파라미터는 연속되는 폴들에 대하여 폴 사이의 권장 간격을 지시할 수 있다. <poll-period>는 생략될 수 있다.
이하 활성화 트리거 일괄 전달에 대해 설명한다.
활성화 트리거들이 인터넷을 통해 일괄적으로 전달되는 경우, 하나의 세그먼트에 대한 활성화 트리거들은 해당 세그먼트에 대한 TPT를 메시지의 첫 번째 부분으로 하고 AMT를 메시지의 두 번째 부분으로 하는 다중 부분 MIME 메시지의 형태로 HTTP를 통해 해당 세그먼트에 대한 TPT와 함께 전달될 수 있다.
이하 방송 스트림에서의 TPT 전달에 대해 설명한다.
방송 스트림으로 전달 시, TPT들은 이들의 XML 포맷에서 상응하는 이진 NRT-스타일 시그널링 포맷으로 변환되어 테이블 인스턴스 당 TPT 하나씩 NRT-스타일 프라이빗 섹션들에 캡슐화될 수 있다. 현재 세그먼트에 대한 TPT는 항상 존재한다. 하나 이상의 미래 세그먼트들에 대한 TPT들도 존재할 있다. TPT 인스턴스는 그 segment_id 필드의 값에 의해 정의된다. 참고로, TDO 파라미터 테이블의 이진 포맷은 위에서 살펴본 바와 같다. 여기서, NRT-스타일 프라이빗 섹션은 도 16의 tpt_section()에 해당할 수 있다.
정리하면, TPT의 이진 구조를 NRT로 전송하기 위해서, TPT는 NRT 전송에 적합한 섹션 구조를 가질 수 있다. 이 과정에 대해 이하 상세히 설명한다.
각 TPT를 블록들로 분할하고 이 블록들을 table_id, protocol_version TPT_data_version과 sequence_number 필드의 공통 값을 가지는 섹션들의 tpt_bytes() 필드들에 삽입함으로써 각 TPT는 NRT-스타일 프라이빗 섹션들 내에 캡슐화될 수 있다. 블록들은 section_number 필드 값들의 오름차순으로 섹션들에 삽입될 수 있다. 프라이빗 섹션들은 TPT에 관련된 가상 채널의 IP 서브넷의 서비스 시그널링 채널(Service Signaling Channel; SSC)로 전송될 수 있다. 여기서, "Service Signaling Channel"은 ATSC-NRT 표준에 정의되어 있으며, 특정 IP 주소와 포트 넘버를 가지는 채널을 의미한다. 섹션들 내의 sequence_number 필드들은 동일한 SSC로 전송되는 상이한 TPT 인스턴스들을 구분하기 위해 사용될 수 있다.
이하 도 16 의 필드들에 대해서 설명한다.
프라이빗 섹션(tpt_section())은 table_id, protocol_version, sequence_number, TPT_data_version, current_next_indicator, section_number, last_section_number, 및/또는 service_id, tpt_bytes() 정보를 포함할 수 있다.
8비트 필드일 수 있는 table_id는 해당 테이블 섹션이 TDO 파라미터 테이블 인스턴스에 속하는 것으로 식별할 수 있다.
protocol_version은 두 부분으로 나눠볼 수 있다. 8비트 무부호 정수 필드 중 상위 4비트는 해당 테이블의 정의의 주 버전 넘버와 여기에 포함되어 전송되는 TPT 인스턴스를 지시할 수 있고, 하위 4비트는 부 버전 넘버를 지시할 수 있다. 주 버전 넘버는 1로 설정될 수 있다. 수신기들은 이들이 지원하도록 구비되지 않은 주 버전 값들을 지시하는 AMT의 인스턴스들을 버리는 것으로 예상할 수 있다. 부 버전 넘버는 0으로 설정될 수 있다. 수신기들은 이들이 지원하도록 구비되지 않은 부 버전 값들을 지시하는 AMT의 인스턴스들을 버리지 않는 것으로 예상할 수 있다. 이 경우, 수신기들은 이들이 인식하지 못하는 디스크립터들과 이들이 지원하지 않는 필드들을 무시하는 것으로 예상할 수 있다.
sequence_number는 8비트 필드일 수 있다. sequence_number는 해당 TPT 인스턴스의 다른 모든 섹션들의 sequence_number와 동일하고, 해당 서비스 시그널링 채널 내 다른 TPT 인스턴스의 모든 섹션들의 sequence_number와는 다를 수 있다. 따라서 다른 TPT 인스턴스와 구별하는 역할을 할 수 있다. sequence_number 필드는 이 섹션이 나타나는 서비스 시그널링 채널과 연관된 IP 서브넷을 가리킬 수 있다. 서로 다른 TPT 인스턴스들의 sequence_number 필드 값들은 방송 스트림에서 세그먼트들이 등장하는 순서를 반영할 수 있다.
TPT_data_version는 5비트 필드일 수 있으며, 해당 TPT 인스턴스의 버전 넘버를 지시할 수 있는데, 여기서 TPT 인스턴스는 그 segment_id에 의해 정의될 수 있다. TPT 버전을 미리 알아야 수신된 TPT 섹션 데이터가 최신 버전의 TPT인지 알 수 있기 때문에 섹션 테이블에 TPT_data_version 필드가 있을 수 있다. 버전 넘버는 TPT 인스턴스 내 임의의 필드에 변경이 있을 경우 1 modulo 32 만큼씩 증분될 수 있다.
current_next_indicator는 1비트 지시자일 수 있으며, TPT 섹션들에 대해 항상 '1'로 설정되어, 전송되는 TPT가 항상 segment_id에 의해 식별되는 세그먼트에 대한 현재 TPT임을 지시할 수 있다.
section_number는 8비트 필드일 수 있으며, 해당 TPT 인스턴스 섹션의 섹션 번호를 제공할 수 있는데, TPT 인스턴스는 segment_id에 의해 식별될 수 있다. TPT 인스턴스 내 첫 번째 섹션의 section_number는 0x00일 있다. section_number는 TPT 인스턴스 내의 각 추가 섹션과 함께 1씩 증분될 수 있다.
last_section_number는 8비트 필드일 수 있으며, 마지막 섹션(즉, section_number가 가장 높은 섹션)이 그 일부인 TPT 인스턴스의 마지막 섹션 번호를 제공할 수 있다.
service_id는 해당 테이블 인스턴스에 기술된 콘텐트 아이템들을 제공하는 양방향 서비스와 연관된 service_id를 특정할 수 있다.
tpt_bytes()는 가변 길이 필드로서, 해당 섹션에 의해 부분적으로 전송되는 TPT 인스턴스 블록으로 구성될 수 있다. 해당 테이블 인스턴스의 모든 섹션의 tpt_bytes() 필드들이 section_number 필드들의 순서대로 연결되면, 그 결과 하나의 온전한 TPT 인스턴스가 만들어질 수 있다.
즉, TPT의 이진 포맷을 이용하거나, XML 포맷을 이진 포맷으로 바꾼 후, NRT 전송에 맞도록 이를 나누어 프라이빗 섹션 중 tpt_bytes() 필드에 넣어 NRT 방식으로 전송할 수 있다. 이 때 하나의 TPT가 여러 프라이빗 섹션으로 나눠질 경우, 각각의 프라이빗 섹션은 동일한 table_id, protocol_version TPT_data_version, sequence_number 값을 가질 수 있다. 나눠진 TPT 블록들은 section_number 필드 값에 따른 순서대로 삽입될 수 있다.
수신단에서는 수신한 프라이빗 섹션들에 대하여 파싱할 수 있다. 하나의 TPT로 다시 합치기 위하여, 동일한 table_id, protocol_version TPT_data_version, sequence_number 값을 가지는 프라이빗 섹션들을 이용할 수 있다. 이 때, section_number와 last_section_number 정보로부터 얻을 수 있는 순서 정보를 이용할 수 있다. 동일한 table_id, protocol_version TPT_data_version, sequence_number 값을 가지는 모든 프라이빗 섹션들의 tpt_bytes()가 section_number의 순서대로 연결되면 하나의 온전한 TPT가 만들어 질 수 있다.
인터넷을 통한 TPT의 전달에 대해 도 17을 참조하여 상세히 설명한다.
이하 TDO 및 콘텐트 아이템의 이동에 대해서 설명한다.
네트워크와 기지국들은 TDO 및 이 TDO들에 의해 사용되는 콘텐트 아이템들(파일들)의 전달을 위해 자체 HTTP 서버들을 자주 제공해야 한다. 제공이 이루어지면, TPT 내의 baseURL은 서버의 위치를 반영하여 조정될 수 있다.
이하 다수의 세그먼트를 하나의 세그먼트로 합치기에 대해서 설명한다.
세그먼트들 사이의 경계를 철저하게 모호하게 만들기 위해, 다수의 세그먼트들에 대한 TPT들과 AMT들은 하나의 TPT 및 AMT로 합쳐질 수 있다. 그 단계는 다음과 같을 수 있다.
1. 합쳐질 세그먼트들의 집합을 식별한다.
2. 새로운 segmentId를 가진 새로운 TPT를 생성한다.
3. 합쳐지는 세그먼트들 중 라이브 활성화들을 가지는 것이 있으면, 이들 활성화 모두에 대해 접근 권한을 부여하는 릴레이 서버를 제공하고, 이 서버에 대한 파라미터들을 "LiveTrigger" 엘리먼트에 넣는다.
4. 필요에 따라 각 세그먼트에 대하여 baseURL을 적용하여 전체 TDO와 ContentItem URL들을 얻는다. (합쳐지는 모든 세그먼트들에 공통적인 더 짧은 baseURL을 식별하고 이를 합쳐진 세그먼트에 대한 baseURL로 유지한다.)
5. 필요에 따라 값들을 수정하여 충돌을 제거한다.
6. 합쳐지는 모든 세그먼트들에 대한 모든 수정된 TDO 엘리먼트들을 새로운 TPT에 삽입한다.
7. 합쳐진 TPT의 새로운 segmentId에 상응하는 segmentId를 가지는 새로운 AMT를 생성한다.
8. 새로운 AMT에 대해 적절한 새로운 "beginMT" 값을 선택한다.
9. appId 값들에서의 변경을 반영하여 합쳐지는 세그먼트들에 대한 AMT 파일들 내의 모든 Activation 엘리먼트의 targetId 값들을 조정한다.
10. 새로운 "beginMT" 값과 합쳐지는 세그먼트들에 대한 방송 스케줄을 반영하여, 합쳐지는 세그먼트들에 대한 AMT 파일들 내의 모든 Activation 엘리먼트의 startTime과 endTime 값을 조정한다.
11. 수정된 모든 Activation 엘리먼트들을 새로운 AMT에 삽입한다.
도 17은 XML 문서로 인코딩된 URL 목록의 일 실시예를 나타낸 도면이다.
이하 인터넷을 통한 TPT의 전달에 대하여 설명한다.
인터넷으로 전달될 경우, TPT들은 HTTP를 통해 전달될 수 있다. 시간 베이스 메시지에서 현재 세그먼트에 대한 TPT의 URL은 "<domain name part>/<directory path>"일 수 있다. TPT에 대한 요청에 대한 응답은 단순히 TPT로 구성되거나, 요청된 TPT는 제1 부분에 있고 URL 리스트는 제2 부분에 있어 XML 문서로서 인코딩되는 2-부분 MIME 메시지로 구성될 수 있다. (요청에 대한 응답은 항상 현재 세그먼트에 대한 TPT를 포함하게 된다. 하나 이상의 미래 세그먼트들에 대한 TPT들도 포함할 있다.)
위에서 설명한 응답의 제2 부분으로서의 URL들은 도 17와 같은 형태일 수 있다.
도 17 의 엘리먼트의 시맨틱에 대해 설명한다.
"UrlList"는 수신기에 유용할 수 있는 URL 리스트를 포함할 수 있다.
"TptUrl"은 미래 세그먼트에 대한 TPT의 URL을 포함할 수 있다. 다수의 TptUrl 엘리먼트들이 포함될 경우, 이들은 방송에서 세그먼트들의 등장 순서대로 배열될 수 있다.
"NrtSignalingUrl"은 수신기가 현재의 방송 스트림으로 모든 가상 채널들에 대한 NRT 시그널링 테이블들을 얻을 수 있는 서버의 URL을 포함할 수 있다.
도 18은 addTriggerEventListener의 일 실시예를 나타낸 도면이다.
이하 DO를 실행하기 위한 환경을 위한, ATSC JavaScript API들에 대해 설명한다.
방송 프로그램에 대한 선언적 객체 동작들의 동기화를 지원하기 위해, 비디오/방송 객체에 대해 추가적인 방법들이 지원될 수 있다.
DTVCC 혹은 인터넷으로 TPT가 수신이 되면 TPT내에는 TDO를 실행하기 위한 여러 개의 이벤트들이 있을 수 있으며 이 이벤트들은 활성화 트리거에 의하여 활성화 될 수 있다.
이 이벤트를 처리하도록 하기 위하여, 리스너(Listener)라는 함수를 eventID별로 등록해 둘 수 있다. 이에 따라, 위에서 설명한 '추가적인 방안들' 로서, 리스너 함수를 등록할 수 있는 다음의 두개의 함수가 있을 수 있다.
도 18에서, addTriggerEventListener에 대한 설명과 포맷, 인수(argument) 등이 도시되어 있다.
"addTriggerEventListener" 함수는 eventId마다 생성된 이벤트를 처리하는 콜백(callback) 함수 (리스너 함수)를 등록할 수 있다. "addTriggerEventListener" 함수는 EventListener 타입의 listener 및 Number 타입의 eventId를 인수로 입력받을 수 있다. EventListener 타입에 대해 후술한다. "addTriggerEventListener" 함수는 반환값을 가지지 않을 수 있다(void). 여기서, eventId 인수는 TPT의 이벤트 엘리먼트에서 이벤트 ID일 수 있다. 여기서, listener 인수는 이벤트에 대한 리스너일 수 있다.
수신기의 트리거 처리 모듈에서는 활성화 메시지를 수신하자마자 "addTriggerEventListener" 함수를 이용하여 eventId 마다 리스너 함수를 등록할 수 있다. 추후 해당 이벤트에 활성화가 일어나면 등록된 리스너 함수가 호출될 수 있다. 이 때, TriggerEvent 타입의 객체는 리스너 함수로 전달될 수 있다. TriggerEvent 타입에 대해서는 후술한다.
도 19는 removeTriggerEventListener의 일 실시예를 나타낸 도면이다.
도 19 에서, removeTriggerEventListener에 대한 설명과 포맷, 인수 등이 도시되어 있다.
"removeTriggerEventListener" 함수는 eventId마다 생성된 이벤트를 처리하는 콜백 함수 (리스너 함수)의 등록을 취소할 수 있다. "removeTriggerEventListener" 함수는 EventListener 타입의 listener 및 Number 타입의 eventId를 인수로 입력받을 수 있다. EventListener 타입에 대해 후술한다. "removeTriggerEventListener" 함수는 반환값을 가지지 않을 수 있다(void). 여기서, eventId 인수는 TPT의 이벤트 엘리먼트에서 이벤트 ID일 수 있다. 여기서, listener 인수는 이벤트에 대한 리스너일 수 있다.
자바스크립트 프로그램에서는, 더 이상 해당 eventide 별로 발생할 수 있는 이벤트를 더 이상 수신하지 않기를 원하거나 "DestroyWindow"와 같은 프로그램 종료시에는 "removeTriggerEventListener"를 이용하여 등록된 리스너 함수를 취소할 수 있다.
도 20은 EventListener 타입의 정의의 일 실시예를 나타낸 도면이다.
여기서, EventListener 타입의 정의는 Web IDL(Web interface definition language)(인터페이스 정의 언어)에 따른다. Web IDL은 웹 브라우저에서 실행되도록 의도된 인터페이스를 서술하는 데 사용될 수 있다. Web IDL은 웹 플랫폼에서의 공용 스크립트 오브젝트들의 동작을 보다 읽기 쉽도록 명세화하기 위한 수많은 기능들을 가진 IDL의 변종이다.
EventListener 타입은 TriggerEvent 타입을 가지는 이벤트를 인수로 할 수 있다. EventListener는 인터페이스일 수 있다.
도 21은 TriggerEvent 타입의 정의의 일 실시예를 나타낸 도면이다.
TriggerEvent 타입은 이벤트에 대한 정보를 담고 있을 수 있다.
TriggerEvent 타입은 eventId, data, status를 속성으로 가질 수 있다. 여기서 eventId는 TPT의 이벤트 엘리먼트 안의 eventId일 수 있다. 여기서 data는 이벤트의 활성화를 위한 일 수 있다. 여기서 data는 16진법으로 되어 있을 수 있다. 여기서 status는 이벤트의 상태를 의미할 수 있다. 여기서 status 값이 "trigger"일 경우는 이벤트가 활성화 트리거에 의해 활성화된 상태를 의미할 수 있다. 여기서 status 값이 "error"일 경우는 에러가 발생한 상태를 의미할 수 있다.
TDO 모델에 대해 설명하였다. 이후, 직접 실행 모델에 대해 설명한다.
직접 실행 모델에서는, 가상 채널이 선택되면 선언적 객체(Declarative Object; DO)가 자동으로 개시될 수 있다. DO는 스크린 상의 특정 위치에서의 화면의 생성, 여론 조사 수행, 다른 특수 DO들의 개시 등과 같이 오디오-비디오 프로그램과 동기화되는 양방향 특징들의 제공을 위한 구체적인 지시사항들을 얻기 위해 백엔드(backend) 서버와 인터넷을 통해 통신할 수 있다.
이하 직접 실행 모델에서의 트리거 동작에 대해 설명한다.
트리거의 역할, 기능, 신택스는 직접 실행 모델이라고 하여 크게 달라지지 않는다.
트리거의 성능에 대해서는 앞서 설명한 것과 같다.
트리거 신택스에 대해서는 앞서 설명한 것과 같다.
트리거는 세 부분으로 구성된 것으로 볼 수 있다.
<도메인 네임 부분> / <디렉토리 경로> [ ? <파라미터들> ]
직접 실행 모델에서, <도메인 네임 부분>과 <디렉토리 경로>의 조합은 개시될 DO를 고유하게 식별할 수 있다.
<파라미터들>은 "event_time", "media_time", 또는 "spread" 중 하나 이상으로 이루어질 수 있다.
직접 실행 모델에서, 가상 채널이 선택되면 바로 어플리케이션이 자동으로 개시될 수 있다. 직접 실행 모델에서, 가상 채널이 선택되면 바로 어플리케이션이 자동으로 개시될 수 있다. 어플리케이션은 "동기화된 콘텐트 프로토콜"을 통해 백엔드 서버와 인터넷으로 통신할 수 있다. 이 서버는 오디오-비디오 프로그램과 모두 동기화된 양방향 특징의 제공을 위한 구체적인 지시사항들을 제공할 수 있다.
직접 실행 모델의 경우, 그 즉시 어플리케이션이 실행되기 때문에, 시간 베이스 트리거가 전달되는 대로 현재 실행중인 어플리케이션으로 정보를 전달할 수 있다. 이 모델에서, 어플리케이션은 서버에, 동기화를 위하여, 현재 방영중인 콘텐츠에 대한 정보를 계속해서 전달할 필요가 있다. 이를 위하여 시간 베이스 트리거에는 TDO 모델과는 다른 특별한 정보가 더 포함될 수 있다. 이 특별한 정보는 현재 방영중인 콘텐츠에 대한 식별자일 수 있다.
유사하게는 상기 콘텐츠 식별자는 트리거의 파라미터 부분에 파라미터의 형태로 존재할 수 있다.
유사하게는 상기 콘텐츠 식별자는 트리거의 media_time에 하나의 항의 형태로 존재할 수 있다. 콘텐트 식별자 항은 문자열을 수반하는 "c ="에 의해 지정될 수 있는 content_id로 불릴 수 있으며, 현재 보여지고 있는 콘텐트에 대한 식별자를 나타낼 수 있다.
content_id 항은 양방향 서비스 실행에 대한 직접 실행 모델을 지원하기 위한 것일 수 있다.
상기에서 설명한대로, 이 모델에서, content_id 항을 가진 시간 베이스 트리거는 어플리케이션의 개시 후 이 어플리케이션으로 전달될 수 있고, 이 어플리케이션은 양방향 작용을 위한 컨텍스트(context)의 식별을 위해 content_id를 백엔드 서버로 전달할 수 있다. 자세한 동작에 대해서는 후술한다.
직접 실행 모델에서의 트리거의 전달 메커니즘에 대해서는 앞서 설명한 것과 같다.
단, 방송 스트림으로의 트리거의 전달의 경우에 있어, 트리거들은 URLString 명령으로 서비스 #6에서 DTV 클로즈드 캡션 채널로 전달될 수 있다. 그리고 직접 실행 모델을 이용하는 양방향 서비스들은, URI_type 필드가 2 (직접 실행 모델을 위한 양방향 TV트리거)로 설정될 수 있다.
이하 직접 실행 모델의 전체 동작에 대해 설명한다.
양방향 서비스를 실행하는 하나의 모델로서, 직접 실행 모델에서는, 가상 채널이 선택되면 바로 어플리케이션이 자동으로 개시될 수 있다. 어플리케이션 "동기화된 콘텐트 프로토콜"을 통해 인터넷으로 백엔드 서버와 통신할 수 있다. 이 서버는 스크린 상의 특정 위치에서의 화면의 생성, 여론 조사 수행, 다른 특수 DO들의 개시 등과 같이 오디오-비디오 프로그램과 동기화되는 양방향 특징들의 제공을 위한 구체적인 지시사항들을 제공할 수 있다.
상기 동작은 다음과 같이 수행될 수 있다.
우선, 어플리케이션이 개시될 수 있다. 그 후 시간 베이스 트리거를 수신한다. 시간 베이스 트리거는 어플리케이션이 실행된 후에 어플리케이션으로 전달된다. 시간 베이스 트리거의 content_id 항에는 현재 보여지는 콘텐츠에 대한 콘텐츠 식별 정보가 들어있을 수 있다. 어플리케이션은 상호작용을 위한 컨텍스트를 식별하고 현재 보여지고 있는 콘텐트를 식별하기 위하여 content_id를 백엔드 서버로 전달할 수 있다.
직접 실행 모델에 대해 설명하였다.
도 22는 WM 기법을 위한 아키텍처의 일실시예를 도시한 도면이다.
다른 인터페이스를 통한 전달에 대해 설명한다.
비압축된 오디오 및 비디오에만 접근할 수 있는(예를 들면, 케이블 또는 위성 셋톱박스로부터 수신되는) 환경에서 양방향 서비스의 획득을 가능하게 하는 프로토콜 및 아키텍처가 정의된다. 아키텍처 및 프로토콜은 인터넷 접속을 갖고 방송 스트림으로부터의 비압축된 오디오 및 비디오에만 접근할 수 있는 수신기에 의한 사용을 위해 설계될 수 있다. 물론, 아키텍처 및 프로토콜은 양방향 서비스 제공자가 그것의 지원을 선택한다면 성공적으로 사용될 수 있다.
이 아키텍처는 시청되고 있는 콘텐트의 식별을 위한 두 가지 기본 기법을 지원하도록 설계되어 관련 양방향 서비스 데이터 개선사항들이 인터넷을 통해 전달될 수 있도록 할 수 있다. 두 가지 기본 기법은 워터마킹(Watermarking)과 핑거프린팅(Fingerprinting)일 수 있다.
워터마킹과 핑거프린팅 기법 모두, 그 목적은 어떤 프로그램이 현재 시청되고 있는 지를 수신기들이 찾아내어 해당 프로그램을 위한 양방향 서비스에 대한 부가 정보를 얻는 출발점으로서 사용될 수 있는 URL을 얻을 수 있도록 하는 것이다.
도 22는 WM 기법을 위한 아키텍처의 일실시예를 도시한 도면이다.
WM 기법을 위한 아키텍처에서, 아키텍처는 방송국(22010), 워터마크 삽입부(22011), MVPD(22020), STB(22030), 수신기(22040), WM 클라이언트(22050), TPT 서버(22060) 및/또는 콘텐트 서버(22070)으로 이루어질 수 있다.
방송국(22010)은 오디오/비디오 스트림 및 오디오/비디오 스트림과 관련된 양방향 서비스를 출력하는 소스가 될 수 있다. 텔레비전 방송국이 방송국(22010)의 일례가 될 수 있다. 방송국(22010)은 방송 콘텐츠 생산자나 배급자가 될 수 있다. 방송국(22010)은 방송 스트림, 오디오/비디오 콘텐츠, 양방향 데이터, 방송 스케줄, 또는 AMT를 전달할 수 있다.
워터마크 삽입부(22011)는 워터마크를 방송 오디오/비디오 프레임에 삽입할 수 있다. 워터마크 삽입부(22011)는 방송국(22010)과 통합될 수도 있고, 개별 모듈일 수도 있다. 워터마크는 수신기에 필요한 정보일 수 있다. 워터마크는 URL과 같은 정보일 수 있다. 워터마크에 대해 상세히 후술한다.
MVPD(22020)는 다중채널 비디오 프로그램 유통업자(Multiprogram Video Program Distributor)의 약자일 수 있다. MVPD(22020)는 케이블 사업자, 위성 사업자 또는 IPTV 사업자일 수 있다. MVPD(22020)는 방송국/워터마크 삽입부로부터 방송 스트림을 수신할 수 있으며, 워터마킹 ACR 시스템의 경우 워터마크 삽입부(22011)에 의해 워터마크가 삽입된다. MVPD(22020)는 종종 오디오 및 비디오 트랙 이외의 다른 프로그램 엘리먼트들을 모두 제외한 스트림을 고객 댁내의 셋탑 박스(STB)에 보낸다.
STB(22030)는 일반적으로 오디오 및 비디오를 디코딩(압축해제)하여 이들을 시청자들에게 보여지는 TV 세트로 보낸다. STB는 비압축된 오디오/비디오 콘텐츠를 수신기(22040)에 보낼 수 있다. STB는 본 발명의 일 실시예에 따른 외부의 디코딩부일 수 있다.
수신기(22040)는 WM 클라이언트(22050)를 포함할 수 있다. WM 클라이언트(22050)는 수신기(22040) 외부에 있을 수도 있다. 여기서, 수신기는 워터마크킹을 할 수 있는 수신기이다. 수신기(22040)의 구조에 대해서는 후술한다.
WM 클라이언트(22050)는 해당 용도의 API를 이용하여 ACR 서버(미도시)로부터 활성화 트리거들을 받아 메인 수신기 코드로 이들을 보낼 수 있다. 일반적으로 WM 클라이언트(22050)은 수신기 내에 구성되지만, 다른 구성도 가능하다. WM 클라이언트(22050)는 비압축된 오디오/비디오 콘텐츠로부터, 삽입된 워터마크들을 추출할 수 있다. 워터마크들은 URL 등의 정보일 수 있다.
TPT 서버(22060)는 TPT와 같은 어플리케이션을 다운로드할 수 있는 서버일 수 있다. 수신기(22040)는 추출된 워터마크를 ACR 서버에 전송한다. 워터마크가 데이터베이스(미도시)에 저장된 워터마크와 매칭되면, 수신기(22040)는 트리거 또는 트리거들을 응답으로 수신할 수 있다. 수신된 트리거 또는 트리거들이 앞서 설명한 새로운 locator_part를 갖거나 새로운 버전의 TPT 또는 어플리케이션 파라미터 테이블이 발견되면, 수신기(22040)는 TPT 서버(22060)에게 새로운 TPT 또는 어플리케이션 파라미터 테이블을 다운로드할 것을 요청할 수 있다.
콘텐츠 서버(22070)는 양방향 서비스를 제공하는 데 필요한 어플리케이션 및 TDO를 제공할 수 있다. 새로운 어플리케이션 또는 TDO가 필요하면, 새로운 어플리케이션은 TPT 또는 어플리케이션 파라미터 테이블에 있는 URL을 이용하여 다운로드 될 수 있다.
워터마킹 (WM) 기법에서, 방송국/워터마크 삽입부는 방송되는 오디오/비디오 프레임들에 워터마크를 넣을 수 있다. 이 워터마크들은 시청자에게 감지되지 않거나 최소한으로만 거슬리는 정도의 양의 정보를 수신기에 전송하도록 설계될 수 있다. 이와 같은 워터마크들은 수신기들이 필요로 하는 정보를 직접 제공할 수도 있고, 또는 수신기들이 필요로 하는 정보를 얻기 위해 멀리 떨어진 서버에 인터넷 연결을 통해 보낼 수 있는 코드 값만 제공할 수도 있다.
도 23에서 FP 기법의 아키텍처의 일 실시예가 도시되어 있다.
FP 기법의 아키텍처에서, 아키텍처는 방송국(23010), MVPD(23020), STB(23030), 수신기(23040), FP 클라이언트(23050), TPT 서버(23060), 콘텐트 서버(23070), 시그니처(signature) 추출기(23080) 및/또는 FP 서버(23090)로 이루어질 수 있다.
방송국(23010)은 오디오/비디오 스트림 및 오디오/비디오 스트림과 관련된 양방향 서비스를 출력하는 소스가 될 수 있다. 텔레비전 방송국이 방송국(23010)의 일례가 될 수 있다. 방송국(23010)은 방송 콘텐츠 생산자나 배급자가 될 수 있다. 방송국(23010)은 방송 스트림, 오디오/비디오 콘텐츠, 양방향 데이터, 방송 스케줄, 또는 AMT를 전달할 수 있다.
MVPD(23020)는 다중채널 비디오 프로그램 유통업자(Multiprogram Video Program Distributor)의 약자일 수 있다. MVPD(23020)는 케이블 사업자, 위성 사업자 또는 IPTV 사업자일 수 있다. MVPD(23020)는 종종 오디오 및 비디오 트랙 이외의 다른 프로그램 엘리먼트들을 모두 제외한 스트림을 고객 댁내의 셋탑 박스(STB)에 보낸다.
STB(23030) 는 일반적으로 오디오 및 비디오를 디코딩(압축해제)하여 이들을 시청자들에게 보여지는 TV 세트로 보낸다. STB는 비압축된 오디오/비디오 콘텐츠를 수신기(23040)에 보낼 수 있다. STB(23030)는 본 발명의 일 실시예에 따른 외부의 디코딩부일 수 있다.
수신기(23040)는 FP 클라이언트(23050)를 포함할 수 있다. FP 클라이언트(23050)는 수신기(22040) 외부에 있을 수도 있다. 여기서, 수신기(23040)는 핑거프린팅을 할 수 있는 수신기이다. 수신기(23040)의 구조에 대해서는 후술한다.
FP 클라이언트(23050)은 해당 용도의 API를 이용하여, FP 서버(23090)로부터 활성화 트리거들을 받아 메인 수신기 코드로 이들을 보낼 수 있다. 일반적으로 FP 클라이언트(23050)은 수신기 내에 구성되지만 이와 달리 구성하는 것도 가능하다. FP 클라이언트(23050)은 비압축된 오디오/비디오 콘텐츠로부터, 핑거프린트를 추출할 수 있다. 핑거프린트에 대해서는 후술한다.
TPT 서버(23060)는 TPT와 같은 어플리케이션을 다운로드할 수 있는 서버일 수 있다. 수신기(23040)는 추출된 핑거프린트를 FP 서버(23090)에 전송한다. 핑거프린트가 시그니처 추출기(23080)의 시그니처와 매칭되면, 수신기(23040)는 트리거 또는 트리거들을 응답으로 수신할 수 있다. 수신된 트리거 또는 트리거들이 앞서 설명한 새로운 locator_part를 갖거나 새로운 버전의 TPT 또는 어플리케이션 파라미터 테이블이 발견되면, 수신기(23040)는 TPT 서버(23060)에게 새로운 TPT 또는 어플리케이션 파라미터 테이블을 다운로드할 것을 요청할 수 있다.
콘텐츠 서버(23070)는 양방향 서비스를 제공하는 데 필요한 어플리케이션 및 TDO를 제공할 수 있다. 새로운 어플리케이션 또는 TDO가 필요하면, 새로운 어플리케이션은 TPT 또는 어플리케이션 파라미터 테이블에 있는 URL을 이용하여 다운로드 될 수 있다.
시그니처 추출기(23080)는 방송국(23010)으로부터 메타데이터를 수신할 수 있다. 시그니처 추출기(23080)는 수신된 메타데이터로부터 프레임의 시그니처를 추출할 수 있다. FP 서버(23090)에 전송된 핑거프린트가 시그니처 추출기(23080)의 시그니처와 매칭되면, 시그니처 추출기(23080)는 시그니처와 관련된 메타데이터를 FP 서버(23090)에 전달할 수 있다.
FP 서버(23090)는 시그니처 추출기(23080)와 시그니처 매칭 동작을 수행할 수 있다. FP 서버(23090)는 시그니처를 수신기(23040)로부터 수신된 핑거프린트에 매칭할 수 있다. 시그니처가 핑거프린트에 매칭되면, FP 서버(23090)는 시그니처 추출기(23080)로부터 시그니처와 관련된 메타데이터를 수신할 수 있다. FP 서버(23090)는 메타데이터를 수신기(23040)에 전송할 수 있다.
핑거프린팅 (FP) 기법에서, FP 클라이언트(23050)은 오디오 또는 비디오 프레임들로부터 핑거프린트들(시그니처들이라고 부를 수도 있음)을 추출하고, 다중 방송국들로부터의 방송 프레임들에 대한 핑거프린트 데이터베이스에 대해 이 핑거프린트들을 검사하여 수신기(23040)들이 필요로하는 정보를 찾을 수 있다. 이와 같은 검사는 멀리 떨어진 서버에 대한 시그니처들에 의해 이루어질 수 있고, 원하는 정보를 가진 기록을 되돌려 받을 수 있으며, 일부 경우에는 수신기(23040)에 다운로드된 시그니처들의 데이터베이스에 대해 검사함으로써 검사가 이루어질 수 있다. 여기서, 멀리 떨러진 서버는 FP 서버(23090)일 수 있다.
워터마킹과 핑거프린팅은 서로 구별되는 기술일 수 있으나, 반드시 서로 배타적인 것은 아니다. 이 두 기술의 조합을 이용하는 것도 생각할 수 있다. 자동 콘텐트 인신(automatic content recognition; ACR)은 이 기술들 중 어느 하나를 별도로 칭하거나 또는 이 두 기술의 조합을 칭하기 위해 사용될 수 있다.
수신기가 방송 스트림으로부터의 비압축된 오디오 및 비디오에만 접근할 수 있는 환경을 "ACR 환경"이라고 부른다.
WM와 FP의 경우 모두, 수신기들은 트리거를 포함하는 양방향 서비스 콘텐트를 얻기 위한출발점으로서 URL을 사용할 수 있다.
WM와 FP의 경우 모두, 인터넷을 통해 전달된 트리거들의 활성화 타임스탬프들과 같이 해당 채널에 대해 시간임계적(time critical) 이벤트들의 방송측 클럭(broadcast side clock)에 대한 타임스탬프의 형태일 수 있다.
방송국들은, 일반적으로 안테나로부터 TV 신호들을 받는 수신기들을 위해 방송 스트림으로의 양방향 서비스의 직접 전달을 지원할 수 있고, 비압축된 오디오 및 비디오를 받는 수신기들을 위해 앞에서 설명한 바와 같이 인터넷을 통한 양방향 서비스의 전달을 지원하되 인터넷 연결을 가질 수 있다고 가정한다. 그러나 방송국들은 이 두 가지 전달 메커님즘들 중 어느 하나만 지원할 수 있다.
워터마크가 코드 값만을 제공하는 경우 워터마킹 기법을 위한 대표적인 아키텍처는 도 22 및 도 23의 두 아키텍처의 조합과 같이 보인다. 도 22와 같이 워터마크 삽입부가 존재하게 되나, 이 삽입부는 수신기들이 필요로 하는 정보가 아닌 코드를 삽입한다. 또한 도 23의 FP 서버와 동일한 역할을 수행하는 WM 서버가 존재한다. 수신기들은 이 서버에 시그니처가 아닌 코드를 보내고, 이들이 필요로 하는 정보를 받게 된다.
양방향 서비스 접근에 대해 설명한다.
양방향 서비스 접근에 대한 설명은 직접 실행 모델, ACR 서버에 독립적인 활성화들을 가진 TDO 모델, ACR 서버로부터 수신된 활성화들을 가진 TDO 모델에 대한 설명을 포함한다. 모델들을 나타내지 않지만, 모델들은 설명에 한정되지 않고 설계자의 의도에 따라 변경될 수 있다.
방송국 선택과 ACR 시스템의 특성에 따라 ACR 환경에 있는 수신기가 양방향 서비스들에 접근할수 있는 방법은 여러가지가 있다. 양방향 서비스 모델은 직접 실행 모델 또는 TDO 모델일 수 있고, TDO 모델의 경우 활성화와 트리거들은 ACR 서버에 독립적으로 또는 ACR 서버에 의해 전달될 수 있다.
직접 실행 모델에 대해 설명한다.
직접 실행 모델을 가진 양방향 서비스를 담고 있는 가상 채널을 위한 ACR 과정은 이 채널을 보고 있는 수신기들에 media_time ("m=") 항과 content_id ("c=") 항을 포함하는 시간 베이스 트리거들에 상응하는 것을 제공할 수 있다. 이 트리거들은 직접 실행 모델을 가진 양방향 서비스를 위한 트리거인 것으로 확인될 수 있다.
먼저 수신기가 새로운 locator_part를 가진 이와 같은 트리거를 수신하면, 그 브라우저에 트리거의 locator_part가 가리키는 선언적 객체(DO)를 로딩할 것으로 생각할 수 있다. 일반적으로 DO는 미리 설치되어 있거나 미리 다운로드 되어 캐시에 저장하게 된다. 그렇지 않으면 수신기가 HTTP GET 요청을 이용하여 DO를 다운로드하는 것으로 생각할 수 있다.
그 후, DO는 적절한 백엔드 서버와 연락하여 백엔드 서버가 지시하는 양방향 서비스를 제공할 수 있다.
수신기는 ACR 서버로부터 새로운 locator_part를 가지고 및/또는 TDO 모델을 가진 양방향 서비스를 위한 트리거로 확인되는 트리거를 얻을 때까지(이 중 어느 한 경우는 일반적으로 채널의 변경을 지시한다) 획들된 초기 트리거와 이어지는 트리거들을 DO가 이용할 수 있게 하는 것으로 생각할 수 있다.
이하, ACR 서버에 독립적인 활성화들을 가진 TDO 모델에 대해 설명한다.
An ACR 과정 for a 가상 채널 that can contain an 양방향 서비스 which has the TDO 모델을 가진 양방향 서비스를 담을 수 있고 ACR 서버와 독립적으로 이벤트 활성화들을 제공하는 가상 채널을 위한 ACR 과정은 media_time ("m=") 항을 포함할 수 있는 시간 베이스 트리거들에 상응하는 것을 이 채널을 보고 있는 수신기들에 제공할 수 있다. 이 트리거들은 TDO 모델을 가진 양방향 서비스를 위한 트리거인 것으로 확인될 수 있다.
먼저 수신기가 새로운 locator_part를 가진 이와 같은 트리거를 수신하면, 해당 트리거의 locator_part가 가리킬 수 있는 TPT 서버에서 현재의 TDO 파라미터 테이블(TPT)를 검색하고, 이 트리거 및 이어지는 트리거들 내의 미디어 시간을 이용하여 ACR 과정에 의해 식별될 수 있는 오디오 또는 비디오 프레임들에 대해 이벤트 활성화들을 위한 기준 시간 베이스를 설정하는 것으로 생각할 수 있다.
AMT (활성화 메시지 테이블)이 TPT와 함께 전달되는 경우, 수신기는 트리거들 내의 미디어 시간에 의해 설정된 시간 베이스를 기준으로 정확한 시간에 이벤트들을 활성화시키기 위해 이 테이블 내의 각각의 활성화 엘리먼트들을 사용하는 것으로 생각할 수 있다. (이 이벤트들은 TDODML 로딩 및 실행, TDO가 동기화될 특정 동작을 수행하도록 하기, TDO 중지시키기 등을 포함할 수 있다.)
TPT에 LiveTrigger 엘리먼트가 포함된 경우, 수신기는 LiveTrigger 엘리먼트에서 시그널링된 폴링 방법을 이용하여 LiveTrigger 엘리먼트 내의 URL에 의해 식별된 라이브 트리거 서버에서 활성화 트리거들을 검색하고, 이 활성화 트리거들을 이용하여 이 트리거들 내의 미디어 시간 항들에 의해 설정된 시간 베이스를 기준으로 정확한 시간에 이벤트들을 활성화시킬 수 있다.
AMT와 라이브 트리거 서버 모두 동일한 서비스를 위해 사용될 수 있는데, 전자는 정적 활성화들을 제공하고, 후자는 동적 활성화들을 제공한다. 이와 달리, 세그먼트의 모든 활성화들이 정적 활성화인 경우에는 AMT만 사용될 수 있고, 라이브 트리거 서버만 이용하여 정적 활성화 및 동적 활성화를 모두 전달할 수도 있다.
ACR 서버로부터 수신된 활성화들을 가진 TDO 모델에 대해 설명한다.
TDO 양방향 서비스 모델을 위한 활성화 트리거들이 ACR 환경에서 별도의 트리거 서버 없이 어떻게 전달될 수 있는 지를 기술한다.
핑거프린팅 ACR 시스템은 ACR 서버를 포함할 수 있다. 수신기들은 ACR 서버에 프레임 시그니처를 보낼 수 있고, ACR 서버는 해당 시그니처가 나타내는 프레임을 식별하여 다시 수신기에서 필요로 하는 정보를 보낼 수 있다. 워터마크가 수신기에서 필요로 하는 정보를 얻기 위해 ACR 서버에 전달될 수 있는 코드로만 구성된 경우, 워터마킹 ACR 시스템은 ACR 서버를 포함할 수 있다. 워터마크 자체가 수신기에서 필요로 하는 정보를 포함하는 경우, 워터마킹 ACR 시스템은 ACR 서버를 포함하지 않을 수 있다. ACR 서버를 포함하는 ACR 시스템에서는, 서버와 수신기 사이의 통신에 서로 다른 두 가지 모델, 즉 요청/응답 모델과 이벤트 주도형 모델이 이용될 수 있다.
방송국에서 TDO 양방향 모델(TDO interaction model)을 지원하고 있는 것으로 가정한다.
요청/응답 모델을 이용하는 ACR 서버, 이벤트 주도형 모델을 이용하는 ACR 서버, 정보를 직접 삽입하는 워터마킹 ACR 시스템과 같은 세 경우를 상정해 볼 수 있다.
ACR 서버가 있는 경우, ACR 방식은 핑거프린팅일 수 있으며, 이 경우 수신기들은 일종의 오디오 또는 비디오 프레임들의 시그니처(또는 핑거프린트)를 산출하여 식별을 위해 이들을 ACR 서버에 제출한다. 또는 ACR 방식이 워터마킹일 수 있으며, 이 경우 수신기들은 오디오 또는 비디오 프레임들에서 워터마크 형태의 코드들을 추출하여 이 코드들을 식별을 ACR 서버에 제출한다.
편의를 위해 핑거프린팅 시그니처의 용어를 설명한다. 다만, 시스템은 워터마킹 코드의 경우와 동일한 방식으로 동작하고, 본 발명은 핑거프린팅에 한정되지 않는다.
도 24는 요청/응답 ACR 경우의 정적 활성화의 일 실시예를 도시한 도면이다.
ACR 서버가 요청/응답 모델을 사용하는 경우에 대해 설명한다.
요청/응답 ACR 모델에서, 수신기는 주기적으로 (예를 들면, 5초마다(이는 예시에 불과하고 설계자에 의해 변경될 수 있다)) 콘텐츠의 시그니처를 생성하고, 시그니처를 포함하는 요청을 ACR 서버에 보내는 것으로 생각할 수 있다. ACR 서버는 수신기로부터 요청을 받으면 응답을 회답할 수 있다. 요청/응답 인스턴스들 사이에는 통신 세션이 개방 상태로 유지되지 않는다. 이 모델에서는, ACR 서버가 수신기로 메시지를 개시하는 것이 불가능할 수 있다.
이 요청/응답 모델을 이용하고 수신기에 활성화 트리거들을 전달하는 ACR 서버의 경우, ACR 서버로부터의 각 응답은 널(Null), 시간 베이스 트리거 또는 활성화 트리거 중의 하나일 수 있다.
널 응답은 시그니처가 인식되지 않음을 지시하거나, 또는 (ACR 인제스트 모듈(ACR Ingest Module)이 프레임에 대한 시그니처를 양방향 서비스가 없는 프로그램 세그먼트에 포함시키는 경우에) 시그니처는 연관된 양방향 서비스가 없는 세그먼트에 속하는 프레임을 나타냄을 지시할 수 있다. ACR 인제스트 모듈에 대해서는 후술한다.
시간 베이스 트리거 응답은 클라이언트의 다음 요청이 있기 전에 이벤트 활성화가 발생하도록 스케줄링되어 있지 않음을 지시할 수 있다. 클라이언트는 시간 베이스 트리거들을 이용하여 미디어 시간 클럭(media-time clock)을 유지하는 것으로 생각할 수 있다.
활성화 트리거 응답은 활성화가 곧 발생할 예정임을 지시할 수 있으며, 활성화의 시간은 트리거 내 "t=" 항에 의해 지시된다.
수신기는 새로운 locator_part를 가진 트리거를 받을 때마다, 이전의 TPT와 함께 전달된 URLList를 이용하여 새로운 TPT가 검색되지 않았으면 이를 즉시 다운로드 하는 것으로 생각할 수 있다.
수신기는 활성화 트리거를 받을 때마다, 미디어 시간 클럭에 대하여 해당 트리거 내 "t=" 항에 의해 지시된 시간에 해당 이벤트를 활성화시키는 것으로 생각할 수 있다.
도 24는 정적 활성화에 대해 (ACR 시스템이 예정보다 충분히 일찍 동적 활성화에 대해 알고 있는 경우 동적 활성화에 대해) 이 방식이 어떻게 작용하는지를 보여준다.
도 24에서, 수신기는 ACR 서버에서 미디어 시간 MT1, MT2 및 MT3을 가지는 것으로 판단한 프레임들에 대한 시그니처를 전달할 수 있다. 미디어 시간 MT1을 가진 프레임의 경우, 수신기는 시간 베이스 트리거를 포함하는 응답을 받는다. 미디어 시간 MT2를 가진 프레임의 경우, 정적 활성화가 미디어 시간 Mta에 예정되어, 수신기는 "t=MTa" 항을 가진 활성화 트리거를 포함하는 응답을 받는다. 미디어 시간 MT3을 가진 프레임의 경우, 수신기는 시간 베이스 트리거를 포함하는 응답을 받는다.
수신기가 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하는 경우가 발생할 수 있다. 그러나 이들 각각에 대한 미디어 시간들은 동일하므로, 수신기는 이들이 중복된 것으로 파악하고 이들 중 하나만 적용할 수 있다.
도 25는 요청/응답 ACR 경우의 정적 활성화의 일 실시예를 도시한 도면이다.
ACR 서버가 요청/응답 모델을 사용하는 경우에 대해 설명한다.
도 25에서, 수신기는 로컬 클럭(local clock) 시간 LC1, LC2, LC3 등에서 보여진 프레임들에 대한 시그니처들을 전달할 수 있다. 로컬 클럭 시간 LC1에 보여진 프레임에 대한 media_time은 ACR 서버에 의해 MT1으로 판단될 수 있고, 수신기는 media_time 또는 event_time이 없는 트리거를 포함하는 응답을 수신한다. 로컬 클럭 시간 LC2에 보여진 프레임에 대한 media_time은 ACR 서버에 의해 MT2로 판단될 수 있고, ACR 서버는 미디어 시간 Mta에 정적 활성화가 예정되어 있음을 알고 있으므로, ACR 서버는 이 활성화를 위한 활성화 시간 Mta가 MT2 이후 <옵셋> 시간임을 의미하는 "d=<offset>" 항을 가진 활성화 트리거를 포함하는 응답을 전달한다. 그러면 수신기는 <옵셋>을 시간 LC2에 추가하여 해당 이벤트를 활성화시켜야 하는 로컬 시간인 Lca를 얻는다.
도 26은 요청/응답 ACR 경우의 동적 활성화의 일 실시예를 도시한 도면이다.
요청/응답 ACR 경우에서 동적 활성화가 일어나는 경우에 대해 설명한다.
이하, 요청/응답 ACR 경우에서, 동적 활성화가 일어나는 경우를 설명한다.
미리 수신기에 트리거를 보내기에는 시간이 늦어질 때까자 ACR 시스템에서 이벤트 활성화에 대해 알지못하는 상황에서의 동적 활성화의 경우에는, ACR 서버가 다음 요청이 있을 때까지 기다렸다가 활성화 트리거를 보내야 한다. 도 26에서 이러한 경우를 도시하고 있다. 이로 인해 하나의 요청 구간만큼 동적 활성화가 지연될 수 있다.
도 26에서, 수신기는 ACR 서버에서 미디어 시간 MT1, MT2 및 MT3을 가지는 것으로 판단한 프레임들에 대한 시그니처를 전달할 수 있다. 미디어 시간 MT1 and MT2를 가진 프레임들의 경우, 수신기는 시간 베이스 트리거를 포함하는 응답을 받는다. 활성화 시간 Mta를 가진 동적 활성화가 미디어 시간 MTa에서 또는 바로 직전에 등장하는 경우, ACR 서버는 미디어 시간 MT3을 가진 프레임에 대해 발생하는 수신기로부터의 다음 요청이 있을 때까지 수신기에 이를 통지할 수 없다. 이때 ACR 서버 응답은 활성화 시간 MTa (약간 과거인 시간)을 가진 활성화 트리거를 포함한다. 이와 같은 상황에서, 수신기는 이 응답이 도달하면 바로 해당 활성화 트리거를 적용하는 것으로 생각할 수 있다.
여기에서, 수신기는 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하는 것이 가능하다. 그러나 이들 각각의 미디어 시간은 동일하므로, 수신기는 이들이 중복된 것으로 파악하고 이들 중 하나만 적용할 수 있다.
도 27는 요청/응답 ACR 경우의 동적 활성화의 일 실시예를 도시한 도면이다.
요청/응답 ACR 경우에서 동적 활성화가 일어나는 경우에 대해 설명한다.
도 27에서, 수신기 로컬 클럭 시간 LC1, LC2, LC3 등에서 보여진 프레임들에 대한 시그니처들을 전달할 수 있다. 로컬 클럭 시간 LC1에 보여진 프레임에 대한 media_time은 ACR 서버에 의해 MT1으로 판단될 수 있고, 수신기는 media_time 또는 event_time이 없는 트리거를 포함하는 응답을 수신한다. 로컬 클럭 시간 LC2에 보여진 프레임에 대한 media_time은 ACR 서버에 의해 MT2로 판단될 수 있고, ACR 서버는 미디어 시간 Mta에 동적 활성화가 등장할 예정임을 알지 못하여, 수신기는 media_time 또는 event_time이 없는 트리거를 포함하는 응답을 수신한다. 동적 활성화가 미디어 시간 Mta에 등장하면, ACR 서버는 로컬 시간 LC3에 발생하는 수신기로부터의 다음 요청이 있을 때가지 수신기에 이에 대해 통지할 수 없다. 이 때, ACR 서버 응답은 음의 <옵셋> 값을 가진 활성화 트리거 또는 "지금 시행" 활성화 트리거를 포함할 수 있다.
이벤트 주도형 모델을 사용하는 ACR 서버에 대해 설명한다.
이벤트 주도형 ACR 모델에서, 수신기는 ACR 서버에 대한 영구적인 접속을 개시하고, 주기적으로 (예를 들면, 5초마다) 콘텐츠의 시그니처를 생성하고, 시그니처를 접속을 통해 제출하는 것으로 생각할 수 있다. ACR 서버는 각 시그니처에 반응하지 않는다. 그것은 새로운 세그먼트가 발견되거나 이벤트 활성화가 수신기에 전해질 필요가 있을 때 수신기에 메시지를 보낼 수 있다. 해당 모델에서, ACR 서버는 어느 때든 클라이언트에 대한 메시지를 개시할 수 있다.
해당 이벤트 주도형 모델을 사용하고 활성화들을 수신기에 전달하는 ACR 서버에 대해, 다음의 규칙은 ACR 서버에로부터의 메시지를 신청할 수 있다.
첫째로, ACR 서버는 새로운 세그먼트에 대응하는 수신기로부터 시그니처를 수신하면, 단지 수신기가 관련된 TPT를 획득할 수 있게 하기 위해, 즉시 시간 베이스 트리거를 수신기에 보낼 수 있다.
둘째로, 이벤트가 활성화될 예정일 때마다, ACR 서버는 활성화 트리거를 수신기에 보낼 수 있다. 가능하다면, 수신기가 적용해야 하는 시기보다 조금 앞서서 활성화 트리거를 보낼 수 있다(이는 요청/응답 모델에서의 동작과 유사하다). ACR 서버는 활성화를 너무 늦게 알게 되어 활성화 트리거를 사전에 일찍 보낼 수 없어도(이는 동적 이벤트 활성화의 경우 일어날 수 있다), 활성화 트리거를 가능한 빨리 보낼 수 있다. 후자의 경우에, 메시지 지연으로 인해 클라이언트는 활성화 시기보다 조금 후에 메시지를 받을 수 있고, 이 경우 수신기는 메시지를 받은 즉시 이벤트를 활성화할 것으로 생각할 수 있다.
수신기는 새로운 locator_part를 갖는 트리거를 받을 때마다, 이전의 TPT와 함께 전달되는 URLList를 이용하여 이미 검색하지 않는 한, 새로운 TPT를 즉시 다운로드 할 것으로 생각할 수 있다.
정보를 직접 삽입하는 워터마킹 ACR 시스템에 대해 설명한다. 워터마킹 ACR 시스템을 나타내지 않았지만, 워터마킹 ACR 시스템은 다음 설명에 한정되지 않고 설계자에 의해 변경될 수 있다.
수신기들이 필요로 하는 정보를 직접 삽입하는 워터마킹 시스템의 경우, 프레임과 연관된 워터마크는, 이 프레임에 대해 요청/응답 ACR 서버가 리턴하는 것에 대해 앞서 설명한 것과 동일한 규칙을 다음과 같이 따를 수 있다. 요청/응답 ACR 서버는 널, 시간 베이스 트리거, 활성화 트리거 중 하나를 리턴할 수 있다.
널 응답은 시그니처가 인식되지 않음을 지시하거나, 또는 (ACR 인제스트 모듈이 프레임에 대한 시그니처를 양방향 서비스가 없는 프로그램 세그먼트에 포함시키는 경우) 시그니처는 연관된 양방향 서비스가 없는 세그먼트에 속하는 프레임을 나타냄을 지시할 수 있다.
시간 베이스 트리거 응답은 클라이언트의 다음 요청이 있기 전에 이벤트 활성화가 발생하도록 스케줄링되어 있지 않음을 지시할 수 있다. 클라이언트는 시간 베이스 트리거들을 이용하여 미디어 시간 클럭을 유지하는 것으로 생각할 수 있다.
활성화 트리거 응답은 활성화가 곧 발생할 예정임을 지시할 수 있으며, 활성화의 시간은 트리거 내 "t=" 항에 의해 지시된다.
ACR 서버가 필요없도록 수신기들이 필요로 하는 정보를 워터마크에 직접 포함시켜 전달하는 워터마킹 ACR 시스템의 경우, 인제스트 모듈은, 각 프레임과 연과시킬 트리거를 결정하고 이 트리거를 데이터베이스 내 해당 프레임과 연관시키지 않고 해당 프레임을 위한 워터마크에 포함시키는 요청/응답 서버 모델에 대해 앞서 설명한 것과 동일한 규칙을 따를 수 있다. 인제스트 모듈과 데이터베이스에 대해서는 후술한다.
독립형 NRT 서비스의 지원에 대해 설명한다. 이를 나타내지 않았지만, 본 발명은 다음 설명에 한정되지 않고 설계자에 의해 변경될 수 있다.
ACR 환경에 있는 수신기가 독립형 NRT 서비스들을 받기 위해서, 방송국은 NRT 서비스에의 인터넷 접속을 지원해야 하고, 수신기는 이 서비스들에 대한 SMT 와 NRT-IT 인스턴스들을 얻어야 할 수 있다.
인터넷을 통해 PSIP 테이블 및 NRT 테이블을 획득하는 질의 프로토콜에 대해 설명한다.
방송국은 특정 방송 스트림에 대해 이 프로토콜을 지원하며, 이 때 이 방송 스트림에 대한 방송국의 시그널링 서버의 URL을 알고 있는 수신기는 다음 단계들을 수행한다.
첫째, 수신기는 지정된 미래 시간 구간(예: 다음 시간) 동안 해당 방송 스트림을 위한 테이블 중 "기본 NRT 집합"에 대해 질의를 발생시킬 수 있다.
둘째, 위 단계에서 각 독립형 NRT 가상 채널들에 대한 SMT와 ILT, 그리고 지정된 시간 구간을 포함하는 NRT-IT 및 TFT 인스턴스들을 생성하게 된다.
수신기가 방송 스트림에 대한 시그널링 서버의 URL을 발견할 수 있는 한 가지 방법은 이 방송 스트림 내 양방향 서비스 세그먼트의 제공자가 TPT와 함께 전달된 URLList 엘리먼트 내에서 시그널링 서버 URL을 제공하기로 선택할 수 있다.
수신기가 방송 스트림에 대한 시그널링 서버의 URL을 발견할 수 있는 또 다른 방법은 사전 설정에 의한 것일 수 있다. DTV 수신기 제조자가 특정 방송 영역에 이르는 ACR 서버를 어떻게 찾을 지를 알도록 DTV 수신기를 미리 설정하는 것과 동일한 방식으로, DTV 수신기 제조자가 특정 방송 영역에 이르는 "NRT 발견 서버"를 어떻게 찾을 지를 알도록 DTV 수신기를 미리 설정할 수 있다. 이와 같은 NRT 발견 서버는 각 방송 스트림에 대한 시그널링 서버 URL과 함께 독립형 NRT 서비스들을 포함하는 방송 스트림 목록을 수신기에 제공할 수 있다.
도 28는 ACR 서버 활성화를 위한 아키텍처의 일 실시예를 도시한 도면이다.
어떤 ACR 시스템들은 ACR 서버를 포함하고, 어떤 ACR 시스템들은 포함하지 않는다. 핑거프린팅 ACR 시스템에서는, 수신기들은 프레임 시그니처를 산출하여 ACR 서버으로 보낼 수 있고, ACR 서버는 수신기에서 필요로 하는 정보를 보낸다. 따라서 핑거프린팅 ACR 시스템은 ACR 서버를 포함한다. 워터마킹 ACR 시스템에서는, 워터마크에 프레임들을 고유하게 식별하는 코드만 포함되거나, 도는 수신기들이 필요로 하는 전체 정보가 포함될 수 있다. 워터마크가 코드만을 포함할 경우에는, 수신기들이 코드를 추출하여 이들을 ACR 서버에 보낼 수 있고, ACR 서버는 수신기에서 필요로 하는 정보를 보낸다. 워터마크가 전체 정보를 포함하는 경우에는, 수신기들이 자신들이 필요로 하는 정보를 워터마크에서 직접 추출할 수 있어, ACR 서버가 필요하지 않다.
ACR 서버를 포함하는 ACR 시스템에서는, ACR 서버와 수신기 사이의 통신을 위해 두 가지 서로다른 모델, 즉 요청/응답 모델과 이벤트 주도형 모델을 공통으로 사용할 수 있다.
요청/응답 ACR 서버 모델에서, 수신기는 주기적으로(예들 들어, 5초마다) 콘텐트의 시그니처를 산출하거나 콘텐트에서 코드를 추출하여 이 시그니처나 코드가 포함된 요청을 ACR 서버로 보내는 것으로 생각할 수 있다. ACR 서버는 수신기로부터 요청을 수신하면, 응답을 리턴할 수 있다. 요청/응답 인스턴스들 사이에는 통신 세션이 열린 상태로 유지되지 않는다. 이 모델에서는, ACR 서버가 수신기로 메시지를 개시하는 것이 불가능할 수 있다.
처리 중인 채널의 방송국이 TDO 양방향 모델을 지원하는 것으로 가정한다.
두 가지 일반적인 유형의 이벤트 활성화, 즉 세그먼트의 방송이 시작되지 전에 활성화 시간이 알려지는 정적 활성화와 세그먼트의 방송 중에 활성화 시간이 동적으로 결정되는 동적 활성화가 있을 수 있다. 미리 기록된 세그먼트에서는, 모든 이벤트 활성화가 정적일 수 있다. 라이브 쇼를 방송하는 세그먼트에서는, 이벤트 활성화들 중 일부 또는 전체가 동적일 수 있다. 정적 활성화들은 활성화 트리거의 형태로 수신기에 전달될 수 있지만, 일반적으로 활성화 메시지 테이블(Activation Messages Table, AMT)에 나열된다. 동적 활성화들은 이들의 타이밍이 AMT의 발생 시점에 알려지지 않으므로, 활성화 트리거의 형태로 전달될 수 있다.
도 28는 ACR 서버를 사용하는 ACR 시스템을 지원하는 아키텍처를 도시하고 있다. 이는 논리 구성도로서, 실행 아키텍처가 아니다. 예를 들어, ACR 인제스트 모듈은 방송 소스와 동일한 위치에 있거나 별도의 위치에 있을 수 있다.
ACR 서버를 사용하는 ACR 시스템을 지원하는 아키텍처에서, 아키텍처는 방송 소스(28010), ACR 인제스트 모듈(28020), MVPD(28030), STB(28040), 수신기(28050), ACR 클라이언트(28060), ACR 설정 서버(28070), ACR 서버(28080) 및 데이터베이스(28090)로 이루어질 수 있다.
방송 소스(28010)는 A/V 스트림 및 관련된 양방향 서비스가 송출되는 지점, 예를 들면, 네트워크 분배점 또는 텔레비전 방송국일 수 있다.
ACR 인제스트 모듈(28020)은 핑거프린팅 ACR 시스템의 경우 프레임들의 시그니처(핑거프린트)를 산출거나 코드를 바탕으로 하는 워터마킹 ACR 시스템의 경우 코드로 이루어진 워터마크를 프레임에 삽입할 수 있다. 이 모듈은 다른 메타데이터와 함께 시그니처 또는 코드에 연관된 각 프레임의 media_time을 데이터베이스(28090)에 저장할 수 있다. ACR 인제스트 모듈(28020)은 하나의 방송 스트림, 전체 방송 스트림, 또는 다수의 방송 스트림 또는 이들의 조합에서 단일 채널을 다룰 수 있다. 이를 위해, ACR 인제스트 모듈(28020)은 양방향 서비스를 포함는 프로그램 세그먼트들을 위한 프레임들을 처리하는 것으로 가정한다. 그러나 모든 프레임들이 처리되지만 양방향 서비스를 가진 세그먼트의 일부아 아닌 것들은 이들이 양방향 서비스를 가진 세그먼트의 일부가 아님을 지시하는 지시자가 데이터베이스(28090) 엔트리에 있는 ACR 시스템도 가능하다.
MVPD(28030)는 일반적으로 케이블 사업자, 위성 사업자 또는 IPTV 사업자일 수 있다. MVPD(28030)는 워터마킹 ACR 시스템의 경우 ACR 인제스트 모듈(28020)에 의해 삽입된 워터마크와 함께 방송 스트림을 어떤 방식으로 방송 소스로부터 수신할 수 있다. 이와 같은 시스템은 종종 오디오 및 비디오 트랙 이외의 다른 프로그램 엘리먼트들을 모두 제외한 스트림을 고객 댁내의 STB(28040)에 보낸다.
STB(28040)는 일반적으로 오디오 및 비디오를 디코딩(압축 해제)하여, 시청자들에게 보여주기 위한 텔레비전 수상기에 보낼 수 있다. 양방향 서비스 트리거를 포함하는 DTV 클로즈드 캡션 서비스 #6는 텔레비전 수상기가 이용할 수 없다고 가정한다.
수신기(28050)는 ACR 클라이언트(28060)를 포함할 수 있다. ACR 클라이언트(28060)는 수신기(28050) 외부에 있을 수도 있다. 수신기(28050)의 구조에 대해서는 후술한다.
수신기(28050) 내의 ACR 클라이언트(28060)는 해당 용도의 API를 이용하여 ACR 서버(28080)로부터 활성화 트리거들을 받아 메인 수신기 코드로 이들을 보낼 수 있다. 일반적으로 ACR 클라이언트(28060)은 수신기(28050) 내에 구성되지만, 다른 구성도 가능하다.
ACR 설정 서버(28070)는 ACR 클라이언트(28060)가 적절한 ACR 서버(28080)의 위치를 결정하는 방식을 제공할 수 있다. 이 발견 과정은 다른 방식으로 획득할 수도 있다.
ACR 서버(28080)는 수신기드로부터 시그니처 또는 코드를 받고, 적절한 시점에 활성화 트리거들을 리턴할 수 있다.
데이터베이스(28090)는 ACR 서버(28080)의 사용을 위해 오디오 또는 비디오 프레임(또는 이들 모두)에 대한 정보가 저장되는 일종의 데이터 저장소로서 엄밀히 말해 데이터베이스가 아닐 수 있다.
워터마크 내 정보의 직접 전달을 이용하는 ACR 시스템의 아키텍처는 데이터베이스와 ACR 서버를 가지지 않을 수 있다. ACR 인제스트 모듈은 정보를 프레임들의 식별자 및 이들과 연관된 정보를 포함하는 데이터베이스 기록들에 삽입하는 대신 워터마크의 형태로 방송 스트림 내 프레임들에 직접 삽입할 수 있다. 그 후 수신기들은 이 정보를 ACR 서버로부터 얻지 않고 방송 내 프레임들로부터 추출할 수 있다.
이하, 요청/응답 ACR 서버들을 통한 활성화 트리거들의 전달에 대하여 단계별로 설명한다.
이 ACR 서버의 거동을 구현하는 효과적인 방법은 이하에서 설명하는 과정을 따르는 것인데, 이 과정의 동작의 수는 위의 아키텍처 다이어그램인 도 28 내의 숫자들에 대응한다.
1) 양방향 서비스 세그먼트들과 AMT들 또는 각 세그먼트에 상당한 것들에 대한 방송 스케줄은 세그먼트들이 방송되기 전에 미리 ACR 인제스트 모듈에 전달될 수 있다. 방송 스케줄은 세그먼트 ID, 연관된 양방향 서비스를 포함할 수 있는 각 세그먼트의 GPS 시작 시점 및 GPS 종료 시점을 포함할 수 있다. 방송 스케줄에 마지막 순간의 변화가 있을 경우, ACR 인제스트 모듈에 이 변화들이 즉시 통지될 수 있다. 방송 스케줄은 각 세그먼트에 대한 TPT의 버전 넘버도 포함할 수 있고, TPT 버전의 스케줄되지 않은 변경은 실시간으로 ACR 인제스트 모듈에 통지되어, 필요시"version" ("v=") 항들을 트리거에 삽입할 수 있다. 인제스트 모듈은, 각 세그먼트의 시작 시 특정 구간 동안(많은 수신기들이 새로운 TPT들을 동시에 요청할 가능성이 있을 때)와 같이 적절한 시간에 "spread" ("s=") 항들을 트리거에 삽입하도록 구성될 수도 있다.
2) 동적 활성화가 존재하는 경우, 동적 활성화의 소스들로부터 ACR 인제스트 모듈로 링크들이 설정될 수 있다.
3) 방송 스트림은 ACR 인제스트 모듈로 전송될 수 있다.
4) ACR 인제스트 모듈은 프레임들로부터 시그니처들을 추출하거나(핑거프린트 ACR 시스템의 경우) 연관된 양방향 서비스를 가지는 세그먼트들에 포함된 모든 프레임들에 대하여 코드들을 프레임에 삽입(워터마크 ACR 시스템의 경우)할 수 있다.(ACR 인제스트 모듈은 GPS 클럭과 방송 스케줄 내 세그먼트들의 시작 시간 및 종료 시간을 이용하여 프레임이 그와 같은 세그먼트에 있는지 판단할 수 있다.) 그와 같은 각 프레임에 대하여 ACR 인제스트 모듈은, 트리거와 시그니처 또는 해당 프레임과 연관된 코드를 포함할 수 있는 데이터베이스에 기록을 삽입할 수 있다. 트리거가 삽입받는 것에 대한 규칙은 과정상 이러한 동작 리스트의 끝에 기술된다.
5) 방송 스트림은 MVPD에 계속 이어질 수 있다.
6) MVPD 가입자의 위치에 있는 STB에 방송 스트림을 전송할 수 있다.(일반적으로 양방향 콘텐트는 먼저 제외시킨다.)
7) STB는 A/V를 디코딩하여 비압축된 A/V를 DTV 수신기에 보낼 수 있다.
8) 먼저 수신기가 ON되면, 수신기는 자신의 위치를 ACR 설정 서버에 보낼 수 있다.( ACR 설정 서버의 URL은 이 수신기 내에 구성될 수 있다.)
9) The ACR 설정 서버는 수신기가 사용할 ACR 서버의 URL을 다시 보낼 수 있다.
10) 수신기 내 ACR 클라이언트는 핑거프린트 시그니처 또는 워터마크 코드들의 추출하여이들을 ACR 서버로 보낼 수 있다.
11) 시그니처 또는 코드를 수신한 ACR 서버는 데이터베이스 내에서 시그니처 또는 코드의 매칭을 시도할 수 있다.
12) 시그니처 또는 코드가 데이터베이스 내의 어떤 시그니처 또는 코드와도 매칭되지 않으면, ACR 서버 "no match" 지시자를 받을 수 있다. 시그니처 또는 코드가 데이터베이스 내의 시그니처 또는 코드와 매칭되면, ACR 서버는 매칭되는 시그니처 또는 코드를 가진 프레이에 대하 기록을 받을 수 있다. 후자의 경우, 데이테베이스 내의 기록은 시간 베이스 트리거를 포함할 수 있고, 및/또는 ACR 인제스트 모듈에 의해 프레임의 기록에 무엇이 삽입되었는 지에 따라 하나 이상의 활성화 트리거를 포함할 수 있다.
13) ACR 서버가 데이터베이스로부터 "no match" 지시자를 받으면, ACR 클라이언트에 널 응답을 리턴할 수 있다. 그렇지 않은 경우 ACR 서버는 얻은 트리거 또는 트리거들을 ACR 클라이언트에 리턴할 수 있다.
아래와 같은 규칙들을 이용하여, ACR 인제스트 모듈이 어떤 트리거 또는 트리거들을 데이터베이스 내 각 프레임 기록에 삽입하는 지를 판단할 수 있다.
도 29 는 EndTime이 없는 경우 (a)와 경우 (b)에서의 활성화 트리거들의 일 실시예를 도시한 도면이다.
수신기들 내의 개별 ACR 클라이언트에 의해 사용된 요청 구간의 길이 상에 어떤 상한(upper bound) L1이 존재한다고 가정할 수 있다.(ACR 클라이언트들이 실제로 이 상한 내에서 동작하는 한 이 경계를 알고 있는 지는 중요하지 않다.) L2를 프레임이 수시기에 도달한 시점으로부터 기산하여 일반적인 ACR 클라이언트가 시그니처를 산출하거나 이 프레임과 연관된 워터마크를 추출하는 데 걸리는 시간의 길이라고 한다. 메시지가 ACR 클라이언트로부터 ACR 서버로 갔다가 돌아오는 데 걸리는 일반적인 왕복이동시간을 L3이라고 하자. M = L1 + L2 + L3이라고 하자. (M의 약간 더 큰 값이 사용될 수도 있다. 약간 더 큰 값의 장점은 활성화 트리거들에 반응하는데 약간의 여분의 시간을 얻는다는 것이다. 단점은, 수신기들이 동일한 이벤트 활성화에 대해 다수의 활성화 트리거들을 받을 가능성이 약간 더 높다는 것이다. 수신기들은 아래에 설명된 바와 같이 이들이 중복됨을 감지하여 활성화를 한 번만 적용할 수 있으므로, 이 단점은 큰 문제가 되지 않는다.)
ACR 인제스트 모듈은 다음 세 가지 조건들 중 적어도 하나가 성립되지 않으면 시간 베이스 트리거만 프레임과 연관된 기록에 삽입할 수 있다.
(a) 활성화 엘리먼트는, 프레임의 media_time이 활성화 엘리먼트의 startTime 전 시간 길이 M에서 시작하여 활성화 엘리먼트의 endTime에서 끝나는 시간 구간에 있도록 AMT에 존재한다. (활성화가 endTime을 가지지 않으면, endTime은 startTime과 동일한 것으로 간주된다.)
(b) 트리거의 활성화 시간("t=<event_time>") 직전의 시간 길이 M의 시간 구간 이전에 동적 활성화 트리거가 인제스트 모듈에 의해 수신되었고, 해당 프레임은 이 구간 내에 존재한다.
(c) 트리거의 활성화 시간 직전의 시간 길이 M의 구간의 시작보다 늦게 동적 활성화 트리거가 인제스트 모듈에 의해 수신되었고, 프레임의 media_time은 트리거의 수신 바로 뒤의 시간 길이 L1의 구간에 존재한다.
이 조건들 (a), (b) 및 (c) 중 어느 것이라도 성립하면, 활성화 트리거는, 활성화될 이벤트를 식별하는 "e=" 항과 AMT 내 활성화 엘리먼트의 startTime을 지시하거나(조건 (a)이 경우) 동적 트리거의 event_time을 지시하는(조건 (b)) "t=" 항과 함께 기록에 포함될 수 있다. 트리거는 버전("v=") 항도 포함할 수 있다.
물론, (a)의 경우 startTime에서 endTime까지의 구간을 통해 계속해서 활성화 트리거들을 프레임들과 연관시키는 이유는 이 구간을 통해 채널에 참여하는 수신기들을 어느 정도 수용하기 위해서이다.
이 접근법은 ACR 서버측에 추가적인 지능을 요구하지 않는다. 이 서버는 단순히 데이터베이스에서 발견하는 정보를 ACR 클라이언트에 리턴하는 점을 유의해야 한다. 모든 지능은 ACR 인제스트 모듈에 있을 수 있다. 더욱이, ACR 인제스트 모듈이 수행해야 할 연산들이 매우 간단할 수 있다.
이 방식을 이용하면, 수신기에서 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거(서로 다른 프레임들과 연관된 트리거)를 수신하는 것이 가능한다. 그러나, 수신기는 "t=" 값으로부터 이 트리거들이 모두 동일한 활성화 시간을 가짐을 알 수 있으므로, 수신기는 이들이 중복된다고 판단하여 이벤트를 한 번만 활성화시킬 수 있다.
앞의 경우들 중 두 경우에, 활성화 트리거 내의 "t=" 항은 연관된 프레임의 media_time 보다 빠른 event_time을 가질 수 있다. (a) 상황에서, 활성화 엘리먼트의 endTime이 startTime 보다 상당히 늦으면, 수신기는 일반적으로 startTime과 endTime의 사이의 구간을 통해 다수의 활성화 트리거들을 받을 수 있고, 이들은 모두 활성화 시간으로서 startTime을 가질 수 있다. (c) 상황에서는, 활성화를 위한 활성화 트리거들이 너무 늦게 프레임 기록들에 삽입되어 수신기가 받는 활성화 트리거가 요청에 대한 응답으로 활성화 시간 이후의 media_time을 가진 프레임에 대한 시그니처와 함께 올 수 있다. 수신기가 연과된 프레임의 media_time 보다 빠른 event_time을 가진 활성화 트리거를 받으면, 이 트리거가 이미 확인하여 해당 이벤트의 활성화를 위해 사용한 활성화 트리거와 동일한 것으로 인식하지 않은 경우 해당 이벤트를 즉시 활성화하는 것으로 생각할 수 있다.
프레임의 media_time이 event_activation time 보다 늦은 경우에 "지금 시행" 트리거가 아닌 과거의 event_time 값을 이용하는 목적은 수신기가 이러한 "after the fact" 활성화 트리거들을 하나 이상 받을 수 있기 때문이다. "t=" 값은 수신기에서 이 트리거들이 모두 동일한 활성화 시간을 가지는 것으로 판단하고 해당 이벤트를 한 번만 활성화시킬 수 있게 한다.
도 29는 AMT 내의 활성화 엘리먼트에 endTime 속성이 없는 상황 (a)와 상황 (b)를 설명한다.
도 29는 AMT 내의 활성화 엘리먼트가 endTime을 가지지 않을 때 앞서 동작 (4)에서의 상황 (a)의 일예를 도시한다. 이는 ACR 인제스트 모듈에 활성화 시간보다 적어도 M 시간 단위 이전에 동적 활성화 트리거가 보내지는 위의 단계 (4)에서의 상황 (b)의 예일 수도 있다.
도 29는 타임 라인(time line) 위에 이벤트 활성화 시간과 이보다 선행하는 길이 L1, L2 및 L3의 구간들을 포함하는 길이 M의 구간을 도시하고 있다. 타임 라인 밑의 수직 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 M의 구간의 시작보다 선행하거나 이벤트 활성화 시간 뒤에 오는 각 프레임은 데이터베이스에서 시간 베이스 트리거와 연관되어 있게 된다. 길이 M의 구간 내의 각 프레임은 데이터베이스에서 도면 아래의 두 예들(f1, f2)과 같은 활성화 트리거와 연관되어 있게 된다. 각 프레임에 대한 "t=" 항은 media_time에 대한 이벤트 활성화 시간을 지시할 수있다. (동그라미 친 f1, f2 로 도시되어 있다.)
동그라미 친 네 개의 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 예에서, 수신기는 동일한 이벤트 활성화에 대해 두 개의 활성화 트리거를 받게 되지만, 이 트리거들은 동일한 이벤트 활성화 시간을 가지므로, 수신기는 이들을 동일한 것으로 인식하여 첫 번째 트리거만 적용하게 된다. 수신기의 요청들 사이의 간격이 L1 미만이기 때문에 수신기는 도면에 도시된 L1 구간에서 프레임에 대한 시그니처와 함께 적어도 하나의 요청을 하도록 보장된다. 이에 따라 활성화 시간 이전에 시그니처를 산출하여 ACR 서버에 요청을 보내고 그 응답으로 활성화 트리거를 받을 시간을 갖게 된다. 이 예에서 수신기가 받는 첫 번째 활성화 트리거는 미리 전달되어지만, 수신기가 받는 두 번째 활성화 트리거는 간신히 시간에 맞춰 도달하게 된다(이 트리거는 중복 트리거이다).
도 30은 EndTime이 없는 경우 (a)와 경우 (b)에서의 활성화 트리거들의 일 실시예를 도시한 도면이다.
이하, EndTime이 없는 경우 (a)와 경우 (b)에서의 활성화 트리거들을 설명한다. 이는 위의 도 29 에 대한 설명과 유사하다.
도 30은 AMT 내의 활성화 엘리먼트가 endTime를 가지지 않는 경우에 위의 동작 (4)에서 상황 (a)의 예를 도시한다. 이는 이는 ACR 인제스트 모듈에 활성화 시간보다 적어도 M 시간 단위 이전에 동적 활성화 트리거가 보내어지는 위의 단계 (4)에서 상황 (b)의 예이다.
도 30은 타임 라인(time line) 위에 이벤트 활성화 시간과 이보다 선행하는 길이 L1, L2 및 L3의 구간들을 포함하는 길이 M의 구간을 보여준다. 타임 라인 밑의 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 M의 구간의 시작보다 선행하거나 이벤트 활성화 시간 뒤에 오는 각 프레임은 데이터베이스에서 <media_time> 또는 <event_time> 항이 없는 트리거와 연관되어 있게 된다. 길이 M의 구간 내의 각 프레임은 데이터베이스에서 도면 아래의 두 예들과 같은 활성화 트리거와 연관되어 있게 된다. 각 프레임에 대한 "d=" 항은 이 프레임과 이벤트 활성화 시간 사이의 시간의 길이를 지시할 수 있다.(동그라미 친 f1, f2로 도시되어 있다).
동그라미 친 네 개의 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 예에서, 수신기는 동일한 이벤트 활성화에 대해 두 개의 활성화 트리거를 받게 되지만, <d1> 값을 프레임 f1에 대한 수신기의 로컬 시간 더하거나 <d2> 값을 프레임 f2에 대한 수신기의 로컬 시간에 더하여 산출한 활성화 시간들은 동일한 결과를 가지므로, 수신기는 이들을 중복된 것으로 인식하여 첫 번째 트리거만 적용하게 된다. 수신기 요청들 사이의 간격이 L1 미만이기 때문에 수신기는 수신기는 도면에 도시된 L1 구간에서 프레임에 대한 시그니처와 함께 적어도 하나의 요청을 하도록 보장된다. 이에 따라 활성화 시간 이전에 시그니처를 산출하여 ACR 서버에 요청을 보내고 그 응답으로 활성화 트리거를 받을 시간을 갖게 된다. 이 예에서 수신기에서 수신된 두 번째 활성화 트리거는 활성화 시간 이후에 도달하게 된다.
도 31는 EndTime이 있는 경우 (a)의 활성화 트리거들의 일 실시예를 도시한 도면이다.
도 31은 AMT 내의 활성화 엘리먼트가 startTime 뿐만 아니라 endTime을 가지는 경우에 위의 동작 (4)에서 상황 (a)의 예를 도시한다.
이 도면은 타임 라인 위에 이벤트 활성화의 startTime과 endTime 및 startTime 보다 선행하는 길이 M의 구간을 보여준다. 타임 라인 밑의 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 M의 구간의 시작보다 선행하거나 이벤트 활성화의 endTime 뒤에 오는 각 프레임은 데이터베이스에서 시간 베이스 트리거와 연관되어 있게 된다. 길이 M의 구간 내부 또는 이벤트 활성화의 startTime과 endTime 사이의 각 프레임은 데이터베이스에서 도면 아래의 세 가지 예에서 보이는 형태로 된 연관된 활성화 트리거를 갖게 된다. 각 프레임에 대한 "t=" 항은 media_time에 대한 이벤트 활성화 시간을 지시할 수있다.(동그라미 친 f1, f2, f3로 도시되어 있다.)
동그라미 친 세개의 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 경우에 수신기는 동일한 이벤트 활성화에 대해 세 개의 활성화 트리거를 받게 되지만, 활성화 시간들이 동일하므로, 수신기는 이들을 동일한 것으로 인식하여 첫 번째 트리거만 적용하게 된다.
물론, 도면에 도시된 처음 두 활성화 트리거들은 startTime 이후에 채널에 참여하여 첫 번째 요청과 함께 프레임 f3의 시그니처를 보내는 수신기에서 알지 못하게 된다.
도 32는 EndTime이 있는 경우 (a)의 활성화 트리거들의 일 실시예를 도시한 도면이다.
이하, EndTime이 있는 경우 (a)의 활성화 트리거들을 설명한다.
도 32는 AMT 내의 활성화 엘리먼트가 startTime 뿐만 아니라 endTime을 가지는 경우에 위의 동작 (4)에서의 상황 (a)의 예를 도시한다.
이 도면은 타임 라인 위에 이벤트 활성화의 startTime과 endTime 및 startTime 보다 선행하는 길이 M의 구간을 보여준다. 타임 라인 밑의 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 M의 구간의 시작보다 선행하거나 이벤트 활성화 시간 뒤에 오는 각 프레임은 데이터베이스에서 <media_time> 또는 <event_time> 항이 없는 트리거와 연관되어 있게 된다. 길이 M의 구간 내부의 각 프레임은 데이터베이스에서 도면 아래의 두 예에서 보이는 형태의 활성화 트리거를 갖게 된다. 각 프레임에 대한 "d=" 항은 이 프레임과 이벤트 활성화 시간 사이의 시간의 길이을 지시할 수 있다.(동그라미 친 수직 화살표들로 도시되어 있다).
동그라미 친 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 경우에 수신기는 동일한 이벤트 활성화에 대해 세 개의 활성화 트리거를 받게 되지만, <d1> 값을 프레임 f1에 대한 수신기의 로컬 시간에 더하거나 <d2> 값을 프레임 f2에 대한 수신기의 로컬 시간에 더하거나 (음의) <d3> 값을 프레임 f3에 대한 수신기의 로컬 시간에 더하여 산출한 활성화 시간들은 동일한 결과를 가지므로, 수신기는 이들을 중복된 것으로 인식하여 첫 번째 트리거만 적용하게 된다.
물론, 도면에 도시된 처음 두 활성화 트리거들은 startTime 이후에 채널에 참여하여 첫 번째 요청과 함께 프레임 f3의 시그니처를 보내는 수신기에서 알지 못하게 된다.
도 33은 경우 (c)에 대한 활성화 트리거들의 일 실시예를 도시한 도면이다.
도 33은 활성화 시간 이전에 M 시간 단위보다 늦게 ACR 인제스트 모듈에 동적 활성화 트리거가 보내어지는 위의 동작 (4)에서의 상황 (c)를 도시한다.
도 33은 타임라인 위에 동적 이벤트 활성화 시간과 ACR 인제스트 모듈에서 이벤트의 활성화를 알게되는 이벤트 활성화 시간 바로 전의 시간을 도시하는 도면으로서, ACR 인제스트 모듈에서 이벤트의 활성화를 알게되는 시간 뒤에 길이 L1의 구간이 따라온다. 타임 라인 밑이 수직 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 L1의 구간의 시작보다 선행하거나 길이 L1의 구간의 끝 뒤에 따라오는 각 프레임은 데이터베이스에서 이 프레임과 연관된 시간 베이스 트리거를 갖게 된다. 길이 L1의 구간 내의 각 프레임은 데이터베이스에서 도면 아래의 예와 같은 활성화 트리거를 갖게 된다. 각 프레임에 대한 "t=" 항은 미디어 시간 라인에 대한 이벤트 활성화 시간을 지시하게 된다.(동그라미 친 수직 화살표들로 도시되어 있다.) 동그라미 친 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 경우에 수신기는 이벤트 활성화에 대해 하나의 활성화 트리거를 갖게 된다. 활성화 트리거의 활성화 시간은 이 트리거를 수신한 시간 전이므로, 수신기는 트리거를 수신한 즉시 적용하게 된다.
도 34는 경우 (c)에 대한 활성화 트리거들의 일 실시예를 도시한 도면이다.
이하, 경우 (c)에 대한 활성화 트리거들을 설명한다.
도 34는 활성화 시간 이전에 M 시간 단위보다 늦게 ACR 인제스트 모듈에 동적 활성화 트리거가 보내어지는 위의 동작 (4)에서의 상황 (c)를 도시한다
도 34는 타임라인 위에 동적 이벤트 활성화 시간과 ACR 인제스트 모듈에서 이벤트의 활성화를 알게되는 이벤트 활성화 시간 바로 전의 시간을 도시하는 도면으로서, ACR 인제스트 모듈에서 이벤트의 활성화를 알게되는 시간 뒤에 길이 M의 구간이 따라온다. 타임 라인 밑의 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 M의 구간의 시작보다 선행하거나 길이 M의 구간의 끝 뒤에 오는 각 프레임은 데이터베이스에서 <media_time> 또는 <event_time> 항이 없는 트리거를 갖게 된다. 길이 M의 구간 내의 각 프레임은 데이터베이스에서 도면 아래의 두 예들과 같은 활성화 트리거를 갖게 된다. 각 프레임에 대한 "d=" 항은 이 프레임과 이벤트 활성화 시간 사이의 시간의 길이을 지시할 수 있다.(동그라미 친 수직 화살표들로 도시되어 있다.) 동그라미 친 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 경우에 수신기는 동일한 이벤트 활성화에 대해 두 개의 활성화 트리거를 받게 되지만, (음의) <d1> 값을 프레임 f1에 대한 수신기의 로컬 시간에 더하거나 (음의) <d2> 값을 프레임 f2에 대한 수신기의 로컬 시간에 더하여 산출한 활성화 시간들은 모두 동일한 결과를 가지므로, 수신기는 이들을 중복된 것으로 인식하여 수신한 첫 번째 트리거만 적용하게 된다. 첫 번째 트리거의 활성화 시간은 이를 수신한 시간 이전이므로 수신기는 이 트리거를 수신한 즉시 적용하게 된다.
도 35는 마지막에 전달되는 동적 활성화 트리거의 일 실시예를 도시한 도면이다.
이벤트 주도형 ACR 모델에서, 수신기는 ACR 서버에 대한 지속적인 접속을 개시하고, 일정한 간격을 두고 (예를 들면, 5초마다) 프레임과 관련된 시그니처를 생성하고, 시그니처를 접속을 통해 제출하는 것으로 생각할 수 있다. ACR 서버는 각 시그니처에 반응하지 않는다. 그것은 새로운 세그먼트가 발견되거나 이벤트 활성화가 수신기에 전해질 필요가 있을 때 수신기에 메시지를 보낼 수 있다. 해당 모델에서, ACR 서버는 어느 때든 지속적인 접속을 통해 클라이언트에 대한 메시지를 개시할 수 있다.
또한, 수신기로부터의 가장 최근 제출에 대응하는 세그먼트 ID(트리거의 <locator_part>) 및 수신기에 보내지는 최근 활성화 트리거와 같은 각 수신기에 관한 일정량의 정보를 유지하는 것은 서버에게 간단하다.
해당 이벤트 주도형 모델을 사용하고 활성화들을 수신기에 전달하는 ACR 서버에 대해, 다음의 규칙은 ACR 서버에로부터의 메시지를 신청할 수 있다.
첫째로, ACR 서버는 새로운 세그먼트에서의 프레임에 대응하는 수신기로부터 시그니처를 수신하면, 수신기가 관련된 TPT를 획득할 수 있게 하기 위해, 즉시 시간 베이스 트리거와 함께 메시지를 수신기에 보낼 수 있다.
둘째로, ACR 서버는 (수신기가 본 가장 최근 버전과 다른) TPT에 대한 새로운 버전 넘버를 갖는 세그먼트의 일부에서의 프레임에 대응하는 수신기로부터 시그니처를 수신하면, 수신기가 관련된 TPT의 새로운 버전을 획득할 수 있게 하기 위해, 즉시 "v=" 항을 갖는 시간 베이스 트리거와 함께 메시지를 수신기에 보낼 수 있다.
셋째로, 이벤트가 활성화될 예정일 때, ACR 서버는 활성화 트리거를 수신기에 보낼 수 있다. 가능하다면, 미디어 시간 라인과 관련된 활성화 시간을 나타내기 위해 활성화 트리거에서의 "t=" 항과 함께, 수신기가 적용해야 하는 시기보다 조금 앞서서 활성화 트리거를 보낼 수 있다(이는 요청/응답 모델에서의 동작과 유사하다). ACR 서버는 활성화를 너무 늦게 알게 되어 활성화 트리거를 보통 때보다 훨씬 일찍 보낼 수 없어도, 활성화를 알자마자 가능한 빨리 활성화 트리거를 보낼 수 있다. (후자의 경우에, 수신기는 활성화 시기 후에 활성화 트리거를 받을 수 있고, 이 경우 수신기는 활성화 트리거를 받은 즉시 이벤트를 활성화할 것으로 생각할 수 있다.)
도 28에 나타낸 요청/응답 경우에 대한 아키텍처도 한 가지 차이점을 갖고 해당 이벤트 주도형 경우에 적합하다. 그 차이점은 이벤트 주도형 경우에 있어 새로운 액션 (2a)가 있을 수 있다는 점이다. 동적 활성화 트리거가 존재하면, ACR 인제스트 모듈이 선택된 동적 활성화 트리거를 ACR 서버에 보낼 수 있도록, ACR 인제스트 모듈과 ACR 인제스트 모듈에 의해 실장된 데이터베이스를 사용하는 모든 ACR 서버 사이에 접속이 설정될 수 있다.
이벤트 주도형 경우에 대한 번호가 붙은 액션은 요청/응답 경우와 유사할 수 있다. 새로운 액션 (2a) 외에, 액션 (4)이 조금 다르고, 액션 (13)이 조금 다르고, 새로운 액션 (14)이 추가된다.
액션 (4)에서, ACR 인제스트 모듈은 프레임들로부터 시그니처들을 추출하거나(핑거프린트 ACR 시스템의 경우) 연관된 양방향 서비스를 가지는 세그먼트들에 포함된 모든 프레임들에 대하여 코드들을 프레임에 삽입(워터마크 ACR 시스템의 경우)할 수 있다. (ACR 인제스트 모듈은 GPS 클럭과 방송 스케줄 내 세그먼트들의 시작 시간 및 종료 시간을 이용하여 프레임이 그와 같은 세그먼트에 있는지 판단할 수 있다.) 그와 같은 각 프레임에 대하여 ACR 인제스트 모듈은, 트리거와 시그니처 또는 해당 프레임과 연관된 코드를 포함할 수 있는 데이터베이스에 기록을 삽입할 수 있다. 다음 두 조건 중 적어도 하나를 만족하지 않으면, ACR 인제스트 모듈에 의해 기록에 포함된 트리거는 시간 베이스 트리거가 될 수 있다.
(a) 활성화 엘리먼트는, 프레임의 media_time이 활성화 엘리먼트의 startTime 전 시간 길이 M에서 시작하여 활성화 엘리먼트의 endTime에서 끝나는 시간 구간에 있도록 AMT에 존재한다. (활성화가 endTime을 가지지 않으면, endTime은 startTime과 동일한 것으로 간주된다.) (요청/응답 ACR 모델에 대해 조건 (a)와 동일)
(b) 트리거의 활성화 시간("t=<event_time>") 직전의 시간 길이 M의 시간 구간 이전에 동적 활성화 트리거가 인제스트 모듈에 의해 수신되었고, 해당 프레임은 이 구간 내에 존재한다. (요청/응답 ACR 모델에 대해 조건 (b)와 동일)
이 조건들 (a) 및 (b) 중 어느 것이라도 성립하면, 활성화 트리거는, 활성화될 이벤트를 식별하는 "e=" 항과 AMT 내 활성화 엘리먼트의 startTime을 지시하거나(조건 (a)이 경우) 동적 트리거의 event_time을 지시하는(조건 (b)) "t=" 항과 함께 기록에 포함될 수 있다.
동적 활성화 트리거가 트리거의 활성화 시간 직전의 시간 길이 M의 구간 동안 인제스트 모듈에 의해 수신되면(이때 M은 요청/응답 서버 경우에서와 같은 의미를 갖는다), 인제스트 모듈은 동적 활성화 트리거와 관련하여 데이터베이스에 어느 것도 두지 않고, 인제스트 모듈이 기록을 삽입할 수 있는 데이터베이스를 사용하는 모든 ACR 서버로 활성화 트리거를 전달할 수 있다. (이 아키텍처에 대해 다음과 같은 변형이 있을 수 있다. 인제스트 모델을 거치지 않고 동적 활성화 트리거가 동적 활성화 트리거 소스로부터 ACR 서버로 직접 전달되지만, 관련된 수신기에 즉시 메시지를 보낼 수 있도록 ACR 서버는 활성화 시간 이전의 M 시간 단위보다 늦게 도착하는 동적 활성화 트리거를 얻는다. 다음 수신기 제출까지 기다리면 너무 늦을 것이다.)
액션 (13)에서, ACR 서버는 직전 제출에 대해 수신하지 않은 후 데이터베이스로부터 "no match" 지시자를 돌려받으면, 수신기에 NULL 메시지를 보낼 수 있다. 직전 제출에 대해 돌려받은 <locator_part>와 다른 <locator_part>와 함께 트리거를 돌려받으면, 수신기에 트리거를 보낼 수 있다. 두 경우에서, 수신기에 시청중인 채널이 변경되었거나 시청중인 세그먼트가 끝났다고 말해주어 수신기가 현재 실행하고 있는 TDO를 종료하고 필요하다면 새로운 TPT를 다운로드 하도록 할 수 있다. ACR 서버는 하나 이상의 활성화 트리거를 돌려받으면, 이미 수신기에 보내진 활성화 트리거와 중복되는 것은 버리고 수신기에 보낼 수 있다. 그렇지 않으면, ACR 서버는 아무것도 하지 않을 수 있다.
새로운 액션 (14)에서, ACR 서버는 동적 활성화 트리거를 수신하면, 동적 활성화 트리거의 <locator_part>와 각 ACR 클라이언트에 대한 현 <locator_part>를 비교할 수 있다. (여기서 클라이언트에 대한 현 <locator_part>는 ACR 서버가 ACR 클라이언트로부터의 가장 최근 제출에 대해 데이터베이스로부터 받은 트리거의 <locator_part>이다. <locator_part>가 매칭되는 각 클라이언트에 대해서, ACR 서버는 동적 트리거를 클라이언트에 보낼 수 있다.)
도 29 및 31은 활성화 시간보다 적어도 M 시간 단위 이전에 ACR 인제스트 모듈로 전달되는 정적 활성화 및 동적 활성화에 대한 트리거의 처리를 나타낸다. 차이점은 ACR 서버가 중복되는 활성화 트리거를 수신기에 보내지 않고 버릴 수 있다는 점이다.
도 35는 갑자기(활성화 시간보다 M 시간 단위 이전에) 수신된 동적 활성화 트리거의 처리의 일 실시예를 나타낸다.
도 35는 시간 라인 상의 동적 이벤트 활성화 시간 및 ACR 인제스트 모듈이 이벤트 활성화에 대해 알 때인 이벤트 활성화 시간보다 조금 앞선 시간을 나타낸다. 시간 라인 아래의 수직 화살표는 개별 프레임의 횟수를 나타낸다. ACR 서버는 ACR 인제스트 모듈로부터 활성화 트리거를 수신하자마자, (트리거의 <locator_part>에 의해 확인되는 바와 같이) 현재 활성화 트리거와 관련된 세그먼트를 시청하고 있는 모든 수신기에 활성화 트리거를 보낼 수 있다.
도 36은 마지막에 전달되는 동적 활성화 트리거의 일 실시예를 도시한 도면이다.
마지막에 전달되는 동적 활성화 트리거에 대해 설명한다.
도 36은 갑자기(활성화 시간보다 M 시간 단위 이전에) 수신된 동적 활성화 트리거의 처리의 일 실시예를 나타낸다.
마지막에 전달되는 동적 활성화 트리거를 나타내는 해당 도면은 시간 라인 상의 동적 이벤트 활성화 시간 및 ACR 인제스트 모듈이 이벤트 활성화에 대해 알 때인 이벤트 활성화 시간보다 조금 앞선 시간을 나타낸다. 시간 라인 아래의 수직 화살표는 개별 프레임의 횟수를 나타낸다. ACR 서버는 ACR 인제스트 모듈로부터 활성화 트리거를 수신하자마자, (트리거의 <locator_part>에 의해 확인되는 바와 같이) 현재 활성화 트리거와 관련된 세그먼트를 시청하고 있는 모든 수신기에 활성화 트리거를 보낼 수 있다. 각 수신기에 대해, 트리거의 event_time을 수신기로부터 가장 최근에 제출된 시그니처에 대응하는 프레임과 관련된 <delay_time>로 조절한다.
도 37 는 요청/응답 ACR의 경우의 ACR 클라이언트와 다른 서버들 사이의 시퀀스 다이어그램을 도시한 도면이다.
도 37 는 요청/응답 모델에서 ACR 서버와 수신기(ACR 클라이언트)의 동작 프로토콜에 따라 트리거 및 TPT를 효과적으로 전송하는 실시예에 따른 시퀀스 다이어그램을 나타낸다.
이하, 요청/응답의 순서로 요청/응답 모델의 동작에 대한 일 예를 설명한다.
요청/응답 ACR 경우에서 ACR 클라이언트와 다른 서버 사이의 시퀀스 다이어그램은 ACR 요청 1 (S37010), ACR 응답 1 (S37020), ACR 요청 2 (S37030), ACR 응답 2 (S37040), HTTP 요청 1 (S37050), HTTP 응답 1 (S37060), HTTP 요청 2 (S37070), HTTP 응답 2 (S37080), ACR 요청 3 (S37090), ACR 응답 3 (S37100), ACR 요청 4 (S37110), 및/또는 ACR 응답 4 (S37120)를 포함할 수 있다.
ACR 요청 1 (S37010)은 수신기가 현재 시청중인 프로그램의 시그니처를 서버에 보내는 단계이다. 서버는 전술한 ACR 서버일 수 있다. 시그니처는 핑거프린트 시그니처 또는 워터마킹 코드일 수 있다.
ACR 응답 1 (S37020)은 시그니처가 인식되지 않거나 관련된 양방향 서비스가 존재하지 않을 때 ACR 서버가 널을 리턴하는 단계이다. 이는 널 응답이 리턴되는 앞서 설명한 경우에 해당하는 경우일 수 있다.
ACR 요청 2 (S37030)는 채널 또는 프로그램이 변경될 때 수신기가 변경된 프로그램의 시그니처를 ACR 서버에 전송하는 단계이다.
ACR 응답 2 (S37040)는 ACR 서버가 해당 프로그램에 관련된 양방향 서비스를 획득할 수 있는 주소를 포함하는 트리거(예를 들면, xbc.com/tpt504)를 리턴하는 단계이다. 이 단계는 ACR 응답 1 (S37020)과 달리, 시그니처가 인식되고 관련된 양방향 서비스가 존재하는 경우에 해당할 수 있다. 즉, 트리거가 이용가능한 경우일 수 있다. 이 경우 리턴 받는 트리거는 media_time에 대한 정보가 없는 시간 베이스 트리거일 수 있다.
HTTP 요청 1 (S37050)은 수신기가 TPT 서버(예를 들면, http://xbc.com/tpt504)에게 http 프로토콜을 통해 ACR 응답 2 (S37040)에서 수신한 주소를 이용하여 해당하는 TPT를 제공할 것을 요청하는 단계이다.
HTTP 응답 1 (S37060)은 TPT 서버가 수신기의 요청에 따라 XML에 나타낸 TPT를 전송하는 단계이다.
HTTP 요청 2 (S37070)는 수신기가 콘텐츠 서버에게 http 프로토콜을 이용하여 TDO와 같은 어플리케이션을 제공할 것을 요청하는 단계이다. 수신기는 TPT 내에 포함된 TDO 관련 정보를 파싱할 수 있다. TDO 관련 정보는 TDO를 다운로드 받을 수 있는 콘텐츠 서버의 주소일 수 있다. 콘텐츠 서버의 주소를 이용하여 요청을 보낼 수 있다.
HTTP 응답 2 (S37080)는 콘텐츠 서버가 수신기의 요청에 따라 해당하는 TDO를 전송하는 단계이다.
ACR 요청 3 (S37090)은 수신기가 현재 시청중인 프로그램의 프레임의 시그니처를 ACR 서버에 보내는 단계이다.
ACR 응답 3 (S37100)은 ACR 서버가 해당 프로그램에 관련된 양방향 서비스를 획득할 수 있는 주소를 포함하는 트리거(예를 들면, xbc.com/tpt504)를 리턴하는 단계이다. 이 경우, ACR 응답 1 (S37020)과 달리, 시그니처가 인식되고 관련된 양방향 서비스가 존재한다. 즉, 이 단계에서 트리거는 사용 가능하다.
ACR 요청 4 (S37110)는 수신기가 현재 시청중인 프로그램의 프레임의 시그니처를 ACR 서버에 전송하는 단계이다.
ACR 응답 4 (S37120)는 ACR 서버가 수신기로부터 전송된 시그니처와 관련된 양방향 서비스와 관련된 활성화 트리거를 전송하는 단계이다. 특정 이벤트가 활성화 트리거에 따라 특정 시간에 활성화될 수 있다.
도 38은 이벤트 주도형 ACR 경우의 ACR 클라이언트와 다른 서버들 사이의 시퀀스 다이어그램을 도시한 도면이다.
도 38은 이벤트 주도형 모델에서 ACR 서버와 수신기(ACR 클라이언트)의 동작 프로토콜에 따라 트리거 및 TPT를 효과적으로 전송하는 실시예에 따른 시퀀스 다이어그램을 나타낸다.
요청, 요청에 대한 응답, 이벤트의 순서로 이벤트 주도형 모델의 동작에 대한 일 예를 설명한다.
이벤트 주도형 ACR 경우에서 ACR 클라이언트와 다른 서버 사이의 시퀀스 다이어그램은 ACR 요청 1 (S38010), ACR 요청 2 (S38020), ACR 이벤트 1 (S38030), HTTP 요청 1 (S38040), HTTP 응답 1 (S38050), HTTP 요청 2 (S38060), HTTP 응답 2 (S38070), ACR 요청 3 (S38080), ACR 이벤트 2 (S38090), 및/또는 ACR 응답 4 (S38100)를 포함할 수 있다.
ACR 요청 1 (S38010)은 수신기가 현재 시청중인 프로그램의 시그니처를 서버에 보내는 단계이다. 서버는 앞서 설명한 ACR 서버일 수 있다. 시그니처는 핑거프린트 시그니처 또는 워터마크일 수 있다. 여기서, 시그니처가 인식되지 않거나 관련된 양방향 서비스가 존재하지 않을 때, 도 37의 시퀀스와 달리, ACR 서버는 널을 리턴하지 않고 ACR 요청 1에 아무 응답도 보내지 않을 수 있다.
ACR 요청 2 (S38020)는 채널 또는 프로그램이 변경될 때 수신기가 변경된 프로그램의 시그니처를 ACR 서버에 전송하는 단계이다.
ACR 이벤트 1 (S38030)은 ACR 서버가 해당 프로그램에 관련된 양방향 서비스를 획득할 수 있는 주소를 포함하는 트리거(예를 들면, xbc.com/tpt504)를 리턴하는 단계이다. 이 단계는 시그니처가 인식되고 관련된 양방향 서비스가 존재하는 경우에 해당할 수 있다. 즉, 이 단계에서 트리거는 사용 가능하다. 이 경우, 리턴하는 트리거는 media_time과 관련된 어떤 정보도 가지고 있지 않은 시간 베이스 트리거일 수 있다.
HTTP 요청 1 (S38040)은 수신기가 TPT 서버(예를 들면, http://xbc.com/tpt504)에게 http 프로토콜을 통해 ACR 이벤트 1 (S38030)에서 수신한 주소를 이용하여 해당하는 TPT를 제공할 것을 요청하는 단계이다.
HTTP 응답 1 (S38050)은 TPT 서버가 수신기의 요청에 따라 XML에 나타낸 TPT를 전송하는 단계이다.
HTTP 요청 2 (S38060)는 수신기가 콘텐츠 서버에게 http 프로토콜을 이용하여 TDO와 같은 어플리케이션을 제공할 것을 요청하는 단계이다. 수신기는 TPT 내에 포함된 TDO 관련 정보를 파싱할 수 있다. TDO 관련 정보는 TDO를 다운로드 받을 수 있는 콘텐츠 서버의 URL일 수 있다. 콘텐츠 서버의 URL을 이용하여 요청을 보낼 수 있다.
HTTP 응답 2 (S38070)는 콘텐츠 서버가 수신기의 요청에 따라 해당하는 TDO를 전송하는 단계이다.
ACR 요청 3 (S38080)은 수신기가 현재 시청중인 프로그램의 프레임의 시그니처를 ACR 서버에 보내는 단계이다.
ACR 이벤트 2 (S38090)는 ACR 서버가 수신기로부터 전송된 시그니처와 관련된 양방향 서비스와 관련된 활성화 트리거를 전송하는 단계이다. 특정 이벤트가 활성화 트리거에 따라 특정 시간에 활성화될 수 있다.
ACR 응답 4 (S38100)는 수신기가 현재 시청중인 프로그램의 프레임의 시그니처를 ACR 서버에 보내는 단계이다.
도 39는 UPnP RemoteUI 클라이언트 서비스의 액션 리스트의 일 실시예이다.
제2 스크린 지원은, 수신기에서 방송사의 서비스 혹은 방송사에서 제공하고 프로그램에 적합한 부가적인 서비스들을 제2 스크린 디바이스에 제공하기 위한 방법에 대한 것이다. 부가적인 컨텐츠는 어플리케이션을 통해 제공될 수 있으며, 어플리케이션은 TV 화면에 표시가 되어 사용자가 리모컨 조작으로 부가 컨텐츠를 사용하게 할 수 있다. 그러나, 최근 개인화 정보화기기(스마트 폰, 스마트 패드 및 소형화 되고 있는 랩탑) 등에 의하여 TV 화면에서 재생이 되고 있는 컨텐츠들은 그대로 보이게 하면서 부가적인 서비스들을 제2 스크린 디바이스에 보이도록 할 수 있다. 이로써, 기존의 방송 컨텐츠를 방해하지 않고 개인적으로 사용할 수 있도록 할 수 있다. 이렇게 부가적인 데이터나 정보들을 제2 스크린 디바이스에 표시하여 처리를 한다면, TV화면을 여러 사람이 함께 보는 상황에서, 부가 서비스에 관심이 있는 사람만이 다른 사람들의 TV시청을 방해하지 않고 부가 컨텐츠를 얻을 수 있는 효과가 있다. 제2 스크린 지원은 전술한 효과 외에도 다양한 용도로 활용될 수 있다.
하나의 장치가 다른 장치들과 연결되고 제어하기 위해서는 먼저 홈네트워크에 어떤 장치들이 있는지를 알아야 할 수 있다. 따라서 하나 이상의 장치들이 자신의 존재를 주기적으로 홈네트워크에 메시지를 전송하여 널리 알릴 수 있다. 한편으로 하나의 장치가 새롭게 홈네트워크에 연결이 되면서 자신을 소개하기 전에 자신 외의 어떤 장치가 있는지를 요청할 수 있다. 이 두 가지 접근 방식들은 서로 장치들을 쉽고 빠르게 인식할 수 있도록 도와줄 수 있다. 이를 UPnP 디바이스 디스커버리(Device Discovery)이라고 한다. 장치를 발견하면 발견된 장치에 관심이 있는 다른 장치들은 그 장치에 어떤 서비스들을 제공해 줄 수 있는지 정보가 필요할 수 있다. UPnP 프레임워크(Framework) 가 내장이 되어 있는 가전기기들은 서로 어떤 기능들을 가지고 있는지 그리고 그 기능들이 어떤 범위까지 지원하는지를 알 수 있다. 이 정보를 UPnP 디바이스 프로파일(Device Profile)로 정의해 두고 서로가 제공할 수 있는 서비스의 속성들을 파악할 수 있다. 특정 서비스를 제공하는 장치를 항상 기다리고 있을 수 있는데, 그 특정 서비스를 제공하는 장치가 발견될 경우, 발견된 장치내에 어떤 서비스들이 있는지를 물을 수 있다. 발견된 장치 내에 적합한 서비스가 있을 경우 바로 연결하여 서로 통신을 할 수 있다. 또한, UPnP 서비스 기술어(Service Descriptor)에 정의된 대로 서비스를 정의하여 교환할 수 있다.
하나의 장치에는 단수 또는 복수개의 서비스가 있어서, 이 서비스를 서로 다른 기기들에서 제어하고 사용할 수 있게 되어 있다. 장치가 하나 이상의 기능들이 있다면 그 기능별로 정의된 복수개의 서비스가 포함이 되어, 다른 기기들에서 제어할 수 있다. 장치의 정의는 장치 고유의 정보를 가질 수 있다. 예를 들면, 모델 이름(Model Name), 일련 번호(Serial Number), 모델 번호(Model Number), CE 제조자 이름(Manufacturer Name) 및 웹 사이트(Web Site) 등의 정보들이 장치 고유의 정보일 수 있다. 이 정보들은 장치별로 고유의 값을 가지며 일반적으로 변경이 되지 않을 수 있다. 서비스는 장치가 수행할 수 있는 동작으로, 각 동작들은 액션(Action)이라고 부르며, 하나 이상의 액션을 가질 수 있다. 액션은 함수와 같이 각각 파라미터 값을 가지며, 하나 이상의 파라미터 값을 가질 수 있다. 액션은 장치 내의 서비스에서 수행이 되며, 액션이 수행된 후에는 필요에 의하여 정의된 리턴 값을 반환 할 수 있다.
액션에 대한 예시로서, 도 39는 예시된 서비스인 UPnP RemoteUI 클라이언트 서비스에 대하여, 그 서비스의 액션들의 종류 및 기술(Description)을 도시하고 있다. Connection/disconnection은 현재 접속 상태를 반환하는 액션일 수 있다. GetCurrentConnection은, 현재 접속 목록을 반환하는 액션일 수 있다. GetDeviceProfile은 디바이스 프로파일을 XML 의 형태로 반환하는 액션일 수 있다. GetUIListing은 호환가능한(compatible)한 UI의 목록을 XML 의 형태로 반환하는 액션일 수 있다. AddUIListing/RemoveUIListing은 remote UI의 URL을 UI 목록에 추가하거나 제거하는 동작일 수 있다. ProcessInput은 RemoteUI 클라이언트 서비스로 데이터를 보내는 액션일 수 있다. DisplayMessage는 RemoteUI 클라이언트 서비스를 포함하는 장치에 메시지를 디스플레이하는 액션일 수 있다.
도 40는 UPnP RemoteUI 클라이언트 서비스의 일 실시예이다.
UPnP에서는 전술한 액션과 필요한 파라미터값들을 전송하기 위하여 SOAP이라는 XML 메시지 형식을 사용하며, SOAP은 원격 절차(Remote Procedure)를 원격으로 수행하기 위하여 사용될 수 있다. 이 메시지들은 HTTP 프로토콜을 이용하여 전송될 수 있다.
전술한 RemoteUI 클라이언트의 액션들은 도 40과 같이 동작할 수 있다. 도 40에 도시된 동작들은 전술한 액션의 일 실시예에 불과하다.
UPnP RemoteUI 클라이언트 서비스의 일 실시예는 UPnP 탐색 프로세스와 RemoteUI 클라이언트 액션들로 나누어 볼 수 있다.
UPnP 탐색 프로세스는 제2 스크린 서비스를 위한 UPnP 애플리케이션을 실행하는 단계 (s40001), UPnP 디바이스를 찾는 단계(s40010), RemoteUIClient를 찾는 단계(s40020), 디바이스 기술(Device Description)을 요청하는 단계(s40030), 디바이스 기술을 수신하는 단계(s40040), 서비스 제어 기술을 요청하는 단계(s40050) 및/또는 서비스 제어 기술을 수신하는 단계(s40060)를 포함할 수 있다.
RemoteUI 클라이언트 액션들은 디바이스 프로파일을 요청하는 단계(s40070), 디바이스 프로파일을 수신하는 단계(s40080), 원격 UI의 URL을 보내는(put) 단계(s40090), 응답1을 전송하는 단계(s40100), RemoteUI 클라이언트 서비스에 메시지를 전송하는 단계(s40110), 응답2를 전송하는 단계(s40120) 및/또는 사용자가 스크린 상의 버튼을 클릭하는 단계(s40130)를 포함할 수 있다.
UPnP 애플리케이션을 실행하는 단계(s40001)는 제2 스크린 디바이스(RemoteUI 클라이언트)에서 an UPnP 애플리케이션을 실행시키는 단계일 수 있다.
UPnP 디바이스를 찾는 단계(s40010)는 프라이머리 디바이스가 제2 스크린 디바이스에서 실행중인 애플리케이션들로 디스커버리 메시지(discovery message)를 멀티캐스트하는 단계일 수 있다. 이를 통해 네트워크 내의 제2 스크린 디바이스를 찾을 수 있다. 프라이머리 디바이스는 디스커버리 메시지를 통해 자신이 제공하는 제2 스크린 지원 서비스를 알릴 수 있다.
RemoteUIClient를 찾는 단계(s40020)는, 제2 스크린 디바이스가 디스커버리 메시지를 받고, 프라이머리 디바이스에 통지 메시지(notification message)를 보내는 단계일 수 있다.
디바이스 기술을 요청하는 단계(s40030)는 프라이머리 디바이스가 제2 스크린 디바이스에 제2 스크린 디바이스에 대한 디바이스 기술을 요청하는 단계일 수 있다.
디바이스 기술을 수신하는 단계(s40040)는, 제2 스크린 디바이스가 디바이스 기술을 요청하는 단계(s40030)에 대한 응답으로서 제2 스크린 디바이스의 디바이스 프로파일을 보내면, 프라이머리 디바이스가 이를 수신하는 단계일 수 있다.
서비스 제어 기술을 요청하는 단계(s40050)는, 프라이머리 디바이스가 제2 스크린 디바이스에 서비스 제어기술을 요청하는 단계일 수 있다.
서비스 제어 기술을 수신하는 단계(s40060)는, 프라이머리 디바이스가 제2 스크린 디바이스로부터, 요청한 서비스 제어 기술을 수신하는 단계일 수 있다.
UPnP 탐색 프로세스를 통해, 네트워크 상에 존재하는 프라이머리 디바이스와 제2 스크린 디바이스는 서로를 찾고 인식하게 될 수 있다. 또한 이를 통해 프라이머리 디바이스와 제2 스크린 디바이스는 서로 연결될 수 있다.
디바이스 프로파일을 요청하는 단계(s40070)는, 제2 스크린 디바이스의 디바이스 프로파일을 요청하는 단계일 수 있다. 전술한 GetDeviceProfile 액션을 이용할 수 있다.
디바이스 프로파일을 수신하는 단계(s40080)는, 프라이머리 디바이스가 요청한 제2 스크린 디바이스의 디바이스 프로파일을 수신하는 단계일 수 있다. "RemoteUI 클라이언트 서비스"를 가지는 장치(제2 스크린 디바이스, RemoteUI 클라이언트)는 원격의 장치(프라이머리 디바이스)에서 UI의 URL주소를 알려 주면 이 주소를 찾아 화면에 표시해 주는 역할을 할 수 있다. 또한 "RemoteUI 서버 서비스"를 가지는 장치는 UI의 URL 주소를 멀티캐스트하여 관심이 있는 장치들에게 알려 주는 서비스일 수 있다. 그러나 이 경우에는 Remote UI 들이 특정 장치를 위하여 만들어지기 때문에 특정 장치들에 맞는 원격 UI를 제공해야 할 수 있다. 따라서 디바이스 프로파일 정보를 함께 전송해 줄 필요가 있을 수 있고, 디바이스 프로파일을 요청하는 단계(s40070) 및 디바이스 프로파일을 수신하는 단계(s40080)가 필요할 수 있다.
원격 UI의 URL을 보내는 단계(s40090)는 원격 UI의 URL 주소를 제2 스크린 디바이스에 알려주는 단계일 수 있다. 전술한 AddUIListing 액션을 이용할 수 있다. 제2 스크린 디바이스는 이를 UIListing에 추가할 수 있다.
응답1을 전송하는 단계(s40100)는 원격 UI의 URL을 보내는 단계(s40090)에 대한 결과를 보내주는 단계일 수 있다. 상황에 따라, HTTP/1.1 200 OK (요청이 성공적으로 처리됨), HTTP/1.1 501 Method Not Implemented (요청을 처리하는데 필요한 기능이 구현되지 않았음), HTTP/1.1 400 Not Found (요청한 파일/자원이 존재하지 않음) 등의 응답을 보내줄 수 있다.
RemoteUI 클라이언트 서비스로 메시지를 전송하는 단계(s40110)는 프라이머리 디바이스가 제2 스크린 디바이스에 디스플레이 메시지를 전송하는 단계일 수 있다. 디스플레이 메시지는 메시지 타입 등의 정보를 포함할 수 있다. 전술한 DispalyMessage 액션을 이용할 수 있다. 제2 스크린 디바이스는 디스플레이 메시지에 따라, 메시지를 제2 스크린에 디스플레이할 수 있다.
응답2를 전송하는 단계(s40120)는 RemoteUI 클라이언트 서비스에 메시지를 전송하는 단계(s40110)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100) 와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
사용자가 스크린 상의 버튼을 클릭하는 단계(s40130)는 제2 스크린에 디스플레이된 메시지 등에 따라, 사용자가 선택을 내리는 단계일 수 있다.
RemoteUI 클라이언트 액션은 전술한 액션 등을 통해 RemoteUI 클라이언트 서비스가 동작하는 과정을 기술한 것일 수 있다.
원격 사용자 인터페이스에 관한 기술은, 화면에 표시되는 HTML 기술 기반의 애플리케이션을 가전기기에서 사용할 수 있도록 기능을 추가하거나 제한된 가전 기기의 리소스를 감안하여 기존의 PC 시스템에서 사용할 수 있는 기능들을 간소화하였다. 이 기술에는 크게 2가지 관점이 포함이 되어 있다. 화면에 표시하는 HTML을 가전 제품에서 사용할 수 있도록 만든 것과 각 가전 제품에서 사용할 수 있는 브라우저 API를 정의하는 것이 그것이다. 브라우저 API는 많이 사용되는 스크립트 언어인 자바스크립트(JavaScript)에서 호출하여 사용할 수 있다. 자바스크립트에서 호출된 API는 결국 수신기의 함수를 호출하게 된다.
이 중에 앞에서 언급을 하였던 UPnP 디바이스와 서비스들을 브라우저에서 동작하는 자바스크립트에 의하여서도 동작할 수 있을 수 있다. 이렇게 하기 위해서는 브라우저에서 각 UPnP 디바이스별로 다른 파라미터들을 전달해 줄 수 있는 새로운 API가 필요할 수 있다.
도 41는 DTVCC Service Number 6에서의 트리거의 일 실시예이다.
전술한 대로, DTVCC(Digital TV Closed Caption Service) 서비스를 활용하여 전술한 트리거를 전송할 수 있다. 트리거는 하나의 URL 스트링(String) 값을 가질 수 있으며, DTVCC 서비스 중에 6번째 서비스로 수신할 수 있다. MPEG-2 전송 프로세서(41010)는 트리거를 DTVCC 서비스 시리즈 #6 로 수신하여, 전송 프로세서 드라이버((41020) 를 통해 DTV-CC 모듈(41040)로 전달할 수 있다. 이 때, Userdata는 버퍼(41030)를 거칠 수 있다. DTV-CC 모듈(41040)은 DTVCC 디코더의 역할을 할 수 있다. DTV-CC 모듈(41040)은 URI 스트링 값을 가지는 트리거를 부가 서비스 모듈(Adjunct Service module)(41050)로 전달해 줄 수 있다. 부가 서비스 모듈(41050)은 트리거 모듈로서, URI 스트링 값을 파악하여 전술한 TPT(TDO Parameters Table) 를 획득할 수 있다. 이를 통해 전술한 대로 트리거, TPT 및 TDO 를 이용한 부가 서비스의 제공이 이루어질 수 있다.
도 42는 제2 스크린 시나리오를 위한 시스템 아키텍쳐의 일 실시예이다.
제2 스크린 지원을 위하여 몇몇 요구사항이 있을 수 있다. 1) 수신기는 하나 혹은 그 이상의 제2 스크린 디바이스와 연결할 수 있다. 2) 제2 스크린 디바이스는 랩탑, 태블릿, 스마트 폰, PDA 등의 휴대 기기가 대상일 수 있다. 3) 제2 스크린의 주요 컨텐트들은 HTML, 텍스트, 비디오, 오디오 등이 될 수 있다. 4) 제2 스크린에서 재생이 되는 컨텐트들은 프라이머리 디바이스(수신기)의 방송 프로그램에 방해가 되지 않게 설계할 수 있다. 5) 제2 스크린은 직접으로 ATSC 2.0 수신기에 연결될 수 있으며 간접적으로는 3GPP망과 같이 우회하여 접속도 가능할 수 있다. 6) 제공자가 특정 컨텐트가 제2 스크린에서만 보여질 수 있도록 시그널링을 할 수도 있다. 7) 경우에 따라, 수신기에서 재생이 가능한 컨텐트도 제2 스크린에서 재생이 가능하게 설계할 수 있다. 8) 인증(Authentication) 및 허가(Authorization)된 제2 스크린에서 제2 스크린 서비스를 이용할 수 있다. 9) 제2 스크린 콘텐츠의 청중 사용량(audience usage)을 측정하게 할 수 있다. (이 경우 이와 같은 정보를 얻기 위하여 사용자에게 동의를 얻어야 할 수 있고, 그 정보를 보고할 수 있는 기능이 있을 수 있다.) 10) 제2 언어 또는 콘텐츠 인핸스먼트(Content Enhancement)할 수 있는 장치를 통하여 제공할 수도 있다.
본 명세서는 방송되는 프로그램과 동기된 콘텐츠를 갖는 제2 스크린 디바이스(스마트 폰, 태블릿, 랩탑 등) 상에서 실행되는 애플리케이션에 의한 A/V 방송에 관련된 콘텐츠의 디스플레이를 지원하기 위하여 수신기에 의해 제공될 수 있는 서비스를 기술할 수 있다. 서비스에 대한 설명은 UPnP 디바이스 아키텍쳐에 기반하여 쓰여졌다.
이 명세서에서 ATSC 2.0 수신기라 함은 TV 수신기 또는 일반적인 수신기를 의미할 수 있다. 또한 DVB, ATSC 등에서의 수신기를 의미할 수 있다.
The UPnP 디바이스 아키텍쳐는 서비스를 제공하는 "피제어 디바이스" 및 그 서비스를 이용하는 "제어 포인트" 간의 IP 네트워크에서의 통신을 위한 프로토콜을 정의한다. "제2 스크린" 시나리오에서, TV 수신기는 "피제어 디바이스"의 역할을 하고 제2 스크린 디바이스는 "제어 포인트"의 역할을 수행할 수 있고, 그 반대일 수 있다.
UPnP 디바이스 아키텍쳐는 관심있는 피제어 디바이스를 찾는 제어 포인트를 위한 "탐색" 프로토콜, 피제어 디바이스 및 서비스에 대한 세부사항을 학습하는 제어 포인트를 위한 "기술(description)" 프로토콜, 피제어 디바이스 상의 "액션들"(방법들)을 인보크(invoke)하는 제어 포인트를 위한 "제어" 프로토콜 및 제어 포인트로 비동기 통지를 전달하는 피제어 디바이스를 위한 "이벤팅(eventing)" 프로토콜을 특정한다. 액션들 및 이벤트들은 디바이스 서비스에 의해 제공될 수 있다.
UPnP 피제어 디바이스가 네트워크에 합류하면, "잘 알려진" IP 멀티캐스트 어드레스 및 포트에 디스커버리 메시지를 멀티캐스트할 수 있다. 이들 메시지는 디바이스에 의해 제공되는 디바이스 타입 및 서비스 타입을 식별할 수 있고 디바이스 및 서비스의 기술을 얻을 수 있는 URL을 제공할 수 있다.
UPnP 제어 포인트가 네트워크에 합류하면, 피제어 디바이스에게 자신을 알릴지를 묻는 서치(search) 메시지를 멀티캐스트할 수 있다. 서치 메시지는 관심있는 디바이스 타입 및/또는 서비스 타입을 특정할 수 있다. 관련 디바이스는 제어 포인트로 유니캐스트 디스커버리 메시지를 보냄으로써 응답할 수 있다.
제어 포인트가 관심있는 디바이스 및 서비스에 대한 디스커버리 메시지를 얻으면, 메시지 내의 URL을 이용하여 디바이스 및 서비스의 기술(description)을 요청할 수 있다. 이들 기술은 액션을 인보크하고 서비스에 대한 이벤트를 신청(subscribe to)하는데 사용될 수 있는 URL을 포함할 수 있다.
일반적인 제2 스크린 탐색 시나리오는 크게 시나리오 A 및 시나리오 B로 나누어 볼 수 있다. 시나리오 A의 경우, 사용자는 TV 수신기가 (TV 수신기가 온될 때 또는 그 네트워크 인터페이스가 인에이블될 때 아마도 발생하는) 네트워크에 합류할 때 자신의 제2 스크린 디바이스에서 실행되는 제2 스크린 애플리케이션을 갖는다. 시나리오 B의 경우, 사용자는 TV 수신기가 네트워크에 합류할 때 자신의 제2 스크린 디바이스에서 실행되는 제2 스크린 애플리케이션을 갖지 않는다.
시나리오 A는 다음과 같을 수 있다. 1) 제2 스크린 지원을 제공하는 TV 수신기는 네트워크에 합류한다. 2) TV 수신기는 그 제2 스크린 지원 서비스를 광고하는 디스커버리 메시지를 멀티캐스트한다. 3) 제2 스크린 디바이스에서 실행되는 제2 스크린 애플리케이션은 멀티캐스트된 디스커버리 메시지를 수신하고 TV 수신기에 그 서비스의 기술에 대한 요청을 전송한다. 4) TV 수신기는 그 서비스의 기술로 응답한다. 5) 제2 스크린 애플리케이션은 기술 내에 포함되는 정보를 이용하여 적절한 서비스를 액세스하고 TV 프로그래밍과 동기된 인터랙티브 경험을 제공한다.
시나리오 B 는 다음과 같을 수 있다. 1) TV 수신기 상에서 보고 있는 TV 프로그래밍은 제2 스크린 지원을 제공하는 프로그램 세그먼트에 들어간다. (이것은 TV 수상기가 온되자 마자 또는 채널이 제2 스크린 지원을 갖는 인터랙티브 데이터 서비스를 제공하지 않는 채널로부터 인터랙티브 데이터 서비스를 제공하는 채널로 변경될 때 또는 보고 있는 채널이 제2 스크린 지원을 갖는 인터랙티브 데이터 서비스를 제공하지 않는 프로그램 세그먼트로부터 인터랙티브 데이터 서비스를 제공하는 프로그램 세그먼트로 변경될 때일 수 있다.) 2) 이것은 TV 수신기가 제2 스크린 지원이 이용가능한 임의의 방식으로, 예를 들어, 스크린의 코너에 있는 작은 아이콘에 의해, 사용자에게 알리도록 한다. 3) 시청자는 제2 스크린 지원을 이용하여 자신의 제2 스크린 디바이스 상에서 제2 스크린 애플리케이션을 활성화한다. 그러면, 제2 스크린 애플리케이션은 제2 스크린 지원을 제공하는 장치를 찾는 메시지를 멀티캐스트한다. TV 수신기는 자신의 디스커버리 메시지로 이 메시지에 응답한다. 4) 제2 스크린 애플리케이션이 디스커버리 메시지를 찾으면, TV 수신기에 그 서비스의 기술에 대한 요청을 전송한다. 5) TV 수신기는 그 서비스의 기술로 응답한다. 6) 제2 스크린 애플리케이션은 기술 내에 포함된 정보를 이용하여 적절한 서비스를 액세스하고 TV 프로그래밍과 동기된 인터랙티브 경험을 제공한다.
시나리오 A를 다시 쓰면 다음과 같을 수 있다. 1) 제2 스크린 지원을 제공하는 TV 수상기는 네트워크에 합류한다. (이것은 TV 세트가 온될 때 또는 그 네트워크 인터페이스가 인에이블될 때일 수 있다.) 2) 이것은 TV 수신기가 자신 및 그 제2 스크린 지원 서비스를 광고하는 자신의 디스커버리 메시지를 멀티캐스트하도록 한다. 3) 이 때 사용자가 자신의 제2 스크린 디바이스에서 실행되는 제2 스크린 애플리케이션을 가지면, 애플리케이션은 멀티캐스트된 디스커버리 메시지를 수신하고 단계(7)로 진행한다. 4) TV 수신기 상에서 보고 있는 TV 프로그래밍이 제2 스크린 지원을 제공하는 프로그램 세그먼트로 들어간다. (이것은 TV 수상기가 온되자 마자 또는 채널이 제2 스크린 지원을 갖는 인터랙티브 데이터 서비스를 제공하지 않는 채널로부터 인터랙티브 데이터 서비스를 제공하는 채널로 변경될 때 또는 보고 있는 채널이 제2 스크린 지원을 갖는 인터랙티브 데이터 서비스를 제공하지 않는 프로그램 세그먼트로부터 인터랙티브 데이터 서비스를 제공하는 프로그램 세그먼트로 변경될 때일 수 있다.) 5) 이것은 TV 수신기가 제2 스크린 지원이 이용가능한 임의의 방식으로, 예를 들어, 스크린의 코너에 있는 작은 아이콘에 의해, 사용자에게 알리도록 한다. 6) 시청자가 자신의 제2 스크린 디바이스에서 실행되는 제2 스크린 애플리케이션을 갖고 있지 않은 경우, 시청자는 제2 스크린 지원을 이용하여 자신의 제2 스크린 디바이스 상에서 제2 스크린 애플리케이션을 활성화한다. 그러면, 제2 스크린 애플리케이션은 제2 스크린 지원을 제공하는 장치를 찾는 메시지를 멀티캐스트한다. TV 수신기는 자신의 디스커버리 메시지로 이 메시지에 응답한다. 7) 제2 스크린 애플리케이션이 디스커버리 메시지를 찾으면, TV 수신기에 그 서비스의 기술에 대한 요청을 전송한다. 8) TV 수신기는 그 서비스의 기술로 응답한다. 이들은 트리거 서비스 및 선택적으로 HTTP 프록시 서버 서비스일 것이다. 9) 제2 스크린 애플리케이션은 트리거 서비스의 "이벤팅" 특징을 신청할 것이다. 제공되는 인터랙티브 데이터 서비스의 상호 작용 모델이 직접 실행 모델이면, 모든 트리거가 TV 수신기에 의해 수신될 때 트리거 서비스는 모든 트리거를 제2 스크린 디바이스로 전송할 것이다. 인터랙티브 데이터 서비스의 상호 작용 모델이 TDO 모델이면, 새로운 활성화 트리거의 활성화 시간에 도달할 때마다 트리거 서비스는 활성화 트리거를 제2 스크린 애플리케이션에 전송할 것이다. 10) 제2 스크린 애플리케이션은, 필요에 따라 TDO 및 다른 파일을 인터넷 링크 또는 TV 수신기에 의해 제공된 HTTP 프록시 서버 서비스로부터 다운로드하고 인터랙티브 서비스를 제2 스크림 장치 사용자에게 제공하면서 트리거에 대하여 동작할 것이다. 11) TV 수신기 상의 TV 프로그래밍이 제2 스크린 지원을 갖는 인터랙티브 데이터 서비스를 제공하지 않는 세그먼트로 진행하면, 트리거 서비스는 "널 트리거(null Trigger)"를 제2 스크린 애플리케이션으로 전송하여 제2 스크린 디바이스에 대한 인터랙티브 데이터 서비스가 더 이상 이용가능하지 않다는 것을 알린다. 12) 그 후, 제2 스크린 디바이스의 사용자가 제2 스크린 애플리케이션을 닫거나 제2 스크린 애플리케이션이 실행되도록 놔두어 TV 수신기 상의 프로그래밍이 제2 스크린 지원을 제공하는 다른 세그먼트로 들어갈 때마다 상호 작용을 재개하도록 할 수 있다.
이들 양 시나리오에서, 가정은 홈 네트워크 상에 1보다 많은 TV 수신기를 가질 수 있다. 이 경우, 제2 스크린 애플리케이션은 다수의 상이한 수신기로부터 디스커버리 메시지를 수신할 수 있다. 이런 경우, 제2 스크린 애플리케이션은 (사용자의 결정을 돕기 위하여 기술 메시지로부터의 정보를 디스플레이하면서) 어느 것으로 상호 작용을 할 것인지 사용자에게 물을 수 있다.
제2 스크린 지원을 제공하는 TV 수신기는 제2 스크린 애플리케이션의 사용을 위한 몇 개의 UPnP 서비스를 제공할 수 있다. UPnP 서비스는 수신기로부터 제2 스크린 애플리케이션으로의 "트리거 전달 서비스", 수신기에서 실행되는 DO들 (Declarative Objects) 및 제2 스크린 애플리케이션 간의 "양방향 통신 서비스" 및 "HTTP 프록시 서버 서비스"일 수 있다. 이들 서비스는 구성에 따라 선택적일 수 있다.
이들 서비스는, 다양한 상이한 소스로부터 얻어지고 다양한 상이한 타입의 제2 스크린 디바이스에서 다양한 상이한 동작 환경에서 실행되는 다양한 상이한 타입의 제2 스크린 애플리케이션을 지원하도록 설계될 수 있다.
일반적인 제2 스크린 패키지 애플리케이션 시나리오는 다음과 같다. 1) 제2 스크린 디바이스 상의 제어 포인트는 제1 스크린 장치 상의 패키지 애플리케이션 서비스를 신청한다. 2) 소비자는 제1 스크린 장치 상의 패키지 애플리케이션을 시작한다. 3) 패키지 애플리케이션은 제2 스크린 애플리케이션의 이름 및 제2 스크린 애플리케이션의 URL을 패키지 애플리케이션 서비스에 이용가능하게 한다. 4) 제2 스크린 디바이스 상의 제어 포인트는 동반자(companion) 애플리케이션 이름 및 URL을 수신한다. 5) 제어 포인트는 필요한 소비자 액션을 지시하는 제2 스크린 상의 마커를 설정한다. 6) 소비자는 제2 스크린 애플리케이션 이름을 검토하고 선택한다. 7) 제어 포인트는 지시된 제2 스크린 애플리케이션을 시작한다.
제2 스크린 지원을 제공하는 제1 스크린은 제2 스크린 애플리케이션의 이용을 위해 몇 개의 UPnP 서비스를 제공할 수 있다. UPnP 서비스 중의 하나는 제2 스크린 디바이스 상에서 실행될 동반자 제2 스크린 애플리케이션의 이름 및 URL을 제공하고 있는 "애플리케이션 URL 서비스"이다.
제2 스크린 시나리오에 대한 시스템 아키텍쳐를 설명한다.
제2 스크린 시나리오에 대한 시스템 아키텍쳐는, 방송 시스템(42010), ACR 서버(42020), 방송사 ATSC 2.0 iTV 서버(42030), ATSC 2.0 수신기(42040) 및/또는 제2 스크린 디바이스(42050)를 포함할 수 있다.
방송 시스템(42010)은 일반적인 방송 시스템일 수 있다. 방송 네트워크를 통하여 트리거, A/V, TPT 및/또는 기타 데이터 파일 등을 전달할 수 있다. 트리거의 경우 전술한 대로 DTVCC 를 통해 전달할 수 있다.
ACR 서버(42020)는 방송 컨텐츠에 대한 ACR 관련 데이터를 관리하는 서버로서, 요청 혹은 필요한 경우 ATSC 2.0 수신기(42040)가 인터랙티브 서비스를 획득할 수 있도록 이와 관련된 트리거를 ATSC2.0 수신기(42040) 에 전송할 수 있다. 전술한 ACR 서버와 동일할 수 있다.
방송사 ATSC 2.0 iTV 서버(42030)는, 인터랙티브 서비스를 생성 및 관리하는 서버로서, 이와 연관된 TDO/파일들을 관리하고 이에 대한 정보를 포함하는 TPT(TDO Parameter Table)를 생성 및 관리할 수 있다.
ATSC 2.0 수신기(42040)는, 방송 A/V 및 인터랙티브 서비스와 관련된 트리거 등을 수신하고 이를 이용하여 인터랙티브 서비스를 획득 및 화면 상에 제공할 수 있다. 전술한 수신기와 동일할 수 있다.
제2 스크린 디바이스(42050)는, 제2 스크린 디바이스인 모바일 폰, 태블릿, 랩탑 등을 포함할 수 있다. 전술한 제2 스크린 디바이스와 동일할 수 있다.
트리거는 DTVCC 채널 또는 ACR 프로세스를 통해 ATSC 2.0 수신기(42040)로 전달되거나 방송 인터랙티브 TV (iTV) 서버(42030)로부터 전달될 수 있다. 이들 모두의 경우, 적절한 시간에 트리거는 ATSC 2.0 수신기(42040)로부터 제2 스크린 디바이스(42050)로 전달된다. 본 명세서는 제2 스크린 디바이스(42050)로 전달될 트리거에 대한 메커니즘을 설명한다. 또한 ATSC 2.0 수신기(42040) 상에서 실행되어 제2 스크린 디바이스(42050)와 양방향 통신을 확립하는 DO들에 대한 메커니즘을 설명한다.
인터넷을 통해 이용가능한 애플리케이션 및 다른 파일은, 그 서비스를 제공한다면, 홈 네트워크를 통해, 별도의 3GPP 네트워크를 통해, 또는 ATSC 2.0 수신기(42040) 상의 HTTP 프록시 서버(도면에 도시되지 않음)를 통해 제2 스크린 디바이스(42050)에 의해 검색될 수 있다. 제1 스크린 디바이스 상에서 실행되는 애플리케이션은 방송을 통해 송신되는 애플리케이션 또는 인터넷으로부터 다운로드된 패키지 애플리케이션일 수 있다.
방송에서 FLUTE 세션을 통해서만 이용가능한 애플리케이션 및 다른 파일은, ATSC 2.0 수신기(42040)가 요청시 FLUTE 파일을 전달하는 HTTP 프록시 서버를 제공할 때에만(제2 스크린 디바이스(42050)는 TV 수신기를 포함하지 않는 것으로 가정), 제2 스크린 디바이스(42050)에 의해 검색될 수 있다.
본 명세서는 또한 제2 스크린 디바이스(42050) 상에서의 애플리케이션의 시작을 지원하기 위하여 ATSC 2.0 수신기(42040) 상에서 실행되는 패키지 애플리케이션에 대한 메카니즘을 설명한다.
도 43은 ATSC 2.0 수신기 및 제2 스크린 간의 토폴로지(직접 연결)의 일 실시예이다.
도 43은 ATSC 2.0 수신기와 제2 스크린 디바이스 간의 직접 연결을 설명한다.
ATSC 2.0 수신기 및 제2 스크린 간의 토폴로지(직접 접속)의 일 실시예는, 방송 시스템(43010), 방송사 ATSC 2.0 서버(43020), ATSC 2.0 수신기(43030) 및/또는 제2 스크린 디바이스(43040)를 포함할 수 있다.
방송 시스템(43010)은 방송 시스템(42010)과 동일할 수 있다.
방송사 ATSC 2.0 서버(43020)는 방송사 ATSC 2.0 iTV 서버(42030)와 동일할 수 있다.
ATSC 2.0 Receiver(43030)는 ATSC 2.0 수신기(42040)와 동일할 수 있다.
제2 스크린 디바이스(43040)는 제2 스크린 디바이스(42050)와 동일할 수 있다.
ATSC 2.0 수신기(43030)는 방송망에 연결이 되어 있어서 직접적으로 지상파 방송 수신이 가능할 수 있다. 따라서 ATSC 2.0 수신기(43030)에서는 DTVCC를 통하여 전송이 되는 iTV 메시지의 URL 스트링을 DTVCC 서비스 번호 6에서 추출이 가능할 수 있다. 또한 홈 게이트웨이에 연결이 되어 있어서 언제든지 필요에 따라서 인터넷에 접속이 가능할 수 있다. 그리고 홈네트워크 기술(UPnP)를 이용하여 다른 홈네트워크 내에 연결된 장치들과 통신할 수 있다.
제2 스크린 디바이스(43040)들은 모두 홈 게이트웨이와 연결이 되어 각각의 장치간의 통신이 가능하며, 자유롭게 인터넷 접근 가능할 수 있다. 홈 게이트웨이는 이더넷(Ethernet) 및 Wi-Fi를 지원하는 기능을 모두 갖추고 있을 수 있다.
방송사는 인터랙티브 서비스를 위하여 인터넷에 서버를 두고 부가 서비스를 제공할 수 있다. ATSC 2.0 수신기(43030)나 제2 스크린 디바이스(43040)들이 접속하여 TDO나 모바일 용으로 만들어진 웹페이지를 다운로드 받을 수 있다. ATSC 2.0 수신기(43030)인 경우에는 TV 의 해상도에 맞게 만들어진 웹페이지이며, 제2 스크린 디바이스(43040)인 경우에는 TV와 다르게 해상도 및 지원하는 APIs가 다를 수 있으므로 이에 적합하게 제작될 수 있다.
도 44는 ATSC 2.0 수신기 및 제2 스크린 간의 토폴로지(간접 연결)의 일 실시예이다.
도 44는 ATSC 2.0 수신기 및 제2 스크린 디바이스 간의 간접 연결을 설명한다.
ATSC 2.0 수신기 및 제2 스크린 간의 토폴로지(간접 연결)의 일 실시예는, 방송 시스템(44010), 방송사 ATSC 2.0 서버(44020), 방송사 세션 관리(44030), ATSC 2.0 수신기(44040) 및/또는 제2 스크린 디바이스(44050)를 포함할 수 있다.
방송 시스템(44010)은 방송 시스템(42010)과 동일할 수 있다.
방송사 ATSC 2.0 서버(44020)는 방송사 ATSC 2.0 iTV 서버(42030)와 동일할 수 있다.
방송사 세션 관리(44030)는, 간접 연결에 있어서, 제2 스크린 디바이스(44050)와 ATSC 2.0 수신기(44040) 간의 간접 연결을 관리하는 역할을 할 수 있다.
ATSC 2.0 수신기(44040)는 ATSC 2.0 수신기(42040)와 동일할 수 있다.
제2 스크린 디바이스(44050)는 제2 스크린 디바이스(42050)와 동일할 수 있다.
도 44의 간접 연결은, 제2 스크린 디바이스(44050)들이 홈 게이트웨이를 통하여 ATSC 2.0 수신기(44040)에 연결이 되는 경우가 아닌 3GPP망에 직접 연결되어 홈 네트워크에 있는 ATSC 2.0 수신기(44040)와 연결이 되는 경우일 수 있다. 이 경우에는 제2 스크린 디바이스(44050)가 홈 네트워크에 연결이 어려울 때나 혹은 홈 네트워크를 지원하는 네트워크 인터페이스가 없을 경우에 해당된다.
이 경우에는 제2 스크린 디바이스(44050)들은 외부의 인터넷 서버가 가지고 있는 ATSC 2.0 수신기(44040)의 정보가 필요할 수 있다. 또한 ATSC 2.0 수신기(44040)는 동작시에 접속 주소를 외부에 있는 인터넷 서버에 보고하여 알려야 할 수 있다.
제2 스크린 디바이스 상에 인터랙티브 서비스를 효과적으로 전달하기 위한 방안으로서 중앙집중형(centralized) 실행 모델 및 분산형(distributed) 실행 모델이 존재할 수 있다.
도 45는 제2 스크린 서비스 애플리케이션의 소프트웨어 층의 일 실시예를 나타내는 도면이다.
제2 스크린 디바이스는 일반적으로 OS들을 이용하여 애플리케이션을 실행한다. 일반적으로, 모바일 장치용 OS들의 일부의 기능은 경량화의 목적으로 포함되지 않을 수 있다. 따라서, OS들에 의해 지원되지 않는 기능들이 애플리케이션에 포함될 필요가 있다.
도 45의 소프트웨어층은 제2 스크린 서비스에 필요한 제2 스크린 서비스 애플리케이션의 소프트웨어 구조를 나타낸다. 도 45는 수신기가 제2 스크린 애플리케이션의 라이프사이클을 관리하는 경우를 나타낼 수 있다.
제2 스크린 디바이스가 인터넷 콘텐츠를 재생하므로, OS는 플랫폼 SDK를 이용하여 웹 애플리케이션이 실행될 수 있는 환경을 프로그래머에게 제공할 수 있다. 환경은 OS에 의해 실행되는 애플리케이션이 인터넷 콘텐츠를 디스플레이하도록 SDK의 형태로 제공될 수 있다.
도 45에서, 제2 스크린 서비스 애플리케이션은 제2 스크린 디바이스 상에서 실행될 수 있다. 이 애플리케이션은 앱스토어(AppStore) (또는 임의의 종류의 애플리케이션 마켓)로부터 다운로드될 수 있다. 제2 스크린 서비스 애플리케이션은 ACR 클라이언트를 포함할 수 있고 마이크로폰 및 카메라를 이용하여 TV 수상기로부터 비디오 및 오디오 데이터를 캡쳐할 수 있다. 또한, ACR 클라이언트는 비디오 및 오디오 데이터를 샘플링하고 미디어 시그니쳐를 ACR 서버로 전송할 수 있다. 제2 스크린 서비스 애플리케이션은 OS 상에서 실행될 수 있고 UPnP 프레임워크가 무엇을 동작시킬 수 있느냐에 따라 HTTP, SSDP 또는 멀티캐스트 이벤트 등의 프로토콜을 포함하고, 브라이저 모듈은 웹 애플리케이션을 수행 및 디스플레이하기 위하여 포함될 수 있다.
브라우저 모듈은 인터넷 웹 페이지를 렌더링하는 모듈일 수 있다. 브라우저 모듈은 웹 애플리케이션(예를 들어, ECMAScript, HTML 및 XHTML)을 렌더링하는 웹 브라우저 엔진의 핵심 부분이다. 또한, 브라우저 모듈은 OS에 의해 제공되는 브라우저와 동일하거나 유사한 기능을 제공하는 소프트웨어 모듈을 의미할 수 있다. 브라우저 및 제어가능한 기능을 이용하는 방법은 OS에 따라 다르다.
제2 스크린 애플리케이션은 제2 스크린 디바이스용으로 설계된 웹 애플리케이션일 수 있다. 제2 스크린 애플리케이션은 ECMAScript 또는 웹 애플리케이션에 따라 기능을 호출하는 웹 애플리케이션일 수 있고, 그 사이즈는 모바일 OS에 의해 제공되는 브라우저 모듈에서 실행되도록 제어될 수 있다. 이 웹 애플리케이션은 제2 스크린 서비스 애플리케이션에서 실행될 수 있다.
모바일 장치용 오퍼레이팅 시스템은 하드웨어를 지원하는 드라이버로 구성될 수 있고 커널 특정(kernel-specific) 서비스용 드라이버를 포함할 수 있다. 기본적으로, IP, TCP 및 UDP 프로토콜을 지원할 수 있다. 네트워크 프로토콜 스택은 OS 상에 존재한다. UPnP의 경우, HTTP는 UDP를 이용하여 송신될 수 있다.
UPnP DCP 프레임워크는 UPnP 포럼에 정의된 디바이스 제어 포인트를 의미할 수 있다.
SSDP (Simple Service Discovery Protocol)는 홈 네트워크에서 네크워크에 접속된 디바이스에 따라 하나 이상의 서비스를 찾을 수 있다.
도 46은 제2 스크린 서비스 애플리케이션의 소프트웨어층을 나타내는 도면이다.
도 46의 소프트웨어층은 제2 스크린 서비스에 필요한 제2 스크린 서비스 애플리케이션의 소프트웨어 구조를 나타낸다. 도 46은 제2 스크린 서비스 애플리케이션이 제2 스크린 애플리케이션의 라이프사이클을 관리하는 경우를 나타낼 수 있다.
도 46의 각각의 엔티티의 설명은 그 역할 및 기능에 있어서 도 45와 동일하다.
ATSC 2.0 트리거 클라이언트는 상술한 트리거, TPT, AMT 등을 수신하고 처리하는 모듈을 의미할 수 있다. 이 모듈은 상황에 따라 제2 스크린 디바이스에 포함될 수 있다. 이 모듈이 제2 스크린 디바이스에 포함된다면, 이 모듈은 TPT 및 AMT를 직접 처리하여 애플리케이션의 라이프사이클을 직접 체크할 수 있다.
도 47은 제2 스크린 애플리케이션 라이프사이클 관리에 따른 송신 순서 및 송신된 데이터 간의 차를 나타내는 테이블을 나타내는 도면이다.
수신기는 방송 네트워크를 통해 DTVCC를 이용하여 TPT 및 AMT를 직접 수신하거나 인터넷 네트워크를 통해 TPT 및 AMT를 다운로드하고 TPT 및 AMT를 처리한다. 상술한 바와 같이, TPT는 이벤트 정보를 포함하고, 이벤트 정보는 EventId, Action, Destination 및 Data 정보를 포함할 수 있다. "Event@Destination"는 이 이벤트 정보가 발생하는 장치를 나타낼 수 있다. 예를 들어, 목적지는 수신기 또는 제2 스크린 디바이스일 수 있다. 목적지가 제2 스크린 디바이스로 설정되면, 수신기는 제2 스크린 디바이스에 이벤트 정보를 전달해야 한다.
따라서, 이 정보를 제2 스크린 디바이스로 전달하는 방법이 필요하다. 제2 스크린 애플리케이션의 라이프사이클은 수신기 또는 제2 스크린 서비스 애플리케이션에 의해 관리될 수 있다.
도 47의 테이블은 어떤 엔티티가 제2 스크린 애플리케이션의 라이프사이클을 지원하느냐에 따른 정보 전달 방법의 개요를 나타낸다.
제1 행은 도 51의 후술하는 경우의 설명의 개요일 수 있고 그 상세한 설명은 후술한다.
제2행은 수신기가 제2 스크린 애플리케이션의 라이프사이클을 관리하는 경우의 설명의 개요일 수 있고 그 상세한 설명은 후술한다.
제3행은 수신기가 제2 스크린 디바이스에 필요한 트리거 정보를 필터링(증가)하고 전달하는 경우의 설명의 개요일 수 있고 그 상세한 설명은 후술한다.
제4행은 도 58의 후술하는 경우의 설명의 개요일 수 있고 그 상세한 설명은 후술한다.
제5행은 도 57의 후술하는 경우의 설명의 개요일 수 있고 그 상세한 설명은 후술한다.
도 48은 중앙집중형 실행 모델의 동작 개념을 나타내는 도면이다.
인터랙티브 서비스를 제2 스크린 디바이스에 효율적으로 전달하는 방법은 중앙집중형 실행 모델 및 분산형 실행 모델을 포함할 수 있다.
중앙집중형 실행 모델의 동작 개념을 나타내는 도면에 도시된 바와 같이, TV 수상기는 UPnP의 RUI 메커니즘을 이용하여 각 제2 스크린 디바이스 상에 디스플레이될 RUI를 생성 및 업데이트하고 네트워크를 통해 RUI를 송신할 수 있다. 각각의 제2 스크린 디바이스는 RUI 클라이언트를 통해 실시간으로 RUI를 수신하고 스크린 상에 RUI를 디스플레이할 수 있다. 분산형 실행 모델과 달리, DAE는 프라이머리 디바이스에 존재할 수 있다.
도 49는 분산형 실행 모델 기반 수신기와 제2 스크린 간의 연동에 대한 플로우의 일 실시예이다.
도 49의 플로우는 중앙집중형 실행 모델의 동작 개넘의 실시예에서 수신기가 방송 네트워크를 통해 인터랙티브 서비스를 얻을 수 있고 제2 스크린 디바이스와 연동하는 환경에서 중앙집중형 실행 모델 메커니즘이 적용될 때의 동작일 수 있다.
중앙집중형 실행 모델 기반 수신기 및 제2 스크린 간의 연동에 대한 플로우의 실시예는 시간 베이스 트리거를 전송하는 단계(s49010), TPT를 요청하는 단계(s49020), 응답으로서 TPT를 송신하는 단계(s49030), TPT를 파싱(parse)하는 단계(s49040), 제2 스크린에 대한 실행 트리거를 전송하는 단계(s49050), TDO들/파일들을 다운로드하는 단계(s49060), RUI를 생성하는 단계(s49070), RUI 프로토콜을 통해 RUI를 전송하는 단계(s49080), 스크린 상에 UI를 디스플레이하는 단계 (s49090), 사용자가 새로운 페이지에 대한 링크를 클릭하는 단계(s49100), 입력 데이터를 전송하는 단계(s49110), 새로운TDO/파일을 다운로드하는 단계(s49120), RUI를 업데이트하는 단계(s49130), RUI 프로토콜을 통해 RUI를 전송하는 단계(s49140) 및/또는스크린 상에 UI를 디스플레이하는 단계(s49150)를 포함할 수 있다.
시간 베이스 트리거를 전송하는 단계(s49010)는 수신기가 DTVCC 또는 ACR 서버를 통해 시간 베이스 트리거를 수신하는 단계를 포함할 수 있다. 시간 베이스 트리거는 상술하였다.
TPT를 요청하는 단계(s49020)는 수신기가 수신된 트리거를 해석하는 단계, TPT를 획득할 수 있는 서버의 URL을 획득하는 단계 및 TPT를 요청할 수 있는 단계를 포함할 수 있다.
응답으로서 TPT를 송신하는 단계(s49030)는 TPT를 요청하는 단계(S49020)에서의 요청에 응답하여 TPT를 송신하는 단계를 포함할 수 있다.
TPT를 파싱하는 단계(s49040)는 수신기가 요청된 TPT를 파싱하는 단계를 포함할 수 있다.
제2 스크린에 대한 실행 트리거를 전송하는 단계(s49050)는 수신기가 DTVCC 또는 ACR 서버를 통해 제2 스크린에 대한 실행 트리거를 수신하는 단계를 포함할 수 있다. 실행 트리거는 상술한 활성화 트리거와 동일할 수 있다.
TDO들/파일들을 다운로드하는 단계(s49060)는 수신기가 수신된 TPT로부터 실행 트리거 또는 시간 베이스 트리거와 연관된 TDO들 및 파일들에 관한 정보를 획득하는 단계 및 콘텐츠 서버로부터 트리거로 지시된 TDO들 및 파일들을 다운로드하는 단계를 포함할 수 있다.
RUI를 생성하는 단계(s49070)는 다운로드된 TDO들 및 파일들에 대한 RUI를 생성하는 단계를 포함할 수 있다.
RUI 프로토콜을 통해 RUI를 전송하는 단계(s49080)는 수신기가 RUI 프로토콜을 이용하여 제2 스크린 상에 생성된 RUI를 송신하는 단계를 포함할 수 있다.
스크린 상에 UI를 디스플레이하는 단계(s49090)는 제2 스크린 상에 수신된 RUI를 디스플레이하는 단계를 포함할 수 있다
사용자가 새로운 페이지에 대한 링크를 클릭하는 단계(s49100)는 제2 스크린 상에서 사용자의 선택에 의해 RUI 상의 특정 링크를 클릭하는 단계를 포함할 수 있다.
입력 데이터를 전송하는 단계(s49110)는 클릭된 특정 링크가 다른 페이지에 접속되면 수신기로 사용자의 입력 정보를 전달하는 단계를 포함할 수 있다
새로운 TDO/파일을 다운로드하는 단계(s49120)는 수신기가 사용자 입력과 연관된 TDO들 및 파일들을 다운로드하는 단계를 포함할 수 있다.
RUI를 업데이트하는 단계(s49130)는 다운로드된 TDO들 및 파일들에 따라 RUI를 업데이트하는 단계를 포함할 수 있다.
RUI 프로토콜을 통해 RUI를 전송하는 단계는 수신기가 RUI 프로토콜을 이용하여 업데이트된 RUI를 제2 스크린으로 송신하는 단계를 포함할 수 있다.
스크린 상에 UI를 디스플레이하는 단계(s49150)는 제2 스크린 상에 업데이트된 RUI를 디스플레이하는 단계를 포함할 수 있다.
도 50은 수신기에서 제2 스크린 디바이스에 UI 정보를 알리는 방법의 실시예를 나타내는 도면이다.
도 50은 수신기가 방송사로부터 트리거를 수신하고 트리거를 제2 스크린 디바이스로 전달하는 논리적 순서를 나타낸다.
이 프로세스는 수신기에 대한 트리거를 수신하는 단계 (s50010), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020), 업데이트된 UI 정보에 대한 통지를 전송하는 단계(s50030), 업데이트된 UI 정보를 요청하는 단계(s50040), 응답으로서 호환가능한 UI 정보를 송신하는 단계(s50050) 및 수신기에 대한 다른 트리거를 수신하는 단계(s50060)를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s50010)는 프라이머리 디바이스가 방송 스트림을 통해 방송사로부터 수신기, 즉, 프라이머리 디바이스에 대한 트리거를 수신하는 단계를 포함할 수 있다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)는 프라이머리 디바이스가 방송 스트림을 통해 방송사로부터 제2 스크린 서비스에 대한 트리거를 수신하는 단계를 포함할 수 있다.
업데이트된 UI 정보에 대한 통지를 전송하는 단계(s50030)는 업데이트된 UI에 대하여 통지하는 단계를 포함할 수 있다. 상술한 바와 같이, 방송 프로그램을 보는 동안 트리거가 수신되면, 수신기는 트리거가 제2 스크린 디바이스 또는 프라이머리 디바이스에 대한 것인지를 체크할 수 있다. 이 때, 트리거가 제2 스크린 디바이스에 대한 것이면, 모든 UPnP 디바이스 또는 특정 UPnP 디바이스에만 새로운 UI 정보 업데이트를 통지할 수 있다. 이것은 제2 스크린 디바이스가 UPnP 프로토콜을 이용하여 가입된 경우에 해당할 수 있다.
업데이트된 UI 정보를 요청하는 단계(s50040)는 제2 스크린 디바이스가 프라이머리 디바이스에게 업데이트된 UI 정보를 요청하는 단계를 포함할 수 있다.
응답으로서 호환가능한 UI 정보를 송신하는 단계(s50050)는 프라이머리 디바이스가 제2 스크린 디바이스로 호환가능한 UI 정보를 송신하는 단계를 포함할 수 있다.
수신기에 대한 다른 트리거를 수신하는 단계(s50060)는 수신기에 대한 트리거를 수신하는 단계와 동일할 수 있다. 즉, 상술한 동작이 다시 수행될 수 있다.
수신기가 트리거 모듈을 포함할 수 있으므로, 수신기는 방송 네트워크 또는 인터넷 네트워크를 통해 TPT 및 AMT 등의 XML 파일을 수신하고, XML 파일을 파싱하고 적절한 동작을 수행할 수 있다. 제2 스크린 디바이스를 찾으면, 제2 스크린 디바이스로 전달되는 액션, TDO URL 및 데이터는 Event@Destination 필드를 이용하여 인식될 수 있다. 제2 스크린 디바이스는 TPT 및 AMT 등의 XML 파일을 직접 수신하지 않을 수 있고, 따라서, 트리거 모듈을 포함하지 않을 수 있다. RemoteUI 클라이언트 서비스가 포함되면, 수신기는 모든 제2 스크린 애플리케이션의 라이프사이클을 관리할 수 있다. 반대로, 몇 개의 제2 스크린 디바이스가 접속되면, 제2 스크린 애플리케이션을 제어하는 데이터가 수 회 송신되어야 한다.
도 51은 수신기에서 제2 스크린 디바이스에 UI 정보를 통지하는 방법의 실시예를 나타내는 도면이다.
도 50과 달리, 도 51은 제2 스크린 디바이스에 적절하게 사용되는 것으로 결정된 제2 스크린 디바이스에 대한 모든 UI 정보가 직접 전달되는 경우를 나타낸다. 즉, 제2 스크린 디바이스에 대한 TDO URL이 송신될 수 있다.
이 프로세스는 수신기에 대한 트리거를 수신하는 단계(s51010), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s51020), UI 정보에 대하여 통지하는 단계(s51030), 응답 "ok"을 전송하는 단계(s51040), 수신기에 대한 트리거를 수신하는 단계(s51050), 수신기에 대한 트리거를 수신하는 단계(s51060), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s51070), UI 정보에 대하여 통지하는 단계(s51080) 및/또는 응답 "ok"를 전송하는 단계(s51090)를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s51010)는 수신기에 대한 트리거를 수신하는 단계(s50010)와 동일할 수 있다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s51020)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다.
UI 정보에 대하여 통지하는 단계(s51030)는 UI 정보 업데이트에 대하여 통지하는 단계를 포함할 수 있다.
응답 "ok"을 전송하는 단계(s51040)는 UI 통지가 수신되었다는 것을 나타내는 메시지를 송신하는 단계를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s51050) 및 수신기에 대한 트리거를 수신하는 단계(s51060)는 수신기에 대한 트리거를 수신하는 단계(s50010)와 동일할 수 있다. 즉, 상술한 동작은 다시 수행될 수 있다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s51070)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 즉, 상술한 동작이 다시 수행될 수 있다.
UI 정보에 대하여 통지하는 단계(s51080)는 UI 정보에 대하여 통지하는 단계(s51030)와 동일할 수 있다. 즉, 상술한 동작이 다시 수행될 수 있다.
응답 "ok"을 전송하는 단계(s51090) 응답 "ok"를 전송하는 단계(s51040)와 동일할 수 있다. 즉, 상술한 동작이 다시 수행될 수 있다.
도 51의 방법에서, 수신기는 어떤 UPnP 디바이스가 제2 스크린 디바이스인지 및 어떤 디바이스 프로파일이 포함되는지를 알아야 한다. 특히, 수신기는 제2 스크린 디바이스가 제2 스크린 서비스를 지원하는지를 알아야 한다.
트리거가 제2 스크린 디바이스 또는 프라이머리 디바이스에 관한 것인지를 결정한 후에 UI 정보에 대하여 통지하는 방법 및 제2 스크린 디바이스에 적절하게 사용되는 것으로 결정된 제2 스크린 디바이스에 대한 모든 UI 정보를 전달하는 방법(도 51의 경우)은 수신기가 TPT 및 트리거를 처리하고 TDO URL만을 제2 스크린 디바이스로 전달한다는 점에서 동일할 수 있다. 이들 2개의 방법은 수신기가 TDO를 제2 스크린 디바이스로 간접적으로 전달하거나 수신기가 각 디바이스의 디바이스 프로파일을 직접 기록하고 제2 스크린 디바이스에만 제2 스크린 애플리케이션의 위치를 통지한다는 점에서 다를 수 있다.
도 52는 RemoteUI 서버 서비스에 대한 방송 시그널링의 실시예를 나타내는 도면이다.
RemoteUI 서버 서비스에 대한 방송 시그널링의 일 실시예는 UPnP 디바이스 및 서비스 디스커버리 단계(s52010), UIListing을 요청하는 단계(s52020), UIListing을 전송하는 단계(s52030), 이벤트를 신청하는 단계(s52040), HTTP 메시지를 반환하는 단계(s52050), UIListingUpdate 메시지를 전송하는 단계(s52060), UIListing을 요청하는 단계(s52070) 및/또는 UIListing을 반환하는 단계(s52080)를 포함할 수 있다.
UPnP 디바이스 및 서비스 디스커버리 단계(s52010)는 수신기 및 제2 스크린 디바이스를 찾는는 단계를 포함할 수 있다. 홈 네트워크에 새로 접속된 디바이스 또는 홈 네트워크에 이미 접속된 디바이스(수신기 또는 제2 스크린 디바이스)는 디스커버리를 위한 메시지를 멀티캐스트할 수 있다. 이 때, 원하는 서비스가 멀티캐스팅을 이용하여 탐색될 수 있고, 복수의 불특정 UPnP 디바이스에 대하여 모든 서비스가 탐색될 수 있다. 이것은 디바이스에 의해 어떤 서비스가 제공되느냐에 따라 변경될 수 있다. 이 단계에서, 제2 스크린 디바이스는 프라이머리 디바이스의 디바이스 프로파일을 알고 있을 수 있다. 프라이머리 디바이스는 디바이스 프로파일을 처리하고 적절한 UIListing을 생성할 수 있다. RemoteUI 서버는 CompatibleUIs XSD 스키마(schema)를 제2 스크린 디바이스에 제공할 수 있다. 이 스키마는 애플리케이션의 URL, UI에 대한 고유 id("uiID"), 이름, protocolInfo 등을 포함할 수 있다.
UIListing를 요청하는 단계(s52020)는 제2 스크린 디바이스가 자신의 디바이스 프로파일을 송신하는 단계 및 UIListing을 요청하는 단계를 포함할 수 있다. 호환가능한 UI를 얻을 수 있는 GetCompatibleUIs 액션이 사용될 수 있다 (UIFilter는 선택적일 수 있다). 그 상세한 설명은 후술한다.
UIListing를 전송하는 단계(s52030)는 프라이머리 디바이스가 요청에 따라 적절한 UI 리스팅을 제2 스크린 디바이스로 송신하는 단계를 포함할 수 있다. 그 상세한 설명은 후술한다.
이벤트를 신청하는 단계(s52040)는 프라이머리 디바이스의 적절한 노출된 이벤트를 신청하는 단계를 포함할 수 있다. 이벤트를 신청하는 단계(s52040)는 RemoteUI 서버 서비스에 의해 제공된 이벤트 정보인 "UIListingUpdate" 를 수신하기 위하여 선택적으로 수행될 수 있다. In UIListing를 반환하는 단계(s52080)에서, 제2 스크린 디바이스는 RemoteUI의 어드레스가 변경되었거나 UI가 변경되었다는 것을 통지받을 수 있다. 즉, 제2 스크린 디바이스가 UI가 변경되었다는 것만을 통지받으므로, 상세한 위치 또는 추가의 정보가 요구되면, "GetCompatibleUIs" 액션이 수신기에 송신되어 "UIListing" 값을 얻을 수 있다.
HTTP 메시지를 반환하는 단계(s52050)는 이벤트를 신청하는 단계(s52040)의 결과를 전송하는 단계를 포함할 수 있다. 응답1을 전송하는 단계(s40100)와 유사하게, HTTP/1.1 200 OK 등의 응답이 상황에 따라 전송될 수 있다.
UIListingUpdate 메시지를 전송하는 단계(s52060)는 가입자에게 "UIListingUpdate" 메시지를 송신하는 단계를 포함할 수 있다.
UIListing를 요청하는 단계(s52070)는 제2 스크린 디바이스가 자신의 디바이스 프로파일을 송신하는 단계 및 UIListing를 요청하는 단계를 포함할 수 있다. 호환가능한 UI를 얻을 수 있는 GetCompatibleUIs 액션이 사용될 수 있다. UIListingUpdate 메시지를 전송하는 단계(s52060) 및 UIListing을 요청하는 단계(s52070)는 제2 스크린 애플리케이션이 변경되지 않고 서버에 의해 지원될 때에만 선택적으로 가능하도록 시간 설정을 수행하는 단계를 포함할 수 있다. 이 단계는 선택적이다. 이 방법은 수신기에서 UPnP 이벤트를 이용하여 제2 스크린 서비스가 존재한다는 것을 모든 제2 스크린 디바이스에 통지하는 방법일 수 있다. 즉, 홈 네트워크 내의 모든 제2 스크린 디바이스는 제2 스크린 서비스와 관련하여 UI가 변경되었다는 것을 통지받을 수 있다. 모든 제2 스크린 디바이스가 UPnP 이벤트를 이용하여 "UIListingUpdate" 변수를 통지받으면, 제2 스크린 디바이스는 UI가 새롭게 업데이트되었다는 것을 확인할 수 있다. 그 후, 제2 스크린 디바이스는 "GetCompatibleUIs" 액션을 수행하고, 하드웨어 장치에 적합한 UI를 선택하고 디바이스 프로파일을 참고함으로써 UI를 실행할 수 있다.
UIListing를 반환하는 단계(s52080)는 프라이머리 디바이스가 요청에 따라 적절한 UI 리스팅을 제2 스크린 디바이스로 송신하는 단계를 포함할 수 있다. 상술한 바와 같이, UIListing를 반환하는 단계(s52080)는 RemoteUI의 어드레스가 변경되었거나 UI가 변경되었다는 것을 신청한 제2 스크린 디바이스에 통지하는 단계를 포함할 수 있다. 즉, 제2 스크린 디바이스가 UI가 변경되었다는 것만을 통지받으므로, 상세한 위치 또는 추가의 정보가 요구되면, "UIListing"을 얻기 위하여 "GetCompatibleUIs" 액션이 수신기에 송신되어야 한다.
RemoteUI 서버 서비스가 동작하면, 수신기는 요청하는 장치의 디바이스 프로파일에 따라 원격 UI 정보를 제공해야 한다. 역호환성의 관점으로부터, 디바이스 프로파일 "DeviceInfo"이 교환되고 후에 수신기에 "GetCompatibleUIs" 액션을 요청할 때 RemoteUI 서버 서비스에 의해 전송된 URL이 요청하는 클라이언트의 프로파일에 따라 변경될 수 있다. 레가시 UPnP 디바이스가 RemoteUI 서버에 "GetCompatibleUIs" 액션을 요청하면, 레가시 UPnP 디바이스의 DeviceInfo에 적합한 UI가 제공되어야 한다. 그러나, 제2 스크린 서비스를 지원하는 디바이스가 "GetCompatibleUIs" 액션을 요청하면, RemoteUI 서버 서비스 장치는 또한 URL 정보를 송신해야 한다.
수신기는 DTVCC를 통해 트리거 정보를 얻고 트리거 정보로부터 미디어 시간 및 이벤트 시간 정보를 얻을 수 있다. 이 때, "appID", "URL"(TDO_URL), "eventID", "action" 및, 선택적으로 , TDO 또는 실행 시간에 대한 "Data"는 "t=media_time" 신택스를 이용하여 확인될 수 있다. 수신기가 제2 스크린 애플리케이션의 라이프사이클을 관리하면, 제2 스크린 서비스 애플리케이션에 의해 처리될 정보의 양이 감소될 수 있다. 반대로, 제2 스크린 서비스 애플리케이션이 제2 스크린 애플리케이션의 라이프사이클을 직접 관리하면, 필요한 정보가 증가될 수 있다.
도 53은 분산형 실행 모델의 동작 개념을 나타내는 도면이다.
제2 스크린 디바이스에 인터랙티브 서비스를 효율적으로 전달하는 방법으로서, 분산형 실행 모델을 설명한다.
분산형 실행 모델의 동작 개념을 나타내는 도면에 도시된 바와 같이, TV 수상기는 UPnP 등을 이용하여 제2 스크린 디바이스로 트리거 등의 정보를 전달할 수 있다. 각각의 제2 스크린 디바이스는 트리거 핸들러를 갖고 트리거 핸들러를 통해 수신된 트리거 등의 정보를 실시간으로 처리할 수 있다. 브라우저는 그와 연관된 인터랙티브 서비스를 실행할 수 있다.
중앙집중형 실행 모델과 달리, 각 제2 스크린 디바이스에 DAE에 존재할 수 있다.
분산형 실행 모델에 기초하여 제2 스크린 디바이스로 인터랙티브 서비스를 전달하는 프로세스는 다음의 순서로 수행될 수 있다. 1. 수신기는 제2 스크린 지원을 갖는 세그먼트를 제시하고 있다. 2. 수신기는 제2 스크린 지원이 이용가능한 임의의 지시를 디스플레이한다. 3. 사용자는 제2 스크린 디바이스 상에서 제2 스크린 애플리케이션을 개시한다. 4. 수신기 및 제2 스크린 디바이스는 (수신기 상의 네이티브 코드 및 디바이스 상의 제2 스크린 애플리케이션에 의해 수행되는) UPnP 메커니즘을 통해 서로를 발견한다. 5. TV 수상기는 (DTVCC 스트림 또는 ACR로부터) 트리거를 얻어 제2 스크린 디바이스 상에서 TDO를 개시한다. 6. TV 수상기는 트리거를 TPT로부터의 정보와 결합하고 활성화 시간에 제2 스크린 디바이스로 전송한다. 7. 제2 스크린 디바이스는 TDO (하나 이상의 파일)을 다운로드하여 브라우저에서 실행한다. 8. 사용자는 TDO와 상호 작용하여 TDO가 추가의 파일을 다운로드하도록 할 수 있다. 9. 수신기는 트리거를 얻어 제2 스크린 디바이스 상에서 TDO에 대한 이벤트를 생성한다. 10. 수신기는 트리거와 TPT로부터의 정보를 결합하여 활성화 시간에 제2 스크린 디바이스로 전송한다. 11. 제2 스크린 디바이스는 브라우저에서 TDO에 대한 (DVB StreamEvent 같은) TriggerEvent 를 생성한다. 12. TDO는 TriggerEvent에 의해 요청된 액션을 수행하여 데이터 파일(들)을 다운로드할 수 있다.
도 54는 분산형 실행 모델 기반 수신기 및 제2 스크린 간의 연동에 대한 플로우를 나타내는 도면이다.
분산형 실행 모델의 플로우는 수신기가 DTVCC 또는 ACR 서버를 통해 수신된 정보를 그대로 제2 스크린으로 송신하는 경우의 데이터 플로우일 수 있다. 이하, 상세한 플로우를 설명한다.
분산형 실행 모델 기반 수신기 및 제2 스크린 간의 연동에 대한 플로우의 실시예는 시간 베이스 트리거를 전송하는 단계(s54010), 시간 베이스 트리거를 전송하는 단계(s54020), TPT를 요청하는 단게(s54030), TPT 를 응답으로서 송신하는 단계(s54040), TPT를 파싱하는 단계(s54050), 제2 스크린에 대한 실행 트리거를 전송하는 단계(s54060), 실행 트리거를 전송하는 단계(s54070), TDO들/파일들을 다운로드하는 단계(s54080), 브라우저에서 TDO를 실행하는 단계(s54090), 사용자가 새로운 페이지에 대한 링크를 클릭하는 단계 (s54100), 새로운 TDO/파일을 다운로드하는 단계(s54110) 및 브라우저에서 새로운 TDO를 실행하는 단계(s54120)를 포함할 수 있다.
시간 베이스 트리거를 전송하는 단계(s54010)는 시간 베이스 트리거를 전송하는 단계(s49010)와 동일할 수 있다.
시간 베이스 트리거를 전송하는 단계(s54020)는 수신기가 수신된 트리거를 그대로 제2 스크린으로 송신하는 단계를 포함할 수 있다.
TPT를 요청하는 단계(s54030)는 제2 스크린이 수신된 트리거를 해석하는 단계, TPT를 획득할 수 있는 서비스의 URL을 확득하는 단계 및 TPT를 요청할 수 있는 단계를 포함할 수 있다.
응답으로서 TPT 를 송신하는 단계(s54040)는 TPT를 요청하는 단계(s54030)에서의 요청에 응답하여 TPT를 송신하는 단계를 포함할 수 있다.
TPT를 파싱하는 단계(s54050)는 요청된 TPT를 파싱하는 단계를 포함할 수 있다.
제2 스크린에 대한 실행 트리거를 전송하는 단계(s54060)는 제2 스크린에 대한 실행 트리거를 전송하는 단계(s49050)와 동일할 수 있다
실행 트리거를 전송하는 단계(s54070)는 수신기가 수신된 트리거를 그대로 제2 스크린으로 송신하는 단계를 포함할 수 있다.
TDO들/파일들을 다운로드하는 단계(s54080)는 TPT 로부터의 트리거와 연관된 TDO들/파일들을 얻는 단계 및 콘텐츠 서버로부터 TDO들/파일들을 다운로드하는 단계를 포함할 수 있다.
브라우저에서 TDO를 실행하는 단계(s54090)는 다운로드된 TDO들 및 파일들을 브라우저 상에서 실행하는 단계를 포함할 수 있다.
사용자가 새로운 페이지에 대한 링크를 클릭하는 단계(s54100)는 사용자가 실행된 TDO 상에서 특정 링크를 클릭하는 단계를 포함할 수 있다.
새로운TDO/파일을 다운로드하는 단계(s54110)는 다른 TDO로의 특정 링크가 확립되면 연관된 TDO/파일을 다운로드하는 단계를 포함할 수 있다.
브라우저에서 새로운 TDO를 실행하는 단계(s54120)는 브라우저 상에서 연관된 TDO 및 파일을 실행하는 단계를 포함할 수 있다.
도 55는 분산형 실행 모델 기반 수신기 및 제2 스크린 간의 연동에 대한 플로우를 나타내는 도면이다.
분산형 실행 모델의 플로우는 수신기가 DTVCC 또는 ACR 서버를 통해 수신된 정보를 그대로 제2 스크린으로 송신하지 않고 제2 스크린에 적합한 트리거에 따라 필요한 정보를 삽입하고, 그 정보를 확장된 트리거로 변경하고, 그 정보를 제2 스크린으로 송신하는 경우의 데이터 플로우일 수 있다. 이하, 상세한 플로우를 설명한다.
분산형 실행 모델 기반 수신기 및 제2 스크린 간의 연동에 대한 플로우의 실시예는 시간 베이스 트리거를 전송하는 단계(s55010), TPT를 요청하는 단계(s55020), 응답으로서 TPT 를 송신하는 단계(s55030), TPT를 파싱하는 단계(s55040), 제2 스크린에 대한 실행 트리거를 전송하는 단계 (s55050), 확장된 트리거를 생성하는 단계(s55060), 확장된 트리거를 전송하는 단계(s55070), TDO들/파일들을 다운로드하는 단계(s55080), 브라우저에서 TDO를 실행하는 단계(s55090), 사용자가 새로운 페이지에 대한 링크를 클릭하는 단계(s55100), 새로운TDO/파일을 다운로드하는 단계(s55110) 및/또는 브라우저에서 새로운 TDO를 실행하는 단계(s55120)를 포함할 수 있다.
시간 베이스 트리거를 전송하는 단계(s55010)는 시간 베이스 트리거를 전송하는 단계(s54010)와 동일할 수 있다.
TPT를 요청하는 단계(s55020)는 TPT를 요청하는 단계 (s54030)와 동일할 수 있다.
응답으로서 TPT를 송신하는 단계(s55030)는 응답으로서 TPT를 송신하는 단계(s54040)와 동일할 수 있다.
TPT를 파싱하는 단계(s55040)는 TPT를 파싱하는 단계 (s54050)와 동일할 수 있다.
제2 스크린에 대한 실행 트리거를 전송하는 단계(s55050) 제2 스크린에 대한 실행 트리거를 전송하는 단계(s54060)와 동일할 수 있다.
확장된 트리거를 생성하는 단계(s55060)는 수신기가 TPT 로부터의 트리거와 연관된 TDO들 및 파일들에 관한 정보를 획득하는 단계 및 그를 포함하는 확장된 트리거를 생성하는 단계를 포함할 수 있다.
확장된 트리거를 전송하는 단계(s55070)는 수신기가 확장된 트리거를 제2 스크린으로 송신하는 단계를 포함할 수 있다.
TDO들/파일들을 다운로드하는 단계(s55080)는 TDO들/파일들을 다운로드하는 단계(s54080)와 동일할 수 있다.
브라우저에서 TDO를 실행하는 단계(s55090)는 브라우저에서 TDO를 실행하는 단계(s54090)와 동일할 수 있다.
사용자가 새로운 페이지에 대한 링크를 클릭하는 단계(s55100)는 사용자가 새로운 페이지에 대한 링크를 클릭하는 단계(s54100)와 동일할 수 있다.
새로운TDO/파일을 다운로드 하는 단계(s55110)는 새로운TDO/파일을 다운로드 하는 단계(s54110)와 동일할 수 있다.
브라우저에서 새로운 TDO를 실행하는 단계(s55120)는 브라우저에서 새로운 TDO를 실행하는 단계 (s54120)와 동일할 수 있다.
도 56은 수신기가 제2 스크린 디바이스에 TDO 및 이벤트 정보를 통지하는 방법의 일 실시예를 나타내는 도면이다.
도 56은 수신기가 트리거 및 TPT를 수신하고 트리거에 따라 처리를 수행하고 제2 스크린 디바이스에 대한 트리거가 도달하면 트리거를 TPT 와 비교하고 제2 스크린 디바이스에 인식될 필요가 있는 정보를 추출하여 XML 파일의 형태로 구성하고 그 정보를 제2 스크린 디바이스로 송신하는 방법을 나타낸다. 이 방법은 제2 스크린 디바이스가 활발히 동작하여 예측을 수행할 수 있다는 점에서 유리할 수 있다.
이 프로세스는 수신기에 대한 트리거를 수신하는 단계(s56010), 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s56020), TPT 및 트리거를 변환(translate)하고 이벤트 정보를 생성하는 단계(s56030), TDO 및 이벤트 정보를 전송하는 단계(s56040), 응답 "ok"를 전송하는 단계(s56050), 수신기에 대한 트리거를 수신하는 단계(s56060), 수신기에 대한 트리거를 수신하는 단계(s56070), 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s56080), TPT 및 트리거를 변환하고 이벤트 정보를 생성하는 단계(s56090), TDO 및 이벤트 정보를 전송하는 단계(s56100) 및 응답 "ok"를 전송하는 단계(s56110)를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s56010)는 수신기에 대한 트리거를 수신하는 단계(s50010)와 동일할 수 있다.
제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s56020)는 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다.
TPT 및 트리거를 변환하고 이벤트 정보를 생성하는 단계(s56030)는 TPT 및 트리거를 해석하는 단계 및 이벤트를 생성하는 단계를 포함할 수 있다. 생성된 정보는 새로운 데이터 구조를 생성하기 위하여 TPT에 포함된 정보 및 트리거를 결합하는데 사용될 수 있고 어떤 TDO가 생성되었는지 또는 언제 TDO가 생성되었는지에 대한 정보를 포함할 수 있다. 이 데이터 구조는 후술한다. 새로운 데이터 구조가 결정되면, TDO URL에 더하여 다양한 필요한 정보가 송신될 수 있다.
TDO 및 이벤트를 전송하는 단계(s56040)는 생성된 이벤트 정보 및 TDO를 제2 스크린 디바이스로 송신하는 단계를 포함할 수 있다.
응답"ok"를 전송하는 단계(s56050)는 수신된 TDO 및 이벤트 정보가 수신되었다는 것을 나타내는 메시지를 송신하는 단계를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s56060) 및 수신기에 대한 트리거를 수신하는 단계(s56070)는 수신기에 대한 트리거를 수신하는 단계(s50010)와 동일할 수 있다.
제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s56080)는 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다.
TPT 및 트리거를 변환하고 이벤트 정보를 생성하는 단계(s56090) TPT 및 트리거를 변환하고 이벤트 정보를 생성하는 단계(s56030)와 동일할 수 있다.
TDO 및 이벤트 정보를 전송하는 단계(s56100)는 TDO 및 이벤트 정보를 전송하는 단계(s56040)와 동일할 수 있다.
응답"ok"를 전송하는 단계(s56110)는 응답"ok"를 전송하는 단계(s56050)와 동일할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s56060), 수신기에 대한 트리거를 수신하는 단계(s56070), 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s56080), TPT 및 트리거를 변환하고 이벤트 정보를 생성하는 단계(s56090), TDO 및 이벤트 정보를 전송하는 단계(s56100) 및 응답 "ok"를 전송하는 단계(s56110)는 상술한 동작과 동일할 수 있다.
도 57은 제2 스크린 디바이스가 TPT 및 제2 스크린 애플리케이션을 액세스하는 방법의 실시예를 나타내는 도면이다.
제2 스크린 디바이스는 수신기가 TPT 및 AMT 등의 XML 파일을 수신하거나 인터넷을 통해 TPT 및 AMT 서버 어드레스를 알면 제2 스크린 애플리케이션을 직접 실행할 수 있는 독립 장치이다. 이 경우, 트리거 모듈이 제2 스크린 디바이스에 포함된다. 제2 스크린 디바이스는 수신기에 의해 수신된 iTV 메시지에 대한 URI 스트링을 수신할 수 있다. 이 메시지는 1) RemoteUI 서버 서비스의 경우 iTV 메시지(트리거)에 대한 URI 스트링을 송신하는 방법 및 2) RemoteUI 클라이언트 서비스의 경우 iTV 메시지(트리거)에 대한 URI 스트링을 송신하는 방법 모두에 적용될 수 있다.
먼저, RemoteUI 서버 서비스의 경우 iTV 메시지(트리거)에 대한 URI 스트링을 송신하는 방법을 설명한다.
이 프로세스는 수신기에 대한 트리거를 수신하는 단계(s57010), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s57020), 업데이트된 UI 정보에 관한 통지를 전송하는 단계(s57030), 업데이트된 UI 정보를 요청하는 단계(s57040), 응답으로서 UI 정보를 송신하는 단계(s57050), TPT XML 파일을 요청하는 단계(s57060), TPT XML 파일을 반환하는 단계(s57070), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s57080), 업데이트된 UI 정보에 대한 통지를 전송하는 단계(s57090), 업데이트된UI 정보를 요청하는 단계(s57100), 응답으로서 UI 정보를 송신하는 단계 (s57110), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s57120), 업데이트된 UI 정보에 대한 통지를 전송하는 단계(s57130), 업데이트된 UI 정보를 요청하는 단계(s57140), 응답으로서 UI 정보를 송신하는 단계(s57150), 제2 스크린 애플리케이션을 요청하는 단계(s57160) 및/또는 제2 스크린 애플리케이션을 반환하는 단계(s57170)를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s57010)는 수신기에 대한 트리거를 수신하는 단계 (s50010)와 동일할 수 있다. 제1 트리거는 제2 스크린 디바이스에 대한 것이 아니므로, 수신기는 트리거를 제2 스크린 디바이스로 전달하지 않는다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s57020)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 트리거는 제2 스크린 서비스에 대한 미디어 시간에 관한 정보를 가질 수 있다. 제2 트리거는 상술한 프리로드(pre-load) 트리거로서 기능할 수 있다.
업데이트된UI 정보에 대한 통지를 전송하는 단계(s57030)는 업데이트된 UI 정보를 통지하는 단계를 포함할 수 있다. 제2 트리거는 제2 스크린 디바이스에 대한 것이므로, 수신기는 수신된 URIString을 제2 스크린 디바이스로 송신할 수 있다. 이 때, 제2 스크린 디바이스는 새로운 정보가 존재한다는 것을 통지 받을 수 있고 이 정보를 직접 판독할 수 있다.
업데이트된 UI 정보를 요청하는 단계(s57040)는 업데이트된 UI 정보를 요청하는 단계(s50040)와 동일할 수 있다.
응답으로서 UI 정보를 송신하는 단계(s57050)는 프라이머리 디바이스가 UI 정보를 제2 스크린 디바이스로 송신하는 단계를 포함할 수 있다. 이 때, 제2 트리거가 송신될 수 있다.
TPT XML 파일을 요청하는 단계(s57060)는 제2 스크린 디바이스가 프라이머리 디바이스로부터 수신된 정보(제2 트리거)를 파싱하는 단계 및 TPT 서버에게 TPT XML 파일을 요청하는 단계를 포함할 수 있다.
TPT XML 파일을 반환하는 단계(s57070)는 제2 스크린 디바이스가 TPT 서버로부터 요청된 TPT XML 파일을 다운로드하는 단계를 포함할 수 있다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s57080)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 제3 트리거는 제2 스크린 디바이스와 연관되고 미디어 시간에 관한 정보를 가질 수 있다. 제3 트리거는 상술한 시간 베이스 트리거와 동일한 기능을 수행할 수 있는 미디어 시간 트리거이다.
업데이트된 UI 정보에 관한 통지를 전송하는 단계(s57090)는 업데이트된 UI 정보를 통지하는 단계를 포함할 수 있다. 제3 트리거가 제2 스크린 디바이스와 연관되는 것으로 결정되므로, 수신기는 제3 트리거를 제2 스크린 디바이스에 통지할 수 있다.
업데이트된 UI 정보를 요청하는 단계(s57100)는 업데이트된 UI 정보를 요청하는 단계(s50040)와 동일할 수 있다.
응답으로서 UI 정보를 송신하는 단계(s57110)는 프라이머리 디바이스가 UI 정보를 제2 스크린 디바이스로 송신하는 단계를 포함할 수 있다. 이 때, 제3 트리거가 송신될 수 있다. 그러나, 제3 트리거는 미디어 시간 트리거이므로, 제2 스크린 디바이스의 미디어 시간만을 제어할 수 있다. 그러므로, 제2 스크린 디바이스 및 수신기 간의 미디어 시간 동기화를 수행할 수 있다.
제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s57120)는 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 제4 트리거는 제2 스크린 디바이스와 연관되고 이벤트 시간에 관한 정보를 가질 수 있다. 제4 트리거는 상술한 활성화 트리거와 동일한 기능을 수행할 수 있는 이벤트 시간 트리거이다.
업데이트된UI 정보에 대한 통지를 전송하는 단계(s57130)는 업데이트된 UI를 통지하는 단계를 포함할 수 있다. 제4 트리거는 제2 스크린 디바이스와 연관되는 것으로 결정되므로, 수신기는 제2 스크린 디바이스에 제4 트리거를 통지할 수 있다.
업데이트된 UI 정보를 요청하는 단계(s57140)는 업데이트된 UI 정보를 요청하는 단계(s50040)와 동일할 수 있다.
응답으로서 UI 정보를 송신하는 단계(s57150)는 프라이머리 디바이스가 UI 정보를 제2 스크린 디바이스로 송신하는 단계를 포함할 수 있다. 이 때, 제4 트리거가 송신될 수 있다.
제2 스크린 애플리케이션을 요청하는 단계(s57160)는 제2 스크린 디바이스가 제4 트리거에 관한 정보를 체크하는 단계 및 TDO URL의 위치의 제2 스크린 애플리케이션을 다운로드하기 위하여 애플리케이션 서버에게 제2 스크린 애플리케이션을 요청하는 단계를 포함할 수 있다.
제2 스크린 애플리케이션을 반환하는 단계(s57170)는 요청에 따라 제2 스크린 애플리케이션을 다운로드하는 단계를 포함할 수 있다. 제2 스크린 애플리케이션이 다운로드되어 Event@Action을 수행할 수 있다. 이 때, 애플리케이션 서버에 제2 스크린 디바이스의 브라우저에 관한 정보를 통지하므로, 애플리케이션 서버는 어떤 제2 스크린 디바이스가 접속되는지를 쉽게 체크할 수 있다. 따라서, 애플리케이션은 자동으로 선택되어 서버로부터 다운로드될 수 있다.
요약하면, iTV 메시지에 대한 URI 스트링이 DTVCC를 통해 수신되면, 수신기는 새로운 UI가 업데이트 되었다는 것을 나타내는 이벤트를 발견된 제2 스크린 디바이스로 송신할 수 있다. 제2 스크린 디바이스는 이벤트 정보를 체크하고 새로운 UI 정보를 얻기 위하여 "GetCompatibleUIs" 액션을 전송할 수 있다. 수신기는 TPT 서버의 수신된 URI 정보를 전송할 수 있다. 이 방법에 의해, 제2 스크린 디바이스는 URI 정보를 수신하고, TPT 및 AMT 정보를 직접 처리하고 제2 스크린 애플리케이션을 직접 제어할 수 있다.
이 프로세스는 ATSC 2.0 트리거 클라이언트가 제2 스크린 서비스 애플리케이션에 포함되는 경우 가능하다.
도 58은 제2 스크린 디바이스가 TPT 및 제2 스크린 애플리케이션을 액세스하는 방법의 실시예를 나타내는 도면이다.
상술한 2개의 방법 중에서, RemoteUI 클라이언트 서비스의 경우 iTV 메시지(트리거)에 대한 URI 스트링을 송신하는 방법을 설명한다.
이 프로세스는 수신기에 대한 트리거를 수신하는 단계(s58010), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s58020), 트리거를 통지하는 단계(s58030), 응답 "ok"를 전송하는 단계(s58040), TPT XML 파일을 요청하는 단계 (s58050), TPT XML 파일을 반환하는 단계(s58060), 제2 스크린 디바이스에 대한 트리거를 수신하는 단계(s58070), 트리거를 통지하는 단계(s58080), 응답 "ok"를 전송하는 단계(s58090), 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s58100), 트리거를 통지하는 단계(s58110), 응답 "ok"를 전송하는 단계(s58120), 제2 스크린 애플리케이션을 요청하는 단계(s58130) 및/또는 제2 스크린 애플리케이션을 반환하는 단계(s58140)를 포함할 수 있다.
수신기에 대한 트리거를 수신하는 단계(s58010)는 프라이머리 디바이스가 방송 스트림을 통해 방송사로부터 수신기, 즉, 프라이머리 디바이스에 대한 트리거를 수신하는 단계를 포함할 수 있다. 제1 트리거가 수신기에 대한 것이므로, 제1 트리거는 제2 스크린 디바이스로 전달되지 않는다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s58020)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 제2 트리거는 제2 스크린 서비스에 대한 트리거이며 미디어 시간에 대한 정보를 가질 수 있다. 제2 트리거는 상술한 프리로드 트리거로서 기능할 수 있다.
트리거를 통지하는 단계(s58030)는 도 57과 달리 제2 스크린 디바이스로 즉시 트리거를 송신하는 단계를 포함할 수 있다. iTV 메시지에 대한 URI 스트링이 DTVCC를 통해 수신되면, 수신기는 "AddUIListing" 액션을 이용하여 수신기에 의해 수신된 URI 값을 제2 스크린 디바이스로 전달할 수 있다.
응답 "ok"을 전송하는 단계(s58040)는 트리거가 수신되었다는 것을 나타내는 메시지를 송신하는 단계를 포함할 수 있다.
TPT XML 파일을 요청하는 단계(s58050)는 TPT XML 파일을 요청하는 단계(s57060)와 동일할 수 있다. 제2 스크린 디바이스에 포함되는 트리거 모듈은 수신된 URI 값을 이용하여 TPT 서버를 액세스하고 TPT 및 AMT 파일을 다운로드하고 제2 스크린 애플리케이션을 직접 제어할 수 있다.
TPT XML 파일을 반환하는 단계(s58060)는 TPT XML 파일을 반환하는 단계(s57070)와 동일할 수 있다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s58070)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 제3 트리거는 제2 스크린 디바이스와 연관되고 미디어 시간에 관한 정보를 가질 수 있다. 제3 트리거는 상술한 시간 베이스 트리거와 동일한 기능을 수행할 수 있는 미디어 시간 트리거이다.
트리거를 통지하는 단계(s58080)는 트리거를 통지하는 단계(s58030)와 유사하게 트리거를 전달하는 단계를 포함할 수 있다.
응답 "ok"를 전송하는 단계(s58090)는 응답 "ok"를 전송하는 단계(s58040)와 동일할 수 있다.
제2 스크린 서비스에 대한 트리거를 수신하는 단계(s58100)는 제2 스크린 서비스에 대한 트리거를 수신하는 단계(s50020)와 동일할 수 있다. 제4 트리거는 제2 스크린 디바이스와 연관되고 이벤트 시간에 관한 정보를 가질 수 있다. 제4 트리거는 상술한 활성화 트리거와 동일한 기능을 수행할 수 있는 이벤트 시간 트리거이다.
트리거를 통지하는 단계(s58110)는 트리거를 통지하는 단계(s58030)와 유사하게 트리거를 전달하는 단계를 포함할 수 있다.
응답 "ok"를 전송하는 단계(s58120)는 응답 "ok"를 전송하는 단계(s58040)와 동일할 수 있다.
제2 스크린 애플리케이션을 요청하는 단계(s58130)는 제2 스크린 애플리케이션을 요청하는 단계(s57160)와 동일할 수 있다.
제2 스크린 애플리케이션을 반환하는 단계(s58140)는 제2 스크린 애플리케이션을 반환하는 단계(s57170)와 동일할 수 있다.
즉, 수신기는 항상 제2 스크린 서비스와 연관된 이벤트 정보를 갖는 트리거를 제2 스크린 디바이스로 전달할 수 있고 제2 스크린 디바이스는 다운로드된 TPT 정보를 이용하여 즉시 동작할 수 있다. 미디어 시간 트리거가 DTVCC를 이용하여 주기적으로 전달되므로, 수신기는 이 정보를 연속적으로 전달해야 한다.
프라이머리 디바이스 또는 제2 스크린 디바이스가 TPT XML을 가지므로, 이벤트 트리거가 라이브 트리거 서버로부터 실시간으로 전송될 때 AMT가 또한 수신될 수 있다.
상술한 2개의 방법은 어떤 URL 값이 적용되는지에 따라 다르게 수행될 수 있고 수신기의 동작 또는 제2 스크린 서비스 애플리케이션의 구조 및 동작은 변경될 수 있다.
제2 스크린 서비스의 시그널링 메커니즘을 설명한다.
제2 스크린 서비스는 2개의 방법, 즉, 수신기가 제2 스크린 서비스가 존재한다는 것을 통지하는 제1 방법 및 제2 스크린 디바이스가 홈 네트워크에 접속되면 제2 스크린 서비스를 제공하는 전자 장치를 검출하기 위하여 장치 및 서비스를 찾는 제2 방법을 이용하여 시그널링될 수 있다. 대안으로, 수신기는 새로운 전자 장치의 디바이스 기술어를 확인하고 서비스 기술어를 요청할 수 있다.
이하에서, 방송 시그널링 및 유니캐스트 시그널링을 설명한다.
방송 시그널링의 경우, 제2 스크린 디바이스는 RemoteUI 서버 서비스를 검출하고, 디바이스 기술어를 확인하고, 제2 스크린 디바이스와 호환가능한 DeviceInfo 프로파일을 요청한다. 이벤트가 수신될 수 있고 수신기를 통해 보는 프로그램에 따라 변경된 TDO(인터랙티브 애플리케이션)의 URL이 수신될 수 있다.
반대로, 유니캐스트 시그널링의 경우, 수신기는 제2 스크린 디바이스의 DeviceInfo가 호환가능한지를 확인하고 호환가능한 TDO URL을 송신할 수 있다. RemoveUIListing 액션은, 현재 실행되는 제2 스크린 애플리케이션을 종료하여 디스플레이 메시지 등의 액션을 지원하고 현재 실행되는 UI를 종료하도록 송신될 수 있다. 수신기에 의해 파싱되고 처리되는 추가의 Event@data가 ProcessInput 액션에 의해 제2 스크린 서비스 애플리케이션으로 전달될 수 있다.
이하, 방송 시그널링 및 유니캐스트 시그널링을 설명한다.
도 59는 RemoteUI 서버 서비스에 대한 방송 시그널링의 다른 실시예이다.
방송 시그널링에서, 처음에 수신기가 홈네트워크에 연결이 되면, 스스로 자신의 디바이스 기술어와 서비스 기술어를 모든 가전기기에 알려 주거나, 다른 제어 포인트에 의하여 요청을 받아 전송할 수 있다.
RemoteUI 서버 서비스에 대한 방송 시그널링의 다른 실시예는, UPnP 디바이스 및 서비스 디스커버리 단계(s59010), UIListing를 전송하는 단계(s59020), UIListing를 전송하는 단계(s59030), UIListing를 요청하는 단계(s59040) 및/또는 UIListing를 반환하는 단계(s59050)를 포함할 수 있다
UPnP 디바이스 및 서비스 디스커버리 단계(s59010)는 UPnP 디바이스 및 서비스 디스커버리 단계(s58010)와 동일한 단계일 수 있다.
UIListing를 전송하는 단계(s59020)는 "UIListingUpdate" 메시지를 모든 UPnP 디바이스로 전송하는 단계일 수 있다. 프라이머리 디바이스는 UIListingUpdate의 어나운스먼트(announcement)를 고유 "uiID" 리스트를 갖는 UPnP 디바이스로 전송할 수 있다. 제2 스크린 디바이스는 이 메시지를 받은 후 uiID를 체크할 수 있다. 그러나 특정 uiID 와 매칭되지 않아, 이 제2 스트림 장치에서는 UI 업데이트가 이뤄지지 않을 수 있다.
UIListing를 전송하는 단계(s59030)는, "UIListingUpdate" 메시지를 모든 UPnP 디바이스로 전송하는 단계일 수 있다. 이번에는 UIListing를 전송하는 단계(s59020)의 경우와는 달리 매칭되는 uiID가 존재할 수 있다.
UIListing를 요청하는 단계(s59040)는, UIListing를 전송하는 단계(s59030)에서 uiID가 매칭되므로, 제2 스크린 디바이스가 자신의 디바이스 프로파일을 전송하며 UIListing을 요청할 수 있다. 호환가능한 UI를 얻을 수 있는 GetCompatibleUIs 액션을 이용할 수 있다.
UIListing를 반환하는 단계(s59050)는 프라이머리 디바이스가 제2 스크린 디바이스로 요청에 따른, 적절한 UI Listing 을 전송하는 단계일 수 있다.
도 60은 제2 스크린 서비스를 위한 장치 디스커버리 및 장치 능력 교환의 일 실시예이다.
전술한 대로, 처음에 수신기가 홈네트워크에 연결이 되면, 스스로 자신의 디바이스 기술어와 서비스 기술어를 모든 가전기기에 알려 주거나, 다른 제어 포인트에 의하여 요청을 받아 전송할 수 있다.
수신기의 디바이스 기술어와 서비스 기술어를 수신한, 모든 홈네트워크에 접속한 UPnP 디바이스들은, 자신의 디바이스 기술어의 위치를 HTTP의 "LOCATION" 헤더로 보낼 수 있다. 즉, UPnP 디바이스 기술어의 위치를 전송해서 자신을 알려줄 수 있다. "LOCATION"으로 HTTP GET 요청을 하면 해당 장치에 대한 정보를 알 수 있는 XML 파일을 받을 수 있다.
UPnP 디바이스 및 서비스 디스커버리 과정에서, 프라이머리 디바이스가 제2 스크린 서비스가 가능한 제2 스크린 디바이스를 찾는 방법을 소개한다. 이 방법은 크게 2가지로 나뉠 수가 있는데, 첫번째는 제2 스크린 디바이스가 두 가지의 디바이스 프로파일을 준비해 두고 이 디바이스 프로파일의 XML 파일을 HTTP 헤더로 알려 주는 방법일 수 있다. 이 때, 호환되지 않는 프라이머리 디바이스는 이해하지 못하는 HTTP 헤더는 그대로 무시한다고 가정할 수 있다. 두 번째로는 디바이스 프로파일 중, 제2 스크린 서비스를 제공하는 제2 스크린 디바이스라는 정보를 "Protocol Info"에 포함하는 것일 수 있다.
도 60의 도면은 첫번째 방식을 예시하는 것일 수 있다.
제2 스크린 서비스에 대한 장치 디스커버리 및 장치 능력 교환의 일 실시예는, 제2 스크린 서비스에 대한 UPnP 애플리케이션을 실행하는 단계(s60001), UPnP 디바이스를 찾는 단계(s60010), RemoteUIClient를 찾는 단계(s60020), 디바이스 기술을 요청하는 단계(s60030), 디바이스 기술을 수신하는 단계(s60040), 서비스 제어 기술(description)을 요청하는 단계(s60050), 서비스 제어 기술을 수신하는 단계(s60060), 디바이스 프로파일을 요청하는 단계(s60070), 디바이스 프로파일을 수신하는 단계(s60080), 원격 UI의 URL을 보내는(put) 단계(s60090), 응답1을 전송하는 단계(s60100), RemoteUI 클라이언트 서비스에 메시지를 전송하는 단계(s60110), 응답2를 전송하는 단계(s60120) 및/또는 사용자가 스크린 상의 버튼을 클릭하는 단계(s60130)를 포함할 수 있다.
제2 스크린 서비스에 대한 UPnP 애플리케이션을 실행하는 단계(s60001), UPnP 디바이스를 찾는 단계(s60010), RemoteUIClient를 찾는 단계(s60020), 디바이스 기술을 요청하는 단계(s60030), 디바이스 기술을 수신하는 단계(s60040), 서비스 제어 기술을 요청하는 단계(s60050), 서비스 제어 기술을 수신하는 단계(s60060), 디바이스 프로파일을 요청하는 단계(s60070), 디바이스 프로파일을 수신하는 단계(s60080), 원격 UI의 URL을 보내는(put) 단계(s60090), 응답1을 전송하는 단계(s60100), RemoteUI 클라이언트 서비스로 메시지를 전송하는 단계(s60110), 응답2를 전송하는 단계(s60120) 및 사용자가 스크린 상의 버튼을 클릭하는 단계(s60130)는, 각각 순서대로, 제2 스크린 서비스에 대한 UPnP 애플리케이션을 실행하는 단계(s40001), UPnP 디바이스를 찾는 단계(s40010), RemoteUIClient를 찾는 단계 (s40020), 디바이스 기술을 요청하는 단계 (s40030), 디바이스 기술을 수신하는 단계(s40040), 서비스 제어 기술을 요청하는 단계(s40050), 서비스 제어 기술을 수신하는 단계(s40060), 디바이스 프로파일을 요청하는 단계(s40070), 디바이스 프로파일을 수신하는 단계(s40080), 원격 UI의 URL을 보내는(put) 단계 (s40090), 응답1을 전송하는 단계(s40100), RemoteUI 클라이언트 서비스로 메시지를 전송하는 단계(s40110), 응답2를 전송하는 단계(s40120) 및 사용자가 스크린 상의 버튼을 클릭하는 단계 (s40130)와 동일한 단계일 수 있다.
첫번째 방식은 도 60 에서와 같이 UPnP 디바이스를 찾는 단계(s60010) 단계 이후에 HTTP 헤더에서 얻는 "X-ATSC-COMPANION-LOCATION" 헤더로 제2 스크린 서비스를 지원하는 디바이스 프로파일의 위치를 알려 주는 방식일 수 있다. X-ATSC-COMPANION-LOCATION: 라고 표시된 부분이 "X-ATSC-COMPANION-LOCATION" 헤더이다. 수신기는 "LOCATION" 헤더는 무시하고 대신 "X-ATSC-COMPANION-LOCATION" 헤더를 보고 수신기가 원하는 정보인 제2 스크린 디바이스의 디바이스 프로파일을 얻어 올 수 있다.
프라이머리 디바이스가 제2 스크린 서비스가 가능한 제2 스크린 디바이스를 찾는 방법 중, 전술한 두번째 방식은 "LOCATION" 헤더의 위치에서 디바이스 프로파일을 얻고 디바이스 프로파일 내에서 제2 스크린 디바이스의 "Protocol Info" 엘리먼트의 값을 파싱하여 처리하는 것일 수 있다. 이는 전술한 RemoteUI 서버 서비스 #1에 대한 방송 시그널링의 일 실시예 중, UIListing 요청(s58020) 단계에서 이루어질 수 있다.
특정 UPnP 디바이스의 디바이스 기술어에는 제공할 수 있는 서비스의 리스트들이 있으며 하나 혹은 복수개의 서비스를 제공한다는 사실을 알 수 있다. UPnP 디바이스가 가지고 있는 각각의 서비스는 원격의 다른 UPnP 디바이스에서 제어가 가능하고 이벤트를 수신할 수 있다. 단, 이벤트 수신은 제공하는 서비스가 이벤트로 알려 줄 수 있는 기능이 있어야만 가능할 수 있다. UPnP 디바이스가 제공하는 서비스들은 "제어", "컨트롤" 그리고 "이벤트"를 할 수 있도록 URL을 알려 줄 수 있다.
도 61은 UPnP 포럼의 DeviceProfile XML 스키마의 일 실시예이다.
전술한 RemoteUI 서버 서비스 #1에 대한 방송 시그널링의 일 실시예 중, UIListing 요청(s58020) 단계에 대해 추가 설명한다. 이 단계는, 제2 스크린 디바이스에서 RemoteUI 서버 서비스가 있는 수신기에게 제2 스크린 디바이스에게 맞는 조건의 UI가 있는지 물어오는 것으로, "InputDeviceProfile" 에는 도 61 과 같은 XSD 파일과 같은 형식을 가져야 할 수 있다.
따라서 제2 스크린 디바이스는 수신기에게 도 61 과 같은 형식으로 자신의 디바이스 프로파일과 맞는 정보를 넣어서 전송해야 할 수 있다.
도 62는 제2 스크린 디바이스의 디바이스 프로파일의 일 실시예이다.
전술한 RemoteUI 서버 서비스 #1에 대한 방송 시그널링의 일 실시예 중, UIListing 요청(s58020) 단계에 대해 추가 설명한다. 이 단계에서, 도 62 는 디바이스 프로파일의 한 예를 도시하고 있다. UIListing 요청(s58020) 단계에서, 도시된 디바이스 프로파일과 같은 정보를 수신기에 보낼 수 있다.
제2 스크린 디바이스가 찾고자하는 디바이스 프로파일의 제2 스크린 서비스가, 수신기에 있는지 검색하는 것으로, 도시된 정보를 "InputDeviceProfile" 변수에 저장하여 전송할 수 있다. 수신기에서는 "InputDeviceProfile" 정보를 확인하고 제공해야 하는 서비스 타입, 버전, 제2 스크린 디바이스의 해상도, 수신기 가능한 이미지 인코딩 방식 등등을 정의할 수 있다.
도 63는 제2 스크린 서비스에 대한 Protocolnfo의 설명의 일 실시예이다.
전술한 RemoteUI 서버 서비스 #1에 대한 방송 시그널링의 일 실시예 중, UIListing를 요청하는 단계(s58020) 및 UIListing를 전송하는 단계(s58030)에 대해 추가 설명한다.
전술한 대로, 수신기에서는 "InputDeviceProfile" 정보를 확인하고 제공해야 하는 서비스 타입, 버전, 제2 스크린 디바이스의 해상도, 수신기 가능한 이미지 인코딩 방식 등등을 정의할 수 있다. "제2 스크린 서비스에 대한 Protocolnfo의 기술의 일 실시예"는 "InputDeviceProfile" 정보의 일 실시예일 수 있다.
도시된 것과 같은 정보를 이용하여 수신기에게 전달했을때(UIListing를 요청하는 단계(s58020)), XML형태로 되어 있는 UILising 정보를 제2 스크린 디바이스로 전송해 준다(UIListing를 전송하는 단계(s58030)).
만약에 RemoteUI 서버 서비스에서 원하는 제2 스크린 디바이스를 지원하지 않는 다른 장치라면, UIListing를 전송하는 단계(s58030)에서 에러 정보를 리턴해 주어 제2 스크린 서비스를 지원할 수 없는 RemoteUI 서버 서비스라는 것을 알 수 있게 할 수 있다.
도 64는 제2 스크린 디바이스에서 AddUIListing 및 RemoteUIListing이 실행되는 동안의 UIListing의 일 실시예이다.
전술한 RemoteUI 서버 서비스 #1에 대한 방송 시그널링의 일 실시예 중, UIListing를 요청하는 단계(s58020) 및 UIListing를 전송하는 단계(s58030)에 대해 추가 설명한다.
UIListing를 요청하는 단계(s58020) 후에, 수신기는 호환이 되는 RemoteUI 정보를 찾아서 요청한 제2 스크린 디바이스에 전달해 줄 수 있다(UIListing를 전송하는 단계(s58030)). UIListing를 전송하는 단계(s58030)에서 수신된 정보는 도 64 에 도시되어 있다.
이 수신된 정보는, 수신기가 제2 스크린에 전송해 줄 때 TPT 및 AMT 를 처리해서 TDO URL를 넣어 주는 것일 수 있다. 따라서 제2 스크린 디바이스는 Remote UI 의 정보만 수신기에서 얻고, 제2 스크린 애플리케이션은 홈네트워크 밖의 인터넷 애플리케이션 서버에서 다운로드 받아 실행할 수 있다. 이때 실행을 하는 것은 제2 스크린 서비스 애플리케이션이 담당할 수 있다.
한편으로는 방송사에서 미리 방송망이나 수신기에게 제2 스크린 디바이스를 위한 제2 스크린 애플리케이션을 전송해 주는 경우도 있을 수 있다. 이 경우에는 수신기가 제2 스크린 서비스를 위한 애플리케이션을 저장해 두었다가 직접 서비스할 수 있다. 이 경우 웹서버가 수신기에서 동작해야 할 수 있고, 관련된 이미지 및 데이터들은 수신기 혹은 홈네트워크가 아닌 외부 애플리케이션 서버에서 다운로드 받을 수 있다. DO가 NDO인 경우에, ATSC-NRT로 NDO 및 관련 리소스 파일들을 방송망으로 전송해 두고 제2 스크린 서비스를 제공할 수 있다.
방송 시그널링의 경우에, 제2 스크린 애플리케이션의 라이프사이클은 수신기 또는 제2 스크린 서비스 애플리케이션이 관리할 수 있다.
첫번째로, 수신기가 제2 스크린 애플리케이션의 라이프 사이클을 관리하는 방법에 대해 설명한다.
수신기는 DTVCC로 전송되는 미디어 시간 트리거의 정보를 처리 후에, 제2 스크린에 관련이 있는 이벤트가 TPT에 존재하고 이 이벤트가 실행이 되어야 할때, 즉시 "UIListingUpdate" 변수를 모든 홈네트워크에 있는 기기에게 알릴 수 있다. 이와 같은 이벤트에 관련이 있어 신청한 기기들은 UI 정보가 업데이트가 되었음을 알고, 필요한 정보를 얻기 위해서 "GetCompatibleUIs" 액션을 수행할 수 있다. 이때 수신기의 RemoteUI 서버에서는 즉시 실행해야 하는 TDO 주소를 넘겨줄 수 있다.
두번째로, 제2 스크린 서비스 애플리케이션이 제2 스크린 애플리케이션의 라이프사이클을 관리하는 방법에 대해 설명한다.
이 경우는 수신기가 수신한 정보를 제2 스크린 디바이스에 전달해주고, 제2 스크린 서비스 애플리케이션이 스스로 동작할 수 있게 할 수 있다. 방송의 경우, 제2 스크린 서비스가 되는 클라이언트가 "GetComaptibleUIs" 액션을 요청하면, 수신기가 직접 DTVCC에서 수신 받은 iTV 메시지(트리거)의 URIString을 리턴해 줄 수 있고, 제2 스크린 디바이스가 수신한 URIString을 이용하여 TPT 파일을 다운로드하여 수신기와 동일하게 TPT를 해석하고 동작할 수 있다. 수신기는 DTVCC로 미디어 시간 트리거나 이벤트 시간 트리거를 수신받을때마다 즉시 "UIListingUpdate" 변수를 변경하여 모든 기기들에게 전송하여 줄 수 있고, 새로운 iTV 메시지(트리거)의 URIString를 받아갈 수 있도록 기기들에게 "GetCompatibleUIs" 액션을 할 수 있게 유도 할 수 있다.
도 65는 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예이다.
전술한 유니캐스트 시그널링에 대하여 설명한다.
이 방법은 제2 스크린 디바이스가 RemoteUIClient 서비스를 장치 내에 내장하고 있는 경우를 말할 수 있다. UPnP 디바이스가 처음에 홈네트워크에 연결이 되면, 스스로 자신의 정보를 통지하여 다른 장치들도 새로운 장치가 홈네트워크에 접속했다는 사실을 알릴 수 있다. 또 다른 방법은 주기적으로 새로운 장치가 있으면 알려 달라는 메시지를 모든 홈네트워크에 연결된 장치들에게 전달해 주면, 모든 홈네트워크에 연결된 장치들은 이 정보에 응답하여 통지(NOTIFY) 메시지를 다시 모든 장치들에게 알릴 수 있다. 먼저, 제2 스크린 디바이스가 제2 스크린 서비스를 지원하는지 여부를 살펴 보아야 할 수 있다.
RemoteUI 클라이언트 서비스에 대한 유니캐스트 시그널링의 일 실시예는, UPnP 디바이스 및 서비스 디스커버리 단계(s65010), 디바이스 프로파일을 요청하는 단계(s65020), 디바이스 프로파일을 반환하는 단계(s65030), TDO URL 정보를 전송하는 단계(s65040), HTTP 메시지를 반환하는 단계(s65050), 디스플레이 메시지를 전송하는 단계(s65060) 및/또는 HTTP 메시지를 전송하는 단계(s65070)를 포함할 수 있다.
UPnP 디바이스 및 서비스 디스커버리 단계(s65010)는, UPnP 디바이스 및 서비스 디스커버리 단계(s58010)와 동일한 단계일 수 있다.
디바이스 프로파일을 요청하는 단계(s65020)는, 수신기가 새로 발견된 제2 스크린 디바이스에게 제2 스크린 서비스를 지원할 수 있는지를 확인하기 위하여 "StaticDeviceInfo" 정보를 전송해 주는 단계일 수 있다.
디바이스 프로파일을 반환하는 단계(s65030)는, 디바이스 프로파일을 요청하는 단계(s65020)에 대한 응답으로서, 제2 스크린 디바이스의 디바이스 프로파일을 얻는 단계일 수 있다. 만약 새롭게 발견된 제2 스크린 디바이스가 보낸 디바이스 프로파일이 "Static DeviceInfo"와 일치하지 않거나, 제2 스크린 디바이스를 지원하지 않는 장치라고 판단된다면, 제2 스크린 서비스를 시작하지 않을 수 있다. "StaticDeviceInfo"는 앞에서 정의한 "DeviceInfo" 와 같을 수 있다. "StaticDeviceInfo" 와 DeviceInfo 정보가 일치되는지는 수신기에서 판단해야 할 수 있다. 만약에 홈네트워크에 새롭게 발견된 제2 스크린 디바이스가 하나 이상일 경우, 이러한 과정은 계속 반복이 되며, 한번 발견된 제2 스크린 디바이스에서 제2 스크린 서비스를 지원하지 않는다고 해서 다시 이러한 과정을 거치지 않는 것은 아니다. 제2 스크린 디바이스에는 하나 이상의 여러 소프트웨어가 설치 및 삭제될 수 있으며 사용자가 실행하는지 여부에 따라서도 이 과정에 대한 결과 값이 달라질 수 있기 때문이다. 제2 스크린 서비스 애플리케이션을 수행해 둔 상태가 되면, TDO URL 정보를 전송하는 단계(s65040)로 넘어가게 될 수 있다.
TDO URL 정보를 전송하는 단계(s65040)는, 수신기가 TPT 및 AMT를 파싱한 결과인 TDO URL 정보를 전송해주는 단계일 수 있다. UPnP RemoteUI 클라이언트 서비스에서 정의된 "AddUIString"을 이용할 수 있다. "AddUIString"는 제2 스크린 디바이스에서 제2 스크린 서비스의 DeviceInfo 정보를 만족한 경우에 실행되는 액션일 수 있다. TDO URL은 하나 혹은 하나 이상의 URL이 될 수도 있다. 하나 이상의 URL 일 경우, 즉시 실행하기 위한 URL을 전송해 줄 수 있다. 이때 선택적으로 디스플레이 메시지를 전송하는 단계(s65060)를 수행할 수 있다.
HTTP를 반환하는 단계(s65050)는 TDO URL 정보를 전송하는 단계(s65040)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
디스플레이 메시지를 전송하는 단계(s65060)는, 제2 스크린 디바이스에 디스플레이 메시지를 전송하는 단계일 수 있다. RemoteUI 클라이언트 서비스는 제2 스크린 디바이스 화면에 메시지를 표시할 수 있는 DisplayMessage 액션을 가지고 있을 수 있으므로 제2 스크린 디바이스에 TDO URL을 전송해 주고 DisplayMessage 액션을 이용해 화면에 현재 시청중인 방송 프로그램과 관련이 있는 제2 스크린 애플리케이션이 있다는 메시지를 표시해 줄 수 있다. 사용자가 이 메시지를 확인하게 되면 바로 제2 스크린 애플리케이션 수행이 될 수 있다.
HTTP 메시지를 반환하는 단계(s65070)는 디스플레이 메시지를 전송하는 단계(s65060)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
도 66는 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예이다.
새로운 UI의 URL들이 제2 스크린 디바이스의 UIListing에 추가될 때마다 제2 스크린 서비스 애플리케이션은 새로운 제2 스크린 애플리케이션을 실행하는 환경을 제공할 수 있다.
도 66의 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예는, 실행중인 제2 스크린 애플리케이션의 수행을 중단하고 새로운 제2 스크린 애플리케이션을 실행하기 위한 순서를 나타낸 것일 수 있다.
RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예는, RemoveUIListing 액션을 전송하는 단계(s66010), HTTP 메시지를 반환하는 단계(s66020), 디스플레이 메시지를 전송하는 단계(s66030), HTTP 메시지를 반환하는 단계(s66040), TDO URL 정보를 전송하는 단계(s66050), HTTP 메시지를 반환하는 단계(s66060), 디스플레이 메시지를 전송하는 단계(s66070) 및/또는 HTTP 메시지를 반환하는 단계(s66080)를 포함할 수 있다.
RemoveUIListing 액션을 전송하는 단계(s66010)는, RemoteUI 클라이언트 서비스에 정의 되어 있는 "RemoveUIListing" 액션을 이용하여 제2 스크린 서비스 애플리케이션에서 실행 중인 제2 스크린 애플리케이션을 중지하는 것일 수 있다. 제2 스크린 서비스 애플리케이션은 수신기에서 현재 수행중인 UI의 애플리케이션 사용 중지를 할때 RemoveUIListing 액션을 보낸다는 것을 알고 있을 수 있다. 따라서 제2 스크린 서비스 애플리케이션은, RemoveUIListing action이 제2 스크린 디바이스에 수신이 되면 즉시 현재 동작하는 제2 스크린 애플리케이션의 동작을 중지해야할 수 있다.
HTTP 메시지를 반환하는 단계(s66020)는 RemoveUIListing 액션을 전송하는 단계(s66010)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
디스플레이 메시지를 전송하는 단계(s66030)는, 제2 스크린 디바이스에 디스플레이 메시지를 보내는 단계일 수 있다. RemoveUIListing 액션을 전송하는 단계(s66010)이 후에, 경우에 따라서는 실행이 중지 된다는 메시지를 제2 스크린 디바이스 화면에 표시해 줄 필요가 있을 수 있다. 이런 경우에는 DisplayMessage 액션을 이용하여 적절한 메시지는 화면에 표시해 줄 수 있다.
HTTP 메시지를 반환하는 단계(s66040)는 디스플레이 메시지를 전송하는 단계(s66030)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
TDO URL 정보를 전송하는 단계(s66050)는, 수신기가 새로 수행될 UI의 TDO URL을 전송해 주기 위하여 AddUIListing 액션을 수행하는 단계일 수 있다. 새로운 제2 스크린 애플리케이션이 수행될 때는, UIListing에 TDO URL이 추가 되자 마자 제2 스크린 서비스 애플리케이션이 실행시킬 수 있다. 참고로 TDO URL은, 수신기에서 직접 다운로드 되어 실행할 수 있는 제2 스크린 애플리케이션에 관한 것일 수도 있고, 부분적인 리소스 데이터만 인터넷 서버에서 다운로드 받아 수행하는 것일 수도 있다. 또한, TDO URL자체가 외부 인터넷 서버 주소를 가르킬 수도 있다. 외부 인터넷 서버 주소를 가르킬 경우에는 제2 스크린 애플리케이션 및 실행에 필요한 모든 데이터들은 인터넷 서버에서 다운로드 받아 실행하게 될 수 있다.
HTTP 메시지를 반환하는 단계(s66060)는 TDO URL 정보를 전송하는 단계(s66050)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
디스플레이 메시지를 전송하는 단계(s66070)는, 제2 스크린 디바이스에 디스플레이 메시지를 보내는 단계일 수 있다. TDO URL 정보를 전송하는 단계(s66050) 이후에, 새로운 제2 스크린 서비스가 실행될 것이라는 메시지를 제2 스크린 디바이스 화면에 표시할 수 있다. 디스플레이 메시지를 전송하는 단계(s66030)와 마찬가지로, DisplayMessage 액션을 이용하여 적절한 메시지는 화면에 표시해 줄 수 있다.
HTTP 메시지를 반환하는 단계(s66080)는 디스플레이 메시지를 전송하는 단계(s66070)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
유니캐스트 시그널링의 경우 또한, 제2 스크린 애플리케이션의 라이프사이클은 수신기 또는 제2 스크린 서비스 애플리케이션이 관리할 수 있다.
첫번째로, 수신기가 제2 스크린 애플리케이션의 라이프사이클을 관리하는 방법에 대해 설명한다.
제2 스크린 서비스 애플리케이션에서는 "URL"(TDO_URL) 정보만 알면 될 수 있다. 따라서 수신기에서 제2 스크린 디바이스에 있는 RemoteUI 클라이언트 서비스에 "AddUIListing" 액션을 수행하여 제2 스크린 디바이스에서 동작할 제2 스크린 애플리케이션을 정해진 시간에 실행하면 될 수 있다. 반대로 제2 스크린 애플리케이션을 중단 시켜야 할 경우에는 "RemoveUIListing" 액션을 수행하여 정해진 시간내에 제2 스크린 애플리케이션을 중단시키면 될 수 있다.
부가적으로 세부적인 시간까지 맞추기 위해서는 URL 외에, TDO를 수행할 미디어 시간 정보까지 주면, 제2 스크린 서비스 애플리케이션이 지정된 시간에 맞추어서 실행할 수 있다. 그러나 미디어 시간은 현재 수신기에서 재생되고 있는 미디어에 대한 상대적인 시간이므로 이 시간은 각 기기들이 이해할 수 있는 절대 시간으로 변경할 필요가 있을 수 있다. NTP(Network Time Protocol) 혹은 다른 시간 정보를 가질 수 있는데, 이 시간에 미래의 시간 정보를 가지는 미디어 시간을 더하면 액션이 수행할 시간이 될 수 있다. 제2 스크린 디바이스에서 액션은 실행과 중지 밖에 없으므로 이는 AddUIListing 및 RemoveUIListing action의 구현에 따라 달라질 수 있다.
두번째로, 제2 스크린 서비스 애플리케이션이 제2 스크린 애플리케이션의 라이프사이클을 관리하는 방법에 대해 설명한다.
제2 스크린 서비스 애플리케이션이 제2 스크린 디바이스에서 동작하는 제2 스크린 애플리케이션을 실행하고 중단하는 시간이나 이벤트에 대한 정보를 알고 있어야 할 수 있다. 그러므로 전술한 바와 같이 제2 스크린 서비스 애플리케이션이 트리거 클라이언트를 포함하고 있고, 수신기가 DTVCC에서 수신된 iTV 메시지(트리거)의 URIString 정보를 수신기의 DeviceInfo (Device Profile)에 맞게 전송하면 될 수 있다.
전송 방법은 크게 2가지로 나뉠 수가 있는데, 첫번째 방법은 DTVCC에서 전송이 되어 수신기에서 처리한 트리거 메시지를 그대로 전송해 주는 방법이 있고, 두 번째 방법은 수신기에서 제2 스크린 디바이스에 필요한 정보만을 다시 정리하여 필요한 정보와 데이터만 XML 형태로 전달해 주는 방법이 있을 수 있다.
첫번째로, 수신기가 트리거를 제2 스크린에 그대로 전달하는 방법에 대해 설명한다.
이 방법은, 수신된 트리거를 그대로 "AddUIListing" 액션을 수행함으로써 처리가 끝날 수 있다. RemoteUI 클라이언트 서비스에서는 이 정보를 가지고 바로 트리거 클라이언트가 처리할 수 있도록 넘겨 주고 트리거 클라이언트는 수신기에서와 같이 TPT를 다운로드 받아 처리할 수 있다. 단, 수신기는 DTVCC에서 미디어 시간 트리거가 수신될 때 마다 제2 스크린 디바이스에 이와 같이 전달해야 할 수 있다. 수신기가 "appID", "eventID" 및 "event@destination"을 확인하고 제2 스크린 디바이스에서 받지 않아도 되는 트리거인 경우에는 스스로 소비하고 제2 스크린 디바이스에는 전달하지 않아도 될 수 있다.
두번째로, 수신기에서 제2 스크린 디바이스에 필요한 트리거 정보를 필터링하여 전달하는 방법에 대하여 설명한다.
이 방법은, 수신기에서 TPT 파일과 트리거를 처리해서 제2 스크린 디바이스가 처리할 데이터를 만들어서 전달해 주는 방법일 수 있다. 이 방법은 제2 스크린 서비스 애플리케이션에서, 트리거 클라이언트가 동작하지 않아도 될 수 있으며, "ProgressInput" action을 통하여 XML 파일을 전송 받아 처리하면 될 수 있다. 즉, 직접 제2 스크린 서비스 애플리케이션이 전체 TPT를 처리하는 것이 아니라 현재 혹은 미래에 처리해야 하는 필요한 데이터만 수신기가 걸러서 주면 이를 처리하면 될 수 있다. 이 방법의 장점은 "Event@Data" 필드가 있는데 이 필드까지도 전달해 줄 수 있다는 점일 수 있다.
도 67는 RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예이다.
도 67은, 전술한 두번째 방법인, "수신기에서 제2 스크린 디바이스에 필요한 트리거 정보를 필터링하여 전달하는 방법"에 대하여 도시한 것일 수 있다.
RemoteUI 클라이언트 서비스를 위한 유니캐스트 시그널링의 일 실시예는, 이벤트 1 정보를 전송하는 단계(s67010), HTTP 메시지를 반환하는 단계(s67020), 이벤트 2 정보를 전송하는 단계 (s67030), HTTP 메시지를 반환하는 단계(s67040), 이벤트 3 정보를 전송하는 단계(s67050) 및/또는 HTTP 메시지를 반환하는 단계(s67060)를 포함할 수 있다.
이벤트 1 정보를 전송하는 단계(s67010)는, 수신기가 제2 스크린 디바이스로 수신한 이벤트 정보를 전달하는 단계일 수 있다. 전술한대로, 수신기에서 TPT 파일과 트리거를 처리해서 제2 스크린 디바이스가 처리할 데이터를 만들어서 전달해 줄 수 있다. 제2 스크린 서비스 애플리케이션에서는, 트리거 클라이언트가 동작하지 않아도 될 수 있으며, "ProgressInput" 액션을 통하여 XML 파일을 전송 받아 처리하면 될 수 있다.
HTTP 메시지를 반환하는 단계(s67020)는 이벤트 1 정보를 전송하는 단계(s67010)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
이벤트 2 정보를 전송하는 단계(s67030)는, 이벤트 1 정보를 전송하는 단계(s67010)와 마찬가지로 이벤트에 대한 정보를 전달해주는 단계일 수 있다. TPT XML 에서와 같이 각 이벤트 별로 데이터를 TDO에 전달해 줄 수 있는데, 이 단계는 이벤트 2 에 대한 정보를 전달해주는 단계일 수 있다.
HTTP 메시지를 반환하는 단계(s67040)는 이벤트 2 정보를 전송하는 단계(s67030)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계 (s40100) 와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
이벤트 3 정보를 전송하는 단계(s67050)는, 마찬가지로, 이벤트 3에 대한 정보를 전달해주는 단계일 수 있다.
HTTP 메시지를 반환하는 단계(s67060)는 이벤트 3 정보를 전송하는 단계(s67050)에 대한 결과를 보내주는 단계일 수 있다. 전술한 응답1을 전송하는 단계(s40100)와 마찬가지로 상황에 따라, HTTP/1.1 200 OK 등의 응답을 보내줄 수 있다.
전술한 두번째 방법의 경우에는 수신기가 제2 스크린 애플리케이션의 라이프사이클을 관리할 수 있다. 제2 스크린 애플리케이션의 라이프사이클은, 제2 스크린 디바이스에서 동작하는 TPT및 AMT 정보들을 파싱하고, 처리하는 과정을 의미할 수 있다.
도 68는 ProcessInput 액션으로 제2 스크린 디바이스에 전달되는 "EventInfo"정보의 일 실시예이다.
도 68은, 전술한 "수신기에서 제2 스크린 디바이스에 필요한 트리거 정보를 필터링하여 전달하는 방법" 에서, 수신기가 TPT 파일과 트리거를 처리해서 제2 스크린 디바이스가 처리할 데이터를 만들어서 전달해 줄 때, 이벤트 정보의 XML 데이터 구조의 일 예시를 도시한 것일 수 있다.
즉, 수신기에서 제2 스크린 애플리케이션의 라이프사이클을 관리해 주는 경우에는, ProcessInput 액션으로는 이벤트 정보는 도 68 의 데이터 구조를 가진 XML 파일로 RemoteUI 클라이언트에 전달될 수 있다. 수신기가 라이브 트리거(Live Trigger)를 받는 경우에도 마찬가지로 라이브 트리거를 처리하여 제2 스크린 디바이스에 실행할 시간과 TDO URL 등의 정보만 전달해 주면 될 수 있다.
도 68의 테이블에서, @appID, URL, Event, @eventID, @action 및 Data 는 수신기가 수신한 트리거 또는 AMT의 정보와 같을 수 있다. 그러나, "@mediaTime", "@startTime" 및 "@endTime"는 수신기에서 특별히 처리해야 할 수 있다. "@mediaTime" 에 맞추어, DTVCC에서 전송된 트리거의 "time=" 신택스의 정보(혹은 AMT의 "@beginMT" 정보)를 처리해서 다시 "@startTime"과 "@endTime"을 결정해야 할 수 있다. 수신기와 제2 스크린 디바이스가 같은 절대 시간 정보(wall clock time)을 사용한다고 볼 수 없으므로, 콘텐츠의 미디어 시간에 맞추어서 제2 스크린 디바이스가 동작하게 하기 위함일 수 있다. 즉, 수신기와 제2 스크린 디바이스 간에 액션에 대한 실행 시작 시간 및 종료 시간에 대한 시간 정보가 실제 NTP(Network Time Protocol)에 맞추어져 있다고 가정한다면, 전송하기 전에 수신기가 변환하는 작업이 이뤄져야 할 수 있다.
전송 지연 및 미디어 시간 추정에 대해 설명한다.
전술한대로 @startTime 과 @endTime은 수신기에서 제2 스크린에 보낼 때 현재의 mediaTime 값을 기준으로 상대적으로 만들어져 전송이 되므로, 전송시에 발생하는 시간 손실은 전송 프로토콜인 HTTP의 헤더에 "Date" 값과 HTTP 응답일 수 있다 도착한 시간 값의 차이를 이용하여, 제2 스크린 디바이스가 자체적으로 조정하여 보다 정확한 시간 값을 찾을 수 있다. 현재 미디어 시간과 @mediaTime 값의 차이는 전송 지연 시간이 되므로 다음과 같은 수식으로 현재 미디어 시간을 얻을 수 있다.
현재 미디어 시간 = 전송 지연 시간(수신시 시간 값-HTTP헤더 "Date" 값) + @mediaTime
이를 통해, 현재 수신기의 현재 미디어 시간 값과 거의 유사하게 유추할 수 있다.
도 69는 수신기와 제2 스크린 디바이스 간의 구성의 일 실시예이다.
수신기와 제2 스크린 디바이스 간의 구성이 도시되어 있다. 수신기가 피제어 디바이스(서버)일 수 있다. 제2 스크린 디바이스가 제어 포인트(클라이언트)일 수 있다.
디스커버리 단계에서, 수신기는 서비스 리스트를 멀티캐스트하여 네트워크에 합류하고, 제2 스크린 애플리케이션은 서비스 리스트에 대한 요청을 멀티캐스트하여 시작될 수 있다.
기술(Description) 단계에서, 제2 스크린 애플리케이션은 수신기의 서비스 기술을 요청할 수 있다.
본 발명에서는, UPnP 를 기반으로 TV 수상기, 즉, 수신기를 통해 수신되는 A/V 방송 콘텐츠와 연관된 인터랙티브 서비스를 제2 스크린 디바이스를 통하여 획득할 수 있도록 하기 위하여 새로운 UPnP 디바이스 및 서비스를 정의할 수 있다.
도 70는 서비스의 서비스 타입 및 서비스 ID의 일 실시예이다.
수신기는 트리거 서비스, 양방향 통신 서비스 및 AppURL 서비스를 지원할 수 있다. 또한, HTTP 프록시 서버 서비스를 지원할 수 있다. 서비스 타입 및 서비스 ID는 도 70에 도시된 바와 같을 수 있다.
양방향 통신 서비스는 제2 스크린 디바이스 내의 애플리케이션과 양방향 통신에 참여하도록 준비된 프라이머리 디바이스에서 실행되는 DO가 존재하는지를 제2 스크린 디바이스가 결정하도록 할 수 있다.
트리거 서비스, AppURL 서비스 및 HTTP 프록시 서버 서비스에 대해서는 후술한다.
도 71는 트리거 전달 서비스의 동작 개념도의 일 실시예이다.
트리거 전달 서비스는, UPnP를 기반으로 TV 수신기에 수신되는 A/V 방송 콘텐츠와 연관된 인터랙티브 서비스를 제2 스크린을 통하여 획득할 수 있도록 하기 위한 서비스를 의미할 수 있다.
도 71 은, 수신기가 DTVCC 혹은 ACR 서버 등으로부터 트리거를 획득하고, 해당 트리거를 그대로 혹은 제2 스크린 디바이스에 적합한 형태로 변형(확장된 트리거)하여 제2 스크린 디바이스에 전송하는 과정을 도시하고 있다.
트리거가 변화할 때마다, 수신기로부터 제2 스크린 디바이스로 해당 트리거 혹은 변형된 확장 트리거를 실시간으로 전송해야 할 수 있다.
도 72는 확장된 활성화 트리거(expanded activation trigger) 생성 과정의 일 실시예이다.
확장된 트리거(확장된 활성화 트리거)는 DTVCC 스트림 혹은 ACR 서버 등으로부터 획득한 트리거와 TPT 내의 정보를 조합하여 생성될 수 있다. 트리거에 포함된 TDO ID와 이벤트 ID, 데이터 ID 그리고 활성화 시간과, TPT 내의 TDO URL, TDO 속성, 이벤트, 액션, 디퓨전(Diffusion) 및 데이터 등의 정보를 조합하여 생성될 수 있다. TDO 내의 정보는 트리거 내의 정보와 연관된 TDO 및 이벤트에 관한 정보일 수 있다.
여기서, 확장된 트리거는 증가된 트리거(augmented trigger)라고도 불릴 수 있다.
도 73는 증가된 활성화 트리거(Augmented Activation Trigger)에 대한 XML 스키마 기술(Schema Description)의 일 실시예이다.
트리거 서비스의 설명서(Specification)에 대해 설명한다.
트리거 서비스는 트리거들을 전달할 수 있다. 트리거들은 (a) ACR 프로세스, (b) 현재 보고 있는 채널의 DTV CC 서비스 #6, (c) 원격 "라이브 트리거" 서버 또는 (d) 활성화 메시지 테이블(AMT)로부터 TV 수상기에 의해 획득될 수 있다. 이것은 상황에 의존한다.
트리거 서비스는 또한 채널이 변경될 때마다 특수 "채널 변경" 트리거를 전달할 수 있다. 채널 변경 트리거에 대해서는 후술한다. 전달될 4가지 타입의 트리거가 기본적으로 존재할 수 있다. 즉, 1) TDO 인터랙티브 서비스 모델을 위한 시간 베이스 트리거, 2) TDO 인터랙티브 서비스 모델을 위한 활성화 트리거, 3) 직접 실행 인터랙티브 서비스 모델을 위한 트리거 및 4) 특수 "채널 변경" 트리거가 존재할 수 있다.
최대의 유연성을 위해, 제2 스크린 디바이스로 모든 타입의 트리거를 전달하는 옵션을 갖고 수신기에서 트리거가 도달하자마자 전달하는 것이 바람직할 수 있다.
그러나, 수신기가 상호 작용을 제공하는 것과 동일한 방식으로 상호 작용을 제공하도록 설계된 제2 스크린 애플리케이션에 대하여, TDO 상호 작용 모델을 위한 시간 베이스 트리거를 생략하고 그 활성화 시간에 TDO 상호 작용 모델을 위한 각 활성화 트리거를 전달하는 것이 바람직할 수 있다. 이것은 시간 베이스를 유지하고 활성화 시간을 산출할 필요성으로부터 이들 제2 스크린 애플리케이션을 구할 수 있다. 이는 또한 트리거로부터의 정보를 트리거에서 참조된 TDO 엘리먼트및 그 이벤트 차일드(child) 엘리먼트에 관한 TPT 로부터의 정보와 결합함으로써 각각의 활성화 트리거를 증가시켜 이들 제2 스크린 애플리케이션이 TPT를 다룰 필요성으로부터 구하는 것이 바람직할 수 있다.
그러므로, 트리거 서비스는 트리거 전달을 위한 2가지 옵션을 제공할 수 있다. 그들 중의 하나는 수신기가 (증가되지 않은) 모든 트리거를 전달하는 "필터링되지 않은 스트림(Unfiltered stream)" 옵션일 수 있다. 다른 하나는 TDO 상호 작용 모델을 위한 증가된 활성화 트리거, TDO 상호 작용 모델 이외의 상호 작용 모델을 위한 모든 트리거 및 특수 채널 변경 트리거만을 전달하는 "필터링된 스트림(Filtered stream)" 옵션일 수 있다.
TDO 상호 작용 모델을 위한 각각의 증가된 활성화 트리거를 위한 타겟 전달 시간은 그 활성화 시간일 수 있다. (필터링되지 않은 스트림 옵션에서 증가 없이 전달된 활성화 트리거를 포함하는) 모든 다른 트리거에 대한 타겟 전달 시간은 수신기에 의해 수신되는 시간일 수 있다. 각각의 특수 채널 변경 트리거의 타겟 트리거 시간은 채널 변경의 시간일 수 있다.
트리거 서비스의 트리거 전달 포맷은 증가된 활성화 트리거에 대한 전달 포맷 및 다른 모든 에 대한 전달 포맷으로 나눌 수 있다.
도 73은 증가된 활성화 트리거(Augmented Activation Trigger)에 대한 전달 포맷을 도시한다. 다른 모든 트리거에 대한 전달 포맷은 후술한다.
증가된 활성화 트리거에 대한 전달 포맷은 @interactionModel, @appURL, 및/또는 @cookieSpace 속성과 능력 및/또는 이벤트 엘리먼트를 포함할 수 있다.
이벤트 엘리먼트는 @action, @destination, @diffusion 및/또는 @data attributes를 포함할 수 있다.
각 필드의 시맨틱(semantics)은 다음과 같을 수 있다.
@interactionModel 속성의 값은 트리거를 전달하는데 사용되는 DTVCC 채널의 서비스 #6 내의 SDOPrivateData 명령 내의 cmdID 필드에 대하여 동일한 코딩을 이용하여 트리거와 연관된 상호 작용 모델을 위한 수치 코드일 수 있다. 본 발명의 일 실시예에서, 수치 코드는 트리거를 전달하는데 사용되는 DTV CC 채널의 서비스 6 내의 URLString 명령 내의 URI_data() 구조 내의 URI_type에 대한 것과 동일한 코딩을 이용할 수 있다.
@appURL 속성의 값은 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 TPT TDO 엘리먼트의 제1 URL 차일드 엘리먼트의 값일 수 있다.
@cookieSpace 속성은 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 TPT TDO 엘리먼트가 @cookieSpace 속성을 포함할 때마다 존재할 수 있고, 그 속성과 동일한 값을 가질 수 있다.
Capabilities 엘리먼트는 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 TPT TDO 엘리먼트가 Capabilities 엘리먼트를 포함할 때마다 존재할 수 있고, 그 엘리먼트와 동일할 수 있다.
Event 엘리먼트는 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 Event 엘리먼트를 나타낼 수 있다. (엄밀히 말하면, 트리거 내의 이벤트 용어는 TPT 내의 TDO 엘리먼트 및 그 TDO 엘리먼트의 이벤트 차일드 엘리먼트를 식별한다. 이것은 여기서 트리거 내의 이벤트 용어에 의해 식별된 Event 엘리먼트라 한다.)
@action 속성의 값은 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 이벤트 엘리먼트의 액션 속성의 값과 동일할 수 있다.
@destination은 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 이벤트 엘리먼트가 목적지 속성을 포함할 때마다 존재할 수 있고, 그 속성과 동일한 값을 가질 수 있다. 본 발명의 일 실시예에서, @destination 속성은 트리거 내의 "e=" 용어에 의해 식별된 TDO 엘리먼트가 목적지 속성을 포함할 때 마다 존재할 수 있다.
@diffusion 속성은 트리거 내의 이벤트 ("e=") 용어에 의해 식별되는 이벤트 엘리먼트가 디퓨전 속성을 포함할 때마다 존재할 수 있고, 그 속성과 동일한 값을 가질 수 있다. 본 발명의 일 실시예에서, @diffusion 속성은 트리거 내의 "e=" 용어에 의해 TDO 엘리먼트가 디퓨전 속성을 포함할 때 마다 존재할 수 있다.
@data 속성은 이벤트 엘리먼트의 데이터 차일드 엘리먼트가 트리거 내의 이벤트 ("e=") 용어에 의해 식별될 때마다 존재할 수 있고, 그 엘리먼트와 동일한 값을 가질 수 있다.
전술한 대로, 증가된 트리거는 DTVCC 스트림 혹은 ACR 서버 등으로부터 획득한 트리거와 TPT 내의 정보를 조합하여 생성될 수 있다
전술한 대로, 확장된 트리거는 증가된 트리거라고도 불릴 수 있다.
도 74는 URI_data()의 신택스의 일 실시예이다.
도 74는 전술한 AugmentedTrigger의 @interactionModel 속성에 대한 설명 중, URI_data()에 관한 것일 수 있다.
URI_data() 구조는 URI_type 및/또는 복수개의 URI_charater를 포함할 수 있다. 또한, URI_data() 구조는 예약 비트를 포함할 수 있다.
4비트 무부호 정수일 수 있는 URI_type는 명령 내에서 전송되는 URI의 타입을 나타낼 수 있다. URI_type의 의미는 도 75에 도시된 바와 같을 수 있다. 수신기는 인식되지 않는 타입을 나타내는 URIString 명령의 인스턴스를 무시할 것으로 기대할 수 있다. URI가 2개의 세그먼트에서 전송되면, URI_type 필드는 양 세그먼트에서 동일할 수 있다.
URI_character는 URI에 대하여 허용되는 것으로 제한되는 값을 갖는 8비트 ASCII 문자일 수 있다. URI가 2개의 세그먼트에서 전송되는 경우의 재조합(reassembly) 후에, URI_character 값의 시퀀스에 의해 형성된 문자 스트링이 유효 URI일 수 있다.
도 75는 URI_type의 의미의 일 실시예이다.
도 75는 URI_data()의 신택스의 일 실시예에서 전술한 URI_data()의 URI_type의 의미에 관한 것일 수 있다.
URI_type이 0인 경우, URI_data()가 인터랙티브 TV 트리거에 관한 것임을 의미할 수 있다.
URI_type이 1인 경우, URI_data()가 서비스 사용 보고 서버(SURS) 로케이터(locator)에 관한 것임을 의미할 수 있다.
URI_type이 2-15인 경우 URI_data()가 어떤 type을 가지는 지는 아직 정해지지 않은 상태이고, 미래 사용을 위해 예약되어 있을 수 있다.
도 76는 증가된 활성화 트리거(Augmented Activation Trigger)에 대한 XML 스키마 기술(Schema Description)의 일 실시예이다.
증가되지 않은 트리거의 XML 포맷일 수 있다. 전술한 특수 "채널 변경" 트리거 역시 이 포맷을 따를 수 있다.
증가된 활성화 트리거에 대한 XML 스키마 기술 의 일 실시예는, @interactionModel 속성 및/또는 @triggerString 속성을 포함할 수 있다.
각 필드의 시맨틱은 다음과 같을 수 있다.
@interactionModel 속성은 특수 "채널 변경" 트리거를 위해 존재할 수 없다. 다른 트리거를 위하여, interactionModel이 존재할 수 있고, 그 값은 DTVCC 채널 내의 SDOPrivateData 코맨드 내의 cmdID 필드에 대한 것과 동일한 코딩을 이용하여 트리거와 연관된 상호 작용 모델을 위한 수치 코드일 수 있다. 라이브 트리거 서버로부터 획득되거나 AMT로부터 도출된 트리거를 위한 @interactionModel은 TDO 모델로 간주될 수 있다. 본 발명의 일 실시예에서, 수치 코드는 DTV CC 채널의 서비스 6의 URLString 명령 내의 URI_data() 구조 내의 URI_type 필드에 대한 것과 동일한 코딩을 이용할 수 있다.
@triggerString 속성의 값은 트리거의 스트링 표시일 수 있다. 트리거의 스트링 표시는 전술한 트리거 신택스에서 설명한 것과 같을 수 있다. 다만, 특수 "채널 변경" 트리거의 경우에는 다를 수 있다. 특수 "채널 변경" 트리거를 위한 @triggerString 속성은 값 "**<major_num>.<minor_num>"을 가질 수 있고, 여기서, <major_num>는 (TV 스테이션에 의해 방송되었기 때문에) 새로운 채널의 본래의 주요 채널 번호일 수 있고, <minor_num>는 (TV 스테이션에 의해 방송되었기 때문에) 새로운 채널의 본래의 마이너 채널 번호일 수 있다. 채널 번호를 모르면, <major_num> 및 <minor_num> 값은 "0"일 수 있다.
도 77는 증가된 활성화 트리거의 포맷의 일 실시예이다.
전술한 증가된 트리거의 포맷의 다른 실시예일 수 있다.
@cookieSpace, Capabilities, Event, @action, @destination, @diffusion 및 @data는 전술한 것과 같을 수 있다.
@activationTime은 미디어 시간 스케일 상의 활성화 시간일 수 있다.
@tdoURL 는 전술한 @appURL과 동일할 수 있다.
도 78는 증가된 활성화 트리거의 포맷의 일 실시예이다.
전술한 증가된 트리거의 포맷의 또 다른 실시예일 수 있다.
@activationTime, @tdoURL, @cookieSpace, Capabilities, Event, @action, @destination, @diffusion 및 @data는 전술한 것과 같을 수 있다.
@availInternet and @availBroadcast can be from TPT. @availInternet 및 @availBroadcast 또한 전술한 바와 같을 수 있다.
도 79는 증가된 활성화 트리거의 포맷의 일 실시예이다.
전술한 증가된 트리거의 포맷의 또 다른 실시예일 수 있다.
@activationTime, @tdoURL, @cookieSpace, Capabilities, Event, @action, @destination, @diffusion 및 @data는 전술한 것과 같을 수 있다.
ContentItem element 및, @updatesAvail, @pollPeriod, @size, @availInternet, @availBroadcast attributes는, augmented trigger를 생성할 때, TPT 에서의 동명의 element 및 attributes에서 온 것일 수 있다. ContentItem element 및, @updatesAvail, @pollPeriod, @size, @availInternet, @availBroadcast 또한 전술한 것과 같을 수 있다.
도 80는 증가된 활성화 트리거의 포맷의 일 실시예이다.
전술한 증가된 트리거의 포맷의 또 다른 실시예일 수 있다.
@cookieSpace, @availInternet, @availBroadcast Capabilities, ContentItem, @updatesAvail, @pollPeriod, @size, @availInternet, @availBroadcast, Event, @action, @destination 및 @data는 전술한 것과 같을 수 있다.
@appID, @appType, @appName, @globalId, @appVersion, @frequencyOfUse, @expireDate, @testTDO, TDO 엘리먼트 내의 URL 및 ContentItem 엘리먼트 내의 URL은, 증가된 트리거를 생성할 때, TPT 에서의 동명의 엘리먼트 및 속성에서 온 것일 수 있다. @appID, @appType, @appName, @globalId, @appVersion, @frequencyOfUse, @expireDate, @testTDO, TDO element 내의 URL 및 ContentItem element 내의 URL 또한 전술한 것과 같을 수 있다.
도 81는 HTTP 롱 폴링 기반 어프로치에 따른 트리거 서비스 상태 변수의 일 실시예이다.
여기서, 트리거 서비스를 지원하는 몇 가지 어프로치가 존재할 수 있다. 몇 가지 어프로치에는 HTTP 롱 폴링 기반 어프로치와 UPnP 이벤팅 메커니즘 기반 어프로치가 있을 수 있다.
이하, HTTP 롱 폴링 기반 어프로치에 대하여 설명한다.
HTTP 롱 폴링 기반 오프로치에서, 트리거 서비스는 하나의 상태 변수를 가질 수 있다.
TrigServerURL 상태 변수의 값은 프로토콜 용어 없이 클라이언트에 의해 트리거를 검색하는데 사용될 URL일 수 있다.
트리거를 검색하라는 요청은 HTTP 요청 또는 WebSocket 요청을 이용하여 이루어질 수 있다. HTTP 요청이 (그 앞에 붙여진 프로토콜 용어 갖는 TrigServerURL을 이용하여) 이루어지면, 서버는 HTTP 롱 폴링 전달 모드에서 응답할 수 있다. WebSocket 요청이 (그 앞에 붙여진 프로토콜 용어 "ws://"를 갖는 TrigServerURL을 이용하여) 이루어지면, 서버는 WebSocket 전달 모드에서 응답할 수 있다.
요청 URL이 쿼리 용어를 포함하지 않거나 쿼리 용어 "?level=unfilter"를 포함하면, 서버는 필터링되지 않은 스트림 옵션으로 응답할 수 있다. 요청 URL이 쿼리 용어 "?level=filter"를 포함하면, 서버는 필터링된 스트림 옵션으로 응답할 수 있다.
트리거가 필터링되지 않은 스트림 옵션으로 전달되고 트리거가 TDO 모델 이외의 상호작용 모델에 대하여 전달되면, 응답의 바디는 도 76으로 표시된 XML 스키마에 맞는 XML 문서의 형태를 가질 수 있다.
활성화 트리거가 필터링된 스트림 옵션으로 전달되면, 응답의 바디가 도 73에 표시된 XML 스키마에 맞는 XML 문서의 형태를 가질 수 있다.
도 82는 HTTP 롱 폴링 기반 어프로치에 따른 트리거 서비스 액션의 일 실시예이다.
HTTP 롱 폴링 기반 어프로치에서, 트리거 서비스는 단일 액션 GetTrigServerURL 액션을 가질 수 있다. GetTrigServerURL 액션은 클라이언트에 의해 TrigServerURL의 값을 얻는데 사용될 수 있다.
도 83는 HTTP 롱 폴링 기반 어프로치에 따른 GetTrigServerURL 액션의 인수(Arguments)의 일 실시예이다.
TrigServerURL 출력 인수는 TrigServerURL 상태 변수의 현재 값일 수 있다.
이 실시예에서, 제2 스크린 애플리케이션은 GetTrigServerURL Action을 이용하여 클라이언트에 의해 트리거를 검색하는데 사용될 URL을 얻을 수 있다.
도 84는 트리거 서비스 상태 변수의 실시예를 나타내는 도면이다.
도 84의 실시예는, UPnP 이벤팅 메커니즘 기반 어프로치에 따른 것일 수 있다.
이하, UPnP 이벤팅 메커니즘 기반 어프로치에 대하여 설명한다.
트리거 서비스 상태 변수의 일 실시예는 도시된 트리거 서비스 상태 변수를 정의할 수 있다. 트리거 서비스는 도 84에 열거된 상태 변수를 가질 수 있다.
LatestUnfilteredTrigger 상태 변수의 값은 가장 최근의 타겟 전달 시간을 갖는 필터링되지 않은 스트림 내의 트리거를 나타낼 수 있다. 이 상태 변수의 포맷은 도 76에 기재된 스키마에 맞는 XML 문서일 수 있다.
LatestFilteredTrigger 상태 변수의 값은 가장 최근의 타겟 전달 시간을 갖는 필터링된 스트렘 내의 트리거를 나타낼 수 있다. 활성화 트리거이면, TPT 내의 정보를 갖는 활성화 트리거 내의 정보를 결합하여 도 73에 기재된 테이블로 표시된 XML 스키마에 맞는 XML 문서를 생성함으로써 증가될 수 있다. TDO 이외의 상호작용 모델을 갖는 트리거이면, 도 76에 기재된 스키마에 맞는 XML 문서의 형태를 가질 수 있다. 특수 채널 변경 트리거이면, 포맷은 상술한 바와 같이 "**<major_num>.<minor_num>"일 수 있다.
UnfilteredTriggerDeliveryTime 상태 변수의 값은 가장 최근의 타겟 전달 시간을 갖는 필터링되지 않은 스트림 내의 트리거의 전달 시간일 수 있다. "dateTime" 데이터 타입은 1970년 1월 1일 00:00:00 이후 밀리초의 수를 나타내는 수일 수 있다.
FilteredTriggerDeliveryTime 상태 변수의 값은 가장 최근의 타겟 전달 시간을 갖는 필터링된 스트림 내의 트리거의 전달 시간일 수 있다.
도 85는 트리거 서비스 액션의 실시예를 나타내는 도면이다.
도 85의 실시예는 UPnP 이벤팅 메커니즘 기반 어프로치에 따른 것일 수 있다.
액션은 제2 스크린 디바이스 또는 수신기가 트리거 서비스 상태 변수의 값을 임의로 판독하도록 정의될 수 있다.
UPnP 이벤팅 메커니즘 기반 어프로치에서, 트리거 서비스 액션은 GetLatestUnfilteredTrigger 및 GetLatestFilteredTrigger 액션을 정의할 수 있다.
도 86은 GetLatestUnfilteredTrigger 액션의 인수의 실시예를 나타내는 도면이다.
도 86의 실시예는 UPnP 이벤팅 메커니즘 기반 어프로치에 따른 것일 수 있다.
LatestUnfilteredTrigger 출력 인수의 값은 LatestUnfilteredTrigger 상태 변수의 값일 수 있다.
제2 스크린 애플리케이션은 GetLatestUnfilteredTrigger 액션을 이용하여 LatestUnfilteredTrigger 상태 변수의 값, 즉, 가장 최근의 타겟 전달 시간을 갖는 필터링되지 않은 스트림 내의 트리거를 얻을 수 있다.
도 87은 GetLatestFilteredTrigger 액션의 인수의 실시예를 나타내는 도면이다.
도 87의 실시예는 UPnP 이벤팅 메커니즘 기반 어프로치에 따른 것일 수 있다.
LatestFilteredTrigger 출력 인수의 값은 LatestFilteredTrigger 상태 변수의 값일 수 있다.
제2 스크린 애플리케이션은 GetLatestFilteredTrigger 액션을 이용하여 LatestFilteredTrigger 상태 변수의 값, 즉, 가장 최근의 타겟 전달 시간을 갖는 필터링된 스트림 내의 트리거를 얻을 수 있다.
도 88은 UPnP 이벤팅 메커니즘 기반 어프로치의 실시예이다.
UPnP 이벤팅 메커니즘 기반 어프로치의 실시예는, 트리거를 수신하는 단계 (s88010), UnfilteredTriggerDeliveryTime을 변경하는 단계(s88020), 비동기 통지를 전달하는 단계(s88030), GetLatestUnfilteredTrigger 액션을 이용하는 단계(s88040), 증가되지 않은 트리거로 응답하는 단계(s88050), 활성화 트리거를 수신하는 단계 (s88060), FilteredTriggerDeliveryTime를 변경하는 단계(s88070), 비동기 통지를 전달하는 단계(s88080), GetLatestFilteredTrigger 액션을 이용하는 단계(s88090) 및/또는 증가된 활성화 트리거로 응답하는 단계(s88100)를 포함할 수 있다.
도면에서, 수신기는 전술한 수신기일 수 있다. 제2 스크린 디바이스 #1은 "unfiltered stream option"을 지원하는 제2 스크린 디바이스일 수 있다. 제2 스크린 디바이스 #2는 "필터링된 스트림 옵션"을 지원하는 제2 스크린 디바이스 일 수 있다.
트리거를 수신하는 단계(s88010)는, 전술한대로 수신기가 DTVCC 채널, ACR 프로세스 또는 방송사 인터랙티브 TV (iTV) 서버 등을 통해 트리거를 전달받는 단계일 수 있다. 이 때 전달받는 트리거는 증가되지 않은 모든 타입의 트리거일 수 있다.
UnfilteredTriggerDeliveryTime를 변경하는 단계(s88020)는 전술한 UnfilteredTriggerDeliveryTime 상태 변수의 값이 변경되는 단계일 수 있다.
비동기 통지를 전달하는 단계(s88030)는 전술한 "이벤팅" 프로토콜에 의한 것일 수 있다. 제2 스크린 애플리케이션은 트리거 서비스의 "이벤팅" 특징에 가입할 수 있다.
GetLatestUnfilteredTrigger 액션을 이용하는 단계(s88040)는, 제2 스크린 애플리케이션이 트리거를 얻기 위하여, 전술한 GetLatestUnfilteredTrigger 액션을 이용하는 단계일 수 있다.
증가되지 않은 트리거로 응답하는 단계(s88050)는 GetLatestUnfilteredTrigger 액션에 대한 응답으로 증가되지 않은 트리거를 전송하는 단계일 수 있다. 제2 스크린 애플리케이션은 GetLatestUnfilteredTrigger 액션을 이용하여 적절한 트리거를 적절한 시간에 얻을 수 있다.
활성화 트리거를 수신하는 단계(s88060)는 전술한대로 수신기가 DTVCC 채널, ACR 프로세스 또는 방송사 인터랙티브 TV (iTV) 서버 등을 통해 활성화 트리거를 전달받는 단계일 수 있다.
FilteredTriggerDeliveryTime를 변경하는 단계(s88070)는 전술한 FilteredTriggerDeliveryTime 상태 변수의 값이 변경되는 단계일 수 있다.
비동기 통지를 전달하는 단계(s88080)는 전술한 비동기 통지를 전달하는 단계 (s88030)와 같을 수 있다.
GetLatestFilteredTrigger 액션을 이용하는 단계(s88090)는, 제2 스크린 애플리케이션이 트리거를 얻기 위하여, 전술한 GetLatestFilteredTrigger 액션을 이용하는 단계일 수 있다.
증가된 활성화 트리거로 응답하는 단계(s88100)는 GetLatestFilteredTrigger 액션에 대한 응답으로 증가된 활성화 트리거를 전송하는 단계일 수 있다. 제2 스크린 애플리케이션은 GetLatestFilteredTrigger 액션을 이용하여 적절한 트리거를 적절한 시간에 얻을 수 있다.
도 89는 트리거 서비스 상태 변수의 실시예를 나타내는 도면이다.
전술한 트리거 서비스를 지원하기 위한 몇 개의 어프로치에는, HTTP 롱 폴링 기반 어프로치와 UPnP 이벤팅 메커니즘 기반 어프로치 외에 다른 실시예가 있을 수 있다. 이하, 그 실시예를 도 89 및 도 90에 걸쳐 설명한다.
이 실시예에 있어, 트리거 서비스 상태 변수는 도 89과 같을 수 있다.
CurrentTrigger 상태 변수의 값은 다음의 3개의 상황 중의 어느 것이 시행되는 지에 의존할 수 있다. 1) 프라이머리 스크린 상에 현재 보이는 프로그래밍과 연관된 인터랙티브 부가(adjunct) 데이터 서비스가 없다. 2) 프라이머리 스크린 상에 현재 보이는 프로그래밍과 연관된 인터랙티브 부가 데이터 서비스가 존재하고, 직접 실행 상호작용 모델을 갖는다. 3) 프라이머리 스크린 상에 현재 보이는 프로그래밍과 연관된 인터랙티브 부가 데이터 서비스가 존재하고 TDO 상호작용 모델을 갖는다.
(1)의 경우, CurrentTrigger 상태 변수의 값은 널 스트링(null string)일 수 있다.
(2)의 경우, CurrentTrigger 상태 변수의 값은 프라이머리 스크린 상에 현재 보이는 프로그래밍에 대하여 TV 수상기에 의해 수신된 가장 최근의 트리거일 수 있다.
(3)의 경우, CurrentTrigger 상태 변수의 값은 프라이머리 스크린 상에 현재 보이는 프로그래밍에 대하여 TV 수상기에 의해 수신된 활성화 트리거 중 가장 최근에 활성화된 활성화 트리거의 증가된 형태일 수 있다. (즉, 활성화 트리거는 활성화 시간에 도달할 때 CurrentTrigger 상태 변수에 대한 기초가되고, 다른 활성화 트리거가 그 활성화 시간에 도달할 때까지 기초로 남아 있을 수 있다.) 활성화 트리거의 증가된 형태는 활성화 트리거 내의 정보를 TPT 내의 정보와 결합함으로써 얻어질 수 있다. 증가된 형태는 상술한 증가된 트리거 포맷 중의 하나와 동일할 수 있다.
CurrentTrigger 상태 변수의 정의는 TDO 상호작용 모델에 대하여 활성화 트리거가 트리거 활성화 시간에 UPnP 클라이언트로 전달되는 것을 의미할 수 있다.
트리거 서비스 상태 변수의 다른 실시예에서, 트리거가 변경될 때마다, 수신기로부터 제2 스크린 디바이스로 트리거 또는 확장된 트리거를 실시간으로 전송하기 위하여, ATSCTrigger 및 ATSCExpandedTrigger가 상태 변수로서 정의될 수 있다.
ATSCTrigger 상태 변수는 DTVCC 스트림 또는 ACR 서버로부터 수신된 트리거에 대한 참조를 URI의 형태로 포함할 수 있다. 이 변수는 TPT(TDO parameters table)에 대한 URL, TDO ID, Event ID, Data ID, 미디어 시간, 콘텐츠 ID, 타겟 이벤트에 대한 활성화 시간 등을 포함할 수 있다.
ATSCExpandedTrigger 상태 변수는 제2 스크린 디바이스에 대한 TDO와 연관된 메타데이터를 XML 프래그먼트의 형태로 포함할 수 있다. 이 메타데이터는 DTVCC 스트림 또는 ACR 서버로부터 수신된 TPT 및 트리거로부터 추출될 수 있다. 이 변수는 도 80의 실시예와 동일한 XML 스키마를 가질 수 있다.
위에서 정의한 ATSCTrigger 및 ATSCExpandedTrigger의 변경된 값은 수신기가 UPnP의 이벤팅 메커니즘에 기초하여 상태 변수를 변경할 때 실시간으로 획득될 수 있다.
도 90는 트리거 서비스 액션의 실시예를 나타내는 도면이다.
ATSCTrigger 및 ATSCExpandedTrigger이 상태 변수로서 정의된 상술한 트리거 서비스 상태 변수의 다른 실시예에서, 트리거 서비스 액션을 설명한다.
이 이벤트에서도, 액션은 제2 스크린 디바이스 또는 수신기가 임의로 ATSCTrigger 및 ATSCExpandedTrigger의 값을 기록 또는 판독하도록 정의될 수 있다.
SetTrigger() 액션은 ATSCTrigger의 사용을 가능하게 할 수 있다. CurrentTrigger는 인수일 수 있다.
SetExpandedTrigger() 액션은 ATSCExpandedTrigger의 값의 이용을 가능하게 할 수 있다. CurrentTrigger는 증가될 수 있다.
GetTrigger() 액션은 ATSCTrigger의 값의 판독을 가능하게 할 수 있다. CurrentTrigger는 인수일 수 있다.
GetExpandedTrigger()는 ATSCExpandedTrigger의 값의 판독을 가능하게 할 수 있다. CurrentTrigger는 인수일 수 있다.
도 91은 트리거 전달 서비스를 통해 트리거를 획득할 때 제2 스크린 상의 동작의 실시예를 나타내는 도면이다.
제2 스크린 디바이스가 트리거 전달 서비스를 통해 제2 스크린 디바이스로부터 수시된 트리거 또는 확장된 활성화 트리거에 포함되는 액션 정보에 따라 동작하는 방법이 도시될 수 있다.
실행/종료 액션의 트리거는 트리거 전달 서비스를 통해 획득될 수 있다.
제2 스크린 디바이스는 트리거 전달 서비스를 통해 실행/종료 액션의 트리거를 획득하고 획득된 트리거로부터의 연관된 정보 및 타겟 TDO의 URL을 DAE/브라우저로 전달할 수 있다. 브라우저는 실행 또는 종료 등의 트리거에 포함되는 액션을 수행할 수 있다.
도 92는 트리거 전달 서비스의 동작 개념을 나타내는 도면이다.
트리거 전달 서비스를 통해 제2 스크린 디바이스로부터 수신된 트리거 또는 확장된 활성화 트리거 내에 포함되는 액션 정보에 따라 동작하는 방법이 도시될 수 있다.
제2 스크린 디바이스는 트리거 전달 서비스를 통해 트리거 이벤트 액션의 트리거를 획득하고 획득된 트리거로부터 Data ID 등의 정보를 추출할 수 있다. 그후, 데이터는 AJAX를 이용하여 현재 실행되는 TDO로 전달될 수 있다. TDO는 수신된 데이터에 따라 적절한 동작을 수행할 수 있다.
ATSCTrigger 및 ATSCExpandedTrigger이 상태 변수로서 정의되는 상술한 트리거 서비스 상태 변수의 다른 실시예에서, 트리거 전달 서비스의 동작 개념을 설명한다.
이 실시예에서, 직접 실행 모델의 경우, 콘텐츠 id, 즉, "c="가 DTVCC 스트림 또는 ACR 서버를 통해 수신된 트리거에 포함되면, 수신기는 수신된 시간 베이스 트리거 값을 ATSCTrigger 상태 변수의 값으로 설정할 수 있다. 시간 베이스 트리거가 수신기에 도달하면, 상태 변수의 값이 즉시 변경되거나 SetTrigger 액션을 통해 제2 스크린 디바이스로 전달될 수 있다.
본 실시예에서, TDO 모델의 경우, 콘텐츠 id, 즉, "c="가 DTVCC 스트림 또는 ACR 서버를 통해 수신된 트리거 내에 포함되지 않으면, 수신기는 활성화 트리거를 수신하고 TPT로부터의 연관된 정보 및 트리거 정보를 추출 및 결합하여 확장된 트리거를 생성한다. 그 후, 확장된 트리거의 활성화 시간에(또는 그 전에), ATSCExpandedTrigger 상태 변수의 값이 설정되거나 SetExpandedTrigger 액션을 통해 제2 스크린 디바이스로 전달될 수 있다.
도 93는 제1 어프로치에 따른 양방향 통신 서비스 상태 변수의 일 실시예이다.
양방향 통신 서비스는 제2 스크린 디바이스 내의 애플리케이션과의 양방향 통신에 참여하도록 준비된 프라이머리 디바이스에서 실행되는 DO가 있는지를 클라이언트 디바이스가 결정하도록 할 수 있다.
양방향 통신 서비스는 클라이언트 디바이스가 수신기에서 실행되는 DO로부터 양방향 통신을 수신하도록 할 수 있다. 이를 지원하기 위하여, 2개의 상이한 어프로치가 존재할 수 있다.
이하, 양방향 통신 서비스를 실현하는 제1 어프로치를 설명한다.
먼저, 클라이언트 디바이스가 등록하면, (일반적으로 클라이언트 디바이스 상에서) WebSocket 서버의 IP 어드레스 및 TCP 포트를 제공할 수 있다. DO가 클라이언트 디바이스와 통신하기를 원하면, 등록될 때 제공된 어드레스 및 포트를 이용하여 클라이언트 디바이스로의 WebSocket 접속을 확립할 수 있다.
제1 어프로치에서, 양방향 통신 서비스는 도 93에 도시된 상태 변수를 가질 수 있다.
ClientList 상태 변수는 양방향 통신을 위해 등록된 클라이언트의 리스트일 수 있다. 또한, Name, IPAddress 및 Port는 각 클라이언트에 대한 이름, IP 어드레스 및 TCP 포트를 의미할 수 있다.
도 94는 제1 어프로치에 따른 ClientList 상태 변수의 XML 스키마 테이블의 일 실시예이다.
ClientList는 도 94 내의 테이블에 의해 기재된 XML 스키마에 맞는 XML 문서의 형태일 수 있다.
Name 상태 변수는 양방향 통신을 위해 등록된 클라이언트의 이름일 수 있다.
IPAddress 상태 변수는 양방향 통신을 위해 등록된 클라이언트에 대한 WebSocket 서버의 IP 어드레스일 수 있다.
TCPPort 상태 변수는 양방향 통신을 위해 등록된 클라이언트에 대한 WebSocket 서버의 TCP 포트일 수 있다.
도 95는 제1 어프로치에 따른 트리거 서비스 액션의 일 실시예이다.
제1 어프로치에서, 양방향 통신 서비스는 도 95 내의 테이블에 의해 기재된 바와 같이 2개의 액션을 가질 수 있다.
SignUp 액션은 클라이언트에 의해 양방향 통신에 참여하는데 관심이 있다는 것을 지시하고 사용될 이름 및 IP 어드레스 및 포트를 제공하여 접속을 확립하는데 사용될 수 있다.
SignOff 액션은 클라이언트에 의해 양방향 통신에 참여하는데 더 이상 관심이 없다는 것을 나타내는데 사용될 수 있다.
도 96는 제1 어프로치에 따른 SignUp 액션의 인수의 일 실시예이다.
Name 입력 인수는 등록된 클라이언트와 연관된 이름일 수 있다. 이는 장치의 호스트이름일 수 있다. 이는 이미 등록된 임의의 다른 클라이언트의 이름과 별개일 수 있다.
IPAddress 입력 인수는 접속을 확립할 때 DO에 의해 사용될 WebSocket 서버의 IP 어드레스일 수 있다.
TCPPort 입력 인수는 접속을 확립할 때 DO에 의해 사용될 WebSocket 서버의 TCP 포트일 수 있다.
도 97는 제1 어프로치에 따른 SignOff 액션의 인수의 일 실시예이다.
Name 입력 인수는 양방향 통신 서비스를 위해 등록될 때 클라이언트가 제공한 이름일 수 있다. 그 목적은 지금 송신 종료(signing off)되는 클라이언트를 식별하는 것이다.
도 98는 제2 어프로치에 따른 양방향 통신 서비스 상태 변수의 일 실시예이다.
이하, 양방향 통신 서비스를 실현하는 제2 어프로치를 설명한다.
프라이머리 디바이스에서 실행되는 이러한 DO가 존재하면, 제2 스크린 디바이스 내의 애플리케이션은 제2 스크린 디바이스 내의 애플리케이션이 양방향 통신에 참여할 준비가 되어 있다는 것을 지시하면서 TCP/IP 접속을 요청할 수 있다. 접속의 제2 스크린 디바이스측 상의 TCP/IP 어드레스 및 포트가 제2 스크린 디바이스의 고유 식별자로서 기능할 수 있다. 바이트는 TCP/IP 접속을 통해 제2 스크린 디바이스 및 프라이머리 디바이스 내의 DO 사이에서 자유롭게 전송될 수 있다.
양방향 통신 서비스는 도 98에 도시된 2개의 상태 변수를 가질 수 있다.
ConnectionAddress 상태 변수는 <address>:<port>의 포맷으로 제2 스크린 디바이스로부터의 접속 요청이 향하는 IP 어드레스 및 TCP 포트를 포함할 수 있다.
Status 상태 변수는 제2 스크린 디바이스와의 양방향 통신에 참여하도록 준비된 실행 DO가 존재하는지를 나타내고, 여기서, "참"은 실행되는 이러한 DO가 존재한다는 것을 의미하고 "거짓"은 이러한 DO가 실행되지 않는다는 것을 의미한다.
본 발명의 일 실시예에서, Status 상태 변수의 데이터 타입은 "스트링"일 수 있다. 이 실시예에서, Status 상태 변수의 가능한 값은 "예" 및 "아니오"일 수 있다.
제2 어프로치에서, 양방향 통신 서비스는 임의의 액션을 갖지 않을 수 있다.
도 99는 제2 어프로치에 따른 onBytesReceived 함수의 일 실시예이다.
이하, 메시지를 전송 및 수신하기 위하여 프라이머리 디바이스 내의 DO에 의해 사용되는 API를 설명한다.
다음의 API는 양방향 통신 서비스를 이용하여 프라이머리 디바이스에서 실행되는 DO가 제2 스크린 디바이스에서 실행되는 애플리케이션과의 양방향 통신에 참여하도록 할 수 있다.
TV 수신기는 DO가 종료될 때마다 양방향 통신 서비스를 위해 UPnP "Status" 상태 변수를 "거짓"으로 설정하여, 통신하기 전에 새로운 DO가 사전에 그 상태 변수를 "참"으로 설정할 수 있다.
전술한 "Status" 상태 변수의 데이터 타입이 스트링인 실시예의 경우, TV 수신기는 DO가 실행을 시작할 때마다 UPnP 상태 변수 "Status"를 "아니오"로 설정하여, 통신 전에 DO가 사전에 그 상태 변수를 "예"로 설정해야 한다.
새로운 특성인 onBytesReceived 함수는 NetworkInterface 클래스에 부가될 수 있다.
콜백 함수인 onBytesReceived 함수는 양방향 통신 서비스를 통해 DO에 대한 바이트가 수신될 때 호출될 수 있다. 2개의 인수, 즉, "address" 및 "bytes"가 정의될 수 있다.
"address"는 <address>:<port>의 포맷으로 수신된 바이트의 송신자의 IP 어드레스 및 UDP 포트를 포함하는 스트링일 수 있다.
"bytes"는 수신된 바이트를 나타내는 스트링일 수 있다. 실시예에 따라, UDP 및/또는 IP 헤더를 제외한 것일 수 있다.
도 100는 제2 어프로치에 따른 setStatusYes()의 일 실시예이다.
새로운 방법, 즉, setStatusYes()이 NetworkInterface 클래스에 추가될 수 있다
setStatusYes()는 양방향 통신 서비스의 UpnP 불린(Boolean) 상태 변수 "Status"의 값을 "참"으로 설정하여, DO가 통신에 참여할 준비가 되어 있다는 것을 나타낼 수 있다.
setStatusYes()는 임의의 인수를 갖지 않을 수 있다.
도 101는 제2 어프로치에 따른 setStatusNo()의 일 실시예이다.
새로운 방법, 즉, setStatusNo()이 NetworkInterface 클래스에 추가될 수 있다.
setStatusNo()는 양방향 통신 서비스의 UpnP 불린 상태 변수 "Status"의 값을 "거짓"으로 설정하여, DO가 통신에 참여할 준비가 되어 있지 않다는 것을 나타낼 수 있다.
setStatusNo()는 임의의 인수를 갖지 않을 수 있다.
도 102는 제2 어프로치에 따른 setStatus()의 일 실시예이다.
전술한 "Status" 상태 변수의 데이터 타입이 스트링인 실시예의 경우, setStatus() 는 NetworkInterface 클래스에 추가될 수 있다.
setStatus()는 양방향 통신 서비스의 UpnP 상태 변수 "Status"의 값을 설정할 수 있다.
setStatus()는 상태 인수를 가질 수 있다.
상태 인수는 DO가 제2 스크린 디바이스와의 양방향 통신에 참여할 수 있으면 "예"로 설정되고, 그렇지 않으면, "아니오"로 설정될 수 있다.
도 103는 제2 어프로치에 따른 sendBytes()의 일 실시예이다
새로운 방법, 즉, sendBytes()은 NetworkInterface 클래스에 추가될 수 있다.
sendBytes()는 양방향 통신 서비스를 이용하여 바이트를 전송할 수 있다.
sendBytes()는 2개의 인수, 즉, 어드레스 및 바이트를 가질 수 있다.
"address" 인수는 <address>:<port>의 포맷으로 바이트에 대한 목적지 TCP/IP 어드레스 및 포트를 의미할 수 있다.
"bytes" 인수는 전송될 바이트를 의미할 수 있다.
도 104는 AppURL 서비스 상태 변수의 일 실시예이다.
AppURL 서비스는 제2 스크린 디바이스가 현재 실행중인 DO와 연관된 제2 스크린 애플리케이션의 이름 및 베이스 URL을 결정하도록 할 수 있다.
UPnP AppURL 서비스는 2개의 상태 변수, 즉, AppURL and AppName를 가질 수 있다.
AppURL 상태 변수의 값은 현재 실행중인 DO와 연관된 제2 스크린 애플리케이션의 베이스 URL일 수 있다. 제1 스크린 디바이스 상에 실행되는 연관된 제2 스크린 애플리케이션을 갖는 DO가 없으면, AppURL 상태 변수의 값은 널 스트링일 수 있다.
AppName 상태 변수의 값은 현재 실행 중인 DO와 연관된 제2 스크린 애플리케이션의 이름일 수 있다. 제1 스크린 디바이스 상에서 실행되는 연관된 제2 스크린 애플리케이션을 갖는 DO가 없으면, AppName 상태 변수의 값은 널 스트링일 수 있다.
도 105는 AppURL 서비스 액션의 일 실시예이다.
AppURL 서비스는 하나의 액션, 즉, GetAppURL을 가질 수 있다.
도 106는 GetAppURL 액션의 인수의 일 실시예이다.
GetAppURL 액션은 2개의 인수, 즉, AppURL 및 AppName을 가질 수 있다.
AppURL 출력 인수는 AppURL 상태 변수의 현재 값일 수 있다. AppName 출력 인수는 AppName 상태 변수의 현재 값일 수 있다.
따라서, GetAppURL 액션을 통해, AppURL 상태 변수의 현재 값 및 AppName 상태 변수의 현재 값을 얻을 수 있다.
도 107는 프록시 HTTP 서버 서비스(Proxy HTTP Server service)의 동작 개념도의 일 실시예이다.
수신기는 프록시 HTTP 서버 서비스를 지원할 수 있다. 프록시 HTTP 서버 서비스는 제2 스크린 디바이스에서 필요로 하는 TDO/파일들이 방송망을 통해서 전송될 경우, 이를 TV 수신기를 통하여 획득할 수 있도록 하는 서비스를 의미할 수 있다.
프록시 HTTP 서버 서비스의 동작 개념도는, 방송 시스템(107010), ACR 서버(107020), 방송사 ATSC 2.0 iTV 서버(107030), ATSC 2.0 수신기(107040) 및/또는 제2 스크린 디바이스(107050)를 포함할 수 있다.
방송 시스템(107010)은, 방송 시스템(42010)과 동일할 수 있다.
ACR 서버(107020)는, ACR 서버(42020)와 동일할 수 있다.
방송사 ATSC 2.0 iTV 서버(107030)는, 방송사 ATSC 2.0 iTV 서버(42030)와 동일할 수 있다.
ATSC 2.0 수신기(107040)는, 방송 A/V 및 인터랙티브 서비스와 관련된 트리거 등을 수신하고 이를 이용하여 인터랙티브 서비스를 획득 및 화면 상에 제공할 수 있다. 전술한 수신기와 동일할 수 있다. 프록시 HTTP 서버 서비스는 ATSC 2.0 수신기(107040)로 하여금 프록시 서버와 비슷한 역할을 수행할 수 있도록 하는 서비스일 수 있다. 제2 스크린 디바이스에서 요청한 파일을 제2 스크린 디바이스에 효율적으로 제공할 수 있도록 하기 위함일 수 있다.
제2 스크린 디바이스(107050)는, 제2 스크린 디바이스(42050)와 동일할 수 있다.
프록시 HTTP 서버 서비스는 수신기로 하여금 방송 스트림 혹은 인터넷에 존재하는 파일을 제2 스크린 디바이스를 통하여 접근가능하도록 함으로써 제2 스크린 디바이스로 하여금 방송 스트림을 통해서 전송되는 콘텐츠에도 접근할 수 있도록 한다. 그리고 다수의 제2 스크린 디바이스들이 인터넷에 존재하는 동일한 파일을 접근하는 경우, 각 제2 스크린 디바이스가 개별적으로 동일한 파일을 접근하는 중복성을 최소화 할 수 있다.
도 108는 프록시 서버 서비스 상태 변수(Proxy Server Service State Variable)의 일 실시예이다.
UPnP 프록시 서버 서비스는 HTTP 프록시 서버를 제공하여 제2 스크린 디바이스가 FLUTE 세션을 통해 방송에서 TV 수신기로 전달되는 파일을 액세스하도록 할 수 있고 가정 내의 다수의 제2 스크린 디바이스가 동시에 동일한 파일을 검색할 때 제2 스크린 디바이스에 의해 인터넷 서버로부터 더 효율적으로 파일을 검색하도록 한다.
이를 가능하도록 하기 위하여 상태 변수 및 액션을 정의할 수 있다.
UPnP HTTP 프록시 서버 서비스는 단일 상태 변수, 즉, ProxyServerURL을 가질 수 있다.
ProxyServerURL 상태 변수의 값은 HTTP 프록시 서버의 URL, 즉, 프록시 서버를 통해 요청을 라우팅(route)하기 위하여 HTTP 요청이 향하는 URL일 수 있다.
도 109는 프록시 서버 서비스 액션(Proxy Server Service Action)의 일 실시예이다.
UPnP 프록시 서버 서비스는 단일 액션, 즉, GetProxyURL을 가질 수 있다.
도 110는 GetProxyURL 액션의 인수의 일 실시예이다.
GetProxyURL 액션은 단일 인수, 즉, ProxyURL를 가질 수 있다.
ProxyURL 출력 인수는 ProxyServerURL 상태 변수의 현재 값일 수 있다.
따라서, GetProxyURL 액션을 통해, ProxyServerURL 상태 변수의 현재 값을 얻을 수 있다.
도 111는 RequestFiles()의 일 실시예이다.
UPnP HTTP 프록시 서버 서비스 상태 변수의 다른 실시예는, ATSCProxySeverURL이라는 UPnP HTTP 프록시 서버 서비스 상태 변수를 정의할 수 있다. 또한, 이 실시예에서, GetProxyServerURL()라는 액션을 정의할 수 있다.
ATSCProxySeverURL 상태 변수는 URI의 형태로 수신기 내의 프록시 서버에 대한 참조를 포함할 수 있다. 프록시 서버는 제2 스크린 디바이스로부터 파일에 대한 HTTP 요청을 받고 인터넷 또는 방송 스트림 내의 FLUTE 세션으로부터 파일을 검색한다. 그 후, 프록시 서버는 HTTP 응답으로서 검색된 파일을 제2 스크린 디바이스로 전송한다.
GetProxyServerURL()는 ProxySeverURL의 값을 읽어 올 수 있도록 하는 액션일 수 있다. ProxySeverURL을 인수로 가질 수 있다.
UPnP HTTP 프록시 서버 서비스 상태 변수의 또 다른 실시예는, 추가로 ATSCFileList 이라는 UPnP HTTP 프록시 서버 서비스 상태 변수를 정의할 수 있다. 또한, 이 실시예에서, RequestFiles() 라는 액션을 정의할 수 있다.
방송 스트림에 존재하는 파일은 방송 콘텐츠 수신이 가능한 수신기에서만 획득이 가능할 수 있다. 그러므로 방송 콘텐츠를 수신할 수 없는 제2 스크린 디바이스 상에서 방송 콘텐츠에 포함된 파일을 접근 가능하도록 하기 위하여 필요한 UPnP 상태 변수 및 액션을 정의할 수 있다. 즉, FLUTE 세션을 통하여 다운로드 받기를 원하는 파일 리스트인 ATSCFileList를 UPnP 상태 변수로 정하거나 제2 스크린 디바이스로 하여금 수신기에 해당 파일을 요청하는 RequestFiles() 액션을 통하여 특정 파일 혹은 다수의 파일을 획득가능하도록 할 수 있다.
ATSCFileList 상태 변수는 수신기 내에 프록시 서버로의 요청된 파일의 CSV 리스트를 포함할 수 있다.
RequestFiles()는, 방송 스트림 혹은 인터넷 상에 존재하는 특정 파일을 다운로드하도록 요청하는 액션일 수 있다. 특히 방송 스트림에 존재하는 파일의 경우 요청한 파일을 FLUTE 세션을 통하여 다운로드하게 할 수 있다.
도 112는 제2 스크린 디바이스 아키텍쳐의 일 실시예이다.
동작의 이론에 대하여 설명한다.
2가지 모드의 동작이 존재할 수 있는데, 그 중 하나의 동작 모드에서는, 트리거된 애플리케이션(TDO)이 TV 수신기 상에서 실행되고, 다른 하나의 동작 모드에서는, 넌-트리거된 애플리케이션(패키지 애플리케이션)이 TV 수신기 상에서 실행된다.
TV 수신기 상에서 실행되는 트리거된 애플리케이션의 경우, TV 수신기 상에 현재 보이는 프로그래밍이 제2 스크린 지원을 갖는 연관된 인터랙티브 데이터 서비스를 가지면, 제2 스크린 디바이스의 사용자는 디바이스 상의 적절한 애플리케이션을 활성화할 수 있다. 이 애플리케이션은 UPnP 디스커버리 및 기술 프로세스를 거쳐 TV 수신기 상의 트리거 서비스, 양방향 통신 서비스 및 프록시 서버 서비스를 발견할 수 있다.
그러면, 제2 스크린 애플리케이션은 트리거 서비스에 대한 UPnP "이벤팅"을 신청하여 전달을 위해 준비된 트리거의 통지를 얻고, GetLatestUnfilteredTrigger 또는 GetLatestFilteredTrigger 액션을 이용하여 사용하도록 설계된 트리거를 획득할 수 있다. 이 결과, 제2 스크린 애플리케이션이 적절한 시간에 적절한 트리거를 얻을 수 있다. 그러면, 애플리케이션은 어떠한 방식으로 사용되도록 설계되든 이들 트리거에 대하여 동작할 수 있다.
제2 스크린 애플리케이션은 또한 양방향 통신 서비스에 대한 UPnP "이벤팅"을 신청하여 양방향 통신을 위한 접속을 요청하는데 사용될 TCP/IP 어드레스 및 포트의 통지 및 통신할 준비가될 프라이머리 디바이스에서 실행되는DO가 존재할 때의 통지를 얻을 수 있다. 그러면, 애플리케이션은 이러한 통신을 지원하는 임의의 DO와의 양방향 통신에 참여할 수 있다.
트리거들 및/또는 양방향 통신들에 의한 액션들은 종종 제2 스크린 애플리케이션이 파일을 다운로드하도록 요구할 수 있다. 이들 파일은 인터넷 상의 HTTP 서버로부터 이용가능하거나 TV 방송 내의 세션으로부터 이용가능할 수 있다 (또는 이들 양쪽으로부터 이용가능할 수 있다).
원하는 모든 파일이 인터넷을 통해 이용가능하고 제2 스크린 디바이스가 네트워크로 양호한 접속성을 가지면, 애플리케이션은 간단히 직접 파일을 검색할 수 있다.
원하는 파일의 일부 또는 전부가 TV 방송을 통해서만 이용가능하고 수신기가 HTTP 프록시 서버 서비스를 제공하면, 애플리케이션은 GetProxyURL 액션으로 프록시 서버 URL을 얻고 프록시 서버를 통해 원하는 파일을 검색할 수 있다. 애플리케이션은 또한 직접적인 방식보다는 오히려 그렇게 파일을 검색하는 것이 더 편리한 다른 상황에서 프록시 서버를 이용하도록 선택할 수 있다.
TV 수신기 상에서 실행되는 넌-트리거 애플리케이션의 경우, 현재 보이는 프로그래밍과 관계없이, 사용자는, 그중에서도, AppURL 서비스를 통해 제2 스크린 디바이스 상에서 개시될 동반자 애플리케이션의 이름 및 위치를 이용가능하게 하는 TV 수신기 상의 DO를 활성화할 수 있다.
제2 스크린 디바이스 상의 제어 포인트는 AppURL 서비스와 연관된 UPnP "이벤팅"을 신청하여 AppURL 및 AppName 속성에 대한 변경의 통지를 얻을 수 있다. 그러면, 제어 포인트는 이용가능한 서비스가 계류(pending)중이라는 것을 제2 스크린 디바이스의 사용자에게 지시한다. 후속으로, 사용자는 AppName을 보고 서비스를 선택하여, 제2 스크린 디바이스 상에서 동반자 제2 스크린 애플리케이션이 개시되도록 한다.
제2 스크린 애플리케이션은, 그 DO가 수신기에 이전에 다운로드된 방송사 제공 패키지 애플리케이션일 때에도 ATSC 2.0 수신기 상에서 실행되는 DO와 연관될 수 있고, 여기서, 방송사 제공 패키지 애플리케이션의 라이프사이클은 방송사 대신에 소비자에 의해 제어된다. 동반자 제2 스크린 애플리케이션을 식별하는 트리거의 부재시, 수신기는, 제2 스크린 디바이스 상의 제어 포인트가 GetAppURL 액션을 이용하여 공개된 제2 스크린 애플리케이션 URL을 액세스하여 제2 스크린 디바이스 상에서 개시하도록 하는 AppURL 서비스를 제공한다.
제2 스크린 디바이스 아키텍쳐의 일 실시예는, 수신기와 상호 작용하는 제2 스크린 애플리케이션과 제2 스크린 디바이스를 도시하고 있다.
제2 스크린 디바이스 아키텍쳐의 일 실시예는, 원격 콘텐츠 서버(112010), TV 수신기(112020) 및/또는 제2 스크린 디바이스(112030)를 포함할 수 있다.
원격 콘텐츠 서버(112010)는, 콘텐츠를 제공할 수 있는 서버일 수 있다. 수신기(112020) 또는 제2 스크린 디바이스(112030)에 컨텐츠를 제공할 수 있다.
TV 수신기(112020)는, UPnP 트리거 서비스 및 UPnP 프록시 서버 서비스를 제공할 수 있다. 전술한 수신기와 동일할 수 있다.
제2 스크린 디바이스(112030)는, 제2 스크린 애플리케이션(ATSC 2.0 App)을 가질 수 있고, 제2 스크린 애플리케이션은 트리거 핸들러 내에 UPnP 제어 포인트(CP) 모듈을 가질 수 있다. UPnP 제어 포인트(CP) 모듈은 제2 스크린 애플리케이션(ATSC 2.0 App) 및 TV 수신기(112020) 상의 트리거 서비스 및 프록시 서버 서비스 간의 모든 UPnP 통신을 핸들링한다. UPnP 제어 포인트(CP) 모듈은 탐색 프로세스를 관리하고, 프록시 서버 URL을 얻고, 트리거 서비스 이벤팅을 신청할 수 있다.
UPnP 트리거 서비스로부터 도달한 트리거는 트리거 핸들러로 넘겨질 수 있다. 새로운 DO가 DAE(즉, 브라우저)에서 다운로드되고 실행될 것이라는 것을 트리거가 나타내면, 트리거 핸들러는 그를 처리한다. 브라우저에서 이미 실행된 DO가 임의의 액션을 취해야 한다고 트리거가 지시하면, 트리거 핸들러는 트리거를 DO로 전달할 수 있다. 제2 스크린 디바이스의 사용자는 DO와 상호 작용할 수 있다. 트리거 핸들러는 사용자에게 보이지 않을 수 있다.
제2 스크린 애플리케이션은 필요에 따라 다음의 기능을 수행할 수 있다. 1) UPnP 디스커버리 및 기술 프로토콜을 이용하여 TV 수신기 상에서 트리거 서비스 및, 이용가능하면, 프록시 서버 서비스를 찾는다. 2) UPnP SUBSCRIBE 프로토콜을 이용하여 트리거 서비스 이벤팅을 신청한다. 3) 프록시 서버 서비스의 GetProxyURL 액션을 인보크하여 (이용가능하면) HTTP 프록시 서버의 URL을 얻는다. 4) 트리거 서비스 이벤트를 통해 전달된 트리거를 수신한다. 5) 직접 실행 트리거가 수신되고 트리거 내에서 식별된 DO가 아직 DAE에서 실행되고 있지 않으면, (필요하면 먼저 다운로드하고) DAE에서 실행하기 시작한다. 6) (필요하면 DO를 다운로드하고 시작한 후) 각 수신된 직접 실행 트리거를 트리거에서 식별된 DO로 전달한다. 7) TDO 트리거가 수신되고 트리거의 액션 속성이 "TriggerEvent" 이외의 임의의 것이면, 액션을 수행(예를 들어, TDO 실행 준비, TDO 실행, TDO 종료 등). 8) TDO 트리거가 수신되고 트리거의 액션 속성이 "TriggerEvent"이면, 트리거를 트리거의 타겟으로서 식별된 TDO로 전달한다. TDO가 DAE에서 아직 실행되고 있지 않으면, 트리거를 폐기한다. 9) 필요에 따라, 직접 인터넷 접속을 통해 TV 수신기 상의 프록시 서버 서비스를 통해 (TDO를 포함하는) 파일을 다운로드한다.
직접 실행 트리거 및 TDO 트리거는, "스프레드" 또는 "디퓨전" 속성을 포함하지 않으면, 수신 즉시 동작할 수 있다. 트리거가 "스프레드" 또는 "디퓨전" 속성을 포함하면, 액션은 랜덤 간격 동안 지연될 수 있다.
도 113는 수신기의 간략화된 구조도의 일 실시예이다.
수신기의 간략화된 구조도는, 안테나(rcvr2010), 튜너(rcvr2020), EPG(rcvr2030), VSB or DVB 복조기r(rcvr2040), 채널 매니저(rcvr2050), SI 모듈(rcvr2051), MPEG-2 TS 시스템 디코더(rcvr2060), 캡션 모듈(rcvr2070), 트리거 모듈(rcvr2080), 웹 브라우저(rcvr2090), UPnP 프레임워크(rcvr2091), 네트워크 프로토콜 스택(rcvr2100), 네트워크 인터페이스(rcvr2110), UI 모듈(rcvr2120), 오디오 디코더(rcvr2140), 비디오 디코더(rcvr2150), 스피커(rcvr2160), 디스플레이 모듈(rcvr2170), 그래픽 프로세서 (rcvr2180), 원격 제어기 수신기(rcvr2190) 및/또는 원격 제어기(rcvr2200) 를 포함할 수 있다.
안테나(rcvr2010)는 방송 스트림에 따라 방송 신호를 수신할 수 있다. 여기서, 안테나(rcvr2010)는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
튜너(rcvr2020)는 수신기의 채널을 찾거나 동조할 수 있고, 무선 주파수 증폭기, 로컬 오실레이터, 주파수 변환 및 입력 회로, 탐지기(seeker) 등을 포함할 수 있다. 튜너(rcvr2020)는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
EPG(rcvr2030)는, TV 방송의 빈 주파수대나 부가 채널을 이용하여 TV 프로그램 방송 시간과 내용, 출연자 정보 등을 보내 주는 방송 프로그램 안내 서비스일 수 있다(Electronic program guide). 수신된 EPG 데이터는 저장되었다가, 시청자가 리모컨으로 이 EPG를 조작하여 프로그램을 선택하고 예약하며, 페이 퍼 뷰 방식(pay per view) 프로그램 주문, 주제 또는 종별 프로그램 검색, 비디오 녹화 등을 할 수 있게 한다. 수신한 EPG 는 UI 모듈로도 전달될 수 있다.
VSB or DVB 복조기(rcvr2040)는 VSB 신호 또는 DVB 신호를 복조할 수 있다. VSB or DVB 복조기(rcvr2040)는 변조된 VSB or DVB (e.g., OFDM-변조 신호)를 본래의 신호로 회복할 수 있다. VSB or DVB 복조기(rcvr2040)의 복조 프로세스는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
채널 매니저(rcvr2050)는 수신된 EPG를 이용하여, 채널 관리를 수행할 수 있다. SI 모듈로 처리된 EPG를 전달할 수 있다. 일반적인 채널 매니저 역할을 할 수 있다.
SI 모듈(rcvr2051)은, MPEG-2 TS 시스템 디코더(rcvr2060)를 통하여 방송 스트림이 들어 오면 프로그램 구성 정보(Program Specific Information)을 파악할 수 있다. 이렇게 파악된 정보를 통하여 이 방송 프로그램에 몇 개의 캡션이 있으며, 트리거가 서비스 #6에 있는지 유무등을 알 수 있다.
MPEG-2 TS 시스템 디코더(rcvr2060)는 복조된 신호의 전송 스트림(TS)을 디코딩할 수 있다. MPEG-2TS 시스템 디코더(rcvr2060)는 전송 스트림으로부터 캡션 스트림을 얻어 캡션 모듈(rcvr207)로 전달할 수 있다. MPEG-2TS 시스템 디코더(rcvr2060)는 디코딩된 오디오 및 비디오 신호를 오디오/비디오 디코더로 전송할 수 있다.
캡션 모듈(rcvr2070)은 캡션 스트림을 수신할 수 있다. 캡션 모듈(rcvr2070)은 서비스 #6 또는 다른 서비스를 모니터하고 서비스 #6 또는 트리거를 송신하는 트리거가 선택되어 트리거 모듈(rcvr2080)로 전송되는지 또는 캡션 텍스트가 처리되어 스크린 상에 디스플레이되는지를 결정할 수 있다. 트리거 데이터는 트리거 모듈(rcvr2080)로 전달될 수 있다. 다른 캡션 서비스는 캡션 텍스트 처리되어 그래픽 프로세서(rcvr2180)로 전송될 수 있다. 캡션 모듈(rcvr2070)은, 전술한 SI 모듈(rcvr2051)이 파악한 정보를 통해, 현재 수신 되고 있는 디지털 캡션 중에 트리거가 있는 경우에는 트리거 모듈(rcvr2080)로 전달하게 된다.
트리거 모듈(rcvr2080)은 트리거, TPT 및/또는 AMT 정보를 파싱하고 파싱된 데이터를 처리할 수 있다. 트리거 모듈(rcvr2080)은 트리거의 URI 정보 값을 이용하여 네트워크 프로토콜 스택(rcvr2100)을 통해 네트워크를 액세스할 수 있다. URI 정보 값은 HTTP 서버의 어드레스일 수 있다. 트리거 모듈(rcvr2080)은 TPT 파일 콘텐츠를 분석하여 TDO URL을 얻을 수 있다. 또한, 트리거 모듈(rcvr2080)은 AMT를 파싱하여 데이터를 처리할 수 있다. 다른 정보는 파싱을 통해 얻을 수 있다. AMT 메시지가 수신된 후, 웹 브라우저에 대응하는 TDO URL은 소정의 시간 및 동작에 따라 전달되거나 현재 동작중인 TDO가 소정의 시간에 정지할 수 있다. 이것은 TDO 액션에 대응하고 트리거 모듈(rcvr2080)은 동작할 웹 브라우저에 코맨드를 전송할 수 있다. 본 발명에 관련된 트리거 모듈(rcvr2080)의 동작은 이하에서 상세히 설명한다. 트리거 모듈(rcvr2080)은 직간접적으로 네트워크 프로토콜 스택(rcvr2100)을 통하여 인터넷에 있는 서버에 접속할 수 있다. 트리거 모듈(rcvr2080)은 즉시 DTVCC에서 수신된 트리거를 분석하고 필요할 경우 네트워크 인터페이스(rcvr2110)를 통해, TPT 파일을 인터넷에서 다운로드 받아 처리할 수 있다. TPT 파일은 다운로드 받는 즉시 처리하여 필요한 동작을 취할 수 있다. 이때 만약 제2 스크린에 관련된 트리거이며 관련된 이벤트가 있으면 전술한 바와 같이 여러 방식으로 제2 스크린 디바이스와 통신을 할 수 있다. 이러한 통신은 후술할 UPnP 프레임워크(rcvr2091)에서 이뤄질 수 있다.
웹 브라우저(rcvr2090)는 트리거 모듈(rcvr2080)로부터 코맨드를 수신하고, UI 모듈(rcvr2120)로부터 브라우저 키 코드를 수신하고 원격 제어기 수신기(rcvr2190)로부터 브라우저 키 코드를 수신하고 네트워크 프로토콜 스택(rcvr2100)과 통신할 수 있다.
UPnP 프레임워크(rcvr2091)는, 제2 스크린 디바이스를 찾아 내고 트리거를 전송하거나 혹은 제2 스크린 디바이스에 필요한 정보들을 다시 재생성하여 전송할 수 있다. 전술한 바와 같이 네트워크 인터페이스(rcvr2110)를 통해 트리거를 받았을 때, 제2 스크린에 관련된 트리거이며 관련된 이벤트가 있으면 UPnP 프레임워크(rcvr2091)는 제2 스크린 디바이스와 통신을 할 수 있다.
네트워크 프로토콜 스택(rcvr2100)은 트리거 모듈(rcvr2080) 및 웹 브라우저와 통신하여 네트워크 인터페이스(rcvr2110)를 통해 서버를 액세스할 수 있다.
네트워크 인터페이스(rcvr2110)는 몇 개의 다른 장치의 공동 접속 또는 네트워크 컴퓨터 및 외부 네트워크의 접속을 수행한다. 네트워크 인터페이스는 서버에 접속되어 TDO, TPT, AMT 등을 다운로드할 수 있다. 여기서, 네트워크 인터페이스(rcvr2110)의 동작은 기술 분야에서 일반적으로 사용되는 네트워크 인터페이스(rcvr2110)의 동작일 수 있다. 본 발명과 관련된 네트워크 인터페이스(rcvr1090)의 동작은 이하에서 상세히 설명한다.
UI 모듈(rcvr2120)은 원격 제어기 수신기(rcvr2190)를 통해 원격 제어기(rcvr2200)를 이용하여 시청자에 의해 입력된 정보를 수신할 수 있다. 수신된 정보가 네트워크를 이용한 서비스와 관련되면, 브라우저 키 코드가 웹 브라우저로 전달될 수 있다. 수신된 정보가 현재 디스플레이되는 비디오와 관련되면, 신호는 그래픽 프로세서(rcvr2180)를 통해 디스플레이 모듈(rcvr2170)로 전달될 수 있다.
오디오 디코더(rcvr2140)는 MPEG-2TS 시스템 디코더(rcvr2060)로부터 수신된 오디오 신호를 디코딩할 수 있다. 그 후, 디코딩된 오디오 신호는 스피커로 전송되어 시청자에게 출력될 수 있다. 여기서, 오디오 디코더(rcvr2140)는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
비디오 디코더(rcvr2150)는 MPEG-2TS 시스템 디코더(rcvr2060)로부터 수신된 비디오 신호를 디코딩할 수 있다. 그 후, 디코딩된 비디오 신호는 디스플레이 모듈(rcvr2170)로 전송되어 시청자에게 출력될 수 있다. 여기서, 비디오 디코더(rcvr2150)는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
스피커(rcvr2160)는 오디오 신호를 시청자에게 출력할 수 있다. 스피커는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
디스플레이 모듈(rcvr2170)은 비디오 신호를 시청자에게 출력할 수 있다. 디스플레이 모듈(rcvr2170)은 기술 분야에서 일반적으로 사용되는 것일 수 있다.
그래픽 프로세서(rcvr2180)는 캡션 모듈(rcvr2070)로부터 수신된 캡션 텍스트 및 UI 모듈(rcvr2120)로부터 수신된 시청자 입력 정보에 대하여 그래피 처리를 수행할 수 있다. 처리된 정보는 디스플레이 모듈(rcvr2170)로 전달될 수 있다. 그래픽 프로세서(rcvr2180)는 기술 분야에서 일반적으로 사용되는 것일 수 있다.
원격 제어기 수신기(rcvr2190)는 원격 제어기(rcvr2200)로부터 정보를 수신할 수 있다. 이 때, 키 코드는 UI 모듈(rcvr2120)로 전달될 수 있고, 브라우저 키 코드는 웹 브라우저로 전달될 수 있다.
원격 제어기(rcvr2200)는 시청자에 의해 입력된 신호를 원격 제어기 수신기(rcvr2190)로 전달한다. 원격 제어기(rcvr2200)는 가상 채널을 변경하는 시청자 입력을 수신할 수 있다. 또한, 원격 제어기는 애플리케이션에 대하여 시청자에 의해 선택된 정보를 수신할 수 있다. 원격 제어기(rcvr2200)는 수신된 정보를 원격 제어기 수신기(rcvr2190)로 전달할 수 있다. 이 때, 정보는 소정 범위 밖의 거리에서 적외선(IR) 광을 이용하여 원격으로 전달될 수 있다.
도 114는 제2 스크린 디바이스의 구조도의 일 실시예이다.
제2 스크린 디바이스의 구조도 의 일 실시예는, IO 서브시스템(114010), 파일 시스템(114020), 네트워크 프로토콜 서브시스템(114030) 및/또는 기본 모듈(114040)을 포함할 수 있다.
IO 서브시스템(114010)은, 제2 스크린 디바이스에 장착될 수 있는, 외부 연결이 되는 모든 장치들이 연결되어 있을 수 있다. IO 서브시스템(114010)에는, 키패드, 디스플레이, 마이크로폰, 스피커, 스테레오 잭, 움직임 센서, 광 센서, GPS 및/또는 카메라 등이 연결될 수 있다. 각 입출력 장치들은 각각 키 모듈, 디스플레이 제어, 오디오 제어, 센서 제어 및/또는 카메라 제어에 의해 제어될 수 있다. 각 입출력 장치들은 디바이스 드라이버로 컨트롤이 되며, 각각의 센서나 카메라 등은 IO 서브시스템(114010)에 의하여 SDK형태로 함수를 호출하면 어떤 프로그램일지라도 접근이 가능할 수 있다. 경우에 따라서는 기능의 제한을 두어 네이티브 애플리케이션에서만 접근이 가능하게 만들 수도 있다.
파일 시스템(114020) 은, 외부 SD 카드에 대한 파일을 읽고 쓸 수 있도록 되어 있으며, USB에 연결하여 데이터 통신이 가능할 수 있다. SD 카드, 플래시 메모리, USB 등의 장치가 연결될 수 있다. 각각 SD 인터페이스, 플래시 메모리 제어, USB 버스 제어에 의해 제어될 수 있다.
네트워크 프로토콜 서브시스템(114030)에서는 3GPP, Wi-Fi 및/또는 블루투스 등을 통한 통신이 가능할 수 있다.
기본 모듈(114040)은, 그 밖에 제2 디바이스에서 기본적인 모듈 등이 있을 수 있다. 배터리 매니저는 제2 스크린 디바이스의 배터리량 등을 관리하며, 통지는 통신사나 혹은 제조사에서 제2 스크린 디바이스에 통지할 경우에 사용되는 모듈일 수 있다. 또한, 스토어 모듈은 제2 스크린 디바이스에서 제공하는 오픈 SDK를 이용하여 만들어진 제2 스크린용 애플리케이션들을 구매하는 모듈일 수 있다. 애플리케이션 매니저는 스토어 모듈을 이용하여 설치된 애플리케이션을 관리하며 설치된 애플리케이션이 업그레이드 된 경우에도 애플리케이션 매니저가 알려 줄 수 있다. 또한 제2 스크린 디바이스에서 인터넷 접속을 할 수 있도록 웹 모듈이 내장되어 있을 수 있다. 개인의 취향에 따라서 제2 스크린의 여러가지 기능들에 대한 편의 설정을 할 수 있는데, 사용자 선호 프로그램을 이용할 수 있다.
기본 모듈(114040)은, 그 외에 여러가지 기능들을 가지고 있으며 기본적으로 제2 스크린 디바이스에 내장이 되어 있어야 하는 프로그램들일 수 있다. 그러나 점선으로 되어 있는 모듈들은 선택적으로 사용자가 설치를 하면 동작이 되는 소프트웨어 모듈들일 수 있다.
예를 들어 UPnP 프레임워크 모듈은 기본적으로 제2 스크린 디바이스에서 지원하지 않을 수 있지만, 내장되어 있을 수도 있다. 내장될 경우에는 네이티브 애플리케이션도 함께 내장이 되어 UPnP 동작을 원활하게 해야 할 수 있다. 그러나 본 수신기 구조도 에서는 UPnP 프레임워크는 선택적으로 사용자가 제2 스크린 서비스 애플리케이션이나 혹은 UPnP 프레임워크를 지원하는 애플리케이션을 설치해야 될 수 있다. UPnP 프레임워크 모듈을 통해, 지상파를 수신할 수 있는 수신기를 찾을 수 있다.
도 115는 제2 스크린 디바이스 시나리오의 일 실시예이다.
제2 스크린 디바이스 시나리오의 일 실시예에 대해 설명한다.
제2 스크린 디바이스 시나리오의 일 실시예는, 트리거를 수신하는 단계(s115010), TPT를 요청하는 단계(s115020), 응답으로서 TPT를 전송하는 단계(s115030), TDO를 요청하는 단계(s115040), 응답으로서 TDO를 전송하는 단계(s115050), TDO를 실행하는 단계(s115060), scanDeviceList 메시지를 전송하는 단계(s115070), 디스커버리 기능을 호출하는 단계(s115080), UPnP 애플리케이션을 실행하는 단계(s115090), 서칭 메시지를 멀티캐스팅하는 단계 (s115100), UPnP 프레임워크를 통지하는 단계(s115110), 장치 리스트를 반환하는 단계(s115120), 장치 핸들을 반환하는 단계(s115130), scanServiceList 메시지를 전송하는 단계(s115140), 서비스 리스트 기능을 호출하는 단계 (s115150), GetServiceDescription 메시지를 전송하는 단계(s115160), HTTP 메시지를 전송하는 단계(s115170), 서비스 리스트를 반환하는 단계(s115180), 서비스 핸들의 리스트를 반환하는 단계 (s115190), hnHandle 메시지를 전송하는 단계(s115200), 서비스 리스트 기능을 호출하는 단계(s115210), GetDeviceProfile 메시지를 전송하는 단계(s115220), HTTP 메시지를 전송하는 단계(s115230), soap 응답을 반환하는 단계(s115240), soap 응답 XML을 반환하는 단계(s115250), soap 응답을 파싱하는 단계(s115260), hnHandle 메시지를 전송하는 단계(s115270), 서비스 리스트 기능을 호출하는 단계 (s115280), InputUIListing 메시지를 전송하는 단계(s115290), HTTP 메시지를 전송하는 단계(s115300), soap 응답을 반환하는 단계(s115310), TimeToLive를 반환하는 단계(s115320), hnHandle 메시지를 전송하는 단계(s115330), 서비스 리스트 기능을 호출하는 단계(s115340), DisplayMessage 전송하는 단계(s115350), HTTP message를 전송하는 단계(s115360), 널(null)을 반환하는 단계(s115370), 널을 반환하는 단계(s115380) 및/또는 제2 스크린 애플리케이션을 실행하는 단계 (s115390)를 포함할 수 있다.
트리거를 수신하는 단계(s115010)는 방송사로부터 방송 스트림을 통해 DTVCC iTV 메시지로 트리거를 수신하는 단계일 수 있다.
TPT를 요청하는 단계(s115020)는 수신한 트리거를 파싱하고 해석하여, 방송사 인터넷 서버에 관련된 TPT를 요청하는 단계일 수 있다.
응답으로서 TPT를 전송하는 단계(s115030)는 요청받은 TPT를 보내주는 단계일 수 있다.
TDO를 요청하는 단계(s115040)는, 관련된 TDO를 다운로드 받아야할 필요가 있을 경우, 방송사 인터넷 서버에 관련 TDO를 요청하는 단계일 수 있다.
응답으로서 TDO를 전송하는 단계(s115050) 는 요청받은 TDO를 보내주는 단계일 수 있다.
TDO를 실행하는 단계(s115060) 는 트리거 모듈이 TDO를 실행시키는 단계일 수 있다.
scanDeviceList 메시지를 전송하는 단계(s115070)는 실행된 DO(또는 TDO)가 디바이스 스캔을 위하여 디바이스 리스트를 스캔할 것을 요청하는 메시지를 보내는 단계일 수 있다.
디스커버리 기능을 호출하는 단계(s115080)는 디바이스 디스커버리를 위하여 UPnP 프레임워크의 디스커버리 기능을 호출하는 단계일 수 있다.
UPnP 애플리케이션(s115090)은, 제2 스크린 디바이스에서 제2 스크린 서비스 런처용 UPnP 애플리케이션을 실행하는 단계일 수 있다. 이 단계는 프라이머리 디바이스와 독립적인 단계로, UPnP 애플리케이션을 실행하는 단계(s115090) 이전에 실행될 수도 있다.
서칭 메시지를 멀티캐스트하는 단계(s115100)는, UPnP 프레임워크가 제2 스크린 디바이스를 찾는 서칭 메시지를 홈 네트워크 내에 멀티캐스트하는 단계일 수 있다.
UPnP 프레임워크를 통지하는 단계(s115110)는 서칭 메시지를 받은 제2 스크린 디바이스가 통지 메시지를 프라이머리 디바이스로 전송하는 단계일 수 있다. 이로서 제2 스크린 디바이스의 존재를 알릴 수 있다.
디바이스 리스트를 반환하는 단계(s115120)는 UPnP 프레임워크가 디바이스 디스커버리 후에, 디바이스 리스트를 반환하는 단계일 수 있다.
디바이스 핸들을 반환하는 단계(s115130)는 전달 받은 디바이스 리스트를 DO에 전달하는 단계일 수 있다.
scanServiceList 메시지를 전송하는 단계(s115140)는 실행된 DO(또는 TDO)가 서비스 스캔을 위하여 서비스 리스트를 스캔할 것을 요청하는 메시지를 보내는 단계일 수 있다.
서비스 리스트 기능을 호출하는 단계(s115150)는 서비스 디스커버리를 위하여, UPnP 프레임워크의 서비스 리스트 기능을 호출하는 단계일 수 있다.
GetServiceDescription 메시지를 전송하는 단계(s115160)는, 제2 스크린 디바이스의 서비스 기술을 얻기 위하여 제2 스크린 디바이스에 요청하는 단계일 수 있다.
HTTP 메시지를 전송하는 단계(s115170)는, GetServiceDescription 메시지를 전송하는 단계(s115160)에서의 요청에 대한 결과를 보내주는 것으로 전술한 바와 같이 HTTP/1.1 200 OK(성공) 같은 메시지를 보낼 수 있다. 서비스 기술을 XML 형태로 전달받을 수도 있다.
서비스 리스트를 반환하는 단계(s115180)는, UPnP 프레임워크가 서비스 기술을 받은 후 서비스 리스트를 반환하는 단계일 수 있다.
서비스 핸들의 리스트를 반환하는 단계(s115190)는 전달받은 서비스 리스트를 리턴하는 단계일 수 있다.
hnHandle 메시지를 전송하는 단계(s115200)는, 디바이스 프로파일을 얻기 위하여 메시지를 보내는 단계일 수 있다.
서비스 리스트 기능을 호출하는 단계(s115210)는 서비스 디스커버리를 위하여, UPnP 프레임워크의 서비스 리스트 기능을 호출하는 단계일 수 있다.
GetDeviceProfile 메시지를 전송하는 단계(s115220)는, 제2 스크린 디바이스의 서비스 기술을 얻기 위하여 제2 스크린 디바이스에 요청하는 단계일 수 있다. 전술한 GetDeviceProfile 액션을 이용할 수 있다.
HTTP 메시지를 전송하는 단계(s115230)는 GetDeviceProfile 메시지를 전송하는 단계(s115220)에서의 요청에 대한 결과를 보내주는 것으로 전술한 바와 같이 HTTP/1.1 200 OK(성공) 같은 메시지를 보낼 수 있다. 디바이스 프로파일을 전달받을 수도 있다.
soap 응답을 반환하는 단계(s115240)는 전달받은 디바이스 프로파일을 반환해주는 단계일 수 있다.
soap 응답 XML을 반환하는 단계(s115250)는, 전달받은 디바이스 프로파일을 XML 형태로 반환해주는 단계일 수 있다.
soap 응답을 파싱하는 단게(s115260)는 DO가 전달받은 SOAP message를 파싱하는 단계일 수 있다.
hnHandle 메시지를 전송하는 단계(s115270)는, 제2 스크린 서비스의 URL 주소를 제2 스크린 디바이스에 알려주기 위해 메시지를 보내는 단계일 수 있다.
서비스 호출 리스트 기능을 호출하는 단계(115280)는 UPnP 프레임워크의 서비스 리스트 기능을 호출하는 단계일 수 있다.
InputUIListing 메시지를 전송하는 단계(s115290)는 제2 스크린 서비스의 URL 주소를 제2 스크린 디바이스에 알려주는 단계일 수 있다. 전술한 AddUIListing 액션을 이용할 수 있다. 제2 스크린 디바이스는 획득한 URL을 UIListing 에 추가할 수 있다.
HTTP 메시지를 전송하는 단계(s115300)는 InputUIListing 메시지를 전송하는 단계(s115290)에서의 요청에 대한 결과를 보내주는 것으로 전술한 바와 같이 HTTP/1.1 200 OK(성공) 같은 메시지를 보낼 수 있다.
soap 응답을 반환하는 단계(s115310)는 URL 의 전송이 이루어졌음을 알려주기 위한 메시지를 반환하는 단계일 수 있다.
TimeToLive를 반환하는 단계(s115320)는, HTTP message를 전송하는 단계(s115300)와 마찬가지로, InputUIListing 메시지를 전송하는 단계(s115290)에서의 요청에 대한 결과를 보내주는 것일 수 있다.
hnHandle 메시지를 전송하는 단계(s115330)는, 디스플레이 메시지를 제2 스크린 디바이스에 전달하기 위하여, 메시지를 보내는 단계일 수 있다.
서비스 리스트 기능을 호출하는 단계(s115340)는, UPnP 프레임워크의 서비스 리스트 기능을 호출하는 단계일 수 있다.
DisplayMessage를 전송하는 단계(s115350)는 제2 스크린 디바이스에 디스플레이 메시지를 전송하는 단계일 수 있다. 디스플레이 메시지는 메시지 타입 등의 정보를 포함할 수 있다. 전술한 DispalyMessage 액션을 이용할 수 있다. 제2 스크린 디바이스는 디스플레이 메시지에 따라, 메시지를 제2 스크린에 디스플레이할 수 있다.
HTTP 메시지를 전송하는 단계(s115360)는 DisplayMessage를 전송하는 단계(s115350)에 대한 결과를 보내주는 것으로 전술한 바와 같이 HTTP/1.1 200 OK(성공) 같은 메시지를 보낼 수 있다.
널을 반환하는 단계(s115370)는 HTTP/1.1 200 OK를 받은 경우, 널(Null)을 반환하는 단계일 수 있다.
널을 반환하는 단계 (s115380)는 마찬가지로 널을 응답으로 받은 경우 DO에 널을 반환하는 단계일 수 있다.
제2 스크린 애플리케이션을 실행하는 단계(s115390)는 제2 스크린 디바이스에서 제2 스크린 애플리케이션을 실행하는 단계일 수 있다.
도 116은 프라이머리 디바이스에서 디지털 서비스 신호를 처리하는 방법의 실시예를 나타내는 도면이다.
프라이머리 디바이스에서 디지털 서비스 신호를 처리하는 방법의 실시예는 프라이머리 애플리케이션을 실행하는 단계(s116010), 인터랙티브 서비스의 메시지를 송신하는 단계(s116020), 기술에 대한 요청을 수신하는 단계(s116030), 기술을 송신하는 단계(s116040), 및/또는 인터랙티브 서비스를 제공하는 단계(s116050)를 포함할 수 있다.
프라이머리 애플리케이션을 실행하는 단계(s116010)는 프라이머리 디바이스가 디지털 서비스 신호에 대한 프라이머리 애플리케이션을 실행하는 단계일 수 있다. 여기서, 프라이머리 애플리케이션은 트리거된 애플리케이션 또는 트리거되지 않은 애플리케이션일 수 있다. 여기서, 프라이머리 디바이스는 상술한 TV 수신기일 수 있다. 여기서, 프라이머리 애플리케이션은 TV 수신기에 의해 실행될 수 있는 DO를 지칭할 수 있다. 여기서, 프라이머리 애플리케이션은 DO, TDO, NDO, 또는 UDO일 수 있다.
인터랙티브 서비스의 메시지를 송신하는 단계(s116020)에서, 메시지는 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지를 지칭할 수 있다. 여기서, 상술한 메시지는 프라이머리 디바이스로부터 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 애플리케이션)으로 송신될 수 있다. 여기서, 인터랙티브 서비스는 트리거된 애플리케이션에 관련된 제1 모드 또는 트리거되지 않은 애플리케이션에 관련된 제2 모드를 포함할 수 있다. 여기서, 세컨더리 애플리케이션은 상술한 프라이머리 애플리케이션 및 제2 스크린 디바이스에 의해 실행되는 애플리케이션과 연관될 수 있다. 애플리케이션은 DO, TDO, NDO, 또는 UDO일 수 있다. 여기서, 트리거된 애플리케이션은 TDO를 지칭하고 트리거되지 않은 애플리케이션은 NDO를 지칭할 수 있다.
기술에 대한 요청을 수신하는 단계(s116030)는 프라이머리 디바이스가 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 애플리케이션)로부터 기술을 수신하는 단계일 수 있다. 여기서, 기술은 상술한 인터랙티브 서비스를 식별하는 기술을 지칭할 수 있다.
기술을 송신하는 단계(s116040)는 프라이머리 디바이스가 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 애플리케이션)로 요청된 기술을 송신하는 단계일 수 있다. 여기서, 기술은 기술에 기술된 인터랙티브 서비스의 각각의 서비스 타입 정보 또는 서비스 id 정보를 포함할 수 있다. 여기서, 서비스 id 정보는 인터랙티브 서비스의 각각을 식별할 수 있다. 여기서, 서비스 타입 정보는 인터랙티브 서비스의 각각의 타입을 나타낼 수 있다.
인터랙티브 서비스를 제공하는 단계(s116050)는 프라이머리 디바이스가 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 애플리케이션)에 인터랙티브 서비스를 제공하는 단계일 수 있다. 인터랙티브 서비스는 인터랙티브 서비스에 대한 정보를 제공함으로써 제공될 수 있다.
본 발명의 일 실시예에서, 상술한 인터랙티브 서비스에 대한 정보는 인터랙티브 서비스의 각각에 따라 정의될 수 있다. 또한, 상술한 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나일 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 트리거에 대응하면, 프라이머리 디바이스는 트리거 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 바이트에 대응하면, 프라이머리 디바이스는 양방향 통신 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 URL 정보이면, 프라이머리 디바이스는 AppURL 서비스를 제공할 수 있다.
본 발명의 다른 실시예에서, 상술한 인터랙티브 서비스에 대한 정보는 트리거일 수 있다. 또한, 트리거 중의 적어도 하나는 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함할 수 있다. 본 실시예는 상술한 트리거 서비스가 상술한 채널 변경 트리거를 송신하는 경우에 대응할 수 있다. 채널 변경 정보를 포함하는 적어도 하나의 트리거는 상술한 채널 변경 트리거를 지칭할 수 있다. 채널 변경 정보는 변경된 채널 번호를 나타내는 값을 가질 수 있다.
본 발명의 다른 실시예에서, 상술한 인터랙티브 서비스에 대한 정보가 트리거이면, 방법은 TPT 내의 정보와 결합함으로써 트리거를 증가(augment)시키는 단계, TPT는 트리거된 애플리케이션에 대한 메타데이터를 포함하고; 및 트리거 내의 식별된 이벤트를 나타내는 이벤트 지시자를 갖는 증가된 트리거를 송신하는 단계를 더 포함할 수 있다. 여기서, "인터랙티브 서비스에 대한 정보가 트리거이면"은 프라이머리 디바이스가 트리거 서비스를 제공하는 경우를 지칭할 수 있다. 본 실시예는 상술한 증가된 트리거가 생성 및 송신되는 경우에 대응할 수 있다. "TPT 내의 정보와 결합함으로써 트리거를 증가시키는 단계"는 TPT 내에 포함되는 정보 및 트리거를 결합하는 단계일 수 있다. 여기서, 이벤트 지시기는 상술한 AugmentedTrigger 내의 이벤트 엘리먼트를 지칭할 수 있다.
본 발명의 다른 실시예에서, 상술한 인터랙티브 서비스에 대한 정보가 바이트일 수 있다. 또한, 인터랙티브 서비스는 애플리케이션이 실행되어 세컨더리 애플리케이션과의 통신에 참여할 준비가 되어 있는지를 나타내는 status 상태 변수를 포함할 수 있다. 또한, 방법은 status 상태 변수를 설정하는 단계를 더 포함할 수 있다. 본 실시예는 프라이머리 디바이스가 양방향 통신 서비스를 제공하는 경우를 지칭할 수 있다. 여기서, status 상태 변수는 상술한 양방향 통신 서비스의 제2 어프로치에서의 Status 상태 변수를 지칭할 수 있다. 여기서, "status 상태 변수를 설정하는 단계"는 상술한 setStatusYes(), setStatusNo() or setStatus() API를 이용하는 경우를 지칭할 수 있다.
본 발명의 다른 실시예에서, 프라이머리 애플리케이션은 API를 이용하여 인터랙티브 서비스를 제공한다. 본 실시예는 프라이머리 디바이스가 양방향 통신 서비스를 제공하는 경우를 지칭할 수 있다. 여기서, API는 상술한 양방향 통신 서비스의 API 중 sendBytes API를 지칭할 수 있다.
본 발명의 다른 실시예에서, API는 바이트 및 바이트 인수에 대한 어드레스 및 포트에 관한 정보를 갖는 어드레스 인수를 포함할 수 있다. 여기서, 어드레스 인수는 sendBytes API의 어드레스 인수를 지칭할 수 있다. 여기서, 바이트 인수는 sendBytes API의 바이트 인수를 지칭할 수 있다.
본 발명의 다른 실시예에서, 방법은 메시지를 송신하기 전에 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 수신하는 단계를 더 포함할 수 있다. 제2 스크린 디바이스는 요청을 프라이머리 디바이스로 전송할 수 있다. 요청은 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 것이다. 여기서, 메시지는 상술한 디스커버리 메시지를 지칭할 수 있다. 프라이머리 디바이스가 메시지에 대한 요청을 수신하면, 프라이머리 디바이스는 메시지를 제2 스크린 디바이스로 송신할 수 있다. 본 실시예는 디바이스 디스커버리 또는 서비스 디스커버리에 대응할 수 있다.
도 117은 세컨더리 애플리케이션에서 디지털 서비스 신호를 처리하는 방법의 실시예를 나타내는 도면이다.
세컨더리 애플리케이션에서 디지털 서비스 신호를 처리하는 방법의 실시예는 애플리케이션을 실행하는 단계(s117010), 인터랙티브 서비스의 메시지를 수신하는 단계(s117020), 기술에 대한 요청을 전송하는 단계(s117030), 기술을 수신하는 단계(s117040), 통지를 위한 프로토콜에 가입하는 단계 (s117050), 통지를 수신하는 단계(s117060), 수신된 통지를 이용하여 정보를 수신하는 단계(s117070), 및/또는 파일을 다운로드하는 단계(s117080)를 포함할 수 있다.
애플리케이션을 실행하는 단계(s117010)는 제2 스크린 디바이스가 디지털 서비스 신호에 대한 애플리케이션을 실행하는 단계일 수 있다. 여기서, 애플리케이션은 제2 스크린 디바이스에 의해 실행될 수 있는 DO, TDO, NDO, 또는 UDO를 지칭할 수 있다.
인터랙티브 서비스의 메시지를 수신하는 단계(s117020)에서, 메시지는 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지를 지칭할 수 있다. 여기서, 메시지는 프라이머리 디바이스로부터 제2 스크린 디바이스로 송신될 수 있다.
기술에 대한 요청을 전송하는 단계(s117030)는 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 제2 스크린 애플리케이션)가 프라이머리 다바이스에 기술을 요청하는 단계일 수 있다. 여기서, 기술은 인터랙티브 서비스를 식별할 수 있다.
기술을 수신하는 단계(s117040)는 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 제2 스크린 애플리케이션)가 프라이머리 디바이스에 의해 요청된 기술을 수신하는 단계일 수 있다. 여기서, 기술은 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 인터랙티브 서비스의 각각에 대한 타입을 나타내는 서비스 타입 정보를 가질 수 있다.
통지를 위한 프로토콜에 가입하는 단계(s117050), 통지를 수신하는 단계(s117060), 및 수신된 통지를 이용하여 정보를 수신하는 단계(s117070)는 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 제2 스크린 애플리케이션)가 상술한 기술을 이용하여 적어도 하나의 인터랙티브 서비스에 접근하는 단계에 포함될 수 있다.
통지를 위한 프로토콜에 가입하는 단계(s117050)는 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 제2 스크린 애플리케이션)가 프라이머리 디바이스에 의해 제공된 적어도 하나의 인터랙티브 서비스에 대한 통지에 프로토콜에 가입하는 단계일 수 있고, 이는 "이벤팅" 프로토콜"에 가입하는 상술한 단계일 수 있다.
통지를 수신하는 단계(s117060)는 프라이머리 디바이스로부터 인터랙티브 서비스에 대한 통지를 수신하는 상술한 단계일 수 있다. 통지는 상술한 비동기 통지일 수 있다.
수신된 통지를 이용하여 정보를 수신하는 단계(s117070)는 수신된 통지를 이용하여 인터랙티브 서비스에 대한 정보를 수신하는 단계일 수 있다.
파일을 다운로드하는 단계(s117080)는 어프로치 인터랙티브 서비스에 대한 파일을 다운로드하는 단계일 수 있다. 파일은 상술한 애플리케이션일 수 있다.
본 발명의 일 실시예에서, 상술한 인터랙티브 서비스에 대한 정보는 인터랙티브 서비스의 각각에 따라 정의될 수 있다. 또한, 상술한 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나일 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 트리거에 대응하면, 프라이머리 디바이스는 트리거 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 바이트에 대응하면, 프라이머리 디바이스는 양방향 통신 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 URL 정보이면, 프라이머리 디바이스는 AppURL 서비스를 제공할 수 있다.
본 발명의 다른 실시예에서, 탐색된 인터랙티브 서비스에 대한 정보가 트리거이면, 트리거의 적어도 하나는 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함할 수 있다. 본 실시예는 상술한 트리거 서비스가 상술한 채널 변경 트리거를 송신하는 경우에 대응할 수 있다. 채널 변경 정보를 포함하는 적어도 하나의 트리거는 상술한 채널 변경 트리거를 지칭할 수 있다. 채널 변경 정보는 변경된 채널 번호를 나타내는 값을 가질 수 있다.
본 발명의 다른 실시예에서, 상술한 액세스된 인터랙티브 서비스에 대한 정보가 바이트이면, 방법은 수신된 통지를 이용하여 인터랙티브 서비스가 시작할 준비가 되었는지를 결정하는 단계 및 수신된 통지를 이용하여 바이트를 송신하기 위한 접속에 대한 요청을 송신하는 단계를 더 포함한다. 본 실시예는 상술한 양방향 통신 서비스가 제공되는 경우에 대응할 수 있다. 본 실시예에서, 통지는 프라이머리 디바이스에 의해 실행되는 DO가 통신할 준비가 되어 있는지를 나타내기 위한 것일 수 있다. 본 실시예에서, 바이트를 송신하기 위한 접속은 TCP/IP 접속일 수 있다. 또한, 본 실시예는 프라이머리 디바이스로의 TCP/IP 접속을 요청하는 동작에 대응할 수 있다.
본 발명의 다른 실시예에서, 방법은 메시지를 수신하기 전에 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 전송하는 단계를 더 포함한다. 제2 스크린 디바이스는 요청을 프라이머리 디바이스로 전송할 수 있다. 요청은 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 것이다. 메시지는 상술한 디스커버리 메시지를 지칭할 수 있다. 프라이머리 디바이스가 메시지에 대한 요청을 수신하면, 프라이머리 디바이스는 메시지를 제2 스크린 디바이스로 송신할 수 있다. 본 실시예는 디바이스 디스커버리 또는 서비스 디스커버리에 대응할 수 있다.
도 118는 프라이머리 디바이스로서 디지털 서비스 신호를 처리하는 장치의 실시예를 나타내는 도면이다.
프라이머리 디바이스로서 디지털 서비스 신호를 처리하는 장치의 실시예는 실행 모듈(118010), 송신 모듈(118020), 수신 모듈(118030), 및/또는 제공 모듈(118040)을 포함할 수 있다.
실행 모듈(118010)은 디지털 서비스 신호에 대한 프라이머리 애플리케이션을 실행하도록 구성될 수 있다. 여기서, 프라이머리 애플리케이션은 트리거된 애플리케이션 또는 트리거되지 않은 애플리케이션일 수 있다. 여기서, 프라이머리 디바이스는 상술한 TV 수신기일 수 있다. 여기서, 프라이머리 애플리케이션은 TV 수신기에 의해 실행될 수 있는 DO를 지칭할 수 있다. 여기서, 프라이머리 애플리케이션은 DO, TDO, NDO, 또는 UDO일 수 있다.
송신 모듈(118020)은 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지를 송신하도록 구성될 수 있다. 또한, 송신 모듈(118020)은 인터랙티브 서비스를 식별하는 기술을 송신하도록 구성될 수 있다. 여기서, 인터랙티브 서비스는 트리거된 애플리케이션과 관련된 제1 모드 또는 트리거되지 않은 애플리케이션과 관련된 제2 모드를 포함할 수 있다. 여기서, 기술은 요청에 따라 송신될 수 있다. 상술한 메시지는 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 애플리케이션)로 송신될 수 있다. 여기서, 세컨더리 애플리케이션은 상술한 프라이머리 애플리케이션과 연관된 애플리케이션 및 제2 스크린 디바이스에 의해 실행된 애플리케이션일 수 있다. 애플리케이션은 DO, TDO, NDO, 또는 UDO일 수 있다. 여기서, 트리거된 애플리케이션은 TDO를 지칭하고 트리거되지 않은 애플리케이션은 NDO를 지칭할 수 있다.
수신 모듈(118030)은 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 인터랙티브 서비스의 각각의 타입을 식별하는 서비스 타입 정보를 갖는 기술에 대한 요청을 수신하도록 구성될 수 있다. 여기서, 기술은 기술에 기술된 인터랙티브 서비스의 각각의 서비스 타입 정보 및 서비스 id 정보를 포함할 수 있다.
여기서, 송신 모듈(118020) 및 수신 모듈(118030)은 설계자의 의도에 따라 하나의 모듈에 포함될 수 있다.
제공 모듈(118040)은 인터랙티브 서비스에 대한 정보를 송신함으로써 인터랙티브 서비스를 제공하도록 구성될 수 있다. 제공 모듈(118040)은 인터랙티브 서비스를 제2 스크린 디바이스(또는 제2 스크린 디바이스에 의해 실행되는 애플리케이션)에 제공할 수 있다.
본 발명의 실시예에서, 상술한 인터랙티브 서비스에 대한 정보는 인터랙티브 서비스의 각각에 따라 정의될 수 있다. 또한, 상술한 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나일 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 트리거에 대응하면, 프라이머리 디바이스는 트리거 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 바이트에 대응하면, 프라이머리 디바이스는 양방향 통신 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 URL 정보이면, 프라이머리 디바이스는 AppURL 서비스를 제공할 수 있다.
본 발명의 다른 실시예에서, 상술한 인터랙티브 서비스에 대한 정보는 트리거일 수 있다. 또한, 트리거 중의 적어도 하나는 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함할 수 있다. 본 실시예는 상술한 트리거 서비스가 상술한 채널 변경 트리거를 송신하는 경우에 대응할 수 있다. 채널 변경 정보를 포함하는 적어도 하나의 트리거는 상술한 채널 변경 트리거를 지칭할 수 있다. 채널 변경 정보는 변경된 채널 번호를 나타내는 값을 가질 수 있다.
본 발명의 다른 실시예에서, 상술한 인터랙티브 서비스에 대한 정보가 트리거이면, 장치는 증가 모듈을 더 포함할 수 있다. 증가 모듈은 TPT 내의 정보와 결합함으로써 트리거를 증가하도록 구성될 수 있다. TPT는 트리거된 애플리케이션에 대한 메타데이터를 포함할 수 있다. 상술한 송신 모듈은 또한 트리거 내의 식별된 이벤트를 나타내는 이벤트 지시자를 갖는 증가된 트리거를 송신할 수 있다. 여기서, "인터랙티브 서비스에 대한 정보가 트리거이면"은 프라이머리 디바이스가 트리거 서비스를 제공하는 경우를 지칭할 수 있다. 본 실시예는 상술한 증가된 트리거가 생성 및 송신되는 경우에 대응할 수 있다. 증가 모듈은 TPT 내에 포함되는 정보 및 트리거를 결합할 수 있다. 여기서, 이벤트 지시기는 상술한 AugmentedTrigger 내의 이벤트 엘리먼트를 지칭할 수 있다.
본 발명의 다른 실시예에서, 상술한 인터랙티브 서비스에 대한 정보가 바이트일 수 있다. 또한, 인터랙티브 서비스는 애플리케이션이 실행되어 세컨더리 애플리케이션과의 통신에 참여할 준비가 되어 있는지를 나타내는 status 상태 변수를 포함할 수 있다. 또한, 장치는 status 상태 변수를 설정하는 것을 더 포함할 수 있다. 본 실시예는 프라이머리 디바이스가 양방향 통신 서비스를 제공하는 경우를 지칭할 수 있다. 여기서, status 상태 변수는 상술한 양방향 통신 서비스의 제2 어프로치에서의 Status 상태 변수를 지칭할 수 있다. 여기서, "status 상태 변수를 설정하는 단계"는 상술한 setStatusYes(), setStatusNo() or setStatus() API를 이용하는 경우를 지칭할 수 있다.
본 발명의 다른 실시예에서, 프라이머리 애플리케이션은 API를 이용하여 인터랙티브 서비스를 제공한다. 본 실시예는 프라이머리 디바이스가 양방향 통신 서비스를 제공하는 경우를 지칭할 수 있다. 여기서, API는 상술한 양방향 통신 서비스의 API 중 sendBytes API를 지칭할 수 있다.
본 발명의 다른 실시예에서, API는 바이트 및 바이트 인수에 대한 어드레스 및 포트에 관한 정보를 갖는 어드레스 인수를 포함할 수 있다. 여기서, 어드레스 인수는 sendBytes API의 어드레스 인수를 지칭할 수 있다. 여기서, 바이트 인수는 sendBytes API의 바이트 인수를 지칭할 수 있다. 본 발명의 다른 실시예에서, 수신 모듈은 또한 송신 모듈이 메시지를 송신하기 전에 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 수신하도록 구성될 수 있다. 제2 스크린 디바이스는 요청을 프라이머리 디바이스로 전송할 수 있다. 요청은 프라이머리 애플리케이션과 연관된 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 것이다. 여기서, 메시지는 상술한 디스커버리 메시지를 지칭할 수 있다. 프라이머리 디바이스가 메시지에 대한 요청을 수신하면, 프라이머리 디바이스는 메시지를 제2 스크린 디바이스로 송신할 수 있다. 본 실시예는 디바이스 디스커버리 또는 서비스 디스커버리에 대응할 수 있다.
도 119는 세컨더리 애플리케이션으로서 디지털 서비스 신호를 처리하는 장치의 실시예를 나타내는 도면이다.
세컨더리 애플리케이션으로서 디지털 서비스 신호를 처리하는 장치의 실시예는 실행 모듈(119010), 수신 모듈(119020), 전송 모듈(119030), 액세스 모듈(119040), 및/또는 다운로드 모듈(119050)을 포함할 수 있다.
실행 모듈(119010)은 디지털 서비스 신호에 대한 애플리케이션을 실행하도록 구성될 수 있다. 여기서, 애플리케이션은 제2 스크린 디바이스에 의해 실행될 수 있는 DO, TDO, NDO, 또는 UDO를 지칭할 수 있다.
수신 모듈(119020)은 실행된 애플리케이션 및 기술에 대한 인터랙티브 서비스의 메시지를 수신하도록 구성될 수 있다. 여기서, 메시지는 프라이머리 디바이스로부터 송신될 수 있다. 여기서, 기술은 프라이머리 디바이스에 의해 요청될 수 있다. 여기서, 기술은 인터랙티브 서비스를 식별할 수 있다.
전송 모듈(119030)은 인터랙티브 서비스를 식별하는 기술에 대한 요청을 전송하도록 구성될 수 있다. 여기서, 기술은 인터랙티브 서비스의 각각을 식별하는 서비스 id 정보 및 인터랙티브 서비스의 각각에 대한 타입을 나타내는 서비스 타입 정보를 가질 수 있다.
액세스 모듈(119040)은 기술을 이용하여 적어도 하나의 인터랙티브 서비스를 액세스하도록 구성될 수 있다. 액세스 모듈(119040)은 또한 적어도 하나의 인터랙티브 서비스에 대한 통지를 위한 프로토콜에 가입할 수 있고, 이는 "이벤팅" 프로토콜에 가입하는 상술한 동작에 대응한다. 액세스 모듈(119040)은 또한 통지를 수신할 수 있다. 통지는 상술한 비동기 통지일 수 있다. 액세스 모듈(119040)은 또한 수신된 통지를 이용하여 적어도 하나의 인터랙티브 서비스에 대한 정보를 수신할 수 있다.
다운로드 모듈(119050)은 액세스된 인터랙티브 서비스에 대한 파일을 다운로드하도록 구성될 수 있다. 여기서, 파일은 상술한 애플리케이션일 수 있다.
본 발명의 일 실시예에서, 상술한 인터랙티브 서비스에 대한 정보는 인터랙티브 서비스의 각각에 따라 정의될 수 있다. 또한, 상술한 인터랙티브 서비스에 대한 정보는 트리거, 바이트 및 URL 정보 중의 하나일 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 트리거에 대응하면, 프라이머리 디바이스는 트리거 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 바이트에 대응하면, 프라이머리 디바이스는 양방향 통신 서비스를 제공할 수 있다. 여기서, 인터랙티브 서비스에 대한 상술한 정보가 URL 정보이면, 프라이머리 디바이스는 AppURL 서비스를 제공할 수 있다.
본 발명의 다른 실시예에서, 탐색된 인터랙티브 서비스에 대한 정보가 트리거이면, 트리거의 적어도 하나는 디지털 서비스 신호의 채널의 변경된 번호를 나타내는 값을 갖는 채널 변경 정보를 포함할 수 있다. 본 실시예는 상술한 트리거 서비스가 상술한 채널 변경 트리거를 송신하는 경우에 대응할 수 있다. 채널 변경 정보를 포함하는 적어도 하나의 트리거는 상술한 채널 변경 트리거를 지칭할 수 있다. 채널 변경 정보는 변경된 채널 번호를 나타내는 값을 가질 수 있다.
본 발명의 다른 실시예에서, 상술한 액세스된 인터랙티브 서비스에 대한 정보가 바이트이면, 액세스 모듈(119040)은 또한 수신된 통지를 이용하여 인터랙티브 서비스가 시작할 준비가 되었는지를 결정할 수 있다. 또한, 액세스 모듈(1109040)은 수신된 통지를 이용하여 바이트를 송신하기 위한 접속에 대한 요청을 송신할 수 있다. 본 실시예는 상술한 양방향 통신 서비스가 제공되는 경우에 대응할 수 있다. 본 실시예에서, 통지는 프라이머리 디바이스에 의해 실행되는 DO가 통신할 준비가 되어 있는지를 나타내기 위한 것일 수 있다. 본 실시예에서, 바이트를 송신하기 위한 접속은 TCP/IP 접속일 수 있다. 또한, 본 실시예는 프라이머리 디바이스로의 TCP/IP 접속을 요청하는 동작에 대응할 수 있다.
본 발명의 다른 실시예에서, 전송 모듈은 또한 수신 모듈이 메시지를 수신하기 전에 실행된 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 요청을 전송하도록 구성될 수 있다. 제2 스크린 디바이스(또는 전송 모듈)는 요청을 프라이머리 디바이스로 전송할 수 있다. 요청은 세컨더리 애플리케이션에 대한 인터랙티브 서비스의 메시지에 대한 것이다. 여기서, 메시지는 상술한 디스커버리 메시지를 지칭할 수 있다. 프라이머리 디바이스가 상술한 디스커버리 메시지를 수신하면, 프라이머리 디바이스는 메시지를 제2 스크린 디바이스로 송신할 수 있다. 본 실시예는 디바이스 디스커버리 또는 서비스 디스커버리에 대응할 수 있다.
UPnP 프레임워크는, 전자 장치를 홈 네트워크에 접속하고 전자 장치에 따라 기능을 제공함으로써 제공될 수 있다. 본 발명은 기존의 UPnP RemoteUI 클라이언트 서비스 및 UPnP RemoteUI 서버 클라이언트의 확장에 관한 것이다. 따라서, 기존의 UPnP 장치와 호환가능하면서 제2 스크린 서비스를 수신할 수 있다.
첨부된 도면을 참조하여 본 발명을 명료하게 설명하지만, 첨부된 도면에 도시된 실시예를 서로 병합함으로써 새로운 실시예(들)을 설계할 수 있다. 상술한 실시예를 실행하는 프로그램이 기록된 컴퓨터에 의해 판독가능한 기록 매체가 당업자의 필요로 설계되면, 이는 첨부된 청구범위 및 그 동등물에 속할 수 있다.
본 발명의 장치 및 방법은 상술한 실시예의 구성 및 방법에 의해 제한되지 않을 수 있다. 또한, 상술한 실시예는 서로 전체적으로 또는 부분적으로 선택적으로 결합되어 다양한 변경이 가능한 방식으로 구성될 수 있다.
또한, 본 발명에 따른 방법은 네트워크 디바이스에 제공되는 프로세서 판독가능 기록 매체에서 프로세서 판독가능 코드로 구현될 수 있다. 프로세서 판독가능 매체는 프로세서에 의해 판독될 수 있는 데이터를 저장할 수 있는 모든 종류의 기록 장치를 포함한다. 프로세서 판독가능 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서 판독가능 기록 매체는 네트워크를 통해 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서 판독가능 코드가 저장되고 실행될 수 있다.
본 발명의 사상 또는 범위를 벗어나지 않고 본 발명의 다양한 변형 및 변경이 가능함은 당업자에게 자명한 것이다. 따라서, 본 발명은 첨부된 청구범위 및 그 동등물의 범위 내에서 제공되는 본 발명의 변형 및 변경을 커버한다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 서로 보충적으로 적용될 수가 있다.
발명의 실시를 위한 형태는 전술한 바와 같이, 발명의 실시를 위한 최선의 형태로 상술되었다.
본 발명은 방송 서비스 제공과 관련한 일련의 산업분야에서 이용 가능하다.
본 발명의 사상 및 범위를 벗어나지 않고 본 발명의 다양한 변형 및 변경이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구범위 및 동등물의 범위 내에서 제공되는 본 발명의 변형 및 변경을 커버한다.

Claims (26)

  1. 프라이머리 디바이스에서 디지털 서비스 신호를 처리하는 방법으로서,
    상기 프라이머리 디바이스가 제공하는 UPnP 서비스들을 알려주는 디스커버리 메시지들을 멀티캐스팅 방식으로 전송하는 단계로서, 상기 UPnP 서비스들은 트리거 서비스 및 투-웨이 커뮤니케이션(two-way communication)서비스를 포함하고;
    컴패니언 디바이스의 세컨더리 어플리케이션으로부터 상기 UPnP 서비스들의 디스크립션들을 요청받는 단계;
    상기 디스크립션들을 상기 세컨더리 어플리케이션으로 전송하는 단계로서, 상기 디스크립션들은 상기 세컨더리 어플리케이션에서 상기 UPnP 서비스들을 구독하기 위해 사용되고;
    방송 스트림 또는 인터넷 서버로부터 액티베이션 트리거를 수신하는 단계로서, 상기 액티베이션 트리거는 어플리케이션 테이블로부터 타겟 이벤트를 식별하고, 미디어 타임에 관련된 상기 타겟 이벤트를 위한 액티베이션 시간을 정의하고, 상기 어플리케이션 테이블은 이벤트들의 메타 데이터, 상기 이벤트들에 의해 타겟되는 어플리케이션들, 및 상기 이벤트들을 위해 사용되는 데이터 세트들을 포함하고;
    상기 액티베이션 트리거 및 상기 어플리케이션 테이블에 포함된 정보를 결합하여 증가된 트리거를 생성하는 단계로서, 상기 증가된 트리거는 상기 타겟 이벤트에 의해 타겟되는 어플리케이션의 메타데이터, 상기 타겟 이벤트 및 상기 타겟 이벤트를 위해 사용되는 데이터 세트를 포함하고, 상기 메타데이터는 상기 액티베이션 트리거에 의해 상기 어플리케이션 테이블로부터 참조되고; 및
    상기 트리거 서비스 의해 상기 증가된 트리거를 상기 세컨더리 어플리케이션으로 전달하는 단계로서, 상기 증가된 트리거는 상기 액티베이션 트리거에 의해 상기 액티베이션 시간에 전달되는 것을 포함하는 인터랙티브 서비스를 제공하는 방법.
  2. 제1항에 있어서,
    상기 투-웨이 커뮤니케이션 서비스를 사용하여 상기 세컨더리 어플리케이션으로 상태 정보를 전송하는 단계로서, 상기 상태 정보는 상기 세컨더리 어플리케이션과의 통신에 참여할 준비가 되어있는 프라이머리 어플리케이션이 상기 프라이머리 디바이스에서 동작하는지 여부를 나타내고;
    상기 세컨더리 어플리케이션으로부터 상기 통신을 위한 요청을 받는 단계; 및
    상기 프라이머리 어플리케이션 및 상기 세컨더리 어플리케이션간에 전송되는 데이터를 통하여 상기 통신을 성립하는 단계를 더 포함하는 인터랙티브 서비스를 제공하는 방법.
  3. 제1항에 있어서,
    상기 어플리케이션 테이블은 상기 어플리케이션들을 설명하는 어플리케이션 엘리먼트들을 포함하고, 각 어플리케이션 엘리먼트는 각 어플리케이션의 메타데이터, 어플리케이션 아이디(ID), 및 상기 각 어플리케이션을 타겟하는 이벤트들을 설명하는 이벤트 엘리먼트들을 포함하고, 각 이벤트 엘리먼트는 각 이벤트의 메타데이터, 이벤트 아이디(ID), 및 상기 각 이벤트를 위해 사용되는 데이터 세트들을 포함하는 데이터 엘리먼트들을 포함하고, 각 데이터 엘리먼트는 데이터 아이디(ID)를 포함하는, 인터랙티브 서비스를 제공하는 방법.
  4. 제3항에 있어서,
    상기 액티베이션 트리거는 상기 어플리케이션 테이블 중 상기 어플리케이션 아이디를 참조하여 상기 각 어플리케이션 엘리먼트를 지시하고,
    상기 액티베이션 트리거는 상기 어플리케이션 엘리먼트 중 상기 이벤트 아이디를 참조하여 상기 각 이벤트 엘리먼트를 지시하고,
    상기 액티베이션 트리거는 상기 이벤트 엘리먼트 중 상기 데이터 아이디를 참조하여 상기 각 데이터 엘리먼트를 지시하는 것을 포함하는 인터랙티브 서비스를 제공하는 방법.
  5. 프라이머리 디바이스가 제공하는 UPnP 서비스들을 알려주는 디스커버리 메시지들을 멀티캐스팅 방식으로 전송하는 네트워크 인터페이스로서, 상기 UPnP 서비스들은 트리거 서비스 및 투-웨이 커뮤니케이션(two-way communication)서비스를 포함하고,
    상기 네트워크 인터페이스는 컴패니언 디바이스의 세컨더리 어플리케이션으로부터 상기 UPnP 서비스들의 디스크립션들을 요청받고, 상기 디스크립션들을 상기 세컨더리 어플리케이션으로 전송하고, 상기 디스크립션들은 상기 세컨더리 어플리케이션에서 상기 UPnP 서비스들을 구독하기 위해 사용되고;
    방송 스트림 또는 인터넷 서버로부터 액티베이션 트리거를 수신하는 튜너로서, 상기 액티베이션 트리거는 어플리케이션 테이블로부터 타겟 이벤트를 식별하고, 미디어 타임에 관련된 상기 타겟 이벤트를 위한 액티베이션 시간을 정의하고, 상기 어플리케이션 테이블은 이벤트들의 메타 데이터, 상기 이벤트들에 의해 타겟되는 어플리케이션들, 및 상기 이벤트들을 위해 사용되는 데이터 세트들을 포함하고; 및
    상기 액티베이션 트리거 및 상기 어플리케이션 테이블에 포함된 정보를 결합하여 증가된 트리거를 생성하는 트리거 모듈로서, 상기 증가된 트리거는 상기 타겟 이벤트에 의해 타겟되는 어플리케이션의 메타데이터, 상기 타겟 이벤트 및 상기 타겟 이벤트를 위해 사용되는 데이터 세트를 포함하고, 상기 메타데이터는 상기 액티베이션 트리거에 의해 상기 어플리케이션 테이블로부터 참조되고, 상기 트리거 모듈은 상기 트리거 서비스 의해 상기 증가된 트리거를 상기 세컨더리 어플리케이션으로 전달하는 단계로서, 상기 증가된 트리거는 상기 액티베이션 트리거에 의해 상기 액티베이션 시간에 전달되는 것을 포함하는, 디지털 서비스 신호를 처리하는 프라이머리 디바이스로서 인터랙티브 서비스를 제공하는 장치.
  6. 제5항에 있어서,
    상기 네트워크 인터페이스는 상기 투-웨이 커뮤니케이션 서비스를 사용하여 상기 세컨더리 어플리케이션으로 상태 정보를 전송하고, 상기 상태 정보는 상기 세컨더리 어플리케이션과의 통신에 참여할 준비가 되어있는 프라이머리 어플리케이션이 상기 프라이머리 디바이스에서 동작하는지 여부를 나타내고,
    상기 네트워크 인터페이스는 상기 세컨더리 어플리케이션으로부터 상기 통신을 위한 요청을 받고, 상기 프라이머리 어플리케이션 및 상기 세컨더리 어플리케이션간에 전송되는 데이터를 통하여 상기 통신을 성립하는 것을 더 포함하는, 인터랙티브 서비스를 제공하는 장치.
  7. 제5항에 있어서,
    상기 어플리케이션 테이블은 상기 어플리케이션들을 설명하는 어플리케이션 엘리먼트들을 포함하고, 각 어플리케이션 엘리먼트는 각 어플리케이션의 메타데이터, 어플리케이션 아이디(ID), 및 상기 각 어플리케이션을 타겟하는 이벤트들을 설명하는 이벤트 엘리먼트들을 포함하고, 각 이벤트 엘리먼트는 각 이벤트의 메타데이터, 이벤트 아이디(ID), 및 상기 각 이벤트를 위해 사용되는 데이터 세트들을 포함하는 데이터 엘리먼트들을 포함하고, 각 데이터 엘리먼트는 데이터 아이디(ID)를 포함하는, 인터랙티브 서비스를 제공하는 장치.
  8. 제7항에 있어서,
    상기 액티베이션 트리거는 상기 어플리케이션 테이블 중 상기 어플리케이션 아이디를 참조하여 상기 각 어플리케이션 엘리먼트를 지시하고,
    상기 액티베이션 트리거는 상기 어플리케이션 엘리먼트 중 상기 이벤트 아이디를 참조하여 상기 각 이벤트 엘리먼트를 지시하고,
    상기 액티베이션 트리거는 상기 이벤트 엘리먼트 중 상기 데이터 아이디를 참조하여 상기 각 데이터 엘리먼트를 지시하는 것을 포함하는, 인터랙티브 서비스를 제공하는 장치.
  9. 삭제
  10. 삭제
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
KR1020157010988A 2012-11-28 2013-11-26 양방향 서비스를 처리하는 장치 및 방법 KR102040623B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261730937P 2012-11-28 2012-11-28
US61/730,937 2012-11-28
US201261736529P 2012-12-12 2012-12-12
US61/736,529 2012-12-12
PCT/KR2013/010788 WO2014084570A1 (en) 2012-11-28 2013-11-26 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
KR20150090049A KR20150090049A (ko) 2015-08-05
KR102040623B1 true KR102040623B1 (ko) 2019-11-27

Family

ID=50774515

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157010988A KR102040623B1 (ko) 2012-11-28 2013-11-26 양방향 서비스를 처리하는 장치 및 방법

Country Status (8)

Country Link
US (1) US9516384B2 (ko)
EP (1) EP2926568A4 (ko)
JP (1) JP6247309B2 (ko)
KR (1) KR102040623B1 (ko)
CN (1) CN104871552B (ko)
CA (1) CA2889868C (ko)
MX (1) MX345034B (ko)
WO (1) WO2014084570A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102504102B1 (ko) 2022-10-19 2023-02-28 주식회사 와이드테크 인터넷 텔레비전을 이용한 라이브 방송 송출 서비스 제공 방법을 제공하는 텔레비전

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8365230B2 (en) 2001-09-19 2013-01-29 Tvworks, Llc Interactive user interface for television applications
US8413205B2 (en) 2001-09-19 2013-04-02 Tvworks, Llc System and method for construction, delivery and display of iTV content
US8042132B2 (en) 2002-03-15 2011-10-18 Tvworks, Llc System and method for construction, delivery and display of iTV content
US11388451B2 (en) 2001-11-27 2022-07-12 Comcast Cable Communications Management, Llc Method and system for enabling data-rich interactive television using broadcast database
US7703116B1 (en) 2003-07-11 2010-04-20 Tvworks, Llc System and method for construction, delivery and display of iTV applications that blend programming information of on-demand and broadcast service offerings
US8352983B1 (en) 2002-07-11 2013-01-08 Tvworks, Llc Programming contextual interactive user interface for television
US11070890B2 (en) 2002-08-06 2021-07-20 Comcast Cable Communications Management, Llc User customization of user interfaces for interactive television
US8220018B2 (en) 2002-09-19 2012-07-10 Tvworks, Llc System and method for preferred placement programming of iTV content
US8578411B1 (en) 2003-03-14 2013-11-05 Tvworks, Llc System and method for controlling iTV application behaviors through the use of application profile filters
US10664138B2 (en) * 2003-03-14 2020-05-26 Comcast Cable Communications, Llc Providing supplemental content for a second screen experience
US11381875B2 (en) 2003-03-14 2022-07-05 Comcast Cable Communications Management, Llc Causing display of user-selectable content types
US8819734B2 (en) 2003-09-16 2014-08-26 Tvworks, Llc Contextual navigational control for digital television
US7818667B2 (en) 2005-05-03 2010-10-19 Tv Works Llc Verification of semantic constraints in multimedia data and in its announcement, signaling and interchange
US11832024B2 (en) 2008-11-20 2023-11-28 Comcast Cable Communications, Llc Method and apparatus for delivering video and video-related content at sub-asset level
US8776105B2 (en) 2012-02-07 2014-07-08 Tuner Broadcasting System, Inc. Method and system for automatic content recognition protocols
US11115722B2 (en) 2012-11-08 2021-09-07 Comcast Cable Communications, Llc Crowdsourcing supplemental content
US9288509B2 (en) * 2012-12-28 2016-03-15 Turner Broadcasting System, Inc. Method and system for providing synchronized advertisements and services
US9253262B2 (en) * 2013-01-24 2016-02-02 Rovi Guides, Inc. Systems and methods for connecting media devices through web sockets
US9553927B2 (en) 2013-03-13 2017-01-24 Comcast Cable Communications, Llc Synchronizing multiple transmissions of content
US10880609B2 (en) 2013-03-14 2020-12-29 Comcast Cable Communications, Llc Content event messaging
JP6168839B2 (ja) * 2013-05-15 2017-07-26 キヤノン株式会社 情報処理装置、その制御方法、プログラム
JP2015012561A (ja) * 2013-07-02 2015-01-19 ソニー株式会社 表示装置、情報取得方法及び情報提供方法
CA2925284C (en) * 2013-09-23 2023-04-25 Samsung Electronics Co., Ltd. Method and apparatus for executing application in wireless communication system
EP2854317A1 (en) * 2013-09-26 2015-04-01 Alcatel Lucent Method for providing a client device with a media asset
MX2016012953A (es) * 2014-04-11 2016-12-07 Sony Corp Aparato de recepcion, metodo de recepcion, aparato de transmision, y metodo de transmision.
KR101875667B1 (ko) * 2014-06-30 2018-07-06 엘지전자 주식회사 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
CN111556342B (zh) * 2014-06-30 2022-04-05 Lg 电子株式会社 用于接收广播信号的装置与方法
WO2016035348A1 (en) * 2014-09-05 2016-03-10 Sharp Kabushiki Kaisha Syntax and semantics for device capabilities
EP3197173B1 (en) 2014-09-05 2021-12-01 Sony Group Corporation Reception device, reception method, transmission device and transmission method
US9979993B2 (en) * 2014-09-15 2018-05-22 Verizon Patent And Licensing Inc. Network for personalized content aggregation platform
US11783382B2 (en) 2014-10-22 2023-10-10 Comcast Cable Communications, Llc Systems and methods for curating content metadata
JP6583281B2 (ja) * 2014-10-28 2019-10-02 ソニー株式会社 受信装置、送信装置、およびデータ処理方法
CN105830459B (zh) 2014-11-20 2019-06-18 Lg电子株式会社 发送广播信号的设备、接收广播信号的设备、发送广播信号的方法和接收广播信号的方法
CN104599163A (zh) * 2015-02-23 2015-05-06 佛山市恒南微科技有限公司 一种可溯源的农产品配送券
WO2016178319A1 (en) * 2015-05-06 2016-11-10 Sharp Kabushiki Kaisha Carrying multiple event times within a trigger
KR20180001559A (ko) * 2015-05-26 2018-01-04 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10779057B2 (en) * 2015-06-08 2020-09-15 Qualcomm Incorporated Broadcast content redistribution and ad insertion
US10917186B2 (en) 2015-07-21 2021-02-09 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
US10681147B2 (en) * 2016-08-15 2020-06-09 Saturn Licensing Llc URLs for acquiring or transmitting data
US10893011B2 (en) * 2016-09-13 2021-01-12 Gluru Limited Semantic interface definition language for action discovery in cloud services and smart devices
TWI640195B (zh) * 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US10701438B2 (en) 2016-12-31 2020-06-30 Turner Broadcasting System, Inc. Automatic content recognition and verification in a broadcast chain
CN108139952B (zh) * 2017-06-14 2022-08-05 北京小米移动软件有限公司 应用交互方法、交互方法及装置
WO2018227899A1 (zh) 2017-06-14 2018-12-20 北京小米移动软件有限公司 应用交互方法、交互方法及装置
WO2019154476A1 (en) * 2018-02-06 2019-08-15 Telefonaktiebolaget Lm Ericsson (Publ) Unique service identifier for a message proxy in a service based architecture
CN108614978B (zh) * 2018-04-19 2022-04-15 中国平安人寿保险股份有限公司 压缩包的校验方法、装置、存储介质以及终端
US10740079B2 (en) * 2018-05-15 2020-08-11 Microsoft Technology Licensing, Llc Maintaining tight coupling between driver and application versions
CN111372135A (zh) * 2018-12-25 2020-07-03 中国移动通信集团浙江有限公司 一种机顶盒应用自动适配方法及系统
US11095927B2 (en) 2019-02-22 2021-08-17 The Nielsen Company (Us), Llc Dynamic watermarking of media based on transport-stream metadata, to facilitate action by downstream entity
WO2020231821A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with fingerprint data match and mismatch detection feature
WO2020231813A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with responsive transmission of reference fingerprint data feature
WO2020231927A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with responsive transmission of reference fingerprint data feature
US11234050B2 (en) 2019-06-18 2022-01-25 Roku, Inc. Use of steganographically-encoded data as basis to control dynamic content modification as to at least one modifiable-content segment identified based on fingerprint analysis
US11704390B2 (en) * 2019-10-10 2023-07-18 Baidu Usa Llc Method and system for signing an artificial intelligence watermark using a query
US11405674B2 (en) 2019-11-12 2022-08-02 The Nielsen Company (Us), Llc Methods and apparatus to identify media for ahead of time watermark encoding
US11012757B1 (en) 2020-03-03 2021-05-18 The Nielsen Company (Us), Llc Timely addition of human-perceptible audio to mask an audio watermark
CN116302076B (zh) * 2023-05-18 2023-08-15 云账户技术(天津)有限公司 一种基于解析配置项表结构进行配置项配置的方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003096669A2 (en) * 2002-05-10 2003-11-20 Reisman Richard R Method and apparatus for browsing using multiple coordinated device
KR100717060B1 (ko) * 2005-12-05 2007-05-10 삼성전자주식회사 홈 네트워크를 통해 ｄｖｄ 컨텐츠를 이용하는 방법 및장치
CN101227418B (zh) * 2007-01-19 2012-04-04 华为技术有限公司 一种实现融合ip消息的方法、装置及系统
US8775647B2 (en) * 2007-12-10 2014-07-08 Deluxe Media Inc. Method and system for use in coordinating multimedia devices
US8521078B2 (en) * 2008-03-21 2013-08-27 Qualcomm Incorporated Common interface protocol for sending FR-RDS messages in wireless communication systems
GB2466289A (en) * 2008-12-18 2010-06-23 Veda Technology Ltd Executing a service application on a cluster by registering a class and storing subscription information of generated objects at an interconnect
US8621520B2 (en) * 2009-05-19 2013-12-31 Qualcomm Incorporated Delivery of selective content to client applications by mobile broadcast device with content filtering capability
EP2343881B1 (en) * 2010-01-07 2019-11-20 LG Electronics Inc. Method of processing application in digital broadcast receiver connected with interactive network, and digital broadcast receiver
US8863171B2 (en) * 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
US8516528B2 (en) 2010-06-30 2013-08-20 Cable Television Laboratories, Inc. Synchronization of 2nd screen applications
EP2472855A1 (en) * 2010-12-29 2012-07-04 Advanced Digital Broadcast S.A. Television user interface
US20130347044A1 (en) * 2011-02-20 2013-12-26 Lg Electronics Inc. Method and apparatus for the seamless playback of content

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102504102B1 (ko) 2022-10-19 2023-02-28 주식회사 와이드테크 인터넷 텔레비전을 이용한 라이브 방송 송출 서비스 제공 방법을 제공하는 텔레비전

Also Published As

Publication number Publication date
JP2016506114A (ja) 2016-02-25
MX345034B (es) 2017-01-16
EP2926568A1 (en) 2015-10-07
CA2889868A1 (en) 2014-06-05
KR20150090049A (ko) 2015-08-05
JP6247309B2 (ja) 2017-12-13
CN104871552A (zh) 2015-08-26
CN104871552B (zh) 2018-05-01
WO2014084570A1 (en) 2014-06-05
MX2015005930A (es) 2015-09-08
EP2926568A4 (en) 2016-06-08
US9516384B2 (en) 2016-12-06
US20140150022A1 (en) 2014-05-29
CA2889868C (en) 2018-01-02

Similar Documents

Publication Publication Date Title
KR102040623B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
US9723375B2 (en) Apparatus and method for processing an interactive service
KR102024600B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR102068567B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR101939296B1 (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