Client device and method, and server device and method

Abstract

The present invention provides a client device, a method for operating the client device, a server device, a method for operating the server device, and a computer program. [Solution] The client device includes a receiving circuit that receives user identification information indicating the user's identity and first transaction data indicating the user's first transaction, and a control circuit that searches for transaction target data stored in association with the user identification information. The control circuit associates the transaction target with the first transaction data in response to the selection of a transaction target from the transaction target data, enabling a second transaction conditional on the first transaction to be processed at a point in time after the first transaction in response to at least one condition being met.

Description

[[Technical Field]]

[0001] The present disclosure relates to a client device, a method for operating a client device, a server device, a method for operating a server device, and a computer program.

[0002] Some transactions may result in a subsequent transaction being performed in response to one or more conditions being satisfied. [[Summary of the Invention]]

[0003] According to a first aspect of the present technology, there is provided a client device, the client device comprising: a receiving circuit configured to receive user identification information indicating a user's identity and first transaction data indicating a first transaction of the user; a control circuit configured to retrieve transaction object data stored in association with the user identification information; wherein the control circuit associates the transaction object with the first transaction data in response to selection of the transaction object from the transaction object data, and enables a second transaction conditional on the first transaction to be processed at a time point after the first transaction in response to at least one condition being satisfied.

[0004] According to a second aspect of the present technology, there is provided a method of operating a client device, the method comprising: receiving user identification information indicating a user's identity and first transaction data indicating a first transaction of the user; triggering retrieval of transaction object data stored in association with the user identification information; associating the transaction object with the first transaction data in response to selection of the transaction object from the transaction object data, and enabling a second transaction conditional on the first transaction to be processed at a time point after the first transaction in response to at least one condition being satisfied. the method comprising the above steps.

[0005] According to a third aspect of this technology, a server device is provided, and the server device is A storage circuit configured to store transaction data associated with each of multiple users, wherein the transaction data identifies one or more transaction items, and when one or more transaction items are associated with a first transaction among one or more first transactions, the storage circuit is processed in response to at least one condition being met at a point in time after the first transaction, where a second transaction associated with the first transaction and conditional on the first transaction is processed. A control circuit that, in response to receiving a transaction data request containing the identification information of a given user from a client device, performs a search in a storage circuit using the identification information, and in response to a hit in the storage circuit, returns the transaction data associated with the given user to the client device. It is equipped with.

[0006] According to a fourth aspect of this technology, a method for operating a server device is provided, and the method is: A step of storing transaction data associated with each of several users, wherein the transaction data identifies one or more transaction items, and when one or more transaction items are associated with a first transaction among one or more first transactions, the storage step enables that a second transaction associated with the first transaction and conditional on the first transaction is processed in response to at least one condition being met at a point in time after the first transaction. The steps include: receiving a transaction data request from a client device that includes the identification information of a given user, performing a search in a storage circuit using the identification information, and returning the transaction data associated with the given user to the client device in response to a hit in the search in the storage circuit; Includes.

[0007] According to a fifth aspect of this technology, a computer program including computer-readable instructions is provided, and when the computer-readable instructions are executed by a processing circuit, the processing circuit is made to execute the method according to the second or fourth aspect.

[0008] In some configurations, computer programs are stored on computer-readable storage media. In some configurations, the computer-readable storage media is non-temporary computer-readable storage media.

[0009] This technology is further described for illustrative purposes only, with reference to its configuration shown in the attached drawings. [Brief explanation of the drawing]

[0010] [Figure 1] A schematic representation of a client device based on a portion of this technology is shown below. [Figure 2] A schematic diagram of a server device based on a part of this technology is shown below. [Figure 3] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 4] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 5] A schematic diagram of an apparatus based on some of the components of this technology is shown below. [Figure 6] A schematic diagram of the interaction involving a server device with a configuration of this technology is shown. [Figure 7] A schematic diagram of the interaction involving a server device with a configuration of this technology is shown. [Figure 8] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 9] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 10] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 11] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 12] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 13-1] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Figure 13-2] The sequence of steps performed according to some of the configurations of this technology is outlined below. [Modes for carrying out the invention]

[0011] Some transactions performed in association with a user may result in further transactions. For example, a first transaction to transfer data or a portion of assets from one user to another may result in a second transaction to transfer further data and / or a further portion of assets being performed if at least one condition is met. Furthermore, the first and second transactions may relate to financial transactions in which the second transaction is conditional on the first transaction. Examples of such transactions include refund transactions where a refund is conditional on the existence of an initial purchase transaction to which the refund is being made.

[0012] According to a part of the configuration of this technology, a client device is provided which includes a receiving circuit configured to receive user identification information indicating the user's identity and first transaction data indicating the user's first transaction. The client device also includes a control circuit configured to retrieve transaction target data stored in association with the user identification information. The control circuit associates the transaction target with the first transaction data in response to the selection of a transaction target from the transaction target data, enabling a second transaction conditional on the first transaction to be processed at a point in time after the first transaction in response to the fulfillment of at least one condition.

[0013] When a certain condition is satisfied, there are several types of transactions that may require a second transaction conditional on a first transaction. As used herein, the term "conditional on" indicates that the second transaction has a dependency on the first transaction, such that the second transaction is not performed without the first transaction being performed before the second transaction. The second transaction not only requires that the first transaction has been performed, but also requires that at least one condition is satisfied. The at least one condition may require that one or more actions are performed by or on behalf of a user, and as a result, at the time of performing the first transaction, it may not be known when the second transaction will occur. It is also possible that the at least one condition is never satisfied, and the second transaction may not occur at all.

[0014] To facilitate the occurrence of the second transaction, these users may for example be registered in a database, whereby the transaction is associated with the user and the achievement of the at least one condition is tracked. In general, a user may have a plurality of second transactions assigned to the user, each of which is associated with a corresponding first transaction. In order for one second transaction (or a plurality of second transactions) to be executed, transaction object data indicating an object (e.g., a destination) of the second transaction should be assigned to each transaction. While the transaction object data can be assigned at or after the point in time when the at least one condition is satisfied, the inventors have recognized that assigning the transaction object data before the at least one condition is satisfied, that is, at the time of the first transaction, reduces the burden on the user and allows the second transaction to be executed without the user needing to provide information when the at least one condition is satisfied. This improves user experience and reduces the total number of interactions between the user and the system.

[0015] The client device therefore comprises a control circuit configured to retrieve transaction target data in response to receiving user identification information, for example, in response to receiving user identification information for selecting a potential transaction target stored in association with a user identified by the user identification information, and to receive a selection of a transaction target (also referred to as a payment target) from the user when a first transaction is executed. The selected transaction target enables a second transaction to be executed when at least one condition is satisfied, that is, without requiring the user to subsequently identify the transaction target. As a specific example, the transaction may be a financial transaction, where the first transaction may be a payment transaction and the second transaction may be a subsequent refund transaction. The subsequent refund transaction may require that the condition be satisfied. For example, the refund may be a partial refund that is paid when the user exports an item purchased as part of the payment transaction, and in this case the partial refund is paid to the transaction target. For example, by identifying a transaction target such as a specific bank account, debit card, or credit card to which the refund is to be paid when executing the first transaction, the second transaction may be configured to be automatically completed when evidence that the user has exported the item is received. This reduces the burden on the user when exporting the item, and avoids the possibility that the user may forget to provide information at that point in time.

[0016] The transaction data may be any information that identifies the subject of a transaction, but in some configurations, the transaction data includes enough data to allow the second transaction to be processed without the user needing to provide further data at a later point in time to trigger the second transaction. Providing the transaction data in this way creates different physical interactions between the system (i.e., the client device and any further systems involved in processing the second transaction) and the world outside the system. In other words, the system is provided with details about the second transaction at the time the first transaction is executed, rather than the user being required to perform two separate interactions with the system—one to perform the first transaction and another to provide the details necessary to perform the second interaction. To put it another way, the provision of the client device allows the second transaction to be handled based on selections already made by the client device.

[0017] The client device may be capable of storing the transaction data locally, but in some configurations, the control circuit is configured to trigger a retrieval of the transaction data from the server device. The server device may be a global server provided as a central repository for transaction data associated with a particular user. Alternatively, the server may be a local server provided in a given region for a user in that region. The transaction data may be stored in a database, which uses user identification information to index and identify specific transaction data associated with a user. The server may be provided as a dedicated server device to store the transaction data. Alternatively, the server device may be provided as part of a general-purpose server device configured to perform one or more other steps relating to the first and second transactions.

[0018] In some configurations, the control circuit transmits the transaction object to the transaction server device in response to the selection. The transaction server may be the same server from which the transaction object data was retrieved, or a separate server. The transaction object may be transmitted along with data indicating the first transaction, user identification information, and / or data indicating the second transaction. The transaction object may be a single transaction object or multiple transaction objects.

[0019] In some configurations, the control circuit is configured to provide a first transaction object identified in the first transaction data for selection as a transaction object. The first transaction object may be provided as sole transaction object data or in addition to transaction object data retrieved, for example, from a server device. For example, the first transaction object may include bank account details or credit / debit card details used by the user as a source of payment during the first transaction.

[0020] In some configurations, the first transaction includes a first transfer from the user to a further transactional entity, and the second transaction includes a second transfer from the further transactional entity to the transactional entity. The further transactional entity may be a seller receiving payment for goods or services. Alternatively, the further transactional entity may be an intermediary configured to facilitate the second transaction when at least one condition is met.

[0021] In some configurations, the amount included in the first remittance is equal to or greater than the amount included in the second remittance. If the first transaction is a financial transaction, the second transaction may be a partial refund transaction or a remittance of a portion of the first transaction to the recipient of payment.

[0022] In some configurations, the first transaction is a purchase transaction, and the second transaction is a refund transaction. The refund transaction may be a full refund or a partial refund. For example, if the refund is a full refund, the transaction subject may be the original payment card, or a bank account or card other than the original payment card. For the refund transaction, at least one condition may be that a specific action is taken on the items purchased during the first transaction. For example, at least one condition may be that the purchased items are delivered to a specific location, returned to the store, or exported from a territory (a country or group of countries sharing a common tax boundary).

[0023] In some configurations, a refund transaction is a tax refund transaction. A refund transaction may be a VAT (Value Added Tax) refund transaction, a goods or services tax refund transaction, or a sales tax refund transaction. In such cases, a refund is made if the user is not required to pay taxes, i.e., if it can be demonstrated that the user is eligible for a tax refund. For example, a user may be a foreign visitor to a particular area and, therefore, may be eligible to make a purchase without paying sales tax or VAT on the purchase in response to specific tax requirements for that area. While some tax refund schemes exist where the user is exempt from paying VAT at the point of sale (VAT-off scheme), another approach is that the user pays the full purchase price, including VAT, at the point of sale, and then the VAT may be refunded when the user exports the purchased items. In such configurations, the choice at the point of purchase of the transaction subject to VAT refund avoids the requirement for the user to provide additional details following the export of the goods. This reduces the burden on the user and increases the overall convenience of the tax refund scheme.

[0024] In some configurations, at least one condition includes an approval condition, which is met in response to the receipt of an approval message generated by a third-party device. For example, the third-party device may be a customs device configured to authenticate (confirm) that the user has exported the purchased items. The third-party device may be provided at a point of departure from the area, such as an airport or ferry port. The third-party device may be provided in the form of a self-service kiosk, where the user can scan and verify that the user is exporting the purchases, for example by scanning barcodes attached to one or more purchases. Alternatively, the third-party device may be a human-operated customs counter where verification is provided by a customs operator. In some configurations, the second transaction may be carried out as soon as the approval condition is met, ensuring that no further action is required from the user once the user has authenticated the export of the purchases.

[0025] In addition to being able to receive selections of trading targets, in some configurations, the control circuit triggers, in response to a mark indicating a deselected trading target, to exclude the deselected trading target from future instances of searching for trading target data. Deselected trading targets may also be referred to as deactivated trading targets. The client device may present a list of possible trading targets for the user to select. In addition to being able to select trading targets, the user may choose to mark one or more of the possible trading targets so that they are not presented in the future. For example, the user may know that one or more of the trading targets are no longer valid (expired), or may have a personal preference that these trading targets not be used.

[0026] In some configurations, the control circuit is configured to present trading objects for user selection. Presenting trading objects to the user may be achieved using a display screen included in the client device or through the user's personal mobile device. For example, the client device may trigger the user's personal mobile device (e.g., when it is running a dedicated app) to present the objects to the user for selection. The user may indicate their selection of the presented trading objects and mark any deselected trading objects. The user's selection may be received, for example, through a touchscreen, keyboard, keypad, or any other input device.

[0027] In some configurations, the trading target data includes a ranking of trading targets, and the control circuit is configured to present the trading targets according to this ranking. The ranking may be based on user preferences, the order in which trading targets were added, the frequency of trading target use, or an indicator that a trading target is not accepted by some client devices. The ranking may exclude any trading targets that have been deselected by the user. In some configurations, trading targets that have been deselected by the user may be hidden at the bottom of the ranking, and the user may be provided with an option to show the deselected trading targets, for example, by allowing the user to select previously deselected trading targets, or by allowing the user to remove the indicator that a previously deselected trading target has been deselected. Trading targets may be ranked as strong trading targets, indicating a higher probability that the user will select that trading target or that a client device will accept that trading target, or as weak trading targets, indicating a lower probability that the user will select that trading target or that a client device will not accept that trading target. For example, some client devices may not accept one or more types of trading targets, and therefore these trading targets may be identified as weak trading targets. Transaction objects may be ranked based on whether they are strong or weak, and may be further ranked based on a date / time stamp indicating the date and / or time the transaction object was last updated. The term “strong” as used herein indicates that the transaction object is more trustworthy, and the term “weak” as used herein indicates that the transaction object is less likely to be trustworthy. Whether a transaction object is captured as “strong” or “weak” may depend on various conditions, such as how the transaction object was captured and who captured it. For example, a transaction object captured using a device (e.g., a card reader) is more likely to be recorded as a “strong” transaction object.On the other hand, devices that are manually captured (for example, by manually entering card details) are more likely to be recorded as "weak" payment targets because they are more likely to have inaccurate data entered. Furthermore, payment targets captured by the user are more likely to be recorded as "stronger" than when they are captured by other parties such as the seller, refund officer, or customs officer.

[0028] Transaction objects may include previously unused transaction objects, such as transaction objects added by the user before the first transaction is performed. However, in some configurations, transaction object data includes at least one previous transaction object associated with the user's previous transactions. For example, a previous transaction object may be associated with a previous transaction in an earlier first transaction (e.g., an earlier purchase by the user).

[0029] In some configurations, a server device is provided, which includes a storage circuit configured to store transaction data associated with each of a plurality of users, wherein the transaction data identifies one or more transaction items, and when one or more transaction items are associated with a first transaction among one or more first transactions, the storage circuit enables that a second transaction associated with the first transaction and conditional on the first transaction is processed in response to at least one condition being met at a point in time after the first transaction. The server device further includes a control circuit that, in response to receiving a transaction data request from a client device that includes the identification information of a given user, performs a search in the storage circuit using the identification information, and returns the transaction data associated with the given user to the client device in response to a hit in the search in the storage circuit.

[0030] A server device is provided to store transaction data associated with each of the users. This transaction data may be stored in a database indexed based on user identification information. The server device may also store transaction information indicating a first transaction and subsequent transactions conditional on that first transaction for each of the multiple users; however, this information may be stored on a separate server instead or additionally. A transaction data request received from a client device includes user identifier information identifying the user performing the first transaction, and performs a search to determine if any transaction data associated with that user exists in the database. If the search is successful, the server device returns the transaction data to the client device. If the search fails, the server device returns an indication that no transaction data is available for that user identification information. Additionally, the server device may assign a new entry in the database for that user and subsequently add transaction data derived from transactions performed by the user. This transaction data may then be provided when the user performs further first transactions on the same or a different client device.

[0031] In some configurations, the control circuit is configured to mark one of the one or more trading objects as invalid in response to a trading object invalidation request indicating one of the one or more trading objects associated with a given user, and to exclude the marked invalid trading object from the returned trading object data. The server device may store an indicator for each of the trading objects indicating whether it is valid or invalid. Invalid trading objects are kept in the server device's memory but may be excluded from being passed to client devices in response to future trading data requests from one or more client devices. Invalid trading objects may also be referred to as deallocated trading objects or deselected trading objects.

[0032] In some configurations, the control circuit, in response to receiving new transaction data specifying a given user and a given transaction object, assigns the given transaction object data to the transaction object data associated with the given user if the given transaction object is not included in the transaction object data associated with the given user. The given transaction object data may then be returned to one of the client devices in response to a future transaction data request from that client device. In some configurations, all valid transaction objects may be returned to the client device in response to a transaction data request. In other configurations, only the first N (where N is a positive integer) transaction objects may be provided.

[0033] In some configurations, the control circuit, in response to an indication that a second transaction using the selected object was unsuccessful, returns one or more objects associated with a given user if the user's object data indicates one or more objects other than the selected object, thereby enabling the second transaction to be re-triggered using one of the one or more objects. The indication that a second transaction was unsuccessful may be received, for example, from a transaction server configured to trigger a second transaction in response to the fulfillment of at least one condition. If the user's object data indicates that no objects other than the selected object exist, the server device may then return a message indicating that no further objects are available. The transaction server or server device may then trigger a message to the user indicating that the user needs to provide object data in order for the second transaction to be executed.

[0034] In some configurations, the control circuit, in response to receiving selection data that identifies a plurality of given trading objects associated with a given user, and which have an associated trading object order, stores the associated trading object order in association with a given user. The order may provide a relative ranking of each trading object to each other, thereby determining a unique order. Alternatively, one or more trading objects may be ranked with one or more other trading objects set to a default ranking such that the order of one or more other trading objects relative to each other is not determined. In response to a future transaction data request, the server device provides the ranking to the client device that requested the transaction data, so that the trading objects can be presented to the user in ranked order. In some configurations, the trading object data includes the ranking of the trading objects.

[0035] In some configurations, the control circuit, in response to a request from a second trading server configured to execute a second transaction in response to the fulfillment of at least one condition, transmits a plurality of given trading objects and a trading object order to the second trading server, enabling the second transaction to be executed using each of the plurality of given trading objects according to the associated trading object order until the second transaction is successfully executed. The second trading server may be hosted in the same location as the server device. Alternatively, the second trading server may be hosted in a different location from the server device. The request from the second trading server includes user identification data, and the transaction data may be retrieved by the server device in the same manner as when responding to transaction data requests from one or more client devices. Following the triggering of the second transaction, the second trading server may provide feedback information indicating whether any of the trading objects failed the second transaction. The server device may respond to the feedback information by lowering the ranking of the trading objects that failed the second transaction, or by marking the trading objects that failed the second transaction as invalid.

[0036] In some configurations, at least one condition includes an approval condition, which is met in response to an approval message generated by a third-party device. As discussed above, the third-party device may be an authentication device, which may issue an approval message in response to a determination that the user is exporting one or more items purchased as part of a second transaction.

[0037] In some configurations, a system is provided that includes a server device and multiple client devices, as described above. In some configurations, the system further includes a second trading server.

[0038] The above system has been described with respect to circuits that may be provided to server and client devices. In some configurations, a computer program is provided that, when executed by the processing circuit, causes the processing circuit to operate as a server and / or client device. In some configurations, the computer program may be stored on a computer-readable storage medium. In some configurations, the computer-readable storage medium may be a non-temporary computer-readable storage medium.

[0039] Some of the components are described here with reference to the attached drawings.

[0040] Figure 1 schematically shows a client device 210 with a partial configuration of this technology. The client device 210 comprises a receiving circuit 211 and a control circuit 212. The receiving circuit 211 is configured to receive user identification information and first transaction data. User identification information is provided to identify the user and may be entered, for example, by scanning the user's identity document (e.g., the user's passport) using a scanner. Alternatively, user identification information may be entered manually, for example, by or on behalf of the user. First transaction data indicates a first transaction performed by or on behalf of the user.

[0041] The control circuit 212 is configured to retrieve transaction data stored in association with user identification information. For example, the control circuit 212 may perform a search in a local database, or it may communicate with the server device 220, as described below in relation to Figure 2, for example. Following the receipt of transaction data, the control circuit 212 is configured to receive a selection of a transaction from the transaction data. In response to the selection, the control circuit 212 is configured to associate the transaction with first transaction data. The association is performed to enable a second transaction, i.e., for a second transaction to be subsequently performed conditionally on the first transaction. For example, the control circuit 212 may store a record of the transaction and the first transaction data in a database area associated with user identification information. The second transaction can then be performed in response to the condition being met.

[0042] Figure 2 schematically shows a server device 220 with a partial configuration of this technology. The server device 220 comprises a storage circuit 221 and a control circuit 222. The storage circuit 221 is provided for storing transaction data for multiple users registered in the server device. The control circuit 222 is provided for receiving transaction data requests from a client device 210 that specifies user identification information, and for performing a search in the storage circuit 221 in response to the received data. If the search is successful in the storage circuit 221, that is, if the control circuit 222 is able to identify the data associated with the user identification information in the storage circuit 221, the control circuit 222 returns the transaction data associated with the user to the client device 210. The control circuit 222 may also update the transaction items associated with the user in response to an update request received from the client device 210, for example, by specifying a new transaction item or requesting the deactivation / deactivation of an existing transaction item for that user.

[0043] Figure 3 schematically illustrates an approach to obtaining a refund of taxes associated with a purchase, such as a refund of value-added tax (VAT) or sales tax. The approach shown in Figure 3 involves a user (e.g., a traveler and / or shopper) 1 who receives a conventional store receipt from a seller 3 when making a purchase of one or more items that include paying taxes associated with the purchase. The seller creates a tax refund form (either a paper copy or a digital copy) which is issued to the shopper. The store receipt is then presented to customs 5 along with the goods and the tax refund form. Customs 5 then determines eligibility and certifies the store receipt, for example, by stamping the tax refund form to confirm (certify) the export of the goods. The receipt can then be used to authorize a payment to the shopper 1. For example, the payment may be handled by a Tax Refund Operator 7 (TRO) that receives the certified receipt (e.g., from the shopper or directly from customs) and pays the refund to the shopper. TRO7 may request a refund of VAT from seller 3, and seller 3 may then recover the VAT from the tax authority 6. Payment to customer 1 may be in any appropriate form, such as cash or credit to a Non-Cash-Payment-Target (NCPT), for example, by crediting the tax refund amount onto a payment card, by giving cash to user 1, or by transferring funds to customer 1's account. For example, customer 1 may prefer that the payment be made directly to their bank account. Customer 1 provides a bank account to the tax refund operator for the payment to be processed and completed.

[0044] In total, the process of claiming a tax refund involves four steps. 1. Purchase of goods by shopper 1, including payment of taxes associated with the purchase. 2. Present relevant information to Customs 5. 3. Determining the eligibility of customer 1 for a refund. 4. Refund of taxes paid by shopper 1.

[0045] The systems described above require the collection and storage of a large amount of information (documents or data) and multiple steps that require input from the shopper. This requires either the shopper to keep track of their own information (e.g., by keeping receipts and tax refund forms) or the shopper to carry identification information (e.g., a passport or some other shopper identifier associated with their account) when making a purchase so that the shopper's receipt information can be linked to their account. In either case, the shopper is required to keep at least some physical information, which places an administrative burden on the shopper. Furthermore, the shopper may be required to present the same information multiple times. For example, a shopper may make a purchase using various payment methods and then need to present information that identifies one or more NCPTs in order for a refund to be processed.

[0046] While a user may be a traveler, this is not always the case. For example, a user may be involved in cross-border shopping, i.e., a shopper purchasing items across tax boundaries, for instance, through online shopping.

[0047] Figure 4 shows exemplary methods, apparatus, and systems for managing the VAT refund process. In the exemplary process, the purchase and receipt collection (issuance 30) are separated from further processing (acquisition 32, approval 34, and payment 36).

[0048] Similar to credit and debit cards, there may be multiple providers of issuance services and multiple recipients of transactions and processing. For example, there may be multiple tax refund operators (TROs). Transaction issuance may follow standard message types for authorization and transmission to payment systems. A wide range of point-of-sale (POS) devices and in-store support for shoppers may be provided.

[0049] In an exemplary configuration, the seller system provides transaction issuance 30 using a POS device and / or software provided by the TRO, the TRO host system performs acquisition 32, the customs approval system performs approval 34 (authentication), and the TRO host system performs refund payment 36 using a kiosk (authentication station) at the point of departure from the territory. In some exemplary configurations, eligibility and identity determination is shifted from the point of sale to the point of departure from the territory. The exemplary configurations provide the simplicity of use of the approach described with reference to Figure 3, as recognized by the system user, while also providing enhanced uniformity.

[0050] Possible user identification information (also referred to as shopper identifiers, tokens, or token identifiers) includes passport numbers, passports, identity card numbers, identity cards, driver's license numbers, driver's licenses, payment card numbers, payment cards, card refund operator card numbers, card refund operator cards, visitor card numbers, visitor cards, user-defined identifiers, and mobile phone numbers. In some examples, a shopper identifier may include a cryptocurrency wallet address. As indicated, a shopper identifier may be a visitor card or other visitor token that may be issued to the user, for example, upon entry into an area that involves or does not involve identity verification at this stage. A visitor token may be, for example, a chip card with a unique number or a card with a magnetic stripe.

[0051] By presenting a shopper identifier (user identification information) when making a purchase, a record of the purchase (an example of a first transaction) can be associated with the shopper identifier. A computer record can be created for purchase transactions relating to one or more purchases from the association between the shopper identifier and a transaction identifier (e.g., a sales receipt or sales receipt identifier). The shopper identifier can then be used to retrieve the record of the transaction(s) upon departure from the region to authenticate a refund for the purchase (i.e., to determine whether at least one condition required to enable a second transaction has been met).

[0052] In the following, an exemplary embodiment of a tax refund system for a territory, including its system and method, is described with reference to Figure 4, in which multiple TROs partner with merchants and then provide tax refunds to shoppers through users of self-service kiosks 22 (example of authentication devices) at exit points from the territory.

[0053] In the first stage 102, a shopper identifier is assigned to the user. This can be done at any point before making the first tax refund-eligible purchase, at the point of sale, or via the user's mobile device before or at the time of entry into the territory. In one example, the user can choose which shopper identifier to use. For example, the user may specify a particular shopper identifier to use (e.g., one of the types mentioned above, such as a cryptocurrency wallet) by, for example, through a website or at a point of sale terminal, or in response to a request from a seller. For example, the user may register their details and associate their details with a shopper identifier by registering on a website provided by the TRO. The TRO may then provide the user with information regarding refund opportunities and procedures. Alternatively, or additionally, a shopper identifier (e.g., the visitor card mentioned above) may be issued to the user. The user details may then be recorded in a local input station at the point of issuance, for example, at the time of entry or at the point of sale, or the issued shopper identifier may be associated with user details pre-entered on the TRO website. For example, a user's cryptocurrency wallet address may be recorded as one of the user details, thereby associating the user's cryptocurrency wallet with an issued shopper identifier. A suitable input station may include, for example, a computer processor containing processing logic, computer memory, a keypad, keyboard, touch-sensitive screen, card reader, machine-readable identifier reader, document scanner, and one or more input interfaces in one or more forms from voice-activated input, and one or more output interfaces in one or more forms from a display, printer, card writer, and speaker. The input station may also include fingerprint reading technology and / or camera technology for verifying biometric information held on a machine-readable user identifier (e.g., an ID document such as a passport).

[0054] A shopper identifier (for example, a unique number for a user and user details (traveler and / or shopper)) is provided to and can be held in an acquisition host server system 20 (example of a server device), and the identifier and user details are recorded (stored) in the acquisition host server system 20. For example, if the shopper identifier is associated with a cryptocurrency wallet, the shopper identifier may be an address for the cryptocurrency wallet. The host server system 20 may consist of one or more server computers, each having one or more processors including processing logic and memory located in a single location or within a distributed system. The efficiency of the system is improved when the shopper identifier and user details are transferred to the host server system and recorded in real time.

[0055] In the next stage 104, user 12 can make a purchase, for example, at a seller. When a regular store receipt is presented, user 12 may be asked if a tax refund is needed (or the user may request a tax refund). If a refund is desired, a first transaction may be created including transaction details such as a receipt identifier (e.g., receipt number), the value of the purchased goods, and user identification information (e.g., shopper identifier). The seller system may also include one or more client devices, or a POS system with client devices as described in relation to Figure 1. When creating the first transaction, the client system requests transaction data and presents the transaction data to the user (shopper 12). Shopper 12 can then select one specific transaction item associated with the first transaction record in the acquisition server system 20. The transaction data can then be used as the transaction item for a refund without the need to retrieve this information from shopper 12 at a later point. This approach reduces the number of interactions between shopper 12 and the tax refund system. Therefore, in this exemplary embodiment, information including the four items (receipt identifier, purchase value, shopper identifier, and selected payment item) can then be electronically transmitted by the seller system 14 to the acquisition server system 20. The seller system 14 may comprise one or more computers, each comprising one or more processors including processing logic and memory located in a single location or distributed system.

[0056] Since multiple TROs can exist within the market, multiple acquisition system hosts 20 can exist. The relationship between the seller and the TRO is the same as the relationship between the seller and the acquirer (using the example of a credit / debit card). Each TRO partners with its own sellers and is responsible for the point-of-sale (POS) device and integrated software that creates the tax refund transaction. Transaction messages can therefore be sent 105 to the TRO acquisition host system 20, where further processing may be carried out. The format of the transaction message between the POS and the acquisition host can take any appropriate form, as this may be proprietary. In one example, a transaction message sent between the seller system 14 and the acquisition host 20 may include a shopper identifier (e.g., shopper identification number), a receipt identifier (e.g., receipt number), a reference to the purchased goods, a seller identifier, a TRO identifier, a time and date stamp, and a security hash (used to prevent tampering). This may additionally include information about the tour guide, a promotional code, or any other data that the TRO wishes to collect.

[0057] A separate acquisition host system 20 may be provided for each TRO, so that each TRO can view only transactions generated by its affiliated merchants, thereby ensuring that commercial confidential information is kept separate within each TRO. All tax refund transactions (first transactions) generated by affiliated merchants can be stored in the database of the acquisition host system 20 along with the associated transaction data. Transaction records stored in the memory of the acquisition host system may include, for example, a shopper identifier (e.g., shopper identification number), a receipt identifier (e.g., receipt number), a reference to the purchased goods, a merchant identifier, and a time and date stamp. The acquisition host system 20 may also assign a unique transaction identifier (e.g., a unique transaction number) to each transaction so that a unique number is available within the system for tracking the transaction while it is being processed.

[0058] The message switch 24 provides a neutral location for all messages to be received and sent, ensuring that messages are properly formatted and routed. For example, a transaction message may include one or more of the following: a transaction identifier (e.g., transaction number), a shopper identifier (e.g., shopper identification number), a receipt identifier (e.g., receipt number), a reference to the purchased goods, a seller identifier, a TRO identifier, a time and date stamp, and a security hash (used to prevent tampering). The message switch 24 may be a separate system or may be combined with the customs approval system 26 depending on the specific implementation.

[0059] Transactions received by each of the acquisition host systems 20 can be forwarded to the customs approval system 26 via the message switch 24. The customs approval system may consist of one or more computers, each having one or more processors and memory containing processing logic.

[0060] Transaction messages received by the TRO in the acquisition host system 20 can be formatted according to the proposed standard and sent to the message switch 24. The message switch can be configured to pass the transaction messages to the customs approval system 26.

[0061] The customs approval system 26 provides an approval system for approving refunds, and this approval system may be operated by the customs authorities or by a third party on their behalf. The customs approval system 26 can automatically approve or reject tax refund transactions based on rules set within the system by customs. The customs approval system 26 can also be accessed manually by customs officers.

[0062] A self-service authentication station (also referred to as a kiosk or authentication device) 22 at the exit point of the region can be connected to a message switch 24. The authentication station 22 can be configured to prompt the user to present an identifier (e.g., an identity document such as a passport) for reading. The authentication station 22 may include one or more input interfaces, such as a keypad, keyboard, touch-sensitive screen, card reader, scanner, or voice-activated input, and one or more output interfaces, such as a display, printer, card writer, or speaker. The authentication station 22 may also include fingerprint reading technology and / or camera technology for verifying biometric information held on a machine-readable user identifier (e.g., an ID document such as a passport).

[0063] In one example, the authentication station 22 may be configured to determine a user's eligibility for a tax refund by machine-reading an identifier (i.e., determining whether at least one condition required for a second transaction to be performed is met). In this example, the authentication station 22 determines eligibility by reading information from the identifier and verifying the information against an internal database containing information on domestic / non-eligible shoppers. In this case, a user may be considered eligible if their nationality or status is not on the list (negative approval). Alternatively, or additionally, the authentication station 22 may be capable of determining eligibility by verifying the information against an internal database containing information on non-domestic / eligible shoppers. In this case, a user may be considered eligible if their nationality or status is on the list (positive approval).

[0064] As described above, the authentication station 22 may also be equipped with fingerprint scanner and / or camera technology, which can be used to verify the user's identity using biometric information stored on a machine-readable user identifier (e.g., an identity document such as a passport).

[0065] If the user's eligibility is determined at the authentication station 22, the authentication station 22 may then be configured to prompt the user to present a shopper identifier. If the user presents a shopper identifier, the authentication station 22 may then be configured to pass one or more authentication request messages to the customs approval system 26 via the message switch 24, requesting a list of all tax refund transaction records associated with the user from all TROs.

[0066] In another example, the authentication station 22 may be configured to prompt the user to enter a shopper identifier and then pass an authentication request message to the customs approval system to request approval based on both the user's eligibility and the transaction recorded in association with the transaction. In this other example, the authentication station 22 may send an authentication request message containing information from the shopper identifier, and the customs approval system may determine whether to authenticate the eligibility and the transaction.

[0067] The customs approval system 26 can be configured to respond to an authentication request message by retrieving all transactions associated with the shopper identifier from its own database and / or the acquisition host system 20, and can apply the rules set out to determine approval or rejection.

[0068] In one example, the customs approval system 26 can be configured to either automatically approve transactions based on pre-defined rules ("green channel") or automatically reject transactions based on rules also set within the customs approval system 26 ("red channel").

[0069] When the customs approval system 26 makes a decision (approval / rejection) regarding a transaction, the approval message (authentication request response message) is automatically routed through the message switch 24 and returned to the appropriate acquisition host system 20. The acquisition host system 20 updates the existing tax refund transaction record regarding the transaction using the approval message (approval, rejection, modification).

[0070] The decision to pay the refund rests with the TRO, as the TRO is responsible to the tax authorities for the transaction. For this reason, the customs approval host does not function as a payment approval host, but the TRO's acquisition host system 20 is the record-keeping system.

[0071] Each acquisition host system 20 formats a refund message and sends it to the authentication station, indicating which transactions have been approved for "Green Channel" automatic payment. The TRO that issued the shopper identifier is given the first position on the authentication station, and its transactions are displayed.

[0072] If all searched transactions have approved codes, the user is given the "Green Channel" service and is asked how the refund should be paid. If any of the transactions are not approved, the user is given the "Red Channel" service and is asked to present themselves to customs officials for further processing.

[0073] If an NCPT (Non-Consuming Transaction Subject) such as a payment card (e.g., a credit or debit card) is provided in connection with an approved first transaction, a refund (second transaction) may be automatically made to the registered payment card. If there is no transaction subject associated with one or more of the first transactions, the authentication station may access a server device, such as the server device described in relation to Figure 2, and provide the shopper 12 with the option to select a payment subject and associate it with one or more of the first transactions. Alternatively, or additionally, the shopper may be provided with the option to swipe the card to which the refund should be made.

[0074] If a user requests a refund for a cash substitute and uses a shopper identifier issued by TRO that can remember the cash amount, the refund amount can then be credited to the shopper identifier.

[0075] If a user requests a refund in the form of a cash substitute and the user has not used a shopper identifier issued by TRO, a card with stored values ​​may be issued from authentication station 22.

[0076] The process described above is repeated for each remaining TRO that has a transaction associated with a shopper identifier.

[0077] If red channel processing is indicated, the authentication station then prompts the user to present the shopper identifier to the customs officer, who can then use the shopper identifier to initiate processing. Customs officials may be provided with an approval station that is associated with or forms part of the customs approval system 26. However, in other examples, the approval station may be separate and / or remote from the customs approval system and may communicate with the customs approval system, for example, via a message switch.

[0078] In response to the input of a shopper identifier (for example, by swiping the card if the shopper identifier is a magnetic stripe card, or by scanning a machine-readable identifier representing the address of the cryptocurrency wallet if the shopper identifier is a cryptocurrency wallet), the approval station can be configured to use the shopper identifier to send an information retrieval message to the customs approval system 26, which can then retrieve a list of approved and rejected transactions associated with the shopper identifier.

[0079] The customs officer can then approve or reject each transaction, or change its value. The customs officer can enter the result of their decision using the input device(s) of the approval station 28. The customs officer's decision is communicated by the customs approval system 26 to the appropriate acquisition host system 20 via the message switch 24. Here, the acquisition host system 20 includes tax refund transactions with approval codes (approved, rejected, or changed value).

[0080] The user then returns to authentication station 22, presents their shopper identifier once again, and may be prompted to proceed with the refund as discussed above.

[0081] The customs approval system 26 can be configured to operate in one or both of two modes of operation. In one mode of operation, transaction information is stored on each acquisition host system 20. In the first mode of operation, the customs approval system 26 is operable to retrieve transaction information from each acquisition host system 20 to authenticate a refund. The approval result is communicated via the message switch 24 and returned to the appropriate acquisition host system 20, where the acquisition host system 20 includes tax refund transactions with approval codes (approved, rejected, changed value). In the second mode of operation, the customs approval system maintains in its own database a copy of each transaction associated not only with the relevant shopper identifier but also with the acquisition host system identifier. In this case, the customs approval system 26 also passes and returns the transaction and approval code to the relevant acquisition host system 20. The difference between the two modes is that in the second mode, the customs approval system maintains copies of all data from all acquisition host systems 20.

[0082] Secure transmission, messaging, and protocols can be used to communicate information using existing software, equipment, and processes for handling secure financial transactions known as electronic payments. Standard-based message formats can therefore be used to transmit refund transactions. The use of standard message formats allows for multiple TRO providers while ensuring that Customs and Internal Revenue Services only need to deal with a single system for approval.

[0083] By recording the transaction on the acquisition host system 20 and / or customs approval system 26 using the transaction identifier, purchase value, and shopper identifier, and by further maintaining user detail records associated with the shopper identifier in the acquisition host system, the customs approval system 26 can be configured to retrieve the refund transaction from the TRO's acquisition host system 20 based on the presentation of the shopper identifier, provide a "yes / no" response to the request for authorization for the refund, and transmit the result to the acquisition host system 20.

[0084] In the example shown, communication between the acquisition host system(s) 20 and the customs approval system 26 can be performed by a message switch 24. The message switch 24 can provide a dedicated network between the customs approval system 26 and the acquisition host system 20 for one or more TROs. In addition to a dedicated network, communication may also be performed via a secure switching channel that operates over a public network such as the Internet.

[0085] In an exemplary embodiment, an automated authentication station (kiosk) 22 can be provided that enables automated pre-screening of refund transactions and generates "red channel / green channel" responses without human intervention. The automated pre-screening process can be performed, for example, using the authentication station 22 (e.g., kiosk) at the exit point from the region.

[0086] The authentication station 22 or an authorization system communicating with the authentication station 22 (e.g., a customs authorization system 26) may be provided with rules defining “red channel” requirements, for example, for high-value purchases and / or certain types of purchases. “Red channel” behavior may require the user to present a shopper identifier, shopping receipt, passport, and purchased goods to a customs officer for authorization.

[0087] The authentication station 22 or the authorization system 26 communicating with the authentication station is provided with rules that define the status of the "green channel," and may provide automatic approval for low-value items and / or purchases by shoppers from certain countries.

[0088] Figure 5 is a schematic system diagram that provides an overview of the exemplary overall system configuration of an exemplary embodiment, in which various systems are connected via a network 15, such as the Internet.

[0089] Figure 5 shows multiple user computers 13 (e.g., desktops, laptops, personal data assistants, mobile phones, etc.) connected to the network 15. The user computers 13 are used by users (e.g., travelers and / or shoppers) to access websites and register shopper identifiers. The websites may be provided, for illustrative purposes only, by one of several TROs, tourist agencies, or travel agencies or authorities.

[0090] Figure 5 shows a plurality of input stations 17 connected to a network 15. The input stations 17 may be provided, for example, at entry points (e.g., immigration areas at airports), tourist information centers, retail stores, etc. The input stations 17 may comprise one or more input interfaces, such as one or more forms of a keypad, keyboard, touch-sensitive screen, passport or other ID document reader, card reader, scanner, voice-activated input, and one or more output interfaces, such as one or more forms of a display, printer, card writer and / or dispenser, speaker, etc. In an exemplary embodiment, the input station may be operable to issue a shopper identifier, such as a card having a unique identifier.

[0091] Figure 5 shows a plurality of sales equipment 14 connected to the network 15. Each sales equipment 14 may be accompanied by one or more computer systems, each of which comprises one or more processors including processing logic, memory, and one or more input interfaces, which may include one or more forms of, for example, a keypad, keyboard, touch-sensitive screen, card reader, scanner, and voice-activated input, and one or more output interfaces, which may include one or more forms of, for example, a display, printer, card writer, and speaker.

[0092] Figure 5 shows multiple TRO acquisition host systems 20 connected to network 15. Each acquisition host system may be accompanied by one or more computer systems, each comprising one or more processors containing processing logic and memory.

[0093] Figure 5 shows a message switch 24 connected to network 15. In this example, the message switch 24 acts as a communication interface between the acquisition host system 20, the authentication station, and the customs approval system 26.

[0094] Figure 5 shows a plurality of authentication devices 22 connected to the network 15. The authentication devices 22 may be located at the departure point (e.g., the departure area of ​​an airport). The authentication device 22 may include one or more input interfaces, such as one or more of the following: a keypad, keyboard, touch-sensitive screen, passport or other ID document reader, card reader, scanner, or voice-activated input; and one or more output interfaces, such as one or more of the following: a display, printer, card writer and / or dispenser, or speaker. The authentication device may also include one or more devices for inputting user biometric information, such as a fingerprint scanner or camera.

[0095] The user's familiarity with automated teller machines (ATMs) and similar devices means that authentication stations in the form of self-service kiosks at departure points are acceptable to users.

[0096] As described above, in one example, the authentication station 22 may be equipped with a reader for automatically reading machine-readable identifiers (e.g., machine-readable identification information such as a machine-readable passport), thereby enabling automatic verification of the user's identity and eligibility for a refund. The authentication station 22 may prompt the user to present a shopper identifier. Similarly, as shown above, the shopper identifier may take the form of a magnetic stripe card, a chip card, a barcode, a QR code (e.g., displayed on a mobile communication device belonging to the user), or a number that needs to be entered into a keypad.

[0097] The authentication device can then determine eligibility for a refund based on information held in the customs approval system or the TRO acquisition host system, and define one or more purchases associated with an identifier to determine whether to authenticate a refund associated with one or more purchases. Optionally, the authentication station 22 can receive biometric information and cross-verify it against the information held on the machine-readable identifier to verify the user's identity.

[0098] In one example, the authentication device, in response to the input of a shopper identifier, sends a request to the server for information defining one or more purchases associated with the identifier, compares the information defining one or more purchases associated with the identifier received from the server with predefined rules to determine whether to authenticate the refund, and has the output interface indicate to the user whether the refund was automatically authenticated (i.e., whether authentication was performed automatically). If the refund is authenticated, the authentication station can send confirmation to the server that authentication was performed for the refund (second transaction) to be executed.

[0099] In another example, the authentication station can send a request to the server in response to the input of a shopper identifier to determine whether to authenticate the refund, and in response to the server's response indicating whether the refund has been authenticated for one or more purchases, the output interface can indicate to the user whether the refund has been authenticated (i.e., whether authentication is performed automatically).

[0100] Alternatively, users may be prompted to report to customs officers for manual verification.

[0101] The authentication device may also be capable of prompting the user to identify the transaction object to which the refund should be made (e.g., to a credit card or in cash) if the transaction object has not yet been provided for one or more first transactions. If the user chooses a credit card, the transaction may be automatically refunded. If the user chooses cash, the user may then be issued a fully valid debit card with the refund amount, or may be prompted to go to an airside location to receive the cash. If the user chooses cryptocurrency, the transaction may be automatically refunded to a cryptocurrency wallet, or the user may be prompted to provide the address of their cryptocurrency wallet as described above.

[0102] If the response is a "red channel," the user will be prompted to indicate how the refund should be processed if approved, and the user may then be directed to a customs office for further verification.

[0103] At the customs counter, the customs office can use an authorization station to retrieve information about the server system using a shopper identifier.

[0104] The approval station may include one or more input interfaces in the form of one or more of the following: a keypad, keyboard, touch-sensitive screen, card reader, scanner, and voice-activated input; and one or more output interfaces in the form of one or more of the following: a display, printer, card writer, and speaker.

[0105] Using the shopper identifier, customs officers can retrieve transaction information from the server system, inspect documents and goods, and decide whether to approve or deny a refund.

[0106] If a refund is approved and the user has requested a refund to their credit card, the money may then be automatically transferred to the credit card in response to the customs officer approving the refund using an approval station. Alternatively, a debit card may be generated by an approval station or an authentication station.

[0107] Figure 6 schematically illustrates the interaction between the client system 230, the Generalized Payment Target (GPT) database 231, the centralized solution 232 (an example of a server device), and the analytical data service 233. The client system 230 may be provided, for example, in the form of a merchant device, a point-of-sale system, or an authentication kiosk, and includes the client device 210 as described in relation to Figure 1. The client system 230 is configured to communicate with the GPT 231 and the centralized solution 232 in order to register new NCPTs and to retrieve NCPTs from the centralized solution 232 associated with the user's first transaction. A GPT is a system that can store data that identifies different types of NCPTs, such as credit cards, debit cards, bank accounts, and mobile wallets, along with the capabilities of these NCPTs. Generally, a GPT stores all the information (details) necessary to carry out a payment transaction; for example, with respect to a credit card, the information includes the PAN (Primary Account Number) scheme, the cardholder's name, and the expiration date. Regarding bank accounts, the information includes the bank code and account number, bank name, and bank account holder name. Capability may relate to any information indicating the use of the NCPT. For example, capability may identify whether the NCPT is creditable (money can be sent to the NCPT), debitable (money can be debited from the NCPT), and / or reversible (payment transactions to this NCPT can be reversed). Capability may also indicate whether the NCPT is reusable (for example, to distinguish it from a disposable card). The ADS is a system that holds metadata about the use of the NCPT in any user-facing system or application related to tax-free shopping. The metadata may be used to differentiate the relative likelihood of a given NCPT being selected by a user when multiple NCPTs are presented. NCPT searching is described below in relation to Figure 7.

[0108] The registration of a new NCPT is initiated by the client system 230. The client system can receive a mark of a new NCPT, which may be entered or identified by the user in a first transaction, for example, to be associated with a previous first transaction. In the first step (1), the client system 230 triggers the GPT database 231 to register the new NCPT. The GPT database 231 can identify the new NCPT and store details that may be used to perform a second transaction and transfer a refund to the new NCPT. In the second step (2), the GPT database 231 returns the capabilities of the new NCPT to the client system 230. The returned capabilities may be sufficient to identify the new NCPT without providing sensitive details of the NCPT. For example, the returned capabilities may include hashed data that can be used to identify the NCPT but does not disclose sensitive details of the NCPT, such as the user's bank details. In the third step (3), the client system 230 transfers the capabilities and attributes of the NCPT to the centralized solution 232 so that they may be stored as transactional objects that can be associated with the user's first transaction. In the fourth step (4), the centralized solution 232 sends the metadata to the ADS 233. The ADS 233 stores the metadata related to the NCPT and returns confirmation to the centralized solution 232 in the fifth step (5). The received metadata is then retrieved by the centralized solution 232 to rank the NCPTs, where multiple NCPTs are provided to a given user.

[0109] Figure 7 schematically illustrates the interaction between the client system 230, the centralized solution 232, and the GPT database 231. The client system 230 receives user identification information and first transaction data related to transactions performed by the user. The client system 230 generates a request for transaction data (e.g., a request for an NCPT associated with the user) and, in the first step (1), issues the request to the centralized solution 232. The request includes user identification information. The centralized solution 232 receives the request and performs a lookup to identify the payment object associated with the user based on the user identification information. The lookup returns any payment object marks associated with the received user identification information. In step (2), the centralized solution 232 sends the NCPT marks identified in the lookup to the GPT 231, and the GPT 231 looks up GPT capability marks and returns them to the centralized solution 232 in step (3). Capabilities can indicate whether the NCPT is creditable (money can be sent to the NCPT), debitable (money can be debited from the NCPT), and / or reversible (the payment transaction to this NCPT can be reversed). Capabilities can also indicate whether the NCPT is reusable (for example, to distinguish it from a disposable card). In step (4), the centralized solution 232 returns a response to the client system 230 that includes a list of payables identified in the search, the capabilities of the payables, and information indicating the strength of the payables, such as an indicator of whether the payable has been previously selected by the user. The client system 230 provides the user with an indicator of the payables, which may be displayed on the client system's display screen, and the user selects a payable to associate with the first transaction. In step (5), the user's selection is returned to the centralized solution to be stored in association with the transaction details.

[0110] Figure 8 schematically shows the sequence of steps performed according to a part of the configuration of this technology. The steps are divided into those performed by the shopper, those performed by the client device, and those performed by the server device. The flow starts in step S80, where the shopper initiates the first transaction and provides the shopper's user identification information. The flow then proceeds to step S81, where the client device determines whether a non-cash purchase (NCPT) is required for the shopper. If it is determined in step S81 that an NCPT is not required for the shopper, the flow then proceeds to step S84, where the client device proceeds with the rest of the transaction as usual before the flow ends in step S94. If it is determined in step S81 that a purchase is required for the shopper, the flow then proceeds to step S82. In step S82, the client device sends a search request to the server device containing the user identification information and requests purchase information. The flow then proceeds to step S83, where the server device performs a search to determine whether any purchase information associated with the user information exists. An example of a search is described below in relation to Figure 13. The server device then returns the chosen payment item to the client device, and the flow proceeds to step S86. In step S86, the client device receives the payment item information and determines whether any appropriate payment item has been identified. If it is determined in step S86 that an appropriate payment item has been found, the client device then identifies the payment item to the user, and the flow proceeds to step S85. In step S85, it is determined whether the shopper accepts one of the payment items. If it is determined in step S85 that the shopper accepts one of the payment items, the flow then proceeds to step S95, where the client device associates the payment item with the first transaction and continues the rest of the transaction. The flow then proceeds to step S91, where the client device sends feedback to the server device.The flow then proceeds to step S92, where the server device receives feedback information from the client device, which can be used, for example, to update usage information related to the payment item, thereby allowing the more conventionally selected payment item to be identified to the user during future transactions. The flow then terminates in step S93.

[0111] If no suitable payment object is identified in step S86, the flow then proceeds to step S87. Additionally, if the shopper does not accept one of the identified payment objects in step S85, the flow then proceeds to step S87. In step S87, it is determined whether the shopper has provided a new payment object to be captured and stored. If the shopper has not provided a new payment object in step S87, the flow then proceeds to step S84, where the client device continues the transaction before the flow terminates in step S94. If it is determined in step S87 that the shopper has already provided a new payment object, the flow then proceeds to step S88, where the client device sends the payment object information to the server device to capture the payment object. The flow then proceeds to step S89, where the server device performs the payment object capture process. An example of the payment object capture process is described in relation to Figure 9. The flow then proceeds to step S90, where the client device identifies whether the user intends to capture another payment object. If it is determined in step S90 that the user does not wish to capture another payment target, the flow then proceeds to step S84, where the remainder of the process continues and the transaction is optionally associated with one of the payment targets provided by the user. If it is determined in step S90 that the user wishes to capture another payment target, the flow then returns to step S87.

[0112] Figure 9 schematically shows the details of the payment target acquisition process in a part of the configuration of this technology. The flow is initiated by the client device in step S100, where it is determined that a new payment target should be registered. The flow then proceeds to step S101, where the client device issues a request to the server device to register the new payment target. The request is passed to the GPT database, where the capabilities of the payment target are verified in step S102. The flow then proceeds to step S105, where the capabilities of the payment target are returned to the client device. The flow then proceeds to step S104, where the client device determines whether to accept the payment target based on its capabilities. For example, if the payment target is described as a disposable payment target, the client device may reject (not accept) the payment target. Alternatively, if the payment target is described as creditable only, i.e., not debitable or revocable, the client device may choose to reject it. If the client device determines in step S104 that it is not possible to accept the payment target, the flow then proceeds to step S103, where an error is returned. The flow then proceeds to step S106, where the client device determines whether the shopper wishes to capture another payment item. If it is determined in step S106 that the shopper does not wish to capture another payment item, the flow then proceeds to step S110, where the payment item capture process ends and the client device continues the transaction.

[0113] In step S104, if the client device determines that the payment item can be accepted, the flow then proceeds to step S110, where the client device continues the transaction. Additionally, the flow proceeds to step S107, where the client device sends an identifier (NCID) to the server device. The flow then proceeds to step S108, where the server device receives the payment item ID and proceeds to request the attributes of the payment item from the analysis server. The flow then proceeds to step S109, where the analysis server performs a lookup based on the payment item ID and returns the attributes to the server device. In step S111, the server device associates the payment item with the shopper by storing the payment item ID in association with the shopper identification information.

[0114] The flow then proceeds to step S112, where the server identifies whether the payment target is a strong payment target or a weak payment target. In particular, in step S112, the server device determines whether this is the first time the payment target identifier has been captured. If it is determined in step S112 that this is the first time the payment target has been identified, the flow then proceeds to step S113, where the attributes received from the analysis server are checked before the flow proceeds to step S115. If it is determined in step S112 that this is not the first time the payment target has been identified, the flow then proceeds to step S114, where the current status of the payment target is identified, i.e., it is determined whether the payment target is currently identified as a strong payment target, which is more likely to be selected by the user or accepted by the client device, or as a weak payment target, which is less likely to be selected by the user or accepted by the client device. If it is determined in step S114 that the current status of the payment target is a weak payment target, the flow then proceeds to step S113 as described above. In step S114, if the current status of the payable is determined to be strong, the flow then proceeds to step S115. In step S115, the status of the payable is updated based on the current status of the payable (in this case, the payable has been previously viewed) and the attributes of the payable. In step S115, if it is determined that the payable is to be set as a strong payable, the flow then proceeds to step S116, where the payable is set as a strong payable before the flow proceeds to step S118. In step S115, if it is determined that the status is to be set as weak, the flow then proceeds to step S117, where the status of the payable is set as weak before the flow proceeds to step S118. In step S118, the metadata associated with the payable is updated. For example, the date field is updated to show the current date and time when the payable was captured.The flow then proceeds to step S119, where it is determined whether the payment target is currently deactivated (for example, deselected or disabled), i.e., whether a prior indication has been received requesting the system to stop providing a particular payment target. If it is determined in step S119 that the payment target is not currently deactivated, the flow then proceeds to S121, where the flow terminates. If it is determined in step S119 that the payment target is currently deactivated, the flow then proceeds to step S120, where the payment target is activated before the flow proceeds to step S121, and the flow terminates in step S121.

[0115] The strength of the payment item and the date information associated with the payment item can be used to order the payment items for the user's selection. For example, stronger payment items may be presented to the user before weaker payment items, and more recently acquired payment items may be presented before earlier acquired payment items. In some configurations, only the highest-ranked payment items are presented to the shopper. In some configurations, only strong payment items are presented to the shopper. The following example illustrates the ordering of payment items.

[0116] In the first exemplary scenario, a shopper has one payment object NCPT1 proposed at store A. In this scenario, the payment object is the only payment object associated with the shopper. The shopper captures a new payment object NCPT2 at store A. Then, for example, 15 minutes later, the shopper visits a second store, store B. The server device adjusts the ordering of payment objects, and when the shopper makes the first transaction at store B, the server device returns payment objects NCPT2 and NCPT1 ordered so that NCPT2 is presented above NCPT1.

[0117] In a second exemplary scenario, a shopper has one payment object NCPT1 offered at store A. In this scenario, the payment object is the only payment object associated with the shopper. The shopper indicates that they no longer wish to receive the offer of this payment object, for example, by selecting the option "Stop offering this NCPT". Then, for example, 15 minutes later, the shopper visits a second store, store B. The server device does not return any payment objects at store B when the shopper performs the first transaction.

[0118] Figure 10 schematically illustrates the transition of a payment object between being a strong payment object and a weak payment object. When a payment object is first captured, it may be recorded as (1) a strong payment object, or (2) a weak payment object, based on, for example, the ability of the payment object at the time of capture. The term “strong” as used herein indicates that the payment object is more reliable, and the term “weak” as used herein indicates that the payment object is less likely to be reliable. Whether a payment object is captured as “strong” or “weak” may depend on various conditions, such as how the NCPT was captured and who captured the NCPT. For example, an NCPT captured using a device (e.g., a card reader) is more likely to be recorded as a “strong” NCPT. On the other hand, a device captured manually (e.g., by manually entering card details) is more likely to be recorded as a “weak” NCPT because it is more likely that inaccurate data is being used. Furthermore, NCPTs captured by shoppers are more likely to be recorded as “stronger” than those captured by other parties, such as sellers, refund officers, or customs officers. There are also various conditions under which a strong payment subject can be downgraded to a weak payment subject, and vice versa. For example, if a strong payment subject is recaptured under “strong” conditions (3), it remains a strong payment subject. Similarly, if a strong payment subject is recaptured under “weak” conditions (4), it remains a strong payment subject. If a weak payment subject is recaptured under weak conditions (5), it then remains a weak payment subject. If a weak payment subject is recaptured under strong conditions (6), it then is upgraded to a strong payment subject. Strong and weak payment subjects can also change depending on the set of rules. For example, there may be a normal downgrade rule (7) that causes a strong payment subject to be downgraded to a weak payment subject in response to a reconfirmation of the conditions for strong and weak payment subjects.Alternatively, there may be a standard upgrade rule (8) that causes a weak payment subject to be upgraded to a strong payment subject in response to a reaffirmation of the conditions for strong and weak payment subjects.

[0119] Figure 11 schematically illustrates the transition of a payment target between being a valid payment target and an invalid payment target. Initially, a captured payment target is captured as a valid payment target. A captured payment target may transition to an invalid payment target, for example, in response to a user indicating that they do not wish to be offered that payment target in the future. An invalid payment target may be upgraded to a valid payment target, for example, in response to the payment target being recaptured.

[0120] Figure 12 schematically illustrates the sequence of steps that may be performed to cause a payable object to be upgraded from a weak payable object to a strong payable object, and / or to cause a payable object to be downgraded from a strong payable object to a weak payable object. For example, the flow shown in Figure 12 may be performed periodically, for example, after a fixed time period such as every few hours, every few days, every few weeks, or every few months. Alternatively, the flow may be performed for a given user in response to an action associated with the user, for example, the user recording a new NCPT or a payment being attempted against the user's NCPT. The flow may be performed after a fixed time period following an action associated with the user, for example, after a fixed number of hours, days, weeks, or months. The flow starts in step S130 and proceeds to step S131. In step S131, all captured payable objects are checked against a set of upgrade and downgrade rules. The upgrade and downgrade rules may be provided, for example, by a system administrator. The flow then proceeds to step S132, where it is determined whether each payment object should be upgraded or downgraded. If, in step S132, it is determined that a given payment object should be downgraded from a strong payment object to a weak payment object, the flow then proceeds to step S135, where the payment object is downgraded to a weak one. The flow then proceeds to step S133, where the date field associated with the object is updated before the flow ends in step S134. If, in step S132, it is determined that the status of a given payment object should remain the same, the flow then proceeds directly to step S133 and proceeds as described above. If, in step S132, it is determined that the status of a given payment object should be upgraded to a strong one, the flow then proceeds to step S136, where the status of the payment object is set to strong. The flow then proceeds to step S133 and proceeds as described above.

[0121] Figure 13 schematically shows the sequence of steps performed during a search for a transaction object in a configuration of this technology. The flow starts at step S140, where the shopper's identification information and one or more client device attributes are received by the server device. The flow then proceeds to step S141, where the server device uses the shopper's identification information to perform a search and identify a payment object associated with the shopper. The flow then proceeds to step S142, where it is determined whether the number of potential payment objects found is greater than zero. If the number of potential payment objects found is not greater than zero, the flow then proceeds to step S160, where the server device indicates to the client system that no suitable payment objects were found. The flow then proceeds to step S159, where the search for payment objects ends, and the server device may move on to capturing one or more payment objects, as described, for example, in relation to Figure 9.

[0122] If it is determined in step S142 that one or more payables have been found, the payables are then shown in the GPT database and the flow proceeds to step S143. In step S143, GPT retrieves the capabilities of each payable and the strength of these payables. The flow then proceeds to step S145, where the retrieved capabilities are stored for transmission back to the server device. The flow then proceeds to step S144, where it is determined whether any further potential payables exist. If it is determined in step S144 that further potential payables exist, the flow then proceeds to step S143. If it is determined in step S144 that no further payables exist, the flow then proceeds to step S149, where the GPT capabilities and the strength of the payables are returned to the server device.

[0123] The flow then proceeds to step S148, where the server device determines whether there are any payment targets in which all GPT functions are set to false. If, in step S148, it is determined that there are several payment targets in which all GPT functions are set to false, such as payment targets in which all capabilities (creditable, debitable, revocable, etc.) are set to FALSE, the flow then proceeds to step S153, where payment targets in which all GPT functions are set to false are deleted. The flow then proceeds to step S152, where it is determined whether any payment targets remain. If, in step S152, it is determined that there are no remaining payment targets, the flow then proceeds to step S160 as described above. If, in step S152, it is determined that there are remaining payment targets, the flow then proceeds to step S147, where each of the remaining payment targets is examined and determined to be either a strong payment target or a weak payment target. If, in step S148, it is determined that there are no payment targets in which all GPT functions are false, the flow then proceeds to step S147 as described above. The flow proceeds from step S147 to step S146, where it is determined whether any weak payables exist.

[0124] If it is determined in step S146 that there are no weak payables, the flow then proceeds to step S156, where the payables are sorted according to the ordering rules for strong payables, for example, the payables may be sorted by the date they were last updated. The flow then proceeds to step S155, where the strongest to the least strong payables, up to M in number, are returned to the client system for display, along with any associated metadata, where M is an integer greater than or equal to 1. The flow then proceeds to step S154, where the payable search process ends. If it is determined in step S146 that there is one or more weak payables, the flow then proceeds to step S150, where it is determined whether the client device can accept weak payables. If it is determined in step S150 that the client device can accept weak payables, the flow then proceeds to step S157, where strong payables are ordered above weak payables (for example, as described in relation to step S156) before strong and weak payables are further sorted. The flow then proceeds to step S156 as described above. If it is determined in step S150 that the client device is not capable of accepting weak payment items, the flow then proceeds to step S151, where the weak payment items are removed. The flow then proceeds to step S158, where the number of remaining payment items is determined. If it is determined in step S158 that there are no remaining payment items, the flow then proceeds to step S160 as described above. If it is determined in step S158 that there are remaining payment items, the flow then proceeds to step S156 as described above.

[0125] Although the above configurations have been described in relation to specific devices and methods, in some configurations the above method steps may be provided as a computer, a computer program. The computer program may be stored on a computer-readable medium, such as a non-temporary computer-readable medium. The computer program includes multiple lines of program code that, when executed by one or more processors, cause a computer, point-of-sale device, or general-purpose client / server system having one or more processors to perform one or more of the steps of the method described herein. For example, one or more existing point-of-sale devices may be modified to include computer-readable code that causes one or more point-of-sale devices to operate as the above-described client devices. Alternatively, or in addition, one or more existing servers may be configured to function as the above-described server devices.

[0126] As a concise overall summary, a client device, a method for operating the client device, a server device, and a method for operating the server device are provided. The client device comprises a receiving circuit configured to receive user identification information indicating the identity of a user and first transaction data indicating the user's first transaction. The device also comprises a control circuit configured to retrieve transaction target data stored in association with the user identification information. The control circuit associates the transaction target with the first transaction data in response to the selection of a transaction target from the transaction target data, enabling a second transaction, conditional on the first transaction, to be processed at a point in time after the first transaction, in response to the fulfillment of at least one condition.

[0127] In this patent application, the phrase “configured to…” is used to mean that the elements of the device have a configuration capable of performing a defined operation. In this context, “configuration” means the arrangement or manner of hardware or software interconnections. For example, the device may have dedicated hardware to provide the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to…” does not imply that the elements of the device are required to be modified in any way to provide the defined operation.

[0128] In this application, the list of features following the phrase "at least one of" means that any one or more of those features may be provided individually or in combination. For example, "[A], [B] and [C]" includes any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), a combination of A and B (without C), a combination of A and C (without B), a combination of B and C (without A), or a combination of A, B and C.

[0129] While exemplary configurations of the present invention have been described in detail herein with reference to the accompanying drawings, it will be understood by those skilled in the art that the present invention is not limited to those exact embodiments, and that various changes, additions, and modifications can be made to the embodiments without departing from the scope of the invention as defined by the appended claims. For example, various combinations of the dependent features can be made using the independent features without departing from the scope of the invention.

Claims

1. A receiving circuit configured to receive user identification information indicating the user's identity and first transaction data indicating the user's first transaction, A control circuit configured to search for transaction target data stored in association with the user identification information, Equipped with, The control circuit associates the trading target with the first trading data in response to the selection of a trading target from the trading target data, enabling a second transaction conditional on the first transaction to be processed at a later point in time after the first transaction, in response to the fulfillment of at least one condition. Client device.

2. The transaction subject includes enough data to enable the second transaction to be processed without the user having to provide any further data at a later point in time to trigger the second transaction. The client device according to claim 1.

3. The control circuit is configured to trigger the search for the transaction target data from the server device. The client device according to claim 1 or 2.

4. The control circuit transmits the transaction target to the transaction server device in response to the selection. The client device according to claim 3.

5. The control circuit is configured to provide a first trading target identified in the first trading data for selection as a trading target. The client device according to any one of claims 1 to 4.

6. The first transaction includes a first transfer from the user to a further transaction entity, and the second transaction includes a second transfer from the further transaction entity to the transaction entity. The client device according to any one of claims 1 to 5.

7. The amount included in the first remittance is equal to or greater than the amount included in the second remittance. The client device according to claim 6.

8. The first transaction is a purchase transaction, and the second transaction is a refund transaction. The client device according to any one of claims 1 to 7.

9. The aforementioned refund transaction is a tax refund transaction. The client device according to claim 8.

10. The above at least one condition includes an approval condition, and the approval condition is satisfied in response to the receipt of an approval message generated from a third-party device. The client device according to any one of claims 1 to 9.

11. The control circuit, in response to a deselected trading target, triggers a mechanism to exclude the deselected trading target from future instances of searching for trading target data. The client device according to any one of claims 1 to 10.

12. The control circuit is configured to present the transaction items for selection by the user. The client device according to any one of claims 1 to 11.

13. The aforementioned transaction target data includes a ranking of the transaction targets, and the control circuit is configured to present the transaction targets according to the ranking. The client device according to claim 12.

14. The transaction data includes at least one previous transaction associated with the user's previous transactions, The client device according to any one of claims 1 to 13.

15. The steps include receiving user identification information indicating the user's identity and first transaction data indicating the user's first transaction, The steps include: triggering a search for transaction data stored in association with the user identification information; A step of associating the transaction target with the first transaction data in response to the selection of the transaction target from the transaction target data, thereby enabling a second transaction conditional on the first transaction to be processed at a point in time after the first transaction in response to the fulfillment of at least one condition, A method for operating a client device, including [specific details omitted].

16. A storage circuit configured to store transaction data associated with each of a plurality of users, wherein the transaction data identifies one or more transaction items, and when the one or more transaction items are associated with a first transaction among the one or more first transactions, the storage circuit enables processing of a second transaction associated with the first transaction and conditional on the first transaction in response to at least one condition being met at a point in time after the first transaction. A control circuit that, in response to receiving a transaction data request from a client device that includes identification information of a given user, performs a search in the storage circuit using the identification information, and in response to the search being successful in the storage circuit, returns the transaction data associated with the given user to the client device. A server device equipped with the following features.

17. The control circuit, in response to a request to invalidate an object, which indicates one of the one or more objects associated with the given user, marks one of the one or more objects as invalid. The control circuit is configured to exclude trade targets marked as invalid from the returned trade target data. The server device according to claim 16.

18. The control circuit, in response to receiving new transaction data specifying a given user and a given transaction object, assigns the given transaction object data to the transaction object data associated with the given user if the given transaction object is not included in the transaction object data associated with the given user. The server device according to claim 16 or 17.

19. The control circuit, in response to an indication that the second transaction using the selected trading object was unsuccessful, returns the one or more trading objects associated with the given user if the trading object data of the given user indicates one or more trading objects other than the selected trading object, thereby enabling the second transaction to be re-triggered using one of the one or more trading objects. The server device according to claim 18.

20. The control circuit, in response to receiving selection data that identifies a plurality of given transaction objects associated with a given user and having an associated transaction object order, stores the associated transaction object order in association with the given user. A server device according to any one of claims 16 to 19.

21. The control circuit, in response to a request from a second trading server configured to execute the second transaction in response to the fulfillment of at least one of the conditions, transmits the plurality of given trading objects and the order of the trading objects to the second trading server, enabling the second transaction to be executed using each of the plurality of given trading objects in accordance with the associated order of trading objects until the second transaction is successfully executed. The server device according to claim 20.

22. The above at least one condition includes an approval condition, and the approval condition is satisfied in response to an approval message generated from a third-party device. A server device according to any one of claims 16 to 21.

23. The aforementioned transaction data includes the ranking of the aforementioned transaction targets. A server device according to any one of claims 16 to 22.

24. A step of storing transaction data associated with each of a plurality of users, wherein the transaction data identifies one or more transaction items, and when the one or more transaction items are associated with a first transaction among the one or more first transactions, the storage step enables that a second transaction associated with the first transaction and conditional on the first transaction is processed in response to at least one condition being met at a point in time after the first transaction. Steps include: receiving a transaction data request from a client device that includes identification information of a given user, performing a search in a storage circuit using the identification information, and returning the transaction data associated with the given user to the client device in response to the search being successful in the storage circuit; A method for operating a server device, including [specific details omitted].

25. A computer program that includes a computer-readable instruction, wherein when the computer-readable instruction is executed by a processing circuit, the processing circuit causes the processing circuit to execute the method of claim 15 or 24.

Images