AI has changed the way people write.
It has also changed the way people draft patents.
That is not always a good thing.
If you are a founder, engineer, or startup builder, AI can feel like a huge win. You can move faster. You can turn rough notes into polished text. You can take technical ideas and organize them in minutes instead of days. For a busy startup team, that feels powerful.
But there is a trap hidden inside that speed.
AI is very good at creating text that looks complete. It is very good at sounding formal. It is very good at producing “patent-like” language. What it is not always good at is capturing the real invention in a way that gives you strong protection later.
That is where boilerplate enters the picture.
Boilerplate is the kind of writing that fills space without adding real value. It sounds official. It sounds broad. It sounds polished. But when you slow down and ask what the text is actually saying, the answer is often “not much.”
That is dangerous in a patent spec.
A patent spec is not just paperwork. It is not just a long explanation that gets filed away somewhere. It is the written backbone of your patent. It is where you describe what you built, how it works, why it works, and what other versions of it could look like. If that backbone is weak, your patent can end up weaker than it should be, no matter how impressive the draft looks on first read.
This matters even more for startups.
Most startups do not have time to waste. They do not want a slow, painful patent process. They do not want to spend months going back and forth. They also do not want to file something shallow and regret it later. They want speed, but they also want confidence.
That is why avoiding boilerplate in AI-generated patent specs matters so much right now.
If you use AI the right way, it can help a lot. If you use it the wrong way, it can bury your invention under generic words.
The good news is that this problem is fixable.
You do not need to reject AI. You do not need to go back to an old, slow process either. You just need a better way to capture the invention before AI turns it into text, and a better way to review that text before it gets filed.
That is exactly the kind of problem PowerPatent is built to solve. It helps founders and technical teams turn real inventions into real patent filings using smart software plus real attorney oversight, so you can move fast without ending up with a generic draft that misses the point. You can see how it works here: https://powerpatent.com/how-it-works
Why boilerplate is such a serious patent problem
A lot of weak writing is annoying.
Weak patent writing is expensive.
That is the difference.
If a blog post is vague, you can rewrite it. If a sales email is generic, you can send a better one. If a product page is thin, you can improve it later. But a patent filing is different. Once filed, it becomes the foundation for what you may later claim and how you may later argue that your invention was fully described.
That is why boilerplate is not just a style issue. It is a support issue.
When a patent spec is full of boilerplate, it often means the filing is not doing enough of the work it needs to do. It may describe a general computer environment without explaining the inventive part.
It may describe a result without describing the mechanism that creates that result. It may sound broad while actually lacking the detail needed to support meaningful breadth.
In plain terms, boilerplate makes a patent look stronger than it is.
That is one reason it is so risky. It creates false confidence.
A founder reads the draft and sees page after page of formal language. The document has headings. It has system sections. It has method sections.
It has references to embodiments. It sounds polished. It sounds like a patent. So the team feels relieved. They think the hard part is done.
But if the draft mostly says things like “one or more modules may process data to generate output,” that relief is built on thin ice.
A strong patent spec should not just announce that a system exists and performs functions. It should explain the invention in a way that shows real technical possession.
It should create a clear path from problem to solution. It should describe concrete implementations and also preserve room for broader framing. It should include detail that later claims can lean on.
Boilerplate gets in the way of all of that.
It hides the real logic of the invention. It crowds out detail. It replaces the sharp edges of the design with smooth, generic language that could fit almost anything.
And when that happens, the spec stops sounding like your invention and starts sounding like a template with your product area pasted into it.
That is not what you want protecting your company’s edge.
Why AI creates boilerplate so easily
To understand how to avoid boilerplate, it helps to understand why AI produces it in the first place.
The answer is not that AI is lazy.
The answer is that AI is predictive.
It generates text based on patterns. When you ask it to draft something that sounds like a patent, it reaches for patterns that look like patent writing.
And public patent writing is full of repeated structures, stock phrases, high-level abstractions, old template language, and generic transitions.
So the first reason AI produces boilerplate is simple. It is imitating what it has seen.
The second reason is that most patent prompts are too vague.
A founder might say, “Write a patent application for an AI system that reduces fraud in payments,” or “Draft a patent spec for a recommendation engine that improves conversion.” Those are real product goals, but they are not enough for strong drafting.
The AI does not know the real architecture, the ranking logic, the decision thresholds, the feedback model, the data sources, the training schedule, the fallback behavior, or the operational constraints. It has to fill those gaps somehow.
Boilerplate is the filler it reaches for.
The third reason is that users often ask AI to be broad before they have earned that breadth.
This happens all the time. A founder is rightly worried about being too narrow. They do not want the patent to cover only one tiny version of the system. So they tell the AI to make it broad. The model responds with vague language. The result feels expansive, but it is often just less specific.
That is not true breadth. It is abstraction without support.
The fourth reason is that AI is often used in place of invention intake rather than after invention intake.
That point matters a lot.
If the real invention has not yet been clearly captured in human terms, AI has nothing solid to work from. It can still create a long document, but the document will reflect the quality of the input. Thin input creates thin support dressed up in formal language.
The fifth reason is that many people reviewing AI-generated drafts do not yet know what to look for. They spot grammar issues. They spot obvious factual errors. They may compare the draft loosely against the product.
But they do not always ask the harder questions. Does this paragraph support a future claim? Does this sentence describe the mechanism or just restate the function? Does this section sound broad because it captures the true concept, or generic because it is hiding a lack of detail?
Until teams ask those questions, boilerplate will keep slipping through.
Why founders are especially exposed to this risk
Founders are not careless.
They are overloaded.
That is an important distinction.
The average technical founder is already juggling product, roadmap, customer feedback, recruiting, fundraising, hiring, planning, engineering issues, and endless decisions. Even founders who care deeply about patents often do not have the time or energy to become experts in patent drafting. So when AI offers speed, it feels like relief.
That relief is real.
The trouble is that the same conditions that make founders love speed also make founders more vulnerable to boilerplate.
For one thing, founders know the product too well. They understand the system inside out. They know which technical choices matter. They know why the architecture is shaped the way it is.
They know what tradeoffs the team made. Because they know all that, they may read a vague paragraph and mentally fill in the missing meaning without realizing the words on the page do not actually say it.
That is a big problem.
The draft feels more specific than it is because the founder is adding the missing specificity in their own head.
Founders also tend to talk in results. They say things like “we cut latency,” “we reduce false positives,” “we improve ranking,” “we increase privacy,” “we improve grounding,” or “we lower compute cost.” Those are useful outcomes, but they are not the same as an invention description. A patent spec needs the technical path, not just the destination.
Founders are also under pressure to stay broad. That pressure is understandable. Nobody wants to describe a system so narrowly that a competitor can work around it with a small change.
But that can lead teams to remove helpful detail too early. Once the helpful detail is gone, AI fills the empty space with generic language, and the filing loses the very support that would have made broader protection possible.
Then there is simple time pressure. Many startups treat patent filing like something that has to fit into the cracks between other urgent work. That makes it easier to accept a polished AI draft without pushing deeply enough on whether the substance is there.
This is why the right workflow matters so much. The process has to help founders extract invention detail from the work they are already doing, without making the whole thing feel like a second job.
That is one reason so many startup teams are drawn to PowerPatent. It is designed around the way real founders and engineers work. Instead of forcing them into a long, painful process, it helps capture actual invention detail quickly and turn it into stronger patent drafts with real attorney review where it matters most. Explore it here: https://powerpatent.com/how-it-works
What boilerplate really looks like in practice
Boilerplate does not always look obvious.
Some of it is easy to spot. Some of it hides inside polished paragraphs that sound useful until you stop and ask what they are actually contributing.
One common form is empty system language.
A draft says the system includes a processor, a memory, a storage unit, a communication interface, and one or more modules configured to perform one or more operations. This is not always wrong. Some system context belongs in many patent specs. But if the draft spends too much time describing generic computer parts instead of the real invention, that is a warning sign.
Another form is empty process language.
The draft explains that data is received, processed, analyzed, transformed, stored, and presented. Again, those verbs are not bad by themselves. But if the draft never explains what kind of data, how the transformation works, why the analysis matters, or what specific decision logic is involved, then the writing is just cycling through generic actions.
Another form is abstract benefit language.
The system allegedly improves speed, accuracy, security, efficiency, scalability, reliability, privacy, or user experience. But the draft never connects those outcomes to the underlying design choices. It says the invention is better without showing what makes it better.
Another form is repeated paraphrase.
AI does this a lot. It introduces a concept once, then repeats it in slightly different wording across later sections. The repetition creates the feeling of depth without adding real support. A “decision engine” becomes an “analysis module,” then an “inference component,” then a “processing subsystem.” The language changes. The substance does not.
Another form is fake flexibility.
The draft says “in some embodiments” so often that it stops saying anything definite. Real optionality has value. But endless hedging can drain the draft of clear embodiment support. A patent spec needs room for variants, yes, but it also needs clear examples of how the invention actually works.
Another form is borrowed framing.
AI may translate a very specific invention into a broad technical category that sounds close enough but loses the important shape of the system. A custom model routing design becomes a “machine learning platform.” A real-time graph update method becomes a “data processing system.” A trust-aware retrieval method becomes an “information access framework.” These labels are not always false, but when they replace the real explanation, they become a form of boilerplate.
The deeper pattern is simple.
Boilerplate often takes a real thing and smooths it into a generic thing.
That smoothing is the problem.
The difference between broad and generic
This is one of the most important ideas in all of patent drafting.
Broad is not generic.
They are not the same. They do not do the same work. They should not be treated the same.
Broad language is useful because it gives room. It helps avoid locking the patent to one tiny implementation. It allows for variations. It captures the larger idea behind a specific embodiment.
Generic language does something else. It blurs the invention until the larger idea disappears too.
The easiest way to see the difference is to compare them.
Suppose your invention uses confidence-based routing to decide whether an AI output should go directly to a user, go through a validation layer, or trigger a request for more context.
A broad description might say that the system routes candidate outputs according to confidence conditions, validation requirements, or context sufficiency criteria. That is broader than the exact code path, but it still preserves the shape of the invention.
A generic description might say that the system processes input using an AI model and provides output based on analysis results. That could describe nearly any AI application. It does not preserve the shape of your invention at all.
That is the core difference.
Broad language keeps the technical identity of the invention.
Generic language removes it.
This matters because many founders mistakenly think any move away from narrow product detail is a move toward strength. It is not. If the move strips out the mechanism, the relationships, the decision logic, or the design principle, it may be weakening the patent rather than strengthening it.
True breadth comes after clear specifics. It grows out of them. It is supported by them. It does not replace them.
That is why a strong patent drafter often starts with the most concrete embodiment, then steps outward in layers. First the real implementation, then alternatives, then the broader pattern shared across those alternatives. That approach produces supported breadth.
AI often tries to start at the top. It wants the broad abstraction right away. That is one big reason boilerplate appears so quickly in AI-generated patent specs.
Why detail gives you more room, not less
A lot of founders worry that if they include real detail, they will narrow the patent too much.
This sounds reasonable at first, but most of the time the opposite is closer to the truth.
Detail creates support.
Support creates options.
Options create flexibility.
If your spec contains only vague statements, you may think you are staying broad. But what you often end up with is less usable support, fewer claim paths, and a weaker foundation for future argument.
By contrast, when your spec includes real embodiments, useful examples, and thoughtful alternatives, you create a much stronger base.
Imagine a founder who says only that their system “uses machine learning to optimize resource allocation.” That sounds broad. But it tells you very little. Now imagine a spec that explains one embodiment using demand predictions, queue state, and constraint weighting to allocate compute across tasks; another embodiment that uses cost thresholds and priority classes; another that applies the same principle across edge and cloud resources; and then a broader explanation of the shared concept behind all those versions.
Which spec creates more room later?
The second one, almost always.
That is because breadth is strongest when it is supported by detailed embodiments and meaningful variants.
This is where many AI-generated specs fail. They rush toward generality before the detail is built. The result feels broad but is actually thin.
A good patent spec should not be one narrow story. It should be a family of related stories built around the same inventive idea. That family is what gives you room. Boilerplate does not create that family. It just hides the fact that it is missing.
Start with the invention story, not the document shell
One of the best ways to avoid boilerplate is also one of the simplest.
Do not begin by asking AI to write a patent.
Begin by explaining the invention.
That may sound obvious, but many teams skip it. They start with the patent shell. They ask for a background section, a summary section, a detailed description, maybe claims. The model then fills those boxes with familiar language.
That is how the draft becomes shaped by the template instead of by the invention.
A better approach is to start with a plain explanation of what changed.
What problem existed before your system?
What was unsatisfying about earlier approaches?
What did your team do differently?
How does the new approach operate?
Why does it work better?
What are the parts that matter most?
What changes are optional and what changes are central?
What other versions still follow the same idea?
Those questions are more valuable than any section heading.
When answered clearly, they give the draft a backbone. They create a real invention story. Once that story exists, the formal patent structure becomes easier to build around it.
A strong invention story usually has a clean arc.
There was a real problem in a real context.
Older approaches had a real limit.
Your team introduced a real design change.
That change caused a real technical effect.
There are other ways to implement the same underlying idea.
That arc gives the patent spec life.
Without it, the draft often becomes a pile of general statements stitched together by stock transitions.
Why plain language should come first
Many people assume patent drafting should start with formal language.
That is usually a mistake.
Plain language should come first because plain language forces clarity. It makes it harder to hide confusion behind big words or abstract structure. If you cannot explain the invention in simple terms to a smart engineer outside your company, you probably do not yet have a strong base for formal drafting.
This is especially important when AI is involved.
If you feed AI vague formal prompts, it will usually respond with vague formal text. If you feed it a clear, grounded explanation of the invention in simple words, it has a much better chance of producing something useful.
Plain language helps surface the missing pieces.
It reveals where the flow is unclear.
It reveals where the mechanism is still fuzzy.
It reveals where the team is talking only about benefits instead of describing the design.
It reveals where an important technical decision still has not been fully articulated.
That is why one of the smartest moves a founder can make is to write or speak the invention in plain words before asking for formal drafting help.
What does the system do?
What was hard before?
What exact change did the team make?
Where does the decision happen?
What signal or rule matters?
What conditions change the path?
What happens when the system is uncertain?
Those kinds of plain questions lead to much better patent drafting than broad requests for “a strong and comprehensive patent application.”
Formal tone can come later.
Clarity has to come first.
How examples rescue a weak draft
Examples are one of the best antidotes to boilerplate.
When a draft stays at the abstract level, boilerplate thrives. When a draft drops into real examples, the invention gets harder to fake.
A good example makes the technical logic visible.
If your invention is about a retrieval system for enterprise AI, an example might show what happens when a user asks a question, how the system identifies accessible repositories, how it expands the query, how it ranks candidate passages by trust and relevance, and how the selected context is handed to a generation stage. That example does a lot of work. It reveals the mechanism. It clarifies the role of each stage. It helps show why the design is not just a generic search system.
If your invention is about automated validation of generated code, an example might show how the system proposes code, checks repository context, runs policy filters, evaluates dependency constraints, and blocks or routes the output based on confidence and permission status. That is far stronger than simply saying the system “uses AI to generate and validate code.”
If your invention is about a multi-stage fraud screening process, an example might show how one transaction is scored, how uncertainty leads to a secondary feature extraction stage, how historical graph relationships affect the score, and how the final result changes based on analyst feedback stored from prior reviews. Now the invention has shape.
Examples help in another way too. They expose gaps. Once you try to write a real example, you discover what you have not yet explained. Maybe the ranking step is too vague. Maybe the threshold logic is still unclear. Maybe the feedback loop is not fully described. That is useful. It tells you where the spec needs more work.
Many teams avoid examples because they fear narrowness. In practice, strong examples usually make the patent stronger because they give broader language something real to rest on.
Why figures are powerful anti-boilerplate tools
A figure forces the invention to become visible.
That is a good thing.
When the draft is too generic, a real figure often reveals it right away. You cannot hide behind broad prose as easily when you have to show the system, the flow, the stages, or the interaction points.
This is especially valuable for software and AI inventions, where teams often rely too heavily on text.
A good figure can show where data enters the system, where it is transformed, where decisions occur, how ranking works, when fallback paths are triggered, how feedback changes later behavior, or how different compute locations divide the work.
A weak figure usually does the opposite. It gives you a few blank boxes labeled server, model, database, and user interface. That kind of figure may satisfy form, but it does very little to deepen the spec.
A strong figure helps in several ways at once.
It forces specificity.
It clarifies relationships.
It reveals missing steps.
It helps align the written description.
It creates anchors for later claim support.
It also makes it easier for reviewers to see where the invention really lives. Sometimes the inventive step is architectural. Sometimes it is procedural. Sometimes it is about coordination between components. Sometimes it is about how the system handles uncertainty or state change over time. Figures help separate those possibilities and make the drafting more honest.
When a team leans into strong figures, the writing usually improves too. The figures place helpful pressure on the prose. The text has to explain what the figures actually show. That reduces the space where boilerplate can hide.
The hidden cost of “patent-sounding” language
A lot of founders think the safest way to draft a patent is to make it sound as patent-like as possible.
That instinct causes a lot of trouble.
Patent documents do need a formal tone. They need consistency. They need care. But formal is not the same as bloated. Formal is not the same as abstract. Formal is not the same as hard to understand.
When people try to make a draft “sound like a patent,” they often end up adding padding. Simple statements become longer. Clear explanations become vague. Obvious points get wrapped in unnecessary phrases. The draft gains a costume of seriousness while losing some of its real force.
AI is especially likely to do this because formal style is easy for it to imitate. It can mimic public patent language very quickly. That is one reason AI-generated specs often feel polished. They have the rhythm of official writing. They use stock transitions. They sound serious.
But sounding serious is not enough.
A good patent spec should still be readable. It should let a technical reader follow the invention. It should make the important relationships and flows easy to see. It should explain the mechanism without making the reader fight through clouds of empty wording.
Boilerplate loves murky language because murky language hides weak support.
Clear writing does the opposite. It exposes weaknesses and forces them to be fixed.
That is why the best patent writing often feels cleaner, not heavier. It is formal, but it is not stuffed. It is precise, but it is not trying to impress with ceremony.
If a paragraph feels official but slippery, that is a sign to slow down.
Why the “why” behind the system matters
Many weak patent drafts explain what the system does but not why it was designed that way.
That missing “why” is often where the invention really becomes meaningful.
Suppose a system routes some model outputs through a validation layer and others directly to a user. A weak draft might just say the system can validate outputs before providing them. That is function. A stronger draft might explain that direct delivery is used for outputs with high confidence and low policy risk, while secondary validation is used when uncertainty, conflict, or missing context is detected. Now the design reason is visible.
Or suppose a system stores only selected memory fragments for future use. A weak draft might say the system stores context. A stronger draft might explain that the system scores candidate context segments using recency, relevance, and source trust to avoid wasting prompt space on low-value content. Again, the design reason makes the invention more concrete.
Or suppose a system splits compute between edge and cloud. A weak draft might say processing may occur locally or remotely. A stronger draft might explain that sensitive input features are processed locally to preserve privacy, while aggregated or reduced representations are sent remotely for heavier analysis. The mechanism and reason now show up together.
The “why” helps in several ways.
It links the problem to the solution.
It reveals the design pressure that shaped the invention.
It makes benefits more believable because the path to those benefits is visible.
It helps broaden the description later because once you know why a choice was made, you can more easily identify alternate ways to serve the same purpose.
AI often loses this layer because it summarizes what happens without preserving the reasoning behind it. That is one more reason boilerplate shows up in AI-generated specs. The design logic gets flattened.
When reviewing a draft, keep asking: why is this built this way?
If the answer matters, put it in the spec.
How boilerplate weakens claim strategy later
Founders do not always think about claims while reviewing the spec.
That is understandable, but the connection matters.
A patent spec is not valuable only because it describes the invention. It is valuable because it gives future claims somewhere to stand. When the spec is full of boilerplate, that support can become shaky.
Claims need a foundation. They need language in the spec that supports how the invention may later be defined, varied, and defended. If the draft contains only broad functional language, it may be harder to draft strong claims that survive scrutiny or that clearly distinguish the invention from known approaches.
This is where generic drafting can quietly cause damage.
A founder might think, “The claims will handle the details later.” But the claims do not live on their own. They rely on the detailed description. If the detailed description is hollow, the claims may be forced into narrower or less effective forms than the team hoped.
Boilerplate can also make it harder to decide what the real claim angles should be. When the invention story is blurred, everything starts to look like generic computer implementation. That makes it harder to see whether the strongest claim path is in system architecture, data handling, model orchestration, ranking logic, validation flow, state management, deployment structure, or some combination of those.
A strong spec helps reveal those paths.
A boilerplate-heavy spec hides them.
At first, boilerplate can seem harmless.
A team may think, “We can always tighten the claims later.”
That idea sounds practical, but it often leads businesses into a weak position. Claims do not appear out of nowhere. They need support from the spec. They need language, examples, structures, flows, and variations that were actually captured when the application was filed. If those pieces are thin, generic, or missing, the business may discover too late that its best claim angles were never properly built into the foundation.
That is where boilerplate does its real damage.
It does not just make the draft less interesting to read. It limits your future options in ways that can affect product protection, licensing value, investor confidence, and even how confidently your company can plan around its own technology.
Boilerplate makes your future claim set less flexible
A strong patent spec gives a business room to move.
It allows you to pursue one kind of claim today and a different kind later if the market shifts, if competitors behave differently than expected, or if the examiner pushes the claims in a new direction. That flexibility is a major business advantage.
Boilerplate reduces that flexibility because it usually captures only surface-level function. It may say the system processes data, generates outputs, or uses machine learning to improve results. But if it does not explain the deeper mechanics, you may lose the ability to pivot your claim strategy later.
For example, maybe your company initially thinks the strongest claim angle is a workflow method. Later, after watching competitors, you realize the better angle is the way your system manages state across sessions, or the way your architecture routes tasks under certain conditions, or the way you rank outputs before action is taken. If your spec is filled with boilerplate and never clearly described those details, your room to pivot may be much smaller than you hoped.
That is why businesses should think beyond the first claim draft.
The real question is not just, “Can we get claims from this application?”
The better question is, “Will this application still give us strategic options one year from now, after the market, product, and competitor behavior become clearer?”
That is a much more useful test.
Weak support can force the company into defensive claiming
When a spec is thin, the claim strategy often becomes reactive.
Instead of choosing claims that best fit the business, the company ends up choosing claims that the spec can barely support. That is not the same thing.
This is where boilerplate quietly changes the game. A business may want claims that target its strongest commercial advantage, but if the draft did not clearly capture that advantage in technical terms, the legal strategy may have to retreat into safer, narrower, less valuable territory.
That can create a serious mismatch.
Your product may win in the market because of a specific architecture choice, control flow, ranking method, training arrangement, deployment design, or validation step. But if the application mostly describes generic system functions, the claims may drift toward bland coverage that does not track the real source of product strength.
For a business, that is costly.
It means the patent may end up protecting what is easiest to describe, not what is most valuable to defend.
A better approach is to pressure-test the draft before filing by asking a business-first question: if a direct competitor copied the most commercially meaningful part of our system, does the spec clearly support claims aimed at that part?
If the honest answer is unclear, more substance needs to go into the application.
Boilerplate can separate legal strategy from product strategy
One of the biggest mistakes startups make is treating patents like a separate legal exercise.
They are not.
Good claim strategy should line up with product strategy. It should reflect how the company creates value, where the technical moat sits, how competitors are likely to copy, and what pieces of the system matter most for revenue or leverage.
Boilerplate breaks that alignment.
Why? Because boilerplate tends to describe inventions in broad, flattened language that no longer matches the real shape of the product. Once that happens, the patent stops tracking the business closely. The legal story and the product story start drifting apart.
That is dangerous for growing companies.
A leadership team may believe it has protected the heart of the product, while the application actually supports only a generalized version of the system. Later, when the company tries to raise money, license the patent, assert it, or expand the family, it may discover that the filing does not line up with the actual business moat.
This is why founders should review patent drafts not only as inventors, but as operators.
Ask where the company really wins.
Ask what technical choice creates customer value.
Ask what a competitor would most likely copy first.
Ask what system behavior would be hardest to replace without recreating your advantage.
Then check whether the spec supports claims to those areas with real detail.
That exercise is far more strategic than simply asking whether the application “covers the product.”
Generic drafting can make continuation strategy weaker
Many businesses file with the hope that future continuation filings will help them adapt over time.
That can be a smart move.
A continuation strategy gives a company room to pursue different claim sets as products evolve, markets mature, and competitor behavior becomes easier to observe. For startups in fast-moving areas, that flexibility can be very valuable.
But continuations are only as strong as the original disclosure.
If the first filing is heavy on boilerplate, future continuation options may look broader on paper than they really are in practice. The company may assume it can later pursue claims aimed at different layers of the system, but when the time comes, it may find that the original application did not clearly support those claim directions.
That is a painful surprise.
Businesses should treat the first filing as the root system for future growth. If the roots are shallow, the branches will always be limited.
A useful internal practice is to map continuation goals before the first filing goes out. Even if you do not plan to draft those future claims right away, list the kinds of directions you may want later.
For example, you may want one future branch aimed at system architecture, another at data flow, another at ranking logic, another at user-specific adaptation, and another at deployment control. Then review the spec with those future paths in mind.
If those branches are not well supported in the disclosure, add more detail before filing.
This is one of the smartest ways businesses can prevent regret later.
Boilerplate weakens your position against design-arounds
A weak claim strategy does not always fail because the claim is rejected.
Sometimes it fails because a competitor can step around it too easily.
Boilerplate increases that risk.
When a spec is generic, the claims that grow out of it often become either too abstract to hold much strategic force or too narrow in the wrong places.
That can leave room for a competitor to change one visible feature, move one function, split one component, reorder one step, or swap one implementation path and avoid the claim while still copying the business value.
This matters a lot in software and AI.
Competitors do not need to clone your exact code. They only need to recreate the same business outcome in a technically different-looking form.
If your application did not describe the invention with enough depth and range, you may have fewer ways to draft around those design-around moves.
This is why a smart claim strategy needs support for substitutes, equivalents, alternate flows, and different deployment models.
Not because you want to bloat the draft, but because you want to make copying harder.
A practical business exercise is to run a design-around workshop before filing.
Take the core invention and ask three questions.
How would a competitor copy this in the cheapest possible way?
How would a well-funded competitor copy this in a more sophisticated way?
Which parts could they swap, split, or relocate while keeping the same market effect?
Then look at the spec. If those likely workarounds are not addressed through meaningful alternative embodiments or broader technical framing, you have a gap worth fixing.
Boilerplate can reduce licensing and diligence value
A patent is not only for litigation.
It can affect licensing talks, partnerships, diligence reviews, and investor perception. In all of those settings, people look for signs that the company actually captured something real and defensible.
Boilerplate can hurt that impression.
Sophisticated buyers, partners, and investors may not use the word boilerplate, but they can often feel when a filing is shallow.
They can see when the application sounds generic. They can see when the invention description drifts into stock language. They can see when the claims look disconnected from the technical depth of the business.
That weakens leverage.
A patent portfolio becomes more valuable when it appears closely tied to the company’s actual moat. It becomes more credible when the claims seem capable of adapting to product growth and competitor behavior. Boilerplate works against that because it makes the filing feel interchangeable.
Businesses should think of each application as part of a story told to future outsiders.
Does the filing show that your team solved a hard problem in a concrete way?
Does it look like a real record of engineering insight?
Does it suggest that the company can keep building a thoughtful patent family around the same core platform?
That story matters more than many founders realize.
The strongest claim strategy starts with commercial pressure points
Many companies review patent specs by asking whether the invention is technically accurate.
That matters, but it is not enough.
A stronger business habit is to review the spec against commercial pressure points.
Where does the company make money?
What feature closes deals?
What technical layer keeps customers from switching?
What part of the system would hurt most if copied?
What integration or workflow creates the deepest lock-in?
What process or architecture lowers cost in a way competitors would love to match?
When you review the draft through those questions, claim strategy becomes much sharper. You stop thinking only in abstract legal categories and start thinking in protection priorities.
Boilerplate is dangerous because it smooths over those pressure points. It describes the whole system in generic terms rather than putting weight on the parts that create real business leverage.
That is why one of the best pre-filing exercises is to mark the top two or three commercial pressure points in the product and make sure the spec describes each one in technical detail, with examples and variations.
This creates a much stronger bridge between patent strategy and company strategy.
Actionable ways to strengthen claim strategy before filing
Businesses do not need to guess here. There are practical steps that make a real difference.
Build a “future claims” memo before the draft is final
Before filing, create a short internal memo listing the claim angles you may want not only now, but later. Include direct coverage, fallback coverage, competitor-focused coverage, and continuation ideas. Then compare that memo against the actual spec. If the draft does not clearly support those paths, fix the draft while you still can.
Review the spec through a competitor lens
Do not only ask what your invention is. Ask how it would likely be copied. Then make sure the disclosure captures not just your current version, but the variants a competitor might use to recreate the value.
Mark the business-critical layer of the system
Many products have one layer that matters most. It could be orchestration, decision logic, memory handling, validation, permissions-aware retrieval, distributed deployment, or something else. Highlight that layer and make sure the spec goes deeper there than anywhere else. The best claim strategy often starts where the business moat is thickest.
Separate “nice product detail” from “claim-support detail”
Not all technical detail is equally useful. Some details are product background. Some are essential support for future claims. During review, label which details actually create claim options later. Those are the details to protect carefully and expand with variations.
Ask what you would regret not being able to claim
This is a simple but powerful question. If the application were filed today, and one year from now you discovered that a competitor copied a certain aspect of the system, what would you most regret not being able to claim? That answer often reveals where the draft still needs more support.
A stronger spec creates business leverage, not just legal language
The best businesses do not think about patent claims as isolated sentences.
They think about them as tools.
Tools for blocking copycats. Tools for raising money. Tools for licensing. Tools for negotiation. Tools for increasing strategic confidence. Tools for building a real moat around technical work that took time, money, and insight to create.
Boilerplate weakens those tools because it weakens the foundation underneath them.
That is why claim strategy should begin much earlier than the claim draft itself. It should begin when the business decides what is worth protecting, what future flexibility matters most, and what technical story truly drives company value.
When that thinking is built into the spec from the beginning, claim strategy gets much stronger later.
And that is exactly the outcome businesses should aim for.
Why invention intake is where quality really starts
By the time you see boilerplate in the draft, the real problem may have started much earlier.
It may have started during intake.
If the invention was not captured clearly at the beginning, the drafting stage becomes much harder. AI can help organize material, but it cannot rescue missing substance. If the intake is shallow, the draft will usually be shallow too.
Good invention intake is not about asking for a polished summary.
It is about pulling the real invention out of the team.
That means asking what changed from the old approach. It means asking where the technical pain existed. It means identifying the key design choices, the flow changes, the control logic, the system relationships, the state behavior, and the meaningful alternatives.
For AI-related inventions, this also means separating the model from the surrounding system. Many teams say “the invention uses AI” when the real invention is actually in the architecture around the AI. Maybe the important part is how context is selected, how outputs are filtered, how confidence is used, how memory is stored, how privacy is preserved, or how feedback is integrated. Intake has to surface that.
Strong intake also pulls from real startup materials. It should not rely only on memory. It can use architecture diagrams, design docs, code structure, product notes, technical debates, test results, and internal explanations that already exist. The patent process should meet the team where the work is already happening.
That is a huge part of modern patent efficiency.
The better the intake, the less the draft depends on generic filler later.
This is one place where PowerPatent is especially useful. It is built to help startup teams capture invention detail from real technical work instead of forcing them into a clunky, old-school process. That leads to better drafts, fewer gaps, and stronger filings without dragging the team into months of unnecessary friction. Learn more here: https://powerpatent.com/how-it-works
A smarter way to use AI in the workflow
The best use of AI is not to have it invent the patent.
The best use is to have it help express an invention that has already been captured.
That difference is everything.
AI is very helpful at turning notes into paragraphs. It can improve consistency. It can help restate a complex mechanism more clearly. It can help connect sections. It can help expand a real embodiment into related variants. It can help compare two descriptions and point out mismatch. It can help spot repetition. It can even help identify when wording has become too generic.
All of that is useful.
What AI is not especially good at is deciding what part of your system is truly inventive when the input material is thin or vague. It is not especially good at knowing which details matter most for future support. It is not especially good at distinguishing supported breadth from empty abstraction unless a human has already provided that logic.
A strong workflow often looks like this.
First, capture the invention clearly in plain technical terms.
Then create one or two strong core embodiments.
Then identify the meaningful variation points.
Then use AI to draft around that grounded material.
Then review the output aggressively for generic language.
Then bring in expert judgment to make sure the broad framing is supported and the important angles are preserved.
That is a much better system than asking AI for a complete patent spec in one shot and hoping the answer is close enough.
The question is not whether AI belongs in patent drafting.
It does.
The real question is where in the workflow it belongs and what job it should be doing.
How to tell if a paragraph is actually helping
This is one of the most useful habits a founder can build during review.
Read each important paragraph and ask: what job is this paragraph doing?
A strong paragraph may define a relationship between components. It may explain how data changes form. It may describe a decision rule. It may show when the system switches states. It may explain why a ranking signal matters. It may show how confidence changes the output path. It may describe a useful alternative embodiment. It may tie a figure to a real implementation. It may explain a technical reason for a performance improvement.
A weak paragraph does much less.
It says the system can perform a function.
That is usually not enough.
A helpful test is to remove the invention area and ask whether the paragraph could still describe a huge number of unrelated software systems. If the answer is yes, the paragraph is probably too generic.
Another helpful test is to look at the nouns and verbs. Do they reveal concrete interactions? Or do they stay trapped in soft words like system, module, component, engine, data, process, determine, analyze, and generate? Those words are fine in moderation, but they cannot carry the whole document.
Strong patent paragraphs tend to have more shape. They mention confidence thresholds, graph edges, repository permissions, trust scores, state transitions, token budgets, cache rules, update windows, fallback conditions, or synchronization behavior. They tell the reader what is happening in a way that future claims can build on.
That is what real support looks like.
What to do when the draft is already full of boilerplate
Sometimes the draft is already done.
Or at least it feels done.
But once you read it closely, you realize it is full of generic language, repeated structure, and empty formal phrasing.
That does not always mean you need to start over from nothing.
The smartest move is usually to identify the strongest parts first.
Maybe there is one good embodiment hidden in the middle. Maybe there is one figure that actually captures the system. Maybe there is one example that reveals the real flow. Maybe there is one paragraph where the invention finally becomes clear. Those are the living parts of the draft.
Find them.
Then isolate the dead language. This includes sections that simply describe generic computing environments, repeated functional paraphrases, stock benefit statements with no mechanism, and paragraphs that could describe almost any software system.
Once you can see the useful material clearly, rebuild around it.
Expand the real embodiment. Add more detail where the mechanism is thin. Improve the figures. Insert examples. Clarify the “why” behind the design. Add alternatives that truly track the same inventive idea. Replace vague labels with more meaningful ones. Tighten the flow so each paragraph does real work.
Then trim the filler.
Not every standard phrase has to disappear. Some conventional language belongs in many patent documents. The goal is not to purge every familiar sentence. The goal is to stop generic text from taking up the space where invention support should live.
Finally, do a consistency review. AI-heavy drafts often drift. A component changes names. A sequence changes order. One section implies a threshold, another does not. One section makes the system sound centralized, another sounds distributed. Boilerplate often hides those problems because it smooths everything into the same generic tone. Once the draft gets more specific, you can spot and fix those mismatches more easily.
The role of real attorney oversight
This is where the market often gives founders the wrong choice.
It acts like there are only two options.
Either you go the old way and accept a slow, expensive, painful process.
Or you go the all-AI way and accept the risk of shallow, generic drafting.
That is a bad choice.
The better answer is the combination of smart software and real human judgment.
AI can help with speed. It can help with structure. It can help reduce the burden on founders. It can help move a draft forward quickly.
But real patent attorneys bring something AI does not bring well on its own. They bring judgment. They know how to spot unsupported breadth. They know where an invention has been overabstracted. They know how to press for missing embodiments. They know how to align the drafting with likely claim strategy. They know how to tell whether a paragraph is doing real legal and technical work or just sounding formal.
That kind of oversight matters even more when AI is involved because AI-generated boilerplate often sounds fine until someone with experience looks closely.
A skilled reviewer can ask the right questions.
Where is the invention here?
What exactly distinguishes this from generic implementation?
Which paragraph supports the broadest claim angle?
Why are these two sections describing the same part differently?
What variations are real, and which ones are just filler?
Those questions raise the quality of the filing in a way that pure automation usually cannot.
That is why a modern platform like PowerPatent makes so much sense for startup teams. It lets founders move with the speed of software while still getting real attorney oversight to make sure the filing is actually strong. That combination is how you avoid both old-school delay and shallow AI output. See how it works here: https://powerpatent.com/how-it-works
Why tactical depth matters more than raw length
AI makes it easy to generate a lot of words.
That means founders have to become more careful about what they count as progress.
A long draft is not necessarily a strong draft.
In fact, many of the weakest AI-generated patent specs are impressively long. They have pages of formal language, lots of repeated structures, and many broad statements that create the appearance of depth.
But support is not measured by page count.
It is measured by how much real invention detail is captured, how clearly that detail is explained, and how effectively it supports broader framing.
A shorter draft with dense, meaningful description can be much stronger than a longer draft padded with boilerplate.
What matters is tactical depth.
Does the draft explain the mechanism?
Does it describe variations that matter?
Does it connect design choices to results?
Does it show real flows?
Does it preserve the shape of the invention?
Does it support future claim angles?
That is the standard.
Not the number of pages.
Not how official the writing sounds.
Not how much text AI can generate in one pass.
A better mindset for founders
The best founder mindset is simple.
Do not ask, “How do we generate a patent document fast?”
Ask, “How do we capture our invention well without slowing down the company?”
That second question leads to better choices.
It reminds you that the job is not document creation. The job is invention capture.
It reminds you that AI is a tool, not the author of the invention.
It reminds you that broadness only helps when it is supported.
It reminds you that a polished draft can still be weak.
It reminds you that the patent should sound like your actual product and engineering work, not like a general sample from the internet.
That mindset shift is powerful.
Once you make it, the whole process changes. You stop rewarding text for being long and formal. You start rewarding it for being grounded and useful. You stop accepting generic sections just because they sound official. You start asking whether they support what matters.
That is how stronger patent filings get built.
What the strongest teams do differently
The strongest startup teams do not avoid AI.
They just do not surrender to it.
They use AI for acceleration, drafting help, consistency, and organization. They let it reduce friction. They let it save time.
But they keep control over the core work.
They make sure the invention story is clear before the drafting gets formal.
They insist on examples.
They use figures to force specificity.
They review for support rather than surface tone.
They make room for expert oversight before filing.
They refuse to confuse generic language with broad protection.
They understand that the patent should preserve the real logic of the system, not flatten it into template wording.
That is the difference.
The best teams do not merely file faster.
They file better.
And they do it without turning patenting into a giant burden.
The strongest teams do not treat patent drafting like a writing task.
They treat it like a business system.
That is a big difference.
Weak teams wait until someone says, “We should probably file a patent,” and then they scramble to turn half-finished notes into a draft. Strong teams do something else. They build habits that make invention capture easier, cleaner, and far more useful over time.
They know that strong patents do not start with better wording. They start with better internal discipline.
That does not mean a heavy process. It means a smart one.
The best teams make sure the right ideas are captured while they are still fresh. They do not rely on memory months later. They do not assume the product roadmap will preserve the details. They do not leave invention strategy trapped in one engineer’s head. They build a repeatable way to spot technical breakthroughs early and turn them into protectable assets before the details get blurred.
That is one reason strong companies create better patent outcomes with less stress. They are not reinventing the process every time. They are creating a reliable path from product insight to patent protection.
They connect patent strategy to company strategy
The strongest teams do not file patents just because they can.
They file around what matters most to the business.
That means they step back and ask a sharper question: which parts of our technology create real leverage for the company over the next one to three years?
Sometimes that is the core engine. Sometimes it is an infrastructure layer. Sometimes it is a workflow that makes the product cheaper to run, easier to scale, or harder to copy. Sometimes it is a hidden system feature the customer never sees but that gives the company an edge in speed, quality, or cost.
This is where many businesses go wrong. They chase novelty instead of advantage.
A feature can be technically interesting and still not matter much to the company’s long-term position. Meanwhile, a less flashy internal system may be the real moat. Strong teams know the difference.
They usually map patent effort to business value in a simple way. They look at what drives product differentiation, what investors may care about, what competitors are likely to copy, what future licensing value may exist, and what technical capabilities are becoming central to the company’s story.
That creates focus.
Instead of spreading patent effort across random ideas, they put attention on the systems that deserve protection first.
A useful internal exercise is to ask product, engineering, and leadership one question every quarter: if a competitor copied three parts of our stack next year, which three would hurt us most? The overlap in those answers is often where patent attention should go.
They build an invention pipeline, not a one-time event
Weak teams treat patents like isolated projects.
Strong teams build an invention pipeline.
This means they do not wait for a big, dramatic breakthrough. They know that protectable value often appears in smaller technical advances over time. A new routing method, a better way to handle uncertainty, a model control layer, a system for data quality, a trust-scoring framework, a latency fix, a privacy-preserving process, a human review loop, or a deployment design can all matter.
The strongest teams create a simple habit of collecting those moments.
That can be as basic as a monthly invention review with leads from engineering and product. It can be a lightweight form tied to sprint retrospectives. It can be part of architecture reviews. It can be a running document where technical leads drop short notes when a team solves something in a new way.
The point is not bureaucracy.
The point is continuity.
When invention capture becomes part of the operating rhythm, businesses stop missing valuable filing opportunities. They also create better raw material for future drafting because the details are captured close to the moment of invention.
A very practical way to do this is to ask engineers to record four things whenever they believe they solved something important: what the old approach was, what failed or felt limited, what changed, and why the new method works better. That short habit can become a goldmine later.
They assign ownership before the filing becomes urgent
One hidden reason patent projects go sideways is simple.
Nobody owns the process until it becomes urgent.
Then everyone rushes.
The strongest teams solve that early. They decide who owns invention intake, who gathers technical inputs, who reviews the draft for product accuracy, and who makes the final call on priority. That clarity speeds everything up.
Ownership does not need to sit with legal. In startups, it often works better when one product leader, technical founder, or engineering manager acts as the internal patent coordinator. That person does not need to write the patent. They just need to make sure the right information shows up at the right time.
This creates real business value because it reduces drift.
Without ownership, useful details stay scattered across Slack threads, whiteboards, code comments, and individual memory. With ownership, those details start getting pulled together before they go stale.
A simple operating rule helps here: every potential filing should have one technical owner and one business owner. The technical owner protects accuracy. The business owner protects priority. That balance helps the company avoid both overfiling and underfiling.
They train engineers to spot patent-worthy work
The strongest teams do not assume engineers will naturally know what is patent-worthy.
They teach them what to look for.
This is not about turning engineers into lawyers. It is about helping technical people recognize when their work may have strategic protection value.
Many engineers think patents are only for giant breakthroughs or research-level inventions. That belief causes businesses to miss a lot. In reality, many valuable patents come from practical system improvements. Better orchestration, smarter validation, cleaner fallback logic, more efficient memory handling, stronger privacy workflows, better ranking systems, lower-cost compute design, safer automation layers, and hybrid control methods can all matter.
When engineers learn how to spot those moments, the quality of invention capture goes up fast.
The best internal guidance is simple. Tell teams to flag work when it meets one or more of these conditions: it solved a hard technical tradeoff, it replaced a common industry approach, it created a measurable system advantage, it made the product easier to scale or defend, or it would be painful if a competitor copied it.
That kind of training changes behavior. It makes the patent process proactive instead of reactive.
They preserve decision history, not just final features
One of the smartest things strong teams do is preserve why decisions were made.
Not just what shipped.
That is important because patent strength often comes from design reasoning. The “why” behind the system is often what separates a generic feature from a real inventive approach.
For example, it matters that a team moved a validation step earlier in the flow because late validation caused too many expensive retries. It matters that a ranking system uses source trust because raw relevance produced poor grounding. It matters that a local processing stage exists because privacy rules blocked direct cloud transfer.
Those design reasons are valuable.
But many companies lose them because they only record the final architecture, not the path that led there.
The strongest teams preserve decision history in lightweight ways. They keep short architecture notes. They save technical tradeoff summaries. They log why one route was chosen over another. They keep internal design memos accessible. Later, those materials make invention capture much easier and much stronger.
A very actionable move for businesses is to create a simple rule for major technical changes: every major architecture decision gets a one-page note covering the problem, rejected options, selected approach, and technical reason for the choice. That document is useful for engineering, and it is extremely useful for patent work later.
They think in families of protection, not single filings
Weak teams often think one idea equals one patent.
Strong teams often think more strategically.
They ask whether an invention should be protected as a family.
That means looking beyond the first filing and asking whether there are multiple protectable layers in the same business capability. Maybe there is a core system architecture, a special ranking method, a privacy control mechanism, a workflow integration layer, and a deployment approach that all relate to the same product capability. Filing those over time can create a much stronger position than trying to force everything into one document.
This matters for business because competitors rarely copy a system in exactly one way. They copy around the edges. They copy the flow. They copy the controls. They copy the user-facing layer while changing the backend. Or they keep the backend while changing the interface.
Teams that think in families are better prepared for that reality.
A smart internal question is this: if we filed on the core concept today, what adjacent implementation choices might deserve their own protection over the next twelve months? That question helps businesses create a more durable IP roadmap instead of making isolated filing decisions.
They use patent reviews to sharpen product thinking
The strongest teams do not see patent review as a distraction from product work.
They use it to improve product thinking.
This is one of the most overlooked benefits of doing patent work well.
When a team has to explain exactly how a system works, why it is better, what tradeoffs it solves, and what alternatives still fit the same concept, they often gain sharper clarity about the product itself. Weak points get exposed. Ambiguous language gets cleaned up. The team becomes more precise about where the real innovation lives.
That clarity helps beyond patents.
It can improve product positioning. It can help with technical hiring. It can strengthen fundraising narratives. It can make roadmap planning more focused. It can also help leadership better understand which parts of the company’s stack are true differentiators and which are easier to replace.
In that sense, strong teams get two wins from the process. They get better patent filings, and they get better strategic understanding of their own technology.
A useful practice is to hold a short post-drafting review after each important patent project and ask: what did we learn about our own product that was not obvious before we started this draft? That keeps the patent process tied to operating insight instead of treating it as a side task.
They review drafts like operators, not spectators
The strongest teams do not just read patent drafts for errors.
They review them like operators.
That means they test whether the document reflects real business and technical reality. They ask whether the draft captures what makes the system valuable, not just whether it sounds polished. They challenge generic statements. They notice when the draft sounds broad but loses the real mechanism. They push for commercial relevance without turning the document into marketing copy.
This kind of review is more strategic than passive proofreading.
It requires teams to ask questions like: if we were pitching the technical moat behind this product, does this draft actually describe it? If a competitor read this after publication, would the real edge still be visible? If an investor asked what we truly built that others would struggle to copy, would this draft reflect that answer?
Those are business questions, not just drafting questions.
And they lead to better patents because they keep the filing connected to the company’s real value.
They measure patent quality by future usefulness
Weak teams celebrate when a patent gets filed.
Strong teams care whether it will be useful later.
That is a much better standard.
A useful patent asset can support fundraising. It can help with diligence. It can strengthen acquisition conversations. It can help discourage copycats. It can support licensing leverage. It can create negotiation value. It can support a broader IP story that makes the company look disciplined and defensible.
That is why the best teams do not ask only, “Did we file?”
They ask, “Will this filing matter?”
That question changes how they prepare, review, and prioritize.
It pushes them toward stronger technical detail, better alignment with business value, and smarter timing. It also reduces the temptation to file weak, generic applications just to say the company has more patents in process.
A helpful internal metric is not patent count alone. It is patent count tied to strategic areas of the business. If the portfolio grows but the filings do not align with the company’s real competitive engine, the numbers can give a false sense of strength.
They choose speed with structure, not speed with shortcuts
The best teams still care about speed.
They just do not confuse speed with skipping steps that matter.
They know the right answer is not a slow, painful patent process. But they also know that pure speed without structure leads to shallow output. So they build systems that are fast because they are organized, not because they are careless.
That is the model businesses should aim for.
Capture invention details early. Tie filing decisions to business priorities. Assign ownership. Preserve technical reasoning. Use AI where it helps. Bring in real oversight where judgment matters. Review drafts for strategic value, not just completion.
That is what the strongest teams do differently.
They do not just produce more patent documents.
They build a smarter engine for turning technical progress into durable company value.
Final thoughts
Boilerplate in AI-generated patent specs is not a minor problem.
It is one of the biggest risks in modern patent drafting.
It shows up when a real invention gets covered by generic text. It shows up when AI is asked to replace invention capture instead of support it. It shows up when speed is mistaken for quality. It shows up when founders see a polished draft and assume the hard work has already been done.
The answer is not to fear AI.
The answer is to use it with discipline.
Start with the invention story.
Capture what changed and why.
Use plain language before formal language.
Build strong embodiments and real examples.
Use figures that force clarity.
Keep broad language connected to specific support.
Review paragraphs for the work they actually do.
Bring in expert judgment before filing.
That is how you keep your patent spec from turning into a long, smooth, generic document that could describe almost anything.
And that is how you make sure your patent actually reflects the real edge your team created.
If you want a better way to do that, PowerPatent helps founders file stronger patents faster by combining modern software with real attorney oversight. It is built for startups that want speed, control, and confidence without settling for boilerplate. See how it works here: https://powerpatent.com/how-it-works
