[go: up one dir, main page]

WO2011071230A1 - Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé - Google Patents

Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé Download PDF

Info

Publication number
WO2011071230A1
WO2011071230A1 PCT/KR2010/005243 KR2010005243W WO2011071230A1 WO 2011071230 A1 WO2011071230 A1 WO 2011071230A1 KR 2010005243 W KR2010005243 W KR 2010005243W WO 2011071230 A1 WO2011071230 A1 WO 2011071230A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual channel
epg
service
metadata
channel map
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/KR2010/005243
Other languages
English (en)
Inventor
Joon Hui Lee
So Young Kim
Hyeon Jae Lee
Kyung Ho Kim
Joo Hwan Sul
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.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
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 LG Electronics Inc filed Critical LG Electronics Inc
Priority to CA2783500A priority Critical patent/CA2783500C/fr
Publication of WO2011071230A1 publication Critical patent/WO2011071230A1/fr
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/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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/65—Arrangements characterised by transmission systems for broadcast
    • H04H20/76—Wired systems
    • H04H20/82—Wired systems using signals not modulated onto a carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68—Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/72—Systems specially adapted for using specific information, e.g. geographical or meteorological information using electronic programme guides [EPG]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5058—Service discovery by the service manager
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Definitions

  • the present invention relates to EPG metadata, and more particularly, to an IPTV and method of processing EPG metadata therein.
  • a content produced by a broadcasting service provider is transmitted via such a radio wave transfer medium as terrestrial, cable, satellite and the like and a viewer is able to view the content via a TV receiver capable of receiving the transfer medium.
  • a viewer can be provided with various contents including real-time broadcasts, CoD (contents on demand), games, news and the like using Internet connected to each home as well as the conventional radio wave media.
  • the contents via internet can be provided via IPTV (internet protocol TV).
  • the related art fails to provide a method for a network device (e.g., an IPTV, etc.) to search and process EPG (electronic program guide) metadata quickly and efficiently.
  • a network device e.g., an IPTV, etc.
  • EPG electronic program guide
  • the present invention is directed to a method of processing EPG metadata in a network device and the network device for controlling the same that substantially obviate one or more problems due to limitations and disadvantages of the related art.
  • An object of the present invention is to provide protocol, by which a network device (e.g., an IPTV, etc.) is enabled to process an EPG service related to contents of a real-time TV service (or a linear TV service) or a COD (contents on demand) service more quickly.
  • a network device e.g., an IPTV, etc.
  • an EPG service related to contents of a real-time TV service (or a linear TV service) or a COD (contents on demand) service more quickly.
  • Another object of the present invention is to provide method of processing EPG metadata, by which EPG metadata of various types ongoing to rise can be more efficiently processed.
  • a method of processing EPG metadata in a network includes the steps of performing a services discovery procedure utilizing multiple service discovery metadata components supplied by a service provider and processing an EPG metadata.
  • the performing step includes the steps of receiving a master SI table which locates in a master SI table location in provisioning information, wherein the provisioning information includes multiple elements, an EPG provider information element in the multiple elements having both a first target virtual channel map identifier element and an EPG data locator element, the first target virtual channel map identifier element indicating that services are covered by each of the EPG metadata provider’s EPG data sources, receiving a virtual channel map table which locates in virtual channel map locations in the received master SI table, receiving a virtual channel description table which locates in virtual channel description table locations in the received virtual channel map table, and receiving a source table which locates in source table locations in the received virtual channel description table.
  • the provisioning information includes multiple elements, an EPG provider information element in the multiple elements having both a first target virtual channel map identifier element and an EPG data locator element, the first target virtual channel map identifier element indicating that services are covered by each of the EPG metadata provider’s EPG data sources, receiving a virtual channel map table which locates in virtual channel
  • the present invention provides the following effects and/or advantages.
  • a network device e.g., an IPTV, etc.
  • an IPTV e.g., an IPTV, etc.
  • an EPG service related to contents of a real-time TV service (or a linear TV service) or a COD (contents on demand) service more quickly.
  • a real-time TV service or a linear TV service
  • COD contents on demand
  • EPG metadata of various types ongoing to rise can be more efficiently processed.
  • FIG. 1 is a diagram for an IPTV service according to one embodiment of the present invention.
  • FIG. 2 is a diagram for a multicast method according to one embodiment of the present invention.
  • FIG. 3 is a diagram for a unicast method according to one embodiment of the present invention.
  • FIG. 4 is a diagram of a process for searching an IPTV service according to one embodiment of the present invention.
  • FIG. 5 is a detailed diagram of FIG. 4;
  • FIG. 6 is a diagram of a process for a network device to perform a service discovery operation according to one embodiment of the present invention
  • FIG. 7 is a diagram of a process for a network device to perform a service discovery operation according to another embodiment of the present invention.
  • FIG. 8 is a diagram of a process for a network device to process a COD service according to a further embodiment of the present invention.
  • FIG. 9 and FIG. 10 are diagrams for a data structure of program information according to one embodiment of the present invention, respectively;
  • FIG. 11 and FIG. 12 are diagrams for a data structure of basic content description according to one embodiment of the present invention, respectively;
  • FIGs. 13 to 15 are diagrams for a data structure of provisioning information according to one embodiment of the present invention.
  • FIG. 16 is a diagram for a data structure of virtual channel description according to one embodiment of the present invention.
  • FIGs. 17 to 19 are diagrams for a data structure of EPG provider information according to one embodiment of the present invention, respectively;
  • FIG. 20 and FIG. 21 are diagrams for a data structure of an EPG data locator according to one embodiment of the present invention, respectively;
  • FIG. 22 is a diagram for a data structure of a delivery layer according to one embodiment of the present invention.
  • FIG. 23 and FIG. 24 are diagrams for a data structure of EPG provider information according to another embodiment of the present invention, respectively;
  • FIG. 25 and FIG. 26 are diagrams for a data structure of an EPG data locator according to another embodiment of the present invention, respectively;
  • FIG. 27 is a detailed diagram of the steps S808 and S809 in FIG. 8;
  • FIG. 28 is a diagram for a data structure of a virtual channel map for signaling an EPG service provider per virtual channel map according to one embodiment of the present invention.
  • FIG. 29 and FIG. 30 are diagrams for a data structure of a virtual channel map for signaling an EPG service provider per EPG virtual channel map according to one embodiment of the present invention, respectively;
  • FIG. 31 and FIG. 32 are diagrams for a data structure of an EPG data locator for signaling an EPG service provider per EPG virtual channel map according to one embodiment of the present invention, respectively;
  • FIG. 33 is a table of fragments according to another embodiment of the present invention.
  • FIG. 34 and FIG. 35 are diagram for a data structure of grouping criteria for signaling SGDD grouped per virtual channel map according to one embodiment of the present invention.
  • FIG. 36 is a diagram for a data structure of an SG response according to one embodiment of the present invention.
  • FIG. 37 is a flowchart for a method of processing content metadata for a linear TV service by unicast according to one embodiment of the present invention.
  • FIG. 38 is a flowchart for a method of processing content metadata for a linear TV service by multicast according to one embodiment of the present invention.
  • FIG. 39 is a diagram of a network device according to one embodiment of the present invention.
  • FIG. 40 is a diagram of a network device according to another embodiment of the present invention.
  • IPTV Internet Protocol TeleVision
  • ITF IPTV Terminal Function
  • digital television a mobile device and the like.
  • FIG. 1 is a diagram for an IPTV service according to one embodiment of the present invention.
  • a service address on IP is determined as URL type for example and an ITF makes a request for an IP address and the like to a DNS server and then receives the requested IP address and the like.
  • the ITF accesses a server by multicast or unicast.
  • an ITF makes a server address resolution request (S101).
  • the ITF receives a resolved address of server from a DNS server (S102).
  • the ITF is connected to a server by a unicast (S103) or a multicast (S104).
  • FIG. 2 is a diagram for a multicast method according to one embodiment of the present invention.
  • FIG. 3 is a diagram for a unicast method according to one embodiment of the present invention.
  • 1-to-1 connection is established between an ITF and a server to transceive data in-between.
  • FIG. 4 is a diagram of a process for searching an IPTV service according to one embodiment of the present invention.
  • a service provider performs a service provider discovery (S401).
  • An ITF performs a SP attachment request (S402).
  • the ITF receives provisioning information after SP attachment complete (S403).
  • the ITF receives master SI tables from the service provider (S404), receives virtual channel map tables from the service provider (S405), receives virtual channel description tables from the service provider (S406), and receives source tables from the service provider (S407).
  • the service provider discovery can mean a process for service providers providing services related to IPTV to discover a server that provides information on services provided by the service providers.
  • a method for discovering an address list for obtaining information (e.g., SP discovery information) on an SD (service discovery) server includes one of the three kinds of methods for example.
  • it is able to use an address preset in the ITF or an address manually set by a user.
  • a DHCP based SP discovery method e.g., DHCP option
  • a DNS SRV-based SP discovery method e.g., DNS SRV mechanism.
  • the ITF accesses a server at the address obtained by one of the above three kinds of methods and then receives a service provider discovery record containing information necessary for the per-SP service discovery. Subsequently, the ITF performs a service searching step using the received service provider discovery record. Theses steps are available for one of a push mode and a pull mode.
  • the ITF accesses an SP attachment server designated as an SP attachment locator of the SP discovery record and then performs an ITF registration procedure (or a service attachment procedure).
  • information delivered to the server from the ITF can have a format of an ITF registration input type record.
  • it is able to perform the service attachment procedure using information of a query term type of HTTP GET method.
  • the ITF accesses an authentication service server of SP, which is designated as an SP authentication locator, performs a separate authentication procedure, and is then able to perform a service authentication procedure.
  • an authentication service server of SP which is designated as an SP authentication locator
  • data transmitted to the ITF by the server can have a format of a provisioning information table.
  • the ITF transmits the data to the server in a manner that its ID and location information are contained in the data. Subsequently, the service attachment server is able to specify a service the ITF has subscribed based on the received ID and location information. Moreover, address information, from which the ITF can obtain service information, is provided as a provisioning information table. This address information corresponds to access information of a master SI table. In case of using this method, it is facilitated to provide a subscriber-specific service.
  • the service information includes access information on a virtual channel map, a master SI table record for managing a version, a virtual channel map table for providing a service list of a package type, and a virtual channel description table including detailed information of each channel, a source table including access information for accessing a service actually, and the like.
  • FIG. 5 is a detailed diagram of FIG. 4. Inter-data relations within SI are described with reference to FIG. 5 as follows.
  • a master SI table includes location information for receiving each virtual channel map and version information of each virtual channel map.
  • Each virtual channel map is uniquely identified via a virtual channel map identifier and the virtual channel map version indicates version information of the virtual channel map.
  • a version of the source table is incremented and a version of the virtual channel description table for referring to the source table is changed as well. Therefore, the change of the lower table causes a change of a higher table, whereby the version of the master SI table is eventually changed.
  • a single master SI table can exist per service provider.
  • the service provider designs a plurality of master SI tables to provide a customized service per unit.
  • a customized service fit for a region of a subscriber, subscription information and the like can be efficiently provided via the master SI table.
  • the virtual channel map table can have at last one virtual channel and includes location information for obtaining channel detail information instead of having the channel detail information contained in the virtual channel map.
  • the virtual channel description of the virtual channel map indicates a location of a virtual channel description table containing the channel detail information.
  • the virtual channel description table contains detail information of virtual channel. And, it is able to access the virtual channel description table using the virtual channel location in the virtual channel map table.
  • a method of delivering the virtual channel description table can use one of the following four kinds of methods.
  • a virtual channel description table of all channels provided by the service provider is transmitted.
  • the virtual channel map table needs not to indicate the address of the detail information per virtual channel but an address of the global multicast stream is just included in the provisioning information table.
  • This second method provides channel detail information using a separate multicast stream per region, while the aforesaid first method provides channel detail information using a single stream nationwide.
  • a region to which the ITF belongs can be specified via the service attachment procedure, it is possible to specify an address of a unique multicast stream per region via PROVISIONING information table.
  • a virtual channel service ID of a virtual channel description table is a unique identifier for discriminating a service corresponding to the virtual channel description.
  • it is able to discover a virtual channel description table.
  • a multicast stream is joined and a virtual channel description table corresponding to the same virtual channel service ID is then discovered.
  • a parameter of the virtual channel service ID is transmitted to a server and a specific virtual channel description table is then received only.
  • the source table provides access information (e.g., IP address, port, AV codec, transport protocol, etc.) necessary for accessing a service actually per service.
  • access information e.g., IP address, port, AV codec, transport protocol, etc.
  • the above described master SI table, virtual channel map table, virtual channel description table and source table are delivered via 4 logically separated flows and are available for push mode and pull mode both. Meanwhile, the master SI table monitors can be transmitted by multicast for version management and a version change is monitored by receiving a multicast stream.
  • the above described service provider information includes a service provider ID, a version, an SP logo, an SP name, an SP description, an SP attachment locator, an SP authentication locator and the like for example.
  • the service provider ID uniquely identifies a service provider and is able to use a registered domain name.
  • the version indicates a version of a record of the service provider information.
  • the SP logo specifies a location of a logo image of a service provider and is selectively usable.
  • the SP name indicates a name of a service provider and can have one name per language.
  • the SP description is a detailed text description of a service provider and can be provided per language.
  • the SP attachment locator specifies an address of a service attachment server of a service provider. Meanwhile, a SERVICE attachment procedure necessary for initiating a service of a corresponding service provider is performed via the server.
  • the SP authentication locator specifies an address of a server to access in case of using a selectively usable authentication procedure.
  • FIG. 6 is a diagram of a process for a network device to perform a service discovery operation according to one embodiment of the present invention.
  • a network device e.g., an ITF
  • finds out service provider’s SD server S601.
  • the network device retrieves service provider information table (S602).
  • the network device parses attribute on service provider ID (S603).
  • the network device determines whether wanted service provider is or not (S604).
  • the network device parses attribute on SP name and SP description (S605).
  • the network device parses attribute on SP attachment locator (S606).
  • the network device goes to service attachment step in pull mode (S607).
  • FIG. 7 is a diagram of a process for a network device to perform a service discovery operation according to another embodiment of the present invention. The flow shown in FIG. 7 can be performed after completion of the steps shown in FIG. 6 for example.
  • the network device performs a service provider attachment step in pull mode(S701).
  • the network device sends SP attachment request to SP attachment server(S702).
  • the network device determines whether SP attachment is OK(S703). If no, the network device recognizes that the SP attachment is fail(S704). If yes, the network device retrieves provisioning information table(S705).
  • the network device parses attribute on master SI table locator(S706).
  • the network device retrieves master SI table(S707).
  • the network device parses attribute on virtual channel map location(S708).
  • the network device retrieves virtual channel map table(S709).
  • the network device parses attribute on virtual channel description locator(S710).
  • the network device retrieves virtual channel description table(S711).
  • the network device parses attribute on source locator(S712).
  • the network device retrieves source table(S713).
  • the network device starts service(S714).
  • FIG. 8 is a diagram of a process for a network device to process a COD service according to a further embodiment of the present invention.
  • the network device performs a service provider attachment step in pull mode (S801).
  • the network device sends SP attachment request to SP attachment server (S802).
  • the network device determines whether SP attachment is OK or not (S803). If no, the network device recognizes that the SP attachment fails (S804). If yes, the network device retrieves provisioning information table (S805).
  • the network device retrieves service information (S806).
  • the network device selects one or more COD services from the COD virtual channel services (S807).
  • the network device retrieves COD content catalog from COD catalog server (S808).
  • the network device browses and selects COD content (S809).
  • the network device performs an authorization including purchasing the selected COD content (S810). Yet, the step S808 and the step S809 shall be described in detail later in this disclosure.
  • the network device determines whether the content will be consumed (S811). If no, the network device will consume the content later (S812). If yes, the network device retrieves location of the selected content instance (S813). The network device retrieves content instance (S814). And, the network device consumes the content (S815).
  • FIG. 8 shows an operation of a thick client that receives and processes metadata.
  • the thick client receives service information and then processes SI metadata.
  • a use of a COD service is initiated by selecting a COD virtual channel service from the processed metadata.
  • the thick client obtains an address of a COD catalog server to obtain a COD content list and detail information included in the COD service.
  • the thick client accesses the address and then obtains content catalog information.
  • the thick client selects a content to consume via such a process as browsing, navigation, searching and the like using the obtained content catalog information and then acquires consumption authority via an authorization procedure.
  • This authorization procedure includes the steps of purchasing, usage terms, payment, settlement and the like.
  • the thick client After acquisition of the consumption authority, the thick client obtains location information of an instance of a content to consume. Afterwards, the thick client accesses the content instance based on the obtained location information and then consumes the corresponding content.
  • the thin client accesses a COD service main portal page accessible to all COD services specified in a provisioning information table and then uses a corresponding service.
  • selection of a COD service is performed based on the received SI information.
  • a portal page of the corresponding COD service is directly accessed and the corresponding service is then used.
  • browsing includes at least one of navigation and searching or can mean a series of steps of discovering a specific content using the content catalog.
  • the thin client executes browsing of a COD content catalog in a manner that a server and a user equipment exchange HTMS based webpage with each other.
  • the thin client performs browsing by receiving a webpage containing a UI and data.
  • a medium level client stores a small quantity of content metadata in a client using various delivery mechanisms and then performs browsing locally. In case that additional metadata is necessary, it is additionally received from a server.
  • a client receives and stores whole COD content catalog and then performs local browsing.
  • Purchasing proceeds via the authorization procedure. Afterwards, information of the purchased content is stored in user’s profile information. A user is able to consume the corresponding content right after completion of the purchasing or can consume it via another device at another timing point in the future. In a manner of managing purchase list information via user profile, one device at the purchasing point and another device at the consuming point can be separated from each other.
  • a real content instance is discovered via the above described source table.
  • Usages of the metadata browsing method are not just limited to the COD service and are applicable to using metadata of IPTV services, which will be introduced in various ways in the future, as well as a linear TV service.
  • Content metadata delivery mechanism proposed by the present invention includes2-layered content metadata delivery scheme shown in the following.
  • the 2-layer configuration is just exemplary and the configuration design is extensible over 3 layers.
  • base-layer metadata delivery channel and 2-nd layer metadata delivery channel are separately defined.
  • the Base-layer Metadata Delivery Channel means a metadata delivery channel configured with lest information necessary for content selection.
  • Conventional metadata has flexibility in delivering metadata information on all items that can be assumed. As this flexibility is allowed, if the number of contents is considerably incremented, a size of metadata information on a whole list can increase too large to be received and processed by a user equipment.
  • the following scheme for enabling a user equipment to perform browsing is useful in a manner of restricting this flexibility partially for fast content browsing, defining minimum necessary metadata, and then delivering the defined metadata to the user equipment quickly.
  • a size of information is minimized into a level of delivering metadata information of a whole content quickly to a user equipment.
  • a stream or channel for delivering the size-minimized information shall be defined as a base-layer metadata delivery channel. If this scheme is used, it is also advantageous in that such a user equipment, which is incapable of processing vast metadata, as a storage-space-limited user equipment, a function-limited user equipment and the like is able to process the minimized metadata information.
  • the base layer is received by a user equipment in a manner of being carried on a multicast stream or the like and is then used.
  • the base layer can be delivered by unicast or the like.
  • the 2-nd Layer Metadata Delivery Channel means an additional metadata delivery channel that delivers the former metadata carries on the base layer. Since the base layer contains very basic metadata items only, additional metadata may be necessary to help user’s content selection. A channel for carrying the additional metadata is intended to be delivered via separate 2-nd Layer Metadata Delivery Channel.
  • This 2-nd layer metadata can be delivered via one of the following three kinds of schemes.
  • HTTP or SOAP Query scheme there is HTTP or SOAP Query scheme.
  • a request for additional metadata of a content selected via base-layer metadata is made to a server by HTTP or SOAP query and the requested additional metadata can be received.
  • a service provided can be provided with the following diverse flexibility and efficiency in providing metadata.
  • local browsing can be performed in a manner of delivering metadata corresponding to a base layer to a user equipment and enabling the delivered metadata to be stored in the user equipment. If local browsing is performed in a manner of storing content metadata in a user equipment, it is able to reduce server load and network use quantity smaller than those of the scheme performed in a manner of requesting, receiving and processing metadata remaining in a server by a user equipment. And, a processing speed of the user’s request is raised to enable fast service provision.
  • FIG. 9 and FIG. 10 are diagrams for a data structure of program information according to one embodiment of the present invention, respectively.
  • content metadata for a base layer can be limited to include three kinds of elements (e.g., program ID, AV attribute, basic description, etc.) only.
  • Other attributes and subordinate elements can be delivered via an additional layer equal to or greater than 2-nd layer.
  • the program ID is the information for uniquely identifying a program described by program information.
  • the AV attribute defines media attribute information (e.g., codec, size, etc.) of audio/video of program and the like.
  • FIG. 11 and FIG. 12 are diagrams for a data structure of basic content description according to one embodiment of the present invention, respectively.
  • Metadata for a base layer is designed to include the following seven kinds of items only for example. Other elements are not carried on the base layer but can be carried on an additional layer over 2-nd layer.
  • ProgramInfoURL URL for obtaining additional program information
  • RRTParentalGuidance Delivering a rating value according to a parental guidance system regulated by ATSC PSIP standard
  • a base layer is limited to the minimum, it can be used by being limited in the above manner.
  • various embodiments for the definitions of metadata items transmittable per layer can exist.
  • metadata are available in a manner of being profiled into more various types.
  • proposed is a method of configuring and delivering 3-layer (or higher layer: n-layer) metadata instead of the above 2-layer scheme.
  • schematic information on massive contents is quickly provided using a small quantity of metadata for list reception, query and the like. If a user attempts to view detailed information, it is able to provide information on a content of a small size more accurately.
  • the object of the list layer is to provide a list. By providing minimum information per content, it is able to efficiently transmit information on massive contents once.
  • a lite layer EPG is defined.
  • the configuration off information is minimized to enable such a user equipment, which has a limited screen size, limited storage space and limited CPU processing capability, as a mobile phone to process the corresponding information sufficiently, this configuration is set suitable for a level necessary to select a content.
  • This layer has information more than that of the above described list layer but is abbreviated smaller than a full layer EPG in the following.
  • the fill layer EPG is the most detailed step of using every metadata element defined in EPG metadata without no restriction.
  • the rest of two steps can be configured according to the restrictions as follows.
  • the content metadata for list can be limitedly usable in a manner of using the following attributes and subordinate elements only.
  • ProgramID This identifier uniquely identifies a program (content) described by this program information.
  • the Basic Content Description provides basic informations on a program (content), a group including a set of the programs or a SuperGroup including a set of the groups. And, metadata for list is set to include the following items only among the basic informations. This restriction is applicable to all of the Program, Group, and SuperGroup.
  • RRTParentalGuidance Delivering a rating value according to a parental guidance system regulated by ATSC PSIP standard
  • the content metadata for lit can be limitedly usable in a manner of using the following attributes and subordinate elements only.
  • ProgramID This identifier uniquely identifies a program (content) described by this program information.
  • AVAttribute This describes media attribute information of Audio/Video and the like of program (e.g., Codec, Size, etc.).
  • ProgramInfoURL URL for obtaining additional program information
  • RRTParentalGuidance Delivering a rating value according to a parental guidance system regulated by ATSC PSIP standard
  • Synopsis This is description of text type. In lite EPG, a length attribute value is limited to “short” and90 English letters. This limitation length is just exemplary or can be set to another value to use.
  • CreditList This is information on a credited person of program and should include maximum 5 roles (major cast, production, screenplay, etc.) and maximum 3 names per role in direct. Since a separate table for names may not be provided by the lite EPG in consideration of size, it may be appropriate that names of characters essential to describe the work or picture are directly described only.
  • the lite EPG is limited to the minimum, the above limitation is available.
  • Various embodiments of more or less definitions of the transmittable metadata items can be provided.
  • one information configuration can be delivered in a manner of configuring a whole delivery layer into 3 steps.
  • the information configuration can be delivered in a manner of being divided into 2 steps by selecting 2-step information configuration from the 3 steps.
  • the former 2-layerr configuration can be regarded as one example for the configuration of Lite EPG and Full EPG.
  • the XML schema for the EPG Lite Profile is derived from the full EPG XML schema by excluding certain elements and attributes, imposing certain size restrictions on some of the remaining elements and attributes, eliminating certain Classification Schemes, and limiting the terms that can be used in some of the remaining Classification Schemes, as specified below.
  • EPGMainType None of its immediate child elements or attributes shall be excluded.
  • ProgramDescriptionType The following child elements shall be excluded.
  • the child elements are CreditsInformationTable element, ProgramReviewTable element.
  • ProgramInformationType The following child elements shall be excluded.
  • the child elements are DerivedFrom element, and AggregateOf element, and PartOfAggregration element.
  • GroupInformationType None of its immediate child elements or attributes shall be excluded.
  • ServiceInformationType The following child elements and attributes shall be excluded.
  • the child elements are Owner element, ServiceURL element, ParentService element, OriginalChannelNumber element, originalServiceProvider attribute, originalServiceLocation attribute, affiliateNetwork attribute.
  • ServiceDescription.length attribute of ServiceInformationType shall be restricted to the value “short”.
  • ScheduleType None of its immediate child elements or attributes shall be excluded.
  • ScheduleEventType The following child elements shall be excluded.
  • the child elements are ProgramURL element, InstanceDescription element, EventInfoURL element, RRTParentalGuidance element, ParentalGuidance element, TrickModeRestrictions element, PublishedDuration element, Live element, Repeat element, FirstShowing element, LastShowing element, and Free element.
  • BroadcastEventType None of its immediate child elements or attributes shall be excluded.
  • OnDemandProgramType The following child elements shall be excluded.
  • the child elements are ProgramURL element, InstanceDescription element, EventInfoURL element, RRTParentalGuidance element, ParentalGuidance element, TrickModeRestrictions element, FirstAvailability element, LastAvailability element, ImmediateViewing element.
  • OnDemandServiceType None of its immediate child elements or attributes shall be excluded.
  • BasicContentDescriptionType The following child elements shall be excluded. The child elements are Title element, MediaTitle element, PromotionInformation element, ProgramURL element, awardsList element, BoxOffice element, RelatedMaterial element, ProductionDate element, ProductionLocation element, CreationCoordinates element, DepictedCoordinates element, and the Synopsis.length attribute of such BasicDescription elements shall have the value “short”.
  • BasicContentDescriptionType For BasicDescription elements which appear in GroupInformation elements or SuperGroupInformation elements, the following additional child elements of BasicContentDescriptionType shall be excluded.
  • the additional child elements are ProgramInfoURL element, CaptionLanguage element, SignLanguage element, CreditsList element, ReleaseInformation element, Duration element, programFormat element, copyRestrictions element.
  • AVAttributesType The following child elements shall be excluded.
  • the child elements are FileFormat element, System element, Bitrate element.
  • AudioAttributesType The following child elements shall be excluded.
  • the child elements are Coding element, SampleFrequency element, BitsPerSample element.
  • VideoAttributesType The following child elements shall be excluded.
  • the child elements are ActiveFormatDescription element, Coding element, FrameRate element.
  • CreditsItemType The following child elements and attributes shall be excluded.
  • the child elements are PersonName.dateFrom, PersonName.dateTo, PersonName.type, PersonNameIDRef, OrganizationNameIDRef, Character.dataFrom, Character.dataTo, Character.type.
  • ClassificationSchemeTable The following classification schemes are not applicable to the EPG Lite Profile, due to the exclusion of the corresponding elements and attributes from the profile. Therefore, these schemes and any aliases for these schemes shall be excluded from the ClassificationSchemeTable(tva:HowRelatedCS, mpeg7:FileFormatCS, mpeg7:AudioCodingFormatCS, mpeg7:VideoCodingFormatCS, mpeg7:SystemCS)
  • the only fragments included for List profile of EPG metadata should be ProgramInformation, GroupInformation, SuperGroupInformation, ServiceInformation, Schedule, and OnDemandService . (The Schedule fragments clearly apply only to scheduled programs, and the GroupInformation and SuperGroupInformation fragments are primarily intended for CoD programs.) The only elements of those fragments included should be those shown below:
  • ProgramInformation It may contain only the programId attribute, the MemberOf element and the ShortTitle, Keyword, Genre and ParentalGuidance elements of the BasicDescription element.
  • GroupInformation and SuperGroupInformation It may contain only the groupId attribute, the MemberOf element, and the ShortTitle, Keyword and Genre elements of the BasicDescription element.
  • ServiceInformation It may contain only the serviceId attribute, and the Name (short form), Logo, and perhaps ServiceGenre elements.
  • Schedule It may contain only the serviceIDRef attribute and the ScheduleEvent elements, and each ScheduleEvent element in the Schedule should contain only the Program, InstanceMetadataId, PublishedStartTime and PublishedEndTime elements. (The Program element is just a reference to the programId of the program, and the InstanceMetadataId element is just an identifier for the event.)
  • OnDemandService It may contain only the serviceIDRef attribute and the OnDemandPrograms. Each OnDemandProgram should contain only the Program, InstanceMetadataId. StartOfAvailability and EndOfAvailability elements.
  • the List profile can be defined as follows.
  • the XML schema for the EPG List Profile is derived from the full EPG XML schema by imposing the restrictions in the list below. Any EPG XML type definitions not mentioned in this list shall remain unchanged in the EPG List Profile.
  • ProgramDescriptionType The following child elements shall be excluded:(CreditsInformationTable, ProgramReviewTable, PurchaseInformationTable)
  • ProgramInformationType All the attributes and elements except for the following shall be excluded:(programId attribute, BasicDescription.ShortTitle element, BasicDescription.Keyword element, BasicDescription.Genre element, BasicDescription.RRTParentalGuidance element, BasicDescription.ParentalGuidance element, MemberOf element)
  • GroupInformationType All the attributes and elements except for the following shall be excluded:(groupId attribute, BasicDescription.ShortTitle element, BasicDescription.Keyword element, BasicDescription.Genre element, MemberOf element)
  • SupergroupInformationType All the attributes and elements except for the following shall be excluded:(groupId attribute, level attribute, BasicDescription.ShortTitle element, BasicDescription.Keyword element, BasicDescription.Genre element, MemberOf element)
  • ServiceInformationType All the attributes and elements except for the following shall be excluded:(serviceId attribute, Name element, Logo element)
  • the “length” attribute of the “Name” element shall be restricted to the “short” value.
  • ScheduleType All the attributes and elements except for the following shall be excluded:(ScheduleEvent element, serviceIDRef element, ScheduleEventType)
  • OnDemandProgram All the attributes and elements except for the following shall be excluded:(Program element, InstanceMetadataId element, StartOfAvailability element, EndOfAvailability element, Classification Schemes)
  • the following three kinds of delivery schemes are proposed. They are applicable to all kinds of services including Linear TV, COD Service and the like.
  • a list layer is received after multicast transmission. Afterwards, a detailed layer can be received by making a request by unicast. Thus, information on massive contents can be simplified, multicasted and then stored in a receiver. Based on the received information, an EPG is provided to a user. If the user makes a request for detailed information, the detailed information is received by unicast and the received detailed information is then processed.
  • both a list layer and a lite layer are transmitted by multicast, while a full layer is transmitted by unicast or multicast.
  • the list layer is more frequently transmitted with higher priority, while the lite layer is less frequently transmitted with lower priority.
  • all layers can be transmitted by unicast.
  • a quantity of a content such as COD is massive, efficiency of navigation and/or browsing is enhanced in a manner of utilizing layers despite sending all data based on the unicast.
  • FIGs. 13 to 15 are diagrams for a data structure of provisioning information according to one embodiment of the present invention.
  • information transmitted to an ITF by a service attachment server can have a type shown in FIG. 13.
  • it is intended to make a definition by extending the schema shown in FIG. 13.
  • COD service information relevant element is added.
  • the COD service information relevant element is shown in detail in FIG. 14 and FIG. 15.
  • COD Catalog Server Information provides access information of a server that provides a COD catalog corresponding to a set of metadata information of COD contents.
  • TargetServiceProviderID can be optionally added as a subordinate element. Through this, information provided by the corresponding CODCatalogServer can identify a valid ServiceProvide.
  • CODCatalogServer provided via Provisioning Information Table is able to provide content metadata about all COD services provided by the corresponding service provider. If a COD Content Metadata storage space possessed by a user equipment is large enough to accommodate total metadata therein, the user equipment accesses CODCatalogServer provided via Provisioning Information Table and is then able to receive all COD Content Metadataprovided by a service provider.
  • navigation can be performed in a manner of receiving metadata of a COD service a user attempts to navigate only. This can be supported by a scheme of catalog location provision per COD virtual channel.
  • a subordinate element named “NumberOfDeliveryLayer” is added. Through this added element, it is able to flexibly support a scheme of delivery with extension up to n-layer from the 2-layer metadata delivery. If the added element does not exist, since a separate layer or similar information is not delivered to each EPG data locator, it is constructed with a single layer. On the contrary, if a separate layer or similar information is delivered to the EPG data locator, it means that it is constructed with at least one layer. This can be recognized by parsing all of the EPG data locators.
  • attribute named “DeliveryLayer” is added.
  • a value this attribute can have can include the value according to the format described in the following signaling method and is configured to signal a layer of metadata transmitted from the corresponding CODCatalogServerLocation.
  • EPG metadata for a base layer defined according to one embodiment of the present invention is defined as “Light-weight EPG Metadata Profile”, the same effect can be obtained in a manner of specifying this profile information. This can be more useful in case of extension to n-layer. In case that a layer configuration is differentiated per service provider, it is advantageous in that indication of an accurate EPG metadata profile is more effective than indication of a layer in prescribed order.
  • a receiver is able to receive EPG metadata by selecting one of several EPG data locations in consideration of a processing capability of the receiver and a type of EPG data needed by a user currently.
  • ThinClientPortal supports ‘thin client’ corresponding to a scheme of using a service via HTTP browser, it provides a URI of a thin client portal that provides the service.
  • ThinClientPortal URI included in COD service information in Provisioning Information Table can be regarded as a URL of a main page accessible to all COD services of a service provider.
  • CODAppilcationServer specifies an address of a specific application server that performs “COD Application” function.
  • the COD Application Function performs Content Search/Navigation/Selection function and Content Terms/Payment/Settlement function as a server-side function of supporting such a process necessary to use a COD service as browsing, searching, selection, purchase and the like.
  • an SD server or a catalog server performs the same function or a communication with a COD application server is transparently routed to an IPTV client.
  • ITFMaximumCODBandwidth it is able to selectively specify ITFMaximumCODBandwidth to specify a maximum bandwidth of an access link to use in using a COD service.
  • ITFMinimumCODStorageSpace a minimum size of a content storage space of a user equipment, which is necessary to use a COD service of SP is specified. If this value is not specified, it may be indicate that a separate storage space is not necessary for using a COD service.
  • FIG. 16 is a diagram for a data structure of virtual channel description according to one embodiment of the present invention. With reference to FIG. 16 and the like, a method of signaling an address of a COD catalog server by extending a virtual channel description is described as follows.
  • a method of processing a COD (content on demand) service by extending a virtual channel description table is proposed.
  • FIG. 16 by extending VirtualChannelDescriptionType, it is intended to provide COD service relevant information.
  • COD service information relevant element is added.
  • CODCatalogServerInfo provides access information of an access server that provides a COD catalog as a metadata information set of COD contents. It is able to selectively provide TargetServiceProviderID as a subordinate element. Through this, it is able to identify ServiceProviderof which information provided by CODCatalogServer is valid.
  • the CODCatalogServer provided via VirtualChannelDescriptionType is a server that provides information on the specific VirtualChannel Service. Through this, it is able to provide COD metadata through a separate COD CatalogServer per COD VirtualChannel service. Through this, a receiver selectively receives metadata of the subscribed service or the COD service currently accessed to use and is then able to use the received metadata.
  • a receiver is able to select and receive an appropriate EPG metadata location based on its processing capability, a user’s request content and the like.
  • ThinClientPortal provides a URI of Thin Client Portal.
  • TheThinClientPortal URI included in CODServiceInfo on VirtualChannelDescriptionType can be regarded as a URI of a specific service page accessible to a corresponding VirtualChannel Service described by VirtualChannelDescriptionType.
  • CODAppilcationServer specifies an address of a specific application server configured to perform “COD Application” Function.
  • the COD Application Function performs Content Search/Navigation/Selection function and Content Terms/Payment/Settlement function as a server-side function of supporting such a process necessary to use a COD service as browsing, searching, selection, purchase and the like.
  • an SD server or a catalog server performs these functions or a communication with a COD application server is transparently routed to an IPTV client.
  • FIGs. 17 to 19 are diagrams for a data structure of EPG provider information according to one embodiment of the present invention, respectively.
  • a method of signaling an address of a COD catalog server using EPG provider information is describe as follows.
  • COD catalog server address and thin client portal in the COD service information can be delivered using EPG provider information and thin client portal information.
  • COD catalog server address and thin client portal information are omitted from the COD service information included in the provisioning information and are delivered by the method shown in FIG. 17 and the like.
  • EPGProviderID shown in FIG. 17 is an identifier that can uniquely identify a provider that provides an EPG. For this, a registered domain name is usable.
  • Version indicates a version of EPGDiscoveryRecord.
  • EPGProviderName indicates a text name of an PEG provider and can have one name per language.
  • EPGProviderDescription contains detailed text description of an EPG provider and can have one description per language.
  • TargetServiceProviderID describes IDs of IPTV SP supported by the corresponding EPG provider.
  • EPGProviderLogo provides a URI of logo of the EPG provider.
  • an element named “SupportedServiceType” is added. This indicates types of services ncluding EPG metadata and is able to indicate whether a corresponding EPG provider provides EPG metadata for all services or information on a specific service (e.g. Linear TV and/or COD Service). This is enabled by adding the element named TypeOfSupportedService, as shown in FIG. 18 and FIG. 19.
  • a value of the element can be set to ‘ALL’ in case of providing EPG metadata for all kinds of services.
  • the value can be set to a LinearTV value.
  • the value can be set to a COD service value.
  • SupportedServiceType can be set to 0 to infinity, it can signal all types of supportable services.
  • a subordinate element named “NumberOfDeliveryLayer” is added. Through this element, it is able to flexibly support a scheme of delivery with extension up to n-layer from the 2-layer metadata delivery. If the added element does not exist, since a separate layer or similar information is not delivered to each EPG data locator, it is constructed with a single layer. On the contrary, if a separate layer or similar information is delivered to the EPG data locator, it means that it is constructed with at least one layer. This can be recognized by parsing all of the EPG data locators.
  • a receiver is able to identify an EPG provider that provides EPG metadata for a COD service. Based on this, the receiver accesses a necessary EPG provider and is then able to receive EPG metadata. Of course, this is identically applicable to information on a service different from the COD service as well.
  • EPG metadata provided by a corresponding EPG provider is delivered via at least two delivery layers as proposed by one embodiment of the present invention
  • a receiver is able to identify an EPG provider that provides EPG metadata for a COD service. Based on this, the receiver accesses a necessary EPG provider and is then able to receive EPG metadata. Of course, this is identically applicable to information on a service different from the COD service as well.
  • FIG. 20 and FIG. 21 are diagrams for a data structure of an EPG data locator according to one embodiment of the present invention, respectively.
  • FIG. 22 is a diagram for a data structure of a delivery layer according to one embodiment of the present invention.
  • EPG data type and delivery layer provided per EPG data location may be different.
  • EPG data locator as shown in FIG. 20 and FIG. 21.
  • EPG metadata can be delivered by multicast or unicast using FLUTE.
  • signaling is performed via multicast EPG service.
  • signaling is performed via unicast EPG service.
  • information according to one embodiment of the present invention is added as an element or an attribute.
  • the element and the attribute can be used together if necessary.
  • This attribute can have a value of the format shown in FIG. 22 and signals a layer of EPG metadata transmitted from the corresponding EPG data locator.
  • EPG metadata for a base layer defined according to one embodiment of the present invention is defined as “Light-weight EPG Metadata Profile”, the same effect can be obtained by specifying this profile information.
  • indication of an accurate EPG data profile is more effective than indicating an order of a layer.
  • a receiver selects one of several EPG data locations in consideration of its processing capability, a type of EPG data currently needed by a user and the like and is then able to receive EPG metadata.
  • the receiver is able to identify an EPG data location that provides EPG metadata about a COD service. Based on this, the receiver accesses a necessary EPG data location and is then able to receive EPG metadata. Of course, this is identically applicable to information on a service different from the COD service as well.
  • a method of processing an EPG (Electronic Program Guide) metadata in a network device comprises both a step of performing a services discovery procedure utilizing multiple service discovery metadata components supplied by a service provider, and a step of processing an EPG metadata.
  • EPG Electronic Program Guide
  • the performing step can be designed to be handled by a service discovery manager 4109 shown in FIG. 39.
  • the processing step can be designed to be handled by the metadata manager 4110 shown in FIG. 39.
  • the performing step includes four kinds of steps shown in FIG. 5.
  • the performing step comprises a first receiving step of receiving a master SI table which locates in a master SI table location in provisioning information. Furthermore, the provisioning information includes multiple elements.
  • An EPG provider information element in the multiple elements has both a first delivery layer element and an EPG data locator element.
  • the first delivery layer element gives a type of delivery layer that is delivered by at least one of an EPG metadata provider’s EPG data sources.
  • the target virtual channel map ID element included in the EPG provider information is exemplarily shown in FIGs. 23 to 24 in detail.
  • the performing step comprises a second receiving step of receiving a virtual channel map table which locates in virtual channel map locations in the received master SI table, a third receiving step of receiving a virtual channel description table which locates in virtual channel description table locations in the received virtual channel map table, and a fourth receiving step of receiving a source table which locates in source table locations in the received virtual channel description table.
  • the provisioning information is obtained by the network device during a SP (service provider) attachment.
  • the network device may correspond to at least one of an ITF (IPTV Terminal Function) device, a mobile device and a digital television.
  • ITF IPTV Terminal Function
  • the first target virtual channel map identifier element further indicates that services in a virtual channel map are covered by each of the EPG metadata provider’s EPG data sources.
  • the EPG data locator element has a second target virtual channel map identifier element, the second target virtual channel map identifier element indicates that services in a virtual channel map are covered by an EPG data service represented by an EPG data locator.
  • the target virtual channel map ID element included in the EP data locator is exemplarily shown in FIG. 25 and FIG. 26.
  • none of the first target virtual channel map identifier element that appears in the EPG provider information element apply to the EPG data source represented by the EPG data locator element if the second target virtual channel map identifier element appears in the EPG data locator element.
  • a delivery of the EPG metadata performs using a service guide delivery unit (SGDU) containing a collection of fragments that meet a grouping criteria, and a grouping of the fragments in the SGDU conforms to the grouping criteria declared for the SGDU in SGDDs(Service Guide Delivery Descriptors) announcing the SGDU.
  • SGDU service guide delivery unit
  • the grouping criteria is based on at least one of a start time, an end time, a service ID, and genre properties of schedule events.
  • the fragments correspond to at least one of a program information fragment, a schedule fragment, and a review fragment.
  • the target virtual channel map ID can be identified on a level of the EPG provider information or a level of the EPG data locator. Moreover, it is effective to enhance efficiency of data transmission in IPTV environment in which numerous contents are ongoing to increase.
  • a user equipment in a manner of transmitting EPG information by dividing it by VCM unit, a user equipment selectively receives and processes a necessary EPG metadata stream (e.g., channel package per region or genre) only. Since various package configurations exist, when there are many channels redundant per package or many channels separated into one channel additionally, if a separate stream is configured per VCM, it may be inefficient. In case that guide information of at least two VCMs is transmitted in a manner of being bound into a single stream, it can be received selectively and efficiently by the following method.
  • a necessary EPG metadata stream e.g., channel package per region or genre
  • EPG metadata is delivered in a manner of being constructed with fragments according to a type of each information. And, at least one or more fragments are transmitted by being bound together by a unit of SGDU (service guide delivery unit).
  • SGDD service guide delivery descriptor
  • SGDD makes announcement in a manner of including a reference link by binding the SGDUs together, whereby a view of a specific part set in the whole guide information can be provided.
  • a specific broadcasting service provider e.g., CNN, MBC, etc.
  • Guide information per service is configured in a manner of being bound into SGDU. It is then able to announce the SGDU containing the guide information on services belonging to the VCM via the SGDD. In this case, a receiver preferentially looks into the SGDD and is then able to sort out the guide information to receive. The receiver selects the referred-to SGDU from the corresponding SGDD only and is then able to process the selectively received SGDU.
  • Service guide information corresponding to VCM1 is announced via SGDD1.
  • guide information on four services SGDU1, SGDU2, SGDU3 and SGDU4 is included.
  • Guide information of VCM2 is announced via SGDD2.
  • SGDU4 is included in SGDD1 and SGDD2 both, it is transmitted by a pair instead of being redundantly transmitted and a corresponding link is included in each SGDD. Through this, even if a service is included in several VCMs, efficient transmission is possible without redundancy of the guide information.
  • SGDD is configured as a document of XML type and provides access information for receiving SGDU.
  • the SGDU is a table for actually describing EPG metadata and is configured in a manner of being divided into several modules for efficient transmission.
  • a TOI value within a FLUTE session per SGDU is provided to specify.
  • a TOI value should be newly assigned.
  • a TOI value of each corresponding SGDD should be changed correspondingly. Therefore, a receiver monitors the SGDD to facilitate the detection of a presence or non-presence of the change of EPG metadata.
  • FLUTE channel carrying FDT/SGDD/SGDU can be separated for the corresponding transmission.
  • a size of the SGDU carrying EPG metadata fragments is small but a size of FDT/SGDD used for describing it is relatively small, efficiency can be raised in a manner of transmitting the FDT and the SGDD on separate FLUTE channel.
  • a receiver receives every latest guide information and is then able detect a presence or non-presence of update by receiving the FLUTE channel carrying the FDT and the SGDD only. Therefore, a size of data, which should be received and processed by the receiver, can be reduced.
  • FIG. 23 and FIG. 24 are diagrams for a data structure of EPG provider information according to another embodiment of the present invention, respectively.
  • FIG. 25 and FIG. 26 are diagrams for a data structure of an EPG data locator according to another embodiment of the present invention, respectively.
  • a method of signaling an address of a COD catalog server using EPG provider information is described with reference to FIG. 23 and the like as follows.
  • EPG Provider information follows a scheme of including a list of target services providing EPG metadata.
  • the target service list is directly enumerated in form of “TargetServiceID”.
  • the target service list is directly enumerated in form of “TargetServiceID”.
  • it is able to use the corresponding EPG provider.
  • EPG metadata is enabled to be delivered via n-layer.
  • FIG. 27 is a detailed diagram of the steps S808 and S809 in FIG. 8.
  • a process for a network device according to one embodiment of the present invention to receive and process content metadata is described with reference to FIG. 27 as follows.
  • the network device selects one or more COD services from the COD virtual channel services(S2701).
  • the network device gets EPG data locations of selected COD services from CDDC metadata(S2702).
  • the network device determines whether a current delivery layer is multiple layer delivery or not(S2703). If no, the network device retrieves COD content catalog from COD catalog server(S2704).
  • the network device browses COD content metadata(S2705).
  • the network device selects COD content(S2706).
  • the network device determines whether the COD content is purchased(S2707). If yes, the network device performs an authorization(S2708).
  • the network device retrieves COD content catalog from base-layer delivery channel(S2709).
  • the network device browses COD content metadata(S2710).
  • the network device selects COD content(S2711).
  • the network device determines whether more information is needed(S2712). If yes, the network device gets more information of selected content from 2-nd layer(S2713). If no, the network device determines whether the COD content is purchased(S2714).
  • the above described metadata processing method is applicable as a scheme of supporting a COD service to a linear TV service. In case of a real-time broadcast service, additional consideration is needed. According to one embodiment of the present invention, proposed is a method of performing the EPG metadata delivery for the linear TV service efficiently.
  • each IPTV service is signaled in a manner of belonging to a virtual channel map.
  • the virtual channel map is a bundle of a plurality of services and can be considered a concept of package.
  • An IPTV service provider retaining a number of real-time channels can signal the channels in a manner of configuring them into several virtual channel maps instead of a single virtual channel map according to various classification types including a service configuration type, a service area and the like.
  • a signaling mechanism is configured as a hierarchical structure starting with a master SI table. If EPG metadata for the structured services are delivered by utilizing the hierarchical structure, transmission can be more efficiently performed. For this, by utilizing the formerly proposed metadata delivery mechanism, efficient EPG metadata delivery for a linear TV service is shall be achieved as follows.
  • informations on subscriber-viewable channels can be selectively received.
  • metadata data for a subscribed channel map is preferentially received, whereby EPG can be provided more quickly.
  • EPG metadata are separated in the above manner and are then delivered as several streams. Therefore, it is able to reduce a consumed bandwidth. This is attributed to the effect of reducing a total size of the overall delivered metadata in a manner of providing metadata necessary per user.
  • subscriber dispersion policy can be established by a channel map unit in dispersing a subscriber load, it is able to establish a detailed load dispersion policy. Therefore, total investment cost can be reduced as well.
  • This method is to provide EPG metadata by a service unit.
  • this method is to provide metadata of a specific real-time broadcast service if a user attempts to view a broadcast guide of the specific real-time broadcast service.
  • This method is specifically useful in case that a user equipment has difficulty in receiving and storing overall EPG metadata information due to the shortage of a storage space. For example of this method, information on real-time broadcast services, of which guide information was requested by a user, is received from a server and is then displayed to the user.
  • FIG. 28 is a diagram for a data structure of a virtual channel map for signaling an EPG service provider per virtual channel map according to one embodiment of the present invention.
  • FIG. 29 and FIG. 30 are diagrams for a data structure of a virtual channel map for signaling an EPG service provider per EPG virtual channel map according to one embodiment of the present invention, respectively.
  • FIG. 31 and FIG. 32 are diagrams for a data structure of an EPG data locator for signaling an EPG service provider per EPG virtual channel map according to one embodiment of the present invention, respectively.
  • FIG. 28 shows an XML schema diagram of an extended VirtualChannelMap Table according to the first method.
  • the added EPGProviderInfo element has the aforesaid EPGProviderInfo type.
  • the signaled EPGProvider provides EPG about the VirtualChannelMap. If a multicast delivery scheme is supported, it is able to receive the EPG by joining the corresponding stream. If a unicast delivery scheme is supported, it is able to receive EPG metadata about a service belonging to the corresponding virtual channel map based on the delivery scheme described in the following.
  • EPGDataLocator element of EPGDataLocatorType can be included in EPG provider information, which means a case of directly specifying a location capable of receiving EPG data.
  • EPGDataLocator it is able to specify an EPG provider per service channel by adding an element of EPGProviderInfo Type to VirtualChannelDescription Table in the same manner of the above description. In this case, it is able to directly specify EPGDataLocator as well.
  • a use range of the formerly extended “TargetServiceID” is extended.
  • Both Service ID and VirtualChannelMap ID correspond to IIFIDType that is a unique identifier designated as URI. Therefore, it is possible for TargetServiceID to have VirtualChannelMap ID. In this case, it is advantageous in that a new element needs not to be added.
  • a supported target virtual channel map is specified.
  • a schema diagram of extending EPG ProviderInfoType and a corresponding schema are shown in FIG. 29 and FIG. 30.
  • Example for extension of EPGDataLocatorType is shown in FIG. 31 and FIG. 32.
  • UnicastEPGService is directly extended and replaced.
  • new XUnicastEPGService is defined. Through this, extended element and attributes are added.
  • Each of the first and second schemes can be located at EPGProviderInfo Level or EPG Data Locator stage. If they exist at both locations, a value located at the EPG data locator is used by replacing a located value at a higher level to specify a target service.
  • FIG. 33 is a table of fragments according to another embodiment of the present invention.
  • FIG. 34 and FIG. 35 are diagram for a data structure of grouping criteria for signaling SGDD grouped per virtual channel map according to one embodiment of the present invention.
  • EPG metadata are delivered in a manner of being configured by a fragment unit. And, a type of the fragment is shown in FIG. 35.
  • a unit of delivering fragments of the EPG metadata includes SGDU (service guide delivery unit) and the fragments can be delivered in a manner of being bound into a bundle of at least one fragment. Alternatively, it is able to announce the SGDU, which is the transmission unit of the EPG fragments, using SGDD (Service Guide Delivery Descriptor).
  • SGDU service guide delivery unit
  • SGDD Service Guide Delivery Descriptor
  • the EPG fragments announced as SGDU can be regarded as a specific view or partial set of the entire EPG metadata. Classification or characteristics of the specific view can be signaled via a groping criteria element.
  • the grouping criteria can include one of a program time, a program genre and the like.
  • SGDUs including the EPG metadata fragments which describe the EPG metadata corresponding to a virtual channel map matching a value of a virtual channel map ID designated to the VirtualChannelMapCriteria element, are announced by the corresponding SGDD.
  • XML schema of an extended grouping criteria type is shown in FIG. 34 and FIG. 35.
  • a corresponding service ID can be included in previous ServiceCriteria to use.
  • “VirtualChannelCriteria” element is newly added to use for this purpose.
  • the same effect can be obtained in a manner of inserting a value of VirtualChannelMap ID or Service ID in the ServiceCriteria element.
  • FIG. 36 is a diagram for a data structure of an SG response according to one embodiment of the present invention.
  • FIG. 37 is a flowchart for a method of processing content metadata for a linear TV service by unicast according to one embodiment of the present invention. In the following description, a method o receiving EPG metadata corresponding to a virtual channel map or a specific service by unicast is explained with reference to FIG. 36 and FIG. 37.
  • EPG metadata delivery by unicast can be performed based on HTTP protocol for example.
  • HTTP based request/response can match query request/response.
  • a scheme proposed by one embodiment of the present invention is non-limited by the HTTP protocol and can be alternatively available via such a protocol as SOAP and the like.
  • the representation of a query request can be regarded as an HTTP request.
  • HTTP based Unicast EPG Metadata delivery can be represented as a query request/response based on an HTTP post method in the following.
  • the Query request is available via ‘POST’ method of HTTP/1.1.
  • parameters included in the query request are configured with key-value pairs and are delivered according to a convention using HTML form data via the ‘POST’ method. Theses parameters are delivered to a server in a manner of being included in ‘message-body’ region of HTTP/1.1 ‘Request’ message.
  • a plurality of key-value pairs can be included in one query request.
  • each key-value pair is identified using ‘&’.
  • a response made by the server in response to the query request can include at least one “SGResponse” element having the schema shown in FIG. 36.
  • the corresponding query request can be configured according to the following matters.
  • the ‘message-body’ of HTTP/1.1 request message SHALL contain key-value pairs, using ⁇ key> as the key representing the criteria and the ⁇ value> as the value from the domain of the criteria. These key-value pairs SHALL be delimited by a ‘&’. If several key-value pairs are given, they are combined as follows:
  • the expected reply are Service Guide fragments that satisfy all given criteria.
  • key-value pairs having the same key are combined using OR logic, i.e. the expected reply are Service Guide fragments that satisfy at least one of the given criteria.
  • the group of OR-combined keys is in the next step below treated as one entity.
  • Key-value pairs (or groups of pairs having the same key) having different keys are combined using AND logic, i.e. the expected reply are Service Guide fragments that satisfy all given criteria.
  • the response to a terminal request containing key-value pairs specifying the set of fragments the terminal expects to receive SHOULD contain all the fragments matching the given criteria and MAY include in addition fragments that do not match the given criteria. If the terminal request does not contain any key-value pairs having the keys “validFrom” or “validTo”, then the response SHALL contain only fragments that are currently valid.
  • a scheme of evaluation of match or mismatch of the above proposed key-value pair is non-limited by one embodiment.
  • an evaluation scheme of a different type can be supported.
  • requested is the metadata to provide EPG of all services included in a virtual channel map of which ID matches a value of ⁇ value>.
  • requested is the metadata to provide EPG of a virtual channel (service) of which ID matches a value of ⁇ value>.
  • ⁇ value> Start time of information such as schedule, schedule event, broadcast event and the like
  • it means a start time of schedule information of a real-time broadcast of which EPG metadata is requested.
  • the guide information starting with a time designated to ⁇ value> is requested.
  • ⁇ value> End time of information such as schedule, schedule event, broadcast event and the like
  • startTime and endTime are designated, schedule information within the time interval is requested. If one of “startTime” and “endTime” is omitted, one end can be regarded as a limited time interval. And, whether to send data amounting to prescribed days can be determined and sent by a service provider.
  • the above described query mechanism can be utilized in case that a separate unicast EPG data location is not specified by a virtual channel map or service unit.
  • SGDD or SGDU can be received.
  • the SGDU announced within the SGDD shall be received and processed.
  • a grouping criteria of the SGDD can be configured as proposed in the above fragment configuration scheme.
  • FIG. 37 shows an operational flow for receiving and processing content metadata for a linear TV service by unicast according to one embodiment of the present invention.
  • Metadata for a linear TV content is received in a manner of making a request to EPG DataLocation server using the above mentioned HTTP/Query scheme.
  • the flowchart shown in FIG. 37 describes the processing schemes for those cases.
  • a server response to the HTTP/Query request can use SGDD (service guide delivery descriptor) capable of SGDU (service guide delivery unit) or SGDUs by a unit of delivering fragments of EPG metadata.
  • SGDD service guide delivery descriptor
  • SGDU service guide delivery unit
  • SGDUs by a unit of delivering fragments of EPG metadata.
  • SGDUs announced through the response are received and processed and the SGDUs included in the response are also processed. According to this processing, all the fragments of the RPG metadata corresponding to the HTTP/Query result are received.
  • a content guide is configured using the received fragments and are then displayed to a user.
  • the network device selects a virtual channel map or service for requesting guide information(S3701).
  • the network device gets EPG data locations of selected virtual channel map or service from CDDC metadata(S3702).
  • the network device unicast-requests to EPG data location (via HTTP or Query)(S3703).
  • the network device determines whether there are SGDDs in response(S3704). If no(S3704), the network device determines whether there are SGDUs in response(3705). If no(S3705), the network device composes content guide based on retrieved fragments(S3706). The network device presents content guide to user(S3707).
  • the network device retrieves SGDUs which are announced in SGDDs(S3708).
  • the network device processes fragments in retrieved SGDUs(S3709).
  • the network device processes fragments in SGDUs contained in response(S3710).
  • FIG. 38 is a flowchart for a method of processing content metadata for a linear TV service by multicast according to one embodiment of the present invention.
  • EPG metadata corresponding to a virtual channel map or a specific service designated to a corresponding stream are configured and delivered.
  • metadata of one virtual channel map or one service can be included in one multicast stream only.
  • metadata of at least two virtual channel maps or at least two services can be included in one multicast stream.
  • a view of metadata belonging to an SGDD, for which grouping criteria is set per metadata belonging to a specific virtual map or a specific service using the above described EPG metadata fragment configuration can be identified with ease and an SGDU belonging to the view can be selectively received.
  • FIG. 38 shows an operational flow for receiving and processing content metadata for a linear TV by multicast.
  • metadata for a linear TV content is received in a manner of joining a multicast stream designated to an EPG DataLocation using the aforesaid multicast scheme.
  • the flowchart shown in FIG. 38 describes a processing scheme for this case.
  • the joined multicast stream includes metadata corresponding to a specific virtual channel map or service to receive only, it is announced through one SGDD within the stream.
  • an SGDU is obtained using the unique SGDD.
  • a guide picture can be then configured by receiving necessary EPG metadata fragments through the obtained SGDU.
  • the network device selects a virtual channel map or service for requesting guide information(S3801).
  • the network device gets EPG data locations of selected virtual channel map or service from CDDC metadata(S3802).
  • the network device joins multicast stream which is signaled through EPG data location(S3803).
  • the network device determines whether there are several SGDDs in the stream(S3804). If no(S3804), the network device retrieves SGDUs which are announced in SGDDs(S3805). The network device processes fragments in retrieved SGDUs(S3806). The network device composes content guide based on retrieved fragments(S3807). The network device presents content guide to a user(S3808).
  • the network device selects SGDD which belongs to selected Virtual Channel Map or service(S3809).
  • FIG. 39 is a diagram of a network device according to one embodiment of the present invention. In the following description, a network device according to one embodiment of the present invention is described with reference to FIG. 39.
  • a Network Interface(3901) performs receiving/sending IPTV packets.
  • the network interface(3901) may correspond to physical & data link layers.
  • An TCP/IP Manager(3902) is responsible for end to end (source to destination) packet delivery.
  • the TCP/IP manager(3902) classifies each packets into appropriate protocol manager.
  • a Service Delivery Manager(3904) is responsible for handling real-time streaming data and downloading content.
  • the service delivery manager(3904) is also responsible for retrieving contents from Content DB for later consuming.
  • RTP/RTCP Real-Time Transport Protocol/RTP Control Protocol
  • MPEG-2 packets are encapsulated in RTP.
  • the service delivery manager(3904) parses RTP packets and sends the parsed transport packets to DEMUX.
  • the service delivery manager(3904) sends feedback on the network reception quality using RTCP.
  • MPEG-2 transport packets may be carried directly in UDP without RTP.
  • HTTP or FLUTE protocol may be used for delivery protocol.
  • a demultiplexer(3908) performs de-multiplexing audio, video and PSI tables from input transport packets.
  • the demux(3908) controls the de-multiplexing for PSI tables by PSI Decoder.
  • the demux(3908) performs making the sections of PSI tables and sending them to PSI Decoder.
  • the demux(3908) controls the de-multiplexing for A/V transport packets.
  • a PSI & (PSIP and/or DVB-SI) Decoder(3907) may correspond to PSI( and PSIP/DVB-SI ) Control Module.
  • the PSI & (PSIP and/or DVB-SI) Decoder(3907) sets PIDs for PSI tables and PSIP/DVB-SI tables to DEMUX.
  • the PSI & (PSIP and/or DVB-SI) Decoder(3907) performs decoding the private sections of PSI and (PSIP and/or DVB-SI) sent by DEMUX.
  • the decoding result is used to de-multiplex input transport packets. (e.g. set Audio and Video PID to DEMUX.)
  • a Audio and Video Decoder (3912) performs decoding audio and video elementary stream packets.
  • a A/V and OSD Displayer(3915) receives audio and video data from A/V Decoder.
  • the A/V and OSD Displayer(3915) controls video and audio data and displays them on the Screen and speaker.
  • the A/V and OSD Displayer(3915) controls OSD (On Screen Display) Graphic data.
  • a Native Application manager and UI (User Interface) Manager(3913) performs supporting the Graphic User Interface on TV Screen, receiving user key by remote control or front panel, and managing the states of the whole TV system.
  • a Service Manager(3914) controls all the other managers related to the services like Service control manager, Service delivery manager, IG-OITF client , Service Discovery manager, and Metadata manager.
  • the service manager(3914) is responsible for serving IPTV services.
  • a SI & Metadata DB(3911) is a database for Service Discovery information and Metadata related to the services.
  • a SD(Service Discovery) Manager(3909) performs enabling of the discovery of IPTV services over bi-directional IP network.
  • the SD manager(3909) provides all the information for selecting service.
  • a Service Control Manager(3903) is responsible for selecting and controlling services and managing sessions.
  • the service control manager(3903) selects live broadcasting service, using IGMP or RTSP protocol.
  • the service control manager(3903) selects VOD contents, using RTSP protocol. If using IMS, SIP protocol is used for initiating and managing sessions through IMS Gateway.
  • RTSP protocol can be used in controlling of the delivery of broadcast TV and audio as well as for on-demand delivery.
  • RTSP protocol uses a persistent TCP connection and allows trick mode control on real-time media streaming.
  • a Content DB(3906) is a database for Contents which may be delivered by content download system or may be recorded from live media TV.
  • a PVR manager(3905) is responsible for recording and playing live streaming contents.
  • the PVR manager(3905) performs gathering all the necessary metadata of the recorded content and generating additional information for better user experience (e.g. thumbnail image, index etc).
  • a metadata manager(3910) controls metadata on EPG.
  • FIG. 40 is a diagram of a network device according to another embodiment of the present invention. In the following description, a network device according to another e embodiment of the present invention is described with reference to FIG. 40.
  • FIG. 40 is a functional block diagram of each module of a network device (e.g., IPTV terminal function: ITF).
  • a bold arrow indicates a data path
  • a doted arrow indicates a control signal path.
  • a Cable modem, DSL modem and etc. 4001 reconstruct a digital signal by demodulating a signal transmitted via an interface and physical medium via which an ITF is connected to an IP network on a physical level.
  • An Ethernet NIC 4002 is a module configured to reconstruct IP data from the signal received via the physical interface.
  • An IP Network Stack 4007 is a processing module of each layer according to an IP protocol stack.
  • An XML Parser 4009 is a module configured to parse XML document in the received IP data.
  • a File Handler 4008 is a module configured to process data transmitted as a file in the received IP data.
  • An SI Handler 4011 is a module configured to process a portion corresponding to IPTV SI data in the received file type data and enable the processed portion to be stored in a storage.
  • An EPG Handler 4010 is a module configured to process a portion corresponding to the file type IPTV EPG data and enable the processed portion to be stored in the storage.
  • a Storage 4012 is a storage space configured to store such data necessary to be stored as SI, EPG and the like.
  • An SI Decoder 4013 is a module configured to reconstruct necessary data. In case that channel map information is necessary, the SI decoder 4013 brings the SI data from the storage, analyzes the SI data, and then reconstructs necessary information.
  • An EPG Decoder 4014 is a module configured to reconstruct necessary data. In case that EPG information is necessary, the EPG decoder 4014 brings the EPG data from the storage, analyzes the EPG data, and then reconstructs necessary information.
  • An ITF Operation Controller 4015 is a main controller configured to control such an operation of ITF as a channel switching, an EPG display and the like.
  • a Channel Service Manager 4016 is a module configured to manage a channel switching operation by receiving an input from a user.
  • An Application Manager 4017 is a module configured to manage such an application service as an EPG display and the like by receiving an input from a user.
  • An MPEG-2 Demultiplexer 4003 is a module configured to extract MPEG-2 transport stream data from the received IP datagram and deliver the extracted data to a corresponding module according to each PID.
  • An MPEG-2 PSI/PSIP Parser 4004 is a module configured to extract and parse PSI/PSIP data containing such information for accessing a program element as PID information of each data (e.g., A/V data, etc.) of the MPEG-2 transport stream within the received IP datagram.
  • An A/V Decoder 4005 is a module configured to decode the delivered A/V data and deliver the decoded data to the display module 4006.
  • a method according to the present invention is recordable in a computer readable medium in a manner of being implemented into a program command type executable through various computer means.
  • the computer readable medium can include a program command, a data file, a data structure or combinations thereof.
  • the program command recorded in the medium is specially designed and configured for the present invention or can be known in public to those skilled in the field of software.
  • the computer readable recording medium includes a magnetic medium such as a hard disk, a floppy disk and a magnetic tape, an optical medium such as a CD-ROM and a DVD, a magneto-optical medium such as a floptical disk, or such a hardware device specially configured to store and execute a program command as a ROM, a RAM, a flash memory and the like.
  • the program command includes a machine code created by compiler or a high-level language code executable by a computer using an interpreter and the like.
  • the hardware device can be configured to operate as at least one software module to perform an operation of the present invention, and vice versa.
  • the present invention is applicable to a digital broadcasting system entirely or in part.

Landscapes

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

Abstract

Selon un mode de réalisation de la présente invention, un procédé de traitement de métadonnées de guide électronique de programmes (EPG) dans un réseau consiste à réaliser une procédure de découverte de services utilisant de multiples composantes de métadonnées de découverte de services fournies par un fournisseur de services et à traiter des métadonnées EPG. De préférence, l'étape de réalisation consiste à recevoir une table SI maître qui se trouve à un emplacement de table SI maître dans des informations de provisionnement, les informations de provisionnement comprenant de multiples éléments, un élément d'informations de fournisseur EPG dans les multiples éléments comprenant à la fois un premier élément identificateur de carte de canaux virtuels cible et un élément localisateur de données EPG, le premier élément identificateur de carte de canaux virtuels cible indiquant que des services sont couverts par chacune des sources de données EPG du fournisseur de métadonnées EPG, recevoir une table de carte de canaux virtuels qui se trouve à des emplacements de carte de canaux virtuels dans la table SI maître reçue, recevoir une table de description de canaux virtuels qui se trouve à des emplacements de table de description de canaux virtuels dans la table de carte de canaux virtuels reçue, et recevoir une table de sources qui se trouve à des emplacements de table de sources dans la table de description de canaux virtuels reçue.
PCT/KR2010/005243 2009-12-07 2010-08-10 Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé Ceased WO2011071230A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA2783500A CA2783500C (fr) 2009-12-07 2010-08-10 Procede de traitement de metadonnees epg dans un dispositif de reseau et dispositif de reseau pour mettre en oeuvre ce procede

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US26743109P 2009-12-07 2009-12-07
US61/267,431 2009-12-07

Publications (1)

Publication Number Publication Date
WO2011071230A1 true WO2011071230A1 (fr) 2011-06-16

Family

ID=44083313

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2010/005243 Ceased WO2011071230A1 (fr) 2009-12-07 2010-08-10 Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé

Country Status (3)

Country Link
US (1) US9693093B2 (fr)
CA (1) CA2783500C (fr)
WO (1) WO2011071230A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011034283A1 (fr) 2009-09-20 2011-03-24 Lg Electronics Inc. Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour commander ce traitement
EP2590425A1 (fr) * 2011-11-03 2013-05-08 Samsung Electronics Co., Ltd. Appareil destiné à recevoir un flux de radiodiffusion incluant un service en ligne dans une liste de canaux et procédé associé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080048763A (ko) * 2006-11-29 2008-06-03 삼성전자주식회사 Ｉｐ 네트워크에서 정보를 송수신하는 방법 및 장치
KR20080063714A (ko) * 2007-01-02 2008-07-07 주식회사 셀런 Ｉｐｔｖ환경에서 전자프로그램가이드 서비스 제공방법
JP2009059160A (ja) * 2007-08-31 2009-03-19 Sony Corp サーバ装置、ネットワークシステム、コンテンツ発見通知方法、及びコンピュータ・プログラム

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7865832B2 (en) * 1999-07-26 2011-01-04 Sony Corporation Extended elements and mechanisms for displaying a rich graphical user interface in panel subunit
WO2000042724A1 (fr) * 1999-01-12 2000-07-20 Sony Corporation Systeme de distribution d'informations
US7814512B2 (en) * 2002-09-27 2010-10-12 Microsoft Corporation Dynamic adjustment of EPG level of detail based on user behavior
US6947935B1 (en) * 2001-04-04 2005-09-20 Microsoft Corporation Training, inference and user interface for guiding the caching of media content on local stores
WO2004075543A1 (fr) * 2003-02-24 2004-09-02 Sony Corporation Systeme, dispositif et procede de traitement de donnees, support d'enregistrement et programme
JP4193629B2 (ja) * 2003-07-25 2008-12-10 ソニー株式会社 画面表示装置，プログラム，および画面表示方法
US8316132B2 (en) * 2005-09-08 2012-11-20 Nokia Corporation Method to determine the completeness of a service guide
US8484689B2 (en) * 2007-12-05 2013-07-09 Lg Electronics Inc. IPTV receiver and method of discovering an IPTV service
US8893205B2 (en) * 2007-12-05 2014-11-18 Lg Electronics Inc. IPTV receiver and method of providing channel map management information
US8813155B2 (en) * 2007-12-05 2014-08-19 Lg Electronics Inc. Method for receiving service information data and an IPTV receiver
US8397256B2 (en) * 2007-12-05 2013-03-12 Lg Electronics Inc. IPTV receiver and method of providing channel map information
US8635641B2 (en) * 2007-12-05 2014-01-21 Lg Electronics Inc. Method of performing parental control a channel and an IPTV receiver
US8112775B2 (en) * 2007-12-05 2012-02-07 Lg Electronics Inc. IPTV receiver and method of providing channel details information
US8869219B2 (en) * 2007-12-05 2014-10-21 Lg Electronics Inc. Method for controlling a channel and an IPTV receiver
US8893200B2 (en) * 2007-12-05 2014-11-18 Lg Electronics Inc. IPTV receiver and method of acquiring a resource for an IPTV service
US20090187960A1 (en) * 2008-01-17 2009-07-23 Joon Hui Lee IPTV receiving system and data processing method
KR101580516B1 (ko) * 2008-04-07 2015-12-28 엘지전자 주식회사 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2011002147A1 (fr) * 2009-06-12 2011-01-06 Lg Electronics Inc. Procédé de traitement de données sur epg dans un prestataire de service connecté au réseau et récepteur de diffusion numérique de traitement de données sur epg
US8438600B2 (en) * 2009-08-20 2013-05-07 Lg Electronics Inc. Method of processing EPG metadata in network device and network device for controlling the same
WO2011034283A1 (fr) * 2009-09-20 2011-03-24 Lg Electronics Inc. Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour commander ce traitement
WO2011065654A1 (fr) * 2009-11-25 2011-06-03 Lg Electronics Inc. Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé
WO2011096625A1 (fr) * 2010-02-08 2011-08-11 Lg Electronics Inc. Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé
KR20130080777A (ko) * 2010-04-16 2013-07-15 엘지전자 주식회사 Iptv 상품에 대한 구매 트랜잭션 방법 및 그를 이용한 iptv 수신기

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080048763A (ko) * 2006-11-29 2008-06-03 삼성전자주식회사 Ｉｐ 네트워크에서 정보를 송수신하는 방법 및 장치
KR20080063714A (ko) * 2007-01-02 2008-07-07 주식회사 셀런 Ｉｐｔｖ환경에서 전자프로그램가이드 서비스 제공방법
JP2009059160A (ja) * 2007-08-31 2009-03-19 Sony Corp サーバ装置、ネットワークシステム、コンテンツ発見通知方法、及びコンピュータ・プログラム

Also Published As

Publication number Publication date
CA2783500A1 (fr) 2011-06-16
US9693093B2 (en) 2017-06-27
CA2783500C (fr) 2015-05-05
US20110138421A1 (en) 2011-06-09

Similar Documents

Publication Publication Date Title
WO2011034283A1 (fr) Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour commander ce traitement
WO2011065654A1 (fr) Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour mettre en œuvre ce procédé
WO2011129641A2 (fr) Procédé de transaction d'achat pour produit iptv et son récepteur iptv
WO2010021525A2 (fr) Procédé de traitement d'un service web dans un service en temps non réel et un récepteur de diffusion
WO2014003394A1 (fr) Appareil et procédé de traitement d'un service interactif
WO2014025207A1 (fr) Procédé et appareil pour traiter un signal de diffusion contenant un service de radiodiffusion interactive
WO2011049278A1 (fr) Procédé pour traiter des informations de programme de diffusion et récepteur de diffusion
WO2012091371A1 (fr) Procédés d'émission et de réception de service de diffusion et appareil de réception du service de diffusion
WO2014030924A1 (fr) Appareil et procédé de traitement d'un service interactif
WO2010082783A2 (fr) Procédé de traitement de service en temps non réel et récepteur de diffusion
WO2009151267A2 (fr) Procédé de prestation de service et récepteur de diffusion
WO2014129803A1 (fr) Appareil d'affichage vidéo et son procédé de fonctionnement
WO2011021867A2 (fr) Procédé de traitement de métadonnées epg dans un dispositif de réseau et dispositif de réseau pour commander ce traitement
WO2010068033A2 (fr) Procédé de traitement de service en temps différé et récepteur de diffusion
WO2011122838A2 (fr) Procédé de traitement de service sans contrainte temps réel et récepteur de diffusion
WO2020162712A1 (fr) Dispositif et procédé d'émission de signal de diffusion et dispositif et procédé de réception de signal de diffusion
WO2014171718A1 (fr) Dispositif de transmission par diffusion, dispositif de réception par diffusion, procédé fonctionnel pour dispositif de transmission par diffusion et procédé fonctionnel pour dispositif de réception par diffusion
WO2009151266A2 (fr) Procédé de prestation de service et récepteur de diffusion mobile
WO2010068040A2 (fr) Procédé de traitement de services en temps non réel et récepteur de radiodiffusion
WO2018169101A1 (fr) Dispositif de réception de signaux de diffusion, et procédé de réception de signaux de diffusion
WO2016171496A1 (fr) Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2011002147A1 (fr) Procédé de traitement de données sur epg dans un prestataire de service connecté au réseau et récepteur de diffusion numérique de traitement de données sur epg
WO2016163772A2 (fr) Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, procédé d'émission de signal de diffusion, et procédé de réception de signal de diffusion
WO2011132879A2 (fr) Procédé pour l'émission/réception d'un contenu sur internet et émetteur/récepteur l'utilisant
WO2016171518A2 (fr) Émetteur de signal de radiodiffusion, récepteur de signal de radiodiffusion, procédé d'émission d'un signal de radiodiffusion et procédé de réception d'un signal de radiodiffusion

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: 10836127

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2783500

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10836127

Country of ref document: EP

Kind code of ref document: A1