AU2017213565A1 - Transaction and transaction processing systems and methods - Google Patents

Abstract

Abstract An electronic point of sale device is described. The device includes a housing having at least first and second stable orientations in which the device can be positioned, a touch screen 5 display, at least one card reading device, a communications interface, and at least one processor in communication with at least one memory device and the touch screen display. The at least one processor is configured to provide at least one user interface on the touch screen display by which a user can interact with the point of sale device, the at least one user interface including a transaction payment interface for facilitating payment of a bill having a transaction amount. The 10 device also includes an orientation sensor in communication with the at least one processor, the orientation sensor being configured to detect an orientation of the point of sale device and send an orientation signal to the at least one processor. The at least one processor is configured to orient the display of the at least one user interface on the touch screen display according to the orientation signal.

Description

1001903398 2017213565 11 Aug 2017 1

Transaction and transaction processing systems and methods

Field of the invention

The present invention relates to transaction and transaction processing systems and methods. 5 Background of the invention

Almost every physical shop or store makes use of a point of sale/transaction system to complete transactions. By way of example, basic point of sale systems for cash transactions include cash registers (or similar) offering the simple functionality of adding item amounts to determine a total purchase price, and deducting this from an amount tendered to determine the 10 change required. In addition to facilitating cash transactions, most modem point of sale systems provide for electronic transactions such as payment by credit card, debit card, a store/merchant card or similar.

It would be desirable to provide transaction systems and methods that provide the public with additional features and/or a useful alternative to existing transaction systems and methods. 15 Reference to any prior art in the specification is not, and should not be taken as, an acknowledgment or any form of suggestion that this prior art forms part of the common general knowledge in Australia or any other jurisdiction or that this prior art could reasonably be expected to be ascertained, understood and regarded as relevant by a person skilled in the art.

Summary of the invention 20 In one aspect the present invention provides an electronic point of sale device including: a housing having at least first and second stable orientations in which the device can be positioned; a touch screen display; at least one card reading device; a communications interface; at least one processor in communication with at least one memory device and the touch screen display, the at least one processor configured to provide at least one user interface on the touch 25 screen display by which a user can interact with the point of sale device, the at least one user interface including a transaction payment interface for facilitating payment of a bill having a transaction amount; and an orientation sensor in communication with the at least one processor, 1001903398 2017213565 11 Aug 2017 2 the orientation sensor being configured to detect an orientation of the point of sale device and send an orientation signal to the at least one processor, wherein the at least one processor is configured to orient the display of the at least one user interface on the touch screen display according to the orientation signal. 5 The first and second stable orientations may include a merchant-facing orientation in which, in use, the point of sale device typically faces a merchant and a customer-facing orientation in which, in use, the point of sale device typically faces a customer, and wherein the at least one processor may be configured to display merchant-relevant information when the orientation sensor detects the point of sale device is in the merchant-facing orientation, and to 10 display customer-relevant information when the orientation sensor detects the point of sale device is in the customer-facing orientation.

The orientation sensor may be an accelerometer, mercury switch, or any other means enabling the sensing of motion and/or orientation.

In a second aspect the present invention provides an electronic point of sale device 15 including: a housing; a touch screen display; at least one card reading device; a communications interface; and at least one processor in communication with at least one memory device and the touch screen display, the at least one processor configured to provide at least one user interface on the touch screen display by which a user can interact with the point of sale device, the at least one user interface including a transaction payment interface for facilitating payment of a bill 20 having a transaction amount, and wherein the at least one user interface includes a bill splitting interface for splitting the transaction amount into a plurality of payment amounts, each payment amount for payment by one of a plurality of parties, and wherein the transaction payment interface is configured to facilitate payment of each payment amount by the relevant party.

The bill splitting interface may include an add party control operable to increase the 25 number of parties between which the bill is to be split.

The bill splitting interface may include a remove party control operable to decrease the number of parties between which the bill is to be split.

Payment of each separate payment amount may be achieved by a payment means selected from a group including: a credit card payment means read by the at least one card reading 1001903398 2017213565 11 Aug 2017 3 device; a debit card payment means read by the at least one payment device; and a cash payment means.

The bill splitting interface may provide bill splitting options selected from a group including: an even split option in which the at least one processor is operated to divide the 5 transaction amount amongst the plurality of parties such that the payment amount for each party is substantially equal; a percentage split option in which each party nominates a percentage of the transaction amount to be paid by that party and the payment amount for a party is calculated according to the percentage nominated by that party; an amount split option in which each party nominates a dollar amount to be paid by that party; an item split option in which each party 10 nominates one or more items from the bill and the payment amount for a party is the sum of the value of the items nominated by that party; and a random split option in which the at least one processor is operated to randomly split the transaction amount amongst the number of parties nominated.

The bill splitting interface may consist of any of a variety of graphic elements, 15 representing a whole transaction amount. These graphic elements may be subdivided into smaller elements, representing each purchaser’s share of a given transaction. An example case may present the transaction amount as a pie chart with a plurality of segments, each segment representing one of the plurality of parties and being sized to indicate a proportion of the total transaction amount to be paid by that party, and wherein the interface includes one or more 20 proportion controls operable to alter the proportions of the total transaction amount payable by each of the separate parties.

The housing may have at least first and second stable orientations in which the device can be positioned; and the device may further include an orientation sensor in communication with the at least one processor, the orientation sensor being configured to detect an orientation of the 25 point of sale device and send an orientation signal to the at least one processor, wherein the at least one processor is configured to orient the display of the at least one user interface on the touch screen display according to the orientation signal.

Also described herein is an electronic point of sale device including at least one processor in communication with at least one memory device, a touch screen, at least one card reading 1001903398 2017213565 11 Aug 2017 4 device, and a communications interface, the at least one processor is configured to display information on the touch screen and process user input commands received by the touch screen.

The at least one processor may include a general processing device for processing non-secure data and a secure processing device for processing secure data. Processing secure data 5 may include encryption processing.

The touch screen may be connected to both the general processing device and the secure processing device, the touch screen being controlled by the general processing device for non-secure applications, and by the secure processing device for secure applications.

The device may include a secure housing for housing at least the secure processing 10 device. The secure housing may be a tamper-proof or tamper-evident housing. The secure housing may be connected to the touch screen by a cable in a tamper-proof or tamper-evident manner. The cable connecting the secure housing to the touch screen may be laminated with an optical or other refractory coating in order to prevent/discourage/show tampering with the cable.

The at least one card reading device may include one or more of a swipe-type card reader, 15 an insert-type card reader, and a contactless reader.

The communications interface may include a network interface allowing device 100 to transmit information to, and receive information from, a network. The network may be a public network such as the Internet, or a private network.

The device may further (or alternatively) include, and the processor be in communication 20 with, one or more of: an image capture device, an audio capture device, a biometric capture device, a speaker, and a printer.

The device may have a base defining a first surface and a second surface meeting at a ridge, the device pivotable about the ridge to stably rest on either the first or second surface, wherein when resting on the first surface the touch screen is angled in a customer friendly 25 orientation, and when resting on the second surface the touch screen is angled in a merchant friendly orientation.

The device may further (or alternatively) include an orientation detection means for detecting when the device is in the customer or merchant friendly orientation. Based on an 1001903398 2017213565 11 Aug 2017 5 orientation signal generated by the orientation detection means, the processor may be configured to display information in a first orientation when the touch screen is in the customer friendly orientation, and rotate the display by 180 degrees when the touch screen is in the merchant friendly orientation. 5 In an alternative embodiment, the invention provides methods of operating a point of sale device. The device may be a device such as that described in one or more of the above statements. The methods include one or more instructions executable by a computer processor of the device. The instructions may be stored on a computer readable memory accessible by the device. 10 The methods may include a method for providing a user of the device with the choice of printing a transaction receipt and/or generating an electronic receipt. If the user elects to print the receipt, the device may print the receipt on an on-board printer or may send a print request to a remote printer via a communications interface to print the receipt. If the user elects to generate an electronic receipt, the device may generate receipt data representative of the receipt and 15 transmit the receipt data to a computer system where the receipt data may be accessed by the user. The device may email the receipt data to an email address supplied by the user. Alternatively, or additionally, the device may transmit the receipt data to a server whereby the receipt data is made accessible to the user via a web interface.

The methods may further (or alternatively) include a method for providing a user of the 20 device with the ability to categorise transactions into one or more categories. If the user elects to categorise a transaction, transaction data is associated with category data relating to the or each selected category. The transaction and associated category data may be transmitted to a computer system where the transaction and associated data can be accessed by the user. The device may email the transaction and associated category data to an email address supplied by 25 the user. Alternatively, or additionally, the device may transmit the transaction and associated category data to a server whereby the transaction and associated category data is made accessible to the user via a web interface. The web interface may allow a user to sort transactions according to transaction categories. 1001903398 2017213565 11 Aug 2017 6

The methods may further (or alternatively) include a method for providing a tab service to a user. The device may access a database storing user details and, where a user has opened a tab, the balance of the users tab.

The methods may further (or alternatively) include a method for providing a customer 5 with a reward. The device may randomly select customers eligible for rewards. Alternatively, the device may select customers eligible for rewards in accordance with one or more eligibility criteria. The eligibility criteria may include: the number of visits a customer has made to a merchant’s shop; the amount a customer has spent at a merchant’s shop, and/or the value of a transaction. 10 The methods may further (or alternatively) include a method for eliciting a donation from a user of the device. The device may automatically suggest a donation amount and/or a donation recipient.

The methods may further (or alternatively) include a method by which a customer can advertise a transaction using the device. The method may include providing the customer with 15 one or more social networking tools on which the transaction may be advertised and, if the customer selects one or more of the social networking tools, advertising the transaction on that tool. The social networking tools may include one or more of dig, twitter, StumbleUpon, facebook, Google.

The methods may further (or alternatively) include a method for capturing customer and 20 or transaction data for access by a merchant. The customer data captured may include one or more of: name, address, gender, age, income, place of residence, item(s) purchased, method of payment, photograph. The customer data may be transmitted to a computer system where the customer data can be accessed by the merchant. The customer data may be stored in a database. The device may email the customer data to an email address supplied by the merchant. 25 Alternatively, or additionally, the device may transmit the customer data to a server whereby the customer data is made accessible to the merchant via a web interface. The web interface may the merchant to analyse and generate reports based on the customer data.

As used herein, except where the context requires otherwise, the term "comprise" and variations of the term, such as "comprising", "comprises" and "comprised", are not intended to 30 exclude further additives, components, integers or steps. 1001903398 2017213565 11 Aug 2017 7

Further aspects of the present invention and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way of example and with reference to the accompanying drawings.

Brief description of the drawings 5 Figure 1A provides a top front perspective view of a point of sale device in accordance with an embodiment of the invention.

Figure IB provides a top rear perspective view of the device shown in Figure 1A.

Figure 2 provides a high level electronic functional block diagram of the various components of the point of sale device of Figures 1A and IB. 10 Figure 3 provides a network diagram showing the device of Figure 1 connected to further computing devices.

Figure 4A provides a top front perspective view of a point of sale device in accordance with an alternative embodiment of the invention.

Figure 4B provides a bottom view of the point of sale device shown in Figure 4A. 15 Figure 5 provides a top front perspective view of a point of sale device in accordance with a further alternative embodiment of the invention.

Figures 6A and 6B provide an example user of interface screens provided by a point of sale device in accordance with an embodiment of the invention, the user interface screens for entering identification details. 20 Figure 7A provides an example user interface provided by a point of sale device in accordance with an embodiment of the invention, the interface for customer use in selecting a receipt option.

Figures 7B and 7C provide example user interfaces for viewing/analysing electronic receipt information generated via use of the interface of Figure 7A. 1001903398 2017213565 11 Aug 2017 8

Figure 8A provides an example user interface provided by a point of sale device in accordance with an embodiment of the invention, the interface for customer use in categorising payments made.

Figures 8B, 8C and 8D provide example user interfaces for viewing/analysing payment 5 categorisation details generated via use of the interface of Figure 8A.

Figure 9 provides an example user interface provided by a point of sale device in accordance with an embodiment of the invention, the interface for use in opening a tab.

Figure 10 provides an example user interface provided by a point of sale device in accordance with an embodiment of the invention, the interface being used to notify a customer of 10 a customer reward.

Figure 11 provides an example user interface provided by a point of sale device in accordance with an embodiment of the invention, the interface for use in making a donation.

Figure 12 provides an example user interface provided by a point of sale device in accordance with an embodiment of the invention, the interface for customer use in advertising a 15 purchase.

Figures 13A to 13F provide example user interfaces provided by a point of sale device in accordance with an embodiment of the invention, the interface for use in dividing a transaction payment between multiple parties.

Figures 14A to 14D provide example user interfaces for viewing/analysing customer data 20 captured by a point of sale device in accordance with an embodiment of the invention.

Figure 15 provides a high level information flow diagram depicting the flow of information between components of a device such as the device of Figure 1.

Figure 16 provides a partial exploded representation of the device of Figure 1.

Figure 17A provides a side view of a point of sale device in accordance with an 25 alternative embodiment of the invention, the point of sale device being in a first stable orientation. 1001903398 2017213565 11 Aug 2017 9

Figure 17B provides a side view of a point of sale device of Figure 17A in a second stable orientation.

Figure 17C provides a bottom front perspective view of the point of sale device shown in Figure 17 A. 5 Figure 17D provides a rear view of the point of sale device shown in Figure 17A.

Figure 18 provides an example user interface provided by a point of sale device in accordance with a further embodiment of the invention, the interface for use in displaying and printing receipt options.

Figures 19A and 19B provide examples of user interface screens provided by a point of 10 sale device in accordance with an embodiment of the invention, the interface for use in entering a tip as part of a transaction.

Figures 20A and 20B provide examples of user interface screens provided by a point of sale device in accordance with an embodiment of the invention, the interface for use in providing a refund to a customer. 15 Figure 21A and 21B provide examples of user interface screens provided by a point of sale device in accordance with an embodiment of the invention, the interface for use in cash out transactions.

Detailed description of the embodiments

Point of sale device 20 Figures 1A and IB respectively provide front and rear perspective views of a transaction or point of sale device 100 in accordance with an embodiment of the invention.

In this specification relative terms such as front, rear, top, bottom, left, and right will be used to describe the locations of various features on the device 100. These terms are taken with reference to the device 100 as depicted in top perspective view Figure 1A. 25 Device 100 includes a housing 102 which, in this instance, defines an upper portion 104 and a lower portion 106 of the device 100. The upper portion 104 of the device 100 is provided 1001903398 2017213565 11 Aug 2017 10 with a touch screen 108, a plurality of card reading devices (in this instance a swipe-type card reader 110, an insert-type card reader 112, a contactless reader 114), a camera 116, a user control 118, a microphone 138, and a speaker 140.

The touch screen assembly (including a touch screen 108 defining a top face of the device 5 100 and a display positioned beneath the touch screen 108) is used to display information to a user such as transaction details, prompts for the user (or merchant) to enter information, advertising messages, etc. Touch screen 108 also allows user to input data, for example via touching a virtual button(s) (e.g. alphanumeric buttons or specific option/function buttons) provided by software, or by using any variety of ‘swiping,’ ‘stroking,’ ‘tapping,’ or any of a 10 wide variety of other motions created by moving the fingers against the touch-sensitive surface, including writing/signing on the screen in a defined location. In order to allow a user to write/sign, a stylus may be provided. Additionally, the touch screen may accept input from the use of more than one simultaneous points of touch, having corresponding commands associated with these gestures. 15 While the size of the touch screen 108 may be selected to suit the intended use of the device, a 7” touch screen may provide for a relatively small device that is still easily usable. As will be appreciated, in many instances an unobtrusive device with a relatively small footprint is desirable as the available room on store counters etc may be limited.

Swipe-type card reader 110 is, in this instance, positioned on the right hand side of the 20 upper portion 104 of the device 100. The swipe-type card reader 110 includes a card slot 120 having a leading end at the rear of the device 100 and a trailing end towards the front of the device 100. Swipe-type card reader 110 can be used to read the magnetic stripe of a transaction card, such as a credit or debit card, by swiping the card through the slot 120. Slot 120, therefore, is dimensioned such that when a card including a magnetic stripe is swiped the magnetic stripe 25 passes across a stripe sensor. To assist in a card-swiping operation, the top right comer 122 of the upper portion 104 of the device 100 is cut away to provide simple and clearly visible access to the leading end of the slot 120, and the trailing end of the slot 120 is provided with a ramp 124 which, when a card is swiped, leads the card out of the slot 120 at the end of the swiping operation. It should, however, be noted that swipe card reading can work in either swipe 30 direction, even though there is a built-in affordance to swipe from top to bottom. 1001903398 2017213565 11 Aug 2017 11

The insert-type card reader 112 of the present embodiment is located at the front of the upper housing 104 of the device 100. The insert-type card reader 112 includes an insert slot 126 for receiving part of a transaction card. In this embodiment the insert-type card reader 112 is configured to read data from a chip on a transaction card (e.g. a smart card) and (in some 5 instances) write data to said chip. Slot 126 is shaped, therefore, such that when a transaction card which includes a chip is inserted the chip is located to be read by a chip reader.

The contactless reader 114, which may, for example, be an RFID reader, is illustrated as being positioned on the top surface of the device. Although indicated in this position and by a “box” in the figures, it will be appreciated that the actual reader 114 may lie below the top 10 surface of the device 100 at any suitable position, and will generally be invisible to users. As such the device 100 will typically be marked by an indicia or similar to alert users to the fact that a contactless reader is provided and the approximate area that a card (or other device) able to be read by the contactless reader 114 should be positioned to be read.

Device 100 may also be configured to allow the user to manually enter/input card details 15 on the touch screen 108 (e.g. card number, expiry date and security codes), for example via displaying a card entry interface.

Camera 116 is positioned on the device 100 so as to be able to scan coupons, 2D bar codes, and acquire a wide variety of other types of optical information. Although shown to be positioned on the top surface of device 100, the camera 116 could of course be positioned 20 elsewhere on the device. In another embodiment, the camera 116 could be provided on the top surface of the device 100, to capture footage of a user during use of the device 100 and enable a variety of types of interaction scenarios, including acquiring the user’s facial image, allow the user to acquire images of objects, facilitate video-communications, etc. Typically the camera 116 will be positioned below a transparent window which allows light to enter the camera but 25 protects the camera components (e.g. the camera lens).

The device 100 also includes a microphone 138. Although shown positioned next to the camera 116, the microphone could of course be positioned elsewhere on the device. In addition, the device includes a speaker, allowing the potential of sound feedback, the broadcast of music, voice, etc. The device may also include a headset jack, allowing the hearing impaired to interact 30 with the device. 1001903398 2017213565 11 Aug 2017 12

User control 118 is, in this instance, a power button 118 positioned on the rear of the upper housing 104. The device may be configured such that the power button can be used to switch the device 100 on/off, to reset the device, and/or place the device 100 in a hibernation or sleep mode. 5 The lower portion 106 of the device 100 of this particular embodiment includes a front foot 128 and a rear foot 130. As can be seen, front foot 128 is smaller than rear foot 130 such that when the device 100 is placed on a level surface the top face (and the touch display 108) is tilted towards a user at a user-friendly angle. By being tilted at an angle user-entered details are also relatively hidden from (for example) a store assistant located on the opposite side of the 10 device to the customer.

Where device 100 is a wired device, necessary cables (e.g. communication and/or power cables) may extend from the rear foot 128 at cable opening/guide 132. Device 100 may, however, be configured for entirely wireless operation - in which case device 100 will include an on board power source (such as a battery) and one or more wireless communications 15 interfaces. If configured for wireless operation, device 100 may still include one or more connection ports/sockets to allow the device to be connected to a power source (to recharge the on-board power supply) and/or provide for wired communication with the device if desired.

The device of the present embodiment also includes a receipt or docket printer (housed in the rear foot 128). A printing slot 134 is provided at the rear of the device between the upper and 20 lower portions 104 and 106 by which printed receipts/dockets are output. The printing slot 134 may be provided with a serrated edge or similar (not shown) to allow easy retrieval of a printed receipt/docket. In order to allow access to a paper roll (used by the printer and housed in the rear foot 128), a bottom cover 136 of the device 100 may be removable.

Device 100 may also be provided with one or more biometric reader/sensor devices for 25 taking a biometric reading of a person using the device 100. This may be a dedicated integrated or peripheral biometric device, or devices such as the touch screen 108, camera 116 and/or microphone 138 may be operated to take biometric readings. By way of example, touch screen 108 is illustrated with a fingerprint reader portion 142. Although indicated as being visible on touch screen 108, fingerprint reader 142 would typically be invisible to users until actually being 1001903398 2017213565 11 Aug 2017 13 used, at which point software would display the relevant area of the touch screen 108 to contact in order to take a reading.

Electronic components

Figure 2 provides a high level electronic functional block diagram of various components 5 of the point of sale device 100.

The device 100 includes at least a processing unit 202, which in this case includes a general processing unit 201 and a secure/encryption processor 203. General processing unit 201 will typically be a single processing device such as a microprocessor or other computational device, for example an Intel® 206 Mhz SA - 1110 Strong-arm CPU. Encryption processor 203 10 is/includes an encryption chipset that provides for the encryption of data sent to/received from the touch screen 108. As is described in more detail below, non-secure applications provided by the device 100 (e.g. non-payment applications) will typically be controlled/performed by general processing unit 201. Secure applications (such as payment applications), however, will be controlled/performed using encryption processor 203 which is housed in a secure housing and 15 operates such that (where necessary, such as PIN entry) data is encrypted by the encryption processor 203 and only available as encrypted data at further processing/transmission steps (including processing by the general processor 201).

Device 100 also includes memory devices indicated generally at 204. Memory devices 204 include a system memory 206 (typically read only) and may also include additional volatile 20 memory 208 (e.g. random access memory including one or more DRAM modules) and/or nonvolatile memory 210 (e.g. one or more hard or solid-sate disk drives, flash memory or the like).

While the processing unit 202 and memory devices 204 are depicted as being separate units, it has become increasingly common for a single integrated circuit (IC) chip to include a processing unit as well ROM and RAM memory devices. 25 The various components will typically be mounted or otherwise connected to one or more printed circuit boards which provide a communications bus 212 for communication (i.e. data transfer) between the processing units 201 and 203, relevant memory devices 204, and other system components. The system memory 206 will typically include a basic input/output system (BIOS) (e.g. a dedicated BIOS chip) which provides the basic routine for operation of the system 1001903398 2017213565 11 Aug 2017 14 100 at start-up. This may include, for example, the identification of system devices and locating/loading of operating system software. The operating system software may be stored on the system memory 206, but will more likely be stored on non-volatile memory 210.

As discussed above, the device 100 also includes a plurality of peripheral devices, 5 indicated generally at 214. Peripheral devices include touch screen 108, swipe-type card reader 110, insert-type card reader 112, contactless reader 114, camera 116, user control 118, microphone 138, speaker 140, and printer 216. The peripheral devices are interconnected with the processing unit 202 and memory devices 204 via connection with the communications bus 212. This may be achieved by direct wiring of a device to the PCB on which the processor and 10 bus are provided, or by connection to a port/other connector provided for that purpose. For clarity, however, individual connections between specific devices and the bus 212 have not been illustrated.

Broadly speaking, the touch screen 108 will include a display located behind a touch screen surface. The touch screen 108 assembly includes a display controller 218 for controlling 15 the display of information, and an input controller 220 for detecting and processing contact made with the touch screen surface. The touch screen may use resistive, capacitive, infra-red or other technologies for detecting user interactions with the surface.

Display controller 218 and input controller 220 are in communication with the general processing unit 201 (for non-secure applications) and the encryption processor 203 (for secure 20 applications) to determine the information to be displayed and transmit user input for processing. In one embodiment the touch screen 108 (or, at least, a portion thereof) also acts as a fingerprint scanner 142. In one embodiment a dedicated fingerprint processing unit may be provided to process fingerprint data, however in other embodiments captured fingerprint data may simply be processed by the general processing unit 201 or encryption processor 203. 25 Figure 16 provides a partial exploded representation of device 100, showing the touch screen surface 1602 (behind which a display is located) connected to a secure component housing 1604 by a cable 1606. As device 100 is used to capture and transmit sensitive data (such as PIN data), securing the hardware of the device 100 to prevent tampering or other access is important. 1001903398 2017213565 11 Aug 2017 15

Secure component housing 1604 houses components of the device 100 including at least the encrypt processor 203 (and associated circuit board). Secure housing 1604 is attached to the rear of the touch screen surface 1603 by secure and tamperproof means (for example by an acrylic or cyanoacrylate adhesive). The secure housing 1604 provides a housing for the relevant 5 components and is packaged such that attempts to access the components/penetrate the housing 1604 result in damage to the housed components and/or the connector 1606 and/or prevent functioning of device 100.

The touch screen end of the cable 1606 is securely connected to the touch screen surface 1602, for example by double lamination. In the lamination process a plastic is used that is 10 hardened, making it very difficult to access the contacts of the cable 1606 at all, let alone without showing indications of tampering. By way of example, optical coatings such as sapphire or other refractories may be used for this purpose. The other end of cable 1606 is securely connected to the encrypt processor 203 (or, more particularly, the circuit board on which the encrypt processor 203 is located) inside the secure housing 1604 such that attempting to access this end of the cable 15 1606, for example by pulling the cable, will result in disconnection of the cable inside the housing 1604 and/or breakage of the cable 1606, again without exposing the cable contacts.

Communication between the components housed in secure housing 1604 and other components of the device 100 (or, where all components are securely housed, power, network and/or other connection ports) is via cable 1608. One end of cable 1608 is secured inside the 20 secure housing 1604 as per cable 1606, with the other end 1610 connectable to further components/ports/PCB’s as appropriate.

The swipe-type card reader 110, again broadly speaking, includes a magnetic stripe reader 222 for reading the data from a magnetic stripe on a swiped card, and magnetic control and decode circuit 224 for decoding data from the magnetic stripe and transmitting to the 25 processing unit 202 (or other processing unit) for processing.

The insert-type card reader 112, broadly speaking, includes a smart card/chip reader/writer 226 for reading the data from an electronic chip of a smart card (or similar) and, in some circumstances, writing data thereto. The insert-type card reader 112 also includes a smart card/chip control and encode/decode circuit 228 for encoding/decoding chip data transmitting 30 data to/receiving data from the processing unit 202 (or other processing unit). 1001903398 2017213565 11 Aug 2017 16

As will be appreciated, while separate swipe-type and insert-type card readers have been provided in the illustrated embodiment, the device 100 could instead be provided with a single “hybrid” reader capable of reading/writing both chip data and magnetic stripe data. A variety of suitable a hybrid chip/stripe readers exist, including the ZU series units available from 5 Matsushita, the ST-40 series units available from Secure-Tech, and units available from ID TECH.

The contactless reader 114 may be an RFID reader for reading an RFID tag of a user. The RFID tag may be stored in a transaction card or other device of the user. In this case reader 114 includes a reader 230 and an associated control and decode circuit 232. A variety of RFID 10 readers are, of course, available, such as those manufactured by Kronegger.

Camera 116 generally includes an image capture device 234 (such as a CCD or CMOS sensor) connected to an image processing circuit 236. During use the image capture device 234 may be operated by the processing unit 202 to capture an image of the face of a user of the device (or an eye or iris of a user) and store that image to a memory device (e.g. local non-15 volatile memory 210 provided by the system 100, or a remote memory device accessed via an interface 240). The image may be stored in a database (either provided by the system 100 or a remote system) along with details sufficient to enable the transaction to be identified (such as date and time, and the details of the transaction card used in the transaction). This may be useful for security purposes. For example, if a transaction is deemed to be fraudulent the database may 20 be interrogated in order to provide an image of the person who conducted the transaction. In certain circumstances and/or jurisdictions capturing an image of a transactor may give rise to privacy issues. In this case this feature can disabled.

In some embodiments data/images captured by camera 116 may be used for biometric identification purposes. 25 Microphone 138 allows for audio to be received and processed by the device 100. In some embodiments the device 100 may run voice recognition processes/software which process audio input to allow for allow for voice control of the device 100. Audio input may, in some circumstances, also be used for biometric identification of a user.

As discussed above, various components of the device 100 are operable to capture 30 biometric or other identification data of a user - e.g.: capture of a user’s fingerprint or signature 1001903398 2017213565 11 Aug 2017 17 by the touch screen 108; capture of an image of a user’s face, eye, retina by the camera 116; capture of a sample of a user’s voice by the microphone 138. Identification of a user from captured biometric data will typically involve processing the captured data and comparing it with a database of reference data in order to identify the user. Depending on the application in 5 question, the reference data may be stored and the processing performed at the device. More typically, the reference data will be stored at a remote location (e.g. a bank server or merchant server) and biometric data will be transmitted to that remote location for processing, with the remote location returning authentication data indicating whether the user is or is not identified.

The device 100 also includes at least one interface (indicated generally at 240) for cabled 10 connection with external computing devices. Depicted are a USB interface 242 and communications interface 244, though additional/alternative interfaces are of course possible (e.g. fire wire, eSata, serial, parallel, etc). It would, of course, also be possible to have a single interface. Communications interface 244 may, for example, be a Network Interface Card allowing for wired or wireless connection to other computing devices either directly or over a 15 network 200. If the device 100 is to be configured for wireless configuration it will also include an aerial, which may be internal or external.

As will be appreciated, a wide variety of additional peripheral devices may be used, including intelligent input/output devices having their own memory and/or processing units. By way of non-limiting example, the device 100 may provide one or more connections for 20 interfacing with integral or connectable devices such as keyboards, pointing devices (e.g. mice or touch pads), microphones, additional display units (e.g. a CRT, LCD or LED screens), additional storage devices (e.g. hard disk drives, solid state disk drives, flash memory devices), CD drives, DVD drives, Blue-Ray drives, biometric devices, etc. The connection of peripheral devices may be achieved using standard connection interfaces with standard data transfer protocols, such as 25 serial connections, parallel connections, e-Sata connections, USB connections, FireWire connections etc. Alternatively, some peripheral devices may use unique connectors and/or data transfer protocols. As will be appreciated not all of the example peripheral devices are necessary. Additionally, while some devices may be useful for system maintenance (e.g. a larger display screen and/or keyboard), these may not be necessary for “normal” operation. 30 1001903398 2017213565 11 Aug 2017 18

Network

As depicted in Figure 3, device 100 may be directly connected to a merchant system 302 (e.g. a point of sale system such as a cash register or other transaction system, or other computing device, connected via USB or Ethernet), and indirectly connected to other computer 5 systems via network 200 (which may be a local area network or a public network such as the Internet). In alternative embodiments, rather than directly connecting with a network 200, the device 100 may be connected to a network 200 only through a transaction computing system such as 302.

By way of non-limiting example, the computer systems depicted in Figure 3 include a 10 customer bank system 306 (maintained by a bank at which issues transaction cards to customers and holds customer accounts), a merchant bank system 308 (holding merchant accounts and, typically, providing device 100 to merchants), a merchant system 310 (i.e. a system maintained by a merchant); and a customer device 312 (i.e. an end-user device accessible by a customer, such as a laptop computer, desktop computer, PDA device, mobile/smart phone device, etc). As 15 will be appreciated, each system 306, 308, 310 and 312 could, in fact, each include multiple physical systems networked together and accessible over network 200. Further, while depicted as separate entities (and separate systems), in some instances the bank of the merchant and customer may be the same.

Communication with a network (and other devices connected thereto) will typically be by 20 the protocols set out in the layers of the OSI model of computer networking. For example, applications/software programs being executed by the processing unit 202 may communicate using one or more transport protocols, e.g. the Transmission Control Protocol (TCP, defined in RFC 793) or the User Datagram Protocol (UDP, defined in RFC 768).

By connecting device 100 to one or more further computing systems (such as merchant 25 bank system 308), data and instructional communications for maintaining/updating the device 100 can be carried out. In addition, connection of the device 100 allows information captured by the device (e.g. transaction records including transaction card details and time and date details, images, and any other details) to be transmitted to a remote device (such as a merchant bank system 308 and/or a merchant system 310) for storage and/or further processing. Such data 1001903398 2017213565 11 Aug 2017 19 transmission may be in real time or done via batch processing (e.g. at the end of a given trading period).

Alternative device embodiments

Figures 4, 5 and 17 depict point of sale devices 400, 500 and 1700 in accordance with 5 alternative embodiments of the invention. Point of sale devices 400, 500 and 1700 include many of the features of device 100, as indicated by the same reference numerals used in respect of device 100. Only the differences between devices 400/500/1700 and 100 will be discussed here.

The upper portion 104 of device 400 of Figure 4 is substantially the same as that of device 100 described above. Instead of having two feet, however, the base 402 of device 400 10 includes a single “tilt” foot 404 having two angled surfaces 406 and 408, meeting at a ridge 410 (perhaps most easily seen in the bottom view of Figure 4B). Often point of sale devices are used over a counter or similar with the front of the device 400 facing a customer and the rear of the device facing a shop assistant. Foot 404 allows device 400 to be positioned in two alternative stable orientations - i.e. a first or customer-facing stable orientation where the device (in use) is 15 tilted towards a customer such that the device 400 rests on surface 406 and screen 108 is at a convenient angle for use by the customer (once again, the tilted angle providing some privacy to the customer on entering details into the device 400), and a second or merchant-facing orientation in which the device is tilted about ridge 410 to rest on surface 408, placing the screen 108 at a convenient angle for use by a merchant/staff member. 20 Device 400 is also provided with an orientation or tilt sensor (not shown) which communicates with the processing unit 202 to signal whether the device 400 is in the first or second orientation. The tilt sensor functionality may be achieved in a number of ways, for example via an accelerometer, a microswitch, ball tilt sensor or other. When the device 400 is tilted such that it rests on surface 406 the processing unit 202 will control display 108 such that 25 information is displayed the right way up for this orientation (i.e. the top of the display being towards the rear of the device 400 and the bottom of the display being towards the front of the device 400). Conversely, when the device 400 is tilted such that it rests on surface 408, the processing unit 202 will control display 108 such that information is rotated 180 degrees from the orientation described above (i.e. the top of the display being towards the front of the device 30 400 and the bottom of the display being towards the rear of the device 400). This allows 1001903398 2017213565 11 Aug 2017 20 information to be easily read from (and input easily entered to) the touch screen 108 regardless of the orientation of the device 400. Additionally, the device may be configured to switch between merchant-relevant and customer-relevant screen information, depending on its orientation. 5 As with device 100, device 400 may be configured for wired or wireless communication with a cash register or other computing device. If connection is to be via wired means, cables may conveniently exit the device at the ridge 410 on one or the other sides so as to not interfere with the tilt operation. Device 400 does not include an on-board printer, however printing may easily be performed by a remote printer accessed by wired or wireless communication means. 10 Device 500 of Figure 5 is largely the same as device 100 discussed above, with the exception that device 500 is a “folio” type design, including a cover 502 (shown in Figure 5 in an open configuration). Cover 502 includes a recessed portion 504 which may be used to display advertising and/or hold a printed receipt of similar.

Device 500 is intended for portable use and as such does not include any wired 15 connections. As such device 500 will include an on-board power supply (such as a battery) and a wireless communications interface and aerial. Device 500 will typically also include one or more connection ports/sockets (not shown) to allow the device to be connected to a power source to recharge the on-board power supply and/or provide for wired communication (this may be via a purpose built dock assembly or similar) when the device is not in use. 20 Device 500 may be particularly convenient for restaurants (where patrons may wish to have their invoice presented and/or arrange for payment at their table rather than at a counter) and stores with roving staff who perform transactions on the floor rather than at a dedicated counter.

While device 500 is shown with foot 130 housing a printer, in alternative embodiments a 25 printer may be omitted, allowing the device to be a “slim-line” device for easy carrying and presentation to customers. In this instance, if the printing of a receipt or other information is necessary this may be achieved via a printer in wireless communication with the device.

Device 1700 of Figure 17 is similar to device 400 insofar as it is stable in two alternative orientations. The base 1702 of device 1700 includes a single “tilt” foot 1704 at its rear. Foot 1001903398 2017213565 11 Aug 2017 21 1704 has two surfaces 1706 and 1708 meeting at a corner/ridge 1710. The comer/ridge 1710 is provided with a radius to allow the device to easily roll/move between the first stable orientation shown in Figure 17A and the second stable orientation shown in Figure 17B.

As can be seen in Figure 17A, in the first stable orientation the device 1700 rests stably 5 on surface 1708 and a rest 1714 positioned at the front of the device 1700. In the first stable orientation the screen 108 is positioned for use by a first person (i.e. a person positioned such that the rest 1714 is at the front of the device proximate to the user and the foot 1704 is at the rear of the device distal the person).

In Figure 17B the device is shown in a second stable orientation, having been tilted about 10 the corner/ridge 1710 in the direction shown by arrow 1716. In the second orientation the device 1700 is tilted such that it rests stably on surface 1706, and the screen 108 is positioned for use/viewing by a second person (i.e. a person located opposite the first person).

Device 1700 is also provided with an orientation or tilt sensor (not shown) which communicates with the processing unit 202 to signal the orientation of the device. When the 15 device 1700 is tilted to the first orientation the processing unit 202 controls display 108 such that information is displayed the right way up for this orientation (i.e. the top of the display being towards the rear of the device 1700 and the bottom of the display being towards the front of the device 1700). Conversely, when the device 1700 is tilted to the second orientation the processing unit 202 controls display 108 such that information is rotated 180 degrees from the orientation 20 described above (i.e. the top of the display being towards the front of the device 1700 and the bottom of the display being towards the rear of the device 1700). This allows information to be easily read from (and input easily entered to) the touch screen 108 regardless of the orientation of the device 1700. As with device 400, device 1700 could be configured to display merchantrelevant information in a first orientation and customer-relevant information in a second 25 orientation.

In use, device 1700 may be positioned on a bench or counter with a merchant on one side and the customer on the opposite side. Although either the first or second orientation could be used as the “merchant” orientation (i.e. an orientation in which the screen faces the merchant), in one embodiment the first orientation depicted in Figure 17A is the merchant orientation and the 30 second orientation of Figure 17B is the customer orientation (where the screen faces the 1001903398 2017213565 11 Aug 2017 22 customer). This may be advantageous as in the second orientation the screen tilted/upright angle of the screen 108 provides some privacy to the customer on entering details such as a pin number into the device 1700.

Although device 1700 has been described as having two stable orientations, it will be 5 understood that device 1700 may, of course, be stable in additional orientations. For example, device 1700 may be placed (and be stable) on either of its sides and the orientation or tilt sensor configured to communicate with the processing unit 202 to control display 108 such that the information is displayed the right way up for the particular orientation (i.e. the information on display 108 is shown in a landscape orientation). 10 As with device 400, device 1700 may be configured for wired or wireless communication with a cash register or other computing device. If connection is to be via wired means, cables may conveniently exit device 1700 at the foot 130 on one or the other sides so as to not interfere with the tilt operation on the ridge 1704.

The foot 1704 of device 1700 may house a printer as described with respect to device 1, 15 or may house alternative device components.

Further, and as can be seen, in the embodiment of the invention shown in Figure 17 the swipe-type card reader 110 is positioned so as to swipe along the top of the device 1700 instead of the side (as per device 100 in Figure 1). Although device 1700 is shown to indicate a swipe direction beginning with the notched corner, the card reader would work with swipes in either 20 left-to-right or right-to-left directions.

As shown in Figure 17C, a front surface of the device 1700 is provided with a camera 116 and headphone jack 1712. As previously described, camera 116 enables easy scanning of barcodes, coupons, etc. If desired an additional camera could be positioned on the top surface of the device 1700, allowing the acquisition of facial images, etc. 25 Turning to Figure 17D, the rear of device 1700 includes two user controls - 118a and 118b. Controls 118a and 118b may be configured as desired, but in one embodiment control 118b is a power button (as per button 118 of Figure 1), and control 118a is a multi function contextual control - i.e. a control whose function depends on the particular context the device is in. For example, the device may be configured such that actuation of user control 118b can be 1001903398 2017213565 11 Aug 2017 23 used to wake the device 1700 from a hibernation or sleep mode, control the brightness/visibility of the display, terminate a current application, display a default screen and/or makes a screen saver disappear. Such features can be implemented by pressing and/or holding user control 118b. Device 1700 may also be configured such that when user control 118a and user control 118b are 5 simultaneously pressed and held, the device is reset.

Device functions/applications

Various embodiments of the present invention extend to applications run on an electronic device. While the applications will be described as running on a device such as device 100, 400, or 500 above, the applications could, of course, be run on/performed by alternative devices 10 provided the relevant components necessary for the input, processing, and output requirements of the application are provided.

The applications are typically embodied in computer software programs/applications. The programs include computer-readable instructions which can be executed by a processing unit 202 of the device 100 to implement the relevant aspects of the invention. 15 The device 100 may be supplied with the software pre-installed and stored on a memory of the device 100, such as non-volatile memory 210. Alternatively, the software/processing instructions may be conveyed to the device 100 by means of a data signal in a transmission channel. Examples of such transmission channels include wired or wireless network connections enabled by the communications interface 244 and various communications protocols. 20 Alternatively, the instructions may be stored on a computer readable medium such as a hard disk, floppy disk, CD, DVD, Blue-Ray disc, flash memory device and transferred to the device 100 via an appropriate interface. Once transmitted to the device 100, the software is stored on one of the memory devices 204 of the device 100, typically on the non-volatile memory 210.

Periodically software updates and/or new applications for device 100 may become 25 available. Such updates may also be transmitted to the device 100 (from, for example, merchant bank system 308) via a transmission channel or via a computer readable medium.

The software applications allow users (e.g. customers, merchants, and device providers) to interact with the device 100 via a user interface. The user interface displays information on the touch screen 108, along with software-defined buttons/controls which if touched by a user input 1001903398 2017213565 11 Aug 2017 24 data into the device 100 for processing by the processing unit 202. The software applications provided will typically have a uniform “look and feel”, and may be customisable as desired by a merchant/retailer such that all units 100 being used by a particular merchant/retailer have the same look and feel. A variety of features of the interface may be customised, for example, fonts, 5 colours, and background images/text (e.g. corporate logos, advertising, etc).

Some of the applications offered by the device 100 involve capturing data (e.g. transaction details and/or customer details) at the point of sale and making that data available to the customer or merchant. While this data may be transmitted directly to the customer or merchant (e.g. via email or direct posting to a customer/merchant system), the data will typically 10 be made available to the customer/merchant from the relevant bank system. For customers this will generally be the issuing bank of the transaction card used by the customer, and for the merchant this will typically be the merchant’s bank (who, in some cases, will also be the provider of the device 100). Typically the customer/merchant bank will maintain a web server (i.e. in the customer bank system 306 or merchant bank system 308) serving web pages by which 15 customers/merchants can access their account information and perform account actions (e.g. view transactions and transaction data, make payments, transfer money etc). The customer/merchant will have a dedicated customer/merchant account and be able to log into their account from a computing device (e.g. a customer device/system 312 or merchant system 310). Where data from device 100 is made available to a user via such a web interface, it may be sent 20 from device 100 to the relevant system either over a network 200 via communications interface 244, or via a directly connected device such as a register 302. Transmission of data from the device 100 may be in real time (i.e. as the data is generated/gathered at the device), or may be as part of a batched process (i.e. a batch of data gathered by the device 100 sent together periodically). Regardless of how the data is transmitted from the device 100 to the bank system, 25 the data will generally be encrypted for security purposes. On receipt of the data from the device, the bank system processes the data and, if applicable, makes it available to the user via their web-accessible account.

Some applications offered by the device 100 also involve a merchant maintaining their own customer database, and for data from that database to be accessible by the device 100 during 30 transactions (e.g. in order to provide customers with a tab option and rewards, and/or to store customer data as described below). In one instance the provider of device 100 or the merchant’s bank (which may be the same entity) may provide the merchant with software to create and 1001903398 2017213565 11 Aug 2017 25 administer this database themselves, allowing the merchant to create and store the database locally either directly on device 100 or on a merchant computer system accessible by the device 100 (e.g. system 310). Alternatively, the provider of device 100 may maintain the database on the merchant bank system 308, in which case the database would be accessible by the merchant 5 for viewing and administration (e.g. via a web interface as discussed above), and accessible by device 100 in order to obtain information to perform various applications. In some embodiments the merchant’s customer database may be integrated with (or access data from) a broader accounting system used by the merchant.

The customer database may store a variety of information regarding the merchant’s 10 customers, for example identification details, contact details, purchase details (dates, items, amounts etc). Whether provided locally on a merchant system or remotely via a bank, the database software will typically provide at least basic administration tools by which the merchant can, for example: create customer accounts (in some instances the software may also allow customers to create their own accounts directly via, for example, a web interface); delete 15 customer accounts; set warnings on customer accounts/flag accounts as being ineligible for services; flag customers for rewards; view/generate reports on customers and customer purchases; automatically send customer notifications and reminders, etc.

Some applications offered by the device 100 may further involve a user identifying themselves - for example in order to access the data regarding that user stored in a database. 20 User identification may be achieved in a variety of ways, for example by prompting the user (via the touch screen 108) to provide user login and/or verification details such as a password or biometric information (e.g. a signature, fingerprint scan, image of the users face/eye/retina, voice sample, etc). Alternatively, customer identification may be by presentation of a transaction (or other) card. Once captured the login and/or verification details can be compared to stored data in 25 order to identify the user and access their related data.

General information flow

Figure 15 provides a high level information flow diagram 1500 depicting the flow of information between components of device 100 during use. The applications/functions provided by device 100 can generally be classified as non-secure applications 1502 (being applications 30 involving the transfer of data that does not need specific security measures taken), and secure 1001903398 2017213565 11 Aug 2017 26 applications 1504 (being applications involving the transfer of data that does need to be secured - e.g. PIN data and suchlike).

For non-secure applications 1502, which will be the majority of applications, the general processor 201 controls the touch screen (via the display controller 218) to display information 5 and input buttons etc on the touch screen 108. User interaction with the touch screen is then relayed to the general processor 201 (via the input controller 220) for further processing and, where required, transmission to other systems (e.g. merchant system 302, merchant bank system 308, customer bank 306, or an alternative networked device 312). As can be seen, the data transfer for non-secure applications 1502 is indicated as being “non-secured” data. It will be 10 appreciated, however, that even though this data has not been processed by the dedicated encrypt processor 203 it may still be encrypted or otherwise secured by general processor 201 (for example where the data is to be transmitted over a public network 200).

In another embodiment, all inputs to the touch screen 108 are processed by the secure controller/encrypt processor 203. This allows the secure controller/encrypt processor 203 to 15 limit access to touch screen inputs (which could include sensitive information such as PINs, passwords and the like). For example, the secure controller/encrypt processor 203 may be configured to only allow applications to access sensitive touch screen input data (such as PINs and passwords) where the application has been validated by the secure controller/encrypt processor 203. Such validation may, for example, be via a secure digital signature indicating that 20 the application has been vetted and approved for sensitive information access by a governance process. This prevents unvalidated applications/user interfaces from acquiring sensitive information.

In the case of secure applications 1504 - for example payment applications which involve a user submitting a transaction card PIN or suchlike -- encrypt processor 203 controls the touch 25 screen (via the display controller 218) to display information and input buttons etc on the touch screen 108. User interaction with the touch screen is then relayed directly to the encrypt processor 203 (via the input controller 220) for further processing and, where required, transmission to other systems (e.g. merchant system 302, merchant bank system 308, customer bank 306, or an alternative networked device 312). For secure applications, transmission of data 30 may be by public network 200 or, in some instances, may be via dedicated/private connection or 1001903398 2017213565 11 Aug 2017 27 over a private network to the intended recipient of the data (which may, for example, be a secure payment side server operated by the customer or merchant bank). PIN entry application

Referring to Figure 6A, a screen shot 602 of a PIN entry user interface is shown. As will 5 be appreciated, the PIN entry application may be used whenever a customer intends to complete a transaction and the transaction card used requires a PIN (as opposed, for example, to a signature or similar). The entry of PIN data is a secure application and as such when the PIN entry application is called (e.g. as part of a payment/transaction process) it is handled by the encrypt processor 203. 10 If PIN data is to be obtained from a user, the encryption processor 203 sends virtual PIN- pad graphics to the display on the touch screen. Screenshot 602 shows a virtual PIN-pad display 604 which includes buttons/controls/keys for the numbers zero to ten, a “delete” button 606, a “clear all” button 614 and an accept/confirm button 608. In addition, a “skip pin/sign” control (not shown) may be displayed allowing a customer to verify their identity by signing instead of 15 entering a pin.

In order to enter a PIN, a user (e.g. a customer wishing to make a transaction) touches the touch screen 108 above the relevant number buttons. Contact with the screen 108 in this secure application is processed by the touch control 220 to determine the location contacted, from which the virtual button activated by the customer can be determined (e.g. by a coordinate 20 comparison of the contact location and the location at which the button is displayed). As the user presses number buttons, the entry indicators 610 in the PIN display field 612 are populated from left to right as consecutive buttons are pressed, typically with a non-descript symbol such as an asterisk so as to not publicly display the users PIN. If a user makes an error, pressing the delete button 606 will cancel the last entered number (and clear the relevant entry indicator 610). 25 Alternatively, pressing the clear all button 614 will cancel all entered numbers and clear the relevant entry indicator 610. On completion of the PIN entry, the user submits the PIN by activation of the accept/confirm button 608.

Once entered, the PIN data is sent directly to the encrypt processor 203 (which, as will be recalled, is housed in the secure housing 1604) for encryption. The encrypt processor 203 may 30 apply any suitable encryption algorithm, such as 3DES. Once the PIN data is encrypted, the 1001903398 2017213565 11 Aug 2017 28 encrypted data is transmitted to the relevant secure payment system for PIN verification - the payment system typically being provided by the issuer of the transaction card (e.g. the customer bank 306). As noted above, this transmission may be via public network 200 or a private connection between device 100 and the PIN verification server. The encrypted PIN (and any 5 associated data) is processed at the secure payment system and verification data sent back to device 100 - the verification data either approving the PIN (at which point the transaction proceeds) or not approving the PIN (at which point the transaction may be cancelled, a request to re-enter the PIN provided, or other error condition processed). The verification data need not involve retransmission of the PIN (encrypted or otherwise). 10 As will be appreciated, at all processing/transmission stages outside the security housing 1604, the components of the device 100 (including general processor 201) deal only with encrypted PIN data and cannot access unencrypted PIN data.

Figure 6B provides an example of user interface 616 which may be displayed when the verification is not successful and the PIN is not accepted. In this case interface 616 allows the 15 user to cancel the transaction 618, skip PIN entry and instead verify the transaction using a signature 620, use another payment card 622, or re-enter the PIN 624. The user may be provided with a limited number of attempts to enter the PIN. The user may also select to return to the home screen 626 to select additional options.

In addition (or by way of alternative) to displaying a visual indication that numbers have 20 been entered (through the PIN display field 612), device 100 may also emit an audible sound when each number is entered. A different audible sound may be entered on deletion of a number, and activation of the “accept” button so as to audibly distinguish these actions.

As a software generated keypad, keypad 604 may of course be positioned anywhere on screen 108, and the individual keys of the keypad may be displayed in any fashion desired (for 25 example with or without letters corresponding to the keys). This aspect of displaying the keypad in a randomly-generated location can be used to make it difficult for fraudulent PIN number acquisition through examining the fingerprints of the user on the touch screen glass, after the PIN number has been entered. Further, and to enhance security, the individual keys of the key pad 604 may be rearranged so as to not be in numerical order. Such a rearrangement may be a 30 random rearrangement selected on successive PIN entries, or the cycling through of predefined 1001903398 2017213565 11 Aug 2017 29 key arrangements. Rearranging the keys enhances security as an onlooker attempting to determine a user’s PIN during entry cannot rely on the physical location pressed by the user to determine a corresponding number. I.e. while the number 9 may be in the bottom right corner on one PIN entry, it may appear in the centre of the keypad 604 in another PIN entry. 5 Customer transaction features

Another application offered by device 100 is an application offering a customer the option of having a printed receipt or an electronic receipt.

Figure 7A provides a screen shot of an example user interface 700 for this application. As can be seen the display 108 displays the question 702 to the customer (“How would you like 10 your receipt”) and provides two response options: “E-Receipt” 704 or “Printed” 706. An interface such as 700 will usually be shown on completion of a transaction (i.e. after the user has tendered their transaction card and the payment details have been processed/accepted), though could also be provided to the user prior to completion of the transaction.

If the customer selects the “printed option” by contacting the screen 108 above the button 15 706, the processing unit 202 will send the receipt data relevant to the transaction in question to a printer (which may be on board printer 216 or a printer accessed via a wired or wireless communication channel) for printing.

Alternatively, if the customer selects the “E-Receipt” option the processing unit 202 will generate data representative of an electronic receipt and transmit that data to a computing device 20 for later access by the customer. On successful generation and transmission of an electronic receipt (where transmission occurs in real time) the device 100 may display a clear “Receipt sent” message to the customer on the screen 108, notifying the customer that the e-receipt has been successfully generated and transmitted. Alternatively, if the device 100 is configured to transmit electronic receipts as a batch process, device 100 may notify the customer (via screen 25 108) that the receipt has generated and will eventually be available for review (e.g. at the close of business, by the next business day, or at the next scheduled batch process).

In another embodiment, an electronic copy of the receipt (or e-receipt) may be shown on the display 108. Figure 18 shows an example of interface 1800 in which e-receipt 1802 is shown on display 108. In this instance, the customer has authorised the transaction using a signature, 1001903398 2017213565 11 Aug 2017 30 but interface 1800 may be shown following PIN entry as described above. Options to print or email the e-receipt may be displayed on interface 1800 (not shown). A progress indicator 1804 may be used to show the device 100 is printing or emailing the receipt. In this instance, progress indicator 1804 is depicted as ‘Processing Transaction’ and this 5 may subsequently change to words or symbols representing that the transaction is approved and completed (e.g. a ‘tick’ symbol).

Interface 1800 also shows an example of a ‘card inserted’ prompt 1806 and a ‘remove card’ reminder 1808. In this instance, the ‘card inserted’ prompt 1806 appears as a boarder around interface 1800 on the display 108. The border may be shaded, coloured or patterned. 10 ‘Remove card’ reminder 1808 may appear at the bottom of display 108 in proximity to insert-type card reader 112. When the customer’s card is removed from device 100 the ‘removed card’ reminder 1808 will no longer be shown on the display 108. The ‘remove card’ reminder 1808 may also be shown to move towards the bottom edge of the display 108 as the customer’s card is pulled out from insert-card reader 112. ‘Card inserted’ prompt 1806 and/or ‘remove card’ 15 reminder 1808 may also be used in relation to other user-interfaces on device 100 in instances where a customer’s card has been placed in insert-type card reader 112.

In one embodiment the processor sends the electronic receipt data (along with the transaction details) to the customer’s bank system 306. The customer bank system 306 then processes the transaction and receipt data and makes the e-receipt available to the customer via 20 the customer’s web account. Figure 7B shows an example web interface 708 accessed from a laptop computer 710 (i.e. one type of customer computing device 312). As can be seen, the webpage 708 provides the user with a list of their electronic receipts for a particular transaction account 712, along with the associated transaction data (e.g. date of transaction 714, time of transaction 716, merchant details 718, amount 720, and a running balance of the transaction 25 account 722. Through interface 708 a user can select to view a given e-receipt (via selection of the relevant button 724). If a receipt is selected the electronic receipt 726 is then displayed to the user as shown in Figure 7C.

Alternatively (or, if desired, in addition), and depending on the type of transaction card/device being used, the processing unit 202 may transmit the electronic receipt data to the 30 users card/device (e.g. via the RFID reader/writer 230, or chip reader/writer 226) for the user to 1001903398 2017213565 11 Aug 2017 31 access at a later date (e.g. by uploading to a personal computer and viewing with appropriate software run by that computer).

Further alternatively the device 100 may be configured to provide the customer with the option of having the receipt sent directly to them via email. In this case the device 100 may 5 prompt the user to enter in the desired email address, or (where the user details are stored on a customer or other database) to identify him or herself (allowing the relevant address to be retrieved from the database).

An additional button (e.g. “both” or “E-Receipt & Printed”) may of course be provided by interface 700 to give the customer the option of having both a printed receipt and an e-receipt. 10 As will be appreciated, where a customer elects to have an electronic rather than printed receipt environmental advantages are achieved. Also, by having an electronic receipt the customer’s records may be more easily maintained, organised/sorted, archived etc when compared with traditional paper receipts.

Merchants may also take advantage of the electronic receipt option for merchant copies 15 of receipts. This may be a system setting by which the merchant can elect to have electronic rather than printed copies of their own merchant receipts generated (rather than requiring the merchant to elect a printed or electronic merchant receipt on a case-by-case basis). As with the customer receipt application, if a merchant elects to have some or all of their receipts electronically generated these may be transmitted by the device 100 (in real time or a batch 20 process) to a computing system accessible by the merchant. Merchant electronic receipts may be transmitted, for example, to the merchant bank system holding the merchant’s account for access by the merchant via a secure web page as discussed above. Alternatively (or in addition) device 100 may be configured to transmit the electronic merchant receipts to a database maintained by the merchant itself and stored on the merchant system 310 for direct access by the merchant. 25 Turning to Figure 8, device 100 may also allow the customer to categorise or tag a purchase at the point of sale. Figure 8 provides a screen shot of an example user interface 800 by which a purchase may be tagged by a customer. In the specific example depicted in Figure 8A, interface 800 allows the customer to tag a payment as one (or more) of a groceries purchase 802, an auto related purchase 804, a clothing related purchase 806, a hobbies related purchase 808, or 30 a household related purchase 810. Alternatively, the customer may not tag the purchase by 1001903398 2017213565 11 Aug 2017 32 activation of the skip button 812. As will be appreciated, additional and/or alternative categories than those illustrated are possible. By way of one example, a “tax-deductible” tag or similar may also or alternatively be provided, by which customers can categorise a transaction as being one that is tax-deductible (assisting the customer in collating all tax-deductible records). Further, if 5 device 100 is being used by a merchant with only one type of services/categories, device 100 may be configured to automatically tag purchases as being in the relevant category. For example, an automotive shop may automatically tag customer purchases as being auto related spending.

Where a customer elects to tag a purchase (by touching or otherwise contacting one of the category controls/buttons) the relevant category information is written to/associated with the 10 transaction record for transmission (again, either directly to the customer and/or to a customer bank system 306 where the transaction details are made available to the customer). This category information can subsequently be used to provide useful information to the customer regarding their purchase trends/habits.

Figure 8B shows one example of an interface 820 (in this instance a web interface 15 provided, for example, by the customer’s bank system 306) by which a customer can view information regarding their purchases. As can be seen, interface 820 is similar to interface 708 with the exception that interface 820 displays three spending graphs to the customer: a monthly spending graph 822 (shown in greater detail in Figure 8C); a weekly spending graph 824; and a daily spending graph 826. In this particular instance each spending graph 822, 824, and 826 is a 20 wheel-shaped graph (effectively a pie-chart) showing the proportion of transactions made in each category over the given time period. In each graph, distinguishable graph segments are provided representing the different categories of spending - in this case the segments being distinguishable by being displayed in different colours and with different indicia. The indicia for a particular category matches the indicia for that category displayed by the device 100 (see 25 Figure 8A) when the customer elects to tag their purchase. Alternative visual representations showing the proportion of each category with respect to the whole are, of course, possible.

By clicking on one of the spending graphs 822, 824 or 826 the customer may further analyse their spending habits/trends. For example, if the customer clicks on the monthly spending graph 822 of interface 820, interface 840 of Figure 8C may be launched. In this figure a 30 larger version 828 of the monthly spending graph 822 is displayed, along with the totals 842 of the transactions made in each category over the time period. In this instance the customer can 1001903398 2017213565 11 Aug 2017 33 clearly see that their major expenses over the month are groceries and household expenses, and over the month they have spent $144.60 on household expenses, $120.30 on groceries, $90.45 on clothing, $25.35 on auto, and $15.05 on household. The web interface may also allow the customer to select arbitrary date-ranges to view, rather than being limited to month/day/week 5 periods.

Where a customer has multiple transaction cards they may be provided with the option of aggregating all purchases across all cards (to gain a more complete picture of their spending habits/trends) or viewing the purchase made on each transaction card separately.

If a customer wishes to further analyse their transactions, this may be done (for example) 10 by clicking on a particular transaction category - either in the spending graph 822 or the totals display 842. For example, by clicking on a particular category (in this instance the groceries category) interface 860 as shown in Figure 8D may be launched/navigated to. Interface 860 displays a merchant graph 862 providing a break down of a particular category of transactions (in this instance groceries) by merchant, and illustrating the proportion of the total transaction 15 value for that category (and across the selected time period) that has been made at particular merchants. Interface 860 also includes a merchant totals display 864 reflecting the information shown in merchant graph 862 but with actual values. More specifically, interface 860 shows that the customer’s grocery transactions over the relevant period have been made at six different merchants - graph 862 visually depicting the proportional spending between those merchants 20 and totals display 864 showing the actual value spent at each merchant. In some embodiments the customer may elect to (or the software may be configured to automatically) only distinguish between merchants with whom more than a threshold amount has been spent, with merchants at whom less than the threshold has been spent being grouped together in an “other” category. In this case the customer would be provided with the option of drilling down into the “other” 25 category to determine more detailed information.

Tab application

In some instances merchants may offer customers a “tab” option - i.e. the option of keeping a tab with a merchant by making purchases but deferring actual payment to a later date.

As will be appreciated, the tab application may be particularly useful for smaller “local” 30 shops (e.g. comer stores etc) where a merchant has regular return customers making multiple 1001903398 2017213565 11 Aug 2017 34 small purchases. In this case, and depending on the circumstances, a merchant may only choose to offer a tab option to regular customers and for relatively cheap purchases. The merchant may maintain a database of their customers (as discussed above), and in particular keep a record of which customers the merchant is happy to provide the tab service to (e.g. by population of a 5 “tab” field in the customer database).

Alternatively, in some situations the merchant may make the tab option accessible to any customer. This may, for example, be the case in bars/pubs and the like where a tab may be desirable even though the customer is not known/regular.

Figure 9 provides a screen shot of an example user interface 900 for a tab application 10 provided by device 100. User interface 900 will typically be displayed by screen 108 after a merchant has “rung up” a purchase and the customer has been identified (for example as per the identification process discussed above) as someone to whom the tab option is to be offered. Screen 900 would be displayed to a customer who does not already have a tab open. Alternatively, the merchant may not require the customer to identify themselves at all, but may 15 simply allow a customer to open a tab. If this option is selected a temporary customer account may be created/provided for the customer to identify the customer (e.g. by a first name or numeric identifier) and keep track of the customer’s tab.

As can be seen, once the purchase details have been entered and the customer has been identified, screen 108 displays the total amount of the purchase 902 (in this instance $3.20) and 20 provides the customer with the option to accept the purchase 904, decline the purchase 906, or open a tab 908.

If the user accepts the purchase by selecting button 904, the transaction is processed as normal - i.e. the customer will present their transaction card (if not already presented) and make payment accordingly. 25 If the user declines the purchase by selecting button 906, the transaction is cancelled.

If the user elects to open a tab by selecting button 908, device 100 opens a tab for the user. If the user is already in the merchant’s customer database, this may simply involve checking that the customer in question is eligible for the tab function and, if so, flagging a “tab open” field and writing the purchase amount to the relevant database field for that customer. The 1001903398 2017213565 11 Aug 2017 35 device 100 may also provide the customer with the option of printing details of their tab purchase, or electronically transmitting these details as per the electronic receipt discussed above.

If the identified customer already has an open tab, display 108 will typically show the 5 running total of the customers’ tab (obtained from the relevant database field) along with the current purchase amount. Instead of displaying an option by which the customer can open a new tab 908, display 108 will provide the option of adding the purchase to the customer’s existing tab (providing doing so would not extend the tab beyond the set limit), paying off part of the tab, or closing the tab by paying the balance of the tab. Once again, the customer may be provided with 10 the option of printing details of the open tab (i.e. all purchases accumulated on the tab).

In conjunction with the tab application, the merchant’s customer database may provide for various tab-relevant functions. These may include, for example, the generation of reports on customers’ tabs (e.g. total amount outstanding across all customers, a report on customers with more than a predefined amount owing, a report on customers with tabs extending beyond a 15 particular date, etc), an automated reminder system (to automatically send reminders to customers with tabs above a particular value or older than a particular number of days), and suchlike. The database may also allow merchants to set tab limits - either on a universal or customer-by-customer basis.

Reward application 20 Device 100 may also provide a reward application by which a merchant can reward certain customers in certain situations. For example, where a merchant has regular dealings with a customer, or over time a particular customer spends a considerable amount at the merchant, the merchant may wish to reward the customer.

In order to track this information, device 100 transmits customer transaction details to the 25 merchant’s customer database as described above. This data typically includes transaction records of the customer including (potentially) date, customer identification data, item(s)/service(s) purchased, purchase amount. From this data the merchant can generate reports regarding customer purchases - for example showing regular customers and customers who have spent over a threshold amount of money with the merchant over a defined time period. 1001903398 2017213565 11 Aug 2017 36

Where a merchant wishes to reward a customer, an appropriate entry/flag in the customer database may be set indicating that a reward is to be given, and a database field defining the reward populated. A merchant may manually review customer reports and select which customers to reward, and the specific reward to be given, on a case-by-case basis. Alternatively, 5 the merchant may be able to put rules in place which automatically flag customers for rewards on meeting predefined reward criteria. By way of non-limiting example, such criteria may include one or more of the customer: making more then a certain number of purchases in a given time period; spending more than a certain amount in a given time period; electing to make a donation (as discussed below); electing to advertise their purchase on their social networking site 10 (as discussed below). As a further example, the merchant may simply run a random reward program, the database configured to randomly ascribe a reward to a customer (e.g. the merchant may decide to randomly reward 1 in every 100 customers).

On flagging a customer for a reward, the merchant may also select the type of reward. This may be a free product/service offered by the merchant (or an affiliate/associate of the 15 merchant), a discount on a customer purchase or such like. The precise type of reward may, in turn, depend on the criteria satisfied. For example, a cafe owner merchant may reward a customer who spends $50 in their cafe in one week with a free coffee, and a customer who spends $150 in their cafe in one week with a free meal.

Figure 10 provides a screenshot 1000 of one example of a reward. In this instance the 20 customer has satisfied the criteria for a free coffee, and is advised of this via screen 108. If the customer orders a coffee on their next visit to the merchant, at the time the transaction is to be made device 100 will access the customer database, determine that the customer has a free coffee reward, and not include the amount for the coffee as part of the transaction.

Donation application 25 A further application offered by device 100 may be a donation application by which customers can choose to make a donation to a particular organisation. This may encourage donations which (typically) are not encouraged by transaction card payment systems.

On making a transaction, device 100 may display a donation interface such as interface 1100 shown in Figure 11. This interface clearly indicates that a donation is being sought, and 30 provides the customer with a number of organisations to which a donation may be made (in this 1001903398 2017213565 11 Aug 2017 37 instance a local high-school 1102 and an aid organisation 1104). An option for continuing without making a donation 1106 is also provided.

The suggested donation amount 1108 is also displayed (in this instance $0.80). The suggested donation amount 1108 may be automatically calculated based on the purchase amount, 5 e.g. as a certain percentage of the purchase amount, or an amount that rounds up the total transaction value - i.e. purchase + donation - to the nearest whole dollar, $5, $10 etc. Alternatively, the customer may enter the desired donation amount (and/or amend the suggested donation amount) using touch display 108. Device 100 may also be configured such that interface 1100 also displays the purchase amount and total transaction value so the customer can 10 clearly see the value of the goods/services they are purchasing and, with the suggested/entered donation, what the total transaction value would be.

The device 100 may be configured by the merchant to list the relevant organisations to which donations can be made. These may be local organisations (such as schools, hospitals, sporting teams, community service organisations etc) or broader organisations (e.g. domestic or 15 foreign aid organisations, disaster appeals etc) which the merchant wishes to support. The merchant may also, of course, select their own establishment as an organisation to which a donation may be made. In this case the donation is effectively a tip/gratuity, and the interface 1100 will preferably make this clear to the customer.

By way of variation, certain merchants may support certain organisations regardless of 20 whether a customer makes a donation or not. For example, a merchant may have a policy that a certain percentage (e.g. 5%) of all purchases made will be donated to a particular organisation. In this instance display 108 may be configured to clearly display to the customer that of their total purchase amount the merchant will be donating a certain (displayed) value to the selected organisation. This display may allow customers to supplement the merchant’s own donation with 25 a donation of their own.

Where a donation is made (either by the customer or automatically by the merchant) a printed receipt (if provided) may also show the amount of the donation, whether the donation was made by the customer or the merchant, and the organisation to which the donation was made. 30 2017213565 11 Aug 2017 1001903398 38

Transaction sharing

In some embodiments a further application provided by device 100 may be the ability for customers to share/advertise purchases made with friends. Figure 12 depicts an interface 1200 for display on screen 108 for this purpose. 5 On purchasing a particular item a customer may wish to share this purchase on a social networking application (e.g. Facebook, Twitter etc). To facilitate this, on completing a transaction device 100 provides the customer with the option of posting their purchase to one or more social networking services/sites - in this instance Digg 1202, Twitter 1204, StumbleUpon 1206, Facebook 1208, and/or Google 1210. The customer may, of course, elect to skip this step 10 1212.

If a customer elects to share/advertise their purchase by activating one of the buttons/controls 1202 to 1210, device 100 may ask the user to enter the relevant account details for that service (to enable the posting). In this case the customer may also be asked if he/she wishes to store their preferred social networking site and details in the customer database. 15 Alternatively, if the relevant customer details are already stored in the customer database the customer need not be prompted to provide these details again.

Once the required details are obtained (either by being entered by the customer or being retrieved from the database), device 100 can transmit details of the purchase to the relevant service. These may include, for example, the particular item/service purchased and the details of 20 the merchant the item/service was purchased from (e.g. the name and/or location of the merchant, contact details of the merchant, and/or (if applicable) a link to the merchant’s website or own social-networking service page).

In some embodiments the merchant may offer an incentive (e.g. a customer reward as discussed above) to customers to advertise their purchase on a social networking tool. For 25 example, the merchant may offer a discount on the current or a future transaction, a free product, etc if the customer shares/advertises the transaction. 1001903398 2017213565 11 Aug 2017 39

Bill splitting A further function offered by device 100 in some embodiments may be the ability for groups of customers to divide payment between multiple people. This may be of particular use, for example, in a restaurant/cafe environment where typically items are tracked with reference to 5 a table as a whole, rather than with reference to the individual customers at that table.

Figures 13A to 13F provide depictions of example interfaces by which customers may elect to split a bill. A bill splitting interface would typically be launched by a customer (or merchant) selecting an option indicating that the bill is to be split.

Figure 13A shows an interface 1300 which provides a customer a variety of ways to 10 divide a single bill: an easy split option 1302, a percentage split option 1304, an item split option 1306, and a lottery split option 1308. For each of these options the device 100 will divide the original bill according to the option selected and provide each person/group with their own bill (covering only the relevant proportion/items of the whole bill) for payment and to take advantage of other services that may be offered by device 100, such as making a donation, advertising their 15 purchase, having a printed and/or electronic receipt.

The easy split option 1302 allows customers to simply indicate the number of people/groups that the bill is to be split between. For example, if the easy split option is entered and four people/groups are selected, each person/group will be apportioned 25% of the whole bill. 20 The percentage split option 1304 is similar to the easy split option 1302 except that it allows customers to choose the precise percentage of the total they wish to pay for. This may be useful, for example, where there are multiple parties of different sizes at the same table. For example, a table of 4 people may include two individuals and one couple in which case (and presuming an even split) the couple would cover 50% of the bill in a single transaction, and each 25 of the individuals would cover 25% of the bill.

The item split option 1304 allows customers to select the specific items from the transaction which they wish to pay for.

If the lottery split option is selected, the number of different individuals/groups paying for the goods/services is entered, and device 100 randomly assigns each group with a percentage 1001903398 2017213565 11 Aug 2017 40 of the total invoice. This option may be selected, for example, where the parties cannot decide who is to pay the bill.

If a single customer wishes to divide payment of a bill between several transaction cards and/or a transaction card(s) and cash payment, the split bill interface may also be used for this 5 purpose.

Further examples by which a bill may be split between customers are shown in Figures 13B, 13C, 13D, 13E, and 13F which provide examples of interfaces 1310 and 1312 for touch display 108.

Interface 1310, as shown in Figure 13B, depicts a further example of a bill splitting 10 interface in which a graph 1316 is displayed. In this particular instance, graph 1316 is a wheelshaped graph (i.e. pie-chart) showing a transaction apportioned between three people/groups. The graph 1316 as indicated has the transaction split as evenly as possible between the three people/groups - each person/group being apportioned around 33% of the whole bill. The contribution of each person/group is represented as a section 1318 of graph 1316 and each 15 person/group is identified with a reference number 1320. The total purchase amount 1322 and the amounts apportioned to each person/group 1324 are displayed. A user may select a *+’ icon 1326 to increase the number of people/groups contributing to the bill, or select a icon 1328 to reduce the number of people/groups contributing to the bill. A user can also select one or more sections which require payment 1318. Sections 1318 20 which have been selected by the user may be visually distinguished from those which have not been selected. This highlights the portion of the bill which will be included in the current transaction.

As previously described, there may be instances where one person in a group may wish to cover a greater proportion of the bill in a single transaction. Figure 13C provides an example of 25 interface 1310 which shows graph 1316 and a transaction apportioned between three people/groups. In this particular instance (and presuming an even split), one person (or a couple) would cover two thirds of the bill in a single transaction, and another individual would cover the remaining third of the bill. A user may select the number of sections 1318 of graph 1316 to be included in a single transaction. Interface 1310 may depict the total amount to be paid in a single 30 transaction 1334 as part of graph 1316 and/or in the confirmation button 1330. 1001903398 2017213565 11 Aug 2017 41

Figure 13D provides an example of interface 1310 which shows an alternative means to adjust the proportion of the bill to be covered in a single transaction. In this particular instance, a transaction is apportioned between two people/groups. Rather than an even split of 50% for each person/group, one person/group wishes to pay for a greater portion of the total purchase amount 5 1322. After selecting a section 1318 of the graph 1316, a user can move a portion adjustment control 1332 by placing a finger on the display 108 to make contact with the control 1332 and dragging it to a location on the display 108. The control 1332 may be moved along the permitter of the graph 1316 between a minimum payment amount and a maximum payment amount. The proportion of the total purchase amount 1322 allocated to a section 1318 corresponds to the 10 degree of movement of the icon 1332. The amounts shown to be apportioned to each person/group 1324 and in the confirmation button 1330 may be shown to increase or decrease in accordance with the movement of the icon 1332.

It is understood that a user may adjust the proportion to be paid in a single transaction by selecting or de-selecting sections 1318 of the graph 1316 and/or by moving the icon 1332 to 15 change the proportion of a particular section 1318.

Following any adjustment to the bill portions, a user may proceed with a payment by a user contact on the touch display 108 in the confirmation button 1330.

Figure 13E shows an example of interface 1312 by which a user can proceed with a cash payment 1336 or card payment 1338 for a particular person/group. In this instance, the first 20 person/group from a group of 5, as indicated by the reference number 1340, is proceeding with the payment of the apportioned amount 1342.

As part of the transaction/payment process for a split bill, the tipping function interface 2000, as shown in Figure 20A, may be displayed. This may encourage individual customers in a group of customers to provide a tip in addition to their individual payment of the total purchase 25 amount. The tipping function interface 2000 may include reference number 1340, as shown in Figure 13E, to indicate which person/group from the split bill is proceeding with the transaction.

After a portion of a split bill has been processed, the device 100 may return to interface 1310 to proceed with the remaining transactions. Figure 13F shows an example of interface 1310 where the graph 1316 depicts the remaining transactions. The next section 1318 to proceed with 30 a transaction may be highlighted. Sections corresponding to completed transactions 1344 may be 1001903398 2017213565 11 Aug 2017 42 distinguished (e.g. by shading and/or patterning). A user may not be able to select sections corresponding to completed transactions 1344. Similarly, a user may be limited to moving the ‘bill adjuster’ icon 1332 only in relation to sections which require payment 1318. In this instance, interface 1310 displays the total purchase amount 1322 and the total remaining amount 5 1346.

Tipping application A further application offered by device 100 may be a tipping application by which users can choose to add a tip to a particular transaction. This may encourage tips prior to the payment being processed, which (typically) is not made available by transaction card payment systems. 10 On making a transaction, device 100 may display a tipping interface such as interface 1900 shown in Figure 19A. This interface indicates that a tip may be paid. Interface 1900 provides the user with an option of selecting a tip amount using a slider 1902 (as shown in Figure 19A) or a manual option 1904 (as shown in Figure 19B) for inputting the desired tip amount on the touch display 108. 15 In the tip slider option shown in Figure 19A, a user can move a slider 1906 by placing a finger on the display 108 to make contact with the slider 1906 and dragging the slider 1906 to a location on the display 108 1906. The slider 1906 may be moved between a minimum tip amount and a maximum tip amount. The tip amounts 1908 may be represented as percentages of the purchase amount as shown (e.g. 2%, 5%, 10% etc) or alternatively tips may be indicated as 20 fixed amounts (e.g. $1, $2, $5 etc).

Device 100 is also be configured such that interface 1900 displays the purchase amount 1910, the value of the tip amount currently selected 1912, and the total transaction value 1914 being the sum of the purchase amount and the currently selected tip. The customer can clearly see the value of the goods/services they are purchasing and, with the entered tip amount 1908, 25 what the total transaction value 1914 would be. Where a tip is made, a printed receipt (if provided) may also show the value of the tip amount 1912. A suggested tip amount 1912 may also be displayed. The suggested tip amount 1912 may be automatically calculated based on the purchase amount, e.g. as a certain percentage of the purchase amount. 1001903398 2017213565 11 Aug 2017 43

Once the user is happy with the selected tip (which may, of course, be 0% or $0) they can activate a confirmation button 1916 on the display 108 to proceed with the transaction. Alternatively, the user may activate a return control 1918 to replace interface 1900 with a previously displayed interface. 5 Figure 19B shows an example of interface 1900 depicting manual input of the value of the tip amount 1912. The user interacts with the screen in a similar manner as the number input described in relation to PIN entry in Figure 6. Interface 1900 may include an option button 1919 which the user can touch to choose between entering the value of the tip amount 1912 or the total amount 1914 they wish to pay (i.e. the purchase amount plus the tip). In some instances, the user 10 may choose to round up the total amount 1914 to a particular sum. Therefore, total amount entered by the user will represent the purchase value 1910 and the value of the tip amount 1912.

Refund application

In some embodiments a further or alternative application provided by device 100 is the ability for merchants to provide a refund to customers. By way of example, Figures 20A and 20B 15 provide examples of interfaces 2000 and 2002 for touch display 108 by which a merchant can provide a refund to customers.

Upon selecting the refund transaction application and receiving a customer’s card details on device 100, the refund amount may be entered on the touch display 108 using a number input interface as previously described. 20 As shown in Figure 20A, interface 2000 may be displayed to allow the merchant or customer to select one or more currencies 2006 in which the refund amount may be provided. Interface 2000 may be configured to display the original refund value 2008, the exchange rate for a selected currency 2010 and the converted refund amount 2012.

As shown in Figure 20B, interface 2002 may be displayed to allow the merchant or 25 customer to select which of the customer’s accounts 2014 the refund amount may be added. A merchant or manager may enter an authorisation code on the display 108, in a similar manner as the number input described in relation to PIN entry in Figure 6A, to permit the transfer of the refund amount. An option may also be provided to cancel the refund (not shown). 1001903398 2017213565 11 Aug 2017 44

Cash out application

In some embodiments a further or alternative application provided by device 100 may be the ability for customers to withdraw an amount of cash. By way of example, Figures 21A and 21B provide examples of interfaces 2100 and 2108 for touch display 108 by a customer may 5 select a cash out amount.

The cash out amount may be entered on display 108 using interface 2100 as shown in Figure 21 A. In this instance, interface 2100 shows that a cash out transaction being made in addition to a purchase and a tip. The cash out amount 2102, purchase amount 2104 and a tip amount 2106 are shown. It is possible, however, that a customer may request a cash out 10 transaction independently of a payment for goods/services.

As described above, the merchant or customer may select one of the customer’s accounts from which the cash amount may be withdrawn.

Figure 2IB, shows an example of an interface 2108 which provides additional options for a cash out transaction. A user may select to return to the home screen 2110, cancel the entire 15 payment 2112 (if the cash out transaction is in addition to a purchase), remove the cash out transaction 2114 (if part of a purchase) or enter another cash out amount if a cash out limit is exceeded 2116.

Where a cash out is made, a printed receipt (if provided) may also show the amount of the cash out. A printed receipt or e-receipt can be provided as described above in relation to 20 Figures 7A and 18.

Data gathering and analysis

In some embodiments of the invention, device 100 may also provide a useful and simple tool by which merchants can gather data regarding their customers at the point of sale.

By way of example, when making a transaction device 100 may be configured to display 25 one or more questions to a customer for the purposes of gathering statistical data regarding the merchant’s customer base. A wide variety of questions are, of course possible, including (though not limited to) questions as to a customer’s: age; age group; gender; income; income bracket; suburb/city of relevance etc. Such questions may be automatically displayed to a customer 1001903398 2017213565 11 Aug 2017 45 (typically with the option for the customer to skip or ignore the question), or the customer may be provided with a prompt asking if they are happy to answer one or more questions.

In either case, by providing simple questions which the customer can easily answer during a transaction (i.e. at the point of sale) the customer may be more inclined to provide such 5 information than may be the case if being asked a survey or similar. In some embodiments the merchant may offer customers an incentive (such as a reward described above) for providing data/answering questions.

If a customer does provide data by answering one or more questions, this data may be transmitted to and stored in the merchant’s customer database as described above. The merchant 10 can then view/generate reports on this data, for example by logging into their web account provided by the merchant banking system 308 (where the customer database is maintained/accessed in this manner).

By way of non-limiting example, Figures 14A, 14B and 14C provide examples of interfaces 1402, 1404, and 1406 (in this instance a web interfaces provided, for example, by the 15 merchants bank system 308) by which a merchant can view statistical data regarding their customer base.

Figure 14A shows one example of an interface 1402 by which the customer data of the merchant is processed to display (by way of line graph 1408) the average age of the merchant’s customers over a given time period, with the vertical axis of graph 1408 indicating the 20 customer’s age and the horizontal axis time (e.g. days, weeks, months, years). Using time controls 1410 the merchant can change the time period from which the data is selected/processed, in this case the options being day, week, month, year. Time and date entry fields could of course also be provided to allow the merchant to select a specific time/date range for analysis. 25 Figure 14B shows one example of an interface 1402 by which the customer data of the merchant is processed to display gender data of the merchant’s customers over a given time period. In this instance, over a day the merchant had 420 customers in total, 256 being female and 164 being male. Of course if not all customers agreed to provide data there could also be an “unspecified” component representing the customers who did not enter their gender. Time 30 controls 1410 for changing the time period being analysed are also provided. 2017213565 11 Aug 2017 1001903398 46

Figure 14C shows one example of an interface 1406 by which the customer data of the merchant is processed to display the various home locations of their customers for a given time period. In this case the display is via a map representation 1412 in which city suburbs are marked and each suburb has a percentage value showing how what percentage of customers came from 5 that suburb over the given time period. Map controls are also allowing a merchant to zoom in and out of the map (controls 1414) and pan the map (control 1416) provided. This information could, of course, be displayed by way of a suburb/location listing and include absolute values rather than percentages. Time controls 1410 for changing the time period being analysed are also provided. 10 In some embodiments, device 100 itself is configured to display interfaces similar to 1402, 1404, and 1406 (or, at least, interfaces showing the same type of information) to the merchant. Figure 14D shows one example of such an interface 1418, in this case providing a geographical breakdown 1420 of the merchant’s customers over a particular day. Interface 1418 also provides forward and back navigation buttons 1422 and 1424 to allow the merchant to 15 navigate between alternative displays (e.g. displays showing the age and/or gender break downs of their customers).

As will be appreciated, the above data break-downs (gender, geography, and age) are by way of example only, and a wide variety of other statistical analyses may be performed/displayed depending on the customer data captured/available and the needs of the 20 merchant. By providing these services the merchant can obtain relevant insights regarding their customer base and use those insights to make business decisions (for example on their stocked products/offered services, where marketing should be directed, whether additional outlets may be viable etc).

It will be understood that the invention disclosed and defined in this specification extends 25 to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims (10)

1. Claims:

   1. An electronic point of sale device including: a housing having at least first and second stable orientations in which the device can be positioned; a touch screen display; at least one card reading device; a communications interface; at least one processor in communication with at least one memory device and the touch screen display, the at least one processor configured to provide at least one user interface on the touch screen display by which a user can interact with the point of sale device, the at least one user interface including a transaction payment interface for facilitating payment of a bill having a transaction amount; and an orientation sensor in communication with the at least one processor, the orientation sensor being configured to detect an orientation of the point of sale device and send an orientation signal to the at least one processor, wherein the at least one processor is configured to orient the display of the at least one user interface on the touch screen display according to the orientation signal.
2. 2. An electronic point of sale device according to claim 1, wherein the first and second stable orientations include a merchant-facing orientation in which, in use, the point of sale device typically faces a merchant and a customer-facing orientation in which, in use, the point of sale device typically faces a customer, and wherein the at least one processor is configured to display merchant-relevant information when the orientation sensor detects the point of sale device is in the merchant-facing orientation, and to display customer-relevant information when the orientation sensor detects the point of sale device is in the customer-facing orientation.
3. 3. An electronic point of sale device according to claim 1 or claim 2, wherein the orientation sensor is an accelerometer.
4. 4. An electronic point of sale device including: a housing; a touch screen display; at least one card reading device; a communications interface; and at least one processor in communication with at least one memory device and the touch screen display, the at least one processor configured to provide at least one user interface on the touch screen display by which a user can interact with the point of sale device, the at least one user interface including a transaction payment interface for facilitating payment of a bill having a transaction amount, and wherein the at least one user interface includes a bill splitting interface for splitting the transaction amount into a plurality of payment amounts, each payment amount for payment by one of a plurality of parties, and wherein the transaction payment interface is configured to facilitate payment of each payment amount by the relevant party.
5. 5. An electronic point of sale device according to claim 4, wherein the bill splitting interface includes an add party control operable to increase the number of parties between which the bill is to be split.
6. 6. An electronic point of sale device according to claim 4 or claim 5, wherein the bill splitting interface includes a remove party control operable to decrease the number of parties between which the bill is to be split.
7. 7. An electronic point of sale device according to any one of claims 4 to 6, wherein payment of each separate payment amount is achieved by a payment means selected from a group including: a credit card payment means read by the at least one card reading device; a debit card payment means read by the at least one payment device; and a cash payment means.
8. 8. An electronic point of sale device according to any one of claims 4 to 7, wherein the bill splitting interface provides bill splitting options selected from a group including: an even split option in which the at least one processor is operated to divide the transaction amount amongst the plurality of parties such that the payment amount for each party is substantially equal; a percentage split option in which each party nominates a percentage of the transaction amount to be paid by that party and the payment amount for a party is calculated according to the percentage nominated by that party; an amount split option in which each party nominates a dollar amount to be paid by that party; an item split option in which each party nominates one or more items from the bill and the payment amount for a party is the sum of the value of the items nominated by that party; and a random split option in which the at least one processor is operated to randomly split the transaction amount amongst the number of parties nominated.
9. 9. An electronic point of sale device according to any one of claims 4 to 8, wherein the bill splitting interface presents the transaction amount as a pie chart with a plurality of segments, each segment representing one of the plurality of parties and being sized to indicate a proportion of the total transaction amount to be paid by that party, and wherein the interface includes one or more proportion controls operable to alter the proportions of the total transaction amount payable by each of the separate parties.
10. 10. An electronic point of sale device according to any one of claims 4 to 9, wherein the housing has at least first and second stable orientations in which the device can be positioned; and wherein the point of sale device further includes an orientation sensor in communication with the at least one processor, the orientation sensor being configured to detect an orientation of the point of sale device and send an orientation signal to the at least one processor, wherein the at least one processor is configured to orient the display of the at least one user interface on the touch screen display according to the orientation signal.