The patent's assignee for patent number 8745530 is
News editors obtained the following quote from the background information supplied by the inventors: "Audio-visual contents of data storage media, e.g. Digital Versatile Discs (DVD) for video applications, usually contain menu data for various applications, e.g. to enable a user to select specific content of the medium. The menu data are used for rendering the menu on a display screen. Often so-called multi-page menus are used, where each possible state of the menu is represented by a full-screen image that is overlaid as a separate layer to the video picture. The menu layer is usually transparent, except for the displayed menu items.
"In state-of-the-art menus the menu items basically consist of a number of buttons and non-button objects. Each button is assigned an on-screen position by the content author and can be navigated and activated by the user, e.g. via a remote control. Each button is associated a state, which can either be the `normal` (or `unselected`) state, the `selected` state or the `activated` state. Each button can provide a different visual representation in each state in order to give the user feedback.
"However, these kinds of menus are rather static as there is no way to dynamically add or remove buttons from the screen, without re-rendering the whole screen. For content authors such more sophisticated menu features would be desirable, for example for the design of sub-menus. In such a case, additional buttons dynamically appear and disappear on the screen through user interaction.
"The invention provides means to generate such dynamic menus."
As a supplement to the background information on this patent, VerticalNews correspondents also obtained the inventors' summary information for this patent: "The present invention is based on the assumption that the different menu items and buttons of an on-screen menu are rendered separately, not pagewise, on top of a static or dynamic background that may remain visible. 'Rendering' means generating values for display pixels.
"According to the invention, each button is assigned an additional state, which can either be the `enabled` or the `disabled` state. As a general rule, this state defines the rendering behaviour of the button. Buttons that are in the `enabled` state are typically displayed on the screen, while buttons that are in the `disabled` state are not rendered and therefore not displayed. Enabled buttons may also be transparent though.
"The user can navigate only buttons that are in the `enabled` state, and their well known `normal`, `selected` or `activated` state is only valid within the `enabled` state. The user cannot navigate buttons that are in the `disabled` state. Any attempt to do that is ignored by the decoder according to the invention.
"Each button within the menu is assigned an on-screen area and a unique identifier. Usually the on-screen area of buttons will be rectangular, or a combination of rectangular partial areas.
"According to the current invention, buttons are organized in groups, and all buttons obey to certain rules, which are described in the following. The number of buttons belonging to one button group can be one or more. There are no empty button groups. A button cannot belong to more than one button group. The on-screen area of any button belonging to a first button group does not overlap with the on-screen area of any other button that is not belonging to the same button group. Each button within a button group must be in one of the two states: `enabled` or `disabled`. Each button is assigned an initial state, which is either the `enabled` or the `disabled` state. Not more than one button within a button group can be in the `enabled` state at a time, i.e. rendered on the screen. Note that the `enabled` state does not imply user-visibility; e.g. an enabled button is not visible to the user if it is represented only through transparent pixels. For each button within a button group neighbourhood information for button navigation can be defined, saying e.g. which other button to select when the user presses the LEFT, RIGHT, UP or DOWN button. This neighbourhood information is only valid when the button is in the `enabled` state. The user cannot navigate to disabled buttons. The on-screen areas of a first button of a first button group and a second button of the same group, i.e. their visible representations, may overlap. They will not be visible simultaneously since they belong to the same button group, and only one of them can be in the `enabled` state at a time.
"Further, a new command is defined, based on the invention. This command can e.g. be associated with a button, and it is used to dynamically switch between the `enabled` and the `disabled` state of another button. In state-of-the-art menus, activating a button already may encompass the execution of one or more commands. The proposed command is activated in the same way and is therefore compatible with the state-of-the-art framework. Other effects of activating a button are commonly that the button changes its appearance, colour etc.
"One aspect of the invention is the definition of a command for enabling or disabling buttons. The information about which button to enable or disable is provided through the button identifier as a parameter of the command.
"For each button there can be defined one or more button commands that are executed upon activation of the button. The command or set of commands associated with a button is also referred to as a button handler. The execution of button commands is only possible when the button is in the `enabled` state. There may be `empty` buttons however that have no associated button command. The disabling of a button may clear the button visibility by substituting it with transparent pixels.
"The inventive button command does usually not change the `enabled` or `disabled` state of its own button. This means that if an enabled button is activated, the corresponding button command that is executed upon activation may switch the `enabled`/`disabled` state of other buttons, but it may not switch its own button to the `disabled` state, except when its button handler has already scheduled the selection of another button. There may however other commands be executed that comprise e.g. disabling the whole menu. Enabling one button of a group implicitly disables all other buttons within that group.
"For each button group a display area is defined where its buttons may be rendered. This area is in the following called a button group area. It is usually rectangular, but can in principle have other shapes. The visible button may have any shape as long as it is within its respective button group area. E.g. it is possible to render a circular button within a rectangular area. The screen pixels that belong to a button group area, but not to an enabled button within said button group area, are rendered transparent.
"For button group areas according to the invention it is characteristic that no possible button position within a button group may overlap with any possible button position of another button group, so that the button group areas of different button groups may not overlap at all.
"This means that the screen can be considered as a number of non-overlapping button group areas. When the state of any of the buttons of a button group changes, the decoder according to the invention reads the position of the respective button group area from a storage medium, usually an internal memory, and then re-renders the area. For each group only the enabled button is rendered, wherein the corresponding button group area may comprise any number of transparent pixels.
"Advantageously, re-rendering of a button group area never modifies pixels belonging to any other button group area, since different button group areas may not overlap. This allows easier decoders. Further, it allows easier programming of menus, and particularly easier verification of the respective programming code, e.g. due to static button positions and static neighborhood relations.
"In detail, there are three possibilities for button group areas, as described in the following. They are specialized versions of a general case.
"The first possibility is the general case as described above, wherein a button group area may comprise several non-overlapping partial areas, and in each button group area a button belonging to the respective button group may be rendered visible. Therefore a button that belongs to a button group is usually associated with one partial area of its button group area, and then not more than one of the partial areas of a button group may contain an enabled button. In principle it is possible though that an enabled button is present in more than one of the partial areas of its button group, so that a single button may consist of several equivalent parts. When the state of any of the buttons of a button group changes, the decoder according to the invention reads the positions of the partial areas of the respective button group from a storage medium and renders all partial areas new. Particularly, it renders not more than one visible button, namely the enabled button.
"The second possibility is that a button group area is a contiguous area, e.g. a rectangular area. This means that a cohesive area is defined for each button group, which area comprises all possible positions of buttons belonging to that button group. As mentioned before, the areas that belong to different button groups may not overlap, and the visible button needs not necessarily fill the allowed area, i.e. the button needs not have the size and shape of the button group area, but it must be fully within the area corresponding to its group. Therefore, buttons belonging to different groups may not overlap. Further, it is easy to fully delete a first button belonging to a first button group when displaying a second button belonging to the same button group, because in this case only the button group area belonging to the respective button group needs to be re-rendered, which is a single contiguous area; it is not necessary to re-render other parts of the screen. Thus, no remains of the previously shown button are visible. All buttons within a button group use the same on-screen area. This is the preferred possibility.
"The third possibility is that all buttons of a button group have identical areas, i.e. button size and position on the screen. This is the easiest case, with respect to decoder implementation, menu programming and verification, because rendering a button that belongs to a certain button group necessarily deletes another button of the same button group that was previously visible on the same position. Though it provides a less flexible menu than the other two possibilities.
"In principle a button group can also contain non-button objects, i.e. menu items that are visible but not selectable. A non-button object that belongs to a button group has a state assigned, the state being `enabled` or `disabled`, and can be rendered visible only if it is enabled. Enabling and disabling is done through button handlers associated with menu buttons.
"The invention provides more sophisticated menu features, as e.g. demanded by content authors, which features allow easy decoding. In particular, the invention provides means to generate dynamic menus, wherein buttons can be dynamically removed or added to a menu.
"With the invention, a content author is able to easily define hierarchical menus and sub-menus being represented by a flat data structure. Particularly the programming and verification of menus is easier than with known methods. An advantage of the invention is that the graphics decoder needs not consider the whole menu for any menu operation, but it may simply handle isolated button groups instead. The data that describe the initial menu structure are read from a storage medium, usually a removable storage medium, e.g. optical disc, and are then stored on a temporary storage medium, e.g. memory, which is connected to the decoder. When the menu is operated, the variables within the temporary storage hold the current state.
"When a button is invisible, this can either mean that it is disabled and can therefore not be selected or activated, or it is enabled and marked invisible, e.g. has a special flag or only transparent pixels. In the latter case it can be selected, and usually will be automatically activated upon selection, so that associated commands are executed and a visible button is selected. It is also possible to concatenate invisible buttons, as long as the last button command selects a visible button.
"claim 1 discloses a method for generating a menu using such button groups. An apparatus that utilizes the inventive method is disclosed in claim 2. A storage medium holding a respective data structure is disclosed in claim 3. A method for recording a respective data structure on a storage medium is disclosed in claim 4.
"Further objects, features and advantages of the invention will become apparent from a consideration of the following description and the appended claims when taken in connection with the accompanying drawings."
For additional information on this patent, see: Hoerentrup, Jobst; Gandolph, Dirk; Herpel, Carsten; Ostermann, Ralf; Peters, Hartmut. Method for Generating an On-Screen Menu. U.S. Patent Number 8745530, filed
Keywords for this news article include:
Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC
Most Popular Stories
- Shia LaBeouf Plea Deal, Alcoholism Treatment
- Stop-Start Engines Save Gas, Reduce Emissions
- Ohio State Band Chief Fired After Probe
- Hispanic Leader Goes the Extra Mile
- Ukraine Says Russians Firing Across the Border
- Ford Q2 Net Profit up 6 Percent
- Jennifer Lopez, Pitbull to Perform at Fashion Rocks
- Ricky Martin Joins 'The Voice ... Mexico'
- U.S. Weighs Refugee Status for Immigrant Kids
- Morgan Stanley Ponies Up $275 Million to Settle SEC Charges