Blockchain Patents

Say you’ve got a great idea to use “blockchain for [insert literally any problem domain]”.First off, congratulations! That sounds cool. Now you think to yourself, “I should patent that!” Maybe.

Before you go through the long and costly process of seeking patent protection there are some questions you should ask yourself, or your attorney should ask you.

Do you really need a blockchain?

This is the most important question, and one that requires serious introspection. Are you pursuing a blockchain technology solution because you are trying to capitalize on a hot new trend? Do you just need a new data storage solution? Have you really hammered out the pros and cons of using blockchain technology? Do you want to build your own blockchain, or use a public blockchain or some private blockchain service?

Your answer to these questions will of course depend on your goals, constraints, and the data you are dealing with. If you are convinced that you do want to pursue a blockchain technology solution to your problem you should have answers to at least the following questions.

What data do you hope to store using blockchain technology?

It doesn’t make sense to throw any old data in a blockchain. I mean, you certainly can, but that would be wasteful. Typically, you want to put “significant” data in a blockchain. For example, data that might be usefully stored on a blockchain may be mission critical data that you don’t want to lose, however, then the question becomes is access to said data time-sensitive? If the answer is yes then a blockchain solution may not be a good fit.

Have you considered any privacy restrictions on the data you are dealing with? For example, is the data personally identifiable information, such as healthcare data? If it’s healthcare data, have you properly walked through permission controls that need to be put into place? “We’re just storing a hash of the data!” you say, and yes that’s great, but are you really comfortable with that? Similarly, how will the data be entered into the system? Is the data going in solely under human direction? Is there some type of machine-machine communication going on?

Good candidate datasets for storage in a blockchain solution are “shared datasets that are shared amongst parties that do not fully trust each other.” That is, parties that may be incentivized to change data to the detriment of other parties involved in the network. Remember, blockchains are tamper-evident and so can cut down on funny business by participants that don’t have a majority of the computing power necessary to overrun the blockchain the data is stored in.

How are transactions handled?

Transaction verification should be trivial, but if you are not dealing with public blockchains (e.g. Ethereum, Bitcoin) then you may need/want additional verification steps. If so, what are the additional steps taken as part of the verification process? Even if your idea involves the use of public blockchains you may want to include additional transaction verification steps that occur prior to interfacing with the public blockchain.

Similarly, how is consensus handled in your blockchain solution? Inventing a new consensus algorithm is probably not a good idea. It’s better to use an existing consensus mechanism. This calculus changes if your blockchain solution does not make use of tokens that are native to your new fangled blockchain network. If you are not using tokens (e.g. bitcoin, ether) as part of your solution, why are you trying to use blockchain technology again?

Does this interface with legacy systems?

How do you envision your blockchain solution fitting into your existing business model? The blockchain solution will either interface with legacy systems or seek to replace legacy systems. Both paths have their own pitfalls, and their own patent considerations.

Along these lines, is your blockchain solution going to be solely internal to your business, client facing, or a combination of both? You need to consider exactly how your use of blockchain technology interacts with these internal systems and external systems.

Who is allowed to participate?

A blockchain network is made up of all sorts of different participants. Have you figured out who can participate in your blockchain network and how? Do you use an existing blockchain network, such as Bitcoin or Ethereum? If so, have you considered privacy requirements for your data, and how they might be met on those networks?

If you are designing your own blockchain network, are there checks performed prior to participation in the network? What would those checks look like? Accordingly, do you have a validation process in place to validate information used as part of any checks on participation? This is less of an issue if you are spinning up some sort of permissioned blockchain where there is a certain level of trust afforded each participant.

Conclusion

Blockchain technology is not a panacea for every problem you face. In fact, blockchain technology is really best suited to situations where you have participants on a network that don’t fully trust each other, want to update valuable data, and don’t fully trust the network. If that is not your situation, you need to think about at least the questions posed above, but probably many more.