In der Patentschrift US 5,432, 941 ist eine Methode und ein System zur dynamischen Konfigurierung von Software-Systemen, die Konfigurationsgruppen benutzen, beschrieben. Diese und andere Lösungen laufen jedoch zur Installationszeit und sind für das von der Erfindung gelöste Problem nicht ausreichend.

Die Benutzerschnittstelle von Selbstbedienungsgeräten soll möglichst einfach und unmittelbar verständlich sein. Ins- besondere für Selbstbedienungsgeräte einschließlich Geld- automaten bedeutet dies, dass die Kunden schnell die ge- wünschte Information erhalten bzw. die gewünschte Transaktion durchführen können.

Dabei ist insbesondere zu vermeiden, dass es zu Sackgassen in der Bedienung kommen kann. Eine solche Sackgasse liegt beispielsweise vor, wenn in einer Menüstruktur Optionen angeboten werden, für die jedoch erst nach der Aktivierung eine Fehlermeldung erscheint, beispielsweise'Funktion nicht vorhanden', 'Funktion nicht erlaubt', 'Gerät außer Betrieb', o. ä. Ein ähnlich zu vermeidender Effekt besteht in dem Angebot von Untermenüs, die keine einzige aktivierbare Funktion enthalten.

Diese unerwünschten Effekte können vermieden werden, indem die die Benutzerschnittstellen bereitstellenden Programme individuell so programmiert werden, dass über Verzweigungen im Programm die Konfiguration jeweils abgefragt werden und durch Ausprogrammierung der Varianten diese Situationen vermieden wird. Obwohl möglich, ist dieser Ansatz sehr aufwendig, fehleranfällig und schwer dokumentierbar.

Aufgabe der Erfindung ist es, eine verbesserte Steuerung der Benutzerinteraktion bereitzustellen, die dieses Problem einfacher und übersichtlicher löst.

Die Erfindung besteht darin, dass die benötigte Konfigu- rationsinformation bereitgestellt und in Indikatoren aufgezählt der Programmfluss nur noch von den so ermittelten Indikatoren abhängig gemacht wird.

Es zeigen Fig. 1 eine mögliche Konfiguration einer Weiterbildung, Fig. 2 eine Bestimmung von Indikatoren mit Tabellen, Fig. 3 eine daraus entstehende Anzeige.

In Fig. 1 ist ein Client 10, z. B. ein Geldausgabeautomat, gezeigt, der Peripheriegeräte wie Kartenleser 11 u. a. umfasst. Die vorhandenen und aktiven Geräte sind in einer Tabelle 12 eingetragen. Der Client 10 ist über eine Netzwerkverbindung 13 mit einem Server 14 verbunden, der wiederum eine Verbindung in ein Bankennetzwerk 16 hat. In dem Server 14 ist eine Datenbank 15 gegeben, deren Benutzung weiter unten beschrieben wird. In dieser, bereits eine Weiterbildung darstellende, Konfiguration wird die Ausgabe auf den Client 10 vom Server 14 anhand der in der Tabelle 12 bzw. Datenbank 15 eingetragenen Konfigurationsdaten erzeugt.

Dabei werden in der Netzwerkversion bevorzugt die den Client 10 betreffenden und von diesem übermittelten Konfigurationsdaten auf dem Server dynamisch bereitgestellt, d. h. entsprechend häufig aktualisiert. Zunächst wird jedoch eine einfache Ausführungsform beschrieben, die keinen Server und keine Netzwerkverbindung voraussetzt und bei der der spätere Client 10 ein Geldautomat sei.

Dieser Geldautomat enthält in der Regel einen Kartenleser, der Magnetstreifen-und Chipkarten lesen kann und mit IDKG abgekürzt bezeichnet sei. Ferner ist ein Auszahlungsmodul AZM möglich. Weiterhin sei die Menge des darin vorhandenen Geldes mit AZVAL bezeichnet. Zudem ist ein Auszugsdrucker KADRU installierbar. Für die Prüfung der Autorisierung wird eine manipulationsgeschützte PIN-Tastatur EPP installiert.

In der folgenden Tabelle werden nun vier Geschäftsvorgänge INFO, AUSZUG, UEBERW und AUSZAHL definiert : ID IDKG AZM AZVAL KADRU EPP INFO * * AUSZUG 1 1 UEBERW 1 1 AUS ZAHL 1 1 5 0 0 1

Hier steht ein Stern'*'für einen beliebigen Wert. Die Geschäftsvorgänge sind dann folgende : INFO Allgemeine Information : kein Gerät notwendig.

AUSZUG Drucken eines Kontoauszugs : Kartenleser IDKG für die Kontonummer und Auszugsdrucker KADRU werden benötigt.

UEBERW Eingabe einer Überweisung : Kartenleser IDKG und eine PIN-Tastatur EPP zur Autorisierung werden benötigt.

AUSZAHL Auszahlung eines Betrages : Lediglich der Kontoauszugsdrucker wird nicht benötigt.

Dabei stellen die Geräte bzw. deren Eigenschaften abstrakt gesehen Dienstmerkmale dar, die sowohl numerisch (AZVAL) als auch boolesch sein können. Die Symbole INFO, AUSZUG usw. in der ersten Spalte stellen Indikatoren dar. Durch die Tabelle wird einer Kombination von Dienstmerkmalen jeweils ein Indikator zugeordnet.

Dabei ist das Dienstmerkmal vorhanden, wenn das entsprechende Gerät installiert und betriebsbereit ist. Daher kann es zweckmäßig sein, dieses Dienstmerkmal über zwei Tabellen zu bestimmen ; in einer Tabelle sind die in dem jeweiligen Gerät installierten Geräte unabhängig vom Betriebszustand aufgeführt, in der zweiten Tabelle können (installierte) Geräte vom Bediener oder Techniker auf verfügbar (online) oder nicht verfügbar (offline) gestellt werden.

Ein übliche Datenbankabfrage liefert dann beispielsweise folgende Tabelle :

Gerät Dienstmerkmal IDKG 1 AZM 1 AZMVAL 20000 KADRU 0 EPP 1 Kombination mit der obigen Tabelle ergibt die Verfügbarkeit der Dienstmerkmale : ID Verfügbar INFO 1 AUSZUG 0 UEBERW 1 AUSZAHL 1 Hier sind die Indikatoren als boolesche Werte mit 0 oder 1 dargestellt, so dass sich eine eindeutige JA/NEIN Aussage ergibt. Diese Operation ist in Fig. 2 dargestellt. In diesem Fall ist dann einfach 1 der Grenzwert, für den das Dienstmerkmal als zutreffend gilt.

Im einfachen Fall sind die Indikatoren direkt jeweils einem Softkey einer Bildschirmmaske zugeordnet, so dass dem Benutzer signalisiert wird, dass von den vier Auswahl- möglichkeiten INFO, AUSZUG, UEBERW und AUSZAHL lediglich AUSZUG nicht verfügbar ist ; dies könnte wie in Fig. 3 gezeigt aussehen. Dabei ist ein Bildschirm 20 mit Funktionstasten

(Softkey) 21a, 21b und 21c gezeigt, bei dem den drei verfügbaren Interaktionen jeweils ein Softkey zugeordnet und für die nicht verfügbare Interaktion ein erklärender Text dargestellt wurde.

Anstelle von Tabellen können auch Formeln verwendet werden, im obigen Fall würde dies für die letzte Zeile beispielsweise lauten : AUSZAHL : = IDKG & AZM & (AZVAL > 500) & EPP Die Evaluierung solcher Ausdrücke ist aus dem Gebiet der interpretierten Programmiersprachen allgemein bekannt.

In der obigen Darstellung wurde das Symbol'*'für'beliebig' verwendet. Alternativ hierzu können die logischen Werte als '0'und'1'eingetragen werden und ein Wertvergleich stattfinden ; eine'0'wirkt dann wie'beliebig'.

Die Erfindung entfaltet ihr Potential im Rahmen einer bevorzugten Weiterbildung einer Konfiguration, wie sie in Fig. 1 gezeigt ist. Geldautomaten werden heute als Clients in einem Netzwerk mit Servern betrieben ; über das Netzwerk werden nicht nur die reinen Banktransaktionen abwickelt, sondern auch die Benutzerschnittstelle aufbereitet und definiert. Besonders verbreitet ist die Lösung, bei der ein HTML-Browser zur Gestaltung der Benutzeranzeige eingesetzt wird, dessen HTML-Datei jeweils vom Server bereitgestellt wird. In diesem Fall werden die Dienstmerkmale vom Client an den Server übermittelt ; hierfür wird bevorzugt eine existierende Wartungskomponente im Netzwerk verwendet.

Natürlich können hierzu auch die Kopfzeilen (Header) im HTTP- Protokoll ausgenutzt werden ; beispielsweise wie es in dem RFC 2295"Transparent Content Negotiation in HTTP ; K.

Holtman, A. Mutz ; March 1998"vorgeschlagen ist. Eine andere Möglichkeit besteht darin, einen Server-ähnlichen Dienst im Client einzurichten, bei dem der Server die Konfigurations- daten abfragen kann. Alternativ oder zusätzlich kann der Client von sich aus bei einer Änderung die Daten an den Server als geänderte Dienstmerkmale übermitteln ('push'- Betrieb).

Dazu kommen dann Dienstmerkmale, die im Server bestimmt werden. Dies können beispielsweise alle Bankenkreise sein, zu denen eine Online-Verbindung besteht.

Hierzu wird eine Variante der Erfindung verwendet, bei der die Werte der Indikatoren von der Software jederzeit aktualisiert abgefragt werden können. Wird ein Indikator durch eine Formel bestimmt, dann ist dies ohnehin der Fall.

Wird ein Indikator durch Datenbank-Tabellenoperationen bestimmt, dann kann entweder eine Funktion zur Aktualisierung bereitgestellt werden, die die obige Tabelle neu erstellt.

Moderne Datenbanksysteme bieten die Möglichkeit, selbst komplexe Abfragen als'view'zu definieren und dann automatisch zu aktualisieren. In diesem Fall muss die Datenbankstruktur derart gestaltet sein, dass die Daten zusätzlich eine Angabe über das Terminal, d. h. den Client, enthalten, und die obigen Tabellen z. B. als'view'verfügbar sind.

Hiernach ergibt sich folgender Ablauf : Zunächst wird ein Indikator LOGIN definiert, der nur den Kartenleser benötigt. Durch das Einlesen der Karte wird die Kartennummer zum Server übertragen, der aus der Kartennummer und ggf. anderen Angaben auf der Magnetspur oder dem Chip den Bankenkreis bestimmt. Danach wird der Bankenkreis in die Datenbank eingetragen (bezogen auf das jeweilige Client- Gerät), und die Indikatoren neu bewertet.

Beispielsweise wird in Abänderung zur obigen Tabelle der Indikator UEBERW nur für bestimmte Bankenkreise aktiviert.

Sind dies mehr als einer, so werden bei der skizzierten Realisierung mit relationalen Datenbanken mehrere Zeilen eingetragen, die sich nur in dem Feld für den Bankenkreis unterscheiden.

In gleicher Art wird aus der Kontonummer entnommen, zu welchen Diensten der Kunde Zugang hat, und eine entsprechende Tabelle aktualisiert. Diese werden dann in gleicher Weise wie die Bankenkreise in die Bedingungen für die Indikatoren aufgenommen, so dass ein Menüeintrag für"Überweisung"nur

dann angezeigt wird, wenn nicht nur eine PIN-Tastatur vorhanden, sondern auch Überweisungen für den Kunden freigeschaltet sind.

Aus dem Beispiel wird deutlich, dass die Erstellung und Wartung der Software für die Benutzerschnittstelle mit Benutzung der Erfindung wesentlich vereinfacht wird. Die Software fragt nicht mehr direkt ab, welche Funktionen bereitstehen, sondern verwendet statt dessen Indikatoren, die in ihrer Gesamtheit nicht mehr installations-und kunden- abhängig sind. Die Anpassung an die jeweilige Installation erfolgt nach der bevorzugten Variante durch Tabellen, deren Datenmodell gleichfalls vordefiniert und einheitlich sein kann. Lediglich die unterschiedlichen, anwendungsbezogenen Inhalte der Tabellen bestimmen die angebotenen Interaktionen.