Source: https://patents.google.com/patent/US8387097B2/en
Timestamp: 2018-04-19 12:31:15
Document Index: 87338475

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 61', 'Application No. 61', 'Application No. 10']

US8387097B2 - Digital broadcasting system and method of processing data in the digital broadcasting system - Google Patents
Digital broadcasting system and method of processing data in the digital broadcasting system Download PDF
US8387097B2
US8387097B2 US12197990 US19799008A US8387097B2 US 8387097 B2 US8387097 B2 US 8387097B2 US 12197990 US12197990 US 12197990 US 19799008 A US19799008 A US 19799008A US 8387097 B2 US8387097 B2 US 8387097B2
US12197990
US20090064244A1 (en )
Pil Sup Shin
A digital broadcasting system and a data processing method are disclosed. A receiving system of the digital broadcasting system includes a baseband processor, a table handler, a FLUTE handler, and a display module. The baseband processor receives a broadcast signal including mobile service data and main service data. Herein, the mobile service data may configure an RS frame. And, the RS frame may include mobile service data, file data, and a table having at least one channel configuration information on the mobile service data and estimated download time for the file data described therein. The table handler parses the table from the RS frame, thereby extracting and outputting at least one channel configuration information on the mobile service data and estimated download time information of the file data. The FLUTE handler parses the file data from the RS frame and storing the parsed data. And, the display module receives the estimated download time for the file data parsed by the FLUTE handler from the table handler, thereby displaying the estimated download time on a portion of a display screen.
This application claims the benefit of U.S. Provisional Patent Application No. 60/957,714, filed on Aug. 24, 2007, U.S. Provisional Patent Application No. 60/974,084, filed on Sep. 21, 2007, U.S. Provisional Patent Application No. 60/977,379, filed on Oct. 4, 2007, U.S. Provisional Patent Application No. 61/044,504 filed on Apr. 13, 2008, U.S. Provisional Patent Application No. 61/076,686, filed on Jun. 29, 2008 and Korean Patent Application No. 10-2008-0082481, filed on Aug. 22, 2008, which are hereby incorporated by reference as if fully set forth herein.
Another object of the present invention is to provide a receiving system and a data processing method that can service (or provide) the user with an estimated download time of file data being received through a file delivery over unidirectional transport (FLUTE) protocol.
To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, a receiving system includes a baseband processor, a table handler, a file delivery over unidirectional transport (FLUTE) handler, and a display module. The baseband processor receives a broadcast signal including mobile service data and main service data. Herein, the mobile service data may configure an RS frame. And, the RS frame may include mobile service data, file data, and a table having at least one channel configuration information on the mobile service data and estimated download time for the file data described therein. The table handler parses the table from the RS frame, thereby extracting and outputting at least one channel configuration information on the mobile service data and estimated download time information of the file data. The file delivery over unidirectional transport (FLUTE) handler parses the file data from the RS frame and storing the parsed data. And, the display module receives the estimated download time for the file data parsed by the FLUTE handler from the table handler, thereby displaying the estimated download time on a portion of a display screen.
Herein, at least one data group configuring the RS frame may include a plurality of known data sequences. A signaling information region may be included between a first known data sequence and a second known data sequence among the plurality of known data sequences. The signaling information region may also include transmission parameter channel (TPC) signaling data and fast information channel (FIC) signaling data.
The baseband processor may further include a known sequence detector detecting a known data sequence included in the data group. Herein, the detected known data sequence may be used for demodulating and channel-equalizing the mobile service data.
Furthermore, the table may correspond to at least one of a service map table (SMT) and an extended service map table (EMT), and an estimated download time information of the file data may be received as at least one of an ensemble level descriptor, a virtual channel level descriptor, and a component level descriptor of the table.
According to another embodiment of the present invention, a data processing method of a receiving system includes the steps of receiving a broadcast signal including mobile service data and main service data, wherein the mobile service data configures an RS frame, and wherein the RS frame comprises mobile service data, file data, and a table having at least one channel configuration information on the mobile service data and estimated download time for the file data described therein, parsing the table from the RS frame, thereby extracting and outputting at least one channel configuration information on the mobile service data and estimated download time information of the file data, parsing the file data from the RS frame and storing the parsed data, and receiving the estimated download time for the file data parsed by the FLUTE handler from the table handler, thereby displaying the estimated download time on a portion of a display screen.
FIG. 26 illustrates an exemplary protocol stack when transmitting file data via IP-based transmission according to the present invention;
FIG. 27 illustrates an example of indicating a combination service in a service_type field of an SMT according to the present invention;
FIG. 28 illustrates an example of indicating a FLUTE file delivery session in an RTP_payload_type field of an SMT according to the present invention;
FIG. 29 illustrates an exemplary bit stream syntax structure of a download time descriptor according to an embodiment of the present invention;
FIG. 30 illustrates a flow chart showing a method for receiving FLUTE file data according to an embodiment of the present invention;
FIG. 31 illustrates an example of displaying an estimated time for downloading FLUTE file data on a portion of a display screen according to the present invention; and
FIG. 32 illustrates a block view showing a structure of a digital broadcast receiving system according to another embodiment of the present invention.
RS frame mode (2 bits) Description
A third region of the FIC segment payload a channel loop region, which includes a channel_type field, a channel_activity field, a CA indicator field, a stand_alone_service_indicator field, a major_channel_num field, and a minor_channel_num field.
Meanwhile, the mobile service data and signaling information data being received by the receiving system may correspond to IP-based data or MPEG-2-based data. According to the embodiment of the present invention, the mobile service data are received in an IP datagram format.
At this point, signaling information is required in order to extract the mobile service data from the channel through which the mobile service data are being transmitted and to decode the extracted mobile service data. Such signaling information may also be referred to as “service information” or “system information”.
The signaling information may include transmission parameters and program table information. The program table information includes at least one table required for channel setting.
FIG. 26 illustrates an exemplary protocol stack when transmitting file data via IP-based transmission according to the present invention. FIG. 26 illustrates an example wherein an adaptation layer is included between the IP layer and the physical layer, so that the IP datagram and signaling information can be transmitted without using the MPEG-2 TS format. Referring to FIG. 26, in the IP layer, A/V streaming for mobile service is packetized according to a real time protocol (RTP) method. Then, the RTP packet is packetized according to a user datagram protocol (UDP). The RTP/UDP packet is then packetized according to an IP method, thereby becoming an RTP/UDP/IP packet. Hereinafter, the packetized RTP/UDP/IP packet data according to the present invention will be referred to as an IP datagram for simplicity.
Additionally, file data download is packetized according to a file transfer protocol method, and the packetized file data download is then packetized according to an asynchronous layered coding/layered coding transport (ALC/LCT) method. The ALC/LCT packet is packetized according to the UDP method. Thereafter, the ALC/LCT/UDP packet is packetized according to the IP method, thereby generating an ALC/LCT/UDP/IP packet. Hereinafter, the packetized ALC/LCT/UDP/IP packet data according to the present invention will also be referred to as an IP datagram for simplicity. Herein, a file delivery over unidirectional transport (FLUTE) protocol may be used as the file transfer protocol. In other words, the FLUTE protocol corresponds to a protocol for file data download services, such as text, audio, video, and image files and downloaded contents. In addition to the streaming service, the file data download service may include file data required for services such as HTML pages, A/V files, and ring-tone services.
Meanwhile, a UDP multicast is packetized according to the UDP method. The UDP packet is then packetized according to the IP method. Thereafter, the IP multicast is packetized according to the IP method. The adaptation layer generates an RS frame including program table information, IP datagram, identification information that can identify the program table information and IP datagram. More specifically, the adaptation layer corresponds to a data link layer that can identify IP datagram and program table information and that can connect the identified data to an upper layer, so that the upper layer can process the identified data. The RS frame is transmitted to the receiving system after being modulated according to a predetermined transmission method (e.g., VSB transmission method) in a mobile physical layer. When file data are transmitted, as described above, the receiving system should be able to receive the file data and process the received file data.
When transmitting file data, the present invention indicates that the transmitted data correspond to a combination service in a service_type field of a respective program table, such as a service map table (SMT). Herein, the combination service refers to multiple services, such as A/V service+data service (TV+data) and audio service+data service (audio+data). FIG. 27 illustrates an example of indicating a combination service in the service_type field of an SMT according to the present invention. More specifically, among the service_type field values shown in Table 2, the values that are not used, such as ‘0x04’ is used to indicate the combination service.
Also, when transmitting the file data, the present invention indicates that the transmitted data correspond to a FLUTE file delivery session in an RTP_payload_type field of a respective service map table (SMT). FIG. 28 illustrates an example of indicating a FLUTE file delivery session in the RTP_payload_type field of an SMT according to the present invention. More specifically, among the RTP_payload_type field values shown in Table 3, the values that are not used, such as ‘0x37’ is used to indicate the FLUTE file delivery session.
The present invention generates a download time descriptor. And, according to the embodiment of the present invention, the generated download time descriptor is transmitted by being included in at least one of the SMT and the EMT. Herein, the syntax structure of the SMT is shown in FIG. 17, and since FIG. 17 has already been described in detail, the description of the SMT syntax structure will be omitted for simplicity. Also, the syntax structure of the EMT is shown in FIG. 25. And, similarly, since FIG. 25 has already been described in detail, the description of the EMT syntax structure will also be omitted for simplicity. Hereinafter, according to an embodiment of the present invention, the download time descriptor will be included in the SMT and transmitted.
FIG. 29 illustrates an exemplary bit stream syntax structure of a download time descriptor est_download_time_Descriptor( ) according to an embodiment of the present invention. Referring to FIG. 29, the descriptor_tag field is an 8-bit field, which indicates that the corresponding descriptor is an est_download_time_Descriptor( ).
The descriptor_length field is an 8-bit field, which indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the est_download time_Descriptor( ).
The est_download_time field is a 32-bit field, which indicates an estimated download time for the corresponding file data. More specifically, the est_download_time field indicates the estimated time consumed for downloading the file data, wherein the value is an integer. For example, the estimated download time may be indicated in seconds.
Herein, the download time descriptor est_download_time_Descriptor( ) may be transmitted as one of an ensemble level descriptor, a virtual channel level descriptor, and a component level descriptor within at least one of the SMT and EMT.
If the download time descriptor est_download_time_Descriptor( ) is transmitted as a component level descriptor, and when using an application transmitting a single file data (or content) as a single IP datagram, it is advantageous in that the estimated time for downloading the corresponding file data can be displayed.
Alternatively, if the download time descriptor est_download_time_Descriptor( ) is transmitted as a virtual channel level descriptor, and when using an application transmitting file data (or content) associated with a single virtual channel, it is advantageous in that the estimated download time for receiving all of the corresponding file data (or contents) can be displayed.
Furthermore, if the download time descriptor est_download_time_Descriptor( ) is transmitted as an ensemble level descriptor, and when using an application transmitting file data (or content) associated with a single ensemble, it is advantageous in that the estimated download time for receiving all of the corresponding file data (or contents) can be displayed.
More specifically, the receiving system may parse the download time descriptor est_download_time_Descriptor( ) from any one of the ensemble level descriptor, the virtual channel level descriptor, and the component level descriptor of the SMT, so as to extract an estimated download time. Thereafter, the receiving system may service (or provide) the extracted estimated download time to the user in a form of on-screen display (OSD).
FIG. 30 illustrates a flow chart showing a method for receiving FLUTE file data according to an embodiment of the present invention. More specifically, when a channel including a requested mobile service is tuned and demodulated (S701), FIC is parsed from each data group of the demodulated mobile service data and then stored (or saved) (S702). Thereafter, an SMT is parsed from each ensemble, so as to be stored (S703). The FIC is transmitted by being allocated to a predetermined portion of the data group. More specifically, the FIC region allocated to each data group configures a single FIC segment. Then, such FIC segments are deinterleaved based upon each MH sub-frame, thereby creating a single completed FIC body. The SMT is included in each ensemble and then transmitted. Since the FIC structure and the detailed process for parsing the FIC, and the SMT structure and the detailed process for parsing the SMT have already been described in FIG. 1 to FIG. 24, detailed description of the same will be omitted for simplicity.
Subsequently, the receiving system verifies whether the RTP_payload_type field value of the SMT parsed in step 703 indicates a FLUTE file delivery session (S704). When it is verified, in step 704, that the RTP_payload_type field value indicates the FLUTE file delivery session, the system verifies whether the estimated download time is being received as at least one of the ensemble level descriptor, the virtual channel level descriptor, and the component level descriptor of the SMT (S705). If the download time descriptor est_download_time_Descriptor( ) is not included in any of the ensemble level descriptor, the virtual channel level descriptor, and the component level descriptor of the SMT, it is determined that the estimated download time is not received. Thus, only the corresponding file data are received and stored (S706).
Meanwhile, if the download time descriptor est_download_time_Descriptor( ) shown in FIG. 29 is received as at least one of the ensemble level descriptor, the virtual channel level descriptor, and the component level descriptor of the SMT, the download time descriptor est_download_time_Descriptor( ) is parsed to extract the estimated download time. Thereafter, while the corresponding file data are being received and stored, the extracted estimated download time is displayed on a portion of the display screen, as shown in FIG. 31. According to the embodiment of the present invention, the extracted estimated download time is displayed on a portion of the display screen in the form of an on-screen display (OSD).
If the est_download_time_Descriptor( ) is included in the component level, the estimated download time for receiving and storing file data associated with a single component is displayed on a portion of the display screen. Alternatively, if the est_download_time_Descriptor( ) is included in the virtual channel level, the estimated download time for receiving and storing file data associated with a single virtual channel is displayed on a portion of the display screen. Finally, if the est_download_time_Descriptor( ) is included in the ensemble level, the estimated download time for receiving and storing file data associated with a single ensemble is displayed on a portion of the display screen.
The receiving system of FIG. 1 may further include a FLUTE handler for processing the above-described FLUTE file data. If the file data are transmitted via IP-based transmission, as shown in FIG. 26, the FLUTE handler may be provided between the IP network stack 220 and the storage unit 290. The file data processed by the FLUTE handler may be stored in the storage unit 290. The operation of the FLUTE handler will now be described in detail.
FIG. 32 illustrates a block view showing a structure of a digital broadcast receiving system according to another embodiment of the present invention. The receiving system shown in FIG. 32 may include a host 800, a baseband processor 801, an RS frame handler 802, an A/V decoder 803, a display module 804, an FIC handler 806, an SMT handler 807, a channel/service map database (DB) 808, a FLUTE handler 809, a contents storage unit 810, and a contents processor 811. The host 800 may correspond to a CPU, or the operation controller 110 shown in FIG. 1, or the physical adaptation control signal handler 216 also shown in FIG. 1. The baseband processor 100 shown in FIG. 1 may be directly applied as the baseband processor 801 without modification. More specifically, the RS frame demodulated and error-corrected by the baseband processor 801 is outputted to the RS frame handler 802, and the FIC is outputted to the FIC handler 806.
The FIC handler 806 parses the FIC received from the baseband processor 801. Then, the FIC handler 806 stores the FIC data, which correspond to the parsed result, in the channel/service map DB 808 through the host 800. The channel/service map DB 808 stores information on all service maps that can be accessed by the receiving system. Thereafter, the channel/service map DB 808 provides the corresponding information to the host 800 when requested. Herein, the term “access” refers to whether or not the receiving system can recognize the presence of a service, regardless of whether the receiving system can consume the service or not. However, when a service provider provides a service designated only to a specific type of receiver (or receiving system), receiving systems other than the designated receiver type may not be able to access the service that is being provided. Herein, the channel/service map DB 808 may correspond to the storage unit 290 of FIG. 1.
The RS frame handler 802 processes IP-based A/V mobile service data from the RS frame transmitted from the baseband processor 801 at a constant time interval (e.g., MH frame) determined by the host 800. Thereafter, the RS frame handler 802 outputs the processed IP-based A/V mobile service data to the A/V decoder 803. The A/V mobile service data decoded by the A/V decoder 803 are provided to the user through a display screen and a speaker of the display module 804. Additionally, when an SMT section is included in the RS frame, the RS frame handler 802 outputs the SMT section to the SMT handler 807. The SMT handler 807 collects (or gathers) at least one SMT section so as to complete an SMT. Thereafter, the SMT handler 807 parses the completed SMT and stores the parsed result in the channel/service map DB 808 through the host 800. When the SMT is parsed, MH ensemble level signaling information, IP access information on each virtual channel belonging to the corresponding MH ensemble including each SMT, and IP stream component level information required for servicing (or providing) the corresponding virtual channel may be acquired.
At this point, when the service_type field of the parsed SMT has the value of ‘0x03’ (i.e., a data only service) or the value of ‘0x04’ (i.e., a combination service), the host 800 verifies whether the RTP_payload_type field value indicates the FLUTE file delivery session. If the RTP_payload_type field value is equal to ‘0x37’, i.e., if the RTP_payload_type field value indicates the FLUTE file delivery session, the host 800 controls the RS frame handler 802, so that the file data within the RS frame can be outputted to the FLUTE handler 809. The FLUTE handler 809 may further include a FLUTE memory (not shown), and may also use the channel/service map DB 808. More specifically, the FLUTE handler 809 processes the inputted file data according to a FLUTE protocol, thereby storing the processed data in the FLUTE memory or the channel/service map DB 808 and simultaneously checking whether or not a download time descriptor, shown in FIG. 29, is included the SMT. At this point, the file data are stored by download fragments. If the download time descriptor est_download_time_Descriptor( ) is included in the SMT, an estimated file data download time is extracted from the download time descriptor est_download_time_Descriptor( ), thereby displaying the extracted estimated file data download time on a portion of the display screen in the form of an on-screen display (OSD) (ref. FIG. 31).
If the est_download_time_Descriptor( ) is included in the component level, the estimated download time for receiving and storing file data associated with a single component is displayed on a portion of the display screen. Alternatively, if the est_download_time_Descriptor( ) is included in the virtual channel level, the estimated download time for receiving and storing file data associated with a single virtual channel is displayed on a portion of the display screen. Finally, if the est_download_time_Descriptor( ) is included in the ensemble level, the estimated download time for receiving and storing file data associated with a single ensemble is displayed on a portion of the display screen. Herein, the estimated download time is displayed until the reception and storage of the corresponding file data is completed. When the reception and storage of the corresponding file data is completed in the FLUTE handler 809, the file data are stored in the contents storage unit 810. The contents processor 811 activates a corresponding application in accordance with a user's request, thereby providing the file data stored in the contents storage unit 810 to the user.
As described above, when file data, such as download contents, are received through a FLUTE protocol, the digital broadcast receiving system and the data processing method according to the embodiment of the present invention may provide an estimated download time, which is required for downloading the corresponding file data, to the user, thereby enabling the user to download file data with more convenience.
receiving a broadcast signal comprising a file, a service map table (SMT), fast information channel (FIC) data, and transmission parameter channel (TPC) data,
wherein the SMT comprises Real-time Transport Protocol (RTP) payload type information for identifying an encoding format of at least one component included in the SMT and session information of the file,
wherein the SMT is included in at least one of a plurality of Reed Solomon (RS) frames belonging to an ensemble,
wherein the FIC data comprises binding information between the ensemble and mobile services included in the ensemble, and
wherein the TPC data includes FIC version information for indicating an update of the FIC data;
decoding the plurality of RS frames from the received broadcast signal;
obtaining the SMT;
obtaining the RTP payload type information from the obtained SMT and identifying the RTP payload type information; and
acquiring the file when the RTP payload type information indicates a file delivery session.
2. The method of claim 1, wherein the plurality of RS frames comprise mobile service data, and wherein the SMT further comprises access information of the mobile service data.
3. The method of claim 1, wherein the SMT further comprises download time information of the file.
4. The method of claim 1, wherein the broadcast signal further comprises known data sequences, and wherein at least two of the known data sequences are spaced 16 segments apart and at least two of the known data sequences have different lengths.
5. The method of claim 4, wherein the FIC data and the TPC data are positioned between a first known data sequence and a second known data sequence of the known data sequences.
a tuner for receiving a broadcast signal, the broadcast signal comprising a file, a service map table (SMT), fast information channel (FIC) data, and transmission parameter channel (TPC) data,
wherein the TPC data comprises FIC version information for indicating an update of the FIC data;
a decoder for decoding the plurality of RS frames from the received broadcast signal;
a first handler for obtaining the SMT;
a second handler for obtaining the RTP payload type information from the obtained SMT and identifying the RTP payload type information; and
a third handler for acquiring the file when the RTP payload type information indicates a file delivery session.
7. The broadcast receiver of claim 6, wherein the plurality of RS frames comprise mobile service data, and wherein the SMT further comprises access information of the mobile service data.
8. The broadcast receiver of claim 6, wherein the SMT further comprises download time information of the file.
9. The broadcast receiver of claim 6, wherein the broadcast signal further comprises known data sequences, and wherein at least two of the known data sequences are spaced 16 segments apart and at least two of the known data sequences have different lengths.
10. The broadcast receiver of claim 9, wherein the FIC data and the TPC data are positioned between a first known data sequence and a second known data sequence of the known data sequences.
performing, by a Reed Solomon (RS) encoder, RS encoding and Cyclic Redundancy Check (CRC) encoding on mobile service data to build RS frames belonging to an ensemble, wherein at least one of the RS frames includes a service map table (SMT) that comprises Real-time Transport Protocol (RTP) payload type information for identifying an encoding format of at least one component included in the SMT and session information of a file;
mapping each of the RS frames into a plurality of groups, wherein each of the plurality of groups comprises a portion of data included in a corresponding RS frame, known data sequences, fast information channel (FIC) data, and transmission parameter channel (TPC) data,
wherein the FIC data comprises binding information between the ensemble and mobile services included in the ensemble, and wherein the TPC data comprises FIC version information for indicating an update of the FIC data; and
12. The method of claim 11, wherein the SMT further comprises access information of the mobile service data.
13. The method of claim 11, wherein the SMT further comprises download time information of the file.
14. The method of claim 11, wherein at least two of the known data sequences are spaced 16 segments apart and at least two of the known data sequences have different lengths.
a Reed Solomon (RS) encoder for performing RS encoding and Cyclic Redundancy Check (CRC) encoding on mobile service data to build RS frames belonging to an ensemble, wherein at least one of the RS frames includes a service map table (SMT) that includes Real-time Transport Protocol (RTP) payload type information for identifying an encoding format of at least one component included in the SMT and session information of a file;
a group formatting means for mapping each of the RS frames into a plurality of groups, wherein each of the plurality of groups comprises a portion of data included in a corresponding RS frame, known data sequences, fast information channel (FIC) data, and transmission parameter channel (TPC) data,
a transmitting means for transmitting a broadcast signal comprising the plurality of groups.
17. The broadcast transmitter of claim 16, wherein the SMT further comprises access information of the mobile service data.
18. The broadcast transmitter of claim 16, wherein the SMT further comprises download time information of the file.
19. The broadcast transmitter of claim 16, wherein at least two of the known data sequences are spaced 16 segments apart and at least two of the known data sequences have different lengths.
20. The broadcast transmitter of claim 16, wherein the FIC data and the TPC data are positioned between a first known data sequence and a second known data sequence of the known data sequences.
US12197990 2007-08-24 2008-08-25 Digital broadcasting system and method of processing data in the digital broadcasting system Active 2031-01-01 US8387097B2 (en)
KR10-2008-0082481 2008-08-22
KR20080082481A KR101556125B1 (en) 2007-08-24 2008-08-22 The digital broadcasting system and a data processing method
US12197990 US8387097B2 (en) 2007-08-24 2008-08-25 Digital broadcasting system and method of processing data in the digital broadcasting system
US20090064244A1 true US20090064244A1 (en) 2009-03-05
US8387097B2 true US8387097B2 (en) 2013-02-26
ID=40506454
US12197990 Active 2031-01-01 US8387097B2 (en) 2007-08-24 2008-08-25 Digital broadcasting system and method of processing data in the digital broadcasting system
US (1) US8387097B2 (en)
US20130194996A1 (en) * 2012-01-27 2013-08-01 Ozgur Oyman Techniques for improved multicast content delivery
US20150134787A1 (en) * 2012-01-27 2015-05-14 Intel Corporation Techniques for improved multicast content delivery
US9565672B2 (en) * 2012-01-27 2017-02-07 Intel Corporation Techniques for improved multicast content delivery
US20090064244A1 (en) 2009-03-05 application
US20100162334A1 (en) 2010-06-24 Method for receiving a broadcast signal
US8165244B2 (en) 2012-04-24 Digital broadcasting system and method of processing data in digital broadcasting system
US20090074079A1 (en) 2009-03-19 Digital broadcasting system and method of processing data in digital broadcasting system
US20090052521A1 (en) 2009-02-26 Digital broadcasting system and method of processing data in digital broadcasting system
US20090079878A1 (en) 2009-03-26 Digital broadcasting system and method of processing data in digital broadcasting system
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHIN, PIL SUP;CHOI, IN HWAN;KIM, JEONG WOO;AND OTHERS;REEL/FRAME:021864/0812;SIGNING DATES FROM 20081013 TO 20081016
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHIN, PIL SUP;CHOI, IN HWAN;KIM, JEONG WOO;AND OTHERS;SIGNING DATES FROM 20081013 TO 20081016;REEL/FRAME:021864/0812