HK1113047A - Enhanced electronic service guide container - Google Patents

Description

Enhanced electronic service guide container

The present invention claims priority from U.S. provisional application serial No. 60/668,283 entitled Enhanced electronic service Guide Container, filed on 5/4/2005, the contents of which are hereby incorporated by reference in their entirety.

Technical Field

The present invention relates generally to communication networks. More particularly, the present invention relates to signaling for data aggregation within a broadcast system.

Background

Typically, an Electronic Service Guide (ESG) enables a terminal to communicate which services are available to end users and how to access those services. ESG fragments are independently existing parts of an ESG. Typically, EGS fragments contain extensible markup language (XML) documents or fragments of XML documents, but more recently they have included a large number of items, such as SDP (Session description protocol) descriptions, text files or images. The ESG fragments describe one or several aspects of currently or future available service or broadcast programs. Such aspects may include, for example: free text description, calendar, geographical availability, price, purchase method, type, and supplemental information such as picture previews or clips. Audio, video and other types of data containing ESG fragments may be transmitted through various types of networks according to a number of different protocols. For example, data may be transmitted over a collection of networks commonly referred to as the "internet" using protocols of the internet protocol suite, such as Internet Protocol (IP) and User Datagram Protocol (UDP). Data is typically sent over the internet addressed to a single user. However, data may be addressed to a group of users, commonly referred to as multicasting. In case the data is addressed to all users, this is called broadcasting.

One way of broadcasting data is to use an IP datacasting (IPDC) network. IPDC is a combination of digital broadcast and internet protocol. Through such an IP-based broadcast network, one or more providers may provide different types of IP services, including online newspapers, radio, and television. These IP services are organized into one or more media streams in the form of audio, video, and/or other types of data. In order to determine when and where these streams occur, the user refers to the ESG. One example for a Digital Video Broadcasting (DVB) stream is an Electronic Program Guide (EPG). One type of DVB is digital video broadcasting-handheld (DVB-H), a recently developed technology that increases the capabilities and services available on small handheld devices, such as mobile phones. DVB-H is designed to deliver data to battery powered terminal devices.

However, the present invention can also be used in other conventional digital mobile broadcasting systems, such as: terrestrial digital audio broadcasting (T-DAB), terrestrial/satellite digital media broadcasting (T/S-DMB), integrated services digital broadcasting-terrestrial (ISDB-T), and Advanced Television Systems Committee (ATSC), private systems such as MediaFLO/FLO, and non-legacy systems such as third generation partnership project multimedia broadcast/multicast service (3GPP MBMS) and third generation partnership project 2 broadcast/multicast service (3GPP2 BCMCS).

Since images and other large files dominate the ESG transport, there is a need to efficiently transport ESG fragments across the intended network to the end receiver. However, previous systems send the header before the ESG, which is inefficient because if the container carrying the EGS is sent before the header, the information cannot be accessed until the header arrives, and there is a risk that the header is not received and thus the information in the container is invalid. Current efforts focus on associating multiple segments, however, have been largely unsuccessful due to the lack of unique segment identification, a valid header or indexing structure, or the need to provide repetitive parameters. There is also a need in the art to make ESGs visible to end users as quickly as possible.

Disclosure of Invention

Aspects of the present invention allow ESG fragments to be efficiently delivered to a receiver through the formation of containers. In this sense, a container contains at least one ESG fragment, but may contain a plurality of fragments. Alternatively, the fragments may be carried in multiple containers. The containers are transmitted to a receiver, for example, by using Asynchronous Layer Coding (ALC)/Layered Coding Transport (LCT) such that a single ALC/LCT transport object corresponds to a single container. The fragments can be used by the receiver as soon as the entire container is received. Aspects of the present invention use a simple and extensible header structure separate from the fragments, regardless of the type and format of the individual fragments. In a further embodiment, compression is used for the entire container, including the fragments and any headers. In still further embodiments, other envelopes, such as third generation partnership project (3GPP) metadata envelopes, may be carried in the container without unnecessary repetition of parameters, such as version, time to live, and identification.

Metadata in a 3GPP envelope or in any other form may include specific channels, specific programs, and/or specific groups of channels. Other types of metadata may include: packet data, purchase data-such as operator identifier data and technical data for completing transactions, e.g. address, protocol, price data which may be packet/day, channel/minute, program/minute based; channel data such as text description for the user, content providing branding information/logos, category and rating data such as genre and parental rating, channel SDP data such as description of capabilities required to use the service, e.g. audio and video format and bit rate information, start and end times, addresses, synchronized auxiliary information provision addresses, attribute extensions; and program data such as a user's text description, start and end times, and a reference to interactive services associated with the program. The metadata may be loaded by the operator or may be done automatically.

In particular embodiments, the invention may be partially or fully implemented on computer-readable media, for example, by storing computer-executable instructions or modules or by utilizing computer-readable data structures.

Of course, the methods and systems of the above-described embodiments may also include other additional elements, steps, computer-executable instructions, or computer-readable data structures. In this regard, other embodiments are also disclosed herein.

Drawings

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:

FIG. 1 illustrates a schematic diagram of a wireless communication system in which various aspects of the present invention may be implemented;

FIG. 2 illustrates a block diagram of a mobile terminal in accordance with an aspect of the subject invention;

FIG. 3 illustrates a schematic diagram of an example transport object in accordance with an aspect of the subject invention;

FIG. 4 illustrates a method of sending multiple single object transfers in accordance with an aspect of the subject invention;

FIGS. 5a and 5b illustrate block diagrams of exemplary Electronic Service Guide (ESG) fragment descriptor entries in accordance with at least one aspect of the present invention;

fig. 6 illustrates a block diagram of an exemplary container having a plurality of ESG objects in accordance with at least one aspect of the present invention;

fig. 7 is a block diagram illustrating additional exemplary frames of ESG fragment descriptor entries in accordance with at least one aspect of the present invention;

FIG. 8 is a block diagram of a simplified container system according to one embodiment of the invention configured for updating previously received fragments;

FIG. 9 is a block diagram illustrating container and fragment management in an update system according to one embodiment of the invention;

FIG. 10 is a block diagram of a container update in accordance with an aspect of the present invention;

fig. 11 illustrates an ESG delivery scheme in accordance with an aspect of the present invention;

fig. 12 illustrates an ESG delivery scheme in accordance with an aspect of the present invention;

fig. 13 illustrates an ESG delivery scheme in accordance with an aspect of the present invention;

fig. 14 illustrates an ESG delivery scheme in accordance with an aspect of the present invention;

fig. 15 illustrates an ESG delivery scheme in accordance with an aspect of the present invention;

FIG. 16 illustrates a method of receiving data in accordance with an aspect of the subject invention;

FIG. 17 illustrates a method of processing received data in accordance with an aspect of the subject invention;

fig. 18 shows an illustrative wireless communication system example in accordance with aspects of the invention; and

fig. 19 illustrates a methodology of providing information to receivers traveling between different regions in accordance with an aspect of the subject innovation.

Detailed Description

In the following description of the various embodiments, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.

It should be noted that each connection between each element is set forth in the following description. It should be noted that these connections in general, unless specified otherwise, may be direct or indirect and that this specification is not intended to be limiting in this respect.

The present invention may be used with a variety of networks and communication protocols. Fig. 1 shows an example of a wireless communication system 110 in which the systems and methods of the present invention may be used. One or more networked mobile devices 112, such as a Personal Digital Assistant (PDA), a cellular telephone, a mobile terminal, a personal video recorder, a portable television, a personal computer, a digital camera, a digital camcorder, a portable audio device, a portable radio, or a combination thereof, communicate with a service source 122 through a broadcast network 114 and/or a cellular network 116. Mobile terminal/device 112 may comprise a digital broadcast receiving device. The service source 122 may be connected to several service providers that provide actual program content or descriptions or information about their services and programs to the service source, which further provides the content or information to the mobile device 112, which may be used or displayed to the user as an electronic service guide for selecting their services and programs. The number of service providers may include, but is not limited to, one or more television and/or digital television service providers, AM/FM radio service providers, short message service/multimedia message service (SMS/MMS) push service providers, internet network content or access providers.

The broadcast network 114 may include wireless transmission of IP datacasting over DVB-H. The broadcast network 114 may broadcast a service, such as a digital or analog television signal, and supplemental content related to the service via a transmitter 118. The broadcast network may also comprise a broadcast network of radio, television or IP datacasting technology. The broadcast network 114 may also transmit additional content, which may include television signals, audio and/or video streams, data streams, video files, audio files, software files, and/or video games. In the case of transmitting IP datacasting services, the service source 122 may transmit the actual program content to the user equipment 112 through the broadcast network 114, while additional information (e.g., user rights and access information) for the actual program content is transmitted through the cellular network 116.

The mobile device 112 may also contact the service source 122 through the cellular network 116. The cellular network 116 may include a wireless network and a base transceiver station transmitter 120. The cellular network may comprise a second/third generation (2G/3G) cellular data communication network, a global system for mobile communications network (GSM), or other wireless communication network such as a Wireless Local Area Network (WLAN).

According to an aspect of the invention, mobile device 112 may include a wireless interface configured to transmit and/or receive digital wireless communications in cellular network 116. The information received by mobile device 112 through cellular network 116 or broadcast network 114 may include user selections, applications, services, electronic images, audio clips, video clips, and/or other messages. As part of cellular network 116, one or more base stations (not shown) may support digital communications with receiver device 112 while the receiver device is located within the administrative domain of cellular network 116.

As shown in fig. 2, mobile device 112 may include processor 128 connected to user interface 130, memory 134 and/or other storage, and display 136, which may be mounted on or in housing 113. Mobile device 112 may also include battery 150, speaker 152, and antenna 154. The user interface 130 may further include a keyboard, touch screen, voice interface, one or more arrow keys, joystick, data glove (data glove), mouse, roller ball, touch screen, voice interface, and the like.

Computer-executable instructions and data used by processor 128 and other components within mobile device 112 may be stored in a computer-readable memory 134. The memory may be implemented using any combination of read only memory modules or random access memory modules, optionally including both volatile and nonvolatile memory, and optionally being detachable. Software 140 may be stored in memory 134 and/or storage to provide instructions to processor 128 for enabling mobile device 112 to perform various functions. Alternatively, some or all of mobile device 112 computer executable instructions may be embodied in hardware or firmware (not shown).

Mobile device 112 may be configured to receive, decode and process transmissions based on the Digital Video Broadcasting (DVB) standard, such as DVB-H or digital broadcast-multimedia home platform (DVB-MHP), through a specific DVB receiver 141. In addition, mobile device 112 may also be configured to receive, decode and process transmissions through FM/AM radio receiver 142, WLAN transceiver 143, and telecommunications transceiver 144. In one aspect of the invention, mobile device 112 may receive Radio Data Stream (RDS) messages.

In the example of the DVB standard, a 10Mbit/s DVB transmission may have 200 audio program channels of 50kbit/s or 50 video (TV) program channels of 200 kbit/s. Mobile device 112 may be configured to receive, decode, and process transmissions based on the DVB-H standard or other DVB standards (e.g., DVB-satellite (DVB-S), DVB-terrestrial (DVB-T), or DVB-cable (DVB-C)). Similarly, other digital transmission formats may alternatively be used to transmit content and information of availability of supplemental services, such as Advanced Television Systems Committee (ATSC), international television systems committee (NTSC), integrated services digital broadcasting-terrestrial (ISDB-T), Digital Audio Broadcasting (DAB), Digital Multimedia Broadcasting (DMB), MediaFLO, or DIRECTV. Furthermore, the digital transmission may be time sliced, for example in DVB-H technology. Time-slicing may reduce the average power consumption of the mobile terminal and may enable smooth and seamless handover. Time-slicing consists of sending data in bursts using a higher instantaneous bit rate than is required to send data using a conventional streaming mechanism. In this case, mobile device 112 may have one or more buffer memories for storing the decoded time-sliced transmission transport prior to presentation.

FIG. 3 is a schematic diagram of an example transport object in accordance with at least one aspect of the present invention. Typically, a single transport object 300 contains a container header 310 and a container payload 320. By combining the header 310 and the payload 320 in a single object 300, there is no longer a need to recombine each header with the location information of each container in a different transport object. Furthermore, there is no problem of which to transmit first as occurs in conventional systems. The container header 310 may contain configuration information about the header and/or the container payload 320. In one embodiment, the header 310 is encoded to inform the receiver of the entry length of the header.

In an exemplary embodiment, the header 310 may have a plurality of ESG fragment descriptor entries 330 that identify the ESG fragments 340 in the container payload 320 so that the receiver may determine the exact location and/or length of each contained ESG fragment 340. For example, in one embodiment, the field specifies where a particular ESG begins in the container payload 120 by providing, for example, an offset value 550, start and end points, or the like. In other embodiments, the metadata 350 may be associated with a separate ESG fragment 340, proximate to or within the header 310, descriptor entries 330, ESG fragments 340 or a mixture thereof. In an exemplary embodiment, the association of a 3GPP metadata envelope with an ESG fragment 340 may replace or negate the need for additional metadata located in the header 310 in relation to the particular ESG fragment.

FIG. 4 illustrates a method of sending multiple single object transfers, wherein the transfers are in accordance with at least one aspect of the present invention. As shown in fig. 4, the Transport Object (TO) of the present invention may be carried in, for example, a file delivery over unidirectional transport (FLUTE) session or a pure ALC session. In the example of fig. 4, ESG root channel data, such as IP address, port number and Transport Session Identifier (TSI), is announced in an IP/MAC announcement table 405(INT table). The FLUTE session of the ESG root channel contains a file delivery table 410(FDT) and one or more delivery objects (415) for the session. These transport objects in the announcement carousel 430 contain mappings between different ESG parts and access parameters for the different ESG methods used to transmit the ESG data. The ESGs may differ from each other, e.g., in different languages and/or with different coding and styles. The access parameters include IP address, port number, TSI, start and end time, etc. The FLUTE session thus states how ESG data is distributed to different sessions. The transport object 415 of the FLUTE session carrying the mapping data is described in the FDT of the FLUTE session. The ESG mapping data may be transmitted in one or more transport objects 415. The mapping may be implemented using XML schema, simple ASCII text, structured ASCII text such as multipart MIME or MIME headers, as a binary of enumerated types, or by other different means known in the art. In this example, the ESG data is transmitted in one or more transport objects in an ESG method 440, which may be a pure ALC session. The ESG data may be transmitted in one or more ESG sessions. In some embodiments of the present invention, ESG data or a portion thereof may be transmitted in one or more FLUTE sessions in addition to or instead of an ACL session.

Fig. 5a and 5b are block diagrams illustrating exemplary frames of ESG fragment descriptor entries along descriptor entries 500A through 500E in accordance with at least one aspect of the present invention. Frame 500 illustrates the format of a protocol frame for header 310 (fig. 3). Frames 502A-D with descriptor entries are illustrative examples that include a type field 505 that indicates the type and characteristics of an entry 330. The type field may be extended to allow for the addition of new types of entries. By entering the entry type in field 505, different information can be provided to the receiver. We have predefined specific metadata associated with the segments for the frame instances 502A-D. For example, in 502B, the offset field, the start field, the end field, and the basic uniform resource identifier (BaseURI) field are metadata for the corresponding fragment in the payload. In contrast, frame instance 502C does not associate any metadata for the segment it represents.

As described above, the payload may contain an envelope that associates metadata with the fragment itself (both included in the envelope) or indicates that the metadata is located in the header, or is of a type that provides an entry for a predefined parameter of an ESG fragment located in the payload. Also, as shown in frame 502C, a single descriptor entry may be configured by its type to describe multiple ESG fragments, or even different versions of the same ESG fragment. For example, the frame 502A is labeled as a type 1 entry and includes information about the ESG fragment such as location, format, version information, unique identifier. To illustrate this, the frame 502 may provide additional information fields regarding the ESG fragment 340 (fig. 3), such as the format 510, version 520, and unique identifier 530. In an exemplary embodiment, the format field 510 specifies whether the ESG fragment 500 is text, video, and/or a picture. However, those skilled in the art will appreciate that the format field 510 may specify virtually any information of the type of media contained in the ESG fragment 340.

A version field 520 may be included to allow updating of previously received ESGs. For example, newer versions of ESGs may be automatically detected and executed, whereas outdated ESG fragments specified by the version field 520 may be left unexecuted or executed at the discretion of the receiver user. This is also always useful when local services are available. For example, when a mobile terminal moves from one geographic area to another, some services may still be available, some may no longer be available, and some may become available. Thus, some ESG objects are valid in the new geographic area as they are in the original geographic area. In an embodiment, the terminal may identify the ESG objects available in the new geographic area and may store/cache the objects that are no longer valid. In another embodiment, the terminal may receive and store ESG objects from different frequencies, IP platforms, and network operators and then merge these objects with ESG objects from the current network in a unified ESG.

Optionally, the version field 520 may be combined with the validity field 570 or replaced by the validity field 570. The version field 520 may indicate whether the received ESG fragment is the most recent version or is configured to determine whether compatibility issues exist, while the validity field 570 may further distinguish unused or lower priority ESG fragments. As shown in fig. 5, one or more validity fields 570 may indicate a period of time for which the associated fragment is valid. Alternatively, validity may be based on the hardware of the receiver, user-defined settings, and/or the presence of other ESGs. For example, the location at which the node is loaded or the presence of a BaseURI, whether in the validity field 570 or other fields, may allow verification of the received ESG fragment. In other embodiments, BaseURI may allow a receiver to use the information located at the URI in conjunction with or in place of an ESG fragment.

The unique identifier field 530 allows identification of the ESG fragment regardless of the information in the container header 310. This information is useful, for example, when multiple ESGs are received, executed, or no longer associated with a header, or need to be globally identifiable. Each of the above-described information fields 510, 520, 530 may optionally contain, among other fields used, a padding field 540 to compensate for portions that do not satisfy the byte rules of the entry. For example, if the location of the ESG fragment contains a BaseURI that does not provide enough bits for the entry, the required space may be filled with ASCII characters (e.g., 0) to meet the bit requirements. As disclosed, each ESG fragment may be encoded to a different bit rate than other ESG fragments. In yet another embodiment, different bit rates may be used for different parameters in a single ESG, for example in different information fields 510, 520, 530.

The position of the ESG fragment may be obtained by utilizing the offset field 550 alone or in conjunction with the entry length field 560, where the offset of the fragment may be measured from the header, an initial point in the payload, or any other point in the transport object. The fragment offset and length values may be measured in bits, bytes, or any similar counting system. As previously described, fields using different systems (e.g., 6 bits, 10 bits, 32 bits) may all be encoded in the same descriptor entry. Each descriptor entry 500 has a fragment identification field 530 that uniquely identifies the ESG fragment. In the example descriptor entries 500C, 500D, 500E, BaseURI is appended to the fragment identification in the payload container to create a globally unique identifier.

Fig. 6 illustrates a block diagram of an exemplary container having a plurality of ESG objects in accordance with at least one aspect of the present invention. Transport object 600 has a container header 610 preceding a container payload 620, together forming a single transport object. The header 610 contains a coded portion regarding the header length 630. The header 610 may optionally contain a signaling mechanism or transport encoding mechanism configured to signal that the transport object or a portion thereof is encoded or compressed. In one embodiment, the LCT codepoint located at the start of the header 610 may signal that the entire transmission including the header is compressed. In other embodiments, the reserved field may contain a codepoint that signals the encoding for the transport object 600. As an example, the program GZIP may be used for the above purpose; however, those skilled in the art will appreciate that a variety of other schemes are possible to accomplish the purpose of compression in the manner described. In embodiments with reserved fields, additional information may optionally be included, for example relating to the ESG, the header itself, or additional compressed or encoded information. The container payload 620 contains at least one ESG fragment 640 in which some or all of the fragments have metadata (as in fig. 3). In some instances, a fragment does not have metadata, but rather any necessary metadata may be found in the header 610 associated with the appropriate descriptor entry. The transport object may be stored in a memory of the transmitter, in an intermediate transport node, and/or in a different receiver.

Fig. 7 is a block diagram illustrating additional exemplary frames of ESG fragment descriptor entries in accordance with at least one embodiment of the present invention. Frames 700, 710, 720, 730, and 740 include a type field 750 to indicate the type of frame received. As described above, the type field 750 may be extensible to allow for the addition of new types of entries. Frame 700 represents a simple ESG descriptor entry for providing the location of an ESG fragment in the payload. In the illustrated embodiment, the offset values of the ESG fragments are used to locate the fragments.

Frames 710, 720 and 730 show different types of descriptor entries that are not associated with any container payload. And frames 710, 720, and 730 may be used to verify the ESG fragments that have been received. In other embodiments, such as that shown by frame 740, the descriptor entry may contain a declaration of a BaseURI for the entire container.

In another aspect, the present invention comprises a system and method for determining whether a newly transmitted container is a valid update of a previously received container without decoding or processing information in the container payload. In at least one embodiment, the transmitter is configured to update the plurality of segments as a unit. In yet another aspect, the present invention comprises a system and method for requiring only a single instance of a container type to determine a fragment combination in every other possible instance of the same type.

FIG. 8 is a block diagram of a simplified container system according to one embodiment of the invention configured for updating previously received fragments. The system is configured to determine whether a newly transmitted container is a valid update without decoding or reading information in the container payload. The update container 800 generally includes a container header 810 and a container payload 820. In an exemplary embodiment, the header 810 contains information related to the number of fragments in the payload 820 and an associated offset value; however, it is within the scope of the present invention to include information related to the header 810 and/or the payload 820. The payload 820 contains data items 830, 840 with fragment updates. Although the present embodiment shows two data items 830, 840, the payload 820 may contain additional data items and may also convey a single data item. Each data item includes an indication of its type 850.

The container may further indicate the presence of a payload header. For example, a type 1 data item may be a binary envelope with metadata in a header 835 as shown, the header 835 being associated with a predetermined segment. Type 2 may indicate 3GPP text envelopes associated with different fragments. The metadata is not fixed at the transport layer. In addition to the above examples, other container types may be defined.

The new update system may be implemented through the configuration and management of fragment and container instances. An "instance of a fragment" or "fragment instance" relates to a particular type and version of fragment, wherein an "instance of a container" or "container instance" relates to a container that holds a particular fragment instance. FIG. 9 is a block diagram illustrating container and fragment management in an update system according to one embodiment of the invention. In an exemplary embodiment, FDTs 900 and 910 advertise instances of fragment groupings. The fragment types in each container type are determined by the receiver when the first container instance is initially received. All different container instances of the same type use the same signature-e.g., FDT content-location, but different Transport Object Identifiers (TOIs). In an exemplary embodiment, FDT 900 has a TOI of 5 and FDT 910 has a TOI of 6, thus representing different container instances, however, the content type and content-location remain unchanged. Two different container instances may use different encodings, i.e. they have different content types. For example, the container holding fragment a of version a1 and fragment B of version B1 and the container holding fragment a of version a2 and fragment B of version B2 are of the same container type. Furthermore, the container holding fragment a (independent of the version) will have a distinct container type from the container holding fragments A, B and C (of any version). Additional optional fields, such as content-encoding, may also remain in an unchanged state according to the preference of the transmitter. For example, if text metadata is used, the entire container may be encoded using, for example, GZIP or other technical mechanisms known in the art. Or some portion or portions of the container may be encoded.

Container coding and Forward Error Correction (FEC) may be declared through different mechanisms. For example, the FDT parameters may declare the encoding mechanism. In one embodiment, the coding and FEC are declared by using LCT extensions. The container is encoded such that a receiver can determine whether the container is to be decoded and processed without accessing or reading the container. FIG. 10 is a block diagram of performing a container update according to one embodiment of the invention. In this example, FDT 1010 has a TOI of 1 and corresponds to type a container 1020 having instance a1, where instance a1 may contain, for example, fragment 1: example 4 and fragment 2: example 3. The FDT 1010 and associated container 1020 are received at the terminal and processed or rejected at the terminal. FDT 1030 represents an update to FDT 1010 and is received after FDT 1010 is received. FDT 1030 still corresponds to type a container 1040, however it contains instance a2 instead of instance a1 and may contain variations such as fragment 1: example 4 no change but fragment 2: example 3 is changed to example 5. Once received, the terminal determines that instance A2 includes one or more fragment updates compared to instance A1. The terminal may further determine that a2 contains fragments of the same type as a 1. In one embodiment, the terminal further determines whether a2 is to be implemented based on a number of factors.

Fig. 11 through 16 illustrate electronic service guide delivery schemes in accordance with various aspects of the present invention. Fig. 16 illustrates an exemplary receiver method. First, in step 1610, the mobile terminal or other receiver retrieves the required XML Schema (XML Schema) file. This can be done by: pre-providing the file, retrieving the file over an interactive network, receiving the file in a broadcast file delivery session (e.g., an announce Carousel or other session), or by other means for receiving data. The receiver may also receive an instance of an ESG delivery descriptor in step 1620. This may be XML or binary, with binary instances contributing to more compression. (see FIGS. 13 and 14). The descriptor may contain one or more session elements. The ESG delivery descriptor may be delivered in an ALC transport object. There may be multiple transport objects and these transport objects may further contain partially or fully overlapping conversation elements. Thus, FDT is not required.

Next, at step 1630, for each conversation group, the receiver may store the declared ESG fragment information for each declared fragment. It should be noted that the continainerid information may optionally be used to point to the correct container exactly. Then, in step 1640, the receiver may attach to (tune to or join) the ALC/FLUTE session defined for the session unit. Thus, at step 1650, the receiver may receive the ALC transmitted object. Optionally, the TOI field may indicate the continainerid (and version). As such, the transport object may be a container (an exemplary syntax for the container is shown in fig. 15).

At step 1660, the receiver examines the container header to identify the contained segment ID/segment version pair and compares the contained or declared segment to the segment bookkeeping list. If the receiver encounters a segment that is already known to the receiver and the version of the encountered segment is equal to or less than the version already contained in the receiver, the encountered segment is skipped. The receiver then compares the list of received fragments to the list of declared fragments (in the ESG delivery descriptor) and if all of the declared fragments have been received, the receiver determines that the delivery associated with the ESG delivery descriptor is complete, step 1670. The receiver can then enter a monitoring mode and monitor for changes triggered on the acceptance carousels (or at lower layers, e.g. in PSI/SI table INT). The not skipped segments are processed at step 1680.

Another embodiment of the present invention is described below. One problem with the prior art is that the broadcaster may want to declare a number of different "views" to allow the receiver to determine completeness. The different "views" may contain partially or completely overlapping segments. According to embodiments of the present invention, a particular ESG fragment may be mapped to multiple sessions. Furthermore, in addition to conversation groups, there are other types of grouping that represent "views" but do not contain any conversation access information. For example, there are talk groups that present the next 8 hours of programming, and talk groups that present the next 8-16 hours of programming. Each of the talkgroups declares its own list of ESG fragments and points to its own carousel (carousel). Furthermore, there is a special "sports 16 h" group that aggregates "views" that collectively present about sports programs for the next 16 hours, but does not contain any session descriptions. In this case, it is expected that the receiver will mainly obtain the segmentation by other methods.

Another problem in the prior art relates to how to provide alternative access to a specific group. According to embodiments of the present invention, a "group" is generalized. The ESG delivery descriptor may carry a 0.. N set. Each group may contain a 0.. X access attribute and a 0.. Y ESG fragment. Furthermore, a group may contain other information related to group level (e.g., group name, validity), access (e.g., access parameters to FLUTE or ALC sessions, access parameters to a web server serving the ESG-http:// www.exampleserver.com/ESG-which is an extension of the group name and/or fragment ID, etc.) or ESG fragments (ID, version, destination container, type, etc.). One method of the present invention addresses this problem as follows: the broadcaster defines a group containing, for example, one access to the FLUTE/ALC session (broadcast reception) and one access to the web server (taken over the interaction channel). There may be multiple different broadcast accesses and two-way accesses simultaneously. This solution may also solve the problem described in the above paragraph.

As indicated in the description of fig. 16 above, the non-skipped ESG fragments may be processed by the receiver. To process the fragment, the receiver will typically require the correct mode (schema). The receiver may obtain the required schema file in a variety of different ways, such as pre-provisioning of the schema, fetching over an interactive network, or receiving the file in a broadcast file delivery session, such as an acceptance license cause.

Fig. 17 illustrates an exemplary processing method for an ESG fragment that is not skipped. It should be noted that if the offset and container length are not known, the receiver may determine the location and length of each ESG fragment. In general, each ESG fragment may be encoded with a given fragment encoding, such as GZIP, so that the encoded fragments may be processed as follows.

First, in step 1710, the native XML is parsed using an XML parser. It will be appreciated that the own plaintext does not require additional steps to be analyzed and thus can be analyzed at the time of delivery. In other words, the plaintext in itself may be an operating system independent document that contains any required context. Here, context refers to a schema or schema rules and is a guide for indicating and/or providing the syntax and semantics of the document.

Next, at step 1715, the referenced plaintext is parsed using the XML parser. It should be noted that the XML parser may be initialized with the referenced schema, examples of which are provided in fig. 13 and 14, (which may be provided in the ESG delivery descriptor). The referenced schema or context defines the XML structure and provides information about which fields are XML documents and which fields are the syntax for the documents. It is to be appreciated that the schema can be provided in a variety of formats.

At step 1720, the GZIP compressed segment is decompressed into plaintext. At step 1725, the previous GZIP compressed segment is analyzed as discussed in steps 1710 and 1715. Next, at step 1730, the BiM compressed segment is processed according to the BiM specification. Of course, step 1720-1730 may be omitted if there are no compressed segment portions. In addition, if other compression methods are used, the compressed portion of the container, which may be the entire container, may be appropriately processed. Thus, in embodiments, the container needs to be decompressed before any analysis can be performed.

It should be noted that it may be well suited to have the ESG fragments provided as one or more self-contained XML documents in clear text. When there are several such documents in the payload, and the container payload is compressed (e.g., payload _ compression is set to 0x01), the GZIP algorithm takes care of the redundancy.

In an embodiment, the ESG delivery descriptor may declare a container by utilizing a container ID equal to the TOI. Thus, for example, the container in the ESG delivery session may be TO1, which may be a single TO 300 including a header 310 and a container payload 320 (fig. 3). The TO may be in an intersection carousel and may contain a mapping between different parts of the ESG and may include parameters that are accessed by different methods of transmitting ESG data.

In an embodiment, there may be multiple ESGs, and these ESGs may be different from each other. For example, different ESGs may be in different languages and/or have different coding or different styles. In an embodiment, the language may be described by listing field values in the fragments.

An example of mode a is depicted in fig. 13, which is depicted in fig. 11 as TOI 7, which may be delivered to the terminal. In alternative embodiments, the terminal may wait for the receive mode until after consulting the declaration in the ESG delivery descriptor or consulting the PSI/SI table identifier to see if a new ESG or some portion of the current ESG is required. Thus, in embodiments, a mode is received only when it is determined that the mode is needed.

As noted above, in embodiments the modes may be pre-provisioned. In such an example, FDT is optionally not used, but all ALC objects are ESG delivery descriptors. The new ESG delivery descriptor may be identified as the new TOI occurrence. To deliver the FEC OTI information in the ALC packets, EXT _ FTI may be used.

As indicated in fig. 12, when a fragment 102 identified as fragment id "102" is received, the corresponding XML-syntax parser is initialized with the schema "esgcoeschema. As can be appreciated from the examples provided below, the offset can be used to determine the size and location of the segment.

Id＝82Ver＝2Offse1＝0...Id＝102Ver＝3Offset＝259...

FragmentId＝82Ver＝2

FragmentId＝102Ver＝3

The container may be the same as an ALC object or an atomic delivery of one or more ESG fragments (XML and/or non-XML). An example of this container syntax is provided in fig. 15. In an embodiment according to the present invention, the corresponding entry is placed in a container defined in the ESG delivery descriptor X TOI 39 based on the fragment ID 102. In an alternative embodiment, the target ESG fragment may be a self-contained XML schema instance, in which case "type" here simply states the type of fragment used for bookkeeping of the terminal, and the terminal may evaluate the type to determine if the conditions are met to proceed to the next step.

The list of one or more fragments in the ESG delivery descriptor defines the concept of integrity. When all announced fragments in the ESG delivery descriptor have been received, the ESG delivery session is completed and the ESG can be viewed through the terminal.

In this way, the sender can create a "view" by declaring, for example, a list of segments of the session, and thus the terminal can view it. One exemplary method of declaring a view is to declare a view through a time frame as discussed above. Another exemplary method is to declare the view by the broadcaster/service.

The following ESG schema for an ESG delivery descriptor describes exemplary embodiments according to aspects of the present invention. The symbol "//" is used to indicate that an explanation of the preceding item is being provided. It is understood that other ESG schemas may be provided.

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema xmlns:xs＝″http://www.w3.org/2001/XMLSchema″

elementFormDefault:xs＝″qualifled″

targetNamespaee:xs＝″http://www.example.com/esgDeliveryDescriptor″>

<xs:element name＝″Session″maxOccurs＝″unbounded″>

<xs:complexType>

<xs:sequence>

<xs:element name＝″Fragment″maxOccurs＝″unbounded″>

<xs:complexType>

<xs:attribute name＝″type″

type＝″xs:anyURI″

The URI gives the namespace of the target segment. I.e., it identifies the ESG XML fragment type. For non-XML use mime: < type >.

use＝″required″/>

<xs:attribute name＝″id″

// ID of ESG fragment. (32 bits)

type＝″xs:positiveInteger″

use＝″required″/>

<xs:attribute name＝″version″

// version of the ESG fragment (32 bits). The value is NTP time stamp

type＝″xs:positiveInteger″

use＝″optional″/>

<xs:attribute name＝″containerId″

This indicates in which container ID the fragment ID is carried.

type＝″xs:positiveInteger″

use＝″optional″/>

<xs:attribute name＝″name″

This gives the name of the segment. Only when non-XML ESG fragments are used.

type＝″xs:anyURI″

use＝″optional″/>

<xs:anyAttribute processContents＝″skip″/>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name＝″destIP″

// destination IP address of the target FLUTE/ALC session.

type＝″xs:positivelnteger″

// there are XML schema types for IP addresses?

use＝″required″/>

<xs:attribute name＝″port″

// Port of target FLUTE/ALC Session

type＝″xs:positiveInteger″

use＝″required″/>

<xs:attribute name＝″tsi″

// TSI of target FLUTE/ALC sessions

type＝″xs:positiveInteger″

use＝″required″/>

<xs:attribute name＝″validFrom″

// NTP timestamp. 32 bits.

type＝″xs:positiveInteger″

use＝″optional″/>

<xs:attribute name＝″validTo″

// NTP timestamp. 32 bits.

type＝″xs:positiveInteger″

use＝″optional″/>

<xs:anyAttribute processContents＝″skip″/>

Allowing a label to mark the session with any conceivable attribute, e.g. "genre" or "channel"

</xs:complexType>

</xs:element>

</xs:schema>

Since mobile devices are expected to move in general and terrestrial-based antennas typically have range limitations, it is useful to provide mobility between antennas or cells. The following example of an embodiment according to aspects of the present invention (illustrated by fig. 18 and 19) describes the use of target _ IPv6_ ESG _ root _ descriptor in the case where a terminal moves among a network of two different ESG regions having platform a (platform _ id 0x000010) and simultaneously among two different ESG regions of platform B (platform _ id 0x 000011). The IP data may be delivered to all IP decapsulators (IPE) through the service system. Each transmitter may feed an IPE. As described, each platform has a unique destination address for all session/IP streams and each ESG area (for a subset of platforms) has a unique source and destination address for all session/IP streams.

For ease of understanding, the method described in fig. 19 refers to the schema described in fig. 18. Turning to fig. 19, at step 1905, the terminal is located in cell a of area 1. The terminal needs the following information:

Platform A(platform_id＝0x000010)：

Target_IPv6_esg_root_descriptor：

IPv6_source_addr＝ff15::0011

IPv6_destination_addr＝ff15::0111

Platform B(platform_id＝0x000011)：

Target_IPv6_esg_root_descriptor：

IPv6_source_addr＝ff15::0022

IPv6_destination_addr＝ff15::222

next, in step 1910, the terminal moves from cell a to cell B, which is also located in area 1. During the movement, the terminal performs handover from cell a to cell B. When the terminal moves to a new cell, it receives source and destination addresses from the target _ IPv6_ esg _ root descriptor. If the addresses are the same, as it would be when moving from cell a to cell B, then the terminal may conclude that it is still in the same area (e.g., area 1). Thus, the terminal does not need to update the ESG unless the previously obtained ESG has expired.

Next, the terminal moves from cell B to cell F, i.e., from zone 1 to zone 2, at step 1915. When the terminal moves, the terminal performs handover from cell B to cell F. The terminal receives source and destination addresses from target _ IPv6_ esg _ root descriptor. Since cell F is in a different area than cell B, the movement from area 1 to area 2 causes the source and destination addresses of the ESG to change as follows:

Platform A(platform_id＝0x000010)：

Target_IPv6_esg_root_descriptor：

IPv6_source_addr＝ff15::0012

IPv6_destination_addr＝ff15::0112

Platform B(platform_id＝0x000011)：

Target_IPv6_esg_root_descriptor：

IPv6_source_addr＝ff15::0023

IPv6_destination_addr＝ff15::0223

since the source and destination addresses have changed, the terminal can infer that the area has changed. The terminal updates the ESG so that the ESG corresponds to a new area (e.g., area 2). Since the ESG may be provided in fragments, the terminal may be able to selectively update different fragments. In an embodiment, the ESG may be the same for both region 1 and region 2, in which case the terminal may not have to update the ESG.

Next, the terminal moves to cell G in step 1920. When the terminal moves, the terminal performs handover from cell F to cell G. Since cell F and cell G are in the same area, the source and destination addresses of target _ IPv6_ esg _ root descriptor remain the same for both platform a and platform B. Accordingly, the terminal can determine that the area has not changed during movement between cells. In this way, the terminal may limit updating of the previously obtained ESG if it has expired. Thus, movement between cells F and G may not require any updates to the ESG.

Next, in step 1925, the terminal moves from cell G to cell E. As described earlier, the terminal performs handover from cell G to cell E. Since cell G and cell E are both in region 2, the source and destination addresses of the target _ IPv6_ esg _ root descriptor remain the same. Therefore, the terminal can presume that the area has not changed and does not have to update the ESG unless it has expired.

Next, in step 1930, the terminal moves from cell E to cell B. As described earlier, the terminal performs handover from cell E to cell B. The terminal checks the source and destination addresses of the target _ IPv6_ ESG _ rootdescriptor, and determines that the source and destination addresses of the ESG change as follows:

Platform A(platform_id＝0x000010)：

Target_IPv6_esg_root_descriptor：

IPv6_source_addr＝ff15::0011

IPv6_destination_addr＝ff15::0111

Platform B(platform_id＝0x000011)：

Target_IPv6_esg_root_descriptor：

IPv6_source_addr＝ff15::0022

IPv6_destination_addr＝ff15::0222

since the source and destination addresses have changed, the terminal determines that the area has changed. Accordingly, the terminal appropriately updates the ESG. As noted above, the updating of the ESG may be limited to the difference, if any, between the ESG for area 2 and the ESG for area 1.

It should be noted that although the ESG region of platform a is described as being the same as the ESG region of platform B, the regions of a and B may be different in embodiments.

In a further embodiment according to aspects of the present invention, additional/optional metadata may be added to the ESG delivery descriptor, such as genre, parent rating, title, service name, record, etc., which may be provided, for example, via an XML schema. In another aspect of the present invention, the terminal may be configured to pre-select fragments based on the additional/optional metadata to thereby decide what ESG fragments to receive.

In one embodiment of the present invention, the ESG is delivered by broadcasting one or more ESG delivery sessions. In another embodiment, the ESG is delivered over an interaction channel. Alternatively, any other transmission may be used, such as the DVB service delivery selection transport protocol (DVBSTP) or the Multicast File Delivery Protocol (MFDP). The container may even be omitted, in which case a single ESG fragment may be considered a container.

While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous permutations and variations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims.

Exemplary aspects of the invention

1. A method of transmitting fragments of an ESG, the method comprising:

the ESG data is fragmented into at least one fragment in the network server,

associating the at least one fragment with an ESG delivery session,

transmitting at least one fragment of the ESG delivery session on at least one carrier,

assembling at least one fragment in the ESG delivery session and declaring at least one fragment for each ESG delivery session; and associating the delivery session with at least one ESG delivery descriptor.

2. The method of claim 1, further comprising the steps of:

comparing the declared at least one fragment with a bookkeeping of existing ESG delivery sessions assembled by fragments in the terminal, and

determining that the ESG delivery session contains missing fragments.

3. The method of claim 2, further comprising the steps of:

if at least one fragment is missing, the terminal is prevented from reading the ESG delivery session containing one or more fragments that the terminal already has by precisely locating the fragment through the ESG delivery descriptor in the correct ESG delivery session.

4. The method of claim 3, further comprising the steps of:

the terminal is enabled to update the ESG with at least one fragment of the ESG delivery session at a time, saving bandwidth for other purposes such as consuming the service (background change).

5. The method of claim 2, wherein the ESG delivery descriptor gives a complete list of one or more fragments needed from each ESG delivery session so that the integrity of the session is well defined.

6. The method of claim 5, further comprising the steps of:

the terminal is allowed to listen to one or more ESG delivery sessions only until all fragments declared by the corresponding ESG delivery descriptor are received.

7. The method of claim 1, further comprising the steps of:

updating and displaying the selectable and received ESG information on the terminal.

8. The method of claim 1, further comprising the steps of:

the ESG delivery descriptor is copied and if there is a change in the ESG delivery descriptor (new fragment, etc.), a new TOI with new content is assigned and sent without sending the old TOI.

The method of claim 8, further comprising the steps of:

a fragment in the ESG delivery session is pinpointed TO a particular TO containing the fragment.

9. The method of claim 1, further comprising the steps of:

the announcement carousel (announcement carousel) is checked at the mobile terminal either occasionally or when triggered e.g. by a PSI/SI table received via said at least one bearer.

10. The method of claim 1, further comprising the steps of:

when at least one fragment is received, an XML parser associated with the at least one fragment is initialized with an XML schema.

11. The method of claim 1, further comprising the steps of:

the type of fragment is declared for terminal bookkeeping when the fragment is an own instance of an XML schema.

12. The method of claim 1, further comprising the steps of:

the ESG integrity is defined by a list of one or more fragments from which a "view" is created after one or more declared fragments have been received.

13. The method of claim 12, further comprising the steps of:

classifying the view by a method consisting of one or more of: time, broadcast operator, and/or service.

14. The method of claim 12, wherein

The ESG fragment includes one or more of: XML fragments, XML documents, or any other file in a markup language format.

15. The method of claim 14, wherein

The ESG fragment has an id for identification and is declared in an ESG delivery descriptor.

16. The method of claim 14, further comprising the step of:

at least one non-declared segment is cached for later declaration.

17. The method of claim 14, wherein the timestamp defines a segmented version.

18. The method of claim 14, wherein the terminal deduces the location and length of fragments within said carrier for the ESG fragments.

19. A method for constructing an ESG at a mobile terminal, the method comprising:

reading a fragment list declared for each ESG delivery session in an ESG descriptor;

comparing the list of segments with bookkeeping already present in the mobile terminal;

determining that the ESG delivery session contains a missing fragment; and if only a subset of the fragments are missing, the ESG delivery descriptor pinpoints the fragments in the correct ESG delivery session, avoiding the mobile terminal from reading an ESG delivery session that contains only the fragments that the terminal already has.

20. The method of claim 19, wherein the method enables the terminal to update the ESG using only a subset of the ESG delivery sessions at a time, saving bandwidth for other purposes such as consuming the service (background change).

21. The method of claim 19, wherein the ESG delivery descriptor gives a complete list of fragments required from each ESG delivery session so that the integrity of the session is well defined. In other words, the terminal is in an ESG delivery session only until all fragments declared by the corresponding ESG delivery descriptor are received.

22. The method according to claim 19, wherein said mobile terminal checks an announcement carousel (announcement carousel), either occasionally or when triggered by a PSI/SI table, for example.

23. The method of claim 19, wherein additional/optional metadata such as genre, parental rating, title, service name, record, etc. is added to the ESG delivery descriptor.

24. The method of claim 19, wherein the terminal is enabled to pre-select fragments based on the additional/optional metadata in order to decide what ESG fragment to receive.

25. The method of 19, wherein after receiving all descriptors from the announcement carousel, the terminal may filter to receive only content related to, for example, sports.

26. The method of claim 22, wherein the update of esg is obtained after a change in a source address of the IPE (encapsulator).

An ESG, comprising:

means for assembling at least one fragment identified in an ESG delivery session;

means for declaring the at least one fragment for each ESG delivery session; and

means for associating the delivery session with at least one ESG delivery descriptor.

The ESG may further include

The ESG data is fragmented into at least one fragment in the network server,

associating the at least one fragment with an ESG delivery session,

transmitting the at least one fragment identified in the ESG delivery session and/or ESG delivery descriptor on at least one carrier,

allowing esg to be visible to the end user as quickly as possible.

28. A network server configured to process ESG fragments, the system comprising:

a processor;

a computer readable medium programmed with computer readable instructions for performing the steps comprising:

the ESG data is fragmented into at least one fragment in the network server,

associating the at least one fragment with an ESG delivery session, an

Transmitting at least one fragment of the ESG delivery session on at least one carrier.

29. A computer readable medium programmed with computer readable instructions that cause a network server to perform the steps comprising:

the ESG data is fragmented into at least one fragment in the network server,

associating the at least one fragment with an ESG delivery session, an

Transmitting at least one fragment of the ESG delivery session on at least one carrier.

30. A system for distributing ESG data, the system comprising:

a processor;

a computer readable medium programmed with computer readable instructions for performing the steps comprising:

the ESG data is fragmented into at least one fragment in the network server,

associating the at least one fragment with an ESG delivery session, and

transmitting at least one fragment of the ESG delivery session on at least one carrier; and

a receiver programmed with computer readable instructions that assembles at least one fragment in the ESG delivery session and declares at least one fragment for each ESG delivery session; and associating the delivery session with at least one ESG delivery descriptor.

Claims (28)

1. A method of transmitting fragments of an ESG, the method comprising:

(a) segmenting data of the ESG in the ESG delivery session to form at least one fragment;

(b) assembling the at least one fragment in at least one container of an ESG delivery session;

(c) associating the at least one fragment with at least one ESG delivery descriptor declaring the at least one fragment for the ESG delivery session; and

(d) conveying the at least one fragment in the at least one container on at least one carrier.

2. The method of claim 1, further comprising:

(e) receiving the declared at least one segment in the terminal;

(f) comparing the declared at least one fragment to existing bookkeeping of one or more ESG fragments assembled from at least one previous ESG delivery session; and

(g) determining whether the at least one carrier contains at least one missing segment.

3. The method of claim 2, further comprising:

(h) pinpointing the at least one missing fragment declared by the ESG delivery descriptor in the at least one correct container.

4. The method of claim 3, wherein the at least one missing fragment of the ESG delivery session comprises a plurality of missing fragments, the method further comprising:

(i) updating the ESG with at least one of the plurality of missing fragments of the ESG delivery session at a time.

5. The method of claim 2, wherein the at least one ESG delivery descriptor provides a complete list of one or more fragments needed from the ESG delivery session.

6. The method of claim 4, further comprising:

(j) preventing the terminal from listening to an ESG delivery session once all of the plurality of missing fragments declared by the ESG delivery descriptor are received.

7. The method of claim 1, further comprising:

(e) if there is a change in the new ESG delivery descriptor as compared to the at least one ESG delivery descriptor, the new ESG delivery descriptor is provided and a new TOI with new content is assigned.

8. The method of claim 7, further comprising:

(f) pinpointing the at least one fragment in the ESG delivery session to a particular transport object containing the at least one fragment.

9. The method of claim 1, further comprising:

(e) receiving the at least one segment in the terminal; and

(f) initializing an XML parser associated with the at least one fragment using an XML schema.

10. The method of claim 1, further comprising:

(e) defining an integrity of the ESG using the list of at least one declared fragment after the at least one declared fragment has been received; and

(f) creating a plurality of "views" through the at least one declared segment.

11. The method of claim 1, wherein the at least one fragment has an id for identification, and the id is declared in an ESG delivery descriptor.

12. The method of claim 1, further comprising:

(e) compressing at least a portion of the at least one container.

13. A computer-readable medium having computer-executable instructions for performing the method of claim 1.

14. A computer-readable medium having computer-executable instructions for performing the method recited in claim 12.

15. A method for constructing an ESG at a mobile terminal, the method comprising:

(a) reading a fragment list declared for an ESG delivery session in an ESG descriptor;

(b) comparing the list of segments with bookkeeping already present in the mobile terminal;

(c) determining whether the ESG delivery session contains at least one missing fragment; and

(d) reading the ESG delivery session if the ESG delivery session contains at least one missing fragment.

16. The method of claim 15, further comprising:

(e) repeating (a) through (d) for each ESG delivery session.

17. The method of claim 15, wherein the mobile terminal is configured to update the ESG using only a subset of the ESG delivery sessions at a time.

18. The method of claim 15, wherein (d) comprises:

(i) determining a container associated with the at least one missing fragment in the ESG delivery session; and

(ii) the container is read.

19. The method of claim 15, wherein metadata is added to the ESG delivery descriptor.

20. The method of claim 19, wherein the terminal is configured to preselect fragments based on the metadata to determine what ESG fragments are to be received.

21. A computer-readable medium having computer-executable instructions for performing the method recited in claim 15.

22. A computer-readable medium having computer-executable instructions for performing the method recited in claim 18.

23. A system for distributing ESG data, the system comprising:

a web server, the web server comprising:

a processor; and

a computer readable medium programmed with computer readable instructions for performing:

(a) the ESG data is fragmented into at least one fragment,

(b) associating the at least one fragment with an ESG delivery session, an

(c) Transmitting at least one fragment of the ESG delivery session on at least one carrier; and

a receiver programmed with computer-executable instructions to assemble the at least one fragment in the ESG delivery session.

24. The system of claim 23, wherein (b) comprises:

(i) associating the delivery session with at least one ESG delivery descriptor; and

(ii) declaring the at least one fragment in the at least one ESG descriptor.

25. A mobile device for receiving ESG data, comprising:

a housing;

a processor mounted within the housing;

a display connected to the processor;

a receiver coupled to the processor;

an antenna connected to the receiver;

a user interface connected to the processor;

a power supply connected to the processor; and

a memory coupled to the processor, wherein the memory comprises computer-executable instructions configured to enable the mobile device to receive, decode and process a container containing fragments, and wherein the memory further comprises computer-executable instructions configured to enable the mobile device to compare the fragments to a bookkeeping of ESGs assembled by at least one previous ESG delivery session to determine whether the container contains at least one missing fragment.

26. The mobile device of claim 25, wherein the memory includes computer-executable instructions configured to enable the mobile device to read the container if the container contains at least one missing segment.

27. The mobile device of claim 25, wherein the receiver comprises a digital video broadcast handheld receiver.

28. The mobile device of claim 25, wherein the receiver comprises at least one selected from a WLAN receiver, an FM receiver, and a telecommunications receiver.