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

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

Info

Publication number
WO2015186954A1
WO2015186954A1 PCT/KR2015/005534 KR2015005534W WO2015186954A1 WO 2015186954 A1 WO2015186954 A1 WO 2015186954A1 KR 2015005534 W KR2015005534 W KR 2015005534W WO 2015186954 A1 WO2015186954 A1 WO 2015186954A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
information
pdi
question
present
Prior art date
Application number
PCT/KR2015/005534
Other languages
English (en)
French (fr)
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 엘지전자 주식회사
Priority to US15/301,826 priority Critical patent/US20170180809A1/en
Priority to KR1020167020595A priority patent/KR101832781B1/ko
Publication of WO2015186954A1 publication Critical patent/WO2015186954A1/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
    • 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/9536—Search customisation based on social or collaborative filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/232—Content retrieval operation locally within server, e.g. reading video streams from disk arrays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/278—Content descriptor database or directory service for end-user access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/432—Content retrieval operation from a local storage medium, e.g. hard-disk
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4668—Learning process for intelligent management, e.g. learning user preferences for recommending movies for recommending content, e.g. movies

Definitions

  • the present invention relates to a broadcast signal transmission apparatus, a broadcast signal reception apparatus, and a broadcast signal transmission and reception method.
  • the digital broadcast signal may include a larger amount of video / audio data than the analog broadcast signal, and may further include various types of additional data as well as the video / audio data.
  • the digital broadcasting system may provide high definition (HD) images, multichannel audio, and various additional services.
  • HD high definition
  • data transmission efficiency for a large amount of data transmission, robustness of a transmission / reception network, and network flexibility in consideration of a mobile receiving device should be improved.
  • a method for providing a personalized service includes receiving a personalization table, wherein the personalization table provides a personalized service.
  • a method of providing a personalized service comprises: receiving a filtering criterion relating to a service, wherein said filtering criterion comprises information relating to said service; Comparing the information in the filtering criteria with the obtained answer; And receiving service data about the service if the information in the filtering criteria and the obtained answer match. It may be a method of providing a personalized service further including.
  • the filtering criterion may be a method for providing a personalized service, which is received by being included in service signaling information signaling the service.
  • the personalization question has a different structure according to the answer type of the personalization question, wherein the personalization question includes a question element including information about the question and an answer element capable of storing an answer to the personalization question. It may be a method of providing a personalized service characterized by.
  • the personalization question may be a method for providing a personalized service, characterized in that the personalization question further includes auto-generation information indicating whether the receiver can automatically answer.
  • the answer to the personalization question according to the auto-generated information may be a method for providing a personalized service, characterized in that is automatically obtained by the receiver.
  • the auto-generated information is a method for providing a personalized service, characterized in that it further comprises a replacement question identifier for identifying a question to replace the personalization question when the receiver does not automatically answer the personalization question.
  • a replacement question identifier for identifying a question to replace the personalization question when the receiver does not automatically answer the personalization question.
  • the method of providing a personalized service comprises: generating a history table containing viewing history information relating to viewing of a service; Comparing the information in the filtering criteria with the information in the history table; And receiving service data regarding the service when the information in the filtering criteria and the information in the history table match. It may be a method of providing a personalized service further including.
  • the history table may be a method of providing a personalized service including history information about a viewer, a viewing time, a viewing place, a viewing object, or a viewing method.
  • the filtering criterion includes reference information about a viewer, a viewing time, a viewing place, a viewing object, or a viewing method, and the service data about the service based on the number of the reference information matching the history information. It may be a method for providing a personalized service characterized in that is received.
  • each of the reference information includes weight information, and the service data regarding the service is received based on the weight of the reference information matching the history information. Can be.
  • An apparatus for providing this personalized service comprises: a first module for receiving a personalization table, wherein the personalization table includes a plurality of personalization questions related to the personalization service and a table identifier identifying the personalization table; And a second module for obtaining at least one answer to the plurality of personalization questions, wherein the second module stores the obtained answer in the personalization table; It may be a device that provides a personalized service including a.
  • the first module receives a filtering criterion relating to a service, wherein the filtering criterion comprises information relating to the service;
  • the apparatus for providing the personalized service comprises a third module for comparing the obtained answer with information in the filtering criteria; And the first module may receive service data regarding the service when the information in the filtering criteria and the obtained answer match.
  • the filtering criterion may be an apparatus for providing a personalized service, which is received by being included in service signaling information signaling the service.
  • the personalization question has a different structure according to the answer type of the personalization question, wherein the personalization question includes a question element including information about the question and an answer element capable of storing an answer to the personalization question. It may be a device for providing a personalized service characterized by.
  • the personalization question may be a device for providing a personalized service, characterized in that the personalization question further comprises automatic generation information indicating whether the receiver can automatically answer the form.
  • the answer to the personalization question according to the auto-generated information may be a device for providing a personalized service, characterized in that is automatically obtained by the receiver.
  • the auto-generated information is an apparatus for providing a personalized service, characterized in that it further comprises an alternative question identifier for identifying a question to replace the personalized question when the receiver does not automatically answer the personalized question. Can be.
  • the apparatus for providing a personalized service comprises a fourth module for generating a history table containing viewing history information about viewing of the service;
  • the third module compares information in the filtering criteria with information in the history table; And when the information in the filtering criteria and the information in the history table coincide with each other, the first module may be a device for providing a personalized service.
  • the history table may be a device for providing a personalized service including history information on a viewer, a viewing time, a viewing place, a viewing object, or a viewing method.
  • the filtering criterion includes reference information about a viewer, a viewing time, a viewing place, a viewing object, or a viewing method, and the service data about the service based on the number of the reference information matching the history information. It may be a device for providing a personalized service characterized in that is received.
  • each of the reference information includes weight information
  • the apparatus for providing a personalized service characterized in that the service data about the service is received based on the weight of the reference information matching the history information. Can be.
  • the present invention can provide various broadcast services by processing data according to service characteristics to control a quality of service (QoS) for each service or service component.
  • QoS quality of service
  • the present invention can achieve transmission flexibility by transmitting various broadcast services through the same radio frequency (RF) signal bandwidth.
  • RF radio frequency
  • the present invention can improve data transmission efficiency and robustness of transmission and reception of broadcast signals using a multiple-input multiple-output (MIMO) system.
  • MIMO multiple-input multiple-output
  • the present invention it is possible to provide a broadcast signal transmission and reception method and apparatus capable of receiving a digital broadcast signal without errors even when using a mobile reception device or in an indoor environment.
  • FIG. 1 shows a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to an embodiment of the present invention.
  • FIG 2 illustrates an input formatting block according to an embodiment of the present invention.
  • FIG 3 illustrates an input formatting block according to another embodiment of the present invention.
  • BICM bit interleaved coding & modulation
  • FIG. 5 illustrates a BICM block according to another embodiment of the present invention.
  • FIG. 6 illustrates a frame building block according to an embodiment of the present invention.
  • FIG 7 illustrates an orthogonal frequency division multiplexing (OFDM) generation block according to an embodiment of the present invention.
  • OFDM orthogonal frequency division multiplexing
  • FIG. 8 illustrates a structure of a broadcast signal receiving apparatus for a next generation broadcast service according to an embodiment of the present invention.
  • FIG. 9 shows a frame structure according to an embodiment of the present invention.
  • FIG. 10 illustrates a signaling hierarchy structure of a frame according to an embodiment of the present invention.
  • FIG 11 illustrates preamble signaling data according to an embodiment of the present invention.
  • FIG 13 illustrates PLS2 data according to an embodiment of the present invention.
  • FIG 14 illustrates PLS2 data according to another embodiment of the present invention.
  • FIG. 15 illustrates a logical structure of a frame according to an embodiment of the present invention.
  • PLS 16 illustrates physical layer signaling (PLS) mapping according to an embodiment of the present invention.
  • EAC emergency alert channel
  • FEC forward error correction
  • 21 illustrates the basic operation of a twisted row-column block interleaver according to an embodiment of the present invention.
  • FIG. 22 illustrates an operation of a twisted row-column block interleaver according to another embodiment of the present invention.
  • FIG. 23 illustrates a diagonal read pattern of a twisted row-column block interleaver according to an embodiment of the present invention.
  • FIG. 24 illustrates XFECBLOCKs interleaved from each interleaving array according to an embodiment of the present invention.
  • FIG. 25 is a diagram illustrating an enhanced television (TV) service system based on automatic content recognition.
  • FIG. 26 illustrates a flow of digital watermarking technology according to an embodiment of the present invention.
  • FIG. 27 is a diagram illustrating an ACR query result format according to an embodiment of the present invention.
  • 28 is a diagram illustrating syntax of a content identifier according to an embodiment of the present invention.
  • 29 is a diagram showing the structure of a receiver according to an embodiment of the present invention.
  • FIG. 30 is a diagram showing the structure of a receiver according to another embodiment of the present invention.
  • FIG. 31 illustrates a digital broadcasting system according to an embodiment of the present invention.
  • FIG. 32 is a diagram illustrating a digital broadcast system according to another embodiment of the present invention.
  • 35 is a diagram illustrating a PDI table according to an embodiment of the present invention.
  • 36 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 37 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • 38 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • 39 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 40 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • 41 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 42 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 43 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • 44 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • 45 is a diagram illustrating a filtering criteria table according to an embodiment of the present invention.
  • 46 is a diagram illustrating a filtering criteria table according to another embodiment of the present invention.
  • 47 is a diagram illustrating a filtering criteria table according to another embodiment of the present invention.
  • FIG. 48 is a diagram illustrating a filtering criteria table according to another embodiment of the present invention.
  • 49 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • 50 is a diagram illustrating a PDI table section according to an embodiment of the present invention.
  • 51 is a diagram illustrating a PDI table section according to another embodiment of the present invention.
  • FIG. 52 is a diagram illustrating a PDI table section according to another embodiment of the present invention.
  • 53 is a diagram illustrating a PDI table section according to another embodiment of the present invention.
  • 54 is a flowchart of a digital broadcast system according to another embodiment.
  • 55 is a diagram illustrating XML schema of an FDT instance according to another embodiment of the present invention.
  • 57 is a diagram illustrating a consumption model according to an embodiment of the present invention.
  • 58 is a diagram illustrating filtering criteria descriptor syntax according to an embodiment of the present invention.
  • 59 is a diagram illustrating filtering criteria descriptor syntax according to another embodiment of the present invention.
  • 60 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • 61 is a diagram illustrating an HTTP request table according to an embodiment of the present invention.
  • 62 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • FIG. 63 is a diagram illustrating a URL list table according to an embodiment of the present invention.
  • TPT 64 illustrates a TPT according to an embodiment of the present invention.
  • 65 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • 66 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • 67 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • 68 is a flowchart of a digital broadcast system according to another embodiment of the present invention.
  • 69 is a diagram illustrating a receiver targeting criteria table according to an embodiment of the present invention.
  • 70 is a diagram illustrating a pre-registered PDI question according to an embodiment of the present invention.
  • 71 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • FIG. 72 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • 73 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • 74 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • 75 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • 76 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • 77 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • FIG. 78 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • 79 is a diagram illustrating a pre-registered PDI question according to another embodiment of the present invention.
  • FIG. 80 illustrates a PDI API according to an embodiment of the present invention.
  • 81 is a diagram illustrating PDI API according to another embodiment of the present invention.
  • 82 is a diagram illustrating PDI API according to another embodiment of the present invention.
  • 83 is a diagram illustrating a protocol stack for a next generation broadcast system according to an embodiment of the present invention.
  • FIG. 84 is a diagram illustrating an UPnP type Action mechanism according to an embodiment of the present invention.
  • 86 is a diagram illustrating a structure of user data exchange between a receiver and companion devices according to an embodiment of the present invention.
  • 87 illustrates a part of PDI user data according to an embodiment of the present invention.
  • FIG. 88 illustrates another part of PDI user data according to an embodiment of the present invention.
  • 89 is a diagram illustrating a service type and a service ID of a service according to an embodiment of the present invention.
  • 91 is a diagram illustrating an XML structure of a UserDataList according to an embodiment of the present invention.
  • 92 is a view illustrating actions of a UserData service according to an embodiment of the present invention.
  • 93 is a view illustrating GetPDIUserDataProtocolVersion among actions of a UserData service according to an embodiment of the present invention.
  • 94 is a view illustrating GetUserDataIdsList and GetUserData among actions of a UserData service according to an embodiment of the present invention.
  • 95 is a view illustrating extended state variables of a UserData service according to an embodiment of the present invention.
  • 96 is a view illustrating SetUserData among actions of a UserData service according to an embodiment of the present invention.
  • 97 is a view illustrating added state variable of a UserData service according to an embodiment of the present invention.
  • 98 is a view showing another added state variable of a UserData service according to an embodiment of the present invention.
  • FIG. 99 illustrates state variables of a UserData service for pair-wise delivery of questions and answers according to an embodiment of the present invention.
  • 100 is a diagram illustrating an XML structure of UserDataQAList according to an embodiment of the present invention.
  • FIG. 101 is a view illustrating actions of a UserData service for pair-wise delivery of questions and answers according to an embodiment of the present invention.
  • FIG. 102 is a view illustrating GetUserDataQAIdsList and GetUserDataQA among actions of a UserData service for pair-wise delivery of questions and answers according to an embodiment of the present invention.
  • FIG. 102 is a view illustrating GetUserDataQAIdsList and GetUserDataQA among actions of a UserData service for pair-wise delivery of questions and answers according to an embodiment of the present invention.
  • FIG. 103 is a view illustrating SetUserDataQA among actions of a UserData service for delivering a pair of questions and answers according to an embodiment of the present invention.
  • FIG. 103 is a view illustrating SetUserDataQA among actions of a UserData service for delivering a pair of questions and answers according to an embodiment of the present invention.
  • FIG. 104 illustrates a sequence diagram in which PDI user data is delivered through a broadband channel according to an embodiment of the present invention.
  • FIG. 104 illustrates a sequence diagram in which PDI user data is delivered through a broadband channel according to an embodiment of the present invention.
  • 105 is a view showing state variables of a UserData service in a situation where PDI user data is transmitted through a broadband channel according to an embodiment of the present invention.
  • FIG. 106 is a view illustrating an action of a UserData service in a situation in which PDI user data is transmitted through a broadband channel according to an embodiment of the present invention.
  • FIG. 107 is a view illustrating an extended state variable of a UserData service in a situation in which PDI user data is transmitted through a broadband channel according to an embodiment of the present invention.
  • FIG. 108 is a view illustrating an extended state variable of a UserData service in a situation where PDI user data is delivered through a broadband channel according to another embodiment of the present invention.
  • 109 is a diagram illustrating a structure of user data exchange between a receiver and companion devices according to another embodiment of the present invention.
  • 110 is a diagram showing a service type and a service ID of a service according to another embodiment of the present invention.
  • 111 is a view showing state variables of the FilteringCriteria service according to an embodiment of the present invention.
  • 112 is a view illustrating an action of a FilteringCriteria service according to an embodiment of the present invention.
  • 113 is a diagram illustrating a sequence diagram in which an FC is delivered through a broadband channel according to an embodiment of the present invention.
  • FIG. 114 is a diagram illustrating state variables of a FilteringCriteria service in a situation where an FC is delivered through a broadband channel according to an embodiment of the present invention.
  • 115 is a view illustrating an action of a FilteringCriteria service in a situation where an FC is delivered through a broadband channel according to an embodiment of the present invention.
  • 116 is a view illustrating an extended state variable of a FilteringCriteria service in a situation where an FC is delivered through a broadband channel according to an embodiment of the present invention.
  • 117 is a view illustrating an extended state variable of a FilteringCriteria service in a situation where an FC is delivered through a broadband channel according to another embodiment of the present invention.
  • 118 is a view showing a broadcast receiver according to an embodiment of the present invention.
  • 119 illustrates a broadcast receiver according to another embodiment of the present invention.
  • 120 is a diagram illustrating a presentation preference according to an embodiment of the present invention.
  • FIG. 121 is a diagram illustrating a sequence diagram of a closed caption preference according to an embodiment of the present invention.
  • FIG. 122 is a sequence diagram of a closed caption preference according to another embodiment of the present invention.
  • FIG. 122 is a sequence diagram of a closed caption preference according to another embodiment of the present invention.
  • FIG. 123 is a view illustrating extended fields of caption_service_descriptor in closed caption preference according to an embodiment of the present invention.
  • FIG. 124 is a view illustrating a pre-registered PDI Question for using closed captions in closed caption preference according to an embodiment of the present invention.
  • FIG. 125 illustrates a Pre-Registered PDI Question for a closed caption language in the closed caption preference according to an embodiment of the present invention.
  • FIG. 126 is a diagram illustrating a pre-registered PDI Question for a font of a closed caption in the closed caption preference according to an embodiment of the present invention.
  • FIG. 127 is a view illustrating a pre-registered PDI Question for a font size of a closed caption in the closed caption preference according to an embodiment of the present invention.
  • FIG. 128 illustrates a pre-registered PDI Question for alignment of closed captions in closed caption preference according to an embodiment of the present invention.
  • FIG. 129 is a view illustrating a pre-registered PDI Question for a printing direction of a closed caption in the closed caption preference according to an embodiment of the present invention.
  • FIG. 130 is a view illustrating a pre-registered PDI Question for a scrolling direction of a closed caption in the closed caption preference according to an embodiment of the present invention.
  • FIG. 131 is a view illustrating a pre-registered PDI question for an easy reader mode of a closed caption in a closed caption preference according to an embodiment of the present invention. .
  • 132 is a diagram illustrating a sequence diagram of an audio preference according to an embodiment of the present invention.
  • 133 illustrates a sequence diagram of an audio preference according to another embodiment of the present invention.
  • 134 is a view illustrating extended fields of AC-3_audio_stream_descriptor in audio preference according to an embodiment of the present invention.
  • FIG. 135 is a diagram illustrating a pre-registered PDI Question for a language of audio in an audio preference according to an embodiment of the present invention.
  • FIG. 136 is a diagram illustrating a pre-registered PDI Question regarding whether to use a mode for the hearing impaired in audio preference according to an embodiment of the present invention.
  • FIG. 137 is a diagram illustrating a pre-registered PDI Question regarding whether to use a mode for the visually impaired in audio preference according to an embodiment of the present invention.
  • 139 is a sequence diagram of an accessibility & sign language presentation according to another embodiment of the present invention.
  • 140 is a view illustrating sign_language_descriptor in an accessibility & sign language presentation according to an embodiment of the present invention.
  • FIG. 141 is a diagram illustrating a pre-registered PDI Question for using accessibility & sign language presentation in an accessibility & sign language presentation preference according to an embodiment of the present invention.
  • FIG. 142 is a diagram illustrating a pre-registered PDI Question for a preference of a sign language in Accessibility & Sign Language Preference according to an embodiment of the present invention.
  • FIG. 143 is a diagram illustrating a pre-registered PDI Question for a preference of a location of a sign language in an accessibility & sign language preference according to an embodiment of the present invention.
  • 144 is a diagram illustrating a menu screen for updating an answer in a presentation preference according to an embodiment of the present invention.
  • 145 is a diagram illustrating a structure of user data exchange between a receiver and companion devices according to another embodiment of the present invention.
  • 146 illustrates PDIUserData further including a user ID field according to an embodiment of the present invention.
  • 147 is a sequence diagram for obtaining an answer to a PDI Question using a user ID according to an embodiment of the present invention.
  • 148 is a sequence diagram of applying filtering criteria using a user ID according to an embodiment of the present invention.
  • 149 illustrates a method for allocating a user ID according to an embodiment of the present invention.
  • FIG. 150 is a diagram illustrating an XML schema of a preference Criteria to be used for channel or program recommendation according to an embodiment of the present invention.
  • FIG. 151 is a diagram illustrating an XML schema of a preference Criteria to be used for channel or program recommendation according to an embodiment of the present invention.
  • FIG. 152 illustrates a descriptor of a preference Criteria used for channel or program recommendation according to an embodiment of the present invention.
  • FIG. 153 is a diagram illustrating an extension diagram of an XML schema for transmitting a preference criterion at a service level according to an embodiment of the present invention.
  • FIG. 154 is a diagram illustrating an XML schema for transmitting a preference criterion at a service level according to an embodiment of the present invention.
  • 155 is a diagram illustrating an extension diagram of an XML schema for transmitting a preference criterion at a content level according to an embodiment of the present invention.
  • 156 is a diagram illustrating an XML schema for transmitting a preference criterion at the content level according to an embodiment of the present invention.
  • 157 is a sequence diagram for recommending a service / content to a user using a preference criterion delivered with an ESG according to an embodiment of the present invention.
  • FIG. 158 is a sequence diagram for recommending a service / content to a user using a preference criterion delivered with an ESG according to another embodiment of the present invention.
  • 159 is a diagram illustrating a method of comparing preference criteria with PDI user data according to an embodiment of the present invention.
  • 160 illustrates a matching boundary field for comparing preference criteria with PDI user data according to an embodiment of the present invention.
  • 161 is a diagram illustrating a UI for providing a recommended service / content according to an embodiment of the present invention.
  • FIG. 162 is a diagram showing a portion of PDI user data according to another embodiment of the present invention including information on an automatic answer.
  • 163 is a diagram illustrating a portion of PDI user data according to another embodiment of the present invention including information on a reply interval.
  • FIG. 164 illustrates a portion of PDI user data according to another embodiment of the present invention, including information for replacing an auto-answerable question with a supplemental question.
  • FIG. 165 illustrates a sequence diagram for replacing an auto-answerable question with a supplemental question and exposing the answer to a user to derive an answer according to an embodiment of the present invention.
  • 166 illustrates a portion of PDI user data according to another embodiment of the present invention, including ID information for replacing an auto-answerable question with a substitute question.
  • FIG. 167 illustrates a sequence diagram for replacing an auto-answerable question with an alternative question and exposing the answer to a user to derive an answer according to an embodiment of the present invention.
  • 168 illustrates a receiver according to another embodiment of the present invention, further including a content history engine.
  • 169 illustrates a structure of a broadcast receiver according to another embodiment of the present invention.
  • 170 is a diagram illustrating a content history table according to an embodiment of the present invention.
  • FIG. 171 illustrates a filtering criterion according to an embodiment of the present invention corresponding to the aforementioned content history table.
  • 172 illustrates a simplified content history table according to an embodiment of the present invention.
  • FIG. 173 illustrates a simplified content history table according to another embodiment of the present invention.
  • FIG. 174 illustrates a simplified filtering criterion according to an embodiment of the present invention, corresponding to the above-described content history table.
  • 175 illustrates a part of usage reporting data according to an embodiment of the present invention.
  • 176 illustrates another portion of usage reporting data according to an embodiment of the present invention.
  • 177 illustrates a sequence diagram for providing a personalized service using a content history table and filtering criteria according to an embodiment of the present invention.
  • 178 is a diagram illustrating a portion of a filtering criterion according to an embodiment of the present invention including count information.
  • FIG. 179 illustrates a portion of a filtering criterion according to an embodiment of the present invention including threshold information.
  • 180 is a view illustrating a comparison process according to an embodiment of the present invention in a filtering criterion including threshold information.
  • 181 is a diagram illustrating a method of providing a personalized service according to an embodiment of the present invention.
  • 182 is a diagram illustrating an apparatus for providing a personalized service according to an embodiment of the present invention.
  • the present invention provides an apparatus and method for transmitting and receiving broadcast signals for next generation broadcast services.
  • the next generation broadcast service includes a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like.
  • a broadcast signal for a next generation broadcast service may be processed through a non-multiple input multiple output (MIMO) or MIMO scheme.
  • MIMO multiple input multiple output
  • the non-MIMO scheme may include a multiple input single output (MISO) scheme, a single input single output (SISO) scheme, and the like.
  • the MISO or MIMO scheme uses two antennas, but the present invention can be applied to a system using two or more antennas.
  • the present invention can define three physical profiles (base, handheld, advanced) that are optimized to minimize receiver complexity while achieving the performance required for a particular application. have.
  • the physical profile is a subset of all the structures that the corresponding receiver must implement.
  • the three physical profiles share most of the functional blocks, but differ slightly in certain blocks and / or parameters. Further physical profiles can be defined later.
  • a future profile may be multiplexed with a profile present in a single radio frequency (RF) channel through a future extension frame (FEF). Details of each physical profile will be described later.
  • RF radio frequency
  • FEF future extension frame
  • the base profile mainly indicates the main use of a fixed receiving device in connection with a roof-top antenna.
  • the base profile can be moved to any place but can also include portable devices that fall into a relatively stationary reception category.
  • the use of the base profile can be extended for handheld devices or vehicles with some improved implementation, but such use is not expected in base profile receiver operation.
  • the target signal-to-noise ratio range of reception is approximately 10-20 dB, which includes the 15 dB signal-to-noise ratio receiving capability of existing broadcast systems (eg, ATSC A / 53). Receiver complexity and power consumption are not as important as in battery powered handheld devices that will use the handheld profile. Key system parameters for the base profile are listed in Table 1 below.
  • the handheld profile is designed for use in battery powered handheld and in-vehicle devices.
  • the device may move at pedestrian or vehicle speed.
  • the power consumption as well as the receiver complexity is very important for the implementation of devices in the handheld profile.
  • the target signal-to-noise ratio range of the handheld profile is approximately 0-10 dB, but can be set to reach below 0 dB if intended for lower indoor reception.
  • the advance profile provides higher channel capability in exchange for greater execution complexity.
  • the profile requires the use of MIMO transmission and reception, and the UHDTV service is a target use, for which the profile is specifically designed.
  • the enhanced capability may also be used to allow for an increase in the number of services at a given bandwidth, for example multiple SDTV or HDTV services.
  • the target signal to noise ratio range of the advanced profile is approximately 20 to 30 dB.
  • MIMO transmissions initially use existing elliptic polarization transmission equipment and can later be extended to full power cross polarization transmissions. Key system parameters for the advance profile are listed in Table 3 below.
  • the base profile may be used as a profile for both terrestrial broadcast service and mobile broadcast service. That is, the base profile can be used to define the concept of a profile that includes a mobile profile. Also, the advanced profile can be divided into an advanced profile for the base profile with MIMO and an advanced profile for the handheld profile with MIMO. The three profiles can be changed according to the designer's intention.
  • Auxiliary stream A sequence of cells carrying data of an undefined modulation and coding that can be used as a future extension or as required by a broadcaster or network operator.
  • Base data pipe a data pipe that carries service signaling data
  • Baseband Frame (or BBFRAME): A set of Kbch bits that form the input for one FEC encoding process (BCH and LDPC encoding).
  • Coded block one of an LDPC encoded block of PLS1 data or an LDPC encoded block of PLS2 data
  • Data pipe a logical channel in the physical layer that carries service data or related metadata that can carry one or more services or service components
  • Data pipe unit A basic unit that can allocate data cells to data pipes in a frame
  • Data symbol OFDM symbol in a frame that is not a preamble symbol (frame signaling symbols and frame edge symbols are included in the data symbols)
  • DP_ID This 8-bit field uniquely identifies a data pipe within the system identified by SYSTEM_ID.
  • Dummy cell A cell that carries a pseudo-random value used to fill the remaining unused capacity for physical layer signaling (PLS) signaling, data pipes, or auxiliary streams.
  • PLS physical layer signaling
  • FAC Emergency alert channel
  • Frame A physical layer time slot starting with a preamble and ending with a frame edge symbol.
  • Frame repetition unit A set of frames belonging to the same or different physical profile that contains an FEF that is repeated eight times in a super-frame.
  • FEC Fast information channel
  • FECBLOCK set of LDPC encoded bits of data pipe data
  • FFT size The nominal FFT size used for a particular mode equal to the active symbol period Ts expressed in cycles of the fundamental period T.
  • Frame signaling symbol The higher pilot density used at the start of a frame in a particular combination of FFT size, guard interval, and scattered pilot pattern, which carries a portion of the PLS data. Having OFDM symbol
  • Frame edge symbol An OFDM symbol with a higher pilot density used at the end of the frame in a particular combination of FFT size, guard interval, and scatter pilot pattern.
  • Frame-group set of all frames with the same physical profile type in a superframe
  • Future extention frame A physical layer time slot within a super frame that can be used for future expansion, starting with a preamble.
  • Futurecast UTB system A proposed physical layer broadcast system whose input is one or more MPEG2-TS or IP (Internet protocol) or generic streams and the output is an RF signal.
  • Input stream A stream of data for the coordination of services delivered to the end user by the system.
  • Normal data symbols data symbols except frame signaling symbols and frame edge symbols
  • PHY profile A subset of all structures that the corresponding receiver must implement
  • PLS physical layer signaling data consisting of PLS1 and PLS2
  • PLS1 The first set of PLS data carried in a frame signaling symbol (FSS) with fixed size, coding, and modulation that conveys basic information about the system as well as the parameters needed to decode PLS2.
  • FSS frame signaling symbol
  • PLS2 The second set of PLS data sent to the FSS carrying more detailed PLS data about data pipes and systems.
  • PLS2 dynamic data PLS2 data that changes dynamically from frame to frame
  • PLS2 static data PLS2 data that is static during the duration of a frame group
  • Preamble signaling data signaling data carried by the preamble symbol and used to identify the basic mode of the system
  • Preamble symbol a fixed length pilot symbol carrying basic PLS data and positioned at the beginning of a frame
  • Preamble symbols are primarily used for fast initial band scans to detect system signals, their timings, frequency offsets, and FFT sizes.
  • Superframe set of eight frame repeat units
  • Time interleaving block A set of cells in which time interleaving is performed, corresponding to one use of time interleaver memory.
  • Time interleaving group A unit in which dynamic capacity allocation is performed for a particular data pipe, consisting of an integer, the number of XFECBLOCKs that change dynamically.
  • a time interleaving group can be directly mapped to one frame or mapped to multiple frames.
  • the time interleaving group may include one or more time interleaving blocks.
  • Type 1 DP A data pipe in a frame where all data pipes are mapped to frames in a time division multiplexing (TDM) manner.
  • Type 2 DPs Types of data pipes in a frame where all data pipes are mapped to frames in an FDM fashion.
  • XFECBLOCK set of N cells cells carrying all the bits of one LDPC FECBLOCK
  • FIG. 1 shows a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to an embodiment of the present invention.
  • a broadcast signal transmission apparatus for a next generation broadcast service includes an input format block 1000, a bit interleaved coding & modulation (BICM) block 1010, and a frame building block 1020, orthogonal frequency division multiplexing (OFDM) generation block (OFDM generation block) 1030, and signaling generation block 1040. The operation of each block of the broadcast signal transmission apparatus will be described.
  • BICM bit interleaved coding & modulation
  • OFDM generation block orthogonal frequency division multiplexing
  • signaling generation block 1040 The operation of each block of the broadcast signal transmission apparatus will be described.
  • IP streams / packets and MPEG2-TS are the main input formats and other stream types are treated as general streams.
  • management information is input to control the scheduling and allocation of the corresponding bandwidth for each input stream.
  • One or multiple TS streams, IP streams and / or general stream inputs are allowed at the same time.
  • the input format block 1000 can demultiplex each input stream into one or multiple data pipes to which independent coding and modulation is applied.
  • the data pipe is the basic unit for controlling robustness, which affects the quality of service (QoS).
  • QoS quality of service
  • One or multiple services or service components may be delivered by one data pipe. Detailed operations of the input format block 1000 will be described later.
  • a data pipe is a logical channel at the physical layer that carries service data or related metadata that can carry one or multiple services or service components.
  • the data pipe unit is a basic unit for allocating data cells to data pipes in one frame.
  • parity data is added for error correction and the encoded bit stream is mapped to a complex value constellation symbol.
  • the symbols are interleaved over the specific interleaving depth used for that data pipe.
  • MIMO encoding is performed at BICM block 1010 and additional data paths are added to the output for MIMO transmission. Detailed operations of the BICM block 1010 will be described later.
  • the frame building block 1020 may map data cells of an input data pipe to OFDM solid balls within one frame. After mapping, frequency interleaving is used for frequency domain diversity, in particular to prevent frequency selective fading channels. Detailed operations of the frame building block 1020 will be described later.
  • the OFDM generation block 1030 can apply existing OFDM modulation having a cyclic prefix as the guard interval.
  • a distributed MISO scheme is applied across the transmitter.
  • a peak-to-average power ratio (PAPR) scheme is implemented in the time domain.
  • PAPR peak-to-average power ratio
  • the proposal provides a variety of FFT sizes, guard interval lengths, and sets of corresponding pilot patterns. Detailed operations of the OFDM generation block 1030 will be described later.
  • the signaling generation block 1040 may generate physical layer signaling information used for the operation of each functional block.
  • the signaling information is also transmitted such that the service of interest is properly recovered at the receiver side. Detailed operations of the signaling generation block 1040 will be described later.
  • 2 illustrates an input format block according to an embodiment of the present invention. 2 shows an input format block when the input signal is a single input stream.
  • the input format block illustrated in FIG. 2 corresponds to an embodiment of the input format block 1000 described with reference to FIG. 1.
  • Input to the physical layer may consist of one or multiple data streams. Each data stream is carried by one data pipe.
  • the mode adaptation module slices the input data stream into a data field of a baseband frame (BBF).
  • BBF baseband frame
  • the system supports three types of input data streams: MPEG2-TS, IP, and GS (generic stream).
  • MPEG2-TS features a fixed length (188 bytes) packet where the first byte is a sync byte (0x47).
  • An IP stream consists of variable length IP datagram packets signaled in IP packet headers.
  • the system supports both IPv4 and IPv6 for IP streams.
  • the GS may consist of variable length packets or constant length packets signaled in the encapsulation packet header.
  • (a) shows a mode adaptation block 2000 and a stream adaptation (stream adaptation) 2010 for a signal data pipe
  • PLS generation block 2020 and PLS scrambler 2030 are shown. The operation of each block will be described.
  • the input stream splitter splits the input TS, IP, GS streams into multiple service or service component (audio, video, etc.) streams.
  • the mode adaptation module 2010 is composed of a CRC encoder, a baseband (BB) frame slicer, and a BB frame header insertion block.
  • the CRC encoder provides three types of CRC encoding, CRC-8, CRC-16, and CRC-32, for error detection at the user packet (UP) level.
  • the calculated CRC byte is appended after the UP.
  • CRC-8 is used for the TS stream
  • CRC-32 is used for the IP stream. If the GS stream does not provide CRC encoding, then the proposed CRC encoding should be applied.
  • the BB Frame Slicer maps the input to an internal logical bit format.
  • the first receive bit is defined as MSB.
  • the BB frame slicer allocates the same number of input bits as the available data field capacity. In order to allocate the same number of input bits as the BBF payload, the UP stream is sliced to fit the data field of the BBF.
  • the BB frame header insertion block can insert a 2 bytes fixed length BBF header before the BB frame.
  • the BBF header consists of STUFFI (1 bit), SYNCD (13 bit), and RFU (2 bit).
  • the BBF may have an extension field (1 or 3 bytes) at the end of the 2-byte BBF header.
  • Stream adaptation 2010 consists of a stuffing insertion block and a BB scrambler.
  • the stuffing insertion block may insert the stuffing field into the payload of the BB frame. If the input data for the stream adaptation is sufficient to fill the BB frame, STUFFI is set to 0, and the BBF has no stuffing field. Otherwise, STUFFI is set to 1 and the stuffing field is inserted immediately after the BBF header.
  • the stuffing field includes a 2-byte stuffing field header and variable sized stuffing data.
  • the BB scrambler scrambles the complete BBF for energy dissipation.
  • the scrambling sequence is synchronized with the BBF.
  • the scrambling sequence is generated by the feedback shift register.
  • the PLS generation block 2020 may generate PLS data.
  • PLS provides a means by which a receiver can connect to a physical layer data pipe.
  • PLS data consists of PLS1 data and PLS2 data.
  • PLS1 data is the first set of PLS data delivered to the FSS in frames with fixed size, coding, and modulation that convey basic information about the system as well as the parameters needed to decode the PLS2 data.
  • PLS1 data provides basic transmission parameters including the parameters required to enable reception and decoding of PLS2 data.
  • the PLS1 data is constant during the duration of the frame group.
  • PLS2 data is the second set of PLS data sent to the FSS that carries more detailed PLS data about the data pipes and systems.
  • PLS2 contains parameters that provide enough information for the receiver to decode the desired data pipe.
  • PLS2 signaling further consists of two types of parameters: PLS2 static data (PLS2-STAT data) and PLS2 dynamic data (PLS2-DYN data).
  • PLS2 static data is PLS2 data that is static during the duration of a frame group
  • PLS2 dynamic data is PLS2 data that changes dynamically from frame to frame.
  • the PLS scrambler 2030 may scramble PLS data generated for energy distribution.
  • the aforementioned blocks may be omitted or may be replaced by blocks having similar or identical functions.
  • FIG 3 illustrates an input format block according to another embodiment of the present invention.
  • the input format block illustrated in FIG. 3 corresponds to an embodiment of the input format block 1000 described with reference to FIG. 1.
  • FIG. 3 illustrates a mode adaptation block of an input format block when the input signal corresponds to a multi input stream.
  • a mode adaptation block of an input format block for processing multi input streams may independently process multiple input streams.
  • a mode adaptation block for processing a multi input stream may be an input stream splitter 3000 or an input stream synchro.
  • Each block of the mode adaptation block will be described.
  • Operations of the CRC encoder 3050, the BB frame slicer 3060, and the BB header insertion block 3070 correspond to the operations of the CRC encoder, the BB frame slicer, and the BB header insertion block described with reference to FIG. Is omitted.
  • the input stream splitter 3000 splits the input TS, IP, and GS streams into a plurality of service or service component (audio, video, etc.) streams.
  • the input stream synchronizer 3010 may be called ISSY.
  • ISSY can provide suitable means to ensure constant bit rate (CBR) and constant end-to-end transmission delay for any input data format.
  • CBR constant bit rate
  • ISSY is always used in the case of multiple data pipes carrying TS, and optionally in multiple data pipes carrying GS streams.
  • Compensating delay block 3020 may delay the split TS packet stream following the insertion of ISSY information to allow TS packet recombination mechanisms without requiring additional memory at the receiver. have.
  • the null packet deletion block 3030 is used only for the TS input stream. Some TS input streams or split TS streams may have a large number of null packets present to accommodate variable bit-rate (VBR) services in the CBR TS stream. In this case, to avoid unnecessary transmission overhead, null packets may be acknowledged and not transmitted. At the receiver, the discarded null packet can be reinserted in the exact place it originally existed with reference to the deleted null-packet (DNP) counter inserted in the transmission, ensuring CBR and time stamp (PCR) updates. There is no need.
  • VBR variable bit-rate
  • the header compression block 3040 can provide packet header compression to increase transmission efficiency for the TS or IP input stream. Since the receiver may have a priori information for a particular portion of the header, this known information may be deleted at the transmitter.
  • the receiver may have a priori information about the sync byte configuration (0x47) and the packet length (188 bytes). If the input TS delivers content with only one PID, that is, one service component (video, audio, etc.) or service subcomponent (SVC base layer, SVC enhancement layer, MVC base view, or MVC dependent view) Only, TS packet header compression may (optionally) be applied to the TS. TS packet header compression is optionally used when the input stream is an IP stream. The block may be omitted or replaced with a block having similar or identical functions.
  • FIG. 4 illustrates a BICM block according to an embodiment of the present invention.
  • the BICM block illustrated in FIG. 4 corresponds to an embodiment of the BICM block 1010 described with reference to FIG. 1.
  • the broadcast signal transmission apparatus for the next generation broadcast service may provide a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like.
  • the BICM block according to an embodiment of the present invention can independently process each data pipe by independently applying the SISO, MISO, and MIMO schemes to the data pipes corresponding to the respective data paths.
  • the apparatus for transmitting broadcast signals for the next generation broadcast service according to an embodiment of the present invention may adjust QoS for each service or service component transmitted through each data pipe.
  • the BICM block shared by the base profile and the handheld profile and the BICM block of the advanced profile may include a plurality of processing blocks for processing each data pipe.
  • the processing block 5000 of the BICM block for the base profile and the handheld profile includes a data FEC encoder 5010, a bit interleaver 5020, a constellation mapper 5030, a signal space diversity (SSD) encoding block ( 5040, and a time interleaver 5050.
  • a data FEC encoder 5010 a bit interleaver 5020
  • a constellation mapper 5030 a signal space diversity (SSD) encoding block ( 5040, and a time interleaver 5050.
  • SSD signal space diversity
  • the data FEC encoder 5010 performs FEC encoding on the input BBF to generate the FECBLOCK procedure using outer coding (BCH) and inner coding (LDPC).
  • Outer coding (BCH) is an optional coding method. The detailed operation of the data FEC encoder 5010 will be described later.
  • the bit interleaver 5020 may interleave the output of the data FEC encoder 5010 while providing a structure that can be efficiently realized to achieve optimized performance by a combination of LDPC codes and modulation schemes. The detailed operation of the bit interleaver 5020 will be described later.
  • Constellation mapper 5030 can be QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, NUQ-1024) or non-uniform constellation (NUC-16, NUC-64, NUC-256, NUC-1024)
  • NUQ-64, NUQ-256, NUQ-1024 non-uniform QAM
  • NUC-16, NUC-64, NUC-256, NUC-1024 A constellation point whose power is normalized by modulating each cell word from the bit interleaver 5020 in the base and handheld profiles or the cell word from the cell word demultiplexer 5010-1 in the advanced profile. e l can be provided.
  • the constellation mapping applies only to data pipes. It is observed that NUQ has any shape, while QAM-16 and NUQ have a square shape. If each constellation is rotated by a multiple of 90 degrees, the rotated constellation overlaps exactly with the original. Due to the rotational symmetry characteristic, the real and imaginary components have the same capacity and average power. Both NUQ and N
  • the time interleaver 5050 may operate at the data pipe level.
  • the parameters of time interleaving can be set differently for each data pipe. The specific operation of the time interleaver 5050 will be described later.
  • the processing block 5000-1 of the BICM block for the advanced profile may include a data FEC encoder, a bit interleaver, a constellation mapper, and a time interleaver.
  • the processing block 5000-1 is distinguished from the processing block 5000 in that it further includes a cell word demultiplexer 5010-1 and a MIMO encoding block 5020-1.
  • operations of the data FEC encoder, the bit interleaver, the constellation mapper, and the time interleaver in the processing block 5000-1 may be performed by the data FEC encoder 5010, the bit interleaver 5020, and the constellation mapper 5030. Since this corresponds to the operation of the time interleaver 5050, the description thereof will be omitted.
  • Cell word demultiplexer 5010-1 is used by an advanced profile data pipe to separate a single cell word stream into a dual cell word stream for MIMO processing. A detailed operation of the cell word demultiplexer 5010-1 will be described later.
  • the MIMO encoding block 5020-1 may process the output of the cell word demultiplexer 5010-1 using the MIMO encoding scheme.
  • MIMO encoding scheme is optimized for broadcast signal transmission. MIMO technology is a promising way to gain capacity, but depends on the channel characteristics. Especially for broadcast, the difference in received signal power between two antennas due to different signal propagation characteristics or the strong LOS component of the channel makes it difficult to obtain capacity gains from MIMO.
  • the proposed MIMO encoding scheme overcomes this problem by using phase randomization and rotation based precoding of one of the MIMO output signals.
  • MIMO encoding is intended for a 2x2 MIMO system that requires at least two antennas at both the transmitter and the receiver.
  • Two MIMO encoding modes are defined in this proposal, full-rate spatial multiplexing (FR-SM) and full-rate full-diversity spatial multiplexing (FRFD-SM).
  • FR-SM encoding provides increased capacity with a relatively small complexity increase at the receiver side, while FRFD-SM encoding provides increased capacity and additional diversity gain with a larger complexity increase at the receiver side.
  • the proposed MIMO encoding scheme does not limit the antenna polarity arrangement.
  • MIMO processing is required for the advanced profile frame, which means that all data pipes in the advanced profile frame are processed by the MIMO encoder. MIMO processing is applied at the data pipe level.
  • the pair of constellation mapper outputs, NUQ (e 1, i and e 2, i ), are fed to the input of the MIMO encoder.
  • MIMO encoder output pairs g1, i and g2, i are transmitted by the same carrier k and OFDM symbol l of each transmit antenna.
  • FIG. 5 illustrates a BICM block according to another embodiment of the present invention.
  • the BICM block illustrated in FIG. 5 corresponds to an embodiment of the BICM block 1010 described with reference to FIG. 1.
  • the EAC is part of a frame carrying EAS information data
  • the FIC is a logical channel in a frame carrying mapping information between a service and a corresponding base data pipe. Detailed description of the EAC and FIC will be described later.
  • a BICM block for protecting PLS, EAC, and FIC may include a PLS FEC encoder 6000, a bit interleaver 6010, and a constellation mapper 6020.
  • the PLS FEC encoder 6000 may include a scrambler, a BCH encoding / zero insertion block, an LDPC encoding block, and an LDPC parity puncturing block. Each block of the BICM block will be described.
  • the PLS FEC encoder 6000 may encode scrambled PLS 1/2 data, EAC and FIC sections.
  • the scrambler may scramble PLS1 data and PLS2 data before BCH encoding and shortening and punctured LDPC encoding.
  • the BCH encoding / zero insertion block may perform outer encoding on the scrambled PLS 1/2 data using the shortened BCH code for PLS protection, and insert zero bits after BCH encoding. For PLS1 data only, the output bits of zero insertion can be permutated before LDPC encoding.
  • the LDPC encoding block may encode the output of the BCH encoding / zero insertion block using the LDPC code.
  • C ldpc and parity bits P ldpc are encoded systematically from each zero-inserted PLS information block I ldpc and appended after it.
  • LDPC code parameters for PLS1 and PLS2 are shown in Table 4 below.
  • the LDPC parity puncturing block may perform puncturing on the PLS1 data and the PLS2 data.
  • LDPC parity bits are punctured after LDPC encoding.
  • the LDPC parity bits of PLS2 are punctured after LDPC encoding. These punctured bits are not transmitted.
  • the bit interleaver 6010 may interleave each shortened and punctured PLS1 data and PLS2 data.
  • the constellation mapper 6020 may map bit interleaved PLS1 data and PLS2 data to constellations.
  • FIG. 6 illustrates a frame building block according to an embodiment of the present invention.
  • the frame building block illustrated in FIG. 7 corresponds to an embodiment of the frame building block 1020 described with reference to FIG. 1.
  • the frame building block may include a delay compensation block 7000, a cell mapper 7010, and a frequency interleaver 7020. have. Each block of the frame building block will be described.
  • the delay compensation block 7000 adjusts the timing between the data pipes and the corresponding PLS data to ensure co-time between the data pipes and the corresponding PLS data at the transmitter. have.
  • PLS data is delayed by the data pipe.
  • the delay of the BICM block is mainly due to the time interleaver 5050.
  • In-band signaling data may cause information of the next time interleaving group to be delivered one frame ahead of the data pipe to be signaled.
  • the delay compensation block delays the in-band signaling data accordingly.
  • the cell mapper 7010 may map a PLS, an EAC, an FIC, a data pipe, an auxiliary stream, and a dummy cell to an active carrier of an OFDM symbol in a frame.
  • the basic function of the cell mapper 7010 is to activate the data cells generated by time interleaving for each data pipe, PLS cell, and EAC / FIC cell, if any, corresponding to each OFDM symbol in one frame. (active) mapping to an array of OFDM cells.
  • Service signaling data (such as program specific information (PSI) / SI) may be collected separately and sent by a data pipe.
  • PSI program specific information
  • SI program specific information
  • the frequency interleaver 7020 may randomly interleave data cells received by the cell mapper 7010 to provide frequency diversity.
  • the frequency interleaver 7020 may operate in an OFDM symbol pair consisting of two sequential OFDM symbols using different interleaving seed order to obtain the maximum interleaving gain in a single frame.
  • FIG 7 illustrates an OFDM generation block according to an embodiment of the present invention.
  • the OFDM generation block illustrated in FIG. 7 corresponds to an embodiment of the OFDM generation block 1030 described with reference to FIG. 1.
  • the OFDM generation block modulates the OFDM carrier by inserting a pilot by the cell generated by the frame building block, inserts a pilot, and generates a time domain signal for transmission.
  • the block sequentially inserts a guard interval and applies a PAPR reduction process to generate a final RF signal.
  • the OFDM generation block includes a pilot and reserved tone insertion block (8000), a 2D-single frequency network (eSFN) encoding block 8010, an inverse fast fourier transform (IFFT).
  • Block 8020 PAPR reduction block 8030, guard interval insertion block 8040, preamble insertion block 8050, other system insertion block 8060, and DAC block ( 8070).
  • the other system insertion block 8060 may multiplex signals of a plurality of broadcast transmission / reception systems in a time domain so that data of two or more different broadcast transmission / reception systems providing a broadcast service may be simultaneously transmitted in the same RF signal band.
  • two or more different broadcast transmission / reception systems refer to a system that provides different broadcast services.
  • Different broadcast services may refer to terrestrial broadcast services or mobile broadcast services.
  • FIG. 8 illustrates a structure of a broadcast signal receiving apparatus for a next generation broadcast service according to an embodiment of the present invention.
  • the broadcast signal receiving apparatus for the next generation broadcast service may correspond to the broadcast signal transmitting apparatus for the next generation broadcast service described with reference to FIG. 1.
  • An apparatus for receiving broadcast signals for a next generation broadcast service includes a synchronization & demodulation module 9000, a frame parsing module 9010, a demapping and decoding module a demapping & decoding module 9020, an output processor 9030, and a signaling decoding module 9040. The operation of each module of the broadcast signal receiving apparatus will be described.
  • the synchronization and demodulation module 9000 receives an input signal through m reception antennas, performs signal detection and synchronization on a system corresponding to the broadcast signal receiving apparatus, and performs a reverse process of the procedure performed by the broadcast signal transmitting apparatus. Demodulation can be performed.
  • the frame parsing module 9010 may parse an input signal frame and extract data in which a service selected by a user is transmitted.
  • the frame parsing module 9010 may execute deinterleaving corresponding to the reverse process of interleaving. In this case, positions of signals and data to be extracted are obtained by decoding the data output from the signaling decoding module 9040, so that the scheduling information generated by the broadcast signal transmission apparatus may be restored.
  • the demapping and decoding module 9020 may convert the input signal into bit region data and then deinterleave the bit region data as necessary.
  • the demapping and decoding module 9020 can perform demapping on the mapping applied for transmission efficiency, and correct an error generated in the transmission channel through decoding. In this case, the demapping and decoding module 9020 can obtain transmission parameters necessary for demapping and decoding by decoding the data output from the signaling decoding module 9040.
  • the output processor 9030 may perform a reverse process of various compression / signal processing procedures applied by the broadcast signal transmission apparatus to improve transmission efficiency.
  • the output processor 9030 may obtain necessary control information from the data output from the signaling decoding module 9040.
  • the output of the output processor 8300 corresponds to a signal input to the broadcast signal transmission apparatus and may be MPEG-TS, IP stream (v4 or v6), and GS.
  • the signaling decoding module 9040 may obtain PLS information from the signal demodulated by the synchronization and demodulation module 9000. As described above, the frame parsing module 9010, the demapping and decoding module 9200, and the output processor 9300 may execute the function using data output from the signaling decoding module 9040.
  • FIG. 9 shows a frame structure according to an embodiment of the present invention.
  • FIG. 9 shows a structural example of a frame time and a frame repetition unit (FRU) in a super frame.
  • (a) shows a super frame according to an embodiment of the present invention
  • (b) shows a FRU according to an embodiment of the present invention
  • (c) shows a frame of various physical profile (PHY profile) in the FRU
  • (D) shows the structure of the frame.
  • Super frame may consist of eight FRUs.
  • the FRU is the basic multiplexing unit for the TDM of the frame and is repeated eight times in the super frame.
  • Each frame in the FRU belongs to one of the physical profiles (base, handheld, advanced profile) or FEF.
  • the maximum allowable number of frames in a FRU is 4, and a given physical profile may appear any number of times from 0 to 4 times in the FRU (eg, base, base, handheld, advanced).
  • the physical profile definition may be extended using the reserved value of PHY_PROFILE in the preamble if necessary.
  • the FEF portion is inserted at the end of the FRU if included. If the FEF is included in the FRU, the maximum number of FEFs is 8 in a super frame. It is not recommended that the FEF parts be adjacent to each other.
  • One frame is further separated into multiple OFDM symbols and preambles. As shown in (d), the frame includes a preamble, one or more FSS, normal data symbols, and FES.
  • the preamble is a special symbol that enables fast Futurecast UTB system signal detection and provides a set of basic transmission parameters for efficient transmission and reception of the signal. Details of the preamble will be described later.
  • the main purpose of the FSS is to carry PLS data.
  • the FSS For fast synchronization and channel estimation, and hence for fast decoding of PLS data, the FSS has a higher density pilot pattern than normal data symbols.
  • the FES has a pilot that is exactly the same as the FSS, which allows frequency only interpolation and temporal interpolation within the FES without extrapolation for symbols immediately preceding the FES.
  • FIG. 10 illustrates a signaling hierarchy structure of a frame according to an embodiment of the present invention.
  • PLS 10 shows a signaling hierarchy, which is divided into three main parts: preamble signaling data 11000, PLS1 data 11010, and PLS2 data 11020.
  • the purpose of the preamble carried by the preamble signal every frame is to indicate the basic transmission parameters and transmission type of the frame.
  • PLS1 allows the receiver to access and decode PLS2 data that includes parameters for connecting to the data pipe of interest.
  • PLS2 is delivered every frame and divided into two main parts, PLS2-STAT data and PLS2-DYN data. The static and dynamic parts of the PLS2 data are followed by padding if necessary.
  • FIG 11 illustrates preamble signaling data according to an embodiment of the present invention.
  • the preamble signaling data carries 21 bits of information needed to enable the receiver to access the PLS data and track the data pipes within the frame structure. Details of the preamble signaling data are as follows.
  • PHY_PROFILE This 3-bit field indicates the physical profile type of the current frame. The mapping of different physical profile types is given in Table 5 below.
  • FFT_SIZE This 2-bit field indicates the FFT size of the current frame in the frame group as described in Table 6 below.
  • GI_FRACTION This 3-bit field indicates a guard interval fraction value in the current super frame as described in Table 7 below.
  • EAC_FLAG This 1-bit field indicates whether EAC is provided in the current frame. If this field is set to 1, EAS is provided in the current frame. If this field is set to 0, EAS is not delivered in the current frame. This field may be converted to dynamic within a super frame.
  • PILOT_MODE This 1-bit field indicates whether the pilot mode is a mobile mode or a fixed mode for the current frame in the current frame group. If this field is set to 0, mobile pilot mode is used. If the field is set to '1', fixed pilot mode is used.
  • PAPR_FLAG This 1-bit field indicates whether PAPR reduction is used for the current frame in the current frame group. If this field is set to 1, tone reservation is used for PAPR reduction. If this field is set to 0, no PAPR reduction is used.
  • This 3-bit field indicates the physical profile type configuration of the FRU present in the current super frame. In the corresponding field in all preambles in the current super frame, all profile types carried in the current super frame are identified. The 3-bit field is defined differently for each profile as shown in Table 8 below.
  • PLS1 data provides basic transmission parameters including the parameters needed to enable the reception and decoding of PLS2. As mentioned above, the PLS1 data does not change during the entire duration of one frame group. A detailed definition of the signaling field of the PLS1 data is as follows.
  • PREAMBLE_DATA This 20-bit field is a copy of the preamble signaling data excluding EAC_FLAG.
  • NUM_FRAME_FRU This 2-bit field indicates the number of frames per FRU.
  • PAYLOAD_TYPE This 3-bit field indicates the format of payload data carried in the frame group. PAYLOAD_TYPE is signaled as shown in Table 9.
  • NUM_FSS This 2-bit field indicates the number of FSS in the current frame.
  • SYSTEM_VERSION This 8-bit field indicates the version of the signal format being transmitted. SYSTEM_VERSION is separated into two 4-bit fields: major and minor.
  • the 4-bit MSB in the SYSTEM_VERSION field indicates major version information. Changes in the major version field indicate incompatible changes. The default value is 0000. For the version described in that standard, the value is set to 0000.
  • Minor Version A 4-bit LSB in the SYSTEM_VERSION field indicates minor version information. Changes in the minor version field are compatible.
  • CELL_ID This is a 16-bit field that uniquely identifies a geographic cell in an ATSC network. ATSC cell coverage may consist of one or more frequencies depending on the number of frequencies used per Futurecast UTB system. If the value of CELL_ID is unknown or not specified, this field is set to zero.
  • NETWORK_ID This is a 16-bit field that uniquely identifies the current ATSC network.
  • SYSTEM_ID This 16-bit field uniquely identifies a Futurecast UTB system within an ATSC network.
  • Futurecast UTB systems are terrestrial broadcast systems whose input is one or more input streams (TS, IP, GS) and the output is an RF signal.
  • the Futurecast UTB system conveys the FEF and one or more physical profiles, if present.
  • the same Futurecast UTB system can carry different input streams and use different RFs in different geographic regions, allowing for local service insertion.
  • Frame structure and scheduling are controlled in one place and are the same for all transmissions within a Futurecast UTB system.
  • One or more Futurecast UTB systems may have the same SYSTEM_ID meaning that they all have the same physical structure and configuration.
  • the following loop is composed of FRU_PHY_PROFILE, FRU_FRAME_LENGTH, FRU_GI_FRACTION, and RESERVED indicating the length and FRU configuration of each frame type.
  • the loop size is fixed such that four physical profiles (including FFEs) are signaled within the FRU. If NUM_FRAME_FRU is less than 4, the unused fields are filled with zeros.
  • FRU_PHY_PROFILE This 3-bit field indicates the physical profile type of the (i + 1) th frame (i is a loop index) of the associated FRU. This field uses the same signaling format as shown in Table 8.
  • FRU_FRAME_LENGTH This 2-bit field indicates the length of the (i + 1) th frame of the associated FRU. Using FRU_FRAME_LENGTH with FRU_GI_FRACTION, the exact value of frame duration can be obtained.
  • FRU_GI_FRACTION This 3-bit field indicates the guard interval partial value of the (i + 1) th frame of the associated FRU.
  • FRU_GI_FRACTION is signaled according to Table 7.
  • the following fields provide parameters for decoding PLS2 data.
  • PLS2_FEC_TYPE This 2-bit field indicates the FEC type used by the PLS2 protection.
  • the FEC type is signaled according to Table 10. Details of the LDPC code will be described later.
  • PLS2_MOD This 3-bit field indicates the modulation type used by PLS2.
  • the modulation type is signaled according to Table 11.
  • PLS2_SIZE_CELL This 15-bit field indicates C total_partial_block which is the size (specified by the number of QAM cells) of all coding blocks for PLS2 carried in the current frame group . This value is constant for the entire duration of the current frame-group.
  • PLS2_STAT_SIZE_BIT This 14-bit field indicates the size, in bits, of the PLS2-STAT for the current frame-group. This value is constant for the entire duration of the current frame-group.
  • PLS2_DYN_SIZE_BIT This 14-bit field indicates the size, in bits, of the PLS2-DYN for the current frame-group. This value is constant for the entire duration of the current frame-group.
  • PLS2_REP_FLAG This 1-bit flag indicates whether the PLS2 repeat mode is used in the current frame group. If the value of this field is set to 1, PLS2 repeat mode is activated. If the value of this field is set to 0, PLS2 repeat mode is deactivated.
  • PLS2_REP_SIZE_CELL This 15-bit field indicates C total_partial_block , which is the size (specified by the number of QAM cells) of the partial coding block for PLS2 delivered every frame of the current frame group when PLS2 repetition is used. If iteration is not used, the value of this field is equal to zero. This value is constant for the entire duration of the current frame-group.
  • PLS2_NEXT_FEC_TYPE This 2-bit field indicates the FEC type used for PLS2 delivered in every frame of the next frame-group.
  • the FEC type is signaled according to Table 10.
  • PLS2_NEXT_MOD This 3-bit field indicates the modulation type used for PLS2 delivered in every frame of the next frame-group.
  • the modulation type is signaled according to Table 11.
  • PLS2_NEXT_REP_FLAG This 1-bit flag indicates whether the PLS2 repeat mode is used in the next frame group. If the value of this field is set to 1, PLS2 repeat mode is activated. If the value of this field is set to 0, PLS2 repeat mode is deactivated.
  • PLS2_NEXT_REP_SIZE_CELL This 15-bit field indicates C total_full_block , which is the size (specified in the number of QAM cells) of the entire coding block for PLS2 delivered every frame of the next frame-group when PLS2 repetition is used. If iteration is not used in the next frame-group, the value of this field is equal to zero. This value is constant for the entire duration of the current frame-group.
  • PLS2_NEXT_REP_STAT_SIZE_BIT This 14-bit field indicates the size, in bits, of the PLS2-STAT for the next frame-group. The value is constant in the current frame group.
  • PLS2_NEXT_REP_DYN_SIZE_BIT This 14-bit field indicates the size of the PLS2-DYN for the next frame-group, in bits. The value is constant in the current frame group.
  • PLS2_AP_MODE This 2-bit field indicates whether additional parity is provided for PLS2 in the current frame group. This value is constant for the entire duration of the current frame-group. Table 12 below provides the values for this field. If the value of this field is set to 00, no additional parity is used for PLS2 in the current frame group.
  • PLS2_AP_SIZE_CELL This 15-bit field indicates the size (specified by the number of QAM cells) of additional parity bits of PLS2. This value is constant for the entire duration of the current frame-group.
  • PLS2_NEXT_AP_MODE This 2-bit field indicates whether additional parity is provided for PLS2 signaling for every frame of the next frame-group. This value is constant for the entire duration of the current frame-group. Table 12 defines the values of this field.
  • PLS2_NEXT_AP_SIZE_CELL This 15-bit field indicates the size (specified by the number of QAM cells) of additional parity bits of PLS2 for every frame of the next frame-group. This value is constant for the entire duration of the current frame-group.
  • RESERVED This 32-bit field is reserved for future use.
  • FIG 13 illustrates PLS2 data according to an embodiment of the present invention.
  • PLS2-STAT data of the PLS2 data.
  • PLS2-STAT data is the same within a frame group, while PLS2-DYN data provides specific information about the current frame.
  • FIC_FLAG This 1-bit field indicates whether the FIC is used in the current frame group. If the value of this field is set to 1, the FIC is provided in the current frame. If the value of this field is set to 0, FIC is not delivered in the current frame. This value is constant for the entire duration of the current frame-group.
  • AUX_FLAG This 1-bit field indicates whether the auxiliary stream is used in the current frame group. If the value of this field is set to 1, the auxiliary stream is provided in the current frame. If the value of this field is set to 0, the auxiliary frame is not transmitted in the current frame. This value is constant for the entire duration of the current frame-group.
  • NUM_DP This 6-bit field indicates the number of data pipes carried in the current frame. The value of this field is between 1 and 64, and the number of data pipes is NUM_DP + 1.
  • DP_ID This 6-bit field uniquely identifies within the physical profile.
  • DP_TYPE This 3-bit field indicates the type of data pipe. This is signaled according to Table 13 below.
  • DP_GROUP_ID This 8-bit field identifies the data pipe group with which the current data pipe is associated. This can be used to connect to the data pipe of the service component associated with a particular service that the receiver will have the same DP_GROUP_ID.
  • BASE_DP_ID This 6-bit field indicates a data pipe that carries service signaling data (such as PSI / SI) used in the management layer.
  • the data pipe indicated by BASE_DP_ID may be a normal data pipe for delivering service signaling data together with service data or a dedicated data pipe for delivering only service signaling data.
  • DP_FEC_TYPE This 2-bit field indicates the FEC type used by the associated data pipe.
  • the FEC type is signaled according to Table 14 below.
  • DP_COD This 4-bit field indicates the code rate used by the associated data pipe.
  • the code rate is signaled according to Table 15 below.
  • DP_MOD This 4-bit field indicates the modulation used by the associated data pipe. Modulation is signaled according to Table 16 below.
  • DP_SSD_FLAG This 1-bit field indicates whether the SSD mode is used in the associated data pipe. If the value of this field is set to 1, the SSD is used. If the value of this field is set to 0, the SSD is not used.
  • DP_MIMO This 3-bit field indicates what type of MIMO encoding processing is applied to the associated data pipe.
  • the type of MIMO encoding process is signaled according to Table 17 below.
  • DP_TI_TYPE This 1-bit field indicates the type of time interleaving. A value of 0 indicates that one time interleaving group corresponds to one frame and includes one or more time interleaving blocks. A value of 1 indicates that one time interleaving group is delivered in more than one frame and contains only one time interleaving block.
  • DP_TI_LENGTH The use of this 2-bit field (only allowed values are 1, 2, 4, 8) is determined by the value set in the DP_TI_TYPE field as follows.
  • N TI the number of time interleaving block per time interleaving group
  • This 2-bit field represents the frame interval (I JUMP ) within the frame group for the associated data pipe, and allowed values are 1, 2, 4, 8 (the corresponding 2-bit fields are 00, 01, 10, 11). For data pipes that do not appear in every frame of a frame group, the value of this field is equal to the interval between sequential frames. For example, if a data pipe appears in frames 1, 5, 9, 13, etc., the value of this field is set to 4. For data pipes that appear in every frame, the value of this field is set to 1.
  • DP_TI_BYPASS This 1-bit field determines the availability of time interleaver 5050. If time interleaving is not used for the data pipe, this field value is set to 1. On the other hand, if time interleaving is used, the corresponding field value is set to zero.
  • DP_FIRST_FRAME_IDX This 5-bit field indicates the index of the first frame of the super frame in which the current data pipe occurs.
  • the value of DP_FIRST_FRAME_IDX is between 0 and 31.
  • DP_NUM_BLOCK_MAX This 10-bit field indicates the maximum value of DP_NUM_BLOCKS for the data pipe. The value of this field has the same range as DP_NUM_BLOCKS.
  • DP_PAYLOAD_TYPE This 2-bit field indicates the type of payload data carried by a given data pipe. DP_PAYLOAD_TYPE is signaled according to Table 19 below.
  • DP_INBAND_MODE This 2-bit field indicates whether the current data pipe carries in-band signaling information. In-band signaling type is signaled according to Table 20 below.
  • DP_PROTOCOL_TYPE This 2-bit field indicates the protocol type of the payload carried by the given data pipe.
  • the protocol type of payload is signaled according to Table 21 below when the input payload type is selected.
  • DP_CRC_MODE This 2-bit field indicates whether CRC encoding is used in the input format block. CRC mode is signaled according to Table 22 below.
  • DNP_MODE This 2-bit field indicates the null packet deletion mode used by the associated data pipe when DP_PAYLOAD_TYPE is set to TS ('00'). DNP_MODE is signaled according to Table 23 below. If DP_PAYLOAD_TYPE is not TS ('00'), DNP_MODE is set to a value of 00.
  • ISSY_MODE This 2-bit field indicates the ISSY mode used by the associated data pipe when DP_PAYLOAD_TYPE is set to TS ('00'). ISSY_MODE is signaled according to Table 24 below. If DP_PAYLOAD_TYPE is not TS ('00'), ISSY_MODE is set to a value of 00.
  • HC_MODE_TS This 2-bit field indicates the TS header compression mode used by the associated data pipe when DP_PAYLOAD_TYPE is set to TS ('00'). HC_MODE_TS is signaled according to Table 25 below.
  • HC_MODE_IP This 2-bit field indicates the IP header compression mode when DP_PAYLOAD_TYPE is set to IP ('01'). HC_MODE_IP is signaled according to Table 26 below.
  • PID This 13-bit field indicates the number of PIDs for TS header compression when DP_PAYLOAD_TYPE is set to TS ('00') and HC_MODE_TS is set to 01 or 10.
  • FIC_VERSION This 8-bit field indicates the version number of the FIC.
  • FIC_LENGTH_BYTE This 13-bit field indicates the length of the FIC in bytes.
  • NUM_AUX This 4-bit field indicates the number of auxiliary streams. Zero indicates that no auxiliary stream is used.
  • AUX_CONFIG_RFU This 8-bit field is reserved for future use.
  • AUX_STREAM_TYPE This 4 bits is reserved for future use to indicate the type of the current auxiliary stream.
  • AUX_PRIVATE_CONFIG This 28-bit field is reserved for future use for signaling the secondary stream.
  • FIG 14 illustrates PLS2 data according to another embodiment of the present invention.
  • the value of the PLS2-DYN data may change during the duration of one frame group, while the size of the field is constant.
  • FRAME_INDEX This 5-bit field indicates the frame index of the current frame within the super frame. The index of the first frame of the super frame is set to zero.
  • PLS_CHANGE_COUNTER This 4-bit field indicates the number of super frames before the configuration changes. The next super frame whose configuration changes is indicated by the value signaled in that field. If the value of this field is set to 0000, this means that no scheduled change is expected. For example, a value of 1 indicates that there is a change in the next super frame.
  • FIC_CHANGE_COUNTER This 4-bit field indicates the number of super frames before the configuration (i.e., the content of the FIC) changes. The next super frame whose configuration changes is indicated by the value signaled in that field. If the value of this field is set to 0000, this means that no scheduled change is expected. For example, a value of 0001 indicates that there is a change in the next super frame.
  • NUM_DP NUM_DP that describes the parameters related to the data pipe carried in the current frame.
  • DP_ID This 6-bit field uniquely represents a data pipe within the physical profile.
  • DP_START This 15-bit (or 13-bit) field indicates the first starting position of the data pipe using the DPU addressing technique.
  • the DP_START field has a length different according to the physical profile and the FFT size as shown in Table 27 below.
  • DP_NUM_BLOCK This 10-bit field indicates the number of FEC blocks in the current time interleaving group for the current data pipe.
  • the value of DP_NUM_BLOCK is between 0 and 1023.
  • the next field indicates the FIC parameter associated with the EAC.
  • EAC_FLAG This 1-bit field indicates the presence of an EAC in the current frame. This bit is equal to EAC_FLAG in the preamble.
  • EAS_WAKE_UP_VERSION_NUM This 8-bit field indicates the version number of the automatic activation indication.
  • EAC_FLAG field If the EAC_FLAG field is equal to 1, the next 12 bits are allocated to the EAC_LENGTH_BYTE field. If the EAC_FLAG field is equal to 0, the next 12 bits are allocated to EAC_COUNTER.
  • EAC_LENGTH_BYTE This 12-bit field indicates the length of the EAC in bytes.
  • EAC_COUNTER This 12-bit field indicates the number of frames before the frame in which the EAC arrives.
  • AUX_PRIVATE_DYN This 48-bit field is reserved for future use for signaling the secondary stream. The meaning of this field depends on the value of AUX_STREAM_TYPE in configurable PLS2-STAT.
  • CRC_32 32-bit error detection code that applies to the entire PLS2.
  • FIG. 15 illustrates a logical structure of a frame according to an embodiment of the present invention.
  • the PLS, EAC, FIC, data pipe, auxiliary stream, and dummy cell are mapped to the active carrier of the OFDM symbol in the frame.
  • PLS1 and PLS2 are initially mapped to one or more FSS. Then, if there is an EAC, the EAC cell is mapped to the immediately following PLS field. If there is an FIC next, the FIC cell is mapped.
  • the data pipes are mapped after the PLS or, if present, after the EAC or FIC. Type 1 data pipes are mapped first, and type 2 data pipes are mapped next. Details of the type of data pipe will be described later. In some cases, the data pipe may carry some special data or service signaling data for the EAS.
  • auxiliary stream or stream if present, is mapped to the data pipe next, followed by a dummy cell in turn. Mapping all together in the order described above, namely PLS, EAC, FIC, data pipe, auxiliary stream, and dummy cell, will correctly fill the cell capacity in the frame.
  • FIG 16 illustrates PLS mapping according to an embodiment of the present invention.
  • the PLS cell is mapped to an active carrier of the FSS. According to the number of cells occupied by the PLS, one or more symbols are designated as FSS, and the number N FSS of the FSS is signaled by NUM_FSS in PLS1.
  • FSS is a special symbol that carries a PLS cell. Since alertness and latency are critical issues in PLS, the FSS has a high pilot density, enabling fast synchronization and interpolation only on frequencies within the FSS.
  • the PLS cell is mapped to an active carrier of the FSS from the top down as shown in the example of FIG.
  • PLS1 cells are initially mapped in ascending order of cell index from the first cell of the first FSS.
  • the PLS2 cell follows immediately after the last cell of PLS1 and the mapping continues downward until the last cell index of the first FSS. If the total number of required PLS cells exceeds the number of active carriers of one FSS, the mapping proceeds to the next FSS and continues in exactly the same way as the first FSS.
  • EAC, FIC or both are present in the current frame, EAC and FIC are placed between the PLS and the normal data pipe.
  • FIG 17 illustrates EAC mapping according to an embodiment of the present invention.
  • the EAC is a dedicated channel for delivering EAS messages and is connected to the data pipes for the EAS. EAS support is provided, but the EAC itself may or may not be present in every frame. If there is an EAC, the EAC is mapped immediately after the PLS2 cell. Except for PLS cells, none of the FIC, data pipes, auxiliary streams or dummy cells are located before the EAC. The mapping procedure of the EAC cell is exactly the same as that of the PLS.
  • EAC cells are mapped in ascending order of cell index from the next cell of PLS2 as shown in the example of FIG. Depending on the EAS message size, as shown in FIG. 17, the EAC cell may occupy few symbols.
  • the EAC cell follows immediately after the last cell of PLS2 and the mapping continues downward until the last cell index of the last FSS. If the total number of required EAC cells exceeds the number of remaining active carriers of the last FSS, the EAC mapping proceeds to the next symbol and continues in exactly the same way as the FSS. In this case, the next symbol to which the EAC is mapped is a normal data symbol, which has more active carriers than the FSS.
  • the FIC is passed next if present. If no FIC is sent (as signaling in the PLS2 field), the data pipe follows immediately after the last cell of the EAC.
  • FIC is a dedicated channel that carries cross-layer information to enable fast service acquisition and channel scan.
  • the information mainly includes channel binding information between data pipes and services of each broadcaster.
  • the receiver can decode the FIC and obtain information such as broadcaster ID, number of services, and BASE_DP_ID.
  • BASE_DP_ID For high-speed service acquisition, not only the FIC but also the base data pipe can be decoded using BASE_DP_ID. Except for the content that the base data pipe transmits, the base data pipe is encoded and mapped to the frame in exactly the same way as a normal data pipe. Thus, no further explanation of the base data pipe is needed.
  • FIC data is generated and consumed at the management layer. The content of the FIC data is as described in the management layer specification.
  • FIC data is optional and the use of FIC is signaled by the FIC_FLAG parameter in the static part of the PLS2. If FIC is used, FIC_FLAG is set to 1 and the signaling field for FIC is defined in the static part of PLS2. Signaled in this field is FIC_VERSION, FIC_LENGTH_BYTE. FIC uses the same modulation, coding, and time interleaving parameters as PLS2. The FIC shares the same signaling parameters as PLS2_MOD and PLS2_FEC. FIC data is mapped after PLS2 if present, or immediately after EAC if EAC is present. None of the normal data pipes, auxiliary streams, or dummy cells are located before the FIC. The method of mapping the FIC cells is exactly the same as the EAC, which in turn is identical to the PLS.
  • the FIC cells are mapped in ascending order of cell index from the next cell of PLS2 as shown in the example of (a).
  • FIC cells are mapped for several symbols.
  • the FIC cell follows immediately after the last cell of PLS2 and the mapping continues downward until the last cell index of the last FSS. If the total number of required FIC cells exceeds the number of remaining active carriers of the last FSS, the mapping of the remaining FIC cells proceeds to the next symbol, which continues in exactly the same way as the FSS. In this case, the next symbol to which the FIC is mapped is a normal data symbol, which has more active carriers than the FSS.
  • the EAC is mapped before the FIC and the FIC cells are mapped in ascending order of cell index from the next cell of the EAC as shown in (b).
  • one or more data pipes are mapped, followed by auxiliary streams and dummy cells if present.
  • FIG 19 shows an FEC structure according to an embodiment of the present invention.
  • the data FEC encoder may perform FEC encoding on the input BBF to generate the FECBLOCK procedure using outer coding (BCH) and inner coding (LDPC).
  • BCH outer coding
  • LDPC inner coding
  • the illustrated FEC structure corresponds to FECBLOCK.
  • the FECBLOCK and FEC structures have the same value corresponding to the length of the LDPC codeword.
  • N ldpc 64800 bits (long FECBLOCK) or 16200 bits (short FECBLOCK).
  • Tables 28 and 29 below show the FEC encoding parameters for the long FECBLOCK and the short FECBLOCK, respectively.
  • a 12-error correcting BCH code is used for the outer encoding of the BBF.
  • the BBF-generated polynomials for short FECBLOCK and long FECBLOCK are obtained by multiplying all polynomials.
  • LDPC codes are used to encode the output of the outer BCH encoding.
  • ldpc P parity bits
  • I ldpc - is systematically encoded from the (BCH encoded BBF), it is attached to the I ldpc.
  • the finished B ldpc (FECBLOCK) is expressed by the following equation.
  • N ldpc for long FECBLOCK - specific procedures for calculating the K ldpc parity bits is as follows.
  • x represents the address of the parity bit accumulator corresponding to the first bit i 0
  • Q ldpc is a code rate dependent constant specified in the address of the parity check matrix.
  • Equation 6 x represents the address of the parity bit accumulator corresponding to information bit i 360 , that is, the entry of the second row of the parity check matrix.
  • the final parity bits are obtained as follows.
  • the corresponding LDPC encoding procedure for short FECBLOCK is t LDPC for long FECBLOCK.
  • the time interleaver operates at the data pipe level.
  • the parameters of time interleaving can be set differently for each data pipe.
  • DP_TI_TYPE (allowed values: 0 or 1): Represents the time interleaving mode.
  • 0 indicates a mode with multiple time interleaving blocks (one or more time interleaving blocks) per time interleaving group. In this case, one time interleaving group is directly mapped to one frame (without interframe interleaving).
  • 1 indicates a mode having only one time interleaving block per time interleaving group. In this case, the time interleaving block is spread over one or more frames (interframe interleaving).
  • DP_NUM_BLOCK_MAX (allowed values: 0 to 1023): Represents the maximum number of XFECBLOCKs per time interleaving group.
  • DP_FRAME_INTERVAL (allowed values: 1, 2, 4, 8): Represents the number of frames I JUMP between two sequential frames carrying the same data pipe of a given physical profile.
  • DP_TI_BYPASS (allowed values: 0 or 1): If time interleaving is not used for the data frame, this parameter is set to one. If time interleaving is used, it is set to zero.
  • the parameter DP_NUM_BLOCK from the PLS2-DYN data indicates the number of XFECBLOCKs carried by one time interleaving group of the data group.
  • each time interleaving group is a set of integer number of XFECBLOCKs, and will contain a dynamically varying number of XFECBLOCKs.
  • N xBLOCK_Group (n) The number of XFECBLOCKs in the time interleaving group at index n is represented by N xBLOCK_Group (n) and signaled as DP_NUM_BLOCK in the PLS2-DYN data.
  • N xBLOCK_Group (n) may vary from the minimum value 0 to the maximum value N xBLOCK_Group_MAX (corresponding to DP_NUM_BLOCK_MAX ) having the largest value 1023.
  • Each time interleaving group is either mapped directly to one frame or spread over P I frames.
  • Each time interleaving group is further divided into one or more (N TI ) time interleaving blocks.
  • each time interleaving block corresponds to one use of the time interleaver memory.
  • the time interleaving block in the time interleaving group may include some other number of XFECBLOCKs. If the time interleaving group is divided into multiple time interleaving blocks, the time interleaving group is directly mapped to only one frame. As shown in Table 32 below, there are three options for time interleaving (except for the additional option of omitting time interleaving).
  • the time interleaver will also act as a buffer for the data pipe data before the frame generation process. This is accomplished with two memory banks for each data pipe.
  • the first time interleaving block is written to the first bank.
  • the second time interleaving block is written to the second bank while reading from the first bank.
  • Time interleaving is a twisted row-column block interleaver.
  • the number of columns N c is equal to N xBLOCK_TI (n, s)
  • 21 illustrates the basic operation of a twisted row-column block interleaver according to an embodiment of the present invention.
  • Fig. 21A shows a write operation in the time interleaver
  • Fig. 21B shows a read operation in the time interleaver.
  • the first XFECBLOCK is written in the column direction to the first column of the time interleaving memory
  • the second XFECBLOCK is written to the next column, followed by this operation.
  • the cells are read diagonally.
  • Cells are read. Specifically, Assuming that this is a time interleaving memory cell position to be read sequentially, the read operation in this interleaving array is a row index as in the equation below. Column index Related twist parameters Is executed by calculating.
  • the cell position to be read is coordinate Calculated by
  • FIG. 22 illustrates an operation of a twisted row-column block interleaver according to another embodiment of the present invention.
  • FIG. 22 Denotes an interleaving array in the time interleaving memory for each time interleaving group including the virtual XFECBLOCK.
  • the interleaving array for twisted row-column block interleaver inserts a virtual XFECBLOCK into the time interleaving memory. It is set to the size of, and the reading process is made as follows.
  • the number of time interleaving groups is set to three.
  • the maximum number of XFECBLOCKs is signaled in PLS2-STAT data by NxBLOCK_Group_MAX, which Leads to.
  • Figure 23 illustrates a diagonal read pattern of a twisted row-column block interleaver according to one embodiment of the present invention.
  • FIG. 25 is a diagram illustrating an enhanced television (TV) service system based on automatic content recognition.
  • the automatic content recognition based ETV service system illustrated in FIG. 25 includes a broadcaster or a content provider 100, a multi-channel broadcaster 101, a set-top box 102, a receiver 103 such as a digital TV receiver, an automatic content recognition server (or Automatic content recognition solution provider) 104.
  • the receiver 103 may operate according to the definition of an advanced television system committee (ATSC) and may support an automatic content recognition function.
  • the real time broadcast service 110 may include audio / video content.
  • the digital broadcasting service may be classified into a terrestrial broadcasting service provided by the broadcaster 100 and a multichannel broadcasting service such as cable broadcasting or satellite broadcasting provided by the multichannel broadcasting service provider 101.
  • the broadcaster 100 may transmit the real time broadcast service 110 and the enhancement data (or additional data) 120 together.
  • the receiver 103 may receive only the real-time broadcast service 110 through the multi-channel broadcaster 101 and the set-top box 102, and the enhancement data 120 may be You may not receive it.
  • the receiver 103 analyzes and processes the audio / video content output with the real-time broadcast service 110, and confirms broadcast program information and / or broadcast program related metadata. do. Using the confirmed broadcast program information and / or broadcast program related metadata, the receiver 103 may receive the enhancement data from the broadcaster 100 or the automatic content recognition server 104 (140). In this case, the enhancement data may be transmitted via the Internet protocol network 150.
  • TDO triggered declarative object
  • TDO represents additional information included in broadcast content.
  • the TDO serves to timely trigger additional information in broadcast content.
  • the additional information of the current ranking of the audition participant may be a TDO.
  • This TDO may be changed through interaction with the viewer, or may be provided according to the viewer's intention.
  • the digital broadcast receiver 103 In the request / response automatic content recognition model of standard ATSC 2.0, the digital broadcast receiver 103 generates a signature of the content periodically (e.g. every 5 seconds) and sends a request containing the signature to the automatic content recognition server. It is supposed to transmit to 104. The automatic content recognition server 104 returns a response upon receiving the request from the digital broadcast receiver 103. The communication session is not open between the request and the response. In this model, automatic content recognition server 104 may not initiate a message to the client.
  • Interactive data broadcasting a typical interactive service, may transmit not only data signals but also existing broadcast signals to subscribers in order to provide various additional services.
  • Digital data broadcasting can be largely classified into a standalone service using a virtual channel and a broadcast related service through an ETV.
  • the standalone service includes only text and graphics without a broadcast image signal and is provided in a format similar to existing Internet web pages.
  • Typical examples of standalone services include weather and stock information services, TV financial services, and commerce services.
  • the broadcast related service transmits additional text and graphic information as well as broadcast image signals. The viewer may obtain information related to the broadcast program watched through the broadcast related service. For example, there is a service that allows viewers to see previous stories or locations while watching a drama.
  • an ETV service may be provided based on automatic content recognition technology.
  • Automatic content recognition refers to a technology that automatically recognizes content through information hidden in the content when the device plays audio / video content.
  • watermarking or fingerprint printing may be used to obtain information about the content.
  • Watermarking refers to a technique for inserting information representing digital content providers into digital content. Fingerprinting is the same as watermarking in that specific information is inserted into digital content, but watermarking differs in that information about a content purchaser is inserted instead of information about a content provider.
  • FIG. 26 illustrates a flow of digital watermarking technology according to an embodiment of the present invention.
  • Interactive data broadcasting a typical interactive service, may transmit not only data signals but also existing broadcast signals to subscribers in order to provide various additional services.
  • Digital data broadcasting can be largely classified into a standalone service using a virtual channel and a broadcast related service through an ETV.
  • the standalone service includes only text and graphics without a broadcast image signal and is provided in a format similar to existing Internet web pages.
  • Typical examples of standalone services include weather and stock information services, TV financial services, and commerce services.
  • the broadcast related service transmits additional text and graphic information as well as broadcast image signals. The viewer may obtain information related to the broadcast program watched through the broadcast related service. For example, there is a service that allows viewers to see previous stories or locations while watching a drama.
  • an ETV service may be provided based on automatic content recognition technology.
  • Automatic content recognition refers to a technology that automatically recognizes content through information hidden in the content when the device plays audio / video content.
  • watermarking or fingerprinting may be used to obtain information about content.
  • Watermarking refers to a technique for inserting information representing digital content providers into digital content. Fingerprinting is the same as watermarking in that specific information is inserted into digital content, but watermarking differs in that information about a content purchaser is inserted instead of information about a content provider.
  • Digital watermarking is the process of embedding information in digital signals in a way that is difficult to remove.
  • the signal can be voice, picture, or video.
  • information is also carried in the duplicated signal.
  • One signal can carry several different watermarks at the same time.
  • the information is visible on the screen or in the image.
  • the information is text or a logo that identifies the owner of the media. If a TV broadcaster adds a logo to the corner of the video being sent, this is also a visual watermark.
  • non-visual watermarking the information is added to the voice, picture, or video as digital data, although it can be perceived that some information is hidden, but not per se.
  • Watermarks are intended to be widely used and may be easy to search, or may be in the form of steganography in which an organization sends and receives secret messages embedded in digital signals. In either case, as in visual watermarking, the goal is to attach to the signal in a way that is difficult to remove the owner or other descriptive information.
  • Hidden landfill information may also be used as a means to divert communication between individuals.
  • watermarking is in copyright protection systems for preventing or preventing unauthorized copying of digital media.
  • the copying apparatus retrieves the watermark from the signal before copying, and determines whether to copy according to the content of the watermark.
  • Another application is in source tracking.
  • the watermark is embedded in the digital signal at each distribution. If a copy of the work is found later, the watermark can be retrieved from the copy and the source of the distribution is known. Reportedly, the technique has been used to determine the source of illegally copied movies.
  • Annotation of digital photography with descriptive information is another application of nonvisual watermarking.
  • digital watermarking is distinguished in that the data is carried in the signal itself.
  • digital watermark refers to the difference between a watermarked signal and a cover signal
  • the information to be embedded is called a digital watermark.
  • the signal to which the watermark is embedded is called a host signal.
  • the watermarking system is mainly divided into three distinct stages: landfill 201, attack 202, and detection (or extraction) 203.
  • the algorithm accepts the host and the data to be embedded and generates a watermarked signal.
  • Watermarked signals are transmitted or stored, often to others. If this person makes a change, it is called an attack 202. While the change may not be malicious, the term attack comes from copyright protection applications where copyright infringers attempt to remove digital watermarks through change. Various changes may be possible. For example, there may be irreversible compression of data, cropping of an image or image, or noise intentionally applied.
  • Detection 203 is an algorithm applied to the attacked signal to extract a watermark from the attacked signal. If the signal did not change during transmission, the watermark is still present and can be extracted. In a robust watermarking application, even if the change is strong, the extraction algorithm will be able to generate the watermark correctly. In vulnerable watermarking, the extraction algorithm will fail no matter what changes are made to the signal.
  • the digital watermark is said to be robust against deformation if the embedded information can be reliably detected from the marked signal even if it is degraded by several modifications. Typical image degradation is JPEG compression, rotation, cropping, additional noise and quantization. In video content, temporary changes and MPEG compression are mainly included. If the watermarked content is perceptually equivalent to the original non-watermarked content, the watermark cannot be detected. In general, it is known that a solid watermark or an undetectable watermark is easy to generate, but a hard and undetectable watermark is difficult to generate. Solid and undetectable watermarks have been proposed as tools for the protection of digital content, such as "non-replicating" flags embedded in professional video content.
  • Digital watermarking techniques can be classified in several ways.
  • watermarks are said to be vulnerable if they are not detected after some modification (solidity).
  • Weak watermarks are commonly used for tamper detection (prove integrity).
  • the modifications made to the apparent original work are usually not called watermarks, but generalized barcodes.
  • Watermarks that are resistant to benign deformation but fail to detect after malignant deformation are slightly vulnerable. Slightly vulnerable watermarks are usually used to detect malicious modifications.
  • Watermarks that are resistant to a given class of deformation are said to be robust. Robust watermarks can be used in copy protection applications to deliver duplicates and access control information.
  • the watermark cannot be detected (perceptual) unless the original cover signal and the marked signal are perceptually distinct (different). If the presence in the marked signal is clear but noninvasive, the watermark is said to be detectable.
  • the length of the embedded message determines two different main classes of watermarking schemes.
  • the message is conceptually 0 bits long, and the system is designed to detect the presence or absence of a watermark in the marked object.
  • This kind of watermarking method is mainly called italic zero bit or italic existence watermarking method. Often this kind of watermarking scheme is called a 1-bit watermark because 1 indicates the presence of a watermark (0 is absent).
  • or M ⁇ 0,1 ⁇ n) and is modulated in the watermark.
  • This kind of approach is often referred to as multi-bit watermarking or non-zero bit watermarking.
  • the watermarking method is called spread spectrum.
  • Spread spectrum watermarks are known to be reasonably robust, but are also known to have low information capacity due to host interference.
  • the watermarking method is said to be of quantization type. Quantization watermarks have low robustness but high information capacity due to the exclusion of host interference.
  • the marked signal is buried by an additional variation similar to the spread spectrum method but especially embedded in the spatial domain, the watermarking method is called amplitude modulation.
  • FIG. 27 is a diagram illustrating an ACR query result format according to an embodiment of the present invention.
  • the TV receiver may receive content for real time service through a multi-channel broadcaster and receive enhancement data through an independent internet protocol signaling channel.
  • the Internet protocol signaling channel is configured such that the PSIP stream is delivered and processed in the form of a binary stream.
  • the Internet protocol signaling channel is configured to use a pull method or a push method.
  • the pull protocol internet protocol channel may be configured according to the HTTP request / response method.
  • the PSIP binary stream may be included in the HTTP response signal for the HTTP request signal and transmitted through SignalingChannelURL.
  • the polling cycle may be requested periodically according to Polling_cycle in the metadata delivered as a result of the automatic content aware query.
  • information related to the time and / or period to be updated may be included in the signaling channel and transmitted.
  • the receiver may request signaling information from the server based on the update time and / or period information received from the internet protocol signaling channel.
  • the internet protocol signaling channel of the push method may be configured using the XMLHTTPRequest application programming interface.
  • the XMLHTTPRequest application programming interface can be used to asynchronously receive the latest information from the server. This is a method of requesting signaling information to the server aperiodically through an XMLHTTPRequest object on the receiver side, and a method of providing signaling information through this channel in response to the request if the signaling information is changed on the server side. If there is a limit on the latency of the session, a session timeout response may be generated, and the receiver may recognize the session timeout response, request signaling information again, and maintain a signaling channel between the receiver and the server.
  • the receiver can operate using watermarking and fingerprinting. Fingerprinting refers to a technique for inserting information about a content purchaser into the content on behalf of the content provider. If fingerprinting is used, the receiver can search the reference database to verify the content. The result of checking the content is called an automatic content recognition query result.
  • the automatic content recognition query result may include a query provided to the TV viewer, and may correspond to the information in the query to execute the automatic content recognition function.
  • the receiver may provide an ETV service based on an automatic content recognition query result.
  • the information regarding the result of the automatic content recognition query may be inserted / embedded in the audio / video content and transmitted on the watermark based automatic content recognition system.
  • the receiver may provide the ETV service after extracting and obtaining the automatic content recognition query result information through the watermark extractor.
  • the ETV service may be provided without a separate automatic content recognition server, and a query through an internet protocol network may be omitted.
  • the XML format of the ACR query result may include a result code unit 310.
  • the ACR query result type 300 may include a content identifier unit 301 and a network time protocol. ) May include a time stamp unit 302, a signaling channel information unit 303, a service information unit 304, and other identifier units 305.
  • the signaling channel information unit 303 may include a signaling channel URL unit 313, an update mode unit 323, and a polling cycle unit 333.
  • the service information unit 304 may include a service name unit 314 and a service logo unit. 324, a service description unit 334.
  • the XML schema of the automatic content recognition query result shown in FIG. 27 will now be described in detail, and an example of the XML schema will be described.
  • the result code unit 310 may indicate a result value of the automatic content recognition query. This can indicate the success or failure of the query, and the reason for the failure in the form of code. For example, if the value of the result code section 310 is 200, this indicates that the query succeeded and the corresponding content information was answered. If the value of result code portion 310 is 404, this indicates that no content was found.
  • the content identifier unit 301 represents an identifier for uniquely identifying content worldwide and may include a global service identifier unit that is an identifier for identifying a service.
  • the NTP time stamp unit 302 may indicate that a specific time point of the sample frame interval used for the automatic content recognition query is provided in the form of an NTP time stamp.
  • the specific time point may be the start point or the end point of the sample frame.
  • NTP is a protocol for setting the computer's time to the reference clock over the Internet and can be used for time synchronization between a time server and clients distributed over a computer network. Because NTP uses universal time coordinated (UTC) time and guarantees 10 ms accuracy, the receiver can handle frame synchronization operations accurately.
  • UTC universal time coordinated
  • the signaling channel information unit 303 may represent access information of an independent signaling channel on an internet protocol network for an ETV service.
  • the signaling channel URL unit 313, which is a lower part of the signaling channel information unit 303, may indicate URL information of the signaling channel.
  • the signaling channel URL unit 313 may include an update mode unit 323 and a polling cycle unit 333 as a lower part.
  • the update mode unit 323 shows a method of obtaining information through an internet protocol signaling channel. For example, in pull mode the receiver may perform polling periodically according to the pull method to obtain information, and in push mode the server may send information to the receiver according to the push method.
  • the polling cycle unit 333 may indicate a basic polling cycle value of the receiver according to the pull method when the update mode unit 323 is in the full mode. The receiver may specify a basic polling cycle value and transmit a request signal to the server at random time intervals, thereby preventing the server from being overloaded with the request.
  • the service information unit 304 may represent information about a broadcast channel.
  • the content identifier unit 301 may indicate an identifier of a service currently being viewed by the viewer, and the service information unit 304 may indicate specific information regarding a broadcast channel.
  • the specific information represented by the service information unit 304 may be a channel name, a logo, or a text description.
  • the service name unit 314, which is a lower part of the service information unit 304, may indicate a channel name
  • the service logo unit 324 may indicate a channel logo
  • the service description unit 334 may indicate a channel text description. Can be.
  • the following shows the XML schema of elements of the automatic content recognition query result shown in FIG. 3 according to an embodiment of the present invention.
  • 28 is a diagram illustrating syntax of a content identifier according to an embodiment of the present invention.
  • the ATSC content identifier may be used as an identifier for identifying the content received by the receiver.
  • the syntax of the content identifier shown in FIG. 28 is the syntax of the content identifier part of the automatic content recognition query result format described with reference to FIG. 27.
  • the ATSC content identifier is a phrase that has a unique period and consists of a Transmitting Subscriber Identification (TSID) and a house number.
  • TSID Transmitting Subscriber Identification
  • the house number is any number desired by the holder of the TSID as constrained here.
  • the number is unique for each value of the TSID.
  • the syntax of the ATSC content identifier structure is as defined in FIG.
  • the TSID a 16-bit unsigned integer field, will contain the value of transport_stream_id.
  • the FCC has the authority to assign these values.
  • the scope for Mexico, Canada, and the United States was established by formal agreements between these countries. Values in other regions are set by arbitrary privileges.
  • the end_of_day field which is a 5-bit unsigned integer, will be set to the time of the day in UTC when the broadcast day ends, and after a while, the content_id values may be reused according to unique_for.
  • the value of this field will be in the range of 0 to 23. At this time, the value of this field is expected to be fixed for each broadcaster.
  • the unique_for field a 9-bit unsigned integer, is measured in terms of the time indicated by end_of_day, which is set to the number of days, rounded up, and whose content_id value is not reallocated to other content. The value will be in the range of 1 to 511. 0 will be prohibited. 511 has a special meaning of "indefinite.” At this time, it is expected that the value of this field is changed only when the house numbering method is changed and is essentially fixed for each broadcaster. Also, the decoder can treat the stored content_values as unique until the unique_for field expires, which can be done by decrementing it by 1 every day at end_of_day until all stored unique_for fields are zero.
  • the content_id field which is a variable length field, may be set to a value of an identifier according to a house number system or a system for a value of TSID. Each of these values cannot be assigned to other content within the unique period set by the values of the end_of_day and unique_for fields.
  • the identifier may be human readable and / or any combination of binary values and need not perfectly match the form of the house number so that it does not exceed 242 bytes.
  • a receiver according to an embodiment of the present invention does not uniquely identify a service globally through the syntax of the content identifier shown in FIG. 28, in an embodiment of the present invention, the receiver uses a service using a global service identifier. Can be identified.
  • the global service identifier according to an embodiment of the present invention may be included in the content identifier of the automatic content recognition query result format described with reference to FIG. 27.
  • Example 1 shows a global service identifier of a URI format according to an embodiment of the present invention.
  • the global service identifier of [Example 1] may be used for ATSC-M / H service.
  • ⁇ region> is a two letter international country code as specified by ISO 639-2.
  • ⁇ xsid> is defined as the decimal encoding of the TSID for the local service as defined in that region. ⁇ xsid> is defined as "0" for local service (major> 69).
  • ⁇ serviceid> is defined as ⁇ major>.
  • ⁇ minor> may indicate a primary channel number and ⁇ minor> may indicate a subchannel number.
  • the above-described global service identifier may be expressed in the following URI format.
  • the receiver according to the embodiment of the present invention may identify the content using the global content identifier based on the global service identifier described above.
  • Example 4 shows a global content identifier of a URI format according to an embodiment of the present invention.
  • the global service identifier of [Example 4] may be used for ATSC service.
  • [Example 4] shows a case in which an ATSC content identifier is used as a global content identifier according to an embodiment of the present invention.
  • ⁇ region> is a two letter international country code as specified by ISO 639-2 [4].
  • ⁇ xsidz> is defined as the decimal encoding of the TSID for the local service as defined in that region. This is followed by ".” ⁇ Serviceid> as long as the emitting broadcaster does not use ⁇ serviceid> and cannot guarantee the uniqueness of the global content identifier. ⁇ xsidz> is defined as ⁇ serviceid> for local service (major> 69).
  • ⁇ serviceid> is as defined for the service delivering the content in section A1.
  • ⁇ content_id> is the base64 [5] encoding of the content_id field defined in FIG. 4 considering the content_id field as a binary string.
  • ⁇ unique_for> is the decimal encoding of the unique_for field defined in FIG.
  • ⁇ end_of_day> is a decimal encoding of the end_of_day field defined in FIG. 4.
  • the ATSC content identifier with the format defined through the above examples can be used to identify content on an automatic content recognition processing system.
  • FIGS. 29 and 30 may be configured differently according to the intention of the designer.
  • 29 is a diagram showing the structure of a receiver according to an embodiment of the present invention.
  • FIG. 29 illustrates an example of a configuration of a receiver that supports automatic content recognition based ETV service using watermarking.
  • a receiver supporting an automatic content recognition-based ETV service may include an input data processor, an ATSC main service processor, an ATSC mobile handheld (MH) service processor, and / or automatic content recognition. It may include a service processor.
  • the input data processor may include a tuner / demodulator 400 and / or residual sideband decoder 401.
  • the ATSC main service processor includes a transport protocol (TP) demultiplexer (402), a non-real-time guide information processor (403), a digital storage media command and control (DSM-CC) addressable section parser (404), and IP / UDP (information).
  • TP transport protocol
  • DSM-CC digital storage media command and control
  • ESG electronic service guide
  • DCD data carrier detect
  • storage control module 410 file / transport protocol switch 411, playback control module 412, first storage device 413, internet protocol packet storage control module 414, internet access control Module 415, internet protocol interface 416, live recording switch 417, file (object) decoder 418, transport protocol / packetized elementary stream (PES) decoder 420, program specific information (PSI) / PSIP (program and system information protocol) decoder ) And / or an electronic program guide (EPG) handler 422.
  • ESG electronic service guide
  • DCD data carrier detect
  • the ATSC MH service processor includes a main / MH / non-real time switch 419, an MH baseband processor 423, an MH physical adaptive processor 424, an internet protocol stack 425, a file handler 426, an ESG handler 427. , A second storage device 428, and / or a streaming handler 429.
  • the automatic content recognition service processor includes a main / MH / non-real time switch 419, an audio / video decoder 430, an audio / video processing module 431, an external input handler 432, a watermark extractor 433, and / Or may include an application 434.
  • the tuner / demodulator 400 may tune and demodulate the broadcast signal received from the antenna. Through this process, residual sideband symbols can be extracted. Residual sideband decoder 401 may decode the residual sideband symbols extracted by tuner / demodulator 400.
  • the residual sideband decoder 401 may output ATSC main service data and MH service data according to decoding.
  • ATSC main service data may be delivered to and processed by the ATSC main service processor
  • MH service data may be delivered to and processed by the ATSC MH service processor.
  • the ATSC main service processor may process the main service signal to deliver main service data except for the MH signal to the automatic content recognition service processor.
  • the transport protocol demultiplexer 402 may demultiplex the transport packet of ATSC main service data transmitted through the residual sideband signal and forward it to another processing module. That is, the transport protocol demultiplexer 402 may demultiplex and transmit various pieces of information included in a transport packet so that elements of a broadcast signal may be processed by modules of a broadcast receiver.
  • the demultiplexed data may include a real time stream, a DSM-CC addressable section, and / or a non real-time service table / A / 90 & 92 signaling table. More specifically, as shown in FIG.
  • the transport protocol demultiplexer 402 can output the live stream to the live recording switch 417 and the DSM-CC addressable section to the DSM-CC addressable section parser.
  • a non-real time service table / A / 90 & 92 signaling table can be output to the non real time guide information processor 403.
  • the non-real time guide information processor 403 receives the non real time service table / A / 90 & 92 signaling table from the transport protocol demultiplexer 402, extracts the FLUT session information, and passes it to the DSM-CC addressable section parser 404. Can be.
  • the DSM-CC addressable section parser 404 receives the DSM-CC addressable section from the transport protocol demultiplexer 402, receives the FLUT session information from the non-real-time guide information processor 403, and the DSM-CC It can handle addressable sections.
  • the IP / UDP parser 405 may receive data output from the DSM-CC addressable section parser 404 and parse the IP datagram sent according to the IP / UDP.
  • the FLUTE parser 406 may receive data output from the IP / UDP parser 405 and process FLUTE data for transmitting a data service transmitted in the form of an asynchronous layered coding (ALC) object.
  • the metadata module 407 and the file module 408 may receive data output from the FLUTE parser 406 and process the metadata and the restored file.
  • the ESG / DCD handler 409 may receive data output from the metadata module 407 and process an electronic service guide and / or downlink channel descriptor related to the broadcast program.
  • the recovered file may be transferred to the storage control module 410 in the form of a file object, such as a reference fingerprint and ATSC 2.0 content.
  • the file object may be processed by the storage control module 410, and may be divided into a normal file and a transport protocol file and stored in the first storage device 413.
  • the playback control module 412 may update the stored file object and pass the file object to the file / transport protocol switch 411 to decode the normal file and the transport protocol file.
  • the file / transport protocol switch 411 passes the normal file to the file decoder 418 and the transport protocol file to the live recording switch 417 so that the normal file and the transport protocol file are decoded through different paths. .
  • the file decoder 418 may decode the normal file and deliver it to the automatic content recognition service processor.
  • the decoded normal file may be passed to the main / MH / non-real time switch 419 of the automatic content recognition service processor.
  • the transport protocol file may be transferred to the transport protocol / PES decoder 420 under the control of the live recording switch 417.
  • the transport protocol / PES decoder 420 decodes the transport protocol file, and the PSI / PSIP decoder 421 decodes the decoded transport protocol file again.
  • the EPG handler 422 may process the decoded transport protocol file and process the EPG service in accordance with ATSC.
  • the ATSC MH service processor may process the MH signal to send ATSC MH service data to the automatic content recognition service processor. More specifically, the MH baseband processor 423 may convert the ATSC MH service data into a pulse waveform suitable for transmission. The MH physical adaptation processor 424 may process the ATSC MH service data in a form suitable for the MH physical layer.
  • the internet protocol stack 425 may receive data output from the MH physical adaptation processor 424 and process it according to a communication protocol for internet transmission / reception.
  • the file handler 426 may receive data output from the internet protocol stack 425 and process a file of an application layer.
  • the ESG handler 427 may receive data output from the file handler 426 and process the mobile ESG.
  • the second storage device 428 may receive data output from the file handler 426 and store a file object.
  • part of the data output from the Internet protocol stack module 425 may be data for an automatic content recognition service of a receiver instead of a mobile ESG service according to ATSC.
  • the streaming handler 429 may process and deliver the real streaming received through the real-time transport protocol (RTP) to the automatic content recognition service processor.
  • RTP real-time transport protocol
  • the main / MH / non-real time switch 419 of the automatic content recognition service processor may receive a signal output from the ATSC main service processor and / or the ATSC MH service processor.
  • the audio / video decoder 430 may decode the compressed audio / video data received from the main / MH / non-real time switch 419.
  • the decoded audio / video data may be delivered to the audio / video processing module 431.
  • the external input handler 432 may process audio / video content received through the external input and transmit it to the audio / video processing module 431.
  • the audio / video processing module 431 may process and display audio / video data received from the audio / video decoder 430 and / or the external input handler 432 on the screen.
  • the watermark extractor 433 may extract data inserted in the form of a watermark from the audio / video data.
  • the extracted watermark data may be delivered to the application 434.
  • the application 434 may provide an enhancement service based on an automatic content recognition function, identify broadcast content, and provide enhancement data related thereto.
  • the audio / video processing module 431 may process the received audio / video data and display the same on the screen.
  • the watermark extractor 433 illustrated in FIG. 29 may extract data (or watermark) inserted in the form of a watermark from audio / video data received through an external input.
  • the watermark extractor 433 may extract the watermark from the audio data, extract the watermark from the video data, or extract the watermark from the audio data and the video data.
  • the watermark extractor 433 may obtain channel information and / or content information from the extracted watermark.
  • a receiver may tune an ATSC MH channel and receive corresponding content and / or metadata using channel information and / or content information acquired by the watermark extractor 433.
  • a receiver may receive corresponding content and / or metadata through an internet network. The receiver may then display the received content and / or metadata using a trigger or the like.
  • FIG. 30 is a diagram showing the structure of a receiver according to another embodiment of the present invention.
  • FIG. 30 illustrates an example of a configuration of a receiver supporting an automatic content recognition based ETV service using watermarking.
  • the basic structure of the receiver shown in FIG. 30 is the same as the basic structure of the receiver shown in FIG. However, there is a difference that the receiver illustrated in FIG. 30 may further include a fingerprint extractor 535 and / or a fingerprint comparator 536 according to an embodiment of the present invention. In addition, the receiver illustrated in FIG. 30 may not include a watermark extractor 433 among the elements illustrated in FIG. 29.
  • FIG. 30 Since the basic configuration of FIG. 30 is the same as the basic configuration of the receiver shown in FIG. 29, description thereof will be omitted. Hereinafter, the operation of the receiver will be described based on the fingerprint extractor 535 and / or the fingerprint comparator 536.
  • the fingerprint extractor 535 may extract data (or signature) inserted into the A / V content received as an external input.
  • the fingerprint extractor 535 may extract the signature from the audio content, extract the signature from the video content, or extract the signature from the audio content and the video content.
  • the fingerprint comparator 536 may obtain channel information and / or content information using the signature extracted from the A / V content.
  • the fingerprint comparator 536 may acquire channel information and / or content information through local search and / or remote search.
  • a route where the fingerprint comparator 536 accesses and operates the storage device 537 is referred to as a local search.
  • the route where the fingerprint comparator 536 accesses and operates the Internet access control module 538 is called remote search. The following describes local search and remote search.
  • the fingerprint comparator 535 may compare the extracted signature with a reference fingerprint stored in the storage device 537.
  • the reference fingerprint is data that the fingerprint comparator 536 additionally receives to process the extracted signature.
  • the fingerprint comparator 536 may acquire channel information and / or content information by matching the extracted signature with a reference fingerprint and comparing the same.
  • the fingerprint comparator 536 may transmit the comparison result to the application.
  • the application may transmit channel information and / or content information related to the extracted signature to the receiver using the comparison result.
  • the fingerprint comparator 536 may receive a new reference fingerprint through the ATSC MH channel. Thereafter, the fingerprint comparator 536 may compare the extracted signature with the reference fingerprint again.
  • the fingerprint comparator 536 may receive channel information and / or content information from a signature database server on the Internet.
  • the fingerprint comparator 536 may access the signature database server by accessing the Internet network through the Internet access control module 538. Thereafter, the fingerprint comparator 536 may transfer the extracted signature as a query parameter to the signature database server.
  • the fingerprint comparator 536 may pass the query parameters to the corresponding signature database server. If the broadcasters individually run the signature database server, the fingerprint comparator 536 may pass query parameters to each signature database. Alternatively, fingerprint comparator 536 may pass query parameters to two or more signature database servers at the same time.
  • a receiver may tune an ATSC M / H channel and receive corresponding content and / or metadata by using channel information and / or content information acquired by the fingerprint comparator 536. .
  • the receiver may then display the received content and / or metadata using a trigger or the like.
  • FIG. 31 illustrates a digital broadcasting system according to an embodiment of the present invention.
  • FIG. 31 shows a personalization broadcast system including a digital broadcast receiver (or receiver) for a personalization service (personalization service).
  • the personalization service according to an embodiment of the present invention is a service that selects and provides contents suitable for a user based on user information.
  • the personalization broadcast system according to an embodiment of the present invention may provide ATSC 2.0 or a next generation broadcast service that provides a personalized service.
  • the user information As an embodiment of the user information, the user's profile, demographics and interest information (or PDI data) are defined.
  • the user's profile, demographics and interest information (or PDI data) are defined.
  • elements of the personalization broadcast system will be described.
  • the answers to the questionnaires collectively represent the user's profiles, demographics, and interests (PDI).
  • the data structure summarizing the questionnaire and the answers given by a particular user is called a PDI questionnaire or PDI table.
  • the data structure may contain an answer when it is available, but the PDI table does not contain answer data as it is provided by a network, broadcaster, or content provider.
  • the question portion of the entry in the PDI table is informally called "PDI-Question" or "PDI-Q”.
  • the answer to a given PDI question is informally called "PDI-A”.
  • the set of filter criteria is informally called "PDI-FC”.
  • Client devices such as ATSC 2.0 capable receivers, include functionality to enable the generation of answers to questions in a questionnaire (in the case of PDI-A).
  • This PDI generation function takes a PDI-Q case as an input and generates a PDI-A case as an output. Both the PDI-Q case and the PDI-A case are stored in the nonvolatile memory of the receiver.
  • the client provides a filtering function that compares the PDI-A case with the PDI-FC case to determine which content item is suitable for download and use.
  • a function is implemented to maintain and distribute the PDI table.
  • Content metadata is generated along with the content.
  • Some of the metadata is PDI-FC based on a question in the PDI table.
  • the personalization broadcast system may include a content provider (or broadcaster) 707 and / or a receiver 700.
  • the receiver 700 may include a PDI engine 701, a filtering engine 702, a PDI storage device 703, a content storage device 704, a declaration content module 705, and / or a UI module. It may include a (User Interface module) 706.
  • the receiver 700 may receive content from the content provider 707.
  • the structure of the above-described personalization broadcast system may vary depending on the intention of the designer.
  • the content provider 707 may transmit content, a PDI questionnaire (PDI questionnaire), and / or filtering criteria to the receiver 700.
  • PDI questionnaire The data structure that summarizes the questionnaire and the answers given by a particular user is called a PDI questionnaire.
  • the PDI questionnaire may include questions (or PDI questions) regarding a user's profile, demographics, interest, and the like.
  • the receiver 700 may process content, PDI questionnaire, and / or filtering criteria received from the content provider 707. Hereinafter, the operation of the modules included in the receiver 700 illustrated in FIG. 31 will be described.
  • the PDI engine 701 may first receive a PDI questionnaire provided by the content provider 707.
  • the PDI engine 701 may transmit the PDI question included in the received PDI questionnaire to the UI 706.
  • the PDI engine 701 may receive the user's answer to the corresponding PDI question and other information (hereinafter, PDI answer) from the UI 706.
  • the PDI engine 701 may generate PDI data by processing PDI questions and PDI answers to provide a personalization service. That is, PDI data according to an embodiment of the present invention may include the above-described PDI questions and / or PDI answers.
  • the PID answers for the PDI questionnaire collectively represent the user's profile, demographics, and interest (or PDI).
  • the PDI engine 701 may update the PDI data using the received PDI answer.
  • the PDI engine 701 may delete, add, and / or modify PDI data using an ID of a PDI answer. Details of the ID of the PDI answer according to an embodiment of the present invention will be described later.
  • the PDI engine 701 may deliver PDI data suitable for the request to the corresponding module.
  • the filtering engine 702 may filter the content according to the PDI data and the filtering criteria.
  • the filtering criteria means a set of criteria (filtering criteria) for filtering only content suitable for a user by using PDI data.
  • the filtering engine 702 may receive PDI data from the PDI engine 701 and may receive content and / or filtering criteria from the content provider 707.
  • the content provider 707 may also transmit a filtering criteria table associated with the declared content.
  • the filtering engine 702 may match and compare the filtering criteria with the PDI data, and filter and download the content using the comparison result.
  • the downloaded content may be stored in the content storage device 704. Details of the filtering method and the filtering criteria will be described later with reference to FIGS. 33 and 34.
  • the UI module 706 may display a PDI question received from the PDI engine 701 and receive a PDI answer from the user with respect to the corresponding PDI question.
  • the user may transmit the PDI answer to the receiver 700 using the remote controller with respect to the displayed PDI question.
  • the UI module 706 may transmit the received PDI answer to the PDI engine 701.
  • the declared content module 705 may access the PDI engine 701 to obtain PDI data. Also, as shown in FIG. 31, the declared content module 705 may receive the declared content provided by the content provider 707.
  • Declaration content according to an embodiment of the present invention is content related to an application executed in the receiver 700 and may include a DO such as a TDO.
  • the declaration content module 705 may access the PDI storage device 703 to obtain a PDI question and / or a PDI answer.
  • the declared content module 705 may use an application programming interface (API).
  • the declaration content module 705 may acquire at least one or more PDI questions by retrieving the PDI storage device 703 using an API. Thereafter, the declaration content module 705 may transmit a PDI question or receive a PDI answer through the UI module 706, and transmit the received PDI answer to the PDI storage device 703.
  • API application programming interface
  • the PDI memory 703 may store a PDI question and / or a PDI answer.
  • the content storage device 704 may store the filtered content.
  • the PDI engine 701 illustrated in FIG. 31 may receive a PDI Questionnaire from the content provider 707.
  • the receiver 700 may display the PDI question of the PDI questionnaire received through the UI module 706 and receive a PDI answer to the corresponding PDI question from the user.
  • the PDI engine 701 may deliver PDI data including the PDI question and / or PDI answer to the filtering engine 702.
  • the filtering engine 702 may filter the content through the PDI data and the filtering criteria. Accordingly, the receiver 700 may implement the personalization service by providing the filtered content to the user.
  • FIG. 32 is a diagram illustrating a digital broadcast system according to another embodiment of the present invention.
  • FIG. 32 illustrates a structure of a personalization broadcast system including a receiver for personalization service.
  • the personalization broadcast system may provide an ATSC 2.0 service.
  • elements of the personalization broadcast system will be described.
  • the personalization broadcast system may include a content provider (or broadcaster) 807 and / or a receiver 700.
  • the receiver 800 according to an embodiment of the present invention includes a PDI engine 801, a filtering engine 802, a PDI storage device 803, a content storage device 804, a declaration content module 805, and a UI module 806. ), Usage monitoring engine 808 and / or usage log module 809.
  • the receiver according to the embodiment of the present invention may receive content and the like from the content provider 807.
  • the basic modules of FIG. 32 are the same as the modules of FIG. 31 except that unlike the broadcast system of FIG. 31, the broadcast system of FIG.
  • a usage monitoring engine 808 and / or a usage log module 809. have.
  • the structure of the above-described personalization broadcast system may vary depending on the intention of the designer.
  • the usage monitoring engine 808 and the usage log module 809 will be described.
  • the usage log module 809 may store information (or history information) on a broadcast service usage history of the user.
  • the history information may include two or more usage data.
  • the usage data according to an embodiment of the present invention refers to information on which broadcast service the user used for a predetermined time. Specifically, the usage data may include information that the user watched the news for 40 minutes at 9 pm, information that the horror movie was downloaded at 11 pm, and the like.
  • the usage monitoring engine 808 may continuously monitor a user's broadcasting service usage status. Thereafter, the usage monitoring engine 808 may delete, add, and / or modify usage data stored in the usage log module 809 using the monitoring result. In addition, the usage monitoring engine 808 according to an embodiment of the present invention may transmit the usage data to the PDI engine 801, and the PDI engine 801 may update the PDI data using the transferred usage data.
  • FIG. 33 is a flowchart illustrating operations of a filtering engine and a PDI engine of the personalization broadcast system described with reference to FIGS. 31 and 32.
  • the receiver 900 may include a filtering engine 901 and / or a PDI engine 902.
  • operations of the filtering engine 901 and the PDI engine 902 according to an embodiment of the present invention will be described.
  • the structure of the above-described receiver may vary depending on the intention of the designer.
  • the receiver 900 may match and compare filtering criteria and PDI data.
  • the filtering engine 901 may receive filtering criteria from the content provider and may transmit a signal (or PDI data request signal) for requesting PDI data to the PDI engine 902.
  • the PDI engine 902 may search for PDI data corresponding to the corresponding PDI data request signal according to the transmitted PDI data request signal.
  • the filtering engine 901 illustrated in FIG. 33 may transmit a PDI data request signal including a reference identifier to the PDI engine 902.
  • the filtering criteria is a set of filtering criteria, and each filtering criterion may include a reference ID for identifying the filtering criteria.
  • the reference ID according to an embodiment of the present invention may be used to identify a PDI question and / or a PDI answer.
  • the PDI engine 902 may access the PDI storage device to retrieve the PDI data.
  • PDI data may include a PDI data ID for identifying a PDI question and / or a PDI answer.
  • the PDI engine 902 illustrated in FIG. 9 may compare the reference ID and the PDI data ID by matching the reference ID and the PDI data ID.
  • the receiver 900 may download the corresponding content.
  • the filtering engine 901 may transmit a download request signal for downloading the content to the content provider.
  • the PDI engine 902 may transmit a null identifier to the filtering engine 901.
  • the filtering engine 901 receiving the null ID may transmit a new PDI data request signal to the PDI engine 902.
  • the new PDI data request signal may include a new reference ID.
  • the receiver 900 may match all filtering criteria and PDI data included in the filtering criteria according to the above-described method. As a result of the matching, if all the filtering criteria match the PDI data, the filtering engine 901 may transmit a download request signal for downloading the content to the content provider.
  • FIG. 34 is a flowchart illustrating operations of a filtering engine and a PDI engine of the personalization broadcast system described with reference to FIGS. 31 and 32.
  • the receiver 1000 may include a filtering engine 1001 and / or a PDI engine 1002.
  • the structure of the above-described receiver may vary depending on the intention of the designer.
  • Basic operations of the filtering engine 1001 and the PDI engine 1002 illustrated in FIG. 34 are the same as those described with reference to FIG. 33.
  • the receiver 1000 illustrated in FIG. 34 may not download the corresponding content.
  • the filtering engine 1001 of the present invention may not transmit a new PDI data request signal to the PDI engine 1002.
  • the filtering engine 1001 of the present invention may not transmit the download request signal to the content provider according to an embodiment.
  • 35 is a diagram illustrating a PDI table according to an embodiment of the present invention.
  • the aforementioned personalization broadcast system of FIG. 31 uses PDI data to provide a personalization service, and the PDI data may be processed in a PDI table format.
  • the data structure summarizing the questionnaire and the answers given by a particular user is called a PDI questionnaire or PDI table.
  • the data structure may contain an answer when it is available, but the PDI table does not contain answer data as it is provided by a network, broadcaster, or content provider.
  • the question portion of the entry in the PDI table is informally called "PDI-Question" or "PDI-Q".
  • the answer to a given PDI question is informally called "PDI-A”.
  • the set of filter criteria is informally called "PDI-FC”.
  • the PDI table is represented by an XML schema.
  • the format of the PDI table according to an embodiment of the present invention can be changed according to the designer's intention.
  • a PDI table may include attributes 1110 and / or a PDI type element.
  • the attribute 1110 may include a transactional attribute 1100 and a time attribute 1101.
  • a PDI type element may include a question with integer answer (QIA) element 1102, a question with Boolean answer element 1102, a question with selection answer (QSA) element 1104, and a QTA (QTA).
  • QIA integer answer
  • QSA question with selection answer
  • QTA QTA
  • the attribute 1110 illustrated in FIG. 35 may indicate attribute information of the PDI table itself according to an embodiment of the present invention. Therefore, even if the PDI type elements included in the PDI table are different, the attribute 1110 may be equally represented in the PDI table according to an embodiment of the present invention.
  • the transactional attribute 1100 according to an embodiment of the present invention may indicate information about the purpose of the PDI question.
  • the time attribute 1101 according to an embodiment of the present invention may indicate information about a time when the PDI table was created or updated.
  • PDI tables including different PDI type elements may include a transactional attribute 1100 and / or a time attribute 1101 even though the PDI type elements are different.
  • the PDI table may include one or more PDI type elements 1102 as a root element.
  • the PDI type element 1102 may be represented in a list format.
  • PDI type elements according to an embodiment of the present invention may be distinguished according to types of PDI answers.
  • a PDI type element according to an embodiment of the present invention may be referred to as a "QxA" element, in which case "x" may be determined according to the type of the PDI answer.
  • the type of PDI answer according to an embodiment of the present invention may include an integer type, a Boolean type, a selection type, a text type, and a type including all types of answers other than the four types described above.
  • the QIA element 1103 may include an integer type PDI answer to one PDI question and / or a corresponding PDI question.
  • the QBA element 1104 may include a Boolean type PDI answer to one PDI question and / or a corresponding PDI question.
  • the QSA element 1105 may include one PDI question and / or a PDI answer of multiple selection type for the corresponding PDI question.
  • the QTA element 1106 may include a PDI answer of text type for one PDI question and / or the corresponding PDI question.
  • the QAA element 1107 may include a PDI answer in a form excluding an integer, a Boolean, multiple selection, and a string form for one PDI question and / or the corresponding PDI question.
  • 36 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 36 illustrates XML schema of QIA elements among the PDI type elements described with reference to FIG. 35.
  • the QIA element may include an attribute 1210, an id attribute 1220, a question element 1230, and / or an answer element 1240 indicating information about a feature associated with a PDI question type. Can be.
  • the attribute 1210 may include a lang attribute indicating a language of a PDI question.
  • the attribute 1210 of the QIA element according to an embodiment of the present invention indicates a minInclusive attribute 1230 indicating a minimum integer value that the PDI answer may have and / or a maximum integer value that the PDI answer may have.
  • the maxInclusive attribute 1240 may be included.
  • the id attribute 1220 may be used to identify a PDI question and / or a PDI answer.
  • the question element 1230 may include the PDI question itself.
  • the question element 1230 may include an attribute indicating information about a PDI question.
  • the question element 1230 may include a time attribute 1231 indicating the time at which the PDI question was created or a time at which the PDI question was sent, and / or an expiration attribute 1232 indicating the valid time of the PDI question. It may include.
  • the answer element 1240 includes the PDI answer itself.
  • the answer element 1240 may include an attribute indicating information on a PDI answer.
  • the answer element 1240 may indicate an id attribute 1241 that may be used to recognize each PDI answer and / or a time indicating when each PDI answer was created or modified. May include an attribute 1242.
  • FIG. 37 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 37 is a diagram illustrating XML schema of QBA elements among the PDI type elements described with reference to FIG. 35.
  • 38 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 38 illustrates XML schema of QSA elements among the PDI type elements described with reference to FIG. 35.
  • the attribute of the QSA element according to an embodiment of the present invention may further include a minChoice attribute 1411 and / or a maxChoice attribute 1412.
  • the minChoice attribute 1411 according to an embodiment of the present invention may indicate the minimum number of PDI answers that can be selected by the user.
  • the maxChoice attribute 1412 according to an embodiment of the present invention may indicate the maximum number of PDI answers that can be selected by the user.
  • 39 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 39 is a diagram illustrating XML schema of QAA elements among the PDI type elements described with reference to FIG. 35.
  • FIG. 40 is a diagram illustrating a PDI table according to another embodiment of the present invention.
  • FIG. 40 is a diagram illustrating an extended format of a PDI table in an XML schema, similar to the PDI table described with reference to FIGS. 35 to 39.
  • the present invention uses the PDI table to provide a personalization service.
  • the preferred content may vary depending on the situation to which the user belongs.
  • the PDI table illustrated in FIG. 40 may further include a situation element 1600 as a component element indicating situation information of a user. Since the basic XML schema of the PDI table illustrated in FIG. 40 is the same as described with reference to FIGS. 35 to 39, a detailed description thereof will be omitted.
  • the situation element 1600 is described below.
  • the context element 1600 may indicate information about a time zone and / or a location as context information of a user. As shown in FIG. 40, the context element 1600 may further include a time element 1610, a location element 1620, and / or other elements representing contextual information of the user. Each element is described below.
  • the time element 1610 may include information related to the time of the region to which the user belongs.
  • the time element 1610 according to an embodiment of the present invention may include a time attribute 1610 indicating time information in a “yyyy-mm-dd” format and / or a timezone indicating a time zone of a region to which the user belongs. It can include an attribute 1612.
  • the location element 1620 may include location information of a region to which the user belongs.
  • the place element 1620 may have a location-desc attribute 1621 indicating information of the location, a latitude attribute 1622 indicating latitude information of the location, and / or the corresponding location element 1620. It may include a longitude attribute 1623 indicating the longitude information of the location.
  • 41 and 42 illustrate a PDI table according to another embodiment of the present invention.
  • FIGS. 41 and 42 illustrate an embodiment of the PDI table according to the XML schema described with reference to FIGS. 35 to 40.
  • the PDI table case document refers to an actual document in which the PDI table is implemented according to an XML schema.
  • FIGS. 41 and 42 also show XML schema definitions for the root element QIA, QBA, QSA, QTA, or QAA that represent individual questions that can be exchanged between the DO and the embedded receiver using the PDI API. Details of the PDI API according to an embodiment of the present invention will be described later.
  • the elements shown in FIGS. 41 and 42 may follow the definition in the XML schema with the namespace “http://www.atsc.org/XMLSchemas/iss/pdi/1”.
  • PDI question or PDI-Q
  • PDI answer or PDI-A
  • the question portion of the entry in the PDI table is informally called "PDI Question” or "PDI-Q”.
  • the document may follow the "PDI Table” XML Schema, which is part of the ATSC 2.0 standard, along with the namespace, and its definition may supersede the description provided herein in case of differences.
  • the PDI-Q document according to an embodiment of the present invention refers to an actual document in which a PDI table including PDI-Q is implemented according to an XML schema.
  • the document consists of one or more elements of type integer-answer type question (QIA), Boolean-answer type question (QBA), selection-type question (QSA), and / or textual-answer type question (QTA). do.
  • QIA type integer-answer type question
  • QBA Boolean-answer type question
  • QSA selection-type question
  • QTA textual-answer type question
  • Elements other than the "A" (answer) child element of this top-level element may be present in the PDI-Q case.
  • an identifier attribute may serve as a link or criterion for the corresponding element in the document in the PDI-A case.
  • the PDI-A case document refers to an actual document in which a PDI table including PDI-A is implemented according to an XML schema.
  • PDI-A the document may follow the PDI Table "XML Schema, which is part of the ATSC 2.0 standard along with the namespace, and its definition may override the description provided herein in case of differences.
  • the documents may be integer-answer type question (QIA), Boolean-answer type question (QBA), selection-type answer question (QSA), textual-answer type question (QTA), and / or QAA (any-format).
  • answer type question consists of one or more elements of a type.
  • Each of these elements has at least one "A” (answer) sub-element. These may or may not include a "Q" (question string) subelement.
  • an identifier attribute may serve as a link or criterion for the corresponding element in the document in the PDI-Q case.
  • an attribute and an element may be distinguished by displaying “@” before the attribute name.
  • the PDI table may include a PDI type element.
  • the PDI type element may include a QIA element, a QBA element, a QSA element, a QTA element, and / or a QAA element as described with reference to FIG. 35.
  • the PDI table may include a protocolVersion attribute, a pdiTableId attribute, a pdiTableVersion attribute, and / or a time attribute regardless of the question type element.
  • the id attributes of QIA, QBA, QSA, QTA and QAA elements all have the same semantics as the expiration attribute of each of these elements. Similarly, like the time attribute of each A element, the lang attribute of each Q element has the same semantics.
  • the id attribute may mean the PDI data identifier described above with reference to FIG. 33.
  • the PDITable element contains a list of one or more question elements. Each is in the format of QIA, QBA, QSA, QTA, or QAA. Use of ⁇ choice> consisting of cardinality 0..N means that any number of QIA, QBA, QSA, QTA and QAA elements can appear in any order.
  • the protocolVersion attribute of the PDITable element consists of two hexadecimal digits.
  • the upper four bits represent the major version number of the table definition.
  • the lower four bits represent the minor version number of the table definition.
  • the major version number for that version of the standard is set to one.
  • Receivers are supposed to discard the case of PDI, which indicates the number of major versions that are not ready to support.
  • the minor version number for that version of the standard is set to zero.
  • Receivers are not supposed to discard the case of PDI, which indicates a minor version number that is not ready to support. In this case, receivers are supposed to ignore individual elements or attributes that they do not support.
  • the pdiTableId attribute of the PDITable element may be a globally unique identifier of the corresponding PDI Table element.
  • the 8-bit pdiTableVersion attribute of the PDITable element indicates the version of the corresponding PDI Table element.
  • the initial value may be zero.
  • the value may be incremented by one every time the PDI table element changes to 0 with a rollover of 0 after 255.
  • the time attribute of the PDITable element indicates the date and time of the most recent change to a question in the corresponding PDI Table.
  • the QIA element represents the integer answer type of the question. This includes optional tolerances that specify the maximum and minimum allowed values for the answer.
  • the QIA.loEnd attribute of a QIA represents the minimum possible value of the "A" child element of the corresponding QIA element. That is, the value of the "A" element is not less than loEnd. If the loEnd attribute is not present, it indicates that there is no minimum value.
  • the QIA.hiEnd attribute of the QIA indicates the maximum possible value of the "A" child element of the corresponding QIA element. That is, the value of the answer is not greater than hiEnd. If the hiEnd attribute is not present, this indicates that there is no maximum value.
  • the QIA.Q element is a child element of the QIA element.
  • the value of the QIA.Q element may indicate a question string to be presented to the user.
  • the question must be expressed to have an integer type answer. There are several instances of that element in different languages.
  • the QIA.A element may have an integer value.
  • the QIA.A element may represent an answer to a question in QIA.Q.
  • the QBA element may indicate the type of question answer.
  • the QBA.Q element is a child element of the QBA element.
  • the value of the QBA.Q element may represent a question string to be presented to the user. The question must be expressed to have a yes / no or correct / false answer. There are several instances of that element in different languages.
  • the QBA.A element may have a Boolean value.
  • the QBA.A element can represent an answer to a question in QBA.Q.
  • the QSA element may indicate the selection answer type of the question.
  • the QSA.minChoices attribute of the QSA element may specify the minimum number of choices that can be made by the user.
  • the QSA.maxChoices attribute of the QSA element may specify the maximum number of choices that can be made by the user.
  • the QSA.Q element is a child element of the QSA element.
  • the value of the QSA.Q element may indicate a question string to be presented to the user. The question must be expressed to have an answer corresponding to one or more given choices.
  • the QSA.Q.Selection element is a child element of the QSA.Q element.
  • the value of the QSA.Q.Selection element may represent a selection that may be presented to the user. If there are multiple QSA.Q subelements (in different languages) in the same QSA element, each has the same number of Selection subelements with the same meaning.
  • the QSA.Q.Selection.id attribute of QSA.Q.Selection may be an identifier for a unique Selection element within the scope of QSA.Q. If there are multiple QSA.Q subelements (in different languages) in the same QSA element, there may be a one-to-one correspondence between the id attributes of the Selection elements that have the same meaning.
  • QSA.A is a child element of the QSA element.
  • Each instance of the child element of the corresponding QSA element may specify one answer allowed in the corresponding selection type question in the form of an id value of one of the Selection elements.
  • the QTA element represents the text answer (descriptive entry) type of the question.
  • the QTA.Q element is a child element of the QTA element.
  • the value of the QTA.Q element may indicate a question string to be presented to the user. The question must be expressed to have a descriptive answer.
  • the QTA.A element is a child element of the QTA element.
  • QTA.A Element The value of an element can represent an answer to a question in QTA, Q.
  • QAA elements can be used to hold various types of information, such as entries in a database.
  • the QAA.A element is a child element of the QAA element.
  • the value of the QAA.A element contains some type of information.
  • the id attribute of a QIA, QBA, QSA, QTA, or QAA element can be a URI that is a globally unique identifier for the element it represents.
  • the expire element of the QIA, QBA, QSA, QTA, and QAA elements can indicate the date and time that the element it appears in is no longer relevant and is deleted from the table.
  • the lang attribute of the QIA.Q, QBA.Q, QSA.Q, QTA.Q, and QTA.A elements may indicate the language of the question or answer string.
  • the lang attribute can also indicate the language of the Selection sub-element of QSA.Q. If the lang attribute does not exist, this may indicate that the language is English.
  • the time attribute of the QIA.A, QBA.A, QSA.A, QTA.A, and QAA.A elements may indicate the date and time the answer was entered in the table.
  • the PDI table may further include a QIAD element, a QBAD element, a QSAD element, a QTAD element, and / or a QAAD element.
  • the aforementioned elements are collectively called QxAD elements.
  • the QxAD element is described below.
  • the QIAD element as a root element may contain a question of integer answer type in the QIA subelement.
  • the QIA may include an optional allowance specifying the maximum and minimum allowable values of the answer.
  • the QBAD element as the root element will represent the type of question answer.
  • the QSAD element as the root element will represent the optional answer type of the question.
  • the QTAD element as the root element will represent the text answer (descriptive entry) type of the question.
  • the QAAD element as the root element will be used to hold various types of information such as entries in the database.
  • each PDI type element may further include a QText element and / or a time attribute.
  • the QIA.Q.QText element is a child element of the QIA.Q element.
  • the value of the QIA.Q.QText element will represent the question string to be presented to the user.
  • the question must be expressed to have an integer type answer.
  • the QIA.A.answer attribute is an integer value attribute of the QIA.A element.
  • the QIA.A.answer property will represent the answer to the question in the QIA.Q.QText element.
  • the QBA.Q.Qtext element is a child element of the QBA.Q element.
  • the value of the QBA.Q.Qtext element will represent the question string to be presented to the user.
  • the question must be expressed to have a yes / no or correct / false answer. There may be various instances of that element in other languages.
  • the QBA.A.answer attribute is a boolean attribute of the QBA.A element.
  • the QBA.A@answer property will represent the answer to the question in the QBA.Q.QText element.
  • the QSA.Q.QText element is a child element of the QSA.Q element.
  • the QSA.Q.QText element will represent the question string to be presented to the user. The question must be expressed to have an answer corresponding to one or more given choices. There may be various instances of that element in other languages.
  • the QSA.A.answer attribute of the QSA.A sub-element shall specify one answer allowed for that selection type question in the form of the id value of one of the Selection elements.
  • the QTA.Q.QText element is a child element of the QTA element.
  • the value of the QTA.Q.QText element will represent the question string to be presented to the user.
  • the question must be expressed to have a descriptive answer.
  • the QTA.A.answer attribute is a child element of the QTA element.
  • the value of the QTA.A.answer element represents the answer to the question in the QTA.Q.QText element.
  • 43 and 44 illustrate a PDI table according to another embodiment of the present invention.
  • FIGS. 43 and 44 are views illustrating a structure of a PDI table according to the XML schema described with reference to FIGS. 35 to 40.
  • the basic structure of the PDI table shown in FIGS. 43 and 44 and the semantics of the basic elements and attributes included in the PDI table are the same as those described with reference to FIGS. 41 and 42.
  • the PDI tables illustrated in FIGS. 43 and 44 may further include an xactionSetId attribute and / or a text attribute. The following description focuses on the xactionSetId attribute and / or the text attribute.
  • the xactionSetId attribute of the QxA element indicates that the question belongs to a transactional set of questions, a set that is treated as a unit for the purpose of answering the question. It also provides an identifier for the transactional set to which the question belongs. Thus, all sets of questions in the PDI table with the same value of the xactionSetId attribute are alternatively answered.
  • the text attribute of a QxA element is a child of the QxA.Q element.
  • the value of the text attribute will represent the question string to be presented to the user.
  • FIG. 45 is a diagram illustrating a filtering criteria table according to an embodiment of the present invention.
  • the aforementioned personalization broadcast system of FIG. 31 may use filtering criteria to provide a personalization service.
  • the filtering criteria described with reference to FIGS. 31, 33, and 34 may be processed in the form of a filtering criteria table.
  • the filtering criteria table is represented by an XML schema.
  • the filtering criteria table of the present invention may have a format similar to that of the PDI table in order to efficiently compare the filtering criteria with the PDI data.
  • the format of the filtering criteria table according to an embodiment of the present invention can be changed according to the designer's intention.
  • the filtering criteria table may include a filtering criterion element 1900, and the filtering criterion element 1900 includes an identifier attribute 1901 and a criterion type attribute 1902. ) And / or criterion value element 1903.
  • the filtering criteria of the present invention may be used as a concept corresponding to the above-described PDI question.
  • elements of the filtering criteria table illustrated in FIG. 45 will be described.
  • the filtering criterion element 1900 may indicate filtering criteria corresponding to the PDI question.
  • the identifier attribute 1901 may identify a PDI question corresponding to the filtering criteria.
  • the criterion type attribute 1902 may indicate the type of filtering criteria. Details of the type of filtering criteria will be described later.
  • the criterion value element 1903 may indicate a value of the filtering criteria.
  • Each reference value is a possible answer to a PDI question.
  • the type of filtering criteria according to the present invention may be one of an integer type, a Boolean type, a selection type, a text type, and / or any type.
  • An integer type filtering criterion refers to a filtering criterion corresponding to an integer type PDI answer.
  • Boolean type filtering criteria means filtering criteria corresponding to a Boolean type PDI answer.
  • the filtering criterion of the selection type refers to the filtering criterion corresponding to the PDI answer of the selection type.
  • the filtering criterion of the text type refers to a filtering criterion corresponding to the PDI answer of the text type.
  • Any type of filtering criteria means filtering criteria corresponding to all types of PDI answers other than the four types described above.
  • Example 5 is an embodiment of the present invention showing an XML schema of the filtering criteria table shown in FIG.
  • 46 is a diagram illustrating a filtering criteria table according to another embodiment of the present invention.
  • FIG. 46 illustrates an extended format of the filtering criteria table described with reference to FIG. 45 in an XML schema.
  • FIG. 46 an XML schema representing the types of filtering criteria and setting attributes for each type is presented.
  • the personalization broadcast system may filter content more precisely by using a filtering criteria table configured according to the XML schema of FIG. 46.
  • the filtering criteria table may include an attribute 2000 and / or a filtering criteria type element.
  • the attribute 2000 may include a time attribute 2001.
  • the filtering criteria type element according to an embodiment of the present invention may be an integer type reference element (Integer Type Criterion element) (or QIA reference element) 2010, a Boolean Type Criterion element (or QBA reference element) ( 2020, Selection Type Criterion element (or QSA reference element) 2030, Text Type Criterion element (or QTA reference element) 2040 and / or which type reference element ( Any Type Criterion element (or QAA reference element) 2050.
  • the attribute 2000 illustrated in FIG. 35 may indicate attribute information of the filtering criteria table itself according to an embodiment of the present invention. Therefore, even if the filtering criteria type elements included in the filtering criteria table are different, they may be expressed in the same manner.
  • the time attribute 2001 may indicate a time when the filtering criteria is generated or an updated time.
  • the filtering criteria tables including different filtering criteria type elements may include a time attribute 2001 even if the filtering criteria type elements are different.
  • the filtering criteria table according to an embodiment of the present invention may include one or more filtering criteria type elements.
  • the filtering criterion type element according to an embodiment of the present invention may indicate the type of filtering criterion.
  • the type of filtering criteria is the same as described with reference to FIG. 45.
  • the filtering criterion type element may be expressed in a list form.
  • the filtering criterion type element may be referred to as a "QxA" criterion, and in this case, "x" may be determined according to the type of filtering criterion.
  • each filtering criteria type element may include an identifier attribute and / or a reference value element. Details of the identifier attribute and reference value element illustrated in FIG. 46 are the same as the content described with reference to FIG. 45.
  • the integer type reference element 2010 may further include a min integer attribute 2011 and / or a max integer attribute 2012.
  • the min integer attribute 2011 may indicate a minimum value of a filtering criterion expressed as an integer type answer.
  • the max integer attribute 2012 may indicate a maximum value of a filtering criterion expressed as an integer type answer.
  • selection type criterion element 2030 and / or text type criterion element 2040 may include a lang attribute 2031.
  • the lang attribute 2031 according to an embodiment of the present invention may indicate a value of a filtering criterion expressed in a string form.
  • Example 6 is an embodiment of the present invention showing an XML schema of the filtering criteria table shown in FIG.
  • 47 is a diagram illustrating a filtering criteria table according to another embodiment of the present invention.
  • FIG. 47 is a diagram illustrating an embodiment of a filtering criteria table according to the XML schema described with reference to FIGS. 45 and 46.
  • Basic elements of the filtering criteria table illustrated in FIG. 47 are the same as the elements described with reference to FIGS. 45 and 46.
  • semantics of elements and attributes included in the filtering criteria table illustrated in FIG. 47 will be described.
  • an attribute and an element may be distinguished by displaying “@” before the attribute name.
  • the presence of the @id attribute of the question in the PDI table identifies the question that corresponds to the filtering criteria for which the @id attribute appears.
  • the QIA Criterion element will represent the filtering criteria corresponding to a question with an integer value.
  • the Criterion Value sub-element of the QIA Criterion element does not contain an @extent element, it will represent an integer answer to the question corresponding to the filtering criteria. If the Criterion Value sub-element of the QIA Criterion element contains the @extent attribute, it will represent the lower end of the range of answers to the question and the @extent attribute will represent the number of integers in that range.
  • the QBA Criterion element will represent the filtering criteria corresponding to a boolean question.
  • the Criterion Value sub-element of the QBACriterion element will represent the answer to the question that corresponds to the filtering criteria.
  • the QSA Criterion element will represent the filtering criteria corresponding to the question with the selected value.
  • the Criterion Value sub-element of the QSA Criterion element will indicate the identifier of the selection answer for the question corresponding to the filtering criteria.
  • the QTA Criterion element will represent the filtering criteria corresponding to a question with a string value.
  • the Criterion Value sub-element of the QTA Criterion element will represent a textual answer to the question corresponding to the filtering criteria.
  • the QAA Criterion element will represent the filtering criteria corresponding to a "question” with only the text "answer” without a question.
  • the Criterion Value sub-element of the QAACriterion element will represent the text "answer” for the "question” corresponding to the filtering criteria.
  • the Filtering Criteria element contains only one Criterion Value element

Abstract

본 발명은 개인화된 서비스를 제공하는 방법을 제안한다. 본 발명에 따른 개인화된 서비스를 제공하는 방법은, 개인화 테이블을 수신하는 단계, 여기서 상기 개인화 테이블은 개인화된 서비스 제공에 관련된 복수개의 개인화 질문 및 상기 개인화 테이블을 식별하는 테이블 식별자를 포함하고; 상기 복수개의 개인화 질문에 대한 적어도 하나의 답변을 획득하는 단계; 및 상기 획득한 답변을 상기 개인화 테이블에 저장하는 단계; 를 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.

Description

방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
본 발명은 방송 신호 송신 장치, 방송 신호 수신 장치, 및 방송 신호 송수신 방법에 관한 것이다.
아날로그 방송 신호 송신이 종료됨에 따라, 디지털 방송 신호를 송수신하기 위한 다양한 기술이 개발되고 있다. 디지털 방송 신호는 아날로그 방송 신호에 비해 더 많은 양의 비디오/오디오 데이터를 포함할 수 있고, 비디오/오디오 데이터뿐만 아니라 다양한 종류의 부가 데이터를 더 포함할 수 있다.
즉, 디지털 방송 시스템은 HD(High Definition) 이미지, 멀티채널(multi channel, 다채널) 오디오, 및 다양한 부가 서비스를 제공할 수 있다. 그러나, 디지털 방송을 위해서는, 많은 양의 데이터 전송에 대한 데이터 전송 효율, 송수신 네트워크의 견고성(robustness), 및 모바일 수신 장치를 고려한 네트워크 유연성(flexibility)이 향상되어야 한다.
목적 및 다른 이점을 달성하기 위해, 본 발명의 목적에 따라, 여기에 포함되고 대략적으로 기재된 바와 같이, 개인화된 서비스를 제공하는 방법은 개인화 테이블을 수신하는 단계, 여기서 상기 개인화 테이블은 개인화된 서비스 제공에 관련된 복수개의 개인화 질문 및 상기 개인화 테이블을 식별하는 테이블 식별자를 포함하고; 상기 복수개의 개인화 질문에 대한 적어도 하나의 답변을 획득하는 단계; 및 상기 획득한 답변을 상기 개인화 테이블에 저장하는 단계; 를 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 개인화된 서비스를 제공하는 방법은: 서비스에 관한 필터링 크리테리아를 수신하는 단계, 여기서 상기 필터링 크리테리아는 상기 서비스에 관한 정보를 포함하고; 상기 필터링 크리테리아 내의 정보와 상기 획득한 답변을 비교하는 단계; 및 상기 필터링 크리테리아 내의 정보와 상기 획득한 답변이 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 단계; 를 더 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 필터링 크리테리아는 상기 서비스를 시그널링하는 서비스 시그널링 정보에 포함되어 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 개인화 질문은 상기 개인화 질문의 답변 타입에 따라 다른 구조를 가지고, 상기 개인화 질문은 질문에 관한 정보를 포함하는 질문 엘레멘트와 상기 개인화 질문에 대한 답변을 저장할 수 있는 답변 엘레멘트를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 개인화 질문은 상기 개인화 질문이 수신기가 자동으로 답변이 가능한 형태인지 여부를 지시하는 자동생성정보를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 자동생성정보에 따라 상기 개인화 질문에 대한 답변은 수신기에 의해 자동으로 획득되는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 자동생성정보는 수신기가 상기 개인화 질문에 자동으로 답변하지 못하는 경우에 상기 개인화 질문을 대체할 질문을 식별하는 대체질문 식별자를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 개인화된 서비스를 제공하는 방법은: 서비스의 시청에 관한 시청 히스토리 정보를 포함하는 히스토리 테이블을 생성하는 단계; 상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보를 비교하는 단계; 및 상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보가 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 단계; 를 더 포함하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 히스토리 테이블은 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 히스토리 정보를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 필터링 크리테리아는 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 기준정보를 포함하고, 상기 히스토리 정보와 매칭되는 상기 기준정보들의 개수를 기반으로 상기 서비스에 관한 서비스 데이터가 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
바람직하게는, 각각의 상기 기준정보는 가중치 정보를 포함하고, 상기 히스토리 정보와 매칭되는 상기 기준정보들의 가중치를 기반으로 상기 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법일 수 있다.
다른 관점에서, 본 발명은 개인화된 서비스를 제공하는 장치를 제안한다. 이 개인화된 서비스를 제공하는 장치는, 개인화 테이블을 수신하는 제 1 모듈, 여기서 상기 개인화 테이블은 개인화된 서비스 제공에 관련된 복수개의 개인화 질문 및 상기 개인화 테이블을 식별하는 테이블 식별자를 포함하고; 및 상기 복수개의 개인화 질문에 대한 적어도 하나의 답변을 획득하는 제 2 모듈, 여기서 상기 제 2 모듈은 상기 획득한 답변을 상기 개인화 테이블에 저장하고; 를 포함하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 제 1 모듈은 서비스에 관한 필터링 크리테리아를 수신하고, 여기서 상기 필터링 크리테리아는 상기 서비스에 관한 정보를 포함하고; 상기 개인화된 서비스를 제공하는 장치는 상기 필터링 크리테리아 내의 정보와 상기 획득한 답변을 비교하는 제 3 모듈을 포함하고; 및 상기 제 1 모듈은 상기 필터링 크리테리아 내의 정보와 상기 획득한 답변이 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 필터링 크리테리아는 상기 서비스를 시그널링하는 서비스 시그널링 정보에 포함되어 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 개인화 질문은 상기 개인화 질문의 답변 타입에 따라 다른 구조를 가지고, 상기 개인화 질문은 질문에 관한 정보를 포함하는 질문 엘레멘트와 상기 개인화 질문에 대한 답변을 저장할 수 있는 답변 엘레멘트를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 개인화 질문은 상기 개인화 질문이 수신기가 자동으로 답변이 가능한 형태인지 여부를 지시하는 자동생성정보를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 자동생성정보에 따라 상기 개인화 질문에 대한 답변은 수신기에 의해 자동으로 획득되는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 자동생성정보는 수신기가 상기 개인화 질문에 자동으로 답변하지 못하는 경우에 상기 개인화 질문을 대체할 질문을 식별하는 대체질문 식별자를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치일 수 있다.
바람직하게는, 개인화된 서비스를 제공하는 장치는 서비스의 시청에 관한 시청 히스토리 정보를 포함하는 히스토리 테이블을 생성하는 제 4 모듈을 포함하고; 상기 제 3 모듈은 상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보를 비교하고; 및 상기 제 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은 자동 콘텐츠 인식 기반 ETV(enhanced television) 서비스 시스템을 나타낸 도면이다.
도 26는 본 발명의 일 실시예에 따른 디지털 워터마킹 기술의 흐름을 나타낸 도면이다.
도 27은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과 포맷을 나타낸 도면이다.
도 28는 본 발명의 일 실시예에 따른 콘텐츠 식별자의 구문(syntax)을 나타낸 도면이다.
도 29는 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
도 30은 본 발명의 또 다른 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
도 31은 본 발명의 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
도 32은 본 발명의 다른 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
도 33는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 34은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 35은 본 발명의 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 36는 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 37은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 38는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 39는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 40은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 41는 본 발명의 또 다른 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 42는 본 발명의 또 다른 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 43는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 44는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
도 45는 본 발명의 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 46은 본 발명의 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 47은 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 48는 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
도 49은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 50는 본 발명의 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 51는 본 발명의 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 52은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 53은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
도 54은 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 55는 본 발명의 다른 일 실시예에 따른 FDT 경우의 XML 스키마를 나타낸 도면이다.
도 56은 본 발명의 일 실시예에 따른 캐퍼빌리티 기술어 구문을 나타낸 도면이다.
도 57은 본 발명의 일 실시예에 따른 소비 모델을 나타낸 도면이다.
도 58는 본 발명의 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
도 59은 본 발명의 다른 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
도 60는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 61는 본 발명의 일 실시예에 따른 HTTP 요청 테이블을 나타낸 도면이다.
도 62은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트이다.
도 63은 본 발명의 일 실시예에 따른 URL 리스트 테이블을 나타낸 도면이다.
도 64은 본 발명의 일 실시예에 따른 TPT를 나타낸 도면이다.
도 65는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 66은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 67은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 68는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
도 69은 본 발명의 일 실시예에 따른 수신기 대상 기준 테이블을 나타낸 도면이다.
도 70는 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 71는 본 발명의 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 72은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 73은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 74은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 75는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 76은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 77은 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 78는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 79는 본 발명의 또 다른 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
도 80는 본 발명의 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 81는 본 발명의 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 82은 본 발명의 또 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
도 83 은 본 발명의 일 실시예에 따른, 차세대 방송 시스템을 위한 프로토콜 스택 (Protocol Stack) 을 도시한 도면이다.
도 84 은 본 발명의 일 실시예에 따른 UPnP 방식의 액션(Action) 메커니즘을 도시한 도면이다.
도 85 은 본 발명의 일 실시예에 따른 REST 메커니즘을 도시한 도면이다.
도 86 는 본 발명의 일 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 87 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 88 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 다른 일부를 도시한 도면이다.
도 89 는 본 발명의 일 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
도 90 은 본 발명의 일 실시예에 따른 UserData 서비스의 상태변수(state variable)들을 도시한 도면이다.
도 91 는 본 발명의 일 실시예에 따른 UserDataList 의 XML 구조를 도시한 도면이다.
도 92 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션(action)들을 도시한 도면이다.
도 93 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetPDIUserDataProtocolVersion 를 설명하는 도면이다.
도 94 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetUserDataIdsList 와 GetUserData 를 설명하는 도면이다.
도 95 은 본 발명의 일 실시예에 따른 UserData 서비스의 확장된 상태변수를 도시한 도면이다.
도 96 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, SetUserData 를 설명하는 도면이다.
도 97 은 본 발명의 일 실시예에 따른, UserData 서비스의 추가된 상태변수를 도시한 도면이다.
도 98 은 본 발명의 일 실시예에 따른, UserData 서비스의 또 다른 추가된 상태변수를 도시한 도면이다.
도 99 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 상태변수들을 도시한 도면이다.
도 100 은 본 발명의 일 실시예에 따른 UserDataQAList 의 XML 구조를 도시한 도면이다.
도 101 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션(action)들을 도시한 도면이다.
도 102 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션들 중, GetUserDataQAIdsList 와 GetUserDataQA 를 설명하는 도면이다.
도 103 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어 단위 전달을 위한, UserData 서비스의 액션들 중, SetUserDataQA 를 설명하는 도면이다.
도 104 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
도 105 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 상태변수를 도시한 도면이다.
도 106 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 액션을 설명한 도면이다.
도 107 은 본 발명의 일 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
도 108 은 본 발명의 다른 실시예에 따른, PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 확장된 상태변수를 설명한 도면이다.
도 109 는 본 발명의 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 110 은 본 발명의 다른 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
도 111 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
도 112 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 액션을 설명한 도면이다.
도 113 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 시퀀스 다이어그램을 도시한 도면이다.
도 114 은 본 발명의 일 실시예에 따른, FC가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
도 115 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 액션을 설명한 도면이다.
도 116 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
도 117 은 본 발명의 다른 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
도 118 은 본 발명의 일 실시예에 따른 방송 수신기를 나타낸 도면이다.
도 119 는 본 발명의 다른 실시예에 따른 방송 수신기를 나타낸 도면이다.
도 120 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 를 도시한 도면이다.
도 121 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 122 는 본 발명의 다른 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 123 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, caption_service_descriptor 의 확장된 필드들을 도시한 도면이다.
도 124 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 125 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 126 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 폰트에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 127 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 글자 크기에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 128 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 정렬에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 129 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 프린트되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 130 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 스크롤되는 방향에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 131 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(Closed Caption Preference) 에 있어서, 클로즈드 캡션의 이지 리더(easy reader) 모드에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 132 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 133 는 본 발명의 다른 실시예에 따른 오디오 선호도(Audio Preference) 의, 시퀀스 다이어그램을 도시한 도면이다.
도 134 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, AC-3_audio_stream_descriptor 의 확장된 필드들을 도시한 도면이다.
도 135 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 언어에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 136 는 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 청각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 137 은 본 발명의 일 실시예에 따른 오디오 선호도(Audio Preference) 에 있어서, 오디오의 시각 장애인을 위한 모드 사용여부에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 138 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
도 139 은 본 발명의 다른 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)의, 시퀀스 다이어그램을 도시한 도면이다.
도 140 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(Accessibility&Sign Language)에 있어서, sign_language_descriptor 를 도시한 도면이다.
도 141 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 접근성&수화 프리젠테이션 사용에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 142 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화 언어의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 143 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(Accessibility&Sign Language Preference) 에 있어서, 수화의 위치의 선호도에 대한 프리-레지스터드(Pre-Registered) PDI Question 을 도시한 도면이다.
도 144 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 에 있어서, 답변의 업데이트를 위한 메뉴 화면을 도시한 도면이다.
도 145 은 본 발명의 또 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
도 146 는 본 발명의 일 실시예에 따른, 유저 ID 필드를 더 포함하는 PDIUserData 를 도시한 도면이다.
도 147 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 PDI Question 에 대한 답변을 얻는 시퀀스 다이어그램을 도시한 도면이다.
도 148 는 본 발명의 일 실시예에 따른, 유저 ID 를 이용하여 필터링 크리테리아를 적용하는 시퀀스 다이어그램을 도시한 도면이다.
도 149 는 본 발명의 일 실시예에 따른, 유저 ID 를 할당하는 방법을 도시한 도면이다.
도 150 은 본 발명의 일 실시예에 따른 채널 혹은 프로그램 추천에 사용할 선호도 크리테리아(Preference Criteria) 의 XML 스키마(Schema)의 다이어그램을 도시한 도면이다.
도 151 는 본 발명의 일 실시예에 따른 채널 혹은 프로그램 추천에 사용할 선호도 크리테리아(Preference Criteria) 의 XML 스키마(Schema) 를 도시한 도면이다.
도 152 는 본 발명의 일 실시예에 따른 채널 혹은 프로그램 추천에 사용할 선호도 크리테리아(Preference Criteria) 의 디스크립터(descriptor) 를 도시한 도면이다.
도 153 은 본 발명의 일 실시예에 따른, 서비스 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마의 확장 다이어그램을 도시한 도면이다.
도 154 은 본 발명의 일 실시예에 따른, 서비스 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마를 도시한 도면이다.
도 155 은 본 발명의 일 실시예에 따른, 컨텐츠 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마의 확장 다이어그램을 도시한 도면이다.
도 156 는 본 발명의 일 실시예에 따른, 컨텐츠 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마를 도시한 도면이다.
도 157 은 본 발명의 일 실시예에 따른, ESG와 함께 전달된 선호도 크리테리아를 이용하여 사용자에게 서비스/컨텐츠 를 추천하는 시퀀스 다이어그램을 도시한 도면이다.
도 158 은 본 발명의 다른 실시예에 따른, ESG와 함께 전달된 선호도 크리테리아를 이용하여 사용자에게 서비스/컨텐츠 를 추천하는 시퀀스 다이어그램을 도시한 도면이다.
도 159 는 본 발명의 일 실시예에 따른, 선호도 크리테리아와 PDI 유저 데이터를 비교하는 방법을 도시한 도면이다.
도 160 은 본 발명의 일 실시예에 따른, 선호도 크리테리아와 PDI 유저 데이터를 비교하기 위한 매칭 바운더리(matching boundary) 필드를 도시한 도면이다.
도 161 는 본 발명의 일 실시예에 따른, 추천된 서비스/컨텐츠를 제공하는 UI 를 도시한 도면이다.
도 162 는 자동답변에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 163 은 재답변 인터벌에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 164 는 자동답변 가능한 질문을 보충 질문으로 대체하기 위한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 165 는 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 보충 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
도 166 은 자동답변 가능한 질문을 대체 질문으로 대체하기 위한 ID 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 167 은 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 대체 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
도 168 은 컨텐츠 히스토리 엔진을 더 포함하는, 본 발명의 또 다른 실시예에 따른 수신기를 도시한 도면이다.
도 169 는 본 발명의 또 다른 실시예에 따른 방송 수신기의 구조를 도시한 도면이다.
도 170 은 본 발명의 일 실시예에 따른 컨텐츠 히스토리 테이블을 도시한 도면이다.
도 171 은 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 필터링 크리테리아를 도시한 도면이다.
도 172 는 본 발명의 일 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
도 173 은 본 발명의 다른 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
도 174 는 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 간략화된 필터링 크리테리아를 도시한 도면이다.
도 175 는 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 일부를 도시한 도면이다.
도 176 은 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 다른 일부를 도시한 도면이다.
도 177 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 테이블 및 필터링 크리테리아를 이용한 개인화된 서비스를 제공하는 시퀀스 다이어그램을 도시한 도면이다.
도 178 은 카운트 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
도 179 는 문턱값 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
도 180 은 문턱값 정보를 포함하는 필터링 크리테리아에 있어서, 본 발명의 일 실시예에 따른 비교 과정을 도시한 도면이다.
도 181 은 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법을 도시한 도면이다.
도 182 는 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치를 도시한 도면이다.
본 발명의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 본 발명의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 본 발명의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 본 발명에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 본 발명이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
본 발명에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 본 발명은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
본 발명은 차세대 방송 서비스에 대한 방송 신호 송신 및 수신 장치 및 방법을 제공한다. 본 발명의 일 실시예에 따른 차세대 방송 서비스는 지상파 방송 서비스, 모바일 방송 서비스, 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에 기재되어 있다.
표 1
Figure PCTKR2015005534-appb-T000001
2. 핸드헬드 프로파일
핸드헬드 프로파일은 배터리 전원으로 구동되는 핸드헬드 및 차량용 장치에서의 사용을 위해 설계된다. 해당 장치는 보행자 또는 차량 속도로 이동할 수 있다. 수신기 복잡도뿐만 아니라 소비 전력은 핸드헬드 프로파일의 장치의 구현을 위해 매우 중요하다. 핸드헬드 프로파일의 타겟 신호 대 잡음비 범위는 대략 0 내지 10 dB이지만, 더 낮은 실내 수신을 위해 의도된 경우 0 dB 아래에 달하도록 설정될 수 있다.
저 신호 대 잡음비 능력뿐만 아니라, 수신기 이동성에 의해 나타난 도플러 효과에 대한 복원력은 핸드헬드 프로파일의 가장 중요한 성능 속성이다. 핸드헬드 프로파일에 대한 중요 시스템 파라미터가 아래 표 2에 기재되어 있다.
표 2
Figure PCTKR2015005534-appb-T000002
3. 어드벤스 프로파일
어드벤스 프로파일은 더 큰 실행 복잡도에 대한 대가로 더 높은 채널 능력을 제공한다. 해당 프로파일은 MIMO 송신 및 수신을 사용할 것을 요구하며, UHDTV 서비스는 타겟 용도이고, 이를 위해 해당 프로파일이 특별히 설계된다. 향상된 능력은 주어진 대역폭에서 서비스 수의 증가, 예를 들면, 다수의 SDTV 또는 HDTV 서비스를 허용하는 데도 사용될 수 있다.
어드벤스 프로파일의 타겟 신호 대 잡음비 범위는 대략 20 내지 30 dB이다. MIMO 전송은 초기에는 기존의 타원 분극 전송 장비를 사용하고, 추후에 전출력 교차 분극 전송으로 확장될 수 있다. 어드벤스 프로파일에 대한 중요 시스템 파라미터가 아래 표 3에 기재되어 있다.
표 3
Figure PCTKR2015005534-appb-T000003
이 경우, 베이스 프로파일은 지상파 방송 서비스 및 모바일 방송 서비스 모두에 대한 프로파일로 사용될 수 있다. 즉, 베이스 프로파일은 모바일 프로파일을 포함하는 프로파일의 개념을 정의하기 위해 사용될 수 있다. 또한, 어드벤스 프로파일은 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로부터 조직적으로 인코딩되고, 그 뒤에 첨부된다.
수학식 1
Figure PCTKR2015005534-appb-M000001
PLS1 및 PLS2에 대한 LDPC 코드 파라미터는 다음의 표 4와 같다.
표 4
Figure PCTKR2015005534-appb-T000004
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에 주어진다.
표 5
Figure PCTKR2015005534-appb-T000005
FFT_SIZE: 해당 2비트 필드는 아래 표 6에서 설명한 바와 같이 프레임 그룹 내에서 현 프레임의 FFT 사이즈를 나타낸다.
표 6
Figure PCTKR2015005534-appb-T000006
GI_FRACTION: 해당 3비트 필드는 아래 표 7에서 설명한 바와 같이 현 슈퍼 프레임에서의 가드 인터벌 일부(fraction) 값을 나타낸다.
표 7
Figure PCTKR2015005534-appb-T000007
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에 나타낸 바와 같이 각각의 프로파일에 대해 다르게 정의된다.
표 8
Figure PCTKR2015005534-appb-T000008
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에 나타낸 바와 같이 시그널링 된다.
표 9
Figure PCTKR2015005534-appb-T000009
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 코드에 대한 자세한 내용은 후술한다.
표 10
Figure PCTKR2015005534-appb-T000010
PLS2_MOD: 해당 3비트 필드는 PLS2에 의해 사용되는 변조 타입을 나타낸다. 변조 타입은 표 11에 따라 시그널링 된다.
표 11
Figure PCTKR2015005534-appb-T000011
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에 대해 사용되지 않는다.
표 12
Figure PCTKR2015005534-appb-T000012
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에 따라 시그널링 된다.
표 13
Figure PCTKR2015005534-appb-T000013
DP_GROUP_ID: 해당 8비트 필드는 현 데이터 파이프가 관련되어 있는 데이터 파이프 그룹을 식별한다. 이는 수신기가 동일한 DP_GROUP_ID를 갖게 되는 특정 서비스와 관련되어 있는 서비스 컴포넌트의 데이터 파이프에 접속하는 데 사용될 수 있다.
BASE_DP_ID: 해당 6비트 필드는 관리 계층에서 사용되는 (PSI/SI와 같은) 서비스 시그널링 데이터를 전달하는 데이터 파이프를 나타낸다. BASE_DP_ID에 의해 나타내는 데이터 파이프는 서비스 데이터와 함께 서비스 시그널링 데이터를 전달하는 노멀 데이터 파이프이거나, 서비스 시그널링 데이터만을 전달하는 전용 데이터 파이프일 수 있다.
DP_FEC_TYPE: 해당 2비트 필드는 관련된 데이터 파이프에 의해 사용되는 FEC 타입을 나타낸다. FEC 타입은 아래의 표 14에 따라 시그널링 된다.
표 14
Figure PCTKR2015005534-appb-T000014
DP_COD: 해당 4비트 필드는 관련된 데이터 파이프에 의해 사용되는 코드 레이트(code rate)을 나타낸다. 코드 레이트(code rate)은 아래의 표 15에 따라 시그널링 된다.
표 15
Figure PCTKR2015005534-appb-T000015
DP_MOD: 해당 4비트 필드는 관련된 데이터 파이프에 의해 사용되는 변조를 나타낸다. 변조는 아래의 표 16에 따라 시그널링 된다.
표 16
Figure PCTKR2015005534-appb-T000016
DP_SSD_FLAG: 해당 1비트 필드는 SSD 모드가 관련된 데이터 파이프에서 사용되는지 여부를 나타낸다. 해당 필드의 값이 1로 설정되면, SSD는 사용된다. 해당 필드의 값이 0으로 설정되면, SSD는 사용되지 않는다.
다음의 필드는 PHY_PROFILE가 어드벤스 프로파일을 나타내는 010과 동일할 때에만 나타난다.
DP_MIMO: 해당 3비트 필드는 어떤 타입의 MIMO 인코딩 처리가 관련된 데이터 파이프에 적용되는지 나타낸다. MIMO 인코딩 처리의 타입은 아래의 표 17에 따라 시그널링 된다.
표 17
Figure PCTKR2015005534-appb-T000017
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에 정의된다.
표 18
Figure PCTKR2015005534-appb-T000018
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에 따라 시그널링 된다.
표 19
Figure PCTKR2015005534-appb-T000019
DP_INBAND_MODE: 해당 2비트 필드는 현 데이터 파이프가 인 밴드(In-band) 시그널링 정보를 전달하는지 여부를 나타낸다. 인 밴드(In-band) 시그널링 타입은 아래의 표 20에 따라 시그널링 된다.
표 20
Figure PCTKR2015005534-appb-T000020
DP_PROTOCOL_TYPE: 해당 2비트 필드는 주어진 데이터 파이프에 의해 전달되는 페이로드의 프로토콜 타입을 나타낸다. 페이로드의 프로토콜 타입은 입력 페이로드 타입이 선택되면 아래의 표 21에 따라 시그널링 된다.
표 21
Figure PCTKR2015005534-appb-T000021
DP_CRC_MODE: 해당 2비트 필드는 CRC 인코딩이 인풋 포맷 블록에서 사용되는지 여부를 나타낸다. CRC 모드는 아래의 표 22에 따라 시그널링 된다.
표 22
Figure PCTKR2015005534-appb-T000022
DNP_MODE: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되는 경우에 관련된 데이터 파이프에 의해 사용되는 널 패킷 삭제 모드를 나타낸다. DNP_MODE는 아래의 표 23에 따라 시그널링 된다. DP_PAYLOAD_TYPE이 TS ('00')가 아니면, DNP_MODE는 00의 값으로 설정된다.
표 23
Figure PCTKR2015005534-appb-T000023
ISSY_MODE: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되는 경우에 관련된 데이터 파이프에 의해 사용되는 ISSY 모드를 나타낸다. ISSY_MODE는 아래의 표 24에 따라 시그널링 된다. DP_PAYLOAD_TYPE이 TS ('00')가 아니면, ISSY_MODE는 00의 값으로 설정된다.
표 24
Figure PCTKR2015005534-appb-T000024
HC_MODE_TS: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 TS ('00')로 설정되는 경우에 관련된 데이터 파이프에 의해 사용되는 TS 헤더 압축 모드를 나타낸다. HC_MODE_TS는 아래의 표 25에 따라 시그널링 된다.
표 25
Figure PCTKR2015005534-appb-T000025
HC_MODE_IP: 해당 2비트 필드는 DP_PAYLOAD_TYPE이 IP ('01')로 설정되는 경우에 IP 헤더 압축 모드를 나타낸다. HC_MODE_IP는 아래의 표 26에 따라 시그널링 된다.
표 26
Figure PCTKR2015005534-appb-T000026
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 사이즈에 따라 다른 길이를 갖는다.
표 27
Figure PCTKR2015005534-appb-T000027
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 인코딩 파라미터를 나타낸다.
표 28
Figure PCTKR2015005534-appb-T000028
표 29
Figure PCTKR2015005534-appb-T000029
BCH 인코딩 및 LDPC 인코딩의 구체적인 동작은 다음과 같다.
12-에러 정정 BCH 코드가 BBF의 외부 인코딩에 사용된다. 쇼트 FECBLOCK 및 롱 FECBLOCK에 대한 BBF 생성 다항식은 모든 다항식을 곱함으로써 얻어진다.
LDPC 코드는 외부 BCH 인코딩의 출력을 인코딩하는 데 사용된다. 완성된 Bldpc (FECBLOCK)를 생성하기 위해, Pldpc (패리티 비트)가 각각의 Ildpc (BCH - 인코딩된 BBF)로부터 조직적으로 인코딩되고, Ildpc에 첨부된다. 완성된 Bldpc (FECBLOCK)는 다음의 수학식으로 표현된다.
수학식 2
Figure PCTKR2015005534-appb-M000002
롱 FECBLOCK 및 쇼트 FECBLOCK에 대한 파라미터는 위의 표 28 및 29에 각각 주어진다.
롱 FECBLOCK에 대해 Nldpc - Kldpc 패리티 비트를 계산하는 구체적인 절차는 다음과 같다.
1) 패리티 비트 초기화
수학식 3
Figure PCTKR2015005534-appb-M000003
2) 패리티 체크 매트릭스의 어드레스의 첫 번째 행에서 특정된 패리티 비트 어드레스에서 첫 번째 정보 비트 i0 누산(accumulate). 패리티 체크 매트릭스의 어드레스의 상세한 내용은 후술한다. 예를 들면, 비율 13/15에 대해,
수학식 4
Figure PCTKR2015005534-appb-M000004
3) 다음 359개의 정보 비트 is, s=1, 2, …, 359에 대해, 다음의 수학식을 이용하여 패리티 비트 어드레스에서 is 누산(accumulate).
수학식 5
Figure PCTKR2015005534-appb-M000005
여기서, x는 첫 번째 비트 i0에 해당하는 패리티 비트 누산기의 어드레스를 나타내고, Qldpc는 패리티 체크 매트릭스의 어드레서에서 특정된 코드 레이트(code rate) 의존 상수이다. 상기 예인, 비율 13/15에 대한, 따라서 정보 비트 i1에 대한 Qldpc = 24에 계속해서, 다음 동작이 실행된다.
수학식 6
Figure PCTKR2015005534-appb-M000006
4) 361번째 정보 비트 i360에 대해, 패리티 비트 누산기의 어드레스는 패리티 체크 매트릭스의 어드레스의 두 번째 행에 주어진다. 마찬가지 방식으로, 다음 359개의 정보 비트 is, s= 361, 362, …, 719에 대한 패리티 비트 누산기의 어드레스는 수학식 6을 이용하여 얻어진다. 여기서, x는 정보 비트 i360에 해당하는 패리티 비트 누산기의 어드레스, 즉 패리티 체크 매트릭스의 두 번째 행의 엔트리를 나타낸다.
5) 마찬가지 방식으로, 360개의 새로운 정보 비트의 모든 그룹에 대해, 패리티 체크 매트릭스의 어드레스로부터의 새로운 행은 패리티 비트 누산기의 어드레스를 구하는 데 사용된다.
모든 정보 비트가 이용된 후, 최종 패리티 비트가 다음과 같이 얻어진다.
6) i=1로 시작해서 다음 동작을 순차적으로 실행
수학식 7
Figure PCTKR2015005534-appb-M000007
여기서 pi, i=0,1,...Nldpc - Kldpc - 1의 최종 콘텐트는 패리티 비트 pi와 동일하다.
표 30
Figure PCTKR2015005534-appb-T000030
표 30을 표 31로 대체하고, 롱 FECBLOCK에 대한 패리티 체크 매트릭스의 어드레스를 쇼트 FECBLOCK에 대한 패리티 체크 매트릭스의 어드레스로 대체하는 것을 제외하고, 쇼트 FECBLOCK에 대한 해당 LDPC 인코딩 절차는 롱 FECBLOCK에 대한 t LDPC 인코딩 절차에 따른다.
표 31
Figure PCTKR2015005534-appb-T000031
도 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에 나타낸 바와 같이, 타임 인터리빙에는 세 가지 옵션이 있다(타임 인터리빙을 생략하는 추가 옵션 제외).
표 32
Figure PCTKR2015005534-appb-T000032
일반적으로, 타임 인터리버는 프레임 생성 과정 이전에 데이터 파이프 데이터에 대한 버퍼로도 작용할 것이다. 이는 각각의 데이터 파이프에 대해 2개의 메모리 뱅크로 달성된다. 첫 번째 타임 인터리빙 블록은 첫 번째 뱅크에 기입된다. 첫 번째 뱅크에서 판독되는 동안 두 번째 타임 인터리빙 블록이 두 번째 뱅크에 기입된다.
타임 인터리빙은 트위스트된 행-열 블록 인터리버이다. n번째 타임 인터리빙 그룹의 s번째 타임 인터리빙 블록에 대해, 열의 수 Nc 가 NxBLOCK_TI(n,s) 와 동일한 반면, 타임 인터리빙 메모리의 행의 수 Nr 는 셀의 수 Ncells 와 동일하다 (즉, Nr = Ncells).
도 21은 본 발명의 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 기본 동작을 나타낸다.
도 21(a)는 타임 인터리버에서 기입 동작을 나타내고, 도 21(b)는 타임 인터리버에서 판독 동작을 나타낸다. (a)에 나타낸 바와 같이, 첫 번째 XFECBLOCK은 타임 인터리빙 메모리의 첫 번째 열에 열 방향으로 기입되고, 두 번째 XFECBLOCK은 다음 열에 기입되고, 이러한 동작이 이어진다. 그리고 인터리빙 어레이에서, 셀이 대각선 방향으로 판독된다. (b)에 나타낸 바와 같이 첫 번째 행으로부터 (가장 왼쪽 열을 시작으로 행을 따라 오른쪽으로) 마지막 행까지 대각선 방향 판독이 진행되는 동안,
Figure PCTKR2015005534-appb-I000001
개의 셀이 판독된다. 구체적으로,
Figure PCTKR2015005534-appb-I000002
이 순차적으로 판독될 타임 인터리빙 메모리 셀 위치라고 가정하면, 이러한 인터리빙 어레이에서의 판독 동작은 아래 식에서와 같이 행 인덱스
Figure PCTKR2015005534-appb-I000003
, 열 인덱스
Figure PCTKR2015005534-appb-I000004
, 관련된 트위스트 파라미터
Figure PCTKR2015005534-appb-I000005
를 산출함으로써 실행된다.
수학식 8
Figure PCTKR2015005534-appb-M000008
여기서,
Figure PCTKR2015005534-appb-I000006
는
Figure PCTKR2015005534-appb-I000007
에 상관없이 대각선 방향 판독 과정에 대한 공통 시프트 값이고, 시프트 값은 아래 식에서와 같이 PLS2-STAT에서 주어진
Figure PCTKR2015005534-appb-I000008
에 의해 결정된다.
수학식 9
Figure PCTKR2015005534-appb-M000009
결과적으로, 판독될 셀 위치는 좌표
Figure PCTKR2015005534-appb-I000009
에 의해 산출된다.
도 22는 본 발명의 다른 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 동작을 나타낸다.
더 구체적으로, 도 22는
Figure PCTKR2015005534-appb-I000010
,
Figure PCTKR2015005534-appb-I000011
,
Figure PCTKR2015005534-appb-I000012
일 때 가상 XFECBLOCK을 포함하는 각각의 타임 인터리빙 그룹에 대한 타임 인터리빙 메모리에서 인터리빙 어레이를 나타낸다.
변수
Figure PCTKR2015005534-appb-I000013
는
Figure PCTKR2015005534-appb-I000014
보다 작거나 같을 것이다. 따라서,
Figure PCTKR2015005534-appb-I000015
에 상관없이 수신기 측에서 단일 메모리 디인터리빙을 달성하기 위해, 트위스트된 행-열 블록 인터리버용 인터리빙 어레이는 가상 XFECBLOCK을 타임 인터리빙 메모리에 삽입함으로써
Figure PCTKR2015005534-appb-I000016
의 크기로 설정되고, 판독 과정은 다음 식과 같이 이루어진다.
수학식 10
Figure PCTKR2015005534-appb-M000010
타임 인터리빙 그룹의 수는 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 PCTKR2015005534-appb-I000017
로 이어진다.
도 23은 본 발명의 일 실시예에 따른 트위스트된 행-열 블록 인터리버의 대각선 방향 판독 패턴을 나타낸다.
더 구체적으로, 도 23은 파라미터
Figure PCTKR2015005534-appb-I000018
및 Sshift=(7-1)/2=3을 갖는 각각의 인터리빙 어레이로부터의 대각선 방향 판독 패턴을 나타낸다. 이때 위에 유사 코드로 나타낸 판독 과정에서,
Figure PCTKR2015005534-appb-I000019
이면, Vi의 값이 생략되고, Vi의 다음 계산값이 사용된다.
도 24는 본 발명의 일 실시예에 따른 각각의 인터리빙 어레이로부터의 인터리빙된 XFECBLOCK을 나타낸다.
도 24는 파라미터
Figure PCTKR2015005534-appb-I000020
및 Sshift=3을 갖는 각각의 인터리빙 어레이로부터 인터리빙된 XFECBLOCK을 나타낸다.
도 25은 자동 콘텐츠 인식 기반 ETV(enhanced television) 서비스 시스템을 나타낸 도면이다.
도 25에 나타낸 자동 콘텐츠 인식 기반 ETV 서비스 시스템은 방송사 또는 콘텐츠 제공자(100), 다채널 방송사업자(101), 셋톱박스(102), 디지털 TV 수신기 등의 수신기(103), 자동 콘텐츠 인식 서버(또는 자동 콘텐츠 인식 솔루션 제공자)(104)를 포함할 수 있다. 수신기(103)는 ATSC(advanced television system committee)의 정의에 따라 동작할 수 있고, 자동 콘텐츠 인식 기능을 지원할 수 있다. 실시간 방송 서비스(110)는 오디오/비디오 콘텐츠를 포함할 수 있다.
디지털 방송 서비스는 크게 방송사(100)에 의해 제공되는 지상파 방송 서비스와 다채널 방송사업자(101)에 의해 제공되는 케이블 방송 또는 위성 방송 등의 다채널 방송 서비스로 구분될 수 있다. 방송사(100)는 실시간 방송 서비스(110) 및 인헨스먼트 데이터(또는 부가 데이터)(120)를 함께 전송할 수 있다. 이 경우, 도 25에 나타낸 바와 같이, 수신기(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) 방식이 이용될 수 있다. 워터마킹은 디지털 콘텐츠 제공자를 나타내는 정보를 디지털 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅은 특정 정보가 디지털 콘텐츠에 삽입되는 점은 워터마킹과 동일하지만, 콘텐츠 제공자에 관한 정보 대신 콘텐츠 구매자에 관한 정보가 삽입되는 점이 워터마킹과 다르다.
도 26는 본 발명의 일 실시예에 따른 디지털 워터마킹 기술의 흐름을 나타낸 도면이다.
디지털 위성방송의 도입에 따라, 디지털 데이터방송이 새로운 부가 서비스로 나타났다. 대표적인 쌍방향 서비스인 쌍방향 데이터방송은 다양한 부가 서비스를 제공하기 위해 데이터 신호뿐만 아니라 기존 방송 신호를 가입자에게 전송할 수 있다.
디지털 데이터방송은 크게 가상 채널을 이용한 독립형 서비스와 ETV를 통한 방송 관련 서비스로 구분될 수 있다. 독립형 서비스는 방송 이미지 신호 없이 텍스트와 그래픽만을 포함하며 기존 인터넷 웹페이지와 유사한 포맷으로 제공된다. 독립형 서비스의 대표적인 예로 날씨 및 주식 정보 제공 서비스, TV 금융 서비스, 상거래 서비스 등을 들 수 있다. 방송 관련 서비스는 방송 이미지 신호뿐만 아니라 부가적인 텍스트 및 그래픽 정보도 전송한다. 시청자는 방송 관련 서비스를 통해 시청한 방송 프로그램에 관련된 정보를 얻을 수 있다. 예를 들면, 시청자가 드라마를 시청하는 동안 이전 스토리나 촬영장소를 볼 수 있게 하는 서비스가 있다.
디지털 데이터방송의 방송 관련 서비스에서는, ETV 서비스가 자동 콘텐츠 인식 기술을 바탕으로 제공될 수 있다. 자동 콘텐츠 인식이란 장치가 오디오/비디오 콘텐츠를 재생할 때 콘텐츠에 숨겨진 정보를 통해 자동으로 콘텐츠를 인식하는 기술을 말한다.
자동 콘텐츠 인식 기술을 시행할 때 콘텐츠에 관한 정보를 얻기 위해 워터마킹이나 핑거프린팅 방식이 이용될 수 있다. 워터마킹은 디지털 콘텐츠 제공자를 나타내는 정보를 디지털 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅은 특정 정보가 디지털 콘텐츠에 삽입되는 점은 워터마킹과 동일하지만, 콘텐츠 제공자에 관한 정보 대신 콘텐츠 구매자에 관한 정보가 삽입되는 점이 워터마킹과 다르다.
이하 도 26와 관련하여 워터마킹 기술에 대해 구체적으로 살펴본다.
디지털 워터마킹은 제거하기 어려운 방식으로 디지털 신호에 정보를 매립하는 과정이다. 예를 들면, 신호는 음성, 화면, 또는 영상 될 수 있다. 신호가 복제되면, 정보도 복제된 신호에 실린다. 하나의 신호는 동시에 여러 다른 워터마크를 실을 수 있다.
시각적 워터마킹에서, 정보는 화면 또는 영상에서 가시적이다. 일반적으로 정보는 미디어의 소유자를 식별하는 텍스트나 로고이다. TV 방송사가 전송되는 영상의 코너에 로고를 추가하면, 이 또한 시각적 워터마크이다.
비시각적 워터마킹에서, 정보는 디지털 데이터로서 음성, 화면, 또는 영상에 추가되는데, 약간의 정보가 숨겨져 있다는 것을 감지할 수 있어도 그 자체가 인지되지는 못한다. 워터마크는 널리 사용되기 위한 것이어서, 검색하기 쉽게 되어있거나, 한 단체가 디지털 신호에 매립된 비밀메시지를 주고받는 스테가노그래피의 형태일 수 있다. 어느 경우이든, 시각적 워터마킹에서와 같이, 목적은 소유주나 다른 서술 정보를 제거하기 어려운 방식으로 신호에 부착하는 것이다. 숨겨진 매립 정보를 개개인 사이의 통신을 전환하기 위한 수단으로 사용할 수도 있다.
워터마킹의 하나의 응용은 디지털 미디어의 비승인 복제를 방지 또는 저지하기 위한 저작권 보호 시스템에 있다. 이 용도에서는, 복제 장치가 복제 전에 신호로부터 워터마크를 검색하고, 워터마크의 콘텐츠에 따라 복제를 할지 결정한다. 또 다른 응용은 소스 추적에 있다.
워터마크는 배포시마다 디지털 신호에 매립된다. 저작물의 복제물이 나중에 발견되면, 워터마크가 복제물로부터 검색될 수 있고, 배포의 소스가 알려진다. 보도에 따르면 이 기술은 불법적으로 복제된 영화의 소스를 알아내기 위해 사용되어 왔다.
서술 정보가 있는 디지털 사진의 어노테이션은 비시각적 워터마킹의 또 다른 응용이다.
디지털 미디어에 대한 파일형식의 일부가 메타데이터라 불리는 부가 정보를 포함할 수 있는 반면, 디지털 워터마킹은 데이터가 신호 자체에서 전달된다는 점에서 구별된다.
일부 문맥에서 디지털 워터마크라는 문구가 워터마킹된 신호와 커버 신호 사이의 차이를 의미하지만, 매립될 정보는 디지털 워터마크라 불린다. 워터마크가 매립될 신호는 호스트 신호라 불린다.
워터마킹 시스템은 주로 매립(201), 공격(202), 검출(또는 추출)(203)의 세 개의 별개의 단계로 구분된다.
매립(201)에서, 알고리즘은 호스트 및 매립될 데이터를 받아들이고, 워터마킹된 신호를 생성한다.
워터마킹된 신호는 전송 또는 저장되는데, 주로 다른 사람에게 전송된다. 이 사람이 변경을 가하면, 이는 공격(202)이라 불린다. 변경이 악의적이지 않을 수도 있지만, 공격이라는 용어는 저작권 침해자들이 변경을 통해 디지털 워터마크를 제거하려는 저작권 보호 어플리케이션으로부터 발생한다. 여러 가지 변경이 가능할 수 있다. 예를 들면, 데이터의 비가역압축, 이미지 또는 영상의 크로핑, 또는 의도적으로 가하는 잡음 등이 있을 수 있다.
검출(203)은 공격받은 신호에서 워터마크를 추출하기 위해 공격받은 신호에 적용되는 알고리즘이다. 신호가 전송 중에 변경되지 않았다면, 워터마크는 여전히 존재하고 추출될 수 있다. 견고한 워터마킹 어플리케이션에서는, 변경이 강력하더라도 추출 알고리즘은 워터마크를 올바르게 생성할 수 있을 것이다. 취약한 워터마킹에서는, 신호에 어떠한 변경이 가해지더라도 추출 알고리즘은 실패할 것이다.
매립된 정보가 몇 번의 변형에 의해 저하되더라도 마킹된 신호로부터 확실히 검출될 수 있으면 디지털 워터마크는 변형에 대해 견고하다고 한다. 전형적인 이미지 저하는 JPEG 압축, 회전(rotation), 크로핑, 부가적인 잡음 및 양자화이다. 비디오 콘텐츠에 있어서, 일시적 변경 및 MPEG 압축이 주로 여기에 포함된다. 워터마킹된 콘텐츠가 원래의 워터마킹되지 않은 콘텐츠와 지각적으로 동등하면 워터마크는 감지할 수 없다고 한다. 일반적으로, 견고한 워터마크나 감지할 수 없는 워터마크는 생성하기 쉽지만, 견고하고 감지할 수 없는 워터마크는 생성하기 어렵다고 알려져 있다. 견고하고 감지할 수 없는 워터마크는 디지털 콘텐츠의 보호를 위한 도구, 예를 들면, 전문적인 비디오 콘텐츠에서 매립된 "복제 불허" 플래그로서 제안되었다.
디지털 워터마킹 기술은 몇 가지 방식으로 분류될 수 있다.
첫째로, 워터마크는 약간의 변형 후에 검출되지 못하면 취약하다고 한다(견고성). 취약한 워터마크는 보통 탬퍼 검출(무결성 입증)을 위해 사용된다. 분명히 뚜렷한 원저작물에 가한 변형은 보통 워터마크라 불리지 않고, 일반화된 바코드라 불린다. 양성 변형에는 저항력이 있지만 악성 변형 후에는 검출에 실패하는 워터마크는 약간 취약하다고 한다. 약간 취약한 워터마크는 보통 악성 변형을 검출하기 위해 사용된다. 지정된 부류의 변형에 저항력이 있는 워터마크는 견고하다고 한다. 견고한 워터마크는 복제물을 전달하고 제어 정보에 접속하기 위해 복제 방지 어플리케이션에서 사용될 수 있다.
둘째로, 원래의 커버 신호와 마킹된 신호가 지각적으로 구별될 수 없으면(구별되기 어려우면) 워터마크는 감지할 수 없다고 한다(지각성). 마킹된 신호에서의 존재가 분명하지만 비침해적이면, 워터마크는 감지할 수 있다고 한다.
셋째로, 용량에 관해서, 매립된 메시지의 길이는 두 가지 다른 주 부류의 워터마킹 방식을 결정한다.
메시지는 개념상으로 0 비트의 길이를 갖고, 시스템은 마킹된 오브젝트에서 워터마크의 존재 유무를 검출하기 위해 설계된다. 이러한 종류의 워터마킹 방식은 주로 이탤릭 0 비트 또는 이탤릭 존재 워터마킹 방식이라 불린다. 종종 이러한 종류의 워터마킹 방식은 1이 워터마크의 존재를 나타내기 때문에(0은 부재) 1 비트 워터마크라 불린다.
메시지는 n 비트 길이의 스트림이고(n = |m| 또는 M = {0,1}n), 워터마크에서 변조된다. 이러한 종류의 방식은 주로 다중비트 워터마킹 또는 비영비트 워터마킹 방식이라 불린다.
넷째로, 매립 단계에는 몇 가지 방식이 있다. 마킹된 신호가 부가적인 변형에 의해 얻어지면 워터마킹 방법은 대역 확산이라 불린다. 대역 확산 워터마크는 적당히 견고하다고 알려져 있지만, 호스트 간섭으로 인해 낮은 정보 용량을 갖는다고 알려져 있기도 하다. 마킹된 신호가 양자화에 의해 얻어지면 워터마킹 방법은 양자화 타입의 것이라고 한다. 양자화 워터마크는 낮은 견고성을 갖지만, 호스트 간섭의 배제로 인해 높은 정보 용량을 갖는다. 마킹된 신호가 대역 확산법과 유사한 부가적인 변형에 의해 매립되지만 특별히 공간 영역에서 매립되면, 워터마킹 방법은 진폭 변조라 불린다.
도 27은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과 포맷을 나타낸 도면이다.
기존의 자동 콘텐츠 인식 서비스 처리 시스템에 따르면, 방송사가 실시간 서비스를 위한 콘텐츠와 ETV 서비스를 위한 인헨스먼트 데이터를 함께 전송하고, TV 수신기가 콘텐츠와 ETV 서비스를 수신하면, 실시간 서비스를 위한 콘텐츠는 수신될 수 있지만, 인헨스먼트 데이터는 수신되지 못한다.
이 경우, 본 발명의 일 실시예에 따르면, 인터넷 프로토콜 네트워크를 이용한 독립적인 인터넷 프로토콜 시그널링 채널을 통해 기존의 자동 콘텐츠 인식 처리 시스템의 문제를 해결할 수 있다. 즉, TV 수신기는 다채널 방송사업자를 통해 실시간 서비스를 위한 콘텐츠를 수신할 수 있고, 독립적인 인터넷 프로토콜 시그널링 채널을 통해 인헨스먼트 데이터를 수신할 수 있다.
이 경우, 본 발명의 일 실시예에 따르면, 인터넷 프로토콜 시그널링 채널은 PSIP 스트림이 바이너리 스트림의 형태로 전달 및 처리되도록 구성된다. 이때, 인터넷 프로토콜 시그널링 채널은 풀(pull) 방법이나 푸시(push) 방법을 이용하도록 구성된다.
풀 방법의 인터넷 프로토콜 시그널링 채널은 HTTP 요청/응답 방법에 따라 구성될 수 있다. HTTP 요청/응답 방법에 따르면, PSIP 바이너리 스트림은 HTTP 요청 신호에 대한 HTTP 응답 신호에 포함될 수 있고, SignalingChannelURL을 통해 전송될 수 있다. 이 경우, 폴링 사이클은 자동 콘텐츠 인식 쿼리 결과로서 전달된 메타데이터에서 Polling_cycle에 따라 주기적으로 요청될 수 있다. 또한, 갱신될 시간 및/또는 주기에 관련된 정보는 시그널링 채널에 포함되어 전송될 수 있다. 이 경우, 수신기는 인터넷 프로토콜 시그널링 채널로부터 수신한 갱신 시간 및/또는 주기 정보에 근거하여 서버에 시그널링 정보를 요청할 수 있다.
푸시 방법의 인터넷 프로토콜 시그널링 채널은 XMLHTTPRequest 어플리케이션 프로그래밍 인터페이스를 이용하여 구성될 수 있다. XMLHTTPRequest 어플리케이션 프로그래밍 인터페이스가 이용되면, 서버로부터 비동기로 최신 정보를 수신할 수 있다. 이는 수신기 측에서는 XMLHTTPRequest 오브젝트를 통해 서버에게 비주기적으로 시그널링 정보를 요청하는 방법이고, 서버 측에서는 시그널링 정보가 변경되었으면 요청에 응답하여 이 채널을 통해 시그널링 정보를 제공하는 방법이다. 세션의 대기시간에 제한이 있으면, 세션 타임아웃 응답이 생성될 수 있고, 수신기는 세션 타임아웃 응답을 인식하고, 시그널링 정보를 다시 요청하고, 수신기와 서버 사이에서 시그널링 채널을 유지할 수 있다.
인터넷 프로토콜 시그널링 채널을 통해 인헨스먼트 데이터를 수신하기 위해, 수신기는 워터마킹과 핑거프린팅을 이용하여 동작할 수 있다. 핑거프린팅은 콘텐츠 구매자에 관한 정보를 콘텐츠 제공자 대신 콘텐츠에 삽입하는 기술을 말한다. 핑거프린팅이 이용되면, 수신기는 콘텐츠를 확인하기 위해 참조 데이터베이스를 검색할 수 있다. 콘텐츠를 확인한 결과는 자동 콘텐츠 인식 쿼리 결과라 불린다. 자동 콘텐츠 인식 쿼리 결과는 TV 시청자에게 제공된 쿼리를 포함하고, 자동 콘텐츠 인식 기능을 실행하기 위해 쿼리의 정보에 대해 대응할 수 있다. 수신기는 자동 콘텐츠 인식 쿼리 결과에 근거하여 ETV 서비스를 제공할 수 있다.
자동 콘텐츠 인식 쿼리 결과에 관한 정보는 워터마크 기반 자동 콘텐츠 인식 시스템 상에서 오디오/비디오 콘텐츠에 삽입/매립되어 전송될 수 있다. 수신기는 워터마크 추출기를 통해 자동 콘텐츠 인식 쿼리 결과 정보를 추출 및 획득한 후, ETV 서비스를 제공할 수 있다. 이 경우, ETV 서비스는 별도의 자동 콘텐츠 인식 서버 없이 제공될 수 있고, 인터넷 프로토콜 네트워크를 통한 쿼리는 생략될 수 있다.
도 27은 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 쿼리 결과를 나타내는 XML 스키마의 도면이다. 도 3에 나타낸 바와 같이, 자동 콘텐츠 인식 쿼리 결과의 XML 포맷은 결과 코드부(310)를 포함할 수 있고, 자동 콘텐츠 인식 쿼리 결과 타입(300)은 콘텐츠 식별자부(301), NTP(network time protocol) 타임스탬프부(302), 시그널링 채널 정보부(303), 서비스 정보부(304), 기타 식별자부(305)를 포함할 수 있다. 시그널링 채널 정보부(303)는 시그널링 채널 URL부(313), 갱신모드부(323), 폴링 사이클부(333)를 포함할 수 있고, 서비스 정보부(304)는 서비스 네임부(314), 서비스 로고부(324), 서비스 서술부(334)를 포함할 수 있다.
이후, 도 27에 나타낸 자동 콘텐츠 인식 쿼리 결과의 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)는 채널 텍스트 설명을 나타낼 수 있다.
다음은 본 발명의 일 실시예에 따른 도 3에 나타낸 자동 콘텐츠 인식 쿼리 결과의 엘리먼트(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>
도 28는 본 발명의 일 실시예에 따른 콘텐츠 식별자의 구문을 나타낸 도면이다.
도 28는 본 발명의 일 실시예에 따른 ATSC 표준에 따른 콘텐츠 식별자의 구문을 나타낸다. ATSC 콘텐츠 식별자는 수신기에 의해 수신한 콘텐츠를 식별하기 위한 식별자로 사용될 수 있다.
또한 도 28에 도시된 콘텐츠 식별자의 구문은 도 27에서 설명한 자동 콘텐츠 인식 질의 결과 포맷의 콘텐츠 식별자부의 구문이다.
ATSC 콘텐츠 식별자는 유일한 주기를 갖고 TSID(Transmitting Subscriber Identification) 및 하우스 넘버로 구성된 구문이다. 하우스 넘버는 여기에 제약된 바와 같이 TSID의 보유자가 원하는 어떤 넘버이다. 넘버는 TSID의 각각의 값에 대해 유일하다. ATSC 콘텐츠 식별자 구조의 구문은 도 35에 정의된 바와 같다.
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 바이트를 넘지 않도록 하우스 넘버의 형태와 완벽히 일치할 필요는 없다.
또한 본 발명의 일 실시예에 따른 수신기가 도 28에 도시된 콘텐츠 식별자의 구문을 통해 서비스를 전세계적으로 유일하게 식별하지 못할 경우, 본 발명의 일 실시예에수신기는 글로벌 서비스 식별자를 이용하여 서비스를 식별할 수 있다. 본 발명의 일 실시예에 따른 글로벌 서비스 식별자는 도 27에서 설명한 자동 콘텐츠 인식 질의 결과 포맷의 콘텐츠 식별자부에 포함될 수 있다.
이하 [예시 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>는 도 4에서 정의한 end_of_day 필드의 십진 인코딩이다.
상술한 예시들을 통해 정의된 포맷을 가진 ATSC 콘텐츠 식별자는, 자동 콘텐츠 인식 처리 시스템 상에서 컨텐트를 식별하기 위해 사용될 수 있다.
이하 본 발명의 일 실시예에 따른 도 29 및 도 30과 관련하여 워터마킹 및 핑거프린팅 기술을 구현할 수 있도록 설계된 수신기를 살펴본다. 도 29 및 도 30은 설계자의 의도에 따라 다르게 구성될 수 있다.
도 29는 본 발명의 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
구체적으로, 도 29는 워터마킹을 이용하여 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기의 구성의 일례를 나타낸다.
도 29에 나타낸 바와 같이, 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 기반 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 시그널링 테이블을 포함할 수 있다. 더 구체적으로, 도 29에 나타낸 바와 같이, 트랜스포트 프로토콜 디멀티플렉서(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)은 수신한 오디오/비디오 데이터를 처리하여 화면에 표시할 수 있다.
구체적으로, 도 29에 도시된 워터마크 추출기(433)는 외부 입력으로 수신된 오디오/비디오 데이터로부터 워터마크의 형태로 삽입된 데이터(또는 워터마크)를 추출할 수 있다. 워터마크 추출기(433)는 오디오 데이터로부터 워터마크를 추출하거나, 비디오 데이터로부터 워터마크를 추출하거나, 오디오 데이터 및 비디오 데이터로부터 워터마크를 추출할 수 있다. 워터마크 추출기(433)는 추출된 워터마크로부터 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
본 발명의 일 실시예에 따른 수신기는 워터마크 추출기(433)가 획득한 채널 정보 및/또는 콘텐츠 정보를 이용하여, ATSC MH 채널을 튜닝하고 해당 콘텐츠 및/또는 메타데이터를 수신할 수 있다. 또한 본 발명의 일 실시예에 따른 수신기는 인터넷망을 통해 해당 콘텐츠 및/또는 메타데이터를 수신할 수도 있다. 이후에 수신기는 트리거 등을 이용하여 수신된 콘텐츠 및/또는 메타데이터를 디스플레이할 수 있다.
도 30은 본 발명의 또 다른 일 실시예에 따른 수신기의 구조를 나타낸 도면이다.
더 구체적으로, 도 30은 워터마킹을 이용하여 자동 콘텐츠 인식 기반 ETV 서비스를 지원하는 수신기의 구성의 일례를 나타낸다.
도 30에 도시된 본 발명의 일 실시예에 따른 수신기의 기본 구조는 도 29에 도시된 수신기에 기본 구조와 동일하다. 다만, 도 30에 도시된 수신기는 본 발명의 일 실시예에 따라 핑거프린트 추출기(535) 및/또는 핑거프린트 비교기(536)를 더 포함할 수 있다는 차이점이 있다. 또한, 도 30에 도시된 수신기는 도 29에 도시된 구성 엘리먼트 중 워터마크 추출기(433)를 포함하지 않을 수 있다.
도 30의 기본적인 구성은 도 29에 도시된 수신기의 기본적인 구성과 동일하므로 설명을 생략한다. 이하 핑거프린트 추출기(535) 및/또는 핑거프린트 비교기(536)를 중심으로 수신기의 동작을 설명한다.
핑거프린트 추출기(535)은 외부 입력으로 수신된 A/V 콘텐츠에 삽입된 데이터(또는 시그니쳐; signature)를 추출할 수 있다. 본 발명의 일 실시예에 따른 핑거프린트 추출기(535)는 오디오 콘텐츠로부터 시그니쳐를 추출하거나, 비디오 콘텐츠로부터 시그니쳐를 추출하거나, 또는 오디오 콘텐츠 및 비디오 콘텐츠로부터 시그니쳐를 추출할 수 있다.
핑거프린트 비교기(536)는 A/V 콘텐츠에서 추출된 시그니쳐를 이용하여 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다. 본 발명의 일 실시예에 따른 핑거프린트 비교기(536)는 로컬 서치(local search) 및/또는 원격 서치(remote search)를 통해 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
구체적으로 도 30에 도시된 바와 같이, 핑거프린트 비교기(536)가 저장 장치(537)에 엑세스하여 동작하는 루트를 로컬 서치라 한다. 또한 도 30에 도시된 바와 같이, 핑거프린트 비교기(536)가 인터넷 접속 제어 모듈(538)에 엑세스하여 동작하는 루트를 원격 서치라 한다. 이하 로컬 서치 및 원격 서치에 대해 설명한다.
본 발명의 일 실시예에 따른 로컬 서치에 따르면, 핑거프린트 비교기(535)는 추출된 시그니쳐와 저장 장치(537)에 저장되어 있던 기준 핑거프린트를 비교할 수 있다. 기준 핑거프린트는 핑거프린트 비교기(536)가 추출된 시그니쳐를 처리하기 위해 추가적으로 수신하는 데이터이다.
구체적으로, 핑거프린트 비교기(536)는 추출된 시그니쳐와 기준 핑거프린트를 매칭하여 동일한지 여부를 비교하여 채널 정보 및/또는 콘텐츠 정보를 획득할 수 있다.
비교 결과, 추출된 시그니쳐와 기준 핑거프린트가 동일한 경우, 핑거프린트 비교기(536)는 비교 결과를 어플리케이션으로 전달할 수 있다. 어플리케이션은 비교 결과를 이용하여 추출된 시그니쳐와 관련된 채널 정보 및/또는 콘텐츠 정보를 수신기로 전달할 수 있다.
비교 결과, 추출된 시그니쳐와 기준 핑거프린트가 매칭되지 않거나 기준 핑거프린트가 부족한 경우, 핑거프린트 비교기(536)는 ATSC MH 채널을 통해 새로운 기준 핑거프린트를 수신할 수 있다. 이후에 핑거프린트 비교기(536)는 추출된 시그니쳐와 기준 핑거프린트를 다시 비교할 수 있다.
또한 본 발명의 일 실시예에 따른 원격 서치에 따르면, 핑거프린트 비교기(536)는 인터넷 상의 시그너처 데이터베이서 서버로부터 채널 정보 및/또는 콘텐츠 정보를 수신할 수 있다.
구체적으로, 핑거프린트 비교기(536)는 인터넷 접속 제어 모듈(538)을 통해 인터넷 망에 접속하여 시그너처 데이터베이서 서버에 엑세스할 수 있다. 이후에 핑거프린트 비교기(536)는 추출된 시그니쳐를 쿼리 파라미터로서 시그너처 데이터베이서 서버로 전달할 수 있다.
모든 방송국들이 하나의 통합된 시그너처 데이터베이서 서버를 이용할 경우, 핑거프린트 비교기(536)는 해당 시그너처 데이터베이서 서버로 쿼리 파라미터를 전달할 수 있다. 방송국들이 개별적으로 시그너처 데이터베이서 서버를 운영할 경우, 핑거프린트 비교기(536)는 각각의 시그너처 데이터베이스로 쿼리 파라미터를 전달할 수 있다. 또는 핑거프린트 비교기(536)는 둘 이상의 시그너처 데이터베이서 서버에 동시에 쿼리 파라미터를 전달할 수도 있다.
본 발명의 일 실시예에 따른 수신기는 핑거프린트 비교기(536)가 획득한 채널 정보 및/또는 콘텐츠 정보를 이용하여, ATSC M/H 채널을 튜닝하고 해당 콘텐츠 및/또는 메타데이터를 수신할 수 있다. 이후에 수신기는 트리거 등을 이용하여 수신된 콘텐츠 및/또는 메타데이터를 디스플레이할 수 있다.
도 31은 본 발명의 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
구체적으로, 도 31은 퍼스널라이제이션 서비스(개인화 서비스)를 위한 디지털 방송 수신기(또는 수신기)를 포함하는 개인화 방송 시스템을 나타낸다. 본 발명의 일 실시예에 따른 개인화 서비스는 사용자 정보를 기반으로 사용자에게 적합한 콘텐츠를 선별하여 제공하는 서비스이다. 또한 본 발명의 일 실시예에 따른 개인화 방송 시스템은 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 경우이다.
도 31에 도시된 바와 같이 개인화 방송 시스템은 콘텐츠 제공자(또는 방송사; 707) 및/또는 수신기(700)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기(700)는 PDI 엔진(701), 필터링 엔진(702), PDI 기억 장치(703), 콘텐츠 기억 장치(704), 선언 콘텐츠 모듈(705) 및/또는 UI 모듈(User Interface module; 706)을 포함할 수 있다. 또한 도 31에 도시된 바와 같이 본 발명의 일 실시예에 따른 수신기(700)는 콘텐츠 제공자(707)로부터 콘텐츠 등을 수신할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
본 발명의 일 실시예에 따른 콘텐츠 제공자(707)는 콘텐츠, PDI 설문지(PDI 설문지) 및/또는 필터링 기준을 수신기(700)로 전송할 수 있다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지라 불린다. 본 발명의 일 실시예에 따른 PDI 설문지는, 사용자의 프로파일, 인구통계, 흥미 등에 관한 질문(또는 PDI 질문)들을 포함할 수 있다.
수신기(700)는 콘텐츠 제공자(707)로부터 수신한 콘텐츠, PDI 설문지 및/또는 필터링 기준을 처리할 수 있다. 이하 도 31에 도시된 수신기(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)에 저장될 수 있다. 필터링 방법 및 필터링 기준에 대한 구체적인 내용은 도 33 및 도 34과 관련하여 후술한다.
본 발명의 일 실시예에 따른 UI 모듈(706)은 PDI 엔진(701)로부터 수신한 PDI 질문을 디스플레이하고, 해당 PDI 질문에 대해 사용자로부터 PDI 답변을 수신할 수 있다. 사용자는 디스플레이된 PDI 질문에 대해 리모컨을 이용하여 PDI 답변을 수신기(700)측으로 전달할 수 있다. UI 모듈(706)은 수신한 PDI 답변을 PDI 엔진(701)로 전달할 수 있다.
본 발명의 일 실시예에 따른 선언 콘텐츠 모듈(705)은 PDI 엔진(701)에 엑세스하여 PDI 데이터를 획득할 수 있다. 또한 도 31에 도시된 바와 같이, 선언 콘텐츠 모듈(705)은 콘텐츠 제공자(707)가 제공하는 선언 콘텐츠를 수신할 수 있다. 본 발명의 일 실시예에 따른 선언 콘텐츠는 수신기(700)에서 실행되는 어플리케이션에 관한 콘텐츠로서, TDO와 같은 DO를 포함할 수 있다.
또한 도 31에는 도시되지 않았으나, 본 발명의 일 실시예에 따른 선언 콘텐츠 모듈(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)는 필터링된 콘텐츠를 저장할 수 있다.
상술한 바와 같이, 도 31에 도시된 PDI 엔진(701)은 콘텐츠 제공자(707)로부터 PDI 설문지(Questionnaire)를 수신할 수 있다. 수신기(700)는 UI 모듈(706)을 통해 수신한 PDI 설문지의 PDI 질문을 디스플레이하고, 해당 PDI 질문에 대한 PDI 답변을 사용자로부터 수신할 수 있다. PDI 엔진(701)은 PDI 질문 및/또는 PDI 답변을 포함한 PDI 데이터를 필터링 엔진(702)로 전달할 수 있다. 필터링 엔진(702)은 PDI 데이터와 필터링 기준을 통해 콘텐츠를 필터링할 수 있다. 따라서 수신기(700)는 필터링된 콘텐츠를 사용자에게 제공함으로써 개인화 서비스를 구현할 수 있다.
도 32은 본 발명의 다른 일 실시예에 따른 디지털 방송 시스템을 나타낸 도면이다.
구체적으로, 도 32은 개인화 서비스를 위한 수신기를 포함하는 개인화 방송 시스템의 구조를 나타낸 것이다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 이하에서는 개인화 방송 시스템의 구성 엘리먼트들에 대해 설명한다.
도 32에 도시된 바와 같이 개인화 방송 시스템은 콘텐츠 제공자(또는 방송국; 807) 및/또는 수신기(700)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기(800)는 PDI 엔진(801), 필터링 엔진(802), PDI 기억 장치(803), 콘텐츠 기억 장치(804), 선언 콘텐츠 모듈(805), UI 모듈(806), 사용 모니터링 엔진(808) 및/또는 사용 로그 모듈(809)을 포함할 수 있다. 또한 도 31에 도시된 바와 같이 본 발명의 일 실시예에 따른 수신기는 콘텐츠 제공자(807)로부터 콘텐츠 등을 수신할 수 있다. 도 32의 기본적인 모듈들은 도 31의 모듈들과 동일하며, 다만 도 31의 방송 시스템과는 달리 도 32의 방송 시스템은 사용 모니터링 엔진(808) 및/또는 사용 로그 모듈(809)을 더 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 사용 모니터링 엔진(808) 및 사용 로그 모듈(809)을 중심으로 설명한다.
본 발명의 일 실시예에 따른 사용 로그 모듈(809)은 사용자의 방송 서비스 사용 내역에 대한 정보(또는 히스토리 정보)를 저장할 수 있다. 히스토리 정보는 2 이상의 사용 데이터를 포함할 수 있다. 본 발명의 일 실시예에 따른 사용 데이터는 일정 시간 동안 사용자가 어떤 방송 서비스를 이용하였는지에 관한 정보를 의미한다. 구체적으로, 사용 데이터는 오후 9시에 뉴스를 40분간 시청했다는 정보, 오후 11시에 공포 영화를 다운로드했다는 정보 등을 포함할 수 있다.
본 발명의 일 실시예에 따른 사용 모니터링 엔진(808)은 사용자의 방송 서비스 사용 현황을 지속적으로 모니터링할 수 있다. 이후에 사용 모니터링 엔진(808)은 모니터링 결과를 이용하여 사용 로그 모듈(809)에 저장된 사용 데이터를 삭제, 추가 및/또는 수정할 수 있다. 또한 본 발명의 일 실시예에 따른 사용 모니터링 엔진(808)은 사용 데이터를 PDI 엔진(801)로 전달할 수 있으며, PDI 엔진(801)은 전달된 사용 데이터를 이용하여 PDI 데이터를 갱신할 수 있다.
도 33는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 33는, 도 31 및 도 32에서 설명한 개인화 방송 시스템의 필터링 엔진 및 PDI 엔진의 동작을 나타낸 플로우 차트이다.
도 33에 도시된 바와 같이, 본 발명의 일 실시예에 따른 수신기(900)는 필터링 엔진(901) 및/또는 PDI 엔진(902)을 포함할 수 있다. 이하 본 발명의 일 실시예에 따른 필터링 엔진(901) 및 PDI 엔진(902)의 동작을 설명한다. 상술한 수신기의 구조는 설계자의 의도에 따라 달라질 수 있다.
도 31에서 설명한 바와 같이, 콘텐츠를 필터링하기 위해, 본 발명의 일 실시예에 따른 수신기(900)는 필터링 기준과 PDI 데이터를 매칭시켜 비교할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 필터링 엔진(901)은 콘텐츠 제공자로부터 필터링 기준을 수신하고, PDI 엔진(902)에 PDI 데이터를 요청하는 신호(또는 PDI 데이터 요청 신호)를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(902)은 전달된 PDI 데이터 요청 신호에 따라, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색할 수 있다.
도 33에 도시된 필터링 엔진(901)은 기준 ID(identifier)를 포함하는 PDI 데이터 요청 신호를 PDI 엔진(902)으로 전달할 수 있다. 상술한 바와 같이 필터링 기준은 필터링 기준들의 집합으로서, 각각의 필터링 기준은 필터링 기준을 식별하기 위한 기준 ID를 포함할 수 있다. 또한 본 발명의 일 실시예에 따른 기준 ID는 PDI 질문 및/또는 PDI 답변을 식별하기 위해 사용될 수 있다.
PDI 데이터 요청 신호를 수신한 PDI 엔진(902)은 PDI 기억 장치에 엑세스하여 PDI 데이터를 검색할 수 있다. 본 발명의 일 실시예에 따른 PDI 데이터는 PDI 질문 및/또는 PDI 답변을 식별하기 위한 PDI 데이터 ID를 포함할 수 있다. 도 9에 도시된 PDI 엔진(902)은 기준 ID와 PDI 데이터 ID를 매칭시켜 기준 ID와 PDI 데이터 ID가 동일한지 여부를 비교할 수 있다.
매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하고, 이에 대한 값이 동일한 경우, 수신기(900)는 해당 콘텐츠를 다운로드할 수 있다. 구체적으로, 본 발명의 일 실시예에 따른 필터링 엔진(901)은 콘텐츠를 다운로드하기 위한 다운로드 요청 신호를 콘텐츠 제공자에게 전달할 수 있다.
매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하지 않은 경우, 도 33에 도시된 바와 같이 PDI 엔진(902)은 필터링 엔진(901)으로 널(null) ID(identifier)를 전달할 수 있다. 널 ID를 수신한 필터링 엔진(901)은 새로운 PDI 데이터 요청 신호를 PDI 엔진(902)으로 전달할 수 있다. 이 경우 새로운 PDI 데이터 요청 신호는 새로운 기준 ID를 포함할 수 있다.
본 발명의 일 실시예에 따른 수신기(900)는, 상술한 방법에 따라 필터링 기준에 포함된 모든 필터링 기준과 PDI 데이터를 매칭시킬 수 있다. 매칭 결과, 모든 필터링 기준이 PDI 데이터와 매칭되는 경우, 필터링 엔진(901)은 콘텐츠를 다운로드하기 위한 다운로드 요청 신호를 콘텐츠 제공자에게 전달할 수 있다.
도 34은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 34은, 도 31 및 도 32에서 설명한 개인화 방송 시스템의 필터링 엔진 및 PDI 엔진의 동작을 나타낸 플로우 차트이다.
도 34에 도시된 바와 같이, 본 발명의 일 실시예에 따른 수신기(1000)는 필터링 엔진(1001) 및/또는 PDI 엔진(1002)를 포함할 수 있다. 상술한 수신기의 구조는 설계자의 의도에 따라 달라질 수 있다. 도 34에 도시된 필터링 엔진(1001) 및 PDI 엔진(1002)의 기본적인 동작은 도 33에서 설명한 바와 같다.
다만, 필터링 기준과 PDI 데이터의 매칭 결과, 기준 ID와 PDI 데이터 ID가 동일하지 않은 경우, 도 34에 도시된 수신기(1000)는 해당 콘텐츠를 다운로드하지 않는 것을 일 실시예로 할 수 있다.
구체적으로, 본 발명의 필터링 엔진(1001)은 널 ID를 수신할 경우, 새로운 PDI 데이터 요청 신호를 PDI 엔진(1002)에 전달하지 않는 것을 일 실시예로 할 수 있다. 또한 필터링 기준에 포함된 모든 필터링 기준이 PDI 데이터와 매칭되지 않을 경우, 본 발명의 필터링 엔진(1001)은 다운로드 요청 신호를 콘텐츠 제공자에게 전달하지 않는 것을 일 실시예로 할 수 있다.
도 35은 본 발명의 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
상술한 도 31의 개인화 방송 시스템은 개인화 서비스를 제공하기 위해 PDI 데이터를 사용하며, PDI 데이터는 PDI 테이블 형식으로 처리될 수 있다. 설문지 및 특정 사용자에 의해 주어진 답변을 요약한 데이터 구조는 PDI 설문지 또는 PDI 테이블이라 불린다. 데이터 구조는 사용 가능할 때 답변을 포함할 수 있지만, PDI 테이블은 네트워크, 방송사, 또는 콘텐츠 제공자에 의해 제공되므로 답변 데이터를 포함하지 않는다. PDI 테이블에서 엔트리의 질문 부분은 비공식적으로 "PDI-질문" 또는 "PDI-Q"라 불린다. 주어진 PDI 질문에 대한 답변은 비공식적으로 "PDI-A"라 불린다. 필터 기준의 집합은 비공식적으로 "PDI-FC"라 불린다. 본 발명의 PDI 테이블은 XML 스키마로 표현되는 것을 일 실시예로 한다. 본 발명의 일 실시예에 따른 PDI 테이블의 포맷은 설계자의 의도에 따라 변경 가능하다.
도 35에 도시된 바와 같이, 본 발명의 일 실시예에 따른 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)를 포함할 수 있다. 이하 도 35에 도시된 PDI 테이블의 구성 엘리먼트들에 대해 설명한다.
구체적으로, 도 35에 도시된 속성(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 답변을 포함할 수 있다.
도 36는 본 발명의 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로 도 36는, 도 35에서 설명한 PDI 타입 엘리먼트 중 QIA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 36에 도시된 바와 같이, QIA 엘리먼트는 PDI 질문 타입과 관련된 특징에 관한 정보를 지시하는 속성(1210), id 속성(1220), 질문 엘리먼트(1230) 및/또는 답변 엘리먼트(1240)를 포함할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 속성(1210)은 PDI 질문의 언어를 지시하는 lang 속성을 포함할 수 있다. 또한 본 발명의 일 실시예에 따른 QIA 엘리먼트의 속성(1210)은 PDI 답변이 가질 수 있는 최소의 정수값을 지시하는 minInclusive 속성(1230) 및/또는 PDI 답변이 가질 수 있는 최대의 정수값을 지시하는 maxInclusive 속성(1240)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 id 속성(1220)는 PDI 질문 및/또는 PDI 답변을 식별하는 데 사용될 수 있다.
또한 본 발명의 일 실시예에 따른 질문 엘리먼트(1230)는 PDI 질문 자체를 포함할 수 있다. 도 36에 도시된 바와 같이, 질문 엘리먼트(1230)는 PDI 질문에 관한 정보를 지시하는 속성을 포함할 수 있다. 예를 들어, 질문 엘리먼트(1230)는 PDI 질문이 생성된 시간 또는 PDI 질문이 전송된 시간을 지시하는 time 속성(1231) 및/또는 PDI 질문의 유효시간을 지시하는 expiration(만료) 속성(1232)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 답변 엘리먼트(1240)는 PDI 답변 자체를 포함한다. 도 36에 도시된 바와 같이 답변 엘리먼트(1240)는 PDI 답변에 관한 정보를 지시한 속성을 포함할 수 있다. 예를 들어, 도 36에 도시된 바와 같이 답변 엘리먼트(1240)는 각각의 PDI 답변을 인식하기 위해 사용될 수 있는 id 속성(1241) 및/또는 각각의 PDI 답변이 생성되거나 수정된 시간을 지시하는 time 속성(1242)를 포함할 수 있다.
도 37은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 37은 도 35에서 설명한 PDI 타입 엘리먼트 중 QBA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 37에 도시된 바와 같이, QBA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 36에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
도 38는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 38는 도 35에서 설명한 PDI 타입 엘리먼트 중 QSA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 38에 도시된 QSA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 36에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
다만, 다중 선택 질문의 특성에 따라, 본 발명의 일 실시예에 따른 QSA 엘리먼트의 속성은 minChoice 속성(1411) 및/또는 maxChoice 속성(1412)을 더 포함할 수 있다. 본 발명의 일 실시예에 따른 minChoice 속성(1411)은 사용자가 선택할 수 있는 PDI 답변의 최소 개수를 지시할 수 있다. 본 발명의 일 실시예에 따른 maxChoice 속성(1412)은 사용자가 선택할 수 있는 PDI 답변의 최대 개수를 지시할 수 있다.
도 39는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 39은 도 35에서 설명한 PDI 타입 엘리먼트 중 QAA 엘리먼트의 XML 스키마를 나타낸 도면이다.
도 39에 도시된 바와 같이, QAA 엘리먼트를 나타낸 XML 스키마의 기본적인 구성 엘리먼트들은 도 36에서 설명한 바와 동일하므로 구체적인 설명은 생략한다.
도 40은 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 40은 도 35 내지 도 39에서 설명한 PDI 테이블과 마찬가지로 PDI 테이블의 확장된 포맷을 XML 스키마로 나타낸 도면이다.
상술한 바와 같이 본 발명에서는 개인화 서비스를 제공하기 위해 PDI 테이블을 사용하는 것을 일 실시예로 한다. 하지만 동일한 사용자라 하더라도, 사용자가 속한 상황에 따라 선호하는 콘텐츠가 달라질 수 있다.
따라서 본 발명에서는 상술한 문제점을 해결하기 위하여 PDI 테이블에 사용자의 상황 정보를 지시하는 구성 엘리먼트를 더 추가하는 것을 일 실시예로 할 수 있다.
도 40에 도시된 PDI 테이블은 사용자의 상황 정보를 지시하는 구성 엘리먼트로서 상황 엘리먼트(1600)를 더 포함할 수 있다. 도 40에 도시된 PDI 테이블의 기본적인 XML 스키마는 도 35 내지 도 39에서 설명한 바와 동일하므로 구체적인 설명은 생략한다. 이하 상황 엘리먼트(1600)를 설명한다.
본 발명의 일 실시예에 따른 상황 엘리먼트(1600)는 사용자의 상황 정보로서 시간대 및/또는 위치에 관한 정보를 지시할 수 있다. 도 40에 도시된 바와 같이, 상황 엘리먼트(1600)는 시간 엘리먼트(1610), 위치 엘리먼트(1620) 및/또는 사용자의 상황 정보를 나타내는 그 밖의 엘리먼트들을 더 포함할 수 있다. 이하 각 엘리먼트를 설명한다.
본 발명의 일 실시예에 따른 시간 엘리먼트(1610)는 사용자가 속한 지역의 시간과 관련된 정보를 포함할 수 있다. 예를 들어, 본 발명의 일 실시예에 따른 시간 엘리먼트(1610)는 "yyyy-mm-dd" 형식의 시간 정보를 지시하는 time 속성(1610) 및/또는 사용자가 속한 지역의 시간대를 지시하는 timezone 속성(1612)을 포함할 수 있다.
본 발명의 일 실시예에 따른 위치 엘리먼트(1620)는 사용자가 속해 있는 지역의 위치 정보를 포함할 수 있다. 예를 들어, 도 40에 도시된 바와 같이, 장소 엘리먼트(1620)는 해당 위치의 정보를 지시하는 location-desc 속성(1621), 해당 위치의 위도 정보를 지시하는 latitude 속성(1622) 및/또는 해당 위치의 경도 정보를 지시하는 longitude 속성(1623)을 포함할 수 있다.
도 41 및 도 42는 본 발명의 또 다른 일 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 41 및 도 42은, 도 35 내지 도 40에서 설명한 XML 스키마에 따른 PDI 테이블의 일 실시예를 나타낸 도면이다.
도 41 및 도 42은 PDI 테이블 경우 문서의 구조를 정의하는 PDI 테이블이라 불리는 루트 엘리먼트에 대한 XML 스키마 정의를 나타낸다. 본 발명의 일 실시예에 따른 PDI 테이블 경우 문서는 PDI 테이블을 XML 스키마에 따라 구현한 실제 문서를 의미한다.
도 41 및 도 42은 또한 PDI API를 이용하여 DO와 내재된 수신기 사이에서 주고 받을 수 있는 개별 질문을 나타내는 루트 엘리먼트 QIA, QBA, QSA, QTA, 또는 QAA에 대한 XML 스키마 정의도 나타낸다. 본 발명의 일 실시예에 따른 PDI API에 대한 구체적인 내용은 후술한다. 도 41 및 도 42에 나타낸 엘리먼트는 명칭 공간이 "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 경우 문서에서 해당하는 엘리먼트에 대한 연결 또는 기준의 역할을 할 수 있다.
이하 도 41 및 도 42에 도시된 PDI 테이블에 포함된 엘리먼트 및 속성의 시맨틱스(semantics)에 대해 설명한다.
도 41 및 도 42에 도시된 바와 같이, 본 발명의 일 실시예에 따른 PDI 테이블에서는 속성의 명칭 앞에"@"를 표시함으로써 속성과 엘리먼트를 구분할 수 있다.
또한 본 발명의 일 실시예에 따른 PDI 테이블은 PDI 타입 엘리먼트를 포함할 수 있다. 구체적으로, PDI 타입 엘리먼트는 도 35에서 설명한 바와 같이 QIA 엘리먼트, QBA 엘리먼트, QSA 엘리먼트, QTA 엘리먼트 및/또는 QAA 엘리먼트를 포함할 수 있다.
또한 도 41 및 도 42에 도시된 바와 같이, 본 발명의 일 실시예에 따른 PDI 테이블은 질문 타입 엘리먼트와 무관하게 protocolVersion 속성, pdiTableId 속성, pdiTableVersion 속성 및/또는 time 속성을 포함할 수 있다.
QIA, QBA, QSA, QTA and QAA 엘리먼트의 id 속성은 이들 각 엘리먼트의 expiration 속성과 마찬가지로 모두 같은 시맨틱스를 갖는다. 유사하게, 각 A 엘리먼트의 time 속성과 마찬가지로 각 Q 엘리먼트의 lang 속성은 각각 같은 시맨틱스를 갖는다. 또한, id 속성은 도 33에서 상술한 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 속성은 답변이 테이블에 입력된 날짜 및 시간을 나타낼 수 있다.
또한 도 41 및 도 42에 도시되지는 않았으나, 본 발명의 일 실시예에 따른 PDI 테이블은 QIAD 엘리먼트, QBAD 엘리먼트, QSAD 엘리먼트, QTAD 엘리먼트, 및/또는 QAAD 엘리먼트를 더 포함할 수 있다. 상술한 엘리먼트들은 통틀어 QxAD 엘리먼트라 불린다. 이하, QxAD 엘리먼트에 대해 설명한다.
루트 엘리먼트로서의 QIAD 엘리먼트는 QIA 하위 엘리먼트에서 정수 답변 타입의 질문을 포함할 수 있다. QIA는 답변의 최대 및 최소 허용값을 명시하는 선택적 허용치를 포함할 수 있다.
루트 엘리먼트로서의 QBAD 엘리먼트는 질문의 불 답변 타입을 나타낼 것이다.
루트 엘리먼트로서의 QSAD 엘리먼트는 질문의 선택 답변 타입을 나타낼 것이다.
루트 엘리먼트로서의 QTAD 엘리먼트는 질문의 텍스트 답변(서술형 엔트리) 타입을 나타낼 것이다.
루트 엘리먼트로서의 QAAD 엘리먼트는 데이터베이스에서의 엔트리와 같이 다양한 타입의 정보를 보유하도록 사용될 것이다.
또한 도 41 및 도 42에 도시되지는 않았으나, 본 발명의 일 실시예에 따른 각각의 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 엘리먼트에서 질문에 대한 답변을 나타낸다.
도 43 및 도 44는 본 발명의 또 다른 실시예에 따른 PDI 테이블을 나타낸 도면이다.
구체적으로, 도 43 및 도 44은, 도 35 내지 도 40에서 설명한 XML 스키마에 따른 PDI 테이블의 구조를 나타낸 도면이다.
도 43 및 도 44에 도시된 PDI 테이블의 기본적인 구조와 PDI 테이블에 포함된 기본적인 엘리먼트 및 속성의 시맨틱스는 도 41 및 도 42에서 설명한 바와 같다. 다만 도 41 및 도 42에 도시된 PDI 테이블과는 달리, 도 43 및 도 44에 도시된 PDI 테이블은 xactionSetId 속성 및/또는 text 속성을 더 포함할 수 있다. 이하 xactionSetId 속성 및/또는 text 속성을 중심으로 설명한다.
QxA 엘리먼트의 xactionSetId 속성은 질문에 대한 답변을 목적으로 하는 유닛으로 취급되는 집합인 질문의 transactional 집합에 질문이 속하는 것을 나타낸다. 이는 또는 질문이 속하는 transactional 집합에 대한 식별자를 제공한다. 따라서, 같은 xactionSetId 속성의 값을 갖는 PDI 테이블에서의 모든 질문의 집합은 양자택일로 답변된다.
QxA 엘리먼트의 text 속성은 QxA.Q 엘리먼트의 하위 엘리먼트다. text 속성의 값은 사용자에게 제시될 질문 스트링을 나타낼 것이다.
도 45는 본 발명의 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다. 상술한 도 31의 개인화 방송 시스템은 개인화 서비스를 제공하기 위해 필터링 기준을 사용할 수 있다. 도 31, 도 33 및 도 34에서 설명한 필터링 기준은 필터링 기준 테이블 형식으로 처리될 수 있다. 본 발명의 필터링 기준 테이블은 XML 스키마로 표현되는 것을 일 실시예로 한다.
또한, 본 발명의 필터링 기준 테이블은, PDI 데이터와 필터링 기준을 효율적으로 비교하기 위해, PDI 테이블의 포맷과 유사한 포맷을 갖는 것을 일 실시예로 할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 테이블의 포맷은 설계자의 의도에 따라 변경 가능하다.
도 45에 도시된 바와 같이, 본 발명의 일 실시예에 따른 필터링 기준 테이블은 filtering criterion 엘리먼트(1900)를 포함할 수 있으며, filtering criterion 엘리먼트(1900)는 identifier 속성(1901), criterion type 속성(1902) 및/또는 criterion value 엘리먼트(1903)를 포함할 수 있다. 본 발명의 필터링 기준은 상술한 PDI 질문에 대응되는 개념으로 사용될 수 있다. 이하 도 45에 도시된 필터링 기준 테이블의 구성 엘리먼트들에 대해 설명한다.
본 발명의 일 실시예에 따른 filtering criterion 엘리먼트(1900)는 PDI 질문에 대응하는 필터링 기준을 지시할 수 있다.
본 발명의 일 실시예에 따른 identifier 속성(1901)은 필터링 기준에 대응하는 PDI 질문을 식별할 수 있다.
본 발명의 일 실시예에 따른 criterion type 속성(1902)은 필터링 기준의 타입을 지시할 수 있다. 필터링 기준의 타입에 관한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 criterion value 엘리먼트(1903)는 필터링 기준이 가지는 값을 지시할 수 있다. 각 기준값은 PDI 질문에 대한 가능한 답변이다.
구체적으로, 본 발명에 따른 필터링 기준의 타입은 정수 타입, 불 타입, 선택 타입, 텍스트 타입 및/또는 어느 타입 중 하나의 타입을 일 실시예로 할 수 있다.
정수 타입의 필터링 기준(또는 정수 타입 기준)은 정수 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
불 타입의 필터링 기준(또는 불 타입 기준)은 불 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
선택 타입의 필터링 기준(또는 선택 타입 기준)은 선택 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
텍스트 타입의 필터링 기준(또는 텍스트 타입 기준)은 텍스트 타입의 PDI 답변에 대응하는 필터링 기준을 의미한다.
어느 타입의 필터링 기준(또는 어느 타입 기준)은 상술한 네 가지 타입 이외의 모든 형태의 PDI 답변에 대응하는 필터링 기준을 의미한다.
이하 [예시 5]는 도 45에 도시된 필터링 기준 테이블의 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>
도 46은 본 발명의 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로 도 46은, 도 45에서 설명한 필터링 기준 테이블의 확장된 포맷을 XML 스키마로 표현한 도면이다. 도 45에 도시된 필터링 기준의 XML 스키마에 따라 필터링 기준 테이블을 구성할 경우, 본 발명의 일 실시예에 따른 필터링 기준의 타입과 각 타입별 세부 속성을 설정할 수 없다는 문제점이 있다. 따라서 도 46에서는 필터링 기준의 타입을 표현하고, 각 타입별 속성을 설정한 XML 스키마를 제시하고자 한다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 도 46에 따른 XML 스키마에 따라 구성된 필터링 기준 테이블을 이용하여, 보다 정밀하게 콘텐츠를 필터링할 수 있다.
도 46에 도시된 바와 같이, 필터링 기준 테이블은 속성(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)를 포함할 수 있다. 이하 도 46에 도시된 필터링 기준 테이블의 구성 엘리먼트들에 대해 설명한다.
구체적으로, 도 35에 도시된 속성(2000)은 본 발명의 일 실시예에 따른 필터링 기준 테이블 자체의 속성 정보를 지시할 수 있다. 따라서 필터링 기준 테이블이 포함하는 필터링 기준 타입 엘리먼트가 달라지더라도 동일하게 표현될 수 있다. 예를 들어, 본 발명의 실시예에 따른 time 속성(2001)은 필터링 기준이 생성된 시간 또는 갱신된 시간을 지시할 수 있다. 이 경우 서로 다른 필터링 기준 타입 엘리먼트를 포함하는 필터링 기준 테이블들은, 필터링 기준 타입 엘리먼트가 달라지더라도 time 속성(2001)을 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 필터링 기준 테이블은 하나 또는 2 이상의 필터링 기준 타입 엘리먼트를 포함할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 필터링 기준의 타입을 지시할 수 있다. 필터링 기준의 타입은 도 45에서 설명한 바와 같다. 이 경우 필터링 기준 타입 엘리먼트는 리스트 형식으로 표현될 수 있다.
본 발명의 일 실시예에 따른 필터링 기준 타입 엘리먼트는 "QxA" 기준으로 호칭될 수 있으며, 이 경우 "x"는 필터링 기준의 타입에 따라 결정될 수 있다.
도 46에 도시된 바와 같이, 각각의 필터링 기준 타입 엘리먼트는 식별자 속성 및/또는 기준값 엘리먼트를 포함할 수 있다. 도 46에 도시된 식별자 속성 및 기준값 엘리먼트 구체적인 내용은 도 45에서 설명한 바와 같다.
다만 도 46에 도시된 바와 같이, 정수 타입 기준 엘리먼트(2010)는 min integer 속성(2011) 및/또는 max integer 속성(2012)을 더 포함할 수 있다. 본 발명의 일 실시예에 따른 min integer 속성(2011)은 정수 타입의 답변으로 표현된 필터링 기준의 최소값을 지시할 수 있다. 본 발명의 일 실시예에 따른 max integer 속성(2012)은 정수 타입의 답변으로 표현된 필터링 기준의 최대값을 지시할 수 있다.
또한 도 46에 도시된 바와 같이, selection type criterion 엘리먼트(2030) 및/또는 text type criterion 엘리먼트(2040)는 lang 속성(2031)을 포함할 수 있다. 본 발명의 일 실시예에 따른 lang 속성(2031)은 문자열 형태로 표현된 필터링 기준의 값을 지시할 수 있다.
이하 [예시 6]는 도 46에 도시된 필터링 기준 테이블의 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>
도 47은 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로 도 47은 도 45 및 도 46에서 설명한 XML 스키마에 따른 필터링 기준 테이블의 일 실시예를 나타낸 도면이다. 도 47에 도시된 필터링 기준 테이블의 기본적인 구성 엘리먼트들은 도 45 및 도 46에서 상술한 바와 같다. 이하 도 47에 도시된 필터링 기준 테이블에 포함된 엘리먼트 및 속성의 시맨틱스에 대해 설명한다.
도 47에 도시된 바와 같이, 본 발명의 일 실시예에 따른 필터링 기준 테이블에서는 속성의 명칭 앞에"@"를 표시함으로써 속성과 엘리먼트를 구분할 수 있다.
테이블에서 @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 등)의 동일 값을 갖는 용어는 각 타겟 기준에 대한 중간 결과를 얻기 위해 논리합이 되고, 이들 중간 결과는 최종 결과를 결정하기 위해 논리곱이 될 것이다. 최종 결과가 수신기에 대해 "맞음"으로 평가되면, 이는 관련 콘텐츠 아이템이 필터를 통과한 것을 의미한다.
도 48는 본 발명의 또 다른 일 실시예에 따른 필터링 기준 테이블을 나타낸 도면이다.
구체적으로, 도 48에 도시된 필터링 기준 테이블은, 도 47에 도시된 필터링 기준 테이블의 확장된 구조를 나타낸다. 도 48에 도시된 필터링 기준 테이블의 기본적인 구성 엘리먼트들은 도 47에서 설명한 바와 같다. 이하 도 47에서 설명한 필터링 기준 테이블과의 차이점을 중심으로 도 48에 도시된 필터링 기준 테이블을 설명한다.
도 48에 도시된 필터링 기준 테이블은 필터링 기준의 집합의 다양한 경우를 허용한다. 각각의 집합은 필터링 기준의 다양한 경우를 포함한다. 각각의 필터링 기준은 일부 필터링 기준에 대해 제공되는 여러 값을 허용한다. 필터링 논리는 필터링 기준의 집합의 여러 경우 중 "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>
도 49은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 49은, 본 발명의 일 실시예에 따른 수신기가 방송망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 31 내지 도 34에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 33 내지 도 44에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 45 내지 도 48에서 설명한 바와 같다.
도 49에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 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 테이블을 수신할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 49에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 수신기는 먼저 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 데이터를 갱신할 수 있다. 구체적인 내용은 도 31 및 도 32에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 수신기는 SSC(2300)를 통해 SMT(Service Map Table) 및/또는 NRT-IT(Non Real Time Information Table)를 수신할 수 있다. 본 발명의 일 실시예에 따른 SMT는 개인화 서비스를 위한 시그널링 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 NRT-IT는 개인화 서비스를 위한 소식 정보를 포함할 수 있다.
이후에 본 발명의 일 실시예에 따른 수신기는 수신한 SMT 및/또는 NRT-IT를 파싱하여 필터링 기준 기술어를 획득할 수 있다. 수신기는 필터링 기준 기술어를 이용하여, 필터링 엔진(2320)으로 필터링 기준을 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 47 및 도 48에서 구체적으로 설명하였다. 이후에 본 발명의 일 실시예에 따른 필터링 엔진(2320)은 PDI 엔진(2330)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(2330)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(2320)으로 전달할 수 있다. 결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 33 및 도 34에서 구체적으로 설명하였다.
도 50는 본 발명의 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 50는 도 49에서 설명한 PDI 테이블 섹션의 구문이다.
PDI 테이블이 방송 스트림에서 전달되면, 도 49에 정의된 테이블의 XML 형식은 DEFLATE 압축 알고리즘을 이용하여 압축된다. 얻어진 압축된 테이블은 도 50의 테이블에 나타낸 바와 같이 블록으로 구분되어 섹션에 삽입됨으로써 NRT 스타일의 전용 섹션에 요약된다.
결론적으로, 본 발명의 일 실시예에 따른 수신기는 동일한 시퀀스 넘버를 가지는 섹션 번호 순서대로 PDI-Q 경우 문서의 블록을 조합하여 압축을 해제할 수 있다. 본 발명의 일 실시예에 따른 수신기는 압축을 해제한 결과로서 PDI-Q 경우 문서를 생성할 수 있다. 이후에 수신기는 PDI-Q 경우 문서를 본 발명의 일 실시예에 따른 PDI 엔진으로 전달할 수 있다. 구체적인 방법은 도 49에서 상술한 바와 같다.
이하 도 50에 도시된 PDI 테이블 섹션의 구문에 대해 설명한다.
블록은 올림순의 section_number 필드 값의 섹션에 삽입될 것이다. "SSC" 및 "IP 서브넷"이라는 용어는 ATSC NRT 표준에서 정의되므로, 전용 섹션은 PDI 테이블이 관련된 가상 채널의 IP 서브넷의 SSC에서 전달된다. 해당 섹션의 sequence_number 필드는 동일한 SSC에서 전달되는 서로 다른 PDI 테이블 경우를 구별하기 위해 사용된다.
8비트의 table_id 필드는 해당 테이블 섹션이 PDI 테이블 경우에 속하는 것을 식별하기 위해 설정될 것이다. 8비트의 table_id 필드는 해당 테이블 섹션이 PDI 테이블 경우에 속하는 것을 식별하기 위해 설정될 것이다. table_id 필드는 도 50에 도시된 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 경우이다.
도 51는 본 발명의 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 51는 도 49에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 50에서 설명한 바와 같다. 다만, 도 50에 도시된 PDI 테이블 섹션과는 달리, 도 51에 도시된 PDI 테이블 섹션은 sequence_number 필드를 포함하지 않을 수 있다. 이하 도 51에 도시된 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 필드는 밑의 표 에 표현된 답변 타입 코드들을 포함할 수 있다. 밑의 표에 도시된 각각의 답변 타입 코드는, 도 35에서 설명한 PDI 답변들의 타입을 지시할 수 있다.
표 33
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 답변의 실제 내용을 포함할 수 있다.
도 52은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 52은 도 49에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 50 및 도 51에서 설명한 바와 같다. 도 52의 구문을 구성하는 필드들은 도 51의 구문을 구성하는 필드들과 동일하므로, 이하 구체적인 설명은 생략한다.
도 53은 본 발명의 또 다른 일 실시예에 따른 PDI 테이블 섹션을 나타낸 도면이다.
구체적으로 도 53은 도 49에서 설명한 PDI 테이블 섹션의 구문으로서, 기본적인 내용은 도 50 및 도 51에서 설명한 바와 같다. 도 53의 구문을 구성하는 기본적인 필드들은 도 51의 syntax를 구성하는 필드들과 동일하므로, 이하 구체적인 설명은 생략한다.
다만, 도 51의 구문과는 달리, 도 53의 구문은 sequence_number 필드를 더 포함할 수 있다. 본 발명의 일 실시예에 따른 sequence_number 필드에 대한 설명은 도 50에서 상술한 바와 같다.
도 54은 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로, 도 49에서 설명한 개인화 방송 시스템 상의 FLUTE 세션, 필터링 엔진 및/또는 PDI 엔진의 동작에 관한 본 발명의 일 실시예를 나타낸 도면이다.
도 54에 도시된 바와 같이 본 발명의 일 실시예에 따른 개인화 방송 시스템은 FLUTE 세션(2800), 필터링 엔진(2810) 및/또는 PDI 엔진(2820)을 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스 및 차세대 방송 서비스 등을 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
도 49에서 상술한 바와 같이, 본 발명의 일 실시예에 따른 수신기는 FLUTE 세션을 통해 PDI 테이블을 수신할 수 있다. 이하 도 54에서는 본 발명의 일 실시예에 따른 수신기가 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)으로 전달할 수 있다. 구체적인 내용은 도 49에서 설명한 바와 같다.
도 55는 본 발명의 다른 일 실시예에 따른 FDT 경우의 XML 스키마를 나타낸 도면이다.
구체적으로 도 55는 도 54에서 설명한 FDT 경우의 XML 스키마를 나타낸 도면으로서, 이하 상술한 콘텐츠 타입 속성(2900)에 대해 설명한다.
도 55에 도시된 바와 같이, 본 발명의 일 실시예에 따른 FDT 경우는 FDT 경우 자체의 속성 정보를 지시하는 속성(2900) 및/또는 FLUTE 세션을 통해 전송되는 파일을 지시하는 file 엘리먼트(2910)를 포함할 수 있다. 도 55에 도시된 file 엘리먼트(2910)는 파일에 대한 속성 정보를 지시하는 속성을 포함할 수 있다. 도 55에 도시된 바와 같이, file 엘리먼트(2910)는 본 발명의 실시예에 따른 content type 속성(2920)을 포함할 수 있다.
도 54에서 설명한 바와 같이, 본 발명의 실시예에 따른 수신기는 content type 속성(2920)에 포함된 값을 이용하여 PDI-Q 경우 문서를 식별할 수 있다. 예를 들어, 도 55에 도시된 content type 속성(2920)은 "application/atsc-pdiq" 또는 "text/atsc-pdiq+xml"로 표현되는 MIME(Multipurpose Internet Mail Extensions) 프로토콜 형태의 값 등을 가질 수 있다.
도 56은 본 발명의 일 실시예에 따른 캐퍼빌리티 기술어 구문을 나타낸 도면이다.
구체적으로 도 56은 도 49에서 설명한 개인화 방송 시스템에 있어서, 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 식별하기 위한 구문을 나타낸다.
본 발명의 일 실시예에 따른 캐퍼빌리티 기술어는 SMT 서비스 레벨에서의 서비스 또는 NRT-IT 콘텐츠 레벨에서의 콘텐츠가 PDI 테이블인지 아닌지를 나타내기 위해 사용될 수 있다. 본 발명의 일 실시예에 따른 수신기는 해당 정보를 이용하여 서비스/콘텐츠가 PDI 테이블인지 아닌지 알고, 해당 서비스/콘텐츠가 다운로드되어야 하는지를 PDI 엔진을 지원하는 등의 캐퍼빌리티에 따라 판단한다.
하기 표 에 표현된 코드는 PDI 테이블 시그널링에 대한 캐퍼빌리티 기술어에서 capability_code에 추가될 수 있다. 본 발명의 일 실시예에 따른 capablilty_code 값은 다른 값에 할당될 수 없다. 이하 하기 표 에 표시된 capability_code 값은 설계자의 의도에 따라 다르게 설정될 수 있다.
표 34
Capability_code value 의미
... ...
0x4F HE ACC v2 with MPEG Surround
0x50 PDI 테이블(PDI-Q 포함)
... ...
도 57은 본 발명의 일 실시예에 따른 소비 모델을 나타낸 도면이다.
구체적으로 도 57은 도 49에서 설명한 개인화 방송 시스템에 있어서, 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 식별하기 위해, SMT 상에 추가된 필드를 나타낸다.
NRT 서비스 기술어는 NRT SMT의 서비스 레벨에 위치하고, 그 NRT_service_category는 서비스가 PDI 테이블을 제공하면 0x04 (PDI)가 된다. 따라서, 수신기는 필드값이 0x04이면 PDI 테이블이 제공된다고 알 수 있다.
도 57에 도시된 소비 모델의 값은 설계자의 의도에 따라 다르게 설정될 수 있다.
도 58는 본 발명의 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
구체적으로 도 58는 도 49에서 설명한 개인화 방송 시스템 상에서, 본 발명의 일 실시예에 따른 수신기가 필터링 기준 테이블을 수신하기 위한 필터링 기준 기술어의 비트 스트림 구문을 나타낸다.
본 발명의 일 실시예에 따른 필터링 기준은 본 발명의 일 실시예에 따른 수신기가 콘텐츠를 다운로드할지 판단하도록 다운로드 가능한 콘텐츠와 관련된다. ATSC 2.0 환경에는 다운로드 가능한 콘텐츠에 두 가지 카테고리가 있다. 독립형의 NRT 서비스에서의 NRT 콘텐츠 및 부속 쌍방향 데이터 서비스에서 TDO에 의해 사용되는 NRT 콘텐츠 아이템이 그에 해당한다.
이하 도 58에서는 독립형의 NRT 서비스에서의 NRT 콘텐츠를 필터링하기 위한 필터링 기준에 대해 설명한다.
본 발명의 일 실시예에 따른 NRT 서비스 및 콘텐츠 아이템에 대한 필터링 기준에서, 이하에 정의된 필터링 기준 기술어의 하나 이상의 경우는 수신기가 사용자에게 NRT 서비스를 제공할지를 결정하도록 하기 위해 SMT에서 서비스 레벨 기술어 루프에 포함될 수도 있고, 수신기가 해당 특정 콘텐츠 아이템을 다운로드 하여 사용자가 사용 가능하게 할지를 결정하도록 NRT-IT에서 콘텐츠 아이템 레벨 기술어 루프에 포함될 수도 있다.
필터링 기준 기술어의 하나 이상의 경우는 다수의 값이 동일 또는 다른 타겟 기준에 대해 제공되도록 한다. 의도하는 타겟 논리는 동일한 타겟 기준에 대해서 다수 값 사이에서 논리합이고, 서로 다른 타겟 기준 사이에서 논리곱이다.
이하 도 58에 도시된 필터링 기준 기술어의 비트 스트림 구문의 각 필드들의 시멘틱 정의에 대해 설명한다.
8비트 필드인 descriptor_tag 필드는 기술어가 본 발명의 일 실시예에 따른 필터링 기준 기술어라는 것을 나타내기 위해 0xTBD로 설정될 수 있다.
8비트 무부호 정수 필드인 descriptor_length 필드는 descriptor_length 필드 자신에 뒤따르는 바이트 수를 나타낼 수 있다.
8비트 필드인 num_ filter_criteria 필드는 도 58에 나타낸 해당 기술어에 포함된 필터링 기준의 수를 나타낼 수 있다.
8비트 필드인 criterion_id_length 필드는 criterion_id 필드의 길이를 나타낼 수 있다.
가변 길이 필드인 criterion_id 필드는 해당 기술어가 나타나는 가상 채널의 PDI 테이블에서 질문(QIA, QBA, QSA, QTA, 또는 QAA 엘리먼트)의 id 속성에 매칭되는 URI의 형태로 해당 필터링 기준의 식별자를 제공할 수 있다.
3비트 필드인 criterion_type_code 필드는 하기 표 에 따라 해당 기준(질문)의 타입을 제공할 수 있다.
표 35
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 서비스 또는 콘텐츠 아이템이 필터를 통과하고 수신기에 다운로드 될 수 있다는 것을 의미한다.
도 59은 본 발명의 다른 일 실시예에 따른 필터링 기준 기술어 구문을 나타낸 도면이다.
구체적으로 도 59은 도 49에서 설명한 개인화 방송 시스템 상에서, 본 발명의 일 실시예에 따른 수신기가 필터링 기준 테이블을 수신하기 위한 필터링 기준 기술어의 비트 스트림 구문을 나타낸다.
도 59에 도시된 필터링 기준 기술어 구문의 기본적인 내용은 도 58에서 설명한 바와 같다.
그러나, criterion_type_code 필드는 하기 표 에 따라 해당 기준(질문)의 타입을 제공할 수 있다.
표 36
criterion_type_code 값
0x000x010x020x030x04 - 0x07 확보됨정수 타입불 타입스트링 타입(선택 타입/텍스트 타입 포함)향후 ATSC 사용을 위해 확보됨
도 60는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 60는, 본 발명의 일 실시예에 따른 수신기가 방송망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 31 내지 도 34에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 33 내지 도 44에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 45 내지 도 48에서 설명한 바와 같다.
도 60에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 시그널링 서버(3410), 필터링 엔진(3420), PDI 엔진(3430) 및/또는 UI(3440)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다.
본 발명의 일 실시예에 따른 PDI 테이블 및 필터링 기준을 처리하기 위한 필터링 엔진(3420), PDI 엔진(3430) 및/또는 UI(3440)의 동작은 도 49에서 설명한 바와 같다. 이하 도 60에 도시된 시그널링 서버(3410)의 동작을 중심으로 설명한다.
본 발명의 일 실시예에 따른 수신기는 먼저 PDI 테이블 섹션을 수신하기 위한 요청 신호를 시그널링 서버(3410)에 전송할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 쿼리 용어를 이용하여 요청 신호를 전송할 수 있다. 쿼리에 대한 구체적인 내용은 후술한다.
본 발명의 일 실시예에 따른 시그널링 서버(3410)는 해당 쿼리에 따른 PDI 테이블 섹션을 수신기로 전송할 수 있다. PDI 테이블 섹션에 대한 구체적인 내용은 도 50 내지 도 53에서 설명한 바와 같다.
도 61는 본 발명의 일 실시예에 따른 HTTP 요청 테이블을 나타낸 도면이다.
구체적으로 도 61는 본 발명의 일 실시예에 따른 수신기가 도 60에서 설명한 시그널링 서버로 쿼리를 전송하기 위한 HTTP 프로토콜을 나타낸다.
방송사에 의해 지원되면, 도 61에 나타낸 프로토콜은 두 개의 캐퍼빌리티를 제공할 수 있다. 첫째로, 압축되지 않은 오디오 또는 비디오만을 전달하는 경로를 통해 DTV 방송 신호를 받는 장치에 대해, 해당 프로토콜은 일반적으로 방송사의 독립형 NRT 서비스에 접속하는 유일한 방법이다. 둘째로, 완전한 방송 스트림에 접속할 수 있는 장치에 대해서도, 해당 프로토콜은 로컬 방송 영역에서 사용 가능한 모든 방송 스트림을 순환하여 원하는 테이블이 나타나기를 기다리지 않고 프로그램/서비스 가이드를 덧붙이는 데이터를 검색하는 방법을 제공한다. 이는 또한 별도의 튜너를 필요로 하지 않고 시청자가 TV를 시청하고 있는 동안에도 어느 때나 이러한 데이터의 검색을 가능하게 한다.
도 61에 도시된 HTTP 요청 테이블은, 수신하고자 하는 테이블의 종류 및 해당 테이블을 수신하기 위한 베이스 URL을 지시하는 쿼리 용어를 포함할 수 있다.
본 발명의 일 실시예에 따른 수신기는 도 61에 도시된 HTTP 요청 테이블의 쿼리 용어를 이용하여 특정 table을 수신할 수 있다. 구체적으로 본 발명의 일 실시예에 따른 수신기는 "?table=PDIT[&chan=<chan_id>]"라는 쿼리 용어를 이용하여 시그널링 서버에 요청 신호를 보낼 수 있다. 구체적인 내용은 도 60에서 설명한 바와 같다.
도 62은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 62은, 본 발명의 일 실시예에 따른 수신기가 인터넷망을 통해 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템의 플로우 차트이다.
본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 31 내지 도 34에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 33 내지 도 43 및 도 44에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 45 내지 도 48에서 설명한 바와 같다.
인터넷을 통해 전달될 때, PDI 테이블 경우는 HTTP 또는 HTTPS를 통해 전달될 것이다. HTTP 응답 헤더에서 PDI 테이블의 콘텐츠 타입은 "text/xml"이 될 것이다.
인터넷을 통해 PDI 테이블을 검색하기 위해 사용되는 URL은 DTV 자막 방송 채널에서 표준 자막 서비스 #6에서 이동되는 SDOPrivateDataURIString 명령어를 통해 전달될 수도 있고, TPT와 함께 전달되는 UrlList XML 엘리먼트에서 전달될 수도 있다.
TPT(TDO 파라미터 테이블)는 세그먼트의 TDO에 관한 메타데이터 및 그것들을 타겟으로 하는 이벤트를 포함한다. TDO라는 용어는 트리거링된 쌍방향 부가 데이터 서비스에서 트리거에 의해 개시된 DO(Declarative Object) 또는 트리거에 의해 개시된 DO에 의해 개시된 DO 등을 반복하여 지정하기 위해 사용된다. 트리거는 시그널링을 식별하고 쌍방향 이벤트의 재생의 타이밍을 설정하는 기능을 갖는 시그널링 엘리먼트다.
도 62에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 PDI 서버(3600), 콘텐츠 서버(3650) 및/또는 수신기를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 TPT(TDO Parameters Table) 클라이언트(3610), 필터링 엔진(3620), PDI 엔진(3630) 및/또는 UI(3640)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 62에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 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)로 전송할 수 있다.
도 62에 도시된 바와 같이, 본 발명의 일 실시예에 따른 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 데이터를 갱신할 수 있다. 구체적인 내용은 도 31 및 도 32에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 TPT 클라이언트(3610)는 TPT를 파싱하여 필터링 기준을 획득할 수 있다. 도 62에 도시된 바와 같이 TPT 클라이언트(3610)는 필터링 기준을 필터링 엔진(3620)으로 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 47 및 도 48에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(3620)은 PDI 엔진(3630)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3630)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(3620)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 33 및 도 34에서 구체적으로 설명하였다.
결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 보다 상세하게는, TPT 클라이언트(3610)는 필터링 결과를 필터링 엔진(3620)으로부터 수신하고, TDO 및/또는 콘텐츠 다운로드 요청 신호를 콘텐츠 서버(3650)에 전달할 수 있다. 콘텐츠 서버(3650)는 TDO 및/또는 콘텐츠 다운로드 요청 신호에 따라 TDO 및/또는 콘텐츠를 TPT 클라이언트(3610)로 전송할 수 있다.
도 63은 본 발명의 일 실시예에 따른 URL 리스트 테이블 나타낸 도면이다.
구체적으로 도 63은, 본 발명의 일 실시예에 따른 수신기가 인터넷망을 통해 PDI 테이블 및/또는 필터링 기준을 수신하기 위한 URL 정보를 포함한 테이블이다. 본 발명의 일 실시예에 따른 URL 리스트 테이블의 송수신 과정은 도 62에서 구체적으로 설명하였다.
URL 리스트 테이블은 인터넷을 통해 전달될 때 멀티파트(multipart) MIME 메시지의 형태로 TPT와 함께 HTTP를 통해 전달될 수 있다.
인터넷을 통해 전달될 때, TPT는 HTTP를 통해 전달될 수 있다. 현 세그먼트의 TPT에 대한 URL 정보는 DTV 자막 서비스 #6 또는 자동 콘텐츠 인식 서버를 통해 전달되며 트리거에 나타날 수 있다. TPT에 대한 요청에 응답은 현 세그먼트에 대한 TPT만으로 구성될 수도 있고, 요청된 TPT가 첫 번째 파트, 세그먼트에 대한 AMT가 선택적으로 두 번째 파트, UrlList XML 문서가 선택적으로 그 다음 파트인 멀티파트 MIME 메시지로 구성될 수도 있다.
이하, 본 발명의 일 실시예 에 따른 URL 리스트 테이블에 포함된 각 엘리먼트들의 시맨틱스에 대해 설명한다.
도 63에 나타낸 UrlList 엘리먼트는 본 발명의 일 실시예에 따른 수신기에 유용한 URL의 리스트를 포함한다.
도 63에 나타낸 UrlList 엘리먼트의 TptUrl 엘리먼트는 현 쌍방향 부가 서비스에서 추후 세그먼트에 대한 TPT의 URL 정보를 포함할 수 있다. 다수의 TptUrl 엘리먼트가 포함되면, 그것들은 방송에서 세그먼트의 출현 순으로 정렬될 것이다.
도 63에 나타낸 UrlList 엘리먼트의 NrtSignalingUrl 엘리먼트는 수신기가 해당 표준의 섹션 18에 정의된 요청 프로토콜을 이용하여 현 전송 스트림에서 모든 가상 채널에 대한 NRT 시그널링 테이블을 얻을 수 있는 서버의 URL 정보를 포함할 수 있다.
도 63에 나타낸 UrlList 엘리먼트의 UrsUrl 엘리먼트는 수신기가 해당 표준의 섹션 10에 정의된 프로토콜을 이용하여 사용 (시청률 조사) 리포트를 보낼 수 있는 서버의 URL 정보를 포함할 수 있다.
도 63에 나타낸 UrlList 엘리먼트의 PdiUrl 엘리먼트는 PDITable의 URL 정보를 포함할 수 있다. 즉, 본 발명의 일 실시예에 따른 PdiUrl 엘리먼트는, PDI 테이블 및/또는 필터링 기준을 전송할 수 있는 서버의 URL 정보를 지시할 수 있다.
상술한 도 63의 URL 리스트 테이블은 이하의 표 와 같은 포맷으로 구성될 수 있다.
표 37
엘리먼트/속성(@ 포함) 허용된 넘버 데이터 타입 설명 & 값
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
도 64은 본 발명의 일 실시예에 따른 TPT를 나타낸 도면이다.
구체적으로 도 64에 도시된 TPT는, PDI 테이블 및/또는 필터링 기준의 URL 정보를 포함할 수 있다. 본 발명의 일 실시예에 따른 TPT의 송수신 과정은 도 62에서 구체적으로 설명하였다. 이하 TPT에 포함된 필터링 기준에 관한 엘리먼트를 설명한다.
구체적으로, 도 64에 도시된 Filter Criterion 엘리먼트는 필터링 기준에 대한 정보를 포함할 수 있다.
본 발명의 일 실시예에 따른 id 속성은 해당 필터링 기준에 관한 PDI 질문을 지시할 수 있다.
본 발명의 일 실시예에 따른 criterion type 속성은 필터링 기준 타입(또는 필터링 기준 타입 엘리먼트)을 지시할 수 있다. 본 발명의 일 실시예에 따른 필터링 기준의 타입에 관하여는 도 46에서 구체적으로 설명하였다.
본 발명의 일 실시예에 따른 criterion value 속성은 상술한 기준 타입 속성에 따른 필터링 기준의 값을 나타낼 수 있다.
도 65는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 65는, 본 발명의 일 실시예에 따른 수신기가 자동 콘텐츠 인식 시스템 상에서 PDI 테이블 및/또는 필터링 기준 테이블을 수신하기 위한 개인화 방송 시스템을 나타낸 도면이다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 시스템은 도 25에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 개인화 방송 시스템의 기본적인 구조는 도 31 내지 도 34에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 PDI 테이블은 도 33 내지 도 44에서 설명한 바와 같다. 본 발명의 일 실시예에 따른 필터링 기준 테이블은 도 45 내지 도 48에서 설명한 바와 같다.
도 65에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 자동 콘텐츠 인식 서버(3900), TPT 서버(3950), PDI 서버(3960), 콘텐츠 서버(3970), 자동 콘텐츠 인식 클라이언트(3910), 필터링 엔진(3920), PDI 엔진(3930) 및/또는 UI(3940)를 포함할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 65에 도시된 각 구성 엘리먼트들의 동작에 대해 설명한다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 핑거프린트로부터 시그니쳐를 추출하여 시그니쳐와 함께 요청을 자동 콘텐츠 인식 서버(3900)로 전송할 수 있다. 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 서버(3900)는 시그니쳐를 수신하고, 해당 시그니쳐와 연관된 트리거 등과 함께 응답을 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다. 상술한 내용은 도 25 내지 도 30에서 구체적으로 설명하였다.
본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(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)로 전송할 수 있다.
도 60에 도시된 바와 같이, 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(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 데이터를 갱신할 수 있다. 구체적인 내용은 도 31 및 도 32에서 설명한 바와 같다.
또한 본 발명의 일 실시예에 따른 자동 콘텐츠 인식 클라이언트(3910)는 TPT를 파싱하여 필터링 기준을 획득할 수 있다. 도 65에 도시된 바와 같이 자동 콘텐츠 인식 클라이언트(3910)는 필터링 기준을 필터링 엔진(3920)으로 전달할 수 있다. 이 경우 본 발명의 필터링 기준은 xml 문서 포맷의 필터링 기준 테이블을 일 실시예로 할 수 있으며, 필터링 기준 테이블에 대해서는 도 47 및 도 48에서 구체적으로 설명하였다.
이후에 본 발명의 일 실시예에 따른 필터링 엔진(3920)은 PDI 엔진(3930)에 PDI 데이터 요청 신호를 전달할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(3930)은 PDI 데이터 요청 신호를 수신하면, 해당 PDI 데이터 요청 신호에 대응하는 PDI 데이터를 검색하여 필터링 엔진(3920)으로 전달할 수 있다. 본 발명의 일 실시예에 따른 필터링 이후의 과정에 대해서는 도 3 및 도 34에서 구체적으로 설명하였다.
결과적으로, 본 발명의 일 실시예에 따른 수신기는 필터링 결과를 이용하여 콘텐츠를 다운로드할 수 있다. 구체적으로, 자동 콘텐츠 인식 클라이언트(3910)는 필터링 결과를 필터링 엔진(3920)으로부터 수신하고, TDO 및/또는 콘텐츠 다운로드 요청 신호를 콘텐츠 서버(3970)에 전달할 수 있다. 콘텐츠 서버(3970)는 TDO 및/또는 콘텐츠 다운로드 요청 신호에 따라 TDO 및/또는 콘텐츠를 자동 콘텐츠 인식 클라이언트(3910)로 전송할 수 있다.
도 66은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 66은 PDI 답변의 중복 방지를 위한 개인화 방송 시스템의 일 실시예를 나타낸 도면이다.
보다 상세하게, 도 66은 본 발명의 일 실시예에 따른 수신기가 다수의 방송국 및 콘텐츠 제공자들로부터 동일한 PDI 질문을 수신하는 경우, 이미 저장된 PDI 답변을 이용하여 PDI 데이터를 갱신할 수 있는 개인화 방송 시스템을 나타낸다. 도 66에 도시된 개인화 방송 시스템을 통해, 사용자는 동일한 PDI 질문에 대해 중복하여 PDI 답변을 입력하는 번거로움을 줄일 수 있다.
도 66에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 2 이상의 방송국(또는 콘텐츠 제공자) 및/또는 수신기를 포함할 수 있다. 본 발명의 일 실시예에 따른 2 이상의 방송국은 방송국 A(4010) 및/또는 방송국 B(4020)를 포함할 수 있다. 본 발명의 일 실시예에 따른 수신기는 PDI 엔진(4030) 및/또는 UI(4040)를 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 66에 도시된 각 구성 엘리먼트들의 동작을 설명한다.
먼저 본 발명의 일 실시예에 따른 수신기는 방송국 A(4010)로부터 제1 PDI 테이블(4011)을 수신할 수 있다. 제1 PDI 테이블(4011)을 수신한 수신기는 PDI 엔진(4030)으로 제1 PDI 테이블(4011)을 전달할 수 있다. 본 발명의 일 실시예에 따른 제1 PDI 테이블(4011)은 제1 PDI 타입 엘리먼트(4012)를 포함할 수 있다. 본 발명의 일 실시예에 따른 제1 PDI 타입 엘리먼트(4012) 각각은, 도 41 및 도 42 및 도 43 및 도 44에서 상술한 바와 같이 제1 식별자 엘리먼트(또는 제1 ID) 및/또는 제1 PDI 질문을 포함할 수 있다. 또한 도 66에 도시된 바와 같이 제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)의 구체적인 동작은 도 49에서 설명한 바와 같다.
또한, 본 발명의 일 실시예에 따른 PDI 엔진(4030)은 방송국 B(4020)로부터 제2 PDI 테이블(4021)을 수신할 수 있다. 본 발명의 일 실시예에 따른 제2 PDI 테이블(4021)은 제2 PDI 타입 엘리먼트(4022)를 포함할 수 있다. 도 41 및 도 42 및 도 43 및 도 44에서 상술한 바와 같이, 제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 답변을 중복하여 입력할 필요가 없으므로 사용자는 보다 편리하게 개인화 서비스를 제공받을 수 있다.
도 67은 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 67은 PDI 답변의 중복 방지를 위한 개인화 방송 시스템의 일 실시예를 나타낸 도면이다. 도 66에서 설명한 개인화 방송 시스템은 PDI 답변의 중복 방지를 위해, 본 발명의 일 실시예에 따른 수신기에 이미 저장된 PDI 테이블을 이용할 수 있다. PDI 답변의 중복 방지를 위한 또 다른 실시예로서, 도 67에서는 PDI 질문 등록을 통한 개인화 방송 시스템을 제시한다.
소비자들이 본질적으로 동일한 질문에 대해 반복해서 급하게 답하지 않도록 서로 다른 방송사에 의해 질문을 재사용하는 것을 지원하기 위해, 질문은 ATSC에 의해 지정될 레지스트라(registrar)에 등록될 수 있다. 각 등록 기록은 도 41 및 도 42 및 도 43 및 도 44에 명시된 바와 같이 전세계적으로 유일한 질문 ID에 관한 정보, 질문 타입 (QIA, QBA, QSA, 또는 QTA), 하나 이상의 언어로 된 질문 텍스트, 등록 날짜, 및/또는 등록을 위해 질문을 제출한 단체에 대한 연락처 정보를 포함할 수 있다. 또한, QSA의 경우, 각 등록 기록(또는 선등록 PDI 질문)은 각 선택의 식별자와 같은 허용되는 선택, 및 하나 이상의 언어로 된 각 선택의 텍스트를 포함할 수 있다.
PDI 테이블은 등록된 질문 및 등록되지 않은 질문의 혼합을 포함할 수 있다.
등록된 질문 및 등록되지 않은 질문은 모두 다수의 PDI 테이블에 나타날 수 있다. 사용자가 다수의 PDI 테이블에 나타난 질문에 답할 때마다, 수신기가 제공하는 기능에 의하든지 또는 어플리케이션이 제공하는 기능에 의하든지, 답변은 그것이 나타나는 모든 설문지에 있는 질문의 모든 경우에 전파될 것으로 예상된다. 따라서, 사용자는 그것이 서로 다른 설문지에 몇 번 나타나든 어느 주어진 질문에 한 번만 답변하면 된다.
사용자에게 질문이 쇄도하는 것을 방지하기 위해, 설문지 생성자는 가능할 때마다 등록된 질문을 사용하고 등록된 질문을 얻을 수 없는 특별한 타겟 요구가 있을 때만 등록되지 않은 질문을 사용하도록 권장된다.
본 발명의 일 실시예에 따른 수신기는 수신기 타겟 기준을 이용하여 선등록 PDI 질문을 추출할 수 있다. 본 발명의 일 실시예에 따른 수신기 타겟 기준은 ATSC NRT 표준인 A/103에 따른다.
도 67에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 SSC(4100), FLUTE 세션(4110), 필터링 엔진(4120), PDI 엔진(4130) 및/또는 UI(4140)을 포함할 수 있다. 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 상술한 개인화 방송 시스템의 구조는 설계자의 의도에 따라 달라질 수 있다. 이하 도 67에 도시된 개인화 방송 시스템에 대해 설명한다.
본 발명의 일 실시예에 따른 수신기는 SSC(4100)를 통해 SMT 및/또는 NRT-IT를 수신하고, SMT 및/또는 NRT-IT에 포함된 수신기 타겟 기준을 획득할 수 있다. 본 발명의 수신기 타겟 기준은 수신기 타겟 기술어 또는 수신기 타겟 기준 테이블을 일 실시예로 할 수 있다.
이후에 본 발명의 일 실시예에 따른 PDI 엔진(4130)은 획득한 수신기 타겟 기준을 변환하여 PDI 질문을 생성할 수 있다. 본 발명의 일 실시예에 따른 UI(4140)는 PDI 엔진(4130)으로부터 상술한 PDI 질문을 전달받아 디스플레이하고, 사용자의 PDI 답변을 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI 엔진(4130) 및 UI(4140)의 구체적인 동작은 도 49에서 설명한 바와 같다.
도 68는 본 발명의 또 다른 일 실시예에 따른 디지털 방송 시스템의 플로우 차트를 나타낸 도면이다.
구체적으로 도 68는 PDI 질문 등록을 통한 개인화 방송 시스템을 나타낸다.
도 68에 도시된 바와 같이, 본 발명의 일 실시예에 따른 개인화 방송 시스템은 시그널링 서버(4200), 수신기(4210), 필터링 엔진(4220), PDI 엔진(4230) 및 UI(4240)을 포함할 수 있다. 수신기(4210)는 필터링 엔진(4220), PDI 엔진(4230) 및/또는 UI(4240)을 포함하는 개념으로 사용될 수 있으며 이는 설계자의 의도에 따라 변경 가능하다. 또한 본 발명의 일 실시예에 따른 개인화 방송 시스템은 ATSC 2.0 서비스를 제공할 수 있다. 이하 도 67에 도시된 개인화 방송 시스템에 대해 설명한다.
기본적인 구성 엘리먼트들의 동작은 도 67에서 설명한 바와 같다. 다만, 도 68에 도시된 수신기(4210)는 시그널링 서버(4200)에 SMT 및/또는 NRT-IT를 요청할 수 있다. 본 발명의 일 실시예에 다른 수신기(4210)의 요청에 따라, 시그널링 서버(4200)는 해당 SMT 및/또는 NRT-IT를 수신기(4210)로 전송할 수 있다.
본 발명의 일 실시예에 따른 수신기가 SMT 및/또는 NRT-IT를 수신한 이후에, 수신기(4210), PDI 엔진(4230) 및/또는 UI(4240)의 구체적인 동작은 도 67에서 설명한 바와 같다.
도 69은 본 발명의 일 실시예에 따른 수신기 대상 기준 테이블을 나타낸 도면이다.
구체적으로 도 69은 도 67 및 도 68에서 설명한 수신기 타겟 기준을 테이블 형식으로 표현한 도면이다.
도 69에 도시된 바와 같이 수신기 대상 기준 테이블은 타겟 기준 타입 코드(targeting criterion type code), 타겟값 길이(targeting value length) 및/또는 타겟값(targeting value)에 관한 정보를 포함할 수 있다. 도 69에 도시된 타겟 기준 타입 코드는 각각의 타겟 기준을 식별하기 위한 코드를 의미한다. 도 69에 도시된 타겟값 길이는 타겟 기준값을 나타내기 위한 바이트 수를 의미한다. 도 69에 도시된 타겟값은 타겟 기준이 나타내는 정보를 의미한다.
본 발명의 일 실시예에 따른 수신기는 타겟 기준 타입 코드에 따라 타겟 기준을 변환하여 선등록 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인 경우, 타겟값은 사적 사용이 가능하고, 타겟값 길이는 정해지지 않는다.
도 70 내지 도 73은 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 70 내지 도 73은, 도 69에서 상술한 타겟 기준 타입 코드가 0x01인 경우로서, 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 테이블들이다.
도 70 내지 도 73에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 지리적 위치에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 하위 3 바이트만을 사용하여 타겟 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다.
도 70는 타겟 기준 타입 코드가 0x01인 경우로서, 위치 코드(location code)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 70에 도시된 선등록 PDI 질문 table에 포함된 선등록 PDI 질문 정보는 도 67에서 설명한 바와 같다.
구체적으로 도 70에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 위치 코드에 관한 정보를 포함할 수 있다. 또한 도 70에 도시된 선등록 PDI 질문은 QTA 타입으로서, 위치 코드에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 8]는 도 70에 도시된 테이블을 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>
도 71는 타겟 기준 타입 코드가 0x01인 경우로서, FIPS(Federal Information Processing Standards Publication) state에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 71에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 67에서 설명한 바와 같다. 다만 도 71에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 71에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 FIPS state에 관한 정보를 포함할 수 있다. 또한 도 71에 도시된 선등록 PDI 질문은 QTA 타입으로서, FIPS state에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 9]은 도 71에 도시된 테이블을 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>
도 72은 타겟 기준 타입 코드가 0x01인 경우로서, FIPS country에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 72에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 67에서 설명한 바와 같다. 다만 도 72에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 72에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 FIPS country에 관한 정보를 포함할 수 있다. 또한 도 72에 도시된 선등록 PDI 질문은 QTA 타입으로서, FIPS country에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 10]는 도 72에 도시된 테이블을 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>
도 73은 타겟 기준 타입 코드가 0x01인 경우로서, 자치주 세분(county subdivision)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 73에 도시된 선등록 PDI 질문이 포함하는 기본적인 내용은 도 67에서 설명한 바와 같다. 다만 도 73에 도시된 선등록 PDI 질문은 question xactionSetId에 관한 정보를 더 포함할 수 있으며, 본 발명의 일 실시예에 따른 question xactionSetId에 대한 구체적인 내용은 후술한다.
구체적으로 도 73에 도시된 바와 같이, 타겟 기준 타입 코드가 0x01인 경우, 본 발명의 일 실시예에 따른 질문 ID는 자치주 세분에 관한 섹터 정보를 포함할 수 있다. 또한 도 73에 도시된 선등록 PDI 질문은 QSA 타입으로서, 자치주 세분에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 QSA 타입의 선등록 PDI 질문은 PDI 답변에 대한 선택지(selection) 정보를 포함할 수 있다. 예를 들어, 도 73에 도시된 자치주 세분에 관한 선등록 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>
상술한 도 71 내지 도 73에 도시된 question xactionSetId는 유사한 내용을 포함하는 PDI 질문들의 집합을 지시할 수 있다. 본 발명의 일 실시예에 따른 수신기는 동일한 question xactionSetId를 포함하는 선등록 PDI 질문들을 조합하여 개인화 방송 서비스에 이용할 수 있다.
예를 들어, 도 70에 도시된 수신기 타겟 기준은, 동일한 question xactionSetId를 가지는 도 71 내지 도 73의 수신기 타겟 기준으로도 표현될 수 있다. 본 발명의 일 실시예에 따른 수신기는 도 70에 도시된 수신기 타겟 기준 및/또는 도 71 내지 도 73의 수신기 타겟 기준을 조합한 결과를 이용하여 개인화 방송 서비스를 제공할 수 있다.
도 74 및 도 75는 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 74 및 도 75는, 도 69에서 상술한 타겟 기준 타입 코드가 0x02인 경우, 선등록 PDI 질문을 나타낸 테이블들이다.
도 74 및 도 75에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 글자와 숫자로 쓴 우편번호에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 영역에 따른 적절한 수의 바이트를 사용하여 목표 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다. 본 발명의 일 실시예에 따른 수신기는 목표 기준 테이블 변환을 위해 최대 8 바이트를 사용할 수 있다.
도 74은 타겟 기준 타입 코드가 0x02인 경우로서, 다섯 자리 우편 번호에 관한 선등록 PDI 질문을 나타낸 테이블이다. 다섯 자리 우편 번호는 미국에서 사용하는 글자와 숫자로 쓴 우편번호를 의미한다. 도 74에 도시된 선등록 PDI 질문이 포함하는 내용은 도 67에서 설명한 바와 같다.
구체적으로 도 74에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 질문 ID는 우편 번호에 관한 정보를 포함할 수 있다. 또한 도 74에 도시된 선등록 PDI 질문은 QTA 타입으로서, 우편 번호에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 12]은 도 74에 도시된 테이블을 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>
도 75는 타겟 기준 타입 코드가 0x02인 경우로서, 수로 나타낸 우편번호에 관한 선등록 PDI 질문을 나타낸 테이블이다. 수로 나타낸 우편번호는 미국 이외의 지역에서 사용하는 글자와 숫자로 쓴 우편번호를 의미한다. 도 75에 도시된 선등록 PDI 질문이 포함하는 내용은 도 67에서 설명한 바와 같다.
구체적으로 도 75에 도시된 바와 같이, 타겟 기준 타입 코드가 0x02인 경우, 본 발명의 일 실시예에 따른 질문 ID는 우편 번호에 관한 정보를 포함할 수 있다. 또한 도 75에 도시된 선등록 PDI 질문은 QTA 타입으로서, 우편 번호에 대한 텍스트 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 13]은 도 75에 도시된 테이블을 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>
도 76 내지 도 79은 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 도면이다.
구체적으로 도 76 내지 도 79은, 도 69에서 상술한 타겟 기준 타입 코드가 0x03인 경우로서, 본 발명의 일 실시예에 따른 선등록 PDI 질문을 나타낸 테이블들이다.
도 76 내지 도 79에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 타겟 기준 테이블은 사용자의 인구통계 카테고리에 관한 선등록 PDI 질문 정보를 포함할 수 있다. 이 경우 본 발명의 일 실시예에 따른 수신기는 하위 2 바이트만을 사용하여 타겟 기준 테이블을 변환하고 선등록 PDI 질문을 획득할 수 있다.
도 76은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 성별에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 76에 도시된 선등록 PDI 질문이 포함하는 내용은 도 67에서 설명한 바와 같다.
구체적으로 도 76에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 성별에 관한 정보를 포함할 수 있다. 또한 도 76에 도시된 선등록 PDI 질문은 QSA 타입으로서, 사용자의 성별에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 76에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 76에 도시된 성별에 관한 선등록 PDI 질문은, 남성 및 여성에 대한 2가지 선택 정보를 포함할 수 있다.
이하 [예시 14]은 도 76에 도시된 테이블을 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>
도 77은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 연령대(age bracket)에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 77에 도시된 선등록 PDI 질문이 포함하는 내용은 도 67에서 설명한 바와 같다.
구체적으로 도 77에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 연령대에 관한 정보를 포함할 수 있다. 또한 도 77에 도시된 선등록 PDI 질문은 QSA 타입으로서, 연령대에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 77에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 77에 도시된 연령대에 관한 선등록 PDI 질문은, 2-5세, 6-11세, 12-17세, 18-34세, 35-49세, 50-54세, 55-64세, 65세 이상에 대한 8가지 선택 정보를 포함할 수 있다.
이하 [예시 15]은 도 77에 도시된 테이블을 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>
도 78는 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 근로 여부에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 78에 도시된 선등록 PDI 질문이 포함하는 내용은 도 67에서 설명한 바와 같다.
구체적으로 도 78에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 근로에 관한 정보를 포함할 수 있다. 또한 도 78에 도시된 선등록 PDI 질문은 QSA 타입으로서, 사용자의 근로 여부에 관한 선택 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
또한 도 78에 도시된 선등록 PDI 질문은 QSA 타입이므로, PDI 답변에 대한 선택 정보를 포함할 수 있다. 예를 들어, 도 76에 도시된 근로에 관한 선등록 PDI 질문은, 예 및 아니오에 대한 2가지 선택 정보를 포함할 수 있다.
이하 [예시 16]은 도 78에 도시된 테이블을 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>
도 79은 타겟 기준 타입 코드가 0x03인 경우로서, 사용자의 성별에 관한 선등록 PDI 질문을 나타낸 테이블이다. 도 79에 도시된 선등록 PDI 질문이 포함하는 내용은 도 67에서 설명한 바와 같다.
구체적으로 도 79에 도시된 바와 같이, 타겟 기준 타입 코드가 0x03인 경우, 본 발명의 일 실시예에 따른 질문 ID는 근로에 관한 정보를 포함할 수 있다. 또한 도 79에 도시된 선등록 PDI 질문은 QBA 타입으로서, 사용자의 근로 여부에 관한 불 타입의 PDI 답변을 요구하는 내용의 질문 텍스트를 포함할 수 있다.
이하 [예시 17]은 도 79에 도시된 테이블을 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>
도 80는 본 발명의 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 80는 상술한 선언 콘텐츠 오브젝트(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 질문을 관리(예를 들면, 갱신, 추가, 또는 삭제)할 수 있도록 한다.
도 80는 본 발명의 일 실시예에 따른 PDI API를 나타낸 테이블이다. 본 발명의 일 실시예에 따른 수신기는 도 80에 도시된 PDI API를 이용하여 PDI 테이블 리스트를 획득할 수 있다.
이하 도 80에 도시된 API에 대해 설명한다.
도 80에 도시된 API의 명칭은 getPDITableList()로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 80에 도시된 설명은 getPDITableList() API 함수의 상세 내용을 나타낸다. 도 80에 도시된 인수(arguments)는 getPDITableList() API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 80에 나타낸 설명은 getPDITableList() API 함수가 각각에 대해 pdiTableId를 제공하며 PDI 테이블의 리스트를 갖는 XML 구조를 응답한다는 것을 나타낸다. XML 구조는 다음의 XML 스키마와 같다. 하나의 pdiTableId 하위 엘리먼트를 갖는 pdiTableList 엘리먼트는 카디널리티 0을 갖고 무한하다. 0 pdiTableId 경우는 방송사가 PDI 테이블을 제공하지 않았다는 것을 나타낸다.
도 80에 나타낸 인수는 pdiTableId가 PDI 테이블의 전세계적으로 유일한 식별자라는 것을 URI의 형태로 나타낸다.
따라서 본 발명의 일 실시예에 따른 수신기는 XML 스키마에 따른 테이블 포맷의 PDI 테이블 리스트를 수신할 수 있다. 도 80에 도시된 바와 같이, PDI 테이블 리스트는 pdiTableId 엘리먼트를 포함할 수 있다. 도 80에 도시된 pdiTableId 엘리먼트의 카디널리티가 0을 지시할 경우, 본 발명의 일 실시예에 따른 수신기가 방송사로부터 PDI 테이블을 수신하지 않았음을 의미할 수 있다.
도 81는 본 발명의 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 81는 본 발명의 일 실시예에 따른 수신기가 PDI 테이블을 획득하기 위한 PDI API를 나타낸 도면이다.
이하 도 81에 도시된 API에 대해 설명한다.
도 81에 도시된 API의 명칭은 getPDITable(String pdiTableId)로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 81에 도시된 설명은 getPDITable(String pdiTableId) API 함수의 상세 내용을 나타낸다. 도 81에 도시된 인수는 getPDITable(String pdiTableId) API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 81에 나타낸 설명은 getPDITable(String pdiTableId) API 함수가 수신기에 대해 PDI 테이블 XML 문서를 응답하기 위한 것임을 나타낸다. 각 pdiTable은 해당 방법에 대한 입력으로 제공된 전세계적으로 유일한 pdiTableId 식별자에 의해 식별된 것과 관련되어 있다. 응답된 값은 연재된 PDI 테이블 XML 경우를 포함하며 선택적으로 PDI-Q 또는 PDI-A XML 경우를 포함하는 스트링이다.
도 81에 나타낸 인수는 pdiTableId가 PDI 테이블의 전세계적으로 유일한 식별자라는 것을 URI의 형태로 나타낸다.
따라서 본 발명의 일 실시예에 따른 수신기는, 도 80에서 설명한 PDI 테이블 리스트를 수신한 후에, PDI 테이블을 수신할 수 있다. 구체적으로 PDI 테이블 리스트를 수신한 수신기는, 도 80에 도시된 pdiTableId에 연관된 PDI 테이블 XML 문서를 수신할 수 있다.
구체적으로, 도 81에 도시된 PDI API에 따른 수신기의 동작은 도 31 내지 34, 도 49, 도 60, 도 62 및 도 65 내지 도 68에서 설명한 바와 같다. 또한 도 81에 도시된 PDI API에 따른 수신기는 도 35 내지 도 44에서 설명한 PDI 테이블 포맷에 따른 PDI 테이블 리스트를 수신할 수 있다.
도 82은 본 발명의 또 다른 일 실시예에 따른 PDI API를 나타낸 도면이다.
구체적으로 도 82은 본 발명의 일 실시예에 따른 수신기가 PDI 답변을 획득하기 위한 PDI API를 나타낸 도면이다.
이하 도 82에 도시된 API에 대해 설명한다.
도 82에 도시된 API의 명칭은 getPDIA(String pdiTableId)로서, 이는 설계자의 의도에 따라 변경 가능한 사항이다. 도 82에 도시된 설명은 getPDIA(String pdiTableId) API 함수의 상세 내용을 나타낸다. 도 82에 도시된 인수는 getPDIA(String pdiTableId) API 함수의 매개변수를 나타낸다.
더 구체적으로, 도 82에 나타낸 설명은 getPDIA(String pdiTableId) API 함수가 수신기에 대해 PDI-A XML 문서를 응답하기 위한 것임을 나타낸다. 각 pdiTable은 해당 방법에 대한 입력으로 제공된 전세계적으로 유일한 pdiTableId 식별자에 의해 식별된 것과 관련되어 있다. 응답된 값은 연재된 PDI-A XML 경우를 포함하는 스트링이다.
도 82에 나타낸 인수는 pdiTableId가 PDI 테이블의 전세계적으로 유일한 식별자라는 것을 URI의 형태로 나타낸다.
따라서 도 80에서 설명한 PDI 테이블 리스트를 수신한 수신기는, 도 80에 도시된 pdiTableId에 연관된 PDI-A 테이블의 XML 문서(또는 PDI-A 경우 문서)를 수신할 수 있다. 본 발명의 일 실시예에 따른 PDI-A 경우 문서는 도 41 및 도 42에서 설명한 바와 같다.
구체적으로, 도 82에 도시된 PDI API에 따른 수신기의 동작은 도 41 내지 34, 도 49, 도 60, 도 62 및 도 65 내지 도 68에서 설명한 바와 같다.
도 80 내지 82에 나타내지 않았지만, 본 실시예에 따른 PDI API는 아래의 표와 같이 서술할 수 있다.
표 38
Object getPDI(String id)
설명 QxA 하위 엘리먼트가 주어진 식별자 QxA@id에 의해 식별되는 PDI 질문인 PDI QxAD 엘리먼트를 루트 엘리먼트로 포함하는 XML 문서를 나타내는 XML DOM 오브젝트를 응답. 해당 주어진 식별자의 값을 갖는 PDI 질문이 존재하지 않으면, 해당 방법은 널(null)을 응답한다.주의: 질문 식별자의 주어진 값을 갖는 하나의 PDI 질문만이 PDI 기억 장치에 존재할 수 있다. 일관성이 유지되는 한, 하나가 넘는 PDI 테이블은 동일한 질문 식별자의 PDI 질문을 보유할 수 있다.
인수 id PDI 질문의 식별
표 39
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 질문 오브젝트를 나타내는 오브젝트.
도 83 은 본 발명의 일 실시예에 따른, 차세대 방송 시스템을 위한 프로토콜 스택 (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 을 시청자에게 제공할 수 있다.
도 84 은 본 발명의 일 실시예에 따른 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 메쏘드 역시 하나만 사용되어도, 무한한 종류의 액션의 교환이 가능할 수 있다.
도 85 은 본 발명의 일 실시예에 따른 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 방식 등에 국한되지 아니한다.
도 86 는 본 발명의 일 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
전술한 바와 같이, 본 발명은 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 를 기반으로, 수신기와 컴패니언 디바이스간의 커뮤니케이션 실시예를 설명한다. 그러나, 수신기와 컴패니언 디바이스간의 커뮤니케이션 프로토콜은, 이에 한정되지 아니한다.
도 87 은 본 발명의 일 실시예에 따른 PDI 유저 데이터의 일부를 도시한 도면이다.
도 88 은 본 발명의 일 실시예에 따른 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 유저 데이터는 어떠한 형태에 국한되지 아니한다.
도 89 는 본 발명의 일 실시예에 따른 서비스의, 서비스 타입과 서비스 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" 일 수 있다.
도 90 은 본 발명의 일 실시예에 따른 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 는 실시예에 따라 생략될 수도 있다.
도 91 는 본 발명의 일 실시예에 따른 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 유저 데이터의 구조 또는, 실시예에 따라 다른 형태의 구조를 가질 수 있다.
도 92 는 본 발명의 일 실시예에 따른 UserData 서비스의 액션(action)들을 도시한 도면이다.
전술한 UserData 서비스에는 GetPDIUserDataProtocolVersion, GetUserDataIdsList, GetUserData, 및/또는 SetUserData 액션이 있을 수 있다. 여기서, GetPDIUserDataProtocolVersion 는 비필수적(Optional) 한 액션일 수 있고, 나머지 3 개의 액션은 필수적(Required)인 액션일 수 있다. 실시예에 따라, GetPDIUserDataProtocolVersion 는 생략될 수도 있다. 또한 실시예에 따라 추가적인 액션들이 더 정의될 수 있다.
각 액션에 대해서는 후술한다.
도 93 은 본 발명의 일 실시예에 따른 UserData 서비스의 액션들 중, GetPDIUserDataProtocolVersion 를 설명하는 도면이다.
GetPDIUserDataProtocolVersion 액션은 PDI 유저 데이터를 가져오기 위한 프로토콜의 버전이 무엇인지 알기위해 사용되는 액션일 수 있다. 여기서, 프로토콜은 수신기(혹은 Primary Device) 가 지원하고 있는 프로토콜을 의미할 수 있다. 컴패니언 디바이스는 GetPDIUserDataProtocolVersion 액션을 이용하여, 수신기가 지원하는 프로토콜의 버전을 알 수 있다.
GetPDIUserDataProtocolVersion 을 사용하기 위해, PDIUserDataProtocolVersion 아웃풋 아규먼트(argument) 가 정의될 수 있다. PDIUserDataProtocolVersion 는 디바이스에 의해 지원되는 UserData 서비스의 프로토콜 버전 정보로서, 전술한 PDIUserDataProtocolVersion 상태변수와 관련있을 수 있다.
도 94 은 본 발명의 일 실시예에 따른 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) 하면서 요청할 수도 있다.
도 95 은 본 발명의 일 실시예에 따른 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가 요청될 수 있다.
도 96 는 본 발명의 일 실시예에 따른 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 가 함께 저장될 수 있다.
도 97 은 본 발명의 일 실시예에 따른, 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 을 제외한 다음 단계부터 수행될 수 있다.
도 98 은 본 발명의 일 실시예에 따른, 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 등의 액션이 사용될 수 있다.
도 99 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, 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 는 실시예에 따라 생략될 수도 있다. 본 상태변수는 실시예에따라 스트링의 형태일 수 있다.
도 100 은 본 발명의 일 실시예에 따른 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 의 구조 또는, 실시예에 따라 다른 형태의 구조를 가질 수 있다.
도 101 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, UserData 서비스의 액션(action)들을 도시한 도면이다.
전술한 UserData 서비스에는 GetUserDataQAIdsList, GetUserDataQA, 및/또는 SetUserDataQA, 액션이 있을 수 있다. 이 액션들은 필수적(Required)인 액션일 수 있다. 실시예에 따라 추가적인 액션들이 더 정의될 수 있다. 각 액션에 대해서는 후술한다.
도 102 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어단위 전달을 위한, 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) 하면서 요청할 수도 있다.
도 103 는 본 발명의 일 실시예에 따른, 질문과 답변의 페어 단위 전달을 위한, 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 가 함께 저장될 수 있다.
도 104 은 본 발명의 일 실시예에 따른 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을 미리 알고 있어야 한다.
도 105 은 본 발명의 일 실시예에 따른 PDI 유저 데이터가 브로드밴드 채널을 통해 전달되는 상황에서, UserData 서비스의 상태변수를 도시한 도면이다.
본 상태변수들은, 컴패니언 디바이스가 직접 PDI 서버에 요청을 하여 PDI 유저 데이터를 받는 경우의 상태변수들일 수 있다. 이 상황에서, PDIUserDataNotification 및/또는 PDIServerUrl 상태변수가 정의될 수 있다.
PDIUserDataNofitication 상태변수는 브로드밴드채널로 PDI 유저 데이터를 받을 수 있다는 알림을 전달받은 시간을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 dataTime 이며, 이벤트 방식을 따를 수 있다. 이벤트 타입이므로, 알림을 전달받은 시간이 변경되면, 즉 새로이 알림을 받으면, 이를 컴패니언 디바이스에 알릴 수 있다.
PDIServerUrl 상태변수는 브로드밴드채널로 PDI 유저 데이터를 받을 수 있는 PDI 서버의 URL 을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 스트링 또는 anyURI 이며, 액션 방식을 따를 수 있다. 따라서, 컴패니언 디바이스가 액션등을 통해 해당 URL 을 받아와야 할 수 있다. 이에 대해서는 후술한다.
도 106 은 본 발명의 일 실시예에 따른 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 액션이 활용될 수 있다.
도 107 은 본 발명의 일 실시예에 따른, 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 , …,) 등과 같이 표현될 수 있다.
도 108 은 본 발명의 다른 실시예에 따른, 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 일 수 있다.
도 109 는 본 발명의 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
전술한 바와 같이, 사용자가 지정한 PDI 유저 데이터를 이용하여, 개인화된 서비스를 제공할 수 있다. 이를 위하여 필터링 크리테리아(Filtering Criteria) 가 제공될 수 있다. 필터링 크리테리아를 통해 수신기/컴패니언 디바이스는 사용자에게 맞춘 컨텐츠를 제공할 수 있다.
여기서, 컨텐츠 프로바이더 또는 브로드캐스터(t112010), PDI Questionnaires(t112020), PDI 엔진(t112030), PDI 스토어(t112040), PDI 클라우드 스토어(t112070), 컴패니언 디바이스 모듈(t112060), 컴패니언 디바이스(t112080) 는 전술한 동명의 모듈과 같을 수 있다.
여기서, 수신기(t112050) 은 전술한 구조도와 달리 필터링 엔진(t112090), 컨텐츠/서비스 스토어(t112100) 을 더 포함할 수 있다. 필터링 엔진은 각 컨텐츠/서비스의 필터링 크리테리아와, 저장된 PDI 유저 데이터를 비교하여 사용자에게 맞춘 컨텐츠/서비스를 선별할 수 있다. 필터링 크리테리아는 컴패니언 디바이스에도 전달될 수 있다.
실시예에 따라, 필터링 크리테리아에 의해 선별된 데이터가 컴패니언 디바이스에 전달될 수도 있고, 필터링 크리테리아를 컴패니언 디바이스에 전달하여, 컴패니언 디바이스가 직접 필터링을 할 수도 있다.
필터링 크리테리아의 XML 구조에 대해서는 전술하였다. 단, 전술한 구조에 의해 한정되지 아니하며, 실시예에 따라 다른 구조의 필터링 크리테리아가 사용될 수 있다. 이하 필터링 크리테리아는 FC 로 축약하여 불릴 수 있다.
컨텐츠/서비스 스토어(t112050)는 수신한 컨텐츠/서비스를 저장하는 곳이며, 실시예에 따라 필터링 엔진에 의해 필터링된 컨텐츠/서비스가 저장될 수 있다. 또한 실시예에 따라 모든 컨텐츠/서비스가 저장된 후, 추후에 필터링 엔진이 필터링을 수행하여 다시 컨텐츠/서비스 스토어에 저장할 수도 있다.
도 110 은 본 발명의 다른 실시예에 따른 서비스의, 서비스 타입과 서비스 ID 를 도시한 도면이다.
수신기가 컴패니언 디바이스로 필터링 크리테리아를 전달하기 위해서, FilteringCriteria 라는 서비스가 정의될 수 있다. 이 서비스의 서비스 타입은 atsc3.0filtering:1 일 수 있다.
각 서비스는 다른 서비스 ID 를 가질 수 있는 데, 실시예에 따라 uurn:atsc.org:serviceId:atsc3.0filtering1(t113010), 또는 uurn:atsc.org:serviceId:atsc3.0filtering(t113020) 일 수 있다.
FilteringCriteria 서비스에 대해서는 후술한다.
도 111 는 본 발명의 일 실시예에 따른 FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
FiltringCriteria 서비스의 한 상태변수로 FilteringCriteria 상태변수가 정의될 수 있다.
FilteringCriteria 상태변수는 컨텐츠/서비스의 필터링을 위하여, 필터링 크리테리아를 컴패니언 디바이스에 전달하기 위해 사용될 수 있다. FilteringCriteria 상태변수는 필수 상태변수로서 데이터 타입은 String 타입(XML, Jason 등..)일 수 있다. 또한, 전술한 액션 방식을 따라, 다양한 액션에서 사용될 수 있다.
도 112 는 본 발명의 일 실시예에 따른 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 를 가진 컨텐츠/서비스를 유저에게 노출시킬 수 있다.
도 113 은 본 발명의 일 실시예에 따른 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을 미리 알고 있어야 한다.
도 114 은 본 발명의 일 실시예에 따른, FC가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 상태변수를 도시한 도면이다.
본 상태변수들은, 컴패니언 디바이스가 직접 FC 서버에 요청을 하여 FC 를 받는 경우의 상태변수들일 수 있다. 이 상황에서, FilteringCriteriaNotification 및/또는 FCServerUrl 상태변수가 정의될 수 있다.
FilteringCriteriaNotification 상태변수는 브로드밴드채널로 FC를 받을 수 있다는 알림을 전달받은 시간을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 dataTime 이며, 이벤트 방식을 따를 수 있다. 이벤트 타입이므로, 알림을 전달받은 시간이 변경되면, 즉 새로이 알림을 받으면, 이를 컴패니언 디바이스에 알릴 수 있다.
PDIServerUrl 상태변수는 브로드밴드채널로 FC를 받을 수 있는 FC 서버의 URL 을 나타낼 수 있다. 본 상태변수는 필수 상태변수로 데이터 타입은 스트링 또는 anyURI 이며, 액션 방식을 따를 수 있다. 따라서, 컴패니언 디바이스가 액션등을 통해 해당 URL 을 받아와야 할 수 있다. 이에 대해서는 후술한다.
도 115 은 본 발명의 일 실시예에 따른 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 를 전달받아 개인화 서비스를 제공할 수 있다.
도 116 은 본 발명의 일 실시예에 따른 FC 가 브로드밴드 채널을 통해 전달되는 상황에서, FilteringCriteria 서비스의 확장된 상태변수를 설명한 도면이다.
FC 서버는 복수개가 존재할 수 있다. 따라서, FC 서버 URL 역시 복수개가 존재할 수 있다. 수신기는 컴패니언 디바이스가 접속해야할 FC 서버를 특정하여, 그 PDI 서버의 URL 을 전달해 줄 수 있다.
이 때, 접속 가능한 모든 FC 서버의 URL 이 모두 컴패니언 디바이스로 전달될 수도 있다. 이 경우 컴패니언 디바이스가 FC 서버 중 하나를 선택하여 접속할 수 있다. 복수개의 URL 을 전달하기 위하여 전술한 FCServerUrl 을 활용하여 수행될 수 있다. 단 이 경우, FCServerUrl 은 확장되어 데이터 타입이 "List of string" 또는 "List of anyURI" 로 변경될 수 있다.
실시예에 따라, FCServerUrl 는 CSV 형태일 수 있으며, ( , , …,) 등과 같이 표현될 수 있다.
도 117 은 본 발명의 다른 실시예에 따른 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 일 수 있다.
도 118 은 본 발명의 일 실시예에 따른 방송 수신기를 나타낸 도면이다.
본 발명의 일 실시예에 따른 방송 수신기는, 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)는 방송 서비스/컨텐츠 서버 등, 방송 서비스/콘텐츠 제공을 위한 방송 수신기 외부의 모듈들을 지칭한다. 외부 관리 장치의 역할을 수행하는 모듈은 방송 수신기 내부에 구비될 수도 있다.
도 119 는 본 발명의 다른 실시예에 따른 방송 수신기를 나타낸 도면이다.
도시된 수신기는 전술한 수신기 및 수신기에 포함되는 장치와 유사하므로, 동일한 명칭을 가지는 장치에 대한 설명은, 전술한 설명으로 대체한다.
전술한 타겟팅 시그널링 파서 (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)를 더 포함할 수 있다. 유저 데이터 데이터베이스는 처리된 유저 데이터를 저장한다.
도 120 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(Presentation Preference) 를 도시한 도면이다.
프리젠테이션 선호도란, 클로즈드 캡션(closed caption), 오디오(audio), 접근성(Accessibility) 및/또는 수화(Sign Language) 등에 있어, 방송 시청시 해당 클로즈드 캡션등이 보여질 것인지에 관한 선호도를 의미할 수 있다.
유저의 프리젠테이션 선호도가, 개인화된 정보로서 수신기에 저장되면, 방송 시청시 그 유저에 맞춘 서비스 제공이 가능하다. 유저는 관련 정보를 매번 세팅해줄 필요없이, 자신의 선호도(preference)에 맞춰진 서비스를 제공받을 수 있다. 실시예에 따라, 유저 프리젠테이션 선호도는 방송 시청 전, 또는 방송 시청 중에 프리-레지스터드(pre-registered) 될 수 있다.
또한, 설정된 프리젠테이션 선호도는 수신기외에 컴패니언 디바이스들에도 공유되어 활용될 수 있다. 반대로, 컴패니언 디바이스들에서 설정된 프리젠테이션 선호도가 수신기로 공유될 수도 있다.
본 발명에서는 프리젠테이션 선호도 중, 클로즈드 캡션, 오디오, 접근성&수화 프리젠테이션에 대해서 설명한다. 그러나, 프리젠테이션 선호도에 관계된 서비스들은 다양할 수 있으며, 본 발명은 상기 세 항목의 프리젠테이션 선호도에 한정되지 아니한다.
도 121 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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 를 통해 해당 질문에 대한 답변을 다시금 받을 수도 있다. 이 경우 새로운 답변은 기존 답변과 답변 시각 등의 측면에서 비교되고, 새로운 답변이 기존 답변을 대체할 수도 있다.
도 122 는 본 발명의 다른 실시예에 따른 클로즈드 캡션 선호도(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) 은 전술한 바와 같을 수 있다.
도 123 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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 영역으로 전달되는 클로즈드 캡션을 파싱하는 과정에서 사용자에게 보여줄 수 있다.
도 124 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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" 의 답변을 할 수 있다.
도 125 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 언어를 이용하여 클로즈드 캡션을 제공할 수 있다.
도 126 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 폰트를 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 폰트로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 127 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 글자 크기를 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 글자 크기로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 128 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 로 제공되는 정렬 방식을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 정렬 방식으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 129 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 으로 제공되는 프린트 방향을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 프린트 방향으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 130 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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) 으로 제공되는 스크롤 방향을 이용하여 클로즈드 캡션을 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 스크롤 방향으로 강제로 클로즈드 캡션을 변환하여 표시할 수도 있다.
도 131 는 본 발명의 일 실시예에 따른 클로즈드 캡션 선호도(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자의 서버에서 전달받아, 수신기가 이지 리더의 형태로 변환, 표시할 수 있다.
도 132 는 본 발명의 일 실시예에 따른 오디오 선호도(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 를 통해 해당 질문에 대한 답변을 다시금 받을 수도 있다. 이 경우 새로운 답변은 기존 답변과 답변 시각 등의 측면에서 비교되고, 새로운 답변이 기존 답변을 대체할 수도 있다.
도 133 는 본 발명의 다른 실시예에 따른 오디오 선호도(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) 은 전술한 바와 같을 수 있다.
도 134 는 본 발명의 일 실시예에 따른 오디오 선호도(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 들을, 오디오 스트림의 오디오를 파싱하는 과정에서 사용자에게 보여줄 수 있다.
도 135 는 본 발명의 일 실시예에 따른 오디오 선호도(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) 로 제공되는 언어를 이용하여 클로즈드 캡션을 제공할 수 있다.
도 136 는 본 발명의 일 실시예에 따른 오디오 선호도(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" 의 답변을 할 수 있다. 오디오의 청각 장애인을 위한 모드가 제공되지 않는 경우, 수신기는 기본적인 모드로 오디오를 제공할 수 있다.
도 137 은 본 발명의 일 실시예에 따른 오디오 선호도(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" 의 답변을 할 수 있다. 오디오의 시각 장애인을 위한 모드가 제공되지 않는 경우, 수신기는 기본적인 모드로 오디오를 제공할 수 있다.
도 138 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(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) 은 전술한 바와 같을 수 있다.
도 139 은 본 발명의 다른 실시예에 따른 접근성&수화 프리젠테이션(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) 은 전술한 바와 같을 수 있다.
도 140 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션(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 으로 변환하여 사용자에게 보여줄 수 있다.
도 141 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(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" 등의 답변을 할 수 있다.
도 142 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(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) 의 서버에 접근하여 해당 수화 언어 서비스를 전달받아 화면에 표시할 수도 있다.
도 143 은 본 발명의 일 실시예에 따른 접근성&수화 프리젠테이션 선호도(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) 로 제공되는 수화 위치에 수화 서비스를 제공할 수 있다. 또한 실시예에 따라, 수신기는 수신기에서 설정된 위치에 강제로 수화 서비스를 표시할 수도 있다.
도 144 은 본 발명의 일 실시예에 따른 프리젠테이션 선호도(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 스토어에 저장되어, 기 저장된 답변을 업데이트 시킬 수 있다.
도 145 은 본 발명의 또 다른 실시예에 따른 수신기와 컴패니언 디바이스들 간의 유저 데이터 교환의 구조도를 도시한 도면이다.
기존의 PDI 시스템은, 한명의 사용자에게 개인화된 서비스를 제공하는 형태였기 때문에, 복수의 사용자들간의 선호도 및 Q&A 를 관리할 수 없었다. 본 발명에서는 PDI 유저 데이터를 복수의 유저간에 별도로 설정하고, 유저에 따라 개인화된 서비스를 제공하는 방법을 제안한다.
본 구조도에서, 컨텐츠 프로바이더 또는 브로드캐스터, PDI Questionnaires, PDI 엔진, PDI 스토어, PDI 클라우드 스토어, 컴패니언 디바이스 모듈, 컴패니언 디바이스, 필터링 엔진, 컨텐츠/서비스 스토어 는 전술한 동명의 모듈과 같을 수 있다.
본 구조도에서, 수신기(t148020)는 전술한 구조도와 달리 유저 매니지먼트 엔진(User Management Engine)(t148010) 을 더 포함할 수 있다.
유저 매니지먼트 엔진(t148010)은 복수의 사용자간에 PDI 유저 데이터를 관리하는 역할을 할 수 있다. 복수의 사용자마다 선호도가 다를 수 있으므로, 유저 매니지먼트 엔진(t148010)은 사용자를 구분하고, 각 사용자에 맞게 답변 저장 및/또는 필터된 컨텐츠 및 서비스를 전달할 수 있다. 실시예에 따라 유저 매니지먼트 엔진(t148010) 의 동작은 PDI 엔진 또는 별도의 모듈에서 처리될 수도 있다.
도 146 는 본 발명의 일 실시예에 따른, 유저 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 필드가 추가될 수 있다.
도 147 는 본 발명의 일 실시예에 따른, 유저 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 의 답변으로 저장될 수 있다.
도 148 는 본 발명의 일 실시예에 따른, 유저 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 세션이 아닌 다른 소스로부터 다운로드를 받을 수도 있다.
현재 로그인되어 있는 유저에 적합하지 않은 컨텐츠/서비스라 할지라도, 유저 매니지먼트 엔진에 의해 관리되는 유저들 중에 해당 컨텐츠/서비스를 선호하는 유저가 있을 경우, 향후 사용을 위해 해당 컨텐츠/서비스를 다운로드 받아놓을 수도 있다. 유저 매니지먼트 엔진에 의해 관리되는 유저들 중에 해당 컨텐츠/서비스를 선호하는 유저가 하나도 없을 경우, 해당 컨텐츠/서비스를 다운로드 받지 않을 수 있다.
도 149 는 본 발명의 일 실시예에 따른, 유저 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 는 글로벌하게 유니크해질 수 있다.
도 150 은 본 발명의 일 실시예에 따른 채널 혹은 프로그램 추천에 사용할 선호도 크리테리아(Preference Criteria) 의 XML 스키마(Schema)의 다이어그램을 도시한 도면이다.
차세대 방송 시스템에서 제공하는 ESG (Enhancement Service Guide) 는, EPG 와 같은 컨텐츠 편성표 정보를 전달할 수 있다. 이에 추가로, 차세대 방송 시스템에서 제공하는 ESG 는 사용자가 선호할만한 채널 또는 프로그램을 추천할 수도 있다.
이러한 기능을 제공하기 위하여, 전술한 PDI 스토어에 저장된 PDI 유저 데이터가 활용될 수 있다. 전술한 PDI 시스템을 이용하여, 사용자는 PDI 질문에 대해 PDI 답변을 저장하였을 수 있다. 이러한 답변들은 사용자의 선호도가 반영된 채 PDI 스토어에 저장되어 있을 수 있다. 서비스 프로바이더는 송신하는 채널 또는 프로그램마다 그 컨텐츠의 선호도 정보를 태깅(tagging) 할 수 있다. 이 태그 정보를 PDI 스토어의 답변들과 비교하여, 사용자가 선호하는 컨텐츠가 선별될 수 있다. 즉, 사용자가 기 작성한 Q&A 를 이용하여, 사용자의 선호도에 맞는 채널 또는 프로그램이 추천될 수 있다.
본 발명은 PDI 스토어에 저장되어 있는 유저의 PDI Q&A를 통한 ESG 를 제공하는 방안을 제안한다.
전술한 바와 같이 PDI 질문(Question) 들은 QIA, QBA, QSA, QTA, 또는 QTA 타입을 가질 수 있다. QIA 는 정수 형태의 답변이 가능한 Q&A, QBA 는 불리안(Boolean) 형태로 답변이 가능한 Q&A, QSA: 는 선택(Selection) 형태로 답변이 가능한 Q&A, QTA 는 텍스트(Text (string)) 형태로 답변이 가능한 Q&A, QAA 는 그 밖의 형태로 답변이 가능한 Q&A (e.g., image, etc.,) 를 의미할 수 있다.
전술한 것과 같은 다양한 형태의 Q&A 정보가 PDI 스토어에 저장될 수 있다. 따라서, 선호도 크리테리아 역시 각각 타입의 Q&A 에 따른 크리테리온들을 포함할 수 있다. 이는 채널 혹은 프로그램마다 선호도 정보를 태깅할 때, 각 질문 타입에 맞게 태깅할 수 있게 하기 위함일 수 있다.
즉, 도시된 선호도 크리테리아의 XML 다이어그램은 전술한 QIA, QBA, QSA, QTA, 및/또는 QTA 타입의 크리테리온를 포함할 수 있다. 실시예에 따라 선호도 크리테리아는 각 타입의 크리테리온 중 일부만을 포함할 수 있고, 일부 타입의 크리테리온은 생략될 수 있다.
여기서, 선호도 크리테리아는 필터링 크리테리아라고 불릴 수도 있다.
도 151 는 본 발명의 일 실시예에 따른 채널 혹은 프로그램 추천에 사용할 선호도 크리테리아(Preference Criteria) 의 XML 스키마(Schema) 를 도시한 도면이다.
본 도면의 XML 스키마는 전술한 XML 다이어그램의 내용을 XML 문서로 작성한 것일 수 있다.
선호도 크리테리아는 각각 QIA, QBA, QSA, QTA, 및/또는 QTA 타입의 크리테리온을 포함할 수 있다. 각각의 크리테리온은 선호도 값(CriterionValue), 타입(type), 필수여부(required/optional) 등의 정보를 포함할 수 있다.
본 XML 스키마는 일 실시예일 뿐이며, 실시예에 따라 다른 방식으로 작성될 수도 있다.
도 152 는 본 발명의 일 실시예에 따른 채널 혹은 프로그램 추천에 사용할 선호도 크리테리아(Preference Criteria) 의 디스크립터(descriptor) 를 도시한 도면이다.
전술한 선호도 크리테리아는 디스크립터를 통해 바이너리(binary) 형태로도 전달될 수 있다. 선호도 크리테리아의 디스크립터는 전술한 XML 다이어그램의 구조 및 정보들을 각 필드에 담아 전달할 수 있다.
descriptor tag 는 8 비트의 필드로서, 해당 디스크립터가 선호도 크리테리아 디스크립터(preference criteria descriptor) 인지를 지칭할 수 있다. descriptor_length 는 8 비트의 필드로서, 해당 디스크립터의 길이를 나타낼 수 있다. num_preference_criteria 는 8 비트의 필드로서, 해당 디스크립터가 표현하는 선호도 크리테리아가 포함하는 선호도 크리테리온의 개수를 나타낼 수 있다.
선호도 디스크립터는, 그 디스크립터가 포함하는 각각의 선호도 크리테리온들의 정보를 for 문을 이용하여 나타낼 수 있다. for 문은 그 디스크립터가 포함하는 각각의 선호도 크리테리온들의 개수만큼 반복될 수 있다.
criterion_id_length 는 8 비트의 필드로서, 해당 크리테리온의 ID 의 길이를 나타낼 수 있다. criterion_id 는 변경가능한 크기의 필드로서, 해당 크리테리온의 ID 를 나타낼 수 있다. 이 ID 정보는 PDI 질문(Question) ID 와 매핑되어 컨텐츠 선별에 활용될 수 있다.
criterion_type_code 는 3 비트의 필드로서, 해당 크리테리온의 타입을 나타낼 수 있다. 즉, 0x01 의 경우 선택 ID 를 포함하는 정수 타입, 0x02 는 불리안 타입, 0x03 은 스트링 타입을 의미할 수 있다. 0x00, 0x04-0x07 은 추후 사용을 위해 남겨둘 수 있다(reserved). 여기서, 실시예에 따라 0x01 은 해당 크리테리온이 전술한 QIA, QSA 에 해당함을 의미할 수 있고, 0x02 는 QBA 에 해당 크리테리온이 전술한 해당함을 의미할 수 있고, 0x03 은 해당 크리테리온이 전술한 QTA 에 해당함을 의미할 수 있다.
num_criterion_values 는 5 비트의 필드로서, 해당 크리테리온이 가지는 값(value) 의 개수를 의미할 수 있다. 해당 크리테리온이 복수 개의 값을 가질 경우, 각 값들에 대한 정보가 for 문으로 표현될 수 있다.
criterion_value_length 는 해당 값의 길이 정보를 나타내는 필드로서 8비트의 길이를 가질 수 있다. criterion value 는 해당 값을 나타내는 필드로서 변경 가능한 길이를 가질 수 있다. criterion value 는 사용자 추천을 위하여 PDI 유저 데이터의 PDI 답변과 매칭해야될 값을 가질 수 있다.
여기서, 각 필드의 길이 및 포맷은 실시예에 따라 변경될 수 있다.
도 153 은 본 발명의 일 실시예에 따른, 서비스 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마의 확장 다이어그램을 도시한 도면이다.
전술한 선호도 크리테리아는, ESG 를 제공하기 위해 수신기로 전송되는 시그널링 정보(signaling information) 와 함께 전송될 수 있다. 전술한 바와 같이, 선호도 크리테리아는 해당 서비스/컨텐츠가 기 저장된 PDI 유저 데이터에 의해 필터링 또는 선별될 수 있도록 활용될 수 있다. 이를 통해 사용자의 선호도에 맞는 서비스/컨텐츠, 즉 채널/프로그램이 추천될 수 있다.
ESG 를 제공하는 시스템은 채널 혹은 프로그램에 관한 정보들을 전달할 수 있다. 일 실시예로, ESG 를 제공하는 시스템에는 OMA-BCAST 가 있을 수 있다. ESG 를 제공하는 시스템은 채널 혹은 프로그램 별로 인핸스먼트 정보(enhancement information)을 제공하기 위하여, 서비스/컨텐츠 별로 관련 정보를 XML 형태로 전달할 수 있다. 이 채널 혹은 프로그램에 관한 정보들의 XML 은 확장되어, 각각 채널 또는 프로그램에 대한 선호도 크리테리아를 더 포함, 전송할 수 있다.
각각 채널 또는 프로그램에 대해 선호도가 태깅(tagging)되어 수신기로 전달됨으로써, 사용자가 선호하는 서비스/컨텐츠, 즉, 채널/프로그램이 선별될 수 있다.
도시된 서비스 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마의 확장 다이어그램에서, XML 스키마 다이어그램은 해당 서비스에 대한 인핸스먼트 정보, 즉 디스크립션(description), 오디오 언어(AudioLanguage) 등의 정보를 가질 수 있다. 이에 추가로, XML 스키마 다이어 그램은 해당 서비스에 대한 선호도를 태깅한, 선호도 크리테리아를 더 포함할 수 있다(t156010). 이 선호도 크리테리아는 전술한 선호도 크리테리아를 일 실시예로 할 수 있다.
도 154 은 본 발명의 일 실시예에 따른, 서비스 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마를 도시한 도면이다.
이는 전술한, 서비스 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마 다이어그램을 XML 도큐먼트로 나타낸 것이다. 이는 일 실시예일 뿐이며, 본 발명은 본 실시예에 한정되지 아니한다. 전술한 선호도 크리테리아가 마찬가지로 XML 형태로 포함됨을 알 수 있다(t157010).
도 155 은 본 발명의 일 실시예에 따른, 컨텐츠 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마의 확장 다이어그램을 도시한 도면이다.
도시된 XML 스키마 다이어그램은 해당 컨텐츠에 대한 인핸스먼트 정보, 즉 디스크립션(description), 오디오 언어(AudioLanguage) 등의 정보를 가질 수 있다. 이에 추가로, XML 스키마 다이어 그램은 해당 컨텐츠에 대한 선호도를 태깅한, 선호도 크리테리아를 더 포함할 수 있다(t158010). 이 선호도 크리테리아는 전술한 선호도 크리테리아를 일 실시예로 할 수 있다.
도 156 는 본 발명의 일 실시예에 따른, 컨텐츠 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마를 도시한 도면이다.
이는 전술한, 컨텐츠 레벨에서 선호도 크리테리아를 전송하기 위한 XML 스키마 다이어그램을 XML 도큐먼트로 나타낸 것이다. 이는 일 실시예일 뿐이며, 본 발명은 본 실시예에 한정되지 아니한다. 전술한 선호도 크리테리아가 마찬가지로 XML 형태로 포함됨을 알 수 있다(t159010).
도 157 은 본 발명의 일 실시예에 따른, ESG와 함께 전달된 선호도 크리테리아를 이용하여 사용자에게 서비스/컨텐츠 를 추천하는 시퀀스 다이어그램을 도시한 도면이다.
ESG 관련 데이터와 함께 전달받은 선호도 크리테리아와, PDI 스토어에 저장된 PDI 유저 데이터를 비교하여, ESG 내에서 사용자가 선호할만한 서비스/컨텐츠가 추천될 수 있다. 여기서, 사용자는 이미 PDI 질문에 대해 답변하였고, 이 PDI 답변들은 PDI 스토어에 저장된 상태임을 가정한다. 답변을 저장하는 시퀀스는 생략되었다.
컨텐츠 프로바이더 또는 브로드캐스터는 ESG 엔진으로 ESG 정보를 전달할 수 있다(t160010). 여기서 ESG 엔진은 ESG 관련된 데이터 처리를 하는 모듈일 수 있다. ESG 엔진은 수신기 내부 또는 외부에 위치할 수 있다. ESG 엔진이 하는 동작은 다른 모듈에서 처리될 수도 있다. ESG 정보는 브로드캐스터 채널을 통해 전달될 수도 있고, 모바일 또는 브로드밴드 채널을 통해 전달될 수도 있다. 실시예에 따라 ESG 정보는 다른 채널을 통해 전달될 수도 있다.
ESG 엔진은 전달받은 ESG 정보로부터 선호도 크리테리아를 파싱할 수 있다(t160020). 전술한 바와 같이 선호도 크리테리아는 ESG 의 XML 확장의 형태로 전달될 수 있다. 일 실시예에 따르면, 선호도 크리테리아는 ESG 와 별개로 전송될 수도 있다. 이 경우, 선호도 크리테리아는 컨텐츠 프로바이더 또는 브로드캐스터로부터 바로 ESG 엔진으로 전달될 수 있다. ESG 엔진은 서비스/컨텐츠 추천에 활용될 PDI 질문들을 확인할 수 있다.
ESG 엔진은 PDI 엔진에 특정 질문에 대한 답변을 요청할 수 있다(t160030). ESG 엔진이 파싱한 선호도 크리테리아는 전술한 바와 같이 복수개의 크리테리온들을 포함할 수 있다. 각각의 크리테리온에 포함되는 PDI 질문(들)의 답변이 PDI 엔진으로 요청될 수 있다. 이 때, 요청은 PDI 질문의 ID 를 이용하여 수행될 수 있다.
PDI 엔진은 요청받은 PDI 답변들을, PDI 스토어 내에서 검색할 수 있다(t160040). 마찬가지로 PDI 질문의 ID 가 활용될 수 있다. PDI 엔진은, 해당 질문의 답변이 존재할 경우, PDI 스토어로부터 그 답변(들)을 응답받을 수 있다(t160050).
PDI 엔진은 검색한 답변을 ESG 엔진에 전달할 수 있다(t160060). ESG 엔진은 전달받은 PDI 답변 내지 PDI 유저 데이터와, 선호도 크리테리온들을 각각 비교할 수 있다(t160070). 이 선호도 크리테리아는 컨텐츠 프로바이더 또는 브로드캐스터가 서비스/컨텐츠 별로 태깅해 둔 것일 수 있다. 사용자가 실제로 작성한 답변과 선호도 크리테리아를 비교하여, 해당 서비스/컨텐츠가 사용자가 선호할만한 것인지 판단될 수 있다.
ESG 엔진은, 비교작업을 통해, 해당 서비스/컨텐츠가 사용자의 선호도에 맞는 서비스/컨텐츠라고 판단되면 이를 UI 를 통해 사용자에게 노출할 수 있다(t160080). 사용자는 UI 를 통해 ESG 중 추천 서비스/컨텐츠를 제공받을 수 있다.
도 158 은 본 발명의 다른 실시예에 따른, ESG와 함께 전달된 선호도 크리테리아를 이용하여 사용자에게 서비스/컨텐츠 를 추천하는 시퀀스 다이어그램을 도시한 도면이다.
방송망이 수신 안되는 환경에서, 모바일 또는 브로드밴드 채널로도 ESG 정보를 직접 수신하지 못하는 경우에도, ESG 정보를 받아 선호도 크리테리아를 이용한 서비스/컨텐츠 추천이 수행될 수 있다. 여기서, 사용자는 이미 PDI 질문에 대해 답변하였고, 이 PDI 답변들은 PDI 스토어에 저장된 상태임을 가정한다. 답변을 저장하는 시퀀스는 생략되었다.
이 경우 먼저 수신기는, ESG 정보를 전달받을 수 있는 알림(notification)을 받을 수 있다(t161010). 수신기는 ESG 정보 전달 가부에 대한 알림을 받기 위해, 관련된 서비스를 지원받고 있을 수 있다. 수신기는 전달받은 알림을 파싱하여, ESG 서버의 URL 을 추출할 수 있다. 이 동작들은 수신기의 ESG 엔진에서 수행될 수 있다.
ESG 엔진은 ESG 서버의 URL 을 이용하여 ESG 서버에 접근해 ESG 정보를 요청할 수 있다(t161011). ESG 서버는 요청받은 ESG 정보를 ESG 엔진으로 전달할 수 있다. 여기서, ESG 서버는 ESG 정보만을 전달하는 독립적인 역할을 하는 서버일 수도 있고, 시그널링을 위한 각종 정보 및 테이블들이 저장되어 있는 통합 시그널링 서버의 역할을 하는 서버일 수도 있다.
이 후, 수신기는 전달받은 ESG 정보를 이용하여, 선호도 크리테리아를 얻고, 이를 이용하여 사용자의 선호도와 비교하여 서비스/컨텐츠를 추천할 수 있다. 이러한 과정(t161020-t161080) 은 전술한 바와 같을 수 있다.
도 159 는 본 발명의 일 실시예에 따른, 선호도 크리테리아와 PDI 유저 데이터를 비교하는 방법을 도시한 도면이다.
전술한 바와 같이, 기 저장된 사용자의 선호도 정보와, 선호도 크리테리아를 이용하여, 선호도에 맞는 서비스/컨텐츠가 추천될 수 있다.
선호도 크리테리아의 일 실시예(t162010)는 QSA 크리테리온 2개와 QBA 크리테리온 1개를 포함할 수 있다.
본 실시예에서, 선호도 크리테리아는 사용자의 연령대에 관한 정보를 가지는 QSA 크리테리온을 포함할 수 있다. 본 실시예에서, 사용자의 연령대에 관한 정보를 가지는 QSA 크리테리온이 4 의 값을 가지므로, 해당 서비스/컨텐츠는 18세에서 34세의 사용자에 적합한 컨텐츠임을 알 수 있다.
마찬가지로, 본 실시예에 따른 선호도 크리테리아는 사용자의 성별에 관한 정보를 가지는 QSA 크리테리온을 포함할 수 있다. 본 실시예에서, 사용자의 성별에 관한 정보를 가지는 QSA 크리테리온이 1 의 값을 가짐으로, 해당 서비스/컨텐츠는 남자에 의해 더 선호될 수 있는 컨텐츠임을 알 수 있다.
또한, 본 실시예에 따른 선호도 크리테리아는 사용자의 직업 유무에 관한 정보를 가지는 QBA 크리테리온을 포함할 수 있다. 본 실시예에서, 사용자의 직업 유무에 관한 정보를 가지는 QBA 크리테리온이 TRUE 의 값을 가짐으로, 해당 서비스/컨텐츠는 직업을 가지는 사용자에 의해 더 선호될 수 있는 컨텐츠임을 알 수 있다.
PDI 스토어에 저장된 PDI 유저 데이터의 일 실시예(t162020)은 각각 QSA 타입의 Q&A 2개와, QBA 타입의 Q&A 1개를 포함할 수 있다.
본 실시예에서, PDI 스토어는 사용자의 연령대에 관한 정보를 가지는 PDI 유저 데이터, 즉 사용자의 PDI 답변을 가질 수 있다. 본 실시예에서, 사용자는 4 라고 대답했으므로, 사용자는 18세에서 34세 사이의 연령임을 알 수 있다.
또한, 본 실시예에서, PDI 스토어는 사용자의 성별에 관한 정보를 가지는 PDI 유저 데이터, 즉 사용자의 PDI 답변을 가질 수 있다. 본 실시예에서, 사용자는 2 라고 대답했으므로, 사용자는 여성임을 알 수 있다.
또한, 본 실시예에서, PDI 스토어는 사용자의 직업 유무에 관한 정보를 가지는 PDI 유저 데이터, 즉 사용자의 PDI 답변을 가질 수 있다. 본 실시예에서, 사용자는 TRUE 라고 대답했으므로, 사용자는 직업을 가지고 있음을 알 수 있다.
선호도 크리테리아의 실시예(t162010)과 PDI 스토어에 저장된 PDI 유저 데이터의 실시예(t162020)를 비교해보면, 연령대와 직업유무는 일치하나, 성별에 관한 정보고 매칭되지 않음을 알 수 있다. 이러한 비교, 매칭 작업은 전술한 바와 같이 선호도 크리테리온의 ID 와 매칭되는 PDI 질문 및 그에 따른 PDI 답변이 있을 경우에 수행될 수 있다. 실시예에 따라, 해당 PDI 데이터가 저장되어 있지 않을 경우, 사용자에 질의할 수 있다.
사용자에게 서비스/컨텐츠를 추천해주기 위한 기준은 다양하게 설정될 수 있다.
크게, 선호도 크리테리온의 값들과 PDI 질문의 답변이 모두 일치될 경우 해당 서비스/컨텐츠를 사용자에 추천할 수 있다. 또한, 선호도 크리테리온의 값들과 PDI 질문의 답변이 일부가 일치될 경우 해당 서비스/컨텐츠를 사용자에 추천할 수 있다. 또한, 선호도 크리테리온의 값들과 PDI 질문의 답변이 일치되는 항목이 몇 퍼센트 이상일 경우 해당 서비스/컨텐츠를 사용자에 추천할 수 있다. 또한, 선호도 크리테리온의 값들과 PDI 질문의 답변이 어느 수준 이상 유사하게 매칭될 경우(예를 들어 연령대 값이 2 이하로 차이날 경우), 해당 서비스/컨텐츠를 사용자에 추천할 수 있다. 또한, PDI 데이터에 비중을 다르게 두어, 어떤 특정 PDI 데이터가 선호도 크리테리온의 값과 일치하면 다른 항목의 일치여부와 무관하게 추천되게 할 수도 있다. 이러한 기준은 다양하게 설정될 수 있으며, 상기 제시된 내용들이 조합되어 사용될 수도 있다.
모두 일치될 경우에만 서비스/컨텐츠를 추천할 경우, 상기 실시예(t162010, t162020)에서, 성별이 매칭되지 않으므로, 상기 실시예의 서비스/컨텐츠는 추천될 수 없다. 일부만 일치되어도 서비스/컨텐츠를 추천할 경우, 상기 실시예의 서비스/컨텐츠는 성별이 맞지 않음에도 추천될 수 있다.
도 160 은 본 발명의 일 실시예에 따른, 선호도 크리테리아와 PDI 유저 데이터를 비교하기 위한 매칭 바운더리(matching boundary) 필드를 도시한 도면이다.
전술한 바와 같이, 사용자에게 서비스/컨텐츠를 추천해주기 위한 기준이 다양하게 설정될 수 있다. 실시예에 따라 이 기준은 수신기에서 사용자에 의해 설정되어, 수신기에 저장될 수 있다. 또 다른 실시예에 따르면, 이 기준은 서비스 프로바이더 또는 브로드캐스터에 의해 선호도 크리테리아에 담겨 함께 수신기로 전달될 수도 있다.
사용자에게 서비스/컨텐츠를 추천해주기 위한 기준이 선호도 크리테리아에 담겨 수신기에 전달될 경우, 이 기준에 관련된 정보는 매칭 바운더리 필드(matching boundary) 에 의해 전송될 수 있다(t163010).
수신기는 매칭 바운더리 필드를 파싱한 후, 이에 따라 사용자에게 서비스/컨텐츠를 추천해줄 수 있다. 매칭 바운더리 필드가 가지는 정보는 다양한 형태를 띌 수 있으며, 이 정보는 전술한 추천 기준에 관한 정보일 수 있다.
본 발명의 일 실시예에 따르면, 매칭 바운더리 필드는 특정 개수 정보를 가질 수 있다. 사용자가 설정한 답변과 매칭되는 크리테리온의 개수가 매칭 바운더리 필드가 나타내는 특정 개수보다 많을 경우, 해당 서비스/컨텐츠가 사용자에게 추천될 수 있다. 이는 매칭 바운더리 필드의 일 실시예일 뿐이며, 매칭 바운더리 필드가 수신기에 추천 기준을 전달하는 방식은 실시예에 따라 달라질 수 있다.
도 161 는 본 발명의 일 실시예에 따른, 추천된 서비스/컨텐츠를 제공하는 UI 를 도시한 도면이다.
전술한 바와 같이, PDI 스토어의 PDI 유저 데이터와 ESG 의 선호도 크리테리아를 이용하여 서비스/컨텐츠가 선별될 수 있다. ESG 중에서 선별된 서비스/컨텐츠는, 수신기의 UI 를 통하여 사용자에게 노출될 수 있다.
특정 채널(e.g. 채널 7)이 추천되는 경우에는 그 특정 채널이 ESG 내에서 하이라이트되어 표시될 수 있다(t164010). 마찬가지로 특정 프로그램, 컨텐츠(e.g. 프로그램 A, F) 가 추천되는 경우에는 그 특정 프로그램이 ESG 내에서 하이라이트되어 표시될 수 있다(t164020).
실시예에 따라, 추천되는 채널, 프로그램은 ESG 의 추천 전용 페이지 UI 를 통해, 사용자에게 노출될 수 있다(t164030). 이 경우 ESG 의 추천 항목 내에서, 추천되는 채널(e.g. 채널 7, 12, 24), 및/또는 추천되는 프로그램(e.g. 프로그램 A, F, H, T, X) 이 리스팅되어 표현될 수 있다.
여기서, 채널은 서비스, 프로그램은 컨텐츠에 대응될 수 있다. 그러나, 문맥에 따라 채널, 서비스, 프로그램, 컨텐츠 등의 용어는 혼용될 수 있다.
실시예에 따라, 본 명세서에서 전술한 상태변수 PDIUserDataProtocolVersion 는 UserDataProtocolVersion 로 불릴 수 있다.
또한, 실시예에 따라, 본 명세서에서 전술한 상태변수 A_ARG_TYPE_UserDataIdsList 는 UserDataIdsList 로 불릴 수 있다.
또한, 실시예에 따라, 본 명세서에서 전술한 상태변수 UserDataList 는 UserData 로 불릴 수 있다.
또한, 실시예에 따라, 본 명세서에서 전술한 상태변수 A_ARG_TYPE_UserDataQAIdsList 는 UserDataQAIdsList 로 불릴 수 있다.
또한, 실시예에 따라, 본 명세서에서 전술한 상태변수 UserDataQAList 는 UserDataQA 로 불릴 수 있다.
도 162 는 자동답변에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 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) 정보, 또는 사용자의 시청 히스토리 정보 등이 있을 수 있다.
도 163 은 재답변 인터벌에 관한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 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)에 정의될 수 있다.
도 164 는 자동답변 가능한 질문을 보충 질문으로 대체하기 위한 정보를 포함하는, 본 발명의 또 다른 실시예에 따른 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 값이 설정될 수 있다.
도 165 는 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 보충 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
먼저, 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 유저 데이터에 저장할 수 있다. 기존 답변이 있는 경우, 새로운 답변으로 업데이트하거나, 기존 답변에 더하여 새 답변을 추가할 수 있다.
도 166 은 자동답변 가능한 질문을 대체 질문으로 대체하기 위한 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 질문을 서비스 프로바이더 측으로부터 전달받은 경우, 수신기는 대체 질문을 사용자에게 노출시켜 답변을 유도할 수 있다. 실시예에 따라, 대체질문 역시 자동 답변 가능 질문일 경우, 수신기가 대체질문을 자동으로 기입하도록 할 수도 있다.
도 167 은 본 발명의 일 실시예에 따른 자동답변 가능한 질문을 대체 질문으로 대체하고, 사용자에게 노출시켜 답변을 유도하는 시퀀스 다이어그램을 도시한 도면이다.
도시된 t167010 - t167050 은 전술한 PDI 유저 데이터를 받고, 자동 답변을 요청하고, 에러메시지를 받는 단계와 같을 수 있다. 단, 이 경우 PDI 유저 데이터의 PDI 질문 엘레멘트는 대체 질문의 ID 를 가지는 @supplementaryId 필드를 포함할 수 있다.
PDI 엔진은 에러 메시지 등을 받은 경우, @supplementaryId 필드를 참조할 수 있다. PDI 엔진은 PDI 스토어에서 대체 질문의 식별자를 가지는 PDI 질문이 있는지 여부를 확인할 수 있다(t167060).
대체 질문이 존재하지 않는 경우, 해당 자동 답변 질문은 무시될 수 있다. 또는 대체 질문을 서비스 프로바이더로부터 수신할 수 있다. 대체 질문이 존재하고 그 답변이 저장되어 있는 경우, 그 대체질문에 대한 새 답변을 얻지 않을 수 있다. 또는 대체 질문에 대한 답변이 저장되어 있지 않거나, 저장되어 있더라도 새로운 답변을 얻을 필요가 있을 경우, 이를 사용자에 노출하여 답변을 얻을 수 있다. 또는 대체 질문이 자동 답변 가능 질문일 경우 수신기가 자동으로 답변을 기입할 수도 있다.
PDI 엔진은 사용자에게 대체질문을 노출시켜야할 경우, 대체 질문을 UI 를 통해 사용자에게 노출시킬 수 있다(t167070). 사용자는 UI 를 통해 대체질문에 대한 답변을 할 수 있다(t167080). UI 는 획득한 답변을 PDI 엔진에 전달할 수 있다(t167090). PDI 엔진은 이를 PDI 스토어의 PDI 유저 데이터에 저장할 수 있다. 기존 답변이 있는 경우, 새로운 답변으로 업데이트하거나, 기존 답변에 더하여 새 답변을 추가할 수 있다.
도 168 은 컨텐츠 히스토리 엔진을 더 포함하는, 본 발명의 또 다른 실시예에 따른 수신기를 도시한 도면이다.
본 발명은 질문과 그 답변을 통하여 서비스를 개인화하는 것 외에, 사용자의 컨텐츠 시청 히스토리를 이용하여 서비스/컨텐츠를 개인화하는 방안을 제안한다. 수신기는 컨텐츠 시청 히스토리 정보를 생성하고, 이를 이용하여 개인화된 서비스를 사용자에게 제공할 수 있다.
도시된 수신기의 구조도에서, 서비스 프로바이더, 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) 로 대체되거나 연계될 수 있다.
도 169 는 본 발명의 또 다른 실시예에 따른 방송 수신기의 구조를 도시한 도면이다.
도시된 방송 수신기는, 서비스/컨텐츠 시청 히스토리를 반영하여 개인화된 서비스를 제공하기 위해 확장된 형태일 수 있다. 도시된 방송 수신기의 내부 구조 모듈들은, 전술한 방송 수신기의 내부 구조 모듈들과 같을 수 있다. 도시된 방송 수신기는, 컨텐츠 히스토리 프로세서, 컨텐츠 히스토리 DB 를 더 포함할 수 있다. 여기서, 도시된 각각의 내부 구조 모듈들은 필요한 경우 버퍼를 더 포함할 수 있다.
컨텐츠 히스토리 프로세서는, 사용자가 시청한 서비스/컨텐츠에 관한 정보들을 기록하기 위한 테이블 내지 데이터를 생성하는 기능을 담당할 수 있다. 컨텐츠 히스토리 프로세서는 전술한 컨텐츠 히스토리 엔진에 해당하는 동작을 수행할 수 있다. 전술한 바와 같이, 서비스/컨텐츠에 관한 정보들은 시그널링이 수행되는 당시에 전달받을 수도 있는데, 이 때 전달받는 정보는 서비스 시그널링 파서 / 앱 시그널링 파서 등으로부터 전달받을 수 있다. 또는 실시예에 따라 시그널링 디코더에서 미리 알 수 있는 정보들을 전달받을 수도 있다. 생성된 컨텐츠 히스토리 관련 테이블 내지 데이터는 유저 데이터 쉐어링 & 타겟팅 프로세서로 전달되어 서비스/컨텐츠의 개인화에 활용될 수 있다. 여기서, 유저 데이터 쉐어링 & 타겟팅 프로세서는 전술한 PDI 엔진에 해당하는 동작을 수행할 수 있다.
컨텐츠 히스토리 DB 는, 컨텐츠 히스토리 프로세서에 의해 생성된 테이블 내지 데이터가 저장되는 저장소 역할을 할 수 있다. 컨텐츠 히스토리 DB 는 전술한 컨텐츠 히스토리 스토어에 해당하는 동작을 수행할 수 있다.
전술한 바와 같이, 실시예에 따라 컨텐츠 히스토리 프로세서와 컨텐츠 히스토리 DB 는 사용 리포팅 프로세서(Usage Reporting Processor) 및/또는 사용 리포팅 DB(Usage Reporting DB)로 대체되거나 연계될 수도 있다.
도 170 은 본 발명의 일 실시예에 따른 컨텐츠 히스토리 테이블을 도시한 도면이다.
컨텐츠 히스토리 테이블은, 전술한 바와 같이, 사용자가 시청하고 있거나 시청한 서비스/컨텐츠의 히스토리 정보를 저장하기 위한 테이블일 수 있다. 컨텐츠 히스토리 테이블은 사용자가 시청한 서비스/컨텐츠에 관련된 정보 뿐 아니라, 사용자가 해당 서비스/컨텐츠를 어떠한 방식으로, 어느 정도의 시간 동안 시청했는지에 관한 정보도 포함할 수 있다. 이러한 컨텐츠 히스토리 테이블은 개인화된 서비스/컨텐츠를 제공하는데 사용될 수 있다.
사용자의 서비스/컨텐츠 시청 히스토리 정보는, 사용자의 입력없이 자동으로 컨텐츠 히스토리 테이블의 형태로 저장될 수 있다. 컨텐츠 히스토리 테이블이 생성되고, 정보가 테이블에 저장되는 과정은 전술한 컨텐츠 히스토리 엔진에 의해 수행될 수 있다. 전술한 바와 같이 컨텐츠 히스토리 엔진에 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 급의 품질인지 등을 나타내는 정보가 포함될 수 있다.
도 171 은 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 필터링 크리테리아를 도시한 도면이다.
전술한 바와 같이, 컨텐츠 히스토리 테이블의 정보와 비교하여 개인화된 서비스를 제공하기 위해 필터링 크리테리아가 정의될 수 있다.
도시된 필터링 크리테리아는 전술한 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 에 대응되는 기준정보일 수 있다. 즉, 본 필드는 레졸루션에 따른 기준 값을 포함할 수 있다.
도 172 는 본 발명의 일 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
전술한 컨텐츠 히스토리 테이블은 각각의 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 정보가 나타내는 특정 컨텐츠 히스토리 테이블 필드의 값을 포함할 수 있다.
도 173 은 본 발명의 다른 실시예에 따른 간략화한 컨텐츠 히스토리 테이블을 도시한 도면이다.
전술한 컨텐츠 히스토리 테이블의 간략화 방안에 더하여, 어떠한 필드들의 ID 가 어떠한 카테고리에 속하게 되는지에 대한 정보가 미리 정해지는 경우, 컨텐츠 히스토리 테이블이 더욱 더 간략해 질 수 있다.
도시된 컨텐츠 히스토리 테이블은 더욱 더 간략화된 컨텐츠 히스토리 테이블일 수 있다.
ContentHistoryProperty 엘레멘트는 컨텐츠 히스토리 테이블을 구성할 수 있는 컨텐츠 히스토리 정보들에 관한 정보를 포함하는 엘레멘트일 수 있다. ID 정보만으로도 해당 컨텐츠 히스토리 정보가 어느 카테고리에 속하는지를 알 수 있으므로, 5W1H 에 따른 카테고리 구분이 필요 없을 수 있다.
@id 는 컨텐츠 히스토리 필드의 ID 정보일 수 있다. ID 정보만으로 ID 정보가 식별하는 컨텐츠 히스토리 정보가 어느 카테고리에 속하는지 알 수 있다. @value 는 해당 히스토리 정보의 값을 포함할 수 있다.
예를 들어 @id 의 ID 정보가 @userID 필드를 지시하는 경우, @id 정보에 의해 ContentHistoryProperty 엘레멘트가 포함하는 히스토리 정보가 사용자의 ID 정보에 관한 것임을 알 수 있다. 또한, 기 정의된 사항에 의하여, 해당 히스토리 정보다 Who 타입에 속한다는 것도 알 수 있다. 실제 사용자 ID 정보는 @value 를 참조하여 획득될 수 있다.
도 174 는 전술한 컨텐츠 히스토리 테이블에 대응하는, 본 발명의 일 실시예에 따른 간략화된 필터링 크리테리아를 도시한 도면이다.
전술한 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 는 그 기준값의 길이를 나타낼 수 있다.
도 175 는 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 일부를 도시한 도면이다.
도 176 은 본 발명의 일 실시예에 따른 사용 리포팅 데이터의 다른 일부를 도시한 도면이다.
두 도면은 원래 하나인 사용 리포팅 데이터를 도시하고 있으나, 도면의 크기를 고려하여 두 개의 도면으로 나뉘어 도시되었다.
전술한 바와 같이, 컨텐츠 히스토리 테이블은 사용 리포팅 데이터(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 엘레멘트는 전술한 것과 같은 포맷을 가질 수 있다.
도 177 은 본 발명의 일 실시예에 따른, 컨텐츠 히스토리 테이블 및 필터링 크리테리아를 이용한 개인화된 서비스를 제공하는 시퀀스 다이어그램을 도시한 도면이다.
전술한 바와 같이, 시청 히스토리에 따라 컨텐츠 히스토리 테이블이 생성될 수 있고, 이를 기반으로 필터링 크리테리아와 비교하여 서비스/컨텐츠가 선별될 수 있다.
먼저, SSC 혹은 FIC 등의 채널을 통하여 방송될 서비스/컨텐츠에 대한 시그널링 정보들이 수신될 수 있다(t177010, t177020). 시그널링 파서는 수신한 시그널링 정보를 파싱하고, 파싱된 정보를 컨텐츠 히스토리 엔진으로 전달할 수 있다(t177030).
컨텐츠 히스토리 엔진은 전달받은 시그널링 정보들을 참조하여, 컨텐츠 히스토리 테이블을 생성할 수 있다(t177040). 이 컨텐츠 히스토리 테이블은 컨텐츠 히스토리 스토어에 저장될 수 있다.
수신기는 SSC 혹은 FIC 를 통해 전달되는 필터링 크리테리아를 수신할 수 있다(t177050). 이 때 필터링 크리테리아는 전술한 필터링 크리테리아 디스크립터의 형태일 수 있다. 컨텐츠 히스토리 테이블을 위한 필터링 크리테리아는 기존의 필터링 크리테리아와 마찬가지로 SMT 또는 NRT-IT 서비스 레벨의 디스크립터 루프에 존재할 수 있다. SMT 또는 NRT-IT 로 전달되는 경우 NRT 서비스나 컨텐트 아이템을 선별하는 용도로 쓰일 수 있으므로, 특정 서비스를 필터링하기 위하여 SSC 혹은 FIC 를 통해 필터링 크리테리아가 전달될 수 있다.
시그널링 파서는 필터링 크리테리아 디스크립터를 파싱하여, 그 기준정보들을 필터링 엔진으로 전달할 수 있다(t177060). 필터링 엔진은 전달받은 기준 정보들을 이용하여, 컨텐츠 히스토리 엔진에 관련된 컨텐츠 히스토리 테이블을 요청할 수 있다(t177070).
컨텐츠 히스토리 엔진은 관련된 컨텐츠 히스토리 테이블을 서치한 후(t177080), 컨텐츠 히스토리 테이블을 필터링 엔진으로 전달할 수 있따(t177090). 필터링 엔진은 전달받은 컨텐츠 히스토리 테이블과 기준 정보들을 비교할 수 있다(t177100). 이 비교과정을 통해 해당 서비스/컨텐츠가 해당 수신기에 적합한지 여부가 판단될 수 있다.
해당 수신기에 적합한 서비스/컨텐츠일 경우, 그 서비스/컨텐츠를 다운로드하거나 디스플레이할 수 있다.
도 178 은 카운트 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
수신기가 필터링 크리테리아를 수신한 후, 그 기준 정보들과 컨텐츠 히스토리 테이블 내의 히스토리 정보들을 비교하는 방안을 설명한다.
비교과정은 특정 히스토리 정보가, 그와 연관되는 기준정보들 내의 기준값에 충족되는지 여부를 판단하는 것으로 수행될 수 있다. 이 때, 각 기준정보에 충족되는 히스토리 정보들에 대하여 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 보다 큰 경우에만 해당 서비스/컨텐츠가 다운로드될 수 있다.
이와 같은 카운트 정보가 포함되지 않을 경우, 사용자가 우연히 해당 필터링 크리테리아를 만족하는 시청 히스토리를 남긴 경우에도 해당 컨텐츠 히스토리 테이블이 생성되므로, 정확한 서비스 개인화에 방해가 될 수 있다. 즉, 컨텐츠 히스토리 테이블이 하나 정도만 존재하는 경우는 필터링 크리테리아가 만족되지 않는 것으로 판단되게 설정하여, 효율적인 개인화를 이룰 수 있다.
도 179 는 문턱값 정보를 포함하는, 본 발명의 일 실시예에 따른 필터링 크리테리아의 일부를 도시한 도면이다.
전술한 비교 정책들은, 필터링 크리테리아의 모든 기준 정보들을 만족하는 컨텐츠 히스토리 테이블이 있는 경우에만 서비스/컨텐츠가 제공된다. 따라서 모든 기준 정보를 만족하는 컨텐츠 히스토리 테이블이 적은 경우 효율이 떨어질 수 있다.
이를 해결하기 위해, 기준 정보들 중 하나라도 만족하는 컨텐츠 히스토리 테이블이 있을 경우 서비스/컨텐츠를 제공하는 비교 정책이 제안될 수 있다. 그러나 이 경우에는 필터링 크리테리아를 충족시키는 컨텐츠 히스토리 테이블이 너무 많아져서 오히려 효율성이 떨어질 수 있다.
따라서, 각 기준 정보에 대하여 가중치를 두어, 각 기준정보의 기준값과 가중치를 곱한 값들의 합(A)을 기준으로 비교를 수행하는 비교 정책이 제안될 수 있다. 이를 위해 필터링 크리테리아는 문턱값(B)를 더 포함할 수 있다. A 값이 B 보다 큰 경우에 해당 필터링 크리테리아가 충족된 것으로 판단되어 해당 서비스/컨텐츠가 제공될 수 있다. 실시예에 따라 각 기준정보의 기준값과 가중치를 곱한 값들의 합이 A 값이 아니라, 만족되는 기준정보의 가중치를 단순히 합한 값이 A 값이 될 수도 있다.
@threshold 성질은 전술한 문턱값에 해당하는 성질(attribute)일 수 있다.
@weight 은 각 기준정보에 포함되는 성질로서, 각 기준정보의 가중치 값을 포함할 수 있다. 가중치는 설계자의 의도에 따라 자유롭게 설정될 수 있다. 여기서 다른 카테고리와는 달리 When 타입의 경우, @weight 이 각 기준정보가 아닌 QWhenCriterion 에 포함되는 성질로서 정의될 수 있다. StartTimeCriterionValue, EndTimeCriterionValue 가 특정 시점을 의미할 수 있기 때문이다. 실시예에 따라 다른 카테고리에 대해서도 @weight 이 각 기준정보가 아닌 QxCriterion 에 포함되는 성질로서 정의될 수 있다.
도 180 은 문턱값 정보를 포함하는 필터링 크리테리아에 있어서, 본 발명의 일 실시예에 따른 비교 과정을 도시한 도면이다.
필터링 크리테리아(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 보다 작은 값이다. 따라서 최종적으로 제공하려고 했던 서비스/컨텐츠는 필터링되어 사용자에게 제공되지 않을 수 있다.
도 181 은 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법을 도시한 도면이다.
본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법은, 개인화 테이블을 수신하는 단계, 개인화 질문에 대한 적어도 하나의 답변을 획득하는 단계 및/또는 답변을 개인화 테이블에 저장하는 단계를 포함할 수 있다.
먼저, 전술한 수신기는 개인화 테이블을 수신할 수 있다(t181010). 여기서 개인화 테이블은 전술한 PDI 유저 데이터 내지 PDIUserData 를 의미할 수 있다. 개인화 테이블은 수신기 내부의 수신모듈(receiving unit, receiving module)에 의해 수신될 수 있다. 수신모듈은 튜너, 디모듈레이터, 네트워크 인터페이스 등의 모듈에 해당할 수 있다. 실시예에 따라 수신모듈은 수신기 외부에 위치할 수도 있다. 수신모듈은 후술할 제 1 모듈에 해당할 수 있다. 여기서, 개인화 테이블은 개인화된 서비스 제공에 관련된 복수개의 개인화 질문을 포함할 수 있다. 여기서 개인화 질문이란 전술한 PDI 질문, PDI Q, PDI 퀘스쳐네어 등을 의미할 수 있다. 개인화 테이블은 해당 개인화 테이블을 식별하는 테이블 식별자를 더 포함할 수 있다.
이 후, 복수개의 개인화 질문에 대해 적어도 하나의 답변이 획득될 수 있다(t181020). 이는 전술한 바와 같이 PDI 엔진이 질문들을 사용자에게 노출시킴으로서 수행될 수 있다. 사용자는 질문에 답변을 할 수 있다. 또는 자동답변가능질문의 경우, 수신기가 자동으로 개인화 질문에 대한 답변을 기입할 수 있다(t181020). 이 경우도 본 단계의 적어도 하나의 답변이 획득되는 것으로 본다. 실시예에 따라 PDI 엔진은 수신기 외부에 위치할 수도 있다. PDI 엔진은 후술할 제 2 모듈에 해당할 수 있다.
획득된 답변은 개인화 테이블에 저장될 수 있다(t181030). PDI 엔진은 사용자가 기입하거나 수신기가 자동으로 기입함으로써 획득된 답변을 개인화 테이블의 형태로 PDI 스토어에 저장할 수 있다. 이 때, 획득된 답변은 개인화 테이블의 A 엘레멘트 내에 저장될 수 있다.
본 발명의 다른 실시예에 따른 개인화된 서비스를 제공하는 방법은, 서비스에 관한 필터링 크리테리아를 수신하는 단계, 필터링 크리테리아 내의 정보와 획득한 답변을 비교하는 단계 및/또는 필터링 크리테리아 내의 정보와 획득한 답변이 일치할 경우, 서비스에 관한 서비스 데이터를 수신하는 단계를 더 포함할 수 있다.
먼저 전술한 수신모듈이 서비스에 관한 필터링 크리테리아를 수신할 수 있다. 필터링 크리테리아는 해당 서비스에 관한 정보를 포함할 수 있다. 필터링 크리테리아는 해당 서비스의 성질, 장르, 언어, 레이팅 등에 관한 정보를 포함할 수 있다. 필터링 크리테리아는 해당 서비스와 함께 또는 별개로 수신될 수 있으며, SSC/FIT 등의 채널을 통해서 수신되거나 SMT 등의 서비스 시그널링 정보와 함께 수신될 수 있다. 전술한 필터링 엔진은 필터링 크리테리아 내의 정보와 획득했던 답변을 비교하여 필터링을 수행할 수 있다. 여기서 필터링 엔진은 후술할 제 3 모듈에 해당할 수 있으며, 실시예에 따라 수신기 외부에 위치할 수도 있다. PDI 유저 데이터와 필터링 크리테리아를 비교하는 방법은 전술한 실시예들 중 하나를 따를 수 있다. 비교결과 해당 서비스가 개인화 관점에서 적합한 서비스인 경우, 수신모듈은 해당 서비스의 데이터를 수신할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 필터링 크리테리아는 서비스를 시그널링하는 서비스 시그널링 정보에 포함되어 수신될 수 있다. 전술한 바와 같이 필터링 크리테리아는 해당 서비스와 함께 또는 별개로 수신될 수 있으며, SSC/FIT 등의 채널을 통해서 수신되거나 SMT 등의 서비스 시그널링 정보와 함께 수신될 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 개인화 질문은 개인화 질문의 답변 타입에 따라 다른 구조를 가질 수 있다. 전술한 바와 같이 PDI 질문들에는 타입이 정의되어 있어, 답변의 타입 즉, 정수(integer), 텍스트(text) 인지 등에 따라 다른 구조를 가질 수 있다. 또한, 개인화 질문은 질문에 관한 정보를 포함하는 질문 엘레멘트와 개인화 질문에 대한 답변을 저장할 수 있는 답변 엘레멘트를 포함할 수 있다. 질문 엘레멘트는 전술한 Q 엘레멘트, 답변 엘레멘트는 A 엘레멘트에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 개인화 질문은 해당 개인화 질문이 수신기가 자동으로 답변이 가능한 형태인지 여부를 지시하는 자동생성정보를 더 포함할 수 있다. 자동생성 정보는 전술한 @autoPopulate 내지 AutoPopulate@type 에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 자동생성정보에 따라 해당 개인화 질문에 대한 답변은 수신기에 의해 자동으로 획득될 수 있다. 이는 수신기의 별도로 정의된 API 에 의해 수행되거나 실시예에 따라 PDI 엔진에 의해 수행될 수도 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 자동생성정보는 수신기가 해당 개인화 질문에 자동으로 답변하지 못하는 경우에, 해당 개인화 질문을 대체할 질문을 식별하는 대체질문 식별자를 더 포함할 수 있다. 여기서 대체질문 식별자는 전술한 AutoPopulate@supplementaryId 에 해당할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법은, 서비스의 시청에 관한 시청 히스토리 정보를 포함하는 히스토리 테이블을 생성하는 단계, 필터링 크리테리아 내의 정보와 히스토리 테이블의 정보를 비교하는 단계 및/또는 필터링 크리테리아 내의 정보와 히스토리 테이블의 정보가 일치할 경우, 서비스에 관한 서비스 데이터를 수신하는 단계를 더 포함할 수 있다.
먼저 전술한 컨텐츠 히스토리 엔진이 서비스 내지 컨텐츠의 시청 히스토리 정보를 이용하여 히스토리 테이블을 생성할 수 있다. 히스토리 테이블은 전술한 컨텐츠 히스토리 테이블을 의미할 수 있다. 컨텐츠 히스토리 엔진은 후술할 제 4 모듈에 해당할 수 있고, 실시예에 따라 수신기 외부에 위치할 수도 있다. 이 후, 필터링 엔진은 필터링 크리테리아 내의 정보와 히스토리 테이블의 정보를 비교하여, 해당 서비스/컨텐츠가 시청 히스토리 관점에서 적합한 서비스/컨텐츠인지를 판단할 수 있다. 이를 통해 시청 히스토리에 맞는 서비스제공이 수행될 수 있다. 수신모듈은 해당 서비스/컨텐츠에 관한 필터링 크리테리아를 만족하는 히스토리 테이블이 있는 경우, 즉 비교작업 상 매칭되는 경우, 해당 서비스/컨텐츠를 수신할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 히스토리 테이블은 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 히스토리 정보를 포함할 수 있다. 각 항목은 전술한 5W1H 에 관한 시청 히스토리 정보를 의미할 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 필터링 크리테리아는 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 기준정보를 포함할 수 있다. 컨텐츠 히스토리 테이블에 대응하여, 5W1H 방식에 따라 각 기준정보가 필터링 크리테리아에 포함될 수 있다. 히스토리 정보와 매칭되는 기준정보들의 개수를 기반으로 서비스에 관한 서비스 데이터가 수신될 수 있다. 즉, 필터링 크리테리아 내의 기준정보와 매칭되는 히스토리 테이블의 정보(내지 컨텐츠 히스토리 테이블)의 개수가, 기 지정된 특정 수보다 클 경우 해당 서비스/컨텐츠가 히스토리에 매칭되는 것으로 판단될 수 있다. 매칭되는 것으로 판단되면 해당 서비스/컨텐츠가 수신모듈에 의해 수신될 수 있다. 기 지정된 특정 수는 전술한 @count 필드의 값을 통해 알 수 있다.
본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 방법에서, 기준정보는 가중치 정보를 포함할 수 있다. 이는 전술한 필터링 크리테리아 내의 각 기준정보가 @weight 성질을 포함하는 것에 해당할 수 있다. 히스토리 정보와 매칭되는 기준정보들의 가중치를 기반으로 서비스에 관한 서비스 데이터를 수신될 수 있다. 매칭되는 기준정보들의 가중치 값을 더하거나, 기준정보들의 값에 가중치 값을 곱한 것들의 합을 계산하여, 그 계산 값이 @threshold 성질의 값보다 큰 경우에만 매칭되는 것으로 판단될 수 있다. 매칭되는 경우, 수신모듈은 해당 서비스/컨텐츠를 수신할 수 있다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법을 설명한다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법은 도면에 도시되지 아니하였다. 다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법은 서비스 프로바이더 내지 서비스/컨텐츠, 개인화 테이블을 전송하는 측의 입장에서 기술된 개인화된 서비스를 제공하는 방법을 의미할 수 있다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법은, 서비스/컨텐츠를 생성하는 단계, 개인화 테이블을 생성하는 단계 및/또는 개인화 테이블을 전송하는 단계를 포함할 수 있다.
컨텐츠 생성 모듈이 서비스/컨텐츠를 생성할 수 있다. 이와 별개로 개인화 모듈은 개인화 테이블을 생성할 수 있다. 전송 모듈은 개인화 테이블을 수신기 측으로 전송할 수 있다. 이 때, SSC/FIT 등의 채널이 사용되거나 SMT 같은 서비스 시그널링 정보와 함께 개인화 테이블이 전송될 수 있다. 이 개인화 테이블은 전술한 개인화 테이블 내지 PDI 유저 데이터의 실시예가 가지는 정보들을 가질 수 있다.
이 후, 개인화 모듈은 생성된 서비스/컨텐츠에 대응되는 필터링 크리테리아를 생성할 수 있다. 이 생성작업은 서비스/컨텐츠의 생성과 동시에 이루어 지거나, 그 이전에 수행될 수도 있다. 전송 모듈은 이 필터링 크리테리아를 수신기 측에 전송할 수 있다. 이 필터링 크리테리아는 전술한 필터링 크리테리아의 실시예들이 가지는 정보들을 가질 수 있다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법은, 전술한 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법에 대응되는 서비스 프로바이더 측 실시예들을 가질 수 있다.
전술한 단계들은 실시예에 따라 생략되거나, 유사/동일한 동작을 수행하는 다른 단계에 의해 대체될 수 있다.
도 182 는 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치를 도시한 도면이다.
본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치는 제 1 모듈 및/또는 제 2 모듈을 포함할 수 있다. 본 발명의 다른 실시예에 따른 개인화된 서비스를 제공하는 장치는, 제 3 모듈을 더 포함할 수 있다. 본 발명의 또 다른 실시예에 따른 개인화된 서비스를 제공하는 장치는, 제 4 모듈을 더 포함할 수 있다. 여기서, 제 1 모듈, 제 2 모듈, 제 3 모듈 및 제 4 모듈은 각각 전술한 수신모듈, PDI 엔진, 필터링 엔진 및/또는 컨텐츠 히스토리 엔진에 해당할 수 있다. 전술한 바와 같이 컨텐츠 히스토리 엔진과 PDI 엔진은 통합되어 운영될 수 있다.
본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치 및 그 내부 모듈/블락들은, 전술한 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법의 실시예들을 수행할 수 있다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치를 설명한다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치는 도면에 도시되지 아니하였다. 다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치는 서비스 프로바이더 내지 서비스/컨텐츠, 개인화 테이블을 전송하는 측의 입장에서 기술된 개인화된 서비스를 제공하는 장치를 의미할 수 있다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치는 전술한 컨텐츠 생성 모듈, 개인화 모듈 및/또는 전송모듈을 포함할 수 있다.
다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 장치 및 그 내부 모듈/블락들은, 전술한 다른 관점에서 본, 본 발명의 일 실시예에 따른 개인화된 서비스를 제공하는 방법의 실시예들을 수행할 수 있다.
전술한 각각의 개인화된 서비스를 제공하는 장치의 내부의 블락/모듈 등은 메모리에 저장된 연속된 수행과정들을 실행하는 프로세서들일 수 있고, 실시예에 따라 장치 내/외부에 위치하는 하드웨어 엘레멘트들일 수 있다.
전술한 모듈들은 실시예에 따라 생략되거나, 유사/동일한 동작을 수행하는 다른 모듈에 의해 대체될 수 있다.
모듈 또는 유닛은 메모리(또는 저장 유닛)에 저장된 연속된 수행과정들을 실행하는 프로세서들일 수 있다. 전술한 실시예에 기술된 각 단계들은 하드웨어/프로세서들에 의해 수행될 수 있다. 전술한 실시예에 기술된 각 모듈/블락/유닛들은 하드웨어/프로세서로서 동작할 수 있다. 또한, 본 발명이 제시하는 방법들은 코드로서 실행될 수 있다. 이 코드는 프로세서가 읽을 수 있는 저장매체에 쓰여질 수 있고, 따라서 장치(apparatus)가 제공하는 프로세서에 의해 읽혀질 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명이 제안하는 방법을 네트워크 디바이스에 구비된, 프로세서가 읽을 수 있는 기록매체에, 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 이해된다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.
본 명세서에서 장치 및 방법 발명이 모두 언급되고, 장치 및 방법 발명 모두의 설명은 서로 보완하여 적용될 수 있다.
다양한 실시예가 본 발명을 실시하기 위한 최선의 형태에서 설명되었다.
본 발명은 일련의 방송 신호 제공 분야에서 이용된다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.

Claims (22)

  1. 개인화된 서비스를 제공하는 방법에 있어서,
    개인화 테이블을 수신하는 단계, 여기서 상기 개인화 테이블은 개인화된 서비스 제공에 관련된 복수개의 개인화 질문 및 상기 개인화 테이블을 식별하는 테이블 식별자를 포함하고;
    상기 복수개의 개인화 질문에 대한 적어도 하나의 답변을 획득하는 단계; 및
    상기 획득한 답변을 상기 개인화 테이블에 저장하는 단계; 를 포함하는 개인화된 서비스를 제공하는 방법.
  2. 제 1항에 있어서, 상기 개인화된 서비스를 제공하는 방법은:
    서비스에 관한 필터링 크리테리아를 수신하는 단계, 여기서 상기 필터링 크리테리아는 상기 서비스에 관한 정보를 포함하고;
    상기 필터링 크리테리아 내의 정보와 상기 획득한 답변을 비교하는 단계; 및
    상기 필터링 크리테리아 내의 정보와 상기 획득한 답변이 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 단계; 를 더 포함하는 개인화된 서비스를 제공하는 방법.
  3. 제 2항에 있어서,
    상기 필터링 크리테리아는 상기 서비스를 시그널링하는 서비스 시그널링 정보에 포함되어 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  4. 제 1항에 있어서,
    상기 개인화 질문은 상기 개인화 질문의 답변 타입에 따라 다른 구조를 가지고,
    상기 개인화 질문은 질문에 관한 정보를 포함하는 질문 엘레멘트와 상기 개인화 질문에 대한 답변을 저장할 수 있는 답변 엘레멘트를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  5. 제 1항에 있어서,
    상기 개인화 질문은 상기 개인화 질문이 수신기가 자동으로 답변이 가능한 형태인지 여부를 지시하는 자동생성정보를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  6. 제 5항에 있어서,
    상기 자동생성정보에 따라 상기 개인화 질문에 대한 답변은 수신기에 의해 자동으로 획득되는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  7. 제 5항에 있어서,
    상기 자동생성정보는 수신기가 상기 개인화 질문에 자동으로 답변하지 못하는 경우에 상기 개인화 질문을 대체할 질문을 식별하는 대체질문 식별자를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  8. 제 2항에 있어서, 상기 개인화된 서비스를 제공하는 방법은:
    서비스의 시청에 관한 시청 히스토리 정보를 포함하는 히스토리 테이블을 생성하는 단계;
    상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보를 비교하는 단계; 및
    상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보가 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 단계; 를 더 포함하는 개인화된 서비스를 제공하는 방법.
  9. 제 8항에 있어서,
    상기 히스토리 테이블은 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 히스토리 정보를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  10. 제 8항에 있어서,
    상기 필터링 크리테리아는 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 기준정보를 포함하고,
    상기 히스토리 정보와 매칭되는 상기 기준정보들의 개수를 기반으로 상기 서비스에 관한 서비스 데이터가 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  11. 제 10항에 있어서,
    각각의 상기 기준정보는 가중치 정보를 포함하고,
    상기 히스토리 정보와 매칭되는 상기 기준정보들의 가중치를 기반으로 상기 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 방법.
  12. 개인화된 서비스를 제공하는 장치에 있어서,
    개인화 테이블을 수신하는 제 1 모듈, 여기서 상기 개인화 테이블은 개인화된 서비스 제공에 관련된 복수개의 개인화 질문 및 상기 개인화 테이블을 식별하는 테이블 식별자를 포함하고; 및
    상기 복수개의 개인화 질문에 대한 적어도 하나의 답변을 획득하는 제 2 모듈, 여기서 상기 제 2 모듈은 상기 획득한 답변을 상기 개인화 테이블에 저장하고;
    를 포함하는 개인화된 서비스를 제공하는 장치.
  13. 제 12항에 있어서,
    상기 제 1 모듈은 서비스에 관한 필터링 크리테리아를 수신하고, 여기서 상기 필터링 크리테리아는 상기 서비스에 관한 정보를 포함하고;
    상기 개인화된 서비스를 제공하는 장치는 상기 필터링 크리테리아 내의 정보와 상기 획득한 답변을 비교하는 제 3 모듈을 포함하고; 및
    상기 제 1 모듈은 상기 필터링 크리테리아 내의 정보와 상기 획득한 답변이 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  14. 제 13항에 있어서,
    상기 필터링 크리테리아는 상기 서비스를 시그널링하는 서비스 시그널링 정보에 포함되어 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  15. 제 12항에 있어서,
    상기 개인화 질문은 상기 개인화 질문의 답변 타입에 따라 다른 구조를 가지고,
    상기 개인화 질문은 질문에 관한 정보를 포함하는 질문 엘레멘트와 상기 개인화 질문에 대한 답변을 저장할 수 있는 답변 엘레멘트를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  16. 제 12항에 있어서,
    상기 개인화 질문은 상기 개인화 질문이 수신기가 자동으로 답변이 가능한 형태인지 여부를 지시하는 자동생성정보를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  17. 제 16항에 있어서,
    상기 자동생성정보에 따라 상기 개인화 질문에 대한 답변은 수신기에 의해 자동으로 획득되는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  18. 제 16항에 있어서,
    상기 자동생성정보는 수신기가 상기 개인화 질문에 자동으로 답변하지 못하는 경우에 상기 개인화 질문을 대체할 질문을 식별하는 대체질문 식별자를 더 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  19. 제 13항에 있어서,
    상기 개인화된 서비스를 제공하는 장치는 서비스의 시청에 관한 시청 히스토리 정보를 포함하는 히스토리 테이블을 생성하는 제 4 모듈을 포함하고;
    상기 제 3 모듈은 상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보를 비교하고; 및
    상기 제 1 모듈은 상기 필터링 크리테리아 내의 정보와 상기 히스토리 테이블의 정보가 일치할 경우, 상기 서비스에 관한 서비스 데이터를 수신하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  20. 제 19항에 있어서,
    상기 히스토리 테이블은 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 히스토리 정보를 포함하는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  21. 제 19항에 있어서,
    상기 필터링 크리테리아는 시청주체, 시청시각, 시청장소, 시청대상 또는 시청방법에 관한 기준정보를 포함하고,
    상기 히스토리 정보와 매칭되는 상기 기준정보들의 개수를 기반으로 상기 서비스에 관한 서비스 데이터가 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
  22. 제 21항에 있어서,
    각각의 상기 기준정보는 가중치 정보를 포함하고,
    상기 히스토리 정보와 매칭되는 상기 기준정보들의 가중치를 기반으로 상기 서비스에 관한 서비스 데이터가 수신되는 것을 특징으로 하는 개인화된 서비스를 제공하는 장치.
PCT/KR2015/005534 2014-06-03 2015-06-02 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 WO2015186954A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/301,826 US20170180809A1 (en) 2014-06-03 2015-06-02 Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method and broadcast signal reception method
KR1020167020595A KR101832781B1 (ko) 2014-06-03 2015-06-02 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201462006903P 2014-06-03 2014-06-03
US62/006,903 2014-06-03
US201462010465P 2014-06-11 2014-06-11
US62/010,465 2014-06-11
US201462018669P 2014-06-30 2014-06-30
US62/018,669 2014-06-30

Publications (1)

Publication Number Publication Date
WO2015186954A1 true WO2015186954A1 (ko) 2015-12-10

Family

ID=54766980

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/005534 WO2015186954A1 (ko) 2014-06-03 2015-06-02 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Country Status (3)

Country Link
US (1) US20170180809A1 (ko)
KR (1) KR101832781B1 (ko)
WO (1) WO2015186954A1 (ko)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3080994A4 (en) * 2013-12-09 2017-07-26 LG Electronics Inc. A receiver and a method for processing a broadcast signal including a broadcast content and an application related to the broadcast content
WO2015138798A1 (en) 2014-03-13 2015-09-17 Verance Corporation Interactive content acquisition using embedded codes
US9805434B2 (en) 2014-08-20 2017-10-31 Verance Corporation Content management based on dither-like watermark embedding
KR102230126B1 (ko) 2017-02-03 2021-03-19 삼성전자주식회사 송신 장치, 그의 셀 멀티플렉싱 방법, 수신 장치 및 그의 셀 디멀티플렉싱 방법
CN107483989A (zh) * 2017-08-23 2017-12-15 深圳市优品壹电子有限公司 一种身份验证方法及终端
WO2019036971A1 (zh) * 2017-08-23 2019-02-28 深圳市优品壹电子有限公司 一种身份验证方法及终端
US11463507B1 (en) * 2019-04-22 2022-10-04 Audible, Inc. Systems for generating captions for audio content
US11347379B1 (en) 2019-04-22 2022-05-31 Audible, Inc. Captions for audio content
CN110958482A (zh) * 2019-12-14 2020-04-03 杭州国芯科技股份有限公司 一种安全保护下录制和回放系统及控制方法
US20220342914A1 (en) * 2021-04-23 2022-10-27 C3S, Inc. Database access system using machine learning-based relationship association

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060129317A (ko) * 2004-01-26 2006-12-15 코닌클리케 필립스 일렉트로닉스 엔.브이. 개인화된 방송 서비스 제공 방법
KR20090058042A (ko) * 2007-12-04 2009-06-09 에스케이 텔레콤주식회사 이동통신 시스템에서 컨텐츠 메타데이터를 이용한 컨텐츠검색 방법 및 장치
KR20110137917A (ko) * 2010-06-18 2011-12-26 삼성전자주식회사 Ｐｎ 라우팅 테이블을 이용한 개인 네트워크의 구성 장치 및 방법
KR20120080747A (ko) * 2011-01-10 2012-07-18 삼성전자주식회사 멀티미디어 스트리밍 시스템에서 시청자 조사를 위한 장치 및 방법
WO2014028255A1 (en) * 2012-08-15 2014-02-20 Sony Corporation Broadband delivery of personalization information for advanced tv services

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6201536B1 (en) * 1992-12-09 2001-03-13 Discovery Communications, Inc. Network manager for cable television system headends
US5758257A (en) * 1994-11-29 1998-05-26 Herz; Frederick System and method for scheduling broadcast of and access to video programs and other data using customer profiles
US7007294B1 (en) * 2000-10-30 2006-02-28 Koninklijke Philips Electronics N.V. Method and apparatus for automatic generation of query search terms for a program recommender
US20030014407A1 (en) * 2001-04-11 2003-01-16 Green Arrow Media, Inc. System and method for making media recommendations
US8275803B2 (en) * 2008-05-14 2012-09-25 International Business Machines Corporation System and method for providing answers to questions
US20100049554A1 (en) * 2008-08-22 2010-02-25 Mcconnell Rachel Ann Methods and systems of insuring fertility care lifestyle affairs
US8875169B2 (en) * 2010-08-27 2014-10-28 Sony Corporation Transmission and reception apparatus, methods, and systems for filtering content
US20120185888A1 (en) 2011-01-19 2012-07-19 Sony Corporation Schema for interests and demographics profile for advanced broadcast services
US9659600B2 (en) * 2014-07-10 2017-05-23 Sap Se Filter customization for search facilitation
US20130103758A1 (en) * 2011-10-19 2013-04-25 c/o Facebook, Inc. Filtering and ranking recommended users on a social networking system
US9473730B1 (en) * 2012-02-13 2016-10-18 Nbcuniversal Media, Llc Method and system for personalized recommendation modeling
WO2014051315A1 (en) * 2012-09-26 2014-04-03 Lg Electronics Inc. Method and apparatus for processing digital service signal
JP6235556B2 (ja) * 2013-03-15 2017-11-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ コンテンツ提示方法、コンテンツ提示装置及びプログラム
US10108817B2 (en) * 2014-09-26 2018-10-23 Microsoft Technology Licensing, Llc Privacy-preserving cookies for personalization without user tracking
US10028025B2 (en) * 2014-09-29 2018-07-17 Time Warner Cable Enterprises Llc Apparatus and methods for enabling presence-based and use-based services

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060129317A (ko) * 2004-01-26 2006-12-15 코닌클리케 필립스 일렉트로닉스 엔.브이. 개인화된 방송 서비스 제공 방법
KR20090058042A (ko) * 2007-12-04 2009-06-09 에스케이 텔레콤주식회사 이동통신 시스템에서 컨텐츠 메타데이터를 이용한 컨텐츠검색 방법 및 장치
KR20110137917A (ko) * 2010-06-18 2011-12-26 삼성전자주식회사 Ｐｎ 라우팅 테이블을 이용한 개인 네트워크의 구성 장치 및 방법
KR20120080747A (ko) * 2011-01-10 2012-07-18 삼성전자주식회사 멀티미디어 스트리밍 시스템에서 시청자 조사를 위한 장치 및 방법
WO2014028255A1 (en) * 2012-08-15 2014-02-20 Sony Corporation Broadband delivery of personalization information for advanced tv services

Also Published As

Publication number Publication date
KR20160108379A (ko) 2016-09-19
KR101832781B1 (ko) 2018-02-27
US20170180809A1 (en) 2017-06-22

Similar Documents

Publication Publication Date Title
WO2015186954A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2015119455A1 (en) Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
WO2015122747A1 (en) Apparatus for processing a hybrid broadcast service, and method for processing a hybrid broadcast service
WO2015084004A1 (en) Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
WO2015178603A1 (ko) 방송 전송 장치, 방송 전송 장치의 동작 방법. 방송 수신 장치 및 방송 수신 장치의 동작 방법
WO2015099331A1 (en) Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
WO2014035130A1 (en) Method and apparatus for processing digital service signal
WO2016010404A1 (ko) 방송 송신 장치, 방송 송신 장치의 데이터 처리 방법, 방송 수신 장치 및 방송 수신 장치의 데이터 처리 방법
WO2015088217A1 (en) A receiver and a method for processing a broadcast signal including a broadcast content and an application related to the broadcast content
WO2016028052A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2015167190A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017014586A1 (ko) 방송 신호 송수신 장치 및 방법
WO2020162712A1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2017007224A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2015190791A1 (ko) 서비스 가이드 정보 송신 방법, 서비스 가이드 정보 수신 방법, 서비스 가이드 정보 송신 장치 및 서비스 가이드 정보 수신 장치
WO2014051315A1 (en) Method and apparatus for processing digital service signal
WO2016036077A1 (ko) 방송 수신 장치, 방송 수신 장치의 동작 방법, 방송 수신 장치와 연동하는 연동 장치 및 연동 장치의 동작 방법
WO2016153241A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016068564A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016018077A1 (ko) 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
WO2017026714A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016190720A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017043898A1 (ko) 방송 신호 송수신 장치 및 방법
WO2016018041A1 (ko) 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
WO2016003151A1 (ko) 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15802563

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20167020595

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15301826

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15802563

Country of ref document: EP

Kind code of ref document: A1