WO2019194750A1

WO2019194750A1 - System, method and apparatus for facilitating secure transactions

Info

Publication number: WO2019194750A1
Application number: PCT/SG2019/050195
Authority: WO
Inventors: Tie Wee TAN
Original assignee: Tourego Global Pte. Ltd.
Priority date: 2018-04-06
Filing date: 2019-04-05
Publication date: 2019-10-10
Also published as: JP2021520012A; JP7235847B2; KR102469607B1; SG10201802919YA; KR20200128760A

Abstract

A system for facilitating secure and convenient transactions comprising a processor configured to generate or store:- a first device agnostic identifier associated with a consumer; and a second device agnostic identifier associated with a retailer; a user mobile device configured to generate or retrieve the first device agnostic identifier for use in a transaction; a retailer device operable to generate or retrieve the second device agnostic identifier for use in the transaction, the retailer device further configured to access the first device agnostic identifier to generate a verification status; and a transaction device operable to read the verification status to determine if the user qualifies for a type of transaction, and if so, the transaction device sends a notification of the qualified transaction to the retailer device and/or to the processor.

Description

SYSTEM, METHOD AND APPARATUS FOR FACILITATING SECURE TRANSACTIONS

FIELD OF THE INVENTION

The present invention relates to a system, method and apparatus for facilitating secure transactions.

BACKGROUND ART

The following discussion of the background to the invention is intended to facilitate an understanding of the present invention only. It should be appreciated that the discussion is not an acknowledgement or admission that any of the material referred to was published, known or part of the common general knowledge of the person skilled in the art in any jurisdiction as at the priority date of the invention.

In line with tax principle while at the same time attracting tourists, jurisdictions that levy a Value-Added Tax (VAT), Goods and Services Tax (GST) or similar forms of tax would allow individuals such as tourists to claim a tax refund on the goods purchased within a country. This tax refund would typically be administered upon the departure of the tourists from the country; provided certain criteria are met such as the goods are unopened, unused and exported out of the country. The Revenue/Customs authorities of the country can administer tourist refund scheme(s), although it is increasingly popular for commercial contractors to be appointed to administer on their behalf. These commercial contractors typically work in cooperation with the Revenue/Customs authorities to complete tax refund transactions. A service or commission fee may be charged which would form a revenue source for the commercial contractor.

Various methods of administration of tourist refund schemes are currently being operated in the world. Some are labor and paper intensive, including forms and mandatory checks including physical checks at the point of departure by Revenue/Customs officials, and others are based on the electronic capture of transaction data by static devices at a participating retailer’s shop and the use of this data to perform a risk-based selection of transactions for physical checks at approved points of departure.

In relation to the use of static devices, a user (e.g. a tourist) will need to prove his eligibility at an authorized premise for refund. However, this may be subjected to fraud and possible abuse. After proving his eligibility, the user may further need to provide a credit/debit card when purchasing goods and/or services, with the primary account number (PAN) of the credit/debit card used as a token for tagging the purchases entitled for refund.

With the token, the tourist can apply for a tax refund at designated self-help kiosk disposed at specific locations and the self-help kiosk will generate an ‘approved’ or a ‘not approved’ notification. It is appreciable that such designated self-help kiosk may be inconvenient as they can cause delay and the tourist need to spend time searching for the same.

If the refund is not approved by the self-help kiosk, the tourist may need to have his purchases physically inspected by an immigration officer. If the goods pass Customs inspection, the immigration officer would generate a notification indicating“Approved” to replace the“Not Approved” notification. During peak hours, these could become bottlenecks in processing the departing tourists as the customs counter is limited by manpower while the self-help kiosks may be overwhelmed by the number of tourists applying for refunds. Departing tourists typically have to arrive at the immigration departure points earlier to locate these static self-help kiosks in anticipation of a queue.

In addition, additional paper work may be imposed on the tourist to leave the country within a certain time frame or to sign declarations relating to his commitment not to return to the country within a specific time frame after he enjoyed the refund. This cause inconvenience to the tourist.

Even for cases where electronic devices are deployed to reduce labor or alleviate the need for paper, there exist a need to provide improved solution(s) for users, in particular for various parties (tourist, retailers, immigration officers) within a tax refund environment to achieve seamless integration to facilitate the tax refund process in a secure and temper-proof manner.

Existing systems for implementing refund transactions at immigration points are typically consumer targeted (i.e. arranged in a business to consumer model). There exists a need for greater integration between businesses, users and immigration authorities.

The present invention seeks to provide a system and method that alleviates the above-mentioned drawbacks or meet the aforementioned needs at least in part.

SUMMARY OF THE INVENTION

Throughout the document, unless the context requires otherwise, the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Furthermore, throughout the specification, unless the context requires otherwise, the word“include” or variations such as“includes” or“including”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

The present invention seeks to meet the needs of a transaction system, such as a tax refund system that does not rely on physical self-help kiosks located at specific sites, and enables users such as tourists to access their tax refunds efficiently and accurately. Further, the invention seeks to provide a convenient environment for tourists, where verification by retailers and/or immigration officers (e.g. customs) for qualifying transactions are made mobile and simple.

In some embodiments, there is provided a system and method of administration by way of software application(s) installable on different mobile devices to verify a user identity and verify qualifying transactions so as to facilitate a completely paperless tourist tax refund experience, and enable more types of transaction data to be captured for a more complete risk-based selection.

A technical problem the invention seeks to solve relates to the bottlenecks faced by immigration points, such as customs, at peak hour. Another technical problem is associated with the need to verify identities of tourists and transactions, such as purchases against invoices and receipts in a more effective and efficient manner to reduce identity and transaction frauds.

Another technical problem the invention seeks to solve relates to the inconvenience faced by tourists and/or businesses in their interaction with immigration. The invention seeks to provide greater integration between businesses, consumers and government departments so that a seamless transaction could be made. This is achieved in part by providing a centralized system that interfaces with all relevant parities to effect a refund transaction in a safe and secure manner.

In accordance with an aspect of the present invention, there is a system for facilitating secure and convenient transactions comprising a central processor configured to generate or store:- a first device agnostic identifier associated with a consumer; and a second device agnostic identifier associated with a retailer; a user mobile device configured to generate or retrieve the first device agnostic identifier for use in a transaction; a retailer device operable to retrieve the second device agnostic identifier for use in the transaction, the retailer device further configured to access the first device agnostic identifier to generate a verification status; and a transaction device operable to read the verification status to determine if the user qualifies for a type of transaction, and if so, the transaction device sends a notification of the qualified transaction to the retailer device and/or to the central processor.

Preferably, the central processor is configured to generate or store a third device agnostic identifier associated with an public authority, and a corresponding device operable to generate or retrieve the third device agnostic identifier for use in verifying the transaction and the identity of the consumer. Preferably, at least one of the first device agnostic identifier and the second device agnostic identifier comprises a first portion associated with the user, and a second portion generated by the central processor.

Preferably, the type of transaction is a refund transaction and the transaction device is further configured to provide a calculation of a refund of the qualified refund transaction.

Preferably, at least one of the first device agnostic identifier, the second device agnostic identifier, and the third device agnostic identifier is encoded as a quick response (QR) code. Preferably, upon successful verification of the identity of the consumer and the transaction, the user mobile device is utilized to access the third device agnostic identifier.

Preferably, upon successful verification of the identity of the consumer and the transaction, the corresponding government device is utilized to access the first device agnostic identifier.

Preferably, the retailer device is a mobile computer device.

Preferably, the corresponding government device is a mobile computer device.

Preferably, after calculation of the refund, the refund is deducted from a purchase price of the transaction and the notification in the form of a receipt is sent to the retailer device and/or the central processor.

Preferably, after calculation of the refund, the amount of refund is stated in the notification for further verification by the corresponding government device.

Preferably, the mobile user device, the retailer device and the corresponding government device are arranged in a distributed ledger or blockchain environment for verification of one or more refund transactions.

Preferably, each of the mobile user device, the retailer device and the corresponding government device are implemented as a node on the distributed ledger or blockchain.

Preferably, the blockchain is a private blockchain, and wherein the genesis node is the central processor.

Preferably, the retailer and transaction devices are integrated. Preferably, the retailer device comprises a plurality of communication modules disposed at specific locations within a premise of the retailer, the plurality of communication modules comprises transmitter and/or receiver to detect the user mobile device.

Preferably, the calculated refund is deposited into a designated account or electronic wallet of the consumer.

Preferably, a portion of the calculated refund is converted to an intermediate value.

Preferably, the intermediate value includes one or more of the following:- coupons, credits, points, or other electronic value. In accordance with another aspect of the present invention, there is a method for facilitating a secure and convenient transaction comprising the steps of: generating a first device agnostic identifier by a central processor or a user mobile device, the first device agnostic identifier associated with a consumer; generating a second device agnostic identifier by the central processor or a retailer device, the second device identifier associated with a retailer; retrieving, by the user mobile device, the first device agnostic identifier for use in a transaction; accessing, by the retailer device, the first device agnostic identifier to generate a verification status; and reading, by a transaction device, the verification status to determine if the user qualifies for a type of transaction, and if so, the transaction device sends a notification of the qualified transaction to the retailer device and/or to the central processor.

In accordance with another aspect of the present invention, there is a mobile device configured to provide a secure and convenient transaction to a user, the mobile device comprises: a memory block configured to store a first device agnostic identifier, the first device agnostic identifier associated with the user; a communication module operable to interact with a retailer device and a central processor for facilitating a transaction; wherein as part of the transaction, the first device agnostic identifier is accessed by the retailer device to determine an eligibility of the user.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Fig. 1 is the overall architecture of an embodiment of the invention showing how the various parts of the system interact;

Fig. 2 is a flowchart of an embodiment of the invention showing how a user is taken through the system when the application is launched;

Fig. 3 is a state machine diagram of an embodiment of the invention; and Fig. 4 and Fig. 5 show how a single MDCC device may be used for the deployment of tourist refund in accordance with other embodiments of the invention.

Other arrangements of the invention are possible and, consequently, the accompanying drawing is not to be understood as superseding the generality of the preceding description of the invention.

PREFERRED EMBODIMENTS OF THE INVENTION

Particular embodiments of the present invention will now be described with reference to the accompanying drawings. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the present invention. Additionally, unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art to which this invention belongs.

Throughout the description, the term‘device agnostic identifier’ refers to an identifier for the purpose of identifying a user, a group of users or an attribute of the user or group of users. Such an identifier is to be distinguished other types of identifiers, such as, but not limited to, a mobile communications device identifier which is associated with a device such as a mobile phone. Throughout the description, the term‘user’ when used in a general sense is construed broadly to include users such as tourist, consumers of goods or services, retailers, immigration officers, etc.

Throughout the description, the term ‘notification’ may refer to electronic notification sent via different means such as, but not limited to, short messaging system message (SMS), email, in-app notification, push notification, multimedia messaging system message (MMS).

In accordance with an aspect of the present invention there is a system for securing secure and convenient transactions. With reference to Fig. 1 , the system 10 is utilized to facilitate a refund transaction. The refund may be in the form of tax refund provided to a tourist for purchase of goods and/or services in a foreign country and will be described in such a context. It is to be appreciated that the system 10 may be adapted for other types of refunds and not limited to a tax refund. The term‘refunds’ include refund in an electronic medium.

The system 10 comprises a processor 1 10 which may be regarded as a central processor for synchronizing, storing and processing data arising from different parties within the tax refund environment. The parties may include one or more of the following individuals or groups:- tourists, retailers, and government immigration.

The central processor 1 10 may be in the form of one or more server computers belonging to an organisation administering the tourist refunds. The central processor 1 10 may be administered by a private organisation, a government organisation, or a quasi-government organisation. The central processor 110 may include functions of settlement, such as a clearing house 170, or be arranged in data communication with a financial institution 170 or relevant database for the purpose of settlement and crediting of refund transaction.

The one or more servers 1 10 can include a cloud server or a conventional server with data communications capability. For the ease of discussion, the one or more server will hereinafter be referred to as ‘server’ or‘servers’. Server 1 10 may be connected to one or more databases (not shown). Such database(s) are operable to contain records and information relating to the tourist refunds such as name, addresses and/or pre-generated or generated identifiers associated with the users seeking refunds. It is to be appreciated that such generated identifiers are device agnostic and are linked to an attribute of the user. In various embodiments, the generation of a device agnostic identifier may include a combination of a personal identification number with a machine generated code. In some embodiments, the device agnostic identifier may include random generated portions to enhance security and reduce fraud.

Examples of device agnostic identifiers of the user may include one or more of the following attributes/parameters of a user such as:- a passport number, foreign identity number, mobile phone identifier, email address etc.

For enhanced security, the device agnostic identifier generated for the user may be unique, i.e. no other identifiers may be used to identify the same user within the system 10.

In some embodiments, the device agnostic identifier may include a predetermined length of alpha-numeric numbers combining various attributes/parameters of a user.

Server 1 10 is also operable to generate and update refund accounts for facilitating, processing and crediting refunds. Such database(s) are also able to contain records relating to one or more transaction receipt(s) associated with the tourist.

In one embodiment, the system 10 comprises a mobile device 120, preferably endowed with communications and computing capabilities and hereinafter referred to as MDCC 120, and computing device 130 (hereinafter referred to as‘Retailer Device’ 130). The Retailer Device 130 can also be an MDCC or other computing device like a desktop/laptop computer. A transaction device, such as a Point-of-Sale (POS) device/system may be arranged in data communication with the Retailer Device 130, the data communication may be enabled in the form of wired or wireless data communication devices, remotely or otherwise. Alternatively, the POS device or its associated function may be incorporated/integrated with the Retailer device 130 as a module.

To facilitate the refund process, the mobile device 120 and computing device 130 may be installed with dedicated software applications (colloquially known as‘apps’). Such dedicated software applications may be operating system (OS) such as iOS™ or Android™ specific, and/or device specific.

The software application installable on mobile device 120 provides a user interface for user registration and for retrieving or providing information for the refund process. Once installed, the software application is operable to perform at least the following functions:- a. receive registration details entered by the user;

b. communicate with the server 1 10 to send the registration details;

c. receive from the server 1 10 a device agnostic identifier associated with the user (tourist); or generate a device agnostic identifier and communicating the device agnostic identifier to the server 1 10;

d. receive from the server 1 10 information related to the refund process; e. display notifications/alerts on the MDCC 120 relating to refund process; f. provide user interface for user to browse or view account details;

g. search for communication networks for data communication with the server 1 10 and the computing device 130 ; and

h. store, organise and retrieve information received from various parties. The MDCC 120 and the Retailer Device 130 can be any mobile electronic device(s) that can connect wirelessly to Wi-Fi networks or conventional telecommunications networks such as 2G, 3G, 4G, or LTE based networks. The mobile electronic devices include, but are not limited to mobile devices like smartphones, personal digital assistant (PDA) phones and tablets. The devices include mobile devices running on iOS platforms such as the iPhone and the iPad.

The invention will next be described in the context where a user of MDCC 120 (presumably a tourist) downloads a dedicated software application (hereinafter‘software application’) onto the MDCC 120 for registration with the system 10; and usage of the MDCC 120 with the installed software application for facilitating refunds.

During the first usage after downloading the dedicated software application, a registration process is initiated where the tourist is prompted to register by entering his or her registration details into the application. The tourist may enter the necessary details for registration via manual entry or via imaging the identification documents associated with the tourist, if the MDCC 120 comprises an imaging device or module such as an on-board camera. The identification documents may include passport or other approved identification papers identifying the user as a tourist. In the case of a passport that comprises a machine readable zone (for example barcode), the MDCC 120 may also be used for reading the readable zone on the passport using an image capturing device, such as an on-board camera or if the MDCC 120 is installed with the necessary hardware and/or software for reading the passport. An example of such hardware or software may be an optical character recognition (OCR) module and/or barcode/QR code reader module. For example, the MDCC 120 may obtain an image of the passport stored in a memory of the MDCC 120 or external database, and read the image of the passport as the registration details.

The registration process can further integrate a verification of the authenticity of passports. The registration process can also include a check against records or entries in one or more authorized databases (for example government immigration records) to ascertain the eligibility of the tourist for a tax refund. Such authorized databases may be public or private databases. Such databases may further be distributed. With these verifications, the tourist may not need to carry his passport in order for the retailer to verify his tourist status, subject to regulatory acceptance of such method of verifications.

In some embodiments, the MDCC 120 may utilise one or more biometric identifiers data such as, but not limited to, fingerprint, handprint, facial recognition, voice recognition, retinal scan, iris scan for added security. In some embodiments, the MDCC 120 may extract the biometric identifier data stored in a memory unit of the MDCC 120 or an external database for the verification. In some embodiments, the MDCC 120 may obtain the biometric identifier data from the tourist for verification upon initiation of the registration process. The MDCC 120 can then verify the biometric identifier data against records or entries in one or more authorized databases (for example government immigration records). In other words, the biometric identifier data function as a second layer authentication in conjunction with the device agnostic identifier.

In some embodiments, the tourist may provide the relevant account numbers or register his/her credit/debit card or digital payment wallet during the point of registration. In this manner, the tourist can save time and/or effort during the check-out at the airport (for example, an airside).

Upon receiving the registration information, the MDCC 120 next sends the registration information to the server 1 10 for the creation of a user account. In the case where the server 1 10 generates the device agnostic identifier, once the user account is created, the server 1 10 communicates the device agnostic identifier to the MDCC 120. Otherwise the MDCC 120 communicates the device agnostic identifier to the server 1 10.

The device agnostic identifier can be in the form of an assigned account number. In some embodiments, the identifier can be encoded into a Quick Response (QR) code by the server 1 10 or a software application installed on MDCC 120. The QR code is a type of matrix barcode that is machine readable and can contain information that can quickly be translated into usable data. Once the device agnostic identifier is generated, the device agnostic identifier can be accessed on the same MDCC 120 used to register the user or on any other mobile devices that is compatible with the form or physical medium that the identifier is encoded. In this regard, the identifier is therefore device agnostic, and independent from any device(s) utilized or used by the user as it is tied to the identity of the user.

In some embodiments, different portions of the device agnostic identifier may be generated by one or more server computers, distributed, or otherwise. The identifier may comprise different portions generated by different processors/servers to enhance security.

Other types of machine readable codes like barcodes can also be used in place of QR codes, although these may hold less data. This QR code is tied/tagged to each and every tax refund qualifying transaction made by the tourist.

It is to be appreciated that the identifier may include a simple account number, and/or a combination/hybrid of one or more of the above described codes. Once registered and a user account is in place, the tourist user may then make tax refund qualifying transactions such as tax refund qualifying purchases at one or more participating retailers.

It may be appreciated that the server 1 10 may provide participating retailers’ information via the software application when the tourist is near any participating retailer’s premise. Such information may be in the form of dining, shopping and sight-seeing spots prompted as notifications on the MDCC 120. In some embodiments, the MDCC 120 (via a location based service or hardware module) may detect the location of the tourist and display the participating retailers’ information and/or local information based on the detected location.

After the tax refund qualifying purchase is made at a participating retailer, the tourist retrieves his or her identifier, in the form of a QR code, for display on the MDCC 120. The participating retailer uses the Retailer Device 130 to scan the QR code (s140) for verification on the eligibility for a tax refund by checking against the server 1 10 to ascertain if the tourist has a registered account and is eligible for a refund. As an example, the step of checking will include comparing and matching entries with the server 1 10 and/or its associated processor(s) or database(s) to determine if the passport is a foreign passport and if the tourist is at an age eligible for refund (e.g. 16 years or older). The server 1 10 can also perform a check against government immigration records via the government server to ascertain the eligibility of the tourist for a tax refund. Alternative ways of identifier accessing technology or combinations may be used. Examples of such technologies may include Near Field Communications (NFC), Bluetooth, Wi-Fi, etc. as known to a skilled person. The identification may also be manually entered into the Retailer Device 130. Such a step of verification may include checking the physical passport and the passport information/details submitted, subject to compliance with the necessary regulatory requirements. Upon scanning of the identifier, the participating retailer may enter the purchase/transaction details related to the purchase made by the tourist into the Retailer Device 130. The transaction details may be manually or automatically transmitted. In the latter, the transaction details may be transmitted automatically via a cable or wirelessly from a Point-of-Sale (“POS”) system and/or POS device, the POS device configured to send the information relating to the refund qualifying transaction, i.e. purchase/transaction details to the Retailer Device 130 and/or server 1 10. For example, to facilitate the transmission, a software driver may be installed on the POS system for detecting the Retailer Device 130 as a printer, so that the POS device can print the transaction details to the Retailer Device 130. Alternatively, software may be installed on the POS device or system to capture the transaction details from a payment screen via an Optical Character Recognition (OCR) module. In the case of an Internet-enabled POS system or device, the purchase or transaction details can be directly transmitted to the server 1 10 via one or more wired or wireless communication means. The transaction details may then be accessible via a web resource locator or link, such as a Uniform Resource Locator (URL). It is appreciable that an access to the URL by any other devices which has not been registered with the server 1 10 may be restricted.

If a paper receipt is issued for the transaction, the Retailer Device 130 may also be used to image or scan the paper receipt associated with the transaction for the transaction details to be extracted by an image conversion and/or recognition module, such as, for example the OCR module. Once the retailer has verified the transaction details thus captured, he can transmit the transaction details to the server 1 10 via the Retailer Device 130. In another embodiment, the MDCC 120 may be used in place of the Retailer Device 130 to image or scan the paper receipt associated with the transaction. Once the retailer has verified the transaction details thus captured, he can present the tourist with a retailer identifier, which can be another QR code, unique to a retailer premise, for scanning by the MDCC 120, as a form of retailer confirmation/receipt.

In some embodiments, the retailer identifier may be device agnostic. The device agnostic retailer identifier may be generated by the processor 1 10, or a retailer application installed on the retailer device 130. In some embodiments, a retailer identifier may be linked to one retailer premise. In other words, the retailer identifier may be associated with a premise providing goods and services, regardless of number of retailers or personnel working in the premise. The device agnostic identifier for the retailer can be shared between the different personnel in the premise. Such an arrangement offers flexibility.

In other embodiments, there may comprise multiple retailer identifiers, each retailer identifier linked or associated with a corresponding personnel. It is appreciable that where there are multiple retailer identifiers, the rights and powers associated each retailer identifier may be configured by the central processor 1 10, or an assigned administrator. Such rights and powers may include rights and powers to verify and/or approve verifying transactions. For example, a retailer identifier associated with a cashier may be able to approve transactions of up to certain amount, after which a manager’s device (which may be temporarily associated with the manager retailer identifier) is required. In another embodiment, if a user is unable to present his identifier in the form of a QR code (for example because the user has not yet registered with the server 1 10), the retailer may scan an alternative identifier, such as but not limited to the Tourist’s passport to retrieve his account information. The scanning device may be the Retailer Device 130 or in the form of a barcode scanner or other imaging device and once the passport has been scanned, the server 1 10 checks if the tourist has a registered account and eligible for a refund, e.g. if passport is a foreign passport and if tourist is at an age eligible for refund (e.g. 16 years or older). The server 1 10 can also perform a check against third party servers or databases, such as government immigration records via the government server to ascertain the eligibility of the tourist for a tax refund. If the tourist is not eligible, the server 1 10 prompts an authorized personnel (e.g. a cashier) to inform the tourist that he is not eligible for tourist refund. If the tourist is eligible, the server 1 10 checks for an existing account by comparing the scanned details with one or more databases of the server 1 10. If a user account already exists, the software application installed on the retailer device 130 is operable to display the user profile or details for validation by the cashier. If the tourist present before the cashier matches the user profile, then the cashier confirms the user (customer) identity via a user interface and proceeds to enter receipt details. If a user account does not exist for the tourist, the server 1 10 creates a user account and the cashier proceeds to enter receipt details.

The Retailer Device 130 (or the MDCC 120) is operable to send the identifier, as well as the transaction details like the cost, the receipt number, the date and time of the transaction, etc. (see s150) to the server 1 10. No transaction details can be transmitted without the necessary information associated with the identifier (in the form of QR code) on the MDCC 120 (or on the Retailer Device 130). To minimize fraud, the Retailer Device 130 can be configured (by the retailer or otherwise) to halt all communications outside of the retailer’s opening hours. This would prevent unauthorised tax refunds claims from being entered into the system 10. The security of the system 10 can be further enhanced by a password management system that requires the cashier to log into the retailer account and may require the password to be changed regularly. Sub-accounts may also be created for individual employees of the retailer who are responsible for collecting payment and their supervisors to create a system of checks-and-balances for approving unusual tax refund claims. Prior to use, the retailer account may undergo a similar registration process as described earlier for the user (tourist) account. In some embodiments, the registration process entails the server 1 10 assigning or issuing retailers with user identifiers (IDs) and passwords. A manager of the retailer may create sub-accounts. Alternatively the server 1 10 may assign subaccounts to the retailers, who in turn have administrative rights to manage the sub-accounts. Similar to the registration of the user account, a retailer identifier such as a QR code may be generated and assigned to each retailer who registers for an account to participate in the system.

Based on the details sent by the participating retailer, the server 1 10 sends a notification of transaction. Such a notification may be in the form of an electronic ticket (containing the details mandated by the Revenue/Customs authorities such as a documentary identifier that uniquely identifies a transaction) directly to the MDCC 120, thus recording the purchase as an eligible transaction. The server 1 10 would also notify the participating retailer via the dedicated software application installed on the Retailer Device 130 of the electronic ticket (see s150).

The MDCC 120 is operable to image, store and organise the purchase receipts and invoices issued by the participating retailer, and link these with the eligible transaction for ease of subsequent retrieval by the tourist or by an inspector of the Revenue/Customs authorities. The server 1 10 will transmit the transaction details as required by the Revenue/Customs authorities to the settlement facility 170 for lodgement as an eligible transaction 180.

In another embodiment, the server 1 10 can also request the settlement facility 170 to perform a risk assessment after each transaction, and communicate 180 the risk assessment results to the server 1 10. If the result is such that the tourist is selected to present his or her purchases for inspection by an officer of the Revenue/Customs authorities at the point of departure from the country, the server 1 10 would then notify the tourist of this requirement via the software application installed on the MDCC 120 either shortly after the transaction itself and/or at the point of departure from the country (s160). This early deterrence would assist to deter potential fraudsters from trying to obtain a tax refund through fraudulent means.

With additional tax refund qualifying purchases, multiple electronic tickets associated with multiple eligible transactions can be sent to the MDCC 120 in the same direct way (s160).

When the tourist is leaving the country, the MDCC 120 or the dedicated software application installed on the MDCC 120 would request for confirmation of departure from the tourist. Once the tourist confirms his departure from the country, the tourist can request for a refund together with a declaration of eligibility (a requirement by some Revenue/Customs authorities) or other declarations as required by the Revenue/Customs authorities (s160). The tourist may be guided through the declaration of eligibility process by the application on the MDCC 120, which also displays the passport details of the tourist for his or her confirmation as the person making the declaration. Purchases recorded as eligible transactions are also displayed for the tourist to select those for which he or she would like to submit a claim for tax refund. For tax refundable purchases made through retailers that do not operate the application, the application on MDCC 120 can scan a paper copy of the electronic tickets issued by these retailers so that all the transactions are consolidated. The application then recognizes the information on the ticket. For example, the application may decode QR code and/or barcode on the Ticket and regenerate relevant information so that all the transactions are consolidated. Alternatively, the settlement facility 170 can also transmit electronically, the details contained in the paper tickets, to MDCC 120, upon request by the MDCC 120 or the dedicated software application installed on the MDCC 120. The tourist would also confirm the preferred refund option - whether in cash or credited to a credit/debit card account or a bank account or even an electronic wallet account - and the dedicated software application guides the tourist to confirm the relevant details accordingly. The preferred refund option and details may have already been entered at the point of user registration, otherwise the tourist will be prompted to do so. The tourist may also enter the necessary details via manual entry or via imaging the credit card via the on-board camera on MDCC 120, for example.

Once the various fields are completed, the application can allow the tourist to confirm the details one last time before submitting them to the server 1 10.

In addition to the tourist proactively initiating a request for refund, one way of reminding the tourist to submit the request for refund would be to use a location-based service, such as Global Positioning System (GPS), geo fencing, navigation systems etc., to alert the MDCC 120 when the MDCC 120 is detected within range of an approved departure point/location installed with a location-based service device, examples of such departure points including, but not limited to, an airport, bus terminal, train station, port or space station. This would notify and remind the tourist to submit the request for refund. Alternatively, the application on the tourist MDCC 120 can also rely on Wi-Fi networks or cellular base stations at the approved departure points to notify the tourist when the MDCC 120 accesses these networks. Alternatively, the MDCC 120 can detect transmitters and/or receiver (including but not limited to Bluetooth Low Energy (BLE) beacons) located at the approved departure point(s), and trigger the application to remind the tourist. This saves the tourist the trouble of having to arrive at the airport early to locate the self-help kiosk, since the tourist can now submit the request using his or her MDCC 120.

Once the request for refund is submitted (s160) to the server 1 10, the settlement facility 170 is notified via s180 and can communicate to the server 1 10 as to whether the tourist has been selected for inspection by the Revenue/Customs authorities and the server 1 10 notifies the tourist via the MDCC 120 accordingly (s160).

For tourists who have not been selected for inspection, they would receive a digitised Notification of Approval on their MDCC 120. Those who have not received a notification of approval and/or have been selected for inspection either at any point of purchase or after the submission of the request for refund would receive a digitised Notification of Inspection prompting them to proceed to a counter of the Revenue/Customs authorities for further processing. There, upon presenting the digitised tickets, invoices/receipts and notification stored on the tourists’ MDCC 120 together with the goods purchased, passport and plane ticket, as required, an authorized personnel such as the Revenue/Customs officer or inspector updates the record stored at the settlement facility 170. This may be performed via a separate computing device provided to the customs officer having a dedicated software application installed thereon and arranged in data communication with the server 1 10 to interact with the server 1 10.

In some embodiments, a‘customs officer’ identifier in the form of a QR Code may be provided to the customs inspector to present to the tourist after the customs inspector is satisfied with the eligibility of the tourist and the purchases for a refund. The tourist may then scan the customs’ officer identifier using his or her MDCC 120.

In some embodiments, the customs officer may hold a customs device provided or supported by the system in accordance with some embodiments of the invention or disclosure. The customs officer may scan the tourist’s identifier, for example QR code, and retrieve relative information from the server of the system. Then, the tourist’s identifier may be checked and approved on the customs device directly. The tourist may be notified via a tourist application or program once the tourist’s identifier is approved.

In some embodiments, the customs officer identifier may be device agnostic. However, it is appreciable that a single custom officers’ identifier may be associated with a plurality of customs officers. In other words, the custom officers’ identifier may be a common identifier for customs’ use.

In some embodiments, the device agnostic identifier(s) of the customs officers may be generated by the central processor 1 10 or pre-determined by an administrator amongst the customs officers.

In other embodiments, there may comprise multiple customs officers identifiers, each customs identifier linked or associated with a corresponding customs officer. It is appreciable that where there are multiple customs identifiers, the rights and powers associated each customs identifier may be configured by the central processor 1 10, or an assigned administrator. Such rights and powers may include rights and powers to verify and/or approve verifying transactions. For example, a customs identifier associated with a supervisor customs officers may be required to verify goods/services of above certain value.

Upon scanning of the QR Code, the server 1 10 then updates the settlement facility record as“Approved” and issues a Notification of Approval.

This Notification of approval may be in paper, or digitised and sent to their MDCC 120.

Once the notification of approval is sent to the MDCC 120, a full refund or portion thereof may be credited to the tourist immediately on a real time basis if the tourist has provided the relevant account numbers or has registered his/her credit/debit card or digital payment wallet. The progress of the refund may also be notified to the tourist in the form of one or more notifications.

In other embodiments, the refund may be credited to the tourist after the tourist left the country. The software application can detect that the user has left the country based on the location information retrieved from the MDCC 120 or information received from authorized databases (for example immigration records). In another embodiments, the user can scan a QR code or barcode displayed at an approved departure point such as an airport (for example, an airside) so that the software application can detect that the user is ready to depart the country. In another embodiments, the software application can detect transmitters and/or receiver (including but not limited to BLE beacons) located at the approved departure point such as the airport (for example, the airside). Once detected, the refund may be credited to the tourist’s designated account or the registered credit/debit card or digital payment wallet.

It is to be appreciated that in some embodiments, since the tourist may receive the refund into the tourist’s mobile payment account (e.g. electronic wallet), the tourist may not be required to go to a Central Refund Counter (CRC), hence omitting an additional step. With the mobile refund, each refund company can just refund directly into the tourist's mobile payment account.

It may also be appreciated that if the tourist opt for a cash refund option, where available cash refunds can be made at the CRC upon presentation of the Notification of Approval. The tourist would then proceed to depart the country (territory) accordingly.

In some embodiments, instead of crediting the refund into a designated account, the refund value or a portion thereof may be converted to an intermediate value. Examples of such intermediate value may be coupons, credits, points, or other electronic value etc. One embodiment of an intermediate value is in the form of ‘rewards points’. The rewards points can be implemented as part of the tourist refund process so that it can be applied towards the purchase of goods and services at participating retailers. Retailers participating in this system of rewards points can be the same ones that are accredited under the tourist refund scheme or retailers that are not accredited but can also be equipped with a Retailer Device 130. Tourists can accumulate rewards points issued by the central processor 110. In the conversion of tax refund to rewards points, the system may refund the full amount, less than or more than the full amount of tax levied depending on the conversion rate between the tax refund to rewards point, instead of withholding a service fee as in the traditional method, although a service fee can still be offered as an alternative. The system can offer the tourist the option to take the refund in the form of tourist refund (whether as cash or via a credit/debit card) or in the form of rewards points, by way of a prompt either at the point of purchase or at the point of departure from the country. The tourist could even be allowed to convert the tourist refund into rewards points (vice versa) at any point in time, with or without a conversion fee. There may be a point in time where the availability of a tourist refund by way of cash or credit card is reduced or even removed. The rewards points can also be tagged with an expiry date, such that they expire if not used within a certain period of time, or the rewards points may be issued without an expiry date.

In some embodiments, the refund may be credited to the tourist’s designated account or the registered credit/debit card or digital payment wallet at the retailer. It may be appreciated that the registered credit/debit card or digital payment wallet may be used as an authorisation means or insurance means to mitigate the system’s risk in cases where the tourist does not complete the tax refund process at the airport after receiving reward points via the intermediate value system or receiving instant refund at the retailer. For example, after the refund is credited to the tourist’s credit/debit card or digital payment wallet at the retailer, if the tourist fails to depart the country within the required period of time, the tourist and/or goods are found not to be eligible for tax refund, and/or the tourist does not follow through the tax return process at the airport, the credited refund may be charged on the registered credit/debit card or digital payment wallet. For example, the credited refund may be recharged by the registered credit/debit card or digital payment wallet.

It may be appreciated that the software application installed on MDCC 120 may include instructions to notify the tourist to claim his/her refund on a date of departure or upon detection of proximity of the approved departure point via sensors and/or location based service. The software application may monitor the status of refund claims after the tourist has submitted the tax refund application. The software application may communicate with a CRC and/or the payment platforms to monitor the status of the refund claims. Further, the software application may notify the tourist of the present status of the refund claims (e.g. whether partially completed or in progress).

If there is any further action required, the software application may notify the tourist of the further action. For example, if the tourist’s account information for the payment platform is invalid or incorrect, the software application may provide a notification to prompt the user for corrective action. In other embodiments, the MDCC 120 may extract the user’s valid or correct account information from a memory of the MDCC 120 or external database, and provide the valid or correct account information accordingly without the user manual intervention.

It may also be appreciated that the software application may further include a user interface which can be presented in different languages. The software application may set a default language based on the tourist’s setting, tourist’s nationality and/or current country. In some embodiments, multiple languages, for example, one language is set by the tourist and the other language is the current country’s official language, may be presented together. In this regard, the tourist can communicate easily with the immigration officer of the current country while viewing the software application screen.

It is to be appreciated that the tourist may claim tax refund for services in countries which allow services to be eligible for tax refund.

At a participating service shop, for example hotel, clinic or hospital, the tourist makes a purchase and the retailer enters or scans the relevant details into the point-of-sale (POS) machine. After verifying that the service purchases qualify for refund and the eligibility of the tourist by checking the tourist’s passport, the retailer scans the identifier being displayed on the MDCC 120. Once verified and the records updated, a confirmation of the transaction is sent together to the retailer and an electronic refund ticket is sent to the MDCC 120. An electronic image or document of the invoice or receipt issued by the retailer can also be stored in the software application.

Unlike the goods, since services are intangible, the retailer may issue a certificate of the service purchase to the tourist. It is to be appreciated that in some countries the certificate may be replaced with the invoice or receipt. The certificate may be provided in the form of hard copy or soft copy. Such a soft copy may be provided in the form of at least one of an in-app notification, push notification, SMS, MMS and email. The MDCC 120 and/or an external database for the software application may store the soft copy of the certificate. At the point of departure from the country, if the tourist is selected to prove his or her service purchases for inspection by an officer of the Revenue/Customs authorities, the tourist may present a hard copy and/or a soft copy of the certificate. It may be appreciated that the software application may display the soft copy of the certificate with the electronic refund ticket when the tourist is undergoing the inspection.

With reference to Fig. 2, an embodiment of a process for facilitating a tourist refund, wherein like numerals reference like parts, is described. The process begins when the dedicated software application installed on MDCC 120 is launched (step 210). The process begins with checking whether a user (i.e. a tourist) is already registered or is a new unregistered user (step 220). If the tourist is not registered, the tourist is walked through with a registration procedure (step 230) where an electronic user account is created with the server 1 10 and the relevant details are captured by the dedicated software application. Backend, the system 10 performs checks against details like passport number, nationality, name and/or other relevant information to ensure duplicate records are not created. The system can also verify the authenticity of the passports based on their security features or the server 1 10 may be linked with one or more third party servers. The third party servers may be private, public or government databases for the checking of stolen passports, as well as checking for other eligibility criteria such as whether the user does not fall under the category of ‘tourist’, therefore ineligible for tourist refund; or whether the user has entered a territory on a visit pass that may not strictly fall under a‘tourist pass’, such as a student pass, etc. whereupon additional criteria have to be fulfilled.

For each user account, a device agnostic identifier like a QR code is created and stored by the application, or created by the server 1 10 and stored by the application. This process can be integrated with the on-board camera of the mobile device 120 to scan the machine readable zone of the passport to populate the various details or even to scan the passport itself with optical character recognition, or else manual entry of the details is used. The tourist is also given the option of imaging the passport, guiding him through the process of which page to capture, so that he does not have to carry a physical passport when shopping to claim a refund.

At a participating retailer premise, the tourist makes a purchase and the retailer enters or scans the relevant details into the point-of-sale (POS) machine (step 240). After verifying that the purchases qualify for refund and the eligibility of the tourist by checking the tourist’s passport, the retailer scans the identifier being displayed on the user MDCC 120 by either using the issued retailer device or the retailer’s own mobile device with the application installed (step 250). One method of verifying the status of the tourist would be verification upon scanning the QR code via an on-board camera (where available) if the retailer is using a mobile device as the retailer device 130, whereby upon receipt of the scanned information (which includes the identifier), the server 1 10 would inform the retailer device whether the user is a tourist or not, which dispenses with the need to check the physical passport. The details of the transaction are then sent to the central server 1 10 (step 260), and this may be further sent to settlement facility 170. Once verified and the records updated, confirmation of the transaction is sent (step 270) together to the retailer and an electronic refund ticket is sent to the tourist either in the application, by email or any other forms of messaging. An electronic image or document of the invoice or receipt issued by the retailer can also be stored in the mobile application for later retrieval.

In some embodiments, the MDCC 120 may scan or capture an image of the paper invoice or receipt associated with the transaction using the on-board camera. Once a paper receipt is scanned, an image of the receipt may be generated.

As an example, the software application may display an icon for scanning the paper receipt on the software application execution screen. If the icon is inputted, the software application may control the camera to scan the paper receipt. The software application may then detect that the image of the receipt is related to the tax refund.

As another example, while the software application is operated as a background application, the tourist can execute a camera application. Once a scan icon on the camera execution screen is inputted or a scan button is actuated, the camera scans the paper receipt. The software application executed in the background may then detect that the image of the receipt is related to the tax refund.

Thereafter, the software application may insert and/or modify a key value in the image of the receipt, so that the image of the receipt can be classified or differentiated from other stored images and be stored accordingly.

For example, once the image of the receipt is generated, the software application may create a new folder relating to the software application in a memory of the MDCC 120, and may store the image of the receipt in the created folder. If the folder relating to the software application has already been created, the software application may store the image of the receipt in the folder. It should be appreciated that the image of the receipt can be stored in an external database provided by an application provider of the software application.

It is to be appreciated that the software application may delete the image of the receipt from the memory and/or the external database after a pre determined period. For example, the image of the receipt may be deleted once the tourist leave the country.

The MDCC 120 may extract the transaction details contained in the image of the receipt by Optical Character Recognition (OCR). Once the transaction details are extracted, the software application may insert and/or modify a key value in the image of the receipt. This key value may relate to the transaction details.

The e-TRS Ticket may be sent to the tourist either in the software application, by email or any other forms of medium such as short-text messaging. It should be appreciated that the e-TRS Ticket contains information associated with the relevant transaction details. The software application may detect and extract the information contained in the e-TRS Ticket, and match the information with the stored image of receipt using the key value.

It should be appreciated that the software application may store the e-TRS Ticket in relation to the corresponding image of receipt.

For example, e-TRS Ticket may be displayed with an image object for displaying the corresponding image of the receipt on the software application execution screen. The image object may include, but not be limited to, icon, widget, shortcut and thumbnail. If the image object is touched or pressed, the corresponding image of the receipt can be extracted and displayed. It allows the tourist to facilitate an inspection in case a customs officer requests the inspection at the departure point.

The e-TRS Ticket can be stored in at least one of the memory, e.g. in said folder, and an external database provided by the application provider. It is to be appreciated that the software application may delete the e-TRS Ticket from the memory and/or the external database after a pre-determined period. For example, the image of the receipt may be deleted once the tourist leave the country.

With some newer POS machines, the purchase details can be transmitted to the retailer device, either wirelessly via Wi-Fi or Bluetooth, or by a cable like a USB or similar, which speeds up the process and reduces the possibility of human error. The purchase details can even be directly transmitted to the server 1 10 in the form of a central processor. The added security measure of requiring the identifier before transmitting means the possibility of non- genuine tourist transactions is reduced. The tourist or the retailer may also use his or her mobile device to image the paper receipt associated with the transaction for the transaction details to be extracted by Optical Character Recognition. The retailer may also be equipped with other devices with imaging or scanning capabilities. Where the details are captured by the tourist’s device, once the retailer has verified the transaction details thus captured, he can present the tourist with an identifier, which can be another QR code, unique to the retailer, for scanning by the tourist’s device, as a form of retailer confirmation. The application (and server 1 10) is also able to track the fulfilment of certain jurisdictional requirements where the purchases made by the tourist are submitted to the server are logged into the system. This feature is available where the tourist images receipts and enters the necessary details relating to the transactions he made. For example, in some jurisdictions, in order to qualify for a tax refund, a predetermined amount must be spent from retailers bearing the same GST registration number and this can be accumulated in up to 3 same-day invoices or receipt, thus the application can immediately alert the user, whether tourist or retailer, if this minimum amount has been reached on the same day. This does away with the current need to check physical receipts and sum them up.

An additional feature of using a system of intermediate value in the form of rewards points as described in the earlier embodiment can be incorporated into the process. During the purchase (step 240), the tourist informs the retailer that he wishes to use his rewards points, and upon scanning the device agnostic identifier (e.g. QR code) on the tourist’s MDCC 120 (step 250), the rewards points balance is retrieved from the server and displayed to the retailer. Based on this amount and confirmation from the tourist via the tourist’s MDCC 120 (step 250) of the number of rewards points to redeem, the retailer would apply the rewards points against the purchase price accordingly and update the server (step 260). In another embodiment, during a purchase (step 240), the tourist who wishes to utilize his intermediate value in the form of rewards points may launch the software application installed on the MDCC 120 to retrieve from the server and display the rewards points balance information. The tourist can inform the retailer of his intention to use his rewards points and scan an identifier, which can be another QR code, unique to the retailer before entering and confirming the number of rewards points he wishes to use, for transmission to the server. The server can then push the number of rewards points to be thus used for display on the issued retailer device or the retailer’s own mobile device with the application installed, and the retailer would apply the rewards points against the purchase price accordingly and update the server (step 260). Upon receipt of the electronic refund ticket in the application, the tourist can be prompted to choose whether to convert the amount, with or without a service charge to the central processor 1 10, into the rewards points. This raises the possibility of the tourist being able to spend his tourist refund at participating retailers even before leaving the country.

A flowchart shown in Fig. 3 describes an embodiment of how the tax refund is credited/made to the tourist when the tourist is departing the country. At an approved departing point, the installed application on the MDCC 120 is launched by the tourist either on his own volition or reminded by notifications displayed on the mobile device 120. Such notifications can be triggered by detecting that the tourist is at the approved departure point. The tourist is then prompted to confirm that he is departing the country (step 310), which triggers the system 10 (either via the installed software application or the server 1 10) to notify the tourist of the purchases made to date, the electronic refund ticket collected, the amount of refund available, as well as the amount of outstanding refunds which may be in the form of an intermediate value as described. The tourist also indicates how the refund is to be made, either in cash or to the credit card account that was used (based on the purchase or transaction details), or to a specified bank account or even to another different credit card account. A further prompt whether to convert the refund available may be triggered to allow the tourist to do so.

Once the list of purchases is confirmed and verified by the tourist, the tourist is guided through the various steps of completing the Declaration of Eligibility and displays the tourist’s passport details for confirmation. After confirmation, the declaration of eligibility and refund claims are submitted to the server (step 320) and to the settlement facility and confirmation is sent to the tourist (step 330), together with either an approval Notification or an inspection Notification if the tourist has been selected for inspection. If the inspection is verified and cleared, an approval Notification is issued to the tourist, and based on the approval Notification, a refund can be obtained (step 340) either in cash at the Cash Refund Counter at the approved departure point, or credited back to the specified credit/debit card or bank account. Alternatively, the tourist can also choose to obtain the refund in the form of an intermediate value such as the rewards points, especially if he plans to visit the country again sometime soon. The tourist then departs the country (step 350). The Declaration of Eligibility can be submitted together with the refund claims via the application on the mobile device, which means that process is simplified and the tourist can do so at their own convenience, e.g. while queuing to check in or clearing immigration or even in the transport on the way to the airport.

As described above, the device agnostic identifier that is used to identify each tourist, and the identifier of a tourist is distinguished from one or more device identifiers. Therefore, a plurality of tourists, for example, a first user and a second user, may be assigned a corresponding first identifier and a corresponding second identifier, regardless of their MDCC 120.

In some embodiments, the first and second users can use the same MDCC 120 installed with the software application. The first and second users may go through with registration procedure on the software application installed in the single MDCC 120. The software application may manage transaction details in respect of each device agnostic identifier.

In some embodiments, when the software application is launched on a device, the software application may display a plurality of identifiers on the screen. In another embodiments, the software application may display one or more identifier(s) for one or more user(s) who have logged into the software application. The retailer can then scan one of the plurality of identifiers as requested by the first and/or second users.

In some embodiments, the software application may analyse transaction history for the plurality of users, and display at least one identifier based on the transaction history. For example, if the software application detects that the first user tends to purchase cosmetics and the second user tends to purchase clothes, the software application can automatically display an identifier of the first user in a cosmetic shop. It is also to be appreciated that the software application can display the plurality of identifiers together and highlight the identifier of the first user in the cosmetic shop. It should be appreciated that the single MDCC 120 may have a multi-user mode function which allows each user to access the single MDCC 120 in each user’s mode. Applications and data are classified according to relevant users, so the software application can be installed in the single MDCC 120 in a first user mode and second user mode respectively. It should be appreciated that generated data, e.g. transaction details, can be classified and stored as the data of the particular user mode by assigning key values associated with the particular user mode. For example, in a first user mode of the single MDCC 120, when the software application is launched, the identifier of the first user can be displayed. When the first user purchases and then the electronic refund ticket is received, the software application inserts a key value associated with the first user mode in the electronic refund ticket to classify the electronic refund ticket from other electronic refund tickets for the second user.

It is to be appreciated that using the single MDCC 120, e.g. tablet or mobile phone, by a plurality of users allows the users to save their data roaming costs. The software application in accordance with the embodiments of the present invention is able to classify and manage data according to relevant users, to allow the users to have a seamless experience for tax refund procedure while they save the data roaming costs.

In another embodiment of the present invention, the software application can be operated according to the requirements of different countries. The software application may interact with a location based module within the device the software application is installed on to determine which country or region the tourist is at.

As one example, in some countries having a tax exemption scheme, the tax is exempted from the purchase price when the tourist purchases goods. Once the tourist performs a transaction, the retailer issues an electronic refund ticket to the tourist. Also, the retailer issues and/or keeps the electronic receipt. At the departure point, the tourist may undergo an inspection and submit the electronic refund ticket to the Revenue/Customs authorities. The software application can notify and/or guide the tourist to go for the inspection by a Customs officer.

It should be appreciated that for the countries implementing the above scheme, the software application may provide a deposit system to recover a loss of tax by an ineligible tourist. For example, the tourist may register his credit/debit card PAN and provide a credit deposit. If the tourist is not eligible for the tax refund, the tax will be accounted for by the registered credit/debit card. In another example, partial tax may be exempted from the purchase price. In this case, after the inspection at the departure point, a remaining tax may be refunded to the eligible tourist.

In the event if the Revenue/Customs authorities deny the tax refund, for example the tourist is not eligible for the tax refund, the denied amount may be charged to at least one of the tourist and the retailer. The denied amount may be reflected in the retailer’s tax returns.

As another example, in some countries having a scheme where the retailer reimburses a third party refund agency (which may be arranged in data communication with the central processor 1 10), the tourist pays the tax together with the purchase price when the tourist purchases the goods. The retailer issues an electronic refund ticket to the tourist. The software application can assist the retailer to issue the electronic refund ticket to the tourist’s MDCC 120. It should be appreciated that this scheme may include an instant refund to the tourist.

Likewise, at the departure point, the tourist may undergo an inspection and submit the electronic refund ticket to the Revenue/Customs authorities. Also, the software application can issue an electronic certificate of remittance (COR) to the retailer after making refund to the tourist. It is to be appreciated that if the Revenue/Customs authorities deny the tax refund, for example the tourist is not eligible for the tax refund, the denied amount may be charged to the tourist.

As another example, in some countries having a scheme that the government reimburses the third party agency or central processor 110 directly, the tourist will pay the tax together with the purchase price when the tourist purchases the goods or services. The retailer issues an electronic refund ticket to the tourist upon purchase. The software application can assist the retailer to issue the electronic refund ticket to the tourist’s MDCC 120. It should be appreciated that this scheme may include an instant refund to the tourist.

Likewise, at the departure point, the tourist may undergo an inspection by customs and submit the electronic refund ticket to the Revenue/Customs authorities. It is also to be appreciated that if the Revenue/Customs authorities deny the tax refund, for example the tourist is not eligible for the tax refund, the denied amount may be charged to the tourist.

In another embodiment of the present invention and with reference to Fig. 4 and 5, wherein like numerals reference like parts, the functions associated with the MDCC 120 and retailer device 130 may be integrated into a single MDCC device 420. Such an arrangement is advantageous in the sense that one single MDCC 420 may be utilized for the whole refund process. It is to be appreciated that either:- the associated functions described for both mobile device 120 and computing device 130 as earlier described would have to be implemented on the MDCC 420, or another dedicated software application incorporating essential functions for mobile device 120 and the computing device 130 would have to be installed on the MDCC 420.

In the single device arrangement, the participating retailer’s premises may be equipped with a transmitter and/or receiver (including but not limited to BLE beacons) 410 operable to transmit to/receive from a MDCC 420 (used interchangeably with the term ‘single device’) within range of the transmitter/receiver.

An example of the single device arrangement 400 is shown in Fig. 4. The arrangement 400 comprises one or more BLE beacons 410 installed within the retailer’s shop at a designated location, such as around a cashier. The BLE beacons 410 can operate in a‘broadcast’ or‘advertisement’ mode to notify nearby devices of its presence via an address. The address follows a specific format, such as a predefined prefix, followed by a variable UUID, and a major, minor pair. When a user with the MDCC 420, such as a tourist is within the pre-determined range of the designated location, the MDCC 420 detects the BLE beacons 410 and prompts the user to launch his dedicated software application, or directly launches the software application without prompt once the BLE beacons 410 are detected, which can be programmed to inform the user that he is at a participating retailer based on matching and verifying the broadcast format of the BLE. The retailer specific information can then be displayed on the MDCC 420.

The user next shops and transacts at the retailer shop. Upon payment for the merchandise, the tourist requests for a tax refund. The cashier then requests the tourist to send the request for refund from his MDCC 420, together with the refund account number and BLE address to the server 1 10.

The server 1 10 opens a session between the user account and the retailer account. The tourist is prompted to scan the transaction receipt using the MDCC 420 via the OCR module as described in previous embodiments, or via other means including manual or POS system as described. Once scanned, the transaction details are displayed on the MDCC 420.

The tourist presents the transaction details to the cashier or other personnel authorized by the retailer. The cashier verifies the transaction details and presents a retailer identifier to the tourist. The retailer identifier may be a QR code. The retailer identifier encoded in the form of a QR code may further comprise one or more of the following information:- i. Retailer’s account number held with the server 1 10; and

ii. Sub-accounts created by the retailer for each authorized personnel (e.g. cashier).

The sub-accounts provide a means for identifying the cashier in case of suspected transaction activity(ies), such as collusion between cashier and tourist.

The tourist scans the retailer QR code and the software application transmits the same to the server 1 10 for verification.

Upon receipt of the information related to the retailer identifier, the server 1 10 matches the QR code with the BLE address to verify that the MDCC 420 is on site. Upon verification, the MDCC 420 transmits the transaction details to the server 1 10. The server 1 10 then runs checks on the transaction details. The checks may include (but not limited to) ensuring that the transaction details are current, i.e. with current date and time, and relate to the correct retailer. Upon completion of the checks, the server 1 10 then sends the transaction details to the settlement facility 170. The settlement facility 170 then acknowledges the lodgement of the refund claim to the server 1 10. The server 1 10 generates the electronic refund ticket Ticket, assigns the DOC-ID and sends the same to MDCC 420.

With reference to Fig. 5, at the approved departure point, the location of the MDCC 420 is determined by the software application via GPS or other location-based services. In some other embodiments, the location of the MDCC 420 may be determined using the BLE beacons deployed at the approved departure point. This may enhance compliance and ensure that the tourist is at the approved departure point. Alternatively, the application on the tourist MDCC 120 can also rely on Wi-Fi networks or cellular base stations at the airport and the cruise centre for detecting the MDCC 420. Once detected, the software application guides the user through the declaration of eligibility as described earlier (see steps 310 to 350). Next the tourist confirms his departure and eligibility. The MDCC 420 then retrieves the transaction records from the server 1 10 for the tourist to select for refund. Once the user selects the transaction records, he is prompted to select the refund method (e.g. rewards points, direct credit into specified account etc.). Upon selection, the MDCC 420 sends the declaration of eligibility; selected refund transaction(s); and refund method to the server 1 10. The server 1 10 in turn transmits the information to the settlement facility 170. The settlement facility 170 then replies with an approval or non-approval Notification to the server 1 10, which in turn transmit the approval or non-approval Notification to the MDCC 420. If the refund is approved, the settlement facility 170 further instructs or informs the CRC 430 to process the refund.

Where the settlement facility 170 replies with the non-approval notification, in some embodiments the tourist may be directed to the customs officer or inspector as described in the earlier embodiment for further inspection. The customs officer may be provided with a separate computer device with a dedicated software application installed thereon to facilitate inspection by the customs officer. A‘customs officer approval’ identifier in the form of a QR Code may be provided to the customs inspector to present to the tourist after the customs inspector is satisfied with the eligibility of the tourist. Upon scanning of the ‘customs officer approval’ QR Code, the server 1 10 then updates the settlement facility record as“Approved” and issues a Notification of Approval. If still not approved, the purchases will not be eligible for tax refunds. It is appreciable that the customs approved QR code may be the common identifier for customs’ use as described in earlier embodiments.

During a purchase (step 240), the tourist who wishes to utilize his intermediate value in the form of rewards points can inform the retailer of his intention to use his rewards points. He may launch the software application installed on the MDCC 420 to retrieve from the server 1 10 his rewards points balance and enter and confirm the number of rewards points he wishes to use, before showing to the retailer for verification. Once the retailer has verified the number of rewards points to be used, he can present the tourist with a retailer identifier, which can be another QR code, unique to the retailer, for scanning by the single device 420 as a form of retailer confirmation, and the server will be updated (step 260). The retailer would apply the rewards points against the purchase price accordingly. Also, upon receipt of the electronic refund ticket Ticket in-app, the tourist can be prompted to choose whether to convert the amount, with or without a service charge to the server 1 10, into the rewards points. This raises the possibility of the tourist being able to spend his tourist refund at participating retailers even before leaving the country.

The single device arrangement is based on the use of a mobile device 420 and eliminates the need for a retailer device. Instead of issuing each retailer with a separate device, BLE beacons (transmitters/receivers) can be placed in each retailer outlet, and each authorized personnel may access the retailer’s identifier (which may be in the form of a QR code or otherwise) in a variety of ways. For example an authorized personnel such as a cashier at the retailer shop can be provided with a QR Code Staff Pass, or each retailer outlet can be provided with its own QR Code identifier. The BLE can ensure transactions only take place at participating shops and the QR Code Staff Pass or identifier acts as retailer acknowledgement that the cashier has done her checks. The BLE can also be used to push targeted retailing information to the tourist, e.g. discounts, advertisements, etc. It is to be appreciated that both the QR code and BLE may be utilized in the form of a two-layered check to ensure that the transactions take place within the retailer’s shop or premise. Such a two layered check reduces the risk of any collusion between a member of the retailer’s staff and the tourist.

In some embodiments, the server 1 10 may be operating the system of intermediate value. In such an arrangement, the server 110 may comprise a predictive engine operable to predict which user refund account is likely to be fraudulent so as to be able to take pre-emptive action. Otherwise the system may compromise on account integrity. The predictive engine can be based on at least one criterion of user demographics (e.g. location, countries visited for a past predetermined time frame), transaction profile (e.g. value of transaction, type of goods, etc.), the type of identifier (e.g. credit card) used to register for a refund account, gender, nationality etc. Based on these criteria, an algorithm can be developed to run in the server 1 10 to pick out suspicious user accounts. For example, the predictive engine may attribute high risk weights to transactions exceeding certain value arising from certain countries. In some embodiments, in addition to identifying suspicious user accounts, the predictive engine may further be configured to communicate and send selected details relating to the ‘suspicious accounts’ to the relevant authorities, which include the customs. The selected details are sent to the authorities for further follow up checks in order to provide a more targeted and focused check In other embodiments, the system 10 may refuse the registration of any requested refunds accounts deemed not to pass an initial security check based on one or more of the at least one criterion. In yet other embodiments, based on the profile identified by the predictive engine, selected users or tourists may be banned from purchasing certain tax free eligible items. In some embodiments, the predictive engine may be arranged in data communication with one or more database servers, such database servers for maintaining user information.

The above arrangements are advantageous in that more parameters for the selection of tourists for inspection are considered, compared to that considered by the settlement facility 170 currently. In addition, the selection performed at the servers 1 10 effectively provide an additional layer of check which is pre-emptive in nature, as compared to that currently done at the exit point(s) which is ‘reactive’. In this regard, it is to be appreciated that the existing system performs selection at the end of a tourist’s trip/visit which is deemed less efficient compared to selection performed before the tourist starts his trip. This is because based on the existing structure, the retailers would have already taken the trouble to process the refund transactions of a fraudster, only for the transactions to be subsequently found invalid (this is assuming the settlement facility is able to select the tourist for inspection) when the fraudster attempts to make a claim for a refund as he leaves the country. The above arrangements effectively prevent suspicious transactions from being performed by would-be fraudsters, saving time and effort for both the retailers as well as the Customs.

In another embodiment, the server 1 10 is configured to link to at least one retailer for the provision of one or more retailer item list(s) available for sale and tax refund. In the app installed on the tourist’s MDCC 120, a user interface may then be provided to the tourist which displays the retailer item list of available items for sale and/or tax refund for the tourist to view before the tourist arrives at the country and/or before he/she leaves the country. Once a wish list or checklist of selected items from a tourist is communicated to the server 1 10 via the app, the server 1 10 is operable to provide a list of retailer(s) and details of the retailers selling the one or more items, via a data push or pull mechanism that the tourist desire to purchase. The wish list and retailer list may be compared by any compare and match algorithm between the entries on the tourist’s wish-list with what the retailers have to offer. The compare and match may be performed at the server 1 10 side or the app installed on the MDCC 120.

In the creation of the tourist’s checklist, the tourist can record a plurality of parameters related to each item. Non-exhaustive examples of these parameters may include the item’s name, category, quantity and recipient’s name and insert short notes and images (such as pictures) related to each item. Newly created items can be added to a temporary‘pending list’ which the tourist can check off to move the items to a completed list whenever a purchase is made. Interfaces for sorting the items in alphabetical or other order may also be provided to the user.

Each time the tourist creates a new item, the app is operable to retrieve a list of retailer(s) selling the item from the server 1 10, and then provide to the tourist, retailers that sell the item or related items. The tourist can download the names of the recommended retailers to add them to his shopping list (via an interface) or to access the retailer’s profile on the app. Through the list and/or a BLE located at the retailer’s outlet, the tourist can be notified by the server 1 10 via the app and/or the retailer that sells the item or related items whenever the tourist is near to the retailer’s shop and/or send content e.g. sales voucher from the retailer to the tourist. This is advantageous to provide a seamless experience for the tourist and to aid the retailers in selling their products. Further, the arrangement provides an advantageous hybrid between a pure online shopping experience and a real shopping experience where goods can be inspected before it is purchased. Amongst other advantages, the above arrangement reduces the shopping time required for a tourist to look or source for an item and whether that item is eligible for tax refund; provides an alert or other forms of notification when the tourist is nearby a retailer; and provides an informed list on prices and quality before committing to the purchase.

In some embodiments, the server 1 10 is operable to issue one electronic refund ticket for each refund claim at each retailer store and charge a service fee for each electronic refund ticket issued. Each electronic refund ticket may comprise more than one sales receipt accumulated at the same store (GSTN), subject to one or more regulations to meet a minimum threshold eligible for refund (e.g. SGD 100). For each electronic refund ticket issued, the server 1 10 may also be required to pay a predetermined fee.

As an alternative embodiment, instead of issuing an electronic refund ticket for each transaction, the server 1 10 is instead operable to issue a provisional electronic refund ticket for the first transaction eligible for a refund claim, and add all subsequent transaction receipts to this provisional electronic refund ticket. This is akin to a batch mode process and allows multiple retailers’ transactions to be combined into a single formal/final electronic refund ticket. The formal electronic refund ticket will be issued only when the tourist is at an approved departure point. In such a way, both the user and the service provider may save on fees because only one Refund Ticket per user per trip is issued, instead of one Refund Ticket per user, per store, per trip. This can be performed without compromising on security or authenticity, as the tourist user will have to undergo the verification step at each retailer store.

In some embodiments, users of the system, such as approved retailers, may be provided with a user interface accessible to a portal, the user interface accessible via any computer device such as, but not limited to, a mobile device. The user interface may be used to display business information related to the retailer described as follow. An example of the interface is a webpage. The server will retrieve and store input received from various sensors such as BLE beacons, image capturing devices located around the retailer’s shop, for purpose of tracking, monitoring, obtaining, and/or deriving one or more parameters associated with the retailer. Examples of such one or more parameters include number of shoppers in a retailer shop. Such data may be provided on a real-time or near real-time basis displayed on the user interface. The data obtained may be further analyzed to provide business intelligence information useful for the retailer. Such business intelligence information may include shopper traffic in the retailer shop, busiest period of a weekday or weekend, busiest period over one or more months, etc.

In some embodiments, the system may be linked up with other commercial databases related to cruise ship services for example, to provide users with information such as Qualifying Cruise Ships eligible for tourist refund, as well as pre-populating travel itinerary to achieve certain level of convenience for the users of the system.

The described embodiments are advantageous as they provide a three-tier checking and verification process. In particular, a first level of check/verification is performed when a user (tourist) registers with the central processor 1 10. The second level of check/verification is performed before or during the generation of the electronic refund ticket, and the third level of check/verification is performed at the point of departure prior to the generation of an electronic notification indicating the success or failure of the refund transaction.

In some embodiments, the software application may provide a reward service. The reward may relate to the total tax refund amount and/or the tourist’s membership grade. For example, the tourist may collect the reward point and use the same when he or she purchases goods. In another embodiments, the rewards may relate to a combination of monetary and non-monetary values.

In another embodiments, the software application may provide an information on total amount that the tourist has purchased in the country during a particular trip. Further the software application may calculate the expected tariff amount that the tourist should pay in his/her home country and notify the same to the tourist.

In some embodiments, various parties associated with the refund transactions including entities such as a government entity (immigration, customs), retailer, tourist (consumer), financial institutions, clearing houses, combinations of the above etc. may be deployed in a distributed ledger or blockchain environment to verify one or more refund transactions. Such an arrangement reduces the possibility of fraud or tempering of records. Each of the aforementioned party may be implemented as a node on a blockchain. In some embodiments, the blockchain may be a private or permissioned blockchain, wherein any new party wishing to join the blockchain will be validated by a network starter or meet certain requirements imposed by existing members of the blockchain. Advantageously, the blockchain provides a temper proof environment against alteration of transaction records, device agnostic identifiers of different parties, and/or other sensitive information.

In some embodiments, the genesis node of the blockchain is the processor 1 10, the processor 1 10 can be managed by a private or public entity. Any subsequent node joining the chain will have to obtain permission to join the blockchain.

In some embodiments, the intermediate value for each tourist may be realized in the form of cryptographic tokens. It is appreciable that in a blockchain model, a clearing house or settlement facility may no longer be necessary. In addition, a central refund counter (CRC) is also not necessary since each node is temper proof and the whole blockchain ecosystem can operate without a trust agent such as settlement facility and CRC.

Further, it is to be appreciated that the capturing of detailed information at the point of user registration allows a tourist to specify a desired account for refund upfront. Such an arrangement is useful to alleviate any time pressure that a tourist may face when he is leaving the country, as he needs to complete all form of formalities prior to boarding the aircraft / cruise ship / train. By shifting the data collection point to prior to the tourist embarking on his trip or at the point of registration, precious time is saved for the tourist when he faces the most time pressure.

The above is a description of embodiments of systems, methods and apparatus for facilitating transactions, such as refund transactions, in particular tax refunds to tourists. It is envisioned that those skilled in the art can design alternative embodiments of this invention that falls within the scope of the invention. In particular, it is to be appreciated that features from various embodiment(s) may be combined to form one or more additional embodiments. Further, the following are non-exhaustive examples of features that may be combined with the described embodiments to form further embodiments that falls within the scope of the invention:-

• In the single device embodiment, the user (tourist) may send both the retailer identifier and the transaction details to the server 1 10 for further processing upon scanning the retailer QR code. As a pre-requisite, the server 1 10 will however process the transaction details if and only if the retailer identifier is verified.

• The verification or scanning of the retailer’s identifier may be performed either during the refund qualifying transaction is made or after. In the former case, the transaction details are captured before the retailer identifier is scanned before transmission to the server 1 10. This is particularly relevant for the single device embodiment. In the latter case, the retailer identifier may be verified or scanned for purpose of opening the transaction session before either the user or an authorized representative of the retailer retrieves the transaction details.

• Although the embodiments are described in the context of a tax refund transaction, it is appreciable that the invention may be applied to other types of transactions wherein checking or verification of various parties’ identities are necessary to reduce unauthorized purchase, prevent fraud and/or facilitate the completion of the transaction.

• Although the embodiments are described in the context of the tax refund transaction in jurisdictions and/or situations in which the tax refund are recorded as per transaction basis for each transaction made at the retailer (for example, in the form of ticket and/or in electronic data format), it may be appreciated that the embodiments may also be applied to the tax refund transaction in jurisdictions and/or situations in which the tax refund are not recorded as per transaction basis. In some embodiments, the server 1 10 does not send the notification of individual transactions to the MDCC 120. Instead, the server 1 10 may tag and/or log the transactions in relation to the tourist of the MDCC 120 using the tourist’s account, passport or other personal identifiers. Alternatively or additionally, the server 1 10 may send the notification to a tax refund system, and the tax refund system may tag and/or log the transactions in relation to the tourist using the tourist’s account, passport or other personal identifiers.

Claims

WE CLAIM

1. A system for facilitating secure and convenient transactions comprising a central processor configured to generate or store:- a first device agnostic identifier associated with a consumer; and

a second device agnostic identifier associated with a retailer;

a user mobile device configured to generate or retrieve the first device agnostic identifier for use in a transaction;

a retailer device operable to retrieve the second device agnostic identifier for use in the transaction, the retailer device further configured to access the first device agnostic identifier to generate a verification status; and

a transaction device operable to read the verification status to determine if the user qualifies for a type of transaction, and if so, the transaction device sends a notification of the qualified transaction to the retailer device and/or to the central processor.

2. The system of claim 1 , wherein the central processor is configured to generate or store a third device agnostic identifier associated with an public authority, and a corresponding device operable to generate or retrieve the third device agnostic identifier for use in verifying the transaction and the identity of the consumer.

3. The system of claim 1 , wherein at least one of the first device agnostic identifier and the second device agnostic identifier comprises a first portion associated with the user, and a second portion generated by the central processor.

4. The system of claim 1 , wherein the type of transaction is a refund transaction and the transaction device is further configured to provide a calculation of a refund of the qualified refund transaction.

5. The system of claim 2, wherein at least one of the first device agnostic identifier, the second device agnostic identifier, and the third device agnostic identifier is encoded as a quick response (QR) code.

6. The system of claim 2, wherein upon successful verification of the identity of the consumer and the transaction, the user mobile device is utilized to access the third device agnostic identifier.

7. The system of claim 2, wherein upon successful verification of the identity of the consumer and the transaction, the corresponding government device is utilized to access the first device agnostic identifier.

8. The system of claim 1 , wherein the retailer device is a mobile computer device.

9. The system of claim 2, wherein the corresponding government device is a mobile computer device.

10. The system of claim 4, wherein after calculation of the refund, the refund is deducted from a purchase price of the transaction and the notification in the form of a receipt is sent to the retailer device and/or the central processor.

1 1. The system of claim 2 and claim 4, wherein after calculation of the refund, the amount of refund is stated in the notification for further verification by the corresponding government device.

12. The system of claim 1 and 2, wherein the mobile user device, the retailer device and the corresponding government device are arranged in a distributed ledger or blockchain environment for verification of one or more refund transactions.

13. The system of claim 12, wherein each of the mobile user device, the retailer device and the corresponding government device are implemented as a node on the distributed ledger or blockchain.

14. The system of clam 13, wherein the blockchain is a private blockchain, and wherein the genesis node is the central processor.

15. The system of claim 1 , wherein the retailer and transaction devices are integrated.

16. The system of claim 1 , wherein the retailer device comprises a plurality of communication modules disposed at specific locations within a premise of the retailer, the plurality of communication modules comprises transmitter and/or receiver to detect the user mobile device.

17. The system of claim 4, wherein the calculated refund is deposited into a designated account or electronic wallet of the consumer.

18. The system of claim 4, wherein a portion of the calculated refund is converted to an intermediate value.

19. The system of claim 18, wherein the intermediate value includes one or more of the following:- coupons, credits, points, or other electronic value.

20. A method for facilitating a secure and convenient transaction comprising the steps of:

generating a first device agnostic identifier by a central processor or a user mobile device, the first device agnostic identifier associated with a consumer;

generating a second device agnostic identifier by the central processor or a retailer device, the second device identifier associated with a retailer; retrieving, by the user mobile device, the first device agnostic identifier for use in a transaction; accessing, by the retailer device, the first device agnostic identifier to generate a verification status; and

reading, by a transaction device, the verification status to determine if the user qualifies for a type of transaction, and if so, the transaction device sends a notification of the qualified transaction to the retailer device and/or to the central processor.

21. A mobile device configured to provide a secure and convenient transaction to a user, the mobile device comprises

a memory block configured to store a first device agnostic identifier, the first device agnostic identifier associated with the user;

a communication module operable to interact with a retailer device and a central processor for facilitating a transaction;

wherein as part of the transaction, the first device agnostic identifier is accessed by the retailer device to determine an eligibility of the user.