Technology Base Assessment

TECHNICAL INTAKE · ONE PROJECT PER FORM ? Help

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 what we need to run that search.

Who should complete it. The engineer or scientist who led the work — not your finance team and not your SR&ED preparer. Your answers become the specification we search against, and the assessment we issue will attribute them to you.

How long it takes. Thirty to forty-five minutes. Section C is the part that matters; the rest is quick. Approximate answers are far better than blank ones — we will come back to you on anything unclear.

You do not have to finish in one sitting. Your answers are saved to your account as you type. Close the page and come back later — from any computer — and pick the project up from the list above the form.

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

A The project

Month and year is enough. Tell us what marks the start — the first experiment, the first prototype, the decision to build it. If the start was gradual, say so.

B What you were trying to do

Plain technical language. Assume the reader is an engineer, but not one from your field.

Accuracy, latency, throughput, temperature, yield, power, cost, tolerance. This is the single most useful answer on the form — it is what separates “we improved it” from a technical objective we can search against. Example: “±2 mm at 30 Hz on a moving subject, on battery, without a calibration step.”

What did you try or evaluate first — off-the-shelf components, published methods, an existing internal system — and where specifically did each fall short?

C What you actually built

This is the heart of the form. List the technical elements of what you built — the mechanisms, not the benefits. Eight to twelve is typical. Each becomes a separate line of searching, so specificity here decides the quality of what we can tell you.

What a good element looks like

Too vague — we cannot search this: The controller keeps the product at the right moisture level, quickly and accurately.

Specific enough — we can: The controller infers moisture indirectly from the difference between inlet and exhaust air temperature rather than measuring the product directly, and corrects that inference for ambient humidity sampled once per minute.

The difference is that the second names a mechanism. If an element could describe a competitor’s product equally well, it is still too vague.

Be honest about the routine ones — a list where everything is hard is less credible, not more. Leave unused rows blank.

#Technical element — the mechanism, in your own wordsCharacter
1
2
3
4
5
6
7
8
9
10
11
12

Need more than twelve? Put the extras in question E11 at the end.

D What was already out there

For each, why did it fail — was it a hard technical limit, a cost or manufacturing constraint, or did you simply not have time? All three are useful; they are just different findings.

Products, papers, standards, patents, open-source projects, conference talks, a competitor’s datasheet. Names or rough descriptions are fine — we will find the documents. If you looked and found nothing useful, say that: it is a finding in itself.

A method you assumed would be published somewhere, a component you thought existed, a standard you expected to cover this case.

E Vocabulary

List the terms of art, including any older names, competing names, vendor-specific names, or common misspellings. Patent literature often uses different words from a research paper about the same thing, and this single answer does more for search recall than any other. If your team invented a name for it internally, tell us that too — and tell us what the outside world would call it.

Additional elements beyond twelve, adjacent fields where the same technique appears under a different name, dead ends we should not waste time on, or sensitivities about who we should not contact.

Supporting files optional

Anything that helps us understand the work: a drawing, a test log, a spec, a slide from an internal review, an earlier report. PDF, Word, Excel, PowerPoint, images or a zip — up to 25 MB each. They are kept with this project and only you and Riahi Patents can see them.

Drop files hereor

    F Confirmation

    The answers above describe work actually carried out by this organisation, to the best of my knowledge. I understand that Riahi Patents will use them as the technical specification for a prior-art search, and that the resulting assessment will attribute this specification to me.

    Saved to your account as you type. Creating the Word document submits this project and locks the answers.

    ✓

    Your document is ready.

    It has downloaded to this computer as a Word file. Open it, check it reads the way you intended, and email it to us at info@riahipatents.com.

    This project is now submitted and its answers are locked, so what we search against is exactly what you signed. — or start another project from the list at the top.

    Spotted something wrong after submitting? Tell us and we will reopen it for you.

    Riahi Patents

    Sign in

    The technical intake is kept against your account, so you can stop and come back from any computer.