A SOFTWARE CONTROLLED IMAGING SYSTEM WITH AN APPLICATION MODULE INTERCONNECTED TO A USER INTERFACE CONTROLLER MODULE IN A DATA DRIVEN ORGANIZATION

Description

BACKGROUND OF THE INVENTION

[0001] The invention relates to a system as recited in the preamble of Claim 1. It has been proposed to allow customers to use a variety of imaging subsystems with the same software program, the application module always remaining unmodified. If the software would remain indeed the pushing force, the application module should be capable to deal with all possible types of imaging subsystems, which is expensive to realize. In consequence, there is a need for a system with improved flexibility.

SUMMARY TO THE INVENTION

[0002] In consequence, amongst other things, it is an object of the present invention to expand a system as recited on the level of its internal interactivity for so attaining a higher degree of flexibility. Now therefore, according to one of its aspects the invention is characterized according to the characterizing part of Claim 1. Further advantageous aspects of the invention are recited in dependent Claims.

BRIEF DESCRIPTION OF THE DRAWING

[0003] These and further aspects and advantages of the invention will be discussed more in detail hereinafter with reference to the disclosure of preferred embodiments, and in particular with reference to the appended Figures that show:

Figure 1, conventional software controlled imaging;

Figure 2, software controlled imaging of the invention;

Figures 3, 3A-3C, examples of a root menu image;

Figures 4, 4A-4C, examples of a sub-menu image.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0004] Figure 1 illustrates conventional software controlled imaging, that may be implemented in a consumer electronics apparatus such as a television set. An application program is running on application module 22; this module includes the necessary data storage and data processing facilities. A visual image is presented to a user on imaging subsystem 32, under control of user interface controller module 24. The imaging system may be a Teletext Display, an LCD, or even be based on a PC; in consequence, subsystem 32 could contain those items necessary for generating the screen image from control signals received, such as scan synchronization, character/icon generator, color look-up-table, and other.

[0005] Furthermore, user interaction is possible on user interaction element 34 that may have a remote control device, keyboard, mouse, speech and other interactivity facilities. The main drive for amending the displayed image is given spontaneously by the application module on line 26. Such origin has been indicated by a dot, which convention will be maintained hereinafter. Subsequently, the application module may receive a user interface action on line 28. In consequence, the system flexibility and performance are restricted to that of the least capable version of the user interface controller module that has been foreseen. The interconnection lines as shown may realize a messaging system through wires, through software interaction, or otherwise.

[0006] Figure 2 illustrates software controlled imaging according to the invention. Application module 36 largely compares to module 22 in Figure 1. Also user interface controller module 38 has similar functions as module 24 in Figure 1. Modules 32, 34 also appear. The interaction pattern between modules 36, 38 has been radically amended with respect to Figure 1. First, User Interface Controller Module 38 may spontaneously issue a so-called 'pull' request on line 40 to Application Module 36, which has been signaled by the dot discussed before. Secondly, as indicated by the retrocoupling arrow, this results in sending the requested graphical user interface elements from Application Module 36 to User Interface Controller Module 38. Also the arrow convention will be followed hereinafter. In its broadest sense, certain UI-elements may be non-graphical such as acoustic, but for the remainder of the description such has been ignored.

[0007] Subsequent to the pulling, a user interface action may be sent via line 44 from User Interface Controller Module 38 to Application Module 36, which may result in one or more (G)UI element changes that are reported via line 46 back to User Interface Controller Module 38. Also, independent Notifications with respect to (G)UI element changes may be spontaneously forwarded on line 48, without earlier relevant signalization from controller module 38.

[0008] The received (G)UI element changes may cause User Interface Controller Module 38 to issue one or more further 'pull' requests via line 40 and to again receive new or updated (G)UI elements via line 42. In consequence, the system is demand driven, and User Interface Controller Module 38 determines which (G)UI elements will be rendered, and when such will be effected and how they will be structured. The User Interface Controller Module 38 decides on the presentation to the user of in particular the information aspects of the presentation, such as by full text, iconizing, menuing and further items of similar levels of complexity. Specific organization thereof, and relevant embodiments will be dealt with hereinafter.

[0009] Figures 3A-3C show an exemplary root menu image. Figure 3A shows a first representation type for such root menu for use with a consumer television set. First, the background image is arbitrary. The graphical user interface elements comprise foremost various lines of text, of which one may be selected such as by remote control.

[0010] Furthermore, the out-of-display text represented in Figure 3 describes the same menu as the onein Figure 3A, including the various possible selections that may be made. Figure 3B shows a second representation type for the same root menu as in Figure 3A, wherein however only a single selectable item is displayed. Through scrolling, this item may be exchanged for the various further items listed with respect to Figure 3A. The representation of Figure 3 also applies here, just as it does with respect to Figure 3C. The latter Figure shows a third representation type for the same root menu, wherein the various selectable items are each represented by a respective icon that may be activated immediately. It is clear that user actions, and further pull messages from the user interface controller module can now control the application module in their respective own manners to update the GUI elements. This would influence the information content, such as by jumping between hierarchically organized menu levels, setting parameter values, or altering a mode, such as between mono and stereo audio. The above describes how the User Interface elements will be structured. On the other hand, the particular manner of the rendering proper, such as by highlighting, popping, moving, hiding, discolouring, resizing, scrolling, animating, and a host of further graphical amendations of the rendering, need not be prescribed. This may indeed be effected by the User Interface controller module.

[0011] Figures 4A-4C show an exemplary sub-menu image, in three representations that respectively correspond to Figures 3A-3C. Again, the out-of-display representation of the "install preset" menu has only been given with respect to Figure 4. According to the invention, changes to a user interface element of Figures 3A-3B need in general not be sent to the user interface controller module, when the latter has one of the menus of Figures 4A-4C shown. Likewise, changes to a user element of Figures 4A-4C need in general not be sent to the user interface controller module, when the latter displays one of the menus of Figures 3A-3C. This is so, because the application can keep track of the menu that the user interface controller module is actually rendering. Figures 3A-3C, and Figures 4A-4C disclose various examples of the variety in structuring that may be displayed. The person skilled in the art know various other set-ups and structuring, both static and dynamic, of such displaying, and will consequence be fully enabled to practice the invention.

The Demand-driven User Interaction model

[0012] The following disclosure deals with (G)UI aspects and the interaction needed to exchange these GUI elements. The basic model for such an interaction protocol describes the GUI information that is exchanged between a target or application module and a user interface controller module, as has been shown also with respect to Figures 1 and 2.

[0013] In principle, the controller module that "pulls" the GUI info is a UI-controller and the target module that supplies the GUI information is typically a driver for a consumer electronics (CE) apparatus, such as a television set, set top box, tuner, or media player. A more flexible approach is to allow other applications than only a UI-controller to act as controller for pulling GUI info and any application (not only device drivers) to act as target for supplying GUI info.

Target and Controller interfaces

[0014] A target interface may look as follows:

• Get-GUI-Element (IN: GE-id, OUT: GE) pulls the requested GUI Element from the target (lines 40+42 in Figure 2).

  * GE-id stands for GUI-element-ID; the GE-id values are determined by the target. For the DDUI protocol these are just identifications for GUI elements.

  * GE stands for a description of a GUI-Element. This structure contains the type of the GUI-element and attributes such as size, position, colour, that are relevant for the type in question. The representation of a GUI element on an actual display allows for three levels of "sophistication":

  • Rendering the GUI element exactly as described, taking into account all supplied attributes. This requires a UI controller that is capable of dealing with the full DDUI.
  • Rendering the intended (graphical) GUI element, but taking into account less than all optional attributes or even no optional attributes at all.
  • Rendering the GUI element in a text-only way by making use of the mandatory (text) labels in the attribute list.

[0015] The above requires that for a specific GUI element it has been defined which attributes are mandatory and which are optional. The actual GUI-element implies which graphical attributes are mandatory.

[0016] Labels should be always mandatory to at least guarantee that "some" rendering is possible on the most "low-end" rendering device that a controller could use.

• User-Action (IN: GE-id, UA, OUT: GE-id-List) indicates to the target the User Action actually performed on the specified GUI element. The response from the target indicates which GUI elements have changed due to this user action ( lines 44+46 in Figure 2). A 'scope' definition is needed in order to avoid overloading the controller with changes that it is not interested in, see the Section on Hierarchy and Scope.

  * GE-id-List stands for a list of changed GE-id's.

  * UA describes a User Action. This structure is defined per type of GUI element. It may contain the type of the corresponding GUI element, and a value that is specific for the type of GUI element, such as a boolean PUSHED/RELEASED for button GUI elements and a character string for text-input GUI elements.

• Subscribe-GUI (OUT: GE-id) is a subscribe function that serves two purposes:

  * It indicates to the target that this controller is going to use its DDUI protocol, until the controller unsubscribes, see below.

  * The controller needs to know the "top-level" GUI-element ID called "root", in order to start the "pulling" process.

• Unsubscribe-GUI () indicates to the target that the above subscription has ended. The target will then send no more GUI-Change messages to the User Interface controller module.

[0017] A controller interface may look as follows:

• GUI-Change (IN: GE-id-List); this message notifies the controller of changes in GUI-elements that were not due to user actions, but for instance due to changes in the device associated with the target, such as end-of-tape (48 in Figure 2). A 'scope' definition is needed in order to avoid overloading the controller with changes that it is not interested in, see the Section on Hierarchy and Scope.

Hierarchy and Scope

[0018] The DDUI protocol requires a hierarchical organization of the GUI elements. This hierarchy serves two purposes:

• Allowing a controller to navigate through the GUI elements in an "organized" or hierarchical way.
• From a target's point of view it indicates which GUI-elements belong together and should preferably displayed together to a user. Even if the controller cannot or will not display simultaneously all GUI-elements associated to a certain level of the hierarchy, it should be apparent to a user which part of the hierarchy is being actually displayed. This means that the DDUI should distinguish between two types of GUI elements:
  • "organizational" GUI elements, called "menus" in the sequel;
  • "non-organizational" GUI elements contained in such menus.

[0019] Note: The "Root" GUI-element mentioned in the Subscribe GUI function of the target should be considered as the "top level" menu.

[0020] By means of the above hierarchy, a controller can select menus and also "non-organizational" GUI elements within menus. The way in which a controller navigates through the menus is arbitrary. The only thing that a target may assume is that a user is aware of the menu that is actually being displayed.

[0021] The hierarchy is also used by the controller to indicate in which set of GUI elements the controller is interested. The target then uses this information to report to the controller only GUI-element changes pertaining to this set. Of course it is possible that a controller is interested in all changes, but when this is not the case it should not be "overloaded" with changes it is not interested in. The basic scope for reporting the GUI-element change is a single menu. The idea behind this is that a controller is normally only "looking" at one menu at a time. In terms of above hierarchical split-up, this means the following:

• If a ("non-organizational") GUI element changes on the current menu this should be indicated by reporting the GUI-element-ID of that GUI element.
• If the set of "non-organizational" GUI elements on the current menu changes, this should be indicated by reporting the GUI-element-ID of the current menu; this in fact is the menu that was last "pulled" by the controller.

Claims

1. A software controlled imaging system comprising an application module interconnected to a user interface controller module, and furthermore user interaction means and an imaging subsystem,
   characterized in that said user interface controller module is arranged for generating a pull request to said application module, which is arranged for thereupon in a demand driven organization outputting to the user interface controller module one or more User Interface elements as were indicated in the request, so that the user interface controller module is operative for deciding which GUI elements will be rendered when and how they will be structured.

2. A system as claimed in Claim 1, wherein a user action that is notified by the user interface controller module to the application module will result in one or more GUI element changes being sent by the application module to the user interface controller module.

3. A system as claimed in Claim 1, wherein furthermore spontaneous updates of one or more GUI elements are notified by the application module to the user interface controller module together with such updated GUI elements.

4. A system as claimed in Claim 1, wherein a particular GUI element represents a menu that contains one or more further GUI elements.

5. A system as claimed in Claim 4, wherein the application module is being kept aware of one or more actually displayed "active" menus.

6. A system as claimed in Claim 5, wherein the user interface controller module receives exclusively amendments of such GUI-elements to be made in one or more actually "active" menus.

Revendications

1. Système d'imagerie commandé par logiciel comprenant un module d'application interconnecté à un module contrôleur d'interface utilisateur, et comprenant en outre des moyens d'interaction utilisateur et un sous-système d'imagerie ;
caractérisé en ce que ledit module contrôleur d'interface utilisateur est propre à générer une demande de déchargement audit module d'application, qui est alors propre, dans une organisation commandée par des demandes, à fournir au module contrôleur d'interface utilisateur un ou plusieurs éléments d'interface utilisateur indiqués dans la demande, de sorte que le module contrôleur d'interface utilisateur fonctionne pour décider quels éléments GUI seront restitués et à quel moment et de quelle manière ils seront structurés.

2. Système suivant la revendication 1, dans lequel une action utilisateur qui est signalée par le module contrôleur d'interface utilisateur au module d'application fera qu'un ou plusieurs changements d'élément GUI seront envoyés par le module d'application au module contrôleur d'interface utilisateur.

3. Système suivant la revendication 1, dans lequel des actualisations spontanées d'un ou de plusieurs éléments GUI sont en outre signalées par le module d'application au module contrôleur d'interface utilisateur en même temps que ces éléments GUI actualisés.

4. Système suivant la revendication 1, dans lequel un élément GUI particulier représente un menu qui contient un ou plusieurs autres éléments GUI.

5. Système suivant la revendication 4, dans lequel le module d'application est tenu informé d'un ou de plusieurs menus "actifs" effectivement affichés.

6. Système suivant la revendication 5, dans lequel le module contrôleur d'interface utilisateur reçoit exclusivement des modifications des éléments GUI à apporter dans un ou plusieurs menus effectivement "actifs".

Ansprüche

1. Softwaregesteuertes Abbildungssystem mit einem Anwendungsmodul verbunden mit einem Benutzer-Schnittstellen-Reglermodul und weiterhin Benutzerinteraktionsmittel und ein Abbildungssystem, dadurch gekennzeichnet, dass das genannte Benutzer-Schnittstellen-Reglermodul vorgesehen ist zum Erzeugen eines Pull-Antrags zu dem genannten Applikationsmodul, das vorgesehen ist um danach in einer antragsgesteuerten Organisation zu dem Benutzer-Schnittstellen-Reglermodul ein oder mehrere Benutzer-Schnittstellenelemente zu liefern, wie diese in dem Antrag angegeben wurden, so dass das Benutzer-Schnittstellen-Reglermodul wirksam ist um zu entscheiden, welche GUI-Elemente gerendert werden, wenn und wie sie strukturiert sein werden.

2. System nach Anspruch 1, wobei eine Benutzeraktion, die von dem Benutzer-Schnittstellen-Reglermodul an das Anwendungsmodul mitgeteilt wurde, zu einer oder mehreren Änderungen in den GUI-Elementen führt, die von dem Anwendungsmodul zu dem Benutzer-Schnittstellen-Reglermodul gesendet werden.

3. System nach Anspruch 1, wobei weiterhin spontane Aktualisierungen eines oder mehrerer GUI-Elemente von dem Anwendungsmodul dem Benutzer-Schnittstellen-Reglermodul mitgeteilt werden zusammen mit solchen aktualisierten GUI-Elementen.

4. System nach Anspruch 1, wobei ein bestimmtes GUI-Element ein Menü darstellt, das ein oder mehrere weitere GUI-Elemente umfasst.

5. System nach Anspruch 4, wobei das Anwendungsmodul sich eines oder mehrerer wirklich wiedergegebener "aktiver" Menüs bewusst ist.

6. System nach Anspruch 5, wobei das Benutzer-Schnittstellen-Reglermodul exklusiv Berichtigungen solcher GUI-Elemente empfängt, die in einem oder mehreren wirklich "aktiven" Menüs durchgeführt werden sollen.

Drawing