AU2011253986B2 - Method of generating an on-screen menu - Google Patents

Abstract

Abstract A method for generating an on-screen menu comprising menu buttons (BG81,...,BG86') and other menu items, e.g. help text, is characterized in that one or more groups of menu buttons or menu items are defined, wherein a group comprises one or more menu buttons or menu items and has associated a defined area on the screen. A state is assigned to a button, the state being "enabled" or "disabled", wherein only an enabled button or item may be displayed, and wherein within a group not more than one button or item may be enabled. The state of a button can be changed by commands associated with other buttons. WO 2005/069109 4/10 PCT/EP2004/014187 BG81 BG81' English BG8 3' Audio Language BG84 Japanese - BG 4' Subtitle Language Korean BG85 BG85' Dutch ]BG86' BG82 BG82' Fig.8 Fig. 9 Audio Languag~e -- - Subtitle Language Fig. .10

Description

WO 2005/069109 PCT/EP2004/014187 1 Method for generating an on-screen menu Field of the invention 5 This invention relates to a method for generating an on screen menu. Background 10 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. 15 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. 20 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 25 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. 30 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 2 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. 5 Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, 10 but not the exclusion of any other element, integer or step, or group of elements, integers or steps. Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present 15 specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present invention as it existed before the priority date of each claim of this application. 20 Summary of the Invention The invention provides means to generate dynamic menus. 25 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. 30 In a first aspect, the invention provides a method for generating a displayable menu from data of a menu data segment, the menu comprising separately rendered visible and selectable menu items, comprising steps of 3 - determining that at least one group of menu items and at least one further menu item that is outside said group of menu items are defined in said menu data segment, wherein each of the menu items has associated 5 a defined area on the display, and wherein a menu item may belong to not more than one of said groups, and wherein said further menu item has a command associated that is executed upon activating the further menu item; 10 - assigning a state to each menu item of said at least one group of menu items, the state being "enabled" or "disabled", wherein only an enabled menu item may be displayed and may have one of the states unselected, selected or activated, and wherein not more than one 15 menu item within a group may be enabled simultaneously; - receiving the command associated to said further menu item when said further menu item is activated; and - upon receiving said command, modifying the "enabled" 20 or "disabled" state of at least one of said menu items that belong to said group. In a second aspect, the invention provides a removable data storage medium containing audio-visual data and a menu data 25 structure for generating a displayable menu relating to the audio-visual data, the menu comprising visible and selectable menu items, wherein all menu items can be separately rendered, and wherein for the menu data structure 30 - at least one group of menu items and at least one further menu item that is outside said group of menu items are defined in said menu data structure, and each of said menu items having associated a defined area on the display; 4 - a menu item may belong to not more than one of said groups; - a state is assigned to each menu item, the state being "enabled" or "disabled", wherein only an enabled menu 5 item may be displayed and may have one of the states unselected, selected or activated, and wherein not more than one menu item within a group may be enabled simultaneously; and - said further menu item has a command associated that 10 modifies, upon activation of said further menu item, the "enabled" or "disabled" state of at least one of the menu items of said group of menu items. In a third aspect, the invention provides a method for 15 recording audio-visual data and a menu data structure for generating a displayable menu relating to the audio-visual data on a removable data storage medium, the menu comprising visible and selectable menu items, wherein all menu items can be separately rendered, the method 20 comprising steps of - creating, in said menu data structure, data for at least one group of menu items and for at least one further menu item that is outside said group of menu items, each of said menu items having associated a 25 defined area on the display, wherein a menu item may belong to not more than one of said groups, and wherein upon generating a menu from said menu data structure, a state is assigned to each menu item of said at least one group of menu items, the state being 30 "enabled" or "disabled", wherein said "enabled" or "disabled" state is modified upon receiving a command associated to said further menu item when said further menu item is activated, and wherein only an enabled menu item may be displayed and may have one of the 5 states unselected, selected or activated, and wherein not more than one menu item within a group may be enabled simultaneously; and - recording said menu data structure and the audio 5 visual data on said removable data storage medium. 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 10 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. 15 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 20 '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 25 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 30 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.

6 - 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. 5 - 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 10 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. 15 - 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 20 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 25 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. 30 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 7 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. 5 One embodiment provides 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. 10 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 15 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. 20 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 25 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. 30 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 8 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 5 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 10 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. 15 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 20 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. 25 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 30 of the respective programming code, e.g. due to static button positions and static neighborhood relations.

9 In detail, there are three possibilities for button group areas, as described in the following. They are specialized versions of a general case. 5 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 10 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 15 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 20 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 25 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, 30 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 9a 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 5 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. 10 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 15 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. 20 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 25 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 30 decoding. In particular, the invention provides means to generate dynamic menus, wherein buttons can be dynamically removed or added to a menu.

9b 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 5 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 10 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. 15 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 20 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. 25 Further, 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. 30 9c Brief description of the drawings Exemplary embodiments of the invention are described with 5 reference to the accompanying drawings, which show in Fig.1 a menu screen with disabled submenus; Fig.2 a menu screen with enabled first submenu; Fig.3 a menu screen with enabled second submenu; 10 Fig.4 an authoring option for submenu selection; Fig.5 a menu screen with selected submenu item; Fig.6 a button group area according to first possibility; Fig.7 a button group area according to second possibility; Fig.8 a button group area according to third possibility; 15 Fig.9 a screen with menu icon; Fig.10 a screen with menu icon and enabled menu; Fig.1l an initial multi-activation menu screen after first activation of a feature type button; Fig.12 a multi-activation menu screen after second 20 activation of a feature type button; WO 2005/069109 PCTIEP2004/014187 10 Fig.13 a multi-activation menu screen after third activation of a feature type button; Fig.14 a menu screen with conditionally enabled item; Fig.15 initial view of a breadcrumb menu; 5 Fig.16 buttons included in initial view of a breadcrumb menu; Fig.17 and Fig.18 transition from first to second view in breadcrumb menu; Fig.19 and Fig.20 transition from second to third view in 10 breadcrumb menu; and Fig.21, 22 and 23 appearances of selected and unselected, but previously selected, buttons in breadcrumb menu, during transition to submenu. 15 Detailed description of the invention Fig.1 shows the initial view of a menu page on a display screen S, with only an "Audio Language" button VB1 and a 20 "Subtitle Language" button VB2 enabled and visible. The other buttons BG belong to submenus of either of the visible buttons and are invisible, as defined through a data-segment that describes the menu and that is contained in a bitstream on the medium. According to the invention, 25 these buttons BG belong to separate button groups and are initially disabled, and thus invisible. Moreover, also the two visible buttons VBl,VB2 may belong to separate button groups. The data segment can be called interactive composition segment (ICS). In the initial view shown in 30 Fig.1 none of the visible buttons VBl,VB2 is activated. Usually one of the visible buttons is initially selected by default. If in the shown case the user presses e.g. the RIGHT button on the remote, nothing would change because WO 2005/069109 PCT/EP2004/014187 11 there is no button activated yet. Generally, if neighbourhood relations are defined that lead to disabled buttons, the decoder ignores the relations as long as the neighbour buttons are disabled. Pressing e.g. the UP or 5 DOWN button would select either of the visible buttons VB1,VB2. Activating the "Audio Language" button VB1 by selecting the button VB1 and pressing on a remote e.g. an "OK" button would lead to a menu display modification, as shown in Fig.2. 10 In Fig.2 the "Audio Language" button VBl is activated, and the button commands associated with it enable the buttons BGA to the right. Consequently, these buttons BGA are rendered visible, allowing to select and activate one of 15 them, and thus to select an audio language. Fig.3 shows a situation where e.g. starting from Fig.2 the "Audio Language" button VB1 was not activated, but the DOWN button was pressed so that the "Subtitle Language" button 20 VB2 gets selected. Then the "Subtitle Language" button VB2 was activated e.g. by the user pressing an "OK" button on the remote control. The effect is that the four buttons BGS to the right are rendered, presenting subtitle options, and in particular these buttons are rendered in the same 25 positions as the four buttons BGA to the right were rendered for audio options in Fig.2. This corresponds to the third possibility for positioning buttons of button groups, as described above, since buttons that have the same position but belong to different submenus belong to 30 the same button group. The buttons BGS shown in Fig.3 are different from the buttons BGA shown in Fig.2, since they have different functions, namely allow selection of a subtitle language. The buttons BGS represent the "Subtitle" WO 2005/069109 PCT/EP2004/014187 12 range of buttons for each of the button groups, while the buttons BGA in Fig.2 represent the "Audio" range of buttons of the same button groups. In this particular example, not only the position but also the appearance and the languages 5 of the corresponding buttons of the shown submenus are the same. E.g. in Fig.3, only from the selected button VB2 is visible to which submenu the buttons BGS refer. Therefore, when one of the submenu buttons BGS is selected, the corresponding superior button VB2 should look different 10 from an unselected button, though it is neither selected nor activated. Fig.4 shows a menu where a graphical user hint GH, in the form of a small arrow, appears in the visible buttons 15 VBl,VB2, showing that related submenus exist. When the "Audio Language" button VBl is activated or when it is selected and the RIGHT button is pressed on the remote, then its button handler selects an invisible button INB being defined in the neighbourhood information of the 20 "Audio Language" button VB1 as neighbour to the right. The invisible button INB is a so-called auto-action button, since it automatically switches from the selected state to the activated state, so that its button handler is executed. The button handler comprises a command to render 25 the four buttons BGA on the right visible, without any of them being activated, and a command to select the "English" button. The invisible button INB has the same data structure as the other buttons. If the RIGHT button is pressed while the "Audio language"'button is selected, the 30 audio options become visible. In the next step, one of the new buttons on the right can be selected, as shown in Fig.5. There are four different WO 2005/069109 PCT/EP2004/014187 13 button groups BGA, namely 'English', 'Japanese', 'Korean' and 'Dutch'. Further, it is possible that the "Audio language" and the "Subtitle Language" buttons belong to button groups. It is also possible though to combine button 5 groups and single buttons. From the data structure point of view, single buttons may also form a button group with only one element. In the situation depicted in Fig.5, the "Audio Language" button looks selected or activated, and for each of the submenu button groups BGA the buttons representing 10 the options for audio are enabled and visible. They are rendered at the same positions where also the buttons for subtitle options would be rendered, if the "Subtitle Languages" were selected. Therefore the buttons belonging to the same button group are overwriting each other. One of 15 the submenu buttons is selected, and therefore the "Audio Language" button must be deselected, as described later for Fig.23. The selected submenu button can be a default button, e.g. 'English' is a predefined default, or it can be the currently used option, or any other type of default. 20 Fig.6-8 show examples for the three above-mentioned possibilities for defining button group areas. The area of a button group is generally defined through the sum of all on-screen areas of the buttons that belong to that button 25 group. Further, the position of different buttons that belong to the same button group may differ, as long as they are within the area specified for their button group. For practical reasons, i.e. due to the column and row structure of a typical display, the button group area and partial 30 areas will usually be rectangular, though they can in principle have any shape.

WO 2005/069109 PCT/EP2004/014187 14 Fig.6 shows the first possibility for definition of a button group, as described above. A first button group BG61 comprises three buttons B#1,B*4,B#6 with three separate, non-coherent areas. A second button group BG62 also 5 comprises three buttons B#2,B#3,B#5 with three separate, non-coherent areas. According to the definition of button groups, not more than one button per button group BG61,BG62 is enabled at a time, and may be visible. Thus, only one of the buttons B#1,B#4 and B#6, and only one of the buttons 10 B#2,B#3,B#5 may be enabled (and visible) at a time, while the others are rendered transparent. Further, none of the individual button areas of the first button group BG61 may overlap with any individual button area from the other button group BG62. It is possible though to surround, even 15 fully surround, a button group area of a first button group with partial areas belonging to a second button group. In this example, the enabled and visible buttons fully cover their respective button group areas. In another embodiment though it would be possible that areas of buttons that 20 belong to the same group may overlap, e.g. B#2 and B#5. This is because they may not be visible at the same time, and when one of them is rendered visible, all partial areas of the button group area are re-rendered and thus cleared, i.e. rendered transparent. 25 Fig.7 shows the preferred embodiment, where a single area is defined for every button group, and all buttons belonging to that button group are positioned within that area. A button group BG71 has a defined area where all its 30 buttons B#11,B#12 are rendered. Another button group BG72 has another area for its buttons B#21,B#22. Also here, button group areas of different button groups may not overlap. The position of different buttons B#11,B#12 that WO 2005/069109 PCT/EP2004/014187 15 belong to the same button group BG71 may differ, as long as they are within the specified area. Fig.8 shows a special case of the preferred embodiment, 5 where all buttons of each button group have exactly the saine position, thus overwriting each other. Therefore, the area of a button is identical with the button group area in this case. A first button group comprises an enabled, and therefore visible, "Audio Language" button BGS and one or 10 more disabled, invisible buttons BG81'. Though the disabled buttons BG81' are drawn visible in the figure for clarity, they have exactly the same display position as the visible button BG81. 15 Fig.9 shows an example where a menu is represented only through a menu icon MM, while the rest of the screen shows an audio-visual presentation, e.g. a movie. A small icon MM is displayed on the screen, indicating that a menu is available. The icon MM does not disturb the viewer who is 20 watching a movie. When the viewer activates the menu, e.g. through pressing either a dedicated button or the "OK" button on the remote control, further buttons of the menu are revealed, as shown in Fig.10. The user can operate the menu to make selections, e.g. select an audio language or a 25 subtitle language with respective buttons AL,SL. If e.g. the "Audio Language" button AL is selected and activated, an audio language submenu is rendered visible, as shown in Fig.11. It may comprise e.g. the "Audio Language" button ALl, to indicate the current position within the 30 hierarchical menu, and initial language option buttons L1,...,L4 for English, Japanese, Korean and Dutch. The "Audio Language" button ALl has an indication MIl for indicating that further options exist. In this example, the further WO 2005/069109 PCT/EP2004/014187 16 options can be accessed by repeated activation of the "Audio Language" button AL. This is called multi activation. If this button AL is activated a second time, audio language buttons L5,...,L8 for Spanish, French, Greek 5 and Polish appear, and after a third activation there are audio language buttons L9,...,L12 for Danish, Norwegian, Finnish and Swedish. After a fourth activation of the "Audio Language" button AL however the initial menu is displayed again, as shown in Fig.10. The menu can be 10 iconified again with the dedicated menu button. Although the viewer has the impression that only the text within the option buttons changes, it is technically difficult and error-prone to program such a menu with known 15 methods and data structures. In particular, for the verification of the programmed menu data it is necessary to test all possible combinations of buttons, in order to be sure that the menu works correctly. An implementation using button groups according to the invention is advantageous, 20 because the menu needs to be verified with only one button from each button group, and the button group mechanism can be verified separately, only once. Further, it is easy for the menu programmer to rearrange the options, and thus modify the button groups. 25 In the described example, a first button group comprises the buttons for English L1, Spanish L5 and Danish L9. A second button group comprises the buttons for Japanese L2, French L6 and Norwegian 11O. 30 A third button group comprises the buttons for Korean L3, Greek L7 and Finnish L1i. A fourth button group comprises the buttons for Dutch L4, Polish L8 and Swedish L12.

WO 2005/069109 PCTIEP2004/014187 17 Those buttons of the different button groups that are enabled and visible at the same time can be regarded as a logical layer, though from the data structure point of view they are independent from each other. They are only at the 5 same time enabled and visible. But also the "Audio Language" button AL is not a single button, since depending on the current state of the other menu buttons it has different functions. Particularly, the 10 functions differ in which option buttons must be.enabled upon activation of the current "Audio Language" button. E.g. activation of the "Audio Language" button ALl in Fig.11 causes that the option buttons L5,...,L8 shown in Fig.12 are enabled, while activation of the identical 15 looking "Audio Language" button AL2 in Fig.12 causes that the option buttons L9,...,L12 shown in Fig.13 are enabled. Therefore, a fifth button group may comprise the different "Audio Language" buttons AL1,AL2,AL3 that belong to the logical layers. Alternatively, it is possible that the 20 "Audio Language" buttons ALi,AL2,AL3 are identical, and the button command takes into account which button from the button groups are currently enabled, and the command enables the next element from each button group. 25 Fig.14 shows an example for conditional enabling. Buttons can be enabled or disabled depending on user settings or player settings. E.g. there can be three versions of a movie on a disc: a 'children's cut', a 'theatrical cut' and a 'directors cut'. When the disc is inserted into the 30 player, the initial menu may show a non-selectable button NSB with e.g. the title of the movie, and three selectable buttons SB1,SB2,SB3 for the reproduction options. A user can however set a parental level, and thus allows the WO 2005/069109 PCTIEP2004/014187 18 'children's cut' and the 'theatrical cut', but rejects the 'directors cut'. The screen may then show only two selectable buttons SBl,SB2 for the two allowed options. For the forbidden option however there is no visible button 5 available, since it is rendered transparent. According to the invention, this menu behaviour can be technically achieved by using enable/disable commands and button groups. One or more of the option buttons SBl,SB2, SB3 may belong to separate button groups, and according to 10 specified settings for each button group a defined member is enabled and rendered visibly. In the current example, the "Director's cut" button belongs to a button group SB3 according to the invention, with an associated button group area, and the parental level setting of the player causes 15 the initial button handler to disable the respective button, i.e. to render the button group area transparent. Also other setting types can be utilized, e.g. reproduction options depending on player type, audio equipment type etc. 20 As a further embodiment of the invention, so-called breadcrumb menus can easily be constructed. Breadcrumb menus are generally menus where the previously pressed button that belongs to another hierarchy remains visible, so that the user can see which button was selected, and to 25 what the currently displayed option buttons refer. This is particularly useful for hierarchical menus. In the data structure utilized by the invention, hierarchy is given implicitly by neighbourhood relations. 30 Fig.15 shows a menu screen with three buttons AMB,ALMB,SLMB that belong to the same hierarchical level. One of the menu buttons AMB is for multi-angle selection. It is selected, and three angle select option buttons ASB are displayed on WO 2005/069109 PCT/EP2004/014187 19 the right. Each of these visible option buttons ASB belongs to a separate button group and was rendered visible because the "Angle" menu button AMB is selected. The bther members of these button groups are disabled and thus invisible. 5 Fig.16 shows that the menu comprises also other, invisible buttons IB1,...,IB4. These are used to define what should happen at transitions between the higher level menu buttons AMB,ALMB,SLMB. 10 When the "Angle" menu button AMB is selected, like in Fig.15, and the user wants to select the "Audio Language" menu button ALMB, he presses the DOWN button on his remote, because the "Audio Language" menu button ALMB is displayed 15 below the "Angle" menu button AMB. A dynamic menu, as supported by the invention, may perform the following: First, the button that is defined as DOWN neighbour of the "Angle" button is selected, which is in this example an invisible button IB1. This is the state shown in Fig.17. 20 Although invisible buttons are not represented on the display, they may have a display area or position assigned due to data consistency, e.g. if the same data structure is used for visible and invisible buttons. For illustrative purpose however the figures show also invisible buttons, at 25 their logical positions. Then, after the invisible button IB1 was selected, it is automatically activated (autoaction flag==true in Tab.1), and its button handler executes the following commands: 30 first it disables the menu option buttons ASB relating to the "Angle" menu button AMB, thus making them invisible, second it enables the option buttons ALSB that belong to the menu button the user wants to select, which is the WO 2005/069109 PCT/EP2004/014187 20 "Audio Language" menu button ALMB, and finally it selects the "Audio Language" menu button ALMB, thereby deselecting itself. This is shown in Fig.18. Fig.19 and Fig.20 show the corresponding transition from the "Audio Language" menu 5 button ALMB to the "Subtitle Language" menu button SLMB using another invisible button IB3, wherein the audio language submenu buttons ALSB are replaced by subtitle language submenu buttons SLSB. Further, there are invisible buttons IB2,IB4 for the opposite transitions. 10 As a result, the menu option buttons ASB,ALSB,SLSB always match the selected menu button AMB,ALMB,SLMB without the selected menu button being activated. The user may not perceive the intermediate states, the invisible buttons or 15 the short time the described transitions take, usually in the range of milliseconds. According to the invention, the menu option buttons ASB,ALSBSLSB are implemented as members of button groups. Buttons on the same position that belong to different submenus form a button group. This 20 allows an easy menu data structure and therefore simplified programming and verification. In particular, button groups may implicitly handle the disabling of obsolete submenu option buttons and the enabling of the correct submenu option buttons that belong to the newly selected menu 25 button. Since not more than one button from a button group may be enabled, and therefore visible, it is sufficient to select for each button group the new button to be enabled. This implicitly disables the previously enabled button of the group, and the pixels that belong to the button group 30 area are overwritten according to the bitmap representation of the new button. The rest of the display may remain unchanged. Therefore there is no need for the decoder to analyse which buttons were visible before, which button WO 2005/069109 PCTEP2004/014187 21 must be replaced, which area it occupied and if any button areas overlap. Another embodiment of the invention, being an exemplary 5 implementation of the above-described breadcrub effect, is shown in Fig.21-23. When a hierarchical menu button is selected, e.g. the "Angle" menu button AMB1 in Fig.21, it changes from the normal state to the selected state, and its representation looks different, e.g. highlighted. This 10 is caused by different bitmap representations corresponding to the states of a button. When the "Angle" menu button AMB1 is activated, it remains only a very short time in the activated state. Its appearance during this time may differ from the selected state, but the user will hardly see it. 15 When the button is activated, its button handler may select an invisible button INB that is used to render the submenu buttons ASB visible, as described above. This situation is shown in Fig.22. At this time, when the invisible button INB is in the selected state, the "Angle" menu button is 20 not selected, since only one button of the menu can be selected at a time - otherwise the decoder could not detect to which button a user command refers. The "Angle" menu button is in the normal state instead. But in order to achieve the breadcrumb effect, i.e. indicate the menu 25 button to which the current submenu buttons ASB refer, it would be desirable to give the menu button AMB1 another appearance. This can be achieved with the button groups according to the invention, e.g. by generating an "Angle" button group. 30 The default "Angle" button AMBI, like any menu button, has the three states normal, selected and activated. Another button, e.g. an "Angle-Select" button AMB2 belonging to the WO 2005/069109 PCT/EP2004/014187 22 same button group looks similar to the default "Angle" button AMBI and has the same display position, but differs slightly. E.g. its normal state bitmap may be the same as the default buttons selected or activated state bitmap. As 5 described before, the invisible button INB is automatically activated upon selection. It may e.g. render the submenu buttons ASB visible, then enable the "AngleSelect" button AMB2 (in the normal state), thus implicitly disabling the previously visible "Angle" button AMBI, and finally select 10 one of the submenu buttons ASBi, thus deselecting itself. This is shown in Fig.23. The effect is that the user may recognize the button AMB2 as the same button AMBi like before, and that the button AMB2 looks selected or activated, but actually it is deselected. This allows 15 giving a button virtually more different representations than states, e.g. colours, shapes, text etc., by replacing it with other buttons. The inventive button groups allow an easy handling of these buttons, and provide a simple mechanism to determine the correct values for pixels within 20 the button group area. The group structure provides information for the menu decoder, the information defining which on-screen area needs update. Because within a button group not more than 25 one button is active at a time, the activation of another button within a group implies the deactivation of the first button of the same group. This is an advantage for authoring, since it makes it easier to author menus. 30 Especially in the case of prerecorded media, e.g. prerecorded Blu-ray discs, a verification process is performed on any title before it is released to check if the data-structure meets the specification. The invention WO 2005/069109 PCT/EP2004/014187 23 allows for easy verification while providing enhanced features to the content author when creating dynamic menus. In the following, the syntax of a data segment shown in 5 Tab.1 is described, which may be contained in a bitstream and describes the initial menu screen, being an exemplary implementation. It describes the case that the button group area is defined according to the second possibility described above. 10 Tab.1: Exemplary Syntax of data segment describing a menu Syntax No. Mnemonics of bits 1 interactive composition segment { 2 segment type 8 bslbf 3 segment length 16 uimsbf 4 composition number 16 uimsbf 5 composition state 2 bslbf 6 reserved 6 bslbf 7 command update flag 1 bslbf 8 reserved 7 bslbf 9 composition time out pts 33 uimsbf 10 reserved 7 bslbf 11 selection time out pts 33 uimsbf 12 reserved 7 bslbf 13 UO mask table 64 bslbf 14 animation frame rate code 8 uimsbf 15 default selected button number 8 uimsbf 16 default activated button number 8 uimsbf 17 while (processed length < segment length) { 18 button group { 19 button-group horizontalposition 16 uimsbf 20 button group vertical position 16 uimsbf 21 button group horizontal size 16 uimsbf 22 button group vertical size 16 uimsbf 23 default enabled button number 8 uimsbf 24 num buttons 8 uimsbf 25 for (i=0; i<num buttons;i++) { ... _. 26 button number 8 uimsbf 27 numerically selectable flag 1 bslbf 28 reserved 7 bslbf 29 auto action flag 1 bstbf WO 2005/069109 PCT/EP2004/014187 24 30 reserved 7 bslbf 31 button horizontal position 16 uimsbf 32 button vertical position 16 uimsbf 33 neighbor info( { 34 upper button number 8 uimsbf 35 lower button number 8 uimsbf 36 left button number 8 uimsbf 37 right button number 8 uimsbf 38 ) 39 normal state infoO { 40 start objected normal 16 bslbf 41 end object id normal 16 bslbf 42 repeat normal flag 1 bslbf 43 reserved 7 bslbf 44}- 45 selected state info) { 46 start object id selected 16 bslbf 47 end object id selected 16 bslbf 48 repeat selected flag 1 bslbf 49 reserved 7 bslbf 50 51 actioned state info(){ 52 start object id activated 16 bslbf 53 end object id activated 16 bslbf 54 } 55 num of button commands 8 uimsbf 56 for( cmd id = 0; cmdid < numof buttoncommands; cmd id++) { 57 button commandlemd id 96 bslbf 58 59} 60} 61 }_____ Tab.1: Exemplary Syntax of data segment describing a menu 5 The notation used in Tab.1 uses while-loops and for-loops. Loops however are only a means to generalize the notation, since the actual bitstream will include data for the single passes or instances of the loop.

WO 2005/069109 PCT/EP2004/014187 25 Between 1.17 and 1.61 is a loop over the complete data segment of length segmentlength. A data segment may include any number of button groups. 5 In 1.18 is defined that the following lines, until 1.60, refer to the definition of a button group. The identifier of the group is the value given in round brackets. In 1.19-22 the respective position on the screen is defined for the current button group, also referred to as button 10 group area in this application. It is defined by its horizontal and vertical size and the position of its reference point. In this case the button group area is only one rectangular, but as described before it may be other areas or a plurality of rectangulars. In that case 1.19-22 15 would be repeated once for each partial area. The parameter in 1.23 defines which of the buttons of the current group is enabled by default. The decoder uses this value to initially load a register that relates to the 20 current group and holds a variable. This variable specifies the number of the currently enabled button, and can be modified during operation of the menu. It may also be assigned a value that corresponds to none of the buttons, so that all buttons of the group are disabled. This 25 mechanism ensures that not more than one button within a group is enabled. Two other parameters that are used to initialize variables that may be modified during menu operation are defaultselectedbutton number (1.15) and defaultactivatedbuttonnumber (1.16). 30 In 1.24 the number of buttons in the current group is defined.

WO 2005/069109 PCT/EP2004/014187 26 The loop beginning in 1.25 covers all buttons of the group and defines for each button a reference number (1.26), if it is numerically selectable (1.27), if it automatically executes its commands when it is selected (1.29), its s position within the button group area (1.31-32), its neighbour buttons (1.33-38), and address ranges indicating where the bitmap representations corresponding to the different buttons states can be read. For every button, one or more commands can.be defined. The number of commands of 10 the current button is specified in 1.55 by the parameter numofbutton commands. The actual commands of the button handler are defined in 1.56-58. The invention is usable for all kinds of presentation 15 devices that have access to a display and contain a decoder for processing menu data structures read from e.g. DVDs, Blu-ray discs or other media. Further, the invention is usable for generating such data structures. 20 According to the invention, a decoder for decoding a data stream, the data stream comprising menu data for a visually displayable menu, and the menu comprising separately rendered menu items including selectable menu buttons, includes (i) means for defining at least one group of menu 25 items, the group comprising one or more menu items, wherein a menu item may not belong to more than one group, (ii) means for associating to said group a defined area on the display, and (iii) means for assigning a state to each of said menu items belonging to a group, the state being 30 "enabled" or "disabled", wherein only an enabled menu item may be displayed, and wherein not more than one menu item within a group may be enabled simultaneously.

WO 2005/069109 PCT/EP2004/014187 27 Further, a displayed menu item that belongs to a group is displayed within the area associated with said group, wherein the areas of different groups may not overlap and no display pixel may belong to more than one group. 5 Further, a menu item may have an associated command, which -is executed upon activation of the menu item and comprises enabling or disabling of another menu item.

Claims (5)

1. A method for generating a displayable menu from data of a menu data segment, the menu comprising separately rendered visible and selectable menu items, comprising 5 steps of - determining that at least one group of menu items and at least one further menu item that is outside said group of menu items are defined in said menu data segment, wherein each of the menu items has associated 10 a defined area on the display, and wherein a menu item may belong to not more than one of said groups, and wherein said further menu item has a command associated that is executed upon activating the further menu item; 15 - assigning a state to each menu item of said at least one group of menu items, the state being "enabled" or "disabled", wherein only an enabled menu item may be displayed and may have one of the states unselected, selected or activated, and wherein not more than one 20 menu item within a group may be enabled simultaneously; - receiving the command associated to said further menu item when said further menu item is activated; and - upon receiving said command, modifying the "enabled" 25 or "disabled" state of at least one of said menu items that belong to said group.

2. Removable data storage medium containing audio-visual data and a menu data structure for generating a 30 displayable menu relating to the audio-visual data, the menu comprising visible and selectable menu items, wherein all menu items can be separately rendered, and wherein for the menu data structure 29 - at least one group of menu items and at least one further menu item that is outside said group of menu items are defined in said menu data structure, and each of said menu items having associated a defined 5 area on the display; - a menu item may belong to not more than one of said groups; - a state is assigned to each menu item, the state being "enabled" or "disabled", wherein only an enabled menu 10 item may be displayed and may have one of the states unselected, selected or activated, and wherein not more than one menu item within a group may be enabled simultaneously; and - said further menu item has a command associated that 15 modifies, upon activation of said further menu item, the "enabled" or "disabled" state of at least one of the menu items of said group of menu items.

3. A method for recording audio-visual data and a menu data 20 structure for generating a displayable menu relating to the audio-visual data on a removable data storage medium, the menu comprising visible and selectable menu items, wherein all menu items can be separately rendered, the method comprising steps of 25 - creating, in said menu data structure, data for at least one group of menu items and for at least one further menu item that is outside said group of menu items, each of said menu items having associated a defined area on the display, wherein a menu item may 30 belong to not more than one of said groups, and wherein upon generating a menu from said menu data structure, a state is assigned to each menu item of said at least one group of menu items, the state being "enabled" or "disabled", wherein said "enabled" or 30 "disabled" state is modified upon receiving a command associated to said further menu item when said further menu item is activated, and wherein only an enabled menu item may be displayed and may have one of the 5 states unselected, selected or activated, and wherein not more than one menu item within a group may be enabled simultaneously; and - recording said menu data structure and the audio visual data on said removable data storage medium. 10

4. Removable data storage medium containing audio-visual data and a menu data structure for generating a displayable menu relating to the audio-visual data substantially as hereinbefore described with reference 15 to the accompanying drawings.

5. A method for recording audio-visual data and a menu data structure for generating a displayable menu relating to the audio-visual data on a removable data storage medium 20 substantially as hereinbefore described with reference to the accompanying drawings.