Method of processing data in internet protocol television receiver and internet protocol television receiver

0001This application is a reissue of U.S. patent application Ser. No. 12/382,236, filed on Mar. 11, 2009, now U.S. Pat. No. 8,554,923, issued on Oct. 8, 2013, which claims the benefit of U.S. Provisional Application No. 61/038,423, filed on Mar. 21, 2008, which is hereby incorporated by reference as if fully set forth herein. Also, this application claims the benefit of U.S. Provisional Application No. 61/042,255, filed on Apr. 3, 2008, which is hereby incorporated by reference as if fully set forth herein. This application also claims the benefit of Korean Application No. 10-2009-0003308, filed on Jan. 15, 2009, which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

00021. Field of the Invention

0003The present invention relates to an Internet protocol television (IPTV) system, and more particularly, to a method of processing data in an IPTV receiver and such an IPTV receiver.

00042. Discussion of the Related Art

0005An existing TV system may be implemented, for example, in the following manner. A cable broadcast provider, terrestrial broadcast provider or satellite broadcast provider transmits contents produced by broadcasters via a transmission medium such as a broadcasting network. Therefore, the user of the TV system can watch the transmitted contents through a TV receiver capable of receiving the transmitted contents via the transmission medium.

0006However, as digital TV technologies based on digital broadcasting are developed and are commercially available, breaking from existing analog broadcasting, various contents including real-time broadcasts, Contents on Demand (CoD), games and news can be provided to the user using an Internet network connected to each home, besides existing transmission media.

0007Such an IPTV receiver providing various contents using an Internet network has various advantages. For example, differently from general terrestrial broadcasting, cable broadcasting or satellite broadcasting, the user can watch a desired content at a desired time.

0008On the other hand, recently, there has been a discussion on improvements in network-related problems, etc. in an IPTV broadcasting environment. However, a concrete protocol capable of solving such problems has not been defined.

SUMMARY OF THE INVENTION

0009Accordingly, the present invention is directed to a method of processing data in an IPTV receiver and such an IPTV receiver that substantially obviate one or more problems due to limitations and disadvantages of the related art.

0010An object of the present invention is to provide a method of processing data in an IPTV receiver and such an IPTV receiver that can improve network-related problems in an IPTV broadcasting environment.

0011Another object of the present invention is to definitely define a data protocol capable of rapidly processing various contents (for example, CoD) in an IPTV broadcasting environment in which an IP multimedia subsystem (IMS) is introduced.

0012Additional advantages, objects, and features of the invention will be set forth in part 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 the invention may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

0013To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, a method of processing data in an Internet protocol television (IPTV) receiver includes: receiving location information necessary to acquire a content corresponding to a content reference identifier (CRID) by using the CRID; requesting an Internet protocol multimedia subsystem Gateway (IG) to transmit a session description protocol (SDP) file of the content, wherein the content is identified by the CRID and an instance metadata identifier (IMI); receiving the requested SDP file from the IG; and controlling a session setup for processing the content by using the received location information and the received SDP file.

0014In another aspect of the present invention, a method of processing data in an Internet protocol television (IPTV) receiver includes: receiving location information necessary to acquire a content corresponding to a content reference identifier (CRID) by using the CRID; requesting an Internet protocol multimedia subsystem Gateway (IG) to transmit a session description protocol (SDP) file of the content, wherein the content is identified by the CRID and an instance metadata identifier (IMI); requesting a content server to transmit the SDP file if the requesting is completed; transmitting the received SDP file to an open IPTV terminal function (OITF), wherein the received SDP file is received from the content server; and controlling a session setup for processing the content by using the received location information and the received SDP file.

0015In a further aspect of the present invention, an Internet protocol television (IPTV) receiver includes: a first receiving unit receiving location information necessary to acquire a content corresponding to a content reference identifier (CRID) by using the CRID; a requesting unit requesting an Internet protocol multimedia subsystem Gateway (IG) to transmit a session description protocol (SDP) file of the content, wherein the content is identified by the CRID and an instance metadata identifier (IMI); a second receiving unit receiving the requested SDP file from the IG; and a controlling unit controlling a session setup for processing the content by using the received location information and the received SDP file.

0016It 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 intended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

0017The 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:

0018<figref idref="DRAWINGS">FIG. 1</figref> is a view illustrating a data processing process of a system including an IPTV receiver according to one embodiment of the present invention;

0019<figref idref="DRAWINGS">FIG. 2</figref> is a view illustrating an overall content referencing process in an IPTV broadcasting environment according to one embodiment of the present invention;

0020<figref idref="DRAWINGS">FIGS. 3 and 4</figref> are views showing a location resolution schema structure in an IPTV broadcasting environment according to one embodiment of the present invention;

0021<figref idref="DRAWINGS">FIG. 5</figref> is a view showing a content referencing table in an IPTV broadcasting environment according to one embodiment of the present invention;

0022<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating a data processing process of an IPTV receiver according to one embodiment of the present invention; and

0023<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram showing constituent elements of an IPTV receiver according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

0024Reference 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.

0025In addition, although the terms used in the present invention are selected from generally known and used terms, some of the terms mentioned in the description of the present invention have been selected by the applicant at his or her discretion, the detailed meanings of which are described in relevant parts of the description herein. Furthermore, it is required that the present invention is understood, not simply by the actual terms used but by the meaning of each term lying within.

0026<figref idref="DRAWINGS">FIG. 1</figref> illustrates a data processing process of a system including an IPTV receiver according to one embodiment of the present invention.

0027As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the system including the IPTV receiver according to one embodiment of the present invention may be made up of, for example, an open IPTV terminal function (OITF) <b>100</b>, an Internet protocol multimedia subsystem Gateway (IG) <b>110</b>, and a service server <b>120</b>. Particularly, with reference to <figref idref="DRAWINGS">FIG. 1</figref>, a description will be given of a concrete method of processing various contents when the IG <b>110</b> is additionally provided on a network differently from an existing IPTV broadcasting environment.

0028The service server <b>120</b> may include, for example, a metadata control <b>121</b>, an Authentication and Session Management (ASM) <b>122</b>, and a cluster control (CC) <b>123</b>. The IPTV receiver according to one embodiment of the present invention may include only the OITF <b>100</b> or both the OITF <b>100</b> and IG <b>110</b>.

0029In an IPTV broadcasting environment according to one embodiment of the present invention, when the OITF <b>100</b> receives a signal for selection of a specific content (for example, CoD) (S<b>101</b>), it transmits a content reference identifier (CRID) resolution request signal corresponding to the specific content to the metadata control <b>121</b> by using a CRID (S<b>102</b>). Then, the metadata control <b>121</b> transmits location information necessary to acquire the specific content to the OITF <b>100</b> (S<b>103</b>). Here, the CRID resolution may mean, for example, a process of acquiring location information from a given CRID or acquiring a different CRID.

0030Also, the OITF <b>100</b> requests the IG <b>110</b> to transmit a session description protocol (SDP) file corresponding to the specific content, which is identified by the CRID and an instance metadata identifier (IMI) (S<b>104</b>). When the requesting is completed (S<b>104</b>), the IG <b>110</b> requests the metadata control <b>121</b> to transmit the SDP file (S<b>105</b>). Also, the metadata control <b>121</b> transmits the SDP file requested at step S<b>105</b> to the IG <b>110</b> (S<b>106</b>), and the IG <b>110</b> transmits the transmitted SDP file to the OITF <b>100</b> (S<b>107</b>).

0031As a result, because the OITF <b>100</b> has received both the location information and SDP file of the specific content, it can control a session setup process based on the received location information and the received SDP file.

0032The OITF <b>100</b> transmits a request signal for a session setup for processing of the content to the IG <b>110</b> (S<b>108</b>). The IG <b>110</b> transmits a session initiation protocol (SIP) invite signal to the ASM <b>122</b> (S<b>109</b>), and the ASM <b>122</b> transmits the session setup request signal to the CC <b>123</b> (S<b>110</b>). Also, the CC <b>123</b> transmits a service session respond signal to the ASM <b>122</b> (<b>5111</b>), and the ASM <b>122</b> forwards the service session respond signal to the IG <b>110</b> (S<b>112</b>). Then, the IG <b>110</b> transmits a session setup response signal to the OITF <b>100</b> (S<b>113</b>).

0033On the other hand, although the metadata control <b>121</b>, ASM <b>122</b> and CC <b>123</b> have been illustrated in <figref idref="DRAWINGS">FIG. 1</figref> and the associated description, they may be replaced by other modules or servers included in a content server.

0034The location information can be designed to include a session initiation protocol-uniform resource identifier (SIP-URI), and the SDP file can be designed to include a streaming multimedia initiation parameter constituting the content. For detailed example, the SDP file may include media flow information (for example, a media detail, a transport address, session description metadata, etc.) constituting the content.

0035Therefore, the use of one embodiment of the present invention designed as in <figref idref="DRAWINGS">FIG. 1</figref> makes it possible to secure both an SIP-URI and SDP file prior to a session setup process in an IG-added IPTV broadcasting environment, thereby processing all various contents.

0036Also, according to another embodiment of the present invention, it is possible to identify each content using a content reference identifier (CRID). Further, for display of a content selected by the user, location information necessary to acquire a content corresponding to the CRID is acquired through a CRID location resolution process. For example, as shown in <figref idref="DRAWINGS">FIG. 2</figref> (a view illustrating an overall content referencing process in an IPTV broadcasting environment according to one embodiment of the present invention), a content selected by the user is identified by a CRID, location information including the location of an instance of the content is extracted through a location resolving process for the CRID, and the content can thus be consumed.

0037For reference, the content may be, for example, a movie “Spiderman”, and the instance may be, for example, “Spiderman-HD level picture quality”, “Spiderman-SD level picture quality” or “Spiderman-mobile picture quality”.

0038<figref idref="DRAWINGS">FIGS. 3 and 4</figref> show a location resolution schema structure in an IPTV broadcasting environment according to one embodiment of the present invention. For reference, <figref idref="DRAWINGS">FIGS. 3 and 4</figref> correspond to one schema structure, which is shown separately in two figures due to restriction in the size of the drawing.

0039As shown in <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, details of location information corresponding to a CRID detected through a CRID resolution process are defined in Location Result Type, and the location information can be transmitted in a content referencing table.

0040<figref idref="DRAWINGS">FIG. 5</figref> shows a content referencing table in an IPTV broadcasting environment according to one embodiment of the present invention.

0041As shown in <figref idref="DRAWINGS">FIG. 5</figref>, a first result record includes location information (locator) of “dvb://233a.4000.4740; b028@2007-04-24T00:00:00Z/PT04H00M”, which is a resolution result of a CRID corresponding to “crid://bbc.co.uk/1195421736”.

0042That is, as shown in <figref idref="DRAWINGS">FIGS. 1 to 5</figref>, in one embodiment of the present invention, an SIP-URI is transmitted in location information (this may be referred to as a “locator”), and a protocol for transmission of an SDP prior to a session setup is more definitely defined.

0043On the other hand, steps S<b>102</b> and S<b>103</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> may be collectively named a CRID resolution process, which is a process of searching for location information, or locator. According to another embodiment of the present invention, this CRID resolution process can be implemented in two ways.

0044Firstly, the CRID resolution process can be implemented using a step of receiving a content referencing table through broadband content guide (BCG) information, and a step of detecting the same location information as that of the CRID from among location information defined in the table.

0045The aforementioned first method is useful when the BCG information is received in a multicast mode. In this method, a CRID resolution result is transmitted in the BCG information. Also, because this method corresponds to the case where an IPTV receiver has already received and held program information and instance description metadata, the IPTV receiver can complete the CRID resolution process by using a process of searching the content referencing table for a result having the same CRID value.

0046On the other hand, for reference, the BCG information includes detailed information, connection locations, service provider information, service channels, etc. about various contents in an IPTV broadcasting environment. Further, the BCG information may include stream connection information based on a real-time streaming protocol/real-time transport protocol (RTSP/RTP), so that the IPTV receiver may make a direct connection to a streaming server.

0047Accordingly, the use of the above-stated first method is advantageous in that location information, an SDP file, etc. may be transmitted in an extended BCG.

0048Secondly, the CRID resolution process can be implemented using a step of transmitting a CRID to a location resolution server, and a step of receiving a content referencing table including the same location information as that of the CRID from the server.

0049The aforementioned second method is useful when a CRID resolution is carried out over a duplex channel. In this method, the CRID is transmitted to the location resolution server, and the content referencing table, which is a resolution result, is received from the server. The use of this method is advantageous in that a relatively small amount of BCG information is transmitted to an IPTV receiver because only program information is contained in the BCG information transmitted to the IPTV receiver. Accordingly, the content provision can be performed more rapidly.

0050Meanwhile, in the present invention, as seen from steps S<b>104</b>, S<b>105</b>, S<b>106</b> and S<b>107</b> of <figref idref="DRAWINGS">FIG. 1</figref>, a definition is given of a method of acquiring an SDP file through a separate transaction in an IG-added IPTV broadcasting environment.

0051If the CRID location resolution process is completed through steps S<b>102</b> and S<b>103</b> of <figref idref="DRAWINGS">FIG. 1</figref>, the OITF <b>100</b> requests a content server (for example, a location resolution server, metadata control or the like) to transmit an SDP file necessary to process an instance of the specific content, and then receives the SDP file from the content server. This has an advantage that there is no need to change BCG information even when there is a change in the contents of the SDP file.

0052On the other hand, in order to request the SDP file, there is a need for a CRID corresponding to the content, and an IMI corresponding to a specific instance belonging to the content. One unique content instance can be identified by a combination of the CRID and IMI. Of course, in some cases, provided that one CRID has only one instance, the content can be identified by only the CRID.

0053Also, the SDP file receiving process (for example, steps S<b>104</b>, S<b>105</b>, S<b>106</b> and S<b>107</b> of <figref idref="DRAWINGS">FIG. 1</figref>) may be performed before the OITF requests the session setup to the IG. Alternatively, after the OITF requests the session setup to the IG, the IG may request the SDP file, receive the SDP file to complete the session setup, and then transmit the SDP file to the OITF together with a session setup result.

0054<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating a data processing process of an IPTV receiver according to one embodiment of the present invention. With reference to <figref idref="DRAWINGS">FIG. 6</figref>, a detailed description will hereinafter be given of the operation of the IPTV receiver of rapidly processing various contents in an IG-added IPTV broadcasting environment by transmitting an SDP file using a separate transaction as stated above.

0055The user of the IPTV receiver selects a desired content (S<b>601</b>). That is, a control signal at step S<b>601</b> is transmitted to the IPTV receiver. Also, the IPTV receiver determines whether it already has information about authority of a CRID corresponding to the selected content (S<b>602</b>). That is, this step S<b>602</b> is a process of determining whether the IPTV receiver can perform a CRID resolution in a local area without communication with a server, etc.

0056In the case where it is determined at step S<b>602</b> that the IPTV receiver has the authority information, the IPTV receiver performs the CRID resolution in the local area (S<b>603</b>) and then determines whether the CRID resolution has succeeded (S<b>604</b>).

0057In the case where it is determined at step S<b>602</b> that the IPTV receiver does not have the authority information or in the case where it is determined at step S<b>604</b> that the CRID resolution has not succeeded, the IPTV receiver requests the CRID resolution to a remote location resolution server (S<b>610</b>). Subsequently to step S<b>610</b>, the IPTV receiver determines whether the CRID resolution has succeeded (S<b>611</b>).

0058If it is determined at step S<b>604</b> or S<b>611</b> that the CRID resolution has succeeded, the IPTV receiver requests the CRID resolution server to transmit an SDP file by using the CRID and IMI corresponding to the content (S<b>605</b>). Here, the CRID resolution server may be replaced by a different server in a content server.

0059Also, the IPTV receiver determines whether the requesting at step S<b>605</b> has succeeded (S<b>606</b>). In the case where it is determined at step S<b>606</b> that the requesting has succeeded, the IPTV receiver can receive the SDP file. As an alternative, consideration may be given to a method in which the IPTV receiver receives only an SDP uniform resource locator (URL) and then accesses the SDP URL to receive the SDP file.

0060On the other hand, in the case where it is determined at step S<b>606</b> that the requesting has not succeeded or in the case where it is determined at step S<b>611</b> that the CRID resolution has not succeeded, the IPTV receiver can display an error state (S<b>612</b>). Conversely, in the case where it is determined at step S<b>606</b> that the requesting has succeeded, the IPTV receiver requests a session setup to an IG using an SIP-URI in location information and the SDP file (S<b>607</b>). Then, the IPTV receiver determines whether the session setup has succeeded (S<b>608</b>).

0061In the case where it is determined at step S<b>608</b> that the session setup has succeeded, the IPTV receiver consumes the content (S<b>609</b>). Conversely, if it is determined at step S<b>608</b> that the session setup has not succeeded, the IPTV receiver proceeds to step S<b>612</b>.

0062<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram showing constituent elements of an IPTV receiver according to one embodiment of the present invention. Hereinafter, with reference to <figref idref="DRAWINGS">FIG. 7</figref>, a description will be given of one embodiment of the present invention that processes contents in an IPTV broadcasting environment in which an IG (IMS Gateway or Internet protocol multimedia subsystem Gateway) is additionally provided.

0063The IPTV receiver according to one embodiment of the present invention may be designed to include an OITF <b>700</b>, but not include an IG <b>750</b>, or designed to include both the OITF <b>700</b> and IG <b>750</b>. Also, the configuration of <figref idref="DRAWINGS">FIG. 7</figref> is nothing but one embodiment, and the scope of the present invention should be in principle determined by the appended claims, not by <figref idref="DRAWINGS">FIG. 7</figref>.

0064The OITF <b>700</b> includes a network interface <b>701</b>, TCP/IP manager <b>702</b>, service delivery manager <b>703</b>, demultiplexer (Demux) <b>705</b>, PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b>, audio decoder <b>706</b>, video decoder <b>707</b>, display A/V and OSD module <b>708</b>, service control manager <b>709</b>, service discovery manager <b>710</b>, metadata manager <b>712</b>, SI&amp;metadata DB <b>711</b>, UI manager <b>714</b>, and service manager <b>713</b>.

0065The network interface <b>701</b> receives packets from a network and transmits packets to the network. That is, the network interface <b>701</b> receives a service, content, etc. from a service provider over the network.

0066The TCP/IP manager <b>702</b> engages in packet delivery from sources to destinations with respect to a packet which is received by the OITF <b>700</b> and a packet which is transmitted by the OITF <b>700</b>. Also, the TCP/IP manager <b>702</b> classifies received packets such that the received packets correspond to appropriate protocols, and outputs the classified packets to the service delivery manager <b>703</b>, service discovery manager <b>710</b>, service control manager <b>709</b>, and metadata manager <b>712</b>.

0067The service delivery manager <b>703</b> takes charge of control of service data received. For example, the service delivery manager <b>703</b> may use an RTP/RTCP for control of real-time streaming data. When the real-time streaming data is transmitted using the RTP, the service delivery manager <b>703</b> parses the received data packet according to the RTP and delivers the parsed packet to the demultiplexer <b>705</b> or stores the parsed packet in the SI&amp;metadata DB <b>711</b> under control of the service manager <b>713</b>. Also, the service delivery manager <b>703</b> feeds information received from the network back to a service providing server using the RTCP.

0068The demultiplexer <b>705</b> demultiplexes a received packet into audio data, video data, program specific information (PSI) data, etc. and transmits the audio data, video data, PSI data, etc. to the audio and video decoders <b>706</b> and <b>707</b> and the PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b>, respectively.

0069The PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b> decodes service information such as program specific information (PSI). That is, the PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b> receives and decodes a PSI section, a Program and Service Information Protocol (PSIP) section, a DVB-service information (SI) section, etc. demultiplexed by the demultiplexer <b>705</b>.

0070Also, the PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b> decodes the received sections to create a database about the service information, and stores the database about the service information in the SI&amp;metadata DB <b>711</b>.

0071The audio and video decoders <b>706</b> and <b>707</b> decode audio data and video data received from the demultiplexer <b>705</b>, respectively. The audio data decoded by the audio decoder <b>706</b> and the video data decoded by the video decoder <b>707</b> are provided, to the user through the display A/V and OSD module <b>708</b>.

0072The UI manager <b>714</b> and the service manager <b>713</b> manage the entire state of the OITF <b>700</b>, provide a user interface and manage other managers.

0073The UI manager <b>714</b> provides a graphic user interface (GUI) for the user using an on-screen display (OSD), etc., and receives a key input from the user and performs an operation of the receiver based on the key input. For example, if the UI manager <b>714</b> receives a key input for channel selection from the user, then it transmits the received key input to the service manager <b>713</b>.

0074The service manager <b>713</b> controls service-associated managers such as the service delivery manager <b>703</b>, service discovery manager <b>710</b>, service control manager <b>709</b>, and metadata manager <b>712</b>.

0075Also, the service manager <b>713</b> creates a channel map, and selects a channel by using the channel map based on the key input received from the user interface (UI) manager <b>714</b>. The service manager <b>713</b> receives service information of the selected channel from the PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b> and sets an audio/video packet identifier (PID) of the selected channel in the demultiplexer <b>705</b> based on the received service information.

0076The service discovery manager <b>710</b> provides information required for selection of a service provider. If the service discovery manager <b>710</b> receives a signal for channel selection from the service manager <b>713</b>, then it searches for a corresponding service using the information.

0077The service control manager <b>709</b> takes charge of selection and control of a service. For example, the service control manager <b>709</b> performs the service selection and control by using an IGMP or RTSP when the user selects a live broadcasting service as in an existing broadcasting system, and by using the RTSP when the user selects a service such as Video On Demand (VOD). The RTSP can provide a trick mode for real-time streaming. Also, the service control manager <b>709</b> can initiate and manage a session through an IMS gateway by using an IP multimedia subsystem (IMS) and a session initiation protocol (SIP). These protocols are nothing but one embodiment and different protocols may be used according to different embodiments.

0078The metadata manager <b>712</b> manages service-associated metadata and stores the metadata in the SI&amp;metadata DB <b>711</b>.

0079The SI&amp;metadata DB <b>711</b> stores the service information decoded by the PSI&amp;(PSIP and/or DVB-SI) decoder <b>704</b>, the metadata managed by the metadata manager <b>712</b>, and the information required for service provider selection provided by the service discovery manager <b>710</b>. Also, the SI&amp;metadata DB <b>711</b> may store setup data of a system, etc.

0080This SI&amp;metadata DB <b>711</b> may be implemented by a Non-Volatile RAM (NVRAM) or flash memory.

0081On the other hand, the IG <b>750</b> is a gateway that collects functions necessary to access an IMS-based IPTV service based on an IMS core network. This IG <b>750</b> includes an IG-OITF server <b>751</b>, network discovery <b>753</b>, authentication/session management client/server <b>752</b>, and RMS <b>754</b>.

0082The OITF <b>700</b> can use the IMS-based IPTV service by interfacing with the IG <b>750</b>. The IG <b>750</b> and the OITF <b>700</b> are interconnected via, for example, an HN-IGI interface, which can process a function provided by the IG <b>750</b> such that the OITF <b>700</b> can use the IMS-based IPTV service.

0083The IG-OITF server <b>751</b> provides a function of the authentication/session management client/server <b>752</b> to the OITF <b>700</b>. The IG-OITF server <b>751</b> can provide the function of the authentication/session management client/server <b>752</b> to the OITF <b>700</b> through a protocol such as a hypertext transfer protocol (HTTP).

0084The network discovery <b>753</b> searches for an IMS server and performs an access to the IMS server.

0085The authentication/session management client/server <b>752</b> performs subscriber authentication, and session management required on a managed network.

0086The RMS <b>754</b> performs a remote management function in a managed environment.

0087Hereinafter, the operation of an IPTV receiver according to one embodiment of the present invention will be described with reference to <figref idref="DRAWINGS">FIGS. 1, 6 and 7</figref>. Here, the IPTV receiver may be designed to include an OITF, but not include an IG, or designed to include both the OITF and IG.

0088A first receiving unit of the OITF <b>700</b> receives location information necessary to acquire a content corresponding to a CRID by using the CRID. Here, the network interface <b>701</b> and the TCP/IP manager <b>702</b> may be designed to take charge of the function of the first receiving unit.

0089A requesting unit of the OITF <b>700</b> requests the IG <b>750</b> to transmit an SDP file of the content, which is identified by the CRID and an IMI. Here, the service control manager <b>709</b> may be designed to take charge of the function of the requesting unit.

0090A second receiving unit of the OITF <b>700</b> receives the requested SDP file from the IG <b>750</b>. Here, the network interface <b>701</b> and the TCP/IP manager <b>702</b> may be designed to take charge of the function of the second receiving unit. Also, the first and second receiving units may be implemented into a single receiving unit.

0091A controlling unit of the OITF <b>700</b> controls a session setup for processing the content by using the received location information and the received SDP file. Here, the service discovery manager <b>710</b> and the metadata manager <b>712</b> may be designed to take charge of the function of the controlling unit.

0092For example, according to one embodiment of the present invention, the location information is designed to include an SIP-URI, and the SDP file is designed to include a streaming multimedia initiation parameter constituting the content.

0093As stated above in conjunction with <figref idref="DRAWINGS">FIGS. 1 to 7</figref>, according to one embodiment of the present invention, an SIP-URI and an SDP file are provided in an extended BCG in an IMS-based IPTV broadcasting environment, thereby making it possible to implement a session setup operation, which is a precondition for reception of various contents.

0094Alternatively, according to another embodiment of the present invention, an SDP file may be signaled through a separate URL, not included in a BCG. Therefore, it is possible to reduce the data size of BCG information and solve a problem that the BCG information must be updated whenever the SDP file is updated.

0095Therefore, provided that the present invention is applied to an IPTV broadcasting system, it is possible to improve network-related problems in an IPTV broadcasting environment.

0096Further, provided that the present invention is applied to an IPTV broadcasting system, it is possible to definitely define a data protocol capable of rapidly processing various contents (for example, CoD) in an IPTV broadcasting environment in which an IMS is introduced.

0097In addition, provided that the present invention is applied to an IPTV broadcasting system, it is possible to provide an SDP file in an extended BCG while maintaining backward compatibility with an existing IPTV system.

0098The method described herein may be presented in the form of a program command, which may be executed through a diversity of computer devices, so as to be recorded (or written) in a computer readable medium. Herein, the computer readable medium may include a program command, a data file, and a data structure individually or in combination. The program command recorded in the medium may correspond either to a device (or medium) specially designed for the embodiment of the present invention or to a usable device (or medium) disclosed to a computer software manufacturer. Examples of computer readable media may include a hard disk, magnetic media (e.g., floppy disks and magnetic tapes), a CD-ROM, optical media such as DVD, magneto-optical media such as floptical disks, and a hardware device specially configured to store and perform program commands, such as ROM, RAM, and flash memories. Examples of the program command may include a machine language code created by a compiler, as well as a high-level language code that can be executed by the computer using an interpreter. The above-described hardware device may be configured to be operated using at least one software module in order to perform an operation, and vice versa.

0099It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the inventions. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.