Most startups are created by devotees who don’t really want to know about protecting their intellectual property. Often, this leads to unfortunate consequences. Here, I would like to give an overview of the most common errors — and how to avoid them.
Peter created an ingenious algorithm; there are no known analogues to that whatsoever. He fiercely codes a prototype and begins the commercialisation in Russia. He puts up a website, uploads a demo, does some exhibitions. Gains momentum and taps into the US market. And here we go…
Fist scenario
Suddenly, an analogous solution is presented by a major company, who has both extensive promotional budgets and a solid outlook. In a losing fight, Pete’s startup sinks.
Second scenario
Peter’s business is on the rise, when expansively smiling employees of Evil Corp. come and inform him that he infringed upon a fivesome of their patents. Our Pete is certain that he uses none of their technologies. Unfortunately, the American court system happens to be on the dark side, and Pete is forced to prove his innocence at the cost of just a couple (or more) million US dollars in litigation expenses. Eventually he is at a knockdown and is bought out for peanuts by the Corp.
If only Peter had had a patenting strategy, had duly patented his solution in the relevant countries — he could have been golden.
Our Peter is having another incarnation with same algorithm. First thing, he takes a speaking opportunity at a conference and explains the solution to the world in detail. He is good at that, so even mid-level specialists in the field get a good understanding of how everything works. Then, an idea to patent the solution comes to his mind.
Pete is working on the patent application day-and-night. Files with the patent office. And gets a rejection. His solution has become prior art — which means there is no novelty to it, since everything in it is known from the conference proceedings. Now, best he can do is compete, on an equal basis with others, in implementing the public-domain solution. Epic fail.
File patent application first, then feel free to speak up. And there is no need to wait for a prototype — get a patent on the algorithm as soon as you have it.
Pete learned his lessons and with his brand-new idea he went after patents right at the prototyping stage. He wrote a claim of twenty features, in which he even fixed a bunch of math formulas. He filed an application and, pleased enough with himself, moved to taking over the world.
Cash is flowing, but some violators, of a Mickey Mouse Co., are detected doing something way too similar. Pete requires a cease-and-desist from them, to which he gets a reply with a list of those guys’ patents that are rather close to his, but are more streamlined with fewer, more generalised, features.
Where Pete claimed: “data is ranked using the bubble sorting”, the competitors kept to “data is sorted”. Basically, same idea; but Pete’s solution is protected only in case the bubble sorting is used, while the patent of Mickey Mouse Co. trumps that and protects regardless of the sorting algorithm used.
Formulate features through their function, implying the possibility of various implementations of the solution. Do not write too narrowly. Not “Read data from the file placed on an FTP server”, but “Obtain data placed on a remote server”. The latter covers more options — reading by HTTP, HTTPS, FTP, etc. — although gives less of a chance to have a patent granted.
So better off, hire professionals who have the experience of patenting and a background in your technical field. It’s their job to know where to broaden (but where to narrow) the claim — to be able, on the one hand, to actually obtain a patent, but on the other — to make it as wide as possible covering an array of practical implementations.
Let’s give Pete a break. Vlad, an experienced coder, creates a unique piece of software, which uses a few fascinating algorithms. Having heard something about IP (probably, from that pushy investor) he files a patent application, just to get that off his chest.
Competitors, being alerted by that, reverse-engineer the software and file a ream of patent applications — wide and narrow and what not. Fast forward, Vlad is presented with a lawsuit claiming an infringement of some patents. Only to realise that he basically infringes upon his own solution.
The court in this situation takes the competitors’ side — the First to File concept, used in most of the countries, gives priority to the first filer, regardless of who is the first inventor. (Disclaimer: there are many peculiarities related to priorities, which are outside of the scope of this article.)
Build a proper patent strategy. Use your budget wisely to patent as much as possible — both wide and narrow. Wide patens are good for getting some protection of the technology as a whole, while narrow ones work on the particular implementations.
“Is there any life beyond MKAD?”
Vas made an iOS demo app that immediately got trending. He knew about Pete’s negative experience, and so he duly filed the applications in Russia and the US. His mistake (of course there was one) was that he did not think through the protection in other countries. Soon, it became evident that the app is most popular in Europe — where the competitors did not leave Vas a chance in a leveled off competition.
It is normal that you do not know where to seek protection in the beginning. There is a PCT application for that. Having filed that, you will have 30 to 31 months to try and decide where exactly to seek protection (in comparison with the regular 12 months of convention priority under a regular national or regional procedure).
Consider patent landscaping. As a result of that, you will get an idea of what companies develop what technologies in what countries; what are the vectors of their efforts; as well as what are the potential licensees of your patents, and more.
Tim has been working for some months on the idea of a web-service. Finally, he put together some money and decided to stop working for The Man — to create his own startup. He put up a team; together they put up an alpha of the app. That’s where the money dried up.
Seeking investments was an obvious next step, which Tim did. The potential investors seemed mildly interested but kept asking for more and more details of the solution — becoming more and more interested in the process. Tim, having started allotting the profits in his head already, gave up more of the details that he should have.
In the middle of the negotiations, even before he could realise what has happened, Tim stumbled upon an analogous solution marketed abroad. That was when he realised that there was neither a patent nor a Non-Disclosure Agreement signed with the might-have-been investors.
First of all, get a patent.
If you have to disclose the solution before you got a patent, do so at your own risk, but at least make sure a proper NDA is in place. But, seriously, get a patent first.
If you did not get a patent yet, but are disclosing the solution, try and hedge the risks. Sometimes it is better not to get into too much of the details. Some blank spots may turn out not to be a problem for the investors but would make it much more complicated to exploit your solution. This may (or may not) give you enough time to finally get a patent.
Disclaimer: this article is for educational purposes only and shall not be deemed legal advice. Be advised to seek assistance from a professional, to be based on your particulars.
Nuts and bolts
Patent is a document of title to:
• the exclusive right to,
• authorship and
• priority of an —
— invention,
— utility model, or
— industrial design.
Invention, in its essence, is a technical solution expressed in the combination of essential features — that are sufficient for achieving the technical result.
Essential features are those affecting the achievability of the technical result — or, in other words, are in a cause-and-effect relation with the result.
Technical result is a trait of the technical effect, event, property, etc. that effectively appear in the exercise of the method, or in the production or use of the product, including in the use of the product produced directly by the method, of invention.
Patent claim defines the scope of protection of the patent, as it comprises the combination of essential features — that are sufficient for achieving the technical result.
Error 1 — The lack of protection
Peter created an ingenious algorithm; there are no known analogues to that whatsoever. He fiercely codes a prototype and begins the commercialisation in Russia. He puts up a website, uploads a demo, does some exhibitions. Gains momentum and taps into the US market. And here we go…
Fist scenario
Suddenly, an analogous solution is presented by a major company, who has both extensive promotional budgets and a solid outlook. In a losing fight, Pete’s startup sinks.
Second scenario
Peter’s business is on the rise, when expansively smiling employees of Evil Corp. come and inform him that he infringed upon a fivesome of their patents. Our Pete is certain that he uses none of their technologies. Unfortunately, the American court system happens to be on the dark side, and Pete is forced to prove his innocence at the cost of just a couple (or more) million US dollars in litigation expenses. Eventually he is at a knockdown and is bought out for peanuts by the Corp.
Solution
If only Peter had had a patenting strategy, had duly patented his solution in the relevant countries — he could have been golden.
Error 2 — Disclosure of the technical solution
Our Peter is having another incarnation with same algorithm. First thing, he takes a speaking opportunity at a conference and explains the solution to the world in detail. He is good at that, so even mid-level specialists in the field get a good understanding of how everything works. Then, an idea to patent the solution comes to his mind.
Pete is working on the patent application day-and-night. Files with the patent office. And gets a rejection. His solution has become prior art — which means there is no novelty to it, since everything in it is known from the conference proceedings. Now, best he can do is compete, on an equal basis with others, in implementing the public-domain solution. Epic fail.
Solution
File patent application first, then feel free to speak up. And there is no need to wait for a prototype — get a patent on the algorithm as soon as you have it.
Error 3 — Obtaining a narrow patent
Pete learned his lessons and with his brand-new idea he went after patents right at the prototyping stage. He wrote a claim of twenty features, in which he even fixed a bunch of math formulas. He filed an application and, pleased enough with himself, moved to taking over the world.
Cash is flowing, but some violators, of a Mickey Mouse Co., are detected doing something way too similar. Pete requires a cease-and-desist from them, to which he gets a reply with a list of those guys’ patents that are rather close to his, but are more streamlined with fewer, more generalised, features.
Where Pete claimed: “data is ranked using the bubble sorting”, the competitors kept to “data is sorted”. Basically, same idea; but Pete’s solution is protected only in case the bubble sorting is used, while the patent of Mickey Mouse Co. trumps that and protects regardless of the sorting algorithm used.
Solution
Formulate features through their function, implying the possibility of various implementations of the solution. Do not write too narrowly. Not “Read data from the file placed on an FTP server”, but “Obtain data placed on a remote server”. The latter covers more options — reading by HTTP, HTTPS, FTP, etc. — although gives less of a chance to have a patent granted.
So better off, hire professionals who have the experience of patenting and a background in your technical field. It’s their job to know where to broaden (but where to narrow) the claim — to be able, on the one hand, to actually obtain a patent, but on the other — to make it as wide as possible covering an array of practical implementations.
Error 4 — Many ideas, one patent
Let’s give Pete a break. Vlad, an experienced coder, creates a unique piece of software, which uses a few fascinating algorithms. Having heard something about IP (probably, from that pushy investor) he files a patent application, just to get that off his chest.
Competitors, being alerted by that, reverse-engineer the software and file a ream of patent applications — wide and narrow and what not. Fast forward, Vlad is presented with a lawsuit claiming an infringement of some patents. Only to realise that he basically infringes upon his own solution.
The court in this situation takes the competitors’ side — the First to File concept, used in most of the countries, gives priority to the first filer, regardless of who is the first inventor. (Disclaimer: there are many peculiarities related to priorities, which are outside of the scope of this article.)
Solution
Build a proper patent strategy. Use your budget wisely to patent as much as possible — both wide and narrow. Wide patens are good for getting some protection of the technology as a whole, while narrow ones work on the particular implementations.
Error 5 — Not knowing your market
“Is there any life beyond MKAD?”
Vas made an iOS demo app that immediately got trending. He knew about Pete’s negative experience, and so he duly filed the applications in Russia and the US. His mistake (of course there was one) was that he did not think through the protection in other countries. Soon, it became evident that the app is most popular in Europe — where the competitors did not leave Vas a chance in a leveled off competition.
Solution
It is normal that you do not know where to seek protection in the beginning. There is a PCT application for that. Having filed that, you will have 30 to 31 months to try and decide where exactly to seek protection (in comparison with the regular 12 months of convention priority under a regular national or regional procedure).
Consider patent landscaping. As a result of that, you will get an idea of what companies develop what technologies in what countries; what are the vectors of their efforts; as well as what are the potential licensees of your patents, and more.
Error 6 — Trusting but not checking
Tim has been working for some months on the idea of a web-service. Finally, he put together some money and decided to stop working for The Man — to create his own startup. He put up a team; together they put up an alpha of the app. That’s where the money dried up.
Seeking investments was an obvious next step, which Tim did. The potential investors seemed mildly interested but kept asking for more and more details of the solution — becoming more and more interested in the process. Tim, having started allotting the profits in his head already, gave up more of the details that he should have.
In the middle of the negotiations, even before he could realise what has happened, Tim stumbled upon an analogous solution marketed abroad. That was when he realised that there was neither a patent nor a Non-Disclosure Agreement signed with the might-have-been investors.
Solution
First of all, get a patent.
If you have to disclose the solution before you got a patent, do so at your own risk, but at least make sure a proper NDA is in place. But, seriously, get a patent first.
If you did not get a patent yet, but are disclosing the solution, try and hedge the risks. Sometimes it is better not to get into too much of the details. Some blank spots may turn out not to be a problem for the investors but would make it much more complicated to exploit your solution. This may (or may not) give you enough time to finally get a patent.
A (non-patentable) algorithm
1. Invent
2. Prototype — simultaneously with determining patentable technical solutions
3. Research the market; maybe get patent landscaping done; consider making this step 2 instead of 3 (depending on your situation)
4. Fix a patenting strategy
5. File patent applications
6. Commercialise
Disclaimer: this article is for educational purposes only and shall not be deemed legal advice. Be advised to seek assistance from a professional, to be based on your particulars.
