WO2003085611A2 - Konfigurieren eines zahlungsverkehrsterminals - Google Patents

Konfigurieren eines zahlungsverkehrsterminals Download PDF

Info

Publication number
WO2003085611A2
WO2003085611A2 PCT/EP2003/003392 EP0303392W WO03085611A2 WO 2003085611 A2 WO2003085611 A2 WO 2003085611A2 EP 0303392 W EP0303392 W EP 0303392W WO 03085611 A2 WO03085611 A2 WO 03085611A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
configuration
payment transaction
browser
transaction terminal
Prior art date
Application number
PCT/EP2003/003392
Other languages
English (en)
French (fr)
Other versions
WO2003085611A3 (de
Inventor
Arndt Berthold
Andreas Johne
Original Assignee
Giesecke & Devrient Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to AU2003226767A priority Critical patent/AU2003226767A1/en
Publication of WO2003085611A2 publication Critical patent/WO2003085611A2/de
Publication of WO2003085611A3 publication Critical patent/WO2003085611A3/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/206—Software aspects at ATMs
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/211—Software architecture within ATMs or in relation to the ATM network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • a payment transaction terminal is to be understood in particular to mean any device which carries out transactions using a chip card or other electronic identification and / or storage means. Such payment terminals are used, for example, for cashless payments of all kinds.
  • the term payment transaction terminal is also intended to encompass devices which are only indirectly involved in payment and billing processes, such as chip card-based access control and time recording systems.
  • payment transaction terminals In order to be able to be used sensibly, payment transaction terminals must be configured customer-specifically and / or device-specifically. For example, the device configuration, the range of functions, device-specific header data (account number, location data, terminal identifier, ...) and / or customer-specific ad texts are set. It is known to carry out this configuration by the customer service of the terminal manufacturer. The customer receives a form by fax, which he fills out and sends back to customer service. The form is evaluated by hand to create a corresponding configuration file. Finally, the configuration file is loaded into the payment terminal by customer service via a maintenance computer.
  • the object of the invention is to avoid all or part of the problems mentioned.
  • the invention is intended to create the technical foundations in order to simplify the configuration of payment terminals, to avoid errors and to reduce the time and cost required.
  • this object is achieved in whole or in part by a method having the features of claim 1, a computer-readable data carrier according to claim 12 and a payment transaction terminal according to claim 13.
  • the dependent claims relate to preferred embodiments of the invention.
  • the list of process steps in the claims should not be understood as a restriction of the scope. Rather, embodiments of the invention are provided in which these steps are carried out in a different order and / or at least partially parallel and / or at least partially interlocked.
  • the invention is based on the basic idea of automating the process of configuring the ZaWungs horrterminal. For this purpose, it is proposed according to the invention to display a configuration form that can be filled out by a browser running on a user computer.
  • the entries in the configuration form are transmitted to a translator in the form of input data which have a data format specified by the browser.
  • the translator generates loading data depending on the input data and possibly further information.
  • the loading data in turn have a data format specified by the payment transaction terminal and are used to configure the payment transaction terminal.
  • the automation proposed according to the invention leads to a higher quality of the configuration process because manual processing errors are avoided. Changes can be made faster and with less effort for customer service.
  • the invention also makes it practicable to equip payment transaction terminals with expanded configuration options which previously could not have been used efficiently.
  • the configuration form is transmitted to the browser in a page description language, for example HTML or XML.
  • a page description language for example HTML or XML.
  • the graphic design of the form can make it much easier to fill it in correctly.
  • the browser can be a common Internet browser.
  • the configuration form can be loaded into the browser from an external server or from a local data carrier.
  • the parameters to be configured are preferably binary parameters (corresponding to a yes / no entry in the configuration form) and / or numerical parameters (corresponding to a number entry in the configuration form) and / or text parameters (corresponding to a text entry in the configuration form).
  • the configuration is based on header data (data with an individual terminal reference) and / or on customer-specific data (eg telephone numbers or customer names) and / or on country-specific data (messages to be displayed or printed in the respective national language) ) relates.
  • customer-specific data eg telephone numbers or customer names
  • country-specific data messages to be displayed or printed in the respective national language
  • the data format specified by the browser in which the browser sends the input data to the translator is preferably a text format.
  • the input data is preferably transmitted as an e-mail message from the browser to the translator.
  • the translator is executed as a program module by the operating computer or by an external service computer or by a microcontroller of the payment transaction terminal.
  • a communication interface of the payment transaction terminal is preferably used to transfer the externally calculated loading data to the payment transaction terminal and to trigger the configuration process there.
  • the communication interface is preferably used to transmit the input data.
  • the communication interface is used not only for the purpose of configuration, but also in the normal operation of the payment transaction terminal, for example for connecting the payment transaction terminal to a telephone line or a company network.
  • the loading data are generated as a function of the input data.
  • only a conversion process takes place here, which does not add any further information to the input data. added.
  • additional information is evaluated in order to generate the loading data. In particular, this can be information that was determined by a database query.
  • configurations are provided in which, alternatively or additionally, information obtained from a database is included as entries in the configuration form. Such entries can be visible or hidden and can be changed or fixed by the user. They are transferred to the translator with the input data.
  • connection to the database has the advantage that not all of the information required for configuration has to be entered individually via the user interface provided by the browser. This is particularly important when many ZaWungsterminal are to be provided with similar configurations.
  • a preferred embodiment can also provide functionality for reading configuration data from the taming traffic terminal.
  • the read data can e.g. displayed by the browser and / or stored in the database.
  • the data carrier provided according to the invention can be an electronic or magnetic or optical storage medium, for example a floppy disk or hard disk or CD-ROM, but is not limited to physical data carriers. Electrical or optical signals, for example voltage level of a communication link, are also to be understood as computer-readable data carriers in the sense used here.
  • the disk contains invented In accordance with the invention computer commands that control the conversion process between the input data and the load data.
  • the payment transaction terminal is set up to translate the input data of the external browser received via the communication interface into the loading data.
  • the payment terminal is configured according to the loading data.
  • the load data can correspond, for example, to the new memory content to be written into a configuration memory area or specify rules for changing the memory content.
  • the steps of generating the load data and changing the memory content are preferably interlinked, so that, for example, each byte of the load data generated is written directly into the configuration memory area of the payment transaction terminal.
  • the computer-readable data carrier and / or the payment transaction terminal are further developed with features which correspond to the features described above and / or to the features mentioned in the method claims.
  • 1 shows a block diagram of a first exemplary embodiment in which the conversion process of the input data into the load data is carried out by an external service computer
  • 2 shows a block diagram of a second exemplary embodiment in which the conversion process of the input data into the load data is carried out by a microcontroller of the payment transaction terminal
  • Fig. 3 is a flow chart for explaining other embodiments of the invention.
  • FIG. 4 shows a block diagram of an arrangement similar to that in FIG. 1 to explain the reading out of configuration data from the payment transaction terminal.
  • the payment transaction terminal 10 shown in FIGS. 1 and 2 is used to carry out cashless payment transactions using a chip card.
  • This functionality is known, for example, from the ZVT® 700 charging terminal currently offered by CpayS AG.
  • the payment transaction terminal 10 is designed as a compact module with a microcontroller 12, which is connected to a program and working memory 14, an alphanumeric display 16 with one or two display lines and a keypad 18 with ten numeric keys and a few function keys.
  • Further components of the payment transaction terminal 10, for example an interface for a chip card or another data carrier, are of less importance in connection with the present invention and are therefore not shown in the figures.
  • the program and working memory 14 has a writable, non-volatile configuration memory area 20 which contains terminal and customer-specific configuration data.
  • the configuration data comprise approximately 50 setting options. 100 function configurations, 60 telephone numbers, 10 terminal-specific data (header data) and 2 x 16 characters of customer-specific text. More or less configuration data can be provided in alternative embodiments; In particular, it can be provided that the configuration data also have country-specific data such as print or display texts that can be configured using the method according to the invention. These country-specific data, which include, for example, 300 display text lines and 350 print text lines, are then also contained in the configuration memory area 20, which must be designed to be correspondingly larger.
  • the payment transaction terminal 10 also has a communication interface 22 which, in different configurations, either an interface for connection to a telephone line or an interface for connection to a company network or e.g. serial interface for connection to an external computer.
  • the communication interface 22 is e.g. used to obtain authorizations from a background computer that can be reached by telephone or to exchange data with a local or network-connected computer or a cash register.
  • loading data 24 can also be imported via the communication interface 22 in a format specified by the payment transaction terminal 10.
  • the predefined format of the loading data 24 is a simple, text-based format, the interpretation of which places little demands on the program and working memory 14 and on the microcontroller 12.
  • the format of the loading data 24 - after an initial keyword and possibly a starting address - can contain a sequence of hexadecimal numbers in the ASCII code that converted into bytes by the microcontroller 12 and written to the configuration memory area 20 in ascending order.
  • Such a configuration option is known per se from the ZVT® 700 charging terminal already mentioned.
  • a browser 26, which is executed by an operating computer 28, is used in the exemplary embodiments of FIGS. 1 and 2 as a tool for configuring the payment transaction terminal 10 (in FIGS. 1 and 2, the browser 26 is shown on the screen of the Operating computer 28 shown main window).
  • the browser 26 is a common Internet browser, as it is known for example under the names Microsoft® Internet Explorer® or Netscape® Navigator®.
  • the operating computer 28 is a conventional personal computer.
  • the browser 26 displays a configuration form 30, which in the present example has the form of a table with information on the respective configuration parameter in the left column and input fields or input buttons in the right column. Fields for entering text or numbers can be provided as input fields, for example, and radio buttons can be used as input buttons.
  • the configuration form 30 displayed by the browser 26 is a graphical representation of form data 32 that are available in a page description language.
  • HTML hypertext markup language
  • XML extensible markup language
  • the form data 32 also define the graphic appearance of the Configuration form 30, text markup, preset values and so on.
  • the excerpt of the form data 32 shown by way of example in FIGS. 1 and 2 corresponds to the displayed configuration form 30, but for reasons of better readability in FIGS. 1 and 2, the form data 32 is not in HTML or XML, but in a clearer intermediate language are shown.
  • Each line of the intermediate language introduced with one of the keywords "ITEM” or "SUBITEM” corresponds to a line of the configuration form 30.
  • Each such line of the intermediate language contains several sections separated by "$" characters, which are provided for the following elements: a unique identifier of the respective configuration parameter, the text to be displayed to the user, the type of input field or input buttons, the labeling of the input field or input buttons and the preset value (at
  • the intermediate language can be automatically converted into valid HTML or XML code.
  • the browser 26 is set up to transmit the entries (e.g. numbers, texts, markings of buttons and so on) of the completed configuration form 30 in the form of input data 34 to a service computer 36 (FIG. 1).
  • the form data 32 have suitable constructs in order to determine the type of transmission and the transmission format of the input data 34.
  • the transmission type is a transmission of the input data 34 as an e-mail message to an address of the service computer 36 specified by the form data 32 HTML is achieved in that the form data 32 have the method "post" and the action "mailto" with the desired e-mail address as parameters in a 'y ⁇ 7' tag.
  • the transmission format in the example described here is the so-called tag / b ⁇ -we format, in which a line of text is sent for each configuration parameter, which assigns the unique identifier 38 of the configuration parameter specified in the form data 32 and the value 40 specified in the completed form 30.
  • Other transmission formats and / or other types of transmission are provided, in particular the "get" method can be used to transmit the input data 34.
  • the service computer 36 is designed as a server which, among other things, executes a translator 42.
  • the translator 42 is used to convert the input data 34 into the load data 24.
  • each configuration parameter that is, each identifier 38 in the input data 34
  • the translator 42 is in a script language such as Python implemented, which supports the analysis and processing of the textual input data 34 well.
  • the user first loads the form data 32 into the browser 26 on his operating computer 28.
  • the form data 32 may have been sent to the user, for example as an e-mail attachment or on a diskette.
  • the user can load the form data 32 from an external server (for example the service computer 36) into the browser 26 via the Internet.
  • the user now fills out the displayed configuration form 30.
  • the browser 26 for example by means of JAVA®- Applets - carries out certain consistency checks or provides assistance to the user.
  • the user presses a send button displayed by the browser 26 (not shown in the drawing figures).
  • the browser 26 then generates the input data 34 which contain the identifier / value pairs 38, 40 for all configuration parameters provided in the form 30 in the textual e-mail format.
  • the browser 26 sends the input data 34 to the service computer 36 as an e-mail message.
  • the translator 42 executed by the service computer 36 analyzes the input data 34 and converts them into the loading data 24 in accordance with the format required by the ZaWungsclairterminal 10.
  • various consistency checks are preferably carried out.
  • the service computer 36 establishes a remote data transmission connection to the grain numbering interface 22 of the payment terminal 10 and sends the loading data 24 via this connection.
  • the load data 24 are interpreted by the microcontroller 12, and corresponding binary values are written into the configuration memory area 20.
  • the configuration process is now complete, and the user can immediately start up and test the configured payment transaction terminal 10.
  • the service computer 36 does not load the loading data 24 directly into the payment transaction terminal 10 via the remote data transmission connection (for example a telephone connection), but rather that the loading data 24 (for example by email or on diskette or on one through the payment transaction terminal) 10 immediately readable data carriers) are sent to the user.
  • the user can then - if necessary using the operating computer 28 or another local computer - import the loading data itself into the payment transaction terminal 10.
  • This variant is intended in particular for the country-specific or customer-specific configuration of a number of payment transaction terminals 10.
  • the service computer 36 is assigned to an external customer service center.
  • software updates or additional software components can also be imported into the payment transaction terminal 10. Differentiated fees may be charged for these services.
  • the translator 42 is not executed by an external service computer 36, but by the operating computer 28.
  • the operating computer 28 can then immediately - e.g. via a company network or a serial direct connection - transfer the loading data 24 to the interface 22 of the payment terminal 10. In this case, an external service center is not required.
  • the service computer 36 has also been omitted in comparison to FIG. 1.
  • the payment transaction terminal 10 is particularly powerful in terms of its microcontroller 12 and the program and working memory 14.
  • the translator 42 can therefore be executed directly by the microcontroller 12 of the payment transaction terminal 10.
  • the payment transaction terminal 10 is accordingly set up to receive the input data 34 directly from the browser 26 of the operating computer 28 via the communication interface 22.
  • the translator 42 then converts this input data 34 into load data 24 '.
  • the loading data 24 'in the exemplary embodiment in FIG. 2 are not textual Sequences of numbers, but the binary values written directly into the configuration memory area 20.
  • the operating computer 28 carry out an extensive check of the values entered in the configuration form 30 for consistency and completeness. This check can be carried out by the browser 26 or by another program module executed by the operating computer 28.
  • FIG. 3 illustrates several embodiment variants in which this basic method is expanded.
  • a first direction of expansion concerns the use of database information during configuration.
  • 3 shows two options that can be used alternatively or cumulatively, namely firstly access to a first database 60 in connection with the generation of the form data 32 in step 50 and secondly access to a second database 62 in connection with the generation of the loading data 24, 24 'in step 56.
  • the representation of two databases 60, 62 in FIG. 3 is only to be understood conceptually; in actual implementations, all required data can be stored in a single database.
  • the required information ions can be transferred from the databases 60, 62, for example, via a computer network or also by email.
  • the information read out from the first database 60 is recorded, for example, in hidden entries of the configuration form 30 or is displayed as preset values in visible and changeable entries in the configuration form 30 or is displayed as visible and unchangeable entries in the configuration form 30.
  • the browser 26 records all of these entries in the input data 34 in a conventional manner.
  • the information from the second database 62 is first processed by the translator 42 and combined with the input data 34 in order to obtain the load data 24, 24 '.
  • it can also be provided to generate a plurality of sets of load data 24, 24 ′ from a single input data message, each of which results from the input data 34 and the data from one of several data records in the database 62.
  • common settings for a large number of payment transaction terminals 10 can be made via the browser 26, while the different values (e.g. location data or identification numbers) for the individual payment transaction terminals 10 are taken from the database 62.
  • the second direction of expansion of all the exemplary embodiments described so far is to provide a function in the payment transaction terminal 10 for at least partially reading out the configuration data contained in the configuration memory area 20.
  • the configuration data are read out of the configuration memory area 20 and in Output data converted.
  • the output data or information based thereon can be stored in a third database 66 and / or displayed by the service computer 36 or the operating computer 28 or another computer.
  • an output form based on the output data is represented by the browser 26 as an example.
  • database 66 as a "third" database is only to be understood conceptually; in real implementations, database 66 will often be identical to database 60 and / or database 62.
  • FIG. 4 shows an exemplary modification of the system from FIG. 1, in which the read-out and feedback function just described is provided.
  • the conversion process according to step 64 (FIG. 3) takes place in response to any change in the configuration and / or to the initial installation and / or to an explicit request.
  • the output data 70 are merely a simple textual representation of the content of the configuration memory area 20, while more complex processing steps can take place in alternative embodiments. It can be provided that particularly security-critical sections of the configuration memory area 20 are protected from being read out.
  • the output data 70 are transmitted to the service computer 36 via the communication interface 22.
  • the service computer 36 carries out further suitable conversion steps.
  • the information from the output data 70 can be exported to the database 66 and / or converted into an output page 72.
  • the output page 72 is written in a page description language that can be interpreted by the browser 26.
  • the service computer 36 also serves as a server, which, in response to a request 74 from the browser 26, outputs the output page 72 in response to the Browser 26 sends.
  • the browser 26 then displays the output page 72 in the form of the output form 76.
  • the output form 76 not only corresponds to the configuration form 30 in terms of its external design, but rather can be used as a configuration form 30 for a further execution of the method according to the invention.
  • the output page 72 already contains all the form data 32 required for further configuration.
  • the current configuration is shown in the form of changeable entries in the output form 76 serving as a new configuration form 30.
  • the user can thus query the current configuration of the payment transaction terminal 10, change it on the browser 26, and write the changed configuration back into the payment transaction terminal 10.
  • the service computer 36 is shown as the central instance for processing the output data 70.
  • this task can be performed by any other computer previously described - or by the payment terminal 10 or an additional computer.
  • additional security against manipulation can be achieved by using electronic checksums and / or signatures in the transmitted data records.
  • authorization checks can also be carried out - if necessary with different authorization levels.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

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 Zahlungverkehrsterminals vereinfacht, Fehler werden vermieden, und der erforderliche Zeit- und Kostenaufwand wird verringert.

Description

Konfigurieren eines Zahlungsverkehrsterminals
Die Erfindung betrifft das technische Gebiet des Konf igurierens 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 künden- und/ oder gerätespezifisch konfiguriert werden. Dabei werden beispielsweise die Gerätekonf iguration, der Funktionsumfang, gerätespezifische Kopf daten (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 Konf igurationsdatei 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äß An- spruch 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 ZaWungsverkehrsterminals 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 Ü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 Zahlungsverkehrs- terminals. 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 Auf- wand 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 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 erleichtert werden. Der Browser kann ein üblicher Internet-Browser sein. Das Kon- figurierungsformular 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 Zahlungsver- kehrsterminal kann vorgesehen sein, daß sich die Konfigurierung auf Kopfdaten (Daten mit individuellem Terminalbezug) und/ oder auf kundenspezi- fische 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 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/υalue γair). 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 Zahlungsverkehrsterminals ausgeführt. In den beiden erstgenannten Fällen wird vorzugsweise eine Komn unikationsschnittstelle des Zahlungsverkehrsterminals verwendet, um die extern berechneten Ladedaten in das Zahlungsverkehrsterminal zu übertragen und dort den Konfigurationsvorgang auszulösen. In der drit- ten genannten Alternative dient die Kominunikationsschnittstelle vorzugsweise zum Übertragen der Eingabedaten. In einer vorteilhaften Weiterbildung wird die Korr-munikationsschnittstelle nicht nur zum Zwecke der Konfigurierung, sondern auch im normalen Betrieb des Zahlungsverkehrsterminals, beispielsweise zum Anschluß des Zahlungsverkehrsterminals an eine Telef onleitung 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 hinzu- fü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 ZaWungsverkehrsterminals 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 Konfi- gurationsdaten aus dem ZaMungsverkeh-csterrninal 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 erfin- dungsgemäß 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 Zahlungsverkehrs- 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 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 Mikro- controller des Zahlungsverkehrsterminals ausgeführt wird,
Fig. 3 ein Ablauf diagramm 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 Konf igurationsdaten aus dem Zahlungsverkehrs- terminal.
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 Programmund 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 Zahlungsverkehrsterrninals 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 Ko figurationsspeicherbereich 20 auf, der terminal- und kundenspezifische Konfigurationsdaten enthält. Im hier beschriebenen Ausführungsbeispiel umfassen die Konfigurationsdaten ungefähr 50 Einstelloptio- nen, 100 Funktionskonfigurationen, 60 Telefonnummern, 10 terminalspezifi- sche Daten (Kopf daten) und 2 x 16 Zeichen kundenspezifischen Text. In Ausführungsalternativen können mehr oder weniger Konfigurationsdaten vorgesehen sein; insbesondere kann vorgesehen sein, daß die Ko figura- 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 Komn unikationsschnitt- 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 Ko-rununikationsschnittstelle 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 Korrununikationsschnittstelle 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 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® 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 Seitenbeschreibungs- spräche 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 Konfigürierungsformulars 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 Konfigürierungsformulars 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 Eingabe- felds 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 Kon- strukte auf, um die Übertragungsart und das Übertragungsformat der Ein- gabedaten 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 'yό7' "-Tag die Methode "post" und die Aktion "mailto" mit der gewünschten E-Mail- Adresse als Parameter aufweisen. Das Übertragungsf ormat ist im hier beschriebenen Beispiel das sogenannte tag/bα-we-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 Ü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 ZaWungsverkehrsterminal 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 Korn-numkationsschnittstelle 22 des Za ungsverkehrsterminals 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 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 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 Mikrocontr ollers 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 Pro- grammodul 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 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 Inf orma- 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 Konfigürierungsformulars 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 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 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/ 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 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 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 - gegebenenfalls mit unterschiedlichen Autorisierungsstuf en - erfolgen.

Claims

Patentansprüche
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 lbis3, 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 l bis 4, d a durch gekennzeichne t, daß zum Konfigurieren des Zahlungsverkehrsterminals (10) die Ladedaten (24) über eine Kommunikationsschnittstelle (22) in das ZaHungsverkehrsterminal (10) übertragen werden, und daß der Speicherinhalt eines Konfigurations- speicherbereichs (20) des Z- lungsverkehrsterπ- -als (10) entsprechend den Ladedaten (24) verändert wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, d a durch gekennzeic hne t, 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, d a durch gekennzeichnet, d aß die Eingabedaten (34) über eine Kommunikationsschnittstelle (22) in das ZaWungsverkehrsterminal (10) übertragen werden, und daß das Umsetzen der Eingabedaten (34) in die Ladedaten (24') von einem Mikrocontroller (12) des ZaWungsverkehrsterminals (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, d adurch gekennzeichnet, d aß die Kommu-r-i ationsschnittstelle (22) auch im normalen Betrieb des Za ungsverkehrsterminals (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, dad rch gekennze ichnet, d aß 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, dadur ch ge kennze ichnet, 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 Mikro- controller (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, da durch gekennz eichnet, daß das Zahlungsverkehrsterminal (10) zur Ausgabe von Ausgabedaten (70), die dem Speicherinhalt des Konfigurationsspeicherbereichs (20) zumindest teilweise entsprechen, über die Kom-munikationsschnittstelle (22) eingerichtet ist.
PCT/EP2003/003392 2002-04-05 2003-04-01 Konfigurieren eines zahlungsverkehrsterminals WO2003085611A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003226767A AU2003226767A1 (en) 2002-04-05 2003-04-01 Configuration of a payment transaction terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10215005.2 2002-04-05
DE10215005A DE10215005A1 (de) 2002-04-05 2002-04-05 Konfigurieren eines Zahlungsverkehrsterminals

Publications (2)

Publication Number Publication Date
WO2003085611A2 true WO2003085611A2 (de) 2003-10-16
WO2003085611A3 WO2003085611A3 (de) 2004-02-12

Family

ID=28458587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/003392 WO2003085611A2 (de) 2002-04-05 2003-04-01 Konfigurieren eines zahlungsverkehrsterminals

Country Status (3)

Country Link
AU (1) AU2003226767A1 (de)
DE (1) DE10215005A1 (de)
WO (1) WO2003085611A2 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1030277A2 (de) * 1998-05-27 2000-08-23 Diebold, Incorporated Vermächtnisschnittstelle zur Kommunikation mit bestehenden Wirtrechnersystemen (mit Übertragung von Objektmerkmalen)
EP1096447A2 (de) * 1999-11-01 2001-05-02 Citicorp Development Center, Inc. Verfahren und System für eine entfernte Bedienerschnittstelle mit einem Selbstbedienungsendgerät für finanzielle Transaktionen
WO2001067365A1 (en) * 2000-03-09 2001-09-13 Tekchand, Llc Providing internet services to automated teller machine
US6308887B1 (en) * 1997-12-02 2001-10-30 Cash Technologies, Inc. Multi-transactional architecture

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19735106C2 (de) * 1997-08-13 2003-04-30 Siemens Ag Konfigurierbare Telekommunikationsendeinrichtung
JP3472217B2 (ja) * 1999-12-28 2003-12-02 株式会社エヌ・ティ・ティ・ドコモ 仮想端末構成方法及びそのシステム
DE10015775A1 (de) * 2000-03-30 2001-10-04 Deutsche Telekom Ag Kartenmaterial und Verfahren zum Betreiben eines Kartenterminals

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6308887B1 (en) * 1997-12-02 2001-10-30 Cash Technologies, Inc. Multi-transactional architecture
EP1030277A2 (de) * 1998-05-27 2000-08-23 Diebold, Incorporated Vermächtnisschnittstelle zur Kommunikation mit bestehenden Wirtrechnersystemen (mit Übertragung von Objektmerkmalen)
EP1096447A2 (de) * 1999-11-01 2001-05-02 Citicorp Development Center, Inc. Verfahren und System für eine entfernte Bedienerschnittstelle mit einem Selbstbedienungsendgerät für finanzielle Transaktionen
WO2001067365A1 (en) * 2000-03-09 2001-09-13 Tekchand, Llc Providing internet services to automated teller machine

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BARRETT R ET AL: "Intermediaries: an approach to manipulating information" IBM SYSTEMS JOURNAL, IBM CORP. ARMONK, NEW YORK, US, Bd. 38, Nr. 4, 1999, Seiten 629-641, XP002197969 ISSN: 0018-8670 *
HOSOON KU ET AL: "Web-based Configuration Management Architecture for Router Networks" IEEE 0-7803-5864-3, 10. April 2000 (2000-04-10), Seiten 173-186, XP010376682 *
JOAO BAPTISTA SIU ET AL: "Web-based network configuration management system" IEEE, 0-7803-6394-9, Bd. 1, 21. August 2000 (2000-08-21), Seiten 487-491, XP010526797 *
SINTES T: "XML AND SOFTWARE CONFIGURATION" DR. DOBB'S JOURNAL, M&T PUBL., REDWOOD CITY, CA,, US, Bd. 25, Nr. 7, Juli 2000 (2000-07), Seiten 56,58-62, XP000997367 ISSN: 1044-789X *

Also Published As

Publication number Publication date
AU2003226767A8 (en) 2003-10-20
WO2003085611A3 (de) 2004-02-12
AU2003226767A1 (en) 2003-10-20
DE10215005A1 (de) 2003-10-23

Similar Documents

Publication Publication Date Title
DE60207155T2 (de) Objektorientiertes Internetschnittstellensystem für eine industrielle Steuereinrichtung
EP2012205B1 (de) Vorrichtung und Verfahren zum Generieren einer Bedienoberflächenkonfiguration für ein Feldgerät
DE60006018T2 (de) Drahtlose Steuerung eines Feldgerätes in einem industriellen Prozess
EP0466969B1 (de) Verfahren zur Verhinderung unzulässiger Abweichungen vom Ablaufprotokoll einer Anwendung bei einem Datenaustauschsystem
EP1436676B1 (de) Verfahren zum bedienen und zum beobachten von feldger ten
WO2017080768A1 (de) Tastaturapplikation für eine gerätezugriffssoftware
DE10155489A1 (de) Kraftstoffzapfsystem unter Verwendung von XML-Prozessoren Hintergrund der Erfindung
EP1005215B1 (de) Verfahren und Vorrichtung zum Editieren von Konfigurationsdaten für Telekommunikationssysteme
EP1749257A2 (de) Verfahren, vorrichtung und computerprogrammprodukt zum erzeugen eines seiten- und/oder bereichsstrukturierten datenstroms aus einem zeilendatenstrom
EP1646917B1 (de) Verfahren zum erzeugen einer eine spezifische automatisierungsanlage beschreibenden strukturdarstellung
EP0303869B1 (de) Modular strukturiertes digitales Kommunikationssystem mit betriebstechnischen Kommunikationsmitteln
DE19735278A1 (de) Elektronisches Datenerfassungsverfahren und Datenverarbeitungssystem
DE3629404A1 (de) Benutzerprogrammierbare datenverarbeitungsanlage
DE10205765A1 (de) Dokumentenverteilungssystem und Verfahren mit einer verdichteten Dokumentenserviceverwaltung
WO2003085611A2 (de) Konfigurieren eines zahlungsverkehrsterminals
EP1282883B1 (de) Verfahren und system zur transformation digitaler druckdatenströme sowie zugehörige drucker und druckerserver
DE60010078T2 (de) System zur analyse von daten für den elektronischen handel
DE102020213485A1 (de) Numeriksteuervorrichtung
EP1328865A2 (de) Anzeigesteuerung mit aktiven hypertextdokumenten
DE4310615C2 (de) Entwurf elektrischer Vorrichtungen mit mehreren Entwurfswerkzeugen, die zumindest teilweise untereinander inkompatibel sind
DE10142378A1 (de) Datenverarbeitungsanlage, Ressourcensteuergerät und Verfahren zur Fernverwaltung von Ressourcen
DE2950296A1 (de) Sichtanzeigevorrichtung
EP1593036A2 (de) Verfahren und vorrichtung zum modifizieren von modular aufgebauten nachrichten
EP1380907A1 (de) Elektronische Einheit für ein Feldgerät
EP0787331A1 (de) Journalspeicher

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP