Riahi Patents · Help

Filling in the technical intake

What the form is for, what each section is asking, and what happens after you submit.

Before you start

What this is for. An SR&ED claim rests on the knowledge relevant to your project not having been publicly available when the work began. We search the patent and scientific literature as it stood at that date and report what was, and was not, already disclosed. This form gives us the specification we search against.

Who should fill it in. The engineer or scientist who led the work — not your finance team and not your SR&ED preparer. The assessment we issue will attribute the technical description to the person who signs it.

How long it takes. Thirty to forty-five minutes. Section C is the one that matters; the rest is quick.

Approximate is fine. An approximate answer is far better than a blank one. We will come back to you on anything unclear.

One project per form. If your claim covers several projects, complete a separate form for each. Projects that shared a team but solved different technical problems are separate projects here.

Signing in

Accounts are created by Riahi Patents. You will have been given an email address and a password, or an invitation link.

Your projects

Above the form is the list of your projects. Start a new project opens a blank form; clicking a project in the list opens it. Each one shows whether it is still a draft or has been submitted.

Your answers are saved as you type — to your account, not to the computer. Close the page whenever you like and continue later from any computer. The grey line under the buttons at the bottom of the form tells you when the last change was saved.

A · The project

Project name is whatever you call it internally. Fiscal years are the years being claimed. Status is whether the work is still running, finished, or abandoned — an abandoned project can still be claimed.

A1. When work began

This is the most important date on the form. We search the literature as it stood at that date, so anything published after it does not count against you. Give the month and year if you can, and say what you count as the start — the first experiment, the first design review, the first prototype. If earlier work was only reading and evaluating, say so and leave it out.

B · What you were trying to do

B3 is the goal in plain words, as you would explain it to a new engineer on the team. B4 is the target that had to be hit — the numbers: a temperature, an efficiency, a tolerance, a cost. B5 is why the things that already existed could not hit that target. Name the approaches you tried or evaluated and what went wrong with each.

Numbers matter. "Faster" tells us little; "under 40 ms at 95th percentile, where the best commercial option managed 120 ms" tells us exactly what to look for.

C · What you actually built

This section is the specification we search. List the technical elements of what you built — the mechanisms, one per row, in your own words. Each row is one idea: how frost is detected, how a value is estimated, how two parts are arranged. Twelve rows are available; use as many as you need.

For each element, say whether it was routine to implement or where the difficulty was. Be honest about the routine ones. A list where everything is hard is less credible than a list where three things are hard and seven are routine, and it makes the three stand out.

Write mechanisms, not benefits. "A more efficient defrost cycle" is a benefit and cannot be searched. "Defrost is initiated when the marginal heat delivered per unit of frost removed falls below the projected energy cost of the cycle" is a mechanism and can.

D · What was already out there

D7 — approaches you considered and rejected before starting, and why. Finding these in the published literature supports your account of knowing the state of the art. D8 — papers, patents, products or reports you actually consulted. D9 — anything you expected to find published and could not. That last one is your own statement of the gap; we test it directly.

E · Vocabulary

E10 — what people in your field call this. Terms of art, older names, competing names, vendor names, common misspellings. Patents often use different words from research papers about the same thing, and this single answer does more for the search than any other. If your team invented a name for something internally, tell us that too, and tell us what the outside world would call it. E11 — anything else: adjacent fields where the same technique appears, dead ends we should not waste time on, anyone we should not contact.

Supporting files

Optional. Anything that helps us understand the work: a drawing, a test log, a spec, an internal review slide, an earlier report. PDF, Word, Excel, PowerPoint, images or a zip, up to 25 MB each. Drop them on the box or choose them from your computer. Only you and Riahi Patents can see them, and they lock with the project when you submit.

Submitting

When everything is in, tick the confirmation, sign with your name and the date, and click Create the Word document. Two things happen:

Spotted something wrong after submitting? Tell us and we will reopen it for you. You can download the document again at any time from the project.

Contact

Anything unclear, or a question the form does not cover: info@riahipatents.com.