Blockchain seems to have become a new buzzword in the tech industry. We are told it has the power to transform everything from finance to supply chains, to decentralise the control of data and even to revolutionise intellectual property itself.

According to the European Patent Office there were over 2,000 blockchain patent families published in 2018 compared to zero in 2008. The territories with the largest number of filings during this time were the US and China (by far) followed by the EPO and South Korea.

The top worldwide applicants include IBM, Mastercard and Visa. The top EPO applicants include Visa, Mastercard, Nokia and Sony.

What exactly is blockchain? What type of blockchain inventions might be patentable?

To demonstrate the principles of blockchain, let’s look an example in which a blockchain is used to store a digital ledger. A ledger is a set of ordered transactions between a plurality of parties. Our example shared ledger (figure 1) involves four participants, Alice (A), Bob (B), Charlie (C) and Dave (D).

Figure 1 (digital ledger):

(1) A sends B £50

(2) B sends C £120

(3) B sends D £20

(4) C sends A £40

We will assume that each of our participants A, B, C and D start with £100.

After transaction (1), A has £50 and B has £150. After transaction (2), B has £30 and C has £220. After transaction (3), B has £10 and D has £120. After transaction (4), C has £180 and A has £90.

The ledger can thus be used for financial transactions between A, B, C and D in place of physical money.

Each transaction must adhere to certain rules in order for it to be accepted and added to the ledger.

• Rule 1 is that no party should be able to send more money than they have available. So, if A were to try to send more than £100 as transaction (1), this should be rejected. Similarly, if B were to try to send more than £30 as transaction (3), this should be rejected.
• Rule 2 is that it should only be possible to send money from one party to another with the permission of the sending party. So, transaction (1) can only occur with the permission of A, transaction (2) can only occur with the permission of B, etc.

Rule 1 can be enforced by the initial amounts of each party being included as initial lines on the ledger (in the form “A has £100”, “B has £100”, etc.), for example. The amount of money each party has available to “spend” at any given time is then given by the running total of credits to and debits from that party (e.g. transaction (1) is a debit from A and a credit to B, transaction (2) is a debit from B and a credit to C, etc.).

Rule 2 can be enforced by requiring that each transaction contains some unique information and is digitally signed by the sender (e.g. transaction (1) contains the unique number “1” and is digitally signed by A, transaction (2) contains the unique number “2” and is digitally signed by B, etc.).

The transaction is only added to the ledger if the digital signature can be verified. The digital signature can only be verified if it has genuinely been created by the sender and the transaction has not been altered in any way.

Who stores the digital ledger?

Conventionally, the ledger is stored centrally by a single, trusted party X. Each of A, B, C and D must trust that X will, for example, check that each transaction it receives satisfies rules 1 and 2 and add all such transactions and nothing but those transactions to the ledger. X may be a bank, for example.

An alternative to a central ledger is that each party A, B, C and D stores their own copy of the ledger. When one of the parties wishes to add a transaction to the ledger, they broadcast that transaction to each of the other parties. So, A broadcasts transaction (1) to each of B, C and D. B broadcasts transactions (2) and (3) to each of A, C and D. C broadcasts transaction (4) to each of A, B and D. Each party then adds that transaction to their copy of the ledger. Each party thus, in principle, has their own copy of the ledger and each copy of the ledger is the same (this is referred to as a shared or distributed ledger). There is therefore no need for X and the central ledger.

There remains a problem, however. The distributed ledger relies on the parties A, B, C and D all trusting each other in a similar way that X was trusted as holder of the central ledger.

For example, when B receives transaction (1) (“A sends B £50”) from A and records transaction (1) on its ledger, B must trust that A has also sent transaction (1) to C and D to allow C and D to record transaction (1) on their ledgers. If A has not done this (either by mistake or to deliberately defraud B), then neither C nor D will accept transaction (2) (“B sends £120 to C”) when they receive it from B because they will think that B only has £100 (not £150 due to transaction (1)). The copy of the ledger held by B (with transaction (1)) is thus different to the copies of the ledger held by C and D (without transaction (1)) and the £50 received by B from A in transaction (1) is no good to B if they wish to transfer money to C or D. This is a big problem with distributed ledgers.

Blockchain solves this problem by making it virtually impossible for a single party to add a transaction to the shared ledger without broadcasting that transaction to each of the other parties.

Figure 2 shows the same ledger as shown in figure 1 stored as a blockchain. The blockchain comprises multiple blocks (blocks 1, 2, 3 and 4). In this example, each block contains a respective one of the transactions (1) to (4) (including, though not shown, the digital signature of that transaction). In reality, each block may contain multiple transactions (each including its respective digital signature).

Figure 2 (blockchain):

Cryptographic hash

Each block also contains a cryptographic hash of the block, the cryptographic hash of the previous block (the first block does not have this because it has no previous block) and a “proof of work” (explained below). Each party A, B, C and D stores their own copy of the blockchain.

The cryptographic hash of each block is generated by applying a cryptographic hash algorithm to certain information held in the block (this information is an input to the cryptographic hash algorithm). For example, Hash#1 of block 1 is generated using the combination of the transaction information “(1) A sends B £50” and the proof of work information “06542444” as input information. Hash#2 of block 2 is generated using the combination of the transaction information “(2) B sends A £120”, the proof of work information “43251572” and Hash#1 as input information. Hash#3 of block 3 is generated using the combination of the transaction information “(3) B sends D £20”, the proof of work information “47865445” and Hash#2 as input information, and so on. Including the hash of the previous block when generating the hash of the current block “chains” the blocks together (hence the term “blockchain”).

Cryptographic hashes have the special property that it is very difficult to predict in advance the input information which generates a particular cryptographic hash. Furthermore, even a small change in the input information will completely change the cryptographic hash in an unpredictable way. Thus, for example, if transaction (1) in block 1 were changed to “(1) A sends B £60”, the resulting Hash#1 would be completely different to the Hash#1 generated when transaction (1) is “(1) A sends B £50”. Furthermore, since the hash of each block (other than the first block) has the hash of the previous block as one of its inputs, changing any information in any one of the blocks requires the hash of that block and all subsequent blocks in the chain to be recalculated in order to maintain the chain. For example, if Hash#1 is different (due to changing transaction (1)), then Hash#2 (whose input includes Hash#1) will be different. If Hash#2 is different, then Hash#3 (whose input includes Hash #2) will be different, and so on.

Proof of work

The “proof of work” in this example is a number (06542444 for block 1, 43251572 for block 2, etc.) which is included in each block to give the hash of that block a particular characteristic. For example, if each hash takes the form of a 256 bit number (e.g. when the SHA256 cryptographic hash algorithm is used), the particular characteristic may be that the hash of each block begins with a certain number of consecutive zeros (e.g. 8 zeros, so that each hash begins with 00000000…).

Because a cryptographic hash is unpredictable, the only way to determine the proof of work number is to try adding different candidate proof of work numbers to the block (e.g. using a random number generator) and calculating the hash until the “right” proof of work number is found and the generated hash therefore has the desired characteristic.

This is a very computationally expensive process. Once the proof of work is known, however, it is very easy for any party to verify it simply by entering it as part of the input to the cryptographic hash algorithm used and ensuring that the generated hash has the desired characteristic.

Generating the blockchain of figure 2 thus includes the following steps:

1. A sends a digitally signed message containing transaction (1) to parties B, C and D. Each of B, C and D verify the digital signature of the message.
2. A, B, C and D each try to find the proof of work which gives Hash#1 of block 1 the desired characteristic (e.g. so it starts with 8 consecutive zeros). The proof of work is 06542444 in this case, but none of A, B, C or D know this until it is found by one of them as they all try as many different numbers as necessary. Finding the proof of work is known as “mining”. In some blockchains (e.g. Bitcoin), parties are incentivised to mine by awarding a financial prize to the first party which finds the proof of work of a given block.
3. Whoever finds the desired proof of work announces it to everyone else. Each party individually verifies that the announced proof of work gives Hash#1 of block 1 the desired characteristic (e.g. so it starts with 8 consecutive zeros). Each party then adds block 1 (with the verified proof of work number) to their individual copy of the blockchain.
4. Repeat for each subsequent transaction. The number of blocks in the blockchain thus gradually increases (i.e. the blockchain grows in length) as transactions are added to the blockchain.

Because it is very computationally expensive to calculate the proof of work of each new block, it becomes virtually impossible for a single party to add transactions to the blockchain without telling the other parties and to make that blockchain longer than the “legitimate” blockchain made up of transactions announced to all parties.

For example, for a fraudulent party A to convince party B that transaction (1) has been added to the “legitimate” blockchain without party A informing all the other parties of transaction (1), party A would have to generate a blockchain longer than that generated by all of the other parties working together.

Assuming that legitimate transactions are continuously being announced to all parties and that all parties are working on adding blocks to the block chain (and announcing when each new block, with its verifiable proof of work, is generated), as time goes by, it becomes virtually impossible for the blockchain generated by party A to be the longest blockchain. It is therefore safe to trust the longest blockchain as the legitimate blockchain.

The elegance of blockchain is therefore that each party can trust the distributed ledger represented by the longest blockchain even though there is no trusted central entity controlling the blockchain and there is no trust between individual parties. All that is required is to find the longest blockchain and verify it by verifying the digital signature of each transaction and verifying that the hash of each block is what it is supposed to be.

Digital signature and hash verification are computationally simple and can be done by any party with a copy of the blockchain. In particular, hash verification is easy once the proof of work has already been found. You simply put the relevant input information of the block concerned (including the transaction(s), proof of work and, for all blocks other than the first block, the hash of the previous block) into the cryptographic hash algorithm and check that (i) the hash which comes out is the same as the hash included in the block and (ii) the hash has the desired “proof of work” characteristic (e.g. starts with 8 consecutive zeros).

Application of the blockchain

Using blockchain to represent a distributed financial ledger is just one of many envisaged blockchain applications. A common theme amongst these potential applications is the tracking of commodities with unique identifying characteristics (e.g. original artwork, precious stones, delivery packages with a unique barcode or intellectual property rights) as they change ownership (e.g. during transactions or as they are passed through a global supply chain).

There is also scope for improvements to the core implementation of blockchain technology itself. For example, one problem is the huge amounts of electricity used by the computers doing the proof of work calculations in popular blockchains. Is there a robust alternative which uses less power?

It seems that both the applications and implementation of blockchain technology are likely to involve significant inventive activity in the coming years. But, will these inventions be patentable?

EPO Guidelines for Examination - computer implemented inventions

In November 2018, the European Patent Office re-wrote the Guidelines for Examination on how it handles Computer Implemented Inventions (CII). In this update to the guidelines, there were two important clarifications in respect of blockchain.

• Firstly, the EPO acknowledged that a distributed computing environment, such as that used in blockchain, is a CII. Given this, and the comments made at its “Patenting Blockchain” conference in December 2018, it is clear that the EPO treats a blockchain related invention as a CII. This is similar to the practice at other patent offices, most notably at CNIPA (formally SIPO). We shall look at how the EPO handles CII later.
• Secondly, a new allowable claim category directed towards a distributed computing environment, such as those using blockchain to maintain a distributed ledger, was introduced. On the face of it, this seems like a very positive change by indicating that the EPO is more willing to adapt its allowable claim types in view of current technology. However, whilst welcome, it is unlikely that this new type of claim will be particularly powerful.

The guidelines note that, in order to avoid a clarity objection, it may be necessary to refer to specific features of the different entities and to define how those features interact with one another. This means that in the likely event that the distributed computer network spans several jurisdictions, and involves several parties each being involved in carrying out different features of the distributed computer network, bringing an infringement action will be complicated.

Therefore, if possible, the claims should be drafted to ensure that only the operation of one of the entities is covered in a single claim. The claim to the distributed network should be included, but this, ideally, should not be the sole claim type in the application.

Computer implemented inventions

The examination of CII at the EPO has been consistent for many years. The challenge faced by many CII is that inventions must be concerned with, and solve, a technical problem.

In the context of blockchain related inventions, this can sometimes be difficult to show. For example, if the invention relates solely to the use of blockchain to track the movement of commodities (instead of a database) using a known characteristic of the commodity, this would be unlikely to be patentable at the EPO. This is because the difference between the invention and the prior art is solely the use of the blockchain (the technical features of which are already known) instead of a database.

However, if, for example, the invention relates to a previously unknown technical mechanism for generating a unique characteristic of the commodity and placing that characteristic on the blockchain, then that would likely be patentable. This is because the invention lies in the previously unknown technical mechanism for generating the unique characteristic. Similarly, if the invention relates to a more processor-efficient mechanism for generating a known unique characteristic of the commodity and placing that characteristic on the blockchain, then that too would likely be patentable. This is because the invention lies in the technical feature of the more processor-efficient mechanism for generating the known characteristic.

Blockchain and fintech innovation

One very active area of development for blockchain is in the financial sector. The use of blockchain in this area presents very specific problems for patenting these inventions. This is because methods of doing business, as such, are not seen as having technical character at the EPO. Changes to an underlying business or administrative method using blockchain are therefore likely to be seen as non-technical by the EPO (e.g. because they merely circumvent a particular technical problem rather than solving it) and will therefore be ignored when assessing inventive step. It is thus important when drafting applications in this area to concentrate on how the invention solves a technical problem, rather than describing and claiming changes to the underlying business or administrative method.

For example, if the invention relates to reducing the power consumption in the proof of work calculation by simply not performing certain steps of the calculation and accepting that the resultant proof of work is not as robust, then this would likely be seen as a change in the administrative process and would not contribute to inventive step. However, if the invention relates to reducing the power consumption in the proof of work calculation by using a new algorithm that provides an equally robust or better proof of work, then this would likely be seen as contributing to inventive step.

Conclusion

Blockchain has the potential to be a hugely disruptive technology. Where there is such disruption, it is common for patent offices to be slow to react to these changes. However, the EPO has been very proactive in giving guidance on the examination of applications in this area. If you have any questions about patenting blockchain inventions, please contact your usual D Young & Co adviser.