GB2510585A

GB2510585A - A data-processing system having a reduced-form card reader

Info

Publication number: GB2510585A
Application number: GB1302190.2A
Authority: GB
Inventors: David Paul Ingram; Daniel Maurice Wagner
Original assignee: Powa Technologies Ltd
Current assignee: Powa Technologies Ltd
Priority date: 2013-02-07
Filing date: 2013-02-07
Publication date: 2014-08-13
Also published as: GB201302190D0

Abstract

A data-processing system includes a first portable processing device which is a mobile communications device, such as a mobile phone, and has an alphanumeric display, and a second portable processing device, which lacks an alphanumeric display and is a card-reading mobile communications device, the two devices communicating with each other, preferably using the Bluetooth(RTM) wireless protocol. The first processing device performs a data-processing operation and indicates on its display various stages occurring during the data-processing operation and indicates, as one of these stages, when authorization is required and accordingly prompts the insertion of a card into the second processing device. An authorization parameter (PIN or signature) is then entered and this is compared with a valid authorization parameter stored on the card. If the entered and stored authorization parameters match each other, the data-processing operation is completed. Since the second processing device has no display of its own, the display on the first processing device is used to provide instructions and feedback in relation to the use of the system. The second device preferably has a keypad to accept PIN input and LEDs to indicate various outputs. The data processing task may be a payment transaction or document retrieval process.

Description

DATA-PROCESSING SYSTEM

The present invention relates to a data-processing system and in particular, but not exclusively, to a data-processing system for use in an electronic payment system.

Present electronic payment systems involve the use of a PIN entry device (a FED"), which is in communication with a point-of-sale (POS) device. The PED, which is portable, has a set of numeric keys and a display. The POS, which is not portable and quite bulky, generally has a more functional display and a set of alphanumeric and other keys. During a payment transaction, the merchant brings up the relevant details on the item being purchased on the screen of the POS.

The total price is also displayed on the PED for checking and confirming by the customer. The customer's card is inserted into the PED, the customer keys in his is PIN number and hands the PED back to the merchant, who, if the entered PIN matches that on the card, completes the transaction. Thus the P05 and PED in concert form two parts of a data-processing system.

This known system has the drawback that the POS is a bulky device, generally designed so as to provide user-relevant information to the merchant (not to the cardholder). The PED therefore must perform the function of providing user-relevant information to the cardholder, since typically the P05 is not designed, or cannot be used, to perform that function. Both POS and PED are also costly. A typical PED might cost between $150 and $300, for example.

In accordance with a first aspect of the present invention there is provided a data-processing system comprising: a first portable processing device having an alphanumeric display and a second portable processing device lacking an alpha or numeric or alphanumeric display, the first and second portable processing devices being mobile communications devices able to communicate with each other, the second processing device being a card-reading device; the first processing device being configured to perform a data-processing operation and to indicate on its display various steps occurring during said data-processing operation and to indicate, as one of said steps, when authorization is required and to prompt the insertion of a card into the second processing device; the system being configured to accept entry of an authorization parameter, which is S compared with a valid authorization parameter stored on the card; said data-processing operation being completed in the event of a match between said entered and stored authorization parameters.

Since only the first processing device has an alphanumeric display, it carries the bulk of the processing load, allowing the second processing device to be reduced in size and complexity. Being portable, the first processing device can be used to prompt the user of the second processing device to carry out certain actions on the second processing device.

is The authorization parameter may be a signature, the card being a magnetic swipe card having displayed thereon the valid signature, the entered signature being entered on the display of the first processing device and being visually compared with the valid signature on the card.

The authorization parameter may be a PIN code and the second processing device may have a set of numeric keys for the entry of the PIN code.

The entered PIN code may be compared by the second processing device with the valid PIN code stored on the card.

The second processing device may comprise one or more control keys. The control keys may comprise a confirmation key and a non-confirmation key, the system being configured to allow the confirmation key or non-confirmation key to be pressed at least following the entry of the PIN code on the numeric keys of the second processing device.

Provision of the control keys enables the user of the second processing device to easily correct mistakes made in, e.g., entering the PIN code.

The system may be configured such that, in the event that said entered PIN code is the wrong code, one or more further attempts at entering the code are allowed.

The second processing device may be configured to read from the card an allowed maximum number of attempts to enter the correct PIN code and may comprise an indicator element for indicating when a final one of said attempts has failed. One or more further indicator elements may be provided for indicating io when one or more of said attempts prior to said final attempt have failed.

A value of a further parameter, which is entered during the data-processing operation carried out by the first processing device, may be prevented from being changed prior to said authorization.

This is advantageous where the further parameter is a sensitive parameter -e.g. the value of an item or details relating to a requested secure document.

The second processing device may be configured to detect if a card is capable of multiple applications as regards its use and to communicate this to the first processing device. The first processing device may be configured to display a numbered list of said multiple applications, and a selection of one or more of said multiple applications may be made by operation of the numeric keys of the second processing device.

The first processing device may be configured to produce an indication of confirmation that said data-processing operation has been successfully completed.

The data-processing system may be configured to carry out the following steps: (a) the first processing device starts the processing operation; (b) the first processing device prompts insertion of the card into the second processing device; (c) the first processing device prompts entry of the PIN code into the second processing device; (d) the system checks if the entered PIN code is the valid PIN code stored on the card and, if not, allows a predetermined number of re-entries of the PIN code; (e) if the entered PIN code is correct, the first processing device treats the processing operation as authorized and completes the processing operation.

The data-processing system may be configured to carry out between steps (b) and (c) the following further steps: (b')the second processing device checks if the inserted card has multiple applications as regards its use and, if so, informs the first processing device; (b") the first processing device displays a numbered list of the multiple applications and requests the selection of the appropriate application; (b'') the selection is made by operation of the numeric keys of the second processing device.

Before step (c) a value of a parameter, which is entered during the data-processing operation carried out by the first processing device, may be prevented from being changed.

The data-processing operation may be a payment transaction or, alternatively, a document-retrieval operation.

In accordance with a second aspect of the present invention, a portable data-processing device is provided for use as the second portable processing device in the above-described data-processing system, the device lacking an alpha or numeric or alphanumeric display, the device having a set of numeric keys and being a card reader.

The portable data-processing device may comprise one or more control keys, which may comprise a confirmation key and a non-confirmation key.

The portable data-processing device may be configured to read from a card an allowed maximum number of attempts to enter the correct PIN code and may comprise an indicator element for indicating when a final one of said attempts has tailed. One or more turther indicator elements may be provided for indicating S when one or more of said attempts prior to said final attempt have tailed.

The portable data-processing device may be configured to detect it a card is capable of multiple applications as regards its use and to communicate this to the tirst portable data-processing device.

Embodiments of the invention will now be described, by way of example only, with reference to the drawings, ot which: Fig. 1 is a block diagram of an embodiment ot a payment-type data-processing system according to the present invention; Fig. 2 is a front view of a PED for use in the embodiment otthe payment-type data-processing system according to the present invention; Figs. 3-16 show different stages in the payment-type data processing system according to the present invention; Figs. 17-21 are an amplification of Fig. 12 and show different steps in a PIN-entering stage; Fig. 22 is a flowchart summarizing the process of the first embodiment involving PIN entry; Figs. 23-26 show steps in the authorisation process involving a swipe card; and Fig. 27 is atlowchart showing the steps followed in a second embodiment otthe data-processing system according to the present invention.

A tirst embodiment of a data-processing system according to the invention involves a payment system 10 having the components shown in Fig. 1.

In Fig. 1 a mobile communications device (e.g. a smart phone, iPhonerM, iPadTM, etc.) 12 and a FED 14 are in communication with each other via, e.g., BluetoothrM or a physical electronic connection. The mobile communications device 12, which acts as a P05, also communicates with a P05 server 16 via LAN, WAN or the Internet. The P05 server 16 may service a large number of mobile communication devices 12, and in turn communicates with a merchant S dashboard 18 and an administration dashboard 20. Both dashboards contain Web applications and libraries for use by the merchants on the system or by a system administrator, and provide the merchants and administrator with an overview of the processes being carried out. The P05 server 16 also communicates with a payment gateway 22, sometimes via one or more intermediary systems. The gateway 22 functions as a server for the company running the payment system, generally referred to as the "Merchant Acquirer" 26.

(An "acquirer" is generally a regulated financial institution that performs credit and debit card processing on behalf of the Card Schemes, where the Card Schemes are credit and debit card companies such as VisaTM, Mastercard1, AmexiM, etc).

The mobile communications device 12 has installed on itan application ("app") specifically designed to run the present payment system. The PED 14 is a stripped-down unit having essentially only a set of numeric keys 15 and control keys 17 and 19 and no display, though it may also include LEDs 21 and 23 as described in more detail later (see Fig. 2). It also has a slot for accepting a chip-and-PIN card and may also include a slot for a swipe card.

An example of the operation of the payment system will now be described with reference to Figs. 3-16.

Firstly, a merchant, who has the use of a mobile communications device 12 on which has been installed the appropriate app. for carrying out the payment processing, calls up the app and is authenticated, for example by username and password or by some other secure token (Fig. 3). Then the merchant creates the sales order (e.g. by selecting products from a product list, scanning product barcodes, or entering details regarding the product) on the device 12 (Fig. 4).

Such details may include the identity and price of the product and, optionally, a photograph of the product. Next, the merchant is prompted that the next stage is the payment stage (Fig. 5). He ascertains from the customer how the customer wishes to pay for the product -i.e. by cash or card -and enters the selection on the device 12 (Fig. 6). The device 12 then prompts the customer to confirm that S the amount shown is the correct amount. If that is the case, the customer confirms by pressing the "check" key 17 on the PED (Fig. 7). At that point the price shown is frozen on both PED and POS and cannot be altered without the merchant or cardholder cancelling the present transaction and starting again.

This frozen state of the price is indicated by a visual signal (for example a padlock icon) on the display of the device 12 (Fig. 8). This freezing of the price amounts to the prevention of change of the value of a parameter entered during the data-processing operation carried out by the device 12, as recited in the claims. Then the device 12 prompts the customer to insert his card 28 into the PED 14, which he does (Fig. 9). At this point the FED checks if the card is a multiple-application card (e.g. VisarM, MasterCard1, Credit, Debit). This is ascertained by the RED from the chip on the card. If the card is indeed multiple-application, the possible applications are displayed on the device 12 (Fig. 10) as a prompt for the customer to select the appropriate application using the numeric keypad on the FED -in this case the credit card application. A prompt to indicate processing is then shown on the device 12 (Fig. 11). This involves the device 12 and the card communicating to determine which cardholder verification method (CVM, e.g. FIN entry, signature, etc) the card requires, and whether verification and the transaction can proceed without connecting via servers 16 and 22 and any intermediary systems to the Acquirer 26 and card Issuer (authorization network), or whether a connection is required (see Fig. 1) and receiving, if all is well, an indication that processing can continue. If a PIN is required the device 12 prompts the customer to enter his PIN, following which the customer again presses the "check" key 17 (Fig. 12) in confirmation. The key 17 therefore acts as a "confirmation key". If a mistake has been made in entering the PIN, the customer simply presses the "cross" key (non-confirmation key) 19 and starts entering the PIN again. An authorization request message is encrypted either in the FED 14 or in the device 12 before being transmitted to the server 22, from which it is passed on to the authorization network (Fig. 13). If the transaction is approved by the authorization network, the device 12 prompts the user to remove his card (Fig. 14), after which the merchant proceeds to the receipt-issuing stage (Fig. 15). In this stage the merchant can either dispense with the issuing of a receipt (press "Skip" on the screen) or can choose to send a receipt (press "send Receipt"). The receipt may then be sent either by email, in which case the merchant requires the customer's email address, or by sms, in which case he requires the customer's mobile-phone details. Finally, the device 12 indicates that the transaction has gone through and states that a receipt has been sent, as required (Fig. 16).

Note that, depending on the card being used, the checking of the entered PIN against the PIN stored on the card may be performed directly by the PED or by the server 22. In the latter case the PED sends the entered PIN to the device 12, is which forwards it on to the server. The server then validates this PIN and sends the result to the device 12. The valid PIN may be sent to the server as part of the authorization request message or at some stage prior to the PIN-entering step of Fig. 12.

A preferred version of the PED includes six LEDs in two groups of 3, namely group 21 and group 23 (see Fig. 2). In order from left to right these LEDs are as follows: 1. Blue LED 21 -indicates Bluetooth'TM, power and charging status; 2. Red LED 21 -indicates a negative action or negative key press; 3. Green LED 21 -indicates a positive successful card insertion, a positive key press or processing taking place; 4-6. Bi-colour Red/Green LEDs 23-indicate number of retries of the cardholder verification method (e.g. PIN); The exact colours used may be different from those indicated. However, green and red are advantageously used to indicated a positive ("go") and negative ("no-go") action, respectively, since this tends to be conventional usage (cf. traffic lights).

The PIN-entering stage shown in Fig. 12 is now explained in greater detail with S the aid of Figs. 17-20.

Fig. 17 corresponds to Fig. 12, in which the customer is prompted to enter his PIN into the FED. Should the customer enter the wrong PIN, the device 12 informs the customer that the FIN was wrong and asks him to re-enter the PIN (Fig. 18). The customer then makes one or more further attempts. Note that the card will normally have been programmed with a maximum number of tries for the PIN, after which the card may be blocked. This maximum number is read by the PED and used to set a PIN-try counter. Fig. 19 shows a situation where the customer makes a final attempt to enter the correct PIN. Should this final attempt is also be wrong, then the counter value is exceeded and the CVM (Card Verification Method) result is returned to the device 12 for subsequent processing (Fig. 20). This will be an indication on the device 12 that the transaction is now void.

In one version of this embodiment, during the PIN-retry process the customer is informed that his PIN-entry attempts are invalid by an indication to that effect on the screen of the mobile device 12. Another version, however, makes use of three LEDs 23 in the FED (see Fig. 2). Referring to Figs. 21(a)-(d) and assuming that the PIN-retry counter has been set to a value of, e.g., six, for the first three tries the LEDS 23 will all three be lit in one colour, e.g. green. When the customer tries a fourth time, also wrongly, the left-most LED 23 will change colour to, e.g., red. Similarly, after a fifth wrong attempt the middle LED 23 will change to red and after a sixth and final wrong attempt the right-most LED 23 will turn red. This is therefore an indication to the customer that his attempts at entering a correct PIN have not met with success. When any one of these final three attempts is successful, however, the appropriate LED 21 may be arranged to flash green instead of being a continuous green. Also there may be more than or less than three LEDs 23. At minimum there may be one LED 23 only, which preferably lights up a first colour, e.g. green, when the final allowed PIN-entry attempt stage has been reached, and turns e.g. red if that final attempt is a wrong attempt. If the final attempt is correct, however, the LED 23 may flash green to S show that the entry was a success.

Note that, instead of the three LEDs 23 being lit a first colour before the final three tries, they may be turned off, only then coming on when the final three tries are in progress. In that case a LED 21 turned on green will indicate success, while the same LED turned on red will indicate failure. This also applies where only one LED 21 is used.

The above-described payment process is summarized in the flowchart of Fig. 22.

is The FED has so far been described in connection with the use of a chip-and-FIN card. It may also, or alternatively, be used in conjunction with a magnetic-stripe card. (Where the device 14 is purely a swipe-card device, it cannot, of course, be called a FED as such.) Figs. 23-26 show the steps involved in the use of a magnetic-stripe card ("swipe card"). It is assumed that the authorization process has proceeded to the step of Fig. 8, in which the price of the product is locked and cannot be changed without voiding the present transaction. At that point now the customer is prompted to insert his swipe card, which he does by passing the card through a slot made in one side of the FED -here the right-hand side (Fig. 23). Card data are read from the magnetic stripe on the card (this is confirmed by flashing of the green LED 21 and visual prompt on the mobile device 12), and these are passed to the mobile device 12. This device then makes a payment authorization request to the cardholder's issuing bank. This is signalled by the "Frocessing" indication on the mobile device (Fig. 24). If the request is accepted by the bank, the mobile device displays a signing window on its screen and the customer duly writes his signature on the screen (Fig. 25). The merchant (or the customer) confirms this signature by pressing a "Done" icon on the screen. At this point the mobile device prompts the merchant to compare the written signature with that on the card and decide whether or not to accept the transaction or render it void (Fig. 26). This is done in this particular example by the merchant pressing an "Accept S Signature" or a "Reject Signature" icon on the screen. The app then proceeds to the steps shown in Figs. 14-16.

The entering of a PIN on the device 14 and, alternatively, the writing of a signature on the device 12 constitute the entering of a further parameter, which is io used for authorization or validation purposes.

What has been described is a payment system comprising a mobile communications device 12, which acts as a POS, and a PED 14. Both items are much more compact than the conventional POS and PED, since the FOS is a is mobile handheld device and the FED, which is likewise portable, has no display providing instructions to the customer. Both items, and especially the RED, are also cheaper than the conventional items. Indeed, a PED as just described is likely to cost only one-tenth of the conventional FED. In addition, the use of a mobile device for the POS has enabled the PED to dispense with the usual display. This is because, being a mobile device, the user interface (display) of the device 12 is easily shared with the customer, who can then take his prompts and instructions from this device instead of relying upon just the PED. The FED therefore need include no indicators at all, except perhaps for the LEDs 21, which give the customer greater confidence in the use of the FED. However, as described above, the RED may also include the LEDs 23, which would enable him to keep re-entering the PIN without the need to consult the mobile device 12, which may well at this stage have been moved away from the customer by the merchant.

In its broadest expression, the present invention is not a payment system per se, but a data-processing system involving the use of two data processors 12 and 14.

These processors utilize a shared visual user interface for the purpose of providing instructions and feedback to a user of the system, removing the need for each device to have its own visual user interface for this purpose. The processor 12 performs a data-processing operation, which requires authorization or validation of some form of identity or authority before it can be completed.

Authorization or validation takes place with the aid of the data processor 14. The processor 14 includes a valid authorization/validation parameter, which is compared with a corresponding parameter entered by the user. This authorization/validation parameter may, in the embodiment just described, be a multi-digit code stored in the card or a graphical code such as a signature written io on the card. It is even envisaged that this parameter will be a biological code such as a finger print, retina scan or even a DNA sample. Furthermore, the processing functions are divided between the two processors, such that the processor 12 performs all, or virtually all, of the display (e.g. instruction and feedback) functions required. This is convenient, since the processor 12 will in any case require a display which enables a user to interface with those parts of the data-processing operation outside the authorization function. This enables the processor 14 to be simplified and reduced in size.

A second embodiment of the data-processing system will now be described.

In this embodiment the data-processing operation retrieves sensitive documents from a central server. As with the first embodiment, the data processor 14 is a PED, while the data processor 12 is again a mobile communications device linked wirelessly to the FED. In this case the PED is used in conjunction with a security pass having stored on it a pass-code. Either the mobile device 12 is able to call up an index of the documents required or the user of the mobile device can directly specify a required document by entering its details. Being mobile, the device 12 may be situated in any convenient location, where wireless communication with the server can be achieved. Indeed, it may be brought to the very person requiring the sensitive document.

The operation of this embodiment is summarized in the flowchart of Fig. 27.

Firstly, the document retriever is authenticated on the device 12 (S100) (e.g. by username and password, or by some other secret token). The device 12 then prompts the requester to insert his pass (S102), upon which the device 14 reads S from the card those types and parts of a document which the requester is permitted to obtain (e.g. because different documents and parts thereof relate to different security levels) and communicates these to the device 12 (Si 04). The retriever then asks the requester which document he requires and either enters its details himself on the device 12 or selects it from an index or list (Si 06). The io requester confirms these details by pressing the "check" button 17 on the PED i4. The device 12 now checks, with reference to the information received in step Si 04, that the requested document type and part of document is permitted under the clearance level of the requester (5108). If so, the identity and details of the document are locked and cannot at this stage be altered (S110). This acts as a is safeguard against either the retriever or the requester changing the document details either accidentally or deliberately, which could compromise security. As with the first embodiment, this locking of the document details corresponds to the prevention of change in the value of a parameter entered before the authorization stage during the data-processing operation carried out by the device i2, as recited in the claims. The device i2 then prompts the requester to key his security PIN into the device 14 (S112), after which he presses the confirmation key 17. As with the first embodiment, should a mistake be made during entry of the PIN, the "cross" (non-confirmation) key i9 can be pressed and the PIN can be entered again. Then, either the PED itself checks the validity of the entered PIN against what is stored on the pass, or the device 12 sends the entered PIN to the server, which checks it against the requester's valid PIN, which is stored on the server (Sii4). As with the first embodiment, all data sent to the server is preferably encrypted first. Assuming authorization is confirmed, the requester is prompted by the device i 2 to remove his pass (Si i 6), after which the retriever may generate a confirmation slip for the requester (S118), the session being then terminated (S120). The device 12 is then reset to its initial screen, so as to be able to carry out the next retrieval operation (5102). At this point, however, the retriever may log out (Si 22). Finally, the document is supplied to the requester in any suitable manner -e.g. hard copy or electronic copy.

In the event that the device 12 indicates to the retriever that the requested S document is not permitted to this particular requester (see step 5108), the device 12 prompts the requester to remove his pass (S124) and the session is terminated (Si 24). Control may then pass either to step S102, in which case the retriever awaits his next request, or to step 5122, in which case he logs off. The same thing happens if the entered PIN is incorrect (see steps Si 14 and S124).

It can be seen that this is similar to the data-processing operation of the first embodiment except for the lack of a payment step and a change in the order of some of the steps.

is Also as with the first embodiment, the FED may be configured to read from the requester's pass a maximum number of retries in entering the PIN, this number then being used to set a counter in the device 12, as in the first embodiment.

Hence Figs. 17-21 apply to the second embodiment, as do also Figs. 23-26, with of course the word "merchant" replaced by "retriever" and the word "payment" replaced by "document retrieval". Similarly, instead of a chip-and-PIN reader as the device 14, a swipe-card reader -or a reader capable of both -may be employed.

The embodiment that has just been described is not, of course, a system for the mere presentation of information, but rather a system for the accessing of information in the form of sensitive documents in a secure manner.

A third embodiment involves a combination of the first and second embodiments, in which the requester not only retrieves a requested document (or part of a document), but also pays for this service. This embodiment follows a similar set of steps as the second embodiment, but includes also the steps of Figs. 5 and 6 relating to the first embodiment between the steps SlOB and SilO in Fig. 27. As in the first embodiment, confirmation of the price by the requester results in the locking of this price as well as the locking of the requested document.

While it has been assumed that the PED will be linked to the mobile communications device by wireless means (e.g. Bluetooth1), the link may instead be a wired link.

The invention also envisages a situation, in which the server is dispensed with, the mobile communications device 12 taking over the server's functions. Thus, in the first embodiment the mobile device 12 would store a list of products and be the final arbiter as to whether or not a transaction was valid. In the second embodiment the mobile device 12 would store a list of available documents and be the final arbiter as to whether or not a document-retrieval request was valid.

is The foregoing description has been given by way of example only and it will be appreciated by a person skilled in the art that modifications can be made without departing from the scope of the present invention.

Claims

CLAIMS1. A data-processing system, comprising: a first portable processing device having an alphanumeric display and a second portable processing device lacking an alpha or numeric or alphanumeric display, the first and second portable processing devices being mobile communications devices able to communicate with each other, and the second portable processing device being a card-reading device; the first processing device being configured to perform a data-processing operation and to indicate on its display various steps occurring during said data-processing operation and to indicate, as one of said steps, when authorization is required and to prompt the insertion of a card into the second processing device; the system being configured to accept entry of an authorization parameter, which is compared with a valid authorization parameter stored on the card; said data-processing operation being completed in the event of a match between said entered and stored authorization parameters.
2. A data-processing system as claimed in claim 1, wherein the authorization parameter is a signature, the card is a magnetic swipe card having displayed thereon the valid signature, the entered signature is entered on the display of the first processing device and is visually compared with the valid signature on the card.
3. A data-processing system as claimed in claim 1, wherein the authorization parameter is a PIN code and the second processing device has a set of numeric keys for the entry of the PIN code.
4, A data-processing system as claimed in claim 3, wherein the entered PIN code is compared by the second processing device with the valid PIN code stored on the card.
5. A data-processing system as claimed in claim 3 or claim 4, wherein the second processing device comprises one or more control keys.
6. A data-processing system as claimed in claim 5, wherein the control keys comprise a confirmation key and a non-confirmation key, the system being configured to allow the confirmation key or non-confirmation key to be pressed at least following the entry of the PIN code on the numeric keys of the second processing device.
7. A data-processing system as claimed in any one of claims 3 to 6, wherein the system is configured such that, in the event that said entered PIN code is the wrong code, one or more further attempts at entering the code are allowed.
8. A data-processing system as claimed in claim 7, wherein the second processing device is configured to read from the card an allowed maximum number of attempts to enter the correct PIN code and to communicate this to the first processing device.
9. A data-processing system as claimed in claim 8, wherein the second processing device comprises an indicator element for indicating when a final one of said attempts has failed.
10. A data-processing system as claimed in claim 9, wherein the second processing device comprises one or more further indicator elements for indicating when one or more of said attempts prior to said final attempt have failed.
11. A data-processing system as claimed in any one of the preceding claims, wherein a value of a further parameter, which is entered during the data-processing operation carried out by the first processing device, is prevented from being changed prior to said authorization.
12. A data-processing system as claimed in any one of the preceding claims, wherein the second processing device is configured to detect if a card is capable of multiple applications as regards its use and to communicate this to the first processing device, the first processing device is configured to display a numbered list of said multiple applications, and a selection of one or more of said multiple applications can be made by operation of the numeric keys of the second processing device.
13. A data-processing system as claimed in any one of the preceding claims, wherein the first processing device is configured to produce an indication of confirmation that said data-processing operation has been successfully completed.
14. A data-processing system as claimed in claim 3, the system being configured to carry out the following steps: (a) the first processing device starts the processing operation; (b) the first processing device prompts insertion of the card into the second processing device; (c) the first processing device prompts entry of the PIN code into the second processing device; (d) the system checks if the entered FIN code is the valid FIN code stored on the card and, if not, allows a predetermined number of re-entries of the FIN code; (e) if the entered PIN code is correct, the first processing device treats the processing operation as authorized and completes the processing operation.
15. A data-processing system as claimed in claim 14, wherein the system is configured to carry out between steps (b) and (c) the following further steps: (b') the second processing device checks if the inserted card has multiple applications as regards its use and, if so, informs the first processing device; (b") the first processing device displays a numbered list of the multiple applications and requests the selection of the appropriate application; (b") the selection is made by operation of the numeric keys of the second processing device.
16. A data-processing system as claimed in claim 14 or claim 15, wherein before step (c) the first processing device is configured to prevent a value of a parameter, which is entered during the data-processing operation carried out by the first processing device, from being changed.
17. A data-processing system as claimed in any one of the preceding claims, wherein said data-processing operation is a payment transaction.
18. A data-processing system as claimed in any one of claims 1 to 16, wherein said data-processing operation is a document-retrieval operation.
19. A portable data-processing device for use as the second portable processing device in the system claimed in any one of claims 3 to 18, the device lacking an alpha or numeric or alphanumeric display, the device having a set of numeric keys and being a card reader.
20. A portable data-processing device as claimed in claim 19, comprising one or more control keys.
21. A portable data-processing device as claimed in claim 20, wherein the control keys comprise a confirmation key and a non-confirmation key.
22. A portable data-processing device as claimed in any one of claims 19 to 21, the device being configured to read from a card an allowed maximum number of attempts to enter the correct PIN code and to communicate this to the first portable data-processing device.
23. A portable data-processing device as claimed in claim 22, comprising an indicator element for indicating when a final one of said attempts has failed.
24. A portable data-processing device as claimed in claim 23, comprising one or more further indicator elements for indicating when one or more of said attempts prior to said final attempt have failed.
25. A portable data-processing device as claimed in any one of claims 19 to 24, wherein the device is configured to detect if a card is capable of multiple applications as regards its use and to communicate this to the first portable data-processing device.
26. A data-processing system as hereinbefore described with reference to the attached drawings.
27. A portable data-processing device as hereinbetore described with reference to the attached drawings.