WO2008053568A1

WO2008053568A1 - Apparatus and method for preloading data in mobile communication devices

Info

Publication number: WO2008053568A1
Application number: PCT/JP2006/322205
Authority: WO
Inventors: Jek Thoon Tan; Kum Yuen Ronn Yang
Original assignee: Panasonic Corporation
Priority date: 2006-10-31
Filing date: 2006-10-31
Publication date: 2008-05-08

Abstract

A method of preloading data in a mobile data communication device, including encoding a broadcast contents structure; delivering said encoded broadcast contents structure; retrieving encoded broadcast contents structure on the communication device; decoding and displaying said broadcast contents structure; selecting broadcast contents for preloading; managing said broadcast content selections; managing preloading operations; and preloading said broadcast contents selections. A method of specifying and delivering a structure, including parsing the structure of an entire broadcast channel file system or contents of broadcast application data and resources; encoding the structure into a textual or binary format; embedding textual or binary formatted information in a descriptor or table; periodically inserting the descriptor or table into a broadcast channel; detecting or being informed of updates to the structure; and including versioning information in the descriptor or table.

Description

DESCRIPTION

APPARATUS AND METHOD FOR PRELOADING DATA IN MOBILE COMMUNICATION DEVICES

TECHNICAL FIELD

The invention relates to data broadcasting to mobile data communication devices. In particular, it relates to an apparatus and methods by which data is preloaded into such devices without any intervention from the user. The data can be, but is not limited to, static information in the form of files and directories, textual data, binary data, multimedia data, streaming data and also applications and associated resources.

BACKGROUND ART

Rich media applications are now available on a variety of mobile data communication devices. These applications are offered by data broadcasters and content providers. The applications can encompass information services such as news and location specific content. In addition, multimedia content can also be delivered to the device via streaming or by downloading media files for playback at another time.

Menus are typically provided as a means for navigating among the myriad of offerings from the broadcasters. Menus organize content in a hierarchical manner. The tree structure representation that is used is a common method of representing hierarchical content. The tree branches could represent the major categories of data. Each branch could then be further subdivided into additional sub-branches and each sub-branch could in turn contain many other sub-branches. The depth of the hierarchical structure depends on the amount of content and also the manner in which the data are categorized.

Normal usage of data services presented in the form of a hierarchical menu would involve the user navigating among the branches in search of the information desired. Time is spent perusing the branch designations and then deciding whether a particular branch is relevant. Typically, the desired information is embedded below several layers of branches. When the desired information has been found, a download operation commences and the data is subsequently rendered on the mobile device. This navigating and downloading operation can occur many times in a typical session.

All this while, the device is continually operating its receiving and decoding circuitry to receive data broadcasts, ready to serve the demands of the user. Whenever, a content item is selected for viewing, the associated address location and properties of the data necessary to render that item are noted by the device. , Address resolution could then take place to determine the exact position in which the required data is located in the data broadcast channel. The data can comprise specific files and directories or streaming media.

The nature of the address resolution operation depends to a large extent on the broadcast protocol employed. Some protocols require a fair amount of processing to obtain the address. The device then checks to ascertain whether the required data is already residing in memory. If it is, the requested content is rendered as soon as possible. Otherwise, the receiving and decoding modules would be notified to download the relevant data into memory.

The latency experienced by users to download the desired data varies widely and is dependent on many factors. One major factor is the broadcast protocol. The amount of information available in a data broadcast is normally very large compared to the device's memory capacity. As such, the device is made to selectively store only the required data from the broadcast channel. Once the previously downloaded data has ceased being useful to the user, it is purged to make way for new data from the broadcast.

The broadcast data is typically transmitted in a round robin manner. That is, the information is repeated continually at intervals. Depending on the data, the intervals could be regular or irregular. Important information is normally delivered more frequently. This cyclical approach to dissemination data assures that client devices in various states always have the full suite of data available for retrieval. The device has to constantly scan the data broadcast channel for information relating to the upcoming contents. Once the desired information arrives, it is stored in memory. , The application is then notified and the data is subsequently rendered.

In the unidirectional data broadcast scenario, no feedback channel is available from the mobile device to the broadcaster. The broadcaster has no knowledge of the state of the mobile devices. The mobile devices can only passively extract data and applications from the broadcast channel, according to the temporal needs of the user.

When a return channel from the mobile device to the broadcaster is present, value added services can be provided, such as the purchase of premium content or pay per view content. This facility also allows the mobile device to request for specific information from the broadcaster, in which case, the broadcaster can transmit in-band (via the broadcast channel) or out-of-band (via the private return channel) to the device. This is an example of a bidirectional broadcast scenario.

In addition to application based menu driven systems for acquiring content, data broadcasting also enables the downloading of software, delivery of internet services and also interactive television services. All these services commonly employ some form of content selection capability on the terminal device.

Several prior art systems have been invented to enhance the delivery of personalized content to mobile communication devices. In patent US 6,779,019, user selected data is pushed from a host system to a mobile data communication device, but only upon detecting the occurrence of one or more user-defined event triggers. This patent mainly deals with the synchronization of file and data modifications on the mobile device with those in the host system.' When the host system files are changed, those equivalent files within the mobile device are updated.

In patent US 6,374,245, users with Personal Digital Assistant (PDA) devices , are able to selectively stipulate files to be downloaded from a remote server. The download process is initiated by the PDA user. The server intervenes in this download process by having a controller which determines whether the files or data can be accommodated in the physical memory of the PDA. This is an example of on- demand request for information from the server. The server is responsible for directing the downloading process.

Patent US 6,754,696 proposes a system for transparently combining remote and local storage means to act as one or more virtual local drives of a client device such as a PDA or set top box. When a connection to an extended file system is present, the extended file system provides automatic downloading of information that is not locally cached and automatic uploading of information that has been modified on the client. Providing such a remote drive allows any client device to load file system objects, to store the directories and files remotely, and to retrieve the files only when required. With this invention, the broadcast channel can be regarded as a virtual drive.

DISCLOSURE OF THE INVENTION

PROBLEMS THAT THE INVENTION IS TO SOLVE

Many different types of viewing and selection user interfaces are available to present the collection of content that is offered for downloading from the data broadcast channel. These interfaces may be textual, graphical or menu driven. They essentially enable users to navigate, browse and select content. However, such systems are generally designed to allow the viewing of one content dataset at a time. For example, only one news article, one video stream or one web page can be viewed at a time. This is somewhat limited by the system capabilities of typical terminal devices: limited screen size and resolution, computing resources, memory size and battery life. Depending on the implementation and structure of the data broadcast, the time required to download the desired data varies. Therefore, the user is usually made to wait for a finite time before the data arrives at his device, unless the data has already been saved previously.

Suppose the user desires to view a series of contents relating to local news, international sports and the latest movie listings. Typical menu-driven systems on terminal devices will require the user to individually navigate to these three categories of subjects in a serial manner, one after another. After selecting the local news category, the user has to wait for the corresponding data files to arrive at the device followed by rendering before any viewing is possible. When viewing has ended, the user then navigates to the international sports news section, which might involve some more latency before viewing is possible. Similarly, the same navigation and data download latency is experienced for the latest movie listings information.

This latency experienced is typical of users' interaction with content requests from a terminal device that derives its data from the broadcast medium. This situation would be cumbersome for the user when almost the same set of data is desired every day.

To address the problem of latency, certain data caching methodologies have been employed to download data relating to the user's anticipated data requests. One approach would be the caching of data that are related to all the outgoing links or references of a particular application state. While the user is interacting with that particular application state, data relating to the outgoing links or references is downloaded in the background. In this way, the terminal is assured that there is ready data to present to the user regardless of the route by which the user takes away from the current application state. However, such methodologies are very reactive and are highly dependent on the user's interaction with the application.

The above caching approach is useful for caching data in the vicinity of currently accessed data. It fails when the envisaged data requirements span across disparate content segments that are not covered by outgoing links and references. The approach is not useful for preloading data from various unassociated files and directories. The device is unable to anticipate such requirements. Therefore, the user is often left to wait for his data to be downloaded. This is a time consuming process. In other words, preloading data from outgoing links and references only works in some circumstances.

Power consumption is a critical design factor in terminal devices. The battery life is directly proportional to the duration of time spent accessing the broadcast channel. When accessing the broadcast channel, power is consumed by the device's receiver and decoding modules. It would be preferable to seek a means to reduce the use of the receiver and decoding modules while not compromising on the user's interaction with the device.

Despite new broadcast delivery schemes to reduce power consumption such as time-slicing, the major determinant of the terminal's battery life is the usage pattern. In typical usage, time is spent by the user digesting the information already rendered on the device. During this time, the receiver and decoding modules are continually being activated in anticipation of a data request from the user. This is undesirable, as no useful work is being done while power is being consumed. In fact, whenever the receiver and decoding modules are activated, they should be made to do useful work by downloading required data. However, devices are not aware of what data is considered relevant to the user.

MEANS FOR SOLVING THE PROBLEMS

A first aspect of the invention is a method of preloading data in a mobile data communication device, including encoding a broadcast contents structure; delivering said encoded broadcast contents structure; retrieving said encoded broadcast contents structure on the communication device; decoding and displaying said broadcast contents structure; selecting broadcast contents for preloading; managing said broadcast content selections; managing preloading operations; and preloading said broadcast contents selections.

A second aspect of the invention is a method of specifying and delivering a structure of a broadcast channel file system, including parsing an entire broadcast channel file system; encoding a structure of the broadcast channel file system into a textual or binary format; embedding textual or binary formatted information in a descriptor or table; periodically inserting the descriptor or table into a broadcast channel; detecting or being informed of updates to the broadcast chanηel file system; and including versioning information in the descriptor or table.

A third aspect of the invention is a method of specifying and delivering a structure of broadcast application data and resources, including parsing the contents of the broadcast application data and resources; encoding a structure of the contents into textual or binary format; embedding textual or binary formatted information in a descriptor or table; periodically inserting the descriptor or table into a broadcast channel; detecting or being informed of updates to the broadcast application data and resources; and including versioning information in the descriptor or table.

A fourth aspect of the invention is an apparatus for preloading data in mobile data communication devices, said apparatus including a retrieving unit that retrieves encoded broadcast contents structure on the communication device; a decoding unit that decodes and displays the broadcast contents structure; a selecting unit that selects broadcast contents for preloading; a first managing unit that manages said selected broadcast content; a second managing unit that manages preloading operations; and a preloading unit that preloads said broadcast contents selections.

BRIEF DESCRIPTION OF THE DRAWINGS

The advantages, nature, and various additional features of the invention will appear more fully upon consideration of the exemplary .embodiments. The exemplary embodiments are set forth in the following drawings.

Figure 1 shows a sample file and directory structure.

Figure 2 shows an embodiment of the interface for selecting contents for preloading.

Figure 3 shows an embodiment of the interface for selecting files and directories for preloading.

Figure 4 shows an embodiment of the interface for profile selection.

Figure 5 shows an embodiment of the interface for preload configuration.

Figure 6 shows the block diagram of the mobile data communication device.

BEST MODE FOR CARRYING OUT THE INVENTION

Although the invention will be described with respect to exemplary embodiments thereof, the following exemplary embodiments do not limit the invention.

The exemplary embodiments relate to an apparatus and methods that enable terminal devices to preload or cache a collection of preferred contents from the broadcast channel without direct action from the user. According to the embodiments, the user first defines the desired content. However, the user is not actively involved in the selection and downloading cycles for many of the desired content categories. Instead, such actions are initiated and monitored automatically by the terminal device, typically as a background process. This background process can also be scheduled to commence at an appointed time. Facilities are provided for the user to stipulate the collection of content for downloading and also other associated parameters. Each¹ collection of content is regarded as a preload profile. Many preload profiles can exist within a terminal device. The profiles can also be transferred between devices.

The preferred contents can be general or specific categories of data. The types of data can include text, images, application code, audio video media or any other form of information that is required for normal operation by a terminal device from the broadcast channel. When the rendering of such data requires the download of other dependent data, the dependent data is automatically downloaded

In addition, specific files and directories carried by the data broadcast channel file system can also be selected for downloading. The files and directories are normally not visible to the user, as the terminal devices interact with users at the application level. However, in an operation mode, broadcast files and directories can be selected for downloading. The collection of desired files and directories is similarly stored as profiles.

The structure of the broadcast file system can be derived by terminal devices manually by decoding the protocol's descriptors and tables. Depending on the protocol, this can be a computationally intensive process. A means is proposed to encode the file system structure at the broadcaster and deliver the structure information in-band. In this way, terminal devices can readily obtain the file system structure with minimal processing. This structure is then presented to the user in a display. This display is then used to as a means to select the files and directories for preloading. Additionally, the structure of the hierarchical application contents can also be delivered in the same manner.

This method is especially useful when many disparate contents or files and directories have to be downloaded frequently. The method can be regarded as having two major modes of operation. One mode caters to the preloading of application level content, such as news articles and streaming media. The other mode allows specific files and directories to be preloaded. Neither mode requires direct action from the user for obtaining the data. Operation

Broadcast contents and its file system are typically hierarchically organized. These contents are parsed and the hierarchical organization is subsequently encoded into descriptors or tables which are then inserted into the broadcast channel. Terminal devices decode these descriptors or tables to generate a snapshot of the structure of the broadcast contents. This structure can be rendered graphically to provide a means for the user to select specific items for preloading.

Collections of preferred contents or files and directories can be organized to form entities known as profiles. Each profile contains the snapshot of a particular set of data that is earmarked for preloading. Attached to each profile's data item are ancillary information such as its broadcast channel address, data size, type and priority. Profiles can therefore be regarded as databases that contain details of all the data items to be preloaded. The profile configuration is stored in Extended Markup Language (XML) format, but other forms of representation can also be used Adopting the XML format ensures that the profile can be used by various families of devices with different implementations. Names can be assigned to each profile for differentiation. Each profile is stored as a file that is saved in the persistent memory area of the terminal device.

A terminal device can store a plurality of profiles. These profiles can be configured by the user or downloaded from the broadcaster or obtained from another device. The user typically configures a preloading process by selecting the desired profile. Multiple profiles can be activated simultaneously. In this case, the terminal device combines the data item list from all the selected profiles.

' The preloading operation preferably occurs during periods when the terminal device is idle, as a background process. It can also occur when the device is in use, but no downloading operation is taking place. The process can also be stipulated to commence at a specific time. This can be a daily, weekly or a one off occurrence. A series of preload operations can also be configured for activation at different times of the day. In addition, when a predetermined period of time has elapsed, the preferred contents, directories and files can be automatically updated with the latest versions. This can be a global update or a restricted update for only certain contents or files and directories.

Profiles can be created in many ways. One approach is the employment of user interfaces that present all the available content in a hierarchical manner. Each item will then have an associated graphical element that serves as a means for selection. The content can also be presented in the form of a one-dimensional list Each data item can be displayed as text, graphics or other forms of suitable representation. A means is also provided in the interface to allow the horizontal and vertical scrolling of contents when the device's display is not able to show all the contents in one screen.

In addition to content categories, the user is also able to specify specific preferred files and directories for preloading. The manner in which files and directories are selected is similar to that of the content categories mentioned previously. When a selected file is deeply embedded in the directory structure, the file path from the root level down to the selected file is noted and replicated in the device memory. In this situation, all the intermediate directories are automatically created even though they have not been selected for downloading. The contents within those intermediate directories would not be preloaded if they have not been selected. Transport of the Hierarchical Content Structure for Mobile Application Data

One feature of the embodiment is the establishment of a means to transport the hierarchical structure of the broadcast contents, such as files and directories, to the mobile devices. This structure can be rendered in graphical or textual form on the device. It serves to provide a snapshot of the entire contents of the broadcast channel that is available to the device, even though the device might not contain all the data.

There are basically two main technical aspects regarding the rendering of the hierarchical structure of the contents. The first aspect pertains to the structure of the contents from the mobile applications' point of view. These are typically menu driven applications that organize data into categories. Within each category, the data can be further divided into sub-categories. Many levels of categories can exist, depending on the depth and breadth of the contents. This rendering of the hierarchical structure is apart from the manner in which the applications present their collection of contents to the user. It is independent of the customized interfaces that each mobile application employs. That is, the rendering of the hierarchical content structure always utilizes the same interface for presentation, regardless of the type of mobile application.

The structure of the application data is derived at the broadcaster. This can be achieved by intelligently parsing the application codes and resources or manually defined. Subsequently, the structure is encoded in the form of a descriptor or table. This descriptor or table is then inserted into the broadcast channel. The means of encoding the structure is a common technique used by several of the embodiments described herein and is presented in the following subparts of the embodiment. Transport of the Hierarchical Content Structure for Broadcast File Systems

A second feature of the embodiment deals with the files and directory structure of the underlying file system of the broadcast channel. This is apart from the structure of the application contents as seen by the user. The delivery of the hierarchical file system structure could be achieved via the use of dedicated descriptors or additional signaling tables embedded in the broadcast channel. These descriptors could define the hierarchical structure using linked lists, tree representations, or other forms of description necessary to fully depict the broadcast contents. For large data broadcast carousels, these descriptors or tables will have to be placed at intervals of sufficient frequency in order to enable devices to quickly extract the hierarchical structure of the contents.

On the other hand, in the absence of such mechanisms, passive scanning and decoding has to be done by the mobile devices to extract the hierarchical structure of the broadcast file system. In this case, the device has to continually scan and decode the incoming data for one entire carousel cycle. The device can either save all the incoming data or just decode the descriptors or tables that are necessary to derive the hierarchical structure. Because of limited device memory, the latter approach is preferred. The period of one broadcast carousel cycle can be large. Thus the construction of the structure by the use of passive scanning can involve very high latency. However, this approach is useful in situations where the specialized descriptors and tables for delivering the file and directory structures have not been adopted by the broadcaster. Passive scanning assures that this invention can be used in different contexts. The downside to this approach is the need to consume the device's computational resources in order to derive the hierarchical structure. The device's receiving and decoding modules have to also remain activated for the entire carousel cycle, leading to unnecessary battery consumption.

In the field of broadcasting, many different data delivery protocols are currently in use. Despite having different approaches and implementations, these protocols commonly employ some means to describe their file system structure and contents. This is necessary because mobile devices need a replica of a subset of the file system contents in order to execute the mobile applications that are downloaded from the broadcaster.

Two of such data delivery protocols are used to depict the derivation of the file system structure, either by means of specialized descriptors or tables embedded in the broadcast channel or by passively scanning the incoming broadcast data. The examples of the MPEG-2 Digital Storage Media - Command and Control (DSM-CC) Object Carousel and the Internet Protocol Datacasting (IPDC) protocols are used. However, the techniques described herein are also applicable across a host of other data delivery protocols, as long as the same means and approach is used with regards to their file system structure. DSM-CC Object Carousel

In the case of the DSM-CC Object Carousel data delivery protocol, the source file system is encoded into a series of Broadcast Interoperability ORB Protocol (BIOP, where ORB is the Object Request Broker) files and directory objects. These objects are delivered in the form of modules in DSM-CC Object Carousels. Each module is further segmented into blocks, which are transported as DownloadDataBlock (DDB) messages. The Inter-operable Object Reference (lOR) is embedded in the DownloadServerlnitiate (DSI) messages. The IOR holds references to the file and directory objects residing directly under the service gateway. The service gateway can be regarded as the root directory for the broadcast file system. Additionally, the IOR carried in a directory's BIOP message contains references to other directory and file objects residing directly in that directory.

Because of the manner in which independent IORs are used to describe all levels of the directory structure, all IORs that are carried by the intermediate directory objects between the service gateway and the directory containing a particular file object have to be processed in order to construct a hierarchical structure from the root level to the file concerned. Therefore, the amount of computation required varies directly with the depth and breadth of the directory structure. In other words, a deeply embedded file will require more computing resources for full address resolution. In passive scanning, the device has to collect, decode and assemble all the lORs, file and directory objects in order to cover entire file system structure. This can involve high latency, especially for large carousels. Thereafter, this structural information is assembled together rendered in the user interface.

Alternatively, the directory structure of the file system can be provided by means of a descriptor. This will alleviate the problem of high latency and also reduce the computational resources required for assembling the file system structure using the passive scanning approach. This descriptor can be embedded in the userlnfo_data field of the DSI message. This message is chosen as a platform for the descriptor because the DSI is used to provide the service gateway information.

The new descriptor is termed the directory_structure descriptor. It will carry the structure of the entire broadcast file system located under the service gateway. Mobile devices that recognize this descriptor will be able to obtain the file system structure readily, whereas devices that do not support the descriptor will simply ignore it. This descriptor will be updated by the broadcaster whenever a change in the directory structure is made. This descriptor is therefore backward compatible to existing systems.

The semantics of the directory_structure descriptor is shown in Table 1. The fields are as follows: descriptor_tag 8-bit field that provides a unique value that identifies the directory_structure descriptor. descriptorjength 8-bit field that specifies the length in bytes of the subsequent fields up to the end of the descriptor. version 8-bit field that indicates the version number of the XML contents stored in this descriptor.

XMLJength 16-bit field that specifies the length of the XML data in bytes. XML_data XML contents describing the file and directory structure.

Table 1 : directory_structure descriptor

The version field enables mobile devices to track updates in the broadcast channel file system. Upon startup, the mobile device downloads and decodes the contents of the directory_structure descriptor and notes its version number. The appearance of subsequent instances of this descriptor are ignored if the same version number is encountered. This saves the mobile device from having to constantly analyze the contents of the directory_structure descriptor for changes. New version numbers are always incremented by one, modulo 2⁸. When a new version number is found, the directory_structure descriptor is downloaded and decoded again to replace the old instance.

The entire file and directory structure of the broadcast file system is described using the Extended Markup Language (XML). XML is the preffered means of representation, although other suitably formatted textual or binary representations can also be used Each broadcast channel structure is stored within one descriptor This invention also encompasses variations to the proposed XML syntax, as long as the goal and use of the XML syntax remains the same. The suggested XML representation to describe the sample file and directory structure shown in Figure 1 is shown below

<files_and_dιrectories> <node>

<text> Di rectory 1 </text>

<type>directory</type>

<node>

<text> Di rectory 2</text>

<type>directory</type>

<node>

<text>Directory 2-1 </text>

<type>directory</type>

<node>

The <files_and_directories> tag represents the extremities of the XML representation and it encompasses one entire broadcast channel's file system.

Files 101 and directories 100 are encoded as <node> tags. One <node> tag is assigned to each instance of a file or directory. The <text> parameter contains the name of the file or directory. The <type> parameter indicates whether the node is a file or a directory. Multiple child nodes can be nested or contained within one node, as long as the parent node is of type directory. Therefore, this versatile XML syntax enables all structures of file systems to be represented.

In addition to the XML syntax above, other tags may be included to provide more detailed information regarding the directory structure. For example, a <size> tag can be used to indicate the file size. A <file_type> tag might be useful to inform the mobile device of specific actions to take for a particular file. Internet Protocol Data-Casting (IPDC)

In the area of IPDC based broadcasting, the emerging File Delivery over Unidirectional Transport (FLUTE) protocol uses File Descriptor Tables (FDTs) to describe the broadcast file contents. All data are formatted into Internet Protocol (IP) packets. The FDTs describe the full path of the files and their respective sizes. FDTs are transmitted periodically in the IPDC data stream and are interleaved with the file payloads. Each FDT instance can describe the entire file system or just several files. The files defined in each FDT instance are always transmitted in subsequent IP packets. To derive the entire hierarchical structure of the broadcast file system, the complete collection of FDT instances have to be obtained and decoded.

Unlike, DSM-CC Object Carousel, no directory objects are present. IPDC payload only consists of file objects. To derive the directory structure, the paths of all the files described in the FDTs have to be parsed. In the file path representation, directory names are delineated with the "V character. Beginning with the root directory, the device processes each file path entry by noting successive directory names, up to the file concerned. As more file paths are processed, the hierarchical structure of the file system is gradually assembled. When all the FDTs have been processed, the hierarchical structure is then rendered onto the user interface. Therefore, this passive FDT scanning approach involves some computation and latency on the part of the mobile device.

No facility for additional descriptors and tables exists in the FLUTE protocol. The header formats within FLUTE are closed. Therefore, no means is available to carry directory specific information in the FLUTE layer to circumvent the computational resources required to derive the entire file system structure.

The Digital Video Broadcasting (DVB) standard covers the use of data broadcasting. When FLUTE data is transported over Motion Pictures Experts Group (MPEG) -2 Transport Stream (TS), the Multi-protocol Encapsulation (MPE) layer acts as an intermediate layer between the IP based FLUTE packets and the sections based TS. In other words, the IP stream is encapsulated in MPE sections within the MPEG-2 TS multiplex. DVB contains a signaling mechanism for mobile devices to discover the presence, availability and location of the IP streams. This signaling scheme is achieved through the use of IP/MAC Notification Table (INT) tables. The INT table provides the facility to contain additional descriptors. These descriptors provide more detailed platform, target and operational information. Therefore, this INT table feature can be exploited to carry directory structure information on behalf of FLUTE. Mobile devices will consequently decode both the FLUTE packets as well as the corresponding INT tables to more efficiently reconstruct the file system structure.

To this end, the embodiment proposes a new descriptor, termed the directory_structure descriptor. This descriptor can be embedded within the platform_deschptor_loop of the INT table It will carry the entire directory information of the upper FLUTE protocol layer that it is associated with. Mobile devices that support the use of this descriptor will tap on the ready information provided to construct the file system structure with minimal processing, whereas devices that do not support the descriptor will simply ignore it. This descriptor is therefore backward compatible to existing systems. The semantics and usage of the directory_structure descriptor has been described previously It is shown in Table 1 Preload Profiles

Profiles are used to describe a plurality of items that have been shortlisted for the preloading operation. Each item has several associated parameters. The Extended Markup Language (XML) is preferably used to define the parameters Other suitably formatted textual or binary representations can also be used. Each profile definition is stored in one XML file. The suggested XML representation is shown below. This embodiment also covers variations to the suggested XML syntax, as long as the spirit and purpose of the XML file remains the same.

<preload_configuration> <version></version> <schedule></schedule> <profile>

<profile_name> <item>

<profile_name></profile_name>

</profile> <preload_configuration>

The <preload_configuration> tag defines the extremities of the entire preload XML file. The file typically contains the same name as the <profile_name>.

The <version> tag helps mobile devices to identify and use the correct XML syntax to interpret the file. This feature will allow many different forms of XML syntax to coexist with each other and to also facilitate future feature upgrades.

Besides being initiated by users, preloading operations can also be scheduled to occur at specific times. This information is contained within the <schedule> tag. A syntax that describes the exact activation time can be defined. Many methods of denoting time information can exist. This invention is not tied to any one method Recurrence settings can optionally be included in that tag, like daily, weekly or a one off event.

As the name suggests, the <profile_name> tag stores the label given to the profile. The label has to be unique within the scope of the device, otherwise ambiguity will result. The label is case sensitive.

Each preload item is defined within the scope of <item> tags. There is no limit to the number of <item> tags within each profile. However, the onus rests on the mobile device to ascertain whether it is capable of preloading all the items within the selected profile. The <item_name> identifies the item. It must be unique within the profile definition. It may not be unique across profiles. This is to allow a plurality of profiles to commonly denote a particular file for preloading.

Each item in the profile configuration will have an associated address of its location in the broadcast channel. This address enables the mobile device to establish where the data item can be found. It is stored in the <path> tag. Depending on the particular implementation of broadcast protocol, the address can be an absolute path from the root directory or just a relative path from another directory. The address should also include the file name. The file name can be similar to that defined in the <item_name> tag.

The expected or estimated memory size of the individual data items can also be stored in the profile. This allows the terminal device to conduct memory management operations and checks prior to preloading. The <size> tag stores the memory requirements of the item in bytes. If a device deems an item to be unsuitable for preloading because of its required memory footprint, a notification can be sent to the device user that the selected preload item would not be downloaded. This could occur when the amount of items that are selected for preloading exceeds the internal memory capacity of the mobile device. In some cases, the size of the item is only known just prior to downloading. The device would then have to make a decision whether to proceed with the download or not. A zero value can be attached to the <size> tag when the size is not known at the time the profile is constructed.

A data type designation, <type>, can also be attached to the items. This feature enables devices to take the appropriate processing action, if necessary, after downloading. The data type can also be derived from the file name extension that is defined in the <path> parameter. This <type> tag is useful in cases where no file name extension exists, or when special processing is required for a particular data item.

The priority setting is defined by the <priority> tag. It is used to indicate the relative importance of an item compared to the rest of the items in the profile. When device memory is limited, only those items with a high priority metric are given precedence in downloading.

A mixture of data items and profiles can be defined under one profile. This nesting ability for profiles allows the creation of master profiles that groups profiles with different focus.

Preload profiles are also intended to be portable, in that they are not specific to any mobile device or hardware and software implementation. The XML representation used promotes the portable nature of the profiles. They can be easily reused by devices that support the same broadcast channel protocol. As such, they can be transferred and copied between devices. For added versatility and portability, the Unicode representation of characters can also be used. Content Selection Interfaces

To define the collection of contents or files and directories for a preload profile, a user interface portion which resides in mobile devices is presented. There are many embodiment variations to user interfaces, whether graphics or text based. These interface variations adhere to the central purpose of presenting the broadcast channel contents in a logically organized manner with accompanying content selection portion. The scope is not limited to the specific layout or particular graphical elements presented in the user interface diagrams of this embodiment. It must be understood that the diagrams and textual descriptions only represent one of the many possible embodiments of this invention. This interface should also cater for the selection of multiple content items or categories. In addition to the presentation of organized contents, the file system of the broadcast channel can also be shown, with the ability to select multiple files and directories.

Therefore, there are two basic modes of operation in the interface. One mode organizes the content into broad categories, akin to the menu systems the data broadcast applications. The other mode presents the lower level file system view. Both of these modes feature selection means for contents or files and directories.

Upon confirmation of the selection, the device generates the equivalent XML representation of the preload selection. This XML file would be associated with the profile name that was previously defined. The existence and technical details pertaining to the XML file format is shielded from the user The user is thus only concerned with naming the profile and deciding which contents, file and directories to preload. Figure 2 presents an embodiment of a graphical user interface 200 that is used to display the broadcast channel contents in a hierarchical format. A tree structure is adopted. The main branches 204 represent the broad categories. Each main branch can have one or many sub-branches 205 emerging from it. The sub- branches gradually break down the contents into more detailed sections. There can be many levels of sub-branches. Each successive level further segregates content categories. At the furthest level, the sub-branches terminate with one or many leaves that represent the actual content. The content of the branches sub-branches and leaves can vary depending on the broadcast channel data.

Each branch, sub-branch and leaf contains a label that describes its content designation. For differentiation, they can be color coded. In addition, a graphical element is attached to each branch, sub-branch and leaf. This can be in the form of a check box or any other means as long as it allows the selection of the branch, sub- branch or leaf When a particular branch or sub-branch is chosen, all the sub- branches and items within it are automatically chosen as well. That is, the check boxes of the lower level branches or leaves are automatically changed to the selected state.

The user interface also contains a Save button 211 which provides a means to confirm the selection of the preload items. On the other hand, the Cancel button 209 aborts the content selection process and all item selections will be ignored by the device. The device would then revert to its previous state. Vertical 202 and horizontal 203 scroll bars can be employed when the hierarchical structure cannot be fully rendered within the confines of the available display area. These bars permit the user to view different portions of the structure. The user interface can also allow other profiles to be imported and included in the current profile.

The interface can also feature other functions to aid in the content selection process, comprising, but not limited to, the expansion of the entire tree structure 206, the minimization of the entire tree structure to the root branches 210, the expansion of the tree structure up to a certain level, the selection of all content items in the entire tree 208 and also resetting all the selections in the tree 207. These facilities expedite the selection of items and also enhance the usability of the user interface.

Figure 2 shows a typical usage of the selection interface for preloading broadcast contents. A profile name 201 can been assigned, which must be unique for all the profiles within the mobile device. Several categories of contents have also been chosen using the checkbox graphic element.

In addition to the broadcast content categories, files and directories in the broadcast file systems can also be specified ,for preloading. These files and directories represent the raw data of the broadcast channel, which can be very different from the structure of the menu driven broadcast applications that the broadcast channel carries. Figure 3 shows the selection user interface 300 for preloading files and directories. When a particular directory is selected, all the files and directories within it are automatically selected. The purpose and usage of the interface elements 301 302 303 306 307 308 309 310 311 is similar to that used for selecting content categories.

In Figure 3, several files 305 and directories 304 have been selected. When a file residing in a directory structure is selected, all the corresponding directories above it up to the root level are automatically reconstructed in the mobile device, even though no files in those directories have been selected. In the XML profile file, the entire path specification of the selected file or directory from the root level is saved.

Preload Profile Management

Many preload profiles can be stored within each mobile device. Each profile can be geared towards a specific genre of content, a specific user or a specific content provider. Therefore, there is a need for a means to manage the collection of profiles within a device. Management operations comprise, but are not limited to, creation 402, deletion 403, transfer, scheduling 404 and activation 405.

Figure 4 shows only one of the many possible embodiments of mobile device user interfaces 400 for the selection and management of preload profiles 401. Other forms of user interfaces, whether graphical or textual, with different layouts and designs can also be used, as long as they enable the user to perform the previously listed profile management operations. The list of preload profiles varies according to the plurality of profiles stored in the mobile device. The Cancel button 406 terminates the profile selection interface.

New profiles can be created. This is done by first specifying the profile name. An interface is then presented that enables the user to select the contents, files and directories for preloading. Other profiles can also be embedded within this newly created profile. Upon confirmation, the device checks to confirm whether the specified profile name is unique compared to all the other profiles currently stored in that device. This is the approach for profiles that are created from the ground up.

Alternatively, a new profile can be created by using another existing profile as a template. In this case, an interface containing the settings for the contents, files and directories of the template profile is shown. The user then modifies the settings accordingly for the new profile and saves those under a new profile name. This feature is useful especially when fairly similar profiles have to be created. The deletion operation involves the selection of the profile, confirmation and the erasure of the profile from memory.

Profiles are designed to be portable. They can be transferred between devices or downloaded from the service provider. The XML file format adopted allows devices with very different implementations to commonly share profile files. Profiles can be transferred between devices in a number of ways, comprising, but not limited to, infrared means, Bluetooth™ means, wireless Local Area Network (LAN) means and wired means. Devices would first establish a communication link between each other, followed by the selection and transfer of profiles. When completed, the communication link is disconnected.

To initiate a preloading operation, the desired profile is selected and then activated. Upon completion, a notification is sent to the user. Any errors that occurred during the preloading operation are also made known to the user. Errors occur when the stipulated content, file or directory no longer exists in the broadcast channel. The user is given a choice either to delete the missing items from the profile or to just preserve the state of the profile items.

Additionally, specific preload times can be scheduled for different profiles at different times of the day. The profile activation schedule can be shown next to the profile entries in the user interface. For example, a daily news profile can be set for preloading in the morning before the user wakes up. Another profile that focuses on stock market news can be invoked at lunch time. These can be recurring events on a daily or weekly basis, or even one off events. The profile scheduler automatically turns on the device's broadcast channel receiver and decoder when a profile is due for activation, even when the device is not being used at the time of activation. The receiver and decoder are automatically turned off after use. On the other hand, if the device is being used for other purposes at the time of activation, the preloading operation takes place as a background process. Preload Configuration

The preloading operation is governed by many parameters. These parameters can be configured manually by the user or determined automatically by the device. An embodiment of a user interface 500 for adjusting the preloading parameters is shown in Figure 5. Other forms of user interfaces, whether graphical or textual, with different layouts and designs can also be used, as long as they enable the user to tweak the preloading parameters.

Apart from the ability to schedule the activation of profiles, the device is able to automatically initiate the reloading of profile contents. This is useful in helping to keep the contents up to date. The Update Period parameter 501 adjusts the time interval between successive update operations. This can be a global setting that is applicable to all profiles or specifically targeted at just a number of profiles. This feature can be enabled or disabled. Setting an update period that is too small will ensure very up to date contents, but at the expense of higher power consumption and hence lower the battery life.

The Download Limit parameter 502 can be used to restrict the amount of data that is permitted for downloading during each preloading cycle. A data counter is used to monitor the cumulative amount of downloaded data for the preload profile concerned. A warning notification would be issued to the user if the preload data exceeds the preset limit. The user can either react by stopping the download or by allowing the download to continue. When a particular broadcast directory is setup for preload, changes to the collection of directory files made by the content provider can result in a directory that unexpectedly requires a larger amount of memory for storage. Therefore, this feature acts as a safeguard by preventing devices from inadvertently downloading a large quantity of data. In addition, it stops profiles from consuming too much storage in memory limited mobile devices.

The downloaded contents often make references to files or contents that are located in other non-downloaded directories. In typical operation, devices would attempt to resolve all the references that are attached to a particular page before rendering it. This involves the acquisition of files or images to assemble the final page. If the referenced file or image is . not present in the device's memory, the download module would be tasked to extract the missing data from the broadcast channel.

The benefits derived from the preloading operation would be significantly diminished if missing reference files were to be downloaded every time they were required. This would most likely lead to increased latency as the files would have to appear in the broadcast channel before they can be retrieved. Battery consumption would also be increased as the receiver and decoder modules have to spend more time to monitor the broadcast channel.

To circumvent this issue, an Offline Viewing parameter 503 is made available to disable the download of referenced files when they are not present in the device's memory. Therefore, the rendering of pages would be constrained to whatever data is available from within the device. This feature will clearly reduce the latency and improve the battery's life span. However, the user would not be able to enjoy the full presentation effect of the material as envisaged by the content provider.

The OK button 504 confirms the preload configuration settings, while the Cancel button 505 terminates the interface and ignores the changes that have been made.

Functional Block Diagram of Preferred Embodiments

- Figure 6 shows the block diagram of the mobile data communication device constructed in accordance with the invention. The In Band Data Retrieving Unit 600 retrieves, demodulates and channel decoded the RF input signal to produce the transport stream 601 containing the broadcast contents. The Data Selecting Unit 604 extracts the section table data from the transport stream 601 and filter the desired data by identifying the unique 13-bit PID. When the matching data is encountered, the Data Selecting Unit 604 sends the selected data 605 to the Broadcast Content Managing Unit 606 that manages and stores the selected broadcast data 612 for use by the Decoding Unit 613. The Decoding Unit 613 decodes the broadcast data 612 and sends the display data 614 to the display Unit 615 for rendering the broadcast contents structure.

The Preloading Managing Unit 608 retrieves the preloading information 607 and manages the preloading operations by extracting the selected broadcast contents 611 from the Data Selecting Unit 604. The collection of selected contents 609 are send to the Preloading Unit 610 that preloads the preferred broadcast contents for storage The collection of preloaded contents shall be relayed to the Broadcast Content Managing Unit 606 for immediate consumption by the Decoding Unit 613 when required, thus eliminating the latency for having to retrieve the data from the stream.

Power saving is achieved by feeding the time slicing information 601 back to the In band Data Retrieving Unit 600 to power-off the front-end reception during the time slot whereby the desired data are not transmitted. The Out of Band Retrieving Unit 602 can derive data wirelessly through a multicast scenario that supplements the data transmission for delivering the desired broadcast contents as described above. Moreover, the derived data comprising of application and data for execution 603 can be downloaded by the Data Selecting Unit 604 to be consumed by the Decoding Unit 613 for displaying broadcast services and contents.

Mobile Device Power Conservation

The conservation of battery power resources is one of the top technical design issues facing designers of mobile devices. This issue has a significant effect on the size, capabilities, feature set, hardware and software design approaches for such devices. With proper application of this invention, mobile device power savings can be achieved.

Under conventional mobile device operation and usage of broadcast applications, many repeated content navigation, selection and download cycles require the device's receiver module to be continually turned on. Between these cycles, the user typically takes time to digest the information that is rendered on the device. This causes a strain on battery resources when used for any length of time. Instead, the receiver module should be activated just long enough for sufficient data reception and decoding, but without compromising the usage of the broadcast applications.

Depending on the user's content viewing habits, the power savings can be very significant. The application of this invention can therefore be very beneficial in extending the battery life and operational duration of the mobile device.

The described embodiment enables the automatic download of specific content to a mobile data communication device. It does not require direct action from the user to serially download each desired content category one at a time. Time savings can therefore be derived from the use of this invention, as the user does not need to wait for frequently accessed content to be downloaded. In conventional art, the user has to navigate to each desired content category and subsequently wait for the content to be downloaded. The downloading process can even take place in the background, when the device's receiver module is being for other purposes. Therefore, the connection time, or the time taken by the device's receiver module to scan the broadcast channel and download the required data, is much reduced. This leads to device power conservation, as the receiver module is used for a shorter period of time - just long enough to scan the channel and download the desired data, instead of repeated navigate, download and view cycles. In addition, this invention allows the user to download specific files and directories from the broadcast channel. Typical menu-driven device applications do not expose this ability. To allow data items to be selected for preloading, the mobile device requires a snapshot of the available broadcast contents. This embodiment encodes the hierarchical structure of the application content and files and directories and embeds this information in the broadcast channel. Mobile devices would then extract this information to easily reconstruct the structure of the broadcast contents without having to resort to computationally expensive passive scanning.

While the invention has been described with reference to the exemplary embodiments thereof, the technical scope of the invention is not restricted to the description of the exemplary embodiments It is apparent to the skilled in the art that various changes or improvements can be made. It is apparent from the description of claims that the changed or improved configurations can also be included in the technical scope of the invention.

Claims

1. A method of preloading data in a mobile data communication device, comprising: encoding a broadcast contents structure; delivering said encoded broadcast contents structure; retrieving said encoded broadcast contents structure on the communication device; decoding and displaying said broadcast contents structure; selecting broadcast contents for preloading; managing said broadcast content selections; managing preloading operations; and preloading said broadcast contents selections.

2. The method of claim 1 , wherein said broadcast contents comprise at least one of the following: categorically organized application data and resources in textual or binary form; audio and video media in file or streaming form; and files and directories of a broadcast channel.

3. The method of claim 2, wherein said broadcast contents comprise at least the categorically organized application data and resources in textual or binary form, the method further comprising: parsing said broadcast contents to obtain a structure of the categorically organized application data and resources; manually specifying the structure of the categorically organized application data and resources; encoding the structure of the categorically organized application data and resources into a descriptor or table; and inserting the descriptor or table into the broadcast channel.

4. The method of claim 2, wherein said broadcast contents comprise at least the files and directories of the broadcast channel, said encoding method further comprising: parsing said broadcast contents to obtain a structure of the files and directories of the broadcast channel; manually specifying the structure of the files, and directories of the broadcast channel; encoding the structure of the files and directories into a descriptor or table; and inserting the descriptor or table into the broadcast channel.

5. The method of claim 3, further comprising: specifying categories, sub-categories and content as nodes; specifying names of the categories, sub-categories and content; specifying associated information of the categories, sub-categories and content; representing the categories, sub-categories and content as a tree structure; including versioning information; and encoding the tree structure into Extended Markup Language (XML) format.

6. The method of claim 4, further comprising: specifying the files and directories as nodes; retrieving the names of the files and directories, specifying associated information of the files and directories, representing the files and directories as a tree structure; including versioning information; and encoding the tree structure into Extended Markup Language (XML) format;

7. The method of claim 3, further comprising: embedding a descriptor in a private data section of a Download Server Initiate message, which is delivered over object carousels; embedding the descriptor in a private data section of an Internet Protocol / Media Access Control (IP/MAC) Notification Table, which is delivered over transport streams; and embedding the table as a section in the transport streams.

8. The method of claim 4, further comprising: embedding a descriptor in a private data section of a Download Server Initiate message, which is delivered over object carousels; embedding the descriptor in a private data section of an Internet Protocol / Media Access Control (IP/MAC) Notification Table, which is delivered over transport streams; and embedding the table as a section in the transport streams.

9. The method of claim 1 , further comprising: providing a user interface to display the broadcast contents structure in a tree form; providing a selection means to allow users to choose contents; specifying a selection as a profile; and storing the specified profile into a file.

10. The method of claim 9, method further comprising: encoding the profile in Extended Markup Language (XML) form; specifying selection contents in XML form; assigning a name to the profile; and storing the profile in a persistent memory of the communication device.

11. The method of claim 1 , wherein the broadcasting contents structure is obtained by at least one of the following: passive scanning and decoding of broadcast channel information to obtain indirectly said broadcast contents structure; and retrieving descriptors and tables from a broadcast channel to directly obtain the broadcast contents structure.

12. The method of claim 1 , further comprising: rendering the broadcast contents structure in graphical or textual form on the mobile communication device; providing a means to select specific items from the broadcast contents; grouping the selected items as a profile; encoding the selected items into Extended Markup Language (XML) form; and saving the profile in the mobile communication device.

13. The method of claim 1 , further comprising: displaying a collection of preload profiles stored within the communication device; creating new preload profiles; deleting some of said preload profiles; editing existing preload profiles; scheduling an activation of said preload profiles; and transferring the preload profiles from the communication device.

14. The method of claim 1 , further comprising: configuring a frequency of activation of the preloading of the broadcast contents selections; configuring a maximum download data size of the preloading of the broadcast contents selections; and configuring a referencing of outgoing links of the preloading of the broadcast contents selections.

15. The method of claim 1 , further comprising: retrieving a profile file from a persistent storage of the mobile data communication device; decoding contents of the profile file; scanning the broadcast channel to detect a presence and location of the contents of the profile file; checking a size of items before downloading; downloading the items into the mobile data communication device; and informing the user of a status of the preloading of the broadcast contents selections.

16. A method of specifying and delivering a structure of a broadcast channel file system, comprising:

^■ parsing an entire broadcast channel file system; encoding a structure of the broadcast channel file system into a textual or binary format; embedding textual or binary formatted information in a descriptor or table; periodically inserting the descriptor or table into a broadcast channel; detecting or being informed of updates to the broadcast channel file system; and including versioning information in the descriptor or table.

17. A method of specifying and delivering a structure of broadcast application data and resources, comprising: parsing contents of the broadcast application data and resources; encoding a structure of the contents into textual or binary format; embedding textual or binary formatted information in a descriptor or table; periodically inserting the descriptor or table into a broadcast channel; detecting or being informed of updates to the broadcast application data and resources; and including versioning information in the descriptor or table.

18. An apparatus for preloading data in mobile data communication devices, said apparatus comprising: a retrieving unit that retrieves encoded broadcast contents structure on the communication device; a decoding unit that decodes and displays the broadcast contents structure; a selecting unit that selects broadcast contents for preloading; a first managing unit that manages said selected broadcast content; a second managing unit that manages preloading operations; and a preloading unit that preloads said broadcast contents selections.

19. The mobile data communication device apparatus of claim 18, further comprising: a deriving unit that derives data wirelessly through a multicast scenario; a downloading unit that downloads applications and data for execution and viewing locally; and a consuming unit that consumes services and content offered by broadcasters.