Language selection

Search

Patent 2645878 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2645878
(54) English Title: A METHOD OF PERFORMING PARENTAL CONTROL IN AN IPTV RECEIVER AND AN IPTV RECEIVER FOR PERFORMING PARENTAL CONTROL
(54) French Title: METHODE DE REALISATION D'UN LOGICIEL DE FILTRAGE DE CANAL, ET TELEVISEUR SUR IP
Status: Granted
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04N 21/454 (2011.01)
  • H04H 40/18 (2009.01)
  • H04H 60/72 (2009.01)
  • H04N 21/462 (2011.01)
  • H04L 29/06 (2006.01)
(72) Inventors :
  • SONG, JAE HYUNG (Republic of Korea)
  • LEE, JOON HUI (Republic of Korea)
  • THOMAS, GOMER (United States of America)
(73) Owners :
  • LG ELECTRONICS INC. (Republic of Korea)
(71) Applicants :
  • LG ELECTRONICS INC. (Republic of Korea)
(74) Agent: SMART & BIGGAR LP
(74) Associate agent:
(45) Issued: 2014-09-02
(22) Filed Date: 2008-12-05
(41) Open to Public Inspection: 2009-06-05
Examination requested: 2008-12-05
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
60/992,676 United States of America 2007-12-05
61/053,016 United States of America 2008-05-13

Abstracts

English Abstract

A method for performing parental control a channel for building a channel map in an internet protocol television (IPTV) receiver and the IPTV receiver thereof are provided. The method includes receiving a master service information (SI) table including a first element defining location of a virtual channel map table, parsing the first element in the received master SI table, receiving the virtual channel map table including a second element defining 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, which includes a third element indicating a default parental guidance rating of a virtual channel service when present, based on the parsed second element, parsing the third element in the received virtual channel description table, and controlling to allow ratings based on the type of parental guidance system according to the parsed third element.


French Abstract

Procédé permettant la réalisation d'un contrôle parental, un canal pour établir une correspondance de canaux dans un récepteur de télévision sur protocole Internet (IPTV) et un récepteur TV IP. Le procédé comprend la réception d'un tableau d'information de service (SI) principal composé d'un premier élément définissant l'emplacement d'un tableau de correspondance de canaux virtuels, l'analyse du premier élément dans le tableau d'information de service principal reçu, la réception du tableau de correspondance de canaux virtuels, y compris un deuxième élément définissant l'emplacement d'un tableau de description de canaux virtuels fondé sur l'élément d'emplacement analysé, l'analyse du deuxième élément dans le tableau de correspondance de canaux virtuels reçu, la réception du tableau de description de canaux virtuels, qui comprend un troisième élément indiquant une valeur de surveillance parentale par défaut d'un service de canaux virtuels, le cas échéant, en fonction du deuxième élément analysé, l'analyse du troisième élément dans le tableau de description de canaux virtuels reçu, et la gestion des cotes d'évaluation en fonction du type de système de contrôle parental selon le troisième élément analysé.

Claims

Note: Claims are shown in the official language in which they were submitted.


CLAIMS:
1. A method of performing parental control in an
internet protocol television (IPTV) receiver, the method
comprising:
performing a service discovery procedure with a
service provider, wherein the service discovery procedure
comprises:
receiving, from the service provider, a master
service information (SI) table including a first element
defining location of a virtual channel map table,
parsing the first element in the received master SI
table,
receiving, from the service provider, the virtual
channel map table including a second element defining location
of a virtual channel description table based on the parsed
first element,
parsing the second element in the received virtual
channel map table,
receiving, from the service provider, the virtual
channel description table, which includes a third element
including a first parental guidance of a virtual channel, based
on the parsed second element, wherein the first parental
guidance includes a code number for a dimension of the virtual
channel and a code number for a rating level for the dimension
of the virtual channel, and
parsing the third element in the received virtual
channel description table;

86

performing an electronic program guide (EPG)
reception procedure with an EPG server, wherein the EPG
reception procedure comprises:
receiving, from the EPG server, an electronic program
guide (EPG) metadata including both a rating region table and a
second parental guidance of a broadcast program, wherein the
rating region table defines allowable rating dimensions and
allowable rating levels for a parental guidance system, and the
second parental guidance includes a code number for a dimension
of the broadcast program and a code number for a rating level
for the dimension of the broadcast program;
performing parental controls on the virtual channel
based on the first parental guidance; and
performing parental controls on the broadcast program
based on the second parental guidance.
2. The method of claim 1,
wherein the virtual channel corresponds to a virtual
channel service ID in the virtual channel description table,
and
wherein information on the first parental guidance in
the virtual channel description table and information on the
second parental guidance rating in the EPG metadata are linked
to each other using the virtual channel service ID.
3. The method of claim 2, wherein the first element
further includes attribute information of rating Region, and
rating description text element containing a description of a
rating.

87

4. The method of claim 2, wherein the rating region
table further includes attribute information of rating Region,
rating description text element containing a description of a
rating.
5. The method of claim 1, wherein allowable values of
the second parental guidance is defined by the rating region
table, and
allowable values of the first parental guidance is
defined by the rating region table.
6. The method of claim 1, wherein the master SI table
further includes version information of the virtual channel map
table.
7. An internet protocol television (IPTV) receiver for
performing parental control, comprising:
an IP network stack for receiving an IP stream
including service information (SI) data and electronic program
guide (EPG) metadata, wherein the SI data is received from the
service provider through a service discovery procedure, and the
EPG metadata is received from the EPG server through an EPG
reception procedure;
a file handler for demultiplexing the SI data and EPG
metadata in the received IP stream;
an SI handler for demultiplexing a master SI table, a
virtual channel map table, and a virtual channel description
table in the demultiplexed SI data, wherein the demultiplexed
virtual channel description table includes a first element
including a first parental guidance of a virtual channel, and

88

the first parental guidance includes a code number for a
dimension of the virtual channel and a code number for a rating
level for the dimension of the virtual channel;
an EPG handler for demultiplexing content information
in the demultiplexed EPG metadata, wherein the demultiplexed
content information includes both a rating region table and a
second parental guidance of a broadcast program, wherein the
rating region table defines allowable rating dimensions and
allowable rating levels for a parental guidance system, and the
second parental guidance includes a code number for a dimension
of the broadcast program and a code number for a rating level
for the dimension of the broadcast program;
an SI decoder for parsing the first parental guidance
from the demultiplexed virtual channel description table;
an EPG decoder for parsing the second parental
guidance from the demultiplexed content information; and
a controller for performing parental controls on the
virtual channel based on the first parental guidance and
performing parental controls on the broadcast program based on
the second parental guidance,
wherein allowable values of the second parental
guidance is defined by the rating region table, and
allowable values of the first parental guidance is
defined by the rating region table.
8. The IPTV receiver of claim 7, wherein allowable
values of the second parental guidance are defined by the
rating region table, and

89

allowable values of the first parental guidance are defined by
the rating region table.
9. The IPTV receiver of claim 7, wherein the controller
controls to building an EPG screen based on the parsed second
parental guidance.
10. The IPTV receiver of claim 9, further comprising:
a storage unit for storing the demultiplexed master
SI table, virtual channel map table, virtual channel
description table, and RRT.
11. The IPTV receiver of claim 10, further comprising:
a display unit for displaying the virtual channel and
the built EPG screen.


Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02645878 2012-08-23
50514-47
AMETHODOFPERFORMINGPARENTALCONTROLINANIPTVRECEIVER
ANDANIPTVRECEIVERFORPERFORMINGPARENTALCONTROL
[0001]
BACKGROUND OF THE INVENTION
Field of the Invention
[0002] The present invention relates to a method of
performing parental control a channel and an IPTV receiver,
and more particularly, to an IPTV receiver and a method for
discovering an IPTV service using an Internet protocol.
Discussion of the Related Art
[0003] An
example of provision of a content service using
an Internet network includes an Internet protocol TV (IPTV)
system. The
IPTV system transmits various types of
information services, moving image contents and broadcasts to
a receiver of a user using the Internet network. The
Internet network can be implemented over various types of
networks such as an optical cable network, a coaxial cable
network, fiber to the home, a telephone network and a
wireless network based on the Internet protocol (IP). '
Broadcasting environments were divided according to
terrestrial, cable and satellite, but have been gradually
1

CA 02645878 2013-08-30
,
50514-47
integrated. In such a process, recently, the IPTV
environments for providing a service based on the IP are
created and standards related thereto have been made.
[0004] Although the IPTV environments are created, the
service should be still provided based on the channel. That
is, a method for managing a channel for providing a service
in IPTV environments has significance.
[0005] However, since the method for managing the channel
is incomplete in the related standards which have been made
up to now, it leads to confusion of a user and a
manufacturer of a receiver terminal.
SUMMARY OF THE INVENTION
[0006] Some embodiments of the present invention may
provide a method of performing parental control in an IPTV
receiver that substantially obviate one or more problems due
to limitations and disadvantages of the related art.
[0006a] According to an aspect of the present invention,
there is provided a method of performing parental control in an
internet protocol television (IPTV) receiver, the method
comprising: performing a service discovery procedure with a
service provider, wherein the service discovery procedure
comprises: receiving, from the service provider, a master
service information (SI) table including a first element
defining location of a virtual channel map table, parsing the
first element in the received master SI table, receiving, from
2

CA 02645878 2013-08-30
50514-47
the service provider, the virtual channel map table including a
second element defining location of a virtual channel
description table based on the parsed first element, parsing
the second element in the received virtual channel map table,
receiving, from the service provider, the virtual channel
description table, which includes a third element including a
first parental guidance of a virtual channel, based on the
parsed second element, wherein the first parental guidance
includes a code number for a dimension of the virtual channel
and a code number for a rating level for the dimension of the
virtual channel, and parsing the third element in the received
virtual channel description table; performing an EPG reception
procedure with an EPG server, wherein the EPG reception
procedure comprises: receiving, from the EPG server, an
electronic program guide (EPG) metadata including both a rating
region table and a second parental guidance of a broadcast
program, wherein the rating region table defines allowable
rating dimensions and allowable rating levels for a parental
guidance system, and the second parental guidance includes a
code number for a dimension of the broadcast program and a code
number for a rating level for the dimension of the broadcast
program; performing parental controls on the virtual channel
based on the first parental guidance; and performing parental
controls on the broadcast program based on the second parental
guidance.
(0006b]
According to another aspect of the present invention,
there is provided an internet protocol television (IPTV)
receiver for performing parental control, comprising: an IP
network stack for receiving an IP stream including service
information (SI) data and electronic program guide (EPG)
metadata, wherein the SI data is received from the service
3

CA 02645878 2013-08-30
50514-47
provider through a service discovery procedure, and the EPG
metadata is received from the EPG server through an EPG
reception procedure; a file handler for demultiplexing the SI
data and EPG metadata in the received IP stream; an SI handler
for demultiplexing a master SI table, a virtual channel map
table, and a virtual channel description table in the
demultiplexed SI data, wherein the demultiplexed virtual
channel description table includes a first element including a
first parental guidance of a virtual channel, and the first
parental guidance includes a code number for a dimension of the
virtual channel and a code number for a rating level for the
dimension of the virtual channel; an EPG handler for
demultiplexing content information in the demultiplexed EPG
metadata, wherein the demultiplexed content information
includes both a rating region table and a second parental
guidance of a broadcast program, wherein the rating region
table defines allowable rating dimensions and allowable rating
levels for a parental guidance system, and the second parental
guidance includes a code number for a dimension of the
broadcast program and a code number for a rating level for the
dimension of the broadcast program; an SI decoder for parsing
the first parental guidance from the demultiplexed virtual
channel description table; an EPG decoder for parsing the
second parental guidance from the demultiplexed content
information; and a controller for performing parental controls
on the virtual channel based on the first parental guidance and
performing parental controls on the broadcast program based on
the second parental guidance, wherein allowable values of the
second parental guidance is defined by the rating region table,
and allowable values of the first parental guidance is defined
by the rating region table.
4

CA 02645878 2013-08-30
. .
50514-47
[0007] Some embodiments may provide a method of
performing parental control in an IPTV receiver, by which an
IPTV receiver, and more particularly, an ITF (IPTV terminal
function) is enabled to efficiently set channels.
5 [0008] Some embodiments may provide a method of
performing parental control in an IPTV receiver, by which an
IPTV receiver, and more particularly, and ITF (IPTV terminal
function) is enabled to perform a parental control on each
virtual channel.
10 [0009] Some embodiments may provide a method of
performing parental control in an IPTV receiver, by which a
parental control can be performed on each virtual channel.
[0010] Some embodiments may provide a method of
performing parental control in an IPTV receiver, by which an
15 ITF (IPTV terminal function) is enabled to determine whether
to access each virtual channel and whether to provide guide
information on the corresponding virtual channel.
[0011] Additional advantages, objects, and features of
some embodiments of the invention will be set forth in part
20 in the description which follows and in part will become
apparent to those having ordinary skill in the art upon
examination of the following or may be learned from practice
of the invention. The objectives and other advantages of
some embodiments of the invention may be realized and
25 attained by the structure particularly pointed out in the

CA 02645878 2013-08-30
,
50514-47
written description and claims hereof as well as the
appended drawings.
[0012] According to another aspect, there is provided a
method of performing parental control in an internet
protocol television (IPTV) receiver, the method comprising:
receiving a master service information (SI) table including
a first element defining location of a virtual channel map
table; parsing the first element in the received master SI
table; receiving the virtual channel map table including a
second element defining 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,
which includes a third element indicating a default parental
guidance rating of a virtual channel service when present,
based on the parsed second element; parsing the third
element in the received virtual channel description table;
and controlling display of the virtual channel service based
on the type of parental guidance system according to the
parsed third element.
[0013] In some embodiments, the method further includes
receiving an electronic program guide (EPG) metadata
providing descriptive information of contents.
[0014] In some embodiments, the third element includes
attribute information of rating Region, a dimension element
6

CA 02645878 2013-08-30
50514-47
defining a dimension, and rating description text element
containing a description of a rating.
[0015] In some embodiments, the dimension element
includes a rating dimension element identifying a rating
dimension and rating value element identifying rating value.
[0016] In some embodiments, the descriptive information
includes information defining rating region table (RRT).
[0017] In some embodiments, the RRT includes attribute
information of rating Region, a dimension element defining a
dimension, and rating description text element containing a
description of a rating.
[0018] In some embodiments, the dimension element
includes a rating dimension element identifying a rating
dimension and rating value element identifying rating value.
[0019] In some embodiments, allowable values of the third
element are identical to each element of same name in a
service fragment of the EPG metadata for a service.
[0020] In some embodiments, the third element is RRT
Parental Guidance element.
[0021] In some embodiments, the master SI table further
includes version information of the virtual channel map
table.
7

CA 02645878 2013-08-30
50514-47
[0022] According to another aspect, there is provided an
internet protocol television (IPTV) receiver for performing
parental control, comprising: a receiving unit for
receiving an IP stream including service information (SI)
data and electronic program guide (EPG) data; a first
demultiplexing unit for demultiplexing the SI data and EPG
data in the received IP stream; a second demultiplexing unit
for demultiplexing a master SI table, a virtual channel map
table, and a virtual channel description table in the
demultiplexed SI data, wherein the demultiplexed virtual
channel description table includes a first element
indicating a default parental guidance rating of a virtual
channel service when present; a third demultiplexing unit
for demultiplexing a rating region table (RRT) in the
demultiplexed EPG data, wherein the demultiplexed RRT
includes a second element indicating a default parental
guidance rating of a virtual channel service when present; a
SI decoder for parsing the first element from the
demultiplexed virtual channel description table; an EPG
decoder for parsing the second element from the
demultiplexed RRT; and a controller for controlling display
of the virtual channel service based on the type of parental
guidance system according to the parsed first element and
second element.
[0023] In some embodiments, allowable values of the third
element are identical to each element of same name in a
service fragment of the EPG metadata for a service.
7a

CA 02645878 2013-08-30
50514-47
[0024] In some embodiments, the controller controls to
building an EPG screen based on the parsed second element.
[0025] In some embodiments, the IPTV receiver further
includes a storage unit for storing the demultiplexed master
SI table, virtual channel map table, virtual channel
description table, and RRT.
[0026] In some embodiments, the IPTV receiver further
includes a display unit for displaying the virtual channel
service and the builded EPG screen.
[0027] It is to be understood that both the foregoing
general description and the following detailed description
of the present invention are exemplary and explanatory and
are
7b

CA 02645878 2008-12-05
intended to provide further explanation of the invention as
claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0028] The accompanying drawings, which are included to
provide a further understanding of the invention and are
incorporated in and constitute a part of this application,
illustrate embodiment(s) of the invention and together with
the description serve to explain the principle of the
invention. In the drawings:
[0029] FIG. 1 illustrates a configuration of an IPTV
system for providing IPTV services;
[0030] FIG. 2 schematically illustrates a multicast
scheme;
[0031] FIG. 3 schematically illustrates a unicast scheme;
[0032] FIG. 4 illustrates a procedure of a preferred
embodiment of a method for discovering an IPTV service
according to the present invention;
[0033] FIG. 5 illustrates a schema of a preferred
embodiment of a service provider discovery type according to
the present invention;
[0034] FIG. 6 illustrates a schema of a preferred
embodiment of an ITF registration input type according to the
present invention;
8

CA 02645878 2008-12-05
[0035] FIG. 7 illustrates a schema of a preferred
embodiment of an ITF registration output type according to
the present invention;
[0036] FIG. 8 illustrates relations between tables
included in service information (SI);
[0037] FIG. 9 illustrates a schema of a preferred
embodiment of a master SI table record type;
[0038] FIG. 10 illustrates a schema of a preferred
embodiment of a channel map type;
[0039] FIG. 11 illustrates a schema of another preferred
embodiment of a channel map type;
[0040] FIGs. 12A and 128 illustrate schemas of another
preferred embodiment of a channel details type;
[0041] FIG. 13 is a flow chart illustrating a procedure of
a preferred embodiment of service provider discovery
according to the present invention;
[0042] FIG. 14 is a flow chart illustrating a procedure of
a preferred embodiment of service provider registration and
service discovery according to the present invention;
[0043] FIG. 15 is a flow chart illustrating a procedure of
a preferred embodiment of a method for performing update of a
master SI table;
[0044] FIG. 16 is a flow chart illustrating a procedure of
another preferred embodiment of a method for performing
update of a master SI table;
9

CA 02645878 2013-08-30
50514-47
[0045] FIG. 17 is a flow chart illustrating a procedure of
a preferred embodiment of a method for performing update of a
channel details version;
[0046] FIG. 18 is a flow chart illustrating a procedure of
another preferred embodiment of a method for performing
update of a channel details version;
[0047] FIG. 19 illustrates a schema of a preferred
embodiment of an EPG discovery record type according to the
present invention;
[0048] FIG. 20 is a block diagram illustrating a
configuration of a preferred embodiment of an IPTV Terminal
Function (ITF) according to the present invention; and
[0049] FIG. 21 is a flow chart illustrating a procedure of
a preferred embodiment of a virtual channel setting method
according to the present invention.
[0050] FIG. 22 is a diagram of RRT defined in ATSC A/65C
and EIA-766A for explaining rating region value allocation.
[0051] FIG. 23 is a diagram for U.S. rating region table
system.
[0052] FIG. 24 is a diagram for correlation between SI
data and EPG data in IPTV system according to one embodiment
of the present invention.
[0053] FIG. 25 is a diagram of RatingRegionTableType
schema for receiving ITF as a part of EPG data in IPTV system
according to an embodiment of the present invention,

CA 02645878 2013-08-30
50514-47
[0054] FIG. 26 is a diagram of the XML schema shown in FIG.
25.
[0055] FIG. 27 is a diagram of a schema structure of SI
data including parental control information and
VirtualChannelDescriptionTable according to one embodiment of
the present invention,
[0056] FIG. 28 is a diagram of XML schema of the
VirtualChannelDescriptionTable shown in FIG. 28,
[0057] FIG. 29 is a diagram of XML schema of
RRTParentalGuidance element in FIG. 27.
[0058] FIG. 30 is a flowchart for an ITF to enable a user
to set a parental control according to one embodiment of the
present invention.
[0059] FIG. 31 is a flowchart for an ITF to determine
whether to access a predetermined virtual channel and whether
to provide guide information on the corresponding virtual
channel using parental control information received by being
included in SI data and the parental control setup previously
set in the ITF by a user according to an embodiment of the
present invention.
[0060] FIGs. 32 to 34 are diagrams for EPG pictures of ITF
including rating information using a rating system defined in
RRT according to embodiments of the present invention,
respectively.
11

CA 02645878 2013-08-30
50514-47
DETAILED DESCRIPTION OF EMBODIMENTS
[0061] Preferred embodiments of the invention will now be
described with reference to the accompanying drawings. The
configuration and operation of the invention, illustrated in
the drawings and described below with reference to the
drawings, will be described using at least one embodiment
without limiting the essential configuration and operation of
the invention.
[0062] Although most terms of elements in the present
invention have been selected from general ones widely used in
the art taking into consideration their functions in the
invention, the terms may be changed depending on the
intention or convention of those skilled in the art or the
introduction of new technology. Some terms have been
arbitrarily selected by the applicant and their meanings are
explained in detail in the following description as needed.
Thus, the definitions of the terms used in the invention
should be determined based on the whole content of this
specification together with the intended meanin4s of the
terms rather than their simple names or meanings.
[0063] FIG. 1 illustrates a configuration of an IPTV
system for providing IPTV services.
12

CA 02645878 2008-12-05
[0064] As shown
in FIG. 1, the IPTV system includes a
service provider domain, a network provider domain, and a
customer domain.
[0065] The
service provider domain may include a content
provider and a service provider. The content provider serves
to provide content to the service provider. The
service
provider serves to provide services to subscribers, and
collects a variety of content and converts content signals
according to an IP environment and transfers the converted
signals to users (or customers). The service provider also
transmits multimedia data and performs maintenance, repair,
and management of a transmission network to enable users to
reliably receive content and provides functions and
facilities to enable the content provider to transmit data
over the network. Here, the
service provider may be a
virtual entity and the content provider may also serve as the
service provider.
[0066] The
network provider domain serves to connect users
and the service provider through an IP network. The
transmission system may use a variety of networks such as an
access network, a backbone network, or a wireless Wide Area
Network (WAN).
[0067] The
customer domain is a domain which consumes IPTV
services. The
customer domain serves to reproduce data
received using facilities such as xDSL or cable or to
13

CA 02645878 2008-12-05
immediately reply to a request made by a user. The customer
domain mostly includes companies which produce IPTV-related
devices, the types of which can be divided into IPTVs, IP
STBs, IP phones, etc. In the
customer domain, a customer
domain apparatus may be used to receive and display a
broadcast containing content provided by the content provider.
Examples of the customer domain apparatus include a set-top
box, a PC, a mobile terminal, an IPTV Terminal Function (ITF)
device, or a Delivery Network Gateway (DNG) device.
[0068] The
following is a more detailed description of
each of the domains.
[0069] The
content provider may be a TV station or a radio
station that produces broadcast programs. The TV station is
a conventional terrestrial or cable broadcast station. The
broadcast station produces and stores programs that can be
viewed by users and can convert the programs to digital
signals for transmission. The purpose of converting programs
into digital signals is to enable transmission of various
types of broadcasts.
[0070] The radio station is a general radio broadcast
station and is operated without video channels in most cases
although it may provide video channels in some cases. Video
on Demand (VoD) and Audio on Demand (AoD) services have
different characteristics from those of the TV station or the
radio station. The content provider generally provides live
14

- - .
CA 02645878 2008-12-05
broadcast programs such that users cannot rewind or pause and
view the programs unless they record the programs. However,
in the case of VoD or AoD services, the service provider
stores broadcast programs or movies or music and then
provides them to users such that the users can reproduce and
view desired broadcast programs or movies or music when they
desire to view. For example, when a customer cannot view a
broadcast program due to lack of time, they can, at a later
time, access a site that provides such a broadcast service
and download or immediately reproduce a corresponding file.
Similarly, when a customer cannot listen to an audio program
due to lack of time, they can, at a later time, access a site
that provides such an audio service and download or
immediately reproduce a corresponding file. Music on Demand
(MoD) services allow customers to download and listen to
desired music. Music companies or distributers can provide
such MoD services by extending existing web services.
[0071] Reference will now be made to embodiments of
services provided by the content provider.
[0072] A PF
service can be provided by a company that
manages all broadcast information and location information
provided by the content provider. This
service mainly
contains broadcast time information of a corresponding
broadcast station or location information required for
broadcasting and information which enables users (or

CA 02645878 2008-12-05
customers) to access the broadcast station. Customers
can
obtain and display such information on the screen. The PF
service should be provided by each broadcast station. In
IPTV environments, the PF service is provided to allow
customers to access the corresponding broadcast station.
[0073] The EPG
service is a convenient service that allows
customers to check broadcast programs for each time zone and
for each channel. A program that provides the EPG service is
previously installed automatically on a customer device so
that it is executed when requested. While the customer can
obtain information of the corresponding broadcast station
from the PF service, they can use the EPG service more
conveniently since they can collectively obtain information
of real-time broadcast channels of all broadcast stations
using the EPG service. For
example, since the IPTV has
useful functions, for example a function to schedule
recording of a program such as CNN news and a function to
schedule viewing of a broadcast such as a Disney broadcast,
the EPG service should provide detailed information of
broadcast programs of a corresponding region for each time
zone. Certain drama-related EPG is designed to allow search
of the contents of the drama and to allow classification of
programs into categories such as science fiction, drama, and
animation. The EPG may also contain detailed information of
story or characters of a drama or movie of a simple broadcast
16
. .

_
CA 02645878 2008-12-05
program. One major challenge of the EPG service is how to
transmit EPG data suitable for the customer since there are a
lot of types of customer licenses for IPTV viewing. To
access the EPG service, the customer only needs to locate and
press an input key on a remote controller.
[0074] An
Electronic Content Guide (ECG) service provides
a variety of functions that allow the customer to easily use
information regarding a variety of content provided by the
content provider, the location of a corresponding access
server, the authority to access the server, etc. That is,
the ECG service has a function to allow the customer to
easily access servers that store a variety of content and
serves as an EPG that provides detailed information of the
content. The ECG provides integrated information of services
such as AoD, MoD, and VoD rather than real-time broadcasts,
similar to the EPG to reduce the burden of the customer
having to individually access a content service to view or
download content. Although the ECG service is similar to the
EPG service, the ECG does not provide real-time broadcast
channel information but instead allows the customer to view,
download, and store content at any time since the content is
stored in the server. To access a server that contains each
desired content item, the customer needs to enter an address,
which it is very difficult to type, and to access PF servers.
This is a very complicated procedure requiring a lot of time.,
17
4@=
_______________________________________________________________________________


CA 02645878 2008-12-05
A company that provides the ECG allows the ECG program to be
automatically installed on the customer device and collects
information of all content items and provides corresponding
data. Similar to the EPG service, to access the ECG service,
the customer only needs to click a corresponding input key on
the remote controller.
[0075] A portal
service is a web service provided by each
broadcast station and a portal server that provides such a
portal service is connected to a web server of a company that
provides content services. The
portal service allows the
customer to search or view a list of programs provided by
each broadcast station or by content providers that provide
content services. The
functions of the portal service are
similar to those of the ECG or EPG. However,
since the
portal service also provides functions associated with user
authentication or license contract, it is necessary for the
customer to access the portal service to view a desired
program. While the ECG or EPG service provides an integrated
broadcast or content list, the portal service provides
information of a list of content or broadcasts provided by a
corresponding program provider, thereby enabling detailed
search. To access
the portal service, the customer only
needs to click a portal input key on the remote controller.
[0076] Equipment
of the content provider needs to have
functions to provide such services. To allow these functions
18
_
_______________________________________________________________________________
__

CA 02645878 2008-12-05
to operate normally, a server 130 of each service company
should already be connected to the IP network so that it can
transmit a corresponding program in real time or transmit
broadcast information. Each
broadcast station or service
company should be equipped with a system that is connected to
the network of the service provider to enable transmission of
multimedia data without errors or delay using a real-time
Internet protocol such as RTP, RTSP, RSVP, or MPLS. For
example, to transmit the multimedia data created according to
the MPEG-2 and AC-3 audio specification from a TV studio that
currently provides news data, the corresponding server needs
to transcode the multimedia data into an IPTV format. After
this process, an RTP/UDP protocol including time information
is attached to the multimedia data to implement a caption or
overdub feature and the multimedia data is then transmitted
through the IP network provided by the service provider.
[0077] The
service provider provides the bandwidth and the
stability of the network to allow satisfactory transmission
of multimedia data and/or broadcast data received from the
content provider.
Service providers may provide IPTV
services using the existing cable network. In this case, it
is necessary to change equipment of the delivery network.
That is, it is necessary to construct equipment that can
perform real-time data transmission and to construct a
network for the customer in consideration of the bandwidth.
19
. . PRPIP'
__________________________

CA 02645878 2008-12-05
Such equipment should use a multicast service, which is a
basic network service of the IPTV, to process a large amount
of multimedia data in order to reduce the bandwidth. When
the bandwidth is not secured, the service provider may re-
transcode multimedia broadcast data received from the content
provider or the optical cable network and reconstruct the
data into an MPEG-4 or MPEG-7 format for transmission. To
accomplish this, the service provider should provide some
services which mainly include a Network Management System
(NMS) service, a Dynamic Host Control Protocol (DHCP) service,
and a CDN service.
[0078] The NMS
service provides a function to manage the
delivery network over which the service provider can transmit
data to each customer (or user) and a Remote Configuration
and Management Server (RCMS) function. That is,
when the
customer cannot receive a broadcast since a problem has
occurred in the transmission network, the service provider
should have means for immediately solving the problem. The
NMS is widely used as a standardized means for smoothly
controlling and managing remote transport layer machines.
Using this service, it is possible to determine how much
traffic has occurred for a broadcast and an area where the
bandwidth is insufficient. Also, the service provider should
provide content providers with the NMS service to allow the
content providers to generate and manage multicast groups

CA 02645878 2008-12-05
when providing a multicast service. This is
because the
service provider may need to be able to further generate a
multicast group in some cases.
[0079] The DHCP
service is used to automatically allocate
an IP address to the IPTV receiver of the customer and to
inform the IPTV receiver of the address of the CDN server.
The DHCP service is also used as an appropriate means for
allocating an IP address to a PC in a general network. That
is, it is necessary to transmit an available address to an
IPTV receiver that is authorized to use the server to allow
the customer to perform a registration procedure when
initially accessing the server. Generally, an IPTV receiver
which supports IPv4 also supports IPv6. Thus, an
IPTV
receiver which supports IPv4 can also be used.
[0080] The CDN service is provided as data that the
service provider provides to the IPTV receiver. When the
IPTV receiver is powered on to start operation, the IPTV
receiver receives CDN information from the service provider
while receiving IP information through the DHCP service. The
CDN information contains information associated with user
registration or authentication performed by the IPTV service
provider and PF information described above. By
acquiring
the CDN information from the service provider, the IPTV
receiver can receive an IP broadcast signal.
21
_ -

CA 02645878 2008-12-05
[0081] The customer may have various types of IPTV
receivers. If the
customer has a general TV receiver, the
customer may rent an IPTV STB to enjoy an IPTV broadcasting
service at a low cost. The customer may also apply for an IP
phone at a low service cost while the service provider pays
the additional service fee. The IPTV
receiver basically
includes a network interface that can access the network and
an Internet protocol to receive and process data packets
received from the network. When the data is multimedia data,
the IPTV receiver reproduces the data on the screen. Here,
when the customer has issued a request by operating the
remote controller, the IPTV receiver immediately transmits a
corresponding data packet to the server through the network
to receive corresponding information from the server. That
is, the IPTV receiver can operate to transmit a request from
the customer to the server while processing received
multimedia data in a bidirectional fashion. A variety
of
IPTV buttons may also be provided on the IPTV receiver to
allow the customer to fully use the service. Using the IPTV
receiver, the customer can store and view key scenes in a
drama and can receive additional services such as hotel
reservation or location information services.
[0082] On the
other hand, the NMS that has been described
above provides not only the function to allow the service
provider to manage the network but also an RCMS function.
22

CA 02645878 2008-12-05
The RCMS function helps the customer to control and manage
their IPTV receiver. The
importance of the RCMS will
increase as the use of IPTV receivers increases and the
number of additional relevant services increases. Thus, the
SNMP protocol has been compulsorily employed in IPTV
broadcast receivers in order to allow the service provider to
manage and control IPTV broadcast receivers. This will
enable the IPTV broadcast receiver to acquire statistical
data of a protocol currently used for communication and
information of a currently used processor and to identify the
TV manufacturer.
[0083] To
receive an IPTV service, an ITF 120 in the
customer domain can transmit a server address resolution
request to a DNS server 110. The DNS
server 110 then
transmits a server address to the ITF 120. Using the
received address, the ITF 120 connects to the server 130 to
receive an IPTV service. Here, the ITF 120 can connect to
the server 130 using at least one of a multicast scheme and a
unicast scheme.
[0084] FIG. 2 schematically illustrates the multicast
scheme.
[0085] As shown
in FIG. 2, the multicast scheme is a
method in which data is transmitted to a number of receivers
in a specific group. For example, the service provider can
collectively transmit data to a number of registered ITFs.
23

CA 02645878 2008-12-05
An Internet Group Management Protocol (IGMP) protocol can be
used for the multicast registration.
[0086] FIG. 3 schematically illustrates the unicast scheme.
[0087] As shown in FIG. 3, the unicast scheme is a method
in which one transmitter transmits data to one receiver in a
one to one manner. For example, in the case of the unicast
scheme, when an ITF has requested a service from the service
provider, the service provider transmits a corresponding
service to the ITF in response to the request.
[0088] FIG. 4 illustrates a procedure of a preferred
embodiment of a method for discovering an IPTV service
according to the present invention.
[0089] As shown in FIG. 4, in order to receive an IPTV
service, an ITF performs service provider discovery to search
for a Service Discovery (SD) server address list. Here, the
service provider discovery is a procedure in which the ITF
searches for information regarding an IPTV service provider
and information required to access the service provider
through a network that is under security management. The ITF
can search for the SD server address list in the following
manner.
[0090] Method for Searching for SD Server Address List
[0091] 1. Use of preset address or manual setting: The ITF
complies with an address preset in the ITF or the customer
manually sets an address.
24

CA 02645878 2008-12-05
[0092] 2. DHCP-
based SP Discovery: The ITF uses a DHCP
option to acquire an SD server address list.
[0093] 3. DNS
SRV-based SP Discovery: The ITF issues a
query using a DNS SRV mechanism to acquire SD server address
list.
[0094] The ITF
420 can search for a specific SD server
using the SD server address list obtained through the above
processes 1 to 3 and can receive a service provider discovery
record from the specific SD server.
[0095] The service provider 410 transmits a service
provider discovery record to the ITF 420 (S400). Here, the
service provider discovery record includes information
regarding useful IPTV service providers and information
required to access the service provider through a network
that is under security management. The
service provider
discovery record can be transmitted in a push mode or a pull
mode. In the pull mode, the service provider 410 transmits
the service provider discovery record when the ITF 420 has
issued a request to transmit the service provider discovery
record. However, in the push mode, the service provider 410
transmits the service provider discovery record regardless of
whether or not the ITF 420 has issued a request to transmit
the service provider discovery record.
[0096] The ITF 420 accesses a registration server
specified by registration server address information included
, _

CA 02645878 2008-12-05
in the service provider discovery record and performs an ITF
registration process (S405). Here,
information transmitted
from the ITF 420 to the service provider 410 may be carried
in an ITFRegistrationInputType record format and may include
subscriber identification information and subscriber location
information. In addition, the ITF registration can be termed
a "Service Provider (SP) attachment" and the term may be
changed depending on the intention or convention of those
skilled in the art or the introduction of new technology.
[0097] After
authentication is successfully performed, the
service provider 410 transmits a provision information record
to the ITF 420 (S410). Herein, the provision information
record is a record for providing the provisioning information
and the authentication information that are obtained by an
ITF during the process of Service Provider attachment. The
provision information record has an ITFRegistrationOutputType
record format and may contain information customized to a
service joined based on information included in the
ITFRegistrationInputType record. Here, the
ITFRegistrationInputType record may include at least one of
subscriber identification information and subscriber location
information. Here, the subscriber location information may
be an address where the ITF of the subscriber is located.
When the ITFRegistrationInputType record includes only the
subscriber identification information, the registration
26

CA 02645878 2008-12-05
server can obtain previously stored subscriber location
information and subscription status information based on the
subscriber identification information.
[0098] For example, the provision information may be
customized using the subscription status of the subscriber
and the location of the ITF. The ITF 420 may provide its ID
and location information through the ITFRegistrationInputType
record and the registration server may specify a service
joined by the ITF 420 based on the ID and location
information.
The registration server provides, in an
ITFRegistrationOutputType format, an address from which it is
possible to obtain service information that should be
received by the ITF 420 based on the specified service.
[0099]
The service information is divided into a master SI
table record for managing the version of channel details and
a channel map, a channel map record for providing a list of
channels in a packet format, and a channel details record
that contains details of each channel.
The service
information can be transmitted in a push mode or a pull mode.
[00100] The service provider 410 transmits a master SI
table record to the ITF 420 (S415).
Here, the ITF 420 may
receive the corresponding master SI table record or may
request the corresponding master SI table record from the
service provider 410 based on location information of the
master SI table included in the provision information record.
27
_

, I ,
CA 02645878 2008-12-05
[00101] The service provider 410 transmits a channel map
record to the ITF 420 (S420). Here, the ITF 420 may receive
a corresponding channel map record or may request a
corresponding channel map record from the service provider
410 based on channel map management information included in
the master SI table record.
[00102] The service provider 410 transmits a channel
details record to the ITF 420 (S425). Here, the ITF 420 may
receive the corresponding channel map record or may request
the corresponding channel map record from the service
provider 410 based on virtual channel information included in
the master SI table record or channel details location
information included in the channel map record.
[00103] FIG. 5 illustrates a schema of a preferred
embodiment of a service provider discovery type according to
the present invention.
[00104] As shown in FIG. 5, the service provider discovery
record includes a ServiceProviderID attribute, a Version
attribute, a LogoURI attribute, a Name element, a Description
element, and an SProviderRegistrationServer element.
[00105] The ServiceProviderID attribute includes unique ID
information of the service provider and uses a registered
domain name as the ID to guarantee the uniqueness of the ID.
[00106] The Version attribute includes version information
of this record.
28
wva.i

.. Sumo
CA 02645878 2008-12-05
[00107] The LogoURI attribute includes logo image
information specifying a URI of a logo image of the service
provider and can be selectively used.
[00108] The Name
element may include name information of
the service provider. The service provider may have one name
for each language. To
accomplish this, the Name element
includes a Language attribute and the Language attribute
includes information of respective names defined for
different languages. Here, the Name element needs to include
at least one Language attribute.
[00109] The Description element includes detailed text
description information of the service provider and single
text description information may be provided for each
language, similar to the name information of the service
provider. To
accomplish this, the Description element
includes a Language attribute. Here, the Description element
may include a plurality of Language attributes. The Language
attribute includes text description information. Here, the
text description information can be selectively provided and
may also not be provided.
[00110] The SProviderRegistrationServer element includes
address information of a registration server of the service
provider. To accomplish this, the
SProviderRegistrationServer element may include a Location
URL attribute and the Location URL attribute includes
29
_ ____________________________________________________________

CA 02645878 2008-12-05
Registration Server address information. Here, for example,
the Registration Server address information may be provided
in URL format.
[00111] FIG. 6 illustrates a schema of a preferred
embodiment of an ITF registration input type according to the
present invention.
[00112] As shown
in FIG. 6, the ITF Registration Input
record includes a ConsumerID attribute and a ConsumerLocation
attribute.
Information transmitted from the ITF to the
registration sever for registration can be carried in an ITF
registration input type format.
[00113] The
ConsumerID attribute includes unique subscriber
ID information of the subscriber. A MAC address of the ITF
may be used as the subscriber ID.
[00114] The
ConsumerLocation attribute includes subscriber
location information indicating the location of the
subscriber. Through
information included in the
ConsumerLocation attribute, the registration server can
determine the location of the subscriber and determine a
corresponding region =and can select and transmit flows
suitable for the ITF according to the determined region.
Here, the subscriber location information can be obtained
through a DHCP option at the network attachment process.

CA 02645878 2008-12-05
[00115] FIG. 7 illustrates a schema of a preferred
embodiment of an ITF registration output type according to
the present invention.
[00116] As shown in FIG. 7, the ITF registration output
record includes a MasterSITableLocation element, a
SubscribedChannelMap element, an UnsubscribedChannelMap
element, an EPGDiscoveryLocation element, and an
SPRemoteConfigurationServerLocation element. The information
transmitted from the registration server to the ITF when
authentication is successful may be carried in an ITF
registration output type format.
[00117] The MasterSITableLocation element includes location
information of a master SI table.
[00118] The SubscribedChannelMap element includes
information of a map of channels joined by the customer. The
service provider provides their channels in a format of a
number of channel maps so that the customer can select one or
more of the channel maps to join. The channel maps may be
constructed in an internal channel map format that is not
directly visible to the customer so that a list of channels
joined by the customer is provided through a combination of
channel maps.
[00119] The UnsubscribedChannelMap element includes
information of a map of channels not joined by the customer.
The service provider may need to provide the channel list for
31

CA 02645878 2008-12-05
promotion although the customer cannot view the channels
since they have not joined the channels. The
service
provider may selectively provide such channel maps.
[00120] The
EPGDiscoveryLocation element includes EPG data
provider information used to discovery EPG data. The EPG
data provider information includes information of an address
from which EPG data can be obtained. The EPG
can be
selectively provided and one or more EPGs may also be
provided. Here, for
example, the EPGDiscoveryLocation
element may be defined as an EPG discovery record type.
[00121] The SPRemoteConfigurationServerLocation element
includes information of an address of a remote configuration
server provided by the service provider. When
remote
configuration server address information is present, the ITF
needs to access a corresponding remote configuration server
to perform a remote configuration process. Here, the remote
configuration server performs the RCMS function described
above.
[00122] FIG. 8 illustrates relations between tables
included in service information (SI).
[00123] As shown in FIG. 8, a master SI table record
contains pointers to the Virtual Channel Maps, which are
necessary to start the Virtual Channel discovery process. The
master SI table record allows ITF to detect any version
changes of any part of the SI. To accomplish this, the master
32
_
_______________________________________________________________________________
__

CA 02645878 2008-12-05
SI table record includes channel map management information.
Herein, "Virtual Channel Maps" can be termed "Channel Maps"
in IPTV service.
[00124] the
master SI table record includes a channel map
master containing version information of channel maps and a
virtual channel master containing version information of
channel details containing detailed information of channels.
Here, the master SI table record may selectively include the
virtual channel master.
[00125] Each channel map is uniquely identified by a
VCListID and has two version information,i.e., VCListVerion
and ChannelDetailsVersion. The
VCListVersion is version
information of the channel list of the channel map and is
changed only when a channel is added or removed. The
ChannelDetailsVersion is version information used to manage
whether or not details information of channels included in
the channel map have been changed and is changed only when
the details information have been changed.
[00126] Only one
master SI table record can be uniquely
present for the service provider. However,
when service
configurations of regions are different, it will be more
efficient to construct one individual master SI table record
for each region. In this case, it is possible to provide a
master SI table record suitable for a region to which the ITF
belongs through the registration process.
33
_ _

CA 02645878 2008-12-05
[00127] In the
example illustrated in FIG. 8, two channel
maps are included in the master SI table record. The channel
maps can be uniquely identified using VCListIDs. Each
channel map may have one or more channels. Each channel map
does not include details information of the channels but
instead specifies locations from which the details
information can be obtained. That is, each channel details
location field in the channel map serves to specify the
location of the channel details information.
[00128] A channel
details record contains details of the
channels which can be located by a channel details location
field in the channel map. In
addition to this method, a
variety of methods as follows can be used to transfer the
channel details location or record.
[00129] Methods
of Transferring Channel Details Location or
Record
[00130] 1. Method of globally providing one multicast
stream
[00131] In this
method, a channel details record of all
channels provided by the service provider is distributed
through one global multicast stream. In this
case, the
channel details record can be provided by inserting the
address of the global multicast stream into an
ITFRegistrationOutputType element without the need to insert
34

CA 02645878 2008-12-05
an address of the details of each channel into the channel
map as described above.
[00132] 2. Method
of providing channel details record for
each region
[00133] While the
above method I globally provides channel
details through one stream, this method can provide channel
details of each region through an individual multicast stream.
In this case, since a region to which the ITF belongs can be
specified through the registration process, it is possible to
specify the address of a multicast stream unique to each
region through the ITFRegistrationOutputType element.
[00134] 3. Method
of specifying default channel details
location in channel map
[00135] If all or
part of details of channels belonging to
one channel map can be obtained from the same address, it
suffices to specify the address once in the channel map
instead of specifying the address in each channel details
location. In this
case, if a channel, the details of which
should be obtained from another address, is present, the
address is again or additionally specified in the channel
details location, thereby overriding the address specified in
the channel map.
[00136] 4. Method
of specifying location of details of each
channel through channel details location field as shown in
FIG. 5

CA 02645878 2008-12-05
[00137] In this
method, details of channels belonging to
each channel map are specified in each channel details
location field. For example, for channels whose service IDs
are "WNBC.COM/ch9" and "WNBC.COM/ch11", a LocationURL
attribute in the channel details location field of the
channel of "WNBC.COM/ch9" is specified as
"ipm://sd.verizon.com" and a LocationURL attribute in the
channel details location field of the channel of
"WNBC.COM/chll" is specified as "ipm://sd.verizon.com".
[00138] In order
to search for details of each channel in
transmitted channel details records, the serviceID in the
channel details location field can serve as a unique ID of
the details of each channel and it is possible to search for
a channel details record of the channel through the serviceID
of the channel details location field.
[00139] When channel details records are received in a
multicast scheme, it is possible to join a corresponding
stream and to search for the channel details record
corresponding to the serviceID while repeatedly receiving
records through the stream.
[00140] When a
channel details record is received in a
unicast scheme, it is possible to receive only a
corresponding channel details record by transferring the
serviceID as a parameter to the server to cause the server to
transmit only the desired channel details record.
36

CA 02645878 2008-12-05
[00141] The
master SI table record, the channel map record,
and the channel details record are transferred through three
separate flows in any of the push and pull modes.
[00142] Through
the master SI table record, the ITF can
manage updating of the channel map and the channel details.
The ITF monitors the master SI table to determine whether or
not the version of the channel map and the channel details
has been changed. When the version has been changed, the ITF
determines that the channel map and the channel details have
been updated and thus can perform a process for updating the
channel map and the channel details.
[00143] Here,
whether or not the channel details have been
updated can be determined using two methods. The first
method determines whether or not the channel details have
been updated using the channel details version of the channel
map master of the master SI table record. That is, when the
channel details version of the channel map master has been
changed, it can be determined that the channel details have
been updated. The second method determines whether or not
the channel details have been updated using the channel
details version of the channel map record. That is,
a
channel map record indicated by the channel map master is
searched for and whether or not the channel details version
of the channel map record has been changed is determined and
whether or not the channel details have been updated is
37
, _

CA 02645878 2008-12-05
determined based on the determination. 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.
[00144] FIG. 9 illustrates a schema of a preferred
embodiment of a master SI table record type.
[00145] As shown in FIG. 9, the master SI table record
includes channel map management information. To accomplish
this, the master SI table record may include a
ServiceProviderID attribute, a Version attribute, a
ChannelMapMaster element, and a VirtualChannelMaster element.
Here, the VirtualChannelMaster element may be selectively
included in the master SI table record.
[00146] The ServiceProviderID attribute includes service
provider identification information that enables unique
identification of the service provider and a registered
domain name can be used as the service provider ID.
[00147] The Version attribute includes version information
of the master SI table record. Using the version information
included in the Version attribute, it is possible to
determine whether or not the master SI table record has been
updated.
[00148] The ChannelMapMaster element includes information
used to receive the channel map. That is, The
ChannelMapMaster element includes a pointer to channel map
38

_
CA 02645878 2008-12-05
instance. The master SI table record contains one or more
pointer for pointing one or more channel map records. Based
on information included in the ChannelMapMaster element, it
is possible to receive the channel map record and to
determine whether or not the channel map has been updated.
To accomplish this, the ChannelMapMaster element may include
a VCListID attribute, a VCListVersion attribute, and a
ChannelDetailsVersion attribute. The
VCListID attribute
includes identification information that uniquely identifies
the channel map instance. The
VCListVersion attribute
includes version information indicating whether or not
channel lists included in the channel map have been changed.
Here, version information included in the VCListVersion
attribute is changed when a channel is added or removed. The
ChannelDetailsVersion attribute includes version information
indicating whether or not details of each channel included in
the channel map have been changed. Here, version information
included in the ChannelDetailsVersion attribute is changed
when the details of the channel are changed.
[00149] The VirtualChannelMaster element includes a
ServiceID attribute and a VCVersion attribute. The ServiceID
attribute includes identification information that uniquely
identifies the service. Based on information included in the
ServiceID attribute, it is possible to search for a desired
39
_
_______________________________________________________________________________
__

n M.*
CA 02645878 2008-12-05
channel details record. The
VCVersion attribute includes
version information of channel details.
[00150] FIG. 10 illustrates a schema of a preferred
embodiment of a channel map type.
[00151] As shown in FIG. 10, the channel map contains
channel map information and does not include details of
channels and serves as a package of channels. Here, the
channel map of FIG. 10 illustrates the fourth of the 4
channel details transmission methods described above with
reference to FIG. 8 in which an individual address is
specified for details of each channel. Also, channel map
information can be channel map instance.
[00152] The channel map record includes a channel map
instance. To accomplish this, the channel map record includes
a ServiceProviderID attribute, VCListID attribute, a
VCListVersion attribute, a ChannelDetailsVersion attribute,
and a ChannelDetailsLocation element.
[00153] The ServiceProviderID attribute includes service
provider identification information that enables unique
identification of the service provider and a registered
domain name can be used as the service provider ID.
[00154] The VCListID attribute includes identification
information that uniquely identifies the channel map.
[00155] The VCListVersion attribute includes version
information indicating whether or not channel lists included

CA 02645878 2008-12-05
,
in the channel map have been changed.
Here, version
information included in the VCListVersion attribute is
changed when a channel is added or removed.
[00156] The ChannelDetailsVersion attribute includes
version information indicating whether or not details of each
channel included in the channel map have been changed. Here,
the version information included in the ChannelDetailsVersion
attribute is changed when details of a channel are changed.
[00157] The ChannelDetailsLocation element includes
location information of details of each channel.
To
accomplish this, the ChannelDetailsLocation element includes
a ServiceID attribute, a LocationURL attribute, and a
VCVersion attribute.
The ServiceID attribute includes
identification information that uniquely identifies the
service.
Based on information included in the ServiceID
attribute, it is possible to search for the channel details
record. The LocationURL attribute includes information of an
address from which details of the service can be obtained.
The VCVersion attribute includes version information of
channel details.
[00158]
FIG. 11 illustrates a schema of another preferred
embodiment of a channel map type.
[00159] As shown in FIG. 11, the channel map contains
channel map information and serves as a package of channels.
The channel map does not include details of each channel but
41

CA 02645878 2008-12-05
instead includes information of a default location of details
of the channel. Here, the channel map of FIG. 11 illustrates
the third of the 4 channel details transmission methods
described above with reference to FIG. 8 in which a default
channel details location is specified in the channel map.
Also, channel map information can be channel map instance.
[00160] The channel map record includes channel map
instance. To accomplish this, the channel map record may
includes a ServiceProviderID attribute, VCListID attribute, a
VCListVersion attribute, a ChannelDetailsVersion attribute, a
ChannelDetailsDefaultLocation element, and a
ChannelDetailsLocation element.
[00161] The ServiceProviderID attribute includes service
provider identification information that enables unique
identification of the service provider and a registered
domain name can be used as the service provider ID.
[00162] The VCListID attribute includes identification
information that uniquely identifies the channel map.
[00163] The VCListVersion attribute includes version
information indicating whether or not channel lists included
in the channel map have been changed. Here,
version
information included in the VCListVersion attribute is
changed when a channel is added or removed.
[00164] The ChannelDetailsVersion attribute includes
version information indicating whether or not details of each
42

CA 02645878 2008-12-05
;
channel included in the channel map have been changed. Here,
the version information included in the ChannelDetailsVersion
attribute is changed when details of a channel are changed.
[00165]
The ChannelDetailsDefaultLocation element includes
default location information of details of each channel
belonging to the channel map.
To accomplish this, the
ChannelDetailsDefaultLocation element includes a LocationURL
attribute.
The LocationURL attribute includes default
location information. Here, the default location information
includes an address from which all or part of details of each
channel belonging to the channel map can be obtained. If a
channel, the details of which should be obtained from another
address, is present, location information of the details of
the channel can be overridden in the ChannelDetailsLocation
element.
[00166] The ChannelDetailsLocation element includes
location information of details of each channel. That is, if
there are details of a channel which cannot be obtained from
default location information included in
the
ChannelDetailsDefaultLocation element,
the
ChannelDetailsLocation element includes location information
of details of the channel.
To accomplish this, the
ChannelDetailsLocation element includes a ServiceID attribute,
a LocationURL attribute, and a VCVersion attribute.
The
ServiceID attribute includes identification information that
43

CA 02645878 2008-12-05
uniquely identifies the service. Based on
information
included in the ServiceID attribute, it is possible to search
for the channel details record. The
LocationURL attribute
includes information of an address from which details of the
service can be obtained. The
VCVersion attribute includes
version information of channel details.
[00167] FIGs. 12A
and 12B illustrate schemas of another
preferred embodiment of a channel details type.
[00168] As shown
in FIGs. 12A and 12B, the channel details
record includes details of each channel included in the
channel map. To accomplish this, the channel details record
includes a ServiceProviderID attribute and a
VirtualChannelDetails element.
[00169] The ServiceProviderID attribute includes service
provider identification information that enables unique
identification of the service provider.
[00170] The
VirtualChannelDetails element includes details
of each channel. To accomplish this, the
VirtualChannelDetails element includes a ChannelType
attribute, a ServiceID attribute, a VCVersion attribute, a
ShortChannelName element, a ChannelNumber element, and a
ChannelSource element. Here, the ChannelSource element may
be selectively included in the VirtualChannelDetails element.
When the ChannelSource element is not included in the
VirtualChannelDetails element, the ChannelSource element can
44

CA 02645878 2008-12-05
;
be separately transmitted through a separate ChannelSource
record and the VirtualChannelDetails element may include
location information and identification information that can
be used to receive the ChannelSource record.
[00171] The ChannelType attribute includes service type
information indicating the 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.
[00172] The ServiceID attribute includes identification
information that uniquely identifies the service. Based on
information included in the ServiceID attribute, it is
possible to search for a desired channel details record.
[00173] The VCVersion attribute includes version
information of channel details.
[00174] The ShortChannelName element includes a channel
name expressed by short text including 7 characters or less.
For example, the ShortChannelName element may have a value of
"WABC".
[00175]
The ChannelNumber element includes a corresponding
channel number. Since the present invention can support both
a one-part channel number and a two-part channel number, the
corresponding channel number may be either a one-part channel
number or a two-part channel number. To accomplish this, the
ChannelNumber element may include a MajorChannelNumber

CA 02645878 2008-12-05
:
element including physical channel information and a
MinorChannelNumber including logical channel information.
[00176] The ChannelSource element includes information
specifying an actual source of the corresponding channel. To
accomplish this, the ChannelSource element includes a
VirtualChannelLocation element, a ChannelSourcePurpose
element, a VideoAttribute element, an AudioAttributes element,
and an ECMLocation element.
[00177] The VirtualChannelLocation element includes
information of a transport protocol and an IP address from
which the source of the channel can be received.
To
accomplish this, the VirtualChannelLocation element includes
a ProgramNumber attribute and an IPLocation element.
By
selectively supporting the ProgramNumber attribute, it is
possible to guarantee extension to the MPTS and also to
provide a chance for the customer to check whether or not a
received stream is a desired stream in the case of SPTS. The
IPLocation element includes a Location URL attribute
including information of a URL from which the source of the
channel can be received.
[00178] The ChannelSourcePurpose element includes source
type information indicating the characteristics of the
channel and may include a plurality of source type
information. The source type information may have one of the
values of "HD", "SD", "PIP", and "Barker".
The Barker
46

CA 02645878 2008-12-05
channel is a channel for advertisement or publicity and is
automatically selected when the customer cannot view the
channel since they are not authorized for the channel. The
Barker channel serves to provide publicity of the channel and
guidance to join the channel. The Barker channel includes at
least one of the values of "HD Barker", "SD Barker", and "PIP
Barker".
[00179] One
channel may have one source for each value
specified by the ChannelSourcePurpose element. That is, when
the ChannelSourcePurpose element includes both one "HD" and
one "SD", one channel may have one HD source and one SD
source. However, since one channel does not need to include
two HD sources, the ChannelSourcePurpose element does not
include two HDs.
[00180] The VideoAttributes element includes video
attribute information of a corresponding source. To
accomplish this, the VideoAttributes element includes a Codec
attribute including video codec information, a Profile
attribute including video including profile information, and
a Level attribute including video level information.
[00181] The AudioAttributes element includes audio
attribute information of a corresponding source. To
accomplish this, the AudioAttributes element includes a Codec
attribute including audio codec information, a Profile
attribute including audio profile information, a Level
47

CA 02645878 2008-12-05
attribute including audio level information, a Bitrate
attribute including audio bitrate information, and
SamplingFrequency information including audio sampling
frequency information.
[00182] Through
the video attribute information included in
the VideoAttribute element and the audio attribute
information included in the AudioAttributes element, it is
possible to select and view a source optimal for the
functionality of the ITF.
[00183] The
ECMLocation element includes information of an
address from which ECM information can be received.
[00184] FIG. 13
is a flow chart illustrating a procedure of
a preferred embodiment of service provider discovery
according to the present invention.
[00185] As shown
in FIG. 13, the ITF searches for a Server
Discovery (SD) server (S1300). Here, the ITF can search for
an SD server according to the SD server address list search
method described above with reference to FIG. 4.
[00186] The ITF
accesses the SD server based on the SD
server address list and obtains a service provider discovery
record from the SD server (S1310). Here, the
service
provider discovery record may be that described above with
reference to FIG. 5. The ITF
can receive the service
provider discovery record from the SD server in a push mode
or in a pull mode.
48

CA 02645878 2008-12-05
[00187] The ITF parses a ServiceProviderID attribute of the
received service provider discovery record to read service
provider identification information included in the
ServiceProviderID attribute (S1320).
[00188] Based on the read service provider identification
information, the ITF determines whether or not the
corresponding service provider is that from which the ITF
desires to receive a service (S1330). When the corresponding
service provider is not that from which the ITF desires to
receive a service, the ITF performs the process of step S1300
to search for another SD server from the SD server address
list.
[00189] When the corresponding service provider is that
from which the ITF desires to receive a service, the ITF
parses a name attribute and a description attribute of the
service provider discovery record to read name information of
a service provider included in the name attribute and
detailed text description information of the service provider
included in the description attribute (S1340).
[00190] The ITF parses an SProviderRegistrationServer
element in the provider discovery record to read address
information of a registration server of the service provider
included in the SProviderRegistrationServer element (S1350).
Based on the read registration server address information,
49

CA 02645878 2008-12-05
the ITF can access the registration server to perform an ITF
registration process.
[00191] FIG. 14
is a flow chart illustrating a procedure of
a preferred embodiment of service provider registration and
service discovery according to the present invention.
[00192] As shown in FIG. 14, the ITF transmits a
registration request to the registration server specified by
the registration server address information included in the
service provider discovery record (S1400). Here, the ITF can
transmit the ITFRegistrationInputType record described above
with reference to FIG. 6 in the registration request.
[00193] The
registration server receives the registration
request and determines whether or not to register the ITF
(S1410). Here, the
registration server can receive the
ITFRegistrationInputType record in the registration request
and can determine whether or not to register the ITF based on
subscriber identification information and subscriber location
information included in the ITFRegistrationInputType record.
[00194] When
registration is approved, the ITF retrieves an
ITFRegistrationOutputType record (S1420). Here, the
ITFRegistrationOutputType record may be the
ITFRegistrationOutputType record described above with
reference to FIG. 7 and information included in the
TFRegistrationOutputType record is pre-customized using
information included in the ITFRegistrationInputType record.

CA 02645878 2008-12-05
,.
[00195]
The ITF parses a MasterSITableLocation element in
the retrieved ITFRegistrationOutputType record and reads
location information of a master SI table included in the
MasterSITableLocation element (S1430).
[00196]
The ITF retrieves a master SI table record based on
the read location information of the master SI table (S1440).
Here, the retrieved master SI table record may be that
described above with reference to FIG. 9.
[00197]
The ITF parses a SubscribedChannelMap element in
the retrieved ITFRegistrationOutputType record and reads
information of a channel map joined by the customer included
in the SubscribedChannelMap element (S1450).
Here, the ITF
can read channel map location information required to receive
the channel map joined by the customer from the
ChannelMapMaster element in the master SI table record.
[00198]
The ITF retrieves a channel map record based on the
read channel map location information (S1460).
Here, the
retrieved 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 above with reference to
FIG. 11.
[00199]
The ITF parses the ChannelDetailsLocation element
in the retrieved channel map record to read location
information of details of each channel included in the
ChannelDetailsLocation element (S1470).
51

CA 02645878 2008-12-05
[00200] The ITF retrieves a channel details record based on
the read location information of the details of each channel
(S1480). Here, the retrieved channel details record may be
that illustrated in FIG. 12A and 128.
[00201] The ITF then starts the received service (S1490).
[00202] FIG. 15 is a flow chart illustrating a procedure of
a preferred embodiment of a method for performing update of a
master SI table.
[00203] As shown in FIG. 15, the ITF updates a master SI
table (S1500). The ITF can monitor the master SI table in
real time to check whether or not the version of the received
master SI table has been changed. When the version of the
received master SI table has been changed, the ITF updates
the master SI table based on information included in the
received master SI table.
[00204] The ITF selects the ChannelMapMaster element for
updating from among ChannelMapMaster elements included in the
master SI table (S1510).
[00205] The ITF checks whether or not the ChannelMapMaster
element selected by the ITF includes information used to
receive the channel map joined by the customer (S1520). To
accomplish this, the ITF can use information of a channel map
joined by the customer included in the SubscribedChannelMap
element in the ITFRegistrationOutputType record.
52

CA 02645878 2008-12-05
[00206] When the
selected ChannelMapMaster element includes
information used to receive the channel map joined by the
customer, the ITF checks whether or not version information
included in a VCListVersion attribute in the selected
ChannelMapMaster element has been changed (S1530). When
version information included in the VCListVersion attribute
has been changed, the ITF receives the updated channel map
record and updates a channel map using information included
in the received channel map record (S1540).
[00207] The ITF
then checks whether or not an unselected
channelMapMaster element is included in the master SI table
(S1550). When an
unselected channelMapMaster element is
included in the master SI table, the ITF returns to step
S1510.
[00208] FIG. 16
is a flow chart illustrating a procedure of
another preferred embodiment of a method for performing
update of a master SI table.
[00209] As shown
in FIG. 16, the ITF updates a master SI
table (S1600). The ITF
can monitor the master SI table in
real time to check whether or not the version of the received
master SI table has been changed. When the version of the
received master SI table has been changed, the ITF updates
the master SI table based on information included in the
received master SI table.
53

CA 02645878 2008-12-05
[00210] The ITF
selects the ChannelMapMaster element for
updating from among ChannelMapMaster elements included in the
master SI table (S1610).
[00211] The ITF
checks whether or not the ChannelMapMaster
element selected by the ITF includes information used to
receive the channel map joined by the customer (S1620). To
accomplish this, the ITF can use information of a channel map
joined by the customer included in the SubscribedChannelMap
element in the ITFRegistrationOutputType record.
[00212] When the
selected ChannelMapMaster element includes
information used to receive the channel map joined by the
customer, the ITF checks whether or not version information
included in a VCListVersion attribute in the selected
ChannelMapMaster element has been changed (S1630). When
version information included in the VCListVersion attribute
has been changed, the ITF receives the updated channel map
record and updates a channel map using information included
in the received channel map record (S1640).
[00213] The ITF
checks whether or not version information
included in the ChannelDetailsVersion attribute in the
selected ChannelMapMaster element has been changed (S1650).
When the version information included in the
ChannelDetailsVersion attribute has been changed, the ITF
performs a channel details update process (S1660).
54

CA 02645878 2008-12-05
1.'
[00214]
The ITF then checks whether or not an unselected
channelMapMaster element is included in the master SI table
(S1670).
When an unselected channelMapMaster element is
included in the master SI table, the ITF returns to step
S1610.
[00215]
FIG. 17 is a flow chart illustrating a procedure of
a preferred embodiment of a method for performing update of a
channel details version.
[00216]
As shown in FIG. 17, the ITF updates the channel
map (S1700).
[00217]
The ITF selects a channel from the channel map
(S1710). Here, the ITF can also select
a
ChannelDetailsLocation element including location information
of details of the channel selected from the channel map.
[00218]
The ITF checks whether or not version information
included in the VCVersion attribute in the selected
ChannelDetailsLocation element has been changed (S1720).
When the version information has been changed, the ITF
receives the updated channel details record and updates the
channel details of the selected channel based on information
included in the received channel details record (S1730).
[00219]
The ITF checks whether or not an unselected channel
is included in the channel map (S1740). When an unselected
channel is included in the channel map, the ITF returns to
step S1710.

CA 02645878 2008-12-05
[00220] FIG. 18
is a flow chart illustrating a procedure of
another preferred embodiment of a method for performing
update of a channel details version.
[00221] As shown
in FIG. 18, the ITF selects a channel from
the channel map (S1800). Here, the
ITF can also select a
ChannelDetailsLocation element including location information
of details of the channel selected from the channel map.
[00222] The ITF
searches the master SI table MasterSITable
for a virtual channel master element including a ServiceID
attribute including the same identification information as
that included in a ServiceID attribute in the selected
ChannelDetailsLocation element (S1810).
[00223] The ITF determines whether or not version
information included in the found virtual channel master
element is identical to version information included in the
VCVersion attribute in the selected ChannelDetailsLocation
element (S1820). When the
two version information are
different, the ITF receives the updated channel details
record and updates channel details of the selected channel
based on information included in the received channel details
record (S1830).
[00224] The ITF
checks whether or not an unselected channel
is included in the channel map (S1840). When an unselected
channel is included in the channel map, the ITF returns to
step S1800.
56

CA 02645878 2008-12-05
[00225] FIG. 19 illustrates a schema of a preferred
embodiment of an EPG discovery record type according to the
present invention.
[00226] As shown in FIG. 19, the EPG discovery record
includes EPG discovery information used to discovery EPG data.
To accomplish this, 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.
[00227] The
EPGProviderID attribute includes identification
information that enables unique identification of an EPG data
provider. Here, a registered domain name can be used as the
identification information.
[00228] The
Version attribute includes version information
of an EPG discovery record.
[00229] The Name
element includes information of a text
name of the EPG data provider and the EPG data provider may
have one name for each language. To
accomplish this, the
Name element includes a Language attribute. The Name element
may also include a plurality of Language attributes and each
of the Language attributes includes information of a text
name of the EPG data provider defined for each language.
[00230] The Description element includes detailed text
description information of the EPG data provider and single
text description information may be provided for each
57

CA 02645878 2008-12-05
language, similar to the information of the name of the EPG
data provider. To accomplish this, the Description element
includes a Language attribute. The Description element may
include a plurality of Language attributes and each of the
Language attributes includes text description information
defined for each language.
[00231] The EPG
ServerLocation element includes information
of an IP address from which EPG data can be received and
information of a protocol used to receive the EPG data.
[00232] The TargetServiceProviderID element includes ID
information of service providers supported by the EPG data
provider.
[00233] The Logo
element includes location information of a
logo of the EPG data provider. Here, the
logo location
information may be provided in a URI format.
[00234] FIG. 20 is a block diagram illustrating a
configuration of a preferred embodiment of an IPTV Terminal
Function (ITF) according to the present invention.
[00235] As shown
in FIG. 20, the ITF includes an IP network
stack 2015, a file handler 2020, an SI handler 2025, an EPG
handler 2030, a storage 2035, an SI decoder 2040, an EPG
decoder 2045, an ITF operation controller 2050, a channel
service manager 2055, an application manager 2060, a
demultiplexer 2065, a PSI/PSIP parser 2070, an A/V decoder
2075, and a display module 2080. Here, a network interface
58

CA 02645878 2008-12-05
..
may include a modem 2005 and an Ethernet Network Interface
Card (NIC) 2010.
[00236] The modem 2005 serves as an interface through which
the ITF connects to the IP network at the physical level.
The modem 2005 demodulates a signal received through a
physical modem to reconstruct the received signal into a
digital signal and modulates a digital signal for
transmission to the service provider and outputs the
modulated digital signal to the IP network. The modem 2005
may be implemented as a cable modem, a DSL modem, or the like.
[00237] The Ethernet NIC 2010 reconstructs a digital signal
received through the modem 2005 into an IP packet and outputs
the IP packet to the IP network stack 2015. The Ethernet NIC
2010 also encapsulates an IP packet output from the IP
network stack 2015 into an Ethernet datagram and outputs the
Ethernet datagram to the modem 2005.
[00238] The IP network stack 2015 handles a processing
module of each layer according to the IP protocol stack. The
IP network stack 2015 involves transfer of packets received
and transmitted by the ITF from a source to a destination.
The IP network stack 2015 classifies each received packet
according to an appropriate protocol and outputs the
classified packet to the file handler 2020 and demultiplexer
2065. For example, when the IP network stack 2015 receives a
packet including one of a service provider discovery record,
59

CA 02645878 2008-12-05
an ITF registration output record, a master SI table record,
a channel map record, a channel details record, and an EPG
discovery record, the IP network stack 2015 outputs data
included in the packet to the file handler 2020. The IP
network stack 2015 converts the ITF registration input record
into an IP packet and outputs the IP packet to the Ethernet
NIC 2010 so that it is transmitted to the service provider.
[00239] The file
handler 2020 collects data output from the
IP network stack 2015 and reconstructs the data into a file
format. Here, the
file handler 2020 can reconstruct data
output from the IP network stack 2015 into a file format
using FLUTE. That is, the service provider can transmit a
file using FLUTE and the file handler 2020 can receive the
file transmitted by the service provider using FLUTE. The
file handler 2020 classifies and outputs the reconstructed
file to one of the SI handler 2025 and the EPG handler 2030.
[00240] The SI handler 2025 processes a portion
corresponding to IPTV SI data among the file-format data
received from the file handler 2020 and stores the processed
data in the storage 2035. Here, the IPTV SI data may be at
least one of a service provider discovery record, an ITF
registration output record, a master SI table record, a
channel map record, a channel details record, and an EPG
discovery record.

CA 02645878 2008-12-05
:
[00241] The EPG handler 2030 can process a portion
corresponding to IPTV EPG data among the file-format data
received from the file handler 2020 and store the processed
data in the storage 2035.
Here, the EPG handler 2030 can
receive the IPTV EPG data using information included in the
EPG discovery record.
[00242]
The storage 2035 stores SI provided by the SI
handler 2025, an EPG provided by the EPG handler 2030, data
provided by the ITF operation controller 2050, etc.
[00243]
The SI decoder 2040 decodes SI data stored in the
storage 2035 to reconstruct required information and provides
the reconstructed information to the ITF operation controller
2050.
From the service provider discovery record, the SI
decoder 2040 reads useful IPTV service provider information
and information used to access the service provider through a
network that is under security management. For example, the
SI decoder 2040 can parse the service provider discovery
record to read registration server address information
included in the service provider discovery record.
[00244]
The SI decoder 2040 can parse the ITF registration
output record to read information included in the ITF
registration output record. For example, the SI decoder 2040
can read address information used to receive the master SI
table record and EPG discovery information used to discovery
EPG data included in the ITF registration output record.
61

CA 02645878 2008-12-05
[00245] The SI
decoder 2040 can also parse the master SI
table record to read information used to receive a channel
map record and a channel details record, version information
of the channel map record, and version information of the
channel details record included in the management SI table
record.
[00246] The SI decoder 2040 can also read channel map
information from the channel map record and can read channel
details information of the corresponding channel from the
channel details record.
[00247] When EPG
information is required, the EPG decoder
2045 reads and analyzes EPG data stored in the storage 2035
to reconstruct original EPG data. The EPG
decoder 2045
provides the reconstructed EPG data to the ITF operation
controller 2050.
[00248] The ITF operation controller 2050 controls
operations of the ITF. The ITF
operation controller 2050
controls the SI decoder 2040, the EPG decoder 2045, and the
display module 2080 and processes requests input from the
channel service manager 2055 and the application manager 2060.
[00249] The ITF
operation controller 2050 controls the SI
decoder 2040 to create a channel map and selects a channel
using the channel map according to a key input received from
the channel service manager 2055. The ITF
operation
controller 2050 then controls the IP network stack 2015 to
62

CA 02645878 2008-12-05
,-
allow the selected channel to be received. Also, The ITF
operation controller 2050 controls PSI/PSIP Parser 2070 to
allow the selected channel to be received. Also, The ITF
operation controller 2050 controls IP Network Stack 2015 to
allow the selected channel to be received
[00250] The channel service manager 2055 receives a channel
request signal from a customer and provides the input request
signal to the ITF operation controller 2050 so that the
channel is switched to the requested channel.
[00251] The application manager 2060 manages overall states
and provides a user interface. When an EPG display request
has been received from the customer through the user
interface, the application manager 2060 provides the EPG
display request to the ITF operation controller 2050 to allow
the display module 2080 to display the EPG.
[00252] The demultiplexer 2065 demultiplexes the received
packet into audio data, video data, and Program Specific
Information (PSI) data and transmits the audio and video data
and the PSI data to the A/V decoder 2075 and the PSI/PSIP
parser 2070. That is, the demultiplexer 2065 extracts MPEG-2
transport stream data from the IP packet received from the IP
network stack 2015 and transfers the data to the PSI/PSIP
parser 2070 or the A/V decoder 2075 according to a
corresponding PID.
63

CA 02645878 2008-12-05
.-
[00253] The PSI/PSIP parser 2070 extracts and parses
PSI/PSIP data containing information that can be used to
access a program element such as PID information of each data
item (for example, A/V data) of an MPEG-2 transport stream
in the IP datagram received from the multiplexer 2065. The
PSI/PSIP parser 2070 can also control the demultiplexing
process of the application manager 2060 based on the
extracted PSI/PSIP data.
[00254]
The A/V decoder 2075 decodes video data and audio
data received from the demultiplexer 2065.
To accomplish
this, the A/V decoder 2075 may include an audio decoder and a
video decoder. The audio data decoded by the audio decoder
is provided to the customer through the display module 2080
and the video data decoded by the video decoder is displayed
on the display module 2080.
[00255]
The display module 2080 displays video data and
audio data decoded by the A/V decoder 2075 under control of
the ITF operation controller 2050. The display module 2080
also receives EPG data from the ITF operation controller 2050
and displays the received EPG data under control of the ITF
operation controller 2050.
[00256]
FIG. 21 is a flow chart illustrating a procedure of
a preferred embodiment of a virtual channel setting method
according to the present invention.
64

CA 02645878 2008-12-05
[00257] As shown in FIG. 21, the ITF performs network
attachment (S2100). Here, the
network attachment is a
process in which the ITF establishes a connection between the
IP network and the layer 3 and obtains network configuration
data.
[00258] The ITF performs service provider discovery to
obtain service provider discovery record (S2105). Here, the
ITF can perform the service provider discovery described
above with reference to FIG. 13.
[00259] The ITF
retrieves SI and EPG data using information
included in the service provider discovery record (S2110).
Here, the ITF can perform service provider registration and
service discovery described above with reference to FIG. 14
in order to obtain SI metadata. The ITF can perform service
provider registration to retrieve a registration output
record and can perform service discovery based on information
included in the obtained ITF registration output record.
Then, the ITF can perform service discovery to retrieve a
master SI table record, a channel map record, and a channel
details record. The SI metadata can be read from information
included in the channel map record and the channel details
record.
[00260] The ITF
can retrieve EPG data based on information
included in the EPGDiscoveryLocation element included in the
ITF registration output record.

CA 02645878 2008-12-05
[00261] The ITF
generates a channel map using the retrieved
SI metadata and stores the generated channel map (S2215).
The ITF then receives a virtual channel request signal from
the customer (S2220). Here, the
customer can select a
virtual channel through channel-up and channel-down
operations.
[00262] The ITF
generates an EPG using the retrieved EPG
data and stores the generated EPG (S2225). The ITF displays
the stored EPG (S2230). The ITF receives a signal requesting
a virtual channel selected from the displayed EPG (S2235).
Here, the customer can select a specific virtual channel that
they desire to view from the EPG displayed on the screen.
[00263] The ITF searches the stored channel map for
information of a virtual channel requested according to the
virtual channel request signal (S2240). Here, the
ITF can
search for channel details location information including a
service ID identical to the service ID of the requested
virtual channel in the channel map and detect information of
a location from which the virtual channel can be received
included in the LocationURL attribute in the channel details
location information. The ITF
also searches for channel
details including a service ID identical to the service ID of
the requested virtual channel and detects details of the
requested virtual channel.
66

CA 02645878 2008-12-05
[00264] The ITF tunes to the requested virtual channel
based on the found virtual channel information (S2245). Here,
the ITF can access an address indicated by information of a
location from which the detected virtual channel can be
received and receive an IPTV service of the requested virtual
channel. The ITF provides the received IPTV server to the
customer (S2250).
[00265] As is apparent from the above description, the
present invention provides an IPTV receiver and a method for
discovering an IPTV service, which have advantages in that it
is possible to efficiently search for and obtain an IPTV
service and to quickly and correctly update IPTV service
information, thereby enabling efficient management of IPTV
service information.
[00266] Hereinafter, a method of Parental Control for
building a channel map in ITF will now be made in detail to
the preferred embodiments of the present invention, examples
of which are illustrated in the accompanying drawings.
Wherever possible, the same reference numbers will be used
throughout the drawings to refer to the same or like parts.
[00267] In particular, explained in this disclosure are a
method and apparatus for performing a parental control more
efficiently by an ITF (IPTV terminal function) using system
information (hereinafter abbreviated 'SI') essential to the
use of IPTV services and contents and information relevant to
67

CA 02645878 2008-12-05

electronic programming guide (hereinafter abbreviated 'EPG')
according to the present invention.
[00268] In this disclosure, 'channel' is generally used as
the concept of a channel used in conventional broadcasting
environments or a channel relevant to the use of an IP-based
service and contents.
[00269] In this disclosure, if contents defined in the
relevant regulations are included, when SI information and
EPG information essential to the service and content use are
referred to, 'parental control' is generally used to have the
meaning of a case of performing a conditional access by
determining accessibility to each of the service and content
provided on a corresponding channel or a case of performing a
conditional access to a corresponding channel by determining
accessibility to the corresponding channel.
[00270] In FCC (North America Organization), every digital
TV receiver is forced to perform a parental control according
to RRT (rating region table) defined in ATSC A/65C and EIA-
766A. Therefore, an ITF is requested to have a parental
control function for a virtual channel as well.
[00271] In particular, a parental control is performed on
each virtual channel by the ITF in IPTV environments instead
of or with a parental control for services or contents on the
respective virtual channels. For this, explained in the
following description is a case that a parental control is
68

CA 02645878 2008-12-05
performed on each virtual channel based on SI metadata and
EPG metadata according to one embodiment of the present
invention.
[00272] FIG. 22 is a diagram of RRT defined in ATSC A/65C
and EIA-766A for explaining rating region value allocation.
[00273] Referring to FIG. 22, a current rating region value
ranges from '0x01' to '0x05'. And, a rating region
corresponding to each rating region value is defined. In this
case, rating region values ranging from '0x011 to '0x04'
correspond to U.S. (50 states + other possessions), Canada,
Taiwan and Korea, respectively. In particular, in case of
U.S., another rating region value is set to '0x05' to cope
with a new rating system, which will be defined in the future,
as well as the conventional rating system corresponding to
'0x01'. Hence, a downloadable rating system is regulated to
be extensible. And, every digital TV receiver is formed to
cope with the corresponding extension.
[00274] FIG. 23 is a diagram for U.S. rating region table
system.
[00275] FIG. 23 shows the contents defined in U.S. FCC
regarding a current U.S. rating region table system.
[00276] Referring to FIG. 23, a rating system, a plurality
of dimensions and rating values for the respective dimensions
are exemplarily shown. Herein, their details are omitted in
69

CA 02645878 2008-12-05
_
,
,
this disclosure and contents provided by U.S. FCC are cited
for the details.
[00277] FIG. 24 is a diagram for correlation between SI
data and EPG data in IPTV system according to one embodiment
of the present invention. Herein, the arrows in the diagram
indicate a path the ITF would follow in building a channel
map that would allow the ITF to acquire any of the desired
channels.
[00278] Referring to FIGs. 4, 5, and 24, ITF receives
ServiceProviderInfo Table (SI) Record providing access
information of Service Provider Registration Server and
additional information about a Service Provider. Accordingly,
the ITF discovers a Service Provider and performs
registration procedure.
[00279] Referring to FIGs. 4, 7, and 24, ITF receives
ITFRegistrationOutput (SI) Record providing first access
information of a Master SI table, a list of channel
identifiers which a user is subscribed, second access
information of a Service Provider Remote Configuration Server,
third access information of an EPG metadata, and additional
information about an EPG Provider. Accordingly, the ITF
receives the Master SI table based on the first access
information.
[00280] Referring to FIGs. 4, 9, and 24, ITF receives
IIFMasterSiTable (SI) Record providing access information of

CA 02645878 2008-12-05
,
Virtual Channel Maps and version information of Virtual
Channel Maps. Accordingly, the ITF receives the Virtual
Channel Map and manages a version of the received Virtual
Channel Map.
[00281] Referring to FIGs. 4, 10-11, and 24, ITF receives
ITFVirtualChannelMap (SI) Record providing access information
of a Virtual Channel Description Table, a list of Virtual
Channel Services, and additional information about each
Virtual Channel Service. Accordingly, the ITF receives the
Virtual Channel Description Table based on the access
information.
[00282] Referring to FIG. 24, ITF
receives
ITFVirtualChannelDescriptionTable (SI) Record specifying a
category of the Virtual Channel Service and providing access
information of a Virtual Channel Service stream, and
descriptive information of the Virtual Channel Service.
Herein, the descriptive information of the Virtuacl Channel
Service includes information of Virtual Channel short name
and Channel Parental Guidance Rating.
[00283] Referring to FIG. 24, ITF receives an EPG metadata
providing schedule information of contents, purchase
information of contents, and descriptive information of
scheduled contents. Herein, the descriptive information of
the scheduled contents includes information of Contents name
and Contents Parental Guidance Rating
71

CA 02645878 2008-12-05
[00284] Information on channel parental guidance rating
within the VirtualChannelDescriptionTable and information on
contents parental guidance rating within the EPG element are
linked to each other using linkage information. In this case,
the linkage is performed using elements for
VirtualChannelServiceID and ServiceIDRef.
[00285]
Hereinafter, Parental Control information including
SI data is named the Channel Parental Guidance Rating and
Parental Control information including EPG metadata is named
Contents Parental Guidance Rating. However, it is not limited
to the name.
[00286] Referring
to FIG. 24, information of the Channel
Parental Guidance Rating is included VirtualChannelService
element. And, the VirtualChannelService element is included
VirtualChannelDescriptionTable providing detail specification.
Also, the VirtualChannelDescriptionTable is accessed using
access information in the VirtualChannelMap element.
[00287] Moreover, EPG element includes information on
contents parental guidance rating that corresponds to
information on the channel parental guidance rating according
to one embodiment of the present invention.
[00288] In the
following description, the information on
the channel parental guidance rating according to one
embodiment of the present invention is explained in detail.
72

CA 02645878 2008-12-05
[00289] FIG. 25 is a diagram of RatingRegionTableType
schema for receiving ITF as a part of EPG data in IPTV system
according to the present invention, and FIG. 26 is a diagram
of the XML schema shown in FIG. 25. Herein, the
RatingRegionTable defines the dimensions and values for a
parental guidance rating system.
[00290] First of all, an ITF receives an RRT and then
stores it in a storage unit. The ITF provides an EPG screen
for enabling a user to set a parental control according to
the stored RRT. Various fields of the RRT are explained with
reference to FIG. 25 and FIG. 26 as follows. In this case,
names of the fields are represented as bold types.
[00291] RatingRegionName field is a name of rating region
to which this table applies and corresponds to the
rating_region_name_text field in the ATSC PSIP Standard.
[00292] RatingRegion field is a code number for the rating
region to which this table applies and corresponds to the
rating_region field of the Rating Region Table in the ATSC
PSIP standard. Only those values approved by the ATSC in its
role as Registration Authority shall be used. No table with
RatingRegion value "1" shall be downloaded.
[00293] TableVersion field is a version of this Rating
Region Table.
[00294] Dimension field is the rating definition for a
specific rating dimension.
73

CA 02645878 2008-12-05
,
,
[00295] RatingDimensionName field is the name of the rating
dimension and corresponds to the dimension_name_text field of
the Rating Region Table in the ATSC PSIP Standard.
[00296] RatingDimension field is the code number of the
rating dimension and corresponds to the index "i" of the
rating dimension in the dimensions_defined loop of the Rating
Region Table in the ATSC PSIP Standard.
[00297] GraduatedScale field is the flag indicating whether
the rating dimension uses a graduated scale and corresponds
to the graduated_scale field of the Rating Region Table in
the ATSC PSIP Standard. If a graduated scale is used, the
DimensionValue elements shall appear in the table in order of
least restrictive first to most restrictive last.
[00298] DimensionValue field is the definition of a rating
value for the dimension.
[00299] RatingValueText field is the text description of
the rating value and corresponds to the rating_value_text
field of the Rating Region Table in the ATSC PSIP Standard.
[00300] AbbrevValueText field is the abbreviated text for
the rating value; corresponds to the abbrev_rating_value_text
field of the Rating Region Table in the ATSC PSIP Standard.
[00301] RatingValue field is the code number of the rating
value and corresponds to the index "j" of the rating value in
the values_defined loop of the Rating Region Table in the
ATSC PSIP Standard.
74

CA 02645878 2008-12-05
[00302] FIG. 27
is a diagram of a schema structure of SI
data including parental control information and
VirtualChannelDescriptionTable according to one embodiment of
the present invention, FIG. 28 is a diagram of XML schema of
the VirtualChannelDescriptionTable shown in FIG. 28, and FIG.
29 is a diagram of XML schema of RRTParentalGuidance element
in FIG. 27.
[00303] Referring
to FIGs. 27 to 29, the parental control
information according to the present invention includes one
of a plurality of sub-elements within
VirtualChannelDescriptionTable and names the corresponding
element RRTParentalGuidance element. Yet, it is understood
that this is arbitrarily determined to explain the present
invention, by which examples of the present invention are
non-limited.
[00304]
VirtualChannelServiceId field indicates that each
Virtual Channel has an ID which is used to link to the
Virtual Channel map and to the EPG entries.
[00305] VirtualChannelServiceVersion field is a counter
that increments when any modification are made to this
instance of a Virtual Channel Description.
[00306] VirtualChannelServiceCategory field indicates a
type of Virtual Channel Service (Linear or VOD).
[00307] VirtualChannelShortName field indicates a short
name (<7 characters) of the Virtual Channel.

CA 02645878 2008-12-05
[00308] ProgrammingSource field indicates o ne or more
sources available to the Virtual Channel, generally
differentiated by resolution (e.g. HD, SD, PIP) and
entitlement state (e.g. Barker).
[00309] RRTParentalGuidance field indicates the type
definition for specifying a parental guidance rating that
conforms to the structure of a single instance of the
rating_region loop in the ATSC Content Advisory Descriptor
[1]. In any element of this type, the ratingRegion value
shall match the ratingRegion value of a Rating Region Table
approved by the standards or regulatory body applicable to
the region of interest, and each ratingDimension of the
instance shall match a ratingDimension that appears in that
Rating Region Table, and the ratingValue associated with a
ratingDimension in the instance shall match a ratingValue for
the corresponding dimension in that Rating Region Table.
[00310] Dimension field indicates the rating for a specific
rating dimension.
[00311] RatingDimension field indicates the 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
shall have different values of the ratingDimension attribute.
76

CA 02645878 2008-12-05
[00312] RatingValue field indicates the code number for the
rating level for the dimension, corresponding to the
rating_value field in the ATSC Content Advisory Descriptor.
[00313] RatingDescriptionText field indicates the text
description of the overall rating.
[00314] ratingRegion field indicates the code number for
the rating region to which this parental guidance rating
applies, corresponding to the rating_region field in the ATSC
Content Advisory Descriptor.
[00315] FIG. 30 is a flowchart for an ITF to enable a user
to set a parental control according to one embodiment of the
present invention.
[00316] Referring to FIG. 30, in order for a user to set a
parental control, an ITF receives and stores RRT data as a
part of EPG data and then uses the corresponding data.
[00317] The ITF performs a network attachment [S3001]. In
this case, the network attachment is the procedure for the
ITF to establish a connection between an IP network and a
layer 3 and to obtain network configuration data. The step
S3001 is performed by the Ethernet NIC (2010) and IP network
stack (2015) for example.
[00318] The ITF obtains a ServiceProviderDiscovery Record
by performing a Service Provider Discovery and then receives
service provider (SP) lists within the obtained
ServiceProviderDiscovery Record [S3002]. In doing so, the ITF
77

CA 02645878 2008-12-05
,
is able to perform the Service Provider Discovery explained
in the foregoing description of FIG. 4. The step S3002 is
performed by the Ethernet NIC (2010) and IP network stack
(2015) or the SI handler (2025) and decoder (2040).
[00319] Subsequently, the ITF selects a service provider
(SP) from the received Service Provider lists. And, the ITF
performs a registering procedure on the selected Service
Provider [S3003]. For instance, the step S3002 is performed
by the Ethernet NIC (2010) and IP network stack (2015).
[00320] The ITF is able to acquire SI data and EPG data
using the information included in the obtained Service
Provider Discovery Record. In this case, the ITF is able to
perform the service provider registration and service
discovery explained in the foregoing description with
reference to FIG. 4 to acquire SI metadata. The ITF is able
to receive an ITFRegistrationOutput Record by performing a
Service Provider Registration [S3004]. And, the ITF is able
to perform the Service Discovery based on the information
included in the acquired RegistrationOutput Record.
[00321] The ITF is able to acquire a master SI table record,
a channel map record and a channel details record by
performing the Service Discovery. The SI metadata can be
calculated from the information included in the channel map
record and the channel details record.
78

CA 02645878 2008-12-05
[00322] The ITF finds out location information on an EPG
server from which the EPG metadata can be obtained based on
the information included in EPGDiscoveryLocation contained in
the ITF registration output record [S3005]. For instance, the
steps of S3004 and 3005 are performed by the File handler
(2020), SI handler (2025), and decoder (2040).
[00323] Subsequently, the EPG server is accessed based on
the discovered location information [S3006]. For instance,
the step S3006 is performed by the Ethernet NIC (2010) and
the IP network stack (2015) or the SI handler (2025) and the
decoder (2040).
[00324] The ITF receives an RRT and different EPG metadata
from the accessed EPG server [S3007]. For instance, the step
S3007 is performed by the File handler (2020).
[00325] The ITF parses the received RRT and then stores a
rating system in the parsed RRT [S3008]. For instance, the
step S3008 is performed by the EPG handler (2030), the
storage unit (2035) and the decoder (2045).
[00326] In case of receiving a request for a parental
control from a user, the ITF performs the parental control on
a corresponding virtual channel appropriately according to
the stored rating system [S3009]. For instance, the step
S3009 is performed by the application manager (2060), the ITF
operation controller (2050) and the storage unit (2035).
79

CA 02645878 2008-12-05
,
.'
[00327] FIG. 31 is a flowchart for an ITF to determine
whether to access a predetermined virtual channel and whether
to provide guide information on the corresponding virtual
channel using parental control information received by being
included in SI data and the parental control setup previously
set in the ITF by a user according to the present invention.
[00328] In the following description, steps S3101 to S3103
corresponding to the overlapped steps of FIG. 30 are omitted
by referring to the steps S3001 to S3003 and the rest of
steps next to the step S3103 are explained.
[00329] First of all, the ITF finds out location
information of SI tables as outputs of registration through
the step S3103 [S3104]. The ITF then receives and then parses
a VirtualChannelDescriptionTable using location information
of the discovered SI tables [S3105].
[00330] The ITT parses to interpret RRTParentalGuidance
field included in the parsed virtual channel description
table [S3106]. The ITF also parses RatingDimension field
including at least one or more rating dimensions applied to a
corresponding virtual channel and RatingValue field including
a rating value according to the rating dimension according to
the information of the parsed and interpreted Parental
Guidance field [S3107]. For instance, the steps of S3004 and
3005 are performed by the File handler (2020), SI handler
(2025), and decoder (2040)..

CA 02645878 2008-12-05
,
,
[00331] The ITF determines whether to block the
corresponding virtual channel based on values of the parsed
RatingDimension field and the RatingValue field, i.e., at
least one rating dimension for the corresponding virtual
channel and the rating value according to each rating
dimension through the step S3107. This process is explained
in detail as follows.
[00332] First of all, the ITF determines whether a
graduated scale is applied to the rating dimension extracted
from the parsed field [S3108].
[00333]
As a result of the determination performed in the
step S3108, if the graduated scale is not applied to the
corresponding RatingDimension, the ITF determines whether a
user's setup for a parental control is set for the
corresponding RatingDimension and the corresponding
RatingValue [S3109]. As a result of the determination
performed in the step S3109, if the user's setup does not
exist, the ITF does not block the corresponding virtual
channel [S3110] but determines whether another rating
dimension further exists [S3114]. As a result of the
determination performed in the step S3114, if another rating
dimension fails to further exist, the ITF ends the procedure.
On the contrary, as a result of the determination performed
in the step S3114, if another rating dimension further exists,
the ITF will sequentially execute the steps from S3107 again.
81

CA 02645878 2008-12-05
In this case, 'the ITF does not block the corresponding
virtual channel' may mean that an IPTV service is consumed on
the corresponding virtual channel or that guide information
for the corresponding virtual channel is displayed.
[00334] However, if the user's setup exists as the result
of the determination performed in the step S3109, the ITF
blocks the corresponding virtual channel [S3113].
[00335] As a result of the determination performed in the
step S3108, if the graduated scale is applied to the
corresponding rating dimension, the ITF compares a rating
value (first rating value) according to the user's setup for
the parental control and a rating value (second rating value)
according to the corresponding rating dimension extracted
from the parsed field [S3111].
[00336] The ITF determines whether the second rating value
is equal to or greater than the first rating value according
to the user's setup [S3112]. If the second rating value is
equal to or greater than the first rating value, the ITF
blocks the corresponding virtual channel [S3113]. If the
second rating value is smaller than the first rating value,
the ITF does not block the corresponding virtual channel
[S3110]. Having determined whether to block the corresponding
virtual channel or not, the ITF determines whether another
dimension further exists [S3114]. For instance, the steps of
S3008, S3009, S3011, and S3012 are performed by the ITF
82

CA 02645878 2008-12-05
Operation Controller (2050) and the Storage unit (2035). And,
for instance, the steps of S3010, 53013, and S3014 are
performed by the ITF Operation Controller (2050), Channel
Service Manager (2055), and Application manager (2060).
[00337] In the above description, if the corresponding
virtual channel is blocks, the ITF restricts the user's
access to the corresponding virtual channel and is able to
prevent guide information on EPG for the corresponding
virtual channel from being provided.
[00338] FIGs. 32
to 34 are diagrams for EPG pictures of ITF
including rating information using a rating system defined in
RRT according to embodiments of the present invention,
respectively.
[00339] FIG. 32
shows an embodiment of an EPG picture on
the condition that any parental control is not set up by a
user.
[00340] Referring
to FIG. 32, in case of a channel 99-1
(adult service), contents having rating value R are provided
in order of time sequence. For instance, looking into an EPG
providing picture, a content 'Playboy Weekly' is provided on
12:00-13:00, a content 'Basic Instinct' is provided on
13:00-14:00, and a
content 'Hustler' is provided on
14:00-15:00. Yet, since a user does not perform a parental
control setting of any rating value, and more particularly, a
83

CA 02645878 2008-12-05
rating value R, the respective contents on the channel 99-1
shall not be blocks.
[00341] FIG. 33 shows an embodiment of an EPG picture or a
blocked screen according to a rating of Schedule/Content in
case that a user sets an ITF to a parental control (rating
TV-14 applied) using EPG data.
[00342] Referring to FIG. 33, a content provided on a
channel 32-1 (Fox-1 service) on 12:00-13:30 and three
contents provided on a channel 99-1 (ADULT service) on
12:00-15:00 by a unit of hour are blocked according to user's
setup. However, the channel 99-1 itself is not blocked.
[00343] FIG. 34 shows an embodiment of a blocked EPG
picture for a virtual channel according to a user's parental
control setup (rating TV-14 applied) using SI data according
to the present invention. In case of FIG. 34, assume that the
block on Schedule/Content is performed together with the EPG
picture block for the virtual channel using EPG data. In case
of FIG. 33, each content is blocked according to a user's
setup. On the contrary, in case of FIG. 34 according to one
embodiment of the present invention, a corresponding virtual
channel itself is blocked. And, EPG data is blocked together
with the corresponding virtual channel.
[00344] Accordingly, the present invention enables an ITF
to perform a parental control on each virtual channel using
84

CA 02645878 2012-08-23
50514-47
parental control information included in SI data, thereby
providing a safer IPTV service.

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date 2014-09-02
(22) Filed 2008-12-05
Examination Requested 2008-12-05
(41) Open to Public Inspection 2009-06-05
(45) Issued 2014-09-02

Abandonment History

There is no abandonment history.

Maintenance Fee

Last Payment of $473.65 was received on 2023-11-08


 Upcoming maintenance fee amounts

Description Date Amount
Next Payment if standard fee 2024-12-05 $624.00
Next Payment if small entity fee 2024-12-05 $253.00

Note : If the full payment has not been received on or before the date indicated, a further fee may be required which may be one of the following

  • the reinstatement fee;
  • the late payment fee; or
  • additional fee to reverse deemed expiry.

Patent fees are adjusted on the 1st of January every year. The amounts above are the current amounts if received by December 31 of the current year.
Please refer to the CIPO Patent Fees web page to see all current fee amounts.

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Request for Examination $800.00 2008-12-05
Application Fee $400.00 2008-12-05
Maintenance Fee - Application - New Act 2 2010-12-06 $100.00 2010-11-25
Maintenance Fee - Application - New Act 3 2011-12-05 $100.00 2011-11-09
Maintenance Fee - Application - New Act 4 2012-12-05 $100.00 2012-10-22
Maintenance Fee - Application - New Act 5 2013-12-05 $200.00 2013-11-29
Final Fee $462.00 2014-05-14
Maintenance Fee - Patent - New Act 6 2014-12-05 $200.00 2014-10-15
Maintenance Fee - Patent - New Act 7 2015-12-07 $200.00 2015-11-05
Maintenance Fee - Patent - New Act 8 2016-12-05 $200.00 2016-11-03
Maintenance Fee - Patent - New Act 9 2017-12-05 $200.00 2017-11-08
Maintenance Fee - Patent - New Act 10 2018-12-05 $250.00 2018-11-09
Maintenance Fee - Patent - New Act 11 2019-12-05 $250.00 2019-11-08
Maintenance Fee - Patent - New Act 12 2020-12-07 $250.00 2020-11-12
Maintenance Fee - Patent - New Act 13 2021-12-06 $255.00 2021-11-15
Maintenance Fee - Patent - New Act 14 2022-12-05 $254.49 2022-11-11
Maintenance Fee - Patent - New Act 15 2023-12-05 $473.65 2023-11-08
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
LG ELECTRONICS INC.
Past Owners on Record
LEE, JOON HUI
SONG, JAE HYUNG
THOMAS, GOMER
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Representative Drawing 2009-05-12 1 20
Abstract 2008-12-05 1 27
Description 2008-12-05 84 3,054
Claims 2008-12-05 5 162
Drawings 2008-12-05 35 1,099
Cover Page 2009-06-03 2 62
Description 2012-08-23 85 3,056
Claims 2012-08-23 4 112
Cover Page 2014-08-07 2 62
Description 2013-08-30 87 3,159
Claims 2013-08-30 5 151
Assignment 2008-12-05 3 108
Prosecution-Amendment 2009-03-20 1 36
Prosecution-Amendment 2012-02-24 3 82
Prosecution-Amendment 2012-08-23 20 598
Prosecution-Amendment 2013-05-01 3 123
Prosecution-Amendment 2013-08-30 24 960
Correspondence 2014-02-07 1 55
Correspondence 2014-05-14 2 75