GB2500352A - Portable device for single-handed operation and method of processing information - Google Patents

Abstract

A portable device 100 for single-handed operation comprises a housing (120) arranged to be held by one hand; a touchscreen (110) operable to display image information on a display area and arranged to receive touch inputs in response to the hand touching a button displayed in the display area; and a control unit operable to carry out operations based on touch inputs received in a first area 114 of the display area and operable to disregard, when carrying out operations, touch inputs outside the first area. Buttons 114a, 114b in the first area are positioned to be operated by the thumb of the hand and the first area is in the form of a band 114 along an edge of the touchscreen, the width of the band being less than the width of the touchscreen. The portable device is for processing at least one of a tax refund, a tax free transaction validation and a customs validation and further comprises a scanner for scanning a barcode. A further invention relates to a method of processing information based on a document provided by a user using a portable scanner.

Description

1

PORTABLE DEVICE FOR SINGLE-HANDED OPERATION AND METHOD OF

PROCESSING INFORMATION

5 Field

The present disclosure relates to a portable device for single-handed operation and to a method of processing information. The present disclosure is applicable, but not limited to, use for tax refund approval carried out by a mobile agent.

Background

10 Portable devices for carrying operations can include a keyboard and/or a touchscreen that mobile agents can use them while they are on the move. Such devices are generally arranged to be used with a stylus or another type of input means whereby the mobile agent can conduct operations using the device.

Summary of the Invention

15 Aspects of the invention are defined in the appended claims.

According to an aspect of the invention, there is provided a portable device for single-handed operation, the device comprising: a housing configured to be held by one hand; a touchscreen operable to display image information on a display area and arranged to receive touch inputs in response to the hand touching a button displayed in the display area; and a control unit 20 operable to carry out operations based on touch inputs received in a first area of the display area; operable to disregard, when carrying out operations, touch inputs outside the first area; and operable to control the display of image information on the touchscreen; wherein the control unit is operable to display, in response to inputs in the first area, information in a pane outside the first area; and wherein buttons in the first area are positioned to be operated by the 25 thumb of the hand and wherein the first area is comprised in a band along an edge of the touchscreen, the width of the band being less than the width of the touchscreen.

Such a device can advantageously be held and used by a mobile agent, using only one hand, while the other hand remains available for any other tasks (e.g. holding a document for checking or scanning). In particular, the specific arrangement of buttons and a pane enables 30 the user to enter inputs using for example only a thumb while being able to see all required information from the pane on a different part of the touchscreen. As a result, the portable device can be more efficiently used and the time required to use the device can thereby be reduced.

2

The portable device may for example be for processing at least one of a tax refund, a tax free transaction validation and a customs validation and wherein the pane and the buttons are for a corresponding tax refund application, tax free transaction validation application and/or customs validation application, respectively.

5 An example portable device can comprise a scanner, for example a bar code scanner, wherein the control unit is operable to carry out operations based on information, for example a one or two dimensional bar code, scanned by the scanner. Advantageously, a mobile agent or any other type of user of the device can use the portable device with one hand, for example entering inputs if required, while holding a document for scanning.

10 In an example portable device, the control unit can be operable to change the position of the first area, for example to change the position of the first area based on a left-handed or right-handed setting, so that it is comprised in a different band along a different edge of the touchscreen, wherein the width of different band is less than the width of the touchscreen. Such a device can advantageously be used with different users and in different configurations.

15 For example, depending on an application running and/or on a user's preference, it may be more appropriate to use a rectangular touchscreen with the buttons along the shorter or longer edge of the touchscreen.

In an example portable device, the control unit is operable to display buttons in the display area for receiving inputs from a user with the buttons being sized, shaped and arranged for

20 receiving input from touch operations with a thumb of the hand to facilitate one handed operation. By sizing, shaping and arranging the buttons for receiving input from touch operations with a gloved thumb of the hand, the device can then also be used comfortably in cold conditions where a user has to wear gloves (for example mittens) which can otherwise make the handling and using of a portable more difficult.

25 In an example portable device, the touchscreen has an elongate shape and the first band extends along the elongated direction of the touchscreen. For example, the touchscreen can have a substantially rectangular shape and the first band can extend along one of the two long edges of the touchscreen.

An example portable device comprises a communication unit for sending data to a remote

30 element. For example, the communication module can be a wireless communication unit.

In an example portable device, the control unit is operable to display three buttons in the first area and two panes outside the first area. For example, each button can have a length in a first direction of at least 2cm and a length in a second direction of at least 1cm, the first and second directions being different directions.

35 According to another aspect of the invention, there is provided a method of processing information based on a document provided by a user and using a portable device having a

3

scanner, the method comprising the steps of: the scanner of the portable device scanning a first identification item for the user; the device automatically transmitting a message based on the scanned first identification item to retrieve first identification information for the user from a remote element and displaying the first identification information for the user on the portable 5 device; in response to determining that the identity of the user is confirmed based on a comparison between the first identification information and second identification information obtained from a second identification item for the user: the scanner of the portable device scanning a document; the portable device displaying document information based on the scanning of the document; in response to an operation approval or rejection determination 10 based on the document information, the portable device reporting the document information and the operation approval or rejection determination. The method may for example be for processing at least one of a tax refund, a tax free transaction validation and a customs validation and wherein the pane.

List of Figures

15 The invention will now be discussed by way of example with reference to the accompanying drawings in which like-numbered elements represent like parts.

Figure 1 is an illustration of a portable device.

Figure 2 is an illustration of a possible touchscreen arrangement.

Figure 3 is an illustration of a portable device being help by a hand.

20 Figures 4-5 are illustrations of example displays on the device.

Figures 6-8 are schematic illustrations of example portable devices.

Figures 9 and 10 are illustrations of example button shapes and sizes.

Figures 11-13 are illustrations of example shapes for the first area of the touchscreen.

Figures 14-15 illustrate example methods of processing information in accordance with the 25 present disclosure.

Figure 16 illustrates an example of a high-level workflow.

Figure 17 illustrates another example of a high-level workflow.

Figure 18 illustrates an example power on/off workflow.

Figure 19 illustrates an example of a start-up workflow.

30 Figure 20 illustrates an example of an officer authentication workflow.

Figure 21 illustrates an example of a traveller's card scanning workflow.

Figure 22 illustrates an example of a tax refund form scan workflow.

Figure 23 illustrates an example of a tax refund form approval workflow.

4

Figure 24 illustrates an example of a tax refund form rejection workflow.

Figure 25 illustrates an example of a tax refund form skipping workflow.

Figure 26 illustrates an example of a call flow for a start-up process.

Figure 27 illustrates an example of a call flow for an officer authentication process.

5 Figure 28 illustrates an example of a call flow for an approval process.

Figure 29 illustrates an example of a state diagram for a tax refund form status.

Detailed Description

Figure 1 illustrates an example of a portable device 100. The portable device 100 includes housing 120, a touchscreen 110 and buttons 131-136. When using the device, the user can 10 use a combination of inputs on the touchscreen 110 and inputs using buttons 131-136 to interact with the device 100. For example, a cursor 134 can be used to navigate on an interface displayed on the touchscreen 110 and/or one of the other buttons can be used to go to a home screen, to cancel the last action or to go back one screen. It is to be noted that the portable device 100 of Figure 1 is for illustrative purposes only, and that in other examples, the 15 device may include more or fewer buttons (for example it may not include any buttons) and/or another shape or relative arrangements for the housing, the touchscreen and buttons may be provided.

Figure 2 is an illustration of a possible arrangement for the touchscreen 110 in accordance with the present disclosure. In this example, the touchscreen 110 comprises three areas, a 20 first area 114, a second area 116 and the status bar area 112. The first area 114 comprises buttons 114a, 114b which the user can activate by touching the touchscreen in their corresponding zones. In this example, two buttons have been illustrated, however in other examples the first area may include more or fewer buttons. The second area 116 can be used as a display area wherein the content can, for example, be displayed in a pane in this second 25 area and wherein the content can be updated based on inputs received in the first area 114. For example, in the illustration of Figure 2 the second area 116 comprises two panes 116a, 116b which can be used to display content based on inputs. Such content may vary, for example based on the application running, the user of the device and/or any fixed or variable parameter. In a tax approval system illustration, the first pane 116a may, for example, display 30 a traveller's details while the second pane 116b may display transaction information relating to that traveller. A status bar 112 can also optionally be provided (as illustrated for example in Figure 2) and may be used to display information such as date, connection status, notifications, etc.

Figure 3 is an illustration of a user's hand 300 holding and using the device 100. In this 35 example the user is using is device with his left hand and is using his left thumb 305 to enter

5

inputs by touching buttons in the first area 114. As can be seen on this illustration, the same hand is holding the device and using the touchscreen 110. By providing a user with such a device which can be used with one hand only, the device can be used to simultaneously display information and receive inputs via buttons when the user has to use the other hand, 5 e.g. for holding a document. Additionally, the speed at which the device can be used is also thereby increased. In a conventional device, if at any point, the user has to hold a document or to make use of one of his hand for any other reasons, he can no longer use the conventional device. Moreover, the illustrated device is easy and convenient to use even when the user is wearing gloves (e.g. mittens) and can for example be used in cold or 10 extreme conditions, for example outside in Nordic countries.

In other examples, the device may be arranged to be used with a right hand. For example, the first area comprising buttons may be provided along the opposite edge, in the area are 115. In this manner, there can be provided a device which is suitable for right-handed or left-handed users. The device may be permanently arranged to be in one of the right-handed or left-15 handed configuration, or it may be configurable (for example by the user) to be in one or the other configuration, for example to allow a user to change between left-handed and right-handed use, for example during prolonged use of the device. As an illustrative implementation, the button 136 in Figure 3 may be used to switch between the two configurations. In other examples, a suitable configuration can be selected in the settings for 20 an application and/or for the device.

Figure 4 illustrates an example use of the device 100. In this example, large buttons are provided in the first area for entering inputs with the thumb on the hand that holds the device 100. In response to inputs entered using the buttons, the display in an area outside the first area is changed. In the example of Figure 4, a traveller "John Doe" has been identified by his 25 passport and a transaction which may be eligible for tax refund is displayed on the screen. If the user of the device presses one of the "REJECT", "APPROVE" or "SKIP" buttons, the display will be changed accordingly. In one example, the transaction information will no longer be displayed and new buttons can be displayed in the first area, such as "NEW TRANSACTION" or "TERMINATE APPROVAL FOR TRAVELLER" buttons for checking 30 another transaction for this user or terminating the transaction approval process for this traveller, respectively. In an illustrative example, after the device's user touches the "APPROVE" button illustrated on Figure 4, the display may be changed as illustrated in Figure 5. This screen can for example be used to display the summary of the tax refund approval and rejection information for the traveller. In the illustration of Figure 5, the user can select to 35 consider a new transaction (e.g. by scanning a shop receipt with a scanner on the device) for approval or rejection, to validate the current approvals/rejections (and for example to output a final report) or to cancel the current approvals/rejections. In some examples, the user can

6

cancel or validate all or some of the transactions approvals/rejections. However, this embodiment may, for example, be more appropriate in situations where the user will not be using gloves or mittens and where the user can thus use smaller buttons more conveniently. In other situations, it may be more appropriate to have fewer options available to the user as 5 this may help reducing the number of buttons to display and/or facilitate having a layout which is simplified and more adapted to single-handed use.

Figures 6-8 are functional block diagrams illustrating possible device embodiments. In the example of Figure 6, the portable device 100 comprises a housing 120, a touchscreen 110, a control unit 140 and a scanner 150. Even though a scanner 150 has been included in this 10 example, in other embodiments the scanner may be omitted. For example, if documents (e.g. traveller's identification, transaction document, etc.) have to be identified, they can be identified in a different way, for example using manual inputs and/or communications such as Near Field Communications (NFC), Bluetooth, wired communications, etc. The control unit is operable to control the display on the touchscreen and to carry out operations using inputs in a first area of 15 the touchscreen and to disregard inputs outside the first area. In cases where a scanner 150 is provided, the control unit may be operable to activate and deactivate the scanner 150 whenever required. For example, if a document is to be scanned, the scanner can be activated. The scanner can then be automatically deactivated once the document has been successfully scanned or if the user decides to manually deactivate it, e.g. using a physical or 20 touchscreen button. Even though the touchscreen 110, control unit 140 and scanner 150 have been represented within the housing 120 in Figures 6-8, their physical arrangement may be such that they are partially or fully provided outside the housing. For example, the scanner may be an external scanner plugged on a port of the housing such that is part of the portable device while it is provided outside the housing. Any other physical arrangement of these 25 elements which is suitable for the portable device is considered under the present disclosure.

Figures 7-8 are functional block diagrams illustrating two possible portable device 100 implementations comprising a control unit 140 operable to carry out operations using inputs in a first area of the touchscreen and to disregard inputs outside the first area. In the example of Figure 7, the control unit comprises an input manager function or unit 160 which is operable to 30 process inputs received on the touchscreen 110. In this example the touchscreen 110 forwards to the input manager 160 a flow 710 of inputs received on the touchscreen. For example, the flow may include one or more of: an input position along one or more directions, a timestamp, an input type (e.g. single or dual touch), an input duration, an input length or distance, etc. The input manager 160 is then operable to determine whether an input received 35 via flow 710 will be considered or ignored. For example, the input manager may determine that the input was received outside the first area and will thus be disregarded. It may also determine that, even though an input was received in the first area, the input is of an

7

unacceptable type under the circumstances (e.g. a dual touch when only buttons usable with a single touch are provided in the first area) and will thus be disregarded. Once the determination has been made, the input manager may forward any input to be considered to the control unit 140 and/or to any other element for carrying out one or more operations based 5 on the input. For example, if the input corresponds to pressing a button on the touchscreen, the input may be forwarded so that the action corresponding to activating or pressing the button is carried out. In other examples, the input manager 160 may return to the touchscreen 110 the result of the determination and the touchscreen can then disregard or consider inputs based on the determination. In the illustration of Figure 7, the input manager 160 may be 10 controlled by the control unit 140 which can configure the input manager 160 with respect to determining whether an input will be considered or disregarded. Even though in the illustration of Figure 7, the input manager 160 has been represented as part of the control unit 140, in other embodiments it may be partially or fully external to the control unit 140.

In the example of Figure 8, the input manager 160 is implemented as part of the touchscreen 15 110. For example, it may be implemented in at least one of a physical element managing the touchscreen (similar to a graphic card in a computer), an operating software ("OS") module managing the touchscreen and an application managing the touchscreen. The control unit 140 is operable to control the input manager 160 by configuring it with parameters 812 sent to the input manager 160. The input manager 160 can then determine whether an input will be 20 considered or disregarded based on the configuration received from the input manager 140. In the example of Figure 8, the input manager 160 can then forward inputs not to be discarded to the control unit 140 via flow 814. In other examples, another element, either of the touchscreen or not, may forward the inputs to be considered to the relevant element and/or the input may be forwarded to an element other than the control unit 140 instead of -or in addition 25 to- the control unit 140. Figure 7 and 8 have been provided for the purpose of illustrating two possible implementations for the control unit to carry out operations using inputs in the first area of the touchscreen and to disregard inputs outside the first area. However the present disclosure is not limited to these two specific examples and the portable device 100 may be implemented in any other manner suitable for the control unit to carry out operations based on 30 relevant inputs restricted to a first area.

Figures 9 and 10 are illustrations of possible button shapes and sizes for buttons to be displayed on the touchscreen and to be touched with the thumb of the hand holding the portable device. In order to facilitate the use of the buttons with only one thumb, the buttons are preferably sized so as to be used with a thumb. For example, in Figure 9, the button 900 35 has been dimensioned so that its area comprises a disk area 901 having a diameter d. The diameter may be any value suitable for receiving an input from a thumb, or possibly a gloved thumb. For example, the diameter may be in the 0.8 cm - 3 cm range (0.8cm and 3cm

8

included), e.g. 1cm, 1,5cm, 2cm, or 2.5cm, or in any sub-range, e.g. having two of 0.8cm, 1cm, 1.5cm, 2cm, 2.5cm, and 3cm as extremities. The button 900 may be dimensioned so as to fit the disk 901 as closely as possible. For example, if the button 900 has a rectangular shape, it can be dimensioned as a square having a side length of d. In other examples, the button may 5 have a disk shape with a diameter of d or more, or may have a shape and dimension which does not necessarily fit the disk 901 as closely as possible. Figure 9 is an illustration of such a case: the button 900 in this example is rectangular-shaped and is dimensioned so that its length L is more than diameter d of disk 901 and its width W is equal to diameter d. In the example of Figure 10, the button 1000 is sized and dimensioned so that its area comprises an 10 elliptic are 1001 having a short axis length a and a long axis length b. In the example of Figure 10, the button 1000 has a rectangular shape wherein its length L is more than twice the long axis length b and its width W is more than twice the short axis length a. In other examples, the length L and/or width W may be equal to twice the corresponding axis length. Even though only substantially rectangular shapes (e.g. rounded corner rectangles, squares) have been 15 discussed in the previous examples, the present disclosure is not limited to such embodiments and a button displayed in the first area 114 might have any suitable shape, for example an elliptic shape, a disk shape, an octagonal shape, a trapezoidal shape, etc.

Figures 11-13 illustrate possible shapes for the first area 114 of the touchscreen, which can be used as alternative to the band-shaped first area 114 of Figure 2. The shape of the first area 20 114 may be adjusted based on for example the expected position of the user's thumb or an expected area reachable by the thumb. In the example of Figure 11, the first area 114 is larger at one edge (e.g. the bottom edge) of the touchscreen 110 than at the opposite edge (e.g. the top edge) of the touchscreen 110. For example, it may correspond to an intersection of the touchscreen area and a triangular area. In the illustration of Figure 12, the first area 114 25 corresponds substantially to the intersection of the touchscreen area and a sector of a disk or an ellipse. For example, the disk sector may correspond to an expected area that a user's thumb can reach as the thumb is rotated along the touchscreen's surface when the user's hand holds the portable device. Figure 13 is a further illustration of an alternative shape for the first area 114. In this example, the first area 114 has a shape corresponding to the intersection 30 of the touchscreen area and a triangular- or diamond-shaped area. This shape can be used for example as an approximate shape for the first area shape illustrated in Figure 12. More generally, any suitable shape for the first area 114 can be used, such as a substantially triangular shape, a polygon, a curved shape, etc. With whichever shape considered as suitable, the first area 114 is provided within a band along an edge of the touchscreen, wherein 35 the band's width is less than that of the touchscreen. In Figures 11-13, the edge of this band has been illustrated as dashed line 115. The size of the band may vary depending on the device's size (e.g. the size of the housing or the size of the part that the user's hand will hold)

9

and/or on an expected use of the device (e.g. with a naked or gloved hand). In some examples, the width of the band may be in the 0.8cm - 3cm range (0.8cm and 3cm included), for example 1cm, 1.5cm, 2cm, or 2.5cm or in any sub-range, e.g. having two of 0.8cm, 1cm, 1.5cm, 2cm, 2.5cm, and 3cm as extremities.

5 There will now be discussed methods of processing information based on a document provided by a user and using a portable device having a scanner in accordance with the present disclosure. In the example process of Figure 14, the method starts at step S1401 where the scanner (of the device) scans a first identification item for identifying a person, for example for identifying a traveller. Next, at step S1402, the device transmits a message based 10 on the scanned item. For example, if the identification item is a passport, a national identity card or another type of user identification (e.g. a loyalty card), the device may transmit the identification item number, a full or partial name and/or any other information retrieved from scanning the identification item. This message may be sent for example to a remote system or database for checking whether the person is registered in the database. In response to the 15 message, the device may receive a message comprising first identification information for the person. The first identification information for the person may comprise one or more names, an address and/or one or more biometric identifiers (e.g., fingerprint, iris identifiers, photos, etc.) for the person. Upon retrieval of the first identification information for the user, the portable device displays the first identification information (step S1403). Next a determination 20 is made whether the person's identification is confirmed, at step S1404. This may involve for example a device's operator manually checking whether the first identification information corresponds to the first identification item or, alternatively or in combination, the device automatically making a determination. In some examples, this device determination may involve sub-steps such as data comparison (for example with conventional and/or fuzzy logic), 25 a facial recognition and/or other biometric information check (e.g. fingerprint, iris recognition, etc.). Depending on the outcome of this determination, the method move on to "identity confirmed" (S1405) or "identity not confirmed" (S1406). If the identity is confirmed, the method can continue as illustrated in Figure 15. If the identity is not confirmed, the method may stop there. Alternatively, it may in that case return to a state where the device is awaiting the 30 scanning of a new identification item and/or it may send a report with information about the failed identification process. This could be advantageous for example to try to estimate whether one or more persons are trying to impersonate an identity, possibly repeatedly.

Figure 15 is an example illustration of a method of making an approving or rejecting determination relating to a document for the identified user. At the first step S1501, the 35 scanner of the portable device scans a document. In some examples, the document may be a purchase document (e.g. a purchase receipt, a VAT receipt, a VAT refund cheque), a ticket (e.g. a train or parking ticket), or any other suitable document. The portable device then

10

displays document information (S1502) based on the document information. For example, in the example of a tax refund cheque, if the document relates to the purchasing of goods, the information displayed may include one or more of: the type of goods, goods identification (e.g. description, serial number, brand, and/or model), place of purchase (e.g. shop name, city 5 name, etc.), purchase amount, VAT amount, whether the transaction or goods are a VAT-refundable (e.g. in case of constraints as to minimal purchase amount, goods category, etc.). An operation approval or rejection determination may then be made at step S1503 and based on the document information. For example, it may be determined whether a train ticket is valid (e.g. if the operation is a train ticket validity check), or whether a tax refund is allowed (e.g. if 10 the operation is a tax refund allowability check). A mobile agent may in some examples check whether the goods description corresponds to the goods presented by the traveller, check whether the journey for the train ticket is consistent with the train on which the ticket holder is. In response to an approval or rejection determination, the portable device can generate a report comprising document information and the corresponding approval determination 15 (S1504) or rejection determination (S1505). At a later stage, the portable device may then transmit the report, for example to a remote server, to a device connected via a wired or wireless connection, or to any other suitable element. In some examples, the portable device may transmit the report with other reports. In one implementation, the portable device may generate and transmit the report. In another implementation, the portable may wait before 20 transmitting the report. For example, it may be configured to transmit the report with other reports for the identified user, or it may transmit the report once it has accumulated a certain amount data of reports to transmit. For example it may be configured to send reports once it has at least 1 MB of reports to transmit (e.g. to optimise bandwidth usage).

Additionally, after the report has been generated, the method may terminate after the report 25 transmittal, or the method can return to a user identification step, or return to a document scanning step (e.g. to check further tickets for the ticket carrier or to process further transaction purchases for the identified traveller), either before or after the report transmitting step.

In other examples, the report may be generated remotely by a remote server in response to the information input at the portable device and transmitted to the remote server. The remote 30 server can the n transmit the report to the portable device for displaying or otherwise reporting to the operator of the portable device.

Even though the above examples discuss determinations with two possible outcomes (e.g. at steps S1404 or S1503), in other examples, the determination may have more possible outcomes. For example, it could additionally be determined to skip the determination. In the 35 case of a tax refund process, a "skip" determination may for example result in the transaction being neither approved for refund nor rejected. This may be advantageous for example in cases where a mobile agent using the portable device cannot make the determination (e.g. he

11

may require additional information to make the determination) or is not allowed to make such determination. The mobile agent may then for example swiftly complete the process for any transaction he can approve or reject, and refer the traveller to a desk or remote support for any other transaction he could not approve or reject. In other example, the determination may 5 result in a "provisional acceptance", which may for example be fully approved only if the total refund amount is equal to or more than a threshold (for example in cases where such a minimum threshold may be required by law or for another reason). In other cases, it may be provisionally approved provided that the total refund amount for this traveller is not more than a threshold, for example in cases where bigger refund may be required to be dealt with at a 10 desk.

In other examples, the portable device may not comprise a scanner and a device's user may for example manually enter information, such as identification information (e.g. passport number, member identification, etc.). It may be advantageous to provide a scanner as this would make the processing information quicker to carry out, in particular if the user is using the 15 portable with one hand only. For example, with a portable device adapted for use with one hand and a scanner, a mobile agent can very quickly proceed through the identification of a user and the document scanning and approval/rejection determination. This may be particularly useful in a tax refund process wherein the process is generally carried out at a country's border and where a quicker tax approval system significantly reduces the queues at 20 the border, thereby fluidising the traffic and reducing local pollution created by waiting cars.

Further illustrations of possible tax refund form handling methods will now be discussed with reference to Figures 16-25. Figure 16 illustrates an example of a high-level workflow for example for using the device for handling tax refunds. At step S1601, the method starts and at step S1602, the customs officer is authenticated. For example, the officer may be 25 authenticated using a badge, biometrics (e.g. a fingerprint) and/or a login and password. Next, the officer may receive documents from a traveller at step S1603. For example, the documents may include one or more tax refund forms, one or more receipts and/or a form of personal identification for the traveller. At check S1604, it is determined whether the documents include a tax refund traveller ID card (e.g. issued by the organisation handling the tax refunds). In the 30 event that documents include such a tax refund traveller ID card, the method proceeds to step S1605, where the ID card is scanned by the customs officer, and the method can then move on to step S1606. In the event that the documents do not include a tax refund traveller ID card, the method moves on to step S1606, thereby skipping step S1605.

At step S1606, the officer a scans tax refund form included in the documents and, at step 35 S1607, the officer confirms the traveller's identity (e.g. by comparing a photo associated with the traveller ID card to the traveller and/or by checking another form of ID for the traveller such

12

as a passport). Next, the customs officer can validate the export at step S1608 and approve or disapprove the tax refund form at step S1609.

At step S1610, it is determined whether one or more additional tax refund forms remain to be processed for the same traveller (in which case the method returns to step S1606), whether all 5 tax refund forms for this traveller have been processed and the customs officer will now deal with another traveller (in which case the method returns to step S1603) or whether all tax refund forms for this traveller have been processed and the officer will not deal with any other travellers (in which case to methods goes to S1611 where it ends).

Figure 17 illustrates another example of a high-level workflow. In this example, if a traveller 10 does not have any valid traveller's ID card, the traveller may then be asked to go to an office and may not be able to benefit from validation through the mobile device operated by an officer. Also, the tax refund forms and the traveller's ID card may be scanned in any suitable order, e.g. a tax refund form may be scanned before a traveller's ID card is scanned.

At step S1701 the method starts and at step S1702 the officer is authenticated on the device. 15 Then, at step S1703, the traveller can give the officer one or more receipts, one or more tax refund forms and/or a traveller's ID card. The officer can then start scanning documents at step S1704 and it is determined whether a traveller's ID card or a tax refund form will be scanned. If the officer scans a traveller's ID card, the method moves on to step S1705 where the card is scanned or if the officer scans a tax refund form, the method moves onto step S1709.

20 After step S1705, it is determined at step 1706 whether the traveller's ID card is valid or not. If it is not valid, the method moves on to step S1708 where the officer asks the traveller to go to an office. If it is valid, the method moves on to step S1707 where it is determined whether any tax refund form is pending or not. If no tax refund form is pending, the officer can then scan a tax refund form for the user (step S1709). If a tax refund form is currently pending, the method 25 moves to step S1714 where the officer reviews the details of the tax refund form for this traveller.

From step S1709 where the officer scans the tax refund form, it is then determined at step S1710 whether the tax refund form is found and valid, e.g. if there is a corresponding valid entry in transaction/tax refund forms records of the tax refund organisation. If it is found and 30 valid, it is then determined at step S1711 whether traveller's data is available for the tax refund form. If it is available, the officer can then review the details at step S1714. If the traveller data is not available, the officer can then ask the user for a traveller's ID at step S1712. From step S1712, it is determined at step S1713 whether the traveller has a traveller's ID card. If he has such a card, the method moves to step S1706 (discussed above) and if he doesn't have such 35 a card, the method moves on to step S1708 (discussed above).

13

From step S1714 where the officer can review details of the tax refund form and/or of the traveller's data, the method moves to step S1715 where it is determined which action to take with respect to tax refund. If it is decided, for example by the officer, to reject or skip this tax refund form, the method moves on to step S1720 where information regarding the tax refund 5 being rejected or skipped can be displayed on the mobile device for certain time. If it is decided to approve this tax refund form, the method moves to step S1716 where the approval can be confirmed or not. If it is confirmed, the method moves to step S1720 (mentioned above) where information regarding the approval can be displayed for a certain time. If it is not confirmed, for example if an error has occurred, an error message asking for confirmation can be displayed 10 at step S1717. Next, the officer can confirm the approval error at step S1718.

After step S1720 or step S1718, it is determined at step S1719 whether there is any additional tax refund form to be scanned for this traveller or whether the officer may now deal with a new traveller. In the event that the officer has finished dealing with travellers, the officer can logout in which case the method ends at step S1721. If a new tax refund form has to be scanned, the 15 method returns to step S1709 (discussed above) or, if the officer decides to deal with a new traveller, the method then returns to step S1703 (discussed above).

Figures 16 and 17 are illustrations of possible high-level methods for processing tax refund forms for travellers. The particular examples, as for all other illustrations, are not intended to be limiting but are intended to illustrate possible implementations. A method according to present 20 disclosure may include more or fewer steps, the same or different steps and/or may include any suitable combination of any steps illustrated in Figures 16 or 17 or of any other appropriate steps.

Illustrative examples of more specific aspects of the use of the mobile device and/or of the tax refund form processing methods will now be discussed with reference to Figures 18 to 25.

25 Figure 18 illustrates an example power on/off workflow. At step S1801 the method starts and at step 1802 a customs officer can pick up or take the device and then switch it on at step S1803. At step 1804, an input field for entering a password for the certificate store can be displayed. This can be used at this stage or at a later stage, for example to check whether the device has a valid certificate on it (e.g. to authenticate that the device is a genuine device 30 and/or that it has a valid licence installed on it).

Next, at step 1805, the officer can identify the customs area for example by scanning a QR code for this area. In other examples, the officer can use NFC to enter the location, enter the location manually or select it from one or more lists and yet further examples, geolocation may be used by the device and/or officer to enter the location. For illustrative purposes, the 35 remainder of the method will be shown using the example of a QR code implementation. At step S1806, it is determined whether the QR code is valid. In the event that it is not valid the

14

method goes to step S1807 where it is determined whether a threshold for number of attempts has been exceeded. If it has not been exceeded, the method returns to step S1804 (discussed above). If it has been exceeded, the method moves to step S1808 where the home screen is displayed. Also, from step S1806, if it is determined that the QR code is valid, the method also 5 proceeds to step S1808. Thus, at this step S1806 where home screen is displayed, a valid password and/or a valid QR code may have been provided or no valid password or QR code may have been provided yet. Then, at the next S1809, the method ends.

Figure 19 illustrates an example of a start-up workflow. At step S1901 the method starts with the customs officer starting a tax refund application on the device at step S1902, for example 10 by pressing an icon on the home screen or by navigating one or more menus to find and launch the application. Next, at step S1903 it is determined whether there is a valid certificate for the device. If no valid certificate can be found, the method moves on to step S1904 where an error message is displayed and the method then ends at step S1905.

If the valid certificate is found on the device, a message for waiting is displayed to the customs 15 officer at step S1906. For example, such a message may be displayed while steps S1907 and S1908 are performed. Next, at step S1907, it is determined whether any connections are available. If no connection can be found, it is determined at step S1908 whether the maximum number of attempts (to find a connection) has been exceeded. If it has been exceeded, the method moves to step S1904 (discussed above). If it has not been exceeded, the method goes 20 back to step S1907 to try again to find a connection.

If a connection has been found, a message for waiting for configuration can be displayed at step S1909. For example, such a message can be displayed while steps S1910 and S1911 are performed. At step S1910, it is determined whether time information (e.g. date and time) and configuration information have been uploaded successfully. If they have not been 25 uploaded successfully, it is determined at step S1911 whether this upload should be tried again. For example, this can be based on a number of previous attempts, the connection status and/or any other suitable information. If it is determined that it will not be tried again, the method goes to step S1904 (discussed above). If it is determined that it will be tried again, the method returns to step S1910.

30 From step S1910, if it is determined that the upload has been successful, the time and configuration information on the device can be updated based on the uploaded time and configuration information (step S1912). For example the date and time can be reset based on date and time information that may have been received and the configuration can be updated or overwritten based on configuration information that may have been received. The 35 initialisation of the application is then completed and the application may then be ready to use.

15

Next, at step S1913 the application can be launched for use by the customs officer, starting with for example showing a logo. The method may then end at step S1905.

Figure 20 illustrates an example of an officer authentication workflow which may for example be used once the (tax refund) application has been launched so that the customs officer can 5 be identified before he processes tax refund forms. The method starts at step S2001 and at step S2002 the officer can scan an officer's identification, for example the officer can scan a barcode on an ID card and/or fingerprint may be read and/or a login and password may be entered, etc. For illustrative purposes, the remainder of the method will be shown for an identification based on scanning a barcode on the officer's ID card.

10 At step 2003, it is determined whether the ID card is valid, for example based on the barcode previously scanned. If the ID card is not valid, an error message can be displayed at step S2004, for example for certain time. After step S2004, the method may return to step S2002 waiting for an officer to start the identification again. If the ID card is valid, authentication and permissions for the officer may be requested at step S2005. It is then determined at step 15 S2006 whether the identified officer is authorised to use the application. In the event that he is not authorised to use the application, the method goes to step S2004 (discussed above). If it is determined at step S2006, that the officer is authorised to use the application, to start screen for the application may be displayed to the officer at step S2007. The tax refund application may then be ready to use for the officer. Next, at step S2008, the method ends.

20 Figure 21 illustrates an example of a traveller's card scanning workflow. The method starts at step S2101 and at step S2102, a customs officer can scan a traveller's ID card. Next, it is determined at step S2103 whether the traveller's ID card is valid or not. In the event that the card is not valid, the method moves to step S2104 where it is determined whether the officer can try to scan the card again (in which case the method returns to step S2102) or should not 25 try again (in which case the method goes to step S2105). At step S2105, the customs officer can ask traveller to go to an office and the method can then end at step S2106.

If it is determined at step S2103 that the traveller's ID card is valid, it is then determined at step S2107 whether any non-personalised tax refund form (e.g. not yet associated to the traveller) has been scanned before. If one or more tax refund forms have been scanned before, the 30 traveller's details can be displayed to the officer along with the tax refund form information (step S2108) and the method can then end at step S2106. In some examples, before, at or after step S2108, the tax refund form may be personalised (i.e. associated with the traveller previously identified). If no tax refund forms have been scanned before, the traveller's details can be displayed to the officer either without any tax refund form information or with an empty 35 tax refund form (step S2109) and the method can then end at step S2105.

16

Figure 22 illustrates an example of a tax refund form scan workflow which can for example be performed before or after a traveller's identification has been checked (e.g. by scanning a traveller's ID card). The method starts at step S2201 and at step S2202 a customs officer can scan a tax refund form (e.g. the officer can scan a barcode such as a QR code on a tax refund 5 form). It is determined at step S2203 whether the tax refund form can be found for example in the records of the tax refund organisation. If the tax refund form cannot be found, the method returns to step S2202. If however tax refund form can be found, the method moves to step S2204 where it is determined whether the tax refund form is personalised or not. If the tax refund form is personalised, e.g. if a traveller's ID card has already been scanned and 10 validated prior to the scanning of the tax refund form, the method moves to step S2205 where the traveller's details and tax refund form information are displayed. Next, the method can end at step S2207.

If the tax refund form is not personalised, e.g. if it is not associated with a particular traveller, at step S2206 tax refund form information can be displayed and a button for scanning and/or a 15 message instructing the scanning of a traveller's ID card can be displayed. Next, the method can end at step S2207.

Figure 23 illustrates an example of a tax refund form approval workflow. At step S2301 the method starts and the customs officer can inspect the goods at step S2302. For example, the customs officer may wish to compare the goods with the goods description from the tax refund 20 form to determine whether they correspond to each other. Next, at step S2303 the customs officer can decide to approve the transaction (depending on the circumstances, the officer may decide differently, e.g. to approve/reject/skip the transaction).

Once the officer has approved the transaction, it is determined at step S2304 whether the approval has been successful or not. If the approval fails, an error message can be displayed 25 at step S2305 and the customs officer can confirm the message (i.e. confirm the failed approval) at step S2306. Next, the tax refund form and the traveller's details can be displayed at step S2307. The method can then end at step S2310. In some examples, from S2310, the customs officer may wish to start the method again at step 2301, for example in a case where the approval was unsuccessful and the officer wishes to have another attempt at approving the 30 transaction.

If it is determined at step S2304 that the approval is successful, a confirmation screen or message can be displayed for certain time (step S2308). Next, the traveller's details and an empty tax refund form can be displayed at step S2309. For example, the display of an empty tax refund form can be useful to indicate that the tax refund form has been processed (and/or 35 approved). Then, the method can then end at step S2310.

17

Figure 24 illustrates an example of a tax refund form rejection workflow. At step S2401, the method starts at step S2401 and the customs officer can inspect the goods at step S2402. For example, the customs officer may wish to compare the goods with the goods description from the tax refund form to determine whether they correspond to each other. Next, at step S2403, 5 the customs officer can decide to reject transaction (depending on the circumstances, the officer may decide differently, e.g. to approve/reject/skip the transaction).

Once the officer has rejected a transaction, it is determined at step 2404 whether the rejection has been successful or not. If the rejection fails, an error message can be displayed at step S2405 and the customs officer can confirm the message (i.e. confirm the failed rejection) at 10 step S2406. Next, the tax refund form details and traveller's details can be displayed at step S2407. The method made then and at step S2410. In some examples, from S2410, the customs officer may wish to start the method again at step S2401, for example a case where the rejection was unsuccessful and the officer wishes to have another attempt at rejecting the transaction.

15 If it is determined at step S2404 that the rejection was successful, a confirmation screen or message can be displayed for certain time (step S2408). Next, the traveller's details and an empty tax refund form can be displayed at step S2409. For example, the display of an empty tax refund form can be useful to indicate that the tax refund form has been processed (and/or rejected). The method may then end at step S2410.

20 Figure 25 illustrates an example of a tax refund form skipping workflow. The method starts at step S2501 and at step S2502, the customs officer can inspect the goods, for example to compare the goods with the goods description from the tax refund form. Next, at step S2503, the customs officer can decide to skip the transaction. For example, the customs officer may decide that it would be more appropriate for this transaction to be processed at a desk rather 25 than with a mobile officer using a mobile device. A message and/or screen can then be displayed to confirm that the transaction has been skipped, wherein the message and/or screen can be displayed for a certain time (step S2504). At step S2505, the traveller's details can then be displayed. For example, they may not be displayed with the tax refund form information, e.g. to illustrate that the tax refund form has been processed by the customs 30 officer.

Examples of call flows will now be discussed for illustrative purposes with reference to Figures 26-28. These examples are not intended to be limiting and, for example, the various steps illustrated may be performed in a different order (e.g. in any suitable order) and/or may be combined in any appropriate manner.

35 Figure 26 illustrates an example of a call flow for a start-up process. In some examples, this call flow may correspond to a certain extent to the workflow illustrated in Figure 19 and in other

18

examples, this call flow may correspond to a different start-up workflow. In the example implementation illustrated in Figure 26, there is provided an application 201 (for example running on a mobile device 100), a server 202 and a configuration element 203 (for example a configuration server or a configuration files repository). At S2601, the application 201 checks 5 that there is a valid certificate and at step S2602, the application displays a message to a user (e.g. a customs officer) such as "please wait while connecting to the network" and then tries to request the current time to the server 202 (S2603). If the application 201 is connected to the network and able to connect with the server 202, it may then receive a response to this time query at S2604.

10 Next, the application 201 sets the date and time based on the response from the server 202 at step S2605. At step S2606, the application 201 can display a message such as "please wait while retrieving the configuration". At step S2607 (which may occur before, on and/or after step S2606), the application 201 displays the updated date and time.

Next, at step S2608, the application 201 requests an updated configuration from server 202 15 which may in turn requests an appropriate configuration from the configuration element 203. For example, the request for an updated configuration may include a device ID for identifying the device 100 running the application 201 and the configuration returned by the configuration element 203 may be based on this device ID. At step S2610 and S2611, a configuration is returned from the configuration element 203 to the server 202 and from the server 202 to the 20 application 201, respectively. At step S2612, the application 201 can then store the configuration received, for example for the configuration to be applied to the application and/or the device. Optionally, the application 201 may then display a message such as "please use your ID card to login to the application" (S2613).

Figure 27 illustrates an example of a call flow for an officer authentication process. In some 25 examples, this call flow corresponds to the workflow illustrated in Figure 20 and in other examples, this call flow may correspond to a certain extent to a different authentication workflow. In the example implementation illustrated in Figure 27, there is provided a user 200 (for example a customs officer), an application 201 (for example running on a mobile device 100), a server 202 and an identity server 204. For example, the identity server may be a server 30 commonly known as a "AAA" server or a server including or for accessing the database storing identity information.

At S2701, the user 200 scans his or her ID card (for example, using a scanner comprised in or connected to a device 100 running the application 201) and the outcome of the scanning is sent to the application 201. The application 201 can then validate the ID card based on the 35 scanned information at S2702. Next, the application 201 can authenticate and retrieve permissions for the user by requesting such authentication and permissions to server 202

19

(S2703), which in turn can check the authentication and the permissions for the user with the identity server 204 (S2704). In some examples, this may involve the user 200 providing additional authentication information (e.g. a user ID and password) prior to S2703 and S2704.

The identity server 204 can then authenticate the user and if for example the authentication is 5 successful, the identity server 204 can return the permissions for this user at step S2705. Next, the server 204 can send the received permissions to the application 201 (S2706). The application 201 may then finalise the authentication and permission granting process (S2707) and if the authentication is successful finalised, the application 201 can then proceed with any appropriate steps. For example, as illustrated in Figure 27, the application 201 may display the 10 start screen at S2708.

Figure 28 illustrates an example of a call flow for an approval process. In some examples, this call flow corresponds to the workflow illustrated in Figure 23 and in other examples, this call flow may correspond to different approval workflow. In the example implementation illustrated in Figure 28, there is provided a user 200, an application 201, a server 202 and a tax refund 15 server 205 (for example a server comprising or being connected to one or more databases for traveller's data and/or for transaction data).

At step S2801, the user 200 (e.g. a customs officer) can scan a traveller's ID card and the outcome of the scanning is sent to the application 201. The application 201 may then validate the traveller's ID cards at step S2802. For example the application 201 may check whether an 20 ID card identifier or number is compliant with existing ID card number rules (e.g. the ID card identifier or number may comprise a CRC code). The application 201 may then retrieve traveller's details (S2803) by sending a request to the server 202 based on the scanned ID card. The server 202 may then in turn retrieve traveller's details from the tax refund server 205 with a query sent at S2804 and a response received at S2805. The server 202 may then 25 respond to the query received at S2803 with the travellers details received at S2805 (S2806). The application 201 may then optionally display the received traveller's data to the user 200 at S2807.

The user 200 may then scan a tax refund form at S2808 and the application 201 may then validate the scanned form at S2809. At step 2810, the application 201 can then contact the 30 server 202 to retrieve the corresponding transaction details which can be returned by the server 202 at step S2811.

Optionally, the application 201 can request for this transaction to be associated with this traveller by sending a request to the server 202 (S2812), for example if the transaction is not personalised or associated with any traveller. The server 202 may then request the tax refund 35 server 205 to associate the transaction and traveller (S2813) and the association may then be

20

confirmed by the server 205 (S2814). Next, the server 202 can confirm to the application 201 that the association has been done.

Next, at S2816, the application 201 can display the transactions details to the user 200. For example, they may be displayed at the same time as the traveller's data or they may be 5 displayed on a different screen or tab. In the event that the user 200 (e.g. a customs officer) decides to approve the tax refund for this transaction and traveller. The user 200 uses the application 201 to request approval of the tax refund (S2817). The application 201 may then retrieve the transaction details from the server 202 (S2818 and S2819). The application 201 can then request approval of the transaction for this traveller to the server 202 (S2820 and 10 S2821). If for example the approval at the server 202 was successful, the application 201 can notify an approval confirmation to the user 200 (S2822). For example, the application 201 may display a message to the user 200 and/or play a sound to indicate that the approval has been successful.

In the example of Figure 28, the tax refund server 205 is mainly used as a server for managing 15 traveller's data as the server 205 is mostly used to retrieve traveller's data and to associate a traveller with one or more transactions. In other examples, the server may also or alternatively be used to manage transactions data.

Figure 29 illustrates an example of a state diagram for a tax refund form processing status. The status of a tax refund relating to a transaction or tax refund form may be maintained at a 20 server, of the tax refund organisation for example, (e.g. server 202 and/or server 205) and may also or alternatively be maintained locally by the application 201. Once a tax refund form has been identified (2900), for example has been scanned or manually or automatically entered, the status of the tax refund is by default set to "Not Set" (2901). From this state, the tax refund can be approved or rejected. If approved, the state changes to new status "Approved" (2902) 25 and if rejected, the state changes to new status "Rejected" (2903). Also, from states 2902 and 2903, the status can be undone in which case the tax refund's status returns to the state "Not Set" 2901.

In accordance with the present disclosure, the term "scanner" includes barcode scanners, such as conventional vertical line-barcodes or QR codes; and more generally any image 30 identification means for identifying a document reference or identification number. QR codes can be particularly advantageous in view of the amount of information stored in a limited area.

In the present disclosure, the term touchscreen refers to an element which is operable to display image data and which is operable to receive touch input. Touching the touchscreen comprises applying pressure onto the screen or approaching the touchscreen, using input 35 means. Input means may comprise for example a finger, a pen or a stylus. Depending on, for example, the sensibility of the touchscreen and/or on the type of input means, a different

21

degree of pressure may be required for inputting information. The touchscreen may use any appropriate technology (e.g. capacitive or resistive technologies), may be arranged to detect single touch and/or dual touch.

22

Claims (17)

1. Portable device for single-handed operation, the device comprising: 5 a housing arranged to be held by one hand;

a touchscreen operable to display image information on a display area and arranged to receive touch inputs in response to the hand touching a button displayed in the display area; and a control unit operable to carry out operations based on touch inputs received in a first 10 area of the display area; operable to disregard, when carrying out operations, touch inputs outside the first area; and operable to control the display of image information on the touchscreen;

wherein the control unit is operable to display, in response to inputs in the first area, information in a pane outside the first area; and 15 wherein buttons in the first area are positioned to be operated by the thumb of the hand and wherein the first area is comprised in a band along an edge of the touchscreen, the width of the band being less than the width of the touchscreen.

2. A portable device according to claim 1, wherein the portable device is for processing at 20 least one of a tax refund, a tax free transaction validation and a customs validation and wherein the pane and the buttons are for a corresponding tax refund application, tax free transaction validation application and/or customs validation application, respectively.

3. A portable device according to claim 1 or 2, further comprising a scanner, wherein the 25 control unit is operable to carry out operations based on information scanned by the scanner.

4. A portable device according to claim 3, wherein the scanner is for scanning a barcode, wherein the control unit is operable to carry out operations based on a barcode scanned by the scanner.

30

5. A portable device according to any preceding claim, wherein the control unit is operable to change the position of the first area so that it is comprised in a different band along a different edge of the touchscreen, wherein the width of different band is less than the width of the touchscreen.

35

23

6. A portable device according to claim 5, wherein the control unit being operable to change the position of the first area are comprises the control unit being operable to change the position of the first area based on a left-handed or right-handed setting.

5

7. A portable device according to any preceding claim, wherein the control unit is operable to display buttons in the display area for receiving inputs from a user, the buttons being sized, shaped and arranged for receiving input from touch operations with a thumb of the hand.

8. A portable device according to claim 7, wherein the button are sized, shaped and 10 arranged for receiving input from touch operations with a gloved thumb of the hand.

9. A portable device according to any preceding claims, wherein the touchscreen has an elongate shape and wherein the first band extends along the elongated direction of the touchscreen.

15

10. A portable device according to any preceding claims, wherein the touchscreen has a substantially rectangular shape and wherein the first band extends along one of the two long edges of the touchscreen.

20

11. A portable device according to any preceding claims, wherein the portable device comprises a communication unit for sending data to a remote element and wherein, optionally, the communication module is a wireless communication unit.

12. A portable device according to any preceding claims, wherein the control unit is 25 operable to display three buttons in the first area and two panes outside the first area.

13. A portable device according to any preceding claims, wherein each button has a length in a first direction of at least 2cm and a length in a second direction of at least 1cm, the first and second directions being different directions.

30

14. A method of processing information based on a document provided by a user and using a portable device having a scanner, the method comprising the steps of:

the scanner of the portable device scanning a first identification item for the user; the device automatically transmitting a message based on the scanned first 35 identification item to retrieve first identification information for the user from a remote element and displaying the first identification information for the user on the portable device;

24

in response to determining that the identity of the user is confirmed based on a comparison between the first identification information and second identification information obtained from a second identification item for the user:

the scanner of the portable device scanning a document; 5 the portable device displaying document information based on the scanning of the document;

in response to an operation approval or rejection determination based on the document information, the portable device reporting the document information and the operation approval or rejection determination.

10

15. A method according to claim 14, wherein the method is for processing at least one of a tax refund, a tax free transaction validation and a customs validation and wherein the pane.

16. A method according to claim 14 or 15, wherein the document is a transaction document 15 relating to the purchase of goods and wherein the document information comprises goods purchase information; the approval or rejection determination comprising:

in response to an indication that the goods of the user correspond to the goods to which the transaction document relates, the portable device reporting an approval determination; and

20 in response to an indication that the goods of the user do not correspond to the goods to which the transaction document relates, the portable device reporting a disapproval determination.

17. A method according to any one of claims 14 to 16, wherein the method comprises, prior 25 to transmitting the report:

the scanner of the portable device scanning a further document;

the portable device displaying further information based on the scanning of the further document; and in response to a further approval or rejection determination, the portable device 30 reporting the further approval or rejection determination.