KR101838078B1 - 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법 - Google Patents

방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법 Download PDF

Info

Publication number
KR101838078B1
KR101838078B1 KR1020167014572A KR20167014572A KR101838078B1 KR 101838078 B1 KR101838078 B1 KR 101838078B1 KR 1020167014572 A KR1020167014572 A KR 1020167014572A KR 20167014572 A KR20167014572 A KR 20167014572A KR 101838078 B1 KR101838078 B1 KR 101838078B1
Authority
KR
South Korea
Prior art keywords
pdi
companion device
service
data
pdi table
Prior art date
Application number
KR1020167014572A
Other languages
English (en)
Other versions
KR20160077197A (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 KR20160077197A publication Critical patent/KR20160077197A/ko
Application granted granted Critical
Publication of KR101838078B1 publication Critical patent/KR101838078B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4668—Learning process for intelligent management, e.g. learning user preferences for recommending movies for recommending content, e.g. movies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/29—Arrangements for monitoring broadcast services or broadcast-related services
    • H04H60/33—Arrangements for monitoring the users' behaviour or opinions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/78—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by source locations or destination locations
    • H04H60/80—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by source locations or destination locations characterised by transmission among terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H04N21/41265—The peripheral being portable, e.g. PDAs or mobile phones having a remote control device for bidirectional communication between the remote control device and client device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/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/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/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • 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/454—Content or additional data filtering, e.g. blocking advertisements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4751—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for defining user accounts, e.g. accounts for children
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4755—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for defining user preferences, e.g. favourite actors or genre
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4758—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for providing answers, e.g. voting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/46—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for recognising users' preferences

Abstract

본 발명은 방송 신호를 송신하는 방법을 제공한다. 방법은 컴패니언 디바이스와 페어링하는 단계; 방송 신호를 통해 PDI(Profiles, Demographics, Interests) 테이블을 수신하는 단계 - 상기 PDI 테이블은 인터랙티브 컨텐츠에 대한 개인 관심에 관련된 복수의 PDI 질문을 포함하고 상기 PDI 테이블은 상기 PDI 테이블을 식별하는 ID를 포함함 -; 상기 PDI 질문 중의 적어도 하나에 대한 답변을 얻는 단계; 및 상기 얻은 답변을 갖는 PDI 테이블을 상기 페어링된 컴패니언 디바이스로 전달하는 단계를 포함한다.

Description

방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법{APPARATUS FOR TRANSMITTING BROADCAST SIGNALS, APPARATUS FOR RECEIVING BROADCAST SIGNALS, METHOD FOR TRANSMITTING BROADCAST SIGNALS AND METHOD FOR RECEIVING BROADCAST SIGNALS}
본 발명은 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호를 송수신하는 방법에 관한 것이다.
아날로그 방송 신호 송신이 끝남에 따라, 디지털 방송 신호를 송수신하는 다양한 기술이 개발되고 있다. 디지털 방송 신호는 아날로그 방송 신호보다 더 많은 양의 비디오/오디오 데이터를 포함할 수 있고, 비디오/오디오 데이터에 더하여 다양한 타입의 추가 데이터를 더 포함할 수 있다.
즉, 디지털 방송 시스템은 고화질(HD; high definition) 영상, 멀티 채널 오디오 및 다양한 추가 서비스를 제공할 수 있다. 그러나, 디지털 방송을 위해, 많은 양의 데이터의 송신을 위한 데이터 송신 효율, 송수신 네트워크의 강건함(robustness) 및 모바일 수신 장비를 고려한 네트워크 유연성이 개선될 필요가 있다.
본 발명의 목적은 방송 신호를 송신하여 시간 도메인에서 2개 이상의 상이한 방송 서비스를 제공하는 방송 송수신 시스템의 데이터를 멀티플렉싱하고 동일한 RF 신호 대역폭을 통해 멀티플렉싱된 데이터를 송신하는 장치 및 방법 및 그에 대응하는 방송 신호를 수신하는 장치 및 방법을 제공하는 것이다.
본 발명의 다른 목적은 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치 및 방송 신호를 송수신하여 컴포넌트에 의해 서비스에 대응하는 데이터를 분류하고 각 컴포넌트에 대응하는 데이터를 데이터 파이프로서 송신하고 데이터를 수신 및 처리하는 방법을 제공하는 것이다.
본 발명의 다른 목적은 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치 및 방송 신호를 송수신하여 방송 신호를 제공하는데 필요한 시그널링 정보를 시그널링하는 방법을 제공하는 것이다.
본 발명의 목적 및 다른 이점을 달성하기 위하여, 본 발명은 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법을 제공한다. 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법은 컴패니언 디바이스와 페어링하는 단계; 방송 신호를 통해 PDI(Profiles, Demographics, Interests) 테이블을 수신하는 단계 - 상기 PDI 테이블은 인터랙티브 컨텐츠에 대한 개인 관심에 관련된 복수의 PDI 질문을 포함하고 상기 PDI 테이블은 상기 PDI 테이블을 식별하는 ID를 포함함 -; 상기 PDI 질문 중의 적어도 하나에 대한 답변을 얻는 단계; 및 상기 얻은 답변을 갖는 PDI 테이블을 상기 페어링된 컴패니언 디바이스로 전달하는 단계를 포함한다.
바람직하게, 상기 PDI 테이블을 전달하는 단계는, 상기 컴패니언 디바이스로부터 PDI 테이블의 ID의 리스트에 대한 제1 요청을 수신하는 단계; 상기 요청된 PDI 테이블의 ID의 리스트를 상기 컴패니언 디바이스로 전달하는 단계; 상기 컴패니언 디바이스로부터 ID의 리스트 내의 소정 ID를 갖는 PDI 테이블에 대한 제2 요청을 수신하는 단계; 및 상기 요청된 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 단계를 포함한다.
바람직하게, 상기 PDI 테이블을 전달하는 것은 UserData 서비스를 이용하여 수행되고, 상기 UserData 서비스는 상기 PDI 테이블을 전달하는 UPnP 서비스이고, 상기 제1 요청은 상기 UserData 서비스의 제1 UPnP 액션에 기초하고, 상기 제1 UPnP 액션은 PDI 테이블의 ID의 리스트를 얻기 위한 것이고, 상기 제1 UPnP 액션은 입력 인수로서 상기 UserData 서비스의 프로토콜 버전 정보 및 출력 인수로서 상기 PDI 테이블의 ID의 리스트를 가지며, 상기 제2 요청은 상기 UserData 서비스의 제2 UPnP 액션에 기초하고, 상기 제2 UPnP 액션은 ID의 리스트 내의 소정의 ID를 갖는 PDI 테이블을 얻기 위한 것이고, 상기 제2 UPnP 액션은 입력 인수로서 상기 PDI 테이블의 ID의 리스트 및 출력 인수로서 상기 PDI 테이블을 갖는다.
바람직하게, 상기 방법은 상기 컴패니언 디바이스로부터 상기 UserData 서비스에 대한 가입을 수신하는 단계를 더 포함하고, 상기 UserData 서비스는 상기 PDI 테이블을 전달하는 UPnP 서비스이고,
상기 PDI 테이블을 전달하는 단계는, 상기 PDI 테이블 내의 답변이 업데이트되거나 새로운 PDI 테이블이 수신될 때 상기 컴패니언 장치로 알림을 전송하는 단계; 및 상기 업데이트된 답변을 갖는 PDI 테이블 또는 새로운 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 단계를 더 포함한다.
바람직하게, 상기 방법은 인터랙티브 컨텐츠 및 상기 인터랙티브 컨텐츠와 연관된 필터링 기준을 수신하는 단계 - 상기 필터링 기준은 상기 연관된 인터랙티브 컨텐츠의 성질에 관한 정보를 포함함 -; 상기 필터링 기준을 상기 컴패니언 디바이스로 전달하는 단계 - 상기 필터링 기준은 상기 컴패니언 디바이스 내의 PDI 테이블과 비교됨 -; 및 상기 필터링 기준이 상기 PDI 테이블 내의 답변과 매칭되면 상기 인터랙티브 컨텐츠를 전달하는 단계를 더 포함한다.
바람직하게, 상기 필터링 기준을 전달하는 단계는, 상기 컴패니언 디바이스에 대한 인터랙티브 컨텐츠가 수신되었다는 것을 상기 컴패니언 디바이스에 알리는 단계; 상기 컴패니언 디바이스로부터 상기 인터랙티브 컨텐츠와 연관된 필터링 기준에 대한 제3 요청을 수신하는 단계; 및 상기 필터링 기준을 상기 컴패니언 디바이스로 전달하는 단계를 더 포함한다.
바람직하게, 상기 필터링 기준을 전달하는 것은 FilteringCriteria 서비스를 이용하여 수행되고, 상기 FilteringCriteria 서비스는 상기 필터링 기준을 전달하는 UPnP 서비스이고,상기 제3 요청은 상기 FilteringCriteria 서비스의 제3 UPnP 액션에 기초하고, 상기 제3 UPnP 액션은 상기 필터링 기준을 얻기 위한 것이고, 상기 UPnP 액션은 출력 인수로서 상기 필터링 기준을 갖는다.
바람직하게, 방법은 상기 수신된 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 단계 - 상기 적어도 하나의 PDI 질문에 대한 답변이 상기 전달된 PDI 테이블에 저장됨 -; 및 상기 컴패니언 디바이스로부터 상기 답변을 갖는 PDI 테이블을 수신하는 단계를 더 포함한다.
바람직하게, 방법은 상기 컴패니언 디바이스로부터의 PDI 테이블 내의 답변으로 대체함으로서 상기 저장된 답변을 업데이트하는 단계를 더 포함한다.
바람직하게, 상기 PDI 테이블 내의 PDI 질문의 각각은 질문 ID를 포함하고, 상기 PDI 테이블을 전달하는 단계는, 상기 컴패니언 디바이스로부터 PDI 질문의 질문 ID의 리스트에 대한 제4 요청을 수신하는 단계; 상기 요청된 PDI 질문의 질문 ID의 리스트를 상기 컴패니언 디바이스로 전달하는 단계; 상기 컴패니언 디바이스로부터 질문 ID의 리스트 내의 소정의 질문 ID를 갖는 PDI 질문에 대한 제5 요청을 수신하는 단계; 및 상기 요청된 PDI 질문 및 상기 요청된 PDI 질문에 대한 답변을 상기 컴패니언 디바이스로 전달하는 단계를 더 포함한다.
다른 형태에 있어서, 본 발명은 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 장치를 제공한다. 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 장치는 컴패니언 디바이스와 페어링하는 페어링 모듈; 방송 신호를 통해 PDI(Profiles, Demographics, Interests) 테이블을 수신하는 수신 모듈 - 상기 PDI 테이블은 인터랙티브 컨텐츠에 대한 개인 관심에 관련된 복수의 PDI 질문을 포함하고 상기 PDI 테이블은 상기 PDI 테이블을 식별하는 ID를 포함함 -; 상기 PDI 질문 중의 적어도 하나에 대한 답변을 얻는 답변 획득 모듈; 상기 PDI 테이블에 상기 얻은 답변을 저장하는 PDI 저장 모듈; 및 상기 얻은 답변을 갖는 PDI 테이블을 상기 페어링된 컴패니언 디바이스로 전달하는 컴패니언 디바이스 모듈을 포함한다.
바람직하게, 상기 컴패니언 디바이스 모듈은 또한 상기 컴패니언 디바이스로부터 PDI 테이블의 ID의 리스트에 대한 제1 요청을 수신하고; 상기 요청된 PDI 테이블의 ID의 리스트를 상기 컴패니언 디바이스로 전달하고; 상기 컴패니언 디바이스로부터 ID의 리스트 내의 소정 ID를 갖는 PDI 테이블에 대한 제2 요청을 수신하고; 상기 요청된 PDI 테이블을 상기 컴패니언 디바이스로 전달한다.
바람직하게, 상기 PDI 테이블을 전달하는 것은 UserData 서비스를 이용하여 수행되고, 상기 UserData 서비스는 상기 PDI 테이블을 전달하는 UPnP 서비스이고, 상기 제1 요청은 상기 UserData 서비스의 제1 UPnP 액션에 기초하고, 상기 제1 UPnP 액션은 PDI 테이블의 ID의 리스트를 얻기 위한 것이고, 상기 제1 UPnP 액션은 입력 인수로서 상기 UserData 서비스의 프로토콜 버전 정보 및 출력 인수로서 상기 PDI 테이블의 ID의 리스트를 가지며, 상기 제2 요청은 상기 UserData 서비스의 제2 UPnP 액션에 기초하고, 상기 제2 UPnP 액션은 ID의 리스트 내의 소정의 ID를 갖는 PDI 테이블을 얻기 위한 것이고, 상기 제2 UPnP 액션은 입력 인수로서 상기 PDI 테이블의 ID의 리스트 및 출력 인수로서 상기 PDI 테이블을 갖는다.
바람직하게, 상기 컴패니언 디바이스 모듈은 또한 상기 컴패니언 디바이스로부터 상기 UserData 서비스에 대한 가입을 수신하고 - 상기 UserData 서비스는 상기 PDI 테이블을 전달하는 UPnP 서비스임 -; 상기 PDI 테이블 내의 답변이 업데이트되거나 새로운 PDI 테이블이 수신될 때 상기 컴패니언 장치로 알림을 전송하고; 상기 업데이트된 답변을 갖는 PDI 테이블 또는 새로운 PDI 테이블을 상기 컴패니언 디바이스로 전달한다.
바람직하게, 상기 수신 모듈은 또한 인터랙티브 컨텐츠 및 상기 인터랙티브 컨텐츠와 연관된 필터링 기준을 수신하고, 상기 필터링 기준은 상기 연관된 인터랙티브 컨텐츠의 성질에 관한 정보를 포함하고, 상기 컴패니언 디바이스 모듈은 또한 상기 필터링 기준을 상기 컴패니언 디바이스로 전달하고 - 상기 필터링 기준은 상기 컴패니언 디바이스 내의 PDI 테이블과 비교됨 -; 상기 필터링 기준이 상기 PDI 테이블 내의 답변과 매칭되면 상기 인터랙티브 컨텐츠를 전달한다.
바람직하게, 상기 필터링 기준을 전달하는 것은 상기 컴패니언 디바이스에 대한 인터랙티브 컨텐츠가 수신되었다는 것을 상기 컴패니언 디바이스에 알리는 것; 상기 컴패니언 디바이스로부터 상기 인터랙티브 컨텐츠와 연관된 필터링 기준에 대한 제3 요청을 수신하는 것; 및 상기 필터링 기준을 상기 컴패니언 디바이스로 전달하는 것을 더 포함한다.
바람직하게, 상기 필터링 기준을 전달하는 것은 FilteringCriteria 서비스를 이용하여 수행되고, 상기 FilteringCriteria 서비스는 상기 필터링 기준을 전달하는 UPnP 서비스이고, 상기 제3 요청은 상기 FilteringCriteria 서비스의 제3 UPnP 액션에 기초하고, 상기 제3 UPnP 액션은 상기 필터링 기준을 얻기 위한 것이고, 상기 UPnP 액션은 출력 인수로서 상기 필터링 기준을 갖는다.
바람직하게, 상기 컴패니언 디바이스 모듈은 또한 상기 수신된 PDI 테이블을 상기 컴패니언 디바이스로 전달하고 - 상기 적어도 하나의 PDI 질문에 대한 답변이 상기 전달된 PDI 테이블에 저장됨 -; 상기 컴패니언 디바이스로부터 상기 답변을 갖는 PDI 테이블을 수신한다.
바람직하게, 상기 답변 획득 모듈은 또한 상기 컴패니언 디바이스로부터의 PDI 테이블 내의 답변으로 대체함으로서 상기 저장된 답변을 업데이트한다.
바람직하게, 상기 PDI 테이블 내의 PDI 질문의 각각은 질문 ID를 포함하고, 상기 컴패니언 디바이스 모듈은 또한 상기 컴패니언 디바이스로부터 PDI 질문의 질문 ID의 리스트에 대한 제4 요청을 수신하고; 상기 요청된 PDI 질문의 질문 ID의 리스트를 상기 컴패니언 디바이스로 전달하고; 상기 컴패니언 디바이스로부터 질문 ID의 리스트 내의 소정의 질문 ID를 갖는 PDI 질문에 대한 제5 요청을 수신하고; 상기 요청된 PDI 질문 및 상기 요청된 PDI 질문에 대한 답변을 상기 컴패니언 디바이스로 전달한다.
본 발명은 각 서비스 또는 서비스 컴포넌트에 대한 QoS(Quality of Services)를 제어하는 서비스 특성에 따라 데이터를 처리하여 다양한 방송 서비스를 제공할 수 있다.
본 발명은 동일한 RF 신호 대역폭을 통해 다양한 방송 서비스를 송신함으로써 송신 유연성을 달성할 수 있다.
본 발명은 데이터 송신 효율을 개선하고 MIMO 시스템을 이용하여 방송 신호의 송수신의 강건함을 증가시킬 수 있다.
본 발명에 따르면, 모바일 수신 장비로 또는 실내 환경에서도 에러없이 디지털 방송 신호를 수신할 수 있는 방송 신호 송신 및 수신 방법 및 장치를 제공할 수 있다.
본 발명의 추가의 이해를 제공하기 위하여 포함되고 본 출원의 일부에 포함되거나 그 일부를 구성하는 첨부된 도면은 본 발명의 실시예(들)을 나타내고 설명과 함께 본 발명의 원리를 설명한다.
도 1은 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 송신하는 장치의 구조를 나타내는 도면.
도 2는 본 발명의 일 실시예에 따른 입력 포맷팅 블록을 나타내는 도면.
도 3은 본 발명의 다른 실시예에 따른 입력 포맷팅 블록을 나타내는 도면.
도 4는 본 발명의 다른 실시예에 따른 입력 포맷팅 블록을 나타내는 도면.
도 5는 본 발명의 실시예에 따른 BICM 블록을 나타내는 도면.
도 6은 본 발명의 다른 실시예에 따른 BICM 블록을 나타내는 도면.
도 7은 본 발명의 일 실시예에 따른 프레임 빌딩 블록을 나타내는 도면.
도 8은 본 발명의 실시예에 따른 OFMD 생성 블록을 나타내는 도면.
도 9는 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 수신하는 장치의 구조를 나타내는 도면.
도 10은 본 발명의 실시예에 따른 프레임 구조를 나타내는 도면.
도 11은 본 발명의 실시예에 따른 프레임의 시그널링 계층 구조를 나타내는 도면.
도 12는 본 발명의 실시예에 따른 프리엠블 시그널링 데이터를 나타내는 도면.
도 13은 본 발명의 실시예에 따른 PLS1 데이터를 나타내는 도면.
도 14는 본 발명의 실시예에 따른 PLS2 데이터를 나타내는 도면.
도 15는 본 발명의 다른 실시예에 따른 PLS2 데이터를 나타내는 도면.
도 16은 본 발명의 실시예에 따른 프레임의 논리 구조를 나타내는 도면.
도 17은 본 발명의 실시예에 따른 PLS 맵핑을 나타내는 도면.
도 18은 본 발명의 실시예에 따른 EAC 맵핑을 나타내는 도면.
도 19는 본 발명의 실시예에 따른 FIC 맵핑을 나타내는 도면.
도 20은 본 발명의 실시예에 따른 DP의 타입을 나타내는 도면.
도 21은 본 발명의 실시예에 따른 DP 맵핑을 나타내는 도면.
도 22는 본 발명의 실시예에 따른 FEC 구조를 나타내는 도면.
도 23은 본 발명의 실시예에 따른 비트 인터리빙을 나타내는 도면.
도 24는 본 발명의 실시예에 따른 셀-워드 디멀티플렉싱을 나타내는 도면.
도 25는 본 발명의 실시예에 따른 시간 인터리빙을 나타내는 도면.
도 26는 본 발명의 실시예에 따른 트위스트 행-열 블록 인터리버의 기본 동작을 나타내는 도면.
도 27은 본 발명의 다른 실시예에 따른 트위스트 행-열 블록 인터리버의 동작을 나타내는 도면.
도 28은 본 발명의 실시예에 따른 트위스트 행-열 블록 인터리버의 대각선 방향 판독 패턴을 나타내는 도면.
도 29은 본 발명의 실시예에 따른 각 인터리빙 어레이로부터의 인터리빙된 XFECBLOCK을 나타내는 도면.
도 30은 자동 콘텐츠 인식 기반 ETV(enhanced television) 서비스 시스템을 나타낸 도면이다.
도 31는 본 발명의 일 실시예에 따른 디지털 워터마킹 기술의 흐름을 나타낸 도면이다.
도 32은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과 포맷을 나타낸 도면이다.
도 33는 본 발명의 일 실시예에 따른 콘텐츠 식별자의 구문(syntax)을 나타낸 도면이다.
도 34는 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
도 35은 본 발명의 또 다른 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
도 36은 본 발명의 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
도 37은 본 발명의 다른 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
도 38는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 39은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 40은 본 발명의 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 41는 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 42은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 43는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 44는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 45은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 46은 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 47은 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 48는 본 발명의 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 49은 본 발명의 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 50은 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 51는 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 52은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 53는 본 발명의 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 54는 본 발명의 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 55은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 56은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 57은 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 58는 본 발명의 다른 일 실시예에 따른 FDT 경우의 XML 스키마를 나타낸 도면이다.
도 59은 본 발명의 일 실시예에 따른 캐퍼빌리티 기술어 구문을 나타낸 도면이다.
도 60은 본 발명의 일 실시예에 따른 소비 모델을 나타낸 도면이다.
도 61는 본 발명의 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
도 62은 본 발명의 다른 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
도 63는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 64는 본 발명의 일 실시예에 따른 HTTP 요청 테이블을 나타낸 도면이다.
도 65은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트이다.
도 66은 본 발명의 일 실시예에 따른 URL 리스트 테이블을 나타낸 도면이다.
도 67은 본 발명의 일 실시예에 따른 TPT를 나타낸 도면이다.
도 68는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 69은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 70은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 71는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 72은 본 발명의 일 실시예에 따른 수신기 대상 기준 테이블을 나타낸 도면이다.
도 73는 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 74는 본 발명의 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 75은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 76은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 77은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 78는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 79은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 80은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 81는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 82는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 83는 본 발명의 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 84는 본 발명의 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 85은 본 발명의 또 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 86은 본 발명의 실시예에 따른 차세대 방송 시스템용 프로토콜 스택을 나타내는 도면이다.
도 87은 본 발명의 실시예에 따른 UPnP 타입 액션 메커니즘을 나타내는 도면이다.
도 88은 본 발명의 실시예에 따른 REST 메커니즘을 나타내는 도면이다.
도 89는 본 발명의 실시예에 따른 수신기 및 컴패니언 장치 간의 유저 데이터의 교환을 나타내는 구조도이다.
도 90은 본 발명의 실시예에 따른 PDI 유저 데이터의 일부를 나타내는 도면이다.
도 91은 본 발명의 실시예에 따른 PDI 유저 데이터의 다른 부분을 나타내는 도면이다.
도 92는 본 발명의 실시예에 따른 서비스의 서비스 타입 및 서비스 ID를 나타내는 도면이다.
도 93은 본 발명의 실시예에 따른 UserData 서비스의 상태 변수를 나타내는 도면이다.
도 94 는 본 발명의 일 실시예에 따른 UserDataList 의 XML 구조를 도시한 도면이다.
도 95 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션(action)들을 도시한 도면이다.
도 96 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetPDIUserDataProtocolVersion 를 설명하는 도면이다.
도 97 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetUserDataIdsList 와 GetUserData 를 설명하는 도면이다.
도 98 은 본 발명의 일 실시예에 따른 UserData 서비스의 확장된 상태변수를 도시한 도면이다.
도 99 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, SetUserData 를 설명하는 도면이다.
도 100 은 본 발명의 일 실시예에 따른, UserData 서비스의 추가된 상태변수를 도시한 도면이다.
도 101 은 본 발명의 일 실시예에 따른, UserData 서비스의 또 다른 추가된 상태변수를 도시한 도면이다.
도 102 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 상태변수들을 도시한 도면이다.
도 103 은 본 발명의 일 실시예에 따른 UserDataQAList 의 XML 구조를 도시한 도면이다.
도 104 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션(action)들을 도시한 도면이다.
도 105 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션들 중, GetUserDataQAIdsList 와 GetUserDataQA 를 설명하는 도면이다.
도 106 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어 단위 전달을 위한, UserData 서비스의 액션들 중, SetUserDataQA 를 설명하는 도면이다.
도 107 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
도 108 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 상태변수를 도시한 도면이다.
도 109 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 액션을 설명한 도면이다.
도 110 은 본 발명의 일 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
도 111 은 본 발명의 다른 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
도 112 는 본 발명의 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 113 은 본 발명의 다른 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
도 114 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
도 115 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 액션을 설명한 도면이다.
도 116 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
도 117 은 본 발명의 일 실시예에 따른, FC가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
도 118 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 액션을 설명한 도면이다.
도 119 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
도 120 은 본 발명의 다른 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
도 121 은 본 발명의 일 실시예에 따른 방송 수신기를 나타낸 도면이다.
도 122 는 본 발명의 다른 실시예에 따른 방송 수신기를 나타낸 도면이다.
도 123 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 를 도시한 도면이다.
도 124 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 125 는 본 발명의 다른 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 126 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, caption_service_descriptor 의 확장된 필드들을 도시한 도면이다.
도 127 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 128 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 129 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 폰트에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 130 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 글자 크기에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 131 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 정렬에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 132 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 프린트되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 133 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 스크롤되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 134 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 이지 리더(easy reader) 모드에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 135 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 136 는 본 발명의 다른 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 137 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, AC-3_audio_stream_descriptor 의 확장된 필드들을 도시한 도면이다.
도 138 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 139 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 청각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 140 은 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 시각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 141 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
도 142 은 본 발명의 다른 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
도 143 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)에 있어서, sign_language_descriptor 를 도시한 도면이다.
도 144 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 접근성&수화 프리젠테이션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 145 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화 언어의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 146 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화의 위치의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 147 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 에 있어서, 답변의 업데이트를 위한 메뉴 화면을 도시한 도면이다.
도 148 은 본 발명의 또 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 149 는 본 발명의 일 실시예에 따른, 유저 ID 필드를 더 포함하는 PDIUserData 를 도시한 도면이다.
도 150 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 PDI Question 에 대한 답변을 얻는 시퀀스 다이어그램을 도시한 도면이다.
도 151 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 필터링 크리테리아를 적용하는 시퀀스 다이어그램을 도시한 도면이다.
도 152 는 본 발명의 일 실시예에 따른, 유저 ID 를 할당하는 방법을 도시한 도면이다.
도 153은 본 발명의 실시예에 따른 개인 관심에 기초한 인터랙티브 콘텐츠를 제공하는 방법을 나타내는 도면이다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 설명한다. 첨부된 도면을 참조하여 이하에서 설명하는 상세한 설명은 본 발명에 따라 구현될 수 있는 실시예만을 나타내기 보다는 본 발명의 예시적인 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 본 발명의 완벽한 이해를 제공하기 위하여 특정한 세부사항을 포함한다. 그러나, 본 발명은 이러한 특정한 세부사항없이 실행될 수 있음은 당업자에게 자명하다.
본 발명에서 사용되는 대부분의 용어들은 본 기술에서 널리 사용되는 것으로부터 선택되었지만, 일부 용어는 출원인에 의해 임의로 선택된 것이며, 그 의미는 필요에 따라 다음의 설명에서 상세히 설명한다. 따라서, 본 발명은 단순한 이름 또는 의미보다는 용어의 의도된 의미에 기초하여 이해되어야 한다.
본 발명은 미래의 방송 서비스를 위한 방송 신호를 송수신하는 장치 및 방법을 제공한다. 본 발명의 실시예에 따른 미래의 방송 서비스는 지상파 방송 서비스, 모바일 방송 서비스, UHDTV 서비스 등을 포함한다. 본 발명은 일 실시예에 따라 넌-MIMO(multiple input multiple output) 또는 MIMO를 통해 미래의 방송 서비스를 위한 방송 신호를 처리할 수 있다. 본 발명의 실시예에 따른 넌-MIMO 방식은 MISO(multiple input single output) 방식, SISO(single input single output) 방식 등을 포함할 수 있다.
MISO 또는 MIMO가 설명의 편의를 위해 다음에서 2개의 안테나를 사용하지만, 본 발명은 2개 이상의 안테나를 이용하는 시스템에 적용될 수 있다.
본 발명은 특정한 사용 케이스를 위해 요구되는 성능을 획득하면서 수신기 복잡도를 최소화하기에 각각 최적화된 3개의 물리층(PL) 프로파일(베이스, 핸드헬드 및 어드밴스드 프로파일)을 정의할 수 있다. 물리층(PHY) 프로파일은 해당 수신기가 구현해야 하는 모든 구성의 서브세트이다.
3개의 PHY 프로파일은 기능 블록의 대부분을 공유하지만 특정 블록 및/또는 파라미터에 있어서 약간 다르다. 추가의 PHY 프로파일이 미래에 정의될 수 있다. 시스템 진화를 위해, 미래의 프로파일은 또한 FEF(future extension frame)을 통해 단일 RF 채널 내의 기존 프로파일과 멀티플렉싱될 수 있다. 각각의 PHY 프로파일의 세부사항은 이하에서 설명한다.
1. 베이스 프로파일
베이스 프로파일은 루프톱(roof-top) 안테나에 통상 접속되는 고정 수신 장치에 대한 주요 사용 케이스를 나타낸다. 베이스 프로파일은 또한 어느 장소로 운반될 수 있지만 비교적 정지된 수신 카테고리에 속하는 포터블 장치를 포함한다. 베이스 프로파일의 사용은 임의의 개선된 구현예에 의해 핸드헬드 장치 또는 심지어 차량 장치로 확장될 수 있지만, 이들 사용 케이스는 베이스 프로파일 수신기 동작에 대해서는 기대되지 않는다.
수신의 타겟 SNR 범위는 대략 10 내지 20 dB이고, 이는 기존 방송 시스템(예를 들어, ATSC A/53)의 15dB SNR 수신 능력을 포함한다. 수신기 복잡도 및 소비 파워는 핸드헬드 프로파일을 사용하는 배터리 동작 핸드헬드 장치에서처럼 중요하지 않다. 베이스 프로파일에 대한 중요한 시스템 파라미터는 이하의 표 1에 열거된다.
LDPC 코드워드 길이 16K, 64K 비트
성상(constellation) 사이즈 4-10 bpcu (채널 용도별 비트)
시간 디인터리빙 메모리 사이즈 ≤ 219 데이터 셀
파일럿 패턴 고정 수신을 위한 파일럿 패턴
FFT 사이즈 16K, 32K 포인트
2. 핸드헬드 프로파일
핸드헬드 프로파일은 배터리 파워로 동작하는 핸드헬드 및 차량 장치에 사용되도록 설계되었다. 장치는 보행자 또는 차량 속도로 이동할 수 있다. 수신기 복잡도 뿐만 아니라 소비 파워는 핸드헬드 프로파일의 장치의 구현에 매우 중요하다. 핸드헬드 프로파일의 타겟 SNR 범위는 대략 0 내지 10dB이지만, 더 깊은 실내 수신을 대상으로 할 때 0dB 미만에 도달하도록 구성될 수 있다.
낮은 SNR 능력에 더하여, 수신기 이동도에 의해 유발된 도플러 효과에 대한 탄력성은 핸드헬드 프로파일의 가장 중요한 성능 속성이다. 핸드헬드 프로파일에 대한 중요한 파라미터는 이하의 표 2에 열거된다.
LDPC 코드워드 길이 16K 비트
성상(constellation) 사이즈 2-8 bpcu
시간 디인터리빙 메모리 사이즈 ≤ 218 데이터 셀
파일럿 패턴 모바일 및 실내 수신을 위한 파일럿 패턴
FFT 사이즈 8K, 16K 포인트
3. 어드밴스드 프로파일
어드밴스드 프로파일은 더 많은 구현 복잡도를 희생하고 가장 높은 채널 용량을 제공한다. 이 프로파일은 MIMO 송신 및 수신의 이용을 요구하고 UHDTV 서비스는 이 프로파일이 특별히 설계된 타겟 사용 케이스이다. 증가된 용량은 또한 주어진 대역폭 내에서 증가된 수의 서비스, 예를 들어, SDTV 또는 HDTV 서비스를 허용하도록 사용될 수 있다.
어드밴스드 프로파일의 타겟 SNR 범위는 대략 20 내지 30dB이다. MIMO 송신은 초기에 기존의 타원 편파(elliptically-polarized) 송신 장치를 이용할 수 있지만, 미래에 풀 파워 교차 편파 송신(full-power cross-polarized transmission)으로 확장된다. 어드밴스드 프로파일에 대한 중요한 시스템 파라미터는 이하의 표 3에 열거된다.
LDPC 코드워드 길이 16K, 64K 비트
성상(constellation) 사이즈 8-12 bpcu
시간 디인터리빙 메모리 사이즈 ≤ 219 데이터 셀
파일럿 패턴 고정 수신을 위한 파일럿 패턴
FFT 사이즈 16K, 32K 포인트
이 경우, 베이스 프로파일은 지상파 방송 서비스 및 모바일 방송 서비스 모두를 위한 프로파일로서 사용될 수 있다. 즉, 베이스 프로파일은 모바일 프로파일을 포함하는 프로파일의 개념을 정의하는데 사용될 수 있다. 또한, 어드밴스드 프로파일은 MIMO를 갖는 베이스 프로파일을 위한 어드밴스드 프로파일 및 MIMO를 갖는 핸드헬드 프로파일을 위한 어드밴스드 프로파일로 분리될 수 있다. 또한, 3개의 프로파일은 설계자의 의도에 따라 변경될 수 있다.
다음의 용어 및 정의가 본 발명에 적용될 수 있다. 다음의 용어 및 정의는 설계에 따라 변경될 수 있다.
보조 스트림: 아직 정의되지 않은 변조 및 코딩의 데이터를 전달하는 셀의 시퀀스로서, 미래 확장을 위해 또는 브로드캐스터 또는 네트워크 오퍼레이터에 의한 요구대로 사용될 수 있다.
베이스 데이터 파이프: 서비스 시그널링 데이터를 전달하는 데이터 파이프
베이스밴드 프레임(또는 BBFRAME): 하나의 FEC 인코딩 프로세스(BCH 및 LDPC 인코딩)으로의 입력을 형성하는 Kbch 비트의 세트
셀: OFDM 송신의 하나의 캐리어에 의해 전달되는 변조 값
코딩 블록: PLS1 데이터의 LDPC 인코딩 블록 또는 PLS2 데이터의 LDPC 인코딩 블록 중의 하나
데이터 파이프: 서비스 데이터 또는 관련 메타데이터를 전달하는 물리층 내의 논리 채널로서, 하나 또는 다수의 서비스(들) 또는 서비스 컴포넌트(들)를 전달할 수 있다.
데이터 파이프 단위: 프레임 내의 DP로 데이터 셀을 할당하는 기본 단위
데이터 심볼: 프리앰블 심볼이 아닌 프레임 내의 OFDM 심볼 (프레임 시그널링 심볼 및 프레임 에지 심볼은 데이터 심볼에 포함된다.)
DP_ID: 이 8 비트 필드는 SYSTEM_ID에 의해 식별된 시스템 내의 DP 를 고유하게 식별한다.
더미 셀: PLS 시그널링, DP 또는 보조 스트림에 사용되지 않는 나머지 용량을 채우는데 사용되는 의사 랜덤 값을 전달하는 셀
비상 경계 채널(emergency alert channel; EAS): EAS 정보 데이터를 전달하는 프레임의 일부
프레임: 프리앰블로 시작하고 프레임 에지 심볼로 종료하는 물리층 시간 슬롯
프레임 수신 유닛: FET를 포함하는 동일 또는 상이한 물리층 프로파일에 속하는 프레임 세트로서, 수퍼 프레임 내에서 8회 반복된다.
고속 정보 채널: 서비스 및 대응 베이스 DP 사이의 맵핑 정보를 전달하는 프레임 내의 논리 채널
FECBLOCK: DP 데이터의 LDPC 인코딩 비트의 세트
FFT 사이즈: 특정 모드에 사용되는 공칭 FFT 사이즈로, 기본 기간((elementary period)(T)의 주기로 표현되는 액티브 심볼 기간(Ts)과 동일하다.
프레임 시그널링 심볼: FFT 사이즈, 보호 구간(guard interval) 및 분산형 파일럿 패턴의 소정의 조합으로 프레임의 시작시에 사용되는 더 높은 파일럿 밀도를 갖는 OFDM 심볼로, PLS 데이터의 일부를 전달한다.
프레임 에지 심볼: FFT 사이즈, 보호 구간(guard interval) 및 분산형 파일럿 패턴의 소정의 조합으로 프레임의 종료시에 사용되는 더 높은 파일럿 밀도를 갖는 OFDM 심볼
프레임 그룹: 수퍼 프레임 내의 동일한 PHY 프로파일 타입을 갖는 모든 프레임의 세트
미래 확장 프레임: 미래 확장을 위해 사용될 수 있는 수퍼 프레임 내의 물리층 시간 슬롯으로서, 프리앰블로 시작한다.
퓨처캐스트(futurecast) UTB 시스템: 입력이 하나 이상의 MPEG2-TS 또는 IP 또는 일반 스트림(들)이고 출력이 RF 신호인 제안된 물리층 방송 시스템
입력 스트림: 시스템에 의해 엔드 사용자에게 전달되는 서비스의 앙상블을 위한 데이터의 스트림
정상 데이터 심볼: 프레임 시그널링 심볼 및 프레임 에지 심볼을 제외한 데이터 심볼
PHY 프로파일: 해당 수신기가 구현해야 하는 모든 구성의 서브세트
PLS: PSL1 및 PLS2로 구성된 물리층 시그널링 데이터
PLS1: 고정 사이즈, 코딩 및 변조를 갖는 FSS 심볼에서 전달되는 PLS 데이터의 제1 세트로서, PLS2를 디코딩하는데 필요한 파라미터 뿐만 아니라 시스템에 관한 기본 정보를 전달한다.
주(note): 프레임 그룹의 듀레이션을 위해 PLS1 데이터는 일정하게 유지된다.
PLS2: FSS 심볼에서 송신되는 PLS 데이터의 제2 세트로서, 시스템 및 DP에 대한 더 세부적인 PLS 데이터를 전달한다.
PLS2 동적 데이터: 프레임별로 동적으로 변할 수 있는 PLS2 데이터
PLS2 정적 데이터: 프레임 그룹의 듀레이션 동안 정적으로 유지되는 PLS2 데이터
프리앰블 시그널링 데이터: 프리앰블 심볼에 의해 전달되고 시스템의 기본 모드를 식별하는데 사용되는 시그널링 데이터
프리앰블 심볼: 기본 PLS 데이터를 전달하고 프레임의 초기에 위치하는 고정 길이 파일럿 심볼
주: 프리앰블 심볼은 주로 고속 초기 밴드 스캔을 위해 사용되어 시스템 신호, 그 타이밍, 주파수 오프셋 및 FFT 사이즈를 검출한다.
미래 사용을 위해 예약: 현재 문서에서는 정의되지 않지만 미래에 정의될 수 있다.
수퍼 프레임: 8개의 프레임 반복 단위의 세트
시간 인터리빙 블록(TI 블록): 시간 인터리버 메모리의 하나의 용도에 대응하는 시간 인터리빙이 수행되는 셀의 세트
TI 그룹: 특정 DP을 위한 동적 용량 할당이 수행되는 단위로서, 정수, 즉, 동적으로 변하는 수의 XFECBLOCK으로 구성된다.
주: TI 그룹은 하나의 프레임에 직접 맵핑되거나 다수의 프레임에 맵핑될 수 있다. 이것은 하나 이상의 TI 블록을 포함할 수 있다.
타입 1 DP: 모든 DP가 TDM 방식으로 맵핑되는 프레임의 DP
타입 2 DP: 모든 DP가 FDM 방식으로 맵핑되는 프레임의 DP
XFECBLOCK: 하나의 LDPC FECBLOCK의 모든 비트를 전달하는 Ncells 셀의 세트
도 1은 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 송신하는 장치의 구조를 나타내는 도면이다.
본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 송신하는 장치는 입력 포맷팅 블록(1000), BICM(bit interleaved coding & modulation) 블록(1010), 프레임 구조 블록(1020), OFDM(orthogonal frequency division multiplexing) 생성 블록(1030), 시그널링 생성 블록(1040)을 포함할 수 있다. 방송 신호를 송신하는 장치의 각 모듈의 동작을 이하에서 설명한다.
IP 스트림/패킷 및 MPEG2-TS는 메인 입력 포맷이고, 다른 스트림 타입은 일반 스트림으로서 처리된다. 이들 데이터 입력에 더하여, 관리 정보가 입력되어 각 입력 스트림에 대한 해당 대역폭의 스케줄링 및 할당을 제어한다. 하나 또는 다수의 TS 스트림(들), IP 스트림(들) 및/또는 일반 스트림(들) 입력이 동시에 허용된다.
입력 포맷팅 블록(1000)은 각 입력 스트림을 하나 또는 다수의 데이터 파이프(들)로 디멀티플렉스하고, 독립 코딩 및 변조가 데이터 파이프에 적용된다. 데이터 파이프(DP)는 강건함 제어를 위한 기본 단위로, QoS에 영향을 준다. 하나 또는 다수의 서비스(들) 또는 서비스 컴포넌트(들)는 단일 DP에 의해 전달될 수 있다. 입력 포맷팅 블록(1000)의 동작의 세부사항은 후술한다.
데이터 파이프는 서비스 데이터 또는 관련 메타데이터를 전달하는 물리층 내의 논리 채널로, 하나 또는 다수의 서비스(들) 또는 서비스 컴포넌트(들)를 전달할 수 있다.
또한, 데이터 파이프 단위는 프레임 내의 DP에 데이터 셀을 할당하는 기본 유닛이다.
BICM 블록(1010)에서, 패리티 데이터가 에러 정정을 위해 추가되고, 인코딩된 비트 스트림은 복소수값 성상 심볼에 맵핑된다. 심볼은 해당 DP에 사용되는 특정 인터리빙 깊이를 가로질러 인터리빙된다. 어드밴스드 프로파일에 대하여, MIMO 인코딩이 BICM 블록(1010)에서 수행되고 추가의 데이터 경로는 MIMO 송신을 위한 출력에서 더해진다. BICM 블록(1010)의 세부사항은 후술한다.
프레임 빌딩 블록(1020)은 입력 DP의 데이터 셀을 프레임 내의 OFDM 심볼로 맵핑할 수 있다. 맵핑 후, 주파수 인터리빙은 주파수 도메인 다이버시티에 사용되어 특히 주파수 선택 페이딩 채널을 방지한다. 프레임 빌딩 블록(1020)의 동작의 세부사항은 후술한다.
각 프레임의 초기에 프리앰블을 삽입한 후에, OFDM 생성 블록(1030)은 보호 구간으로서 순환 전치(cyclic prefix)를 갖는 종래의 OFDM 변조를 적용할 수 있다. 안테나 공간 다이버시트리를 위하여, 분산형 MISO 방식이 송신기에 적용된다. 또한, PAPR(peak-to-average power reduction) 방식이 시간 도메인에서 수행된다. 유연한 네트워크 계획을 위해, 이 제안은 다양한 FFT 사이즈, 보호 구간 길이 및 해당 파일럿 패턴의 세트를 제공한다.
시그널링 생성 블록(1040)은 각 기능 블록의 동작에 사용되는 물리층 시그널링 정보를 생성할 수 있다. 이 시그널링 정보는 또한 관심있는 서비스가 수신측에서 적절히 회복되도록 송신된다. 시그널링 생성 블록(1040)의 동작의 세부사항은 후술한다.
도 2, 3 및 4는 본 발명의 실시예에 따른 입력 포맷팅 블록(1000)을 나타낸다. 각 도면에 대하여 설명한다.
도 2는 본 발명의 일 실시예에 따른 입력 포맷팅 블록을 나타내는 도면이다. 도 2는 입력 신호가 단일 입력 스트림일 때의 입력 포맷팅 블록을 나타낸다.
도 2에 도시된 입력 포맷팅 블록은 도 1을 참조하여 설명한 입력 포맷팅 블록(1000)의 실시예에 해당한다.
물리층으로의 입력은 하나 또는 다수의 데이터 스트림으로 구성될 수 있다. 각 데이터 스트림은 하나의 DP에 의해 전달된다. 모드 적응 모듈은 들어오는 데이터 스트림을 베이스밴드 프레임(BBF)의 데이터 필드로 슬라이스한다. 시스템은 3가지 타입의 입력 데이터 스트림, 즉, MPEG2-TS, 인터넷 프로토콜(IP) 및 GS(generic stream)를 지원한다. MPEG2-TS는 고정 길이(188 바이트) 패킷으로 특성화되고, 제1 바이트는 싱크(sync) 바이트(0x47)이다. IP 스트림은 IP 패킷 헤더 내에서 시그널링되는 가변 길이 IP 데이터그램 패킷으로 구성된다. 시스템은 IP 스트림을 위한 IPv4 및 IPv6를 지원한다. GS는 캡슐화 패킷 헤더 내에서 시그널링되는 가변 길이 패킷 또는 고정 길이 패킷으로 구성될 수 있다.
(a) 는 신호 DP를 위한 모드 적응 블록(2000) 및 스트림 적응 블록(2010)을 나타내고, (b)는 PLS 신호를 생성하고 처리하는 PLS 생성 블록(2020) 및 PLS 스크램블러(2030)를 나타낸다. 각 블록의 동작을 설명한다.
입력 스트림 스플리터는 입력 TS, IP, GS 스트림을 다수의 서비스 또는 서비스 컴포넌트(오디오, 비디오, 등) 스트림으로 분리한다. 모드 적응 모듈(2010)은 CRC 인코더, BB(baseband) 프레임 슬라이서 및 BB 프레임 헤더 삽입 블록으로 구성된다.
CRC 인코더는 사용자 패킷(UP) 레벨, 즉, CRC-8, CRC-16 및 CRC-32에서 에러 정정을 위한 3가지 타입의 CRC 인코딩을 제공한다. 계산된 CRC 바이트는 UP 후에 첨부된다. CRC-8는 TS 스트림에 사용되고 CRC-32는 IP 스트림에 사용된다. GS 스트림이 CRC 인코딩을 제공하지 않으면, 제안된 CRC 인코딩이 적용되어야 한다.
BB 프레임 슬라이서는 입력을 내부 논리 비트 포맷으로 맵핑한다. 처음 수신된 비트는 MBS인 것으로 정의된다. BB 프레임 슬라이서는 이용가능한 데이터 필드 용량과 동일한 다수의 입력 비트를 할당한다. BBF 페이로드와 동일한 다수의 입력 비트를 할당하기 위하여, UP 패킷 스트림은 BBF의 데이터 필드에 맞도록 슬라이스된다.
BB 프레임 헤더 삽입 블록은 2바이트의 고정 길이 BBF 헤더를 BB 프레임의 앞에 삽입할 수 있다. BBF 헤더는 STUFFI (1 비트), SYNCD(13 비트) 및 RFU(2 비트)로 구성된다. 고정 2바이트 BBF 헤더에 더하여, BBF는 2바이트 BBF 헤더의 끝에 확장 필드(1 또는 3 바이트)를 가질 수 있다.
스트림 적응 블록(2010)은 스터핑(stuffing) 삽입 블록 및 BB 스크램블러로 구성된다.
스터핑 삽입 블록은 스터핑 필드를 BB 프레임의 페이로드에 삽입할 수 있다. 스트림 적응으로의 입력 데이터가 BB 프레임을 채우기에 충분하면, STUFFI는 "0"으로 설정되고 BBF는 스터핑 필드를 갖지 않는다. 그렇지 않으면, STUFFI가 "1"로 설정되고 스터핑 필드가 BBF 헤더 직후에 삽입된다. 스터핑 필드는 2 바이트의 스터핑 필드 헤더 및 가변 사이즈의 스터핑 데이터를 포함한다.
BB 스크램블러는 에너지 분산(energy dispersal)을 위해 완전한 BBF를 스크램블링한다. 스크램블링 시퀀스는 BBF와 동시 발생한다. 스크램블링 시퀀스는 피드백된 시프트 레지스터에 의해 생성된다.
PLS 생성 블록(2020)은 물리층 시그널링(PLS) 데이터를 생성할 수 있다. PLS는 수신기에 물리층 DP를 액세스하는 수단을 제공한다. PLS 데이터는 PLS1 데이터 및 PLS2 데이터로 구성된다.
PLS1 데이터는 고정 사이즈, 코딩 및 변조를 갖는 프레임 내의 FSS 심볼에서 전달되는 PLS 데이터의 제1 세트로서, PLS2 데이터를 디코딩하는데 필요한 파라미터 뿐만 아니라 시스템에 관한 기본 정보를 전달한다. PLS1 데이터는 PLS2 데이터의 수신 및 디코딩을 가능하게 하는데 요구되는 파라미터를 포함하는 기본 송신 파라미터를 제공한다. 또한, PLS1 데이터는 프레임 그룹의 듀레이션 동안 일정하게 유지된다.
PLS2 데이터는 FSS 심볼에서 전송되는 PLS 데이터의 제2 세트로서, 시스템 및 DP에 대한 더 상세한 PLS 데이터를 전달한다. PLS2는 수신기에게 충분한 데이터를 제공하여 원하는 DP를 디코딩하는 파라미터를 포함한다. PLS2 시그널링은 또한 2가지 타입의 파라미터, 즉, PLS2 정적 데이터(PLS2-STAT 데이터) 및 PLS2 동적 데이터(PLS2-DYN 데이터)로 구성된다. PLS2 정적 데이터는 프레임 그룹의 듀레이션 동안 정적으로 남아 있는 PLS2 데이터이고, PLS2 동적 데이터는 프레임별로 동적으로 변할 수 있는 PLS2 데이터이다.
PLS 데이터의 세부사항은 후술한다.
PLS 스크램블러(2030)는 에너지 분산을 위해 생성된 PLS 데이터를 스크램블링할 수 있다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 3은 본 발명의 다른 실시예에 따른 입력 포맷팅 블록을 나타내는 도면이다.
도 3에 도시된 입력 포맷팅 블록은 도 1을 참조하여 설명한 입력 포맷팅 블록(1000)의 실시예에 해당한다.
도 3은 입력 신호가 다수의 입력 스트림에 대응할 때 입력 포맷팅 블록의 모드 적응 블록을 나타낸다.
다수의 입력 스트림을 처리하는 입력 포맷팅 블록의 모드 적응 블록은 독립적으로 다수의 입력 스트림을 처리할 수 있다.
도 3을 참조하면, 다수의 입력 스트림을 각각 처리하는 모드 적응 블록은 입력 스트림 스플리터(3000), 입력 스트림 동기화기(3010), 보상 지연 블록(3020), 널(null) 패킷 삭제 블록(3030), 헤드 압축 블록(3040), CRC 인코더(3050), BB 프레임 슬라이서(3060) 및 BB 헤더 삽입 블록(3070)을 포함할 수 있다. 모드 적응 블록의 각 블록을 이하에서 설명한다.
CRC 인코더(3050), BB 프레임 슬라이서(3060) 및 BB 헤더 삽입 블록(3070)의 동작은 도 2를 참조하여 설명한 CRC 인코더, BB 프레임 슬라이서 및 BB 헤더 삽입 블록에 대응하므로 그 설명은 생략한다.
입력 스트림 스플리터(3000)는 입력 TS, IP GS 스트림을 다수의 서비스 또는 서비스 컴포넌트(오디오, 비디오, 등) 스트림으로 분리할 수 있다.
입력 스트림 동기화기(3010)는 ISSY라 할 수 있다. ISSY는 임의의 입력 데이터 포맷에 대한 일정한 엔드-투-엔드 송신 지연 및 CBR(constant bit rate)을 보장하는 적절한 수단을 제공할 수 있다. ISSY는 항상 TS를 전달하는 다수의 DP의 경우에 사용되고, 선택적으로, GS 스트림을 전달하는 DP에 사용된다.
보상 지연 블록(3020)은 ISSY 정보의 삽입 후에 분리된 TS 패킷 스트림을 지연하여 수신기 내의 추가의 메모리를 요구하지 않고 TS 패킷 재결합 메커니즘을 허용할 수 있다.
널 패킷 삭제 블록(3030)은 TS 입력 스트림 케이스에만 사용된다. 임의의 TS 입력 스트림 또는 분리된 TS 스트림은 CBR TS 스트림에 VBR(variable bit-rate) 서비스를 수용하기 위하여 존재하는 다수의 널 패킷을 가질 수 있다. 이 경우, 불필요한 송신 오버헤드를 피하기 위하여, 널 패킷이 식별되고 송신되지 않는다. 수신기에서, 제거된 널 패킷은 송신시에 삽입된 DNP(deleted null-packet) 카운터를 참조하여 본래에 있던 정확한 장소에 재삽입되어, 일정한 비트 레이트를 보장하고 타임스탬프(PCR) 업데이트에 대한 필요성을 피할 수 있다.
헤드 압축 블록(3040)은 패킷 헤더 압축을 제공하여 TS 또는 IP 입력 스트림에 대한 송신 효율을 증가시킬 수 있다. 수신기가 헤더의 소정 부분에 대한 선험적 정보(a priori information)를 가질 수 있으므로, 이 기지의 정보는 송신기에서 삭제될 수 있다.
전송 스트림에 대하여, 수신기는 싱크-바이트 구성(0x47) 및 패킷 길이(188 바이트)에 관한 선험적 정보를 갖는다. 입력 TS 스트림이 단 하나의 PID를 갖는 콘텐츠를 전달하면, 즉, 하나의 서비스 컴포넌트(비디오, 오디오 등) 또는 서비스 서브 컴포넌트(SVC 베이스층, SVC 인핸스먼트층, MVC 베이스 뷰 또는 MVC 종속 뷰)에 대해서만, TS 패킷 헤더 압축이 (선택적으로) 전송 스트림에 적용될 수 있다. 입력 스트림이 IP 스트림이면, IP 패킷 헤더 압축이 선택적으로 사용된다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 4는 본 발명의 다른 실시예에 따른 입력 포맷팅 블록을 나타내는 도면이다.
도 4에 도시된 입력 포맷팅 블록은 도 1을 참조하여 설명한 입력 포맷팅 블록(1000)의 실시예에 해당한다.
도 4는 입력 신호가 다수의 입력 스트림에 대응할 때 입력 포맷팅 모듈의 스트림 적응 블록을 나타낸다.
도 4를 참조하면, 다수의 입력 스트림을 각각 처리하는 모드 적응 블록은 스케줄러(4000), 1프레임 지연 블록(4010), 스터핑 삽입 블록(4020), 인밴드(in-band) 시그널링(4030), BB 프레임 스크램블러(4040), PLS 생성 블록(4050) 및 PLS 스크램블러(4060)를 포함할 수 있다. 스트림 적응 블록의 각각의 블록을 이하에서 설명한다.
스터핑 삽입 블록(4020), BB 프레임 스크램블러(4040), PLS 생성 블록(4050) 및 PLS 스크램블러(4060)의 동작은 도 2를 참조하여 설명한 스터핑 삽입 블록, BB 스크램블러, PLS 생성 블록 및 PLS 스크램블러에 대응하므로 그 설명은 생략한다.
스케줄러(4000)는 각각의 DP 의 FECBLOCK의 양으로부터 전체 프레임에 걸친 전체 셀 할당을 결정할 수 있다. PLS, EAC 및 FIC에 대한 할당을 포함하여, 스케줄러는 PLS2-DYN 데이터의 값을 생성하고, 이는 프레임의 FSS 내의 인밴드 시그널링 또는 PLS 셀로서 송신된다. FECBLOCK, EAC 및 FIC의 세부사항은 후술한다.
1프레임 지연 블록(4010)은 입력 데이터를 1 송신 프레임만큼 지연시켜 다음 프레임에 관한 스케줄링 정보가 DP로 삽입될 인밴드 시그널링 정보에 대한 현재 프레임을 통해 송신되도록 할 수 있다.
인밴드 시그널링(4030)은 PLS2 데이터의 지연되지 않은 부분을 프레임의 DP로 삽입할 수 있다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 5는 본 발명의 실시예에 따른 BICM 블록을 나타내는 도면이다.
도 5에 도시된 BICM 블록은 도 1을 참조하여 설명한 BICM 블록(1010)의 실시예에 해당한다.
상술한 바와 같이, 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 송신하는 장치는 지상파 방송 서비스, 모바일 방송 서비스, UHDTV 서비스 등을 제공할 수 있다.
QoS는 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 송신하는 장치에 의해 제공되는 서비스의 특성에 의존하므로, 각 서비스에 대응하는 데이터는 상이한 방식을 통해 처리될 필요가 있다. 따라서, 본 발명의 실시예에 따른 BICM 블록은 SISO, MISO 및 MIMO 방식을 데이터 경로에 각각 대응하는 데이터 파이프에 독립적으로 적용함으로써 그에 입력된 DP 를 독립적으로 처리할 수 있다. 결과적으로, 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 송신하는 장치는 각각의 DP 를 통해 송신되는 각각의 서비스 또는 서비스 컴포넌트에 대한 QoS를 제어할 수 있다.
(a) 는 베이스 프로파일 및 핸드헬드 프로파일에 의해 공유된 BICM 블록을 나타내고, (b)는 어드밴스드 프로파일의 BICM 블록을 나타낸다.
베이스 프로파일 및 핸드헬드 프로파일에 의해 공유된 BICM 블록 및 어드밴스드 프로파일에 의해 공유된 BICM 블록은 각 DP 를 처리하는 복수의 처리 블록을 포함할 수 있다.
베이스 프로파일 및 핸드헬드 프로파일을 위한 BICM 블록 및 어드밴스드 프로파일을 위한 BICM 블록의 각각의 처리 블록을 이하에서 설명한다.
베이스 프로파일 및 핸드헬드 프로파일을 위한 BICM 블록의 처리 블록(5000)은 데이터 FEC 인코더(5010), 비트 인터리버(5020), 성상 맵퍼(5030), SSD(signal space diversity) 인코딩 블록(5040) 및 시간 인터리버(5050)를 포함할 수 있다.
데이터 FEC 인코더(5010)는 입력 BBF에 대하여 FEC 인코딩을 수행하여 아우터 코딩(BCH) 및 이너 코딩(LDPC)를 이용하여 FECBLOCK 절차를 생성할 수 있다. 아우터 코딩(BCH)는 선택적인 코딩 방법이다. 데이터 FEC 인코더(5010)의 동작의 세부사항은 후술한다.
비트 인터리버(5020)는 데이터 FECT 인코더(5010)의 출력을 인터리빙하여 효율적으로 구현가능한 구조를 제공하면서 LDPC 코드 및 변조 방식의 조합으로 최적화된 성능을 달성할 수 있다. 비트 인터리버(5020)의 동작의 세부사항은 후술한다.
성상 맵퍼(5030)는 QPSK, QAM-16, 불균일 QAM(NUQ-64, NUQ-256, NUQ-1024) 또는 불균일 성상(NUC-16, NUC-64, NUC-256, NUC-1024)을 이용하여 베이스 및 핸드헬드 프로파일 내의 비트 인터리버(5020)로부터의 각 셀 워드 및 어드밴스드 프로파일 내의 셀-워드 디멀티플렉서(5010-1)로부터의 셀 워드를 변조하여 파워 정규화 성상 포인트를 제공할 수 있다. 이 성상 맵핑은 DP 에 대해서만 적용된다. QAM-16 및 NUQ가 방형(square shaped)이지만 NUC는 임의의 형상을 갖는다. 각각의 성상이 90도의 임의의 배수로 회전하면, 회전된 성상은 정확히 본래의 성상과 중첩한다. 이 "회전-감각(rotation-sense) 대칭 특성은 실수 성분 및 허수 성분의 평균 파워 및 용량이 서로 같아지게 한다. NUQ 및 NUC는 각 코드 레이트에 대하여 특별히 정의되고 사용되는 특정한 하나가 PLS2 데이터에서 제출된 파라미터(DP_MOD)에 의해 시그널링된다.
SSD 인코딩 블록(5040)은 2(2D), 3(3D) 및 4(4D) 차원으로 셀을 프리코딩하여 상이한 페이딩 조건 하에서 수신 강건함을 증가시킬 수 있다.
시간 인터리버(5050)는 DP 레벨에서 동작할 수 있다. 시간 인터리빙(TI)의 파라미터는 각 DP 에 대하여 상이하게 설정될 수 있다. 시간 인터리버(5050)의 동작의 세부사항은 후술한다.
어드밴스드 프로파일을 위한 BICM 블록의 처리 블록(5000-1)은 데이터 FEC 인코더, 비트 인터리버, 성상 맵퍼 및 시간 인터리버를 포함할 수 있다. 그러나, 처리 블록(5000-1)은 처리 블록(5000)와 구별되며, 셀-워드 디멀티플렉서(5010-1) 및 MIMO 인코딩 블록(5020-1)을 더 포함한다.
또한, 처리 블록(5000-1)의 데이터 FEC 인코더, 비트 인터리버, 성상 맵퍼 및 시간 인터리버의 동작은 상술한 데이터 FEC 인코더(5010), 비트 인터리버(5020), 성상 맵퍼(5030) 및 시간 인터리버(5050)에 대응하므로 그 설명은 생략한다.
셀-워드 디멀티플렉서(5010-1)는 어드밴스드 프로파일의 DP에 사용되어 단일 셀-워드 스트림을 MIMO 처리를 위한 듀얼 셀-워드 스트림으로 분리한다. 셀-워드 디멀티플렉서(5010-1)의 동작의 세부사항은 후술한다.
MIMO 인코딩 블록(5020-1)은 MIMO 인코딩 방식을 이용하여 셀-워드 디멀티플렉서(5010-1)의 출력을 처리할 수 있다. MIMO 인코딩 방식은 방송 신호 송신을 위해 최적화되었다. MIMO 기술은 MIMO 기술은 용량을 증가시키는 우수한 방식이지만 채널 특성에 의존한다. 특히, 브로드캐스팅에 대하여, 상이한 신호 전파 특성에 의해 유발된 2개의 안테나 사이의 수신된 신호 파워의 차 또는 채널의 강한 LOS 성분은 MIMO로부터 용량 이득을 얻기 어렵게 만들 수 있다. 제안된 MIMO 인코딩 방식은 MIMO 출력 신호 중의 하나의 회전 기반 프리코딩 및 위상 랜덤화를 이용하여 이 문제를 극복한다.
MIMO 인코딩은 송신기 및 수신기에서 적어도 2개의 안테나를 필요로 하는 2X2 MIMO 시스템을 목적으로 할 수 있다. 이 제안에서 2개의 MIMO 인코딩 모드, 즉, FR-SM(full-rate spatial multiplexing) 및 FRFD-SM(full-rate full-diversity spatial multiplexing)가 정의된다. FR-SM 인코딩은 수신기측에서 비교적 작은 복잡도 증가와 함께 용량 증가를 제공하지만, FRFD-SM 인코딩은 수신기측에서 큰 복잡도 증가와 함께 용량 증가 및 추가의 다이버시티 이득을 제공한다. 제안된 MIMO 인코딩 방식은 안테나 극성 구성에 대한 제한을 갖지 않는다.
MIMO 처리는 어드밴스드 프로파일 프레임을 위해 요구될 수 있고, 이는 어드밴스드 프로파일 프레임 내의 모든 DP가 MIMO 인코더에 의해 처리되는 것을 의미한다. MIMO 처리는 DP 레벨에서 적용될 수 있다. 성상 맵퍼 출력(constellation mapper output)(NUQ)의 쌍(e1,i 및 e2,i)은 MIMO 인코더의 입력으로 공급될 수 있다. MIMO 인코더 출력의 쌍(g1,i 및 g2,i)은 각각의 TX 안테나의 OFDM 심볼(l) 및 동일 캐리어(k)에 의해 송신될 수 있다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 6은 본 발명의 다른 실시예에 따른 BICM 블록을 나타내는 도면이다.
도 6에 도시된 BICM 블록은 도 1을 참조하여 설명한 BICM 블록(1010)의 실시예에 해당한다.
도 6은 물리층 시그널링(PLS), 비상 경계 채널(EAC) 및 고속 정보 채널(FIC)의 보호를 위한 BICM 블록을 나타낸다. EAC는 EAS 정보를 전달하는 프레임의 일부이고 FIC는 서비스 및 해당 베이스 DP 사이의 맵핑 정보를 전달하는 프레임 내의 논리 채널이다. EAC 및 FIC의 세부사항은 후술한다.
도 6을 참조하면, PLS, EAC 및 FIC의 보호를 위한 BICM 블록은 PLS FEC 인코더(6000), 비트 인터리버(6010) 및 성상 맵퍼(6020)를 포함할 수 있다.
또한, PLS FEC 인코더(6000)는 스크램블러, BCH 인코딩/제로 삽입 블록, LDPC 인코딩 블록 및 LDPC 패리터 펑쳐링 블록을 포함할 수 있다. BICM 블록의 각 블록을 이하에서 설명한다.
PLS FEC 인코더(6000)는 스크램블링된 PLS 1/2 데이터, EAC 및 FIC 섹션을 인코딩할 수 있다.
스크램블러는 BCH 인코딩 및 단축 및 펑쳐링된 LDPC 인코딩 전에 PLS1 데이터 및 PLS2 데이터를 스크램블링할 수 있다.
BCH 인코딩/제로 삽입 블록은 PLS 보호를 위해 단축된 BCH 코드를 이용하여 스크램블링된 PLS 1/2 데이터에 대하여 아우터 인코딩을 수행하고 BCH 인코딩 후 제로 비트를 삽입할 수 있다. PLS1 데이터에 대해서만, LDPC 인코딩 전에 제로 삽입의 출력 비트가 퍼뮤팅(permute)될 수 있다.
LDPC 인코딩 블록은 LDPC 코드를 이용하여 BCH 인코딩/제로 삽입 블록의 출력을 인코딩할 수 있다. 완전한 코딩 블록(Cldpc)을 생성하기 위하여, 패리티 비트(Pldpc)가 각각의 제로 삽입 PLS 정보 블록(Ildpc)로부터 조직적으로 인코딩되고 그 후 첨부된다.
Figure 112016052519418-pct00001
PLS1 및 PLS2에 대한 LDPC 코드 파라미터는 다음의 표 4와 같다.
Figure 112016052519418-pct00002
LDPC 패리티 펑쳐링 블록은 PLS1 데이터 및 PLS2 데이터에 대하여 펑쳐링을 수행할 수 있다.
PLS1 데이터 보호에 단축이 적용되면, 임의의 LDPC 패리티 비트는 LDPC 인코딩 후에 펑쳐링된다. 또한, PLS2 데이터 보호를 위해, PLS2의 LDPC 패리티 비트는 LDPC 인코딩 후에 펑쳐링된다. 이들 펑쳐링된 비트는 송신되지 않는다.
비트 인터리버(6010)는 각각 단축 및 평쳐링된 PLS1 데이터 및 PLS2 데이터를 인터리빙한다.
성상 맵퍼(6020)는 비트 인터리빙된 PLS1 데이터 및 PLS2 데이터를 성상에 맵핑할 수 있다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 7은 본 발명의 일 실시예에 따른 프레임 빌딩 블록을 나타내는 도면이다.
도 7에 도시된 프레임 빌딩 블록은 도 1을 참조하여 설명한 프레임 빌딩 블록(1020)의 실시예에 해당한다.
도 7을 참조하면, 프레임 빌딩 블록은 지연 보상 블록(7000), 셀 맵퍼(7010) 및 주파수 인터리버(7020)를 포함할 수 있다. 프레임 빌딩 블록의 각각의 블록을 이하에서 설명한다.
지연 보상 블록(7000)은 데이터 파이프 및 대응 PLS 데이터 간의 타이밍을 조절하여 송신단에서 시간이 함께 맞추어지도록 보장할 수 있다. PLS 데이터는 입력 포맷팅 블록 및 BICM 블록에 의해 유발된 데이터 파이프의 지연을 처리함으로써 데이터 파이프와 동일한 양만큼 지연된다. BICM 블록의 지연은 주로 시간 인터리버(5050)에 의한다. 인밴드 시그널링 데이터가 다음의 TI 그룹의 정보를 전달하여 시그널링될 DP 보다 하나의 프레임만큼 빠르게 전달된다. 따라서, 지연 보상 블록은 인밴드 시그널링 데이터를 지연한다.
셀 맵퍼(7010)는 PLS, EAC, FIC, DP, 보조 스트림 및 더미 셀을 프레임 내의 OFDM 심볼의 액티브 캐리어로 맵핑할 수 있다. 셀 맵퍼(7010)의 기본 기능은, 만약에 있다면, DP, PLS 셀 및 EAC/FIC 셀의 각각에 대하여 TI에 의해 생성된 데이터 셀을 프레임 내의 OFDM 심볼의 각각에 대응하는 액티브 OFDM 셀의 어레이로 맵핑하는 것이다. 서비스 시그널링 데이터(PSI(program specific information)/SI))는 데이터 파이프에 의해 개별적으로 모아 전송될 수 있다. 셀 맵퍼는 스케줄러에 의해 생성된 동적 정보 및 프레임 구조의 구성에 따라 동작한다. 프레임의 세부사항은 후술한다.
주파수 인터리버(7020)는 셀 맵퍼(7010)로부터 수신된 데이터 셀을 랜덤하게 인터리빙하여 주파수 다이버시티를 제공할 수 있다. 또한, 주파수 인터리버(7020)는 상이한 인터리빙 시드(interleaving-seed) 순서를 이용하여 2개의 순차적인 OFDM 심볼로 구성되는 OFDM 심볼 쌍에 대하여 동작하여 단일 프레임 내의 최대 인터리빙 이득을 얻을 수 있다. 주파수 인터리버(7020)의 동작의 세부사항은 후술한다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 8은 본 발명의 실시예에 따른 OFDM 생성 블록을 나타내는 도면이다.
도 8에 도시된 OFDM 생성 블록은 도 1을 참조하여 설명한 OFDM 생성 블록(1030)의 실시예에 해당한다.
OFDM 생성 블록은 프레임 빌딩 블록에 의해 생성된 셀에 의해 OFDM 캐리어를 변조하고, 파일럿을 삽입하고, 송신될 시간 도메인 신호를 생성한다. 또한, 이 블록은 순차적으로 보호 구간을 삽입하고 PAPR(peak-to-average power ratio) 감소 처리를 적용하여 최종 RF 신호를 생성한다.
도 8을 참조하면, 프레임 빌딩 블록은 파일럿 및 예약 톤 삽입 블록(8000), 2D-eSFN 인코딩 블록(8010), IFFT(inverse fast Fourier transform) 블록(8020), PAPR 감소 블록(8030), 보호 구간 삽입 블록(8040), 프리앰블 삽입 블록(8050), 다른 시스템 삽입 블록(8060) 및 DAC 블록(8070)을 포함할 수 있다. 프레임 빌딩 블록의 각각의 블록을 이하에서 설명한다.
파일럿 및 예약 톤 삽입 블록(8000)은 파일럿 및 예약 톤을 삽입할 수 있다.
OFDM 심볼 내의 다양한 셀은 파일럿으로 알려진 기준 정보로 변조되고, 파일럿은 수신기에서 선험적으로 알려진 송신 값을 갖는다. 파일럿 셀의 정보는 분산된 파일럿, 반복 파일럿(continual pilot), 에지 파일럿, FSS(frame signaling symbol) 파일럿 및 FES(frame edge symbol) 파일럿으로 구성된다. 각각의 파일럿은 파일럿 타입 및 파일럿 패턴에 따라 특정 부스팅 파워 레벨에서 송신된다. 파일럿 정보의 값은 임의의 주어진 심볼 상의 각각의 송신된 캐리어에 대하여 일련의 값인 기준 시퀀스로부터 도출된다. 파일럿은 프레임 동기화, 주파수 동기화, 시간 동기화, 채널 추정 및 송신 모드 식별에 사용될 수 있고, 또한 위상 잡음을 팔로윙(following)하는데 사용될 수 있다.
기준 시퀀스로부터 취해진 기준 정보는 프레임의 프리앰블, FSS 및 FES를 제외한 모든 심볼에서 분산된 파일럿 셀에서 송신된다. 반복 파일럿은 프레임의 모든 심볼에 삽입된다. 반복 파일럿의 수와 위치는 FFT 사이즈 및 분산된 파일럿 패턴에 의존한다. 에지 캐리어는 프리앰블 심볼을 제외한 모든 심볼 내의 에지 파일럿이다. 이들은 스펙트럼의 에지까지 주파수 보간을 허용하기 위하여 삽입된다. FSS 파일럿은 FSS(들)에 삽입되고 FES 파일럿은 FES에 삽입된다. 이들은 프레임의 에지까지 시간 보간을 허용하기 위하여 삽입된다.
본 발명의 실시예에 따른 시스템은 SFN 네트워크를 지원하고, 분산형 MISO 방식은 선택적으로 매우 강건한 송신 모드를 지원하는데 사용된다. 2D-eSFN은 다수의 TX 안테나를 이용하는 분산형 MISO 방식이고, 각각의 TX 안테나는 SFN 네트워크 내의 상이한 송신측에 배치된다.
2D-eSFN 인코딩 블록(8010)은, SFN 구성에서 시간 및 주파수 다이버시티를 생성하기 위하여, 2D-eSFN 처리를 수행하여 다수의 송신기로부터 송신된 신호의 위상을 왜곡할 수 있다. 그러므로, 오랜 시간 동안의 낮은 플랫 페이딩 또는 깊은 페이딩에 의한 버스트 에러가 완화될 수 있다.
IFFT 블록(8020)은 OFDM 변조 방식을 이용하여 2D-eSFN 인코딩 블록(8010)으로부터의 출력을 변조할 수 있다. 파일럿으로서 (또는 예약 톤으로서) 지정되지 않은 데이터 심볼 내의 임의의 셀은 주파수 인터리버로부터의 데이터 셀 중의 하나를 전달한다. 셀은 OFDM 캐리어에 맵핑된다.
PAPR 감소 블록(8030)은 시간 도메인 내의 다양한 PAPR 감소 알고리즘을 이용하여 입력 신호에 대한 PAPR 감소를 수행할 수 있다.
보호 구간 삽입 블록(8040)은 보호 구간을 삽입할 수 있고, 프리앰블 삽입 블록(8050)은 신호의 앞에 프리앰블을 삽입할 수 있다. 프리앰블의 구조의 세부사항은 후술한다. 다른 시스템 삽입 블록(8060)은 시간 도메인에서 복수의 방송 송수신 시스템의 신호를 멀티플렉싱하여 방송 서비스를 제공하는 2개 이상의 상이한 방송 송신/수신 시스템의 데이터가 동일한 RF 신호 대역폭에서 동시에 송신될 수 있다. 이 경우, 2개 이상의 상이한 방송 송수신 시스템은 상이한 방송 서비스를 제공하는 시스템을 지칭한다. 상이한 방송 서비스는 지상파 방송 서비스, 모바일 방송 서비스 등을 지칭한다. 각각의 방송 서비스와 관련된 데이터는 상이한 프레임을 통해 송신될 수 있다.
DAC 블록(8070)은 입력 디지털 신호를 아날로그 신호르 변환하고 아날로그 신호를 출력할 수 있다. DAC 블록(8070)으로부터 출력된 신호는 물리층 프로파일에 따라 다수의 출력 안테나를 통해 송신될 수 있다. 본 발명의 실시예에 따른 TX 안테나는 수직 또는 수평 극성(polarity)을 가질 수 있다.
상술한 블록은 생략되거나 유사 또는 동일한 기능을 갖는 블록으로 대체될 수 있다.
도 9는 본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 수신하는 장치의 구조를 나타내는 도면이다.
본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 수신하는 장치는 도 1을 참조하여 설명한 미래의 방송 서비스를 위해 방송 신호를 송신하는 장치에 대응할 수 있다.
본 발명의 실시예에 따라 미래의 방송 서비스를 위한 방송 신호를 수신하는 장치는 동기화 및 복조 모듈(9000), 프레임 파싱 모듈(9010), 디맵핑 및 디코딩 모듈(9020), 출력 프로세서(9030) 및 시그널링 디코딩 모듈(9040)을 포함할 수 있다. 방송 신호를 수신하는 장치의 각 모듈의 동작을 이하에서 설명한다.
동기화 및 복조 모듈(9000)은 m개의 Rx 안테나를 통해 입력 신호를 수신하고 방송 신호를 수신하는 장치에 대응하는 시스템에 대하여 신호 검출 및 동기화를 수행하고 방송 신호를 송신하는 장치에 의해 수행되는 절차의 역 절차에 대응하는 복조를 수행할 수 있다.
프레임 파싱 모듈(9100)은 입력 신호 프레임을 파싱하고 사용자에 의해 선택된 서비스가 송신되는 데이터를 추출할 수 있다. 방송 신호를 송신하는 장치가 인터리빙을 수행하면, 프레임 파싱 모듈(9100)은 인터리빙의 역 절차에 대응하는 디인터리빙을 수행할 수 있다. 이 경우, 추출될 필요가 있는 신호 및 데이터의 위치는 시그널링 디코딩 모듈(9400)로부터 출력된 데이터를 디코딩하여 방송 신호를 송신하는 장치에 의해 생성된 시그널링 정보를 회복함으로써 얻어질 수 있다.
디맵핑 및 디코딩 모듈(9200)은 입력 신호를 비트 도메인 데이터로 변환한 후 필요에 따라 디인터리빙할 수 있다. 디맵핑 및 디코딩 모듈(9200)은 송신 효율을 위해 적용된 맵핑에 대하여 디맵핑을 수행하고 디코딩을 통해 송신 채널에 대하여 생성된 에러를 정정할 수 있다. 이 경우, 디맵핑 및 디코딩 모듈(9200)은 시그널링 디코딩 모듈(9400)로부터 출력된 데이터를 디코딩함으로써 디맵핑 및 디코딩에 필요한 송신 파라미터를 얻을 수 있다.
출력 프로세서(9300)는 방송 신호를 송신하여 송신 효율을 개선하는 장치에 의해 적용되는 다양한 압축/신호 처리 절차의 역 절차를 수행할 수 있다. 이 경우, 출력 프로세서(9300)는 시그널링 디코딩 모듈(9400)로부터 출력된 데이터로부터 필요한 제어 정보를 얻을 수 있다. 출력 프로세서(8300)의 출력은 방송 신호를 송신하는 장치로 입력되는 신호에 대응하고 MPEG-TS, IP 스트림(v4 또는 v6) 및 일반 스트림일 수 있다.
시그널링 디코딩 모듈(9400)은 동기화 및 복조 모듈(9000)에 의해 복조된 신호로부터 PLS 정보를 얻을 수 있다. 상술한 바와 같이, 프레임 파싱 모듈(9100), 디맵핑 및 디코딩 모듈(9200) 및 출력 프로세서(9300)는 시그널링 디코딩 모듈(9400)로부터 출력된 데이터를 이용하여 그 기능을 실행할 수 있다.
도 10은 본 발명의 실시예에 따른 프레임 구조를 나타내는 도면이다.
도 10은 수퍼프레임 내의 프레임 타입 및 FRU의 예시적인 구성을 나타낸다. (a) 본 발명의 실시예에 따른 수퍼 프레임을 나타내고, (b)는 본 발명의 실시예에 따른 FRU(frame repetition unit)를 나타내고, (c)는 FRU 내의 가변 PHY 프로파일의 프레임을 나타내고, (d)는 프레임의 구조를 나타낸다.
수퍼 프레임은 8개의 FRU로 구성될 수 있다. FRU는 프레임의 TDM을 위한 기본 멀티플렉싱 단위이고 수퍼프레임 내에서 8번 반복된다.
FRU 내의 각 프레임은 PHY 프로파일(베이스, 핸드헬드, 어드밴스드) 또는 FET 중의 하나에 속한다. FRU 내의 프레임의 최대 허용수는 4이고 주어진 PHY 프로파일은 FRU(예를 들어, 베이스, 베이스, 핸드헬드, 어드밴스드)에서 0배 내지 4배까지의 임의의 횟수만큼 나타날 수 있다. PHY 프로파일 정의는 필요하다면 프리앰블 내의 PHY_PROFILE의 예약 값을 이용하여 확장될 수 있다.
FET 부분은 포함된다면 FRU의 끝에 삽입된다. FET가 FRU에 포함되면, 수퍼 프레임에서 FET의 최소수는 8이다. FET 부분이 서로 인접하는 것은 추천되지 않는다.
하나의 프레임은 또한 다수의 OFDM 심볼 및 프리앰블로 분리된다. (d)에 도시된 바와 같이, 프레임은 프리앰블, 하나 이상의 프레임 시그널링 심볼(FSS), 정상 데이터 심볼 및 프레임 에지 심볼(FES)을 포함한다.
프리앰블은, 고속 퓨어캐스트 UTB 시스템 신호 검출이 가능하고 신호위 효율적인 송수신을 위한 기본 송신 파라미터의 세트를 제공하는 특수 심볼이다. 프리앰블의 세부 설명은 후술한다.
FSS(들)의 주요 목적은 PLS 데이터를 전달하는 것이다. 고속 동기화 및 채널 추정 및 PLS 데이터의 고속 디코딩을 위해, FSS는 정상 데이터 심볼보다 더 밀집한 파일럿 패턴을 갖는다. FES는 정확히 FSS와 동일한 파일럿을 갖고, 이는 FES 직전의 심볼에 대하여 외삽하지 않고 FES 내의 주파수 전용 보간 및 시간 보간을 가능하게 한다.
도 11은 본 발명의 실시예에 따른 프레임의 시그널링 계층 구조를 나타내는 도면이다.
도 11은 3개의 주요 부분, 즉, 프리앰블 시그널링 데이터(11000), PLS1 데이터(11010) 및 PLS2 데이터(11020)로 분리된 시그널링 계층 구조를 나타낸다. 모든 프레임에서 프리앰블 심볼에 의해 전달되는 프리앰블의 목적은 그 프레임의 송신 타입 및 기본 송신 파라미터를 지시하는 것이다. PLS1은 수신기가 PLS2 데이터를 액세스 및 디코딩하도록 하고, 이는 관심있는 DP를 액세스하는 파라미터를 포함한다. PLS2는 모든 프레임에서 전달되고 2개의 주요 부분, 즉, PLS2-STAT 데이터 및 PLS2-DYN 데이터로 분리된다. PLS2 데이터의 정적 및 동적 부분은 필요하면 패딩이 뒤따른다.
도 12는 본 발명의 실시예에 따른 프리엠블 시그널링 데이터를 나타내는 도면이다.
프리앰블 시그널링 데이터는 프레임 구조 내에서 수신기가 PLS 데이터를 액세스하고 DP를 트레이싱하도록 하는데 필요한 정보의 21 비트를 전달한다. 프리앰블 시그널링의 세부사항은 다음과 같다.
PHY_PROFILE: 이 3 비트 필드는 현재 프레임의 PHY 프로파일 타입을 나타낸다. 상이한 PHY 프로파일 타입의 맵핑은 이하 표 5에 주어진다.
값 PHY 프로파일
000 베이스 프로파일
001 핸드헬드 프로파일
010 어드밴스드 프로파일
011-110 예약
111 FET
FFT_SIZE: 이 2 비트 필드는 이하의 표 6에 기재된 바와 같이 프레임 그룹 내의 현재 프레임의 FFT 사이즈를 나타낸다.
값 FFT 사이즈
00 8K FFT
01 16K FFT
10 32K FFT
11 예약
GI_FRACTION: 이 3 비트 필드는 이하의 표 7에 기재된 바와 같이 현재의 수퍼 프레임 내의 보호 구간 분수(fraction) 값을 나타낸다.
값 GI_FRACTION
000 1/5
001 1/10
010 1/20
011 1/40
100 1/80
101 1/160
110-111 예약
EAC_FLAG: 이 1 비트 필드는 EAC가 현재의 프레임에 제공되는지를 나타낸다. 이 필드가 "1"로 설정되면, EAS(emergency alert service)가 현재의 프레임에서 제공된다. 이 필드가 "0"으로 설정되면, EAS가 현재의 프레임에서 전달되지 않는다. 이 필드는 수퍼 프레임 내에서 동적으로 스위칭될 수 있다.
PILOT_MODE: 이 1 비트 필드는 프로파일 모드가 현재의 프레임 그룹 내의 현재의 프레임에 대하여 모바일 모드인지 고정 모드인지를 지시한다. 이 필드가 "0"로 설정되면, 모바일 파일럿 모드가 사용된다. 필드가 "1"로 설정되면, 고정 파일럿 모드가 사용된다.
PAPR_FLAG: 이 1 비트 필드는 PAPR 감소가 현재의 프레임 그룹 내의 현재의 프레임에 사용되는지를 지시한다. 이 필드가 "1"로 설정되면, PAPR 감소에 톤 예약(tone reservation)이 사용된다. 이 필드가 "0"으로 설정되면, PAPR 감소가 사용되지 않는다.
FRU_CONFIGURE: 이 3 비트 필드는 현재의 수퍼 프레임 내에 존재하는 FRU(frame repetition unit)의 PHY 프로파일 타입 구성을 나타낸다. 현재의 수퍼 프레임에서 전달되는 모든 프로파일 타입은 현재의 수퍼 프레임 내의 모든 프레임 내의 이 필드에서 식별된다. 3 비트 필드는 이하의 표 8에 도시된 바와 같이 각 프로파일에 대한 상이한 정의를 갖는다.
현재의 PHY_PROFILE="000" (베이스) 현재의 PHY_PROFILE="001" (핸드헬드) 현재의 PHY_PROFILE="010" (어드밴스드) 현재의 PHY_PROFILE="111" (FET)
FRU_CONFIGURE=000 베이스 프로파일만 존재 핸드헬드 프로파일만 존재 어드밴스드 프로파일만이 존재 FET만이 존재
FRU_CONFIGURE=1XX 핸드헬드 프로파일이 존재 베이스 프로파일이 존재 베이스 프로파일이 존재 베이스 프로파일이 존재
FRU_CONFIGURE=X1X 어드밴스드 프로파일이 존재 어드밴스드 프로파일이 존재 핸드헬드 프로파일이 존재 핸드헬드 프로파일이 존재
FRU_CONFIGURE=XX1 FET가 존재 FET가 존재 FET가 존재 어드밴스드 프로파일이 존재
RESERVED: 이 7 비트 필드가 미래의 사용을 위해 예약된다.
도 13은 본 발명의 실시예에 따른 PLS1 데이터를 나타내는 도면이다.
PLS1 데이터는 PLS2의 수신 및 디코딩을 가능하게 하는데 필요한 파라미터를 포함하는 기본 송신 파라미터를 제공한다. 상술한 바와 같이, PLS1 데이터는 하나의 프레임 그룹의 전체 듀레이션 동안 변경되지 않는다. PLS1 데이터의 시그널링 필드의 상세한 정의는 다음과 같다.
PREAMBLE_DATA: 이 20 비트 필드는 EAC_FLAG를 제외한 프리앰블 시그널링 데이터의 사본이다.
NUM_FRAME_FRU: 이 2 비트 필드는 FRU당 프레임의 수를 나타낸다.
PAYLOAD_TYPE: 이 3 비트 필드는 프레임 그룹에서 전달되는 페이로드 데이터의 포맷을 지시한다. PAYLOAD_TYPE은 표 9에 도시된 바와 같이 시그널링된다.
값 페이로드 타입
1XX TS 스트림이 송신됨
X1X IP 스트림이 송신됨
XX1 GS 스트림이 송신됨
NUM_FSS: 이 2 비트 필드는 현재의 프레임 내의 FSS 심볼의 수를 나타낸다.
SYSTEM_VERSION: 이 8 비트 필드는 송신된 신호 포맷의 버전을 나타낸다. SYSTEM_VERSION은 2개의 4 비트 필드, 즉 메이저 버전 및 마이너 버전으로 분리된다.
메이저 버전: SYSTEM_VERSION 필드의 MSB 4 비트는 메이저 버전 정보를 나타낸다. 메이저 버전 필드의 변화는 비-하위-호환(non-backward-compatible) 변화를 나타낸다. 디폴트 값은 "0000"이다. 이 표준에 기재된 버전에서, 값은 "0000"으로 설정된다.
마이너 버전: SYSTEM_VERSION의 LSB 4 비트는 마이너 버전 정보를 나타낸다. 마이너 버전 필드의 변화는 하위 호환성이다.
CELL_ID: 이것은 ATSC 네트워크에서 지리적인 셀을 고유하게 식별하는 16 비트 필드이다. ATSC 셀 커버리지 영역은 퓨어캐스트 UTB 시스템에 사용되는 주파수의 수에 의존하여 하나 이상의 주파수로 구성될 수 있다. CELL_ID의 값이 알려져 있지 않거나 특정되지 않으면, 이 필드는 "0"으로 설정된다.
NETWORK_ID: 이것은 현재의 ATSC 네트워크를 고유하게 식별하는 16 비트 필드이다.
SYSTEM_ID: 이 16 비트 필드는 ATSC 네트워크 내의 퓨어캐스트 UTB 시스템을 고유하게 식별한다. 퓨어캐스트 UTB 시스템은 입력이 하나 이상의 입력 스트림(TS, IP, GS)이고 출력이 RF 신호인 지상파 방송 시스템이다. 퓨어캐스트 UTB 시스템은 만약 있다면 하나 이상의 PHY 프로파일 및 FET를 전달한다. 동일한 퓨어캐스트 UTB 시스템은 상이한 입력 스트림을 전달할 수 있고 상이한 지리적 영역에서 상이한 RF 주파수를 사용하여 로컬 서비스 삽입을 허용한다. 프레임 구조 및 스케줄링은 하나의 장소에서 제어되고 퓨어캐스트 UTB 시스템 내에서 모든 송신에 대하여 동일하다. 하나 이상의 퓨어캐스트 UTB 시스템은 모두 동일한 물리층 구조 및 구성을 갖는다는 것을 의미하는 동일한 SYSTEM_ID를 가질 수 있다.
다음의 루프는 각 프레임 타입의 FRU 구성 및 길이를 지시하는데 사용되는 FRU_PHY_PROFILE, FRU_FRAME_LENGTH, FRU_GI_FRACTION 및 RESERVED로 구성된다. 루프 사이즈는 고정되어 4개의 PHY 프로파일(FET를 포함)이 FRU 내에서 시그널링된다. NUM_FRAME_FRU가 4보다 작으면, 사용되지 않은 필드는 제로로 채워진다.
FRU_PHY_PROFILE: 이 3 비트 필드는 연관된 FRU의 (i+1)번째 (i는 루프 인덱스이다) 프레임의 PHY 프로파일 타입을 나타낸다. 이 필드는 표 8에 도시된 바와 같이 동일한 시그널링 포맷을 사용한다.
FRU_FRAME_LENGTH: 이 2 비트 필드는 연관된 FRU의 (i+1)번째 프레임의 길이를 나타낸다. FRU_GI_FRACTION과 함께 FRU_FRAME_LENGTH를 이용하여, 프레임 듀레이션의 정확한 값이 얻어질 수 있다.
FRU_GI_FRACTION: 이 3 비트 필드는 연관된 FRU의 (i+1)번째 프레임의 보호 구간 분수 값을 나타낸다. FRU_GI_FRACTION은 표 7에 따라 시그널링된다.
RESERVED: 이 4 비트 필드가 미래의 사용을 위해 예약된다.
다음의 필드는 PLS2 데이터를 디코딩하는 파라미터를 제공한다.
PLS2_FEC_TYPE: 이 2 비트 필드는 PLS2 보호에 의해 사용되는 FEC 타입을 나타낸다. FEC 타입은 표 10에 따라 시그널링된다. LDPC 코드의 세부사항은 후술한다.
콘텐츠 PLS2 FEC 타입
00 4K-1/4 및 7K-3/10 LDPC 코드
01-11 예약
PLS2_MOD: 이 3 비트 필드는 PLS2에 의해 사용되는 변조 타입을 나타낸다. 변조 타입은 표 11에 따라 시그널링된다.
값 PLS2_MODE
000 BPSK
001 QPSK
010 QAM-16
011 NUQ-64
100-111 예약
PLS2_SIZE_CELL: 이 15 비트 필드는 현재의 프레임 그룹에서 전달되는 PLS2에 대한 풀 코딩 블록(full coded blocks)의 모음(collection)의 사이즈(QAM 셀의 수로서 특정됨)(Ctotal_partial_block)를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_STAT_SIZE_BIT: 이 14 비트 필드는 현재의 프레임 그룹에 대한 PLS2-STAT의 비트 사이즈를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_DYN_SIZE_BIT: 이 14 비트 필드는 현재의 프레임 그룹에 대한 PLS2-DYN의 비트 사이즈를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_REP_FLAG: 이 1 비트 플래그는 현재의 프레임 그룹에서 PLS2 반복 모드가 사용되는지를 나타낸다. 이 필드가 값 "1"로 설정되면, PLS2 반복 모드가 활성화된다. 이 필드가 값 "0"으로 설정되면, PLS2 반복 모드가 비활성화된다.
PLS2_REP_SIZE_CELL: 이 15 비트 필드는 PLS2 반복이 사용될 때 현재의 프레임 그룹의 모든 프레임에서 전달되는 PLS2에 대한 부분 코딩 블록(partial coded blocks)의 모음(collection)의 사이즈(QAM 셀의 수로서 특정됨)(Ctotal_partial_block)를 나타낸다. 반복이 사용되지 않으면, 이 필드의 값은 0과 동일하다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_NEXT_FEC_TYPE: 이 2 비트 필드는 다음의 프레임 그룹의 모든 프레임에서 전달되는 PLS2에 사용되는 FEC 타입을 나타낸다. FEC 타입은 표 10에 따라 시그널링된다.
PLS2_NEXT_MOD: 이 3 비트 필드는 다음의 프레임 그룹의 모든 프레임에서 전달되는 PLS2에 사용되는 변조 타입을 나타낸다. 변조 타입은 표 11에 따라 시그널링된다.
PLS2_NEXT_REP_FLAG: 이 1 비트 필드는 다음의 프레임 그룹에서 PLS2 반복 모드가 사용되는지를 나타낸다. 이 필드가 값 "1"로 설정되면, PLS2 반복 모드가 활성화된다. 이 필드가 값 "0"으로 설정되면, PLS2 반복 모드가 비활성화된다.
PLS2_NEXT_REP_SIZE_CELL: 이 15 비트 필드는 PLS2 반복이 사용될 때 다음의 프레임 그룹의 모든 프레임에서 전달되는 PLS2에 대한 풀 코딩 블록(full coded blocks)의 모음(collection)의 사이즈(QAM 셀의 수로서 특정됨)(Ctotal_partial_block)를 나타낸다. 다음의 프레임 그룹에서 반복이 사용되지 않으면, 이 필드의 값은 0과 동일하다. 이 값은 현재의 프레임 그룹에서 일정하다.
PLS2_NEXT_REP_STAT_SIZE_BIT: 이 14 비트 필드는 다음의 프레임 그룹에 대한 PLS2-STAT의 비트 사이즈를 나타낸다. 이 값은 현재의 프레임 그룹에서 일정하다.
PLS2_NEXT_REP_DYN_SIZE_BIT: 이 14 비트 필드는 다음의 프레임 그룹에 대한 PLS2-DYN의 비트 사이즈를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_AP_MODE: 이 2 비트 필드는 현재의 프레임 그룹 내의 PLS2에 추가의 패리티가 제공되는지를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다. 하기의 표 12는 이 필드의 값을 나타낸다. 이 필드가 "00"으로 설정되면, 현재의 프레임에서 PLS2에 대하여 추가의 패리티가 사용되지 않는다.
값 PLS2-AP 모드
00 AP는 제공되지 않음
01 AP1 모드
10-11 예약
PLS2_AP_SIZE_CELL: 이 15 비트 필드는 PLS2의 추가의 패리티 비트의 사이즈(QAM 셀의 수로 특정됨)를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_NEXT_AP_MODE: 이 2 비트 필드는 다음의 프레임 그룹에서 PLS2에 추가의 패리티가 제공되는지를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다. 표 12는 이 필드의 값을 정의한다.
PLS2_NEXT_AP_SIZE_CELL: 이 15 비트 필드는 다음의 프레임 그룹의 모든 프레임에서 PLS2의 추가의 패리티 비트의 사이즈(QAM 셀의 수로 특정됨)를 나타낸다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
RESERVED: 이 32 비트 필드가 미래의 사용을 위해 예약된다.
CRC_32: 전체 PLS1 시그널링에 적용되는 32 비트 에러 검출 코드
도 14는 본 발명의 실시예에 따른 PLS2 데이터를 나타내는 도면이다.
도 14는 PLS2 데이터의 PLS2-STAT 데이터를 나타낸다. PLS2-STAT 데이터는 프레임 그룹 내에서 동일하지만, PLS2-DYN 데이터는 현재의 프레임에 특정된 정보를 제공한다.
PLS2-STAT 데이터의 필드의 세부사항은 다음과 같다.
FIC_FLAG: 이 1 비트 필드는 FIC가 현재의 프레임 그룹에 사용되는지를 나타낸다. 이 필드가 "1"로 설정되면, FIC가 현재의 프레임에서 제공된다. 이 필드가 "0"으로 설정되면, FIC가 현재의 프레임에서 전달되지 않는다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
AUX_FLAG: 이 1 비트 필드는 현재의 프레임 그룹에서 보조 스트림(들)이 사용되는지를 나타낸다. 이 필드가 "1"로 설정되면, 보조 스트림에 현재의 프레임에서 제공된다. 이 필드가 "0"으로 설정되면, 보조 스트림이 현재의 프레임에서 전달되지 않는다. 이 값은 현재의 프레임 그룹의 전체 듀레이션 동안 일정하다.
NUM_DP: 이 6 비트 필드는 현재의 프레임에서 전달되는 DP의 수를 나타낸다. 이 필드의 값은 1 내지 64의 범위 내에 있고 DP의 수는 NUM_DP+1이다.
DP_ID: 이 6 비트 필드는 PHY 프로파일 내에서 DP를 고유하게 식별한다.
DP_TYPE: 이 3 비트 필드는 DP의 타입을 나타낸다. 이것은 이하의 표 13에 따라 시그널링된다.
값 DP 타입
000 DP 타입 1
001 DP 타입 2
010-111 예약
DP_GROUP_ID: 이 8 비트 필드는 현재의 DP가 연관된 DP 그룹을 식별한다. 이것은 수신기가 특정 서비스와 연관된 서비스 컴포넌트의 DP를 액세스하는데 사용될 수 있고, 이들 DP는 동일한 DP_GROUP_ID를 갖는다.
BASE_DP_ID: 이 6 비트 필드는 관리층에서 사용되는 서비스 시그널링 데이터(PSI/SI)를 전달하는 DP를 나타낸다. BASE_DP_ID로 지시된 DP는 서비스 시그널링 데이터만을 전달하는 전용 DP 또는 서비스 데이터와 함께 서비스 시그널링 데이터를 전달하는 정상 DP일 수 있다.
DP_FEC_TYPE: 이 2비트 필드는 연관된 DP에 의해 사용되는 FEC 타입을 나타낸다. FEC 타입은 이하의 표 14에 따라 시그널링된다.
값 FEC_TYPE
00 16K LDPC
01 64K LDPC
10-11 예약
DP_COD: 이 4 비트 필드는 연관된 DP에 의해 사용되는 코드 레이트를 나타낸다. 코드 레이트는 이하의 표 15에 따라 시그널링된다.
값 코드 레이트
0000 5/15
0001 6/15
0010 7/15
0011 8/15
0100 9/15
0101 10/15
0110 11/15
0111 12/15
1000 13/15
1001-111 예약
DP_MOD: 이 4비트 필드는 연관된 DP에 의해 사용되는 변조를 나타낸다. 변조는 이하의 표 16에 따라 시그널링된다.
값 변조
0000 QPSK
0001 QAM-16
0010 NUQ-64
0011 NUQ-256
0100 NUQ-1024
0101 NUC-16
0110 NUC-64
0111 NUC-256
1000 NUC-1024
1001-111 예약
DP_SSD_FLAG: 이 1 비트 필드는 SSD 모드가 연관된 DP 에서 사용되는지를 나타낸다. 이 필드가 값 "1"로 설정되면, SSD가 사용된다. 이 필드가 값 "0"으로 설정되면, SSD가 사용되지 않는다.
PHY_PROFILE이 어드밴스드 프로파일을 나타내는 "010"과 동일한 경우에만 다음의 필드가 나타난다.
DP_MIMO: 이 3 비트 필드는 연관된 DP에 어떤 타입의 MIMO 인코딩 프로세스가 적용되는지를 나타낸다. MIMO 인코딩 프로세스의 타입은 표 17에 따라 시그널링된다.
값 MIMO 인코딩
000 FR-SM
001 FRFD-SM
010-111 예약
DP_TI_TYPE: 이 1 비트 필드는 시간 인터리빙의 타입을 나타낸다. "0"의 값은 하나의 TI 그룹이 하나의 프레임에 대응하고 하나 이상의 TI 블록을 포함하는 것을 나타낸다. "1"의 값은 하나의 TI 그룹이 1보다 많은 프레임에서 전달되고 단 하나의 TI 블록만을 포함하는 것을 나타낸다.
DP_TI_LENGTH: 2 비트 필드의 사용(허용되는 값이 단지 1, 2, 4, 8임)은 다음과 같이 DP_TI_TYPE 필드 내에 설정된 값에 의해 결정된다.
DP_TI_LENGTH가 값 "1"로 설정되면, 이 필드는 PI, 즉, 각 TI 그룹이 맵핑되는 프레임의 수를 나타내고, TI 그룹당 하나의 TI 블록이 있다(NTI=1). 2 비트 필드를 갖는 허용된 PI 값은 이하의 표 18에서 정의된다.
DP_TI_TYPE이 "0"으로 설정되면, 이 필드는 TI 그룹당 TI 블록의 수(NTI)를 나타내고 프레임당 하나의 TI 그룹이 있다(PI=1). 2 비트 필드를 갖는 허용된 PI 값은 이하의 표 18에서 정의된다.
2 비트 필드 PI NTI
00 1 1
01 2 2
10 4 3
11 8 4
DP_FRAME_INTERVAL: 이 2 비트 필드는 연관된 DP에 대한 프레임 그룹 내의 프레인 구간(IJUMP)를 나타내고, 허용되는 값은 1, 2, 4, 8이다(대응하는 2 비트 필드는 각각 "00", "01", "10", "11"이다). 프레임 그룹의 모든 프레임에서 나타나지 않는 DP에 대하여, 이 필드의 값은 연속적인 프레임 간의 간격과 동일하다. 예를 들어, DP가 프레임 1, 5, 9, 13 등에서 나타나면, 이 필드는 "4"로 설정된다. 모든 프레임에서 나타나는 DP에 대하여, 이 필드는 "1"로 설정된다.
DP_TI_BYPASS: 이 1 비트 필드는 시간 인터리버(5050)의 이용가능성을 결정한다. DP에 대하여 시간 인터리빙이 사용되지 않으면, 이는 "1"로 설정된다. 시간 인터리빙이 사용되면, 이는 "0"으로 설정된다.
DP_FIRST_FRAME_IDX: 이 5 비트 필드는 현재 DP 가 발생하는 수퍼 프레임의 제1 프레임의 인덱스를 나타낸다. DP_FIRST_FRAME_IDX의 값은 0 내지 31의 범위 내에 있다.
DP_NUM_BLOCK_MAX: 이 10 비트 필드는 이 DP 에 대하여 DP_NUM_BLOCKS의 최대 값을 나타낸다. 이 필드의 값은 DP_NUM_BLOCKS와 동일한 범위를 갖는다.
DP_PAYLOAD_TYPE: 이 2 비트 필드는 주어진 DP 에 의해 전달되는 페이로드 데이터의 타입을 나타낸다. DP_PAYLOAD_TYPE은 이하의 표 19에 따라 시그널링된다.
값 페이로드 타입
00 TS
01 IP
10 GS
11 예약
DP_INBAND_MODE: 이 2 비트 필드는 현재의 DP 가 인밴드 시그널링 정보를 전달하는지를 나타낸다. 인밴드 시그널링 타입은 이하의 표 20에 따라 시그널링된다.
값 인밴드 모드
00 인밴드 시그널링이 전달되지 않음
01 INBAND-PLS만이 전달됨
10 INBAND-ISSY만이 전달됨
11 INBAND-PLS 및 INBAND-ISSY이 전달됨
DP_PROTOCOL_TYPE: 이 2 비트 필드는 주어진 DP에 의해 전달되는 페이로드의 프로토콜 타입을 나타낸다. 입력 페이로드 타입이 선택되면, 이하의 표 21에 따라 시그널링된다.
값 DP_PAYLOAD_TYPE이 TS인 경우 DP_PAYLOAD_TYPE이 IP인 경우 DP_PAYLOAD_TYPE이 GS인 경우
00 MPEG2-TS IPv4 (주)
01 예약 IPv6 예약
10 예약 예약 예약
11 예약 예약 예약
DP_CRC_MODE: 이 2 비트 필드는 입력 포맷팅 블록에서 CRC 인코딩이 사용되는지를 나타낸다. CRC 모드는 이하의 표 22에 따라 시그널링된다.
값 CRC 모드
00 사용되지 않음
01 CRC-8
10 CRC-16
11 CRC-32
DNP_MODE: 이 2 비트 필드는 DP_PAYLOAD_TYPE이 TS("00")으로 설정될 때 연관된 DP에 의해 사용되는 널-패킷 삭제 모드를 나타낸다. DNP_MODE는 이하의 표 23에 따라 시그널링된다. DP_PAYLOAD_TYPE이 TS("00")가 아니면, DNP_MODE는 값 "00"으로 설정된다.
값 널-패킷 삭제 모드
00 사용되지 않음
01 DNP-NORMAL
10 DNP-OFFSET
11 예약
ISSY_MODE: 이 2 비트 필드는 DP_PAYLOAD_TYPE이 TS("00")으로 설정될 때 연관된 DP에 의해 사용되는 ISSY 모드를 나타낸다. ISSY_MODE는 이하의 표 24에 따라 시그널링된다. DP_PAYLOAD_TYPE이 TS("00")가 아니면, ISSY_MODE는 값 "00"으로 설정된다.
값 ISSY 모드
00 사용되지 않음
01 ISSY-UP
10 ISSY-BBF
11 예약
HC_MODE_TS: 이 2 비트 필드는 DP_PAYLOAD_TYPE이 TS("00")으로 설정될 때 연관된 DP에 의해 사용되는 TS 헤더 압축 모드를 나타낸다. HC_MOD_TS는 이하의 표 25에 따라 시그널링된다.
값 헤더 압축 모드
00 HC_MODE_TS 1
01 HC_MODE_TS 2
10 HC_MODE_TS 3
11 HC_MODE_TS 4
HC_MODE_IP: 이 2 비트 필드는 DP_PAYLOAD_TYPE이 IP ("01")으로 설정될 때의 IP 헤더 압축 모드를 나타낸다. HC_MOD_IP는 이하의 표 26에 따라 시그널링된다.
값 헤더 압축 모드
00 압축하지 않음
01 HC_MODE_IP 1
10-11 예약
PID: 이 13 비트 필드는 DP_PAYLOAD_TYPE이 TS("00")으로 설정되고 HC_MODE_TS가 "01" 또는 "10"으로 설정될 때의 TS 헤더 압축을 위한 PID 번호를 나타낸다.
RESERVED: 이 8 비트 필드는 미래의 사용을 위해 예약된다.
FIC_FLAG가 "1"과 동일한 경우에만 다음의 필드가 나타난다.
FIC_VERSION: 이 8 비트 필드는 FIC의 버전 번호를 나타낸다.
FIC_LENGTH_BYTE: 이 13 비트 필드는 FIC의 바이트 길이를 나타낸다.
RESERVED: 이 8 비트 필드는 미래의 사용을 위해 예약된다.
AUX_FLAG가 "1"과 동일한 경우에만 다음의 필드가 나타난다.
NUM_AUX: 이 4 비트 필드는 보조 스트림의 수를 나타낸다. 제로는 보조 스트림이 사용되지 않는 것을 의미한다.
AUX_CONFIG_RFU: 이 8 비트 필드는 미래의 사용을 위해 예약된다.
AUX_STREAM_TYPE: 이 4 비트 필드는 현재의 보조 스트림의 타입을 나타내기 위한 미래의 사용을 위해 예약된다.
UX_PRIVATE_CONFIG: 이 28 비트 필드는 보조 스트림을 시그널링 하기 위한 미래의 사용을 위해 예약된다.
도 15는 본 발명의 다른 실시예에 따른 PLS2 데이터를 나타내는 도면이다.
도 15는 PLS2 데이터의 PLS2-DYN 데이터를 나타낸다. PLS2-DYN 데이터의 값은 하나의 프레임 그룹의 듀레이션 동안 변할 수 있고, 필드의 사이즈는 일정하게 유지된다.
PLS2-DYN 데이터의 필드의 세부사항은 다음과 같다.
FRAME_INDEX: 이 5 비트 필드는 수퍼 프레임 내의 현재의 프레임의 프레임 인덱스를 나타낸다. 수퍼 프레임의 제1 프레임의 인덱스는 "0"으로 설정된다.
PLS_CHANGE_COUNTER: 이 4 비트 필드는 구성이 변경되기 전의 수퍼 프레임의 수를 나타낸다. 구성에 있어서 변경된 다음의 수퍼 프레임은 이 필드 내에서 시그널링되는 값에 의해 지시된다. 이 필드가 값 "0000"으로 설정되면, 스케줄링된 변화가 예상되지 않은 것을 의미하고, 값 "1"은 다음 수퍼 프레임에서 변화가 있다는 것을 의미한다.
FIC_CHANGE_COUNTER: 이 4 비트 필드는 구성(즉, FIC의 내용)이 변경되기 전의 수퍼 프레임의 수를 나타낸다. 구성에 있어서 변경된 다음의 수퍼 프레임은 이 필드 내에서 시그널링되는 값에 의해 지시된다. 이 필드가 값 "0000"으로 설정되면, 스케줄링된 변화가 예상되지 않은 것을 의미하고, 값 "0001"은 다음 수퍼 프레임에서 변화가 있다는 것을 의미한다.
RESERVED: 이 16 비트 필드는 미래의 사용을 위해 예약된다.
NUM_DP를 통해 루프에서 다음의 필드가 나타나고, 이는 현재의 프레임에서 전달되는 DP와 연관된 파라미터를 나타낸다.
DP_ID: 이 6 비트 필드는 PHY 프로파일 내의 DP를 고유하게 지시한다.
DP_START: 이 15 비트 (또는 13 비트) 필드는 DPU 어드레싱 방식을 이용하여 제1 DP의 시작 위치를 나타낸다. DP_START 필드는 이하의 표 27에 도시된 바와 같이 PHY 프로파일 및 FFT 사이즈에 따라 다른 길이를 갖는다.
PHY 프로파일 DP_START 필드 사이즈
64K 16K
베이스 13 비트 15 비트
핸드헬드 - 13 비트
어드밴스드 13 비트 15 비트
DP_NUM_BLOCK: 이 10 비트 필드는 현재의 DP에 대한 현재의 TI 그룹 내의 FEC 블록의 수를 나타낸다. DP_NUM_BLOCK의 값은 0 내지 1023 범위 내에 있다.
RESERVED: 이 8 비트 필드는 미래의 사용을 위해 예약된다.
다음의 필드는 EAC와 연관된 FIC 파라미터를 나타낸다.
EAC_FLAG: 이 1 비트 필드는 현재의 프레임 내의 EAC의 존대를 나타낸다. 이 비트는 프리앰블 내의 EAC_FLAG와 동일한 값이다.
EAS_WAKE_UP_VERSION_NUM: 이 8 비트 필드는 웨이크업 지시의 버전 번호를 나타낸다.
EAC_FLAG 필드가 "1"과 동일하면, 다음의 12 비트는 EAC_LENGTH_BYTE 필드에 대하여 할당된다. EAC_FLAG 필드가 "0"과 동일하면, 다음의 12 비트는 EAC_COUNTER에 할당된다.
EAC_LENGTH_BYTE: 이 12 비트 필드는 EAC의 바이트 길이를 나타낸다.
EAC_COUNTER: 이 12 비트 필드는 EAC가 도달하는 프레임 전의 프레임의 수를 나타낸다.
AUX_FLAG 필드가 "1"과 동일한 경우에만 다음의 필드가 나타난다.
AUX_PRIVATE_DYN: 이 48 비트 필드는 보조 스트림을 시그널링하기 위한 미래 사용을 위해 예약된다. 이 필드의 의미는 구성가능한 PLS2-STAT 내의 AUX_STREAM_TYPE의 값에 의존한다.
CRC_32: 전체 PLS2에 적용되는 32 비트 에러 검출 코드.
도 16은 본 발명의 실시예에 따른 프레임의 논리 구조를 나타내는 도면이다.
상술한 바와 같이, PLS, EAC, FIC, DP, 보조 스트림 및 더미 셀은 프레임 내의 OFDM 심볼의 액티브 캐리어에 맵핑된다. PLS1 및 PLS2는 먼저 하나 이상의 FSS(들)에 맵핑된다. 그 후, 있다면, EAC 셀이 PLS 필드 직후에 맵핑되고, 그 후, 있다면, FIC 셀이 맵핑된다. 있다면, DP는 PLS 또는 EAC, FIC 후에 맵핑된다. 타입 1 DP가 먼저 뒤따르고 그 후 타입 2 DP가 뒤따른다. DP의 타입의 세부사항은 후술한다. 임의의 경우, DP는 EAS를 위한 임의의 특수 데이터 또는 서비스 시그널링 데이터를 전달할 수 있다. 있다면, 보조 스트림 또는 스트림들이 DP를 뒤따르고, 그 후, 더미 셀이 뒤따른다. 이들 모두를 상술한 순서, 즉, PLS, EAC, FIC, DP, 보조 스트림 및 더미 데이터 셀의 순서로 맵핑하는 것은 프레임 내의 셀 용량을 정확히 채운다.
도 17은 본 발명의 실시예에 따른 PLS 맵핑을 나타내는 도면이다.
PLS 셀은 FSS(들)의 액티브 캐리어에 맵핑된다. PLS에 의해 점유된 셀의 수에 의존하여, 하나 이상의 심볼이 FSS(들)로서 지정되고, FSS(들)의 수(NFSS)는 PLS1 내의 NUM_FSS에 의해 시그널링된다. FSS는 PLS 셀을 전달하는 특수 심볼이다. 강건함 및 레이턴시(latency)는 PLS의 중요한 문제이므로, FSS(들)는 FSS 내의 주파수 전용 보간 및 고속 동기화를 허용하는 더 높은 밀도의 파일럿을 갖는다.
PLS 셀은 도 17의 예에 도시된 바와 같이 탑-다운(top-down) 방식으로 NFSS 개의 FSS(들)의 액티브 캐리어에 맵핑된다. PLS1 셀은 셀 인덱스의 증가 순서로 제1 FSS의 제1 셀로부터 먼저 맵핑된다. PLS2 셀은 PLS1의 마지막 셀 직후에 맵핑되고 제1 FSS의 마지막 셀 인덱스까지 맵핑이 하향으로 계속된다. 요구되는 PLS 셀의 총 수가 하나의 FSS의 액티브 캐리어의 수를 초과하면, 맵핑은 다음의 FSS로 진행하고 제1 FSS와 정확히 동일한 방식으로 계속된다.
PLS 맵핑이 완료된 후, DP가 다음에 전달된다. EAC, FIC 또는 EAC 및 FIC가 현재의 프레임에 존재하면, 이들은 PLS 및 "정상" DP 사이에 배치된다.
도 18은 본 발명의 실시예에 따른 EAC 맵핑을 나타내는 도면이다.
EAC는 EAS 메시지를 전달하는 전용 채널이며 EAS에 대한 DP에 링크된다. EAS 지원은 제공되지만, EAC 자체는 모든 프레임에 존재할 수도 있고 존재하지 않을 수도 있다. 있다면, EAC는 PLS2 셀 직후에 맵핑된다. EAC가 PLS 셀 이외에 FIC, DP, 보조 스트림 또는 더미 셀 중의 어느 것의 후에 오지 않는다. EAC 셀을 맵핑하는 절차는 PLS와 정확히 동일하다.
EAC 셀은 도 18에 도시된 바와 같이 셀 인덱스의 증가 순서로 PLS2의 다음 셀로부터 맵핑된다. EAS 메시지 사이즈에 따라, EAC 셀은 도 18에 도시된 바와 같이 몇 개의 심볼을 점유한다.
EAC 셀은 PLS2의 마지막 셀 직후에 맵핑되고, 맵핑은 마지막 FSS의 마지막 셀 인덱스까지 하향으로 계속된다. 요구되는 EAC의 총수가 마지막 FSS의 나머지 액티브 캐리어의 수를 초과하면, 맵핑은 다음의 심볼로 진행하고 FSS(들)와 정확히 동일한 방식으로 계속된다. 이 경우의 맵핑을 위한 다음 심볼은 정상 데이터 심볼이고, 이는 FSS보다 더 많은 액티브 캐리어를 갖는다.
EAC 맵핑이 완료된 후, 존재한다면, FIC가 다음에 전달된다. (PLS2 필드에서 시그널링됨에 따라) FIC가 송신되지 않으면, DP는 EAC의 마지막 셀 직후에 맵핑된다.
도 19는 본 발명의 실시예에 따른 FIC 맵핑을 나타내는 도면이다.
(a) 는 EAC가 없는 FIC의 예시적인 맵핑을 나타내고 (b)는 EAC가 있는 FIC의 예시적인 맵핑을 나타낸다.
FIC는 고속 서비스 획득 및 채널 스캐닝을 가능하게 하는 계층간(cross-layer) 정보에 대한 전용 채널이다. 이 정보는 주로 각 브로드캐스터의 DP 및 서비스 간의 정보를 결합하는 채널을 포함한다. 고속 스캔을 위하여, 수신기는 FIC를 디코딩하여 브로드캐스터 ID, 서비스의 수 및 BASE_DP_ID 등의 정보를 얻을 수 있다. 고속 서비스 획득을 위해, FIC에 더하여, 베이스 DP가 BASE_DP_ID를 이용하여 디코딩될 수 있다. 전달되는 내용 이외에, 베이스 DP는 정상 DP와 정확히 동일한 방식으로 인코딩되고 프레임에 맵핑된다. 그러므로, 베이스 DP에 대하여 추가의 설명이 요구되지 않는다. FIC 데이터가 생성되어 관리층에서 소비된다. FIC 데이터의 내용은 관리 층 설명서에 기재된 것과 같다.
FIC 데이터는 선택적이고 FIC의 사용은 PLS2의 정적 부분 내의 FIC_FLAG 파라미터에 의해 시그널링된다. FIC가 사용되면, FIC_FLAG가 "1"로 설정되고 FIC를 위한 시그널링 필드는 PLS2의 정적 부분에 정의된다. 이 필드에서는 FIC_VERSION 및 FIC_LENGTH_BYTE가 시그널링된다. FIC는 PLS2와 동일한 변조, 코딩 및 시간 인터리빙 파라미터를 이용한다. FIC는 PLS2_MODE 및 PLS2_FEC 등의 동일한 시그널링 파라미터를 공유한다. 있다면, FIC 데이터는 PLS2 또는 있다면 EAC 직후에 맵핑된다. FIC는 임의의 정상 DP, 보조 스트림 또는 더미 셀 후에 맵핑되지 않는다. FIC 셀을 맵핑하는 방법은 EAC와 정확하게 동일하고, 이는 PLS와 동일하다.
PLS 후에 EAC가 없으면, FIC 셀은 (a)의 예에 도시된 바와 같이 셀 인덱스의 증가 순서로 PLS2의 다음 셀로부터 맵핑된다. FIC 데이터 사이즈에 따라, FIC 셀은 (b)에 도시된 바와 같이 몇 개의 심볼에 걸쳐 맵핑될 수 있다.
FIC 셀은 PLS2의 마지막 셀 직후에 맵핑되고 맵핑은 마지막 FSS의 마지막 셀 인덱스까지 하향으로 계속된다. 요구되는 FIC 셀의 총수가 마지막 FSS의 나머지 액티브 캐리어의 수를 초과하면, 맵핑은 다음 심볼로 진행하고 FSS(들)와 정확히 동일한 방식으로 계속된다. 이 경우의 맵핑을 위한 다음의 심볼은 FSS보다 더 많은 액티브 캐리어를 갖는 정상 데이터 심볼이다.
EAS 메시지가 현재의 프레임에서 송신되면, EAC는 FIC를 앞서고, FIC 셀은 (b) 에 도시된 바와 같이 셀 인덱스의 증가 순서로 EAC의 다음 셀로부터 맵핑된다.
FIC 맵핑이 완료된 후, 하나 이상의 DP가 맵핑되고, 그 후, 있다면, 보조 스트림 및 더미 셀이 맵핑된다.
도 20은 본 발명의 실시예에 따른 DP의 타입을 나타내는 도면이다.
도 20의 (a)는 타입 1 DP를 나타내고 (b)는 타입 2 DP를 나타낸다.
선행 채널, 즉, PLS, EAC 및 FIC가 맵핑된 후, DP의 셀이 맵핑된다. DP는 맵핑 방법에 따라 2개의 타입 중의 하나로 분류된다:
타입 1 DP: DP는 TDM에 의해 맵핑됨
타입 2 DP: DP는 FDM에 의해 맵핑됨
DP의 타입은 PLS2의 정적 부분에서 DP_TYPE 필드에 의해 지시된다. 도 20은 타입 1 DP 및 타입 2 DP의 맵핑 순서를 나타낸다. 타입 1 DP는 먼저 셀 인덱스의 증가 순서로 맵핑되고, 마지막 셀 인덱스에 도달 한 후, 심볼 인덱스가 1씩 증가한다. 다음 실볼 내에서, DP는 p=0로부터 셀 인덱스의 증간 순서로 계속 맵핑된다. 하나의 프레임에서 함께 맵핑된 다수의 DP로, 타입 1 DP의 각각은 DP의 TDM 멀티플렉싱과 유사하게 시간에서 그룹화된다.
타입 2 DP는 먼저 심볼 인덱스의 증가 순서로 맵핑되고, 프레임의 마지막 OFDM 심볼에 도달한 후에, 셀 인덱스는 1씩 증가하고, 심볼 인덱스는 제1 이용가능한 심볼로 밀려나고 그 심볼 인덱스부터 증가한다. 하나의 프레임에서 다수의 DP를 함께 맵핑한 후, 타입 2 DP의 각각은 DP의 FDM 멀티플렉싱과 유사하게 주파수에서 그룹화된다.
하나의 제한이 필요하면, 즉, 타입 1 DP가 항상 타입 2 DP를 앞서면, 타입 1 DP 및 타입 2 DP는 프레임 내에서 공존할 수 있다. 타입 1 및 타입 2 DP를 전달하는 OFDM 셀의 총수는 DP의 송신을 위해 이용가능한 OFDM 셀의 총수를 초과할 수 없다.
Figure 112016052519418-pct00003
여기서, DDP1는 타입 1 DP에 의해 점유되는 OFDM 셀의 수이고, DDP2는 타입 2 DP에 의해 점유되는 OFDM 셀의 수이다. PLS, EAC, FIC는 모두 타입 1 DP와 동일한 방식으로 맵핑되므로, 이들은 모두 "타입 1 맵핑 룰"을 따른다. 그러므로, 타입 1 맵핑은 항상 타입 2 맵핑보다 앞선다.
도 21은 본 발명의 실시예에 따른 DP 맵핑을 나타내는 도면이다.
(a) 는 타입 1 DP를 맵핑하기 위한 OFDM 셀의 어드레싱을 나타내고 (b)는 타입 2 DP를 맵핑하기 위한 OFDM 셀의 어드레싱을 나타낸다.
타입 1 DP(0, DDP1-1)를 맵핑하기 위한 OFDM 셀의 어드레싱은 타입 1 DP의 액티브 데이터 셀을 위해 정의된다. 어드레싱 방식은 타입 1 DP의 각각에 대한 TI로부터의 셀이 액티브 데이터 셀에 할당되는 순서를 정의한다. 이는 또한 PLS2의 동적 부분 내의 DP의 위치를 시그널링하는데 사용된다.
EAC 및 FIC 없이, 어드레스 0는 마지막 FSS 내의 PLS를 전달하는 마지막 셀의 직후의 셀을 지칭한다. EAC가 송신되고 FIC가 그 해당 프레임에서 없으면, 어드레스 0는 EAC를 전달하는 마지막 셀 직후의 셀을 지칭한다. FIC가 해당 프레임에서 송신되면, 어드레스 0는 FIC를 전달하는 마지막 셀 직후의 셀을 지칭한다. 타입 1 DP에 대한 어드레스 0는 (a)에 도시된 바와 같이 2개의 상이한 케이스를 고려하여 산출될 수 있다. (a)에 도시된 예에서, PLS, EAC 및 FIC는 모두 송신되는 것으로 가정한다. EAC 및 FIC 중의 하나 또는 둘다가 생략되는 경우로의 확장은 쉽다. (a)의 좌측에 도시된 바와 같이 FIC까지의 모든 셀을 맵핑한 후에 FSS 내에 나머지 셀이 남아 있다.
타입 2 DP(0, …, DDP2-1)를 맵핑하는 OFDM 셀의 어드레싱은 타입 2 DP의 액티브 데이터 셀을 위해 정의된다. 어드레싱 방식은 타입 2 DP의 각각에 대한 TI로부터의 셀이 액티브 데이터 셀로 할당되는 순서를 정의한다. 이는 또한 PLS2의 동적 부분 내의 DP의 위치를 시그널링하는데 사용된다.
(b)에 도시된 바와 같이 3개의 약간 다른 케이스가 가능하다. (b)의 좌측 상에 도시된 제1 케이스에서는, 마지막 FSS 내의 셀은 타입 2 DP 맵핑에 이용된다. 중간에 도시된 제2 케이스에서는, FIC가 정상 심볼의 셀을 차지하지만, 그 심볼 상의 FIC 셀의 수는 CFSS보다 작다. (b)의 우측에 도시된 제3의 케이스는 그 심볼 상에 맵핑된 FIC 셀의 수가 CFSS를 초과한다는 것을 제외하고 제2 케이스와 동일하다.
PLS, EAC 및 FIC는 타입 1 DP(들)와 동일한 "타입 1 맵핑 규칙"을 따르기 때문에, 타입 1 DP(들)이 타입 2 DP(들)를 앞서는 경우로의 확장은 간단하다.
데이터 파이프 단위(DPU)는 데이터 셀을 프레임 내의 DP로 할당하는 기본 단위이다.
DPU는 프레임 내에 DP를 위치시키는 시그널링 단위로서 정의된다. 셀 맵퍼(7010)는 DP의 각각에 대한 TI에 의해 생성된 셀을 맵핑할 수 있다. 시간 인터리버(5050)는 일련의 TI 블록을 출력하고, 각각의 TI 블록은 셀의 세트로 구성되는 가변 수(variable number)의 XFECBLOCK를 포함한다. XFECBLOCK 내의 셀의 수(Ncells)는 FECBLOCK 사이즈(Nldpc) 및 성상 심볼당 송신 비트수에 의존한다. DPU는 주어진 PHY 프로파일에서 지원되는 XFECBLOCK 내의 셀의 수의 모든 가능한 값의 가장 큰 공통 제수(divisor) (Ncells)로서 정의된다. 셀 내의 DPU의 길이는 LDPU로 정의된다. 각 PHY 프로파일이 FECBLOCK 사이즈 및 성상 심볼 당 상이한 수의 상이한 조합을 지원하기 때문에, LDPU는 PHY 프로파일에 기초하여 정의된다.
도 22는 본 발명의 실시예에 따른 FEC 구조를 나타내는 도면이다.
도 22는 비트 인터리빙 전의 본 발명의 실시예에 따른 FEC 구조를 나타낸다. 상술한 바와 같이, 데이터 FEC 인코더는 입력 BBF에 대하여 FEC 인코딩을 수행하여 아우터 코딩(BCH) 및 이너 코딩(LDPC)을 이용하여 FECBLOCK 절차를 생성할 수 있다. 도시된 FEC 구조는 FECBLOCK에 대응한다. 또한, FECBLOCK 및 FEC 구조는 LDPC 코드워드의 길이에 대응하는 동일한 값을 갖는다.
도 22에 도시된 바와 같이 BCH 인코딩은 각각의 BBF(Kbch 비트)에 적용되고, LDPC 인코딩은 BCH 인코딩 BBF(Kldpc 비트 = Nbch 비트)에 적용된다.
Nldpc의 값은 64800 비트(긴 FECBLOCK) 또는 16200 비트(짧은 FECBLOCK)이다.
이하의 표 28 및 29는 각각 긴 FECBLOCK 및 짧은 FECBLOCK에 대한 FEC 인코딩 파라미터를 나타낸다.
LDPC 레이트 Nldpc Kldpc Kbch BCH 에러 정정 능력 Nbch-Kbch
5/15 64800 21600 21408 12 192
6/15 25920 25728
7/15 30240 30048
8/15 34560 34368
9/15 38880 38688
10/15 43200 43008
11/15 47520 47328
12/15 51840 51648
13/15 56160 55968
LDPC 레이트 Nldpc Kldpc Kbch BCH 에러 정정 능력 Nbch-Kbch
5/15 16200 5400 5232 12 168
6/15 6480 6312
7/15 7560 7392
8/15 8640 8472
9/15 9720 9552
10/15 10800 10632
11/15 11880 11712
12/15 12960 12792
13/15 14040 13872
BCH 인코딩 및 LDPC 인코딩의 동작의 세부사항은 다음과 같다.
12 에러 정정 BCH 코드는 BBF의 아우터 인코딩에 사용된다. 짧은 FECBLOCK 및 긴 FECBLOCK에 대한 BCH 생성기 다항식은 모든 다항식을 함께 곱함으로써 얻어진다.
LDPC 코드는 아우터 BCH 인코딩의 출력을 인코딩하는데 사용된다. 완성된 Bldpc(FECBLOCK)를 생성하기 위하여, Pldpc(패리티 비트)는 각 Ildpc (BCH 인코딩 BBF)로부터 체계적으로 인코딩되고 Ildpc에 첨부된다. 완성된 Bldpc(FECBLOCK)는 다음의 수학식으로 표현된다.
Figure 112016052519418-pct00004
긴 FECBLOCK 및 짧은 FECBLOCK에 대한 파라미터는 각각 상기 표 28 및 29에 주어진다.
긴 FECBLOCK에 대한 Nldpc-Kldpc를 산출하는 세부 절차는 다음과 같다.
1) 패리티 비트 초기화
Figure 112016052519418-pct00005
2) 패리티 체크 매트릭스의 어드레스의 제1 행에 특정된 패리티 비트 어드레스에서 제1 정보 비트(i0)를 누산한다. 패리티 체크 매트릭스의 어드레스의 세부사항은 후술한다. 예를 들어, 레이트 13/15에 대하여,
Figure 112016052519418-pct00006
3) 다음의 359개의 정보 비트(is) (s=1, 2, …, 359)가 다음의 수학식을 이용하여 패리티 비트에서 누산된다.
Figure 112016052519418-pct00007
여기서, x는 제1 비트(i0)에 대응하는 패리티 비트 누산기의 어드레스를 나타내고, Qldpc는 패리티 체크 매트릭스의 어드레스에서 특정된 코드 레이트 종속 상수이다. 계속 예를 들어, 레이트 13/15에 대하여, Qldpc = 24이고, 따라서, 정보 비트(i1)에 대하여, 다음의 동작이 수행된다.
Figure 112016052519418-pct00008
4) 361번째 정보 비트(i360)에 대하여, 패리티 비트 누산기의 어드레스는 패리티 체크 매트릭스의 어드레스의 제2 행에 주어진다. 유사한 방식으로, 다음의 358개의 정보 비트(is) (s=361, 362, …, 719)에 대한 패리티 비트 누산기의 어드레스는 수학식 6을 이용하여 얻어지고, 여기서, x는 정보 비트(i360)에 대응하는 패리티 비트 누산기의 어드레스, 패리티 체크 매트릭스의 어드레스의 제2 행 내의 엔트리를 나타낸다.
5) 유사한 방식으로, 360개의 새로운 정보 비트의 모든 그룹에 대하여, 패리티 체크 매트릭스의 어드레스로부터의 새로운 행이 패리티 비트 누산기의 어드레스를 찾는데 사용된다.
정보 비트의 전부가 소진된 후, 최종 패리티가 다음과 같이 얻어진다.
6) i=1로 시작하는 다음의 동작을 순차적으로 수행한다.
Figure 112016052519418-pct00009
여기서, pi(i=0, 1, …, Ndpc-Kldpc-1)의 최종 내용은 패리티 비트(pi)와 동일하다.
코드 레이트 Qldpc
5/15 120
6/15 108
7/15 96
8/15 84
9/15 72
10/15 60
11/15 48
12/15 36
13/15 24
짧은 FECBLOCK에 대한 이 LDPC 인코딩 절차는 표 30 및 31을 대체하고 긴 FECBLOCK에 대한 패리티 체크 매트릭스의 어드레스를 짧은 FECBLOCK에 대한 패리티 체크 매트릭스의 어드레스로 대체하는 것을 제외하고 긴 FECBLOCK에 대한 t LDPC 인코딩 절차를 따른다.
코드 레이트 Qldpc
5/15 30
6/15 27
7/15 24
8/15 21
9/15 18
10/15 15
11/15 12
12/15 9
13/15 6
도 23은 본 발명의 실시예에 따른 비트 인터리빙을 나타내는 도면이다.
LDPC 인코더의 출력은 비트 인터리빙되고, 이는 패리티 인터리빙 및 그 후의 QCB(quasi-cyclic block) 인터리빙 및 내부 그룹 인터리빙으로 구성된다.
(a) 는 QCB 인터리빙을 나타내고 (b)는 내부 그룹 인터리빙을 나타낸다.
FECBLOCK는 패리티 인터리빙될 수 있다. 패리티 인터리빙의 출력에서, LDPC 코드워드는 긴 FECBLOCK 내의 180개의 인접한 QC 블록 및 짧은 FECBLOCK 내의 180개의 인접한 QC 블록으로 구성된다. 긴 또는 짧은 FECBLOCK 내의 각각의 QC 블록은 360 비트로 구성된다. 패리티 인터리빙된 LDPC 코드워드는 QCB 인터리빙에 의해 인터리빙된다. QCB 인터리빙의 단위는 QC 블록이다. 패리티 인터리빙의 출력에서의 QC 블록은 도 23에 도시된 바와 같이 QCB 인터리빙에 의해 퍼뮤테이션(permutation)되고, 여기서, FECBLOCK 길이에 따라 Ncells=64800/μmod 또는 16200/μmod이다. QCB 인터리빙 패턴은 변조 타입 및 LDPC 코드 레이트의 각 조합에 고유하다.
QCB 인터리빙 후, 내부 그룹 인터리빙은 이하의 표 32에 정의된 변조 타입 및 순서(μmod)에 따라 수행된다. 하나의 내부 그룹에 대한 QC 블록의 수(NQCB _IG)가 또한 정의된다.
변조 타입 μmod NQCB_IG
QAM-16 4 2
NUC-16 4 4
NUQ-64 6 3
NUC-64 6 6
NUQ-256 8 4
NUC-256 8 8
NUQ-1024 10 5
NUC-1024 10 10
내부 그룹 인터리빙 프로세스는 QCB 인터리빙 출력의 NQCB-IG 개의 QC 블록으로 수행된다. 내부 그룹 인터리빙은 360개의 열과 NQCB_IG개의 행을 이용하여 내부 그룹의 비트를 기입 및 판독하는 프로세스를 갖는다. 기입 동작에서, QCB 인터리빙 출력으로부터의 비트가 행방향으로 기입된다. 판독 동작은 열 방향으로 수행되어 각 행으로부터 m개의 비트를 판독하고, 여기서, m은 NUC에 대하여 1과 같고 NCQ에 대하여 2와 동일하다.
도 24는 본 발명의 실시예에 따른 셀-워드 디멀티플렉싱을 나타내는 도면이다.
(a)는 8 및 12 bpcu MIMO에 대한 셀-워드 디멀티플렉싱을 나타내고 (b)는 10 bpcu MIMO에 대한 셀-워드 디멀티플렉싱을 나타낸다.
(a)에 도시된 바와 같이 비트 인터리빙 출력의 각 셀 워드
Figure 112016052519418-pct00010
은
Figure 112016052519418-pct00011
및
Figure 112016052519418-pct00012
로 디멀티플렉싱되고, 이는 하나의 XFECBLOCK에 대한 셀-워드 디멀티플렉싱 프로세스를 나타낸다.
MIMO 인코딩을 위한 상이한 타입의 NUQ를 이용한 10bpcu MIMO 케이스에 대하여, NUQ-1024에 대한 비트 인터리버가 재사용된다. (b)에 도시된 바와 같이 비트 인터리버 출력의 각 셀 워드
Figure 112016052519418-pct00013
는
Figure 112016052519418-pct00014
및
Figure 112016052519418-pct00015
으로 디멀티플렉싱된다.
도 25는 본 발명의 실시예에 따른 시간 인터리빙을 나타내는 도면이다.
(a) 내지 (c)는 TI 모드의 예를 나타낸다.
시간 인터리버는 DP 레벨에서 동작한다. 시간 인터리빙(TI)의 파라미터는 각 DP에 대하여 상이하게 설정될 수 있다.
PlS2-STAT 데이터의 일부에서 나타나는 다음의 파라미터는 TI를 구성한다:
DP_TI_TYPE(허용치: 0 또는 1): TI 모드를 나타냄; "0"은 TI 그룹당 다수의 TI 블록(1보다 많은 TI 블록)을 갖는 모드를 나타낸다. 이 경우, 하나의 TI 그룹은 하나의 프레임에 직접 맵핑된다(인터프레임 인터리빙이 아님). "1"은 TI 그룹당 단 하나의 TI 블록을 갖는 모드를 나타낸다. 이 경우, TI 블록은 1보다 많은 프레임에 확산될 수 있다(인터프레임 인터리빙).
DP_TI_LENGTH: DI_TI_TYPE="0"이면, 이 파라미터는 TI 그룹당 TI 블록의 수(NTI)이다. DP_TI_TYPE="1"에 대하여, 이 파라미터는 하나의 TI 그룹으로부터 확산된 프레임의 수(PI)이다.
DP_NUM_BLOCK_MAX(허용치: 0 내지 1023): TI 그룹당 XFECBLOCK의 최대 수를 나타냄.
DP_FRAME_INTERVAL(허용치: 1, 2, 4, 8): 주어진 PHY 프로파일의 동일 DP를 전달하는 2개의 연속적인 프레임 간의 프레임의 수(IJUMP)를 나타냄.
DP_TI_BYPASS(허용치: 0 또는 1): 시간 인터리빙이 DP에 사용되지 않으면, 이 파라미터는 "1"로 설정된다. 시간 인터리빙이 사용되면, "0"으로 설정된다.
추가적으로, PLS2-DYN 데이터로부터의 파라미터(DP_NUM_BLOCK)는 DP의 하나의 TI 그룹에 의해 전달된 XFECBLOCK의 수를 나타내는데 사용된다.
시간 인터리빙이 DP에 사용되지 않으면, 다음의 TI 그룹, 시간 인터리빙 동작 및 TI 모드는 고려되지 않는다. 그러나, 스케줄러로부터의 동적 구성 정보에 대한 보상 블록은 여전히 필요하다. 각 DP에서, SSD/MIMO 인코딩으로부터 수신된 XFECBLOCK은 TI 그룹으로 그룹핑된다. 즉, 각각의 TI 그룹은 정수의(an integer number of) XFECBLOCK의 세트이고 동적으로 가변하는 수의 XFECBLOCK를 포함한다. 인덱스의 TI 그룹 내의 XFECBLOCK의 수(n)는 NxBLOCK_Group_(n)으로 표시되고 PLS2-DYN 데이터의 DP_NUM_BLOCK로서 시그널링된다. NxBLOCK_Group_(n)는 0의 최소값으로부터 가장 큰값이 1023인 최대 값(NxBLOCK_Group_MAX)(DP_NUM_BLOCK_MAX에 대응)까지 변할 수 있다.
각 TI 그룹은 하나의 프레임에 직접 맵핑되거나 PI 프레임에 걸쳐 확산된다. 각각의 TI 그룹은 또한 1보다 많은 TI 블록(NTI)으로 분리되고, 각각의 TI 블록은 시간 인터리버 메모리의 하나의 용도에 대응한다. TI 그룹 내의 TI 블록은 약간 상이한 수의 XFECBLOCK를 포함할 수 있다. TI 그룹이 다수의 TI 블록으로 분리되면, 단 하나의 프레임에만 직접 맵핑된다. 이하의 표 33에 도시된 바와 같이 (시간 인터리빙을 스킵하는 추가의 옵션을 제외하고) 시간 인터리빙을 위한 3개의 옵션이 존재한다.
모드 설명
옵션 1 각각의 TI 그룹은 하나의 TI 블록을 포함하고 (a)에 도시된 바와 같이 하나의 프레임에 직접 맵핑된다. 이 옵션은 DP_TI_TYPE="0" 및 DP_TI_LENGTH="1"(NTI=1)에 의해 PLS2-STAT에서 시그널링된다.
옵션 2 각각의 TI 그룹은 하나의 TI 블록을 포함하고 1보다 많은 프레임에 맵핑된다. (b)는 하나의 TI 그룹이 2개의 프레임, 즉, DP_TI_LENGTH="2"(PI=2) 및 DP_frame_INTERVAL (IJUMP=2)에 맵핑되는 예를 나타낸다. 이것은 낮은 데이터 레이트 서비스에 더 높은 시간 다이버시티를 제공한다. 이 옵션은 DP_TI_TYPE="1"에 의해 PLS2-STAT에서 시그널링된다.
옵션 3 각각의 TI 그룹은 다수의 TI 블록으로 분리되고 (c)에 도시된 바와 같이 하나의 프레임에 직접 맵핑된다. 각각의 TI 블록은 전체 TI 메모리를 사용하여 DP에 최대 비트 레이트를 제공한다. 이 옵션은 PI=1 동안 DP_TI_TYPE="0" 및 DP_TI_LENGTH=NTI에 의해 PLS2-STAT에서 시그널링된다.
각 DP에서, TI 메모리는 입력 XFECBLOCK(SSD/MIMO 인코딩 블록으로부터의 출력 XFECBLOCK)를 저장한다. 입력 XFECBLOCK은
Figure 112016052519418-pct00016
으로서 정의되고,
여기서, dn,s,r,q는 n번째 TI 그룹의 s번째 TI 블록 내의 r번째 XFECBLOCK의 q번째 셀이고 다음과 같이 SSD 및 MIMO 인코딩의 출력을 나타낸다.
Figure 112016052519418-pct00017
또한, 시간 인터리버로부터의 출력 XFECBLOCK는 다음과 같이 정의되는 것으로 가정한다.
Figure 112016052519418-pct00018
여기서, hn,s,i는 n번째 TI 그룹의 s번째 TI 블록 내의 i번째 출력 셀(
Figure 112016052519418-pct00019
)이다.
일반적으로, 시간 인터리버는 프레임 빌딩 프로세스 전에 DP 데이터를 위한 버퍼로서 동작한다. 이것은 각각의 DP에 대한 2개의 메모리 뱅크에 의해 달성된다. 제1 TI 블록은 제1 뱅크에 기입된다. 제1 뱅크가 판독되는 동안 제2 TI 블록이 제2 뱅크에 기입된다.
TI는 트위스트 행-열 블록 인터리버이다. n번째 TI 그룹의 s번째 TI 블록에 대하여, TI 메모리의 행(Nr)의 수는 셀의 수(Ncell)와 동일하다, 즉, Nr=Ncell이지만, 열의 수(Nc)는 수(NxBLOCK_TI(n,s))와 동일하다.
도 26는 본 발명의 실시예에 따른 트위스트 행-열 블록 인터리버의 기본 동작을 나타내는 도면이다.
(a) 는 시간 인터리버에서의 기입 동작을 나타내고 (b)는 시간 인터리버에서의 판독 동작을 나타낸다. (a)에 도시된 바와 같이 제1 XFECBLOCK는 TI 메모리의 제1 열에 열방향으로 기입되고 제2 XFECBLOCK는 다음 열에 기입된다. 그 후, 인터리빙 어레이에서, 셀은 대각선 방향으로 판독된다. 제1 행(최좌측 열에서 시작하여 행을 따라 오른쪽으로) 마지막행까지 대각선 방향의 판독 동안, (b)에 도시된 바와 같이 셀이 판독된다. 구체적으로, 순차적으로 판독될 TI 메모리 셀 위치로서 Zn,s,i(i=0,,,,,,N,N)를 상정하여, 이러한 인터리빙 어레이에서의 판독 프로세스는 다음의 수학식에서처럼 행 인덱스(Rn,s,i), 열 인덱스(Cn,s,i) 및 연관된 트위스트 파라미터(Tn,s,i)를 산출함으로써 수행된다.
Figure 112016052519418-pct00020
여기서, Sshift는 NxBLOCK_TI(n,s)와 관계없이 대각선 방향 판독 프로세스에 대한 공통 시프트 값이고, 다음의 수학식에서처럼 PLS-STAT에 주어진 NxBLOCK_TI_MAX에 의해 결정된다.
Figure 112016052519418-pct00021
결과적으로, 판독될 셀 위치는 Zn,s,i=NrCn,s,i+Rn,s,i로서 좌표에 의해 산출된다.
도 27은 본 발명의 다른 실시예에 따른 트위스트 행-열 블록 인터리버의 기본 동작을 나타내는 도면이다.
특히, 도 27은 NxBLOCK_TI(0,0)=3, NxBLOCK_TI(1,0)=6, NxBLOCK_TI(2,0)=5일 때 가상 XFECBLOCK를 포함하여 각 TI 그룹에 대한 TI 메모리 내의 인터리빙 어레이를 나타낸다.
가변수(NxBLOCK_TI(n,s)=Nr)는 NxBLOCK_TI_MAX보다 작거나 같다. 따라서, 수신측에서 단일 메모리 디인터리빙을 달성하기 위하여, NxBLOCK_TI(n,s)과 관계없이, 트위스트 행-열 블록 인터리버에 사용되는 인터리빙 어레이는 가상 XFECBLOCK를 TI 메모리에 삽입함으로써 Nr×Nc=Ncells×NxBLOCK _ TI _MAX의 사이즈로 설정되고, 판독 프로세스는 다음의 수학식으로 달성된다.
Figure 112016052519418-pct00022
TI 그룹의 수는 3으로 설정된다. 시간 인터리버의 옵션은 DP_TI_TYPE="0", DP_FRAME_INTERVAL="1" 및 DP_TI_LENGTH="1", 즉, NTI=1, IJUMP=1 및 P1=1에 의해 PLS2-STAT 데이터에서 시그널링된다. TI 그룹당 각각이 Ncells=30를 갖는 XFECBLOCK의 수는 각각 NxBLOCK_TI(0,0)=3, NxBLOCK_TI(1,0)=6, NxBLOCK_TI(2,0)=5에 의해 PLS2-DYN 데이터에서 시그널링된다. XFECBLOCK의 최대수는 NxBLOCK_Group_MAX에 의해 PLS2-STAT 데이터에서 시그널링되고, 이는 다음을 유도한다.
Figure 112016052519418-pct00023
도 28은 본 발명의 실시예에 따른 트위스트 행-열 블록 인터리버의 대각선 방향 판독 패턴을 나타내는 도면이다.
특히, 도 28은 NxBLOCK_TI_MAX =7 및 Sshift=(7-1)/2=3의 파라미터를 갖는 각 인터리빙 어레이로부터의 대각선 방향 판독 패턴을 나타낸다. 상기 의사 코드로서 도시된 판독 프로세스에서, Vi≥NcellsNxBLOCK _ TI(n,s)이면, Vi의 값은 스킵되고 Vi의 다음 산출 값이 사용된다.
도 29은 본 발명의 실시예에 따른 각 인터리빙 어레이로부터의 인터리빙된 XFECBLOCK을 나타내는 도면이다.
도 29은 NxBLOCK_TI_MAX =7 및 Sshift=3의 파라미터를 갖는 각각의 인터리빙 어레이로부터 인터리빙된 XFECBLOCK를 나타낸다.
도 30은 자동 콘텐츠 인식 기반 ETV(enhanced television) 서비스 시스템을 나타낸 도면이다.
도 30에 나타낸 자동 콘텐츠 인식 기반 ETV 서비스 시스템은 방송사 또는 콘텐츠 제공자(100), 다채널 방송사업자(101), 셋톱박스(102), 디지털 TV 수신기 등의 수신기(103), 자동 콘텐츠 인식 서버(또는 자동 콘텐츠 인식 솔루션 제공자)(104)를 포함할 수 있다. 수신기(103)는 ATSC(advanced television system committee)의 정의에 따라 동작할 수 있고, 자동 콘텐츠 인식 기능을 지원할 수 있다. 실시간 방송 서비스(110)는 오디오/비디오 콘텐츠를 포함할 수 있다.
디지털 방송 서비스는 크게 방송사(100)에 의해 제공되는 지상파 방송 서비스와 다채널 방송사업자(101)에 의해 제공되는 케이블 방송 또는 위성 방송 등의 다채널 방송 서비스로 구분될 수 있다. 방송사(100)는 실시간 방송 서비스(110) 및 인헨스먼트 데이터(또는 부가 데이터)(120)를 함께 전송할 수 있다. 이 경우, 도 30에 나타낸 바와 같이, 수신기(103)는 다채널 방송사업자(101) 및 셋톱박스(102)를 통해 실시간 방송 서비스(110)만 수신할 수 있고, 인헨스먼트 데이터(120)는 수신하지 못할 수 있다.
따라서, 인헨스먼트 데이터(120)를 수신하기 위해, 수신기(103)는 오디오/비디오 콘텐츠 출력을 실시간 방송 서비스(110)로 분석 및 처리하고, 방송 프로그램 정보 및/또는 방송 프로그램 관련 메타데이터를 확인한다. 확인된 방송 프로그램 정보 및/또는 방송 프로그램 관련 메타데이터를 이용하여, 수신기(103)는 방송사(100) 또는 자동 콘텐츠 인식 서버(104)로부터 인헨스먼트 데이터를 수신할 수 있다(140). 이 경우, 인헨스먼트 데이터는 인터넷 프로토콜 네트워크(150)를 통해 전송될 수 있다.
인헨스먼트 데이터가 별도의 자동 콘텐츠 인식 서버(104)로부터 수신되면(140), 자동 콘텐츠 인식 서버(104)와 수신기(103) 사이의 메커니즘에서, ATSC 2.0 표준에서 정의한 TDO(triggered declarative object) 모델 중 요청/응답 모델을 자동 콘텐츠 인식 서버(104)에 적용할 수 있다. TDO 및 요청/응답 모델은 후술한다.
TDO는 방송 콘텐츠에 포함된 부가 정보를 나타낸다. TDO는 방송 콘텐츠 내에서 부가 정보를 적시에 트리거링하는 역할을 한다. 예를 들면, 오디오 프로그램이 방송되면, 시청자가 선호하는 오디션 참가자의 현재 순위가 방송 콘텐츠와 함께 표시된다. 이때 오디션 참가자의 현재 순위의 부가 정보는 TDO가 될 수 있다. 이러한 TDO는 시청자와의 상호작용을 통해 변경될 수도 있고, 시청자의 의도에 따라 제공될 수도 있다.
표준 ATSC 2.0의 요청/응답 자동 콘텐츠 인식 모델에서, 디지털 방송 수신기(103)는 주기적으로(예를 들면 5초마다) 콘텐츠의 시그너처(signature)를 생성하고 해당 시그너처를 포함하는 요청을 자동 콘텐츠 인식 서버(104)에 전송하게 되어 있다. 자동 콘텐츠 인식 서버(104)는 디지털 방송 수신기(103)로부터 요청을 받으면 응답을 회신한다. 통신 세션은 요청과 응답 사이에서 개방되지 않는다. 이 모델에서, 자동 콘텐츠 인식 서버(104)는 클라이언트에 대한 메시지를 시작할 수 없다.
디지털 위성방송의 도입에 따라, 디지털 데이터방송이 새로운 부가 서비스로 나타났다. 대표적인 쌍방향 서비스인 쌍방향 데이터방송은 다양한 부가 서비스를 제공하기 위해 데이터 신호뿐만 아니라 기존 방송 신호를 가입자에게 전송할 수 있다.
디지털 데이터방송은 크게 가상 채널을 이용한 독립형 서비스와 ETV를 통한 방송 관련 서비스로 구분될 수 있다. 독립형 서비스는 방송 이미지 신호 없이 텍스트와 그래픽만을 포함하며 기존 인터넷 웹페이지와 유사한 포맷으로 제공된다. 독립형 서비스의 대표적인 예로 날씨 및 주식 정보 제공 서비스, TV 금융 서비스, 상거래 서비스 등을 들 수 있다. 방송 관련 서비스는 방송 이미지 신호뿐만 아니라 부가적인 텍스트 및 그래픽 정보도 전송한다. 시청자는 방송 관련 서비스를 통해 시청한 방송 프로그램에 관련된 정보를 얻을 수 있다. 예를 들면, 시청자가 드라마를 시청하는 동안 이전 스토리나 촬영장소를 볼 수 있게 하는 서비스가 있다.
디지털 데이터방송의 방송 관련 서비스에서는, ETV 서비스가 자동 콘텐츠 인식 기술을 바탕으로 제공될 수 있다. 자동 콘텐츠 인식이란 장치가 오디오/비디오 콘텐츠를 재생할 때 콘텐츠에 숨겨진 정보를 통해 자동으로 콘텐츠를 인식하는 기술을 말한다.
자동 콘텐츠 인식 기술을 시행할 때 콘텐츠에 관한 정보를 얻기 위해 워터마킹(watermarking)이나 핑거프린팅(finger printing) 방식이 이용될 수 있다. 워터마킹은 디지털 콘텐츠 제공자를 나타내는 정보를 디지털 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅은 특정 정보가 디지털 콘텐츠에 삽입되는 점은 워터마킹과 동일하지만, 콘텐츠 제공자에 관한 정보 대신 콘텐츠 구매자에 관한 정보가 삽입되는 점이 워터마킹과 다르다.
도 31는 본 발명의 일 실시예에 따른 디지털 워터마킹 기술의 흐름을 나타낸 도면이다.
디지털 위성방송의 도입에 따라, 디지털 데이터방송이 새로운 부가 서비스로 나타났다. 대표적인 쌍방향 서비스인 쌍방향 데이터방송은 다양한 부가 서비스를 제공하기 위해 데이터 신호뿐만 아니라 기존 방송 신호를 가입자에게 전송할 수 있다.
디지털 데이터방송은 크게 가상 채널을 이용한 독립형 서비스와 ETV를 통한 방송 관련 서비스로 구분될 수 있다. 독립형 서비스는 방송 이미지 신호 없이 텍스트와 그래픽만을 포함하며 기존 인터넷 웹페이지와 유사한 포맷으로 제공된다. 독립형 서비스의 대표적인 예로 날씨 및 주식 정보 제공 서비스, TV 금융 서비스, 상거래 서비스 등을 들 수 있다. 방송 관련 서비스는 방송 이미지 신호뿐만 아니라 부가적인 텍스트 및 그래픽 정보도 전송한다. 시청자는 방송 관련 서비스를 통해 시청한 방송 프로그램에 관련된 정보를 얻을 수 있다. 예를 들면, 시청자가 드라마를 시청하는 동안 이전 스토리나 촬영장소를 볼 수 있게 하는 서비스가 있다.
디지털 데이터방송의 방송 관련 서비스에서는, ETV 서비스가 자동 콘텐츠 인식 기술을 바탕으로 제공될 수 있다. 자동 콘텐츠 인식이란 장치가 오디오/비디오 콘텐츠를 재생할 때 콘텐츠에 숨겨진 정보를 통해 자동으로 콘텐츠를 인식하는 기술을 말한다.
자동 콘텐츠 인식 기술을 시행할 때 콘텐츠에 관한 정보를 얻기 위해 워터마킹이나 핑거프린팅 방식이 이용될 수 있다. 워터마킹은 디지털 콘텐츠 제공자를 나타내는 정보를 디지털 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅은 특정 정보가 디지털 콘텐츠에 삽입되는 점은 워터마킹과 동일하지만, 콘텐츠 제공자에 관한 정보 대신 콘텐츠 구매자에 관한 정보가 삽입되는 점이 워터마킹과 다르다.
이하 도 31와 관련하여 워터마킹 기술에 대해 구체적으로 살펴본다.
디지털 워터마킹은 제거하기 어려운 방식으로 디지털 신호에 정보를 매립하는 과정이다. 예를 들면, 신호는 음성, 화면, 또는 영상 될 수 있다. 신호가 복제되면, 정보도 복제된 신호에 실린다. 하나의 신호는 동시에 여러 다른 워터마크를 실을 수 있다.
시각적 워터마킹에서, 정보는 화면 또는 영상에서 가시적이다. 일반적으로 정보는 미디어의 소유자를 식별하는 텍스트나 로고이다. TV 방송사가 전송되는 영상의 코너에 로고를 추가하면, 이 또한 시각적 워터마크이다.
비시각적 워터마킹에서, 정보는 디지털 데이터로서 음성, 화면, 또는 영상에 추가되는데, 약간의 정보가 숨겨져 있다는 것을 감지할 수 있어도 그 자체가 인지되지는 못한다. 워터마크는 널리 사용되기 위한 것이어서, 검색하기 쉽게 되어있거나, 한 단체가 디지털 신호에 매립된 비밀메시지를 주고받는 스테가노그래피의 형태일 수 있다. 어느 경우이든, 시각적 워터마킹에서와 같이, 목적은 소유주나 다른 서술 정보를 제거하기 어려운 방식으로 신호에 부착하는 것이다. 숨겨진 매립 정보를 개개인 사이의 통신을 전환하기 위한 수단으로 사용할 수도 있다.
워터마킹의 하나의 응용은 디지털 미디어의 비승인 복제를 방지 또는 저지하기 위한 저작권 보호 시스템에 있다. 이 용도에서는, 복제 장치가 복제 전에 신호로부터 워터마크를 검색하고, 워터마크의 콘텐츠에 따라 복제를 할지 결정한다. 또 다른 응용은 소스 추적에 있다.
워터마크는 배포시마다 디지털 신호에 매립된다. 저작물의 복제물이 나중에 발견되면, 워터마크가 복제물로부터 검색될 수 있고, 배포의 소스가 알려진다. 보도에 따르면 이 기술은 불법적으로 복제된 영화의 소스를 알아내기 위해 사용되어 왔다.
서술 정보가 있는 디지털 사진의 어노테이션은 비시각적 워터마킹의 또 다른 응용이다.
디지털 미디어에 대한 파일형식의 일부가 메타데이터라 불리는 부가 정보를 포함할 수 있는 반면, 디지털 워터마킹은 데이터가 신호 자체에서 전달된다는 점에서 구별된다.
일부 문맥에서 디지털 워터마크라는 문구가 워터마킹된 신호와 커버 신호 사이의 차이를 의미하지만, 매립될 정보는 디지털 워터마크라 불린다. 워터마크가 매립될 신호는 호스트 신호라 불린다.
워터마킹 시스템은 주로 매립(201), 공격(202), 검출(또는 추출)(203)의 세 개의 별개의 단계로 구분된다.
매립(201)에서, 알고리즘은 호스트 및 매립될 데이터를 받아들이고, 워터마킹된 신호를 생성한다.
워터마킹된 신호는 전송 또는 저장되는데, 주로 다른 사람에게 전송된다. 이 사람이 변경을 가하면, 이는 공격(202)이라 불린다. 변경이 악의적이지 않을 수도 있지만, 공격이라는 용어는 저작권 침해자들이 변경을 통해 디지털 워터마크를 제거하려는 저작권 보호 어플리케이션으로부터 발생한다. 여러 가지 변경이 가능할 수 있다. 예를 들면, 데이터의 비가역압축, 이미지 또는 영상의 크로핑, 또는 의도적으로 가하는 잡음 등이 있을 수 있다.
검출(203)은 공격받은 신호에서 워터마크를 추출하기 위해 공격받은 신호에 적용되는 알고리즘이다. 신호가 전송 중에 변경되지 않았다면, 워터마크는 여전히 존재하고 추출될 수 있다. 견고한 워터마킹 어플리케이션에서는, 변경이 강력하더라도 추출 알고리즘은 워터마크를 올바르게 생성할 수 있을 것이다. 취약한 워터마킹에서는, 신호에 어떠한 변경이 가해지더라도 추출 알고리즘은 실패할 것이다.
매립된 정보가 몇 번의 변형에 의해 저하되더라도 마킹된 신호로부터 확실히 검출될 수 있으면 디지털 워터마크는 변형에 대해 견고하다고 한다. 전형적인 이미지 저하는 JPEG 압축, 회전(rotation), 크로핑, 부가적인 잡음 및 양자화이다. 비디오 콘텐츠에 있어서, 일시적 변경 및 MPEG 압축이 주로 여기에 포함된다. 워터마킹된 콘텐츠가 원래의 워터마킹되지 않은 콘텐츠와 지각적으로 동등하면 워터마크는 감지할 수 없다고 한다. 일반적으로, 견고한 워터마크나 감지할 수 없는 워터마크는 생성하기 쉽지만, 견고하고 감지할 수 없는 워터마크는 생성하기 어렵다고 알려져 있다. 견고하고 감지할 수 없는 워터마크는 디지털 콘텐츠의 보호를 위한 도구, 예를 들면, 전문적인 비디오 콘텐츠에서 매립된 "복제 불허" 플래그로서 제안되었다.
디지털 워터마킹 기술은 몇 가지 방식으로 분류될 수 있다.
첫째로, 워터마크는 약간의 변형 후에 검출되지 못하면 취약하다고 한다(견고성). 취약한 워터마크는 보통 탬퍼 검출(무결성 입증)을 위해 사용된다. 분명히 뚜렷한 원저작물에 가한 변형은 보통 워터마크라 불리지 않고, 일반화된 바코드라 불린다. 양성 변형에는 저항력이 있지만 악성 변형 후에는 검출에 실패하는 워터마크는 약간 취약하다고 한다. 약간 취약한 워터마크는 보통 악성 변형을 검출하기 위해 사용된다. 지정된 부류의 변형에 저항력이 있는 워터마크는 견고하다고 한다. 견고한 워터마크는 복제물을 전달하고 제어 정보에 접속하기 위해 복제 방지 어플리케이션에서 사용될 수 있다.
둘째로, 원래의 커버 신호와 마킹된 신호가 지각적으로 구별될 수 없으면(구별되기 어려우면) 워터마크는 감지할 수 없다고 한다(지각성). 마킹된 신호에서의 존재가 분명하지만 비침해적이면, 워터마크는 감지할 수 있다고 한다.
셋째로, 용량에 관해서, 매립된 메시지의 길이는 두 가지 다른 주 부류의 워터마킹 방식을 결정한다.
메시지는 개념상으로 0 비트의 길이를 갖고, 시스템은 마킹된 오브젝트에서 워터마크의 존재 유무를 검출하기 위해 설계된다. 이러한 종류의 워터마킹 방식은 주로 이탤릭 0 비트 또는 이탤릭 존재 워터마킹 방식이라 불린다. 종종 이러한 종류의 워터마킹 방식은 1이 워터마크의 존재를 나타내기 때문에(0은 부재) 1 비트 워터마크라 불린다.
메시지는 n 비트 길이의 스트림이고(n = |m| 또는 M = {0,1}n), 워터마크에서 변조된다. 이러한 종류의 방식은 주로 다중비트 워터마킹 또는 비영비트 워터마킹 방식이라 불린다.
넷째로, 매립 단계에는 몇 가지 방식이 있다. 마킹된 신호가 부가적인 변형에 의해 얻어지면 워터마킹 방법은 대역 확산이라 불린다. 대역 확산 워터마크는 적당히 견고하다고 알려져 있지만, 호스트 간섭으로 인해 낮은 정보 용량을 갖는다고 알려져 있기도 하다. 마킹된 신호가 양자화에 의해 얻어지면 워터마킹 방법은 양자화 타입의 것이라고 한다. 양자화 워터마크는 낮은 견고성을 갖지만, 호스트 간섭의 배제로 인해 높은 정보 용량을 갖는다. 마킹된 신호가 대역 확산법과 유사한 부가적인 변형에 의해 매립되지만 특별히 공간 영역에서 매립되면, 워터마킹 방법은 진폭 변조라 불린다.
도 32은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과 포맷을 나타낸 도면이다.
기존의 자동 콘텐츠 인식 서비스 처리 시스템에 따르면, 방송사가 실시간 서비스를 위한 콘텐츠와 ETV 서비스를 위한 인헨스먼트 데이터를 함께 전송하고, TV 수신기가 콘텐츠와 ETV 서비스를 수신하면, 실시간 서비스를 위한 콘텐츠는 수신될 수 있지만, 인헨스먼트 데이터는 수신되지 못한다.
이 경우, 본 발명의 일 실시예에 따르면, 인터넷 프로토콜 네트워크를 이용한 독립적인 인터넷 프로토콜 시그널링 채널을 통해 기존의 자동 콘텐츠 인식 처리 시스템의 문제를 해결할 수 있다. 즉, TV 수신기는 다채널 방송사업자를 통해 실시간 서비스를 위한 콘텐츠를 수신할 수 있고, 독립적인 인터넷 프로토콜 시그널링 채널을 통해 인헨스먼트 데이터를 수신할 수 있다.
이 경우, 본 발명의 일 실시예에 따르면, 인터넷 프로토콜 시그널링 채널은 PSIP 스트림이 바이너리 스트림의 형태로 전달 및 처리되도록 구성된다. 이때, 인터넷 프로토콜 시그널링 채널은 풀(pull) 방법이나 푸시(push) 방법을 이용하도록 구성된다.
풀 방법의 인터넷 프로토콜 시그널링 채널은 HTTP 요청/응답 방법에 따라 구성될 수 있다. HTTP 요청/응답 방법에 따르면, PSIP 바이너리 스트림은 HTTP 요청 신호에 대한 HTTP 응답 신호에 포함될 수 있고, SignalingChannelURL을 통해 전송될 수 있다. 이 경우, 폴링 사이클은 자동 콘텐츠 인식 쿼리 결과로서 전달된 메타데이터에서 Polling_cycle에 따라 주기적으로 요청될 수 있다. 또한, 갱신될 시간 및/또는 주기에 관련된 정보는 시그널링 채널에 포함되어 전송될 수 있다. 이 경우, 수신기는 인터넷 프로토콜 시그널링 채널로부터 수신한 갱신 시간 및/또는 주기 정보에 근거하여 서버에 시그널링 정보를 요청할 수 있다.
푸시 방법의 인터넷 프로토콜 시그널링 채널은 XMLHTTPRequest 어플리케이션 프로그래밍 인터페이스를 이용하여 구성될 수 있다. XMLHTTPRequest 어플리케이션 프로그래밍 인터페이스가 이용되면, 서버로부터 비동기로 최신 정보를 수신할 수 있다. 이는 수신기 측에서는 XMLHTTPRequest 오브젝트를 통해 서버에게 비주기적으로 시그널링 정보를 요청하는 방법이고, 서버 측에서는 시그널링 정보가 변경되었으면 요청에 응답하여 이 채널을 통해 시그널링 정보를 제공하는 방법이다. 세션의 대기시간에 제한이 있으면, 세션 타임아웃 응답이 생성될 수 있고, 수신기는 세션 타임아웃 응답을 인식하고, 시그널링 정보를 다시 요청하고, 수신기와 서버 사이에서 시그널링 채널을 유지할 수 있다.
인터넷 프로토콜 시그널링 채널을 통해 인헨스먼트 데이터를 수신하기 위해, 수신기는 워터마킹과 핑거프린팅을 이용하여 동작할 수 있다. 핑거프린팅은 콘텐츠 구매자에 관한 정보를 콘텐츠 제공자 대신 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅이 이용되면, 수신기는 콘텐츠를 확인하기 위해 참조 데이터베이스를 검색할 수 있다. 콘텐츠를 확인한 결과는 자동 콘텐츠 인식 쿼리 결과라 불린다. 자동 콘텐츠 인식 쿼리 결과는 TV 시청자에게 제공된 쿼리를 포함하고, 자동 콘텐츠 인식 기능을 실행하기 위해 쿼리의 정보에 대해 대응할 수 있다. 수신기는 자동 콘텐츠 인식 쿼리 결과에 근거하여 ETV 서비스를 제공할 수 있다.
자동 콘텐츠 인식 쿼리 결과에 관한 정보는 워터마크 기반 자동 콘텐츠 인식 시스템 상에서 오디오/비디오 콘텐츠에 삽입/매립되어 전송될 수 있다. 수신기는 워터마크 추출기를 통해 자동 콘텐츠 인식 쿼리 결과 정보를 추출 및 획득한 후, ETV 서비스를 제공할 수 있다. 이 경우, ETV 서비스는 별도의 자동 콘텐츠 인식 서버 없이 제공될 수 있고, 인터넷 프로토콜 네트워크를 통한 쿼리는 생략될 수 있다.
도 32은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과를 나타내는 XML 스키마의 도면이다. 도 32에 나타낸 바와 같이, 자동 콘텐츠 인식 쿼리 결과의 XML 포맷은 결과 코드부(310)를 포함할 수 있고, 자동 콘텐츠 인식 쿼리 결과 타입(300)은 콘텐츠 식별자부(301), NTP(network time protocol) 타임스탬프부(302), 시그널링 채널 정보부(303), 서비스 정보부(304), 기타 식별자부(305)를 포함할 수 있다. 시그널링 채널 정보부(303)는 시그널링 채널 URL부(313), 갱신모드부(323), 폴링 사이클부(333)를 포함할 수 있고, 서비스 정보부(304)는 서비스 네임부(314), 서비스 로고부(324), 서비스 서술부(334)를 포함할 수 있다.
이후, 도 32에 나타낸 자동 콘텐츠 인식 쿼리 결과의 XML 스키마의 도면을 상세히 설명하고, XML 스키마의 예를 설명한다.
결과 코드부(310)는 자동 콘텐츠 인식 쿼리의 결과값을 나타낼 수 있다. 이는 쿼리 성공 또는 실패, 쿼리가 실패하면 실패 이유를 코드값의 형태로 나타낼 수 있다. 예를 들면, 결과 코드부(310)의 값이 200이면, 이는 쿼리가 성공하고 그에 해당하는 콘텐츠 정보가 응답되었다는 것을 나타낸다. 결과 코드부(310)의 값이 404이면, 이는 콘텐츠가 발견되지 않았다는 것을 나타낸다.
콘텐츠 식별자부(301)는 전 세계적으로 유일하게 콘텐츠를 식별하기 위한 식별자를 나타내고, 서비스를 식별하기 위한 식별자인 글로벌 서비스 식별자부를 포함할 수 있다.
NTP 타임스탬프부(302)는 자동 콘텐츠 인식 쿼리에 사용되는 샘플 프레임 간격의 특정 시점이 NTP 타임스탬프의 형태로 제공된다는 것을 나타낼 수 있다. 여기서, 특정 시점은 샘플 프레임의 시점 또는 종점일 수 있다. NTP란 인터넷을 통해 컴퓨터의 시간을 레퍼런스 클록에 맞추기 위한 프로토콜을 말하며, 타임 서버와 컴퓨터 네트워크 상에 분배된 클라이언트 사이의 시간 동기화를 위해 사용될 수 있다. NTP가 UTC(universal time coordinated) 시간을 사용하고 10 ms의 정확도를 보장하기 때문에, 수신기는 프레임 동기화 동작을 정확히 처리할 수 있다.
시그널링 채널 정보부(303)는 ETV 서비스를 위한 인터넷 프로토콜 네트워크 상의 독립적인 시그널링 채널의 액세스 정보를 나타낼 수 있다.
더 구체적으로, 시그널링 채널 정보부(303)의 하위부인 시그널링 채널 URL부(313)는 시그널링 채널의 URL 정보를 나타낼 수 있다. 시그널링 채널 URL부(313)는 갱신모드부(323) 및 폴링 사이클부(333)를 하위부로 포함할 수 있다. 갱신모드부(323)는 인터넷 프로토콜 시그널링 채널을 통해 정보를 획득하는 방법을 나타낸다. 예를 들면, 풀 모드에서 수신기는 정보를 획득하기 위해 풀 방법에 따라 주기적으로 폴링을 수행할 수 있고, 푸시 모드에서 서버는 푸시 방법에 따라 수신기에 정보를 송신할 수 있다. 폴링 사이클부(333)는 갱신모드부(323)가 풀 모드이면 풀 방법에 따라 수신기의 기본 폴링 사이클값을 나타낼 수 있다. 그리고 수신기는 기본 폴링 사이클값을 특정하고 임의 시간 간격으로 요청 신호를 서버에 전송하여, 서버가 요청으로 과부하되는 것을 방지할 수 있다.
서비스 정보부(304)는 방송 채널에 관한 정보를 나타낼 수 있다. 콘텐츠 식별자부(301)는 시청자에 의해 현재 시청되고 있는 서비스의 식별자를 나타낼 수 있고, 서비스 정보부(304)는 방송 채널에 관한 구체적인 정보를 나타낼 수 있다. 예를 들면, 서비스 정보부(304)가 나타내는 구체적인 정보는 채널명, 로고, 또는 텍스트 설명일 수 있다.
더 구체적으로, 서비스 정보부(304)의 하위부인 서비스 네임부(314)는 채널명을 나타낼 수 있고, 서비스 로고부(324)는 채널 로고를 나타낼 수 있고, 서비스 서술부(334)는 채널 텍스트 설명을 나타낼 수 있다.
다음은 본 발명의 일 실시예에 따른 도 32에 나타낸 자동 콘텐츠 인식 쿼리 결과의 엘리먼트(element)의 XML 스키마를 나타낸다.
<xs:complexType name="ACR-ResultType">
<xs:sequence>
<xs:element name="ContentID" type="xs:anyURI"/>
<xs:element name="NTPTimestamp" type="xs:unsignedLong"/>
<xs:element name="SignalingChannelInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="SignalingChannelURL" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="UpdateMode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Pull"/>
<xs:enumeration value="Push"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="PollingCycle" type="xs:unsignedInt"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ServiceInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="ServiceName" type="xs:string"/>
<xs:element name="ServiceLogo" type="xs:anyURI" minOccurs="0"/>
<xs:element name="ServiceDescription" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ResultCode" type="xs:string" use="required"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
도 33는 본 발명의 일 실시예에 따른 콘텐츠 식별자의 구문을 나타낸 도면이다.
도 33는 본 발명의 일 실시예에 따른 ATSC 표준에 따른 콘텐츠 식별자의 구문을 나타낸다. ATSC 콘텐츠 식별자는 수신기에 의해 수신한 콘텐츠를 식별하기 위한 식별자로 사용될 수 있다.
또한 도 33에 도시된 콘텐츠 식별자의 구문은 도 32에서 설명한 자동 콘텐츠 인식 질의 결과 포맷의 콘텐츠 식별자부의 구문이다.
ATSC 콘텐츠 식별자는 유일한 주기를 갖고 TSID(Transmitting Subscriber Identification) 및 하우스 넘버로 구성된 구문이다. 하우스 넘버는 여기에 제약된 바와 같이 TSID의 보유자가 원하는 어떤 넘버이다. 넘버는 TSID의 각각의 값에 대해 유일하다. ATSC 콘텐츠 식별자 구조의 구문은 도 40에 정의된 바와 같다.
16 비트의 무부호 정수 필드인 TSID는 transport_stream_id의 값을 포함할 것이다. 미국에서 이 값의 할당 권한은 FCC에 있다. 멕시코, 캐나다, 미국에 대한 범위는 이들 국가 사이의 공식 협약에 의해 설정되었다. 다른 지역의 값은 임의의 권한에 의해 설정된다.
5 비트의 무부호 정수인 end_of_day 필드는 방송일이 종료되는 UTC에서 그 날의 시간으로 설정될 것이며, 잠시 후 content_id 값들이 unique_for에 따라 재사용될 수 있다. 이 필드의 값은 0 내지 23의 범위에 있을 것이다. 이때, 이 필드의 값은 방송사마다 고정될 것으로 예상된다.
9 비트의 무부호 정수인 unique_for 필드는 일수로 설정되고 끝수 올림되고 content_id 값이 다른 콘텐츠에 재할당되지 않는 end_of_day가 나타내는 시간에 관해서 측정된다. 그 값은 1 내지 511의 범위에 있을 것이다. 0은 금지될 것이다. 511은 "무기한"의 특별한 의미가 있다. 이때, 이 필드의 값은 하우스 넘버링 방법이 변경될 때만 변경되고 방송사마다 본질적으로 고정될 것으로 예상된다. 또한, 디코더는 unique_for 필드가 만료될 때까지 저장된 content_values를 유일한 것으로 취급할 수 있고, 이는 저장된 모든 unique_for 필드가 0이 될 때까지 end_of_day에 매일 1씩 감소시킴으로써 실행될 수 있다.
가변 길이 필드인 content_id 필드는 하우스 넘버 시스템이나 TSID의 값을 위한 시스템에 따라 식별자의 값으로 설정될 수 있다. 이러한 각 값은 end_of_day 및 unique_for 필드의 값에 의해 설정된 유일 기간 내에서 다른 콘텐츠로 할당될 수 없다. 해당 식별자는 사람이 판독할 수 있고/있거나 2진 값의 어떠한 조합이 될 수 있고, 242 바이트를 넘지 않도록 하우스 넘버의 형태와 완벽히 일치할 필요는 없다.
또한 본 발명의 일 실시예에 따른 수신기가 도 33에 도시된 콘텐츠 식별자의 구문을 통해 서비스를 전세계적으로 유일하게 식별하지 못할 경우, 본 발명의 일 실시예에수신기는 글로벌 서비스 식별자를 이용하여 서비스를 식별할 수 있다. 본 발명의 일 실시예에 따른 글로벌 서비스 식별자는 도 32에서 설명한 자동 콘텐츠 인식 질의 결과 포맷의 콘텐츠 식별자부에 포함될 수 있다.
이하 [예시 1]은 본 발명의 일 실시예에 따른 URI 포맷의 글로벌 서비스 식별자를 나타낸다. [예시 1]의 글로벌 서비스 식별자는 ATSC-M/H 서비스를 위해 사용될 수 있다.
[예시 1] urn:oma:bcast:iauth:atsc:service:<region>:<xsid>:<serviceid>
<region>은 ISO 639-2에 의해 특정된 바와 같은 2글자 국제 국가 코드이다.
<xsid>는 해당 지역에서 정의된 바와 같이 로컬 서비스에 대해서는 TSID의 10진 인코딩으로 정의된다. <xsid>는 지역 서비스에 대해서는 (major > 69), "0"로 정의된다.
<serviceid>는 <major>.<minor>로 정의된다. 여기서 <major>는 주채널 넘버를 나타낼 수 있고, <minor>는 부채널 넘버를 나타낼 수 있다.
상술한 글로벌 서비스 식별자는 다음과 같은 URI 포맷으로 표현될 수 있다.
[예시 2] urn:oma:bcast:iauth:atsc:service:us:1234:5.1
[예시 3] urn:oma:bcast:iauth:atsc:service:us:0:100.200
또한, 본 발명의 일 실시예에 따른 수신기는 상술한 글로벌 서비스 식별자에 기반하여, 글로벌 콘텐츠 식별자를 이용하여 콘텐츠를 식별할 수 있다.
이하 [예시 4]는 본 발명의 일 실시예에 따른 URI 포맷의 글로벌 콘텐츠 식별자를 나타낸다. [예시 4]의 글로벌 서비스 식별자는 ATSC 서비스를 위해 사용될 수 있다. 구체적으로, [예시 4]는 본 발명의 일 실시예에 따른 글로벌 콘텐츠 식별자로서 ATSC 콘텐츠 식별자가 사용된 경우를 나타낸다.
[예시4]
urn:oma:bcast:iauth:atsc:content:<region>:<xsidz>:<contentid>:<unique_for>:<end_of_day>
<region>은 ISO 639-2 [4]에 의해 특정된 바와 같은 2글자 국제 국가 코드이다.
<xsidz>는 해당 지역에서 정의된 바와 같이 로컬 서비스에 대해서는 TSID의 10진 인코딩으로 정의된다. 여기에는 방출하는 방송사가 <serviceid>를 사용하지 않고 글로벌 콘텐츠 식별자의 유일성을 보장할 수 없는 한 "."<serviceid>가 뒤따른다. <xsidz>는 지역 서비스에 대해서는 (major > 69), <serviceid>로 정의된다.
두 경우에서, <serviceid>는 섹션 A1에서 콘텐츠를 전달하는 서비스에 대해 정의된 바와 같다. <content_id>는 content_id 필드를 2진 스트링으로 고려한 도 33에서 정의한 content_id 필드의 base64 [5] 인코딩이다. <unique_for>는 도 33에서 정의한 unique_for 필드의 10진 인코딩이다. <end_of_day>는 도 33에서 정의한 end_of_day 필드의 십진 인코딩이다.
상술한 예시들을 통해 정의된 포맷을 가진 ATSC 콘텐츠 식별자는, 자동 콘텐츠 인식 처리 시스템 상에서 컨텐트를 식별하기 위해 사용될 수 있다.
이하 본 발명의 일 실시예에 따른 도 34 및 도 35과 관련하여 워터마킹 및 핑거프린팅 기술을 구현할 수 있도록 설계된 수신기를 살펴본다. 도 34 및 도 35은 설계자의 의도에 따라 다르게 구성될 수 있다.
도 34는 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
구체적으로, 도 34는 워터마킹을 이용하여 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기의 구성의 일례를 나타낸다.
도 34에 나타낸 바와 같이, 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기는 입력 데이터 프로세서, ATSC 메인 서비스 프로세서, ATSC MH(mobile handheld) 서비스 프로세서, 및/또는 자동 콘텐츠 인식 서비스 프로세서를 포함할 수 있다. 입력 데이터 프로세서는 튜너/복조기(400) 및/또는 잔류 측파대 디코더(401)를 포함할 수 있다. ATSC 메인 서비스 프로세서는 트랜스포트 프로토콜(TP) 디멀티플렉서(402), 비실시간 가이드 정보 프로세서(403), DSM-CC(digital storage media command and control) 주소 지정 가능 섹션 파서(404), IP/UDP(information provider/user datagram protocol) 파서(405), FLUTE(file delivery over unidirectional transport) 파서(406), 메타데이터 모듈(407), 파일 모듈(408), ESG(electronic service guide)/DCD(data carrier detect) 핸들러(409), 저장 제어 모듈(410), 파일/트랜스포트 프로토콜 스위치(411), 재생 제어 모듈(412), 제1 저장 장치(413), 인터넷 프로토콜 패킷 저장 제어 모듈(414), 인터넷 접속 제어 모듈(415), 인터넷 프로토콜 인터페이스(416), 라이브 레코딩 스위치(417), 파일(오브젝트) 디코더(418), 트랜스포트 프로토콜/PES(packetized elementary stream) 디코더(420), PSI(program specific information)/PSIP(program and system information protocol) 디코더(421), 및/또는 EPG(electronic program guide) 핸들러(422)를 포함할 수 있다. ATSC MH 서비스 프로세서는 메인/MH/비실시간 스위치(419), MH 베이스밴드 프로세서(423), MH 물리적 적응 프로세서(424), 인터넷 프로토콜 스택(425), 파일 핸들러(426), ESG 핸들러(427), 제2 저장 장치(428), 및/또는 스트리밍 핸들러(429)를 포함할 수 있다. 자동 콘텐츠 인식 서비스 프로세서는 메인/MH/비실시간 스위치(419), 오디오/비디오 디코더(430), 오디오/비디오 처리 모듈(431), 외부 입력 핸들러(432), 워터마크 추출기(433), 및/또는 어플리케이션(434)을 포함할 수 있다.
이후, 각 프로세서의 각 모듈의 동작을 설명한다.
입력 데이터 프로세서에서, 튜너/복조기(400)는 안테나로부터 수신한 방송 신호를 튜닝 및 복조할 수 있다. 이 과정을 통해, 잔류 측파대 심볼이 추출될 수 있다. 잔류 측파대 디코더(401)는 튜너/복조기(400)에 의해 추출된 잔류 측파대 심볼을 디코딩할 수 있다.
잔류 측파대 디코더(401)는 디코딩에 따른 ATSC 메인 서비스 데이터 및 MH 서비스 데이터를 출력할 수 있다. ATSC 메인 서비스 데이터는 ATSC 메인 서비스 프로세서로 전달되어 처리될 수 있고, MH 서비스 데이터는 ATSC MH 서비스 프로세서로 전달되어 처리될 수 있다.
ATSC 메인 서비스 프로세서는 MH 신호를 제외한 메인 서비스 데이터를 자동 콘텐츠 인식 서비스 프로세서에 전달하기 위해 메인 서비스 신호를 처리할 수 있다. 트랜스포트 프로토콜 디멀티플렉서(402)는 잔류 측파대 신호를 통해 전송된 ATSC 메인 서비스 데이터의 전송 패킷을 역다중화하여 다른 처리 모듈에 전달할 수 있다. 즉, 트랜스포트 프로토콜 디멀티플렉서(402)는 방송 신호의 엘리먼트들이 각각 방송 수신기의 모듈에 의해 처리되도록 전송 패킷에 포함된 다양한 정보를 역다중화하여 전달할 수 있다. 역다중화된 데이터는 실시간 스트림, DSM-CC 주소 지정 가능 섹션, 및/또는 비실시간 서비스 테이블/A/90&92 시그널링 테이블을 포함할 수 있다. 더 구체적으로, 도 34에 나타낸 바와 같이, 트랜스포트 프로토콜 디멀티플렉서(402)는 실시간 스트림을 라이브 레코딩 스위치(417)로 출력할 수 있고, DSM-CC 주소 지정 가능 섹션을 DSM-CC 주소 지정 가능 섹션 파서(404)로 출력할 수 있고, 비실시간 서비스 테이블/A/90&92 시그널링 테이블을 비실시간 가이드 정보 프로세서(403)로 출력할 수 있다.
비실시간 가이드 정보 프로세서(403)는 트랜스포트 프로토콜 디멀티플렉서(402)로부터 비실시간 서비스 테이블/A/90&92 시그널링 테이블을 수신하고, FLUT 세션 정보를 추출하여 DSM-CC 주소 지정 가능 섹션 파서(404)로 전달할 수 있다. DSM-CC 주소 지정 가능 섹션 파서(404)는 트랜스포트 프로토콜 디멀티플렉서(402)로부터 DSM-CC 주소 지정 가능 섹션을 수신하고, 비실시간 가이드 정보 프로세서(403)로부터 FLUT 세션 정보를 수신하고, DSM-CC 주소 지정 가능 섹션을 처리할 수 있다. IP/UDP 파서(405)는 DSM-CC 주소 지정 가능 섹션 파서(404)로부터 데이터 출력을 수신하고, IP/UDP에 따라 전송된 IP 데이터그램을 파싱할 수 있다. FLUTE 파서(406)는 IP/UDP 파서(405)로부터 출력된 데이터를 수신하고, ALC (asynchronous layered coding) 오브젝트의 형태로 전송된 데이터 서비스를 전송하기 위한 FLUTE 데이터를 처리할 수 있다. 메타데이터 모듈(407) 및 파일 모듈(408)은 FLUTE 파서(406)로부터 출력된 데이터를 수신하고, 메타데이터 및 복원된 파일을 처리할 수 있다. ESG/DCD 핸들러(409)는 메타데이터 모듈(407)로부터 출력된 데이터를 수신하고, 방송 프로그램에 관련된 전자서비스 가이드 및/또는 하향링크 채널 기술어를 처리할 수 있다. 복구된 파일은 레퍼런스 핑거프린트 및 ATSC 2.0 콘텐츠와 같은 파일 오브젝트의 형태로 저장 제어 모듈(410)로 전달될 수 있다. 파일 오브젝트는 저장 제어 모듈(410)에 의해 처리되고, 정상 파일 및 트랜스포트 프로토콜 파일로 분리되어 제1 저장 장치(413)에 저장될 수 있다. 재생 제어 모듈(412)은 저장된 파일 오브젝트를 갱신하고 파일 오브젝트를 파일/트랜스포트 프로토콜 스위치(411)에 전달하여 정상 파일 및 트랜스포트 프로토콜 파일을 디코딩할 수 있다. 파일/트랜스포트 프로토콜 스위치(411)는 정상 파일 및 트랜스포트 프로토콜 파일이 서로 다른 경로를 통해 디코딩되도록 정상 파일은 파일 디코더(418)로 전달하고 트랜스포트 프로토콜 파일은 라이브 레코딩 스위치(417)로 전달한다.
파일 디코더(418)는 정상 파일을 디코딩하여 자동 콘텐츠 인식 서비스 프로세서로 전달할 수 있다. 디코딩된 정상 파일은 자동 콘텐츠 인식 서비스 프로세서의 메인/MH/비실시간 스위치(419)로 전달될 수 있다. 트랜스포트 프로토콜 파일은 라이브 레코딩 스위치(417)의 제어 하에 트랜스포트 프로토콜/PES 디코더(420)로 전달될 수 있다. 트랜스포트 프로토콜/PES 디코더(420)는 트랜스포트 프로토콜 파일을 디코딩하고, PSI/PSIP 디코더(421)는 디코딩된 트랜스포트 프로토콜 파일을 다시 디코딩한다. EPG 핸들러(422)는 디코딩된 트랜스포트 프로토콜 파일을 처리하고, ATSC에 따라 EPG 서비스를 처리할 수 있다.
ATSC MH 서비스 프로세서는 ATSC MH 서비스 데이터를 자동 콘텐츠 인식 서비스 프로세서에 전송하기 위해 MH 신호를 처리할 수 있다. 더 구체적으로, MH 베이스밴드 프로세서(423)는 ATSC MH 서비스 데이터를 전송에 적합한 펄스 파형으로 전환할 수 있다. MH 물리적 적응 프로세서(424)는 ATSC MH 서비스 데이터를 MH 물리적 계층에 적합한 형태로 처리할 수 있다.
인터넷 프로토콜 스택(425)은 MH 물리적 적응 프로세서(424)로부터 출력된 데이터를 수신하여 인터넷 전송/수신을 위한 통신 프로토콜에 따라 처리할 수 있다. 파일 핸들러(426)는 인터넷 프로토콜 스택(425)으로부터 출력된 데이터를 수신하고 응용 계층의 파일을 처리할 수 있다. ESG 핸들러(427)는 파일 핸들러(426)로부터 출력된 데이터를 수신하고 모바일 ESG를 처리할 수 있다. 또한, 제2 저장 장치(428)는 파일 핸들러(426)로부터 출력된 데이터를 수신하고, 파일 오브젝트를 저장할 수 있다. 또한, 인터넷 프로토콜 스택 모듈(425)로부터 출력된 데이터의 일부는 ATSC에 따른 모바일 ESG 서비스 대신 수신기의 자동 콘텐츠 인식 서비스를 위한 데이터가 될 수 있다. 이 경우, 스트리밍 핸들러(429)는 RTP(real-time transport protocol)을 통해 수신된 리얼 스트리밍을 처리하여 자동 콘텐츠 인식 서비스 프로세서에 전달할 수 있다.
자동 콘텐츠 인식 서비스 프로세서의 메인/MH/비실시간 스위치(419)는 ATSC 메인 서비스 프로세서 및/또는 ATSC MH 서비스 프로세서로부터 출력된 신호를 수신할 수 있다. 오디오/비디오 디코더(430)는 메인/MH/비실시간 스위치(419)로부터 수신된 압축 오디오/비디오 데이터를 디코딩할 수 있다. 디코딩된 오디오/비디오 데이터는 오디오/비디오 처리 모듈(431)에 전달될 수 있다.
외부 입력 핸들러(432)는 외부 입력을 통해 수신된 오디오/비디오 콘텐츠를 처리하여 오디오/비디오 처리 모듈(431)에 전송할 수 있다.
오디오/비디오 처리 모듈(431)은 오디오/비디오 디코더(430) 및/또는 외부 입력 핸들러(432)로부터 수신된 오디오/비디오 데이터를 처리하여 스크린에 표시할 수 있다. 이 경우, 워터마크 추출기(433)는 오디오/비디오 데이터로부터 워터마크의 형태로 삽입된 데이터를 추출할 수 있다. 추출된 워터마크 데이터는 어플리케이션(434)에 전달될 수 있다. 어플리케이션(434)은 자동 콘텐츠 인식 기능에 근거한 인헨스먼트 서비스를 제공하고, 방송 콘텐츠를 확인하고, 거기에 관련된 인헨스먼트 데이터를 제공할 수 있다. 어플리케이션(434)이 인헨스먼트 데이터를 오디오/비디오 처리 모듈(431)에 전달하면, 오디오/비디오 처리 모듈(431)은 수신한 오디오/비디오 데이터를 처리하여 화면에 표시할 수 있다.
구체적으로, 도 34에 도시된 워터마크 추출기(433)는 외부 입력으로 수신된 오디오/비디오 데이터로부터 워터마크의 형태로 삽입된 데이터(또는 워터마크)를 추출할 수 있다. 워터마크 추출기(433)는 오디오 데이터로부터 워터마크를 추출하거나, 비디오 데이터로부터 워터마크를 추출하거나, 오디오 데이터 및 비디오 데이터로부터 워터마크를 추출할 수 있다. 워터마크 추출기(433)는 추출된 워터마크로부터 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
본 발명의 일 실시예에 따른 수신기는 워터마크 추출기(433)가 획득한 채널 정보 및/또는 콘텐츠 정보를 이용하여, ATSC MH 채널을 튜닝하고 해당 콘텐츠 및/또는 메타데이터를 수신할 수 있다. 또한 본 발명의 일 실시예에 따른 수신기는 인터넷망을 통해 해당 콘텐츠 및/또는 메타데이터를 수신할 수도 있다. 이후에 수신기는 트리거 등을 이용하여 수신된 콘텐츠 및/또는 메타데이터를 디스플레이할 수 있다.
도 35은 본 발명의 또 다른 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
더 구체적으로, 도 35은 워터마킹을 이용하여 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기의 구성의 일례를 나타낸다.
도 35에 도시된 본 발명의 일 실시예에 따른 수신기의 기본 구조는 도 34에 도시된 수신기에 기본 구조와 동일하다. 다만, 도 35에 도시된 수신기는 본 발명의 일 실시예에 따라 핑거프린트 추출기(535) 및/또는 핑거프린트 비교기(536)를 더 포함할 수 있다는 차이점이 있다. 또한, 도 35에 도시된 수신기는 도 34에 도시된 구성 엘리먼트 중 워터마크 추출기(433)를 포함하지 않을 수 있다.
도 35의 기본적인 구성은 도 34에 도시된 수신기의 기본적인 구성과 동일하므로 설명을 생략한다. 이하 핑거프린트 추출기(535) 및/또는 핑거프린트 비교기(536)를 중심으로 수신기의 동작을 설명한다.
핑거프린트 추출기(535)은 외부 입력으로 수신된 A/V 콘텐츠에 삽입된 데이터(또는 시그니쳐; signature)를 추출할 수 있다. 본 발명의 일 실시예에 따른 핑거프린트 추출기(535)는 오디오 콘텐츠로부터 시그니쳐를 추출하거나, 비디오 콘텐츠로부터 시그니쳐를 추출하거나, 또는 오디오 콘텐츠 및 비디오 콘텐츠로부터 시그니쳐를 추출할 수 있다.
핑거프린트 비교기(536)는 A/V 콘텐츠에서 추출된 시그니쳐를 이용하여 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다. 본 발명의 일 실시예에 따른 핑거프린트 비교기(536)는 로컬 서치(local search) 및/또는 원격 서치(remote search)를 통해 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
구체적으로 도 35에 도시된 바와 같이, 핑거프린트 비교기(536)가 저장 장치(537)에 엑세스하여 동작하는 루트를 로컬 서치라 한다. 또한 도 35에 도시된 바와 같이, 핑거프린트 비교기(536)가 인터넷 접속 제어 모듈(538)에 엑세스하여 동작하는 루트를 원격 서치라 한다. 이하 로컬 서치 및 원격 서치에 대해 설명한다.
본 발명의 일 실시예에 따른 로컬 서치에 따르면, 핑거프린트 비교기(535)는 추출된 시그니쳐와 저장 장치(537)에 저장되어 있던 기준 핑거프린트를 비교할 수 있다. 기준 핑거프린트는 핑거프린트 비교기(536)가 추출된 시그니쳐를 처리하기 위해 추가적으로 수신하는 데이터이다.
구체적으로, 핑거프린트 비교기(536)는 추출된 시그니쳐와 기준 핑거프린트를 매칭하여 동일한지 여부를 비교하여 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
비교 결과, 추출된 시그니쳐와 기준 핑거프린트가 동일한 경우, 핑거프린트 비교기(536)는 비교 결과를 어플리케이션으로 전달할 수 있다. 어플리케이션은 비교 결과를 이용하여 추출된 시그니쳐와 관련된 채널 정보 및/또는 콘텐츠 정보를 수신기로 전달할 수 있다.
비교 결과, 추출된 시그니쳐와 기준 핑거프린트가 매칭되지 않거나 기준 핑거프린트가 부족한 경우, 핑거프린트 비교기(536)는 ATSC MH 채널을 통해 새로운 기준 핑거프린트를 수신할 수 있다. 이후에 핑거프린트 비교기(536)는 추출된 시그니쳐와 기준 핑거프린트를 다시 비교할 수 있다.
또한 본 발명의 일 실시예에 따른 원격 서치에 따르면, 핑거프린트 비교기(536)는 인터넷 상의 시그너처 데이터베이서 서버로부터 채널 정보 및/또는 콘텐츠 정보를 수신할 수 있다.
구체적으로, 핑거프린트 비교기(536)는 인터넷 접속 제어 모듈(538)을 통해 인터넷 망에 접속하여 시그너처 데이터베이서 서버에 엑세스할 수 있다. 이후에 핑거프린트 비교기(536)는 추출된 시그니쳐를 쿼리 파라미터로서 시그너처 데이터베이서 서버로 전달할 수 있다.
모든 방송국들이 하나의 통합된 시그너처 데이터베이서 서버를 이용할 경우, 핑거프린트 비교기(536)는 해당 시그너처 데이터베이서 서버로 쿼리 파라미터를 전달할 수 있다. 방송국들이 개별적으로 시그너처 데이터베이서 서버를 운영할 경우, 핑거프린트 비교기(536)는 각각의 시그너처 데이터베이스로 쿼리 파라미터를 전달할 수 있다. 또는 핑거프린트 비교기(536)는 둘 이상의 시그너처 데이터베이서 서버에 동시에 쿼리 파라미터를 전달할 수도 있다.
본 발명의 일 실시예에 따른 수신기는 핑거프린트 비교기(536)가 획득한 채널 정보 및/또는 콘텐츠 정보를 이용하여, ATSC M/H 채널을 튜닝하고 해당 콘텐츠 및/또는 메타데이터를 수신할 수 있다. 이후에 수신기는 트리거 등을 이용하여 수신된 콘텐츠 및/또는 메타데이터를 디스플레이할 수 있다.
도 36은 본 발명의 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
구체적으로, 도 36은 퍼스널라이제이션 서비스(개인화 서비스)를 위한 디지털 방송 수신기(또는 수신기)를 포함하는 개인화 방송 시스템을 나타낸다. 본 발명의 일 실시예에 따른 개인화 서비스는 사용자 정보를 기반으로 사용자에게 적합한 콘텐츠를 선별하여 제공하는 서비스이다. 또한 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 혹은 개인화된 서비스를 제공하는 차세대 방송 서비스를 제공할 수 있다.
본 발명에서는 사용자 정보의 일 실시예로서, 사용자의 프로파일, 인구통계 및 흥미 정보(또는 PDI 데이터)를 정의한다. 이하에서는 개인화 방송 시스템의 구성 엘리먼트들에 대해 설명한다.
설문지에 대한 답변(answer)은 종합하면 사용자의 프로파일, 인구통계, 흥미(PDI; profiles, demographics, and interests)를 나타낸다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지 또는 PDI 테이블이라 불린다. 데이터 구조는 사용 가능할 때 답변을 포함할 수 있지만, PDI 테이블은 네트워크, 방송사, 또는 콘텐츠 제공자에 의해 제공되므로 답변 데이터를 포함하지 않는다. PDI 테이블에서 엔트리의 질문(question) 부분은 비공식적으로 "PDI-질문" 또는 "PDI-Q"라 불린다. 주어진 PDI 질문에 대한 답변은 비공식적으로 "PDI-A"라 불린다. 필터 기준의 집합은 비공식적으로 "PDI-FC"라 불린다.
ATSC 2.0 가능 수신기와 같은 클라이언트 장치는 설문지에서 질문에 대한 답변의 생성을 가능하게 하는 기능을 포함한다 (PDI-A 경우). 이 PDI 생성 기능은 PDI-Q 경우를 입력으로 사용하고 PDI-A 경우를 출력으로 생성한다. PDI-Q 경우 및 PDI-A 경우 모두 수신기의 비휘발성 기억 장치에 저장된다. 클라이언트는 PDI-A 경우와 PDI-FC 경우를 비교하여 어느 콘텐츠 아이템이 다운로드 및 사용에 적합할 지 결정하는 필터링 기능을 제공한다.
나타낸 바와 같이 서비스 제공자 측에서는, PDI 테이블을 유지 및 분배하기 위한 기능이 시행된다. 콘텐츠와 함께 콘텐츠 메타데이터가 생성된다. 메타데이터 중 일부가 PDI 테이블에서 질문에 근거한 PDI-FC 경우이다.
도 36에 도시된 바와 같이 개인화 방송 시스템은 콘텐츠 제공자(또는 방송사; 707) 및/또는 수신기(700)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기(700)는 PDI 엔진(701), 필터링 엔진(702), PDI 기억 장치(703), 콘텐츠 기억 장치(704), 선언 콘텐츠 모듈(705) 및/또는 UI 모듈(User Interface module; 706)을 포함할 수 있다. 또한 도 36에 도시된 바와 같이 본 발명의 일 실시예에 따른 수신기(700)는 콘텐츠 제공자(707)로부터 콘텐츠 등을 수신할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
본 발명의 일 실시예에 따른 콘텐츠 제공자(707)는 콘텐츠, PDI 설문지(PDI 설문지) 및/또는 필터링 기준을 수신기(700)로 전송할 수 있다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지라 불린다. 본 발명의 일 실시예에 따른 PDI 설문지는, 사용자의 프로파일, 인구통계, 흥미 등에 관한 질문(또는 PDI 질문)들을 포함할 수 있다.
수신기(700)는 콘텐츠 제공자(707)로부터 수신한 콘텐츠, PDI 설문지 및/또는 필터링 기준을 처리할 수 있다. 이하 도 36에 도시된 수신기(700)에 포함된 모듈들의 동작을 중심으로 설명한다.
본 발명의 일 실시예에 따른 PDI 엔진(701)은 먼저 콘텐츠 제공자(707)가 제공하는 PDI 설문지를 수신할 수 있다. PDI 엔진(701)은 수신한 PDI 설문지에 포함된 PDI 질문을 UI(706)로 전달할 수 있다. 해당 PDI 질문에 관한 사용자의 입력이 있을 경우, PDI 엔진(701)은 해당 PDI 질문에 대한 사용자의 답변과 기타 정보(이하, PDI 답변)들을 UI(706)로부터 수신할 수 있다. 이후에 PDI 엔진(701)은 개인화 서비스를 제공하기 위해 PDI 질문들 및 PDI 답변들을 처리하여 PDI 데이터를 생성할 수 있다. 즉, 본 발명의 일 실시예에 따른 PDI 데이터는 상술한 PDI 질문들 및/또는 PDI 답변들을 포함할 수 있다. 따라서, PDI 설문지에 대한 PID 답변은 종합하면 사용자의 프로파일, 인구통계, 흥미(또는 PDI)를 나타낸다.
또한, 본 발명의 일 실시예에 따른 PDI 엔진(701)은 수신한 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있다. 구체적으로 PDI 엔진(701)은 PDI 답변의 ID를 이용하여 PDI 데이터를 삭제, 추가 및/또는 수정할 수 있다. 본 발명의 일 실시예에 따른 PDI 답변의 ID의 구체적인 내용은 후술한다. 또한 다른 모듈에서 PDI 데이터의 수신을 요청하는 경우, PDI 엔진(701)은 해당 요청에 적합한 PDI 데이터를 해당 모듈에 전달할 수 있다.
본 발명의 일 실시예에 따른 필터링 엔진(702)은 PDI 데이터와 필터링 기준에 따라 콘텐츠를 필터링할 수 있다. 필터링 기준은 PDI 데이터를 이용하여 사용자에게 적합한 콘텐츠만을 필터링하기 위한 기준(필터링 기준)들의 집합을 의미한다. 구체적으로, 필터링 엔진(702)은 PDI 엔진(701)으로부터 PDI 데이터를 수신할 수 있고, 콘텐츠 제공자(707)로부터 콘텐츠 및/또는 필터링 기준을 수신할 수 있다. 또한 콘텐츠 제공자(707)는 선언 콘텐츠에 관한 파라미터를 전송할 때, 해당 선언 콘텐츠와 연관된 필터링 기준 테이블을 함께 전송할 수 있다. 이후에 필터링 엔진(702)은 필터링 기준과 PDI 데이터를 매칭시켜 비교하고, 비교 결과를 이용하여 콘텐츠를 필터링하여 다운로드할 수 있다. 다운로드한 콘텐츠는 콘텐츠 기억 장치(704)에 저장될 수 있다. 필터링 방법 및 필터링 기준에 대한 구체적인 내용은 도 38 및 도 39과 관련하여 후술한다.
본 발명의 일 실시예에 따른 UI 모듈(706)은 PDI 엔진(701)로부터 수신한 PDI 질문을 디스플레이하고, 해당 PDI 질문에 대해 사용자로부터 PDI 답변을 수신할 수 있다. 사용자는 디스플레이된 PDI 질문에 대해 리모컨을 이용하여 PDI 답변을 수신기(700)측으로 전달할 수 있다. UI 모듈(706)은 수신한 PDI 답변을 PDI 엔진(701)로 전달할 수 있다.
본 발명의 일 실시예에 따른 선언 콘텐츠 모듈(705)은 PDI 엔진(701)에 엑세스하여 PDI 데이터를 획득할 수 있다. 또한 도 36에 도시된 바와 같이, 선언 콘텐츠 모듈(705)은 콘텐츠 제공자(707)가 제공하는 선언 콘텐츠를 수신할 수 있다. 본 발명의 일 실시예에 따른 선언 콘텐츠는 수신기(700)에서 실행되는 어플리케이션에 관한 콘텐츠로서, TDO와 같은 DO를 포함할 수 있다.
또한 도 36에는 도시되지 않았으나, 본 발명의 일 실시예에 따른 선언 콘텐츠 모듈(705)은 PDI 기억 장치(703)에 엑세스하여 PDI 질문 및/또는 PDI 답변을 획득할 수도 있다. 이 경우 선언 콘텐츠 모듈(705)은 API(Application Programming Interface)를 이용할 수 있다. 구체적으로, 선언 콘텐츠 모듈(705)은 API를 이용하여 PDI 기억 장치(703)을 검색(retrieve)함으로써 적어도 하나 이상의 PDI 질문을 획득할 수 있다. 이후에 선언 콘텐츠 모듈(705)은 UI 모듈(706)을 통해 PDI 질문을 전달하거나 PDI 답변을 수신하고, 수신한 PDI 답변을 PDI 기억 장치(703)로 전달할 수 있다.
본 발명의 일 실시예에 따른 PDI 기억 장치(703)은 PDI 질문 및/또는 PDI 답변을 저장할 수 있다.
본 발명의 일 실시예에 따른 콘텐츠 기억 장치(704)는 필터링된 콘텐츠를 저장할 수 있다.
상술한 바와 같이, 도 36에 도시된 PDI 엔진(701)은 콘텐츠 제공자(707)로부터 PDI 설문지(Questionnaire)를 수신할 수 있다. 수신기(700)는 UI 모듈(706)을 통해 수신한 PDI 설문지의 PDI 질문을 디스플레이하고, 해당 PDI 질문에 대한 PDI 답변을 사용자로부터 수신할 수 있다. PDI 엔진(701)은 PDI 질문 및/또는 PDI 답변을 포함한 PDI 데이터를 필터링 엔진(702)로 전달할 수 있다. 필터링 엔진(702)은 PDI 데이터와 필터링 기준을 통해 콘텐츠를 필터링할 수 있다. 따라서 수신기(700)는 필터링된 콘텐츠를 사용자에게 제공함으로써 개인화 서비스를 구현할 수 있다.
도 37은 본 발명의 다른 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
구체적으로, 도 37은 개인화 서비스를 위한 수신기를 포함하는 개인화 방송 시스템의 구조를 나타낸 것이다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 이하에서는 개인화 방송 시스템의 구성 엘리먼트들에 대해 설명한다.
도 37에 도시된 바와 같이 개인화 방송 시스템은 콘텐츠 제공자(또는 방송국; 807) 및/또는 수신기(700)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기(800)는 PDI 엔진(801), 필터링 엔진(802), PDI 기억 장치(803), 콘텐츠 기억 장치(804), 선언 콘텐츠 모듈(805), UI 모듈(806), 사용 모니터링 엔진(808) 및/또는 사용 로그 모듈(809)을 포함할 수 있다. 또한 도 36에 도시된 바와 같이 본 발명의 일 실시예에 따른 수신기는 콘텐츠 제공자(807)로부터 콘텐츠 등을 수신할 수 있다. 도 37의 기본적인 모듈들은 도 36의 모듈들과 동일하며, 다만 도 36의 방송 시스템과는 달리 도 37의 방송 시스템은 사용 모니터링 엔진(808) 및/또는 사용 로그 모듈(809)을 더 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 사용 모니터링 엔진(808) 및 사용 로그 모듈(809)을 중심으로 설명한다.
본 발명의 일 실시예에 따른 사용 로그 모듈(809)은 사용자의 방송 서비스 사용 내역에 대한 정보(또는 히스토리 정보)를 저장할 수 있다. 히스토리 정보는 2 이상의 사용 데이터를 포함할 수 있다. 본 발명의 일 실시예에 따른 사용 데이터는 일정 시간 동안 사용자가 어떤 방송 서비스를 이용하였는지에 관한 정보를 의미한다. 구체적으로, 사용 데이터는 오후 9시에 뉴스를 40분간 시청했다는 정보, 오후 11시에 공포 영화를 다운로드했다는 정보 등을 포함할 수 있다.
본 발명의 일 실시예에 따른 사용 모니터링 엔진(808)은 사용자의 방송 서비스 사용 현황을 지속적으로 모니터링할 수 있다. 이후에 사용 모니터링 엔진(808)은 모니터링 결과를 이용하여 사용 로그 모듈(809)에 저장된 사용 데이터를 삭제, 추가 및/또는 수정할 수 있다. 또한 본 발명의 일 실시예에 따른 사용 모니터링 엔진(808)은 사용 데이터를 PDI 엔진(801)로 전달할 수 있으며, PDI 엔진(801)은 전달된 사용 데이터를 이용하여 PDI 데이터를 갱신할 수 있다.
도 38는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 38는, 도 36 및 도 37에서 설명한 개인화 방송 시스템의 필터링 엔진 및 PDI 엔진의 동작을 나타낸 플로우 차트이다.
도 38에 도시된 바와 같이, 본 발명의 일 실시예에 따른 수신기(900)는 필터링 엔진(901) 및/또는 PDI 엔진(902)을 포함할 수 있다. 이하 본 발명의 일 실시예에 따른 필터링 엔진(901) 및 PDI 엔진(902)의 동작을 설명한다. 상술한 수신기의 구조는 설계자의 의도에 따라 달라질 수 있다.
도 36에서 설명한 바와 같이, 콘텐츠를 필터링하기 위해, 본 발명의 일 실시예에 따른 수신기(900)는 필터링 기준과 PDI 데이터를 매칭시켜 비교할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 필터링 엔진(901)은 콘텐츠 제공자로부터 필터링 기준을 수신하고, PDI 엔진(902)에 PDI 데이터를 요청하는 신호(또는 PDI 데이터 요청 신호)를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(902)은 전달된 PDI 데이터 요청 신호에 따라, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색할 수 있다.
도 38에 도시된 필터링 엔진(901)은 기준 ID(identifier)를 포함하는 PDI 데이터 요청 신호를 PDI 엔진(902)으로 전달할 수 있다. 상술한 바와 같이 필터링 기준은 필터링 기준들의 집합으로서, 각각의 필터링 기준은 필터링 기준을 식별하기 위한 기준 ID를 포함할 수 있다. 또한 본 발명의 일 실시예에 따른 기준 ID는 PDI 질문 및/또는 PDI 답변을 식별하기 위해 사용될 수 있다.
PDI 데이터 요청 신호를 수신한 PDI 엔진(902)은 PDI 기억 장치에 엑세스하여 PDI 데이터를 검색할 수 있다. 본 발명의 일 실시예에 따른 PDI 데이터는 PDI 질문 및/또는 PDI 답변을 식별하기 위한 PDI 데이터 ID를 포함할 수 있다. 도 38에 도시된 PDI 엔진(902)은 기준 ID와 PDI 데이터 ID를 매칭시켜 기준 ID와 PDI 데이터 ID가 동일한지 여부를 비교할 수 있다.
매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하고, 이에 대한 값이 동일한 경우, 수신기(900)는 해당 콘텐츠를 다운로드할 수 있다. 구체적으로, 본 발명의 일 실시예에 따른 필터링 엔진(901)은 콘텐츠를 다운로드하기 위한 다운로드 요청 신호를 콘텐츠 제공자에게 전달할 수 있다.
매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하지 않은 경우, 도 38에 도시된 바와 같이 PDI 엔진(902)은 필터링 엔진(901)으로 널(null) ID(identifier)를 전달할 수 있다. 널 ID를 수신한 필터링 엔진(901)은 새로운 PDI 데이터 요청 신호를 PDI 엔진(902)으로 전달할 수 있다. 이 경우 새로운 PDI 데이터 요청 신호는 새로운 기준 ID를 포함할 수 있다.
본 발명의 일 실시예에 따른 수신기(900)는, 상술한 방법에 따라 필터링 기준에 포함된 모든 필터링 기준과 PDI 데이터를 매칭시킬 수 있다. 매칭 결과, 모든 필터링 기준이 PDI 데이터와 매칭되는 경우, 필터링 엔진(901)은 콘텐츠를 다운로드하기 위한 다운로드 요청 신호를 콘텐츠 제공자에게 전달할 수 있다.
도 39은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 39은, 도 36 및 도 37에서 설명한 개인화 방송 시스템의 필터링 엔진 및 PDI 엔진의 동작을 나타낸 플로우 차트이다.
도 39에 도시된 바와 같이, 본 발명의 일 실시예에 따른 수신기(1000)는 필터링 엔진(1001) 및/또는 PDI 엔진(1002)를 포함할 수 있다. 상술한 수신기의 구조는 설계자의 의도에 따라 달라질 수 있다. 도 39에 도시된 필터링 엔진(1001) 및 PDI 엔진(1002)의 기본적인 동작은 도 38에서 설명한 바와 같다.
다만, 필터링 기준과 PDI 데이터의 매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하지 않은 경우, 도 39에 도시된 수신기(1000)는 해당 콘텐츠를 다운로드하지 않는 것을 일 실시예로 할 수 있다.
구체적으로, 본 발명의 필터링 엔진(1001)은 널 ID를 수신할 경우, 새로운 PDI 데이터 요청 신호를 PDI 엔진(1002)에 전달하지 않는 것을 일 실시예로 할 수 있다. 또한 필터링 기준에 포함된 모든 필터링 기준이 PDI 데이터와 매칭되지 않을 경우, 본 발명의 필터링 엔진(1001)은 다운로드 요청 신호를 콘텐츠 제공자에게 전달하지 않는 것을 일 실시예로 할 수 있다.
도 40은 본 발명의 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
상술한 도 36의 개인화 방송 시스템은 개인화 서비스를 제공하기 위해 PDI 데이터를 사용하며, PDI 데이터는 PDI 테이블 형식으로 처리될 수 있다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지 또는 PDI 테이블이라 불린다. 데이터 구조는 사용 가능할 때 답변을 포함할 수 있지만, PDI 테이블은 네트워크, 방송사, 또는 콘텐츠 제공자에 의해 제공되므로 답변 데이터를 포함하지 않는다. PDI 테이블에서 엔트리의 질문 부분은 비공식적으로 "PDI-질문" 또는 "PDI-Q"라 불린다. 주어진 PDI 질문에 대한 답변은 비공식적으로 "PDI-A"라 불린다. 필터 기준의 집합은 비공식적으로 "PDI-FC"라 불린다. 본 발명의 PDI 테이블은 XML 스키마로 표현되는 것을 일 실시예로 한다. 본 발명의 일 실시예에 따른 PDI 테이블의 포맷은 설계자의 의도에 따라 변경 가능하다.
도 40에 도시된 바와 같이, 본 발명의 일 실시예에 따른 PDI 테이블은 속성(attributes)(1110) 및/또는 PDI 타입 엘리먼트를 포함할 수 있다. 본 발명의 일 실시예에 따른 속성(1110)은 transactional(거래) 속성(1100), time(시간) 속성(1101)을 포함할 수 있다. 본 발명의 일 실시예에 따른 PDI 타입 엘리먼트는 QIA(Question with Integer Answer) 엘리먼트(1102), QBA(Question with Boolean Answer) 엘리먼트(1102), QSA(Question with Selection Answer) 엘리먼트(1104), QTA(Question with Text Answer) 엘리먼트(1105) 및/또는 QAA(Question with Any-format Answer) 엘리먼트(1106)를 포함할 수 있다. 이하 도 40에 도시된 PDI 테이블의 구성 엘리먼트들에 대해 설명한다.
구체적으로, 도 40에 도시된 속성(1110)은 본 발명의 일 실시예에 따른 PDI 테이블 자체의 속성 정보를 지시할 수 있다. 따라서 PDI 테이블이 포함하는 PDI 타입 엘리먼트가 달라지더라도, 속성(1110)은 본 발명의 일 실시예에 따른 PDI 테이블에 동일하게 표현될 수 있다. 예를 들어, 본 발명의 일 실시예에 따른 transactional 속성(1100) 은 PDI 질문의 목적에 대한 정보를 지시할 수 있다. 본 발명의 일 실시예에 따른 time 속성(1101)은 PDI 테이블이 생성되거나 업데이트된 시간에 대한 정보를 지시할 수 있다. 이 경우 서로 다른 PDI 타입 엘리먼트를 포함하는 PDI 테이블들은, PDI 타입 엘리먼트가 달라지더라도 transactional 속성(1100) 및/또는 time 속성(1101)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 PDI 테이블은 루트 엘리먼트(root element)로서 하나 또는 2 이상의 PDI 타입 엘리먼트(1102)를 포함할 수 있다. 이 경우 PDI 타입 엘리먼트(1102)는 리스트 형식으로 표현될 수 있다.
본 발명의 일 실시예에 따른 PDI 타입 엘리먼트는 PDI 답변의 타입에 따라 구별될 수 있다. 예를 들어, 본 발명의 일 실시예에 따른 PDI 타입 엘리먼트는 "QxA" 엘리먼트로 호칭될 수 있으며, 이 경우 "x"는 PDI 답변의 타입에 따라 결정될 수 있다. 본 발명의 일 실시예에 따른 PDI 답변의 타입은 정수 타입, 불(Boolean) 타입, 선택 타입, 텍스트 타입 및 상술한 네 가지 타입 이외의 모든 형태의 답변을 포함하는 타입을 포함할 수 있다.
본 발명의 일 실시예에 따른 QIA 엘리먼트(1103)는 하나의 PDI 질문 및/또는 해당 PDI 질문에 대한 정수 타입의 PDI 답변을 포함할 수 있다.
본 발명의 일 실시예에 따른 QBA 엘리먼트(1104)는 하나의 PDI 질문 및/또는 해당 PDI 질문에 대한 불 타입의 PDI 답변을 포함할 수 있다.
본 발명의 일 실시예에 따른 QSA 엘리먼트(1105)는 하나의 PDI 질문 및/또는 해당 PDI 질문에 대한 다중 선택(selection) 타입의 PDI 답변을 포함할 수 있다.
본 발명의 일 실시예에 따른 QTA 엘리먼트(1106)는 하나의 PDI 질문 및/또는 해당 PDI 질문에 대한 문자열(text) 타입의 PDI 답변을 포함할 수 있다.
본 발명의 일 실시예에 따른 QAA 엘리먼트(1107)는 하나의 PDI 질문 및/또는 해당 PDI 질문에 대한 정수, 불, 다중 선택 및 문자열 형태를 제외한 형태의 PDI 답변을 포함할 수 있다.
도 41는 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로 도 41는, 도 40에서 설명한 PDI 타입 엘리먼트 중 QIA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 41에 도시된 바와 같이, QIA 엘리먼트는 PDI 질문 타입과 관련된 특징에 관한 정보를 지시하는 속성(1210), id 속성(1220), 질문 엘리먼트(1230) 및/또는 답변 엘리먼트(1240)를 포함할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 속성(1210)은 PDI 질문의 언어를 지시하는 lang 속성을 포함할 수 있다. 또한 본 발명의 일 실시예에 따른 QIA 엘리먼트의 속성(1210)은 PDI 답변이 가질 수 있는 최소의 정수값을 지시하는 minInclusive 속성(1230) 및/또는 PDI 답변이 가질 수 있는 최대의 정수값을 지시하는 maxInclusive 속성(1240)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 id 속성(1220)는 PDI 질문 및/또는 PDI 답변을 식별하는 데 사용될 수 있다.
또한 본 발명의 일 실시예에 따른 질문 엘리먼트(1230)는 PDI 질문 자체를 포함할 수 있다. 도 41에 도시된 바와 같이, 질문 엘리먼트(1230)는 PDI 질문에 관한 정보를 지시하는 속성을 포함할 수 있다. 예를 들어, 질문 엘리먼트(1230)는 PDI 질문이 생성된 시간 또는 PDI 질문이 전송된 시간을 지시하는 time 속성(1231) 및/또는 PDI 질문의 유효시간을 지시하는 expiration(만료) 속성(1232)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 답변 엘리먼트(1240)는 PDI 답변 자체를 포함한다. 도 41에 도시된 바와 같이 답변 엘리먼트(1240)는 PDI 답변에 관한 정보를 지시한 속성을 포함할 수 있다. 예를 들어, 도 41에 도시된 바와 같이 답변 엘리먼트(1240)는 각각의 PDI 답변을 인식하기 위해 사용될 수 있는 id 속성(1241) 및/또는 각각의 PDI 답변이 생성되거나 수정된 시간을 지시하는 time 속성(1242)를 포함할 수 있다.
도 42은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 42은 도 40에서 설명한 PDI 타입 엘리먼트 중 QBA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 42에 도시된 바와 같이, QBA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 41에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
도 43는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 43는 도 40에서 설명한 PDI 타입 엘리먼트 중 QSA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 43에 도시된 QSA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 41에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
다만, 다중 선택 질문의 특성에 따라, 본 발명의 일 실시예에 따른 QSA 엘리먼트의 속성은 minChoice 속성(1411) 및/또는 maxChoice 속성(1412)을 더 포함할 수 있다. 본 발명의 일 실시예에 따른 minChoice 속성(1411)은 사용자가 선택할 수 있는 PDI 답변의 최소 개수를 지시할 수 있다. 본 발명의 일 실시예에 따른 maxChoice 속성(1412)은 사용자가 선택할 수 있는 PDI 답변의 최대 개수를 지시할 수 있다.
도 44는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 44은 도 40에서 설명한 PDI 타입 엘리먼트 중 QAA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 44에 도시된 바와 같이, QAA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 41에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
도 45은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 45은 도 40 내지 도 44에서 설명한 PDI 테이블과 마찬가지로 PDI 테이블의 확장된 포맷을 XML 스키마로 나타낸 도면이다.
상술한 바와 같이 본 발명에서는 개인화 서비스를 제공하기 위해 PDI 테이블을 사용하는 것을 일 실시예로 한다. 하지만 동일한 사용자라 하더라도, 사용자가 속한 상황에 따라 선호하는 콘텐츠가 달라질 수 있다.
따라서 본 발명에서는 상술한 문제점을 해결하기 위하여 PDI 테이블에 사용자의 상황 정보를 지시하는 구성 엘리먼트를 더 추가하는 것을 일 실시예로 할 수 있다.
도 45에 도시된 PDI 테이블은 사용자의 상황 정보를 지시하는 구성 엘리먼트로서 상황 엘리먼트(1600)를 더 포함할 수 있다. 도 45에 도시된 PDI 테이블의 기본적인 XML 스키마는 도 40 내지 도 44에서 설명한 바와 동일하므로 구체적인 설명은 생략한다. 이하 상황 엘리먼트(1600)를 설명한다.
본 발명의 일 실시예에 따른 상황 엘리먼트(1600)는 사용자의 상황 정보로서 시간대 및/또는 위치에 관한 정보를 지시할 수 있다. 도 45에 도시된 바와 같이, 상황 엘리먼트(1600)는 시간 엘리먼트(1610), 위치 엘리먼트(1620) 및/또는 사용자의 상황 정보를 나타내는 그 밖의 엘리먼트들을 더 포함할 수 있다. 이하 각 엘리먼트를 설명한다.
본 발명의 일 실시예에 따른 시간 엘리먼트(1610)는 사용자가 속한 지역의 시간과 관련된 정보를 포함할 수 있다. 예를 들어, 본 발명의 일 실시예에 따른 시간 엘리먼트(1610)는 "yyyy-mm-dd" 형식의 시간 정보를 지시하는 time 속성(1610) 및/또는 사용자가 속한 지역의 시간대를 지시하는 timezone 속성(1612)을 포함할 수 있다.
본 발명의 일 실시예에 따른 위치 엘리먼트(1620)는 사용자가 속해 있는 지역의 위치 정보를 포함할 수 있다. 예를 들어, 도 45에 도시된 바와 같이, 장소 엘리먼트(1620)는 해당 위치의 정보를 지시하는 location-desc 속성(1621), 해당 위치의 위도 정보를 지시하는 latitude 속성(1622) 및/또는 해당 위치의 경도 정보를 지시하는 longitude 속성(1623)을 포함할 수 있다.
도 46은 본 발명의 다른 실시예에 따른 PDI 테이블을 나타내는 도면이다.
구체적으로, 도 46은 본 발명의 실시예에 대하여 도 40 내지 45를 참조하여 설명한 XML 스키마로 PDI 테이블을 나타낸다.
도 46은 PDI 테이블이라 불리우는 루트 엘레멘트에 대한 XML 스키마 정의로서, PDI 테이블 인스턴스 다큐먼트의 구조를 정의한다. 본 발명의 실시예에 따르면, PDI 테이블 인스턴스 다큐먼트는 PDI 테이블을 XML 스키마로 실현함으로써 얻어지는 실제 다큐먼트를 지칭한다.
도 46은 PDI 어플리케이션 프로그래밍 인터페이스(API)를 이용하여 DO 및 근원적인 수신기 사이에서 전달될 수 있는 개별 질문을 나타내는 루트 엘레멘트 QIA, QBA, QSA, QTA 또는 QAA에 대한 XML 스키마 정의를 나타낸다. 본 실시예에 따른 PDI API가 구체적으로 기술된다. 도 46에 도시된 엘레멘트는 이름 공간 "를 갖는 XML 스키마의 정의를 따를 수 있다.
PDI 질문(또는 PDI-Q) 및 PDI 답변(또는 PDI-A) 간의 차는 스키마 자체보다는 오히려 사용 규칙에서 특정된다. TDI 테이블 내의 엔트리의 질문 부분은 비공식적으로 "PDI 질문" 또는 "PDI-Q"라 불리운다. 주어진 PDI 질문에 대한 답변은 비공식적으로 "PDI-A"라 한다. 예를 들어, 스키마가 다양한 타입의 질문의 "q" 엘레멘트에 대하여 minOccurs="0"을 나타내지만, 스키마가 PDI-Q에 사용되면, 이 경우의 "q" 엘레멘트의 사용은 의무적이다. 스키마가 PDI-A에 사용되면, "q" 엘레멘트의 포함은 선택적이다.
PDI-Q 인스턴스 다큐먼트는 그 이름 공간으로 ATSC 2.0 표준의 일부인 "PDI 테이블" XML 스키마에 따를 수 있고, 그 정의는 임의의 차의 경우 여기에 제공되는 설명보다 우선한다. 본 발명의 실시예에 따르면, PDI-Q 인스턴스 다큐먼트는 PDI-Q를 포함하는 PDI 테이블을 XML 스키마로 실현함으로써 얻어지는 실제 다큐먼트이다.
PDI-Q 인스턴스 다큐먼트는 QIA(integer-answer type question), QBA(Boolean-answer type question), QSA(selection-type question) 및/또는 QTA(textual-answer type question) 중의 하나 이상의 엘레멘트로 구성된다.
이들 상위 레벨 엘레멘트의 "A" (답변) 하위 엘레멘트가 PDI-Q 인스턴스에 존재하지 않을 수 있다.
이들 엘레멘트의 각각의 내의 식별자 속성("id")은 PDI-A 인스턴스 다큐먼트 내의 해당 엘레멘트에 대한 기준 또는 링크로서 기능할 수 있다. 본 발명의 실시예에 따르면, PDI-A 인스턴스 다큐먼트는 PDI-A를 포함하는 PDI 테이블을 XML 스키마로 실현함으로써 얻어지는 실제 다큐먼트이다.
PDI-A 인스턴스 다큐먼트는 그 이름 공간으로 ATSC 2.0 표준의 일부인 "PDI 테이블" XML 스키마에 따를 수 있고, 그 정의는 임의의 차의 경우 여기에 제공되는 설명보다 우선한다.
PDI-A 인스턴스 다큐먼트는 QIA(integer-answer type question), QBA(Boolean-answer type question), QSA(selection-type question), QTA(textual-answer type question), 및/또는 QAA(any-format answer type question)중의 하나 이상의 엘레멘트로 구성된다.
이들 엘레멘트의 각각은 적어도 하나의 "A"(답변) 하위 엘레멘트를 갖는다. 이들은 임의의 "Q"(질문 스트링) 하위 엘레멘트를 포함하지 않을 수 있다.
이들 엘레멘트의 각각의 내의 식별자 속성("id")은 PDI-Q 인스턴스 다큐먼트 내의 해당 엘레멘트에 대한 기준 또는 링크로서 기능할 수 있다.
이하, 도 46에 도시된 PDI 테이블 내에 포함되는 엘레멘트 및 속성의 시맨틱을 설명한다.
도 46에 도시된 바와 같이, 본 실시예에 따른 PDI 테이블에서, "@"는 속성의 이름의 앞에 표시되어 속성 및 엘레멘트를 구별할 수 있다.
본 실시예에 따른 PDI 테이블은 PDI 타입 엘레멘트를 포함할 수 있다. 구체적으로, PDI 타입 엘레멘트는 도 40을 참조하여 설명한 바와 같이 QIA 엘레멘트, QBA 엘레멘트, QSA 엘레멘트, QTA 엘레멘트 및/또는 QAA 엘레멘트를 포함할 수 있다.
도 46에 도시된 바와 같이, 본 실시예에 따른 PDI 테이블은 질문 타입 엘레멘트와 상관없이 protocolversion 속성, pditableid 속성, pidtableversion 속성 및/또는 time 속성을 포함할 수 있다.
QIA, QBA, QSA, QTA 및/또는 QAA 엘레멘트의 id 속성은 이들 엘레멘트의 각각의 만료 속성에서처럼 모두 동일한 시맨틱을 갖는다. 마찬가지로, Q 엘레멘트의 각각의 lang 속성은 각각 A 엘레멘트의 각각의 시간 속성처럼 동일한 시맨틱을 갖는다. 또한, id 속성은 도 38을 참조하여 설명한 PDI 데이터 식별자를 지칭할 수 있다.
PDITable 엘레멘트는 하나 이상의 질문 엘레멘트의 리스트를 포함한다. 이들 각각은 QIA, QBA, QSA, QTA 또는 QAA의 포맷이다. 기수(0, …, N)을 갖는 <초이스> 구성의 사용은 임의의 수의 QIA, QBA, QSA, QTA 및 QAA 엘레멘트가 임의의 순서로 나타날 수 있다는 것을 의미한다.
PDITable 엘레멘트의 protocolVersion 속성은 2 hex 숫자로 구성된다. 상위 4비트는 테이블 정의의 메이저 버전 번호를 나타낸다. 하위 4비트는 테이블 정의의 마이너 버전 번호를 나타낸다. 이 표준의 이 버전에 대한 메이저 버전 번호는 1로 설정된다. 수신기는 지원하지 않는 메인 버전 값을 나타내는 PDI의 인스턴스를 폐기할 것으로 예상된다. 표준의 이 버전에 대한 마이너 버전 번호는 0으로 설정된다. 수신기는 지원되지 않는 마이너 버전 값을 나타내는 PDI의 인스턴스를 폐기하지 않을 것으로 예상한다. 이 경우, 지원되지 않는 임의의 개별 엘레멘트 또는 속성을 무시할 것으로 예상한다.
PDITable 엘레멘트의 pdiTableId 속성은 이 PDI 테이블 엘레멘트의 글로벌 유니크 식별자일 수 있다.
PDITable 엘레멘트의 8비트를 갖는 pdiTableVersion 속성은 이 PDI 테이블 엘레멘트의 버전을 나타낸다. 초기 값은 0일 수 있다. 값은 이 PDI 테이블 엘레멘트가 변경될 때마다 1씩 증가할 수 있고, 255후에 0으로 넘어간다.
PDITable 엘레멘트의 time 속성은 이 PDI 테이블 내의 임의의 질문에 대한 가장 최근의 변경의 일시를 나타낸다.
QIA 엘레멘트는 질문의 정수 답변 타입을 나타낸다. 이것은 답변의 최대 및 최소 허용 값을 특정하는 선택적인 제한을 포함한다.
QIA의 QIA.loEnd 속성은 이 QIA 엘레멘트의 "A" 하위 엘레멘트의 최소 가능 값을 나타낸다. 즉, "A" 엘레멘트의 값은 loEnd보다 작지 않다. loEnd 속성이 존재하지 않으면, 최소가 없는 것을 나타낸다.
QIA의 QIA.hiEnd 속성은 이 QIA 엘레멘트의 "A" 하위 엘레멘트의 최대 가능 값을 나타낸다. 즉, 답변의 값은 hiEnd보다 크지 않다. hiEnd 속성이 존재하지 않으면, 최대가 없는 것을 나타낸다.
QIA.Q 엘레멘트는 QIA 엘레멘트의 하위 엘레멘트이다. QIA.Q 엘레멘트의 값은 사용자에게 제시되는 질문 스트링을 나타낼 수 있다. 질문은 정수 타입 답변을 갖는 것으로 표현되어야 한다. 이 엘레멘트의 다수의 인스턴스가 상이한 언어로 존재할 수 있다.
QIA 엘레멘트의 하위 엘레멘트로서의 QIA.A 엘레멘트는 정수 값을 가질 수 있다. QIA.A 엘레멘트는 QIA.Q에서 질문에 대한 답변을 나타낼 수 있다.
QBA 엘레멘트는 질문의 불 답변 타입을 나타낸다.
QBA.Q 엘레멘트는 QBA 엘레멘트의 하위 엘레멘트이다. QBA.Q 엘레멘트의 값은 사용자에게 제시될 질문 스트링을 나타낼 수 있다. 질문은 답변의 예/아니오 또는 참/거짓 타입을 갖도록 표현될 수 있다. 이 엘레멘트의 다수의 인스턴스가 상이한 언어로 존재할 수 있다.
QBA 엘레멘트의 하위 엘레멘트로서의 QBA.A 엘레멘트는 불(Boolean) 값을 가질 수 있다. QBA.A 엘레멘트는 QBA.Q에서 질문에 대한 답변을 나타낼 수 있다.
QSA 엘레멘트는 질문의 선택 답변 타입을 나타낸다.
QSA 엘레멘트의 QSA.minChoices 속성은 사용자에 의해 이루어질 수 있는 선택의 최소 번호를 특정할 수 있다.
QSA 엘레멘트의 QSA.maxChoices 속성은 사용자에 의해 이루어질 수 있는 선택의 최대 번호를 특정할 수 있다.
QSA.Q 엘레멘트는 QSA 엘레멘트의 하위 엘레멘트이다. QSA.Q 엘레멘트의 값은 사용자에게 제시될 질문 스트링을 나타낼 수 있다. 질문은 제공되는 선택 초이스 중의 하나 이상에 대응하는 답변을 갖도록 표현될 수 있다.
QSA.Q.Selection 엘레멘트는 QSA.Q 엘레멘트의 하위 엘레멘트이다. QSA.Q.Selection 엘레멘트의 값은 사용자에게 제시될 가능한 선택을 나타낼 수 있다. 동일한 QSA 엘레멘트의 다수의 QSA.Q 하위 엘레멘트(상이한 언어의)가 존재하면, 그들 각각은 동일한 의미를 갖는 동일한 수의 선택 하위 엘레멘트를 갖는다.
QSA.Q.Selection의 QSA.Q.Selection.id 속성은 QSA.Q의 범위 내의 고유한 선택 엘레멘트에 대한 식별자일 수 있다. 동일한 QSA 엘레멘트의 다수의 QSA.Q 하위 엘레멘트(상이한 언어의)가 존재하면, 동일한 의미를 갖는 해당 선택 엘레멘트를 갖는 그 선택 엘레멘트의 id 속성 사이에 일대일 대응이 존재할 수 있다.
QSA.A는 QSA 엘레멘트의 하위 엘레멘트이다. QSA 엘레멘트의 이 하위 엘레멘트의 각각의 인스턴스는 선택의 엘레멘트 중의 하나의 id 값의 형태로 이 선택 타입 질문에 대한 하나의 허용 답변을 특정할 수 있다.
QTA 엘레멘트는 질문의 텍스트 답변 (자유 형태 엔트리) 타입을 나타낸다.
QTA.Q 엘레멘트는 QTA 엘레멘트의 하위 엘레멘트이다. QTA.Q 엘레멘트의 값은 사용자에게 제시될 질문 스트링을 나타낼 수 있다. 질문은 자유 형태 텍스트 답변을 갖도록 표현될 수 있다.
QTA.A 엘레멘트는 QTA 엘레멘트의 하위 엘레멘트이다. QTA.A 엘레멘트의 값은 QTA.Q 내의 질문에 대한 답변을 나타낼 수 있다.
QAA 엘레멘트는 데이터베이스 내의 엔트리처럼 다양한 타입의 정보를 유지하는데 사용될 수 있다.
QAA.A 엘레멘트는 QAA 엘레멘트의 하위 엘레멘트이다. QAA.A 엘레멘트의 값은 임의의 형태의 정보를 포함한다.
QIA, QBA, QSA, QTA 및 QAA 엘레멘트의 id 속성은 그것이 나타나는 엘레멘트에 대한 글로벌 유니크 식별자인 URI일 수 있다.
QIA, QBA, QSA, QTA 및 QAA 엘레멘트의 만료 엘레멘트는 그것이 나타난 엘레멘트가 더 이상 관련되지 않고 테이블에서 삭제되는 일시를 나타낸다.
QIA.Q, QBA.Q, QSA.Q, QTA.Q 및 QTA.A 엘레멘트의 lang 속성은 질문 또는 답변 스트링의 언어를 나타낼 수 있다. QSA.Q의 경우, lang 속성은 또한 QSA.Q의 선택 하위 엘레멘트의 언어를 나타낼 수 있다. Lang 속성이 존재하지 않으면, 이것은 언어가 영어라는 것을 나타낼 수 있다.
QIA.A, QBA.A, QSA.A, QTA.A 및 QAA.A 엘레멘트의 time 속성은 답변이 테이블에 입력되는 일시를 나타낼 수 있다.
도 46에는 도시되지 않았지만, 본 실시예에 따른 PDI 테이블은 QIAD 엘레멘트, QBAD 엘레멘트, QSAD 엘레멘트, QTAD 엘레멘트 및/또는 QAAD 엘레멘트를 더 포함할 수 있다. 상술한 엘레멘트는 통합하여 QxAD 엘레멘트라 한다. 이하, QxAD 엘레멘트를 설명한다.
루트 엘레멘트로서의 QIAD 엘레멘트는 QIA 하위 엘레멘트 내의 질무의 정수 답변 타입을 포함한다. QIA는 답변의 최대 및 최소 허용 값을 특정하는 선택적 제한을 포함한다.
루트 엘레멘트로서의 QBAD 엘레멘트는 질문의 불 답변 타입을 나타낸다.
루트 엘레멘트로서의 QSAD 엘레멘트는 질문의 선택 답변 타입을 나타낸다.
루트 엘레멘트로서의 QTAD 엘레멘트는 질문의 텍스트 답변(자유 형태 엔트리) 타입을 나타낸다.
루트 엘레멘트로서의 QAAD 엘레멘트는 데이터베이스 내의 엔트리처럼 다양한 타입의 정보를 유지하는데 사용될 수 있다.
도 46에는 도시되지 않았지만, 각각의 PDI 타입 엘레멘트는 QText 엘레멘트 및/또는 time 속성을 더 포함할 수 있다.
QIA.Q.QText 엘레멘트는 QIA.Q 엘레멘트의 하위 엘레멘트이다. QIA.Q.QText 엘레멘트의 값은 사용자에게 제시될 질문 스트링을 나타낸다. 질문은 정수 타입 답변을 갖도록 표현되어야 한다.
QIA.A.answer 속성은 QIA.A 엘레멘트의 정수 값 속성이다. QIA.A.answer 속성은 QIA.Q.QText 엘레멘트 내의 질문에 대한 답변을 나타낸다.
QBA.Q.QText 엘레멘트는 QBA.Q 엘레멘트의 하위 엘레멘트이다. QBA.Q.QText 엘레멘트의 값은 사용자에게 제시될 질문 스트링을 나타낸다. 질문은 답변의 예/아니오 또는 참/거짓 타입을 갖도록 표현되어야 한다. 이 엘레멘트의 다수의 인스턴스가 상이한 언어로 존재할 수 있다.
QBA.A.answer 속성은 QBA.A 엘레멘트의 불 값 속성이다. QBA.A.@answer 속성은 QBA.Q.QText 엘레멘트 내의 질문에 대한 답변을 나타낸다.
QSA.Q.QText 엘레멘트는 QSA.Q 엘레멘트의 하위 엘레멘트이다. QSA.Q.QText 엘레멘트는 사용자에게 제시될 질문 스트링을 나타낸다. 질문은 제공되는 선택 초이스 중의 하나 이상에 대응하는 답변을 갖도록 표현되어야 한다. 이 엘레멘트의 다수의 인스턴스가 상이한 언어로 존재할 수 있다.
QSA.A 하위 엘레멘트의 QSA.A.answer 속성은 선택 엘레멘트 중의 하나의 id 값의 형태로 이 선택 타입 질문에 대한 하나의 허용 답변을 특정한다.
QTA.Q.QText 엘레멘트는 QTA.Q 엘레멘트의 하위 엘레멘트이다. QTA.Q.QText 엘레멘트의 값은 사용자에게 제시될 질문 스트링을 나타낸다. 질문은 자유 형태 텍스트 답변을 갖도록 표현되어야 한다.
QTA.A.answer 속성은 QTA 엘레멘트의 하위 엘레멘트이다. QTA.A.answer 엘레멘트의 값은 QTA.Q.QText 엘레멘트 내의 질문에 대한 답변을 나타낸다.
도 47은 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸다.
구체적으로, 도 47은 도 40 내지 45를 참조하여 설명한 XML 스키마로 PDI 테이블의 구조를 나타낸다.
도 47에 도시된 PDI 테이블의 기본 구조 및 기본 엘레멘트 및 속성의 시맨틱은 도 46과 동일하다. 그러나, 도 46에 도시된 PDI 테이블과 달리, 도 47의 PDI 테이블은 xactionSetId 속성 및/또는 text 속성을 더 포함할 수 있다. 이하, xactionSetId 속성 및/또는 text 속성에 대하여 PDI 테이블을 설명한다.
QxA 엘레멘트의 xactionSetId 속성은 질문이 질문의 트랜잭션 세트에 속한다는 것을 나타내고, 여기서, 질문의 트랜잭션 세트는 질문에 답변할 목적으로 단위로서 취급될 세트이다. 이것은 또한 질문이 속하는 트랜잭션 세트에 대한 식별자를 제공한다. 따라서, xactionSetId 속성의 동일한 값을 갖는 PDI 테이블 내의 모든 질문의 세트는 "전체 또는 제로(all or nothing)" 기초로 답변될 수 있다.
QxA 엘레멘트의 text 속성은 QxA.Q 엘레멘트의 하위 엘레멘트이다. Text 속성의 값은 사용자에게 제시될 질문 스트링을 나타낼 수 있다.
도 48는 본 발명의 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다. 상술한 도 36의 개인화 방송 시스템은 개인화 서비스를 제공하기 위해 필터링 기준을 사용할 수 있다. 도 36, 도 38 및 도 39에서 설명한 필터링 기준은 필터링 기준 테이블 형식으로 처리될 수 있다. 본 발명의 필터링 기준 테이블은 XML 스키마로 표현되는 것을 일 실시예로 한다.
또한, 본 발명의 필터링 기준 테이블은, PDI 데이터와 필터링 기준을 효율적으로 비교하기 위해, PDI 테이블의 포맷과 유사한 포맷을 갖는 것을 일 실시예로 할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 테이블의 포맷은 설계자의 의도에 따라 변경 가능하다.
도 48에 도시된 바와 같이, 본 발명의 일 실시예에 따른 필터링 기준 테이블은 filtering criterion 엘리먼트(1900)를 포함할 수 있으며, filtering criterion 엘리먼트(1900)는 identifier 속성(1901), criterion type 속성(1902) 및/또는 criterion value 엘리먼트(1903)를 포함할 수 있다. 본 발명의 필터링 기준은 상술한 PDI 질문에 대응되는 개념으로 사용될 수 있다. 이하 도 48에 도시된 필터링 기준 테이블의 구성 엘리먼트들에 대해 설명한다.
본 발명의 일 실시예에 따른 filtering criterion 엘리먼트(1900)는 PDI 질문에 대응하는 필터링 기준을 지시할 수 있다.
본 발명의 일 실시예에 따른 identifier 속성(1901)은 필터링 기준에 대응하는 PDI 질문을 식별할 수 있다.
본 발명의 일 실시예에 따른 criterion type 속성(1902)은 필터링 기준의 타입을 지시할 수 있다. 필터링 기준의 타입에 관한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 criterion value 엘리먼트(1903)는 필터링 기준이 가지는 값을 지시할 수 있다. 각 기준값은 PDI 질문에 대한 가능한 답변이다.
구체적으로, 본 발명에 따른 필터링 기준의 타입은 정수 타입, 불 타입, 선택 타입, 텍스트 타입 및/또는 어느 타입 중 하나의 타입을 일 실시예로 할 수 있다.
정수 타입의 필터링 기준(또는 정수 타입 기준)은 정수 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
불 타입의 필터링 기준(또는 불 타입 기준)은 불 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
선택 타입의 필터링 기준(또는 선택 타입 기준)은 선택 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
텍스트 타입의 필터링 기준(또는 텍스트 타입 기준)은 텍스트 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
어느 타입의 필터링 기준(또는 어느 타입 기준)은 상술한 네 가지 타입 이외의 모든 형태의 PDI 답변에 대응하는 필터링 기준을 의미한다.
이하 [예시 5]는 도 48에 도시된 필터링 기준 테이블의 XML 스키마를 나타낸 본 발명의 일 실시예이다.
[예시 5]
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FilterCriteriaTable" type="FilterCriteriaTableType"/>
<xs:complexType name="FilterCriteriaTableType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="FilterCriterion" type="FilterCriterionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FilterCriterionType">
<xs:sequence>
<xs:element name="CriterionValue" type="xs:base64Binary" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:anyURI" use="required"/>
<xs:attribute name="CriterionType" type="xs:unsignedByte" use="required"/>
</xs:complexType>
</xs:schema>
도 49은 본 발명의 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로 도 49은, 도 48에서 설명한 필터링 기준 테이블의 확장된 포맷을 XML 스키마로 표현한 도면이다. 도 48에 도시된 필터링 기준의 XML 스키마에 따라 필터링 기준 테이블을 구성할 경우, 본 발명의 일 실시예에 따른 필터링 기준의 타입과 각 타입별 세부 속성을 설정할 수 없다는 문제점이 있다. 따라서 도 49에서는 필터링 기준의 타입을 표현하고, 각 타입별 속성을 설정한 XML 스키마를 제시하고자 한다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 도 49에 따른 XML 스키마에 따라 구성된 필터링 기준 테이블을 이용하여, 보다 정밀하게 콘텐츠를 필터링할 수 있다.
도 49에 도시된 바와 같이, 필터링 기준 테이블은 속성(2000) 및/또는 필터링 기준 타입 엘리먼트를 포함할 수 있다. 본 발명의 일 실시예에 따른 속성(2000)은 time 속성(2001)를 포함할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 정수 타입 기준 엘리먼트(Integer Type Criterion 엘리먼트) (또는 QIA 기준 엘리먼트)(2010), 불 타입 기준 엘리먼트(Boolean Type Criterion 엘리먼트) (또는 QBA 기준 엘리먼트)(2020), 선택 타입 기준 엘리먼트(Selection Type Criterion element) (또는 QSA 기준 엘리먼트)(2030), 텍스트 타입 기준 엘리먼트(Text Type Criterion element)(또는 QTA 기준 엘리먼트)(2040) 및/또는 어느 타입 기준 엘리먼트(Any Type Criterion element)(또는 QAA 기준 엘리먼트)(2050)를 포함할 수 있다. 이하 도 49에 도시된 필터링 기준 테이블의 구성 엘리먼트들에 대해 설명한다.
구체적으로, 도 40에 도시된 속성(2000)은 본 발명의 일 실시예에 따른 필터링 기준 테이블 자체의 속성 정보를 지시할 수 있다. 따라서 필터링 기준 테이블이 포함하는 필터링 기준 타입 엘리먼트가 달라지더라도 동일하게 표현될 수 있다. 예를 들어, 본 발명의 실시예에 따른 time 속성(2001)은 필터링 기준이 생성된 시간 또는 갱신된 시간을 지시할 수 있다. 이 경우 서로 다른 필터링 기준 타입 엘리먼트를 포함하는 필터링 기준 테이블들은, 필터링 기준 타입 엘리먼트가 달라지더라도 time 속성(2001)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 필터링 기준 테이블은 하나 또는 2 이상의 필터링 기준 타입 엘리먼트를 포함할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 필터링 기준의 타입을 지시할 수 있다. 필터링 기준의 타입은 도 48에서 설명한 바와 같다. 이 경우 필터링 기준 타입 엘리먼트는 리스트 형식으로 표현될 수 있다.
본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 "QxA" 기준으로 호칭될 수 있으며, 이 경우 "x"는 필터링 기준의 타입에 따라 결정될 수 있다.
도 49에 도시된 바와 같이, 각각의 필터링 기준 타입 엘리먼트는 식별자 속성 및/또는 기준값 엘리먼트를 포함할 수 있다. 도 49에 도시된 식별자 속성 및 기준값 엘리먼트 구체적인 내용은 도 48에서 설명한 바와 같다.
다만 도 49에 도시된 바와 같이, 정수 타입 기준 엘리먼트(2010)는 min integer 속성(2011) 및/또는 max integer 속성(2012)을 더 포함할 수 있다. 본 발명의 일 실시예에 따른 min integer 속성(2011)은 정수 타입의 답변으로 표현된 필터링 기준의 최소값을 지시할 수 있다. 본 발명의 일 실시예에 따른 max integer 속성(2012)은 정수 타입의 답변으로 표현된 필터링 기준의 최대값을 지시할 수 있다.
또한 도 49에 도시된 바와 같이, selection type criterion 엘리먼트(2030) 및/또는 text type criterion 엘리먼트(2040)는 lang 속성(2031)을 포함할 수 있다. 본 발명의 일 실시예에 따른 lang 속성(2031)은 문자열 형태로 표현된 필터링 기준의 값을 지시할 수 있다.
이하 [예시 6]는 도 49에 도시된 필터링 기준 테이블의 XML 스키마를 나타낸 본 발명의 일 실시예이다.
[예시 6]
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FilterCriteriaTable" type="FilterCriteriaTableType"/>
<xs:complexType name="FilterCriteriaTableType">
<xs:choice maxOccurs="unbounded">
<xs:element name="IntegerTypeCriterion" type="IntegerCriterionOption"/>
<xs:element name="BooleanTypeCriterion" type="BooleanCriterionOpntion"/>
<xs:element name="SelectionTypeCriterion" type="StringCriterionOption"/>
<xs:element name="TextTypeCriterion" type="StringCriterionOption"/>
<xs:element name="AnyTypeCriterion" type="AnyTypeCriterionOption"/>
</xs:choice>
<xs:attribute name="time" type="xs:dateTime"/>
</xs:complexType>
<xs:complexType name="IntegerCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute name="minInteger" type="xs:integer"/
<xs:attribute name="maxInteger" type="xs:integer"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BooleanCriterionOpntion">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" type="xs:boolean"/>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StringCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" default="EN-US"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AnyTypeCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded"/>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="any" type="xs:anySimpleType"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:sequence>
</xs:sequence>
</xs:complexType></xs:schema>
도 50은 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로 도 50은 도 48 및 도 49에서 설명한 XML 스키마에 따른 필터링 기준 테이블의 일 실시예를 나타낸 도면이다. 도 50에 도시된 필터링 기준 테이블의 기본적인 구성 엘리먼트들은 도 48 및 도 49에서 상술한 바와 같다. 이하 도 50에 도시된 필터링 기준 테이블에 포함된 엘리먼트 및 속성의 시맨틱스에 대해 설명한다.
도 50에 도시된 바와 같이, 본 발명의 일 실시예에 따른 필터링 기준 테이블에서는 속성의 명칭 앞에"@"를 표시함으로써 속성과 엘리먼트를 구분할 수 있다.
테이블에서 @id 속성이 나타나는 각 위치에서, PDI 테이블에서 질문의 @id 속성이 있음으로써 @id 속성이 나타나는 필터링 기준에 해당하는 질문을 식별한다.
QIA Criterion 엘리먼트는 정수값을 갖는 질문에 해당하는 필터링 기준을 나타낼 것이다.
QIA Criterion 엘리먼트의 Criterion Value 하위 엘리먼트가 @extent 엘리먼트를 포함하지 않으면, 이는 필터링 기준에 해당하는 질문에 대한 정수 답변을 나타낼 것이다. QIA Criterion 엘리먼트의 Criterion Value 하위 엘리먼트가 @extent 속성을 포함하면, 이는 질문에 대한 답변의 수 범위의 하위점을 나타낼 것이고 @extent 속성은 그 범위에서 정수의 개수를 나타낼 것이다.
QBA Criterion 엘리먼트는 불 값을 갖는 질문에 해당하는 필터링 기준을 나타낼 것이다.
QBACriterion 엘리먼트의 Criterion Value 하위 엘리먼트는 필터링 기준에 해당하는 질문에 대한 불 답변을 나타낼 것이다.
QSA Criterion 엘리먼트는 선택 값을 갖는 질문에 해당하는 필터링 기준을 나타낼 것이다.
QSA Criterion 엘리먼트의 Criterion Value 하위 엘리먼트는 필터링 기준에 해당하는 질문에 대한 선택 답변의 식별자를 나타낼 것이다.
QTA Criterion 엘리먼트는 스트링 값을 갖는 질문에 해당하는 필터링 기준을 나타낼 것이다.
QTA Criterion 엘리먼트의 Criterion Value 하위 엘리먼트는 필터링 기준에 해당하는 질문에 대한 텍스트 답변을 나타낼 것이다.
QAA Criterion 엘리먼트는 질문 없이 텍스트 "답변"만을 갖는 "질문"에 해당하는 필터링 기준을 나타낼 것이다.
QAACriterion 엘리먼트의 Criterion Value 하위 엘리먼트는 필터링 기준에 해당하는 "질문"에 대한 텍스트 "답변"을 나타낼 것이다.
Filtering Criteria 엘리먼트에 하나의 Criterion Value 엘리먼트만 있으면, Criterion Value 엘리먼트의 값이 (질문이 Criterion Value 엘리먼트를 포함하는 엘리먼트의 id 속성에 의해 나타내어지는) Criterion Value 엘리먼트를 포함하는 엘리먼트에 해당하는 질문에 대한 PDI-A에서의 질문 중의 값과 일치하는 경우 서비스나 콘텐츠 아이템이 필터를 통과하는지에 대한 필터링 결정은 "맞음" (예)이 되고 그렇지 않은 경우 "틀림" (아니오)이 될 것이다.
"extent" 속성이 존재하는 QIA Criterion 엘리먼트의 Criterion Value 하위 요 소의 경우, 질문의 값이 Criterion Value 및 extent 속성에 의해 정의되는 구간에 있으면, Criterion Value 엘리먼트의 값은 해당하는 PDI-A에서의 답변 중의 값과 일치한다고 여겨질 것이다.
Filtering Criteria 엘리먼트에서 Criterion Value 엘리먼트의 총수가 1보다 크면, 각 Criterion Value 엘리먼트의 값은 (id 값에 의해 나타낸 바와 같이) Criterion Value가 필터링 기준에 해당하는 질문에 대한 PDI-A에서의 답변 중의 값과 일치하는 경우 "맞음"을 답하는 중간 용어로 평가될 것이고 그렇지 않은 경우 "틀림"을 답하는 중간 용어로 평가될 것이다. 이러한 중간 용어들 중, 상위 엘리먼트 식별자(QIA.id, QBA.id 등)의 동일 값을 갖는 용어는 각 타겟 기준에 대한 중간 결과를 얻기 위해 논리합이 되고, 이들 중간 결과는 최종 결과를 결정하기 위해 논리곱이 될 것이다. 최종 결과가 수신기에 대해 "맞음"으로 평가되면, 이는 관련 콘텐츠 아이템이 필터를 통과한 것을 의미한다.
도 51는 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로, 도 51에 도시된 필터링 기준 테이블은, 도 50에 도시된 필터링 기준 테이블의 확장된 구조를 나타낸다. 도 51에 도시된 필터링 기준 테이블의 기본적인 구성 엘리먼트들은 도 50에서 설명한 바와 같다. 이하 도 50에서 설명한 필터링 기준 테이블과의 차이점을 중심으로 도 51에 도시된 필터링 기준 테이블을 설명한다.
도 51에 도시된 필터링 기준 테이블은 필터링 기준의 집합의 다양한 경우를 허용한다. 각각의 집합은 필터링 기준의 다양한 경우를 포함한다. 각각의 필터링 기준은 일부 필터링 기준에 대해 제공되는 여러 값을 허용한다. 필터링 논리는 필터링 기준의 집합의 여러 경우 중 "OR" 논리이다. 필터링 기준의 각 집합 내에서, 필터링 논리는 동일한 필터링 기준에 대한 여러 값 중 "OR" 논리이고, 서로 다른 필터링 기준 중에서는 "AND" 논리이다.
예를 들면, 필터링 기준이 ((연령(age)=20) 및 (장르(genre)= "스포츠(sport) "))이거나 ((연령(age)=10) 및 (장르(genre)= "애니메이션(animation) "))이면, 필터링 기준 테이블은 아래 [예시 7]과 같이 나타낼 수 있다.
[예시 7]
<FilterCriteriaTable time="2012-09-03T09:30:47.0Z" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FilterCriterionSet>
<IntegerTypeCriterion id="abc.tv/age/">
<CriterionValue>20</CriterionValue>
</IntegerTypeCriterion>
<TextTypeCriterion id = "abc.tv/genre/">
<CriterionValue>sport</CriterionValue>
</TextTypeCriterion>
</FilterCriterionSet>
<FilterCriterionSet>
<IntegerTypeCriterion id= "abc.tv/age/">
<CriterionValue>10</CriterionValue>
</IntegerTypeCriterion>
<TextTypeCriterion id = "abc.tv/genre//">
<CriterionValue>animation</CriterionValue>
</TextTypeCriterion>
</FilterCriterionSet>
</FilterCriteriaTable>
도 52은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 52은, 본 발명의 일 실시예에 따른 수신기가 방송망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 7 내지 도 10에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 9 내지 도 18에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 48 내지 도 51에서 설명한 바와 같다.
도 52에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 SSC(Service Signaling Channel)(2300), FLUTE(File Delivery over Unidirectional Transport) 세션(2310), 필터링 엔진(2320), PDI 엔진(2330) 및/또는 UI(2340)을 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 DSM-CC(Digital Storage Media Command and Control) 섹션을 통해 PDI 테이블을 수신할 수 있다. 이 경우, 본 발명의 일 실시예에 따른 수신기는 FLUTE 세션(2310) 통하여 PDI 테이블을 수신할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 52에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 수신기는 먼저 SSC(2300)를 통해 PDI 테이블 섹션을 수신할 수 있다. 구체적으로, 본 발명의 일 실시예에 따른 수신기는, DSM-CC 섹션을 통해 수신되는 IP 데이터그램 중 SSC(2300)에 해당하는 IP 데이터그램을 파싱하여 PDI 테이블 섹션을 수신할 수 있다. 이 경우, 본 발명의 일 실시예에 따른 수신기는 SSC(2300)이 가지는 잘 알려진 IP 주소 및/또는 UDP 포트 넘버를 이용하여 PDI 테이블 섹션을 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI 테이블 섹션은 PDI 테이블을 방송망을 통해 전달하기 위해, 본 발명의 일 실시예에 따른 PDI 테이블을 압축한 테이블을 의미한다. PDI 테이블 섹션에 대한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 수신기는 SSC(2300)를 통해 수신한 PDI 테이블 섹션을 파싱하여 PDI 테이블을 획득할 수 있다. 이후에 본 발명의 일 실시예에 따른 수신기는 PDI 엔진(2330)으로 PDI 테이블을 전달할 수 있다.
본 발명의 일 실시예에 따른 PDI 엔진(2330)은 전달받은 PDI 테이블을 처리하여, 해당 PDI 테이블에 포함된 PDI 질문들을 추출할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(2330)은 추출된 PDI 질문들을 UI(2340)로 전달할 수 있다.
본 발명의 일 실시예에 따른 UI(2340)는 전달받은 PDI 질문들을 디스플레이하고, 해당 PDI 질문들에 대한 PDI 답변들을 수신할 수 있다. 이 경우 본 발명의 일 실시예에 따른 UI(2340)는 리모컨을 통해 PDI 답변들을 수신할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(2330)은 UI(2340)로부터 수신한 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있다. 구체적인 내용은 도 36 및 도 37에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 수신기는 SSC(2300)를 통해 SMT(Service Map Table) 및/또는 NRT-IT(Non Real Time Information Table)를 수신할 수 있다. 본 발명의 일 실시예에 따른 SMT는 개인화 서비스를 위한 시그널링 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 NRT-IT는 개인화 서비스를 위한 소식 정보를 포함할 수 있다.
이후에 본 발명의 일 실시예에 따른 수신기는 수신한 SMT 및/또는 NRT-IT를 파싱하여 필터링 기준 기술어를 획득할 수 있다. 수신기는 필터링 기준 기술어를 이용하여, 필터링 엔진(2320)으로 필터링 기준을 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 50 및 도 51에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(2320)은 PDI 엔진(2330)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(2330)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(2320)으로 전달할 수 있다. 결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 38 및 도 39에서 구체적으로 설명하였다.
도 53는 본 발명의 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 53는 도 52에서 설명한 PDI 테이블 섹션의 구문이다.
PDI 테이블이 방송 스트림에서 전달되면, 도 52에 정의된 테이블의 XML 형식은 DEFLATE 압축 알고리즘을 이용하여 압축된다. 얻어진 압축된 테이블은 도 53의 테이블에 나타낸 바와 같이 블록으로 구분되어 섹션에 삽입됨으로써 NRT 스타일의 전용 섹션에 요약된다.
결론적으로, 본 발명의 일 실시예에 따른 수신기는 동일한 시퀀스 넘버를 가지는 섹션 번호 순서대로 PDI-Q 경우 문서의 블록을 조합하여 압축을 해제할 수 있다. 본 발명의 일 실시예에 따른 수신기는 압축을 해제한 결과로서 PDI-Q 경우 문서를 생성할 수 있다. 이후에 수신기는 PDI-Q 경우 문서를 본 발명의 일 실시예에 따른 PDI 엔진으로 전달할 수 있다. 구체적인 방법은 도 52에서 상술한 바와 같다.
이하 도 53에 도시된 PDI 테이블 섹션의 구문에 대해 설명한다.
블록은 올림순의 section_number 필드 값의 섹션에 삽입될 것이다. "SSC" 및 "IP 서브넷"이라는 용어는 ATSC NRT 표준에서 정의되므로, 전용 섹션은 PDI 테이블이 관련된 가상 채널의 IP 서브넷의 SSC에서 전달된다. 해당 섹션의 sequence_number 필드는 동일한 SSC에서 전달되는 서로 다른 PDI 테이블 경우를 구별하기 위해 사용된다.
8비트의 table_id 필드는 해당 테이블 섹션이 PDI 테이블 경우에 속하는 것을 식별하기 위해 설정될 것이다. 8비트의 table_id 필드는 해당 테이블 섹션이 PDI 테이블 경우에 속하는 것을 식별하기 위해 설정될 것이다. table_id 필드는 도 53에 도시된 PDI 테이블 섹션이 본 발명의 일 실시예에 따른 PDI 테이블에 관한 정보를 포함하고 있음을 지시할 수 있다.
본 실시예에 따른 section_syntax_indicator 필드는 PDI 테이블 섹션의 포맷을 나타낼 수 있다.
본 실시예에 따른 private_indicator 필드는 사용자에 대한 비트 정보를 나타낼 수 있다.
본 실시예에 따른 section_length 필드는 PDI 테이블 섹션에서 바이트의 수를 나타낼 수 있다.
본 실시예에 따른 table_id_extension 필드는 PDI 테이블 섹션을 식별할 수 있다.
본 실시예에 따른 protocol_version 필드는 PDI 테이블 구문의 프로토콜 버전을 포함할 수 있다.
8비트의 sequence_number 필드의 값은 PDI-Q 경우의 다른 모든 섹션의 sequence_number와 동일하고, SSC에서 전달되는 다른 PDI-Q 경우의 모든 섹션의 sequence_number와 다르다. sequence_number 필드는 동시에 SSC에서 전달되는 PDI-Q의 서로 다른 경우에 속하는 섹션을 구별하기 위해 사용된다.
5비트의 PDIQ_data_version 필드는 pdiTableId 값에 의해 정의되는 PDI-Q 경우의 버전 넘버를 나타낸다. PDI-Q 경우의 어느 엘리먼트 또는 속성이 변화하면 버전 넘버는 1 modulo 32씩 증분된다.
1비트의 current_next_indicator 필드는 PDI-Q 섹션에 대해서는 항상 1로 설정되고, PDI-Q가 항상 segment_id에 의해 식별되는 세그먼트에 대해 현재 PDI-Q임을 나타낸다.
8비트의 section_number 필드는 PDI-Q 경우의 해당 섹션의 섹션 넘버를 제공한다. PDI-Q 경우의 첫 번째 섹션의 section_number는 0x00으로 설정된다. section_number는 PDI-Q 경우의 각각의 추가 섹션에 따라 1씩 증분된다.
8비트의 last_section_number 필드는 해당 섹션이 일부인 PDI-Q 경우의 마지막 섹션(즉, 최고의 section_number의 섹션)의 넘버를 제공한다.
16비트의 service_id 필드는 해당 PDI-Q 경우가 어느 특정 서비스가 아닌 그것이 나타나는 가상 채널에서의 모든 데이터 서비스에 적용된다는 것을 나타내기 위해 0x0000으로 설정된다.
가변 길이를 갖는 pdiq_bytes() 필드는 해당 섹션에 의해 부분적으로 전달되는 PDI-Q 경우의 블록으로 구성된다. 해당 테이블 경우의 모든 섹션의 pdiq_bytes() 필드가 그들의 section_number 필드의 순으로 연결되면, 결과는 완전한 PDI-Q 경우이다.
도 54는 본 발명의 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 54는 도 52에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 53에서 설명한 바와 같다. 다만, 도 53에 도시된 PDI 테이블 섹션과는 달리, 도 54에 도시된 PDI 테이블 섹션은 sequence_number 필드를 포함하지 않을 수 있다. 이하 도 54에 도시된 PDI 테이블 섹션의 구문에 대해 설명한다.
본 발명의 일 실시예에 따른 num_questions 필드는 PDI 테이블에 포함된 PDI 질문의 수를 지시할 수 있다.
본 발명의 일 실시예에 따른 question_id_length 필드는 하나의 PDI 질문의 ID의 길이를 지시할 수 있다.
본 발명의 일 실시예에 따른 question_id_value 필드는 하나의 PDI 질문의 ID가 가지는 값을 지시할 수 있다.
본 발명의 일 실시예에 따른 question_text_length 필드는 question_text의 길이를 지시할 수 있다.
본 발명의 일 실시예에 따른 question_text 필드는 하나의 PDI 질문의 실제 내용을 포함할 수 있다.
본 발명의 일 실시예에 따른 answer_type_code 필드는 PDI 질문에 대한 PDI 답변의 타입을 지시할 수 있다. 구체적으로 본 발명의 일 실시예에 따른 answer_type_code 필드는 이하 표 1에 표현된 답변 타입 코드들을 포함할 수 있다. 이하 Table 1에 도시된 각각의 답변 타입 코드는, 도 11에서 설명한 PDI 답변들의 타입을 지시할 수 있다.
answer_type_code 값
0x00
0x01
0x02
0x03
0x04 - 0x07		 확보됨
정수 타입
불 타입
스트링 타입 (including selection type/text type)
추후 ATSC 사용을 위해 확보됨
본 발명의 일 실시예에 따른 num_answer 필드는 PDI 질문에 대한 PDI 답변의 수를 지시할 수 있다.
본 발명의 일 실시예에 따른 answer_value_length 필드는 answer_value의 실제 길이를 지시할 수 있다.
본 발명의 일 실시예에 따른 answer_value 필드는 answer_type_code로 표현되는 PDI 답변의 실제 내용을 포함할 수 있다.
도 55은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 55은 도 52에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 53 및 도 54에서 설명한 바와 같다. 도 55의 구문을 구성하는 필드들은 도 54의 구문을 구성하는 필드들과 동일하므로, 이하 구체적인 설명은 생략한다.
도 56은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 56은 도 52에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 53 및 도 54에서 설명한 바와 같다. 도 56의 구문을 구성하는 기본적인 필드들은 도 54의 syntax를 구성하는 필드들과 동일하므로, 이하 구체적인 설명은 생략한다.
다만, 도 54의 구문과는 달리, 도 56의 구문은 sequence_number 필드를 더 포함할 수 있다. 본 발명의 일 실시예에 따른 sequence_number 필드에 대한 설명은 도 53에서 상술한 바와 같다.
도 57은 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로, 도 52에서 설명한 개인화 방송 시스템 상의 FLUTE 세션, 필터링 엔진 및/또는 PDI 엔진의 동작에 관한 본 발명의 일 실시예를 나타낸 도면이다.
도 57에 도시된 바와 같이 본 발명의 일 실시예에 따른 개인화 방송 시스템은 FLUTE 세션(2800), 필터링 엔진(2810) 및/또는 PDI 엔진(2820)을 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스 및 차세대 방송 서비스 등을 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
도 52에서 상술한 바와 같이, 본 발명의 일 실시예에 따른 수신기는 FLUTE 세션을 통해 PDI 테이블을 수신할 수 있다. 이하 도 57에서는 본 발명의 일 실시예에 따른 수신기가 FLUTE 세션을 통해 PDI 테이블을 수신하는 방법을 설명한다.
본 발명의 일 실시예에 따른 수신기는 FLUTE 세션(2800)을 통해 FDT 경우를 수신할 수 있다. FDT(File Delivery Table) 경우는 동일한 FLUTE 세션(2800)을 통해 전송되는 콘텐츠의 전송 단위를 의미한다. 본 발명의 일 실시예에 따른 FDT 경우는 콘텐츠의 타입을 지시하는 콘텐츠 타입 속성을 포함할 수 있다. 구체적으로, 본 발명의 일 실시예에 따른 콘텐츠 타입 속성은 FLUTE 세션(2800)을 통해 전송되는 파일이 PDI-Q 경우 문서(또는 PDI 테이블)임을 지시하는 내용을 포함할 수 있다. 본 발명의 일 실시예에 따른 콘텐츠 타입 속성에 관한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 수신기는, FDT 경우를 이용하여, FLUTE 세션(2800)을 통해 전송되는 파일이 PDI-Q 경우 문서임을 인지할 수 있다. 이후에 본 발명의 일 실시예에 따른 수신기는 PDI-Q 경우 문서를 PDI 엔진(2820)으로 전달할 수 있다. 구체적인 내용은 도 52에서 설명한 바와 같다.
도 58는 본 발명의 다른 일 실시예에 따른 FDT 경우의 XML 스키마를 나타낸 도면이다.
구체적으로 도 58는 도 57에서 설명한 FDT 경우의 XML 스키마를 나타낸 도면으로서, 이하 상술한 콘텐츠 타입 속성(2900)에 대해 설명한다.
도 58에 도시된 바와 같이, 본 발명의 일 실시예에 따른 FDT 경우는 FDT 경우 자체의 속성 정보를 지시하는 속성(2900) 및/또는 FLUTE 세션을 통해 전송되는 파일을 지시하는 file 엘리먼트(2910)를 포함할 수 있다. 도 58에 도시된 file 엘리먼트(2910)는 파일에 대한 속성 정보를 지시하는 속성을 포함할 수 있다. 도 58에 도시된 바와 같이, file 엘리먼트(2910)는 본 발명의 실시예에 따른 content type 속성(2920)을 포함할 수 있다.
도 57에서 설명한 바와 같이, 본 발명의 실시예에 따른 수신기는 content type 속성(2920)에 포함된 값을 이용하여 PDI-Q 경우 문서를 식별할 수 있다. 예를 들어, 도 58에 도시된 content type 속성(2920)은 "application/atsc-pdiq" 또는 "text/atsc-pdiq+xml"로 표현되는 MIME(Multipurpose Internet Mail Extensions) 프로토콜 형태의 값 등을 가질 수 있다.
도 59은 본 발명의 일 실시예에 따른 캐퍼빌리티 기술어 구문을 나타낸 도면이다.
구체적으로 도 59은 도 52에서 설명한 개인화 방송 시스템에 있어서, 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 식별하기 위한 구문을 나타낸다.
본 발명의 일 실시예에 따른 캐퍼빌리티 기술어는 SMT 서비스 레벨에서의 서비스 또는 NRT-IT 콘텐츠 레벨에서의 콘텐츠가 PDI 테이블인지 아닌지를 나타내기 위해 사용될 수 있다. 본 발명의 일 실시예에 따른 수신기는 해당 정보를 이용하여 서비스/콘텐츠가 PDI 테이블인지 아닌지 알고, 해당 서비스/콘텐츠가 다운로드되어야 하는지를 PDI 엔진을 지원하는 등의 캐퍼빌리티에 따라 판단한다.
이하 표 2에 표현된 코드는 PDI 테이블 시그널링에 대한 캐퍼빌리티 기술어에서 capability_code에 추가될 수 있다. 본 발명의 일 실시예에 따른 capablilty_code 값은 다른 값에 할당될 수 없다. 이하 Table 2에 표시된 capability_code 값은 설계자의 의도에 따라 다르게 설정될 수 있다.
Capability_code value 의미
... ...
0x4F HE ACC v2 with MPEG Surround
0x50 PDI 테이블(PDI-Q 포함)
... ...
도 60은 본 발명의 일 실시예에 따른 소비 모델을 나타낸 도면이다.
구체적으로 도 60은 도 52에서 설명한 개인화 방송 시스템에 있어서, 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 식별하기 위해, SMT 상에 추가된 필드를 나타낸다.
NRT 서비스 기술어는 NRT SMT의 서비스 레벨에 위치하고, 그 NRT_service_category는 서비스가 PDI 테이블을 제공하면 0x04 (PDI)가 된다. 따라서, 수신기는 필드값이 0x04이면 PDI 테이블이 제공된다고 알 수 있다.
도 60에 도시된 소비 모델의 값은 설계자의 의도에 따라 다르게 설정될 수 있다.
도 61는 본 발명의 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
구체적으로 도 61는 도 52에서 설명한 개인화 방송 시스템 상에서, 본 발명의 일 실시예에 따른 수신기가 필터링 기준 테이블을 수신하기 위한 필터링 기준 기술어의 비트 스트림 구문을 나타낸다.
본 발명의 일 실시예에 따른 필터링 기준은 본 발명의 일 실시예에 따른 수신기가 콘텐츠를 다운로드할지 판단하도록 다운로드 가능한 콘텐츠와 관련된다. ATSC 2.0 환경에는 다운로드 가능한 콘텐츠에 두 가지 카테고리가 있다. 독립형의 NRT 서비스에서의 NRT 콘텐츠 및 부속 쌍방향 데이터 서비스에서 TDO에 의해 사용되는 NRT 콘텐츠 아이템이 그에 해당한다.
이하 도 61에서는 독립형의 NRT 서비스에서의 NRT 콘텐츠를 필터링하기 위한 필터링 기준에 대해 설명한다.
본 발명의 일 실시예에 따른 NRT 서비스 및 콘텐츠 아이템에 대한 필터링 기준에서, 이하에 정의된 필터링 기준 기술어의 하나 이상의 경우는 수신기가 사용자에게 NRT 서비스를 제공할지를 결정하도록 하기 위해 SMT에서 서비스 레벨 기술어 루프에 포함될 수도 있고, 수신기가 해당 특정 콘텐츠 아이템을 다운로드 하여 사용자가 사용 가능하게 할지를 결정하도록 NRT-IT에서 콘텐츠 아이템 레벨 기술어 루프에 포함될 수도 있다.
필터링 기준 기술어의 하나 이상의 경우는 다수의 값이 동일 또는 다른 타겟 기준에 대해 제공되도록 한다. 의도하는 타겟 논리는 동일한 타겟 기준에 대해서 다수 값 사이에서 논리합이고, 서로 다른 타겟 기준 사이에서 논리곱이다.
이하 도 61에 도시된 필터링 기준 기술어의 비트 스트림 구문의 각 필드들의 시멘틱 정의에 대해 설명한다.
8비트 필드인 descriptor_tag 필드는 기술어가 본 발명의 일 실시예에 따른 필터링 기준 기술어라는 것을 나타내기 위해 0xTBD로 설정될 수 있다.
8비트 무부호 정수 필드인 descriptor_length 필드는 descriptor_length 필드 자신에 뒤따르는 바이트 수를 나타낼 수 있다.
8비트 필드인 num_ filter_criteria 필드는 도 61에 나타낸 해당 기술어에 포함된 필터링 기준의 수를 나타낼 수 있다.
8비트 필드인 criterion_id_length 필드는 criterion_id 필드의 길이를 나타낼 수 있다.
가변 길이 필드인 criterion_id 필드는 해당 기술어가 나타나는 가상 채널의 PDI 테이블에서 질문(QIA, QBA, QSA, QTA, 또는 QAA 엘리먼트)의 id 속성에 매칭되는 URI의 형태로 해당 필터링 기준의 식별자를 제공할 수 있다.
3비트 필드인 criterion_type_code 필드는 하기 표 3에 따라 해당 기준(질문)의 타입을 제공할 수 있다.
criterion_type_code 값
0x00 확보됨
0x01 정수 타입(selection id 포함), uimsbf 포맷
0x02 불 타입, "맞음"이면 0x01, "틀림"이면 0x00
0x03 스트링 타입
0x04 - 0x07 향후 ATSC 사용을 위해 확보됨
5비트 필드인 num_criterion_values 필드는 각 값이 criterion_id에 의해 식별되는 질문(QIA, QBA, QSA, QTA, 또는 QAA)에 대한 가능한 답변인 해당 필터링 기준에 대한 루프에서 타겟 기준값의 수를 제공한다.
8비트 필드인 criterion_value_length 필드는 해당 타겟 기준값을 나타낼 필요가 있는 바이트의 수를 제공한다.
가변 길이 필드인 criterion_value 필드는 해당 타겟 기준값을 제공한다.
본 발명의 일 실시예에 따른 필터링 기준 기술어는 서비스나 콘텐츠 아이템과 관련된 특정 타겟 기준에 대한 값을 나타낸다. ATSC 2.0 송출에서, 상기 정의된 filtering_criteria_descriptor()의 하나 이상의 경우는 SMT에서 NRT 서비스의 기술어 루프 또는 NRT-IT에서 콘텐츠 아이템의 기술어 루프에 들어갈 수 있다. 전자의 경우, 그것들은 서비스 자체(모든 콘텐츠 아이템)에 적용할 수 있다. 후자의 경우, 그것들은 개별 콘텐츠 아이템에 적용할 수 있다.
기술어 루프에 하나의 필터링 기준 기술어만 있고, 그것이 하나의 기준값만을 가지면, 서비스 또는 콘텐츠 아이템이 필터를 통과하는지에 대한 결정은 해당 기준값이 (criterion_id에 의해 나타낸 바와 같이) 필터링 기준에 해당하는 질문에 대한 PDI-A에서 질문 중의 값과 일치하는 경우 "맞음" (예)가 되고, 그렇지 않은 경우 "틀림" (아니오)가 될 것이다.
단일 기술어 루프의 모든 필터링 기준 기술어에서 총 기준값의 수가 1보다 크면, 각 기준값의 결과는 기준값이 (criterion_id에 의해 나타낸 바와 같이) 필터링 기준에 해당하는 질문에 대한 PDI-A에서 답변 중의 값과 일치하면 "맞음"을 답하는 중간 용어로 평가될 것이고 그렇지 않은 경우 "틀림"을 답하는 중간 용어로 평가될 것이다. 이러한 중간 용어들 중, (criterion_id에 의해 결정되는 바와 같이) 필터링 기준의 동일값을 갖는 것들은 각 타겟 기준에 대한 중간 결과를 얻기 위해 논리합이 될 것이고, 이들 중간 결과는 최종 결과를 결정하기 위해 논리곱이 될 것이다. 최종 결과가 수신기에 대해 "맞음"으로 평가되면, 이는 관련된 NRT 서비스 또는 콘텐츠 아이템이 필터를 통과하고 수신기에 다운로드 될 수 있다는 것을 의미한다.
도 62은 본 발명의 다른 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
구체적으로 도 62은 도 52에서 설명한 개인화 방송 시스템 상에서, 본 발명의 일 실시예에 따른 수신기가 필터링 기준 테이블을 수신하기 위한 필터링 기준 기술어의 비트 스트림 구문을 나타낸다.
도 62에 도시된 필터링 기준 기술어 구문의 기본적인 내용은 도 61에서 설명한 바와 같다.
그러나, criterion_type_code 필드는 하기 표에 따라 해당 기준(질문)의 타입을 제공할 수 있다.
criterion_type_code 값
0x00
0x01
0x02
0x03
0x04 - 0x07		 확보됨
정수 타입
불 타입
스트링 타입(선택 타입/텍스트 타입 포함)
향후 ATSC 사용을 위해 확보됨
도 63는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 63는, 본 발명의 일 실시예에 따른 수신기가 방송망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 36 내지 도 39에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 38 내지 도 47에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 48 내지 도 51에서 설명한 바와 같다.
도 63에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 시그널링 서버(3410), 필터링 엔진(3420), PDI 엔진(3430) 및/또는 UI(3440)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
본 발명의 일 실시예에 따른 PDI 테이블 및 필터링 기준을 처리하기 위한 필터링 엔진(3420), PDI 엔진(3430) 및/또는 UI(3440)의 동작은 도 52에서 설명한 바와 같다. 이하 도 63에 도시된 시그널링 서버(3410)의 동작을 중심으로 설명한다.
본 발명의 일 실시예에 따른 수신기는 먼저 PDI 테이블 섹션을 수신하기 위한 요청 신호를 시그널링 서버(3410)에 전송할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 쿼리 용어를 이용하여 요청 신호를 전송할 수 있다. 쿼리에 대한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 시그널링 서버(3410)는 해당 쿼리에 따른 PDI 테이블 섹션을 수신기로 전송할 수 있다. PDI 테이블 섹션에 대한 구체적인 내용은 도 53 내지 도 56에서 설명한 바와 같다.
도 64는 본 발명의 일 실시예에 따른 HTTP 요청 테이블을 나타낸 도면이다.
구체적으로 도 64는 본 발명의 일 실시예에 따른 수신기가 도 63에서 설명한 시그널링 서버로 쿼리를 전송하기 위한 HTTP 프로토콜을 나타낸다.
방송사에 의해 지원되면, 도 64에 나타낸 프로토콜은 두 개의 캐퍼빌리티를 제공할 수 있다. 첫째로, 압축되지 않은 오디오 또는 비디오만을 전달하는 경로를 통해 DTV 방송 신호를 받는 장치에 대해, 해당 프로토콜은 일반적으로 방송사의 독립형 NRT 서비스에 접속하는 유일한 방법이다. 둘째로, 완전한 방송 스트림에 접속할 수 있는 장치에 대해서도, 해당 프로토콜은 로컬 방송 영역에서 사용 가능한 모든 방송 스트림을 순환하여 원하는 테이블이 나타나기를 기다리지 않고 프로그램/서비스 가이드를 덧붙이는 데이터를 검색하는 방법을 제공한다. 이는 또한 별도의 튜너를 필요로 하지 않고 시청자가 TV를 시청하고 있는 동안에도 어느 때나 이러한 데이터의 검색을 가능하게 한다.
도 64에 도시된 HTTP 요청 테이블은, 수신하고자 하는 테이블의 종류 및 해당 테이블을 수신하기 위한 베이스 URL을 지시하는 쿼리 용어를 포함할 수 있다.
본 발명의 일 실시예에 따른 수신기는 도 64에 도시된 HTTP 요청 테이블의 쿼리 용어를 이용하여 특정 table을 수신할 수 있다. 구체적으로 본 발명의 일 실시예에 따른 수신기는 "?table=PDIT[&chan=<chan_id>]"라는 쿼리 용어를 이용하여 시그널링 서버에 요청 신호를 보낼 수 있다. 구체적인 내용은 도 63에서 설명한 바와 같다.
도 65은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 65은, 본 발명의 일 실시예에 따른 수신기가 인터넷망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 36 내지 도 39에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 38 내지 도 47에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 48 내지 도 51에서 설명한 바와 같다.
인터넷을 통해 전달될 때, PDI 테이블 경우는 HTTP 또는 HTTPS를 통해 전달될 것이다. HTTP 응답 헤더에서 PDI 테이블의 콘텐츠 타입은 "text/xml"이 될 것이다.
인터넷을 통해 PDI 테이블을 검색하기 위해 사용되는 URL은 DTV 자막 방송 채널에서 표준 자막 서비스 #6에서 이동되는 SDOPrivateDataURIString 명령어를 통해 전달될 수도 있고, TPT와 함께 전달되는 UrlList XML 엘리먼트에서 전달될 수도 있다.
TPT(TDO 파라미터 테이블)는 세그먼트의 TDO에 관한 메타데이터 및 그것들을 타겟으로 하는 이벤트를 포함한다. TDO라는 용어는 트리거링된 쌍방향 부가 데이터 서비스에서 트리거에 의해 개시된 DO(Declarative Object) 또는 트리거에 의해 개시된 DO에 의해 개시된 DO 등을 반복하여 지정하기 위해 사용된다. 트리거는 시그널링을 식별하고 쌍방향 이벤트의 재생의 타이밍을 설정하는 기능을 갖는 시그널링 엘리먼트다.
도 65에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 PDI 서버(3600), 콘텐츠 서버(3650) 및/또는 수신기를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 TPT(TDO Parameters Table) 클라이언트(3610), 필터링 엔진(3620), PDI 엔진(3630) 및/또는 UI(3640)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 65에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 TPT 클라이언트(3610)는 TPT 및/또는 URL 리스트 테이블을 수신할 수 있다. 본 발명의 일 실시예에 따른 TPT는 세그먼트의 TDO에 관한 메타데이터 및 그것들을 타겟으로 하는 이벤트를 포함한다. 본 발명의 일 실시예에 따른 TPT는 PDI 테이블 및 필터링 기준 테이블에 대한 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 URL 리스트 테이블은 PDI 서버(3600)의 URL 정보를 포함할 수 있다. TPT 및 URL 리스트 테이블에 대한 구체적인 내용은 후술한다.
또한 본 발명의 일 실시예에 따른 TPT 클라이언트(3610)는 URL 리스트 테이블로부터 PDI 서버(3600)의 URL 정보를 획득할 수 있다. TPT 클라이언트(3610)는 획득한 URL 정보를 이용하여 PDI 서버(3600)에 엑세스하고, 본 발명의 일 실시예에 따른 PDI 테이블의 전송을 요청할 수 있다. 본 발명의 일 실시예에 따른 PDI 서버(3600)는 TPT 클라이언트(3610)의 요청에 따라 해당 PDI 테이블을 TPT 클라이언트(3610)로 전송할 수 있다.
도 65에 도시된 바와 같이, 본 발명의 일 실시예에 따른 TPT 클라이언트(3610)는 수신한 PDI 테이블을 PDI 엔진(3630)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3630)은 전달받은 PDI 테이블을 처리하여, 해당 PDI 테이블에 포함된 PDI 질문들을 추출할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(3630)은 추출된 PDI 질문들을 UI(3640)로 전달할 수 있다.
본 발명의 일 실시예에 따른 UI(3640)는 전달받은 PDI 질문들을 디스플레이하고, 해당 PDI 질문들에 대한 PDI 답변들을 수신할 수 있다. 본 발명의 일 실시예에 따른 UI(3640)는 리모컨을 통해 PDI 답변들을 수신할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(3630)은 UI(3640)로부터 수신한 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있다. 구체적인 내용은 도 36 및 도 37에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 TPT 클라이언트(3610)는 TPT를 파싱하여 필터링 기준을 획득할 수 있다. 도 65에 도시된 바와 같이 TPT 클라이언트(3610)는 필터링 기준을 필터링 엔진(3620)으로 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 50 및 도 51에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(3620)은 PDI 엔진(3630)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3630)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(3620)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 38 및 도 39에서 구체적으로 설명하였다.
결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 보다 상세하게는, TPT 클라이언트(3610)는 필터링 결과를 필터링 엔진(3620)으로부터 수신하고, TDO 및/또는 콘텐츠 다운로드 요청 신호를 콘텐츠 서버(3650)에 전달할 수 있다. 콘텐츠 서버(3650)는 TDO 및/또는 콘텐츠 다운로드 요청 신호에 따라 TDO 및/또는 콘텐츠를 TPT 클라이언트(3610)로 전송할 수 있다.
도 66은 본 발명의 일 실시예에 따른 URL 리스트 테이블 나타낸 도면이다.
구체적으로 도 66은, 본 발명의 일 실시예에 따른 수신기가 인터넷망을 통해 PDI 테이블 및/또는 필터링 기준을 수신하기 위한 URL 정보를 포함한 테이블이다. 본 발명의 일 실시예에 따른 URL 리스트 테이블의 송수신 과정은 도 65에서 구체적으로 설명하였다.
URL 리스트 테이블은 인터넷을 통해 전달될 때 멀티파트(multipart) MIME 메시지의 형태로 TPT와 함께 HTTP를 통해 전달될 수 있다.
인터넷을 통해 전달될 때, TPT는 HTTP를 통해 전달될 수 있다. 현 세그먼트의 TPT에 대한 URL 정보는 DTV 자막 서비스 #6 또는 자동 콘텐츠 인식 서버를 통해 전달되며 트리거에 나타날 수 있다. TPT에 대한 요청에 응답은 현 세그먼트에 대한 TPT만으로 구성될 수도 있고, 요청된 TPT가 첫 번째 파트, 세그먼트에 대한 AMT가 선택적으로 두 번째 파트, UrlList XML 문서가 선택적으로 그 다음 파트인 멀티파트 MIME 메시지로 구성될 수도 있다.
이하, 본 발명의 일 실시예 에 따른 URL 리스트 테이블에 포함된 각 엘리먼트들의 시맨틱스에 대해 설명한다.
도 66에 나타낸 UrlList 엘리먼트는 본 발명의 일 실시예에 따른 수신기에 유용한 URL의 리스트를 포함한다.
도 66에 나타낸 UrlList 엘리먼트의 TptUrl 엘리먼트는 현 쌍방향 부가 서비스에서 추후 세그먼트에 대한 TPT의 URL 정보를 포함할 수 있다. 다수의 TptUrl 엘리먼트가 포함되면, 그것들은 방송에서 세그먼트의 출현 순으로 정렬될 것이다.
도 66에 나타낸 UrlList 엘리먼트의 NrtSignalingUrl 엘리먼트는 수신기가 해당 표준의 섹션 47에 정의된 요청 프로토콜을 이용하여 현 전송 스트림에서 모든 가상 채널에 대한 NRT 시그널링 테이블을 얻을 수 있는 서버의 URL 정보를 포함할 수 있다.
도 66에 나타낸 UrlList 엘리먼트의 UrsUrl 엘리먼트는 수신기가 해당 표준의 섹션 10에 정의된 프로토콜을 이용하여 사용 (시청률 조사) 리포트를 보낼 수 있는 서버의 URL 정보를 포함할 수 있다.
도 66에 나타낸 UrlList 엘리먼트의 PdiUrl 엘리먼트는 PDITable의 URL 정보를 포함할 수 있다. 즉, 본 발명의 일 실시예에 따른 PdiUrl 엘리먼트는, PDI 테이블 및/또는 필터링 기준을 전송할 수 있는 서버의 URL 정보를 지시할 수 있다.
상술한 도 66의 URL 리스트 테이블은 이하의 표와 같은 포맷으로 구성될 수 있다.
엘리먼트/속성(@ 포함) 허용된 넘버 데이터 타입 설명 & 값
UrlList 잠재적으로 유용한 URL의 리스트
TptUrl 0...N anyURI 추후 세그먼트의 TPT의 URL
NrtSignalingUrl 0...1 anyURI NRT 시그널링 서버의 URL
UrsUrl 0...1 anyURI 사용 보고 서버의 URL
PDIUrl 0...1 anyURI PDI-Q의 URL
도 67은 본 발명의 일 실시예에 따른 TPT를 나타낸 도면이다.
구체적으로 도 67에 도시된 TPT는, PDI 테이블 및/또는 필터링 기준의 URL 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 TPT의 송수신 과정은 도 65에서 구체적으로 설명하였다. 이하 TPT에 포함된 필터링 기준에 관한 엘리먼트를 설명한다.
구체적으로, 도 67에 도시된 Filter Criterion 엘리먼트는 필터링 기준에 대한 정보를 포함할 수 있다.
본 발명의 일 실시예에 따른 id 속성은 해당 필터링 기준에 관한 PDI 질문을 지시할 수 있다.
본 발명의 일 실시예에 따른 criterion type 속성은 필터링 기준 타입(또는 필터링 기준 타입 엘리먼트)을 지시할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준의 타입에 관하여는 도 49에서 구체적으로 설명하였다.
본 발명의 일 실시예에 따른 criterion value 속성은 상술한 기준 타입 속성에 따른 필터링 기준의 값을 나타낼 수 있다.
도 68는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 68는, 본 발명의 일 실시예에 따른 수신기가 자동 콘텐츠 인식 시스템 상에서 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템을 나타낸 도면이다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 시스템은 도 30에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 36 내지 도 39에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 38 내지 도 47에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 48 내지 도 51에서 설명한 바와 같다.
도 68에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 자동 콘텐츠 인식 서버(3900), TPT 서버(3950), PDI 서버(3960), 콘텐츠 서버(3970), 자동 콘텐츠 인식 클라이언트(3910), 필터링 엔진(3920), PDI 엔진(3930) 및/또는 UI(3940)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 68에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 핑거프린트로부터 시그니쳐를 추출하여 시그니쳐와 함께 요청을 자동 콘텐츠 인식 서버(3900)로 전송할 수 있다. 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 서버(3900)는 시그니쳐를 수신하고, 해당 시그니쳐와 연관된 트리거 등과 함께 응답을 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다. 상술한 내용은 도 30 내지 도 35에서 구체적으로 설명하였다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 수신한 트리거 등을 이용하여, TPT 서버(3950)에 TPT 및/또는 URL 리스트 테이블을 요청할 수 있다. 본 발명의 일 실시예에 따른 TPT 서버(3950)는 자동 콘텐츠 인식 클라이언트(3910)의 요청에 따라, 자동 콘텐츠 인식 클라이언트(3910)로 TPT 및/또는 URL 리스트 테이블을 전송할 수 있다. TPT 및/또는 URL 리스트 테이블에 대한 구체적인 내용은 상술한 바와 같다. 이후에 본 발명의 일 실시예에 따른 TPT 서버(3950)는 수신한 TPT 및/또는 URL 리스트 테이블을 자동 콘텐츠 인식 클라이언트(3910)로 전달할 수 있다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 URL 리스트 테이블로부터 PDI 서버(3960)의 URL 정보를 획득할 수 있다. 자동 콘텐츠 인식 클라이언트(3910)는 획득한 URL 정보를 이용하여 PDI 서버(3960)에 엑세스하고, 본 발명의 일 실시예에 따른 PDI 테이블의 전송을 요청할 수 있다. 본 발명의 일 실시예에 따른 PDI 서버(3960)는 자동 콘텐츠 인식 클라이언트(3910)의 요청에 따라 해당 PDI 테이블을 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다.
도 63에 도시된 바와 같이, 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 수신한 PDI 테이블을 PDI 엔진(3930)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3930)은 전달받은 PDI 테이블을 처리하여, 해당 PDI 테이블에 포함된 PDI 질문들을 추출할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(3930)은 추출된 PDI 질문들을 UI(3940)로 전달할 수 있다.
본 발명의 일 실시예에 따른 UI(3940)는 전달받은 PDI 질문들을 디스플레이하고, 해당 PDI 질문들에 대한 PDI 답변들을 수신할 수 있다. 본 발명의 일 실시예에 따른 UI(3940)는 리모컨을 통해 PDI 답변들을 수신할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(3930)은 UI(3940)로부터 수신한 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있다. 구체적인 내용은 도 36 및 도 37에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 TPT를 파싱하여 필터링 기준을 획득할 수 있다. 도 68에 도시된 바와 같이 자동 콘텐츠 인식 클라이언트(3910)는 필터링 기준을 필터링 엔진(3920)으로 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 50 및 도 51에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(3920)은 PDI 엔진(3930)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3930)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(3920)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 38 및 도 39에서 구체적으로 설명하였다.
결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 구체적으로, 자동 콘텐츠 인식 클라이언트(3910)는 필터링 결과를 필터링 엔진(3920)으로부터 수신하고, TDO 및/또는 콘텐츠 다운로드 요청 신호를 콘텐츠 서버(3970)에 전달할 수 있다. 콘텐츠 서버(3970)는 TDO 및/또는 콘텐츠 다운로드 요청 신호에 따라 TDO 및/또는 콘텐츠를 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다.
도 69은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 69은 PDI 답변의 중복 방지를 위한 개인화 방송 시스템의 일 실시예를 나타낸 도면이다.
보다 상세하게, 도 69은 본 발명의 일 실시예에 따른 수신기가 다수의 방송국 및 콘텐츠 제공자들로부터 동일한 PDI 질문을 수신하는 경우, 이미 저장된 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있는 개인화 방송 시스템을 나타낸다. 도 69에 도시된 개인화 방송 시스템을 통해, 사용자는 동일한 PDI 질문에 대해 중복하여 PDI 답변을 입력하는 번거로움을 줄일 수 있다.
도 69에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 2 이상의 방송국(또는 콘텐츠 제공자) 및/또는 수신기를 포함할 수 있다. 본 발명의 일 실시예에 따른 2 이상의 방송국은 방송국 A(4010) 및/또는 방송국 B(4020)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 PDI 엔진(4030) 및/또는 UI(4040)를 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 69에 도시된 각 구성 엘리먼트들의 동작을 설명한다.
먼저 본 발명의 일 실시예에 따른 수신기는 방송국 A(4010)로부터 제1 PDI 테이블(4011)을 수신할 수 있다. 제1 PDI 테이블(4011)을 수신한 수신기는 PDI 엔진(4030)으로 제1 PDI 테이블(4011)을 전달할 수 있다. 본 발명의 일 실시예에 따른 제1 PDI 테이블(4011)은 제1 PDI 타입 엘리먼트(4012)를 포함할 수 있다. 본 발명의 일 실시예에 따른 제1 PDI 타입 엘리먼트(4012) 각각은, 도 46 및 도 47에서 상술한 바와 같이 제1 식별자 엘리먼트(또는 제1 ID) 및/또는 제1 PDI 질문을 포함할 수 있다. 또한 도 69에 도시된 바와 같이 제1 PDI 테이블(4011)은 서로 다른 제1 ID를 가지는 2 이상의 제1 PDI 타입 엘리먼트(4012)들을 포함할 수 있다.
본 발명의 일 실시예에 따른 PDI 엔진(4030)은 제1 PDI 타입 엘리먼트(4012)로부터 제1 PDI 질문을 추출하고, 추출한 제1 PDI 질문을 UI(4040)로 전달할 수 있다. 이후에 본 발명의 일 실시예에 따른 UI(4040)는 사용자로부터 제1 PDI 질문에 대한 제1 PDI 답변을 수신할 수 있다. PDI 엔진(4030)은 제1 PDI 답변을 제1 PDI 타입 엘리먼트(4012)에 추가 및/또는 수정할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(4030) 및 UI(4040)의 구체적인 동작은 도 52에서 설명한 바와 같다.
또한, 본 발명의 일 실시예에 따른 PDI 엔진(4030)은 방송국 B(4020)로부터 제2 PDI 테이블(4021)을 수신할 수 있다. 본 발명의 일 실시예에 따른 제2 PDI 테이블(4021)은 제2 PDI 타입 엘리먼트(4022)를 포함할 수 있다. 도 46 및 도 47에서 상술한 바와 같이, 제2 PDI 타입 엘리먼트(4022)는 제2 식별자 엘리먼트(또는 제2 ID) 및/또는 제2 PDI 질문을 포함할 수 있다.
제2 PDI 테이블을 수신한 PDI 엔진(4030)은 PDI 기억 장치에 엑세스하여 이미 저장된 제1 PDI 테이블을 탐색할 수 있다. 이후에 본 발명의 일 실시예에 따른 PDI 엔진(4030)은 제2 ID와 제1 ID를 비교할 수 있다. 비교 결과 제2 ID와 제1 ID가 동일할 경우, 제1 PDI 답변을 제2 PDI 타입 엘리먼트(4022)에 추가 및/또는 수정할 수 있다.
결론적으로, 본 발명의 일 실시예에 따른 수신기는 이미 저장된 PDI 질문과 동일한 PDI 질문을 수신할 경우, PDI 질문을 중복하여 디스플레이하지 않고, 이미 저장된 PDI 답변을 이용하여 처리할 수 있다. 따라서 본 발명의 일 실시예에 따른 개인화 방송 시스템 상에서, 사용자는 동일한 PDI 질문에 대해 같은 내용의 PDI 답변을 중복하여 입력할 필요가 없으므로 사용자는 보다 편리하게 개인화 서비스를 제공받을 수 있다.
도 70은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 70은 PDI 답변의 중복 방지를 위한 개인화 방송 시스템의 일 실시예를 나타낸 도면이다. 도 69에서 설명한 개인화 방송 시스템은 PDI 답변의 중복 방지를 위해, 본 발명의 일 실시예에 따른 수신기에 이미 저장된 PDI 테이블을 이용할 수 있다. PDI 답변의 중복 방지를 위한 또 다른 실시예로서, 도 70에서는 PDI 질문 등록을 통한 개인화 방송 시스템을 제시한다.
소비자들이 본질적으로 동일한 질문에 대해 반복해서 급하게 답하지 않도록 서로 다른 방송사에 의해 질문을 재사용하는 것을 지원하기 위해, 질문은 ATSC에 의해 지정될 레지스트라(registrar)에 등록될 수 있다. 각 등록 기록은 도 46 및 47에 명시된 바와 같이 글로벌 유니크 질문 ID에 관한 정보, 질문 타입 (QIA, QBA, QSA, 또는 QTA), 하나 이상의 언어로 된 질문 텍스트, 등록 날짜, 및/또는 등록을 위해 질문을 제출한 단체에 대한 연락처 정보를 포함할 수 있다. 또한, QSA의 경우, 각 등록 기록(또는 선등록 PDI 질문)은 각 선택의 식별자와 같은 허용되는 선택, 및 하나 이상의 언어로 된 각 선택의 텍스트를 포함할 수 있다.
PDI 테이블은 등록된 질문 및 등록되지 않은 질문의 혼합을 포함할 수 있다.
등록된 질문 및 등록되지 않은 질문은 모두 다수의 PDI 테이블에 나타날 수 있다. 사용자가 다수의 PDI 테이블에 나타난 질문에 답할 때마다, 수신기가 제공하는 기능에 의하든지 또는 어플리케이션이 제공하는 기능에 의하든지, 답변은 그것이 나타나는 모든 설문지에 있는 질문의 모든 경우에 전파될 것으로 예상된다. 따라서, 사용자는 그것이 서로 다른 설문지에 몇 번 나타나든 어느 주어진 질문에 한 번만 답변하면 된다.
사용자에게 질문이 쇄도하는 것을 방지하기 위해, 설문지 생성자는 가능할 때마다 등록된 질문을 사용하고 등록된 질문을 얻을 수 없는 특별한 타겟 요구가 있을 때만 등록되지 않은 질문을 사용하도록 권장된다.
본 발명의 일 실시예에 따른 수신기는 수신기 타겟 기준을 이용하여 선등록 PDI 질문을 추출할 수 있다. 본 발명의 일 실시예에 따른 수신기 타겟 기준은 ATSC NRT 표준인 A/103에 따른다.
도 70에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 SSC(4100), FLUTE 세션(4110), 필터링 엔진(4120), PDI 엔진(4130) 및/또는 UI(4140)을 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 70에 도시된 개인화 방송 시스템에 대해 설명한다.
본 발명의 일 실시예에 따른 수신기는 SSC(4100)를 통해 SMT 및/또는 NRT-IT를 수신하고, SMT 및/또는 NRT-IT에 포함된 수신기 타겟 기준을 획득할 수 있다. 본 발명의 수신기 타겟 기준은 수신기 타겟 기술어 또는 수신기 타겟 기준 테이블을 일 실시예로 할 수 있다.
이후에 본 발명의 일 실시예에 따른 PDI 엔진(4130)은 획득한 수신기 타겟 기준을 변환하여 PDI 질문을 생성할 수 있다. 본 발명의 일 실시예에 따른 UI(4140)는 PDI 엔진(4130)으로부터 상술한 PDI 질문을 전달받아 디스플레이하고, 사용자의 PDI 답변을 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(4130) 및 UI(4140)의 구체적인 동작은 도 52에서 설명한 바와 같다.
도 71는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 71는 PDI 질문 등록을 통한 개인화 방송 시스템을 나타낸다.
도 71에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 시그널링 서버(4200), 수신기(4210), 필터링 엔진(4220), PDI 엔진(4230) 및 UI(4240)을 포함할 수 있다. 수신기(4210)는 필터링 엔진(4220), PDI 엔진(4230) 및/또는 UI(4240)을 포함하는 개념으로 사용될 수 있으며 이는 설계자의 의도에 따라 변경 가능하다. 또한 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 이하 도 70에 도시된 개인화 방송 시스템에 대해 설명한다.
도 71의 기본적인 구성 엘리먼트들의 동작은 도 70에서 설명한 바와 같다. 다만, 도 71에 도시된 수신기(4210)는 시그널링 서버(4200)에 SMT 및/또는 NRT-IT를 요청할 수 있다. 본 발명의 일 실시예에 다른 수신기(4210)의 요청에 따라, 시그널링 서버(4200)는 해당 SMT 및/또는 NRT-IT를 수신기(4210)로 전송할 수 있다.
본 발명의 일 실시예에 따른 수신기가 SMT 및/또는 NRT-IT를 수신한 이후에, 수신기(4210), PDI 엔진(4230) 및/또는 UI(4240)의 구체적인 동작은 도 70에서 설명한 바와 같다.
도 72은 본 발명의 일 실시예에 따른 수신기 대상 기준 테이블을 나타낸 도면이다.
구체적으로 도 72은 도 70 및 도 71에서 설명한 수신기 타겟 기준을 테이블 형식으로 표현한 도면이다.
도 72에 도시된 바와 같이 수신기 대상 기준 테이블은 타겟 기준 타입 코드(targeting criterion type code), 타겟값 길이(targeting value length) 및/또는 타겟값(targeting value)에 관한 정보를 포함할 수 있다. 도 72에 도시된 타겟 기준 타입 코드는 각각의 타겟 기준을 식별하기 위한 코드를 의미한다. 도 72에 도시된 타겟값 길이는 타겟 기준값을 나타내기 위한 바이트 수를 의미한다. 도 72에 도시된 타겟값은 타겟 기준이 나타내는 정보를 의미한다.
본 발명의 일 실시예에 따른 수신기는 타겟 기준 타입 코드에 따라 타겟 기준을 변환하여 선등록 PDI 질문을 획득할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 타겟 기준 타입 코드가 0x00인 경우, 타겟값은 보유하고, 타겟값 일이는 정해지지 않는다.
본 발명의 일 실시예에 따른 타겟 기준 타입 코드가 0x01인 경우, 타겟값은 하위 3 바이트만을 사용하는 A/65의 표 6.21에 정의된 지리적 위치이고, 타겟값 길이는 3 바이트이다. 상술한 A/65는 PSIP(Program and System Information Protocol)에 관한 ATSC 표준이다. 보다 상세한 내용은 후술한다.
본 발명의 일 실시예에 따른 타겟 기준 타입 코드가 0x02인 경우, 타겟값은 해당 영역에 적절한 바이트 수(8까지)를 사용하는 A/65의 섹션 6.7.2에 정의된 바와 같은 글자와 숫자로 쓴 우편번호이고, 타겟값 길이는 가변적이다. 보다 상세한 내용은 후술한다.
본 발명의 일 실시예에 따른 타겟 기준 타입 코드가 0x03인 경우, 타겟값은 하위 2 바이트만을 사용하는 A/65의 표 6.18에 정의된 바와 같은 인구통계학적 카테고리이고, 타겟값 길이는 2 바이트이다. 보다 상세한 내용은 후술한다.
본 발명의 일 실시예에 따른 타겟 기준 타입 코드가 0x04 - 0x0F인 경우, 타겟값은 추후 ATSC 사용을 위해 보유되고, 타겟값 길이는 정해지지 않는다.
본 발명의 일 실시예에 따른 타겟 기준 타입 코드가 0x10 - 0x1F인 경우, 타겟값은 사적 사용이 가능하고, 타겟값 길이는 정해지지 않는다.
도 73 내지 도 76은 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 73 내지 도 76은, 도 72에서 상술한 타겟 기준 타입 코드가 0x01인 경우로서, 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 테이블들이다.
도 73 내지 도 76에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 지리적 위치에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 하위 3 바이트만을 사용하여 타겟 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다.
도 73는 타겟 기준 타입 코드가 0x01인 경우로서, 위치 코드(location code)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 73에 도시된 선등록 PDI 질문 table에 포함된 선등록 PDI 질문 정보는 도 70에서 설명한 바와 같다.
구체적으로 도 73에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 위치 코드에 관한 정보를 포함할 수 있다. 또한 도 73에 도시된 선등록 PDI 질문은 QTA 타입으로서, 위치 코드에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 8]는 도 73에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 8]
<a20:QTA id="atsc.org/PDIQ/location-code">
<a20:Q xml:lang="en-us">
<a20:Text>What is your location code?</a20:Text>
</a20:Q>
</a20:QTA>
도 74는 타겟 기준 타입 코드가 0x01인 경우로서, FIPS(Federal Information Processing Standards Publication) state에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 74에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 70에서 설명한 바와 같다. 다만 도 74에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 74에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 FIPS state에 관한 정보를 포함할 수 있다. 또한 도 74에 도시된 선등록 PDI 질문은 QTA 타입으로서, FIPS state에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 9]은 도 74에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 9]
<a20:QTA id="atsc.org/PDIQ/state" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What state are you located in?</a20:Text>
</a20:Q>
</a20:QTA>
도 75은 타겟 기준 타입 코드가 0x01인 경우로서, FIPS country에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 75에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 70에서 설명한 바와 같다. 다만 도 75에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 75에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 FIPS country에 관한 정보를 포함할 수 있다. 또한 도 75에 도시된 선등록 PDI 질문은 QTA 타입으로서, FIPS country에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 10]는 도 75에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 10]
<a20:QTA id="atsc.org/PDIQ/county" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What county are you located in?</a20:Text>
</a20:Q>
</a20:QTA>
도 76은 타겟 기준 타입 코드가 0x01인 경우로서, 자치주 세분(county subdivision)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 76에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 70에서 설명한 바와 같다. 다만 도 76에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 76에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 자치주 세분에 관한 섹터 정보를 포함할 수 있다. 또한 도 76에 도시된 선등록 PDI 질문은 QSA 타입으로서, 자치주 세분에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 QSA 타입의 선등록 PDI 질문은 PDI 답변에 대한 선택지(selection) 정보를 포함할 수 있다. 예를 들어, 도 76에 도시된 자치주 세분에 관한 선등록 PDI 질문은 북서, 북중, 북동, 서중, 중앙, 동중, 남서, 남중, 및 남동에 대한 9가지 선택 정보를 포함할 수 있다.
이하 [예시 11]는 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 11]
<a20:QSA id="atsc.org/PDIQ/sector" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What part of your county are you located in?
</a20:Text>
<a20:Selection id="1">NW</a20:Selection>
<a20:Selection id="2">NC</a20:Selection>
<a20:Selection id="3">NE</a20:Selection>
<a20:Selection id="4">WC</a20:Selection>
<a20:Selection id="5">C</a20:Selection>
<a20:Selection id="6">EC</a20:Selection>
<a20:Selection id="7">SW</a20:Selection>
<a20:Selection id="8">SC</a20:Selection>
<a20:Selection id="9">SE</a20:Selection>
</a20:Q>
</a20:QTA>
상술한 도 74 내지 도 76에 도시된 question xactionSetId는 유사한 내용을 포함하는 PDI 질문들의 집합을 지시할 수 있다. 본 발명의 일 실시예에 따른 수신기는 동일한 question xactionSetId를 포함하는 선등록 PDI 질문들을 조합하여 개인화 방송 서비스에 이용할 수 있다.
예를 들어, 도 73에 도시된 수신기 타겟 기준은, 동일한 question xactionSetId를 가지는 도 74 내지 도 76의 수신기 타겟 기준으로도 표현될 수 있다. 본 발명의 일 실시예에 따른 수신기는 도 73에 도시된 수신기 타겟 기준 및/또는 도 74 내지 도 76의 수신기 타겟 기준을 조합한 결과를 이용하여 개인화 방송 서비스를 제공할 수 있다.
도 77 및 도 78는 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 77 및 도 78는, 도 72에서 상술한 타겟 기준 타입 코드가 0x02인 경우, 선등록 PDI 질문을 나타낸 테이블들이다.
도 77 및 도 78에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 글자와 숫자로 쓴 우편번호에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 영역에 따른 적절한 수의 바이트를 사용하여 목표 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다. 본 발명의 일 실시예에 따른 수신기는 목표 기준 테이블 변환을 위해 최대 8 바이트를 사용할 수 있다.
도 77은 타겟 기준 타입 코드가 0x02인 경우로서, 다섯 자리 우편 번호에 관한 선등록 PDI 질문을 나타낸 테이블이다. 다섯 자리 우편 번호는 미국에서 사용하는 글자와 숫자로 쓴 우편번호를 의미한다. 도 77에 도시된 선등록 PDI 질문이 포함하는 내용은 도 70에서 설명한 바와 같다.
구체적으로 도 77에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 질문 ID는 우편 번호에 관한 정보를 포함할 수 있다. 또한 도 77에 도시된 선등록 PDI 질문은 QTA 타입으로서, 우편 번호에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 12]은 도 77에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 12]
<a20:QTA id="atsc.org/PDIQ/ZIPcode">
<a20:Q xml:lang="en-us">
<a20:Text>What is your 5-digit ZIP code?</a20:Text>
</a20:Q>
</a20:QTA>
도 78는 타겟 기준 타입 코드가 0x02인 경우로서, 수로 나타낸 우편번호에 관한 선등록 PDI 질문을 나타낸 테이블이다. 수로 나타낸 우편번호는 미국 이외의 지역에서 사용하는 글자와 숫자로 쓴 우편번호를 의미한다. 도 78에 도시된 선등록 PDI 질문이 포함하는 내용은 도 70에서 설명한 바와 같다.
구체적으로 도 78에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 질문 ID는 우편 번호에 관한 정보를 포함할 수 있다. 또한 도 78에 도시된 선등록 PDI 질문은 QTA 타입으로서, 우편 번호에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 13]은 도 78에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 13]
<a20:QTA id="atsc.org/PDIQ/ZIPcode">
<a20:Q xml:lang="en-us">
<a20:Text>What is your 5-digit ZIP code?</a20:Text>
</a20:Q>
</a20:QTA>
도 79 내지 도 82 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 79 내지 도 82은, 도 72에서 상술한 타겟 기준 타입 코드가 0x03인 경우로서, 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 테이블들이다.
도 79 내지 도 82에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 사용자의 인구통계 카테고리에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 하위 2 바이트만을 사용하여 타겟 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다.
도 79은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 성별에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 50에 도시된 선등록 PDI 질문이 포함하는 내용은 도 70에서 설명한 바와 같다.
구체적으로 도 79에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 성별에 관한 정보를 포함할 수 있다. 또한 도 79에 도시된 선등록 PDI 질문은 QSA 타입으로서, 사용자의 성별에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 79에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 79에 도시된 성별에 관한 선등록 PDI 질문은, 남성 및 여성에 대한 2가지 선택 정보를 포함할 수 있다.
이하 [예시 14]은 도 79에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 14]
<a20:QSA id="atsc.org/PDIQ/gender" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text>What is your gender?</a20:Text>
<a20:Selection id="1">Male</a20:Selection>
<a20:Selection id="2">Female</a20:Selection>
</a20:Q>
</a20:QSA>
도 80은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 연령대(age bracket)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 80에 도시된 선등록 PDI 질문이 포함하는 내용은 도 70에서 설명한 바와 같다.
구체적으로 도 80에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 연령대에 관한 정보를 포함할 수 있다. 또한 도 80에 도시된 선등록 PDI 질문은 QSA 타입으로서, 연령대에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 80에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 51에 도시된 연령대에 관한 선등록 PDI 질문은, 2-5세, 6-11세, 12-17세, 18-34세, 35-49세, 50-54세, 55-64세, 65세 이상에 대한 8가지 선택 정보를 포함할 수 있다.
이하 [예시 15]은 도 80에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 15]
<a20:QSA id="atsc.org/PDIQ/age-bracket" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text> What age bracket are you in</a20:Text>
<a20:Selection id="1">Ages 2-5</a20:Selection>
<a20:Selection id="2">Ages 6-11</a20:Selection>
<a20:Selection id="3">Ages 12-17</a20:Selection>
<a20:Selection id="4">Ages 18-34</a20:Selection>
<a20:Selection id="5">Ages 35-49</a20:Selection>
<a20:Selection id="6">Ages 50-54</a20:Selection>
<a20:Selection id="7">Ages 55-64</a20:Selection>
<a20:Selection id="8">Ages 65+</a20:Selection>
</a20:Q>
</a20:QSA>
도 81는 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 근로 여부에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 81에 도시된 선등록 PDI 질문이 포함하는 내용은 도 70에서 설명한 바와 같다.
구체적으로 도 81에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 근로에 관한 정보를 포함할 수 있다. 또한 도 81에 도시된 선등록 PDI 질문은 QSA 타입으로서, 사용자의 근로 여부에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 81에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 79에 도시된 근로에 관한 선등록 PDI 질문은, 예 및 아니오에 대한 2가지 선택 정보를 포함할 수 있다.
이하 [예시 16]은 도 81에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 16]
<a20:QSA id="atsc.org/PDIQ/working" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text>Are you working at a paying job?
</a20:Text>
<a20:Selection id="1">Yes</a20:Selection>
<a20:Selection id="2">No</a20:Selection>
</a20:Q>
</a20:QSA>
도 82은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 성별에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 82에 도시된 선등록 PDI 질문이 포함하는 내용은 도 70에서 설명한 바와 같다.
구체적으로 도 82에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 근로에 관한 정보를 포함할 수 있다. 또한 도 82에 도시된 선등록 PDI 질문은 QBA 타입으로서, 사용자의 근로 여부에 관한 불 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 17]은 도 82에 도시된 테이블을 XML 스키마로 나타낸 일 실시예이다.
[예시 17]
<a20:QBA id="atsc.org/PDIQ/working" >
<a20:Q xml:lang="en-us">
<a20:Text>Are you working at a paying job?
</a20:Q>
</a20:QBA>
도 83는 본 발명의 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 83는 상술한 선언 콘텐츠 오브젝트(DO) 등의 어플리케이션이 PDI 데이터를 이용하기 위한 함수를 나타낸 도면이다. 본 발명의 일 실시예에 따른 PDI API는 본 발명의 일 실시예에 따른 수신기가 PDI 기억 장치에 엑세스하기 위한 인터페이스를 의미한다.
ATSC 2.0 클라이언트 장치는 PDI 질문에 대한 접근(예를 들면, 검색 및 갱신)을 가능하게 하기 위해 PDI API를 지원한다.
ATSC 2.0 DAE의 일환으로 제공되는 API는 저장 장치로부터 해당 질문의 텍스트를 불러오고, (가능하다면) 해당 질문에 대해 이미 제공된 답변을 불러오고, 해당 질문에 대한 답변을 저장하기 위해 주어진 질문의 ID를 고려하여 DO를 허용한다.
TDO가 어느 특정 질문 또는 답변에 대해 접근하거나 기록하는 것을 방지하는 어느 규칙을 정의하거나 실시하는 시도가 이루어지지 않는다. 다수의 개체가 주어진 채널에서 사용 가능한 설문지를 제공할 수 있는 것이 구상된다. 이러한 객체는 국가의 전송망 사업자, 로컬 방송사 계열회사, 다양한 프로그램 생산자/공급자를 포함할 수 있는데 이에 제한되지 않는다.
ATSC 2.0 클라이언트 장치는 PDI 데이터 저장 및 검색을 위한 API를 실현한다. PDI 기능을 실행하기 위해, 장치는 네이티브 어플리케이션, 파일 시스템/데이터베이스를 사용하거나 원격 서비스를 사용하여 PDI 데이터베이스를 제공할 수 있다. PDI 기억 장치는 ATSC 클라이언트에 구속되어 있다. 하나의 PDI 기억 장치 경우만이 클라이언트를 위해 존재한다. PDI 기억 장치는 DO가 클라이언트의 PDI 데이터에 접속할 수 있도록 하며, 또한 사용자가 네이티브 어플리케이션을 통해 서로 다른 서비스 제공자에 걸쳐 지속적으로 PDI 질문을 관리(예를 들면, 갱신, 추가, 또는 삭제)할 수 있도록 한다.
도 83는 본 발명의 일 실시예에 따른 PDI API를 나타낸 테이블이다. 본 발명의 일 실시예에 따른 수신기는 도 83에 도시된 PDI API를 이용하여 PDI 테이블 리스트를 획득할 수 있다.
이하 도 83에 도시된 API에 대해 설명한다.
도 83에 도시된 API의 명칭은 getPDITableList()로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 83에 도시된 설명은 getPDITableList() API 함수의 상세 내용을 나타낸다. 도 83에 도시된 인수(arguments)는 getPDITableList() API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 83에 나타낸 설명은 getPDITableList() API 함수가 각각에 대해 pdiTableId를 제공하며 PDI 테이블의 리스트를 갖는 XML 구조를 응답한다는 것을 나타낸다. XML 구조는 다음의 XML 스키마와 같다. 하나의 pdiTableId 하위 엘리먼트를 갖는 pdiTableList 엘리먼트는 카디널리티 0을 갖고 무한하다. 0 pdiTableId 경우는 방송사가 PDI 테이블을 제공하지 않았다는 것을 나타낸다.
도 83에 나타낸 인수는 pdiTableId가 PDI 테이블의 글로벌 유니크 식별자라는 것을 URI의 형태로 나타낸다.
따라서 본 발명의 일 실시예에 따른 수신기는 XML 스키마에 따른 테이블 포맷의 PDI 테이블 리스트를 수신할 수 있다. 도 83에 도시된 바와 같이, PDI 테이블 리스트는 pdiTableId 엘리먼트를 포함할 수 있다. 도 83에 도시된 pdiTableId 엘리먼트의 카디널리티가 0을 지시할 경우, 본 발명의 일 실시예에 따른 수신기가 방송사로부터 PDI 테이블을 수신하지 않았음을 의미할 수 있다.
도 84는 본 발명의 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 84는 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 획득하기 위한 PDI API를 나타낸 도면이다.
이하 도 84에 도시된 API에 대해 설명한다.
도 84에 도시된 API의 명칭은 getPDITable(String pdiTableId)로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 84에 도시된 설명은 getPDITable(String pdiTableId) API 함수의 상세 내용을 나타낸다. 도 84에 도시된 인수는 getPDITable(String pdiTableId) API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 84에 나타낸 설명은 getPDITable(String pdiTableId) API 함수가 수신기에 대해 PDI 테이블 XML 문서를 응답하기 위한 것임을 나타낸다. 각 pdiTable은 해당 방법에 대한 입력으로 제공된 글로벌 유니크 pdiTableId 식별자에 의해 식별된 것과 관련되어 있다. 응답된 값은 연재된 PDI 테이블 XML 경우를 포함하며 선택적으로 PDI-Q 또는 PDI-A XML 경우를 포함하는 스트링이다.
도 84에 나타낸 인수는 pdiTableId가 PDI 테이블의 글로벌 유니크 식별자라는 것을 URI의 형태로 나타낸다.
따라서 본 발명의 일 실시예에 따른 수신기는, 도 83에서 설명한 PDI 테이블 리스트를 수신한 후에, PDI 테이블을 수신할 수 있다. 구체적으로 PDI 테이블 리스트를 수신한 수신기는, 도 83에 도시된 pdiTableId에 연관된 PDI 테이블 XML 문서를 수신할 수 있다.
구체적으로, 도 55에 도시된 PDI API에 따른 수신기의 동작은 도 36 내지 39, 도 52, 도 63, 도 65 및 도 68 내지 도 71에서 설명한 바와 같다. 또한 도 84에 도시된 PDI API에 따른 수신기는 도 40내지 도 47에서 설명한 PDI 테이블 포맷에 따른 PDI 테이블 리스트를 수신할 수 있다.
도 85은 본 발명의 또 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 85은 본 발명의 일 실시예에 따른 수신기가 PDI 답변을 획득하기 위한 PDI API를 나타낸 도면이다.
이하 도 85에 도시된 API에 대해 설명한다.
도 85에 도시된 API의 명칭은 getPDIA(String pdiTableId)로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 85에 도시된 설명은 getPDIA(String pdiTableId) API 함수의 상세 내용을 나타낸다. 도 85에 도시된 인수는 getPDIA(String pdiTableId) API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 85에 나타낸 설명은 getPDIA(String pdiTableId) API 함수가 수신기에 대해 PDI-A XML 문서를 응답하기 위한 것임을 나타낸다. 각 pdiTable은 해당 방법에 대한 입력으로 제공된 글로벌 유니크 pdiTableId 식별자에 의해 식별된 것과 관련되어 있다. 응답된 값은 연재된 PDI-A XML 경우를 포함하는 스트링이다.
도 85에 나타낸 인수는 pdiTableId가 PDI 테이블의 글로벌 유니크 식별자라는 것을 URI의 형태로 나타낸다.
따라서 도 83에서 설명한 PDI 테이블 리스트를 수신한 수신기는, 도 83에 도시된 pdiTableId에 연관된 PDI-A 테이블의 XML 문서(또는 PDI-A 경우 문서)를 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI-A 경우 문서는 도 46에서 설명한 바와 같다.
구체적으로, 도 85에 도시된 PDI API에 따른 수신기의 동작은 도 36 내지 39, 도 52, 도 63, 도 65 및 도 68 내지 도 71에서 설명한 바와 같다.
도 83 내지 85에 나타내지 않았지만, 본 실시예에 따른 PDI API는 아래의 표들 같이 서술할 수 있다.
Object getPDI(String id)
설명 QxA 하위 엘리먼트가 주어진 식별자 QxA@id에 의해 식별되는 PDI 질문인 PDI QxAD 엘리먼트를 루트 엘리먼트로 포함하는 XML 문서를 나타내는 XML DOM 오브젝트를 응답. 해당 주어진 식별자의 값을 갖는 PDI 질문이 존재하지 않으면, 해당 방법은 널(null)을 응답한다.
주의: 질문 식별자의 주어진 값을 갖는 하나의 PDI 질문만이 PDI 기억 장치에 존재할 수 있다. 일관성이 유지되는 한, 하나가 넘는 PDI 테이블은 동일한 질문 식별자의 PDI 질문을 보유할 수 있다.
인수 id PDI 질문의 식별
void setPDI(object id)
설명 우선 주어진 오브젝트에 의해 나타내어지는 QxAD 문서에서 QxA 엘리먼트에 해당하는 PDI 질문이 PDI 기억 장치에 이미 존재하는지 확인. 존재하지 않으면, 해당 방법은 아무 것도 하지 않는다. 존재하면, 저장된 PDI 질문은 주어진 것으로 갱신될 것이다. PDI 질문의 답변 엘리먼트 QxA.A만이 갱신될 수 있다. PDI 테이블의 PDITable@pdiTableVersion의 값은 변하지 않는다. 갱신된 PDI 질문이 서로 다른 PDI 테이블에 의해 공유되면, 관련 테이블은 버전 갱신 없이 변화될 것이다. 해당 방법은 저장 용량이 초과되면 QUOTA_EXCEEDED_ERR exception을 투입하고, 또는 무효 문서가 특정되면 WRONG_DOCUMENT_ERR exception을 투입할 것이다. 해당 방법은 실패에 대해 어토믹(atomic)하다. 실패의 경우, 해당 방법은 아무 것도 하지 않는다. 즉, 데이터 저장 영역에 대한 변화가 성공적이거나, 데이터 저장 영역이 전혀 변화되지 않아야 한다.
인수 id 답변이 저장될 PDI 질문 오브젝트를 나타내는 오브젝트.
도 86 은 본 발명의 일 실시예에 따른, 차세대 방송 시스템을 위한 프로토콜 스택 (Protocol Stack) 을 도시한 도면이다.
본 발명은 지상파 방송망과 인터넷망 연동 기반 차세대 하이브리드 방송 환경에 있어서, 전술한 PDI 정보를 수신기와 컴패니언 디바이스 간에 교환하기 위한 방안을 제안할 수 있다. 본 발명에서는, 전술한 PDI 정보가 수신기에서만 활용되지 않고 컴패니언 디바이스에 제공될 수 있다. 유저는 컴패니언 디바이스를 활용하여 PDI 정보가 반영된 인터랙티브 서비스를 제공받을 수 있다.
하지만, 한 명의 유저가 여러 개의 컴패니언 디바이스를 사용할 수 있다. 이 경우, 각 컴패니언 디바이스마다 PDI 유저 데이터를 설정하게 된다면, 그 유저는 중복된 응답을 계속해야 할 수 있다. 따라서 PDI 유저 데이터가 여러 컴패니언 디바이스 간에 공유될 필요가 있다. 따라서, 본 발명은 수신기와, 복수 개의 컴패니언 디바이스들 간에 PDI 정보를 교환/공유하는 방안을 제안한다. 여기서 교환/공유되는 PDI 정보에는 전술한 PDI Question, Answer 및/또는 필터링 크리테리아(Filtering Criteria) 등이 있을 수 있다.
또한 본 발명은 복수의 사용자의 PDI 정보를 제공/저장 및 그를 활용하여 필터링된 인터랙티브 서비스를 제공하는 방법을 제안한다.
또한, 본 발명은 보여지는 정보에 대한 선호도, 즉 프리젠테이션 선호도(Presentation Preference) 를 개인화하기 위하여, 전달받은 관련 정보를 PDI Question 으로 변환하여 사용자에게 보여주는 방안을 제안한다. 또한, 본 발명은 이미 설정된 프리젠테이션 선호도를 업데이트 하는 방안에 대해서도 제안한다.
본 발명에 따른 방송 시스템은, IP (Internet Protocol) 중심 브로드캐스트 네트워크 (IP centric broadcast network)와 브로드밴드 (broadband) 가 결합된 하이브리드 방송 시스템에 해당될 수 있다.
본 발명에 따른 방송 시스템은, 기존의 MPEG-2 기반의 방송 시스템 과의 호환성을 유지하도록 설계될 수 있다.
본 발명에 따른 방송 시스템은, IP 중심 브로드캐스트 네트워크 (IP centric broadcast network), 브로드밴드 (broadband) 네트워크, 및/또는 이동통신 네트워크 (mobile communication network 또는 cellular network) 의 결합에 기반한 하이브리드 방송 시스템에 해당될 수 있다.
도면을 참조하면, 물리적 계층 (Physical layer) 은, ATSC 시스템 및/또는 DVB 시스템과 같은 방송 시스템에서 채용하는 물리적 프로토콜을 이용할 수 있다. 예를 들면, 본 발명에 따른 물리적 계층에서는, 송/수신기는 지상파 방송 신호을 송신/수신하고 방송 데이터를 포함하는 전송 프레임 (transport frame)를 적절한 형태로 변환할 수 있다.
암호화 (Encapsulation) 계층에서는, 물리적 계층으로부터 획득된 정보로부터, IP 데이터그램 (datagram) 을 획득하거나, 획득된 IP 데이터그램을 특정 프레임 (예를 들어, RS Frame, GSE-lite, GSE 혹은 신호 프레임 등)으로 변환한다. 여기서, 프레임은 IP 데이터 그램들의 집합을 포함할 수 있다. 예를 들면, 암호화 계층에서 송신기는, 물리적 계층으로부터 처리된 데이터를 전송 프레임에 포함시키거나, 수신기는, 물리적 계층으로부터 획득한 전송 프레임에서 MPEG-2 TS, IP 데이터 그램을 추출한다.
FIC(fast information channel)는 서비스 및/또는 콘텐츠에 접근할 수 있도록 하기 위한 정보 (예, 서비스 ID와 프레임 간의 매핑 정보 등)를 포함한다. FIC는 FAC (Fast Access Channel) 로 명명 될 수도 있다.
본 발명의 방송 시스템은 IP (Internet Protocol), UDP (User Datagram Protocol), TCP (Transmission Control Protocol), ALC/LCT (Asynchronous Layered Coding / Layered Coding Transport), RCP/RTCP (Rate Control Protocol / RTP Control Protocol), HTTP (Hypertext Transfer Protocol), FLUTE (File Delivery over Unidirectional Transport) 등의 프로토콜을 이용할 수 있다. 이들 프로토콜 간의 스택 (stack) 은 도면에 도시된 구조를 참조할 수 있다.
본 발명의 방송 시스템에서 데이터는 ISOBMFF (ISO base media file format) 형태로 전송될 수 있다. ESG (Electrical Service Guide), NRT (Non Real Time), A/V (Audio / Video) 및/또는 일반 데이터는 ISOBMFF의 형태로 전송될 수 있다.
브로드캐스트 네트워크에 의한 데이터의 전송은, 리니어 컨텐츠(linear content)의 전송 및/또는 논-리니어 컨텐츠(non-linear content)의 전송을 포함할 수 있다.
RTP/RTCP 기반 A/V, Data(closed caption, emergency alert message 등) 전송은 리니어 컨텐츠의 전송에 해당될 수 있다.
RTP payload는 NAL (Network Abstraction Layer) 이 포함된 RTP/AV 스트림 형태 및/또는 ISO based media file format 으로 암호화(encapsulation) 된 형태로 전송될 수 있다. RTP payload의 전송은 리니어 컨텐츠의 전송에 해당될 수 있다. ISO based media file format 으로 암호화된 형태의 전송은 A/V 등에 대한 MPEG DASH 미디어 세그먼트를 포함할 수 있다.
FLUTE 기반 ESG의 전송, 논-타임드 데이터(non-timed data)의 전송, NRT content의 전송은 논-리니어 컨텐츠의 전송에 해당될 수 있다. 이들은 MIME type 의 파일 형태 및/또는 ISO based media file format 으로 암호화(encapsulation)된 형태로 전송될 수 있다. ISO based media file format 으로 암호화된 형태의 전송은 A/V 등에 대한 MPEG DASH 미디어 세그먼트를 포함할 수 있다.
브로드밴드 네트워크에 의한 전송은 컨텐츠에 대한 전송과 시그널링 데이터에 대한 전송으로 분리하여 생각할 수 있다.
컨텐츠의 전송은 리니어 컨텐츠 (A/V, data(closed caption, emergency alert message 등) 의 전송과 논-리니어 컨텐츠 (ESG, non-timed data 등)의 전송, MPEG DASH 기반의 미디어 세그먼트(A/V, data) 전송을 포함한다.
시그널링 데이터의 전송은, 방송망에서 전송되는 시그널링 테이블(signaling table) (MPEG DASH 의 MPD 포함)을 포함하는 전송이 가능하다.
본 발명의 방송 시스템에서는 방송망을 통해 전송된 리니어/논-리니어 콘텐츠 간의 동기화, 혹은 방송망을 통해 전송되는 컨텐츠와 broadband 을 통해 전송된 콘텐츠 간의 동기화를 지원할 수 있다. 예를 들어, 하나의 UD 콘텐츠가 방송망과 broadband 을 통해 나눠서 동시에 전송되는 경우, 수신기는 전송 프로토콜에 의존적인 타임라인을 조정하고, 방송망의 컨텐츠와 브로드밴드의 컨텐츠를 동기화 후 하나의 UD 콘텐츠로 재구성할 수 있다.
본 발명의 방송 시스템의 Applications 계층은 양방향성 (Interactivity), 개인 맞춤화(Personalization), Second Screen, ACR (automatic content recognition) 등의 기술적 특징을 구현할 수 있다. 이러한 특징은, 예를 들면, 북미 방송 표준인 ATSC2.0 에서 ATSC3.0으로 확장에서 중요한 특징이다. 예를 들면, 양방향성의 특징을 위하여, HTML5 가 사용될 수 있다.
본 발명의 방송 시스템의 Presentation 계층에서는, 컴포넌트들 사이 또는 양방향 어플리케이션들 사이의 공간적, 시간적 관계를 식별하기 위하여 HTML 및/또는 HTML5가 사용될 수 있다.
본 발명에서 시그널링 (Signaling) 은 콘텐츠 및/또는 서비스의 효과적인 획득을 지원하기 위한 시그널링 정보를 포함한다. 시그널링 데이터는 바이너리 혹은 XML형태 등으로 표현할 수 있으며, 지상파 방송망 혹은 broadband 을 통하여 전달될 수 있다.
실시간 방송 A/V 콘텐츠 및/또는 Data 의 경우 ISO Base Media File Format 등으로 표현 될 수 있다. 이 경우, 방송 A/V 콘텐츠 및/또는 Data 는 지상파 방송망을 통하여 실시간으로 전달될 수 있으며, IP/UDP/FLUTE을 기반으로 비실시간으로 전달될 수 있다. 또는, 방송 A/V 콘텐츠 및/또는 Data를, 인터넷 망을 통하여 DASH (Dynamic Adaptive Streaming over HTTP) 등을 이용하여 실시간으로 콘텐츠를 스트리밍 받거나 요청하여 받을 수 있다. 본 발명의 일 실시예에 따른 방송 시스템은, 이렇게 전달받은 방송 A/V 콘텐츠 및/또는 Data 를 조합하여 Interactive 서비스, second screen 서비스 등 다양한 enhanced service 을 시청자에게 제공할 수 있다.
도 87 은 본 발명의 일 실시예에 따른 UPnP 방식의 액션(Action) 메커니즘을 도시한 도면이다.
먼저, 본 발명에서의 기기간 커뮤니케이션에 대하여 설명한다.
기기간 커뮤니케이션이란, 기기간에 메시지/명령(command)/콜(call)/액션(action)/요청(request)/응답(response) 를 교환하는 것을 의미할 수 있다.
기기간에 메시지를 원하는 대상 기기에 안정적으로 전달하기 위하여, IP (Internet Protocol) 뿐 아니라 ICMP (Internet Control Message Protocol), IGMP (Internet Group Management Protocol) 등의 다양한 프로토콜이 적용될 수 있다. 이 때, 본 발명은 특정 프로토콜에 국한되지 아니한다.
기기간 커뮤니케이션에 사용되는 메시지에 다양한 정보를 담기 위하여, HTTP (Hypertext Transfer Protocol), RTP (Real-time Transport Protocol), XMPP (Extensible Messaging and Presence Protocol), FTP (File Transfer Protocol) 등의 다양한 프로토콜이 적용될 수 있다. 이 때, 본 발명은 특정 프로토콜에 국한되지 아니한다.
기기간 커뮤니케이션에 사용되는 메시지를 전달할 때, 각 프로토콜이 정의하는 메시지 헤더/메시지 바디 등의 다양한 컴포넌트가 활용될 수 있다. 즉, 각 메시지 컴포넌트에 데이터가 저장되어 전달될 수 있으며, 특정 메시지 컴포넌트에 국한되지 아니한다. 또한, 메시지에 의해 전달되는 데이터는 각 프로토콜이 정의하는 다양한 타입(string, integer, floating point, boolean, character, array, list 등) 으로 전달될 수 있다. 복잡한 내용의 데이터를 구조적으로 표현/전달/저장하기 위해 XML (Extensible Markup Language), HTML (Hypertext Markup Language), XHTML (Extensible Hypertext Markup Language), JSON (JavaScript Object Notation) 등의 마크업(Markup) 방식 혹은 텍스트, 이미지 포맷 등이 적용될 수 있다. 이 때, 본 발명은 특정 방식에 국한되지 아니한다.
또한, 기기간 커뮤니케이션에 사용되는 메시지는 데이터를 압축하여 전달할 수 있는데, 본 발명은 특정 방식의 압축기술을 적용하는 것에 국한되지 아니한다.
전술한 본 발명에서의 기기간 커뮤니케이션에 대한 설명 중, 한가지 방식인 UPnP 방식에 대하여 설명한다. UPnP 방식은 전술한 기기간 커뮤네케이션에 관한 설명 중에서, IP-TCP/UDP-HTTP의 프로토콜이 조합된 경우에 해당할 수 있다.
도시된 본 발명의 일 실시예에 따른 UPnP 방식의 액션(Action) 메커니즘이란, UPnP 컨트롤 포인트와 UPnP 디바이스 간의 커뮤니케이션 매커니즘을 의미할 수 있다. 여기서 UPnP 컨트롤 포인트(t87010) 은 HTTP 클라이언트일 수 있고, UPnP 디바이스(t87020) 은 HTTP 서버일 수 있다. UPnP 컨트롤 포인트(t87010) 는 액션이라 불리우는 일종의 메시지를, UPnP 디바이스(t87020) 에 전달하여, UPnP 디바이스(t87020) 가 특정한 동작을 수행하도록 할 수 있다.
여기서, UPnP 컨트롤 포인트(t87010) 과 UPnP 디바이스(t87020) 은 페어링되어 있을 수 있다. 페어링은 각 디바이스들 간에 디스커버리 및 디스크립션 전달과정을 통해 수행될 수 있다. UPnP 컨트롤 포인트는 페어링 과정을 통해 컨트롤 URL 을 획득할 수 있다.
UPnP 컨트롤 포인트(t87010) 는 각 액션을 XML 의 형태로 표시할 수 있다. UPnP 컨트롤 포인트(t87010) 는 HTTP 에서 정의한 POST 메쏘드(t87030) 를 이용하여, 획득한 컨트롤 URL로 전달할 수 있다. 각 액션은 일종의 메시지로 실제 전달하고자 하는 데이터일 수 있으며, 이는 HTTP POST 메시지 바디에 XML 형태로 전달될 수 있다. 여기서, 각 액션은 이름(Name) 과, 아규먼트(arguments), 관련 데이터 들을 포함할 수 있다. HTTP POST 메시지 바디는, 각 액션의 이름 및/또는 아규먼트를 전달할 수 있다.
이 때, 각 액션은 같은 컨트롤 URL 로 전달될 수 있다. UPnP 디바이스(t87020) 는 전달받은 액션을 XML 파서(parser) 를 이용하여 파싱을 수행할 수 있다. UPnP 디바이스(t87020) 는 파싱한 각 액션에 따라 해당 동작을 수행할 수 있다.
UPnP 프로토콜의 경우, 각 액션이 이름(Name)에 의해 정의되어 사용될 수 있다. 또한, HTTP POST 메시지 바디에 액션 이름(Name) 도 함께 전달되기 때문에, 대상 기기에 대한 URL이 하나만 존재하고, HTTP POST 메쏘드 역시 하나만 사용되어도, 무한한 종류의 액션의 교환이 가능할 수 있다.
도 88 은 본 발명의 일 실시예에 따른 REST 메커니즘을 도시한 도면이다.
전술한 본 발명에서의 기기간 커뮤니케이션에 대한 설명 중, 한가지 방식인 REST 방식에 대하여 설명한다.
도시된 본 발명의 일 실시예에 따른 REST 메커니즘이란, REST 클라이언트(t88010) 과 REST 서버(t88020) 간의 커뮤니케이션 매커니즘을 의미할 수 있다. 여기서 REST 클라이언트(t88010) 은 HTTP 클라이언트일 수 있고, REST 서버(t88020) 은 HTTP 서버일 수 있다. 전술한 것과 마찬가지로, REST 클라이언트는 액션이라 불리우는 일종의 메시지를, REST 서버(t88020) 에 전달하여, REST 서버(t88020) 가 특정한 동작을 수행하도록 할 수 있다.
본 실시예에서, REST 클라이언트(t88010) 는 각 액션을 URI 를 통하여 REST 서버(t88020) 에 전달할 수 있다. 각 액션에는 액션 이름(Name) 이 필수적이지 않을 수 있다. 각 액션은 아규먼트들과 데이터만을 포함할 수 있다.
여기서, HTTP 메쏘드 중 POST 뿐 만 아니라, GET, HEAD, PUT, DELETE, TRACE, OPTIONS, CONNECT, PATCH 등의 여러 메쏘드가 활용될 수 있다. 또한, 커뮤니케이션을 행할 대상 기기에 접근할 URI 가 복수개가 정의될 수 있다. 이러한 특징들로 인하여, 액션 이름의 정의없이도 액션이 전달될 수 있다. 이러한 REST 방식에 필요한 복수의 URI 값은 디스커버리 혹은 디스크립션 전달 과정에서 획득될 수 있다.
전달이 필요한 데이터 또는 아규먼트들이, 해당 URI 에 부가되어(appended) 전달될 수 있고, 또는 HTTP 바디에 다양한 형태(XML, JSON, HTML, TEXT, IMAGE,…..)로 포함되어 전달될 수 있다.
REST 서버(t88020) 는 전달받은 액션에 따라 특정 동작을 수행할 수 있다.
전술한 기기간 커뮤니케이션은 일 실시예일 뿐이며, 본 발명에서 제안하는 모든 내용은 UPnP 방식 등에 국한되지 아니한다.
도 89 는 본 발명의 일 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
전술한 바와 같이, 본 발명은 PDI 유저 데이터를, 리시버와 다른 컴패니언 디바이스 간에 교환/전달하는 방법을 제안한다.
여기서, 컨텐츠 프로바이더 또는 브로드캐스터(t89010), PDI 설문지(t89020), PDI 엔진(t89030), PDI 스토어(t89040) 는 전술한 동명의 모듈과 같을 수 있다.
전술한 바와 같이 컨텐츠 프로바이더 또는 브로드캐스터(t89010) 이 생성한 PDI 설문지(t89020) 가 수신기(t89050) 으로 전달될 수 있다. PDI 엔진(t89030) 은 유저에게 해당 설문지를 제공하고 답변(Answer) 를 받아 PDI 스토어(t89040) 에 저장할 수 있다. 실시예에 따라, 사용자에게 질문의 답변을 유도하지 않고, 수신기 내에서 자동으로 답변이 기입될 수 있다.
유저에게 Questionare 를 보여주고, 답변을 저장하는 매커니즘은 전술한 실시예와 같을 수 있으나, 이는 일 실시예일 뿐이다. 본 발명은 이에 국한되지 아니한다.
전술한 바와 같이, PDI 스토어(t89040) 은 수신기(t89050) 내에 위치할 수 있다. 그러나, 실시예에 따라, 수신기 외부에 PDI 클라우드 스토어(t89070) 이 존재할 수도 있다. PDI 클라우드 스토어(t89070) 는 전술한 PDI 스토어(t89040) 와 동일한 동작을 수행할 수 있다. 다만, PDI 클라우드 스토어(t89070) 는 수신기(t89050) 의 외부에 위치하여, 클라우드 서버로서 동작할 수 있다.
본 실시예에서, 수신기(t89050) 은 컴패니언 디바이스 모듈(t89060) 을 더 포함할 수 있다. 저장된 PDI 유저 데이터는 컴패니언 디바이스 모듈(t89060) 을 통해, 컴패니언 디바이스(t89080)로 전달될 수 있다. 반대로, 컴패니언 디바이스 모듈(t89060) 을 통해, 컴패니언 디바이스에서 설정된 답변들이 리시버로 전달될 수도 있다.
본 발명은 UPnP 를 기반으로, 수신기와 컴패니언 디바이스간의 커뮤니케이션 실시예를 설명한다. 그러나, 수신기와 컴패니언 디바이스간의 커뮤니케이션 프로토콜은, 이에 한정되지 아니한다.
도 90 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 91 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 다른 일부를 도시한 도면이다.
두 도면은 원래 하나인 도표를 도시하고 있으나, 공간의 제약에 의해 두 개의 도표로 나뉘어 도시되었다.
도시된 PDI 유저 데이터는 전술한 PDITable 의 다른 실시예일 수 있다(XML 형태). 즉, 교환되는 PDI 유저 데이터의 일 실시예는 전술한 PDI 테이블일 수 있다.
PDIUserData 는 한 개 이상의 질문 엘레먼트를 포함하는 루트 엘레먼트일 수 있다. @ProtocolVersion 은 전술한 PDITable 내의 @ProtocolVersion 과 같을 수 있다. @userDataId 은 전술한 PDITable 내의 @pdiTableId 와 같을 수 있다. @userDataVersion 은 전술한 PDITable 내의 @pdiTableVersion 과 같을 수 있다. @time 은 전술한 PDITable 내의 @time 과 같을 수 있다.
QxA(즉, QIA, QBA, QSA, QTA, QAA) 는 전술한 PDITable 내의 QxA 의 다른 실시예일 수 있다. 본 실시예에서, 각 QxA 는 전술한 바와 동일한 의미를 가지나, 내부 구조는 약간 상이할 수 있다. 각 QxA 의 내부구조는 QxAType 엘레먼트에 표현되어 있다. 예를 들어 QIA 의 구조는 QIAType 필드에 표현되어 있다.
QxA 밑의 @id 는 전술한 PDITable 내의 @id 와 같을 수 있다. QxA 밑의 @expire 는 전술한 PDITable 내의 @expire 와 같을 수 있다.
QxA 밑의 Q 는 전술한 PDITable 내의 Q 와 같을 수 있다. 본 실시예에서, Q 엘레멘트는 질문의 텍스트를 표현하는 QText 엘레멘트를 가질 수 있다. QxA 밑의 @lang 은 전술한 PDITable 내의 @lang 와 같을 수 있으나, 본 실시예에서는 QText 엘레멘트 밑에 위치할 수 있다.
QxA 밑의 A 는 전술한 PDITable 내의 A 와 같을 수 있다. 본 실시예에서, A 엘레멘트는 실제 답변 정보를 가지는 @answer 를 가질 수 있다. QxA 밑의 @time 는 전술한 PDITable 내의 @time 과 같을 수 있다.
QIA 밑의 @loEnd, @hiEnd 는 전술한 PDITable 내의 @loEnd, @hiEnd 와 같을 수 있으나, 본 실시예에서는 Q 엘레먼트 밑에 위치할 수 있다.
QSA 밑의 @minChoices, @maxChoices 는 전술한 PDITable 내의 @minChoices, @maxChoices 와 같을 수 있으나, 본 실시예에서는 Q 엘레먼트 밑에 위치할 수 있다. QSA 밑의 Selection 엘레멘트 및 @selectionId 는 전술한 PDITable 내의 Selection 엘레멘트 및 그 하위의 @id 와 같을 수 있다.
QTA 밑의 A 는 @lang 을 가질 수 있는데, 이는 전술한 PDITalbe 의 QTA 의 A 엘레멘트의 @lang 과 같을 수 있다.
전술한 바와 같이, QAA 의 경우 Q 엘레멘트가 없을 수 있다.
QxAD 는, 답변의 데이터 타입에 따라 분류되는 Q&A 도큐먼트를 의미할 수 있다. 즉, QxAD 에는, 실제 질문과 답변에 관련된 QxA 엘레멘트와 @protocolVersion 이 포함될 수 있다. x 는 데이터 타입에 따라, I (integer), B(Boolean), S(Selection), T(text), A(without question) 중 하나에 해당할 수 있다.
도시된 PDI 유저 데이터 중, t91010 으로 표시된 부분은 실시예에 따라 생략될 수도 있다.
전술한 PDI 유저 데이터는, PDI 유저 데이터의 일 실시예일 뿐이며, 본 발명의 PDI 유저 데이터는 어떠한 형태에 국한되지 아니한다.
도 92 는 본 발명의 일 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
먼저, PDI 유저 데이터를 교환하기 위해서는, 수신기와 컴패니언 디바이스간의 호환성을 위해서 디바이스 타입이 정의되어야 한다. 디바이스 타입의 일 실시예는 다음과 같을 수 있다.
UPnP Device Type : urn:atsc.org:device:atsc3.0rcvr
정의된 디바이스 타입과 맞지 않는 경우에는 본 발명에서 제안하는 PDI 유저 데이터 교환과 관련된 서비스를 활용하지 못할 수 있다.
정의된 디바이스 타입을 지원하는 수신기와 컴패니언 디바이스간에, PDI 유저데이터를 교환하기 위해서는 서비스 타입 및/또는 서비스 ID 가 정의되어야 할 수 있다. UserData 서비스가 정의될 수 있는데, 여기서 UserData 서비스란 정의된 디바이스 타입을 지원하는 수신기와 컴패니언 디바이스 간에 PDI 유저 데이터를 교환하기 위한 서비스를 의미할 수 있다. UserData 서비스를 통해서, PDI 유저 데이터 내지 PDI 테이블을 컴패니언 디바이스로 전달하거나 전달받을 수 있다.
도시된 서비스 타입과 서비스 ID 의 두 실시예(t92010, t92020) 에서, 서비스 명은 "UserData", 서비스 타입은 "atsc3.0userdata:1", 서비스 ID 는 각각 "urn:atsc.org:servceId:atsc3.0userdata1" 또는 "urn:atsc.org:servceId:atsc3.0userdata" 일 수 있다.
도 93 은 본 발명의 일 실시예에 따른 UserData 서비스의 상태변수(state variable)들을 도시한 도면이다.
전술한 UPnP UserData 서비스는, PDI 유저 데이터를 교환하기 위해서 PDIUserDataProtocolVersion, A_ARG_TYPE_UserDataIdsList, UserDataList 및/또는 A_ARG_TYPE_UserData 상태 변수를 정의할 수 있다.
데이터 전달에 관해서, 이벤트 방식과 액션 방식이 있을 수 있다. 이벤트 방식은 컴패니언 디바이스가 수신기에 자신을 등록해 놓으면, 수신기가 특정 정보가 변하거나 했을 때, 수신기가 자동으로 컴패니언 디바이스에 전달해 주는 방식을 의미할 수 있다. 액션 방식은 컴패니언 디바이스가 수신기에 특정 정보를 달라고 요청하는 방식을 의미할 수 있다.
전술한 UserData 서비스의 상태변수 4가지는, 필수 상태변수(Req) 로서, 전술한 이벤트 방식이 아닌 액션 방식에 따를 수 있고, 따라서 다양한 액션의 아규먼트로서 활용될 수 있다.
PDIUserDataProtocolVersion 는 디바이스가 지원하는 UserData 서비스의 프로토콜 버전을 나타낼 수 있다. 본 상태변수를 통해, 각 디바이스(수신기, 컴패니언 디바이스 등) 가 개인화(personalization)을 위한 UserData 서비스를 지원하는지 알 수 있다. 본 상태변수는 bin 또는 hex 의 데이터 타입을 가질 수 있다. 처음 4 비트는 메이저 버전 넘버, 그 다음 4 비트는 마이너 버전 넘버를 의미할 수 있다. 예를 들어, 00010010 의 값을 가질 경우, 버전 1.2 임을 알 수 있다(메이저 버전넘버:1, 마이너 버전넘버:2). 이 버전 정보는 전술한 PDI 유저 데이터의 @protocolVersion 또는 후술할 UserDataList 상태변수의 protocolVersion 정보와 매칭하기 위하여 사용될 수 있다.
A_ARG_TYPE_UserDataIdsList 는 전술한 PDI 스토어에 저장되어 있는 PDI 유저 데이터들의 ID 들을 포함하는 리스트를 나타낼 수 있다. 후술할 UserDataList 상태변수의 userDataId 들을 스트링(string) 형태의 리스트로 표현할 수 있다. 따라서, UserDataList 상태변수의 userDataId 들과 관련된 액션들을 위해 활용될 수 있다. 본 상태변수는 List 데이터 타입(e.g., CSV)을 가질 수 있다.
UserDataList 는 PDI 유저 데이터를 담는 리스트 역할을 할 수 있다. 본 상태변수는 복수개의 설문지 와 답변들을 포함할 수 있다. 본 상태변수는 후술할 GetUserData() 액션에서 활용될 수 있다. 본 상태변수의 자세한 구조에 대해서는 후술한다.
A_ARG_TYPE_UserData 는 전술한 UserDataList 의 한 프래그먼트일 수 있다. 이 때, 두 상태변수들은 같은 마크업 언어(mark up language) 에 따를 수 있다. 예를 들어, UserDataList 상태변수가 XML 문서일 경우, A_ARG_TYPE_UserData는 그 XML 문서의 한 프래그먼트가 될 수 있다. 본 상태변수는 복수 개의 PDIUserData 엘레먼트와 어트리뷰트(attributes)를 가질 수 있다. 또한, 본 상태변수는 사용되는 액션의 용도에 따라서 서브 엘레먼트들을 포함할 수 있다. A_ARG_TYPE_UserData 는 실시예에 따라 생략될 수도 있다.
도 94 는 본 발명의 일 실시예에 따른 UserDataList 의 XML 구조를 도시한 도면이다.
UserDataList 는 복수개의 PDIUserData 를 포함할 수 있다. 각 PDIUserData 는 전술한 PDI 유저 데이터 내지 PDI 테이블에 해당할 수 있다. PDIUserData 의 엘레먼트 및 어트리뷰트(attribute) 들은 전술한 바와 같을 수 있다. 실시예에 따라 다른 형태로 PDIUserData 의 구조가 변경될 수 있다.
첫번째 UserDataList (t94010) 는, userDataId 가 "atsc.org/userdata1" 인 PDIUserData 와, userDataId 가 "atsc.org/userdata2" 인 PDIUserData 를 포함할 수 있다.
userDataId 가 "atsc.org/userdata1" 인 PDIUserData 는 QIA 타입을 가진 question1 을 가질 수 있다. question1 은 "what is your age" 와 같은 질문을 가질 수 있고, 또한, 2014년 6월 2일에 대답한 "21" 라는 답을 가질 수 있다. "atsc.org/userdata2" 인 PDIUserData 역시, 전술한 PDIUserData 에 따라, 정보를 가질 수 있다.
두번째 UserDataList (t94020) 는, userDataId 가 각각 "atsc.org/userdata1", "atsc.org/userdata2", "atsc.org/userdata3" 인 PDIUserData 를 포함할 수 있다. 각 PDIUserData 역시, 전술한 PDIUserData 에 따라, 정보를 가질 수 있다.
UserDataList 는 전술한 두 실시예와 같은 형식으로, 복수개의 PDIUserData 를 포함할 수 있으며, 각 PDIUserData 는 전술한 PDI 유저 데이터의 구조 또는, 실시예에 따라 다른 형태의 구조를 가질 수 있다.
도 95 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션(action)들을 도시한 도면이다.
전술한 UserData 서비스에는 GetPDIUserDataProtocolVersion, GetUserDataIdsList, GetUserData, 및/또는 SetUserData 액션이 있을 수 있다. 여기서, GetPDIUserDataProtocolVersion 는 비필수적(Optional) 한 액션일 수 있고, 나머지 3 개의 액션은 필수적(Required)인 액션일 수 있다. 실시예에 따라, GetPDIUserDataProtocolVersion 는 생략될 수도 있다. 또한 실시예에 따라 추가적인 액션들이 더 정의될 수 있다.
각 액션에 대해서는 후술한다.
도 96 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetPDIUserDataProtocolVersion 를 설명하는 도면이다.
GetPDIUserDataProtocolVersion 액션은 PDI 유저 데이터를 가져오기 위한 프로토콜의 버전이 무엇인지 알기위해 사용되는 액션일 수 있다. 여기서, 프로토콜은 수신기(혹은 Primary Device) 가 지원하고 있는 프로토콜을 의미할 수 있다. 컴패니언 디바이스는 GetPDIUserDataProtocolVersion 액션을 이용하여, 수신기가 지원하는 프로토콜의 버전을 알 수 있다.
GetPDIUserDataProtocolVersion 을 사용하기 위해, PDIUserDataProtocolVersion 아웃풋 아규먼트(argument) 가 정의될 수 있다.
PDIUserDataProtocolVersion 는 디바이스에 의해 지원되는 UserData 서비스의 프로토콜 버전 정보로서, 전술한 PDIUserDataProtocolVersion 상태변수와 관련있을 수 있다.
도 97 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetUserDataIdsList 와 GetUserData 를 설명하는 도면이다.
GetUserDataIdsList 액션을 설명한다.
GetUserDataIdsList 액션은 전술한 PDI 스토어에 저장된 PDI 유저 데이터들의 ID 를 가져오는데 사용되는 액션일 수 있다. 컴패니언 디바이스는 GetUserDataIdsList 액션을 이용하여, 수신기 내/외부에 존재하는 PDI 스토어에서, PDI 유저 데이터의 Id 정보를 가져올 수 있다. 이 때, PDI 유저 데이터의 프로토콜 버전이 참조되어, 해당 프로토콜을 지원하는 PDI 유저 데이터의 ID 만 가지고 올 수 있다.
GetUserDataIdsList 액션을 사용하기 위해, ProtocolVersion 인풋 아규먼트와 UserDataIdsList 아웃풋 아규먼트가 정의될 수 있다(t97010). ProtocolVersion 인풋 아규먼트는 PDI 유저 데이터의 프로토콜 버전 정보로서, 전술한 PDIUserDataProtocolVersion 상태변수와 관련있을 수 있다. UserDataIdsList 아웃풋 아규먼트는 스트링(string) 형태인 PDI 유저 데이터의 ID 들의 리스트로서, 전술한 A_ARG_TYPE_UserDataIdsList 상태변수와 관련 있을 수 있다.
GetUserDataIdsList 액션이 사용되면, UserDataList 상태변수의 PDIUserData 엘레멘트들 중 @protocolVersion 값과 인풋 아규먼트인 ProtocolVersion 의 값이 일치하는 엘레멘트들이 있으면, 그 일치되는 PDIUserData 엘레먼트들 중 @userDataId 값들이 리스트로 출력될 수 있다. 그 출력은 전술한 UserDataList 아웃풋 아규먼트로서, 수신기에서 컴패니언 디바이스로 전달될 수 있다.
GetUserData 액션을 설명한다.
GetUserData 액션은 전술한 PDI 스토어에 저장된 PDI 유저 데이터들을 가져오는데 사용되는 액션일 수 있다. 컴패니언 디바이스는 GetUserData 액션을 이용하여, 수신기 내/외부에 존재하는 PDI 스토어에서, PDI 유저 데이터를 가져올 수 있다. 이 때, 전술한 UserDataIdsList 가 참조되어, 그 PDIUserDataId 에 매칭되는 PDIUserData 만을 프래그먼트 형태로 가지고 올 수 있다.
GetUserData 액션을 사용하기 위해, UserDataIdsList 인풋 아규먼트와 UserData 아웃풋 아규먼트가 정의될 수 있다(t97020). UserDataIdsList 아규먼트는 전술한 바와 같을 수 있고, 전술한 A_ARG_TYPE_UserDataIdsList 상태변수와 관련있을 수 있다. UserData 아웃풋 아규먼트는 전술한 UserDataList 상태변수의 프래그먼트로서 전술한 A_ARG_TYPE_UserData 상태변수와 관련 있을 수 있다. UserData 아규먼트는 PDIUserData 엘레멘트 등의 정보들을 가질 수 있으며, UserDataList 의 데이터 타입을 따를 수 있다(e.g. XML).
예를 들어, GetUserData(UserDataIdsList="atsc.org/userdata1", "atsc.org/userdata3") 와 같은 내용의 액션이 사용되었다면, 전술한 UserDataList 의 XML 구조에서, UserDataList 에 포함되는 복수개의 PDIUserData 중 userDataId 가 "atsc.org/userdata1" 인 것과, "atsc.org/userdata3" 인 PDIUserData 가 리턴될 수 있다. 이 때, 리턴되는 UserData 의 XML 구조는 userDataId 가 각각 "atsc.org/userdata1", "atsc.org/userdata3" 인 PDIUserData 만을 가질 수 있고, "atsc.org/userdata2" 의 userDataId 를 가지는 PDIUserData 엘레먼트는 없을 수 있다.
여기서, GetUserData 액션에서, 아웃풋 아규먼트인 UserData 의 PDIUserData 엘레멘트 수는 인풋 아규먼트인 UserDataIdsList 내의 PDIUserDataId 의 개수보다 적거나 같을 수 있다.
실시예에 따라, UserDataIdsList 인풋 아규먼트를 "ALL" 로 설정하면 PDIUserDataId 에 무관하게 모든 PDIUserData가 요청될 수 있다.
전술한 GetUserDataIdsList 와 GetUserData 액션의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다. 또한, 컴패니언 디바이스는 이미 활용 가능한 프로토콜 버전을 알고 있다고 가정한다.
전술한 컨텐츠 프로바이더 또는 브로드캐스터는, 개인화된 서비스 제공을 위하여, PDI 유저 데이터를 수신기로 전달할 수 있다(ts97010). 여기서, PDI 유저 데이터는 복수개의 설문 이거나 혹은 복수개의 설문지 와 답변(Answer)들의 조합이 될 수 있다.
수신기는 전달받은 PDI 유저 데이터를, 전술한 PDI 엔진으로 전달할 수 있다(ts97020). PDI 엔진은 사용자에게 설문지 를 보여주고, 사용자로부터 각 질문에 해당하는 답변을 얻을 수 있다(ts97030). PDI 엔진은 답변을 얻은 Q&A 를 전술한 PDI 스토어에 저장할 수 있다(ts97040).
전술한 컴패니언 디바이스는 수신기로부터 PDI 유저 데이터를 얻기 위하여, 전술한 GetUserDataIdsList 액션을 수행할 수 있다(ts97050). 컴패니언 디바이스는 전술한 수신기 내부의 컴패니언 디바이스 모듈에, PDI 유저 데이터들의 ID 를 요청할 수 있다.
컴패니언 디바이스 모듈은 PDI 엔진에, 컴패니언 디바이스로부터 요청받은 PDI 유저 데이터들의 ID 를 요청할 수 있다(ts97060). PDI 엔진은 해당하는 PDI 유저 데이터의 ID 들을 PDI 스토어에서 찾을 수 있다(ts97070). 그 후, PDI 엔진은 검색된 PDI 유저 데이터의 ID 들을, 컴패니언 디바이스 모듈로 전달할 수 있다(ts97080).
컴패니언 디바이스 모듈은 전달받은 PDI 유저 데이터의 ID 들을 컴패니언 디바이스로 전달할 수 있다(ts97090).
PDI 유저 데이터의 ID 들을 얻게된 컴패니언 디바이스는, PDI 유저 데이터를 얻기 위하여 전술한 GetUserData 액션을 활용할 수 있다(ts97100). 컴패니언 디바이스는 전달받은 PDI 유저 데이터의 ID 들을 이용하여, 또는 인풋 아규먼트로 사용하여 PDI 유저 데이터들을 요청할 수 있다.
컴패니언 디바이스 모듈은 PDI 엔진에 해당 PDI 유저 데이터를 요청할 수 있다(ts97110). 컴패니언 디바이스 모듈은 PDI 스토어에서 해당 PDI 유저 데이터를 검색하고(ts97120), 검색된 PDI 유저 데이터를 컴패니언 디바이스 모듈로 전달할 수 있다(ts97130).
컴패니언 디바이스 모듈은 전달받은 PDI 유저 데이터를 컴패니언 디바이스로 전달할 수 있다(ts97140). 컴패니언 디바이스는 전달받은 PDI 유저 데이터를 저장할 수 있다. 저장된 PDI 유저 데이터들은 반영구적으로 저장되어 활용될 수 있으며, 만약 컴패니언 디바이스에 저장소가 없을 경우, 메모리 등의 공간에 일시적으로 저장할 수도 있다.
본 발명에서, GetUserDataIdsList와 GetUserData 액션을 수행하는 시점은, 특정 시점에 한정되지 아니한다. 실시예에 따라, 컴패니언 디바이스와 수신기가 페어링된 직후에 각 액션이 수행될 수 있다. 또한, 실시예에 따라, 컴패니언 디바이스가 수신기에 주기적으로 폴링(polling) 하면서 요청할 수도 있다.
도 98 은 본 발명의 일 실시예에 따른 UserData 서비스의 확장된 상태변수를 도시한 도면이다.
특정 UserDataId 를 가지고 있는 PDI 유저 데이터가 업데이트될 경우, 새로운 XML 도큐먼트가 생성될 수도 있고, 새로운 XML 도큐먼트가 생성되지 않고 userDataVersion 만이 증가할 수도 있다.
새로운 XML 도큐먼트가 생성되지 않고 userDataVersion 만이 증가하는 방법을 따를 경우, 전술한 액션들을 사용하면 되지만, PDI 유저 데이터가 업데이트될 때마다 XML 도큐먼트가 새로이 생성되는 방법을 따른다면ProtocolVersion 뿐 아니라 특정 PDI 유저 데이터의 userDataVersion 역시 참조될 필요가 있다.
이를 위하여 전술한 UserDataList 상태변수는 A_ARG_TYPE_UserDataIdsList 로 확장될 수 있다. A_ARG_TYPE_UserDataIdsList 은 필수 상태변수일 수 있으며, 전술한 액션 방식에 따를 수 있다.
A_ARG_TYPE_UserDataIdsList 의 데이터 타입은 스트링에서, 스트링의 리스트로 변경될 수 있다. 스트링의 리스트란, PDI 스토어에 저장되어 있는 PDI 유저 데이터들의 ID와 해당 ID를 가지고 있는 XML 도큐먼트의 userDataVersion들을 포함하는 리스트일 수 있다. 이 리스트는 여러가지 형태로 표현될 수 있으며, (userDataId, userDataVersion) 형태의 페어로 표현되는 것을 일 실시예로 한다. PDI 유저 데이터가 업데이트 될 때마다 새로 XML 도큐먼트를 생성하는 방법을 따를 경우라면, 동일한 userDataId의 PDI 유저 데이터라도 userDataVersion에 따라 여러 개의 XML 도큐먼트가 PDI 스토어에 존재 할 수 있다.
A_ARG_TYPE_UserDataIdsList 로 상태변수가 확장될 경우, 전술한 GetUserDataIdsList 액션의 아규먼트 중, UserDataIdsList 는 (userDataId, userDataVersion) 형태의 스트링의 리스트를 반환할 수 있다. 또한, 인풋 아규먼트인 ProtocolVersion 을 00000000으로 설정하면 ProtocolVersion에 구분없이 모든 userDataId와 userDataVersion의 페어형태의 리스트가 요청될 수 있다. 또한, 인풋 아규먼트인 ProtocolVersion 을 11111111으로 설정하면 가장 최신 ProtocolVersion에 해당하는 userDataId와 userDataVersion의 페어형태의 리스트가 요청될 수 있다.
A_ARG_TYPE_UserDataIdsList 로 상태변수가 확장될 경우, 전술한 GetUserData 액션의 아규먼트 중, UserDataIdsList도 (userDataId, userDataVersion)형태의 스트링의 리스트를 인풋으로 하여, 전체 UserDataIdsList 중 특정 userDataId와 userDataVersion 이 매칭되는 PDIUserData만을 프래그먼트형태로 요청할 수 있다. 추가적으로, 인풋 아규먼트인 UserDataIdsList를 "ALL"로 설정하면 userDataId와 userDataVersion에 구분없이 모든 PDIUserData가 요청될 수 있다.
도 99 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, SetUserData 를 설명하는 도면이다.
SetUserData 액션은, 역으로 컴패니언 디바이스에서 PDI 유저 데이터가 설정/저장되고, 이 설정된 PDI 유저 데이터가 수신기로 전달될 때 사용되는 액션일 수 있다. SetUserData 액션은 UserDataList 를 인풋 아규먼트로 가지고, 전술한 UserDataList 상태변수와 관련있을 수 있다(t99010).
SetUserData 액션을 통해 전달된 PDI 유저 데이터를 이용하여, 수신기 내에 기저장되어 있던 UserDataList 를 수정/업데이트할 수 있다. 수신기는 전달받은 PDI 유저 데이터들을 PDI 스토어에 저장되어 있는 PDI 유저 데이터들과 비교할 수 있다. 해당 PDI 유저 데이터가 없는 경우 전달받은 PDI 유저 데이터를 추가할 수 있다. 해당 PDI 유저 데이터가 있는 경우, PDIUserData 의 @userDataVersion 을 상호 비교하여, 전달받은 PDI 유저 데이터의 @userDataVersion 이 높다면 전달받은 PDI 유저 데이터로 업데이트할 수 있다.
SetUserData 액션의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
전술한 컨텐츠 프로바이더 또는 브로드캐스터는, 개인화된 서비스 제공을 위하여, PDI 유저 데이터를 컴패니언 디바이스로 전달할 수 있다(ts99010). 여기서, PDI 유저 데이터는 복수개의 설문지 이거나 혹은 복수개의 설문지 와 답변(Answer)들의 조합이 될 수 있다.
컴패니언 디바이스는 사용자에게 설문지를 보여주고, 사용자로부터 각 질문에 해당하는 답변을 얻을 수 있다(ts99020). 컴패니언 디바이스는 SetUserData 액션을 통해 설정된 PDI 유저 데이터를, 전술한 수신기 내부의 컴패니언 디바이스 모듈로 전달할 수 있다(ts99030).
컴패니언 디바이스 모듈은 전달받은 PDI 유저 데이터를 PDI 엔진으로 전달할 수 있다(ts99040). PDI 엔진은 PDI 스토어에 기 저장되어 있는 PDI 유저 데이터가 있는지 검색할 수 있다(ts99050). PDI 엔진은 검색결과, 기존에 저장되어 있는 PDI 유저 데이터가 없으면 새로운 PDI 유저데이터를 저장하고, 기존에 저장되어 있는 PDI 유저 데이터가 있으면 버전 정보에 따라 PDI 유저 데이터를 업데이트할 수 있다(ts99060).
예를 들어, 수신기의 PDI 스토어에는 전술한 UserDataList 의 XML 구조에, userDataId 가 "atsc.org/userdata1" 인 PDIUserData 가 저장되어 있을 수 있다. 컴패니언 디바이스에는 전술한 UserDataList 의 XML 구조에 userDataId 가 "atsc.org/userdata3" 인 PDIUserData 가 저장되어 있을 수 있다.
SetUserData 액션을 통해 컴패니언 디바이스는 userDataId 가 "atsc.org/userdata3" 인 PDIUserData 를 수신기로 전달할 수 있다. 수신기의 PDI 엔진은 userDataId 가 "atsc.org/userdata3" 인 PDIUserData 가 PDI 스토어에 존재하지 않으므로, 해당 PDIUserData 를 추가하여 PDI 스토어에 저장할 수 있다. 최종적으로 수신기의 PDI 스토어에는 전술한 UserDataList 의 XML 구조에, userDataId 가 "atsc.org/userdata1" 인 PDIUserData 와, userDataId 가 "atsc.org/userdata3" 인 PDIUserData 가 함께 저장될 수 있다.
도 100 은 본 발명의 일 실시예에 따른, UserData 서비스의 추가된 상태변수를 도시한 도면이다.
전술한 UPnP UserData 서비스는 PDI 유저 데이터에 변화가 있을 경우에만 컴패니언 디바이스로 PDI 유저데이터를 전달하기 위하여, 추가적인 상태변수 UserDataModefiedTime 를 설정할 수 있다(t100010).
UserDataModefiedTime 상태 변수는 PDI 유저 데이터가 마지막으로 수정된 시간을 나타낼 수 있다. 본 상태변수는 전술한 이벤트 방식을 따를 수 있으며, 따라서 컴패니언 디바이스가 수신기에 섭스크라이빙(Subscribing) 을 해놓으면, PDI 유저 데이터가 수정될 경우 자동으로 컴패니언 디바이스에 해당 상태변수가 전달될 수 있다. 본 상태변수는 필수(Req) 상태변수 일 수 있으며, 데이터 타입은 dateTime 일 수 있다.
UserDataModefiedTime 상태 변수의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 실시예에서는 새로운 PDI 유저 데이터가 컨텐츠 프로바이더로부터 전달되는 경우를 상정하였으나, PDI 유저 데이터가 변경되는 상황은 이에 한정되지 아니한다. 본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
컴패니언 디바이스는 UserData 서비스를, 전술한 컴패니언 디바이스 모듈에 섭스크라이빙(subscribing)해 놓을 수 있다(ts100010). 이는 전술한 이벤트 방식에 따른 것이며, 섭스크라이빙으로 인해 UserData 서비스의 이벤트 방식에 따른 알림/전달 등의 동작을 받을 수 있다. 섭스크라이빙은 PDI 유저 데이터의 변경시점 전에만 이루어지면, PDI 유저 데이터의 변경이 있을 때 알림 등을 받을 수 있다. 실시예에 따라 섭스크라이빙은 페어링 직후에 이루어질 수도 있고, 다른 시점에 이루어질 수도 있다.
전술한 컨텐츠 프로바이더 또는 브로드캐스터는 새로운 PDI 유저 데이터를 수신기에 전달할 수 있다(ts100020). 수신기는 PDI 엔진에 전달받은 새로운 PDI 유저 데이터를 전달할 수 있다(ts100030). 전술한 것과 같이 PDI 엔진은 사용자로부터 답변을 받고(ts100040), 그 Q&A 를 PDI 스토어에 저장할 수 있다(ts100050).
이 경우, 새로운 PDI 유저 데이터가 전달되었으므로, 기 저장되어 있던 PDI 유저 데이터에 변경이 발생하였다. 이에, PDI 엔진은 상태변수인 UserDataIdxCount 를 업데이트할 수 있다. 또한, PDI 엔진은 UserDataIdxCount 가 업데이트 되었으면, UserDataModefiedTime 상태 변수의 업데이트를 컴패니언 디바이스 모듈에 전달할 수 있다(ts100060). 컴패니언 디바이스 모듈은 섭스크라이빙된 컴패니언 디바이스에, 이벤트를 통해, PDI 유저 데이터의 변화가 발생했음을 알릴 수 있다(ts100070).
변화의 발생이 통지된 후에(ts100070), 컴패니언 디바이스는 전술한 GetPDIUserDataProtocolVersion, GetUserDataIdsList 와 GetUserData 등의 액션을 통하여 PDI 유저 데이터를 가져올 수 있다.
본 실시예에서, 새로운 PDI 유저 데이터가 전달되는 것이 아닌 기존에 저장되어 있던 PDI 유저 데이터의 답변이 변경되는 경우는 ts100020, ts100030 을 제외한 다음 단계부터 수행될 수 있다.
도 101 은 본 발명의 일 실시예에 따른, UserData 서비스의 또 다른 추가된 상태변수를 도시한 도면이다.
전술한 UPnP UserData 서비스는 PDI 유저 데이터에 변화가 있을 경우에만 컴패니언 디바이스로 PDI 유저데이터를 전달하기 위하여, 또 다른 추가적인 상태변수 UserDataUpdatedList 를 설정할 수 있다(t101010).
UserDataUpdatedList 상태 변수는 PDI 유저 데이터 ID 와 그에 해당하는 PDI 유저 데이터 버전의 페어 형태의 리스트일 수 있다. 예를 들어, 본 상태변수는 (UserDataId#1, 1.0) 과 같은 형태로 표현될 수 있다. PDI 유저 데이터 ID의 변화가 있거나 PDI 유저 데이터 버전의 변화가 있을 경우 UserDataUpdatedList 가 업데이트 될 수 있다. PDI 유저 데이터 ID의 경우는 추가 혹은 삭제가 될 수 있으며, PDI 유저 데이터 버전의 경우 수정이 될때마다 1씩 증가될 수 있다.
실시예에 따라 본 상태변수는 CSV 리스트의 형태일 수 있다. 본 상태변수는 전술한 이벤트 방식을 따를 수 있으며, 따라서 컴패니언 디바이스가 수신기에 섭스크라이빙(Subscribing) 을 해놓으면, PDI 유저 데이터의 변화가 자동으로 컴패니언 디바이스에 해당 상태변수가 전달될 수 있다. 본 상태변수는 필수(Req) 상태변수 일 수 있다.
UserDataUpdatedList 상태 변수의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 실시예에서는 기존에 저장되어 있던 PDI 유저 데이터의 답변(answer) 가 변경되는 경우를 상정하였으나, PDI 유저 데이터가 변경되는 상황은 이에 한정되지 아니한다. 본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
컴패니언 디바이스가 섭스크라이빙하는 과정(ts101010) 은 전술한 바와 같다. PDI 엔진은 새로이 답변을 받아, 기존에 저장되어 있던 설문지 의 답변을 변경할 수 있다(ts101020). 이 때, 기존의 PDI 유저 데이터가 변경된 것이므로 PDI 유저 데이터의 버전 또한 업데이트될 수 있다. 답변이 완료된 Q&A 는 PDI 스토어에 저장될 수 있다(ts101030).
PDI 엔진은 변경된 PDI 유저 데이터 버전에 따라, UserDataUpdatedList 의 값을 업데이트할 수 있다. PDI 엔진은 UserDataUpdatedList 상태 변수의 업데이트를 컴패니언 디바이스 모듈에 전달할 수 있다(ts101040). 컴패니언 디바이스 모듈은 섭스크라이빙된 컴패니언 디바이스에, 이벤트를 통해, PDI 유저 데이터의 변화가 발생했음을 알릴 수 있다(ts101050).
컴패니언 디바이스는 변경된 UserDataUpdatedList를 참조하여, 기존에 저장되어 있던 PDI 유저 데이터와 그 버전을 서로 비교할 수 있다(ts101060). 컴패니언 디바이스는 버전이 변경된 PDI 유저 데이터에 대하여, 그 PDI 유저 데이터를 가져오도록 액션을 수행할 수 있다. 이 때, 변경된 PDI 유저 데이터만 가져올 수도 있고, 전체 PDI 유저 데이터를 다 가져올 수도 있다. PDI 유저 데이터 요청에, 전술한 GetPDIUserDataProtocolVersion, GetUserDataIdsList 와 GetUserData 등의 액션이 사용될 수 있다.
도 102 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 상태변수들을 도시한 도면이다.
수신기와 컴패니언 디바이스간 PDI 유저 데이터의 교환이 이루어질 때, 많은 양의 데이터가 교환되면 오버로드가 발생할 수 있다. 이를 방지하기 위해, 질문과 답변의 페어단위로, PDI 유저 데이터의 교환을 할 수도 있다. Q&A 페어를 교환하기 위하여 A_ARG_TYPE_UserDataQAIdsList, UserDataQAList, 및/또는 A_ARG_TYPE_UserDataQA 상태변수가 정의될 수 있다. 이 상태변수들은 필수 상태변수(Req) 로서, 전술한 이벤트 방식이 아닌 액션 방식에 따를 수 있고, 따라서 다양한 액션의 아규먼트로서 활용될 수 있다.
A_ARG_TYPE_UserDataQAIdsList 는 PDI 스토어에 저장되어 있는 Q&A 페어의 ID 의 리스트를 나타낼 수 있다. 본 상태변수는 전술한 QxAD 엘레멘트의 QxA 의 @id 와 관련된 아규먼트를 사용하는 액션들에 활용될 수 있다. 또한, 후술한 UserDataQAList 상태변수의 @id 들을 리스트로 표현할 수 있다. 본 상태변수는 실시예에따라 CSV 스트링의 형태일 수 있다.
UserDataQAList 는 PDI 스토어에 저장되어 있는 Q&A 페어 세트를 나타낼 수 있다. 본 상태변수는 복수개의 QxAD 엘레멘트를 가질 수 있다. 본 상태변수는 후술할 다양한 액션들에서 활용될 수 있다. 본 상태변수의 자세한 구조에 대해서는 후술한다. 본 상태변수는 실시예에따라 스트링의 형태일 수 있다.
A_ARG_TYPE_UserDataQA 는 전술한 UserDataQAList 의 한 프래그먼트일 수 있다. 이 때, 두 상태변수들은 같은 마크업 언어(markup language) 에 따를 수 있다. 예를 들어, UserDataQAList 상태변수가 XML 문서일 경우, A_ARG_TYPE_UserDataQA 는 그 XML 문서의 한 프래그먼트가 될 수 있다. 본 상태변수는 복수 개의 QxAD 엘레먼트와 어트리뷰트(attributes)를 가질 수 있다. 또한, 본 상태변수는 사용되는 액션의 용도에 따라서 서브 엘레먼트들을 포함할 수 있다. A_ARG_TYPE_UserDataQA 는 실시예에 따라 생략될 수도 있다. 본 상태변수는 실시예에따라 스트링의 형태일 수 있다.
도 103 은 본 발명의 일 실시예에 따른 UserDataQAList 의 XML 구조를 도시한 도면이다.
UserDataQAList 는 복수개의 QxAD 엘레멘트를 포함할 수 있다. 각 QxAD 엘레멘트 및 어트리뷰트(attribute) 들은 전술한 바와 같을 수 있다. 실시예에 따라 다른 형태로 QxAD 엘레멘트의 구조가 변경될 수 있다.
첫번째 UserDataQAList (t103010) 는, QIAD 와 QBAD 를 포함할 수 있다. QIAD 의 ID 는 "question1" 일 수 있고, question1 은 "what is your age" 와 같은 질문을 가질 수 있다. QBAD 역시 전술한 바와 같은 방식으로 정보를 가질 수 있다.
두번째 UserDataQAList (t103020) 는, QIAD, QBAD, QTAD 를 포함할 수 있다. 각 QxAD 역시, 전술한 바와 같은 방식으로 정보를 가질 수 있다.
UserDataQAList 는 전술한 두 실시예와 같은 형식으로, 복수개의 QxAD 를 포함할 수 있으며, 각 QxAD 는 전술한 QxAD 의 구조 또는, 실시예에 따라 다른 형태의 구조를 가질 수 있다.
도 104 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션(action)들을 도시한 도면이다.
전술한 UserData 서비스에는 GetUserDataQAIdsList, GetUserDataQA, 및/또는 SetUserDataQA, 액션이 있을 수 있다. 이 액션들은 필수적(Required)인 액션일 수 있다. 실시예에 따라 추가적인 액션들이 더 정의될 수 있다. 각 액션에 대해서는 후술한다.
도 105 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션들 중, GetUserDataQAIdsList 와 GetUserDataQA 를 설명하는 도면이다.
GetUserDataQAIdsList 액션을 설명한다.
GetUserDataQAIdsList 액션은 전술한 PDI 스토어에 저장된 Q&A 페어들의 ID 를 가져오는데 사용되는 액션일 수 있다. 즉, GetUserDataQAIdsList 액션은 UserDataQAList 상태변수의 QxAD 엘레멘트의 QxA 의 @id 값들의 리스트를 가져오는 액션일 수 있다. 이 리스트는 스트링 형태일 수 있으며(e.g. CSV), 다른 형태일 수도 있다. 컴패니언 디바이스는 GetUserDataQAIdsList 액션을 이용하여, 수신기 내/외부에 존재하는 PDI 스토어에서, Q&A 페어들의 ID 정보를 가져올 수 있다. 이 때, PDI 유저 데이터의 프로토콜 버전이 참조되어, QxAD엘레멘트의 @protocolVersion 값과 매칭되는 @id 들을 컴패니언 디바이스로 가져올 수 있다.
GetUserDataQAIdsList 액션을 사용하기 위해, ProtocolVersion 인풋 아규먼트와 UserDataQAIdsList 아웃풋 아규먼트가 정의될 수 있다(t105010). ProtocolVersion 아규먼트는 전술한 바와 같고, 전술한 PDIUserDataProtocolVersion 상태변수와 관련있을 수 있다. UserDataQAIdsList 아웃풋 아규먼트는 QxAD 엘레멘트의 QxA 의 @id 값들의 리스트로서, 전술한 A_ARG_TYPE_UserDataQAIdsList 상태변수와 관련 있을 수 있다. UserDataQAIdsList 는 스트링 형태의 리스트(e.g. CSV) 일 수 있다.
GetUserDataQA 액션을 설명한다.
GetUserDataQA 액션은 전술한 PDI 스토어에 저장된 Q&A 페어들을 가져오는데 사용되는 액션일 수 있다. 컴패니언 디바이스는 GetUserDataQA 액션을 이용하여, 수신기 내/외부에 존재하는 PDI 스토어에서, Q&A 페어들을 가져올 수 있다. 이 때, 전술한 UserDataQAIdsList 가 참조되어, 그 ID 에 매칭되는 QxAD 만을 프래그먼트 형태로 가지고 올 수 있다.
GetUserDataQA 액션을 사용하기 위해, UserDataQAIdsList 인풋 아규먼트와 UserDataQA 아웃풋 아규먼트가 정의될 수 있다(t105020). UserDataQAIdsList 아규먼트는 전술한 바와 같을 수 있고, 전술한A_ARG_TYPE_UserDataQAIdsList 상태변수와 관련있을 수 있다. UserDataQA 아웃풋 아규먼트는 전술한 UserDataQAList 상태변수의 프래그먼트로서 전술한 A_ARG_TYPE_UserDataQA 상태변수와 관련 있을 수 있다. UserDataQA 아규먼트는 QxAD 엘레멘트 등의 정보들을 가질 수 있으며, UserDataQAList의 데이터 타입을 따를 수 있다(e.g. XML).
예를 들어, GetUserDataQA(UserDataQAIdsList="question1", "question3") 와 같은 내용의 액션이 사용되었다면, 전술한 UserDataQAList 의 XML 구조에서, UserDataQAList 에 포함되는 복수개의 QxAD 중 id가 "question1" 인 것과, "question3" 인 QxAD가 리턴될 수 있다. 이 때, 리턴되는 UserData 의 XML 구조는 id 가 각각 "question1", "question3" 인 QxAD 만을 가질 수 있고, "question2" 의 id를 가지는 QxAD엘레먼트는 없을 수 있다.
GetUserDataQA 액션에서, 아웃풋 아규먼트인 UserDataQA의 QxAD 엘레멘트 수는 인풋 아규먼트인 UserDataQAIdsList 내의 @id의 개수보다 적거나 같을 수 있다.
전술한 GetUserDataQAIdsList 와 GetUserDataQA 액션의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다. 또한, 컴패니언 디바이스는 이미 활용 가능한 프로토콜 버전을 알고 있다고 가정한다.
여기서, 컨텐츠 프로바이더가 수신기로 PDI 유저 데이터를 전달하고, PDI 유저 데이터가 다시 PDI 엔진으로 저달되어 답변을 받고 Q&A 를 저장하는 과정(ts105010, ts105020, ts105030, ts105040) 은 전술한 바와 같을 수 있다.
전술한 컴패니언 디바이스는 수신기로부터 Q&A 페어를 얻기 위하여, 전술한 GetUserDataQAIdsList 액션을 수행할 수 있다(ts105050). 컴패니언 디바이스는 전술한 수신기 내부의 컴패니언 디바이스 모듈에, Q&A 페어의 ID 들을 요청할 수 있다.
컴패니언 디바이스 모듈은 PDI 엔진에, 컴패니언 디바이스로부터 요청받은 Q&A 페어의 ID를 요청할 수 있다(ts105060). PDI 엔진은 해당하는 Q&A 페어의 ID 들을 PDI 스토어에서 찾을 수 있다(ts105070). 그 후, PDI 엔진은 검색된 Q&A 페어의 ID 들을, 컴패니언 디바이스 모듈로 전달할 수 있다(ts105080).
컴패니언 디바이스 모듈은 전달받은 Q&A 페어의 ID 들을 컴패니언 디바이스로 전달할 수 있다(ts105090).
Q&A 페어의 ID 들을 얻게된 컴패니언 디바이스는, Q&A 페어를 얻기 위하여 전술한 GetUserDataQA 액션을 활용할 수 있다(ts105100). 컴패니언 디바이스는 전달받은 Q&A 페어의 ID 들을 이용하여, 또는 인풋 아규먼트로 사용하여 Q&A 페어들을 요청할 수 있다.
컴패니언 디바이스 모듈은 PDI 엔진에 해당 Q&A 페어를 요청할 수 있다(ts105110). 컴패니언 디바이스 모듈은 PDI 스토어에서 해당 Q&A 페어를 검색하고(ts105120), 검색된 Q&A 페어를 컴패니언 디바이스 모듈로 전달할 수 있다(ts105130).
컴패니언 디바이스 모듈은 전달받은 Q&A 페어를 컴패니언 디바이스로 전달할 수 있다(ts105140). 컴패니언 디바이스는 전달받은 Q&A 페어를 저장할 수 있다. 저장된 Q&A 페어들은 반영구적으로 저장되어 활용될 수 있으며, 만약 컴패니언 디바이스에 저장소가 없을 경우, 메모리 등의 공간에 일시적으로 저장할 수도 있다.
본 발명에서, GetUserDataQAIdsList 와 GetUserDataQA 액션을 수행하는 시점은, 특정 시점에 한정되지 아니한다. 실시예에 따라, 컴패니언 디바이스와 수신기가 페어링된 직후에 각 액션이 수행될 수 있다. 또한, 실시예에 따라, 컴패니언 디바이스가 수신기에 주기적으로 폴링(polling) 하면서 요청할 수도 있다.
도 106 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어 단위 전달을 위한, UserData 서비스의 액션들 중, SetUserDataQA 를 설명하는 도면이다.
SetUserDataQA 액션은 전술한 SetUserData 액션과 마찬가지로, 역으로 컴패니언 디바이스에서 PDI 유저 데이터가 설정/저장되고, 이 설정된 PDI 유저 데이터의 Q&A 가 수신기로 전달될 때 사용되는 액션일 수 있다. SetUserDataQA 액션은 UserDataQAList 를 인풋 아규먼트로 가지고, 전술한 UserDataQAList 상태변수와 관련있을 수 있다(t106010).
SetUserDataQA 액션을 통해 전달된 Q&A를 이용하여, 수신기 내에 기저장되어 있던 Q&A 가 수정/업데이트될 수 있다. 수신기는 전달받은 Q&A들을 PDI 스토어에 저장되어 있는 Q&A들과 비교할 수 있다. 해당 Q&A가 없는 경우 전달받은 Q&A를 추가할 수 있다. 해당 Q&A가 있는 경우, QxAD 엘레멘트의 QxA 의 A 의 @time 과 비교하여 Q&A 의 답변 기입 시간이 더 최신인 쪽을 유지할 수 있다.
SetUserDataQA 액션의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
여기서, 컨텐츠 프로바이더가 PDI 유저 데이터를 컴패니언 디바이스로 전달하고, 답변을 얻는 과정(ts106010, ts106020) 은 전술한 바와 같을 수 있다.
컴패니언 디바이스는 SetUserDataQA 액션을 통해 설정된 Q&A를, 전술한 수신기 내부의 컴패니언 디바이스 모듈로 전달할 수 있다(ts106030).
컴패니언 디바이스 모듈은 전달받은 Q&A를 PDI 엔진으로 전달할 수 있다(ts106040). PDI 엔진은 PDI 스토어에 기 저장되어 있는 Q&A가 있는지 검색할 수 있다(ts106050). PDI 엔진은 검색결과, 기존에 저장되어 있는 Q&A가 없으면 Q&A를 저장하고, 기존에 저장되어 있는 Q&A가 있으면 @time 정보에 따라 Q&A를 업데이트할 수 있다(ts106060).
예를 들어, 수신기의 PDI 스토어에는 전술한 UserDataQAList 의 XML 구조에, id가 "question1" 인 QxAD가 저장되어 있을 수 있다. 컴패니언 디바이스에는 전술한 UserDataQAList 의 XML 구조에 id 가 "question3" 인 QxAD가 저장되어 있을 수 있다.
SetUserDataQA 액션을 통해 컴패니언 디바이스는 id 가 "question3" 인 QxAD를 수신기로 전달할 수 있다. 수신기의 PDI 엔진은 id 가 "question3" 인 QxAD가 PDI 스토어에 존재하지 않으므로, 해당 QxAD를 추가하여 PDI 스토어에 저장할 수 있다. 최종적으로 수신기의 PDI 스토어에는 전술한 UserDataQAList 의 XML 구조에, id가 "question1" 인 QxAD와, id 가 "question3" 인 QxAD 가 함께 저장될 수 있다.
도 107 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
브로드캐스터 채널이 지원되지 않고 브로드밴드 채널(e.g. 인터넷) 만이 지원되는 환경에서도, 수신기는 PDI 유저 데이터를 전달받을 수 있다. 이러한 환경에서도 브로드밴드 채널을 통해 PDI 유저 데이터를 받기 위하여 별도의 PDI 서버가 존재할 수 있다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
전술한 환경에서, 수신기는 현재 지원되는 서비스의 리스트를 시그널링받는 과정에서, 브로드밴드채널로 PDI 유저 데이터를 받을 수 있다는 알림을 받을 수 있다(ts107001). 수신기는 이 알림(Notification) 을 수신받아 파싱할 수 있다.
수신기는 PDI 유저 데이터를 PDI 서버에 요청할 수 있다(ts107005). 이 때, 전술한 파싱결과 얻은 URL 을 이용하여 PDI 서버에 액세스할 수 있다. 이 때, 수신기 내/외부의 서비스 리스트 클라이언트가 PDI 서버와 통신할 수 있다. 요청받은 PDI 서버는 요청받은 PDI 유저 데이터를 수신기로 전달할 수 있다(ts107010). 서비스 리스트 클라이언트는 PDI 유저 데이터를 PDI 엔진으로 전달할 수 있다(ts107020).
이 후, PDI 엔진이 PDI 스토어에 답변을 저장하고, 컴패니언 디바이스가 GetUserDataIdsList 및 GetUserData 액션을 활용하여 PDI 유저 데이터를 가져오는 과정(ts107020~ts107140) 은 전술한 바와 같다.
상기와 같은 방식을 통해, 브로드캐스터 채널이 지원되지 않고 브로드밴드 채널만이 지원되는 환경에서도, 수신기는 PDI 유저 데이터를 전달받을 수 있다.
PDI 서버는 PDI 유저 데이터만 전달하는 독립적인 역할을 할 수도 있고, 시그널링을 위한 각종 테이블 들이 저장되어 있는 통합 시그널링 서버의 역할을 담당할 수도 있다. 만약 PDI 유저 데이터를 전달받으라는 알림(notification)이 없는 경우, 수신기는 PDI 서버와 지속적으로 요청/답변(request/response) 의 과정을 수행할 수 있다. 단 이 경우, 수신기는 PDI 서버의 URL을 미리 알고 있어야 한다.
도 108 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 상태변수를 도시한 도면이다.
본 상태변수들은, 컴패니언 디바이스가 직접 PDI 서버에 요청을 하여 PDI 유저 데이터를 받는 경우의 상태변수들일 수 있다. 이 상황에서, PDIUserDataNotification 및/또는 PDIServerUrl 상태변수가 정의될 수 있다.
PDIUserDataNofitication 상태변수는 브로드밴드채널로 PDI 유저 데이터를 받을 수 있다는 알림을 전달받은 시간을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 dataTime 이며, 이벤트 방식을 따를 수 있다. 이벤트 타입이므로, 알림을 전달받은 시간이 변경되면, 즉 새로이 알림을 받으면, 이를 컴패니언 디바이스에 알릴 수 있다.
PDIServerUrl 상태변수는 브로드밴드채널로 PDI 유저 데이터를 받을 수 있는 PDI 서버의 URL 을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 스트링 또는 anyURI 이며, 액션 방식을 따를 수 있다. 따라서, 컴패니언 디바이스가 액션등을 통해 해당 URL 을 받아와야 할 수 있다. 이에 대해서는 후술한다.
도 109 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 액션을 설명한 도면이다.
이러한 상황에서, GetPDIServerUrl 이라는 액션이 정의될 수 있다(t109010). GetPDIServerUrl 액션은 PDI 서버의 URL 을 가져오는데 사용되는 액션일 수 있다. GetPDIServerUrl 액션은 PDIServerUrl 이라는 아웃풋 아규먼트를 가질 수 있다(t109020). PDIServerUrl 아규먼트는 전술한 PDIServerUrl 상태변수와 관련있을 수 있다. 이 아규먼트는 PDI 서버의 URL 을 저장할 수 있다.
GetPDIServerUrl 액션의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다. 또한 컴패니언 디바이스는 UserData 서비스에 이미 섭스크라이빙되어 있다고 가정한다.
여기서, 수신기가 브로드밴드 채널을 통해 PDI 유저 데이터를 전달받을 수 있다는 알람을 받는 단계(ts109010)는 전술한 바와 같을 수 있다.
수신기의 서비스 리스트 클아이언트는, 컴패니언 디바이스 모듈에 파싱된 PDI 서버의 URL 을 전달하고, PDI 유저 데이터를 전달받을 수 있다는 것을 알릴 수 있다(ts109020).
컴패니언 디바이스 모듈은 PDIUserDataNotification 상태변수를 업데이트한다(ts109030). 알람을 새로이 전달받았기 때문이다. 이벤트 방식에 따라, 컴패니언 디바이스 모듈은 컴패니언 디바이스에 PDIUserDataNotification 상태변수가 변경되었음을 알릴 수 있다(ts109040).
컴패니언 디바이스는 GetPDIServerUrl 액션을 수행하여(ts109050), 해당 PDI 서버의 URL 을 전달받을 수 있다(ts109060). 컴패니언 디바이스는 이 URL 을 이용하여 PDI 서버에 접근할 수 있다. PDI 서버에 PDI 유저 데이터를 요청하고(ts109070), 해당 PDI 유저 데이터를 받아올 수 있다(ts109080).
컴패니언 디바이스는 질문에 대한 답변을 유저로부터 얻을 수 있다(ts109090). 이 후, 컴패니언 디바이스는 전술한 SetUserData 또는 SetUserDataQA 액션을 이용하여, 수신기의 PDI 스토어에 해당 PDI 유저 데이터를 업데이트 시킬 수 있다(ts109100 ~ ts109130). 이 과정은 전술한 바와 같다.
전술한 바와 같이, GetPDIServerUrl 액션이 활용될 수 있다.
도 110 은 본 발명의 일 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
PDI 서버는 복수개가 존재할 수 있다. 따라서, PDI 서버 URL 역시 복수개가 존재할 수 있다. 수신기는 컴패니언 디바이스가 접속해야할 PDI 서버를 특정하여, 그 PDI 서버의 URL 을 전달해 줄 수 있다.
이 때, 접속 가능한 모든 PDI 서버의 URL 이 모두 컴패니언 디바이스로 전달될 수도 있다. 이 경우 컴패니언 디바이스가 PDI 서버 중 하나를 선택하여 접속할 수 있다. 복수개의 URL 을 전달하기 위하여 전술한 PDIServerURL 을 활용하여 수행될 수 있다. 단 이 경우, PDIServerURL 은 확장되어 데이터 타입이 "List of string" 또는 "List of anyURI" 로 변경될 수 있다.
실시예에 따라, PDIServerUrl 는 CSV 형태일 수 있으며, (http://pdiserver1.com , http://pdiserver2.com , …,) 등과 같이 표현될 수 있다.
도 111 은 본 발명의 다른 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
전술한 PDIServerUrl 상태변수는 액션 방식이 아닌 이벤트 방식을 따르도록 확장될 수 있다. 이 경우 GetPDIServer 액션이 수행될 필요없이 바로 PDI 서버 URL 이 컴패니언 디바이스로 전달될 수 있다.
컴패니언 디바이스가 UserData 서비스에 섭스크라이빙한 직 후, 또는 PDI 서버의 URL 이 변경되는 경우에 PDI 서버의 URL 이 컴패니언 디바이스로 전달될 수 있다. 이 때, PDI 서버의 URL 은 PDIServerUrl 상태변수의 형태로 전달될 수 있다.
전술한 바와 같이, PDI 서버의 URL 이 복수개인 경우, 수신기가 특정 URL 만 전달해줄 수도 있고, 모든 URL 을 전달해줄 수도 있다. 이에 따라, PDIServerUrl 의 데이터 타입은, string, anyURI, List of strings, 및/또는 List of anyURI 일 수 있다.
도 112 는 본 발명의 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
전술한 바와 같이, 사용자가 지정한 PDI 유저 데이터를 이용하여, 개인화된 서비스를 제공할 수 있다. 이를 위하여 필터링 크리테리아(Filtering Criteria) 가 제공될 수 있다. 필터링 크리테리아를 통해 수신기/컴패니언 디바이스는 사용자에게 맞춘 컨텐츠를 제공할 수 있다.
여기서, 컨텐츠 프로바이더 또는 브로드캐스터(t112010), PDI 설문지(t112020), PDI 엔진(t112030), PDI 스토어(t112040), PDI 클라우드 스토어(t112070), 컴패니언 디바이스 모듈(t112060), 컴패니언 디바이스(t112080) 는 전술한 동명의 모듈과 같을 수 있다.
여기서, 수신기(t112050) 은 전술한 구조도와 달리 필터링 엔진(t112090), 컨텐츠/서비스 스토어(t112100) 을 더 포함할 수 있다. 필터링 엔진은 각 컨텐츠/서비스의 필터링 크리테리아와, 저장된 PDI 유저 데이터를 비교하여 사용자에게 맞춘 컨텐츠/서비스를 선별할 수 있다. 필터링 크리테리아는 컴패니언 디바이스에도 전달될 수 있다.
실시예에 따라, 필터링 크리테리아에 의해 선별된 데이터가 컴패니언 디바이스에 전달될 수도 있고, 필터링 크리테리아를 컴패니언 디바이스에 전달하여, 컴패니언 디바이스가 직접 필터링을 할 수도 있다.
필터링 크리테리아의 XML 구조에 대해서는 전술하였다. 단, 전술한 구조에 의해 한정되지 아니하며, 실시예에 따라 다른 구조의 필터링 크리테리아가 사용될 수 있다. 이하 필터링 크리테리아는 FC 로 축약하여 불릴 수 있다.
컨텐츠/서비스 스토어(t112100)는 수신한 컨텐츠/서비스를 저장하는 공간이다. 실시예에 따라 필터링 엔진에 의해 필터링된 컨텐츠/서비스가 컨텐츠/서비스 스토어(t112100)에 저장될 수 있다. 또한 실시예에 따라 모든 컨텐츠/서비스가 컨텐츠/서비스 스토어에 저장된 후, 추후에 필터링 엔진이 필터링을 수행하여 다시 컨텐츠/서비스 스토어에 저장할 수도 있다.
도 113 은 본 발명의 다른 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
수신기가 컴패니언 디바이스로 필터링 크리테리아를 전달하기 위해서, FilteringCriteria 라는 서비스가 정의될 수 있다. 이 서비스의 서비스 타입은 atsc3.0filtering:1 일 수 있다.
각 서비스는 다른 서비스 ID 를 가질 수 있는 데, 실시예에 따라 uurn:atsc.org:serviceId:atsc3.0filtering1(t113010), 또는 uurn:atsc.org:serviceId:atsc3.0filtering(t113020) 일 수 있다.
FilteringCriteria 서비스에 대해서는 후술한다.
도 114 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
FiltringCriteria 서비스의 한 상태변수로 FilteringCriteria 상태변수가 정의될 수 있다.
FilteringCriteria 상태변수는 컨텐츠/서비스의 필터링을 위하여, 필터링 크리테리아를 컴패니언 디바이스에 전달하기 위해 사용될 수 있다. FilteringCriteria 상태변수는 필수 상태변수로서 데이터 타입은 String 타입(XML, Jason 등..)일 수 있다. 또한, 전술한 액션 방식을 따라, 다양한 액션에서 사용될 수 있다.
도 115 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 액션을 설명한 도면이다.
FilteringCriteria 서비스는 GetFilteringCriteria 액션을 가질 수 있다(t115010). 본 액션은 컴패니언 디바이스가 수신기로부터 필터링 크리테리아를 가져오기 위한 액션일 수 있다.
GetFilteringCriteria 액션은 FilteringCriteria 를 아웃풋 아규먼트로 가질 수 있다(t115020). 본 액션은 전술한 FilteringCriteria 상태변수와 관련있을 수 있다. 본 액션을 사용하면, FilteringCriteria 가 컴패니언 디바이스로 출력될 수 있다.
전술한 GetFilteringCriteria 액션의 동작 및 필터링 크리테리아를 이용한 개인화 서비스 제공의 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
컨텐츠 프로바이더 또는 브로드캐스터는 컴패니언 디바이스에서 수행될 컨텐츠나 서비스를 수신기에 전달할 수 있다(ts115010). 이 때, 컨텐츠 프로바이더 또는 브로드캐스터는 FC 역시 수신기에 전달할 수 있다.
수신기는 필터링 엔진에 FC 를 전달할 수 있다(ts115020). 또한, 수신기는 컴패니언 디바이스 모듈로 컴패니언 디바이스를 위한 컨텐츠/서비스가 존재한다고 알릴 수 있다(ts115030). 컴패니언 디바이스 모듈은 이를 컴패니언 디바이스에 알릴 수 있다(ts115040).
컴패니언 디바이스 모듈은 전술한 GetFilteringCriteria 액션을 사용할 수 있다(ts115050). 이 액션을 통해, 컴패니언 디바이스 모듈은, FC 를 컴패니언 디바이스 모듈로 요청할 수 있다. FC 는 컴패니언 디바이스가 컨텐츠/서비스를 수신하기 전에 사용자가 설정한 PDI 유저 데이터를 참조하기 위해 사용될 수 있다.
컴패니언 디바이스 모듈은 필터링 엔진에 FC 를 요청할 수 있다(ts115060). 필터링 엔진은 FC 를 컴패니언 디바이스로 전달할 수 있다(ts115070). 컴패니언 디바이스 모듈은, FC 를 컴패니언 디바이스로 전달할 수 있다(ts115080).
컴패니언 디바이스는 PDI 유저 데이터를 컴패니언 디바이스 모듈로 요청할 수 있다(ts115090). PDI 유저 데이터를 요청하는데에는 전술한 액션들이 활용될 수 있다.
컴패니언 디바이스 모듈은 PDI 엔진에 설문지 에 대한 답변을 요청할 수 있다(ts115100). PDI 엔진은 PDI 스토어에 기 저장된 설문지 에 대한 답변을 검색할 수 있다(ts115110). PDI 엔진은 검색이 완료된 답변을 컴패니언 디바이스 모듈로 전달할 수 있다(ts115120). 컴패니언 디바이스 모듈은, PDI 유저 데이터인 해당 답변을 컴패니언 디바이스로 전달할 수 있다(ts115130).
컴패니언 디바이스는 FC 와 사용자가 기설정한 답변을 비교할 수 있다(ts115140). FC 가, 사용자의 답변, 즉 PDI 유저 데이터에 만족할 경우, 해당 컨텐츠/서비스가 사용자에게 제공될 수 있다. 그렇지 않은 경우, 해당 컨텐츠/서비스가 사용자에게 제공되지 않을 수 있다.
컴패니언 디바이스는, FC 가 사용자의 답변과 부합할 경우, 수신기로부터 해당 컨텐츠/서비스를 가져올 수 있다. 이 때, 해당 컨텐츠/서비스의 전달은 컴패니언 디바이스 모듈을 통해 수행될 수 있다(ts115150, ts115160). 실시예에 따라, FC 가 사용자의 답변과 부합할 경우, 컴패니언 디바이스는 해당 컨텐츠/서비스를 서비스 프로바이더 또는 브로드캐스터의 서버로부터 직접 수신할 수도 있다.
이 후, 컴패니언 디바이스는 PDI 유저 데이터에 맞는 FC 를 가진 컨텐츠/서비스를 유저에게 노출시킬 수 있다.
도 116 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
전술한 것과 같이, 브로드캐스터 채널이 지원되지 않고 브로드밴드 채널(e.g. 인터넷) 만이 지원되는 환경에서도, 수신기는 FC 를 전달받을 수 있다. 이러한 환경에서도 브로드밴드 채널을 통해 FC를 받기 위하여 별도의 FC 서버가 존재할 수 있다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다.
전술한 환경에서, 수신기는 현재 지원되는 서비스의 리스트를 시그널링받는 과정에서, 브로드밴드채널로 FC 를 받을 수 있다는 알림을 받을 수 있다(ts116001). 실시예에 따라, 수신기 내지 서비스 리스트 클라이언트는 브로드캐스트 채널의 시그널링 정보를 요청할 수 있는데, 이 요청에 따라 시그널링 정보를 받는 과정에서, 수신기는 전술한 알림을 받을 수 있다. 이하, 수신기 내지 서비스 리스트 클라이언트는 수신기라 불릴 수 있다. 전달받은 알람이 파싱되어 FC 서버의 URL 을 얻을 수 있다.
수신기는 FC 를, FC 서버에 요청할 수 있다(ts116005). 이 때, 파싱된 FC 서버의 URL 이 활용될 수 있다. 요청받은 FC 서버는 요청받은 FC를 수신기로 전달할 수 있다(ts116010). FC 가 브로드밴드 채널을 통해 전달되는 경우, FC 는 시그널링 채널을 통해 전달될 수 있으며, FC 는 Binary 또는 XML 형태로 전달될 수 있다. 이 때, 브로드밴드 채널에는 여러 종류가 있을 수 있으며, 일 실시예로 SMT, NRT-IT 등의 채널이 사용될 수 있다. 수신기 내지 서비스 리스트 클라이언트는 FC를 필터링 엔진으로 전달할 수 있다(ts116020).
이 후, 컴패니언 디바이스에 컨텐츠/서비스의 존재를 알리고, GetFilteringCriteria 액션을 통해 FC 가 컴패니언 디바이스에 전달되고, PDI 유저 데이터가 컴패니언 디바이스에 전달되고, FC 와 PDI 유저 데이터를 비교하여, 개인화 서비스를 제공하는 과정(ts116030 - ts116160) 은 전술한 바와 같을 수 있다.
상기와 같은 방식을 통해, 브로드캐스터 채널이 지원되지 않고 브로드밴드 채널만이 지원되는 환경에서도, 수신기는 FC 를 전달받을 수 있다.
FC 서버는 FC만 전달하는 독립적인 역할을 할 수도 있고, 시그널링을 위한 각종 테이블 들이 저장되어 있는 통합 시그널링 서버의 역할을 담당할 수도 있다. 만약 FC를 전달받으라는 알림(notification)이 없는 경우, 수신기는 FC 서버와 지속적으로 요청/답변(request/response) 의 과정을 수행할 수 있다. 단 이 경우, 수신기는 FC 서버의 URL을 미리 알고 있어야 한다.
도 117 은 본 발명의 일 실시예에 따른, FC가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
본 상태변수들은, 컴패니언 디바이스가 직접 FC 서버에 요청을 하여 FC 를 받는 경우의 상태변수들일 수 있다. 이 상황에서, FilteringCriteriaNotification 및/또는 FCServerUrl 상태변수가 정의될 수 있다.
FilteringCriteriaNotification 상태변수는 브로드밴드채널로 FC를 받을 수 있다는 알림을 전달받은 시간을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 dataTime 이며, 이벤트 방식을 따를 수 있다. 이벤트 타입이므로, 알림을 전달받은 시간이 변경되면, 즉 새로이 알림을 받으면, 이를 컴패니언 디바이스에 알릴 수 있다.
PDIServerUrl 상태변수는 브로드밴드채널로 FC를 받을 수 있는 FC 서버의 URL 을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 스트링 또는 anyURI 이며, 액션 방식을 따를 수 있다. 따라서, 컴패니언 디바이스가 액션등을 통해 해당 URL 을 받아와야 할 수 있다. 이에 대해서는 후술한다.
도 118 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 액션을 설명한 도면이다.
이러한 상황에서, GetFCServerUrl 이라는 액션이 정의될 수 있다(t118010). GetFCServerUrl 액션은 FC 서버의 URL 을 가져오는데 사용되는 액션일 수 있다. GetFCServerUrl 액션은 FCServerUrl 이라는 아웃풋 아규먼트를 가질 수 있다(t118020). FCServerUrl 아규먼트는 전술한 FCServerUrl 상태변수와 관련있을 수 있다. 이 아규먼트는 FC 서버의 URL 을 저장할 수 있다.
GetFCServerUrl 액션의 동작 시퀀스 다이어그램의 일 실시예를 설명한다.
본 동작 시퀀스 다이어그램에서 컴패니언 디바이스와 수신기는 이미 페어링되어 있으며, 페어링하는 과정은 생략되었다. 또한 컴패니언 디바이스는 FilteringCriteria 서비스에 이미 섭스크라이빙되어 있다고 가정한다.
여기서, 수신기가 브로드밴드 채널을 통해 FC를 전달받을 수 있다는 알람을 받는 단계(ts118010)는 전술한 바와 같을 수 있다.
수신기의 서비스 리스트 클라이언트는, 컴패니언 디바이스 모듈에 파싱된 FC서버의 URL 을 전달하고, FC를 전달받을 수 있다는 것을 알릴 수 있다(ts118020).
컴패니언 디바이스 모듈은 FilteringCriteriaNotification 상태변수를 업데이트한다(ts118030). 알람을 새로이 전달받았기 때문이다. 이벤트 방식에 따라, 컴패니언 디바이스 모듈은 컴패니언 디바이스에 FilteringCriteriaNotification 상태변수가 변경되었음을 알릴 수 있다(ts118040).
컴패니언 디바이스는 GetFCServerUrl 액션을 수행하여(ts118050), 해당 FC서버의 URL 을 전달받을 수 있다(ts118060). 컴패니언 디바이스는 이 URL 을 이용하여 FC서버에 접근할 수 있다. FC서버에 FC를 요청하고(ts118070), 해당 FC를 받아올 수 있다(ts118080).
이 후, 컴패니언 디바이스 모듈이 PDI 유저 데이터를 요청하여, 해당 답변을 얻고, FC 와 PDI 유저 데이터를 비교하여, 개인화 서비스를 제공하는 과정(ts118090 - ts118160) 은 전술한 바와 같을 수 있다.
상기와 같은 방식을 통해, 브로드캐스터 채널이 지원되지 않고 브로드밴드 채널만이 지원되는 환경에서, 컴패니언 디바이스는 FC 서버로부터 직접 FC 를 전달받아 개인화 서비스를 제공할 수 있다.
도 119 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
FC 서버는 복수개가 존재할 수 있다. 따라서, FC 서버 URL 역시 복수개가 존재할 수 있다. 수신기는 컴패니언 디바이스가 접속해야할 FC 서버를 특정하여, 그 PDI 서버의 URL 을 전달해 줄 수 있다.
이 때, 접속 가능한 모든 FC 서버의 URL 이 모두 컴패니언 디바이스로 전달될 수도 있다. 이 경우 컴패니언 디바이스가 FC 서버 중 하나를 선택하여 접속할 수 있다. 복수개의 URL 을 전달하기 위하여 전술한 FCServerUrl 을 활용하여 수행될 수 있다. 단 이 경우, FCServerUrl 은 확장되어 데이터 타입이 "List of string" 또는 "List of anyURI" 로 변경될 수 있다.
실시예에 따라, FCServerUrl 는 CSV 형태일 수 있으며, ( , , …,) 등과 같이 표현될 수 있다.
도 120 은 본 발명의 다른 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
전술한 FCServerUrl 상태변수는 액션 방식이 아닌 이벤트 방식을 따르도록 확장될 수 있다. 이 경우 GetFCServerUrl 액션이 수행될 필요없이 바로 FC 서버 URL 이 컴패니언 디바이스로 전달될 수 있다.
컴패니언 디바이스가 FilteringCriteria 서비스에 섭스크라이빙한 직 후, 또는 FC 서버의 URL 이 변경되는 경우에 FC 서버의 URL 이 컴패니언 디바이스로 전달될 수 있다. 이 때, FC 서버의 URL 은 FCServerUrl 상태변수의 형태로 전달될 수 있다.
전술한 바와 같이, FC 서버의 URL 이 복수개인 경우, 수신기가 특정 URL 만 전달해줄 수도 있고, 모든 URL 을 전달해줄 수도 있다. 이에 따라, FCServerUrl 의 데이터 타입은, string, anyURI, List of strings, 및/또는 List of anyURI 일 수 있다.
도 121 은 본 발명의 일 실시예에 따른 방송 수신기를 나타낸 도면이다.
본 발명의 일 실시예에 따른 방송 수신기는, 서비스/콘텐츠 획득 제어기 (J2010), 인터넷 인터페이스 (J2020; Internet interface), 방송망 인터페이스 (J2030; Broadcast interface), 시그널링 디코더 (J2040), 서비스 맵 데이터 베이스 (J2050), 디코터 (J2060), 타겟팅 프로세서 (J2070), 프로세서 (J2080), 관리 유닛 (J2090; Managing unit) 및/또는 재분배 모듈 (J2100; redistribution module) 를 포함한다. 도면에서는 방송 수신기의 외부 및/또는 내부에 존재할 수 있는 외부 관리장치 (J2110; External Management)이 도시되어 있다.
서비스/콘텐츠 획득 제어기 (J2010)는 방송/브로드밴드(broadcast/broadband) 채널을 통하여 서비스 및/또는 콘텐츠, 이와 관련된 시그널링 데이터를 수신한다. 또는 서비스/콘텐츠 획득 제어기 (J2010)는 서비스 및/또는 콘텐츠, 이와 관련된 시그널링 데이터를 수신하기 위한 제어를 수행할 수 있다.
인터넷 인터페이스 (J2020; Internet interface)는 인터넷 어세스 컨트롤 모듈 (Internet Access Control Module)를 포함할 수 있다. 인터넷 어세스 컨트롤 모듈은 Broadband 채널을 통하여 서비스, 콘텐츠 및/또는 시그널링 데이터를 수신한다. 또는 인터넷 어세스 컨트롤 모듈은 서비스, 콘텐츠 및/또는 시그널링 데이터를 획득하기 위한 수신기의 동작을 제어할 수 있다.
방송망 인터페이스 (J2030; Broadcast interface)는 물리적 계층 모듈 (Physical Layer Module) 및/또는 물리적 계층 인터페이스 모듈 (Physical Layer I/F Module)을 포함할 수 있다. 물리적 계층 모듈은 방송 채널을 통하여 방송 관련 신호를 수신한다. 물리적 계층 모듈은 방송 채널을 통하여 수신한 방송 관련 신호를 처리 (복조, 복호 등) 한다. 물리적 계층 인터페이스 모듈은 물리적 계층 모듈로부터 획득한 정보로부터, IP (Internet Protocol) 데이터그램을 획득하거나, 획득된 IP 데이터그램을 이용하여 특정 프레임 (예를 들면, 방송 프레임, RS Frame, 또는 GSE 등)으로 변환한다.
시그널링 디코더 (J2040)는 방송 채널 등을 통하여 획득한 시그널링 데이터 또는 시그널링 정보 (이하 '시그널링 데이터'라 한다)를 디코딩한다.
서비스 맵 데이터 베이스 (J2050)는 디코딩된 시그널링 데이터를 저장하거나, 수신기의 다른 장치 (예를 들면, 시그널링 파서 등)에서 처리된 시그널링 데이터를 저장한다.
디코더 (J2060)는 수신기에서 수신한 방송 신호 또는 데이터를 디코딩한다. 디코더 (J2060)는 스케쥴드 스트리밍 디코더 (Scheduled Streaming Decoder), 파일 디코더 (File Decoder), 파일 데이터베이스 (File DB), 온디멘드 스트리밍 디코더 (On-Demand Streaming Decoder), 컴포넌트 동기화기 (Component Synchronizer), 경보 시그널링 파서 (Alert Signaling Parser), 타겟팅 시그널링 파서 (Targeting Signaling Parser), 서비스 시그널링 파서 (Service Signaling Parser) 및/또는 어플리케이션 시그널링 파서 (Application Signaling Parser)를 포함할 수 있다.
스케쥴드 스트리밍 디코더 (Scheduled Streaming Decoder)는 IP 데이터그램 등으로 부터 실시간 A/V (Audio / Video) 스트리밍을 위한 오디오/비디오 데이터 추출하고, 이를 디코딩한다.
파일 디코더 (File Decoder)는 IP 데이터그램으로부터, NRT 데이터 및 어플리케이션 (application) 등 파일 형태 데이터 추출하고, 이를 디코딩한다.
파일 데이터베이스 (File DB)는 파일 디코더에서 추출한 데이터를 저장한다.
온디멘드 스트리밍 디코더 (On-Demand Streaming Decoder) 는 IP 데이터그램등으로 부터 사용자 요청 (on-demand) 스트리밍을 위한 오디오/비디오 데이터 추출하고, 이를 디코딩한다.
컴포넌트 동기화기 (Component Synchronizer)는 스케쥴드 스트리밍 디코더, 파일 디코더 및/또는 온디멘드 스트리밍 디코더를 통하여 디코딩 된 데이터를 기반으로, 콘텐츠를 구성하는 요소들 사이의 동기화를 수행하거나, 서비스를 구성하는 요소들 사이의 동기화를 수행하여, 콘텐츠 또는 서비스를 구성한다.
경보 시그널링 파서 (Alert Signaling Parser)는 IP 데이터그램 등으로부터 경보 (alerting)와 관련된 시그널링 정보 추출하고, 이를 파싱한다.
타겟팅 시그널링 파서 (Targeting Signaling Parser)는 IP 데이터그램 등으로부터 서비스/콘텐츠 개인화, 또는 타겟팅 관련된 시그널링 정보 추출하고, 이를 파싱한다. 여기서 타겟팅은, 특정 시청자의 조건에 맞는 콘텐츠 또는 서비스를 제공하는 것으로, 해당 시청자의 조건에 맞는 콘텐츠 또는 서비스를 식별하여 이를 제공하는 행위를 말한다.
서비스 시그널링 파서 (Service Signaling Parser)는 IP 데이터그램 등으로부터 서비스 스캔 및/또는 서비스/콘텐츠 등과 관련된 시그널링 정보를 추출하고, 이를 파싱한다. 서비스/콘텐츠 등과 관련된 시그널링 정보는 방송 시스템 정보 및/또는 방송 시그널링 정보를 포함한다.
어플리케이션 시그널링 파서는 IP 데이터그램 등으로부터 어플리케이션 획득과 관련된 시그널링 정보를 추출하고, 이를 파싱한다. 어플리케이션 획득과 관련된 시그널링 정보는 트리거 (Trigger), TPT (TDO parameter table) 및/또는 TDO 파라미터 엘레멘트를 포함할 수 있다.
타겟팅 프로세서 (J2070)는 타겟팅 시그널링 파서에서 파싱된 서비스/콘텐츠 타겟팅 관련 정보를 처리한다.
프로세서 (J2080)는 수신한 데이터를 디스플레이하기 위한 일련의 처리를 수행한다. 프로세서 (J2080)는 경보 프로세서 (Alert Processor), 어플리케이션 프로세서 (Application Processor) 및/또는 오디오/비디오 프로세서 (A/V Processor)를 포함할 수 있다.
경보 프로세서는 경보와 관련된 시그널링 정보를 통하여, 경보 데이터를 획득하도록 수신기를 제어하고, 경보 데이터를 디스플레이하기 위한 처리를 수행한다.
어플리케이션 프로세서는 어플리케이션 관련 정보를 처리하고, 다운로드 된 어플리케이션의 상태 및 어플리케이션과 관련한 디스플레이 파라미터를 처리한다.
오디오/비디오 프로세서는 디코딩된 오디오 데이터, 비디오 데이터 및/또는 어플리케이션 데이터을 기반으로 오디오/비디오 랜더링 관련 동작을 수행한다.
관리 유닛 (J2090; Managing unit)은 장치 매니저 (device manager) 및/또는 데이터 통신 및 쉐어링 유닛 (Data Sharing & Communication Unit)을 포함한다.
장치 매니저는 연결 및 데이터 교환 등 연동 가능한 외부 장치 추가/삭제/갱신 등 외부 장치에 대한 관리를 수행한다.
데이터 통신 및 쉐어링 유닛은 수신기와 외부 장치 (예를 들면, companion device)간의 데이터 전송 및 교환 관련 정보를 처리하고, 이와 관련한 동작을 수행한다. 전송 및 교환 가능한 데이터는 시그널링 데이터, PDI table, PDI user data, PDI Q&A 및/또는 A/V 데이터가 될 수 있다.
재분배 모듈 (J2100; redistribution module)은 수신기가 방송 신호를 직접 수신 하지 못하는 경우, 방송 서비스/콘텐츠 관련 정보 및/또는 서비스/콘텐츠 데이터 획득을 수행한다.
외부 관리장치 (J2110; External Management)는 방송 서비스/컨텐츠 서버 등, 방송 서비스/콘텐츠 제공을 위한 방송 수신기 외부의 모듈들을 지칭한다. 외부 관리 장치의 역할을 수행하는 모듈은 방송 수신기 내부에 구비될 수도 있다.
도 122 는 본 발명의 다른 실시예에 따른 방송 수신기를 나타낸 도면이다.
도시된 수신기는 전술한 수신기 및 수신기에 포함되는 장치와 유사하므로, 동일한 명칭을 가지는 장치에 대한 설명은, 전술한 설명으로 대체한다.
전술한 타겟팅 시그널링 파서 (Targeting Signaling Parser)는 유저 데이터 쉐어링 및 타겟팅 시그널링 파서 (User Data Sharing & Targeting Signaling Parser) 로 명명될 수 있고, 전술한 user data (예를 들면, PDI user data 또는 Q&A)를 파싱하는 역할을 더 수행할 수 있다.
전술한 타겟팅 프로세서 (Targeting Processor)는 유저 데이터 쉐어링 및 타겟팅 프로세서 (User Data Sharing & Targeting Processor) 로 명명될 수 있고, 전술한 user data (예를 들면, PDI user data 또는 Q&A)를 처리하는 역할을 더 수행할 수 있다.
본 발명의 다른 실시예에 따른 수신기는, 유저 데이터 데이터베이스 (User Data DB)를 더 포함할 수 있다. 유저 데이터 데이터베이스는 처리된 유저 데이터를 저장한다.
도 123 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 를 도시한 도면이다.
프리젠테이션 선호도란, 클로즈드 캡션(closed caption), 오디오(audio), 접근성(Accessibility) 및/또는 수화(Sign Language) 등에 있어, 방송 시청시 해당 클로즈드 캡션등이 보여질 것인지에 관한 선호도를 의미할 수 있다.
유저의 프리젠테이션 선호도가, 개인화된 정보로서 수신기에 저장되면, 방송 시청시 그 유저에 맞춘 서비스 제공이 가능하다. 유저는 관련 정보를 매번 세팅해줄 필요없이, 자신의 선호도(preference)에 맞춰진 서비스를 제공받을 수 있다. 실시예에 따라, 유저 프리젠테이션 선호도는 방송 시청 전, 또는 방송 시청 중에 프리-레지스터드(pre-registered) 될 수 있다.
또한, 설정된 프리젠테이션 선호도는 수신기외에 컴패니언 디바이스들에도 공유되어 활용될 수 있다. 반대로, 컴패니언 디바이스들에서 설정된 프리젠테이션 선호도가 수신기로 공유될 수도 있다.
본 발명에서는 프리젠테이션 선호도 중, 클로즈드 캡션, 오디오, 접근성&수화 프리젠테이션에 대해서 설명한다. 그러나, 프리젠테이션 선호도에 관계된 서비스들은 다양할 수 있으며, 본 발명은 상기 세 항목의 프리젠테이션 선호도에 한정되지 아니한다.
도 124 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
전술한 클로즈드 캡션의 선호도와 관련하여, 사용자는 클로즈드 캡션의 사용유무, 클로즈드 캡션의 언어 선호, 폰트 선호, 폰트 사이즈 선호 등을 설정할 수 있다. 이러한 정보들들은, 클로즈드 캡션을 시그널링하는 과정에서 전달되는 디스크립터(descriptor) 또는 테이블을 참조할 수 있다. 클로즈드 캡션과 관련된 정보가 전달되는 채널, 디스크립터 또는 테이블들은 여러 형태로 표현될 수 있으며, 본 발명은 어느 한 형태에 한정되지 아니한다.
클로즈드 캡션과 관련된 정보가 전달되는 디스크립터를, caption_service_descriptor 라고 칭하기로 한다. 이 디스크립터는 클로즈드 캡션과 관련된 기본적인 정보를 전달하는 디스크립터일 수 있다. 이 디스크립터는 종래기술에서 사용되는, 클로즈드 캡션 관련 디스크립터의 정보들을 포함하며, 이에 더하여 본 발명에서 제안하는 필드/정보 등을 더 포함할 수 있다. 즉, 기존 클로즈드 캡션 관련 디스크립터의 변형일 수 있다.
이 caption_service_descriptor 는 클로즈드 캡션이 제공되는 방송이 있을 경우, PMT/EIT를 통해서 전달될 수 있다. caption_service_descriptor 의 정보들을 이용하여, caption_service_descriptor 는 미리 정의된 PDI Question 으로 변환될 수 있다. 수신기는 caption_service_descriptor 를 수신하면, 이를 미리 정의된 PDI Question 으로 변환하여, 답변을 받을 수 있다.
본 실시예의 시퀀스는, 수신기가 PMT 또는 EIT 를 통해 caption_service_descriptor 를 수신하는 상황을 상정하였다.
caption_service_descriptor 는 PMT 또는 EIT 에 포함될 수 있다(ts124010). 전술한 바와 같이 caption_service_descriptor 는 PMT 또는 EIT 를 통해 전달될 수 있다. caption_service_descriptor 가 수신기에 수신되면(t124020), 수신기 내/외부의 시그널링 파서는 caption_service_descriptor 를 수신기 내/외부의 PDI 엔진에 전달할 수 있다(ts124030).
PDI 엔진은 caption_service_descriptor 의 정보에 따라, PDI Question 을 자동적으로 생성할 수 있다(ts124040). 이 과정은 caption_service_descriptor 를 PDI Question 으로 자동적으로 변환한다고 표현될 수도 있다. PDI 엔진은, ID 를 이용하여 해당 질문에 대한 답변이 기존에 존재하는지 여부를 확인하고, 존재하지 않는 경우 완성된 PDI Question 을 UI 에 보내어(ts124050), 유저로부터 답변을 받을 수 있다.
유저는 UI 를 통해 해당 PDI Question 에 대한 답변을 설정하고(ts124060), UI 는 이 답변을 PDI 엔진으로 리턴할 수 있다(ts124070). PDI 엔진은 해당 내용을 PDI 스토어에 추가 또는 업데이트할 수 있다(ts124080).
실시예에 따라, 기존에 질문에 대한 답변이 있는 경우라 할지라도, 유저의 선호도의 변화가 있을 수 있는 바, UI 를 통해 해당 질문에 대한 답변을 다시금 받을 수도 있다. 이 경우 새로운 답변은 기존 답변과 답변 시각 등의 측면에서 비교되고, 새로운 답변이 기존 답변을 대체할 수도 있다.
도 125 는 본 발명의 다른 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
본 실시예의 시퀀스는, 수신기가 PMT 또는 EIT 를 시그널링 서버로 요청하고, PMT 혹은 EIT 통해 caption_service_descriptor 를 수신하는 상황을 상정하였다.
수신기는 시그널링 서버에 PMT 또는 EIT 를 요청할 수 있다(ts125010). 시그널링 서버는 요청된 PMT 또는 EIT 를 수신기에 전달할 수 있다(ts125020). 수신기는 PMT, EIT 내의 caption_service_descriptor 를 PDI 엔진으로 전달할 수 있다(ts125030).
이 후, PDI 엔진이 PDI Question 을 생성하고, UI 를 통해 질문에 대한 답변을 받으며, 답변을 PDI 스토어에 추가/업데이트하는 동작(ts125040 - ts125080) 은 전술한 바와 같을 수 있다.
도 126 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, caption_service_descriptor 의 확장된 필드들을 도시한 도면이다.
본 발명의 caption_service_descriptor 는 전술한 바와 같이, 기존의 caption_service_descriptor 의 확장 내지 변경일 수 있다.
본 발명의 caption_service_descriptor 는 Font 필드, Font Size 필드, Alignment 필드, Print Direction 필드, 및/또는 Scroll Direction 필드 등을 더 포함할 수 있다(t126010).
Font 필드는 클로즈드 캡션의 글자체를 나타낼 수 있다. 캡션은, Font 필드가 0 일 경우 기본값, 1 일 경우 Monospaced with serifs, 2일 경우 Proportionally spaced with serifs, 3일 경우 Monospaced without serifs, 4일 경우 Proportionally spaced without serifs, 5일 경우 Casual font type, 6일 경우 Cursive font type, 7일 경우 Small capitals 의 글자체를 가질 수 있다. Font 필드는 3 비트의 필드로서, uimsbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
Font Size 필드는 클로즈드 캡션의 글자 사이즈를 나타낼 수 있다. 캡션은, Font Size 필드가 0 일 경우 기본값, 1 일 경우 Standard, 2 일 경우 Small, 3일 경우 Large, 의 글자 사이즈를 가질 수 있다. Font Size 필드는 2 비트의 필드로서, uimsbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
Alignment 필드는 클로즈드 캡션의 정렬 방법을 나타낼 수 있다. 캡션은, Alignment 필드가 0 일 경우 기본값, 1 일 경우 Left, 2일 경우 Right, 3일 경우 Center, 4일 경우 Full, 에 정렬될 수 있다. Alignment 필드가 5-7 일 경우는 향후 사용을 위해 남겨둘 수 있다. Alignment 필드는 3 비트의 필드로서, uimsbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
Print Direction 필드는 클로즈드 캡션의 프린트되는 방향을 나타낼 수 있다. 캡션은, Print Direction 필드가 0 일 경우 기본값, 1 일 경우 Left to Right, 2일 경우 Right to Left, 3일 경우 Top to Bottom, 4일 경우 Bottom to Top, 의 방향으로 프린트될 수 있다. Print Direction 필드가 5-7 일 경우는 향후 사용을 위해 남겨둘 수 있다. Print Direction 필드는 3 비트의 필드로서, uimsbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
Scroll Direction 필드는 클로즈드 캡션의 스크롤되는 방향을 나타낼 수 있다. 캡션은, Scroll Direction 필드가 0 일 경우 기본값, 1 일 경우 Left to Right, 2일 경우 Right to Left, 3일 경우 Top to Bottom, 4일 경우 Bottom to Top, 의 방향으로 스크롤될 수 있다. Scroll Direction 필드가 5-7 일 경우는 향후 사용을 위해 남겨둘 수 있다. Scroll Direction 필드는 3 비트의 필드로서, uimsbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
전술한 바와 같이, 수신기는 caption_service_descriptor 의 각 필드를 참조하여, 프리-레지스터드 PDI Question 을 생성/변환할 수 있다.
실시예에 따라, 클로즈드 캡션은 비디오 스트림의 user_data 영역으로 전달될 수 있다. 클로즈드 캡션이 user_data 영역으로 전달되었음에도 불구하고, PMT 또는 EIT 에 caption_service_descriptor 가 전달되지 않을 수 있다. 이 경우, 수신기는 user_data 영역의 클로즈드 캡션 데이터를 직접 파싱하여, 프리 레지스터드 PDI Question 으로 변환하여 사용자에게 보여줄 수 있다.
또한, PMT 또는 EIT 를 통해 전달되는 caption_service_descriptor 에 전술한 추가 필드들이 전달되지 않을 수도 있다. 이 경우, caption_service_descriptor 에는 클로즈드 캡션 사용유무, 캡션 언어, 이지 리더 모드 등에 관련된 필드들만이 있을 수 있다. 수신기는 클로즈드 캡션 사용유무, 캡션 언어, 이지 리더 모드 등에 관한 프리 레지스터드 PDI Question 을 생성/변환하여 사용자에게 보여줄 수 있다. 수신기는, 나머지 프리 레지스터드 PDI Question 들은, 비디오 스트림의 user_data 영역으로 전달되는 클로즈드 캡션을 파싱하는 과정에서 사용자에게 보여줄 수 있다.
도 127 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
디스크립터가 caption_service_descriptor 일 경우, 해당 디스크립터의 descriptor_tag 필드가 0x86 의 값을 가질 수 있다. 해당 디스크립터가 caption_service_descriptor 일 경우, 수신기는 클로즈드 캡션이 있을 경우 그 클로즈드 캡션을 볼 것인지에 대한 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션 사용여부를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Are you using Closed Caption?" 과 같을 수 있고, 사용자는 그에 대해 "Yes" 또는 "No" 의 답변을 할 수 있다.
도 128 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 language 필드를 참조하여, 사용자에게 클로즈드 캡션의 선호 언어를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션에 사용될 언어를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which Closed Caption language do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "English", "French" , "Italian" 또는 "Etc" 의 답변을 할 수 있다. 사용자가 답변하여 설정된 선호 언어의 클로즈드 캡션이 제공되지 않는 경우라면, 수신기는 기본값(default) 로 제공되는 언어를 이용하여 클로즈드 캡션을 제공할 수 있다.
도 129 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 폰트에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 font 필드를 참조하여, 사용자에게 클로즈드 캡션의 선호 폰트를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션에 사용될 폰트를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which font of Closed Caption do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "Default", "Monospaced with serifs" , "Proportionally spaced with serifs" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 폰트의 클로즈드 캡션이 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 로 제공되는 폰트를 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 폰트로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 130 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 글자 크기에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 font_size 필드를 참조하여, 사용자에게 클로즈드 캡션의 선호 글자 크기를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션에 사용될 글자 크기를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which font size of Closed Caption do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "Default", "Small" , "Normal" 또는 "Big" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 글자 크기의 클로즈드 캡션이 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 로 제공되는 글자 크기를 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 글자 크기로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 131 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 정렬에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 alignment 필드를 참조하여, 사용자에게 클로즈드 캡션의 선호 정렬을 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션의 정렬을 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which alignment of Closed Caption do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "Default", "Left" , "Right" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 정렬 방식의 클로즈드 캡션이 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 로 제공되는 정렬 방식을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 정렬 방식으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 132 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 프린트되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 print_direction 필드를 참조하여, 사용자에게 클로즈드 캡션의 선호 프린트 방향을 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션의 프린트 방향을 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which print direction of Closed Caption do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "Default", "Left to Right" , "Right to Left" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 프린트 방향의 클로즈드 캡션이 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 으로 제공되는 프린트 방향을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 프린트 방향으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 133 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 스크롤되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 scroll_direction 필드를 참조하여, 사용자에게 클로즈드 캡션의 선호 스크롤 방향을 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션의 스크롤 방향을 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which scroll direction of Closed Caption do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "Default", "Left to Right" , "Right to Left" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 스크롤 방향의 클로즈드 캡션이 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 으로 제공되는 스크롤 방향을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 스크롤 방향으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 134 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 이지 리더(easy reader) 모드에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 caption_service_descriptor의 easy_reader 필드를 참조하여, 사용자에게 클로즈드 캡션의 이지 리더(easy reader) 모드를 사용할 것인지를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 클로즈드 캡션의 이지 리더 모드 사용 여부를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Are you using Easy Reader Mode?" 과 같을 수 있고, 사용자는 그에 대해 "Yes", "No" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 이지 리더 형태의 클로즈드 캡션이 제공되지 않는 경우라면, 다음과 같은 실시예에 따라 수신기가 동작할 수 있다. 첫번째 실시예로, 수신기가 이지 리더의 형태로 클로즈드 캡션을 강제로 변환하여 표시할 수 있다. 두번째 실시예로, 수신기는 이지 리더 형태의 클로즈드 캡션을 제공하는 별도의 서버를 통해서 캡션을 수신하여 사용자에게 제공할 수 있다. 세번째 실시예로, 수신기는 제 3자(third party) 의 서버에 접근하여 다양한 버전의 클로즈드 캡션을 전달받을 수 있다. 이지 리더 형태의 클로즈드 캡션은 인물의 음성 뿐 아니라, 나레이션, 효과음과 같은 소리도 제공할 수 있다. 이러한 다양항 클로즈드 캡션은, 방송국에서 제공하지 않는 경우, 전술한 제 3자의 서버에서 전달받아, 수신기가 이지 리더의 형태로 변환, 표시할 수 있다.
도 135 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
전술한 오디오의 선호도와 관련하여, 사용자는 오디오 트랙의 언어 선호, 시청각 장애인을 위한 모드의 사용여부 등을 설정할 수 있다. 이러한 정보들들은, 오디오를 시그널링하는 과정에서 전달되는 디스크립터(descriptor) 또는 테이블을 참조할 수 있다. 클로즈드 캡션과 관련된 정보가 전달되는 채널, 디스크립터 또는 테이블들은 여러 형태로 표현될 수 있으며, 본 발명은 어느 한 형태에 한정되지 아니한다.
오디오와 관련된 정보가 전달되는 디스크립터를, AC-3_audio_stream_descriptor 라고 칭하기로 한다. 이 디스크립터는 오디오와 관련된 기본적인 정보를 전달하는 디스크립터일 수 있다. 이 디스크립터는 종래기술에서 사용되는, 오디오 관련 디스크립터의 정보들을 포함하며, 이에 더하여 본 발명에서 제안하는 필드/정보 등을 더 포함할 수 있다. 즉, 기존 오디오 관련 디스크립터의 변형일 수 있다.
이 AC-3_audio_stream_descriptor 는 PMT/EIT를 통해서 전달될 수 있다. 이 디스크립터의 정보들을 이용하여, AC-3_audio_stream_descriptor 는 미리 정의된 PDI Question 으로 변환될 수 있다. 수신기는 AC-3_audio_stream_descriptor 를 수신하면, 이를 미리 정의된 PDI Question 으로 변환하여, 답변을 받을 수 있다.
본 실시예의 시퀀스는, 수신기가 PMT 또는 EIT 를 통해 AC-3_audio_stream_descriptor 를 수신하는 상황을 상정하였다.
AC-3_audio_stream_descriptor 는 PMT 또는 EIT 에 포함될 수 있다(ts135010). 전술한 바와 같이 AC-3_audio_stream_descriptor 는 PMT 또는 EIT 를 통해 전달될 수 있다. AC-3_audio_stream_descriptor 가 수신기에 수신되면(t135020), 수신기 내/외부의 시그널링 파서는 AC-3_audio_stream_descriptor 를 수신기 내/외부의 PDI 엔진에 전달할 수 있다(ts135030).
이 후, PDI 엔진이 AC-3_audio_stream_descriptor 를 이용하여 PDI Question 을 생성하고, UI 를 통해 질문에 대한 답변을 받으며, 답변을 PDI 스토어에 추가/업데이트하는 동작(ts135040 - ts135080) 은 전술한 바와 같을 수 있다.
실시예에 따라, 기존에 질문에 대한 답변이 있는 경우라 할지라도, 유저의 선호도의 변화가 있을 수 있는 바, UI 를 통해 해당 질문에 대한 답변을 다시금 받을 수도 있다. 이 경우 새로운 답변은 기존 답변과 답변 시각 등의 측면에서 비교되고, 새로운 답변이 기존 답변을 대체할 수도 있다.
도 136 는 본 발명의 다른 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
본 실시예의 시퀀스는, 수신기가 PMT 또는 EIT 를 시그널링 서버로 요청하고, PMT 혹은 EIT 통해 AC-3_audio_stream_descriptor 를 수신하는 상황을 상정하였다.
수신기는 시그널링 서버에 PMT 또는 EIT 를 요청할 수 있다(ts136010). 시그널링 서버는 요청된 PMT 또는 EIT 를 수신기에 전달할 수 있다(ts136020). 수신기는 PMT, EIT 내의 AC-3_audio_stream_descriptor 를 PDI 엔진으로 전달할 수 있다(ts136030).
이 후, PDI 엔진이 AC-3_audio_stream_descriptor 를 이용하여 PDI Question 을 생성하고, UI 를 통해 질문에 대한 답변을 받으며, 답변을 PDI 스토어에 추가/업데이트하는 동작(ts136040 - ts136080) 은 전술한 바와 같을 수 있다.
도 137 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, AC-3_audio_stream_descriptor 의 확장된 필드들을 도시한 도면이다.
본 발명의 AC-3_audio_stream_descriptor 전술한 바와 같이, 기존의 오디오 관련 디스크립터의 확장 내지 변경일 수 있다.
본 발명의 AC-3_audio_stream_descriptor 는 langcod 필드, 및/또는 bsmod 필드 등을 더 포함할 수 있다.
langcod 필드는 오디오의 언어 코드를 나타낼 수 있다. 오디오는 langcod 필드의 값에 따라 각기 다른 언어로 표현될 수 있다. langcod 필드는 8 비트의 필드로서, bslbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
bsmod 필드는 시청각 장애인을 위한 모드의 사용여부를 나타낼 수 있다. 예를 들어, bsmod 필드의 값이 000일 경우 complete main 오디오 서비스가 제공될 수 있다. bsmod 필드의 값이 001 일 경우 music and effects 오디오 서비스가 제공될 수 있다. bsmod 필드의 값이 010일 경우 visually impaired 오디오 서비스가 제공될 수 있다. bsmod 필드의 값이 011일 경우 hearing impaired 오디오 서비스가 제공될 수 있다. bsmod 필드의 값이 100일 경우 dialogue 오디오 서비스가 제공될 수 있다. bsmod 필드의 값이 101일 경우 commentary 오디오 서비스가 제공될 수 있다. bsmod 필드의 값이 110일 경우 emergency 오디오 서비스가 제공될 수 있다. bsmod 필드 값이 111 인 경우는 향후 사용을 위해 남겨두거나, 다른 오디오 서비스 제공의 표시에 할당될 수 있다. bsmod 필드는 3 비트의 필드로서, bslbf 포맷을 가지는 것을 일 실시예로 할 수 있다.
전술한 바와 같이, 수신기는 AC-3_audio_stream_descriptor의 각 필드를 참조하여, 프리-레지스터드 PDI Question 을 생성/변환할 수 있다.
실시예에 따라, 오디오는 오디오 스트림을 통해 전달될 수 있다. 이 때, PMT 또는 EIT 로 AC-3_audio_stream_descriptor 가 전달되지 않을 수 있다. 이 경우, 수신기는 오디오 스트림의 오디오를 직접 파싱하여, 프리 레지스터드 PDI Question 으로 변환하여 사용자에게 보여줄 수 있다.
또한, PMT 또는 EIT 를 통해 전달되는 AC-3_audio_stream_descriptor 에 전술한 추가 필드들이 전달되지 않을 수도 있다. 이 경우, 수신기는 프리 레지스터드 PDI Question 들을, 오디오 스트림의 오디오를 파싱하는 과정에서 사용자에게 보여줄 수 있다.
도 138 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 AC-3_audio_stream_descriptor의 langcod 필드를 참조하여, 사용자에게 오디오의 선호 언어를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 오디오에 사용될 언어를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which audio language do you prefer?" 과 같을 수 있고, 사용자는 그에 대해 "English", "French" , "Italian" 또는 "Etc" 의 답변을 할 수 있다. 사용자가 답변하여 설정된 선호 언어의 오디오가 제공되지 않는 경우라면, 수신기는 기본값(default) 로 제공되는 언어를 이용하여 클로즈드 캡션을 제공할 수 있다.
도 139 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 청각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 AC-3_audio_stream_descriptor의 bsmod 필드를 참조하여, 사용자에게 오디오의 청각 장애인을 위한 모드 사용여부를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 여기서 청각 장애인이란 청각이 완전히 소실되지 않고, 충분히 제 기능을 하지 못하는 상태의 사용자를 의미할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 오디오의 청각 장애인을 위한 모드 사용 여부를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Are you using audio hearing impaired mode?" 과 같을 수 있고, 사용자는 그에 대해 "Yes", "No" 의 답변을 할 수 있다. 오디오의 청각 장애인을 위한 모드가 제공되지 않는 경우, 수신기는 기본적인 모드로 오디오를 제공할 수 있다.
도 140 은 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 시각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 AC-3_audio_stream_descriptor의 bsmod 필드를 참조하여, 사용자에게 오디오의 시각 장애인을 위한 모드 사용여부를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 여기서 시각 장애인이란 시각이 완전히 소실되지 않고, 충분히 제 기능을 하지 못하는 상태의 사용자를 의미할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 오디오의 시각 장애인을 위한 모드 사용 여부를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Are you using audio visually impaired mode?" 과 같을 수 있고, 사용자는 그에 대해 "Yes", "No" 의 답변을 할 수 있다. 오디오의 시각 장애인을 위한 모드가 제공되지 않는 경우, 수신기는 기본적인 모드로 오디오를 제공할 수 있다.
도 141 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
전술한 접근성&수화 프리젠테이션의 선호도와 관련하여, 사용자는 청각 장애인을 위한 접근성 서비스 또는 수화 서비스에 대한 사용유무 등을 설정할 수 있다. 여기서의 청각 장애인이란 전술한 청각 장애인과 달리, 청각의 손상이 심해 수화 서비스를 이용해야 하는 사용자를 의미할 수 있다. 이 때, 해당 서비스의 사용 유무, 수화의 선호도(ASL, KSL 등..) 을 설정할 수 있다. 이러한 정보들들은, 접근성&수화 프리젠테이션 관련 시그널링하는 과정에서 전달되는 디스크립터(descriptor) 또는 테이블을 참조할 수 있다. 접근성&수화 프리젠테이션과 관련된 정보가 전달되는 채널, 디스크립터 또는 테이블들은 여러 형태로 표현될 수 있으며, 본 발명은 어느 한 형태에 한정되지 아니한다.
접근성&수화 프리젠테이션과 관련된 정보가 전달되는 디스크립터를, sign_language_descriptor 라고 칭하기로 한다. 이 디스크립터는 접근성&수화 프리젠테이션과 관련된 기본적인 정보를 전달하는 디스크립터일 수 있다. 이 디스크립터는 종래기술에서 사용되는, 접근성&수화 프리젠테이션 관련 디스크립터의 정보들을 포함하며, 이에 더하여 본 발명에서 제안하는 필드/정보 등을 더 포함할 수 있다. 즉, 기존 접근성&수화 프리젠테이션 관련 디스크립터의 변형일 수 있다.
이 sign_language_descriptor 는 수화 서비스 등이 제공되는 방송이 있을 경우, PMT/EIT를 통해서 전달될 수 있다. sign_language_descriptor 의 정보들을 이용하여, sign_language_descriptor 는 미리 정의된 PDI Question 으로 변환될 수 있다. 수신기는 sign_language_descriptor 를 수신하면, 이를 미리 정의된 PDI Question 으로 변환하여, 답변을 받을 수 있다.
본 실시예의 시퀀스는, 수신기가 PMT 또는 EIT 를 통해 sign_language_descriptor 를 수신하는 상황을 상정하였다.
본 시퀀스에서, 디스크립터가 PMT/EIT 를 통해 전달되는 과정 및 시그널링 파서가 디스크립터를 PDI 엔진으로 전달하는 과정(ts141010 - ts141030) 은 전술한 과정과 동일할 수 있다. 단, 이 경우에는 디스크립터가 sign_language_descriptor 인 점이 다를 수 있다.
이 후, PDI 엔진이 PDI Question 을 생성하고, UI 를 통해 질문에 대한 답변을 받으며, 답변을 PDI 스토어에 추가/업데이트하는 동작(ts141040 - ts141080) 은 전술한 바와 같을 수 있다.
도 142 은 본 발명의 다른 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
본 실시예의 시퀀스는, 수신기가 PMT 또는 EIT 를 시그널링 서버로 요청하고, PMT 혹은 EIT 통해 sign_language_descriptor 를 수신하는 상황을 상정하였다.
본 시퀀스에서, 수신기가 시그널링 서버에 PMT 또는 EIT 를 요청하고, PMT 또는 EIT 를 전달받아, sign_language_descriptor 를 PDI 엔진에 전달하는 과정(ts142010 - ts142030) 은 전술한 과정과 동일할 수 있다. 단, 이 경우에는 디스크립터가 sign_language_descriptor 인 점이 다를 수 있다.
이 후, PDI 엔진이 PDI Question 을 생성하고, UI 를 통해 질문에 대한 답변을 받으며, 답변을 PDI 스토어에 추가/업데이트하는 동작(ts142040 - ts142080) 은 전술한 바와 같을 수 있다.
도 143 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)에 있어서, sign_language_descriptor 를 도시한 도면이다.
여기서, descriptor tag 필드는 8 비트의 필드로서, 본 디스크립터가 수화 서비스를 제공하기 위한 디스크립터임을 나타내는 필드일 수 있다. descriptor length 필드는 본 sign_language_descriptor 의 길이를 나타내는 필드로서 8비트의 길이를 가질 수 있다.
number of services 필드는 5 비트의 필드로서, 여러 종류의 수화를 제공받기 위한 서비스 넘버를 나타낼 수 있다. language 필드는 해당 수화의 언어(e.g., ASL(American Sign Language, KSL(Korean Sign Language), etc.,) 를 나타내는 필드 일 수 있다.
resolution 필드는 수화 서비스의 해상도를 나타내고, codec 필드는 수화 서비스의 코덱을 나타낼 수 있다. location 필드는 수화 서비스를 화면에 표시하기 위한 위치를 나타내며, 자동(Auto selection), 좌하단(Lower left), 우하단(Lower right), 좌상단(Upper left), 우상단(Upper right 등의 값을 가질 수 있다.
전술한 바와 같이, 수신기는 sign_language_descriptor 의 각 필드를 참조하여, 프리-레지스터드 PDI Question 을 생성/변환할 수 있다.
실시예에 따라, sign_language_descriptor가 수신기로 전달되지 않는 경우, 수신기는 수신된 수화 서비스 관련 데이터를 직접 파싱하여, 프리 레지스터드 PDI Question 으로 변환하여 사용자에게 보여줄 수 있다.
도 144 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 접근성&수화 프리젠테이션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 sign_language_descriptor 의 descriptor_tag 필드를 참조하여, 사용자에게 접근성&수화 프리젠테이션 사용 여부를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 접근성&수화 프리젠테이션 사용 여부를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Are you using sign language mode?" 과 같을 수 있고, 사용자는 그에 대해 "Yes", "No" 등의 답변을 할 수 있다.
도 145 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화 언어의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 sign_language_descriptor 의 language 필드를 참조하여, 사용자에게 수화 서비스의 선호 언어를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 수화 서비스에 사용될 언어를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which sign language are you using?" 과 같을 수 있고, 사용자는 그에 대해 "ASL(American Sign Language)", "LSF (French Sign Language)" , "LSM (Mexican Sign Language)" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 수화 언어가 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 로 제공되는 수화 언어를 이용하여 수화 서비스를 제공할 수 있다. 또한 실시예에 따라, 수신기는 다양한 버전의 수화 언어를 제공하는 제 3자(third party) 의 서버에 접근하여 해당 수화 언어 서비스를 전달받아 화면에 표시할 수도 있다.
도 146 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화의 위치의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
수신기는 sign_language_descriptor 의 location 필드를 참조하여, 사용자에게 수화가 화면 상에 나타나는 선호 위치를 설정 할 수 있는 프리-레지스터드 PDI Question 을 생성할 수 있다. 수신기는 생성된 PDI Question 을 사용자에게 보여주고, 그에 대한 답변을 저장할 수 있다. 사용자는 해당 PDI Question 을 통해 수화가 표시될 위치를 설정할 수 있다.
본 실시예에서, QSA 형태의 PDI Question 이 생성되어 사용자에게 보여질 수 있다. 질문의 텍스트는 "Which location of sign language do you prefer to present?" 과 같을 수 있고, 사용자는 그에 대해 "Lower Left", "Lower Right" , "Upper Left" 등의 답변을 할 수 있다.
사용자가 답변하여 설정된 선호 수화 위치가 제공되지 않는 경우라면, 실시예에 따라 수신기는 기본값(default) 로 제공되는 수화 위치에 수화 서비스를 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 위치에 강제로 수화 서비스를 표시할 수도 있다.
도 147 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 에 있어서, 답변의 업데이트를 위한 메뉴 화면을 도시한 도면이다.
사용자가 프리젠테이션 선호도에 관련된 프리 레지스터드 PDI Question 에 답변을 하게 되면, 그 이후부터는 그 프리젠테이션 선호도에 관련된 서비스 제공시 사용자에게 동일 Question 이 노출되지 않을 수 있다. 이 경우, 그 프리젠테이션 선호도에 관련된 서비스 제공시 기 저장된 답변이 활용되어, 서비스 제공 유무 등이 제어될 수 있다.
그러나, 이 경우에는 한번 저장된 답변이 변경될 수 없으므로, 사용자의 선호도가 바뀌는 경우에는 답변을 업데이트할 방안이 필요할 수 있다. 답변 업데이트를 위하여 만료 필드(Exprie field)를 사용하거나, 뷰잉 프리퍼런스 메뉴(Viewing Preference Menu) 가 제공될 수 있다. 실시예에 따라 업데이트에 다른 방법이 사용될 수도 있다.
먼저, 만료 필드에 대해 설명한다.
PDI Question 들은 만료 필드(Exprie field)를 가질 수 있다. 프리젠테이션 선호도와 관련된 PDI Question 들을 사용자에 보여줄 때, 만료 필드를 적절히 설정할 수 있다. 만료 필드에 설정된 시간이 지나고나면, 수신기는 사용자에게 해당 PDI Question 을 다시 보여줄 수 있다. 사용자는 다시 보여진 질문에 대해 대답을 하여, 답변을 업데이트할 수 있다.
PDI Question 에 대한 답변은, 일정 시간이 지나면 자동적으로 소멸될 수 있다. 그 이후 수신기가 관련 서비스를 전달받으면, PDI 스토어에 저장된 질문 및 답변이 있는 지 확인한 후, 프리 레지스터드 PDI Question 의 형태로 다시 사용자에게 노출시킬 수 있다.
뷰잉 프리퍼런스 메뉴에 대해 설명한다.
수신기는 뷰잉 프리퍼런스 메뉴를 제공할 수 있다. 뷰잉 프리퍼런스 메뉴는 사용자가 확인/변경할 수 있는 네이티브(Native) 형태의 메뉴일 수 있다. 사용자는 언제든지 원할 때, 해당 메뉴에 접근하여 프리젠테이션 선호도를 변경할 수 있다.
뷰잉 프리퍼런스 메뉴가 활성화되면, 수신기는 PDI 스토어에서 프리젠테이션 선호도와 관련된 질문들의 답변을 확인하고, 저장된 답변을 UI 를 통해 사용자에 보여줄 수 있다(t147010). 사용자는 뷰잉 프리퍼런스 메뉴를 통해, 프리젠테이션 선호도의 값을 변경할 수 있다. 변경된 값은 해당 프리 레지스터드 PDI Question 의 ID 를 참조하여 PDI 스토어에 저장되어, 기 저장된 답변을 업데이트 시킬 수 있다.
도 148 은 본 발명의 또 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
기존의 PDI 시스템은, 한명의 사용자에게 개인화된 서비스를 제공하는 형태였기 때문에, 복수의 사용자들간의 선호도 및 Q&A 를 관리할 수 없었다. 본 발명에서는 PDI 유저 데이터를 복수의 유저간에 별도로 설정하고, 유저에 따라 개인화된 서비스를 제공하는 방법을 제안한다.
본 구조도에서, 컨텐츠 프로바이더 또는 브로드캐스터, PDI 설문지, PDI 엔진, PDI 스토어, PDI 클라우드 스토어, 컴패니언 디바이스 모듈, 컴패니언 디바이스, 필터링 엔진, 컨텐츠/서비스 스토어 는 전술한 동명의 모듈과 같을 수 있다.
본 구조도에서, 수신기(t148020)는 전술한 구조도와 달리 유저 매니지먼트 엔진(User Management Engine)(t148010) 을 더 포함할 수 있다.
유저 매니지먼트 엔진(t148010)은 복수의 사용자간에 PDI 유저 데이터를 관리하는 역할을 할 수 있다. 복수의 사용자마다 선호도가 다를 수 있으므로, 유저 매니지먼트 엔진(t148010)은 사용자를 구분하고, 각 사용자에 맞게 답변 저장 및/또는 필터된 컨텐츠 및 서비스를 전달할 수 있다. 실시예에 따라 유저 매니지먼트 엔진(t148010) 의 동작은 PDI 엔진 또는 별도의 모듈에서 처리될 수도 있다.
도 149 는 본 발명의 일 실시예에 따른, 유저 ID 필드를 더 포함하는 PDIUserData 를 도시한 도면이다.
수신기가 복수의 사용자를 구분하고, 각각의 사용자의 선호도에 맞게 컨텐츠/서비스를 제공하기 위해서, 유저 매니지먼트 엔진은 복수의 사용자를 식별할 수 있어야 한다. 유저 매니지먼트 엔진이 복수의 사용자를 식별하는 방안은 다음과 같을 수 있다. 복수의 사용자를 식별하는 방안은 실시예에 따라 다양하게 선택될 수 있다.
먼저, 로그인(log in) 방식은, 사용자에게 PDI Question 을 보여주기 전에 사용자가 로그인하는 방식일 수 있다. 유저 매니지먼트 엔진은 UI 를 통해 로그인 창을 사용자에게 노출할 수 있다. 로그인 창이 노출되는 시점은 실시예에 따라 수신기가 켜진 직 후, 또는 PDI 설문지 를 수신한 시점일 수 있다.
사용자는 로그인 창이 노출되면 자신의 유저 ID 를 통해 로그인할 수 있다. 유저 ID 가 존재하지 않는 경우, 사용자는 자신의 유저 ID 를 생성할 수 있으며, 유저 ID 생성 및 관리는 유저 매니지먼트 모듈에서 수행될 수 있다. 실시예에 따라 로그인창은 컴패니언 디바이스에서 노출될 수도 있다. 이 경우, 사용자는 컴패니언 디바이스를 통해 로그인할 수도 있다.
다음으로, 자동 식별(Automatic Identification) 방식은, 사용자가 유저 ID 를 직접 입력하는 것이 아니라, 수신기 내 유저 매니지먼트 엔진이 자동으로 사용자를 식별하는 방식일 수 있다. 사용자를 자동으로 식별하기 위하여 안면 인식(Face Recognition) 또는 목소리 인식(Voice Recognition) 방식이 있을 수 있다.
사용자가 자동 식별 방식에 따라 식별이 되면, 해당 사용자의 유저 ID 로 자동으로 로그인 될 수 있다. 사용자가 처음 인식된 경우라면, 유저 매니지먼트 엔진은 해당 유저의 유저 ID 를 생성하여 관리할 수 있다.
사용자가 자신의 ID 로 로그인된 상태에서는, 자신만의 PDI Q&A 를 작성할 수 있다. 이를 위해서, 전술한 PDI 유저 데이터(PDIUserData) 는 도시된 바와 같이 변형될 수 있다.
먼저, PDIUserData 는 @user_id 필드를 추가로 가질 수 있다(t149010). @user_id 필드는 string 타입의 필드로서, 유저 ID 를 나타내는 필드일 수 있다. 또한, 각각의 QxA, 즉 PDI Question 들 또한 @user_id 필드를 추가로 가질 수 있다(t149020). QxAType 에는 @user_id 필드가 추가된다. 도시된 QxA 는 QIA 이지만, 다른 형태의 Question 에도 모두 @user_id 필드가 추가될 수 있다.
도 150 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 PDI Question 에 대한 답변을 얻는 시퀀스 다이어그램을 도시한 도면이다.
컨텐츠 프로바이더 또는 브로드캐스터는 PDI 테이블을 수신기로 전달할 수 있다(ts150010). 이 때, PDI 테이블은 브로드캐스트 또는 브로드밴드 채널을 통해 전달될 수 있다. 수신기는 전달된 PDI 테이블을 PDI 엔진에 전달할 수 있다(ts150020). PDI 엔진은 유저 매니지먼트 엔진에 PDI 테이블이 수신되었다는 것을 알릴 수 있다(ts150030).
유저 매니지먼트 엔진은 유저가 로그인되어 있는지, 로그인 상태를 체크할 수 있다(ts150040). 로그인되어 있지 않는 상태일 경우, 유저 매니지먼트 엔진은 UI 를 통해 로그인 UI 를 사용자에게 노출시킬 수 있다(ts150050). 사용자는 로그인 UI 를 통해 로그인 프로세스를 수행할 수 있다(ts1500960). 또는 실시예에 따라 수신기가 안면인식/목소리인식 등을 통해, 자동으로 유저를 인식할 수도 있다. UI 는 입력된 유저 ID 정보를 유저 매니지먼트 엔진으로 전달할 수 있다(ts150070).
만일, 유저가 이미 로그인되어 있는 상태일 경우, 유저 매니지먼트 엔진은 로그인 프로세스를 생략할 수 있다. 이 경우, 전술한 ts150040 - ts150070 단계는 생략될 수 있다. 유저 매니지먼트 엔진은 유저가 로그인되어 있다는 사실을 지속적으로 기억하고 있을 수 있다.
유저 매니지먼트 엔진은 유저 ID 가 유효한 것인지를 확인할 수 있다(ts150080). 만약 전달받은 ID 가 등록되어 있지않은 ID 일 경우에는, 별도의 등록(registration) 과정이 수행될 수 있다. 이 등록과정은 UI 를 통해, 유저의 정보를 입력받아, 유저 ID 를 생성하는 과정일 수 있다.
전달받은 ID 가 유효한 것이라면, 유저 매니지먼트 모듈은 이 ID 를 PDI 엔진으로 전달할 수 있다(ts150090). PDI 엔진은 전달받은 유저 ID 를 PDI 테이블에 저장할 수 있다(ts150100). 이 때, 전술한 PDI 테이블 내의 @user_id 필드가 사용될 수 있다. 또한, 각 Question 별 QxA 필드의 @user_id 필드에도 유저 ID 가 저장될 수 있다.
PDI 엔진은 UI 를 통해, PDI Question 들을 노출시킬 수 있다(ts150110). 사용자는 UI 를 통해 답변을 입력하고(ts150120), UI 는 이 답변을 PDI 엔진에 전달할 수 있다(ts150130). PDI 엔진은 해당 답변을 PDI 스토어에 저장할 수 있다(ts150140). 이 PDI 유저 데이터들은, 향후 사용자별 개인화 서비스를 제공할 때 활용될 수 있을 것이다.
유저에게 중복질문이 노출되는 것을 방지하는 방법을 설명한다.
유저가 로그인된 이후에, 동일한 PDI Question 이 수신기로 전달된다면, 유저가 이미 대답한 PDI Question 이 다시 유저에게 노출될 수도 있다. 이를 방지하기 위해 다음과 같은 방법을 고려할 수 있다.
먼저, 전달받은 PDI Question 의 ID 와 같은 ID 를 가지는 PDI Question 과 그 답변이, 이미 PDI 스토어에 저장되어 있는지 확인될 수 있다.
첫번째로, 해당 PDI Question 의 답변이 이미 저장되어 있지 않는 경우, 해당 PDI Question 은 UI 를 통해 사용자에게 노출되고, 사용자는 해당 질문에 답변할 수 있다.
두번째로, 해당 PDI Question 의 답변이 이미 저장되어 있으나, 그 PDI Question 의 @user_id 가 현재 로그인된 사용자의 ID 와 다를 경우, 해당 PDI Question 은 UI 를 통해 사용자에게 노출되고, 사용자는 해당 질문에 답변할 수 있다. 기 저장된 답변은 다른 유저의 답변이기 때문이다.
세번째로, 해당 PDI Question 의 답변이 이미 저장되어 있고, 그 PDI Question 의 @user_id 가 현재 로그인된 사용자의 ID 와 같을 경우, 해당 PDI Question 은 유저에게 노출되지 않을 수 있다. 해당 유저가, 해당 PDI Question 에 이미 답변을 한 상태이기 때문이다. 이 경우, 기 저장된 답변이 전달받은 PDI Question 의 답변으로 저장될 수 있다.
도 151 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 필터링 크리테리아를 적용하는 시퀀스 다이어그램을 도시한 도면이다.
필터링 크리테리아를 통해 컨텐츠/서비스를 필터링하는 경우에 있어서도, 유저 ID 를 이용해 복수의 사용자를 구분해야 할 수 있다. 입력된 사용자별 Q&A 를 이용하여 FC 를 적용해야, 복수의 사용자의 선호도에 맞게 컨텐츠/서비스를 제공할 수 있다.
본 시퀀스 다이어그램에서, 사용자는 이미 로그인된 상태라고 가정한다.
컨텐츠 프로바이더 또는 브로드캐스터는 FC 를 수신기에 전달할 수 있다(ts151010). 이 때, FC는 브로드캐스트 또는 브로드밴드 채널을 통해 전달될 수 있다. 수신기는 전달받은 FC 디스크립터 또는 테이블을 시그널링하고, 이를 파싱한 후 FC 집합을 FC 엔진으로 전달할 수 있다(ts151020).
FC 엔진은 유저 매니지먼트 엔진에 유저 ID 를 요청할 수 있다(ts151030). 유저 매니지먼트 엔진은 요청받은 유저 ID 를 리턴할 수 있다(ts151040). 실시예에 따라, PDI 테이블이 유저 ID 를 요청하고, 반환받을 수도 있다.
FC 엔진은 PDI 엔진에, 리턴받은 유저 ID 를 가지는 PDI Q&A 를 요청할 수 있다(ts151050). PDI 엔진은 해당 PDI Q&A 를 PDI 스토어에서 검색할 수 있다(ts151060). PDI 엔진은 검색된 해당 PDI Q&A 를 FC 엔진에 전달할 수 있다(ts151070).
FC 엔진은 전달받은 PDI 데이터와 FC 집합을 비교할 수 있다(ts151080). 이 비교를 통하여 해당 컨텐츠/서비스가 해당 유저에 적합한 컨텐츠/서비스인지가 판단될 수 있다. FC 집합에 매칭되는 컨텐츠/서비스라면, FC 엔진은 FLUTE 세션으로부터 해당 컨텐츠/서비스를 다운로드 받을 수 있다. 실시예에 따라 FLUTE 세션이 아닌 다른 소스로부터 다운로드를 받을 수도 있다.
현재 로그인되어 있는 유저에 적합하지 않은 컨텐츠/서비스라 할지라도, 유저 매니지먼트 엔진에 의해 관리되는 유저들 중에 해당 컨텐츠/서비스를 선호하는 유저가 있을 경우, 향후 사용을 위해 해당 컨텐츠/서비스를 다운로드 받아놓을 수도 있다. 유저 매니지먼트 엔진에 의해 관리되는 유저들 중에 해당 컨텐츠/서비스를 선호하는 유저가 하나도 없을 경우, 해당 컨텐츠/서비스를 다운로드 받지 않을 수 있다.
도 152 는 본 발명의 일 실시예에 따른, 유저 ID 를 할당하는 방법을 도시한 도면이다.
전술한 바와 같이, 사용자를 구분하기 위해 user_id 필드가 사용될 수 있다. 이 때, user_id 필드에 저장되는 유저 ID 는 로컬 유니크 ID 방식(Local Unique ID Method) 또는 글로벌 유니크 ID 방식(Globally Unique ID Method) 에 의해 저장될 수 있다. 실시예에 따라, 유저 ID 는 다른 방식으로 저장될 수도 있다.
로컬 유니크 ID 방식은 수신기 및 홈 네트워크 환경의 범위에서 유니크한 ID 를 사용하는 방식일 수 있다. 이 때, 유저 ID 는 string 데이터 타입을 가질 수 있으며, 유저 매니지먼트 엔진에 의해 관리될 수 있다.
전술한 로그인 방식에 따를 경우, 즉 사용자가 수동으로 유저 ID 를 통해 로그인하는 경우, 로컬 유니크 ID 는 사용자에 의해 제약없이 string 형태로 등록될 수 있다. 유저 매니지먼트 엔진은, 등록하려는 ID 가 중복된 ID 일 경우 사용자에게 재등록을 요구할 수 있다.
전술한 자동 식별 방식에 따를 경우, 유저 매니지먼트 엔진은, 새로이 인식된 사용자에게 자동으로 랜덤하게 유저 ID 를 설정/할당해놓을 수 있다.
글로벌 유니크 ID 방식은 글로벌한 범위에서 유니크한 ID 를 사용하는 방식일 수 있다. 이 때, 유저 ID 는 마찬가지로, string 데이터 타입을 가질 수 있으며, 유저 매니지먼트 엔진에 의해 관리될 수 있다.
여기서 글로벌한 범위란 홈 네트워크를 벗어나 다른 수신기 역시 포함된 범위를 말할 수도 있고, 서비스 프로바이더의 시스템이 미치는 범위일 수도 있고, 전 세계를 범위로 할 수도 있다. 이에 따라, 본 발명에 따른 PDI 시스템이 적용된 수신기가 있는 어느 장소에서라도, 사용자는 자신의 ID 로 로그인 한 후, 자신의 PDI Question 에 맞춰 컨텐츠/서비스를 제공받을 수 있다. 이를 위해서, 유저 ID 및 이에 따른 Q&A 가 저장될 수 있는 공용 스토리지가 필요할 수 있다(e.g. 클라우드 스토리지).
전술한 로그인 방식 및 자동 식별 방식에 따르는 경우, 로컬 유니크 ID 방식과 같은 방식으로 동작될 수 있다.
글로벌 유니크 ID 생성을 위하여, 유저 ID 는 다음과 같은 방식으로 조합될 수 있다.
user_id : <manually assigned id by user>_<uniquely identifiable data>
여기서, <Manually assigned id by user> 는 유저에 의해서 직접 지정되는 ID 일 수 있다. 또한, 여기서, <Uniquely identifiable data> 는 유저에 의해 직접 지정되거나, 혹은 직접 지정되지는 않지만 ID 를 글로벌하게 유니크하도록 구분시켜주는 데이터일 수 있다. 실시예에 따라, <Uniquely identifiable data> 는 유저의 이메일 주소, 전화번호 또는 디바이스의 MAC 주소 등을 포함할 수 있다.
글로벌 유니크 ID 는 <manually assigned id by user> 및 <uniquely identifiable data> 의 조합에 의해서 글로벌하게 유니크해질 수 있다. <manually assigned id by user> 는 복수의 사용자들간에 동일할 수 있어도, <uniquely identifiable data> 에 의해 전체 글로벌 유니크 ID 는 글로벌하게 유니크해질 수 있다.
도 153은 본 발명의 실시예에 따른 개인 관심에 기초한 인터랙티브 컨텐츠를 제공하는 방법을 나타낸다.
방법은 컴패니언 디바이스와 페어링하는 단계, PDI(Profiles, Demographics, Interests) 테이블을 수신하는 단계, 답변을 얻는 단계, 얻은 답변을 저장하는 단계 및/또는 PDI 테이블을 페어링된 컴패니언 디바이스로 전달하는 단계를 포함한다.
컴패니언 디바이스와 페어링하는 단계에서, 상술한 컴패니언 디바이스 모듈은 컴패니언 디바이스와 페어링한다. 이 단계에서, 일반적인 UPnP 기술이 사용될 수 있다. 실시예에 따라 다른 페어링 기술이 사용될 수 있다.
PDI 테이블을 수신하는 단계에서, 상술한 수신기는 PDI 테이블을 수신할 수 있다. PDI 테이블은 PDI 설문지 또는 PDI 유저 데이터라 할 수 있다. 이 실시예에서, PDI 테이블은 방송 신호를 통해 전달될 수 있다. 그러나, PDI 테이블 또는 PDI 유저 데이터는 브로드밴드를 통해 또한 전달될 수 있다. PDI 테이블은 인터랙티브 컨텐츠에 대한 개인 관심에 관련된 복수의 PDI 질문을 포함할 수 있다. PDI 질문은 상술한 QxA 타입 중의 하나 일 수 있다. PDI 테이블 또는 PDI 유저 데이터는 PDI 테이블을 식별하는 ID를 포함할 수 있다. ID는 PDIUserData 내의 @userDataId에 대응할 수 있다.
답변을 얻는 단계에서, PDI 엔진은 상술한 바와 같이 PDI 유저 데이터 내의 PDI 질문에 대한 답변을 얻을 수 있다. 답변은 사용자로부터 얻을 수 있다.
얻어진 답변을 저장하는 단계에서, PDI 엔진은 PDI 테이블에 얻어진 답변을 저장할 수 있다. 답변을 갖는 PDI 테이블은 상술한 PDI 스토어에 저장될 수 있다.
PDI 테이블을 페어링된 컴패니언 디바이스로 전달하는 단계에서, 컴패니언 디바이스 모듈은 PDI 테이블 또는 PDI 유저 데이터를 컴패니언 디바이스로 전달할 수 있다. GetUserDataIdsList 또는 GetUserData 등의 세부 액션이 이 단계에서 사용될 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, PDI 테이블을 전달하는 단계는 컴패니언 디바이스로부터 PDI 테이블의 ID의 리스트에 대한 제1 요청을 수신하는 단계를 더 포함한다. PDI 테이블의 ID의 리스트에 대한 제1 요청은 상술한 GetUserDataIdsList 액션에 대응할 수 있다. 제1 요청은 GetUserDataIdsList 액션에 기초하여 이루어질 수 있다.
이 실시예에서, 방법은 요청된 PDI 테이블의 ID의 리스트를 컴패니언 디바이스로 전달하는 단계를 더 포함한다. 이 단계는 GetUserDataIdsList 액션에 대한 응답에 대응한다. 컴패니언 디바이스는 PDI 유저 데이터의 ID를 얻을 수 있다.
이 실시예에서, 방법은 컴패니언 디바이스로부터 ID의 리스트 내의 소정의 ID를 갖는 PDI 테이블에 대한 제2 요청을 수신하는 단계를 더 포함한다. 제2 요청은 상술한 GetUserData 액션에 대응할 수 있다. 제2 요청은 GetUserData 액션에 기초하여 이루어질 수 있다. PDI 테이블의 ID의 리스트에 기초하여 컴패니언 디바이스는 그 ID를 이용하여 소정의 PDI 유저 데이터를 요청할 수 있다.
이 실시예에서, 방법은 요청된 PDI 테이블을 컴패니언 디바이스로 전달하는 단계를 더 포함한다. 이 단계는 GetUserData 액션에 대한 응답에 대응한다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, PDI 테이블을 전달하는 것은 UserData 서비스를 이용하여 수행된다. Userdata 서비스는 상술한 바와 같이 PDI 테이블을 전달하는 UPnP 서비스 중의 하나일 수 있다.
상술한 제1 요청은 UserData 서비스의 제1 UPnP 액션에 기초할 수 있다. 제1 UPnP 액션은 GetUserDataIdsList 액션에 대응할 수 있다. 제1 UPnP 액션 GetUserDataIdsList는 상술한 바와 같이 PDI 테이블의 ID의 리스트를 얻기 위한 것이다. 제1 UPnP 액션은 입력 인수로서 UserData 서비스의 프로토콜 버전 정보를 갖는다. 프로토콜 버전 정보는 상술한 ProtocolVersion 입력 인수에 대응할 수 있다. 제1 UPnP 액션은 출력 인수로서 PDI 테이블의 ID의 리스트를 가질 수 있다. 제1 UPnP 액션은 출력 인수로서 PDI 테이블의 ID의 리스트를 갖는다. PDI 테이블의 ID의 리스트는 상술한 UserDataIdsList 출력 인수에 대응할 수 있다.
상술한 제2 요청은 UserData 서비스의 제2 UPnP 액션에 기초할 수 있다. 제2 UPnP 액션은 GetUserData 액션에대응할 수 있다. 제2 UPnP 액션 GetUserData은 상술한 바와 같이 ID의 리스트 내의 소정의 ID를 갖는 PDI 테이블을 얻기 위한 것이다. 제2 UPnP 액션은 입력 인수로서 PDI 테이블의 ID의 리스트를 갖는다. PDI 테이블의 ID의 리스트는 상술한 UserDataIdsList 입력 인수에 대응할 수 있다. 제2 UPnP 액션은 출력 인수로서 PDI 테이블을 갖는다. PDI 테이블은 상술한 UserData 출력 인수에 대응할 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, 방법은 컴패니언 디바이스로부터 UserData 서비스에 대한 가입을 수신하는 단계를 더 포함한다. 이 실시예는 이벤트 방법에 기초한 전달 기술에 대응할 수 있다. 이 실시예는 UserDataUpdatedList 상태 변수에 기초한다. UserData 서비스는 PDI 테이블을 전달하는 UPnP 서비스 중의 하나이다.
이 실시예에서, UserDataUpdatedList가 업데이트/변경되면, 컴패니언 디바이스 모듈은 컴패니언 디바이스로 알림을 전송할 수 있다. 여기서, PDI 테이블 내의 답변이 업데이트되거나 새로운 PDI 테이블이 수신되면, UserDataUpdatedList가 업데이트/변경된다. 새로운 PDI 테이블이 수신되는 경우, PDI 유저 데이터의 버전이 변경될 수 있다. 컴패니언 디바이스에게 통지되면, 컴패니언 디바이스는 이를 컴패니언 디바이스에 저장된 PDI 유저 데이터와 비교할 수 있다. 컴패니언 디바이스는 업데이트된/변경된 PDI 유저 데이터를 요청할 수 있다. 컴패니언 디바이스 모듈은 업데이트된 답변을 갖는 PDI 테이블 또는 새로운 PDI 테이블을 컴패니언 디바이스로 전달할 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, 방법은 인터랙티브 컨텐츠 및 인터랙티브 컨텐츠와 연관된 필터링 기준을 수신하는 단계를 더 포함한다. 필터링 기준은 연관된 인터랙티브 컨텐츠의 성질에 관한 정보를 포함할 수 있다. 필터링 기준이 저장된 PDI 유저 데이터와 매칭되어 연관된 컨텐츠가 개인 취향에 적합한 것으로 결정할 수 있다.
이 실시예에서, 방법은 필터링 기준을 컴패니언 디바이스에 전달하는단계를 더 포함한다. 이 단계에서, GetFilteringCriteria 액션이 컴패니언 디바이스에 의해 사용될 수 있다. 필터링 기준이 컴패니언 디바이스에 전달되면, 컴패니언 디바이스는 필터링 기준을 컴패니언 디바이스 내의 PDI 테이블과 비교할 수 있다. 필터링 기준이 PDI 테이블 내의 답변과 매칭하면, 컴패니언 디바이스는 수신기에 요청할 수 있고, 수신기는 인터랙티브 컨텐츠를 전달할 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, 필터링 기준을 전달하는 것은 컴패니언 디바이스를 위한 인터랙티브 컨텐츠가 수신되었다는 것을 컴패니언 디바이스에 알리는 단계를 더 포함한다. 이것은 상술한 CD를 위한 컨텐츠/서비스의 존재의 알림에 대응한다. 그 후, 컴패니언 디바이스 모듈은 컴패니언 디바이스로부터 인터랙티브 컨텐츠와 연관된 필터링 기준에 대한 제3 요청을 수신할 수 있다. 제3 요청은 상술한 GetFilteringCriteria 액션에 기초한다. 컴패니언 디바이스 모듈은 CD를 위한 컨텐츠/서비스의 필터링 컨텐츠를 컴패니언 디바이스로 전달할 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, 필터링 기준을 전달하는 것은 FilteringCriteria 서비스를 이용하여 수행된다. FilteringCriteria 서비스는 상술한 바와 같이 필터링 기준을 전달하는 UPnP 서비스 중의 하나이다.
상술한 제3 요청은 FilteringCriteria 서비스의 제3 UPnP 액션에 기초할 수 있다. 제3 UPnP 액션은 GetFilteringCriteria 액션에 대응할 수 있다. 제3 UPnP 액션은 상술한 필터링 기준을 얻기 위한 것이다. 제3 UPnP 액션은 출력 인수로서 필터링 기준을 갖는다. 출력 인수는 상술한 FilteringCriteria에 대응할 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, 방은 수신된 PDI 테이블을 컴패니언 디바이스로 전달하는 단계를 더 포함한다. 이것은 CD가 PDI 질문에 대한 답변을 얻어 수신기로 전달하는 실시예에 대응할 수 있다. PDI 테이블은 컨텐츠 프로바이더/브로드캐스터 또는 수신기로부터 전달될 수 있다. 수신기가 PDI 테이블을 CD로 전달하는 경우, PDI 테이블이 먼저 수신기에 의해 수신되었다.
PDI 테이블이 수신되면, 컴패니언 디바이스는 적어도 하나의 PDI 질문에 대한 답변을 얻어 PDI 테이블에 저장할 수 있다. 그 후, CD는 상술한 SetUserDataQA 액션을 이용하여 PDI 테이블을 수신기로 전달할 수 있다.
수신기 내의 컴패니언 디바이스 모듈은 컴패니언 디바이스로부터 답변을 갖는 PDI 테이블을 수신할 수 있다. 전달은 SetUserDataQA 액션 및 Userdata 서비스에 기초한다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, 방법은 저장된 답변을 업데이트하는 단계를 더 포함한다. 저장된 답변은 PDI 답변이 PDI 스토어에 저장된 것을 의미한다. PDI 엔진은 저장된 답변을 컴패니언 디바이스로부터의 PDI 테이블 내의 답변으로 대체할 수 있다. CD로부터의 PDI 유저 데이터의 전달은 SetUserDataQA 액션에 기초한다. 이 방식으로, PDI 테이블은 CD측으로부터 얻은 답변으로 업데이트될 수 있다.
본 발명의 다른 실시예에 따라 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법에서, PDI 질문의 각각은 전체 PDI 테이블로서가 아니라 개별적으로 전달될 수 있다. PDI 테이블 내의 PDI 질문의 각각은 질문 ID를 포함하고, 질문 ID는 이 방법에 사용될 수 있다.
컴패니언 디바이스 모듈은 컴패니언 디바이스로부터 PDI 질문의 질문 ID의 리스트에 대한 제4 요청을 수신할 수 있다. 제4 요청은 GetUserDataQAIdsList 액션에 기초한다. 컴패니언 디바이스 모듈은 GetUserDataQAIdsList 액션에 대한 응답으로서 요청된 PDI 질문의 질문 ID의 리스트를 컴패니언 디바이스로 전달할 수 있다. CD는 수신된 리스트 내의 질문 ID를 이용하여 소정의 PDI 질문을 요청할 수 있다.
컴패니언 디바이스는 컴패니언 디바이스로부터 질문 ID의 리스트 내의 소정의 질문 ID를 갖는 PDI 질문에 대한 제5 요청을 수신할 수 있다. 제5 요청은 상술한 GetUserDataQA 액션에 기초한다. 컴패니언 디바이스 모듈은 GetUserDataQA 액션에 대한 응답으로서 요청된 PDI 질문 및 요청된 PDI 질문에 대한 답변을 컴패니언 디바이스로 전달할 수 있다.
상술한 단계는 설계에 따라 생략되거나 유사 또는 동일한 기능을 수행하는 단계로 대체될 수 있다.
본 발명의 설명은 명료화를 위해 첨부된 도면의 각각을 참조하여 설명하지만, 첨부된 도면에 도시된 실시예를 서로 병합함으로써 새로운 실시예(들)를 설계할 수 있다. 상기 설명에서 언급된 실시예를 실행하는 프로그램이 기록된 컴퓨터 판독가능 기록 매체가 당업자의 필요에 따라 설계되면, 이는 첨부된 청구 범위 및 그 동등물의 범위에 속할 수 있다.
본 발명에 따른 장치 및 방법은 상기 설명에서 언급된 실시예들의 구성들 및 방법들에 의해 제한되지 않는다. 상기 설명에서 언급된 실시예는 전체적으로 또는 부분적으로 서로 선택적으로 결합되는 방식으로 구성되어 다양한 변형이 가능하다.
또한, 본 발명에 따른 방법은 네트워크 장치에 제공되는 프로세서 판독가능 기록 매체에서 프로세서 판독가능 코드로 구현될 수 있다. 프로세서 판독가능 매체는 프로세서에 의해 판독가능한 데이터를 저장할 수 있는 모든 종류의 기록 장치를 포함할 수 있다. 프로세서 판독가능 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서 판독가능 기록 매체는 네트워크를 통해 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서 판독가능 코드가 저장되고 실행될 수 있다.
당업자는 본 발명의 사상 및 범위를 벗어나지 않고 본 발명의 다양한 변형 및 변경이 가능함을 인식할 것이다. 따라서, 본 발명은 첨부된 청구범위 및 그 동등물의 범위 내에서 제공되는 본 발명의 변형 및 변경을 커버한다.
장치 및 방법 발명이 본 명세서에 언급되었으며, 이들 장치 및 방법 발명의 설명은 서로 상호보완적으로 적용될 수 있다.
다양한 실시예가 본 발명을 수행하는 최상의 모드로 기재되었다.
본 발명은 방송 신호 제공 필드에서 유용하다.
본 발명의 사상 또는 범위를 벗어나지 않고 본 발명의 다양한 변형과 변경이 가능하다는 것은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구범위 및 그 동등물의 범위 내에서 제공되는 본 발명의 모든 변형과 변경을 커버하는 것으로 의도된다.

Claims (20)

  1. 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 방법으로서,
    컴패니언 디바이스와 페어링하는 단계;
    방송 신호를 통해 PDI(Profiles, Demographics, Interests) 테이블을 수신하는 단계, 상기 PDI 테이블은 인터랙티브 컨텐츠에 대한 개인 관심에 관련된 복수의 PDI 질문을 포함하고, 상기 PDI 테이블은 상기 PDI 테이블을 식별하는 ID를 포함하고;
    상기 PDI 질문 중의 적어도 하나에 대한 답변을 획득하는 단계; 및
    상기 획득한 답변을 갖는 상기 PDI 테이블을, 상기 PDI 테이블을 전달하기 위한 UPnP 서비스에 따라, 상기 페어링된 컴패니언 디바이스로 전달하는 단계; 를 포함하고, 상기 UPnP 서비스는 제 1 UPnP 액션 및 제 2 UPnP 액션을 포함하고,
    상기 PDI 테이블을 전달하는 단계는:
    상기 UPnP 서비스의 프로토콜 버전 정보를 포함함으로써 PDI 테이블의 ID 의 리스트를 요청하는 제 1 요청을 수신하는 단계;
    상기 리스트를 상기 컴패니언 디바이스로 전달하는 단계, 여기서 상기 제 1 요청은 상기 제 1 UPnP 액션에 따라 수행되고, 상기 제 1 UPnP 액션은 상기 프로토콜 버전 정보를 입력변수로, 상기 리스트를 출력 변수로 가지고;
    상기 ID 를 포함함으로써 상기 PDI 테이블을 요청하는 제 2 요청을 수신하는 단계; 및
    상기 ID 를 가지는 상기 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 단계; 를 포함하고, 상기 제 2 요청은 상기 제 2 UPnP 액션에 따라 수행되고, 상기 제 2 UPnP 액션은 상기 ID 를 입력변수로, 상기 PDI 테이블을 출력변수로 가지는 것을 특징으로 하는 방법.

  2. 삭제
  3. 삭제
  4. 제1항에 있어서, 상기 방법은:
    상기 컴패니언 디바이스로부터 상기 UPnP 서비스에 대한 가입을 수신하는 단계;
    를 더 포함하고,
    상기 UPnP 서비스는 상기 PDI 테이블을 전달하는 서비스이고,
    상기 PDI 테이블을 전달하는 단계는,
    상기 PDI 테이블 내의 답변이 업데이트되거나 새로운 PDI 테이블이 수신될 때 상기 컴패니언 디바이스로 알림을 전송하는 단계; 및
    상기 업데이트된 답변을 갖는 PDI 테이블 또는 새로운 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 단계;를 더 포함하는 방법.
  5. 제1항에 있어서, 상기 방법은:
    인터랙티브 컨텐츠 및 상기 인터랙티브 컨텐츠와 연관된 필터링 기준을 수신하는 단계, 상기 필터링 기준은 상기 연관된 인터랙티브 컨텐츠의 성질에 관한 정보를 포함하고;
    상기 필터링 기준을 상기 컴패니언 디바이스로 전달하는 단계, 상기 전달된 필터링 기준은 상기 컴패니언 디바이스 내에 저장된 상기 PDI 테이블과 비교되어, 상기 인터랙티브 컨텐츠를 수신할지 여부를 결정하는데 사용되고; 및
    상기 전달된 필터링 기준이 상기 PDI 테이블 내의 답변과 매칭되면 상기 인터랙티브 컨텐츠를 전달하는 단계; 를 더 포함하는 방법.
  6. 제5항에 있어서, 상기 필터링 기준을 전달하는 단계는,
    상기 컴패니언 디바이스에 대한 인터랙티브 컨텐츠가 수신되었다는 것을 상기 컴패니언 디바이스에 알리는 단계;
    상기 컴패니언 디바이스로부터 상기 인터랙티브 컨텐츠와 연관된 필터링 기준을 요청하는 제3 요청을 수신하는 단계; 및
    상기 필터링 기준을 상기 컴패니언 디바이스로 전달하는 단계; 를 더 포함하는 방법.
  7. 제6항에 있어서,
    상기 필터링 기준을 전달하는 것은 FilteringCriteria 서비스를 이용하여 수행되고,
    상기 FilteringCriteria 서비스는 상기 필터링 기준을 전달하는 UPnP 서비스이고,
    상기 제3 요청은 상기 FilteringCriteria 서비스의 제3 UPnP 액션에 기초하고, 상기 제3 UPnP 액션은 상기 필터링 기준을 얻기 위한 것이고, 상기 UPnP 액션은 출력 인수로서 상기 필터링 기준을 갖는 방법.
  8. 제1항에 있어서,
    상기 수신된 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 단계, 상기 적어도 하나의 PDI 질문에 대한 답변이 상기 전달된 PDI 테이블에 저장되고; 및
    상기 컴패니언 디바이스로부터 새로운 답변을 갖는 상기 PDI 테이블을 수신하는 단계;
    를 더 포함하는 방법.
  9. 제8항에 있어서, 상기 컴패니언 디바이스로부터의 PDI 테이블 내의 상기 새로운 답변으로 대체함으로서 상기 저장된 답변을 업데이트하는 단계를 더 포함하는 방법.
  10. 제1항에 있어서,
    상기 PDI 테이블 내의 PDI 질문의 각각은 질문 ID를 포함하고,
    상기 PDI 테이블을 전달하는 단계는,
    상기 컴패니언 디바이스로부터 PDI 질문의 질문 ID의 리스트를 요청하는 제4 요청을 수신하는 단계;
    상기 요청된 PDI 질문의 질문 ID의 리스트를 상기 컴패니언 디바이스로 전달하는 단계;
    상기 컴패니언 디바이스로부터 질문 ID의 리스트 내의 특정 질문 ID를 갖는 PDI 질문을 요청하는 제5 요청을 수신하는 단계; 및
    상기 요청된 PDI 질문 및 상기 요청된 PDI 질문에 대한 답변을 상기 컴패니언 디바이스로 전달하는 단계
    를 더 포함하는 방법.
  11. 개인 관심에 기초하여 인터랙티브 컨텐츠를 제공하는 장치로서,
    컴패니언 디바이스와 페어링하는 페어링 모듈;
    방송 신호를 통해 PDI(Profiles, Demographics, Interests) 테이블을 수신하는 수신 모듈, 상기 PDI 테이블은 인터랙티브 컨텐츠에 대한 개인 관심에 관련된 복수의 PDI 질문을 포함하고 상기 PDI 테이블은 상기 PDI 테이블을 식별하는 ID를 포함하고;
    상기 PDI 질문 중의 적어도 하나에 대한 답변을 획득하는 답변 획득 모듈;
    상기 PDI 테이블에 상기 획득한 답변을 저장하는 PDI 저장 모듈; 및
    상기 획득한 답변을 갖는 상기 PDI 테이블을, 상기 PDI 테이블을 전달하기 위한 UPnP 서비스에 따라, 상기 페어링된 컴패니언 디바이스로 전달하는 컴패니언 디바이스 모듈; 을 포함하고, 상기 상기 UPnP 서비스는 제 1 UPnP 액션 및 제 2 UPnP 액션을 포함하고,
    상기 컴패니언 디바이스 모듈은, 상기 PDI 테이블을 전달하기 위하여:
    상기 UPnP 서비스의 프로토콜 버전 정보를 포함함으로써 PDI 테이블의 ID 의 리스트를 요청하는 제 1 요청을 수신하고;
    상기 리스트를 상기 컴패니언 디바이스로 전달하고, 여기서 상기 제 1 요청은 상기 제 1 UPnP 액션에 따라 수행되고, 상기 제 1 UPnP 액션은 상기 프로토콜 버전 정보를 입력변수로, 상기 리스트를 출력 변수로 가지고;
    상기 ID 를 포함함으로써 상기 PDI 테이블을 요청하는 제 2 요청을 수신하고; 및
    상기 ID 를 가지는 상기 PDI 테이블을 상기 컴패니언 디바이스로 전달하고;
    여기서 상기 제 2 UPnP 액션은 상기 ID 를 입력변수로, 상기 PDI 테이블을 출력변수로 가지는 것을 특징으로 하는 장치.

  12. 삭제
  13. 삭제
  14. 제11항에 있어서, 상기 컴패니언 디바이스 모듈은 또한
    상기 컴패니언 디바이스로부터 상기 UPnP 서비스에 대한 가입을 수신하고, 상기 UPnP 서비스는 상기 PDI 테이블을 전달하는 서비스이고;
    상기 PDI 테이블 내의 답변이 업데이트되거나 새로운 PDI 테이블이 수신될 때 상기 컴패니언 디바이스로 알림을 전송하고;
    상기 업데이트된 답변을 갖는 PDI 테이블 또는 새로운 PDI 테이블을 상기 컴패니언 디바이스로 전달하는 장치.
  15. 제11항에 있어서, 상기 수신 모듈은 또한,
    인터랙티브 컨텐츠 및 상기 인터랙티브 컨텐츠와 연관된 필터링 기준을 수신하고, 상기 필터링 기준은 상기 연관된 인터랙티브 컨텐츠의 성질에 관한 정보를 포함하고,
    상기 컴패니언 디바이스 모듈은 또한
    상기 필터링 기준을 상기 컴패니언 디바이스로 전달하고, 상기 전달된 필터링 기준은 상기 컴패니언 디바이스 내에 저장된 상기 PDI 테이블과 비교되어, 상기 인터랙티브 컨텐츠를 수신할지 여부를 결정하는데 사용되고;
    상기 전달된 필터링 기준이 상기 PDI 테이블 내의 답변과 매칭되면 상기 인터랙티브 컨텐츠를 전달하는 장치.
  16. 제15항에 있어서, 상기 필터링 기준을 전달하는 것은
    상기 컴패니언 디바이스에 대한 인터랙티브 컨텐츠가 수신되었다는 것을 상기 컴패니언 디바이스에 알리는 것;
    상기 컴패니언 디바이스로부터 상기 인터랙티브 컨텐츠와 연관된 필터링 기준을 요청하는 제3 요청을 수신하는 것; 및
    상기 필터링 기준을 상기 컴패니언 디바이스로 전달하는 것
    을 더 포함하는 장치.
  17. 제16항에 있어서,
    상기 필터링 기준을 전달하는 것은 FilteringCriteria 서비스를 이용하여 수행되고,
    상기 FilteringCriteria 서비스는 상기 필터링 기준을 전달하는 UPnP 서비스이고,
    상기 제3 요청은 상기 FilteringCriteria 서비스의 제3 UPnP 액션에 기초하고, 상기 제3 UPnP 액션은 상기 필터링 기준을 얻기 위한 것이고, 상기 UPnP 액션은 출력 인수로서 상기 필터링 기준을 갖는 장치.
  18. 제11항에 있어서, 상기 컴패니언 디바이스 모듈은 또한,
    상기 수신된 PDI 테이블을 상기 컴패니언 디바이스로 전달하고, 상기 적어도 하나의 PDI 질문에 대한 답변이 상기 전달된 PDI 테이블에 저장되고;
    상기 컴패니언 디바이스로부터 새로운 답변을 갖는 상기 PDI 테이블을 수신하는 장치.
  19. 제18항에 있어서, 상기 답변 획득 모듈은 또한 상기 컴패니언 디바이스로부터의 PDI 테이블 내의 상기 새로운 답변으로 대체함으로서 상기 저장된 답변을 업데이트하는 장치.
  20. 제11항에 있어서,
    상기 PDI 테이블 내의 PDI 질문의 각각은 질문 ID를 포함하고,
    상기 컴패니언 디바이스 모듈은 또한
    상기 컴패니언 디바이스로부터 PDI 질문의 질문 ID의 리스트를 요청하는 제4 요청을 수신하고;
    상기 요청된 PDI 질문의 질문 ID의 리스트를 상기 컴패니언 디바이스로 전달하고;
    상기 컴패니언 디바이스로부터 질문 ID의 리스트 내의 특정 질문 ID를 갖는 PDI 질문을 요청하는 제5 요청을 수신하고;
    상기 요청된 PDI 질문 및 상기 요청된 PDI 질문에 대한 답변을 상기 컴패니언 디바이스로 전달하는 장치.
KR1020167014572A 2013-12-24 2014-12-11 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법 KR101838078B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361920485P 2013-12-24 2013-12-24
US61/920,485 2013-12-24
US201462018669P 2014-06-30 2014-06-30
US62/018,669 2014-06-30
PCT/KR2014/012201 WO2015099331A1 (en) 2013-12-24 2014-12-11 Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals

Publications (2)

Publication Number Publication Date
KR20160077197A KR20160077197A (ko) 2016-07-01
KR101838078B1 true KR101838078B1 (ko) 2018-03-13

Family

ID=53479131

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020167014572A KR101838078B1 (ko) 2013-12-24 2014-12-11 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법

Country Status (5)

Country Link
US (1) US9866908B2 (ko)
EP (1) EP3087746B1 (ko)
KR (1) KR101838078B1 (ko)
CN (1) CN105850141B (ko)
WO (1) WO2015099331A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102461599B1 (ko) 2014-06-20 2022-11-03 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법
WO2016189870A1 (en) * 2015-05-26 2016-12-01 Sharp Kabushiki Kaisha Message Protocol Sequence for Primary Device and Companion Device Communication
BR112017000548B1 (pt) * 2015-10-13 2023-04-11 Huawei Technologies Co., Ltd Dispositivo e método de decodificação e sistema de transmissão de sinal
CA3082203C (en) 2015-10-23 2022-11-08 Sharp Kabushiki Kaisha Signaling method, receiving method signaling device, and receiving device
US10972205B2 (en) 2016-10-21 2021-04-06 Saturn Licensing Llc Reception apparatus, transmission apparatus, and data processing method
US11115720B2 (en) * 2016-12-06 2021-09-07 Facebook, Inc. Providing a live poll within a video presentation
CN109660370A (zh) * 2019-01-08 2019-04-19 湖南康通电子股份有限公司 一种数字广播系统的设备通信方法
CN114614877B (zh) * 2022-01-18 2023-12-19 南京控维通信科技有限公司 基于tdm/tdma体制的卫星通信数据封装系统及其封装方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010187418A (ja) * 1995-10-02 2010-08-26 Starsight Telecast Inc テレビジョンスケジュール情報を供給するシステム及び方法
JP2012014722A (ja) * 2011-09-12 2012-01-19 Hitachi Ltd 情報処理装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040073482A1 (en) * 2002-10-15 2004-04-15 Wiggins Randall T. Targeted information content delivery using a combination of environmental and demographic information
US20080155062A1 (en) * 2006-11-02 2008-06-26 Andre Rabold System for providing media data
US8695033B2 (en) * 2009-11-13 2014-04-08 Hydra Media Technology, Inc. Networks and systems for generating and/or delivering hybrid broadcast content
EP2343881B1 (en) * 2010-01-07 2019-11-20 LG Electronics Inc. Method of processing application in digital broadcast receiver connected with interactive network, and digital broadcast receiver
US9723360B2 (en) 2010-04-01 2017-08-01 Saturn Licensing Llc Interests and demographics profile for advanced broadcast services
US20120095796A1 (en) * 2010-04-29 2012-04-19 E Motive LLC System and method for mobile survey management
US8909694B2 (en) 2010-08-27 2014-12-09 Sony Corporation Transmission apparatus and method, reception apparatus and method, and transmission and reception system
US20120185888A1 (en) * 2011-01-19 2012-07-19 Sony Corporation Schema for interests and demographics profile for advanced broadcast services
US20120271696A1 (en) 2011-04-22 2012-10-25 Patricia Akbar Personalized Coupon Delivery System, Web Interface and Method of Use

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010187418A (ja) * 1995-10-02 2010-08-26 Starsight Telecast Inc テレビジョンスケジュール情報を供給するシステム及び方法
JP2012014722A (ja) * 2011-09-12 2012-01-19 Hitachi Ltd 情報処理装置

Also Published As

Publication number Publication date
US9866908B2 (en) 2018-01-09
CN105850141A (zh) 2016-08-10
CN105850141B (zh) 2019-08-20
WO2015099331A1 (en) 2015-07-02
EP3087746A1 (en) 2016-11-02
EP3087746B1 (en) 2019-07-03
US20160316270A1 (en) 2016-10-27
EP3087746A4 (en) 2017-07-26
KR20160077197A (ko) 2016-07-01

Similar Documents

Publication Publication Date Title
KR101850727B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법
US11265619B2 (en) Method for transmitting broadcast signals and method for receiving broadcast signals
KR101832781B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR101838078B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법
KR101829844B1 (ko) 하이브리드 방송 서비스를 프로세싱하는 장치, 하이브리드 방송 서비스를 프로세싱하는 방법
JP6189546B2 (ja) 放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置
KR101832780B1 (ko) 방송 수신 장치 및 방송 수신 장치의 동작 방법
KR101923459B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR20150034190A (ko) 디지털 서비스 신호 처리 방법 및 장치
KR20160091421A (ko) 방송 전송 장치, 방송 전송 장치의 동작 방법. 방송 수신 장치 및 방송 수신 장치의 동작 방법
KR101902409B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

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