WO2011129599A2 - 디스커버리 메타데이터 접근을 위한 방법 및 장치 - Google Patents

디스커버리 메타데이터 접근을 위한 방법 및 장치 Download PDF

Info

Publication number
WO2011129599A2
WO2011129599A2 PCT/KR2011/002591 KR2011002591W WO2011129599A2 WO 2011129599 A2 WO2011129599 A2 WO 2011129599A2 KR 2011002591 W KR2011002591 W KR 2011002591W WO 2011129599 A2 WO2011129599 A2 WO 2011129599A2
Authority
WO
WIPO (PCT)
Prior art keywords
metadata
scheme
section
access
request message
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2011/002591
Other languages
English (en)
French (fr)
Other versions
WO2011129599A3 (ko
Inventor
탕쯔엉꽁
강정원
배성준
박상택
류원
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Electronics and Telecommunications Research Institute ETRI
Original Assignee
Electronics and Telecommunications Research Institute ETRI
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
Priority claimed from KR1020110024750A external-priority patent/KR101199703B1/ko
Application filed by Electronics and Telecommunications Research Institute ETRI filed Critical Electronics and Telecommunications Research Institute ETRI
Priority to US13/641,059 priority Critical patent/US20130198790A1/en
Priority to CN2011800187351A priority patent/CN102845073A/zh
Publication of WO2011129599A2 publication Critical patent/WO2011129599A2/ko
Publication of WO2011129599A3 publication Critical patent/WO2011129599A3/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. 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/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

Definitions

  • the following embodiments are directed to a method and apparatus for accessing service discovery metadata.
  • next generation IPTV a generic protocol for accessing service discovery metadata is disclosed.
  • Service discovery metadata allows a user to discover and select an IPTV service or content.
  • Discovery metadata is one of the most important issues in all IPTV standards.
  • each IPTV standard developed by each standardization body has a different metadata scheme.
  • specific protocols are designed to process (eg, access or update) a metadata database of a particular scheme.
  • the purpose of the AIT standard is to provide standard and efficient standardized protocols and application programming interfaces (APIs) to enable rapid deployment of the IPTV value chain.
  • ITU-T International Telecommunication Union Telecommunication Standardization Sector
  • ETSI European Telecommunications Standards Institute
  • ATIS Alliance for Telecommunications Industry Solutions
  • One embodiment of the present invention may provide an apparatus and method for accessing discovery metadata of different schemes.
  • the method comprising: generating an access metadata request message indicating information about a metadata section to be accessed, transmitting the access metadata request message to a description provider device, and the description provider device.
  • a metadata retrieval method of a requesting device comprising receiving an access metadata response message including the contents of the metadata section from the terminal and retrieving metadata based on the contents of the metadata section.
  • the metadata retrieval method of the requesting device may further include signing the access metadata request message.
  • the metadata retrieval method of the requesting device may further include replying to the description provider device in a notification message.
  • the metadata retrieval method of the request device may include generating a metadata scheme request message for accessing the metadata, transmitting the metadata scheme request message to the description provider device, and from the description provider device.
  • the method may further include receiving a metadata scheme response message indicating whether the metadata scheme is accessible.
  • the metadata scheme request message may include a list of all metadata schemes supported by the requesting device and a priority attribute for each scheme of the list.
  • the metadata scheme response message is adapted to indicate a metadata scheme selected by the description provider device based on an optimal match between the characteristics of the requesting device and the description provider device. May include a scheme element.
  • the metadata scheme response message may include a scheme result element indicating the cause of the failure.
  • the access metadata request message includes a scheme name element indicating a type of the metadata scheme, an encoding element indicating an encoding type to be used for the metadata, a requested section element indicating a group of requested sections at a level of a section hierarchy; It may include one or more of the section condition element for conveying the identifier of the requested metadata sections at the level of the section layer.
  • the metadata response message may indicate that the metadata request message does not specify a version value of the metadata color line, or that the version value of the metadata section requested by the description provider device is the version value. If it is larger than the value specified in the access metadata request message, it may include the contents of the metadata section.
  • the metadata section may be identified by one or more identifiers according to hierarchical levels that divide the metadata section.
  • the searching of the metadata based on the contents of the metadata section may include searching for the metadata included in the metadata section element of the access metadata response message, or searching the metadata URL element of the access metadata response message.
  • the metadata can be retrieved from the location specified by.
  • the method comprising: receiving an access metadata request message indicating information about a metadata section that the requesting device wants to access from a requesting device, an access metadata response message including the metadata section;
  • a method of providing metadata of a description provider device is provided, the method including generating and transmitting the access metadata response message to the requesting device.
  • the metadata providing method of the description provider device may further include verifying a signature of the access metadata request message.
  • the metadata providing method of the description provider device may further include receiving a notification message from the requesting device.
  • the metadata providing method of the description provider device may include receiving a metadata scheme request message for accessing metadata from the requesting device, and receiving a metadata scheme response message indicating whether the metadata scheme is accessible.
  • the method may further include generating and transmitting the metadata scheme response message to the requesting device.
  • the metadata scheme response message is adapted to indicate a metadata scheme selected by the description provider device based on an optimal match between the characteristics of the requesting device and the description provider device. May include a scheme element.
  • a control unit for generating an access metadata request message indicating information about a metadata section to be accessed, and searching for metadata based on the contents of the metadata section and the access metadata request
  • a requesting device includes an interface portion for sending a message to a description provider device and for receiving an access metadata response message containing the contents of the metadata section from the description provider device.
  • Apparatus and methods are provided for accessing discovery metadata of different schemes.
  • FIG. 1 illustrates a method of using a protocol to access discovery metadata in an AIT value chain, according to an embodiment of the invention.
  • FIG. 2 is a diagram illustrating a representation of metadata sectioning according to an embodiment of the present invention.
  • FIG. 3 is a signal flow diagram of a discovery metadata protocol according to an embodiment of the present invention.
  • FIG. 4 is a structural diagram of an RD 302 according to an embodiment of the present invention.
  • FIG. 5 is a structural diagram of a DPD 304 according to an embodiment of the present invention.
  • FIG. 1 illustrates a method of using a protocol to access discovery metadata in an AIT value chain, according to an embodiment of the invention.
  • MXM MPEG Extensible Middleware
  • the proposed protocol is to allow MPEG AIT devices to access discovery metadata of different schemes.
  • the proposed protocol consists of between end-user devices (EUDs) 110, description service provider devices 120 and 130 and IPTV service provider devices 140 and 150. Enable metadata exchange.
  • IPTV service provider 140 or 150 can provide a description service
  • end-user device 110 may request metadata directly from IPTV service provider 140 or 150.
  • the approach used in the proposed protocol can support the modification of future metadata schemes and the addition of new metadata.
  • IPTV content provider 160 may provide the content to IPTV service provider 140 or 150.
  • IPTV service provider 140 or 150 may provide the content to end-consumer device 110.
  • FIG. 2 is a diagram illustrating a representation of metadata sectioning according to an embodiment of the present invention.
  • the metadata is divided into sections or subsections (regardless of schema choices).
  • Each section is identified by one or more identifiers, depending on the hierarchical level that divides the section.
  • each rectangle 210, 220, 230, 240, 250 or 260 represents one section (or subsection).
  • the identifier of each section is unique only within its parent section.
  • the first metadata section 250 of level-3 is identified by three identifiers A, B and C.
  • A denotes a name of a service provider
  • B denotes a service type of the corresponding service provider
  • C denotes a specific service provided by the corresponding service type.
  • the metadata coloring scheme is determined according to a specific IPTV metadata scheme.
  • Each section is associated with an attribute "version" used to update or synchronize metadata between players in the IPTV value chain.
  • a user may request to access or retrieve only a few sections of metadata (ie metadata associated with a particular provider's broadcast service). Later, if there is a change such as modification / addition of the metadata, the version value of the associated metadata section is increased so that the change can be known.
  • metadata ie metadata associated with a particular provider's broadcast service.
  • the protocol according to an embodiment of the present invention may support not only an existing metadata scheme but also a metadata scheme to be newly defined in the future.
  • protocol uses a general syntax for protocol messages, it uses a classification scheme (CS) to define the coloration / fragmentation structure of the metadata section. Can be represented.
  • CS classification scheme
  • the protocol message indicates the section to search or use, and the identifier of that section is referenced in the CS.
  • the advantage of this approach is that as metadata evolves, it can accommodate evolved metadata by modifying or creating new CSs without changing the protocol syntax.
  • FIG. 3 is a signal flow diagram of a discovery metadata protocol according to an embodiment of the present invention.
  • the protocol for accessing service discovery metadata is used by the requesting device (RD) to access metadata in another description provider device (DPD).
  • the RD 302 may be an End-User Device (EUD) 110 or a DPD.
  • EUD End-User Device
  • RD 302 and DPD 304 are mutually identifiable. If the RD 302 already knows the metadata schemes supported by the DPD 304, the following operations 310-340 can be omitted.
  • the RD 302 In operation 310, the RD 302 generates a metadata scheme request message (eg, an mxm: MetadataSchemeRequest message) for accessing specific metadata.
  • a metadata scheme request message eg, an mxm: MetadataSchemeRequest message
  • the metadata scheme request message includes a list of all metadata schemes supported by the RD 302 (eg, ITU-T, ETSI or ATIS).
  • the metadata scheme request message includes a priority attribute for each scheme of the list.
  • the RD 302 optionally signs a metadata scheme request message.
  • the RD 302 sends a metadata scheme request message to the DPD 304.
  • DPD 304 receives the metadata scheme request message.
  • the DPD 304 In operation 330, the DPD 304 generates a metadata scheme response message (eg, an mxm: MetadataSchemeResponse message).
  • the metadata scheme response message indicates whether (scheme) access is possible by the result attribute.
  • the scheme response message includes an "AdoptedScheme" element.
  • AdoptedScheme represents the metadata scheme selected by DPD 304 based on an optimal match between the characteristics of RD 302 and DPD 304.
  • the DPD 304 optionally signs a metadata scheme response message.
  • the DPD 304 sends a metadata scheme response message to the RD 302.
  • the RD 302 has prior knowledge of the metadata scheme provided by the DPD 304, or the operations 310, 315, 320, 330, 335 and 340 described above are executed and the RD 302 is executed. ) Receives an affirmative response from DPD 304, the following operations 350 to 395 are performed.
  • the RD 302 In operation 350, the RD 302 generates an access metadata request message (eg, an mxm: AccessMetadataRequest message).
  • the access metadata request message indicates information about a metadata section to be accessed.
  • the RD 302 optionally signs an access metadata request message.
  • the RD 302 sends an access metadata request message to the DPD 304.
  • the DPD 304 verifies the digital signature if there is a digital signature in the access metadata request message.
  • the DPD 304 can satisfy the request of the access metadata request message, the following operations 370 and 375 are performed.
  • the DPD 304 In operation 370, the DPD 304 generates an access metadata response message (eg, an mxm: AccessMetadataResponse) message.
  • an access metadata response message eg, an mxm: AccessMetadataResponse
  • the version value is not specified in the access metadata request message, or 2) the version value in the database of the DPD 304 of the section requested by the DPD 304 is the access metadata. If greater than the value specified in the request message, the contents of the metadata section requested by the DPD 304 are included in the access metadata response message. Otherwise, the metadata section requested by DPD 304 is not included in the access metadata response message.
  • the DPD 304 sends an access metadata response message to the RD 302.
  • the DPD 304 In operation 380, the DPD 304 generates a notification message (eg, an mxm: Ack message).
  • the notification message conveys information relating to the reason for the failure.
  • the DPD 304 sends a notification message to the RD 302.
  • the RD 302 optionally returns to the DPD 304 with a notification message.
  • the RD 302 retrieves the metadata contained in the "MetadataSection” element, or the meta from the location specified by the "MetadataURL” element of the access metadata response message. retrieve the data.
  • Table 1 below shows the definition of an access metadata protocol type (eg, AccessMetadataProtocolType).
  • the mxm: AccessMetadataProtocolType complex type defined as shown in Table 1, extends mxmbp: ProtocolType.
  • Table 2 below shows the definition of the response element (eg, the mxm: Ack element).
  • the response message is used to convey an error message in case of failure or to inform the success of the operation.
  • the mxm: Ack message extends the mxmbp: ProtocolResult message by adding a "Result" attribute that indicates whether the approved operation was successful.
  • Table 3 shows a definition of a metadata scheme request element (eg, an mxm: MetadataSchemeRequest element).
  • the metadata scheme request message is passed from the RD 302 to the DPD 304 to request permission to access some of the discovery metadata present in the DPD 304 database.
  • Table 4 shows the definition of the metadata scheme type (eg, mxm: MetadataSchemeType).
  • MetadataSchemeType complex type represents a metadata scheme defined in CS (eg, as defined in Table 12 below).
  • SchemeName can be any term in the CS.
  • EncodingScheme element carries a list of preferred encoding types for the requested metadata.
  • a CS defining possible metadata encoding types is provided in Table 16 below.
  • Table 5 shows the definition of an encoding scheme type (eg, mxm: EncodingSchemeType).
  • Table 6 below shows the definition of the metadata scheme response element (eg, the mxm: MetadataSchemeResponse element).
  • the mxm: MetadataSchemeResponse message is passed from DPD 304 to RD 302 in response to mxm: MetadataSchemeRequest.
  • the response includes confirmation or denial of the requested service.
  • the "Result” attribute is set to true, and the "AdoptedSchemeName” element indicates the “agreed metadata” scheme.
  • the "AdoptedEncoding” element indicates the encoding type of the metadata.
  • the Result attribute is set to "false” and the "ProtocolResult” element conveys the reason for the failure.
  • the "Signature” element can carry the digital signature of the message.
  • Table 7 below shows the definition of an access metadata request element (eg, an mxm: AccessMetadataRequest element).
  • RD 302 forwards the access metadata request message to DPD 304 to access the metadata.
  • An access metadata request (eg, mxm: AccessMetadataRequest) message may carry information as shown in Table 8 below.
  • SchemeName element indicates the type of metadata scheme to use for the requested metadata. If the metadata scheme request message and metadata ski response message have already been used to specify the metadata scheme, the SchemeName element is not used. If no metadata scheme request message and metadata scheme response message are used, and the RD 302 has prior knowledge of the metadata scheme supported by the DPD 304, a SchemeName element may be present to indicate the preferred scheme. Can be.
  • Encoding indicates the encoding type to be used for the requested metadata. The use of the Encoding element is similar to the use of the SchemeName element.
  • RequestedSections The RequestedSection element represents a group of requested sections at the level of the section hierarchy.
  • SectionCondition SectionCondition carries the identifiers of the requested metadata sections at the level of the section hierarchy. The following rules apply: 1) Higher level identifiers appear before lower level identifiers. Except for the lowest level, higher level identifiers appear only once. 2)
  • the type of metadata section is defined as a "SectionKind (section) that carries the items defined in Discovery CS (eg, Table 13, Table 14, and Table 15). Type) "element. Specific sections of that type are represented by "NumericValue” or “TextualValue” (depending on the type of metadata section as defined in Tables 12-16).
  • SectionKind can be "ServiceProvider” and TextualValue can be "www.Provider1.com”. 3) When all sections of a given type are requested, the “Value (Value) "element is not used. 4) To determine the requested section (s), higher level identifiers may be combined with the lowest level identifier.
  • Table 9 below is an XML instance.
  • the XML instance of Table 9 means that the "BroadcastService” type metadata section (or segment) Nos. 2 and 3 of "Provider1" are requested.
  • Table 10 shows a definition (eg, schema of an access metadata response message) of an access metadata response element (eg, an mxm: AccessMetadataResponse element).
  • the access metadata response message is sent as a reply to the access metadata request.
  • the access metadata response message is used by the DPD 304 to convey the information shown in Table 11 below.
  • the RepliedSection element is the element that carries the specific metadata section identified by the SectionCondition element as before, where each level's identifier appears only once. Latest If all requested metadata sections do not need to be returned or updated, the Latest property is set to true and no metadata section is sent. MetadataSection The MetadataSection element contains the metadata section that is passed in the reply message. MetadataURL The MetadataURL element represents a URL for obtaining the requested metadata section. As you can see in the syntax, only one element (MetadataSection or MetadataURL is used to pass the metadata section. dsig: Signature (dsig: signature) The dsig: Signature element represents the digital signature of the message. The dsig: Signature element is an optional value.
  • Table 12 shows a classification scheme for a list of service discovery metadata schemes.
  • Table 13 below shows a classification scheme for sections of the server discovery metadata of ETSI.
  • Table 14 below shows a classification scheme for sections of the server discovery metadata of ATIS.
  • Table 15 below shows a classification scheme for sections of the server discovery metadata of the ITU-T.
  • Table 16 shows a classification scheme for metadata encoding types.
  • FIG. 4 is a structural diagram of an RD 302 according to an embodiment of the present invention.
  • the RD 302 includes a controller 410 and an interface unit 420.
  • the controller 410 generates a message to be transmitted by the RD 302 and processes the message received by the RD 302. For example, the controller 410 processes the operations 310, 315, 350, 355, and 395.
  • the interface unit 420 transmits the generated message to the DPD 304 and receives the message from the DPD 304. For example, interface unit 420 transmits or receives a message of operations 320, 340, 360, 375, 385, and 390.
  • FIG. 5 is a structural diagram of a DPD 304 according to an embodiment of the present invention.
  • the DPD 304 includes a control unit 510, an interface unit 520, and a storage unit 530.
  • the controller 510 generates a message to be transmitted by the DPD 304 and processes the message received by the DPD 304. For example, the controller 510 processes the operations 330, 335, 365, 370 and 380.
  • the interface unit 520 transmits the generated message to the RD 302 and receives the message from the RD 302. For example, the interface unit 520 transmits or receives a message of operations 320, 340, 360, 375, 385, and 390.
  • the storage 530 provides the controller 510 with data necessary for the processing of the controller 510.
  • the storage unit 530 provides the metadata scheme to the controller 510.
  • Method according to an embodiment of the present invention can be implemented in the form of program instructions that can be executed by various computer means may be recorded on a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, and the like, alone or in combination.
  • Program instructions recorded on the media may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer readable recording media include magnetic media such as hard disks, floppy disks and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks such as floppy disks.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

서비스 디스커버리 메타데이터에 접근하기 위한 방법 및 장치가 제공된다. MXM 기반의 일반적인 프로토콜을 사용함으로써 MPEG의 AIT 디바이스들이 상이한 스킴의 디스커버리 메타데이터에 접근할 수 있다. 이러한 접근 방식에 의해 말단-소비자 디바이스들, 디스크립션 서비스 프로바이더 디바이스들 및 IPTV 서비스 프로바이더 디바이스들은 메타데이터를 교환할 수 있으며, 추후의 메타데이터 스킴의 수정 및 추가가 지원된다.

Description

디스커버리 메타데이터 접근을 위한 방법 및 장치
아래의 실시예들은 서비스 디스커버리 메타데이터에 접근하기 위한 방법 및 장치에 관한 것이다.
차세대 IPTV(advance IPTV)에서, 서비스 디스커버리 메타데이터에 접근하기 위한 일반적인(generic) 프로토콜(protocol)이 개시된다.
서비스 디스커버리 메타데이터(service discovery metadata)(짧게, 디스커버리 메타데이터)는 소비자(user)가 IPTV 서비스 또는 콘텐츠(content)를 발견하고 선택할 수 있게 한다.
디스커버리 메타데이터는 모든 IPTV 표준에서 가장 중요한 이슈(issue) 중 하나이다.
그러나, 각 표준화 단체에 의해 개발된 각각의 IPTV 표준은 서로 상이한 메타데이터 스킴(scheme)을 갖는다. 또한, 각 IPTV 표준에서, 특정 프로토콜들은 특정 스킴의 메타데이터 데이터베이스를 처리(예컨대, 접근 또는 업데이트(update))하도록 설계되었다.
반면, AIT 표준의 목적은 IPTV 가치사슬(value chain)의 빠른 디플로이먼트(deployment)가 가능하도록 일반적이며 효율적인 표준화된 프로토콜과 애플리케이션 프로그래밍 인터페이스(Application Programming Interface; API)들을 제공하는 것이다.
그러나, 현재의 상황에서는, 미래의 MPEG AIT 에코-시스템(eco-system)이 많은 현재 및 미래의 메타데이터 스킴(예컨대, 국제전기통신연합 전기통신표준화부문(International Telecommunication Union Telecommunication Standardization Sector; ITU-T), 유럽 전기통신 표준화기구(European Telecommunications Standards Institute; ETSI) 및 미국 통신 산업 연합(Alliance for Telecommunications Industry Solutions; ATIS))들을 처리할 것이 기대된다.
본 발명의 일 실시에는 상이한 스킴의 디스커버리 메타데이터에 접근하기 위한 장치 및 방법을 제공할 수 있다.
본 발명의 일 측에 따르면, 접근하고자 하는 메타데이터 색션에 대한 정보를 나타내는 접근 메타데이터 요청 메시지를 생성하는 동작, 상기 접근 메타데이터 요청 메시지를 디스크립션 프로바이더 디바이스에게 전송하는 동작, 상기 디스크립션 프로바이더 디바이스로부터 상기 메타데이터 색션의 내용을 포함하는 접근 메타데이터 응답 메시지를 수신하는 동작 및 상기 메타데이터 색션의 내용에 기반하여 메타데이터를 검색하는 동작을 포함하는, 요청 디바이스의 메타데이터 검색 방법이 제공된다.
상기 요청 디바이스의 메타데이터 검색 방법은, 상기 접근 메타데이터 요청 메시지에 서명하는 동작을 더 포함할 수 있다.
상기 요청 디바이스의 메타데이터 검색 방법은, 알림 메시지로 상기 디스크립션 프로바이더 디바이스에게 회신하는 동작을 더 포함할 수 있다.
상기 요청 디바이스의 메타데이터 검색 방법은, 상기 메타데이터에 접근하기 위한 메타데이터 스킴 요청 메시지를 생성하는 동작, 상기 메타데이터 스킴 요청 메시지를 상기 디스크립션 프로바이더 디바이스에게 전송하는 동작 및 상기 디스크립션 프로바이더 디바이스로부터 상기 메타데이터의 스킴에 접근 가능한지 여부를 나타내는 메타데이터 스킴 응답 메시지를 수신하는 동작을 더 포함할 수 있다.
상기 메타데이터 스킴 요청 메시지는 상기 요청 디바이스에 의해 지원되는 모든 메타데이트 스킴의 리스트 및 상기 리스트의 각 스킴을 위한 우선순위 속성을 포함할 수 있다.
상기 메타데이터의 스킴의 접근이 가능한 경우, 상기 메타데이터 스킴 응답 메시지는 상기 요청 디바이스 및 상기 디스크립션 프로바이더 디바이스의 특성들 간의 최적의 매치에 기반하여 상기 디스크립션 프로바이더 디바이스가 선택한 메타데이터 스킴을 나타내는 채택된 스킴 요소를 포함할 수 있다.
상기 메타데이터의 스킴의 접근이 가능하지 않은 경우, 상기 메타데이터 스킴 응답 메시지는 실패의 원인을 나타내는 스킴 결과 요소를 포함할 수 있다.
상기 접근 메타데이터 요청 메시지는 상기 메타데이터 스킴의 타입을 나타내는 스킴 이름 요소, 상기 메타데이터를 위해 사용될 인코딩 타입을 나타내는 인코딩 요소, 색션 계층의 레벨에서 요청받은 색션의 그룹을 나타내는 요청된 색션들 요소 및 상기 색션 계층의 레벨에서 요청받은 메타데이터 색션들의 식별자를 전달하는 색션 컨디션 요소 중 하나 이상을 포함할 수 있다.
상기 메타데이터 응답 메시지는 상기 메타데이터 요청 메시지가 상기 메타데이터 색선의 버전 값을 명시하지 않은 경우나, 상기 디스크립션 프로바이더 디바이스가 요청받은 상기 메타데이터 색션의 상기 디스크립션 프로바이더 디바이스에 있는 버전 값이 상기 접근 메타데이터 요청 메시지에서 명시된 값보다 더 큰 경우에 상기 메타데이터 색션의 내용을 포함할 수 있다.
상기 메타데이터 색션은 상기 메타데이터 색션을 나누는 계층 수준에 따른 한 개 이상의 식별자에 의해 식별될 수 있다.
상기 메타데이터 색션의 내용에 기반하여 메타데이터를 검색하는 동작은, 상기 접근 메타데이터 응답 메시지의 매타데이터 색션 요소에 포함된 상기 메타데이터를 검색하거나, 상기 접근 메타데이터 응답 메시지의 메타데이터 URL 요소에 의해 명시된 위치로부터 상기 메타데이터를 검색할 수 있다.
본 발명의 다른 일 측에 따르면, 요청 디바이스로부터 상기 요청 디바이스가 접근하고자 하는 메타데이터 색션에 대한 정보를 나타내는 접근 메타데이터 요청 메시지를 수신하는 동작, 상기 메타데이터 색션을 포함하는 접근 메타데이터 응답 메시지를 생성하는 동작 및 상기 접근 메타데이터 응답 메시지를 상기 요청 디바이스로 전송하는 동작을 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법이 제공된다.
상기 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법은, 상기 접근 메타데이터 요청 메시지의 서명을 확인하는 동작을 더 포함할 수 있다.
상기 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법은, 상기 요청 디바이스로부터 알림 메시지를 수신하는 동작을 더 포함할 수 있다.
상기 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법은, 상기 요청 디바이스로부터 메타데이터에 접근하기 위한 메타데이터 스킴 요청 메시지를 수신하는 동작, 상기 메타데이터의 스킴의 접근이 가능한지 여부를 나타내는 메타데이터 스킴 응답 메시지를 생성하는 동작 및 상기 메타데이터 스킴 응답 메시지를 상기 요청 디바이스로 전송하는 동작을 더 포함할 수 있다.
상기 메타데이터의 스킴의 접근이 가능한 경우, 상기 메타데이터 스킴 응답 메시지는 상기 요청 디바이스 및 상기 디스크립션 프로바이더 디바이스의 특성들 간의 최적의 매치에 기반하여 상기 디스크립션 프로바이더 디바이스가 선택한 메타데이터 스킴을 나타내는 채택된 스킴 요소를 포함할 수 있다.
본 발명의 또 다른 일측에 따르면, 접근하고자 하는 메타데이터 색션에 대한 정보를 나타내는 접근 메타데이터 요청 메시지를 생성하고, 상기 메타데이터 색션의 내용에 기반하여 메타데이터를 검색하는 제어부 및 상기 접근 메타데이터 요청 메시지를 디스크립션 프로바이더 디바이스에게 전송하고, 상기 디스크립션 프로바이더 디바이스로부터 상기 메타데이터 색션의 내용을 포함하는 접근 메타데이터 응답 메시지를 수신하는 인터페이스부를 포함하는, 요청 디바이스가 제공된다.
상이한 스킴의 디스커버리 메타데이터에 접근하기 위한 장치 및 방법이 제공된다.
도 1은 본 발명의 일 실시예에 따른 AIT 가치사슬에서 디스커버리 메타데이터에 접근하기 위해 프로토콜의 사용 방법을 도시한다.
도 2는 본 발명의 일 실시예에 따른 메타데이터 색셔닝(sectioning)의 표현을 나타낸 도이다.
도 3은 본 발명의 일 실시예에 따른 디스커버리 메타데이터 프로토콜의 신호 흐름도이다.
도 4는 본 발명의 일 예에 따른 RD(302)의 구조도이다.
도 5는 본 발명의 일 예에 따른 DPD(304)의 구조도이다.
이하에서, 본 발명의 일 실시예를, 첨부된 도면을 참조하여 상세하게 설명한다. 그러나, 본 발명이 실시예들에 의해 제한되거나 한정되는 것은 아니다. 각 도면에 제시된 동일한 참조 부호는 동일한 부재를 나타낸다.
도 1은 본 발명의 일 실시예에 따른 AIT 가치사슬에서 디스커버리 메타데이터에 접근하기 위해 프로토콜의 사용 방법을 도시한다.
MPEG 확장 가능한 미들웨어(MPEG Extensible Middleware; MXM) 기반의 일반적인 프로토콜이 제안된다.
제안된 프로토콜은 MPEG의 AIT 디바이스(device)들이 상이한 스킴의 디스커버리 메타데이터에 접근할 수 있도록 하기 위한 것이다.
제안된 프로토콜은 말단-소비자 디바이스(End-User Device; EUD)들(110), 디스크립션 서비스 프로바이더(description service provider) 디바이스들(120 및 130) 및 IPTV 서비스 프로바이더 디바이스들(140 및 150) 간의 메타데이터 교환을 가능하게 한다.
IPTV 서비스 프로바이더(140 또는 150)가 디스크립션 서비스를 제공할 수 있는 경우, 말단-사용자 디바이스(110)가 IPTV 서비스 프로바이더(140 또는 150)에게 직접적으로 메타데이터를 요청할 수 있다.
제안된 프로토콜에서 사용된 접근 방식은 추후의 메타데이터 스킴의 수정 및 새로운 메타데이터의 추가를 지원할 수 있다.
IPTV 콘텐츠 프로바이더(160)는 IPTV 서비스 프로바이더(140 또는 150)에게 콘텐츠들을 제공할 수 있다. IPTV 서비스 프로바이더(140 또는 150)는 말단-소비자 디바이스(110)에게 콘텐츠들을 제공할 수 있다.
도 2는 본 발명의 일 실시예에 따른 메타데이터 색셔닝(sectioning)의 표현을 나타낸 도이다.
네트워크에서 소비될 수 있는 콘텐츠들 또는 서비스들을 제공하는 프로바이더(provider)들이 다양하기 때문에, 디스커버리 메타데이터의 데이터베이스(database) 또는 그 양이 매우 많다.
따라서, 메타데이터의 효율적인 전송(업데이트(update)를 포함한다.)을 위해서, 메타데이터는 (스키마 선택들(schema choices)과 무관하게) 색션(section) 또는 서브섹션(subsection)들로 나뉘어 진다.
각 색션을 색션을 나누는 계층 수준(hierarchical level)에 따라서, 한 개 이상의 식별자에 의해 식별된다.
예컨대, 도 2에서 각 사각형(210, 220, 230, 240, 250 또는 260)은 한 개의 색션(또는 서브색션)을 나타낸다.
각 색션의 식별자는 바로 위의 부모 색션(parent section) 내에서만 고유하다.
도 2에서, 레벨-3(level-3)의 첫 번째 메타데이터 색션(250)은 3 개의 식별자들인 A, B 및 C에 의해 식별된다. 이 때, A는 서비스 프로바이더의 이름을, B는 해당 서비스 프로바이더의 서비스 타입을, C는 해당 서비스 타입에서 제공되는 특정한 서비스를 나타낸다.
메타데이터 색셔닝 방식은 특정 IPTV 메타데이터 스킴에 따라 결정된다.
각 색션은 IPTV 가치사슬 내의 플레이어(player)들 간에 메타데이터를 업데이트 또는 동기화하는데 사용되는 속성(attribute) "version(버전)"과 연관된다.
기본적으로, 소비자(user)는 메타데이터의 몇 개의 색션(즉, 특정 프로바이더의 방송 서비스와 관련된 메타데이터) 만을 접근 또는 검색하기를 요청할 수 있다. 나중에, 만약 메타데이터의 수정/추가와 같은 변화가 있다면, 관련된 메타데이터 색션의 버전 값이 증가하여 변화가 알려질 수 있게 된다.
명백히, 특정한 단체에 의해 정의된 메타데이터의 스키마에 접근하기 위한 특정한 프로토콜을 설계하는 것은 비효율적인 방법이다. 본 발명의 일 예에 따른 프로토콜은 이미 존재하는 메타데이터 스킴 뿐만 아닌 미래에 새롭게 정의될 메타테이터 스킴 또한 지원할 수 있다.
본 발명의 일 예에 따른 프로토콜은 프로토콜 메시지를 위한 일반적인 신택스(syntax)를 사용하는 반면, 분류 스킴(Classification Scheme; CS)을 사용하여 메타데이터 색션의 색셔닝/프래그맨테이션(fragmentation) 구조를 나타낼 수 있다.
프로토콜 메시지는 검색 혹은 사용하고자 하는 섹션을 나타내며, 해당 섹션의 식별자는 CS에서 참조된다. 이러한 방식의 장점은, 메타데이터가 진화함에 따라, 프로토콜 신택스의 변화없이, CS를 수정하거나 새롭게 만들어내는 것에 의해 진화된 메타데이터를 수용할 수 있다는 것이다.
ETSI IPTV(DVB-IP) 및 ATIS IPTV(IIF)를 위한 CS의 일 예가 하기의 표 12 내지 표16에서 설명된다.
도 3은 본 발명의 일 실시예에 따른 디스커버리 메타데이터 프로토콜의 신호 흐름도이다.
서비스 디스커버리 메타데이터에 접근하기 위한 프로토콜은, 다른 디스크립션 프로바이더 디바이스(Description Provider Device; DPD)에 있는 메타데이터에 접근하기 위하여 요청하는 디바이스(Requesting Device; RD)에 의해 사용된다.
RD(302)는 말단-소비자 디바이스(End-User Device; EUD)(110) 또는 DPD일 수 있다.
RD(302) 및 DPD(304)는 상호 식별 가능하다. RD(302)가 DPD(304)에 의해 지원되는 메타데이터 스킴들을 이미 알고 있다면, 하기의 동작들(310 내지 340)은 생략될 수 있다.
동작(310)에서, RD(302)는 특정 메타데이터에 접근하기 위한 메타데이터 스킴 요청 메시지(예컨대, mxm:MetadataSchemeRequest 메시지)를 생성한다.
메타데이터 스킴 요청 메시지는 RD(302)(예컨대, ITU-T, ETSI 또는 ATIS)에 의해 지원되는 모든 메타데이터 스킴의 리스트를 포함한다. 또한, 메타데이터 스킴 요청 메시지는 상기 리스트의 각 스킴을 위한 우선순위(priority) 속성을 포함한다.
동작(315)에서, RD(302)는 메타데이터 스킴 요청 메시지에 선택적으로 서명(sign)한다.
동작(320)에서, RD(302)는 메타데이터 스킴 요청 메시지를 DPD(304)로 전송한다. DPD(304)는 메타데이터 스킴 요청 메시지를 수신한다.
동작(330)에서, DPD(304)는 메타데이터 스킴 응답 메시지(예컨대, mxm:MetadataSchemeResponse 메시지)를 생성한다. 메타데이터 스킴 응답 메시지는 결과(result) 속성에 의해 (스킴의) 접근이 가능한지 아닌지 여부를 나타낸다.
만약, 접근이 가능한 경우, 스킴 응답 메시지는 "AdoptedScheme(채택된 스킴)" 요소(element)를 포함한다. AdoptedScheme은 RD(302) 및 DPD(304)의 특성들 간의 최적의 매치(match)에 기반하여 DPD(304)가 선택한 메타데이터 스킴을 나타낸다.
만약, 접근이 가능하지 않은 경우, 실패의 원인을 나타내는 "SchemeResult(스킴 결과)" 요소가 실패의 원인을 전달한다.
동작(335)에서, DPD(304)는 메타데이터 스킴 응답 메시지에 선택적으로 서명한다.
동작(340)에서 DPD(304)는 메타데이터 스킴 응답 메시지를 RD(302)로 전송한다.
RD(302)가 DPD(304)에 의해 제공되는 메타데이터 스킴에 관한 지식을 사전에 가지고 있는 경우, 또는 전술된 동작들(310, 315, 320, 330, 335 및 340)이 실행되고 RD(302)가 DPD(304)로부터 긍적적인(affirmative) 반응을 수신한 경우, 하기의 동작들(350 내지 395) 이 실행된다.
동작(350)에서, RD(302)는 접근 메타데이터 요청 메시지(예컨대, mxm:AccessMetadataRequest 메시지)를 생성한다. 접근 메타데이터 요청 메시지는 접근하고자 하는 메타데이터 색션에 관한 정보를 나타낸다.
동작(355)에서, RD(302)는 접근 메타데이터 요청 메시지에 선택적으로 서명한다.
동작(360)에서, RD(302)는 접근 메타데이터 요청 메시지를 DPD(304)로 전송한다.
동작(365)에서, DPD(304)는 접근 메타데이터 요청 메시지에 디지털 서명이 있으면, 디지털 서명을 확인한다.
DPD(304)가 접근 메타데이터 요청 메시지의 요청을 만족시킬 수 있는 경우, 하기의 동작들(370 및 375)이 수행된다.
동작(370)에서, DPD(304)는 접근 메타데이터 응답 메시지(예컨대, mxm:AccessMetadataResponse) 메시지를 생성한다.
각각의 요청된 색션에 대해서, 1) 접근 메타데이터 요청 메시지에서 버전 값이 명시되지 않은 경우나, 2) DPD(304)가 요청받은 색션의 DPD(304)의 데이터베이스에 있는 버전 값이 접근 메타데이터 요청 메시지에서 명시된 값보다 더 큰 경우, DPD(304)가 요청 받은(requested) 메타데이터 색션의 내용은 접근 메타데이터 응답 메시지에 포함된다. 그렇지 않은 경우, DPD(304)가 요청 받은 메타데이터 색션은 접근 메타데이터 응답 메시지에 포함되지 않는다.
만약, 접근 메타데이터 응답 메시지에 포함된 메타데이터 색션이 없으면, " Latest(최신)" 속성은 " true(참)"으로 설정된다.
동작(375)에서, DPD(304)는 접근 메타데이터 응답 메시지를 RD(302)로 전송한다.
DPD(304)가 접근 메타데이터 요청 메시지의 요청을 만족시킬 수 없는 경우, 하기의 동작들(380 및 385)이 수행된다.
동작(380)에서, DPD(304)는 알림 메시지(예컨대, mxm:Ack 메시지)를 생성한다. 알림 메시지는 실패에 대한 이유와 관련된 정보를 전달한다.
동작(385)에서, DPD(304)는 알림 메시지를 RD(302)로 전송한다.
동작(390)에서, RD(302)는 알림 메시지로 DPD(304)에게 선택적으로 회신한다.
동작(395)에서, RD(302)는 "MetadataSection(메타데이터 색션)" 요소에 포함된 메타데이터를 검색하거나, 접근 메타데이터 응답 메시지의 " MetadataURL(메타데이터 URL)" 요소에 의해 명시된 위치로부터 메타데이터를 검색한다.
하기의 표 1은 접근 메타데이터 프로토콜 타입(예컨대, AccessMetadataProtocolType)의 정의를 나타낸다.
표 1
<complexType name="AccessMetadataProtocolType" abstract="true"> <complexContent> <extension base="mxmbp:ProtocolType"/> </complexContent></complexType>
표 1과 같이 정의된 mxm:AccessMetadataProtocolType 콤플렉스(complex) 타입(type)은 mxmbp:ProtocolType을 확장한다.
하기의 표 2는 응답 요소(예컨대, mxm:Ack 요소)의 정의를 나타낸다.
응답 메시지는 실패한 경우의 에러 메시지를 전달하거나, 동작의 성공을 알리기 위해 사용된다.
표 2
<element name="Ack" type="mxm:AckType"/><complexType name="AckType"> <complexContent> <extension base="mxm:AccessMetadataProtocolType"> <sequence minOccurs="0"> <element ref="mxmbp:ProtocolResult"/> </sequence> <attribute name="Result" type="boolean" use="required"/> </extension> </complexContent></complexType>
mxm:Ack 메시지는 승인된 동작이 성공적인지 아닌지를 나타내는 "Result(결과)" 속성을 추가함으로써 mxmbp:ProtocolResult 메시지를 확장한다.
하기의 표 3은 메타데이터 스킴 요청 요소(예컨대, mxm:MetadataSchemeRequest 요소)의 정의를 나타낸다.
메타데이터 스킴 요청 메시지는 DPD(304) 데이터베이스에 존재하는 디스커버리 메타데이터의 일부를 접근하기 위한 허가를 요청하기 위해 RD(302)로부터 DPD(304)로 전달된다.
표 3
<!-- Definition of MetadataSchemeRequest --> <element name="MetadataSchemeRequest" type="mxm:MetadataSchemeRequestType"/> <complexType name="MetadataSchemeRequestType"> <complexContent> <extension base="mxm:ProtocolRequestType"> <sequence> <element name="MetadataScheme" type="mxm:MetadataSchemeType" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>
하기의 표 4는 메타데이터 스킴 타입(예컨대, mxm:MetadataSchemeType)의 정의를 나타낸다.
표 4
<complexType name="MetadataSchemeType"> <complexContent> <extension base="mxm:ProtocolBaseType"> <sequence> <element name="SchemeName" type="mpeg7:ControlledTermUseType"/> </sequence> <attribute name="priority" type="int" use="required"/> </extension> </complexContent> </complexType>
mxm:MetadataSchemeType 콤플렉스 타입은 CS(예컨대, 하기의 표 12에서 정의된 것과 같은)에서 정의된 메타데이터 스킴을 나타낸다.
이러한 타입의 "SchemeName(스킴 이름)" 요소에는 CS의 어떠한 항목(term)도 올 수 있다.
메타데이터 스킴의 모든 타입들은 "priority(우선순위)" 속성에 의해 특성 지워지며, priority 속성은 의도된 우선순위에 역으로 비례하는 정수 값이다. 예컨대, "priority='1'"은 가장 우선순위가 높은 것을 의미한다.
유시하게, "EncodingScheme(인코딩 스킴)" 요소는 요청 받은 메타데이터를 위한 선호하는 인코딩 타입의 리스트를 전달한다. 가능한 메타데이터 인코딩 타입을 정의한 CS가 하기의 표 16에서 제공된다.
하기의 표 5는 인코딩(encoding) 스킴 타입(예컨대, mxm:EncodingSchemeType)의 정의를 나타낸다.
표 5
<complexType name="EncodingSchemeType"> <complexContent> <extension base="mxmbp:ProtocolBaseType"> <sequence> <element name="Encoding" type="mpeg7:ControlledTermUseType"/> </sequence> <attribute name="priority" type="int" use="required"/> </extension> </complexContent></complexType>
하기의 표 6은 메타데이터 스킴 응답 요소(예컨대, mxm:MetadataSchemeResponse 요소)의 정의를 나타낸다.
mxm:MetadataSchemeResponse 메시지는 mxm:MetadataSchemeRequest에 대한 응답으로서 DPD(304)에서 RD(302)로 전달된다
표 6
<element name="MetadataSchemeResponse" type="mxm:MetadataSchemeResponseType"/> <complexType name="MetadataSchemeResponseType"> <complexContent> <extension base="mxm:ProtocolResponseType"> <sequence> <element name="AdoptedSchemeName" type="mpeg7:ControlledTermUseType" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>
응답은 요청 받은 서비스의 확인 또는 거부를 포함한다.
응답이 확인을 포함하는 경우, "Result(결과)" 속성은 true로 설정되고, "AdoptedSchemeName(채택된 스킴 이름)" 요소는 "agreed metadata(동의된 메타데이터)" 스킴을 나타낸다. 추가로, "AdoptedEncoding(채택된 인코딩)" 요소는 메타데이터의 인코딩 타입을 나타낸다.
응답이 거부를 포함하는 경우, Result 속성은 "false(거짓)"으로 설정되고, "ProtocolResult(프로토콜 결과)" 요소는 실패의 이유를 전달한다. (선택적으로) "Signature(서명)" 요소는 메시지의 디지털 서명을 전달할 수 있다.
하기의 표 7은 접근 메타데이터 요청 요소(예컨대, mxm:AccessMetadataRequest 요소)의 정의를 나타낸다.
RD(302)는 메타데이터에 접근하기 위해서 접근 메타데이터 요청 메시지를 DPD(304)로 전달한다.
표 7
<!-- Definition of RequestMetadataRequest --> <element name="RequestMetadataRequest" type="mxm:RequestMetadataRequestType"/> <complexType name="RequestMetadataRequestType"> <complexContent> <extension base="mxm:ProtocolRequestType"> <sequence> <element name="SchemeName" type="mpeg7:ControlledTermUseType" minOccurs="0"/> <choice> <element name="RequestedSection" type="mxm:RequestedSectionType"/> <element name="RequestedFragmentUri" type="anyURI"/> </choice> </sequence> </extension> </complexContent> </complexType> <element name="AccessMetadataRequest" type="mxmamp:AccessMetadataRequestType"/><complexType name="AccessMetadataRequestType"> <complexContent> <extension base="mxmamp:AccessMetadataProtocolType"> <sequence> <element name="SchemeName" type="mpeg7:ControlledTermUseType" minOccurs="0"/> <element name="Encoding" type="mpeg7:ControlledTermUseType" minOccurs="0"/> <element name="RequestedSections" type="mxmamp:RequestedSectionsType" minOccurs="0" maxOccurs="unbounded"/> <element ref="dsig:Signature" minOccurs="0"/> </sequence> </extension> </complexContent></complexType><!-- Definition of RequestedSectionType --> <complexType name="RequestedSectionType"> <complexContent> <extension base="mxm:ProtocolBaseType"> <sequence> <element name="SectionCondition" type="mxm:SectionConditionType" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType><!-- Definition of SectionConditionType --> <complexType name="SectionConditionType"> <complexContent> <extension base="mxm:ProtocolBaseType"> <sequence> <element name="SectionKind" type="mpeg7:ControlledTermUseType"/> <element name="Identification" type="mxm:IdentificationType" minOccurs="0"/> </sequence> <attribute name="Version" type="int" use="optional"/> </extension> </complexContent> </complexType><complexType name="ValueType"> <complexContent> <extension base="mxmbp:ProtocolBaseType"> <choice> <element name="NumericValue" type="int"/> <element name="TextualValue" type="string"/> </choice> </extension> </complexContent></complexType>
접근 메타데이터 요청(예컨대, mxm:AccessMetadataRequest) 메시지는 하기의 표 8과 같은 정보를 전달할 수 있다.
표 8
이름 설명
SchemeName(스킴 이름) SchemeName 요소는 요청받은 메타데이터를 위해 사용할 메타데이터 스킴의 타입을 나타낸다.메타데이터 스킴 요청 메시지 및 메타데이터 스키 응답 메시지가 메타데이터 스킴을 정하기 위해 이미 사용된 경우, SchemeName 요소는 사용되지 않는다.그러나, 메타데이터 스킴 요청 메시지 및 메타데이터 스킴 응답 메시지가 사용되지 않고, RD(302)가 DPD(304)에 의해 지원되는 메타데이터 스킴에 대한 사전 지식이 있다면, SchemeName 요소는 선호하는 스킴을 나타내기 위해서 존재할 수 있다.
Encoding(인코딩) Encoding 요소는 요청받은 메타데이터를 위해 사용될 인코딩 타입을 나타낸다.Encoding 요소의 사용은 SchemeName 요소의 사용과 유사하다.
RequestedSections(요청된 색션들) RequestedSection 요소는 색션 계층의 레벨에서 요청받은 색션의 그룹을 나타낸다.RequestedSection 요소의 다른 인스턴스(instance)에 의해 지목당하는 요청받은 색션 그룹들은 중복되지 않아야 한다.
SectionCondition(색션 컨디션) SectionCondition 은 색션 계층의 레벨에서 요청받은 메타데이터 색션들의 식별자를 전달한다. 하기의 규칙들이 적용된다.1) 더 높은 레벨의 식별자는 더 낮은 레벨의 식별자보다 먼저 나타난다. 가장 낮은 레벨을 제외하고, 더 높은 레벨의 식별자는 한 번만 나타난다.2) 메타데이터 색션의 타입은 디스커버리 CS(예컨대, 표 13, 표 14 및 표 15)에서 정의된 항목들을 전달하는 " SectionKind(색션 종류)" 요소에 의해 나타내어진다. 그러한 타입의 특정 색션은 " NumericValue(뉴메릭 값)" 또는 " TextualValue(텍스트 값)"(표 12 내지 표 16에서 정의된 것과 같은 메타데이터 색션의 타입에 따라서)에 의해 나타내어진다. 예컨대, ETSI IPTV를 위한 CS 항목을 사용할 때, SectionKind 는 "ServiceProvider"가 될 수 있고, TextualValue은 "www.Provider1.com"이 될 수 있다.3) 주어진 타입의 모든 색션이 요청될 때, " Value(값)" 요소는 사용되지 않는다.4) 요청받은 색션(들)을 결정하기 위해서, 더 높은 레벨들의 식별자들은 가장 낮은 레벨의 식별자와 결합될 수 있다.
하기의 표 9는 XML 인스턴스이다. 표 9의 XML 인스턴스는 "Provider1"의 "BroadcastService(브로드캐스트 서비스)" 타입 메타데이터 색션(또는, 세그먼트(segment)) No.2 및 No.3을 요청하는 것을 의미한다.
표 9
<RequestedSections> <SectionCondition> <SectionKind href=" urn:mpeg:ait:2010:DiscoveryCS-NS:2"> <mpeg7:Name>ServiceProvider</mpeg7:Name> </SectionKind> <Value><TextualValue>www.Provider1.com</TextualValue></Value> </SectionCondition> <SectionCondition> <SectionKind href=" urn:mpeg:ait:2010:DiscoveryCS-NS:2.1"> <mpeg7:Name>BroadcastService</mpeg7:Name> </SectionKind> <Value><NumericValue>2</NumericValue></Value> </SectionCondition> <SectionCondition> <SectionKind href=" urn:mpeg:ait:2010:DiscoveryCS-NS:2.1"> <mpeg7:Name>BroadcastService</mpeg7:Name> </SectionKind> <Value><NumericValue>3</NumericValue></Value> </SectionCondition><RequestedSections>
표 9에서, "Version(버전)"은 요청하는 색션의 현재 버전 값을 나타내기 위해 사용되는 속성이다. "dsig:Signature)"은 메시지의 디지털 서명을 나타낸다. "dsig:Signature "은 선택적인(optional) 값이다.
하기의 표 10은 접근 메타데이터 응답 요소(예컨대, mxm:AccessMetadataResponse 요소)의 정의(예컨대, 접근 메타데이터 응답 메시지의 스키마)를 나타낸다.
표 10
<element name="AccessMetadataResponse" type="mxmaitp:AccessMetadataResponseType"/><complexType name="AccessMetadataResponseType"> <complexContent> <extension base="mxm:AccessMetadataProtocolType"> <sequence> <element name="RepliedSection" type="mxm:RepliedSectionType" minOccurs="0" maxOccurs="unbounded"/> <element ref="dsig:Signature" minOccurs="0"/> </sequence> <attribute name="Latest" type="boolean" use="optional"/> </extension> </complexContent></complexType><complexType name="RepliedSectionType"> <complexContent> <extension base="mxmbp:ProtocolBaseType"> <sequence> <element name="SectionCondition" type="mxm:SectionConditionType" maxOccurs="unbounded"/> <choice> <element name="MetadataSection"> <complexType> <sequence> <any namespace="##any" processContents="skip"/> </sequence> </complexType> </element> <element name="MetadataURL" type="anyURI"/> </choice> </sequence> </extension> </complexContent></complexType>
접근 메타데이터 응답 메시지는 접근 메타데이터 요청의 회신으로서 보내진다.
접근 메타데이터 응답 메시지는 하기의 표 11과 같은 정보를 전달하기 위해 DPD(304)에 의해 사용된다.
표 11
이름 설명
RepliedSection (리플라이된 색션) RepliedSection 요소는 이전처럼 SectionCondition 요소에 의해 식별되는 특정 메타데이터 색션을 전달하는 요소임.이 때, 각 레벨의 식별자는 한 번만 나타난다.
Latest(최신) 모든 요청받은 메타데이터 색션이 회신 또는 업데이트될 필요가 없을 경우 Latest 속성은 true로 설정되고, 어떠한 메타데이터 색션도 보내지지 않는다.
MetadataSection(메타데이터 색션) MetadataSection 요소는 회신 메시지에 전달되는 메타데이터 색션을 포함한다.
MetadataURL(메타데이터 URL) MetadataURL 요소는 요청받은 메타데이터 색션을 얻기 위한 URL을 나타낸다. 신택스에서 볼 수 있듯이, 한 개의 요소(MetadataSection 또는 MetadataURL 만이 메타데이터 색션을 전달하기 위해 사용된다.
dsig:Signature (dsig:서명) dsig:Signature 요소는 메시지의 디지털 서명을 나타낸다. dsig:Signature 요소는 선택적인 값이다.
하기의 표 12는 서비스 디스커버리 메타데이터 스킴의 리스트를 위한 분류(classification) 스킴을 나타낸다.
표 12
<ClassificationScheme uri="urn:mpeg:ait:2010:DiscoveryMetadataSchemesCS-NS" > <Term termed="1"> <Name xml:lang="en">ETSI-Service-Discovery</Name> <Definition xml:lang="en"> Indicates the metadata scheme of ETSI IPTV for service discovery. </Definition> </Term> <Term termed="2"> <Name xml:lang="en">ATIS-Service-Discovery</Name> <Definition xml:lang="en"> Indicates the metadata scheme of ATIS IPTV for service discovery. </Definition> </Term> <Term termed="3"> <Name xml:lang="en">ITUT-Service-Discovery</Name> <Definition xml:lang="en"> Indicates the metadata scheme of ITU-T IPTV for service discovery. </Definition> </Term></ClassificationScheme>
하기의 표 13은 ETSI의 서버스 디스커버리 메타데이터의 색션들을 위한 분류 스킴을 나타낸다.
표 13
<ClassificationScheme uri="urn:mpeg:ait:2010:ETSIDiscoveryCS-NS"> <Term termId="1"> <Name xml:lang="en">ServiceProviderDiscovery</Name> <Definition xml:lang="en"> Indicates the metadata for service provider discovery information (payload ID 0x01). Metadata of this type could be divided into sections, identified by numeric values. </Definition> </Term> <Term termId="2"> <Name xml:lang="en">ServiceProvider</Name> <Definition xml:lang="en"> Indicates all service discovery metadata of an IPTV Service Provider. Different service providers are differentiated by their domain names (i.e. textual values). </Definition> <Term termId="2.1"> <Name xml:lang="en">BroadcastService</Name> <Definition xml:lang="en"> Indicates metadata for broadcast service discovery of an IPTV Service Provider (payload ID 0x02). Metadata of this type could be divided into sections, identified by numeric values. </Definition> </Term> <Term termId="2.2"> <Name xml:lang="en">CoDService</Name> <Definition xml:lang="en"> Indicates metadata for Content-on-Demand service discovery of an IPTV Service Provider (payload ID 0x03). Metadata of this type could be divided into sections, identified by numeric values. </Definition> </Term> <Term termId="2.3"> <Name xml:lang="en">ServicesFromOtherSP</Name> <Definition xml:lang="en"> Indicates metadata for referenced service discovery at an IPTV Service Provider (payload ID 0x04). Metadata of this type could be divided into sections, identified by numeric values. </Definition> </Term> <Term termId="2.4"> <Name xml:lang="en">PackageService</Name> <Definition xml:lang="en"> Indicates metadata for package service discovery of an IPTV Service Provider (payload ID 0x05). Metadata of this type could be divided into sections, identified by numeric values. </Definition> </Term> <Term termId="2.5"> <Name xml:lang="en">BCGService</Name> <Definition xml:lang="en"> Indicates metadata for BCG (Broadband Content Guide) service discovery of an IPTV Service Provider (payload ID 0x06). Metadata of this type could be divided into sections, identified by numeric values. Note: BCG metadata will have its own classification scheme. </Definition> </Term> </Term></ClassificationScheme>
하기의 표 14는 ATIS의 서버스 디스커버리 메타데이터의 색션들을 위한 분류 스킴을 나타낸다.
표 14
<ClassificationScheme uri="urn:mpeg:ait:2010:ATISDiscoveryCS-NS"> <Term termId="1"> <Name xml:lang="en">ServiceProviderInfo</Name> <Definition xml:lang="en">Indicates a metadata record of ATIS IIF ServiceProviderInfoType which provides information about different IPTV service providers</Definition> </Term> <Term termId="2"> <Name xml:lang="en">ServiceProvider</Name> <Definition xml:lang="en">Indicates all service discovery metadata of an IPTV Service Provider</Definition> <Term termId="2.1"> <Name xml:lang="en">ProvisioningInfo</Name> <Definition xml:lang="en">Indicates a metadata record of ATIS IIF ProvisioningInfoType which provides provisioning information from an IPTV service provider</Definition> </Term> <Term termId="2.2"> <Name xml:lang="en">Master SI Table</Name> <Definition xml:lang="en"> Indicates a metadata record of ATIS IIF MasterSiTableType which is a list of virtual channel map tables of a given service provider.</Definition> </Term> <Term termId="2.3"> <Name xml:lang="en">Virtual Channel Map</Name> <Definition xml:lang="en">Indicates a metadata record of ATIS IIF VirtualChannelMapType which is a list of virtual channels. Each record is identified by a textual string representing the URI of the record</Definition> </Term> <Term termId="2.4"> <Name xml:lang="en">Virtual Channel Description</Name> <Definition xml:lang="en"> Indicates a metadata record of ATIS IIF VirtualChannelDescriptionType which is a description of virtual channels. Each record is identified by a textual string representing the URI of the record</Definition> </Term> <Term termId="2.5"> <Name xml:lang="en">Source</Name> <Definition xml:lang="en"> Indicates a metadata record of ATIS IIF SourceType which shows acquisition information for virtual channels. Each record is identified by a textual string representing the URI of the record </Definition> </Term> <Term termId="2.6"> <Name xml:lang="en">EPGInfo</Name> <Definition xml:lang="en"> Indicates all metadata for electronic program guide. Note: EPG metadata will have its own classification scheme. </Definition> </Term></ClassificationScheme>
하기의 표 15는 ITU-T의 서버스 디스커버리 메타데이터의 색션들을 위한 분류 스킴을 나타낸다.
표 15
<ClassificationScheme uri="urn:mpeg:ait:2010:ITUTDiscoveryCS-NS"> <Term termed="1"> <Name xml:lang="en">ITUT</Name> <Definition xml:lang="en"> This CS will be described once the schema of ITU-T IPTV service discovery is completed. </Definition> </Term></ClassificationScheme>
하기의 표 16은 메타데이터 인코딩 타입들에 대한 분류 스킴을 나타낸다.
표 16
<ClassificationScheme uri="urn:mpeg:ait:2010:DiscoveryMetadataSchemesCS-NS" > <Term termed="1"> <Name xml:lang="en">ETSI-Service-Discovery</Name> <Definition xml:lang="en"> Indicates the metadata scheme of ETSI IPTV for service discovery. </Definition> </Term> <Term termed="2"> <Name xml:lang="en">ATIS-Service-Discovery</Name> <Definition xml:lang="en"> Indicates the metadata scheme of ATIS IPTV for service discovery. </Definition> </Term> <Term termed="3"> <Name xml:lang="en">ITUT-Service-Discovery</Name> <Definition xml:lang="en"> Indicates the metadata scheme of ITU-T IPTV for service discovery. </Definition> </Term></ClassificationScheme>
도 4는 본 발명의 일 예에 따른 RD(302)의 구조도이다.
RD(302)는 제어부(410) 및 인터페이스부(420)를 포함한다.
제어부(410)는 RD(302)가 전송할 메시지를 생성하고, RD(302)가 수신한 메시지를 처리한다. 예컨대, 제어부(410)는 동작들(310, 315, 350, 355 및 395)을 처리한다.
인터페이스부(420)는 생성된 메시지를 DPD(304)로 전송하고, DPD(304)로부터 메시지를 수신한다. 예컨대, 인터페이스부(420)는 동작들(320, 340, 360, 375, 385 및 390)의 메시지를 송신 또는 수신한다.
앞서 도 1 내지 도 3을 참조하여 설명된 본 발명의 일 실시예에 따른 기술적 내용들이 본 실시예에도 그대로 적용될 수 있다. 따라서 보다 상세한 설명은 이하 생략하기로 한다.
도 5는 본 발명의 일 예에 따른 DPD(304)의 구조도이다.
DPD(304)는 제어부(510), 인터페이스부(520) 및 저장부(530)를 포함한다.
제어부(510)는 DPD(304)가 전송할 메시지를 생성하고, DPD(304)가 수신한 메시지를 처리한다. 예컨대, 제어부(510)는 동작들(330, 335, 365, 370 및 380)을 처리한다.
인터페이스부(520)는 생성된 메시지를 RD(302)로 전송하고, RD(302)로부터 메시지를 수신한다. 예컨대, 인터페이스부(520)는 동작들(320, 340, 360, 375, 385 및 390)의 메시지를 송신 또는 수신한다.
저장부(530)는 제어부(510)의 처리에 필요한 데이터를 제어부(510)에게 제공한다. 예컨대, 저장부(530)는 메타데이터 스킴 등을 제어부(510)에게 제공한다.
앞서 도 1 내지 도 4를 참조하여 설명된 본 발명의 일 실시예에 따른 기술적 내용들이 본 실시예에도 그대로 적용될 수 있다. 따라서 보다 상세한 설명은 이하 생략하기로 한다.
본 발명의 일 실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상과 같이 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다.
그러므로, 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (20)

  1. 접근하고자 하는 메타데이터 색션에 대한 정보를 나타내는 접근 메타데이터 요청 메시지를 생성하는 동작;
    상기 접근 메타데이터 요청 메시지를 디스크립션 프로바이더 디바이스에게 전송하는 동작;
    상기 디스크립션 프로바이더 디바이스로부터 상기 메타데이터 색션의 내용을 포함하는 접근 메타데이터 응답 메시지를 수신하는 동작; 및
    상기 메타데이터 색션의 내용에 기반하여 메타데이터를 검색하는 동작
    를 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  2. 제1항에 있어서,
    상기 접근 메타데이터 요청 메시지에 서명하는 동작
    를 더 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  3. 제1항에 있어서,
    알림 메시지로 상기 디스크립션 프로바이더 디바이스에게 회신하는 동작
    를 더 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  4. 제1항에 있어서,
    상기 메타데이터에 접근하기 위한 메타데이터 스킴 요청 메시지를 생성하는 동작;
    상기 메타데이터 스킴 요청 메시지를 상기 디스크립션 프로바이더 디바이스에게 전송하는 동작; 및
    상기 디스크립션 프로바이더 디바이스로부터 상기 메타데이터의 스킴에 접근 가능한지 여부를 나타내는 메타데이터 스킴 응답 메시지를 수신하는 동작
    를 더 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  5. 제4항에 있어서,
    상기 메타데이터 스킴 요청 메시지는 상기 요청 디바이스에 의해 지원되는 모든 메타데이트 스킴의 리스트 및 상기 리스트의 각 스킴을 위한 우선순위 속성을 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  6. 제4항에 있어서,
    상기 메타데이터의 스킴의 접근이 가능한 경우, 상기 메타데이터 스킴 응답 메시지는 상기 요청 디바이스 및 상기 디스크립션 프로바이더 디바이스의 특성들 간의 최적의 매치에 기반하여 상기 디스크립션 프로바이더 디바이스가 선택한 메타데이터 스킴을 나타내는 채택된 스킴 요소를 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  7. 제4항에 있어서,
    상기 메타데이터의 스킴의 접근이 가능하지 않은 경우, 상기 메타데이터 스킴 응답 메시지는 실패의 원인을 나타내는 스킴 결과 요소를 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  8. 제4항에 있어서,
    상기 접근 메타데이터 요청 메시지는 상기 메타데이터 스킴의 타입을 나타내는 스킴 이름 요소, 상기 메타데이터를 위해 사용될 인코딩 타입을 나타내는 인코딩 요소, 색션 계층의 레벨에서 요청받은 색션의 그룹을 나타내는 요청된 색션들 요소 및 상기 색션 계층의 레벨에서 요청받은 메타데이터 색션들의 식별자를 전달하는 색션 컨디션 요소 중 하나 이상을 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  9. 제1항에 있어서,
    상기 메타데이터 응답 메시지는 상기 메타데이터 요청 메시지가 상기 메타데이터 색선의 버전 값을 명시하지 않은 경우나, 상기 디스크립션 프로바이더 디바이스가 요청받은 상기 메타데이터 색션의 상기 디스크립션 프로바이더 디바이스에 있는 버전 값이 상기 접근 메타데이터 요청 메시지에서 명시된 값보다 더 큰 경우에 상기 메타데이터 색션의 내용을 포함하는, 요청 디바이스의 메타데이터 검색 방법.
  10. 제1항에 있어서,
    상기 메타데이터 색션은 상기 메타데이터 색션을 나누는 계층 수준에 따른 한 개 이상의 식별자에 의해 식별되는, 요청 디바이스의 메타데이터 검색 방법.
  11. 제1항에 있어서,
    상기 메타데이터 색션의 내용에 기반하여 메타데이터를 검색하는 동작은,
    상기 접근 메타데이터 응답 메시지의 매타데이터 색션 요소에 포함된 상기 메타데이터를 검색하거나, 상기 접근 메타데이터 응답 메시지의 메타데이터 URL 요소에 의해 명시된 위치로부터 상기 메타데이터를 검색하는, 요청 디바이스의 메타데이터 검색 방법.
  12. 요청 디바이스로부터 상기 요청 디바이스가 접근하고자 하는 메타데이터 색션에 대한 정보를 나타내는 접근 메타데이터 요청 메시지를 수신하는 동작;
    상기 메타데이터 색션을 포함하는 접근 메타데이터 응답 메시지를 생성하는 동작; 및
    상기 접근 메타데이터 응답 메시지를 상기 요청 디바이스로 전송하는 동작
    를 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  13. 제12항에 있어서,
    상기 접근 메타데이터 요청 메시지의 서명을 확인하는 동작
    를 더 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  14. 제12항에 있어서,
    상기 요청 디바이스로부터 알림 메시지를 수신하는 동작
    를 더 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  15. 제12항에 있어서,
    상기 요청 디바이스로부터 메타데이터에 접근하기 위한 메타데이터 스킴 요청 메시지를 수신하는 동작;
    상기 메타데이터의 스킴의 접근이 가능한지 여부를 나타내는 메타데이터 스킴 응답 메시지를 생성하는 동작; 및
    상기 메타데이터 스킴 응답 메시지를 상기 요청 디바이스로 전송하는 동작
    를 더 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  16. 제15항에 있어서,
    상기 메타데이터의 스킴의 접근이 가능한 경우, 상기 메타데이터 스킴 응답 메시지는 상기 요청 디바이스 및 상기 디스크립션 프로바이더 디바이스의 특성들 간의 최적의 매치에 기반하여 상기 디스크립션 프로바이더 디바이스가 선택한 메타데이터 스킴을 나타내는 채택된 스킴 요소를 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  17. 제15항에 있어서,
    상기 메타데이터의 스킴의 접근이 가능하지 않은 경우, 상기 메타데이터 스킴 응답 메시지는 실패의 원인을 나타내는 스킴 결과 요소를 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  18. 제12항에 있어서,
    상기 메타데이터 응답 메시지는 상기 메타데이터 요청 메시지가 상기 메타데이터 색선의 버전 값을 명시하지 않은 경우나, 상기 디스크립션 프로바이더 디바이스가 요청받은 상기 메타데이터 색션의 상기 디스크립션 프로바이더 디바이스에 있는 버전 값이 상기 접근 메타데이터 요청 메시지에서 명시된 값보다 더 큰 경우에 상기 메타데이터 색션의 내용을 포함하는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  19. 제10항에 있어서,
    상기 메타데이터 색션은 상기 메타데이터 색션을 나누는 계층 수준에 따른 한 개 이상의 식별자에 의해 식별되는, 디스크립션 프로바이더 디바이스의 메타데이터 제공 방법.
  20. 접근하고자 하는 메타데이터 색션에 대한 정보를 나타내는 접근 메타데이터 요청 메시지를 생성하고, 상기 메타데이터 색션의 내용에 기반하여 메타데이터를 검색하는 제어부; 및
    상기 접근 메타데이터 요청 메시지를 디스크립션 프로바이더 디바이스에게 전송하고, 상기 디스크립션 프로바이더 디바이스로부터 상기 메타데이터 색션의 내용을 포함하는 접근 메타데이터 응답 메시지를 수신하는 인터페이스부
    를 포함하는, 요청 디바이스.
PCT/KR2011/002591 2010-04-12 2011-04-12 디스커버리 메타데이터 접근을 위한 방법 및 장치 Ceased WO2011129599A2 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/641,059 US20130198790A1 (en) 2010-04-12 2011-04-12 Method and apparatus for accessing service discovery metadata
CN2011800187351A CN102845073A (zh) 2010-04-12 2011-04-12 用于存取发现元数据的方法及装置

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US32294310P 2010-04-12 2010-04-12
US32294510P 2010-04-12 2010-04-12
US61/322,945 2010-04-12
US61/322,943 2010-04-12
US32343610P 2010-04-13 2010-04-13
US61/323,436 2010-04-13
KR1020110024750A KR101199703B1 (ko) 2010-04-12 2011-03-21 디스커버리 메타데이터 접근을 위한 방법 및 장치
KR10-2011-0024750 2011-03-21

Publications (2)

Publication Number Publication Date
WO2011129599A2 true WO2011129599A2 (ko) 2011-10-20
WO2011129599A3 WO2011129599A3 (ko) 2012-01-26

Family

ID=44799165

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2011/002591 Ceased WO2011129599A2 (ko) 2010-04-12 2011-04-12 디스커버리 메타데이터 접근을 위한 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2011129599A2 (ko)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100864839B1 (ko) * 2007-09-10 2008-10-23 한국전자통신연구원 ＲＳＳ로부터 수집한 ＴＶ－Ａｎｙｔｉｍｅ 메타데이터기반 뉴스 패키지 서비스
KR101531166B1 (ko) * 2007-11-27 2015-06-25 삼성전자주식회사 Ｓｉｐ 프로토콜을 이용한 ｉｐｔｖ 서비스 제공자 및 ｉｐｔｖ 서비스 검색 방법 및 장치
EP2242266A4 (en) * 2008-02-05 2014-04-02 Samsung Electronics Co Ltd A method and device for sending and receiving metadata for an application providing an iptv service

Also Published As

Publication number Publication date
WO2011129599A3 (ko) 2012-01-26

Similar Documents

Publication Publication Date Title
WO2011108893A2 (en) Method and apparatus for generating and reproducing adaptive stream based on file format, and recording medium thereof
WO2012099400A2 (en) Apparatus and method for storing and playing content in a multimedia streaming system
WO2012002776A2 (en) Apparatus and method for controlling access to multiple services
WO2011071309A2 (en) Method and apparatus for sharing comments regarding content
WO2009096686A2 (ko) 컨텐츠 공유 서비스 제공 방법 및 그 장치
WO2011108908A2 (en) Method and apparatus for transmitting and receiving a content file including multiple streams
WO2012047064A2 (ko) Ｄｒｍ 서비스 제공 방법 및 장치
WO2013165083A1 (ko) 이미지에 기반하여 동영상 서비스를 제공하는 시스템 및 방법
WO2012060669A1 (ko) Sms를 통해 원격 디바이스를 제어하는 방법 및 이를 위한 장치
WO2010082782A2 (en) Rich media-enabled service guide provision method and system for broadcast service
WO2010147362A2 (en) Widget activation and communication method
WO2012047074A2 (en) Methods and apparatus for obtaining a service
WO2011159093A2 (en) Hybrid delivery mechanism in a multimedia transmission system
EP2279571A2 (en) Method and apparatus for sending and receiving broadcast service in a digital broadcasting system
WO2013024966A1 (ko) 콘텐트 수신 방법 및 장치
WO2015160221A1 (en) Method and apparatus for providing information related to content supporting broadcast service
WO2010143855A2 (ko) 원격 사용자 인터페이스 제공 방법 및 그 장치
EP2344951A2 (en) Conditional processing method and apparatus
EP2301174A2 (en) Method and apparatus for providing rich media service
WO2010008196A2 (ko) 구조화된 정보의 장면 표시 장치 및 그 방법
WO2009154390A2 (en) Method for providing channel service and computer-readable medium having thereon program performing function embodying the same
WO2011129623A2 (ko) 방송 네트워크로 위젯 스트리밍 서비스를 제공하는 방법 및 이를 위한 장치
WO2011129599A2 (ko) 디스커버리 메타데이터 접근을 위한 방법 및 장치
WO2010062096A2 (en) Method and apparatus for reproducing content by using metadata
WO2010110605A2 (ko) Iptv 수신기 및 그의 컨텐트 다운로드 방법

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180018735.1

Country of ref document: CN

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

Ref document number: 11769065

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13641059

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 11769065

Country of ref document: EP

Kind code of ref document: A2