KR101485191B1 - A method of performing parental control a channel for building a channel map in an ＩＰＴＶ receiver and apparatus thereof - Google Patents

Abstract

The present invention relates to a method and apparatus for performing parental control for forming a channel map in an IPTV receiver, wherein an example of a method according to the present invention includes a first element defining a location of a virtual channel map table Receiving mast service information; Parsing a first element included in the received master service information table; Receiving the virtual channel map table including a second element that defines a location of a virtual channel description table based on the parsed location element; Parsing the second element in the received virtual channel map table; Receiving, based on the parsed second element, the virtual channel description table including a third element indicating a default pair real-time rating of a virtual channel service; Parsing the third element in the received virtual channel description table; And a rating based on the type of the parental guidance system is set according to the parsed third element. Therefore, according to the present invention, it is possible to restrict the viewing of the virtual channel, not the contents, so that the convenience of the user can be pursued.

IPTV, channel map, service, RRT, viewing restrictions

Description

[0001] The present invention relates to a method and a device for performing a parental control for forming a channel map in an IPTV receiver,

Field of the Invention [0002] The present invention relates to a method and apparatus for performing a viewing restriction to form a channel map in an IPTV receiver, and more particularly, to a method and apparatus capable of performing viewing restriction for each virtual channel.

The broadcasting environment has been separated by the existing terrestrial, cable, and satellite media, but is becoming more and more integrated. In this process, IPTV environment that can provide services based on IP has been established and relevant standards have been made recently. For example, channels are still being used in IPTV environments.

Regarding IPTV environment, various contents and services exist. Therefore, it is necessary to restrict the viewing of each content and services appropriately in the IPTV environment. If not, there is a problem that the user may be inconvenienced.

It is an object of the present invention to provide an IPTV receiver, that is, an IPTV terminal function (ITF), to perform parental control for each virtual channel.

It is another object of the present invention to provide a method and apparatus for restricting viewing of each virtual channel.

It is another object of the present invention to enable the ITF to determine whether to access each virtual channel and provide guide information for the virtual channel.

In order to achieve the above object, an example of a method for performing a viewing restriction in order to form a channel map in an IPTV receiver according to the present invention includes a first element defining a location of a virtual channel map table, Receiving service information (SI); Parsing a first element included in the received master service information table; Receiving the virtual channel map table including a second element that defines a location of a virtual channel description table based on the parsed location element; Parsing the second element in the received virtual channel map table; Receiving the virtual channel description table including a third element indicating a default parental guidance rating of a virtual channel service based on the parsed second element; Parsing the third element in the received virtual channel description table; And a rating based on the type of the parental guidance system is set according to the parsed third element.

In this case, in the method of controlling parental control of the channel, the method may further include receiving program guide metadata for providing descriptive information on the content.

And the third element may include rating information text elements including attribute information of a rating area, dimension elements defining dimensions, and a ball describing a rating.

In addition, the dimension element may include a rating dimension element that identifies a rating dimension and a rating value element that identifies a rating value.

The technical information may include information defining a rating region table (RRT).

In addition, the RRT may include rating information text elements including attribute information of a rating region, dimension elements defining dimensions, and information describing a rating.

And the dimension element may include a rating value element that identifies a rating dimension and a rating value element that identifies a rating value.

Also, the possible value of the third element may be the same as the respective element of the same name as the service fragment of the program guide metadata for the service.

And the third element may be an RRT parental guidance element.

In addition, the master service information (SI) table may further include version information of the virtual channel map table.

An example of an IPTV receiver according to the present invention includes an IP network stack for receiving IP stream data including service information (SI) data and program guide data; A file handler for demultiplexing SI data and program guide data included in the received IP stream; A service information (SI) handler for demultiplexing a virtual channel description table including a master SI table, a virtual channel map table, and a first element indicating that there is a default pair ran- guial rating of a virtual channel service; A program guide handler for demultiplexing a rating region table (RRT) including a second element indicating that a default parental guidance rating of a virtual channel service is present in the demultiplexed program guide data, ; A service information (SI) decoder for parsing the first element from the demultiplexed virtual channel description table; A program guide parser for parsing the first element from the demultiplexed RRT; And a controller for applying and controlling a rating based on the type of the paired landing guidance system according to the parsed first element and the second element.

At this time, the value of the third element may be the same as each element of the same name in the service fragment of the program guide metadata for the service.

The control unit may control to display a service guide screen based on the parsed second element.

In addition, the IPTV receiver may store a demultiplexed mast SI table, a virtual channel map table, a virtual channel description table, and an RRT.

The IPTV receiver may further include a displayed program guide screen and a display unit for displaying a virtual channel service.

Therefore, according to the parental control method and the IPTV receiver according to the present invention, it is possible to restrict the viewing of the virtual channel, not the contents, so that the convenience of the user can be pursued.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. The structure and operation of the present invention shown in the drawings and described by the drawings are described as at least one embodiment, and the technical ideas and the core structure and operation of the present invention are not limited thereby.

Although the terms used in the present invention have been selected in consideration of the functions of the present invention, it is possible to use general terms that are currently widely used, but this may vary depending on the intention or custom of a person skilled in the art or the emergence of new technology. Also, in certain cases, there may be a term selected arbitrarily by the applicant, in which case the meaning thereof will be described in detail in the description of the corresponding invention. Therefore, it is to be understood that the terminology used herein is for the purpose of describing the invention only and is not to be taken by name.

1 is a system configuration diagram showing the concept of an IPTV service.

Referring to FIG. 1, an IPTV system includes a service provider domain, a network provider domain, and a consumer domain.

The service provider domain may include a content provider and a service provider. The content provider plays a role of providing content to a service provider. The service provider plays a role of providing services to subscribers, collects various contents, modifies signals according to the IP environment, and delivers the modified contents to users. In addition, the service provider transmits multimedia data, and performs maintenance and management of the transmission network so that the contents can be received stably by the customer, and an infrastructure for network transmission to the contents provider Function. Here, the service provider may be a virtual entity, and the content provider may soon be a service provider.

The network provider domain serves to connect a user and a service provider through an IP network. The transmission system may use various network networks such as an access network, a backbone network, or a wireless wide area network (WAN).

The customer area is an area for consuming an IPTV service. The customer area serves to reproduce the incoming data using an infrastructure such as xDSL or cable and react immediately to the user's request. Most of them are made up of companies that produce IPTV, and they can be divided into IPTV, IP STB, and IP phone. A customer area device may be used to receive content from the customer area and receive broadcasts. Here, the customer area apparatus includes a set top box, a PC, a mobile terminal, an IPTV terminal function (ITF) apparatus, or a delivery network gateway (DNG) apparatus.

Let's look at each area in detail.

First, a contents provider may be a TV station and a radio station that create a broadcast program. A TV station means a conventional terrestrial or cable broadcasting station, which can create a program that can be viewed by the user, store it in a digital form, and transmit it. In general, it is intended to allow transmission in various broadcasting formats.

A radio station is a general radio station, and although it may be a video channel occasionally, it can be seen as operating without a video channel in most cases. Video On Demand (VoD) and Audio On Demand (AoD) services have different characteristics from TV stations and Radio Stations. The contents provider also stores the program to be broadcasted. However, this is a live broadcast with continuity. The program can not be rewound or stopped unless it is recorded. However, in the case of VoD or AoD, I can store the desired program, movie, or music, and then play it back. For example, if there is a broadcast program that has not been viewed properly because there is no current time, the user can access the site providing the broadcast service and download the file or view it immediately. AoD also offers the ability to record audio programs in a difficult or real-time manner. MoD (Music on Demand) service can download music I want to listen to. The service of MoD can be performed by a music distributor or a music distribution company by expanding existing web services.

Hereinafter, an embodiment of a service provided by a content provider will be described.

The PF server can service all the broadcasting information and location information provided by the contents provider in place of the provider. This service mainly includes the broadcasting time of the broadcasting station, position information necessary for broadcasting, and information that the user can access. The customer can obtain this information and display it on the screen. The PF server is one of the services to be provided for each broadcasting station and can provide the service in the IPTV environment so that the user can access the corresponding broadcasting station.

The EPG service is one of convenient services that enables users to view broadcast programs by time zone and to grasp them by channel. The EPG service is already installed on the customer side so that the program can be executed automatically. The user can obtain only the information on the corresponding broadcasting station from the PF server, but the EPG service can obtain the information on the real time broadcasting channel of all the broadcasting stations at once and can be used very conveniently. For example, it has built-in powerful functions such as scheduled recording of CNN news or reservation of watching Disney broadcasting. Therefore, the EPG service must provide detailed information of the broadcast program in the corresponding time zone. Especially, in some dramas, it is possible to search contents of drama, divide into SF, Drama, Animation and so on by dividing into categories, and it also includes detailed information about plot and characters of movies and dramas of simple broadcasting programs can do. A major problem of the EPG service is that there are many types of licenses of a customer who watches IPTV, so it may be a matter of how to transmit EPG data suitable for a user. To access the EPG service, Costumer simply finds and presses the input key on the remote control.

The ECG service has all the functions that the user can conveniently use the contents information of the contents provider, the location of the connection server and the access right. Simply put, it is an electronic program guide (EPG) that gives you detailed information on the content and the ability to easily access servers with content. That is, services such as AoD, MoD, and VoD are bundled together like an EPG, not a real-time broadcast, thereby relieving the user of a separate access to view or download content to a content service. It is similar to EPG service, but it does not inform real time broadcasting channel information, but it is already stored in server so that it can be viewed at any time, downloaded and stored. In order for users to access the server with each Content, they will need to access very difficult addresses or PF servers. This is a very complex process and takes a lot of time. The provider of the ECG will automatically install the ECG program on the customer, collecting information on all the content and providing the data. To access the ECG service, Customer can also click the input key button on the remote control.

Portal Server is a Web service provided by each broadcasting station and is connected to a web server of a broadcasting station or a service provider. The role of Portal Server is to retrieve a list of programs provided by each broadcasting station or content providers providing contents services (contents providers), or to view a list. This can be thought of as an ECG or EPG. However, the Portal service also has features such as user authentication and license agreement, so I need to connect to watch the program I want. In addition, the ECG or EPG provides a consolidated broadcast or content list, but the portal service can provide detailed information by providing broadcast or content list information for the program provider. To access the Portal service, Customer can click the Portal input button on the remote control.

In order to operate the functions normally, the contents provider needs to transmit the program in real time or transmit the broadcast information to the server 130 of each service company. Must be connected to the IP network. In addition, since each broadcasting station or service provider is connected to a network of a service provider and is required to transmit without delay and error, it is possible to transmit multimedia data using Internet real time protocols such as RTP, RTSP, RSVP, and MPLS . For example, if you want to transmit multimedia in real-time in TV Studio, which provides current news, if you are using MPEG-2 and AC-3 audio specifications, you need to transcode it to fit the format of IPTV. After passing through the server that performs this task, the system is configured to pass the IP Network provided by the service provider by attaching the RTP / UDP protocol including time information so that caption or Lipync can be matched.

The service provider provides the stability and bandwidth of the network so that multimedia data and broadcast data transmitted from the contents provider can be transmitted well. Service providers may provide IPTV services using existing cable networks. In this case, it is necessary to change the equipment of the delivery network. In other words, it is necessary to configure network equipment capable of real-time data transmission and configure the network considering bandwidth to the customer. These devices need to reduce the bandwidth by processing large amounts of multimedia data using Multicast service, which is the basic network service of IPTV. If the bandwidth can not be secured, the service provider may transcode the multimedia broadcasting data from the optical fiber network configuration or contents provider in an effort to secure bandwidth, and transmit the data in the form of MPEG-4 or MPEG-7 have. To do this, the Service Provider has to provide a number of services, such as NMS (Network Management System), Dynamic Host Control Protocol (DHCP), and CDN service.

The NMS service manages the delivery network that the service provider can transmit to each customer and performs the RCMS (Remote Configuration and Management Server) function. In other words, if there is a problem in the transmission network and the customer can not receive the broadcasting, it must have a means of emergency handling. NMS is widely used as a standardized means for smoothly controlling and managing remote transport layer machines. With this service, you can see how much traffic is being generated for a certain broadcast, and what bandwidth is not available in some areas. It is also necessary to provide content providers with content providers to create and manage groups at the time of multicast. Sometimes it is necessary to create more multicast groups.

The DHCP service is used to automatically assign IP to the IPTV receiver of the customer and to provide the address of the CDN server. The DHCP service is also a good way to assign IP to a PC in a normal network. The IPTV receiver should be able to connect to the IPTV receiver to allow access to the IPTV receiver when the user first accesses the IPTV receiver. In general, IPv4 will be provided by IPTV receiver, but IPv6 is also available. Therefore, it does not mean that it can not be used as an IPTV receiver that provides IPv4.

The CDN service is data provided by the service provider, and when the IPTV receiver is powered on for the first time, the CDN information is received by the service provider while receiving the IP by the DHCP service. This information contains the registration and authentication of users of IPTV operators and the PF information mentioned above. IPTV receiver can receive IP broadcast signal by obtaining CDN information from service provider.

A customer can have several types of IPTV receivers. For users with ordinary TVs, users can rent IPTV STBs to enjoy IPTV inexpensively. Service providers can also pay for additional services at low cost and apply for IP phones. The IPTV receiver basically has a network interface capable of connecting to a network and has an internet protocol, and receives and processes data packets received from the network. In the case of multimedia data, the IPTV receiver can reproduce data on the screen. And the information is received from the server and reacted. That is, the IPTV receiver can operate in a bidirectional manner to transmit user's requests while processing multimedia data. In addition, IPTV buttons can be provided on the remote control so that the service can be used well. In the IPTV receiver thus provided, the user can enjoy a wonderful scene in the drama, and can enjoy additional services such as location information and hotel reservation.

Meanwhile, the NMS mentioned above performs the RCMS function as well as the function of the service provider to manage the network. The RCMS helps to control and manage the users' IPTV receivers. When IPTV receivers surge and additional services increase, the role of RCMS becomes more important. For this reason, the SNMP protocol is mandatory for IPTV broadcast receivers. This is intended to allow service providers to manage and control IPTV broadcast receivers. In this case, the IPTV broadcast receiver can obtain detailed information about the protocol of the currently communicating protocol, the information of the processor used, and the TV manufacturer.

In order to receive the IPTV service in the customer domain, the ITF 120 may send a server address resolution request to the DNS server 110. Then, the DNS server 110 transmits the server address to the ITF 120. Then, the ITF 120 connects to the server 130 with the received server address and receives the IPTV service. Here, the ITF 120 may be connected to the server 130 through at least one of a multicast casting method and a unicast method.

2 is a diagram schematically showing a multicast scheme.

Referring to FIG. 2, a multicast scheme is a scheme of transmitting data to a plurality of recipients of a specific group. For example, a service provider may transmit data to a plurality of pre-registered ITFs at once. An Internet Group Management Protocol (IGMP) protocol may be used for the multicast registration.

Fig. 3 is a diagram schematically showing a unicast method.

Referring to FIG. 3, the unicast method is a method of transmitting data between one sender and one receiver at a ratio of 1: 1. For example, in a case of a unicast method, when an ITF requests a service to a service provider, the service provider transmits the service to the ITF according to a request.

4 is a flowchart illustrating a method of searching for an IPTV service according to an exemplary embodiment of the present invention.

Referring to FIG. 4, in order to receive an IPTV service, the ITF performs a service provider discovery to find an address list of an SD server (Service Discovery Server). Here, the service provider discovery refers to a process in which the ITF finds information for accessing an IPTV service provider and a service provider through a secure managed network. The ITF can find the address list of the SD server (Service Discovery Server) in the following way.

Address list search method of SD server (Service Discovery Server)

1. Pre-set or manual settings: follow the preset address in the ITF or manually set up the user

2. DHCP-based SP Discovery: Using the DHCP option to get the address list of the SD server

3. DNS SRV-based SP Discovery: Uses the DNS SRV mechanism to retrieve queries from the SD server peripheral list

The ITF 420 can find a specific SD server through the SD server address list obtained by the above-described methods 1 to 3, and receive the service provider discovery record from the specific SD server.

The service provider 410 transmits a service provider discovery record to the ITF 420 (S400). Wherein the service provider discovery record includes information about a useful IPTV service provider and information for accessing a service provider to a secure managed network. The service provider discovery record may be transmitted in a push mode or a pull mode. In the case of being transmitted in the pull mode, the service provider 410 transmits the service provider discovery record when the ITF 420 has a transmission request for the service provider discovery record. However, in the case of being transmitted in the push mode, the service provider 410 transmits the service provider discovery record regardless of the transfer request for the service provider discovery record by the ITF 420.

The ITF 420 accesses the Registration Server designated by the address information of the Registration Server included in the service provider discovery record to perform the ITF registration procedure (S405). In this case, information transmitted from the ITF 420 to the service provider 410 may be transmitted in the form of an ITF RegistrationInputType record, and may include subscriber identifier information and subscriber location information. And wherein the ITF registration may be named SP Provider Attachment, which may vary depending on the intent or custom of the skilled artisan in the art, or the emergence of new technology.

After successful authentication, the service provider 410 transmits a provision information record to the ITF 420 (S410). Here, the provision information record is a record providing provisioning information and authentication information obtained by the ITF during the SP access procedure. The provision information record is in the form of an ITFRegistrationOutputType record, and may be data customized to the subscribed service based on the information contained in the ITFRegistrationInputType record. Here, the ITFRegistrationInputType record may include at least one of subscriber identifier information and subscriber location information. Herein, the subscriber location information may be an address where the subscriber's ITF is located. Also, when the ITF RegistrationInputType record includes only the subscriber identifier information, the Registration Server can acquire the subscriber location information and the subscription state information previously stored based on the subscriber identifier information.

For example, the provision information record may be customized to the subscription status and ITF location of the subscriber. The ITF 420 provides its ID and location information through the ITF RegistrationInputType record, and the Registration Server can identify the service to which the ITF subscribes based on the ID and location information. The registration server provides an address for obtaining the service information to be received by the ITF 420 based on the specified service, in the form of an ITFRegistrationOutputType record.

The service information includes a master SI table record for managing the version of the channel map and the channel details, a channel map record for providing the channel list of the package type, And a channel details record containing detailed information. Here, the service information may be transmitted in a push mode or a pull mode.

The service provider 410 transmits a master SI table record to the ITF 420 (S415). Here, the ITF 420 may receive the master SI table record or request the service provider 410 based on the location information of the master SI table included in the provision information record.

In addition, the service provider 410 transmits a channel map record to the ITF 420 (S420). Here, the ITF 420 may receive the corresponding channel map record or request the service provider 410 based on the channel information included in the master SI table record.

Then, the service provider 410 transmits a channel details record to the ITF 420 (S425). Here, the ITF 420 may receive the channel detail scale record or request the service provider 410 based on the virtual channel information included in the master SI table record or the channel detail switch information included in the channel map record.

FIG. 5 is a diagram illustrating a schema of a preferred embodiment of a service provider discovery type according to the present invention.

Referring to FIG. 5, the service provider discovery record includes a ServiceProviderID attribute, a Version attribute, a LogoURI attribute, a Name element, a Description element, and a SProviderRegistrationServer element.

The ServiceProviderID attribute contains unique identifier information that identifies the service provider, and the identity of the identifier can be guaranteed by using the domain name registered with the identifier.

The Version property contains version information for this record.

The LogoURI attribute contains logo image information specifying the URI of the logo of the service provider and can optionally be used.

The Name element contains information about the service provider's name, and the service provider can have one name for each language. To do this, the Name element contains the Language attribute, and the Language attribute contains information about the name defined for each language. Where the Name element must contain at least one Language attribute.

The Description element contains detailed textual description information for the service provider, and the textual description information can be for each language, similar to the information for the service provider's name. To this end, the Description element includes a Language attribute, and may include a plurality of the Language attributes. The Language attribute includes text description information. Here, the text description information is optionally available and may not be provided.

The SProviderRegistrationServer element contains the address information of the service provider's Registration Server. To this end, the SProviderRegistrationServer element may include a Location URL attribute, and the Location URL attribute contains the address information of the Registration Server. Here, the address information of the Registration Server may be URL format.

FIG. 6 is a diagram illustrating a schema of a preferred embodiment of the ITF Registration Input Type according to the present invention.

Referring to FIG. 6, the ITF Registration Input Record includes a ConsumerID attribute and a ConsumerLocation attribute, and the information transmitted from the ITF to the Registration Sever for Registration can be transmitted in the structure of the ITF registration input type.

The ConsumerID attribute includes subscriber identifier information that can uniquely identify the subscriber, and the MAC address of the ITF may be used as the subscriber identifier.

The ConsumerLocation attribute includes subscriber location information indicating the location of the subscriber. Through the information contained in the ConsumerLocation, the Registration server can recognize the location of the subscriber and determine the corresponding area, and can select and send appropriate flows according to the determined area. Here, the subscriber location information can be obtained through the DHCP option in the network attachment step.

7 is a diagram illustrating a schema of a preferred embodiment of the ITF Regulation Output Type according to the present invention.

Referring to FIG. 7, the ITF registration output record includes a MasterSITableLocation element, a SubscribedChannelMap element, an UnsubscribedChannelMap element, an EPGDiscoveryLocation element, and an SPRemoteConfigurationServerLocation element. When registration is successful, information transmitted from the Registarion Server to the ITF is an ITF registration output type Regitration Output Type) structure.

The MasterSITableLocation element contains the location information of the Master SI Table.

The SubscribedChannelMap element contains information about the channel map to which the user subscribes. Service providers can provide channels they serve in multiple channel maps so that users can select one or more of them to subscribe. Also, it is possible that the channel map is not directly displayed to the user but is internally configured in the form of a channel map, thereby providing a list of channels subscribed to by the user in combination of the channel maps.

The UnsubscribedChannelMap element contains information about the channel map to which the user has not subscribed. The service provider may need to provide such a channel list for the promotion, although the user may not be able to view it, even though the user is not currently subscribed. The service provider may optionally provide such channel maps.

The EPGDiscoveryLocation element includes EPG data provider information for discovery of EPG data. The EPG data provider information includes address information capable of receiving EPG data. The EPG may be provided selectively and may provide one or more EPGs. Here, the EPGDiscoveryLocation element may be defined as an EPG Discovery Record Type, for example.

The SPRemoteConfigurationServerLocation element contains the address information of the Remote Configuration Server provided by the SP. If there is address information of Remote Configuration Server, ITF must connect to Remote Configuration Server and perform Remote Configuration procedure. Here, the Remote Configuration Server performs the RCMS function described above.

FIG. 8 is a diagram showing a relationship among respective tables constituting service information (SI).

Referring to FIG. 8, a master SI table record provides pointers to virtual channel maps. Here, the pointers are information necessary for starting the virtual channel discovery process. The master SI table record also allows the ITF to detect changes in some versions of the SI. The master SI table record includes a channel map master containing version information of each channel map and a version of channel detail containing channel details. And virtual channel masters that contain information. Here, the master SI table record may optionally include a virtual channel master.

Each channel map is uniquely identified by a VCListID and has two version information, VCListVerion and ChannelDetailsVersion. VCListVersion is the version of the channel map's channel list. It is changed only when the channel is added or deleted. The ChannelDetailsVersion is version information for managing whether or not the detailed information of the channel included in the Channel Map is changed. The version is changed only when the detailed information of the channel is changed.

There can be only one master SI table record in the service provider. However, if the service configuration is different by region, it would be more efficient to configure one master SI table record for each region. In this case, it is possible to provide a master SI table record for the area where the ITF belongs through the Registration step.

In Figure 8, two channel maps are illustrated in the master SI table record, which can be uniquely identified by the VCListID. Each channel map may have one or more channels, and it does not include detailed information of the channels on the channel map, but specifies a position where the information can be obtained. That is, the Channel Details Location serves to specify the location of the channel detail information.

The Channel Detail Record contains detailed information of the channel and can be accessed by the Channel Details Location on the Channel Map. In addition to such a method, a method of transmitting a channel details record may have a variety of methods as follows.

Channel Detail Record Delivery Method

1. How to provide a single multicast stream as a global

It is a method of distributing channel detail records of all channels provided by a service provider to a single global multicast stream. In this case, as described above, it is possible to provide the address of the global multicast stream by storing the address of the detailed information in the channel map on the ITF registration information output format without providing the address of the detailed information for each channel.

2. Provide a single multicast stream by region

In the first scheme, channel detail information is provided globally as one stream. In this case, channel detail information can be provided through a separate multicast stream for each region. In this case, since the registration process can specify the area belonging to the ITF, ITFRegistrationOutputType can specify the address of the unique multicast stream in each region.

3. How to assign the Default Channel details location to the Channel Map

  If some or all of the details of a channel belonging to one channel map can be received from the same address, it is sufficient to specify it once in the channel map rather than specifying it for each Channel Details Location. In this case, if there is a channel to acquire detailed information from another address, it is possible to override the address specified in the channel map by designating the channel details location again or additionally .

4. As shown in FIG. 5, a method of specifying the location of detailed information for each channel through the Channel Details Location

And detailed information of channels belonging to each channel map is designated for each channel details location. For example, if the ServiceID is "WNBC.COM/ch9" for a channel of "WNBC.COM/ch9" and "WNBC.COM/ch11", the LocationURL of the Channel Details Location of the channel is set to "ipm: //sd.verizon.com ", and in the case of the channel" WNBC.COM/ch11 ", the LocationURL of the Channel Details Location for the detailed information of the channel is designated as" ipm: //sd.verizon.com " do.

In order to find detailed information of each channel in the transmitted channel detail records, the ServiceID of the Channel Details Location can serve as a unique identifier for distinguishing detailed information of each channel And the Channel Details Record of the corresponding channel can be found through the ServiceID of the Channel Details Location.

If a channel detail record is received in a multicast manner, a channel detail record corresponding to the ServiceID can be found while joining the stream to continuously receive the records.

If a channel detail record is received in a unicast manner, the service ID is transmitted to the server as a parameter to transmit only the desired channel detail record, and the corresponding channel detail record Record) can be received.

Master SI Table Record, Channel Map Record, and Channel Details Record are transmitted logically through three separate flows, and are in Push Mode and Pull Mode. Any one of the methods can be freely transmitted.

Pass the Master SI Table Record The ITF can manage the update of the Channel Map and Channel Details. The ITF monitors the master SI table to determine whether to change the version of the channel map and the channel details. If the version is changed, the ITF checks the channel map and the channel details, It is possible to update the channel map and the channel details.

Here, the update of the channel details can be confirmed in two ways. The first can be confirmed through the Channel Details Version of the Channel Map Master in the Master SI Table Record. If the Channel Details Version of the Channel Map Master is changed, the Channel Details can be recognized as updated. The second is through the Channel Details Version of the Channel Map Record. That is, a channel map record indicated by the Channel Map Master, and determines whether or not the Channel Details Version of the corresponding Channel Map Record is changed. In the second method, the Master SI Table Record does not need to include the Virtual Channel Master and the Channel Map Master does not need to include the Channel Details Version.

FIG. 9 is a diagram illustrating a schema of a preferred embodiment of a master SI table record type.

Referring to FIG. 9, a master SI table record includes channel map management information. To this end, the master SI table record may include a ServiceProviderID attribute, a Version attribute, a ChannelMapMaster element, and a VirtualChannelMaster element. The VirtualChannelMaster element can optionally be included here.

The ServiceProviderID attribute may contain service provider identifier information that uniquely identifies the service provider and may use the domain name registered with the service provider identifier.

The Version attribute contains the version information of the master SI table record. The version information included in the Version attribute can determine whether the master SI table record is updated.

The ChannelMapMaster element contains information for receiving the Channel Map. That is, the ChannelMapMaster element includes a pointer to a channel map instance. The master SI table record may also include one or more pointers for indicating one or more channel map records, respectively. Based on the information contained in the ChannelMapMaster element, it is possible to receive a channel map record and determine whether or not to update the channel map. To do this, the ChannelMapMaster element may include a VCListID attribute, a VCListVersion attribute, and a ChannelDetailsVersion attribute. The VCListID attribute contains identifier information that uniquely identifies the channel map instance. The VCListVersion attribute includes version information indicating whether channel lists constituting the channel map have changed. The version information contained in the VCListVersion attribute here is changed when the channel is added or deleted. The ChannelDetailsVersion attribute includes version information indicating whether or not the detailed information of the channel constituting the channel map is changed. The version information contained in the ChannelDetailsVersion attribute is changed when the channel details are changed.

The VirtualChannelMaster element includes a ServiceID attribute and a VCVersion attribute. The ServiceID attribute contains identifier information for uniquely identifying the service. Based on the information contained in the ServiceID attribute, a desired Channel Details Record can be found. The VCVersion attribute includes version information of the Channel Details.

10 is a diagram illustrating a schema of a preferred embodiment of a channel map type.

Referring to FIG. 10, a channel map includes channel map information. It does not include detailed information of channels, and functions as a bundle of channels. Here, the channel map of FIG. 10 indicates a method of specifying a separate address for each channel detail, which is the fourth method among the above-described channel details delivery methods in FIG. Here, the channel map information may be, for example, a channel map instance.

The Channel Map Record includes a Channel Map Instance. To this end, the Channel Map Record includes a ServiceProviderID attribute, a VCListID attribute, a VCListVersion attribute, a ChannelDetailsVersion attribute, and a ChannelDetailsLocation element.

The ServiceProviderID attribute may contain service provider identifier information that uniquely identifies the service provider and may use the domain name registered with the service provider identifier.

The VCListID contains identifier information that uniquely identifies the ChannelMap.

The VCListVersion attribute includes version information indicating whether channel lists constituting the channel map have changed. The version information included in the VCListVersion attribute is changed when a channel is added or deleted.

The ChannelDetailsVersion property includes version information indicating whether or not the detailed information of the channel constituting the channel map is changed. The version information contained in the ChannelDetailsVersion attribute is changed when the channel details are changed.

The ChannelDetailsLocation element contains the location information of the detailed information of each channel. To this end, the ChannelDetailsLocation element includes a ServiceID attribute, a LocationURL attribute, and a VCVersion attribute. The ServiceID attribute contains identifier information for uniquely identifying the service. Based on the information contained in the ServiceID attribute, a desired Channel Details Record can be found. The LocationURL attribute contains address information from which detailed information of this service can be obtained. The VCVersion attribute includes version information of the Channel Details.

11 is a diagram illustrating a schema of another preferred embodiment of a channel map type.

Referring to FIG. 11, a channel map includes channel map information and serves as a bundle of channels, and does not include detailed information of a channel. Instead, And information about the location. Here, the channel map (Channel Ma) of FIG. 11 corresponds to a method of assigning a default channel details location to a channel map, which is the third method among the channel detail delivery methods described in FIG. 8 . Here, the channel map information may be, for example, a channel map instance.

The Channel Map Record includes a Channel Map Instance. To this end, the Channel Map Record includes a ServiceProviderID attribute, a VCListID attribute, a VCListVersion attribute, a ChannelDetailsVersion attribute, a ChannelDetailsDefaultLocation element, and a ChannelDetailsLocation element.

The ServiceProviderID attribute may contain service provider identifier information that uniquely identifies the service provider and may use the domain name registered with the service provider identifier.

The VCListID contains identifier information that uniquely identifies the ChannelMap.

The VCListVersion attribute includes version information indicating whether channel lists constituting the channel map have changed. The version information included in the VCListVersion attribute is changed when a channel is added or deleted.

The ChannelDetailsVersion property includes version information indicating whether or not the detailed information of the channel constituting the channel map is changed. The version information contained in the ChannelDetailsVersion attribute is changed when the channel details are changed.

The ChannelDetailsDefaultLocation element includes the location information of the details of the channel belonging to the channel map. To do this, the ChannelDetailsDefaultLocation element contains a LocationURL attribute. The LocationURL attribute contains the location information of the devolat. Here, the location information is an address that can receive all or a part of the detailed information of a channel belonging to one channel map. If there is a channel to acquire detailed information from another address, the location information of the detailed information of the corresponding channel may be overlaid on the ChannelDetailsLocation element.

The ChannelDetailsLocation element contains the location information of the detailed information of each channel. In other words, if there is detailed information on the channel that can not be obtained from the location information of the devolta included in the ChannelDetailsDefaultLocation element, the ChannelDetailsLocation element includes the location information of the detailed information of the channel. To this end, the ChannelDetailsLocation element includes a ServiceID attribute, a LocationURL attribute, and a VCVersion attribute. The ServiceID attribute contains identifier information for uniquely identifying the service. Based on the information contained in the ServiceID attribute, a desired Channel Details Record can be found. The LocationURL attribute contains address information from which detailed information of this service can be obtained. The VCVersion attribute includes version information of the Channel Details.

12A and 12B are diagrams illustrating schemes of one preferred embodiment of a Channel Details Type.

12A and 12B, a channel detail record includes detailed information of a channel included in a channel map. The Channel Details Record for this includes a ServiceProviderID attribute and a VirtualChannelDetails element.

The ServiceProviderID attribute contains service provider identifier information that can uniquely identify the service provider.

The VirtualChannelDetails element contains the details of each channel. To this end, the VirtualChannelDetails element includes a ChannelType attribute, a ServiceID attribute, a VCVersion attribute, a ShortChannelName element, a ChannelNumber element, and a ChannelSource element. Where the ChannelSource element may optionally be included. If the VirtualChannelDetails element does not contain a ChannelSource element, the ChannelSource element may be independently transmitted in a separate ChannelSource record, and the VirtualChannelDetails element may contain location information and identification information capable of receiving ChannelSource records.

The ChannelType attribute includes service type information indicating a service type of the channel, and the service type information indicates whether the corresponding channel is a video channel, an audio channel, or a data broadcast channel.

The ServiceID attribute contains identifier information for uniquely identifying the service. Based on the information contained in the ServiceID attribute, a desired Channel Details Record can be found.

The VCVersion attribute includes version information of the Channel Details.

The ShortChannelName element contains the name of the channel with a short text value of up to seven characters. For example, it could be the same value as "WABC".

The ChannelNumber element contains the corresponding channel number. In the present invention, both the one-part channel number and the two-part channel number can be supported, so that the corresponding channel number can be either a one-part channel number or a two-part channel number. To this end, the ChannelNumber element may include a MajorChannelNumber element including physical channel information and a MinorChannelNumber including logical channel information.

The ChannelSource element contains information specifying the actual source of the channel. To this end, the ChannelSource element includes a VirtualChannelLocation element, a ChannelSourcePurpose element, a VideoAttribute element, an AudioAttributes element, and an ECMLocation element.

The VirtualChannelLocation element contains the IP address and transport protocol information that can receive the source of the channel. To this end, the VirtualChannelLocation element includes a ProgramNumber attribute and an IPLocation element. By selectively supporting the ProgramNumber attribute, scalability to the MPTS is ensured, and at the same time, the SPTS provides an opportunity to check whether the received stream is a desired stream. The IPLocation element contains a Location URL attribute that contains URL information that can receive the source of the channel.

The ChannelSourcePurpose element includes source type information, which is a value indicating the character of the channel, and may include a plurality of source type information. Here, the source type information may be any one of HD, SD, PIP, and Barker. The Barker channel is an advertising or promotional channel. When the channel can not be watched because the channel is not authorized, the channel is automatically selected as a channel, and Barker plays the role of promoting and signing up the channel. Barker is at least one of HD Barker, SD Barker and PIP Barker It contains one value.

One channel can have one source per value specified by ChannelSourcePurpose. That is, if the ChannelSourcePurpose element contains one HD and one SD simultaneously, one channel may have one HD source and one SD source. However, since one channel does not need to have two HD sources at the same time, the ChannelSourcePurpose element does not contain two HDs at the same time.

The VideoAttributes element contains the video attribute information of the corresponding source. To this end, the VideoAttributes element includes a Codec attribute including video codec information, a Profile attribute including video profile information, and a Level attribute including video level information.

The AudioAttributes element contains the audio attribute information of the corresponding source. To this end, the AudioAttributes element includes a Codec including audio codec information, a Profile attribute including video profile information, a Level attribute including audio level information, a Bitrate attribute including audio bitrate information, and SamplingFrequency information including audio sampling frequency information .

The optimal source can be selected and watched according to the function of the ITF through the video attribute information included in the VideoAttribute element and the audio attribute information included in the AudioAttributes element.

The ECMLocation element includes ECMLocation address information capable of receiving ECM information.

FIG. 13 is a flowchart illustrating a process of performing a service provider discovery according to an exemplary embodiment of the present invention.

Referring to FIG. 13, the ITF searches for an SD server (S1300). Here, the ITF can find the SD server according to the address list search method of the SD server (Service Discovery Server) described above with reference to FIG.

The ITF accesses the SD server based on the list of peripheral speeds of the SD server and obtains a service provider discovery record from the SD server (S1310). Here, the service provider discovery record may be the service provider discovery record described above with reference to FIG. In addition, the ITF can receive the service provider discovery record from the SD server in the PUSH mode or the PULL mode.

The ITF parses the ServiceProviderID attribute of the received Service Provider Discovery Record (S1320), and calculates the service provider identifier information included in the ServiceProviderID attribute.

The ITF checks whether the calculated service provider identifier information is a service provider that desires to receive the service (S1330). If the service provider is not a service provider who desires to receive the service, the ITF performs step S1300 to search for another SD server in the list of peripheral devices of the SD server.

If the service provider wishes to receive the service, the ITF parses the Name and Description attributes of the Service Provider Discovery Record to provide information about the name of the service provider included in the Name attribute and Description Detailed text description information on the service provider included in the attribute is calculated (S1340).

Then, the ITF parses the SProviderRegistrationServer element of the provider discovery record (S1350) and calculates the address information of the registration server of the service provider included in the SProviderRegistrationServer element. The ITF can access the Registration Server based on the address information of the Registration Server to perform the ITF registration procedure.

FIG. 14 is a flowchart illustrating a process of performing a service provider registration (Service Provider Registration) and a service discovery (Service Discovery) according to a preferred embodiment of the present invention.

Referring to FIG. 14, the ITF transmits a registration request to a registration server designated by the address information of the Registration Server included in the service provider discovery record (S1400). Here, the ITF can transmit the ITFRegistrationInputType record described above in Fig. 6 as a registration request.

The Registration Server receives the registration request and determines whether the ITF is registered (S1410). Here, the Registration Server can receive the ITFRegistrationInputType record as the registration request, and can determine whether or not to register based on the subscriber identifier information and the subscriber location information included in the ITFRegistrationInputType record.

If the registration is approved, the ITF receives the ITFRegistrationOutputType record (S1420). Here, the ITFRegistrationOutputType record may be the ITFRegistrationOutputType record described above in FIG. 7, and the information included in the TFRegistrationOutputType record may be information customized by the information included in the ITFRegistrationInputType record.

The ITF parses the MasterSITableLocation element of the received ITFRegistrationOutputType record, and calculates the location information of the Master SI Table included in the MasterSITableLocation element (S1430).

The ITF receives the master SI table record based on the calculated location information of the master SI table (S1440). The received master SI table record (Master SI Table Record) may be the master SI table record described above with reference to FIG.

The ITF parses the SubscribedChannelMap element of the received ITFRegistrationOutputType record, and calculates information about the channel map to which the user included in the SubscribedChannelMap element subscribes (S1450). Here, the ITF can calculate the channel map position information for receiving the channel map to which the user subscribes from the ChannelMapMaster of the master SI table record (Master SI Table Record).

The ITF receives a channel map record based on the calculated channel map location information (S1460). The received channel map record may be at least one of the channel map record described above with reference to FIG. 10 and the channel map record described with reference to FIG.

The ITF parses the ChannelDetailsLocation element of the received channel map record to calculate the location information of the detailed information of the channel included in the ChannelDetailsLocation element (S1470).

The ITF receives the channel details record based on the location information of the detailed information of the calculated channel (S1480). The received channel detail record may be a channel details record shown in FIGS. 12A and 12B.

Then, the ITF starts the received service service (S1490).

FIG. 15 is a flow chart illustrating the process of performing a preferred embodiment of a method for processing an update of a master SI table (Master SI Table).

Referring to FIG. 15, the ITF updates the master SI table (S1500). The ITF monitors the master SI table in real time and confirms whether the received master SI table record has been changed. If the received version of the master SI table record is changed, the ITF updates the master SI table with the information contained in the received master SI table record (master SI table record) .

The ITF selects a ChannelMapMaster element for updating among the ChannelMapMaster elements included in the master SI table (S1510).

The ITF checks whether the selected ChannelMapMaster element includes information for receiving the channel map to which the user subscribes (S1520). For this purpose, the ITF can use the information on the channel map subscribed by the user included in the SubscribedChannelMap of the ITFRegistrationOutputType record.

If the user includes information for receiving the channel map to which the user subscribes, the ITF checks whether the version information included in the VCListVersion attribute of the selected ChannelMapMaster element has been changed (S1530). When the version information included in the VCListVersion attribute is changed, the ITF receives the updated channel map record and stores the channel map as information included in the received channel map record (S1540).

It is checked whether there is an unselected ChannelMapMaster element in the master SI table (S1550). If there is an unselected ChannelMapMaster element, the ITF performs step S1510.

Figure 16 is a flow chart illustrating the process of performing another preferred embodiment of a method for handling an update of a master SI table (Master SI Table).

Referring to FIG. 16, the ITF updates the master SI table (S1600). The ITF monitors the master SI table in real time and confirms whether the received master SI table record has been changed. If the received version of the master SI table record is changed, the ITF updates the master SI table with the information contained in the received master SI table record (master SI table record) .

The ITF selects a ChannelMapMaster element for updating among the ChannelMapMaster elements included in the master SI table (S1610).

The ITF checks whether the selected ChannelMapMaster element includes information for receiving the channel map to which the user subscribes (S1620). For this purpose, the ITF can use the information on the channel map subscribed by the user included in the SubscribedChannelMap of the ITFRegistrationOutputType record.

If the user includes information for receiving the channel map to which the user subscribes, the ITF checks whether the version information included in the VCListVersion attribute of the selected ChannelMapMaster element is changed (S1630). When the version information included in the VCListVersion attribute is changed, the ITF receives the updated channel map record and stores the channel map as information included in the received channel map record (S1640).

The ITF checks whether the version information included in the ChannelDetailsVersion attribute of the selected ChannelMapMaster element is changed (S1650). When the version information included in the ChannelDetailsVersion attribute is changed, the channel detail information (Channel Details) is updated (S1650).

It is checked whether there is an unselected ChannelMapMaster element in the master SI table (S1670). If there is an unselected ChannelMapMaster element, the ITF performs step S1610.

Figure 17 is a flow diagram illustrating the process of performing a preferred embodiment of a method for handling updates of a Channel Details Version.

Referring to FIG. 17, the ITF updates a channel map (S1700).

The ITF selects a channel from a channel map (S1710). Here, the ITF can also select a ChannelDetailsLocation element including location information of the detailed information of the channel selected in the channel map.

The ITF checks whether the version information included in the VCVersion attribute of the selected ChannelDetailsLocation element is changed (S1720). If the version information is changed, the ITF receives the updated channel detail record and, based on the information contained in the received channel details record, Details is updated (S1730).

The ITF checks whether there is a channel that is not selected in the channel map (S1740). If there is an unselected channel, the ITF performs step S1710.

FIG. 18 is a flow chart illustrating a process of performing another preferred embodiment of a method for processing an update of a Channel Details Version. FIG.

Referring to FIG. 18, the ITF selects a channel from a channel map (S1800). Here, the ITF can also select a ChannelDetailsLocation element including location information of the detailed information of the channel selected in the channel map.

The ITF retrieves a Virtual Channel Master element including a ServiceID attribute including identifier information such as identifier information included in the ServiceID attribute of the ChannelDetailsLocation element selected in the master SI table (MasterSITable) (S1810).

The ITF determines whether the version information included in the VCVersion attribute of the searched Virtual Channel Master element is the same as the version information included in the VCVersion attribute of the selected ChannelDetailsLocation element (S1820). If different from the version information, the ITF receives the updated Channel Detail Record and, based on the information contained in the received Channel Details Record, (S1830).

The ITF checks whether there is a channel that is not selected in the channel map (S1840). If there is an unselected channel, the ITF performs step S1800.

FIG. 19 is a diagram illustrating a schema of a preferred embodiment of an EPG Discovery Record Type according to the present invention.

Referring to FIG. 19, an EPG Discovery Record includes EPG discovery information for discovery of EPG data. To this end, the EPG Discovery Record includes an EPGProviderID attribute, a Version attribute, a Name element, a Description element, an EPG ServerLocation element, a TargetServiceProviderID element, and a Logo element.

The EPGProviderID contains identifier information that can uniquely identify the provider providing the EPG data. Here, the domain name registered as the identifier information can be used.

The Version attribute contains version information of the EPG Discovery Record.

The Name element contains information about the text name of the EPG data provider, and the EPG data provider can have one name for each language. To do this, the Name element contains the Language attribute. The Name element may include a plurality of Language attributes, and each of the plurality of Language attributes includes information on a text name of an EPG data provider defined for each language.

The Description element includes detailed textual description information for the EPG data provider, and the textual description information can be one for each language, similar to the information for the name of the EPG data provider. To this end, the Description element contains a Language attribute. The Description element may include a plurality of Language attributes, and each of the plurality of Language attributes includes text description information defined for each language.

The EPG ServerLocation element includes IP address information capable of receiving EPG data and protocol information used to receive EPG data.

The TargetServiceProviderID element contains the ID information of service providers supported by the EPG data provider.

The logo contains the location information of the logo of this EPG data provider. Here, the location information of the logo may be in the form of a URI.

20 is a block diagram showing a configuration of a preferred embodiment of the ITF (IPTV Terminal Function) according to the present invention.

20, the ITF includes a network interface unit, an IP network stack 2015, a file handler 2020, an SI handler 2025, an EPG handler 2025, A Storage 2035, an SI Decoder 2040, an EPG Decoder 2045, an ITF Operation Controller 2050, a Channel Service Manager A service manager 2055, an application manager 2060, a demultiplexer 2065, a PSI / PSIP parser 2070, an A / V decoder 2075, And a display module (display module) 2080. The network interface unit may include a modem 2005 and an Ethernet network interface (Ethernet NIC) 2010.

Modem (2005) acts as an interface between ITF and IP network at the physical level. A modem 2005 demodulates a signal transmitted through a physical medium and restores the signal to a digital signal and modulates a digital signal transmitted from the ITF to a service provider. And outputs it to the IP network. The modem 2005 may be implemented as a cable modem, a DSL modem, or the like.

The Ethernet network interface (Ethernet NIC) 2010 restores an IP packet of a digital signal transmitted through a modem 2005 and outputs it to an IP network stack 2015. The Ethernet network interface (Ethernet NIC) 2010 encapsulates the IP packet output from the IP network stack 2015 into an Ethernet datagram and outputs the encapsulated IP datagram to the modem 2005.

The IP network stack (2015) processes the processing modules of each layer according to the IP protocol stack. The IP network stack (2015) is involved in delivering packets from the source to the destination for packets received at the ITF and packets transmitted at the ITF. The IP network stack 2015 classifies the received packets so as to correspond to an appropriate protocol, and outputs packets classified as a file handler 2020 and a demultiplexer 2065. For example, the IP Network Stack 2015 may include a Service Provider Discovery Record, an ITF Registrations Output Record, a Master SI Table Record, a Channel Map Record When receiving a packet including any one of a channel map record, a channel detail record, and an EPG discovery record, the data included in the packet is handled by a file handler, (2020). Also, the network stack (IP Network Stack) 2015 outputs an ITF Registration Input Record to the Ethernet network interface (Ethernet NIC) 2010 so as to be IP packetized and transferred to the service provider.

The file handler 2020 collects the data output from the IP network stack 2015 and restores the data to a file form. Here, the file handler 2020 can restore the data output from the IP network stack 2015 to a file format using the FLUTE. That is, the service provider can transfer the file using the FLUTE, and the file handler 2020 can receive the file transmitted by the service provider using the FLUTE. The file handler 2020 classifies the converted file and outputs the file to one of an SI handler 2025 and an EPG handler 2030.

The SI handler 2025 processes the portion corresponding to the IPTV SI data from the file type data transmitted from the file handler 2020 and stores the processed portion in the storage unit 2035. Here, the IPTV SI data includes a service provider discovery record, an ITF registration output record, a master SI table record, a channel map record, And may be at least one of a Channel Details Record and an EPG Discovery Record.

The EPG handler 2030 may process a part corresponding to the IPTV EPG data among the data of the file type received from the file handler 2020 and store the processed data in the storage unit 2035 . Here, the IPTV EPG data can be received from the service provider using the information included in the EPG discovery record.

The storage 2035 is provided with an SI provided by an SI handler 2025 and an EPG and an ITF operation controller 2050 provided by an EPG handler 2030 And the like.

The SI decoder 2040 decodes the SI data stored in the storage 2035 to restore necessary information and provides it to the ITF operation controller 2050. The SI decoder 2040 calculates information for a useful IPTV service provider from the service provider discovery record and information for accessing the service provider through a secure managed network. For example, the SI decoder (SI Decoder) 2040 can calculate the registration server address information included in the service provider discovery record by parsing the service provider discovery record.

In addition, the SI decoder 2040 can parse the ITF registration output record to calculate information included in the ITF registration output record. For example, an SI decoder 2040 calculates EPG discovery information for discovery of EPG data included in an ITF registration output record and address information for receiving a master SI table record It is possible.

The SI decoder 2040 parses the master SI table record to receive channel map records and channel detail records included in the master SI table record The version information of the channel map record, and the version information of the channel detail record.

The SI decoder 2040 can calculate the channel map information from the channel map record and calculate the channel detail information of the corresponding channel from the channel detail record .

The EPG decoder 2045 retrieves and analyzes the EPG data stored in the storage unit 2035 when the EPG information is needed, and restores the EPG data. The EPG decoder 2045 provides the restored EPG data to the ITF operation controller 2050.

The ITF Operation Controller (ITF Operation Controller) 2050 controls the operation of the ITF. The ITF operation controller 2050 controls the SI decoder 2040, the EPG decoder 2045 and the display module 2080 and controls the ITF operation controller ITF Operation Controller 2050 processes a request input from a channel service manager 2055 and an application manager 2060.

The ITF operation controller 2050 controls the SI decoder 2040 to generate a channel map and transmits the key map to the key input received from the channel service manager 2055 And then selects a channel using the channel map. The ITF Operation Controller (ITF Operation Controller) 2050 controls the SI Decoder 2015 so that the selected channel is received. Also, the ITF Operation Controller (ITF Operation Controller) 2050 can control the IP network stack 2015 to receive the selected channel. Also, the ITF Operation Controller (ITF Operation Controller) 2050 can control the PSI / PSIP parser (PSI / PSIP parser) 2070 so that the selected channel is received.

The channel service manager 2055 receives the channel request signal from the user and provides the input channel request signal to the ITF operation controller 2050 to change the channel to the requested channel, do.

The Application Manager (2060) manages the overall state and provides a user interface. When receiving an EPG display request from a user through a user interface, the application manager 2060 provides an EPG display request to the ITF operation controller 2050 to display a display module 2080 ) Is responsible for displaying the EPG.

The demultiplexer 2060 demultiplexes the received packets into audio data, video data, and PSI (Program Specific Information) data, and outputs them to an A / V decoder 2075 and a PSI / PSIP parser Quot; Parser " That is, the demultiplexer 2065 extracts the MPEG-2 Transport Stream data from the IP packet transmitted from the IP network stack 2015, and outputs the PSI / PSIP parser 2070 or the PSI / And transmits it to the A / V decoder (A / V Decoder) 2075.

The PSI / PSIP Parser 2070 includes a program element 2010 such as PID information of each data (A / V, etc.) of the MPEG-2 Transport Stream in the IP Datagram transmitted from the demultiplexer 2060, And extracts and parses PSI / PSIP data containing information capable of connecting the PSI / PSIP data. Also, the PSI / PSIP parser 2070 can control the demultiplexing process of the demultiplexer 2060 based on the extracted PSI / PSIP data.

The A / V decoder 2075 decodes the video data and the audio data received from the demultiplexer 2010. To this end, the decoder 2014 may include an audio decoder and a video decoder. The audio data decoded in the audio decoder is provided to a user through a display module 2080, and the decoded video data is displayed through a display module 2080.

The display module 2080 displays video data and audio data decoded by the A / V decoder 2075 under the control of the ITF operation controller 2050. The display module 2080 receives the EPG data from the ITF operation controller 2050 and displays the received EPG data according to the ITF operation controller 2050.

FIG. 21 is a flowchart illustrating a method of setting a virtual channel according to an exemplary embodiment of the present invention. Referring to FIG.

Referring to FIG. 21, the ITF performs Network Attachment (S2100). Here, the network attachment is a procedure in which the ITF establishes a layer 3 layer connection with the IP network and acquires network configuration data.

The ITF performs a service provider discovery to acquire a service provider discovery record (S2105). Here, the ITF can perform the service provider discovery described above with reference to FIG.

The ITF acquires SI and EPG data using the information included in the obtained service provider discovery record (S2110). Here, the ITF may perform the service provider registration and the service discovery described above with reference to FIG. 14 to obtain the SI metadata. The ITF performs a service provider registration so that the ITF can obtain a registration output record (ITF Regulation Output Record), and based on the information contained in the obtained registration output record (ITF Regulation Output Record) Discovery (Service Discovery) can be performed. The ITF can perform a service discovery to obtain a master SI table record, a channel map record, and a channel details record. The SI metadata can be calculated from the information included in the channel map record and the channel details record.

The ITF can also obtain EPG data based on the information contained in the EPGDiscoveryLocation included in the Registration Output Record (ITF Regulation Output Record).

The ITF generates a channel map using the obtained SI metadata and stores the generated channel map (S1215). The ITF receives the virtual channel request signal of the user (S1220). Here, the user can select a virtual channel to watch by up / down the channel.

In addition, the ITF generates an EPG using the acquired EPG data and stores the generated EPG (S1225). The ITF displays the stored EPG (S1230). The ITF receives the virtual channel request signal selected from the displayed EPG (S1235). Here, the user can select a particular virtual channel to watch on the EPG displayed on the screen.

The ITF searches the stored channel map for the requested virtual channel according to the virtual channel request signal (S1240). Here, the ITF can detect the location information that can receive the virtual channel included in the LocationURL of the channel details location by searching the channel map for the Channel Details location including the SeviceID that matches the SeviceID of the requested virtual channel. Also, the ITF can detect the detailed information of the requested virtual channel by searching the channel detail including the SeviceID that matches the SeviceID of the requested virtual channel.

The ITF tunes to the requested virtual channel based on the information about the searched virtual channel (S1245). Here, the ITF can receive the IPTV service for the requested virtual channel by accessing the address indicated by the location information capable of receiving the detected virtual channel. The ITF provides the received IPTV service to the user (S1250).

Hereinafter, a method and an apparatus for parental control for building a channel map in an IPTV terminal function according to the present invention will be described in detail with reference to the accompanying drawings.

Particularly, in the present specification, a method and an apparatus for more efficiently viewing and listening in an ITF (IPTV Terminal Function) according to the present invention will be described using SI (System Information) and EPG (Electronic Programming Guide) data essential for service and contents use.

In this specification, the term "channel" refers to both the concept of a channel used in an existing broadcasting environment and the channel related to the use of an IP-based service and contents.

In the present specification, the term " parental control "refers to a service provided through a corresponding channel when referring to SI data and EPG data that are essential for service and contents use, Accessing or restricting access to each of the contents, and accessing or restricting the channel by determining whether the corresponding channel is accessible or not.

In connection with the present invention, in the FCC, a related organization in North America, all digital TV receivers are forced to perform the viewing restriction according to the RRT (Rating Region Table) defined by ATSC A / 65C and EIA-766A. Therefore, the ITF also requires a viewing restriction function for the virtual channel.

In particular, the following describes how to restrict viewing of each virtual channel in the ITF, rather than viewing restrictions on services and contents through each virtual channel. Herein, an embodiment will be described for performing viewing restriction on each virtual channel using SI metadata.

22 is a diagram illustrating the allocation of Rating Region values of the RRT as defined in ATSC A / 65C and EIA-766A, in the context of the present invention.

Referring to FIG. 22, the Rating Region Value is allocated from '0x01' to '0x05', and a rating region, which is a meaning corresponding to each rating value, is defined. Here, '0x01' to '0x04' are the ratings (50 States + Other Possessions), Canada (Canada), Taiwan (Taiwan), and Korea. In particular, in the United States, '0x05' is assigned as rating criterion value in addition to the rating system corresponding to the existing '0x01', so that it can correspond to a rating system to be newly defined, System), and defines that all digital TV receivers are forced to respond to the expansion.

23 shows, in the context of the present invention, (U.S. Rating Region Table System).

Figure 23 is a graphical representation of the U.S. This is defined in relation to the rating table system. Referring to FIG. 23, a rating system, a plurality of dimensions, and rating values for the respective dimensions are illustrated. It should be noted, however, that the present invention will be described in detail in the US FCC, and detailed description thereof will be omitted herein.

24 is a diagram showing a relationship between SI data and EPG data in an IPTV system according to an embodiment of the present invention.

Referring to Figures 4, 5 and 24, the ITF receives access information from the service provider registration server and a Service Provider Infor Table (SI) that provides additional information about the service provider. Thus, the ITF can locate the service provider and perform the registration procedure.

Referring to FIGS. 4, 7 and 24, the ITF includes access information of the master SI table, list of channel ids subscribed by the user, access information of the service provider remote configuration server, access information of the EPG metadata, Receive ITFRegistrationOutput (SI), which provides additional information. Therefore, the ITF receives the master SI table using the access information of the received master SI table.

Referring to FIGS. 4, 9 and 24, the ITF receives an IIFMasterSiTalbe (SI) which provides access information of Virtual Channel Maps and version information of the Virtual Channel Maps. Therefore, the ITF can receive the Virtual Channel Map using the access information, and can manage the version information.

Referring to FIGS. 4, 10-11 and 24, the ITF receives an access to the Virtual Channel Description Table, a list of Virtual Channel Services, and an IIF Virtual Channel Map that provides additional information about each Virtual Channel Service. Therefore, the ITF can receive the Vitual Channel Description Table using the access information.

Referring to FIG. 24, the ITF describes a category of a Virtual Channel Service, and receives a Vitual Channel Description Table including access information of a Virtual Channel Service stream and description information of a Virtual Channel Service. Here, the description information of the Virtual Channel Service includes a virtual channel short name, a channel spatial guidance rating information, and the like.

Referring to FIG. 24, the ITF receives EPG metadata providing schedule information of contents, purchase information of contents, and explanation information of scheduled contents. Here, the description information of the scheduled content includes content name information, content partial guidance rating information, and the like.

The Vitual Channel Description Table and EPG metadata are linked to each other. Here, the link information is used for the link, and the link information may include a VirtualChannelServiceID and a ServiceIDRef.

In the following, Parental Control information of the SI data format is named Channel Parental Guidance Rating information, and Parental Control information of the EPG metadata format is named Contents Parental Guidance Rating information. However, the present invention is not limited to these names.

Referring to FIG. 24, Channel Parental Guidance Rating information according to an embodiment of the present invention is included in a VirtualChannelService element. The VirtualChannelService element is included in a VirtualChannelDescriptionTable that provides a detailed description thereof, and the VirtualChannelDescriptionTable included in the VirtualChannelService element will be accessible using the access information in the previously formed VirtualChannelMap element.

In addition, the EPG element includes information on the Contents Parental Guidance Rating corresponding to information on the Channel Parental Guidance Rating according to the embodiment of the present invention in the description information of the scheduled content.

Hereinafter, Channel Parental Guidance Rating information according to an embodiment of the present invention will be described in more detail.

FIG. 25 illustrates a schema of a Rating Region Table (RRT), which is content parental guidance rating information, which is received by the ITF as part of the EPG data in the IPTV system according to the present invention. FIG. As shown in FIG. The RRT is defined by the dimensions and values for a parental guidance rating system.

After receiving the RRT, the ITF stores it in the storage unit. The ITF provides an EPG screen so that a Parental Control can be set according to the stored RRT if the user desires. The RRT Type element includes a RatingRegionName element, a RatingRegion element, a TableVersion element, and a Dimension element, and the Dimension element includes a RatingDimensionName element, a RatingDimension element, a GraduatedScale element, and a DimensionValue element as child elements. And the DimensionValue element includes a RatingValueText element, an AbbrevValueText element, and a RatingValue element as child elements. Hereinafter, with reference to FIGS. 25 and 26, each element of the RRT Type element will be described. At this time, the name of each element of the RRT type element is indicated by bold type.

The RatingRegionName element is the name of the rating region that applies to the table. The element corresponds to the rating_region_name_text field in the ATSC PSIP specification. (The ATSC PSIP Standard corresponds to the rating_region_name_text field.

The RatingRegion element is the code number for the rating region to which the table applies. The code number corresponds to the rating_region field of the RRT table of the ATSC PSIP standard. These values approved by the ATSC as the Registration Authority will only be used. A table with a RatingRegion value of '1' will not be downloaded (Code number for the rating region to which this table applies; corresponds to the rating_region field in the ATSC PSIP standard. No table with RatingRegion value "1" shall be downloaded.

The TableVersion element is the version of the corresponding RRT table (Version of this Rating Region Table).

The Dimension element is a rating definition for a specific rating dimension.

The RatingDimensionName element is the name of the rating dimension. The name corresponds to the dimension_name_text field of the RRT of the ATSC PSIP standard (corresponds to the dimension_name_text field of the ATSC PSIP Standard).

The RatingDimension element is the code number of the rating dimension. The element corresponds to the index " i " of the dimensions-defined looping dimension of the RRT of the ATSC PSIP specification (Code number of the rating dimension; corresponding to the index " i " in the ATSC PSIP Standard).

The GraduatedScale element is a flag that indicates whether there is a rating dimension that uses a grained scale. The element corresponds to the graduated_scale field of the RRT of the ATSC PSIP standard. If the grained scale is used, the DimensionValue elements will appear in the list of order lists in the list of constrained firsts (see, for example, The Rating Region Table in the ATSC PSIP Standard. If a graduated scale is used, the DimensionValue elements shall appear in the order of least restrictive first to most restrictive last).

The DimensionValue element is a definition of a rating value for the dimension.

The RatingValueText element is the textual description of the rating value. The element corresponds to the rating_value_text field of the RRT of the ATSC PSIP specification. (Text description of the rating value corresponds to the rating_value_text field of the ATSC PSIP Standard).

The AbbrevValueText element is a simplified text for the rating value. The element corresponds to the abbrev_rating_value_text field of the RRT of the ATSC PSIP standard (corresponding to the abbrev_rating_value_text field of the ATSC PSIP Standard).

The RatingValue element is the code number of the rating value. The element corresponds to the index " j " of the value_defined looping value of the RRT of the ATSC PSIP specification (Code number of the rating value; corresponding to the index value of the value_defined loop of the Rating Region Table in the ATSC PSIP Standard).

The ITF receives and stores the RRT Type element including each of the elements of FIGS. 25 and 26 described above. In addition, an EPG is generated and provided according to a request of a user, thereby enabling a user to restrict viewing.

FIG. 27 illustrates a schema structure of SI data and Virtual Channel Descriptions Table including Parental Control information according to an embodiment of the present invention, FIG. 28 illustrates a schema structure of a VirtualChannelDescription Table in XML format, and FIG. 29 is a diagram showing the schema structure of the RRTParentalGuidance element in XML form in FIG.

27 to 29, the Parental Control information of the SI data format according to the present invention is included as one of a plurality of lower-level elements in the VirtualChannelDescriptionTable element, and the corresponding element is referred to as an RRTParentalGuidance element. It should be noted, however, that the present invention is not limited thereto. The VirtualChannelDescriptionTable Type element includes, as child elements, a VirtualChannelServiceId element, a VirtualChannelServiceVersion element, a VirtualChannelServiceCategory element, a VirtualChannelShrotName element, a ProgrammingSource element, and an RRTParentalGuidance element. Here, the RRTParentalGuidance element includes a ratingRegion attribute, a Dimension element, and a RatingDescriptionText element. In addition, the Dimension element includes a RatingDimension element and a RatingValue element. Hereinafter, each element constituting the VirtualChannelDescriptionTable Type element will be described.

The VirtualChannelServiceId element is the ID of each virtual channel. The ID is used to link the virtual channel map and the EPG entries (Each Virtual Channel has an ID which is used to link to the EPG entries).

The VirtualChannelServiceVersion element is a counter that is incremented when there is a modification to the corresponding instance of the virtual channel description.

The VirtualChannelServiceCategory element is a type of a virtual channel service ((Linear or VOD)) (Type of Virtual Channel Service (Linear or VOD)).

The VirtualChannelShortName element is (Short name (<7 characters) of the Virtual Channel).

The ProgrammingSource element is one or more sources available for virtual channels that are typically differentiated by resolutions (eg HD, SD, PIP) and qualification status (eg Barker) generally differentiated by resolution (eg HD, SD, PIP) and entitlement state (eg Barker)).

The RRTParentalGuidance element defines a type for describing the parental guidance rating according to the structure of a single instance of the rating_region loop in the ATSC content advisory descriptor. In some elements of this type, the ratingRegion value may be set to a ratingValue associated with a ratingDimension in an instance that matches the ratingValue in the RRT, a ratingDimension of each instance that matches a ratingDimension in the RRT, and a regular body or specification applicable to the area of interest. This is consistent with the ratingRegion value of the RRT approved by the ATSC Content Advisory Descriptor [1]. In any element of this type, the ratingRegion value will match the ratingRegion value of a Rating Region Table Approved by the standards and regulatory body applicable to the region of interest, and each ratingDimension of the instance, ratingDimension in the instance will match a ratingValue for the correspon ding dimension in that Rating Region Table).

The Dimension field is a rating for a specific rating dimension.

The RatingDimension element is a code number for a rating level for the dimension corresponding to the rating_value in the ATSC content advisory descriptor. In some RRTParentalGuidance elements, the sub-elements of other dimensions may have different values of the rating dimension attribute (Code number for the dimension, corresponding to the rating_dimension field in the ATSC Content Advisory Descriptor. In any RRTParentalGuidance element, different Dimension sub-elements should have different values of the rating attribute attribute).

The RatingValue element is a code number for the rating level for the dimension corresponding to the corresponding rating_value in the ATSC content advisory descriptor (Code number for the rating level for the dimension, corresponding to the rating_value field in the ATSC Content Advisory Descriptor).

The RatingDescriptionText element is the text description of the overall rating.

The ratingRegion property is the field in which the ATSC Content Advisory Descriptor is applied.

FIG. 30 is a flowchart illustrating a flow of allowing the ITF to set a parental control to a user according to an embodiment of the present invention.

In this case, the ITF can receive and store RRT data as part of the EPG data and use the corresponding data in setting the Parental Control to the user as described above.

The ITF performs network attachment (S3001). Here, the Network Attachment is a procedure in which the ITF establishes a layer 3 layer connection with the IP network and acquires network configuration data. Step S3001 is performed in the Ethernet network interface 2010 and the IP network stack 2015, for example.

The ITF performs a service provider discovery to obtain a service provider discovery record and receives service provider lists (SP lists) in the obtained service provider discovery record (S3002). Here, the ITF may implement the Service Provider Discovery described above with reference to FIG. Step S3002 is performed in the Ethernet network interface 2010 and the IP network stack 2015 or is performed in the SI handler 2025 and the decoder 2040, for example.

The ITF selects a service provider (SP) from the received service provider lists. Then, an authentication procedure is performed with the selected service provider SP (S3003). Step S3003 is performed in the Ethernet network interface 2010 and the IP network stack 2015, for example.

The ITF can obtain SI data and EPG data using the information contained in the acquired service provider discovery record. Here, the ITF may perform the service provider registration (Service Provider Registration) and the service discovery (Service Discovery) described above in FIG. 4 to acquire the SI metadata. The ITF performs a service provider registration, the ITF receives a registration output record (S3004), and performs a service discovery (Service Discovery) based on the information included in the obtained registration output record (ITF Regulation Output Record) ). &Lt; / RTI &gt;

The ITF can then perform service discovery to obtain a master SI table record, a channel map record, and a channel details record. The SI metadata can be calculated from the information contained in the channel map record and the channel detail record.

The ITF finds location information for the EPG server that can obtain the EPG metadata based on the information included in the EPGDiscoveryLocation in the registration output record (S3005). Steps S3004 and S3005 are performed in the file handler 2020, the SI handler 2025, and the decoder 2040, for example.

The EPG server is accessed based on the location information found in the above (S3006). Step S3006 is performed in, for example, the Ethernet network interface 2010 and the IP network stack 2015 or is performed in the SI handler 2025 and the decoder 2040. [

The ITF receives EPG metadata different from the RRT from the accessed EPG server (S3007). Step S3007 is performed, for example, in the file handler 2020 in Fig.

The ITF parses the received RRT and stores the parsed rating system in the RRT (S3008). Step S3008 is performed in the EPG handler 2030, the decoder 2045, and the storage unit 2035, for example.

When a request for parental control is received from the user, the ITF appropriately performs parental control on the virtual channel according to the stored rating system (S3009). Step S3009 is performed in the application manager 2060, the ITF operation controller 2050, and the storage unit 2035, for example.

31 is a flowchart illustrating a method for determining whether to provide access and guide information for a corresponding virtual channel by using Parental Control information included in the SI data and the Parental Control setting that the user has already set in the ITF according to an embodiment of the present invention Fig.

Hereinafter, steps S3101 to S3103 of FIG. 31, which are the same as those of FIG. 30, will be referred to in the above-described steps S3001 to S3003 of FIG. 30, and step S3103 will be described later.

In step S3103, the ITF searches location information of the SI tables by outputting authorization / registration (S3104). The virtual channel description table is received and parsed using the location information of the found SI tables (S3105).

The ITF parses the RRTParentalGuidance element included in the parsed Virtual Channel Description Table (S3106). The ITF parses a RatingValue element including a RatingDimension element including one or more Rating Dimension applied to the corresponding virtual channel and a Rating Value element corresponding to the Rating Dimension element according to the parsed and analyzed RRTParentalGuidance element information S3107). Steps S3104 to S3107 are performed in the file handler 2020, the SI handler 2025, and the decoder 2040, for example.

In step S3107, the ITF determines whether to block the virtual channel based on the value of the parsed RatingDimension element and the RatingValue element, that is, at least one Rating Dimension for the virtual channel and a Rating Value according to each Rating Dimension . Hereinafter, the process will be described in more detail.

First, the ITF determines whether a Graduated scale is applied to the Rating Dimension extracted from the parsed field (S3108).

If it is determined in step S3108 that the gravity scale is not applied to the rating dimension, the ITF determines whether there is a user setting for parental control in the rating dimension and the corresponding rating value in step S3109. As a result of the determination in step S3109, if there is no such user setting, the ITF does not block the corresponding virtual channel (S3110), and determines whether another rating dimension exists (S3114). If it is determined in step S3114 that there is no more rating dimension, the ITF terminates the procedure. However, if it is determined in step S3114 that there is more rating dimension, the ITF will step sequentially from step S3107. In this case, the ITF does not block the corresponding virtual channel in step S3110, which means that the ITF consumes the IPTV service through the corresponding virtual channel or displays the guide information for the corresponding virtual channel.

However, if there is a user's setting as a result of the determination in step S3109, the ITF blocks the corresponding virtual channel (S3113).

If it is determined in step S3108 that the Graduated scale is applied to the corresponding rating dimension, the ITF determines whether the Rating value (first rating value) according to the user's setting for Parental Control and the Rating value (Second rating value) (S3111).

The ITF determines whether the second rating value is greater than or equal to the first rating value according to the setting of the user (S3112). If the second rating value is greater than or equal to the first rating value, the ITF blocks the corresponding virtual channel (S3113). However, if the second rating value is less than the first rating value, the corresponding virtual channel is not blocked (S3110). Then, the ITF determines whether there is another dimension after determining that the corresponding virtual channel is not blocked or blocked (S3114).

In the above, when the corresponding virtual channel is blocked, the ITF restricts the access to the corresponding virtual channel by the user and restricts the provision of the guide information on the EPG for the virtual channel.

FIGS. 32 to 34 illustrate examples of an EPG screen of an ITF including rating information using a rating system defined in the RRT according to the present invention.

32 is an example of an EPG screen on the assumption that no parental control by the user is set. Referring to FIG. 32, in case of 99-1 channel (adult service), contents having an R rating value are provided in time order. For example, in the EPG providing screen, Hustler contents are provided at Playboy weekly from 12:00 to 13:00, Basic Instinct at 13:00 to 14:00, and Hustler contents at 14:00 to 15:00, In particular, since R rating value is not set as Parental Control, each content of 99-1 channel will not be blocked.

FIG. 33 shows an embodiment in which a user sets Parental Control (applied as a TV-14 class) to the ITF using EPG data, and EPG screen is also blocked according to the rating of Schedule / Content. Referring to FIG. 33, contents provided at 12:00 to 13:30 of the 32-1 (Fox-1 service) channel and time at 12:00 to 15:00 through the 99-1 (ADULT service) The three contents provided in units are blocked according to the setting of the user.

FIG. 34 shows an embodiment in which an EPG screen for a virtual channel is blocked according to a user's parental control setting (applied as a TV-14 class) using the SI data proposed in the present invention. In the case of FIG. 34, it is assumed that a block for Schedule / Content is also used in parallel with the EPG screen block for the virtual channel using EPG data. In the case of FIG. 33, each content blocks according to the user's setting. In the case of FIG. 34 according to an embodiment of the present invention, the virtual channel itself is blocked. At the same time, EPG data is also blocked.

Therefore, according to the present invention, the ITF can perform parental control for each virtual channel using the Parental Control information included in the SI data, thereby providing a more secure IPTV service.

It is to be understood that the terminology used herein is for the purpose of description and should not be interpreted as limiting the scope of the present invention. It should be based on the contents.

It is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory only and are not restrictive of the invention, It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention.

1 is a system configuration diagram showing the concept of an IPTV service,

Figure 2 is a schematic representation of a multicast scheme,

3 schematically illustrates a unicast scheme, Fig.

4 is a flowchart illustrating a method of searching for an IPTV service according to an exemplary embodiment of the present invention.

FIG. 5 is a diagram illustrating a schema of a service provider discovery type according to an embodiment of the present invention.

FIG. 6 is a diagram illustrating a schema of an ITF registration input type according to an embodiment of the present invention; FIG.

FIG. 7 is a diagram illustrating a schema of an ITF Regulation Output Type according to an embodiment of the present invention.

8 is a diagram showing a relationship between respective tables constituting service information (SI) according to the present invention;

FIG. 9 is a diagram illustrating a schema of a master SI table record type according to an embodiment of the present invention;

10 is a diagram illustrating a schema of a channel map type according to an embodiment of the present invention.

FIG. 11 illustrates a schema of a channel map type according to another embodiment of the present invention; FIG.

12A and 12B are diagrams illustrating a schema of a channel detail type according to an embodiment of the present invention,

13 is a flowchart illustrating a process of performing a service provider discovery according to an embodiment of the present invention.

FIG. 14 is a flowchart illustrating a process of performing a service provider registration (Service Provider Registration) and a service discovery (Service Discovery) according to an embodiment of the present invention;

FIG. 15 is a flowchart illustrating a process of performing a method of processing an update of a master SI table according to an embodiment of the present invention; FIG.

16 is a flowchart showing a process of performing a method of processing an update of a master SI table according to another embodiment of the present invention;

17 is a flowchart illustrating a process of performing a method of processing an update of a Channel Details Version according to an embodiment of the present invention.

18 is a flowchart showing a process of performing a method of processing an update of a channel detail version according to another embodiment of the present invention;

FIG. 19 is a diagram illustrating a schema of an EPG Discovery Record Type according to an embodiment of the present invention;

20 is a block diagram showing the configuration of an ITTV (IPTV Terminal Function) according to an embodiment of the present invention.

FIG. 21 is a flowchart illustrating a process of performing a virtual channel setting method according to an embodiment of the present invention. FIG.

22 is a diagram illustrating the allocation of Rating Region values of the RRT defined in ATSC A / 65C and EIA-766A in connection with the present invention,

23 shows, in the context of the present invention, What is shown to illustrate the Rating Region Table System,

24 is a diagram showing a correlation between SI data and EPG data in an IPTV system according to an embodiment of the present invention;

FIG. 25 is a diagram showing a schema of a Rating Region Table (RRT), which is contents parental guidance rating information, which is received by the ITF as a part of EPG data in the IPTV system according to the present invention,

FIG. 26 is a diagram showing the schema of FIG. 25 in XML form,

27 is a diagram illustrating a schema structure of SI data and Virtual Channel Descriptions Table including Parental Control information according to an embodiment of the present invention,

FIG. 28 shows a schema structure of the VirtualChannelDescription Table in XML format in FIG. 27,

FIG. 29 is a diagram showing the schema structure of the RRTParentalGuidance element in XML form in FIG. 27,

FIG. 30 is a flowchart showing a flow of allowing the ITF to set a parental control to a user according to an embodiment of the present invention;

31 is a flowchart illustrating a method for determining whether to provide access and guide information for a corresponding virtual channel by using Parental Control information included in the SI data and the Parental Control setting that the user has already set in the ITF according to an embodiment of the present invention Fig.

FIGS. 32 to 34 illustrate examples of an EPG screen of an ITF including rating information using a rating system defined in the RRT according to the present invention.

Claims (15)

Receiving a master service information (SI) table including a first element defining a location of a virtual channel map table; Parsing a first element included in the received master service information table; Receiving the virtual channel map table including a second element that defines a location of a virtual channel description table based on the parsed location element; Parsing the second element in the received virtual channel map table; Receiving the virtual channel description table including a third element indicating a default parental guidance rating of a virtual channel service based on the parsed second element; Parsing the third element in the received virtual channel description table; And And controlling the ranking based on the type of the paired prioral guidance system according to the parsed third element. The method according to claim 1, In the parental control method of the channel, And receiving program guide metadata for providing descriptive information about the content. 3. The method of claim 2, Wherein the third element comprises a ranking descriptive text element comprising attribute information of a rating region, dimension elements defining a dimension, and information describing a rating. The method of claim 3, Wherein the dimension element comprises a rating dimension element that identifies a rating dimension and a rating value element that identifies a rating value. 3. The method of claim 2, Wherein the technical information includes information defining a rating region table (RRT). 6. The method of claim 5, Wherein the RRT comprises rating information text attribute elements including rating information attributes, dimension elements defining dimensions, and rating describing information. The method according to claim 6, Wherein the dimension element comprises a rating value element that identifies a rating dimension and a rating value element that identifies a rating value. 3. The method of claim 2, A possible value of the third element is the same as the element of the same name as the service fragment of the program guide metadata for the service. The method according to claim 1, And the third element is an RRT parental guidance element. The method according to claim 1, Wherein the master service information (SI) table further includes version information of the virtual channel map table. An IP network stack for receiving IP stream data including service information (SI) data and program guide data; A file handler for demultiplexing SI data and program guide data included in the received IP stream; A service information (SI) handler for demultiplexing a virtual channel description table including a master SI table, a virtual channel map table, and a first element indicating that there is a default pair real-time rating of a virtual channel service; A program guide handler for demultiplexing a rating region table (RRT) including a second element indicating that a default parental guidance rating of a virtual channel service is present in the demultiplexed program guide data, ; A service information (SI) decoder for parsing the first element from the demultiplexed virtual channel description table; A program guide parser for parsing the first element from the demultiplexed RRT; And And a controller for applying and controlling a rating based on the type of the paired landing guidance system according to the parsed first and second elements. 12. The method of claim 11, The value of the third element is the same as each element of the same name in the service fragment of the program guide metadata for the service. 12. The method of claim 11, And the control unit controls to display a program guide screen based on the parsed second element. 14. The method of claim 13, The IPTV receiver stores a demultiplexed mast SI table, a virtual channel map table, a virtual channel description table, and an RRT. 15. The method of claim 14, Wherein the IPTV receiver further comprises a display unit for displaying the program guide screen and the virtual channel service.

Images