Patent Application
20060026376
Due to recent advances in technology, computer users are now able to enjoy many features that provide an improved user experience, such as playing various media and multimedia content on their personal or laptop computers. For example, most computers today are able to play compact discs (CDs) so users can listen to their favorite musical artists while working on their computers. Many computers are also equipped with digital versatile disc (DVD) drives enabling users to watch movies.
In some multimedia environments, a computer has access to a computer-readable medium storing compressed media files such as Moving Picture Experts Group audio layer-3 (MP3) files and WINDOWS MEDIA technologies audio (WMA) files. When the media files are rendered on a computer, the computer typically has access to a database storing metadata describing albums, artists, genres, years, or the like for the media files. The computer typically organizes the media files into playlists based on the metadata when the compressed media files are played on the computer. For example, in the case of audio media files, the files may be organized by album, artist, genre, year, or some user specified selection and ordering. This allows users to easily have access to all of their content regardless of whether or not the users manually created a playlist.
However, low-end rendering devices with limited resources take a long time to display on-screen graphics. These devices are often constrained in disk-seek and processing power. For example, a low end DVD player contains a 16 bit processor having a two second seek time. Some existing devices require extra time to display the on screen images because the on screen menu images are each stored as a separate file on the media. Each image file is located on the disk, opened, and then decoded for display. For example, if a menu lists seven items of content, the device has to open eight image files: the background image file plus seven thumbnail image files for the content items. Existing devices have to open many files to display a menu and these devices may experience delays in seeking each of the files.
Accordingly, a system including an efficient storage model for menu images is desired to address one or more of these and other disadvantages.
Embodiments of the invention accelerate the loading and display of a menu of media files on consumer electronic devices having a low-power processor, limited memory and/or limited display capabilities. In an embodiment, the invention stores relevant image data for the menu in an optimized image data store such as a compound image file. The compound image file includes the relevant image data organized in a memory efficient manner. For example, the boundaries of each compound image file correspond to the sector size of the computer-readable medium storing the compound image file. In one embodiment, a device need only run a single seek-and-open operation to load a menu. Once the compound image file has been opened, the menu images may be read in a single operation provided there is sufficient buffer memory available. By reducing the number of file operations, the load and display times of a device are greatly improved.
Alternatively, aspects of the invention may comprise various other methods and apparatuses.
Other features will be in part apparent and in part pointed out hereinafter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
Referring first to
One aspect of the present invention enables the user or, particularly, enables a media player program executing on computing device 112, to access, retrieve, and display for the user, so-called metadata. Those skilled in the art are familiar with metadata, which is simply information about data. In the context of the illustrated embodiment, metadata includes information related to specific content of a digital media file being played on the media player. Basic metadata includes, but is not limited to, title, performer, genre, track number, and the like. Extended metadata includes, but is not limited to, cover art, composer, description of content, performer biographies, reviews, ratings, related performers, where to buy similar items, upcoming concerts, ticket sales, URLs to other related experiences including purchase opportunities, studio, director, and the like. In one embodiment, extended metadata may be organized into two main categories: metadata retrieved or downloaded, and metadata computed from the media file (e.g., digital signal processing of the file stream). The metadata may be stored within the media file or stored in another file accessible and known to the media file.
In one example, additional metadata is available from the metadata provider 111 via a data communication network 113. The computer 102 and metadata provider 111 are coupled to the data communication network 113. While the network 113 includes the Internet in one example, the teachings of the invention may be applied to any data communication network. Data communication network 113 may support, for example, client/server communications or peer-to-peer connections.
The consumer electronic devices 112 or computer 102 may have access to one or more computer-readable media (e.g., memory area 114). While the memory area 114 is illustrated to be part of any of the consumer electronic devices 112 in
In one embodiment, memory area 114 stores a compound image file 116. The compound image file 116 includes the relevant image data 118 for a menu. The menu may be defined in a menu file 115, a menu structure file, or the like. The relevant image data 118 may include all images associated with the menu such as a background image and one thumbnail image for each media file or other item of content listed in the menu. In general, the compound image file 116 may store a plurality of image data 118 such as image data #1 through image data #N. Each of the image data 118 corresponds to an image that is associated with a media file. The media file is associated with at least one menu. The compound image file 116 also includes a plurality of image entries 120 such as image entry #1 through image entry #N each storing a reference (not shown) to one of the plurality of images. Each of the plurality of image entries 120 further stores a menu identifier (not shown) identifying the menu associated with the image entry 120. In one embodiment, the compound image file 116 further stores a menu entry (not shown) associated with each menu that identifies a background color and/or a text color for the menu.
In one embodiment, the consumer electronic devices 112 (e.g., a portable media device) are configured to execute computer-executable instructions for presenting a menu of media content to a user. The computer-executable instructions may be organized into one or more components. For example, the consumer electronic devices 112 may store a menu component 122, an image component 124, a cache component 126, and a display component 128. The menu component 122 receives menu data from memory area 114. The menu data defines a menu of media files. Each of the media files has an image associated therewith. The image component 124 identifies, from the menu data received by the menu component 122, the compound image file 116 associated with the menu data. The compound image file 116 stores image data 118 (e.g., a thumbnail image) for each of the media files. The cache component 126 retrieves the image data 118 from the identified compound image file 116 as a function of the menu data. The display component 128 renders, to a user for navigation and selection, the menu with the image data 118 retrieved by the cache component 126. In one embodiment, the menu data is stored within the compound image file 116.
The computer 102, or other device or software, also has one or more exemplary modules or components for implementing aspects of the invention. In one embodiment, the computer 102 or other device with menu rendering capability has access to and may execute the menu component 122, the image component 124, the cache component 126, and the display component 128 to present a menu of media content to a user. In another embodiment, the computer 102 or other rendering device with authoring capability may have a computer-executable component such as an authoring component 129 for defining the menu data based on a grouping of the media files, identifying the image data 118 for the media files, receiving the identified image data 118 from a metadata provider or the like (e.g., from a metadata repository, from within the image files), and storing the retrieved image data 118 in the compound image file 114. These operations are described in
The invention software may be implemented with any number and organization of components or modules. That is, the invention is not limited to the specific configuration of the menu component 122, image component 124, cache component 126, display component 128, the authoring component 129, or any other computer-executable instructions executed by the consumer electronic devices 112 and/or computer 102, but may include more or less components having more or less individual functionality than described herein. Further, the invention may be embodied in hardware, software, or a combination thereof in a media player, operating system, DVD recorder, CD recorder, video camera, hard drive, flash drive, personal digital assistant, wireless device (e.g., cellular telephone), or the like.
The invention allows a device to do a single seek and open operation to display most menus. Once open, the menu images may be read in a single operation given enough buffer memory in the device. A single seek operation may take up to two seconds. The invention reduces the number of file operations needed to display a menu. Further, images are stored in the compound image files 116 on boundaries corresponding to a sector size of the computer-readable medium storing the compound image file 116. This improves the seek efficiency as all seeks in the file are guaranteed to occur on a sector boundary. As such, the invention greatly improves the load and display times for the menu to enhance the consumer experience.
Referring next to
In the example of
Referring next to
The method further populates each of a plurality of image entries with the determined references at 312. The image entries act as an index table. The method associated each image entry with a particular menu by populating each image entry with a menu identifier associated with the particular menu. The populated image entries are stored in the compound image file on the computer-readable medium at 314.
In one embodiment, one or more computer-readable media have computer-executable instructions for performing the computerized method illustrated in
Referring next to
The exemplary method illustrated in
Referring next to
The compound image file includes an index table identifying each thumbnail stored within the compound image file. The compound image file may contain images for multiple menus, but a menu will never span multiple compound image files. Thumbnails are duplicated across compound image files as necessary.
The identifier field is an 8-byte entry such as the text string “CMPIFHMT”. The version field is a 2-byte entry representing the version of the specification of this playlist file. The ‘size of compound image file’ field is a 4-byte entry representing the size of the current <Compound Image>.HMT file in bytes. The ‘number of menu entries’ field is a 4-byte entry representing the number of menu entries in the menu table. The ‘number of image entries’ field is a 4-byte entry representing the number of image entries in the compound image file. The ‘name of authoring application’ field is a 64-byte entry representing the text string name of the authoring application.
The menu table includes a list of menu entries sorted in ascending order by the menu identifier. The fields in an exemplary menu entry data structure are shown in the table below.
The ‘menu ID’ field is a 4-byte entry representing the menu identifier of the menu header which references the current menu entry. The ‘background ID’ is a 4-byte entry representing the menu content identifier (e.g., Menu Content ID) for the image to display as the background of this menu. A value of zero indicates there is no background image. If this field contains a non-zero value then image data with image type ‘BACKGROUND IMAGE 4×3’ or ‘BACKGROUND IMAGE 16×9’ for the corresponding menu content identifier is stored in the image entry in the current compound image file. The ‘text color’ field is a 4-byte entry defining the color for the text on the current menu on the display. The entry is formatted as an RGB value with 0xFFRRGGBB as the byte order, where 0xFF are the actual hex digits and RR, GG, and BB denote the values of the red, green, and blue values respectively. If the ‘background ID’ field or the ‘background color’ field is populated, then the ‘text color’ field includes a non-zero value. A value of zero means that the player should select a text color that contrasts with the default background color. If a player is not capable of color rendering, this field may be ignored. The ‘background color’ field is a 4-byte entry defining the background color that should be used when the current menu is rendered on the display. It is formatted as an RGB value with 0xFFRRGGBB as the byte order, where 0xFF are the actual hex digits and RR, GG, and BB denote the values of the red, green, and blue values respectively. If the ‘background image ID’ field is defined, the background color is only visible on areas of the display not covered by the background image. A value of zero indicates there is no background color and that the player may use its own default background color. If a player is not capable of color rendering then this field may be ignored.
Image entries are sorted in ascending order by Menu Content ID then Type. There may be multiple entries with the same Menu Content ID provided each has a different Type. Applications or devices with authoring capability add new image data at the end of the entries. When updating the entries, the authoring applications may move the image data “down” a sector (e.g., two kilobytes for a DVD) to make room for another entry. If there are more than 400 images in the compound image file, a new file is created in one embodiment. Any unused space in the image data should be padded with zeros.
In one embodiment, multiple entries point to the same image data. In other embodiments, there is a one-to-one relationship between entries and image data. Further, there is only one entry per Image Type per Menu Content ID in the compound image file. Menus that wish to use the same thumbnails for menu items may use the same Menu Content ID for each of the menu items to minimize the space used in the compound image file. The fields in an exemplary image entry data structure are shown in the table below.
The ‘menu content ID’ field is a 4-byte entry defining the menu content identifier for the corresponding image data that is referenced by menu and playlist items. The menu content identifier is unique within all compound image files on a particular computer-readable medium. The ‘image type’ field is a 2-byte entry representing the image type (e.g., the type of menu image). Exemplary image type values are shown in the table below.
The ‘offset to image data’ field is a 4-byte entry represents the byte offset from the beginning of the compound image file to the image data for this menu image. This offset value is a multiple of the sector size of the computer-readable medium storing the compound image file (e.g., 2,048 for a DVD). The ‘image data length’ field is a 4-byte entry representing the length in bytes of the image data.
Referring next to
The identifier field is an 8-byte entry such as the text string “MENU_HMT”. The version field is a 2-byte entry representing the version of a specification to which the current menu file conforms. The ‘size of MENU.HMT’ field is a 4-byte entry representing the size of the current MENU.HMT file in bytes. The ‘name of authoring application’ field is a 64-byte entry representing the text string name of the authoring application. The ‘offset to root menu’ field is a 4-byte entry representing the byte offset from the beginning of the current MENU.HMT to the root menu header. The ‘menu title length’ field is a 2-byte entry representing the byte length of the menu title (excluding any termination null bytes). The ‘menu title’ field is the menu title as a text string. An empty string (e.g., one null character) indicates that there is no title to display.
Each menu header represents one menu within the menu hierarchy and contains references to its single parent menu and its child items. Each child item is either a reference to a child menu or a reference to a playlist file. The child menu also has the same format as the menu header. Each child menu is referenced by a single parent menu to form a hierarchical menu structure. The first menu header in MENU.HMT is the top-level menu. In one embodiment, menus support either a background image, a solid background color, or default player behavior. If a background image or background color is defined, the text color is also defined. If a valid text color and background image or color are not defined, the player uses default behavior. Padding is written after each menu header to allow for easier additions to the menu. The amount of padding should not exceed the sector size of the computer-readable medium storing the menu header (e.g., 2,048 bytes for a DVD). Further, the padding may be an even number to preserve 2-byte alignment. The fields in an exemplary menu header data structure are shown in the table below, where ‘n’ represents the number of menu items.
The ‘size of menu header’ field is a 4-byte entry representing the size of the menu header including the menu and playlist items and any padding in bytes. The ‘offset to parent menu’ field is a 4-byte entry representing the byte offset from the beginning of MENU.HMT to the beginning of the menu header corresponding to the parent menu. This value is zero if the current menu header is the top-level menu. The ‘offset to padding’ field is a 4-byte entry representing the byte offset from the beginning of MENU.HMT to the beginning of the padding at the end of the current menu header. This value is zero if there is no padding. The ‘menu ID’ is a 4-byte entry representing the unique identifier for the current menu header in MENU.HMT. In one embodiment, the menu identifiers start at a value of one when the MENU.HMT file is initially created. It is possible for the MENU.HMT file to not have a menu identifier of one after edit operations. The ‘compound image file ID’ field is a 4-byte entry representing the identifier of the compound image file that contains the menu images for the current menu header. The ‘number of items’ field is a 2-byte entry defining the number of menu or playlist items in the current menu. The ‘menu subtitle length’ field is a 2-byte entry representing the byte length of the menu subtitle excluding any ending null bytes. The ‘menu subtitle’ field represents the text string menu subtitle. An empty string (e.g., one null character) indicates that there is no subtitle to display. The ‘menu or playlist item’ field is a variable-sized entry representing either a menu item or a playlist item.
The fields in an exemplary menu item data structure are shown in the table below.
The ‘type of entry’ field is a 1-byte entry identifying either a menu item or a playlist item. The values of exemplary entry types are shown in the table below.
The ‘menu summary type’ field is a value defining the type of playlists that are accessible through the current menu item. This value is a logical OR of the summary types of the items the current menu item contains. The ‘menu content ID’ field is a 4-byte entry representing the menu content identifier of the image file (e.g., a thumbnail image file) for the current menu item in the corresponding compound image file. If there is no image for the current menu item, the value is zero. If this field contains a non-zero value, the image data with an image type of ‘THUMBNAIL IMAGE’ or ‘SELECTED THUMBNAIL IMAGE’ for the current menu content identifier is stored in the image entry in the corresponding compound image file. The ‘offset to menu’ field is a 4-byte entry defining the byte offset from the beginning of MENU.HMT to the sub-menu below this menu item in the menu hierarchy. The ‘menu name length’ field is a 2-byte entry containing the byte length of the name of the menu item (e.g., excluding any ending null bytes). The ‘menu name’ field is a text string name of the menu item as it appears in the menu displayed to the user.
The fields in an exemplary playlist item data structure are shown in the table below.
The ‘type of entry’ field is a 1-byte entry defining either a menu item or a playlist item. This value is the value of PLAYLIST from Table 8 above. The ‘playlist summary type’ field is a value defining the type of playlist that this playlist item references. The ‘playlist ID’ field is a 4-byte entry defining the playlist identifier for the current playlist item. The ‘menu content ID’ field is a 4-byte entry representing the menu content identifier of the image file (e.g., a thumbnail image file) for the current playlist item in the corresponding compound image file. If there is no image for this playlist item, the value is zero. If this field contains a non-zero value, the image data with an image type of ‘THUMBNAIL IMAGE’ or ‘SELECTED THUMBNAIL IMAGE’ for the current menu content identifier is stored in the image entry in the corresponding compound image file. The ‘starting group index’ field is a 4-byte entry containing the index of the offset group entry in the offset group table. Playback starts at the playlist group corresponding to the index of the offset group entry contained in this field. A value of one indicates the first playlist group listed in the offset group table in the playlist. The ‘starting file index’ field is a 4-byte entry defining the index of the file in the playlist group at which playback starts. A value of one indicates the first file in the playlist group. The ‘starting group index’ field and the ‘starting file index’ field together allow one playlist to be referenced multiple times in the menu. For example, a menu may show thumbnails for every image on the disk to a user, and each thumbnail returns the user to a different starting point beginning with the selected image. However, the rendering of the playlist ends when the end of the playlist is reached. The ‘playlist name in menu length’ field is a 2-byte entry containing the byte length of the playlist name in the menu (e.g., excluding any null characters). The ‘playlist name in menu’ field is the text string name of the playlist as it appears in the menu displayed to the user.
Referring next to
Referring next to
Referring next to
Referring next to
Referring next to
Exemplary Operating Environment
The computer 130 typically has at least some form of computer readable media. Computer readable media, which include both volatile and nonvolatile media, removable and non-removable media, may be any available medium that may be accessed by computer 130. By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by computer 130. Communication media typically embody computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of any of the above are also included within the scope of computer readable media.
The system memory 134 includes computer storage media in the form of removable and/or non-removable, volatile and/or nonvolatile memory. In the illustrated embodiment, system memory 134 includes read only memory (ROM) 138 and random access memory (RAM) 140. A basic input/output system 142 (BIOS), containing the basic routines that help to transfer information between elements within computer 130, such as during start-up, is typically stored in ROM 138. RAM 140 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 132. By way of example, and not limitation,
The computer 130 may also include other removable/non-removable, volatile/nonvolatile computer storage media. For example,
The drives or other mass storage devices and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into computer 130 through input devices or user interface selection devices such as a keyboard 180 and a pointing device 182 (e.g., a mouse, trackball, pen, or touch pad). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to processing unit 132 through a user input interface 184 that is coupled to system bus 136, but may be connected by other interface and bus structures, such as a parallel port, game port, or a Universal Serial Bus (USB). A monitor 188 or other type of display device is also connected to system bus 136 via an interface, such as a video interface 190. In addition to the monitor 188, computers often include other peripheral output devices (not shown) such as a printer and speakers, which may be connected through an output peripheral interface (not shown).
The computer 130 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 194. The remote computer 194 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer 130. The logical connections depicted in
When used in a local area networking environment, computer 130 is connected to the LAN 196 through a network interface or adapter 186. When used in a wide area networking environment, computer 130 typically includes a modem 178 or other means for establishing communications over the WAN 198, such as the Internet. The modem 178, which may be internal or external, is connected to system bus 136 via the user input interface 184, or other appropriate mechanism. In a networked environment, program modules depicted relative to computer 130, or portions thereof, may be stored in a remote memory storage device (not shown). By way of example, and not limitation,
Generally, the data processors of computer 130 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described herein.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks. It is recognized, however, that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.
Although described in connection with an exemplary computing system environment, including computer 130, the invention is operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
An interface in the context of a software architecture includes a software module, component, code portion, or other sequence of computer-executable instructions. The interface includes, for example, a first module accessing a second module to perform computing tasks on behalf of the first module. The first and second modules include, in one example, application programming interfaces (APIs) such as provided by operating systems, component object model (COM) interfaces (e.g., for peer-to-peer application communication), and extensible markup language metadata interchange format (XMI) interfaces (e.g., for communication between web services).
The interface may be a tightly coupled, synchronous implementation such as in Java 2 Platform Enterprise Edition (J2EE), COM, or distributed COM (DCOM) examples. Alternatively or in addition, the interface may be a loosely coupled, asynchronous implementation such as in a web service (e.g., using the simple object access protocol). In general, the interface includes any combination of the following characteristics: tightly coupled, loosely coupled, synchronous, and asynchronous. Further, the interface may conform to a standard protocol, a proprietary protocol, or any combination of standard and proprietary protocols.
The interfaces described herein may all be part of a single interface or may be implemented as separate interfaces or any combination therein. The interfaces may execute locally or remotely to provide functionality. Further, the interfaces may include additional or less functionality than illustrated or described herein.
In operation, computer 130 executes computer-executable instructions such as those illustrated in the figures to create a compound image file and render a menu to a user using a compound image file.
The following examples further illustrate the invention. The invention includes means for displaying the menu to a user for navigation and selection and means for creating the compound image file. Hardware and software such as a data structure, a user interface, an application program, an application programming interface (API), computer-executable instructions, firmware, and the like (such as illustrated in the figures) constitute means for displaying the menu to a user for navigation and selection and means for creating the compound image file. The invention is not limited to a particular method for creating the compound image files. Various methods are within the scope of the invention.
In the examples described herein, the media content of the digital media file is described in the context of content embodied on a CD or a DVD. It is to be appreciated and understood that the media content may be embodied on any suitable media and that the specific examples described herein are given to further understanding of the inventive principles. For convenience, a digital media file refers to one or more files representing, for example, a single song track or a collection of tracks such as would be found on an audio CD. The media content may include, without limitation, specially encoded media content (e.g., audio, video, or still images) in the form of an encoded media file.
The exemplary media file operations illustrated in the drawings and described herein are merely exemplary. Other variations of these file operations are within the scope of the invention. Alternatively or in addition, other media file operations not described herein yet embodying the invention are also within the scope of the invention.
The order of execution or performance of the methods illustrated and described herein is not essential, unless otherwise specified. That is, elements of the methods may be performed in any order, unless otherwise specified, and that the methods may include more or less elements than those disclosed herein. For example, it is contemplated that executing or performing a particular element before, contemporaneously with, or after another element is within the scope of the invention.
When introducing elements of the present invention or the embodiment(s) thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results attained.
As various changes could be made in the above constructions, products, and methods without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
This application is a continuation-in-part of co-pending U.S. patent application Ser. No. 10/273,411, filed Oct. 17, 2002, entitled “Adaptive Menu System for Media Players,” hereby incorporated by reference, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/418,973, filed Oct. 16, 2002, entitled “COMPRESSED MEDIA FORMAT SPECIFICATION,” now abandoned.
| Number | Date | Country | |
|---|---|---|---|
| 60418973 | Oct 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10273411 | Oct 2002 | US |
| Child | 11168089 | Jun 2005 | US |
