Derartige Zahlungsverkehrsterminals werden zum Beispiel für bargeldlose Zahlungen aller Art eingesetzt. Der Begriff Zahlungsverkehrsterminal soll jedoch auch Geräte umfassen, die lediglich indirekt mit Zahlungs-und Abrechnungsvorgängen zu tun haben, wie beispielsweise chipkartenbasierte Zugangskontroll-und Zeiterfassungssysteme.

Um sinnvoll eingesetzt werden zu können, müssen Zahlungsverkehrs- terminals kunden-und/oder gerätespezifisch konfiguriert werden. Dabei werden beispielsweise die Gerätekonfiguration, der Funktionsumfang, ge- rätespezifische Kopfdaten (Kontonummer, Standortdaten, Terminalbezeich- ner, ... ) und/oder kundenspezifische Anzeigentexte eingestellt. Es ist be- kaimt, diese Konfiguration durch den Kundendienst des Terminalherstellers vorzunehmen. Der Kunde erhält dazu per Telefax ein Formular zugesandt, das er ausfüllt und an den Kundendienst zurücksendet. Das Formular wird von Hand ausgewertet, um eine entsprechende Konfigurationsdatei zu erstellen. Schließlich wird die Konfigurationsdatei durch den Kundendienst über einen Wartungscomputer in das Zahlungsverkehrsterminal geladen.

Diese bekannte Vorgehensweise ist wegen der manuellen Datenauswertung personalintensiv und fehleranfällig. Außerdem kann es zu Wartezeiten kom- men, bis die gewünschte Konfiguration erstellt und geprüft ist.

Die Erfindung hat die Aufgabe, die genannten Probleme ganz oder teilweise zu vermeiden. Insbesondere sollen durch die Erfindung die technischen Grundlagen geschaffen werden, um die Konfiguration von Zahlungsver- kehrsterminals zu vereinfachen, Fehler zu vermeiden und den erforderlichen Zeit-und Kostenaufwand zu verringern.

Erfindungsgemäß wird diese Aufgabe ganz oder teilweise durch ein Verfah- ren mit den Merkmalen des Anspruchs 1, einen computerlesbaren Daten- träger gemäß Anspruch 12 sowie ein Zahlungsverkehrsterminal gemäß An- spruch 13 gelöst. Die abhängigen Ansprüche betreffen bevorzugte Ausge- staltungen der Erfindung. Die Aufzählungsreihe der Verfahrensschritte in den Ansprüchen soll nicht als Einschränkung des Schutzbereichs verstanden werden. Es sind vielmehr Ausgestaltungen der Erfindung vorgesehen, in denen diese Schritte in anderer Reihenfolge und/oder zumindest teilweise parallel und/oder zumindest teilweise ineinander verzahnt ausgeführt werden.

Die Erfindung geht von der Grundidee aus, den Vorgang der Konfiguration des Zahlungsverkehrsterminals zu automatisieren. Dazu wird erfindungs- gemäß vorgeschlagen, ein ausfüllbares Konfigurierungsformular durch einen auf einem Benutzerrechner laufenden Browser anzuzeigen. Die Einträ- ge in dem Konfigurierungsformular werden in Form von Eingabedaten, die ein durch den Browser vorgegebenes Datenformat aufweisen, an einen Über- setzer übermittelt. Der Übersetzer erzeugt Ladedaten in Abhängigkeit von den Eingabedaten und gegebenenfalls weiteren Informationen. Die Lade- daten weisen ihrerseits ein durch das Zahlungsverkehrsterminal vorgegebe- nes Datenformat auf und dienen zur Konfigurierung des Zahlungsverkehrs- terminals.

Die erfindungsgemäß vorgeschlagene Automatisierung führt zu einer höhe- ren Qualität des Konfigurationsvorgangs, weil manuelle Bearbeitungsfehler vermieden werden. Änderungen können schneller und mit geringerem Auf- wand für den Kundendienst durchgeführt werden. Die Erfindung macht es überdies praktikabel, Zahlungsverkehrsterminals mit erweiterten Konfigura- tionsmöglichkeiten auszustatten, die sich bisher nicht effizient hätten nutzen lassen.

In bevorzugten Ausgestaltungen der Erfindung wird das Konfigurierungs- formular in einer Seitenbeschreibungssprache, beispielsweise HTML oder XML, an den Browser übermittelt. Dies ermöglicht eine benutzerfreundliche Gestaltung des angezeigten Konfigurierungsformulars. Durch die grafische Ausgestaltung des Formulars kann das korrekte Ausfüllen erheblich erleich- tert werden. Der Browser kann ein üblicher Internet-Browser sein. Das Kon- figurierungsformular kann von einem externen Server oder von einem loka- len Datenträger in den Browser geladen werden.

Vorzugsweise sind die zu konfigurierenden Parameter binäre Parameter (entsprechend einer Ja/Nein-Eingabe im Konfigurierungsformular) und/oder numerische Parameter (entsprechend einer Zahleneingabe im Konfigurierungsformular) und/oder Textparameter (entsprechend einer Texteingabe im Konfigurierungsformular). Abhängig vom Zahlungsver- kehrsterminal kann vorgesehen sein, daß sich die Konfigurierung auf Kopf- daten (Daten mit individuellem Terminalbezug) und/oder auf kundenspezi- fische Daten (z. B. Telefonnummern oder Kundennamen) und/oder auf län- derspezifische Daten (anzuzeigende oder auszudruckende Meldungen in der jeweiligen Landessprache) bezieht. Insbesondere die Konfigurierbarkeit von Texten durch den Kunden erleichtert die Arbeit des Kundendiensts bzw. des

Servicecenters erheblich. Dies gilt besonders bei der Anpassung des Zah- lungsverkehrsterminals an die unterschiedlichen Sprachen.

Das vom Browser vorgegebene Datenformat, in dem dieser die Eingabe- daten an den Übersetzer sendet, ist vorzugsweise ein Textformat. Besonders bevorzugt wird ein Datenformat, das für jeden Konfigurierungsparameter ein Paar aus einem Bezeichner des Parameters und dem für den Parameter eingestellten Wert aufweist (Bezeichner/Wert-Paar = tag/value pair). Viele übliche Browser sind zur Erzeugung derartiger Formate eingerichtet. Vor- zugsweise werden die Eingabedaten als E-Mail-Nachricht vom Browser zum Übersetzer übertragen.

In unterschiedlichen Ausgestaltungen der Erfindung wird der Übersetzer als Programmodul von dem Bedienungsrechner oder von einem externen Servicerechner oder von einem Mikrocontroller des Zahlungsverkehrs- terminals ausgeführt. In den beiden erstgenannten Fällen wird vorzugsweise eine Kommunikationsschnittstelle des Zahlungsverkehrsterminals verwen- det, um die extern berechneten Ladedaten in das Zahlungsverkehrsterminal zu übertragen und dort den Konfigurationsvorgang auszulösen. In der drit- ten genannten Alternative dient die Kommunikationsschnittstelle vorzugs- weise zum Übertragen der Eingabedaten. In einer vorteilhaften Weiter- bildung wird die Kommunikationsschnittstelle nicht nur zum Zwecke der Konfigurierung, sondern auch im normalen Betrieb des Zahlungsverkehrs- terminals, beispielsweise zum Anschluß des Zahlungsverkehrsterminals an eine Telefonleitung oder ein Firmennetz, verwendet.

Erfindungsgemäß werden die Ladedaten in Abhängigkeit von den Eingabe- daten erzeugt. In manchen Ausgestaltungen findet hier lediglich ein Umsetz- vorgang statt, der den Eingabedaten keine weiteren Informationen hinzu-

fügt. In anderen Ausgestaltungen ist dagegen vorgesehen, daß zur Erzeu- gung der Ladedaten neben den Eingabedaten weitere Informationen aus- gewertet werden. Dies können insbesondere Informationen sein, die durch eine Datenbank-Abfrage ermittelt wurden. Ferner sind Ausgestaltungen vorgesehen, bei denen-alternativ oder zusätzlich-aus einer Datenbank erhaltenene Informationen als Einträge in das Konfigurierungsformular aufgenommen werden. Derartige Einträge können sichtbar oder verborgen sowie durch den Benutzer änderbar oder fest sein. Sie werden mit den Eingabedaten an den Übersetzer übertragen.

In den im vorhergehenden Absatz genannten Varianten hat die Anbindung an die Datenbank den Vorteil, daß nicht alle zur Konfigurierung erforderli- chen Informationen jeweils einzeln über die vom Browser bereitgestellte Bedienoberfläche eingegeben werden müssen. Dies ist insbesondere dann bedeutsam, wenn viele Zahlungsverkehrsterminals mit ähnlichen Konfi- gurationen versehen werden sollen.

Neben dem Einspielen von Eingabe-und/oder Ladedaten kann in bevor- zugten Ausgestaltungen auch eine Funktionalität zum Auslesen von Konfi- gurationsdaten aus dem Zahlungsverkehrsterminal vorgesehen sein. Die ausgelesenen Daten können z. B. durch den Browser angezeigt und/oder in der Datenbank gespeichert werden.

Der erfindungsgemäß vorgesehene Datenträger kann ein elektronisches oder magnetisches oder optisches Speichermedium, z. B. eine Diskette oder Fest- platte oder CD-ROM sein, ist aber nicht auf körperliche Datenträger be- schränkt. Auch elektrische oder optische Signale, z. B. Spannungspegel einer Kommunikationsverbindung, sollen im hier verwendeten Sinne als compu- terlesbare Datenträger aufgefaßt werden. Der Datenträger enthält erfin-

dungsgemäß Computerbefehle, die den Umsetzvorgang zwischen den Ein- gabedaten und den Ladedaten steuern.

Das erfindungsgemäße Zahlungsverkehrsterminal ist zum Übersetzen der über die Kommunikationsschnittstelle empfangenen Eingabedaten des ex- ternen Browsers in die Ladedaten eingerichtet. Das Zalllungsverkehrs- terminal wird entsprechend den Ladedaten konfiguriert. Die Ladedaten können beispielsweise dem neu in einen Konfigurationsspeicherbereich einzuschreibenden Speicherinhalt entsprechen oder Regeln zur Veränderung des Speicherinhalts angeben. Vorzugsweise sind die Schritte des Erzeugens der Ladedaten und des Veränderns des Speicherinhalts ineinander verzahnt, so daß beispielsweise jedes erzeugte Byte der Ladedaten unmittelbar in den Konfigurationsspeicherbereich des Zahlungsverkehrsterminals eingeschrie- ben wird.

In bevorzugten Ausgestaltungen sind der computerlesbare Datenträger und/oder das Zahlungsverkehrsterminal mit Merkmalen weitergebildet, die den oben beschriebenen und/oder den in den Verfahrensansprüchen ge- nannten Merkmalen entsprechen.

Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden detaillierten Beschreibung mehrerer Ausführungsbeispiele und Ausführungsalternativen hervor. Es wird auf die schematischen Zeichnun- gen verwiesen, in denen zeigen : Fig. 1 ein Blockdiagramm eines ersten Ausführungsbeispiels, bei dem der Umsetzvorgang der Eingabedaten in die Ladedaten von einem externen Servicerechner ausgeführt wird,

Fig. 2 ein Blockdiagramm eines zweiten Ausführungsbeispiels, bei dem der Umsetzvorgang der Eingabedaten in die Ladedaten von einem Mikro- controller des Zahlungsverkehrsterminals ausgeführt wird, Fig. 3 ein Ablaufdiagramm zur Erläuterung weiterer Ausführungsbeispiele der Erfindung, und Fig. 4 ein Blockdiagramm einer Anordnung ähnlich wie in Fig. 1 zur Erläu- terung des Auslesens von Konfigurationsdaten aus dem Zahlungsverkehrs- terminal.

Das in Fig. 1 und Fig. 2 gezeigte Zahlungsverkehrsterminal 10 dient in sei- nem normalen Betrieb zur Ausführung bargeldloser Zahlungstransaktionen unter Verwendung einer Chipkarte. Diese Funktionalität ist beispielsweise aus dem gegenwärtig von der Firma CpayS AG angebotenen Ladeterminal ZVT (D 700 bekannt. Das Zahlungsverkehrsterminal 10 ist als kompaktes Modul mit einem Mikrocontroller 12 ausgebildet, der mit einem Programm- und Arbeitsspeicher 14, einer alphanumerischen Anzeige 16 mit einer oder zwei Anzeigezeilen und einem Tastenfeld 18 mit zehn Zifferntasten und einigen wenigen Funktionstasten in Verbindung steht. Weitere Kompo- nenten des Zahlungsverkehrsterminals 10, beispielsweise eine Schnittstelle für eine Chipkarte oder einen sonstigen Datenträger, sind in Zusammenhang mit der vorliegenden Erfindung weniger bedeutsam und daher in den Figu- ren nicht gezeigt.

Der Programm-und Arbeitsspeicher 14 weist einen beschreibbaren, nicht- flüchtigen Konfigurationsspeicherbereich 20 auf, der terminal-und kunden- spezifische Konfigurationsdaten enthält. Im hier beschriebenen Ausfüh- rungsbeispiel umfassen die Konfigurationsdaten ungefähr 50 Einstelloptio-

nen, 100 Funktionskonfigurationen, 60 Telefonnummern, 10 terminalspezifi- sche Daten (Kopfdaten) und 2 x 16 Zeichen kundenspezifischen Text. In Ausführungsalternativen können mehr oder weniger Konfigurationsdaten vorgesehen sein ; insbesondere kann vorgesehen sein, daß die Konfigura- tionsdaten auch länderspezifische Daten wie Druck-oder Anzeigetexte aufweisen, die über das erfindungsgemäße Verfahren konfigurierbar sind.

Diese länderspezifischen Daten, die beispielsweise 300 Anzeigetextzeilen und 350 Drucktextzeilen umfassen, sind dann ebenfalls im Konfigurations- speicherbereich 20 enthalten, der entsprechend größer ausgelegt sein muß.

Das Zahlungsverkehrsterminal 10 weist ferner eine Kommunikationsschnitt- stelle 22 auf, die in unterschiedlichen Ausgestaltungen entweder eine Schnittstelle zum Anschluß an eine Telefonleitung oder eine Schnittstelle zum Anschluß an ein Firmennetz oder eine z. B. serielle Schnittstelle zum Anschluß an einen externen Computer sein kann. Im Normalbetrieb des Zahlungsverkehrsterminals 10 wird die Kommunikationsschnittstelle 22 z. B. zum Einholen von Autorisierungen von einem telefonisch erreichbaren Hintergrundrechner oder zum Dätenaustausch mit einem lokalen oder netz- werkgekoppelten Computer oder einer Registrierkasse genutzt. Über die Kommunikationsschnittstelle 22 können jedoch bei dem Ausfüluungsbei- spiel von Fig. 1 auch Ladedaten 24 in einem durch das Zahlungsverkehrs- terminal 10 vorgegebenen Format eingespielt werden.

Das vorgegebene Format der Ladedaten 24 ist im Ausführungsbeispiel gemäß Fig. 1 ein einfaches, textbasiertes Format, dessen Interpretierung nur geringe Ansprüche an den Programm-und Arbeitsspeicher 14 sowie an den Mikrocontroller 12 stellt. Beispielsweise kann das Format der Ladedaten 24- nach einem anfänglichen Schlüsselwort und gegebenenfalls einer Anfangs- adresse-eine Folge von Hexadezimalzahlen im ASCII-Code enthalten, die

vom Mikrocontroller 12 in Bytes umgewandelt und, in aufsteigender Reihen- folge in den Konfigurationsspeicherbereich 20 geschrieben werden. Eine derartige Konfigurierungsmöglichkeit ist aus dem bereits erwähnten Lade- terminal ZVTt) 700 an sich bekannt.

Als Hilfsmittel zur Konfigurierung des Zahlungsverkehrsterminals 10 wird in den Ausführungsbeispielen von Fig. 1 und Fig. 2 ein Browser 26 verwen- det, der von einem Bedienungsrechner 28 ausgeführt wird (in Fig. 1 und Fig. 2 ist der Browser 26 durch sein auf dem Bildschirm des Bedienungs- rechners 28 angezeigtes Hauptfenster dargestellt). Der Browser 26 ist ein üblicher Internet-Browser, wie er beispielsweise unter den Bezeichnungen Microsoft@ Internet Explorer@ oder Netscape (D Navigatorg bekannt ist. Der Bedienungsrechner 28 ist ein üblicher persönlicher Computer.

Beim Konfigurationsvorgang zeigt der Browser 26 ein Konfigurierungs- formular 30 an, das im vorliegenden Beispiel die Form einer Tabelle mit Hinweisen zum jeweiligen Konfigurierungsparameter in der linken Spalte und Eingabefeldern bzw. Eingabe-Schaltflächen in der rechten Spalte aufweist. Als Eingabefelder können beispielsweise Felder zur Text-oder Zahleneingabe vorgesehen sein, und als Eingabe-Schaltflächen können Auslöseknöpfe (radio buttons) dienen.

Das vom Browser 26 angezeigte Konfigurierungsformular 30 ist eine grafi- sche Repräsentation von Formulardaten 32, die in einer Seitenbeschreibungs- sprache vorliegen. Im hier beschriebenen Ausführungsbeispiel wird als Seitenbeschreibungssprache HTML (hypertext markup language) bzw. XML (extensible markup language) verwendet, wobei XML den Vorteil einer besse- ren Trennung von Form und Inhalten hat. Neben dem eigentlichen Formu- larinhalt definieren die Formulardaten 32 auch das grafische Aussehen des

Konfigurierungsformulars 30, Textauszeichnungen, voreingestellte Werte und so weiter.

Der beispielhaft in Fig. 1 und Fig. 2 gezeigte Ausschnitt der Formulardaten 32 entspricht dem angezeigten Konfigurierungsformular 30, wobei jedoch aus Gründen der besseren Lesbarkeit in Fig. 1 und Fig. 2 die Formulardaten 32 nicht in HTML oder XML, sondern in einer übersichtlicheren Zwischen- sprache dargestellt sind. Jede mit einem der Schlüsselworte"ITEM"oder "SUBITEM"eingeleitete Zeile der Zwischensprache entspricht einer Zeile des Konfigurierungsformulars 30. Jede solche Zeile der Zwischensprache enthält mehrere durch"$"-Zeichen getrennte Abschnitte, die für die folgenden Ele- mente vorgesehen sind : einen eindeutigen Bezeichner des jeweiligen Konfi- gurationsparameters, den dem Benutzer anzuzeigenden Text, die Art des Eingabefelds bzw. der Eingabe-Schaltflächen, die Beschriftung des Eingabe- felds bzw. der Eingabe-Schaltflächen und den voreingestellten Wert (bei Eingabe-Schaltflächen durch einen Stern im Beschriftungsabschnitt gekenn- zeichnet). Die Zwischensprache kann automatisch in gültigen HTML-oder XML-Code umgesetzt werden.

Der Browser 26 ist dazu eingerichtet, die Einträge (z. B. Zahlen, Texte, Mar- kierungen von Schaltflächen und so weiter) des ausgefüllten Konfigurie- rungsformulars 30 in Form von Eingabedaten 34 an einen Servicerechner 36 (Fig. 1) zu übertragen. Die Formulardaten 32 weisen hierzu geeignete Kon- strukte auf, um die Übertragungsart und das Übertragungsformat der Ein- gabedaten 34 zu bestimmen.

Im vorliegenden Ausführungsbeispiel ist die Übertragungsart eine Übersen- dung der Eingabedaten 34 als E-Mail-Nachricht an eine durch die Formular- daten 32 vorgegebene Adresse des Servicerechners 36. Dies wird z. B. in

HTML dadurch erreicht, daß die Formulardaten 32 in einem"/cnM"-Tag die Methode"post"und die Aktion"mailto"mit der gewünschten E-Mail-Adresse als Parameter aufweisen. Das Übertragungsformat ist im hier beschriebenen Beispiel das sogenannte ta ;/value-Format, bei dem für jeden Konfigurie- rungsparameter eine Textzeile gesendet wird, die den in den Formulardaten 32 angegebenen, eindeutigen Bezeichner 38 des Konfigurierungsparameters und den im ausgefüllten Formular 30 angegebenen Wert 40 einander zuordnet. In Ausführungsalternativen sind andere Übertragungsformate und/oder andere Übertragungsarten vorgesehen ; insbesondere kann zur Übertragung der Eingabedaten 34 die Methode"get"verwendet werden.

Im Ausführungsbeispiel gemäß Fig. 1 ist der Servicerechner 36 als Server ausgestaltet, der unter anderem einen Übersetzer 42 ausführt. Der Über- setzer 42 dient zur Umwandlung der Eingabedaten 34 in die Ladedaten 24.

Dabei entspricht jedem Konfigurationsparameter (also jedem Bezeichner 38 in den Eingabedaten 34) eine festgelegte Byte-und Bitposition in den Lade- daten 24. Der Übersetzer 42 ist im hier beschriebenen Ausführungsbeispiel in einer Scriptsprache wie z. B. Python implementiert, die das Analysieren und Verarbeiten der textuellen Eingabedaten 34 gut unterstützt.

Um das Zahlungsverkehrsterminal 10 zu konfigurieren, lädt in dem Aus- führungsbeispiel von Fig. 1 der Benutzer zunächst an seinem Bedienungs- rechner 28 die Formulardaten 32 in den Browser 26. Die Formulardaten 32 können dem Benutzer beispielsweise als E-Mail-Anhang oder auf Diskette zugesandt worden sein. Alternativ kann der Benutzer die Formulardaten 32 von einem externen Server (beispielsweise dem Servicerechner 36) über das Internet in den Browser 26 laden. Der Benutzer füllt nun das angezeigte Konfigurierungsformular 30 aus. In weiterentwickelten Ausgestaltungen kann vorgesehen sein, daß der Browser 26-beispielsweise mittels JAVAS-

Applets-gewisse Konsistenzprüfungen vornimmt bzw. dem Benutzer Hilfestellungen leistet.

Ist das Formular 30 komplett ausgefüllt, betätigt der Benutzer eine vom Browser 26 angezeigte Sende-Schaltfläche (in den Zeichnungsfiguren nicht gezeigt). Der Browser 26 erzeugt daraufhin die Eingabedaten 34, welche die Bezeichner/Wert-Paare 38,40 für alle im Formular 30 vorgesehenen Konfi- gurationsparameter in dem textuellen E-Mail-Format enthalten. Schließlich sendet der Browser 26 die Eingabedaten 34 als E-Mail-Nachricht an den Servicerechner 36. Der durch den Servicerechner 36 ausgeführte Übersetzer 42 analysiert die Eingabedaten 34 und setzt sie in die Ladedaten 24 gemäß dem vom Zahlungsverkehrsterminal 10 geforderten Format um. Auch hier- bei werden vorzugsweise diverse Konsistenzüberprüfungen vorgenommen.

Ist der Umsetzvorgang erfolgreich beendet, baut im hier beschriebenen Aus- führungsbeispiel der Servicerechner 36 eine Datenfernübertragungs-Verbin- dung zur Kommunikationsschnittstelle 22 des Zahlungsverkehrsterminals 10 auf und sendet die Ladedaten 24 über diese Verbindung. Die Ladedaten 24 werden vom Mikrocontroller 12 interpretiert, und entsprechende Binärwerte werden in den Konfigurationsspeicherbereich 20 eingeschrieben. Der Konfi- gurationsvorgang ist damit abgeschlossen, und der Benutzer kann das kon- figurierte Zahlungsverkehrsterminal 10 sofort in Betrieb nehmen und testen.

In Ausführungsalternativen ist vorgesehen, daß der Servicerechner 36 die Ladedaten 24 nicht unmittelbar über die Datenfernübertragungs-Verbin- dung (z. B. eine Telefonverbindung) in das Zahlungsverkehrsterminal 10 lädt, sondern daß die Ladedaten 24 (z. B. per E-Mail oder auf Diskette oder auf einem durch das Zahlungsverkehrsterminal 10 unmittelbar lesbaren Datenträger) an den Benutzer gesendet werden. Der Benutzer kann dann-

gegebenenfalls unter Verwendung des Bedienungsrechners 28 oder eines weiteren lokalen Rechners-die Ladedaten selbst in das Zahlungsverkehrs- terminal 10 einspielen. Diese Variante ist insbesondere für die länder-oder kundenspezifische Konfigurierung mehrerer Zahlungsverkehrsterminals 10 vorgesehen.

Im Ausführungsbeispiel von Fig. 1 ist der Servicerechner 36 einem externen Kundendienstzentrum zugeordnet. Neben der Übermittlung der Konfigura- tionsdaten können auch Softwareaktualisierungen oder zusätzliche Soft- warekomponenten in das Zahlungsverkehrsterminal 10 eingespielt werden.

Für diese Dienste können differenzierte Gebühren verlangt werden. In einer Ausführungsalternative ist vorgesehen, den Übersetzer 42 nicht durch einen externen Servicerechner 36, sondern durch den Bedienungsrechner 28 aus- führen zu lassen. Der Bedienungsrechner 28 kann dann unmittelbar-z. B. über ein Firmennetz oder eine serielle Direktverbindung-die Ladedaten 24 an die Schnittstelle 22 des Zalllungsverkehrsterminals 10 übertragen. Ein externes Servicecenter ist in diesem Fall nicht erforderlich.

Bei dem Ausführungsbeispiel von Fig. 2 ist im Vergleich zu Fig. 1 ebenfalls der Servicerechner 36 entfallen. Gemäß Fig. 2 ist das Zahlungsverkehrs- terminal 10 hinsichtlich seines Mikrocontrollers 12 und des Programm-und Arbeitsspeichers 14 besonders leistungsfähig ausgestaltet. Der Übersetzer 42 kann daher direkt vom Mikrocontroller 12 des Zahlungsverkehrsterminals 10 ausgeführt werden. Das Zahlungsverkehrsterminal 10 ist demgemäß dazu eingerichtet, die Eingabedaten 34 über die Kommunikationsschnittstelle 22 unmittelbar von dem Browser 26 des Bedienungsrechners 28 zu erhalten.

Der Übersetzer 42 setzt diese Eingabedaten 34 dann in Ladedaten 24'um.

Die Ladedaten 24'im Ausführungsbeispiel von Fig. 2 sind keine textuellen

Zahlenfolgen, sondern die unmittelbar in den Konfigurationsspeicherbereich 20 eingeschriebenen Binärwerte.

Um die Anforderungen an das Zahlungsverkehrsterminal 10 in Grenzen zu halten, ist es bei dem Ausführungsbeispiel von Fig. 2 besonders wünschens- wert, daß der Bedienungsrechner 28 eine weitgehende Überprüfung der in das Konfigurierungsformular 30 eingetragenen Werte auf Konsistenz und Vollständigkeit vornimmt. Diese Überprüfung kann vom Browser 26 oder von einem weiteren durch den Bedienungsrechner 28 ausgeführten Pro- grammodul vorgenommen werden.

In der Darstellung von Fig. 3 sind die bereits beschriebenen Verarbeitungs- schritte nochmals schematisch gezeigt, nämlich das Bereitstellen der Formu- lardaten 32 (Schritt 50), das Anzeigen des Konfigurierungsformulars 30 durch den Browser 26 (Schritt 52), das Erzeugen der Eingabedaten 34 (Schritt 54), das Erzeugen der Ladedaten 24, 24'aus den Eingabedaten 34 (Schritt 56) und das Konfigurieren des Zahlungsverkehrsterminals 10 auf Grundlage der Ladedaten 24,24'. Ferner veranschaulicht Fig. 3 mehrere Ausführungs- varianten, in denen dieses Grundverfal-iren erweitert wird.

Eine erste Erweiterungsrichtung betrifft die Verwendung von Datenbank- Informationen bei der Konfigurierung. Fig. 3 zeigt hier zwei alternativ oder kumulativ einsetzbare Möglichkeiten, nämlich erstens den Zugriff auf eine erste Datenbank 60 im Zusammenhang mit dem Erzeugen der Formular- daten 32 in Schritt 50 und zweitens den Zugriff auf eine zweite Datenbank 62 im Zusammenhang mit dem Erzeugen der Ladedaten 24, 24' in Schritt 56.

Die Darstellung zweier Datenbanken 60,62 in Fig. 3 ist lediglich konzeptuell zu verstehen ; in tatsächlichen Implementierungen können alle erforderlichen Daten in einer einzigen Datenbank gespeichert sein. Die benötigten Informa-

tionen können von den Datenbanken 60,62 z. B. über ein Rechnernetz oder auch per E-Mail übertragen werden.

In der oben erstgenannten Möglichkeit werden die aus der ersten Datenbank 60 ausgelesenen Informationen beispielsweise in versteckte Einträge des Konfigurierungsformulars 30 aufgenommen oder als voreingestellte Werte in sichtbaren und änderbaren Einträgen des Konfigurierungsformulars 30 angezeigt oder als sichtbare und unveränderliche Einträge des Konfigurie- rungsformulars 30 angezeigt. Alle diese Einträge nimmt der Browser 26 in üblicher Weise in die Eingabedaten 34 auf.

In der oben zweitgenannten Möglichkeit werden die Informationen aus der zweiten Datenbank 62 erst vom Übersetzer 42 verarbeitet und mit den Ein- gabedaten 34 kombiniert, um die Ladedaten 24,24'zu erhalten. Hierbei kann auch vorgesehen sein, aus einer einzigen Eingabedaten-Nachricht mehrere Sätze von Ladedaten 24, 24'zu erzeugen, die sich jeweils aus den Eingabe- daten 34 und den Daten je eines von mehreren Datensätzen der Datenbank 62 ergeben. Auf diese Weise können gemeinsame Einstellungen für eine Vielzahl von Zahlungsverkehrsterminals 10 über den Browser 26 vorgenom- men werden, während die für die einzelnen Zahlungsverkehrsterminals 10 unterschiedlichen Werte (z. B. Standortdaten oder Identifikationsnummern) aus der Datenbank 62 entnommen werden.

Die zweite Erweiterungsrichtung aller bisher beschriebenen Ausführungs- beispiele ist es, im Zahlungsverkehrsterminal 10 auch eine Funktion zum zumindest teilweisen Auslesen der im Konfigurationsspeicherbereich 20 enthaltenen Konfigurationsdaten vorzusehen. Wie in Fig. 3 unterhalb der gestrichelten Linie dargestellt ist, werden hierbei in Schritt 64 die Konfigura- tionsdaten aus dem Konfigurationsspeicherbereich 20 ausgelesen und in

Ausgabedaten umgewandelt. Die Ausgabedaten bzw. darauf basierende Informationen können in einer dritten Datenbank 66 gespeichert und/oder durch den Servicerechner 36 oder den Bedienungsrechner 28 oder einen anderen Computer angezeigt werden. In Schritt 68 wird beispielhaft ein auf Grundlage der Ausgabedaten basierendes Ausgabeformular durch den Browser 26 dargestellt. Wieder ist die Bezeichnung der Datenbank 66 als "dritte"Datenbank lediglich konzeptuell zu verstehen ; in realen Implemen- tierungen wird die Datenbank 66 oft identisch mit der Datenbank 60 und/oder der Datenbank 62 sein.

Fig. 4 zeigt eine beispielhafte Abwandlung des Systems von Fig. 1, bei der die gerade beschriebene Auslese-und Rückmeldefunktion vorgesehen ist.

Der Umwandlungsvorgang gemäß Schritt 64 (Fig. 3) erfolgt in Reaktion auf jede Änderung der Konfiguration und/oder auf die Erstinstallation und/oder auf eine explizite Aufforderung. Im vorliegenden Beispiel sind die Ausgabedaten 70 lediglich eine einfache textuelle Darstellung des Inhalts des Konfigurationsspeicherbereichs 20, während in Ausführungsalternativen komplexere Verarbeitungsschritte erfolgen können. Es kann vorgesehen sein, daß besonders sicherheitskritische Abschnitte des Konfigurations- speicherbereichs 20 vor dem Auslesen geschützt sind.

In dem Beispiel von Fig. 4 werden die Ausgabedaten 70 über die Kommuni- kationsschnittstelle 22 zum Servicerechner 36 übertragen. Der Servicerechner 36 führt weitere geeignete Umwandlungsschritte aus. Dabei können die Informationen aus den Ausgabedaten 70 in die Datenbank 66 exportiert wer- den und/oder in eine Ausgabeseite 72 umgeformt werden. Die Ausgabeseite 72 ist in einer vom Browser 26 interpretierbaren Seitenbeschreibungssprache abgefaßt. Der Servicerechner 36 dient ferner als Server, der in Reaktion auf eine Anfrage 74 des Browsers 26 die Ausgabeseite 72 als Antwort an den

Browser 26 sendet. Der Browser 26 zeigt die Ausgabeseite 72 dann in Form des Ausgabeformulars 76 an.

Im hier beschriebenen Ausführungsbeispiel entspricht das Ausgabeformular 76 nicht nur in seiner äußeren Gestaltung dem Konfigurierungsformular 30, sondern es kann vielmehr als Konfigurierungsformular 30 für einen weiteren Durchlauf des erfindungsgemäßen Verfahrens verwendet werden. Mit ande- ren Worten enthält die Ausgabeseite 72 bereits alle zur weiteren Konfigurie- rung benötigten Formulardaten 32. Die aktuelle Konfiguration wird in Form von änderbaren Einträgen in dem als neues Konfigurierungsformular 30 die- nenden Ausgabeformular 76 dargestellt. Insgesamt kann damit der Benutzer die aktuelle Konfigurierung des Zahlungsverkehrsterminals 10 abfragen, am Browser 26 ändern, und die geänderte Konfigurierung in das Zahlungsver- kehrsterminal 10 zurückschreiben.

In dem Beispiel von Fig. 4 ist der Servicerechner 36 als zentrale Instanz für das Verarbeiten der Ausgabedaten 70 gezeigt. Es versteht sich aber, daß diese Aufgabe von jedem anderen bisher beschriebenen Computer-oder von dem Zahlungsverkehrsterminal 10 oder einem zusätzlichen Rechner- übernommen werden kann.

In allen hier beschriebenen Ausführungsbeispielen kann zusätzliche Mani- pulationssicherheit durch die Verwendung von elektronischen Prüfsummen und/oder Unterschriften bei den übertragenen Datensätzen erzielt werden.

In diesem Zusammenhang können auch Autorisierungsprüfungen-gegebe- nenfalls mit unterschiedlichen Autorisierungsstufen-erfolgen.