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

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

Info

Publication number
KR102068567B1
KR102068567B1 KR1020147034794A KR20147034794A KR102068567B1 KR 102068567 B1 KR102068567 B1 KR 102068567B1 KR 1020147034794 A KR1020147034794 A KR 1020147034794A KR 20147034794 A KR20147034794 A KR 20147034794A KR 102068567 B1 KR102068567 B1 KR 102068567B1
Authority
KR
South Korea
Prior art keywords
trigger
activation
event
time
receiver
Prior art date
Application number
KR1020147034794A
Other languages
English (en)
Other versions
KR20150048669A (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 KR20150048669A publication Critical patent/KR20150048669A/ko
Application granted granted Critical
Publication of KR102068567B1 publication Critical patent/KR102068567B1/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/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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23892—Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
    • 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • 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/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/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • 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/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • 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
    • 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/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

양방향 서비스를 처리하는 방법 및 그 장치를 개시한다. 본 발명은 외부 디코딩부로부터 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하는 단계, 상기 수신된 콘텐츠로부터 프레임의 식별자를 추출하는 단계, 상기 식별자를 포함하는 요청을 서버로 보내는 단계, 및 상기 요청을 바탕으로 상기 서버로부터 상기 콘텐트에 대한 트리거를 수신하는 단계를 포함하고, 상기 트리거는 상기 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블 내의 특정 양방향 이벤트를 참조하거나 상기 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알리고, 상기 어플리케이션 파라미터 테이블은 어플리케이션들 중 적어도 하나에 대한 정보를 포함한다.

Description

양방향 서비스를 처리하는 장치 및 방법 {APPARATUS AND METHOD FOR PROCESSING AN INTERACTIVE SERVICE}
본 발명은 방송 서비스를 제공하고 이를 수신 처리 하기 위한 방법 및 장치에 관한 것이다. 보다 상세하게는, 방송 콘텐트와 관련된 부가 서비스를 제공하는 방법 및 장치에 관한 것이다.
TV는 19세기 말에 처음 등장한 이후, 화면 표시 방법이나 디자인 등이 지속적으로 발전하면서 20세기 후반부터 가장 대중적인 정보 전달 기기로 확고히 자리잡았다. 다만, 방송국에서 전해주는 단방향의 정보를 시청자들이 일방적으로 수용한다는 근본적인 형태를 가지고 있었다. 이러한 TV의 한계는 1990년대부터 PC(개인용컴퓨터) 및 인터넷이 대중화되면서 더욱 분명하게 부각되기 시작했다. 이에 TV는 쌍방향 서비스가 가능한 방향으로 진화를 하고 있다.
그러나, 현재 콘텐츠 제공자와 시청자 사이에 이러한 양방향 서비스를 본격적으로 실행할 시스템이 부재한 실정이다. 특히 이러한 양방향 서비스의 제공을 위해 방영중인 방송 콘텐츠와 관련된 어플리케이션을 특정 시점에 구동하고, 정보의 특정 처리를 통해, 시청자에게 관련 정보를 제공하는 방법 및 포맷에 관한 기술적 지원이 필요한 상황이다.
본 발명이 이루고자 하는 기술적 과제는, 전술한 문제점을 해결하기 위한 것으로, 방송 콘텐트가 재생되는 기간 중 적절한 시기에 방송 콘텐트와 관련된 부가 정보를 제공하는 것에 있다.
상기 기재된 기술적 과제를 해결하기 위하여, 수신기가 양방향 서비스를 처리하는 방법은 외부 디코딩부로부터 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하는 단계, 상기 수신된 콘텐츠로부터 프레임의 식별자를 추출하는 단계, 상기 식별자를 포함하는 요청을 서버로 보내는 단계, 및 상기 요청을 바탕으로 상기 서버로부터 상기 콘텐트에 대한 트리거를 수신하는 단계를 포함하고, 상기 트리거는 상기 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블 내의 특정 양방향 이벤트를 참조하거나 상기 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알리고, 상기 어플리케이션 파라미터 테이블은 어플리케이션들 중 적어도 하나에 대한 정보를 포함한다.
바람직하게는, 다음 요청을 보내기 전에 이벤트 활성화가 발생하도록 스케줄링되지 않은 경우 상기 트리거는 시간 베이스 트리거이고, 상기 시간 베이스 트리거는 세그먼트의 시간을 유지하기 위해 사용된다.
바람직하게는, 활성화가 발생될 예정인 경우 상기 트리거는 활성화 트리거이고, 상기 활성화 트리거는 상기 이벤트에 대한 활성화 시간을 설정하며, 상기 활성화 시간은 상기 활성화 트리거 내의 타이밍 값 항에 의해 지시된다.
바람직하게는, 상기 방법은, 상기 수신기가 상기 어플리케이션 파라미터 테이블과 함께 전달된 URL 정보를 이용하여 새로운 어플리케이션 파라미터 테이블을 아직 검색하지 않았으면, 상기 트리거가 상기 새로운 어플리케이션 파라미터 테이블을 식별하는 어플리케이션 파라미터 테이블 식별자를 포함하는 경우, 상기 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드하는 단계를 더 포함한다.
바람직하게는, 상기 방법은, 상기 수신기가 상기 트리거와 연관된 새로운 어플리케이션을 가지지 않은 경우, 상기 어플리케이션 파라미터 테이블 또는 상기 새로운 어플리케이션 파라미터 테이블로부터 상기 새로운 어플리케이션에 대하여 어플리케이션 URL을 얻는 단계, 및 상기 어플리케이션 URL을 이용하여 상기 새로운 어플리케이션을 다운로드하는 단계를 더 포함한다.
바람직하게는, 상기 수신기는 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하면, 상기 활성화 트리거는 한 번 적용된다.
바람직하게는, 활성화 트리거가 상기 활성화 시간 이후에 수신되면 활성화 트리거는 도달하자마자 적용된다.
바람직하게는, 상기 시간은 미디어 시간이고, 상기 미디어 시간은 콘텐츠 아이템의 재생 중 한 지점을 참조하는 파라미터이다.
바람직하게는, 상기 어플리케이션은 선언적 객체(Declarative Object), 트리거된 선언적 객체(Triggered Declarative Object), 비실시간 선언적 객체(Non-Real Time Declarative Object) 또는 언바운드 선언적 객체(Unbound Declarative Object)이다.
또한, 상기 기재된 기술적 과제를 해결하기 위하여, 양방향 서비스를 처리하는 장치는 외부 디코딩부로부터 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하도록 구성된 수신 모듈, 상기 수신된 콘텐츠로부터 프레임의 식별자를 추출하도록 구성된 식별자 추출 모듈, 및 상기 식별자를 포함하는 요청을 서버로 보내고, 상기 요청을 바탕으로 상기 서버로부터 상기 콘텐트에 대한 트리거를 수신하도록 구성된 네트워크 인터페이스를 포함하고, 상기 트리거는 상기 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블 내의 특정 양방향 이벤트를 참조하거나 상기 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알리고, 상기 어플리케이션 파라미터 테이블은 어플리케이션들 중 적어도 하나에 대한 정보를 포함한다.
바람직하게는, 다음 요청을 보내기 전에 이벤트 활성화가 발생하도록 스케줄링되지 않은 경우 상기 트리거는 시간 베이스 트리거이고, 상기 시간 베이스 트리거는 세그먼트의 시간을 유지하기 위해 사용된다.
바람직하게는, 활성화가 발생될 예정인 경우 상기 트리거는 활성화 트리거이고, 상기 활성화 트리거는 상기 이벤트에 대한 활성화 시간을 설정하며, 상기 활성화 시간은 상기 활성화 트리거 내의 타이밍 값 항에 의해 지시된다.
바람직하게는, 상기 네트워크 인터페이스는, 상기 장치가 상기 어플리케이션 파라미터 테이블과 함께 전달된 URL 정보를 이용하여 새로운 어플리케이션 파라미터 테이블을 아직 검색하지 않았으면, 상기 트리거가 상기 새로운 어플리케이션 파라미터 테이블을 식별하는 어플리케이션 파라미터 테이블 식별자를 포함하는 경우, 상기 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드하도록 더 구성된다.
바람직하게는, 상기 장치는, 상기 장치가 상기 트리거와 연관된 새로운 어플리케이션을 가지지 않은 경우, 상기 어플리케이션 파라미터 테이블 또는 상기 새로운 어플리케이션 파라미터 테이블로부터 상기 새로운 어플리케이션에 대하여 어플리케이션 URL을 얻도록 구성된 트리거 모듈을 더 포함하고, 상기 네트워크 인터페이스 상기 어플리케이션 URL을 이용하여 상기 새로운 어플리케이션을 다운로드하도록 더 구성된다.
바람직하게는, 상기 장치는 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하면, 상기 활성화 트리거는 한 번 적용된다.
바람직하게는, 활성화 트리거가 상기 활성화 시간 이후에 수신되면 활성화 트리거는 도달하자마자 적용된다.
바람직하게는, 상기 시간은 미디어 시간이고, 상기 미디어 시간은 콘텐츠 아이템의 재생 중 한 지점을 참조하는 파라미터인이다.
바람직하게는, 상기 어플리케이션은 선언적 객체(Declarative Object), 트리거된 선언적 객체(Triggered Declarative Object), 비실시간 선언적 객체(Non-Real Time Declarative Object) 또는 언바운드 선언적 객체(Unbound Declarative Object)이다.
본 발명에 따르면, 기존 방송 시스템을 이용하여, 방송 콘텐트와 연관된 부가 정보를 제공할 수 있는 효과가 있다.
본 발명에 따르면, 방송 콘텐트와 관련된 부가 정보가 디스플레이 되어야 하는 시점을 정확히 파악하여, 적시에 부가 정보를 사용자에게 제공할 수 있는 효과가 있다.
본 발명에 따르면, 인터넷 커넥션은 있으나, 방송 스트림을 통한 비압축적 오디오/비디오에만 접근할 수 있는 수신기에 대해, 방송 콘텐츠와 연관된 부가정보를 인터넷을 통해 제공할 수 있는 효과가 있다.
도 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는 요청/응답 ACR의 경우 ACR 클라이언트와 다른 서버들 사이의 시퀀스 다이어그램의 일 실시예를 도시한 도면.
도 36은 요청/응답 모델에서, 수신기가 양방향 서비스를 처리하는 방법의 일 실시예를 나타낸 도면.
도 37은 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면.
도 38은 방송을 셋탑 박스에서 HDMI 혹은 외부 입력으로 수신하는 경우의 수신기 구조도의 일 실시예를 나타낸 도면.
도 39는 요청/응답 모델에서, 양방향 서비스를 처리하는 장치의 일 실시예를 나타낸 도면.
본 명세서에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도, 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한 특정 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 아닌 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다.
본 명세서에서 미디어 시간은 오디오/비디오 또는 오디오 콘텐트 아이템의 재생(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를 활용하여 수집된 데이터들을 전송할 수 있다.
이하 URL 리스트에 관하여 설명한다.
URLlist는 UrlList, TptUrl, UrsUrl, 및/또는 PdiUrl 등을 포함할 수 있다. 이 엘리먼트들의 시맨틱은 다음과 같다.
UrlList 엘리먼트의 엘리먼트인 TptUrl는 현재의 양방향 부가 서비스 내 미래 세그먼트에 대한 TPT의 URL을 포함할 수 있다. 다수의 TptUrl 엘리먼트들이 포함된 경우, 방송 내 세그먼트들의 등장 순서대로 배열될 수 있다.
UrlList 엘리먼트의 엘리먼트인 NrtSignalingUrl은 수신기들이 현재의 트랜스포트 스트림 내 모든 가상 채널들에 대한 NRT 시그널링 테이블을 얻을 수 있는 서버의 URL을 포함할 수 있다.
UrlList 엘리먼트의 엘리먼트인 UrsUrl은 수신기들이 현재의 가상 채널에 대한 사용(시청률 조사) 보고를 전송할 수 있는 서버의 URL을 포함할 수 있다.
UrlList 엘리먼트의 엘리먼트인 PdiUrl은 현재의 가상 채널에 대한 PDI-Q 테이블의 URL을 포함할 수 있다.
이하 전달 메커니즘에 관하여 설명한다.
이하 양방향 서비스 생성으로부터의 결과, 방송 스트림 내에서의 트리거의 전달, 인터넷을 통한 시간 베이스 트리거의 전달, 인터넷을 통한 활성화 트리거의 전달 (ACR 시나리오), 방송 스트림에서의 TPT의 전달, 인터넷을 통한 TPT의 전달, TDO 및 콘텐트 아이템의 이동, 다수의 세그먼트를 하나의 세그먼트로 합치기의 순서대로 설명한다.
이 중, 양방향 서비스 생성으로부터의 결과, 방송 스트림에서의 트리거의 전달, 인터넷을 통한 시간 베이스 트리거의 전달, 인터넷을 통한 활성화 트리거의 전달 (ACR 시나리오), TDO 및 콘텐트 아이템의 이동, 다수의 세그먼트를 하나의 세그먼트로 합치기에 대해서는 도면에 도시되지 않았으나, 명세서 사항에 국한되지 않으며, 설계자의 의도에 따라 변경 가능하다.
도 16 내지 도 17은 각각 방송 스트림에서의 TPT의 전달 및 인터넷을 통한 TPT의 전달의 경우를 도시한 도면이다.
이하 상기 전달 메커니즘에 관한 사항을 설명한다.
이하 양방향 서비스 생성으로부터의 결과에 대해 설명한다.
하나의 세그먼트에 대한 서비스 생성 과정은 모든 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와 함께 전달될 수 있다.
도 16은 TPT들을 포함하는 프라이빗 섹션(private section)들의 이진 포맷의 일 실시예를 나타낸 도면이다. 하기 설명하는 NRT-스타일 프라이빗 섹션은 도 16와 같을 수 있다.
이하 방송 스트림에서의 TPT 전달에 대해 설명한다.
방송 스트림으로 전달 시, TPT들은 이들의 XML 포맷에서 상응하는 이진 NRT-스타일 시그널링 포맷으로 변환되어 테이블 인스턴스 당 TPT 하나씩 NRT-스타일 프라이빗 섹션들에 캡슐화될 수 있다. 현재 세그먼트에 대한 TPT는 항상 존재한다. 하나 이상의 미래 세그먼트들에 대한 TPT들도 존재할 있다. TPT 인스턴스는 그 segment_id 필드의 값에 의해 정의된다. 참고로, TDO 파라미터 테이블의 이진 포맷은 위에서 살펴본 바와 같다.
정리하면, 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 인스턴스들을 구분하기 위해 사용될 수 있다.
프라이빗 섹션(tpt_section())은 table_id, protocol_version, sequence_number, TPT_data_version, current_next_indicator, section_number, last_section_number, 및/또는 service_id, tpt_bytes() 정보를 포함할 수 있다.
이하 도 16 의 필드들에 대해서 설명한다.
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가 만들어 질 수 있다.
도 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을 포함할 수 있다.
이하 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에 삽입한다.
도 18는 addTriggerEventListener의 일 실시예를 나타낸 도면이다
도 19는 removeTriggerEventListener의 일 실시예를 나타낸 도면이다
도 20은 EventListener 타입의 정의의 일 실시예를 나타낸 도면이다.
도 21는 TriggerEvent 타입의 정의의 일 실시예를 나타낸 도면이다.
이하 DO를 실행하기 위한 환경을 위한, ATSC JavaScript API들에 대해 설명한다.
방송 프로그램에 대한 선언적 객체 동작들의 동기화를 지원하기 위해, 비디오/방송 객체에 대해 추가적인 방법들이 지원될 수 있다.
DTVCC 혹은 인터넷으로 TPT가 수신이 되면 TPT내에는 TDO를 실행하기 위한 여러 개의 이벤트들이 있을 수 있으며 이 이벤트들은 활성화 트리거에 의하여 활성화 될 수 있다.
이 이벤트를 처리하도록 하기 위하여, 리스너(Listener)라는 함수를 eventID별로 등록해 둘 수 있다. 이에 따라, 위에서 설명한 '추가적인 방안들' 로서, 리스너 함수를 등록할 수 있는 다음의 두개의 함수가 있을 수 있다.
addTriggerEventListener 함수는 eventId 별로 발생된 이벤트를 처리하기 위한 콜백(callback) 함수(리스너 함수)를 등록할 수 있다.
removeTriggerEventListener 함수는 eventId별로 발생된 이벤트를 처리하기 위한 콜백 함수(리스너 함수)의 등록을 취소할 수 있다.
도 18에서, addTriggerEventListener에 대한 설명과 포맷, 아규먼트(argument) 등이 도시되어 있다.
addTriggerEventListener 함수는 넘버 타입의 eventId와, EventListener 타입의 listener를 아규먼트로 받을 수 있다. EventListener 타입에 대해서는 후술한다. addTriggerEventListener 함수는 리턴 값이 없을 수 있다. (void)
여기서 eventId 아규먼트는 TPT의 이벤트 엘리먼트 안의 eventId일 수 있다. 여기서 listener 아규먼트는 해당 이벤트를 위한 리스너일 수 있다.
수신기의 트리거 처리 모듈에서는 활성화 메시지를 수신하자마자 "addTriggerEventListener" 함수를 이용하여 eventId 마다 리스너 함수를 등록할 수 있다. 추후 해당 이벤트에 활성화가 일어나면 등록된 리스너 함수가 호출될 수 있다. 이 때, TriggerEvent 타입의 객체는 리스너 함수로 전달될 수 있다. TriggerEvent 타입에 대해서는 후술한다.
도 19 에서, removeTriggerEventListener에 대한 설명과 포맷, 아규먼트 등이 도시되어 있다.
removeTriggerEventListener 함수는 Number 타입의 eventId와, EventListener 타입의 listener를 아규먼트로 받을 수 있다. EventListener 타입에 대해서는 후술한다. removeTriggerEventListener 함수는 리턴 값이 없을 수 있다. (void)
여기서 eventId 아규먼트는 TPT의 이벤트 엘리먼트 안의 eventID일 수 있다. 여기서 listener 아규먼트는 해당 이벤트를 위한 리스너일 수 있다.
자바스크립트 프로그램에서는, 더 이상 해당 eventide 별로 발생할 수 있는 이벤트를 더 이상 수신하지 않기를 원하거나 "DestroyWindow"와 같은 프로그램 종료시에는 "removeTriggerEventListener"를 이용하여 등록된 리스너 함수를 취소할 수 있다.
도 20 에서, the EventListener type 의 정의가 도시되어 있다.
EventListener 타입은 TriggerEvent 타입을 가지는 이벤트를 아규먼트로 할 수 있다. EventListener는 인터페이스일 수 있다.
도 21 에서, TriggerEvent type 의 정의가 도시되어 있다.
TriggerEvent 타입은 이벤트에 대한 정보를 담고 있을 수 있다.
TriggerEvent 타입은 eventId, data, status를 속성으로 가질 수 있다. 여기서 eventId는 TPT의 이벤트 엘리먼트 안의 eventId일 수 있다. 여기서 data는 이벤트의 활성화를 위한 일 수 있다. 여기서 data는 16진법으로 되어 있을 수 있다. 여기서 status는 이벤트의 상태를 의미할 수 있다. 여기서 status 값이 "trigger"일 경우는 이벤트가 활성화 트리거에 의해 활성화된 상태를 의미할 수 있다. 여기서 status 값이 "error"일 경우는 에러가 발생한 상태를 의미할 수 있다.
이하 직접 실행 모델에 대해 설명한다.
직접 실행 모델에서는, 가상 채널이 선택되면 선언적 객체(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 기법을 위한 아키텍처의 일실시예를 도시한 도면이다.
도 23은 FP 기법의 아키텍처의 일 실시예를 도시한 도면.
이하, 다른 인터페이스 지원을 통한 전달에 대해 설명한다.
압축되지 않은 비디오와 오디오만 접속 가능한 환경(예를 들어, 케이블 또는 위성 셋탑 박스로부터 수신되는 환경)에서 양방향 서비스를 획득 가능하게 하기 위한 프로토콜 및 아키텍처를 정의한다. 이 프로토콜 및 아키텍처는 인터넷 연결은 있으나, 방송 스트림을 통한 비압축된 오디오와 비디오에만 접근할 수 있는 수신기에 의해 사용되도록 설계될 수 있다. 물론, 이 프로토콜 및 아키텍처는 양방향 서비스 제공자가 이들을 지원하기로 선택하면 성공적으로 사용될 수 있다.
이 아키텍처는 시청되고 있는 콘텐트의 식별을 위한 두 가지 기본 기법을 지원하도록 설계되어 관련 양방향 서비스 데이터 개선사항들이 인터넷을 통해 전달될 수 있도록 할 수 있다. 두 가지 기본 기법은 워터마킹(Watermarking)과 핑거프린팅(Fingerprinting)일 수 있다.
워터마킹과 핑거프린팅 기법 모두, 그 목적은 어떤 프로그램이 현재 시청되고 있는 지를 수신기들이 찾아내어 해당 프로그램을 위한 양방향 서비스에 대한 부가 정보를 얻는 출발점으로서 사용될 수 있는 URL을 얻을 수 있도록 하는 것이다.
도 22에서 WM 기법을 위한 아키텍처의 일실시예가 도시되어 있다.
WM 기법을 위한 아키텍처에서, 아키텍처는 방송국(22010), 워터마크 삽입부(22011), MVPD(22020), STB(22030), 수신기(22040), WM 클라이언트(22050), TPT 서버(22060) 및 콘텐트 서버(22070)으로 이루어질 수 있다.
방송국(22010)는 오디오/비디오 스트림과 그와 관련된 양방향 서비스를 내보내는 소스일 수 있다. TV 방송국 등을 그 예로 들 수 있다. 방송 콘텐츠의 생산자 내지 유통업자일 수 있다. 방송 스트림, 오디오/비디오 콘텐츠, 양방향 데이터, 방송 스케줄 또는 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 등의 어플리케이션을 다운로드 받을 수 있는 서버이다. 추출한 워터마크를 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)는 오디오/비디오 스트림과 그와 관련된 양방향 서비스를 내보내는 소스일 수 있다. TV 방송국 등을 그 예로 들 수 있다. 방송 콘텐츠의 생산자 내지 유통업자일 수 있다. 방송 스트림, 오디오/비디오 콘텐츠, 양방향 데이터, 방송 스케줄 또는 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 등의 어플리케이션을 다운로드 받을 수 있는 서버이다. 추출한 핑거프린트를 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)와 시그니처 매칭작업을 할 수 있다. 시그니처와 수신기(23040)으로부터 전달받은 핑거프린트를 매칭작업 할 수 있다. 매칭될 경우 시그니처 추출기(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 서버가 요청/응답 모델을 이용하는 경우를 설명한다. 이는 위의 도 24에 대한 설명과 유사하다.
도 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 서버가 다음 요청이 있을 때까지 기다렸다가 활성화 트리거를 보내야 한다. 도 26에서 이러한 경우를 도시하고 있다. 이로 인해 하나의 요청 구간만큼 동적 활성화가 지연될 수 있다.
도 26에서, 수신기는 ACR 서버에서 미디어 시간 MT1, MT2 및 MT3을 가지는 것으로 판단한 프레임들에 대한 시그니처를 전달할 수 있다. 미디어 시간 MT1 and MT2를 가진 프레임들의 경우, 수신기는 시간 베이스 트리거를 포함하는 응답을 받는다. 활성화 시간 Mta를 가진 동적 활성화가 미디어 시간 MTa에서 또는 바로 직전에 등장하는 경우, ACR 서버는 미디어 시간 MT3을 가진 프레임에 대해 발생하는 수신기로부터의 다음 요청이 있을 때까지 수신기에 이를 통지할 수 없다. 이때 ACR 서버 응답은 활성화 시간 MTa (약간 과거인 시간)을 가진 활성화 트리거를 포함한다. 이와 같은 상황에서, 수신기는 이 응답이 도달하면 바로 해당 활성화 트리거를 적용하는 것으로 생각할 수 있다.
여기에서, 수신기는 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하는 것이 가능하다. 그러나 이들 각각의 미디어 시간은 동일하므로, 수신기는 이들이 중복된 것으로 파악하고 이들 중 하나만 적용할 수 있다.
도 27는 요청/응답 ACR 경우의 동적 활성화의 일 실시예를 도시한 도면이다.
이하, 요청/응답 ACR 경우에서, 동적 활성화가 일어나는 경우를 설명한다. 이는 위의 도 26 에 대한 설명과 유사하다.
도 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 서버는 널, 시간 베이스 트리거, 활성화 트리거 중 하나를 리턴할 수 있다.
널 응답은 시그니처가 인식되지 않음을 지시하거나, 또는 (ACR 인제스트 모듈이 프레임에 대한 시그니처를 양방향 서비스가 없는 프로그램 세그먼트에 포함시키는 경우) 시그니처는 연관된 양방향 서비스가 없는 세그먼트에 속하는 프레임을 나타냄을 지시할 수 있다.
시간 베이스 트리거 응답은 클라이언트의 다음 요청이 있기 전에 이벤트 활성화가 발생하도록 스케줄링되어 있지 않음을 지시할 수 있다. 클라이언트는 시간 베이스 트리거들을 이용하여 미디어 시간 클럭을 유지하는 것으로 생각할 수 있다.
활성화 트리거 응답은 활성화가 곧 발생할 예정임을 지시할 수 있으며, 활성화의 시간은 트리거 내 "t=" 항에 의해 지시된다.
ACR 서버가 필요없도록 수신기들이 필요로 하는 정보를 워터마크에 직접 포함시켜 전달하는 워터마킹 ACR 시스템의 경우, 인제스트 모듈은, 각 프레임과 연과시킬 트리거를 결정하고 이 트리거를 데이터베이스 내 해당 프레임과 연관시키지 않고 해당 프레임을 위한 워터마크에 포함시키는 요청/응답 서버 모델에 대해 앞서 설명한 것과 동일한 규칙을 따를 수 있다. 인제스트 모듈과 데이터베이스에 대해서는 후술한다.
이하, 독립형(stand-alone) NRT 서비스들의 지원에에 대해 설명한다. 이는 도면에 도시되지 않았으나, 발명의 내용은 이하 설명에 한정되지 아니하고, 설계자의 의도에 따라 변경될 수 있다.
ACR 환경에 있는 수신기가 독립형 NRT 서비스들을 받기 위해서, 방송국은 NRT 서비스에의 인터넷 접속을 지원해야 하고, 수신기는 이 서비스들에 대한 SMT 와 NRT-IT 인스턴스들을 얻어야 할 수 있다.
인터넷을 통해 PSIP 테이블과 NRT 테이블을 얻기 위한 질의(query) 프로토콜에 대하여 설명한다.
방송국은 특정 방송 스트림에 대해 이 프로토콜을 지원하며, 이 때 이 방송 스트림에 대한 방송국의 시그널링 서버의 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 스트림 및 관련 양방향 서비스가 송출되는 지점으로, 예를 들어 네트워크 분배 지점 또는 TV 방송국일 수 있다.
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)은 일반적으로 오디오 및 비디오를 디코딩(압축해제)하여 이들을 시청자들에게 보여지는 TV 세트로 보낸다. 양방향 서비스 트리거들을 포함하는 DTV 클로즈드 캡션 서비스 #6은 이 TV 세트에서 이용할 수 없는 것으로 가정한다.
수신기(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)의 활성화 트리거들을 설명한다. 이는 위의 도 31에 대한 설명과 유사하다.
도 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)에 대한 활성화 트리거들을 설명한다. 이는 위의 도 33 에 대한 설명과 유사하다.
도 34는 활성화 시간 이전에 M 시간 단위보다 늦게 ACR 인제스트 모듈에 동적 활성화 트리거가 보내어지는 위의 동작 (4)에서의 상황 (c)를 도시한다
도 34는 타임라인 위에 동적 이벤트 활성화 시간과 ACR 인제스트 모듈에서 이벤트의 활성화를 알게되는 이벤트 활성화 시간 바로 전의 시간을 도시하는 도면으로서, ACR 인제스트 모듈에서 이벤트의 활성화를 알게되는 시간 뒤에 길이 M의 구간이 따라온다. 타임 라인 밑의 화살표들은 개별 프레임들의 시간을 나타낸다. 길이 M의 구간의 시작보다 선행하거나 길이 M의 구간의 끝 뒤에 오는 각 프레임은 데이터베이스에서 <media_time> 또는 <event_time> 항이 없는 트리거를 갖게 된다. 길이 M의 구간 내의 각 프레임은 데이터베이스에서 도면 아래의 두 예들과 같은 활성화 트리거를 갖게 된다. 각 프레임에 대한 "d=" 항은 이 프레임과 이벤트 활성화 시간 사이의 시간의 길이을 지시할 수 있다.(동그라미 친 수직 화살표들로 도시되어 있다.) 동그라미 친 수직 화살표들은 일반적인 수신기가 요청을 보낼 때의 예시일 수 있다. 이 경우에 수신기는 동일한 이벤트 활성화에 대해 두 개의 활성화 트리거를 받게 되지만, (음의) <d1> 값을 프레임 f1에 대한 수신기의 로컬 시간에 더하거나 (음의) <d2> 값을 프레임 f2에 대한 수신기의 로컬 시간에 더하여 산출한 활성화 시간들은 모두 동일한 결과를 가지므로, 수신기는 이들을 중복된 것으로 인식하여 수신한 첫 번째 트리거만 적용하게 된다. 첫 번째 트리거의 활성화 시간은 이를 수신한 시간 이전이므로 수신기는 이 트리거를 수신한 즉시 적용하게 된다.
도 35는 요청/응답 ACR의 경우의 ACR 클라이언트와 다른 서버들 사이의 시퀀스 다이어그램을 도시한 도면이다.
도 35는 요청/응답 모델에서 ACR 서버와 수신기(ACR 클라이언트)의 동작 프로토콜에 따라 트리거 및 TPT를 효과적으로 전송하는 실시예에 따른 시퀀스 다이어그램을 나타낸다.
이하, 요청/응답의 순서로 요청/응답 모델의 동작에 대한 일 예를 설명한다.
요청/응답 ACR의 경우의 ACR 클라이언트와 다른 서버들 사이의 시퀀스 다이어그램은 ACR 요청 1(s35010), ACR 응답 1(s35020), ACR 요청 2(s35030), ACR 응답 2(s35040), HTTP 요청 1(s35050), HTTP 응답 1(s35060), HTTP 요청 2(s35070), HTTP 응답 2(s35080), ACR 요청 3(s35090), ACR 응답 3(s35100), ACR 요청 4(s35110), ACR 응답 4(s35120)을 포함할 수 있다.
ACR 요청 1(s35010)는 수신기가 현재 시청 중인 프로그램에 대한 시그니처를 서버에 전송하는 단계이다. 서버는 전술한 ACR 서버일 수 있다. 시그니처는 핑거프린트 시그니처 또는 워터마킹 코드일 수 있다.
ACR 응답 1(s35020)는, 시그니처가 인식이 되지 않거나 연관된 양방향 서비스가 존재하지 않는 경우, ACR 서버가 널(NULL)을 리턴하는 단계이다. 전술한 널 응답을 리턴하는 경우와 같은 경우일 수 있다.
ACR 요청 2(s35030)는, 채널 혹은 프로그램이 변경된 후 수신기가 변경된 프로그램에 대한 시그니처를 ACR서버에 전송하는 단계이다.
ACR 응답 2(s35040)는, ACR 서버가 해당 프로그램과 연관된 양방향 서비스를 획득할 수 있는 주소를 포함하는 트리거(예, xbc.com/tpt504)를 리턴하는 단계이다. 이 경우는 전술한 ACR 응답 1(s35020)과는 달리, 시그니처가 인식되고 연관된 양방향 서비스가 존재하는 경우일 수 있다. 즉, 트리거가 이용가능한 경우일 수 있다. 이 경우 리턴 받는 트리거는 media_time에 대한 정보가 없는 시간 베이스 트리거일 수 있다.
HTTP 요청 1(s35050)은, 수신기가 http 프로토콜을 이용하여 전술한 ACR 응답 2(s25040)에서 수신한 주소를 이용하여, TPT 서버(예: http://xbc.com/tpt504 등)에 해당 TPT를 요청하는 단계이다.
HTTP 응답 1(s35060)는, TPT 서버가 수신기의 요청에 따라 XML로 표현된 TPT를 전송하는 단계이다.
HTTP 요청 2(s35070)는, 수신기가 http 프로토콜을 이용하여 콘텐츠 서버에 TDO 등의 어플리케이션을 요청하는 단계이다. 수신기는 TPT 내에 포함된 TDO 관련 정보를 파싱할 수 있다. TDO 관련 정보는 TDO를 다운로드 받을 수 있는 콘텐츠 서버의 주소일 수 있다. 콘텐츠 서버의 주소를 이용하여 요청을 보낼 수 있다.
HTTP 응답 2(s35080)는, 콘텐츠 서버가 수신기의 요청에 따라 해당 TDO를 전송하는 단계이다.
ACR 요청 3(s35090)은, 수신기가 현재 시청 중인 프로그램의 프레임에 대한 시그니처를 ACR 서버에 전송하는 단계이다.
ACR 응답 3(s35100)는, ACR 서버가 해당 프로그램과 연관된 양방향 서비스를 획득할 수 있는 주소를 포함하는 트리거(예, xbc.com/tpt504)를 리턴하는 단계이다. 이 경우, 전술한 ACR 응답 1(s35020)과는 달리, 시그니처가 인식되고 연관된 양방향 서비스가 존재하는 경우일 수 있다. 즉, 트리거가 이용가능한 경우일 수 있다.
ACR 요청 4(s35110)는, 수신기가 현재 시청 중인 프로그램의 프레임에 대한 시그니처를 ACR 서버에 전송하는 단계이다.
ACR 응답 4(s35120)는, ACR 서버가 수신기로부터 전송된 시그니처와 연관된 양방향 서비스와 관련된 활성화 트리거를 전송하는 단계이다. 활성화 트리거의 내용에 따라, 특정 이벤트를 특정 시간에 활성화시킬 수 있다.
도 36은 요청/응답 모델에서, 수신기가 양방향 서비스를 처리하는 방법의 일 실시예를 나타낸 도면이다.
본 발명에 따른 요청/응답 모델에서, 수신기가 양방향 서비스를 처리하는 방법의 일 실시예는, 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하는 단계(s36010), 식별자를 추출하는 단계(s36020), 상기 식별자를 포함하는 요청을 보내는 단계(s36030), 상기 콘텐트에 대한 트리거를 수신하는 단계(s36040)를 포함할 수 있다.
비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하는 단계(s36010)은, 외부의 디코딩부로부터 수신기가 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 전달받는 단계이다.
여기서, 외부의 디코딩부는 앞서 설명한 STB일 수 있다. STB에 대한 자세한 설명은 후술한다.
여기서, 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠는 앞서 설명한 STB(외부의 디코딩부)이 수신기로 전달하는 오디오/비디오 콘텐츠일 수 있다.
외부의 디코딩부는 MVPD 등으로부터 전달받은 A/V 콘텐츠를 디코딩(압축해제)시킨 후, 수신기로 전달할 수 있다. 수신기는 외부의 디코딩부 등으로부터 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 전달받아 시청자에게 보여줄 수 있다. 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠는 앞서 설명한 ACR 인제스트 모듈의 동작대로 처리된 상태일 수 있다. 즉, ACR 인제스트 모듈은 핑거프린팅 ACR 시스템의 경우 프레임들의 시그니처(핑거프린트)를 산출거나 코드를 기반으로 하는 워터마킹 ACR 시스템의 경우 코드로 이루어진 워터마크를 프레임에 삽입할 수 있다. 여기서 프레임들은 STB에 의해 디코딩/압축해제 되기 전의 오디오/비디오 콘텐츠에 관한 것일 수 있다. ACR 인제스트 모듈은 다른 메타데이터와 함께 시그니처 또는 코드에 연관된 각 프레임의 media_time을 데이터베이스에 저장할 수 있다.
식별자를 추출하는 단계(s36020)은, 수신기가 전달받은 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠의 한 프레임에서 식별자를 추출하는 단계이다.
여기서 식별자는 전달받은 콘텐츠의 프레임을 식별하는 식별자일 수 있다. 이 식별자는 앞서 설명한 개념 중, 핑거프린트 시그니처 또는 워터마크 코드일 수 있다. 본 실시예는 핑거프린팅 또는 워터마킹 중 어느 하나의 기법에 한정되지 아니한다.
여기서 '추출'은 전달받은 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠의 한 프레임에서 식별자를 추출하는 것으로서, 앞서 설명한 '시그니처 산출', '워터마크 추출', '시그니처 생성' 에 대응할 수 있다.
여기서 '추출'은 앞서 설명한 ACR 클라이언트에서 일어나는 동작일 수 있다. 단, 이는 일 실시예일 뿐, 발명의 사상은 이에 한정되지 아니하고, 다른 모듈에서 일어나도록 설계자가 설계할 수 있다. ACR 클라이언트는 수신기 내에 위치할 수 있다.
식별자를 추출하는 단계(s36020)에서 한 프레임에 해당하는 식별자를 추출해 내게 된다. 추출된 식별자는 앞서 설명한대로, ACR 서버 등에 보내질 수 있다. 앞서 설명한 동작과 마찬가지로, ACR 서버는 전달받은 식별자를 데이터베이스 내의 기록들과 매칭작업을 할 수 있다. 여기서 ACR 서버 와 데이터베이스는 앞서 설명한 ACR 서버와 데이터베이스일 수 있다. 데이터베이스 내의 기록들은 이전에 ACR 인제스트 모듈에 의해 저장된 기록들 일 수 있다.
본 발명의 일 실시예는, 전달받은 콘텐츠의 프레임들에서 식별자들을 주기적으로 추출(생성)할 수 있다.
본 발명의 일 실시예는, 식별자를 추출하는 주기가 5초일 수 있다. 이는 설계자의 의도에 따라 변경 가능한 사항이다.
상기 식별자를 포함하는 요청을 보내는 단계(s36030)은, 앞서 추출한 식별자를 포함한 요청을 서버에 보내는 단계이다.
여기서, 식별자는 앞서 추출한 식별자로서, 핑거프린트 시그니처 또는 워터마크 코드일 수 있다. 본 실시예는 핑거프린팅 또는 워터마킹 중 어느 하나의 기법에 한정되지 아니한다.
여기서, 요청은 상기 식별자를 포함할 수 있다. 여기서, 수신기는 서버에 요청을 주기적으로 보낼 수 있다. 하나의 요청은 하나의 식별자를 포함할 수 있다. 여기서 주기의 길이는 설계자의 의도에 따라 변경 가능한 사항이다.
여기서, 서버는 앞서 설명한 ACR 서버일 수 있다. 서버는 요청을 전달받고, 데이터베이스와 매칭작업을 할 수 있다. 여기서 ACR 서버와 데이터베이스는 앞서 설명한 ACR 서버와 데이터베이스일 수 있다. 데이터베이스 내의 기록들은 이전에 ACR 인제스트 모듈에 의해 저장된 기록들 일 수 있다.
상기 콘텐트에 대한 트리거를 수신하는 단계(s36040)은, 서버로 보내진 요청 및 식별자가 데이터베이스 내의 기록들과 매칭되는지에 따라, 또한 어떠한 트리거가 매칭된 기록들에 존재하는지에 따라, 서버로부터 트리거를 전달받는 단계이다.
여기서, 트리거는 앞서 수신기가 STB로부터 전달받은 콘텐츠에 관한 것일 수 있다.
여기서, 콘텐츠는 앞서 설명한, STB 로부터 전달받은 콘텐츠일 수 있다.
여기서, 트리거는 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블에서 특정 양방향 이벤트를 참조하거나 해당 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알릴 수 있다.
여기서, 어플리케이션 파라미터 테이블은 적어도 하나의 어플리케이션에 대한 정보를 포함할 수 있다.
여기서, 서버는 앞서 설명한 ACR 서버일 수 있다. 데이터베이스는 앞서 설명한 데이터베이스일 수 있다. 여기서 식별자는 핑거프린트 시그니처 또는 워터마크 코드일 수 있다. 본 실시예는 핑거프린팅 또는 워터마킹 중 어느 하나의 기법에 한정되지 아니한다.
서버는 전달받은 요청/식별자를 이용해 데이터베이스와 매칭작업을 실행할 수 있다. 매칭작업은 이전에 ACR 인제스트 모듈이 데이터베이스에 저장한 기록들과 이루어질 수 있다. 서버는 식별자가 데이터베이스의 식별자와 매칭되는 경우, 서버는 데이터베이스로부터 그 관련된 기록을 받을 수 있다. 이 경우, 기록은 시간 베이스 트리거 또는 활성화 트리거를 포함할 수 있다. 어떤 트리거를 포함할지는 ACR 인제스트 모듈이 이전에 기록에 어떠한 것을 삽입했는지에 따라 달라질 수 있다. 서버가 데이터베이스로부터 기록을 받으면, 서버는 수신기로 획득한 트리거 또는 트리거들을 보낼 수 있다.
본 발명의 일 실시예는, 다음 요청을 보내기 전에 이벤트 활성화가 발생하도록 예정되지 않을 경우 트리거는 시간 베이스 트리거이다. 여기서, 시간 베이스 트리거는 세그먼트의 시간을 유지하기 위해 사용된다. 시간 베이스 트리거는 앞서 설명한 시간 베이스 트리거의 동작을 따를 수 있다.
본 발명의 일 실시예는, 활성화가 발생할 예정인 경우 트리거는 활성화 트리거이다. 여기서, 활성화 트리거는 해당 이벤트에 대한 활성화 시간을 설정한다. 여기서, 활성화 시간은 활성화 트리거 내의 타이밍 값 항에 의해 지시된다. 활성화 트리거는 앞서 설명한 활성화 트리거의 동작을 따를 수 있다. 활성화 트리거는 어플리케이션의 이벤트에 적용되어, 특정 시간에 활성화를 일으킬 수 있다. 이벤트의 활성화를 통해, 시청자는 양방향 서비스를 제공받을 수 있다. 본 발명의 실시예에 따른 활성화 트리거 전달의 경우, 앞서 설명한 ACR 환경의 경우, 즉, 수신기가 인터넷 연결과, 방송 스트림으로부터의 비압축된 오디오 및 비디오에 대한 접속만 있는 경우에도 양방향 서비스를 제공받을 수 있다.
본 발명의 일 실시예는, 수신기가 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하면, 활성화 트리거는 한 번 적용된다. 앞서 설명한 바와 같이, 같은 이벤트 활성화에 대해, 수신기는 복수개의 활성화 트리거를 받을 수 있다. 본 발명의 일 실시예 중 하나는 주기적으로 식별자를 추출하여 서버에 보낼 수 있다. 이 때, 주기적 요청에 대한 응답으로서, 복수개의 활성화 트리거를 받을 수 있다. 앞서 설명한 바와 같이, 이 경우, 활성화 트리거는 같은 "t=" 항을 가지기 때문에 수신기는 이것이 중복된 것임을 알 수 있고, 하나의 활성화 트리거만을 적용할 수 있다.
본 발명의 일 실시예는, 활성화 시간 이후에 활성화 트리거가 수신되는 경우 활성화 트리거는 도달하자마자 적용된다. 이 실시예는 앞서 설명한 동적 활성화의 경우와 같다. 서버가 활성화 시간 보다 앞서 활성화 트리거를 수신기에 보낼 수 없을 만큼 활성화에 대해 늦게 인지한 경우, 서버는 수신기의 다음 요청까지 기다린 후, 다음 요청에 대한 응답으로 활성화 트리거를 보낼 수 있다. 이 경우 해당 활성화 트리거는 이미 지난 활성화 시간을 가리킬 수 있다. 이럴 경우, 수신기는 활성화 트리거를 받자마자 이를 적용할 수 있다.
본 발명의 일 실시예는, 양방향 서비스를 처리하는 방법에 있어, 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드 받는 단계를 더 포함할 수 있다. 트리거가 새로운 어플리케이션 파라미터 테이블을 식별하는 어플리케이션 파라미터 테이블 식별자를 포함하는 경우, 수신기가 해당 어플리케이션 파라미터 테이블과 함께 전달된 URL 정보를 이용하여 새로운 어플리케이션 파라미터 테이블을 이미 검색하지 않았으면, 수신기는 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드 받는다. 앞서 설명한 바와 같이, 수신기는 새로운 어플리케이션 파라미터 테이블 식별자를 가진 트리거를 수신한 경우, 새로운 어플리케이션 파라미터 테이블 (예를 들어, TPT)를 다운로드 받음으로써, 관련된 세그먼트에 대한 양방향 서비스를 제공하는 데 있어 새로운 정보를 얻을 수 있다. 여기서 발명의 일 실시예는, http 프로토콜을 이용하여 어플리케이션 파라미터 테이블 서버에 새로운 어플리케이션 파라미터 테이블을 요청하고, 다운로드 받을 수 있다. 여기서, 발명의 일 실시예는, 어플리케이션 파라미터 테이블이 XML 또는 이진 포맷 형태로 되어 있을 수 있다. 여기서, 어플리케이션 파라미터 테이블 식별자는 앞서 설명한 locator_part일 수 있다. 여기서, URL 정보는 앞서 설명한 URLList일 수 있다.
본 발명의 일 실시예는, 양방향 서비스를 처리하는 방법에 있어, 어플리케이션 URL을 얻는 단계, 새로운 어플리케이션을 다운로드하는 단계를 더 포함할 수 있다. 수신기는 해당 어플리케이션 파라미터 테이블로부터 또는 수신기가 해당 새로운 어플리케이션을 가지지 않은 경우 새로운 어플리케이션 파라미터 테이블로부터 해당 트리거와 연관된 새로운 어플리케이션에 대한 어플리케이션 URL을 얻을 수 있다. 그리고, 수신기는 이 어플리케이션 URL을 이용하여 새로운 어플리케이션을 다운로드 할 수 있다. 여기서, 수신기는 어플리케이션 파라미터 테이블(예를 들어, TPT) 내에 포함된 어플리케이션(예를 들어, TDO) 관련 정보를 파싱하고 서버에 어플리케이션을 요청할 수 있다. 여기서 요청은 http 프로토콜을 이용할 수 있다. 여기서, 서버는 콘텐츠 서버일 수 있다. 서버는 수신기의 요청에 따라 해당 어플리케이션을 전송할 수 있다.
본 발명의 일 실시예는, 해당 시간이 미디어 시간일 수 있고, 이 미디어 시간은 콘텐트 아이템의 재생 중 한 지점을 참조하는 파라미터일 수 있다.
본 발명의 일 실시예는, 어플리케이션이 선언적 객체, 트리거된 선언적 객체, 비실시간 선언적 객체, 또는 언바운드 선언적 객체이다.
본 발명의 일 실시예는, 통신 세션이 요청과 응답을 주고 받을 때를 제외하고는, 닫혀 있을 수 있다. 통신 세션은 요청/응답 인스턴스들 사이에서 열린 상태로 유지되지 않는다.
본 발명의 일 실시예는, 수신기가 아닌, 서버 측에서 먼저 메시지를 보낼 수 없을 수 있다. 해당 서버(예를 들어, ACR 서버)가 해당 클라이언트(예를 들어, 수신기)로 메시지를 개시하는 것이 실현가능하지 않을 수 있다.
본 발명의 일 실시예는, 수신기가 트리거가 아닌 널 응답을 받을 수 있다. 서버가 전달받은 식별자가 데이터베이스에 있는 식별자와 매칭되지 않을 경우, 서버는 데이터베이스로부터, "no match" 지시자를 전달받을 수 있다. 서버가 "no match" 지시자를 전달받은 경우, 서버는 수신기에 널 응답을 리턴할 수 있다.
본 발명의 일 실시예는, 서버에, 어떠한 추가적인 지능을 요구하지 않을 수 있다. 서버는 단순히 수신기(예를 들어, ACR 클라이언트)에 데이터베이스에서 찾은 정보를 전달할 뿐일 수 있다. 본 발명의 동작에 대한 모든 지능은 ACR 인제스트 모듈에서 담당할 수 있다.
도 37는 본 발명에서, 수신기의 구조도의 일 실시예를 나타낸 도면이다.
본 발명의 일 실시예는, 수신기는 안테나(rcvr1010), 튜너(rcvr1020), VSB 또는 DVB 복조기(rcvr1030), MPEG-2TS 시스템 디코더(rcvr1040), 캡션 모듈(rcvr1050), 트리거 모듈(rcvr1060), 웹 브라우저(rcvr1070), 네트워크 프로토콜 스택(rcvr1080), 네트워크 인터페이스(rcvr1090), UI 모듈(rcvr1100), 오디오 디코더(rcvr1110), 비디오 디코더(rcvr1120), 스피커(rcvr1130), 디스플레이 모듈(rcvr1140), 그래픽 프로세서(rcvr1150), 리모콘 수신기(rcvr1160) 및/또는 리모콘(rcvr1170)을 포함할 수 있다.
안테나(rcvr1010)는 방송 스트림에 따라 방송 신호를 수신할 수 있다. 여기서, 안테나(rcvr1010)는 통상의 기술분야에서 사용되는 것일 수 있다.
튜너(rcvr1020)는 수신기의 채널을 탐색하거나 여기에 맞출 수 있고, 무선 주파수 증폭기, a 국부 발진기(local oscillator), 주파수 변환입력 회로, 탐색기(seeker) 등을 포함할 수 있다. 튜너(rcvr1020)는 통상의 기술분야에서 사용되는 것일 수 있다.
VSB 또는 DVB 복조기(rcvr1030)는 VSB 신호 또는 DVB 신호를 복조할 수 있다. VSB or DVB 복조기(rcvr1030)는 변조된 VSB 또는 DVB (예, OFDM-modulated 신호)를 원래의 신호로 복원할 수 있다. VSB 또는 DVB 복조기(rcvr1030)의 복조 과정은 통상의 기술분야에서 사용되는 것일 수 있다.
MPEG-2TS 시스템 디코더(rcvr1040)는 복조된 신호의 전송 스트림(TS)을 디코딩할 수 있다. MPEG-2TS 시스템 디코더(rcvr1040)는 전송 스트림으로부터 캡션 모듈(rcvr1050)로 캡션 스트림을 얻어서 전달할 수 있다. MPEG-2TS 시스템 디코더(rcvr1040)는 디코딩된 오디오 및 비디오 신호를 오디오/비디오 디코더(rcvr1120)로 보낼 수 있다.
캡션 모듈(rcvr1050)은 캡션 스트림을 수신할 수 있다. 캡션 모듈(rcvr1050)은 서비스 #6 또는 다른 서비스들을 모니터링하여 서비스 #6 또는 해당 트리거의 전송을 위한 서비스들이 선택되어 트리거 모듈(rcvr1060)로 보내지는지 여부 또는 캡션 텍스트가 처리되어 화면에 보여지는지 여부를 판단할 수 있다. 트리거 데이터는 트리거 모듈(rcvr1060)에 전달될 있다. 다른 캡션 서비스드은 캡션 텍스트 처리가 이루어져 그래픽 프로세서(rcvr1150)로 보내질 있다.
트리거 모듈(rcvr1060)은 트리거, TPT, 및/또는 AMT 정보 등을 파싱하여, 파싱된 데이터를 처리할 수 있다. 트리거 모듈(rcvr1060)은 트리거의 URI 정보 값을 이용하여, 네트워크 프로토콜 스택(rcvr1080)을 통해 해당 네트워크에 접속할 수 있다. URI 정보 값은 HTTP 서버의 주소일 수 있다. 트리거 모듈(rcvr1060) TPT 파일 내용을 분석하여 TDO URL을 얻을 수 있다. 또한, 트리거 모듈(rcvr1060)은 AMT를 파싱하여 데이터를 처리할 수 있다. 그 밖의 정보들도 파싱하여 얻을 수 있다. AMT 메시지를 수신한 후에는 정해진 시간과 동작에 따라서 웹 브라우저에 해당되는 TDO URL을 전달하거나 혹은 정해진 시간에 현재 동작하는 TDO를 중단시키거나 할 수 있다. 이것은 TDO 동작에 해당되는 동작으로 트리거 모듈(rcvr1060)이 웹 브라우저에 명령을 내려서 동작할 수 있게 할 수 있다. 본 발명과 관련된 트리거 모듈(rcvr1060) 의 동작에 관해서 자세한 사항은 후술한다.
웹 브라우저(rcvr1070) 는 트리거 모듈(rcvr1060) 이 내린 명령, UI 모듈(rcvr1100)에서 전달받은 브라우저 키 코드, 리모콘 수신기(rcvr1160)가 전달한 브라우저 키 코드 등을 전달받아 네트워크 프로토콜 스택(rcvr1080)과 통신할 수 있다.
네트워크 프로토콜 스택(rcvr1080)은 트리거 모듈(rcvr1060) 및 웹 브라우저와 통신하여 네트워크 인터페이스(rcvr1090)를 통해 서버에 접속할 수 있다.
네트워크 인터페이스(rcvr1090) 는 다른 여러 장치의 공통 접속이나 망 컴퓨터 및 외부 망의 접속을 수행한다. 네트워크 인터페이스는 서버에 접속하여 TDO, TPT, AMT 등을 다운로드 받을 수 있다. 여기서 네트워크 인터페이스(rcvr1090)의 동작은 통상의 기술분야에서 사용되는 네트워크 인터페이스(rcvr1090)의 동작일 수 있다. 본 발명과 관련된 네트워크 인터페이스(rcvr1090)의 동작에 관해서 자세한 사항은 후술한다.
UI 모듈(rcvr1100)은 리모콘(rcvr1170)을 이용해 시청자가 입력한 정보를 리모콘 수신기(rcvr1160)를 통해 전달받을 수 있다. 전달받은 정보가 망을 이용한 서비스 등에 관련된 것일 경우 브라우저 키 코드를 웹 브라우저로 전달할 수 있다. 전달받은 정보가 현재 보여지는 비디오에 관한 것이면, 그래픽 프로세서(rcvr1150)를 거쳐 디스플레이 모듈(rcvr1140)로 신호를 전달할 수 있다.
오디오 디코더(rcvr1110)는 MPEG-2TS 시스템 디코더(rcvr1040)로부터 전달받은 오디오 신호를 디코딩할 수 있다. 그 후 스피커로 디코딩한 오디오 신호를 보내 시청자에게 출력하게 할 수 있다. 여기서 오디오 디코더(rcvr1110)는 통상의 기술분야에서 사용되는 오디오 디코더일 수 있다.
비디오 디코더(rcvr1120) MPEG-2TS 시스템 디코더(rcvr1040)로부터 전달받은 비디오 신호를 디코딩할 수 있다. 그 후 디스플레이 모듈(rcvr1140)로 디코딩한 비디오 신호를 보내 시청자에게 출력하게 할 수 있다. 여기서 비디오 디코더(rcvr1120)는 통상의 기술분야에서 사용되는 비디오 디코더일 수 있다.
스피커(rcvr1130)는 오디오 신호를 시청자에게 출력할 수 있다. 스피커는 통상의 기술분야에서 사용되는 스피커일 수 있다.
디스플레이 모듈(rcvr1140) 은 비디오 신호를 시청자에게 출력할 수 있다. 디스플레이 모듈(rcvr1140) 은 통상의 기술분야에서 사용되는 디스플레이 장치일 수 있다. 본 발명과 관련된 디스플레이 모듈((rcvr1140))의 동작에 관해서 자세한 사항은 후술한다.
그래픽 프로세서(rcvr1150)는 캡션 모듈(rcvr1050)로부터 전달받은 캡션 텍스트와 UI 모듈(rcvr1100)로부터 받은 시청자의 입력정보를 그래픽화 하는 처리과정을 거칠 수 있다. 처리된 정보들을 디스플레이 모듈(rcvr1140)로 전달할 수 있다. 그래픽 프로세서(rcvr1150) 은 통상의 기술분야에서 사용되는 그래픽 프로세서일 수 있다.
리모콘 수신기(rcvr1160)는 리모콘(rcvr1170)으로부터 정보를 받을 수 있다. 이 때 키 코드는 UI 모듈(rcvr1100)로 전달하고, 브라우저 키 코드는 웹 브라우저로 전달할 수 있다.
리모콘(rcvr1170)은 시청자가 입력한 신호를 리모콘 수신기(rcvr1160)로 전달한다. 리모콘(rcvr1170)은 시청자가 가상 채널을 바꾸려는 입력을 받을 수 있다. 또한 어플리케이션에 대해 시청자가 선택한 정보 등을 입력받을 수 있다. 리모콘(rcvr1170)은 리모콘 수신기(rcvr1160)로 입력받은 정보를 전달할 수 있다. 이 때 적외선(IR)를 이용하여 해당 정보를 일정거리 밖에서 원격으로 전달할 수 있다.
도 38는 방송을 셋탑 박스에서 HDMI 혹은 외부 입력으로 수신하는 경우의 수신기 구조도의 일 실시예를 나타낸 도면이다.
도 38에 도시된 본 발명의 일 실시예에서, 수신기는 안테나(rcvr2010), 튜너(rcvr2020), 셋탑 박스(rcvr2030), VSB 또는 DVB 복조기(rcvr2040), HDMI(rcvr2050), MPEG-2 TS 시스템 디코더(rcvr2060), 캡션 모듈(rcvr2070), 트리거 모듈(rcvr2080), 웹 브라우저(rcvr2090), 네트워크 프로토콜 스택(rcvr2100), 네트워크 인터페이스(rcvr2110), UI 모듈(rcvr2120), ACR 모듈(rcvr2130), 오디오 디코더(rcvr2140), 비디오 디코더(rcvr2150), 스피커(rcvr2160), 디스플레이 모듈(rcvr2170), 그래픽 프로세서(rcvr2180), 리모콘 수신기(rcvr2190), 리모콘(rcvr2200)을 포함할 있다.
이 경우에는, 일단 방송 스트림이 비디오와 오디오가 원시 데이터(raw data)이므로 캡션 스트림에 포함되어 있는 트리거를 수신할 수 없을 수 있다. 본 발명에 관한 자세한 사항은 후술한다.
여기서 the 모듈s excluding the 셋탑 박스(rcvr2030), HDMI(rcvr2050), ACR 모듈(rcvr2130)을 제외한 나머지 모듈들은, 도 37에서의 실시예에서 설명한 모듈들과 그 역할이 유사하다.
셋탑 박스(rcvr2030), HDMI(rcvr2050), ACR 모듈(rcvr2130)에 대한 설명은 다음과 같다.
셋탑 박스(rcvr2030)는 디지털망을 통해 비디오 서버로부터 수신한 압축신호를 원래의 영상 및 음성신호로 복원할 수 있다. TV를 인터넷 사용자 인터페이스로 만들어줄 수 있다.
HDMI(rcvr2050)는 비압축 방식의 디지털 비디오/오디오 인터페이스 규격의 하나인 고화질 멀티미디어 인터페이스일 수 있다. HDMI(rcvr2050)는 셋탑 박스(rcvr2030)와 AV기기, 즉 오디오 디코더(rcvr2140), 비디오 디코더(rcvr2150) 사이에 인터페이스를 제공할 수 있다.
ACR 모듈(rcvr2130)는 오디오 디코더(rcvr2140)와 비디오 디코더(rcvr2150)로부터의 방송 콘텐츠를 자동으로 인식할 수 있다. 인식된 현재의 콘텐츠를 바탕으로 트리거 모듈(rcvr2080)과 네트워크 인터페이스(rcvr2110)를 통해 ACR 서버로 질의(query)를 보내어 트리거를 위한 TPT/AMT를 수신할 수 있다.
도 39는 요청/응답 모델에서, 양방향 서비스를 처리하는 장치의 일 실시예를 나타낸 도면이다.
본 발명에 따른 요청/응답 모델에서, 양방향 서비스를 처리하는 장치의 일 실시예는, 수신 모듈(39010), 식별자 추출 모듈(39020), 네트워크 인터페이스(39030)를 포함할 수 있다.
수신 모듈(39010)은, 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 외부 디코딩부로부터 전달받는 모듈이다.
여기서, 외부 디코딩부는 앞서 설명한 STB일 수 있다.
여기서, 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠는 앞서 설명한 STB(외부 디코딩부)가 수신기로 전달하는 오디오/비디오 콘텐츠일 수 있다.
여기서, 수신 모듈(39010)은 도 38의 HDMI에 해당할 수 있다. 단, 수신 모듈(39010)은 도 37 또는 도 38에 도시되지 않은 다른 모듈일 수 있다. 이는 설계자의 의도에 따라 변경될 수 있다.
외부 디코딩부는 MVPD 등으로부터 전달받은 A/V 콘텐츠를 디코딩(압축해제)시킨 후, 수신 모듈(39010)로 전달할 수 있다. 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠는 앞서 설명한 ACR 인제스트 모듈의 동작대로 처리된 상태일 수 있다. 즉, ACR 인제스트 모듈은 은 핑거프린팅 ACR 시스템의 경우 프레임들의 시그니처(핑거프린트)를 산출거나 코드를 바탕으로 하는 워터마킹 ACR 시스템의 경우 코드로 이루어진 워터마크를 프레임에 삽입할 수 있다. 여기서 프레임들은 STB에 의해 디코딩/압축해제되기 전의 오디오/비디오 콘텐츠에 관한 것일 수 있다. ACR 인제스트 모듈은 다른 메타데이터와 함께 시그니처 또는 코드에 연관된 각 프레임의 media_time을 데이터베이스에 저장할 수 있다.
식별자 추출 모듈(39020)은, 수신 모듈(39010)이 전달받은 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠의 한 프레임에서 식별자를 추출하는 모듈이다.
여기서 식별자는 전달받은 콘텐츠의 프레임을 식별하는 식별자일 수 있다. 이 식별자는 앞서 설명한 개념 중, 핑거프린트 시그니처 또는 워터마크 코드일 수 있다. 본 실시예는 핑거프린팅 또는 워터마킹 중 어느 하나의 기법에 한정되지 아니한다.
여기서 '추출'은 전달받은 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠의 한 프레임에서 식별자를 추출하는 것으로서, 앞서 설명한 '시그니처 산출', '워터마크 추출', '시그니처 생성' 에 대응할 수 있다.
식별자 추출 모듈(39020)에서 한 프레임에 해당하는 식별자를 추출해 내게 된다. 추출된 식별자는 앞서 설명한대로, ACR 서버 등에 보내질 수 있다. 앞서 설명한 동작과 마찬가지로, ACR 서버는 전달받은 식별자를 데이터베이스 내의 기록들과 매칭 작업을 할 수 있다. 여기서 ACR 서버와 데이터베이스는 앞서 설명한 ACR 서버와 데이터베이스일 수 있다. 데이터베이스 내의 기록들은 이전에 ACR 인제스트 모듈에 의해 저장된 기록들일 수 있다.
여기서, 식별자 추출 모듈(39020)은 도 38의 ACR 모듈에 해당할 수 있다. 단, 식별자 추출 모듈(39020)은 도 37 또는 도 38에 도시되지 않은 다른 모듈일 수 있다. 이는 설계자의 의도에 따라 변경될 수 있다.
본 발명의 한 실시예는, 전달받은 콘텐츠의 프레임들에서 식별자들을 주기적으로 추출(생성)할 수 있다.
본 발명의 한 실시예는 식별자를 추출하는 주기가 5초일 수 있다. 이는 설계자의 의도에 따라 변경 가능한 사항이다.
네트워크 인터페이스(39030)는, 서버에 앞서 추출한 식별자를 포함한 요청을 보내고, 서버로부터 콘텐츠에 관련한 트리거를 받는 모듈이다. 여기서 트리거는 요청에 근거하여 받을 수 있다.
여기서, 네트워크 인터페이스(39030)은 도 38의 네트워크 인터페이스에 해당할 수 있다. 단, 네트워크 인터페이스(39030)은 도 37 또는 도 38 에 도시되지 않은 다른 모듈 일 수 있다. 이는 설계자의 의도에 따라 변경될 수 있다.
여기서, 식별자는 앞서 추출한 식별자로서, 핑거프린트 시그니처 또는 워터마크 코드일 수 있다. 본 실시예는 핑거프린팅 또는 워터마킹 중 어느 하나의 기법에 한정되지 아니한다.
여기서, 요청은 상기 식별자를 포함할 수 있다. 여기서, 네트워크 인터페이스(39030)는 서버에 요청을 주기적으로 보낼 수 있다. 하나의 요청은 하나의 식별자를 포함할 수 있다. 여기서 주기의 길이는 설계자의 의도에 따라 변경 가능한 사항이다.
여기서, 서버는 앞서 설명한 ACR 서버일 수 있다. 서버는 요청을 전달받고, 데이터베이스와 매칭작업을 할 수 있다. 여기서 ACR 서버와 데이터베이스는 앞서 설명한 ACR 서버와 데이터베이스일 수 있다. 데이터베이스 내의 기록들은 이전에 ACR 인제스트 모듈에 의해 저장된 기록들일 수 있다.
여기서, 트리거는 앞서 수신 모듈(39010)이 STB로부터 전달받은 콘텐츠에 관한 것일 수 있다.
여기서, 콘텐츠는 앞서 설명한, STB로부터 전달받은 콘텐츠 일 수 있다.
여기서, 트리거는 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블에서 특정 양방향 이벤트를 참조하거나 해당 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알릴 수 있다.
여기서, 어플리케이션 파라미터 테이블은 적어도 하나의 어플리케이션에 대한 정보를 포함할 수 있다.
여기서, 서버는 앞서 설명한 ACR 서버 일 수 있다. 데이터베이스는 앞서 설명한 데이터베이스일 수 있다. 여기서 식별자는 핑거프린트 시그니처 또는 워터마크 코드일 수 있다. 본 실시예는 핑거프린팅 또는 워터마킹 중 어느 하나의 기법에 한정되지 아니한다.
서버는 전달받은 요청/식별자를 이용해 데이터베이스와 매칭작업을 실행할 수 있다. 매칭작업은 이전에 ACR 인제스트 모듈이 데이터베이스에 저장한 기록들과 이루어질 수 있다. 서버는 식별자 가 데이터베이스의 식별자와 매칭되는 경우, 서버는 데이터베이스로부터 그 관련된 기록을 받을 수 있다. 이 경우, 기록은 시간 베이스 트리거 또는 활성화 트리거를 포함할 수 있다. 어떤 트리거를 포함할지는 ACR 인제스트 모듈이 이전에 기록에 어떠한 것을 삽입했는지에 따라 달라질 수 있다. 서버가 데이터베이스로부터 기록을 받으면, 서버는 네트워크 인터페이스(39030)로 획득한 트리거 또는 트리거들을 보낼 수 있다.
본 발명의 일 실시예는, 다음 요청을 보내기 전에 이벤트 활성화가 발생하도록 예정되지 않을 경우 트리거는 시간 베이스 트리거이다. 여기서, 시간 베이스 트리거는 세그먼트의 시간을 유지하기 위해 사용된다. 시간 베이스 트리거는 앞서 설명한 시간 베이스 트리거의 동작을 따를 수 있다.
본 발명의 일 실시예는, 활성화가 발생할 예정인 경우 트리거는 활성화 트리거이다. 여기서, 활성화 트리거는 해당 이벤트에 대한 활성화 시간을 설정한다. 여기서, 활성화 시간은 활성화 트리거 내의 타이밍 값 항에 의해 지시된다. 활성화 트리거는 앞서 설명한 활성화 트리거의 동작을 따를 수 있다. 활성화 트리거는 어플리케이션의 이벤트에 적용되어, 특정 시간에 활성화를 일으킬 수 있다. 이벤트의 활성화를 통해, 시청자는 양방향 서비스를 제공받을 수 있다. 본 발명의 실시예에 따른 활성화 트리거 전달의 경우, 앞서 설명한 ACR 환경의 경우, 즉, 수신기가 인터넷 연결과, 방송 스트림으로부터의 비압축된 오디오 및 비디오에 대한 접속만 있는 경우에도 양방향 서비스를 제공받을 수 있다.
본 발명의 일 실시예는, 장치가 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하면, 활성화 트리거는 한 번 적용된다. 앞서 설명한 바와 같이, 같은 이벤트 활성화에 대해, 장치는 복수개의 활성화 트리거를 받을 수 있다. 본 발명의 일 실시예 중 하나는 주기적으로 식별자를 추출하여 서버에 보낼 수 있다. 이 때, 주기적 요청에 대한 응답으로서, 복수개의 활성화 트리거를 받을 수 있다. 앞서 설명한 바와 같이, 이 경우, 활성화 트리거는 같은 "t=" 항을 가지기 때문에 장치는 이 것이 중복된 것임을 알 수 있고, 하나의 활성화 트리거만을 적용할 수 있다.
본 발명의 일 실시예는, 활성화 시간 이후에 활성화 트리거가 수신되는 경우 활성화 트리거는 도달하자마자 적용된다. 이 실시예는 앞서 설명한 동적 활성화의 경우와 같다. 서버가 활성화 시간 보다 앞서 활성화 트리거를 장치에 보낼 수 없을 만큼 활성화에 대해 늦게 인지한 경우, 서버는 장치의 다음 요청까지 기다린 후, 다음 요청에 대한 응답으로 활성화 트리거를 보낼 수 있다. 이 경우 해당 활성화 트리거는 이미 지난 활성화 시간을 가리킬 수 있다. 이럴 경우, 장치는 활성화 트리거를 받자마자 이를 적용할 수 있다.
본 발명의 일 실시예는, 네트워크 인터페이스(39030)는, 트리거가 새로운 어플리케이션 파라미터 테이블을 식별하는 어플리케이션 파라미터 테이블 식별자를 포함하는 경우, 수신기가 해당 어플리케이션 파라미터 테이블과 함께 전달된 URL 정보를 이용하여 새로운 어플리케이션 파라미터 테이블을 이미 검색하지 않았으면, 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드하도록 더 구성된다. 앞서 설명한 바와 같이, 이 장치는 새로운 어플리케이션 파라미터 테이블 식별자를 가진 트리거를 수신한 경우, 새로운 어플리케이션 파라미터 테이블(예를 들어, TPT)를 다운로드 받음으로써, 관련된 세그먼트에 대한 양방향 서비스를 제공하는 데 있어 새로운 정보를 얻을 수 있다. 여기서 발명의 일 실시예는, http 프로토콜을 이용하여 어플리케이션 파라미터 테이블 서버 에 새로운 어플리케이션 파라미터 테이블을 요청하고, 다운로드 받을 수 있다. 여기서, 발명의 일 실시예는 어플리케이션 파라미터 테이블이 XML 또는 이진 포맷 형태로 되어 있을 수 있다. 여기서, 어플리케이션 파라미터 테이블 식별자는 앞서 설명한 locator_part일 수 있다. 여기서, URL 정보는 앞서 설명한 URLList 일 수 있다.
본 발명의 일 실시예는, 장치는, 장치에 새로운 어플리케이션이 없는 경우 어플리케이션 파라미터 테이블 또는 새로운 어플리케이션 파라미터 테이블로부터 트리거와 연관된 새로운 어플리케이션에 대해 어플리케이션 URL을 얻는 트리거 모듈을 더 포함하고, 네트워크 인터페이스는 이 어플리케이션 URL을 이용하여 새로운 어플리케이션을 다운로드하도록 더 구성된다. 여기서, 상기 장치는 어플리케이션 파라미터 테이블(예를 들어, TPT) 내에 포함된 어플리케이션(예를 들어, TDO) 관련 정보를 파싱하고 서버에 어플리케이션을 요청할 수 있다. 여기서 요청은 http 프로토콜을 이용할 수 있다. 여기서, 서버는 콘텐츠 서버일 수 있다. 서버는 장치의 요청에 따라 해당 어플리케이션을 전송할 수 있다.
본 발명의 일 실시예는, 해당 시간이 미디어 시간일 수 있고, 이 미디어 시간은 콘텐트 아이템의 재생 중 한 지점을 참조하는 파라미터일 수 있다.
본 발명의 일 실시예는, 어플리케이션이 선언적 객체, 트리거된 선언적 객체, 비실시간 선언적 객체, 또는 언바운드 선언적 객체이다.
본 발명의 일 실시예는, 통신 세션이 요청과 응답을 주고 받을 때를 제외하고는, 닫혀 있을 수 있다. 통신 세션은 요청/응답 인스턴스들 사이에서 열린 상태로 유지되지 않는다.
본 발명의 일 실시예는, 상기 장치가 아닌, 서버 측에서 먼저 메시지를 보낼 수 없을 수 있다. 해당 서버(예를 들어, ACR 서버)가 해당 클라이언트(예를 들어, 상기 장치)로 메시지를 개시하는 것이 실현가능하지 않을 수 있다.
본 발명의 일 실시예는, 네트워크 인터페이스(39030)가 트리거가 아닌 널 응답을 받을 수 있다. 서버가 전달받은 식별자가 데이터베이스에 있는 식별자와 매칭되지 않을 경우, 서버는 데이터베이스로부터, "no match" 지시자를 전달받을 수 있다. 서버가 "no match" 지시자를 전달받은 경우, 서버는 네트워크 인터페이스(39030)에 널 응답을 리턴할 수 있다.
본 발명의 일 실시예는, 서버 에, 어떠한 추가적인 지능을 요구하지 않을 수 있다. 서버는 단순히 네트워크 인터페이스(39030)에 데이터베이스에서 찾은 정보를 전달할 뿐일 수 있다. 본 발명의 동작에 대한 모든 지능은 ACR 인제스트 모듈에서 담당할 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명의 방송 프로그램과 관련한 양방향 서비스를 처리하는 방법을 네트워크 디바이스에 구비된, 프로세서가 읽을 수 있는 기록매체에, 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
발명의 실시를 위한 형태는 전술한 바와 같이, 발명의 실시를 위한 최선의 형태로 상술되었다.본 발명은 방송 서비스 제공과 관련한 일련의 산업분야에서 이용 가능하다.

Claims (18)

  1. 수신기가 양방향 서비스를 처리하는 방법에 있어서,
    외부 디코딩부로부터 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하는 단계;
    상기 수신된 콘텐츠로부터 주기적으로 프레임들의 식별자들을 추출하는 단계;
    현재 시청되고 있는 비압축된 콘텐츠를 식별하기 위하여 상기 식별자들을 포함하는 요청을 서버로 보내는 단계로서, 상기 식별자들에 의해 대표되는 상기 프레임들은 상기 서버에 의하여 프레임들의 식별자들의 데이터 베이스와 상기 식별자들을 매칭하여 식별되고; 및
    상기 요청을 바탕으로 상기 서버로부터 상기 콘텐츠에 대한 네트워크 인터페이스 트리거를 수신하는 단계로서, 상기 네트워크 인터페이스 트리거의 타입들은 상기 식별자들에 의해 대표되는 상기 프레임들을 기반으로 상기 서버에 의해 결정되고;
    상기 콘텐츠와 연관된 부가 정보를 디스플레이 하는 단계;
    리모콘 수신기를 통해 상기 부가 정보와 관련된 신호를 수신하는 단계; 및
    상기 리모콘 수신기 및 UI (User Interface) 모듈로부터 브라우저 키 코드를 수신하는 단계로서, 상기 트리거는 상기 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블 내의 특정 양방향 이벤트를 참조하거나 상기 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알리고,
    상기 어플리케이션 파라미터 테이블은 어플리케이션들에 대한 정보를 포함하는 적어도 하나 이상의 어플리케이션 엘리먼트를 포함하고,
    각 어플리케이션 엘리먼트는 각 어플리케이션을 식별하는 제 1 식별자를 포함하고, 상기 각 어플리케이션 엘리먼트는 상기 이벤트에 대한 정보를 포함하는 적어도 하나 이상의 이벤트 엘리먼트를 포함하고,
    각 이벤트 엘리먼트는 상기 이벤트를 식별하는 제 2 식별자를 포함하고, 상기 각 이벤트 엘리먼트는 해당 이벤트에 사용될 데이터에 대한 정보를 포함하는 적어도 하나 이상의 데이터 엘리먼트를 포함하고,
    각 데이터 엘리먼트는 각 데이터를 식별하는 제 3 식별자를 포함하고,
    복수개의 이벤트들 중 하나의 이벤트에 대해 활성화가 발생할 예정인 경우, 상기 트리거는 활성화 트리거이고, 상기 활성화 트리거는 상기 활성화될 이벤트에 대한 활성화 시간을 설정하고,
    상기 활성화 시간은 상기 활성화 트리거 내의 타이밍 값 항에 의해 지시되고, 세그먼트의 시간 값에 대하여 상대적이고,
    상기 활성화 트리거는 어플리케이션 텀 (application term), 이벤트 텀 (event term), 데이터 텀 (data term)을 포함하고,
    활성화될 어플리케이션을 식별하기 위하여 상기 어플리케이션 텀은 상기 제 1 식별자와 일치하고, 활성화될 이벤트를 식별하기 위하여 상기 이벤트 텀은 상기 제 2 식별자와 일치하고, 상기 활성화될 이벤트에 사용되기 위한 데이터를 식별하기 위하여 상기 데이터 텀은 상기 제 3 식별자와 일치하고,
    상기 부가 정보가 네트워크를 사용하는 서비스에 관한 것인 경우, 상기 브라우저 키 코드는 웹 브라우저로 전송되고,
    상기 부가 정보가 현재 디스플레이되고 있는 비디오에 관한 것인 경우, 상기 현재 디스플레이되고 있는 비디오에 대응하는 신호는 디스플레이 모듈로 전송되는 것을 포함하는, 양방향 서비스를 처리하는 방법.
  2. 제1항에 있어서,
    다음 요청을 보내기 전에 이벤트 활성화가 발생하도록 스케줄링되지 않은 경우 상기 트리거는 시간 베이스 트리거이고,
    상기 시간 베이스 트리거는 세그먼트의 시간을 유지하기 위해 사용되는, 양방향 서비스를 처리하는 방법.
  3. 제1항에 있어서,
    캡션 텍스트를 처리하고, 상기 처리된 캡션 데이터를 디스플레이 하기 위하여 그래픽 프로세스로 전송하는 단계를 더 포함하는 양방향 서비스를 처리하는 방법.
  4. 제1항에 있어서,
    상기 수신기가 상기 어플리케이션 파라미터 테이블과 함께 전달된 URL 정보를 이용하여 새로운 어플리케이션 파라미터 테이블을 아직 검색하지 않았으면, 상기 트리거가 상기 새로운 어플리케이션 파라미터 테이블을 식별하는 어플리케이션 파라미터 테이블 식별자를 포함하는 경우, 상기 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드하는 단계를 더 포함하는, 양방향 서비스를 처리하는 방법.
  5. 제4항에 있어서,
    상기 수신기가 상기 트리거와 연관된 새로운 어플리케이션을 가지지 않은 경우, 상기 어플리케이션 파라미터 테이블 또는 상기 새로운 어플리케이션 파라미터 테이블로부터 상기 새로운 어플리케이션에 대하여 어플리케이션 URL을 얻는 단계; 및
    상기 어플리케이션 URL을 이용하여 상기 새로운 어플리케이션을 다운로드하는 단계를 더 포함하는, 양방향 서비스를 처리하는 방법.
  6. 제1항에 있어서,
    상기 수신기는 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하면, 상기 활성화 트리거 중 하나를 적용하는, 양방향 서비스를 처리하는 방법.
  7. 제1항에 있어서,
    활성화 트리거가 상기 활성화 시간 이후에 수신되면 활성화 트리거는 도달하자마자 적용되는, 양방향 서비스를 처리하는 방법.
  8. 제1항에 있어서,
    상기 수신기에 포함된 오디오 또는 비디오 디코더로부터 콘텐츠들을 자동으로 인식하는 단계를 더 포함하는 양방향 서비스를 처리하는 방법.
  9. 제1항에 있어서,
    상기 부가 정보와 관련된 신호를 기반으로 네트워크 인터페이스를 통해 네트워크에 접근하는 단계를 더 포함하는 양방향 서비스를 처리하는 방법.
  10. 양방향 서비스를 처리하는 장치에 있어서,
    외부 디코딩부로부터 비압축된 오디오 콘텐츠 또는 비압축된 비디오 콘텐츠를 수신하도록 구성된 수신 모듈;
    상기 수신된 콘텐츠로부터 주기적으로 프레임들의 식별자들을 추출하도록 구성된 식별자 추출 모듈;
    현재 시청되고 있는 비압축된 콘텐츠를 식별하기 위하여 상기 식별자들을 포함하는 요청을 서버로 보내는 네트워크 인터페이스로서, 상기 식별자들에 의해 대표되는 상기 프레임들은 상기 서버에 의하여 프레임들의 식별자들의 데이터 베이스와 상기 식별자들을 매칭하여 식별되고;
    상기 콘텐츠와 연관된 부가 정보를 디스플레이 하는 디스플레이 모듈;
    리모콘 수신기를 통해 상기 부가 정보와 관련된 신호를 수신하는 UI (User Interface) 모듈; 및
    상기 리모콘 수신기 및 UI (User Interface) 모듈로부터 브라우저 키 코드를 수신하는 웹 브라우저 모듈로서, 상기 네트워크 인터페이스는 상기 요청을 바탕으로 상기 서버로부터 상기 콘텐츠에 대한 네트워크 인터페이스 트리거를 수신하는 단계로서, 상기 네트워크 인터페이스 트리거의 타입들은 상기 식별자들에 의해 대표되는 상기 프레임들을 기반으로 상기 서버에 의해 결정되고,
    상기 트리거는 상기 콘텐츠의 현재 시간을 지시하고, 어플리케이션 파라미터 테이블 내의 특정 양방향 이벤트를 참조하거나 상기 이벤트가 지금 또는 지정된 미래 시간에 실행됨을 알리고,
    상기 어플리케이션 파라미터 테이블은 어플리케이션들에 대한 정보를 포함하는 적어도 하나 이상의 어플리케이션 엘리먼트를 포함하고,
    각 어플리케이션 엘리먼트는 각 어플리케이션을 식별하는 제 1 식별자를 포함하고, 상기 각 어플리케이션 엘리먼트는 상기 이벤트에 대한 정보를 포함하는 적어도 하나 이상의 이벤트 엘리먼트를 포함하고,
    각 이벤트 엘리먼트는 상기 이벤트를 식별하는 제 2 식별자를 포함하고, 상기 각 이벤트 엘리먼트는 해당 이벤트에 사용될 데이터에 대한 정보를 포함하는 적어도 하나 이상의 데이터 엘리먼트를 포함하고,
    각 데이터 엘리먼트는 각 데이터를 식별하는 제 3 식별자를 포함하고,
    복수개의 이벤트들 중 하나의 이벤트에 대해 활성화가 발생할 예정인 경우, 상기 트리거는 활성화 트리거이고, 상기 활성화 트리거는 상기 활성화될 이벤트에 대한 활성화 시간을 설정하고,
    상기 활성화 시간은 상기 활성화 트리거 내의 타이밍 값 항에 의해 지시되고, 세그먼트의 시간 값에 대하여 상대적이고,
    상기 활성화 트리거는 어플리케이션 텀 (application term), 이벤트 텀 (event term), 데이터 텀 (data term)을 포함하고,
    활성화될 어플리케이션을 식별하기 위하여 상기 어플리케이션 텀은 상기 제 1 식별자와 일치하고, 활성화될 이벤트를 식별하기 위하여 상기 이벤트 텀은 상기 제 2 식별자와 일치하고, 상기 활성화될 이벤트에 사용되기 위한 데이터를 식별하기 위하여 상기 데이터 텀은 상기 제 3 식별자와 일치하고,
    상기 부가 정보가 네트워크를 사용하는 서비스에 관한 것인 경우, 상기 브라우저 키 코드는 웹 브라우저로 전송되고,
    상기 부가 정보가 현재 디스플레이되고 있는 비디오에 관한 것인 경우, 상기 현재 디스플레이되고 있는 비디오에 대응하는 신호는 디스플레이 모듈로 전송되는 것을 포함하는, 양방향 서비스를 처리하는 장치.
  11. 제10항에 있어서,
    다음 요청을 보내기 전에 이벤트 활성화가 발생하도록 스케줄링되지 않은 경우 상기 트리거는 시간 베이스 트리거이고,
    상기 시간 베이스 트리거는 세그먼트의 시간을 유지하기 위해 사용되는, 양방향 서비스를 처리하는 장치.
  12. 제10항에 있어서,
    캡션 텍스트를 처리하고, 상기 처리된 캡션 데이터를 디스플레이 하기 위하여 그래픽 프로세스로 전송하는 캡션 모듈을 더 포함하는 양방향 서비스를 처리하는 장치.
  13. 제10항에 있어서,
    상기 네트워크 인터페이스는, 상기 장치가 상기 어플리케이션 파라미터 테이블과 함께 전달된 URL 정보를 이용하여 새로운 어플리케이션 파라미터 테이블을 아직 검색하지 않았으면, 상기 트리거가 상기 새로운 어플리케이션 파라미터 테이블을 식별하는 어플리케이션 파라미터 테이블 식별자를 포함하는 경우, 상기 새로운 어플리케이션 파라미터 테이블을 즉시 다운로드하도록 더 구성되는, 양방향 서비스를 처리하는 장치.
  14. 제13항에 있어서,
    상기 장치가 상기 트리거와 연관된 새로운 어플리케이션을 가지지 않은 경우, 상기 어플리케이션 파라미터 테이블 또는 상기 새로운 어플리케이션 파라미터 테이블로부터 상기 새로운 어플리케이션에 대하여 어플리케이션 URL을 얻도록 구성된 트리거 모듈을 더 포함하고,
    상기 네트워크 인터페이스 상기 어플리케이션 URL을 이용하여 상기 새로운 어플리케이션을 다운로드하도록 더 구성되는, 양방향 서비스를 처리하는 장치.
  15. 제10항에 있어서,
    상기 장치는 동일한 이벤트 활성화에 대해 하나 이상의 활성화 트리거를 수신하면, 상기 활성화 트리거 중 하나를 적용하는, 양방향 서비스를 처리하는 장치.
  16. 제10항에 있어서,
    활성화 트리거가 상기 활성화 시간 이후에 수신되면 활성화 트리거는 도달하자마자 적용되는, 양방향 서비스를 처리하는 장치.
  17. 제10항에 있어서,
    상기 수신기에 포함된 오디오 또는 비디오 디코더로부터 콘텐츠들을 자동으로 인식하는 자동 콘텐츠 인식 모듈을 포함하는 양방향 서비스를 처리하는 장치.
  18. 제10항에 있어서,
    상기 웹 브라우저는 상기 부가 정보와 관련된 신호를 기반으로 네트워크 인터페이스를 통해 네트워크에 접근하는 양방향 서비스를 처리하는 장치.
KR1020147034794A 2012-08-22 2013-08-21 양방향 서비스를 처리하는 장치 및 방법 KR102068567B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261691805P 2012-08-22 2012-08-22
US61/691,805 2012-08-22
US201261703749P 2012-09-20 2012-09-20
US61/703,749 2012-09-20
PCT/KR2013/007496 WO2014030924A1 (en) 2012-08-22 2013-08-21 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
KR20150048669A KR20150048669A (ko) 2015-05-07
KR102068567B1 true KR102068567B1 (ko) 2020-02-11

Family

ID=50148997

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147034794A KR102068567B1 (ko) 2012-08-22 2013-08-21 양방향 서비스를 처리하는 장치 및 방법

Country Status (8)

Country Link
US (3) US9071663B2 (ko)
EP (1) EP2839671B1 (ko)
JP (1) JP6045692B2 (ko)
KR (1) KR102068567B1 (ko)
CN (1) CN104584574B (ko)
CA (1) CA2875467C (ko)
MX (1) MX342972B (ko)
WO (1) WO2014030924A1 (ko)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2839444C (en) * 2011-06-16 2016-05-31 Lg Electronics Inc. Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
US9769503B2 (en) * 2012-11-14 2017-09-19 Saturn Licensing Llc Information processor, information processing method and program
US9986307B2 (en) * 2013-07-19 2018-05-29 Bottle Rocket LLC Interactive video viewing
US10504200B2 (en) 2014-03-13 2019-12-10 Verance Corporation Metadata acquisition using embedded watermarks
KR101731770B1 (ko) * 2014-03-13 2017-04-28 베란스 코오포레이션 임베디드 코드를 사용한 양방향 콘텐츠 획득
WO2015168697A1 (en) * 2014-05-02 2015-11-05 Verance Corporation Metadata acquisition using embedded codes
KR102481425B1 (ko) * 2014-05-30 2022-12-27 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법
US10372511B2 (en) * 2014-07-18 2019-08-06 Verizon Patent And Licensing Inc. Method and apparatus for providing an application control trigger
WO2016028936A1 (en) 2014-08-20 2016-02-25 Verance Corporation Watermark detection using a multiplicity of predicted patterns
JPWO2016035589A1 (ja) * 2014-09-05 2017-06-15 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US9942602B2 (en) 2014-11-25 2018-04-10 Verance Corporation Watermark detection and metadata delivery associated with a primary content
US9769543B2 (en) * 2014-11-25 2017-09-19 Verance Corporation Enhanced metadata and content delivery using watermarks
US9602891B2 (en) 2014-12-18 2017-03-21 Verance Corporation Service signaling recovery for multimedia content using embedded watermarks
WO2016208161A1 (en) * 2015-06-21 2016-12-29 Sharp Kabushiki Kaisha Extensible Watermark Associated Information Retrieval
US9813781B2 (en) * 2015-10-27 2017-11-07 Sorenson Media, Inc. Media content matching and indexing
US10506058B2 (en) * 2016-03-18 2019-12-10 Qualcomm Incorporated Signaling of application content packaging and delivery
US10419511B1 (en) * 2016-10-04 2019-09-17 Zoom Video Communications, Inc. Unique watermark generation and detection during a conference
TWI640195B (zh) * 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US9918135B1 (en) * 2017-02-07 2018-03-13 The Directv Group, Inc. Single button selection to facilitate actions in a communications network
CN112612580A (zh) * 2020-11-25 2021-04-06 北京思特奇信息技术股份有限公司 一种组合事件触发方法及触发系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020056129A1 (en) * 1999-10-05 2002-05-09 Dean J. Blackketter Trigger having a time attribute
WO2012091322A1 (ko) * 2010-12-26 2012-07-05 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020162118A1 (en) * 2001-01-30 2002-10-31 Levy Kenneth L. Efficient interactive TV
US20030192060A1 (en) * 2001-01-30 2003-10-09 Levy Kenneth L. Digital watermarking and television services
US8407752B2 (en) * 2004-03-18 2013-03-26 Digimarc Corporation Synchronizing broadcast content with corresponding network content
TW200733733A (en) * 2005-09-06 2007-09-01 Nokia Corp Enhanced signaling of pre-configured interaction message in service guide
US20070074079A1 (en) * 2005-09-27 2007-03-29 Forster Darren P System and method for providing trigger information in a video signal and playing out a triggered event
US20070162399A1 (en) 2005-12-22 2007-07-12 Alexander Medvinsky Method and apparatus for providing broadcast trigger messages
US8893210B2 (en) 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
JP5765558B2 (ja) * 2010-08-27 2015-08-19 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、プログラム、および放送システム
EP2645731B8 (en) * 2010-11-24 2019-04-17 LG Electronics Inc. Video display device and method of controlling the same
US9554175B2 (en) 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020056129A1 (en) * 1999-10-05 2002-05-09 Dean J. Blackketter Trigger having a time attribute
WO2012091322A1 (ko) * 2010-12-26 2012-07-05 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치

Also Published As

Publication number Publication date
EP2839671A1 (en) 2015-02-25
CA2875467C (en) 2017-03-14
MX2014014754A (es) 2015-02-24
EP2839671A4 (en) 2015-12-02
US20150264410A1 (en) 2015-09-17
WO2014030924A1 (en) 2014-02-27
JP6045692B2 (ja) 2016-12-14
MX342972B (es) 2016-10-20
JP2015527807A (ja) 2015-09-17
US9596494B2 (en) 2017-03-14
US20150172785A1 (en) 2015-06-18
CA2875467A1 (en) 2014-02-27
US20140059116A1 (en) 2014-02-27
CN104584574B (zh) 2018-06-22
EP2839671B1 (en) 2018-10-10
CN104584574A (zh) 2015-04-29
US9912971B2 (en) 2018-03-06
KR20150048669A (ko) 2015-05-07
US9071663B2 (en) 2015-06-30

Similar Documents

Publication Publication Date Title
KR102068567B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR102024599B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR101939296B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR102040623B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
CA2887659C (en) Apparatus and method for processing an interactive service

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant