patent.txt

Embed Size (px)

Citation preview

  • 8/10/2019 patent.txt

    1/9

    Was going to file this, but would need lawyers to get it accepted, so publishingin the public domain so no-one else can patent it.-------------------------------------------------------

    System and method for enabling trusted digital cryptography based payments between 2 parties engaged in a commerce transaction for physical goods delivery

    ABSTRACTThe present application describes systems and methods for enabling secure, trusted transactions between 2 parties for the delivery of physical goods for paymentin digital cryptography based currency, such as but not limited to Bitcoin.

    Crypto-currencies incur very small transaction costs and so are an attractive payment mechanism for the Payee. Crypto-currency can also not be challenged by thePayer as they can with PayPal or visa and so are attractive for the Payee as there can be no charge-back fraud.

    This presents a problem for the Payer purchasing goods of non-delivery from thePayee. Once they have paid for the goods, they cannot reverse the payment and sorun the risk of the goods not arriving. Crypto-currencies are not tied to a specific identity and so there is no way to prove that the payment came from a certain actor to another certain actor, only that the actors involved held the correct cryptographic keys to enable the transaction.

    I propose a solution whereby the multi-signatory features of digital crypto currency are used to enable an escrow involving actors: the Payer, Payee and Courier. The Courier takes on the dual role of Courier and escrow agent. The payment isheld in a multi-signatory escrow address which requires the digital signature of 2 or the 3 aforementioned actors in order to release payment to the Payee- orback to the Payer. The payment is released to the Payee on receipt of the delivery. The Courier does not release the goods to the Payer until he has signed thetransaction. After which the Courier also digitally signs the transaction and transmits the transaction to the digital cryptographic currency network. The release of the funds to the Payee account can be confirmed at the point of executionand the transaction is complete.

    The opportunity is also provided for the Payer to check the condition and correc

    tness of the goods, if at which point they are not satisfied, the transaction can go into arbitration or the funds can be rolled back to the Payer there and then.

    Negotiation can occur directly between the Payer and Payee, or via the Courier Company (in the example of the goods being damaged in transit). As the multi-sigtransaction only requires 2 or 3 signatories, this provides flexibility in dispute resolution.

    Current cash-on-delivery systems require the Courier to take on risk on behalf of the Payee, the system described in the present application requires no risk onbehalf of the Courier and reduces the risk of Payer to non-delivery of, incorrect or damaged goods.

    IMAGESFigure 1. Process OverviewFigure 2. Signing ProcessFigure 3. Method of Initiating TransactionFigure 4. Methods of Loading Data onto the Signing DeviceFigure 5. Method of Completing TransactionFigure 6. Method of Rolling Back Transaction

  • 8/10/2019 patent.txt

    2/9

    CLAIMSDESCRIPTIONCOPYRIGHT NOTICEFIELD OF THE INVENTIONThe present invention related to fields of digital crypto-currency and escrow services.

    BACKGROUND OF THE INVENTIONSUMMARY OF THE INVENTIONBRIEF DESCRIPTION OF THE FIGURES

    DETAILED DESCRIPTION OF THE INVENTIONThe emergence of digital cryptographic currency has provided the potential for both increased and reduced risks in the exchange of goods between two parties. Bitcoin relies on a distributed peer-to-peer network to validate transactions andmaintain a cryptographically secure decentralized Blockchain of transactions. Funds move between addresses which are not tied to any persons identity. If you arein possession of the cryptographic private key tied to the address, you have the authority to spend any funds associated with the address. Transactions of thisnature cannot be reversed, once said transactions are accepted into the Blockchain it is cryptographically impossible to reverse back out.Bitcoin addresses are based on a public/private key pair used to authenticate the address.

    The address itself is a string of characters for example, mwDCKFdWGpFohottqxk6g4pqF6DFGKwUZbThe address is generated from an algorithm performing a series of hashes and transformations on the public key, such that the public key cannot be recovered from simply knowing the address. The private key associated with the public key used to generate the address is required if funds attached to theaddress are to be spent.

    The Bitcoin protocol allows for the generation of an address based on multiple key pairs, with a parameter determining the number of digital signatures requiredon the transaction to spend the funds attached to the address.This is known as a MultiSig (multi-signatory) address and MultiSig transaction.

    A MultiSig, or n of m, address might be a 2 of 3 address, with 3 public keys, requiring at least 2 digital signatures. Or it could be a 7 of 7 address, with 7 public keys requiring 7 digital signatures to spend the funds. Any combination ofintegers where n

  • 8/10/2019 patent.txt

    3/9

    erned with levels of trust from trustless to full trust and all combinations that could present themselves in all relationships between the parties.

    In the simplest example the Payer, Payee and Courier all have full-trust with each other and so can trust any party to aggregate the public keys involved in thetransaction. In this scenario the Payee is best suited to be the aggregator ofthe public keys. The Payee proposal of the public keys to use for the MultiSig address can be immediately accepted by the other parties as they all have full trust. An example of full-trust might be, but is not limited to, a Consumer purchasing from Amazon.com with Fed- Ex as the Courier. The long standing relationshipbetween the three parties and the reputational damage to Amazon and Fed-Ex should they maliciously corrupt the key aggregation process could be enough to permit the parties not to validate that the public keys of the other parties do indeed belong to said parties.

    In the other extreme all the parties involved have no trust with any other partythat is a signatory on the transaction and so must turn to 1 or many trusted parties to prevent the public key aggregator acting dishonestly or to comply withregulations such as but not limited to, public keys being required to be validated by 1 or many trusted authorities. Any proposal by the aggregator has to be validated by each participant, who in turn validates each key. Once the validationof the keys is in place the process can move on to the next stage.

    A more typical scenario would be the Payer has full-trust with the Courier but n

    o trust with the Payee. In this scenario the Payer cannot trust the Payee as theaggregator of the public keys and so must validate the keys provided. He validates his own key was the one he provided to the Payee, and contacts the Courier to confirm that one of the other two keys provided is owned by the courier. Oncethe validation of the keys is in place the process can move on to the next stage.It is important to note that any party in possession of the public keys and theparameter NumberOfSignatoriesRequired can derive the actual address that the funds will be transferred to. The present application presents a system whereby anyof the participants can function as the key aggregator.

    This present application is concerned with a 2 of 3 multi-digital signature address and 2 of 3 multi-digital signature transaction where the participants are a

    Payee, a Payer and a Courier. Upon the agreement to purchase goods between the Payee and the Payer in an online purchase, the Payee provides a Courier, or a list of available Couriers who can support escrow. A multi-digital signature address is generated based on 3 public keys provided by the Payee, Payer and the Courier. Any funds sent to this address can only be spent by a transaction containingat two digital signatures matching the respective public keys used to generatethe address.Valid combinations would be:

    1. Payer and Courier2. Payee and Courier3. Payer and Payee

    Payer and CourierThe Payer and the Courier are physically present on delivery of the goods. The correctness and condition of the goods can be validated by the Payer with the Courier present and if correct the Payer digitally signs a transaction which when signed by another valid signatory and transmitted to the relevant payment network, will transfer funds from the multi-digital signature address to the Payee. This indicates the Payer is happy with the goods and their condition. The Courier transfers the goods to the Payers ownership. The Courier then digitally signs thetransaction confirming that the goods have been delivered and transmits the transaction to the network. The funds are released to the Payee and the success of t

  • 8/10/2019 patent.txt

    4/9

    he transaction is confirmed.

    Payee and CourierThe Payer is not happy with the goods delivered and so will not digitally sign the transaction on delivery. The Courier retains possession of the goods and thePayer digitally signs a transaction transferring the funds from the multi-digital signature address to the Payer. The Courier returns the goods to the Payee.

    Payer and PayeeIn the event of the Courier company folding or losing private keys associated with the address, the Payer and the Payee can still authorize the movement of thefunds directly

    Methods of Key Exchange and Agreement1. One party is nominated as key aggregator2. Each party provides a key to the key aggregator and the key aggregator provides his own3. The key aggregator publishes his proposal for the keys4. Each party that has full-trust with the key aggregator approves the proposal5. Each party that has no-trust with the key aggregator contacts each other party that it has full- trust with and validates that the proposed keys are genuine,if the keys are not genuine the proposal is rejected6. Each party that has no-trust with the key aggregator, for each other party that it has no-trust with, contacts a nominated trusted party and validates that t

    he proposed keys are genuine, if the keys are not genuine the proposal is rejected7. a. If any party rejects the proposal, the process stops b. If all parties agree on the proposal the process continues

    Method of initiating transactionSee diagram 1

    1. Payer selects goodsThe goods available for purchase can be selected on any kind of e-commerce platform, be it a website or software application running on any technology platform,such as a web server or a smart phone. The Payee totals up the amount of the goods and provides the Payer with a pre- total for the goods.

    2. Payer selects payment optionThe Payer selects to pay with a crypto-currency based on a list of available crypto-currencies, such as Bitcoin.

    3. Payer selects Courier optionPayer selects from a list of Couriers which support the MSE method for the crypto-currency selected in step (2). The Payee provides a total amount to pay including any taxes and Courier fees applicable.

    4- 16. Public keys are agreed upon as per Methods of Key Exchange and Agreement.Each party now has a record of the public keys to be used in the transaction and can derive the MultiSig address.

    17. Payer makes payment to multi-digital signature addressThe Payer makes the correct payment amount established in step (3) to the multi-digital signature address derived from the public keys established in steps (4-16) and provided to the Payer in step (12). The Payer uses the payment network for the crypto-currency established ascurrency for payment in step (2). The transaction is executed from, but not limited to, a wallet stored directly on a device owned by the Payer, a wallet hostedby a third party on behalf of the Payer, payment functionality provided by thePayee which may or may not utilize a third party that hosts the wallet associat

  • 8/10/2019 patent.txt

    5/9

    ed with the Payers addresses. The transaction will be broadcast to the network,such as but not limited to the Bitcoin network via a participating node and rebroadcast from node to node until it has propagated throughout the network. The transaction will subsequently be included in the Blockchain and can be verified byanyone with access to said Blockchain. In crypto-currencies such as Bitcoin theBlockchain is readable by anyone in the world with suitable tools or technology.

    18. Payee confirms payment to multi-digital signature addressThe Payee verifies that the transaction is present in the Blockchain and is of the correct amount agreed on in step (3). ? what if correct funds do not arrive?

    19.a. Payee requests dispatch from CourierThe Payee creates a dispatch request for the Courier and transmits the details electronically, including details of physical delivery addressb. Payee transmits details for payment release to the CourierThe Payee provides details required for payment release. The script created in steps (4)- (16), the currency of the transaction established in step (2), the amount of the transaction established in step (3), the address of the Payee to which the funds will be transferred in the event of a completed delivery. The address of the Payer to which the funds will be transferred in the event of a failed delivery. The data is transmitted electronically using protocols such as, but notlimited to, a web service hosted by the Courier or via electronic mail such as,

    but not limited to email or text message.

    20. Courier stores against dispatch recordThe Courier receives the dispatch request initiated by the Payee in step (19a) and stores the transaction data received in step (19b) in a suitable database ordata storage device.

    21. Transaction Details are Transmitted to Devices The transaction details are made available to the electronic hand held devices carried by the Couriers engaged in the physical delivery of the goods. These handheld devices such as, but notlimited to custom devices such as STAR II/IIIdevices used by FedEx delivery personnel or an application running on a smartphone or tablet device. The handheld device requires software able to generate the correct transaction formats to be b

    roadcast to the network, connectivity to networks such as but not limited to theinternet, in order to connect to broadcast the transaction, software librariesto facilitate the communication protocols with the crypto- currency networks. The handheld device requires the ability to communicate with anotherdevice via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks.

    22. Payee generates shipping label with scan-able transaction detailsThe Payee prints a shipping label which includes a scan-able code, such as but not limited to a QR code. The code contains the details of the transaction to release funds from the multi- signatory address established in steps (4)-(16) together with the currency established in step (2), the amount established in step (3) and the address to release the funds to upon successful delivery established i

    n step (19b). The standard details normally included in shipping labels are alsoincluded, such as, but not limited to name, address of recipient.

    23. Courier ships goods

    The Courier ships the goods to the physical address established in step (19a)

    We define the following components:

    Payer Signing Device: such as but not limited to a smartphone or tablet running

  • 8/10/2019 patent.txt

    6/9

    an application provided by the Courier company or a third-party. The signing device requires the ability to scan a code such as but not limited to a QR code viaa camera or other device. The signing device requires access to the private keyassociated with the public key used in the Payer component of the multi-digitalsignature generated in step (10). The signing device requires the ability to communicate with other devices via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks. The signing device requires software with the ability to generate and digitally sign transactions in the correct format for transmission to networks such as, but not limited to, the Bitcoin network.

    Courier Signing Device: such as but not limited to custom devices such as STAR II/IIIdevices used by FedEx delivery personnel or an application running on a smartphone or tablet device. The signing device requires access to the private key associated with the public key used in the Courier component of the multi-digitalsignature generated in step (10). The signing device requires the ability to communicate with other devices via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks. The signing device requires software with the ability to generate and digitally signtransactions in the correct format for transmission to networks such as, but notlimited to, the Bitcoin network.

    Data for Signing:

    The data can be, but is not limited to be, a hash of a transaction representingthe transaction to be transmitted to the network, minus its signed key components.The transaction to be hashed for signing takes the form of, but is not limited to:

    1. Data for signing funds over to Payee

    TransactionIdInputsTransactionToSpendTransactionOutputToSpendMultiSig Script established in step (10)

    OutputsAddressOfPayee established in step (15b)Amount established in step (3)

    2. Data for signing funds over to Payer

    TransactionIdInputsTransactionToSpendTransactionOutputToSpendMultiSig Script established in step (10)OutputsAddressOfPayer established in step (15b)

    Amount established in step (3)Data for Payment to Payee:The data can take the form of, but not limited to be a transaction containing the following:TransactionIdInputsTransactionToSpendTransactionOutputToSpendSigned DFSS by PayerSigned DFSS by Courier

  • 8/10/2019 patent.txt

    7/9

    MultiSig Script established in step (10)OutputsAddressOfPayee established in step (15b)Amount established in step (3)Data for Payment to Payer:The data can take the form of, but not limited to be a transaction containing the following:TransactionIdInputsTransactionToSpendTransactionOutputToSpendSigned DFBS by PayerSigned DFSB by CourierMultiSig Script established in step (10)OutputsAddressOfPayer established in step (15b)Amount established in step (3)

    Methods of loading data onto a Signing Device

    Method 1The Payer and Courier connect to the Payees server via a network connection on the signing device such as but not limited to the internet. The Data for Payment and Data for Signing are loaded onto the respective Device for Signing, the detai

    ls are confirmed.

    Method 2The Payer and Courier connect to the Couriers server via a network connection onthe signing device such as but not limited to the internet. The Data for Paymentand Data for Signing are loaded onto the respective Device for Signing, the details are confirmed.

    Method 3The Courier connects to the Couriers server via a network connection on the signing device such as but not limited to the internet. The Data for Payment and Datafor Signing are loaded onto the respective Device for Signing, the details areconfirmed. The Courier transmits Data for Payment and Data for Signing details t

    o the Payers Device for Signing via a protocol such as but not limited to, NFC,Bluetooth, Infra-Red, Mobile networks, wireless networks. The Data for Payment and Data for Signing are loaded onto the Payers Device for Signing, the details are confirmed.

    Method 4The Payer and Courier utilize an image reading device such as but not limited toa camera to scan the code printed on the package such as but not limited to a QR code. The Data for Payment and Data for Signing are loaded onto the respectiveDevice for Signing, the details are confirmed.Method of completing transaction

    1. Payer loads transaction details using one of Methods of Loading Data onto a S

    igning Device

    2. Courier loads transaction details using one of Methods of Loading Data onto aSigning Device

    3. Payer Digitally signs Transaction The Payer uses software on the device for signing to create a Data for Signing Funds over to Payeeon the device. The software loads the private key associated with the public key established in step (4).The software digitally signs the Data for Signing Funds over to Payeewith said private key to generate a digital signature of the Data for Signing Funds over to P

  • 8/10/2019 patent.txt

    8/9

    ayee.

    4. Payer Transmits Digital signature to Courier

    The digital signature of the Data for Signing Funds over to Payeeis then transferred to the Couriers Device for Signing using a protocol such as but not limited to NFC, Bluetooth, Infra- Red, Mobile networks, wireless networks.

    5. Courier receives and verifies the digital signatureCourier receives and verifies the digital signature of the Data for Signing Fundsover to Payeetransmitted by the Payer and stores said digital signature of the Data for Signing Funds over to Payeein a database or suitable data storage devicelocated on, but not limited to be located on, the Device for Singing or a remote database connected via the Internet.

    6. Courier Digitally signs TransactionThe Courier uses software on the device for signing to create a Data for SigningFunds over to Payeeon the device. The software loads the private key associatedwith the public key established in step (8). The software digitally signs the DFSS with said private key to generate a digital signature of the Data for SigningFunds over to Payee.

    7. Courier generates Data for Payment to PayeeThe Courier uses software on the device for signing to create a Data for Payment

    to Payee on the device.

    8. Courier Transmits Transaction to networkThe Courier uses software on the device for signing to connect to the relevant network for the crypto-currency established in step (2) and transmits the data tothe network via a connection such as, but not limited to an internet connection.

    9. The Transaction is confirmed to have arrived on the network.

    The Courier uses software on the device for signing to confirm the arrival of the transaction on the network via a connection such as, but not limited to an internet connection.

    Method of rolling back transactionMethod of Immediate Rollback

    1. Customer loads Data for signing funds over to Payerdetails using one of Methodsof Loading Data onto a Signing Device

    2. Courier loads Data for signing funds over to Payerdetails using one of Methodsof Loading Data onto a Signing Device

    3. Payer Digitally signs Transaction

    The Payer uses software on the device for signing to create a Data for Signing Funds over to Payeron the device. The software loads the private key associated wi

    th the public key established in step (4). The software digitally signs the Datafor Signing Funds over to Payerwith said private key to generate a digital signature of the Data for Signing Funds over to Payer.

    4. Payer Transmits Digital signature to Courier

    The digital signature of the Data for Signing Funds over to Payeris then transferred to the Couriers Device for Signing using a protocol such as but not limited to NFC, Bluetooth, Infra- Red, Mobile networks, wireless networks.

  • 8/10/2019 patent.txt

    9/9

    5. Courier receives and verifies digital signature

    Courier receives and verifies the digital signature of the Data for Signing Fundsover to Payertransmitted by the Payer and stores said digital signature of the Data for Signing Funds over to Payerin a database or suitable data storage devicelocated on, but not limited to be located on, the Device for Singing or a remote database connected via the Internet. 6. Courier Digitally signs Transaction

    The Courier uses software on the device for signing to create a Data for SigningFunds over to Payeron the device. The software loads the private key associatedwith the public key established in step (8). The software digitally signs the Data for Signing Funds over to Payerwith said private key to generate a digital signature of the Data for Signing Funds over to Payer.

    7. Courier generates Data for Payment to Payer

    The Courier uses software on the device for signing to create a Data for Paymentto Payeron the device.

    8. Courier Transmits Transaction to network

    The Courier uses software on the device for signing to connect to the relevant network for the crypto-currency established in step (2) and transmits the data tothe network via a connection such as, but not limited to an internet connection

    .

    9. The Transaction is confirmed to have arrived on the network by the Payer andCourier

    The Courier uses software on the device for signing to confirm the arrival of the transaction on the network via a connection such as, but not limited to an internet connection.