DE10156783A1

DE10156783A1 - Steuerung eines Zahlungsverkehrsterminals

Info

Publication number: DE10156783A1
Application number: DE2001156783
Authority: DE
Inventors: Arndt Berthold; Ludger Holtmann; Andreas Johne; Bernhard Pluhatsch; Gabriele Willer-Scheib
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2001-11-19
Filing date: 2001-11-19
Publication date: 2003-05-28
Also published as: WO2003044751A2; AU2002365986A1; AU2002365986A8; WO2003044751A3

Abstract

Bei einem Verfahren zur Steuerung eines Zahlungsverkehrsterminals erfolgt die Steuerung zumindest zum Teil gemäß Programmbefehlen (80x), die jeweils einen Befehlsteil und eine Gültigkeitsbedingung aufweisen, wobei nur solche Programmbefehle (80x) ausgeführt werden, deren jeweilige Gültigkeitsbedingung zur Laufzeit erfüllt ist. Bei einem weiteren solchen Verfahren werden die Programmbefehle (80x) mittels eines Interpreters des Zahlungsverkehrsterminals zur Laufzeit interpretiert. Ein computerlesbarer Datenträger und ein Zahlungsverkehrsterminal weisen entsprechende Merkmale auf. Durch die Erfindung werden die technischen Grundlagen geschaffen, um die Programmierung von Zahlungsverkehrsterminals und/oder deren Anpassung an geänderte Gegebenheiten zu erleichtern.

Description

Die Erfindung betrifft das technische Gebiet der Steuerung und Programmierung 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 insbesondere für bargeldlose Zahlungen aller Art mittels Kreditkarten, ec-Karten, Bankkarten oder Geldkarten eingesetzt. In der hier verwendeten Wortwahl werden als Zahlungsverkehrsterminals auch Geldautomaten und Automaten zum Auffüllen von Geldkarten angesehen, sowie Geräte, die lediglich indirekt mit Zahlungs- und Abrechnungsvorgängen zu tun haben (z. B. Kontoauszugsdrucker oder Zugangskontrollsysteme).
Es ist bekannt, bei derartigen Zahlungsverkehrsterminals die erforderlichen Abläufe (z. B. Transaktionen mit der Chipkarte oder mit einem Hintergrundsystem, Ansteuerung einer Anzeige oder eines Druckers, Eingabevorgänge) durch ein in Assembler oder in einer höheren Programmiersprache geschriebenes Programm zu steuern. Erfolgt die Programmierung beispielsweise in der Programmiersprache C, so wird das Quellprogramm mittels eines Compilers in einen vom Prozessor des Zahlungsverkehrsterminals unmittelbar ausführbaren Objektcode umgesetzt.
Solche in einer allgemeinen Programmiersprache geschriebenen Steuerprogramme sind jedoch komplex und unübersichtlich. Sie sind anfällig für Programmierfehler und lassen sich nur mit hohem Aufwand warten. Eine Anpassung an Kundenwünsche, geänderte Spezifikationen und Änderungsanforderungen von Netzbetreibern ist komplex und aufwendig. Ein in Assembler geschriebenes Programm muss für jede Hardwareplattform neu entwickelt werden. Auch bei Programmen in einer höheren Programmiersprache (z. B. der Sprache C) sind für jede neue Hardware erhebliche Anpassungsarbeiten erforderlich.
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 Programmierung von Zahlungsverkehrsterminals und/oder die Anpassung an geänderte Gegebenheiten zu erleichtern. Ferner soll eine möglichst weitgehende Hardwareunabhängigkeit des Steuerprogramms erreicht werden.
Erfindungsgemäß wird diese Aufgabe durch Verfahren mit den Merkmalen der Ansprüche 1 und 6 sowie durch einen computerlesbaren Datenträger gemäß Anspruch 8 und ein Zahlungsverkehrsterminal gemäß Anspruch 9 gelöst. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung geht von der Grundidee aus, zur Steuerung eines Zahlungsverkehrsterminals nicht ein in einer Allzweck-Programmiersprache geschriebenes Programm zu verwenden, sondern vielmehr ein Steuerprogramm, das speziell auf die Erfordernisse und Gegebenheiten bei Zahlungsverkehrsterminals zugeschnitten ist.
Gemäß einem ersten Aspekt der Erfindung ist vorgesehen, dass die Steuerung des Zahlungsverkehrsterminals zum Teil oder vollständig gemäß Programmbefehlen erfolgt, die jeweils einen Befehlsteil und eine Gültigkeitsbedingung aufweisen, wobei jeder Programmbefehl nur bei zur Laufzeit erfüllter Gültigkeitsbedingung ausgeführt wird. Diese Maßnahme stellt eine Abkehr von der bei herkömmlichen Allzweck-Programmiersprachen üblichen Technik dar, unterschiedliche Konstrukte für Bedingungen und Instruktionen zu verwenden.
Die erfindungsgemäße Technik ist insbesondere deshalb besonders vorteilhaft, weil sie eine Programmierung des Zahlungsverkehrsterminals auf eine Weise ermöglicht, die der Darstellung in typischen Spezifikationen für Transaktionsvorgänge ähnelt. Auf der Grundlage einer derartigen Spezifikation, die eine Folge von Ein- und Ausgabeaktionen unter vor gegebenen Bedingungen darstellt, kann das Steuerprogramm relativ leicht entwickelt werden. Der erforderliche Zeit- und Arbeitsaufwand wird verringert, und Fehler werden vermieden. Auch eine Anpassung an geänderte Spezifikationen oder an Kundenwünsche ist besonders einfach und schnell möglich.
Erfindungsgemäß erfolgt die Steuerung des Zahlungsverkehrsterminals zumindest zum Teil gemäß Programmbefehlen, die eine bestimmte Struktur aufweisen. Diese Formulierung soll auch den Fall umfassen, dass die Programmbefehle die genannte Struktur nur während der Programmentwicklung und nicht mehr zur Laufzeit des Steuerprogramms aufweisen. Beispielsweise kann in manchen Ausführungsformen das Steuerprogramm durch einen Compiler in maschinensprachliche Programmstrukturen übersetzt werden, die im Hinblick auf die Ausführungsgeschwindigkeit und/oder den Speicherplatz optimiert sind und daher keine Beziehung zu der erfindungsgemäß geforderten Struktur mehr haben. In bevorzugten Ausführungsformen ist jedoch diese Struktur der Programmbefehle (Befehlsteil und Gültigkeitsbedingung) auch zur Laufzeit des Steuerprogramms noch vorhanden, weil allenfalls Codierungsschritte vorgenommen werden, die eine effiziente Speicherung und/oder Interpretierung der Programmbefehle erlauben, ohne jedoch ihren grundsätzlichen Aufbau zu verändern.
Nach einem zweiten Aspekt der Erfindung ist ein Interpreter vorgesehen, der nicht-maschinensprachliche Programmbefehle während der Programmlaufzeit interpretiert. Eine derartige Verwendung eines Interpreters verringert die Hardwareabhängigkeit des Steuerprogramms erheblich, weil der Interpreter als abstrakte, für mehrere Hardwareumgebungen einheitliche Maschine angesehen werden kann. Ein und dasselbe Steuerprogramm ist daher für Zahlungsverkehrsterminals unterschiedlichster Bauart verwendbar. Die insgesamt anfallenden Entwicklungskosten werden dadurch erheblich verringert. Überdies werden durch diesen Aspekt der Erfindung die technischen Grundlagen geschaffen, um einen Programmbefehlssatz anbieten zu können, der besonders leistungsfähige und/oder spezifikationsnahe Programmbefehle enthält. Auch durch diese Maßnahme ergibt sich eine erhebliche Steigerung der Produktivität und Qualität bei der Erstellung von Steuerprogrammen für Zahlungsverkehrsterminals.
In bevorzugten Ausführungsformen sind die beiden bisher beschriebenen Aspekte der Erfindung miteinander kombiniert, um eine Kombination der genannten Vorteile zu erreichen.
Vorzugsweise ist die Gültigkeitsbedingung aus mehreren unterschiedlichen Bedingungsarten zusammengesetzt. Insbesondere können eine oder mehrere Überfahrbedingungen und/oder eine oder mehrere einfache Ausführungsbedingungen und/oder eine oder mehrere kombinierte Ausführungsbedingungen vorgesehen sein. Der Befehlsteil ist in bevorzugten Ausführungsformen in einen Funktionsabschnitt und einen Parameterabschnitt gegliedert, wobei der Funktionsabschnitt seinerseits zumindest bei manchen Programmbefehlen eine Befehlsgruppe und einen Befehlstyp angeben kann.
Eine besonders speicherplatzsparende Codierung der Programmbefehle nutzt die Tatsache aus, dass bei in der Praxis auftretenden Steuerprogrammen viele Programmbefehle identische oder zumindest teilweise identische Gültigkeitsbedingungen aufweisen. Wenn die Programmbefehle teils in einem Befehlsspeicherbereich und teils in einem Bedingungsspeicherbereich abgelegt werden, so brauchen identische Gültigkeitsbedingungen oder Teile davon nur einmal in dem Bedingungsspeicherbereich enthalten zu sein. Es können dann mehrere Programmbefehle auf ein und dieselben Daten im Bedingungsspeicherbereich verweisen.
Eine für die Programmentwicklung besonders vorteilhafte Darstellung des Steuerprogramms weist eine Haupttabelle und gegebenenfalls eine oder mehrere Nebentabellen auf. Vorzugsweise sind Hilfsmittel vorgesehen, um ein in Tabellenform dargestelltes Steuerprogramm zu bearbeiten und um es in eine für den Interpreter verarbeitbare Codierung umzuwandeln.
Der erfindungsgemäß vorgesehene computerlesbare 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 aufgefasst werden.
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 der Erfindung hervor. Es wird auf die schematischen Zeichnungen verwiesen, in denen zeigen:
Fig. 1 eine Darstellung von Hardware- und Softwareebenen bei einem Zahlungsverkehrsterminal nach einem Ausführungsbeispiel der Erfindung,
Fig. 2 eine beispielhafte Darstellung einer Haupttabelle in dem Ausführungsbeispiel von Fig. 1,
Fig. 3 eine beispielhafte Spezifikation eines Datensatz-Formats,
Fig. 4 eine beispielhafte Spezifikation eines Transaktionsablaufs,
Fig. 5A und Fig. 5B eine beispielhafte Darstellung einer Haupttabelle für die Spezifikation gemäß Fig. 4,
Fig. 6 ein Flußdiagramm der von einem Interpreter ausgeführten Programmschleife,
Fig. 7 eine beispielhafte Darstellung einer Codierung der Haupttabelle von Fig. 2 während der Laufzeit des Steuerprogramms, und
Fig. 8 ein Ablaufschema eines Umsetzvorgangs zur Erzeugung eines ladbaren Steuerprogramms.
In der Darstellung von Fig. 1 ist ein Zahlungsverkehrsterminal in seinen aufeinander aufbauenden funktionalen Schichten gezeigt. Eine Hardwareschicht 10 weist die Hardware-Elemente des Zahlungsverkehrsterminals auf. Hinsichtlich seines Hardware-Aufbaus ist das Zahlungsverkehrsterminal als solches bekannt. Es weist einen Prozessor 12 auf, der auf einen Arbeitsspeicher 14, z. B. RAM und EEPROM, und einen Programmspeicher 16, z. B. ROM und EEPROM, zugreift. Die noch zu beschreibende Software des Zahlungsverkehrsterminals ist in dem Programmspeicher 16 enthalten.
Der Prozessor 12 ist ferner über einen Bus 18 mit einer Chipkarten-Schnittstelle 20, einer Nachrichten-Schnittstelle 22, einem Krypto-Prozessor 24, einer Drucker-Schnittstelle 26, einer Tastatur-Schnittstelle 28, einer Anzeigen- Schnittstelle 30 und einem Zeitgeber 32 verbunden. Eine Chipkarte 34 ist an die Chipkarten-Schnittstelle 20 anschließbar. Die Chipkarte 34 ist nicht Bestandteil des Zahlungsverkehrsterminals und deshalb in Fig. 1 gestrichelt dargestellt.
Die Nachrichten-Schnittstelle 22 kann beispielsweise als Modem für die drahtgebundene oder drahtlose Kommunikation ausgestaltet sein. Das Zahlungsverkehrsterminal vermag über die Nachrichten-Schnittstelle 22 und ein entsprechendes Kommunikationsmedium, z. B. eine Telefonleitung oder das GSM-Netz oder das Internet, mit einem Hintergrundsystem, z. B. dem Computersystem einer Bank oder einer Abrechnungszentrale, zu kommunizieren.
Der Krypto-Prozessor 24 ist eine speziell gegen Angriffe gesicherte Baugruppe, die kryptographische Funktionen, z. B. zur Verschlüsselung persönlicher Identifikationsnummern, bereitstellt. In Ausführungsalternativen ist der Krypto-Prozessor 24 nicht als Hardware-Baugruppe, sondern als von dem Prozessor 12 ausgeführtes Software-Modul realisiert.
Die Drucker-Schnittstelle 26, die Tastatur-Schnittstelle 28 und die Anzeigen- Schnittstelle 30 dienen auf an sich bekannte Weise zur Ansteuerung eines Druckers 36, einer Tastatur 38 sowie einer Anzeige 40. Der Zeitgeber 32 stellt Funktionen zur programmgesteuerten Generierung von Zeitüberschreitungssignalen bereit, die bei der Kommunikation mit der Chipkarte 34 und dem Hintergrundsystem benötigt werden.
Unmittelbar auf die Hardwareschicht 10 setzt eine hardwarenahe Softwareschicht 42 mit Treibern für die gerade genannten Hardware-Elemente 20 bis 40 auf. Bei dem in Fig. 1 gezeigten Ausführungsbeispiel sind hier Softwaremodule für einen Chipkartentreiber 44, einen Nachrichtentreiber 46, einen Kryptotreiber 48, einen Druckertreiber 50, einen Tastaturtreiber 52, einen Anzeigentreiber 54 und einen Zeitgeber-Treiber 56 vorgesehen.
Auf die hardwarenahe Softwareschicht 42 baut als weitere Abstraktionsebene eine Interpreter-Schicht 58 auf. Die Interpreter-Schicht 58 enthält als wesentlichen Bestandteil einen Interpreter 60 für die zur Steuerung des Zahlungsverkehrsterminals verwendeten Programmbefehle.
Die Programmbefehle sowie weitere für die Steuerung benötigte Informationen bilden ein Steuerprogramm 62, das konzeptuell eine über der Interpreter-Schicht 58 angeordnete Steuerprogramm-Schicht 64 darstellt. Das Steuerprogramm 62 weist eine Haupttabelle 66 auf, in der jede Zeile einen Programmbefehl enthält.
Im hier beschriebenen Ausführungsbeispiel sind ferner mehrere Nebentabellen 68, 70, 72, 74 vorgesehen, in denen jeweils logisch zusammengehörige Informationen gesammelt sind. So enthält beispielsweise die Nebentabelle 68 Einträge, die den Aufbau der einzelnen Chipkarten-Kommandos beschreiben, die Nebentabelle 70 enthält Informationen über den Aufbau der einzelnen Nachrichten an das Hintergrundsystem, die Nebentabelle 72 enthält Informationen über den Aufbau der vom Hintergrundsystem erwarteten Antworten und die Nebentabelle 74 enthält als Texttabelle Einträge mit den anzuzeigenden oder auszudruckenden Zeichenketten.
In den Steuerbefehlen der Haupttabelle 66 wird, falls erforderlich, auf einen entsprechenden Eintrag in einer der Nebentabellen 68 bis 74 verwiesen. Durch die Auslagerung aller Informationen über bestimmte Funktionseinheiten, z. B. über das Format von Chipkarten-Kommandos, in die Nebentabellen 68 bis 74 wird die Übersichtlichkeit des Steuerprogramms 62 erheblich erhöht. Außerdem wird dadurch das Steuerprogramm 62 in seiner Struktur an die Gliederung der einschlägigen Spezifikationen und Normen angeglichen.
In Fig. 1 sind der klareren Darstellung halber die Elemente des Steuerprogramms 62 in einer Tabellenform gezeigt, wie sie während der Programmentwicklung verwendet wird. In unterschiedlichen Ausführungsbeispielen ist diese Tabellenform in der endgültigen Codierung des Steuerprogramms 62, wie sie sich im Programmspeicher 16 befindet, mehr oder weniger verwischt oder im Extremfall gar nicht mehr erkennbar.
Fig. 2 zeigt ein Beispiel für den Aufbau der Haupttabelle 66. Auch hier ist die für die Programmentwicklung verwendete Tabellenform gezeigt; eine beispielhafte Laufzeit-Codierung wird später unter Hinweis auf Fig. 7 beschrieben werden. Wie bereits erwähnt, weist die Haupttabelle 66 eine Vielzahl von Zeilen auf, in denen je ein Programmbefehl 80A, 808, 80C, . . . enthalten ist (die Programmbefehle 80A, 808, 80C, . . . werden im folgenden auch zusammenfassend mit dem Bezugszeichen 80x bezeichnet). Die Haupttabelle 66 und damit jeder Programmbefehl 80x ist in vier Hauptabschnitte unterteilt, nämlich in einen Funktionsabschnitt 82, einen Parameterabschnitt 84, einen Bedingungsabschnitt 86 und einen Kommentarabschnitt 88. Der Funktionsabschnitt 82 und der Parameterabschnitt 84 jedes Programmbefehls 80x bilden zusammen den Befehlsteil dieses Programmbefehls 80x.
Der Funktionsabschnitt 82 jedes Programmbefehls 80x definiert die von dem Programmbefehl 80x ausgeführte Funktion und entspricht somit beispielsweise dem Operationscode (OP-code) in Assembler-Programmierung. Im hier beschriebenen Ausführungsbeispiel ist der Funktionsabschnitt 82 in einen ersten Unterabschnitt 90 für die Befehlsgruppe und einen zweiten Unterabschnitt 92 für den Befehlstyp innerhalb jeder Befehlsgruppe unterteilt. Durch diese Maßnahme werden die zur Verfügung stehenden Befehle weiter gegliedert, um eine besonders hohe Übersichtlichkeit bei der Programmierung und bei der Wartung des Steuerprogramms 62 zu erreichen.
Im Parameterabschnitt 84 jedes Programmbefehls 80x sind die für diesen Programmbefehl erforderlichen Parameter enthalten. In der Haupttabelle 66 gemäF Fig. 2 sind maximal drei Parameter eingezeichnet; es können jedoch in Ausführungsalternativen auch Befehlssätze verwendet werden, die eine höhere oder geringere maximale Parameterzahl aufweisen. In weiteren Ausführungsalternativen ist der Befehlstyp nicht in dem zweiten Unterabschnitt 92 des Funktionsabschnitts 82, sondern als erster Parameter in dem Parameterabschnitt 84 enthalten.
Im vorliegenden Ausführungsbeispiel sind für das Steuerprogramm 62 Programmbefehle 80x vorgesehen, die den bei Zahlungsterminals auftretenden Grundaufgaben entsprechen. Der Befehlssatz enthält unter anderem die folgenden Programmbefehle 80x:

a) Befehlsgruppe: Zurücksetzen
Befehlstyp: Kennung des zurückzusetzenden Prozessors Parameter: keine
b) Befehlsgruppe: Anzeigen
Befehlstyp: Ausgabegerät (Drucker 36 oder Anzeige 40)
1. Parameter: Verweis auf auszugebenden Text in der Nebentabelle 74
c) Befehlsgruppe: Tastaturabfrage
Befehlstyp: keine unterschiedlichen Befehlstypen vorgesehen
1. Parameter: Wertebereich der erwarteten Eingabe
d) Befehlsgruppe: Senden an Chipkarte
Befehlstyp: keine unterschiedlichen Befehlstypen vorgesehen
1: Parameter: Chipkarten-Kommando
e) Befehlsgruppe: Empfangen von Chipkarte
Befehlstyp: keine unterschiedlichen Befehlstypen vorgesehen
1. Parameter: Chipkarten-Kommando
2. Parameter: maximale Wartezeit bis zur Erzeugung eines Zeitfehlers
f) Befehlsgruppe: Senden einer Nachricht an Hintergrundsystem
Befehlstyp: keine unterschiedlichen Befehlstypen vorgesehen
1. Parameter: Abwicklungskennzeichen
2. Parameter: Verweis auf Nachricht in Nebentabelle 70
g) Befehlsgruppe: Empfangen einer Nachricht vom Hintergrundsystem
Befehlstyp: keine unterschiedlichen Befehlstypen vorgesehen
1. Parameter: Abwicklungskennzeichen
2. Parameter: Verweis auf Antwortbedingung in Nebentabelle 72
3. Parameter: Verweis auf Bestätigungsnachricht in Nebentabelle 70
h) Befehlsgruppe: Verschlüsseln
Befehlstyp: anzuwendendes Verschlüsselungsverfahren
1. Parameter: Verweis auf zu verschlüsselnde Daten
2. Parameter: Verweis auf Speicherbereich für entschlüsselte Daten
i) Befehlsgruppe: Entschlüsseln
Befehlstyp: anzuwendendes Entschlüsselungsverfahren
1. Parameter: Verweis auf zu entschlüsselnde Daten
2. Parameter: Verweis auf Speicherbereich für entschlüsselte Daten
j) Befehlsgruppe: Prüfen
Befehlstyp: Prüfkriterium, z. B. "Datum>" = aktuelles Datum früher als Datum in dem durch die Parameter angegebenen Speicherbereich
1. Parameter: Verweis auf Beginn des zu prüfenden Speicherbereichs
2. Parameter: Verweis auf Ende des zu prüfenden Speicherbereichs.

Die Untergliederung der Bestandteile eines Programmbefehls 80x in Befehlsgruppe, Befehlstyp und Parameter dient, wie bereits erwähnt, primär der besseren Übersichtlichkeit. In Ausführungsalternativen sind daher andere Gliederungen möglich. Beispielsweise kann bei dem oben genannten Befehl b) das Ausgabegerät in der Befehlsgruppe, statt, wie oben, im Befehlstyp, angegeben werden. Hinsichtlich der Befehle d) und f) ist es dagegen in anderen Ausführungsvarianten vorgesehen, den Empfänger nicht als Bestandteil der Befehlsgruppe, sondern als Befehlstyp oder sogar als Parameter anzugeben. Es wird ferner angemerkt, dass Befehle mit unterschiedlich vielen Parametern bis zu der jeweils vorgesehenen maximalen Parameteranzahl im Befehlssatz enthalten sind.
Die einzelnen Programmbefehle 80x der Haupttabelle 66 werden von dem Interpreter 60 (Fig. 1) der Reihe nach abgearbeitet, wie dies später noch im Detail beschrieben werden wird. Spezielle Befehle zur Programmflusssteuerung sind nicht oder nur sehr eingeschränkt vorgesehen. Der Hauptmechanismus zur Steuerung des Programmflusses besteht vielmehr darin, dass jeder Programmbefehl 80x im Bedingungsabschnitt 86 eine Gültigkeitsbedingung aufweist. Während des Programmablaufs werden nur solche Programmbefehle 80x ausgeführt, deren jeweilige Gültigkeitsbedingung zur Laufzeit erfüllt ist. Andere Programmbefehle 80x werden übersprungen. Durch dieses Verfahren bei der Abarbeitung der Programmbefehle 80x wird der Programmfluss an Laufzeitkriterien oder Eingaben oder äußere oder interne Ereignisse angepasst, wodurch sich Konstrukte wie beispielsweise bedingte Sprünge vermeiden lassen. Beispielsweise kann durch diesen Mechanismus bei einem erfolgreichen Lesen von der Chipkarte eine erste Nachricht an das Hintergrundsystem gesendet werden, im Falle einer Wartezeitüberschreitung (timeout) hingegen eine zweite Nachricht.
In Fig. 2 sind beispielhaft Gültigkeitsbedingungen dargestellt, die sich aus bis zu sechs vorgegebenen Kriterien zusammensetzen. Typische Beispiele für solche Kriterien sind die eingestellte Zahlungsart, die Gerätevariante, eine optionale Funktionalität, ein externes Ereignis, ein interner Zustand des Zahlungsverkehrsterminals oder die Benutzungssteuerung der Speicher oder anderer Aktoren. Die Wirkung eines erfüllten Kriteriums wird in der Tabellendarstellung von Fig. 2 durch die Zeichen "+", "&" und und "\" in der entsprechenden Spalte des Bedingungsabschnitts 86 angegeben. Ist für einen Programmbefehl 80x in einer Kriterienspalte kein Zeichen eingetragen, so beeinflusst dieses Kriterium die Ausführung dieses Programmbefehls 80x nicht.
Bei dem Programmbefehl SOA hat die im Bedingungsabschnitt 86 enthaltene Gültigkeitsbedingung die Form einer einfachen Ausführungsbedingung. Dies wird dadurch angezeigt, dass ein einziges Kriterium im Bedingungsabschnitt 86 mit dem Zeichen "+" markiert ist. Der Programmbefehl 80A wird genau dann ausgeführt, wenn zur Laufzeit das markierte Kriterium, hier Kriterium 2) erfüllt ist.
Bei dem Programmbefehl 80B sind mehrere einfache Ausführungsbedingungen vorgesehen, indem mehrere Kriterien mit dem "+"-Zeichen markiert sind. Hier entspricht die Gültigkeitsbedingung der ODER-Verknüpfung der einzelnen Ausführungsbedingungen. Der Programmbefehl 80B wird daher genau dann ausgeführt, wenn mindestens eines der Kriterien 1, 2 oder 3 zur Laufzeit erfüllt ist.
Eine als "kombinierte Ausführungsbedingung" bezeichnete Gültigkeitsbedingung ist im Programmbefehl 80C gezeigt. Diese Gültigkeitsbedingung ist erfüllt, wenn alle im Bedingungsabschnitt 86 mit dem Zeichen "&" markierten Kriterien zur Laufzeit gegeben sind.
Alle bisher genannten Gültigkeitsbedingungen können durch eine Überfahrbedingung eingeschränkt werden. Eine derartige Überfahrbedingung wird durch das Zeichen "\" für ein oder mehrere Kriterien des Bedingungsabschnitts 86 angezeigt. Ist bei der Ausführung eines Programmbefehls 80x eine Überfahrbedingung erfüllt, so wird dieser Programmbefehl 80x übersprungen, ohne dass die sonstigen Kriterien im Bedingungsabschnitt 86 eine Rolle spielen würden. So wird beispielsweise der Programmbefehl 80D auf keinen Fall dann ausgeführt, wenn das Kriterium 4 zur Laufzeit erfüllt ist. Als weiteres Beispiel wird der Programmbefehl 80E genau dann ausgeführt, wenn entweder das Kriterium 1 erfüllt ist und das Kriterium 4 nicht erfüllt ist, oder wenn die Kriterien 2, 3 und 5 sämtlich erfüllt sind und das Kriterium 4 nicht erfüllt ist.
Fig. 3 stellt eine beispielhafte Spezifikation eines Antwortdatensatzes der Chipkarte 34 in Tabellenform dar. Entsprechende Daten können in einer Nebentabelle eingetragen werden, anhand derer die Gültigkeit einer Chipkarten-Antwort überprüft wird. Auch die Nebentabelle 72 zur Überprüfung von Antworten des Hintergrundsystems kann einen ähnlichen Aufbau aufweisen. Dies entspricht den im vorliegenden Ausführungsbeispiel allgemein herangezogenen Prinzipien, komplexe Strukturen und Mechanismen in Nebentabellen auszulagern und die Darstellung des Steuerprogramms 62 zumindest während der Programmentwicklung möglichst weitgehend den zugrundeliegenden Spezifikationen anzunähern.
Fig. 4 zeigt einen beispielhaften und vereinfachten Ausschnitt des Ablaufs "Laden vorbereiten" für eine als Geldkarte ausgestaltete Chipkarte 34 gemäß Kapitel 4.12 des Dokuments "Schnittstellenspezifikation für die ec-Karte mit Chip 3.0, Geldkarte-Ladeterminal". Allgemein sind in derartigen Spezifikationen Abläufe in einem Zahlungsverkehrsterminal als Abfolge von nacheinander, also sequentiell erfolgenden Ausgabeaktionen (Senden) und Eingabeaktionen (Empfangen) beschrieben. Die Spezifikation ist weitgehend hardwareunabhängig.
Die Haupttabelle 66 eines der Spezifikation von Fig. 4 entsprechenden Steuerprogramms 62 ist in Fig. 5A und Fig. 5B dargestellt, wobei Fig. 5A die linke Hälfte der Haupttabelle 66 und Fig. 5B die rechte, unmittelbar daran anschließende Hälfte zeigt. In diesem ausführlicheren Beispiel weist der Bedingungsabschnitt 86 jedes Programmbefehls 80x eine Vielzahl möglicher Gültigkeitskriterien auf, die in die Kategorien "Gerätefunktionen", "Status", "Fehler" und "Kartentyp" unterteilt sind.
Kriterien der Kategorie "Gerätefunktionen" betreffen äußere Bedingungen, die über die Tastatur 38 oder eine Registrierkasse ausgewählt werden oder die sich durch den verwendeten Kartentyp oder die gegenwärtige Betriebsart ergeben. Beispiele für derartige Kriterien sind die Bezahlung per ec-Karte in einer online-Betriebsart, d. h. bei bestehender Kommunikationsmöglichkeit mit dem Hintergrundsystem, die Zahlung per ec-Karte in einer offline- Betriebsart, d. h. ohne Zugriff auf das Hintergrundsystem, die Bezahlung mittels einer Geldkarte, das Nachladen der Geldkarte von einem Bankkonto oder die Bezahlung per Kreditkarte oder Flottenkarte.
Status- und Fehlerkriterien sind in der Regel solche, die interne Gerätevorgänge betreffen und die erst während der Programmlaufzeit auftreten beziehungsweise sich während der Programmlaufzeit ändern. Beispiele für derartige Kriterien sind Zeitfehler (timeouts), Unterbrechungen (interrupts), negative Rückmeldungen des Hintergrundsystems oder der Chipkarte sowie Autostornobedingungen.
Die in Fig. 5B gezeigte Spalte "Speicher" dient zur Angabe von wählbaren Speicherplätzen für Ergebnisse oder Eingabewerte einzelner Programmbefehle. Die dort gezeigten Angaben sind daher konzeptionell als Befehlsparameter aufzufassen, auch wenn sie optisch im Bedingungsabschnitt 86 angeordnet sind und in manchen Ausführungsformen des erfindungsgemäßen Systems intern wie Kriterien von Gültigkeitsbedingungen gespeichert werden.
Während des Betriebs des in Fig. 1 gezeigten Zahlungsverkehrsterminals führt der Interpreter 60 eine Programmschleife aus, wie sie beispielhaft in Fig. 6 gezeigt ist. In einem ersten Schritt 100 wird ein Befehlszähler des Interpreters 60 auf den ersten Programmbefehl 80A in der Haupttabelle 66 des Steuerprogramms 62 gesetzt. In einem nächsten Schritt 102 wird ein Gerätestatus gebildet, der den momentanen Zustand der einzelnen für die Gültigkeitsbedingungen möglichen Kriterien enthält. Der Interpreter 60greift nun auf den aktuellen Programmbefehl 80x zu und lädt dessen im Bedingungsabschnitt 86 enthaltene Gültigkeitsbedingung (Schritt 104).
In Abfrage 106 wird überprüft, ob mindestens ein in der Gültigkeitsbedingung des aktuellen Programmbefehls angegebenes Überfahrkriterium (Zeichen "\" in Fig. 2) erfüllt ist. Ist dies der Fall ("Ja"-Zweig in Abfrage 106), so wird der aktuelle Programmbefehl übersprungen. Ist keine Überfahrbedingung erfüllt ("Nein"-Zweig in Abfrage 106), so wird in Abfrage 108 überprüft, ob gegenwärtig mindestens ein als einfache Ausführungsbedingung (Zeichen "+" in Fig. 2) markiertes Kriterium vorliegt. Wenn dies der Fall ist ("Ja"-Zweig in Abfrage 108), wird der aktuelle Programmbefehl 80x in den Schritten 110 und 112 ausgeführt.
Zur Ausführung des Programmbefehls 80x wird zunächst dessen Funktionsabschnitt 82 decodiert (Schritt 110). In Schritt 112 ruft der Interpreter 60 den entsprechenden Treiber (Bezugszeichen 44 bis 56 in Fig. 1) auf und übergibt die Daten gemäß dem Parameterabschnitt 84 des Programmbefehls 80x an das Treibermodul 44 bis 56. Nach der Befehlsausführung durch das Treibermodul 44 bis 56 werden eventuell zurückgegebene Datenwerte entsprechend den Angaben im Parameterabschnitt 84 gespeichert.
War keine der einfachen Ausführungsbedingungen erfüllt ("Nein"-Zweig in Abfrage 108), so wird in Abfrage 114 noch das Vorliegen einer kombinierten Ausführungsbedingung ("&"-Zeichen in Fig. 2) überprüft. Sind alle in einer solchen kombinierten Ausführungsbedingung genannten Kriterien erfüllt ("Ja"-Zweig in Abfrage 114), so erfolgt ebenfalls die Befehlsausführung in den Schritten 110 und 112.
Nach dem Ende der Befehlsausführung beziehungsweise wenn ein Programmbefehl 80x übersprungen worden ist, wird der Befehlszähler in Schritt 116 erhöht. Ist das Tabellenende noch nicht erreicht ("Nein"-Zweig in Abfrage 118), so wird die Programmausführung mit dem nächsten Programmbefehl 80x fortgeführt. Andernfalls beginnt die Abarbeitung der Haupttabelle 66 erneut mit dem ersten Programmbefehl 80A.
Im hier beschriebenen Ausführungsbeispiel wird somit die gesamte Haupttabelle 66 in einer Endlosschleife zyklisch durchlaufen. In Ausführungsalternativen sind dagegen Mittel zur Strukturierung des Steuerprogramms 62 oder zur Steuerung des Programmflusses vorgesehen. Beispielsweise können Programmteile in weitere Tabellen ausgelagert werden und wie Unterprogramme aufgerufen werden. Im Befehlssatz können auch Sprungbefehle zu vorbestimmten Zielen innerhalb der Haupttabelle 66 oder zu den gerade genannten Untertabellen enthalten sein; derartige Sprünge werden dann ausgeführt, wenn ihre jeweilige Gültigkeitsbedingung erfüllt ist.
Wie oben bereits erwähnt, kann das Steuerprogramm 62 in unterschiedlichen Codierungen vorliegen. Eine besonders einfache Codierung der in den bisherigen Figuren gezeigten Tabellen wäre beispielsweise die Darstellung als ASCII-Text oder in einer Seitenbeschreibungssprache, z. B. HTML oder XML oder in einem gebräuchlichen Dateiformat, z. B. wie in den Programmen Microsoft® Word oder Microsoft® Excel®. In manchen Ausführungsformen der Erfindung kann vorgesehen sein, dass der Interpreter 60 Steuerprogramme 62 in einer solchen Codierung unmittelbar einliest und abarbeitet. Wegen des damit verbundenen hohen Speicherplatz- und Rechenaufwands werden jedoch Ausführungsbeispiele bevorzugt, bei denen das Steuerprogramm 62 in einer effizient codierten Form vorliegt.
Ein Beispiel für eine solche Codierung der Haupttabelle 66 von Fig. 2 ist in Fig. 7 dargestellt. In der beispielhaften Codierung von Fig. 7 ist die Haupttabelle 66 teils in einem Befehlsspeicherbereich 120 und teils in einem Bedingungsspeicherbereich 122 abgelegt. Für jeden Programmbefehl 80x weist der Befehlsspeicherbereich 120 zwei, drei oder vier Bytes auf, nämlich ein erstes Byte zur Codierung der Funktion (Befehlsgruppe und gegebenenfalls Befehlstyp), ein zweites Byte, das einen Verweis auf eine in dem Bedingungsspeicherbereich 122 eingetragene Gültigkeitsbedingung enthält, und null, ein oder zwei weitere Bytes für die entsprechende Anzahl von Parametern des Programmbefehls 80x. Bei Befehlen mit drei Parametern ist vorgesehen, den ersten Parameter wie einen Befehlstyp im ersten Byte zu codieren. Die in Fig. 7 gezeigten Werte sind beispielhafte Codierungen für die in Fig. 2 im Klartext dargestellten Programmbefehle 80x.
Der Bedingungsspeicherbereich 122 enthält einen Eintrag für jede in der Haupttabelle 66 auftretende Gültigkeitsbedingung. Wie aus Fig. 5A und Fig. 5B hervorgeht, weisen in der Praxis häufig mehrere Programmbefehle 80x der Haupttabelle 66 die gleiche Gültigkeitsbedingung auf. Diese Gültigkeitsbedingung ist im Bedingungsspeicherbereich 122 nur jeweils einmal vorhanden, wodurch eine unnötige Duplizierung von identischen Gültigkeitsbedingungen vermieden wird.
Im vorliegenden Ausführungsbeispiel weist jeder Eintrag im Bedingungsspeicherbereich 122 zwei Bitfelder 124, 126 auf, die für jedes mögliche Gültigkeitskriterium je ein Bit enthalten. Die Zuordnung dieser Bits zu den Gültigkeitskriterien ist in beiden Bitfeldern 124, 126 identisch. In dem hier beschriebenen Beispiel sind nur sechs Gültigkeitskriterien vorgesehen, so dass jedes der Bitfelder 124, 126 lediglich sechs Bits je eines Bytes verwendet. In einem typischen Ausführungsbeispiel der Erfindung, bei dem die Haupttabelle 66 beispielsweise wie in Fig. 5A und Fig. 5B aufgebaut ist, sind dagegen 32 Gültigkeitskriterien und dementsprechend 32 Bit (= vier Byte) für jedes der beiden Bitfelder 124, 126 vorgesehen.
Die bereits beschriebenen Gültigkeitsbedingungen werden gemäß der folgenden Tabelle in die entsprechenden Bits der beiden Bitfelder 124, 126 codiert:
Wenn eine Codierung gemäß Fig. 7 vorliegt, können die Abfragen 106, 108 und 114 von Fig. 6 auf besonders einfache Weise durchgeführt werden. Dazu wird in Schritt 102 der Gerätestatus ebenfalls in Form eines Bitfeldes dargestellt, das hinsichtlich der Anordnung der Gültigkeitskriterien dem Format der Bitfelder 124, 126 entspricht. Eine Überfahrbedingung ist dann erfüllt, wenn die UND-Verknüpfung zwischen dem Gerätestatus und dem zweiten Bitfeld 126 sowie der Negation des ersten Bitfelds 124 ungleich Null ist. Auf ähnliche Weise kann in Schritt 108 das Vorliegen einer einfachen Ausführungsbedingung durch eine UND-Verknüpfung zwischen dem Gerätestatus und dem ersten Bitfeld 124 sowie der Negation des zweiten Bitfelds 126 überprüft werden. Zur Überprüfung der kombinierten Ausführungsbedingung in Abfrage 114 sind zunächst eine UND-Verknüpfung der beiden Bitfelder 124, 126 und dann eine Exklusiv-ODER-Verknüpfung des Ergebnisses mit dem Gerätestatus sowie ein Nullvergleich erforderlich.
Während im vorliegenden Ausführungsbeispiel die Überfahrinformation im Bedingungsspeicherbereich 122 enthalten ist, kann in Ausführungsalternativen vorgesehen sein, in den Bedingungsspeicherbereich 122 nur Ausführungsbedingungen aufzunehmen und gegebenenfalls vorhandene Überfahrbedingungen gesondert zu verwalten. Allgemein kann auch vorgesehen sein, die hier vorgeschlagene Vorgehensweise der gemeinsamen Speicherung identischer Gültigkeitsbedingungen nur für einige der zur Verfügung stehenden Gültigkeitskriterien anzuwenden.
Fig. 8 zeigt ein Verfahren, das im vorliegend beschriebenen Ausführungsbeispiel zum Codieren der diversen Tabellen des Steuerprogramms 62 (Fig. 1) und zum Erzeugen eines in den Programmspeicher 16 ladbaren Programms (Datei "zvt.hex" im Hex-Code) verwendet wird.
Das Verfahren gemäß Fig. 8 geht von einer Haupttabelle 66 aus, die in einer für den Programmierer komfortabel bearbeitbaren Codierung (hier als Datei "zvt_tab.xls" im Format des Tabellenkalkulationsprogramms Microsoft® Excel®) vorliegt. Diese Datei wird in Schritt 130 analysiert und in eine Codierung umgesetzt, die einem Quelltext-Segment der Pr ogrammiersprache C entspricht (Datei "zvt_tab.c"). Für den Umsetzvorgang in Schritt 130 können übliche Hilfsmittel wie z. B. die Programme Lex und Yacc eingesetzt werden. Beispielsweise kann ein Codesegment in der folgenden Struktur erzeugt werden:
In einem nächsten Schritt 132 wird die als Programmabschnitt codierte Haupttabelle 66 durch einen üblichen Compiler, der auf die Hardware des Zahlungsverkehrterminals zugeschnitten ist, in eine Objektdatei umgesetzt (Datei "zvt_tab.obj"). Zusammen mit anderen Objektdateien, die Nebentabellen des Steuerprogramms 62 sowie den Interpreter 60 und die Treibermodule 44 bis 56 (Fig. 1) beinhalten, erzeugt ein Bindeprogramm daraus in Schritt 134 ein ladbares Programm (Datei "zvt.hex"). Sowohl die Objektdatei "zvt_tab.obj" als auch das ladbare Programm "zvt.hex" enthalten Binärdaten, die der in Fig. 7 beispielhaft gezeigten Codierung entsprechen.
Das ladbare Programm (Datei "zvt.hex") implementiert die Softwareschichten 42, 58 und 64 (Fig. 1) des Zahlungsverkehrsterminals nach dem vorliegend beschriebenen Ausführungsbeispiel der Erfindung. Das Programm wird über eine geeignete Schnittstelle in die Hardware des Zahlungsverkehrsterminals geladen, um ein arbeitsfähiges System zu erhalten.

Claims

1. Verfahren zur Steuerung eines Zahlungsverkehrsterminals, dadurch gekennzeichnet, dass die Steuerung zumindest zum Teil gemäß Programmbefehlen (80x) erfolgt, die jeweils einen Befehlsteil und eine Gültigkeitsbedingung aufweisen, wobei nur solche Programmbefehle (80x) ausgeführt werden, deren jeweilige Gültigkeitsbedingung zur Laufzeit erfüllt ist.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Gültigkeitsbedingung mindestens eines der folgenden Elemente aufweist:

- mindestens eine Überfahrbedingung, die, wenn sie zur Laufzeit erfüllt ist, die Befehlsausführung verhindert,

- mindestens eine einfache Ausführungsbedingung, die, wenn sie zur Laufzeit erfüllt ist, die Befehlsausführung freigibt, und

- eine kombinierte Ausführungsbedingung, die mehrere Ausführungsbedingungen aufweist und die, wenn alle diese Ausführungsbedingungen erfüllt sind, die Befehlsausführung freigibt.

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass der Befehlsteil mindestens eines der folgenden Elemente aufweist:

- einen Funktionsabschnitt (82), der die durch den Programmbefehl (80x) auszuführende Funktion angibt, und

- einen Parameterabschnitt (84), der mindestens einen für die Ausführung des Programmbefehls (80x) relevanten Parameter angibt.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Programmbefehle (80x) zur Laufzeit in einer Codierung vorliegen, die mindestens einen Befehlsspeicherbereich (120) und mindestens einen Bedingungsspeicherbereich (122) aufweist, wobei:
in dem Befehlsspeicherbereich (120) Funktionen und/oder Parameter von Programmbefehlen (80x) sowie Verweise auf Daten in dem Bedingungsspeicherbereich (122) enthalten sind,
in dem Bedingungsspeicherbereich (122) zumindest Teile von Gültigkeitsbedingungen für die Ausführung von Programmbefehlen (80x) enthalten sind, und
Einträge in dem Befehlsspeicherbereich (120), die Programmbefehlen (80x) mit zumindest teilweise identischen Gültigkeitsbedingungen zugeordnet sind, auf gemeinsame Daten in dem Bedingungsspeicherbereich (122) verweisen.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass ein Steuerprogramm (62) mit einer Mehrzahl von Programmbefehlen (80x) zumindest zum Zwecke der Programmentwicklung in Form einer oder mehrerer Tabellen (66, 68, 70, 72, 74) darstellbar ist.

6. Verfahren zur Steuerung eines Zahlungsverkehrsterminals, dadurch gekennzeichnet, dass die Steuerung gemäß Programmbefehlen (80x) erfolgt, die mittels eines Interpreters (60) des Zahlungsverkehrsterminals zur Laufzeit interpretiert werden.

7. Verfahren zur Steuerung eines Zahlungsverkehrsterminals nach Anspruch 6 und einem der Ansprüche 1 bis 5.

8. Computerlesbarer Datenträger mit einem Steuerprogramm (62), das dazu eingerichtet ist durch mindestens einen Prozessor (12) eines Zahlungsverkehrsterminals ausgeführt zu werden, um das Zahlungsverkehrsterminal durch ein Verfahren gemäß einem der Ansprüche 1 bis 7 zu steuern.

9. Zahlungsverkehrsterminal, das dazu eingerichtet ist, durch ein Verfahren gemäß einem der Ansprüche 1 bis 7 gesteuert zu werden.