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

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

Info

Publication number
KR20170026484A
KR20170026484A KR1020177001595A KR20177001595A KR20170026484A KR 20170026484 A KR20170026484 A KR 20170026484A KR 1020177001595 A KR1020177001595 A KR 1020177001595A KR 20177001595 A KR20177001595 A KR 20177001595A KR 20170026484 A KR20170026484 A KR 20170026484A
Authority
KR
South Korea
Prior art keywords
information
question
personalization
service
present
Prior art date
Application number
KR1020177001595A
Other languages
English (en)
Other versions
KR101902409B1 (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 KR20170026484A publication Critical patent/KR20170026484A/ko
Application granted granted Critical
Publication of KR101902409B1 publication Critical patent/KR101902409B1/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/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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2668—Creating a channel for a dedicated end-user group, e.g. insertion of targeted commercials based on end-user profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/78—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/7867—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using information manually generated, e.g. tags, keywords, comments, title and artist information, manually generated time, location and usage information, user ratings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9538—Presentation of query results
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user 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/4508—Management of client data or end-user data
    • H04N21/4516—Management of client data or end-user data involving client characteristics, e.g. Set-Top-Box type, software version or amount of memory available
    • 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/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4667—Processing of monitored end-user data, e.g. trend analysis based on the log file of viewer selections
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/47—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 genres

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Graphics (AREA)
  • Computer Security & Cryptography (AREA)
  • Library & Information Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

본 발명은 방송 수신기에서 개인화된 서비스를 제공하는 방법을 제안한다. 본 방법은, 수신 모듈이 개인화된 서비스 제공에 관한 적어도 하나의 개인화 질문을 포함하는 개인화 테이블을 수신하는 단계; 개인화 모듈이 사용자로부터 상기 적어도 하나의 개인화 질문에 대한 답변을 획득하여 저장하는 단계; 상기 수신 모듈이 특정 서비스에 관한 개인화 기준정보를 포함하는 제 1 필터링 크리테리아를 수신하는 단계; 및 필터링 모듈이 상기 수신한 제 1 필터링 크리테리아의 개인화 기준정보와 상기 저장된 답변을 비교하여 매칭되는 경우, 상기 수신모듈이 상기 특정 서비스에 관한 서비스 데이터를 수신하는 단계; 를 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.

Description

방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법{BROADCASTING SIGNAL TRANSMISSION APPARATUS, BROADCASTING SIGNAL RECEPTION APPARATUS, BROADCASTING SIGNAL TRANSMISSION METHOD, AND BROADCASTING SIGNAL RECEPTION METHOD}
본 발명은 방송 신호 송신 장치, 방송 신호 수신 장치, 및 방송 신호 송수신 방법에 관한 것이다.
아날로그 방송 신호 송신이 종료됨에 따라, 디지털 방송 신호를 송수신하기 위한 다양한 기술이 개발되고 있다. 디지털 방송 신호는 아날로그 방송 신호에 비해 더 많은 양의 비디오/오디오 데이터를 포함할 수 있고, 비디오/오디오 데이터뿐만 아니라 다양한 종류의 부가 데이터를 더 포함할 수 있다.
즉, 디지털 방송 시스템은 HD(High Definition) 이미지, 멀티채널(multi channel, 다채널) 오디오, 및 다양한 부가 서비스를 제공할 수 있다. 그러나, 디지털 방송을 위해서는, 많은 양의 데이터 전송에 대한 데이터 전송 효율, 송수신 네트워크의 견고성(robustness), 및 모바일 수신 장치를 고려한 네트워크 유연성(flexibility)이 향상되어야 한다.
목적 및 다른 이점을 달성하기 위해, 본 발명의 목적에 따라, 여기에 포함되고 대략적으로 기재된 바와 같이, 방송 수신기에서 개인화된 서비스를 제공하는 방법은, 수신 모듈이 개인화된 서비스 제공에 관한 적어도 하나의 개인화 질문을 포함하는 개인화 테이블을 수신하는 단계; 개인화 모듈이 사용자로부터 상기 적어도 하나의 개인화 질문에 대한 답변을 획득하여 저장하는 단계; 상기 수신 모듈이 특정 서비스에 관한 개인화 기준정보를 포함하는 제 1 필터링 크리테리아를 수신하는 단계; 및 필터링 모듈이 상기 수신한 제 1 필터링 크리테리아의 개인화 기준정보와 상기 저장된 답변을 비교하여 매칭되는 경우, 상기 수신모듈이 상기 특정 서비스에 관한 서비스 데이터를 수신하는 단계; 를 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 개인화된 서비스를 제공하는 방법은: 히스토리 모듈이 사용자의 서비스 시청에 대해 시청 히스토리 정보를 생성하여 저장하는 단계; 를 더 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.
다른 관점에서, 본 발명은 개인화된 서비스를 제공하는 방송 수신기를 제안한다. 이 방송 수신기는, 개인화된 서비스 제공에 관한 적어도 하나의 개인화 질문을 포함하는 개인화 테이블을 수신하는 수신 모듈; 사용자로부터 상기 적어도 하나의 개인화 질문에 대한 답변을 획득하여 저장하는 개인화 모듈, 여기서, 상기 수신 모듈은 특정 서비스에 관한 개인화 기준정보를 포함하는 제 1 필터링 크리테리아를 수신하고; 및 상기 수신한 제 1 필터링 크리테리아의 개인화 기준정보와 상기 저장된 답변을 비교하는 필터링 모듈, 여기서 상기 개인화 기준정보와 상기 저장된 답변이 매칭되는 경우, 상기 수신모듈이 상기 특정 서비스에 관한 서비스 데이터를 수신하고; 를 포함하는 개인화된 서비스를 제공하는 방송 수신기일 수 있다. .
바람직하게는, 개인화된 서비스를 제공하는 방송 수신기는, 사용자의 서비스 시청에 대해 시청 히스토리 정보를 생성하여 저장하는 히스토리 모듈; 을 더 포함하는 개인화된 서비스를 제공하는 방송 수신기일 수 있다.
본 발명은 서비스 특성에 따라 데이터를 처리하여 각 서비스 또는 서비스 컴포넌트에 대한 QoS (Quality of Service)를 제어함으로써 다양한 방송 서비스를 제공할 수 있다.
본 발명은 동일한 RF (radio frequency) 신호 대역폭을 통해 다양한 방송 서비스를 전송함으로써 전송 유연성(flexibility)을 달성할 수 있다.
본 발명은 MIMO (Multiple-Input Multiple-Output) 시스템을 이용하여 데이터 전송 효율 및 방송 신호의 송수신 견고성(Robustness)을 향상시킬 수 있다.
본 발명에 따르면, 모바일 수신 장치를 사용하거나 실내 환경에 있더라도, 에러 없이 디지털 방송 신호를 수신할 수 있는 방송 신호 송신 및 수신 방법 및 장치를 제공할 수 있다.
본 발명에 대해 더욱 이해하기 위해 포함되며 본 출원에 포함되고 그 일부를 구성하는 첨부된 도면은 본 발명의 원리를 설명하는 상세한 설명과 함께 본 발명의 실시예를 나타낸다.
도 1은 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치의 구조를 나타낸다.
도 2는 본 발명의 일 실시예에 따른 인풋 포맷팅(Input formatting, 입력 포맷) 블록을 나타낸다.
도 3은 본 발명의 다른 일 실시예에 따른 인풋 포맷팅(Input formatting, 입력 포맷) 블록을 나타낸다.
도 4는 본 발명의 일 실시예에 따른 BICM (bit interleaved coding & modulation) 블록을 나타낸다.
도 5는 본 발명의 다른 일 실시예에 따른 BICM 블록을 나타낸다.
도 6은 본 발명의 일 실시예에 따른 프레임 빌딩(Frame Building, 프레임 생성) 블록을 나타낸다.
도 7은 본 발명의 일 실시예에 따른 OFDM (orthogonal frequency division multiplexing) 제너레이션(generation, 생성) 블록을 나타낸다.
도 8은 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치의 구조를 나타낸다.
도 9는 본 발명의 일 실시예에 따른 프레임 구조를 나타낸다.
도 10은 본 발명의 일 실시예에 따른 프레임의 시그널링 계층 구조를 나타낸다.
도 11은 본 발명의 일 실시예에 따른 프리앰블 시그널링 데이터를 나타낸다.
도 12는 본 발명의 일 실시예에 따른 PLS1 데이터를 나타낸다.
도 13은 본 발명의 일 실시예에 따른 PLS2 데이터를 나타낸다.
도 14는 본 발명의 다른 일 실시예에 따른 PLS2 데이터를 나타낸다.
도 15는 본 발명의 일 실시예에 따른 프레임의 로지컬(logical, 논리) 구조를 나타낸다.
도 16은 본 발명의 일 실시예에 따른 PLS (physical layer signalling) 매핑을 나타낸다.
도 17은 본 발명의 일 실시예에 따른 EAC (emergency alert channel) 매핑을 나타낸다.
도 18은 본 발명의 일 실시예에 따른 FIC (fast information channel) 매핑을 나타낸다.
도 19는 본 발명의 일 실시예에 따른 FEC (forward error correction) 구조를 나타낸다.
도 20은 본 발명의 일 실시예에 따른 타임 인터리빙을 나타낸다.
도 21은 본 발명의 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 기본 동작을 나타낸다.
도 22는 본 발명의 다른 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 동작을 나타낸다.
도 23은 본 발명의 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 대각선 방향 읽기 패턴을 나타낸다.
도 24는 본 발명의 일 실시예에 따른 각 인터리빙 어레이(array)로부터 인터리빙된 XFECBLOCK을 나타낸다.
도 25 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디 인터리빙을 위한 시그널링을 도시한 도면이다.
도 26 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디 인터리빙을 위한 시그널링에 있어서, FSS 를 위한 FI 스킴들을 도시한 도면이다.
도 27 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디 인터리빙을 위한 시그널링에 있어서, FES 를 위한 리셋 모드의 동작을 도시한 도면이다.
도 28 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 주파수 인터리버의 입력과 출력을 수학식으로 표시한 도면이다.
도 29 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, FI 스킴 #1 및 FI 스킴 #2 에 따른 주파수 인터리빙의 논리적 동작 매커니즘의 수학식을 나타낸다.
도 30 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 짝수인 경우의 실시예를 도시한 도면이다.
도 31 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 짝수인 경우의 실시예를 도시한 도면이다.
도 32 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 홀수인 경우의 실시예를 도시한 도면이다.
도 33 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 홀수인 경우의 실시예를 도시한 도면이다.
도 34 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 주파수 디인터리버의 동작을 도시한 도면이다.
도 35는 본 발명의 다른 실시예에 따른 variable data-rate 시스템을 나타낸 개념도이다.
도 36은 본 발명의 블록 인터리빙의 라이팅(writing) 및 리딩 (reading) 오퍼레이션의 일 실시예를 나타낸다. 이에 대한 구체적인 내용은 전술하였다.
도 37은 본 발명의 일 실시예에 따른 블록 인터리빙을 나타낸 수학식이다.
도 38는 본 발명의 일 실시예에 따른 버츄얼 (virtual) FEC 블록들을 나타낸 도면이다.
도 39은 본 발명의 일 실시예에 따른 버츄얼 (virtual) FEC 블록들이 삽입된 이후 리딩 (reading) 동작을 나타낸 수학식이다.
도 40는 본 발명의 일 실시예에 따른 타임 인터리빙의 프로세스를 나타낸 순서도이다.
도 41은 본 발명의 일 실시예에 따른 시프트 밸류 및 맥시멈 TI 블록의 크기를 결정하는 과정을 나타낸 수학식이다.
도 42은 본 발명의 일 실시예에 따른 라이팅 (writing) 오퍼레이션을 나타낸다.
도 43은 본 발명의 일 실시예에 따른 리딩 (reading) 오퍼레이션을 나타낸다.
도 44은 본 발명의 일 실시예에 따른 리딩 (reading) 오퍼레이션에서 스킵 오퍼레이션이 수행된 결과를 나타낸다.
도 45는 본 발명의 일 실시예에 따른 타임 디인터리빙의 라이팅 (writing) 과정을 나타낸다.
도 46는 본 발명의 다른 실시예에 따른 타임 디인터리빙의 라이팅 (writing) 과정을 나타낸다.
도 47은 본 발명의 다른 실시예에 따른 타임 디인터리빙의 리딩 (reading) 오퍼레이션을 나타내는 수학식이다.
도 48은 본 발명의 일 실시예에 따른 타임 디인터리빙의 프로세스를 나타낸 순서도이다.
도 49은 자동 콘텐츠 인식 기반 ETV(enhanced television) 서비스 시스템을 나타낸 도면이다.
도 50는 본 발명의 일 실시예에 따른 디지털 워터마킹 기술의 흐름을 나타낸 도면이다.
도 51은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과 포맷을 나타낸 도면이다.
도 52는 본 발명의 일 실시예에 따른 콘텐츠 식별자의 구문(syntax)을 나타낸 도면이다.
도 53는 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
도 54은 본 발명의 또 다른 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
도 55은 본 발명의 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
도 56은 본 발명의 다른 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
도 57는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 58은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 59은 본 발명의 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 60는 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 61은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 62는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 63는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 64은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 65는 본 발명의 또 다른 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 66는 본 발명의 또 다른 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 67는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 68는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 69는 본 발명의 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 70은 본 발명의 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 71은 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 72는 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 73은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 74는 본 발명의 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 75는 본 발명의 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 76은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 77은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 78은 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 79는 본 발명의 다른 일 실시예에 따른 FDT 경우의 XML 스키마를 나타낸 도면이다.
도 80은 본 발명의 일 실시예에 따른 캐퍼빌리티 기술어 구문을 나타낸 도면이다.
도 81은 본 발명의 일 실시예에 따른 소비 모델을 나타낸 도면이다.
도 82는 본 발명의 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
도 83은 본 발명의 다른 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
도 84는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 85는 본 발명의 일 실시예에 따른 HTTP 요청 테이블을 나타낸 도면이다.
도 86은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트이다.
도 87은 본 발명의 일 실시예에 따른 URL 리스트 테이블을 나타낸 도면이다.
도 88은 본 발명의 일 실시예에 따른 TPT를 나타낸 도면이다.
도 89는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 90은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 91은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 92는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 93은 본 발명의 일 실시예에 따른 수신기 대상 기준 테이블을 나타낸 도면이다.
도 94는 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 95는 본 발명의 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 96은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 97은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 98은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 99는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 100은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 101은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 102는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 103는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 104는 본 발명의 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 105는 본 발명의 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 106은 본 발명의 또 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 107 은 본 발명의 일 실시예에 따른, 차세대 방송 시스템을 위한 프로토콜 스택 (Protocol Stack) 을 도시한 도면이다.
도 108 은 본 발명의 일 실시예에 따른 UPnP 방식의 액션(Action) 메커니즘을 도시한 도면이다.
도 109 은 본 발명의 일 실시예에 따른 REST 메커니즘을 도시한 도면이다.
도 110 는 본 발명의 일 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 111 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 112 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 다른 일부를 도시한 도면이다.
도 113 는 본 발명의 일 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
도 114 은 본 발명의 일 실시예에 따른 UserData 서비스의 상태변수(state variable)들을 도시한 도면이다.
도 115 는 본 발명의 일 실시예에 따른 UserDataList 의 XML 구조를 도시한 도면이다.
도 116 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션(action)들을 도시한 도면이다.
도 117 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetPDIUserDataProtocolVersion 를 설명하는 도면이다.
도 118 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetUserDataIdsList 와 GetUserData 를 설명하는 도면이다.
도 119 은 본 발명의 일 실시예에 따른 UserData 서비스의 확장된 상태변수를 도시한 도면이다.
도 120 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, SetUserData 를 설명하는 도면이다.
도 121 은 본 발명의 일 실시예에 따른, UserData 서비스의 추가된 상태변수를 도시한 도면이다.
도 122 은 본 발명의 일 실시예에 따른, UserData 서비스의 또 다른 추가된 상태변수를 도시한 도면이다.
도 123 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 상태변수들을 도시한 도면이다.
도 124 은 본 발명의 일 실시예에 따른 UserDataQAList 의 XML 구조를 도시한 도면이다.
도 125 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션(action)들을 도시한 도면이다.
도 126 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션들 중, GetUserDataQAIdsList 와 GetUserDataQA 를 설명하는 도면이다.
도 127 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어 단위 전달을 위한, UserData 서비스의 액션들 중, SetUserDataQA 를 설명하는 도면이다.
도 128 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
도 129 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 상태변수를 도시한 도면이다.
도 130 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 액션을 설명한 도면이다.
도 131 은 본 발명의 일 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
도 132 은 본 발명의 다른 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
도 133 는 본 발명의 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 134 은 본 발명의 다른 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
도 135 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
도 136 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 액션을 설명한 도면이다.
도 137 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
도 138 은 본 발명의 일 실시예에 따른, FC가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
도 139 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 액션을 설명한 도면이다.
도 140 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
도 141 은 본 발명의 다른 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
도 142 은 본 발명의 일 실시예에 따른 방송 수신기를 나타낸 도면이다.
도 143 는 본 발명의 다른 실시예에 따른 방송 수신기를 나타낸 도면이다.
도 144 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 를 도시한 도면이다.
도 145 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 146 는 본 발명의 다른 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 147 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, caption_service_descriptor 의 확장된 필드들을 도시한 도면이다.
도 148 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 149 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 150 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 폰트에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 151 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 글자 크기에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 152 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 정렬에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 153 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 프린트되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 154 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 스크롤되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 155 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 이지 리더(easy reader) 모드에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 156 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 157 는 본 발명의 다른 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 158 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, AC-3_audio_stream_descriptor 의 확장된 필드들을 도시한 도면이다.
도 159 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 160 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 청각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 161 은 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 시각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 162 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
도 163 은 본 발명의 다른 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
도 164 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)에 있어서, sign_language_descriptor 를 도시한 도면이다.
도 165 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 접근성&수화 프리젠테이션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 166 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화 언어의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 167 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화의 위치의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 168 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 에 있어서, 답변의 업데이트를 위한 메뉴 화면을 도시한 도면이다.
도 169 은 본 발명의 또 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 170 는 본 발명의 일 실시예에 따른, 유저 ID 필드를 더 포함하는 PDIUserData 를 도시한 도면이다.
도 171 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 PDI Question 에 대한 답변을 얻는 시퀀스 다이어그램을 도시한 도면이다.
도 172 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 필터링 크리테리아를 적용하는 시퀀스 다이어그램을 도시한 도면이다.
도 173 는 본 발명의 일 실시예에 따른, 유저 ID 를 할당하는 방법을 도시한 도면이다.
도 174 는 자동답변에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 175 은 재답변 인터벌에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 176 는 자동답변 가능한 질문을 보충 질문으로 대체하기 위한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 177 는 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 보충 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
도 178 은 자동답변 가능한 질문을 대체 질문으로 대체하기 위한 ID 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 179 은 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 대체 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
도 180 은 컨텐츠 히스토리 엔진을 더 포함하는, 본 발명의 또 다른 실시예에 따른 수신기를 도시한 도면이다.
도 181 는 본 발명의 또 다른 실시예에 따른 방송 수신기의 구조를 도시한 도면이다.
도 182 은 본 발명의 일 실시예에 따른 컨텐츠 히스토리 테이블을 도시한 도면이다.
도 183 은 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 필터링 크리테리아를 도시한 도면이다.
도 184 는 본 발명의 일 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
도 185 은 본 발명의 다른 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
도 186 는 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 간략화된 필터링 크리테리아를 도시한 도면이다.
도 187 는 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 일부를 도시한 도면이다.
도 188 은 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 다른 일부를 도시한 도면이다.
도 189 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 테이블 및 필터링 크리테리아를 이용한 개인화된 서비스를 제공하는 시퀀스 다이어그램을 도시한 도면이다.
도 190 은 카운트 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
도 191 는 문턱값 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
도 192 은 문턱값 정보를 포함하는 필터링 크리테리아에 있어서, 본 발명의 일 실시예에 따른 비교 과정을 도시한 도면이다.
도 193 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 PDI 유저 데이터를 통해 전달되는 경우의 시퀀스 다이어그램을 도시한 도면이다.
도 194 는 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 PDI 유저 데이터를 통해 전달되는 경우의 PDI 유저 데이터의 구조를 도시한 도면이다.
도 195 는 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 PDI 유저 데이터를 통해 전달되는 경우의 컨텐츠 히스토리 정보 및 PDI 유저 데이터의 예시를 도시한 도면이다.
도 196 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 필터링 크리테리아를 통해 전달되는 경우의 시퀀스 다이어그램을 도시한 도면이다.
도 197 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 필터링 크리테리아를 통해 전달되는 경우의 필터링 크리테리아의 구조를 도시한 도면이다.
도 198 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 필터링 크리테리아를 통해 전달되는 경우의 필터링 크리테리아의 예시를 도시한 도면이다.
도 199 는 본 발명의 일 실시예에 따른, 휴리스틱 방법에 따라 컨텐츠 히스토리 정보를 단순화한 경우를 도시한 도면이다.
도 200 은 본 발명의 일 실시예에 따른, 휴리스틱 방법에 따라 단순화한 컨텐츠 히스토리 정보에 근거해 PDI 유저 데이터를 수집하는 과정을 도시한 도면이다(PDI 유저데이터를 통해 기준정보 전달).
도 201 은 본 발명의 일 실시예에 따른, 휴리스틱 방법에 따라 단순화한 컨텐츠 히스토리 정보에 근거해 PDI 유저 데이터를 수집하는 과정을 도시한 도면이다(필터링 크리테리아를 통해 기준정보 전달).
도 202 는 본 발명의 일 실시예에 따른, ACR 상황에서 컨텐츠 히스토리 정보에 근거해 PDI 유저 데이터를 수집하는 과정을 도시한 도면이다.
도 203 은 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법을 도시한 도면이다.
도 204 는 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방송 수신기를 도시한 도면이다.
발명의 실시를 위한 최선의 형태
본 발명의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 본 발명의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 본 발명의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 본 발명에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 본 발명이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
본 발명에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 본 발명은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
본 발명은 차세대 방송 서비스에 대한 방송 신호 송신 및 수신 장치 및 방법을 제공한다. 본 발명의 일 실시예에 따른 차세대 방송 서비스는 지상파 방송 서비스, 모바일 방송 서비스, UHDTV 서비스 등을 포함한다. 본 발명은 일 실시예에 따라 비-MIMO (non-Multiple Input Multiple Output) 또는 MIMO 방식을 통해 차세대 방송 서비스에 대한 방송 신호를 처리할 수 있다. 본 발명의 일 실시예에 따른 비-MIMO 방식은 MISO (Multiple Input Single Output) 방식, SISO (Single Input Single Output) 방식 등을 포함할 수 있다.
이하에서는 설명의 편의를 위해 MISO 또는 MIMO 방식은 두 개의 안테나를 사용하지만, 본 발명은 두 개 이상의 안테나를 사용하는 시스템에 적용될 수 있다. 본 발명은 특정 용도에 요구되는 성능을 달성하면서 수신기 복잡도를 최소화하기 위해 최적화된 세 개의 피지컬 프로파일(PHY profile) (베이스(base), 핸드헬드(handheld), 어드벤스(advanced) 프로파일)을 정의할 수 있다. 피지컬 프로파일은 해당하는 수신기가 구현해야 하는 모든 구조의 서브셋이다.
세 개의 피지컬 프로파일은 대부분의 기능 블록을 공유하지만, 특정 블록 및/또는 파라미터에서는 약간 다르다. 추후에 추가로 피지컬 프로파일이 정의될 수 있다. 시스템 발전을 위해, 퓨처 프로파일은 FEF (future extension frame)을 통해 단일 RF (radio frequency) 채널에 존재하는 프로파일과 멀티플렉싱 될 수도 있다. 각 피지컬 프로파일에 대한 자세한 내용은 후술한다.
1. 베이스 프로파일
베이스 프로파일은 주로 루프 톱(roof-top) 안테나와 연결되는 고정된 수신 장치의 주된 용도를 나타낸다. 베이스 프로파일은 어떤 장소로 이동될 수 있지만 비교적 정지된 수신 범주에 속하는 휴대용 장치도 포함할 수 있다. 베이스 프로파일의 용도는 약간의 개선된 실행에 의해 핸드헬드 장치 또는 차량용으로 확장될 수 있지만, 이러한 사용 용도는 베이스 프로파일 수신기 동작에서는 기대되지 않는다.
수신의 타겟 신호 대 잡음비 범위는 대략 10 내지 20 dB인데, 이는 기존 방송 시스템(예를 들면, ATSC A/53)의 15 dB 신호 대 잡음비 수신 능력을 포함한다. 수신기 복잡도 및 소비 전력은 핸드헬드 프로파일을 사용할 배터리로 구동되는 핸드헬드 장치에서만큼 중요하지 않다. 베이스 프로파일에 대한 중요 시스템 파라미터가 아래 표 1에 기재되어 있다.
Figure pct00001
2. 핸드헬드 프로파일
핸드헬드 프로파일은 배터리 전원으로 구동되는 핸드헬드 및 차량용 장치에서의 사용을 위해 설계된다. 해당 장치는 보행자 또는 차량 속도로 이동할 수 있다. 수신기 복잡도뿐만 아니라 소비 전력은 핸드헬드 프로파일의 장치의 구현을 위해 매우 중요하다. 핸드헬드 프로파일의 타겟 신호 대 잡음비 범위는 대략 0 내지 10 dB이지만, 더 낮은 실내 수신을 위해 의도된 경우 0 dB 아래에 달하도록 설정될 수 있다.
저 신호 대 잡음비 능력뿐만 아니라, 수신기 이동성에 의해 나타난 도플러 효과에 대한 복원력은 핸드헬드 프로파일의 가장 중요한 성능 속성이다. 핸드헬드 프로파일에 대한 중요 시스템 파라미터가 아래 표 2에 기재되어 있다.
Figure pct00002
3. 어드벤스 프로파일
어드벤스 프로파일은 더 큰 실행 복잡도에 대한 대가로 더 높은 채널 능력을 제공한다. 해당 프로파일은 MIMO 송신 및 수신을 사용할 것을 요구하며, UHDTV 서비스는 타겟 용도이고, 이를 위해 해당 프로파일이 특별히 설계된다. 향상된 능력은 주어진 대역폭에서 서비스 수의 증가, 예를 들면, 다수의 SDTV 또는 HDTV 서비스를 허용하는 데도 사용될 수 있다.
어드벤스 프로파일의 타겟 신호 대 잡음비 범위는 대략 20 내지 30 dB이다. MIMO 전송은 초기에는 기존의 타원 분극 전송 장비를 사용하고, 추후에 전출력 교차 분극 전송으로 확장될 수 있다. 어드벤스 프로파일에 대한 중요 시스템 파라미터가 아래 표 3에 기재되어 있다.
Figure pct00003
이 경우, 베이스 프로파일은 지상파 방송 서비스 및 모바일 방송 서비스 모두에 대한 프로파일로 사용될 수 있다. 즉, 베이스 프로파일은 모바일 프로파일을 포함하는 프로파일의 개념을 정의하기 위해 사용될 수 있다. 또한, 어드벤스 프로파일은 MIMO을 갖는 베이스 프로파일에 대한 어드벤스 프로파일 및 MIMO을 갖는 핸드헬드 프로파일에 대한 어드벤스 프로파일로 구분될 수 있다. 그리고 해당 세 프로파일은 설계자의 의도에 따라 변경될 수 있다.
다음의 용어 및 정의는 본 발명에 적용될 수 있다. 다음의 용어 및 정의는 설계에 따라 변경될 수 있다.
보조 스트림: 퓨처 익스텐션(future extension, 추후 확장) 또는 방송사나 네트워크 운영자에 의해 요구됨에 따라 사용될 수 있는 아직 정의되지 않은 변조 및 코딩의 데이터를 전달하는 셀의 시퀀스
베이스 데이터 파이프(base data pipe): 서비스 시그널링 데이터를 전달하는 데이터 파이프
베이스밴드 프레임 (또는 BBFRAME): 하나의 FEC 인코딩 과정 (BCH 및 LDPC 인코딩)에 대한 입력을 형성하는 Kbch 비트의 집합
셀(cell): OFDM 전송의 하나의 캐리어에 의해 전달되는 변조값
코딩 블록(coded block): PLS1 데이터의 LDPC 인코딩된 블록 또는 PLS2 데이터의 LDPC 인코딩된 블록들 중 하나
데이터 파이프(data pipe): 하나 또는 다수의 서비스 또는 서비스 컴포넌트를 전달할 수 있는 서비스 데이터 또는 관련된 메타데이터를 전달하는 물리 계층(physical layer)에서의 로지컬 채널
데이터 파이프 유닛(DPU, data pipe unit): 데이터 셀을 프레임에서의 데이터 파이프에 할당할 수 있는 기본 유닛
데이터 심볼(data symbol): 프리앰블 심볼이 아닌 프레임에서의 OFDM 심볼 (프레임 시그널링 심볼 및 프레임 엣지(edge) 심볼은 데이터 심볼에 포함된다.)
DP_ID: 해당 8비트 필드는 SYSTEM_ID에 의해 식별된 시스템 내에서 데이터 파이프를 유일하게 식별한다.
더미 셀(dummy cell): PLS (physical layer signalling) 시그널링, 데이터 파이프, 또는 보조 스트림을 위해 사용되지 않은 남아 있는 용량을 채우는 데 사용되는 의사 랜덤값을 전달하는 셀
FAC (emergency alert channel, 비상 경보 채널): EAS 정보 데이터를 전달하는 프레임 중 일부
프레임(frame): 프리앰블로 시작해서 프레임 엣지 심볼로 종료되는 물리 계층(physical layer) 타임 슬롯
프레임 리피티션 유닛(frame repetition unit, 프레임 반복 단위): 슈퍼 프레임(super-frame)에서 8회 반복되는 FEF를 포함하는 동일한 또는 다른 피지컬 프로파일에 속하는 프레임의 집합
FIC (fast information channel, 고속 정보 채널): 서비스와 해당 베이스 데이터 파이프 사이에서의 매핑 정보를 전달하는 프레임에서 로지컬 채널
FECBLOCK: 데이터 파이프 데이터의 LDPC 인코딩된 비트의 집합
FFT 사이즈: 기본 주기 T의 사이클로 표현된 액티브 심볼 주기 Ts와 동일한 특정 모드에 사용되는 명목상의 FFT 사이즈
프레임 시그널링 심볼(frame signaling symbol): PLS 데이터의 일부를 전달하는, FFT 사이즈, 가드 인터벌(guard interval), 및 스캐터(scattered) 파일럿 패턴의 특정 조합에서 프레임의 시작에서 사용되는 더 높은 파일럿 밀도를 갖는 OFDM 심볼
프레임 엣지 심볼(frame edge symbol): FFT 사이즈, 가드 인터벌, 및 스캐터 파일럿 패턴의 특정 조합에서 프레임의 끝에서 사용되는 더 높은 파일럿 밀도를 갖는 OFDM 심볼
프레임 그룹(frame-group): 슈퍼 프레임에서 동일한 피지컬 프로파일 타입을 갖는 모든 프레임의 집합
퓨쳐 익스텐션 프레임(future extention frame, 추후 확장 프레임): 프리앰블로 시작하는, 추후 확장에 사용될 수 있는 슈퍼 프레임 내에서 물리 계층(physical layer) 타임 슬롯
퓨처캐스트(futurecast) UTB 시스템: 입력이 하나 이상의 MPEG2-TS 또는 IP (Internet protocol) 또는 일반 스트림이고 출력이 RF 시그널인 제안된 물리 계층(physical layer) 방송 시스템
인풋 스트림(input stream, 입력 스트림): 시스템에 의해 최종 사용자에게 전달되는 서비스의 조화(ensemble)를 위한 데이터의 스트림
노멀(normal) 데이터 심볼: 프레임 시그널링 심볼 및 프레임 엣지 심볼을 제외한 데이터 심볼
피지컬 프로파일(PHY profile): 해당하는 수신기가 구현해야 하는 모든 구조의 서브셋
PLS: PLS1 및 PLS2로 구성된 물리 계층(physical layer) 시그널링 데이터
PLS1: PLS2를 디코딩하는 데 필요한 파라미터뿐만 아니라 시스템에 관한 기본 정보를 전달하는 고정된 사이즈, 코딩, 변조를 갖는 FSS (frame signalling symbol)로 전달되는 PLS 데이터의 첫 번째 집합
NOTE: PLS1 데이터는 프레임 그룹의 듀레이션(duration) 동안 일정하다.
PLS2: 데이터 파이프 및 시스템에 관한 더욱 상세한 PLS 데이터를 전달하는 FSS로 전송되는 PLS 데이터의 두 번째 집합
PLS2 다이나믹(dynamic, 동적) 데이터: 프레임마다 다이나믹(dynamic, 동적)으로 변화하는 PLS2 데이터
PLS2 스태틱(static, 정적) 데이터: 프레임 그룹의 듀레이션 동안 스태틱(static, 정적)인 PLS2 데이터
프리앰블 시그널링 데이터(preamble signaling data): 프리앰블 심볼에 의해 전달되고 시스템의 기본 모드를 확인하는 데 사용되는 시그널링 데이터
프리앰블 심볼(preamble symbol): 기본 PLS 데이터를 전달하고 프레임의 시작에 위치하는 고정된 길이의 파일럿 심볼
NOTE: 프리앰블 심볼은 시스템 신호, 그 타이밍, 주파수 오프셋, 및 FFT 사이즈를 검출하기 위해 고속 초기 밴드 스캔에 주로 사용된다.
추후 사용(future use)을 위해 리저브드(reserved): 현재 문서에서 정의되지 않지만 추후에 정의될 수 있음
슈퍼 프레임(superframe): 8개의 프레임 반복 단위의 집합
타임 인터리빙 블록(time interleaving block, TI block): 타임 인터리버 메모리의 하나의 용도에 해당하는, 타임 인터리빙이 실행되는 셀의 집합
타임 인터리빙 그룹(time interleaving group, TI group): 정수, 다이나믹(dynamic, 동적)으로 변화하는 XFECBLOCK의 수로 이루어진, 특정 데이터 파이프에 대한 다이나믹(dynamic, 동적) 용량 할당이 실행되는 단위
NOTE: 타임 인터리빙 그룹은 하나의 프레임에 직접 매핑되거나 다수의 프레임에 매핑될 수 있다. 타임 인터리빙 그룹은 하나 이상의 타임 인터리빙 블록을 포함할 수 있다.
타입 1 데이터 파이프(Type 1 DP): 모든 데이터 파이프가 프레임에 TDM (time division multiplexing) 방식으로 매핑되는 프레임의 데이터 파이프
타입 2 데이터 파이프(Type 2 DP): 모든 데이터 파이프가 프레임에 FDM 방식으로 매핑되는 프레임의 데이터 파이프
XFECBLOCK: 하나의 LDPC FECBLOCK의 모든 비트를 전달하는 Ncells 셀들의 집합
도 1은 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치의 구조를 나타낸다.
본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치는 인풋 포맷 블록 (Input Format block) (1000), BICM (bit interleaved coding & modulation) 블록(1010), 프레임 빌딩 블록 (Frame building block) (1020), OFDM (orthogonal frequency division multiplexing) 제너레이션 블록 (OFDM generation block)(1030), 및 시그널링 생성 블록(1040)을 포함할 수 있다. 방송 신호 송신 장치의 각 블록의 동작에 대해 설명한다.
IP 스트림/패킷 및 MPEG2-TS은 주요 입력 포맷이고, 다른 스트림 타입은 일반 스트림으로 다루어진다. 이들 데이터 입력에 추가로, 관리 정보가 입력되어 각 입력 스트림에 대한 해당 대역폭의 스케줄링 및 할당을 제어한다. 하나 또는 다수의 TS 스트림, IP 스트림 및/또는 일반 스트림 입력이 동시에 허용된다.
인풋 포맷 블록(1000)은 각각의 입력 스트림을 독립적인 코딩 및 변조가 적용되는 하나 또는 다수의 데이터 파이프로 디멀티플렉싱 할 수 있다. 데이터 파이프는 견고성(robustness) 제어를 위한 기본 단위이며, 이는 QoS (Quality of Service)에 영향을 미친다. 하나 또는 다수의 서비스 또는 서비스 컴포넌트가 하나의 데이터 파이프에 의해 전달될 수 있다. 인풋 포맷 블록(1000)의 자세한 동작은 후술한다.
데이터 파이프는 하나 또는 다수의 서비스 또는 서비스 컴포넌트를 전달할 수 있는 서비스 데이터 또는 관련 메타데이터를 전달하는 물리 계층(physical layer)에서의 로지컬 채널이다.
또한, 데이터 파이프 유닛은 하나의 프레임에서 데이터 셀을 데이터 파이프에 할당하기 위한 기본 유닛이다.
인풋 포맷 블록(1000)에서, 패리티(parity) 데이터는 에러 정정을 위해 추가되고, 인코딩된 비트 스트림은 복소수값 컨스텔레이션 심볼에 매핑된다. 해당 심볼은 해당 데이터 파이프에 사용되는 특정 인터리빙 깊이에 걸쳐 인터리빙 된다. 어드벤스 프로파일에 있어서, BICM 블록(1010)에서 MIMO 인코딩이 실행되고 추가 데이터 경로가 MIMO 전송을 위해 출력에 추가된다. BICM 블록(1010)의 자세한 동작은 후술한다.
프레임 빌딩 블록(1020)은 하나의 프레임 내에서 입력 데이터 파이프의 데이터 셀을 OFDM 실볼로 매핑할 수 있다. 매핑 후, 주파수 영역 다이버시티를 위해, 특히 주파수 선택적 페이딩 채널을 방지하기 위해 주파수 인터리빙이 이용된다. 프레임 빌딩 블록(1020)의 자세한 동작은 후술한다.
프리앰블을 각 프레임의 시작에 삽입한 후, OFDM 제너레이션 블록(1030)은 사이클릭 프리픽스(cyclic prefix)을 가드 인터벌로 갖는 기존의 OFDM 변조를 적용할 수 있다. 안테나 스페이스 다이버시티를 위해, 분산된(distributed) MISO 방식이 송신기에 걸쳐 적용된다. 또한, PAPR (peak-to-average power ratio) 방식이 시간 영역에서 실행된다. 유연한 네트워크 방식을 위해, 해당 제안은 다양한 FFT 사이즈, 가드 인터벌 길이, 해당 파일럿 패턴의 집합을 제공한다. OFDM 제너레이션 블록(1030)의 자세한 동작은 후술한다.
시그널링 생성 블록(1040)은 각 기능 블록의 동작에 사용되는 물리 계층(physical layer) 시그널링 정보를 생성할 수 있다. 해당 시그널링 정보는 또한 관심 있는 서비스가 수신기 측에서 적절히 복구되도록 전송된다. 시그널링 생성 블록(1040)의 자세한 동작은 후술한다.
도 2, 3, 4는 본 발명의 실시예에 따른 인풋 포맷 블록(1000)을 나타낸다. 각 도면에 대해 설명한다.
도 2는 본 발명의 일 실시예에 따른 인풋 포맷 블록을 나타낸다. 도 2는 입력 신호가 단일 입력 스트림(single input stream)일 때의 인풋 포맷 블록을 나타낸다.
도 2에 도시된 인풋 포맷 블록은 도 1을 참조하여 설명한 인풋 포맷 블록(1000)의 일 실시예에 해당한다.
물리 계층(physical layer)으로의 입력은 하나 또는 다수의 데이터 스트림으로 구성될 수 있다. 각각의 데이터 스트림은 하나의 데이터 파이프에 의해 전달된다. 모드 어댑테이션(mode adaptaion, 모드 적응) 모듈은 입력되는 데이터 스트림을 BBF (baseband frame)의 데이터 필드로 슬라이스한다. 해당 시스템은 세 가지 종류의 입력 데이터 스트림, 즉 MPEG2-TS, IP, GS (generic stream)을 지원한다. MPEG2-TS는 첫 번째 바이트가 동기 바이트(0x47)인 고정된 길이(188 바이트)의 패킷을 특징으로 한다. IP 스트림은 IP 패킷 헤더 내에서 시그널링 되는 가변 길이 IP 데이터그램 패킷으로 구성된다. 해당 시스템은 IP 스트림에 대해 IPv4와 IPv6을 모두 지원한다. GS는 캡슐화 패킷 헤더 내에서 시그널링되는 가변 길이 패킷 또는 일정 길이 패킷으로 구성될 수 있다.
(a)는 신호 데이터 파이프에 대한 모드 어댑테이션(mode adaptaion, 모드 적응) 블록(2000) 및 스트림 어댑테이션(stream adaptation, 스트림 적응)(2010)을 나타내고, (b)는 PLS 데이터를 생성 및 처리하기 위한 PLS 생성 블록(2020) 및 PLS 스크램블러(2030)를 나타낸다. 각 블록의 동작에 대해 설명한다.
입력 스트림 스플리터는 입력된 TS, IP, GS 스트림을 다수의 서비스 또는 서비스 컴포넌트(오디오, 비디오 등) 스트림으로 분할한다. 모드 어댑테이션(mode adaptaion, 모드 적응) 모듈(2010)은 CRC 인코더, BB (baseband) 프레임 슬라이서, 및 BB 프레임 헤더 삽입 블록으로 구성된다.
CRC 인코더는 유저 패킷 (user packet, UP)레벨에서의 에러 검출을 위한 세 종류의 CRC 인코딩, 즉 CRC-8, CRC-16, CRC-32를 제공한다. 산출된 CRC 바이트는 UP 뒤에 첨부된다. CRC-8은 TS 스트림에 사용되고, CRC-32는 IP 스트림에 사용된다. GS 스트림이 CRC 인코딩을 제공하지 않으면, 제안된 CRC 인코딩이 적용되어야 한다.
BB 프레임 슬라이서는 입력을 내부 로지컬 비트 포맷에 매핑한다. 첫 번째 수신 비트는 MSB라고 정의한다. BB 프레임 슬라이서는 가용 데이터 필드 용량과 동일한 수의 입력 비트를 할당한다. BBF 페이로드와 동일한 수의 입력 비트를 할당하기 위해, UP 스트림이 BBF의 데이터 필드에 맞게 슬라이스된다.
BB 프레임 헤더 삽입 블록은 2바이트의 고정된 길이의 BBF 헤더를 BB 프레임의 앞에 삽입할 수 있다. BBF 헤더는 STUFFI (1비트), SYNCD (13비트), 및 RFU (2비트)로 구성된다. 고정된 2바이트 BBF 헤더뿐만 아니라, BBF는 2바이트 BBF 헤더 끝에 확장 필드(1 또는 3바이트)를 가질 수 있다.
스트림 어댑테이션(stream adaptation, 스트림 적응)(2010)은 스터핑(stuffing) 삽입 블록 및 BB 스크램블러로 구성된다. 스터핑 삽입 블록은 스터핑 필드를 BB 프레임의 페이로드에 삽입할 수 있다. 스트림 어댑테이션(stream adaptation, 스트림 적응)에 대한 입력 데이터가 BB 프레임을 채우기에 충분하면, STUFFI는 0으로 설정되고, BBF는 스터핑 필드를 갖지 않는다. 그렇지 않으면, STUFFI는 1로 설정되고, 스터핑 필드는 BBF 헤더 직후에 삽입된다. 스터핑 필드는 2바이트의 스터핑 필드 헤더 및 가변 사이즈의 스터핑 데이터를 포함한다.
BB 스크램블러는 에너지 분산을 위해 완전한 BBF를 스크램블링한다. 스크램블링 시퀀스는 BBF와 동기화된다. 스크램블링 시퀀스는 피드백 시프트 레지스터에 의해 생성된다.
PLS 생성 블록(2020)은 PLS 데이터를 생성할 수 있다. PLS는 수신기에서 피지컬 레이어(physical layer) 데이터 파이프에 접속할 수 있는 수단을 제공한다. PLS 데이터는 PLS1 데이터 및 PLS2 데이터로 구성된다.
PLS1 데이터는 PLS2 데이터를 디코딩하는 데 필요한 파라미터뿐만 아니라 시스템에 관한 기본 정보를 전달하는 고정된 사이즈, 코딩, 변조를 갖는 프레임에서 FSS로 전달되는 PLS 데이터의 첫 번째 집합이다. PLS1 데이터는 PLS2 데이터의 수신 및 디코딩을 가능하게 하는 데 요구되는 파라미터를 포함하는 기본 송신 파라미터를 제공한다. 또한, PLS1 데이터는 프레임 그룹의 듀레이션 동안 일정하다.
PLS2 데이터는 데이터 파이프 및 시스템에 관한 더욱 상세한 PLS 데이터를 전달하는 FSS로 전송되는 PLS 데이터의 두 번째 집합이다. PLS2는 수신기가 원하는 데이터 파이프를 디코딩하는 데 충분한 정보를 제공하는 파라미터를 포함한다. PLS2 시그널링은 PLS2 스태틱(static, 정적) 데이터(PLS2-STAT 데이터) 및 PLS2 다이나믹(dynamic, 동적) 데이터(PLS2-DYN 데이터)의 두 종류의 파라미터로 더 구성된다. PLS2 스태틱(static, 정적) 데이터는 프레임 그룹의 듀레이션 동안 스태틱(static, 정적)인 PLS2 데이터이고, PLS2 다이나믹(dynamic, 동적) 데이터는 프레임마다 다이나믹(dynamic, 동적)으로 변화하는 PLS2 데이터이다.
PLS 데이터에 대한 자세한 내용은 후술한다.
PLS 스크램블러(2030)는 에너지 분산을 위해 생성된 PLS 데이터를 스크램블링 할 수 있다.
전술한 블록은 생략될 수도 있고 유사 또는 동일 기능을 갖는 블록에 의해 대체될 수도 있다.
도 3은 본 발명의 다른 일 실시예에 따른 인풋 포맷 블록을 나타낸다.
도 3에 도시된 인풋 포맷 블록은 도 1을 참조하여 설명한 인풋 포맷 블록(1000)의 일 실시예에 해당한다.
도 3은 입력 신호가 멀티 인풋 스트림(multi input stream, 다수의 입력 스트림)에 해당하는 경우 인풋 포맷 블록의 모드 어댑테이션(mode adaptaion, 모드 적응) 블록을 나타낸다.
멀티 인풋 스트림(multi input stream, 다수의 입력 스트림)을 처리하기 위한 인풋 포맷 블록의 모드 어댑테이션(mode adaptaion, 모드 적응) 블록은 다수 입력 스트림을 독립적으로 처리할 수 있다.
도 3을 참조하면, 멀티 인풋 스트림(multi input stream, 다수의 입력 스트림)을 각각 처리하기 위한 모드 어댑테이션(mode adaptaion, 모드 적응) 블록은 인풋 스트림 스플리터 (input stream splitter) (3000), 인풋 스트림 싱크로나이저 (input stream synchronizer) (3010), 컴펜세이팅 딜레이(compensatin delay, 보상 지연) 블록(3020), 널 패킷 딜리션 블록 (null packet deletion block) (3030), 헤더 컴프레션 블록 (header compression block) (3040), CRC 인코더 (CRC encoder) (3050), BB 프레임 슬라이서(BB frame slicer) (3060), 및 BB 헤더 삽입 블록 (BB header insertion block) (3070)을 포함할 수 있다. 모드 어댑테이션(mode adaptaion, 모드 적응) 블록의 각 블록에 대해 설명한다.
CRC 인코더(3050), BB 프레임 슬라이서(3060), 및 BB 헤더 삽입 블록(3070)의 동작은 도 2를 참조하여 설명한 CRC 인코더, BB 프레임 슬라이서, 및 BB 헤더 삽입 블록의 동작에 해당하므로, 그 설명은 생략한다.
인풋 스트림 스플리터(3000)는 입력된 TS, IP, GS 스트림을 다수의 서비스 또는 서비스 컴포넌트(오디오, 비디오 등) 스트림으로 분할한다.
인풋 스트림 싱크로나이저(3010)는 ISSY라 불릴 수 있다. ISSY는 어떠한 입력 데이터 포맷에 대해서도 CBR (constant bit rate) 및 일정한 종단간 전송(end-to-end transmission) 지연을 보장하는 적합한 수단을 제공할 수 있다. ISSY는 TS를 전달하는 다수의 데이터 파이프의 경우에 항상 이용되고, GS 스트림을 전달하는 다수의 데이터 파이프에 선택적으로 이용된다.
컴펜세이팅 딜레이(compensatin delay, 보상 지연) 블록(3020)은 수신기에서 추가로 메모리를 필요로 하지 않고 TS 패킷 재결합 메커니즘을 허용하기 위해 ISSY 정보의 삽입에 뒤따르는 분할된 TS 패킷 스트림을 지연시킬 수 있다.
널 패킷 딜리션 블록(3030)은 TS 입력 스트림 경우에만 사용된다. 일부 TS 입력 스트림 또는 분할된 TS 스트림은 VBR (variable bit-rate) 서비스를 CBR TS 스트림에 수용하기 위해 존재하는 많은 수의 널 패킷을 가질 수 있다. 이 경우, 불필요한 전송 오버헤드를 피하기 위해, 널 패킷은 확인되어 전송되지 않을 수 있다. 수신기에서, 제거된 널 패킷은 전송에 삽입된 DNP(deleted null-packet, 삭제된 널 패킷) 카운터를 참조하여 원래 존재했던 정확한 장소에 재삽입될 수 있어, CBR이 보장되고 타임 스탬프(PCR) 갱신의 필요가 없어진다.
헤더 컴프레션 블록(3040)은 TS 또는 IP 입력 스트림에 대한 전송 효율을 증가시키기 위해 패킷 헤더 압축을 제공할 수 있다. 수신기는 헤더의 특정 부분에 대한 선험적인(a priori) 정보를 가질 수 있기 때문에, 이 알려진 정보(known information)는 송신기에서 삭제될 수 있다.
TS에 대해, 수신기는 동기 바이트 구성(0x47) 및 패킷 길이(188 바이트)에 관한 선험적인 정보를 가질 수 있다. 입력된 TS가 하나의 PID만을 갖는 콘텐트를 전달하면, 즉, 하나의 서비스 컴포넌트(비디오, 오디오 등) 또는 서비스 서브 컴포넌트(SVC 베이스 레이어, SVC 인헨스먼트 레이어, MVC 베이스 뷰, 또는 MVC 의존 뷰)에 대해서만, TS 패킷 헤더 압축이 TS에 (선택적으로) 적용될 수 있다. TS 패킷 헤더 압축은 입력 스트림이 IP 스트림인 경우 선택적으로 사용된다. 상기 블록은 생략되거나 유사 또는 동일 기능을 갖는 블록으로 대체될 수 있다.
도 4는 본 발명의 일 실시예에 따른 BICM 블록을 나타낸다.
도 4에 도시된 BICM 블록은 도 1을 참조하여 설명한 BICM 블록(1010)의 일 실시예에 해당한다.
전술한 바와 같이, 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치는 지상파 방송 서비스, 모바일 방송 서비스, UHDTV 서비스 등을 제공할 수 있다.
QoS가 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치에 의해 제공되는 서비스의 특성에 의존하므로, 각각의 서비스에 해당하는 데이터는 서로 다른 방식을 통해 처리되어야 한다. 따라서, 본 발명의 일 실시예에 따른 BICM 블록은 SISO, MISO, MIMO 방식을 각각의 데이터 경로에 해당하는 데이터 파이프에 독립적으로 적용함으로써 각데이터 파이프를 독립적으로 처리할 수 있다. 결과적으로, 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치는 각각의 데이터 파이프를 통해 전송되는 각 서비스 또는 서비스 컴포넌트에 대한 QoS를 조절할 수 있다.
(a)는 베이스 프로파일 및 핸드헬드 프로파일에 의해 공유되는 BICM 블록을 나타내고, (b)는 어드벤스 프로파일의 BICM 블록을 나타낸다.
베이스 프로파일 및 핸드헬드 프로파일에 의해 공유되는 BICM 블록 및 어드벤스 프로파일의 BICM 블록은 각각의 데이터 파이프를 처리하기 위한 복수의 처리 블록을 포함할 수 있다.
베이스 프로파일 및 핸드헬드 프로파일에 대한 BICM 블록 및 어드벤스 프로파일에 대한 BICM 블록의 각각의 처리 블록에 대해 설명한다.
베이스 프로파일 및 핸드헬드 프로파일에 대한 BICM 블록의 처리 블록(5000)은 데이터 FEC 인코더(5010), 비트 인터리버(5020), 컨스텔레이션 매퍼(mapper)(5030), SSD (signal space diversity) 인코딩 블록(5040), 타임 인터리버(5050)를 포함할 수 있다.
데이터 FEC 인코더(5010)는 외부 코딩(BCH) 및 내부 코딩(LDPC)을 이용하여 FECBLOCK 절차를 생성하기 위해 입력 BBF에 FEC 인코딩을 실행한다. 외부 코딩(BCH)은 선택적인 코딩 방법이다. 데이터 FEC 인코더(5010)의 구체적인 동작에 대해서는 후술한다.
비트 인터리버(5020)는 효율적으로 실현 가능한 구조를 제공하면서 데이터 FEC 인코더(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)로부터의 셀 워드를 변조하여 파워가 정규화된 컨스텔레이션 포인트 el을 제공할 수 있다. 해당 컨스텔레이션 매핑은 데이터 파이프에 대해서만 적용된다. NUQ가 임의의 형태를 갖는 반면, QAM-16 및 NUQ는 정사각형 모양을 갖는 것이 관찰된다. 각각의 컨스텔레이션이 90도의 배수만큼 회전되면, 회전된 컨스텔레이션은 원래의 것과 정확히 겹쳐진다. 회전 대칭 특성으로 인해 실수 및 허수 컴포넌트의 용량 및 평균 파워가 서로 동일해진다. NUQ 및 NUC는 모두 각 코드 레이트(code rate)에 대해 특별히 정의되고, 사용되는 특정 하나는 PLS2 데이터에 보관된 파라미터 DP_MOD에 의해 시그널링 된다.
타임 인터리버(5050)는 데이터 파이프 레벨에서 동작할 수 있다. 타임 인터리빙의 파라미터는 각각의 데이터 파이프에 대해 다르게 설정될 수 있다. 타임 인터리버(5050)의 구체적인 동작에 관해서는 후술한다.
어드벤스 프로파일에 대한 BICM 블록의 처리 블록(5000-1)은 데이터 FEC 인코더, 비트 인터리버, 컨스텔레이션 매퍼, 및 타임 인터리버를 포함할 수 있다.
단, 처리 블록(5000-1)은 셀 워드 디멀티플렉서(5010-1) 및 MIMO 인코딩 블록(5020-1)을 더 포함한다는 점에서 처리 블록(5000)과 구별된다.
또한, 처리 블록(5000-1)에서의 데이터 FEC 인코더, 비트 인터리버, 컨스텔레이션 매퍼, 타임 인터리버의 동작은 전술한 데이터 FEC 인코더(5010), 비트 인터리버(5020), 컨스텔레이션 매퍼(5030), 타임 인터리버(5050)의 동작에 해당하므로, 그 설명은 생략한다.
셀 워드 디멀티플렉서(5010-1)는 어드벤스 프로파일의 데이터 파이프가 MIMO 처리를 위해 단일 셀 워드 스트림을 이중 셀 워드 스트림으로 분리하는 데 사용된다. 셀 워드 디멀티플렉서(5010-1)의 구체적인 동작에 관해서는 후술한다.
MIMO 인코딩 블록(5020-1)은 MIMO 인코딩 방식을 이용해서 셀 워드 디멀티플렉서(5010-1)의 출력을 처리할 수 있다. MIMO 인코딩 방식은 방송 신호 송신을 위해 최적화되었다. MIMO 기술은 용량 증가를 얻기 위한 유망한 방식이지만, 채널 특성에 의존한다. 특별히 방송에 대해서, 서로 다른 신호 전파 특성으로 인한 두 안테나 사이의 수신 신호 파워 차이 또는 채널의 강한 LOS 컴포넌트는 MIMO로부터 용량 이득을 얻는 것을 어렵게 한다. 제안된 MIMO 인코딩 방식은 MIMO 출력 신호 중 하나의 위상 랜덤화 및 회전 기반 프리코딩을 이용하여 이 문제를 극복한다.
MIMO 인코딩은 송신기 및 수신기 모두에서 적어도 두 개의 안테나를 필요로 하는 2x2 MIMO 시스템을 위해 의도된다. 두 개의 MIMO 인코딩 모드는 본 제안인 FR-SM (full-rate spatial multiplexing) 및 FRFD-SM (full-rate full-diversity spatial multiplexing)에서 정의된다. FR-SM 인코딩은 수신기 측에서의 비교적 작은 복잡도 증가로 용량 증가를 제공하는 반면, FRFD-SM 인코딩은 수신기 측에서의 큰 복잡도 증가로 용량 증가 및 추가적인 다이버시티 이득을 제공한다. 제안된 MIMO 인코딩 방식은 안테나 극성 배치를 제한하지 않는다.
MIMO 처리는 어드벤스 프로파일 프레임에 요구되는데, 이는 어드벤스 프로파일 프레임에서의 모든 데이터 파이프가 MIMO 인코더에 의해 처리된다는 것을 의미한다. MIMO 처리는 데이터 파이프 레벨에서 적용된다. 컨스텔레이션 매퍼 출력의 페어(pair, 쌍)인 NUQ (e1,i 및 e2,i)는 MIMO 인코더의 입력으로 공급된다. MIMO 인코더 출력 페어(pair, 쌍)(g1,i 및 g2,i)은 각각의 송신 안테나의 동일한 캐리어 k 및 OFDM 심볼 l에 의해 전송된다.
전술한 블록은 생략되거나 유사 또는 동일 기능을 갖는 블록으로 대체될 수 있다.
도 5는 본 발명의 다른 실시예에 따른 BICM 블록을 나타낸다.
도 5에 도시된 BICM 블록은 도 1을 참조하여 설명한 BICM 블록(1010)의 일 실시예에 해당한다.
도 5는 PLS, EAC, 및 FIC의 보호를 위한 BICM 블록을 나타낸다. EAC는 EAS 정보 데이터를 전달하는 프레임의 일부이고, FIC는 서비스와 해당하는 베이스 데이터 파이프 사이에서 매핑 정보를 전달하는 프레임에서의 로지컬 채널이다. EAC 및 FIC에 대한 상세한 설명은 후술한다.
도 5를 참조하면, PLS, EAC, 및 FIC의 보호를 위한 BICM 블록은 PLS FEC 인코더(6000), 비트 인터리버(6010), 및 컨스텔레이션 매퍼(6020)를 포함할 수 있다.
또한, PLS FEC 인코더(6000)는 스크램블러, BCH 인코딩/제로 삽입 블록, LDPC 인코딩 블록, 및 LDPC 패리티 펑처링(puncturing) 블록을 포함할 수 있다. BICM 블록의 각 블록에 대해 설명한다.
PLS FEC 인코더(6000)는 스크램블링된 PLS 1/2 데이터, EAC 및 FIC 섹션을 인코딩할 수 있다.
스크램블러는 BCH 인코딩 및 쇼트닝(shortening) 및 펑처링된 LDPC 인코딩 전에 PLS1 데이터 및 PLS2 데이터를 스크램블링 할 수 있다.
BCH 인코딩/제로 삽입 블록은 PLS 보호를 위한 쇼트닝된 BCH 코드를 이용하여 스크램블링된 PLS 1/2 데이터에 외부 인코딩을 수행하고, BCH 인코딩 후에 제로 비트를 삽입할 수 있다. PLS1 데이터에 대해서만, 제로 삽입의 출력 비트가 LDPC 인코딩 전에 퍼뮤테이션(permutation) 될 수 있다.
LDPC 인코딩 블록은 LDPC 코드를 이용하여 BCH 인코딩/제로 삽입 블록의 출력을 인코딩할 수 있다. 완전한 코딩 블록을 생성하기 위해, Cldpc 및 패리티 비트 Pldpc는 각각의 제로가 삽입된 PLS 정보 블록 Ildpc로부터 조직적으로 인코딩되고, 그 뒤에 첨부된다.
Figure pct00004
PLS1 및 PLS2에 대한 LDPC 코드 파라미터는 다음의 표 4와 같다.
Figure pct00005
LDPC 패리티 펑처링 블록은 PLS1 데이터 및 PLS2 데이터에 대해 펑처링을 수행할 수 있다.
쇼트닝이 PLS1 데이터 보호에 적용되면, 일부 LDPC 패리티 비트는 LDPC 인코딩 후에 펑처링된다. 또한, PLS2 데이터 보호를 위해, PLS2의 LDPC 패리티 비트가 LDPC 인코딩 후에 펑처링된다. 이들 펑처링된 비트는 전송되지 않는다.
비트 인터리버(6010)는 각각의 쇼트닝 및 펑처링된 PLS1 데이터 및 PLS2 데이터를 인터리빙할 수 있다.
컨스텔레이션 매퍼(6020)는 비트 인터리빙된 PLS1 데이터 및 PLS2 데이터를 컨스텔레이션에 매핑할 수 있다.
전술한 블록은 생략되거나 유사 또는 동일 기능을 갖는 블록으로 대체될 수 있다.
도 6은 본 발명의 일 실시예에 따른 프레임 빌딩 블록(frame building block)을 나타낸다.
도 7에 도시한 프레임 빌딩 블록은 도 1을 참조하여 설명한 프레임 빌딩 블록(1020)의 일 실시예에 해당한다.
도 6을 참조하면, 프레임 빌딩 블록은 딜레이 컴펜세이션(delay compensation, 지연보상) 블록(7000), 셀 매퍼 (cell mapper) (7010), 및 프리퀀시 인터리버 (frequency interleaver) (7020)를 포함할 수 있다. 프레임 빌딩 블록의 각 블록에 관해 설명한다.
딜레이 컴펜세이션(delay compensation, 지연보상) 블록(7000)은 데이터 파이프와 해당하는 PLS 데이터 사이의 타이밍을 조절하여 송신기 측에서 데이터 파이프와 해당하는 PLS 데이터 간의 동시성(co-time)을 보장할 수 있다. 인풋 포맷 블록 및 BICM 블록으로 인한 데이터 파이프의 지연을 다룸으로써 PLS 데이터는 데이터 파이프만큼 지연된다. BICM 블록의 지연은 주로 타임 인터리버(5050)로 인한 것이다. 인 밴드(In-band) 시그널링 데이터는 다음 타임 인터리빙 그룹의 정보를 시그널링될 데이터 파이프보다 하나의 프레임 앞서 전달되도록 할 수 있다. 딜레이 컴펜세이션(delay compensation, 지연보상) 블록은 그에 맞추어 인 밴드(In-band) 시그널링 데이터를 지연시킨다.
셀 매퍼(7010)는 PLS, EAC, FIC, 데이터 파이프, 보조 스트림, 및 더미 셀을 프레임 내에서 OFDM 심볼의 액티브(active) 캐리어에 매핑할 수 있다. 셀 매퍼(7010)의 기본 기능은 각각의 데이터 파이프, PLS 셀, 및 EAC/FIC 셀에 대한 타임 인터리빙에 의해 생성된 데이터 셀을, 존재한다면, 하나의 프레임 내에서 각각의 OFDM 심볼에 해당하는 액티브(active) OFDM 셀의 어레이에 매핑하는 것이다. (PSI(program specific information)/SI와 같은) 서비스 시그널링 데이터는 개별적으로 수집되어 데이터 파이프에 의해 보내질 수 있다. 셀 매퍼는 프레임 구조의 구성 및 스케줄러에 의해 생성된 다이나믹 인포메이션(dynamic information, 동적 정보)에 따라 동작한다. 프레임에 관한 자세한 내용은 후술한다.
주파수 인터리버(7020)는 셀 매퍼(7010)로부터 의해 수신된 데이터 셀을 랜덤하게 인터리빙하여 주파수 다이버시티를 제공할 수 있다. 또한, 주파수 인터리버(7020)는 단일 프레임에서 최대의 인터리빙 이득을 얻기 위해 다른 인터리빙 시드(seed) 순서를 이용하여 두 개의 순차적인 OFDM 심볼로 구성된 OFDM 심볼 페어(pair, 쌍)에서 동작할 수 있다.
전술한 블록은 생략되거나 유사 또는 동일 기능을 갖는 블록으로 대체될 수 있다.
도 7은 본 발명의 일 실시예에 따른 OFDM 제너레이션 블록을 나타낸다.
도 7에 도시된 OFDM 제너레이션 블록은 도 1을 참조하여 설명한 OFDM 제너레이션 블록(1030)의 일 실시예에 해당한다.
OFDM 제너레이션 블록은 프레임 빌딩 블록에 의해 생성된 셀에 의해 OFDM 캐리어를 변조하고, 파일럿을 삽입하고, 전송을 위한 시간 영역 신호를 생성한다. 또한, 해당 블록은 순차적으로 가드 인터벌을 삽입하고, PAPR 감소 처리를 적용하여 최종 RF 신호를 생성한다.
도 8을 참조하면, OFDM 제너레이션 블록은 파일럿 및 리저브드 톤 삽입 블록 (pilot and revserved tone insertion block) (8000), 2D-eSFN (single frequency network) 인코딩 블록(8010), IFFT (inverse fast Fourier transform) 블록(8020), PAPR 감소 블록(8030), 가드 인터벌 삽입 블록 (guard interval insertion block)(8040), 프리앰블 삽입 블록 (preamble insertion block)(8050), 기타 시스템 삽입 블록(8060), 및 DAC 블록(8070)을 포함할 수 있다.
기타 시스템 삽입 블록(8060)은 방송 서비스를 제공하는 둘 이상의 서로 다른 방송 송신/수신 시스템의 데이터가 동일한 RF 신호 대역에서 동시에 전송될 수 있도록 시간 영역에서 복수의 방송 송신/수신 시스템의 신호를 멀티플렉싱 할 수 있다. 이 경우, 둘 이상의 서로 다른 방송 송신/수신 시스템은 서로 다른 방송 서비스를 제공하는 시스템을 말한다. 서로 다른 방송 서비스는 지상파 방송 서비스, 모바일 방송 서비스 등을 의미할 수 있다.
도 8은 본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치의 구조를 나타낸다.
본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치는 도 1을 참조하여 설명한 차세대 방송 서비스에 대한 방송 신호 송신 장치에 대응할 수 있다.
본 발명의 일 실시예에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치는 동기 및 복조 모듈 (synchronization & demodulation module) (9000), 프레임 파싱 모듈 (frame parsing module) (9010), 디매핑 및 디코딩 모듈 (demapping & decoding module) (9020), 출력 프로세서 (output processor) (9030), 및 시그널링 디코딩 모듈 (signaling decoding module) (9040)을 포함할 수 있다. 방송 신호 수신 장치의 각 모듈의 동작에 대해 설명한다.
동기 및 복조 모듈(9000)은 m개의 수신 안테나를 통해 입력 신호를 수신하고, 방송 신호 수신 장치에 해당하는 시스템에 대해 신호 검출 및 동기화를 실행하고, 방송 신호 송신 장치에 의해 실행되는 절차의 역과정에 해당하는 복조를 실행할 수 있다.
프레임 파싱 모듈(9010)은 입력 신호 프레임을 파싱하고, 사용자에 의해 선택된 서비스가 전송되는 데이터를 추출할 수 있다. 방송 신호 송신 장치가 인터리빙을 실행하면, 프레임 파싱 모듈(9010)은 인터리빙의 역과정에 해당하는 디인터리빙을 실행할 수 있다. 이 경우, 추출되어야 하는 신호 및 데이터의 위치가 시그널링 디코딩 모듈(9040)로부터 출력된 데이터를 디코딩함으로써 획득되어, 방송 신호 송신 장치에 의해 생성된 스케줄링 정보가 복원될 수 있다.
디매핑 및 디코딩 모듈(9020)은 입력 신호를 비트 영역 데이터로 변환한 후, 필요에 따라 비트 영역 데이터들을 디인터리빙할 수 있다. 디매핑 및 디코딩 모듈(9020)은 전송 효율을 위해 적용된 매핑에 대한 디매핑을 실행하고, 디코딩을 통해 전송 채널에서 발생한 에러를 정정할 수 있다. 이 경우, 디매핑 및 디코딩 모듈(9020)은 시그널링 디코딩 모듈(9040)로부터 출력된 데이터를 디코딩함으로써 디매핑 및 디코딩을 위해 필요한 전송 파라미터를 획득할 수 있다.
출력 프로세서(9030)는 전송 효율을 향상시키기 위해 방송 신호 송신 장치에 의해 적용되는 다양한 압축/신호 처리 절차의 역과정을 실행할 수 있다. 이 경우, 출력 프로세서(9030)는 시그널링 디코딩 모듈(9040)로부터 출력된 데이터에서 필요한 제어 정보를 획득할 수 있다. 출력 프로세서(8300)의 출력은 방송 신호 송신 장치에 입력되는 신호에 해당하고, MPEG-TS, IP 스트림 (v4 또는 v6) 및 GS일 수 있다.
시그널링 디코딩 모듈(9040)은 동기 및 복조 모듈(9000)에 의해 복조된 신호로부터 PLS 정보를 획득할 수 있다. 전술한 바와 같이, 프레임 파싱 모듈(9010), 디매핑 및 디코딩 모듈(9200), 출력 프로세서(9300)는 시그널링 디코딩 모듈(9040)로부터 출력된 데이터를 이용하여 그 기능을 실행할 수 있다.
도 9는 본 발명의 일 실시예에 따른 프레임 구조를 나타낸다.
도 9는 프레임 타임의 구성예 및 슈퍼 프레임에서의 FRU (frame repetition unit, 프레임 반복 단위)를 나타낸다. (a)는 본 발명의 일 실시예에 따른 슈퍼 프레임을 나타내고, (b)는 본 발명의 일 실시예에 따른 FRU를 나타내고, (c)는 FRU에서의 다양한 피지컬 프로파일(PHY profile)의 프레임을 나타내고, (d)는 프레임의 구조를 나타낸다.
슈퍼 프레임은 8개의 FRU로 구성될 수 있다. FRU는 프레임의 TDM에 대한 기본 멀티플렉싱 단위이고, 슈퍼 프레임에서 8회 반복된다.
FRU에서 각 프레임은 피지컬 프로파일(베이스, 핸드헬드, 어드벤스 프로파일) 중 하나 또는 FEF에 속한다. FRU에서 프레임의 최대 허용수는 4이고, 주어진 피지컬 프로파일은 FRU에서 0회 내지 4회 중 어느 횟수만큼 나타날 수 있다(예를 들면, 베이스, 베이스, 핸드헬드, 어드벤스). 피지컬 프로파일 정의는 필요시 프리앰블에서의 PHY_PROFILE의 리저브드 값을 이용하여 확장될 수 있다.
FEF 부분은 포함된다면 FRU의 끝에 삽입된다. FEF가 FRU에 포함되는 경우, FEF의 최대수는 슈퍼 프레임에서 8이다. FEF 부분들이 서로 인접할 것이 권장되지 않는다.
하나의 프레임은 다수의 OFDM 심볼 및 프리앰블로 더 분리된다. (d)에 도시한 바와 같이, 프레임은 프리앰블, 하나 이상의 FSS, 노멀 데이터 심볼, FES를 포함한다.
프리앰블은 고속 퓨처캐스트 UTB 시스템 신호 검출을 가능하게 하고, 신호의 효율적인 송신 및 수신을 위한 기본 전송 파라미터의 집합을 제공하는 특별한 심볼이다. 프리앰블에 대한 자세한 내용은 후술한다.
FSS의 주된 목적은 PLS 데이터를 전달하는 것이다. 고속 동기화 및 채널 추정을 위해, 이에 따른 PLS 데이터의 고속 디코딩을 위해, FSS는 노멀 데이터 심볼보다 고밀도의 파일럿 패턴을 갖는다. FES는 FSS와 완전히 동일한 파일럿을 갖는데, 이는 FES에 바로 앞서는 심볼에 대해 외삽(extrapolation) 없이 FES 내에서의 주파수만의 인터폴레이션(interpolation, 보간) 및 시간적 보간(temporal interpolation)을 가능하게 한다.
도 10은 본 발명의 일 실시예에 따른 프레임의 시그널링 계층 구조(signaling hierarchy structure) 를 나타낸다.
도 10은 시그널링 계층 구조를 나타내는데, 이는 세 개의 주요 부분인 프리앰블 시그널링 데이터(11000), PLS1 데이터(11010), 및 PLS2 데이터(11020)로 분할된다. 매 프레임마다 프리앰블 신호에 의해 전달되는 프리앰블의 목적은 프레임의 기본 전송 파라미터 및 전송 타입을 나타내는 것이다. PLS1은 수신기가 관심 있는 데이터 파이프에 접속하기 위한 파라미터를 포함하는 PLS2 데이터에 접속하여 디코딩할 수 있게 한다. PLS2는 매 프레임마다 전달되고, 두 개의 주요 부분인 PLS2-STAT 데이터와 PLS2-DYN 데이터로 분할된다. PLS2 데이터의 스태틱(static, 정적) 및 다이나믹(dynamic, 동적) 부분에는 필요시 패딩이 뒤따른다.
도 11은 본 발명의 일 실시예에 따른 프리앰블 시그널링 데이터를 나타낸다.
프리앰블 시그널링 데이터는 수신기가 프레임 구조 내에서 PLS 데이터에 접속하고 데이터 파이프를 추적할 수 있게 하기 위해 필요한 21비트의 정보를 전달한다. 프리앰블 시그널링 데이터에 대한 자세한 내용은 다음과 같다.
PHY_PROFILE: 해당 3비트 필드는 현 프레임의 피지컬 프로파일 타입을 나타낸다. 서로 다른 피지컬 프로파일 타입의 매핑은 아래 표 5에 주어진다.
Figure pct00006
FFT_SIZE: 해당 2비트 필드는 아래 표 6에서 설명한 바와 같이 프레임 그룹 내에서 현 프레임의 FFT 사이즈를 나타낸다.
Figure pct00007
GI_FRACTION: 해당 3비트 필드는 아래 표 7에서 설명한 바와 같이 현 슈퍼 프레임에서의 가드 인터벌 일부(fraction) 값을 나타낸다.
Figure pct00008
EAC_FLAG: 해당 1비트 필드는 EAC가 현 프레임에 제공되는지 여부를 나타낸다. 해당 필드가 1로 설정되면, EAS가 현 프레임에 제공된다. 해당 필드가 0으로 설정되면, EAS가 현 프레임에서 전달되지 않는다. 해당 필드는 슈퍼 프레임 내에서 다이나믹(dynamic, 동적)으로 전환될 수 있다.
PILOT_MODE: 해당 1비트 필드는 현 프레임 그룹에서 현 프레임에 대해 파일럿 모드가 모바일 모드인지 또는 고정 모드인지 여부를 나타낸다. 해당 필드가 0으로 설정되면, 모바일 파일럿 모드가 사용된다. 해당 필드가 1로 설정되면, 고정 파일럿 모드가 사용된다.
PAPR_FLAG: 해당 1비트 필드는 현 프레임 그룹에서 현 프레임에 대해 PAPR 감소가 사용되는지 여부를 나타낸다. 해당 필드가 1로 설정되면, 톤 예약(tone reservation)이 PAPR 감소를 위해 사용된다. 해당 필드가 0으로 설정되면, PAPR 감소가 사용되지 않는다.
FRU_CONFIGURE: 해당 3비트 필드는 현 슈퍼 프레임에서 존재하는 FRU의 피지컬 프로파일 타입 구성을 나타낸다. 현 슈퍼 프레임에서 모든 프리앰블에서의 해당 필드에서, 현 슈퍼 프레임에서 전달되는 모든 프로파일 타입이 식별된다. 해당 3비트 필드는 아래 표 8에 나타낸 바와 같이 각각의 프로파일에 대해 다르게 정의된다.
Figure pct00009
RESERVED: 해당 7비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
도 12는 본 발명의 일 실시예에 따른 PLS1 데이터를 나타낸다.
PLS1 데이터는 PLS2의 수신 및 디코딩을 가능하게 하기 위해 필요한 파라미터를 포함한 기본 전송 파라미터를 제공한다. 전술한 바와 같이, PLS1 데이터는 하나의 프레임 그룹의 전체 듀레이션 동안 변화하지 않는다. PLS1 데이터의 시그널링 필드의 구체적인 정의는 다음과 같다.
PREAMBLE_DATA: 해당 20비트 필드는 EAC_FLAG를 제외한 프리앰블 시그널링 데이터의 카피이다.
NUM_FRAME_FRU: 해당 2비트 필드는 FRU당 프레임 수를 나타낸다.
PAYLOAD_TYPE: 해당 3비트 필드는 프레임 그룹에서 전달되는 페이로드 데이터의 포맷을 나타낸다. PAYLOAD_TYPE은 표 9에 나타낸 바와 같이 시그널링 된다.
Figure pct00010
NUM_FSS: 해당 2비트 필드는 현 프레임에서 FSS의 수를 나타낸다.
SYSTEM_VERSION: 해당 8비트 필드는 전송되는 신호 포맷의 버전을 나타낸다. SYSTEM_VERSION은 주 버전 및 부 버전의 두 개의 4비트 필드로 분리된다.
주 버전: SYSTEM_VERSION 필드의 MSB인 4비트는 주 버전 정보를 나타낸다. 주 버전 필드에서의 변화는 호환이 불가능한 변화를 나타낸다. 디폴트 값은 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 시스템은 존재한다면 FEF 및 하나 이상의 피지컬 프로파일을 전달한다. 동일한 퓨처캐스트 UTB 시스템은 서로 다른 입력 스트림을 전달하고 서로 다른 지리적 영역에서 서로 다른 RF를 사용할 수 있어, 로컬 서비스 삽입을 허용한다. 프레임 구조 및 스케줄링은 하나의 장소에서 제어되고, 퓨처캐스트 UTB 시스템 내에서 모든 전송에 대해 동일하다. 하나 이상의 퓨처캐스트 UTB 시스템은 모두 동일한 피지컬 구조 및 구성을 갖는다는 동일한 SYSTEM_ID 의미를 가질 수 있다.
다음의 루프(loop)는 각 프레임 타입의 길이 및 FRU 구성을 나타내는 FRU_PHY_PROFILE, FRU_FRAME_LENGTH, FRU_GI_FRACTION, RESERVED로 구성된다. 루프(loop) 사이즈는 FRU 내에서 4개의 피지컬 프로파일(FEF 포함)이 시그널링되도록 고정된다. NUM_FRAME_FRU가 4보다 작으면, 사용되지 않는 필드는 제로로 채워진다.
FRU_PHY_PROFILE: 해당 3비트 필드는 관련된 FRU의 (i+1)번째 프레임(i는 루프(loop) 인덱스)의 피지컬 프로파일 타입을 나타낸다. 해당 필드는 표 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비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
다음의 필드는 PLS2 데이터를 디코딩하기 위한 파라미터를 제공한다.
PLS2_FEC_TYPE: 해당 2비트 필드는 PLS2 보호에 의해 사용되는 FEC 타입을 나타낸다. FEC 타입은 표 10에 따라 시그널링 된다. LDPC 코드에 대한 자세한 내용은 후술한다.
Figure pct00011
PLS2_MOD: 해당 3비트 필드는 PLS2에 의해 사용되는 변조 타입을 나타낸다. 변조 타입은 표 11에 따라 시그널링 된다.
Figure pct00012
PLS2_SIZE_CELL: 해당 15비트 필드는 현 프레임 그룹에서 전달되는 PLS2에 대한 모든 코딩 블록의 사이즈(QAM 셀의 수로 특정됨)인 C total_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에 대한 부분 코딩 블록의 사이즈(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에 대한 전체 코딩 블록의 사이즈(QAM 셀의 수로 특정됨)인 Ctotal_full_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에 대해 사용되지 않는다.
Figure pct00013
PLS2_AP_SIZE_CELL: 해당 15비트 필드는 PLS2의 추가 패리티 비트의 사이즈(QAM 셀의 수로 특정됨)를 나타낸다. 해당 값은 현 프레임 그룹의 전체 듀레이션 동안 일정하다.
PLS2_NEXT_AP_MODE: 해당 2비트 필드는 다음 프레임 그룹의 매 프레임마다 PLS2 시그널링에 대해 추가 패리티가 제공되는지 여부를 나타낸다. 해당 값은 현 프레임 그룹의 전체 듀레이션 동안 일정하다. 표 12는 해당 필드의 값을 정의한다.
PLS2_NEXT_AP_SIZE_CELL: 해당 15비트 필드는 다음 프레임 그룹의 매 프레임마다 PLS2의 추가 패리티 비트의 사이즈(QAM 셀의 수로 특정됨)를 나타낸다. 해당 값은 현 프레임 그룹의 전체 듀레이션 동안 일정하다.
RESERVED: 해당 32비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
CRC_32: 전체 PLS1 시그널링에 적용되는 32비트 에러 검출 코드
도 13은 본 발명의 일 실시예에 따른 PLS2 데이터를 나타낸다.
도 13은 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비트 필드는 현 프레임 내에서 전달되는 데이터 파이프의 수를 나타낸다. 해당 필드의 값은 1에서 64 사이이고, 데이터 파이프의 수는 NUM_DP+1이다.
DP_ID: 해당 6비트 필드는 피지컬 프로파일 내에서 유일하게 식별한다.
DP_TYPE: 해당 3비트 필드는 데이터 파이프의 타입을 나타낸다. 이는 아래의 표 13에 따라 시그널링 된다.
Figure pct00014
DP_GROUP_ID: 해당 8비트 필드는 현 데이터 파이프가 관련되어 있는 데이터 파이프 그룹을 식별한다. 이는 수신기가 동일한 DP_GROUP_ID를 갖게 되는 특정 서비스와 관련되어 있는 서비스 컴포넌트의 데이터 파이프에 접속하는 데 사용될 수 있다.
BASE_DP_ID: 해당 6비트 필드는 관리 계층에서 사용되는 (PSI/SI와 같은) 서비스 시그널링 데이터를 전달하는 데이터 파이프를 나타낸다. BASE_DP_ID에 의해 나타내는 데이터 파이프는 서비스 데이터와 함께 서비스 시그널링 데이터를 전달하는 노멀 데이터 파이프이거나, 서비스 시그널링 데이터만을 전달하는 전용 데이터 파이프일 수 있다.
DP_FEC_TYPE: 해당 2비트 필드는 관련된 데이터 파이프에 의해 사용되는 FEC 타입을 나타낸다. FEC 타입은 아래의 표 14에 따라 시그널링 된다.
Figure pct00015
DP_COD: 해당 4비트 필드는 관련된 데이터 파이프에 의해 사용되는 코드 레이트(code rate)을 나타낸다. 코드 레이트(code rate)은 아래의 표 15에 따라 시그널링 된다.
Figure pct00016
DP_MOD: 해당 4비트 필드는 관련된 데이터 파이프에 의해 사용되는 변조를 나타낸다. 변조는 아래의 표 16에 따라 시그널링 된다.
Figure pct00017
DP_SSD_FLAG: 해당 1비트 필드는 SSD 모드가 관련된 데이터 파이프에서 사용되는지 여부를 나타낸다. 해당 필드의 값이 1로 설정되면, SSD는 사용된다. 해당 필드의 값이 0으로 설정되면, SSD는 사용되지 않는다.
다음의 필드는 PHY_PROFILE가 어드벤스 프로파일을 나타내는 010과 동일할 때에만 나타난다.
DP_MIMO: 해당 3비트 필드는 어떤 타입의 MIMO 인코딩 처리가 관련된 데이터 파이프에 적용되는지 나타낸다. MIMO 인코딩 처리의 타입은 아래의 표 17에 따라 시그널링 된다.
Figure pct00018
DP_TI_TYPE: 해당 1비트 필드는 타임 인터리빙의 타입을 나타낸다. 0의 값은 하나의 타임 인터리빙 그룹이 하나의 프레임에 해당하고 하나 이상의 타임 인터리빙 블록을 포함하는 것을 나타낸다. 1의 값은 하나의 타임 인터리빙 그룹이 하나보다 많은 프레임으로 전달되고 하나의 타임 인터리빙 블록만을 포함하는 것을 나타낸다.
DP_TI_LENGTH: 해당 2비트 필드(허용된 값은 1, 2, 4, 8뿐이다)의 사용은 다음과 같은 DP_TI_TYPE 필드 내에서 설정되는 값에 의해 결정된다.
DP_TI_TYPE의 값이 1로 설정되면, 해당 필드는 각각의 타임 인터리빙 그룹이 매핑되는 프레임의 수인 PI를 나타내고, 타임 인터리빙 그룹당 하나의 타임 인터리빙 블록이 존재한다 (NTI=1). 해당 2비트 필드로 허용되는 PI의 값은 아래의 표 18에 정의된다.
DP_TI_TYPE의 값이 0으로 설정되면, 해당 필드는 타임 인터리빙 그룹당 타임 인터리빙 블록의 수 NTI를 나타내고, 프레임당 하나의 타임 인터리빙 그룹이 존재한다 (PI=1). 해당 2비트 필드로 허용되는 PI의 값은 아래의 표 18에 정의된다.
Figure pct00019
DP_FRAME_INTERVAL: 해당 2비트 필드는 관련된 데이터 파이프에 대한 프레임 그룹 내에서 프레임 간격(IJUMP)을 나타내고, 허용된 값은 1, 2, 4, 8 (해당하는 2비트 필드는 각각 00, 01, 10, 11)이다. 프레임 그룹의 모든 프레임에 나타나지 않는 데이터 파이프에 대해, 해당 필드의 값은 순차적인 프레임 사이의 간격과 동일하다. 예를 들면, 데이터 파이프가 1, 5, 9, 13 등의 프레임에 나타나면, 해당 필드의 값은 4로 설정된다. 모든 프레임에 나타나는 데이터 파이프에 대해, 해당 필드의 값은 1로 설정된다.
DP_TI_BYPASS: 해당 1비트 필드는 타임 인터리버(5050)의 가용성을 결정한다. 데이터 파이프에 대해 타임 인터리빙이 사용되지 않으면, 해당 필드 값은 1로 설정된다. 반면, 타임 인터리빙이 사용되면, 해당 필드 값은 0으로 설정된다.
DP_FIRST_FRAME_IDX: 해당 5비트 필드는 현 데이터 파이프가 발생하는 슈퍼 프레임의 첫 번째 프레임의 인덱스를 나타낸다. DP_FIRST_FRAME_IDX의 값은 0에서 31 사이다.
DP_NUM_BLOCK_MAX: 해당 10비트 필드는 해당 데이터 파이프에 대한 DP_NUM_BLOCKS의 최대값을 나타낸다. 해당 필드의 값은 DP_NUM_BLOCKS와 동일한 범위를 갖는다.
DP_PAYLOAD_TYPE: 해당 2비트 필드는 주어진 데이터 파이프에 의해 전달되는 페이로드 데이터의 타입을 나타낸다. DP_PAYLOAD_TYPE은 아래의 표 19에 따라 시그널링 된다.
Figure pct00020
DP_INBAND_MODE: 해당 2비트 필드는 현 데이터 파이프가 인 밴드(In-band) 시그널링 정보를 전달하는지 여부를 나타낸다. 인 밴드(In-band) 시그널링 타입은 아래의 표 20에 따라 시그널링 된다.
Figure pct00021
DP_PROTOCOL_TYPE: 해당 2비트 필드는 주어진 데이터 파이프에 의해 전달되는 페이로드의 프로토콜 타입을 나타낸다. 페이로드의 프로토콜 타입은 입력 페이로드 타입이 선택되면 아래의 표 21에 따라 시그널링 된다.
Figure pct00022
DP_CRC_MODE: 해당 2비트 필드는 CRC 인코딩이 인풋 포맷 블록에서 사용되는지 여부를 나타낸다. CRC 모드는 아래의 표 22에 따라 시그널링 된다.
Figure pct00023
DNP_MODE: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되는 경우에 관련된 데이터 파이프에 의해 사용되는 널 패킷 삭제 모드를 나타낸다. DNP_MODE는 아래의 표 23에 따라 시그널링 된다. DP_PAYLOAD_TYPE이 TS ('00')가 아니면, DNP_MODE는 00의 값으로 설정된다.
Figure pct00024
ISSY_MODE: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되는 경우에 관련된 데이터 파이프에 의해 사용되는 ISSY 모드를 나타낸다. ISSY_MODE는 아래의 표 24에 따라 시그널링 된다. DP_PAYLOAD_TYPE이 TS ('00')가 아니면, ISSY_MODE는 00의 값으로 설정된다.
Figure pct00025
HC_MODE_TS: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되는 경우에 관련된 데이터 파이프에 의해 사용되는 TS 헤더 압축 모드를 나타낸다. HC_MODE_TS는 아래의 표 25에 따라 시그널링 된다.
Figure pct00026
HC_MODE_IP: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 IP ('01')로 설정되는 경우에 IP 헤더 압축 모드를 나타낸다. HC_MODE_IP는 아래의 표 26에 따라 시그널링 된다.
Figure pct00027
PID: 해당 13비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되고 HC_MODE_TS가 01 또는 10으로 설정되는 경우에 TS 헤더 압축을 위한 PID 수를 나타낸다.
RESERVED: 해당 8비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
다음 필드는 FIC_FLAG가 1과 동일할 때만 나타난다.
FIC_VERSION: 해당 8비트 필드는 FIC의 버전 넘버를 나타낸다.
FIC_LENGTH_BYTE: 해당 13비트 필드는 FIC의 길이를 바이트 단위로 나타낸다.
RESERVED: 해당 8비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
다음 필드는 AUX_FLAG가 1과 동일할 때만 나타난다.
NUM_AUX: 해당 4비트 필드는 보조 스트림의 수를 나타낸다. 제로는 보조 스트림이 사용되지 않는 것을 나타낸다.
AUX_CONFIG_RFU: 해당 8비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
AUX_STREAM_TYPE: 해당 4비트는 현 보조 스트림의 타입을 나타내기 위한 추후 사용을 위해 리저브드(reserved)된다.
AUX_PRIVATE_CONFIG: 해당 28비트 필드는 보조 스트림을 시그널링 하기 위한 추후 사용을 위해 리저브드(reserved)된다.
도 14는 본 발명의 다른 일 실시예에 따른 PLS2 데이터를 나타낸다.
도 14는 PLS2 데이터의 PLS2-DYN을 나타낸다. PLS2-DYN 데이터의 값은 하나의 프레임 그룹의 듀레이션 동안 변화할 수 있는 반면, 필드의 사이즈는 일정하다.
PLS2-DYN 데이터의 필드의 구체적인 내용은 다음과 같다.
FRAME_INDEX: 해당 5비트 필드는 슈퍼 프레임 내에서 현 프레임의 프레임 인덱스를 나타낸다. 슈퍼 프레임의 첫 번째 프레임의 인덱스는 0으로 설정된다.
PLS_CHANGE_COUNTER: 해당 4비트 필드는 구성이 변화하기 전의 슈퍼 프레임의 수를 나타낸다. 구성이 변화하는 다음 슈퍼 프레임은 해당 필드 내에서 시그널링 되는 값에 의해 나타낸다. 해당 필드의 값이 0000으로 설정되면, 이는 어떠한 예정된 변화도 예측되지 않는 것을 의미한다. 예를 들면, 1의 값은 다음 슈퍼 프레임에 변화가 있다는 것을 나타낸다.
FIC_CHANGE_COUNTER: 해당 4비트 필드는 구성(즉, FIC의 콘텐츠)이 변화하기 전의 슈퍼 프레임의 수를 나타낸다. 구성이 변화하는 다음 슈퍼 프레임은 해당 필드 내에서 시그널링 되는 값에 의해 나타낸다. 해당 필드의 값이 0000으로 설정되면, 이는 어떠한 예정된 변화도 예측되지 않는 것을 의미한다. 예를 들면, 0001의 값은 다음 슈퍼 프레임에 변화가 있다는 것을 나타낸다.
RESERVED: 해당 16비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
다음 필드는 현 프레임에서 전달되는 데이터 파이프와 관련된 파라미터를 설명하는 NUM_DP에서의 루프(loop)에 나타난다.
DP_ID: 해당 6비트 필드는 피지컬 프로파일 내에서 데이터 파이프를 유일하게 나타낸다.
DP_START: 해당 15비트 (또는 13비트) 필드는 DPU 어드레싱(addressing) 기법을 사용하여 데이터 파이프의 첫 번째의 시작 위치를 나타낸다. DP_START 필드는 아래의 표 27에 나타낸 바와 같이 피지컬 프로파일 및 FFT 사이즈에 따라 다른 길이를 갖는다.
Figure pct00028
DP_NUM_BLOCK: 해당 10비트 필드는 현 데이터 파이프에 대한 현 타임 인터리빙 그룹에서 FEC 블록의 수를 나타낸다. DP_NUM_BLOCK의 값은 0에서 1023 사이에 있다.
RESERVED: 해당 8비트 필드는 추후 사용을 위해 리저브드(reserved)된다.
다음의 필드는 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비트 필드는 보조 스트림을 시그널링 하기 위한 추후 사용을 위해 리저브드(reserved)된다. 해당 필드의 의미는 설정 가능한 PLS2-STAT에서 AUX_STREAM_TYPE의 값에 의존한다.
CRC_32: 전체 PLS2에 적용되는 32비트 에러 검출 코드.
도 15는 본 발명의 일 실시예에 따른 프레임의 로지컬(logical) 구조를 나타낸다.
전술한 바와 같이, PLS, EAC, FIC, 데이터 파이프, 보조 스트림, 더미 셀은 프레임에서 OFDM 심볼의 액티브(active) 캐리어에 매핑된다. PLS1 및 PLS2는 처음에 하나 이상의 FSS에 매핑된다. 그 후, EAC가 존재한다면 EAC 셀은 바로 뒤따르는 PLS 필드에 매핑된다. 다음에 FIC가 존재한다면 FIC 셀이 매핑된다. 데이터 파이프는 PLS 다음에 매핑되거나, EAC 또는 FIC가 존재하는 경우, EAC 또는 FIC 이후에 매핑된다. 타입 1 데이터 파이프가 처음에 매핑되고, 타입 2 데이터 파이프가 다음에 매핑된다. 데이터 파이프의 타입의 구체적인 내용은 후술한다. 일부 경우, 데이터 파이프는 EAS에 대한 일부 특수 데이터 또는 서비스 시그널링 데이터를 전달할 수 있다. 보조 스트림 또는 스트림은 존재한다면 데이터 파이프를 다음에 매핑되고 여기에는 차례로 더미 셀이 뒤따른다. 전술한 순서, 즉, PLS, EAC, FIC, 데이터 파이프, 보조 스트림, 및 더미 셀의 순서로 모두 함께 매핑하면 프레임에서 셀 용량을 정확히 채운다.
도 16은 본 발명의 일 실시예에 따른 PLS 매핑을 나타낸다.
PLS 셀은 FSS의 액티브(active) 캐리어에 매핑된다. PLS가 차지하는 셀의 수에 따라, 하나 이상의 심볼이 FSS로 지정되고, FSS의 수 NFSS는 PLS1에서의 NUM_FSS에 의해 시그널링된다. FSS는 PLS 셀을 전달하는 특수한 심볼이다. 경고성 및 지연 시간(latency)은 PLS에서 중대한 사안이므로, FSS는 높은 파일럿 밀도를 가지고 있어 고속 동기화 및 FSS 내에서의 주파수만의 인터폴레이션(interpoloation, 보간)을 가능하게 한다.
PLS 셀은 도 16의 예에 나타낸 바와 같이 하향식으로 FSS의 액티브(active) 캐리어에 매핑된다. PLS1 셀은 처음에 첫 FSS의 첫 셀부터 셀 인덱스의 오름차순으로 매핑된다. PLS2 셀은 PLS1의 마지막 셀 직후에 뒤따르고, 매핑은 첫 FSS의 마지막 셀 인덱스까지 아래방향으로 계속된다. 필요한 PLS 셀의 총 수가 하나의 FSS의 액티브(active) 캐리어의 수를 초과하면, 매핑은 다음 FSS로 진행되고 첫 FSS와 완전히 동일한 방식으로 계속된다.
PLS 매핑이 완료된 후, 데이터 파이프가 다음에 전달된다. EAC, FIC 또는 둘 다 현 프레임에 존재하면, EAC 및 FIC는PLS와 노멀 데이터 파이프 사이에 배치된다.
도 17은 본 발명의 일 실시예에 따른 EAC 매핑을 나타낸다.
EAC는 EAS 메시지를 전달하는 전용 채널이고 EAS에 대한 데이터 파이프에 연결된다. EAS 지원은 제공되지만, EAC 자체는 모든 프레임에 존재할 수도 있고 존재하지 않을 수도 있다. EAC가 존재하는 경우, EAC는 PLS2 셀의 직후에 매핑된다. PLS 셀을 제외하고 FIC, 데이터 파이프, 보조 스트림 또는 더미 셀 중 어느 것도 EAC 앞에 위치하지 않는다. EAC 셀의 매핑 절차는 PLS와 완전히 동일하다.
EAC 셀은 도 17의 예에 나타낸 바와 같이 PLS2의 다음 셀부터 셀 인덱스의 오름차순으로 매핑된다. EAS 메시지 크기에 따라, 도 17에 나타낸 바와 같이 EAC 셀은 적은 심볼을 차지할 수 있다.
EAC 셀은 PLS2의 마지막 셀 직후에 뒤따르고, 매핑은 마지막 FSS의 마지막 셀 인덱스까지 아래방향으로 계속된다. 필요한 EAC 셀의 총 수가 마지막 FSS의 남아 있는 액티브(active) 캐리어의 수를 초과하면, EAC 매핑은 다음 심볼로 진행되며, FSS와 완전히 동일한 방식으로 계속된다. 이 경우 EAC의 매핑이 이루어지는 다음 심볼은 노멀 데이터 심볼이고, 이는 FSS보다 더 많은 액티브(active) 캐리어를 갖는다.
EAC 매핑이 완료된 후, 존재한다면 FIC가 다음에 전달된다. FIC가 전송되지 않으면(PLS2 필드에서 시그널링으로), 데이터 파이프가 EAC의 마지막 셀 직후에 뒤따른다.
도 18은 본 발명의 일 실시예에 따른 FIC 매핑을 나타낸다.
(a)는 EAC 없이 FIC 셀의 매핑의 예를 나타내고, (b)는 EAC와 함께 FIC 셀의 매핑의 예를 나타낸다.
FIC는 고속 서비스 획득 및 채널 스캔을 가능하게 하기 위해 계층간 정보(cross-layer information)를 전달하는 전용 채널이다. 해당 정보는 주로 데이터 파이프 사이의 채널 바인딩 (channel binding) 정보 및 각 방송사의 서비스를 포함한다. 고속 스캔을 위해, 수신기는 FIC를 디코딩하고 방송사 ID, 서비스 수, BASE_DP_ID와 같은 정보를 획득할 수 있다. 고속 서비스 획득을 위해, FIC뿐만 아니라 베이스 데이터 파이프도 BASE_DP_ID를 이용해서 디코딩 될 수 있다. 베이스 데이터 파이프가 전송하는 콘텐트를 제외하고, 베이스 데이터 파이프는 노멀 데이터 파이프와 정확히 동일한 방식으로 인코딩되어 프레임에 매핑된다. 따라서, 베이스 데이터 파이프에 대한 추가 설명이 필요하지 않다. FIC 데이터가 생성되어 관리 계층에서 소비된다. FIC 데이터의 콘텐트는 관리 계층 사양에 설명된 바와 같다.
FIC 데이터는 선택적이고, FIC의 사용은 PLS2의 스태틱(static, 정적)인 부분에서 FIC_FLAG 파라미터에 의해 시그널링 된다. FIC가 사용되면, FIC_FLAG는 1로 설정되고, FIC에 대한 시그널링 필드는 PLS2의 스태틱(static, 정적)인 부분에서 정의된다. 해당 필드에서 시그널링되는 것은 FIC_VERSION이고, FIC_LENGTH_BYTE. FIC는 PLS2와 동일한 변조, 코딩, 타임 인터리빙 파라미터를 사용한다. FIC는 PLS2_MOD 및 PLS2_FEC와 같은 동일한 시그널링 파라미터를 공유한다. FIC 데이터는 존재한다면 PLS2 후에 매핑되거나, EAC가 존재하는 경우 EAC 직후에 매핑된다. 노멀 데이터 파이프, 보조 스트림, 또는 더미 셀 중 어느 것도 FIC 앞에 위치하지 않는다. FIC 셀을 매핑하는 방법은 EAC와 완전히 동일하고, 이는 다시 PLS와 동일하다.
PLS 후의 EAC가 존재하지 않는 경우, FIC 셀은 (a)의 예에 나타낸 바와 같이 PLS2의 다음 셀부터 셀 인덱스의 오름차순으로 매핑된다. FIC 데이터 사이즈에 따라, (b)에 나타낸 바와 같이, FIC 셀은 수 개의 심볼에 대해서 매핑된다.
FIC 셀은 PLS2의 마지막 셀 직후에 뒤따르고, 매핑은 마지막 FSS의 마지막 셀 인덱스까지 아래방향으로 계속된다. 필요한 FIC 셀의 총 수가 마지막 FSS의 남아 있는 액티브(active) 캐리어의 수를 초과하면, 나머지 FIC 셀의 매핑은 다음 심볼로 진행되며 이는 FSS와 완전히 동일한 방식으로 계속된다. 이 경우, FIC가 매핑되는 다음 심볼은 노멀 데이터 심볼이며, 이는 FSS보다 더 많은 액티브(active) 캐리어를 갖는다.
EAS 메시지가 현 프레임에서 전송되면, EAC는 FIC 보다 먼저 매핑되고 (b)에 나타낸 바와 같이 EAC의 다음 셀부터 FIC 셀은 셀 인덱스의 오름차순으로 매핑된다.
FIC 매핑이 완료된 후, 하나 이상의 데이터 파이프가 매핑되고, 이후 존재한다면 보조 스트림, 더미 셀이 뒤따른다.
도 19는 본 발명의 일 실시예에 따른 FEC 구조를 나타낸다.
도 19는 비트 인터리빙 전의 본 발명의 일 실시예에 따른 FEC 구조를 나타낸다. 전술한 바와 같이, 데이터 FEC 인코더는 외부 코딩(BCH) 및 내부 코딩(LDPC)을 이용하여 FECBLOCK 절차를 생성하기 위해 입력 BBF에 FEC 인코딩을 실행할 수 있다. 도시된 FEC 구조는 FECBLOCK에 해당한다. 또한, FECBLOCK 및 FEC 구조는 LDPC 코드워드의 길이에 해당하는 동일한 값을 갖는다.
도 19에 도시된 바와 같이, BCH 인코딩이 각각의 BBF(Kbch 비트)에 적용된 후, LDPC 인코딩이 BCH - 인코딩된 BBF(Kldpc 비트 = Nbch 비트)에 적용된다.
Nldpc의 값은 64800 비트 (롱 FECBLOCK) 또는 16200 비트 (쇼트 FECBLOCK)이다.
아래의 표 28 및 표 29는 롱 FECBLOCK 및 쇼트 FECBLOCK 각각에 대한 FEC 인코딩 파라미터를 나타낸다.
Figure pct00029
Figure pct00030
BCH 인코딩 및 LDPC 인코딩의 구체적인 동작은 다음과 같다.
12-에러 정정 BCH 코드가 BBF의 외부 인코딩에 사용된다. 쇼트 FECBLOCK 및 롱 FECBLOCK에 대한 BBF 생성 다항식은 모든 다항식을 곱함으로써 얻어진다.
LDPC 코드는 외부 BCH 인코딩의 출력을 인코딩하는 데 사용된다. 완성된 Bldpc (FECBLOCK)를 생성하기 위해, Pldpc (패리티 비트)가 각각의 Ildpc (BCH - 인코딩된 BBF)로부터 조직적으로 인코딩되고, Ildpc에 첨부된다. 완성된 Bldpc (FECBLOCK)는 다음의 수학식으로 표현된다.
Figure pct00031
롱 FECBLOCK 및 쇼트 FECBLOCK에 대한 파라미터는 위의 표 28 및 29에 각각 주어진다.
롱 FECBLOCK에 대해 Nldpc - Kldpc 패리티 비트를 계산하는 구체적인 절차는 다음과 같다.
1) 패리티 비트 초기화
Figure pct00032
2) 패리티 체크 매트릭스의 어드레스의 첫 번째 행에서 특정된 패리티 비트 어드레스에서 첫 번째 정보 비트 i0 누산(accumulate). 패리티 체크 매트릭스의 어드레스의 상세한 내용은 후술한다. 예를 들면, 비율 13/15에 대해,
Figure pct00033
3) 다음 359개의 정보 비트 is, s=1, 2, …, 359에 대해, 다음의 수학식을 이용하여 패리티 비트 어드레스에서 is 누산(accumulate).
Figure pct00034
여기서, x는 첫 번째 비트 i0에 해당하는 패리티 비트 누산기의 어드레스를 나타내고, Qldpc는 패리티 체크 매트릭스의 어드레서에서 특정된 코드 레이트(code rate) 의존 상수이다. 상기 예인, 비율 13/15에 대한, 따라서 정보 비트 i1에 대한 Qldpc = 24에 계속해서, 다음 동작이 실행된다.
Figure pct00035
4) 361번째 정보 비트 i360에 대해, 패리티 비트 누산기의 어드레스는 패리티 체크 매트릭스의 어드레스의 두 번째 행에 주어진다. 마찬가지 방식으로, 다음 359개의 정보 비트 is, s= 361, 362, …, 719에 대한 패리티 비트 누산기의 어드레스는 수학식 6을 이용하여 얻어진다. 여기서, x는 정보 비트 i360에 해당하는 패리티 비트 누산기의 어드레스, 즉 패리티 체크 매트릭스의 두 번째 행의 엔트리를 나타낸다.
5) 마찬가지 방식으로, 360개의 새로운 정보 비트의 모든 그룹에 대해, 패리티 체크 매트릭스의 어드레스로부터의 새로운 행은 패리티 비트 누산기의 어드레스를 구하는 데 사용된다.
모든 정보 비트가 이용된 후, 최종 패리티 비트가 다음과 같이 얻어진다.
6) i=1로 시작해서 다음 동작을 순차적으로 실행
Figure pct00036
여기서 pi, i=0,1,...Nldpc - Kldpc - 1의 최종 콘텐트는 패리티 비트 pi와 동일하다.
Figure pct00037
표 30을 표 31로 대체하고, 롱 FECBLOCK에 대한 패리티 체크 매트릭스의 어드레스를 쇼트 FECBLOCK에 대한 패리티 체크 매트릭스의 어드레스로 대체하는 것을 제외하고, 쇼트 FECBLOCK에 대한 해당 LDPC 인코딩 절차는 롱 FECBLOCK에 대한 t LDPC 인코딩 절차에 따른다.
Figure pct00038
도 20은 본 발명의 일 실시예에 따른 타임 인터리빙을 나타낸다.
(a) 내지 (c)는 타임 인터리빙 모드의 예를 나타낸다.
타임 인터리버는 데이터 파이프 레벨에서 동작한다. 타임 인터리빙의 파라미터는 각각의 데이터 파이프에 대해 다르게 설정될 수 있다.
PLS2-STAT 데이터의 일부에 나타나는 다음의 파라미터는 타임 인터리빙을 구성한다.
DP_TI_TYPE (허용된 값: 0 또는 1): 타임 인터리빙 모드를 나타낸다. 0은 타임 인터리빙 그룹당 다수의 타임 인터리빙 블록(하나 이상의 타임 인터리빙 블록)을 갖는 모드를 나타낸다. 이 경우, 하나의 타임 인터리빙 그룹은 하나의 프레임에 (프레임간 인터리빙 없이) 직접 매핑된다. 1은 타임 인터리빙 그룹당 하나의 타임 인터리빙 블록만을 갖는 모드를 나타낸다. 이 경우, 타임 인터리빙 블록은 하나 이상의 프레임에 걸쳐 확산된다(프레임간 인터리빙).
DP_TI_LENGTH: DP_TI_TYPE = '0'이면, 해당 파라미터는 타임 인터리빙 그룹당 타임 인터리빙 블록의 수 NTI이다. DP_TI_TYPE = '1'인 경우, 해당 파라미터는 하나의 타임 인터리빙 그룹으로부터 확산되는 프레임의 수 PI이다.
DP_NUM_BLOCK_MAX (허용된 값: 0 내지 1023): 타임 인터리빙 그룹당 XFECBLOCK의 최대 수를 나타낸다.
DP_FRAME_INTERVAL (허용된 값: 1, 2, 4, 8): 주어진 피지컬 프로파일의 동일한 데이터 파이프를 전달하는 두 개의 순차적인 프레임 사이의 프레임의 수 IJUMP를 나타낸다.
DP_TI_BYPASS (허용된 값: 0 또는 1): 타임 인터리빙이 데이터 프레임에 이용되지 않으면, 해당 파라미터는 1로 설정된다. 타임 인터리빙이 이용되면, 0으로 설정된다.
추가로, PLS2-DYN 데이터로부터의 파라미터 DP_NUM_BLOCK은 데이터 그룹의 하나의 타임 인터리빙 그룹에 의해 전달되는 XFECBLOCK의 수를 나타낸다.
타임 인터리빙이 데이터 프레임에 이용되지 않으면, 다음의 타임 인터리빙 그룹, 타임 인터리빙 동작, 타임 인터리빙 모드는 고려되지 않는다. 그러나 스케줄러부터의 다이나믹(dynamic, 동적) 구성 정보를 위한 딜레이 컴펜세이션(delay compensation, 지연보상) 블록은 여전히 필요하다. 각각의 데이터 파이프에서, SSD/MIMO 인코딩으로부터 수신한 XFECBLOCK은 타임 인터리빙 그룹으로 그루핑된다. 즉, 각각의 타임 인터리빙 그룹은 정수 개의 XFECBLOCK의 집합이고, 다이나믹(dynamic, 동적)으로 변화하는 수의 XFECBLOCK을 포함할 것이다. 인덱스 n의 타임 인터리빙 그룹에 있는 XFECBLOCK의 수는 NxBLOCK_Group(n)로 나타내고, PLS2-DYN 데이터에서 DP_NUM_BLOCK으로 시그널링된다. 이때, NxBLOCK_Group(n)은 최소값 0에서 가장 큰 값이 1023인 최대값 NxBLOCK_Group_MAX (DP_NUM_BLOCK_MAX에 해당)까지 변화할 수 있다.
각각의 타임 인터리빙 그룹은 하나의 프레임에 직접 매핑되거나 PI개의 프레임에 걸쳐 확산된다. 또한 각각의 타임 인터리빙 그룹은 하나 이상(NTI개)의 타임 인터리빙 블록으로 분리된다. 여기서 각각의 타임 인터리빙 블록은 타임 인터리버 메모리의 하나의 사용에 해당한다. 타임 인터리빙 그룹 내의 타임 인터리빙 블록은 약간의 다른 수의 XFECBLOCK을 포함할 수 있다. 타임 인터리빙 그룹이 다수의 타임 인터리빙 블록으로 분리되면, 타임 인터리빙 그룹은 하나의 프레임에만 직접 매핑된다. 아래의 표 32에 나타낸 바와 같이, 타임 인터리빙에는 세 가지 옵션이 있다(타임 인터리빙을 생략하는 추가 옵션 제외).
Figure pct00039
일반적으로, 타임 인터리버는 프레임 생성 과정 이전에 데이터 파이프 데이터에 대한 버퍼로도 작용할 것이다. 이는 각각의 데이터 파이프에 대해 2개의 메모리 뱅크로 달성된다. 첫 번째 타임 인터리빙 블록은 첫 번째 뱅크에 기입된다. 첫 번째 뱅크에서 판독되는 동안 두 번째 타임 인터리빙 블록이 두 번째 뱅크에 기입된다.
타임 인터리빙은 트위스트된 행-열 블록 인터리버이다. n번째 타임 인터리빙 그룹의 s번째 타임 인터리빙 블록에 대해, 열의 수 Nc 가 NxBLOCK_TI(n,s) 와 동일한 반면, 타임 인터리빙 메모리의 행의 수 Nr 는 셀의 수 Ncells 와 동일하다 (즉, Nr = Ncells).
도 21은 본 발명의 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 기본 동작을 나타낸다.
도 21(a)는 타임 인터리버에서 기입 동작을 나타내고, 도 21(b)는 타임 인터리버에서 판독 동작을 나타낸다. (a)에 나타낸 바와 같이, 첫 번째 XFECBLOCK은 타임 인터리빙 메모리의 첫 번째 열에 열 방향으로 기입되고, 두 번째 XFECBLOCK은 다음 열에 기입되고, 이러한 동작이 이어진다. 그리고 인터리빙 어레이에서, 셀이 대각선 방향으로 판독된다. (b)에 나타낸 바와 같이 첫 번째 행으로부터 (가장 왼쪽 열을 시작으로 행을 따라 오른쪽으로) 마지막 행까지 대각선 방향 판독이 진행되는 동안,
Figure pct00040
개의 셀이 판독된다. 구체적으로,
Figure pct00041
이 순차적으로 판독될 타임 인터리빙 메모리 셀 위치라고 가정하면, 이러한 인터리빙 어레이에서의 판독 동작은 아래 식에서와 같이 행 인덱스
Figure pct00042
, 열 인덱스
Figure pct00043
, 관련된 트위스트 파라미터
Figure pct00044
를 산출함으로써 실행된다.
Figure pct00045
여기서,
Figure pct00046
는
Figure pct00047
에 상관없이 대각선 방향 판독 과정에 대한 공통 시프트 값이고, 시프트 값은 아래 식에서와 같이 PLS2-STAT에서 주어진
Figure pct00048
에 의해 결정된다.
Figure pct00049
결과적으로, 판독될 셀 위치는 좌표
Figure pct00050
에 의해 산출된다.
도 22는 본 발명의 다른 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 동작을 나타낸다.
더 구체적으로, 도 22는
Figure pct00051
,
Figure pct00052
,
Figure pct00053
일 때 가상 XFECBLOCK을 포함하는 각각의 타임 인터리빙 그룹에 대한 타임 인터리빙 메모리에서 인터리빙 어레이를 나타낸다.
변수
Figure pct00054
는
Figure pct00055
보다 작거나 같을 것이다. 따라서,
Figure pct00056
에 상관없이 수신기 측에서 단일 메모리 디인터리빙을 달성하기 위해, 트위스트된 행-열 블록 인터리버용 인터리빙 어레이는 가상 XFECBLOCK을 타임 인터리빙 메모리에 삽입함으로써
Figure pct00057
의 크기로 설정되고, 판독 과정은 다음 식과 같이 이루어진다.
Figure pct00058
타임 인터리빙 그룹의 수는 3으로 설정된다. 타임 인터리버의 옵션은 DP_TI_TYPE='0', DP_FRAME_INTERVAL='1', DP_TI_LENGTH='1', 즉 NTI=1, IJUMP=1, PI=1에 의해 PLS2-STAT 데이터에서 시그널링된다. 각각 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 pct00059
로 이어진다.
도 23은 본 발명의 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 대각선 방향 판독 패턴을 나타낸다.
더 구체적으로, 도 23은 파라미터
Figure pct00060
및 Sshift=(7-1)/2=3을 갖는 각각의 인터리빙 어레이로부터의 대각선 방향 판독 패턴을 나타낸다. 이때 위에 유사 코드로 나타낸 판독 과정에서,
Figure pct00061
이면, Vi의 값이 생략되고, Vi의 다음 계산값이 사용된다.
도 24는 본 발명의 일 실시예에 따른 각각의 인터리빙 어레이로부터의 인터리빙된 XFECBLOCK을 나타낸다.
도 24는 파라미터
Figure pct00062
및 Sshift=3을 갖는 각각의 인터리빙 어레이로부터 인터리빙된 XFECBLOCK을 나타낸다.
도 25 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디 인터리빙을 위한 시그널링을 도시한 도면이다.
전술한 바와 같이, 본 발명에 따른 주파수 인터리버는 OFDM 심볼마다 다른 인터리빙 시퀀스를 사용하여 인터리빙을 수행하나, 주파수 디인터리버는 수신한 OFDM 심볼에 대하여 싱글 메모리 디인터리빙을 수행할 수 있다.
본 발명에서는, 한 프레임 내의 OFDM 심볼 수가 짝수인지 홀수인지에 무관하게 주파수 디인터리버가 싱글 메모리 디인터리빙을 수행할 수 있는 방법을 제안한다. 이를 위하여, OFDM 심볼 수가 짝수개인지 홀수개인지에 따라 전술한 주파수 인터리버의 구조가 다르게 운영될 수 있다. 또한, 이와 관련된 시그널링 정보가 전술한 프리앰블 및/또는 PLS(Physical Layer Signaling) 에 추가로 정의될 수 있다. 이를 통하여 OFDM 심볼의 개수가 짝수인 경우에 한정되지 않고, 언제든지 싱글 메모리 디인터리빙이 가능해질 수 있다.
여기서, PLS 는 매 프레임의 FSS(Frame Starting Symbol, FSS) 에 포함되어 전송될 수 있다. 또는 실시예에 따라, PLS 는 첫번째 OFDM 심볼에 포함되어 전송될 수 있다. 또는 PLS 존재여부에 따라, PLS 에 해당하는 시그널링은 프리앰블에 모두 포함되어 전송될 수 있다. 또는 프리앰블 및/또는 PLS 에 해당하는 시그널링 정보들은 부트 스트랩 정보에 포함되어 전송될 수도 있다. 부트 스트랩 정보는 프리앰블의 앞에 위치하는 정보 파트일 수 있다.
송신부의 주파수 인터리버에서 활용된 처리동작 등에 관한 정보로서, FI_mode 필드와 N_sym 필드가 있을 수 있다.
FI_mode 필드는 프리앰블에 위치할 수 있는 1 비트 필드일 수 있다. FI_mode 필드는 매 프레임의 FSS(Frame Starting Symbol) 또는 첫번째 OFDM 심볼에 사용된 인터리빙 스킴을 나타낼 수 있다.
FI_mode 필드가 지시하는 인터리빙 스킴에는 FI 스킴 #1 와 FI 스킴 #2 가 있을 수 있다.
FI 스킴 #1 은 송신측에서 주파수 인터리버가 FSS 에 대하여, 랜덤 쓰기(random writing) 동작 수행 후 선형 읽기(linear reading) 동작을 수행한 경우를 의미할 수 있다. 이 경우는 FI_mode 필드 값이 0 인 경우에 해당될 수 있다. PRBS 등을 이용한 임의의 랜덤 시퀀스 제너레이터에 의해 발생되는 값을 이용해, 메모리에 랜덤쓰기, 선형 읽기 동작을 수행할 수 있다. 여기서 선형 읽기란 순차적으로 읽어들이는 동작을 의미할 수 있다.
FI 스킴 #2 는 송신측에서 주파수 인터리버가 FSS 에 대하여, 선형 쓰기(linear writing) 동작 수행 후 랜덤 읽기(random reading) 동작을 수행한 경우를 의미할 수 있다. 이 경우는 FI_mode 필드 값이 1 인 경우에 해당될 수 있다. 마찬가지로, PRBS 등을 이용한 임의의 랜덤 시퀀스 제너레이터에 의해 발생되는 값을 이용해, 메모리에 선형쓰기, 랜덤읽기 동작을 수행할 수 있다. 여기서 선형 쓰기란 순차적으로 쓰는 동작을 수행하는 것을 의미할 수 있다.
또한, FI_mode 필드는 매 프레임의 FES(Frame Edge Symbol) 또는 마지막 OFDM 심볼에 사용된 인터리빙 스킴을 나타낼 수 있다. FES 에 적용되는 인터리빙 스킴은 PLS 에 의해 전송되는 N_sym 필드의 값에 따라 다르게 지시될 수 있다. 즉, OFDM 심볼 수가 홀수인지 짝수인지에 따라 FI_mode 필드가 지시하는 인터리빙 스킴이 달라질 수 있다. 두 필드들간의 관계는 미리 송수신측에 테이블로서 정의되어 있을 수 있다.
FI_mode 필드는 실시예에 따라 프리앰블 외에 프레임의 다른 부분에 정의되어 전송될 수 있다.
N_sym 필드는 PLS 파트에 위치할 수 있는 필드일 수 있다. N_sym 필드의 비트수는 실시예에 따라 가변적일 수 있다. N_sym 필드는 한 프레임에 포함된 OFDM 심볼의 개수를 지시할 수 있다. 이에 따라, 수신측에서는 OFDM 심볼의 개수가 짝수개인지 홀수개인지 파악할 수 있다.
전술한 한 프레임 내의 OFDM 심볼 수에 무관한 주파수 인터리버에 대응되는 주파수 디인터리버의 동작은 다음과 같다. 이 주파수 디인터리버는 제안된 시그널링 필드들을 활용하여 OFDM 심볼 수가 짝수인지 홀수인지 여부에 무관하게 싱글 메모리 디인터리빙을 수행할 수 있다.
주파수 디인터리버는 먼저, 프리앰블의 FI_mode 필드의 정보를 이용하여 FSS 에 대하여 주파수 디인터리빙을 수행할 수 있다. FSS 에 활용된 주파수 인터리빙 스킴이 FI_mode 에 의해 지시되기 때문이다.
주파수 디인터리버는 FI_mode 필드의 시그널링 정보와 PLS 의 N_sym 필드의 시그널링 정보를 이용하여, FES 에 대하여 주파수 디인터리빙을 수행할 수 있다. 이 때, 미리 정의된 테이블을 이용하여 두 필드간의 관계가 파악될 수 있다. 기 정의된 테이블에 대하여는 후술한다.
이 외의 심볼들의 전반적인 디인터리빙 과정은, 송신측의 인터리빙 과정의 역순으로 수행될 수 있다. 즉, 입력되는 연속된 한쌍의 OFDM 심볼에 대해서, 주파수 디인터리버는 하나의 인터리빙 시퀀스를 활용하여 디인터리빙을 수행할 수 있다. 여기서, 하나의 인터리빙 시퀀스는 해당 주파수 인터리버가 읽기&쓰기에 사용했던 인터리빙 시퀀스일 수 있다. 주파수 디인터리버는 그 인터리빙 시퀀스를 이용하여 역순으로 읽기&쓰기 과정을 수행할 수 있다.
허나, 본 발명에 따른 주파수 디인터리버는 더블 메모리를 사용하는 핑퐁(ping pong) 구조를 사용하지 않을 수 있다. 주파수 디인터리버는 연속된 입력 OFDM 심볼들에 대하여, 싱글 메모리를 활용해 디인터리빙을 수행할 수 있다. 이로써 주파수 디인터리버의 메모리 사용 효율성이 증대될 수 있다.
도 26 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디 인터리빙을 위한 시그널링에 있어서, FSS 를 위한 FI 스킴들을 도시한 도면이다.
전술한 FI_mode 필드와 N_sym 필드를 이용하여 주파수 인터리빙 과정에서 적용되는 인터리빙 스킴을 결정할 수 있다.
FSS 의 경우에 있어서, N_sym 필드가 지시하는 OFDM 심볼의 수가 짝수인 경우, FI_mode 필드 값에 무관하게 FI 스킴 #1 이 FSS 에 수행될 수 있다.
N_sym 필드가 지시하는 OFDM 심볼의 수가 홀수인 경우, FI_mode 필드가 0 의 값을 가지면, FI 스킴 #1 이 FSS 에 적용되고, 1 의 값을 가지면, FI 스킴 #2 가 FSS 에 적용될 수 있다. 즉, OFDM 심볼의 수가 홀수인 경우, 주파수 인터리빙에 있어 FI 스킴 #1 과 #2 가 번갈아가면서 FSS 에 적용될 수 있다.
도 27 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디 인터리빙을 위한 시그널링에 있어서, FES 를 위한 리셋 모드의 동작을 도시한 도면이다.
FES 에 대한 주파수 인터리빙에 있어서, 전술한 심볼 오프셋 생성기는 리셋 모드(Reset mode) 라는 새로운 개념을 도입할 수 있다. 리셋 모드는, 심볼 오프셋 생성기에 의해 발생되는 심볼 오프셋 값이 '0' 인 모드를 의미할 수 있다.
FES 에 대한 주파수 인터리빙에 있어서, 전술한 FI_mode 필드와 N_sym 필드를 이용하여 리셋 모드의 사용여부를 결정할 수 있다.
N_sym 필드가 지시하는 OFDM 심볼의 수가 짝수인 경우, FI_mode 필드의 값에 무관하게 심볼 오프셋 생성기의 리셋 모드는 동작하지 않을 수 있다(off).
N_sym 필드가 지시하는 OFDM 심볼의 수가 홀수인 경우, FI_mode 필드의 값이 0 일 경우 심볼 오프셋 생성기가 리셋 모드에 따라 동작할 수 있다(on). 또한, FI_mode 필드의 값이 1 일 경우 심볼 오프셋 생성기의 리셋 모드는 동작하지 않을 수 있다(off). 즉, OFDM 심볼의 수가 홀수인 경우, 주파수 인터리빙에 있어 리셋모드가 번갈아가며 온/오프 될 수 있다.
도 28 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 주파수 인터리버의 입력과 출력을 수학식으로 표시한 도면이다.
전술한 바와 같이, 각각의 메모리 뱅크-A 및 메모리 뱅크-B 의 OFDM 심볼 페어들은 전술한 인터리빙 과정에 의해 처리될 수 있다. 전술한 바와 같이, 인터리빙에는 하나의 메인 인터리빙 시드가 순환 천이(cyclic-shifting)되어 생성된 다양한 다른 인터리빙 시드가 활용될 수 있다. 여기서, 인터리빙 시드는 인터리빙 시퀀스라고 칭해질 수도 있다. 또한, 인터리빙 시드는 인터리빙 주소값(interleaving address value) 내지는 주소값(address value), 인터리빙 주소(interleaving address) 라고 칭해질 수 있다. 여기서, 인터리빙 주소값이라는 용어는 복수개의 주소값들의 집합의 의미로 복수의 대상을 지시하는데 사용될 수도 있고, 인터리빙 시드의 의미로 단수의 대상을 지시하는데 사용될 수도 있다. 즉 실시예에 따라, 인터리빙 주소값이라 함은 H(p) 의 각각의 주소값을 의미하거나, H(p) 자체를 의미할 수도 있다.
하나의 OFDM 심볼 내에서 인터리빙될 주파수 인터리빙의 입력은 Om,l 으로 표기될 수 있다(t50010). 여기서, 각각의 데이터 셀들은 xm,l,0, .... xm,l,Ndata-1 로 표기될 수 있다. p 는 셀 인덱스, l 은 OFDM 심볼 인덱스, m 은 프레임의 인덱스를 의미할 수 있다. 즉, xm,l,p 는 m 번째 프레임, l 번째 OFDM 심볼의 p 번째 데이터 셀을 의미할 수 있다. Ndata 는 데이터 셀들의 개수를 의미할 수 있다. Nsym 은 심볼(프레임 시그널링 심볼, 노말 데이터 심볼, 프레임 엣지 심볼)들의 개수를 의미할 수 있다.
전술한 동작에 의해 인터리빙을 거친 후의 데이터 셀들은 Pm,l 로 표기될 수 있다(t50020). 각각의 인터리빙된 데이터 셀들은 vm,l,0, .... vm,l,Ndata-1 로 표기될 수 있다. p, l, m 은 전술한것과 같은 인덱스 값을 가질 수 있다.
도 29 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, FI 스킴 #1 및 FI 스킴 #2 에 따른 주파수 인터리빙의 논리적 동작 매커니즘의 수학식을 나타낸다.
먼저, FI 스킴 #1 에 따른 주파수 인터리빙을 설명한다. 전술한 바와 같이, 각 메모리 뱅크의 인터리빙 시퀀스(인터리빙 주소)를 이용하여 주파수 인터리빙이 수행될 수 있다.
짝수번째 심볼(j mod 2 = 0)에 대한 인터리빙 동작은 도시된 수학식(t51010)과 같이 수학적으로 기술될 수 있다. 입력 데이터 x 에 대하여, 인터리빙 시퀀스(인터리빙 주소)를 이용하여 주파수 인터리빙이 수행되어 출력 v 를 얻을 수 있다. 여기서, p 번째 입력 데이터 x 는, H(p) 번째 출력 데이터 v 와 같아지도록 순서가 섞일 수 있다.
즉, 짝수번째 심볼(첫번째 심볼)에 대해서는, 인터리빙 시퀀스를 이용하여 랜덤 쓰기 과정이 먼저 수행된 후, 다시 이를 순차적으로 읽는 선형 읽기 과정이 수행될 수 있다. 여기서, 인터리빙 시퀀스(인터리빙 주소)는 PRBS 등을 이용한 임의의 랜덤 시퀀스 제너레이터에 의해 발생되는 값일 수 있다.
홀수번째 심볼(j mod 2 = 1)에 대한 인터리빙 동작은 도시된 수학식(t51020)과 같이 수학적으로 기술될 수 있다. 입력 데이터 x 에 대하여, 인터리빙 시퀀스(인터리빙 주소)를 이용하여 주파수 인터리빙이 수행되어 출력 v 를 얻을 수 있다. 여기서, H(p) 번째 입력 데이터 x 는, p 번째 출력 데이터 v 와 같아지도록 순서가 섞일 수 있다. 즉, 짝수번째 심볼에 대한 인터리빙 처리와 비교했을 때, 인터리빙 시퀀스(인터리빙 주소)가 반대로(역으로, inverse) 적용될 수 있다.
즉, 홀수번째 심볼(두번째 심볼)에 대해서는, 순서대로 메모리에 데이터를 쓰는 선형쓰기 동작이 먼저 수행된 후, 다시 이를 인터리빙 시퀀스를 이용하여 랜덤하게 읽는 랜덤 읽기 과정이 수행될 수 있다. 마찬가지로, 인터리빙 시퀀스(인터리빙 주소)는 PRBS 등을 이용한 임의의 랜덤 시퀀스 제너레이터에 의해 발생되는 값일 수 있다.
먼저, FI 스킴 #2 에 따른 주파수 인터리빙을 설명한다.
FI 스킴 #2 에 따른 주파수 인터리빙의 경우, 짝/홀수번째 심볼에 대한 동작이 FI 스킴 #1 과 반대로 수행될 수 있다.
즉, 짝수번째 심볼에 대해서는 도시된 수학식(t51020)에 따라, 선형쓰기 동작 후, 랜덤 읽기 동작이 수행될 수 있다. 또한, 홀수번째 심볼에 대해서는 도시된 수학식(t51010)에 따라, 랜덤쓰기 동작 후, 선형 읽기 동작이 수행될 수 있다. 자세한 사항은, FI 스킴 #1 에서 설명한 것과 같다.
심볼 인덱스 l 은 0, 1, ... , Nsym-1, 셀 인덱스 p 는 0, 1, ... , Ndata - 1 로 표현될 수 있다. 실시예에 따라 짝수번째 심볼과 홀수번째 심볼에 대한 주파수 인터리빙 방식이 서로 뒤바뀔 수 있다. 또한, 실시예에 따라, FI 스킴 #1 과 FI 스킴 #2 에 따른 주파수 인터리빙 방식이 서로 뒤바뀔 수 있다.
도 30 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 짝수인 경우의 실시예를 도시한 도면이다.
본 실시예에서, N_sym 필드는 한 프레임 내에 OFDM 개수가 짝수개임을 지시할 수 있다. 본 실시예에서, 하나의 프레임은 하나의 프리앰블과 8 개의 OFDM 심볼을 가지고 있음을 가정한다. 실시예에 따라 프리앰블 앞에 부트 스트랩 정보가 더 포함될 수 있다. 부트 스트랩 정보는 도시되지 않았다.
본 실시예에서, 한 프레임은 각각 하나의 FSS 와 FES 를 포함할 수 있다. 여기서, FSS 와 FES 의 길이는 같다고 가정한다. 또한, N_sym 필드의 정보는 PLS 파트에 포함되어 전송되므로, 주파수 디인터리버가 FSS 디코딩 후에 이를 확인할 수 있다. 또한, 본 실시예에서, FES 에 대한 동작이 수행되기 이전에 N_sym 필드에 대한 디코딩이 완료된다고 가정한다.
각각의 프레임의 FSS 에서, 심볼 오프셋 생성기의 값은 0 으로 리셋될 수 있다. 따라서, 각 첫번째, 두번째 심볼들은 같은 인터리빙 시퀀스에 의해 처리될 수 있다. 또한, 각 프레임의 시작마다 다시 #0 시퀀스가 동작에 사용될 수 있다. 그 이후 차례대로 #1, #2 시퀀스가 주파수 인터리버/디인터리버의 동작에 사용될 수 있다.
도 31 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 짝수인 경우의 실시예를 도시한 도면이다.
첫번째 프레임에서, 프리앰블의 FI_mode 필드로부터, FSS 가 어떠한 방식으로 인터리빙되었는지에 대한 정보를 얻을 수 있다. 본 실시예는 OFDM 심볼이 짝수개인 경우이므로 FI 스킴 #1 만 사용될 수 있다.
이 후, FSS 가 디코딩되어, N_sym 정보가 획득될 수 있다. N_sym 정보로부터 본 프레임의 심볼 개수가 짝수개임을 알 수 있다. 이 후, 주파수 디인터리버가 FES 를 디코딩하게 될 때, 획득된 FI_mode 정보와 N_sym 정보를 이용하여 디코딩이 수행될 수 있다. 심볼의 개수가 짝수개인 경우이므로, 심볼 오프셋 생성기는 전술한 리셋모드에 따라 동작하지 않는다. 즉, 리셋 모드는 오프(off)된 상태일 수 있다.
이 후 다른 프레임에 대해서도, 짝수개의 OFDM 심볼들이 포함되어 있으므로 주파수 디인터리버가 같은 방식으로 동작할 수 있다. 즉, FSS 에서 사용될 FI 스킴은 FI 스킴 #1 이며, FES 에서 사용될 리셋 모드는 오프(off) 된 상태일 수 있다.
도 32 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 홀수인 경우의 실시예를 도시한 도면이다.
본 실시예에서, N_sym 필드는 한 프레임 내에 OFDM 개수가 홀수개임을 지시할 수 있다. 본 실시예에서, 하나의 프레임은 하나의 프리앰블과 7 개의 OFDM 심볼을 가지고 있음을 가정한다. 실시예에 따라 프리앰블 앞에 부트 스트랩 정보가 더 포함될 수 있다. 부트 스트랩 정보는 도시되지 않았다.
본 실시예에서, 심볼의 개수가 짝수인 경우와 마찬가지로, 한 프레임은 각각 하나의 FSS 와 FES 를 포함할 수 있다. 여기서, FSS 와 FES 의 길이는 같다고 가정한다. 또한, N_sym 필드의 정보는 PLS 파트에 포함되어 전송되므로, 주파수 디인터리버가 FSS 디코딩 후에 이를 확인할 수 있다. 또한, 본 실시예에서, FES 에 대한 동작이 수행되기 이전에 N_sym 필드에 대한 디코딩이 완료된다고 가정한다.
각각의 프레임의 FSS 에서, 심볼 오프셋 생성기의 값은 0 으로 리셋될 수 있다. 또한 임의의 프레임의 FES 에서, FI_mode 필드와 N_sym 필드의 값에 따라 심볼 오프셋 생성기가 리셋모드에 따라 동작할 수 있다. 따라서, 임의의 프레임의 FES에서, 심볼 오프셋 생성기의 값이 0 으로 리셋되거나, 리셋되지 않을 수 있다. 이러한 리셋 과정은 매 프레임마다 교대로 수행될 수 있다.
도시된 첫번째 프레임의 마지막 심볼, FES 에서 심볼 오프셋 생성기의 리셋이 발생될 수 있다. 따라서, 인터리빙 시퀀스는 #0 시퀀스로 리셋될 수 있다. 따라서, 주파수 인터리버/디인터리버는 해당 FES 를 #0 시퀀스에 따라 처리할 수 있다(t54010).
다음 프레임의 FSS 에서는 심볼 오프셋 생성기가 다시 리셋되어 #0 시퀀스가 사용될 수 있다(t54010). 두번째 프레임(프레임 #1) 의 FES 에서는 리셋이 발생되지 않고, 다시 세번째 프레임(프레임 #2) 의 FES 에서는 리셋이 발생될 수 있다.
도 33 는 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 심볼의 개수가 홀수인 경우의 실시예를 도시한 도면이다.
첫번째 프레임에서, 프리앰블의 FI_mode 필드로부터, FSS 가 어떠한 방식으로 인터리빙되었는지에 대한 정보를 얻을 수 있다. OFDM 심볼이 홀수개인 경우이므로 FI 스킴 #1 과 FI 스킴 #2 가 사용될 수 있다. 본 실시예의 첫번째 프레임에서는 FI 스킴 #1 이 사용되었다.
이 후, FSS 가 디코딩되어, N_sym 정보가 획득될 수 있다. N_sym 정보로부터 본 프레임의 심볼 개수가 홀수개임을 알 수 있다. 이 후, 주파수 디인터리버가 FES 를 디코딩하게 될 때, 획득된 FI_mode 정보와 N_sym 정보를 이용하여 디코딩이 수행될 수 있다. 심볼의 개수가 홀수개이고, FI 스킴#1 가 사용된 경우이므로, FI_mode 필드 값은 0임을 알 수 있다. FI_mode 가 0 이므로 심볼 오프셋 생성기는 전술한 리셋모드에 따라 동작할 수 있다. 즉, 리셋 모드는 온(on) 상태일 수 있다.
리셋모드에 따라 동작되어, 심볼 오프셋 생성기는 0 으로 리셋될 수 있다. 두번째 프레임에서 FI_mode 필드 값이 1 이므로, FI 스킴 #2 에 의해 FSS 가 처리되었음을 알 수 있다. 역시, N_sym 필드를 통해, 심볼의 개수가 홀수개임을 알 수 있다. 두번째 프레임의 경우에는 FI_mode 필드 값이 1 이고, 심볼 개수가 홀수개이므로 심볼 오프셋 생성기는 리셋모드에 따라 동작하지 않을 수 있다.
이러한 방식으로, FSS 에서 사용될 FI 스킴은 FI 스킴 #1 과 #2 가 번갈아가며 세팅될 수 있다. 또한, FES 에서 사용될 리셋 모드는 온(on) 과 오프(off) 가 번갈아가며 세팅될 수 있다. 실시예에 따라 매 프레임마다 세팅이 바뀌지 않을 수도 있다.
도 34 은 본 발명의 일 실시예에 따른 프레임 내의 심볼 수에 영향받지 않는 싱글 메모리 디인터리빙을 위한 시그널링에 있어서, 주파수 디인터리버의 동작을 도시한 도면이다.
주파수 디인터리버는 앞서 정의된 FI_mode 필드 및/또는 N_sym 필드의 정보를 이용하여 주파수 디인터리빙을 수행할 수 있다. 전술한 바와 같이 주파수 디인터리버는 싱글 메모리를 이용하여 동작할 수 있다. 기본적으로 주파수 디인터리빙은 송신단에서 수행한 주파수 인터리빙 과정의 역과정을 수행하여 원래의 데이터가 순서가 복원되도록 하는 과정일 수 있다.
전술한 것과 같이, FSS 에 대한 주파수 디인터리빙은 프리앰블의 FI_mode 필드 및 N_sym 필드를 이용하여 얻은 FI 스킴에 관한 정보를 기반으로 동작될 수 있다. FES 에 대한 주파수 디인터리빙은 FI_mode 필드와 N_sym 필드를 통해 리셋 모드의 동작 여부를 파악한뒤 그에 기반하여 동작될 수 있다.
즉, 입력되는 한쌍의 OFDM 심볼에 대하여, 주파수 디인터리버는 주파수 인터리버의 읽기/쓰기 동작의 역과정을 수행할 수 있다. 이 과정에서 하나의 인터리빙 시퀀스가 사용될 수 있다.
단, 전술한 바와 같이 주파수 인터리버는 더블 메모리를 사용하는 핑퐁 구조를 따르지만, 주파수 디인터리버는 싱글 메모리로 디인터리빙을 수행할 수 있다. 이 싱글 메모리 주파수 디인터리빙은 FI_mode 필드 및 N_sym 필드의 정보들을 이용하여 수행될 수 있다. 이 정보들을 통해, OFDM 심볼 개수에 영향을 받지 않고, 홀수개의 OFDM 심볼을 가진 프레임에 대해서도 싱글 메모리 주파수 디인터리빙이 가능할 수 있다.
본 발명에 따른 주파수 인터리버는 OFDM 심볼의 모든 데이터 셀들을 대상으로 주파수 인터리빙을 수행할 수 있다. 주파수 인터리버는 데이터 셀들을, 각 심볼의 가능한(available) 데이터 캐리어에 매핑시키는 동작을 수행할 수 있다.
본 발명에 따른 주파수 인터리버는 FFT 사이즈에 따라 다른 인터리빙 모드로 동작할 수 있다. 예를 들어, FFT 사이즈가 32K 인 경우, 주파수 인터리버는 전술한 FI 스킴 #1 과 같이 짝수번째 심볼에 대해서는 랜덤쓰기/선형읽기 동작을 수행하고, 홀수번째 심볼에 대해서는 선형쓰기/랜덤읽기 동작을 수행할 수 있다. 또한, FFT 사이즈가 16K 또는 8K 인 경우, 주파수 인터리버는 짝수/홀수에 무관하게 모든 심볼들에 대하여 선형읽기/랜덤쓰기 동작을 수행할 수 있다.
인터리빙 모드 전환을 결정하는 FFT 사이즈는 실시예에 따라 변경될 수 있다. 즉, 32K 및 16K 일 경우 FI 스킴 #1 과 같이 동작하고, 8K 일 경우 짝수/홀수에 무관한 동작을 수행할 수도 있다. 또한, 모든 FFT 사이즈에 대해 FI 스킴 #1 과 같이 동작할 수도 있고, 모든 FFT 사이즈에 대해 짝수/홀수에 무관한 동작을 수행할 수도 있다. 또한 실시예에 따라, 특정 FFT 사이즈에 대해서는 FI 스킴 #2 와 같이 동작할 수도 있다.
이러한 주파수 인터리빙은 전술한 인터리빙 시퀀스(인터리빙 주소)를 이용하여 수행될 수 있다. 인터리빙 시퀀스는 전술한대로 오프셋 값을 이용하여 다양하게 생성될 수 있다. 또한, 주소값 체크(address check) 가 수행되어 다양한 인터리빙 시퀀스가 생성될 수 있다.
도 35는 본 발명의 다른 실시예에 따른 variable data-rate 시스템을 나타낸 개념도이다.
구체적으로, 이 도면에 도시된 하나의 전송 슈퍼 프레임은 NTI_NUM개의 TI 그룹들로 구성되며, 각 TI 그룹은 N BLOCK_TI 개의 FEC 블록들을 포함할 수 있다. 이 경우, 각 TI 그룹에 포함된 FEC 블록의 개수는 서로 다를 수 있다. 본 발명의 일 실시예에 따른 TI 그룹은 타임 인터리빙을 수행하기 위한 블록으로 정의될 수 있으며, 상술한 TI 블록 또는 IF와 동일한 의미로 사용될 수 있다.
본 발명에서는 TI 그룹 내에 포함된 FEC 블록들의 개수가 서로 다른 경우, 하나의 트위스티드 로-컬럼 블록 인터리빙 룰(twisted row-column block interleaving rule)을 이용하여 TI 그룹들에 대한 인터리빙을 수행하는 것을 일 실시예로 할 수 있다. 이를 통해 수신기는 단일 메모리를 사용하여 디인터리빙을 수행할 수 있다. 이하에서는 매 TI 그룹마다 FEC 블록 개수가 변할 수 있는 베리어블 비트-레이트 (variable bit-rate, VBR) 전송을 고려한 입력 FEC block의 메모리 배열 방법 및 타임 인터리버의 리딩 (reading) 동작을 설명한다.
도 36은 본 발명의 블록 인터리빙의 라이팅(writing) 및 리딩 (reading) 오퍼레이션의 일 실시예를 나타낸다. 이에 대한 구체적인 내용은 전술하였다.
도 37은 본 발명의 일 실시예에 따른 블록 인터리빙을 나타낸 수학식이다.
도면에 도시된 수학식은 각 TI 그룹 단위로 적용되는 블록 인터리빙을 나타낸다. 수학식에 도시된 바와 같이, 시프트 밸류는 TI 그룹에 포함된 FEC 블록들의 개수가 홀수인 경우 및 짝수인 경우 각각 계산될 수 있다. 즉, 본 발명의 일 실시예에 따른 블록 인터리빙은 FEC 블록들의 개수를 홀수로 만든 후 시프트 밸류를 계산할 수 있다.
본 발명의 일 실싱예에 따른 타임 인터리버는 수퍼 프레임 내에서 가장 큰 FEC 블록 개수를 갖는 TI group을 기준으로 인터리빙과 관련된 파라미터들을 결정할 수 있다. 이를 통해 수신기는 단일 메모리 사용하여 디인터리빙을 수행할 수 있다. 이때, 결정된 FEC 블록을 가장 많이 포함하고 있는 TI 그룹의 FEC 블록 개수보다 적은 FEC 블록을 갖는 TI 그룹에 대해서는 부족한 FEC 블록의 개수에 해당하는 버츄얼 (virtual) FEC 블록들을 추가할 수 있다.
본 발명의 일 실시예에 따른 버츄얼 (virtual) FEC 블록들은 실제 FEC 블록들 앞에 삽입될 수 있다. 이후, 본 발명의 일 실시예에 따른 타임 인터리버는 버츄얼 (virtual) FEC 블록들을 고려하여 하나의 트위스티드 로-컬럼 블록 인터리빙 룰(twisted row-column block interleaving rule)을 이용하여 TI 그룹들에 대한 인터리빙을 수행할 수 있다. 또한 본 발명의 일 실시예에 따른 타임 인터리버는 리딩(reading) 동작에서 버츄얼 (virtual) FEC 블록들에 해당되는 메모리-인덱스 (memory-index)가 발생하는 경우 상술한 스킵 오퍼레이션을 수행할 수 있다. 이후 라이팅 (writing) 동작 시, 입력된 TI 그룹의 FEC 블록들의 개수와 리딩 (reading)시 출력 TI 그룹의 FEC 블록들의 개수를 일치 시킨다. 결과적으로, 본 발명의 일 실시예에 따른 타임 인터리빙에 따르면, 수신기에서 효율적인 싱글-메모리 디인터리빙(single-memory deinterleaving)을 수행하기 위하여 버츄얼 (virtual) FEC 블록을 삽입하더라도 스킵 오퍼레이션을 통해 실제 전송되는 데이터-레이트의 손실은 발생하지 않을 수 있다.
도 38는 본 발명의 일 실시예에 따른 버츄얼 (virtual) FEC 블록들을 나타낸 도면이다.
도면의 좌측은 맥시멈 FEC 블록들의 개수와 TI 그룹에 포함된 실제 FEC 블록들의 개수 및 맥시멈 FEC 블록들의 개수와 실제 FEC 블록들의 개수간의 차이를 나타낸 파라미터 및 버츄얼 (virtual) FEC 블록들의 개수를 도출하기 위한 수학식을 나타낸다.
도면의 우측은 TI 그룹 내에 버츄얼 (virtual) FEC 블록들이 삽입된 실시예를 나타낸다. 이 경우 상술한 바와 같이 버츄얼 (virtual) FEC 블록들은 실제 FEC 블록의 앞에 삽입될 수 있디.
도 39은 본 발명의 일 실시예에 따른 버츄얼 (virtual) FEC 블록들이 삽입된 이후 리딩 (reading) 동작을 나타낸 수학식이다.
도면에 표시된 스킵 오퍼레이션은 리딩(reading) 동작에서 버츄얼 (virtual) FEC 블록들을 스킵하는 역할을 수행할 수 있다.
도 40는 본 발명의 일 실시예에 따른 타임 인터리빙의 프로세스를 나타낸 순서도이다.
본 발명의 일 실시예에 따른 타임 인터리버는 이니셜 밸류(initial value)를 셋업할 수 있다(S67000).
이후 본 발명의 일 실시예에 따른 타임 인터리버는 버츄얼 (virtual) FEC 블록들을 고려하여 실제 FEC 블록들을 라이팅 (writing)할 수 있다(S67100).
이후, 본 발명의 일 실시예에 따른 타임 인터리버는 템포럴 TI 어드레스(temporal TI address)를 생성할 수 있다(S67200).
이후, 본 발명의 일 실시예에 따른 타임 인터리버는 생성된 TI 리딩 어드레스 (reading address)의 가용성 (availiability)를 평가할 수 있다(S67300). 이후, 본 발명의 일 실시예에 따른 타임 인터리버는 최종 TI 리딩 어드레스 (reading address)를 생성할 수 있다(S67400).
이후, 본 발명의 일 실시예에 따른 타임 인터리버는 실제 FEC 블록들을 리딩(reading)할 수 있다(S67500).
도 41은 본 발명의 일 실시예에 따른 시프트 밸류 및 맥시멈 TI 블록의 크기를 결정하는 과정을 나타낸 수학식이다.
본 도면은 TI 그룹이 2개이고, TI 그룹내의 셀의 개수는 30이고, 첫번째 TI 그룹에 포함된 FEC 블록의 개수가 5이고 두번째 TI 블록에 포함된 FEC 블록의 개수가 6인 경우의 실시예를 나타낸다. 맥시멈 FEC 블록의 개수는 6이 되나, 짝수이므로, 시프트 밸류를 구하기 위한 조정된 맥시멈 FEC 블록의 개수는 7이 될 수 있으며, 시프트 밸류는 4로 계산될 수 있다.
도 42 내지 도 44은 이전도면에서 전술한 실시예의 TI 과정을 나타낸 도면이다.
도 42은 본 발명의 일 실시예에 따른 라이팅 (writing) 오퍼레이션을 나타낸다.
이 도면은 이전도면에서 설명한 두 개의 TI 그룹에 대한 라이팅 (writing) 오퍼레이션을 나타낸다.
도면의 왼쪽에 도시된 블록은 TI 메모리 어드레스 어레이(memory address array)를 나타내며, 도면의 오른쪽에 도시된 블록은 연속한 두 개의 TI 그룹들에 대해 각각 버츄얼(virtual) FEC 블록들이 각각 2개 및 1개가 삽입된 경우의 라이팅 (writing) 오퍼레이션을 나타낸다. 상술한 바와 같이 조정된 맥시멈 FEC 블록의 개수는 7이므로, 첫번째 TI 그룹에는 두 개의 버츄얼(virtual) FEC 블록들이 삽입되며, 두번째 TI 그룹에는 한 개의 버츄얼(virtual) FEC 블록이 삽입된다.
도 43은 본 발명의 일 실시예에 따른 리딩 (reading) 오퍼레이션을 나타낸다.
도면의 왼쪽에 도시된 블록은 TI 메모리 어드레스 어레이(memory address array)를 나타내며, 도면의 오른쪽에 도시된 블록은 연속한 두 개의 TI 그룹들에 대해 각각 버츄얼(virtual) FEC 블록들이 각각 2개 및 1개가 삽입된 경우의 리딩 (reading) 오퍼레이션을 나타낸다. 이 경우, 버츄얼(virtual) FEC 블록들에도 실제 FEC 블록과 동일하게 리딩 (reading) 오퍼레이션이 수행될 수 있다.
도 44은 본 발명의 일 실시예에 따른 리딩 (reading) 오퍼레이션에서 스킵 오퍼레이션이 수행된 결과를 나타낸다.
도면에 도시된 바와 같이 두 개의 TI 그룹내에는 버츄얼(virtual) FEC 블록들이 스킵될 수 있다.
도 45 내지 46는 전술한 TI의 역과정인 타임 디인터리빙을 나타낸다.
구체적으로 도 47은 첫번째 TI 그룹에 대한 타임 디인터리빙을 나타내며 도 48는 두번째 TI 그룹에 대한 타임 디인터리빙을 나타낸다.
도 45는 본 발명의 일 실시예에 따른 타임 디인터리빙의 라이팅 (writing) 과정을 나타낸다.
도면의 왼쪽에 도시된 블록은 TI 메모리 어드레스 어레이(memory address array)를 나타내며, 도면의 가운데 도시된 블록은 타임 디인터리버에 입력된 첫번째 TI 그룹을 나타내며, 도면의 오른쪽에 도시된 블록은 연속한 첫번째 TI 그룹에 대해 스킵된 버츄얼(virtual) FEC 블록들을 고려하여 수행된 라이팅 (writing) 과정을 나타낸다.
도면에 도시된 바와 같이, TI 과정에서 스킵된 2 개의 버츄얼 (virtual) FEC 블록들은 정확한 리딩 (reading) 오퍼레이션을 위해 라이팅 (writing) 과정에서 복원될 수 있다. 이 경우, 스킵된 2 개의 버츄얼 (virtual) FEC 블록들의 위치 및 양은 임의의 알고리즘을 통해 추정될 수 있다.
도 46는 본 발명의 다른 실시예에 따른 타임 디인터리빙의 라이팅 (writing) 과정을 나타낸다.
도면의 왼쪽에 도시된 블록은 TI 메모리 어드레스 어레이(memory address array)를 나타내며, 도면의 가운데 도시된 블록은 타임 디인터리버에 입력된 두번째 TI 그룹을 나타내며, 도면의 오른쪽에 도시된 블록은 연속한 두번째 TI 그룹에 대해 스킵된 버츄얼(virtual) FEC 블록들을 고려하여 수행된 라이팅 (writing) 과정을 나타낸다.
도면에 도시된 바와 같이, TI 과정에서 스킵된 1 개의 버츄얼 (virtual) FEC 블록들은 정확한 리딩 (reading) 오퍼레이션을 위해 라이팅 (writing) 과정에서 복원될 수 있다. 이 경우, 스킵된 1 개의 버츄얼 (virtual) FEC 블록들의 위치 및 양은 임의의 알고리즘을 통해 추정될 수 있다.
도 47은 본 발명의 다른 실시예에 따른 타임 디인터리빙의 리딩 (reading) 오퍼레이션을 나타내는 수학식이다.
수신기에서 사용되는 TDI 시프트 밸류는 송신기에서 사용된 시프트 밸류에 의해 결정될 수 있으며, 스킵 오퍼레이션 (skip operation)은 송신부와 유사하게 리딩 (reading) 오퍼레이션에서 버츄얼 (virtual) FEC 블록들을 스킵하는 역할을 수행할 수 있다.
도 48은 본 발명의 일 실시예에 따른 타임 디인터리빙의 프로세스를 나타낸 순서도이다.
본 발명의 일 실시예에 따른 타임 디인터리버는 이니셜 밸류(initial value)를 셋업할 수 있다(S75000).
이후 본 발명의 일 실시예에 따른 타임 인터리버는 버츄얼 (virtual) FEC 블록들을 고려하여 실제 FEC 블록들을 라이팅 (writing)할 수 있다(S75100).
이후, 본 발명의 일 실시예에 따른 타임 인터리버는 템포럴 TDI 어드레스(temporal TDI address)를 생성할 수 있다(S75200).
이후, 본 발명의 일 실시예에 따른 타임 인터리버는 생성된 TDI 리딩 어드레스 (reading address)의 가용성 (availiability)를 평가할 수 있다(S75300). 이후, 본 발명의 일 실시예에 따른 타임 인터리버는 최종 TDI 리딩 어드레스 (reading address)를 생성할 수 있다(S75400).
이후, 본 발명의 일 실시예에 따른 타임 인터리버는 실제 FEC 블록들을 리딩(reading)할 수 있다(S75500).
도 49은 자동 콘텐츠 인식 기반 ETV(enhanced television) 서비스 시스템을 나타낸 도면이다.
도 49에 나타낸 자동 콘텐츠 인식 기반 ETV 서비스 시스템은 방송사 또는 콘텐츠 제공자(100), 다채널 방송사업자(101), 셋톱박스(102), 디지털 TV 수신기 등의 수신기(103), 자동 콘텐츠 인식 서버(또는 자동 콘텐츠 인식 솔루션 제공자)(104)를 포함할 수 있다. 수신기(103)는 ATSC(advanced television system committee)의 정의에 따라 동작할 수 있고, 자동 콘텐츠 인식 기능을 지원할 수 있다. 실시간 방송 서비스(110)는 오디오/비디오 콘텐츠를 포함할 수 있다.
디지털 방송 서비스는 크게 방송사(100)에 의해 제공되는 지상파 방송 서비스와 다채널 방송사업자(101)에 의해 제공되는 케이블 방송 또는 위성 방송 등의 다채널 방송 서비스로 구분될 수 있다. 방송사(100)는 실시간 방송 서비스(110) 및 인헨스먼트 데이터(또는 부가 데이터)(120)를 함께 전송할 수 있다. 이 경우, 도 49에 나타낸 바와 같이, 수신기(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) 방식이 이용될 수 있다. 워터마킹은 디지털 콘텐츠 제공자를 나타내는 정보를 디지털 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅은 특정 정보가 디지털 콘텐츠에 삽입되는 점은 워터마킹과 동일하지만, 콘텐츠 제공자에 관한 정보 대신 콘텐츠 구매자에 관한 정보가 삽입되는 점이 워터마킹과 다르다.
도 50는 본 발명의 일 실시예에 따른 디지털 워터마킹 기술의 흐름을 나타낸 도면이다.
디지털 위성방송의 도입에 따라, 디지털 데이터방송이 새로운 부가 서비스로 나타났다. 대표적인 쌍방향 서비스인 쌍방향 데이터방송은 다양한 부가 서비스를 제공하기 위해 데이터 신호뿐만 아니라 기존 방송 신호를 가입자에게 전송할 수 있다.
디지털 데이터방송은 크게 가상 채널을 이용한 독립형 서비스와 ETV를 통한 방송 관련 서비스로 구분될 수 있다. 독립형 서비스는 방송 이미지 신호 없이 텍스트와 그래픽만을 포함하며 기존 인터넷 웹페이지와 유사한 포맷으로 제공된다. 독립형 서비스의 대표적인 예로 날씨 및 주식 정보 제공 서비스, TV 금융 서비스, 상거래 서비스 등을 들 수 있다. 방송 관련 서비스는 방송 이미지 신호뿐만 아니라 부가적인 텍스트 및 그래픽 정보도 전송한다. 시청자는 방송 관련 서비스를 통해 시청한 방송 프로그램에 관련된 정보를 얻을 수 있다. 예를 들면, 시청자가 드라마를 시청하는 동안 이전 스토리나 촬영장소를 볼 수 있게 하는 서비스가 있다.
디지털 데이터방송의 방송 관련 서비스에서는, ETV 서비스가 자동 콘텐츠 인식 기술을 바탕으로 제공될 수 있다. 자동 콘텐츠 인식이란 장치가 오디오/비디오 콘텐츠를 재생할 때 콘텐츠에 숨겨진 정보를 통해 자동으로 콘텐츠를 인식하는 기술을 말한다.
자동 콘텐츠 인식 기술을 시행할 때 콘텐츠에 관한 정보를 얻기 위해 워터마킹이나 핑거프린팅 방식이 이용될 수 있다. 워터마킹은 디지털 콘텐츠 제공자를 나타내는 정보를 디지털 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅은 특정 정보가 디지털 콘텐츠에 삽입되는 점은 워터마킹과 동일하지만, 콘텐츠 제공자에 관한 정보 대신 콘텐츠 구매자에 관한 정보가 삽입되는 점이 워터마킹과 다르다.
이하 도 50와 관련하여 워터마킹 기술에 대해 구체적으로 살펴본다.
디지털 워터마킹은 제거하기 어려운 방식으로 디지털 신호에 정보를 매립하는 과정이다. 예를 들면, 신호는 음성, 화면, 또는 영상 될 수 있다. 신호가 복제되면, 정보도 복제된 신호에 실린다. 하나의 신호는 동시에 여러 다른 워터마크를 실을 수 있다.
시각적 워터마킹에서, 정보는 화면 또는 영상에서 가시적이다. 일반적으로 정보는 미디어의 소유자를 식별하는 텍스트나 로고이다. TV 방송사가 전송되는 영상의 코너에 로고를 추가하면, 이 또한 시각적 워터마크이다.
비시각적 워터마킹에서, 정보는 디지털 데이터로서 음성, 화면, 또는 영상에 추가되는데, 약간의 정보가 숨겨져 있다는 것을 감지할 수 있어도 그 자체가 인지되지는 못한다. 워터마크는 널리 사용되기 위한 것이어서, 검색하기 쉽게 되어있거나, 한 단체가 디지털 신호에 매립된 비밀메시지를 주고받는 스테가노그래피의 형태일 수 있다. 어느 경우이든, 시각적 워터마킹에서와 같이, 목적은 소유주나 다른 서술 정보를 제거하기 어려운 방식으로 신호에 부착하는 것이다. 숨겨진 매립 정보를 개개인 사이의 통신을 전환하기 위한 수단으로 사용할 수도 있다.
워터마킹의 하나의 응용은 디지털 미디어의 비승인 복제를 방지 또는 저지하기 위한 저작권 보호 시스템에 있다. 이 용도에서는, 복제 장치가 복제 전에 신호로부터 워터마크를 검색하고, 워터마크의 콘텐츠에 따라 복제를 할지 결정한다. 또 다른 응용은 소스 추적에 있다.
워터마크는 배포시마다 디지털 신호에 매립된다. 저작물의 복제물이 나중에 발견되면, 워터마크가 복제물로부터 검색될 수 있고, 배포의 소스가 알려진다. 보도에 따르면 이 기술은 불법적으로 복제된 영화의 소스를 알아내기 위해 사용되어 왔다.
서술 정보가 있는 디지털 사진의 어노테이션은 비시각적 워터마킹의 또 다른 응용이다.
디지털 미디어에 대한 파일형식의 일부가 메타데이터라 불리는 부가 정보를 포함할 수 있는 반면, 디지털 워터마킹은 데이터가 신호 자체에서 전달된다는 점에서 구별된다.
일부 문맥에서 디지털 워터마크라는 문구가 워터마킹된 신호와 커버 신호 사이의 차이를 의미하지만, 매립될 정보는 디지털 워터마크라 불린다. 워터마크가 매립될 신호는 호스트 신호라 불린다.
워터마킹 시스템은 주로 매립(201), 공격(202), 검출(또는 추출)(203)의 세 개의 별개의 단계로 구분된다.
매립(201)에서, 알고리즘은 호스트 및 매립될 데이터를 받아들이고, 워터마킹된 신호를 생성한다.
워터마킹된 신호는 전송 또는 저장되는데, 주로 다른 사람에게 전송된다. 이 사람이 변경을 가하면, 이는 공격(202)이라 불린다. 변경이 악의적이지 않을 수도 있지만, 공격이라는 용어는 저작권 침해자들이 변경을 통해 디지털 워터마크를 제거하려는 저작권 보호 어플리케이션으로부터 발생한다. 여러 가지 변경이 가능할 수 있다. 예를 들면, 데이터의 비가역압축, 이미지 또는 영상의 크로핑, 또는 의도적으로 가하는 잡음 등이 있을 수 있다.
검출(203)은 공격받은 신호에서 워터마크를 추출하기 위해 공격받은 신호에 적용되는 알고리즘이다. 신호가 전송 중에 변경되지 않았다면, 워터마크는 여전히 존재하고 추출될 수 있다. 견고한 워터마킹 어플리케이션에서는, 변경이 강력하더라도 추출 알고리즘은 워터마크를 올바르게 생성할 수 있을 것이다. 취약한 워터마킹에서는, 신호에 어떠한 변경이 가해지더라도 추출 알고리즘은 실패할 것이다.
매립된 정보가 몇 번의 변형에 의해 저하되더라도 마킹된 신호로부터 확실히 검출될 수 있으면 디지털 워터마크는 변형에 대해 견고하다고 한다. 전형적인 이미지 저하는 JPEG 압축, 회전(rotation), 크로핑, 부가적인 잡음 및 양자화이다. 비디오 콘텐츠에 있어서, 일시적 변경 및 MPEG 압축이 주로 여기에 포함된다. 워터마킹된 콘텐츠가 원래의 워터마킹되지 않은 콘텐츠와 지각적으로 동등하면 워터마크는 감지할 수 없다고 한다. 일반적으로, 견고한 워터마크나 감지할 수 없는 워터마크는 생성하기 쉽지만, 견고하고 감지할 수 없는 워터마크는 생성하기 어렵다고 알려져 있다. 견고하고 감지할 수 없는 워터마크는 디지털 콘텐츠의 보호를 위한 도구, 예를 들면, 전문적인 비디오 콘텐츠에서 매립된 "복제 불허" 플래그로서 제안되었다.
디지털 워터마킹 기술은 몇 가지 방식으로 분류될 수 있다.
첫째로, 워터마크는 약간의 변형 후에 검출되지 못하면 취약하다고 한다(견고성). 취약한 워터마크는 보통 탬퍼 검출(무결성 입증)을 위해 사용된다. 분명히 뚜렷한 원저작물에 가한 변형은 보통 워터마크라 불리지 않고, 일반화된 바코드라 불린다. 양성 변형에는 저항력이 있지만 악성 변형 후에는 검출에 실패하는 워터마크는 약간 취약하다고 한다. 약간 취약한 워터마크는 보통 악성 변형을 검출하기 위해 사용된다. 지정된 부류의 변형에 저항력이 있는 워터마크는 견고하다고 한다. 견고한 워터마크는 복제물을 전달하고 제어 정보에 접속하기 위해 복제 방지 어플리케이션에서 사용될 수 있다.
둘째로, 원래의 커버 신호와 마킹된 신호가 지각적으로 구별될 수 없으면(구별되기 어려우면) 워터마크는 감지할 수 없다고 한다(지각성). 마킹된 신호에서의 존재가 분명하지만 비침해적이면, 워터마크는 감지할 수 있다고 한다.
셋째로, 용량에 관해서, 매립된 메시지의 길이는 두 가지 다른 주 부류의 워터마킹 방식을 결정한다.
메시지는 개념상으로 0 비트의 길이를 갖고, 시스템은 마킹된 오브젝트에서 워터마크의 존재 유무를 검출하기 위해 설계된다. 이러한 종류의 워터마킹 방식은 주로 이탤릭 0 비트 또는 이탤릭 존재 워터마킹 방식이라 불린다. 종종 이러한 종류의 워터마킹 방식은 1이 워터마크의 존재를 나타내기 때문에(0은 부재) 1 비트 워터마크라 불린다.
메시지는 n 비트 길이의 스트림이고(n = |m| 또는 M = {0,1}n), 워터마크에서 변조된다. 이러한 종류의 방식은 주로 다중비트 워터마킹 또는 비영비트 워터마킹 방식이라 불린다.
넷째로, 매립 단계에는 몇 가지 방식이 있다. 마킹된 신호가 부가적인 변형에 의해 얻어지면 워터마킹 방법은 대역 확산이라 불린다. 대역 확산 워터마크는 적당히 견고하다고 알려져 있지만, 호스트 간섭으로 인해 낮은 정보 용량을 갖는다고 알려져 있기도 하다. 마킹된 신호가 양자화에 의해 얻어지면 워터마킹 방법은 양자화 타입의 것이라고 한다. 양자화 워터마크는 낮은 견고성을 갖지만, 호스트 간섭의 배제로 인해 높은 정보 용량을 갖는다. 마킹된 신호가 대역 확산법과 유사한 부가적인 변형에 의해 매립되지만 특별히 공간 영역에서 매립되면, 워터마킹 방법은 진폭 변조라 불린다.
도 51은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과 포맷을 나타낸 도면이다.
기존의 자동 콘텐츠 인식 서비스 처리 시스템에 따르면, 방송사가 실시간 서비스를 위한 콘텐츠와 ETV 서비스를 위한 인헨스먼트 데이터를 함께 전송하고, TV 수신기가 콘텐츠와 ETV 서비스를 수신하면, 실시간 서비스를 위한 콘텐츠는 수신될 수 있지만, 인헨스먼트 데이터는 수신되지 못한다.
이 경우, 본 발명의 일 실시예에 따르면, 인터넷 프로토콜 네트워크를 이용한 독립적인 인터넷 프로토콜 시그널링 채널을 통해 기존의 자동 콘텐츠 인식 처리 시스템의 문제를 해결할 수 있다. 즉, TV 수신기는 다채널 방송사업자를 통해 실시간 서비스를 위한 콘텐츠를 수신할 수 있고, 독립적인 인터넷 프로토콜 시그널링 채널을 통해 인헨스먼트 데이터를 수신할 수 있다.
이 경우, 본 발명의 일 실시예에 따르면, 인터넷 프로토콜 시그널링 채널은 PSIP 스트림이 바이너리 스트림의 형태로 전달 및 처리되도록 구성된다. 이때, 인터넷 프로토콜 시그널링 채널은 풀(pull) 방법이나 푸시(push) 방법을 이용하도록 구성된다.
풀 방법의 인터넷 프로토콜 시그널링 채널은 HTTP 요청/응답 방법에 따라 구성될 수 있다. HTTP 요청/응답 방법에 따르면, PSIP 바이너리 스트림은 HTTP 요청 신호에 대한 HTTP 응답 신호에 포함될 수 있고, SignalingChannelURL을 통해 전송될 수 있다. 이 경우, 폴링 사이클은 자동 콘텐츠 인식 쿼리 결과로서 전달된 메타데이터에서 Polling_cycle에 따라 주기적으로 요청될 수 있다. 또한, 갱신될 시간 및/또는 주기에 관련된 정보는 시그널링 채널에 포함되어 전송될 수 있다. 이 경우, 수신기는 인터넷 프로토콜 시그널링 채널로부터 수신한 갱신 시간 및/또는 주기 정보에 근거하여 서버에 시그널링 정보를 요청할 수 있다.
푸시 방법의 인터넷 프로토콜 시그널링 채널은 XMLHTTPRequest 어플리케이션 프로그래밍 인터페이스를 이용하여 구성될 수 있다. XMLHTTPRequest 어플리케이션 프로그래밍 인터페이스가 이용되면, 서버로부터 비동기로 최신 정보를 수신할 수 있다. 이는 수신기 측에서는 XMLHTTPRequest 오브젝트를 통해 서버에게 비주기적으로 시그널링 정보를 요청하는 방법이고, 서버 측에서는 시그널링 정보가 변경되었으면 요청에 응답하여 이 채널을 통해 시그널링 정보를 제공하는 방법이다. 세션의 대기시간에 제한이 있으면, 세션 타임아웃 응답이 생성될 수 있고, 수신기는 세션 타임아웃 응답을 인식하고, 시그널링 정보를 다시 요청하고, 수신기와 서버 사이에서 시그널링 채널을 유지할 수 있다.
인터넷 프로토콜 시그널링 채널을 통해 인헨스먼트 데이터를 수신하기 위해, 수신기는 워터마킹과 핑거프린팅을 이용하여 동작할 수 있다. 핑거프린팅은 콘텐츠 구매자에 관한 정보를 콘텐츠 제공자 대신 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅이 이용되면, 수신기는 콘텐츠를 확인하기 위해 참조 데이터베이스를 검색할 수 있다. 콘텐츠를 확인한 결과는 자동 콘텐츠 인식 쿼리 결과라 불린다. 자동 콘텐츠 인식 쿼리 결과는 TV 시청자에게 제공된 쿼리를 포함하고, 자동 콘텐츠 인식 기능을 실행하기 위해 쿼리의 정보에 대해 대응할 수 있다. 수신기는 자동 콘텐츠 인식 쿼리 결과에 근거하여 ETV 서비스를 제공할 수 있다.
자동 콘텐츠 인식 쿼리 결과에 관한 정보는 워터마크 기반 자동 콘텐츠 인식 시스템 상에서 오디오/비디오 콘텐츠에 삽입/매립되어 전송될 수 있다. 수신기는 워터마크 추출기를 통해 자동 콘텐츠 인식 쿼리 결과 정보를 추출 및 획득한 후, ETV 서비스를 제공할 수 있다. 이 경우, ETV 서비스는 별도의 자동 콘텐츠 인식 서버 없이 제공될 수 있고, 인터넷 프로토콜 네트워크를 통한 쿼리는 생략될 수 있다.
도 51은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과를 나타내는 XML 스키마의 도면이다. 도 51에 나타낸 바와 같이, 자동 콘텐츠 인식 쿼리 결과의 XML 포맷은 결과 코드부(310)를 포함할 수 있고, 자동 콘텐츠 인식 쿼리 결과 타입(300)은 콘텐츠 식별자부(301), NTP(network time protocol) 타임스탬프부(302), 시그널링 채널 정보부(303), 서비스 정보부(304), 기타 식별자부(305)를 포함할 수 있다. 시그널링 채널 정보부(303)는 시그널링 채널 URL부(313), 갱신모드부(323), 폴링 사이클부(333)를 포함할 수 있고, 서비스 정보부(304)는 서비스 네임부(314), 서비스 로고부(324), 서비스 서술부(334)를 포함할 수 있다.
이후, 도 51에 나타낸 자동 콘텐츠 인식 쿼리 결과의 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)는 채널 텍스트 설명을 나타낼 수 있다.
다음은 본 발명의 일 실시예에 따른 도 51에 나타낸 자동 콘텐츠 인식 쿼리 결과의 엘리먼트(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>
도 52는 본 발명의 일 실시예에 따른 콘텐츠 식별자의 구문을 나타낸 도면이다.
도 52는 본 발명의 일 실시예에 따른 ATSC 표준에 따른 콘텐츠 식별자의 구문을 나타낸다. ATSC 콘텐츠 식별자는 수신기에 의해 수신한 콘텐츠를 식별하기 위한 식별자로 사용될 수 있다.
또한 도 52에 도시된 콘텐츠 식별자의 구문은 도 51에서 설명한 자동 콘텐츠 인식 질의 결과 포맷의 콘텐츠 식별자부의 구문이다.
ATSC 콘텐츠 식별자는 유일한 주기를 갖고 TSID(Transmitting Subscriber Identification) 및 하우스 넘버로 구성된 구문이다. 하우스 넘버는 여기에 제약된 바와 같이 TSID의 보유자가 원하는 어떤 넘버이다. 넘버는 TSID의 각각의 값에 대해 유일하다. ATSC 콘텐츠 식별자 구조의 구문은 도 59에 정의된 바와 같다.
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 바이트를 넘지 않도록 하우스 넘버의 형태와 완벽히 일치할 필요는 없다.
또한 본 발명의 일 실시예에 따른 수신기가 도 52에 도시된 콘텐츠 식별자의 구문을 통해 서비스를 전세계적으로 유일하게 식별하지 못할 경우, 본 발명의 일 실시예에수신기는 글로벌 서비스 식별자를 이용하여 서비스를 식별할 수 있다. 본 발명의 일 실시예에 따른 글로벌 서비스 식별자는 도 51에서 설명한 자동 콘텐츠 인식 질의 결과 포맷의 콘텐츠 식별자부에 포함될 수 있다.
이하 [예시 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진 스트링으로 고려한 도 4에서 정의한 content_id 필드의 base64 [5] 인코딩이다. <unique_for>는 도 4에서 정의한 unique_for 필드의 10진 인코딩이다. <end_of_day>는 도 52에서 정의한 end_of_day 필드의 십진 인코딩이다.
상술한 예시들을 통해 정의된 포맷을 가진 ATSC 콘텐츠 식별자는, 자동 콘텐츠 인식 처리 시스템 상에서 컨텐트를 식별하기 위해 사용될 수 있다.
이하 본 발명의 일 실시예에 따른 도 53 및 도 54과 관련하여 워터마킹 및 핑거프린팅 기술을 구현할 수 있도록 설계된 수신기를 살펴본다. 도 53 및 도 54은 설계자의 의도에 따라 다르게 구성될 수 있다.
도 53는 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
구체적으로, 도 53는 워터마킹을 이용하여 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기의 구성의 일례를 나타낸다.
도 53에 나타낸 바와 같이, 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 기반 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 시그널링 테이블을 포함할 수 있다. 더 구체적으로, 도 53에 나타낸 바와 같이, 트랜스포트 프로토콜 디멀티플렉서(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)은 수신한 오디오/비디오 데이터를 처리하여 화면에 표시할 수 있다.
구체적으로, 도 53에 도시된 워터마크 추출기(433)는 외부 입력으로 수신된 오디오/비디오 데이터로부터 워터마크의 형태로 삽입된 데이터(또는 워터마크)를 추출할 수 있다. 워터마크 추출기(433)는 오디오 데이터로부터 워터마크를 추출하거나, 비디오 데이터로부터 워터마크를 추출하거나, 오디오 데이터 및 비디오 데이터로부터 워터마크를 추출할 수 있다. 워터마크 추출기(433)는 추출된 워터마크로부터 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
본 발명의 일 실시예에 따른 수신기는 워터마크 추출기(433)가 획득한 채널 정보 및/또는 콘텐츠 정보를 이용하여, ATSC MH 채널을 튜닝하고 해당 콘텐츠 및/또는 메타데이터를 수신할 수 있다. 또한 본 발명의 일 실시예에 따른 수신기는 인터넷망을 통해 해당 콘텐츠 및/또는 메타데이터를 수신할 수도 있다. 이후에 수신기는 트리거 등을 이용하여 수신된 콘텐츠 및/또는 메타데이터를 디스플레이할 수 있다.
도 54은 본 발명의 또 다른 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
더 구체적으로, 도 54은 워터마킹을 이용하여 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기의 구성의 일례를 나타낸다.
도 54에 도시된 본 발명의 일 실시예에 따른 수신기의 기본 구조는 도 53에 도시된 수신기에 기본 구조와 동일하다. 다만, 도 54에 도시된 수신기는 본 발명의 일 실시예에 따라 핑거프린트 추출기(535) 및/또는 핑거프린트 비교기(536)를 더 포함할 수 있다는 차이점이 있다. 또한, 도 54에 도시된 수신기는 도 53에 도시된 구성 엘리먼트 중 워터마크 추출기(433)를 포함하지 않을 수 있다.
도 54의 기본적인 구성은 도 53에 도시된 수신기의 기본적인 구성과 동일하므로 설명을 생략한다. 이하 핑거프린트 추출기(535) 및/또는 핑거프린트 비교기(536)를 중심으로 수신기의 동작을 설명한다.
핑거프린트 추출기(535)은 외부 입력으로 수신된 A/V 콘텐츠에 삽입된 데이터(또는 시그니쳐; signature)를 추출할 수 있다. 본 발명의 일 실시예에 따른 핑거프린트 추출기(535)는 오디오 콘텐츠로부터 시그니쳐를 추출하거나, 비디오 콘텐츠로부터 시그니쳐를 추출하거나, 또는 오디오 콘텐츠 및 비디오 콘텐츠로부터 시그니쳐를 추출할 수 있다.
핑거프린트 비교기(536)는 A/V 콘텐츠에서 추출된 시그니쳐를 이용하여 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다. 본 발명의 일 실시예에 따른 핑거프린트 비교기(536)는 로컬 서치(local search) 및/또는 원격 서치(remote search)를 통해 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
구체적으로 도 54에 도시된 바와 같이, 핑거프린트 비교기(536)가 저장 장치(537)에 엑세스하여 동작하는 루트를 로컬 서치라 한다. 또한 도 54에 도시된 바와 같이, 핑거프린트 비교기(536)가 인터넷 접속 제어 모듈(538)에 엑세스하여 동작하는 루트를 원격 서치라 한다. 이하 로컬 서치 및 원격 서치에 대해 설명한다.
본 발명의 일 실시예에 따른 로컬 서치에 따르면, 핑거프린트 비교기(535)는 추출된 시그니쳐와 저장 장치(537)에 저장되어 있던 기준 핑거프린트를 비교할 수 있다. 기준 핑거프린트는 핑거프린트 비교기(536)가 추출된 시그니쳐를 처리하기 위해 추가적으로 수신하는 데이터이다.
구체적으로, 핑거프린트 비교기(536)는 추출된 시그니쳐와 기준 핑거프린트를 매칭하여 동일한지 여부를 비교하여 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
비교 결과, 추출된 시그니쳐와 기준 핑거프린트가 동일한 경우, 핑거프린트 비교기(536)는 비교 결과를 어플리케이션으로 전달할 수 있다. 어플리케이션은 비교 결과를 이용하여 추출된 시그니쳐와 관련된 채널 정보 및/또는 콘텐츠 정보를 수신기로 전달할 수 있다.
비교 결과, 추출된 시그니쳐와 기준 핑거프린트가 매칭되지 않거나 기준 핑거프린트가 부족한 경우, 핑거프린트 비교기(536)는 ATSC MH 채널을 통해 새로운 기준 핑거프린트를 수신할 수 있다. 이후에 핑거프린트 비교기(536)는 추출된 시그니쳐와 기준 핑거프린트를 다시 비교할 수 있다.
또한 본 발명의 일 실시예에 따른 원격 서치에 따르면, 핑거프린트 비교기(536)는 인터넷 상의 시그너처 데이터베이서 서버로부터 채널 정보 및/또는 콘텐츠 정보를 수신할 수 있다.
구체적으로, 핑거프린트 비교기(536)는 인터넷 접속 제어 모듈(538)을 통해 인터넷 망에 접속하여 시그너처 데이터베이서 서버에 엑세스할 수 있다. 이후에 핑거프린트 비교기(536)는 추출된 시그니쳐를 쿼리 파라미터로서 시그너처 데이터베이서 서버로 전달할 수 있다.
모든 방송국들이 하나의 통합된 시그너처 데이터베이서 서버를 이용할 경우, 핑거프린트 비교기(536)는 해당 시그너처 데이터베이서 서버로 쿼리 파라미터를 전달할 수 있다. 방송국들이 개별적으로 시그너처 데이터베이서 서버를 운영할 경우, 핑거프린트 비교기(536)는 각각의 시그너처 데이터베이스로 쿼리 파라미터를 전달할 수 있다. 또는 핑거프린트 비교기(536)는 둘 이상의 시그너처 데이터베이서 서버에 동시에 쿼리 파라미터를 전달할 수도 있다.
본 발명의 일 실시예에 따른 수신기는 핑거프린트 비교기(536)가 획득한 채널 정보 및/또는 콘텐츠 정보를 이용하여, ATSC M/H 채널을 튜닝하고 해당 콘텐츠 및/또는 메타데이터를 수신할 수 있다. 이후에 수신기는 트리거 등을 이용하여 수신된 콘텐츠 및/또는 메타데이터를 디스플레이할 수 있다.
도 55은 본 발명의 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
구체적으로, 도 55은 퍼스널라이제이션 서비스(개인화 서비스)를 위한 디지털 방송 수신기(또는 수신기)를 포함하는 개인화 방송 시스템을 나타낸다. 본 발명의 일 실시예에 따른 개인화 서비스는 사용자 정보를 기반으로 사용자에게 적합한 콘텐츠를 선별하여 제공하는 서비스이다. 또한 본 발명의 일 실시예에 따른 개인화 방송 시스템은 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 경우이다.
도 55에 도시된 바와 같이 개인화 방송 시스템은 콘텐츠 제공자(또는 방송사; 707) 및/또는 수신기(700)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기(700)는 PDI 엔진(701), 필터링 엔진(702), PDI 기억 장치(703), 콘텐츠 기억 장치(704), 선언 콘텐츠 모듈(705) 및/또는 UI 모듈(User Interface module; 706)을 포함할 수 있다. 또한 도 55에 도시된 바와 같이 본 발명의 일 실시예에 따른 수신기(700)는 콘텐츠 제공자(707)로부터 콘텐츠 등을 수신할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
본 발명의 일 실시예에 따른 콘텐츠 제공자(707)는 콘텐츠, PDI 설문지(PDI 설문지) 및/또는 필터링 기준을 수신기(700)로 전송할 수 있다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지라 불린다. 본 발명의 일 실시예에 따른 PDI 설문지는, 사용자의 프로파일, 인구통계, 흥미 등에 관한 질문(또는 PDI 질문)들을 포함할 수 있다.
수신기(700)는 콘텐츠 제공자(707)로부터 수신한 콘텐츠, PDI 설문지 및/또는 필터링 기준을 처리할 수 있다. 이하 도 55에 도시된 수신기(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)에 저장될 수 있다. 필터링 방법 및 필터링 기준에 대한 구체적인 내용은 도 57 및 도 58과 관련하여 후술한다.
본 발명의 일 실시예에 따른 UI 모듈(706)은 PDI 엔진(701)로부터 수신한 PDI 질문을 디스플레이하고, 해당 PDI 질문에 대해 사용자로부터 PDI 답변을 수신할 수 있다. 사용자는 디스플레이된 PDI 질문에 대해 리모컨을 이용하여 PDI 답변을 수신기(700)측으로 전달할 수 있다. UI 모듈(706)은 수신한 PDI 답변을 PDI 엔진(701)로 전달할 수 있다.
본 발명의 일 실시예에 따른 선언 콘텐츠 모듈(705)은 PDI 엔진(701)에 엑세스하여 PDI 데이터를 획득할 수 있다. 또한 도 55에 도시된 바와 같이, 선언 콘텐츠 모듈(705)은 콘텐츠 제공자(707)가 제공하는 선언 콘텐츠를 수신할 수 있다. 본 발명의 일 실시예에 따른 선언 콘텐츠는 수신기(700)에서 실행되는 어플리케이션에 관한 콘텐츠로서, TDO와 같은 DO를 포함할 수 있다.
또한 도 55에는 도시되지 않았으나, 본 발명의 일 실시예에 따른 선언 콘텐츠 모듈(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)는 필터링된 콘텐츠를 저장할 수 있다.
상술한 바와 같이, 도 55에 도시된 PDI 엔진(701)은 콘텐츠 제공자(707)로부터 PDI 설문지(Questionnaire)를 수신할 수 있다. 수신기(700)는 UI 모듈(706)을 통해 수신한 PDI 설문지의 PDI 질문을 디스플레이하고, 해당 PDI 질문에 대한 PDI 답변을 사용자로부터 수신할 수 있다. PDI 엔진(701)은 PDI 질문 및/또는 PDI 답변을 포함한 PDI 데이터를 필터링 엔진(702)로 전달할 수 있다. 필터링 엔진(702)은 PDI 데이터와 필터링 기준을 통해 콘텐츠를 필터링할 수 있다. 따라서 수신기(700)는 필터링된 콘텐츠를 사용자에게 제공함으로써 개인화 서비스를 구현할 수 있다.
도 56은 본 발명의 다른 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
구체적으로, 도 56은 개인화 서비스를 위한 수신기를 포함하는 개인화 방송 시스템의 구조를 나타낸 것이다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 이하에서는 개인화 방송 시스템의 구성 엘리먼트들에 대해 설명한다.
도 56에 도시된 바와 같이 개인화 방송 시스템은 콘텐츠 제공자(또는 방송국; 807) 및/또는 수신기(700)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기(800)는 PDI 엔진(801), 필터링 엔진(802), PDI 기억 장치(803), 콘텐츠 기억 장치(804), 선언 콘텐츠 모듈(805), UI 모듈(806), 사용 모니터링 엔진(808) 및/또는 사용 로그 모듈(809)을 포함할 수 있다. 또한 도 55에 도시된 바와 같이 본 발명의 일 실시예에 따른 수신기는 콘텐츠 제공자(807)로부터 콘텐츠 등을 수신할 수 있다. 도 56의 기본적인 모듈들은 도 55의 모듈들과 동일하며, 다만 도 55의 방송 시스템과는 달리 도 56의 방송 시스템은 사용 모니터링 엔진(808) 및/또는 사용 로그 모듈(809)을 더 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 사용 모니터링 엔진(808) 및 사용 로그 모듈(809)을 중심으로 설명한다.
본 발명의 일 실시예에 따른 사용 로그 모듈(809)은 사용자의 방송 서비스 사용 내역에 대한 정보(또는 히스토리 정보)를 저장할 수 있다. 히스토리 정보는 2 이상의 사용 데이터를 포함할 수 있다. 본 발명의 일 실시예에 따른 사용 데이터는 일정 시간 동안 사용자가 어떤 방송 서비스를 이용하였는지에 관한 정보를 의미한다. 구체적으로, 사용 데이터는 오후 9시에 뉴스를 40분간 시청했다는 정보, 오후 11시에 공포 영화를 다운로드했다는 정보 등을 포함할 수 있다.
본 발명의 일 실시예에 따른 사용 모니터링 엔진(808)은 사용자의 방송 서비스 사용 현황을 지속적으로 모니터링할 수 있다. 이후에 사용 모니터링 엔진(808)은 모니터링 결과를 이용하여 사용 로그 모듈(809)에 저장된 사용 데이터를 삭제, 추가 및/또는 수정할 수 있다. 또한 본 발명의 일 실시예에 따른 사용 모니터링 엔진(808)은 사용 데이터를 PDI 엔진(801)로 전달할 수 있으며, PDI 엔진(801)은 전달된 사용 데이터를 이용하여 PDI 데이터를 갱신할 수 있다.
도 57는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 57는, 도 55 및 도 56에서 설명한 개인화 방송 시스템의 필터링 엔진 및 PDI 엔진의 동작을 나타낸 플로우 차트이다.
도 57에 도시된 바와 같이, 본 발명의 일 실시예에 따른 수신기(900)는 필터링 엔진(901) 및/또는 PDI 엔진(902)을 포함할 수 있다. 이하 본 발명의 일 실시예에 따른 필터링 엔진(901) 및 PDI 엔진(902)의 동작을 설명한다. 상술한 수신기의 구조는 설계자의 의도에 따라 달라질 수 있다.
도 55에서 설명한 바와 같이, 콘텐츠를 필터링하기 위해, 본 발명의 일 실시예에 따른 수신기(900)는 필터링 기준과 PDI 데이터를 매칭시켜 비교할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 필터링 엔진(901)은 콘텐츠 제공자로부터 필터링 기준을 수신하고, PDI 엔진(902)에 PDI 데이터를 요청하는 신호(또는 PDI 데이터 요청 신호)를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(902)은 전달된 PDI 데이터 요청 신호에 따라, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색할 수 있다.
도 57에 도시된 필터링 엔진(901)은 기준 ID(identifier)를 포함하는 PDI 데이터 요청 신호를 PDI 엔진(902)으로 전달할 수 있다. 상술한 바와 같이 필터링 기준은 필터링 기준들의 집합으로서, 각각의 필터링 기준은 필터링 기준을 식별하기 위한 기준 ID를 포함할 수 있다. 또한 본 발명의 일 실시예에 따른 기준 ID는 PDI 질문 및/또는 PDI 답변을 식별하기 위해 사용될 수 있다.
PDI 데이터 요청 신호를 수신한 PDI 엔진(902)은 PDI 기억 장치에 엑세스하여 PDI 데이터를 검색할 수 있다. 본 발명의 일 실시예에 따른 PDI 데이터는 PDI 질문 및/또는 PDI 답변을 식별하기 위한 PDI 데이터 ID를 포함할 수 있다. 도 57에 도시된 PDI 엔진(902)은 기준 ID와 PDI 데이터 ID를 매칭시켜 기준 ID와 PDI 데이터 ID가 동일한지 여부를 비교할 수 있다.
매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하고, 이에 대한 값이 동일한 경우, 수신기(900)는 해당 콘텐츠를 다운로드할 수 있다. 구체적으로, 본 발명의 일 실시예에 따른 필터링 엔진(901)은 콘텐츠를 다운로드하기 위한 다운로드 요청 신호를 콘텐츠 제공자에게 전달할 수 있다.
매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하지 않은 경우, 도 57에 도시된 바와 같이 PDI 엔진(902)은 필터링 엔진(901)으로 널(null) ID(identifier)를 전달할 수 있다. 널 ID를 수신한 필터링 엔진(901)은 새로운 PDI 데이터 요청 신호를 PDI 엔진(902)으로 전달할 수 있다. 이 경우 새로운 PDI 데이터 요청 신호는 새로운 기준 ID를 포함할 수 있다.
본 발명의 일 실시예에 따른 수신기(900)는, 상술한 방법에 따라 필터링 기준에 포함된 모든 필터링 기준과 PDI 데이터를 매칭시킬 수 있다. 매칭 결과, 모든 필터링 기준이 PDI 데이터와 매칭되는 경우, 필터링 엔진(901)은 콘텐츠를 다운로드하기 위한 다운로드 요청 신호를 콘텐츠 제공자에게 전달할 수 있다.
도 58은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 58은, 도 55 및 도 56에서 설명한 개인화 방송 시스템의 필터링 엔진 및 PDI 엔진의 동작을 나타낸 플로우 차트이다.
도 58에 도시된 바와 같이, 본 발명의 일 실시예에 따른 수신기(1000)는 필터링 엔진(1001) 및/또는 PDI 엔진(1002)를 포함할 수 있다. 상술한 수신기의 구조는 설계자의 의도에 따라 달라질 수 있다. 도 58에 도시된 필터링 엔진(1001) 및 PDI 엔진(1002)의 기본적인 동작은 도 57에서 설명한 바와 같다.
다만, 필터링 기준과 PDI 데이터의 매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하지 않은 경우, 도 58에 도시된 수신기(1000)는 해당 콘텐츠를 다운로드하지 않는 것을 일 실시예로 할 수 있다.
구체적으로, 본 발명의 필터링 엔진(1001)은 널 ID를 수신할 경우, 새로운 PDI 데이터 요청 신호를 PDI 엔진(1002)에 전달하지 않는 것을 일 실시예로 할 수 있다. 또한 필터링 기준에 포함된 모든 필터링 기준이 PDI 데이터와 매칭되지 않을 경우, 본 발명의 필터링 엔진(1001)은 다운로드 요청 신호를 콘텐츠 제공자에게 전달하지 않는 것을 일 실시예로 할 수 있다.
도 59은 본 발명의 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
상술한 도 55의 개인화 방송 시스템은 개인화 서비스를 제공하기 위해 PDI 데이터를 사용하며, PDI 데이터는 PDI 테이블 형식으로 처리될 수 있다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지 또는 PDI 테이블이라 불린다. 데이터 구조는 사용 가능할 때 답변을 포함할 수 있지만, PDI 테이블은 네트워크, 방송사, 또는 콘텐츠 제공자에 의해 제공되므로 답변 데이터를 포함하지 않는다. PDI 테이블에서 엔트리의 질문 부분은 비공식적으로 "PDI-질문" 또는 "PDI-Q"라 불린다. 주어진 PDI 질문에 대한 답변은 비공식적으로 "PDI-A"라 불린다. 필터 기준의 집합은 비공식적으로 "PDI-FC"라 불린다. 본 발명의 PDI 테이블은 XML 스키마로 표현되는 것을 일 실시예로 한다. 본 발명의 일 실시예에 따른 PDI 테이블의 포맷은 설계자의 의도에 따라 변경 가능하다.
도 59에 도시된 바와 같이, 본 발명의 일 실시예에 따른 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)를 포함할 수 있다. 이하 도 59에 도시된 PDI 테이블의 구성 엘리먼트들에 대해 설명한다.
구체적으로, 도 59에 도시된 속성(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 답변을 포함할 수 있다.
도 60는 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로 도 60는, 도 59에서 설명한 PDI 타입 엘리먼트 중 QIA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 60에 도시된 바와 같이, QIA 엘리먼트는 PDI 질문 타입과 관련된 특징에 관한 정보를 지시하는 속성(1210), id 속성(1220), 질문 엘리먼트(1230) 및/또는 답변 엘리먼트(1240)를 포함할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 속성(1210)은 PDI 질문의 언어를 지시하는 lang 속성을 포함할 수 있다. 또한 본 발명의 일 실시예에 따른 QIA 엘리먼트의 속성(1210)은 PDI 답변이 가질 수 있는 최소의 정수값을 지시하는 minInclusive 속성(1230) 및/또는 PDI 답변이 가질 수 있는 최대의 정수값을 지시하는 maxInclusive 속성(1240)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 id 속성(1220)는 PDI 질문 및/또는 PDI 답변을 식별하는 데 사용될 수 있다.
또한 본 발명의 일 실시예에 따른 질문 엘리먼트(1230)는 PDI 질문 자체를 포함할 수 있다. 도 60에 도시된 바와 같이, 질문 엘리먼트(1230)는 PDI 질문에 관한 정보를 지시하는 속성을 포함할 수 있다. 예를 들어, 질문 엘리먼트(1230)는 PDI 질문이 생성된 시간 또는 PDI 질문이 전송된 시간을 지시하는 time 속성(1231) 및/또는 PDI 질문의 유효시간을 지시하는 expiration(만료) 속성(1232)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 답변 엘리먼트(1240)는 PDI 답변 자체를 포함한다. 도 60에 도시된 바와 같이 답변 엘리먼트(1240)는 PDI 답변에 관한 정보를 지시한 속성을 포함할 수 있다. 예를 들어, 도 60에 도시된 바와 같이 답변 엘리먼트(1240)는 각각의 PDI 답변을 인식하기 위해 사용될 수 있는 id 속성(1241) 및/또는 각각의 PDI 답변이 생성되거나 수정된 시간을 지시하는 time 속성(1242)를 포함할 수 있다.
도 61은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 61은 도 59에서 설명한 PDI 타입 엘리먼트 중 QBA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 61에 도시된 바와 같이, QBA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 60에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
도 62는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 62는 도 59에서 설명한 PDI 타입 엘리먼트 중 QSA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 62에 도시된 QSA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 60에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
다만, 다중 선택 질문의 특성에 따라, 본 발명의 일 실시예에 따른 QSA 엘리먼트의 속성은 minChoice 속성(1411) 및/또는 maxChoice 속성(1412)을 더 포함할 수 있다. 본 발명의 일 실시예에 따른 minChoice 속성(1411)은 사용자가 선택할 수 있는 PDI 답변의 최소 개수를 지시할 수 있다. 본 발명의 일 실시예에 따른 maxChoice 속성(1412)은 사용자가 선택할 수 있는 PDI 답변의 최대 개수를 지시할 수 있다.
도 63는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 63은 도 59에서 설명한 PDI 타입 엘리먼트 중 QAA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 63에 도시된 바와 같이, QAA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 60에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
도 64은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 64은 도 59 내지 도 63에서 설명한 PDI 테이블과 마찬가지로 PDI 테이블의 확장된 포맷을 XML 스키마로 나타낸 도면이다.
상술한 바와 같이 본 발명에서는 개인화 서비스를 제공하기 위해 PDI 테이블을 사용하는 것을 일 실시예로 한다. 하지만 동일한 사용자라 하더라도, 사용자가 속한 상황에 따라 선호하는 콘텐츠가 달라질 수 있다.
따라서 본 발명에서는 상술한 문제점을 해결하기 위하여 PDI 테이블에 사용자의 상황 정보를 지시하는 구성 엘리먼트를 더 추가하는 것을 일 실시예로 할 수 있다.
도 64에 도시된 PDI 테이블은 사용자의 상황 정보를 지시하는 구성 엘리먼트로서 상황 엘리먼트(1600)를 더 포함할 수 있다. 도 64에 도시된 PDI 테이블의 기본적인 XML 스키마는 도 59 내지 도 63에서 설명한 바와 동일하므로 구체적인 설명은 생략한다. 이하 상황 엘리먼트(1600)를 설명한다.
본 발명의 일 실시예에 따른 상황 엘리먼트(1600)는 사용자의 상황 정보로서 시간대 및/또는 위치에 관한 정보를 지시할 수 있다. 도 64에 도시된 바와 같이, 상황 엘리먼트(1600)는 시간 엘리먼트(1610), 위치 엘리먼트(1620) 및/또는 사용자의 상황 정보를 나타내는 그 밖의 엘리먼트들을 더 포함할 수 있다. 이하 각 엘리먼트를 설명한다.
본 발명의 일 실시예에 따른 시간 엘리먼트(1610)는 사용자가 속한 지역의 시간과 관련된 정보를 포함할 수 있다. 예를 들어, 본 발명의 일 실시예에 따른 시간 엘리먼트(1610)는 "yyyy-mm-dd" 형식의 시간 정보를 지시하는 time 속성(1610) 및/또는 사용자가 속한 지역의 시간대를 지시하는 timezone 속성(1612)을 포함할 수 있다.
본 발명의 일 실시예에 따른 위치 엘리먼트(1620)는 사용자가 속해 있는 지역의 위치 정보를 포함할 수 있다. 예를 들어, 도 64에 도시된 바와 같이, 장소 엘리먼트(1620)는 해당 위치의 정보를 지시하는 location-desc 속성(1621), 해당 위치의 위도 정보를 지시하는 latitude 속성(1622) 및/또는 해당 위치의 경도 정보를 지시하는 longitude 속성(1623)을 포함할 수 있다.
도 65 및 도 66는 본 발명의 또 다른 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 65 및 도 66은, 도 59 내지 도 64에서 설명한 XML 스키마에 따른 PDI 테이블의 일 실시예를 나타낸 도면이다.
도 65 및 도 66은 PDI 테이블 경우 문서의 구조를 정의하는 PDI 테이블이라 불리는 루트 엘리먼트에 대한 XML 스키마 정의를 나타낸다. 본 발명의 일 실시예에 따른 PDI 테이블 경우 문서는 PDI 테이블을 XML 스키마에 따라 구현한 실제 문서를 의미한다.
도 65 및 도 66은 또한 PDI API를 이용하여 DO와 내재된 수신기 사이에서 주고 받을 수 있는 개별 질문을 나타내는 루트 엘리먼트 QIA, QBA, QSA, QTA, 또는 QAA에 대한 XML 스키마 정의도 나타낸다. 본 발명의 일 실시예에 따른 PDI API에 대한 구체적인 내용은 후술한다. 도 65 및 도 66에 나타낸 엘리먼트는 명칭 공간이 "http://www.atsc.org/XMLSchemas/iss/pdi/1"인 XML 스키마에서의 정의를 따를 수 있다.
PDI 질문(또는 PDI-Q)과 PDI 답변(또는 PDI-A) 사이의 차이는 스키마 자체보다는 사용 규칙에 명시되어 있다. PDI 테이블에서 엔트리의 질문 부분은 비공식적으로 "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 answer question), QTA (textual-answer type question), 및/또는 QAA (any-format answer type question) 타입의 하나 이상의 엘리먼트로 구성된다.
이들 각 엘리먼트는 적어도 하나의 "A" (답변) 하위 엘리먼트를 갖는다. 이들은 "Q" (질문 스트링) 하위 엘리먼트를 포함할 수도 있고 포함하지 않을 수도 있다.
이들 각 엘리먼트에서 식별자 속성("id")은 PDI-Q 경우 문서에서 해당하는 엘리먼트에 대한 연결 또는 기준의 역할을 할 수 있다.
이하 도 65 및 도 66에 도시된 PDI 테이블에 포함된 엘리먼트 및 속성의 시맨틱스(semantics)에 대해 설명한다.
도 65 및 도 66에 도시된 바와 같이, 본 발명의 일 실시예에 따른 PDI 테이블에서는 속성의 명칭 앞에"@"를 표시함으로써 속성과 엘리먼트를 구분할 수 있다.
또한 본 발명의 일 실시예에 따른 PDI 테이블은 PDI 타입 엘리먼트를 포함할 수 있다. 구체적으로, PDI 타입 엘리먼트는 도 59에서 설명한 바와 같이 QIA 엘리먼트, QBA 엘리먼트, QSA 엘리먼트, QTA 엘리먼트 및/또는 QAA 엘리먼트를 포함할 수 있다.
또한 도 65 및 도 66에 도시된 바와 같이, 본 발명의 일 실시예에 따른 PDI 테이블은 질문 타입 엘리먼트와 무관하게 protocolVersion 속성, pdiTableId 속성, pdiTableVersion 속성 및/또는 time 속성을 포함할 수 있다.
QIA, QBA, QSA, QTA and QAA 엘리먼트의 id 속성은 이들 각 엘리먼트의 expiration 속성과 마찬가지로 모두 같은 시맨틱스를 갖는다. 유사하게, 각 A 엘리먼트의 time 속성과 마찬가지로 각 Q 엘리먼트의 lang 속성은 각각 같은 시맨틱스를 갖는다. 또한, id 속성은 도 57에서 상술한 PDI 데이터 식별자를 의미할 수 있다.
PDITable 엘리먼트는 하나 이상의 질문 엘리먼트의 리스트를 포함한다. 각각은 QIA, QBA, QSA, QTA, 또는 QAA의 포맷으로 되어 있다. 카디널리티(cardinality) 0..N로 구성된 <choice>의 사용은 QIA, QBA, QSA, QTA and QAA 엘리먼트의 어떤 수라도 어떤 순서로 나타날 수 있다는 것을 의미한다.
PDITable 엘리먼트의 protocolVersion 속성은 2개의 16진 숫자로 구성된다. 상위 4비트는 테이블 정의의 메이저(major) 버전 수를 나타낸다. 하위 4비트는 테이블 정의의 마이너(minor) 버전 수를 나타낸다. 해당 표준의 해당 버전에 대한 메이저 버전 수는 1로 설정된다. 수신기들은 지원하도록 준비되지 않은 메이저 버전 수를 나타내는 PDI의 경우를 버리도록 되어 있다. 해당 표준의 해당 버전에 대한 마이너 버전 수는 0으로 설정된다. 수신기들은 지원하도록 준비되지 않은 마이너 버전 수를 나타내는 PDI의 경우를 버리지 않도록 되어 있다. 이 경우, 수신기들은 지원하지 않는 개별 엘리먼트 또는 속성을 무시하도록 되어 있다.
PDITable 엘리먼트의 pdiTableId 속성은 해당 PDI 테이블 엘리먼트의 전세계적으로 유일한 식별자일 수 있다.
PDITable 엘리먼트의 8비트의 pdiTableVersion 속성은 해당 PDI 테이블 엘리먼트의 버전을 나타낸다. 초기값은 0이될 수 있다. 해당 값은 255 이후 롤오버(rollover)가 0으로 해당 PDI 테이블 엘리먼트가 변화할 때마다 1씩 증분될 수 있다.
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 엘리먼트는 불 값을 가질 수 있다. 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 하위 엘리먼트가 있으면, 각각은 같은 의미를 같는 같은 수의 Selection 하위 엘리먼트를 갖는다.
QSA.Q.Selection의 QSA.Q.Selection.id 속성은 QSA.Q의 범위 내에서 유일한 Selection 엘리먼트에 대한 식별자일 수 있다. 동일한 QSA 엘리먼트에 (다른 언어로) 다수의 QSA.Q 하위 엘리먼트가 있으면, 그들의 같은 의미를 갖는 Selection 엘리먼트의 id 속성 사이에는 일대일 대응이 있을 수 있다.
QSA.A는 QSA 엘리먼트의 하위 엘리먼트다. 해당 QSA 엘리먼트의 하위 엘리먼트의 각 경우는 Selection 엘리먼트 중 하나의 id 값의 형태로 해당 selection 타입 질문에 허용된 하나의 답변을 명시할 수 있다.
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 엘리먼트의 expire 엘리먼트는 그것이 나타나는 엘리먼트가 더 이상 관련되어 있지 않아 테이블에서 삭제되는 날짜 및 시간을 나타낼 수 있다.
QIA.Q, QBA.Q, QSA.Q, QTA.Q, QTA.A 엘리먼트의 lang 속성은 질문 또는 답변 스트링의 언어를 나타낼 수 있다. QSA.Q의 경우, lang 속성은 QSA.Q의 Selection 하위 엘리먼트의 언어도 나타낼 수 있다. lang 속성이 존재하지 않으면, 이는 해당 언어가 영어임을 나타낼 수 있다.
QIA.A, QBA.A, QSA.A, QTA.A, QAA.A 엘리먼트의 time 속성은 답변이 테이블에 입력된 날짜 및 시간을 나타낼 수 있다.
또한 도 65 및 도 66에 도시되지는 않았으나, 본 발명의 일 실시예에 따른 PDI 테이블은 QIAD 엘리먼트, QBAD 엘리먼트, QSAD 엘리먼트, QTAD 엘리먼트, 및/또는 QAAD 엘리먼트를 더 포함할 수 있다. 상술한 엘리먼트들은 통틀어 QxAD 엘리먼트라 불린다. 이하, QxAD 엘리먼트에 대해 설명한다.
루트 엘리먼트로서의 QIAD 엘리먼트는 QIA 하위 엘리먼트에서 정수 답변 타입의 질문을 포함할 수 있다. QIA는 답변의 최대 및 최소 허용값을 명시하는 선택적 허용치를 포함할 수 있다.
루트 엘리먼트로서의 QBAD 엘리먼트는 질문의 불 답변 타입을 나타낼 것이다.
루트 엘리먼트로서의 QSAD 엘리먼트는 질문의 선택 답변 타입을 나타낼 것이다.
루트 엘리먼트로서의 QTAD 엘리먼트는 질문의 텍스트 답변(서술형 엔트리) 타입을 나타낼 것이다.
루트 엘리먼트로서의 QAAD 엘리먼트는 데이터베이스에서의 엔트리와 같이 다양한 타입의 정보를 보유하도록 사용될 것이다.
또한 도 65 및 도 66에 도시되지는 않았으나, 본 발명의 일 실시예에 따른 각각의 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 속성은 Selection 엘리먼트 중 하나의 id 값 형태로 해당 선택 타입 질문에 대해 허용된 하나의 답변을 명시할 것이다.
QTA.Q.QText 엘리먼트는 QTA 엘리먼트의 하위 엘리먼트다. QTA.Q.QText 엘리먼트의 값은 사용자에게 제시될 질문 스트링을 나타낼 것이다. 질문은 서술형 답변을 갖도록 표현되어야 한다.
QTA.A.answer 속성은 QTA 엘리먼트의 하위 엘리먼트다. QTA.A.answer 엘리먼트의 값은 QTA.Q.QText 엘리먼트에서 질문에 대한 답변을 나타낸다.
도 67 및 도 68는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 67 및 도 68은, 도 59 내지 도 64에서 설명한 XML 스키마에 따른 PDI 테이블의 구조를 나타낸 도면이다.
도 67 및 도 68에 도시된 PDI 테이블의 기본적인 구조와 PDI 테이블에 포함된 기본적인 엘리먼트 및 속성의 시맨틱스는 도 65 및 도 66에서 설명한 바와 같다. 다만 도 65 및 도 66에 도시된 PDI 테이블과는 달리, 도 67 및 도 68에 도시된 PDI 테이블은 xactionSetId 속성 및/또는 text 속성을 더 포함할 수 있다. 이하 xactionSetId 속성 및/또는 text 속성을 중심으로 설명한다.
QxA 엘리먼트의 xactionSetId 속성은 질문에 대한 답변을 목적으로 하는 유닛으로 취급되는 집합인 질문의 transactional 집합에 질문이 속하는 것을 나타낸다. 이는 또는 질문이 속하는 transactional 집합에 대한 식별자를 제공한다. 따라서, 같은 xactionSetId 속성의 값을 갖는 PDI 테이블에서의 모든 질문의 집합은 양자택일로 답변된다.
QxA 엘리먼트의 text 속성은 QxA.Q 엘리먼트의 하위 엘리먼트다. text 속성의 값은 사용자에게 제시될 질문 스트링을 나타낼 것이다.
도 69는 본 발명의 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다. 상술한 도 55의 개인화 방송 시스템은 개인화 서비스를 제공하기 위해 필터링 기준을 사용할 수 있다. 도 55, 도 57 및 도 58에서 설명한 필터링 기준은 필터링 기준 테이블 형식으로 처리될 수 있다. 본 발명의 필터링 기준 테이블은 XML 스키마로 표현되는 것을 일 실시예로 한다.
또한, 본 발명의 필터링 기준 테이블은, PDI 데이터와 필터링 기준을 효율적으로 비교하기 위해, PDI 테이블의 포맷과 유사한 포맷을 갖는 것을 일 실시예로 할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 테이블의 포맷은 설계자의 의도에 따라 변경 가능하다.
도 69에 도시된 바와 같이, 본 발명의 일 실시예에 따른 필터링 기준 테이블은 filtering criterion 엘리먼트(1900)를 포함할 수 있으며, filtering criterion 엘리먼트(1900)는 identifier 속성(1901), criterion type 속성(1902) 및/또는 criterion value 엘리먼트(1903)를 포함할 수 있다. 본 발명의 필터링 기준은 상술한 PDI 질문에 대응되는 개념으로 사용될 수 있다. 이하 도 69에 도시된 필터링 기준 테이블의 구성 엘리먼트들에 대해 설명한다.
본 발명의 일 실시예에 따른 filtering criterion 엘리먼트(1900)는 PDI 질문에 대응하는 필터링 기준을 지시할 수 있다.
본 발명의 일 실시예에 따른 identifier 속성(1901)은 필터링 기준에 대응하는 PDI 질문을 식별할 수 있다.
본 발명의 일 실시예에 따른 criterion type 속성(1902)은 필터링 기준의 타입을 지시할 수 있다. 필터링 기준의 타입에 관한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 criterion value 엘리먼트(1903)는 필터링 기준이 가지는 값을 지시할 수 있다. 각 기준값은 PDI 질문에 대한 가능한 답변이다.
구체적으로, 본 발명에 따른 필터링 기준의 타입은 정수 타입, 불 타입, 선택 타입, 텍스트 타입 및/또는 어느 타입 중 하나의 타입을 일 실시예로 할 수 있다.
정수 타입의 필터링 기준(또는 정수 타입 기준)은 정수 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
불 타입의 필터링 기준(또는 불 타입 기준)은 불 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
선택 타입의 필터링 기준(또는 선택 타입 기준)은 선택 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
텍스트 타입의 필터링 기준(또는 텍스트 타입 기준)은 텍스트 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
어느 타입의 필터링 기준(또는 어느 타입 기준)은 상술한 네 가지 타입 이외의 모든 형태의 PDI 답변에 대응하는 필터링 기준을 의미한다.
이하 [예시 5]는 도 69에 도시된 필터링 기준 테이블의 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>
도 70은 본 발명의 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로 도 70은, 도 69에서 설명한 필터링 기준 테이블의 확장된 포맷을 XML 스키마로 표현한 도면이다. 도 69에 도시된 필터링 기준의 XML 스키마에 따라 필터링 기준 테이블을 구성할 경우, 본 발명의 일 실시예에 따른 필터링 기준의 타입과 각 타입별 세부 속성을 설정할 수 없다는 문제점이 있다. 따라서 도 70에서는 필터링 기준의 타입을 표현하고, 각 타입별 속성을 설정한 XML 스키마를 제시하고자 한다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 도 70에 따른 XML 스키마에 따라 구성된 필터링 기준 테이블을 이용하여, 보다 정밀하게 콘텐츠를 필터링할 수 있다.
도 70에 도시된 바와 같이, 필터링 기준 테이블은 속성(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)를 포함할 수 있다. 이하 도 70에 도시된 필터링 기준 테이블의 구성 엘리먼트들에 대해 설명한다.
구체적으로, 도 59에 도시된 속성(2000)은 본 발명의 일 실시예에 따른 필터링 기준 테이블 자체의 속성 정보를 지시할 수 있다. 따라서 필터링 기준 테이블이 포함하는 필터링 기준 타입 엘리먼트가 달라지더라도 동일하게 표현될 수 있다. 예를 들어, 본 발명의 실시예에 따른 time 속성(2001)은 필터링 기준이 생성된 시간 또는 갱신된 시간을 지시할 수 있다. 이 경우 서로 다른 필터링 기준 타입 엘리먼트를 포함하는 필터링 기준 테이블들은, 필터링 기준 타입 엘리먼트가 달라지더라도 time 속성(2001)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 필터링 기준 테이블은 하나 또는 2 이상의 필터링 기준 타입 엘리먼트를 포함할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 필터링 기준의 타입을 지시할 수 있다. 필터링 기준의 타입은 도 69에서 설명한 바와 같다. 이 경우 필터링 기준 타입 엘리먼트는 리스트 형식으로 표현될 수 있다.
본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 "QxA" 기준으로 호칭될 수 있으며, 이 경우 "x"는 필터링 기준의 타입에 따라 결정될 수 있다.
도 70에 도시된 바와 같이, 각각의 필터링 기준 타입 엘리먼트는 식별자 속성 및/또는 기준값 엘리먼트를 포함할 수 있다. 도 70에 도시된 식별자 속성 및 기준값 엘리먼트 구체적인 내용은 도 69에서 설명한 바와 같다.
다만 도 70에 도시된 바와 같이, 정수 타입 기준 엘리먼트(2010)는 min integer 속성(2011) 및/또는 max integer 속성(2012)을 더 포함할 수 있다. 본 발명의 일 실시예에 따른 min integer 속성(2011)은 정수 타입의 답변으로 표현된 필터링 기준의 최소값을 지시할 수 있다. 본 발명의 일 실시예에 따른 max integer 속성(2012)은 정수 타입의 답변으로 표현된 필터링 기준의 최대값을 지시할 수 있다.
또한 도 70에 도시된 바와 같이, selection type criterion 엘리먼트(2030) 및/또는 text type criterion 엘리먼트(2040)는 lang 속성(2031)을 포함할 수 있다. 본 발명의 일 실시예에 따른 lang 속성(2031)은 문자열 형태로 표현된 필터링 기준의 값을 지시할 수 있다.
이하 [예시 6]는 도 70에 도시된 필터링 기준 테이블의 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>
도 71은 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로 도 71은 도 69 및 도 70에서 설명한 XML 스키마에 따른 필터링 기준 테이블의 일 실시예를 나타낸 도면이다. 도 71에 도시된 필터링 기준 테이블의 기본적인 구성 엘리먼트들은 도 69 및 도 70에서 상술한 바와 같다. 이하 도 71에 도시된 필터링 기준 테이블에 포함된 엘리먼트 및 속성의 시맨틱스에 대해 설명한다.
도 71에 도시된 바와 같이, 본 발명의 일 실시예에 따른 필터링 기준 테이블에서는 속성의 명칭 앞에"@"를 표시함으로써 속성과 엘리먼트를 구분할 수 있다.
테이블에서 @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 등)의 동일 값을 갖는 용어는 각 타겟 기준에 대한 중간 결과를 얻기 위해 논리합이 되고, 이들 중간 결과는 최종 결과를 결정하기 위해 논리곱이 될 것이다. 최종 결과가 수신기에 대해 "맞음"으로 평가되면, 이는 관련 콘텐츠 아이템이 필터를 통과한 것을 의미한다.
도 72는 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로, 도 72에 도시된 필터링 기준 테이블은, 도 71에 도시된 필터링 기준 테이블의 확장된 구조를 나타낸다. 도 72에 도시된 필터링 기준 테이블의 기본적인 구성 엘리먼트들은 도 71에서 설명한 바와 같다. 이하 도 71에서 설명한 필터링 기준 테이블과의 차이점을 중심으로 도 72에 도시된 필터링 기준 테이블을 설명한다.
도 72에 도시된 필터링 기준 테이블은 필터링 기준의 집합의 다양한 경우를 허용한다. 각각의 집합은 필터링 기준의 다양한 경우를 포함한다. 각각의 필터링 기준은 일부 필터링 기준에 대해 제공되는 여러 값을 허용한다. 필터링 논리는 필터링 기준의 집합의 여러 경우 중 "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>
도 73은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 73은, 본 발명의 일 실시예에 따른 수신기가 방송망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 55 내지 도 58에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 57 내지 도 68에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 69 내지 도 72에서 설명한 바와 같다.
도 73에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 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 테이블을 수신할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 73에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 수신기는 먼저 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 데이터를 갱신할 수 있다. 구체적인 내용은 도 55 및 도 56에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 수신기는 SSC(2300)를 통해 SMT(Service Map Table) 및/또는 NRT-IT(Non Real Time Information Table)를 수신할 수 있다. 본 발명의 일 실시예에 따른 SMT는 개인화 서비스를 위한 시그널링 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 NRT-IT는 개인화 서비스를 위한 소식 정보를 포함할 수 있다.
이후에 본 발명의 일 실시예에 따른 수신기는 수신한 SMT 및/또는 NRT-IT를 파싱하여 필터링 기준 기술어를 획득할 수 있다. 수신기는 필터링 기준 기술어를 이용하여, 필터링 엔진(2320)으로 필터링 기준을 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 71 및 도 72에서 구체적으로 설명하였다. 이후에 본 발명의 일 실시예에 따른 필터링 엔진(2320)은 PDI 엔진(2330)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(2330)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(2320)으로 전달할 수 있다. 결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 57 및 도 58에서 구체적으로 설명하였다.
도 74는 본 발명의 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 74는 도 73에서 설명한 PDI 테이블 섹션의 구문이다.
PDI 테이블이 방송 스트림에서 전달되면, 도 73에 정의된 테이블의 XML 형식은 DEFLATE 압축 알고리즘을 이용하여 압축된다. 얻어진 압축된 테이블은 도 74의 테이블에 나타낸 바와 같이 블록으로 구분되어 섹션에 삽입됨으로써 NRT 스타일의 전용 섹션에 요약된다.
결론적으로, 본 발명의 일 실시예에 따른 수신기는 동일한 시퀀스 넘버를 가지는 섹션 번호 순서대로 PDI-Q 경우 문서의 블록을 조합하여 압축을 해제할 수 있다. 본 발명의 일 실시예에 따른 수신기는 압축을 해제한 결과로서 PDI-Q 경우 문서를 생성할 수 있다. 이후에 수신기는 PDI-Q 경우 문서를 본 발명의 일 실시예에 따른 PDI 엔진으로 전달할 수 있다. 구체적인 방법은 도 73에서 상술한 바와 같다.
이하 도 74에 도시된 PDI 테이블 섹션의 구문에 대해 설명한다.
블록은 올림순의 section_number 필드 값의 섹션에 삽입될 것이다. "SSC" 및 "IP 서브넷"이라는 용어는 ATSC NRT 표준에서 정의되므로, 전용 섹션은 PDI 테이블이 관련된 가상 채널의 IP 서브넷의 SSC에서 전달된다. 해당 섹션의 sequence_number 필드는 동일한 SSC에서 전달되는 서로 다른 PDI 테이블 경우를 구별하기 위해 사용된다.
8비트의 table_id 필드는 해당 테이블 섹션이 PDI 테이블 경우에 속하는 것을 식별하기 위해 설정될 것이다. 8비트의 table_id 필드는 해당 테이블 섹션이 PDI 테이블 경우에 속하는 것을 식별하기 위해 설정될 것이다. table_id 필드는 도 74에 도시된 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 경우이다.
도 75는 본 발명의 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 75는 도 73에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 74에서 설명한 바와 같다. 다만, 도 74에 도시된 PDI 테이블 섹션과는 달리, 도 75에 도시된 PDI 테이블 섹션은 sequence_number 필드를 포함하지 않을 수 있다. 이하 도 75에 도시된 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 필드는 밑의 표 에 표현된 답변 타입 코드들을 포함할 수 있다. 밑의 표에 도시된 각각의 답변 타입 코드는, 도 59에서 설명한 PDI 답변들의 타입을 지시할 수 있다.
answer_type_code 값
0x000x010x020x030x04 - 0x07 확보됨정수 타입불 타입스트링 타입 (including selection type/text type)추후 ATSC 사용을 위해 확보됨
본 발명의 일 실시예에 따른 num_answer 필드는 PDI 질문에 대한 PDI 답변의 수를 지시할 수 있다.
본 발명의 일 실시예에 따른 answer_value_length 필드는 answer_value의 실제 길이를 지시할 수 있다.
본 발명의 일 실시예에 따른 answer_value 필드는 answer_type_code로 표현되는 PDI 답변의 실제 내용을 포함할 수 있다.
도 76은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 76은 도 73에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 74 및 도 75에서 설명한 바와 같다. 도 76의 구문을 구성하는 필드들은 도 75의 구문을 구성하는 필드들과 동일하므로, 이하 구체적인 설명은 생략한다.
도 77은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 77은 도 73에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 74 및 도 75에서 설명한 바와 같다. 도 77의 구문을 구성하는 기본적인 필드들은 도 75의 syntax를 구성하는 필드들과 동일하므로, 이하 구체적인 설명은 생략한다.
다만, 도 75의 구문과는 달리, 도 77의 구문은 sequence_number 필드를 더 포함할 수 있다. 본 발명의 일 실시예에 따른 sequence_number 필드에 대한 설명은 도 74에서 상술한 바와 같다.
도 78은 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로, 도 73에서 설명한 개인화 방송 시스템 상의 FLUTE 세션, 필터링 엔진 및/또는 PDI 엔진의 동작에 관한 본 발명의 일 실시예를 나타낸 도면이다.
도 78에 도시된 바와 같이 본 발명의 일 실시예에 따른 개인화 방송 시스템은 FLUTE 세션(2800), 필터링 엔진(2810) 및/또는 PDI 엔진(2820)을 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스 및 차세대 방송 서비스 등을 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
도 73에서 상술한 바와 같이, 본 발명의 일 실시예에 따른 수신기는 FLUTE 세션을 통해 PDI 테이블을 수신할 수 있다. 이하 도 78에서는 본 발명의 일 실시예에 따른 수신기가 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)으로 전달할 수 있다. 구체적인 내용은 도 73에서 설명한 바와 같다.
도 79는 본 발명의 다른 일 실시예에 따른 FDT 경우의 XML 스키마를 나타낸 도면이다.
구체적으로 도 79는 도 78에서 설명한 FDT 경우의 XML 스키마를 나타낸 도면으로서, 이하 상술한 콘텐츠 타입 속성(2900)에 대해 설명한다.
도 79에 도시된 바와 같이, 본 발명의 일 실시예에 따른 FDT 경우는 FDT 경우 자체의 속성 정보를 지시하는 속성(2900) 및/또는 FLUTE 세션을 통해 전송되는 파일을 지시하는 file 엘리먼트(2910)를 포함할 수 있다. 도 79에 도시된 file 엘리먼트(2910)는 파일에 대한 속성 정보를 지시하는 속성을 포함할 수 있다. 도 79에 도시된 바와 같이, file 엘리먼트(2910)는 본 발명의 실시예에 따른 content type 속성(2920)을 포함할 수 있다.
도 78에서 설명한 바와 같이, 본 발명의 실시예에 따른 수신기는 content type 속성(2920)에 포함된 값을 이용하여 PDI-Q 경우 문서를 식별할 수 있다. 예를 들어, 도 79에 도시된 content type 속성(2920)은 "application/atsc-pdiq" 또는 "text/atsc-pdiq+xml"로 표현되는 MIME(Multipurpose Internet Mail Extensions) 프로토콜 형태의 값 등을 가질 수 있다.
도 80은 본 발명의 일 실시예에 따른 캐퍼빌리티 기술어 구문을 나타낸 도면이다.
구체적으로 도 80은 도 73에서 설명한 개인화 방송 시스템에 있어서, 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 식별하기 위한 구문을 나타낸다.
본 발명의 일 실시예에 따른 캐퍼빌리티 기술어는 SMT 서비스 레벨에서의 서비스 또는 NRT-IT 콘텐츠 레벨에서의 콘텐츠가 PDI 테이블인지 아닌지를 나타내기 위해 사용될 수 있다. 본 발명의 일 실시예에 따른 수신기는 해당 정보를 이용하여 서비스/콘텐츠가 PDI 테이블인지 아닌지 알고, 해당 서비스/콘텐츠가 다운로드되어야 하는지를 PDI 엔진을 지원하는 등의 캐퍼빌리티에 따라 판단한다.
하기 표 에 표현된 코드는 PDI 테이블 시그널링에 대한 캐퍼빌리티 기술어에서 capability_code에 추가될 수 있다. 본 발명의 일 실시예에 따른 capablilty_code 값은 다른 값에 할당될 수 없다. 이하 하기 표 에 표시된 capability_code 값은 설계자의 의도에 따라 다르게 설정될 수 있다.
Capability_code value 의미
... ...
0x4F HE ACC v2 with MPEG Surround
0x50 PDI 테이블(PDI-Q 포함)
... ...
도 81은 본 발명의 일 실시예에 따른 소비 모델을 나타낸 도면이다.
구체적으로 도 81은 도 73에서 설명한 개인화 방송 시스템에 있어서, 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 식별하기 위해, SMT 상에 추가된 필드를 나타낸다.
NRT 서비스 기술어는 NRT SMT의 서비스 레벨에 위치하고, 그 NRT_service_category는 서비스가 PDI 테이블을 제공하면 0x04 (PDI)가 된다. 따라서, 수신기는 필드값이 0x04이면 PDI 테이블이 제공된다고 알 수 있다.
도 81에 도시된 소비 모델의 값은 설계자의 의도에 따라 다르게 설정될 수 있다.
도 82는 본 발명의 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
구체적으로 도 82는 도 73에서 설명한 개인화 방송 시스템 상에서, 본 발명의 일 실시예에 따른 수신기가 필터링 기준 테이블을 수신하기 위한 필터링 기준 기술어의 비트 스트림 구문을 나타낸다.
본 발명의 일 실시예에 따른 필터링 기준은 본 발명의 일 실시예에 따른 수신기가 콘텐츠를 다운로드할지 판단하도록 다운로드 가능한 콘텐츠와 관련된다. ATSC 2.0 환경에는 다운로드 가능한 콘텐츠에 두 가지 카테고리가 있다. 독립형의 NRT 서비스에서의 NRT 콘텐츠 및 부속 쌍방향 데이터 서비스에서 TDO에 의해 사용되는 NRT 콘텐츠 아이템이 그에 해당한다.
이하 도 82에서는 독립형의 NRT 서비스에서의 NRT 콘텐츠를 필터링하기 위한 필터링 기준에 대해 설명한다.
본 발명의 일 실시예에 따른 NRT 서비스 및 콘텐츠 아이템에 대한 필터링 기준에서, 이하에 정의된 필터링 기준 기술어의 하나 이상의 경우는 수신기가 사용자에게 NRT 서비스를 제공할지를 결정하도록 하기 위해 SMT에서 서비스 레벨 기술어 루프에 포함될 수도 있고, 수신기가 해당 특정 콘텐츠 아이템을 다운로드 하여 사용자가 사용 가능하게 할지를 결정하도록 NRT-IT에서 콘텐츠 아이템 레벨 기술어 루프에 포함될 수도 있다.
필터링 기준 기술어의 하나 이상의 경우는 다수의 값이 동일 또는 다른 타겟 기준에 대해 제공되도록 한다. 의도하는 타겟 논리는 동일한 타겟 기준에 대해서 다수 값 사이에서 논리합이고, 서로 다른 타겟 기준 사이에서 논리곱이다.
이하 도 82에 도시된 필터링 기준 기술어의 비트 스트림 구문의 각 필드들의 시멘틱 정의에 대해 설명한다.
8비트 필드인 descriptor_tag 필드는 기술어가 본 발명의 일 실시예에 따른 필터링 기준 기술어라는 것을 나타내기 위해 0xTBD로 설정될 수 있다.
8비트 무부호 정수 필드인 descriptor_length 필드는 descriptor_length 필드 자신에 뒤따르는 바이트 수를 나타낼 수 있다.
8비트 필드인 num_ filter_criteria 필드는 도 82에 나타낸 해당 기술어에 포함된 필터링 기준의 수를 나타낼 수 있다.
8비트 필드인 criterion_id_length 필드는 criterion_id 필드의 길이를 나타낼 수 있다.
가변 길이 필드인 criterion_id 필드는 해당 기술어가 나타나는 가상 채널의 PDI 테이블에서 질문(QIA, QBA, QSA, QTA, 또는 QAA 엘리먼트)의 id 속성에 매칭되는 URI의 형태로 해당 필터링 기준의 식별자를 제공할 수 있다.
3비트 필드인 criterion_type_code 필드는 하기 표 에 따라 해당 기준(질문)의 타입을 제공할 수 있다.
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 서비스 또는 콘텐츠 아이템이 필터를 통과하고 수신기에 다운로드 될 수 있다는 것을 의미한다.
도 83은 본 발명의 다른 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
구체적으로 도 83은 도 73에서 설명한 개인화 방송 시스템 상에서, 본 발명의 일 실시예에 따른 수신기가 필터링 기준 테이블을 수신하기 위한 필터링 기준 기술어의 비트 스트림 구문을 나타낸다.
도 83에 도시된 필터링 기준 기술어 구문의 기본적인 내용은 도 82에서 설명한 바와 같다.
그러나, criterion_type_code 필드는 하기 표 에 따라 해당 기준(질문)의 타입을 제공할 수 있다.
criterion_type_code 값
0x000x010x020x030x04 - 0x07 확보됨정수 타입불 타입스트링 타입(선택 타입/텍스트 타입 포함)향후 ATSC 사용을 위해 확보됨
도 84는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 84는, 본 발명의 일 실시예에 따른 수신기가 방송망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 55 내지 도 58에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 57 내지 도 68에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 69 내지 도 72에서 설명한 바와 같다.
도 84에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 시그널링 서버(3410), 필터링 엔진(3420), PDI 엔진(3430) 및/또는 UI(3440)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
본 발명의 일 실시예에 따른 PDI 테이블 및 필터링 기준을 처리하기 위한 필터링 엔진(3420), PDI 엔진(3430) 및/또는 UI(3440)의 동작은 도 73에서 설명한 바와 같다. 이하 도 84에 도시된 시그널링 서버(3410)의 동작을 중심으로 설명한다.
본 발명의 일 실시예에 따른 수신기는 먼저 PDI 테이블 섹션을 수신하기 위한 요청 신호를 시그널링 서버(3410)에 전송할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 쿼리 용어를 이용하여 요청 신호를 전송할 수 있다. 쿼리에 대한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 시그널링 서버(3410)는 해당 쿼리에 따른 PDI 테이블 섹션을 수신기로 전송할 수 있다. PDI 테이블 섹션에 대한 구체적인 내용은 도 74 내지 도 77에서 설명한 바와 같다.
도 85는 본 발명의 일 실시예에 따른 HTTP 요청 테이블을 나타낸 도면이다.
구체적으로 도 85는 본 발명의 일 실시예에 따른 수신기가 도 84에서 설명한 시그널링 서버로 쿼리를 전송하기 위한 HTTP 프로토콜을 나타낸다.
방송사에 의해 지원되면, 도 85에 나타낸 프로토콜은 두 개의 캐퍼빌리티를 제공할 수 있다. 첫째로, 압축되지 않은 오디오 또는 비디오만을 전달하는 경로를 통해 DTV 방송 신호를 받는 장치에 대해, 해당 프로토콜은 일반적으로 방송사의 독립형 NRT 서비스에 접속하는 유일한 방법이다. 둘째로, 완전한 방송 스트림에 접속할 수 있는 장치에 대해서도, 해당 프로토콜은 로컬 방송 영역에서 사용 가능한 모든 방송 스트림을 순환하여 원하는 테이블이 나타나기를 기다리지 않고 프로그램/서비스 가이드를 덧붙이는 데이터를 검색하는 방법을 제공한다. 이는 또한 별도의 튜너를 필요로 하지 않고 시청자가 TV를 시청하고 있는 동안에도 어느 때나 이러한 데이터의 검색을 가능하게 한다.
도 85에 도시된 HTTP 요청 테이블은, 수신하고자 하는 테이블의 종류 및 해당 테이블을 수신하기 위한 베이스 URL을 지시하는 쿼리 용어를 포함할 수 있다.
본 발명의 일 실시예에 따른 수신기는 도 85에 도시된 HTTP 요청 테이블의 쿼리 용어를 이용하여 특정 table을 수신할 수 있다. 구체적으로 본 발명의 일 실시예에 따른 수신기는 "?table=PDIT[&chan=<chan_id>]"라는 쿼리 용어를 이용하여 시그널링 서버에 요청 신호를 보낼 수 있다. 구체적인 내용은 도 84에서 설명한 바와 같다.
도 86은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 86은, 본 발명의 일 실시예에 따른 수신기가 인터넷망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 55 내지 도 58에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 57 내지 도 67 및 도 68에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 69 내지 도 72에서 설명한 바와 같다.
인터넷을 통해 전달될 때, PDI 테이블 경우는 HTTP 또는 HTTPS를 통해 전달될 것이다. HTTP 응답 헤더에서 PDI 테이블의 콘텐츠 타입은 "text/xml"이 될 것이다.
인터넷을 통해 PDI 테이블을 검색하기 위해 사용되는 URL은 DTV 자막 방송 채널에서 표준 자막 서비스 #6에서 이동되는 SDOPrivateDataURIString 명령어를 통해 전달될 수도 있고, TPT와 함께 전달되는 UrlList XML 엘리먼트에서 전달될 수도 있다.
TPT(TDO 파라미터 테이블)는 세그먼트의 TDO에 관한 메타데이터 및 그것들을 타겟으로 하는 이벤트를 포함한다. TDO라는 용어는 트리거링된 쌍방향 부가 데이터 서비스에서 트리거에 의해 개시된 DO(Declarative Object) 또는 트리거에 의해 개시된 DO에 의해 개시된 DO 등을 반복하여 지정하기 위해 사용된다. 트리거는 시그널링을 식별하고 쌍방향 이벤트의 재생의 타이밍을 설정하는 기능을 갖는 시그널링 엘리먼트다.
도 86에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 PDI 서버(3600), 콘텐츠 서버(3650) 및/또는 수신기를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 TPT(TDO Parameters Table) 클라이언트(3610), 필터링 엔진(3620), PDI 엔진(3630) 및/또는 UI(3640)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 86에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 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)로 전송할 수 있다.
도 86에 도시된 바와 같이, 본 발명의 일 실시예에 따른 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 데이터를 갱신할 수 있다. 구체적인 내용은 도 55 및 도 56에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 TPT 클라이언트(3610)는 TPT를 파싱하여 필터링 기준을 획득할 수 있다. 도 86에 도시된 바와 같이 TPT 클라이언트(3610)는 필터링 기준을 필터링 엔진(3620)으로 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 71 및 도 72에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(3620)은 PDI 엔진(3630)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3630)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(3620)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 57 및 도 58에서 구체적으로 설명하였다.
결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 보다 상세하게는, TPT 클라이언트(3610)는 필터링 결과를 필터링 엔진(3620)으로부터 수신하고, TDO 및/또는 콘텐츠 다운로드 요청 신호를 콘텐츠 서버(3650)에 전달할 수 있다. 콘텐츠 서버(3650)는 TDO 및/또는 콘텐츠 다운로드 요청 신호에 따라 TDO 및/또는 콘텐츠를 TPT 클라이언트(3610)로 전송할 수 있다.
도 87은 본 발명의 일 실시예에 따른 URL 리스트 테이블 나타낸 도면이다.
구체적으로 도 87은, 본 발명의 일 실시예에 따른 수신기가 인터넷망을 통해 PDI 테이블 및/또는 필터링 기준을 수신하기 위한 URL 정보를 포함한 테이블이다. 본 발명의 일 실시예에 따른 URL 리스트 테이블의 송수신 과정은 도 86에서 구체적으로 설명하였다.
URL 리스트 테이블은 인터넷을 통해 전달될 때 멀티파트(multipart) MIME 메시지의 형태로 TPT와 함께 HTTP를 통해 전달될 수 있다.
인터넷을 통해 전달될 때, TPT는 HTTP를 통해 전달될 수 있다. 현 세그먼트의 TPT에 대한 URL 정보는 DTV 자막 서비스 #6 또는 자동 콘텐츠 인식 서버를 통해 전달되며 트리거에 나타날 수 있다. TPT에 대한 요청에 응답은 현 세그먼트에 대한 TPT만으로 구성될 수도 있고, 요청된 TPT가 첫 번째 파트, 세그먼트에 대한 AMT가 선택적으로 두 번째 파트, UrlList XML 문서가 선택적으로 그 다음 파트인 멀티파트 MIME 메시지로 구성될 수도 있다.
이하, 본 발명의 일 실시예 에 따른 URL 리스트 테이블에 포함된 각 엘리먼트들의 시맨틱스에 대해 설명한다.
도 87에 나타낸 UrlList 엘리먼트는 본 발명의 일 실시예에 따른 수신기에 유용한 URL의 리스트를 포함한다.
도 87에 나타낸 UrlList 엘리먼트의 TptUrl 엘리먼트는 현 쌍방향 부가 서비스에서 추후 세그먼트에 대한 TPT의 URL 정보를 포함할 수 있다. 다수의 TptUrl 엘리먼트가 포함되면, 그것들은 방송에서 세그먼트의 출현 순으로 정렬될 것이다.
도 87에 나타낸 UrlList 엘리먼트의 NrtSignalingUrl 엘리먼트는 수신기가 해당 표준의 섹션 18에 정의된 요청 프로토콜을 이용하여 현 전송 스트림에서 모든 가상 채널에 대한 NRT 시그널링 테이블을 얻을 수 있는 서버의 URL 정보를 포함할 수 있다.
도 87에 나타낸 UrlList 엘리먼트의 UrsUrl 엘리먼트는 수신기가 해당 표준의 섹션 10에 정의된 프로토콜을 이용하여 사용 (시청률 조사) 리포트를 보낼 수 있는 서버의 URL 정보를 포함할 수 있다.
도 87에 나타낸 UrlList 엘리먼트의 PdiUrl 엘리먼트는 PDITable의 URL 정보를 포함할 수 있다. 즉, 본 발명의 일 실시예에 따른 PdiUrl 엘리먼트는, PDI 테이블 및/또는 필터링 기준을 전송할 수 있는 서버의 URL 정보를 지시할 수 있다.
상술한 도 87의 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
도 88은 본 발명의 일 실시예에 따른 TPT를 나타낸 도면이다.
구체적으로 도 88에 도시된 TPT는, PDI 테이블 및/또는 필터링 기준의 URL 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 TPT의 송수신 과정은 도 86에서 구체적으로 설명하였다. 이하 TPT에 포함된 필터링 기준에 관한 엘리먼트를 설명한다.
구체적으로, 도 88에 도시된 Filter Criterion 엘리먼트는 필터링 기준에 대한 정보를 포함할 수 있다.
본 발명의 일 실시예에 따른 id 속성은 해당 필터링 기준에 관한 PDI 질문을 지시할 수 있다.
본 발명의 일 실시예에 따른 criterion type 속성은 필터링 기준 타입(또는 필터링 기준 타입 엘리먼트)을 지시할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준의 타입에 관하여는 도 70에서 구체적으로 설명하였다.
본 발명의 일 실시예에 따른 criterion value 속성은 상술한 기준 타입 속성에 따른 필터링 기준의 값을 나타낼 수 있다.
도 89는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 89는, 본 발명의 일 실시예에 따른 수신기가 자동 콘텐츠 인식 시스템 상에서 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템을 나타낸 도면이다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 시스템은 도 49에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 55 내지 도 58에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 57 내지 도 44에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 69 내지 도 72에서 설명한 바와 같다.
도 89에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 자동 콘텐츠 인식 서버(3900), TPT 서버(3950), PDI 서버(3960), 콘텐츠 서버(3970), 자동 콘텐츠 인식 클라이언트(3910), 필터링 엔진(3920), PDI 엔진(3930) 및/또는 UI(3940)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 89에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 핑거프린트로부터 시그니쳐를 추출하여 시그니쳐와 함께 요청을 자동 콘텐츠 인식 서버(3900)로 전송할 수 있다. 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 서버(3900)는 시그니쳐를 수신하고, 해당 시그니쳐와 연관된 트리거 등과 함께 응답을 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다. 상술한 내용은 도 49 내지 도 54에서 구체적으로 설명하였다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(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)로 전송할 수 있다.
도 84에 도시된 바와 같이, 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(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 데이터를 갱신할 수 있다. 구체적인 내용은 도 55 및 도 56에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 TPT를 파싱하여 필터링 기준을 획득할 수 있다. 도 89에 도시된 바와 같이 자동 콘텐츠 인식 클라이언트(3910)는 필터링 기준을 필터링 엔진(3920)으로 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 71 및 도 72에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(3920)은 PDI 엔진(3930)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3930)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(3920)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 51 및 도 58에서 구체적으로 설명하였다.
결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 구체적으로, 자동 콘텐츠 인식 클라이언트(3910)는 필터링 결과를 필터링 엔진(3920)으로부터 수신하고, TDO 및/또는 콘텐츠 다운로드 요청 신호를 콘텐츠 서버(3970)에 전달할 수 있다. 콘텐츠 서버(3970)는 TDO 및/또는 콘텐츠 다운로드 요청 신호에 따라 TDO 및/또는 콘텐츠를 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다.
도 90은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 90은 PDI 답변의 중복 방지를 위한 개인화 방송 시스템의 일 실시예를 나타낸 도면이다.
보다 상세하게, 도 90은 본 발명의 일 실시예에 따른 수신기가 다수의 방송국 및 콘텐츠 제공자들로부터 동일한 PDI 질문을 수신하는 경우, 이미 저장된 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있는 개인화 방송 시스템을 나타낸다. 도 90에 도시된 개인화 방송 시스템을 통해, 사용자는 동일한 PDI 질문에 대해 중복하여 PDI 답변을 입력하는 번거로움을 줄일 수 있다.
도 90에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 2 이상의 방송국(또는 콘텐츠 제공자) 및/또는 수신기를 포함할 수 있다. 본 발명의 일 실시예에 따른 2 이상의 방송국은 방송국 A(4010) 및/또는 방송국 B(4020)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 PDI 엔진(4030) 및/또는 UI(4040)를 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 90에 도시된 각 구성 엘리먼트들의 동작을 설명한다.
먼저 본 발명의 일 실시예에 따른 수신기는 방송국 A(4010)로부터 제1 PDI 테이블(4011)을 수신할 수 있다. 제1 PDI 테이블(4011)을 수신한 수신기는 PDI 엔진(4030)으로 제1 PDI 테이블(4011)을 전달할 수 있다. 본 발명의 일 실시예에 따른 제1 PDI 테이블(4011)은 제1 PDI 타입 엘리먼트(4012)를 포함할 수 있다. 본 발명의 일 실시예에 따른 제1 PDI 타입 엘리먼트(4012) 각각은, 도 65 및 도 66 및 도 67 및 도 68에서 상술한 바와 같이 제1 식별자 엘리먼트(또는 제1 ID) 및/또는 제1 PDI 질문을 포함할 수 있다. 또한 도 90에 도시된 바와 같이 제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)의 구체적인 동작은 도 73에서 설명한 바와 같다.
또한, 본 발명의 일 실시예에 따른 PDI 엔진(4030)은 방송국 B(4020)로부터 제2 PDI 테이블(4021)을 수신할 수 있다. 본 발명의 일 실시예에 따른 제2 PDI 테이블(4021)은 제2 PDI 타입 엘리먼트(4022)를 포함할 수 있다. 도 65 및 도 66 및 도 67 및 도 68에서 상술한 바와 같이, 제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 답변을 중복하여 입력할 필요가 없으므로 사용자는 보다 편리하게 개인화 서비스를 제공받을 수 있다.
도 91은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 91은 PDI 답변의 중복 방지를 위한 개인화 방송 시스템의 일 실시예를 나타낸 도면이다. 도 90에서 설명한 개인화 방송 시스템은 PDI 답변의 중복 방지를 위해, 본 발명의 일 실시예에 따른 수신기에 이미 저장된 PDI 테이블을 이용할 수 있다. PDI 답변의 중복 방지를 위한 또 다른 실시예로서, 도 91에서는 PDI 질문 등록을 통한 개인화 방송 시스템을 제시한다.
소비자들이 본질적으로 동일한 질문에 대해 반복해서 급하게 답하지 않도록 서로 다른 방송사에 의해 질문을 재사용하는 것을 지원하기 위해, 질문은 ATSC에 의해 지정될 레지스트라(registrar)에 등록될 수 있다. 각 등록 기록은 도 65 및 도 66 및 도 67 및 도 68에 명시된 바와 같이 전세계적으로 유일한 질문 ID에 관한 정보, 질문 타입 (QIA, QBA, QSA, 또는 QTA), 하나 이상의 언어로 된 질문 텍스트, 등록 날짜, 및/또는 등록을 위해 질문을 제출한 단체에 대한 연락처 정보를 포함할 수 있다. 또한, QSA의 경우, 각 등록 기록(또는 선등록 PDI 질문)은 각 선택의 식별자와 같은 허용되는 선택, 및 하나 이상의 언어로 된 각 선택의 텍스트를 포함할 수 있다.
PDI 테이블은 등록된 질문 및 등록되지 않은 질문의 혼합을 포함할 수 있다.
등록된 질문 및 등록되지 않은 질문은 모두 다수의 PDI 테이블에 나타날 수 있다. 사용자가 다수의 PDI 테이블에 나타난 질문에 답할 때마다, 수신기가 제공하는 기능에 의하든지 또는 어플리케이션이 제공하는 기능에 의하든지, 답변은 그것이 나타나는 모든 설문지에 있는 질문의 모든 경우에 전파될 것으로 예상된다. 따라서, 사용자는 그것이 서로 다른 설문지에 몇 번 나타나든 어느 주어진 질문에 한 번만 답변하면 된다.
사용자에게 질문이 쇄도하는 것을 방지하기 위해, 설문지 생성자는 가능할 때마다 등록된 질문을 사용하고 등록된 질문을 얻을 수 없는 특별한 타겟 요구가 있을 때만 등록되지 않은 질문을 사용하도록 권장된다.
본 발명의 일 실시예에 따른 수신기는 수신기 타겟 기준을 이용하여 선등록 PDI 질문을 추출할 수 있다. 본 발명의 일 실시예에 따른 수신기 타겟 기준은 ATSC NRT 표준인 A/103에 따른다.
도 91에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 SSC(4100), FLUTE 세션(4110), 필터링 엔진(4120), PDI 엔진(4130) 및/또는 UI(4140)을 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 91에 도시된 개인화 방송 시스템에 대해 설명한다.
본 발명의 일 실시예에 따른 수신기는 SSC(4100)를 통해 SMT 및/또는 NRT-IT를 수신하고, SMT 및/또는 NRT-IT에 포함된 수신기 타겟 기준을 획득할 수 있다. 본 발명의 수신기 타겟 기준은 수신기 타겟 기술어 또는 수신기 타겟 기준 테이블을 일 실시예로 할 수 있다.
이후에 본 발명의 일 실시예에 따른 PDI 엔진(4130)은 획득한 수신기 타겟 기준을 변환하여 PDI 질문을 생성할 수 있다. 본 발명의 일 실시예에 따른 UI(4140)는 PDI 엔진(4130)으로부터 상술한 PDI 질문을 전달받아 디스플레이하고, 사용자의 PDI 답변을 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(4130) 및 UI(4140)의 구체적인 동작은 도 73에서 설명한 바와 같다.
도 92는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 92는 PDI 질문 등록을 통한 개인화 방송 시스템을 나타낸다.
도 92에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 시그널링 서버(4200), 수신기(4210), 필터링 엔진(4220), PDI 엔진(4230) 및 UI(4240)을 포함할 수 있다. 수신기(4210)는 필터링 엔진(4220), PDI 엔진(4230) 및/또는 UI(4240)을 포함하는 개념으로 사용될 수 있으며 이는 설계자의 의도에 따라 변경 가능하다. 또한 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 이하 도 91에 도시된 개인화 방송 시스템에 대해 설명한다.
기본적인 구성 엘리먼트들의 동작은 도 91에서 설명한 바와 같다. 다만, 도 92에 도시된 수신기(4210)는 시그널링 서버(4200)에 SMT 및/또는 NRT-IT를 요청할 수 있다. 본 발명의 일 실시예에 다른 수신기(4210)의 요청에 따라, 시그널링 서버(4200)는 해당 SMT 및/또는 NRT-IT를 수신기(4210)로 전송할 수 있다.
본 발명의 일 실시예에 따른 수신기가 SMT 및/또는 NRT-IT를 수신한 이후에, 수신기(4210), PDI 엔진(4230) 및/또는 UI(4240)의 구체적인 동작은 도 91에서 설명한 바와 같다.
도 93은 본 발명의 일 실시예에 따른 수신기 대상 기준 테이블을 나타낸 도면이다.
구체적으로 도 93은 도 91 및 도 92에서 설명한 수신기 타겟 기준을 테이블 형식으로 표현한 도면이다.
도 93에 도시된 바와 같이 수신기 대상 기준 테이블은 타겟 기준 타입 코드(targeting criterion type code), 타겟값 길이(targeting value length) 및/또는 타겟값(targeting value)에 관한 정보를 포함할 수 있다. 도 93에 도시된 타겟 기준 타입 코드는 각각의 타겟 기준을 식별하기 위한 코드를 의미한다. 도 93에 도시된 타겟값 길이는 타겟 기준값을 나타내기 위한 바이트 수를 의미한다. 도 93에 도시된 타겟값은 타겟 기준이 나타내는 정보를 의미한다.
본 발명의 일 실시예에 따른 수신기는 타겟 기준 타입 코드에 따라 타겟 기준을 변환하여 선등록 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인 경우, 타겟값은 사적 사용이 가능하고, 타겟값 길이는 정해지지 않는다.
도 94 내지 도 97은 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 94 내지 도 97은, 도 93에서 상술한 타겟 기준 타입 코드가 0x01인 경우로서, 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 테이블들이다.
도 94 내지 도 97에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 지리적 위치에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 하위 3 바이트만을 사용하여 타겟 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다.
도 94는 타겟 기준 타입 코드가 0x01인 경우로서, 위치 코드(location code)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 94에 도시된 선등록 PDI 질문 table에 포함된 선등록 PDI 질문 정보는 도 91에서 설명한 바와 같다.
구체적으로 도 94에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 위치 코드에 관한 정보를 포함할 수 있다. 또한 도 94에 도시된 선등록 PDI 질문은 QTA 타입으로서, 위치 코드에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 8]는 도 94에 도시된 테이블을 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>
도 95는 타겟 기준 타입 코드가 0x01인 경우로서, FIPS(Federal Information Processing Standards Publication) state에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 95에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 91에서 설명한 바와 같다. 다만 도 95에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 95에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 FIPS state에 관한 정보를 포함할 수 있다. 또한 도 95에 도시된 선등록 PDI 질문은 QTA 타입으로서, FIPS state에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 9]은 도 95에 도시된 테이블을 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>
도 96은 타겟 기준 타입 코드가 0x01인 경우로서, FIPS country에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 96에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 91에서 설명한 바와 같다. 다만 도 96에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 96에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 FIPS country에 관한 정보를 포함할 수 있다. 또한 도 96에 도시된 선등록 PDI 질문은 QTA 타입으로서, FIPS country에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 10]는 도 96에 도시된 테이블을 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>
도 97은 타겟 기준 타입 코드가 0x01인 경우로서, 자치주 세분(county subdivision)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 97에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 91에서 설명한 바와 같다. 다만 도 97에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 97에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 자치주 세분에 관한 섹터 정보를 포함할 수 있다. 또한 도 97에 도시된 선등록 PDI 질문은 QSA 타입으로서, 자치주 세분에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 QSA 타입의 선등록 PDI 질문은 PDI 답변에 대한 선택지(selection) 정보를 포함할 수 있다. 예를 들어, 도 97에 도시된 자치주 세분에 관한 선등록 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>
상술한 도 95 내지 도 97에 도시된 question xactionSetId는 유사한 내용을 포함하는 PDI 질문들의 집합을 지시할 수 있다. 본 발명의 일 실시예에 따른 수신기는 동일한 question xactionSetId를 포함하는 선등록 PDI 질문들을 조합하여 개인화 방송 서비스에 이용할 수 있다.
예를 들어, 도 94에 도시된 수신기 타겟 기준은, 동일한 question xactionSetId를 가지는 도 95 내지 도 97의 수신기 타겟 기준으로도 표현될 수 있다. 본 발명의 일 실시예에 따른 수신기는 도 94에 도시된 수신기 타겟 기준 및/또는 도 95 내지 도 97의 수신기 타겟 기준을 조합한 결과를 이용하여 개인화 방송 서비스를 제공할 수 있다.
도 98 및 도 99는 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 98 및 도 99는, 도 93에서 상술한 타겟 기준 타입 코드가 0x02인 경우, 선등록 PDI 질문을 나타낸 테이블들이다.
도 98 및 도 99에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 글자와 숫자로 쓴 우편번호에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 영역에 따른 적절한 수의 바이트를 사용하여 목표 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다. 본 발명의 일 실시예에 따른 수신기는 목표 기준 테이블 변환을 위해 최대 8 바이트를 사용할 수 있다.
도 98은 타겟 기준 타입 코드가 0x02인 경우로서, 다섯 자리 우편 번호에 관한 선등록 PDI 질문을 나타낸 테이블이다. 다섯 자리 우편 번호는 미국에서 사용하는 글자와 숫자로 쓴 우편번호를 의미한다. 도 98에 도시된 선등록 PDI 질문이 포함하는 내용은 도 91에서 설명한 바와 같다.
구체적으로 도 98에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 질문 ID는 우편 번호에 관한 정보를 포함할 수 있다. 또한 도 98에 도시된 선등록 PDI 질문은 QTA 타입으로서, 우편 번호에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 12]은 도 98에 도시된 테이블을 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>
도 99는 타겟 기준 타입 코드가 0x02인 경우로서, 수로 나타낸 우편번호에 관한 선등록 PDI 질문을 나타낸 테이블이다. 수로 나타낸 우편번호는 미국 이외의 지역에서 사용하는 글자와 숫자로 쓴 우편번호를 의미한다. 도 99에 도시된 선등록 PDI 질문이 포함하는 내용은 도 91에서 설명한 바와 같다.
구체적으로 도 99에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 질문 ID는 우편 번호에 관한 정보를 포함할 수 있다. 또한 도 99에 도시된 선등록 PDI 질문은 QTA 타입으로서, 우편 번호에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 13]은 도 99에 도시된 테이블을 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>
도 100 내지 도 103은 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 100 내지 도 103은, 도 93에서 상술한 타겟 기준 타입 코드가 0x03인 경우로서, 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 테이블들이다.
도 100 내지 도 103에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 사용자의 인구통계 카테고리에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 하위 2 바이트만을 사용하여 타겟 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다.
도 100은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 성별에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 100에 도시된 선등록 PDI 질문이 포함하는 내용은 도 91에서 설명한 바와 같다.
구체적으로 도 100에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 성별에 관한 정보를 포함할 수 있다. 또한 도 100에 도시된 선등록 PDI 질문은 QSA 타입으로서, 사용자의 성별에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 100에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 100에 도시된 성별에 관한 선등록 PDI 질문은, 남성 및 여성에 대한 2가지 선택 정보를 포함할 수 있다.
이하 [예시 14]은 도 100에 도시된 테이블을 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>
도 101은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 연령대(age bracket)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 101에 도시된 선등록 PDI 질문이 포함하는 내용은 도 91에서 설명한 바와 같다.
구체적으로 도 101에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 연령대에 관한 정보를 포함할 수 있다. 또한 도 101에 도시된 선등록 PDI 질문은 QSA 타입으로서, 연령대에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 101에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 101에 도시된 연령대에 관한 선등록 PDI 질문은, 2-5세, 6-11세, 12-17세, 18-34세, 35-49세, 50-54세, 55-64세, 65세 이상에 대한 8가지 선택 정보를 포함할 수 있다.
이하 [예시 15]은 도 101에 도시된 테이블을 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>
도 102는 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 근로 여부에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 102에 도시된 선등록 PDI 질문이 포함하는 내용은 도 91에서 설명한 바와 같다.
구체적으로 도 102에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 근로에 관한 정보를 포함할 수 있다. 또한 도 102에 도시된 선등록 PDI 질문은 QSA 타입으로서, 사용자의 근로 여부에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 102에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 100에 도시된 근로에 관한 선등록 PDI 질문은, 예 및 아니오에 대한 2가지 선택 정보를 포함할 수 있다.
이하 [예시 16]은 도 102에 도시된 테이블을 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>
도 103은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 성별에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 103에 도시된 선등록 PDI 질문이 포함하는 내용은 도 91에서 설명한 바와 같다.
구체적으로 도 103에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 근로에 관한 정보를 포함할 수 있다. 또한 도 103에 도시된 선등록 PDI 질문은 QBA 타입으로서, 사용자의 근로 여부에 관한 불 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 17]은 도 103에 도시된 테이블을 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>
도 104는 본 발명의 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 104는 상술한 선언 콘텐츠 오브젝트(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 질문을 관리(예를 들면, 갱신, 추가, 또는 삭제)할 수 있도록 한다.
도 104는 본 발명의 일 실시예에 따른 PDI API를 나타낸 테이블이다. 본 발명의 일 실시예에 따른 수신기는 도 104에 도시된 PDI API를 이용하여 PDI 테이블 리스트를 획득할 수 있다.
이하 도 104에 도시된 API에 대해 설명한다.
도 104에 도시된 API의 명칭은 getPDITableList()로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 104에 도시된 설명은 getPDITableList() API 함수의 상세 내용을 나타낸다. 도 104에 도시된 인수(arguments)는 getPDITableList() API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 104에 나타낸 설명은 getPDITableList() API 함수가 각각에 대해 pdiTableId를 제공하며 PDI 테이블의 리스트를 갖는 XML 구조를 응답한다는 것을 나타낸다. XML 구조는 다음의 XML 스키마와 같다. 하나의 pdiTableId 하위 엘리먼트를 갖는 pdiTableList 엘리먼트는 카디널리티 0을 갖고 무한하다. 0 pdiTableId 경우는 방송사가 PDI 테이블을 제공하지 않았다는 것을 나타낸다.
도 104에 나타낸 인수는 pdiTableId가 PDI 테이블의 전세계적으로 유일한 식별자라는 것을 URI의 형태로 나타낸다.
따라서 본 발명의 일 실시예에 따른 수신기는 XML 스키마에 따른 테이블 포맷의 PDI 테이블 리스트를 수신할 수 있다. 도 104에 도시된 바와 같이, PDI 테이블 리스트는 pdiTableId 엘리먼트를 포함할 수 있다. 도 104에 도시된 pdiTableId 엘리먼트의 카디널리티가 0을 지시할 경우, 본 발명의 일 실시예에 따른 수신기가 방송사로부터 PDI 테이블을 수신하지 않았음을 의미할 수 있다.
도 105는 본 발명의 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 105는 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 획득하기 위한 PDI API를 나타낸 도면이다.
이하 도 105에 도시된 API에 대해 설명한다.
도 105에 도시된 API의 명칭은 getPDITable(String pdiTableId)로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 105에 도시된 설명은 getPDITable(String pdiTableId) API 함수의 상세 내용을 나타낸다. 도 105에 도시된 인수는 getPDITable(String pdiTableId) API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 105에 나타낸 설명은 getPDITable(String pdiTableId) API 함수가 수신기에 대해 PDI 테이블 XML 문서를 응답하기 위한 것임을 나타낸다. 각 pdiTable은 해당 방법에 대한 입력으로 제공된 전세계적으로 유일한 pdiTableId 식별자에 의해 식별된 것과 관련되어 있다. 응답된 값은 연재된 PDI 테이블 XML 경우를 포함하며 선택적으로 PDI-Q 또는 PDI-A XML 경우를 포함하는 스트링이다.
도 105에 나타낸 인수는 pdiTableId가 PDI 테이블의 전세계적으로 유일한 식별자라는 것을 URI의 형태로 나타낸다.
따라서 본 발명의 일 실시예에 따른 수신기는, 도 104에서 설명한 PDI 테이블 리스트를 수신한 후에, PDI 테이블을 수신할 수 있다. 구체적으로 PDI 테이블 리스트를 수신한 수신기는, 도 104에 도시된 pdiTableId에 연관된 PDI 테이블 XML 문서를 수신할 수 있다.
구체적으로, 도 105에 도시된 PDI API에 따른 수신기의 동작은 도 55 내지 34, 도 73, 도 84, 도 86 및 도 89 내지 도 92에서 설명한 바와 같다. 또한 도 105에 도시된 PDI API에 따른 수신기는 도 59 내지 도 68에서 설명한 PDI 테이블 포맷에 따른 PDI 테이블 리스트를 수신할 수 있다.
도 106은 본 발명의 또 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 106은 본 발명의 일 실시예에 따른 수신기가 PDI 답변을 획득하기 위한 PDI API를 나타낸 도면이다.
이하 도 106에 도시된 API에 대해 설명한다.
도 106에 도시된 API의 명칭은 getPDIA(String pdiTableId)로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 106에 도시된 설명은 getPDIA(String pdiTableId) API 함수의 상세 내용을 나타낸다. 도 106에 도시된 인수는 getPDIA(String pdiTableId) API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 106에 나타낸 설명은 getPDIA(String pdiTableId) API 함수가 수신기에 대해 PDI-A XML 문서를 응답하기 위한 것임을 나타낸다. 각 pdiTable은 해당 방법에 대한 입력으로 제공된 전세계적으로 유일한 pdiTableId 식별자에 의해 식별된 것과 관련되어 있다. 응답된 값은 연재된 PDI-A XML 경우를 포함하는 스트링이다.
도 106에 나타낸 인수는 pdiTableId가 PDI 테이블의 전세계적으로 유일한 식별자라는 것을 URI의 형태로 나타낸다.
따라서 도 104에서 설명한 PDI 테이블 리스트를 수신한 수신기는, 도 104에 도시된 pdiTableId에 연관된 PDI-A 테이블의 XML 문서(또는 PDI-A 경우 문서)를 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI-A 경우 문서는 도 65 및 도 66에서 설명한 바와 같다.
구체적으로, 도 106에 도시된 PDI API에 따른 수신기의 동작은 도 65 내지 도 82, 도 73, 도 84, 도 86 및 도 89 내지 도 92에서 설명한 바와 같다.
도 104 내지 도 106에 나타내지 않았지만, 본 실시예에 따른 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 질문 오브젝트를 나타내는 오브젝트.
도 107 은 본 발명의 일 실시예에 따른, 차세대 방송 시스템을 위한 프로토콜 스택 (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 을 시청자에게 제공할 수 있다.
도 108 은 본 발명의 일 실시예에 따른 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 메쏘드 역시 하나만 사용되어도, 무한한 종류의 액션의 교환이 가능할 수 있다.
도 109 은 본 발명의 일 실시예에 따른 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 방식 등에 국한되지 아니한다.
도 110 는 본 발명의 일 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
전술한 바와 같이, 본 발명은 PDI 유저 데이터를, 리시버와 다른 컴패니언 디바이스 간에 교환/전달하는 방법을 제안한다.
여기서, 컨텐츠 프로바이더 또는 브로드캐스터(t89010), PDI Questionnaires(t89020), PDI 엔진(t89030), PDI 스토어(t89040) 는 전술한 동명의 모듈과 같을 수 있다.
전술한 바와 같이 컨텐츠 프로바이더 또는 브로드캐스터(t89010) 이 생성한 PDI Questionaires(t89020) 가 수신기(t89050) 으로 전달될 수 있다. PDI 엔진(t89030) 은 유저에게 해당 Questionairese 를 제공하고 답변(Answer) 를 받아 PDI 스토어(t89040) 에 저장할 수 있다. 실시예에 따라, 사용자에게 질문의 답변을 유도하지 않고, 수신기 내에서 자동으로 답변이 기입될 수 있다.
유저에게 Questionare 를 보여주고, 답변을 저장하는 매커니즘은 전술한 실시예와 같을 수 있으나, 이는 일 실시예일 뿐이다. 본 발명은 이에 국한되지 아니한다.
전술한 바와 같이, PDI 스토어(t89040) 은 수신기(t89050) 내에 위치할 수 있다. 그러나, 실시예에 따라, 수신기 외부에 PDI 클라우드 스토어(t89070) 이 존재할 수도 있다. PDI 클라우드 스토어(t89070) 는 전술한 PDI 스토어(t89040) 와 동일한 동작을 수행할 수 있다. 다만, PDI 클라우드 스토어(t89070) 는 수신기(t89050) 의 외부에 위치하여, 클라우드 서버로서 동작할 수 있다.
본 실시예에서, 수신기(t89050) 은 컴패니언 디바이스 모듈(t89060) 을 더 포함할 수 있다. 저장된 PDI 유저 데이터는 컴패니언 디바이스 모듈(t89060) 을 통해, 컴패니언 디바이스(t89080)로 전달될 수 있다. 반대로, 컴패니언 디바이스 모듈(t89060) 을 통해, 컴패니언 디바이스에서 설정된 답변들이 리시버로 전달될 수도 있다.
본 발명은 UPnP 를 기반으로, 수신기와 컴패니언 디바이스간의 커뮤니케이션 실시예를 설명한다. 그러나, 수신기와 컴패니언 디바이스간의 커뮤니케이션 프로토콜은, 이에 한정되지 아니한다.
도 111 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 112 은 본 발명의 일 실시예에 따른 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 유저 데이터는 어떠한 형태에 국한되지 아니한다.
도 113 는 본 발명의 일 실시예에 따른 서비스의, 서비스 타입과 서비스 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" 일 수 있다.
도 114 은 본 발명의 일 실시예에 따른 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 유저 데이터를 담는 리스트 역할을 할 수 있다. 본 상태변수는 복수개의 Questionaires 와 답변들을 포함할 수 있다. 본 상태변수는 후술할 GetUserData() 액션에서 활용될 수 있다. 본 상태변수의 자세한 구조에 대해서는 후술한다.
A_ARG_TYPE_UserData 는 전술한 UserDataList 의 한 프래그먼트일 수 있다. 이 때, 두 상태변수들은 같은 마크업 언어(mark up language) 에 따를 수 있다. 예를 들어, UserDataList 상태변수가 XML 문서일 경우, A_ARG_TYPE_UserData는 그 XML 문서의 한 프래그먼트가 될 수 있다. 본 상태변수는 복수 개의 PDIUserData 엘레먼트와 어트리뷰트(attributes)를 가질 수 있다. 또한, 본 상태변수는 사용되는 액션의 용도에 따라서 서브 엘레먼트들을 포함할 수 있다. A_ARG_TYPE_UserData 는 실시예에 따라 생략될 수도 있다.
도 115 는 본 발명의 일 실시예에 따른 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 유저 데이터의 구조 또는, 실시예에 따라 다른 형태의 구조를 가질 수 있다.
도 116 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션(action)들을 도시한 도면이다.
전술한 UserData 서비스에는 GetPDIUserDataProtocolVersion, GetUserDataIdsList, GetUserData, 및/또는 SetUserData 액션이 있을 수 있다. 여기서, GetPDIUserDataProtocolVersion 는 비필수적(Optional) 한 액션일 수 있고, 나머지 3 개의 액션은 필수적(Required)인 액션일 수 있다. 실시예에 따라, GetPDIUserDataProtocolVersion 는 생략될 수도 있다. 또한 실시예에 따라 추가적인 액션들이 더 정의될 수 있다.
각 액션에 대해서는 후술한다.
도 117 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetPDIUserDataProtocolVersion 를 설명하는 도면이다.
GetPDIUserDataProtocolVersion 액션은 PDI 유저 데이터를 가져오기 위한 프로토콜의 버전이 무엇인지 알기위해 사용되는 액션일 수 있다. 여기서, 프로토콜은 수신기(혹은 Primary Device) 가 지원하고 있는 프로토콜을 의미할 수 있다. 컴패니언 디바이스는 GetPDIUserDataProtocolVersion 액션을 이용하여, 수신기가 지원하는 프로토콜의 버전을 알 수 있다.
GetPDIUserDataProtocolVersion 을 사용하기 위해, PDIUserDataProtocolVersion 아웃풋 아규먼트(argument) 가 정의될 수 있다. PDIUserDataProtocolVersion 는 디바이스에 의해 지원되는 UserData 서비스의 프로토콜 버전 정보로서, 전술한 PDIUserDataProtocolVersion 상태변수와 관련있을 수 있다.
도 118 은 본 발명의 일 실시예에 따른 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 아웃풋 아규먼트로서, 수신기에서 컴패니언 디바이스로 전달될 수 있다.
실시예에 따라, ProtocolVersion 을 00000000으로 설정하면 ProtocolVersion에 구분없이 모든 ID의 리스트가 요청될 수 있고, ProtocolVersion을 11111111으로 설정하면 가장 최신 ProtocolVersion에 해당하는 ID의 리스트가 요청될 수 있다.
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 유저 데이터는 복수개의 Questionnaires 이거나 혹은 복수개의 Questionnaires 와 답변(Answer)들의 조합이 될 수 있다.
수신기는 전달받은 PDI 유저 데이터를, 전술한 PDI 엔진으로 전달할 수 있다(ts97020). PDI 엔진은 사용자에게 Questionaires 를 보여주고, 사용자로부터 각 질문에 해당하는 답변을 얻을 수 있다(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) 하면서 요청할 수도 있다.
도 119 은 본 발명의 일 실시예에 따른 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가 요청될 수 있다.
도 120 는 본 발명의 일 실시예에 따른 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 유저 데이터는 복수개의 Questionnaires 이거나 혹은 복수개의 Questionnaires 와 답변(Answer)들의 조합이 될 수 있다.
컴패니언 디바이스는 사용자에게 Questionaires 를 보여주고, 사용자로부터 각 질문에 해당하는 답변을 얻을 수 있다(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 가 함께 저장될 수 있다.
도 121 은 본 발명의 일 실시예에 따른, 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 을 제외한 다음 단계부터 수행될 수 있다.
도 122 은 본 발명의 일 실시예에 따른, 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 엔진은 새로이 답변을 받아, 기존에 저장되어 있던 Questionnaires 의 답변을 변경할 수 있다(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 등의 액션이 사용될 수 있다.
도 123 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, 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 의 한 프래그먼트일 수 있다. 이 때, 두 상태변수들은 같은 마크업 언어(mark up language) 에 따를 수 있다. 예를 들어, UserDataQAList 상태변수가 XML 문서일 경우, A_ARG_TYPE_UserDataQA 는 그 XML 문서의 한 프래그먼트가 될 수 있다. 본 상태변수는 복수 개의 QxAD 엘레먼트와 어트리뷰트(attributes)를 가질 수 있다. 또한, 본 상태변수는 사용되는 액션의 용도에 따라서 서브 엘레먼트들을 포함할 수 있다. A_ARG_TYPE_UserDataQA 는 실시예에 따라 생략될 수도 있다. 본 상태변수는 실시예에따라 스트링의 형태일 수 있다.
도 124 은 본 발명의 일 실시예에 따른 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 의 구조 또는, 실시예에 따라 다른 형태의 구조를 가질 수 있다.
도 125 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션(action)들을 도시한 도면이다.
전술한 UserData 서비스에는 GetUserDataQAIdsList, GetUserDataQA, 및/또는 SetUserDataQA, 액션이 있을 수 있다. 이 액션들은 필수적(Required)인 액션일 수 있다. 실시예에 따라 추가적인 액션들이 더 정의될 수 있다. 각 액션에 대해서는 후술한다.
도 126 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, 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) 하면서 요청할 수도 있다.
도 127 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어 단위 전달을 위한, 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 가 함께 저장될 수 있다.
도 128 은 본 발명의 일 실시예에 따른 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을 미리 알고 있어야 한다.
도 129 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 상태변수를 도시한 도면이다.
본 상태변수들은, 컴패니언 디바이스가 직접 PDI 서버에 요청을 하여 PDI 유저 데이터를 받는 경우의 상태변수들일 수 있다. 이 상황에서, PDIUserDataNotification 및/또는 PDIServerUrl 상태변수가 정의될 수 있다.
PDIUserDataNofitication 상태변수는 브로드밴드채널로 PDI 유저 데이터를 받을 수 있다는 알림을 전달받은 시간을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 dataTime 이며, 이벤트 방식을 따를 수 있다. 이벤트 타입이므로, 알림을 전달받은 시간이 변경되면, 즉 새로이 알림을 받으면, 이를 컴패니언 디바이스에 알릴 수 있다.
PDIServerUrl 상태변수는 브로드밴드채널로 PDI 유저 데이터를 받을 수 있는 PDI 서버의 URL 을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 스트링 또는 anyURI 이며, 액션 방식을 따를 수 있다. 따라서, 컴패니언 디바이스가 액션등을 통해 해당 URL 을 받아와야 할 수 있다. 이에 대해서는 후술한다.
도 130 은 본 발명의 일 실시예에 따른 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 액션이 활용될 수 있다.
도 131 은 본 발명의 일 실시예에 따른, 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 , …,) 등과 같이 표현될 수 있다.
도 132 은 본 발명의 다른 실시예에 따른, 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 일 수 있다.
도 133 는 본 발명의 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
전술한 바와 같이, 사용자가 지정한 PDI 유저 데이터를 이용하여, 개인화된 서비스를 제공할 수 있다. 이를 위하여 필터링 크리테리아(Filtering Criteria) 가 제공될 수 있다. 필터링 크리테리아를 통해 수신기/컴패니언 디바이스는 사용자에게 맞춘 컨텐츠를 제공할 수 있다.
여기서, 컨텐츠 프로바이더 또는 브로드캐스터(t112010), PDI Questionnaires(t112020), PDI 엔진(t112030), PDI 스토어(t112040), PDI 클라우드 스토어(t112070), 컴패니언 디바이스 모듈(t112060), 컴패니언 디바이스(t112080) 는 전술한 동명의 모듈과 같을 수 있다.
여기서, 수신기(t112050) 은 전술한 구조도와 달리 필터링 엔진(t112090), 컨텐츠/서비스 스토어(t112100) 을 더 포함할 수 있다. 필터링 엔진은 각 컨텐츠/서비스의 필터링 크리테리아와, 저장된 PDI 유저 데이터를 비교하여 사용자에게 맞춘 컨텐츠/서비스를 선별할 수 있다. 필터링 크리테리아는 컴패니언 디바이스에도 전달될 수 있다.
실시예에 따라, 필터링 크리테리아에 의해 선별된 데이터가 컴패니언 디바이스에 전달될 수도 있고, 필터링 크리테리아를 컴패니언 디바이스에 전달하여, 컴패니언 디바이스가 직접 필터링을 할 수도 있다.
필터링 크리테리아의 XML 구조에 대해서는 전술하였다. 단, 전술한 구조에 의해 한정되지 아니하며, 실시예에 따라 다른 구조의 필터링 크리테리아가 사용될 수 있다. 이하 필터링 크리테리아는 FC 로 축약하여 불릴 수 있다.
컨텐츠/서비스 스토어(t112050)는 수신한 컨텐츠/서비스를 저장하는 곳이며, 실시예에 따라 필터링 엔진에 의해 필터링된 컨텐츠/서비스가 저장될 수 있다. 또한 실시예에 따라 모든 컨텐츠/서비스가 저장된 후, 추후에 필터링 엔진이 필터링을 수행하여 다시 컨텐츠/서비스 스토어에 저장할 수도 있다.
도 134 은 본 발명의 다른 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
수신기가 컴패니언 디바이스로 필터링 크리테리아를 전달하기 위해서, FilteringCriteria 라는 서비스가 정의될 수 있다. 이 서비스의 서비스 타입은 atsc3.0filtering:1 일 수 있다.
각 서비스는 다른 서비스 ID 를 가질 수 있는 데, 실시예에 따라 uurn:atsc.org:serviceId:atsc3.0filtering1(t113010), 또는 uurn:atsc.org:serviceId:atsc3.0filtering(t113020) 일 수 있다.
FilteringCriteria 서비스에 대해서는 후술한다.
도 135 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
FiltringCriteria 서비스의 한 상태변수로 FilteringCriteria 상태변수가 정의될 수 있다.
FilteringCriteria 상태변수는 컨텐츠/서비스의 필터링을 위하여, 필터링 크리테리아를 컴패니언 디바이스에 전달하기 위해 사용될 수 있다. FilteringCriteria 상태변수는 필수 상태변수로서 데이터 타입은 String 타입(XML, Jason 등..)일 수 있다. 또한, 전술한 액션 방식을 따라, 다양한 액션에서 사용될 수 있다.
도 136 는 본 발명의 일 실시예에 따른 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 엔진에 Questionaires 에 대한 답변을 요청할 수 있다(ts115100). PDI 엔진은 PDI 스토어에 기 저장된 Questionaires 에 대한 답변을 검색할 수 있다(ts115110). PDI 엔진은 검색이 완료된 답변을 컴패니언 디바이스 모듈로 전달할 수 있다(ts115120). 컴패니언 디바이스 모듈은, PDI 유저 데이터인 해당 답변을 컴패니언 디바이스로 전달할 수 있다(ts115130).
컴패니언 디바이스는 FC 와 사용자가 기설정한 답변을 비교할 수 있다(ts115140). FC 가, 사용자의 답변, 즉 PDI 유저 데이터에 만족할 경우, 해당 컨텐츠/서비스가 사용자에게 제공될 수 있다. 그렇지 않은 경우, 해당 컨텐츠/서비스가 사용자에게 제공되지 않을 수 있다.
컴패니언 디바이스는, FC 가 사용자의 답변과 부합할 경우, 수신기로부터 해당 컨텐츠/서비스를 가져올 수 있다. 이 때, 해당 컨텐츠/서비스의 전달은 컴패니언 디바이스 모듈을 통해 수행될 수 있다(ts115150, ts115160). 실시예에 따라, FC 가 사용자의 답변과 부합할 경우, 컴패니언 디바이스는 해당 컨텐츠/서비스를 서비스 프로바이더 또는 브로드캐스터의 서버로부터 직접 수신할 수도 있다.
이 후, 컴패니언 디바이스는 PDI 유저 데이터에 맞는 FC 를 가진 컨텐츠/서비스를 유저에게 노출시킬 수 있다.
도 137 은 본 발명의 일 실시예에 따른 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을 미리 알고 있어야 한다.
도 138 은 본 발명의 일 실시예에 따른, FC가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
본 상태변수들은, 컴패니언 디바이스가 직접 FC 서버에 요청을 하여 FC 를 받는 경우의 상태변수들일 수 있다. 이 상황에서, FilteringCriteriaNotification 및/또는 FCServerUrl 상태변수가 정의될 수 있다.
FilteringCriteriaNotification 상태변수는 브로드밴드채널로 FC를 받을 수 있다는 알림을 전달받은 시간을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 dataTime 이며, 이벤트 방식을 따를 수 있다. 이벤트 타입이므로, 알림을 전달받은 시간이 변경되면, 즉 새로이 알림을 받으면, 이를 컴패니언 디바이스에 알릴 수 있다.
PDIServerUrl 상태변수는 브로드밴드채널로 FC를 받을 수 있는 FC 서버의 URL 을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 스트링 또는 anyURI 이며, 액션 방식을 따를 수 있다. 따라서, 컴패니언 디바이스가 액션등을 통해 해당 URL 을 받아와야 할 수 있다. 이에 대해서는 후술한다.
도 139 은 본 발명의 일 실시예에 따른 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 를 전달받아 개인화 서비스를 제공할 수 있다.
도 140 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
FC 서버는 복수개가 존재할 수 있다. 따라서, FC 서버 URL 역시 복수개가 존재할 수 있다. 수신기는 컴패니언 디바이스가 접속해야할 FC 서버를 특정하여, 그 PDI 서버의 URL 을 전달해 줄 수 있다.
이 때, 접속 가능한 모든 FC 서버의 URL 이 모두 컴패니언 디바이스로 전달될 수도 있다. 이 경우 컴패니언 디바이스가 FC 서버 중 하나를 선택하여 접속할 수 있다. 복수개의 URL 을 전달하기 위하여 전술한 FCServerUrl 을 활용하여 수행될 수 있다. 단 이 경우, FCServerUrl 은 확장되어 데이터 타입이 "List of string" 또는 "List of anyURI" 로 변경될 수 있다.
실시예에 따라, FCServerUrl 는 CSV 형태일 수 있으며, ( , , …,) 등과 같이 표현될 수 있다.
도 141 은 본 발명의 다른 실시예에 따른 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 일 수 있다.
도 142 은 본 발명의 일 실시예에 따른 방송 수신기를 나타낸 도면이다.
본 발명의 일 실시예에 따른 방송 수신기는, Service / Content Acquisition Controller (J2010), 인터넷 인터페이스 (J2020; Internet interface), 방송망 인터페이스 (J2030; Broadcast interface), 시그널링 디코더 (J2040), 서비스 맵 데이터 베이스 (J2050), 디코터 (J2060), 타겟팅 프로세서 (J2070), 프로세서 (J2080), 관리 유닛 (J2090; Managing unit) 및/또는 재분배 모듈 (J2100; redistribution module) 를 포함한다. 도면에서는 방송 수신기의 외부 및/또는 내부에 존재할 수 있는 외부 관리장치 (J2110; External Management)이 도시되어 있다.
Service / Content Acquisition Controller (J2010)는 broadcast/broadband 채널을 통하여 서비스 및/또는 콘텐츠, 이와 관련된 시그널링 데이터를 수신한다. 또는 Service / Content Acquisition Controller (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)는 broadcast 채널 등을 통하여 획득한 시그널링 데이터 또는 시그널링 정보 (이하 '시그널링 데이터'라 한다)를 디코딩한다.
서비스 맵 데이터 베이스 (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)는 방송 서비스/컨텐츠 서버 등, 방송 서비스/콘텐츠 제공을 위한 방송 수신기 외부의 모듈들을 지칭한다. 외부 관리 장치의 역할을 수행하는 모듈은 방송 수신기 내부에 구비될 수도 있다.
도 143 는 본 발명의 다른 실시예에 따른 방송 수신기를 나타낸 도면이다.
도시된 수신기는 전술한 수신기 및 수신기에 포함되는 장치와 유사하므로, 동일한 명칭을 가지는 장치에 대한 설명은, 전술한 설명으로 대체한다.
전술한 타겟팅 시그널링 파서 (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)를 더 포함할 수 있다. 유저 데이터 데이터베이스는 처리된 유저 데이터를 저장한다.
도 144 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 를 도시한 도면이다.
프리젠테이션 선호도란, 클로즈드 캡션(closed caption), 오디오(audio), 접근성(Accessibility) 및/또는 수화(Sign Language) 등에 있어, 방송 시청시 해당 클로즈드 캡션등이 보여질 것인지에 관한 선호도를 의미할 수 있다.
유저의 프리젠테이션 선호도가, 개인화된 정보로서 수신기에 저장되면, 방송 시청시 그 유저에 맞춘 서비스 제공이 가능하다. 유저는 관련 정보를 매번 세팅해줄 필요없이, 자신의 선호도(preference)에 맞춰진 서비스를 제공받을 수 있다. 실시예에 따라, 유저 프리젠테이션 선호도는 방송 시청 전, 또는 방송 시청 중에 프리-레지스터드(pre-registered) 될 수 있다.
또한, 설정된 프리젠테이션 선호도는 수신기외에 컴패니언 디바이스들에도 공유되어 활용될 수 있다. 반대로, 컴패니언 디바이스들에서 설정된 프리젠테이션 선호도가 수신기로 공유될 수도 있다.
본 발명에서는 프리젠테이션 선호도 중, 클로즈드 캡션, 오디오, 접근성&수화 프리젠테이션에 대해서 설명한다. 그러나, 프리젠테이션 선호도에 관계된 서비스들은 다양할 수 있으며, 본 발명은 상기 세 항목의 프리젠테이션 선호도에 한정되지 아니한다.
도 145 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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 를 통해 해당 질문에 대한 답변을 다시금 받을 수도 있다. 이 경우 새로운 답변은 기존 답변과 답변 시각 등의 측면에서 비교되고, 새로운 답변이 기존 답변을 대체할 수도 있다.
도 146 는 본 발명의 다른 실시예에 따른 클로즈드 캡션 선호도(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) 은 전술한 바와 같을 수 있다.
도 147 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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 영역으로 전달되는 클로즈드 캡션을 파싱하는 과정에서 사용자에게 보여줄 수 있다.
도 148 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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" 의 답변을 할 수 있다.
도 149 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 언어를 이용하여 클로즈드 캡션을 제공할 수 있다.
도 150 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 폰트를 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 폰트로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 151 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 글자 크기를 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 글자 크기로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 152 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 정렬 방식을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 정렬 방식으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 153 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 으로 제공되는 프린트 방향을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 프린트 방향으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 154 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 으로 제공되는 스크롤 방향을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 스크롤 방향으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 155 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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자의 서버에서 전달받아, 수신기가 이지 리더의 형태로 변환, 표시할 수 있다.
도 156 는 본 발명의 일 실시예에 따른 오디오 선호도(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 를 통해 해당 질문에 대한 답변을 다시금 받을 수도 있다. 이 경우 새로운 답변은 기존 답변과 답변 시각 등의 측면에서 비교되고, 새로운 답변이 기존 답변을 대체할 수도 있다.
도 157 는 본 발명의 다른 실시예에 따른 오디오 선호도(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) 은 전술한 바와 같을 수 있다.
도 158 는 본 발명의 일 실시예에 따른 오디오 선호도(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 들을, 오디오 스트림의 오디오를 파싱하는 과정에서 사용자에게 보여줄 수 있다.
도 159 는 본 발명의 일 실시예에 따른 오디오 선호도(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) 로 제공되는 언어를 이용하여 클로즈드 캡션을 제공할 수 있다.
도 160 는 본 발명의 일 실시예에 따른 오디오 선호도(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" 의 답변을 할 수 있다. 오디오의 청각 장애인을 위한 모드가 제공되지 않는 경우, 수신기는 기본적인 모드로 오디오를 제공할 수 있다.
도 161 은 본 발명의 일 실시예에 따른 오디오 선호도(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" 의 답변을 할 수 있다. 오디오의 시각 장애인을 위한 모드가 제공되지 않는 경우, 수신기는 기본적인 모드로 오디오를 제공할 수 있다.
도 162 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(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) 은 전술한 바와 같을 수 있다.
도 163 은 본 발명의 다른 실시예에 따른 접근성&수화 프리젠테이션(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) 은 전술한 바와 같을 수 있다.
도 164 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(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 으로 변환하여 사용자에게 보여줄 수 있다.
도 165 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(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" 등의 답변을 할 수 있다.
도 166 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(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) 의 서버에 접근하여 해당 수화 언어 서비스를 전달받아 화면에 표시할 수도 있다.
도 167 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(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) 로 제공되는 수화 위치에 수화 서비스를 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 위치에 강제로 수화 서비스를 표시할 수도 있다.
도 168 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(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 스토어에 저장되어, 기 저장된 답변을 업데이트 시킬 수 있다.
도 169 은 본 발명의 또 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
기존의 PDI 시스템은, 한명의 사용자에게 개인화된 서비스를 제공하는 형태였기 때문에, 복수의 사용자들간의 선호도 및 Q&A 를 관리할 수 없었다. 본 발명에서는 PDI 유저 데이터를 복수의 유저간에 별도로 설정하고, 유저에 따라 개인화된 서비스를 제공하는 방법을 제안한다.
본 구조도에서, 컨텐츠 프로바이더 또는 브로드캐스터, PDI Questionnaires, PDI 엔진, PDI 스토어, PDI 클라우드 스토어, 컴패니언 디바이스 모듈, 컴패니언 디바이스, 필터링 엔진, 컨텐츠/서비스 스토어 는 전술한 동명의 모듈과 같을 수 있다.
본 구조도에서, 수신기(t148020)는 전술한 구조도와 달리 유저 매니지먼트 엔진(User Management Engine)(t148010) 을 더 포함할 수 있다.
유저 매니지먼트 엔진(t148010)은 복수의 사용자간에 PDI 유저 데이터를 관리하는 역할을 할 수 있다. 복수의 사용자마다 선호도가 다를 수 있으므로, 유저 매니지먼트 엔진(t148010)은 사용자를 구분하고, 각 사용자에 맞게 답변 저장 및/또는 필터된 컨텐츠 및 서비스를 전달할 수 있다. 실시예에 따라 유저 매니지먼트 엔진(t148010) 의 동작은 PDI 엔진 또는 별도의 모듈에서 처리될 수도 있다.
도 170 는 본 발명의 일 실시예에 따른, 유저 ID 필드를 더 포함하는 PDIUserData 를 도시한 도면이다.
수신기가 복수의 사용자를 구분하고, 각각의 사용자의 선호도에 맞게 컨텐츠/서비스를 제공하기 위해서, 유저 매니지먼트 엔진은 복수의 사용자를 식별할 수 있어야 한다. 유저 매니지먼트 엔진이 복수의 사용자를 식별하는 방안은 다음과 같을 수 있다. 복수의 사용자를 식별하는 방안은 실시예에 따라 다양하게 선택될 수 있다.
먼저, 로그인(log in) 방식은, 사용자에게 PDI Question 을 보여주기 전에 사용자가 로그인하는 방식일 수 있다. 유저 매니지먼트 엔진은 UI 를 통해 로그인 창을 사용자에게 노출할 수 있다. 로그인 창이 노출되는 시점은 실시예에 따라 수신기가 켜진 직 후, 또는 PDI Questionnaires 를 수신한 시점일 수 있다.
사용자는 로그인 창이 노출되면 자신의 유저 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 필드가 추가될 수 있다.
도 171 는 본 발명의 일 실시예에 따른, 유저 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 의 답변으로 저장될 수 있다.
도 172 는 본 발명의 일 실시예에 따른, 유저 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 세션이 아닌 다른 소스로부터 다운로드를 받을 수도 있다.
현재 로그인되어 있는 유저에 적합하지 않은 컨텐츠/서비스라 할지라도, 유저 매니지먼트 엔진에 의해 관리되는 유저들 중에 해당 컨텐츠/서비스를 선호하는 유저가 있을 경우, 향후 사용을 위해 해당 컨텐츠/서비스를 다운로드 받아놓을 수도 있다. 유저 매니지먼트 엔진에 의해 관리되는 유저들 중에 해당 컨텐츠/서비스를 선호하는 유저가 하나도 없을 경우, 해당 컨텐츠/서비스를 다운로드 받지 않을 수 있다.
도 173 는 본 발명의 일 실시예에 따른, 유저 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 는 글로벌하게 유니크해질 수 있다.
도 174 는 자동답변에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
본 발명은 특정 PDI 질문에 대하여, 그 질문을 사용자에게 보여주지 않고 수신기가 자동으로 답변하여 처리하는 방안을 제안한다.
PDI 유저 데이터를 통해 개인화된 서비스를 제공하기 위해서는, 먼저 PDI 테이블의 PDI 질문들을 사용자에게 노출시켜 그 답변을 획득하는 방식으로 PDI 유저 데이터를 획득해야 한다. 그러나 특정 타입의 질문들은 사용자가 직접 답을 기입하기 어려울 수 있다. 예를 들어 수신기의 위치정보, 즉 GPS 정보 등은 개인화에 참조하기 좋은 정보이나, 사용자가 그 정보를 직접 기입하기 어려울 수 있다. 또한, 과도한 질문의 노출은 사용자에게 불편함을 초래할 수 있다.
따라서, 이런 타입의 질문들은 사용자에게 노출시키지 않고, 수신기가 수신기내에서 자동으로 답변을 기입할 수 있다. 예를 들어 GPS 정보를 알 수 있는 수신기의 경우, 수신기가 수신기의 현재 GPS 정보를 직접 기입하여 수신기의 위치정보에 대한 질문에 답변할 수 있다. 이 경우 사용자에게 노출되는 질문의 수를 줄일 수 있어 쾌적한 시청환경을 만들 수 있다.
따라서, 본 발명은 특정 PDI 질문에 대하여, 수신기가 자동으로 답변하여 처리하는 방안을 제안한다. 이는 전술한 PDI 유저 데이터 내지 PDITable 를 확장하여 수행될 수 있다.
도시된 PDI 유저 데이터는 PDIUserData 를 루트 엘레먼트로서 가질 수 있다. 루트 엘레멘트 내의 @protocolVersion 등의 성질(attribute)와 QIA 등의 엘레멘트는 전술한 바와 같을 수 있다.
단, 각각의 QIA, QBA, QSA, QTA, QAA 등의 질문 엘레멘트는 @autoPopulate 를 추가로 포함할 수 있다. 이는 각각의 XML 데이터 타입인 QIAType, QBAType, QSAType, QTAType, QAAType 등에서 정의될 수 있다.
@autoPopulate 는 해당 PDI 질문이, 수신기가 자동으로 답변기입이 가능한 형태인지를 여부를 지시하는 성질(attribute)일 수 있다. 하나의 @autoPopulate 가 PDI 질문 엘레멘트 내에 포함될 수 있으며, 불리안(boolean) 데이터 타입을 가져 일종의 플래그(flag)역할을 할 수 있다. 본 필드의 값이 TRUE 일 경우 해당 PDI 질문은 수신기가 자동으로 답변기입이 가능한 타입일 수 있다.
수신기는 @autoPopulate 의 값이 TRUE 일 경우, 해당 PDI 질문을 사용자에게 노출시키지 않을 수 있다. 이 경우, 수신기는 해당 PDI 질문에 대한 답변을 스스로 기입할 수 있다. 또한 이 경우, Q 엘레멘트의 Qtext 는 참조되지 않을 수 있다. 수신기는 해당 PDI 질문에 대한 답변을 할 때, 전달받은 시그널링 정보를 이용해서 답변하거나, 별도의 API 를 통해 답변할 수 있다.
수신기는 @autoPopulate 의 값이 FALSE 일 경우, Q 엘레멘트의 Qtext 를 참조해서, 일반적인 방식으로 PDI 질문을 사용자에게 노출시킬 수 있다.
자동 답변이 가능한 질문 타입은 미리 고정적으로 정의해서 등록해 둘 수 있다(Pre registered). 자동 답변이 가능한 질문 타입을 고정적으로 정의해 등록해 두는 경우, 자동 답변을 위한 API 도 별도로 정의해 둘 수 있다.
자동 답변이 가능한 질문 타입에는, 예를 들어, 경도/위도/GPS 등의 위치(location) 정보, 디바이스(TV, 모바일폰 등)가 지원하는 해상도/코덱 등의 디바이스 능력(capability) 정보, 또는 사용자의 시청 히스토리 정보 등이 있을 수 있다.
도 175 은 재답변 인터벌에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
PDI 유저 데이터의 답변을 업데이트하는 데에는 다양한 방법이 있을 수 있다. 일반적인 PDI 질문 뿐만 아니라 자동 답변 가능한 질문의 경우에도, 수시로 변경되는 위치 정보 같은 정보에 관한 질문의 경우 업데이트가 필요할 수 있다.
PDI 유저 데이터의 답변을 업데이트하는 방법으로 하기 실시예들을 설명한다. 업데이트 방안에는 여러 실시예가 있을 수 있으며 하기 실시예들에 한정되지 아니한다. 또한, 하기의 실시예들은 조합되어 사용될 수 있으며, 그 조합 역시 본 발명의 범위에 포함된다.
첫번째로, PDI 질문 및 그 답변을 삭제한 후 새로운 PDI 질문을 수신하여 답변을 획득하는 방법이 있을 수 있다. 질문에 대한 답변을 업데이트하기 위하여 PDITable 내의 각 질문에 대한 QxA 엘레멘트 중 @expire 성질(attribute) 가 활용될 수 있다. @expire 가 지시하는 만료시각이 되면 해당 PDI 질문 및 답변은 더 이상 유효하지 않게 되어 삭제될 수 있다. 이 후 삭제된 것과 동일한 @id 값을 가지는 PDI 질문을 다시 받아 답변을 획득할 수 있다. 이 때, 해당 질문이 자동답변 가능한 질문으로 설정된 경우 수신기가 자동으로 답변을 기입할 수 있다. 해당 질문이 자동답변 가능하지 않은 질문으로 설정된 경우, 수신기는 해당 질문을 사용자에게 노출시켜 새로운 답변을 얻을 수 있다.
PDITable 을 전송하는 서비스 프로바이더는 만료시각을 알고 있으므로, 방송망 등을 통하여 동일한 PDI 질문을 다시 수신기로 재전송할 수 있다. 또는 해당 PDI 질문을 다시 받아오기 위해서, 브로드밴드 등을 통하여 수신기가 PDI 서버로 해당 PDI 질문을 요청할 수 있다. 이 때 PDI 서버로부터 특정 PDI 질문을 받아오는 것에는 여러 방법이 있을 수 있다. 예를 들어 PDI 서버 URL 에 PDI 질문의 ID 값을 파라미터로 하여 요청할 수 있다 (e.g. ). 다시 받아 온 PDI 질문의 @expire 값은 이전 질문의 @expire 와 다른 새로운 값을 가질 수 있다.
두번째로, PDI 질문 및 그 답변을 삭제한 후 수신기에서 새로운 PDI 질문을 생성하여 답변을 획득하는 방법이 있을 수 있다. @expire 가 가리키는 만료시각이 되면 해당 PDI 질문 및 그 답변이 삭제될 수 있다. 이 후 수신기는 수신기 내의 정보를 이용하여 해당 PDI 질문을 다시 생성해 낼 수 있다. 특히 자동 답변 가능 질문의 경우, 그 유형이 미리 정의되어 수신기내에 등록되어 있을 수 있는데(Pre registered), 이 정보에 따라 수신기는 질문을 생성해 낼 수 있다. PDI 질문이 생성되면, 자동답변 가능 질문의 경우 수신기가 자동으로 답변을 기입하고, 그렇지 않은 경우 수신기가 해당 질문을 사용자에게 노출시켜 답변을 획득할 수 있다. 이 실시예는 특히, PDI 질문을 외부로부터 수신할 수 없는 환경에서 유용할 수 있다.
세번째로, PDI 질문은 그대로 유지한 채, 그에 해당되는 답변만을 업데이트할 수 있다. 자동 답변이 가능한 질문일 경우, 특정 시각이 되면 수신기가 그 질문에 대하여 새로이 답변을 기입하여 답변을 업데이트시킬 수 있다. 또한, 자동 답변이 불가능한 질문일 경우, 특정 시각이 되면 그 질문을 사용자에게 노출시켜 새로운 답변을 기입하도록 할 수 있다. 실시예에 따라, 자동 답변이 가능한 질문은 이 세번째 실시예에 따라 답변을 업데이트하고, 그렇지 않은 질문은 전술한 첫번째 또는 두번째 실시예에 따라 새로운 PDI 질문을 획득하여 답변을 얻을 수도 있다. 또한 실시예에 따라, 특정 질문의 경우 삭제가 되지 않도록 하여, 답변만을 업데이트하도록 할 수도 있다. 전술한 특정 시각을 지시하는 방법에 대해서는 후술한다.
네번째로, PDI 질문은 그대로 유지한 채, 그에 해당하는 답변을 받되, 이전의 답변을 업데이트시키는 것이 아니라 새로운 답변을 추가하여 답변들이 누적되도록 할 수 있다. 예를 들어 GPS 정보의 경우, 현재 시점의 GPS 좌표를 통한 위치 정보 외에 누적된 GPS 좌표의 변경 히스토리 정보가 개인화된 서비스 제공을 위해 필요할 수 있다. 이 경우 새로운 답변이 이전 답변을 덮어씌우는 것 보다는 복수개의 답변이 시간 순서로 존재하는 것이 필요할 수 있다. 따라서 세번째 실시예와 달리 답변이 계속 추가되는 방식으로 PDI 유저 데이터에 축적될 수 있다.
자동 답변이 가능한 질문일 경우, 특정 시각이 되면 수신기가 그 질문에 대하여 새로이 답변을 기입하여 답변을 추가할 수 있다. 또한, 자동 답변이 불가능한 질문일 경우, 특정 시각이 되면 그 질문을 사용자에게 노출시켜 새로운 답변을 추가하도록 할 수 있다. 실시예에 따라, 자동 답변이 가능한 질문은 이 네번째 실시예에 따라 답변을 추가하고, 그렇지 않은 질문은 전술한 첫번째 또는 두번째 실시예에 따를 수 있다. 또한 실시예에 따라, 특정 질문의 경우 삭제가 되지 않도록 하여, 답변들을 추가하게 할 수도 있다. 전술한 특정 시각을 지시하는 방법에 대해서는 후술한다. 이 경우, 해당 PDI 질문의 XML 구조는 복수개의 답변을 포함할 수 있도록 변경될 수 있다. 또한, 해당 PDI 질문의 XML 구조는 새로운 답변을 받은 시각 정보를 포함할 수 있도록 변경될 수 있다.
세번째, 네번째 실시예에서 전술한 특정 시각을 지시하는 방법을 설명한다. 여기서, 특정 시각은 @expire 가 지시하는 PDI 질문의 만료시각 전에, 새로운 답변을 얻어 답변 업데이트 또는 답변 추가를 수행해야하는 시각을 의미할 수 있다. 여기서, 답변을 얻는 방법은 수신기에 의한 자동답변기입 방법을 따르거나, 사용자에게 노출함으로써 사용자로부터 답변을 얻는 방법을 따를 수 있다. 실시예에 따라 @expire 가 지시하는 만료시각을 전술한 특정 시각으로 할 수도 있는데, 이 경우에는 @expire 값은 답변 업데이트 / 답변 추가 후에 새로운 값으로 업데이트될 수 있다. 실시예에 따라 @expire 가 전술한 특정 시각이 아닌 해당 PDI 질문의 만료시각을 나타내는 경우, @expire 가 지시하는 만료시각에 해당 PDI 질문 및 답변이 삭제될 수도 있다.
전술한 특정시각을 지시하기 위하여 PDI 유저 데이터는 확장될 수 있다. 전술한 각 PDI 질문 엘레멘트의 A 엘레멘트는 @dateDuration 성질(attribute)를 포함하도록 확장될 수 있다. @dateDuration 필드는 답변을 업데이트/추가하기 위한 재답변 인터벌을 지시할 수 있다. 전술한 A 엘레멘트의 @time 필드는 해당 답변이 기입된 시각을 지시할 수 있는데, @time 이 지시하는 시각에 @dateDuration 이 지시하는 시간을 더하여, 새로이 답변을 얻어야 하는 시각이 계산될 수 있다. 즉, 전술한 양자의 값을 더한 시각이 되면, 수신기는 자동으로 해당 질문에 대한 답변을 기입하거나, 사용자에게 해당 질문을 노출하여 답변을 기입하게 할 수 있다.
이렇게 획득된 답변은 기존 답변을 업데이트하거나 기존 답변에 추가될 수 있다. 또한 재답변에 의한 답변이 기입되면, @time 은 재답변이 이뤄진 시각으로 업데이트될 수 있다. 이 후 @dateDuration 이 지시하는 시간간격 후에 재답변이 이루어지므로, 주기적인 답변의 업데이트/추가가 가능하다. 실시예에 따라, 자동답변가능한 질문에 대해서만 @dateDuration 이 활용될 수도 있고, 모든 질문에 대해 @dateDuration 이 활용될 수도 있다. 여기서, @time 및/또는 @dateDuration 의 단위는 초/분/시간 등의 단위가 사용될 수 있다. @dateDuration 필드는 각 QxAType (QIA, QBA, QSA, QTA, QAA)에 정의될 수 있다.
도 176 는 자동답변 가능한 질문을 보충 질문으로 대체하기 위한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
특정 PDI 질문이 자동답변 가능한 타입의 질문으로서, 자동답변되어야 하는 질문임에도 수신기가 해당 질문에 답변할 수 있는 능력(capability)이 없어(e.g. 하드웨어 제약사항 등) 자동으로 답변하지 못할 수 있다. 예를 들어, 디바이스의 위치 정보를 GPS 좌표로 답해야하는 자동 질문의 경우, GPS 정보를 획득할 수 없는 디바이스의 경우 자동으로 해당 질문을 답변하지 못할 수 있다. 이 경우, 해당 자동답변 질문을 보충질문으로 대체하여 사용자에게 노출시킴으로써, 답변 기입을 유도할 수 있다.
도시된 또 다른 실시예에 따른 PDI 유저 데이터는, 각 PDI 질문 엘레멘트에 대하여 AutoPopulate 엘레멘트를 추가로 포함할 수 있다. AutoPopulate 엘레멘트는 자동답변에 관련한 정보를 포함하는 엘레멘트로서, 해당 PDI 질문이 자동답변 질문인지 여부 등의 정보를 포함할 수 있다. AutoPopulate 엘레멘트는 각 QxAType (QIA, QBA, QSA, QTA, QAA) 엘레멘트에 포함될 수 있다.
@type 은 AutoPopulate 엘레멘트에 포함되는 성질(attribute)로서, 전술한 @autoPopulate 에 해당하는 역할을 수행할 수 있다. 즉, 해당 PDI 질문이, 수신기가 자동으로 답변기입이 가능한 형태인지를 여부를 지시할 수 있다. 본 필드의 값이 TRUE 일 경우 해당 PDI 질문은 수신기가 자동으로 답변기입이 가능한 타입일 수 있다.
@supplementaryQuestion 은 AutoPopulate 엘레멘트에 포함되는 성질(attribute)로서, 보충 질문을 활용할 것인지 여부를 지시할 수 있다. 즉, 본 필드는 해당 PDI 질문이 자동답변 가능 질문일 경우에 수신기가 해당 질문을 자동으로 답변하지 못하는 경우, 사용자에게 보충 질문을 노출시켜서라도 해당 질문의 답변을 획득할 것인지 여부를 지시할 수 있다. 본 필드의 값이 TRUE 일 경우 수신기는 Qtext 를 참조하여, Qtext 의 질문을 사용자에게 노출시키고 직접 답변을 시입하게 할 수 있다. 본 필드의 값이 FALSE 일 경우, 해당 PDI 질문을 사용자에게 노출시키지 않을 수 있다. 하나의 @supplementaryQuestion 가 AutoPopulate 엘레멘트 내에 포함될 수 있으며, 불리안(boolean) 데이터 타입을 가져 일종의 플래그(flag) 역할을 할 수 있다. 본 필드가 생략될 경우, 디폴트(default) 값으로 TREU 또는 FALSE 값이 설정될 수 있다.
도 177 는 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 보충 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
먼저, SSC (Service Signaling Channel) 혹은 FIC (Fast Information Channel) 등의 채널을 통하여 전술한 PDI 유저 데이터(즉 PDI 테이블)이 수신될 수 있다(t165010). 실시예에 따라 PDI 유저 데이터는 서비스 시그널링 정보에 포함되어 전송될 수 있다. 이 실시예에서, PDI 유저 데이터의 AutoPopulate 엘레멘트의 @type 은 TRUE, AutoPopulate 엘레멘트의 @supplimentaryQuestion 역시 TRUE 값을 가질 수 있다.
수신기는 수신한 PDI 유저 데이터를 PDI 엔진으로 전달할 수 있다(t165020). 여기서 PDI 엔진은 수신기 내/외부에 위치할 수 있다. PDI 엔진은 전달받은 PDI 유저 데이터의 PDI 질문이 자동 답변 질문임을 @type 을 통해 파악할 수 있다. PDI 엔진은 API 등을 통해 수신기에 자동 답변을 할 것을 요청할 수 있다(t165030).
수신기는 자동 답변 가능 질문의 답변을 위한 동작을 수행할 수 있다(t165040). 그러나, 해당 질문에 대한 답변을 자동으로 얻지 못하는 경우, PDI 엔진으로 에러 메시지 또는 답변 불가하다는 메시지를 전달할 수 있다(t165050).
PDI 엔진은 수신기로부터 자동으로 기입된 답변을 얻지 못한 경우, @supplimentaryQuestion 값을 참조할 수 있다. 본 실시예에서 @supplementaryQuestion 의 값을 참조한다. @supplementary 값이 TRUE 이므로, PDI 엔진은 본 질문에 대해 사용자에게 직접 답변을 얻어야 함을 알 수 있다. 따라서, PDI 엔진은 UI 에 해당 질문을 전달할 수 있다(t165060). 여기서 UI 는 수신기 내/외부에 위치할 수 있다.
사용자는 노출된 PDI 질문에 답변할 수 있다(t165070). 이 때 사용자는 UI 를 이용하여 답변할 수 있다. 사용자가 답변한 내용은 PDI 엔진으로 전달될 수 있다(t165080). PDI 엔진은 전달받은 답변을 PDI 스토어의 PDI 유저 데이터에 저장할 수 있다. 기존 답변이 있는 경우, 새로운 답변으로 업데이트하거나, 기존 답변에 더하여 새 답변을 추가할 수 있다.
도 178 은 자동답변 가능한 질문을 대체 질문으로 대체하기 위한 ID 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
자동 답변 질문에 대하여, 수신기가 자동으로 답변을 기입할 수 없어 사용자에게 노출시키는 경우, 사용자가 해당 질문에 답변하기 어려울 수 있다. 이는 일반적으로 사용자가 답변하기 어려운 질문이 자동 답변 질문으로 설정되기 때문일 수 있다. 예를 들어, GPS 정보 등은 사용자가 답변하기 어려울 수 있다.
따라서, 수신기가 자동으로 답변을 기입할 수 없는 경우, 본래의 PDI 질문을 대체할 수 있는 대체 질문이 사용자에게 노출되게 할 수 있다. 예를 들어, 자동 답변 질문이 GPS 정보를 묻는 질문인 경우에 있어서, 대체 질문은 사용자가 직접 답변하기 쉬운 집 코드(Zip code)를 묻는 질문일 수 있다.
전술한 대체 질문은 PDI 유저 데이터를 전달하는 서비스 프로바이더 측에서 정할 수 있다. PDI 질문들은 글로벌하게 유니크한 ID 를 가질 수 있으므로, 서비스 프로바이더 측은 특정 질문을 식별하여 이를 대체할 수 있는 유사한 의미의 대체 질문을 전달할 수 있다.
도시된 PDI 유저 데이터의 PDI 질문 엘레멘트는 전술한 AutoPopulate 엘레멘트를 포함할 수 있다. 전술한 AutoPopulate 엘레멘트는 전술한 @type 을 포함할 수 있다. 전술한 AutoPopulate 엘레멘트는 @supplementaryId 를 더 포함할 수 있다.
@supplementaryId 는 해당 자동 답변 가능 질문을 대체 질문으로 대체할 경우, 대체 질문의 ID 를 지시할 수 있다. 즉, 해당 PDI 질문이 자동답변 가능 질문이고(@type == TRUE), 수신기가 이에 대하여 답변을 자동으로 기입하지 못하는 경우, @supplementaryId 는 해당 PDI 질문을 대체할 대체질문의 ID 를 지시할 수 있다.
수신기(혹은 수신기 내의 PDI 엔진)는, @supplementaryId 를 통해 전달받은 ID 를 통해 식별되는 PDI 질문(대체질문) 및 그 답변이 이미 PDI 스토어에 저장되어 있는 경우, 대체질문에 대한 답변을 획득하지 않을 수 있다.
대체 질문이 PDI 스토어에 저장되어 있지 않은 경우, 수신기(또는 PDI 엔진)은 본래의 자동 답변 가능 질문을 무시할 수 있다. 또는 이를 해결하기 위해 수신기는 대체질문에 해당하는 PDI 질문을 서비스 프로바이더 측으로부터 수신할 수 있다.
대체 질문에 해당하는 PDI 질문이 PDI 스토어에 있으나 해당 답변이 없거나, 답변을 업데이트시킬 필요가 있는 경우, 또는 새로이 대체 질문에 해당하는 PDI 질문을 서비스 프로바이더 측으로부터 전달받은 경우, 수신기는 대체 질문을 사용자에게 노출시켜 답변을 유도할 수 있다. 실시예에 따라, 대체질문 역시 자동 답변 가능 질문일 경우, 수신기가 대체질문을 자동으로 기입하도록 할 수도 있다.
도 179 은 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 대체 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
도시된 t167010 - t167050 은 전술한 PDI 유저 데이터를 받고, 자동 답변을 요청하고, 에러메시지를 받는 단계와 같을 수 있다. 단, 이 경우 PDI 유저 데이터의 PDI 질문 엘레멘트는 대체 질문의 ID 를 가지는 @supplementaryId 필드를 포함할 수 있다.
PDI 엔진은 에러 메시지 등을 받은 경우, @supplementaryId 필드를 참조할 수 있다. PDI 엔진은 PDI 스토어에서 대체 질문의 식별자를 가지는 PDI 질문이 있는지 여부를 확인할 수 있다(t167060).
대체 질문이 존재하지 않는 경우, 해당 자동 답변 질문은 무시될 수 있다. 또는 대체 질문을 서비스 프로바이더로부터 수신할 수 있다. 대체 질문이 존재하고 그 답변이 저장되어 있는 경우, 그 대체질문에 대한 새 답변을 얻지 않을 수 있다. 또는 대체 질문에 대한 답변이 저장되어 있지 않거나, 저장되어 있더라도 새로운 답변을 얻을 필요가 있을 경우, 이를 사용자에 노출하여 답변을 얻을 수 있다. 또는 대체 질문이 자동 답변 가능 질문일 경우 수신기가 자동으로 답변을 기입할 수도 있다.
PDI 엔진은 사용자에게 대체질문을 노출시켜야할 경우, 대체 질문을 UI 를 통해 사용자에게 노출시킬 수 있다(t167070). 사용자는 UI 를 통해 대체질문에 대한 답변을 할 수 있다(t167080). UI 는 획득한 답변을 PDI 엔진에 전달할 수 있다(t167090). PDI 엔진은 이를 PDI 스토어의 PDI 유저 데이터에 저장할 수 있다. 기존 답변이 있는 경우, 새로운 답변으로 업데이트하거나, 기존 답변에 더하여 새 답변을 추가할 수 있다.
도 180 은 컨텐츠 히스토리 엔진을 더 포함하는, 본 발명의 또 다른 실시예에 따른 수신기를 도시한 도면이다.
본 발명은 질문과 그 답변을 통하여 서비스를 개인화하는 것 외에, 사용자의 컨텐츠 시청 히스토리를 이용하여 서비스/컨텐츠를 개인화하는 방안을 제안한다. 수신기는 컨텐츠 시청 히스토리 정보를 생성하고, 이를 이용하여 개인화된 서비스를 사용자에게 제공할 수 있다.
도시된 수신기의 구조도에서, 서비스 프로바이더, PDI 엔진, PDI 스토어, PDI 클라우드 스토어, 컴패니언 디바이스 모듈, 컴패니언 디바이스, 필터링 엔진, 컨텐츠/서비스 스토어 등은 전술한 바와 같을 수 있다.
도시된 수신기의 구조도는, 수신기 내부에 컨텐츠 히스토리 엔진 및/또는 컨텐츠 히스토리 스토어를 더 포함할 수 있다. 실시예에 따라 추가된 모듈들은 수신기 외부의 장치에, 또는 수신기 외부의 서버 등에 위치할 수도 있다.
컨텐츠 히스토리 엔진은, 사용자가 시청한 서비스/컨텐츠에 관한 정보들을 모니터링, 수집 및/또는 시그널링하는 역할을 할 수 있다. 컨텐츠 히스토리 엔진은 사용자의 서비스/컨텐츠 사용 내역을 지속적으로 모니터링하고, 시청한 서비스/컨텐츠에 관한 정보를 포함하는 컨텐츠 히스토리 테이블(Contents History Table)을 생성할 수 있다. 컨텐츠 히스토리 테이블에 대해서는 후술한다. 컨텐츠 히스토리 엔진은 사용자의 서비스/컨텐츠 시청 히스토리 정보를 컨텐츠 히스토리 테이블에 추가/삭제/갱신할 수 있다. 서비스/컨텐츠에 관한 정보들은 해당 서비스/컨텐츠에 대한 시그널링이 수행되는 당시에 전달받을 수도 있다. 또한, 컨텐츠 히스토리 엔진은 컨텐츠 히스토리 테이블을 컨텐츠 히스토리 스토어에 저장할 수 있다. 또한, 컨텐츠 히스토리 엔진은 컨텐츠 히스토리 테이블을 PDI 엔진 및/또는 필터링 엔진에 전달하여, 시청 히스토리에 기반한 서비스 개인화에 참조될 수 있도록 할 수 있다. 컨텐츠 히스토리 엔진은 CH(Contents History) 엔진으로 불릴 수 있다. 컨텐츠 히스토리 테이블은 CHT(Contents History Table) 로 불릴 수 있다.
컨텐츠 히스토리 스토어는 전술한 컨텐츠 히스토리 테이블을 저장하는 저장소 역할을 할 수 있다. 컨텐츠 히스토리 스토어는 그 외에 사용자의 서비스/컨텐츠 시청 히스토리에 관한 정보들을 포함할 수도 있다. 컨텐츠 히스토리 스토어는 CH(Contents History) 스토어로 불릴 수 있다.
전술한 컨텐츠 히스토리 엔진은 별도의 모듈로서 존재하지 않고, 전술한 PDI 엔진과 통합될 수 있다. 또한 실시예에 따라, 컨텐츠 히스토리 테이블은 사용 리포팅 데이터(Usage Reporting Data)를 그대로 사용하거나, 그 중에서 필요한 정보들을 참조하여 생성될 수 있는데, 이 경우 컨텐츠 히스토리 엔진은 사용 리포팅 엔진(Usage Reporting Engine) 으로 대체되거나 연계될 수 있다. 또한 이 경우, 컨텐츠 히스토리 엔진은 사용 리포팅 스토어(Usage Reporting Store) 로 대체되거나 연계될 수 있고, 컨텐츠 히스토리 테이블은 사용 리포팅 데이터(Usage Reporting Data) 로 대체되거나 연계될 수 있다.
도 181 는 본 발명의 또 다른 실시예에 따른 방송 수신기의 구조를 도시한 도면이다.
도시된 방송 수신기는, 서비스/컨텐츠 시청 히스토리를 반영하여 개인화된 서비스를 제공하기 위해 확장된 형태일 수 있다. 도시된 방송 수신기의 내부 구조 모듈들은, 전술한 방송 수신기의 내부 구조 모듈들과 같을 수 있다. 도시된 방송 수신기는, 컨텐츠 히스토리 프로세서, 컨텐츠 히스토리 DB 를 더 포함할 수 있다. 여기서, 도시된 각각의 내부 구조 모듈들은 필요한 경우 버퍼를 더 포함할 수 있다.
컨텐츠 히스토리 프로세서는, 사용자가 시청한 서비스/컨텐츠에 관한 정보들을 기록하기 위한 테이블 내지 데이터를 생성하는 기능을 담당할 수 있다. 컨텐츠 히스토리 프로세서는 전술한 컨텐츠 히스토리 엔진에 해당하는 동작을 수행할 수 있다. 전술한 바와 같이, 서비스/컨텐츠에 관한 정보들은 시그널링이 수행되는 당시에 전달받을 수도 있는데, 이 때 전달받는 정보는 서비스 시그널링 파서 / 앱 시그널링 파서 등으로부터 전달받을 수 있다. 또는 실시예에 따라 시그널링 디코더에서 미리 알 수 있는 정보들을 전달받을 수도 있다. 생성된 컨텐츠 히스토리 관련 테이블 내지 데이터는 유저 데이터 쉐어링 & 타겟팅 프로세서로 전달되어 서비스/컨텐츠의 개인화에 활용될 수 있다. 여기서, 유저 데이터 쉐어링 & 타겟팅 프로세서는 전술한 PDI 엔진에 해당하는 동작을 수행할 수 있다.
컨텐츠 히스토리 DB 는, 컨텐츠 히스토리 프로세서에 의해 생성된 테이블 내지 데이터가 저장되는 저장소 역할을 할 수 있다. 컨텐츠 히스토리 DB 는 전술한 컨텐츠 히스토리 스토어에 해당하는 동작을 수행할 수 있다.
전술한 바와 같이, 실시예에 따라 컨텐츠 히스토리 프로세서와 컨텐츠 히스토리 DB 는 사용 리포팅 프로세서(Usage Reporting Processor) 및/또는 사용 리포팅 DB(Usage Reporting DB)로 대체되거나 연계될 수도 있다.
도 182 은 본 발명의 일 실시예에 따른 컨텐츠 히스토리 테이블을 도시한 도면이다.
컨텐츠 히스토리 테이블은, 전술한 바와 같이, 사용자가 시청하고 있거나 시청한 서비스/컨텐츠의 히스토리 정보를 저장하기 위한 테이블일 수 있다. 컨텐츠 히스토리 테이블은 사용자가 시청한 서비스/컨텐츠에 관련된 정보 뿐 아니라, 사용자가 해당 서비스/컨텐츠를 어떠한 방식으로, 어느 정도의 시간 동안 시청했는지에 관한 정보도 포함할 수 있다. 이러한 컨텐츠 히스토리 테이블은 개인화된 서비스/컨텐츠를 제공하는데 사용될 수 있다.
사용자의 서비스/컨텐츠 시청 히스토리 정보는, 사용자의 입력없이 자동으로 컨텐츠 히스토리 테이블의 형태로 저장될 수 있다. 컨텐츠 히스토리 테이블이 생성되고, 정보가 테이블에 저장되는 과정은 전술한 컨텐츠 히스토리 엔진에 의해 수행될 수 있다. 전술한 바와 같이 컨텐츠 히스토리 엔진에 PDI 엔진과 통합되는 경우, PDI 엔진이 해당 과정을 수행할 수 있다. 사용자의 서비스/컨텐츠 시청 히스토리 정보는, 해당 서비스/컨텐츠의 시그널링시 획득될 수도 있다. 또는 GPS 등과 같은 수신기가 직접 획득할 수 있는 정보들은 수신기에서 지원하는 API 에 의해 획득될 수도 있다. 컨텐츠 히스토리 테이블은 사용자가 서비스를 시청하고 있는 중에도 생성될 수 있으며, 서비스 또는 프로그램 단위별로 생성될 수 있다.
생성된 컨텐츠 히스토리 테이블을 이용하여 개인화된 서비스를 제공하기 위해서는, 컨텐츠 히스토리 테이블에 대응되는 필터링 크리테리아(FC, Filtering Criteria)가 필요할 수 있다. PDI 유저 데이터를 이용한 개인화 서비스 제공에 있어서는, PDI 질문과 답변을 포함하는 PDI 유저 데이터를 필터링 크리테리아와 비교하여, 특정 서비스/컨텐츠를 다운로드할지 여부를 결정할 수 있었다. 이러한 선별과정을 통해 개인화된 서비스가 제공될 수 있었다. 컨텐츠 히스토리 테이블을 이용한 개인화 서비스 제공에 있어서도, 생성된 컨텐츠 히스토리 테이블과 필터링 크리테리아를 비교하여 다운로드할 서비스/컨텐츠를 선별함으로써, 개인화된 서비스가 제공될 수 있다.
실시예에 따라 컨텐츠 히스토리 뿐 아니라, 사용자의 PDI 유저 데이터도 참조하여 필터링이 수행될 수 있다. 이 경우 컨텐츠 히스토리 테이블에 대응되는 필터링 크리테리아와, 전술한 PDI 유저 데이터에 대응되는 필터링 크리테리아가 통합되어 수신기로 전송될 수 있다. 또는 실시예에 따라 양자는 분리되어 수신기로 전송될 수도 있다. 이 필터링 크리테리아에 대해서는 PDI 엔진 혹은 필터링 엔진에서 처리가 수행될 수 있다. PDI 유저 데이터에 대응되는 필터링 크리테리아와 컨텐츠 히스토리 테이블에 대응되는 필터링 크리테리아를 모두 만족하거나, 둘 중 하나만 만족하는 경우 서비스/컨텐츠를 사용자에 제공하도록 설정될 수 있다. 이는 실시예에 따라 다르게 설정될 수 있다. 또한, 컨텐츠 히스토리 테이블이 전술한 PDI 유저 데이터의 형태로 변경될 수 있는 경우, PDI 유저 데이터에 대응하는 필터링 크리테리아 하나만 수신기로 전달될 수도 있다.
컨텐츠 히스토리 테이블 및 필터링 크리테리아를 구성하는 데에는 다양한 방법이 있을 수 있다. 본 발명은 5W1H 방법(육하원칙)을 토대로 컨텐츠 히스토리 테이블을 구성하는 실시예를 제안한다. 후술할 필터링 크리테리아 역시 같은 방식으로 구성될 수 있다. 이 방법은 데이터를 카테고리화하므로, 단순히 컨텐츠 히스토리 테이블의 데이터를 ID 로 분류하여 필터링하는 방법보다 효율적이다. 또한 PDI 유저 데이터를 이용한 필터링의 경우, 답변의 타입에 따라 카테고리화를 수행하였으나, 컨텐츠 히스토리 정보의 경우 5W1H 방식을 따르는 것이 서비스/컨텐츠 선별시 더 효과적일 수 있다.
먼저 Who, 즉 누가 시청했는가에 대한 정보가 컨텐츠 히스토리 테이블에 포함될 수 있다. 시청의 주체는 사람(개인 혹은 집단)이 될 수도 있고, 디바이스가 될 수도 있다. 예를 들어 시청 주체를 디바이스의 능력(capability) 관점에서 정의하여, 해상도 1920X1080을 지원하는 디바이스가 시청했다는 정보를 컨텐츠 히스토리 테이블에 포함시킬 수 있다. 이를 통해, 이후 필터링 크리테리아가 사람의 특징(e.g. 성별 등) 및/또는 디바이스의 능력을 필터링하여 개인화된 서비스를 제공할 수 있다.
또한 When, 즉 언제 시청했는가에 대한 정보가 컨텐츠 히스토리 테이블에 포함될 수 있다. 특정서비스/컨텐츠를 시청한 시작시간/종료시간이 명시될 수 있다. 또한 실시예에 따라, 시청의 지속시간이 명시될 수도 있다.
또한 Where, 즉 어디에서 시청했는가에 대한 정보가 컨텐츠 히스토리 테이블에 포함될 수 있다. 어디에서 시청했는지 정보는, 시청한 장소(e.g. GPS 정보 등)를 의미할 수 있다. 또한 실시예에 따라 어떠한 디바이스(e.g. 모바일/스테이셔너리) 를 통해 시청했는지를 의미할 수도 있다.
또한 What, 즉 무엇을 시청했는가에 대한 정보가 컨텐츠 히스토리 테이블에 포함될 수 있다. 시청의 대상은 채널 넘버, 서비스 ID, 앱 ID 등을 이용하여 지시될 수 있다.
또한 How, 즉 어떻게 시청했는가에 대한 정보가 컨텐츠 히스토리 테이블에 포함될 수 있다. 특정 컨텐츠/서비스를 시청할 때 풀 스크린(Full Screen) 을 통해서 시청했는지, PIP 방식을 통해 시청했는지 등의 정보가 포함될 수 있다. 또는 실시예에 따라 시청한 서비스의 레졸루션(resolution) 정보등이 포함될 수도 있다.
본 실시예에서 Why 부분은 고려되지 않았으나, 실시예에 따라 심층화된 개인화를 위하여 Why 정보가 포함될 수도 있다. 이 경우, Why 즉 시청의 이유에 대한 정보는 사용자에게 질문을 노출하여 답변을 받는 방식으로 획득될 수도 있다.
도시된 컨텐츠 히스토리 테이블은 5W1H 방식에 따라 구성된 것으로서, 본 발명의 일 실시예일 뿐이며 다른 방식으로 테이블이 구성될 수도 있다.
CHTable 엘레멘트는 컨텐츠 히스토리 테이블의 루트 엘레멘트로서, @protocolVersion 등의 성질(attribute)들과, 5W1H 에 해당하는 엘레멘트들인 QWhoType, QWhenType, QWhereType, QWhatType, QHowType 엘레멘트들을 포함할 수 있다.
@protocolVersion 성질은 해당 컨텐츠 히스토리 테이블의 프로토콜 버전을 지시할 수 있다. 본 필드는 옵셔널(optional) 필드로서, 두 16 진법 디짓을 포함할 수 있다. 고차의 4 비트는 메이저 버전 넘버, 저차의 4 비트는 마이너 버전넘버를 의미할 수 있다.
@chTableId 성질은 해당 컨텐츠 히스토리 테이블의 ID 를 지시할 수 있다. 필수(required) 필드로서, ID 는 글로벌하게 유니크할 수 있다.
@chTableVersion 성질은 해당 컨텐츠 히스토리 테이블의 버전을 지시할 수 있다. 필수(required) 필드로서, 초기값 0 을 가질 수 있다. 이 값은 1씩 증가하며 255 를 넘어가게되면 다시 0으로 돌아올 수 있다.
@time 성질은 해당 컨텐츠 히스토리 테이블의 필드들에 변경이 있을 경우, 그 변경된 시각정보를 지시할 수 있다. 이 시각정보는 날짜 및/또는 시간으로 표현될 수 있으며, 본 필드는 필수(required) 필드일 수 있다.
@expire 성질은 해당 컨텐츠 히스토리 테이블의 만료시각을 지시할 수 있다. 이 시각정보는 날짜 및/또는 시간으로 표현될 수 있으며, 본 필드는 옵셔널(optional) 필드일 수 있다. 만료시각이 지나면 해당 컨텐츠 히스토리 테이블은 유효하지 않게되며, 삭제될 수 있다.
QWhoType 엘레멘트는 5W1H 카테고리 중 Who 에 해당하는 엘레멘트일 수 있다.
@userType 성질은 시청 주체의 타입을 지시할 수 있다. 즉, 본 필드는 시청 주체가 사람인지 디바이스인지를 구분하기 위한 역할을 수행할 수 있다(예를 들어, 0 이면 사람, 1 이면 디바이스). 본 필드의 값에 따라 @userId 의 형식이 변경될 수 있다.
@userId 성질은 시청 주체를 구분하는 식별자를 포함할 수 있다. 본 필드의 형식/포맷은 @userType 의 값에 따라 변경될 수 있다. 예를 들어 시청 주체가 사람인 경우, 본 필드의 ID 는 atsc.org/user1 과 같은 형식일 수 있다. 또한 시청 주체가 디바이스일 경우, 본 필드의 ID 는 atsc.org/device1:AA:BB:CC:DD:EE:FF 와 같은 맥 어드레드 등의 고유값일 수 있다. 또는 실시예에 따라 본 필드의 ID 는 atsc.org/device1&1920X1080 과 같이 디바이스의 능력(capability) 을 덧붙인 형태일 수도 있다. 또한 실시예에 따라, 시청 주체를 구분할 수 있는 주소나 지역을 나타내는 값이 ID 가 될 수도 있다.
QWhenType 엘레멘트는 5W1H 카테고리 중 When 에 해당하는 엘레멘트일 수 있다.
@startTime 은 특정 컨텐츠 시청의 시작시각 정보를 포함할 수 있다. @endTime 은 특정 컨텐츠 시청이 끝난 시각 정보를 포함할 수 있다. 형식은 날짜 및/또는 시간일 수 있다. 전술한 바와 같이 본 필드들 대신 시청의 지속시간 정보(duration)가 QWhenType 엘레멘트에 포함될 수도 있다. 또는 실시예에 따라 @startTime, @endTime 정보에 더하여 지속시간 정보가 QWhenType 엘레멘트에 포함될 수도 있다.
QWhereType 엘레멘트는 5W1H 카테고리 중 Where 에 해당하는 엘레멘트일 수 있다.
@targetDevice 성질은 특정 서비스/컨텐츠를 시청한 디바이스 타입 정보를 포함할 수 있다. 예를 들어 TV 나 스마트폰 등의 디바이스 타입이 지시될 수 있다.
NonChangeableLocation 엘레멘트는 위치 정보 중 변화하지 않는 정보를 저장하기 위한 엘레멘트일 수 있다. 예를 들어 집 코드(Zip code) 같은 정보는 변하지 않는 타입의 위치 정보라고 할 수 있다. @locationData 는 이 변하지 않는 타입의 위치 정보 값을 포함할 수 있다.
ChangeableLocation 엘레멘트는 위치 정보 중 변화하는 정보를 저장하기 위한 엘레멘트일 수 있다. 예를 들어 GPS 정보 같은 정보는 변하는 타입의 위치 정보라고 할 수 있다. @locationData 는 이 변하는 타입의 위치 정보 값을 포함할 수 있다.
QWhatType 엘레멘트는 5W1H 카테고리 중 What 에 해당하는 엘레멘트일 수 있다.
@channelNum, @serviceId, @broadcastId, @programId 는 각각 시청의 대상이된 서비스/컨텐츠의 채널 넘버, 서비스ID/컨텐츠ID, 브로드캐스터의 ID, 프로그램의ID 정보를 포함할 수 있다.
Component 엘레멘트는 시청의 대상이된 서비스/컨텐츠의 컴포넌트에 대한 정보를 포함하고 있고, @componentId 는 그 대상 컴포넌트의 ID 정보를 포함할 수 있다.
ContnentItem 엘레멘트는 시청의 대상이된 서비스/컨텐츠의 컨텐트 아이템에 대한 정보를 포함하고 있고, @contentItemId 는 그 대상 컨텐트 아이템의 ID 정보를 포함할 수 있다. 예를 들어, @contentItemId 는 NRT 컨텐트 아이템의 식별자를 포함할 수 있다.
OnDemandComponent 엘레멘트는 시청의 대상이된 서비스/컨텐츠의 온 디맨드 컴포넌트에 대한 정보를 포함하고 있고, @onDemandComponentId 는 그 대상 온 디맨드 컴포넌트의 ID 정보를 포함할 수 있다.
App 엘레멘트는 시청의 대상이된 서비스/컨텐츠의 어플리케이션에 대한 정보를 포함하고 있고, @appId 는 그 대상 어플리케이션의 ID 정보를 포함할 수 있다.
ShowSegment 엘레멘트는 시청의 대상이된 서비스/컨텐츠의 쇼 세그먼트에 대한 정보를 포함하고 있고, @showSegmentId 는 그 대상 쇼 세그먼트의 ID 정보를 포함할 수 있다.
InterstitialSegment 엘레멘트는 시청의 대상이된 서비스/컨텐츠의 인터스티셜 세그먼트에 대한 정보를 포함하고 있고, @interstitialSegmentId 는 그 대상 인터스티셜 세그먼트의 ID 정보를 포함할 수 있다. 예를 들어, @interstitialSegmentId 는 광고의 식별자를 포함할 수 있다.
QHowType 엘레멘트는 5W1H 카테고리 중 How 에 해당하는 엘레멘트일 수 있다.
@serviceType 성질은 시청한 서비스/컨텐츠의 서비스 타입에 관한 정보를 포함할 수 있다. 예를 들어 TV 서비스인지, 데이터인지, 오디오만을 가지는 컨텐츠인지 등의 타입정보가 포함될 수 있다.
@usageType 성질은 시청한 서비스/컨텐츠의 사용 타입에 관한 정보를 포함할 수 있다. 예를 들어, 서비스를 PIP 를 통해 시청했는지, 풀 스크린을 통해 시청했는지 등의 정보가 포함될 수 있다.
@resolution 성질은 시청한 서비스/컨텐츠의 사용 타입에 관한 정보를 포함할 수 있다. 예를 들어, 서비스가 UHD 급의 품질인지, 또는 HD, SD 급의 품질인지 등을 나타내는 정보가 포함될 수 있다.
도 183 은 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 필터링 크리테리아를 도시한 도면이다.
전술한 바와 같이, 컨텐츠 히스토리 테이블의 정보와 비교하여 개인화된 서비스를 제공하기 위해 필터링 크리테리아가 정의될 수 있다.
도시된 필터링 크리테리아는 전술한 5W1H 방법에 따른 컨텐츠 히스토리 테이블에 맞추어 변형된 형태의 필터링 크리테리아일 수 있다. 그러나, 필터링 크리테리아가 항상 컨텐츠 히스토리 테이블에 대응되는 형태를 가질 필요는 없고, 일반적인 형태의 필터링 크리테리아도 컨텐츠 히스토리 테이블과의 비교에 사용될 수 있다. 이 경우, 컨텐츠 히스토리 테이블의 정보들 중에 비교에 필요한 정보들을 추출하여 비교에 사용할 수 있다.
전술한 바와 같이, 컨텐츠 히스토리 테이블과 필터링 크리테리아를 비교하여 다운로드할 서비스/컨텐츠를 선별함으로써, 개인화된 서비스가 제공될 수 있다.
FilteringCriteria 엘레멘트는 필터링 크리테리아의 루트 엘레멘트일 수 있다. FilteringCriteria 엘레멘트는 5W1H 에 맞추어 QWhoCriterion, QWhereCriterion 등의 기준정보 엘레멘트들을 포함할 수 있다. 실시예에 따라, FilteringCriteria 엘레멘트는 QWhoCriterion 등의 카테고리별 기준정보들 중 적어도 하나 이상의 기준정보 엘레멘트들을 포함할 수 있다. 예를 들어, QWhereCriterion 만 3개를 포함하는 필터링 크리테리아도 있을 수 있다.
QWhoCriterion 엘레멘트는 Who 에 해당하는 컨텐츠 히스토리 청보에 대응하는 기준 정보를 가지는 기준정보 엘레멘트일 수 있다.
UserTypeCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @userType 성질에 대응되는 기준정보일 수 있다. 즉, 본 필드는 유저 타입(사람 혹은 디바이스)를 구분하기 위한 기준 값을 포함할 수 있다.
UserIdCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @userId 성질에 대응되는 기준정보일 수 있다. 즉, 본 필드는 유저에 따른 구분을 하기 위한 기준 값을 포함할 수 있다.
QWhenCriterion 엘레멘트는 When 에 해당하는 컨텐츠 히스토리 청보에 대응하는 기준 정보를 가지는 기준정보 엘레멘트일 수 있다.
StartTimeCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @startTime 성질에 대응되는 기준정보일 수 있다. 즉, 본 필드는 시청 시작 시각에 대한 기준 값을 포함할 수 있다.
EndTimeCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @endTime 성질에 대응되는 기준정보일 수 있다. 즉, 본 필드는 시청 종료 시각에 대한 기준 값을 포함할 수 있다.
실시예에 따라, StartTimeCriterionValue 와 EndTimeCriterionValue 의 경우 각각 특정 시점을 명시할 수도 있고, StartTimeCriterionValue 와 EndTimeCriterionValue 사이의 기간을 명시할 수도 있다.
Duration 엘레멘트는 시청한 기간에 대한 기준 정보를 가지는 기준정보 엘레멘트일 수 있다. 시청한 기간은 시청 시작시점과 시청 종료시점간의 차이를 의미할 수 있다. @month, @day, @hour 는 각각 월, 일, 시간에 대한 기준 정보 일 수 있다. 각각 현재부터 기준정보 값에 해당하는 만큼의 기간을 의미할 수 있다. 예를 들어, @month 가 3, @day 가 2, @hour 가 2 의 값을 가질 경우, 수신기는 과거 3개월 2일 2시간 전부터 현재까지의 기간 중에 생성된 컨텐츠 히스토리 테이블을 검색하여 비교작업을 수행할 수 있다.
QWhereCriterion 엘레멘트는 Where 에 해당하는 컨텐츠 히스토리 청보에 대응하는 기준 정보를 가지는 기준정보 엘레멘트일 수 있다.
TargetDeviceCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @targetDevice 성질에 대응되는 기준정보일 수 있다. 즉, 본 필드는 타겟 디바이스에 따른 기준 값을 포함할 수 있다.
NonChangeableLocationCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 NonChangeableLocation 엘레멘트에 대응되는 기준정보일 수 있다. 즉, 본 필드는 변하지 않는 위치 정보에 대한 기준 값을 포함할 수 있다.
ChangeableLocationCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 ChangeableLocation 엘레멘트에 대응되는 기준정보일 수 있다. 즉, 본 필드는 변하는 위치 정보에 대한 기준 값을 포함할 수 있다.
QWhatCriterion 엘레멘트는 What 에 해당하는 컨텐츠 히스토리 청보에 대응하는 기준 정보를 가지는 기준정보 엘레멘트일 수 있다.
ChannelNumberCriterionValue 엘레멘트, ServiceIdCriterionValue 엘레멘트, BroadcastIdCriterionValue 엘레멘트, ProgramIdCriterionValue 엘레멘트, ComponentIdCriterionValue 엘레멘트, ContentItemIdCriterionValue 엘레멘트, OnDemandComponentIdCriterionValue 엘레멘트, AppIdCriterionValue 엘레멘트, InterstitialSegmentIdCriterionValue 엘레멘트는, 각각 컨텐츠 히스토리 테이블의 @channelNum, @serviceId, @broadcastId, @programId, @componentId, @comtentId, @onDemandComponentId, @appId, @showSegmentId, @interstitialSegmentId 에 대응되는 기준정보를 가진 엘레멘트일 수 있다. 각각의 필드들은 각각의 채널넘버 또는 ID 정보에 대한 기준정보를 포함하고 있다. 따라서, 각각의 필드들이 활용되어, 서비스, 브로드 캐스터, 프로그램 등이 필터링될 수 있다.
QHowCriterion 엘레멘트는 How 에 해당하는 컨텐츠 히스토리 청보에 대응하는 기준 정보를 가지는 기준정보 엘레멘트일 수 있다.
ServiceTypeCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @serviceType 에 대응되는 기준정보일 수 있다. 즉, 본 필드는 서비스의 타입에 따른 기준 값을 포함할 수 있다.
UsageTypeCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @usageType 에 대응되는 기준정보일 수 있다. 즉, 본 필드는 사용 타입에 따른 기준 값을 포함할 수 있다.
ResolutionCriterionValue 엘레멘트는 컨텐츠 히스토리 테이블의 @resolution 에 대응되는 기준정보일 수 있다. 즉, 본 필드는 레졸루션에 따른 기준 값을 포함할 수 있다.
도 184 는 본 발명의 일 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
전술한 컨텐츠 히스토리 테이블은 각각의 QWhoType 엘레멘트 등의 컨텐츠 히스토리 정보 내의 세부 컨텐츠 히스토리 정보들이 존재할 수 있다. 이 각각의 세부 히스토리 정보들, 즉 컨텐츠 히스토리 테이블 내의 필드들은 고유의 ID 를 가질 수 있고, 그 고유의 ID 를 이용하여 컨텐츠 히스토리 테이블이 간략화될 수 있다.
예를 들어, @userID 성질이 가지는 유저 ID 에 관한 정보는 atsc.org/CHT/user-id 와 같은 ID 정보를 가질 수 있고, @targetDevice 성질이 가지는 타겟 디바이스에 관한 정보는 atsc.org/CHT/target-device 와 같은 ID 정보를 가질 수 있다.
이러한 ID 정보를 이용하여 컨텐츠 히스토리 테이블을 간략화하기 위해서 각 ID 들은 미리 정의될 수 있다. 예를 들어, @userID 의 ID 정보인 atsc.org/CHT/user-id 는 QWhoType 엘레멘트에 속해야 한다는 등의 기준 역시 미리 정의될 수 있다. 정의되는 방법은 실시예에 따라 다를 수 있다.
도시된 컨텐츠 히스토리 테이블은 이 고유의 ID 들을 이용하여 간략화된 컨텐츠 히스토리 테이블일 수 있다.
각각의 QWhoType, QWhenType, QWhereType, QWhatType, QHowType 엘레멘트들은 @id, @value 정보를 포함할 수 있다. @id 는 특정 컨텐츠 히스토리 테이블 필드의 ID 정보를 포함할 수 있다. @value 는 그 ID 정보가 나타내는 특정 컨텐츠 히스토리 테이블 필드의 값을 포함할 수 있다.
도 185 은 본 발명의 다른 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
전술한 컨텐츠 히스토리 테이블의 간략화 방안에 더하여, 어떠한 필드들의 ID 가 어떠한 카테고리에 속하게 되는지에 대한 정보가 미리 정해지는 경우, 컨텐츠 히스토리 테이블이 더욱 더 간략해 질 수 있다.
도시된 컨텐츠 히스토리 테이블은 더욱 더 간략화된 컨텐츠 히스토리 테이블일 수 있다.
ContentHistoryProperty 엘레멘트는 컨텐츠 히스토리 테이블을 구성할 수 있는 컨텐츠 히스토리 정보들에 관한 정보를 포함하는 엘레멘트일 수 있다. ID 정보만으로도 해당 컨텐츠 히스토리 정보가 어느 카테고리에 속하는지를 알 수 있으므로, 5W1H 에 따른 카테고리 구분이 필요 없을 수 있다.
@id 는 컨텐츠 히스토리 필드의 ID 정보일 수 있다. ID 정보만으로 ID 정보가 식별하는 컨텐츠 히스토리 정보가 어느 카테고리에 속하는지 알 수 있다. @value 는 해당 히스토리 정보의 값을 포함할 수 있다.
예를 들어 @id 의 ID 정보가 @userID 필드를 지시하는 경우, @id 정보에 의해 ContentHistoryProperty 엘레멘트가 포함하는 히스토리 정보가 사용자의 ID 정보에 관한 것임을 알 수 있다. 또한, 기 정의된 사항에 의하여, 해당 히스토리 정보다 Who 타입에 속한다는 것도 알 수 있다. 실제 사용자 ID 정보는 @value 를 참조하여 획득될 수 있다.
도 186 는 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 간략화된 필터링 크리테리아를 도시한 도면이다.
전술한 ID 정보를 이용한 간략화 방안을 이용하여, 필터링 크리테리아 역시 단순화될 수 있다. 필터링 크리테리아의 기준 정보 엘레멘트 내에 다양한 세부 기준정보 엘레멘트들이 존재할 수 있다. 이 각각의 세부 기준정보 엘레멘트들 역시 고유의 ID 를 가질 수 있고, 그 고유의 ID 를 이용하여 필터링 크리테리아가 간략화될 수 있다.
도시된 필터링 크리테리아는 ID 정보를 활용하여 간략화된 필터링 크리테리아일 수 있다(t174010).
FilteringCriterion 엘레멘트는 각각의 기준정보에 대한 정보를 가지는 엘레멘트일 수 있다.
@id 는 해당 기준 정보의 ID 정보를 의미할 수 있다. 이를 통해 컨텐츠 히스토리 테이블 내에서 연관된 히스토리 정보와, 해당 기준 정보를 매칭시킬 수 있다.
@CriterionType 은 Who, When, Where, What, How 등의 기준 정보의 타입에 관한 정보를 포함할 수 있다. 실시예에 따라, ID 정보가 카테고리에 따라 분류된 경우, 카테고리에 따른 기준정보의 분류가 필요 없을 수 있다.
CriterionValue 엘레멘트는 @id 에 의해 식별되는 해당 기준 정보의 값을 포함할 수 있다.
전술한 간략화된 필터링 크리테리아는 비트 스트림으로 구성될 수도 있다. 도시된 디스크립터는 간략화된 필터링 크리테리아의 디스크립터일 수 있다(t174020). 이 디스크립터는 방송망으로 전송되는 시그널링 테이블 등의 디스크립터 루프에 위치될 수 있다.
descriptor_tag 는 디스크립터 태그로서, 해당 디스크립터가 서비스/컨텐츠 선별을 위한 필터링 크리테리아 디스크립터임을 지시하는 필드일 수 있다. descriptor_length 는 해당 디스크립터의 길이를 나타낼 수 있다. num_filter_criteria 는 해당 디스크립터 내에 포함된 기준 정보의 개수를 의미할 수 있다. num_filter_criteria 가 나타내는 수 만큼의 타입 정보, ID 정보 등이 존재할 수 있다. 각각의 기준 정보를 표현하기 위함이다.
criterion_type_code 는 포함된 기준 정보의 타입을 나타내는 필드일 수 있다. 예를 들어, 0x01 은 Who, 0x02 는 When, 0x03 은 Where, 0x04 는 What, 0x05 는 How 타입을 의미할 수 있다. 0x00 및 0x06, 0x07 은 향후 사용을 위해 남겨둘 수 있다. 각 값이 가지는 의미는 실시예에 따라 달라질 수 있다.
criterion_id 는 포함된 기준 정보의 식별자를 나타낼 수 있다. criterion_id_length 는 기준 정보 식별자의 길이를 나타낼 수 있다. num_criterion_values 는 해당 기준 정보에 대한 기준 값의 개수를 나타낼 수 있다. 이 필드가 나타내는 수만큼의 criterion_value_length 및 criterion_value 필드가 있을 수 있다. 각각의 기준 값을 표현하기 위함이다.
criterion_value 는 기준 값의 실제 값을 나타낼 수 있다. criterion_value_length 는 그 기준값의 길이를 나타낼 수 있다.
도 187 는 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 일부를 도시한 도면이다.
도 188 은 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 다른 일부를 도시한 도면이다.
두 도면은 원래 하나인 사용 리포팅 데이터를 도시하고 있으나, 도면의 크기를 고려하여 두 개의 도면으로 나뉘어 도시되었다.
전술한 바와 같이, 컨텐츠 히스토리 테이블은 사용 리포팅 데이터(Usage Reporting Data)를 그대로 사용하거나 필요한 정보를 참조하여 생성될 수 있다. 수신기가 사용 리포팅 서비스(Usage Reporting service)를 지원하는 경우, 컨텐츠 히스토리 테이블의 필드 값 중 일부는 사용 리포팅 데이터의 값으로 설정될 수 있다. 또한, 컨텐츠 히스토리 테이블의 필드들이 전부/일부 사용 리포팅 데이터의 각 필드들과 매핑되는 경우, 사용 리포팅 데이터의 각 필드 값들이 전부/일부 참조되어 컨텐츠 히스토리 테이블이 생성될 수 있다. 또한 컨텐츠 히스토리 테이블이 사용 리포팅 데이터로 대체될 수도 있다.
즉, 실시예에 따라 전술한 컨텐츠 히스토리 테이블로서 사용 리포팅 데이터를 그대로 사용하는 경우, 도시된 사용 리포팅 데이터의 포맷이 그대로 컨텐츠 히스토리 테이블의 포맷이 될 수 있다.
또는 실시예에 따라 전술한 컨텐츠 히스토리 테이블이 사용 리포팅 데이터의 일부를 사용하거나 참조하는 경우, 전술한 컨텐츠 히스토리 테이블의 형태에서 도시된 사용 리포팅 데이터의 일부 필드들이 추가된 형태의 컨텐츠 히스토리 테이블이 사용될 수 있다. 또한 이 경우, 컨텐츠 히스토리 테이블로서 도시된 사용 리포팅 데이터의 일부가 그대로 사용될 수도 있다.
도시된 사용 리포팅 데이터는 본 발명의 일 실시예이며, 필드들은 다르게 구성될 수도 있다.
UsageReporting 은 사용 리포팅 데이터의 루트 엘레먼트일 수 있다. @protocolVersion 은 사용 리포팅 프로토콜의 버전을 나타낼 수 있다. @location 은 디바이스의 위치정보, 예를 들어 GPS 정보를 포함할 수 있다.
Service 엘레멘트는 사용 리포팅할 대상 서비스에 대한 정보를 포함할 수 있다. @serviceId 는 서비스의 ID 정보, @channelNum 은 채널 넘버 정보, @broadcastId 는 브로드캐스터의 ID 정보, @genre 는 서비스의 장르 정보, @rating 은 서비스의 레이팅 정보, @serviceType 은 서비스의 타입 정보를 포함할 수 있다.
LinearService 엘레멘트는 해당 서비스가 리니어 서비스일 경우에, 그에 관한 정보를 포함할 수 있다. @startTime 은 리니어 서비스 사용 인터벌의 시작시간을 의미할 수 있다. @endTime 은 리니어 서비스 사용 인터벌의 종료시간을 의미할 수 있다. @usageType 은 어떠한 방식으로 해당 리니어 서비스를 사용했는지에 관한 정보를 포함할 수 있다(e.g. 풀 스크린, PIP 등). @timeShift 는 타임 쉬프트되었는지 여부를 지시할 수 있다.
Component 엘레멘트는 해당 리니어 서비스의 컴포넌트 관련 정보를 포함할 수 있다. Component 엘레멘트는 VideoComponent, AuioComponent, CCComponent 엘레멘트 등을 포함할 수 있다.
VideoComponent 엘레멘트는 해당 리니어 서비스의 비디오 컴포넌트 관련 정보를 포함할 수 있다. @componentId 는 해당 비디오 컴포넌트의 ID 정보, @role 은 해당 비디오 컴포넌트의 롤 정보, @targetDevice 는 해당 비디오 컴포넌트가 타겟팅하는 디바이스 정보를 포함할 수 있다. @startTime, @endTime 은 해당 비디오 컴포넌트를 사용한 시작시점, 종료시점에 대한 정보를 포함할 수 있다.
AudioComponent 엘레멘트는 해당 리니어 서비스의 오디오 컴포넌트 관련 정보를 포함할 수 있다. VideoComponent 엘레멘트 내부의 필드들과 동명의 필드들은 해당 리니어 서비스의 오디오 컴포넌트에 대하여 유사한 정보를 포함할 수 있다. @language 는 해당 오디오 컴포넌트의 언어 정보를 포함할 수 있다. @mode 필드는 해당 오디오 컴포넌트의 모드 정보를 포함할 수 있다.
CCComponent 엘레멘트는 해당 리니어 서비스의 클로즈드 캡션 컴포넌트 관련 정보를 포함할 수 있다. VideoComponent 엘레멘트 내부의 필드들과 동명의 필드들은 해당 리니어 서비스의 클로즈드 캡션 컴포넌트에 대하여 유사한 정보를 포함할 수 있다. @language 는 해당 클로즈드 캡션의 언어 정보를 포함할 수 있다. @type 필드는 해당 클로즈드 캡션의 타입 정보를 포함할 수 있다.
AppBasedEnhancement 엘레멘트는 해당 리니어 서비스의 앱 기반 부가서비스에 대한 사용 정보를 포함할 수 있다. @targetDevice 는 해당 앱기반 부가서비스의 타겟 디바이스 정보를 포함할 수 있다. @startTime 과 @endTime 은 해당 앱 기반 부가서비스의 사용 시작시점, 종료시점에 관한 정보를 포함할 수 있다.
AppBasedEnhancement 엘레멘트는 App 엘레멘트, OnDemandComponent 엘레멘트, NRTContentItem 엘레멘트를 포함할 수 있는데, 각각 어플리케이션, 온 디맨드 컴포넌트, NRT 컨텐트 아이템에 관한 사용 정보를 포함할 수 있다. 각각의 App 엘레멘트, OnDemandComponent 엘레멘트, NRTContentItem 엘레멘트는 해당 어플리케이션, 온 디맨드 컴포넌트, NRT 컨텐트 아이템을 식별하는 ID 정보 필드와, 사용 시작시점, 종료시점에 관한 정보 필드를 포함할 수 있다.
Service 엘레멘트는 LinearService 엘레멘트 외에, AppBasedService 엘레멘트를 포함할 수 있다. AppBasedService 엘레멘트는 앱 기반 서비스에 대한 사용 정보를 포함할 수 있다.
AppBasedService 엘레멘트의 @appBasedServiceId 는 해당 앱 기반 서비스의 ID 정보를 포함할 수 있다. @startTime 과 @endTime 은 해당 앱 기반 서비스의 사용 시작시점, 종료시점에 관한 정보를 포함할 수 있다.
AppBasedService 엘레멘트는 LinearService 엘레멘트와 마찬가지로 AppBasedEnhancement 엘레멘트를 포함할 수 있다. AppBasedEnhancement 엘레멘트는 전술한 것과 같은 포맷을 가질 수 있다.
도 189 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 테이블 및 필터링 크리테리아를 이용한 개인화된 서비스를 제공하는 시퀀스 다이어그램을 도시한 도면이다.
전술한 바와 같이, 시청 히스토리에 따라 컨텐츠 히스토리 테이블이 생성될 수 있고, 이를 기반으로 필터링 크리테리아와 비교하여 서비스/컨텐츠가 선별될 수 있다.
먼저, SSC 혹은 FIC 등의 채널을 통하여 방송될 서비스/컨텐츠에 대한 시그널링 정보들이 수신될 수 있다(t177010, t177020). 시그널링 파서는 수신한 시그널링 정보를 파싱하고, 파싱된 정보를 컨텐츠 히스토리 엔진으로 전달할 수 있다(t177030).
컨텐츠 히스토리 엔진은 전달받은 시그널링 정보들을 참조하여, 컨텐츠 히스토리 테이블을 생성할 수 있다(t177040). 이 컨텐츠 히스토리 테이블은 컨텐츠 히스토리 스토어에 저장될 수 있다.
수신기는 SSC 혹은 FIC 를 통해 전달되는 필터링 크리테리아를 수신할 수 있다(t177050). 이 때 필터링 크리테리아는 전술한 필터링 크리테리아 디스크립터의 형태일 수 있다. 컨텐츠 히스토리 테이블을 위한 필터링 크리테리아는 기존의 필터링 크리테리아와 마찬가지로 SMT 또는 NRT-IT 서비스 레벨의 디스크립터 루프에 존재할 수 있다. SMT 또는 NRT-IT 로 전달되는 경우 NRT 서비스나 컨텐트 아이템을 선별하는 용도로 쓰일 수 있으므로, 특정 서비스를 필터링하기 위하여 SSC 혹은 FIC 를 통해 필터링 크리테리아가 전달될 수 있다.
시그널링 파서는 필터링 크리테리아 디스크립터를 파싱하여, 그 기준정보들을 필터링 엔진으로 전달할 수 있다(t177060). 필터링 엔진은 전달받은 기준 정보들을 이용하여, 컨텐츠 히스토리 엔진에 관련된 컨텐츠 히스토리 테이블을 요청할 수 있다(t177070).
컨텐츠 히스토리 엔진은 관련된 컨텐츠 히스토리 테이블을 서치한 후(t177080), 컨텐츠 히스토리 테이블을 필터링 엔진으로 전달할 수 있따(t177090). 필터링 엔진은 전달받은 컨텐츠 히스토리 테이블과 기준 정보들을 비교할 수 있다(t177100). 이 비교과정을 통해 해당 서비스/컨텐츠가 해당 수신기에 적합한지 여부가 판단될 수 있다.
해당 수신기에 적합한 서비스/컨텐츠일 경우, 그 서비스/컨텐츠를 다운로드하거나 디스플레이할 수 있다.
도 190 은 카운트 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
수신기가 필터링 크리테리아를 수신한 후, 그 기준 정보들과 컨텐츠 히스토리 테이블 내의 히스토리 정보들을 비교하는 방안을 설명한다.
비교과정은 특정 히스토리 정보가, 그와 연관되는 기준정보들 내의 기준값에 충족되는지 여부를 판단하는 것으로 수행될 수 있다. 이 때, 각 기준정보에 충족되는 히스토리 정보들에 대하여 AND 로직을 적용하여 해당 서비스/컨텐츠가 해당 수신기에 적합한지 여부를 판단할 수 있다. 즉, 이 경우 모든 기준 정보에 대하여 히스토리 정보가 충족되어야, 적합한 서비스/컨텐츠라고 판단될 수 있다.
또한 실시예에 따라 각 기준정보에 충족되는 히스토리 정보들에 대하여 OR 로직을 적용하여 해당 서비스/컨텐츠가 해당 수신기에 적합한지 여부를 판단할 수 있다. 즉, 이 경우 어느 하나의 기준 정보에 대하여 히스토리 정보가 충족되면, 적합한 서비스/컨텐츠라고 판단될 수 있다.
또한 실시예에 따라 다른 카테고리(Who, When 등)에 속하는 기준 정보에 대해서는 AND 로직을 적용하고, 같은 카테고리에 속하는 기준 정보에 대해서는 OR 로직을 적용하여, 해당 서비스/컨텐츠가 해당 수신기에 적합한지 여부를 판단할 수도 있다.
또한 실시예에 따라 기준 정보들에 대해 AND 로직 또는 OR 로직이 설계자의 의도에 따라 적용될 수도 있다.
특히, When 타입의 기준정보에 대하여 비교방안을 설명한다.
When 타입의 기준정보를 구성하는 @startTime, @endTime 같은 정보는 기본적으로 시청 시작시점, 시청 종료시점을 의미한다. 따라서, When 타입의 기준 정보는 @startTime 과 @endTime 사이의 시간 동안에 시청했었는지 여부를 의미할 수 있다. 그러나 실시예에 따라 @startTime 은, @statTime 이 지시하는 시점부터 현재시간까지 시청했었는지 여부, @endTime 은 과거부터 @endTime 이 지시하는 시점까지 시청했었는지 여부를 의미하도록 설정될 수도 있다.
예를 들어, @startTime == 20140101, @endTime == 20140501, @channelNum == 7-1, @programId == EP00001E001, @resolution == UHD 인 필터링 크리테리아가 수신될 수 있다. 이는 "2014년 1월 1일부터 2014년 5월 1일까지, 7-1 채널을 보았거나 EP00001E001 프로그램을 본 경우로서, UHD 화질로 시청한 경우" 를 의미할 수 있다. 이 경우 "When 기준정보 AND What 기준정보 AND How 기준정보" 의 형태로 AND 로직이 적용되었고, What 기준 정보 내에서는 "7-1 채널 OR EP00001E001 프로그램" 로서 OR 로직이 적용되었다.
이 예시와 같은 조건에 부합하는 컨텐츠 히스토리 테이블이 있는지 서칭이 수행된 후, 그러한 컨텐츠 히스토리 테이블 내지 컨텐츠 히스토리 정보가 있다면, 해당 서비스/컨텐츠가 다운로드되거나 사용자에게 노출될 수 있다. 만약 이에 부합되는 컨텐츠 히스토리 테이블이 하나도 없다면 해당 서비스/컨텐츠는 다운로드되지 않고, 사용자에게 노출되지 않을 수 있다.
도시된 필터링 크리테리아는 전술한 필터링 크리테리아가 확장된 형태로서, 카운트 정보를 더 포함할 수 있다.
@count 성질은 전술한 카운트 정보에 해당하는 성질(attribute)로서, 기준정보에 매칭되는 컨텐츠 히스토리 테이블(또는 컨텐츠 히스토리 정보, 컨텐츠 히스토리 테이블 내의 QWhoType 등의 히스토리 정보 엘레멘트)의 개수 정보를 포함할 수 있다. 즉, 해당 필터링 크리테리아가 포함하는 기준 정보들에 충족되는 컨텐츠 히스토리 테이블의 개수(A) 가, @count 가 지시하는 개수(B) 이상인 경우에만 해당 필터링 크리테리아가 만족된 것으로 판단될 수 있다. 즉, A가 B 보다 큰 경우에만 해당 서비스/컨텐츠가 다운로드될 수 있다.
이와 같은 카운트 정보가 포함되지 않을 경우, 사용자가 우연히 해당 필터링 크리테리아를 만족하는 시청 히스토리를 남긴 경우에도 해당 컨텐츠 히스토리 테이블이 생성되므로, 정확한 서비스 개인화에 방해가 될 수 있다. 즉, 컨텐츠 히스토리 테이블이 하나 정도만 존재하는 경우는 필터링 크리테리아가 만족되지 않는 것으로 판단되게 설정하여, 효율적인 개인화를 이룰 수 있다.
도 191 는 문턱값 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
전술한 비교 정책들은, 필터링 크리테리아의 모든 기준 정보들을 만족하는 컨텐츠 히스토리 테이블이 있는 경우에만 서비스/컨텐츠가 제공된다. 따라서 모든 기준 정보를 만족하는 컨텐츠 히스토리 테이블이 적은 경우 효율이 떨어질 수 있다.
이를 해결하기 위해, 기준 정보들 중 하나라도 만족하는 컨텐츠 히스토리 테이블이 있을 경우 서비스/컨텐츠를 제공하는 비교 정책이 제안될 수 있다. 그러나 이 경우에는 필터링 크리테리아를 충족시키는 컨텐츠 히스토리 테이블이 너무 많아져서 오히려 효율성이 떨어질 수 있다.
따라서, 각 기준 정보에 대하여 가중치를 두어, 각 기준정보의 기준값과 가중치를 곱한 값들의 합(A)을 기준으로 비교를 수행하는 비교 정책이 제안될 수 있다. 이를 위해 필터링 크리테리아는 문턱값(B)를 더 포함할 수 있다. A 값이 B 보다 큰 경우에 해당 필터링 크리테리아가 충족된 것으로 판단되어 해당 서비스/컨텐츠가 제공될 수 있다. 실시예에 따라 각 기준정보의 기준값과 가중치를 곱한 값들의 합이 A 값이 아니라, 만족되는 기준정보의 가중치를 단순히 합한 값이 A 값이 될 수도 있다.
@threshold 성질은 전술한 문턱값에 해당하는 성질(attribute)일 수 있다.
@weight 은 각 기준정보에 포함되는 성질로서, 각 기준정보의 가중치 값을 포함할 수 있다. 가중치는 설계자의 의도에 따라 자유롭게 설정될 수 있다. 여기서 다른 카테고리와는 달리 When 타입의 경우, @weight 이 각 기준정보가 아닌 QWhenCriterion 에 포함되는 성질로서 정의될 수 있다. StartTimeCriterionValue, EndTimeCriterionValue 가 특정 시점을 의미할 수 있기 때문이다. 실시예에 따라 다른 카테고리에 대해서도 @weight 이 각 기준정보가 아닌 QxCriterion 에 포함되는 성질로서 정의될 수 있다.
도 192 은 문턱값 정보를 포함하는 필터링 크리테리아에 있어서, 본 발명의 일 실시예에 따른 비교 과정을 도시한 도면이다.
필터링 크리테리아(t180010)와, 컨텐츠 히스토리 스토어(t180020) 의 일 실시예가 도시되어 있다.
수신된 필터링 크리테리아의 각 기준정보에 부합하는 컨텐츠 히스토리 테이블을 컨텐츠 히스토리 스토어에서 검색하고 매칭하여 비교과정이 수행될 수 있다. 하나의 컨텐츠 히스토리 테이블이라도 기준 정보들과 매칭되는 경우, 부합되는 기준정보에 대해서만 가중치를 곱하여 합산한 결과를 계산할 수 있다.
본 실시예에서, 만족되는 기준정보의 가중치를 단순히 합한 값을 문턱값과 비교하는 대상으로 가정한다.
CHT1 의 경우, 필터링 크리테리아의 기준정보들과 매칭되는 것을 @StartTime과 @EndTime을 통한 시청기간, @channelNum 이다. 만족되는 기준정보들의 가중치를 더하면 1.6 + 1.4 = 3 으로 문턱값 4.5 보다 낮다. 따라서, CHT1 은 매칭되는 컨텐츠 히스토리 테이블로 판단되지 않는다.
CHT2의 경우, @resolution을 제외한 모든 기준 정보들이 매칭된다. 따라서 만족되는 기준정보들의 가중치를 더하면 1.6 + 1.4 + 1.8 = 4.8 이로 문턱값보다 크다. 따라서, CHT2 는 매칭되는 컨텐츠 히스토리 테이블로 판단된다.
CHT3의 경우는 하나도 부합하는 기준정보가 없으므로, 매칭에서 배제될 수 있다.
비교 과정 결과, 필터링 크리테리아에 만족하는 컨텐츠 히스토리 테이블은 총 1개이다. 이는 @count 가 지시하는 2 보다 작은 값이다. 따라서 최종적으로 제공하려고 했던 서비스/컨텐츠는 필터링되어 사용자에게 제공되지 않을 수 있다.
도 193 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 PDI 유저 데이터를 통해 전달되는 경우의 시퀀스 다이어그램을 도시한 도면이다.
PDI 유저 데이터의 PDI 질문을 무조건적으로 사용자에게 노출시켜 답변을 받게 할 수 있다. 그러나 이 경우 PDI 질문이 해당 사용자가 전혀 관심없는 내용에 관한 것일 경우 시청환경을 개선하는 데에 있어 크게 도움이 되지 못할 수 있다. 예를 들어 야구 경기를 좋아하지 않는 사용자에게 "좋아하는 야구 팀은 어느 곳입니까?" 란 질문을 보여주는 것은 무의미한 PDI 유저 데이터 수집으로 시스템의 로드만 늘리는 동작일 수 있다.
이를 개선하기 위하여, 본 발명은 컨텐츠 히스토리 정보, 즉 사용자의 시청 정보를 바탕으로 하여 PDI 질문을 노출시키는 방안을 제안한다. 저장된 컨텐츠 히스토리 정보를 이용하여, 일정 조건을 만족하는 경우에만 해당 PDI 질문을 사용자에게 노출시켜 PDI 데이터를 수집/저장할 수 있다. 또한 전술한 문턱값 관련 특징을 추가하여, 일정 조건을 만족하는 컨텐츠 히스토리 정보의 개수가 문턱값을 넘을 경우, 해당 PDI 질문을 사용자에게 노출시킬 수도 있다. 여기서 컨텐츠 히스토리 정보는 전술한 컨텐츠 히스토리 테이블(CHT) 내지 컨텐츠 히스토리 테이블 내의 정보를 의미할 수 있다.
후술할 다양한 실시예에 따라 변형될 수 있지만, 기본적인 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집은, PDI 질문 수신, 컨텐츠 히스토리 정보 검색/비교 및/또는 질문의 노출/비노출의 순서로 수행될 수 있다. 먼저, PDI 질문을 가지는 PDI 유저 데이터가 수신될 수 있다. 해당 PDI 질문에 대한 특정 기준정보와 컨텐츠 히스토리 정보의 비교를 통해, 해당 PDI 질문의 노출여부가 결정될 수 있다. 여기서 특정 기준정보는, 예를 들어, "일주일동안 프로야구 경기를 4번(threshold) 이상 시청한 경우" 등의 조건을 나타낼 수 있다.
특정 기준정보의 조건에 맞는 컨텐츠 히스토리 정보가 없는 경우, 즉 시청 히스토리에 근거할 때 해당 PDI 질문의 노출이 무의미하다고 판단되는 경우에는 해당 질문이 사용자에 노출되지 않을 수 있다. 만약 특정 기준정보의 조건에 맞는 컨텐츠 히스토리 정보가 잇는 경우, 해당 PDI 질문은 사용자에게 노출되고 PDI 답변이 기입되어 PDI 유저 데이터에 저장될 수 있다.
컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, PDI 질문의 노출을 판단하는 기준정보는 PDI 유저데이터 내지 PDI 질문에 포함되어 전달될 수 있다. 실시예에 따라 기준정보는 필터링 크리테리아에 포함되어 전달될 수도 있다.
PDI 질문 노출의 기준정보가 PDI 유저데이터에 포함되어 전달되는 경우를 설명한다.
먼저 PDI 유저 데이터(=PDI 테이블, PDI Q&A)가 수신될 수 있다(t193010). 브로드캐스터 또는 서비스 프로바이더는 수신기로 PDI 유저 데이터에 질문 노출 기준정보를 포함하여 전달할 수 있다. PDI 유저 데이터는 주기적 또는 비주기적으로 반복해서 수신될 수도 있다.
수신기는 수신된 PDI 유저데이터에서 질문 노출 기준정보가 존재하는지 여부부터 확인할 수 있다(t193020). 여기서 질문 노출 기준정보는 ShowingCriterion 엘레멘트에 의해 표현될 수 있다. 이 엘레멘트 및 PDI 유저 데이터 내의 질문 노출 기준정보의 구조는 후술한다.
만약, 수신된 PDI 유저 데이터에 질문 노출 기준정보가 없는 경우, 해당 PDI 유저 데이터를 노출시키지 않고 저장만 해둘 수 있다(t193030). 이 후, 수신기는 동일한 PDI 유저 데이터 내지 동일한 PDI 질문을 가지는 PDI 유저 데이터가 재수신될 때까지, 해당 PDI 유저 데이터에 대한 동작을 중지할 수 있다(t193040). 추후 동일한 PDI 유저 데이터가 재수신되었을 때, 다시 도시된 로직에 따라 비교작업이 수행되어 노출/비노출될 수 있다. 재수신된 PDI 유저 데이터가 기 저장된 경우라면 재수신된 PDI 유저 데이터는 중복 저장하지 않고 삭제할 수 있다.
수신된 PDI 유저 데이터에 질문 노출 기준정보가 있는 경우, 이를 기 저장된 컨텐츠 히스토리 정보와 비교할 수 있다(t193050). 해당 질문 노출 기준정보의 조건들에 모두 만족되는 컨텐츠 히스토리 정보가 존재한다면, 또는 조건들에 모두 만족되는 컨텐츠 히스토리 정보의 개수가 문턱값(threshold) 이상이라면, 해당 PDI 질문을 사용자에 노출시킬 수 있다(t193060). 사용자는 해당 PDI 질문에 대해 답변을 기입하고, 수신기는 그 답변을 PDI 유저 데이터에 저장하여 PDI 스토어 등에 보관할 수 있다(t193070).
해당 질문 노출 기준정보의 조건들에 모두 만족되는 컨텐츠 히스토리 정보가 존재하지 않거나, 문턱값보다 적은 수의 컨텐츠 히스토리 정보만이 존재하는 경우, 수신기는 이를 노출시키지 않고 저장만 해둘 수 있다(t193030). 마찬가지로 PDI 유저 데이터가 재수신될 때까지, 해당 PDI 유저 데이터에 대한 동작이 중지될 수 있다(t193040).
도 194 는 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 PDI 유저 데이터를 통해 전달되는 경우의 PDI 유저 데이터의 구조를 도시한 도면이다.
전술한 PDI 질문의 노출여부를 결정하는 기준정보는, 전술한 실시예들에 따른 PDI 유저 데이터에 하나의 엘레멘트로 포함될 수 있다. 이 엘레멘트는 전술한 ShowingCriterion 엘레멘트일 수 있다.
PDI 유저 데이터 내의 기준정보의 형태는, 컨텐츠 히스토리 정보를 저장하는 형태에 따라 달라질 수 있다. 전술한 바와 같이, 컨텐츠 히스토리 정보 내지 컨텐츠 히스토리 테이블은 5W1H 방법에 따라 내부 정보가 구성되거나, 5W1H 에 따른 타입 구분은 두되 세부 항목은 @id 및 @value 값을 두어 구분되도록 구성되거나, 단순히 @id 및 @value 값들만으로 구분되도록 구성될 수 있다. 이에 대응되도록, 질문 노출 기준정보 역시 5W1H 에 따른 구분되도록 구성되거나, 5W1H 에 따르되 ID 를 이용해 세부항목이 구분되도록 구성되거나, 타입별 구분없이 ID 만을 이용해 구분되도록 구성되도록 할 수 있다. 예를 들어 컨텐츠 히스토리 정보가 저장될 때 각 필드별 ID 가 지정되지 않는 경우, ID 대신 각 필드들의 이름이 직접 지정될 수도 있다.
도시된 질문 노출 기준정보는 타입별 구분없이 ID 만을 이용해 구분된 컨텐츠 히스토리 정보에 대응되도록 구성된 실시예이다. 이는 일 실시예이며 본 발명은 이 구성에 국한되지 아니한다. 또한 ShowingCriterion 엘레멘트를 제외한 PDI 유저 데이터의 나머지 부분들은 전술한 PDI 유저 데이터의 다양한 실시예들과 조합될 수 있다.
PDI 유저 데이터는 ShowingCriterion 엘레멘트를 포함할 수 있다. 이 엘레멘트는 해당 PDI 유저 데이터의 PDI 질문들을 사용자에게 노출시킬지 여부를 결정하는 질문 노출 기준정보들을 포함할 수 있다. 이 엘레멘트는 @threshold 성질(attribute) 및/또는 적어도 하나 이상의 ContentHistoryCriterion 엘레멘트를 포함할 수 있다.
ContentHistoryCriterion 엘레멘트는 컨텐츠 히스토리 정보와 비교하기 위한 세부 기준정보(criterion)일 수 있다. 이 엘레멘트는 저장된 컨텐츠 히스토리 정보를 구성하는 각 필드들 중 비교를 위해 사용될 필드들을 나타내는 엘레멘트일 수 있다. 이 엘레멘트들은 각각 @id, @value 를 포함할 수 있다.
@id 는 컨텐츠 히스토리 정보 중 비교를 위해 사용될 필드의 유니크한 ID 를 나타낼 수 있다. 참고로 컨텐츠 히스토리 정보가 저장될 때 각각의 필드들은 유니크한 ID 를 가질 수 있어야 한다. 예를 들어 ChannelNumber 필드는 atsc.org/CHT/ChannelNumber 와 같은 형태의 유니크 ID 를 가질 수 있다.
@value 는 @id 로 식별되는 필드의 값, 즉 컨텐츠 히스토리 정보 중 비교를 위해 사용될 필드의 값을 나타낼 수 있다. 이 값을 이용해 컨텐츠 히스토리 정보와 비교가 수행될 수 있다.
@threshold 는 매칭여부를 판단하기 위해 사용될, 기준정보를 모두 만족하는 컨텐츠 히스토리 정보의 문턱값을 나타낼 수 있다. ContentHistoryCriterion 엘레멘트들이 나타내는 세부 기준정보들에 모두 만족하는 시청 히스토리 정보(CHT)의 개수가, @threshold 가 나타내는 문턱값 이상일 경우 해당 PDI 유저 데이터와 컨텐츠 히스토리 정보가 매칭된다고 판단될 수 있다. 매칭되었다고 판단되면 해당 PDI 유저 데이터의 PDI 질문들이 사용자에게 노출될 수 있다. 본 필드는 존재하지 않을 수도 있는데, 본 필드가 존재하지 않는 경우 모든 세부 기준정보들을 만족하는 시청 히스토리 정보가 존재하는지 여부로 매칭이 판단될 수 있다.
도 195 는 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 PDI 유저 데이터를 통해 전달되는 경우의 컨텐츠 히스토리 정보 및 PDI 유저 데이터의 예시를 도시한 도면이다.
먼저, 도시된 컨텐츠 히스토리 정보(t195010)는, 시청자가 102-1 번 채널의 "Major League Baseball" 이라는 프로그램을 시청한 정보를 나타내고 있다. 여기서, "atsc.org/cht/channelNumber" 의 ID 로 식별되는 필드의 값이 "102-1" 이므로, 시청된 채널 번호는 102-1 번 채널임을 알 수 있다. "atsc.org/cht/programName" 의 ID 로 식별되는 필드의 값이 "Major League Baseball" 이므로, 시청된 프로그램 이름은 Major League Baseball 임을 알 수 있다. "atsc.org/cht/resolution" 의 ID 로 식별되는 필드의 값이 "UHD" 이므로, UHD 화질로 시청되었음을 알 수 있다. "atsc.org/cht/startTime", "atsc.org/cht/endTime" 의 ID 로 식별되는 필드의 값이 "2014-07-15T10:30:30", "2014-07-15T12:30:30" 이므로, 2014년 7월15일, 10:30:30 부터 12:30:30 까지 시청되었음을 알 수 있다. 이러한 컨텐츠 히스토리 정보는 미리 수신기 등에 저장되어 있어야 하며, 저장되는 컨텐츠 히스토리 정보의 형식은 실시예에 따라 변경될 수 있다.
다음으로 도시된 질문 노출 기준정보를 포함한 PDI 유저 데이터(t195020)은, "What is your favorite baseball team" 이라는 PDI 질문을 포함할 수 있다. 이 PDI 유저 데이터에 대한 질문 노출의 세부 기준정보로는, 프로그램 이름, 시청시작시각 및 시청종료시각이 제시되어 있다. 여기서, "atsc.org/cht/ programName" 의 ID 로 식별되는 세부 기준정보가 "Major League Baseball" 이고, "atsc.org/cht/startTime", "atsc.org/cht/endTime" 의 ID 로 식별되는 필드의 값이 "2014-07-08T22:00:00", "2014-07-15T22:00:00" 이다. @threshold 의 값은 4 이다. 이는 "2014년 7월8일 22시부터, 2014년 7월 15일 22시까지 Major League Baseball 이라는 프로그램을 4번 이상 시청한 경우" 로 해석될 수 있다.
도시된 컨텐츠 히스토리 정보(t195010)은, 도시된 질문 노출 기준정보의 모든 조건에 부합된다. 따라서 이와 같은 컨텐츠 히스토리 정보가 3개 이상 더 탐색되는 경우, 해당 PDI 유저 데이터는 컨텐츠 히스토리 정보에 부합하게 되는 걸로 판단될 수 있다. 모든 조건에 부합되는 총 컨텐츠 히스토리 정보가 4 개 이상이 되면 해당 PDI 질문을 노출시킬 수 있다.
도 196 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 필터링 크리테리아를 통해 전달되는 경우의 시퀀스 다이어그램을 도시한 도면이다.
PDI 질문의 노출 여부를 결정하는 질문 노출 기준정보는, PDI 유저 데이터가 아닌 다른 시그널링 정보에 포함되어 전송될 수도 있다. 질문 노출 기준정보는 SMT 또는 EIT 등의 시그널링 정보에 포함되어 전달될 수 있으며, 어떠한 시그널링 정보에 삽입될지는 실시예에 따라 변경될 수 있다.
일 실시예로 질문 노출 기준정보는 필터링 크리테리아에 포함되어 수신기로 전달될 수 있다. 먼저 질문 노출 여부를 판별하기 위한 타입의 필터링 크리테리아가 수신기에 수신될 수 있다(t196010). 수신기는 필터링 크리테리아 내의 질문 노출 기준정보를 저장된 컨텐츠 히스토리 정보와 비교할 수 있다(t196020). 이 비교과정은 전술한 바와 같을 수 있다. 필터링 크리테리아 내의 질문 노출 기준정보가 컨텐츠 히스토리 정보와 매칭되지 않는 경우, 해당 필터링 크리테리아는 무시될 수 있다(t196030).
컨텐츠 히스토리 정보와 매칭되는 경우, 수신기는 필터링 크리테리아가 PDI 질문의 노출여부를 판별하기 위함인가를 판단할 수 있다(t196040). 이는 후술할 @filteringCriteriaType 필드에 의해 지시될 수 있다. PDI 질문 노출여부를 위한 필터링 크리테리아가 아니라고 판별된 경우, 해당 필터링 크리테리아는 일반적인 경우의 필터링 크리테리아일 수 있다. 이 경우, 수신기는 일반적인 필터링 크리테리아를 이용한 프로세스를 수행할 수 있다(t196050). 여기서 일반적인 필터링 프로세스란, 전술된 바와 같이, 기 저장된 PDI 유저 데이터와 수신된 필터링 크리테리아를 비교하여 해당 서비스/컨텐츠를 수신할지 여부를 결정하는 과정을 의미할 수 있다. 여기서, 필터링 크리테리아는 이미 컨텐츠 히스토리 정보와 비교되었으므로 시청자의 시청 히스토리에 기반한 필터링은 이미 수행된 경우라고 볼 수 있다.
해당 필터링 크리테리아가 PDI 질문 노출여부를 위한 필터링 크리테리아라고 판별된 경우, 수신기는 타겟 질문 지시자에 의해 지시되는 PDI 유저 데이터의 PDI 질문을 사용자에 노출시킬 수 있다(t196060). 여기서 타겟 질문 지시자는 질문 노출 기준정보와 함께 필터링 크리테리아에 포함된 필드로서, 후술할 @targetQuestionTableId 에 해당할 수 있다. 사용자는 노출된 질문에 답변하고, 수신기는 해당 답변을 PDI 유저 데이터에 저장하고 PDI 스토어에 보관시킬 수 있다(t196070).
도 197 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 필터링 크리테리아를 통해 전달되는 경우의 필터링 크리테리아의 구조를 도시한 도면이다.
전술한 PDI 질문의 노출여부를 결정하는 기준정보는, 전술한 실시예들에 따른 필터링 크리테리아에 포함되어 수신될 수 있다. 여기서, 기존의 필터링 크리테리아를 확장함으로써, 일반적인 필터링 크리테리아를 PDI 질문의 노출 기준정보를 포함하는 필터링 크리테리아로 동작하게 할 수 있다.
도시된 필터링 크리테리아(t197010)는 전술한 일반적인 필터링 크리테리아의 구조 중 하나이다. 이 필터링 크리테리아는 컨텐츠 히스토리 정보에 기반한 서비스/컨텐츠 필터링을 위한 필터링 크리테리아일 수 있다. 이 구조에 대해서는 전술한 바와 같다.
이 일반적인 필터링 크리테리아(t197010)를 확장한 형태의 필터링 크리테리아(t197020) 또한 도시되었다. 확장된 필터링 크리테리아는 타입정보, 타겟 질문 지시자 및/또는 문턱값 정보를 더 포함할 수 있다. 또한 기존에 서비스/컨텐츠 필터링을 위한 기준정보들(FilterCriterion 엘레멘트)은, 추가된 필드들의 값에 따라, PDI 질문의 노출여부 판단을 위한 기준정보들로서 활용될 수 있다.
확장된 필터링 크리테리아는 @filteringCriteriaType 필드를 더 포함할 수 있다. 이 필드는 해당 필터링 크리테리아의 타입을 지시할 수 있다. 이 필드는 해당 필터링 크리테리아가 서비스/컨텐츠 또는 어플리케이션을 필터링하기 위한 것인지, PDI 질문의 노출여부를 결정하기 위한 것인지를 결정할 수 있다. 예를 들어 이 필드가 0 의 값을 가지면 서비스/컨텐츠 필터링을 위함이고, 1 의 값을 가지면 PDI 질문 노출여부를 필터링하기 위함일 수 있다. 본 필드는 옵셔널(optional) 필드이며 정수(int) 데이터 타입을 가질 수 있다.
필터링 크리테리아가 PDI 질문의 노출여부를 결정하기 위한 것일 경우, 필터링 크리테리아의 FilterCriterion 엘레멘트들은 전술한 질문 노출 기준정보로서 기능할 수 있다. 해당 엘레멘트들의 @id 식별되는 컨텐츠 히스토리 정보의 필드들이, @CriterionType 이 지시하는 타입이고, 해당 값이 CriterionValue 에 일치되는 경우, 해당 세부 노출 기준정보의 기준에 부합된다고 볼 수 있다. 모든 FilterCriterion 엘레멘트들의 조건에 부합되는 컨텐츠 히스토리 정보가 존재하는지, 또는 모든 조건에 부합되는 컨텐츠 히스토리 정보의 개수가 문턱값보다 큰 지 여부로 매칭여부가 판단될 수 있다.
확장된 필터링 크리테리아는 @targetQuestionTableId 필드를 더 포함할 수 있다. 이 필드는 해당 필터링 크리테리아의 질문 노출 기준정보가 컨텐츠 히스토리 정보에 매칭되는 경우, 노출되어야할 PDI 질문을 지시할 수 있다. 이 필드는 전술한 타겟 질문 지시자에 해당할 수 있다. 이 필드는 해당 필터링 크리테리아가 PDI 질문의 노출여부를 결정하기 위한 타입일 경우에 사용될 수 있다. 이 필드는 옵셔널 필드로 특정 URI 데이터 타입을 가질 수 있다.
확장된 필터링 크리테리아는 @threshold 필드를 더 포함할 수 있다. 이 필드는 매칭여부 판단을 위한 문턱값을 나타낼 수 있다. 이 필드는 옵셔널 필드로 정수(int) 데이터 타입을 가질 수 있다.
PDI 유저 데이터와 마찬가지로, 필터링 크리테리아 내부의 질문 노출 기준정보의 형태 역시, 컨텐츠 히스토리 정보를 저장하는 형태에 따라 달라질 수 있다. 각각의 컨텐츠 히스토리 정보 형태에 따른 필터링 크리테리아는 이미 설명되었다. 도시된 필터링 크리테리아들은 타입별 구분 없이 ID 만을 이용해 내부 기준정보를 구성한 형태에 해당할 수 있다. 전술된 다른 형태의 필터링 크리테리아들도 PDI 질문의 노출여부 결정을 위해 확장될 수 있다. 도시된 형태는 일 실시예이며, 이 구성에 국한되지 아니한다.
도 198 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 정보에 근거한 PDI 유저 데이터 수집에 있어서, 그 기준정보가 필터링 크리테리아를 통해 전달되는 경우의 필터링 크리테리아의 예시를 도시한 도면이다.
먼저 도시된 필터링 크리테리아(t198010)는 filteringCriteriaType 값이 1 로, PDI 질문의 노출 여부를 필터링하기 위한 필터링 크리테리아일 수 있다. 도시된 필터링 크리테리아의 세부 노출 기준정보로는, 프로그램 이름, 시청시작시각 및 시청종료시각이 제시되어 있다. 여기서, "atsc.org/cht/ programName" 의 ID 로 식별되는 세부 기준정보가 "Major League Baseball" 이고, "atsc.org/cht/startTime", "atsc.org/cht/endTime" 의 ID 로 식별되는 필드의 값이 "2014-07-08T22:00:00", "2014-07-15T22:00:00" 이다. @threshold 의 값은 4 이다. 이는 "2014년 7월8일 22시부터, 2014년 7월 15일 22시까지 Major League Baseball 이라는 프로그램을 4번 이상 시청한 경우" 로 해석될 수 있다.
수신기, 또는 컨텐츠 히스토리 엔진은 해당 조건에 부합하는 컨텐츠 히스토리 정보가 컨텐츠 히스토리 스토어에 저장되어 있는지 탐색한다. 모든 조건에 부합하는 컨텐츠 히스토리 정보가 4 개이상 탐색된 경우, 도시된 질문 노출 기준정보는 컨텐츠 히스토리 정보에 매칭된다고 판단될 수 있다.
매칭된 경우, 필터링 크리테리아의 targetQuestionTableId 가 지시하는 PDI 질문을 사용자에게 노출시킬 수 있다. 이 경우 PDI 유저 데이터의 ID 는 "atsc.org/PDI/1" 이므로 해당 PDI 유저 데이터(t198020)의 PDI 질문이 노출될 수 있다. 즉, "What is your favorite baseball team" 이라는 질문이 사용자에 노출될 수 있다.
매칭된 경우에 해당 PDI 질문이 수신기에 저장되어 있지 않은 경우, 실시예에 따라 해당 PDI 질문을 노출시키지 않을 수 있다. 또는 실시예에 따라, 브로드밴드를 통하여 서버에 해당 PDI 질문을 요청해 수신한 후, 사용자에 노출시킬 수도 있다.
도 199 는 본 발명의 일 실시예에 따른, 휴리스틱 방법에 따라 컨텐츠 히스토리 정보를 단순화한 경우를 도시한 도면이다.
사용자의 시청 히스토리를 바탕으로 PDI 질문을 노출시키는 경우, 그 조건에 있어 구체적인 단계(level)이 필요할 수 있다. 예를 들어 "일주일 동안 프로야구 경기 중 New York 경기를 4번 이상 본 경우"와 같이 단계화된 조건이 필요할 수 있다. 이를 위해서는 시그널링할 때부터 관련 정보들이 카테고리화되어 있어야 한다(e.g. 팀, 종목). 그러나 방송 프로그램에 관한 모든 정보를 카테고리화하는 것은 무한히 많은 수의 형태가 가능할 수 있고, 이를 모두 정의하고 표준화하는 것은 현실적으로 어려울 수 있다. 이 문제를 처리하기 위하여 휴리스틱 방법, EIT 를 활용하는 방법, 웹 기반(Web based) 방법등이 활용될 수 있다.
먼저, 휴리스틱 방법은 태그(tag)를 이용하는 방법일 수 있다. 시그널링시 시그널링 테이블에 태그 필드가 추가되어 전송될 수 있다. 태그의 데이터 타입은 여러 형태로 정의될 수 있다. 예를 들어 태그의 데이터 타입이 스트링(string)인 경우, 태그 필드에는 "Baseball, New York, Boston, Yankees, Red Socks" 와 같은 일련의 정보가 포함될 수 있다. 브로드캐스터 내지 컨텐츠 프로바이더는 태그 필드에 원하는 모든 정보를 자유롭게 포함시킬 수 있다. 수신기는 시그널된 태그 필드를 파싱하고, 컨텐츠 히스토리 엔진은 컨텐츠 히스토리 정보를 저장할 때 해당 태그를 그대로 같이 저장할 수 있다. 이 질문 노출여부를 필터링하거나 서비스/컨텐츠를 필터링하는 경우에 있어 이 태그들이 사용될 수 있다. 태그 검색시 전체, 혹은 부분의 문자열 매칭을 통해 검색 및 매칭이 가능하므로, 다양한 단계(level)의 컨텐츠 히스토리 정보의 포맷이 필요하지 않을 수 있다. 또한 이 방법에 따른 컨텐츠 히스토리 저장에 있어서 단순 문자열 매칭이 가능하므로, 내츄럴 랭귀지 프로세싱(Natural Language Processing) 이나 텍스트 마이닝(text mining) 등의 기법도 필요하지 않을 수 있다.
전술한 문제점을 해결하기 위하여 EIT 가 활용될 수도 있다. EIT 를 통해 전달되는 정보들 중 Title 필드를 전술한 휴리스틱 방법에서의 태그 필드와 동일하게 사용할 수 있다. 즉, Title 필드의 값을 브로드캐스터나 컨텐츠 프로바이더가 원하는 대로 설정하여 전송하면, 수신기는 해당 값을 그대로 컨텐츠 히스토리 정보의 한 필드로 저장할 수 있다. 이 후 질문 노출 또는 서비스/컨텐츠 필터링시에 해당 필드를 검색, 비교하여 매칭절차를 밟을 수 있다.
또 다른 방안으로 웹 기반 방식이 있을 수 있다. 이는 PDI 질의 응답을 위한 어플리케이션을 수신기에 전달하고, 이 어플리케이션을 통해 PDI 질문, 답변이 이루어지는 형식이다. 이 어플리케이션은 어플리케이션 서버에 의해 관리될 수 있다. 먼저 이 어플리케이션에 대한 필터링 크리테리아를 수신기에 전달한다. 수신기는 컨텐츠 히스토리 정보와 필터링 크리테리아를 비교하고, 매칭되는 경우 해당 어플리케이션을 수신할 수 있다. 어플리케이션은 사용자에게 노출되며, 이 어플리케이션을 통한 사용자의 답변 등의 관리는 어플리케이션 서버에서 담당할 수 있다. 이 경우 수신기는 별도로 질문을 수신하고 저장할 필요가 없을 수 있다.
도시된 실시예는 전술한 휴리스틱 방법에 의한 것일 수 있다. 수신된 질문 노출 기준정보(t199010)은 @threshold 값이 2 이며, "Baseball, Newyork" 을 태그 값으로 가질 수 있다. 수신기는 사용자의 서비스 시청에 대하여, 그 컨텐츠 히스토리 정보를 태그 값을 이용해 저장할 수 있다. 여기서 이 태그값들은 서비스에 대한 시그널링이 수행될 시에 같이 수신된 것일 수 있다. 예를 들어 컨텐츠 히스토리 스토어(t199020)에는, 6개의 컨텐츠 히스토리 정보가 저장되어 있을 수 있다. CHT1 에는 "Baseball, Newyork, Boston..." 등의 태그 정보가 포함되어 있을 수 있고, CHT2 에는 "Baseball, San Francisco, LA..." 등의 태그 정보가 포함되어 있을 수 있다. 이 태그 정보들은 해당 컨텐츠 히스토리 정보가 나타내는 서비스 시청에 관계된 정보일 수 있다. 즉, CHT1 은 Newyork, Boston, Baseball 에 관계된 서비스가 시청되었음을 나타낼 수 있다. 질문 노출 기준정보가 포함하는 태그인 "Baseball, Newyork" 태그를 포함하는 컨텐츠 히스토리 정보는 CHT1 과 CHT3 이다. 문턱값 2 보다 많은 수인, 총 2 개의 컨텐츠 히스토리 정보가 질문 노출 기준정보의 조건에 만족하므로, 해당 PDI 질문은 사용자에 노출될 수 있다.
도 200 은 본 발명의 일 실시예에 따른, 휴리스틱 방법에 따라 단순화한 컨텐츠 히스토리 정보에 근거해 PDI 유저 데이터를 수집하는 과정을 도시한 도면이다(PDI 유저데이터를 통해 기준정보 전달).
먼저, 유저 매니지먼트 엔진/모듈은 로그인 프로세스를 수행할 수 있다(t200010). 사용자를 구분할 수 있는 기능을 제공하는 수신기에서는 로그인 프로세스를 통해 특정 사용자를 위한 개인화를 수행할 수 있다. 이 경우, PDI 유저 데이터에는 각 사용자를 구분하기 위한 유저 ID 가 추가될 수 있다. 이 단계는 생략될 수 있다.
수신모듈은 컨텐츠 프로바이더 내지 브로드캐스터로부터 서비스에 관한 시그널링 정보를 수신할 수 있다(t200020). 이 시그널링 정보는 태그 정보를 가지는 태그 필드를 수반할 수 있다. 예를 들어 야구 경기에 관한 서비스라고 하면 "Basebal, Newyork, Boston, Yankees, Red Socks" 의 태그 정보가 포함되어 있을 수 있다.
수신모듈은 전달받은 시그널링 정보를 파싱하여 해당 서비스를 사용자에게 보여줄 수 있다. 또한, 파싱된 시그널링 정보는 컨텐츠 히스토리 엔진/모듈로 전달될 수 있다(t200030). 컨텐츠 히스토리 모듈은 사용자의 시청 정보를 저장할 때, 수신된 태그 정보를 같이 저장할 수 있다.
수신모듈은 컨텐츠 프로바이더 내지 브로드캐스터로부터 PDI 유저 데이터(PDI 테이블)을 전달받을 수 있다(t200040). 이 PDI 유저 데이터는 전술한 질문 노출 기준정보를 포함할 수 있다. 여기서 이 질문 노출 기준정보는 휴리스틱 방법에 기반한 태그 정보일 수 있다. 예를 들어 "Baseball, Newyork" 과 같은 정보가 포함되어 있을 수 있다. PDI 유저 데이터는 방송망 또는 브로드밴드를 통해 수신기로 전달될 수 있다. 예를 들어, 시청자가 "야구 경기 중 New York 경기를 4번 이상 본 경우"에 해당 PDI 질문을 보여주고 싶으면, @threshold는 4로, 질문 노출 기준정보로서의 태그의 값은 "Baseball, New York"으로 설정할 수 있다.
수신모듈은 수신된 PDI 유저 데이터를 PDI 엔진으로 전달할 수 있다(t200050). PDI 엔진은 PDI 유저 데이터를 파싱한 후, 매칭여부를 판단하기 위하여 질문 노출 기준정보와 문턱값을 컨텐츠 히스토리 엔진으로 전달할 수 있다(t200060). 컨텐츠 히스토리 엔진은 전달된 정보들을 바탕으로 조건들을 만족하는 컨텐츠 히스토리 정보를 탐색할 수 있다(t200070). 이 때 태그 정보를 이용하여 탐색이 수행될 수 있다. 매칭여부를 판단하는 과정은 전술한 바와 같다. 컨텐츠 히스토리 엔진은 매칭 결과를 PDI 엔진으로 전달할 수 있다(t200080).
PDI 엔진은, 매칭된 경우, 해당 PDI 유저 데이터의 PDI 질문을 UI 를 통해 사용자에 노출시킬 수 있다(t200090). 사용자는 UI 를 통해 질문에 답변하고(t200100), PDI 엔진은 해당 답변을 전달받아(t200110), PDI 스토어의 PDI 유저데이터에 저장할 수 있다(t200120).
전술한 각 단계들은 실시예에 따라 생략되거나, 동일/유사한 동작을 하는 다른 단계에 의해 대체될 수 있다.
도 201 은 본 발명의 일 실시예에 따른, 휴리스틱 방법에 따라 단순화한 컨텐츠 히스토리 정보에 근거해 PDI 유저 데이터를 수집하는 과정을 도시한 도면이다(필터링 크리테리아를 통해 기준정보 전달).
로그인 단계 및 태그 정보들을 시그널링 받는 단계(t201011-t200030)는 전술한 바와 같을 수 있다. 수신 모듈은 컨텐츠 프로바이더 내지 브로드캐스터로부터 PDI 유저 데이터를 전달받을 수 있다(t201040). 이는 전술한 PDI 유저 데이터를 수신하는 단계와 유사하나, 이 경우 PDI 유저 데이터는 질문 노출 기준정보를 포함하지 않을 수 있다.
수신된 PDI 유저 데이터는 PDI 엔진으로 전달되어(t201050), PDI 스토어에 저장될 수 있다(t201060), 이 경우 해당 PDI 유저 데이터는 사용자에게 노출되지 않고 단순히 저장만 될 수 있다.
수신 모듈은 컨텐츠 프로바이더 내지 브로드캐스터로부터 필터링 크리테리아를 전달받을 수 있다(t201070). 필터링 크리테리아는 방송망 또는 브로드밴드를 통해 전달될 수 있으며, 컨텐츠 히스토리를 기반으로 PDI 질문의 노출 여부를 판단하기 위한 타입의 필터링 크리테리아일 수 있다. 필터링 크리테리아 내의 질문 노출 기준정보는 태그 형태의 정보일 수 있다. 예를 들어, "Baseball, Newyork" 과 같은 질문 노출 기준정보가 있을 수 있다. 수신모듈은 수신한 필터링 크리테리아를 필터링 엔진/모듈로 전달할 수 있다(t201080).
필터링 엔진은 필터링 크리테리아를 파싱한 후, 매칭여부를 판단하기 위하여 질문 노출 기준정보와 문턱값을 컨텐츠 히스토리 엔진으로 전달할 수 있다(t201090). 컨텐츠 히스토리 엔진은 전달된 정보들을 바탕으로 조건들을 만족하는 컨텐츠 히스토리 정보를 탐색할 수 있다(t201100). 이 때 태그 정보를 이용하여 탐색이 수행될 수 있다. 매칭여부를 판단하는 과정은 전술한 바와 같다. 컨텐츠 히스토리 엔진은 매칭 결과를 필터링 엔진으로 전달할 수 있다(t201110).
필터링 엔진은, 매칭된 경우, @targetQuestionTableId 가 지시하는 PDI 유저 데이터의 PDI 질문을 PDI 엔진에 알릴 수 있다(t201120). PDI 엔진은 해당 PDI 질문을 UI 를 통해 사용자에 노출시킬 수 있다(t201130). 사용자는 UI 를 통해 질문에 답변하고(t201140), PDI 엔진은 해당 답변을 전달받아(t201150), PDI 스토어의 PDI 유저데이터에 저장할 수 있다(t201160).
전술한 각 단계들은 실시예에 따라 생략되거나, 동일/유사한 동작을 하는 다른 단계에 의해 대체될 수 있다.
도 202 는 본 발명의 일 실시예에 따른, ACR 상황에서 컨텐츠 히스토리 정보에 근거해 PDI 유저 데이터를 수집하는 과정을 도시한 도면이다.
STB(Set Top Box) 등의 외부 디코딩 유닛에 의해 서비스가 제공되는 시청환경에서는, 방송 지상파를 통해 시그널링이 불가능할 수 있다. 이 경우, 전술한 지상파를 통한 시그널링이 가능하지 않을 수 있다.
따라서, 이러한 환경, 즉 ACR(Auto Content Recognition) 이 요구되는 환경에서 전술한 컨텐츠 히스토리에 따른 필터링, PDI 질문 노출여부 판단등의 동작이 수행될 수 있는 방안을 제안한다. 이 때 ACR 서버는 단순히 현재 시청중인 방송은 인지하는 것 뿐만 아니라, 유저들간의 개인화 정보 관리, 컨텐츠 히스토리 정보 수집/관리 등의 역할까지 담당할 수 있다.
도시된 실시예는 PDI 유저데이터에 질문 노출 기준정보가 포함되어 전송되는 경우이다. 그러나 본 발명은 필터링 크리테리아에 질문 노출 기준정보가 포함되는 경우도 포함하며, 도시된 실시예에 한정되지 아니한다. 또한 도시된 실시예는 핑거프린트 방식을 사용한 ACR 을 가정하나, 본 발명은 워터마크 등의 다른 ACR 방식을 배제하지 아니한다.
먼저 방송사는 ACR 업체가 제공하는 툴을 이용하여 프로그램 별로 핑거프린트를 추출할 수 있다. 이 때 방송사는 오디오/비디오 핑거프린트 DB 를 구축할 수 있다. 필요한 경우, 오디오/비디오 두가지 핑거프린트 모두 추출되어 저장될 수 있다. 이 후, 방송사는 ACR 서버로 추출된 핑거프린트를 전달할 수 있다. 기 제작된 서비스/컨텐츠의 경우 방송으로 송출되기 전에 핑거프린트 전달이 이뤄질 수 있고, 라이브 서비스/컨텐츠의 경우 실시간으로 핑거프린트가 추출되어 전달될 수 있다. 라이브의 경우, 방송사는 사전에 컨텐츠를 인식할 수 있는 유니크 ID 정보를 부여하여 실시간으로 추출된 핑거프린트와 매핑하여 ACR 서버에 전달해야 할 수 있다. ACR 서버는 전달받은 핑거프린트들을 DB 에 저장할 수 있다.
수신모듈은 STB 등의 외부 디코딩 유닛을 통해 컨텐츠 프로바이더 내지 브로드캐스터로부터 방송 서비스를 전달받을 수 있다(t202010). 수신 모듈은 수신된 방송 서비스/컨텐츠의 프레임 별로 핑거프린트(시그니쳐)를 추출하여 ACR 서버로 전송할 수 있다(t202020). 이는 일종의 쿼리 리퀘스트(Query Request)일 수 있다. ACR 서버는 수신한 핑거프린트를 ACR DB 에서 검색하여 매칭되는 컨텐츠를 찾을 수 있다. 컨텐츠가 인식되면 ACR 서버는 컨텐츠에 관한 정보와 관련 시그널링 서버의 주소를 수신기 쪽으로 전달할 수 있다(t202030). 이와 동시에 ACR 서버는 수신기의 시청 정보를 알 수 있으므로, 이를 컨텐츠 히스토리 정보의 형태로 저장해두고 관리할 수 있다.
컨텐츠의 인식결과에 따라 관련된 PDI 유저 데이터가 있는지 여부에 관하여, 수신기는 시그널링 서버로 PDI 유저 데이터를 요청할 수 있다(t202040). 이는 수신기 내의 네트워크 인터페이스 등에 의해 수행될 수 있다. 본 실시예에서 수신 모듈은 일종의 네트워크 인터페이스일 수 있다. 이 때 시그널링 서버는 일종의 PDI 서버일 수 있다. 시그널링 서버는 관련된 PDI 유저 데이터를 수신기 내의 PDI 엔진으로 전달할 수 있다(t202050).
PDI 엔진은 전달받은 PDI 유저 데이터를 파싱하여, 질문 노출 기준정보를 획득할 수 있다(t202060). PDI 엔진은 ACR 서버로 질문 노출 기준정보를 전달할 수 있다(t202070). 이 전달은 수신모듈 내지 네트워크 인터페이스를 통하여 수행될 수 있다. ACR 서버는 기 저장된 컨텐츠 히스토리 정보와, 전달받은 질문 노출 기준정보의 매칭여부를 판단할 수 있다(t202080). 매칭결과는 PDI 엔진으로 전달될 수 있다(t202090). 이 전달 역시 수신모듈 내지 네트워크 인터페이스를 통하여 수행될 수 있다.
PDI 엔진은, 매칭된 경우, 해당 PDI 유저 데이터의 PDI 질문을 UI 를 통해 사용자에 노출시킬 수 있다(t202100). 사용자는 UI 를 통해 질문에 답변하고(t202110), PDI 엔진은 해당 답변을 전달받아 PDI 스토어의 PDI 유저데이터에 저장할 수 있다(t202120).
전술한 각 단계들은 실시예에 따라 생략되거나, 동일/유사한 동작을 하는 다른 단계에 의해 대체될 수 있다.
도 203 은 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법을 도시한 도면이다.
본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법은, 개인화 테이블을 수신하는 단계, 답변을 획득하여 저장하는 단계, 제 1 필터링 크리테리아를 수신하는 단계 및/또는 특정 서비스에 관한 서비스 데이터를 수신하는 단계를 포함할 수 있다.
먼저, 수신모듈이 개인화된 서비스 제공에 관한 적어도 하나의 개인화 질문을을 포함하는 개인화 테이블을 수신할 수 있다(t203010). 여기서 개인화 질문은 전술한 PDI 질문을 의미할 수 있다. 개인화 테이블은 전술한 PDI 유저 데이터 내지 PDI 테이블을 의미할 수 있다. 여기서 수신 모듈은 방송 수신기 내의 수신 모듈로서, 튜너 또는 네트워크 인터페이스 또는 둘을 합친 개념을 일컬을 수 있다.
개인화 모듈은 사용자로부터 적어도 하나의 개인화 질문에 대한 답변을 획득하여 저장할 수 있다(t203020). 여기서 개인화 모듈은 전술한 PDI 엔진/모듈을 의미할 수 있다. 답변 획득 과정은 UI 를 이용하여 이루어질 수 있다. PDI 엔진은 획득한 답변을 PDI 스토어 내의 PDI 유저 데이터에 저장할 수 있다.
수신 모듈은 이후 특정 서비스에 관한 개인화 기준정보를 포함하는 제 1 필터링 크리테리아를 수신할 수 있다(t203030). 여기서 개인화 기준정보는 PDI 유저 데이터를 기반으로 하여 서비스/컨텐츠의 필터링의 기준이 되는 기준정보를 의미할 수 있다. 여기서 제 1 필터링 크리테리아는 서비스/컨텐츠의 필터링에 사용되는 타입의 필터링 크리테리아일 수 있다. 제 1 필터링 크리테리아는 "특정 서비스"의 필터링에 관한 필터링 크리테리아일 수 있다.
필터링 모듈은 수신한 제 1 필터링 크리테리아의 개인화 기준정보와 저장된 답변을 비교하여 매칭여부를 판단하고, 매칭되는 경우 수신모듈이 특정 서비스에 관한 서비스 데이터를 수신할 수 있다(t203040). 필터링 크리테리아의 기준정보들과 PDI 유저 데이터가 비교하여 매칭여부가 판단될 수 있다. 이 과정에서 전술한 문턱값 또는 가중치등이 사용될 수 있다. 매칭되는 경우, 해당 서비스/컨텐츠가 사용자의 선호도에 맞는 것으로 판단되어, 수신모듈에 의해 수신될 수 있다.
본 발명의 다른 실시예에 따른 개인화된 서비스를 제공하는 방법은, 히스토리 모듈이 사용자의 서비스 시청에 대해 시청 히스토리 정보를 생성하여 저장하는 단계를 더 포함할 수 있다. 여기서 히스토리 모듈은 전술한 컨텐츠 히스토리 엔진/모듈에 해당할 수 있다. 여기서 시청 히스토리 정보는 전술한 컨텐츠 히스토리 정보 내지 컨텐츠 히스토리 테이블에 해당할 수 있다. 여기서 컨텐츠 히스토리 정보는 컨텐츠 히스토리 스토어에 저장될 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 제 1 필터링 크리테리아는 특정 서비스에 관한 히스토리 기준정보를 더 포함할 수 있다. 제 1 필터링 크리테리아는 PDI 유저 데이터에 기반한 기준정보(Criterion) 뿐 아니라, 컨텐츠 히스토리 정보에 기반한 기준정보를 더 포함할 수 있다. 여기서 히스토리 기준정보는 전술한 컨텐츠 히스토리에 기반한 기준정보(Criterion) 에 해당할 수 있다. 본 실시예에서, 컨텐츠 히스토리 엔진/모듈은 컨텐츠 히스토리 정보와 히스토리 기준정보를 비교할 수 있다. 양자가 매칭되는 경우, 해당 서비스/컨텐츠가 사용자의 서비스 시청 내역에 맞는 것으로 판단되어, 서비스 데이터가 수신모듈에 의해 수신될 수 있다. 여기서 매칭은 전술한 문턱값 또는 가중치등이 사용될 수 있다. 본 실시예는, PDI 유저 데이터 및/또는 컨텐츠 히스토리 정보를 모두 고려하여 서비스/컨텐츠의 필터링을 수행하는 경우에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 개인화 질문은 해당 개인화 질문의 노출여부에 관한 적어도 하나의 질문 노출 기준정보를 포함할 수 있다. 여기서, 질문 노출 기준정보는 전술한 질문 노출 기준정보에 해당할 수 있다. 본 실시예는 질문 노출 기준정보가 PDI 유저 데이터에 포함되어 전송되는 경우에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법은, 수신 모듈이 타겟 개인화 질문 지시자 및 적어도 하나의 질문 노출 기준정보를 포함하는 제 2 필터링 크리테리아를 수신하는 단계를 더 포함할 수 있다. 타겟 개인화 질문 지시자는 전술한 타겟 질문 지시자 즉, @targetQuestionTableId 에 해당할 수 있다. 여기서, 제 2 필터링 크리테리아는 전술한 PDI 질문의 노출여부를 결정하는 역할을 하는 타입의 필터링 크리테리아에 해당할 수 있다. 질문 노출 기준정보는 전술한 필터링 크리테리아 내의 FilterCriterion 엘레멘트 등에 해당할 수 있다. 본 실시예는 질문 노출 기준정보가 필터링 크리테리아를 통해 전송되는 경우에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 전술한 개인화 질문에 대한 답변을 획득하여 저장하는 단계는: 질문 노출 기준정보와 시청 히스토리 정보를 비교하여 매칭되는 경우에 개인화 질문을 노출시키는 단계 및/또는 개인화 질문에 대한 답변을 획득하여 저장하는 단계를 포함할 수 있다. 전술한 컨텐츠 히스토리 엔진/모듈(히스토리 모듈)은 전달받은 질문 노출 기준정보와 컨텐츠 히스토리 정보를 비교할 수 있다. 매칭여부의 판단은 전술한 실시예들에 따라 수행될 수 있다. 매칭된다고 판단된 경우, PDI 엔진(개인화 모듈)은 해당 개인화 질문을 노출시킬 수 있다. 여기서 해당 개인화 질문은 질문 노출 기준정보를 가지고 있던 PDI 유저 데이터의 PDI 질문, 또는 필터링 크리테리아의 타겟 질문 지시자가 지시하는 PDI 질문일 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 제 2 필터링 크리테리아는 문턱값(threshold) 정보를 더 포함할 수 있다. 문턱값 정보는 전술한 @threshold 에 해당하는 정보일 수 있다. 본 실시예에서, 질문 노출 기준정보들과 일치하는 시청 히스토리 정보들의 개수가 문턱값 정보의 값보다 큰 경우에 양자가 매칭되었다고 판단될 수 있다. 매칭된 경우, 특정 개인화 질문이 노출될 수 있다. 판단은 컨텐츠 히스토리 엔진/모듈 또는 PDI 엔진/모듈 에서 수행될 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 저장된 시청 히스토리 정보는 시청된 서비스를 표현하는 복수개의 태그(tag) 일 수 있다. 전술한 문제점 해결을 위하여 휴리스틱 방법이 쓰일 수 있다. 이 경우, 태그는 시그널링 정보와 함께 수신기로 전달되었을 수 있다. 제 2 필터링 크리테리아를 통해 전달되는 질문 노출 기준정보 역시 태그를 이용하여 표현되었을 수 있다. 본 실시예의 특정 개인화 질문을 노출시키는 단계는, 질문 노출 기준정보의 적어도 하나의 태그를 모두 포함하고 있는 시청 히스토리 정보의 개수가 문턱값 정보의 값보다 큰 경우에 양자가 매칭되었다고 판단될 수 있다. 매칭된 경우, 특정 개인화 질문을 노출될 수 있다. 판단은 컨텐츠 히스토리 엔진/모듈 또는 PDI 엔진/모듈 에서 수행될 수 있다. 본 실시예는 휴리스틱 방법이 활용되는 경우에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법은, 수신모듈이 외부 디코딩 유닛으로부터 방송 컨텐츠를 전달받을 수 있다. 여기서 외부 디코딩 유닛은 전술한 STB 등에 해당할 수 있다. 또한 본 실시예에서 ACR 모듈은 방송 컨텐츠의 프레임들에 대한 핑거 프린트를 생성하여 ACR 서버로 전송할 수 있다. 여기서, ACR 모듈은 수신기 내의 특정 모듈이거나, 전술한 수신모듈 내지 네트워크 인터페이스일 수 있다. 여기서 핑거 프린트의 전송은 사용자의 서비스 시청에 대한 시청 히스토리 정보, 즉 컨텐츠 히스토리 정보를 수반할 수 있다. 본 실시예는 ACR 환경에서의 컨텐츠 히스토리 정보에 기반한 PDI 유저 데이터 수집에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 개인화 질문은 해당 개인화 질문의 노출여부에 관한 적어도 하나의 질문 노출 기준정보를 포함할 수 있다. 이는 질문 노출 기준정보가 PDI 유저 데이터를 통해 전달되는 경우를 상정한 것일 수 있다. ACR 모듈은 ACR 서버로 질문 노출 기준정보를 전송할 수 있다. 질문 노출 기준정보는 ACR 서버 내에 축적된 컨텐츠 히스토리 정보와 비교될 수 있다. 매칭 과정은 전술한 실시예들에서 설명한 것과 같은 방식으로 수행될 수 있다. ACR 모듈은 ACR 서버로부터 양자의 매칭 결과를 전달받을 수 있다. 매칭되는 경우 개인화 모듈(PDI 엔진/모듈)이 해당 개인화 질문을 노출시키고, 사용자로부터 그 답변을 획득하여 저장할 수 있다. 본 실시예는 ACR 환경에서의 컨텐츠 히스토리 정보에 기반한 PDI 유저 데이터 수집에 해당할 수 있다.
본 발명의 일 실시예에 따른, 컨텐츠 프로바이더 측에서 개인화된 서비스를 제공하는 방법을 설명한다. 본 방법은 도면에 도시되지 아니하였다.
컨텐츠 프로바이더는 PDI 질문을 포함하는 PDI 유저 데이터를 생성하여 수신기로 전송할 수 있다. 여기서 PDI 질문 및 PDI 유저 데이터는 전술된 각각의 실시예에 따른 PDI 질문, PDI 유저데이터일 수 있다. 그 구조 및 내부 정보 역시 각각의 실시예에 따를 수 있다.
또한 컨텐츠 프로바이더는 필터링 크리테리아를 생성하여 이를 수신기로 전송할 수 있다. 여기서 필터링 크리테리아는 전술한 각각의 실시예에 따른 필터링 크리테리아일 수 있다. 예를 들어, 이 필터링 크리테리아는 서비스/컨텐츠의 필터링을 위한 필터링 크리테리아 또는 PDI 질문의 노출여부의 필터링을 위한 필터링 크리테리아일 수 있다. 그 구조 및 내부 정보 역시 각각의 실시예에 따를 수 있다.
또한 컨텐츠 프로바이더는 서비스/컨텐츠를 생성하여 이를 수신기로 전송할 수 있다. 이러한 서비스/컨텐츠의 전송은 필터링 크리테리아의 필터링 결과에 따라 수행될 수 있다.
여기서, PDI 유저 데이터의 생성, 필터링 크리테리아의 생성은 PDI 데이터 생성모듈에 의해 수행될 수 있다. 서비스/컨텐츠의 생성은 서비스 데이터 생성모듈에 의해 수행될 수 있다. 수신기로의 데이터 전송은 전송모듈에 의해 수행될 수 있다.
ACR 서버 측에서는 ACR 동작을 수행함과 동시에, 컨텐츠 히스토리 정보를 저장할 수 있다. 또한 질문 노출 기준정보를 전달받아 그 매칭여부를 판단하거나, PDI 유저 데이터 기반 기준정보를 전달받아 그 매칭여부를 판단할 수 있다. 이는 ACR 서버 내의 컨텐츠 히스토리 모듈, PDI 모듈, 네트워크 인터페이스, ACR DB 등에 의해 각각 수행될 수 있다.
전술한 단계들은 실시예에 따라 생략되거나, 유사/동일한 동작을 수행하는 다른 단계에 의해 대체될 수 있다.
도 204 는 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방송 수신기를 도시한 도면이다.
본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방송 수신기는 전술한 수신모듈, 개인화 모듈 및/또는 필터링 모듈을 포함할 수 있다. 실시예에 따라 방송 수신기는 컨텐츠 히스토리 모듈 및/또는 ACR 모듈을 더 포함할 수 있다. 각각의 블락, 모듈들은 전술한 바와 같다.
본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방송 수신기 및 그 내부 모듈/블락들은, 전술한 본 발명의 개인화된 서비스를 제공하는 방법의 실시예들을 수행할 수 있다.
본 발명의 일 실시예에 따른 컨텐츠 프로바이더 측에서 개인화된 서비스를 제공하는 장치를 설명한다. 본 장치는 도시되지 않았다.
본 발명의 일 실시예에 따른 컨텐츠 프로바이더 측에서 개인화된 서비스를 제공하는 장치는 전술한 PDI 데이터 생성모듈, 서비스 데이터 생성모듈 및/또는 전송모듈을 포함할 수 있다. ACR 서버 측의 장치는 컨텐츠 히스토리 모듈, PDI 모듈, 네트워크 인터페이스 및/또는 ACR DB 를 포함할 수 있다. 각각의 블락, 모듈들은 전술한 바와 같다.
본 발명의 일 실시예에 따른 컨텐츠 프로바이더 측에서 개인화된 서비스를 제공하는 장치 및 그 내부 모듈/블락들은, 전술한 본 발명의 컨텐츠 프로바이더 측에서 개인화된 서비스를 제공하는 방법의 실시예들을 수행할 수 있다. 본 발명의 일 실시예에 따른 ACR 서버 측에서의 장치 및 그 내부 모듈/블락들은, 전술한 본 발명의 ACR 서버 측에서 개인화된 서비스를 제공하는 방법의 실시예들을 수행할 수 있다.
전술한 개인화된 서비스를 제공하는 장치들 내부의 블락/모듈 등은 메모리에 저장된 연속된 수행과정들을 실행하는 프로세서들일 수 있고, 실시예에 따라 장치 내/외부에 위치하는 하드웨어 엘레멘트들일 수 있다.
전술한 모듈들은 실시예에 따라 생략되거나, 유사/동일한 동작을 수행하는 다른 모듈에 의해 대체될 수 있다.
모듈 또는 유닛은 메모리(또는 저장 유닛)에 저장된 연속된 수행과정들을 실행하는 프로세서들일 수 있다. 전술한 실시예에 기술된 각 단계들은 하드웨어/프로세서들에 의해 수행될 수 있다. 전술한 실시예에 기술된 각 모듈/블락/유닛들은 하드웨어/프로세서로서 동작할 수 있다. 또한, 본 발명이 제시하는 방법들은 코드로서 실행될 수 있다. 이 코드는 프로세서가 읽을 수 있는 저장매체에 쓰여질 수 있고, 따라서 장치(apparatus)가 제공하는 프로세서에 의해 읽혀질 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명이 제안하는 방법을 네트워크 디바이스에 구비된, 프로세서가 읽을 수 있는 기록매체에, 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 이해된다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.
본 명세서에서 장치 및 방법 발명이 모두 언급되고, 장치 및 방법 발명 모두의 설명은 서로 보완하여 적용될 수 있다.
발명의 실시를 위한 형태
다양한 실시예가 본 발명을 실시하기 위한 최선의 형태에서 설명되었다.
본 발명은 일련의 방송 신호 제공 분야에서 이용된다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.

Claims (20)

  1. 방송 수신기에서 개인화된 서비스를 제공하는 방법에 있어서,
    수신 모듈이 개인화된 서비스 제공에 관한 적어도 하나의 개인화 질문을 포함하는 개인화 테이블을 수신하는 단계;
    개인화 모듈이 사용자로부터 상기 적어도 하나의 개인화 질문에 대한 답변을 획득하여 저장하는 단계;
    상기 수신 모듈이 특정 서비스에 관한 개인화 기준정보를 포함하는 제 1 필터링 크리테리아를 수신하는 단계; 및
    필터링 모듈이 상기 수신한 제 1 필터링 크리테리아의 개인화 기준정보와 상기 저장된 답변을 비교하여 매칭되는 경우, 상기 수신모듈이 상기 특정 서비스에 관한 서비스 데이터를 수신하는 단계;
    를 포함하는 개인화된 서비스를 제공하는 방법.
  2. 제 1 항에 있어서, 상기 개인화된 서비스를 제공하는 방법은:
    히스토리 모듈이 사용자의 서비스 시청에 대해 시청 히스토리 정보를 생성하여 저장하는 단계;
    를 더 포함하는 개인화된 서비스를 제공하는 방법.
  3. 제 2 항에 있어서,
    상기 제 1 필터링 크리테리아는 상기 특정 서비스에 관한 히스토리 기준정보를 더 포함하고,
    상기 특정 서비스에 관한 서비스 데이터를 수신하는 단계는, 상기 제 1 필터링 크리테리아 내의 히스토리 기준정보와 상기 저장된 시청 히스토리 정보를 비교하여 매칭되는 경우, 상기 특정 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  4. 제 2 항에 있어서,
    상기 개인화 질문은 해당 개인화 질문의 노출여부에 관한 적어도 하나의 질문 노출 기준정보를 포함하는 개인화된 서비스를 제공하는 방법.
  5. 제 2 항에 있어서, 상기 개인화된 서비스를 제공하는 방법은:
    상기 수신 모듈이 타겟 개인화 질문 지시자 및 적어도 하나의 질문 노출 기준정보를 포함하는 제 2 필터링 크리테리아를 수신하는 단계를 더 포함하고;
    여기서 상기 타겟 개인화 질문 지시자는 특정 개인화 질문을 지시하고, 상기 질문 노출 기준정보는 상기 특정 개인화 질문의 노출여부에 관한 정보인 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  6. 제 5 항에 있어서, 상기 개인화 질문에 대한 답변을 획득하여 저장하는 단계는:
    상기 히스토리 모듈이 상기 질문 노출 기준정보를 상기 시청 히스토리 정보와 비교하여 매칭되는 경우, 상기 개인화 모듈이 상기 특정 개인화 질문을 노출시키는 단계, 및
    상기 개인화 모듈이 사용자로부터 상기 특정 개인화 질문에 대한 답변을 획득하여 저장하는 단계
    를 더 포함하는 개인화된 서비스를 제공하는 방법.
  7. 제 6 항에 있어서,
    상기 제 2 필터링 크리테리아는 문턱값(threshold) 정보를 더 포함하고,
    상기 특정 개인화 질문을 노출시키는 단계는,
    상기 질문 노출 기준정보들과 일치하는 시청 히스토리 정보들의 개수가 상기 문턱값 정보의 값보다 큰 경우, 상기 특정 개인화 질문을 노출시키는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  8. 제 6 항에 있어서,
    상기 저장된 시청 히스토리 정보는 시청된 서비스를 표현하는 복수개의 태그(tag) 이고, 상기 제 2 필터링 크리테리아의 질문 노출 기준정보는 적어도 하나의 태그를 포함하고,
    상기 특정 개인화 질문을 노출시키는 단계는,
    상기 질문 노출 기준정보의 적어도 하나의 태그를 모두 포함하고 있는 시청 히스토리 정보의 개수가 상기 문턱값 정보의 값보다 큰 경우, 상기 특정 개인화 질문을 노출시키는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  9. 제 1 항에 있어서, 상기 개인화된 서비스를 제공하는 방법은:
    상기 수신 모듈이 외부 디코딩 유닛으로부터 방송 컨텐츠를 전달받는 단계; 및
    ACR (Auto Content Recognition) 모듈이 상기 방송 컨텐츠의 프레임들에 대한 핑거 프린트를 생성하여 ACR 서버로 전송하는 단계; 를 더 포함하고,
    여기서 핑거 프린트의 전송은 사용자의 서비스 시청에 대한 시청 히스토리 정보를 수반하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  10. 제 9 항에 있어서,
    상기 개인화 질문은 해당 개인화 질문의 노출여부에 관한 적어도 하나의 질문 노출 기준정보를 포함하고, 상기 개인화 질문에 대한 답변을 획득하여 저장하는 단계는:
    상기 ACR 모듈이 상기 ACR 서버로 상기 질문 노출 기준정보를 전송하는 단계, 여기서 상기 질문 노출 기준정보는 상기 ACR 서버 내의 시청 히스토리 정보와 비교되고;
    상기 ACR 모듈이 상기 ACR 서버로부터 상기 질문 노출 기준정보와 상기 전송한 시청 히스토리 정보의 매칭 결과를 전달받는 단계;
    상기 개인화 모듈이 상기 매칭 결과에 따라 상기 해당 개인화 질문을 노출시키는 단계; 및
    상기 개인화 모듈이 사용자로부터 상기 해당 개인화 질문에 대한 답변을 획득하여 저장하는 단계;
    를 더 포함하는 개인화된 서비스를 제공하는 방법.
  11. 개인화된 서비스 제공에 관한 적어도 하나의 개인화 질문을 포함하는 개인화 테이블을 수신하는 수신 모듈;
    사용자로부터 상기 적어도 하나의 개인화 질문에 대한 답변을 획득하여 저장하는 개인화 모듈, 여기서, 상기 수신 모듈은 특정 서비스에 관한 개인화 기준정보를 포함하는 제 1 필터링 크리테리아를 수신하고; 및
    상기 수신한 제 1 필터링 크리테리아의 개인화 기준정보와 상기 저장된 답변을 비교하는 필터링 모듈, 여기서 상기 개인화 기준정보와 상기 저장된 답변이 매칭되는 경우, 상기 수신모듈이 상기 특정 서비스에 관한 서비스 데이터를 수신하고;
    를 포함하는 개인화된 서비스를 제공하는 방송 수신기.
  12. 제 11 항에 있어서, 상기 개인화된 서비스를 제공하는 방송 수신기는,
    사용자의 서비스 시청에 대해 시청 히스토리 정보를 생성하여 저장하는 히스토리 모듈;
    을 더 포함하는 개인화된 서비스를 제공하는 방송 수신기.
  13. 제 12 항에 있어서,
    상기 제 1 필터링 크리테리아는 상기 특정 서비스에 관한 히스토리 기준정보를 더 포함하고,
    상기 히스토리 모듈은 상기 제 1 필터링 크리테리아 내의 히스토리 기준정보와 상기 저장된 시청 히스토리 정보를 비교하고,
    상기 수신 모듈은 상기 히스토리 기준정보와 상기 저장된 시청 히스토리 정보가 매칭되는 경우, 상기 특정 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
  14. 제 12 항에 있어서,
    상기 개인화 질문은 해당 개인화 질문의 노출여부에 관한 적어도 하나의 질문 노출 기준정보를 포함하는 개인화된 서비스를 제공하는 방송 수신기.
  15. 제 12 항에 있어서,
    상기 수신 모듈은 타겟 개인화 질문 지시자 및 적어도 하나의 질문 노출 기준정보를 포함하는 제 2 필터링 크리테리아를 수신하고,
    여기서 상기 타겟 개인화 질문 지시자는 특정 개인화 질문을 지시하고, 상기 질문 노출 기준정보는 상기 특정 개인화 질문의 노출여부에 관한 정보인 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
  16. 제 15 항에 있어서,
    상기 히스토리 모듈은 상기 질문 노출 기준정보를 상기 시청 히스토리 정보와 비교하고,
    상기 개인화 모듈은 상기 질문 노출 기준정보와 상기 시청 히스토리 정보가 매칭되는 경우, 상기 특정 개인화 질문을 노출시키고, 사용자로부터 상기 특정 개인화 질문에 대한 답변을 획득하여 저장하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
  17. 제 16 항에 있어서,
    상기 제 2 필터링 크리테리아는 문턱값(threshold) 정보를 더 포함하고,
    상기 히스토리 모듈은 상기 질문 노출 기준정보들과 일치하는 시청 히스토리 정보들의 개수가 상기 문턱값 정보의 값보다 큰 경우 매칭되었다고 판단하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
  18. 제 16 항에 있어서,
    상기 저장된 시청 히스토리 정보는 시청된 서비스를 표현하는 복수개의 태그(tag) 이고, 상기 제 2 필터링 크리테리아의 질문 노출 기준정보는 적어도 하나의 태그를 포함하고,
    상기 히스토리 모듈은 상기 질문 노출 기준정보의 적어도 하나의 태그를 모두 포함하고 있는 시청 히스토리 정보의 개수가 상기 문턱값 정보의 값보다 큰 경우 매칭되었다고 판단하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
  19. 제 11 항에 있어서,
    상기 수신 모듈은 외부 디코딩 유닛으로부터 방송 컨텐츠를 전달받고, 상기 방송 수신기는:
    상기 방송 컨텐츠의 프레임들에 대한 핑거 프린트를 생성하여 ACR (Auto Content Recognition) 서버로 전송하는 ACR 모듈을 더 포함하고,
    여기서 핑거 프린트의 전송은 사용자의 서비스 시청에 대한 시청 히스토리 정보를 수반하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
  20. 제 19 항에 있어서,
    상기 개인화 질문은 해당 개인화 질문의 노출여부에 관한 적어도 하나의 질문 노출 기준정보를 포함하고,
    상기 ACR 모듈은 상기 ACR 서버로 상기 질문 노출 기준정보를 전송하고, 여기서 상기 질문 노출 기준정보는 상기 ACR 서버 내의 시청 히스토리 정보와 비교되고,
    상기 ACR 모듈은 상기 ACR 서버로부터 상기 질문 노출 기준정보와 상기 전송한 시청 히스토리 정보의 매칭 결과를 전달받고,
    상기 개인화 모듈은 상기 매칭 결과에 따라 상기 해당 개인화 질문을 노출시키고, 사용자로부터 상기 해당 개인화 질문에 대한 답변을 획득하여 저장하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방송 수신기.
KR1020177001595A 2014-07-29 2015-07-15 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 KR101902409B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462030603P 2014-07-29 2014-07-29
US62/030,603 2014-07-29
PCT/KR2015/007352 WO2016017964A1 (ko) 2014-07-29 2015-07-15 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Publications (2)

Publication Number Publication Date
KR20170026484A true KR20170026484A (ko) 2017-03-08
KR101902409B1 KR101902409B1 (ko) 2018-09-28

Family

ID=55217797

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177001595A KR101902409B1 (ko) 2014-07-29 2015-07-15 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Country Status (3)

Country Link
US (1) US20170134809A1 (ko)
KR (1) KR101902409B1 (ko)
WO (1) WO2016017964A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10841656B2 (en) 2018-05-11 2020-11-17 Samsung Electronics Co., Ltd. Electronic apparatus and controlling method thereof

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10575055B2 (en) * 2016-07-11 2020-02-25 Sony Corporation Using automatic content recognition (ACR) to weight search results for audio video display device (AVDD)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130091748A (ko) * 2010-08-27 2013-08-19 소니 주식회사 송신 장치 및 방법, 수신 장치 및 방법, 및 송수신 시스템
US20140068686A1 (en) * 2012-08-29 2014-03-06 Lg Electronics Inc. Method and apparatus for processing digital service signal

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120233631A1 (en) * 1991-12-02 2012-09-13 Geshwind David M Processes and systems for creating and delivering granular idiomorphic media suitable for interstitial channels
JPH117453A (ja) * 1997-04-22 1999-01-12 Mitsubishi Electric Corp メディア情報推薦装置
JP4792602B2 (ja) * 2006-04-07 2011-10-12 日本放送協会 情報通信装置、情報通信方法及びプログラム
FR2925197A1 (fr) * 2007-12-17 2009-06-19 Alcatel Lucent Sas Procede de diffusion d'informations personnalisees sur un reseau iptv. dispositif pour la mise en oeuvre de ce procede
KR101131613B1 (ko) * 2008-11-20 2012-03-30 한국전자통신연구원 개인 맞춤형 방송 서비스 제공 방법
US9723360B2 (en) * 2010-04-01 2017-08-01 Saturn Licensing Llc Interests and demographics profile for advanced broadcast services
US20110247028A1 (en) * 2010-04-01 2011-10-06 Mark Eyer Receiver and System Using an Electronic Questionnaire for Advanced Broadcast Services
US9351037B2 (en) * 2012-02-07 2016-05-24 Turner Broadcasting System, Inc. Method and system for contextual advertisement replacement utilizing automatic content recognition

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130091748A (ko) * 2010-08-27 2013-08-19 소니 주식회사 송신 장치 및 방법, 수신 장치 및 방법, 및 송수신 시스템
US20140068686A1 (en) * 2012-08-29 2014-03-06 Lg Electronics Inc. Method and apparatus for processing digital service signal

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10841656B2 (en) 2018-05-11 2020-11-17 Samsung Electronics Co., Ltd. Electronic apparatus and controlling method thereof

Also Published As

Publication number Publication date
WO2016017964A1 (ko) 2016-02-04
KR101902409B1 (ko) 2018-09-28
US20170134809A1 (en) 2017-05-11

Similar Documents

Publication Publication Date Title
KR101850727B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법
KR101832781B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US11265619B2 (en) Method for transmitting broadcast signals and method for receiving broadcast signals
JP6474835B2 (ja) ハイブリッド放送サービスを処理する装置、及びハイブリッド放送サービスを処理する方法
KR101838078B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법
JP6189546B2 (ja) 放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置
KR101923459B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR20150052832A (ko) 디지털 서비스 신호 처리 방법 및 장치
KR101672288B1 (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