Patent Considerations for Hardware & PCB Engineers: 8 Pitfalls to Avoid

1. The on-sale bar starts running before you think it does

In the United States, you have one year from the first public disclosure, offer for sale, or commercial use of an invention to file a patent application, or you lose the right to patent it. For hardware, this deadline is easy to miss because “offer for sale” doesn't require an actual sale. Sending a customer a quote, taking a purchase order, or showing a working prototype at a trade show with pricing attached can all start the clock, even if the product isn't finished or the deal never closes.

The bar only looks at offers you make to sell the invention to someone else, so buying-side steps like soliciting a tooling quote from a manufacturer don't trigger it on their own. But those steps carry a separate risk that's covered in the next section. This matters more for hardware than software because physical products usually go through a longer path to market: tooling vendors, contract manufacturers, distributors, beta customers. Each of those relationships is a chance to disclose the invention or trigger the bar without realizing it. Track your first disclosure date the same way you'd track a shipping deadline, and talk to your patent counsel before you talk to a manufacturer or a customer.

Most countries outside the U.S. don't give you a grace period at all. If you want patent rights abroad, the safe rule is to file before any public disclosure, not within a year of it.

2. Sending drawings to a vendor can be a disclosure that costs you the patent

This is the single most common way hardware clients damage their own rights, and it usually happens months before anyone thinks about patents. You need a quote, so you email a STEP file and a dimensioned drawing to four shops. Nobody has signed anything. You've now disclosed your invention four times.

What separates a safe disclosure from a damaging one is confidentiality. A disclosure made under a genuine obligation of confidentiality generally isn't a “public” disclosure and doesn't count against you. A disclosure to someone with no such obligation can qualify as prior art against your own application, and outside the U.S., where there's typically no grace period, it can end your rights in that country outright.

A few things worth knowing:

• The NDA has to exist before the material goes out. Signing one afterward doesn't retroactively make the earlier disclosure confidential. If a vendor is slow to sign, that's a reason to wait, not a reason to send the file and sort out paperwork later.
• Vendor-supplied NDAs are often too narrow to help. Many boilerplate mutual NDAs cover “business and pricing information” but say little about technical data, exclude anything the vendor claims to already know, or expire in two or three years. Read for whether it actually covers drawings, specs, tolerances, and test data, and whether the term outlasts your filing timeline.
• Without an NDA, vendors have every incentive to reuse your design. Shops legitimately build sample books, portfolios, and capability decks from work they've done. A part you consider proprietary may show up on a website or a trade show table as an example of what the shop can machine.
• Every RFQ recipient is a separate exposure. Sending the same package to six shops to compare pricing multiplies the risk six times. Consider sending the full package only to a shortlist and giving the rest enough to quote without revealing what makes the design novel.
• You can often split the work. If no single vendor needs the complete assembly to do their part, don't give them the complete assembly. Partitioning across suppliers limits what any one of them can reconstruct or reuse.

One point of reassurance: paying a contract manufacturer to build your product is generally not treated as a sale of the invention itself for on-sale bar purposes, because the manufacturer is selling you services rather than buying your invention. So the risk here is disclosure and confidentiality, not the one-year sales clock. That distinction matters when you're deciding what to worry about, but the practical advice is the same either way.

The habits that prevent all of this are cheap: get the NDA signed first, mark drawings and specs as confidential, send the minimum a vendor needs to do the job, and keep a dated log of who received which files and when. That log is also what your attorney will ask for if a disclosure question ever comes up, and reconstructing it two years later from an email archive is miserable.

3. Drawings carry more weight than they do in software patents

A mechanical patent application typically lives or dies on its figures. Examiners, and later courts, will compare your claims against your drawings to figure out what you actually invented. For hardware, this means:

• Every part you plan to claim needs to show up in a drawing, labeled with a reference number.
• Drawings should show the invention from enough angles and in enough states (assembled, exploded, in operation) that someone could build it from the application alone.
• If your device has multiple embodiments, each one generally needs its own set of figures.

CAD files are not patent drawings. Patent drawings follow USPTO formatting rules (line weights, shading conventions, numbering) that most CAD exports don't meet. Budget time and a professional draftsperson for this step, and start it early. Reworking drawings after a filing deadline is looming is a common source of rushed, unfair applications.

4. Claims describe function and structure, not just parts

A common pitfall is to draft claims almost like how you'd write a bill of materials: a list of components. That approach tends to produce narrow claims that are easy for a competitor to design around by swapping one part for a functionally similar one.

Good mechanical claims usually describe how the parts relate to each other and what they do. Instead of “a spring and a lever arm,” a stronger claim says something closer to “a biasing element configured to urge the lever arm into a first position.” That phrasing covers a spring, but it also covers a different mechanism that does the same job, which is often the point.

Be careful with “means-plus-function” language (claims that say “means for doing X” instead of naming a structure). Courts read those claims narrowly, limited to the specific structure described in your application and its equivalents, not the function in the abstract.

5. Obviousness is assessed by combining what's already known

A large share of mechanical rejections come down to obviousness, not novelty. The invention doesn't need to already exist somewhere; an examiner just needs to show that combining two or more existing devices, in a way a skilled engineer would have found natural, gets you to the same result.

This is why “nobody's done exactly this before” isn't enough to justify skipping a prior art search. What matters is whether the combination itself was predictable. If your invention takes a known mechanism and applies it in a new field, or combines two known solutions in a way that produces an unexpected result (lower cost, higher reliability, a problem nobody had solved with that combination before), document that reasoning. It's often the strongest part of your application.

6. Working prototypes change your options, not just your confidence

Building and testing a prototype is a form of “reduction to practice,” and it can matter for a few reasons beyond proving the thing works:

• It gives you data (tolerances, failure modes, performance numbers) that can support broader claims than a paper design alone.
• It creates a paper trail (dated test logs, revision history, failure analysis) that can help establish your invention date if priority is ever disputed.
• It also creates the disclosure risk described above. Testing at a customer site, a trade show, or even with an outside vendor who isn't under NDA can start the one-year clock or, outside the U.S., cut off rights entirely.

Keep dated records of design iterations and testing results as a matter of routine, not just when a dispute seems likely. Good documentation costs little at the time and is often decisive later.

7. Inventorship follows who contributed to the claims, not who built the thing

On a hardware team, it's common for one person to write the requirements, another to model it in CAD, another to test it, and a fourth to fix problems that come up in testing. Inventorship isn't about job title or who ran the test rig; it's about who contributed to the specific ideas that end up in the claims. Someone who only followed instructions or built a prototype exactly as specified typically isn't a co-inventor. Someone who suggested a design change that ends up in a claim, even a small one, typically is.

Getting this wrong can create real problems later, including challenges to the patent's validity. Loop in your attorney or agent whenever a design changes hands between people during development, and don't assume the org chart tells you who the inventors are.

8. Printed circuit boards (PCBs) raise a few issues of their own

PCB design sits at the boundary of how hardware and software patents are typically written, and that boundary creates some issues that don't come up with purely mechanical inventions.

Claim the circuit function, not the layout. A schematic shows a topology: which components connect to which nodes and why. A layout is one physical arrangement of that topology on a board. Claims almost always protect the topology and the values or relationships that make it work (a particular filter arrangement, a specific feedback path, a protection circuit triggered by a defined condition), not the trace routing or component placement. If a competitor buys the same chips and wires them the same way but lays out the board differently, the layout won't save them from infringing a well-drafted circuit claim.

Board layout itself has its own, separate protection. In the U.S., mask work protection under the Semiconductor Chip Protection Act covers the topology of semiconductor chips, not printed circuit boards, so it doesn't apply here. What can help for a board layout is copyright in the layout as an original work, or, in some cases, trade dress if the board's appearance functions as a source identifier. These are worth raising with your attorney or agent as an addition to patent protection, not a substitute for it, since they protect the arrangement rather than the underlying circuit.

A lot of circuit prior art lives in datasheets and application notes, not patents. Component manufacturers publish reference designs and app notes showing how to wire their parts for common use cases. Examiners search these along with patent literature, and a design that just follows a manufacturer's suggested application circuit is unlikely to be patentable on its own. The patentable contribution is usually in what you changed from the reference design and why: a component value chosen to solve a specific problem, a protection scheme added for a failure mode the reference design doesn't address, or a way of combining two reference circuits that isn't obvious from either one alone.

Reverse engineering a board is easier than reverse engineering a mechanism. X-raying or delayering a board can reveal the schematic fairly directly, especially if silkscreen labels or unremoved component markings are left in place. If you're weighing patent protection against trade secret protection for a board design, keep in mind that boards are generally easier to reverse-engineer than firmware or mechanical assemblies, which pushes many circuit-level inventions toward patenting rather than trying to keep them secret.

Firmware that makes the circuit work can raise separate eligibility questions. If part of what makes your board novel is the firmware controlling it (a control algorithm, a calibration routine, a way of interpreting sensor data), that piece may need to be described and claimed differently from the hardware, since software-related claims are reviewed under a different legal standard for what counts as patentable subject matter. Flag any firmware-dependent functionality for your attorney or agent separately from the hardware claims so it gets analyzed under the right framework.

None of this replaces a conversation with your patent attorney or agent about your specific invention and business goals, but if you keep these eight points in mind as your project moves from concept to prototype to product, you'll walk into that conversation with better records, fewer surprises, and a stronger application when the time comes to file.