ES2808412A1 - Procedure for creating and transmitting exchange documents using DLT technology (Machine-translation by Google Translate, not legally binding) - Google Patents

Abstract

It is a system for issuing, endorsing, accepting and submitting electronic exchange documents for payment, characterized in that each of these operations is performed by smart contracts/modules located in the account that the competent tax authority (in the case of bills of exchange) or the corresponding bank (in the case of checks) have open on the blockchain. The system incorporates a method for creating an electronic stamp, characterized in that the tax authority signs the serial number and class of the exchange document, and then, subsequently, a module located in the account verifies the validity of said signature, and that the serial number has not previously been used to issue another exchange document. (Machine-translation by Google Translate, not legally binding)

Description

DESCRIPTION

PROCEDURE FOR THE CREATION AND TRANSMISSION OF EXCHANGE DOCUMENTS USING DLT TECHNOLOGY

TECHNICAL SECTOR

The invention falls within the scope of distributed databases ( Distríbuted Ledger Technology, DLT), and particularly in the field of blockchain technology.

BACKGROUND OF THE INVENTION

Exchange documents are physical documents, made on paper, that incorporate rights of a credit nature, and are transferable under the conditions indicated by law. They are grouped into three main types: bills of exchange, checks and promissory notes. Currently, in accordance with Spanish legislation, for an exchange document to be valid it must be drawn up on a type of physical paper, called stamped paper, issued by the National Currency and Stamp Factory. In the present patent application a new procedure is described for creating electronic stamping paper, and for issuing exchange documents using exclusively this type of stamping paper. These documents would be stored in a distributed database, governed by the Libra protocol.

In the last decades of the 20th century, information technology and electronic databases have increasingly affected money transfers and property rights. In the legal field, since the 1980s there has been a process of "dematerialization" of negotiable securities (shares, bonds ...), by virtue of which said securities were no longer represented by paper documents, and were progressively incorporated to computer databases, thereby facilitating their transmission. At present, the creation and transmission of values no longer takes place through the drafting and signing of written documents but through the practice of entries in a centralized database.

An important milestone in the movement of traffic economic rights to cyberspace took place in 2008, with the appearance of Bitcoin and colored coins (in English colored coins). The latter can be defined as a set of satoshis uniquely and individually identified by a series of metadata, and which, as a consequence, are apt to represent patrimonial content rights. With the emergence of Bitcoin and blockchain technology, the possibility of practicing representative book entries of negotiable securities was opened not only in centralized registries, but also in decentralized electronic databases.

In 2014 Ethereum appeared, and with it, a second generation of blockchains equipped with virtual machines (simulated computers) capable of executing smart contracts. It was within Ethereum where the possibility of documenting negotiable values through tokens acquired full functionality, an English expression that defines those variables or data structures whose creation, transmission and amortization is controlled by a block of computer code, resident in the blockchain itself , and called smart contract (smart contract). Tokens can be of two types: fungible and non-fungible. Non-fungible tokens are those identified by unique characteristics, which make them fully distinguishable from others. The fungible tokens , on the contrary, are those that are identified by their gender, that is, by collective characteristics shared with others of the same class. Fungible tokens are beginning to be used to electronically document transferable securities, and within Ethereum initiatives are taking place to homogenize them through standards (such as the famous ERC20) that describe the essential functions that the contract must have as a minimum. smart that emits a token, and what are the basic characteristics that these functions must have.

Within the Libra protocol, economic rights are represented by resources , which play a role analogous to tokens within the Ethereum protocol. Algorithmic structures that control the creation, transmission and amortization of these rights are called modules, and are similar to contracts intelligent (smart contracts) other distributed protocols.

As with Ethereum, within Libra the information is structured in accounts, which store all the information related to the rights of a certain person, and transactions, through which alterations of the machine state of the chain and transfers of rights from one individual to another take place:

a) Accounts

Accounts are identified by their address, derived from a public key. Every time a user intends to create a new account, he must first generate, using an asymmetric cryptography algorithm, a pair of keys, private and public. The address is calculated by hashing the public key. The account is created when a transaction is sent to that address for the first time.

As previously explained, the information stored in each account is arranged in modules and resources. The modules ( modules) are the equivalent in Libra of the smart contracts of Ethereum: in both cases they are pieces of code that control the changes of the individual machine state of each account, and therefore, regulate the modification of individual rights and duties registered in it. Resources (resources), meanwhile, are variables used to represent rights within the database: they are the equivalent of criptomonedas and existing tokens in other blockchains, and therefore are fully eligible to electronically document incorporeal rights of a fungible nature, such as securities or negotiable securities. The issuance and amortization of resources are carried out by the modules of each account.

In the same way that there are different classes of tokens and cryptocurrencies, different types of resources can also be defined within Libra. The syntax of each of the latter is as follows:

account_address.intelligent_contract.resource

The type of resource is identified by three variables, separated from each other by points. The first corresponds to the address of the competent account to issue or amortize the resource. The second, to the smart contract in charge of carrying out these operations. And finally, the third is the name of the specific resource.

For example, if we wanted to create a type of resource (in this case, a security) called bono_rojo, charged to a smart contract called issuer, located in the account with address 0x45, its syntax would be the following:

0x45.emitter.red_bond

Once the resource has been issued, it can be transmitted and stored through all the accounts on the blockchain. Within each of them, the resource has the following syntax:

account_address / resources / resource_type

As an example, a security of name red_bond, issued by the smart contract of account 0x45 of issuer name, and that is in possession of account 0x25 is expressed by the following string:

0x25 / resources / 0x45.emitter.red_bond

An essential principle of the Libra blockchain is that resources can only be redeemed by the same account that issued them. Outside of this account, a kind of principle of resource conservation is imposed, by virtue of which resources can be transmitted, but never created (issued) or destroyed (amortized).

b) Transactions

Along with accounts (and their associated modules and resources), transactions occupy a prominent role in the Libra protocol. They are the only existing mechanism to modify the machine state of the blockchain, and therefore, to modify the rights of patrimonial content incorporated into it. It should be noted that unlike what happens in the Bitcoin and Ethereum protocols, in Libra the machine state of the chain is not updated block by block, but transaction by transaction. Transactions are configured as messages sent from one account to another, which must include, among others, the following fields:

-Address of sender and recipient.

-Public key corresponding to the sender's private key.

-Program: Computer code that must be executed by the virtual machine, accompanied by its input parameters and, optionally, the code of new modules (smart contracts) destined to be published.

The computer programs executed with each transaction are written in a specific language called Move IR, and they can include functions to withdraw funds from a specific account (eg withdraw_from_sender procedure) and assign them to the recipient account (eg deposit procedure). Transactions can be used to transfer funds from one account to another, but also for other purposes.

Once the transaction is executed, the events related to the execution and the result of the execution are published on the blockchain, including a Boolean that describes whether the transaction has been successful or not.

. EXPLANATION OF THE INVENTION

The patent being requested is included in section G06Q 50/18 ( Legal services; Treatment of legal documents - Legal Services; Handling legal documents) within the Cooperative Patent Classification .

The invention consists of a system to create electronic stamp paper, and to issue, endorse, accept and cancel bills of exchange, checks, promissory notes and any other type of exchange documents, in an electronic way and using a blockchain governed by the Libra protocol.

In the present system, each exchange document is represented by a resource (a concept that, as we have seen, within Libra is equivalent to Ethereum tokens ), which must conform to the following structure:

{

identifying section:

operative section:

link section:

encryption section:

}

The identification section contains all the points that identify the document, such as its class, its serial number and the electronic stamp, which is the signature of said data by the competent tax authority (in Spain, the National Mint and Stamp Factory ). The operative section contains all the circumstances relating to the creditor, the debtor, the amount owed and the expiration date, if any, as well as the certificates and signatures of the parties involved. The fields in this part of the document are sent encrypted to the blockchain using the AES ( Advanced Encryption Standard) system. The link section contains references (consisting of hash functions) to the previous or subsequent transmissions of the currency document. Finally, the encryption section contains the symmetric key with which the operative section has been encrypted, in turn encrypted with the public keys of the parties' certificates.

By the mode of designation of the holder, electronic titles can be bearer, nominative and to order:

a) Bearer securities

The holder is identified only by his email address, which in Libra - as we have already indicated previously - is equivalent to the hash of a public key. The public key / private key pairs are stored in a file called a wallet or, in English, a wallet .

The person who has in his possession the private key linked to the title is considered to be the owner, bearer and owner of the title. The transmission of the security can be done by physically handing over the private key to another person, changing said private key (a possibility supported by the Libra protocol) or transferring the security electronically to another address through a transaction.

Electronic bearer securities can be used to incorporate multiple equity content rights. In the field of bearer titles documented in writing, the Spanish jurist Rodrigo Uría established a classification that, without a doubt, is fully applicable to electronic titles:

-Payment certificates (checks, banknotes backed by a metallic standard, obligations issued by corporations, etc.), which make their holder the creditor of a monetary obligation.

-Social participation certificates (shares of public limited companies), which grant their holder political or economic rights within the scope of a company.

-Tradition titles (eg deposit receipt), which empower to demand the delivery of any object or merchandise.

All these assumptions are capable of being electronically documented.

b) Titles to order

The holder is identified with his name, surname and national identity document. Said identification is carried out by means of an electronic certificate issued by the National Currency and Stamp Factory, which links the identity of the natural person (or, where appropriate, the legal person) to a public key. The electronic certificate (which includes the public key) and the private key are stored in a specific file type called PKCS12 (in Windows, these files have the extension .pfx).

The essential characteristic of the titles to the order is that their transmission is carried out through a specific legal business called electronic endorsement. The title to the order par excellence is the electronic bill of exchange.

c) Registered titles

The identification of their holder meets the same requirements as that of titles to order (that is, the holder must be identified by means of an electronic certificate). Its particularity lies in the fact that the module that issues the security must keep a record in which each individually issued security is recorded, represented by a resource. The transmission of each one of them is carried out by modifying its corresponding resource. Registered titles can be used to document the most heterogeneous economic rights, from promissory notes to shares of Anonymous Societies.

3.2- Bills of exchange

A bill of exchange is a security that contains an abstract and unconditional order for payment to a creditor, called a holder, by a debtor, called a drawee, which the debtor must comply with and execute within a specified time. For this security to have the status of a bill of exchange, it must also meet a series of formal requirements required by exchange legislation.

In this section we will describe a new resource, the electronic bill of exchange. We will analyze its typology, its structure and its mechanisms of issuance (bypass) and transmission (endorsement).

a) Typology of the bill of exchange

In the model object of this patent application, each bill of exchange is configured as a Letter-type resource issued by the module (smart contract) called Issuer, located in the account that the state authority in charge of issuing digital certificates of natural persons has within a private blockchain governed by the Libra Core protocol. For the resource to meet the status of an electronic bill of exchange, it must contain the following data structure:

1: Emitter module {

2: resource Letter {

3: serial_number: char [16], // Serial number

4: class: int [4], // Letter class

5: tribute: float [16], // Tribute to pay

6: stamp: char [736], // Code issued by the FNMT (null padding of 2 bytes)

7: liberation_place: char [48], // Place of liberation

8: release_date: char [16], // Release date

9: currency: char [16], // Currency

10: amount_letter: char [48], // Amount to pay (in letters) 11: amount_number: float [32], // Amount to pay (in number) 12: issuer_certificate: char [736], // Digital certificate of the drawer (2-byte null padding)

13: drawer_address: char [96], // Drawer address

14: holder_certificate: char [736], // Digital certificate of holder (creditor, 2-byte null padding)

holder_address: char [96], // Holder's domicile

15: IBAN_fork: char [48], // IBAN of fork (14-byte null padding)

16: certificate_librado: char [736] // Digital certificate of the drawee (debtor, null padding of 2 bytes)

17: registered_address: char [96], // Address of the drawee

18: Librado_ID: char [96], // Common name (common name) of the drawee

19: expiration_date: char [16], // expiration date

20: signer_signature: char [256], // Signature of the drawer

21: fork_signature: char [256], // Fork's signature

22: signature_librado: char [256], // Signature of the drawee (only if it has been accepted)

23: endorsement: bool, // Has the letter been endorsed? 24: endorsement_address: address, // Next address in endorsement chain

(void, if it is the last endorsement)

25: acceptance: bool, // Has the letter been accepted? 26: release_key: char [256], // Symmetric key encrypted with the public key of the drawer

27: taker_key: char [256], // Symmetric key encrypted with the taker's public key

28: authority_key: char [256] // Symmetric key encrypted with the public key corresponding to the root certificate of the FNMT

//

//

40:}

41: // ...

42:}

Lines 2 to 28 create a kind of template to which all bills of exchange must be adjusted, and which will have to be filled in each time one of them is issued. The parameters of lines 3 to 6 (both included) make up the identifying section, and as their name indicates they are used to identify the bill of exchange. The parameters of lines 7 to 19 are called the operative section, and contain all the information related to the legal exchange business. All of them will be encrypted using a symmetric key generated by the drawee's computer. They contain the following information:

-Place of bypass, expressed in a string of 15 characters (char [15]).

-Date of clearance, encoded in YYYYMMDD format (in Spanish, YYMMDD, year, month and day), and expressed in a string of 8 characters (char [8]).

-Type of currency (euro, dollar, yen ...). It is a 15 character string (char [15]). -Amount of the amount to be paid. It is a 64-bit figure (u64), and whose range, therefore, extends from the number 0 to 18,446,744,073,709,551,615.

-Amount of the amount to be paid, expressed in letters, and specifically in a string of 50 characters (char [50]).

-Serial number. It is a 9 character string (char [9]).

-Tribute. Indicates the amount paid by the parties, as stamp duty.

-Digital certificate (X.509) of the holder and the drawer, necessary for their signatures to be considered legally binding, in the terms of article 25.2 of European Regulation 910/2014 (eIDAS Regulation). Certificates are saved in DER format, and consist of 734 bytes (char [734]) each.

-IBAN from the holder's bank account, where the payment is to be made. 34-byte string (char [34]).

-Digital certificate of the drawee (the debtor of the bill).

-Expiration date, encoded in YYYYMMDD format, and expressed in a string of 8 characters (char [8]).

-Signature of the drawer. 256-byte string (char [256]).

-Signature of the fork. 256-byte string (char [256]).

-Signature of the drawee (debtor). 256-byte string (char [256]) that is attached once the drawee has accepted the letter.

The parameters of lines 23 to 25 are given the generic name of link section, and are used for the reconstruction of the successive exchange tract:

-The endorsement field is a Boolean that indicates whether the letter has been transmitted (or not) to a third person by means of an endorsement.

-In the event that there has been an endorsement, the direccion_endoso field will contain the address where is located the previous letter.

-Finally, a Boolean indicates whether the letter has been accepted by the drawee or not. Its original value is 0. When the letter is accepted, its value changes to one.

The last three lines, which make up the encryption section, will store the symmetric key encrypted with the public keys of the drawer, the drawee and the state authority issuing the digital identification certificates (in the Spanish case, the FNMT).

Each time a policyholder prepares to acquire a bill of exchange, his computer will generate a pair of asymmetric cryptography keys, and from the public key it will calculate an electronic address, which will be where the bill is stored. Once the account is created, its private key will be modified, making it correspond to that of the certificate. The procedure for creating and storing the letter will be that established in section c).

b) Obfuscation of bill of exchange data

Unlike what happens with real property rights, which are subject to the principle of formal publicity and whose data is therefore available to third parties, the possession of an exchange document is only known, in principle, by the people who have granted it.

For this reason, it is necessary to create obfuscation mechanisms in the blockchain, which ensure that the content of exchange documents is only accessible to people who have a specific key.

The present invention incorporates the following mechanism:

-The data of the operative section will be encrypted using the symmetric encryption system AES ( Advanced Encryption Standard), using a symmetric key generated by the drawer's computer. This key will be shared with the borrower and the other subsequent holders of the bill, in such a way that they all have access to the data of the entire successive exchange tract.

-The data of the identifying section and the link section will remain unencrypted.

-The symmetric key will in turn be encrypted using the public keys of the policyholder, the drawer and the public authority in charge of issuing the digital certificates. The result will be stored in the fields key_librador, key_taker and key_authority, respectively (all of them located in the encryption section). Each time the borrower and the drawer intend to recover the original symmetric key, they may do so using their respective private keys.

c) Bypass

The act by which a bill of exchange is issued is called a draft or draft. Two people intervene in the act: the drawer and the first holder of the bill of exchange, called the payee. The drawer orders a third person, the debtor (also called the drawee), to pay a certain amount of money to the payee in a specified time. The debtor does not intervene in the settlement, and is not obliged to exchange until he accepts the bill of exchange, becoming the acceptor from that moment. The existing legal relationship between the drawer and the debtor is called the hedging relationship, the existing one between the drawer and the borrower is called the valuta relationship.

The issuance of an electronic bill of exchange is structured in the following phases:

-Through the website of the competent tax authority, the user will buy the necessary electronic stamp to validate the letter. The authority will provide the user with a JSON with the values of the fields serial_number, class and tribute, as well as the signature ( "stamp") of the same by said authority. The Keccak-256 hash function will be applied to each of these fields. The three resulting 256-bit strings will be assembled and the same function will be applied to the set again. Next, the result will be applied the private key of the root certificate of the said authority, and with this the electronic stamp to be incorporated into the bill of exchange will be obtained, which will be entered to the drawer via TLS protocol.

-In a way external to the blockchain, the policyholder will send their certificate and bank details to the drawer in JSON format, who will fill in the remaining data of the bill of exchange (not yet encrypted). The signature of the policyholder will fall on the identifying and operative sections of the document. The signed letter will be sent to the policyholder, who will also sign the same sections. The signature of the participants will be made on the data not yet encrypted, since otherwise, either of the two parties could urge the invalidity of the exchange business, claiming the existence of error (which is a vice of the invalidating will of a business legal, in accordance with the provisions of multiple European civil laws).

-The identifying and operative sections of the document will be encrypted following the procedure established in section b).

-The policyholder's computer will generate a pair of keys, public and private. From the first, the email address of the account where the future bill of exchange will be stored will be calculated.

-The private key of the policyholder's account will be modified and will match the one corresponding to his digital certificate.

-Finally, the letter will be sent to the blockchain by means of a transaction by the borrower to the FNMT account, in which the librar_letra function will be invoked within the Issuer module. The parameters of the transaction will be the place ( place_i), and the date ( date_i) of the settlement, the currency (currency_i ) in which it is carried out, its amount in number ( amount_i) and letter ( amount_letra_i), the serial number ( number_serie_i ), the electronic stamp ( timbre_i), the certificate of the drawer ( certificate_librador_i), the signature of the drawer ( firma_librador_i), the certificate of the policyholder ( certificate_tenedor_i), the IBAN of the policyholder ( IBAN_i), the expiration date ( expiration_date_i) and the encrypted keys of the drawer, the policyholder and the state authority in charge of issuing the electronic certificates ( key_librador_i, key_taker_i, key_authority_i). The transaction will be signed by the drawer and the borrower.

The function librar_letra should have a structure similar to the following:

1: Emitter module {

2: public release_letter (release_place_i, release_i_date, currency_i, amount_i, amount_i, 3: serial_number_i, stamp_i, release_certificate_i, release_signature_i, holder_certificate_i, holder_signature_i, IBAN_i, expiration_date_i, release_signature_i, holder_signature_i, holder_key_i, holder_key_i, holder_key_i): Letter {

//

// In the first lines of code, the function checks that the signature of the transaction by the drawer and the drawee is valid

//

100: RejectUnless (serial_number! = 0);

101: move_to_sender <Letter> (

102: Letter {

103: release_place: release_place_i,

104: release_date: release_date_i,

105: currency: currency_i,

106: amount: amount_i,

107: letter_amount: letter_amount_i,

108: serial_number: serial_number_i,

109: timbre: timbre_i,

110: release_certificate: release_certificate_i,

111: holder_certificate: holder_certificate_i,

112: IBAN_fork: IBAN_i,

113: expiration_date: expiration_date_i,

114: release_signature: release_signature_i,

115: fork_signature: fork_signature_i,

release_key: taker_key_i,

taker_key: release_key_i,

FNMT code: taker code i

116:}

117:);

118:}

119: // ...

120:}

In general terms, we can make the following observations:

-In the first four lines the input parameters of the function are set, which are precisely the data necessary to issue the bill of exchange.

-In lines 5 to 99, which are not developed in the diagram above, the function will check that the amount transferred to the FNMT account is the same as that described in the stamp field, and that the signatures of the participants are valid.

-Finally, on lines 101 to 114, the function fills in the bill of exchange template with the input data provided in the first four lines. After that, the letter is sent to the electronic address of the drawer (line 101, move_to_sender instruction).

d) Endorsement

The endorsement is that legal business by virtue of which the holder of a title to the order transfers his legal position of exchange creditor to another person. In the securities documented on paper, the endorsement is recorded on the back of the same document where the bill of exchange appears, as a kind of addition to the original exchange document, as shown in the image:

At the electronic level, this work proposes that endorsements be represented by a specific resource, called Endorsement, which would be linked to a specific bill of exchange by means of a reference ( hash) to the contents of the latter. The structure of each endorsement is relatively simple:

1: Emitter module {

2: resource Endorsement {

3: endorsement_number: int, // Position in the endorsement chain

4: old_address: address, // Previous address in endorsement chain

5: hash_letra: char [256], // Hash of the encrypted contents of the endorsement (or the letter letter) above

6: endorsee_certificate: char [734], // Endorsee certificate 7: endorsee_IBAN, // Endorsee account

7: new_endoso: bool, // Has there been a new endorsement? 8: next_address: address, // Next address in endorsement chain

(null, if it is the last endorsement)

9: endorser_signature: char [256] // Endorser signature

10: endorsee_signature: char [256] // Endorsee's signature

endorsee_key: // Symmetric key encrypted with the public key of the endorsee

// ...

twenty-one: }

22: // ...

2. 3: }

The data contained in this resource are the following:

-The direccion_anterior variable (line 4) contains the address of the account is stored letter original change (in the event that the case of the first endorsement) or that of the immediately preceding endorsement (in the case where previously there has been another endorsement). In this way, a sort of "successive exchange tract" is formed, at the beginning of which is the original bill of exchange, as it was drawn, and at the end of which is the last endorsement. This successive tract is reinforced by means of a cryptographic reference ( hash) to the immediately preceding exchange document (letter or endorsement). The number of endorsements produced so far will be recorded in the variable number_endoso.

-As in other cases, the resource (in this case, the endorsement) must store the electronic certificate of its holder ( certificate_endosatario).

-If the bill of exchange has been endorsed again, the Boolean referenced by line 7 will take the value of one, and the address of the new endorsement will be stored in the variable next_address.

All the data reviewed will be encrypted, except for those stored in the new_endoso, previous_address and next_address fields, which will retain their original values.

Electronic endorsements are made through a procedure very similar to that of the draft: First, the endorsee sends his certificate and bank details to the endorser. The endorser decrypts the symmetric key thanks to his private key and re-encrypts it with the public key of the endorsee's certificate, and save in the field recipient_key. After that, it will fill in the remaining data of the endorsement, and will calculate two signatures: One on the unencrypted data (requirement of Civil Law) and another on the encrypted data (requirement of the Libra protocol). Both will be sent to the endorsee, along with the content of the letter.

Next, the endorsee will send a message to the FNMT account, invoking the construct_tracto function, which will have the address of the electronic document to be endorsed as a parameter. Using the old_address (which is not encrypted) and hash references, the function will rebuild the endorsement chain, going back to the original letter. The data of the entire chain will be sent to the endorsee, who will decrypt them, and check their validity.

If everything is correct, the endorsee will sign the new endorsement data, encrypt it and send it through a transaction to the FNMT account. The transaction will invoke the function publish_endoso, which as its name suggests will publish a new Endorsement on the endorsee's account. The parameters of the transaction (and of the function) will be constituted by all the ends of the new endorsement, as well as by the signature of the endorser of the encrypted data of the letter. The publish_endoso function, which should be executed by all the nodes of the network, would have the following structure in Move IR language:

1: Emitter module {

2: public publish_endoso (...) {

//

... // In these lines the function will calculate the hash of the published contents // of the previous endorsement, and it will check that the (encrypted) data of the // new endorsement has been signed by the endorser //

101: let recipient_address address = GetTxnSenderAddress ();

102: let endor_ref: & mut Endorsement = BorrowGlobal <Endorse> (move (endorse_address));

103: let recipient_ref: & mut Endorsement = BorrowGlobal <Endoso> (move (recipient_address));

104: end_number_i = * move (& mut move (endorsement_ref). endorsement_number) 1;

105: * move (& mut move (end_ref). Endor) = 1;

106: * move (& mut move (sender_ref) .next_address) = recipient_address;

201: move_to_sender <Endoso> (

202: Endorsement {

203: recipient_certificate: recipient_certificate_i,

204: IBAN_endosatario: IBAN_endosatario_i,

number_endoso: number_endoso_i

}

)

}

In its first lines (2 to 106), not reproduced in the schema, the function will verify the signature of the endorser, it will calculate the hash of the previous endorsement, and it will modify two of the fields of the latter: the boolean new_endoso will take the value of one, and the variable next_address, the address of the new endorsement. The details of the new endorsement will then be filled in, and it will be published in the endorsee's account.

e) Password recovery

Given that the power of disposal over tokens and cryptocurrencies is intrinsically linked to a private key, the loss of the latter by its holder entails the impossibility of exercising the right. To prevent this undesirable result, in the case of securities issued by name or to order, the issuing module must have a function, recover_password, to recover the lost keys.

The user who intends to recover his key must previously obtain a new digital certificate from the FNMT, and open a new account within the Libra blockchain. Next, from this account, it will send a transaction invoking the retrieve_password function. Its parameters will be two:

-The new electronic certificate, encrypted with the public key of the FNMT root certificate.

-The address where the bill of exchange whose password has been lost is housed.

The function will check that the new certificate is valid, and that the old one has been revoked, and that both correspond to the same person. If the verification has been successful, the function will order a specific type of endorsement (signed this time with the private key of the root certificate of the FNMT), whose destination address will be, precisely, the new account from which the transaction originates. The symmetric key will be encrypted with the public key of the new certificate, and it will be stored in the recipient_key field of the new endorsement.

f) Acceptance

Acceptance is that act by the drawee gives his consent to become a foreign exchange obligee, thereby committing himself to execute the payment order ordered by the drawer. It is only necessary when the letter is enforceable at a time from sight.

Acceptance can be done at the same time the letter is rotated or can be done later. In the first case, the original document must include the certificate of the drawee, his address, as well as the signature of the latter on all the data of the same, in the same terms that are required of the holder. The accepted boolean must have the value 1.

If the acceptance is made later, the drawee must send a transaction to the FNMT, invoking the function accept_letter, within the Issuer module. The parameters of this function will be made up of the address of the letter, as well as the certificate and signature of the drawee. The function will check that the string ID_librado, which had identification effects, is present in the certificate of the drawee, and that the latter is valid, and has not been revoked. If the signature verification yields a positive result, the drawee's certificate will be incorporated into the original bill of exchange, whose accepted Boolean will take the value of 1.

g) Presentation for payment and cancellation of the bill

When the expiration date arrives, the bill may be presented for payment to the corresponding bank where the drawee had his account domiciled. A new resource called Cancellation will be created within the account that the bank has on the blockchain. The structure of the Cancellation resource will be as follows:

1: Emitter module {

2: resource Cancellation {

3: endorsement_number: int, // Position in the endorsement chain

4: address_presentante: address, // Address of the account of the presenter

5: hash_letra: char [256], // Hash of the encrypted contents in the submitter's exchange document

6: bank_certificate: char [734], // Endorsee certificate 7: representative_signature: char [256] // Endorser signature

8: bank_signature: char [256] // Signature of the endorsee

9: bank_key: // Symmetric key encrypted with the bank's public key

paid: bool, // Letter paid

protested: bool // Unpaid and protested letter //.

twenty: }

eleven: //.

12:}

The mechanism of submission to payment is relatively simple:

Once the exchange obligation becomes enforceable, the holder will request the payment of his bill through the domiciliary bank's server, in a way that is completely external to the blockchain. Together with the request, it will send the encrypted data of the entire chain of endorsements, as well as the symmetric key encrypted using the Bank's public key. The Bank will decrypt the symmetric key of the letter by means of its private key, will verify that all the data is correct and will try to carry out a transfer of funds from the drawee's account to that of the policyholder. If the banking entities of origin and destination are different, the letter and its chain of endorsements will be presented before a Clearing House.

In the event that the funds transfer has been successful, the paid boolean will take the value of one. If the transfer has been unsuccessful, the paid Boolean will take the value zero, while the protested Boolean will take the value one. In both cases, the Bank will send a transaction to the blockchain in which it will execute the cancel_letter function. This last function will check that the data has been signed by the donor, and if so, it will publish a Cancellation resource at the address assigned to the bank. The cancellation of the bill implies that no more endorsements can be made to it.

3.3- Checks

According to its original English definition, a check can be defined as "a bill of exchange payable on demand, the drawee of which is a bank."

Within the scheme that we present, checks are represented by resources with exactly the same internal structure as bills of exchange. The mechanisms for issuing, transmitting and presenting bills of exchange for payment are fully applicable to electronic checks, but with the following particularities:

a) On the written plane, the checks are not issued on stamped paper, but on a checkbook provided to the drawer by the drawee bank itself. In the electronic field, checks, like bills of exchange, have a quadruple structure made up of identification, operative, link and encryption sections. The only peculiarity of the checks is that in their identification section, it is the bank that sets the values related to the serial number, the tax and the class of the document. The stamp is replaced by the bank's signature of these three fields, as determined in section 3.2.c). The issuance, transmission and presentation for payment of checks are carried out through transactions made to the account that the drawee bank has on the blockchain, which will house the modules in charge of executing each of the exchange operations. The code housed in each of the modules It will have to be standardized and previously approved by the Ministry of Justice or the Ministry of Economy.

b) Checks do not necessarily have to be issued in nominative form. They can also be issued to the bearer. In the latter case, it is not necessary to attach the holder's digital certificate to the identification section of the electronic document. The creditor of the check would be identified exclusively with his public key, while the loss of his private key would imply the definitive damage to the document.

c) It is not necessary to set the date of its collection on the check. It will always be payable on demand.

3.4- Promissory notes

A promissory note is an exchange document by virtue of which a person, called the signer, is obliged to pay another, called the holder, an amount of money on a certain date. Promissory notes are always nominative, and cannot be transferred. Since they are not intended to circulate, in them the legal relationship that is documented is not triangular, but bilateral.

In our invention, the signing of the promissory note is carried out through a transaction to the competent tax authority (in Spain, the FNMT), following a procedure similar to that of the bill of exchange, only in this case, the fields relating to the drawer Bill and its holder, within the operative part, will be replaced by those of the signer of the promissory note and its holder, respectively. Since the promissory notes are not transferable, the link section will be non-existent.

PREFERRED EMBODIMENT OF THE INVENTION

A possible preferred embodiment of the invention would be constituted by the issuance of the bill of exchange, its subsequent endorsement and its final presentation for payment.

Example 1

One person ("Individual A") has a credit of 10,000 euros against another ("Individual B"), which is not payable at this time, but is payable at a certain date in the future. Individual A, who does not have liquidity, wishes to contract the services of a company ("Individual C"), transmitting the credit for the payment of said services. To do this, an electronic bill of exchange is signed, and Individual A takes the position as drawer, Individual B, as drawee, and Individual C as payee.

The drawer ("Individual A") contacts the server of a web application, and through it acquires from the corresponding tax authority (in Spain, the FNMT) the electronic stamp necessary to grant the new electronic document, also receiving a number of series and class of the new document to be released The three data, which make up the identifying section, are stored in the table of an SQL database on the server, in which all the other points relative to the new exchange document will also be stored. Each bill of exchange will correspond to a row within said table. At this moment, the row contains the data of the identification section and those data related to the operative section corresponding to the drawer (including its digital certificate), the amount owed and the expiration date of the document.

The policyholder ("Individual C") contacts the web application and transmits his digital certificate and address, which are stored within the SQL database, in the row corresponding to the bill of exchange that is being issued. The policyholder's data is transmitted, the web server will generate a symmetric key and encrypt it with the public keys of the policyholder and drawer certificates. With this, the identification, device and encryption section will be completed. Within the database, the row corresponding to the bill of exchange will consist of the following fields:

serial_number: 0 A 63957493

class: 10

tribute: 0.96

stamp: Signature of the Spanish FNMT

release_place: Seville

release_date: 02-27-2020

euro coin

letter_amount: Ten thousand

amount_number: 10,000

certificate_librador: Certificate of Individual A

home_librador: Seville

certificate_holder: Certificate from Individual C

holder_home: Seville

IBAN_forward: Individual C's IBAN

expiration date: 01-01-2021

The letter can then be signed by the parties who will receive a response from the server via HTTPS protocol, which will include all the data of the letter. The letter will be signed by the user's browser, which will send the server a request (also by HTTPS protocol) whose body will contain, structured in JSON format, the serial number of the letter, the signature of its encrypted data (requirement of the Libra protocol ), as well as that of unencrypted data (legal requirement).

The web application will verify that the signatures are correct, and that the certificates have not been revoked. If everything is correct, it will send a transaction to the blockchain in which the librar_letra function will be invoked, and all its data will be transmitted. The librar_letra module will create a Letter resource in the policyholder's account, and with this the creation of the new exchange document will be complete.

Example 2

On July 27, 2020, one person ("Creditor") lends to another ("Debtor") 100,000 euros to be repaid in four years, with an interest of 2,500 euros per year. The contracting parties transmit their data to a web application, which configures with them four promissory notes for an amount of 25,625 euros each, which expire respectively on July 27, 2021, 2022, 2023 and 2024. All of them are signed by the parties and sent to the blockchain, where they will be validated by an account module of the National Mint and Stamp Factory (or other equivalent fiscal authority). If the validation is successful, the promissory notes will be stored in the creditor's account, who may present them for payment when the due dates arrive. their maturities.

Claims (5)

1. Structure of a new type of electronic document, characterized in that it is made up of four sections called identifying, operative, link and encryption. The first is used to identify the document (serial number, class and tax to pay) and includes the electronic stamp issued by the corresponding tax authority. The second contains all the points related to the credit right incorporated into the exchange document (identification of the parties, amount to be paid, expiration date, domiciliary bank account, signature of the parties). The link section allows the transmission of the exchange document, and links the original draft / check with its subsequent endorsements by means of hash functions. The last section (encryption) obfuscates the bill of exchange data on the blockchain by using the symmetric encryption system AES ( Advanced Encryption Standard). The symmetric key used is encrypted using the parties' public keys, which in turn can retrieve them using their respective private keys. 2. Method for creating electronic stamped paper, characterized in that the stamp is constituted by the signature of the data in the identification section of the exchange document by the tax authority. This signature is made by the backend of your website and is delivered to the user through the HTTPS protocol. Once the exchange document is filled in, signed by the parties and sent to the blockchain for validation, a smart contract / module, located in the account that said authority has on the blockchain, is in charge of verifying the signature and verifying that the document's serial number has not previously been used to issue another exchange document. 3. Method to electronically issue bills of exchange, checks, promissory notes and other commercial documents, characterized in that the exchange documents are issued through a smart contract ( module) located in the account that the competent tax authority has in a private blockchain governed by the Libra protocol or another of similar operation. The exchange document takes the form of a JSON object whose content is electronically signed by the parties through their digital certificate and private key. Next, the stamp of the competent tax authority is added to the document. 4. Method to electronically endorse bills of exchange, checks, promissory notes and other commercial documents characterized in that each endorsement is represented by a resource within the Libra protocol, which is related to the original bill / check and subsequent endorsements by means of hash functions included in the link section. The set formed by the bill of exchange / check and its subsequent endorsements is called the successive tract to change it, and is used by the courts of justice to determine the validity or invalidity of the transmissions of the respective document. 5. Method to present exchange documents for payment, characterized in that the entire successive tract of exchange is sent via HTTPS protocol to the website of the domiciliary banking entity, which will determine through a program located on the server side ( backend) if the chain endorsements is valid and if there are enough funds in the domiciliary account to meet the payment of the document. If so, the bank will make the payment and the boolean paid will take the value of one in the original document. Otherwise, the protested boolean will take the value of one in the original document. In both cases, the bank will send a Cancellation resource to the blockchain to definitively close the successive exchange tract. In the case of the opening of an exchange trial, the competent tax authority will definitively decipher the symmetric code of the tract and deliver it to the Lawyer of the Administration of Justice attached to the court where the trial is held, with the aim that the deciphered content of the letter and subsequent endorsements remain at the disposal of the judging body.