EP1658689A1 - Radio mit anzeige für textinformationen, die auf weitere textinformationsobjekte verweisen - Google Patents

Radio mit anzeige für textinformationen, die auf weitere textinformationsobjekte verweisen

Info

Publication number
EP1658689A1
EP1658689A1 EP04764470A EP04764470A EP1658689A1 EP 1658689 A1 EP1658689 A1 EP 1658689A1 EP 04764470 A EP04764470 A EP 04764470A EP 04764470 A EP04764470 A EP 04764470A EP 1658689 A1 EP1658689 A1 EP 1658689A1
Authority
EP
European Patent Office
Prior art keywords
text information
user
information object
displayed
objects
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP04764470A
Other languages
English (en)
French (fr)
Other versions
EP1658689B1 (de
Inventor
Alexander Zink
Markus Prosch
Olaf Korte
Michael REICHENBÄCHER
Gerd Kilian
Thomas Jaumann
Thomas FRÜHWALD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority to PL07015293T priority Critical patent/PL1845643T3/pl
Priority to EP07015293A priority patent/EP1845643B1/de
Priority to PL04764470T priority patent/PL1658689T3/pl
Priority to PL06009464T priority patent/PL1689104T3/pl
Priority to EP06009464A priority patent/EP1689104B9/de
Publication of EP1658689A1 publication Critical patent/EP1658689A1/de
Application granted granted Critical
Publication of EP1658689B1 publication Critical patent/EP1658689B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/40—Arrangements for broadcast specially adapted for accumulation-type receivers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/25—Arrangements for updating broadcast information or broadcast-related information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/27—Arrangements for recording or accumulating broadcast information or broadcast-related information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/46—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for recognising users' preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/16—Arrangements for broadcast or for distribution of identical information repeatedly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H2201/00—Aspects of broadcast communication
    • H04H2201/10—Aspects of broadcast communication characterised by the type of broadcast system
    • H04H2201/20—Aspects of broadcast communication characterised by the type of broadcast system digital audio broadcasting [DAB]

Definitions

  • the present invention relates to radios, and more particularly to those having an indicator for displaying textual information.
  • DAB Digital Audio Broadcasting
  • Text-based news services are already exploiting this possibility of digital broadcasting in order to broadcast text messages to end devices.
  • broadcasters transmit text information that can be displayed on the display of the user's radio receiver, such as the name of the broadcast program or current news or the like.
  • the program manager decided on the type and order of the information.
  • Previous text-based messaging services have limited the ability of a user to influence the selection of text messages displayed on their display, such as by changing the program. It is therefore the object of the present invention to provide a text information service scheme that provides a user with a more effective means of accessing desired textual information over the radio by means of a radio.
  • a user of a broadcast receiver obtains textual information much more quickly if a reference to another text information object in the broadcast signal is included in a text information object included in the broadcast signal that is being displayed on the broadcasting receiver's display is, and it is the be ⁇ user ermRglicht to get through simple operation of loading user-selection means that the text to be displayed information is changed from the text information of the current text information object to text information of the text information object is referenced by the current text information object.
  • the extra effort is very limited here, since today's
  • Broadcast receivers usually a "blank" button, which only in special situations of use of the radio receiver has an assigned function and is therefore occupied, exists and insofar can be used as a user-selection device.
  • the text information objects in the broadcasting Radio signal sequentially among other information in the broadcast signal, such as the audio information o- but other information, broadcast from a radio station, each text information object has an object ID. If a text information object references another text information object, its object IDs will be different. Introducing the object IDs makes it possible to divide the content of the text information objects in the broadcast signal into groups and to transmit and update them cyclically repeatedly for receivers.
  • a broadcast receiver can thus, without having to analyze the content of the text information objects, ie the text information, recognize whether a particular text information object just received, although different from the currently displayed one, relates to the same object as a previously received one and thus represents an update, or whether the currently received text information object content concerns a completely different subject.
  • An update can be easily made by comparing the object ID of a text information object directly or not immediately following the currently displayed text information object in the broadcast signal with the object ID of the currently displayed one. Depending on whether the comparison results in the identity of the object IDs, the update is made or not.
  • the update for the radio receivers can be rendered less expensive by the fact that the text information objects next to the object ID still have a revision index, which provides information about which version of the text information associated with this object ID, this Text- information object concerns. Consequently, a radio receiver is not forced blindly to update whenever a text information object whose object ID matches the object ID of the currently displayed text information object is broadcast again in the broadcast signal. Rather, the update is still made dependent on whether the revision index has changed. Image construction and other rendering mechanisms are therefore omitted if the new text information object with the same object ID can not differ in content from that already displayed, since it concerns the same version of the text information for this object ID. The additional expenditure due to the burden on the transmission channel by the revision index in each text information object is comparatively low.
  • the update can also be made more user-friendly by distinguishing between the individual text information objects.
  • menu objects, list objects, and plain text objects exist. Each text information object is assigned to one of these types by an object descriptor or object type ID.
  • object descriptor or object type ID In the event that it is menu or list objects Han delt, the radio receiver performs the update UNMIT ⁇ telbar, ie without user interaction by, while otherwise the update is made dependent on whether the user his consent or give his consent to the update so that it will not be abruptly interrupted due to the possibility of a minor update when reading a coherent longer text.
  • the display displays a section of the text information of this new text information object that is at least partially associated with overlap a section that the ad showed before updating from the old text information object.
  • this has the advantage that the user does not have to re-orientate himself in the list or the menu after the update has taken place, and that nevertheless he still receives the update when scrolling further.
  • the radio receiver or radio has a cache memory for temporarily storing text information objects already received, it is possible for it to change the text information to be displayed from text information of the current text information object to text information of the text information object having another object ID
  • the current text information object refers to first look in the cache memory to see if a text information object with that object ID is not already in the cache. The user thus gets faster to the new text information of the new
  • Text information object and does not have to wait for the duration of time before a text information object with the desired object ID referenced by the current text information object is re-broadcast in the broadcast signal.
  • a cache hit identifier may be provided which first caches for text information objects for all object IDs associated with menu items of the menu item, and then provides for modifying the textual information to be displayed in that the menu options for which text information objects are present in the cache memory are visibly distinguishable to the user from those for which text information objects are not yet present in the cache memory. This speeds up for a user zapping through the menus, ie the nodes of the object tree, according to which the text information objects are arranged ⁇ .
  • a broadcast receiver supports a favorite functionality.
  • one or more object IDs of text information objects are stored in a favorites memory, which relate to objects which the user repeats, for example, every morning on the way to work, and which he or she can retrieve by operating a favorite query device.
  • a text information object includes a static flag.
  • the add-listen functionality of the broadcast receiver is activated only if the static flag is set, otherwise not, thereby avoiding pointless addition of randomly assigned object IDs.
  • FIG. 1 shows an overview block diagram with transmitter and receiver to illustrate a text information broadcast service according to an embodiment of the present invention
  • Fig. 2 is an exemplary tree structure in which the text information objects of the service of Fig. 1 are arranged;
  • FIG. 3 is a schematic diagram illustrating the structure of the text information objects after the service of FIG. 1 according to an embodiment of the present invention
  • Figures 4a-e are schematic drawings for illustrating the construction of exemplary text information objects or parts thereof by NML and UTF-8 codes;
  • Fig. 5 is a schematic drawing illustrating the serial and cyclic transmission of the text information objects in the broadcast signal of Fig. 1;
  • FIG. 6a-d show exemplary screen displays on the display of the broadcast receiver of Figure 1;
  • FIG. 7 is a flowchart of a display update process according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of a cache update process according to an embodiment of the present invention.
  • FIG. 9 is a schematic diagram of an exemplary tree structure of text information objects illustrating the cache displacement strategy in accordance with one embodiment of the present invention.
  • FIG. 10 is a flowchart of a scrolling process according to an embodiment of the present invention.
  • FIG. 11 is a flowchart of a menu selection process according to an embodiment of the present invention.
  • FIG. 13 is a flowchart of a one-hierarchy level back process according to an embodiment of the present invention.
  • FIG. 14 is a flowchart of a favorite addition process according to an embodiment of the present invention.
  • the present invention will be described below with reference to the figures in the light of a text information broadcasting service as shown in FIG. 1 in construction.
  • radios according to the present invention could also be used in other text information broadcasting systems.
  • the same reference numerals have been used for them, a repeated description of the elements being avoided.
  • the broadcast transmitter 10 is a stationary central broadcasting station which is connected via an antenna 14, e.g. a broadcast mast, broadcast signals 16 to a plurality of radio receivers, such as the radio receiver 12 emits.
  • the broadcast signal 16 includes, in addition to audio information that may relate to different broadcast programs, text information intended for the radio receivers or terminals 12 and their users in the context of the text message broadcast service.
  • the broadcast signal 16 corresponds to the DAB standard, for example.
  • the radio transmitter 10 comprises a memory 18 and an integration device 20, among other components which are intended for the audio transmission or for the transmission of the audio information and are not shown here for reasons of clarity, the memory 18 contains a list 22 of text information objects. As will be described in more detail later, each includes Text information object at least one object identification number or object ID and the actual text content, ie the text information. In addition, text information objects also contain further information, depending on their type, as will also be described in more detail below.
  • the text information objects in list 22 are maintained and updated by a service operator. He makes the selection of topics that affect the objects, the structure in which the objects are ordered, and the length of time in which they are repeatedly broadcast cyclically.
  • the embedding means 20 is connected to the memory 18 for reading out the text information objects from the memory 18 and incorporating them into the broadcast signal to broadcast the same via the antenna 14 as the broadcast signal 16.
  • the readout or transmission by the binding device 20 takes place cyclically for each text information object, so that overall all text information objects are transmitted cyclically one after the other in the broadcast signal 16, with different cycle repetition times, as described in more detail later with reference to FIG becomes.
  • a radio receiver 12 comprises a receiving device 24, a control device 26, a loudspeaker 28, a display or a display 30, a memory 32, a first control panel 34 and a second control panel 36.
  • the receiving device 24 is connected to a data input to an antenna 38 to receive the broadcast signal 16 via the same 38.
  • the receiving device 24 is designed to be able to extract the audio signal from the broadcast signal 16. Extract information and the text information and forward via its data output to the controller 26.
  • the controller 26, such as e.g. a processor or the like, first passes the audio information to the speaker 28.
  • the forwarding of selected audio signals can either take place via an internal line to an integrated loudspeaker 28, as shown in FIG. 1 by solid lines, or via a loudspeaker connection or by outputting suitable audio signals to an external loudspeaker 40 which is external to the loudspeaker
  • Radio receiver 12 is arranged, as shown by dotted lines in Figure 1.
  • the user of the radio receiver 12 can change from one broadcast program to the other via the control panel 36, which comprises, for example, only one toggle switch with two tilt positions or tilt positions.
  • the control panel 36 is for this purpose connected to the control device 26, which in turn is designed to change the current program and thus the audio signals to the loudspeakers 28 and 40, depending on the presence of a respective tilt position.
  • the control panel 34 consists of four knobs, one with an arrow down, one with an arrow up, one with an arrow to the left and another with an arrow to the right, or out two toggle switches, which are arranged perpendicular to each other, or a diamond-shaped toggle switch, but there are also other options for the control panel 34. Instead of a control panel with knobs, for example, a voice input could be provided.
  • the control panel 34 is provided so that the user via the control panel 34 of the control device 26 can supply control signals with which the same in a manner, as will be discussed in more detail, influence text information the controller 26 as forwards the text information to be displayed to the display 30.
  • the text information which the controller 26 forwards to the display 30 extracts the same from the text information objects contained in the broadcast signal 16 and extracted from the broadcast signal by the receiver 24.
  • the Textinformationsan- is show functionality losgelRst vRllig of the reproduction of the audio information, so that the sound or the current through the loudspeaker 28 or 40 wiedefplannede program is not chen underbro ⁇ upon actuation of the control panel 34th
  • the radio receiver 12 of Figure 1 further comprises in the memory 32, which is also referred to below as a cache memory, and for example, is a RAM, a list already received text information objects 42, a Ob ⁇ jekt path list 44 of object IDs, whose contents and meaning will be discussed in more detail below, and a list or an array of object IDs, referred to as favorite list 46, the meaning of which will also be specified in more detail below.
  • the memory 32 which is also referred to below as a cache memory, and for example, is a RAM, a list already received text information objects 42, a Ob ⁇ jekt path list 44 of object IDs, whose contents and meaning will be discussed in more detail below, and a list or an array of object IDs, referred to as favorite list 46, the meaning of which will also be specified in more detail below.
  • the "NewsService Journaline” enables the user of the radio or radio receiver 12 to easily and immediately access information in accordance with his or her current interest type.
  • the information is provided in a simple textual form.
  • the text information is contained in the text information objects There are, on the one hand, menu objects, text objects and list objects Before discussing the structure of the individual object types, it is intended to briefly illustrate their hierarchical structure with reference to FIG.
  • FIG. 2 illustrates how the text information objects according to the present embodiment are arranged in a tree structure.
  • FIG. 2 shows an exemplary example of an object tree 50 of text information objects.
  • the text information objects are indicated in FIG. 2 with square rectangles or rounded rectangles.
  • Each text information object is labeled with an "M", "T” and "L" for menu, text or list object.
  • every text information object has an object ID assigned to it.
  • it is assumed that the text information object at the root of the object tree 50 is assigned the fixed object ID 0, ie, 0x0000.
  • This main menu object is located in the first hierarchical level of the object tree 50 and is first of all triggered by the control device 26 as soon as it has been emitted via the broadcast signal 16 after switching on the radio 12 display 30 to show to ⁇ passed.
  • the main menu item 52 is thus initially shown when the user is using the radio or the NewsServcie Journaline functionality of the radio 12 first time without requesting a specific object id.
  • the text information object at the root of the object tree 50 is a menu object.
  • each menu item comprises in its text information a plurality of menu options or menu items to which a reference to a text information object of a next higher hierarchical level in the form of an object ID is assigned.
  • menu item 52 includes four menu options, and thus four references to other text information objects, as indicated by arrows 54.
  • the menu object 52 refers to two further menu objects 56 and 58 as well as two text objects 60 and 62, all of which form the text information objects of the second hierarchical level.
  • menu objects 56 and 58 of the second hierarchical level in turn have references to further text information objects, indicated by arrows 64 and 66, text objects, and thus also the text objects 60 and 62, do not include a reference to another text information object. They contain only text information.
  • the text objects "T” thus form the leaves of the object tree 50. The same applies to list objects "L”.
  • the exemplary object tree 50 of FIG. 2 forms four hierarchical levels, although any other number is conceivable. It is also conceivable that two menu objects (with different hierarchical levels, as a rule, refer to the same text information object, as is also the case in FIG Arrows 64 and 66 and the text information object 68 in the third hierarchical level.
  • the number of hierarchical levels of the tree structure may be set to a particular value, such as e.g. 20, be limited so that the receiving side at the radio receivers 12, the storage space for storing the data path 44 can be suitably dimensioned.
  • each text information object sometimes also simply referred to below as an object, must be referenced by at least one menu object, or at least one menu object must have a reference to the same. Only for the object 52 at the root of the object tree 50 does not need to exist a text information object that refers to the same. Of course, this would be possible.
  • the text information objects are therefore structured as in FIG. 2. All of these text information objects in the object tree 50 are stored in the list 22 in the memory 18 of the broadcast transmitter 10. Should, for some reason, the broadcaster 10 be unable to provide the "News Service Jouranline" service, the object at the root of the object tree 50 may also be a textual object such that the
  • Object tree 50 has only one hierarchy level, the text information in this text object, for example, indicate the temporary failure of the service.
  • Fig. 3 shows an embodiment for constructing text information objects according to an embodiment of the present invention.
  • Text information object 100 into an object header section 100a and an object content section 100b and is a maximum of 2044 bytes long.
  • the maximum length is not mandatory.
  • the object header section 100a is divided into a 3-byte default header 100al and an extension header 100a2, assuming that the latter has a length of n bytes, where n is an integer greater than or equal to zero ,
  • the object content section 100b is m bytes long, where m is an integer greater than zero.
  • the standard header 100a For example, it decomposes again into a 2-byte or 16-bit object ID 102, which may be 0x0000 at the main object 52 (FIG. 2), and an object descriptor 104, which is the eight lower-order bits of the standard Headers 100 occupies.
  • the number of 16 bits of the object ID limits the number of allocatable IDs to 2 16 , that is about 10 6 .
  • the bits of the object descriptor 104 have different meanings.
  • the object type ID 108 indicates by its value the object type of the text information object 100, as shown in the following table.
  • the static flag has the meaning that, when set, it is possible for the user to add the object ID 102 to the favorites list 46.
  • the static flag is set or not set by the text information broadcast service operator, depending on whether the object ID is assigned only randomly and temporarily, that is, displays only the same content information for a limited time, in which case adding to the favorites would be meaningful, or if the assignment of the object ID is permanent, and so that a favorites Hmzufugung would be useful, as will be discussed in more detail below.
  • the compression flag 114 indicates whether or not the object contents section 100b is compressed in a predetermined manner.
  • the revision index is set by the service operator to specify in the cyclically repeatedly serially transmitted text information objects with the same object ID, Which version of the text information or object to which these textual information objects are related. For each update, the revision index 110 is incremented on the send side.
  • the text information "0: 0" indicating the score would appear in the first text information objects having this object ID together with the revision index 000 b (b for binary), while after a bullet in the memory 18 the text information would be changed to "0: 1" and at the same time the revision index would be changed from 000 b to 001 b so that subsequently transmitted With this object ID, the text information object would have the text information "0: 1" and the revision index 001 b .
  • the revision index makes it possible to carry out updates on the receive side depending on whether the revision index has changed from an already received text information object to a newly received text information object or not without having to analyze the content.
  • the object ID is linked on the transmission side with text information, which is then contained in the object content section 10b, as will be explained below.
  • text information which is then contained in the object content section 10b, as will be explained below.
  • the extension header 100a2 represents an extension option for the message service. If the data application signaling information of the broadcasting system, that is, the control information in the broadcast signal besides the audio information and the text information, indicates that the extension header 100a2 contains additional header information If a receiver is unable to work with the extension header, it can easily ignore this section. Since the display is based on the use of the extension header and the usual data application signaling information of the broadcasting system, the length of the extension header 100a2 is the same for all objects of the "NewsService Journaline".
  • the actual text content or text information is contained in the text information objects in the object content section 100b.
  • FIGS. 6a to 6d each show an example of a screen display as it results on the display 30 depending on the object type. It should be noted that the examples assume a display capable of displaying a plurality of lines on a screen, but that the service can of course also be implemented on existing car radio displays, which can display mostly only one line of 16 characters.
  • a text information or a text-only message of a text object is divided into a title 150 and the actual text 152, the so-called text body.
  • the title 150 and the subsequent actual text section 152 are displayed or edited on the screen of the display 30 with automatic line break.
  • the user may scroll vertically through the text, for example, by operating a vertically positioned toggle switch or the like on the control panel 34.
  • the title 150 is appended to the text portion 152 so that it may be included in the displayed portion of the display along with the remaining text 152 as appropriate 30 is pushed. Any font can be used for display.
  • the amount of textual information of a textual object is greater than a displayable amount, so that only a part of the textual information can be displayed on the screen of the display 30.
  • This displayable portion is moved by operating corresponding keys on the control panel 34 via title 150 and text 152.
  • This possibility is indicated to the user by means of corresponding arrows on the right-hand edge of the screen of the display 30, as can be seen at 154 and 156 in FIG. 6a.
  • the displayable section is at the beginning of the entire text message. Another scrolling upwards does not make sense. This is indicated by a corresponding, for example color highlighting the arrow 154, which points upward. correspond
  • the highlighting is performed at arrow 156 when the displayable area or section is at the end of the message and therefore scrolling down is no longer possible.
  • Title-only messages only include a title 150 that is displayed on the screen of the display 30.
  • a text section 152 or body text is not provided.
  • the title text 150 is displayed on the screen of the display 30 again, for example, with automatic line break. If necessary, the user can scroll through the text. However, in the present case, the title may be fully displayed on the screen of the display 30, so that, by the absence of the arrows 154 and 156, the user is notified that the title 150 has been fully displayed and there is no scrolling capability.
  • the representation of a pure title message can, for example, always be centered both in the line and in the vertical direction. As a font, in turn, each is equally usable.
  • a list message includes a title 160 and a list of text lines 162a-162d.
  • the title should always be visible on the screen of the display 30 as the user scrolls through the rows 162a-162d of information in the body portion 162. It may be advantageous to use a font for displaying list objects that has a uniform character spacing in the row direction. to provide two-column tables by providing blanks as in the example of FIG. If the title 160 or any of the lines 162a to 162d exceeds a line length of the screen of the display 30, this list item is cut off at the end of the line, for example.
  • a menu contains a title 170 and a list of menu options 172a, 172b and 172c.
  • Each menu option is associated with a reference to another text information object, in the form of an object ID.
  • the user can scroll through the menu options.
  • One of the menu options on the screen of the display 30 is always highlighted, in this case the menu option 172b. If the user indicates by pressing a suitable button on the control panel 34, e.g.
  • the key to the right indicates that it wants to go to the text information object referenced by the reference of the menu option that is currently highlighted, and its contents are as well circumscribed by the text in the highlighted line of the menu as in the present Case through the menu option text "Second Corporation 32nd round", as will be described below, the text information of this text information object is next displayed on the display, whereby the current object or textual information on the screen of the display 30 replaced by the new one.
  • a menu option consists of a reference to another text information object and a label that contains a line on the screen of the display 30 represents and denotes or circumscribes the content of the referenced text information object. If the title or label exceeds the length of one line of the screen of the display 30, the corresponding content may be cut off.
  • square brackets 174 highlight menu options which can not be displayed immediately because they are not yet in the cache memory 32 , as will be discussed in more detail below.
  • the object content section is usually divided into a title and a body section. Only for title-only objects does the body section in the object content section be missing.
  • NML News Service Markup Language
  • escape sequences may be provided to introduce text formatting information, such as text highlighting, forced line break, etc., as well as additional functionalities, such as areas of information provided by recipients, Those who are unable to handle the extra functionality or who do not support this additional functionality can simply be ignored.
  • NML codes and escape sequences are one-byte codes ranging from 0x00 to 0xlF, called UTF-8 control codes.
  • the NML codes range from 0x00 to 0xOF and the escape sequences range from 0x10 to 0xlF.
  • Each object block in the object content section is started with an NML code and by either the NML code "End", the occurrence of another NML code, or the end of the object content section completed.
  • the NML codes are defined as examples in the following way:
  • 0x00 is the NML code for "end". It is used to terminate a section or block within the object content section without requiring another section or another block is started. It is applicable to every object type.
  • 0x01 be the NML code for "title” and, by its occurrence in the object content section 100b, indicate on the reception side the beginning of the title section or title block. Exactly one title block must exist per object for all previously defined object types, ie the NML code 0x01 will appear at least once in section 100b. The title block must also be the first block in the object content section 100b.
  • the NML code 0x01 is also applicable to all object types.
  • 0x02 be the NML code for a menu option block start. So this code represents the beginning of every menu option in a menu object. This code is therefore only intended for menu objects.
  • the receiver or decoder (not shown) provided in the controller 26 first awaits, in the subsequent bytes, the destination address or object ID of the referenced text information object referred to, and then the text of the menu option, which should be displayed and describes the content of the referenced object. For each menu option of a menu item, the code 0x02 occurs once in the item contents section.
  • the decoder in the controller 26 expects the code 0x02 to be followed by two bytes indicating the object ID of the referenced object, ie, the object to be displayed if the user selects this menu option , and then another n bytes, which indicate the menu option description to be displayed, in one line of the menu to be displayed to the user and to make it possible for him to choose among all the menu options.
  • Figure 4a shows a textual information object for the menu item of Figure 6a with the NML codes 0x00 to 0x02 for illustration.
  • the object 100 starts with an object header 100a, which in the present case is n bytes long by way of example. This is followed by the object content section 100b.
  • the first byte of the object content portion 100b is 0x01, that is, the NML code indicating the beginning of the title block whose textual content immediately follows the NML code 0x01 at the byte position 0 + 1 and byte 0 + 2 extends to byte k.
  • the title of the menu of FIG. 6d is stored, namely "Sport Germany Soccer".
  • the receive-side decoder knows when the title 200 has ended, since, as mentioned above, the text information of the title is encoded only with one-byte or multi-byte UTF-8 code words that are not NML codes or Escape Sequences are. Thus, once the receive-side decoder encounters the NML code 0x02 at byte k + 1 as shown, it knows that this is the beginning of a next block, namely the first menu option block.
  • the following two bytes k + 2 and k + 3 indicate by object ID OxAABB the next text information object to be displayed, in case that this menu item is selected. This is followed at 202 within bits k + 4 through p by the text encoding for the first menu option of the menu of Figure 6d, namely "Bundesliga 32nd round".
  • the byte p + 1 again an NML code 0x02 to indicate the beginning of a menu option block.
  • the menu option area is shown again at the reference 204a, 204b and 204c.
  • the NML code 0x00 occurs at byte t + 1. It indicates the end of the entire text information object 100 in this case.
  • This NML code 0x00 may be missing if, for example, the extension header contains the length of the entire text information object, so that the end of the entire object can be detected at the receiving end by appropriate syntactic analysis.
  • 0x03 be the NML code indicating the beginning of a body block in the object content section.
  • This therefore contains the text of the text body, which is displayed as the actual text in a text object, ie as 152 in FIG. 6 a, for example. Only one body block is possible in each object content section, and consequently only the occurrence of only once 0x03. The code occurs only with text objects.
  • the NML code 0x03 is missing in the object content section, since they do not contain a text body but only a title.
  • a coding example for a title information object is shown in FIG. 4b by way of example for the text object of FIG. 6a.
  • the body block is visible at 206. It consists of the NML code 0x03 followed by the UTF-8 encoding for the body text 152, namely "The cash position of the municipalities ".
  • the NML code 0x04 indicates the beginning of a bullet block in the object content section. This code only occurs with list objects in the Object Content section. In the bullet point box, the NML code 0x04 is followed by the encoding for the text that is to be displayed for that list item in a row of the list on the screen of the display.
  • FIG. 4c shows an example of a coding of a text information object using the example of FIG the list object of Figure 6c. The bullet points are indicated at 208a, 208b and 208c.
  • a block in the content section may have multiple escape sequences that should not be immediately displayed to the user.
  • escape sequences may include rendering pointers for the display, such as a display. an indication of a portion of text to be highlighted, a forced line break, a preferred line break, etc., or highlight portions of text that are not intended for direct rendering, such as textual editing; Binary code, that is, things that need to be ignored by recipients who are unable to process those data.
  • Escape or ESC codes can be, for example:
  • the continuation data section may comprise, for example, HTML / XML compliant labels or binary data.
  • Each of these two codes or codewords is followed by a byte specifying the length of the following data section in "Number of Bytes minus One". For example, a sample text with such data slices might read, "This is a ⁇ big> great ⁇ / big> test! (big), where the representation would be without a "data snapshot escape sequence” this is a ⁇ big> great ⁇ / big> test! "and the intended representation on a simple receiver” this is a great test!
  • Figs 4d and 4e can therefore be used can be used to indicate the text passages in the BIRcken 204a to 204c, 206 and 208a to 208c for suitably equipped receivers with corresponding indicators in a special way.
  • extension code contains only a single code without an explicit start / end version, you should always continue with the “extension code start” escape code. If a receiver is unable to interpret "extension codes,” it may have the “extension code begin / end” escape code (1 byte) and the following “extension code value” (1 byte ) to ignore.
  • the text information objects are transmitted by the transmitter 10 in the broadcast signal 16, and parsed in the controller 26 by means of a decoder or parser (not shown) therein in the manner explained with reference to FIGS. 3 and 4.
  • the control device 26 comprises an image processing device, not shown, which generates from the syntactically analyzed text information in the object content section of the text information object to be displayed suitable data, such as pixel data, which is then sent to the display 30 become. It should be noted, however, that the division regarding the image generation or processing and text extraction from the text information object to be displayed can also be proportionately shifted to the display 30, or that specially provided modules are connected between the control device 26 and the display 30.
  • FIGS. 3 and 4 dealt with the construction of a single text information object, it is described with reference to FIG. 5 in which order the text information objects in the broadcast signal 16 are transmitted.
  • FIG. 5 shows by way of example in a line 300 a section of a broadcasting signal 16.
  • An arrow 302 indicates which part of the broadcasting signal 16 is broadcast earlier or later, i. according to Figure 5, the left part before the right part.
  • individual text information objects are indicated by BlRcke. Each text information object is numbered. The number is the object ID assigned to the text information object.
  • the text information object with the object ID 1 with the repetition period ⁇ 1 and the object ID 25 with ⁇ 2 5- The frequency or repetition time depends on the expected frequency with which the respective text information object is desired by users of terminals, ie more frequently for weather news than for specific news from home or abroad.
  • the service provider constantly updates the text information objects in the memory 18. This means, on the one hand, the addition of text information objects to the list 22 with the assignment of new object IDs. However, this must also be accompanied by the change of at least one menu object, which now has to have another menu item or a further menu option with a reference to this new text information object. Therefore, there is also a change of the corresponding entry in the list 22 to the corresponding object ID of this changed menu object.
  • the text information object is
  • the receiver can use the object ID 1, the text information object whose text information is currently being displayed on the display 30, and the text information object 306, also containing the object ID 1, the text information object just received by the receiver 12, then the receiver can use the
  • the revision index of the text information object 306 and comparison thereof with the revision index of the text information object 304 determine whether an update is necessary is or not. Within a certain total repetition period (not shown in FIG. 5), each text information object is broadcast at least once.
  • text information object is used ambiguously: on the one hand it denotes an object which is transmitted in the broadcast signal but on the other hand also all objects with a specific object ID 2 is not text information object arranged in the tree structure, but object IDs.
  • object ID represents a plurality of text information objects which are transmitted one after the other, and those with the corresponding object ID, which in turn must not all be identical, but they can be updated over time, but in each case it is clear from the context in which the term "text information object” has just been used.
  • Figure 7 shows how the controller 26 in a display update process examines a recently received text information object to determine whether a Aktualisie ⁇ tion of the screen contents of the display 30 or should not be performed.
  • the controller 26 At the entrance of a text information
  • the controller 26 first checks in a step 400 whether the object ID of a currently received text information object is identical to the object ID of a currently displayed text information object. This would mean that the newly received text information object could include possible changes to the older one currently being displayed. If the comparison in step 400 results in no identity, the display update process ends at 402 to begin again upon receipt of the next received or subsequent text information object. If there is identity in step 400, control unit 26 checks in step 404 whether the revision index (110 in FIG.
  • step 404 the controller 26 checks the object type ID (108 in Figure 3), either of the currently received or currently displayed text information object, to see if it is a list, menu or title-only object type, ie 0x1, 0x3 or 0x4. If this is the case, the newly received text information object is now displayed on the display 30 in a step 410, as a result of which the text information on the display 30 is updated.
  • a display controller (not shown) ensures that the current scrolling Position of the user is maintained. This prevents the user, who has been laboriously scrolling or crawling through a part of a list or menu, to start over again when updating.
  • updating step 410 results in a menu option line of the pre-update menu, such as row 172b in FIG. 6d, having the same screen position even after the update, provided that the new menu object has enough lines or enough menu options or that it still has this menu option.
  • step 410 updating accordingly causes a list line of the list to be displayed at the same screen position before updating as after the update, provided that the new list object has enough lines .
  • the updating of step 410 is performed such that the so-so-many menu option and / or list line appears at the same screen position before and after the update. This also means that the displayable area before and after the update at least partially overlaps, so that user confusion during an update is avoided.
  • step 410 it may be provided simply to include the updated textual content of the newly received object as a new object new object ID easy to start from the beginning, since title-only messages by definition do not have a larger text body by definition. A possible renewed "screen scrolling" does not hurt.
  • the control unit checks whether the user gives or does not give consent. In the event that the user refuses an update, the display update process ends 414 until it is restarted. Otherwise, a display update is made 416. However, the display update in step 416 is performed without retaining the current display position as in step 410, but preferably as in the case of displaying a text information object with a new object ID from the beginning, that is, to the position scrolled to the beginning.
  • FIG. 8 shows a further process which is carried out continuously by the control device 26 when a newly received text information object arrives.
  • the process of Figure 8 is a cache update process.
  • the cache update process of FIG. 8 serves to ensure that the receiver 12 always contains at least part of the text information objects already received, more precisely for each object ID the text information object with the latest available version, for rapid display or has fast access.
  • the controller 26 checks the cache-updating process, first, in a step 450 based on the object ID of the newly received text information object, whether a text information onsTalk with this object ID in the list 22 in the SpeI ⁇ cher contained 32nd If this is the case, ie in the case of a cache hit, it is checked in a step 452 whether the revision index of the newly received text information object differs from the revision index of the text information object stored in the memory 32 and has the same object ID. If step 452 results in the identity of the two revision indexes, the cache update process terminates at 454 to start at one time. start again from the beginning of the subsequent text information object. If the check in step 452 reveals that the revision index of the newly received text information object is different from that in the cache memory 32, in step 456 the replacement of the corresponding entry in the list 42 is performed by the newly received text information object.
  • step 450 indicates that there is no entry with such an object ID in the list 42 of the cache memory 32, i. a cache miss
  • the controller 26 checks in step 458 whether the space provided for the list 42 in the memory 32 is full, or whether there is still enough memory to make an entry in the list 42. If the cache is not full, then in a step 460, the controller 26 enters the newly received text information object in the list 22 and the cache memory 32, respectively. However, this is only in an initial phase after switching on the receiver 12 or the "News Service Journaline" -
  • Functionality of the receiver 12 may be the case. After some time, the cache memory 32 will be full. In this case, in a step 462, the controller 26 checks for a certain cache displacement strategy, as will be explained in more detail below with reference to Figure 9, whether in the cache memory 32 in the list 42, a text information object exists that a has lower cache priority than the newly received one.
  • the check 462 takes into account the tree structure of the text information objects and defines a priority order among the text information objects depending on whether they are interspersed by the currently displayed text information object or a text information object in the data path. or not, or more generally, because of its position in the tree or its relative position to the currently displayed text information object within the tree structure. In addition, between objects of the same cache priority, the time of the last reception or content update or the frequency of reception or content updates can be evaluated.
  • an object tree is again shown as an example in FIG. 9, with menu objects again being marked with M and text objects with T. All menu items are numbered by a number at the bottom left corner indicating the item ID.
  • the currently displayed text information object is the text object with the object ID 100. It is in the fourth hierarchical level.
  • the user had to change the text information objects or the menu objects with the object ID 3 in the second one Go through the hierarchy level and the object ID 12 in the third hierarchical level.
  • the sequence of object IDs of the text information objects from the main object with the object ID 0 to and including the currently displayed object with the object ID 100, with the menu objects lying therebetween in the object tree constitute the object object.
  • Path 44 the receiver 12 stores in the memory 32, and will be discussed in more detail later. It is actually created to allow the user to return to higher menu levels, and therefore also saved to each "favorite.”
  • the object path is ⁇ 0, 3, 12, 100 ⁇ . All objects whose object ID are contained in the object path 44 (FIG. 1) are encircled by a dashed line in FIG.
  • a semicolon line in Figure 9 in addition to the object-path objects, all objects are referenced, which will be referred to by at least one of the objects in the object-path; these are the objects with the object IDs 1, 2, 4,..., 9, 13 in the example of FIG. 9.
  • the currently displayed text information object in the example of FIG. 9 was a text object. If it were a menu object, the semicolon line would include objects located in the fifth hierarchical level of the object tree.
  • Lowest priority text information objects that are outside the semicolon line i. Text information objects that are not referenced by at least one of the text information objects in the object path (indicated by the dashed line). In the example of FIG. 9, these are the text information objects 10, 11, 14 to 20.
  • Next higher priority text information objects are located between the knot point line and the dashed line. So these are the objects that are not on the object path, but are referenced by at least one object in the object path. 2.1.
  • a priority order is defined, such that objects of a higher hierarchy level have a higher priority than those of a lower hierarchy level, ie in the example of FIG. 9 the object with the object ID 13 has a higher priority than the one with the object IDs 1, 2, 4 to 9.
  • a priority order could be defined by the fact that objects with the Static Flag is set, a higher priority is assigned as such with no static flag set.
  • Next higher priority again comprise the menus or objects in the object path, in the present case the objects with the object IDs 0, 3, 12 and 100. Under these, a priority order could again be defined depending on the hierarchical level.
  • the cache update process ends at 464. If such exists, at step 466, the lowest priority object is replaced with the currently received object. Even if several objects of equal priority in the memory are the ones with the lowest priority, the oldest-received one should be replaced.
  • FIG. 10 shows a process performed by the controller 26 when a user on the control panel 34, while displaying a text information object on the display 30, operates keys intended for scrolling, such as those shown in FIG. the up-arrow and down-arrow keys.
  • the control device 26 shifts the text detail of the text information of the currently displayed object to be displayed downwards or upwards, if still possible.
  • the title is always displayed on the screen of the display.
  • FIG. 11 shows a process which is carried out by the control device 26 when, with the text information object displayed, the user actuates a selection key which may be a dedicated key on the control panel 34 or is, for example, the arrow-right key.
  • a selection key which may be a dedicated key on the control panel 34 or is, for example, the arrow-right key.
  • the controller 26 Upon actuation of this button or selection device checks the controller 26, in a step 550, whether or not the currently displayed text information object is a menu item. If this is not the case, the selection key is not assigned, ie no function is assigned to it, and the process of FIG. 11 ends at 552. If it is a menu object, then the control device 26 beats in the memory 32 in a step 554 to see if it contains an object with an object ID associated with the highlighted menu option (see 172b in Figure 6d). If this is the case, ie in the
  • step 556 the controller 26 changes the text information to be displayed to that of the object contained in the cache memory 32. As access to the cache memory 32 is fast, the screen change to the display 30 is thus imperceptible to the user, i. immediate.
  • step 558 the controller 26 waits for an object having the searched object ID to be broadcast in the broadcast signal 16.
  • all other processes are performed as usual, in particular the processes of Figure 7 and Figure 8 on the now incoming objects.
  • control device 26 changes in a step 560 the text information to be displayed on the screen of the display 30 to that of the currently received object with the searched object ID.
  • steps 560 and 556 respectively, an object-path update is performed in a step 562, as shown in greater detail in FIG.
  • FIG. 12 illustrates the object path update process of step 562 the controller 26 looked up in the memory 32 whether the new object ID, ie the object ID of the now newly displayed on the display 30 object, which was associated with the selected menu option, already xediert in the object path 44 , If that were the case, the simple would be
  • the controller 26 in a step 582, causes the object path list 44 to be clipped to this object ID, i. to end with this object id. Otherwise, i. in the case of a miss at lookup step 580, in a step 584, the new object ID is appended to the end of the object path list 44, unless the object path is length limited and has already reached its maximum length.
  • the management of the object Pf d list 44 is intended to enable menu-back functionality, as further explained with reference to FIG. 13, which illustrates a process that the controller 26 chooses to press a back key , such as the post-left key on the control panel 34, when a text information object is being displayed on the display 30.
  • a back key such as the post-left key on the control panel 34
  • the controller 26 retrieves, from the object path list 44, the object ID immediately preceding the object path of the object ID of the currently displayed object in the object path, and its object thus refers to it.
  • pressing the back button there would cause the object ID 12 to be determined in step 600.
  • the controller 26 beats in the memory 32 for an object with this object ID.
  • step 604 the controller 26 changes the text information to be displayed to that of the object contained in the cache memory 32. Otherwise, ie in the case of a failure, the control device 26 waits in step 606 until an object with the searched object ID is broadcast in the broadcast signal 16, whereupon, as in a step 608, the text information to be displayed matches that of the current one received object with searched object ID changes.
  • step 612 it is checked in step 612 whether the object ID path 44 actually has more than one object ID.
  • the length would be one if the user were currently in the main menu (i.e., 0x0000, for example). If so, the operation of the menu back key would have no consequences and the process ended at 614. Otherwise, the process would start at 600 as described above.
  • the receiver 12 has favorite functionality to enable a user to store certain menu or message objects for fast and direct future access, for example by giving them the highest priority in cache memory is assigned.
  • the receiver 12 comprises a dedicated key, by the long press of which the user can express his desire to add the object ID of the currently displayed text information object to the favorites list while briefly pressing the same key causes the controller to pull the favorite object ID into the favorite memory for the next text information object to be displayed.
  • FIG. 14 illustrates a favorite addition key activation control process. If the user indicates the desire to add, then in step 700 the controller 26 first checks whether the currently displayed object has a set static flag.
  • a menu item relating to "weather forecast for Bamberg" could always be offered by a particular news service or news service under object ID 0x0020.
  • the controller 26 adds the object ID to the favorites list 46 in the memory 32 in a step 702.
  • this game ends in finite time and the object ID will be awarded elsewhere, for example for a political day avoidance or the like. If the static flag is not set, then the process ends at 704 without addition.
  • the rejection 704 may be accompanied by, for example, a sound which transmits the normal audio signal from the loudspeaker 28 or 40 and the user's disapproval, or a short-term cross-fade.
  • a receiver 12 that supports the favorites functionality also for each favorite object ID, the full path of object IDs from the main object with the main object ID (eg 0x0000) down to the respective favorite object. Otherwise, the recipient will not be able to provide the menu-back functionality or return-to-higher-menu functionality to a user when a user has invoked this favorite object, although of course the object itself as well as the immediate sub-objects, in the case that it is a menu object pointing to them, would still be reachable. If a menu from the object ID path should no longer exist (be shipped) upon restoration of a favorite memory, the controller could instead jump directly to the default main menu (e.g., 0x0000).
  • menu object contains references to object IDs that have not yet been received, these menu items or menu options are nevertheless offered to the user. Of course, this could be avoided. However, it is preferred to offer all menu options, but to clearly indicate to the user which menu options are immediately available, since the objects have already been received and are in the cache, and which are not immediately available, such as eg by surrounding the menu Option labels or titles with square brackets, as shown in Figure 6d.
  • the receiver could only keep the currently displayed object in its memory along with the object ID path associated with the currently displayed object. If the user then requests another object, he must wait until the requested object is received in the next time.
  • the NewsService Journaline service described above may be broadcast via DAB as a new user application, and any single NewsService Journaline object may be transported as an "MSC Data Group", in which case to Chapter 5.3.3 "Packaged Mode - Data Group Level” in "Radio Broadcasting Systems, Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers", ETSI EN 301 401 VI.3.2, 2000-09, is shown.
  • DAB Digital Audio Broadcasting
  • An MSC data group would then contain the following items: An MSC data group headers of two or four bytes, a session header which would be optional and which would be 3 + n bytes long, an MSC data group field includes a "News-Service Journaline" object or text information object of, for example, m bytes, max. however, 2044 bytes, and finally an MSC data group CRC of two bytes, which is mandatory for "NewsService Journaline".
  • the following settings could be set uniformly for all recipients. Namely, it could be specified that the MSC Data Group header field has the following layout:
  • the following information could be used to signal the DAB "NewsService Journaline” data application, referring to Chapter 8.1.20 "User Application Information” from the above document or standard.
  • the main ll-bit "user application type” ID for the "News Service Journal” could be 0x44A from the range of proprietary user applications until officially standardized by DAB bodies. The value corresponds to 10001001010 b .
  • the User Application Data field had to have the length of the extension header in bytes in the header section of each object, which at least had to be able to be read by each receiver, even if he subsequently entered the data in the extension header. Discards headers because he is unable to evaluate them.
  • "NewsService Journaline” can also be broadcast via DRM ("Digital Radio Musice"), as well as via FM / RDS after adjustment of data service signaling.
  • the inventive scheme for controlling a radio can also be implemented in software.
  • the implementation can take place on a digital storage medium, in particular a floppy disk or a CD with electronically readable control signals, which can cooperate with a programmable computer system such that the corresponding method is carried out.
  • the invention thus also exists in a computer program product with program code stored on a machine-readable carrier for carrying out the method according to the invention, when the computer program product runs on a computer.
  • the invention can thus be described as a computer program with a program code to perform the method when the computer program runs on a computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Circuits Of Receivers In General (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

RADIO MIT ANZEIGE FÜR TEXTINFORMATIONEN-DIE AUF WEITERE TEXTINFORMATIONSOBJEKTEN VERWEISEN
Beschreibung
5 Die vorliegende Erfindung bezieht sich auf Radios und insbesondere auf solche, die eine Anzeige aufweisen, um Textinformationen anzeigen zu kRnnen.
Es existieren bereits textbasierte Nachrichtendienste für 10 digitale Rundfunksysteme, bei denen ein Benutzer eines Radios Textnachrichten an einer Anzeige des Radios ablesen kann. Hierbei werden in dem Rundfunksignal zusammen mit den Audioinformationen für das Radio weitere Informationen, nämlich Textinformationen, ausgestrahlt. Ein HRrfunkstan- 15 dard, der diese Übertragung von Audio-Informationen und Textinformationen nebeneinander in einem Übertragungskanal bzw. Rundfunksignal ermRglicht, ist beispielsweise der DAB- Standard (DAB = Digital Audio Broadcasting) .
20 Textbasierte Nachrichtendienste nutzen diese MRglichkeit des digitalen Rundfunks jetzt schon aus, um an Endgeräte Textnachrichten auszustrahlen. Beispielsweise senden Rundfunkanstalten neben dem eigentlichen Rundfunkprogramm, also den Audio-Informationen, Textinformationen, die auf der An- 25 zeige des Rundfunkempfängers des Benutzers angezeigt werden kRnnen, wie z.B. den Namen des Rundfunkprogramms oder aber aktuelle Nachrichten oder dergleichen. Über die Art und die Reihenfolge der Informationen entschied der Programmverantwortliche. Bisherige textbasierte Nachrichtendienste ermRg- 30 lichten es einem Benutzer hierbei nur beschränkt Einfluss auf die Auswahl der Textnachrichten zu nehmen, die auf seinem Display angezeigt wurden, wie z.B. durch Wechseln des Programms . Es ist deshalb die Aufgaben der vorliegenden Erfindung ein Textinformationsdienstschema bereitzustellen, das einem Benutzer eine effektivere MRglichkeit bietet, mittels eines Radios an gewünschte Textinformationen über den Rundfunk zu gelangen.
Diese Aufgabe wird durch einen Rundfunkempfänger gemäß Anspruch 1 und Verfahren zum Steuern eines Rundfunkempfängers gemäß Anspruch 16 gelRst.
Eine Erkenntnis der vorliegenden Erfindung besteht darin, dass ein Benutzer eines Rundfunkempfängers bedeutend schneller an Textinformationen gelangt, wenn in einem in dem Rundfunksignal umfassten Textinformationsobjekt, das auf der Anzeige des Rundumrundfunkempfängers gerade angezeigt wird, ein Verweis auf ein anderes Textinformations- Objekt in dem Rundfunksignal enthalten ist, und es dem Be¬ nutzer ermRglicht wird, durch einfache Bedienung einer Be- nutzer-Auswahleinrichtung zu veranlassen, dass die anzuzeigenden Textinformationen von den Textinformationen des aktuellen Textinformationsobjekts auf die Textinformationen des Textinformationsobjekts geändert werden, auf das durch das aktuelle Textinformationsobjekt verwiesen wird. Der Zu- satzaufwand ist hierbei sehr begrenzt, da bei heutigen
Rundfunkempfängern zumeist eine "unbelegte" Taste, die nur in speziellen Situationen der Benutzung des Rundfunkempfängers eine zugewiesene Funktion hat und somit belegt ist, existiert und insoweit als Benutzer-Auswahleinrichtung ver- wendet werden kann.
Gemäß einem speziellen Ausführungsbeispiel der vorliegenden Erfindung werden die Textinformationsobjekte in dem Rund- funksignal aufeinanderfolgend neben anderen Informationen in dem Rundfunksignal, wie z.B. den Audio-Informationen o- der aber anderen Informationen, von einem Rundfunksender ausgestrahlt, wobei jedes Textinformationsobjekt eine Ob- jekt-ID aufweist. Verweist ein Textinformations-Objekt auf ein anderes Textinformationsobjekt, so unterscheiden sich deren Objekt-IDs. Das Einführen der Objekt-IDs ermRglicht es, die Textinformationsobjekte in dem Rundfunksignal inhaltlich in Gruppen einzuteilen und sie für Empfänger er- kennbar zyklisch wiederholt zu übertragen und dabei zu aktualisieren. Ein Rundfunkempfänger kann somit ohne inhaltlich den Inhalt der Textinformations-Objekte, d.h. die Textinformationen, analysieren zu müssen, erkennen, ob ein bestimmtes soeben empfangenes Textinformationsobjekt, ob- wohl es sich von dem aktuellen angezeigten unterscheidet, den selben Gegenstand betrifft wie ein vorher bereits empfangenes und somit eine Aktualisierung darstellt, oder ob das aktuell empfange Textinformationsobjekt inhaltlich einen vRllig anderen Gegenstand betrifft. Eine Aktualisierung kann auf einfache Weise vorgenommen werden, indem die Ob- jekt-ID eines auf das aktuell angezeigte Textinformations- Objekt unmittelbar oder nicht unmittelbar folgenden Textinformationsobjekts in dem Rundfunksignal mit der Objekt-ID des aktuell angezeigten verglichen wird. Abhängig davon, ob der Vergleich die Identität bei den Objekt-IDs ergibt, wird die Aktualisierung vorgenommen oder nicht.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann die Aktualisierung für die Rundfunkempfänger unaufwen- diger gestaltet werden, indem die Textinformationsobjekte neben der Objekt-ID noch einen Revisionsindex aufweisen, der Auskunft darüber gibt, welche Version der Textinformationen, die dieser Objekt-ID zugeordnet sind, dieses Text- informationsobjekt betrifft. Ein Radioempfänger ist folglich nicht gezwungen, blind eine Aktualisierung immer dann vorzunehmen, wenn in dem Rundfunksignal wieder ein Textinformationsobjekt ausgestrahlt wird, dessen Objekt-ID mit der Objekt-ID des aktuell angezeigten Textinformations- Objekts übereinstimmt. Vielmehr wird die Aktualisierung noch davon abhängig gemacht, ob sich der Revisionsindex geändert hat. Bildaufbau und andere Aufbereitungsmechanismen unterbleiben folglich, wenn das neue Textinformationsobjekt mit selbiger Objekt-ID sich inhaltlich gar nicht von dem bereits angezeigten unterscheiden kann, da es dieselbe Version der Textinformationen zu dieser Objekt-ID betrifft. Der Zusatzaufwand durch die Belastung des Übertragungskanals durch den Revisionsindex in jedem Textinformationsob- jekt ist vergleichsweise gering.
Die Aktualisierung kann darüber hinaus weiter benutzerfreundlicher gestaltet werden, wenn zwischen den einzelnen Textinformations-Objekten unterschieden wird. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung existieren Menüobjekte, Listenobjekte und reine Textobjekte. Jedes Textinformationsobjekt ist durch einen Objekt-Deskriptor bzw. eine Objekt-Typ-ID einem dieser Typen zugeordnet. In dem Fall, dass es sich um Menü- oder Listen-Objekte han- delt, führt der Rundfunkempfänger die Aktualisierung unmit¬ telbar, d.h. ohne eine Benutzerinteraktion, durch, während anderenfalls die Aktualisierung davon abhängig gemacht wird, ob der Benutzer sein Einverständnis bzw. seine Zustimmung zur Aktualisierung erteilt, damit er nicht wegen einer eventuell nur geringfügigen Aktualisierung beim Lesen eines zusammenhängenden längeren Textes jäh unterbrochen wird. Gemäß einem weiteren Ausführungsbeispiel ist es ferner vorgesehen, dass die Anzeige bei der Aktualisierung in dem Fall, dass die Menge an Textinformationen des neuen Textinformationsobjekts grRßer als eine anzeigbare GrRße ist, ei- nen Ausschnitt der Textinformationen dieses neuen Textinformationsobjekts anzeigt, der sich zumindest teilweise mit einem Ausschnitt überschneidet, den die Anzeige vor der Aktualisierung von dem alten Textinformationsobjekt zeigte. Insbesondere bei Listen- und Menü-Objekten ergibt dies den Vorteil, dass der Benutzer sich nach erfolgter Aktualisierung nicht neu in der Liste bzw. dem Menü orientieren muss, und dass er aber trotzdem beim Weiterscrollen die Aktualisierung erfährt.
Verfügt der Rundfunkempfänger bzw. das Radio über einen Cache-Speicher zum zeitweiligen Speichern von bereits empfangenen Textinformationsobjekten, so ist es ihm mRglich, bei der Änderung der anzuzeigenden Textinformationen von Textinformationen des aktuellen Textinformations-Objekts auf Textinformationen des Textinformationsobjekts mit anderer Objekt-ID, auf das das aktuelle Textinformations-Objekt verweist, zunächst in dem Cache-Speicher nachzuschlagen, ob sich ein Textinformationsobjekt mit dieser Objekt-ID nicht bereits im Cache-Speicher befindet. Der Benutzer gelangt somit schneller zu den neuen Textinformationen des neuen
Textinformationsobjekts und muss nicht die Zeitdauer abwarten, bis ein Textinformationsobjekt mit der gewünschten Objekt-ID, auf das das aktuelle Textinformationsobjekt verweist, in dem Rundfunksignal wieder ausgestrahlt wird.
Damit der Benutzer beim Durchsehen des Menüs bzw. Scrollen durch dasselbe gleich weiß, welche Menüoptionen auf Objekt- IDs verweisen, für die ein Textinformationsobjekt im Cache- Speicher gespeichert ist, kann ein Cache-Treffer- Identifizierer vorgesehen sein, der zunächst im Cache- Speicher nach Textinformationsobjekten für alle Objekt-IDs nachschlägt, die den Menüoptionen des Menü-Objekts zugeord- net sind, und dann durch Modifizieren der anzuzeigenden Textinformationen dafür sorgt, dass die Menüoptionen, für die Textinformationsobjekte in dem Cache-Speicher vorhanden sind, für den Benutzer sichtbar von denjenigen unterscheidbar sind, für die noch keine Textinformationsobjekte im Ca- che-Speicher vorhanden sind. Dies beschleunigt für einen Benutzer das Zappen durch die Menüs, d.h. den Knoten des Objektbaumes, gemäß dem die Textinformationsobjekte ange¬ ordnet sind.
Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung unterstützt ein Rundfunkempfänger eine Favoritenfunktionalität. In einem Favoritenspeicher sind hierzu eine oder mehrere Objekt-IDs von Textinformationsobjekten gespeichert, die Gegenstände betreffen, die den Benutzer wie- derholt, beispielsweise jeden Morgen auf der Fahrt zur Arbeit, interessieren und die er durch Bedienen einer Favoriten-Abfrage-Einrichtung abrufen kann. Um nun zu verhindern, dass der Benutzer Objekt-IDs zu den Favoriten hinzufügt, die aber nicht auf längere Zeit hin einem Textinformations- objekt mit diesem Gegenstand zugeordnet sind, wie z.B. eine einmalige Nachrichtenmeldung, sondern die anschließend wieder einem Textinformationsobjekt mit einem inhaltlich ande¬ ren Gegenstand zugewiesen werden, umfasst ein Textinformationsobjekt beispielsweise ein Statisch-Flag. Die Zu- Favoriten-Hinzufügen-Funktionalität des Rundfunkempfängers wird nur aktiviert, wenn das Statisch-Flag gesetzt ist, sonst nicht, wodurch sinnloses Hinzufügen zufällig zugewiesener Objekt-IDs vermieden wird. Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf beiliegende Zeichnungen näher erläutert. Es zeigen:
Fig. 1 ein Übersichtsblockschaltbild mit Sender und Empfänger zu Veranschaulichung eines Textinfor- mationsrundfunkdienstes gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 2 eine exemplarische Baumstruktur, in der die Textinformationsobjekte des Dienstes von Fig. 1 angeordnet sind;
Fig. 3 eine schematische Zeichnung zur Veranschaulichung des Aufbaus der Textinformationsobjekte nach dem Dienst von Fig. 1 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 4a-e schematische Zeichnungen zur Veranschaulichung des Aufbaus exemplarischer Textinformationsobjekte oder von Teilen derselben durch NML- und UTF-8-Codes;
Fig. 5 eine schematische Zeichnung zur Veranschaulichung der seriellen und zyklischen Übertragung der Textinformationsobjekte in dem Rundfunksignal von Figur 1;
Fig. 6a-d exemplarische Bildschirmanzeigen auf der Anzeige des Rundfunkempfängers von Fig. 1; Fig. 7 ein Flussdiagramm eines Anzeige-Aktualisierungs-Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 8 ein Flussdiagramm eines Cache-Aktualisierungs- Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 9 eine schematische Skizze einer exemplarischen Baumstruktur von Textinformationsobjekten zur Veranschaulichung der Cache-Verdrängungs-Strategie gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 10 ein Flussdiagramm eines Scroll-Prozesses gemäß einem Ausführungsbeispiels der vorliegenden Erfindung;
Fig. 11 ein Flussdiagramm eines Menü-Auswahl-Prozesses gemäß einem Ausführungsbeispiels der vorliegenden Erfindung;
Fig. 12 ein Flussdiagramm einer Objekt-Pfad-Aktualisierung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; und
Fig. 13 ein Flussdiagramm eines Eine-Hierarchie-Ebene- Zurück-Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; und
Fig. 14 ein Flussdiagramm eines Favoriten-Hinzufügung- Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die vorliegende Erfindung wird nachfolgend bezugnehmend auf die Figuren vor dem Hintergrund eines Textinformationsrund- funkdienstes beschrieben, wie er in Figur 1 im Aufbau ge- zeigt ist. Radios gemäß der vorliegenden Erfindung kRnnten jedoch auch im Rahmen anderer Textinformations- Rundfunksysteme Verwendung finden. Bei in unterschiedlichen Figuren gleichermaßen vorkommenden Elementen sind für diese gleiche Bezugszeichen verwendet worden, wobei eine wieder- holte Beschreibung der Elemente vermieden wurde.
Der Textinformationsrundfunkdienst nach Fig. 1, der im Folgenden auch manchmal als "NewsService Journaline" bezeichnet wird, wird in Fig. 1 an einem Paar eines Rundfunksen- ders 10 und eines Rundfunkempfängers 12 veranschaulicht. Der Rundfunksender 10 ist eine stationäre zentrale Rundfunkstation, die über eine Antenne 14, wie z.B. einen Sendemast, Rundfunksignale 16 an eine Vielzahl von Rundfunkempfängern, wie den Rundfunkempfänger 12, ausstrahlt. Das Rundfunksignal 16 umfasst neben Audio-Informationen, die unterschiedliche Rundfunkprogramme betreffen kRnnen, Textinformationen, die für die Rundfunkempfänger bzw. Endgeräte 12 und deren Benutzer im Rahmen des Textnachrichtenrundfunkdienstes bestimmt sind. Das Rundfunksignal 16 ent- spricht beispielsweise dem DAB-Standard.
Der Rundfunksender 10 umfasst neben anderen Komponenten, die für die Audio-Übertragung bzw. für die Übertragung der Audio-Informationen bestimmt sind und hier aus Übersicht- lichkeitsgründen nicht gezeigt sind, einen Speicher 18 und eine Einbindungseinrichtung 20. Der Speicher 18 enthält eine Liste 22 von Textinformationsobjekten. Wie es später noch detaillierter beschrieben werden wird, umfasst jedes Textinformationsobjekt zumindest eine Objekt- Identifikationsnummer bzw. Objekt-ID sowie den eigentlichen Textinhalt, d.h. die Textinformationen. Daneben umfassen Textinformationsobjekte je nach ihrem Typ auch weitere In- formationen, wie es ebenfalls detaillierter im Folgenden beschrieben werden wird. Die Textinformationsobjekte in der Liste 22 werden von einem Dienstbetreiber gepflegt und aktualisiert. Er trifft die Auswahl an Themen, die die Objekte betreffen, die Struktur, in der die Objekte geordnet sind, und die Zeitdauer, in der dieselben zyklisch wiederholt ausgestrahlt werden.
Die Einbindungseinrichtung 20 ist mit dem Speicher 18 verbunden, um die Textinformationsobjekte von dem Speicher 18 auszulesen und in das Rundfunksignal einzubinden, um dasselbe über die Antenne 14 als das Rundfunksignal 16 auszustrahlen. Die Auslese bzw. Ausstrahlung durch die Einbindungseinrichtung 20 erfolgt für jedes Textinformationsobjekt zyklisch, so dass insgesamt alle Textinformations- Objekte zyklisch nacheinander über in dem Rundfunksignal 16 ausgestrahlt werden, und zwar mit unterschiedlichen Zyklus- Wiederholzeiten, wie es später noch bezugnehmend auf Figur 5 detaillierter beschrieben wird.
Ein Rundfunkempfänger 12 gemäß dem vorliegenden Ausfüh- rungsbeispiel umfasst eine Empfangseinrichtung 24, eine Steuereinrichtung 26, einen Lautsprecher 28, eine Anzeige bzw. ein Display 30, einen Speicher 32, ein erstes Bedienfeld 34 und ein zweites Bedienfeld 36. Die Empfangseinrich- tung 24 ist mit einem Dateneingang mit einer Antenne 38 verbunden, um über dieselbe 38 das Rundfunksignal 16 zu empfangen. Die Empfangseinrichtung 24 ist geeignet ausgebildet, um aus dem Rundfunksignal 16 die Audio- Informationen und die Textinformationen zu extrahieren und über ihren Datenausgang an die Steuereinrichtung 26 weiterzuleiten.
Die Steuereinrichtung 26, wie z.B. ein Prozessor oder dergleichen, leitet zunächst die Audio-Informationen an den Lautsprecher 28 weiter. Hierbei wird schon eine Auswahl getroffen worden sein unter einem Angebot verschiedener Audioinhalte bzw. Rundfunkprogramme. Die Weiterleitung ausge- wählter Audiosignale kann entweder über eine interne Leitung zu einem integrierten Lautsprecher 28 geschehen, wie es in Figur 1 mit durchgezogenen Linien dargestellt ist, oder über einen Lautsprecheranschluss oder durch Ausgabe geeigneter Audiosignale an einen externen Lautsprecher 40 geschehen, der extern zu dem Rundfunkempfänger 12 angeordnet ist, wie es mit gepunkteten Linien in Figur 1 gezeigt ist.
Über das Bedienfeld 36, das beispielsweise lediglich einen Kippschalter mit zwei Kipppositionen bzw. Kippstellungen umfasst, kann der Benutzer des Rundfunkempfängers 12 beispielsweise von einem Rundfunkprogramm zu dem anderen wechseln. Das Bedienfeld 36 ist hierzu mit der Steuereinrichtung 26 verbunden, die wiederum ausgebildet ist, um je nach vorliegen einer jeweiligen Kippstellung das aktuelle Programm und damit die Audiosignale an den Lautsprecher 28 bzw. 40 zu ändern.
Weitere Steuersignale erhält die Steuereinrichtung 26 von dem Bedienfeld 34. Das Bedienfeld 34 besteht beispielsweise aus vier KnRpfen, einem mit einem Pfeil nach unten, einem mit einem Pfeil nach oben, einem mit einem Pfeil nach links und einem anderen mit einem Pfeil nach rechts, oder aus zwei Kippschaltern, die senkrecht zueinander angeordnet sind, oder einem rautefRrmigen Kippschalter, wobei jedoch auch andere MRglichkeiten für das Bedienfeld 34 bestehen. Anstatt eines Bedienfeldes mit KnRpfen kRnnte beispielswei- se eine Spracheingabe vorgesehen sein. Das Bedienfeld 34 ist dazu vorgesehen, dass der Benutzer über das Bedienfeld 34 der Steuereinrichtung 26 Steuersignale zuführen kann, mit denen derselbe auf eine Weise, wie sie im Folgenden näher erRrtert werden wird, Einfluss darauf nehmen kann, wel- ehe Textinformationen die Steuereinrichtung 26 als die anzuzeigenden Textinformationen an die Anzeige 30 weiterleitet. Die Textinformationen, die die Steuereinrichtung 26 an die Anzeige 30 weiterleitet, extrahiert dieselbe aus den Textinformationsobjekten, die in dem Rundfunksignal 16 ent- halten sind, und durch die Empfangseinrichtung 24 aus dem Rundfunksignal extrahiert werden. Die Textinformationsan- zeigefunktionalität ist von der Widergabe der Audioinformationen vRllig losgelRst, so dass bei Betätigung des Bedienfeldes 34 die Tonwiedergabe bzw. das aktuell über den Laut- Sprecher 28 oder 40 wiedefgegebene Programm nicht unterbro¬ chen wird.
Der Rundfunkempfänger 12 von Figur 1 umfasst ferner in dem Speicher 32, der im Folgenden auch als Cache-Speicher be- zeichnet wird, und beispielsweise ein RAM ist, eine Liste bereits empfangener Textinformationsobjekte 42, eine Ob¬ jekt-Pfad-Liste 44 von Objekt-IDs, deren Inhalt und Bedeutung im Folgenden noch näher erRrtert werden wird, und eine Liste bzw. ein Array von Objekt-IDs, die als Favoritenliste 46 bezeichnet wird, deren Bedeutung ebenfalls im Folgenden näher spezifiziert werden wird. Durch den „NewsService Journaline" kann der Benutzer des Radios bzw. Rundfunkempfängers 12 auf einfache Weise und sofort auf Informationen gemäß ihrem oder seinem augenblicklichen Interessentyp zugreifen. Die Informationen lie- gen in einfacher Textform vor. Die Textinformationen sind in den Textinformationsobjekten enthalten. Es existieren verschiedene Textinformationsobjekte, die nach ihrem Typ unterschieden werden kRnnen. Da gibt es einerseits Menü- Objekte, Textobjekte und Listenobjekte. Bevor näher auf den Aufbau der einzelnen Objekttypen eingegangen wird, soll bezugnehmend auf Figur 2 kurz deren hierarchische Struktur veranschaulicht werden.
Figur 2 veranschaulicht, wie die Textinformationsobjekte gemäß dem vorliegenden Ausführungsbeispiel in einer Baumstruktur angeordnet sind. Figur 2 zeigt ein exemplarisches Beispiel eines Objektbaumes 50 aus Textinformationsobjekten. Die Textinformationsobjekte sind in Figur 2 mit eckigen Rechtecken bzw. angerundeten Rechtecken angezeigt. Je- des Textinformationsobjekt ist mit einem "M" , "T" und "L" für Menü-, Text- bzw. Listen-Objekt beschriftet. Wie bereits erwähnt, ist jedem Textinformationsobjekt eine Objekt-ID zugeordnet. Lediglich exemplarisch wird davon ausgegangen, dass dem Textinformationsobjekt an der Wurzel des Objektbaumes 50 die feste Objekt-ID 0 zugewiesen ist, d.h. 0x0000. Dieses Haupt-Menü-Objekt, angezeigt mit 52, befindet sich in der ersten Hierarchieebene des Objektbaums 50 und wird von der Steuereinrichtung 26, sobald es nach dem Einschalten des Radios 12 über das Rundfunksignal 16 ausge- strahlt worden ist, zu aller erst an die Anzeige 30 zur An¬ zeige weitergeleitet. Das Hauptmenü-Objekt 52 wird folglich zu Beginn gezeigt, wenn der Benutzer das Radio oder die „NewsServcie Journaline"-Funktionalität des Radios 12 das erste Mal einschaltet, ohne dabei eine spezifische Objekt- ID abzufordern.
In dem Ausführungsbeispiel von Figur 2 ist das Textinforma- tionsobjekt an der Wurzel des Objektbaumes 50 ein Menü- Objekt. Wie es im Folgenden noch näher erRrtert werden wird, umfasst jedes Menü-Objekt in seinen Textinformationen mehrere Menü-Optionen bzw. Menüpunkte, denen jeweils ein Verweis auf ein Textinformationsobjekt einer nächsthRheren Hierarchieebene in Form einer Objekt-ID zugeordnet ist. In dem vorliegenden exemplarischen Beispiel umfasst das Menü- Objekt 52 vier Menü-Optionen und damit vier Verweise auf andere Textinformationsobjekte, wie es mit Pfeilen 54 angedeutet ist. Insbesondere verweist in dem vorliegenden Bei- spiel das Menü-Objekt 52 auf zwei weitere Menü-Objekte 56 und 58 sowie zwei Text-Objekte 60 und 62, die all vier die Textinformationsobjekte der zweiten Hierarchieebene bilden. Während die Menü-Objekte 56 und 58 der zweiten Hierarchieebene ihrerseits wiederum Verweise auf weitere Textinforma- tionsobjekte aufweisen, angedeutet durch Pfeile 64 und 66, umfassen Textobjekte, und somit auch die Textobjekte 60 und 62, keinen Verweis auf ein anderes Textinformationsobjekt. Sie enthalten lediglich Textinformation. Die Text-Objekte "T" bilden somit die Blätter des Objektbaumes 50. Selbiges gilt für Listen-Objekte „L" .
Wie es in Figur 2 dargestellt ist, bildet somit der exemplarische Objektbaum 50 von Figur 2 vier Hierarchieebenen, wobei jedoch auch jegliche andere Anzahl denkbar ist. Fer- ner ist es denkbar, dass zwei Menü-Objekte (mRglcherweise unterschiedlicher Hierarchieebenen) auf das selbe Textinformations-Objekt verweisen, wie es auch in Figur 2 bei Pfeilen 64 und 66 und dem Textinformations-Objekt 68 in der dritten Hierarchieebene gezeigt ist.
Die Anzahl an Hierarchieebenen der Baumstruktur kann auf einen bestimmten Wert, wie z.B. 20, begrenzt sein, damit empfangsseitig bei den Rundfunkempfängern 12 der Speicherplatz zur Speicherung des Datenpfads 44 geeignet dimensioniert werden kann.
Aus der Beschreibung von Fig. 2 wird klar, dass jedes Textinformationsobjekt, im Folgenden auch manchmal einfach als Objekt bezeichnet, von zumindest einem Menü-Objekt referen- ziert sein muss, bzw. dass zumindest ein Menü-Objekt einen Verweis auf dasselbe aufweisen muss. Lediglich für das Ob- jekt 52 an der Wurzel des Objektbaumes 50 muss kein Textinformationsobjekt existieren, das auf das selbe verweist. Freilich wäre dies aber mRglich.
Die Textinformationsobjekte sind demnach wie in Fig. 2 strukturiert. All diese Textinformationsobjekte in dem Objektbaum 50 sind in der Liste 22 in dem Speicher 18 des Rundfunksenders 10 gespeichert. Sollte aus irgendeinem Grunde der Rundfunksender 10 den „NewsService Jouranline"- Dienst nicht anbieten kRnnen, kann das Objekt an der Wurzel des Objektbaums 50 auch ein Textobjekt sein, so dass der
Objektbaum 50 lediglich eine Hierarchieebene aufweist, wobei die Textinformationen in diesem Textobjekt beispielsweise auf den vorübergehenden Ausfall des Dienstes hinweisen.
Fig. 3 zeigt ein Ausführungsbeispiel für den Aufbau von Textinformationsobjekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Nach Figur 3 gliedert sich ein Textinformationsobjekt 100 in einen Objekt-Header-Abschnitt 100a und einen Objekt-Inhalt-Abschnitt 100b und ist maximal 2044 Bytes lang. Die maximale Länge ist nicht zwingend. Freilich wäre es auch mRglich unbegrenzte Längen zuzulas- sen. Sie ermRglicht es aber, dass die Abspeicherung der Objekte 100 sowohl empfangsseitig als auch sendeseitig auf einfache Weise in Arrays erfolgen kann, in denen die Objekte mit einem Versatz von 2044 Bytes oder einem Vielfachen davon zueinander angeordnet sind und damit einfach handhab- bar sind.
Der Objekt-Header-Abschnitt 100a gliedert sich beispielsweise wiederum seinerseits in einen 3 Byte langen Standard- Header lOOal und einen Erweiterungs-Header 100a2, wobei an- genommen wird, letzterer habe eine Länge von n Bytes, wobei n eine Ganzzahl grRßer gleich Null ist. Der Objekt-Inhalt- Abschnitt 100b ist m Byte lang, wobei m eine Ganzzahl grRßer Null ist.
Der Standard-Header 100a! zergliedert sich beispielsweise wieder in eine 2 Byte bzw. 16 Bit lange Objekt-ID 102, die beim Haupt-Objekt 52 (Figur 2) wie erwähnt 0x0000 betragen kann, und einen Objekt-Deskriptor 104, der die acht nied- rigwertigeren Bits des Standard-Headers 100 einnimmt. Die Anzahl von 16 Bits der Objekt-ID schränkt die Anzahl an vergebbaren IDs auf 216, also ungefähr 106, ein. Die Bits des Objekt-Deskriptors 104 haben verschiedene Bedeutung. Wie es bei 106 angedeutet ist, bilden die drei MSB (MSB = Most Significant Bits = hRchstwertige Bits) des Objekt- Deskriptors 104 eine Objekt-Typ-ID 108, die drei LSB (LSB = Least Significant Bits = niedrigstwertige Bits) einen Revisions-Index 110 und die beiden Bits dazwischen ein Static- bzw. Statisch-Flag 112 und ein Komprimierungsflag 114. Die Ob^ekt-Typ-ID 108 zeigt durch ihren Wert den Objekttyp des Textinformationsobjekts 100 an, wie es in nachfolgender Tabelle gezeigt ist.
Die Liste kann freilich jederzeit um neue Objekt-Typen ergänzt werden, die von bisherigen Empfangern zu ignorieren waren.
Wie es im Folgenden noch erRrtert werden wird, hat das Sta- tic-Flag die Bedeutung, dass es, wenn es gesetzt ist, dem Benutzer mRglich ist, die Objekt-ID 102 zu der Favoritenliste 46 hinzuzufügen. Das Static-Flag wird vom Textinforma- tions-Rundfunkdienst-Betreiber gesetzt oder nicht gesetzt, je nachdem, ob die Objekt-ID nur zufallig und temporar zugewiesen wird, also nur zeitlich begrenzt inhaltlich gleiche Informationen anzeigt, im welchem Fall ein Hinzufugen zu den Favoriten nicht sinnvoll wäre, oder ob die Zuweisung der Objekt-ID dauerhaft ist, und damit eine Favoriten- Hmzufugung sinnvoll wäre, wie es im Folgenden noch naher erRrtert werden wird.
Das Kompressionsflag 114 zeigt an, ob der Objekt-Inhalt- Abschnitt 100b auf vorbestimmte Weise komprimiert ist oder nicht. Der Revisions-Index wird von dem Dienstbetreiber ge¬ setzt, um bei den zyklisch wiederholt seriell übertragenen Textinformationsobjekten mit gleicher Objekt-ID anzugeben, um welche Version der Textinformation bzw. des Gegenstands, auf die sich diese Textinformationsobjekte beziehen, es sich handelt. Bei jeder Aktualisierung wird der Revisions- Index 110 sendeseitig inkrementiert . Betrifft beispielswei- se die Textinformation einer bestimmten Objekt-ID den Fußballspielstand eines Fußballspiels, das augenblicklich stattfindet, würde die Textinformation "0:0", die den Spielstand anzeigt, in den ersten Textinformationsobjekten mit dieser Objekt-ID zusammen mit dem Revisions-Index 000b (b für binär) übertragen werden, während nach einem Tor- schuss in dem Speicher 18 die Textinformation auf "0:1" geändert werden würde und gleichzeitig der Revisions-Index von 000b auf 001b geändert werden würde, so dass nachfolgend übertragene Texinformationsobjekt mit dieser Objekt-ID die Textinformation „0:1" und den Revisionsindex 001b hätten. Der Revisions-Index ermRglicht folglich, wie es im Folgenden noch näher erRrtert werden wird, dass empfangs- seitig Aktualisierungen abhängig davon durchgeführt werden kRnnen, ob sich der Revisions-Index von einem bereits emp- fangenen Textinformationsobjekt zu einem neu empfangenen Textinformationsobjekt geändert hat oder nicht, ohne inhaltlich analysieren zu müssen.
Die Objekt-ID wird sendeseitig mit Textinformationen ver- knüpft, die dann in dem Objekt-Inhalt-Abschnitt 10b enthalten sind, wie es im Folgenden noch erläutert werden wird. Wie bereits erwähnt, gibt es Objekt-IDs die zufällig und nur temporär vergeben werden, und bei denen das Static-Flag 112 nicht gesetzt ist, und solche, bei denen die Objekt-IDs fest mit einer Art von Textinformation (beispielsweise dem aktuellen Wetterbericht einer Stadt) verknüpft sind, die gegebenenfalls aktualisiert wird, wobei dann der Revisions- Index 110 inkrementiert wird. Der Erweiterungs-Header 100a2 stellt eine Erweiterungsoption für den Nachrichtendienst dar. Falls in den Datenanwen- dungssignalisierungsinformationen des Rundfunksystems, also den Steuerungsinformationen in dem Rundfunksignal neben den Audio-Informationen und den Textinformationen, angezeigt wird, dass der Erweiterungs-Header 100a2 zusätzliche Header-Informationen enthält, kann ein Empfänger, der nicht in der Lage ist, mit dem Erweiterungs-Header zu arbeiten, die- sen Abschnitt ohne weiteres ignorieren. Da die Anzeige in der Benutzung des Erweiterungs-Headers und den üblichen Da- tenanwendungssignalisierungsinformationen des Rundfunksystems erfolgt, ist die Länge des Erweiterungs-Headers 100a2 für alle Objekte des „NewsService Journaline" gleich.
Wie bereits erwähnt, sind der eigentliche Textinhalt bzw. die Textinformationen in den Textinformationsobjekten im Objekt-Inhalt-Abschnitt 100b enthalten. Die Textinformationen sind dabei beispielsweise in einer UTF-8Bit-Kodierung (ÜTF = Unicode Transformation Format) kodiert.
Bevor die Kodierung der Textinformationen und der weiteren Informationen in dem Objekt-Inhalt-Abschnitt 100b bezugnehmend auf Figur 4 näher veranschaulicht wird, wird im Fol- genden bezugnehmend auf Figur 6a bis 6d zunächst jeder Objekt-Typ näher beschrieben. Figur 6a bis 6d zeigen jeweils ein Beispiel für eine Bildschirmanzeige, wie sie sich je nach Objekt-Typ an der Anzeige 30 ergibt. Es sei erwähnt, dass die Beisiele von einer zur Darstellung von mehreren Zeilen auf einem Bildschirm fähigen Anzeige ausgehen, dass der Dienst aber freilich auch auf existierenden Autoradioanzeigen, die zumeist nur 1 Zeile mit 16 Zeichen anzeigen kRnnen, realisiert werden kann. Figur 6a zeigt den Bildschirmaufbau, wie er sich auf der Anzeige 30 bei Anzeige der Textinformationen eines Text- Objekts, d.h. mit Objekt-Typ-ID = 0x2, ergibt. Wie es zu sehen ist, gliedert sich eine Textinformation bzw. eine Nur-Text-Nachricht eines Text-Objekts in einen Titel 150 und den eigentlichen Text 152, den sog. TextkRrper. Zur Darstellung an den Benutzer werden der Titel 150 und der nachfolgende eigentliche Textabschnitt 152 auf dem Bild- schirm der Anzeige 30 mit automatischem Zeilenumbruch angezeigt bzw. aufbereitet. Der Benutzer kann vertikal durch den Text scrollen, beispielsweise durch Betätigung eines vertikal angeordneten Kippschalters oder dergleichen an dem Bedienfeld 34. Der Titel 150 ist an den Textabschnitt 152 angefügt, so dass derselbe gegebenenfalls zusammen mit dem übrigen Text 152 eventuell aus dem angezeigten Abschnitt der Anzeige 30 geschoben wird. Zur Anzeige kann jegliche Schriftart verwendet werden.
Genauer ausgedrückt wird es der Normalfall sein, dass die Menge an Textinformationen eines Textobjektes grRßer ist als eine anzeigbare Menge bzw. GrRße, so dass nur ein Teil der Textinformationen auf dem Bildschirm der Anzeige 30 angezeigt werden kann. Dieser anzeigbare Abschnitt wird durch Betätigung entsprechender Tasten am Bedienfeld 34 über Titel 150 und Text 152 verschoben. Diese MRglichkeit wird dem Benutzer durch entsprechende Pfeile am rechten Rand des Bildschirms der Anzeige 30 angezeigt, wie es in Figur 6a bei 154 und 156 zu sehen ist. Vorliegend liegt der anzeig- bare Abschnitt am Beginn der gesamten Textnachricht. Ein weiteres Scrollen nach oben ist nicht sinnvoll. Dies wird durch entsprechendes, beispielsweise farbliches Hervorheben des Pfeils 154, der nach oben weist, angedeutet. Entspre- chende Hervorhebung wird beim Pfeil 156 durchgeführt, wenn sich der anzeigbare Bereich bzw. Abschnitt am Ende der Nachricht befindet und deshalb ein Scrollen nach unten nicht mehr mRglich ist.
Figur 6b zeigt eine Nur-Titel-Nachricht bzw. ein Nur-Titel- Objekt (Objekt-Typ-ID = 0x3) . Nur-Titel-Nachrichten umfassen lediglich einen Titel 150, der auf dem Bildschirm der Anzeige 30 angezeigt wird. Ein Textabschnitt 152 bzw. Body- Text ist nicht vorgesehen. Zur Darstellung an den Benutzer wird der Titel-Text 150 auf dem Bildschirm der Anzeige 30 beispielsweise wieder mit automatischem Zeilenumbruch angezeigt. Gegebenenfalls kann der Benutzer durch den Text scrollen. Vorliegend kann jedoch der Titel vollständig auf dem Bildschirm der Anzeige 30 angezeigt werden, so dass durch Fehlen der Pfeile 154 und 156 dem Benutzer angezeigt wird, dass der Titel 150 vollständig angezeigt worden ist und keine Scroll-MRglichkeit besteht. Die Darstellung einer reinen Titelnachricht kann beispielsweise immer sowohl in Zeilen- als auch in vertikaler Richtung zentriert erfolgen. Als Schriftart ist wiederum jede gleich gut verwendbar.
Figur 6c zeigt eine Listen-Nachricht bzw. die Textinforma¬ tionen eines Listen-Objekts (Objekt-Typ-ID = 0x4). Eine Li- sten-Nachricht enthält einen Titel 160 und eine Liste von Textzeilen 162a bis 162d. Zur Darstellung an den Benutzer sollte der Titel im Unterschied zu den in Figur 6a gezeigten Textnachrichten immer auf dem Bildschirm der Anzeige 30 zu sehen sein, während der Benutzer durch die Zeilen 162a bis 162d von Informationen in dem KRrper-Abschnitt 162 scrollt. Es kann vorteilhaft sein, zur Darstellung von Listen-Objekten eine Schriftart zu verwenden, die einen gleichmäßigen Zeichenwiderholabstand in Zeilenrichtung auf- weist, um wie in dem Beispiel von Figur 6 zweispaltige Tabellen durch Vorsehen von Leerzeichen zu ermRglich. Falls der Titel 160 oder irgendeine Zeile 162a bis 162d eine Zeilenlänge des Bildschirms der Anzeige 30 überschreitet, wird dieser Listen-Punkt bzw. diese Listenzeile beispielsweise am Zeilenende abgeschnitten.
Figur 6a zeigt eine Menü- bzw. die Textinformation eines Menü-Objektes (Objekt-Typ-ID = 0x1) . Ein Menü enthält einen Titel 170 und eine Liste von Menü-Optionen 172a, 172b und 172 c. Jeder Menü-Option ist ein Verweis auf ein anderes Textinformationsobjekt zugeordnet, und zwar in Form einer Objekt-ID. Wie beim Listen-Objekt von Figur 6c kann der Benutzer durch die Menü-Optionen scrollen. Dabei wird immer eine der Menü-Optionen auf dem Bildschirm der Anzeige 30 hervorgehoben, in diesem Fall die Menü-Option 172b. Zeigt der Benutzer durch Drücken einer geeigneten Taste auf dem Bedienfeld 34, wie z.B. der Taste nach rechts, an, dass er zu dem Textinformationsobjekt will, auf das der Verweis der Menü-Option verweist, die gerade hervorgehoben ist, und dessen Inhalt durch den Text in der hervorgehobenen Zeile des Menüs mRglichst gut umschrieben wird, wie in dem vorliegenden Fall durch den Menü-Optionstext "Zweite Bundesliga 32. Runde", so wird, wie es im Folgenden beschreiben wird, die Textinformation dieses Textinformationsobjekts als Nächstes auf der Anzeige angezeigt, wodurch das augenblickliche Objekt bzw. die augenblickliche Textinformation auf dem Bildschirm der Anzeige 30 durch die neue ersetzt wird.
Genauer ausgedrückt besteht also eine Menü-Option aus einem Verweis auf ein anderes Textinformationsobjekt und einem Etikett, das eine Zeile auf dem Bildschirm der Anzeige 30 darstellt und den Inhalt des referenzierten Textinformationsobjekts bezeichnet bzw. betitelt oder umschreibt. Falls der Titel oder ein Etikett die Länge einer Zeile des Bildschirms der Anzeige 30 überschreitet, kRnnte der entspre- chende Inhalt abgeschnitten werden. Neben den entsprechenden Scroll-Pfeilen 156, 154 werden auf dem Bildschirm der Anzeige 30 in dem Fall eines Menü-Objekts durch eckige Klammern 174 Menü-Optionen hervorgehoben, die nicht sofort angezeigt werden kRnnen, da sie sich noch nicht im Cache- Speicher 32 befinden, wie es im Folgenden noch näher erRrtert werden wird.
Nachdem im Vorhergehenden bezugnehmend auf Figur 6 Beispiele für Textinformationen von Textinformations-Objekten un- terschiedlichen Objekt-Typs beschrieben worden sind, wird im Folgenden bezugnehmend auf Figur 4a-4e exemplarisch die Kodierung dieser Textinformationen im Objekt-Inhalt- Abschnitt 100b (Figur 3) beschrieben. Wegen der starken Limitierung der verfügbaren Bandbreiten gängiger Rundfunksy- steme für Datendienste werden bei der Generierung der zu übertragenden Textinformationsobjekte mRglichst effiziente Codierungen verwendet.
Der Objekt-Inhalt-Abschnitt gliedert sich normalerweise in einen Titel- und einen KRrper- bzw. Body-Abschnitt. Lediglich bei Nur-Titel-Objekten fehlt der Body-Abschnitt im Objekt-Inhalt-Abschnitt. Der Titel- und Body-Abschnitt jedes Objekts sind durch NML-Codes strukturiert (NML = NewsServi- ce Markup Language) , die den Anfang und das Ende eines be- stimmten Informationsblocks innerhalb des Objekt-Inhalt- Abschnitts anzeigen, wie z.B. des Titel- und des Body- Abschnitts . Innerhalb eines bestimmten Informationsblocks, wie z.B. des Titel- oder Body-Abschnitts, kRnnen Escape-Sequenzen vorgesehen sein, um Textformatierungs-Informationen einzubringen, wie z.B. Texthervorhebung, erzwungenen Zeilenumbruch, usw., sowie zusätzliche Funktionalitäten, wie z.B. Informationsbereiche, die durch Empfänger, die nicht in der Lage sind, mit der zusätzlichen Funktionalität umzugehen bzw. die diese zusätzliche Funktionalität nicht unterstützen, einfach ignoriert werden kRnnen.
Sowohl NML-Codes als auch Escape-Sequenzen sind Ein-Byte- Codes aus dem Bereich von 0x00 bis OxlF, sogenannte UTF-8- Steuercodes . Insbesondere umfassen die NML-Codes den Bereich von 0x00 bis OxOF und die Escape- bzw. Ausweich- Sequenzen einen Bereich von 0x10 bis OxlF.
Im Folgenden werden bezugnehmend auf die Beispiele von Figur 4a bis 4e Beispiele für Textinformationsobjekte (Figur 4a bis 4c) bzw. InformationsblRcke im Objekt-Inhalt- Abschnitt (Figur 4d und 4e) beschrieben.
Zunächst wird der NML-Code näher erläutert. Jeder Objekt- Abschnitt bzw. Objekt-Block in dem Objekt-Inhalt-Abschnitt wird mit einem NML-Code gestartet und durch entweder den NML-Code "End", das Auftreten eines weiteren NML-Codes oder das Ende des Objekt-Inhalt-Abschnitts beendet.
Die NML-Codes sind exemplarisch auf folgende Weise definiert :
0x00 sei der NML-Code für "Ende". Er wird verwendet, um einen Abschnitt bzw. Block innerhalb des Objekt-Inhalt- Abschnitts zu beenden, ohne dass ein weiterer Abschnitt bzw. weiterer Block begonnen wird. Er ist auf jeden Objekt- Typ anwendbar.
0x01 sei der NML-Code für "Titel" und zeigt durch sein Auf- treten in dem Objekt-Inhalt-Abschnitt 100b empfangsseitig den Beginn des Titel-Abschnittes bzw. Titel-Blockes an. Exakt ein Titel-Block muss pro Objekt für alle bisher definierten Objekt-Arten vorhanden sein, der NML-Code 0x01 also zumindest einmal im Abschnitt 100b auftreten. Der Titel- Block muss zudem der erste Block in dem Objekt-Inhalt- Abschnitt 100b sein. Der NML-Code 0x01 ist ebenfalls bei allen Objekt-Typen anwendbar.
0x02 sei der NML-Code für einen Menü-Options-Block-Beginn. Dieser Code stellt also den Anfang jeder Menü-Option in einem Menü-Objekt dar. Dieser Code ist folglich auch nur für Menü-Objekte vorgesehen. Auf das Auftreten des NML-Codes 0x02 hin erwartet der Empfänger bzw. ein in der Steuereinrichtung 26 vorgesehener Dekodierer (nicht gezeigt) in den nachfolgenden Bytes zunächst die Zieladresse bzw. den Verweis bzw. die Objekt-ID des Textinformationsobjekts, auf das verwiesen wird, und anschließend den Text der Menü- Option, der angezeigt werden soll und den Inhalt das refe- renzierten Objektes beschreibt. Pro Menü-Option eines Menü- Objekts tritt der Code 0x02 einmal in dem Objekt-Inhalt- Abschnitt auf. Genauer ausgedrückt, erwartet empfangsseitig der Dekodierer in der Steuereinrichtung 26, dass auf den Code 0x02 zwei Bytes folgen, die die Objekt-ID des referen- zierten Objekts angeben, d.h. des Objekts, das angezeigt werden soll, falls der Benutzer diese Menü-Option auswählt, und daraufhin noch n Bytes, die die anzuzeigende Menü- Options-Beschreibung anzeigen, die in einer Zeile des Menüs dem Benutzer angezeigt werden soll und ihm quasi die Auswahl unter allen Menü-Optionen ermRglichen soll.
Figur 4a zeigt beispielsweise ein Textinformationsobjekt für das Menü-Objekt von Figur 6a mit den NML-Codes 0x00 bis 0x02 zur Veranschaulichung. Wie bereits bezugnehmend auf Figur 3 beschrieben, beginnt das Objekt 100 mit einem Objekt-Header 100a, der vorliegend exemplarisch n Byte lang ist. Daraufhin folgt der Objekt-Inhalt-Abschnitt 100b. Das erste Byte des Objekt-Inhalt-Abschnitts 100b ist 0x01, d.h. der NML-Code, der den Beginn des Titel-Blocks anzeigt, dessen Textinhalt auf den NML-Code 0x01 an der Byte-Position 0+1 unmittelbar folgt und sich von Byte 0+2 bis Byte k erstreckt. In diesem Abschnitt 200 ist auf eine Weise, wie sie im Folgenden noch näher spezifiziert werden wird, der Titel des Menüs von Figur 6d gespeichert, nämlich "Sport- Deutschland-Fussball" . Der empfangsseitige Dekodierer weiß, wann der Titel 200 beendet ist, da, wie im Vorhergehenden erwähnt, die Textinformation des Titels nur mit Ein-Byte- bzw. Multi-Byte-UTF-8-CodewRrtern kodiert ist, die nicht NML-Codes oder Escape-Sequenzen sind. Sobald der empfangsseitige Dekodierer folglich beim Byte k+1 wie gezeigt auf den NML-Code 0x02 trifft, weiß er, dass dies der Beginn eines nächsten Blocks ist, nämlich des ersten Menü-Options- Blocks. Die darauffolgenden zwei Bytes k+2 und k+3 zeigen durch Objekt-ID OxAABB das nächste anzuzeigende Textinformationsobjekt an, in dem Fall, dass dieser Menüpunkt ausgewählt wird. Darauf folgt bei 202 innerhalb der Bits k+4 bis p die Textkodierung für die erste Menü-Option des Menü von Figur 6d, nämlich "Bundesliga 32. Runde". Hierauf folgt beim Byte p+1 wiederum ein NML-Code 0x02 zur Anzeige des Beginns eines Menü-Options-Blocks. Zur Veranschaulichung sind die Menü-Options-BIRcke noch einmal bei den Bezugszei- chen 204a, 204b und 204c angezeigt. Am Ende des Textinformationsobjekts 100 tritt der NML-Code 0x00 am Byte t+1 auf. Er zeigt das Ende von in diesem Fall dem gesamten Textinformationsobjekt 100 an. Dieser NML-Code 0x00 kann fehlen, wenn beispielsweise im Erweiterungs-Header die Länge des gesamten Textinformationsobjekts enthalten ist, so dass empfangsseitig durch entsprechende syntaktische Analyse das Ende des gesamten Objektes festgestellt werden kann.
Weiterhin sei 0x03 der NML-Code, der den Beginn eines Body- Blocks in dem Objekt-Inhalt-Abschnitt anzeige. Dieser enthält also den Text des TextkRrpers, der als der eigentliche Text in einem Text-Objekt angezeigt wird, also als 152 in Figur 6a beispielsweise. Lediglich ein Body-Block ist in jedem Objekt-Inhalt-Abschnitt mRglich und folglich auch nur das Auftreten von nur einmal 0x03. Der Code kommt nur bei Text-Objekten vor. Bei Nur-Titel-Objekten fehlt der NML- Code 0x03 im Objekt-Inhalt-Abschnitt, da diese keinen Text- kRrper aufweisen sondern nur einen Titel. Ein Kodierungs- beispiel für ein Titelinformations-Objekt ist in Figur 4b exemplarisch für das Text-Objekt von Figur 6a gezeigt. Der Body-Block ist bei 206 ersichtlich. Er besteht aus dem NML- Code 0x03 gefolgt von der UTF-8-Kodierung für den Body-Text 152, nämlich "Die Kassenlage der Kommunen ...".
Der NML-Code 0x04 zeige den Beginn eines Listenpunkt-Blocks in dem Objekt-Inhalt-Abschnitt an. Dieser Code tritt nur bei Listen-Objekten in dem Objekt-Inhalt-Abschnitt auf. In den Listenpunkt-BIRcken folgt auf dem NML-Code 0x04 die Ko- dierung für den Text, der für diesen Listenpunkt in einer Zeile der Liste auf dem Bildschirm der Anzeige angezeigt werden soll. Figur 4c zeigt ein Beispiel für eine Kodierung eines Textinformationsobjekts exemplarisch am Beispiel für das Listen-Objekt von Figur 6c. Die Listenpunkt-BlRcke sind mit 208a, 208b und 208c angezeigt.
Nachdem bezugnehmend auf die Figur 4a bis 4c verschiedene Ausführungsbeispiele für Textinformationsobjekte zur Veranschaulichung der NML-Codes beschrieben worden sind, wird bezugnehmend auf die Figuren 4d und 4e die Kodierung der Textinformationen in den einzelnen BlRcken 204a bis 204c, 206 und 208a bis 208c beschrieben.
Ein Block in dem Inhalt-Abschnitt kann mehrere Escape- Sequenzen aufweisen, die dem Benutzer nicht unmittelbar angezeigt werden sollen. Statt dessen kRnnen Escape-Sequenzen Aufbereitungshinweise für die Anzeige umfassen, wie z.B. einen Hinweis auf einen hervorzuhebenden Textabschnitt, einen erzwungenen Zeilenwechsel, einen bevorzugten Zeilenwechsel, usw., oder Abschnitte von Text markieren, der nicht zur direkten Bildaufbereitung vorgesehen ist, wie z.B. binären Code, also Dinge, die durch Empfänger, die nicht zur Verarbeitung dieser Datenabschnitte in der Lage sind, ignoriert werden müssen.
Escape- bzw. ESC-Codes kRnnen beispielsweise sein:
OxlB Datenab- tet werde soll, der nicht in der Lage schnitt- ist, den Datenabschnitt auszuwerten. Der Fortset- Datenabschnitt kann beispielsweise zung HTML/XML-Konforme Etiketten oder binäre Daten umfassen. Jeder dieser zwei Codes bzw. Codeworte wird durch ein Byte gefolgt, das die Länge des folgenden Datenabschnitts in "Anzahl von Bytes minus Eins" spezifiziert. Ein Beispielstext mit solchen Datenschnitten kRnnte beispielsweise lauten "dies ist ein <big> großartiger </big> Test!" (big = groß), wobei die Darstellung ohne "Datenabschnitf'-Escape-Sequenz "dies ist ein <big> großartiger </big> Test!" lauten würde und die beabsichtigte Darstellung auf einem einfachen Empfänger "dies ist ein großartiger Test!". Im er- steren Fall wäre folglich die Anzeige in der Lage, die in den Klammern angegebenen Befehle bei der Anzeige zu berücksichtigen und auszuführen, d.h. in diesem Fall das Wort "großartig" fettgedruckt oder auf andere Weise groß zu schreiben. Ein Beispiel für den Ausschnitt aus einem Objekt-Inhalt-Abschnitt, der diese Text- Sequenz kodiert, ist beispielsweise in Figur 4d gezeigt. Falls der Datenabschnitt mehr als 256 Bytes aufweist, wird der Escape-Code "Datenabschnitt-Fortsetzung" eingefügt, und zwar direkt nach dem vorhergehenden Datenabschnitt, um den Datenabschnitt um max. 256 Bytes mit jeder Wiederholung zu erweitern. Ein Kodierungsbeispiel hierfür ist in Figur 4e gezeigt. Die Ausführungsbeispiele von Figur 4d und 4e kRnnen folglich dafür verwendet werden, die Textpassagen in den BIRcken 204a bis 204c, 206 und 208a bis 208c für entsprechend ausgerüstete Empfänger mit entsprechenden Anzeigern auf spezielle Weise anzuzeigen.
OxlC ErweiteDiese Escape-Codes ermRglichen die Signarungs- lisierung von erweiterten Escape- Code BeSequenzen. Jeder dieser zwei Codes bzw. ginn CodewRrter wird gefolgt durch einen Er- OxlD Erweite- weiterte-Code-Wert, der ein Byte lang rungs- ist. Diese Erweiterte-Code-Werte sind für Code Ende zusätzliche Neuerungen vorgesehen, um für alte Empfänger abwärts-kompatibel zu sein. Falls ein "Erweiterungs-Code" in einer "Beginn"- und einer "Ende"-Version existiert, (z.B. wäre ein "Erweiterungs- Code-Wert" 0x00 = <bold> (bold = fettgedruckt) ) , mit der Notwendigkeit, sowohl <bold-Beginn> und <bold-Ende> zu signalisieren, wird derselbe "Erweiterungs-Code- Wert" verwendet: In dem ersten Fall wird mit dem "Erweiterungs-Code-Beginn"- Escape-Code fortgefahren, in dem zweiten Fall mit "Erweiterungs-Code-Ende"-Escape- Code . Falls ein "Erweiterungs-Code" lediglich ein einzelnen Code ohne eine explizite Beginn/Ende-Version enthält, soll immer mit dem "Erweiterungs-Code-Beginn"- Escape-Code fortgefahren werden. Falls ein Empfänger nicht in der Lage ist, "Erweiterungs-Codes" zu interpretieren, kann derselbe den "Erweiterungs- Code-Beginn/Ende"-Escape-Code (1 Byte) sowie den folgenden "Erweiterungs-Code- Wert" (1 Byte) ignorieren.
Bisher ist bezugnehmend auf die Figuren 2 bis 6 folglich der Aufbau der Textinformationsobjekte beschrieben worden. Die Textinformationsobjekte werden von dem Sender 10 in dem Rundfunksignal 16 übertragen, und in der Steuereinrichtung 26 mittels eines darin enthaltenen Dekodierers bzw. Parsers (nicht gezeigt) auf die bezugnehmend auf Figur 3 und 4 erläuterte Art und Weise syntaktisch analysiert. Zudem umfasst die Steuereinrichtung 26 eine nicht gezeigte Bildaufbereitungseinrichtung, die aus den syntaktisch analysierten Textinformationen in dem Objektinhalt-Abschnitt des anzuzeigenden Textinformationsobjekts geeignete Daten, wie z.B. Pixel-Daten generiert, die dann zur Anzeige 30 gesendet werden. Es ist jedoch darauf hingewiesen, dass die Aufteilung betreffend die Bildgenerierung bzw. -aufbereitung und Textextraktion aus dem anzuzeigenden Textinformations- Objekt auch anteilig auf die Anzeige 30 verlagert sein kann, oder dass eigens vorgesehene Module zwischen Steuereinrichtung 26 und Anzeige 30 geschaltet sind.
Während sich die Figuren 3 und 4 mit dem Aufbau eines einzelnen Textinformationsobjekts beschäftigten, wird bezug- nehmend auf Figur 5 beschrieben, in welcher Reihenfolge die Textinformationsobjekte in dem Rundfunksignal 16 übertragen werden. Figur 5 zeigt exemplarisch in einer Zeile 300 einen Ausschnitt aus einem Rundfunksignal 16. Mit einem Pfeil 302 ist angedeutet, welcher Teil des Rundfunksignals 16 früher bzw. später ausgestrahlt wird, d.h. gemäß Figur 5 der linke Teil vor dem rechten Teil. Innerhalb des Rundfunksignals 300 sind durch BlRcke einzelne Textinformationsobjekte angedeutet. Jedes Textinformationsobjekt ist nummeriert. Die Nummer sei die dem Textinformationsobjekt zugeordnete Ob- jekt-ID.
Obwohl das in Figur 5 so dargestellt ist, als ob die Text¬ informationsobjekte zeitlich hintereinander ausgestrahlt werden würden, ist es freilich mRglich, dass die Ausstrah- lung einzelner Textinformationsobjekte zeitlich quasigleichzeitig erfolgt. Trotzdem ist unter den Textinformationsobjekten jedenfalls eine Reihenfolge definiert, nämlich durch die serielle Weiterleitung der ausgestrahlten und an der Antenne 38 empfangenen Textinformationsobjekte durch den Empfänger 12, so dass die Darstellung in Figur 5 auch für diesen Fall anwendbar ist. Die Textinformationsobjekte sind in dem Rundfunksignal 300 folglich in einer gewissen Reihenfolge aufeinander folgend angeordnet. Der Sender 10 strahlt jedes Textinformationsobjekt je nach Priorität mit einer gewissen Häufigkeit wiederholt aus. In der Figur 5 beispielsweise das Textinformationsobjekt mit der Objekt-ID 1 mit der Wiederhol-Zeitdauer τ1 und das mit der Objekt-ID 25 mit τ25- Die Häufigkeit bzw. Wiederhol-Zeitdauer richtet sich nach der zu erwartenden Häufigkeit, mit der das jeweilige Textinformationsobjekt durch Benutzer von Endgeräten gewünscht wird, d.h. für Wetternachrichten häufiger als für spezielle Nachrichten aus In- oder Ausland. Der Dienst- betreiber aktualisiert hierzu ständig die Textinformationsobjekte in dem Speicher 18. Dies bedeutet zum einem das Hinzufügen von Textinformationsobjekten zu der Liste 22 mit Vergabe neuer Objekt-IDs. Damit einhergehen muss allerdings auch die Änderung mindestens eines Menü-Objektes, das näm- lieh nun einen weiteren Menüpunkt bzw. eine weitere Menü- Option mit einem Verweis auf dieses neue Textinformationsobjekt aufweisen muss. Es erfolgt deshalb auch eine Änderung des entsprechenden Eintrags in der Liste 22 an der entsprechenden Objekt-ID dieses geänderten Menü-Objektes. Es sei beispielsweise das Objekt mit der Objekt-ID 1 in Figur 5 dieses zu verändernde Menü-Objekt, so würde es sich bei der nächsten Ausstrahlung nach der Zyklus-Zeitdauer τx verändert haben, und, wie im Vorhergehenden beschrieben, würde insbesondere der Revisions-Index inkrementiert sein. Ist in Figur 5 beispielsweise das Textinformationsobjekt
304 mit der Objekt-ID 1 das Textinformationsobjekts, dessen Textinformationen gerade auf der Anzeige 30 angezeigt werden, und das Textinformations-Objekt 306 mit ebenfalls der Objekt-ID 1 das soeben von dem Empfänger 12 empfangene Tex- tinformationsobjekt, dann kann der Empfänger anhand des
Revisions-Index des Textinformations-Objekts 306 und Vergleich desselben mit dem Revisions-Index des Textinformati- ons-Objekts 304 bestimmen, ob eine Aktualisierung notwendig ist oder nicht. Innerhalb einer gewissen, in Figur 5 nicht dargestellten, Gesamtwiederhol-Zeitdauer wird jedes Textinformationsobjekt zumindest einmal ausgestrahlt.
Es sei darauf hingewiesen, dass aus der Beschreibung von
Fig. 5 deutlich wird, dass in der vorliegenden Beschreibung der Begriff „Textinformationsobjekt" doppeldeutig verwendet wird: er bezeichnet einerseits ein Objekt, das in dem Rundfunksignal übertragen wird, aber andererseits auch alle Ob- jekte mit einer speziellen Objekt-ID. So sind genau genommen in Fig. 2 nicht Textinformationsobjekt in der Baumstruktur angeordnet, sondern Objekt-IDs. Jede Objekt-ID steht stellvertretend für mehrere, nacheinander ausgestrahlte Textinformationsobjekte, und zwar die mit der ent- sprechenden Objekt-ID. Diese müssen ihrerseits nicht alle identisch sein, sondern kRnnen im Laufe der Zeit aktualisiert werden. Trotz alledem geht jeweils aus dem Sinnzusammenhang hervor, in welcher Art der Ausdruck „Textinformationsobjekt" gerade verwendet worden ist.
Nachdem nun im Vorhergehenden bezugnehmend auf die Figuren 1 bis 6 der „NewsService Journaline"-Dienst beschreiben worden ist, inklusive des Aufbaus der Textinformations- Objekte und der Art und Weise ihrer Ausstrahlung, wird im Folgenden die Funktionsweise des Empfängers 12 anhand der Figuren 7 bis 13 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung näher beschrieben.
Figur 7 zeigt, wie die Steuereinrichtung 26 in einem Anzei- ge-Aktualisierungs-Prozess ein soeben empfangenes Textinformationsobjekt daraufhin untersucht, ob eine Aktualisie¬ rung des Bildschirminhalts der Anzeige 30 durchgeführt werden soll oder nicht. Auf den Eingang eines Textinformati- onsobjekts hin überprüft nun die Steuereinrichtung 26 in einem Schritt 400 zunächst, ob die Objekt-ID eines aktuell empfangenen Textinformationsobjekts zu der Objekt-ID eines aktuell angezeigten Textinformationsobjektes identisch ist. Dies würde bedeuten, dass das neu empfangene Textinformationsobjekt eventuelle Änderungen zu dem älteren, aktuell angezeigten beinhalten kRnnte. Ergibt der Vergleich in Schritt 400 keine Identität, endet der Anzeige- Aktualisierungs-Prozess bei 402, um bei Empfang des näch- sten empfangenen bzw. nachfolgenden Textinformationsobjekts wieder zu beginnen. Liegt Identität bei Schritt 400 vor, wird in Schritt 404 durch die Steuereinrichtung 26 geprüft, ob sich der Revisions-Index (110 in Figur 3) in dem aktuell empfangenen und dem aktuell angezeigten Textinformationsob- jekt gleicht. Ist dies der Fall, bedeutet dies, dass empfangsseitig davon ausgegangen werden kann, dass sich inhaltlich keine Änderungen bezüglich dieser Objekt-ID ergeben haben. Auf Feststellung der Identität in Schritt 404 hin endet folglich der Anzeige-Aktualisierungs-Prozess bei 406, um mit dem unmittelbar nachfolgend empfangenen Textin- formationsobjekt wieder zu beginnen. Liegt jedoch Ungleichheit in Schritt 404 vor, überprüft die Steuereinrichtung 26 in einem Schritt 408 die Objekt-Typ-ID (108 in Figur 3) , und zwar entweder des aktuell empfangenen oder des aktuell angezeigten Textinformationsobjekts, daraufhin, ob dasselbe einen Listen-, Menü- oder Nur-Titel-Objekt-Typ anzeigt, d.h. 0x1, 0x3 oder 0x4 ist. Ist dies der Fall, wird in einem Schritt 410 nunmehr das neu empfangene Textinformationsobjekt auf der Anzeige 30 angezeigt, wodurch die Textin- formation auf der Anzeige 30 aktualisiert wird.
Bei der Aktualisierung in Schritt 410 sorgt eine Anzeige- Steuerung (nicht gezeigt) dafür, dass die aktuelle Scroll- Position des Benutzers beibehalten wird. Das verhindert, dass der Benutzer, der in einer Liste oder einem Menü gerade mühsam einen Teil durchscrollt bzw. durchforstet hat, bei Aktualisierung wieder von Neuem beginnen muss. Bei ei- nem Menü-Objekt führt die Aktualisierung von Schritt 410 folglich dazu, dass eine Menü-Options-Zeile des Menüs vor der Aktualisierung, wie z.B. die Zeile 172b in Figur 6d, auch nach der Aktualisierung dieselbe Bildschirmposition aufweist, vorausgesetzt, dass das neue Menü-Objekt genügend Zeilen bzw. genügend Menü-Optionen aufweist bzw. dass es überhaupt diese Menü-Option noch aufweist. In dem Fall eines Listen-Objekts führt die Aktualisierung nach Schritt 410 entsprechend dazu, dass eine Listen-Zeile der Liste vor der Aktualisierung an derselben Bildschirmposition ange- zeigt wird, wie nach der Aktualisierung, vorausgesetzt, dass das neue Listen-Objekt genügend Zeilen aufweist. Beispielsweise wird die Aktualisierung von Schritt 410 derart durchgeführt, dass die so und so vielte Menü-Option bzw. so und so vielte Listen-Zeile an derselben Bildschirmposition vor und nach der Aktualisierung erscheint. Dies bedeutet auch, dass der anzeigbare Bereich vor und nach der Aktualisierung zumindest teilweise überlappt, so dass Verwirrungen beim Benutzer bei einer Aktualisierung vermieden werden.
Alternativ kann für die Prüfung auf Gleichheit eines Eintrags im neuen Objekt mit dem aktuell angezeigten Eintrag des gerade angezeigten Objekts auch beispielsweise die OB- jekt-ID des Menü-Eintrags oder der Text des Menü- oder Listen-Eintrags herangezogen werden.
In dem Fall eines Nur-Titel-Objektes kann es in Schritt 410 jedoch vorgesehen sein, einfach den aktualisierten Textinhalt des neu empfangenen Objektes wie ein neues Objekt mit neuer Objekt-ID einfach von vorn anzugeigen, da ja Nur- Titel-Nachrichten ohnehin per Definition keinen grRßeren TextkRrper aufweisen. Ein eventuelles erneutes „Bild- schirmscrollen" schadet also nicht.
Bei Listen-, Menü- und Nur-Titel-Objekten geschieht die Aktualisierung nach 410 folglich unmittelbar, automatisch und ohne, dass der Benutzer seine Zustimmung geben muss. Bei Text-Objekten kann es jedoch mühsam sein, wenn der Benutzer aus seiner augenblicklichen Lese-Position in einem Fließtext wieder an den Anfang zurückversetzt wird oder der aktuell ausgelesene Inhalt im aktualisierten Objekt gar nicht mehr enthalten ist. Deshalb wird in dem Fall, dass die Prüfung bei 408 ergibt, dass es sich bei dem aktuell angezeig- ten oder dem aktuell empfangenen Textinformations-Objekt nicht um eine Listen-, Menü- oder Nur-Titel-Objekt handelt, sondern demnach um ein Text-Objekt, in einem Schritt 410 der Benutzer wie z.B. über eine Anfrage über die Anzeige 30 oder aber über ein blinkendes Lämpchen, ein blinkendes „Ak- tualisierung" auf dem Bildschirm der Anzeige 30 oder eine andere Einrichtung, darüber informiert, dass eine aktualisierte Version dessen vorliegt, was er gerade liest. Der Benutzer wird hierdurch gleichzeitig angefragt, ob er eine Aktualisierung wünscht oder eine solche vermeiden mRchte bzw. ablehnt. Die Zustimmung kann der Benutzer über das Be¬ dienfeld 34 zum Ausdruck bringen, wie z.B. durch Drücken einer gewissen Taste, oder aber durch eine andere Bestätigungseinrichtung. Die Ablehnung kann in einer Keine- Reaktion-Betätigung bzw. -Bedienung bestehen, wie z.B. das Nicht-Drücken einer Taste. Die MRglichkeit, dass der Benutzer seine Zustimmung zum Ausdruck bringt, kann auch zeitlich begrenzt werden, wie z.B. durch eine Zustimmungs- HRchstzeitdauer . In einem Schritt 412 überprüft die Steue- rungseinrichtung, ob der Benutzer Zustimmung erteilt oder nicht erteilt. In dem Fall, dass der Benutzer eine Aktualisierung ablehnt, endet der Anzeige-Aktualisierungs-Prozess bis zu seinem Neubeginn bei 414. Anderenfalls erfolgt 416 eine Anzeige-Aktualisierung. Die Anzeige-Aktualisierung in Schritt 416 erfolgt jedoch ohne Beibehaltung der aktuellen Anzeigeposition wie bei Schritt 410, sondern vorzugsweise wie bei Anzeige eines Textinformationsobjektes mit neuer Objekt-ID von Beginn an, d.h. in bis an den Anfang ges- crollter Position.
Figur 8 zeigt einen weiteren Prozess, der durch die Steuereinrichtung 26 ständig bei Eintreffen eines neu empfangenen Textinformationsobjekts ausgeführt wird. Der Prozess von Figur 8 ist ein Cache-Aktualisierungs-Prozess . Der Cache- Aktualisierungs-Prozess von Figur 8 dient dazu, dass der Empfänger 12 stets zumindest einen Teil der bereits empfangenen Textinformationsobjekte, genauer gesagt für jede Objekt-ID das Textinformations-Objekt mit der neuesten ver- fügbaren Version, für eine schnelle Anzeige bzw. einen schnellen Zugriff aufweist. Zur Cache-Aktualisierung prüft die Steuereinrichtung 26 im Cache-Aktualisierungsprozess zunächst in einem Schritt 450 anhand der Objekt-ID des neu empfangenen Textinformationsobjekts, ob ein Textinformati- onsobjekt mit dieser Objekt-ID in der Liste 22 in dem Spei¬ cher 32 enthalten ist. Falls dies der Fall ist, d.h. in dem Fall eines Cache-Treffers, wird in einem Schritt 452 überprüft, ob sich der Revisions-Index des neu empfangenen Textinformationsobjektes von dem Revisions-Index des Text- informationsobjekts unterscheidet, der im Speicher 32 gespeichert ist und dieselbe Objekt-ID aufweist. Ergibt der Schritt 452 die Identität der beiden Revisions-Indizes, endet der Cache-Aktualisierungs-Prozess bei 454, um bei Ein- treffen des nachfolgenden Textinformationsobjekts wieder von vorn zu beginnen. Ergibt die Überprüfung in Schritt 452, dass sich der Revisions-Index des neu empfangenen Textinformationsobjekts von dem in dem Cache-Speicher 32 unterscheidet, erfolgt in Schritt 456 die Ersetzung des entsprechenden Eintrags in der Liste 42 durch das neu empfangene Textinformationsobjekt.
Ergibt der Schritt 450 jedoch, dass in der Liste 42 des Ca- che-Speichers 32 kein Eintrag mit einer solchen Objekt-ID vorhanden ist, d.h. einen Cache-Fehlschlag, überprüft die Steuereinrichtung 26 in einem Schritt 458, ob der für die Liste 42 in dem Speicher 32 vorgesehene Speicherplatz voll ist, oder ob noch genügend Speicherplatz vorhanden ist, um einen Eintrag in der Liste 42 vorzunehmen. Ist der Cache nicht voll, so trägt in einem Schritt 460 die Steuereinrichtung 26 das neu empfangene Textinformationsobjekt in der Liste 22 bzw. dem Cache-Speicher 32 ein. Dies wird jedoch nur in einer Anfangsphase nach dem Einschalten des Empfängers 12 bzw. der „NewsService Journaline"-
Funktionalität des Empfängers 12 der Fall sein. Nach einer gewissen Zeit wird der Cache-Speicher 32 voll sein. In diesem Fall überprüft in einem Schritt 462 die Steuereinrichtung 26 nach einer gewissen Cache-Verdrängungs-Strategie, wie sie im Folgenden bezugnehmend auf Figur 9 näher erläutert werden wird, ob in dem Cache-Speicher 32 in der Liste 42 ein Textinformationsobjekt existiert, das eine niedrigere Cache-Priorität aufweist, als das neu empfangene. Die Überprüfung 462 berücksichtigt die Baumstruktur der Textin- formationsobjekte und definiert unter den Textinformationsobjekten eine Prioritäts-Reihenfolge je nachdem, ob auf dieselben durch das aktuell angezeigte Textinformationsobjekt oder ein Textinformationsobjekt in dem Datenpfad zwi- sehen dem Wurzel-Objekt bzw. Haupt-Objekt und dem aktuell angezeigten Textinformationsobjekt verwiesen wird oder nicht, bzw. allgemeiner ausgedrückt, aufgrund seiner Position in der Baumstruktur bzw. seiner relativen Lage zu dem aktuell angezeigten Textinformationsobjekt innerhalb der Baumstruktur. Zusätzlich kann zwischen Objekten gleicher Cache-Priorität der Zeitpunkt des letzten Empfangs oder inhaltlichen Updates bzw. die Häufigkeit des Empfangs bzw. der inhaltlichen Updates ausgewertet werden.
Um dies zu veranschaulichen, ist in Figur 9 noch einmal exemplarisch ein Objektbaum dargestellt, wobei Menü-Objekte wiederum mit M und Text-Objekte mit T gekennzeichnet sind. Alle Menü-Objekte sind durch eine Nummer am linken unteren Eck nummeriert, welche die Objekt-ID angebe. Das aktuell angezeigte Textinformationsobjekt sei das Text-Objekt mit der Objekt-ID 100. Es befindet sich in der vierten Hierarchieebene. Um durch Verweise von dem Haupt-Objekt mit der Objekt-ID 0 zu dem aktuell angezeigten Text-Objekt mit der Objekt-ID 100 zu gelangen, musste der Benutzer die Textinformationsobjekte bzw. die Menü-Objekte mit der Objekt-ID 3 in der zweiten Hierarchieebene und der Objekt-ID 12 in der dritten Hierarchieebene durchlaufen. Die Folge von Objekt- IDs der Textinformationsobjekte von dem Haupt-Objekt mit der Objekt-ID 0 bis einschließlich des aktuell angezeigten Objekts mit der Objekt-ID 100, mit den auf dem Weg in dem Objektbaum zwischen denselben liegenden Menü-Objekten bilden den Objekt-Pfad 44, den der Empfänger 12 in dem Speicher 32 speichert, und auf den später noch näher eingegan- gen wird. Er wird eigentlich angelegt, um dem Benutzer das Zurückkehren in hRhere Menü-Ebenen zu ermRglichen, und deshalb auch zu jedem „Favoriten" abgespeichert. In vorliegendem exemplarischen Fall lautet der Objekt-Pfad {0, 3, 12, 100}. Alle Objekte, deren Objekt-ID in dem Objekt-Pfad 44 (Figur 1) enthalten sind, sind in Figur 9 durch eine gestrichelte Linie umkreist. Durch eine Strichpunkt-Linie sind in Figur 9 zusätzlich zu den Objekt-Pfad-Objekten alle Objekte umrahmt, auf die durch zumindest eines der Objekte in dem Objekt-Pfad verweisen wird; dies sind in dem Beispiel von Figur 9 die Objekte mit den Objekt-IDs 1, 2, 4, ..., 9, 13. Lediglich exemplarisch war das aktuell angezeigte Textinformations-Objekt in dem Beispiel von Figur 9 ein Text-Objekt. Wäre es ein Menü-Objekt wären durch die Strichpunkt-Linie auf Objekte eingeschlossen, die sich in der fünften Hierarchieebene des Objektbaumes befinden.
Die Cache-Verdrängungs-Strategie, nach welcher eine Priori- täts-Reihenfolge unter den Objekten festgelegt wird, läuft nun folgendermaßen:
1. Niedrigste Priorität haben Textinformations-Objekte, die sich außerhalb der Strichpunkt-Linie befinden, d.h. Textin- formations-Objekte, auf die nicht durch zumindest eines der Textinformationsobjekte in dem Objektpfad (angezeigt durch die gestrichelte Linie) verwiesen wird. Dies sind bei dem Beispiel von Figur 9 die Textinformationsobjekte 10, 11, 14 bis 20.
2. NächsthRhere Priorität besitzen Textinformations- Objekte, die sich zwischen der Strickpunkt-Linie und der gestrichelten Linie befinden. Dies sind also die Objekte, die sich nicht auf dem Objekt-Pfad befindet, auf die aber zumindest durch ein Objekt in dem Objekt-Pfad verwiesen wird. 2.1. Unter diesen Objekten ist wiederum eine Prioritäts- Reihenfolge definiert, derart, dass Objekte einer hRhe- ren Hierarchieebene eine hRhere Priorität aufweisen als solche einer niedrigeren Hierarchieebene, d.h. in dem Beispiel von Figur 9 das Objekt mit der Objekt-ID 13 eine hRhere Priorität als die mit dem Objekt-IDs 1, 2, 4 bis 9.
2.2 Unter denen gleicher Priorität sollten dann wie- derum Menü-Objekte hRherer Priorität aufweisen als die übrigen Objekt-Typen. Das Objekt mit der Objekt- ID 2 hätte folglich geringere Priorität als die Objekte mit den Objekts-ID 1, 4 bis 9. 2.3 Unter den Verbleibenden mit gleicher Priorität kRnnte wiederum eine Prioritäts-Reihenfolge dadurch definiert werden, dass Objekten, bei denen das Static-Flag gesetzt ist, eine hRhere Priorität zugewiesen wird, als solchen mit nicht gesetzten Static-Flag.
3. NächsthRhere Priorität umfassen wiederum die Menüs bzw. Objekte im Objekt-Pfad, vorliegend folglich die Objekte mit den Objekt-IDs 0, 3, 12 und 100. Unter diesen kRnnte wieder eine Prioritäts-Reihenfolge in Abhängigkeit von der Hierarchieebene definiert werden.
Es kRnnte ferner vorgesehen werden, dass abweichend von der vorhergehend dargestellten Verdrängungs-Strategie spezielle Objekte, und zwar mit Objekt-IDs, die in der Favoritenliste 46 in dem Speicher 32 enthalten sind, die hRchste Priorität aufweisen. HRchste Priorität aufweisen kRnnten ferner diejenigen Objekte, auf die durch das aktuell angezeigte Ob- jekt, d.h. mit der Objekt-ID 100 verwiesen wird. Ferner kRnnten Objekte in der Strichpunktlinie alle gleich behandelt werden, also auch die Objekte des Objekt-Pfades gleich behandelt werden wie die Objekte, auf die sie verweisen, d.h. Punkt 3 würde fehlen.
Zurückkehrend zu Figur 8 endet der Cache-Aktualisierungs- Prozess bei 464, wenn bei Schritt 462 festgestellt wird, dass in dem Cache-Speicher kein Objekt mit niedrigerer Ca- che-Priorität existiert. Existiert ein solches, wird bei Schritt 466 das Objekt mit niedrigster Priorität durch das aktuell empfangene Objekt ersetzt. Auch wenn mehrere Objekte gleicher Priorität im Speicher diejenigen mit geringster Priorität sind, sollte ältest-empfangenes ersetzt werden.
Figur 10 zeigt einen Prozess, der durch die Steuereinrichtung 26 durchgeführt wird, wenn ein Benutzer am Bedienfeld 34 während der Anzeige eines Textinformationsobjekts an der Anzeige 30 Tasten betätigt, die zum Scrollen vorgesehen sind, wie z.B. die Pfeil-nach-oben- und Pfeil-nach-unten- Taste. In diesem Fall verschiebt die Steuereinrichtung 26 in einem Schritt 500 den anzuzeigenden Textausschnitt der Textinformationen des aktuell angezeigten Objekts nach unten bzw. nach oben, falls dies noch mRglich ist. Im Fall der Menü- und Listen-Objekte, wird, wie beschrieben, der Titel immer auf dem Bildschirm der Anzeige angezeigt.
Figur 11 zeigt einen Prozess, der durch die Steuereinrichtung 26 ausgeführt wird, wenn bei angezeigtem Textinforma- tionsobjekt der Benutzer eine Auswahltaste betätigt, die eine eigens vorgesehene Taste auf dem Bedienfeld 34 sein kann, oder beispielsweise die Pfeil-nach-rechts-Taste ist. Bei Betätigung dieser Taste bzw. Auswahleinrichtung prüft die Steuereinrichtung 26 in einem Schritt 550, ob es sich bei dem aktuell angezeigten Textinformations-Objekt um ein Menü-Objekt handelt oder nicht. Ist dies nicht der Fall, ist die Auswahltaste nicht belegt, d.h. ihr ist keine Funktion zugewiesen, und der Prozess von Figur 11 endet bei 552. Handelt es sich um ein Menü-Objekt, so schlägt in einem Schritt 554 die Steuereinrichtung 26 im Speicher 32 nach, ob darin ein Objekt mit einer Objekt-ID enthalten ist, die der hervorgehobenen Menü-Option zugeordnet ist (vgl. 172b in Figur 6d) . Ist dies der Fall, d.h. in dem
Fall eines Cache-Treffers, ändert in einem Schritt 556 die Steuereinrichtung 26 die anzuzeigende Textinformation auf die des in dem Cache-Speichers 32 enthaltenen Objekts. Da der Zugriff auf den Cache-Speicher 32 schnell ist, voll- zieht sich die Bildschirmänderung an der Anzeige 30 für den Benutzer folglich unmerklich, d.h. unmittelbar. Ergibt das Nachschlagen bei 554 jedoch einen Cache-Fehlschlag, wartet in einem Schritt 558 die Steuereinrichtung 26 darauf, dass in dem Rundfunksignal 16 ein Objekt mit der gesuchten Ob- jekt-ID ausgestrahlt wird. Während des Schritts 558 werden alle andern Prozesse natürlich wie üblich durchgeführt, insbesondere die Prozesse von Figur 7 und Figur 8 an den inzwischen eingehenden Objekten. Sobald das Objekt mit der gesuchten Objekt-ID empfangen wird, ändert die Steuerein- richtung 26 in einem Schritt 560 die anzuzeigende Textinformation an dem Bildschirm der Anzeige 30 auf die des aktuell empfangenen Objekts mit der gesuchten Objekt-ID. Nach den Schritten 560 bzw. 556 wird in einem Schritt 562 eine Objekt-Pfad-Aktualisierung durchgeführt, wie sie in Figur 12 detaillierter dargestellt ist.
Figur 12 stellt den Objekt-Pfad-Aktualisierungs-Prozess von Schritt 562 dar. In einem Schritt 580 wird zunächst durch die Steuereinrichtung 26 in dem Speicher 32 nachgeschlagen, ob die neue Objekt-ID, d.h. die Objekt-ID des nun neu auf der Anzeige 30 angezeigten Objekts, die der angewählten Menü-Option zugeordnet war, bereits in den Objekt-Pfad 44 e- xistiert. Falls dies der Fall wäre, würde das einfache
Hinzufügen der neuen Objekt-ID an das Ende der Objekt-Pfad- Liste von Objekt-IDs zu einer zirkulären Referenz führen. Führt der Nachschlag in Schritt 580 folglich zu einem Treffer, sorgt die Steuereinrichtung 26 in einem Schritt 582 dafür, dass die Objekt-Pfad-Liste 44 bis zu dieser Objekt- ID gelRscht wird, d.h. um mit dieser Objekt-ID zu enden. Anderenfalls, d.h. in dem Fall eines Fehlschlags beim nachschlagenden Schritt 580, wird in einem Schritt 584 die neue Objekt-ID an das Ende der Objekt-Pfad-Liste 44 angefügt, falls nicht der Objektpfad längenlimitiert ist und bereits seine maximale Länge erreicht hat.
Die Verwaltung der Objekt-Pf d-Liste 44 ist dazu vorgesehen, um eine Menü-Zurück-Funktionalität zu ermRglichen, wie es bezugnehmend auf Figur 13 näher erläutert wird, die einen Prozess veranschaulicht, den die Steuereinrichtung 26 auf das Drücken einer Zurück-Taste, wie z.B. der NachLinks-Taste auf dem Bedienfeld 34, ausführt, wenn gerade ein Textinformationsobjekt an der Anzeige 30 angezeigt wird. In diesem Fall nämlich ermittelt die Steuereinrichtung 26 in einem Schritt 600 aus der Objekt-Pfad-Liste 44 diejenige Objekt-ID, die in dem Objekt-Pfad der Objekt-ID des aktuell angezeigten Objekts unmittelbar vorausgeht, und dessen Objekt folglich auf dieselbe verweist. Kurz bezug- nehmend auf Figur 9, würde beispielsweise das Drücken der Zurück-Taste dort dazu führen, dass in dem Schritt 600 die Objekt-ID 12 ermittelt werden würde. Daraufhin schlägt in einem Schritt 602 die Steuereinrichtung 26 in dem Speicher 32 nach einem Objekt mit dieser Objekt-ID nach. In dem Fall eines Cache-Treffers ändert die Steuereinrichtung 26 in einem Schritt 604 die anzuzeigende Textinformation auf die des in dem Cache-Speicher 32 enthaltenen Objekts. Anderen- falls, d.h. in dem Fall eines Fehlschlags, wartet die Steuereinrichtung 26 in einem Schritt 606, bis in dem Rundfunksignal 16 ein Objekt mit der gesuchten Objekt-ID ausgestrahlt wird, woraufhin sich wie in einem Schritt 608 die anzuzeigende Textinformation auf die des aktuell empfange- nen Objekts mit gesuchter Objekt-ID ändert. Nach den
Schritten 604 und 608 aktualisiert die Steuereinrichtung 26 in einem Schritt 610 die Objekt-Pfad-Liste 44 durch Kürzen derselben um die letzte Objekt-ID, nämlich die Objekt-ID des Textinformationsobjektes, das vor der Änderung 604, 608 angezeigt worden ist.
Es wird natürlich, wie in Fig. 13 auch angezeigt, vor dem Schritt 600, in einem Schritt 612 geprüft, ob der Objekt- ID-Pfad 44 überhaupt mehr als eine Objekt-ID aufweist. Die Länge wäre eins, wenn sich der Benutzer gerade im Hauptmenü (d.h. z.B. 0x0000) befände. Wäre dies der Fall bliebe die Betätigung der Menü-Zurück-Taste ohne Folgen und der Prozeß endete bei 614. Nur anderenfalls begänne der Prozeß bei 600 wie oben beschrieben zu laufen.
Gemäß dem Ausführungsbeispiel von Figur 14 weist der Empfänger 12 eine Favoriten-Funktionalität auf, um ea einem Benutzer zu ermRglichen, bestimmte Menü- oder Nachrichten- Objekte für einen schnellen und direkten zukünftigen Zugriff zu speichern, indem denselben beispielsweise im Cache-Speicher die hRchste Priorität zugewiesen wird. Zur Realisierung der Favoriten-Funktionalität umfasst der Empfänger 12 beispielsweise eine eigens vorgesehene Taste, durch deren langes Drücken der Benutzer seinen Wunsch zum Ausdruck bringen kann, die Objekt-ID des aktuell angezeig- ten Textinformationsobjekts der Favoriten-Liste hinzuzufügen, während kurzes Drücken derselben Taste dazu führt, dass die Steuereinrichtung die Favoriten-Objekt-ID in dem Favoriten-Speicher für das nächste anzuzeigende Textinformationsobjekt heranzieht. Freilich kRnnen auch andere Ein- richtungen vorgesehen sein, mit denen der Benutzer eine Favoriten-Hinzufügung oder einen Favoriten-Aufruf hervorrufen kann. Figur 14 stellt einen Favoriten-Hinzufügungs- Tastenaktivierungs-Steuerungsprozess dar. Zeigt der Benutzer den Wunsch des Hinzufügens an, wird in einem Schritt 700 durch die Steuerungseinrichtung 26 zunächst überprüft, ob das aktuell angezeigte Objekt ein gesetztes Static-Flag aufweist. Ist dies der Fall, bedeutet dies, dass die Objekt-ID für ein bestimmtes Menü oder ein bestimmtes Nachrichtenobjekt (z.B. themenbezogen) statisch bzw. ständig vorgesehen ist. Beispielsweise kRnnte ein Menü-Objekt betreffend "Wettervorhersage für Bamberg" immer durch einen bestimmten NewsService bzw. Nachrichtendienst unter der Objekt-ID 0x0020 angeboten werden. Folglich ist es in diesem Fall sinnvoll, es dem Benutzer zu ermRglichen, eine solche Objekt-ID zu einer Favoriten-Liste hinzuzufügen. Folglich fügt die Steuerungseinrichtung 26 in diesem Fall in einem Schritt 702 die Objekt-ID der Favoriten-Liste 46 in dem Speicher 32 hinzu. Sinnvoll wäre dies jedoch beispielsweise nicht bei einer Objekt-ID, die gerade für ein Text-Objekt vergeben ist, das den aktuellen Spielstand eines gerade stattfindenden Fußballspiels angibt. Dies Spiel endet nämlich in endlicher Zeit und die Objekt-ID wird anderweitig vergeben werden, beispielsweise für eine politische Tages- meidung oder dergleichen. Bei nicht gesetztem Static-Flag endet der Prozess bei 704 folglich ohne Hinzufügung. In diesem Fall kann die Ablehnung 704 durch beispielsweise einen Ton, der das normale Audiosignal aus dem Lautsprecher 28 bzw. 40 übertRnt und dem Benutzer die Ablehnung angezeigt, oder durch eine kurzzeitige Überblendung begleitet werden .
Es wird darauf hingewiesen, dass es bevorzugt wird, dass ein Empfänger 12, der die Favoriten-Funktionalität unterstützt, für jede Favoriten-Objekt-ID auch den vollen Pfad von Objekt-IDs von dem Haupt-Objekt mit der Haupt-Objekt-ID (z.B. 0x0000) bis zu dem jeweiligen Favoriten-Objekt speichert. Anderenfalls wird der Empfänger nicht in der Lage sein, die Menü-Zurück-Funktionalität bzw. Rückkehr-zu- einem-hRheren-Menü-Funktionalität einem Benutzer zur Verfügung zu stellen, wenn ein Benutzer dieses Favoriten-Objekt aufgerufen hat, wenngleich natürlich das Objekt selbst sowie die unmittelbaren Unter-Objekte, in dem Fall dass es sich um ein Menü-Objekt handelt, das auf dieselben verweist, immer noch erreichbar sein würden. Falls ein Menü aus dem Objekt-ID-Pfad bei Restaurieren eines Favoriten- Seichers nicht mehr existieren (versendet werden) sollte, kRnnte die Steuereinrichtung statt dessen direkt in das Standard-Hauptmenü (z.B. 0x0000) springen.
Bei dem in Vorhergehenden beschriebenem Empfänger .wurde eine Aufzeichnung aller Menü-O jekt-IDs von dem augenblicklich angezeigten Menü/Nachrichten-Objekt zurück bis zu dem Hauptmenü-Objekt (z.B. Objekt-ID 0x0000) bewahrt, der so genannte Objekt-ID-Pfad. Auf diese Weise kann derselbe eine "Zurück-zu-hRherer-Menü-Ebene"-Funktionalität liefern. Falls ein Objekt mit bestimmter Objekt-ID augenblicklich angezeigt wird bzw. dem Benutzer präsentiert wird und gleichzeitig eine aktualisierte Version desselben Objekts, d.h. ein Objekt mit identischer Objekt-ID aber unterschied- lichem Revisions-Index, empfangen wird, kRnnte entgegen vorhergehender Beschreibung dem Benutzer auch unabhängig von dem Objekt-Typ immer zunächst angezeigt werden, dass eine solche aktuelle Version dieses Objekts empfangen worden ist, wie z.B. durch Zeigen eines aufblinkenden "Aktua- lisierung"-Zeichens auf dem Bildschirm. Bevorzugt ist es jedoch, bei Menü- oder Listen-Nachricht-Objekten den Bildschirm der Anzeige unmittelbar mit dem Inhalt des neuen Objekts zu aktualisieren, während die aktuelle Relativ- Position des Benutzers innerhalb der Liste, d.h. der Li- stenzeilen-Index, an derselben Position im Bildschirm beibehalten wird. Anstelle des Listenzeilen-Indexes kRnnte ein Empfänger auf den Listenzeilen- bzw. Gegenstands-Text oder, in dem Fall eines Menü-Objekts, die Objekt-ID des Objekts, auf das verwiesen wird, auswerten. Bei einer Nur-Titel- Nachricht wird es bevorzugt, die Aktualisierung des Bildschirm der Anzeige mit dem Inhalt des neuen Objekts unmittelbar vorzunehmen.
Falls ein Menü-Objekt Verweise auf Objekt-IDs enthält, die noch nicht empfangen worden sind, werden diese Menüpunkte bzw. Menü-Optionen dem Benutzer trotzdem angeboten. Dies kRnnte freilich unterbleiben. Bevorzugt wird es jedoch, alle Menü-Optionen anzubieten, allerdings dabei dem Benutzer klar anzuzeigen, welche Menü-Optionen unmittelbar verfügbar sind, da die Objekte bereits empfangen worden sind und sich im Cache-Speicher befinden, und welche nicht unmittelbar sofort verfügbar sind, wie z.B. durch Umrahmen des Menü- Options-Etiketts bzw. -Titels mit eckigen Klammern, wie in Figur 6d gezeigt.
Bei Anwendungen mit extremen Speicherengpässen, kRnnte der Empfänger lediglich das aktuell angezeigte Objekt zusammen mit dem Objekt-ID-Pfad, der zu dem aktuell angezeigten Objekt gehRrt, in seinem Speicher behalten. Falls der Benutzer dann ein anderes Objekt anfordert, muss er warten, bis das angeforderte Objekt in der nächsten Zeit empfangen wird.
Wie bereits erwähnt, kann der oben beschriebene „NewsServi- ce Journaline"-Dienst via DAB als eine neue Benutzer- Applikation ausgestrahlt werden. Jedes einzelne "NewsServi- ce Journaline"-Objekt kRnnte als eine "MSC-Datengruppe" transportiert werden, wobei hierzu auf Kapitel 5.3.3 "Pak- ked Mode - Data Group Level" in "Radio Broadcasting Systems, Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers", ETSI EN 301 401 VI.3.2, 2000-09, ver- wiesen wird.
Eine MSC-Datengruppe enthielte dann die folgenden Punkte: Einen MSC-Datengruppen-Heäder zu zwei oder vier Bytes, einen Session- bzw. Sitzung-Header, der optional wäre und 3+n Bytes lang wäre, ein MSC-Datengruppen-Feld, das ein "News- Service Journaline"-Objekt bzw. Textinformationsobjekt beinhaltet, und zwar von beispielsweise m Bytes, max . jedoch 2044 Bytes, und schließlich eine MSC-Datengruppe-CRC zu zwei Bytes, die für „NewsService Journaline" verbindlich ist. Folgende Einstellungen kRnnten einheitlich für alle Empfänger festgelegt sein. Und zwar kRnnte festgelegt sein, dass es MSC-Datengruppen-Header-Feld folgendes Layout hat:
- Erweiterungs-Flag = 0 (Bei auf Eins gesetztem Flag musste der Empfänger Con- ditional Access bzw. eine Zugriffskontrolle unterstützen, um die Informationen zu dekodieren. Falls ein Empfänger kein Conditional Access unterstützt, musste er die MSC-Datengruppe verwerfen) CRC-Flag = 1 Segment-Flag = 0 (Wert hängt von dem Erweiterungs-Flag ab) Benutzer-Zugriffs-Flag = 0 (Wert hängt von dem Erweiterungs-Flag ab) Datengruppentyp = 0000b ("Allgemeine Daten") Kontinuitäts-Index: Inkrementiert kontinuierlich für jedes Objekt, kann aber ohne weiteres ignoriert werden. Wiederhol-Index: Wird üblicherweise dem Wert 000b aufweisen, kann aber ebenfalls ignoriert werden. Erweiterungs-Feld: Nicht vorhanden, weil das Erweiterungs-Flag auf 0 eingestellt ist.
Die folgenden Informationen kRnnten verwendet werden, um die DAB-Datenanwendung "NewsService Journaline" zu signali- sieren, wobei hierzu auf das Kapital 8.1.20 "User Application Information" aus obigen Dokument bzw. Standard verwiesen wird. Die Haupt-ll-Bit-"Benutzer-Applikationstyp"-ID für den "NewsService-Journaline" kRnnte bis zu einer offiziellen Standardisierung durch DAB-Gremien 0x44A von dem Bereich der proprietären Benutzeranwendungen sein. Der Wert ent- spricht 10001001010b.
Das Benutzer-Applikationsdaten-Feld kRnnte folgende Struktur aufweisen:
Ein Byte zur Anzeige der Version des „NewsService Journaline" . Zusätzliche Informationen einer neueren Version kRnnten in vollständig abwärts kompatibler Weise an zwei Stellen hinzugefügt werden, nämlich zum einen in der gesamten Dienstsignalisierung, nämlich der "DAB-Benutzer-Applika- tions-Information" durch Erweitern der Länge des "Benutzer- Applikations-Daten"-Abschnitts unter Beibehaltung aller e- xistierender Bytes und deren Definition, wie sie in jeder vorgehenden Version des "NewsService Journaline" definiert ist, oder in dem Objekt-Header-Abschnitt jedes einzelnen Objekts durch Erweitern der Länge des "Erweiterungs-
Header"-Feldes bei gleichzeitiger Beibehaltung aller existierenden Bytes und deren Definitionen, wie sie in einer vorhergehenden Version des „NewsService Journaline" definiert sind.
- Außerdem musste das User-Application-Data-Feld die Länge des Erweiterungs-Headers in Bytes in dem Header-Abschnitt jedes Objekts aufweisen, die zu Lesen jeder Empfänger zumindest in der Lage sein musste, auch wenn er anschließend die Daten in dem Erweiterungs-Header verwirft, weil er zu deren Auswertung nicht in der Lage ist. Mit identischer Signalisierung kann „NewsService Journaline" auch über DRM („Digital Radio Mondiale") ausgestrahlt werden, sowie über UKW/RDS nach Anpassung der Datendienst- Signalisierung.
Im Bezug auf die vorhergehende Figurenbeschreibung wird darauf hingewiesen, dass verschiedene darin enthaltene Aspekte nicht alle in der beschriebenen Weise kombiniert werden müssen, sondern dass diese Aspekte unabhängig von- einander implementiert oder nicht-implementiert sein kRnnen, wie z.B. insbesondere die Objekt-Pfad-Verwaltung mit zugehRriger "Menü-Zurück"-Funktionalität, die Cache- Speicher-Aktualisierung zur Beschleunigung des Zugriffs auf andere Textinformations-Objekte, die Abhängigkeit der An- zeige-Aktualisierung von dem Revisions-Index, die Abhängigkeit der Aktualisierung von dem Objekt-Typ, die Favoriten- Funktionalität, die Vermeidung von Zirkular-Referenzen in dem Objekt-ID-Pfad, der unterschiedlichen Bildschirm- Aktualisierung je nach Objekt-Typ, das Vorsehen des Revisi- ons-Index und dergleichen.
Abschließend wird darauf hingewiesen, dass abhängig von den Gegebenheiten das erfindungsgemäße Schema zur Steuerung eines Radio auch in Software implementiert sein kann. Die Im- plementierung kann auf einem digitalen Speichermedium, insbesondere einer Diskette oder einer CD mit elektronisch auslesbaren Steuersignalen erfolgen, die so mit einem programmierbaren Computersystem zusammenwirken kRnnen, dass das entsprechende Verfahren ausgeführt wird. Allgemein be- steht die Erfindung somit auch in einem Computerprogrammprodukt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode zur Durchführung des erfindungsgemäßen Verfahrens, wenn das Computerprogrammprodukt auf einem Rechner abläuft. In anderen Worten ausgedrückt kann die Er- findung somit als ein Computerprogramm mit einem Programm- code zur Durchführung des Verfahrens realisiert werden, wenn das Computerprogramm auf einem Computer abläuft.

Claims

Patentansprüche
Radio mit einer Empfangseinrichtung (24) zum Empfangen eines Rundfunksignals, das Textinformationsobjekte (100) umfasst, in denen Textinformationen (100b) enthalten sind; einer Anzeige (30) zum Anzeigen von anzuzeigenden TextInformationen; einer Benutzerauswahleinrichtung (34) , die durch einen Benutzer bedienbar ist, und einer Steuereinrichtung (26) , die ausgebildet ist, um abhängig von einer Bedienung der Benutzerauswahleinrichtung (34) durch den Benutzer die anzuzeigenden Textinformationen von aktuell angezeigten Textinformationen eines aktuell angezeigten Textinformationsobjekts auf Textinformationen eines Textinformationsobjektes zu ändern, auf das durch das aktuelle Textinformationsobjekt verwiesen wird.
2. Radio gemäß Anspruch 1, bei dem die Textinformations- Objekte in dem Rundfunksignal (16) aufeinander folgend angeordnet sind, jedes Textinformationsobjekt (100) eine Objekt-Identifikationsnummer (102) aufweist, und die Objekt-Identifikationsnummer (102) des aktuellen Textinformationsobjekts sich von der Objekt- Identifikationsnummer (102) des Textinformationsobjekts, auf das dasselbe verweist, unterscheidet.
3. Radio gemäß Anspruch 2, das ferner folgendes Merkmal aufweist : eine Aktualisierungseinrichtung zum Vergleichen (400) der Objekt-Identifikationsnummer eines auf das aktuell angezeigte Textinformationsobjekt folgenden Textinformationsobjekts mit der Objekt-Identifikationsnummer des aktuell angezeigten Textidentifikationsobjekts und Aktualisieren (402, 410, 416) der anzuzeigenden Textinformationen durch Ändern der aktuell angezeigten Textinformationen des aktuell angezeigten Textinformationsobjekts auf Textinformationen des folgenden Textinformationsobjektes abhängig von dem Vergleich.
4. Radio gemäß Anspruch 3, bei dem jedes Textinformationsobjekt 100 einen Revisions-Index (110) aufweist, und wobei die Aktualisierungseinrichtung ausgebildet ist, um den Revisionsindex des auf das aktuell anzeig- te Textinformationsobjekt folgenden Textinformationsobjekts mit dem Revisions-Index des aktuell angezeigten Textinformationsobjekts zu vergleichen (404) und die Aktualisierung nur bei gleicher Objekt- Identifikationsnummer und ungleichem Revisions-Index durchzuführen (410, 416) .
5. Radio gemäß Anspruch 3 oder 4, bei dem jedes Textinformationsobjekt ferner einen Objekt-Typ-Identifikator (108) aufweist, und wobei die Aktualisierungseinrich- tung ausgebildet ist, um die Aktualisierung auch abhängig von dem Objekt-Typ-Identifikator des aktuell angezeigten oder des folgenden Textinformationsobjekts durchzuführen, nämlich abhängig von demselben entweder unmittelbar (410) oder nach einer Benutzernachfrage (416) .
6. Radio gemäß einem der Ansprüche 3 bis 5, bei dem die Anzeige (30) ausgebildet ist, um bei Aktualisierung in dem Fall, dass die Menge an Textinformationen des folgenden Textinformationsobjekts grRßer als eine anzeigbare GrRße ist, einen Ausschnitt der Textinformation des folgenden Textinformationsobjekts anzuzeigen, der sich zumindest teilweise mit einem Ausschnitt überschneidet, den die Anzeige vor der Aktualisierung zeigte .
7. Radio gemäß einem der Ansprüche 2 bis 5, bei dem das aktuell angezeigte Textinformationsobjekt ein Menü- Objekt ist, und die aktuell angezeigten Textinformationen eine Liste von Menü-Optionen umfassen, wobei das Menü-Objekt für jede Menü-Option eine zugeordnete Objektidentifikationsnummer aufweist, wobei die Steu- ereinrichtung ausgebildet ist, um abhängig von der Bedienung der Benutzerauswahleinrichtung (34) durch den Benutzer die anzuzeigenden Textinformationen von den aktuellen angezeigten Textinformationen des aktuell angezeigten Textinformationsobjekts auf Textinforma- tionen eines Textinformationsobjekts zu ändern, das dieselbe Objekt-Identifikationsnummer aufweist, wie diejenige, die einer als ausgewählt hervorgehobenen Menü-Option zugeordnet ist.
8. Radio gemäß Anspruch 7, das ferner eine Benutzer- bedienbare Scroll-Einrichtung aufweist, wobei die Steuereinrichtung ausgebildet ist, um abhängig von der Bedienung der Scroll-Einrichtung durch den Benutzer die aktuell als ausgewählt hervorgehobene Menü-Option auf eine andere der Menü-Optionen zu ändern.
9. Radio gemäß einem der Ansprüche 2 bis 8, das ferner einen Cache-Speicher (42) zum zeitweiligen Speichern von bereits empfangenen Textinformationsobjekten aufweist.
10. Radio gemäß Anspruch 9, das ferner folgendes Merkmal aufweist: eine Cache-Aktualisierungs-Einrichtung zum Vergleichen (450) der Objekt-Identifikationsnummer eines aktuell empfangenen Textinformationsobjektes in dem Rundfunk- signal mit der Objekt-Identifikationsnummer jedes in dem Cache-Speicher (42) gespeicherten Textinformationsobjektes und Ersetzen eines gespeicherten Textinformationsobjektes, dessen Objekt-Identifikations- Nummer mit der des aktuell empfangenen Textinformati- onsobjekts in dem Rundfunksignal übereinstimmt, mit dem aktuell empfangenen Textinformationsobjekt.
11. Radio gemäß Anspruch 9 oder 10, die ferner folgendes Merkmal aufeist: eine Cache-Verdrängungs-Einrichtung (462, 464, 466) zum Vergleich (450) der Objekt-Identifikationsnummer eines aktuell empfangenen Textinformationsobjekts in dem Rundfunksignal mit der Objekt-Identifikations- nummer jedes in dem Cache-Speicher gespeicherten Textinformationsobjektes und Speichern des aktuell empfangenen Textinformationsobjekts in dem Rundfunksignal, wenn die Objekt-Identifikationsnummer desselben mit der Objekt-Identifikationsnummer keines der gespeicherten Textinformationsobjekte übereinstimmt.
12. Radio gemäß Anspruch 11, bei dem die Textinformations- Objekte in einer Baumstruktur angeordnet sind und die Steuereinrichtung ausgebildet ist, um die Speicherung durch Überspeicherung eines zu überspeichernden Textinformationsobjektes unter den in dem Cache-Speicher gespeicherten durchzuführen, wie es durch eine Ver- drängungsstrategie angezeigt wird, wobei die Verdrängungs-Strategie unter dem aktuell empfangenen Textinformationsobjekt und den in dem Cache-Speicher gespeicherten in Abhängigkeit von ihrer Lage und der Lage des aktuellen angezeigten Textinformationsobjekts in der Baumstruktur eine Priorität definiert, wobei unter den in dem Cache-Speicher gespeicherten Textinformationsobjekten diejenigen mit niedrigerer Priorität als dem aktuell empfangenen Textinformationsobjekt als mRgliches zu überspeicherndes Textinformationsobjekt in Frage kommen .
13. Radio gemäß einen der Ansprüche 9 bis 12, bei dem die Steuereinrichtung ausgebildet ist, um bei der Änderung der anzuzeigenden Textinformationen das andere Textin- formationsobjekt, auf das das aktuell angezeigte Textinformationsobjekt verweist, unter Verwendung der Objekt-Identifikationsnummer erst im Cache-Speicher nachzuschlagen und nur in dem Fall eines Fehlschlags abzuwarten, bis dasselbe in dem Rundfunksignal empfan- gen wird.
14. Radio gemäß einem Ansprüche 9 bis 13, das ferner folgendes Merkmal aufweist: einen Cache-Treffer-Identifizierer mit einer Einrichtung zum Nachschlagen, für jede Objekt-Identifikationsnummer, auf die durch das aktuell angezeigte Textinformationsobjekt verwiesen wird, ob ein Textinformations-Objekt mit der Objekt-Identifikationsnummer in dem Cache-Speicher vorhanden ist; und eine Einrichtung zum Hervorheben unter den aktuell angezeigten Textinformationen solcher Teile, die Identifikationsnummern zugeordnet sind, für die ein Textinformationsobjekt in dem Cache- Speicher vorhanden ist, gegenüber solchen Teilen in den aktuell angezeigten Textinformationen, denen Identifikationsnummern zugeordnet sind, für die kein Textinformationsobjekt in dem Cache- Speicher vorhanden ist.
15. Radio gemäß einem der Ansprüche 2 bis 10, wobei jedes Textinformationsobjekt ein Statisch-Flag aufweist, wobei das Radio ferner folgendes Merkmal aufweist: eine Favoriten-Aufruf-Einrichtung, die durch den Benutzer bedienbar ist; eine Benutzer-Hinzufügungs-Einrichtung, die durch den Benutzer bedienbar ist; einen Favoriten-Speicher zur Speicherung einer Objekt- Identifikationsnummer; wobei die Steuereinrichtung ausgebildet ist, um abhängig von einer Bedienung der Favoriten-Aufruf- Einrichtung durch den Benutzer die anzuzeigenden Textinformationen von den aktuell angezeigten Textinforma- tionen auf Textinformationen eines Textinformationsobjekts zu ändern, das dieselbe Objekt-Identifikationsnummer aufweist, wie die in dem Favoritenspeicher gespeicherte, und wobei die Steuereinrichtung ausgebildet ist, um abhängig von der Bedienung der Favori- ten-Hinzufügungs-Einrichtung durch den Benutzer das Statisch-Flag des aktuell angezeigten Textinformationsobjekts zu untersuchen und in dem Fall, dass das Statisch-Flag nicht gesetzt ist, die Bedienung zu übergehen, und in dem Fall, dass das Statisch-Flag ge- setzt ist, die Objekt-Identifikationsnummer des aktuell angezeigten Textinformationsobjekts in den Favoritenspeicher einzutragen.
16. Verfahren zum Steuern eines Radios mit einer Empfang- seinrichtung (24) zum Empfangen eines Rundfunksignals, das Textinformationsobjekte (100) umfasst, in denen Textinformationen (100b) enthalten sind, einer Anzeige (30) zum Anzeigen von anzuzeigenden Textinformationen, und einer Benutzerauswahleinrichtung (34), die durch einen Benutzer bedienbar ist, mit folgendem Schritt: abhängig von einer Bedienung der Benutzerauswahleinrichtung (34) durch den Benutzer, Ändern der anzuzeigenden Textinformationen von aktuell angezeigten Text- Informationen eines aktuell angezeigten Textinformationsobjekts auf Textinformationen eines Textinformationsobjektes, auf das durch das aktuelle Textinformationsobjekt verwiesen wird.
7. Computer-Programm mit einem Programmcode zur Durchführung des Verfahrens nach Anspruch 16, wenn das Computer-Programm auf einem Computer abläuft.
EP04764470A 2003-08-26 2004-08-25 Radio mit anzeige für textinformationen, die auf weitere textinformationsobjekte verweisen Expired - Lifetime EP1658689B1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
PL07015293T PL1845643T3 (pl) 2003-08-26 2004-08-25 Nadajnik radiowy do nadawania tekstowych obiektów informacyjnych
EP07015293A EP1845643B1 (de) 2003-08-26 2004-08-25 Rundfunksender zum Senden von Textinformationsobjekte
PL04764470T PL1658689T3 (pl) 2003-08-26 2004-08-25 Radioodbiornik z wyświetlaczem informacji tekstowych, które odnoszą się do kolejnych informacyjnych obiektów tekstowych
PL06009464T PL1689104T3 (pl) 2003-08-26 2004-08-25 Radioodbiornik z wyświetlaczem informacji tekstowych odnoszących się do innych obiektów informacji tekstowej
EP06009464A EP1689104B9 (de) 2003-08-26 2004-08-25 Radio mit Anzeige für Textinformationen, die auf weitere Textinformationsobjekte verweisen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10339537A DE10339537A1 (de) 2003-08-26 2003-08-26 Radio
PCT/EP2004/009494 WO2005022790A1 (de) 2003-08-26 2004-08-25 Radio mit anzeige für textinformationen, die auf weitere textinformationsobjekten verweisen

Related Child Applications (4)

Application Number Title Priority Date Filing Date
EP07015293A Division EP1845643B1 (de) 2003-08-26 2004-08-25 Rundfunksender zum Senden von Textinformationsobjekte
EP06009464A Division EP1689104B9 (de) 2003-08-26 2004-08-25 Radio mit Anzeige für Textinformationen, die auf weitere Textinformationsobjekte verweisen
EP06009464.6 Division-Into 2006-05-08
EP07015293.9 Division-Into 2007-08-03

Publications (2)

Publication Number Publication Date
EP1658689A1 true EP1658689A1 (de) 2006-05-24
EP1658689B1 EP1658689B1 (de) 2011-06-08

Family

ID=34202119

Family Applications (3)

Application Number Title Priority Date Filing Date
EP07015293A Expired - Lifetime EP1845643B1 (de) 2003-08-26 2004-08-25 Rundfunksender zum Senden von Textinformationsobjekte
EP04764470A Expired - Lifetime EP1658689B1 (de) 2003-08-26 2004-08-25 Radio mit anzeige für textinformationen, die auf weitere textinformationsobjekte verweisen
EP06009464A Expired - Lifetime EP1689104B9 (de) 2003-08-26 2004-08-25 Radio mit Anzeige für Textinformationen, die auf weitere Textinformationsobjekte verweisen

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP07015293A Expired - Lifetime EP1845643B1 (de) 2003-08-26 2004-08-25 Rundfunksender zum Senden von Textinformationsobjekte

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP06009464A Expired - Lifetime EP1689104B9 (de) 2003-08-26 2004-08-25 Radio mit Anzeige für Textinformationen, die auf weitere Textinformationsobjekte verweisen

Country Status (9)

Country Link
US (1) US7590381B2 (de)
EP (3) EP1845643B1 (de)
AT (2) ATE512514T1 (de)
CA (2) CA2672277C (de)
DE (2) DE10339537A1 (de)
ES (3) ES2294754T3 (de)
HK (1) HK1094488A1 (de)
PL (3) PL1845643T3 (de)
WO (1) WO2005022790A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024132830A1 (en) 2022-12-20 2024-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for coding of radio programs and multimedia services in television broadcasts
WO2024132752A1 (en) 2022-12-20 2024-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for coding, transport and signaling of logos and icons in television and radio broadcasts

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7415243B2 (en) * 2003-03-27 2008-08-19 Honda Giken Kogyo Kabushiki Kaisha System, method and computer program product for receiving data from a satellite radio network
US7643788B2 (en) 2004-09-22 2010-01-05 Honda Motor Co., Ltd. Method and system for broadcasting data messages to a vehicle
US20060158357A1 (en) * 2005-01-19 2006-07-20 Visteon Global Technologies, Inc. Text compression method for multi-level display
GB2423877B (en) * 2006-03-06 2007-05-30 Imagination Tech Ltd A method and system for selectively storing information received from a broadcast signal
US8099308B2 (en) 2007-10-02 2012-01-17 Honda Motor Co., Ltd. Method and system for vehicle service appointments based on diagnostic trouble codes
JP5440004B2 (ja) * 2008-10-20 2014-03-12 セイコーエプソン株式会社 情報配信システム、情報配信システムのサービス実現方法およびそのプログラム
JP5293086B2 (ja) 2008-10-28 2013-09-18 セイコーエプソン株式会社 情報配信システム、情報配信システムのサービス実現方法およびそのプログラム
KR101574603B1 (ko) 2008-10-31 2015-12-04 삼성전자주식회사 컨디셔널 프로세싱 방법 및 장치
EP2242249B1 (de) * 2009-04-14 2017-07-19 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Textbasierte Informationsübertragung

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2546501B2 (ja) * 1993-07-12 1996-10-23 日本電気株式会社 無線電話装置，それを備えた無線電話システム，及び無線電話応答方法
EP0762680A3 (de) 1995-08-23 2001-04-25 Fraunhofer-Gesellschaft Zur Förderung Der Angewandten Forschung E.V. Verfahren zur Übertragung und Installation und/oder Aktualisierung von Software und/oder Daten
DE19619491C2 (de) 1995-08-23 1999-03-25 Fraunhofer Ges Forschung Verfahren zur Übertragung und Installation und/oder Aktualisierung von Software und/oder Daten
FI98676C (fi) * 1995-10-05 1997-07-25 Nokia Oy Ab Tietostoryhmän siirto digitaalisessa yleisradiojärjestelmässä
FI99065C (fi) * 1995-10-05 1997-09-25 Nokia Oy Ab Ohjelmatiedoston käsittely digitaalisessa yleisradiojärjestelmässä
JPH10327111A (ja) * 1997-05-26 1998-12-08 Alpine Electron Inc Ｄａｂ受信機の番組受信方法
JP4196473B2 (ja) 1998-06-26 2008-12-17 パナソニック株式会社 デジタルデータ受信装置及びデジタルデータ受信方法並びにコンピュータ読み取り可能な記録媒体
EP1146673A1 (de) 2000-04-10 2001-10-17 Sony International (Europe) GmbH Verfahren zur Übertragung eines Informationsdienstes in einem Rundfunkübertragungssystem
US7180917B1 (en) * 2000-10-25 2007-02-20 Xm Satellite Radio Inc. Method and apparatus for employing stored content at receivers to improve efficiency of broadcast system bandwidth use
EP2207347B1 (de) * 2001-04-03 2013-03-27 United Video Properties, Inc. Elektronischer Programmführer zur Anzeige der Verfügbarkeit vergangener Programme in der Zukunft
DE10150596B4 (de) 2001-10-12 2009-04-02 Audi Ag Vorrichtung zum Empfangen und Verfahren zur Aktualisierung von TMC-Meldungen
US20030110272A1 (en) * 2001-12-11 2003-06-12 Du Castel Bertrand System and method for filtering content
JP3965126B2 (ja) * 2002-03-20 2007-08-29 松下電器産業株式会社 コンテンツを再生する再生装置
US7228100B2 (en) * 2003-03-25 2007-06-05 Visteon Global Technologies, Inc. Program data display in duplicative digital audio broadcasting system
US7415243B2 (en) * 2003-03-27 2008-08-19 Honda Giken Kogyo Kabushiki Kaisha System, method and computer program product for receiving data from a satellite radio network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005022790A1 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024132830A1 (en) 2022-12-20 2024-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for coding of radio programs and multimedia services in television broadcasts
WO2024132752A1 (en) 2022-12-20 2024-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for coding, transport and signaling of logos and icons in television and radio broadcasts
WO2024132118A1 (en) 2022-12-20 2024-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for coding, transport and signaling of logos and icons in television and radio broadcasts
WO2024132117A1 (en) 2022-12-20 2024-06-27 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for coding of radio programs and multimedia services in television broadcasts

Also Published As

Publication number Publication date
CA2672277A1 (en) 2005-03-10
HK1094488A1 (en) 2007-03-30
ES2366553T3 (es) 2011-10-21
US7590381B2 (en) 2009-09-15
CA2672277C (en) 2014-07-08
EP1658689B1 (de) 2011-06-08
PL1689104T3 (pl) 2008-03-31
WO2005022790A1 (de) 2005-03-10
ATE512514T1 (de) 2011-06-15
PL1658689T3 (pl) 2011-11-30
CA2537181A1 (en) 2005-03-10
DE10339537A1 (de) 2005-03-24
ES2294754T3 (es) 2008-04-01
CA2537181C (en) 2013-11-12
EP1689104A1 (de) 2006-08-09
EP1689104B1 (de) 2007-10-10
ES2389976T3 (es) 2012-11-05
EP1845643B1 (de) 2012-06-27
EP1845643A2 (de) 2007-10-17
ATE375641T1 (de) 2007-10-15
PL1845643T3 (pl) 2012-12-31
DE502004005230D1 (de) 2007-11-22
EP1689104B9 (de) 2008-08-20
US20060229056A1 (en) 2006-10-12
EP1845643A3 (de) 2007-10-31

Similar Documents

Publication Publication Date Title
DE69031510T2 (de) Abstimm-Steuergerät mit der Möglichkeit einer Abstimmung mittels Etiketten und unter Verwendung alphabetischer Etikettenspeicherung
EP1689104B9 (de) Radio mit Anzeige für Textinformationen, die auf weitere Textinformationsobjekte verweisen
WO1997042723A1 (de) Verfahren zur übertragung von durchsagen mittels digitaler hörfunksendungen und empfänger zur durchführung des verfahrens
EP2290886A1 (de) Verfahren zur Übertragung von Kurznachrichten
EP2126733B1 (de) Codieren eines text-datensstroms in einem basis-und erweiterungsmodus für empfänger mit unterschiedlichen decodern
DE60115627T2 (de) Sende-Empfänger und Verfahren zum Bereitstellen von züsatzlichen Diensten
EP1561281A2 (de) Verfahren zur erzeugung eines bitstroms aus einem indizierungsbaum
EP2034641A2 (de) Verfahren und Vorrichtung zur Darstellung von anzeigbaren RDS-Informationen
DE10248409A1 (de) Verfahren zur Steuerung der Programmauswahl am Empfangsgerät eines Broadcast-Mediums
DE60019802T2 (de) System und gerät zur erzeugung von nachrichten in mehreren sprachen für die verteilung an set-top-endgeräte in einem rundfunkfernsehsystem
DE102005026539B3 (de) Verfahren zur Bereitstellung von Informationen betreffend Rundfunkinhalte an einen Nutzer
WO1998020677A1 (de) Rundfunkprogrammsignal sowie verfahren zum verarbeiten dieses signals
EP2197202A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung sowie die Vorrichtung umfassendes System
EP0836292B1 (de) Verfahren und Einrichtung zur gebietsabhängigen selektiven Ausgabe von empfangenen digital codierten Meldungen
EP1248398B1 (de) RDS-Rundfunkempfänger mit PTY-Auswahl
DE10309612B4 (de) Verfahren zur Alarmierung mittels Funkruf und Funkrufempfänger
DE4422235A1 (de) Rundfunkempfänger
DE10141607A1 (de) Verfahren zur Wiedergabe von Multimediadateien in einem Endgerät
DE102013210644A1 (de) Methode und Einrichtung zum Integrieren von audio-visuellen Medieninhalten von Web-TV bzw. Webradio-Diensten in die Rundfunkkanal- und Programmverzeichnisse eines TV-Empfängers
DE102011078237B4 (de) Programmführungseinrichtung für einen Fernsehempfänger und Verfahren zum Generieren eines Programminformationsmenüs
DE102005014527A1 (de) Verfahren und Übertragen von Daten
EP0994589A2 (de) Empfänger für den Empfang von digitalen Hörfunkprogrammen (DAB)
EP1787474A1 (de) Verfahren zur codierung eines xml-basierten dokuments
WO2015011122A1 (de) Verfahren zur wiedergabe eines radioprogramms sowie multimediaeinheit zur durchführung des verfahrens

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060216

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1091051

Country of ref document: HK

17Q First examination report despatched

Effective date: 20100427

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04H 60/25 20080101ALN20101126BHEP

Ipc: H04H 20/40 20080101AFI20101126BHEP

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502004012584

Country of ref document: DE

Effective date: 20110721

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2366553

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20111021

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110909

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

REG Reference to a national code

Ref country code: PL

Ref legal event code: T3

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20111010

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

BERE Be: lapsed

Owner name: FRAUNHOFER-GESELLSCHAFT ZUR FORDERUNG DER ANGEWAN

Effective date: 20110831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

26N No opposition filed

Effective date: 20120309

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502004012584

Country of ref document: DE

Effective date: 20120309

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 512514

Country of ref document: AT

Kind code of ref document: T

Effective date: 20110825

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110825

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1091051

Country of ref document: HK

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110825

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110908

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110608

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 15

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230512

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20230823

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: TR

Payment date: 20230817

Year of fee payment: 20

Ref country code: IT

Payment date: 20230831

Year of fee payment: 20

Ref country code: GB

Payment date: 20230824

Year of fee payment: 20

Ref country code: ES

Payment date: 20230918

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: PL

Payment date: 20230816

Year of fee payment: 20

Ref country code: FR

Payment date: 20230821

Year of fee payment: 20

Ref country code: DE

Payment date: 20230822

Year of fee payment: 20

REG Reference to a national code

Ref country code: DE

Ref legal event code: R071

Ref document number: 502004012584

Country of ref document: DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: MK

Effective date: 20240824

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20240830

REG Reference to a national code

Ref country code: GB

Ref legal event code: PE20

Expiry date: 20240824

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20240824