WO2019119056A1

WO2019119056A1 - Methods and systems for the distribution of goods

Info

Publication number: WO2019119056A1
Application number: PCT/AU2018/051380
Authority: WO
Inventors: Brendan Borg; Simon Borg
Original assignee: Motus Ware Pty Ltd
Priority date: 2017-12-22
Filing date: 2018-12-21
Publication date: 2019-06-27

Abstract

A method and system for the distribution of goods, including: receiving a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller; adding a block to a blockchain, the block containing information identifying at least the amount of tax payable; determining when a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority, has been added to the blockchain; and upon determining that the later block has been added to the blockchain: querying the blockchain to determine the amount of tax payable; and instructing a transaction processor to transfer funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

Description

METHODS AND SYSTEMS FOR THE DISTRIBUTION OF GOODS

Technical Field

[0001] The present invention generally relates to methods and systems for the distribution of goods, and in particular, for collection and remittance of a tax related to goods entering a taxing jurisdiction, e.g., a district, state, or country in which one or more taxes is levied upon the goods.

Background

[0002] In many taxing jurisdictions (e.g., countries, states or districts), taxes are levied upon goods purchased from outside of that taxing jurisdiction.

[0003] For example, a value-added tax (VAT), known in some countries as a goods and services tax (GST), is a type of general consumption tax that is collected incrementally, based on the value of the goods or services, and is usually implemented as a destination- based tax, where the tax rate is based on the location of the customer.

[0004] In recent years, international transactions such as online purchases of goods from vendors located in a different taxing jurisdiction (e.g., a different country) have become increasingly popular. This has posed some difficulties for taxing authorities around the world in collecting consumption-based taxes related to these goods.

[0005] In particular, goods purchased online by individual buyers are usually small in amount and of relatively low values. Taxing these goods would require considerable administrative costs, which may outweigh the revenue generated by the taxation.

[0006] However, with the rapid growth of electronic commerce, more and more taxing authorities around the world have started levying GST or similar taxes upon goods purchased online from overseas, for example, by imposing tax collection obligations upon overseas vendors.

[0007] For instance, the Australian Government has announced that from 1 July 2018,

GST would be applied to all goods purchased by Australian consumers from overseas merchants, including goods below AU$1,000 (which until that date are exempt from the tax). Under the new model, foreign vendors, as well as“electronic distribution platforms” (EDPs), such as Amazon and eBay, would be liable for GST on low value imported goods sold to an Australian consumer. The new legislation is expected to generate an extra $300 million revenue over four years for the Australian Government.

[0008] However, a major challenge in introducing this new regulation is that conventional tax collection technologies are not suitable for efficiently collecting taxes from a large number of vendors located in different countries. Existing tax collection processes typically involve complicated paperwork, and often lead to long processing cycles and waiting times, which may significantly lower the compliance of vendors with any

consumption-based tax regimes (such as the new Australian GST collection requirements).

[0009] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative.

Summary

[0010] The present invention provides a method for the distribution of goods, including:

receiving a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller; adding a block to a blockchain, the block containing information identifying at least the amount of tax payable;

determining when a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority, has been added to the blockchain; and

upon determining that the later block has been added to the blockchain:

querying the blockchain to determine the amount of tax payable; and instructing a transaction processor to transfer funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

[0011] The present invention also provides a system for the distribution of goods, the system including one or more electronic processing devices configured to: receive a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller; add a block to a blockchain, the block containing information identifying at least the amount of tax payable;

determine when a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority, has been added to the blockchain; and

upon determining that the later block has been added to the blockchain:

query the blockchain to determine the amount of tax payable; and instruct a transaction processor to transfer funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

[0012] The present invention further provides a method for the distribution of goods, including:

upon determining that the later block has been added to the blockchain:

causing a transfer of funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

[0013] The present invention further provides a system for the distribution of goods, the system including one or more electronic processing devices configured to:

receive a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller; add a block to a blockchain, the block containing information identifying at least the amount of tax payable;

upon determining that the later block has been added to the blockchain: cause a transfer of funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

[0014] The present invention further provides a system for the distribution of goods, the system including:

a seller computing system;

a tax payment processing computing system configured to receive a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller, the tax payment processing computing system or the seller computing system being further configured to add a block to a blockchain, the block containing information identifying at least the amount of tax payable; and

a destination operator computing system configured to add to the blockchain a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority,

wherein the tax payment processing computing system is further configured to cause a transfer of funds, corresponding to the amount of tax payable, from the holding account to an account associated with the taxing authority upon determining that the later block has been added to the blockchain.

[0015] The present invention further provides a system for the distribution of goods, the system including:

a seller computing system;

a tax payment processing computing system configured to receive a payment completion signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller, the tax payment processing computing system or the seller computing system being further configured to add a block to a blockchain, the block containing information identifying at least the amount of tax payable; and

a destination operator computing system configured to send a goods release signal to the tax payment processing computing system, the goods release signal indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority,

wherein the tax payment processing computing system is further configured to add a later block to the blockchain indicating that the goods are released upon receiving the goods release signal, and to cause a transfer of funds, corresponding to the amount of tax payable, from the holding account to an account associated with the taxing authority.

Brief Description of the Drawings

[0016] Some embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

[0017] Fig. 1 illustrates a schematic diagram of an exemplary system 100 for the distribution of goods;

[0018] Fig. 2 illustrates an exemplary workflow 200 for the distribution of goods;

[0019] Fig. 3 illustrates a schematic diagram of an exemplary system 300 utilising at least one distributed ledger;

[0020] Fig. 4 and Fig. 5 show an exemplary workflow implemented by the system

300 for processing payment of one or more taxes imposed upon goods entering a taxing jurisdiction;

[0021] Fig. 6 illustrates an example of a method 600 executed by the tax payment processing server 110 of Fig. 1 for processing payment of a tax; and

[0022] Fig. 7 shows an exemplary structure of a tax payment processing server 110 of

Fig. 1. Detailed Description

[0023] Described herein are methods and systems for the distribution of goods, and in particular, for collection and remittance of one or more taxes for goods entering a taxing jurisdiction, e.g., a district, state, or country in which the one or more taxes is levied upon the goods.

[0024] In at least some embodiments, the proposed methods and systems utilise at least one distributed ledger to record events relating to the shipment of goods, including associated financial transactions.

[0025] A distributed ledger (which may also be referred to as a“shared ledger”) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple computing devices (which may also be referred to as“nodes”) connected with each other via one or more data communication networks.

[0026] The data is accurately replicated and synchronized across all participating nodes to maintain data integrity, availability and resiliency. Unlike a centralised system, there is no central administrator or single point of control. If a node abruptly fails or stops functioning, the remaining nodes have the data and the capacity to maintain the ledger or all transaction details in the absence of the failed node. In this way, a distributed ledger provides real-time information with reduced error or fail rates of transactions. It also reduces the costs of infrastructure as compared to the centralised system.

[0027] In at least some embodiments, the data related to the shipment of goods is recorded in a blockchain in the distributed ledger.

[0028] A blockchain (which may also be referred to as a“block chain”) is a continuously growing list of records (sometimes referred to as“blocks”) which are linked to each other and secured using cryptography. Each block contains a hash pointer as a link to a previous block, a timestamp and transaction data. The linked blocks form a chain. This iterative process confirms the integrity of the previous block, all the way back to the original genesis block.

[0029] Blockchains are inherently resistant to modification of the data. A blockchain can serve as one form of distributed ledger (which may also be referred to as a“distributed blockchain ledger” or a“blockchain ledger”). Transactions recorded in a blockchain ledger cannot be altered retroactively without the alteration of all subsequent blocks and the collusion of the network. Thus, it can be used to record transactions between multiple parties efficiently and in a traceable and immutable way. It also allows the participants to verify and audit transactions inexpensively.

[0030] A blockchain can be public, permissioned, or private. Anyone can be a user or a node (host) on a public blockchain, while permissioned or private blockchains are operated by a wide but defined group, such as the primary stakeholders of a specific industry. A permissioned or private blockchain is considered to be more efficient and secure compared to a public blockchain, and gives the operating party or parties more control over the rules of the blockchain and who can access the blockchain.

[0031] In at least some embodiments, the methods and systems utilise a permissioned or private blockchain to record data related to the shipment of goods, including associated financial transactions. The permissioned or private blockchain of embodiments of the invention is accessible by users who have registered themselves to a tax payment service (referred to below as the Rapid Release service) provided by the methods and systems described herein. The users may include both sellers (or their representatives) and destination operators (or their representatives). Alternatively, the blockchain used in the methods and systems described herein may be a public blockchain, or a hybrid blockchain (i.e., a blockchain combining a public and private/ permission blockchain).

[0032] In at least some embodiments, the blockchain can be updated by different parties along the life cycle of the shipment of goods, so that the messages and data transferred within the system across the network may be significantly reduced, thereby improving the efficiency of utilisation of network resources. Allowing the blockchain to be updated by different parties rather than a single server may further increase the data transparency and security of the system, and may effectively prevent the central server tampering with the blockchain.

[0033] Fig. 1 is a schematic diagram of an exemplary system 100 for the distribution of goods. [0034] The system 100 includes a tax payment processing server 110, a seller system

120, and a destination operator system 130, connected with each other via a communication network 140.

[0035] The tax payment processing server 110 may be hosted on one or more electronic computing devices accessible by the seller system 120 and the destination operator system 130.

[0036] In some embodiments, the tax payment processing server 110 is a cloud-based server.

[0037] In some embodiments, the tax payment processing server may include a plurality of servers that operate collaboratively to process the tax payment.

[0038] The seller system 120 is a system operated by a seller who sells the goods, or by a representative of the seller. The seller may be an individual or an entity. The seller may also be referred to as a“vendor”, a“merchant”, or a“retailer”.

[0039] The seller system 120 may include one or more terminal computing devices

(which may also be referred to as the“seller terminal computing devices”) used by the seller or a representative of the seller. The seller system 120 may alternatively or additional include one or more servers, e.g., one or more seller gateway servers for controlling the data communication between the seller terminal computing device(s) and the tax payment processing server 110.

[0040] The destination operator system 130 is a system operated by a party (referred to as a“destination operator”) operating in the destination taxing jurisdiction of the goods, e.g., a party operating in the destination country. The destination operator may be an individual or entity that facilitates the shipment or customs clearance of the goods in the destination country, e.g., a customs clearing agent. Alternatively, in some embodiments the destination operator may be the taxing authority itself, e.g., the customs authority of the destination country.

[0041] The destination operator systems 130 may include one or more terminal computing devices (which may also be referred to as the“destination operator terminal computing devices”) used by the destination operator, or by a representative of the destination operator. The destination operator system 130 may alternatively or additionally include one or more servers, e.g., one or more destination operator gateway servers for controlling the data communication between the destination operator terminal computing device(s) and the tax payment processing server 110.

[0042] The communication network 140 may be a wired network, a wireless network, or a mix of both, including, but not limited to: mobile networks, private networks such as 802.1 l-based networks, the Internet, LANs, WANs, as well as direct or point-to-point connections, such as Bluetooth, Near-field communication (NFC), Z-Wave, Zigbee, WiGig and the like.

[0043] Although only one seller system 120 is shown in Fig. 1, in some embodiments the system 100 may include a plurality of seller systems used by a plurality of sellers from whom taxable goods can be purchased.

[0044] Similarly, although only one destination operator system 130 is shown in Fig.

1, in some embodiments the system 100 may include a plurality of destination operator systems used by a plurality of destination operators, who may operate in one or more taxing jurisdictions.

[0045] In other words, the infrastructure illustrated in Fig. 1 may be used for processing the payment of tax levied in one or a plurality of taxing jurisdictions in relation to goods purchased from one or a plurality of sellers.

[0046] Further, as shown in Fig. 1, in some embodiments, the taxable goods are sold by the seller using an electronic commerce platform, for example, an online shopping website operated by the seller itself, or an electronic distribution platform such as Amazon or eBay.

In these circumstances, the system 100 may further include an electronic commerce system 150 which hosts the electronic commerce platform through which the goods are sold. The electronic commerce system 150 may be accessible by the seller system 120, either via the communication network 140 or a different communication network. The electronic commerce system 150 may be communicable with the tax payment processing server 110 via the communication network 140, e.g., by using an application programming interface (API) or any other suitable data communication protocol. [0047] Further, as shown in Fig. 1, the tax payment processing server 110 may be in communication with an external financial institution system 160, which provides to the tax payment processing server 110 information related to one or more financial accounts associated with the system 100, and facilitates the undertaking of various financial transactions described in more detail below.

[0048] Further, as shown in Fig. 1, the destination operator systems 130 may be in communication with an external taxing authority system 170, from which information related to the shipment or release status of the purchased goods may be received. The information may include, e.g., whether the goods are released or rejected by a taxing authority in the destination country.

[0049] Fig. 2 outlines an exemplary workflow 200 for the distribution of goods according to some embodiments.

[0050] At step 202, a buyer located in the taxing jurisdiction purchases goods from the seller who is located outside of the taxing jurisdiction. The purchase may be conducted, for example, via an online shopping website or an electronic distribution platform hosted by the electronic commerce system 150 of Fig. 1. In the examples described herein, it is assumed that the taxing jurisdiction is a country, and the goods are purchased by a buyer located in this country from an overseas seller, and are to be delivered to a destination specified by the buyer, e.g., a destination address in the buyer’s country.

[0051] At step 204, the seller receives the purchase order, and collects from the buyer a payment for the goods.

[0052] Along with a purchase price of the goods, the seller also collects payment to cover additional costs associated with importation of the goods into the buyer’s country, including for example, the shipment fee and one or more taxes payable for the goods. The collection of the payment may be performed using the online shopping website or the electronic distribution platform hosted by the electronic commerce system 150 of Fig. 1.

[0053] At step 206, upon confirming that the payment has been completed by the buyer, the seller then transfers the payable amount of tax associated with the goods into a holding account. The holding account may be a virtual account maintained by the tax payment processing server 110 or an actual financial account (such as a bank account) accessible to the tax payment processing server 110.

[0054] In some embodiments, the holding account is a virtual account associated with the purchased goods, created by the tax payment processing server 110. Preferably each sales transaction is associated with a unique virtual holding account. The transactions in and out of the virtual holding account are recorded in one or more blockchains. For example, a new blockchain may be created by the tax payment processing server 110 upon confirming the transfer of tax payable by the seller to the virtual holding account. The blockchain stores the amount of transaction, and some metadata related to the transaction e.g., one or more of the following: seller information related to the seller, buyer information related to the buyer, and goods information related to the goods that have been purchased.

[0055] Alternatively, the holding account may be a common holding account in the form of an actual financial account. The common holding account may be used by the tax payment processing server 110 for managing funds associated with a plurality of sales transactions. The seller may transfer the payable amount of tax associated with the goods into the common holding account controlled by tax payment processing server 110. In this embodiment, the blockchain that is created by tax payment processing server 110 upon confirming the transfer of the tax payable by the seller to the common holding account stores sufficient details to associate an amount of funds in the common holding account with the corresponding sales transaction. In this embodiment, the various blockchains that are created (one for each sales transaction) act as ledgers for the common account.

[0056] In other embodiments, the holding account is a common virtual account maintained by the tax payment processing server 110. It operates in much the same way as a holding account in the form of an actual financial account, but is implemented through entries in a database associated with the tax payment processing server 110. Of course the underlying funds controlled by the virtual account may be stored in one or more actual financial accounts.

[0057] The tax payable may be transferred into the virtual or common holding account from a financial account associated with the seller, the financial account being managed by a financial institution, e.g., the issuer of the financial account. This may be performed by the seller transferring the tax payable from the seller’s financial account into a virtual or actual financial account and controlled by the tax payment processing server 110. Information related to this payment may be received by the tax payment processing server 110 from the external financial institution system 160.

[0058] Alternatively, the tax payable may be transferred into the actual or virtual holding account from a virtual account created and controlled by the tax payment processing server 110, e.g., a shadow account associated with the seller. The seller may deposit funds in advance into the shadow account, and transfer the payable tax from the shadow account to the holding account when using the tax payment service. Data related to the shadow account, e.g., the balance of the shadow account, the transaction data, and information of the seller, may be stored by the tax payment processing server 110 in a local or remote data store. The funds in the shadow account may be withdrawn by the seller at any time, e.g., to a financial account associated with the seller, or any other financial account specified by the seller.

[0059] As transferring funds from an external financial account into the holding account may be more time consuming compared to transferring funds from one virtual account (the shadow account) controlled by the tax payment processing server 110 to another account (the virtual or common holding account) also controlled by the tax payment processing server 110, using the shadow account may significantly reduce the delay in paying tax into the holding account and therefore allow rapid process of tax payment.

[0060] The payable amount of tax associated with the goods may be determined by the seller manually, e.g., by conducting a calculation based on the sale price of the goods and a tax rate determined by the taxing authority of the destination country (which may also be referred to as the“destination taxing authority”). Alternatively, the payable amount of tax may be automatically determined by the online shopping website or the electronic distribution platform used by the seller in selling the goods. Alternatively, the payable amount of tax may be calculated by the seller system 120 or the tax payment processing server 110 based on the sale price of the goods and the tax rate determined by the destination taxing authority.

[0061] In exchange for the seller depositing funds on account of tax payable into the holding account, the seller system 120 may receive from the tax payment processing server 110 a unique identifier associated with the payment. Where the payment is for a single item, the unique identifier may be considered to be associated with that item. However, where the payment is for multiple items, the same unique identifier is associated with each item. In both cases, the unique identifier is associated with a single payment.

[0062] Preferably, the unique identifier is a blockchain identifier uniquely associated with the blockchain used for recording information related to the transaction. Alternatively, the unique identifier may be any identifier that is uniquely associated with the blockchain, e.g., a derivation of the blockchain identifier.

[0063] The unique identifier may be, for example, a distinctive alphabetic or alphanumeric sequence, or a distinctive number. In some embodiments, the unique identifier is a blockchain identifier. The blockchain identifier may be, for example, a 6-digit or 8-digit numerical string.

[0064] In some embodiments, the unique identifier is received from the tax payment processing server 110 in the form of machine readable information, e.g., a barcode. In some embodiments, in additional to the blockchain identifier, the received machine readable information may further include additional information, e.g., the value of payable tax associated with the goods, and a destination address for last mile delivery. In other embodiments, when the seller system 120 arranges payment of the tax payable into the virtual or common holding account, it also transmits to the tax payment processing server 110 a unique transaction identifier. The seller system 120 associates the unique transaction identifier with other sale-related information (such as a description of the goods, a destination delivery address, a transaction date, details identifying the purchaser etc.) In these

embodiments, the unique identifier received from tax payment processing server 110 includes at least information from which a blockchain identifier may be derived, and the unique transaction identifier. This enables the seller system 120 to associate the received blockchain identifier with other sale-related information it had stored in association with the unique transaction identifier.

[0065] At step 208, the seller system 120 generates a hard copy containing the unique identifier, for example, by printing out a tag bearing the machine readable information that contains the unique identifier. The tag may also be referred to as a“Rapid Release label” or an“RR label”. This may trigger a new block to be created and added to the blockchain, e.g., a new block indicating that the tag has been generated. This ensures that duplicate tags cannot be generated having the same unique identifier. In some embodiments the tag printed or otherwise generated by the seller system 120 includes not only the unique identifier received from the tax payment processing server 110, but additional sale-related information which the seller system 120 had stored in association with the sale, as described in the immediately preceding paragraph. The additional sale related information may be encoded in machine-readable information recorded on the tag, such that, for example, a single code (e.g. a barcode) encodes not only the blockchain identifier, but also associated sale-related information).

[0066] In some embodiments, the machine readable information is a barcode, and a tag in the form of a paper label bearing the machine readable information may be generated by the seller by using a printing device, such as a printer.

[0067] Alternatively or additionally, the unique identifier may be recorded on the tag as clear text. However, embedding the unique identifier in machine readable information rather than as clear text may allow rapid recognition of the identifier (and hence rapid processing of the goods) in the destination country, and may also enhance the data security of the system 100 as the unique identifier would not be quickly or easily human readable.

[0068] The machine readable information may take any suitable form, e.g., a one- or two-dimensional barcode, a NFC tag, or a RFID tag.

[0069] As described above, in addition to the unique identifier, the machine readable information may further include other suitable information, for example, delivery address information enabling last mile delivery in the destination country. Alternatively or additionally, the additional information such as the delivery address may be recorded as clear text on the tag.

[0070] At step 210, the seller packs the goods and applies the tag to the goods, e.g., by attaching the tag to the goods, or by associating the tag with the goods in any other suitable manner. When dispatching the goods, the seller may capture the machine readable information (for example, if the machine readable information is a barcode, the seller may scan it using a scanning device). The goods are then dispatched by the seller. This may trigger a new block to be created and added to the blockchain for recording the change in shipment status of the goods, e.g., a new block indicating that the goods have been dispatched by the seller. [0071] At step 212, the goods are transported to the destination country, e.g., the buyer’s country. Alternatively, in some embodiments, the destination country may be any country (or other type of taxing jurisdiction) specified by the buyer, where one or more taxes are levied upon the goods. Accordingly, any tax payable would be paid to the taxing authority of that country (or that taxing jurisdiction).

[0072] At step 214, the goods are collected and delivered to an unloading depot specified by or known to a taxing authority of the destination country. The taxing authority may, for example, be the customs authority of the destination country.

[0073] At step 216, the machine readable information attached to or associated with the goods is captured by staff of a destination operator, e.g., by using a scanning device for scanning a barcode. This may trigger a new block to be created and added to the blockchain for recording the change in shipment status of the goods, e.g., a new block indicating that the goods has arrived at the destination country.

[0074] As described hereinbefore, the destination operator may be an individual or entity that facilitates the shipment or customs clearance of the goods in the destination country, such as a customs clearing agent. Alternatively, in some embodiments the destination operator may be the taxing authority itself, e.g., the customs authority of the destination country.

[0075] The customs authority determines whether the goods are to be: (i) released; or

(ii) returned or destroyed.

[0076] In some embodiments, the customs authority’s decision is received by the destination operator system 130 from the taxing authority system 170. Preferably, this information is received before the scan of the goods in step 216, so that when the goods are scanned in step 216, the received information may be recorded by the system 100, e.g., by adding new block to the blockchain indicating the decision of the customs authority. In some embodiments, the new block is added by the destination operator system 130, and the blockchain is replicated to the blockchain stored at the tax payment processing server 110.

[0077] Alternatively, a message indicating the decision of the customs authority may be sent from the destination operator system 130 to the tax payment processing server 110 via the communication network 140, triggering the tax payment processing server 110 to update the blockchain, which is then replicated across the network.

[0078] In some other embodiments, data representing the decision of the customs authority may be manually input into the destination operator system 130 by staff of the destination operator.

[0079] At step 218, for the goods that are cleared to be released, the tax payment processing server 110 causes the funds held in the holding account to be remitted to an account associated with the taxing authority of the destination country, the amount of the funds remitted being the amount of tax payable for the goods. This may be performed by the tax payment processing server 110 communicating with the financial institution system 160, causing transfer of funds from the financial account in which the funds in the holding account are stored, to a financial account associated with the taxing authority. Using the unique identifier obtained by scanning the tag, a blockchain associated with the transaction can be identified. The blockchain is then updated to indicate the removal of funds from the holding account. In addition, the machine readable information (e.g., the barcode) borne by the tag is caused to expire, e.g., by modifying the blockchain to prevent any further information being written to it. The released goods are delivered to the buyer, or to a recipient specified by the buyer, in the destination country.

[0080] Alternatively, if the goods are rejected by the customs authority, e.g., if the customs authority issues a direction to return or destroy the goods (step 220), at step 222 the machine readable information (e.g., the barcode) on the tag may be captured again by the destination operator. This may trigger a new block to be added to the blockchain to indicate the decision of the customs authority. For example, the destination operator system 130 may update the blockchain, which will then be replicated to the corresponding blockchain at the tax payment processing server 110. Alternatively, a message may be sent from the destination operator system 130 to the tax payment processing server 110, indicating that the goods are rejected by the customs authority, and the tax payment processing server 110 may update the blockchain, the update replicating across the network in due course.

[0081] At step 224, upon receiving a message from the destination operator system

130, the tax payment processing server 110 may cause a notification to be sent to the seller, indicating that the funds held in the holding account are ready to be returned to the seller’s account. The machine readable information (e.g., the barcode) borne by the tag is caused to expires, e.g., by modifying the blockchain to prevent any further information being written to it.

[0082] At step 226, the seller may choose to keep the funds in their shadow account as credits for future transactions, or to remove funds from the shadow account to an account specified by the seller. A message indicating the seller’s decision may be sent from the seller system 120 to the tax payment processing server 110, to allow the funds to be processed accordingly. If the seller chooses to remove the funds from the holding account to a financial account associated with the seller, the tax payment processing server 110 may notify the financial institution system 160 to cause the transfer of funds to the seller’s financial account. Alternatively, as referred to above, the funds may be removed from the holding account to the shadow account associated with the seller. The tax payment processing server 110 may update the blockchain to indicate the removal of the funds from the holding account.

[0083] In this way, the described methods and systems provides a technical infrastructure allowing a streamlined, secure and efficient process for the payment of tax levied by a destination taxing jurisdiction and the distribution of goods.

[0084] By using the described methods and systems, once the goods are released by the customs authority of the destination country, the payment of tax may be made in real-time or near real-time to the corresponding taxing authority. If the goods are rejected by the customs authority, the funds held for the tax payment may be released in real-time or near real-time once the rejection of the goods is confirmed.

[0085] The described methods and systems may be used for the payment of GST, customs duty, or any other suitable type of taxes imposed upon goods entering a taxing jurisdiction.

[0086] In the embodiments described above, a unique identifier associated with the blockchain is generated by the tax payment processing server 110 and sent to the seller system 120. The seller system 120 uses the unique identifier to generate a tag (e.g., in the form of an RR label), which is subsequently associated with the goods when dispatching the goods. [0087] Alternatively, in some other embodiments, instead of sending the unique identifier to the seller system 120, the tax payment processing server 110 may receive a parcel identifier (ID) from the seller system 120, the parcel ID being uniquely associated with the parcel sending the goods. The tax payment processing server 110 stores the parcel ID in association with a blockchain identifier (ID) that uniquely identifies the blockchain, e.g., in a local or remote data store accessible by the tax payment processing server 110. The parcel ID and the blockchain ID may be stored in association with each other in any suitable form, e.g., in a parcel ID-blockchain ID table for storing the corresponding relationship between a plurality of parcel IDs and a plurality of blockchain IDs.

[0088] The parcel ID may take any suitable form known to a person skilled in the art, e.g., a parcel number, an alphabetic sequence, or an alphanumeric sequence. The parcel ID may be attached to the parcel for sending the goods in any suitable manner. For example, the parcel ID may be embedded in a machine readable code (e.g., a barcode or a QR code) printed on the parcel or on a label attached to the parcel. Alternatively, the parcel ID may be printed on the parcel or on a label attached to the parcel in clear text.

[0089] When the goods arrive at the destination country, the destination operator system 130 is used by staff of a destination operator to capture the parcel ID and send it to the tax payment processing server 110. To capture the parcel ID, the staff of the destination operator may manually input the parcel ID into the destination operator system 130.

Alternatively, the parcel ID may be captured by using a scanner to scan a machine readable code on the parcel that bears the parcel ID. Alternatively, the parcel ID may be retrieved from a digital image of the parcel ID taken at the destination country.

[0090] When receiving the parcel ID from the destination operator system 130, the tax payment processing server 110 queries the data store (e.g., by looking up the parcel ID- blockchain ID table) and identifies the blockchain associated with that parcel ID. The tax payment processing server 110 then updates the blockchain accordingly to record the arrival of the goods, and/or the custom's decision on the goods. The transfer of the funds can be controlled accordingly based on the status of the blockchain.

[0091] In this way, the shipment status of the goods can be tracked without requiring sending the unique identifier associated with the blockchain and printing out of the tag, which makes it more efficient and convenient for the seller to use the system 100 and the methods described above.

[0092] Fig. 3 illustrates a schematic diagram of an exemplary system 300 utilising a distributed ledger.

[0093] The system 300 includes a tax payment processing server 310, a seller terminal computing device 320, and a destination operator terminal computing device 330, connected with each other via a communication network 340.

[0094] The tax payment service provided by the system 300 may also be referred to as the“Rapid Release service” or“RR service”. Similarly, the tax payment processing server 310 may also be referred to as the“Rapid Release server” or“RR server”.

[0095] The seller terminal computing device 320 is operated by a seller who sells the goods, or a representative of the seller. As shown, a capturing device 324 is in wired and/or wireless communication with the seller terminal computing device 320. The capturing device 324 may be used by the seller for capturing the machine readable information that contains the unique identifier, or in some alternative embodiments the capturing device 324 may be used for capturing the parcel ID.

[0096] The seller terminal computing device 320 may take any suitable form, for example, a desktop personal computer as shown in Fig. 3. Alternatively, the seller terminal computing device 320 may be a portable computer, a tablet computer, a personal digital assistant (PDA), a smart phone, or any other suitable computing device.

[0097] As shown, the capturing device 324 may be a handheld scanning device for scanning a barcode. Alternatively, the capturing device 324 may take any other suitable form, for example, a digital imaging device for capturing a digital image of a barcode or two- dimensional barcode, a NFC reader for reading a NFC tag, or an RFID reader for reading an RFID tag.

[0098] Further, in some embodiments, the capturing device 324 may be integrated with the seller terminal computing device 320. For example, the seller terminal computing device 320 may be a smart phone device that includes a digital imaging module for capturing a barcode or a two-dimensional barcode, and/or an NFC module for reading an NFC tag. [0099] The destination operator terminal computing device 330 is operated by staff of a destination operator operating in the destination country, e.g., a customs clearing agent, or the customs authority of the destination country.

[00100] In some embodiments, the destination operator terminal computing device 330 has a capturing module for capturing the machine readable information attached to or associated with the goods. For example, the destination operator terminal computing device 330 may be a smart phone as shown in Fig. 3, which includes a digital imaging module for capturing a barcode or a two-dimensional barcode, or an embedded NFC reader for reading an NFC tag.

[00101] Alternatively, the destination operator terminal computing device 330 may be a handheld scanning device that includes a communication module for performing data communication with the tax payment processing server 310 via the communication network 340.

[00102] Alternatively, the destination operator terminal computing device 330 may be any suitable terminal computing device that is communicable with an external capturing device for capturing the machine readable information or the parcel ID.

[00103] The communication network 340 may be a wired network, a wireless network, or a mix of both, including, but not limited to mobile networks, private networks such as 802.1 l-based networks, the Internet, LANs, WANs, as well as via direct or point-to-point connections, such as Bluetooth, Near-field communication (NFC), Z-Wave, Zigbee, WiGig and the like.

[00104] In some embodiments, the seller terminal computing device 320 may further be in communication with an electronic commerce system 350 which hosts the electronic commerce platform through which the goods are sold. In some embodiments, the parcel ID may be received by the tax payment processing server 110 from the electronic commerce system 350, rather than from the seller system 120 directly. For example, the seller may provide the parcel ID to the electronic commerce system 350 when despatching the goods, and the electronic commerce system 350 may subsequently pass the parcel ID to the tax payment processing server 110. [00105] In some embodiments, the tax payment processing server 310 may further be in communication with an external financial institution system 360, which provides to the tax payment processing server 310 account related services, including the provision of a holding account and, in some embodiments, an account for storing funds which are allocated to sellers through a set of shadow accounts.

[00106] In some embodiments, the destination operator terminal computing device 330 may further be in communication with an external taxing authority system 370, from which information related to the shipment status of the purchased goods may be received. The information may include, e.g., whether the goods are released or rejected by a taxing authority in the destination country.

[00107] As shown in Fig. 3, the distributed ledger 312 / 322 / 332 is replicated and stored at the tax payment processing server 310, the seller terminal computing device 320, and the destination operator terminal computing devices 330, respectively, for tracking shipment activities, together with associated financial transactions.

[00108] The data stored in the distributed ledger 312 / 322 / 332 is replicated, shared, and synchronized across the system 300 via the communication network 340. In this way, the integrity, availability and resiliency of the data is maintained, and information pertaining to the transactions of the funds and the shipment status of the goods can be provided in real- time or near real-time, with improved data transparency and security. The distributed ledger also allows reduction of error or fail rates of transactions as compared to conventional tax- collection systems.

[00109] In at least some embodiments, the data related to funds transaction and/or the shipment status is recorded in a blockchain in the distributed ledger 312 / 322 / 332.

[00110] In at least some embodiments, a series of triggering events (which may also be referred to as“milestones”) may be defined. Occurrence of the triggering events or achievement of one or more milestones may trigger the distributed ledger to be updated, e.g., by generating at least one new block and appending the new block to the blockchain, with a reference to at least one of the previous blocks in the blockchain. The reference may be, e.g., a hash value associated with the prior block. The hash value may be calculated using a known hashing algorithm, e.g., a Secure Hash Algorithm 256-bit (SHA-256). [00111] The triggering events may include, for example, the transfer of funds in or out of the holding account, and/or change of the shipment status of the goods.

[00112] For instance, in some embodiments, a series of milestones Ml - M8 may be defined as follows:

[00113] Upon the achievement of each of these milestones, the blockchain ledger may be updated as follows:

[00114] Ml : A new blockchain may be initiated when a seller makes a payment into the holding account. A new block is created for recording the relevant information (as described in further detail hereinafter). This block may be a genesis block of a new blockchain. The amount of tax payable and a timestamp associated therewith are stored in the block. In some embodiments, the block may also record additional information, e.g., a description of the goods, a destination delivery address, buyer details identifying the buyer, and seller details identifying the seller. An example of the additional information recorded in the block is shown as follows:

[00115] M2: When the seller prints out the tag bearing the machine readable information (e.g., the barcode), this milestone is achieved, and a new block is added to the blockchain to record this. The new block includes a reference to the most recently added block, e.g., a hash value associated with the prior block. The new block also includes an indicator that the tag has been printed by the seller or that milestone M2 is achieved, and in some embodiments includes additionally a timestamp indicating the time of printing the tag. Updating the blockchain upon printing the tag may facilitate ensuring that the machine readable information containing the unique identifier can only be printed once, so that the same tag would not be applied to multiple goods. However, this milestone is optional, and in some other embodiments, the system may check the validity of the tag when the goods are scanned in the destination country to detect the unauthorised application of the same tag to multiple goods.

[00116] M3 : When the goods are despatched by the seller (which, in alternative embodiments may be indicated by a message sent from the seller terminal computing device 320 to the tax payment processing server 310), this milestone is achieved, and a new block is added to the blockchain, the new block including an indicator indicating that the goods have been despatched by the seller and an associated timestamp, or that milestone M3 is achieved.

[00117] M4: When the goods arrive at the destination country and are scanned by staff of the destination operator, this milestone is achieved, and a new block is added to the blockchain, the new block including an indicator indicating that the goods have arrived at the destination country or that milestone M4 is achieved, and in some embodiments also including an associated timestamp.

[00118] M5: When the goods are cleared by the customs authority and released to a destination courier or delivery service provider, this milestone is achieved, and a new block is added to record this. The new block includes an indicator indicating that the goods have been cleared for release, or that milestone M5 is achieved.

[00119] M6: If the goods are held by the customs authority of the destination country for inspection, this milestone is achieved and a new block is added to record this, the new block including an indicator indicating that the goods are being held for further inspection, or that milestone M6 is achieved.

[00120] M7: If a direction is received from the customs authority indicating that the goods are to be destroyed or returned, milestone M7 is achieved, which triggers a new block to be added to the blockchain. The new block includes an indicator indicating that the goods are to be destroyed or returned, or that milestone M7 is achieved.

[00121] M8: For the goods that are cleared, the amount payable for one or more taxes

(e.g., the GST) held in the holding account is transferred to an account associated with the destination taxing authority. Milestone M8 is achieved, and a new block is added to the blockchain, including an indicator indicating that the payment of tax is completed, or that milestone M8 is achieved. The blockchain ledger may then be closed, e.g., by disabling the ability to write to or update the blockchain.

[00122] When updating the blockchain ledger, the unique identifier contained in the machine readable information is used to identify the blockchain that is associated with the goods. The unique identifier may be obtained by, e.g., capturing the machine readable information on the tag attached to or associated with the goods.

[00123] As described hereinbefore, in some alternative embodiments, instead of generating a tag that bears the machine readable information containing the unique identifier associated with the blockchain, the seller system 120 may send the parcel ID to the tax payment processing server 110 when the goods are despatched. In this case, the milestone M2 described above may not be required. Also, the milestones M3 and M4 may be defined to indicate that the goods associated with that parcel ID are despatched and have arrived at the destination country, respectively.

[00124] Fig. 4 and Fig. 5 are diagrams showing an exemplary workflow implemented by the system 300 for processing payment of one or more taxes imposed upon goods entering a taxing jurisdiction.

[00125] Before initiating the tax payment flow, the seller confirms that the goods have been purchased by a buyer, and the destination specified by the buyer is a taxing jurisdiction in which one or more taxes are payable for the goods. The purchase may be performed via an online shopping website or an electronic distribution platform, e.g., Amazon, eBay, or the like.

[00126] When selling the goods, the seller charges the amount of tax payable in addition to the sale price of the goods. Optionally, the seller may further charge for the costs related to shipment of the goods, e.g., a shipping fee.

[00127] For example, if the sale price of the goods is $100.00, and the tax payable includes a 10% GST (i.e., $10.00), the total amount the seller charges from the buyer may be:

$100.00 (sale price) + shipping fee + $10.00 (tax).

[00128] When the seller confirms that the required amount of payment has been made by the buyer, the seller initiates the workflow 400.

[00129] At step 402, the seller logs into a Rapid Release seller portal (which may also be referred to as“RR seller portal”), with a user name and password, using the seller terminal computing device 320. The Rapid Release seller portal may be a website accessible by the seller terminal computing device 320 using a browser application executed on the seller terminal computing device 320. The website may be hosted on the tax payment processing server 310. Alternatively, the Rapid Release seller portal may take the form of a software application executable on the seller terminal computing device 320. The user name and the password may be defined in a user registration process by which the seller registers to the Rapid Release service.

[00130] At step 404, the seller provides details of the products purchased by the buyer. The product details may be manually input by the seller using the seller terminal computing device 320, or imported into the Rapid Release seller portal, e.g., by importing an electronic document, such as a CSV or XML file. The product details input into the Rapid Release seller portal may include, for example, a product name for each product sold, a number of items sold, a sale price of each item, and a payable amount of tax received for one or a plurality of products. The seller may further input contact information related to the seller (which may also be referred to as“seller details”), and the delivery information related to the buyer or a recipient of the goods specified by the buyer (which may also be referred to as “buyer details” or“delivery details”).

[00131] Alternatively, in some embodiments, the product details, the seller details, and the delivery details may be sent to the Rapid Release system from a server of the online shopping website or electronic distribution platform used by the seller for selling the goods, e.g., via an application programming interface (API).

[00132] In some embodiments, when providing the product details, the seller details, and the delivery details, the seller may be allowed to select a destination delivery service provider using the Rapid Release seller portal.

[00133] At step 406, data including at least some of the product details provided by the seller is transmitted from the RR seller portal (which, in some embodiments, is executed on the seller terminal computing device 320) to the tax payment processing server 310 (which may also be referred to as the RR Server), via the communication network 340. If the user has selected a destination delivery service provider, this information is also sent to the RR Server as part of the product details. In addition to the product details, some seller details and/or delivery details may also be provided to the RR server. [00134] For example, in some embodiments, the RR seller portal communicates the following information to the tax payment processing server 310:

• Total invoice value of the goods

• Value of payable tax

• Other product details

• Buy details

• Seller details

[00135] In some embodiments, the RR seller portal may additionally communicate to the tax payment processing server 310 a unique transaction identifier associated with the transaction. The transaction identifier can be used by the RR seller portal to identify the above-mentioned details of the transaction.

[00136] At step 408, the RR Server cross-checks the payable amount of tax based on the product information (such as the sale price of the products sold) and the tax rate in the destination country, and confirms that the amount of tax reported to be collected by the seller matches the payable amount of tax in the destination country. Preferably, the corresponding tax rates in one or more taxing jurisdictions are stored in a local or remote data store accessible by the RR Server.

[00137] At step 410, data including the result of the cross-check is sent from the RR server to the RR seller portal.

[00138] Optionally, if it is determined at step 408 that the amount of tax collected by the seller matches the tax payable for the goods, a message is sent to the RR seller portal, confirming that the correct amount of payable tax has been charged by the seller.

[00139] As described hereinbefore, the seller remits funds corresponding to the tax payable to a virtual or actual holding account (step 412). As described hereinbefore, the funds may be transferred from a financial account of the seller, or a shadow account associated with the seller, details of the shadow account being maintained by the system 300. The virtual holding account may be created in the user registration process, and is managed by the RR system, e.g., by using a blockchain stored in a distributed ledger.

[00140] Alternatively, in some embodiments, the cross-checks of the value of payable tax may be performed by the RR server after the transfer of funds by the seller into the holding account has been completed.

[00141] At step 414, the RR Server confirms that the payment has been made, e.g., by receiving a payment completion message from the external financial institution system 360. This achieves milestone Ml as described hereinbefore. As a result, the RR server generates a new block. The new block may be generated as the first block (which may also be referred to as a“genesis block”) of a new blockchain, or added to an existing blockchain associated with the same seller who has previously used the RR system and the holding account.

[00142] Alternatively, the payment completion message may be received by the RR server from the RR seller portal. For example, the RR seller portal may send payment completion message to the RR server upon the seller remitting funds corresponding to the tax payable to a virtual or actual holding account using the RR seller portal.

[00143] Alternatively, the new block may be generated by the RR seller portal, e.g., upon the seller remitting funds corresponding to the tax payable to a virtual or actual holding account using the RR seller portal.

[00144] The new block may store, for example, information identifying the amount of payable tax transferred by the seller into the holding account. In some embodiments, the new block may further store the balance of the holding account. Alternatively, the balance of the holding account may be stored in a data store accessible to the RR server.

[00145] In addition, the new block may further store at least some details of the transaction, e.g., the product details, the seller details, and the delivery details, as described hereinbefore.

[00146] At step 416, the RR Server sends a unique identifier associated with the blockchain to the RR seller portal, enabling the printing of a tag (referred to below as“Rapid Release label” or“RR label”), the RR label bearing the machine readable information which contains the unique identifier. The machine readable information may be, for example, a barcode.

[00147] Preferably, the unique identifier is a blockchain identifier of the blockchain. Alternatively, the unique identifier may be any identifier that is uniquely associated with the blockchain, e.g., a derivation of the blockchain identifier.

[00148] The unique identifier may be, for example, a distinctive alphabetic or alphanumeric sequence, or a distinctive number. In some embodiments, the unique identifier is a blockchain identifier. The blockchain identifier may be, for example, a 6-digit or 8-digit numerical string.

[00149] In some embodiments, the unique identifier is received from the tax payment processing server 310 in the form of machine readable information, e.g., a barcode. In some embodiments, in addition to the blockchain identifier, the received machine readable information may further include additional information, e.g., the value of payable tax associated with the goods, and a destination address for last mile delivery.

[00150] As described hereinbefore, in some embodiments, the RR seller portal may additionally communicate to the tax payment processing server 310 a unique transaction identifier associated with the transaction. Accordingly, when sending back the unique identifier, the RR seller may send the unique identifier together with the transaction identifier received from the RR seller portal, so that the RR seller portal may use the transaction identifier to identify the details of the transaction, e.g., the delivery details, and encode the unique identifier and the delivery details into a machine readable information. This may reduce the amount of data required to be sent back to the RR seller portal from the tax payment processing server 310.

[00151] At step 418, the RR label is printed, e.g., by the user using a printing device communicable with the seller terminal computing device 320. The RR seller portal may receive a signal from the printing device indicating that the RR label has been printed.

Accordingly, milestone M2 is achieved, and the RR seller portal generates a new block indicating the achievement of M2 and adds it to the blockchain stored in the distributed ledger 322. In this way, the blockchain is updated without the RR seller portal transferring a message to the tax payment processing server 310. The update of the blockchain is then replicated to other copies of the distributed ledger, e.g., 312 and 332. As a result, the tax payment processing server 310 may subsequently detect that M2 has been achieved by checking the blockchain ledger 312. In this way, the amount of data sent through the communication network can be significantly reduced.

[00152] Alternatively, the tax payment processing server 310 may be the only party that can update the blockchain. Accordingly, when the milestone M2 is achieved, a message may be sent from the RR seller portal to the tax payment processing server 310, to notify the tax payment processing server 310 that milestone M2 has been achieved, thereby causing the tax payment processing server 310 to update the blockchain stored in the distributed ledger 312. The updated blockchain is then replicated to other copies of the distributed ledger, e.g., 322 and 332. In this scenario, the RR seller portal is not required to have the ability to update the blockchain. Accordingly, the RR seller portal may have relatively simple configuration.

[00153] In some embodiments, the RR label may further include other suitable information, e.g., a delivery barcode, for providing relevant information (e.g., the delivery code and/or delivery address) to a destination delivery service provider. The format of the delivery barcode may be determined by the RR server based on the destination delivery service provider selected by the seller at step 404, as indicated by the data received at step 406 from the RR seller portal.

[00154] As described hereinbefore, having the milestone M2 may facilitate ensuring that the machine readable information containing the unique identifier can only be printed out once, so that the same RR label would not be applied to multiple goods. In some other embodiments, this milestone may not be required, and the system may check the validity of the RR label when the goods are scanned in the destination country to prevent application of the same RR label to multiple goods.

[00155] At step 420, the goods are packed and despatched with the RR label attached thereto or associated therewith. When despatching the goods, the seller may capture the machine readable information (e.g., the barcode) recorded on the RR label, e.g., by using the capturing device 324 communicable with the seller terminal computing device 320. This causes the achievement of milestone M3, which triggers a new block to be generated and added to the blockchain associated with the unique identifier contained in the machine readable information. Similar to M2, the update to the blockchain may be carried out by the RR seller portal, so that the amount of data sent through the communication network can be significantly reduced. Alternatively, the update to the blockchain may be carried out by the RR server, which allows the RR seller portal to have a relatively simple configuration.

[00156] As shown in Fig. 5, when the goods arrive at the destination country, they may be handed over to a customs clearing agent (step 422), and may be subsequently transported to the customs clearing agent’s warehouse for scanning (step 424).

[00157] At the warehouse, each parcel received is scanned by staff of the customs clearing agent (step 426), e.g., by using the destination operator terminal computing device 330. For parcels affixed with the RR label, capturing the machine readable information on the RR label causes data to be sent from the destination operator terminal computing device 330 to the RR server, indicating that the goods have arrived at the destination country. Milestone M4 is achieved. Preferably, the destination operator terminal computing device 330 updates the blockchain stored in the distributed ledger 332, by adding a new block to the blockchain. The updated blockchain is then replicated to other copies of the distributed ledger, e.g., 312 and 322.

[00158] Alternatively, the destination operator terminal computing device 330 may send a message to the RR server, notifying the RR server that the milestone M4 has been achieved, which triggers the RR server to update the blockchain stored in the distributed ledger 312. The message sent to the RR server includes at least the unique identifier contained in the machine readable information (or alternatively the machine readable information itself). The RR server identifies the relevant blockchain ledger based on the unique identifier, and then adds a new block to the blockchain. The updated blockchain is then replicated to other copies of the distributed ledger, e.g., 322 and 332.

[00159] Next, the customs determine whether the goods in the agent’s warehouse are to be inspected. If inspection of the goods is not required, the goods are cleared and released to a destination delivery service provider to be delivered to the buyer (Step 428).

[00160] In some embodiments, the customs’ decision is received by the destination operator terminal computing device 330 from the taxing authority system 370. The destination operator terminal computing device 330 may update the blockchain stored in the distributed ledger 332 to record this change in shipment status of the goods, e.g., by adding new block to the blockchain indicating the custom’s decision. The updated blockchain is then replicated to other copies of the distributed ledger, e.g., 312 and 322.

[00161] By monitoring the blockchain stored in the ledger 312, the RR Server may detect that milestone M4 has been achieved, and authorise remittance of funds to the relevant taxing authority (step 430). In this way, the amount of data sent through the communication network can be significantly reduced.

[00162] Alternatively, the update of the blockchain may be performed by the tax payment processing server 110. In this case, a message is sent from the destination operator terminal computing device 330 to the RR Server, so that the RR server can update the blockchain and authorise remittance of funds to relevant taxing authority (step 430). This allows the destination operator terminal computing device 330 to have a relatively simple configuration.

[00163] At step 432, upon confirming that the goods are cleared and are to be released for final mile delivery, the RR Server remits funds corresponding to the payable amount of tax from the holding account to an account associated with the taxing authority, and updates the blockchain ledger, by adding a new block to the blockchain. Milestone M5 is achieved.

[00164] At step 434, the RR Server receives confirmation that the funds have been successfully transferred to the account associated with the taxing authority, which achieves milestone M8, causing a new block to be added by the RR server to the blockchain to record this. The blockchain ledger may then be closed. At step 436, a notification confirming the completion of the payment of tax is provided to the seller. Alternatively, the seller may detect closure of the ledger, and treat this as confirmation that the tax has been paid.

[00165] In some circumstances, the goods that have finished the scanning process at the customs clearing agent’s warehouse may be required to be held by the customs authority at step 438 for further inspection, which results in achievement of Milestone M6, and a new block is added to the blockchain to record this status. Similarly to the achievement of milestone M4, the update to the blockchain may be carried out by the destination operator terminal computing device 330, so that the amount of data sent through the communication network can be significantly reduced. Alternatively, the update to the blockchain may be carried out by the RR server, which allows the destination operator terminal computing device 330 to have a relatively simple configuration.

[00166] If after the inspection the customs authority determines to release the goods, the same flow as shown by steps 428 - 436 is performed, and the funds are released to the account of the taxing authority.

[00167] If after the inspection the customs authority determines that the goods should destroyed or returned to sender (step 440), the destination operator terminal computing device 330 may determine that milestone M7 is achieved, and update the blockchain stored in the distributed ledger 332 to reflect this decision, e.g., by adding new block to the blockchain indicating the decision of the customs authority. The updated blockchain is then replicated to other copies of the distributed ledger, e.g., 312 and 322.

[00168] By monitoring the blockchain stored in the ledger 322, the RR seller portal may detect that the milestone M7 has been achieved, and send a notification to the seller.

[00169] Alternatively, by monitoring the blockchain stored in the ledger 312, the RR Server may detect that the milestone M7 has been achieved. In some embodiments, the RR server may send a notification to the seller. For example, the RR Server may send to the RR seller portal a notification with data confirming the tax credit remaining within the float account, so that the credit can be used for a subsequent transaction made by the same seller (Step 444). Alternatively, the seller may choose to have the funds returned to an account specified by the seller.

[00170] Alternatively, the update of the blockchain may be performed by the RR server. In this case, a message is sent to the RR Server from the destination operator terminal computing device 330, indicating that the goods are rejected (Step 442). Milestone M7 is achieved accordingly, which triggers the RR server to add a new block to the blockchain to record this status, and notifies the seller.

[00171] As described hereinbefore, in some alternative embodiments, instead of using a tag bearing the machine readable information that contains the unique identifier associated with the blockchain, the parcel ID may be used for tracking the goods, wherein the tax payment processing server 110 stores the corresponding relationship between the parcel ID and an associated blockchain.

[00172] Fig. 6 illustrates an example of a method 600 executed by the tax payment processing server 110 of Fig. 1 for processing payment of tax.

[00173] At step 610, the tax payment processing server 110 receives a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller.

[00174] Next, at step 620, the tax payment processing server 110 adds a block to a blockchain, the block containing information identifying at least the amount of tax payable.

[00175] Next, at step 630, the tax payment processing server 110 determines when a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority, has been added to the blockchain.

[00176] Upon determining that the later block has been added to the blockchain (step 640): at step 650, the tax payment processing server 110 queries the blockchain to determine the amount of tax payable. Further, at step 660, the tax payment processing server 110 instructs a transaction processor to transfer funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

[00177] Fig. 7 shows an exemplary structure of a tax payment processing server 110 of Fig. 1.

[00178] In this example, the tax payment processing server 110 includes at least one processor 710, a memory 720, an external input/output interface 730, and an input/output module 740 such as a keyboard and/or a display, interconnected via a bus 750 as shown. The external interface 730 may be utilised for data communication with other computing devices in system 100 (as shown in Fig. 1) via the communication network 140. Although a single external interface 730 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided. [00179] Accordingly, it will be appreciated that the tax payment processing server 110 may be formed from any suitable processing system, such as a suitably programmed computer system, PC, web server, network server, or the like. In one example, the tax payment processing server 110 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.

[00180] In use, the exemplary workflow 600 described above may be executed by the tax payment processing server 110 in the form of applications software or a computer program stored in a memory of the tax payment processing server, or in the form of executable instructions stored in a hardware device of the tax payment processing server.

[00181] Alternatively, the workflow 600 may be executed in the form of smart contracts based on distributed blockchain ledgers, so that the workflow can be partially or fully executed or enforced without human interaction. The smart contract may be executed when specified conditions are met, e.g., the occurrence of one or more defined triggering events (such as the milestones Ml - M8 described hereinbefore). The smart contract responds to the defined triggers to transition from one contractual state to the next, e.g., by updating the blockchain ledger. As smart contracts are not controlled by a central authority, undesired tampering or modification may be avoided.

[00182] In at least some embodiments, a distributed ledger is used to store the data in relation to the transfer of funds in or out of the holding account, and/or data in relation to the change in shipment status of the goods. As described hereinbefore, the distributed ledger is replicated across the communication network 140. The tax payment processing server 110 manages at least a portion of the distributed ledger, which may be stored in the memory 720 of the tax payment processing server 110, or in a local or remote external data store 760 accessible by the tax payment processing server 1 10, as shown in Fig. 7. [00183] According to at least some embodiments, the methods and systems described herein provide a low-cost, efficient technical infrastructure that enables convenient and fast payment of one or more taxes imposed upon goods entering a taxing jurisdiction.

[00184] In at least some embodiments, the proposed methods and systems utilise a distributed ledger to track the transactions of the funds in or out of the holding account and/or the shipment status of the goods, which may effectively improve the integrity, transparency and accessibility of the data. With the distributed ledger, information pertaining to the transactions of the funds and the shipment status of the goods can be updated securely in real- time or near real-time. The distributed ledger may also allow reduction of error or fail rates of transactions as compared to conventional tax-collection systems.

[00185] In at least some embodiments, the data related to funds transaction and the shipment status is recorded in a blockchain in the distributed ledgers. By using a blockchain, transactions can be recorded efficiently in a secure, traceable and immutable way. It also allows the participants to verify and audit transactions inexpensively.

[00186] In at least some embodiments, the blockchain can be updated by different parties along the life cycle of the shipment of goods, so that messages and data transferred within the system across the network may be significantly reduced, thereby improving the efficiency of utilisation of network resources. Allowing the blockchain to be updated by different parties rather than a single server may further increase data transparency and data security of the system, and may effectively prevent the central server tampering with the blockchain.

[00187] In some other embodiments, the updates to the blockchain are performed only by the tax payment processing server, which allows the configuration of the seller system and the destination operator system to be simplified.

[00188] In some exemplary embodiments described above, eight milestones Ml - M8 are defined as triggering events for updating the distributed ledger. In some other

embodiments, when the parcel ID is used instead of the RR label for tracking the goods, the milestone M2 may not be required. Alternatively, in some other embodiments, any suitable number of milestones or trigging events may be defined. [00189] Further, in the exemplary embodiments described above, a blockchain is used to record the data, e.g., data related to the transactions and/or shipment status of the goods, to be stored in the distributed ledger. Alternatively, in some other embodiments, more than one blockchain may be used for recording relevant data. In some further embodiments, the data in the distributed ledger may be stored in any other suitable forms or data structures in addition to or as an alternative to a blockchain. However, using one or more blockchains to record the data may allow recording the transactions and/or shipment status of the goods in a traceable and immutable way. It may also allow the participants to verify and audit transactions efficiently and inexpensively.

[00190] Further, in the exemplary embodiments described above, a shadow account associated with the seller may be created and used for holding funds for the payment of tax.

In some other embodiments, in addition to the shadow account associated with the seller, a float account associated with the destination taxing authority may be created, and used for receiving payment from the seller holding account. The funds held in the taxing authority holding account may be withdrawn by the destination taxing authority at any time (e.g., regularly).

[00191] Further, in the exemplary embodiments described above, the goods sold are delivered to the buyer’s country. Alternatively, the described methods and systems may be used in the circumstances where the destination country is not the country where the buyer is located, but another country (or other type of taxing jurisdiction) specified by the buyer, in which one or more taxes are levied upon the goods. The payment accordingly would be paid to the taxing authority of that country (or that taxing jurisdiction).

[00192] Further, in some exemplary embodiments described above, the unique identifier associated with the blockchain is recorded in the machine readable information borne by the RR label. Alternatively or additionally, the unique identifier may be recorded on the RR label in clear text. Correspondingly, rather than capturing the machine readable information, the destination operator may manually input the unique identifier recorded on the RR label into the destination operator terminal computing device 330. However, using machine readable information may significantly improve the efficiency of the process and also enhance the security of the system. In some alternative embodiments, the parcel ID is used for tracking the goods instead of the RR label that bears the machine readable information containing the unique identifier associated with the blockchain.

[00193] Further, in the exemplary embodiments described above, the described methods and systems are used for the payment of tax for goods purchased online.

Alternatively, the described methods and systems may also be used for processing payment of tax in relation to goods purchased by the buyer in any other suitable manner, e.g., goods ordered by mail or telephone.

[00194] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

[00195] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings.

Claims

nil CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A method for the distribution of goods, including:

upon determining that the later block has been added to the blockchain:

2. The method of claim 1, further including:

generating a unique identifier associated with the blockchain, wherein a tag bearing machine readable information containing the unique identifier is generated, and attached to or associated with the goods before they are despatched by the seller.

3. The method of claim 2, wherein the machine readable information on the tag is captured when the goods are despatched.

4. The method of claim 1, further including:

receiving a parcel identifier associated with a parcel for sending the goods; and storing, in a data store, the parcel identifier in association with a unique identifier associated with the blockchain.

5. The method of any one of the preceding claims, wherein a further block is added to the blockchain in response to reception of a signal indicating despatch of the goods.

6. The method of claim 5, wherein the further block is added to the blockchain by a seller system.

7. The method of claim 2, wherein the machine readable information on the tag is captured after the goods have arrived at the destination taxing jurisdiction to record the arrival of the goods in the destination taxing jurisdiction.

8. The method of any one of the preceding claims, wherein an another further block is added to the blockchain in response to reception of a signal indicating the arrival of the goods in the destination taxing jurisdiction.

9. The method of claim 8, wherein the another further block is added to the blockchain by a destination operator system.

10. The method of claim 2, wherein an additional further block is added to the blockchain in response to the tag bearing the machine readable information being generated.

11 The method of claim 10, wherein the additional further block is added to the blockchain by a seller system.

12. A system for the distribution of goods, the system including one or more electronic processing devices configured to:

upon determining that the later block has been added to the blockchain: query the blockchain to determine the amount of tax payable; and

instruct a transaction processor to transfer funds corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

13. The system of claim 12, wherein the one or more electronic processing devices are further configured to:

generate a unique identifier associated with the blockchain, wherein a tag bearing machine readable information containing the unique identifier is generated, and attached to or associated with the goods before they are despatched by the seller.

14. The system of claim 13, wherein the machine readable information on the tag is captured when the goods are despatched.

15. The method of claim 12, wherein the one or more electronic processing devices are further configured to:

receive a parcel identifier associated with a parcel for sending the goods; and store, in a data store, the parcel identifier in association with a unique identifier associated with the blockchain.

16. The system of any one of claims 12 - 15, wherein a further block is added to the blockchain in response to reception of a signal indicating despatch of the goods.

17. The system of claim 16, wherein the further block is added to the blockchain by a seller system.

18. The system of claim 13, wherein the machine readable information on the tag is captured after the goods have arrived at the destination taxing jurisdiction to record the arrival of the goods in the destination taxing jurisdiction.

19. The system of any one of claims 12-18, wherein an another further block is added to the blockchain in response to reception of a signal indicating the arrival of the goods in the destination taxing jurisdiction.

20. The system of claim 19, wherein the another further block is added to the blockchain by a destination operator system.

21. The system of claim 13, wherein an additional further block is added to the blockchain in response to the tag bearing the machine readable information being generated.

22. The system of claim 21, wherein the additional further block is added to the blockchain by a seller system.

23. A method for the distribution of goods, including:

receiving a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller; adding a block to a blockchain, the block containing information identifying at least the amount of tax payable; determining when a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority, has been added to the blockchain; and

upon determining that the later block has been added to the blockchain: causing a transfer of funds, corresponding to the amount of tax payable from the holding account to an account associated with the taxing authority.

24. A system for the distribution of goods, the system including one or more electronic processing devices configured to:

receive a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller;

add a block to a blockchain, the block containing information identifying at least the amount of tax payable;

25. A system for the distribution of goods, the system including:

a seller computing system;

a tax payment processing computing system configured to receive a signal indicating completion of a payment to a holding account, the amount of the payment corresponding to an amount of tax payable for goods sold by a seller, the tax payment processing computing system or the seller computing system being further configured to add a block to a blockchain, the block containing information identifying at least the amount of tax payable; and a destination operator computing system configured to add to the blockchain a later block, indicating that the goods sold by the seller are released for delivery in a destination taxing jurisdiction having a taxing authority,

26. A system for the distribution of goods, the system including:

a seller computing system;