DE10215005A1

DE10215005A1 - Konfigurieren eines Zahlungsverkehrsterminals

Info

Publication number: DE10215005A1
Application number: DE10215005A
Authority: DE
Inventors: Arndt Berthold; Andreas Johne
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2002-04-05
Filing date: 2002-04-05
Publication date: 2003-10-23
Also published as: WO2003085611A2; AU2003226767A1; WO2003085611A3; AU2003226767A8

Abstract

Bei einem Verfahren zum Konfigurieren eines Zahlungsverkehrsterminals (10) wird ein ausfüllbares Konfigurierungsformular (30) durch einen von einem Bedienungsrechner (28) ausgeführten Browser (26) angezeigt, Eingabedaten (34), die Einträgen im ausgefüllten Konfigurierungsformular (30) entsprechen und die ein durch den Browser (26) vorgegebenes Datenformat aufweisen, werden von dem Browser (26) zu einem Übersetzer (42) übermittelt, Ladedaten (24) werden in Abhängigkeit von den Eingabedaten (34) durch den Übersetzer (42) erzeugt, wobei die Ladedaten (24) ein durch das Zahlungsverkehrsterminal (10) vorgegebenes Datenformat aufweisen, und das Zahlungsverkehrsterminal (10) wird mittels der Ladedaten (24) konfiguriert. Ein computerlesbarer Datenträger und ein Zahlungsverkehrsterminal weisen entsprechende Merkmale auf. Durch die Erfindung wird die Konfiguration von Zahlungsverkehrsterminals vereinfacht, Fehler werden vermieden und der erforderliche Zeit- und Kostenaufwand wird verringert.

Description

Die Erfindung betrifft das technische Gebiet des Konfigurierens von Zahlungsverkehrsterminals. Unter einem Zahlungsverkehrsterminal soll im vorliegenden Dokument insbesondere jedes Gerät verstanden werden, das Transaktionen unter Verwendung einer Chipkarte oder eines sonstigen elektronischen Identifizierungs- und/oder Speichermittels durchführt. 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 Zahlungsverkehrsterminals kunden- und/oder gerätespezifisch konfiguriert werden. Dabei werden beispielsweise die Gerätekonfiguration, der Funktionsumfang, gerätespezifische Kopfdaten (Kontonummer, Standortdaten, Terminalbezeichner, . . .) und/oder kundenspezifische Anzeigentexte eingestellt. Es ist bekannt, 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 kommen, 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 Zahlungsverkehrsterminals zu vereinfachen, Fehler zu vermeiden und den erforderlichen Zeit- und Kostenaufwand zu verringern.
Erfindungsgemäß wird diese Aufgabe ganz oder teilweise durch ein Verfahren mit den Merkmalen des Anspruchs 1, einen computerlesbaren Datenträger gemäß Anspruch 12 sowie ein Zahlungsverkehrsterminal gemäß Anspruch 13 gelöst. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen 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 erfindungsgemäß 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 Übersetzer übermittelt. Der Übersetzer erzeugt Ladedaten in Abhängigkeit von den Eingabedaten und gegebenenfalls weiteren Informationen. Die Ladedaten weisen ihrerseits ein durch das Zahlungsverkehrsterminal vorgegebenes Datenformat auf und dienen zur Konfigurierung des Zahlungsverkehrsterminals.
Die erfindungsgemäß vorgeschlagene Automatisierung führt zu einer höheren Qualität des Konfigurationsvorgangs, weil manuelle Bearbeitungsfehler vermieden werden. Änderungen können schneller und mit geringerem Aufwand für den Kundendienst durchgeführt werden. Die Erfindung macht es überdies praktikabel, Zahlungsverkehrsterminals mit erweiterten Konfigurationsmöglichkeiten auszustatten, die sich bisher nicht effizient hätten nutzen lassen.
In bevorzugten Ausgestaltungen der Erfindung wird das Konfigurierungsformular 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 erleichtert werden. Der Browser kann ein üblicher Internet-Browser sein. Das Konfigurierungsformular kann von einem externen Server oder von einem lokalen 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 Zahlungsverkehrsterminal kann vorgesehen sein, daß sich die Konfigurierung auf Kopfdaten (Daten mit individuellem Terminalbezug) und/oder auf kundenspezifische Daten (z. B. Telefonnummern oder Kundennamen) und/oder auf länderspezifische 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 Zahlungsverkehrsterminals an die unterschiedlichen Sprachen.
Das vom Browser vorgegebene Datenformat, in dem dieser die Eingabedaten 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. Vorzugsweise 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 Zahlungsverkehrsterminals ausgeführt. In den beiden erstgenannten Fällen wird vorzugsweise eine Kommunikationsschnittstelle des Zahlungsverkehrsterminals verwendet, um die extern berechneten Ladedaten in das Zahlungsverkehrsterminal zu übertragen und dort den Konfigurationsvorgang auszulösen. In der dritten genannten Alternative dient die Kommunikationsschnittstelle vorzugsweise zum Übertragen der Eingabedaten. In einer vorteilhaften Weiterbildung wird die Kommunikationsschnittstelle nicht nur zum Zwecke der Konfigurierung, sondern auch im normalen Betrieb des Zahlungsverkehrsterminals, beispielsweise zum Anschluß des Zahlungsverkehrsterminals an eine Telefonleitung oder ein Firmennetz, verwendet.
Erfindungsgemäß werden die Ladedaten in Abhängigkeit von den Eingabedaten erzeugt. In manchen Ausgestaltungen findet hier lediglich ein Umsetzvorgang statt, der den Eingabedaten keine weiteren Informationen hinzufügt. In anderen Ausgestaltungen ist dagegen vorgesehen, daß zur Erzeugung der Ladedaten neben den Eingabedaten weitere Informationen ausgewertet 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 erforderlichen Informationen jeweils einzeln über die vom Browser bereitgestellte Bedienoberfläche eingegeben werden müssen. Dies ist insbesondere dann bedeutsam, wenn viele Zahlungsverkehrsterminals mit ähnlichen Konfigurationen versehen werden sollen.
Neben dem Einspielen von Eingabe- und/oder Ladedaten kann in bevorzugten Ausgestaltungen auch eine Funktionalität zum Auslesen von Konfigurationsdaten 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 Festplatte oder CD-ROM sein, ist aber nicht auf körperliche Datenträger beschränkt. Auch elektrische oder optische Signale, z. B. Spannungspegel einer Kommunikationsverbindung, sollen im hier verwendeten Sinne als computerlesbare Datenträger aufgefaßt werden. Der Datenträger enthält erfindungsgemäß Computerbefehle, die den Umsetzvorgang zwischen den Eingabedaten und den Ladedaten steuern.
Das erfindungsgemäße Zahlungsverkehrsterminal ist zum Übersetzen der über die Kommunikationsschnittstelle empfangenen Eingabedaten des externen Browsers in die Ladedaten eingerichtet. Das Zahlungsverkehrsterminal 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 eingeschrieben 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 genannten 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 Zeichnungen 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 Mikrocontroller 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äuterung des Auslesens von Konfigurationsdaten aus dem Zahlungsverkehrsterminal.
Das in Fig. 1 und Fig. 2 gezeigte Zahlungsverkehrsterminal 10 dient in seinem 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® 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 Komponenten 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 Figuren nicht gezeigt.
Der Programm- und Arbeitsspeicher 14 weist einen beschreibbaren, nichtflüchtigen Konfigurationsspeicherbereich 20 auf, der terminal- und kundenspezifische Konfigurationsdaten enthält. Im hier beschriebenen Ausführungsbeispiel umfassen die Konfigurationsdaten ungefähr 50 Einstelloptionen, 100 Funktionskonfigurationen, 60 Telefonnummern, 10 terminalspezifische Daten (Kopfdaten) und 2 × 16 Zeichen kundenspezifischen Text. In Ausführungsalternativen können mehr oder weniger Konfigurationsdaten vorgesehen sein; insbesondere kann vorgesehen sein, daß die Konfigurationsdaten 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 Konfigurationsspeicherbereich 20 enthalten, der entsprechend größer ausgelegt sein muß.
Das Zahlungsverkehrsterminal 10 weist ferner eine Kommunikationsschnittstelle 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 Datenaustausch mit einem lokalen oder netzwerkgekoppelten Computer oder einer Registrierkasse genutzt. Über die Kommunikationsschnittstelle 22 können jedoch bei dem Ausführungsbeispiel von Fig. 1 auch Ladedaten 24 in einem durch das Zahlungsverkehrsterminal 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 Anfangsadresse - eine Folge von Hexadezimalzahlen im ASCII-Code enthalten, die vom Mikrocontroller 12 in Bytes umgewandelt und in aufsteigender Reihenfolge in den Konfigurationsspeicherbereich 20 geschrieben werden. Eine derartige Konfigurierungsmöglichkeit ist aus dem bereits erwähnten Ladeterminal ZVT® 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 verwendet, der von einem Bedienungsrechner 28 ausgeführt wird (in Fig. 1 und Fig. 2 ist der Browser 26 durch sein auf dem Bildschirm des Bedienungsrechners 28 angezeigtes Hauptfenster dargestellt). Der Browser 26 ist ein üblicher Internet-Browser, wie er beispielsweise unter den Bezeichnungen Microsoft® Internet Explorer® oder Netscape® Navigator® bekannt ist. Der Bedienungsrechner 28 ist ein üblicher persönlicher Computer.
Beim Konfigurationsvorgang zeigt der Browser 26 ein Konfigurierungsformular 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 grafische Repräsentation von Formulardaten 32, die in einer Seitenbeschreibungssprache vorliegen. Im hier beschriebenen Ausführungsbeispiel wird als Seitenbeschreibungssprache HTML (hypertext markup language) bzw. XML (extensible markup language) verwendet, wobei XML den Vorteil einer besseren Trennung von Form und Inhalten hat. Neben dem eigentlichen Formularinhalt 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 Zwischensprache 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 Elemente vorgesehen sind: einen eindeutigen Bezeichner des jeweiligen Konfigurationsparameters, den dem Benutzer anzuzeigenden Text, die Art des Eingabefelds bzw. der Eingabe-Schaltflächen, die Beschriftung des Eingabefelds bzw. der Eingabe-Schaltflächen und den voreingestellten Wert (bei Eingabe-Schaltflächen durch einen Stern im Beschriftungsabschnitt gekennzeichnet). 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, Markierungen von Schaltflächen und so weiter) des ausgefüllten Konfigurierungsformulars 30 in Form von Eingabedaten 34 an einen Servicerechner 36 (Fig. 1) zu übertragen. Die Formulardaten 32 weisen hierzu geeignete Konstrukte auf, um die Übertragungsart und das Übertragungsformat der Eingabedaten 34 zu bestimmen.
Im vorliegenden Ausführungsbeispiel ist die Übertragungsart eine Übersendung der Eingabedaten 34 als E-Mail-Nachricht an eine durch die Formulardaten 32 vorgegebene Adresse des Servicerechners 36. Dies wird z. B. in HTML dadurch erreicht, daß die Formulardaten 32 in einem "form"-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 tag/value-Format, bei dem für jeden Konfigurierungsparameter 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 Übersetzer 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 Ladedaten 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 Ausführungsbeispiel von Fig. 1 der Benutzer zunächst an seinem Bedienungsrechner 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 JAVA®- 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 Konfigurationsparameter 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 hierbei werden vorzugsweise diverse Konsistenzüberprüfungen vorgenommen.
Ist der Umsetzvorgang erfolgreich beendet, baut im hier beschriebenen Ausführungsbeispiel der Servicerechner 36 eine Datenfernübertragungs-Verbindung 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 Konfigurationsvorgang ist damit abgeschlossen, und der Benutzer kann das konfigurierte 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-Verbindung (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 Zahlungsverkehrsterminal 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 Konfigurationsdaten können auch Softwareaktualisierungen oder zusätzliche Softwarekomponenten 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 ausfü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 Zahlungsverkehrsterminals 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 Zahlungsverkehrsterminal 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ünschenswert, 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 Programmodul vorgenommen werden.
In der Darstellung von Fig. 3 sind die bereits beschriebenen Verarbeitungsschritte nochmals schematisch gezeigt, nämlich das Bereitstellen der Formulardaten 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ührungsvarianten, in denen dieses Grundverfahren 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 Formulardaten 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 Informationen 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 Konfigurierungsformulars 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 Eingabedaten 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 Eingabedaten 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 vorgenommen 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ührungsbeispiele 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 Konfigurationsdaten 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 Implementierungen 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 J 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 Konfigurationsspeicherbereichs 20 vor dem Auslesen geschützt sind.
In dem Beispiel von Fig. 4 werden die Ausgabedaten 70 über die Kommunikationsschnittstelle 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 werden 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 anderen Worten enthält die Ausgabeseite 72 bereits alle zur weiteren Konfigurierung benötigten Formulardaten 32. Die aktuelle Konfiguration wird in Form von änderbaren Einträgen in dem als neues Konfigurierungsformular 30 dienenden 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 Zahlungsverkehrsterminal 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 Manipulationssicherheit 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 - gegebenenfalls mit unterschiedlichen Autorisierungsstufen - erfolgen.

Claims

1. Verfahren zum Konfigurieren eines Zahlungsverkehrsterminals (10), mit den Schritten:

- Anzeigen eines ausfüllbaren Konfigurierungsformulars (30) durch einen von einem Bedienungsrechner (28) ausgeführten Browser (26),

- Übermitteln von Eingabedaten (34), die Einträgen im ausgefüllten Konfigurierungsformular (30) entsprechen und die ein durch den Browser (26) vorgegebenes Datenformat aufweisen, von dem Browser (26) zu einem Übersetzer (42),

- Erzeugen von Ladedaten (24, 24') durch den Übersetzer (42) in Abhängigkeit von den Eingabedaten (34), wobei die Ladedaten (24, 24') ein durch das Zahlungsverkehrsterminal (10) vorgegebenes Datenformat aufweisen, und

- Konfigurieren des Zahlungsverkehrsterminals (10) mittels der Ladedaten (24, 24').

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Konfigurierungsformular (30) in Form von in einer Seitenbeschreibungssprache verfaßten Formulardaten (32) an den Browser (26) übermittelt wird.

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß die Eingabedaten (34) mindestens einen von dem Zahlungsverkehrsterminal (10) anzuzeigenden oder zu druckenden Text aufweisen.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das von dem Browser (26) vorgegebene Datenformat für die Eingabedaten (34) ein Textformat ist, das Bezeichner/Wert-Paare (38, 40) aufweist.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß zum Konfigurieren des Zahlungsverkehrsterminals (10) die Ladedaten (24) über eine Kommunikationsschnittstelle (22) in das Zahlungsverkehrsterminal (10) übertragen werden, und daß der Speicherinhalt eines Konfigurationsspeicherbereichs (20) des Zahlungsverkehrsterminals (10) entsprechend den Ladedaten (24) verändert wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß das Erzeugen der Ladedaten (24) von dem Bedienungsrechner (28) und/oder einem externen Servicerechner (36) ausgeführt wird.

7. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Eingabedaten (34) über eine Kommunikationsschnittstelle (22) in das Zahlungsverkehrsterminal (10) übertragen werden, und daß das Umsetzen der Eingabedaten (34) in die Ladedaten (24') von einem Mikrocontroller (12) des Zahlungsverkehrsterminals (10) ausgeführt wird, und daß der Speicherinhalt eines Konfigurationsspeicherbereichs (20) des Zahlungsverkehrsterminals (10) entsprechend den Ladedaten (24') verändert wird.

8. Verfahren nach Anspruch 5 oder Anspruch 7, dadurch gekennzeichnet, daß die Kommunikationsschnittstelle (22) auch im normalen Betrieb des Zahlungsverkehrsterminals (10) verwendet wird.

9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß das Konfigurierungsformular (30) mindestens einen sichtbaren oder verborgenen Eintrag aufweist, der in Abhängigkeit von aus einer Datenbank (60) erhaltenen Informationen vorbesetzt ist.

10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die Ladedaten (24, 24') in Abhängigkeit von den Eingabedaten (34) und ferner in Abhängigkeit von aus einer Datenbank (62) erhaltenen Informationen ermittelt werden.

11. Verfahren nach einem der Anspüche 1 bis 10, dadurch gekennzeichnet, daß Ausgabedaten (70), die zumindest Teile der Konfiguration des Zahlungsverkehrsterminals (10) angeben, aus dem Zahlungsverkehrsterminal 10 ausgelesen werden, und daß Informationen, die den ausgelesenen Ausgabedaten (70) entsprechen, angezeigt und/oder in einer Datenbank (66) gespeichert werden.

12. Computerlesbarer Datenträger mit Programmbefehlen zur Ausführung durch mindestens einen Prozessor, um Ladedaten (24, 24') in Abhängigkeit von Eingabedaten (34), die Einträgen in einem durch einen externen Browser (26) angezeigten Konfigurationsformular (30) entsprechen und die ein durch den Browser (26) vorgegebenes Datenformat aufweisen, zu erzeugen, wobei die Ladedaten (24) ein zum Konfigurieren eines Zahlungsverkehrsterminals (10) vorgegebenes Datenformat aufweisen.

13. Zahlungsverkehrsterminal (10), das dazu eingerichtet ist, über eine Kommunikationsschnittstelle (22) Eingabedaten (34) zu empfangen, die in Abhängigkeit von Einträgen in einem durch einen externen Browser (26) angezeigten Konfigurationsformular (30) erzeugt worden sind und die ein durch den Browser (26) vorgegebenes Datenformat aufweisen, und das einen Mikrocontroller (12) aufweist, um die Eingabedaten (34) in Ladedaten (24') umzusetzen und den Speicherinhalt eines Konfigurationsspeicherbereichs (20) des Zahlungsverkehrsterminals (10) entsprechend den Ladedaten (24') zu verändern.

14. Zahlungsverkehrsterminal (10) nach Anspruch 13, dadurch gekennzeichnet, daß das Zahlungsverkehrsterminal (10) zur Ausgabe von Ausgabedaten (70), die dem Speicherinhalt des Konfigurationsspeicherbereichs (20) zumindest teilweise entsprechen, über die Kommunikationsschnittstelle (22) eingerichtet ist.